個人アプリのAI原価を9割落とした話 — 制作日誌 #5

自作のiOSタスク管理アプリには、書いたタスクをAIが「着手できる形」まで補完する機能がある。「病院」と書けば、持ち物・所要時間・サブタスクに割ってくれる、という類のものだ。

これが、有料プランの枠を上限まで使うユーザー1人につき、月¥66の原価になっていた。月額課金の値段を考えると、ヘビーユーザーばかりになった瞬間に利益が消える構造だ。個人開発なので、この赤字は全部自分が被る。

結論から書くと、**¥66 → ¥6.8（最悪ケース想定、約9割減）**まで落とせた。以下はその作業記録と、そこで捨てたものの話。

前提：どこに金がかかっていたのか

構成はシンプルで、アプリ → 自前のサーバー → LLM（大規模言語モデル）のAPI、という流れ。使っていたのは Anthropic の Haiku 系（安価・高速な小型モデル）だった。

原価の内訳を見ると、支配的だったのはWeb検索だった。「近くの店」「所要時間」といった補完をまともにやろうとすると、モデルに検索させることになる。この検索1回あたりの課金が、素のトークン（AIが読み書きする文字のかたまり。課金の単位）代よりずっと重かった。

つまり原価問題は「モデルが高い」のではなく、**「モデルに調べさせているのが高い」**だった。ここを取り違えると、モデルだけ安いものに替えても大して下がらない。

やったこと1：モデルの乗り換え

Anthropic の Haiku から、Google の Gemini 3.1 Flash-Lite へ移した。単価が桁で違うクラスなので、ここは素直に効く。

ただし、ここで1つ罠を踏んだ。当初は世代の古い gemini-2.5-flash-lite を指定していたのだが、新しく作ったGoogleアカウントからは呼べなかった。返ってきたのは「このモデルは新規ユーザーには提供されていない」という趣旨のエラーだ。ドキュメント上は存在するモデルでも、アカウントの作成時期で使えるかどうかが変わる。実際にAPIを叩いて疎通を確認するまで、確定したと思わないほうがいい。

もう1つ、地味に効いたのがJSONを直接返させる仕組み（応答の形をスキーマで縛る機能）だ。以前は「JSONで返して」とお願いして、返ってきた文字列を自分で解析していた。これをやめて、応答の型をAPI側で保証させると、失敗してやり直す回数が減る。やり直しは、そのまま原価なので、これも実質的な値下げになる。

やったこと2：Web検索を既定でOFFにする

一番効いたのがこれだ。Web検索を既定でオフにし、必要なときだけ環境変数で戻せるようにした。

検索を切ると、モデルは自分の知識だけで答えることになる。そこで、プロンプト（AIへの指示文）側を全部書き直した。「調べて正確な値を出せ」ではなく、**「一般的な目安を概算で出せ」**という指示に変えたのだ。

所要時間、費用の相場、持ち物、移動の目安──こういうものは、そもそも厳密な検索が要らない。「病院に行くなら保険証と診察券」に検索は不要だ。検索が本当に要る機能と、要らないのに検索していた機能を仕分ける、というのが作業の実体だった。

あわせて、思考予算をゼロに設定した。最近のモデルには、答える前に内部で長く考えるモードがある。品質は上がるが、その思考分もトークンとして課金される。タスクを分解する程度の作業に長考は要らないと判断し、切った。

代償：飲食店の候補が出なくなった

正直に書く。検索を切ったことで、飲食店まわりの提案がほぼ出なくなった。

理由は、モデルが真面目だからだ。実在するかWebで確認できない以上、店名を出せば嘘になる。だから何も出さない。これは正しい挙動で、むしろ検索なしで店名を出してくるほうが危ない。

結果として「今夜ごはん」的なタスクを書いても、候補は静かなままになった。一方で、サブタスクへの分割、持ち物、出発時刻といった中核の機能は品質が落ちなかった。

ここが判断のポイントで、原価削減とは「機能を均等に薄める」ことではなく「どの機能を捨てるか決める」ことだった。全機能の品質をなだらかに落とすより、切れるものを完全に切ったほうが、残る体験は良い。

検索を戻す選択肢も残してある。ただし戻すと合計額は乗り換え前を超える見込みで、しかも応答の型を縛る仕組みと同時に使えないため、2回に分けて呼ぶ設計が要る。やるなら別の作り込みが要る、という状態で置いてある。

結果と、既存ユーザーへの反映

最終的な数字はこうなった。

ありがたかったのは、この変更にアプリの更新が要らなかったことだ。AIを呼んでいるのはサーバー側なので、サーバーを差し替えた瞬間に、既にインストール済みの全ユーザーが新しい構成に切り替わる。アプリの審査も、アップデートの通知も要らない。

「AIの重い処理はアプリに埋め込まず、必ずサーバー越しにする」という設計を最初に選んでおいたことが、ここで効いた。もしアプリ内から直接APIを叩いていたら、乗り換えのたびに審査を通す必要があり、旧バージョンのユーザーはいつまでも高い構成のままだったはずだ。

同じことをやる人へ

• まず内訳を見る。 「モデルが高い」と思い込んで乗り換えても、支配的なのが検索なら大して下がらない
• やり直しの回数も原価。 応答の形を縛って、パース失敗による再実行を潰す
• 長考は既定で切る。 必要な機能にだけ戻す
• 捨てる機能を決める。 全体を薄めると全部が中途半端になる
• AIを呼ぶ場所はサーバーに置く。 乗り換えの自由が段違いになる

よくある質問

Q. 品質は落ちませんでしたか？ 中核（タスクの分割・持ち物・時刻の見積もり）は体感で落ちていません。落ちたのは、Web検索が前提だった機能（実在の店舗の提案）です。ここは削減と引き換えに捨てた部分だと割り切っています。

Q. なぜ検索を完全に消さず、切替式にしたのですか？ 戻す判断が将来ありうるからです。設定ひとつで戻せる状態にしておけば、収益構造が変わったときに実装をやり直さずに済みます。

Q. 原価の数字は実測ですか？ 公開単価と、上限まで使い切った場合の想定利用量から算出した最悪ケースの試算です。実際の平均利用者はこれより低くなります。実測の平均原価は、利用が溜まってから改めて出す予定です。

この記事で触れているアプリ

本稿の題材は、筆者が個人開発している iOS アプリ THE TASK：AI下調べToDoリスト（App Store・無料）です。書いたタスクをAIが着手できる状態まで補完する、という発想で作っています。他の回は制作日誌シリーズにまとまっています。

あわせて読みたい

• Gmail を AI に裁かせる MCP を自作した話 — 制作日誌 #3
• 強制アップデートが誰にも出なかった — 制作日誌 #6