ERPとAI・MCP連携のセキュリティ｜権限・承認・監査を設計する

AIがERPへ接続すると、誰の情報を参照し、誰の権限で何を変えるかを明確にする必要があります。MCPを使うだけで安全性が保証されるわけではありません。本記事では、業務責任者と情シスが確認したい認証、権限、承認、データ、監査の基本を整理します。

Agenda（この記事の内容）

1. 認証・認可・業務承認を分ける
2. 必要最小限の機能とデータを公開する
3. 入力と外部情報を信頼し過ぎない
4. 更新操作には承認と結果確認を置く
5. 監査・停止・変更管理を運用へ組み込む
6. 権限の境界を一つの依頼で検証する
7. よくある質問

認証・認可・業務承認を分ける

認証は利用者や接続元を確かめること、認可は許可された範囲を制御することです。業務承認は、特定の取引を実行してよいかを判断することです。ログインできたことが、すべての情報と操作への許可を意味するわけではありません。

AIアプリケーション、MCPサーバー、ERPの間で、どの利用者と権限が対応するかを確認します。広い共通アカウントで接続すると、元の利用者が参照できないデータまで扱える可能性があります。責任と履歴の追跡にも影響します。

MCPのHTTP向け認可仕様と、ローカルな接続での資格情報の扱いは同一ではありません。接続形態と対応仕様を確認し、製品の実装と自社の管理方針に合う方式を選びます。

必要最小限の機能とデータを公開する

最初に、利用者、会社、業務、操作、データの範囲を定めます。参照、下書き、承認、確定、削除を分け、必要な機能だけを公開します。便利さのために広い管理者権限を共通で与えないことが重要です。

データは取得後の利用も含めて確認します。AIへ送る情報、保存される場所、保持期間、ログ、学習への利用条件などを、対象サービスと契約で確認します。機密や個人情報が不要なら、取得・送信しない構成を考えます。

許可された情報でも、回答へ出してよい範囲は別に考える場合があります。集計結果から詳細が推測されることもあるため、どの粒度をどの利用者へ示すかを業務側と確認します。

領域	確認すること
認証・認可	利用者・接続元・許可範囲
業務承認	対象・変更内容・承認者
情報保護	送信・保存・保持・閲覧
実行制御	入力検証・重複防止・結果確認
運用	ログ・停止・復旧・変更管理

入力と外部情報を信頼し過ぎない

AIは、取得した文書や取引メモに含まれる文章を読む場合があります。そこに「別の情報を送れ」などの指示が書かれていても、業務上の命令として扱わない設計が必要です。外部の内容と、正当な利用者の依頼を区別します。

対策はプロンプトだけに依存しません。サーバーやERP側で、対象と値の検証、権限制御、許可する操作、送信先の制限を行います。モデルが誤って行動を選んでも、実行側で止められる境界を作ります。

MCP公式のセキュリティ資料では、認可に関する攻撃や資格情報の誤用などが扱われています。実装担当者は対象バージョンの公式仕様と安全対策を確認し、事業会社は実装内容と検証結果を説明してもらいます。

更新操作には承認と結果確認を置く

重要な操作では、対象、変更前後、金額や数量、操作の意味を人が確認できるようにします。「実行してよいか」という抽象的な表示だけでは、誤った対象を承認するおそれがあります。変更内容を具体的に示します。

承認が必要な条件と、ERP内の承認フローとの関係を決めます。AI側の確認ボタンが、社内の業務承認を代替するとは限りません。依頼者と承認者の分離など、自社が必要とする統制を維持します。

処理後は、ERPの登録番号や状態で結果を確認します。通信失敗の後に再試行する場合も、すでに実行されたかを確かめます。重複や不完全な取引の復旧方法を事前に設計します。

監査・停止・変更管理を運用へ組み込む

記録には、利用者、依頼、実行した操作、対象、承認、結果、エラーなどを含めます。ただしログに機密や資格情報を無制限に残さず、閲覧権限、保持、マスキングを設計します。調査できることと情報保護を両立します。

異常時には、対象機能や接続を止め、権限を取り消し、業務を代替できる手順を置きます。誰が停止を決め、誰が原因を調べ、いつ再開できるかを明らかにします。全体を止めず一部を止められる構成も検討します。

モデル、指示、ツール、認証、ERPの更新は、動作へ影響する変更です。重要なシナリオを再確認し、権限外の要求や悪意ある入力も試します。セキュリティを導入時のチェックだけで終わらせず、日常の運用へ組み込みましょう。

権限の境界を一つの依頼で検証する

国内営業の利用者が、通常は見られない海外子会社の受注を質問した例を考えます。AIの画面で拒否するだけでなく、取得要求の段階でサーバーやERPが対象を制限することが重要です。回答から消しても、取得やログへ保存した時点で不要な情報を扱っている可能性があります。

検証では、許可された対象、権限外の対象、曖昧な会社名、直接番号を指定した要求などを試します。検索一覧で制限されても、明細取得では制限が抜けることがないかも確認します。機能ごとの権限と、ERP利用者の権限の対応を追います。

記録には、誰が何を要求し、どの機能が何を取得し、どの判断で拒否したかが必要です。ただし、拒否の説明で対象の存在や機密を不用意に明かさないようにします。利用者へ示す内容と、運用担当者が調査する記録を分けます。

このように、認証が成功する試験だけでは安全性を評価できません。許可した業務ができることと、許可していない業務ができないことの両方を、具体的なシナリオで確かめましょう。

権限の変更と取り消しも試験します。接続時だけでなく、異動や退職、対象業務の終了後に不要なアクセスを止められることが、実際の管理には必要です。

よくある質問

MCP対応製品なら安全ですか？

規格への対応だけでは判断できません。公開機能、権限、資格情報、データの扱い、実装、運用と検証の結果を確認します。

すべての操作で毎回人が確認しますか？

影響と自社の業務ルールに応じて決めます。重要な更新には適切な承認を置き、参照でもアクセス権と情報保護は維持します。

次に確認すること

誰の権限で、何を読み、何を変え、誰が承認し、どこに記録するかを一つの業務シナリオで確認してください。

• MCPとは？ERP担当者向けに仕組みと確認ポイントを解説
• ERPでAIを活用できる業務と適用判断｜参照・分析・登録を分けて考える
• AI・MCP対応をERP選定でどう評価するか｜ベンダーへの質問と判断基準
• ERPのAI連携をどう導入・運用するか｜小規模検証から効果測定まで

AI・MCPの記事一覧へ

参考情報・編集方針

本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。

• MCP公式：Security Best Practices（2026-07-28）
• MCP公式仕様：Authorization（2026-07-28）
• MCP公式仕様：Tools（2026-07-28）

参考情報の確認日：2026年10月28日。運営方針・プロフィール