動くものを作れても利益が残らない理由は設計だ。Claude・GPT副業のAPI赤字を止める3手

AIで何か動くものを作れた瞬間、多くの人が次の壁で詰まる。コストだ。たとえばSIer5年目あたりでClaude Codeを半年触って、自動投稿や要約のような副業向けの仕組みが「とりあえず動いた」状態になったのに、収益はゼロ、API管理画面の数字だけ淡々と積み上がっていく——という展開はよく見る。これは個人の能力ではなくて、設計の話だ。自分は10年以上現役で開発をやってきて、副業でもAIを絡めた発信システムを回しているが、最初に詰まるのは完成度より運用コストの方だった。

結論を先に出すと、コストを下げる手は3つに絞れる。用途ごとにモデルを使い分ける、同じ質問を2回叩かない、失敗した時だけ上位モデルへ落とす。この3つが入っていない仕組みは、規模が広がるほど赤字を吐き続ける。

「動くもの作れた」の次に来る、課金の壁
モデルを1つに固定している限り副業は赤字になる
元記事の著者がやった経路切替の中身
自分が運用で効いたコスト圧縮の3手
仕組みが赤字を生まない設計に変える
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

「動くもの作れた」の次に来る、課金の壁

仕組みが動いた瞬間は気持ちいい。問題はその仕組みが回り続けた時に、ユーザー1人あたりいくらかかっているかを計算していない時に来る。

dev.toに投稿されたある記事で、ブートキャンプを卒業して半年の開発者がこの壁にぶつかった話を書いていた。最初の個人プロジェクトにOpenAIを直結して、友人5人が1週間遊んだだけで想定外の額が乗ったという。「学習目的だったのに」と頭を抱える展開は、AIを触り始めた人の大半が一度は踏む。

副業としてAIを使う場合、これは趣味の損失で終わらない。月の運用コストが副業収入を上回ったら、その仕組みは「動かしておくほど損する装置」に変わる。動くこと自体を目的にすると、ここで止まる。仕組みが完成した時点はゴールではなくて、スタートラインだ。気づくの遅すぎたけど、最初の設計でここを織り込むかどうかで、半年後の収支が完全に分かれる。

モデルを1つに固定している限り副業は赤字になる

副業向けにAIシステムを組む人が最初にやりがちなミスは、全部の処理を1つの高性能モデルに任せることだ。GPT-4oかClaude Opusか、どれでもいい。動くし、品質は高い。だが用途に対して過剰なスペックを払い続ける構造になる。

例えば自分の運用システムには、文章を生成する処理、タグを付ける処理、テーマを分類する処理、コードのチェックをする処理、画像のキャプションを書く処理が並んでいる。これを全部「一番賢いモデル」に任せると、頭の使い所のないタスクにも上位モデル料金を払うことになる。

賢さが全部の工程で要るわけではない。短文の分類なら軽量モデルで十分通る。記事1本の構造化はさすがに上位モデルに任せる。この線引きを最初に設計せず、全部を上位モデルで通している人は、運用が長くなるほどコストカーブが立ち上がる。気づいた頃にはダッシュボードに副業の利益が吸われている、というのが定番の負けパターンだ。

元記事の著者がやった経路切替の中身

元記事の著者は、ギフトのアイデアを出すチャットボットを公開していた。用途は「短い条件文を受け取って、創造的なアイデアを3〜4個返す」だけ。これにGPT-4oを当てていたが、明らかに過剰だと判断し、複数のモデルを並べて比較したと書いている。

比較対象として著者が挙げているのは、DeepSeek V4 Flash、DeepSeek V4 Pro、Qwen3-32B、GLM-4 Plus、そしてGPT-4o。ここ1年で性能を伸ばしてきた新興モデルが並んでいる。同じプロンプトを各モデルに投げ、出力品質と入出力単価を並べて検証した結果、用途によっては「ユーザーが出力差を判別できないレベルで、入出力単価がひと桁安い」モデルが選べた、というのが著者の結論だ。

ここで一つ補足する。著者は「Global API」というサービス名で、これらのモデルを単一エンドポイントから使う構成を紹介している。自分は同サービスを検証していないので推奨はしない。学ぶべきはサービス名ではなく「単一プロバイダに縛られず、用途で安いモデルへ切り替える」という考え方の方だ。直接DeepSeekやQwenの公式APIを叩く構成でも、同じ効果は出せる。

自分が運用で効いたコスト圧縮の3手

ここからは、自分が副業のAIシステム運用で実際に効かせた手を3つに絞る。難しい技術ではない。むしろ「気づくの遅すぎたな」と毎回思うやつだ。

キャッシュで同じ質問を2回叩かない

APIを叩く前に、同じプロンプトが過去に来ていないかを照合する。プロンプト文字列をハッシュ化して、ローカルのストレージに結果を保存する。次に同じプロンプトが来た時は、ストレージから返してそのまま終わり。

これだけで「あれ、自分のシステム、同じ質問けっこう食ってたな」という気づきが出る。元記事の著者はキャッシュヒット率が4割に落ち着いたと書いている。自分の運用でも、似た入力の繰り返しは無視できない比率になった。バッチでループを回している処理に同じプロンプトを混ぜている設計があれば、ヒット率はもっと跳ねる。

ストレージ側は何でもいい。SQLiteでも、Redisでも、ファイル1枚でも構わない。重要なのは「先に確認してから投げる」という順序だけ。地味だけど、効くのはこういう作業の方だ。

用途ごとにモデルを分ける

工程ごとに「ここはどれくらい賢さが要るか」を判定し、モデルを切り替える。短文分類・タグ生成・URL整形のような構造の浅い処理は軽量モデルへ、記事生成・コードレビュー・コンテンツ構造化のように出力構造が深い処理は上位モデルへ。これを最初の設計で分けておく。

実装はそんなに大袈裟ではない。OpenAI互換クライアントなら、modelパラメータを差し替えるだけでコードの骨格は同じまま動く。設定ファイル側で「分類タスク → 軽量」「記事生成 → 中位」「コードレビュー → 上位」のような対応表を持って、呼び出し側はキーで引くだけにする。

差し替え可能な構造にしておく価値は、後から「このタスク、もっと安いやつで十分だったな」と気づいた時に、設定1行で変えられることだ。コードを書き直す必要がない。新しいモデルが出るたびに性能とコストを試して、より安いやつに差し替える運用が回せる。これが効く。

失敗時に高いモデルへ落ちる経路を作る

安いモデルで叩いて、失敗・タイムアウト・空応答・スキーマ違反が返ってきた時にだけ、上位モデルへ上げる。フォールバック経路を明示的に組んでおく。

ポイントは順序だ。最初は安いモデルに賭ける。賭けに勝てば安く済む。賭けに外した時だけ、上位モデルが面倒を見る。8割か9割が安いモデルで通れば、平均コストは大きく下がる。

ここで気をつけたいのは、失敗判定を仕組みに乗せておくこと。空応答だけ拾って終わるのは弱い。出力がJSONで来るならスキーマ検証、文章で来るなら文字数や禁止語のチェック、コードで来るならパース可能性のチェックを入れる。判定が甘いと、安いモデルの低品質出力をそのまま採用してしまって、コストは下がるが品質が崩れる。判定を厳しく置いて、ダメだった時だけ上位モデルに頼る。これでフォールバックが意味を持つ。

仕組みが赤字を生まない設計に変える

副業でAIを回して利益を残すには、「動く」だけでは足りない。「動かし続けても赤字にならない」設計が要る。動くものを作れる人は増えた。利益を残せる人はまだ少ない。差はここで生まれる。

3つの要点を最後にまとめる。

①キャッシュで同じ質問を2回叩かないプロンプトをハッシュ化して結果を保存。先に確認してからAPIを叩く。

②用途ごとにモデルを分ける構造の浅い処理は軽量モデル、深い処理は上位モデル。設定で切り替え可能にしておく。

③失敗時に上位モデルへ落ちる経路を組む安いモデルで叩いて、失敗判定で引っかかった時だけ上位モデルへ。判定基準は厳しめに置く。

動くものを作れた次に来るのは、コストの設計だ。動くことと、稼げることは違う設計の話で、そこを混同しているうちは副業の収益は立ち上がらない。仕組みを作った瞬間に一度立ち止まって、「これが回り続けたら自分の利益は残るか」を計算する癖を持っておきたい。