AI・MCP対応をERP選定でどう評価するか｜ベンダーへの質問と判断基準
KXSfourthERPのAI・MCP対応は、対応の有無だけでは比較できません。どの業務を、どの利用者が、どの権限と承認で使えるかを確認する必要があります。本記事では、選定時に確認する七つの領域と、公開情報・提案・検証を区別して評価する方法を説明します。
この記事の要点
- AI対応の名称ではなく、現在使える業務・環境・条件で評価する
- 接続性、業務機能、セキュリティ、統制、運用、実現性、将来の変更を確認する
- 予定と提供済み、説明と実証を区別して判断を残す
Agenda（この記事の内容）
評価は使いたい業務から始める
最初に、誰が何を知り、何を作成し、どこまで実行するかを定めます。例えば在庫の参照と受注の確定では、必要な機能と統制が異なります。製品のAI機能一覧を、そのまま自社の評価表にしないことが重要です。
利用場面には、対象会社、データ、処理量、結果の確認方法、例外、許容できる失敗を記載します。曖昧な指示では確認を求める、権限外は拒否するなど、望ましい振る舞いも評価条件に含めます。
従来の業務適合性や費用の評価を置き換えるわけではありません。AI活用に必要な条件を追加し、自社の目的に関係する範囲で重み付けします。AI機能が魅力的でも、基礎となる取引やデータが適合しなければ導入は成立しません。
接続性と業務機能を確かめる
接続性では、MCP、API、標準コネクターなどの方式、対応仕様、利用環境、認証を確認します。提供者と保守窓口も調べます。接続できることと、自社が必要な操作を実行できることを分けます。
業務機能では、参照、下書き、更新、承認、取消などの範囲を確認します。必要なデータ項目や状態が扱えるか、標準の検証と業務ルールが適用されるかを見ます。複数会社や特殊な取引の条件も質問します。
公開資料には、対象バージョン、契約、地域、試験提供などの条件が付くことがあります。提供済み、限定提供、予定、未確認を区分し、現時点の利用条件を記録します。将来予定を確定した要件充足として採点しません。
| 領域 | 主な確認 |
|---|---|
| 接続性 | 方式・仕様・環境・提供者 |
| 業務機能 | 操作・データ・状態・制約 |
| セキュリティ | 認証・権限・情報保護 |
| 統制 | 承認・記録・結果確認 |
| 運用 | 監視・復旧・責任 |
| 実現性 | 費用・構築・人の負担 |
| 変更対応 | 更新・移行・支援・提供終了 |
セキュリティと統制を確認する
セキュリティでは、利用者の識別、権限の対応、データの送信と保管、資格情報の管理を確認します。利用者がERPで見られない情報をAI経由で見られないか、会社や部門の制限が維持されるかを見ます。
統制では、実行前の確認、業務承認、職務分離、監査記録、結果の確認を評価します。チャット上で確認しただけでERP側の承認を迂回しないかなど、実際の取引シナリオで確認します。
ベンダーの説明だけでなく、権限外の依頼や誤った入力への動作も見ます。安全機能があるという名称より、どこで何を防ぎ、誰が設定し、どの証拠が残るかを確認することが重要です。
運用・実現性・変更への対応を見る
運用では、監視、障害の切り分け、再実行、重複防止、停止、復旧、問い合わせの責任を確認します。AIが失敗を報告した場合に、実際の取引が作られているか調査できる必要があります。
実現性には、追加の契約、構築、環境、社内工数、利用料、確認作業を含めます。AIの回答にかかる料金だけでなく、データ整備、保守、人のレビューの負担も見ます。試験環境と本番環境の差も確認します。
将来の変更では、MCP、API、モデル、ERPの更新への追随と支援範囲を評価します。移行や代替の方法、データの取り出し、提供終了時の扱いを確認します。抽象的な将来性より、変更に対応する仕組みを見ます。
共通シナリオで根拠を残す
各候補へ同じ業務シナリオを示し、通常、曖昧な依頼、権限外、通信失敗、重複などを確認します。デモが実接続か模擬か、標準機能か追加構築かを記録します。重要な条件は小規模検証で確かめます。
評価欄には、対応範囲、制約、根拠、確認日、費用、未確認事項を残します。資料に書かれた可能性と、自社条件で動作した事実を同じ確度で扱いません。必須条件は総合点で相殺しないようにします。
最終判断では、AI活用の効果と運用の成立性を一緒に説明します。現時点で使える範囲と、将来の期待を分けることで、導入後の認識差を減らせます。評価表は、導入時の検証と運用準備へ引き継ぎましょう。
提案の「対応可能」を分解して質問する
「MCP経由で受注登録に対応」という回答があったとします。まず、対象ERPとバージョン、自社の利用環境、提供時期を確認します。次に、下書きか確定か、扱える取引条件、標準の承認や入力検証、利用者権限への対応を質問します。この回答を分解すると、実際に評価すべき範囲が見えます。
実演では、通常の一件だけでなく、必須項目不足、権限外、同じ依頼の繰り返し、途中の通信失敗を確認します。実演できない条件は未確認として残し、資料や検証の予定を置きます。対応するという言葉の広さを、採点の根拠へそのまま持ち込まないことが重要です。
費用も同様です。MCPサーバーが標準提供でも、自社向けの業務機能、認証設定、ログ連携、運用支援が別費用になる可能性があります。何が含まれ、誰が維持するかを確認します。技術と業務、費用、運用をつなげて質問することで、候補の差を具体的に説明できます。
比較の結果は、採点と証拠を分けて保存します。将来仕様が変わったとき、評価を更新するべき項目を見つけやすくなります。
提供済みの機能でも、自社の環境で確認していない項目は未検証と残します。公開情報の確認と、自社の業務適合性の確認を別の欄で管理すると、次の調査が明確になります。
よくある質問
MCP対応は必須条件にすべきですか？
必要な業務と接続構成によります。APIや製品内機能で目的を達成できる場合もあり、名称ではなく実現条件から判断します。
ロードマップを評価してもよいですか？
将来計画として別に記録できますが、提供済みと区別します。重要な必須要件を満たす根拠にする場合は、条件と不確実性を明示します。
次に確認すること
候補ごとに、必要な業務で「提供済み・条件付き・予定・未確認」を分け、根拠と検証予定を記載してください。
- ERP製品を比較する評価軸と評価表の作り方
- MCPとは？ERP担当者向けに仕組みと確認ポイントを解説
- ERPでAIを活用できる業務と適用判断｜参照・分析・登録を分けて考える
- ERPとAI・MCP連携のセキュリティ｜権限・承認・監査を設計する
- ERPのAI連携をどう導入・運用するか｜小規模検証から効果測定まで
参考情報・編集方針
本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。
- MCP公式仕様：Tools（2026-07-28）
- MCP公式仕様：Authorization（2026-07-28）
- MCP公式：Security Best Practices（2026-07-28）
参考情報の確認日：2026年10月28日。運営方針・プロフィール
