powered by TechFeed
表示モード
Deep Dive

AIエージェントに「してよいこと」を判断させてはいけない — モデルの性能より先に整備すべきインフラのガバナンス設計

10月5日、Mozilla.aiが「You Don't Just Need Better AI. You Need Better Infrastructure.」と題した記事を公開した。AIコーディングエージェントへの権限委譲が進む中で、モデルの性能向上だけでなくインフラ側のガバナンス設計が不可欠だという論点を展開している。

10月5日、Mozilla.aiが「You Don't Just Need Better AI. You Need Better Infrastructure.」と題した記事を公開した。AIコーディングエージェントへの権限委譲が進む中で、モデルの性能向上だけでなくインフラ側のガバナンス設計が不可欠だという論点を展開している。


「何ができるか」と「何をしてよいか」は別問題だ

コーディングエージェントがリポジトリを編集し、テストを実行し、プルリクエストを開く――今やそれは実験ではなく日常だ。しかし記事が指摘する核心はここにある。

「モデルが何をできるか」にはベンチマークがある。スコアがあり、チャートがあり、ローンチ記事があり、1週間の議論がある。各社がこの問いに競い合うのは、勝てる問いだからだ。
「モデルが何をしてよいか」は測りにくい。答えは組織・タスク・委任した人間によって異なる。ガバナンスにはリーダーボードがない。測定されないものが得る注目はわずかで、何かが起きるまでそれは続く。

現状、多くのルールはAGENTS.mdファイルやシステムプロンプトに記述されている。エージェントはそれを「読んで解釈する」。

ルールに「従う」かどうかをエージェント自身が決めている

ここで見落とされがちなリスクがある。エージェントがルールを読んで解釈する以上、「このタスクはルールの例外に当たるか」「この操作は禁止範囲に含まれるか」という判断そのものがモデルに委ねられている。人間のレビューを介さず数千回の操作が自動実行される環境では、解釈のわずかなズレが本番環境の破壊やシークレットの漏洩につながりうる。ルールの遵守がエージェント自身の判断に依存しているという構造的問題は、モデルを賢くすれば解消するものではない。

「指示」は「制約」ではない

記事が強調する最も重要な区別がここだ。インストラクション(指示)とコンストレイント(制約)は根本的に異なる。

「生成ファイルを変更するな」というルールがあるとき、エージェントは「このファイルは生成ファイルに該当するか」「このタスクは例外を意味するか」「小さな修正は変更に当たるか」を自ら判断する。99%の遵守率に聞こえても、数千回の操作に適用すれば残り1%は運用上の問題になる。

記事ではRaffi Krikorianのエッセイ(元記事内で「最近のエッセイ」として紹介されている)を引用してこう述べる。

「文章は方向を示す。しかしロックはしない。」(A sentence steers; it doesn't lock.)

Krikorianはコーディングエージェントを個人システムのクレデンシャルから切り離し、ローカルで動くエージェントがアクセスを仲介する構成を採った。しかしそれでも問題は残る――「何が許可されるかを別のモデルに判断させる」限り、判断はループの中に留まり続ける。

パーミッション境界の本質は「リクエストを行うソフトウェアの判断にコンプライアンスが依存しない」ことにある。 アプリケーションの品質が向上してもデータベースのパーミッションを削除しなかったのと同じ論理だ。

決定の「記録」が後の調査を支える

ルールを強制することは問題の半分しか解決しない。エージェントが想定外の操作をしたとき、なぜそれが許可されたかを再構築できる必要がある。

変更されてはいけないファイルが変更されていたとしても、その変更自体からわかることは少ない。

  • ルールが存在しなかったのか
  • 例外が承認されていたのか
  • チェックが及ばないルートを通ったのか

結果は同じでも、対応は全く異なる。エージェント自身の説明も信頼の根拠にはならない。「リポジトリの規約に従った」という説明は検証が必要な主張であり、同じシステムに説明を求めても別の「語り」が返ってくるだけだ。

必要なのは、試みられた操作・適用されたポリシー・その決定を紐付けて記録するインフラだ。ツールのトレースだけでは不十分で、ポリシーの決定が同時に記録されていなければ、どのルールが適用されたか・その時点でのバージョンは何か・操作が許可・拒否・警告のいずれであったかが不明のままになる。

オープンソースである理由はガバナンスの「所有権」にある

記事が提示するガバナンス設計の要件は、突き詰めると次の二点に収束する。

  • エージェントを切り替えるたびにルールを作り直してはならない
  • 過去の決定を調査するために、今は使っていないプロダクトへのアクセスを必要としてはならない

これは年単位で運用し続けるインフラに求められる、ごく普通の要件だ。モデル・エージェント・インターフェースは今後も変わり続けるが、「システムが何をしてよいか」を記述するルールと「何をしたか」の記録は、それらすべてより長く生き続ける。

Mozilla.aiはこの問題意識を自社プロダクトに直接反映させており、コーディングエージェント向けのリポジトリ定義ルール機能「**Agent Guardrails**」を含むOtariの開発を進めている。記事が論じるガバナンス層――ルールの外部定義、決定の記録、エージェント非依存の制約――を実装するための具体的な手段として位置づけられたツールだ。オープンソースであることは、それ自体が信頼性を保証するわけではない。自社のペリメーター内で実行でき、ベンダーが消えても手元に残せる――その「所有権」が重要だと記事は主張する。


詳細はYou Don't Just Need Better AI. You Need Better Infrastructure.を参照していただきたい。