AI連携とは？API・iPaaS・MCPで外部システムとつなぐ方法と事例

更新日

2026年7月31日

確認時点

2026年7月時点

AI連携とは、AIを社内データやSaaS、基幹システムへ接続し、情報の取得と外部システムの操作を可能にすることです。この3方式は排他的な関係にはありません。接続する相手の数と社内の開発体制によって主役が変わり、本番環境では組み合わせて使う構成が一般的です。

生成AIを導入したものの、社内のデータや基幹システムとつながっていないため、結局は人がコピーと貼り付けを繰り返している。AI連携を検討する現場では、この状態から抜け出す手段としてAPI、iPaaS、MCPという3つの言葉が同時に出てきます。どれを選ぶべきかが決まらないまま、要件定義が止まってしまう場面も見かけます。

判断に必要なのは、接続できるかどうかだけではありません。どの操作まで許可するか、費用がどこで発生するか、障害が起きたときに誰が切り分けるか。ここまで決めて初めて、PoCから本番へ進む道筋が見えます。

API、iPaaS、MCPがそれぞれ全体のどこに位置するのかを、先に1枚の図で示します。

AIアプリと業務システムの間に接続層があり、そこへ3つの方式が並びます。どれか1つを選んで他を捨てる構造ではありません。

先に、検討時によく出てくる疑問と短い答えをまとめます。

よくある疑問	短い答え
AI連携とは何か	AIを社内データ・SaaS・基幹システムへ接続し、参照と操作を可能にすること
API・iPaaS・MCPのどれを選ぶか	接続先の数と開発体制で決まる。実務では併用する
MCPがあればAPI開発は不要か	不要にはならない。MCPの背後で既存APIを使う構成が一般的
社内DBをAIへ直接つないでよいか	直結は勧めない。読み取り専用の中間層を挟む
APIキーとOAuthのどちらを使うか	ユーザー単位の権限が必要ならOAuth。システム間はサービスアカウント
費用はどこで発生するか	開発費・従量課金・保守の3つ。従量分は実行数とデータ量で変動する
オンプレミスと接続できるか	可能。ただし専用エージェントまたは閉域接続の設計が必要
導入はどこから始めるか	読み取り専用・限定データのPoCから

※ 各項目の詳細は本文の該当章で解説します。2026年7月31日時点の情報です。

表の答えは判断の入口にすぎません。実際には、接続方式ごとに向き不向きがあり、権限設計と運用体制まで含めて決める必要があります。

AI連携とは、AIを外部システムへ接続して参照と操作を可能にすること

AI連携という言葉を聞いて、ChatGPTにファイルをアップロードする作業を思い浮かべる方もいます。実務で問題になるのは、その先の話です。

AI連携とは、AIモデル・AIアプリ・AIエージェントを外部へ接続する取り組み全般を指します。接続先は社内データ、SaaS、基幹システム、APIなどで、目的は情報の取得と外部システムの操作です。ファイルを手渡す行為と、システムを自動で操作させる行為とでは、必要になる設計がまったく違います。前者は入力の管理で済みますが、後者は権限、承認、記録、復旧までを含む設計になります。

IBMは、API連携をAPIによって統合フローを公開する取り組みと説明しています。接続の対象は企業のアプリケーション、システム、ワークフローであり、目的はデータとサービスの交換にあります。

AIが外部データを参照できるようにする

第1段階は参照です。社内の文書管理システム、データベース、SaaS上の顧客情報などをAIが読み取れる状態にします。ここで見落とされやすいのが、元のシステムに設定されている閲覧権限をAI側でも再現する必要がある点です。人事情報や役員限定の資料が同じ検索対象に含まれていると、権限のない社員がAIの回答経由でその内容を受け取ります。参照だから安全という前提は成り立ちません。

AIが外部システムへ処理を依頼できるようにする

第2段階は実行です。CRMへのレコード登録、チケットの起票、メールの送信といった操作をAIが呼び出せるようにします。参照と実行の間には、リスクの大きな段差が存在します。

参照の失敗は情報が得られないだけで済みますが、実行の失敗は取引先へ誤った内容を送信する事故になります。

結果を元のシステムへ記録できるようにする

AIが出した結果を人が手で転記している状態では、連携は完成していません。処理結果、判断根拠、実行日時を元のシステムへ書き戻すところまで設計します。この記録が後の監査とトラブル対応の材料になります。

認証・権限・監視まで含めて連携を設計する

接続に成功した時点を完成と見なすと、本番運用で止まります。誰の権限で動いているのか、失敗したときに誰が気づくのか、費用がどこまで膨らむのか。この3点の設計を含めて、初めてAI連携が完成します。

GLOSSARY

この記事で使う用語

API

システムの機能やデータを外部から呼び出せるようにした接続口

iPaaS

クラウド上で複数システムの接続と処理の流れを管理する統合基盤

MCP

AIアプリケーションが外部のデータやツールを利用するための標準的な接続方式

Webhook

システム側の変化を起点として、あらかじめ登録した宛先へ自動通知する仕組み

冪等性

同じ処理を複数回実行しても結果が1回分にとどまる性質

AI連携は「つなぐ」、AIオーケストレーションは「調整して動かす」

AI連携を調べていると、AIオーケストレーションという言葉が並んで出てきて、どちらの話をしているのか分からなくなることがあります。両者は対立概念ではなく、担当する層が違います。

AI連携は接続そのものを扱います。AIオーケストレーションは、複数のAI・処理・連携を調整して動かす層を指します。IBMは、AIオーケストレーションをAIモデル・システム・統合の調整と管理であり、AIシステム全体の展開・実装・統合・保守を対象とするものと説明しています。

AI連携はシステム・データへの接続を扱う

AI連携が答えるのは「どうやってつなぐか」です。認証方式、データ形式の変換、送受信の方法がこの層の設計対象になります。接続先が1つでも成立します。

AIオーケストレーションは実行順・役割・状態を制御する

AIオーケストレーションが答えるのは「どの順番で、誰に、何をさせるか」です。複数のモデルやエージェントが登場して初めて意味を持つ層であり、扱う論点は次の3つに整理できます。

単一のAIが1つのシステムを参照するだけの構成では、この層はまだ必要になりません。

実務では連携基盤の上にオーケストレーションを構築する

この2つには順序があり、接続できていないものは調整できません。連携が整っていない段階でオーケストレーション製品を検討しても、つなぐ相手が存在しないため要件が固まらない状態に陥ります。

次の表で、両者の担当範囲を整理します。

項目	AI連携	AIオーケストレーション
主目的	外部システムへ接続する	複数の要素を調整・管理する
対象	API、DB、SaaS、MCP	モデル、エージェント、ワークフロー
主要機能	認証、変換、送受信	ルーティング、状態管理、再試行、監視
成果	データと操作を利用可能にする	目標に沿って処理を完了させる
先に必要なもの	なし	AI連携（接続がないと調整対象が存在しない）

※ 2026年7月31日時点の編集部による整理です。

表の最終行が実務上の分岐点になります。オーケストレーション製品の検討を先に始めてしまい、接続要件が固まらないまま比較表だけが増えていく進め方は、避けたほうが無難です。

AI連携は接続・変換・実行・制御・監視の5層で設計する

接続がうまくいったのに本番で止まる、という相談は珍しくありません。原因の大半は、接続以外の層を設計していない点にあります。

AI連携は5つの層に分けて考えると、抜けている設計が見つけやすくなります。なお、この5層は当社が提案する自社定義の整理であり、公式の指標ではありません。

接続層｜API・コネクタ・MCPで接続する

物理的につなぐ層であり、どの方式を使うかをここで決めます。接続先にAPIが用意されているか、既存のコネクタが使えるかによって、後続の工数が変わります。

変換層｜データ形式・項目・コードを変換する

送信元と送信先で項目名やデータ型が一致していることは、まずありません。顧客コードの桁数、日付の書式、全角と半角の扱い、必須項目の有無を一つずつ突き合わせるのがこの層の仕事になります。作業量が読みにくく、見積もりが外れやすい領域でもあります。

連携が失敗する原因は、接続層よりこの層に集中します。

実行層｜参照・登録・更新・送信を行う

実際の操作を行う層です。ここで重要になるのは、操作の種類ごとに扱いを変えることです。参照と更新を同じ設定で許可すると、AIの誤判断がそのままデータ破損につながります。

制御層｜認証・権限・レート・承認を管理する

誰の権限で、どこまでの操作を、どれだけの頻度で許すかを決める層です。人間の承認を挟む位置もここで設計します。制御層を後回しにしたPoCは、本番移行の直前で作り直しになりがちです。

監視層｜ログ・エラー・費用・遅延を確認する

動き始めた後を支える層であり、成功率、応答時間、費用、エラーの内訳を記録します。この層を省くと、遅くなった原因がAIの処理なのか接続先の応答なのかを切り分けられません。

5つの層の関係を1枚に整理すると、どの層の設計が抜けているかを確認しやすくなります。

上の層ほどAIに近く、下の層ほど既存システムに近い並びです。設計の抜けは、中間にある変換層と制御層に集中します。

APIは独自要件と細かな制御が必要な接続に向く

APIで直接つなぐべきか、それともツールに任せるべきかで迷う場面があります。判断を左右するのは、要件の独自性と社内にどれだけ開発体制があるかです。

API連携が向くのは、独自要件が多く、低遅延や大量処理が求められ、細かな制御が必要な場合です。自由度と引き換えに、開発・テスト・保守の工数が継続的に発生します。

APIはシステムのデータ・機能を外部へ公開する接続口

APIは、ソフトウェア同士がデータや機能をやり取りするための規則です。Web APIではRESTが主流であり、SOAPやgRPC、GraphQLも用途に応じて選ばれます。

AIアプリからAPIを呼び出して参照・更新する

AIアプリがAPIを呼ぶ流れは、認証、リクエスト、応答、記録の4段階です。AIが生成した引数をそのまま渡す点が、従来のシステム間連携との違いになります。この引数の扱いは後の章で詳しく触れます。

呼び出しの往復を1枚にすると、どの段階で認証が入り、どの段階で記録を残すのかが見えます。

AI側が判断するのは引数の中身だけであり、認証の付与と実行結果の記録は連携基盤の側が担当します。

Webhookでシステム変更をAI処理の起点にする

こちらから取りに行くのではなく、相手の変化を受け取る方法もあります。システムでイベントが発生した際にWebhookが自動でデータ交換を起動する形であり、リアルタイムに近い処理が実現できます。

API Gatewayで認証・レート制限・ログを管理する

APIを個別に守るのではなく、手前に関門を置く方法があります。API Gatewayを置くと、レート制限とクォータの適用を一箇所で管理できます。JWTによる認証や認可、ログの取得も同じ層でまとめられます。近年は、この関門でAI向けのトラフィックを扱う機能も広がっています。

独自要件が多い場合はAPI連携が向く

自社独自の業務ルールを処理に埋め込みたい、応答速度を数十ミリ秒単位で詰めたい、既存サービスへ機能として組み込みたい。こうした要件があるなら、API連携を軸に据える構成が合います。

＋API連携の利点

• 処理内容を自由に設計できる
• 高速・大量の処理に対応しやすい
• 独自の業務ルールを組み込める
• 既存サービスへ機能として統合できる
• 権限をきめ細かく設定できる

−API連携の注意点

• 開発・テスト・保守の体制が必要
• 接続先ごとに仕様が異なる
• 相手のバージョン変更へ追随する必要がある
• 障害時の再試行と冪等性を自前で設計する
• 認証情報の保管と更新を運用する

注意点の最後に挙げた認証情報の管理は、事故に直結しやすい項目です。

iPaaSは複数システムをローコードで統合したい場合に向く

つなぎたい相手が5つも10もあり、しかも社内に開発者が少ない。この条件では、個別にAPIを実装する進め方が現実的でなくなります。

iPaaSが向くのは、複数のSaaS・クラウド・オンプレミス間を、標準コネクタとローコードのフローで接続する場合です。開発期間は短縮しやすい一方、実行数とデータ量に応じて費用が変動します。

MuleSoftは、iPaaSをクラウドベースの統合ソリューションと説明しています。接続の対象はアプリケーション、システム、技術であり、クラウドとオンプレミスの両環境にまたがります。

iPaaSはクラウド型のシステム統合基盤

iPaaSはサーバーの用意や保守を事業者側が担う形で提供されます。Google Cloudの統合サービスの場合、サーバーレスで自動的にスケールし、事業者が完全に管理する構成になっています。

標準コネクタでSaaS・DB・オンプレミスを接続する

主要なSaaSやデータベースについては、あらかじめ用意されたコネクタが使えます。認証や通信の実装を省けるため、接続までの時間が短くなります。

一方で、コネクタが対応していない操作は扱えません。導入前に、実際に必要な操作がコネクタの機能範囲に含まれているかを確認しておくと、後戻りを避けられます。

項目マッピング・データ変換・条件分岐を設定する

視覚的なエディタ上で、送信元と送信先の項目を線でつなぐ形で変換を定義できます。複雑な変換ロジックにも対応しており、条件によって処理を分岐させる設定も画面上で行えます。

イベント・スケジュール・APIをトリガーにする

処理の起点は3種類あります。相手システムでの変化を捉えるイベント、決まった時刻に動くスケジュール、外部から呼ばれるAPIです。用途に応じて選びます。

トリガーから接続先までの流れを図にすると、iPaaSがどこで変換を挟んでいるのかが分かります。

1本のフローの中に、起点、変換、分岐、接続先が順に並びます。この可視化が、引き継ぎのしやすさにつながります。

複数システムをローコードで管理したい場合に向く

つなぐ相手が多く、業務部門の担当者もフローの中身を把握しておきたい。この条件ならiPaaSが有力な候補になります。処理の流れが画面上に見えるため、引き継ぎと障害対応が属人化しにくい点も利点です。

＋iPaaSの利点

• 開発期間を短縮しやすい
• 主要サービスの接続部分を作らずに済む
• データ変換を画面上で定義できる
• 処理の流れが可視化され引き継ぎやすい
• 監視と再試行の機能が備わっている

−iPaaSの注意点

• コネクタが対応していない操作は扱えない
• 独自処理の作り込みには限界がある
• 実行数とデータ量に応じて費用が増える
• 移行時のベンダー依存が生じやすい
• オンプレミス接続には専用エージェントが必要
• フローが増えすぎると全体の保守が難しくなる

MCPはAIアプリ向けの標準接続口として既存APIの上に置く

MCPが登場してから、既存のAPI資産をどう扱うべきか迷う声を聞くようになりました。結論から言えば、置き換える関係にはありません。

MCPは、AIアプリケーションから外部のデータやツールを利用するための標準的な接続方式です。既存のAPIを不要にするものではなく、既存のAPIをAI向けに公開する層として働きます。

MCPはAIアプリ向けの外部接続標準

従来は、AIアプリごとに接続部分を個別に実装する必要がありました。MCPはこの接続部分の作法を統一するため、同じMCPサーバーを複数のAIクライアントから使い回せます。

MCPサーバーはデータ・ツールをAIへ公開する

MCPサーバーは、AIから呼び出せる機能をツールとして公開します。AI側はどんなツールが使えるかを問い合わせて把握し、必要なものを選んで呼び出します。この「先に一覧を取得してから選ぶ」という流れがあるため、AIアプリ側へ接続先を一つずつ設定しておく必要がありません。接続先が増えたときの設定変更を減らせる点が、個別実装との実務上の違いになります。

既存APIをMCPツールとして公開できる

ゼロから作り直す必要はありません。APIゲートウェイの機能を使い、管理下のREST APIをリモートのMCPサーバーとして公開する方法が用意されています。ただし対応範囲には制限があり、現時点ではMCPのツールに対応する一方、リソースとプロンプトには対応していない製品もあります。

既存のAPIとMCPサーバーの位置関係を図にすると、置き換えではないことが読み取れます。

MCPサーバーはAIとAPIの間に立つ層であり、API側はそのまま残ります。管理対象は減るのではなく、1層増えます。

MCPはAPI・iPaaSの代替ではなく上位の接続口になる

MCPサーバーの背後では、たいてい既存のAPIやデータベースが動いています。MCPを導入しても、API側の保守がなくなるわけではありません。

むしろ管理対象が1層増えると考えたほうが、見積もりを外しません。

FEATURES

MCPが担う3つの役割

1

接続方法の統一

AIアプリごとに違っていた接続の作法を、共通の形にそろえます

2

ツールの発見と呼び出し

使える機能の一覧をAI側が問い合わせ、必要なものを選んで実行します

3

既存資産の再利用

作り直しではなく、既存のAPIやDBをAI向けに公開する形をとります

役割が整理できたところで、導入時期の判断に関わる点に触れます。

現行仕様は2026-07-28版で、移行期にある

MCPの仕様は改訂が続いています。2026年7月28日に公開された2026-07-28版は、公開以来もっとも規模の大きい改訂とされ、プロトコルの中核がステートレス化されました。あわせて、一部の機能と旧来のトランスポート方式が非推奨となっています。

非推奨となった機能には、削除まで最低12か月の期間が設けられています。とはいえ、仕様の改訂に製品側の対応が追いつくまでには時間差が生じます。実際、既存のMCPサーバーを扱う製品ドキュメントが、より前のバージョンを前提として書かれている例もあります。

詳細な仕組み・実装はMCP記事で確認する

MCPサーバーの内部構成や実装手順については、仕様の改訂サイクルが速いため、MCPの仕組みと実装方法を解説した記事で最新の内容をご確認ください。

処理の待ち方で同期・非同期・イベント駆動・定期実行を使い分ける

検証環境では動いたのに、本番でタイムアウトが頻発する。AI連携でよく聞く症状であり、原因は処理の待ち方の設計にあります。

AIの応答には時間がかかります。すべてを同期で組むと、待ち時間が呼び出し元へそのまま跳ね返ります。処理時間と起点の種類によって、4つの方式を選び分けます。

同期連携｜結果を待って次の処理へ進む

呼び出した側が応答を待つ方式です。チャットの応答、リアルタイムの検索、小規模なデータ取得のように、結果がすぐ必要な処理に向きます。注意したいのは、AIの応答時間が入力の長さや混雑状況で変動する点です。タイムアウト値をどこに設定するかを最初に決めておかないと、遅い応答が呼び出し元の待ち時間へそのまま積み上がり、遅延が連鎖します。

非同期連携｜処理を受け付け、完了後に結果を返す

先に受付だけを返し、処理が終わってから結果を渡す方式です。大量データの処理、長時間かかるAI処理、夜間バッチがここに当たります。ジョブIDを発行し、進行状況を問い合わせられる仕組みを合わせて用意します。

イベント駆動｜システムの変化を起点に処理する

こちらから取りに行くのではなく、相手の変化を受け取る方式です。イベント駆動システムは3者で構成されます。イベントを生成する側、受信して振り分けるルーター、受け取って処理する側です。3者は疎結合であり、それぞれ独立して更新や増設ができます。

新規問い合わせの受信、ファイルの追加、注文の作成といった変化を起点にできるため、待ち時間のない処理が組めます。

定期実行｜スケジュールで情報を取得・処理する

決まった時刻に動かす方式です。日次レポートの生成、在庫の定期監視、システム間のデータ同期に使います。前回の実行が終わらないうちに次が始まる二重起動を防ぐ制御が要ります。

4つの方式は排他ではなく、1つの業務フローの中で組み合わせて使う場面が出てきます。

横軸に時間を取ると、待つ設計と待たない設計の差が見えます。AI処理が絡む部分ほど、待たない設計へ寄せたほうが安定します。

連携するデータは形式と粒度を先に揃える

接続そのものは1日で終わったのに、データが合わずに1か月止まる。この順序で詰まる案件は珍しくありません。

連携の失敗要因は、接続層よりデータ側に集中します。扱うデータの種類によって、必要な前処理と変換の重さが変わります。

構造化データ｜DB・CSV・業務システム

行と列が定義されているデータです。項目の意味が明確なため扱いやすい一方、コード体系が組織ごとに異なる点が壁になります。取引先コードや部門コードの対応表を先に用意しておきます。

半構造化データ｜JSON・XML・ログ

構造はあるものの、項目の並びや深さが一定でないデータです。API連携で扱う機会が多い形式であり、階層の深いところに必要な値が入っている場合は、抽出のルールを個別に決めます。

非構造データ｜文書・メール・画像・音声

決まった形を持たないデータです。AIが力を発揮する領域である反面、抽出結果の正確さが保証されません。抽出した値をそのまま基幹システムへ書き込む設計は避け、確認の工程を挟みます。

マスターデータ｜顧客・商品・組織・権限

他のデータが参照する基準になるデータです。ここがずれていると、どれだけ連携を作り込んでも結果が合いません。マスターの持ち主がどのシステムなのかを、連携の設計前に確定させます。

種類ごとの違いを踏まえたうえで、送信元と送信先の突き合わせに入ります。

チェック項目のうち、実務で見落とされやすいのは日時の扱いとコード体系です。突き合わせの結果は、次のような対応図として残しておくと引き継ぎに使えます。

項目名が同じでも中身が違う例、名前は違うが同じ意味の例が混在します。この突き合わせ作業は工数が読みにくく、見積もりが外れやすい領域です。

接続先の数と開発体制でAPI・iPaaS・MCPを選ぶ

3方式のどれを選ぶべきかという問いには、単独の正解がありません。判断を分けるのは、つなぐ相手の数と社内にある開発体制です。

接続先が1つか2つで独自仕様が多いならAPI、接続先が多数のSaaSに広がるならiPaaS、複数のAIアプリから同じ機能を使わせたいならMCPが軸になります。本番構成では併用が一般的です。

条件	API	iPaaS	MCP
独自仕様が多い	◎	△	○
接続先が多数のSaaS	△	◎	○
複数AIアプリへ同じ機能を提供	△	△	◎
ローコードで構築したい	△	◎	○
大量処理と低遅延が必要	◎	○	接続先次第
データ変換が重い	実装が必要	◎	背後の処理次第
社内に開発者がいない	×	条件付きで可	条件付きで可
既存APIを再利用したい	◎	◎	◎

※ ◎は適する、○は条件付きで使える、△は工夫が要る、×は向かないことを示します。2026年7月31日時点の編集部による整理です。

表の最終行が示すとおり、既存API資産はどの方式でも活かせます。作り直しを前提とした比較は不要です。

1つの独自システムを深く接続するならAPI

自社独自の業務ルールを処理へ埋め込みたい場合や、応答速度を細かく詰めたい場合はAPIが向きます。開発体制が前提になるため、社内に担当者がいるかを先に確認します。

複数SaaSを短期間で連携するならiPaaS

つなぐ相手が5つを超えたあたりから、個別実装の保守が重くなります。標準コネクタで賄える範囲であれば、iPaaSのほうが立ち上がりも引き継ぎも軽く済みます。

複数AIアプリから同じツールを使うならMCP

社内で複数のAIクライアントを使っており、同じ業務機能をそれぞれから呼びたい。この条件でMCPの利点が出ます。逆に、AIアプリが1つしかない段階では、MCPを挟む必然性が薄くなります。

本番ではAPI・iPaaS・MCPを組み合わせる

実際の構成では、基幹系はAPIで直結し、SaaS間はiPaaSで束ね、AI向けの入口だけMCPで統一するといった形になります。それぞれの層で求められる性質が違うため、1つの方式ですべてを賄おうとすると、どこかに無理が出ます。基幹系に求められるのは応答速度と細かな制御、SaaS間に求められるのは接続の数をさばく効率、AI向けの入口に求められるのは呼び出し方の統一です。1つを選んで他を捨てる設計にはしません。

まだ連携に着手すべきでないケース

条件がそろっていない段階で方式選定に入ると、要件が固まらないまま比較検討だけが長引きます。次の状態に当てはまる場合は、連携の設計より前に整理すべきものがあります。

○おすすめの方

• 接続対象と操作範囲を一覧化できている方
• 対象業務の件数と処理時間を把握している方
• 個人情報の取り扱い方針が社内で決まっている方

×合わない方

• 何を自動化するかがまだ決まっていない方
• 接続先にAPIがなく画面操作の自動化しか手段がない方
• 対象業務の件数が少なく開発費を回収できない方

右側に当てはまる場合、先に着手すべきは業務手順の文書化とデータ方針の確定です。連携方式の比較は、その後で意味を持ちます。

認証は「誰か」、認可は「何ができるか」を分けて設計する

認証方式を決めれば権限も決まる、と考えて設計を進めると、後工程で作り直しになります。この2つは別の設計項目です。

認証は相手が誰かを確かめる仕組み、認可はその相手に何を許すかを決める仕組みです。連携で事故が起きるのは、認証だけを整えて認可を省いた構成です。

APIキー｜単純だが権限と保管に注意

発行された文字列を提示するだけの方式です。実装は軽い反面、キーを持っている人が誰でも同じ権限を持ちます。サーバー側で保管し、接続元IPと呼び出せるAPIを制限したうえで、定期的な入れ替えを運用に組み込みます。

OAuth｜ユーザー・アプリ単位で権限を付与

利用者本人の同意に基づき、必要な範囲だけを許可する方式です。スコープで操作範囲を絞り、アクセストークンの有効期限と失効の仕組みを持ちます。ユーザーごとに見える範囲を変えたい場合はこちらを選びます。

サービスアカウント｜システム間連携に利用

人ではなくシステムそのものに割り当てる認証情報であり、最小権限で発行して環境ごとに分離します。鍵ファイルを配布せずに済むキーレスの方式が使えるなら、そちらのほうが漏洩の経路を減らせます。

MCPの認可｜登録方式が移行期にある

MCPサーバーはOAuthのリソースサーバーとして扱われます。2026年7月の仕様改訂では認可の強化が入り、クライアント登録の方式が動的登録からクライアントIDメタデータ文書へと移る流れが示されました。動的登録は後方互換のため当面動作するものの、将来的に削除される予定です。

認証方式が決まったら、その上に権限の設計を重ねます。2つの関係を1枚にすると、どちらの設計が抜けているかを確認しやすくなります。

左側が認証、右側が認可です。同じ利用者でも、参照は許可し更新は承認を挟むといった段階を設けられます。

AI連携では生成された入力そのものを検証対象にする

従来のシステム間連携では、送られてくる値の形式が決まっていました。AIが呼び出し元になると、この前提が崩れます。

AIが生成したAPIの引数やツールの入力は、外部から届いたユーザー入力と同じ基準で検証します。ここが従来の連携設計との違いです。

読み取り・書き込み・削除の権限を分ける

同じ接続情報で参照も削除もできる状態は避けます。操作の種類ごとに認証情報を分ければ、誤判断が起きたときの影響範囲が限定されます。

AIが生成したツール引数を検証する

型、桁数、値の範囲、業務ルールとの整合をスキーマで検査します。

AIが妥当そうな値を組み立てても、それが業務上許される値かどうかは別の話です。

機密データを最小限だけ渡す

AIへ渡す情報は、判断に必要な範囲へ絞ります。

全件を渡してから絞り込ませる設計は、漏洩が起きたときの影響範囲を大きくします。

レート制限・予算上限を設定する

想定外の繰り返し実行に備えて、呼び出し回数と費用の上限を先に設定します。上限に達したときの動作も併せて決めておきます。

監査ログ・アラート・承認履歴を残す

いつ、どの権限で、何を実行したのか。この記録がないと、事故が起きた後に影響範囲を特定できません。人が承認した履歴も、同じ場所へまとめて残しておきます。

Prompt Injectionとデータ流出を想定する

MCPの公式文書は、実装に固有のリスクと攻撃経路を整理しています。スコープ設計が粗いままだと、トークンが漏れたときの影響範囲が広がり、取り消しも難しくなると指摘されています。

本番・検証・開発環境を分ける

検証の段階で本番データへ接続する構成は、事故が起きたときに戻せません。環境ごとに接続先と権限を分離します。

AI連携の障害はレイヤーを分けて切り分ける

応答が遅い、結果がおかしい。この連絡を受けたとき、原因がAIなのか接続先なのかを即答できる体制になっているでしょうか。

AIの誤判断と連携基盤の障害を同じエラーとして扱うと、原因の特定に時間がかかります。監視はレイヤーごとに設計します。

タイムアウト・再試行・バックオフを設定する

待ち時間の上限、再試行の回数、再試行の間隔を明示的に決めます。間隔を空けずに再試行すると、復旧しかけた接続先へ負荷をかけ直すことになります。

冪等性キーで重複登録・重複送信を防ぐ

再試行と重複実行は表裏一体です。処理ごとに一意のキーを持たせ、同じキーの2回目以降は結果を変えない実装にします。

失敗イベントをキューへ保存する

処理できなかったイベントを捨てずに退避させます。原因を直した後にまとめて再処理できる状態にしておくと、手作業での復旧が減ります。

手動再処理・切り戻しを用意する

自動で復旧できない場合の手順を、運用開始前に文書化しておきます。誰が、どの画面から、どこまで戻せるのかが決まっていないと、障害の発生時に判断そのものが止まります。

接続先の仕様変更・廃止を追跡する

APIのバージョン変更や機能の廃止は、こちらの都合と無関係に起こります。相手側の告知から実際の変更までの猶予は数か月というケースもあり、気づくのが遅れると停止したまま放置されます。接続先ごとに更新情報を受け取る経路を確保し、確認する担当者と頻度を決めておきます。

この担当を決めていない連携は、いずれ静かに止まります。

監視の対象は、レイヤーごとに見るべき指標が異なります。

監視対象	見る指標
接続	成功率・応答時間・タイムアウト発生数
AI	出力の精度・人による修正率・トークン使用量
API	エラーコードの内訳・レート制限への到達
iPaaS	実行数・失敗したフロー・キューの滞留
MCP	ツール呼び出し数・認可エラー・入力検証の却下
費用	API利用料・モデル利用料・実行数・転送量
セキュリティ	異常なアクセス・権限変更・データの持ち出し

※ 2026年7月31日時点の編集部による整理です。自社の構成に合わせて項目を調整してください。

この表を1つにまとめず、レイヤーごとに分けて持つことが切り分けの速さに直結します。監視の構成を図にすると、確認する順序が固定できます。

上から順に見ていけば、どの層で止まったかが絞り込めます。すべてを1つのダッシュボードへ混ぜると、この絞り込みができなくなります。

AI連携の費用は開発・従量・保守の3つで発生する

PoCの予算は通ったのに、本番移行の稟議で止まってしまう。この相談を受けたとき、原因の大半は初期開発費だけで見積もっていた点にあります。

連携費用は3か所で発生します。初期の開発費、動かし続けるための従量課金、そして仕様変更へ追随する保守です。3つ目が見積もりから抜けやすい部分になります。

FEATURES

連携費用が発生する3か所

1

開発費

接続の実装、テスト、既存システム側の改修にかかる初期費用です

2

ランニング費用

モデル利用料、APIの従量課金、iPaaSの実行数に応じて毎月発生します

3

保守費用

接続先の仕様変更への追随、障害対応、権限の棚卸しが継続的に発生します

3つの内訳を、それぞれ見ていきます。

開発費｜実装だけでなく既存システム側の改修も含む

見落とされやすいのは、接続先システム側の改修費です。APIが用意されていない場合や、必要な項目が返ってこない場合、相手側の開発も発生します。自社の実装費だけで見積もると差が出ます。

ランニング費用｜実行数とデータ量で変動する

モデルの利用料に加えて、APIの呼び出し回数、iPaaSの実行数、転送データ量が費用に効きます。PoCの規模で測った単価をそのまま本番の件数へ掛けると、想定を超える場合があります。

保守費用｜接続先が増えるほど重くなる

接続先が10あれば、10か所の仕様変更を追い続けることになります。連携の本数に比例して保守工数が積み上がる構造であり、この点はどの方式を選んでも変わりません。ローコードで作った場合も同じで、作るのが速いぶん本数が増えやすく、結果として棚卸しの対象が膨らむ傾向があります。年に一度は使われていないフローを止める工程を、運用計画へ最初から組み込んでおくと安全です。

オンプレミス・閉域環境と接続する場合の追加要件

クラウド上のAIから社内の基幹システムへつなぐ場合、専用のエージェントを社内へ設置するか、閉域の接続経路を用意します。ネットワーク側の設計と、その運用を担当する体制が追加で必要になります。

読み取り専用のPoCから8ステップで本番へ進める

どこから手を付ければよいかという相談には、共通して答えられる順序があります。権限を最初から広げないことが要点です。

限定したデータの読み取り専用から始め、8段階で対象と権限を広げます。各段階で決めるべきことを整理します。

1

連携する業務と目的を決める

STEP1

検索、登録、更新、通知、自動実行のどれを目的にするかを1つに絞ります。複数を同時に狙うと評価軸が定まりません。

2

接続するシステムとデータを一覧化する

STEP2

SaaS、データベース、ファイル、基幹システムを書き出し、それぞれにAPIがあるかを確認します。

3

読み取り・更新・送信・削除を分類する

STEP3

操作ごとにリスクを評価し、人の承認を挟む位置を決めます。最小権限の範囲もここで確定させます。

4

API・iPaaS・MCPを選ぶ

STEP4

独自要件の量、接続先の数、社内の開発体制、AIクライアントの数から方式を決めます。

5

データ形式と項目をマッピングする

STEP5

スキーマ、コード体系、必須項目、個人情報の所在を突き合わせ、変換ルールを文書化します。

6

認証・認可・監査を設計する

STEP6

認証方式、スコープ、ログの保存先と保存期間を決めます。環境ごとの分離もここで設計します。

7

限定データ・読み取り専用でPoCする

STEP7

成功率、応答の遅延、出力の精度、費用、障害の発生状況を計測します。数値がないと本番移行を判断できません。

8

本番運用・監視・復旧を設計する

STEP8

再試行、冪等性、失敗時のキュー、停止手順、切り戻し、仕様変更への追随を整えます。

STEP2で作る一覧は、そのまま方式選定と権限設計の材料になります。次の形で書き出すと、STEP3とSTEP4がそのまま進みます。

接続対象	API有無	操作種別	リスク	人の承認
（例）CRM	あり	参照・登録	中	登録時のみ
（例）会計システム	なし	参照のみ	低	不要
（例）メール配信	あり	送信	高	送信前に必須

※ 判断列を自社の状況に合わせて上書きしてお使いください。行は必要なだけ追加します。

一覧が埋まると、どの接続が高リスクなのかが一目で分かります。8つの段階と権限の広がり方をあわせて見ると、どこまでをPoCの範囲にするかが決めやすくなります。

権限の帯が右へ進むほど広がる構造です。PoCと本番の境界線をどこに引くかを、着手前に合意しておきます。

業務フロー別に見るAI連携の構成パターン

自社の業務ではどの方式になるのか。この見当をつけるには、業務フローごとの構成例を見るのが早道です。

同じAI連携でも、接続先と操作の種類によって選ぶ方式が変わります。代表的な5パターンを、接続先と人の確認箇所とあわせて整理します。

社内ナレッジ検索と回答支援

文書管理システム、FAQ、権限データベースへ接続し、質問に対して出典付きで回答します。方式はAPIまたはMCPです。参照が中心のため着手しやすい一方、元のシステムに設定されている閲覧権限をAI側でも再現できるかが設計の要点になります。ここを省くと、人事情報や役員限定の資料が検索対象に混ざり、権限のない社員が回答経由で内容を受け取ります。機密情報や規程の解釈が絡む回答については、人の確認を挟む運用にします。

問い合わせを分類してCRM・チケットへ登録

メール、CRM、ITSM、チャットをつなぎ、受信した問い合わせを分類して登録します。方式はiPaaSとAPIの組み合わせです。クレーム、返金、重要顧客に関わる案件は、自動処理から外して人へ回します。

営業前の企業調査と商談準備

Web、CRM、カレンダー、社内文書へ接続し、予定を起点に情報を集めて資料を用意します。方式はAPIとMCPの組み合わせです。事実関係と顧客固有の情報は、担当者が確認してから提出します。

請求書の読取・照合・会計登録案

ストレージ、文字認識、購買システム、会計システムをつなぎます。方式はiPaaSとAPIの組み合わせになります。金額の確定と税区分の判断、そして例外処理については人が承認します。

AIエージェントから社内ツールを利用

CRM、データベース、検索、業務APIをAIエージェントから呼び出します。方式はMCPとAPIゲートウェイの組み合わせです。更新、送信、削除にあたる操作は、実行前に内容を提示して承認を得ます。

5つのパターンを方式と操作の種類で並べると、判断の傾向が見えます。

業務フロー	主な接続先	方式	人が確認する箇所
社内ナレッジ検索	文書管理・FAQ・権限DB	APIまたはMCP	機密情報・規程の解釈
問い合わせの分類と登録	メール・CRM・ITSM	iPaaS＋API	クレーム・返金・重要顧客
営業前の企業調査	Web・CRM・カレンダー	API＋MCP	事実関係・顧客固有情報
請求書の読取と照合	ストレージ・購買・会計	iPaaS＋API	金額・税区分・例外
エージェントからの社内ツール利用	CRM・DB・業務API	MCP＋APIゲートウェイ	更新・送信・削除

※ 一般化した構成例です。実際の要件は接続先の仕様により変わります。

参照が中心のパターンほど着手が早く、更新や送信を伴うパターンほど承認の設計が重くなります。

接続の確認だけで進めると本番で止まる

技術的にはつながったのに、プロジェクトとしては前へ進まない。この止まり方には、業種を問わず現れる共通の型があります。

失敗の大半は技術ではなく進め方で起きるため、避けたい型を4つ挙げます。

接続できることだけを確認し、業務目的を決めない

つながった時点で成功と見なすと、次に何を測ればよいかが決まりません。削減したい工数か、短縮したい時間か、目的を1つ決めてから接続に入ります。

APIとデータ形式の仕様を記録しない

動いたコードだけが残り、なぜその変換をしているのかが誰にも分からなくなります。項目の対応関係、コード体系の読み替え、例外時の既定値といった判断の背景は、コードを読んでも復元できません。担当者が変わった瞬間に保守が止まる構造です。

iPaaSフローを増やしすぎて管理できなくなる

作りやすさが裏目に出る場面です。似たフローが増殖し、どれが本番で動いているのか分からなくなります。

命名規則と棚卸しの周期を、最初に決めておきます。

PoCの成功率・遅延・費用を測らない

感触だけで本番移行を判断すると、稟議の場で根拠を説明できません。成功率、応答の遅延、出力の精度、費用のうち、どれが合格ラインを超えたのかを数値で示せない状態では、投資判断そのものが成立しません。数値を取らなかったPoCは、次の判断材料を何も残さずに終わります。

AI連携に関するよくある質問

検討の過程で繰り返し出てくる疑問を、短い答えとあわせてまとめます。

FAQ

よくある質問

Q.AI連携とは何ですか？−

A.

AIと外部のデータ、SaaS、基幹システムを接続し、情報の参照と外部システムの操作をできるようにすることです。ファイルを渡すだけの利用とは、必要になる設計が異なります。

Q.APIとiPaaSの違いは何ですか？+

Q.MCPがあればAPIは不要になりますか？+

Q.iPaaSとMCPは併用できますか？+

Q.AI連携とAIオーケストレーションの違いは何ですか？+

Q.社内データをAIへ接続しても安全ですか？+

Q.APIキーだけで本番運用できますか？+

Q.ノーコードでAI連携できますか？+

Q.オンプレミスのシステムとも連携できますか？+

API・iPaaS・MCPは接続対象と運用要件で使い分ける

3方式のどれが優れているかという問いは、実務では成立しません。決まるのは、つなぐ相手と、どこまでの操作を許すかです。

次に着手するのは、接続対象の棚卸しです。i-13の棚卸し表に、接続先、API有無、操作種別、リスク、承認の要否を書き出すところから始めると、方式の選定とPoCの範囲が同時に決まります。

複数のAIやエージェントをどう制御するかはAIオーケストレーションを解説した記事で、MCPの仕組みと実装手順はMCPの解説記事で、それぞれ扱っています。