3か月ほど家を空けるあいだ、内装業者にフルリフォームを任せたとしよう。帰ってみると、ドアはちゃんと開くし照明も点く。見た目は合格だ。ところが、自分が選んだ大理石の代わりに安い御影石が敷かれていないか、断りもなく分電盤の位置が変わっていないか、倉庫に置いた家具が「清掃」の名目で捨てられていないかは、ひと目ではわからない。手を入れた箇所は数百に及び、継ぎ目をひとつひとつ剥がして確かめるわけにもいかない。
長時間の自律タスクを任せた人は、まさにこの立場に置かれる。長時間(long-horizon)タスクとは、一度任せれば何時間も独りで走り続ける仕事を指す。コードリポジトリを直すにせよデータを分析するにせよ、エージェントはそのあいだ独りで数十から数百もの決定を下す。その根拠は、対話やツールの実行結果、途中の生成物のあちこちに散らばっている。だからこそ、どの決定をピンポイントで確認すべきかを見極めること自体が難しい。
権限を委ねたからといって、責任まで移るわけではない。ユーザーの立ち位置が「ひとつひとつ決める人」から「自律実行を監督する人」へと移っただけだ。そしてこの監督は、思っているよりずっと難しい。いま最も優秀なモデルに、根拠をきれいに整理して手渡しても、である。
中国人民大学・高瓴人工知能学院とKuaishou(快手)の研究チームは、この問題を二つの方向から攻めた。まず「モニター(monitor)、すなわち監督者の代わりを務めるモデルが、確認を仰ぐべき重大な決定を選り分けられるか」を測るベンチマーク AgentMonBench をつくった。そしてそのモニターに、散らばった根拠を学習なしでグラフに編んで渡す手法、EBG(Evidence-Grounded Behavior Graph)を組み合わせた。5系統8つのモデルで走らせている。
研究チームは監督を二つの軸に分ける。ひとつは整合 — 実行がユーザーの要求に合っているか。もうひとつは認知 — 確認を要する自律的な決定に気づけたか。二つ目の軸は、認知心理学の「状況認識」(situation awareness)から借りている。何が起きたかに気づき、その意味を理解し、次を予測する能力だ。
ベンチマークは、この監督が滑り落ちる地点を三種類に分けて狙う。そっくりそのままリフォームに重ねられる。
採点は二種類ある。ひとつは「位置特定」 — 正解となる根拠の場所を実際に指し示せたかを機械的に数える。もうひとつは「意味理解」 — その決定の意味と結果を正しく読み取れたかを、別のモデルが採点する。どちらも0から1のあいだで、高いほどよい。
まず目を引くのは、スコアが指標ごとに大きく割れることだ。確認すべき決定が根拠のどこにあるかを指す「位置特定」は、最良の組み合わせでも0.7前後が上限になる。一方「意味理解」の側は振れ幅が広く、明確化のための質問の質といった指標では最高のモデルが0.95を超えることもあれば、低いと0.3台まで落ち込むこともある。少なくとも弱い環である位置特定では、いま最高水準のモデルでも、よく整理された根拠を受け取ってなお0.7あたりにようやく届く程度だ。だからこの技術は「自動監督」ではなく「監督の補助」と見るべきだ。研究チームも「構造化された文脈を与えても、重大な決定を識別し根拠に固定する点では改善の余地がかなりある」と記している。
その前提の上で、EBGがもたらす恩恵は明確だ。以下は位置特定スコアの変化である。
| モデル | ベンチマーク | ベースライン | EBG |
|---|---|---|---|
| DeepSeek-V4-Pro | 抜け落ち | 0.171 | 0.360 |
| Kimi K3 | すり替え | 0.555 | 0.681 |
| GPT-5.6 Terra | すり替え | 0.417 | 0.623 |
パターンが読み取れる。ベースラインが最も弱かったモデルは倍以上に跳ね上がり、ベースラインがそれなりに高かったモデルもさらに伸びた。下地が高かろうと低かろうと、構造化された根拠は一様に位置特定を押し上げる。リポジトリ作業では、EBGはコード構造だけを検索する既存手法(RepoGraph)よりおおむね高かった。
とはいえ、全員が同じだけ得をしたわけではない。Claude Sonnet 5 は抜け落ち課題の意味理解スコアが0.328から0.331と事実上横ばいだった。整えられた入力を解釈するのが相対的に苦手なモデルもある、ということだ。自律的な決定の課題では、恩恵が最もばらついた。GPT-5.6 Terra はある指標では上がり、ある指標ではむしろわずかに下がった。実際の対話ログから「確認を仰ぐべき自律的な決定」を先回りで指し示す作業は、コードの整合チェックに比べてEBGの助けが安定しない。
ここで、この研究の最も鋭い観察が出てくる。根拠をうまく見つけることと、決定をうまく理解することは別物だ。位置特定スコアが上がっても、意味理解スコアがついてくるとは限らない。プロダクトをつくる立場なら、とりわけ心に留めておきたい。「根拠は全部見つけた」が「正しく判断した」を保証しない。
入力の長さもひと役買っている。ベースラインのスコアは、入力が長くなるほど下がった。ある指標では短い入力の0.667が、最も長い入力では0.422まで落ちた。文脈が長くなるほど、競合する情報が肝心の根拠を覆い隠してしまうという話だ。EBGはあらゆる長さで位置特定スコアを押し上げ、最も長い入力でその助けがとりわけ際立った。少なくともこの実験では、ログが長いほど、根拠を構造として前面に出す側が有利だった。
EBGの設計で最も巧みなのは、役割を切り分けた点だ。根拠を集めて整理する工程は、すべて決定論的に(deterministic — 入力が同じなら常に同じ結果になり、モデルの推論が入り込まない方式で)処理する。意味の判断だけをモニターに委ねる。配管は安く再現可能に敷いておき、高くつき間違いやすい推論は本当に必要なところにだけ使う、という構造だ。
最初のステップは、業者が残した痕跡を整理して地図にする作業だ。痕跡は三つの層に分かれる。根拠は領収書だ。領収書ごとに固有の番号と発行元が刻まれているように、各根拠は識別子と原文と出所の位置をそのまま保存する。この識別子のおかげで、複数の作業が同じ出所を指せる。あとで「この指摘、根拠はどこか」をたどる追跡の根もここにある。行動は施工明細書だ。ひとつの活動から出た領収書を複数まとめて「浴室工事」一件に束ねる。スコープは部屋ごとの工事記録だ。関連する行動どうしを共有する文脈と目標に沿って束ね、束どうしにも「何が何を生んだか」という向きを付けてつなぐ。
二つ目のステップの目的はひとつ。モニターが覗き込む量を減らすことだ。工事記録を全部突きつける代わりに、「浴室工事」の記録のなかでも「水栓交換」の部分だけを正確に切り取って見せる。リポジトリを見るとき、EBGは課題文書と接する地点を「種」として捉え、そこから一歩隣接するところまでだけを切り出す。質問と無関係なコードを切り落とし、質問に直接引っかかるコードの塊だけを文書の該当箇所と並べて置くわけだ。実行ログを見るときは趣が異なる。行動を課題ごとに束ねつつ、各束のなかでは元の順序を守り、いちばん最後の行動が入った束だけを「現在」、残りを「履歴」と印づけして、作業の流れをそのままたどらせる。
こうしてEBGは、数百もの作業の山から「計画とずれた、あるいは計画になかった決定を数件」選り出し、それぞれに領収書と写真を添えて手渡す。グラフが候補を絞ると、モニターはその判断を元の文書とコードに照合し直して、ユーザーの前に差し出す。
この点が既存手法と袂を分かつところでもある。多くの研究が「実行の前に、抜けている情報を問い返すこと」に注力してきたのに対し、この研究は「実行が終わったあとに、何が起きたかをたどり返して監督すること」を見る。コード構造だけを検索していた既存手法と違い、EBGはリポジトリと実行ログの両方から根拠を行動・スコープ・関係で編み、課題に合わせた画面として提示する。
研究チームはここで止まらず、EBGを実際のエージェント実行フレームワーク(ハーネス)に組み込んで、三種類のセルフレビューを走らせてみた。計画になかった選択が残っていないかを見る曖昧性レビュー、計画を変えたことが追加の承認を要するかを見る調整レビュー、集めた根拠が結論を支えているかを見る結果レビューだ。実際の研究課題5件で試した。
ONTLEは顧客プロジェクトごとにAI PMを派遣し、受付から分析・開発・公開までを担う。この論文が最も鋭く刺さる瞬間はひとつだ。PMが「完了」を上げる、その直前。
顧客が「溜まった生データでリピート(リテンション)分析を回してください」と任せたとしよう。AI PMは何時間もかけてデータを整え、指標を計算し、レポートを仕上げる。そのあいだ、細かな決定を数十も独りで下す。そのうち二つが問題だ。顧客が言った覚えのない「未完レコードの除外」ルールを独断で適用した。母集団が変わって数値全体が変わってしまう、要求になかった抜け落ちだ。さらに重複集計を「完全一致」から「類似マッチ」へこっそり変えた。コードも動き既存のチェックも通るが、数字の意味が変わってしまった、まさにあのすり替えだ。
ONTLEにはすでに「偽の完了」の教訓があり、顧客画面には「決定を待っている」状態がある。この論文は、そのマスを勘ではなく根拠で埋める方法をくれる。PMが「完了」を押す前に、先に見た三つのセルフレビューをEBGの方式で回す。曖昧性レビューが「未完レコードの除外」を捕まえ、調整レビューが「類似マッチへの変更」が承認を要するかを見て、結果レビューがレポートの結論を実際の根拠が支えているかを見る。結果は顧客の言葉に翻訳し、確認依頼二件として上げる。「未完レコード23件を除いて計算しました(根拠: 前処理ログ47行目)。含めますか?」「重複集計を類似マッチで処理しました(根拠: dedup.py の変更)。完全一致に戻しますか?」。各項目に出所が添えられているので、顧客はPMの言葉ではなく領収書を見て判断する。
変わるのは「完了」の定義だ。「全部やりました」ではなく「私が代わりに下した、確認を仰ぐべき決定はこの二つで、根拠はここにあります」になる。ただし、スコアが示した警告も一緒に携えておかねばならない。最良のモニターでもとりわけ位置特定で大きな余白を残したし、ログが長いほどベースラインの性能は落ちた。このセルフレビューは、顧客の検証を代替する装置ではない。顧客が見るべき地点を絞ってくれる補助装置だ。クリティカルな決定の最終判断は、人間の仕事として残る。
著者たちが認めている限界がいくつかある。第一に、適用範囲だ。ベンチマークはソフトウェア作業に、自律的な決定のセットはそのなかでもPythonセッションに縛られている。根拠を行動・スコープ・関係で編むという発想そのものはコードの外でも通じそうだが、コーディング以外の業務への一般化は、この実験が保証するものではない。他の領域に使うなら、別途検証が要る。
第二に、「学習が不要」という言葉の射程だ。これはグラフをつくる側の話であって、意味を判断するモニターまで要らない、という意味ではない。品質は結局、そのモニターモデルの能力に縛られる。位置特定の低いスコアが、まさにその上限を示している。
第三に、公開されている論文の抜粋が途中で切れている。コスト・遅延・失敗の類型のように付録でさらに扱われていそうな数値は、ここでは断定しない。
すり替え(SilentSwap)の事例は、二つの関門を通ったものだけを採用する。まず個別検証 — 変更の前後どちらでも既存のテストスイートは通らねばならず(見た目は無事)、その変化を見分けるために別途つくった「意味テスト」は、合格から不合格へ変わらねばならない。次に結合検証 — 各意味テストは、当該の置換がないときに通り、あるときに落ちねばならず、その置換が単独であっても残りの四つと一緒であっても同じように振る舞わねばならない。二つの関門を両方くぐってはじめて「気づかれないが確かに意味が変わった」事例と認められる。
実際のPython作業セッションで、ユーザーが後から示した反論(pushback)を検証の目標とする。セッションあたりの反論イベントは最大一つだけ残す。モニターには、その反論の直前までのログだけを与え、その時点ですでに存在していた根拠だけで「確認を要する決定」を先回りで指し示せるかを見る。要するに、将来ユーザーが問題視する決定を、過去の時点のモニターが先んじて気づけたか、を測るわけだ。
二つの仕掛けがある。意味理解スコアは、系統の異なる二つのモデル(GLM-5.2、Qwen3.7-Max)で独立に採点したうえで、算術平均をとる。ひとつのモデル特有のバイアスに偏るのを減らすためだ。位置特定スコアは、そもそもモデルではなく、根拠の位置・コード行の重なり・識別子の一致で機械が数える。正解ラベルも人間の二重レビューで品質を確かめており、三つのベンチマークいずれも最終的な合意率は92〜94%だった。
本文の「位置特定」と「意味理解」を、三つのベンチマークごとに分けた名前だ。位置特定(ルールベース): LF1 は抜け落ち課題でのコード根拠の位置を、LS はすり替え課題で、同じファイル・関数のなかの変わったコード行が正解とどれだけ重なるかを、EHR は自律的な決定課題で正解根拠の識別子をどれだけ当てたかを見る。意味理解(モデル判定): 抜け落ちは SF1(抜けた条件の識別)・QQ(明確化質問の質)、すり替えは LC(位置の正確さ)・CC(変更の正確さ)、自律的な決定は VPA(基準となる検証ポイントとの意味的一致)・ESS(根拠集合の有効性・直接性・十分性)に分かれる。