AI技術・実装 / 2026/8/8 / 約9分

AIエージェントを役割で使い分ける — 性能・コスト・用途の実測メモ

この記事について

複数のAIエージェントを1つのリポジトリ・1つの自動化基盤に同居させて運用している。長く「どれが賢いか」で選んでいたが、実測を取ったところ判断軸が間違っていた。**比較すべきは $/1M トークンでもベンチマークスコアでもなく、「同じ枠で何タスクが人間の介入なしに完了するか」**だった。

この記事は、その実効コストの観点で各エージェントを並べ直した作業メモ。数字はすべて自分の環境の実測で、一般的なベンチマークではない。

試した環境

項目	内容
母艦	MacBook Pro（対話セッション）
自動化サーバ	Mac mini M1（常時稼働・launchd で約47レーン）
計測期間	2026-08-01 〜 08-08
集計方法	各CLIが元から書いているセッションログを後追い集計（`~/.claude/projects` / `~/.codex/sessions`）
実行台帳	`~/.local/state/ntmedia/agent_runs.jsonl`（レーン名・エンジン・成否・所要時間）

まず、どこが食っていたか

週間の Claude 課金対象トークン

機体	トークン	比率
自動化サーバ（無人ループ）	118,693,018	65.5%
母艦（人間との対話）	62,362,218	34.5%

体感では「無人ループが4割くらい」だったが、実測では約3分の2。人間が対話で使う分より、誰も見ていない時間に動いているループのほうが倍近く食っていた。

同じ期間、同じサーバ上でのベンダー別内訳はこうなる。

ベンダー	トークン	比率
Claude	118,693,018	71.2%
Codex	48,031,622	28.8%

画像生成などの定型工程はすでに別ベンダーに逃がしてあり、残っていたのは「判断」を含む工程（起稿・レビュー・監査）だけが単一ベンダーに寄っている状態だった。ここが今回の組み替え対象になる。

実測：成功率と所要時間

実行台帳から、同一の自動化レーン群での成否を拾ったもの（2026-07-31 〜 08-08）。

エンジン	実行数	成功	成功率	所要時間（中央値）	最長
Claude 系	144	137	95%	472秒	1,822秒
Codex 系	9	6	67%	180秒	418秒

数字だけ見ると成功率で負けているが、この比較はそのまま読んではいけない。

Codex の失敗3回はすべて No prompt provided via stdin で終わっていた。プロンプトが1バイトも渡っていなかった配線バグ（nullglob 環境で CLI オプションの値が glob 消滅し、直後のプロンプト全文を設定値として食う）。修正後に走った1件は成功している
Claude 側の失敗も品質ではない。状態ディレクトリがサンドボックスの書き込み許可範囲外で mkdir が弾かれ、エージェントが人間に選択肢を尋ねて終了していた（終了コードは0だが成果物ゼロ）

両ベンダーとも、観測された失敗の主因は環境と配線であってモデルではなかった。速度差（中央値で2.6倍）は素直に読んでよいが、成功率の差はまだ「測れていない」が正しい。

速度が効くのは「量をこなす工程」だけ

中央値180秒と472秒の差は、1日1本の記事では誤差だが、1日に何十本も回る監査・分類・下書き生成では効く。逆に、1回の判断ミスが公開事故になる工程では、300秒の短縮に価値はない。この線引きが用途の割り振りの軸になった。

用途別の割り振り（現在の配分）

工程	第一優先	フォールバック	理由
記事の起稿（機械検証できる媒体）	Codex / GPT-5.6 Luna	Claude Sonnet	失敗しても在庫が1本増えないだけ。ビルドと構文検証で機械判定できる
公開前レビュー（本流）	Claude Sonnet	Codex / Luna	空振りすると無人公開の根拠そのものが崩れる。データが揃うまで動かさない
公開前レビュー（1レーンだけ）	Codex / Luna（カナリア）	Claude Sonnet	データを取るために倒す。空振りしても次回に拾い直せる手戻り最小のレーン
画像生成	Antigravity / Gemini 画像モデル	—	5時間ごとのクォータ制。1期間15〜20枚が実効上限
要約・分類・URL検証	Gemini Flash 系 / ローカルLLM	Gemini Flash-Lite	判断を含まない前処理。ここに高いモデルを使う理由がない
対話・設計・障害対応	Claude（母艦）	—	文脈を長く持ち、途中で方針を変えられることに価値がある工程

キャラクターの掛け合いがある媒体の起稿はあえて対象外にした。プロンプトが特定モデル向けに作り込まれており、結果が悪かったときにモデル差なのかプロンプト適合度の差なのか切り分けられない。交絡が大きすぎる比較はやらない。

クォータの使い残しという観点

コストを「金額」だけで見ると見落とすものがある。定額枠で契約している場合、使い残した枠は消える。ある日の残量を見たときの実測がこれ。

契約	週次枠の残り
主力（対話・レビュー）	5%
副主力	53〜60%
画像・補助	62〜98%

片方が枯渇し、もう片方が半分以上余っている。これは金額の問題ではなく配分の問題で、モデルを変えなくても「どの契約に流すか」を変えるだけで総処理量が増える。

そしてこれは副次的な効果で、本命は別にある。単一ベンダー依存（SPOF）の解消だ。値上げ・障害・供給停止が全工程の停止に直結する構造をやめること自体に価値がある。トークン削減はその副産物として得ればよい。

組み合わせとして効いている形

現時点で最も手応えがあるのは、安価で速いモデルに「量」を、高価で文脈の長いモデルに「判断」を振る組み合わせ。

[量をこなす層]  下書き生成・分類・要約・整形
    ↓ 機械検証（ビルド / 構文チェック / リンク検証）で足切り
[判断する層]    公開前レビュー・事実確認・公開可否
    ↓
[人間]          不可逆な操作と、事業判断だけ

重要なのは間の機械検証で、ここが無いと安いモデルの出力がそのまま判断層に流れ込み、判断層のトークンを余計に食う。安いモデルの真価は「安いこと」ではなく「機械検証で足切りできる工程に置けること」にある。

導入時に踏んだ落とし穴（4件とも「無言で効かない」型）

配分を書き換えたつもりが、8日間1件も切り替わっていなかった。原因は4つあり、いずれも例外を投げずに静かに既定へ戻るタイプだった。

#	何が起きたか	対策
1	設定ファイル名が `.gitignore` の `.env` に一致し、git に乗らないので実機へ配送されなかった*	秘密情報を含まないので `!path/to/file.env` で例外指定し、明示的に git 管理下へ
2	参照側が `[ -f ... ] && . "$_"` で、ファイルが無いことを無言で握り潰していた	読み込みを1つのローダに集約し、欠落時は標準エラーに警告を出す
3	設定していた変数がどこからも読まれない死に変数だった	受け口を実際に配線し、疎通を1件のログで確認
4	1つの変数で2ベンダーにモデル名を配っていたため、片方のモデル名を入れるとフォールバック先が必ず失敗する状態だった	ベンダー別の変数に分離。想定外のプレフィックスが来たら渡さず警告

教訓は1行に畳める。「設定を書いた」と「実機で動いている」は別々に確認する。切り替えたつもりの構成は、実行ログに engine= と model= を1件見つけるまで、切り替わっていないものとして扱う。

効果の測り方

判定式はこれだけ。

実効コスト = 総トークン消費 ÷ 人間の介入なしに完了したタスク数

安いモデルでも2回叩けば高いモデルより高くつく。リトライ率と手戻りを織り込まない単価比較は無意味で、だから比較には最低でも2週間ぶんの実行台帳が要る。今回はカナリアを1レーンだけ立てて、それが溜まるまで本流は動かさないことにした。

「速いから」「安いから」で全面移行しないのは臆病だからではなく、移行後に悪化しても気づけない構成にしないため。切り戻せる範囲でしか倒さない、というだけの話でもある。

まとめ

無人ループが週間トークンの 65.5% を食っていた。体感（4割）より大きい
速度差は実測で 2.6倍（中央値180秒 vs 472秒）。ただし成功率の差は配線バグが原因で、モデル品質の差としてはまだ測れていない
割り振りの軸は「賢さ」ではなく 機械検証で足切りできる工程かどうか
定額枠は使い残すと消える。片方5%・片方60%残は、モデルを変えずに配分だけで改善できる
本命は節約ではなく 単一ベンダー依存の解消
切り替えは4つとも「無言で効かない」型で失敗した。実行ログで疎通を確認するまで切り替わっていないものとして扱う