デモではうまく動いた。ところが社内展開の話になった途端、「その仕組みから、うちの基幹データはどこまで見えるんですか」と情報システム部門に問われて止まる——AIエージェントの導入では、この場面が繰り返されます。接続を標準化するMCP（Model Context Protocol）が普及し、企業向けアプリケーションでも対応が進みつつありますが、規格を選んだ後に待っているのは「自社の何を、どこまで、誰に公開するのか」という設計です。本記事では、MCPで社内システムをAIから使える形にする実装の進め方を扱います。なお個別API・MCP・連携基盤という手段の選び方は社内システムとAIエージェントをつなぐ方法で解説しています。
目次
MCPでの接続とは、社内システムの機能やデータを、AIが呼び出せる形で公開することです。つまり、システムを丸ごと開放するのではなく、公開する範囲を自分たちで定義する作業が中心になります。 AI側から見ると、MCPを介して「使える道具」が並んでいる状態になります。どの道具を置くか、その道具は何ができるのか、誰が使えるのかを決めるのは公開する側です。ここを曖昧なまま進めると、必要な情報が取れない、あるいは渡してはいけない情報まで見える、という両極端の失敗が起こります。まずは全体像を押さえておきましょう。「つなぐ」という言葉で想像しがちな配線作業ではなく、業務ルールの設計に近い作業だと捉えると、必要な検討事項が見えてきます。
公開する機能は、大きく読み取り（データを取得する）と操作（登録・更新・実行する）に分かれます。読み取りだけなら影響範囲は限定的ですが、操作を許すとAIの判断がそのまま業務データを書き換えます。最初は読み取りから始め、操作は対象と条件を絞って段階的に開くのが安全です。この2つを混ぜて設計すると、リスクの評価が難しくなります。たとえば「在庫を確認する」だけなら在庫が減ることはありませんが、「発注する」を許した瞬間から、AIの判断が取引として外部に出ていきます。「参照系のツール」「更新系のツール」と分けて定義しておけば、承認する側も判断しやすくなります。
社内システムにAPIが用意されていれば、それをMCPの形で見せる作業が中心になります。一方、APIがない、あるいはファイル連携やデータベース直接参照しか手段がないシステムでは、間に橋渡しの層が必要です。自社のシステムがどちらに当たるかで、作業の中身が変わります。APIがある場合は「公開範囲をどう決めるか」の議論が作業の大半を占めますが、ない場合はその手前に「データを取り出す経路をつくる」工程が丸ごと乗ります。着手前に、対象システムのインターフェース（API・ファイル出力・DB参照のどれが使えるか）を一覧にしておきましょう。
コードを書き始める前に、設計として決めるべきことがあります。技術的にはつなげても、公開範囲や権限が曖昧なままだと、セキュリティ審査で止まったり、運用開始後に想定外のアクセスが発覚したりします。ここが曖昧なまま進めると、後から作り直しになります。次の3点は、着手前に情報システム部門と業務部門、必要に応じて法務も交えて合意しておきたい論点です。決めた内容は文書に残しておくと、後の議論の蒸し返しを防げます。
「とりあえず全部つなぐ」ではなく、AIに何をさせたいかから逆算して公開範囲を決めます。たとえば「在庫を確認して回答する」なら、在庫の読み取りだけで足ります。発注まで任せたいと思ったとしても、それは次の段階の話として切り離せます。ユースケースを先に固めると、公開する機能は驚くほど絞れます。範囲が狭いほど、検証もセキュリティ設計も現実的になります。「将来使うかもしれない」機能まで先回りして公開すると、使われないまま管理対象だけが増えていきます。
AIがシステムを呼び出すとき、その処理は誰の権限で動くのかを決めます。共通のアカウントで全社分のデータにアクセスできる設計にすると、利用者ごとの制御ができません。利用者本人の権限を引き継ぐのか、限定的な専用アカウントを使うのかは、扱うデータの機微性に応じて選びます。ここは後から変えにくいため、最初に決めておくべき論点です。利用者の権限を引き継ぐ設計にすると、既存のシステム権限をそのまま活かせるという利点もあります。
同じ「顧客情報」でも、全項目を渡すのか、氏名と取引状況だけにするのかで、リスクも精度も変わります。必要のない項目は渡さないのが原則です。個人情報や機密度の高い項目は、マスキングして渡す設計も検討します。渡す情報を絞るほど、AIが誤って外部へ持ち出すリスクも下がります。クラウドのAIサービスを使う場合は、そのデータが自社の外に出るという前提で項目を選ぶ必要があります。
設計が固まったら、実装に入ります。一度に全システム・全機能を対象にすると、検証が追いつかず、問題が起きたときの切り分けも難しくなります。1つのユースケースで通しで動かし、そこで得た型を横に広げるのが失敗しないコツです。次の4ステップで進めます。
まず1つの業務、1つの読み取り機能から始めます。動く状態を早く作り、AI側から実際に呼び出して結果を確認します。ここで、返すデータの形式や粒度が実用に耐えるかが見えてきます。最初から多機能を目指すより、1本を通して感触をつかむほうが確実です。実際に使ってみると、想定していた項目が不足していたり、逆に不要だったりすることに気づきます。この気づきを設計へ戻せるのが、小さく始める最大の利点です。
MCPに対応していない基幹システムや、APIを持たない古いシステムは、間に層を置いて橋渡しします。データ連携基盤で対象システムからデータを取得・整形し、その結果をAIへ渡せる形にすれば、システム自体を改修せずに対応できます。この橋渡しがあるかどうかで、つなげる範囲は大きく変わります。多くの日本企業では、基幹の中核に長年使われてきたシステムが残っているため、ここが実用性の分かれ目になります。新しいSaaSだけがつながっても、肝心の業務データが取れなければ意味がありません。
システムから取り出したままのデータは、コード値や省略表記が多く、AIが正しく解釈できないことがあります。コードを名称に変換する、単位をそろえる、不要な項目を落とすといった整形を挟むと、回答の精度が上がります。データ連携の考え方をそのまま適用できる領域です。渡す前のひと手間が、精度に直結します。人が見て意味の分かるデータになっているかを、一度目視で確認しておくとよいでしょう。
読み取りが安定したら、登録や更新といった操作系を検討します。ただし、いきなり本番データを書き換えられる設計にはせず、確認を挟む、対象を限定する、取り消せるようにするといった安全策を組み込みます。自動実行の範囲は、業務影響の小さいものから順に広げていきます。金額や在庫が動く処理は、人の承認を挟む設計から始めるのが無難です。
実際に取り組むと、設計段階では見えなかった問題が出てきます。いずれもMCPという仕組み自体の問題ではなく、社内システムの実情とAIの使い方が噛み合わないことから生じるものです。あらかじめ知っておくと、設計段階で手を打てます。代表的な4つを挙げます。
便利さを優先して多くの機能を公開すると、誰が何にアクセスできるかを把握できなくなります。そして厄介なのは、開けたものを閉じるほうが難しいという点です。業務部門が既に日常的に使っていれば止められず、誰がどう使っているか分からないため影響も読めない。最小限から始めて必要に応じて足す、という順序を守りましょう。
公開した機能を後から見直せるようにするには、何を公開しているかの一覧と、追加・削除の履歴が必要です。「使われていないなら閉じよう」と判断するためにも、利用状況を把握できる状態が前提になります。半年に一度、使われていない機能を閉じる棚卸しを予定に組み込んでおくと、公開範囲が一方的に広がるのを防げます。監査で問われたときに、その場で説明できる状態にもなります。
AIからの呼び出しに対して、基幹システムの検索が数十秒かかるようでは、対話として成立しません。あらかじめ集約したデータを用意しておく、検索条件を絞る、といった工夫が必要です。リアルタイム参照にこだわらず、用途によっては定期的に同期したデータを見せる設計も有効です。
データ連携について詳しく学ぶ（無料ダウンロード）
同期したデータを見せる設計にした場合、元システムの更新をどう反映するかが課題になります。反映の仕組みがなければ、AIは古い情報を最新として答えます。更新の検知と反映を自動化しておくことが、精度を保つ条件です。ここは運用に入ってから効いてくる部分です。公開した直後は正しく動いていても、数か月後に「答えが古い」と指摘されるのはこのパターンです。
MCP非対応のレガシーや独自システムも含めてAIへ渡すデータを用意する役割は、データ連携基盤「ASTERIA Warp」（累計10,000社超）が引き受けられます。100種類以上のアダプターで基幹システム・SaaS・DB・ファイルからデータを取得し、コード変換や項目の絞り込み、マスキングといった整形を経て渡す流れを、ノーコードで構築できます。渡す範囲を項目単位で設計できるため、公開しすぎを防ぐ制御にも役立ちます。更新分だけを反映する差分連携も設定でき、参照データの鮮度を保てます。実際にアステリア自身が生成AI「Dify」やOpenAIと連携したAI回答システムを構築した事例があります。システムを改修せずにAIから使える状態をつくる、という選択肢として検討してみてください。
Q. MCPで社内システムをつなぐとき、最初に決めるべきことは何ですか？
A. 「何を公開するか」です。AIに何をさせたいかから逆算すると、公開すべき機能は絞り込めます。あわせて、誰の権限で実行するか、どの項目まで渡すかを先に決めておきましょう。
Q. APIがない古いシステムもつなげますか？
A. 間に橋渡しの層を置けば対応できます。データ連携基盤で対象システムからデータを取得・整形し、AIへ渡せる形にすれば、システム自体を改修せずに済みます。MCP非対応のシステムをどう扱うかが、実用性の分かれ目になります。
Q. 読み取りだけでなく、登録や更新もAIに任せてよいですか？
A. 段階的に開くのが安全です。まず読み取りで安定させ、操作系は確認を挟む・対象を限定する・取り消せるようにするといった安全策とセットで検討します。業務影響の小さいものから順に広げましょう。
Q. 回答が遅い・古い情報が返る場合は？
A. 応答が遅い場合は、あらかじめ集約したデータを見せる設計が有効です。ただしその場合、元システムの更新をどう反映するかが課題になります。更新の検知と反映を自動化しておくことが、精度を保つ条件です。
MCPで社内システムをAIにつなぐ作業の中心は、コードを書くことではなく「何を、どこまで、誰に公開するか」の決定です。ユースケースから逆算して範囲を絞り、実行権限とデータの粒度を先に決め、読み取り機能1つから段階的に広げます。MCP非対応のレガシーは間に橋渡しの層を置き、データを整えてから渡します。公開しすぎ・応答の遅さ・更新の反映漏れという3つのつまずきにも備えておきましょう。社内システムとAIの間を担う基盤には、「ASTERIA Warp」という選択肢もあります。
▼ 渡す範囲を絞る設計を、自分の環境で試す ASTERIA Warpは全機能を試せる無料体験版をご用意。AIへ渡すデータの取得・整形も、サーバー準備不要ですぐに体験できます。 |
PM・SE・マーケティングなど多彩なバックグラウンドを持つ「データ連携」のプロフェッショナルが、専門領域を超えたチームワークで「データ活用」や「業務の自動化・効率化」をテーマにノウハウやWarp活用法などのお役立ち情報を発信していきます。
ASTERIA Warp製品の技術情報やTips、また情報交換の場として「ADNフォーラム」をご用意しています。
アステリア製品デベロッパー同士をつなげ、技術情報の共有やちょっとしたの疑問解決の場とすることを目的としたコミュニティです。
