エージェントはいつ止まるべきか

エージェントと限界 — 09

エージェントが仕事を終えられないとき、まず、もう少し時間を与えようと考えるかもしれない。ツールをもう一度呼び出す、別の試みをする、より強力なモデルを使う……。

続けることが役立つ場合もある。同じ不確かさの周りに、処理だけを積み重ねてしまう場合もある。システムは動き続けるが、課題の解決に近づいているのかは分からない。

a2に取り組む中で、停止はそれ自体が一つの設計上の問いになる。

次の一歩を進めるために、どのような根拠が必要なのか。

答えは、課題の完了、使う資源、手元の証拠、エージェントの権限によって変わる。

答えを出せば、仕事は終わるのか

仮に、二つのファイルのデータを照合する仕事を考えてみる。レコードを結び付け、一致しないものを分け、矛盾は残す必要がある。

エージェントが出力を生成したとき、ファイルを読み取れることは最初の確認を通る。必要な項目が期待した形式で存在することも、別の確認だ。けれど誤ったレコードを結び付けていたら、仕事はまだ正しくできていない。

そのためa2では、出力の検証と、独立した期待結果との比較を分けている。参照となる答えが与えられれば、それと比較できる。形式だけを確認しても、意味の上で課題を正しく解いた証明にはならない。

停止の判断にも、この区別が必要だ。モデルの最終回答は、実行が終わったことを示すかもしれない。仕事を受け入れるには、どの確認を通ったかも知る必要がある。

無効な出力を成功結果として記憶に保存しないことは、a2でこの境界を保つ仕組みの一つだ。

同じ処理を繰り返す意味は、いつあるのか

エージェントが照合スキルを呼び出し、エラーを受け取った。同じ入力で、同じスキルをもう一度呼ぼうと提案した。

二度目には何が変わるのだろう。

一時的な接続障害なら、再試行する理由はあるかもしれない。けれど同じデータに同じ変換を繰り返しても、欠けている照合ルールが自然に補われるわけではない。

a2のdata runでは、同じ引数による同じスキルの呼び出しを、既定で一回に制限している。繰り返そうとすると、次のモデル要求の前に実行が停止する。失敗した呼び出しも、この回数に含まれる。

入力が違えば、同じスキルを使える。繰り返しの上限は明示的に増やせる。この動作はa2の全経路に適用される一般ルールではなく、特定の実行経路の制約だ。

ここで大切だと思うのは、繰り返しが自動的に認められるものではないことだ。もう一度試す根拠を見えるようにする必要がある。

それでも、この仕組みが進捗全体を測るわけではない。別の言い方や別のツールで同じ場所に戻ることは、もっと広い問題だ。繰り返しの上限が捉えるのは、その一つの形に限られる。

資源の上限に達したとき

課題が未解決でも、実行に割り当てた資源は尽きることがある。

a2では、ステップ数の上限がループを制限する。トークン予算を設定すると、親エージェントと子エージェントは同じ消費台帳を共有する。仕事を委ねても予算は最初に戻らない。チェックポイントから再開しても、それまでの消費量は保持される。

トークン上限はソフトリミットだ。一つの応答が残り予算を超えることはありうる。消費量を記録したあとで、次の要求を止める仕組みだからだ。したがって、正確な支出の上限として示すべきではない。

消費量が分からない場合もある。プロバイダーが使用量を返さない、または情報が無効な場合、予算を設定した実行では追加の要求を止める。

理由は単純だ。どれだけ使ったか分からなければ、残りを信頼できる形で計算できない。

予算で停止した実行を、完了と数えるべきではない。途中までの結果とともに、停止理由も残す必要がある。

処理が実行されたか分からないとき

停止が、資源よりもエージェントの外で何が起きたかという不確かさに関わる場合もある。

ファイルを変更するツール呼び出しが始まり、そのあとでプロセスが中断したとしよう。処理の完了を確認する記録はない。

同じ呼び出しをやり直すのは簡単に見える。けれど最初の処理がすでに実行されていたかもしれない。再試行が二度目の変更を生む可能性がある。

a2のチェックポイントは、ツール処理の前に保留中の処理を示す印を残す。その記録から再開すると、不確かな処理を自動で繰り返さず、確認のために停止する。

あらゆる状況で処理が厳密に一度だけ行われる保証ではない。状態が不確かなときに、自動継続を制限する仕組みだ。

権限の確認にも似た区別がある。Gateは、承認が必要な処理に承認がなければ、その処理を止められる。一つの処理を止めることと、課題全体を止めることは違う。エージェントは別の許可された経路で進めるかもしれないが、別のツールで承認の欠如を迂回すべきではない。

対応可能な経路を見つけられないとき

課題を頼まれたからといって、手元のスキルで実行できるとは限らない。

a2の計画経路では、提示された契約で目標を満たせない場合や、依頼が曖昧な場合に、モデルは空の計画を返せる。このとき実行可能な計画ファイルは保存されず、対応可能な計画が見つからなかったと報告して停止する。すでに使ったモデル呼び出しとトークンは計上される。

ここにも限界がある。この動作は、対応できない仕事をすべて確実に認識する仕組みではない。モデルは誤った計画を提案しうるし、構造上の条件を満たす計画でも目標を取り違えることがある。

だから、計画を生成することと、目標に適した経路を見つけることには、別々の確認が必要だ。

「現在のツールでは進めない」という説明は、何が欠けているかも示せたときに役立つ。照合ルールなのか、必要なデータなのか、適したスキルなのか、それとも権限なのか。

停止したあとに何が残るべきか

a2の現在の仕組みは、この問いを部分に分けている。ステップ数の上限、共有予算、特定の繰り返しの拒否、不確かな処理の確認、出力検証だ。

これらは、エージェントがどんな状況でも適切な時点で停止することを示してはいない。a2はまだ開発アルファ段階にあり、この文章も新しい性能評価を示すものではない。

私にとって開かれたままの問いは、これらの部分が利用者に何を残すかだ。

実行はどこで止まったのか。どの処理が行われたのか。どの処理は実行されたか不確かなのか。残った出力はどの確認を通ったのか。続けるには何が変わる必要があるのか。

答えられれば、止まった仕事を引き継げる。欠けたデータを補い、権限を与え、ルールを直し、別の方法を選べる。

エージェントが止まる場所に、人が続けられるほど明瞭な跡を残したい。

---

出典について — 2026年10月15日：a2の既存コード、README、アーキテクチャ文書、技術仕様に基づく。データ照合と中断したファイル操作の例は仮定である。この文章のために新たなモデル呼び出しや評価実行は行っていない。

a2プロジェクト · アイデアが動く道具になるまで

シリーズの前の文章：写真のシリーズを組む。