AI に仕事を任せるには、モデルの外側を設計する

by

AI が正しい文章やコードを生成できることと、現実の仕事を最後まで完了できることは別の能力である。コード生成を例にすると、要求に合いそうな修正案を出した時点では、まだ既存コードとの整合性も、実行可能性も、変更後の挙動も確定していない。依存関係を壊していないか、既存テストが通るか、修正対象とは別の機能へ副作用が出ていないか、ブラウザ上で期待した状態になるかは、生成されたコードを実際の環境へ適用して初めて観測できる。

この差は、生成時点で利用できる情報の範囲から生じる。修正前には、修正後のテスト結果はまだ存在しない。テストを実行して失敗すれば、そのエラーメッセージやスタックトレースが新しい判断材料になる。さらにコードを直して再実行すれば、最初とは別のテストが失敗することもある。画面操作を伴う機能なら、クリック後にどの要素が表示されるか、通信が成功するか、表示状態が正しく更新されるかも、操作前には観測できない。

仕事を進めること自体が、次の判断に必要な情報を生む。ここが、一回の入力から一回の出力を返す生成処理と、環境を変えながら完了条件へ近づく仕事との境界になる。前者では、入力に必要な情報がそろっていれば、生成物を返した時点で処理を終了できる。後者では、操作によって環境が変わり、その変化を観測しなければ次の判断を決められない。

この過程を一方向の生成として扱うと、作業開始時には存在しなかった情報を利用できない。逆に、操作結果を観測し、その観測を次の判断へ戻せるなら、エラー内容に応じて修正箇所を変え、期待状態へ到達するまで処理を続けられる。AI エージェントに必要な最初の条件は、長い回答を生成することではなく、この往復を成立させることである。

ただし、環境と往復できれば、それだけで仕事を正しく完了できるわけではない。AI が古いファイルを現在の状態だと思って読めば、判断の前提が崩れる。必要な操作がツールとして提供されていなければ、正しい修正方針を考えても環境へ反映できない。作業途中の状態を失えば、長い仕事を再開するたびに現在位置を推測し直すことになる。テストや画面確認のような完了判定がなければ、途中状態を完成と誤認する可能性も残る。

モデルの推論能力は、この一連の過程の一部を担う。実際の仕事を完了する能力は、その推論を現在状態へ接続する観測手段、環境を変更する操作手段、必要な情報を維持する仕組み、変更結果を判定する検証手段によっても決まる。さらに、機械だけでは判定できない仕様、優先順位、許容リスクについて、どの時点で人間へ判断を戻すかという境界も必要になる。

本稿で考える単位は、AI モデル単体ではなく、この一連の処理を含むシステムである。何を観測できるか。どの操作を実行できるか。現在の判断にどの情報を残すか。長い作業の途中状態をどこへ保存するか。何を満たせば完成とするか。どの条件で人間へ処理を返すか。これらを分解していくと、AI エージェントの実用能力がモデル性能だけでは決まらない理由を具体的に説明できる。

1. AI が答えを出せても、仕事を完了できるとは限らない

1.1 生成物が正しそうに見えても、実行結果はまだ存在しない

入力から出力までを一方向に考えてよい仕事もある。与えられた文章を短く要約する場合、対象文章が入力としてそろっていれば、要約文を作った時点で処理を終えられる。要約を生成したことによって元の文章そのものが変化し、その変化を読み直して要約を修正する必要は通常ない。

ソフトウェア開発では、出力したものを環境へ適用すると、その適用結果が新しい事実を生む。たとえば、認証処理の条件分岐を修正したとする。修正前には、その変更が既存テストを通るかどうかは観測できない。コードを書き換えてテストを実行すると、初めて成功または失敗という結果が発生する。

テストが失敗した場合、単に「修正が間違っていた」と分かるだけではない。どのテストが失敗したか、期待値と実際の値がどう違うか、例外がどこで発生したかという情報が得られる。その情報によって、次に調べるべき対象が変わる。認証判定そのものではなく、セッション更新処理に原因があると分かるかもしれない。修正対象を変えて再実行すれば、今度は別の依存関係が壊れていることが分かる場合もある。

因果関係は二段階に分かれる。最初のコード変更が実行環境を変え、その変化がテスト結果を生む。次に、そのテスト結果が原因候補の範囲を変え、次のコード変更を決める。作業開始時の入力だけでは、後半の判断材料を用意できない。後半の情報は、前半の操作を実行した結果として初めて存在するからである。

画面を伴う機能では、この関係がさらに明確になる。ログインボタンを押した後に設定画面へ遷移する機能を修正する場合、コード上の遷移先が正しく見えても、それだけでは完了と判定できない。実際にブラウザでログインし、ボタンを押し、設定画面が表示されるかを確認する必要がある。表示されても、必要な項目が欠けていたり、保存ボタンが無効なままだったりすれば、まだ要求を満たしていない。

コードを生成できる能力と、コード変更を完了できる能力の差はここにある。前者では、修正案を出せれば仕事が一区切りになる。後者では、修正案を環境へ適用した結果を観測し、その結果から次の判断を更新しなければならない。

1.2 仕事を進めるたびに、判断条件そのものが変わる

作業開始時に詳細な指示を与えれば、多くの判断材料を先回りして渡すことはできる。対象ファイル、変更方針、禁止事項、実行すべきテスト、期待する画面状態を指定することもできる。それでも、実行前には存在しない情報までは記述できない。

たとえば、変更後にテスト A が失敗したとする。失敗原因を修正すると、テスト A は通るがテスト B が落ちる。その結果から、A と B が共有している状態管理に副作用があると分かる。さらに状態管理を修正すると、今度はブラウザ上の戻る操作だけで不具合が再現することが分かる。この一連の情報を最初の指示へ完全に書いておくことはできない。テスト B の失敗も、戻る操作の不具合も、それ以前の変更を実行した結果として現れたからである。

このとき、作業の状態は単純に「未完了から完了へ進む」のではない。各操作によって観測可能な情報が増え、その情報によって次の原因候補が絞られ、次の操作が変わる。つまり、作業は結果を作るだけでなく、問題についての知識も更新している。

この構造を、入力と出力だけで表すと途中の変化が消える。

時点 観測できる状態 その時点で選べる判断
修正前 問題報告、既存コード、既存テスト、現在の画面状態を確認できる。 原因候補を立て、最初に変更する箇所を選べる。
最初の修正後 変更後のテスト結果、構文エラー、実行時例外などが新しく得られる。 最初の仮説を維持するか、別の原因候補へ切り替えるかを決められる。
テスト通過後 プログラム内部の条件を満たしたことは確認できるが、実画面の操作結果はまだ未確認の場合がある。 ブラウザ操作や結合確認へ進むか、追加テストを行うかを決められる。
画面確認後 利用者が実際に操作したときの遷移、表示、入力状態を確認できる。 要求を満たしたと判断するか、さらに修正へ戻るかを決められる。

一つ前の段階で得られた結果が、次の段階へ進む条件になる。テストが失敗しているのに画面確認へ進めば、内部状態が壊れたまま外見だけを調べることになる。逆に、単体テストが通ったことだけで終了すれば、ブラウザ上の操作経路でしか現れない不具合を残す可能性がある。

この順序性は、AI エージェントへ仕事を任せるときにもそのまま残る。モデルが一度に大量の推論をできたとしても、まだ発生していない観測結果を利用することはできない。必要なのは、各段階で環境から事実を取得し、その事実を次の判断条件へ変換する経路である。

1.3 開ループの生成から、閉ループの仕事へ移る

入力から出力までを一方向に進む処理を、制御の考え方になぞらえて開ループとして整理できる。最初に条件を与え、その条件から出力を作り、出力後の状態を次の入力へ戻さない構造である。文章の要約や、条件が完全に固定された変換処理では、この形式で十分な場合がある。

一方、環境へ操作を加え、その結果を観測し、観測結果によって次の操作を変える構造は閉ループになる。ソフトウェア修正でいえば、コードを変更して終わるのではなく、テストを実行し、結果を読み、必要なら再修正する。ブラウザ操作でいえば、クリック命令を発行して終わるのではなく、クリック後の画面状態を取得し、期待した状態になったかを確認する。

閉ループでは、操作結果を戻せることだけでも足りない。取得した結果が古かったり、必要な部分を含んでいなかったりすれば、次の判断が誤る。テストを実行できても、どの条件を満たせば完成なのか決まっていなければ終了判定ができない。途中状態を保持できなければ、長い作業の途中で処理が切れたときに、どこから再開するか分からなくなる。

閉ループを仕事として成立させるには、少なくとも観測、判断、操作、検証を区別する必要がある。

段階 役割 直接的な失敗 後続工程への影響
観測 コード、画面、ログ、テスト結果などから現在状態を取得する。 古い状態、無関係な情報、不完全な結果を現在状態だと認識する。 誤った前提から次の操作を選ぶため、推論そのものが正しくても変更先を誤る。
判断 現在状態、目的、制約から次の操作を選ぶ。 原因候補、優先順位、必要な検証を誤って選ぶ。 不要な変更を増やしたり、本来守るべき条件を壊したりする。
操作 ファイル変更、コマンド実行、ブラウザ操作などによって環境を変える。 必要な操作が存在しない、粒度が粗すぎる、権限が過大または不足している。 正しい方針を立てても現実の環境へ反映できないか、意図しない範囲まで変更する。
検証 変更後の状態が要求した条件を満たしたかを確認する。 確認項目が不足するか、合否条件そのものが誤っている。 不完全な状態を完成として確定し、その誤りを後続作業へ渡す。

四つの段階は独立しているように見えるが、実際には連鎖している。観測を誤れば判断を誤り、判断を誤れば操作対象が変わる。操作結果を十分に観測できなければ検証へ進めず、検証が不十分なら誤った状態が次の観測時点の前提になる。一箇所の欠陥が一回の失敗で終わらず、その後の判断条件まで汚染する。

反対に、各段階が接続されていれば、モデルが最初の判断を誤っても修正できる。原因候補を間違えてコードを変更しても、テスト失敗を観測できれば仮説を捨てられる。ブラウザ操作が期待どおり進まなくても、現在の画面状態を取得できれば別の操作へ切り替えられる。閉ループの価値は、一度も間違えないことではなく、間違いを次の入力へ変換して回復できることにある。

この違いを踏まえると、「AI が賢ければ仕事を任せられる」という説明の不足が具体化する。推論能力が高くても、現在状態を取得できなければ古い前提で判断する。正しい修正方法を考えられても、必要な操作手段がなければ環境を変えられない。変更できても検証できなければ、途中状態と完成状態を区別できない。

AI エージェントの実用能力を考えるとき、生成能力は出発点になる。しかし、仕事の完了までを説明するには、モデルの外側まで見る必要がある。どのような状態を観測できるか、どのような操作を実行できるか、その結果をどの形式で受け取るか、何をもって完了と判定するかによって、同じモデルでも実際に遂行できる仕事は変わる。

次に確認すべきなのは、この差が概念上の整理にとどまるのか、それとも実際のエージェント性能として観測されるのかである。モデルと計算機の間のインターフェースを変えたときに成績が変わるなら、AI の能力をモデル単体だけで説明することはできなくなる。

2. エージェントは、一度答えるのではなく環境と往復しながら働く

2.1 行動すると、開始時には存在しなかった情報が得られる

言語モデルを外部環境と往復させる考え方は、AI エージェント研究で早くから明示的に扱われてきた。ReAct は、推論だけを連続させるのではなく、推論によって次の行動を選び、その行動によって外部環境から得た観測結果を後続の推論へ戻す構造を提示した[1]。この構造では、モデルが最初から必要な事実をすべて知っていることを前提にしない。分からないことがあれば行動によって調べ、得られた結果に応じて次の判断を変える。

たとえば、あるライブラリで「特定条件のときだけ設定値が反映されない」という不具合を調査するとする。開始時に分かっているのは、不具合報告とコードベースだけである。どのファイルに原因があるかはまだ分からない。そこで名前やエラーメッセージを検索すると、設定値を書き込む関数と、その値を読み出す別の関数が見つかる。前者を読んだだけでは問題が見えなくても、後者を読むと、空文字列だけを未設定として扱う条件分岐が見つかるかもしれない。

ここで一度修正してテストを実行すると、さらに別の情報が生まれる。対象テストは通っても、既存の回帰テストが失敗する場合がある。その失敗から、空文字列だけでなく null 相当の値も別用途で使われていたことが分かる。この時点で、原因についての理解は開始時とは変わっている。検索が候補を絞り、ファイル読解が仮説を作り、修正とテストがその仮説を検証し、失敗結果が次の仮説を作る。

因果関係は一段では終わらない。最初の行動によって外部環境から観測結果が得られ、その観測結果によって原因候補が更新される。更新された原因候補が次の操作を変え、その操作がまた別の観測結果を生む。仕事の途中で得られる情報が次の仕事の条件を変えるため、開始時の入力だけを基に最後まで推論を続ける方法とは構造が異なる。

段階 エージェントが行うこと 新しく得られる情報 次の判断への影響
検索 問題文の語句、関数名、エラーメッセージなどから候補箇所を探す。 関連するファイル、関数、テストの位置が分かる。 読むべき範囲を絞り込み、無関係なコードを調べる時間を減らせる。
読解 候補箇所の制御フローやデータの受け渡しを確認する。 原因候補、依存関係、変更時に壊れそうな前提が見つかる。 どこを変更し、どこを先に検証するかを決められる。
変更 仮説に基づいてコードや設定を修正する。 環境が新しい状態へ移る。 修正後の状態を実際に検証できるようになる。
検証 テスト、コマンド、実画面などで変更結果を確認する。 成功、失敗、別機能への副作用、未解決条件が分かる。 仮説を確定するか、修正方針を変更するかを判断できる。

この流れでは、失敗も単なる停止理由ではない。テスト失敗やコマンドエラーは、次の判断に利用できる観測結果になる。エージェントにとって価値があるのは、最初の推論で正解を当てることだけではなく、外したときに環境から得た情報を使って仮説を修正できることである。

2.2 ReAct が分けたのは、思考と実世界への作用である

ReAct の意義は、推論文とツール呼び出しを交互に並べた形式そのものより、モデル内部の推論と外部環境への作用を別の段階として接続したことにある[1]。モデルは「次に何を調べるべきか」を推論するが、検索結果そのものを内部推論だけで生成してはいけない。実際に検索を行い、外部から返った結果を観測として受け取り、その結果から次の推論を行う。

この区別がなければ、モデルは分からない事実についても、手元の情報から推測し続けることになる。たとえば、リポジトリ内に対象関数が存在するかどうかは、検索すれば確認できる事実である。ここを推測で済ませると、存在しないファイル名や古い API を前提に作業を進める可能性がある。検索できるなら、推論能力を「存在するかを当てる」ことに使うより、「何を検索すれば原因候補を最短で絞れるか」を決めるために使った方がよい。

外部環境を使うことで、モデルの仕事は二つに分かれる。一つは、不確実な状況から次に確認すべきことを選ぶ仕事である。もう一つは、実際の環境から返った事実を使って判断を更新する仕事である。この分離によって、推論と事実確認を混同しにくくなる。

ソフトウェア開発では、この差は特に大きい。依存ライブラリの現在のバージョン、テストの実行結果、ファイルの実際の内容、ブラウザで表示された状態は、推論だけでは確定できない。モデルがどれだけ過去のコード例を知っていても、現在のリポジトリがどの状態にあるかは環境を読まなければ分からない。エージェントは、この「推論で決めるべきこと」と「外部から確認すべきこと」を交互に処理する。

そのため、エージェントを単に「長く考える AI」と捉えると本質を外す。長い推論を一度行う構造では、開始時に与えられた世界像の中でしか判断できない。エージェントは、途中で世界へ問い合わせ、その回答によって自分が持っている世界像を更新する。能力差を生むのは推論の長さだけではなく、推論と外部観測をどのようにつなぐかである。

2.3 ワークフローとエージェントの違いは、途中で判断経路を変えられるかにある

Anthropic は、AI を使った処理を、大きくワークフローとエージェントに分けて整理している[2]。ワークフローでは、どの処理をどの順序で呼ぶかがあらかじめコード側で決められている。たとえば、「文書を三つに分割する」「各部分を要約する」「三つの要約を結合する」という処理なら、実行経路は開始前に固定できる。

エージェントでは、次に何をするかをモデル自身が途中状態から選ぶ。検索結果を見て別の検索へ進むかもしれない。ファイルを読んだ結果、当初予定していた変更をやめるかもしれない。テスト失敗を受けて、コードではなく設定ファイルを修正する場合もある。処理経路が実行前に完全には決まらず、観測結果によって分岐する。

観点 固定されたワークフロー エージェント
処理順序 開始前にコードや設定として決められている。 途中の観測結果に応じてモデルが次の処理を選ぶ。
分岐条件 想定された条件分岐を人間が事前に実装する。 観測内容を解釈し、想定外の状況でも別の手段を選べる。
適する仕事 入力形式と処理手順が安定しており、例外の種類を事前に列挙しやすい仕事に向く。 調査、デバッグ、複数ツールの選択など、途中で必要な手順が変わる仕事に向く。
失敗時の処理 失敗ごとの回復経路をあらかじめ実装する必要がある。 失敗内容を観測し、別の検索、修正、検証手段を選択できる。

この違いは、どちらが高度かという序列ではない。処理手順を事前に固定できるなら、ワークフローの方が予測可能で、テストしやすく、コストも管理しやすい。入力ファイルを決まった形式へ変換し、固定された検証を実行する処理に、毎回モデルへ次の行動を選ばせる必要はない。

エージェントが必要になるのは、途中で得られる情報によって次の手順そのものが変わる仕事である。未知の不具合を調べる作業では、最初から「三番目にこのファイルを開く」と固定できない。最初の検索結果によって読むファイルが変わり、読んだ内容によって実行するテストが変わり、失敗内容によって修正対象が変わる。この不確実性を処理するために、モデルへ判断権を渡す。

その意味で、エージェントの自律性は「人間が何も指示しなくても動く」という性質より、途中状態に応じて処理経路を選び直せる性質として捉えた方が具体的である。観測結果を受け取り、その結果から次のツール利用を選び、終了条件を満たすまで反復する。これが、単発生成や固定ワークフローから一段進んだ構造になる。

2.4 環境へ接続しただけでは、モデルの能力を十分に使えるとは限らない

ここまでの整理だけなら、強い言語モデルへシェル、ファイルシステム、ブラウザを渡せば十分に見える。実際、通常の Linux シェルには、検索、ファイル閲覧、編集、コマンド実行というソフトウェア開発に必要な操作がほぼそろっている。機能の有無だけを見れば、エージェントはそれだけでリポジトリを調査し、コードを変更し、テストまで実行できる。

しかし、「操作できる」と「操作しやすい」は異なる。人間は長大な検索結果から必要な数行を見つけたり、複数のシェルコマンドを組み合わせたり、エラーメッセージの文脈から次の操作を推測したりできる。言語モデルへ同じインターフェースをそのまま与えると、長い出力がコンテキストを占有し、必要な情報が大量の表示に埋もれ、細かな編集操作を何度も組み合わせる必要が生じる。

さらに、ツール側が返す情報の形も次の判断に影響する。検索コマンドが数千行を返せば、モデルはそのすべてを入力として受け取る。編集コマンドが成功したかどうかだけを返し、変更後の該当箇所を示さなければ、現在状態を確認するためにもう一度ファイルを読む必要がある。構文エラーを含む変更をそのまま保存すれば、次の操作は壊れた状態を前提に始まる。

つまり、外部環境への接続にはさらに一段下の設計問題がある。何を操作できるようにするかだけでなく、どの単位で操作させるか、操作結果をどの程度返すか、失敗をどの形式で知らせるか、現在状態のどの範囲を見せるかを決めなければならない。

ここで、モデル単体の能力とエージェントシステムの能力を分けて考える必要が生じる。同じモデルでも、検索結果が整理されて返る場合と、無制限の生データが返る場合では、次の判断条件が違う。変更後の状態が自動的に表示される場合と、変更成否しか返らない場合でも、誤りから回復するまでの手順数が変わる。

次章で扱う SWE-agent は、この点を実験として切り出している。基盤モデルを同じままにして、モデルと計算機の間のインターフェースを変えたとき、実際のソフトウェア工学タスクの成績がどう変わるかを比較した。もしインターフェースだけで性能が動くなら、エージェントの実力をモデル性能だけで説明することはできない。

3. 同じモデルでも、仕事道具を変えると成績が変わる

3.1 SWE-bench が測っているのは、短いコード生成ではなく修正作業の完遂である

SWE-bench は、実在する GitHub の課題と、その課題を解決したコード変更を基に 2,294 件のソフトウェア工学問題を構成した評価基盤である[3]。入力として与えられるのは、単純な関数仕様だけではない。既存リポジトリと課題文があり、その中から問題に関係する箇所を特定し、既存設計を壊さない形で変更し、テストを通る状態まで持っていく必要がある。

ここでは、正しいコード断片を一度生成できるだけでは足りない。課題文に出てくる語句が、そのまま関数名やファイル名になっているとは限らない。まずリポジトリを検索し、候補となる実装を読み、呼び出し関係や既存テストを確認する必要がある。修正後にはテストを実行し、失敗すればその結果から原因仮説を更新する。前章で整理した「観測、判断、操作、再観測」という往復が、評価対象そのものに含まれている。

たとえば、課題文に「空の設定値を保存すると既定値へ戻ってしまう」と書かれていたとしても、原因箇所が設定保存関数にあるとは限らない。保存処理は正しくても、読み出し側で空文字列を未設定と同一視しているかもしれない。さらに、その条件分岐を変更すると、別のテストが「未設定時には既定値を返す」という既存仕様を要求して失敗する可能性がある。修正対象を決めるためには、課題文、コード、テスト、実行結果を何度も行き来しなければならない。

SWE-bench の意味は、このような修正作業を一つの問題として評価できる点にある。モデルがコードを知っているかだけでなく、リポジトリの中から必要な情報を探し、現在状態を把握し、変更を加え、その変更結果を検証できるかまでが問われる。モデルと計算機の接続方法を比較するには、短いコード生成よりこの種の課題の方が適している。

3.2 SWE-agent は、モデルを変えずに計算機との接続方法を変えた

SWE-agent の研究が切り分けたのは、基盤モデルの能力と、モデルが計算機を扱うための環境設計である[4]。研究者は、言語モデル向けに検索、ファイル閲覧、編集、エラー通知、履歴管理をまとめた Agent-Computer Interface、略して ACI を設計した。

ACI は、新しい知識をモデルへ学習させる仕組みではない。モデルの重みを変更するのでも、対象リポジトリについて追加学習するのでもない。変えたのは、モデルがファイルをどう見るか、検索結果をどの形で受け取るか、コードをどの単位で編集するか、変更が失敗したときにどの情報を返すかという、モデルと実行環境の間にある層である。

この分離が研究上重要なのは、性能差の原因を絞り込めるからである。より新しいモデルへ交換して成績が上がった場合、その差が推論能力、学習データ、コンテキスト長、ツール利用能力のどれに由来するかを切り分けにくい。一方、同じモデルを使い、インターフェースだけを変えれば、少なくとも「モデルの重みを変えなくても、仕事の遂行成績は変わるか」という問いを直接調べられる。

GPT-4 Turbo を使った SWE-bench Lite の比較では、通常の Linux シェルを中心に操作させる Shell-only agent が 11.0% を解決したのに対し、SWE-agent は 18.0% を解決した[4]。この数字を現在の AI が解ける問題割合として読むことはできない。2024 年当時のモデル、SWE-bench Lite の問題集合、評価方法に依存する値だからである。

比較から直接言えるのは、同じ基盤モデルでも、計算機との接続方法を変えるだけで解決率が変化したことまでである。Shell-only agent にも検索、ファイル閲覧、編集、テスト実行のための基本的な機能はある。それでも ACI を設計した構成の方が高い成績を示した。機能が存在することと、その機能をモデルが効率よく使えることは別である。

比較対象 基盤モデル 主な違い SWE-bench Lite の解決率
Shell-only agent GPT-4 Turbo 一般的な Linux シェルを中心に、モデルが通常のコマンドを組み合わせて調査、編集、実行を行う。 11.0%
SWE-agent GPT-4 Turbo 検索、ファイル表示、編集、エラー通知、履歴管理を言語モデル向けの ACI として構成する。 18.0%

この差には二段階の構造がある。第一に、インターフェースが変わると、モデルが一回の判断で受け取る情報の形と、実行できる操作の粒度が変わる。第二に、その違いが検索回数、誤編集、無駄な出力、失敗からの回復手順を変え、最終的な問題解決率へ影響する。モデルそのものが同じでも、モデルに到達する観測と、モデルから環境へ出ていく操作が変われば、利用可能な能力の範囲も変わる。

3.3 情報を増やした構成ほど成績が上がったわけではない

SWE-agent の結果をさらに細かく見ると、「良いツールを用意すると成績が上がる」という単純な話では終わらない。ACI の構成要素を一部変更したアブレーションでは、情報量や履歴量を増やした構成が、標準構成より低い成績を示した[4]。

標準構成では、ファイルを一定範囲ずつ表示する。これをファイル全文表示へ変えると、解決率は 18.0% から 12.7% へ下がった[4]。この比較だけから低下原因を一つに特定することはできない。一つの解釈として、必要部分と無関係な部分が同じ入力へ入り、現在の判断で選別すべき候補が増えた可能性がある。

たとえば、200 行付近の条件分岐を調べたいとき、前後 100 行だけが表示されれば、モデルが読む対象は比較的限定される。5,000 行あるファイル全体を表示すれば、対象関数だけでなく、別機能のクラス、コメント、補助関数、古い互換処理まで同じコンテキストへ入る。必要な情報は失われていないが、その情報が占める割合は下がる。情報量が増えることと、現在の判断に必要な情報が目立つことは同じではない。

履歴管理でも同じ傾向が出ている。直近の観測を中心に扱う標準構成に対し、全履歴を保持すると解決率は 15.0% へ下がった[4]。この差の原因も実験だけから一つに特定できないが、全履歴には編集によって古くなった観測も残り得るため、現在どの状態が有効なのかを識別する必要が増えるという経路は考えられる。

検索についても、検索結果をまとめて扱いやすい形で返す構成から、モデル自身が逐次的に検索結果をたどる構成へ変えると 12.0% まで低下した[4]。検索機能自体は失われていない。逐次検索では必要な候補へ到達するまでの操作と観測が増える構成になるが、それが成績低下の直接原因だとこの比較だけから断定することはできない。

ACI の構成 SWE-bench Lite の解決率 直接変わるもの 成績へ影響し得る経路
SWE-agent 標準構成 18.0% 必要範囲の表示、整理された検索結果、限定された履歴を使う。 現在の判断に関係する情報を比較的狭い範囲へ保ち、操作と観測の往復を短くできる。
ファイル全文表示 12.7% 一回の表示でファイル全体をコンテキストへ入れる。 対象箇所以外の情報も増えるため、必要なコードを識別する負荷が増え、コンテキストも多く消費する。
全履歴保持 15.0% 過去の観測を広くコンテキストへ残す。 編集前の古い状態と現在状態が同時に残り、現在の判断に不要な履歴も参照候補になる。
逐次検索 12.0% 検索結果をモデルが段階的に探索する。 必要な候補へ到達するまでの操作数と観測数が増え、途中で判断を誤る機会も増える。

これらの比較から、「コンテキストを減らせば常に性能が上がる」と一般化することもできない。対象タスクによっては、長いファイル全文や過去の履歴が必要になる場合もある。SWE-agent の実験が示すのは、少なくともこの評価条件では、情報を追加すること自体が利益にならず、情報をどの単位で提示するかが結果へ影響したという点である。

情報量を一つの軸だけで考えると、この違いを説明しにくい。重要になるのは、必要な情報が存在するか、現在の判断と関係する範囲へ絞られているか、古い状態と新しい状態を区別できるか、次の操作を決めるまでに何回の往復が必要かという複数の条件である。

3.4 編集機能は、書き換えるだけでなく失敗からの回復まで設計されている

ACI の特徴は、検索や表示だけではない。コード編集についても、人間が一般的なエディタやシェルを使う場合とは異なる補助が入っている[4]。変更を加えた直後に更新後の内容を表示し、モデル自身が意図した変更になっているかを確認できるようにする。また、構文上の問題を含む編集については、そのまま壊れた状態を保存するのではなく、問題を検出してモデルへ返す。

この設計によって変わるのは、エラーが起きるかどうかだけではない。一般的な編集では、モデルが変更コマンドを実行し、成功したと思い、後からテストを実行して初めて構文エラーに気づく場合がある。その時点では、原因が編集そのものなのか、修正したロジックなのか、別の依存関係なのかを切り分ける必要がある。

編集直後に構文上の問題を検出できれば、失敗地点を「編集操作」まで戻せる。壊れた変更を次の状態として確定せず、同じ箇所の修正へ戻れる。直接的には一つのエラーチェックに見えるが、その効果は後続工程へ広がる。壊れた状態でテストや追加編集へ進むことを防げるため、その後に発生する無関係なエラーや誤った原因推測も減らせる。

同様に、編集直後に変更後の周辺コードを返す仕組みは、単なる表示上の親切ではない。モデルが指定した行番号や置換条件が期待した箇所へ適用されたかを、その場で再観測できる。意図しない関数を変更していれば、テストまで進む前に修正できる。

編集後の仕組み 直接得られる情報 次工程への効果
変更後の内容を再表示 どのコードが実際に書き換わったかをその場で確認できる。 対象箇所の誤りや不完全な置換を、テスト実行前に修正できる。
構文上の問題を検出 編集操作自体が有効なコードを作ったかを確認できる。 壊れた状態を後続テストや追加編集の前提にすることを防げる。
失敗理由を返却 何が受理されなかったかをモデルが把握できる。 原因候補を広く推測せず、失敗した操作そのものを修正できる。

この構造を見ると、ツールの性能を「何ができるか」という機能一覧だけで比較できない理由が分かる。同じ「コードを編集できる」という機能でも、変更結果を自動で返すか、構文上の問題を検出するか、失敗時にどこまで具体的な情報を返すかによって、次の判断条件が変わる。

3.5 モデルと仕事の間には、独立して設計できる層がある

SWE-agent の比較を一本につなぐと、モデルの実用能力を決める経路を少なくとも三段階に分けられる。最初に基盤モデルが推論し、次に ACI がモデルと計算機の間で観測と操作を仲介し、最後に実際のリポジトリやテスト環境が変更結果を返す。

モデルが強くても、ACI が大量の無関係な情報を返せば、次の判断は難しくなる。ACI が必要な操作を提供しなければ、正しい方針を実行できない。編集結果を十分に返さなければ、モデルは現在状態を再取得するために余分な操作を行う必要がある。エラーを曖昧に返せば、修正対象を切り分けるための探索が増える。

逆に、ACI が現在の判断に必要な情報を整理し、操作結果をすぐ返し、局所的な失敗をその場で検出できれば、モデルは推論能力を「環境の扱い方を推測すること」より「問題そのものを解くこと」へ使いやすくなる。ここで性能差を生むのはモデルの知識量だけではなく、モデルへ届く観測と、モデルから環境へ出ていく操作の設計である。

この関係は、AI システムをモデル中心に見る場合と、仕事中心に見る場合の違いとして整理できる。

見方 主な評価対象 見落としやすい要因
モデル中心 推論性能、知識、コンテキスト長、生成品質などを比較する。 観測形式、ツール設計、エラー返却、履歴管理が実務成績へ与える影響を見落としやすい。
仕事中心 目的を達成するまでの観測、判断、操作、検証を含む一連のシステムを評価する。 モデルだけを交換すれば同じ改善が得られるとは限らないことを前提にできる。

SWE-agent から「環境設計の方がモデル性能より重要だ」とまでは言えない。より強いモデルへ交換すれば、別の条件でも成績は上がり得る。研究から直接確認できるのは、モデルを固定しても、モデルと環境の接続方法という別の変数だけで成績が動いたことである。

この区別には実務上の帰結がある。AI エージェントの性能が不足したとき、常に「もっと強いモデルが必要だ」と結論するのは早い。必要なファイルへ到達できているか、検索結果が過剰ではないか、古い履歴が混ざっていないか、編集後の状態を確認できるか、エラーが次の判断に使える形で返っているかを分けて確認する必要がある。

SWE-agent のアブレーションは、その中でも特に情報の与え方へ注意を向ける。ファイル全文を見せることも、全履歴を残すことも、少なくともこの実験では標準構成を上回らなかった。ここから論点は、AI にどれだけ多くの情報を与えるかではなく、現在の判断にどの情報を残すかというコンテキスト設計へ移る。

4. AI に与える情報は、多ければ多いほどよいわけではない

4.1 情報が存在することと、その情報を判断に使えることは別である

長いコンテキストを扱えるモデルが登場すると、コード、仕様書、ログ、会話履歴をできるだけ多く渡せば、判断材料が増えるぶん性能も上がるように見える。必要な情報が入力されていなければモデルはその情報を使えないため、情報不足を避けるという方向自体には合理性がある。しかし、前章で見た SWE-agent の結果では、ファイル全文を見せる構成や全履歴を残す構成が、必要な範囲へ情報を絞った標準構成を下回った。情報が不足すると判断できない一方で、情報を追加し続けても性能が単調に上がるわけではない。

前章の全文表示の比較をこの観点から読むと、必要な情報がコンテキスト内に存在することと、その情報を現在の判断へ有効に使えることは分けて考える必要がある。必要範囲だけを取得できれば、情報を完全に失わずに、現在の判断へ参加させる候補を狭められる。

この差は、単純な容量不足の問題ではない。コンテキスト上限に余裕があっても、どの情報が現在の判断に関係するかという選択問題は残る。入力可能な量が増えることと、判断対象を選別する必要がなくなることは別である。

AI エージェントにとって必要なのは、利用可能な情報を最大化することより、現在の一手を決めるために必要な情報へ到達できることになる。情報不足と情報過多は反対方向の失敗に見えるが、どちらも「現在の判断に必要な情報を適切な状態で渡せていない」という同じ設計問題から生じる。

4.2 エージェントが動くほど、コンテキストには古い状態が蓄積する

単発の質問では、入力された資料は回答中にほとんど変化しない。エージェントでは事情が異なる。ファイルを読み、編集し、テストを実行し、さらにファイルを読み直すたびに、新しい観測結果が追加される。同じ対象について、異なる時点の情報が一つのコンテキストへ共存するようになる。

たとえば、認証処理を調査している途中で auth.py を最初に読み、その内容を観測 A とする。数回の操作後に auth.py を編集し、変更後の内容を観測 B として読み直したとする。さらにテスト失敗を受けて再修正し、観測 C を取得する。この時点では、A、B、C はすべて同じファイルについての情報だが、現在状態を表しているのは C だけである。

観測 取得時点 内容 現在の判断での扱い
観測 A 修正前 不具合が存在していた時点の auth.py を表す。 不具合原因を理解する履歴としては有用だが、現在コードとして扱うと誤る。
観測 B 最初の修正後 一度目の変更を反映した auth.py を表す。 最初の修正とテスト失敗の関係を調べる材料になるが、すでに現行状態ではない。
観測 C 再修正後 現在の auth.py を表す。 次の操作を決める直接の前提として使う。

履歴をすべて残すと、「何が起きたか」は詳しく保存できる。その一方で、「今どうなっているか」を判断するには時点を区別しなければならない。古いコードも新しいコードも文字列としては同じコンテキストに存在するため、単純に多くの情報を保持するだけでは現在状態を表現したことにならない。

古い観測と現在状態が同時に残る問題は、SWE-agent で全履歴を保持した構成が標準構成を下回った結果とも対応する。標準構成では、直近の観測を中心にコンテキストを管理する。全履歴を残せば過去の情報を失わずに済むが、同時に古くなった観測も判断候補として残る。情報保存の利益と、現在状態を識別する負荷が同時に増える。

ソフトウェア開発では、状態の新旧を間違えると影響が連鎖する。古い auth.py を現在状態だと判断すれば、すでに修正済みの箇所をもう一度修正する可能性がある。その変更によって現在コードがさらに変わり、新しいテスト結果が生じる。最初の観測誤りが一回の読み違いで終わらず、その後の操作と検証結果まで変えてしまう。

エージェントが長く動くほど、課題は「情報を忘れないこと」から「どの情報が現在も有効かを管理すること」へ移る。コンテキスト管理は記憶容量の問題だけではなく、時間とともに変化する状態をどう表現するかという問題でもある。

4.3 コンテキストには、コード以外の情報も入り続ける

Anthropic は、エージェントにおけるコンテキストを、その時点でモデルが利用できる情報の集合として整理している[5]。そこにはユーザーからの依頼だけでなく、システム上の指示、利用可能なツールの定義、検索やファイル閲覧で取得した情報、過去の会話、コマンド出力、エラーメッセージ、途中まで作った計画なども含まれる。

この点は、単に「長いコードを何行読ませるか」という問題より広い。たとえば、10 個のツールが利用可能なら、それぞれの名前、役割、引数、返却形式についての情報もモデルから参照できる状態にする必要がある。テストを 20 回実行すれば、それぞれの出力も候補になる。検索結果を大量に取得すれば、その内容も追加される。エージェントが仕事を進めるほど、利用可能な情報は自然に増加する。

情報の種類 役割 増え続けた場合に起こること
ユーザーの要求 達成すべき目的、制約、禁止事項を定める。 途中の補足指示が増えると、初期条件との優先関係を解釈する必要が生じる。
ツール定義 何を観測し、どの操作を実行できるかをモデルへ知らせる。 利用可能なツールが増えるほど、現在の仕事に適したものを選ぶ判断も複雑になる。
ファイル・検索結果 対象システムの実際の状態を提供する。 無関係な候補や編集前の状態まで残ると、現在状態との区別が必要になる。
コマンド・テスト結果 操作が成功したか、どこで失敗したかを示す。 解決済みのエラーまで保持すると、現在も存在する問題なのかを判別する必要がある。
作業履歴 何を試し、なぜ変更したかを残す。 詳細をすべて残すと、現在の一手には不要な過程がコンテキストを占有する。

一つ一つの情報は役に立つ。それでも、すべてを常時モデルから見える状態にする必要があるとは限らない。解決済みのエラーについては、「この原因は調査済みで対象外」という結論だけがあればよく、数百行の過去ログそのものは不要になる場合がある。検索済みのファイルについても、候補から外した理由だけを残し、全文は必要になったときに再取得できればよい。

ここでコンテキストは、資料を保存する場所ではなく、現在の推論に使う作業領域として捉えた方が分かりやすい。保存すべき情報と、常時モデルへ見せるべき情報は一致しない。後から参照する可能性がある情報は外部に保存し、現在の判断に必要になった時点で再取得すれば、情報を失わずにコンテキスト内の密度を維持できる。

4.4 必要な情報は、最初から全部入れるのではなく必要になった時点で取得する

情報を必要になった時点で取得する考え方は、エージェントの仕事の進み方と相性がよい。開始時には、最終的にどの情報が必要になるかを完全には予測できない。原因調査の最初からリポジトリの全ファイルを読むより、課題文から検索語を作り、候補ファイルを見つけ、その内容から次に読む対象を決めた方が、作業の進展に応じて必要情報を絞れる。

Anthropic は、この種のコンテキスト管理について、最小限の高信号情報を維持し、必要な情報を必要になった時点で取得する考え方を示している[5]。ここでの「最小限」は、文字数を機械的に少なくすることではない。現在の判断を成立させるために必要な情報を残し、それ以外は必要になったら再取得できる状態へ置くことを意味する。

たとえば、リポジトリに 10,000 個のファイルがあるとしても、その 10,000 個を開始時に読み込む必要はない。まずディレクトリ構成や検索結果を使って候補を 20 個へ絞り、その中から関数名や参照関係を調べて 3 個へ絞る。その 3 個を読んで原因候補が一つに絞れたら、関連テストを検索する。各段階で対象範囲が決まり、その範囲に応じて次の情報を取得する。

段階 取得する情報 この時点で取得しない情報 次へ進む条件
問題把握 課題文、リポジトリ構成、主要な検索結果を確認する。 全ファイルの本文や全テストの実装までは読まない。 原因候補となるモジュールや機能領域を絞れる。
原因調査 候補ファイル、呼び出し元、関連する条件分岐を読む。 現在の原因候補と関係しない機能の詳細は取得しない。 変更すべき箇所について検証可能な仮説を立てられる。
変更 対象コードと変更に直接関係する周辺情報を保持する。 原因から外れた候補ファイルの全文は保持し続けない。 変更後の状態をテストできる。
検証 関連テスト、失敗結果、変更後のコードを使う。 すでに解決した探索過程の詳細は必要に応じて圧縮する。 合格なら状態を確定し、不合格なら失敗内容から必要情報を追加取得する。

この流れでは、情報取得そのものが推論の一部になる。何を検索するか、どのファイルを開くか、どのログを詳しく読むかという選択によって、次にモデルへ入る情報が決まる。エージェントは与えられたコンテキストの中だけで推論するのではなく、自分の操作によって次のコンテキストを作っている。

そのため、検索やファイル閲覧は単なる補助機能ではない。次の判断に必要な情報を選別する機構として働く。検索結果が適切に絞れなければ大量の候補がコンテキストへ入り、ファイル閲覧の粒度が粗ければ不要な実装まで読み込む。情報取得ツールの設計は、そのままコンテキストの質へ影響する。

4.5 使い終わった詳細は、捨てるのではなく圧縮または外部化する

現在の判断に不要になった情報をコンテキストから外すと、「後で必要になったときに困る」という懸念が生じる。この問題は、情報を完全に消すことと、常時モデルへ見せないことを区別すると整理できる。

たとえば、200 行のテストログを調査した結果、「失敗原因は session_id が null の場合だけ発生する」という事実が確定したとする。次の修正を考える段階では、200 行のログ全体より、この確定した条件の方が高い情報価値を持つ。ログそのものはファイルや実行履歴として保存しておき、コンテキストには調査結果だけを残せる。

同じことは作業履歴にも当てはまる。「A を疑って調べたが原因ではなかった」「B を変更したが回帰テスト C が失敗した」「現在は D の状態管理を調査している」という三つの事実があれば、各調査で実行した数十回のコマンドをすべて保持しなくても現在位置を理解できる。

情報 そのまま保持する場合 圧縮・外部化する場合 残すべきもの
長いテストログ すべての標準出力とエラー出力をコンテキストへ残す。 元ログは外部へ保存し、現在の失敗原因と該当箇所をコンテキストへ残す。 次の修正判断に必要な失敗条件と、必要なら元ログへ戻れる参照先を残す。
過去のファイル内容 編集前後の全文をすべて保持する。 現在のファイルを基準とし、変更理由や差分は Git などへ残す。 現在状態と、変更理由を復元できる情報を残す。
探索履歴 検索語、検索結果、読んだ全ファイルを保持する。 除外した仮説と現在の原因候補を要約し、詳細は必要時に再検索する。 同じ誤った探索を繰り返さないための結論を残す。

圧縮には損失がある。長いログを一文へまとめれば、後で別のエラー行が必要になったときに、その詳細は現在のコンテキストには存在しない。だからこそ、圧縮と外部保存を組み合わせる。現在の判断には要約を使い、詳細が再び必要になれば元データを取得する。

圧縮と外部保存を組み合わせれば、保存領域と作業領域を分離できる。すべての記録を失わずに残す場所と、現在の一手を決めるためにモデルへ見せる場所を同じにする必要はない。長期作業では、この分離がさらに重要になる。数時間、数日、複数セッションへ作業が広がれば、過去の詳細をすべて同時に保持すること自体が現実的ではなくなる。

4.6 プロンプト設計から、コンテキスト設計へ対象が広がる

生成 AI を単発で使う場合、入力設計の中心はプロンプトになりやすい。「どの役割を与えるか」「何を出力させるか」「どの条件を守らせるか」を文章として明示し、その入力から一つの出力を得る。入力時点で必要情報がほぼ確定しているなら、この設計で多くを制御できる。

エージェントでは、仕事の途中で必要情報そのものが変わる。最初の検索結果によって読むファイルが変わり、ファイル内容によって実行するテストが変わり、テスト結果によって次に必要なログが変わる。そのため、開始時のプロンプトをどれだけ精密にしても、実行中のコンテキスト全体を開始時点だけで確定することはできない。

プロンプト設計とコンテキスト設計は、担当する範囲が異なる。

設計対象 主に決めること 典型的な問い
プロンプト設計 モデルへ何を依頼し、どの制約や出力条件を与えるかを定める。 何を達成させるか、どの形式で答えさせるか、何を禁止するかを決める。
コンテキスト設計 その時点の判断に、どの事実、履歴、ツール、途中成果を利用可能にするかを定める。 何を今見せるか、何を圧縮するか、何を外部へ残すか、何を必要時に再取得するかを決める。

両者は競合しない。目的や制約を明確にするプロンプトがあっても、現在状態を誤って渡せば判断は誤る。逆に、正確な現在状態を渡しても、何を達成する仕事なのかが曖昧なら、モデルは適切な終了条件を選べない。エージェントでは、指示の設計に加えて、実行中に変化する情報環境の設計が必要になる。

この観点から見ると、SWE-agent のファイル表示や履歴管理は細かな UI 上の工夫ではない。どの情報を現在の推論へ参加させるかを制御する機構である。ファイル全文表示で成績が下がったことも、全履歴保持で成績が下がったことも、単純に「情報が多すぎると AI は混乱する」という説明だけでは粗い。現在の判断と関係しない情報、古い状態、追加の操作を必要とする情報取得方法が、次の判断条件を変えている。

4.7 コンテキストを設計するには、情報へ戻るための経路が必要になる

現在必要な情報だけをコンテキストへ残す設計は、必要になった情報を後から取り戻せることを前提にしている。ファイル全文を保持しないなら、必要な行をもう一度読めなければならない。過去ログを圧縮するなら、詳細が必要になったときに元ログへ戻れなければならない。リポジトリ全体を読み込まないなら、検索によって必要ファイルへ到達できなければならない。

ここで情報管理の問題とツール設計の問題がつながる。コンテキストを小さく保てるのは、情報を失ってよいからではない。ファイル検索、部分読み出し、履歴参照、ログ取得などを通じて、必要な情報へ再到達できるからである。

たとえば、現在のコンテキストから 5,000 行のファイルを外しても、「関数名から該当ファイルを検索する」「指定範囲だけを読む」という操作が安定して使えるなら、必要時に詳細へ戻れる。反対に、検索機能が弱く、一度コンテキストから外した情報へ再到達するのが難しい環境では、多くの情報を保持し続ける必要が生じる。

この因果を逆から見ると、優れた情報取得ツールはコンテキスト管理の自由度を上げる。必要時に正確な情報へ戻れるから、すべてを常時保持する必要が減る。常時保持する情報が減れば、現在の判断に関係する情報の割合を高くできる。情報密度が上がれば、次の操作を選ぶ際に比較すべき候補も減る。

AI に与える情報量だけを最適化しても、この構造は完成しない。何を残すかと同時に、何を外へ置き、必要になったときにどう取得するかを設計する必要がある。次章で扱うツールは、単に AI に新しい機能を追加するものではない。AI が環境のどの情報へ到達でき、どの粒度で取得し、どの形式で結果を受け取るかを決める。コンテキスト設計の次には、必然的にその取得経路となるツールの設計が現れる。

5. ツールは機能一覧ではなく、AI と環境の契約である

5.1 同じ機能でも、AI から見える形が違えば使いやすさは変わる

前章では、AI に必要な情報を常にすべてコンテキストへ入れるのではなく、必要になった時点で取得できる構造が重要だと整理した。そのためには、検索、ファイル閲覧、ログ取得、ブラウザ操作といった外部への経路が必要になる。しかし、ここで「検索ツールがある」「ブラウザ操作ツールがある」と機能の有無だけを数えても、エージェントが実際にその機能を使いこなせるかは分からない。

たとえば、同じリポジトリ検索でも、検索結果として 500 件の一致行をそのまま返すツールと、ファイル名、一致箇所、周辺数行を整理して返すツールでは、次の判断条件が違う。前者でも必要な情報は含まれているかもしれないが、モデルは数百件から有力候補を選び直さなければならない。後者で候補が適切に整理されていれば、検索後すぐに「どのファイルを読むか」という次の判断へ進める。

操作についても同じである。ファイルを書き換えられるという機能があっても、変更後の内容が返らなければ、実際にどこが変わったかを確認するためにもう一度ファイルを読む必要がある。失敗時に単に「エラー」とだけ返る場合と、「指定した文字列が 2 箇所に存在するため変更対象を一意に決められなかった」と返る場合でも、その後の回復手順は異なる。

機能 機能だけを見た場合 実際に性能へ影響する設計
検索 対象文字列を検索できる。 結果件数、周辺文脈、絞り込み条件、ページ分割などによって、次の候補を選ぶ難しさが変わる。
ファイル閲覧 ファイル内容を取得できる。 全文を返すか指定範囲を返すかによって、コンテキスト消費量と必要部分の識別負荷が変わる。
編集 ファイルを書き換えられる。 対象指定の方法、変更後の再表示、失敗時の復旧方法によって、誤編集から回復するまでの手順数が変わる。
ブラウザ操作 クリックや文字入力を実行できる。 どの要素を操作対象として認識できるか、操作後の状態をどの形で取得できるかによって次の判断が変わる。

ツールの機能数と、エージェントが仕事を完了できる能力は一対一には対応しない。AI から見て、何を入力すればよいか、何が返ってくるか、失敗したときに何を修正すればよいかまで理解できる形になって初めて、その機能を安定して利用できる。

5.2 AI 向けツールでは、呼び出し方だけでなく返却内容まで契約になる

Anthropic は、従来の API が決定的なソフトウェア同士を接続するのに対し、AI エージェント向けのツールは、決定的なシステムと非決定的なエージェントの間を接続する契約になると整理している[6]。通常のプログラムは、条件分岐として書かれた規則に従って API を呼ぶ。言語モデルは、与えられた目的、現在の観測、ツール説明から、そもそもどのツールを使うかまで判断する。

この違いによって、API では補助的だった情報が、エージェントでは行動選択そのものへ影響する。ツール名が曖昧なら、似た機能のどちらを使うべきか判断しにくい。説明文が抽象的なら、どの条件で呼び出すべきか分からない。引数の意味が重複していれば、不正な組み合わせを作る可能性がある。返却値が大量の内部情報を含んでいれば、呼び出し自体は成功しても、その後の判断に必要な事実が埋もれる。

このため、エージェント向けツールでは少なくとも四つの契約を分けて考える必要がある。どの状況で使うものかを示す機能境界、何を指定すれば操作できるかを示す入力、操作結果として何を返すかを示す出力、失敗した場合にどの修正が必要かを示すエラーである。

契約 定める内容 曖昧な場合に起きる失敗
機能境界 そのツールが何のために存在し、どの場面で使うかを定める。 似たツールを誤って選び、不要な操作や遠回りが発生する。
入力 対象、条件、範囲など、操作に必要な情報を定める。 不正な引数や過剰に広い対象を指定し、意図しない操作を実行する。
出力 操作結果として、次の判断に必要な情報をどの形式で返すかを定める。 成功した事実だけは分かっても、環境がどの状態へ変わったか判断できない。
エラー 何が失敗し、どの条件を修正すれば再試行できるかを示す。 原因を広く推測する必要が生じ、無関係な操作を繰り返す。

従来の API 設計でも、入力と出力を明確にすることは当然求められる。それでも AI エージェントでは、曖昧さの影響する場所が広い。人間がコードとして呼び出し条件を固定するのではなく、モデル自身が説明を読んで利用判断まで行うためである。ツール仕様は、単なる実装者向け文書ではなく、エージェントが次の行動を選ぶための入力にもなる。

5.3 返却値は、処理結果ではなく次の判断材料として設計する

通常のプログラムでは、ツール呼び出しの返却値を、後続コードが機械的に処理する。成功なら true、失敗なら false だけでも、後続処理が別途状態を取得する設計なら成立する。エージェントでは、返却値がそのまま次の推論材料になるため、返却内容の粒度が行動の質へ直接影響する。

ファイル編集を例にすると、「成功した」という結果だけでは、指定した変更が期待した場所へ適用されたか分からない。変更後の周辺コードまで返せば、モデルはその場で編集結果を再観測できる。誤った箇所を書き換えていれば、テストへ進む前に修正できる。返却情報を増やしたことで一回の出力は長くなるが、確認のための別操作を省ける。

反対に、返却情報を無制限に増やせばよいわけでもない。リポジトリ検索で 10,000 件をすべて返せば、検索結果を取得するという目的は達成していても、次に読むファイルを決める作業が難しくなる。返却値は「システム内部で取得できる情報を全部出す」のではなく、「次の判断に必要な情報を十分に返す」という基準で設計する必要がある。

この関係は、前章のコンテキスト設計と直接つながる。ツールの返却値は、その呼び出し直後からコンテキストの一部になる。返却量が過剰なら、それだけで現在の判断に不要な情報が増える。返却量が不足すれば、状態を確認するために追加のツール呼び出しが必要になる。

返却設計 直後に起きること 後続判断への影響
情報が不足 操作が成功したかだけが返り、変更後の状態が分からない。 状態確認のために追加操作が必要になり、往復回数が増える。
必要十分 結果と、次の判断に必要な周辺情報が返る。 同じ観測から次の操作を直接選びやすい。
情報が過剰 大量のログ、候補、内部情報が一度に返る。 必要部分を選別する負荷とコンテキスト消費が増える。

ツール出力の最適化は、文字数を最小化することでも、取得できる情報を最大化することでもない。次の判断を成立させる情報を返し、それ以外の詳細へは必要なときに再到達できるようにする。この設計によって、ツール利用とコンテキスト管理が一つの仕組みとしてつながる。

5.4 エラーは停止理由ではなく、次の操作を決める観測である

AI エージェントにとって、ツールの失敗は処理終了を意味するとは限らない。ファイルが見つからない、検索結果が多すぎる、編集対象を一意に決められない、入力欄が画面上に存在しないといった失敗は、現在の仮説や操作指定が環境と一致していないことを示す新しい観測になる。

この観測を利用できるかどうかは、エラーの返し方によって変わる。たとえば、ファイル編集ツールが単に「編集失敗」と返した場合、モデルはファイルが存在しないのか、指定文字列が見つからないのか、複数一致したのか、書き込み権限がないのかを推測しなければならない。それぞれ対処方法が違うため、原因を外せば無関係な確認を繰り返す。

一方、「置換対象が 3 箇所存在するため一意に編集できない」と返れば、次の操作は対象範囲を狭めることになる。「指定した要素は現在のページに存在しない」と返れば、画面状態を再取得するか、前の操作が成功したかを確認する方向へ進める。エラー内容が原因分類まで含んでいれば、失敗そのものを次の行動条件として使える。

ここでも因果は二段階になる。第一に、エラー表現の具体性が、モデルが立てる原因候補の数を変える。第二に、原因候補の数が、再試行までに必要な追加観測や誤操作の数を変える。エラー処理は、失敗時の表示品質ではなく、閉ループがどれだけ短く回復できるかを決める機構になる。

エラー 情報が粗い返却 回復に使える返却
検索対象が存在しない 検索に失敗したとだけ返す。 検索対象が存在しないことと、検索した範囲を返し、別の検索語や範囲へ変更できるようにする。
編集対象が複数一致 編集できなかったとだけ返す。 一致件数と候補位置を返し、対象範囲を狭められるようにする。
画面要素が見つからない クリック失敗とだけ返す。 現在の画面に対象が存在しないことを返し、画面状態の再取得や前段操作の確認へ戻せるようにする。

失敗を完全になくすことより、失敗した時点で誤りの範囲を小さく特定できる方が、長いエージェント処理では重要になる。一つの操作失敗が曖昧なまま残れば、その後の数回の操作が誤った前提に基づく可能性がある。局所的な失敗を局所的な情報として返せれば、その場で修正して閉ループへ戻れる。

5.5 Playwright MCP は、画面を操作対象の構造へ変換する

ブラウザ操作は、AI と環境の契約を具体的に考えやすい。人間は Web ページを視覚的に見て、どの文字が見出しで、どの長方形がボタンで、どの入力領域に文字を書けばよいかを判断する。画面には色、位置、余白、アイコン、文字サイズなど大量の視覚情報があるが、人間は経験を使ってその中から操作対象を抽出する。

Playwright MCP は、ブラウザの状態をエージェントから扱う際に、アクセシビリティ情報を利用した構造化されたスナップショットを提供し、そこからページ上の要素を認識して操作できるようにする[7]。モデルはページ全体を「画素の集合」としてだけ扱うのではなく、見出し、ボタン、入力欄、リンク、テキストなど、Web ページの意味的な構造を利用できる。

たとえば、人間には「右上の青いボタンを押す」という指示で十分でも、その表現には色と位置への依存がある。UI の配置が変わったり、テーマが変わったりすれば指示の意味が崩れる。一方、「設定」という名前のボタンを操作対象として認識できれば、位置や色ではなく要素の役割と名称を手掛かりにできる。

表現 得られる情報 操作対象を選ぶときの特徴
画面画像 色、位置、形状、文字、余白を含む視覚状態全体を取得できる。 視覚的な確認には強いが、操作対象を特定するには位置や形状から意味を読み取る必要がある。
構造化されたページ情報 見出し、ボタン、入力欄、リンクなどの意味的な役割と名称を取得できる。 「何を操作するか」を画面座標より高い抽象度で選びやすい。

これは、画像より構造化情報の方が常に優れているという意味ではない。レイアウト崩れ、色の間違い、要素の重なり、画像そのものの品質などは、構造情報だけでは判定できない。視覚的な状態を確認するにはスクリーンショットが必要になる場合がある。操作対象を選ぶための表現と、最終的な見た目を検証するための表現は、目的が違う。

この区別によって、ブラウザツールを一つの「画面操作機能」とまとめるだけでは粗いことが分かる。現在ページの意味構造を取得する観測、対象要素を指定する操作、操作後の状態を再取得する観測、必要に応じて画面そのものを画像として確認する検証では、必要な情報形式が異なる。

5.6 ツールは、環境から AI への観測と、AI から環境への操作を同時に定める

ここまでの例を整理すると、AI 向けツールには二つの方向がある。一つは、環境の状態を AI へ渡す方向である。検索結果、ファイル内容、ブラウザのページ構造、テスト結果がこれに当たる。もう一つは、AI の判断を環境へ反映する方向である。ファイル編集、コマンド実行、クリック、文字入力などが該当する。

この二方向は独立していない。観測が粗ければ、次の操作対象を正しく決められない。操作が粗ければ、意図した範囲だけを変更できない。操作後の再観測が不足すれば、本当に環境が変わったか分からない。つまり、ツール設計は「AI が何をできるか」ではなく、「どの状態を見て、その状態に対してどの変更を加え、その結果をどの状態として受け取るか」という一組の契約として考える必要がある。

方向 代表例 設計上の問い 失敗した場合
環境から AI への観測 検索結果、ファイル内容、ログ、ページ構造、テスト結果を取得する。 現在の判断に必要な状態を、どの粒度と形式で返すかを決める。 古い状態や無関係な情報を基に次の行動を選ぶ。
AI から環境への操作 編集、コマンド実行、クリック、入力などを行う。 どの単位で変更を許し、どの対象をどう指定させるかを決める。 正しい意図があっても、意図しない対象を変更したり操作自体に失敗したりする。
操作後の再観測 変更後のファイル、終了コード、更新後の画面などを取得する。 操作結果をその場で判断できるだけの情報を返すかを決める。 成功したと思い込んだまま次工程へ進み、誤った状態を前提にする。

必要な情報へ再到達できるツールは、前章で扱ったコンテキスト設計とも結び付く。ツールが必要な情報へ正確に再到達できれば、すべての情報をコンテキストに残し続ける必要はない。逆に、必要な情報を再取得しにくいツールしかなければ、モデルは将来必要になるかもしれない情報を保持し続けざるを得ない。

ツール設計が改善されると、単に操作が便利になるだけではない。必要時に情報へ戻れるためコンテキストを整理しやすくなり、結果を明確に返せるため誤った状態から早く回復でき、操作単位を限定できるため変更範囲も制御しやすくなる。一つのインターフェース設計が、観測、コンテキスト、操作、回復の複数段階へ影響する。

5.7 高い自律性ほど、ツールの権限境界がシステムの挙動を決める

ツールが AI と環境の契約であるなら、そこには「何ができるか」だけでなく「何をできないようにするか」も含まれる。ファイル閲覧だけを許すツールと、任意のファイルを書き換えられるツールでは、同じモデルでも環境へ与えられる影響範囲が違う。ブラウザでページを読むだけのエージェントと、フォーム送信まで行えるエージェントでも、失敗時の帰結は異なる。

観測権限が不足すれば、正しい判断材料を取得できない。操作権限が不足すれば、判断した内容を実行できない。一方、必要以上に広い操作権限を与えれば、一度の誤判断が広い範囲の変更へ直結する。権限の大小だけを問題にするのではなく、仕事を完了するために必要な最小単位まで操作を分解し、影響範囲をどこで区切るかが設計対象になる。

たとえば、「設定ファイルの一項目を変更する」という仕事で、任意のシェルコマンドを実行できることは十分条件ではあるが、必要条件ではない場合がある。対象設定だけを読み書きできる専用ツールがあれば、エージェントが誤って別ファイルを削除する経路そのものを減らせる。反対に、調査対象が未知で、どのコマンドが必要になるか事前に分からない仕事では、汎用シェルの柔軟性が必要になる。

ここには、固定ワークフローとエージェントを分けた第 2 章と同じ交換条件がある。仕事の範囲が明確なら、狭いツールで操作経路を限定できる。途中で必要な処理が変わる探索的な仕事では、より汎用的なツールが必要になる。その代わり、観測、エラー、検証、人間への返却条件を強く設計しなければ、一回の判断ミスがそのまま環境変更へ広がる。

AI 向けツール設計は、機能を追加する作業ではなく、環境との接触面を定義する作業になる。何を見せるか、どの粒度で変更させるか、結果をどう返すか、失敗をどう伝えるか、どこまで操作を許すかによって、モデルが同じでも実際の振る舞いは変わる。

5.8 観測と操作が整っても、長い仕事には現在位置を残す仕組みが必要になる

ツールが適切に設計されれば、エージェントは必要な情報を取りに行き、環境を変更し、その結果を受け取ることができる。しかし、この閉ループが一つのセッションに収まるとは限らない。数十個のファイルを変更する仕事、複数の機能を段階的に実装する仕事、調査と検証を何度も繰り返す仕事では、一回のコンテキストだけで最後まで進めない場合がある。

ここで必要になる情報は、過去の会話すべてではない。「何を調べたか」「どの仮説を捨てたか」「どこまで変更したか」「どの検証が通ったか」「何がまだ未確認か」といった、現在の作業位置を復元するための状態である。

ツールによって環境を操作できても、この状態が次のセッションへ渡らなければ、新しいエージェントは同じ検索を繰り返したり、すでに否定された原因を再調査したり、不完全な変更を完成済みだと誤認したりする。観測と操作の閉ループを時間方向へ延長するには、途中状態をモデルの会話記憶とは別の場所へ残す必要がある。

長時間エージェントでは、この問題がさらに明確になる。焦点は「モデルがどれだけ長く覚えられるか」ではなく、セッションが切れても仕事の現在位置を復元できるように、どの状態を外部へ残すかに移る。

6. 長い仕事は、会話の記憶ではなく外部状態でつなぐ

6.1 長期作業で失われるのは、会話ではなく「現在位置」である

長い仕事を AI に任せるとき、「もっと長いコンテキストを持つモデルなら解決する」と考えやすい。しかし、作業を継続するために必要なのは、過去の発言を最初から最後まで再現できることではない。次の実行主体が、現在どこまで仕事が進み、何が確定し、何が失敗し、何がまだ未確認なのかを復元できることである。

たとえば、三つの機能 A、B、C を順番に実装する仕事を考える。機能 A のコードを書き、単体テストは通ったが、ブラウザ上の確認はまだ終わっていない。その途中でセッションが終了したとする。次のセッションに必要なのは、前の会話を一語ずつ再現することではない。「A の実装は存在する」「単体テストは通過した」「実画面確認は未実施」「B と C には着手していない」という現在状態である。

この情報がなければ、新しいセッションはリポジトリを読んで現在位置を推測するしかない。コードが存在することだけを見て A を完成済みと判断すれば、未確認の状態を確定事項として B へ進む。逆に、A が未完成だと考えて同じ修正を最初からやり直せば、すでに通っていたテストや設計判断を重複して調査することになる。

長期作業で失われると困るのは、会話履歴そのものより、作業状態に付いていた意味である。同じコードが存在していても、それが「実装途中」なのか、「テスト済み」なのか、「暫定修正」なのか、「完成して後続作業が前提にしてよい状態」なのかによって扱いは変わる。ファイルの内容だけでは、その確定度まで復元できない場合がある。

残っている情報 分かること 分からないこと 後続作業で起きる危険
コードだけ 現在リポジトリにどの実装が存在するかは分かる。 その実装が検証済みか、暫定状態か、どの要求まで満たしたかは分からない。 未確認の実装を完成済みとして後続作業が依存する可能性がある。
会話履歴だけ 過去に何を考え、何を試したかは追える。 会話後にファイルがさらに変更された場合、現在の実環境との一致は保証されない。 過去の説明を現在状態だと誤認する可能性がある。
現在状態と検証結果 何が実装され、どこまで確認済みかを区別できる。 詳細な経緯は別途参照しなければ分からない場合がある。 後続作業が利用してよい前提と、まだ依存してはいけない部分を分けられる。

長期作業の継続性を考えるとき、保存対象は「過去に何を話したか」から「現在何を事実として扱ってよいか」へ移る。この違いが、会話の記憶とプロジェクト状態を分ける出発点になる。

6.2 セッションが切れても、プロジェクトの状態まで消える必要はない

Anthropic の長時間エージェント実験では、新しいセッションが前のセッションの会話を直接保持しない条件で、複数回のセッションをまたいでアプリケーション開発を継続する方法が検討された[8]。そこで採用されたのは、モデルの内部状態を無理に連続させることではなく、作業に必要な状態をファイルや Git など外部環境へ残す方法だった。

実験では、最初のエージェントが開発環境を初期化し、後続セッションが同じ環境を読み直して作業を継続する。進捗を記録する claude-progress.txt、コミット履歴として残る Git、アプリケーションの起動方法を固定する初期化スクリプトなどが、セッション間の引き継ぎに使われた[8]。

外部状態を使う方法では、前のモデルが何を考えていたかを完全に復元する必要がない。次のセッションは、Git の履歴からどの変更が加えられたかを確認し、進捗ファイルから何が終わり、何が残っているかを読み、実際のコードから現在状態を再確認する。会話の連続性が切れても、仕事側の連続性を維持できる。

ここには二段階の分離がある。第一に、モデルのセッションとプロジェクトの寿命を分ける。セッションは終了しても、ファイル、Git、テスト結果は残せる。第二に、過去の思考過程と後続作業に必要な状態を分ける。すべての推論を保存しなくても、確定事項、未完了事項、検証結果が残っていれば次の作業を始められる。

外部状態 保持する内容 次のセッションでの用途
Git 履歴 どのファイルをどの単位で変更したかを保持する。 現在コードと直前の変更範囲を確認し、すでに行った作業を重複させないために使う。
進捗ファイル 完了事項、未完了事項、既知の問題、次の作業候補を保持する。 どこから再開すべきかを短時間で復元するために使う。
初期化スクリプト 環境の起動方法や再現手順を固定する。 セッションごとに異なる起動方法を推測せず、同じ条件でアプリケーションを再現するために使う。
テスト結果 どの条件が確認済みで、どの条件が失敗しているかを保持する。 実装の存在だけでは分からない確定度を判断するために使う。

この設計によって、モデル内部の記憶が有限でも、プロジェクトそのものは有限のセッションへ分割して進められる。長期作業を一つの巨大な会話として維持する代わりに、複数の短い実行を外部状態で接続する構造になる。

6.3 長い仕事ほど難しいが、その原因を状態管理だけに帰すことはできない

長時間タスクそのものが AI にとって難しいことは、別の研究でも定量化されている。人間が完了するまでに要する時間と AI の成功率の関係を調べた研究では、人間なら長時間を要するタスクほど AI の成功率が下がる傾向を使って、AI が一定確率で完了できる仕事の「時間地平」を測定している[9]。

この結果を「長い仕事に失敗するのは、AI が過去を忘れるからだ」と読むことはできない。長時間タスクでは、必要な推論の数、使用するツールの種類、コード変更の範囲、途中で起こる失敗、要求間の依存関係なども増える。短時間の仕事より難しい理由は複数ある。

たとえば、人間なら 5 分で終わる設定変更なら、対象ファイルを一つ読み、一箇所を書き換え、一回テストすれば完了するかもしれない。2 時間かかる機能追加なら、仕様を読み、複数ファイルを変更し、データモデルを更新し、単体テストと結合テストを実行し、ブラウザで確認し、途中の失敗を修正する必要がある。作業時間が伸びるにつれて、一回の誤判断が後続工程へ影響する経路も増える。

仕事が長くなると増えるもの 直接生じる負荷 長期継続への影響
観測回数 ファイル、ログ、画面、テスト結果を何度も読む必要がある。 古い観測と現在状態を区別する必要が増える。
操作回数 編集、コマンド実行、ブラウザ操作を繰り返す。 一つの誤操作が後続状態へ影響する機会が増える。
中間成果 一部だけ完成したコードや暫定的な判断が増える。 完成済みと未確定を区別しなければ後続作業が誤った前提へ依存する。
失敗と再試行 仮説を捨て、別の経路へ戻る回数が増える。 何を試して否定したかを残さないと、同じ失敗を繰り返しやすい。

長時間タスクで状態管理が重要になるのは、時間が長いからではなく、時間が長くなるほど途中状態の種類が増えるからである。調査済み、実装済み、テスト済み、未確認、失敗中、差し戻し済みといった状態が混在し、それらを次の判断へ正しく渡す必要が生じる。

この研究は、外部状態を残せば長時間タスクが解決すると証明したものではない。それでも、長い仕事では一回の推論能力だけではなく、多数の中間状態を正しく扱い続ける能力が必要になるという背景を与える。

6.4 会話履歴を残すことと、作業状態を残すことは役割が違う

会話履歴にも価値はある。なぜその方針を選んだのか、途中でどの仮説を検討したのか、利用者からどの追加条件が提示されたのかを確認するには役立つ。しかし、会話履歴だけをプロジェクト状態の正本にすると、現在の実環境とのずれが発生する。

たとえば、会話中に「config.py を変更した」とモデルが説明した後、人間が別途その変更を修正したとする。次のセッションが会話履歴だけを読めば、モデルが説明した状態を現在状態だと考える可能性がある。一方、実際のリポジトリを読めば、人間による後続変更を含む現在状態を取得できる。

逆の問題もある。リポジトリだけを読んでも、「なぜこの実装になったか」「どのテストはまだ確認していないか」「一時的な回避策なのか」は分からない場合がある。コードは現在の実装状態を持つが、状態の意味や確定度をすべて表現するわけではない。

このため、長期作業では情報を役割別に分けた方が安定する。

情報源 正本として扱いやすい情報 補助情報として使う内容
リポジトリ 現在どのコード、設定、テストが存在するかを表す。 変更理由や未確認条件は必ずしも十分に表現しない。
Git 履歴 どの変更がどの単位で確定されたかを追跡できる。 コミットされていない作業や詳細な判断過程は別途必要になる。
進捗・タスク状態 何が完了し、何が未完了で、次に何をするかを表す。 実装内容そのものはリポジトリを参照する必要がある。
会話履歴 指示変更、検討過程、補足説明を追跡できる。 現在の実環境と一致しているかは再確認が必要になる。

一つの情報源ですべてを表現しようとすると、それぞれの弱点を引き受けることになる。現在コードはリポジトリ、変更履歴は Git、完了状態は進捗管理、詳細な経緯は必要に応じて会話やログというように役割を分ければ、次のセッションは目的に応じて必要な情報を再取得できる。

6.5 CLAUDE.md と自動メモリは、同じ「記憶」でも保持する内容が異なる

Claude Code の現在の仕様でも、セッションをまたぐ情報はモデル内部だけに閉じていない。Claude Code は各セッションを新しいコンテキストから開始し、CLAUDE.md と自動メモリを通じて継続的な情報を外部へ保持する[10]。

CLAUDE.md は、人間が明示的に管理するプロジェクト上の指示に向いている。ビルド方法、テスト手順、コード規約、触れてはいけないファイル、リポジトリ固有の運用ルールなど、セッションが変わっても守るべき条件を記述できる。これらは「前の作業で何が起きたか」ではなく、「このプロジェクトでは毎回何を前提にすべきか」を表す。

自動メモリは、Claude が作業中に得た知見、訂正、利用者から与えられた継続的な指示などを保持する仕組みである[10]。たとえば、「このリポジトリでは npm test ではなく専用スクリプトを使う」「特定ディレクトリは生成物なので直接編集しない」といった知見が次のセッションでも役立つ場合がある。

ただし、これらと現在のタスク進捗も同一ではない。プロジェクト規則が分かっても、「機能 A のブラウザ確認が未完了」という現在位置までは表現しない。長期作業では、永続的な規則、継続的な知識、現在のタスク状態を別々に管理する必要がある。

情報の種類 例 寿命 適した保存先
プロジェクト規則 テスト方法、コーディング規約、禁止操作を保持する。 長期間変わらない。 CLAUDE.md など、人間が管理するプロジェクト指示へ置く。
継続的な知見 過去の訂正、ツール利用上の注意、環境固有の癖を保持する。 複数セッションで再利用される。 自動メモリなど、継続的な知識領域へ置く。
現在のタスク状態 どの機能まで終わり、何が失敗し、次に何を確認するかを保持する。 作業中に頻繁に変化する。 進捗ファイル、タスク管理、Git の作業状態などへ置く。
詳細な実行記録 ログ、過去のコマンド出力、デバッグ情報を保持する。 必要時だけ参照する。 ログや外部成果物として保存し、常時コンテキストへは載せない。

「記憶」という一語でまとめると、この寿命の違いが見えなくなる。毎回守る規則と、現在のタスク進捗と、一度だけ必要だったデバッグログでは、更新頻度も参照タイミングも違う。長期エージェントでは、何を覚えるかだけでなく、どの種類の情報をどこに置くかが継続性を左右する。

6.6 未確定な成果を確定事項として渡すと、誤りが次の仕事の前提になる

既稿「AI による大規模開発では、未確定な状態を一件ずつ閉じる」では、中規模以上の AI 開発で危険なのは、作業量そのものより、後続タスクが前提にしてよいか分からない状態が残ることだと整理した[11]。長時間エージェントの外部状態という観点から見ると、この「未確定」をどのように記録するかがセッション間継続の中心になる。

三つの機能 A、B、C が依存関係を持つ場合を考える。A の出力形式を B が利用し、B の結果を C が表示する。A のコードを書いたが、境界値テストがまだ失敗している状態で A を完成済みとして記録すると、次のセッションは B を A の仕様に合わせて実装する。その後 A の修正で出力形式が変われば、B も作り直す必要が生じる。

ここでは一つの未確認事項が二段階で影響する。最初に、未検証の A を確定状態として外部へ残す。次に、その誤った確定状態を後続セッションが前提として B を実装する。A の問題が A の中だけに留まらず、B の設計判断へ伝播する。

反対に、「A は実装済みだが境界値テストが未通過」「B は A の確定後まで保留」と状態を分けて残せば、次のセッションは B へ進む前に A の未確認事項を処理できる。進捗情報は、単なるチェックリストではなく、依存関係をどこまで有効にしてよいかを制御する。

状態 意味 後続タスクが依存してよいか
未着手 実装も検証も始まっていない。 依存してはいけない。
実装中 コードは存在するが、変更内容も仕様もまだ変わり得る。 原則として確定前提にはできない。
実装済み・未検証 候補実装はあるが、要求を満たすことをまだ確認していない。 試験的な参照はできても、確定仕様として依存させない方がよい。
検証失敗 現在の実装が少なくとも一つの完了条件を満たしていない。 失敗条件を解消するまで後続作業の基準にしない。
検証済み 定義された完了条件を満たしたことを確認した。 その検証範囲について後続作業が前提にできる。

状態を細かく分ける目的は管理項目を増やすことではない。後続作業がどこまで依存してよいかを機械的に判断できるようにするためである。長期エージェントでは、次のセッションが前の作業者と同じ暗黙知を持たないため、確定度を外部状態として明示する意味が大きくなる。

6.7 外部状態は、モデルの記憶を補うだけでなく再開時の推測を減らす

外部状態を残す価値は、情報を忘れないことだけではない。次のセッションが現在位置を推測する量を減らせる点にもある。推測が必要な項目が多いほど、再開時に誤った前提を置く可能性も増える。

たとえば、進捗情報が何もない場合、新しいセッションはリポジトリを読み、変更差分を調べ、テストを実行し、実画面を確認して、前のセッションがどこまで終わらせたかを再構成しなければならない。これらは本来の開発作業ではなく、前回の状態を推定するための再調査である。

一方、「機能 A は単体テスト通過、ブラウザ確認未実施」「機能 B は未着手」「既知の失敗は test_session_timeout」のような情報が残っていれば、新しいセッションはその記録と実環境を照合し、差異がないことを確認してから作業へ入れる。最初から現在位置を推測する場合より、確認対象を限定できる。

ここでも外部状態を無条件に信用するわけではない。進捗ファイルが古い可能性はあるため、Git やテスト結果など実環境との照合が必要になる。役割は「真実を代わりに保存すること」ではなく、「どこを確認すれば現在位置を再構成できるかを示すこと」にある。

再開時の処理は、次のように変わる。

再開方法 最初に必要な作業 主な危険
外部状態なし コード、差分、テスト、ログから前回の進捗を推測する。 不完全な実装を完成と誤認したり、終了済みの調査を繰り返したりする。
外部状態あり 記録された進捗と現在のリポジトリ、テスト結果を照合する。 記録が古い場合にそのまま信用すると誤るため、実環境との一致確認が必要になる。

この違いは、作業時間だけでなく誤りの種類を変える。状態がなければ、次のセッションは「何が起きたか」を発見するところから始める。状態があれば、「記録された状態が今も正しいか」を確認するところから始められる。後者の方が検証対象を限定しやすい。

6.8 長期自律性は、無停止で動くことより中断後に正しく再開できることで成立する

AI エージェントの長期自律性というと、一つのモデルが何時間も連続して動き続ける姿を想像しやすい。しかし、実際のプロジェクトではモデル更新、コンテキスト上限、環境再起動、人間のレビュー、外部サービスの待ち時間などによって作業は区切られる。無停止を前提にするより、区切られても再開できることを設計した方が現実の運用に合う。

このとき必要なのは、モデル内部の連続性ではなく、仕事の連続性である。前のセッションが終了しても、現在のコード、確定した変更、未完了事項、失敗している検証、プロジェクト固有の規則が残っていれば、新しいセッションは同じ目的へ戻れる。

外部状態を読み直して再開する点は、人間の開発にも似ている。担当者が退勤すると記憶が完全に消えるわけではないが、翌日すべてを頭だけで復元するわけでもない。Git、Issue、テスト結果、設計文書、TODO を読んで現在位置を確認する。複数人で開発する場合には、さらに「他人が次に読んでも分かる状態」を残す必要がある。セッションをまたぐ AI エージェントでは、この条件がより厳密になる。次の実行主体は前回の暗黙知を持っていないからである。

外部状態は、この暗黙知をプロジェクト側へ移す仕組みになる。モデルの記憶能力が向上しても、この価値はなくならない。人間が途中でコードを変更した場合、テスト結果が更新された場合、別のエージェントが並行して作業した場合には、モデルが覚えている過去より現在の外部状態の方を優先しなければならない。

長期自律性を「一つの AI がどれだけ長く動けるか」だけで測ると、プロジェクト側に残された継続可能性を見落とす。より実務的な基準は、処理が途中で止まっても、別のセッションが現在状態を確認し、未完了部分を特定し、同じ検証条件の下で作業を再開できるかである。

6.9 状態を残すだけでは足りず、「確定してよい状態」を決める必要がある

外部状態を使えば、セッションをまたいで仕事をつなげられる。しかし、保存された状態が正しいことまでは保証されない。進捗ファイルに「機能 A 完成」と書かれていても、テストが失敗しているかもしれない。Git に変更がコミットされていても、要求した画面動作まで確認したとは限らない。

ここで、状態の保存と状態の確定を分ける必要がある。保存は「現在こうなっている」と記録する処理である。確定は「この状態を後続作業が前提にしてよい」と判定する処理である。前者はファイルへ書けばできるが、後者には検証条件が必要になる。

たとえば、実装が存在することだけを完成条件にすると、コードを書いた直後に状態を確定できてしまう。単体テスト通過を条件に加えれば、一段強くなる。それでもブラウザ上の操作が要求に含まれるなら、単体テストだけでは不十分である。何をもって確定とするかは、仕事ごとに必要な検証範囲から決まる。

状態 保存可能か 後続作業の確定前提にできるか
コードを書いた 現在の実装状態として保存できる。 要求を満たした確認がないため、そのまま完成扱いにはできない。
テストが失敗している 失敗状態として保存すべきである。 失敗条件を解消するまで、完成した機能として依存させない。
定義した検証条件を通過した 検証済み状態として保存できる。 その検証範囲については後続作業の前提にできる。

長い仕事を安全につなぐには、「何を覚えるか」からもう一段進み、「どの状態なら次へ渡してよいか」を決める必要がある。外部状態はセッション間の連続性を作るが、その状態の確定度を決めるのは検証である。

状態を確定するには、AI が作業結果を自分でテストし、画面を操作し、期待状態と比較できる必要がある。人間が毎回「できたかどうか」を確認しなくても閉ループを回せる範囲はそこで広がる。一方、検証条件そのものが誤っていれば、誤った状態を安定して確定してしまう。長期エージェントの継続性は、外部状態と検証器を接続して初めて完成する。

7. AI を自律させるには、「できた」を機械が確かめられるようにする

7.1 作業できることと、終了を判断できることは別である

エージェントがファイルを読み書きし、コマンドを実行し、ブラウザを操作し、複数のセッションをまたいで作業を続けられるようになっても、それだけでは仕事を自律的に完了できない。残るのは、「現在の状態で仕事を終えてよいか」を誰が判断するかという問題である。

たとえば、「設定画面に通知を無効化するスイッチを追加する」という仕事を考える。エージェントがコンポーネントを追加し、設定保存処理を書き、画面を表示できたとしても、その時点では要求を満たしたとは限らない。初期値が正しく表示されるか、スイッチを変更すると保存されるか、ページを再読み込みしても値が維持されるか、既存の通知設定を壊していないかまで確認する必要がある。

コードが存在することは、実装という一つの状態を示す。しかし、「利用者が要求された操作を行える」という完成条件は、それより広い。実装したという事実から完成したという結論へ進むには、要求と現在状態を比較する判定が必要になる。

この判定がモデル自身の文章上の自己評価だけに依存すると、観測した一部の状態から完成を推測する余地が残る。画面が表示されたので完成した、テストを一つ通したので問題ない、と判断しても、確認していない条件が残っているかもしれない。

確認段階 確認できること まだ確定しないこと
コード作成 要求に対応する実装がリポジトリ内に存在することを確認できる。 そのコードが実行可能か、既存機能と整合するかは確定しない。
ビルド成功 少なくともビルド時に検出される構文、型、依存関係上の問題がないことを確認できる。 実行時の振る舞いや利用者操作が正しいかは確定しない。
自動テスト成功 テストとして記述された条件を満たすことを確認できる。 テストに含まれていない要求まで満たしたとは限らない。
実画面確認 実際の操作経路で期待状態へ到達するかを確認できる。 確認していない別経路や非機能要件まで保証するわけではない。

作業が進むにつれて、確認できる範囲は広がる。しかし、どの段階をもって完成とするかは自動的には決まらない。要求に応じて必要な検証を先に定め、その条件を満たしたかを実行結果から判断できるようにする必要がある。

7.2 完了条件を外部化すると、自己評価から検証へ移せる

Anthropic の 2026 年の長時間アプリケーション開発実験では、計画を作る役割、実装する役割、成果を評価する役割を分ける構成が試されている[12]。実装役が「完成した」と述べたことをそのまま受け入れるのではなく、評価役が別の過程として完成条件を確認する。

評価役は Playwright MCP を使い、実際にアプリケーションを起動して画面を操作し、API やデータベース状態も含めて確認した[12]。この構成では、実装者が何を意図したかと、実環境がどの状態になったかを分離できる。

たとえば、実装役が「保存処理を追加した」と報告しても、評価役はその説明を成功条件にはしない。実際にフォームへ値を入力し、保存操作を行い、再読み込み後にも値が維持されているかを確認する。実装内容の説明ではなく、観測可能な結果を判定材料にする。

この分離によって、完了条件はモデルの自己認識から外へ出る。「自分は要求を満たしたと思う」という判断ではなく、「指定した操作を行った結果、期待状態が観測された」という事実へ置き換えられる。

判定方法 根拠にするもの 失敗しやすい点
実装者の自己評価 実装した内容についてのモデル自身の理解を根拠にする。 未確認の条件を暗黙に満たしたと推測する可能性がある。
外部検証 テスト結果、実画面、API 応答、保存状態など観測可能な結果を根拠にする。 検証条件に含まれていない要求は確認できない。

評価役を別モデルにすれば必ず正しくなる、という話ではない。評価役も言語モデルである以上、判断を誤る可能性がある。効果を生むのは役割名そのものではなく、評価時に実環境へアクセスし、あらかじめ定義された条件を観測可能な結果として確認する構造にある。

また、この三役構成が一般に最適だと示されたわけでもない。実験では評価役自体にも調整が必要で、入れ子になった不具合を見逃す例があり、モデル能力の向上に応じて足場となる構成要素を再評価する必要があると報告されている[12]。

7.3 検証方法があれば、失敗を次の入力へ自動的に戻せる

Claude Code の公式文書でも、エージェントへ自分で実行できる検証方法を与えることが推奨されている[13]。テスト、ビルド、静的検査、出力差分、スクリーンショット比較などを実行できれば、変更後に人間へ確認を求める前に、エージェント自身が失敗を観測できる。

この差は、単に人間の確認時間を減らすだけではない。失敗がエージェントの観測として返ることで、第 1 章から扱ってきた閉ループを最後まで機械側で回せるようになる。

たとえば、コードを変更した後に自動テストを実行し、1 件失敗したとする。エージェントがテスト結果を読めなければ、ここで人間が「このテストが落ちている」と知らせる必要がある。テスト結果を直接観測できれば、失敗したテスト名、期待値、実際の値、スタックトレースを使って原因候補を修正し、再びテストを実行できる。

因果は二段階になる。検証手段があることで、変更結果を合格と不合格に分類できる。不合格の理由を機械が読める形で取得できれば、その理由を次の修正判断へ戻せる。検証は作業の最後に一回行う採点ではなく、修正ループを継続させるための観測装置として働く。

状態 検証手段がない場合 検証手段がある場合
変更直後 モデルがコードを見て完成度を推測する。 テスト、ビルド、画面操作などを実行して外部状態を確認する。
失敗発生 人間が失敗を発見してモデルへ伝える必要がある。 終了コード、差分、エラー内容をモデル自身が観測できる。
再修正 人間から追加指示を受けて次の処理を開始する。 失敗内容から原因候補を更新し、そのまま次の修正へ進める。
終了 人間が最終的に「これでよい」と判断するまで処理が閉じない。 機械化された完了条件の範囲では、自動的に合否を判定できる。

人間が毎回結果を見て次の指示を返す構造では、AI の実行速度が上がっても、人間の確認待ちで処理が止まる。確認条件を機械が実行できれば、その範囲では生成、実行、検証、修正を一つのループとして閉じられる。

7.4 検証条件は、できるだけ観測可能な状態へ変換する

「正しく動くこと」のような抽象的な条件は、そのままでは機械検証できない。何を観測したときに正しいと判断するかへ分解する必要がある。

たとえば、「設定画面の保存機能が正しく動く」という要求なら、少なくとも複数の観測可能な条件へ分けられる。設定画面を開ける。入力欄へ値を設定できる。保存操作後に成功状態になる。ページを再読み込みしても値が残る。既存設定を変更していない場合は値が変わらない。このように分解すれば、それぞれをテストやブラウザ操作として表現できる。

Playwright では、要素が表示されているか、期待する文字列や URL になっているかといった条件を assertion として記述し、実際の画面状態と比較できる[14]。

抽象的な要求 観測可能な条件 検証手段の例
画面が正しく表示される 必要な見出し、入力欄、ボタンが表示されている。 Web assertion や ARIA スナップショットで確認できる。
保存できる 値を入力して保存すると成功状態になり、再取得した値が一致する。 ブラウザ操作、API 確認、データベース状態の確認を組み合わせられる。
既存機能を壊していない 関連する既存テストが引き続き成功する。 回帰テストを実行できる。
見た目が崩れていない 基準とする表示との差が許容範囲内に収まる。 スクリーンショット比較を使える。

要求を観測可能な条件へ変換すると、完成判定の根拠を明示できる。「たぶん動く」から「この操作を行い、この状態を確認した」へ変わる。検証結果を外部状態として残せば、次のセッションも何が確認済みなのかを再利用できる。

この変換には、もう一つ効果がある。要求そのものの曖昧さが表に出る。「使いやすくする」「自然に動く」「適切に表示する」といった要求は、そのままでは assertion に書けない。どの状態を観測すれば達成と判断できるのかを決める過程で、要求の不足や曖昧さを発見できる。

7.5 Web assertion は、時間とともに変化する画面を条件として待てる

Web アプリケーションでは、操作直後の画面状態を一回読むだけでは正しく判定できない場合がある。通信、描画、非同期処理によって、クリック直後には存在しなかった要素が数百ミリ秒後に表示されることがあるからである。

Playwright の Web 向け assertion は、期待条件が成立するまで一定時間再試行する仕組みを持つ[14]。たとえば、保存ボタンを押した後に「保存しました」という表示が出ることを確認する場合、ページの状態を一度だけ確認して存在しなければ即座に失敗するのではなく、条件成立を待ちながら繰り返し確認できる。

これは単純な利便性ではない。Web の現在状態が時間によって変わる以上、「いつ観測するか」も検証条件の一部になる。適切な待機なしに一瞬だけ状態を読むと、本来成功する処理でも読み込み途中を失敗と判定する可能性がある。逆に固定時間だけ待つと、環境によって処理が遅い場合に同じ問題が残る。

条件成立まで再試行する assertion は、「3 秒待つ」という時間そのものではなく、「対象要素が期待状態になった」という状態変化を終了条件にできる。この違いによって、処理速度の変動と要求された状態を分離しやすくなる。

確認方法 終了条件 起こり得る誤判定
即時確認 操作直後の一時点だけを見る。 非同期処理が完了する前の状態を失敗と判定する可能性がある。
固定時間待機 指定時間が経過したら状態を見る。 環境差によって処理時間が変わると、待機時間が短すぎたり長すぎたりする。
状態を待つ assertion 期待する画面状態が成立するか、期限までに成立しないことを確認する。 期待条件そのものが誤っていれば、技術的には正確に誤った条件を判定する。

ここでも検証器がしているのは、仕様の意味を理解することではない。指定された状態が成立したかを、実際の Web ページから繰り返し観測して判定している。何を待つべきかを人間や上流の設計が決め、その判定を機械へ渡す構造である。

7.6 ARIA スナップショットは、画面の意味構造を検証できる

画面の検証には、文字列や一つのボタンの存在確認だけでは足りない場合がある。画面全体として、どの見出し、リンク、ボタン、入力欄が存在するかという構造を確認したい場合がある。Playwright の ARIA スナップショットは、アクセシビリティツリーを基に、そのような画面構造を期待値として保存し、後の実行結果と比較できる[15]。

たとえば、設定画面に「通知設定」という見出し、その下に「メール通知」というチェックボックスと「保存」というボタンが必要だとする。画像上の座標を比較しなくても、これらの役割と名称が期待する構造として存在するかを確認できる。

この方法が有効なのは、見た目の細部ではなく、利用者が操作する意味構造を確認したい場合である。ボタンの位置が数ピクセル動いても役割と名称が変わらなければ、ARIA スナップショットは同じ機能構造として扱える。一方、「保存」ボタン自体が消えたり、見出し階層が変わったりすれば構造差として検出できる。

構造検証は、第 5 章で扱った Playwright MCP の観測ともつながる。エージェントが操作時に利用した見出し、ボタン、入力欄という意味構造を、そのまま完成条件の一部として比較できる。操作に使う表現と検証に使う表現を近づけられる。

7.7 画像比較は、意味構造だけでは分からない視覚差を検出する

ARIA スナップショットで画面構造が一致しても、見た目まで正しいとは限らない。ボタンが画面外へはみ出している、文字色が背景と同化している、要素同士が重なっている、余白が崩れているといった問題は、意味構造だけでは検出できない場合がある。

Playwright は、基準となるスクリーンショットと実行時のスクリーンショットを比較し、視覚的な差分を検出する仕組みも提供している[16]。これを使えば、HTML の要素構造やアクセシビリティツリーでは同じ構造に見えても、実際の描画結果が基準から変化した場合に差を検出できる。

検証方法は、対象とする失敗に応じて使い分ける必要がある。

検証方法 得意な対象 単独では見落としやすいもの
単体・結合テスト 関数の入出力、例外、データ処理、既存機能の回帰を確認する。 実際の画面操作や視覚的な崩れは確認しにくい。
ビルド・静的検査 構文、型、依存関係、規約違反などを確認する。 実行時にしか現れない論理上の不具合は確認できない。
Web assertion 特定の要素、URL、属性、文字列などの状態を確認する。 指定していない画面領域の問題は検出しない。
ARIA スナップショット 見出し、リンク、ボタンなど画面の意味構造を確認する。 色、余白、重なりなど純粋に視覚的な差は十分に表現できない。
画像比較 レイアウト、色、位置、描画結果などの視覚差を確認する。 差が機能上問題なのか意図したデザイン変更なのかは別途判断が必要になる。

一つの検証器ですべての要求を表現する必要はない。コードの振る舞いはテスト、画面上の意味構造は ARIA スナップショット、視覚的な回帰は画像比較というように、要求を観測可能な複数の層へ分けられる。検証範囲が明示されるほど、「どこまで確認済みか」も外部状態として記録しやすくなる。

7.8 検証器は、自律性を「操作権限」から「回復能力」へ変える

AI エージェントの自律性を、どれだけ自由に操作できるかだけで評価すると、権限の広さが中心になる。任意のファイルを書き換えられる、任意のコマンドを実行できる、ブラウザでフォームを送信できる、といった能力である。

しかし、広い操作権限だけでは、誤った操作から自力で戻れるとは限らない。エージェントが間違ったコードを書き、テストを実行せずに次へ進めば、自律的に動ける範囲が広いほど誤りも広がる。

検証器を加えると、自律性の意味が変わる。エージェントは「自分で操作できる」だけでなく、「操作結果を確認し、失敗したら修正できる」ようになる。失敗を検出して同じループへ戻れるため、一回の判断ミスが即座に人間介入へつながる必要がなくなる。

この違いは、次のように整理できる。

自律性の構成 できること 失敗時の挙動
操作だけ 環境を読み、変更し、次の処理へ進める。 失敗に気付けなければ、誤った状態を前提に処理を続ける。
操作と観測 変更後の状態を取得できる。 何が起きたかは分かるが、その状態が要求を満たすかを別途判断する必要がある。
操作と観測と検証 期待状態との比較まで機械的に実行できる。 不合格を次の修正入力として使い、人間を待たずに再試行できる。

自律性を高めるとは、人間の承認を単純に外すことではない。人間が確認していた条件のうち、機械的に表現できる部分を検証器へ移し、その結果をエージェント自身が利用できるようにすることである。自動化できる確認が増えるほど、人間が毎回ループに参加しなくても処理を進められる範囲が広がる。

7.9 検証済みの状態だけを次の仕事へ渡すと、長期作業が安定する

この検証の議論は、前章の外部状態と接続すると意味が大きくなる。外部状態へ「実装済み」とだけ記録するのではなく、「どの検証を通過したか」まで残せれば、次のセッションはその状態をどこまで信用してよいか判断できる。

たとえば、機能 A に対して、単体テストは通過したが画面確認は未実施だとする。この状態を「完成」と一括して保存すると、次のセッションが画面確認済みだと誤認する可能性がある。「単体テスト通過、ARIA 構造確認未実施、画像比較未実施」と残せば、次に何をすべきかが明確になる。

このように、状態と検証結果を組み合わせると、長期作業の確定度を段階として扱える。

状態 確認済みの条件 後続作業での扱い
実装済み コードが存在する。 候補実装として扱い、完成前提にはしない。
基本検証済み ビルドと主要テストを通過している。 内部実装については一定の前提にできるが、実操作条件が残る場合は未完了として扱う。
実操作確認済み 要求された操作経路で期待状態へ到達している。 確認した利用経路について後続作業が前提にできる。
定義済み完了条件を通過 そのタスクで事前に定めた検証項目をすべて満たしている。 その検証範囲について確定状態として次のタスクへ渡せる。

この構造では、テストは品質保証の最後に置かれるだけではない。後続作業が依存してよい状態を確定する境界にもなる。エージェントが長期間動く場合、何を実装したかより、何を検証済みとして次へ渡したかがプロジェクト全体の安定性を左右する。

機械検証によって AI が自分で失敗を見つけ、修正を続けられる範囲は広がる。ただし、検証器が判定できるのは記述された条件への一致であり、その条件が本来の要求を正しく表しているかは別問題である。この限界を具体化するのが、SWE-bench Verified の評価問題や Playwright の検証例である。

8. 検証器を置いても、正しさそのものは自動化できない

8.1 テストが判定するのは、要求そのものではなく要求を変換した条件である

前章では、AI エージェントがテスト、assertion、ARIA スナップショット、画像比較などを自分で実行できれば、生成、実行、検証、修正のループを人間の逐次確認なしに回せる範囲が広がることを見た。ただし、この自動修正ループが成立するには、検証器が本来の要求を適切に表現している必要がある。

テストは、要求を直接理解して合否を決める装置ではない。人間が要求から取り出した条件をコードとして表現し、その条件と実行結果を比較する。要求が「設定値として 0 以上の整数を受け付ける」なら、テストには 0、1、十分大きな値、負数などについて期待挙動を書くことになる。ここで 0 のケースを書き忘れれば、0 を拒否する実装でもテストを通る可能性がある。

逆方向の失敗もある。要求が「0 以上の整数を受け付ける」だけなのに、テストが内部実装で特定の補助関数を呼ぶことまで要求すれば、別の方法で正しく機能を実装したコードを不合格にする。実装が要求を満たしているかではなく、テスト作成者が想定した実装形態と一致しているかを判定する状態になる。

要求から機械判定までには、少なくとも三つの変換が入る。最初に要求を解釈し、次に観測可能な完了条件へ変換し、その条件をテストや検証コードとして実装する。それぞれの段階で情報が欠けたり、不要な制約が加わったりする可能性がある。

段階 変換する内容 起こり得るずれ 後続への影響
要求 利用者やシステムが何を実現したいかを定める。 曖昧な表現、矛盾、境界条件の欠落が残る。 後続の完了条件が、そもそも異なる要求解釈に基づく可能性がある。
完了条件 要求を観測可能な状態へ分解する。 重要な条件を落としたり、要求にない条件を追加したりする。 検証器が確認できる範囲そのものが偏る。
検証器 完了条件をテスト、assertion、比較処理として実装する。 実装ミス、過剰な具体化、環境依存が入る。 正しい実装を落とす、または誤った実装を通す可能性がある。

機械検証が正確であるということは、与えられた条件を正確に判定できることを意味する。その条件が本来の要求を正しく表現していることまでは保証しない。AI が自動修正まで行う場合、この違いはさらに大きくなる。検証器が誤っていれば、AI はその誤った条件を満たす方向へ何度でも修正を繰り返せるからである。

8.2 SWE-bench Verified の再調査は、評価器そのものが誤り得ることを示した

この問題を具体的に示す事例が、OpenAI による 2026 年の SWE-bench Verified 再調査である[17]。SWE-bench Verified は、実在する GitHub の課題をコード修正問題として使い、テストによって解決できたかを判定する評価基盤である。モデルが提出した修正について、指定されたテストが通れば、その課題を解決したものとして扱う。

OpenAI は、o3 が 64 回の実行でも安定して解けなかった 138 問を選び、人手で内容を監査した[17]。その結果、この 138 問の 59.4% に、テスト設計または問題記述上の重大な問題があったと報告している。内訳として、35.5% ではテストが特定の実装方法を過度に要求し、18.8% では問題文に書かれていない追加機能までテストが要求していた[17]。

前者では、機能的には要求を満たしていても、テスト作成者が想定した実装形式から外れると不合格になる。後者では、問題文だけを読んで正しく実装しても、明示されていない要求を満たさないため不合格になる。いずれも、モデルのコード修正能力だけでは説明できない失敗である。

問題の種類 何が起きるか 評価上の帰結
狭すぎるテスト 要求を満たす複数の正しい実装のうち、特定の実装方法だけを許す。 機能的には正しい修正を誤って不合格にする。
広すぎるテスト 問題文に記載されていない追加要件まで満たすことを要求する。 明示された要求を満たしていても不合格にする。
問題記述の不足 テストが要求する条件を、問題文から推測できない。 モデルは観測できない隠れた条件へ合わせる必要が生じる。

ここで 59.4% という数字の射程には注意が必要である。この割合は SWE-bench Verified 全体に対するものではない。o3 が 64 回の実行でも安定して解けなかった 138 問という、あらかじめ選択された部分集合に対する監査結果である[17]。この条件を外して「SWE-bench Verified の約 6 割が壊れていた」と一般化することはできない。

それでも、この事例から確認できる構造は明確である。評価器が存在することと、評価器が本来の要求を正しく表現していることは別である。モデルの成績が低い場合、その原因がモデルにあるとは限らず、課題記述、完了条件、テスト実装のどこかにある可能性も残る。

8.3 自動修正が強くなるほど、誤った検証器への最適化も速くなる

検証器の誤りは、人間が一回だけ結果を確認する場合より、自動修正ループの中に置いた場合の方が広い影響を持つ。AI エージェントは検証失敗を読み、その失敗を解消するようにコードを変更し、再び検証する。検証器が正しければ、この繰り返しによって要求へ近づける。しかし検証器が間違っていれば、同じ能力が間違った条件への適応に使われる。

たとえば、実際の要求が「CSV 出力の列順は変更しない」であるにもかかわらず、誤って新しい列順を期待値としてテストへ登録したとする。エージェントが既存の正しい列順を維持するとテストは失敗する。エージェントは失敗差分を読み、テストに合わせて列順を変更する。再実行するとテストは通る。閉ループとしては完全に成功しているが、製品要求としては退行している。

このとき誤りは二段階で増幅される。最初に、誤った要求表現が検証器へ固定される。次に、エージェントがその検証器を客観的な成功信号として繰り返し最適化する。自動修正能力が高いほど、誤った検証条件へ到達する速度も上がる。

検証器の状態 AI の修正能力が低い場合 AI の修正能力が高い場合
正しい 修正に時間がかかり、人間介入が頻繁に必要になる。 失敗から自動回復し、要求された状態へ速く収束できる。
誤っている 誤った条件へ十分に適応できず、人間が途中で異常に気付く可能性がある。 誤った条件を効率よく満たし、見かけ上は検証済みの状態を短時間で作れる。

自動化能力が上がることは、正しい評価軸に沿って動く限り大きな利点になる。その一方で、評価軸の誤りを自動化する能力も同時に上がる。AI を高速化することと、何へ最適化させるかを正しく定義することは、別の問題として管理しなければならない。

8.4 ARIA スナップショットの差分は、「変更された」ことしか直接は示さない

Web アプリケーションの検証でも同じ問題が現れる。ARIA スナップショットは、アクセシビリティツリー上の見出し、リンク、ボタン、入力欄などの構造を期待状態として保存し、実行時の構造と比較できる[15]。意図しない要素削除や役割変更を検出するには有効である。

しかし、画面構造を意図的に変更した場合、正しい変更でも既存スナップショットとの差分が生じる。そのとき必要なのは、差分を消すことではなく、その差分が要求された変更なのかを判断することである。

たとえば、設定画面に新しい「通知頻度」という選択欄を追加すれば、ARIA スナップショットは変化する。新しい要素が出たためテストは失敗する。この失敗は不具合を意味しない。仕様変更が正しく反映された結果かもしれない。

Playwright はスナップショット更新時に差分を確認し、新しい状態を基準として受け入れるための運用を用意している[15]。このレビューが必要になる理由は、機械が「旧状態と新状態が違う」ことまでは判定できても、「新状態の方が仕様として正しい」ことまでは差分だけから決められないためである。

差分 機械的に確認できること 別途判断が必要なこと
要素が削除された 以前存在したボタンや見出しが現在は存在しないことを検出できる。 削除が仕様変更なのか不具合なのかを判断する必要がある。
要素が追加された 以前なかった入力欄やリンクが追加されたことを検出できる。 追加が要求されたものか、意図しない表示なのかを判断する必要がある。
名称や役割が変わった アクセシビリティツリー上の構造変化を検出できる。 新しい名称や役割が利用者にとって適切かを判断する必要がある。

スナップショットテストは、変化を見逃さないための仕組みとして強い。だが、変化の意味までは自動的に決めない。検証器が担うのは、期待状態との差を検出することまでであり、期待状態そのものを更新してよいかは別の判断になる。

8.5 画像差分も、見た目が変わった理由までは説明しない

画像比較では、さらに分かりやすく同じ限界が現れる。スクリーンショット比較によって、ボタンの位置、余白、色、文字サイズなどが基準画像から変わったことは検出できる。しかし、その差分が不具合なのか、意図したデザイン変更なのかは画像差分だけでは決まらない。

たとえば、アクセシビリティ改善のため文字サイズを大きくした場合、スクリーンショット比較は広い差分を検出する可能性がある。検証器から見れば旧画像との不一致である。しかし要求側から見れば、その差分こそ実現したかった変更である。

逆に、基準画像自体がすでに不具合を含んでいる場合、その画像と完全に一致する新実装は視覚テストを通る。テストが安定していることと、基準画像が望ましい状態であることは一致しない。

検証を自動化するときには、比較処理と基準値を分けて考える必要がある。比較アルゴリズムが正確でも、比較対象の基準が古かったり誤っていたりすれば、判定結果も要求からずれる。

8.6 アクセシビリティは、自動判定だけでは完結しない例である

検証対象そのものを機械条件へ十分に変換できない領域もある。アクセシビリティはその典型例である。Playwright の公式文書でも、自動検査で検出できるのは一般的な問題の一部であり、多くの問題について手動検査や実際の利用者を含む検証が必要になると説明している[18]。

自動検査は、画像に代替テキストがあるか、フォーム部品にラベルが関連付いているか、特定のコントラスト条件を満たすかといった、規則として表現しやすい問題を機械的に確認できる。一方、ページ内の説明順序が利用者に理解しやすいか、複雑な操作が支援技術で現実に遂行可能か、文言が認知的に理解しやすいかといった評価は、HTML の属性や数値条件だけでは十分に判定できない。

アクセシビリティ上の確認 自動化しやすさ 理由
必須属性の有無 高い HTML の要素構造やアクセシビリティツリー上の明示的な条件として判定できる。
一定のコントラスト条件 比較的高い 色の組み合わせを数値として評価できる。
操作手順の理解しやすさ 低い 利用者の認知、前提知識、文脈を含むため、単一の機械条件へ落としにくい。
支援技術を含む実利用上の使いやすさ 低い 複数の操作、利用環境、利用者特性を含む総合的な確認が必要になる。

この例から、検証の自動化率には対象依存性があることが分かる。型検査のように条件を厳密に記述しやすいものは高い割合で機械化できる。利用者体験や意味理解のように文脈依存性が高いものは、人間による評価が残りやすい。

8.7 検証器を増やすだけではなく、要求との対応関係を管理する必要がある

テスト数を増やせば、確認できる条件は増える。しかし、数が多いことと要求を十分に覆っていることは同じではない。同じ内部関数について 100 件のテストがあっても、実際の利用者操作を一つも確認していなければ、画面経路の不具合は残る。

反対に、ブラウザを通した一連の操作テストだけを増やしても、境界値の細かなロジックを十分に検証できない場合がある。検証器は、要求のどの部分を確認しているかという対応関係を持たせる必要がある。

たとえば、「通知設定を変更して保存できる」という要求なら、保存 API の単体テストだけでは足りない。画面から変更できること、保存後に再取得できること、別利用者の設定へ影響しないことなど、要求を複数の観測条件へ分解して検証する必要がある。

要求 対応する検証 検証が欠けた場合
設定値を保存できる 保存 API のテストと永続化状態の確認を行う。 画面上では成功表示が出ても、実際には保存されていない不具合を見逃す。
利用者が画面から変更できる Playwright で実際に入力、保存、再表示を確認する。 内部 API は正しくても、UI 操作経路の不具合を見逃す。
別利用者へ影響しない 異なる利用者状態を使った分離テストを行う。 保存自体は成功しても、データ分離上の不具合を見逃す。

検証設計の中心は、「いくつテストがあるか」ではなく、「要求のどの条件を、どの観測によって確認しているか」である。AI が自動実行できる検証器を増やすほど、この対応表を明確にする価値も上がる。

8.8 人間の役割は、毎回の確認から評価基準の設計へ移る

AI がコードを書き、テストを実行し、画面を操作し、失敗時には自動修正できるようになると、人間が一行ずつコードを確認したり、一回ごとに実行結果を返したりする必要は減る。その代わり、人間側には「何を確認すれば完成とみなせるか」を設計する役割が残る。

人間が担う判断は、少なくとも三種類に分かれる。第一に、要求の意味を確定する。第二に、その要求を機械検証可能な条件と、人間確認が必要な条件へ分解する。第三に、検証器や基準値が変更された場合、その変更が仕様変更に対応しているかを確認する。

判断 自動化しやすい部分 人間側に残りやすい部分
要求の確認 既存仕様や明示された条件を検索し、矛盾候補を抽出する。 複数の要求が衝突した場合に、どちらを優先するかを決める。
完了条件の実行 テスト、assertion、画像比較などを繰り返し実行する。 その完了条件で要求を十分に表現できているかを決める。
基準値の更新 差分を生成し、変更箇所を提示する。 差分を新しい正解として受け入れてよいかを判断する。
自動化できない評価 補助情報や候補問題を抽出する。 利用者体験、意味、リスク、妥当性を総合して判定する。

この変化は、人間の判断量が必ず増えるという意味ではない。個々の実装を毎回確認する仕事は減らせる。その一方で、検証基準の設計ミスが多数の自動処理へ共通して影響するため、一つの上流判断が持つ影響範囲は大きくなる。

8.9 自動検証の規模が大きいほど、検証器の誤りも広く伝播する

手作業で一件ずつ確認している場合、誤った判断の影響はその一件に留まりやすい。共通の検証器を使って 1,000 件の変更を自動判定する場合、その検証器に欠陥があれば同じ誤判定を 1,000 件へ繰り返す可能性がある。

AI エージェントを大量に並列実行する場合、この性質はさらに強くなる。共通のテストスイート、共通の評価プロンプト、共通のスナップショットを成功条件として与えれば、全エージェントが同じ基準へ最適化する。正しい基準なら再利用によって品質を揃えられるが、誤った基準なら誤りも同じ形で複製される。

つまり、自動化によって消えるのは確認作業の回数であり、確認基準の責任ではない。むしろ共通基準を自動適用する範囲が広がるほど、その基準を変更、レビュー、追跡する仕組みが重要になる。

ソフトウェア開発でテストコードを本番コードと同じようにバージョン管理し、レビュー対象にする理由もここにある。AI エージェントの検証器についても、単なる補助的な確認スクリプトではなく、システムが何を正解として扱うかを定義する実行可能な仕様として管理する必要がある。

8.10 AI が実行を引き受けるほど、人間は「何を正しいとするか」の側へ移る

第 7 章では、検証器を置くことで AI が自分の失敗を発見し、人間を待たずに修正ループを続けられる範囲が広がることを見た。本章で分かったのは、その自律性が検証器の正しさに依存しているという点である。

要求から完了条件を作り、完了条件からテストを作り、AI がそのテストへ適応する。この流れでは、AI が下流の実行を引き受けるほど、人間の判断は上流へ移る。どの要求を優先するか、何を合格条件へ入れるか、どこまでを自動判定し、どこから人間確認へ戻すかという判断である。

この移動には一つの帰結がある。AI がコードを書く能力が上がれば、人間に必要な能力が単純に減るわけではない。コードを書く各操作への関与は減る一方、評価基準を設計し、その基準が対象業務を正しく表現しているかを判断する能力の相対的重要性が上がる。

検証器を置けば、AI は「書いて終わる」状態から「書いて、試して、直して、合格するまで進む」状態へ移れる。しかし、何に合格すべきかは検証器の外側で決めなければならない。この境界があるため、AI の自律化は人間の判断を消すのではなく、人間が判断する場所を変える。

この分業は、Claude Code の実利用データでも具体的に観察されている。実行上の判断と計画上の判断が同じ割合で AI へ移っているわけではなく、AI が局所的な実行を引き受ける一方、人間は目的、計画、介入条件といった上流の判断へ多く残っている。

9. AI が実行を引き受けるほど、人間の判断は上流へ移る

9.1 自律性が上がると、人間は一手ずつ承認しなくなる

AI エージェントが検索、編集、テスト、ブラウザ操作を自分で選べるようになると、人間が一操作ごとに許可を出す必要は減る。ファイルを読むたびに確認し、コマンドを実行するたびに承認し、テスト失敗のたびに次の手順を指示する形では、エージェントが高速に動けても、人間の応答速度が処理全体の上限になる。

そのため、利用経験が増えるにつれて、すべての操作を逐次承認する運用から、一定範囲をまとめて任せる運用へ移ることは自然である。ただし、承認回数が減ることと、人間が監督しなくなることは同じではない。

Anthropic が Claude Code と公開 API における数百万件の人間とエージェントのやり取りを分析した研究では、Claude Code の利用経験が多い利用者ほど、自動承認を使う割合が高くなる一方、実行中にエージェントへ割り込む割合も高くなる傾向が報告されている[19]。

この二つは矛盾しない。経験の浅い利用者は、何が起きるか分からないため、一操作ずつ確認する。経験を積んだ利用者は、通常の操作についてはまとめて任せる一方、想定した経路から外れたとき、変更範囲が広がったとき、危険な操作へ進みそうなときにだけ介入する。

監督方法 人間が確認する単位 利点 弱点
逐次承認 検索、編集、コマンド実行など、一操作ごとに確認する。 意図しない操作を早い段階で止めやすい。 操作回数が増えるほど人間の確認待ちが増え、エージェントの処理速度を活かしにくい。
範囲承認 あらかじめ許可した作業範囲の中では複数操作を任せる。 通常経路では人間を待たずに作業を継続できる。 許可範囲の設計が粗いと、一回の誤判断が複数操作へ連鎖する。
例外介入 想定外の状態、権限境界、仕様判断が必要な場面だけ人間が入る。 通常処理を自動化しながら、重要判断を人間側へ残せる。 どの状態を例外として検知するかを事前に設計する必要がある。

この変化を「人間が AI を信用するようになった」とだけ説明すると粗い。実際には、人間が確認する粒度が変わっている。操作そのものを見る頻度は減り、その代わりに、どの範囲を任せてよいか、どの条件で止めるかという上位の判断が重要になる。

9.2 計画と実行では、AI へ移っている判断の割合が違う

人間の判断がどこへ残るかをさらに具体的に見る材料として、Anthropic による約 40 万件の Claude Code セッション分析がある[20]。この研究では、セッション中に現れる意味のある判断を、何を作るか、どの方針を選ぶかといった計画上の判断と、どのファイルを編集するか、どのコマンドを実行するかといった実行上の判断に分けて分析している。

その結果、人間は計画上の判断のおよそ 70% を担う一方、実行上の判断ではおよそ 20% を担っていた[20]。言い換えると、実際の操作手順は AI 側へ多く移っているが、何を達成するのか、どの方針を採るのかという判断は人間側に多く残っている。

この比率をそのまますべての AI 利用へ当てはめることはできない。Claude Code という特定製品の利用データであり、対象もソフトウェア開発である。さらに、利用者がどの種類の仕事を Claude Code へ持ち込んだかによって、計画と実行の比率は変わり得る。

それでも、この観察は「AI に任せるほど、すべての判断が同じ割合で AI へ移る」という見方を支持しない。むしろ、実行判断の方が先に機械へ移り、目的設定や計画判断は人間側に残る非対称な分業が現れている。

判断の種類 具体例 AI へ移しやすい理由 人間側に残りやすい理由
計画 何を作るか、どの要求を優先するか、どこまで変更するかを決める。 既存仕様や明示条件から候補を整理することはできる。 複数の要求が衝突した場合の優先順位、事業上の意図、許容リスクを含む。
探索 どのファイルを読み、どの検索語を使うかを決める。 現在状態と目的から局所的な次操作を選びやすい。 探索範囲そのものを変える必要がある場合は上位判断が必要になる。
実装 どの関数を変更し、どのテストを追加するかを決める。 既存コード、規約、テストから具体的方法を組み立てられる。 仕様に複数の妥当な実装がある場合、将来方針との整合を決める必要がある。
評価 どの検証を実行し、結果を合格とみなすかを決める。 定義済みのテストや assertion は自動実行できる。 その検証条件で要求を十分に表現しているかは別の判断になる。

AI が実行を引き受けるということは、人間が仕事から消えることではない。人間が担当していた判断のうち、現在状態と明示条件から局所的に決められる部分が先に機械へ移る。その結果、人間の役割は、個々の操作よりも、目的、制約、優先順位、完了条件を決める側へ集まりやすくなる。

9.3 専門知識が残るのは、AI がコードを書けないからではない

同じ約 40 万件のセッション分析では、対象領域に関する専門知識が高いセッションほど成功率が高い傾向も報告されている[20]。この結果は、AI が実装手順を多く引き受ける状況でも、利用者側の専門性が無関係になっていないことを示す。

専門知識の役割を、「AI が書けないコードを人間が代わりに書くこと」とだけ考えると、この結果を説明しにくい。エージェントがコード生成、検索、テスト実行を自分で進められる場合でも、そもそもどの振る舞いが異常か、どの変更が危険か、どの要件が暗黙に守られているかを見抜くには対象領域の知識が必要になる。

たとえば、金融システムで残高計算のコードを変更するとする。AI が既存コードを読み、テストを通る実装を作れても、「営業日をまたぐ処理ではこの値を当日残高として扱ってはいけない」といった業務規則がテストに十分表現されていなければ、専門知識を持つ人間がその条件を追加する必要がある。

同じことは既存システム固有の暗黙知にも当てはまる。「この API は新規機能では使わない」「このテーブルは別システムが直接参照している」「この処理は遅く見えるが監査要件のため削除できない」といった条件は、コードだけから完全には読み取れない場合がある。

AI が実装作業を高速化すると、人間の専門知識は下流のタイピングより、上流の条件設定と例外判断へ使われるようになる。専門性の価値がなくなるのではなく、使われる位置が変わる。

9.4 複雑な仕事では、最初に全部説明するより途中で知識を追加する方がよい場合がある

実際の開発者と AI エージェントの協働を観察した別の研究では、19 人の開発者が、自分が過去に貢献したリポジトリに存在する 33 件の未解決課題へ取り組んだ[21]。参加者は、単純な未知のリポジトリではなく、自分自身が文脈を知っているコードベースを対象にしている。

研究では、問題全体を一度にエージェントへ渡す進め方より、課題を段階的に解き、途中の出力を見ながら人間が追加情報を与える進め方の方が成功しやすい傾向が観察された[21]。

この差が生じる理由の一つは、複雑な実務課題では、開始時点で必要な情報をすべて列挙すること自体が難しいからである。人間も、AI がどのファイルを読み、どの仮説を立て、どこで失敗するかを見るまで、どの暗黙知を補足すべきか分からない場合がある。

たとえば、AI がある API を変更しようとした段階で初めて、人間が「その API は外部顧客も使っているので互換性を壊せない」と気付くかもしれない。別の実装案を出した時点で、「その方法は過去に性能問題が出たため採用しない」というリポジトリ固有の経緯を補足する場合もある。

進め方 開始時に必要な情報 途中で起きること 弱点
一括委任 要求、制約、暗黙知、禁止事項をできるだけ最初にまとめて渡す。 エージェントが最後まで一つの計画で進む。 開始時に思い出せなかった条件や、実行結果を見て初めて分かる条件を反映しにくい。
段階的協働 現在の段階で必要な目的と制約を渡す。 途中結果を見て、必要な専門知識、制約、方針修正を追加する。 人間が一定の節目で結果を確認し、必要な知識を投入する必要がある。

途中結果を見て必要な知識を追加する進め方は、第 4 章で扱ったコンテキスト設計にも対応する。最初にすべての情報を入れるのではなく、必要になった時点で高い関連性を持つ情報を追加する。人間の専門知識も、エージェントの実行結果によって必要性が明らかになった時点で投入できる。

9.5 人間が決めるのは「次に何を打つか」から「何を任せてよいか」へ変わる

既稿「AI に任せる前に、人間が残すべき判断」では、AI が出力を作る速度が上がるほど、人間には問いの切り方、判断軸、優先順位、任せない領域を定める役割が残ると論じた[22]。本章で見た実利用データを重ねると、この移動をより具体的に分解できる。

従来、人間が自分で開発していた場合、「次に grep する」「この関数を編集する」「このテストを実行する」といった局所判断まで人間が担っていた。AI エージェントでは、その部分を現在状態からモデル自身が選べる。すると、人間が毎回決める必要があるのは、操作そのものではなく、その操作をどの範囲で許すかになる。

たとえば、「このリポジトリ内でテスト修正まで行ってよいが、データベーススキーマ変更は提案だけにする」「既存 API の外部仕様は変更しない」「本番環境への操作は行わない」といった境界である。この境界が決まっていれば、内部の検索、編集、テストは AI に広く任せられる。

判断の位置は次のように移る。

従来人間が行っていた判断 AI へ移しやすい部分 人間が新たに明示する必要がある境界
次に何を検索するか 現在の問題文とコードから検索語や候補ファイルを選ぶ。 検索してよいリポジトリ、データ、秘密情報の範囲を決める。
どこを編集するか 原因候補に基づいて具体的な変更箇所を選ぶ。 変更してよいディレクトリ、設定、外部仕様の範囲を決める。
どのテストを回すか 変更内容に応じて関連テストや回帰テストを選ぶ。 何を通過すれば完了とするか、最低限必要な検証水準を決める。
失敗時にどうするか エラーを読んで再試行や別案を選ぶ。 何回まで再試行を許し、どの失敗を人間へ返すかを決める。

AI に操作判断を渡すほど、人間は「どの操作をするか」より「どの操作まで AI に決めさせてよいか」を設計する側へ移る。これは単なる権限設定ではない。仕事の目的、失敗したときの損失、変更の可逆性によって、適切な境界が変わる。

9.6 任せられる範囲は、失敗したときの損失によって変わる

同じ操作能力を持つ AI でも、どの仕事まで自律的に任せてよいかは、その操作が失敗した場合の帰結によって変わる。ローカルのテストコードを書き換えることと、本番データを削除することでは、誤判断一回あたりの損失が違う。

変更が簡単に取り消せる作業なら、AI に広い裁量を与え、テスト失敗から自動修正させる運用が取りやすい。Git 管理されたコード変更なら、差分を確認し、問題があれば戻せる。一方、外部へのメール送信、課金、データ削除、公開環境への変更などは、実行後に完全には戻せない場合がある。

この違いによって、人間への返却条件も変わる。可逆的なローカル変更では「テストが一定回数失敗したら返す」でよいかもしれない。不可逆な操作では、操作前に人間承認を要求する方が合理的な場合がある。

操作の性質 例 AI へ渡しやすい裁量 人間介入を置く位置
可逆性が高い ローカルコード変更、テスト追加、作業ブランチ上のコミットを行う。 複数回の試行錯誤まで自動化しやすい。 最終レビューやマージ前に置ける。
限定的に可逆 共有開発環境の設定変更や外部 API への書き込みを行う。 対象範囲と復旧方法を限定すれば一部を任せられる。 影響範囲が広がる操作の前に置く。
不可逆性が高い 本番データ削除、外部送信、課金確定などを行う。 提案や事前準備までに限定する方が安全な場合がある。 実行直前に明示的な承認を置く。

人間と AI の境界は、モデルの賢さだけで決められない。対象操作の可逆性、損失の大きさ、検証可能性、監査可能性によって、任せられる範囲が変わる。自律性は一つの数値ではなく、仕事ごとに異なる権限配置になる。

9.7 Devin と Claude Code の違いも、判断権の配置として読める

既稿「Devin と Claude Code の違いは、作業の任せ方にある」では、AI エージェントを比較するときに、モデル性能だけでなく、どの環境で動くか、どの権限を持つか、どの単位でタスクを渡すか、どこで人間が介入するかを見る必要を整理した[23]。

この観点は、本章の議論と直接つながる。同じようにコードを書けるモデルでも、独立した環境の中で長時間タスクをまとめて任せる設計と、人間が手元の開発環境で随時対話しながら進める設計では、人間と AI の判断境界が違う。

違いは、どちらのモデルが高度かという一軸では表せない。タスクの粒度、操作権限、環境隔離、検証方法、人間介入の頻度によって、AI が担う判断の種類が変わる。

そのため、AI エージェントを導入するときには、「どの製品を使うか」より先に、「どの判断まで AI に渡したいか」を定めた方が設計しやすい。局所的なコード修正を任せたいのか、Issue 単位で完了まで任せたいのか、実環境を操作させたいのかによって、必要なツール、状態管理、検証器、人間承認の位置が変わる。

9.8 人間への返却条件は、エージェントの失敗処理として設計できる

AI に多くを任せる場合でも、すべての状況を AI だけで解決させる必要はない。むしろ、どの条件になったら自律処理をやめ、人間へ返すかを明示した方が、閉ループ全体を設計しやすい。

たとえば、同じテストが 3 回連続で失敗した場合、要求が互いに矛盾している場合、変更対象が許可範囲外へ広がる場合、データ破壊を伴う操作が必要になった場合などを返却条件にできる。

返却条件 AI 側で起きていること 人間に求められる判断
同じ失敗を繰り返す 局所的な修正では解決できず、原因仮説が収束していない。 探索範囲や前提条件を変更するかを決める。
要求が矛盾する 二つの条件を同時には満たせない。 どちらの要求を優先するかを決める。
権限境界を越える必要がある 許可された範囲だけでは仕事を完了できない。 権限を拡張するか、別の方法を選ぶかを決める。
不可逆な操作が必要 実行後に簡単には戻せない変更へ進もうとしている。 損失と必要性を評価し、実行可否を決める。

人間への返却を「AI が失敗したときの例外」とだけ考える必要はない。返却条件そのものを通常フローの一部として設計できる。AI が得意な範囲では自動的に進み、判断の種類が変わった時点で人間へ戻す。この返却設計なら、自律性と人間統制を二者択一にしなくてよい。

9.9 人間と AI の境界は、判断権の配置として設計する

ここまでの事例をまとめると、人間と AI の関係を「どちらが賢いか」で比較するだけでは不十分である。実際の仕事には、目的を決める判断、情報を集める判断、実装方法を選ぶ判断、結果を評価する判断、危険時に止める判断が別々に存在する。

AI エージェントは、このうち現在状態と明示された条件から選べる局所判断を広く引き受けられるようになっている。一方、要求間の優先順位、検証基準の妥当性、許容リスク、不可逆操作の承認といった判断は、同じ形では移っていない。

この違いを判断権の配置として整理すると、AI エージェント導入時に決めるべき項目が具体化する。

判断権 設計時に決めること
目的設定 何を達成する仕事なのか、何を変更対象とするのかを決める。
観測権限 どのコード、データ、ログ、外部サービスを参照してよいかを決める。
操作権限 どのファイル、環境、外部システムまで変更してよいかを決める。
完了判定 どの検証条件を満たせば作業を確定してよいかを決める。
例外処理 どの失敗、矛盾、リスクが発生したら人間へ返すかを決める。

AI が担える操作数が増えるほど、この配置は重要になる。一操作ずつ人間が選んでいた時代には、判断境界を明文化しなくても、人間自身がその都度判断していた。エージェントが数十、数百の操作をまとめて行うなら、その暗黙の判断を、権限、検証、返却条件としてシステム側へ移す必要がある。

9.10 AI が実行を高速化すると、人間の判断一回あたりの影響範囲が大きくなる

AI が実装や検証を高速化すると、人間が直接行う操作数は減る。しかし、人間が一度決めた目的、完了条件、権限境界が、その後の多数の自動操作へ共通して適用されるようになる。

たとえば、人間が「関連する全テストが通れば完了」と一度定義すると、エージェントはその条件に従って数十回の修正とテストを自動的に行える。完了条件が適切なら、人間の判断一回で多くの実行を安全に進められる。完了条件が不足していれば、その不足も全自動処理へ共通して適用される。

同じことは権限にも当てはまる。「このディレクトリ以下は自由に変更してよい」という判断を一度与えれば、その後の多数の編集を確認しなくて済む。一方、その範囲に本来触れてはいけない生成物や設定が含まれていれば、誤判断の影響も広がる。

AI が高速になるほど、人間の判断が不要になるのではなく、一つの判断が支配する自動処理の範囲が広がる。そのため、人間側の仕事は局所的な操作から、境界条件や評価軸の設計へ比重を移す。

ここまでで、観測、操作、コンテキスト、外部状態、検証、人間への返却条件が、別々の便利機能ではなく同じ仕事の循環を構成することが見えてきた。最後に、これらをモデルを含む一つの閉ループとしてまとめる。

10. 設計するのは AI ではなく、AI が仕事を完了する閉ループである

10.1 モデルは閉ループの中心にいるが、閉ループそのものではない

ここまで扱ってきた要素を並べると、AI エージェントの仕事のかなりの部分がモデルの外側で成立していることが分かる。SWE-agent の ACI は、同じ基盤モデルに対して、ファイルをどう見せ、検索結果をどう返し、編集をどの単位で実行させるかを変えた[4]。コンテキスト設計は、利用可能な情報のうち、現在の判断に何を参加させるかを制御する[5]。長時間エージェントでは、セッションをまたいで作業を継続するために、Git、進捗情報、初期化手順などをモデルの外へ残す[8]。

検証もモデルの外にある。テスト、Playwright の assertion、ARIA スナップショット、画像比較は、モデルが「できたと思う」こととは別に、実環境が定めた条件を満たしたかを判定する。さらに、要求が矛盾する場合、権限を広げる必要がある場合、不可逆な操作が必要になる場合には、人間へ判断を返す。モデルはこの循環の中で推論と行動選択を担うが、何を見るか、何を変更できるか、何を成功と呼ぶかまで単独で決めているわけではない。

この区別は、AI エージェントを「強いモデルにツールを付けたもの」と理解すると見えにくい。ツールは付属機能ではなく観測と操作の境界を決め、コンテキスト管理は推論時に利用できる情報を決め、検証器は作業を確定できる条件を決める。それぞれがモデルの判断可能範囲を外側から規定している。

モデルを高性能化すれば、この循環の中で選べる行動や解ける問題は増える。しかし、閉ループを構成する別の要素が不要になるわけではない。モデルが推論主体であることと、システム全体の能力がモデルだけで決まることは別である。

10.2 仕事は「生成して終わる」のではなく、状態を次へ進める処理として考える

AI にコードを書かせるという表現では、仕事の成果を生成物として捉えやすい。実際の開発では、コードが生成されたことより、プロジェクトの状態が「未実装」から「実装済み」、「未検証」から「検証済み」へ移ったことの方が後続作業には重要になる。

たとえば、ある API の修正コードが生成されただけなら、その状態はまだ候補実装である。ビルドを通過すれば構文や型について一段進む。関連テストを通過すれば、記述された機能条件について確認済みになる。実際の利用経路を確認して初めて、後続機能がその API を前提にしてよい状態になる場合もある。

この見方では、一回のエージェント実行は成果物を作る処理ではなく、プロジェクト状態を一段進める処理になる。

開始状態 エージェントの仕事 終了状態
原因不明 検索、読解、再現試験を行い、原因仮説を検証する。 修正対象と再現条件が特定されている。
修正対象特定済み コードを変更し、変更結果を再観測する。 候補実装が存在する。
候補実装あり ビルド、テスト、実操作を行う。 検証結果が得られている。
検証失敗 失敗情報から原因候補を更新して再修正する。 新しい候補実装へ移る。
完了条件通過 検証結果と現在状態を外部へ確定する。 後続作業が依存できる状態になる。

この状態遷移として捉えると、第 6 章で扱った外部状態の意味も明確になる。長時間作業で次のセッションへ渡したいのは、過去に生成した文章のすべてではない。プロジェクトが現在どの状態にあり、次にどの状態へ移すべきかという情報である。

AI が高速にコードを生成できても、候補実装を検証済み状態へ進められなければ、プロジェクトには未確定な成果物だけが高速に増える。仕事の速度を測るなら、生成量ではなく、後続作業が利用できる確定状態へどれだけ進められたかを見る必要がある。

この状態遷移は一方向ではない。検証が失敗すれば、その結果を新しい観測として原因候補を更新し、候補実装へ戻る。閉ループの強さは最初から誤らないことだけではなく、失敗を次の判断材料へ変えて検証済み状態へ戻れることにもある。

10.3 モデルを強くすることと、閉ループを改善することは代替関係ではない

SWE-agent の研究から、「環境の方がモデルより重要である」と結論することはできない。研究で確認されたのは、基盤モデルを固定した状態でも、ACI の設計を変えることで SWE-bench Lite の解決率が変化したことだった[4]。これはモデル以外にも独立して効く設計変数が存在することを示しているのであって、モデル性能の重要性を否定するものではない。

より強いモデルなら、曖昧な検索結果から有力候補を見つける能力も、長いログから原因を探す能力も、失敗から修正案を作る能力も高くなる可能性がある。一方で、検索結果がそもそも取得できなければ、その能力は使えない。現在とは異なる古いファイルだけを渡せば、より高度な推論を古い前提に対して行うことになる。

検証でも同じである。モデルが強くなれば、テスト失敗から正しい原因を推測できる確率は上がり得る。しかし、誤ったテストを成功条件として与えれば、強いモデルほど効率よくその条件を満たす実装へ到達する可能性がある。

モデル改善と閉ループ改善は、同じ問題に対する競合案ではない。

改善対象 主に改善するもの それだけでは解決しないもの
モデル 推論、コード生成、計画、ツール選択、失敗解釈などの能力を高める。 存在しない観測経路、誤った権限設定、間違った検証基準そのものは自動的には直らない。
観測・ツール 必要な現在状態へ到達し、適切な粒度で環境へ作用できるようにする。 取得した情報を正しく解釈する推論能力までは保証しない。
状態管理 長時間作業の現在位置と確定事項を維持する。 保存した状態が正しいことまでは保証しない。
検証 明示された完了条件を機械的に確認する。 完了条件そのものが要求を正しく表現していることまでは保証しない。

システム全体の性能を上げるには、それぞれの弱点がどこにあるかを切り分ける必要がある。エージェントが失敗したとき、常にモデルを交換するのではなく、必要な情報を取得できなかったのか、コンテキストに古い状態が残ったのか、ツールの失敗理由が不明確だったのか、完了条件そのものが不足していたのかを調べる必要がある。

10.4 AI の性能不足に見えるものの一部は、システム境界の設計不足である

この切り分けは実務上重要である。たとえば、エージェントが同じファイルを何度も読み直している場合、「モデルが理解力不足だ」と見えるかもしれない。しかし、ファイル閲覧ツールが変更後の周辺コードを返さず、毎回全文を再取得しなければ現在状態を確認できない設計なら、原因はモデルだけにない。

大量の無関係な検索結果から誤ったファイルを選ぶ場合も同じである。検索結果を 1,000 件そのまま返しているなら、モデルは検索と同時に候補選別まで行わなければならない。検索側で範囲指定や絞り込みができれば、同じモデルでも異なる判断条件を与えられる。

長時間タスクで過去の作業を繰り返す場合も、モデルの記憶能力だけが原因とは限らない。前セッションの確定事項、未確認事項、検証結果がプロジェクト側へ残っていなければ、新しいセッションは再調査する以外に現在位置を知る方法がない。

観察される症状 モデル側の可能性 システム側で確認すべきこと
同じ調査を繰り返す 過去の結論を十分に利用できていない可能性がある。 調査済み事項や現在状態が外部へ記録され、再取得可能になっているかを確認する。
検索対象を誤る 問題文から適切な候補を推論できていない可能性がある。 検索結果が多すぎないか、絞り込み手段や関連情報が十分に返っているかを確認する。
編集後に壊れた状態へ進む 変更内容の理解を誤っている可能性がある。 編集直後の再観測、構文確認、局所検証が閉ループに入っているかを確認する。
完成を早く宣言する 要求の解釈が浅い可能性がある。 終了条件が自己評価ではなく外部検証として定義されているかを確認する。

この診断ができれば、「もっと賢いモデルへ変える」という一種類の改善策だけに依存しなくて済む。モデル交換で改善する問題と、インターフェース、状態、検証を直した方が改善する問題を分けられる。

10.5 企業で AI を使うときも、同じ構造が業務システムの側へ広がる

既稿「生成 AI の競争軸は、モデルから業務実装へ移る」では、企業で生成 AI を使う価値が、モデル単体の能力だけでなく、社内データ、権限、既存システム、監査、人間確認の手順へどう接続するかによって左右されると論じた[24]。

本稿で扱ってきたエージェントの構造は、その議論を一つの仕事の実行単位まで分解したものになる。企業全体でいう「社内データへの接続」は、個々のエージェントでは観測経路になる。「既存システムとの連携」は操作ツールになる。「監査」は操作履歴や外部状態になる。「人間確認」は完了条件や返却条件として実装される。

業務実装上の要素 エージェント内部で対応するもの
社内データへの接続 どの情報を観測できるかという取得経路と権限になる。
既存業務システムとの連携 どの操作を実行できるかというツール境界になる。
業務規則 プロンプト、プロジェクト指示、完了条件として表現される。
監査 操作履歴、変更差分、検証結果、確定状態として残る。
承認手順 自律実行を続ける条件と、人間へ返却する条件として表現される。

この対応を見ると、AI エージェントの導入は既存業務の外に AI を一つ置くことではない。既存業務で人間が暗黙に行っていた情報取得、操作権限、確認、引き継ぎ、例外判断を、エージェントが扱える構造へ変換する作業になる。

人間の担当者なら、「この数字がおかしいから元データを見る」「この変更は金額が大きいので上司へ確認する」「この状態なら次工程へ進めない」と経験的に判断していたかもしれない。エージェントへ仕事を移すなら、その判断のどこを自動化し、どこを条件として明文化し、どこを人間へ戻すかを設計する必要がある。

この意味で、エージェントの設計対象は開始時のプロンプトだけではない。目的や制約を言語化する役割は残るが、実行中に何を観測し、どの情報を残し、何を操作し、結果をどう確かめるかは、プロンプトの外側にある実行環境の設計によって決まる。

10.6 AI が強くなるほど、システム設計の影響範囲も広がる

モデル能力が向上すると、システム設計の重要性が下がるように見える。しかし、より多くの操作を自律的に任せられるようになるほど、一つの設定や判断基準が影響する操作数も増える。

一回のコード補完しか行わない AI なら、誤ったコンテキストの影響は一つの出力に留まりやすい。数時間動くエージェントが誤った前提を持てば、その前提に基づいて複数ファイルを変更し、テストを追加し、外部サービスを操作する可能性がある。

同様に、誤った完了条件を一回の人間作業に使えば一件の誤判定で済むかもしれない。複数のエージェントが同じ検証器を使って自動的に変更を処理するなら、一つの基準誤りが多数の成果物へ共通して反映される。

モデル能力の向上によって増えるのは、成功時の処理能力だけではない。一つの観測設計、権限設定、検証基準が支配する自動処理の範囲も増える。そのため、強いモデルほど周辺設計が不要になるのではなく、周辺設計の失敗が持つ影響も大きくなる。

自律性を高めることは、仕事に含まれる判断をすべて AI へ渡すことでもない。検索、修正、再試行のような局所判断を任せる一方、目的、許容範囲、完了条件、不可逆な操作の承認は人間や組織に残せる。設計すべきなのは、閉ループのどこまでを機械で閉じ、どこで人間へ返すかという境界である。

10.7 AI の能力を測る単位は、モデルから仕事を完了するシステムへ広げる必要がある

本稿の出発点は、AI が正しい文章やコードを生成できることと、現実の仕事を最後まで完了できることは同じではないという点だった。ソフトウェア開発では、コードを生成した後に初めてテスト結果が生じ、ブラウザを操作した後に初めて画面状態が分かる。仕事を進めること自体が次の判断材料を生むため、入力から出力への一方向処理だけでは完了まで説明できない。

SWE-agent は、同じ基盤モデルでも ACI を変えるとソフトウェア工学タスクの成績が変わることを示した[4]。さらに、ファイル全文や全履歴を追加することが標準構成を上回らなかったことから、情報量そのものではなく、現在の判断にどの情報を参加させるかが問題になる。長時間作業では、会話履歴ではなく現在状態を外部へ残さなければ、次のセッションが作業位置を復元できない。検証器を置けば AI 自身が失敗を発見して再試行できるが、その検証器の条件が誤っていれば、誤った条件への最適化も自動化される。

これらは別々の注意事項ではない。一つの閉ループの異なる場所に現れる制約である。

閉ループの段階 必要な設計 最終的に防いでいる失敗
目的 達成条件、制約、優先順位を定める。 動作はしていても本来とは異なる問題を解くことを防ぐ。
観測 現在状態へ正確に到達できる経路を作る。 古い情報や推測だけで判断することを防ぐ。
判断 現在必要な情報をコンテキストへ集める。 無関係な情報や古い状態による判断の混線を減らす。
操作 仕事に必要な粒度と権限で環境を変更できるようにする。 意図を実行できないことや、必要以上の範囲を変更することを防ぐ。
検証 操作結果を観測可能な完了条件と比較する。 途中状態を完成と誤認することを防ぐ。
状態確定 検証結果と現在位置を外部へ残す。 次のセッションが未確定な成果を完成済みと扱うことを防ぐ。
人間への返却 機械で閉じられない判断の境界を定める。 仕様、権限、許容リスクまで AI が暗黙に決めることを防ぐ。

AI エージェントの能力を評価するとき、モデルの推論性能だけを見ると、この循環の一部分しか測れない。実際にどこまで仕事を任せられるかは、モデルに加えて、観測、ツール、コンテキスト、外部状態、検証、権限、人間介入の設計によって決まる。

だからといって、評価対象をモデルから環境へ置き換える必要もない。モデルが弱ければ、正しい情報を渡しても原因を推論できない。環境が弱ければ、モデルが強くても現在状態を取得できない。検証器が弱ければ、正しい変更と途中状態を区別できない。どれか一つを万能な原因にせず、仕事を完了する経路全体として見る必要がある。

AI に仕事を任せるために設計する対象は、AI への指示文だけではなくなった。AI が何を観測し、どの情報から判断し、何を変更し、結果をどう確かめ、どの状態を次へ渡し、どの判断で人間へ戻るか。その循環を閉じることで、モデルの生成能力は継続的な仕事遂行能力へ変わる。

AI エージェントの実用能力を決める単位は、モデル単体ではなく、モデルを含んだ仕事の閉ループである。

参考文献

  1. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao, ReAct: Synergizing Reasoning and Acting in Language Models（2022-10-06）. https://arxiv.org/abs/2210.03629
  2. Anthropic, Building effective agents（2024-12-19）. https://www.anthropic.com/engineering/building-effective-agents
  3. Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan, SWE-bench: Can Language Models Resolve Real-World GitHub Issues?（2023-10-10）. https://arxiv.org/abs/2310.06770
  4. John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, Ofir Press, SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering（NeurIPS 2024）. https://proceedings.neurips.cc/paper_files/paper/2024/hash/5a7c947568c1b1328ccc5230172e1e7c-Abstract-Conference.html
  5. Anthropic, Effective context engineering for AI agents（2025-09-29）. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  6. Anthropic, Writing effective tools for agents — with agents（2025-09-11）. https://www.anthropic.com/engineering/writing-tools-for-agents
  7. Playwright, Playwright MCP（2026-08-19 閲覧）. https://playwright.dev/docs/getting-started-mcp
  8. Anthropic, Effective harnesses for long-running agents（2025-11-26）. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
  9. Thomas Kwa et al., Measuring AI Ability to Complete Long Software Tasks（2025-03-18、v4 2026-07-10）. https://arxiv.org/abs/2503.14499
  10. Anthropic, How Claude remembers your project（2026-08-19 閲覧）. https://code.claude.com/docs/en/memory
  11. id774, AI による大規模開発では、未確定な状態を一件ずつ閉じる（2026-08-15）. https://blog.id774.net/entry/2026/08/15/5503/
  12. Anthropic, Harness design for long-running application development（2026-03-24）. https://www.anthropic.com/engineering/harness-design-long-running-apps
  13. Anthropic, Best practices for Claude Code（2026-08-19 閲覧）. https://code.claude.com/docs/en/best-practices
  14. Playwright, Assertions（2026-08-19 閲覧）. https://playwright.dev/docs/test-assertions
  15. Playwright, Snapshot testing（2026-08-19 閲覧）. https://playwright.dev/docs/aria-snapshots
  16. Playwright, Visual comparisons（2026-08-19 閲覧）. https://playwright.dev/docs/test-snapshots
  17. OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities（2026-02-23）. https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
  18. Playwright, Accessibility testing（2026-08-19 閲覧）. https://playwright.dev/docs/accessibility-testing
  19. Anthropic, Measuring AI agent autonomy in practice（2026-02-18）. https://www.anthropic.com/research/measuring-agent-autonomy
  20. Anthropic, Agentic coding and persistent returns to expertise（2026-06-16）. https://www.anthropic.com/research/claude-code-expertise
  21. Aayush Kumar, Yasharth Bajpai, Sumit Gulwani, Gustavo Soares, Emerson Murphy-Hill, Why AI Agents Still Need You: Findings from Developer-Agent Collaborations in the Wild（2025-06-14）. https://arxiv.org/abs/2506.12347
  22. id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
  23. id774, Devin と Claude Code の違いは、作業の任せ方にある（2026-07-09）. https://blog.id774.net/entry/2026/07/09/4967/
  24. id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/