MCPやAIエージェントを使うと、AIが社内ファイルを検索したり、データベースを参照したり、外部サービスの操作を補助したりできます。便利な一方で、通常のチャットAIよりも「何にアクセスできるか」「何を実行できるか」の設計が重要になります。

導入で大切なのは、AIを怖がって何も使わないことでも、最初から全社のデータとツールをつなぐことでもありません。まずは対象業務と権限を小さく切り分け、失敗しても戻せる状態で試すことです。

先に結論

AIに「何ができるか」より、先に「何をさせないか」を決める

  • 接続先と操作権限を一覧にする
  • 本番データではなく、ダミーデータで試す
  • 送信・更新・削除は人の承認を挟む
AIエージェントの処理を人が承認し、データベースや業務ツールへの接続を保護しているイラスト
イラスト:AIの提案を人が確認し、業務データやツールへの接続を守ります。

この記事では、MCPやAIエージェントを業務に取り入れる前に確認したい項目を、導入担当者が使えるチェックリストとしてまとめます。MCPの仕組みから知りたい場合は、MCP(Model Context Protocol)の解説もあわせてご覧ください。

MCP・AIエージェントで増えるリスク

通常のチャットでは、入力した内容に対して回答が返ってきます。MCPやAIエージェントを業務で使う場合は、そこに次の要素が加わります。

  • 社内文書や顧客情報を参照する
  • 外部サービスのAPIやファイルに接続する
  • AIの判断をもとに、検索・作成・更新などの処理を行う

つまり、問題は「AIが間違った回答をする」だけではありません。誤った情報を参照する、権限のないデータを見せる、意図しない操作を実行する、といった業務上の事故も考える必要があります。

導入前に確認したい12項目

1. 接続するツールを一覧にする

最初に、AIから接続するサービスをすべて書き出します。社内ストレージ、メール、チャット、顧客管理、会計、データベースなどを、サービス名だけでなく「読み取り」「新規作成」「更新」「削除」の操作単位で整理します。

「社内ツールと連携する」という表現だけでは、実際の権限範囲が分かりません。接続先と操作を表にして初めて、過剰な権限に気づけます。

2. AI専用のアカウントと認証情報を使う

個人の管理者アカウントや、担当者が普段使っているAPIキーをそのまま渡すのは避けます。AI連携用のアカウントを作り、担当者が退職したときにも個人アカウントに依存しない状態にします。

APIキーやアクセストークンは、プロンプトや設定ファイルに直書きしません。利用するサービスのシークレット管理機能や環境変数など、外部から参照されにくい方法で保管します。

3. 最小権限にする

AIに必要なのが「顧客情報の検索」だけなら、顧客情報の削除や全件エクスポートまで許可する必要はありません。最初は読み取り専用にし、作成・更新・送信といった操作は人の承認を経てからにします。

4. 扱うデータを分類する

公開情報、社内限定情報、個人情報、契約上の機密情報など、データを分類します。分類がないまま「社内データをAIに読ませる」と、入力してよい情報といけない情報の境界が曖昧になります。

特に、顧客名、住所、電話番号、口座情報、未公開の見積もりなどは、サービスの利用規約や契約条件も確認してから扱います。

5. 外部から混入する指示を疑う

AIが読み取ったWebページ、メール、文書の中に、AIへ向けた偽の指示が含まれることがあります。これはプロンプトインジェクションと呼ばれる問題の一例です。

外部文章を要約する業務であっても、文章中の命令をそのまま実行しない設計が必要です。「取得した情報はデータとして扱い、実行命令として扱わない」という境界を決めます。

6. 自動送信・自動更新を初期設定にしない

メール送信、見積もり金額の変更、顧客ステータスの更新、公開ページの編集などは、AIが提案した内容を人が確認してから実行する形にします。自動化の範囲は、正確性と影響範囲を見ながら段階的に広げます。

7. 操作の対象を限定する

「顧客データを検索できる」ではなく、「営業部が担当する顧客のうち、特定の項目だけを検索できる」のように対象を限定します。フォルダ、テーブル、レコード、項目の単位で制限できるか確認しましょう。

8. AIが出した内容と実行結果を分けて記録する

AIへの指示、参照したデータ、AIの提案、実際に実行された操作を、後から確認できるようにします。AIの回答だけを保存しても、どのデータを根拠にしたのか、誰が実行を承認したのかが追えません。

9. 本番データを使わない検証環境を用意する

最初のテストには、匿名化したデータやダミーデータを使います。AIの誤動作を確認する段階で、本番の顧客情報や重要なファイルを接続する必要はありません。

10. 失敗したときの停止方法を決める

接続を切る方法、APIキーを無効にする方法、変更を元に戻す方法を、導入前に確認します。担当者が不在でも停止できるよう、手順を文書化しておくと安心です。

11. アカウントの追加・削除を管理する

部署異動や退職時に、AI連携の権限が残り続けないようにします。AI専用アカウント、管理者アカウント、利用者アカウントを分け、誰が権限を見直すのかも決めます。

12. 定期的に権限とログを見直す

一度安全に設定しても、連携サービスや業務内容が変わればリスクも変わります。少なくとも、接続先を追加したとき、重要な業務に範囲を広げるとき、サービスの仕様が変わったときは再点検します。

小規模企業なら3段階で始める

いきなり完全自動化を目指す必要はありません。次の順番なら、導入効果とリスクを確認しやすくなります。

  1. 読み取り専用:社内FAQや規程を検索し、回答案を作る
  2. 人の承認付き作成:メールや報告書の下書きを作る
  3. 限定的な実行:条件が明確な処理だけ自動で登録する

最初の対象には、失敗しても金銭的・法的な影響が小さく、正解を人が確認しやすい業務を選びます。顧客への送信、支払い、契約変更、公開情報の更新は、十分に検証してからにしましょう。

12項目・3段階・4つのガードの根拠 この記事の「12項目」「3段階」「4つのガード」は、MCPやAIエージェントを小規模に導入する前に確認しやすいよう、Bloengが接続先・権限・データ・承認・ログ・停止方法などを実務単位で整理した項目です。特定の標準規格が定める必須数や、事故発生率から算出した統計ではありません。実際の導入では、接続するサービス、扱う情報、操作の影響範囲に応じて項目を追加してください。

よくある失敗

「社内だから安全」と考える

社内ネットワークから使うだけでは、入力データの扱いや連携先の権限まで安全になるわけではありません。どのデータが、どのサービスに、どの期間保存されるのかを確認する必要があります。

便利な連携を最初から全部入れる

連携先が増えるほど、権限・障害・ログ確認の範囲も広がります。効果を測りやすい1業務から始め、必要性が確認できた連携だけを追加します。

AIの回答だけを検証する

回答が自然でも、参照したデータが古い、対象が違う、操作対象を取り違えている可能性があります。回答の品質だけでなく、参照範囲と実行権限も確認しましょう。

まとめ

MCPやAIエージェントのセキュリティは、ツールの種類だけで決まるものではありません。接続先、権限、データ分類、人の承認、ログ、停止方法を一つの業務フローとして設計することが重要です。

自社でどの業務から始めるべきか、どこまで権限を与えてよいか判断しづらい場合は、Bloengのお問い合わせフォームからご相談ください。現在の業務と利用中のツールを伺い、安全に小さく始める方法を一緒に整理します。

参考情報