今日、あなたが使用しているあらゆるソフトウェアは、たった一つの前提に基づいて構築されています。それは、「指を持つ誰かがスクリーンの前に座っている」という前提です。ボタンは意図を暗示し、ウィザードは複雑さを管理し、フォームは人間の思考を構造化します。最近までクリックするのは人間だけだったため、このアーキテクチャは何十年もの間、プロダクトデザインを支配してきました。
その前提は、今や崩れ去りました。AIエージェントはインターフェースを読みません。便利なツールチップや確認ダイアログから恩恵を受けることもありません。自律的なシステムがユーザーに代わって行動する必要があるとき、UIの装飾（chrome）が邪魔になります。その結果、プロダクトの構築方法と、現代の呼び出し手（caller）の実際の振る舞いとの間に、深刻なミスマッチが生じています。
クリック・パラダイム
従来のソフトウェアは、視覚的な契約に依存しています。人間はボタンを見て、ラベルを理解し、それを押すかどうかを判断します。ワークフローには、あえて摩擦（フリクション）が設けられています。多段階のウィザードが存在するのは、人間はミスを犯すものであり、ガードレールが必要だからです。ドロップダウンやラジオボタンが入力内容を制限するのは、自由形式のテキストが混乱を招くからです。
オペレーターが人間であれば、これはうまく機能します。しかし、オペレーターがエージェントになると、この仕組みは崩壊します。機械は、サブスクリプションを解約したりレコードを修正したりするために、5段階のウィザードを必要としません。機械が必要としているのは、どのような操作が存在するかという明確な記述と、それを行うことが許可されているかという決定的な回答です。チームがこのことを無視すると、通常、2つの近道に頼ってしまいます。
第一に、エージェントにAPIキーを渡します。第二に、既存のユーザーインターフェースをチャットボットで包み込み、統合が完了したと見なします。どちらのアプローチも、真の問題を解決していません。
APIキーは、「このリクエストは信頼できるソースから来たものか？」という問いには答えてくれます。しかし、重要な問いである「この特定の呼び出し手は、この特定のレコードを読み取ることができるか？」には決して答えられません。キーはマスターキーのようなものです。一度発行されると、通常、リソースやコンテキストを横断して広範なアクセス権を付与してしまいます。システム内の個々の操作を規定するポリシーについては、何も知りません。
GUIをチャットボットで包む手法は、さらに脆弱です。エージェントは、インターフェースに組み込まれたあらゆる人間中心の前提を引き継いでしまいます。自律的なロジックではなく、人間の目（eyeballs）のために設計されたモーダルやフォームを通じて、クリックをシミュレートすることになります。チャットボットはUIの装飾をうまく操作できるかもしれませんが、それは理解を伴わないものです。それは「オートメーション・シアター（自動化の演劇）」に過ぎません。その裏側では、何が許可されているかについての、マシンリーダブル（機械判読可能）な契約は依然として存在しないのです。
エージェントが必要としているのは、玄関の新しい鍵ではありません。「ゲート（門）」なのです。
ゲートが実際に果たす役割
ゲートとは、統制された実行レイヤーのことです。認証情報を信頼して呼び出し手の振る舞いに期待するのではなく、ゲートを備えたシステムは、宣言されたルールに基づいてすべてのリクエストを評価します。これらのルールは、人間用かそれ以外かを問わず、あらゆるインターフェースから独立して存在します。
適切なゲートは、4つのことを定義します。プロダクト内にどのようなアクションが存在するかを宣言します。誰がどのような条件下でそれらを呼び出せるかを規定します。副作用を引き起こす前に、呼び出し手が停止して明示的な同意を求めるべきタイミングを指定します。そして、システムがあらゆる決定を、構造化されクエリ可能なトレイル（履歴）としてログに記録することを保証します。
これは、従来のアクセス制御とは根本的に異なります。ロールベースのシステムは、入り口で「あなたは管理者ですか？」と尋ね、その後は建物内を自由に歩き回らせるようなものです。一方、ゲートは、あらゆる分岐点で「あなたは今、この特定のスイッチを切り替えることが許可されていますか？」と問いかけます。アイデンティティ（身元）は振る舞いに対して二次的なものとなります。ポリシーはアクションと共に移動するのです。
具体的な例として、顧客に返金を行う必要があるエージェントを想像してください。キーベースのアプローチでは、エンドポイントに到達できれば、キーの保持者であれば誰でも返金処理を行えてしまうかもしれません。ゲートベースのアプローチでは、利用可能なアクションのマニフェストを確認し、特定の顧客レコードに対するエージェントの権限を検証し、金銭的な副作用に対してユーザーの明示的な承認を求め、一連のシーケンス全体を監査ログに書き込みます。ゲートは、単なるアイデンティティではなく、ポリシーを強制するのです。
Whistlerでのテスト
私たちはこのモデルをWhistlerに適用しました。人間用とマシン用の別々のパイプラインを構築するのではなく、単一のポリシーレイヤーを記述し、それに対して2つの異なる呼び出し手を実行しました。
一方の呼び出し手は、組み込みのShellを使用する人間でした。もう一方は、私たちのチーム外で開発されたサードパーティのエージェントでした。両者は同じマニフェストに接続しました。両者は、あらゆるステップで同一の権限チェックに直面しました。データの修正や外部イベントのトリガーなど、副作用を伴うアクションをいずれかの呼び出し手が試みたとき、システムは明示的な承認を要求しました。すべてのリクエスト、承認、拒否は、同一の構造化された監査トレイルを生成しました。
いずれの呼び出し元もマスターAPIキーを使用していなかった。バックドアも、ポリシーをバイパスするような昇格された資格情報も存在しなかった。人間だからといって、パスワードやブラウザを持っていることで制限が緩くなることはなかった。エージェントだからといって、人間の指紋（人間らしさ）がないために恣意的なブロックを受けることもなかった。ゲートは、アクション、コンテキスト、そしてルールを評価した。それだけで、トランザクションは完結していた。
その結果、人間であれマシンであれ、新しい呼び出し元を追加する際にアクセスロジックのリファクタリングを必要としないシステムが実現した。ポリシーを更新すれば、ゲートがそれを強制する。
プロダクトに対する問いの再考
もしあなたのチームが、人間向けに構築されたプロダクトにAIエージェントをどのように追加すべきか考えているなら、おそらく間違った問いから始めてしまっている。チームは本能的に「APIを公開すべきか」と問いがちだ。そうではなく、「すべての呼び出し元に対して、統制された実行レイヤーがあるか」を問うべきである。
ゲートのないAPIは、単にドアを広くしただけに過ぎない。もし内部ポリシーがウィザードロジックやフォームバリデーション、人間向けのヘルプテキストの中にしか存在しないのであれば、公開するどのエンドポイントも自律的な呼び出し元に対して安全ではない。エージェントは、キーを通じて過剰な信頼を継承するか、あるいはチャットボットのラッパーを通じて脆い操り人形のような動きをすることになるだろう。
ゲートを先に構築するということは、プロダクト内のあらゆる意味のあるアクションを「宣言された操作（declared operation）」としてリストアップすることを意味する。それは、権限チェックをユーザーインターフェースから分離し、Shellユーザーも外部エージェントも同じランタイムでの強制適用を受けるようにすることを意味する。それは、エージェントが誤ったデータセットを消去した後ではなく、破壊的な操作が必要になる前に、同意のフック（consent hooks）を挿入することを意味する。そして、呼び出し元が炭素（人間）かシリコン（マシン）かを問わず、セキュリティやコンプライアンスチームが検査できる監査証跡（audit trails）を生成することを意味する。
これには真のアーキテクチャの転換が必要だ。人間中心のデザインは、ロジックを共感や摩擦（friction）で包み込む。エージェント対応のデザインは、明示的でマシンリーダブルな契約（contracts）を通じてロジックを公開する。インターフェースがポリシーなのではなく、マニフェストがポリシーになるのだ。
この移行は人間を置き換えるためのものではない。ソフトウェアには、もはや一種類以上の呼び出し元が存在することを認識するためのものだ。それぞれが、同じ厳格さを求められる。
真の教訓
「クリック」のために設計するのをやめ、「ルール」のために設計し始めよう。もし、宣言されたアクション、コンテキストに基づいた権限、同意チェック、そして共有された監査証跡を通じて、システムがあらゆる呼び出し元を統制できるのであれば、その先にいるのが誰であれ、何であれ関係ない。人間であれエージェントであれ、全員が同じゲートに直面する。まずゲートを構築せよ。APIは単なるドアに過ぎない。部屋の整合性を保つのは、ポリシーなのだ。