AIエージェントに自社のどの操作を許可するべきか

AIアシスタントから自社の機能を呼び出せるようにするのは、具体的な顧客の用事に役立ち、システム側で利用範囲を制限できる場合です。まず、何を完了させるのか、どのデータが必要か、誰が結果に責任を持つかを決めます。公開FAQなら、ページを分かりやすくするだけで足りるかもしれません。顧客の非公開の注文状況にはアクセス制御が必要です。予約には、承認と確定の手順が必要です。

「エージェントから呼び出せる」とは、空き状況の確認など、自社が公開した機能をアシスタントが利用できるという意味です。システム全体へのアクセスを与えることではありません。

最初の処理と、その限界を決める

作業が完了したかを顧客から頻繁に尋ねられる、架空のサービス会社を考えます。最初のツールとして、一件の案件の進捗を返す機能は有用かもしれません。その仕様には、次の条件が必要です。

• 呼び出し元に、その案件を閲覧する権限があること。管理番号を知っているだけでは不十分です。
• 回答には、顧客向けに公開を認めた進捗、最終更新日時、問い合わせ先だけを含めます。社内メモや他の顧客の記録は除きます。
• 案件の編集、返金、元のシステムにない完了予定日の約束はできません。
• 情報源に接続できない場合やアクセスが拒否された場合は、その状態を返します。進捗を作り上げてはいけません。

新しいインターフェースを作る前に、既存の顧客ポータルと比較してください。すでに用事を済ませられるなら、なぜアシスタントとの接続が必要なのか、誰が保守するのかを確認します。

最初のリリースでは、支払い、返金、破壊的な変更、個人データの一括出力を対象外にします。機能拡張は、それぞれ別に承認し、テストします。モデルに正しく振る舞うよう指示するだけでは、アクセス制御になりません。

読み取り専用でも保護は必要

読み取りでも、非公開文書の漏えい、他の顧客の注文の表示、古い価格を現在の価格として伝えることが起こり得ます。データベースを書き換えなくても、顧客に損害を与える可能性があります。

顧客のアクセス権は、確認済みの身元とサーバー側の権限から判断します。アシスタントが渡したaccount_idは、そのアカウントを利用できる証拠にはなりません。同じ組織でも、全従業員がすべての文書を読めるとは限りません。

MCPが提供するものと、実装すべきもの

Model Context Protocol（MCP）は、アシスタントにツールを提供する方法の一つです。以下では、2026年10月9日に確認した2026年7月28日版を参照しています。実際のクライアントとサーバーが対応する版を確認してください。

認可仕様は、トークンの検証や権限の範囲を含むHTTP認可を扱います。単にログインを運ぶ仕組みではありません。ただし、付与された権限を、許可する操作や記録に対応づけるのは実装側の仕事です。別のサービス向けに発行されたトークンは、有効でも受け入れてはいけません。

ツール仕様は、サーバー側での入力検証、アクセス制御、呼び出し回数の制限、出力の無害化を求めています。人による監督や確認画面を推奨しますが、唯一の操作画面を規定しているわけではありません。MCPクライアントを接続できても、自社アプリでこれらの制御が機能する証明にはなりません。

セキュリティ指針も、状態を表す識別子の所持を認証と見なさないよう注意しています。ワークフローやカートの番号は確認対象を示すものであり、誰が利用できるかを証明するものではありません。

承認の内容を特定し、システムで強制する

予約を提案する場合は、確定前にサービス、タイムゾーン、日時、価格、キャンセル条件を顧客に示します。何が承認されたかを記録し、重要な条件が変われば改めて承認を得ます。モデルが生成した「承認済み」フラグは、顧客が同意した証拠ではありません。

提案の準備と、予約などを確定する処理を分けます。下書きの保存で記録が作られたり通知が送られたりするなら、それも書き込みとして権限設計に含めます。サーバーは、その正確な条件に対する必要な承認がない確定処理を拒否しなければなりません。

当社のエージェント向けインターフェースは読み取りツールから始め、義務が生じる操作は最後に追加します。取り消せない操作には顧客の確認を求めます。当社のパイロット開発には、システムへの書き込み、顧客へのメッセージ送信、資金移動に関する独自の人による承認条件があります。一般的な構成例が、その契約範囲を広げることはありません。

公開前に拒否と復旧をテストする

テスト用のアカウントと記録を使います。次の開発者も再現できるように、期待した結果と実際の結果を並べて残します。

権限を必要な範囲に絞り、認証情報に有効期限を設定し、権限の撤回をテストします。セキュリティ上の境界に応じて認証情報を分けますが、ツールごとに別のログインが必要とは限りません。タイムアウト、再試行回数、呼び出し元ごとの上限を設定します。書き込みには同じ操作を識別する固定IDとサーバー側の重複処理を使い、モデルの記憶に頼らないようにします。

呼び出し元、操作、権限の判断、関連する承認の参照番号、結果を記録します。秘密情報や不要な個人データを除き、ログを読める人と保存期間を定めます。ツールを停止し、結果が不明な処理を照合できる運用担当者を決めます。調達審査に向けたパイロットのガイドでは、こうした責任分担を確認可能な形にする方法を説明しています。

当社の公開例から確認できること

2026年10月9日、mcp.strataigize.comのtools/list、公開認可メタデータ、auth.mdを確認しました。一覧には公開の読み取りツールが七つと、無料の事業成長相談を申し込む認証付きツールrequest_growth_auditが一つありました。名前は以前のままですが、有料のAI Opportunity Auditではなく、相談の申し込みです。

この申し込みは書き込み操作です。文書には、特定の人が依頼した場合に限り送信でき、人が内容を確認し、予約は自動では確定しないとあります。また、ソフトウェアクライアントの自由な登録と、人の身元確認は異なると明記しています。

今回確認できたのは、公開されたインターフェースと利用条件です。申し込みを送信したり、セキュリティを検証したりしたわけではありません。ツール一覧は、外部からの利用や売上の証拠にもなりません。

開発を依頼する前に、最初の顧客の用事、許可するデータ、禁止する操作、承認のタイミング、失敗時のテスト、運用担当者、機能を取り下げる手順をまとめます。正しく完了した顧客の用事に加え、拒否、例外、人の確認時間を測ります。呼び出し回数には再試行や失敗も含まれるため、成功件数とは区別します。AIコンサルティングでは、連携開発に着手する前の範囲整理を支援できます。