AIエージェントが途中で止まる理由を、モデルのせいだけにしない
AIエージェントに調査、文書作成、社内システムの操作まで任せると、最初はうまく動いても長い仕事の途中で品質が落ちることがあります。会話履歴が膨らみ、古い前提が要約で置き換わり、ツールの実行結果が積み重なるからです。
この問題を「もっと賢いモデルに変える」とだけ考えると、原因が見えなくなります。長時間稼働を安定させるには、次の三つを別の機能として設計することが重要です。
- コンテキスト圧縮: 何を次の推論に残すかを決める
- キャッシュ: 変わらない入力を再利用する
- 承認: 外部への作用を人間が確認できるようにする
この三つは似ていますが、目的が違います。圧縮は履歴の量を減らす処理、キャッシュは同じ入力の再計算を減らす処理、承認は操作の権限境界です。
1. 圧縮は「短くする」より「捨ててはいけないものを決める」
長い会話を一つの要約に置き換えると、読みやすくはなります。しかし、要約には必ず情報の欠落があります。依頼の例外条件、すでに実行した操作、ユーザーの拒否、失敗した試行が消えると、エージェントは同じ操作を繰り返したり、承認済みでない作業を進めたりします。
実装では、履歴を次の三層に分けると扱いやすくなります。
- 原文ログ: 受信した指示、ツール引数、結果、承認、エラーを改変せず保存する
- 作業状態: 現在の目的、未完了タスク、決定事項、禁止事項、次の一手を構造化する
- 作業要約: 次の推論に渡す短い説明。原文ログの代わりではなく、参照先を持つ索引として扱う
圧縮のトリガーも固定値として盲目的に採用しない方がよいでしょう。履歴の何割で圧縮するかは、モデル、ツール定義、入力の長さ、処理内容で変わります。まず仮説を置き、圧縮前後の品質、再実行率、入力トークン、遅延を比較します。
2. キャッシュは圧縮の代用品ではない
同じシステム指示やツール定義を毎回送り直す処理では、入力キャッシュによって再計算を減らせる場合があります。Googleの公式ドキュメントでも、共通の接頭辞を保つことや、明示的なキャッシュを使うことが説明されています。
ただし、履歴を圧縮すると接頭辞が変わり、キャッシュが使われなくなる可能性があります。したがって、次のような配置が現実的です。
- 先頭: ほぼ変わらないルール、権限、ツールの基本定義
- 中央: プロジェクトの正本や参照資料
- 末尾: 現在の依頼、最新のツール結果、時刻や状態
さらに、キャッシュヒットを期待するだけでは不十分です。リクエストごとに、入力トークン、キャッシュされたトークン、圧縮回数、推論時間、推定コストを記録します。「圧縮したから安くなった」「同じ指示だから再利用された」と推測せず、実測値で判断するためです。
3. ツール実行は、会話ではなく状態機械にする
ツール呼び出しをチャットの一往復としてだけ実装すると、通信切断やタイムアウト時に状態が分からなくなります。少なくとも、次の状態を永続化します。
planned → awaiting_approval → running → succeeded
失敗時は failed、期限超過時は timed_out とし、再試行できるかを別に判定します。再試行しても安全な処理には冪等性キーを付け、二重登録や二重送信を防ぎます。外部システムの状態が不明なまま、単純に同じ操作をもう一度送る設計は避けます。
この状態は、エージェントの文章ではなく実行基盤が管理します。モデルに「完了しました」と言わせても、サーバー側で成功応答を確認できなければ完了にはしません。
4. 承認画面の説明文をモデルに任せない
人間の承認が必要な操作では、承認画面に「何が起きるか」を明確に表示します。ここで危険なのは、表示文そのものをモデルに自由生成させることです。ツール引数に悪意ある文字列が混ざったり、外部文書の指示が注入されたりすると、危険な操作が無害に見える説明へ変わる可能性があります。
承認プレビューは、少なくとも次のデータから決定的に生成します。
- ツール名とバージョン
- 実行対象の識別子
- 変更・送信・削除される項目
- 影響範囲と取り消し可能性
- 実行者、許可された権限、期限
- サーバー側で検証済みの引数
モデルは「この操作を提案する」役割にとどめ、最終的な危険度、表示文、許可・拒否の条件はサーバー側のルールで決めます。MCPの仕様でも、利用者がツール呼び出しを拒否できること、公開ツールや確認プロンプトを明確にすることが示されています。
5. ツール定義にも予算を置く
ツールが増えるほど、ツール名、説明、入力スキーマもコンテキストを消費します。すべての詳細仕様を常に渡すと、重要な業務ルールが埋もれ、キャッシュの共通部分も不安定になります。
最初は、利用頻度と危険度でツールを分類します。
- 常時公開: 読み取り専用で頻繁に使うもの
- 条件付き公開: 特定の業務やプロジェクトで必要なもの
- 明示許可: 外部送信、削除、決済、権限変更など影響が大きいもの
- 詳細取得: 概要だけを提示し、必要時にスキーマを取得するもの
ツール一覧の順序や基本定義を安定させることも、モデルへの入力を再利用しやすくするために役立ちます。ただし、キャッシュの挙動はプロバイダーや設定に依存するため、必ず利用量を確認してください。
6. まず7日間だけ、品質と費用を測る
大規模な基盤を先に作る必要はありません。小さな業務を一つ選び、次の項目を記録します。
- 1タスクの総時間と人間の待ち時間
- 入力トークン、キャッシュ済みトークン、出力トークン
- 圧縮の回数と、圧縮後の再確認回数
- ツール呼び出し数、承認・拒否数、失敗・再試行数
- 完了率、二重実行、手戻り、重大な誤操作
- 1タスクあたりの推定コスト
1日目から2日目は原文ログと状態機械だけを整え、3日目から4日目に圧縮とキャッシュを比較します。5日目に承認プレビューを実装し、6日目に失敗・タイムアウト・再試行を意図的に起こします。7日目に、速度ではなく「人間が安心して任せられる範囲」が広がったかを判定します。
まとめ
長時間動くAIエージェントの品質は、モデルの選択だけで決まりません。原文ログと作業状態を分け、圧縮とキャッシュを別々に測り、ツール実行を状態機械として管理し、承認プレビューを実引数から決定的に作る。この順序が、途中停止や誤操作の原因を追える基礎になります。
新しいモデルを試す前に、どこまでを自動化し、どこで止め、何を証跡として残すかを決めておく。AIエージェントを業務へ組み込むときに、最初に整えるべきなのはモデルの宣伝文句ではなく、実行基盤の境界です。
本稿は実装上の判断軸を整理したもので、特定プロバイダーの性能、料金、キャッシュヒット率を保証するものではありません。提供条件や仕様は変わるため、導入時には利用中の公式ドキュメントと実測値を確認してください。