AIエージェント協働の運用（セッション計測・モデル配分・レビュー・報告・記録）

複数の AI エージェントに同じ最高性能モデルと最大 effort を一律指定しない。計算資源は、各役割が持つ判断のレバレッジと失敗時の手戻りコストで配分する。

要件解釈、境界分割、結果統合、最終判断を担うリーダーには高性能モデルと高めの reasoning を置く。計画と変更範囲が明確な実装担当には、速度と費用のバランスがよいモデルを中程度の reasoning で置く。レビューは呼び出し回数が少なく欠陥検出の価値が高いため、実装系統と異なる強いモデルを高めの reasoning で one-shot 実行する。単純な探索、ログ要約、機械的確認だけを安価なモデルへ落とす。

明示的なリーダーと担当境界を持つチームの上に、別の自動マルチエージェント・オーケストレーターを常用で重ねない。分割の二重化、入れ子の委譲、責任境界の曖昧化、トークン増加を招くためである。深い自動委譲は、既存の編成外で独立作業へきれいに分割でき、品質または所要時間の改善を測れる場合だけ選択的に使う。

モデル更新時は名前だけ置換せず、代表タスクで現行 effort と一段低い effort を比較する。タスク成功率、レビューラウンド、差し戻し、総トークン、待ち時間、費用を記録し、最高設定ではなく手戻り込みの総コストが最小になる配分を採用する。

AI エージェントとの長時間セッションが「遅かった」と感じたとき、体感で原因（レビューが長い、生成が遅い等）を決めつけず、セッションログのイベントタイムスタンプから時間内訳を実測してから対策を選ぶ。コーディングエージェントのセッションログは各イベント（ユーザー入力、アシスタント応答、ツール開始・終了、ターン所要時間の記録、離席時サマリ、入力キューの enqueue/dequeue）にタイムスタンプを持つため、連続イベント間のギャップを「直前のイベント種別＝何を待っていたか」で分類集計できる。

手順

• ツール呼び出しはツール開始イベントと対応する結果イベントを id で突き合わせ、実行時間を出す。
• それ以外のギャップは直前イベントで分類する: アシスタント最終応答→次のユーザー入力はユーザー応答待ち、ユーザー入力・ツール結果→アシスタント応答はモデル生成時間、委譲エージェントからの報告待ちは委譲待ち。
• ログにターン所要時間の記録イベントがあれば、それがアシスタント実働時間の正解値になり、ギャップ分類の検算に使える。

落とし穴

• 壁時計時間にはユーザーの離席が丸ごと含まれる。実測すると壁時計の大半（今回の実測では約8割）がユーザー応答待ちで、実働の内訳と壁時計の内訳はまったく別物になる。改善対象を選ぶ前にまず両者を分離する。
• 一律間隔で並ぶギャップ（数分刻みの同一イベント種別の連続など)は、ハーネスの周期処理（離席サマリ生成等）であることがある。ギャップを分類へ算入する前にイベントの中身を確認し、待ち時間と周期処理を混同しない。
• ツール実行時間の合計は体感より圧倒的に小さいことが多く（今回の実測では7時間半のセッションで約3分）、遅さの主因は生成時間・委譲待ち・人間の応答待ちのいずれかに出やすい。

検証

分類済みカテゴリの合計が壁時計時間とほぼ一致すること、ターン所要時間の記録値と「生成時間＋ツール実行」の推定が近いことを確認する。ずれが大きければ分類ルール（どのイベント種別をどの待ちに割り当てたか）を見直す。

LLM による diff レビューを「指摘ゼロまで反復」する運用では、総時間を決めるのは1巡の単価より巡回数になりやすい。レビューは非決定的で、2巡目に1巡目より多い新規指摘が出る（単調収束しない）ことがあり、実測では指摘件数が 3→4→1→0 と推移して4巡を要した。

判断基準

レビュー起動時の重点観点に、実装中に仕様・設計が揺れた箇所（計画への追補として記録された実装中の仕様変更、手戻りが起きた箇所、環境差で実装を差し替えた箇所）を必ず含める。思いついた観点を任意で渡すのではなく、追補の存在を機械的なトリガーにする。

なぜ

実装中に設計が揺れた箇所は、計画時の検討が浅かったことが証明されている場所で、後の巡で新規指摘が湧く出どころになりやすい。実測でも2巡目の新規指摘は実装中に仕様変更した領域（流量制御の上限周り）から出た。1巡目で拾えればフルサイクル1巡分（レビュー実行＋差し戻し＋修正＋再テストで数十分規模）が浮く。

適用条件・限界

• 前提として、実装中の仕様変更を計画側に追補として記録する運用があること（記録がなければトリガーにできない）。
• レビューの非決定性自体は消せないので、巡回数ゼロ保証ではなく期待値の削減策として扱う。終了条件（指摘ゼロまで回す等）は別のレバーとして独立に設計する。

検証

レビューラウンドごとの指摘件数の推移を記録し、2巡目以降の新規指摘が「追補・揺れ箇所由来か」を分類する。揺れ箇所由来の後巡指摘が減り、平均巡回数が下がれば効いている。

AI エージェントに作業完了時の振り返り（手順からの逸脱・摩擦の記録）を自己申告させると、記録される内容が構造的に偏る。これは「チェックを忘れる」想起の問題とは別の失敗モードで、チェック自体は実行されても選別が偏る。

偏りの構造

• エラーが出た・問い合わせが来た・再起動したといった明示的な失敗は記録される。
• 一方、手順どおり進めたのに防げなかった問題（計画の穴を実装中の手戻りで吸収して完了したケースなど）は、AI には「逸脱なく完了」と見えるため記録から落ちる。改善の入力として最も価値が高いのは後者（手順自体の欠陥の証拠）なのに、自己申告はそれを構造的に拾えない。
• 実際の運用でも、同一セッションが明示的失敗2件（エラー応答・再委譲）は記録した一方、最大のロスだった手戻り（計画のチェック観点の穴由来・既存記録と同型の再発）を落とし、件数トリガー式の改善ループが発火しなかった。

判断基準（代替設計）

記録の入力源を自己申告以外に置き換える:

• 機械的照合: 作業中に別目的で残した既存の記録（計画への追補、実測サマリの逸脱欄など）を振り返り時に走査する。記憶ではなく直前に自分が書いた成果物の転記に限定する。
• 人間の主観トリガー＋実測分析: 「時間がかかった・回り方が悪かった」の判定は人間が行い、発火後の原因特定はセッションログのタイムスタンプ実測に任せる。吸収された手戻りは自己申告には見えなくても、ログ上の revert→再実装パターンや時間ギャップとして必ず残る。
• 定期実行や常時自動分析にはしない。「遅さ」の価値判断は人間にしかできず、全セッション分析はコストに見合わない。

検証

自己申告で書かれた記録と、同じセッションの実測分析が拾ったロスを突き合わせ、自己申告に落ちていた項目の型（吸収された手戻りか、明示的失敗か）を分類する。落ちが「同型再発の検知漏れ」を含む場合は、件数・同型トリガーの判定が機能していないサイン。

AI エージェントのセッションが「体感で遅い」とき、往復の多さや委譲待ちなどワークフロー側を疑いがちだが、リーダー自身のテキスト生成が支配的なことがある。対策を選ぶ前に、セッションログ（イベントごとの timestamp と token usage が残る形式）から遅さの帰属を実測する。

手順

1. ツール呼び出しと結果イベントを id で突合してツール実行時間を出す。
2. 残りのイベント間ギャップを「直前のイベント種別＝何を待っていたか」で分類する: ユーザー応答待ち／委譲・バックグラウンド実行待ち／モデル生成。委譲先が動いている間の待ちをユーザー待ちと混同しないよう、バックグラウンドタスクの起動〜完了通知の区間と突き合わせる。
3. アシスタントメッセージの output_tokens を合計し、直前イベントからメッセージ完了までの経過時間で割って実効生成速度（tok/s）の中央値を出す。

切り分けの判断基準

• 「出力トークン合計 ÷ 実測 tok/s」がセッション実働時間に迫るなら生成起因。対策は出力量の削減（報告様式の規定・中間報告の差分化）か生成の速いモデルで、ワークフロー組み替えでは直らない。
• コンテキスト肥大が容疑のときは、キャッシュ読み取りのヒット状況とコンテキストサイズ推移×速度の相関を見る。キャッシュがヒットし続けていればコンテキストが数倍に育っても速度は落ちず、無罪と確定できる。
• ツール実行時間が小さい（合計数分・最長数十秒）なら環境側の最適化は後回しでよい。

実測例（一般化）

壁時計136分のセッションで、リーダー出力238kトークン×中央値45tok/s ≒ 約88分が純粋な生成時間だった。内訳では中間報告・完了報告・記録転記が3〜4割を占め、報告様式の規定だけでレビュー品質に触れずに削減できると判断できた。体感では委譲待ちが犯人に見えていたため、実測しなければ対策を誤っていた。

検証

対策導入後のセッションで同じ集計を再実行し、生成時間の比率と実働時間が下がったかを比較する。

リーダーが実装をエージェントに委譲しレビューを裁くマルチエージェント運用では、リーダーの生成量のかなりの部分が中間報告・帳簿づけ（状況まとめ・完了報告・記録転記）に費やされる。実測ではリーダー出力の3〜4割が報告系で、これがセッションの体感速度を直接悪化させていた。判断に使われない詳細を報告から外し、置き場を移す運用ルールで、品質に触れずに高速化できる。

運用ルール

• 中間報告は差分のみ: 直前の報告から変わった事実だけを数行で書き、既報や全体状況の描き直しをしない。状態が変わらない通知（委譲先の待機通知・バックグラウンド処理の生存確認）への応答は1行。
• 指摘の本文は差し戻し指示にだけ書く: ユーザー向け報告には件数・重大度・処理先（差し戻し／直修正／棄却）のみ。同じ指摘を報告と差し戻しの両方に書く二重生成をやめる。
• 最終報告は要点のみで分量上限を決める: 変更一覧はコミット1件につき1行、検証結果は合否と件数、レビューは収束経過を1行（例: R1 must4 → R2 must2 → R3 ゼロ）。詳細は計画ドキュメントの完了記載・コミット・差し戻し指示に残す。

なぜこのレバーか（却下した代替案）

• 報告量の削減はレビューの検出力・設計品質に一切影響せず、どのモデルでも効く。
• 却下した代替案: オーケストレーション局面だけリーダーを軽量高速モデルに切り替え、代わりに文脈を持たない重モデルの検証エージェントを追加する構成。リーダー検証の検出力は会話文脈（設計議論の経緯を知っているから異常を診断できる）に依存しており、文脈なしの検証役への移管は守りたい品質を最も危険に晒す。さらに手動のモデル切り替えは忘れたときにサイレントに壊れ、指摘の裁定プロトコルなど層が増えて維持コストが上がる。「速いリーダー＋賢い検証役」より「賢いリーダーを寡黙にする」を選ぶ。

落とし穴

• 詳細の置き場（計画ドキュメント・コミットメッセージ・差し戻し指示）をセットで決めずに報告だけ削ると、情報がどこにも残らない。先に置き場を規定してから報告を絞る。
• 状態が変わったときの短報まで省くと進捗の可視性が失われる。削るのは再掲と二重記載であって、変化の通知ではない。

検証

導入前後のセッションログで、出力トークンに占める報告系の比率と実働時間を比較する。

AI に投稿ネタ・素材・候補を作業のそばで継続採取させる仕組みでは、「固有名詞・数字が N 個以上」のような証拠量ベースの採取基準は失敗しやすい。証拠基準は具体性を測るが、受け手にとっての価値（読みたい・使いたい）を測らないため、バージョン同期や設定変更のような作業日誌が素通しし、台帳が「採取100%・活用0%」で渋滞する。

判断基準: 消費形式を先に書かせる

採取時に、最終的な消費形式（投稿なら読者向けの仮タイトル）を先に書くことを必須にし、「自然に書けるか」自体を判定器にする。補助ゲートの例:

• 文脈ゼロテスト: 書き手の内部事情（プライベートなツール名・手法名）を知らない読者が、タイトルだけで中身を想像でき開く理由があるか。内部固有名詞が主語で一般名詞に言い換えられないものは不可
• タイトルに入れる要素を型で限定する: 完成物（作った・公開した）／意外な数字／失敗と回復、のように受け手が反応する型を数種に絞り、どれも入らなければ捨てる
• 迷ったら捨てる・ノルマなし: 0件が正常な日と明示する。これが「AI が無理やりネタをひねり出す」問題への答えになる — 量の目標ではなくゲートで制御すれば、書けたものだけが残り、残ったものは定義上ネタになる

なぜ

採取と消費の間に形式変換（1行ログ→タイトル→本文）を挟むと、変換コストが後段に溜まり、後で見ても採取時の熱が再生されず活用されない。消費形式を採取時点で書かせれば、フィルタと下書きを同時に済ませられる。

検証

台帳の未使用滞留数と活用率を導入前後で比較する。滞留が減らないなら、ゲートでなく消費形式そのもの（短文投稿かブログか）が合っていない可能性を疑う。