AIエージェントが独自の認証情報を持ち、外部サービスに直接通信する場合、それは従業員用ソフトウェアというよりも、監視役のいないコーポレートカードを持った請負業者のように振る舞います。何に触れたのか、誰がアクセスを承認したのか、あるいはなぜある会話が別の会話の10倍のコストがかかったのか、それらが見えなくなります。ログは十数ものサービスに分散し、疑問は増殖していきます。
エージェントは実際にどのツールを呼び出したのか？そのデータベースに触れる権限を誰が与えたのか？月曜日は5トークンだったのに、なぜ火曜日の実行では4万トークンも消費したのか？実際にはいくら使ったのか？
ユーザー、モデル、サービスの間にある中央制御レイヤーがなければ、これらの疑問は未解決のままです。すべての接続を一度だけ登録し、エージェントが真に必要とする限られた機能のみを公開し、すべての実行を完全に記録する、単一のプレーンが必要です。この記事では、ローカルの制御プレーンとして deco Studio を使用した高度なラボの手順を説明します。セットアップを行い、安全な Model Context Protocol サーバーを接続し、許可された機能をたった一つだけ公開し、エージェントがその境界を超えようとしたときに何が起こるかを観察します。
分散した認証情報の問題点
一般的なチームのセットアップを想像してみてください。ある開発者は、個人のキーを使用してエージェントを検索 API に接続します。別の開発者は、デモが安全そうに見えたという理由で、同じエージェントを本番データベースに接続します。三人目の開発者は、エージェントが「請求書の作成を支援」できるように、請求照会ツールを追加します。それぞれの接続は他のメンバーからは見えません。エージェントは現在、検索、本番データ、財務記録への直接的なアクセス権を持っていますが、チームには何が稼働しているのかの統一されたリストがありません。
認証情報がエージェント内部にあると、ガバナンスが崩壊します。キーがエージェントのメモリやローカルの環境変数ファイルにあるため、中央でアクセス権を取り消すことができません。外部サービスからは匿名の自動クライアントからの API コールとしてしか見えないため、使用状況を監査することもできません。コストの急増は数日後にクラウドの請求書として現れますが、その頃にはどのプロンプトがスパイクを引き起こしたのか、誰も覚えていません。
deco Studio で制御プレーンを構築する
deco Studio は、ローカルハブとして機能することでこの問題を解決します。自身のマシン上で実行し、設定を管理する単一の場所となります。API キーやツールの定義をエージェントごとに分散させる代わりに、Studio 内で接続を一度だけ登録します。そして、各エージェントがどの機能を見ることができるかを正確に決定します。
電話交換機を設置することを想像してください。すべての配線は一つの部屋に集まります。どの回線をどの部署に接続するかを選択し、すべての通話の記録を保持します。
まず、deco Studio をローカルで実行することから始めます。起動したら、設定を中央集約します。ツールを使用したいすべてのエージェントは、外部サービスに直接ではなく、制御プレーンにリクエストを送る必要があります。これにより、観察、フィルタリング、およびログ記録を行うためのチョークポイント（集中管理点）が即座に作成されます。
安全な MCP サーバーを接続する
このラボでは、Model Context Protocol サーバーを接続します。MCP はモデルが外部ツールとやり取りできるようにするためのオープン標準ですが、標準であることは安全性を保証するものではありません。ここでの重要なステップは「選択性」です。サーバーが提供するすべてのエンドポイントを盲目的に公開するのではなく、deco Studio にサーバーを登録し、テスト用エージェントには許可された機能を一つだけ公開します。
例えば、MCP サーバーが「ファイルの読み取り」「ファイルの書き込み」「データベースクエリ」「ネットワーク取得」など、10個の機能を提供しているとします。あなたは、サンドボックス化された計算機や、合成データに対する読み取り専用の照会など、無害な操作を一つだけ選び、それのみを公開します。残りの9つはエージェントからは見えなくなります。エージェントがそれらを要求した場合、制御プレーンは明確に拒否を返します。
これは「最小権限の原則」を機械的に実現したものです。エージェントは、丁寧な指示によってではなく、ソフトウェアの境界を通じて権限を受け取ります。
境界のテスト
テスト用エージェントを作成し、deco Studio の制御プレーンに向けます。許可された単一の機能が必要なタスクを与えてください。成功する様子を確認しましょう。Studio 内のログには、モデルのリクエスト、制御プレーンを経由したツール呼び出しのルーティング、関数の実行、そしてモデルに返される結果が表示されます。一連のトレースとして、その経路全体を読み取ることができます。
次に、あえて除外した関数を必要とする2つ目のタスクをエージェントに与えてみてください。エージェントはその制限を回避しようと推論を試みたり、あるいはそのツールが存在するとハルシネーション（幻覚）を起こしたりするかもしれません。いずれにせよ、呼び出しはコントロールプレーンに到達し、許可リストによって拒否され、実行は失敗します。この失敗こそが、境界が理論上のものではなく、ソフトウェアによって強制されていることの証明となります。
まずは、擬似的なタスクでこれを行ってください。生成されたユーザープロファイルで満たされた偽のデータベースを構築し、エージェントにそれをクエリさせます。許可リストと拒否が正しく機能しているかを確認してください。境界が信頼できるものになった後に初めて、エージェントを本番システムに向けることを検討すべきです。境界を検証する前に実データへ急ぐことは、機密情報の漏洩を招く原因となります。
実行の全経路を読み解く
deco Studioを使用すると、実行のあらゆるレイヤーを詳細に調査できます。生のモデルリクエスト（プロンプト、コンテキストウィンドウ、フォーマット）を確認できます。モデルが実行すると決定したツール呼び出しを確認できます。コントロールプレーンがその呼び出しをルーティングし、関数を実行し、ペイロードを返却する様子を確認できます。最後に、モデルがその結果をどのように消費して回答を形成するかを確認できます。
この可視性により、基本的な監査に関する疑問が解決されます。コントロールプレーンがログを記録しているため、どのツールが作動したかがわかります。設定レコードがローカルレジストリに保存されているため、誰がアクセスを許可したかがわかります。トークン数をカウントできるため、なぜその実行にコストがかかったのかがわかります。
重要な指標をカウントする
すべての実行において、4つの特定のメトリクスを追跡してください。第一に、入力および出力トークンです。これらはモデルコストの大部分を占めるため、大まかな見積もりではなく正確なカウントが必要です。第二に、モデルのレイテンシとツールのレイテンシを切り離して考えます。プロンプトからモデルの応答までの時間は、外部サービスがツール呼び出しに回答するまでの時間とは異なります。これらを混同すると、遅延の診断を誤ることになります。第三に、検証済みのプロバイダー料金に基づいてコストを算出してください。推測してはいけません。プロバイダーの料金表を確認し、測定されたトークン数と照らし合わせてください。第四に、成功した呼び出しと、拒否された未承認の呼び出しを比較してください。拒否数が多い場合は、エージェントが境界を探索しているか、あるいは許可リストが正当なニーズと一致していないことを意味します。
これらの数値により、エージェントの運用は「ブラックボックスなサブスクリプション」から「観測可能なシステム」へと変わります。予算を立て、最適化し、説明することが可能になります。
ローカル制御とローカル実行の違い
これは、注意深い開発者であっても陥りやすい教訓です。自身のマシンでdeco Studioを実行すると、設定に関するローカルな制御は可能になりますが、モデル自体のローカル実行が保証されるわけではありません。エージェントをOpenAI、Anthropic、またはその他のホスト型APIなどの外部プロバイダーに呼び出すように設定した場合、プロンプトはマシンを離れます。Studioはゲート（門）を管理しますが、データは依然としてネットワークを越えて移動します。
常にこれらの境界を追跡してください。パイプラインのどの部分がlocalhostに留まり、どの部分が他者のサーバーに送信されるのかを把握してください。データが機密情報である場合、ツールレイヤーのローカル制御だけでは不十分です。モデルの推論がどこで行われているかを知る必要もあります。ローカルダッシュボードの快適さと、リモートモデルの現実を混同しないでください。
指示は認可ではない
一つの危険な近道は、プロンプティングを通じてエージェントを保護しようとすることです。モデルに対して「決してdelete関数を呼び出さないでください」と伝えることは、セキュリティ制御ではありません。それは単なる「提案」です。モデルは指示を誤解したり、ジェイルブレイク（プロンプト・インジェクション）を受けたり、あるいは単に推論ミスを犯したりすることがあります。真のセキュリティは、ソフトウェアの境界に存在します。
deco Studio内の許可リストを使用して、どの関数が呼び出し可能かを正確に定義してください。それらの制限は、コントロールプレーン内のサーバーサイドのチェックによって強制してください。エージェントは、ユーザーがファイル権限を確認するのと同じように、親切なメモを読むのではなく、ハードな制限に突き当たることで自身の能力を認識すべきなのです。セキュリティはアーキテクチャに属するものであり、自然言語に属するものではありません。
小さく始め、常に懐疑的であること
コントロールプレーンを一段階ずつ構築していきましょう。一つのMCPサーバー、一つの公開された関数、一つの擬似的なタスク。エージェントが実行すべき場所で成功し、失敗すべき場所で失敗することを確認してください。トレースを読み、トークン数を確認します。それから次のツールを追加します。
コントロールとは、切り替えるだけのスイッチではありません。それは、境界を信頼する前に、その境界を証明し続ける習慣のことです。deco Studioは、その習慣を実践するためのローカルな環境を提供します。これを利用して、自律型エージェントの群れを、管理可能で、観測可能、かつ境界が定義されたシステムへと変貌させてください。
Source: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
自由参加の学習コミュニティ: Telegram上のGyaanSetu AI