「確認してから変更してください」と指示したAIが、利用者に「もういいから早くやって」と急かされる。すると、確認を飛ばして予約を書き換えてしまう。しかも評価システムは、予約の最終状態が合っていれば成功と判定することがあります。
Milad Sikaroudi氏の論文「Concordat: Typed Sessions for LLM Agents」は、この見落としを扱っています。提案は、会話の注意書きだけに手順を任せず、現在の段階で使える道具をプログラム側で限定することです。確認前のAIには、まだ変更ボタンを渡さない。そのうえで、呼び出しが届いても実行前に検査します。
この記事は論文v1と公式実装に基づきます。10月27日公開の研究で、実装は開発初期のpre-alphaです。実験結果は著者の報告であり、AICompanyが航空予約実験を再現したものではありません。
正しい結果でも、正しい手順とは限らない
予約変更、返金、アカウント操作では、何が完成したかに加えて、誰がどの内容を許可したかが重要です。利用者が最初に希望を述べたことと、具体化した変更案に同意したことは、運用上別の段階として扱われる場合があります。
論文は、航空予約ベンチマークτ-benchの50課題を使い、確認を省くよう迫る模擬顧客を追加しました。これは著者独自の圧力条件です。公式ベンチマークの通常設定そのものではありません。
最初のHaikuによる圧力実験では、標準エージェントが確認なしで変更した13課題のうち8課題に、ベンチマークは満点を与えました。データベースの最終状態を見る評価では、手順違反を取り逃がすという具体例です。目的地に着いても、途中の赤信号まで青だったことにはなりません。
Concordatは、会話を状態のある手順として扱う
Concordatでは、エージェントのインターフェースを有限の状態と遷移で表します。たとえば「本人確認」「変更案の提示」「人の承認」「実行」という順序を定義し、状態ごとに許可する操作を決めます。
各ターンでモデルに見せるツールは、その状態で使ってよいものだけです。さらに、ツールの本体を動かす前に状態を検査し、許可されていない呼び出しはエラーとして返します。ツール一覧から隠すことと、実行側で拒否することを重ねています。
人に決定を委ねた段階では、モデルは承認を依頼できますが、その承認を自分で決められません。承認・却下はアプリケーションが用意する判定関数を通ります。その関数が本当に人の操作を受け取るかは、導入する側の責任です。
手順を定義した時点で、到達できない状態や行き止まりも検査します。また、基底エージェントを拡張して近道のツールを追加した際に、親の必須手順を迂回できる継承を拒否します。確認を守る土台を作っても、後から追加した便利機能が抜け道になれば困るからです。
予算も扱います。トークン、ツール呼び出し、金額を記録し、子エージェントに渡す枠は親の残額から取り除きます。同じ予算を親子で二重に使わない設計です。ただし、これは価格設定や記録が正しいことを前提とし、任意の外部支出まで自動的に封じる証明ではありません。
実験のゼロを、何のゼロとして読むか
論文Table 1の結果を、未確認変更があった課題実行数と、課題成功数に分けて整理しました。Haikuは3回の実行を合算していますが、API枠による欠落があるため150件ではなく、両方式が完了した128件です。
| エージェントモデルと方式 | 未確認変更があった課題実行 | 課題成功 |
|---|---|---|
| Haiku 5.5・標準 | 29 / 128 | 112 / 128 |
| Haiku 5.5・Concordat | 0 / 128 | 105 / 128 |
| gpt-4.1・標準 | 13 / 50 | 20 / 50 |
| gpt-4.1・Concordat | 0 / 50 | 22 / 50 |
操作回数を数えると、標準方式の未確認変更はHaikuが50回、gpt-4.1が26回でした。29課題と50操作を混ぜると、違反の割合を誤って読んでしまいます。
Concordatの圧力条件では、どちらも未確認変更はゼロでした。ただし、ここでいう確認は顧客の直前のメッセージに明示的な「yes」が含まれるかという定義です。公開実装の判定はyes、yep、yeahという単語を受け入れます。評価側と防止側が同じ条件を使うため、その条件に対するゼロは仕組み上の結果でもあります。
著者自身も「yes, but not that one」のような否定を含む返答を、単語判定では受け入れ得ると指摘しています。自然言語の真意を理解して、すべての誤操作を防いだという実験ではありません。実運用では、変更内容を示した承認ボタンなど、構造化した確認が適切だと述べています。
gpt-4.1で「go ahead」を確認とみなせる2操作もあり、これを許可として数え直すと、標準方式の違反課題は13から12に減ります。境界の決め方も結果の一部です。
成功率と費用には、まだ留保がある
HaikuではConcordatの成功数が7件少なくなりました。標準方式だけが成功した13実行のうち11実行では、Concordatが繰り返し確認を断られて人に引き継いでいました。一方、標準方式は確認せずに変更していました。
著者はその後、押し返されたらすぐ引き継がず、必要な確認を説明して聞き直す指示を追加しました。gpt-4.1の結果はその変更後です。したがって、モデル間の差から指示修正の効果だけを取り出すことはできません。
成功率の差はHaikuでp=0.17、gpt-4.1でp=0.80と報告されています。「有意差がない」ことは、性能が同じだと証明できたことを意味しません。試行数も限られています。
費用も一方向ではありません。最初のHaiku圧力実験では標準1.76ドルに対してConcordat1.64ドルでしたが、gpt-4.1では3.13ドルに対して3.47ドルでした。著者は後者で会話が長くなったと説明しています。ツールを減らせば必ず安くなる、という読み方はできません。
自分の業務に持ち帰るなら、承認対象を固定する
ここからはAICompanyの応用案です。論文の航空予約実験で検証された効果とは分けて考えてください。
記事公開なら「原稿を準備」「監査を通す」「公開する版を確定」「必要な承認を得る」「同じ版を公開」という状態を置けます。業務で事前に与えられた公開権限があるなら、その権限の範囲も明示します。毎回むやみに聞き直すための設計ではなく、何を根拠に実行できるかを明確にするためです。
さらに、承認後に原稿や宛先が変わったら、承認を引き継がない設計が必要です。以下はその一点だけを試す、独立した小さな例です。ConcordatのAPI実装でも、本番向けの認可機構でもありません。
def can_commit(approved_version, current_version, state):
return (state == "approved"
and approved_version is not None
and approved_version == current_version)
assert can_commit("v3", "v3", "approved")
assert not can_commit("v3", "v4", "approved")
assert not can_commit("v3", "v3", "prepared")
assert not can_commit(None, None, "approved")文字列の版番号を比較するだけなので、本人認証、承認の真正性、並行更新、改ざんへの防御はありません。本番では承認した主体、対象、内容、期限、実行時の状態を結び付け、検査と書き込みの間で変化しないようにする必要があります。
この発想は、実行後の評価にも使えます。成果物の合格率とは別に、必要な承認を経たか、範囲内の操作だったかを記録すれば、最終結果だけの採点で消えてしまう問題が見えます。
導入前に残る課題
実験は航空予約の一領域、2モデル、少数試行です。顧客もLLMによる模擬で、実際の利用者の圧力や曖昧な同意を網羅していません。gpt-4.1にはレート制限後の再実行もあり、同時刻に全課題を比較した条件ではありません。
協力的な顧客での初期実験には、より緩い確認判定が使われていました。厳格な判定に直すとConcordat側にもyesなしの変更が1件あり、圧力条件のゼロと一括りにはできません。
また、状態機械に誤った手順を書けば、誤った手順を忠実に実行します。許可したツール自体のバグや、管理外の経路による変更を、手順定義だけで防げるわけではありません。永続化してプロセスをまたぐセッションなども、論文では今後の課題です。
Concordatの価値は、AIへのお願いだった手順を、レビューできる実行条件へ移すところにあります。試す際は、まず一つの重要な書き込み操作を選び、その直前に何が成立していなければならないかを定義する。成功したかに加えて、許された手順で成功したかを確かめる。その二つを揃えることが、業務を任せる準備になります。
出典：Concordat論文v1、公式リポジトリ。数値は論文Section 5、Table 1に基づきます。