MCPサーバーでWhatsApp自動化、AIエージェントに権限を渡しすぎてはいけない理由

MetaがWhatsApp Business Tools MCPを公開した。WhatsApp BusinessのAPI接続やアカウント設定を、AIチャットで代行できるツールだ。

このツールは権限の渡しすぎという課題を突きつける。

AIに全権限を与えて自律動作させると、過剰な自律行動（Excessive Agency）によりデータの削除や外部送信が発生するリスクがある。

Claude Codeでコードを書いていると、自動化の利便性とセキュリティの緊張感は常に隣り合わせだ。

AIに『何をさせるか』と『何をさせないか』。開発者が直面する権限設計の境界線を整理する。

Metaの「WhatsApp MCP」公開と、AI自律化の現実

Metaは、WhatsApp Business PlatformをAIエージェントから直接操作できるMCP（Model Context Protocol）サーバーを公開した。

これまでWhatsApp Businessの導入には、開発者コンソール、ビジネス管理画面、APIリファレンス、コードエディタの4つの画面を往復する作業が必要だった。

WhatsApp Business Tools MCPを導入すれば、Claude、Cursor、Codex、ChatGPTといったAIエージェントが設定を代行する。

AIエージェントが担当する作業は以下の6項目だ。

• ビジネスアカウントの新規作成
• 電話番号の追加および認証手続き
• Cloud APIへのアクセス登録
• 利用規約の自動チェックと確認
• メッセージテンプレートの新規作成と編集
• ウェブフック動作や支払い状態のリアルタイム監視

設定エラーが発生しても、AIがログを解析してトラブルシューティングを行う。

しんたろー：
APIコンソールとドキュメントを往復する作業が消えるのは効率的だ。
APIキーの発行から規約同意までAIに全自動で任せることには緊張感がある。
ハルシネーションで設定を誤爆した場合、アカウント停止のリスクが残る。

AIエージェントに開発から公開までを委ねる実験も行われている。

ある開発者はClaude Opusを「AI CTO」に任命し、MCPサーバーを作成するツールを開発させた。

AIは市場調査、仕様策定、実装、テスト、CI構築を1日で完了した。2日目にはnpmへの公開手前まで到達した。

しかし、2要素認証（2FA）やセキュリティトークンの発行など、セキュリティに関わる最終手続きはAI単体では完結せず、人間の手が必要だった。

OWASP Top 10 for LLM（2025年版）では、LLM06:2025としてExcessive Agency（過剰な自律行動）という脆弱性が定義されている。

これは、AIエージェントに必要以上の実行権限を与えた結果、AIが意図しない破壊的な操作を実行するリスクだ。

外部の指示をAIに読み込ませる間接プロンプトインジェクションと組み合わさると被害は深刻化する。

あわせて読みたいAIエージェントを自作して本番運用する方法｜最小構成の実装とサブエージェント設計 →

AIに「どこまで鍵を渡すか」という設計の壁

MCPの普及により、AIエージェントにAPIやCLIの操作を委ねる開発手法が現実味を帯びている。

複雑な初期設定や認証連携を、チャットで指示するだけでAIが完了させる。

手作業の無駄が削ぎ落とされるスピード感は大きい。

AIが代行する裏側では、AIに強力な操作権限（APIキーやアカウント管理権限）が渡されている。

開発効率の最大化とセキュリティリスクの増大は背中合わせだ。

OWASP Top 10 for LLMが警告するExcessive Agency（過剰な自律行動）は、ハルシネーションや間接プロンプトインジェクションを受けた際、意図しないデータの消去や機密情報の外部漏洩を全自動で実行させる。

全権限を委譲したAIは、システムを内部から破壊するリスクを孕む。

Claude Codeを使用すると、ターミナル上で自律的にコマンドを実行するスピードを実感する。

セキュリティの最前線まで丸投げすることには慎重な姿勢が必要だ。

しんたろー：
Claude Codeに開発を任せると、シェルの実行承認もオートにしたくなる誘惑がある。しかし本番データベースの削除コマンドや、公開APIの権限変更までノーガードで通すことにはリスクを感じる。便利さと恐怖は常にセットだ。

AIをSaaS開発や業務自動化に組み込む際、AIには突破できないセキュリティ上の防波堤が存在する。

それが、二要素認証（2FA）やセキュリティキーによる生体認証、そして資金やアカウント設定に関わる最終決定だ。

AIがコードを書き、環境を構築できても、アカウントの新規作成や本番環境への公開作業には人間の介入が求められる。

これはAIの技術的な限界ではなく、人間側の安全性を担保するための意図的なアクセスコントロールだ。

開発者は最小権限の原則（Principle of Least Privilege）をアーキテクチャに組み込む。

AIエージェントには、基本的に読み取り専用（Read-only）の権限を付与する。

ファイルの削除や外部へのデータ送信、支払い設定の変更といった破壊的な影響を持つアクションを実行する直前には、人間が内容を確認して許可ボタンを押す承認ステップ（Human-in-the-loop）を組み込む。

開発環境のフルアクセス権限を本番環境まで引き継ぐことは避けるべきだ。

権限の境界線を設計することで、開発システム全体の堅牢性が決まる。

「AIに何をさせないか」を厳格にコントロールできる開発者が現場から信頼される。

AIエージェント時代に僕らの開発実務はどう変わるか

AIエージェントがMCPを介して各種APIやツールと接続する世界は、快適な開発体験をもたらす。

利便性をプロダクトや開発フローに組み込む前に、見直すべき実務上のポイントがある。

1. APIキーと権限スコープの総点検

現在ツールやスクリプトでAIエージェントに渡しているAPIキーの権限範囲を見直す。

開発中の手動テストでは、フルアクセス権限を持ったトークンを使いたくなる。

運用に乗せる際は、プロンプトインジェクションやモデルの誤判定が発生した際のデータ消去や不正操作を想定する。

• 読み取り専用で済むタスクには、書き込み権限を与えない
• 特定のAPIエンドポイントしか使わない場合は、スコープを最小限に限定したトークンを再発行する
• 開発用と本番用で認証情報とデータベース環境を分離する

最小権限の原則をAIエージェントにも徹底する。

しんたろー：
Claude Codeにターミナル操作を任せると、ドラスティックなコマンドを提案されることがある。開発のスピード感を出すためにAIに全権限を預けたくなるが、本番アクセスの鍵だけは自分が握っておくのが落ち着く。

2. 「破壊的操作」手前の手動承認フロー構築

AIエージェントのハルシネーションや不審な外部入力を100%防ぐことは困難だ。

システム側に承認のガードレールを仕込む。

外部へのデータ送信、ファイルの削除、決済情報の変更、設定の更新といった「やり直しが効かない処理」の直前に、人間によるワンクリック承認（Human-in-the-loop）を挟む。

AIが自律的に作業を進めつつ、最後の決定権だけは人間が保持する。

3. 「AIに任せない領域」の境界線を引く

2段階認証（2FA）の承認、秘密鍵の最終管理、アカウントの新規発行は、AIの手が届かない場所に留めておくべき業務だ。

「AIにどこまでを任せ、どこからを人間が握るか」をチームや個人開発の段階で定義する。

AIに不用意なパワーを与えないための権限設計と、予期せぬ挙動を未然に防ぐ安全対策を意識する。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

よくある質問

Q1: AIエージェントに公式のMCPサーバー経由で設定を任せても安全？

公式が提供するMCP（Model Context Protocol）サーバー自体はセキュリティ面で配慮された設計になっている。

ただし、接続するAIエージェントに与える権限の範囲には注意が必要だ。

アカウントの削除や決済方法の変更、重要通知の受信先変更など、ビジネスの基幹に関わる操作は人間による承認ステップを挟むべきだ。

「最小権限の原則」を適用し、作業に必要な権限だけを一時的に付与する運用を徹底する。

Q2: AIの「過剰な自律行動（Excessive Agency）」を防ぐ具体的な対策は？

最も効果的なのは、AIエージェントに付与する権限を最小限に絞ることだ。

「メールの要約」を担当するエージェントなら、読み取り権限（Read-only）のみを与え、削除や送信の権限は渡さない。

さらに、外部へのデータ送信、設定更新、ファイルの削除といったやり直しの効かない操作の直前には、人間の確認と承認（Human-in-the-loop）を組み込む。

AIに権限を全開で渡すのではなく、操作ごとに明確なガードレールを敷く設計が被害を未然に防ぐ。

Q3: AIエージェントに頼らず、人間が最後まで担うべき作業とは？

2段階認証（2FA）の承認、アクセスキーの管理、アカウントの最終登録は、人間が手動で行うべき領域だ。

また、作成したAPIの権限設定や、本番環境への公開作業における最終セキュリティチェックも、AIに丸投げしてはいけない。

AIは構築の大部分を効率化するが、アカウントの信頼性と最終的な責任はシステムを動かす人間が担保する。

まとめ

MCPによる自動化は便利であり、毎日その恩恵を受けている。

便利さと引き換えにAIへ権限を全開で渡すリスクも存在する。「AIに何をさせないか」を境界線として設計するのが、賢い開発スタイルだ。

AIの利便性を享受しつつ、セキュリティリスクを最小化する開発フローを構築する。

👉 ThreadPostでSNS運用を自動化する