- 公開日
トークン消費が急増したら、まず一回の処理量と実行回数のどちらが増えたかを調べます。入力資料が増えた一回の処理と、同じ操作を進捗なく繰り返す処理を分けるには、トークン量に加え、実際の要求回数、対象と引数、確認できた成果を結び付けます。異常の検知、次の実行の停止、すでに動いた処理の結果確認は別々に設計します。
ここでいうAgentは、モデルの応答を使って検索やツール操作を続ける仕組みです。この記事で異常な反復と呼ぶのは、業務上の終了条件へ近づかないまま、不要な要求を繰り返す状態です。トークン数が大きいという理由だけで、この状態を断定することはできません。
消費量の変化は、入力と回数に分けて見る
まず、同じ種類の仕事、入力規模、モデルと設定で比較します。短い質問の通常値と、資料十数件を読む仕事の量を比べると、必要な処理を異常と判定しかねません。モデルやツール定義を変更した日は、その変更も比較条件へ残します。比較できる記録が少ない場合は「通常から何倍」という値だけで判定せず、入力内容と実行履歴の確認を優先します。直近の一定時間の増加量と、タスク開始からの累積量も区別します。前者は急な変化、後者は上限への接近を見るためです。
入力量、出力量、要求回数を分けると、調査する場所を絞れます。過去の会話や同じ検索結果を毎回付け直すと、入力が段階的に増えます。要求が増えても新しい対象を調べていれば必要な作業かもしれません。反対に、小さな要求を何度も送る異常は、一回の大きさだけでは見落とします。
トークンはモデルが入力や出力を扱う単位です。OpenAIのCounting tokensでは、入力の計数にメッセージ構造やツール定義なども関わることを説明しています。人に見える本文の文字数だけで使用量を推定せず、実際に送った要求と提供者の使用量記録を対応させます。
また、同社のReasoning modelsで扱う推論トークンは、出力として課金されます。短い回答でも内部の生成量が多いことがあり、出力上限によって可視の回答が出ないまま終わる場合もあります。出力総数の内訳として示された推論量を総数へもう一度足すと、二重計上になります。これらの仕様説明は2026年10月12日から19日にかけて確認した範囲であり、実装時には採用するAPIとモデルの項目定義を確かめます。
一つの警告から、実行の記録をたどれるようにする
運用側では、タスクIDから個々のモデル要求とツール要求へたどれるようにします。少なくとも次の関係が分かれば、急増の原因を切り分けやすくなります。これは本稿の記録設計であり、特定製品の必須ログ形式ではありません。
| 記録のまとまり | 残す内容 | 切り分ける問い |
|---|---|---|
| タスクと要求 | タスクID、親子関係、要求ID、試行番号、開始・終了時刻 | 同じ仕事で実際に何回要求したか |
| 使用量 | 入力・出力、定義済みの内訳、確定か推定か | 一回が大きいのか、回数が多いのか |
| 操作と応答 | ツール、対象、入力版、引数の比較用識別子、応答状態 | 同じ条件の操作を繰り返したか |
| 進捗と停止 | 検証済みの成果件数、最後の更新時刻、終了・保留理由 | 何が解決し、何が残ったか |
引数の比較用識別子は、同じ条件かを判定できる形に整理した値です。ただし、空白や順序を機械的に消すと意味が変わる引数もあるため、業務ごとに同一性の定義を決めます。完全一致だけでなく、検索語を少し変えて同じ資料を取り続ける場合も調べます。識別子だけでは意味の同一性や異常を証明できません。
ログへ原文、顧客情報、認証情報を丸ごと保存する必要はありません。許可された資料の版や参照ID、件数、状態を優先し、必要時だけ権限を持つ担当者が対象記録を照合します。進捗は「順調です」というAgentの自己申告ではなく、根拠が確認できた項目や、検査を通った成果物で数えます。モデルの非公開の思考内容を取得しなくても、この照合は設計できます。
同じ使用量の通知が二度届く場合と、処理を実際に二度試す場合は、消費量への数え方が違います。同じ要求の使用量通知は重複計上を避け、新しい試行は別の消費として記録します。SDK側の再試行や子Agentの呼び出しが親の記録に出ないと、画面上の回数と実際の回数がずれます。使用量がまだ届かない要求はゼロにせず、未確定として残します。
架空ログで「大きい一回」と「進まない三回」を比較する
以下は実行していない説明用のログです。架空の調査Agentが公開資料の仕様項目を集めます。資料の版と確認対象を記録でき、更新や送信を行うツールは使わないとします。トークン数は入力と出力の合計で、推論量等の内訳を別に足しません。
通常の短い調査では、1タスクにつき2回、入力合計2,000、出力合計1,000、総計3,000トークンを使うという仮定の比較値を置きます。これは実測した基準値ではなく、すべての仕事へ適用する閾値でもありません。
| 観測対象 | 入力合計 | 出力合計 | モデル要求数 | 確認できた進捗 |
|---|---|---|---|---|
| 長い資料を渡したA | 18,000 | 2,000 | 1回 | 指定12項目の根拠が揃った |
| 同じ資料を探し続けるB | 12,000 | 1,500 | 3回 | 未確認の1項目が残り、新しい根拠は0件 |
Aは20,000トークンで比較値より大きいものの、追加した資料量で入力増加を説明でき、要求は一回で終了しています。担当者が12項目の出典を検査して受理基準を満たすなら、必要な長文処理として扱う候補です。大きいことを理由に「無駄」とも、進捗の数字だけで「正しい」とも決めません。
Bは13,500トークンでAより少ないものの、次の履歴があるとします。時刻は同じ日の同一時計による記録です。
| 完了時刻 | 入力／出力トークン | 資料取得の結果 | 検証済み進捗 |
|---|---|---|---|
| 10:00:00 | 2,000／400 | 資料X・第3版を取得。対象欄は記載なし | 追加0件 |
| 10:00:10 | 4,000／500 | 同じ対象・条件で同じ資料を取得 | 追加0件 |
| 10:00:20 | 6,000／600 | さらに同じ資料を取得 | 追加0件 |
この記録から分かるのは、入力が増え、同じ取得が三回続き、確認項目が解決していないことです。原因候補は、欠けた情報を検索で埋めようとし続ける終了条件の不足、ツール結果の受渡し不良、同じ結果を履歴に重ねる処理などです。対象欄が本当に資料にないのか、取得結果がAgentへ渡ったのかを照合して原因を絞ります。この記録だけで、悪意のある入力や特定のモデル不良が原因とは断定できません。
この例の暫定ルールを「60秒の観測窓で同じ版・同じ条件の読取りが三回成功し、新たに確認できた項目がゼロなら、次の要求を保留」とします。Bは三回目の完了後に該当します。Aは総量の警告対象になっても、反復による保留には該当しません。数値はこの例だけの設定であり、本番の標準値ではありません。
同じ照会を繰り返す必要がある処理もあります。別システムの完了を待つ状態確認なら、結果が変わらないだけで異常とは言えません。許可された待機理由、間隔、最大期限、期待する状態変化を持つ照会として区別します。資料の版が更新された場合も、同じ対象への再取得が正当なことがあります。
警告の後は、再試行の理由と予算の両方を確かめる
Bのツール応答は成功しているため、一時的な通信失敗への再試行としては説明できません。対象欄が資料に存在しないなら、回答を未確認として保留するか、別の許可された資料を探す条件を決めます。新しい情報が得られないことを、同じ呼び出しの回数だけで解決しようとしないことが要点です。
一方、429などのエラーが続く場合は、同じHTTP状態だけで原因を決めず、エラー種別、上限の対象、再試行の指示を確認します。OpenAIのRate limitsでは、要求数やトークン数などの制限を分け、失敗した要求も毎分の制限に寄与すると説明しています。待機して再試行できる条件では待機と回数・総時間の上限を設け、請求や設定の解決が必要なエラーを同じように再試行しません。
運用ルールでは、疑いを知らせる警告と、資源を守る停止条件を独立させます。たとえば本例で一タスクの金額上限50円、モデル要求5回、経過時間120秒という仮定の上限を置くなら、正常な長文でも上限へ達すれば継続を保留します。反対にBは、予算に余裕があっても進捗のない反復を理由に止める対象です。
金額の上限はプロンプトに書くだけでは強制できません。実行環境が、確定費用と実行中の未確定分、次の要求に必要な見込み額を照合し、許容枠を確保できない要求を発行しない構成にします。第三者ツールや子処理も対象に含めます。最大費用を把握できない経路は、厳密に上限内へ収まると保証せず、実行を保留する判断が必要です。
停止を指示した後も、残った要求を照合する
保留を決めたら、まず新しい要求の発行を止め、未開始の処理を取り消すか保留します。実行中の処理については取消できる条件を確認し、取消要求、停止確認、処理結果の確定を別に記録します。警告を表示しただけでは、裏で続く呼び出しを止めたことになりません。
MCP（Model Context Protocol）の2026-07-28版Cancellationでも、取消信号が完了後に届く場合や、取消不能などで無視される場合を扱っています。取消方法は通信方式によって異なるため、使っている版と接続先で確認します。取消の送出から、実行済みの更新や外部送信まで巻き戻ったとは判断できません。
本例Bなら、未確認の仕様項目、参照した資料Xの第3版、三回の取得状態、確定した13,500トークン、追加発行を止めた時刻を引き継ぎます。取消確認が取れない要求や使用量未着の要求が残るなら、そのIDを別に示します。原因調査中に同じタスクを作り直し、元の要求を忘れたまま実行を再開しません。
再開前は、終了条件や結果受渡しを修正し、許可された模擬記録で期待する判定を確認します。正当な長文を止めた件数と、異常反復を見逃した件数は別に残し、閾値を変えるときは両方への影響を調べます。異常検知の閾値調整と予算上限の変更は分け、予算を変える場合は業務責任者へ確認します。長文Aは反復扱いで止めない、反復Bは四回目を発行しない、状態確認の待機は期限まで許容する、使用量欠落は未確定として残す、という違いを見ます。これらは確認計画で、実際に合格した結果ではありません。警告を出せたか、追加要求を止められたか、残存処理を照合できたかを分けて確認してから、継続の可否を判断します。
目標逸脱・反復・過剰実行を止める条件は「AIエージェントの目標逸脱・反復・過剰実行を止める条件」で解説しています。
