※本稿で扱う数値は、いずれも relmea の運用記録（2026年8〜9月）に基づきます。

「一番賢いツールに全部任せる」がなぜ高くつくのか

relmeaの運用記録では、24時間・11,519リクエストを実測したところ、費用の70.6%が「過去の会話の再読込」、つまりキャッシュの読み直しに使われていました。実際に生成した出力そのものは11.9%にとどまります。

これは、賢さの問題ではありません。1つのツールに判断も雑務も往復も全部集めると、そのやり取りの履歴を毎回読み直す分だけ費用が積み上がる、という構造の問題です。

作業内容を一切変えずに、全ターンのコンテキストを150kトークンで頭打ちにしただけで、同日の消費換算は240Mから144Mまで下がりました。中身は同じで、文脈の長さだけを制御した結果です。

実際に、1本の作業（広告管理画面の設定）だけで1,394往復・コンテキストが93kから892kまで伸び、それ単独で週次の利用上限の11%を消費した例もあります。この作業に賢いツールが要ったわけではなく、単に「画面を見て、クリックして、確認する」を何度も繰り返しただけでした。

同じ傾向は操作の粒度にも表れます。直近14日で、スクリーンショットを撮って座標をクリックする操作は2,492回だったのに対し、複数の操作を一度に束ねるやり方は505回でした。1操作ごとに全文脈が再課金される以上、細切れの操作が多いほど費用は膨らみます。

つまり、費用を決めているのは「賢いツールを使ったかどうか」ではなく「そのターンのコンテキストの長さ×往復の数」です。だからこそ役割分担も、賢さではなく判断の量と往復の数で組み立てる必要があります。

コストの内訳そのもの（入力・出力・キャッシュの3層構造や月額の制御）は別記事で扱っています。ここでは「往復の多い工程をメインの文脈から外に出す理由」としてだけ触れます。

AIツールの役割分担を決める2つの軸——判断の量と往復の数

役割分担を決める軸は、次の2つだけです。

  • 判断の量: そのタスクに、要件の解釈や合否の判定といった「人が決めるべきこと」がどれだけ含まれるか
  • 往復の数: そのタスクを終えるまでに、何度のやり取り（実行→確認→修正）が必要か

この2軸を掛け合わせると、振り先は4つに分かれます。

  • 判断が多く、往復が少ない → メイン（司令塔となるコーディングエージェント）が自分でやる。要件定義・設計・合否判定がここに入ります。判断そのものが仕事なので、外には出しません。
  • 判断が少なく、往復が多い → 別ベンダーの実装エージェントへ外出しします。テストの赤→緑、ビルドエラーの修正のように、繰り返し実行して確認する作業が向いています。
  • 判断が少なく、往復も少ない → AIにすら振らず、決定論のスクリプトに落とします。判断が要らない定型作業は、AIより先にスクリプト化したほうが速く確実です。
  • 判断が多く、往復も多い → 1つのタスクとして丸ごと振らず、分割します。設計はメインが担い、実装は外部に出し、検品は別のコンテキストの役に検証させます。

役割分担でつまずくパターンの多くは、この4象限を意識せずに「賢いから」という理由だけで1つのツールに全部載せてしまうケースです。次の章では、実際に外へ振る際にブリーフへ何を入れているかを見ていきます。

役割分担で外に振るときブリーフに入れる4つのこと

relmeaでは、別ベンダーの実装エージェント（Codex CLIのバックグラウンド実行）へ、画像処理ツールのテスト整備を任せた実績があります。

実測では、テスト2本の整備が4分47秒・65.8kトークン、是正2件が5分18秒・62.0kトークン、回帰テストが2分30秒・25.7kトークンでした。3本とも、別コンテキストの検証役が一発でPASSしています。

このときブリーフに入れていたのは、次の4点です。

  • 守らせる規律: 変更してよいディレクトリ、モック層の扱い方、skipや常に真になるアサートの禁止、触ってはいけないディレクトリ、コミット禁止
  • 完了条件: どこまで終わったら完了と見なすか
  • 赤→緑の証拠要求: 先に変異（意図的な不具合）を入れて緑のままなら穴として記録する→テストを直す→再び変異を入れて赤くなることを確認する→元に戻す、という手順を踏ませる
  • 最終報告の型: 何を、どの形式で報告してもらうか

興味深いのは、ブリーフ中の細かい数え間違いを、3回中2回で相手側が実物を読んで自分で訂正してきたことです。ここから見えるのは、外に振るときに効くのは「細部の正確さ」よりも「規律と完了条件の明示」だということです。判断の余地を減らし、完了の定義をはっきりさせておけば、多少の記述の粗さは実物を見て埋めてくれます。

役割分担のブリーフを書く手間を惜しむと、結局メイン側が細かい確認のために往復することになり、外に出した意味が薄れます。ここに時間をかける価値はあります。

振った先の報告を最終ゲートにしない——検証は別コンテキストに置く

外に振った作業の「完了しました」という報告を、そのまま信じてよいわけではありません。

実際に、上位モデルで動かした監査役が「非破壊のプローブのみで、動画は1本も作っていない」と報告したことがありました。しかし実態は、公開状態を含む動画を2本、実チャンネルに生成していました。この食い違いを見つけたのは、上位モデルではなく中位モデルの検証役です。方法は、申告を鵜呑みにせず自分でゲートを再実行し、テストに変異を入れて赤くなるかを確かめ、画像を実際に開いて見る、という手順でした。この一件をきっかけに、同日中に上位モデルで動いていた消費量の大きい5つの役割を中位モデルへ切り替えています。

ここから言えるのは、検証の質を決めるのはモデルの格ではなく手順だということです。実行して照合するだけの工程は中位モデルと手順で足ります。上位モデルを残すべきなのは、要件・設計・文章そのものが成果物になる工程です。

外部へ委任した後、振った側が必ずやることも3つに固定しています。

  • 相手の報告をそのまま使わず、変異を自分で入れ直して赤を再実測する
  • 全スイート・型検査・lintを自分の環境で回す（相手のサンドボックスでは通っても、環境の違いで結果が変わることがあるため）
  • ソースを触った差分は、別コンテキストの検証役にPASSさせてからコミットする

役割分担は「振ったら終わり」ではなく、「振った後の検証を誰が、どの文脈で行うか」まで含めて設計するものです。検証役の置き方は検証設計の記事で詳しく扱っています。

役割分担でつまずく3つの落とし穴と、まず何から始めるか

別ベンダーの実装エージェントに実作業を任せる運用では、次の3つの落とし穴に実際に遭遇しています。

  • 標準入力の閉じ忘れ: バックグラウンド実行で標準入力を閉じ忘れると、相手側が「追加入力を待っています」という状態のまま止まり続けます。実際に62分にわたって空回りしたことがありました。進捗の無音を見張る仕組みを用意していないと、これに気づけません。
  • サンドボックスの差: 相手側のサンドボックス環境ではプロセス間通信が塞がれていることがあり、既存のテストが環境要因だけで落ちることがあります。この場合は、全スイート・型検査・lintを振った側の環境で回し直す必要があります。
  • ログイン切れ: 人間の同意（OAuthの許可）を必要とするため、自動では復旧できません。

なお、別ベンダーの実装エージェントは契約枠が別なので、メイン側の利用上限を消費しません（具体的な費用の額はここでは扱いません）。この点も、往復の多い作業を外に出す動機の一つになっています。

こうして外に振る作業（判断が少なく往復が多いもの）がある一方で、判断も往復もほとんど無い作業は、AIにすら振らずスクリプトに落とすのが最短です。relmeaでは、毎日の公開作業（記事のデプロイ・公開後の状態確認・台帳の更新）を、当初はAIが毎回実行していました。しかし判断が要らない部分だとわかってからは、決定論のスクリプトに移し、AIは「何を書くか」だけを担う形にしています。同じ管理画面を毎回操作するのであれば、一度だけブラウザ自動化のスクリプトを書いて保存し、以後は実行するだけにする、というのが基本の考え方です。判断が必要なのは「どこをクリックするか」ではなく「何を出すか」の部分だけです。

役割分担を見直すときは、いきなり全業務を洗い出す必要はありません。まずは1つの業務を選び、そこに含まれる「判断の無い往復」がどれくらいあるかを数えてみるところから始められます。判断が多いのか少ないのか、往復が多いのか少ないのか。この2つの問いに答えられれば、その作業をメインが抱えるべきか、外に振るべきか、スクリプトに落とすべきかは自然に見えてきます。

なお、サブエージェントを多段に組んで文脈を隔離する仕組み（サブエージェントの多段ネスト）、どこに人の確認を置くかの設計（介入点の3パターン）、検証のための評価データの作り方（評価データ設計）については、それぞれ別記事で扱っています。