WordPress プラグインチームにおける AI 支援開発の経済学
WordPress アナリティクスプラグインを開発する小さなチームによる、正直なコスト会計。最適化前の Anthropic 請求額がどうだったか、現在はどうなっているか、そして複利的な節約がどこから生まれているのか。
1 か月目には正直に答えられなかった質問
Claude Code を日常の協働者として使い、WordPress プラグインを出荷するのにどれくらいのコストがかかるのでしょうか。
Statnive を構築していた最初の 1 か月、私たちはこれに答えられませんでした。請求額は分かっていました。何が実際にコストを押し上げているのかは分かりませんでした。ある日は $3、別の日は $11 となり、その変動は出荷したコード量と明確な相関を持ちませんでした。
4 か月後、状況はずっと明確になりました。本記事はそのコスト会計です。お金がどこに使われているのか、支出を概ね 2〜3 倍圧縮するために複合的に効く 4 つのレバー、そして個別の最適化以上に重要だった 1 つの数字を扱います。
ヘッドライン: 同じエンジニアリングのスループットを保ったまま、日次支出は 〜$6/日 から 〜$2〜3/日へ低下しました。節約は加算的ではありません。乗算的です。
AI 支出が実際に向かう先
Anthropic の Claude Code 関連モデルの価格 (2026 年初頭時点):
| Model | Input / MTok | Output / MTok | 用途 |
|---|---|---|---|
| Haiku 4.5 | $1 | $5 | 読み取り専用の探索、検証、ルーチンの修正 |
| Sonnet 4.6 | $3 | $15 | 標準的な開発作業 |
| Opus 4.7 | $5 | $25 | 複雑なアーキテクチャ、深い推論 |
素朴に考えれば、1 つのモデルを選び、その料金 × トークン消費量を支払います。実際にはもっと粒度が細かく、以下に挙げる 4 つの最適化レバーのうち 3 つは、この粒度を活用するものです。
参考までに、操作ごとの典型的なトークン予算は以下のとおりです。
| 操作の種類 | 典型的なトークン数 | 現実的な所要時間 |
|---|---|---|
| 単純な修正 (Haiku) | 2K〜5K | 1〜2 分 |
| 標準的な機能 (Sonnet) | 10K〜20K | 5〜10 分 |
| 複雑なリファクタ (Sonnet + 拡張思考) | 30K〜50K | 15〜25 分 |
| アーキテクチャレビュー (Opus) | 50K〜100K | 20〜40 分 |
これを 1 営業日の作業に掛け合わせれば、エンジニア 1 人あたり 〜$6/日 はそこから出てきます。年間で掛け合わせれば、最適化の議論は本格化します。
レバー 1 — プロンプトキャッシュ (安定プレフィックスで 〜90%)
Claude Code は、すべての会話の安定プレフィックス、つまりシステムプロンプト、組み込みツール定義、スキルメタデータ、ルートの CLAUDE.md を自動的にキャッシュします。キャッシュ読み取りはベース価格の 0.1 倍で、キャッシュ部分について 90% の削減になります。
安定プレフィックスは、ほとんどのセットアップで 50K トークン以上です。キャッシュなしでは、すべてのターンでこの 50K トークンが再課金されます。キャッシュありでは、最初以降のすべてのターンが 10% のコストでそれらを読み込みます。
実用的な 2 つのルール:
- 静的なものを先、動的なものを後にする。 キャッシュヒットには厳密なプレフィックスの一致が必要です。会話の冒頭に動的なものがあると、キャッシュが壊れて完全な再読み込みが強制されます。私たちはルートの
CLAUDE.mdとスキルメタデータを最初に置き、動的コンテキスト (変更されたファイル、現在のブランチ状態) を最後に置きます。 - セッションごとに変わるものでプレフィックスを汚さない。 これが
CLAUDE.mdを絞っておくべき本当の理由です。削った 1 バイトはファイル変更時に再キャッシュ不要な 1 バイトであり、短いキャッシュプレフィックスは期限切れ時の再生成も安価です。
キャッシュは単一で最大のコストレバーであり、ほとんど自動的です。仕事は「これを壊さない」ことに集約されます。
レバー 2 — モデルルーティング (ルーティング部分で 3 倍)
Haiku 4.5 はトークンあたり Sonnet の 3 分の 1 のコストです。読み取り専用や検証タスクでの能力差は最小限です。Anthropic は ルーチンタスクの約 80% で Haiku をデフォルトにすることを推奨しています。
実際には次のようにルーティングしています。
| タスク | モデル | 理由 |
|---|---|---|
| コード探索 (「X が呼ばれる場所を全部探す」) | Haiku (サブエージェント) | 読み取り専用、決定的 |
| テスト失敗のトリアージ | Haiku (サブエージェント) | パターンマッチング、判断量が少ない |
| 標準的な機能実装 | Sonnet (メイン) | 生産的な作業のデフォルト |
| アーキテクチャ判断、スキーマ設計 | Opus (メイン、まれに) | 難しい推論にはプレミアムの価値あり |
| コードレビューパス | Haiku (フォークサブエージェント) | 読み取り重視、サマリーを返す |
ルーティングはサブエージェントと組み合わせると最大の威力を発揮します。サブエージェントはメインセッションとは独立した独自のモデル設定を持つためです。メインの会話を Sonnet で動かしつつ、フォークサブエージェントが Haiku で読み取り重視の作業を行えます。モデルルーティングは会話境界ではなく、スキル境界で発生します。
レバー 3 — サブエージェント分離 (メインコンテキストを 〜37% 削減)
サブエージェント (フォークエージェントとも呼ばれます) は独自の 200K トークンのコンテキストウィンドウを持ちます。サブエージェント内で行われた作業はメインの会話を汚しません。サマリーだけが返されます。
Anthropic は、内部作業 10,000 トークン以上から 〜500〜1,000 トークンを返すサブエージェントを文書化しており、複雑なタスクではメインコンテキストを概ね 37% 削減します。
コスト面の効果は 2 つあります。
- 直接的なトークン節約。 30 ファイルを読んで結論を返すコードレビューは、そのトークンを分離環境内で消費します。分離なしでは、その 30 件のファイル読み込みがメインコンテキストに残り、以降のターンごとに再課金されます (キャッシュの効果を除く)。
- 品質ドリブンのトークン節約。 長いコンテキストは検索品質を低下させます。研究によれば、コンテキストが満たされるにつれて性能は 15〜47% 低下することが文書化されており、これは「lost in the middle」問題です。品質が下がると、リトライ、再読み込み、無駄なトークンが増えます。メインコンテキストを清潔に保つことで、こうした浪費全般を防げます。
トレードオフは現実です。エージェントチームは、各エージェントが独自のセットアップオーバーヘッドを持つ新しいインスタンスを生成するため、標準セッションの 約 7 倍のトークンを消費します。私たちはこれを受け入れます。なぜなら、最適化対象は総トークン数ではなく、メインコンテキストの清潔さと全体スループットだからです。さらに、Haiku のサブエージェントはどのみち安価です。
レバー 4 — MCP ツール遅延 (〜85%)
これは MCP Tool Search に関する記事で詳しく扱いました。要約は次のとおりです。
24 個の MCP コネクタを遅延なしで読み込むと、セッションあたり概ね 135,000 トークンのベースラインオーバーヘッドを消費していました。Tool Search はこれをインデックスの 〜3,000 トークンまで下げ、フルスキーマはオンデマンドで読み込まれます。85% 削減となり、精度は向上し、セッションが窮屈に感じることはなくなりました。
コスト面の効果: ベースラインオーバーヘッドの 1 トークンは、すべてのセッションでキャッシュプレフィックスに含まれる 1 トークンです。13 万トークンのオーバーヘッドを削減することは、概ね 13 万 × トークン単価の 0.1 倍 × 全セッション分のキャッシュ読み取りを削減することに相当します。10% のコストでも、実働エンジニア 1 人あたり月数百ドルになります。
複合する乗数
ここからがヘッドラインの数字には現れない部分です。4 つのレバーは加算ではなく乗算です。
たとえば 5 分のタスクで $0.30 を消費するベースラインセッションを想像してみてください。各レバーを順に適用します。
| レバー | 効果 | 累積コスト |
|---|---|---|
| ベースライン | — | $0.30 |
| プロンプトキャッシュ (安定プレフィックスで 90%) | 安定プレフィックスはセッショントークンの 〜70% | 〜$0.12 |
| モデルルーティング (Haiku 適用部分で 3 倍) | 作業の 〜50% が Haiku 適用可能 | 〜$0.07 |
| サブエージェント分離 (メインコンテキスト 37% 削減) | メインコンテキストが縮小し、再課金が減少 | 〜$0.05 |
| MCP ツール遅延 (ツールスキーマオーバーヘッドで 85%) | スキーマが既定で読み込まれない | 〜$0.04 |
各ステップは控えめです。組み合わせは劇的です。具体的なパーセンテージは重要ではありません。構造的な洞察は、トークンコストの最適化は請求の重なり合う部分に作用するため、乗算的に複合するということです。4 つを修正すれば、桁が変わります。
これが、出荷物を変えずに私たちの日次支出が 〜$6 から 〜$2〜3 に下がった理由です。同じコード、同じテスト、同じリリースケイデンス。違うデフォルト値だけです。
私たちが今お金を使っているもの
最適化後の典型的な Statnive エンジニアリングデー:
| 活動 | 概算コスト |
|---|---|
| 朝の PR コードレビュー (フォーク、Haiku) | 〜$0.20 |
| React ダッシュボードの標準機能 2 件 (Sonnet、キャッシュ利用) | 〜$0.80 |
リリースゲート 1 回 (statnive-release スキル) | 〜$0.30 |
| ドキュメント・ブログ記事のドラフト | 〜$0.40 |
| その他の探索や Q&A | 〜$0.50 |
| 合計 | 〜$2.20 |
チーム全体での月次 Anthropic 請求額は、レガシーな SaaS サブスクリプション 1 つ分よりはるかに小さく済んでいます。文脈として: その請求額は、実在のビジネスが利用する WordPress プラグインを出荷する手助けをする AI 協働者を支えており、リリースごとに 141 件のテストと 31 件のコンプライアンスチェックが走ります。
拡張思考 (Extended Thinking): キーワードをタスクに合わせる
価格面で知っておくべき細部が 1 つあります。Claude の拡張思考モードはキーワードによって予算がトリガーされます。
| キーワード | 思考予算 |
|---|---|
think | 5K〜10K トークン |
think hard | 20K〜50K トークン |
think harder | 50K〜100K トークン |
ultrathink | 100K〜128K トークン (最大) |
これらのトークンは入力としてカウントされます。タスクに合う最も安いものを使ってください。私たちはルーチン作業では思考修飾子なし、平凡でない設計判断には think hard、深い推論が真に必要なアーキテクチャ問題にだけ ultrathink を使います。タイポ修正に ultrathink を呼び出すのは、AI 開発の世界における「1 つのウェブページを読むために 50 タブの Chrome を開く」と同じです。
レバーと同じくらいセッション衛生が私たちを救った
直感に反する発見: 日次コストの最大の変動要因は、スキルやツール構成ではなく、セッションの長さでした。
コンテキストリセットなしの長時間自律セッションは、品質が漸進的に低下します。「lost in the middle」効果 — コンテキストが満たされるにつれて性能が 15〜47% 低下 — は、リトライ、再読み込み、無駄なトークンの増加に直結します。コンテキスト 80% を超えて走ったセッションは、同じ作業に対して短いセッションの 2〜3 倍のコストがかかることが日常茶飯事でした。
働き方に焼き付けた 2 つの衛生ルール:
- 無関係なタスク間で
/clearする。 フロントエンドのバグからリリースゲートの変更へ移るのは、2 つの異なる会話です。コンテキストをクリアすることはコストゼロで、汚染を防ぎます。 - コンテキスト 60〜70% で先回りして
/compactを実行し、自動コンパクトの 95% 閾値で行わない。 上限に達してからの自動コンパクトは情報を失うパニック操作です。先回りのコンパクトは重要な状態を保持し、ノイズをリセットします。
会話履歴ではなくファイルへ状態を永続化することで、両ルールが安全になります。重要なものはディスクに置かれているので、クリアしても失われません。
私たちが最適化しなかったもの
- スキル単位のコストはまだ計測していません。 Anthropic 請求から日次合計を見ることはできますし、ローカルの
/costと/statsコマンドでスポットチェックも行いますが、スキル単位のアトリビューションはありません。ccusage(Claude のローカル JSONL セッションファイルを読みます) や Claude-Code-Usage-Monitor のようなツールはありますが、まだ統合していません。 - 私たちのサブエージェント比率はおそらく低すぎます。 レビューや監査ではフォークモードを積極的に使いますが、標準作業の意味のある割合がメインコンテキストを清潔に保つためにフォーク可能でしょう。厳密には測定していません。
- 正式な A/B 比較は実施していません。 $6 → $2〜3 という数値は、最適化が安定する前後での支出を比較したものです。背後に対照実験はありません。みなさんの結果は異なります。
さらに半分にするには何が必要か
正直な答え: おそらくやる価値のあるものはありません。
Haiku をさらに押し進めることはできます。サブエージェントへ作業をさらにバッチ処理することはできます。スキルへより積極的な出力予算契約を書き込むこともできます。それぞれ 10〜20% さらに削れるかもしれません。
エンジニアを 1 人増員する費用は、当社の Anthropic 支出全体の何倍にもなります。ある時点を超えて AI コストの最適化にエンジニアの時間を費やすことは、実際の製品を出荷しない時間です。私たちはセッションが窮屈に感じる、または請求が驚かしいときに最適化します。それ以外は出荷します。
Statnive を試す
5 つのプラットフォームと 14 の研究から学んだベストプラクティスに基づき、コスト会計をテストカバレッジと同じくらい真剣に扱うチームが構築した、プライバシー重視の WordPress アナリティクス。WordPress.org から Statnive を無料インストール — データはサーバーに留まり、支出は単一の予算ラインに留まり、エンジニアリングのプラクティス全体がオープンソースです。