AIエージェントと既存システムの連携設計——MCP・APIで基幹・SaaSと接続する方法

AIエージェント導入が進まない本当の理由——「つなぐ」設計の難しさ

AIエージェントが業務で機能しない根本原因

AIエージェントへの関心は、ここ1〜2年で急速に高まっています。しかし、「導入を検討したが、結局止まっている」という企業は少なくありません。その理由の多くは、LLM（大規模言語モデル）の性能への不満ではなく、既存システムとの接続設計がボトルネックになっていることにあります。

AIエージェントは、指示を受けて自律的にタスクを実行できる点が強みです。ただし、そのタスクの大半は「社内データを参照する」「業務システムに書き込む」「複数ツールをまたいで処理を完結させる」といった操作を含みます。つまり、AIエージェント単体では業務に組み込めないケースがほとんどです。

実際の導入現場では、次のような壁にぶつかることが多い傾向にあります。

• 社内DBや基幹システムにAPIが整備されておらず、データを渡せない
• SaaSごとに接続方式が異なり、連携設計が複雑化する
• セキュリティ要件との整合性を取る段階で、プロジェクトが止まる

LLMの性能がいくら高くても、参照できるデータと操作できるシステムの範囲が、AIエージェントの実力の上限を決めます。「つなぐ」設計の巧拙が、活用レベルを左右するのです。

本記事で解説する内容のスコープ

本記事では、AIエージェントと既存システムを接続するための設計論を、意思決定者が判断できる粒度で整理します。具体的には、接続の基本構造、MCP（Model Context Protocol）とAPIの違いと使い分け、基幹システム・SaaSそれぞれの連携設計のポイント、セキュリティ・ガバナンスの確認観点、そしてPoC（概念実証）から本番移行までの進め方を順に解説します。

技術的な実装詳細よりも、「何を・どういう順序で・どう判断するか」に焦点を当てています。社内推進の根拠を整理したい方や、外部ベンダーとの要件定義に臨む前の確認材料としても活用できます。

AIエージェントとシステム連携の基本構造——どのように外部と「つながる」か

LLMとツール呼び出しの仕組み——推論と実行を分けて考える

AIエージェントの中核にあるLLM（大規模言語モデル）は、あくまで「推論エンジン」です。質問に対して何をすべきかを判断する能力は持っていますが、それ自体は社内データベースへのアクセスも、業務システムへの書き込みも、単独では行えません。

この問題を解決する仕組みがツール呼び出し（Function Calling / Tool Use）です。LLMがユーザーの指示を解釈し、「この処理にはどのツールを使うべきか」を判断した上で、外部システムへの操作を呼び出します。たとえば「先月の受注データを集計してレポートを作成して」という指示に対し、LLMはまずデータ取得ツールを呼び出し、次に集計処理、最後にレポート生成という順序を自律的に組み立てます。

重要なのは、推論（LLM）と実行（外部ツール）が明確に分離されているという構造です。この分離を正しく理解することが、AIエージェントの連携設計を考える出発点になります。

主要な連携方式の全体マップ——API / MCP / RPA / DB接続

AIエージェントが外部システムと連携する方式は、大きく4つに整理できます。

• API連携：システムが公開するエンドポイントを通じてデータの取得・送信を行う。SalesforceやSlackなど多くのSaaSが対応しており、最も汎用的な手段です。
• MCP（Model Context Protocol）：Anthropicが提唱した、LLMとツール群を接続するための標準プロトコル。複数ツールの管理や権限制御をまとめて扱える設計で、エージェント活用での注目度が高まっています。
• RPA連携：既存のデスクトップアプリやAPIを持たないレガシーシステムに対し、画面操作を自動化する形で接続します。柔軟性はある一方、システム変更に弱い側面もあります。
• DB直接接続：SQLなどを通じてデータベースに直接アクセスする方式。リアルタイム性は高いですが、セキュリティ設計と権限管理が特に重要になります。

本記事では、この中でもAPIとMCPを重点的に取り上げます。多くのBtoB企業が利用するSaaSや基幹システムとの接続において、現実的な選択肢の中心になるためです。RPAやDB直接接続については、それぞれの連携設計のセクションで必要に応じて補足します。

MCPとは何か——APIとの違いと、AIエージェント連携における役割

MCPの定義——LLMがツールを「使いこなす」ための共通仕様

MCP（Model Context Protocol）は、Anthropicが提唱したオープン標準規格です。大規模言語モデル（LLM）が外部のツールやデータソースを「発見し、呼び出し、結果を受け取る」ための共通インターフェース仕様として設計されています。

従来、AIに外部ツールを使わせるには、ツールごとに個別の呼び出し方法を実装する必要がありました。MCPはその実装方法を標準化することで、AIエージェントがさまざまなツールを統一的な方法で扱えるようにします。いわば「AIエージェント専用の共通コネクター規格」と理解するとわかりやすいでしょう。

APIとMCPの違いを比較表で整理する

APIとMCPはどちらも「システム間の接続」に使われますが、設計の目的と対象が異なります。意思決定の場面では、この違いを正確に把握しておくことが重要です。

APIは既存システムの汎用的な接続手段として引き続き有効です。一方MCPは、AIエージェントがツールを自律的に扱うことを前提に設計された専用プロトコルという位置づけになります。

MCPを導入すると何が変わるか——ツール統合の効率と自律度

MCPを採用することで、AIエージェントの連携設計には具体的な変化が生まれます。主なポイントは以下の3点です。

• ツール定義の標準化：各ツールの呼び出し仕様をMCPの形式で定義することで、AIエージェントが「何ができるツールか」を自動的に解釈できるようになります。ツールごとに個別の実装コストを削減できます。
• 複数ツールの動的な切り替え：タスクの内容に応じて、AIエージェントが適切なツールを自律的に選択・切り替えられます。たとえば、社内DBへの照会とSlackへの通知を状況に応じて自動的に使い分けるといった動作が実現しやすくなります。
• エージェントの自律度向上：ツールを「発見→選択→呼び出し→結果処理」までAIが自律的に行えるため、人間が細かい処理順序を指定しなくても複雑な業務フローを実行できるようになります。

MCPは現時点で標準化が進行中の仕様であり、対応するツールやプラットフォームは急速に増えています。既存のAPIを完全に置き換えるものではなく、AIエージェント活用においては両者を目的に応じて使い分ける設計が現実的です。

基幹システムとの連携設計——ERPやDB接続で押さえるべきポイント

AIエージェントを業務に組み込む際、最初の壁になりやすいのが基幹システムとの接続設計です。ERPや販売管理・在庫管理・会計システムは、企業の中核データを持つ一方で、外部接続を想定していない構成も少なくありません。どのパターンで接続するかによって、データの鮮度・権限の制御・障害時のリスクが大きく変わります。

ERP・販売管理・会計システムへの接続パターン

基幹システムとAIエージェントを接続する方法は、大きく3つに整理できます。

• REST API経由の接続：SAP S/4HANAやOracleなど、APIを公開しているERPではREST APIを介した連携が標準的な選択肢です。リアルタイムにデータを取得・更新でき、データの鮮度を保ちやすい反面、API呼び出しの負荷管理やレート制限への対応が必要になります。
• DB読み取り専用ビュー経由の接続：APIが整備されていても、参照系のクエリに限定したい場合は、データベース上に読み取り専用ビューを作成し、そこにAIエージェントをつなぐ方法が有効です。本番DBへの直接接続は書き込みリスクを伴うため、ビューを介することで影響範囲を限定できます。
• バッチ連携との組み合わせ：リアルタイム性が不要な用途——在庫の日次集計や月次の売上サマリーなど——では、定時バッチでデータを中間テーブルに格納し、AIエージェントはそこを参照する構成が現実的です。基幹システムへの負荷を分散しつつ、安定した連携を実現できます。

意思決定者が特に気にするべきポイントは「データの鮮度」です。AIエージェントが参照するデータが何時間前のものかによって、エージェントの回答精度や意思決定の妥当性が変わります。用途ごとにリアルタイム接続とバッチ接続を使い分ける設計が重要です。

APIが整備されていない基幹システムへの対処法

製造業や流通業では、10年以上前に構築されたERPや独自開発の販売管理システムが現役で稼働しているケースが多くあります。こうしたシステムはAPIを持たないことも多く、直接接続が難しい状況です。その場合の対処法として、以下の2つのアプローチが選択肢になります。

• RPAブリッジ：RPA（Robotic Process Automation）ツールを介して、画面操作でデータを取得・入力する方法です。既存システムを改修せずに連携できる点が利点ですが、画面レイアウトの変更に弱く、安定性の面でリスクを伴います。
• CSVブリッジ：基幹システムが出力するCSVファイルを定期的に取り込み、AIエージェントが参照する中間データベースに変換する方法です。シンプルで導入ハードルが低い反面、データの鮮度はCSVの出力タイミングに依存します。

いずれの方法も、あくまで「つなぐための橋」であり、本番運用での安定性確保には別途の監視設計が必要です。将来的なAPI整備も視野に入れながら、段階的な移行計画を立てておくことが望ましいです。

書き込み操作を伴う連携——承認フローと権限設計の考え方

AIエージェントが基幹システムに対してデータを書き込む操作——発注データの登録や在庫更新など——を行う場合、権限設計と承認フローの整備が不可欠です。

まず押さえるべきは「書き込み権限を最小限に絞る」原則です。AIエージェントに付与するDBアカウントやAPIキーには、必要な操作だけを許可します。たとえば、発注候補の登録は可能でも、確定・送信は人間の承認を経るよう設計します。

障害時の影響範囲も事前に整理しておく必要があります。AIエージェントが誤ったデータを書き込んだ場合のロールバック手順、連携先システムがダウンしたときのエージェント側のフォールバック動作——これらを設計段階で明確にしておかないと、障害対応が属人的になりやすいです。

承認フローの設計としては、「AIエージェントが起票→担当者が確認・承認→基幹システムに書き込み」という段階を設けるパターンが、リスクとスピードのバランスを取りやすい構成です。AIに自律的な書き込みを許可するかどうかは、業務の重要度とデータの影響範囲に応じて判断することが求められます。

SaaSとの連携設計——Salesforce・Slack・kintoneなど業務ツールへの接続

企業内で広く使われているSaaSは、ERPや基幹DBと比べるとAPIの整備が進んでいます。Salesforce・Slack・kintone・Notionといったツールの多くは、REST APIとOAuth認証を標準で提供しており、AIエージェントとの接続を比較的スムーズに始められます。ただし「つなぎやすい」ことと「安全・安定して動く」ことは別の話です。接続方式の選定とレート制限・スコープの設計を誤ると、本番環境で予期しない停止やデータ漏洩リスクを招くことがあります。

主要SaaSの接続方式——OAuth・Webhook・公式APIの使い分け

SaaSとAIエージェントをつなぐ方法は、大きく3つに分かれます。

• REST API（公式API）：エージェント側から能動的にデータを取得・更新する。Salesforceの商談情報を取得してレポートを生成する、kintoneのレコードを更新するといった処理に向いています。
• Webhook：SaaS側でイベントが発生したときに、エージェントへ通知を送る仕組み。「Slackで特定のキーワードを含むメッセージが投稿されたら処理を起動する」といったリアルタイム連携に使います。
• OAuth 2.0認証：ユーザーの代理でAPIを呼び出す際の認証基盤。エージェントが誰の権限で操作するかを明確にするために必要です。サービスアカウントを使う場合も、スコープ（権限範囲）を最小限に設定することが基本です。

これら3つは排他的ではなく、組み合わせて使います。たとえば「SlackのWebhookで起動し、OAuthで認証した上でSalesforceのAPIを呼び出す」という構成が典型的なパターンです。

MCP Serverとして複数SaaSをまとめる設計パターン

AIエージェントが参照するSaaSが複数になると、各ツールのAPI仕様の差異をエージェント側で吸収しなければならず、保守コストが増大します。この課題に対して有効なのが、各SaaSをMCP（Model Context Protocol）Serverとして包むアプローチです。

Salesforce用・Slack用・kintone用のMCP Serverをそれぞれ用意し、エージェントには統一されたインターフェースだけを公開します。SaaS側のAPI変更があっても、修正はMCP Server内に閉じ込められるため、エージェントのロジックに影響が波及しにくくなります。将来的にSaaSを乗り換える際も、差し替えるのはMCP Serverだけで済むことが多く、拡張性の高い構成を維持できます。

レート制限・スコープ制御——SaaS連携で起きやすい問題と対策

SaaS連携で実際に問題が発生しやすいポイントは次の3点です。

• レート制限の超過：AIエージェントは自動で繰り返しAPIを呼び出すため、人間の操作よりも短時間で上限に達しやすい傾向があります。エージェント設計の段階でAPI呼び出し頻度を見積もり、リトライロジックやキャッシュ戦略を組み込む必要があります。
• スコープの過剰付与：「とりあえず広い権限を渡しておく」という設計は、情報漏洩や誤操作のリスクを高めます。エージェントが実際に必要とする操作だけに絞ったスコープを定義することが重要です。
• アクセストークンの管理：OAuthのアクセストークンには有効期限があります。期限切れを考慮したリフレッシュ処理を組み込まないと、業務時間外の自動処理が突然停止するケースがあります。トークンの保管場所についても、環境変数やシークレット管理サービスを使い、コードに直書きしない運用を徹底する必要があります。

SaaSはAPIが整備されている分、初期接続のハードルは低いです。一方で、自動化の範囲が広がるほどこれらの問題が顕在化しやすくなります。PoC（概念実証）段階から運用を想定した設計を意識することが、スムーズな本番移行につながります。

セキュリティ・ガバナンス設計——意思決定者が確認すべき6つの観点

AIエージェントを既存システムと連携させる際、技術的な接続方法と同じくらい重要なのがセキュリティとガバナンスの設計です。エージェントは自律的に外部システムを操作するため、従来のWebアプリケーションとは異なるリスク管理の視点が求められます。意思決定者として連携設計を承認する前に、以下の6つの観点を確認してください。

認証・認可——APIキーとOAuth、RBACの使い分け

AIエージェントが外部システムにアクセスする際の「誰として、何の権限で接続するか」は、設計段階で明確にしておく必要があります。

• APIキー管理：静的なAPIキーは漏洩リスクが高く、環境変数や秘密情報管理ツール（AWS Secrets ManagerやHashiCorp Vaultなど）で保管し、定期的なローテーションを仕組み化することが基本です。
• OAuth 2.0：SalesforceやGoogle WorkspaceなどのSaaS連携では、OAuth 2.0による短命トークンを使うことで、エージェントに恒久的な資格情報を渡さずに済みます。
• RBAC（Role-Based Access Control：ロールベースアクセス制御）：エージェントに付与するロールを業務用途ごとに定義し、「受注データの読み取りのみ可」「在庫更新は不可」といった粒度で制御します。

MCP（Model Context Protocol）サーバーを経由する構成では、MCPサーバー側でRBACを一元管理することで、LLM（大規模言語モデル）から直接システムにアクセスさせない設計が取りやすくなります。

また、最小権限の原則——エージェントに与える権限を業務遂行に必要な最低限に絞る考え方——は、連携先ごとに適用してください。「便利だから広めに権限を渡す」という判断が、後のインシデントにつながるケースが少なくありません。

ログ・監査証跡——誰が何をいつ実行したかを追えるか

AIエージェントが自律的にシステムを操作する以上、「どのエージェントが、どのツールを、いつ、どの引数で呼び出したか」を記録する仕組みが不可欠です。特に基幹システムへの書き込み操作は、事後に操作内容を復元できる監査証跡の設計を求められる場面があります。

確認すべき設計要素は次のとおりです。

• ツール呼び出しのリクエスト・レスポンスのログ記録（タイムスタンプ・ユーザーID・セッションIDを含む）
• ログの改ざん防止措置（書き込み専用ストレージへの転送や電子署名）
• 保存期間とアクセス権限の設定（ログ自体への不正アクセスを防ぐ）

機密データのマスキング・フィルタリングも、ログ設計と一体で検討してください。個人情報や与信情報がログにそのまま記録されることを防ぐため、ログ出力前にPII（Personally Identifiable Information：個人識別情報）を自動でマスクする処理を設けることが望ましいです。

さらに、エージェントがLLMに渡す入力データ・LLMから受け取る出力データの取り扱いポリシーも明示しておく必要があります。社内の機密情報や顧客データをLLMのAPIに送信する場合、利用規約上の学習データへの使用可否、データの保存場所、暗号化の有無を事前にベンダーと確認した上で、社内ポリシーとの整合を取ってください。

自律実行の範囲設計——どこに人間の承認ゲートを置くか

AIエージェントの「自律実行」は、設計次第で業務効率化にも重大なリスクにもなります。すべての操作を自動化するのではなく、影響範囲・可逆性・リスクの大きさに応じて「人間の承認ゲート」を設けることが、ガバナンス設計の核心です。

承認ゲートを置くべき操作の例として、以下が挙げられます。

• 受注データや契約情報の新規登録・更新
• 一定金額以上の発注や支払い処理のトリガー
• 顧客への外部メール・通知の送信
• システムアカウントの作成・権限変更

実装上は、エージェントが操作を実行する前に「承認リクエスト」をSlackや社内ワークフローに送り、担当者が明示的に許可した場合のみ処理を進める構成が有効です。この「Human-in-the-Loop（人間介在型）」の設計をどの操作に適用するかは、業務リスクの評価とセットで意思決定者が判断すべき事項です。

承認ゲートの設計が曖昧なまま本番稼働させると、エージェントが意図しない操作を完了させた後に発覚するケースがあります。PoC（概念実証）段階から「どこで人が確認するか」を明示的に設計に組み込んでおくことが重要です。

連携設計の判断フロー——MCPとAPIをどう使い分けるか

MCPとAPI直接呼び出しの違いを理解したうえで、実際の導入場面では「自社の要件にどちらが適切か」という判断が求められます。以下の観点を順に確認することで、選択の方向性が見えてきます。

MCP優位のケース——複数ツールを動的に組み合わせる自律型エージェント

次のいずれかに当てはまる場合は、MCPを基盤とした連携設計が適しています。

• エージェントが状況に応じて呼び出すツールを自律的に選択する必要がある
• CRM・ドキュメント管理・社内DBなど複数システムをまたいで情報を取得・操作するワークフローがある
• 将来的にツールの追加・変更が頻繁に発生することが見込まれる

たとえば、「問い合わせ内容をSlackで受け取り、Salesforceで顧客情報を確認し、社内ナレッジDBから回答案を生成して担当者に提示する」といった複合的な処理がこれに該当します。MCPのサーバー構造により、ツールの追加がエージェント本体の改修なしに行えるため、拡張性が確保されます。

API直接呼び出しが現実的なケース——単機能・高頻度の定型連携

一方、以下の条件が揃う場合はAPI直接呼び出しのほうが実装コストと運用負荷を抑えられます。

• 呼び出し先のシステムが1〜2つに限定されており、処理内容が固定されている
• エージェントの自律判断は不要で、定型の手順をそのまま実行すればよい
• 既存のREST APIが整備されており、認証・エラー処理の知見が社内にある

毎日決まった時刻にERPから売上データを取得してレポートを生成するような処理は、MCPを介さずAPIを直接叩くほうがシンプルで安定します。

両者を組み合わせるハイブリッド構成の考え方

実際の導入では、定型処理はAPI直接呼び出しで実装し、自律的な判断が必要な部分だけMCPで拡張するハイブリッド構成が現実的な選択肢になるケースが少なくありません。たとえば、基幹システムへの書き込みはAPI経由で制御しつつ、情報収集・判断のフェーズはMCP経由で複数ツールを動的に参照するといった設計です。開発リソースが限られている場合は、まずAPI連携でPoC（概念実証）を進め、ユースケースの複雑性が増した段階でMCPへの移行を検討するアプローチも有効です。

連携設計の進め方——PoC段階から本番移行までのステップ

AIエージェントの連携設計は、一度に全体を構築しようとするとリスクが集中します。PoC（概念実証）から段階的に本番へ移行する進め方が、社内承認を得やすく、失敗時の影響も限定できます。

PoC設計——連携先を絞り、リスクを最小化する

PoC段階では、連携対象を単一のSaaSに限定することを推奨します。たとえばSlackのみ、あるいはkintoneのみを対象にし、操作権限は読み取り専用に制限します。書き込みや更新を伴う処理は、この段階では対象外とするのが原則です。

検証すべきポイントは次の3点です。

• レイテンシ：エージェントがAPIやMCPを経由してデータを取得するまでの応答時間が、業務利用に耐えられるかを確認します
• 精度：エージェントが意図した操作を正しく実行できているか、誤判断の頻度はどの程度かを記録します
• エラーハンドリング：接続失敗や認証エラーが発生した際に、エージェントが適切に処理を中断・通知できるかを検証します

このスコープで2〜4週間程度の検証期間を設けることで、社内への報告材料が揃います。

本番移行の条件——精度・負荷・セキュリティの検証基準

本番移行には、PoCで得られたデータをもとに判断基準を設けます。目安として、以下の条件をクリアしていることが望まれます。

• 意図した操作の正答率が90%以上を安定して維持できている
• ピーク時の負荷をかけた状態でも、レイテンシが許容範囲内に収まっている
• 認証トークンの管理・通信の暗号化・アクセスログの記録が整備されている

移行時は、書き込み・更新処理を段階的に解放します。まず低リスクな補助業務（ドラフト作成・データ参照）から開始し、承認後に更新・登録処理へと自律度を拡張していく方針が現実的です。

運用フェーズでの監視設計——エラー検知と再実行制御

本番稼働後は、エラーの検知と再実行の制御を仕組みとして整備することが重要です。エージェントが外部システムに接続できなかった場合、無制限にリトライを繰り返すと、基幹システムへの負荷集中やデータ重複登録につながるリスクがあります。

最低限、以下の監視体制を設けることを検討してください。

• アラート設計：エラー発生時にSlackやメールで担当者へ即時通知する仕組みを用意する
• リトライ上限の設定：再実行の回数・間隔に上限を設け、超過した場合は処理をキューに積んで人間が確認できる状態にする
• 操作ログの可視化：エージェントがいつ・どのシステムに・何の操作をしたかを記録し、定期的にレビューできる環境を整える

監視設計の粒度は、エージェントが持つ権限の大きさに比例させることが基本です。自律度が高まるほど、人間が介在できるチェックポイントを意図的に設けるよう設計してください。

まとめ——AIエージェント連携設計で押さえるべき要点

本記事で解説した内容を、意思決定の参考として簡潔に整理します。

MCPとAPIの役割の違い

• APIは特定の機能を呼び出すための接続口であり、連携先ごとに個別の実装が必要です
• MCP（Model Context Protocol）はAIエージェントが複数ツールを横断して操作するための共通プロトコルで、接続の標準化と再利用性を高めます
• どちらか一方ではなく、用途に応じて組み合わせて使うケースがほとんどです

基幹・SaaS別の接続パターン

• 基幹システム（ERP・DB）：REST APIまたはDBへの直接接続が中心。変更が難しいレガシー環境ではAPIラッパーの追加が現実的な選択肢になります
• SaaS（Salesforce・Slack・kintoneなど）：公式APIやWebhookを活用しつつ、MCP対応ツールは標準プロトコルで接続できます

セキュリティ設計の6つの観点

1. 認証・認可の範囲設計（最小権限の原則）
2. 通信経路の暗号化
3. アクセスログの取得と監査
4. エージェントの操作範囲の制限
5. 外部API呼び出し時のレート制限・エラー処理
6. 個人情報・機密情報のマスキングルール

使い分けの判断フロー

• 連携先がMCPに対応しているか確認する
• 対応している場合はMCPを優先し、標準化されたツール呼び出しを活用します
• 未対応の場合はAPIラッパーを実装し、MCPサーバーとして公開する設計を検討します
• リアルタイム性・セキュリティ要件によって、クラウド経由かオンプレミス経由かを決定します

PoCから本番移行のステップ

1. スコープを絞ったPoC（概念実証）で接続可能性を検証する
2. セキュリティ・権限設計を整備したうえで限定公開に移行する
3. 監視・ログ基盤を整えてから本番環境へ段階的に展開する

連携設計の複雑さは、接続先のシステム構成や業務要件によって大きく異なります。「どのツールをつなぐか」だけでなく、「どの範囲で・どの権限で・どう監視するか」まで含めた設計が、安定した運用の前提となります。CLANEは業務自動化AIエージェントの設計・開発を手がけており、こうした連携設計の実務にも対応しています。