
自社をAIエージェントから呼び出せるようにすべきか、それともリスクか
返金処理をエージェントから呼び出せる(agent-callable)ようにしていれば、顧客はAIアシスタントを説得して、あなたが承認していない返金をさせることができます。agent-callableとは、アシスタントが求めたときに自社システムが実行する処理のことです。一般的な接続方式であるModel Context Protocol(MCP)はログインを届けますが、そのログインで何をしてよいかは決めません。月曜日にやること:禁止のままにする3つの処理(支払いと返金、削除、個人データの一括エクスポート)を書き出します。次に、すでに接続されている処理のうち、そのリストに当てはまるものがないか探します。私たちが許可するのは、ステータス、空き状況、アカウント単位の文書、すでに公開されている情報の検索です。下書きは人間に回します。
どの従業員も発行しておらず、どの攻撃者も強制していない返金が、帳簿に現れることがあります。顧客がAIアシスタント、つまりその顧客がふだん使っているChatGPT、Claude、Geminiの画面と会話しただけです。アシスタントは、あなたがagent-callableにした処理、つまりアシスタントが求めたときに自社システムが実行する処理を呼び出しました。返金が役に立つ次の一手だと判断し、有効なログインを提示し、システムはその呼び出しを受け入れました。まさに設計どおりの動きです。
月曜日にやること:アシスタントに開始を決して許さない3つの処理を書き出します。支払いと返金。破壊的な編集と削除。個人に関わるあらゆるデータの一括エクスポート。次に、すでに接続されている処理のうち、そのリストに当てはまるものを探します。サーバーの構築から始めるのではありません。
ログインは許可ではありません。
間違った回答は安い。間違った行動は安くない。
人々が身構える失敗は、まずい回答です。チャットボットが誤った価格を伝えても、訂正のメール1通で済みます。
本当に痛い失敗は状態の変更です。発行された返金、削除された記録、エクスポートされた顧客リスト、上書きされた予約。チャージバック手数料は数週間後に届きます。個人データのエクスポートが自社の境界の外に出れば、通知するかどうかの判断が必要になります。ログが「誰がやったのか」に1回のクエリで答えられなければ、その1週間は2週間になります。
書き込み処理がリリースされるのは、デモが見栄えよくなるからです。読み取り専用の接続は地味なLoom動画にしかなりません。予約まで取れる接続に予算がつきます。Callableは、企業の電話に24時間365日応対し、予約を受け付けて取り置きを処理する音声ソフトを販売しています。予約こそがそのソフトの販売を決めるからです。このインセンティブこそ、危険な部分が最初に作られる理由です。
ログインは届く。何をしてよいかはあなたが決める。
一般的な接続方式は、2025年6月18日に公開されたModel Context Protocol(MCP)です。アシスタントが自社システム上の処理を呼び出せるようにする仕様です。仕様は、処理を実行する前に人が同意しなければならないと述べたうえで、仕様そのものはそれを強制しないとも述べています。強制するのはあなたであり、請求書を受け取るのもあなたです。
処理に関するページは、実装者に対して入力を検証し、誰が何を呼び出せるかを制限し、再試行の嵐を抑え、アシスタントからの応答を信頼できないものとして扱うよう求めています。どれもMCPの接続には含まれていません。一つひとつが、自社のチームが作る作業です。
同じMCPリビジョンのサインインのセクションは、一般的なログインの仕組みの上に成り立っており、認証情報がHTTPで届き、欠けていたり弱すぎたりすれば拒否できるようにしています。そのログインでどの処理を開始してよいかは、仕様の外、ログインプロバイダーの外、インストールしたキットの外にあります。それは自社が一度下し、その後守り抜かなければならない判断です。
セキュリティに関する注意事項があるのは、実装者が通信形式がセキュリティの仕事をしてくれると思い込み続けるからです。間違った対象に紐づいたログイン、推測できるセッション、固定のクライアントID。動いているデモがインシデントに変わるのは、たいていこうした経路です。注意事項を読んでください。MCPのバージョンを統制プログラムとして扱ってはいけません。
2025年12月、これを急ぎの課題にする変化がありました。Googleが「agent-ready by design」という言葉を掲げ、MapsとBigQueryを皮切りにホスト型のMCP接続の提供を開始しました。Cloudflareは、リモート呼び出しでメソッドを1行で公開する方法をリリースしました。プラットフォームが公開を1行のデフォルトにすると、範囲の決定は設計フェーズではなくなります。開発者がスプリントの途中で誰にも告げずに済ませるものになるのです。
4つを許可し、3つを拒否し、1つは確認する
私たちが主張する区分けは次のとおりです。リストよりも、その理由のほうが重要です。
許可するもの(読み取り専用):
| 処理 | 現実的な最悪の結果 | 許可したままにする理由 |
|---|---|---|
| 呼び出し側がすでに特定している記録のステータス照会 | 古いステータスが読み上げられる | 状態は変わらず、呼び出し側はすでに識別子を持っている必要がある |
| 空き状況と現在の価格 | 提示した価格が古い | 価格はもともと公開されており、価格の透明性こそが企業が引用される理由になる |
| 1つのアカウントに限定した文書の取得 | 正しいアカウント内の違う文書 | 範囲はサーバー側で強制し、アシスタントの引数には決して任せない |
| 公開済みの資料の検索 | 関係のない結果 | 対象はもともとオープンなウェブ上にある |
きっぱり拒否するもの:支払いと返金、破壊的な編集と削除、個人に関わるあらゆるデータの一括エクスポート。予算がいくらであっても、これらをagent-callableな処理として作ることはしません。これらの処理の最悪の結果は、間違った行動です。プロンプトを強化しても、処理がこの線を越えることはありません。
中間の層が1つあります。下書きの作成です。アシスタントは予約、チケット、注文を提案できます。確定するのは人間です。MCPには確認のステップが組み込まれています(処理の途中で本人に尋ねる機能と、本人が応答を編集できる機能)。ほとんどの実装はこのステップを省いています。
最悪の結果が間違った回答で済む処理は許可する。最悪の結果が間違った行動になる処理は拒否する。
ここでサーバーの構築手順は扱いません。コードは、あなたのチームがすでに書ける部分だからです。作業の費用を見積もるなら、もう1本のチュートリアルより、AIエージェントの実際の費用と自社開発か購入かのほうが役に立ちます。
処理ごとに専用の鍵を渡す
呼び出し側を機械として扱うことから、4つのデフォルトが導かれます。
ログインは処理ごとに1つ。連携ごとに1つではありません。請求書を読む認証情報が、チケット管理にまで届いてはいけません。
ログインはアカウントに紐づけます。アシスタントは運び屋にすぎません。運び屋は入れ替わり、廃止され、買収されます。
レート制限は、決して飽きることのない相手を想定して設定します。人間は3回試せばあきらめます。アシスタントはトークン、つまりモデルがプロンプトに費やす課金単位が尽きるまで再試行します。書き込みを行うものにはすべて冪等性キーを付け、2回目の同一の呼び出しが何も起こさないようにしましょう。
処理ごとの認証情報にはすべて有効期限を設け、失効を日常的な保守作業のままにしておきます。
そして、処理名、引数、呼び出し側の身元、結果として起きた状態の変化を1か所に記録します。この記録こそが、ひどい1週間をひどい午後1回で済ませられるかどうかを決めます。調達部門がこの点を尋ねてくるなら、調達審査を通過するエージェントのパイロットで、調達部門が何を読むのかを解説しています。
退屈なループは巧妙な攻撃より高くつく
誰もが悪意あるプロンプトに備えます。もっと地味な失敗のほうが高くつきます。
ある処理があいまいなパラメーターを1つ受け取るとします。アシスタントがそれを呼び出します。応答が不完全に見えたので、少し違う値を推測してもう一度呼び出します。何も漏れていません。認証情報も悪用されていません。キューはほぼ同じ記録で埋まり、被害は量と照合作業です。
この仕組みは文書化されています。アシスタントに処理を公開している本番サーバーの研究ははっきりこう述べています。モデルは平易な言葉で書かれた説明だけを見て処理を選び、ドキュメントやスキーマは読み飛ばします。エンジニアには明白な処理でも、呼び出し側にはあいまいかもしれません。
ですからデフォルトは、呼び出し側ごとの上限と、あいまいな値をきっぱり拒否する引数スキーマです。もっともらしい解釈が3つあるパラメーターはバグです。
私たちはまた、「アシスタントが解決したアクション」を成功指標として報告することも拒否しています。それは起きた呼び出しを数えるだけで、正しかった判断を数えるものではありません。危険な仕組みを取締役会の資料で成功のように見せてしまう可能性が最も高い数字です。
私たちの仕組みを公開します。確かめてください
私たちのサイト自体がagent-callableで、その範囲は意図的に小さくしています。mcp.strataigize.comは、アシスタント向けプロトコルのtools/listに8つの処理で応答します。7つは公開の読み取り(私たちについて、サービス、事例、無料ツール、コンテンツ検索、依頼の方法、ページの取得)で、1つは認証付きのアクション、つまり名前のある人物に代わってグロースコンサルティングを申し込むもので、audit:requestという単一のスコープの下にあります。このサーバー上のどの処理も、お金を動かすことも、リストをエクスポートすることも、記録を変更することもできません。保護リソースの文書が認可サーバーを示し、プレーンテキストのauth.mdがすべてを説明しています。どちらもアシスタントが最初に探す場所に置いてあります。この段落を書くために、2026年9月13日にサーバー、そのツール一覧、その文書、auth.mdを取得しました。あなたも取得できます。
正直に添えるべき数字もあります。2026年9月6日までの7日間、ログには外部のアシスタントクライアントからの呼び出しが1件もありませんでした。仕組みを作ることと市場がそれを使うことは別の出来事で、普及と呼べるのは後者だけです。
まず拒否リストを書く
ほとんどのチームはこれを連携プロジェクトとして見積もります。コネクターのように範囲を決め、APIの担当者に渡し、1スプリントでリリースする。そう見積もっても、権限の決定はやはり行われます。ただしデフォルトで、処理の説明を書いた人によって行われ、誰もリストに署名しません。
代わりに、ログが許す最悪の呼び出しの後で、書面で弁明できるかどうかを基準に見積もってください。拒否リストから始めます。アシスタントに開始させる4つの処理より先に、決して開始させない3つの処理を書き出し、そのリストを、CTOと法務の双方が署名し日付を入れた文書にします。構築の基にした2025年6月18日のMCPリビジョンと並べて保管しましょう。
ほとんどの企業にとっての答えは、小さな読み取り専用の範囲、人間が確定する下書きの層、そしてアシスタントが決して開始できない支払いと一括エクスポートです。この形はデモとしては見劣りしますが、連休を安心して過ごせます。
まず拒否リストを書きましょう。それから、すでに接続されていてリストに当てはまる処理を探しに行きましょう。この仕組みを推測ではなく設計したいなら、AIコンサルティングから始めてください。私たちが提供しているものの公開版は、agent-callableな仕組みです。
お問い合わせ