Mozilla AIのエージェント基盤、モデル判断よりルールを優先
Mozilla AIは、コーディングエージェントをめぐる中核的な前提に異議を唱えている。より優れたモデル判断だけでは、委任されたソフトウェア作業を安全にできないというものだ。
同社のエージェント基盤に関する主張は、エージェントがリポジトリの調査、コード編集、テスト実行、プルリクエスト準備を担う権限を得る中で提示された。こうした能力は、何時間もの作業を数分に短縮できる。一方で、確率的システムに永続的な影響を伴う操作へのアクセスも与える。
Mozilla AIのエージェント基盤論は、競争軸を能力対能力から、指示対強制可能な制御へと移す。AGENTS.mdファイルは、エージェントに何をすべきかを伝えられる。しかし、絶対に実行してはならない操作を防げるのは、基盤だけだ。
この違いは、エージェントの自律性を広げるあらゆる組織に問いを突きつける。OpenAI、Anthropic、Google、GitHub、そして独立系開発者はいずれも異なるエージェント体験を提供している。それでも、どの導入でもいずれ同じ問いに直面する。モデルがルールを誤解したとき、何がなお守られるのか。
Mozilla AIのエージェント基盤が変えるもの
Mozilla AIは、エージェントをめぐる議論をモデルの知能から、あらゆるモデル判断を取り巻くシステムへと移そうとしている。
コーディングエージェントは、もはやチャットインターフェースとしてだけ動作するものではない。コードベースを検索し、複数のファイルを修正し、シェルコマンドを実行し、テストスイートを走らせ、変更案を組み立てられる。一部のシステムは、開発者が別の作業をしている間も動作を続けられる。
この広がった役割により、基盤は実装の詳細ではなく製品の一部となる。チャット画面での誤答は、ある種類のリスクを生む。リポジトリ、ネットワーク、認証情報へのアクセスを伴う誤ったコマンドは、別の種類のリスクを生む。
Mozilla AIの介入が重要なのは、チームがしばしば混同する3つの責任を分離しているためだ。指示は望ましい振る舞いを記述する。モデルはそれらの指示を解釈する。基盤は、どの操作が技術的に可能かを決める。
この区別は単純に聞こえるが、多くのエージェント導入はこの階層を逆転させている。まず広範なアクセスを与え、その後で自然言語のルールを通じてモデルに自制を求める。この設計では、モデルが作業者であると同時に、自らの主要な制御システムにもなる。
リポジトリの指示には、機能ブランチから直接公開してはならないと書かれているかもしれない。認証コードを変更する前に承認を求めることを要求する場合もある。特定のディレクトリ外のファイルを読むことを禁じる場合もある。
こうした記述は、エージェントが正しく読み、解釈し、優先順位を付けられる場合には、その振る舞いを改善する。しかし、OS境界、ネットワークポリシー、承認ゲートを作り出すわけではない。モデルは依然として、記載されたルールに違反する操作を要求できる。
広く採用されているエージェント指示フォーマットは、プロジェクトのコンテキストに有用な慣例を提供する。同サイトはAGENTS.mdを、ビルドコマンド、テスト手順、慣例、セキュリティ上の考慮事項を置くための予測可能な場所として説明している。また、6万を超えるオープンソースプロジェクトでの採用も報告している。
この普及は、移植可能な指示が重要である理由を示している。チームは、コーディング製品ごとに同じリポジトリのガイダンスを書き直すべきではない。共通フォーマットなら、ルールをエージェント間で持ち運び、コードの隣に見える形で残せる。
ただし、移植性が散文を強制力へと変えるわけではない。Markdownには、シェル、クラウドアカウント、パッケージレジストリ、本番データベースに対する権限はない。Markdownは、それを読むモデルに影響を与えるだけであり、実行時環境が到達可能な世界を依然として制御する。
したがってMozilla AIは、欠けている層を指摘している。エージェント導入には、誤った解釈が密かに自らへ例外を与えられない、モデルのループの外側にある制御が必要だ。
これはAGENTS.mdの価値を下げるものではない。むしろ、ファイルの役割を明確にする。指示は意図を伝えるべきであり、基盤はその意図を囲む境界を強制すべきだ。
この実践的な転換は大きい。チームは、より優れた推論こそが、より安全な自律性への道だと考えてきた。Mozilla AIは、信頼できる自律性は、推論が時に失敗することを前提に始まると主張している。
コーディングエージェントは提案を副作用へ変える
エージェントが完了できる作業が増えるほど、最終的な安全境界として良識に頼ることは許容されなくなる。
従来のコード支援ツールは、主に人間がレビューするためのテキストを提案していた。提案を挿入するか、コマンドを実行するか、変更を上流へ送るかは開発者が決めていた。その人間の操作が、自然なチェックポイントを形成していた。
エージェント型ツールは、こうしたチェックポイントを圧縮する。一つの指示から、ファイルの探索、依存関係のインストール、コード生成、テスト実行、リポジトリ操作が始まる可能性がある。各段階で新たなコンテキストが生まれ、次のモデル判断を形作る。
ソフトウェア作業は、ほとんどの場合、一つのプロンプトと一つの回答には収まらないため、このループは有用だ。エージェントは結果を観察し、前提を修正し、別のアプローチを試す必要がある。同じループは、初期の誤りも増幅する。
失敗している統合テストの修正を依頼されたエージェントを考えてみよう。環境ファイルを調べ、サービスを起動し、依存関係を更新し、スナップショットを再生成するかもしれない。曖昧な指示によって、意図されたテストを大きく越えて進む可能性がある。
失敗に悪意ある行動は必要ない。エージェントは、破壊的なクリーンアップコマンドが通常の手順だと推論するかもしれない。テスト用認証情報を使い捨てだと解釈するかもしれない。Issue、依存関係、Webページから取得したテキストを信頼するかもしれない。
プロンプトインジェクションにより、最後のシナリオは特に重要になる。エージェントは、処理を依頼されたコンテンツ内で敵対的な指示に遭遇し得る。その場合、モデルは作業を継続しながら、タスクデータとコマンドを区別しなければならない。
自然言語のガイダンスは役立つが、他の自然言語が信頼できるかどうかを判断するのは、依然としてモデルというコンポーネントだ。最終境界を置く場所としては不安定である。
実行基盤は、結果の範囲を狭められる。OpenAIのサンドボックスアーキテクチャは、信頼されたハーネスと、モデル主導のコマンドが実行される環境を分離している。ハーネスは、実行コンテナの外側で承認、トレーシング、復旧、状態を管理できる。
この分離は、より広い仕組みを示している。エージェントは、組織が利用できるすべての認証情報やリソースを自動的に継承せずとも、環境内で作業できる。基盤が、境界を越えるものを仲介する。
ドキュメント更新を任されたコーディングエージェントに、パッケージ公開用の認証情報は必要ない。あるサービスを修復するエージェントが、無関係なリポジトリへ自動的にアクセスすべきではない。テスト作成タスクに、本番データベースの権限を持たせるべきではない。
これらは、プロンプト作成ではなくケイパビリティに関する判断だ。ケイパビリティとは、特定のディレクトリへの書き込みや承認済みエンドポイントの呼び出しなど、ランタイムが許可する操作である。優れた基盤は、現在のタスクに応じてケイパビリティを付与する。
この圧力は、まずプラットフォームチームとセキュリティチームにかかる。自律性が生産性向上をもたらすため、開発者はエージェントがより少ない監督で行動することを望む。セキュリティチームは、監督の削減が無制限の権限にならないようにしなければならない。
ベンダーにも同様に影響する。洗練されたエージェントのインターフェースは、脆弱な運用上の制御を隠し得る。購入者はベンチマーク結果だけでなく、システムがアイデンティティ、認証情報、承認、ログ、再試行、復旧をどのように扱うかを問う必要がある。
同じ問題は個人開発者にも及ぶ。ローカルエージェントは、一台のノートPC上で動作するため、閉じ込められているように見えるかもしれない。しかし、そのマシンにはソースコード、ブラウザセッション、クラウド認証情報、個人文書、署名鍵が保存されている可能性がある。
エージェントが重大な損害を引き起こすのに、管理者アクセスは必要ない。タスクに必要な以上の権限を持つ認証情報が一つあればよい。基盤は、この不一致を生みにくくしなければならない。
だからこそ、このニュースは単に責任あるAIを求める声ではない。Mozilla AIは、責任をモデルの振る舞いからシステム設計へと移している。それにより、負担は組織が検査し、テストできるコンポーネントに置かれる。
AGENTS.mdはルールを説明できても、強制はできない
主要な対立は今や明確だ。指示ファイルは人間の意図を表現し、ランタイム制御はエージェントが実際に何をできるかを決める。
AGENTS.mdは、実際の調整上の問題を解決する。コーディングエージェントには、コマンド、リポジトリの慣例、検証要件、ローカル固有の注意事項が必要だ。そのコンテキストをコードの近くに置くことで、可視化、バージョン管理、再利用が可能になる。
このフォーマットは、大規模なリポジトリ内でより限定的な指示を定義することも可能にする。サービスごとに、リポジトリのルートとは異なるテストコマンドや制限を持たせられる。これは、人間がすでに用いている階層的なドキュメントに似ている。
それでも、あらゆる指示はモデルの解釈を経由する。エージェントは、関連するファイルを見つけ、重複するルールを解決し、現在のタスクへ適用し、長時間の実行を通じて記憶しなければならない。
この連鎖のどこかで失敗すれば、ルールは弱まる可能性がある。ファイルが不完全かもしれない。コンテキストが切り詰められるかもしれない。ネストした指示がルートの指示と衝突するかもしれない。モデルが例外を広く一般化しすぎるかもしれない。
完璧に指示に従っても、すべての問題を解決できるわけではない。たとえばルールで、パッケージ公開前に承認を得るよう定めることはできる。それでもエージェントには、信頼できる承認メカニズムと、承認を行う権限を持つアイデンティティが必要だ。
承認がコンテキスト内の別のメッセージとしてしか存在しない場合、信頼できないコンテンツがそれを模倣できる。より強いシステムは、モデルが作り出せない外部状態として承認を表現する。ランタイムは、操作を解放する前にその状態を確認する。
同じ原則は支出上限にも当てはまる。トークンを節約するようエージェントに伝えることは、有用なガイダンスだ。制御プレーンによって強制される予算は、ループが予想以上に長引いた場合でも有効であり続ける。
監査可能性も、別の制約を明らかにする。指示は、エージェントに自身の選択を説明するよう要求できる。しかし、その説明がツール入力、権限状態、ファイル変更、再試行、拒否された操作の完全な記録になるとは限らない。
信頼できる監査証跡は、エージェントの語りの外側でイベントを記録しなければならない。どのアイデンティティが操作を要求したか、どのポリシーが評価されたか、どの入力がツールに渡ったか、どの結果が返ったかを示すべきだ。
記録には失敗も残すべきである。許可された経路を見つける前に3回禁止操作を試みたエージェントと、最初から許可された経路を選んだエージェントでは、意味が異なる。最終出力だけでは、その違いは隠れてしまう。
これはインシデント時に重要になる。チームは、エージェントが何を見て、その瞬間にどの権限を持っていたのかを再構築する必要がある。後からポリシー、プロンプト、認証情報が変わっていれば、現在のドキュメントだけでは不十分だ。
したがって基盤は、操作を特定の実行、ポリシーバージョン、ツールバージョン、承認状態に結び付けるべきである。これにより、後のレビューは記憶や再構成されたチャット記録への依存を減らせる。
ログは、エンジニアリングの改善も支える。チームは、繰り返し介入を要するコマンド、誤検知を生むポリシー、想定範囲を超えるタスクを特定できる。こうしたパターンは、より限定的な権限と改善されたワークフローの指針になる。
開発者には、依然としてよく書かれた指示が必要だ。目標は、人間の意図を硬直したポリシーに置き換えることではない。多くのソフトウェア上の判断には、ファイルシステムのルールだけでは捉えられないコンテキストが必要となる。
より良い設計は、各層に適切な役割を与える。AGENTS.mdは、プロジェクトの仕組みをエージェントに伝える。ポリシー層は、提案された操作がタスクに許可された範囲に収まるかを判断する。
サンドボックスは、実行時に公開されるリソースを制限する。承認サービスは、重要な例外処理を担う。監査システムは、判断とその結果を記録する。
これらのコンポーネントを組み合わせることで、モデルを置き換えてもルールを維持できる。チームは、最も重要な境界を別ベンダーのプロンプト形式で再構築することなく、エージェントを切り替えられる。
この持続性は、Mozilla AIの主張の中核にある。モデルは頻繁に変わるだろう。リポジトリの所有権、コンプライアンス上の責務、プロダクション環境のリスクは、はるかに長く残る。
コントロールプレーンが真の安全メカニズムになる
信頼できるエージェント基盤は、モデルのリクエストと重要なすべてのツール操作の間に、強制可能なポリシーを置く。
コントロールプレーンとは、アクセス、ポリシー、ルーティング、予算、運用状態を管理する信頼層である。モデルは操作を提案できるが、実行の可否と方法を決めるのはコントロールプレーンだ。
このアーキテクチャはアイデンティティから始まる。すべてのエージェント実行には、人間のオペレーターや他の自動プロセスとは区別されたアイデンティティが必要だ。共有認証情報では、帰属の特定が難しくなり、権限の取り消しも不正確になる。
次の要件は最小権限である。各タスクには、必要なファイル、コマンド、サービス、ネットワーク宛先だけを与える。権限は将来の実行でも利用可能なままにするのではなく、タスクとともに失効すべきだ。
OpenAIのサンドボックスセキュリティガイダンスは、分離されたワークロード、制限されたアウトバウンド通信、認証情報の分離、サードパーティーサービスへの仲介アクセスを推奨している。これらの制御は、モデルの意図とは独立して機能する。
仲介された認証情報は特に有用だ。実行環境は、再利用可能なシークレットを見ることなく、承認済みリクエストを送信できる。信頼できるプロキシは、許可された宛先に対してのみ認証情報を提供する。
この設計は、偶発的な情報漏えいの価値を下げる。生成されたコードが環境を出力しても、長期間有効な本番用キーを表示する必要はない。失効処理も、各ワークスペース内ではなくブローカー側で行える。
ツールの仲介は、別の強制ポイントを提供する。基盤は引数を検証し、危険なパスを拒否し、リクエストレートを制限し、特定の操作に承認を要求できる。
Mozilla AIは、mcpd policy pluginsを通じて、そのパターンを探究している。Mozillaは、認証、検証、レート制限、ログ記録を、エージェントとツールサーバーの間に配置できる機能として説明している。
この配置が重要なのは、Model Context Protocolサーバーがファイル、データベース、外部アプリケーションをまたぐ操作を公開しうるためだ。中央の仲介層は、各エージェントがそのポリシーを再現すると信頼せずとも、一貫したポリシーを適用できる。
成熟したコントロールプレーンは状態も管理する。エージェントのワークフローは、一部の操作を完了した後、成功を記録する前に失敗することがある。ジョブ全体を無差別に再試行すると、外部への副作用が重複しかねない。
基盤は、どのステップが完了したか、どれが安全に再試行できるか、どれに照合が必要かを把握すべきだ。プルリクエストの作成、支払い指示、顧客へのメッセージは、ローカルファイルの読み取りのように常に繰り返せるわけではない。
人間の承認は、すべてのステップの後ではなく、選択された境界に置くべきだ。絶え間ない承認要求は、委任の価値の大部分を失わせる。承認がまったくなければ、重要な判断がすべてモデルループの内側に残る。
実用的な中間点は、リスクに基づくエスカレーションである。リポジトリの読み取りは自動で進められる。一時的なブランチ内での書き込みも同様だ。公開、デプロイ、権限変更、顧客への連絡には、明示的な認可を求められる。
ポリシーは、操作を取り巻くコンテキストを検査すべきだ。あるコマンドは分離されたテスト環境では許容できても、本番環境に対しては禁止される場合がある。ネットワークリクエストはドキュメント向けには許可されても、未知のエンドポイント向けにはブロックされることがある。
予算にも同様の強制が必要だ。複数のサブエージェントを調整するエージェントは、1つのチャットを見守る人より速くコストを発生させうる。コントロールプレーンは、タスク、チーム、プロバイダー、成果ごとに上限を設定できる。
Mozilla AIのオープンコントロールプレーンは、このガバナンスの議論をモデルルーティングに結び付けている。Otariは、プロバイダー間のルーティング、予算、アクセス制御、デプロイ、フェイルオーバーのための層として提示されている。
ルーティングは単なるコスト最適化ではない。タスクごとに、異なるプライバシー境界、レイテンシー目標、モデル能力が求められる場合がある。基盤は、そうした選択をアプリケーションコード全体に埋め込むのではなく、一貫して適用できる。
このアプローチは移植性も向上させる。組織は、ポリシーロジック、履歴トレース、運用上の制御を手放さずにモデルを置き換えられる。エージェントは、組織が所有するシステム内の一つのコンポーネントになる。
エンジニアリングチームにとって、これは組織的な知識の維持につながりうる。検索可能な技術ナレッジベースは、アーキテクチャ上の意思決定とローカルドキュメントを保持できる。実行時ポリシーは依然として、エージェントがその知識をどう利用するかを制御しなければならない。
鍵となるのは分離だ。知識はモデルに情報を与える。ポリシーはその操作を制約する。監査記録は何が起きたかを残す。リカバリーは未完了の作業を処理する。
単一のコンポーネントだけでエージェントを信頼できるものにはできない。コントロールプレーンはそれらを調整し、一つの誤った判断で結果全体が決まらないようにする。
オープンな基盤は制御を生むが、自動的な安全性を生むわけではない
エージェントスタックを所有すれば、検査可能性と移植性は向上するが、オープンコードだけで運用リスクが消えるわけではない。
Mozilla AIは、基盤の制御をオープン性に結び付けている。この関係は理解できる。あるベンダーのサービス境界の背後にしか存在しない制御システムを、組織が完全に検査、変更、維持することはできない。
オープンな基盤はベンダーロックインを減らせる。チームはモデルプロバイダーを変えてもポリシーを保持できる。強制コードを調査し、統合を追加し、機密性の高いコンポーネントを自らが管理する環境内にデプロイできる。
また、リスクを負う組織の近くにガバナンスを置くこともできる。病院、銀行、公共機関、ソフトウェア企業では、異なる承認ルールや保持ポリシーが必要になる場合がある。単一のホステッドサービスのデフォルトでは、あらゆる義務を表現できない。
しかし、所有には責任が伴う。セルフホスト型のコントロールプレーンには、セキュリティ更新、アクセスレビュー、バックアップ、監視、検証済みの復旧が必要だ。古くなったオープンコンポーネントは、新たな弱点になりうる。
透明性は正しい設定を保証しない。チームは、寛容なデフォルト、共有認証情報、不完全なログ、無制限のネットワークアクセスを伴う検査可能なソフトウェアをデプロイできる。ソースがオープンでも、デプロイメントは安全でないままになりうる。
ログには独自のトレードオフがある。豊富なトレースは調査に役立つ一方、プロプライエタリコード、個人情報、プロンプト、ツールの結果を取り込む可能性がある。すべてを無期限に保持することは、プライバシーと最小化の目標に反する場合がある。
チームには明示的な保持境界が必要だ。監査システムがすべての機密入力の恒久的なコピーになることなく、責任を確立するのに十分な情報を記録すべきである。
ポリシーの複雑さも別のリスクだ。大規模なルールセットは理解が難しくなりうる。重複する例外は隙間を生む可能性があり、過度に厳格な制御は開発者を未承認のツールへ向かわせることがある。
答えは単にポリシーを増やすことではない。チームには、特定のリスクに結び付いた小さく検証可能な制御が必要だ。各ルールには、所有者、理由、検証方法があるべきだ。
モデルの振る舞いも依然として重要である。基盤は禁じられた操作をブロックできるが、有用なコードを保証することはできない。エージェントは権限内にとどまりながら、誤った実装を出力したり、重要な要件を見落としたりする可能性がある。
したがって、テストと人間によるレビューは引き続きシステムの一部である。非公開または独立して維持された評価ケースは、可視のチェックだけに最適化するエージェントの検出に役立つ。コードオーナーシップのルールは、機密性の高い変更を適切なレビュアーへ回せる。
これが、Mozilla AIのエージェント基盤という主張に対する懐疑的な限界である。より良い基盤は障害を封じ込め、証拠を保持し、復旧を可能にする。不確実な推論を、決定論的なソフトウェアエンジニアリングへ変換するものではない。
組織は、監査ログを安全性の証明として扱うことにも抵抗すべきだ。詳細な記録は、インシデントがどのように起きたかを正確に示せる。インシデントを防ぐには、操作の前に強制可能な制御と検証済みのポリシーが必要だ。
誰がコントロールプレーンを制御するのかというガバナンス上の問題もある。中央ポリシーは組織を守れるが、不透明な社内権力を生む可能性もある。開発者は、なぜ操作が拒否されたのか、例外がどのように機能するのかを把握できなければならない。
オープンな実装はそうした精査に役立つが、プロセスも重要だ。ポリシー変更には、レビュー、テスト、バージョン管理を適用すべきである。緊急時の上書きは期限を設け、記録上でも可視のままにすべきだ。
最も強固なアプローチは、オープン性をセキュリティラベルではなく所有モデルとして扱う。組織はシステムを検査・変更する能力を得る。同時に、それを適切に運用する責任も負う。
このトレードオフは、自動的な安全性を約束するより説得力がある。信頼できる委任は、一つの製品機能ではなく、エンジニアリング上の規律から生まれることを認識しているからだ。
Mozillaの基盤に関する主張を検証する3つのシグナル
次の検証点は、エージェントプラットフォームが、通常業務を遅らせずに開発者が検証できるデフォルトへ、基盤の原則を落とし込めるかどうかだ。
第一のシグナルは、タスクスコープの権限がどこまで広がるかである。コーディングエージェントに、指定されたリポジトリ、ディレクトリ、コマンド、ネットワーク宛先への一時的なアクセスが与えられるかを注視すべきだ。ベンダーが他の場面で安全性を訴求していても、広範なマシンレベルの権限が与えられるなら、実務上はMozilla AIの主張を弱めることになる。
第二のシグナルは、証拠の質である。プラットフォームは、ツール呼び出し、承認、ポリシー判断、ファイル変更、再試行状態の永続的な記録を公開すべきだ。トランスクリプトだけでは、操作が行われた時点でどの権限が存在していたかは分からない。
第三のシグナルは移植性だ。チームは、モデルやデプロイ環境を切り替えても、ポリシー、トレース、ワークフロー状態を保持できるべきである。ガバナンスが一つのプロバイダーに結び付いたままなら、モデル選択は依然として周辺システムを左右する。
これらのシグナルは相互に補強し合う。スコープを限定した権限は、発生しうる損害を減らす。監査記録は、それらの境界が機能したかを明らかにする。移植性は、次のモデル移行時に境界が消えるのを防ぐ。
開発者は日々のワークフローにおける摩擦も注視すべきだ。低リスクの操作を絶えず中断する制御層は、抵抗に直面する。ポリシー判断を隠すものは、信頼もデバッグも難しい。
成功するシステムは、安全な操作を日常的なものにし、例外的な操作を明示的なものにする。エージェントが、境界の定められた環境内で、読み取り、推論、テスト、変更準備を行えるようにする。外部的または不可逆的な結果を伴う操作で停止する。
これらの機能が標準的な製品要件になれば、Mozilla AIのエージェント基盤に関する主張は強まる。エージェントが権限を得続ける一方で、制御が任意のダッシュボードやプロンプトテンプレートのままなら、その主張は弱まる。
今コーディングエージェントを導入するチームにとって、直近の問いは最新モデルのスコアがより高いかどうかではない。エージェントが何にアクセスできるか、どの操作に承認が必要か、あらゆる判断を後から再構築できるかを問うべきだ。次に、それらの保護が自組織に属するものなのか、ベンダーとともに消えるものなのかを問うべきである。より優れたAIは引き続き有用だが、その知性を責任を持って委任できるかを決めるのは基盤である。
