AIとデータ連携
ChatGPT や Claude をブラウザで使うだけでも、要約や下書き作成は十分できます。しかし業務では「自社の最新の議事録を要約してほしい」「顧客 ID を渡したら顧客情報を引いて返してほしい」「Slack で通知を流してほしい」のように、社内の資料や API と繋ぐ場面が必ず出てきます。これが「AI とデータ連携」の話です。
LLM は事前学習までの公開情報しか知らず、社内資料・最新ニュース・API を扱えません。これを補うのが 参照（RAG）・実行（Tool Use）・接続（MCP） の 3 つの役割で、組み合わせて初めて業務で使えます。
01.AI 単体では届かない領域がある
LLM（大規模言語モデル）は、ウェブや書籍などの公開テキストを使った事前学習で「言葉の使い方」を学んでいます。逆に言うと、それ以外のことは知らないし、できません。
| AI 単体で困ること | 理由 | 解決の方向 |
|---|---|---|
| 今日のニュース・最新情報を知らない | 学習データに含まれない | Web 検索ツールを繋ぐ |
| 自社の議事録・規程・契約を知らない | 公開情報ではない | 社内文書を検索させる（RAG） |
| CRM や Slack を直接操作できない | 外部 API を呼ぶ手段がない | API 呼び出しツールを渡す（Tool Use） |
| 毎回違うシステムに繋ぎ直すのが大変 | 個別実装が増える | 接続方式を標準化する（MCP） |
02.データ連携の 3 つの役割：参照・実行・接続
AI 業界で出てくる Tool Use・MCP・RAG という言葉は、それぞれ違う役割を担います。3 つに分けて理解すると、「何をどう繋げばよいか」が見えます。
| 役割 | 用語 | 中身 | 業務例 |
|---|---|---|---|
| 参照 | RAG（検索拡張生成） | 関連資料を検索し、回答の根拠として AI に渡す | 社内 FAQ ボット、契約書 Q&A、規程検索 |
| 実行 | Tool Use（Function Calling） | AI が「この関数を呼びたい」と言い、アプリが API を実行 | CRM 更新、メール下書き、コード修正 |
| 接続 | MCP（Model Context Protocol） | AI と外部ツールをつなぐ接続方式の業界標準 | GitHub・Slack・Notion・社内 DB を横断的に接続 |
RAG は AI が必要な資料を読むこと、Tool Use は AI が「ボタンを押す」こと、MCP はそのボタンとコンセントの規格を揃える話、と捉えると分かりやすくなります。
03.データ連携の変遷：MCP から API 直叩きまで（新しい順）
参照・実行・接続の 3 つは最初からそうだったわけではありません。ここ数年で連携手段は何度も変わってきて、2026 年 5 月時点では「MCP に収斂しつつある」状況です。最新の到達点から遡って見ていくと「いま入れるべき手段」がぶれません。
オレンジで強調した行は、現在の連携像に直結する転換点（Function Calling 公開・MCP 公開・MCP の標準化）。
2025–2026：標準としての MCP
2025 年以降、Claude Code・Cursor・OpenAI Agents SDK・各 SaaS が MCP に対応し、2026 年 5 月時点ではほぼ業界標準として扱われています。組織側の判断は「自前で個別連携を増やす」から「MCP サーバーを採用 / 自作する」へ移行しました。
2024：MCP の公開と接続層の整備
2024 年 11 月に Anthropic が Model Context Protocol（MCP）を公開し、ツール接続の「呼び方」を標準化しました。複数の AI クライアントから同じ MCP サーバーを使い回せるようになり、組織側は接続資産を再利用できるようになりました。
2023 後半：Function Calling 標準化
2023 年 6 月、OpenAI が Function Calling を公開しました。LLM が「呼びたい関数」を構造化 JSON で返す、という標準的なやり取りが確立し、Anthropic も Tool Use として同等の機能を整備します。これにより「LLM ↔ 外部関数」の境界が明確になり、認証・権限はアプリ側、選択判断は LLM 側、と責任が分かれました。
〜2023：API 直叩きと個別 SDK
2022〜2023 年前半は、LLM に API ドキュメントをプロンプトで渡し、生成された URL や HTTP メソッドをアプリ側でパースして呼ぶ、という素朴な連携が一般的でした。LangChain などの個別 SDK が登場し、複数 LLM ↔ 複数ツールの組み合わせを抽象化しようとしましたが、ツール定義は各社・各 SDK で固有でした。この時期の連携は「過去の話」と見て差し支えありません。
OSS / 学習用途では LangChain も引き続き使えますが、業務本番では Anthropic / OpenAI の Agents SDK + MCP の組み合わせが主流です。2022〜2023 年に LangChain で組んだ社内 AI は、乗り換えのタイミングを検討してよい段階です。
04.業務での典型的な組み合わせ
3 つの役割は単独でも機能しますが、実務では組み合わせて使うことがほとんどです。AI が動く 1 サイクルを図にすると、5 つの段階で「参照」と「実行」を分けて使い、結果を人間が確認する形になります。
ユーザーが目的・制約・判断基準を渡す
AI が必要な情報と操作を選ぶ
社内資料・Web を検索して根拠を集める（RAG）
API・ファイル・業務システムを呼び出す（Tool Use / MCP）
結果と出典を人間が確認・承認する
ポイントは、AI に「すべてを直接やらせる」のではなく、参照と実行を分け、結果を人が確認してから次に進むことです。
| 業務シナリオ | AI に任せる範囲 | 使う役割 |
|---|---|---|
| 顧客サポート FAQ | 問い合わせを受けて、社内 FAQ から根拠付きで回答 | RAG（参照） |
| 営業の議事録 → CRM 転記 | 議事録要約 → 次アクション抽出 → CRM 更新案 | RAG + Tool Use（参照 + 実行） |
| 社内ナレッジ横断検索 | Slack / Notion / GitHub を横断して関連情報を集約 | MCP + RAG（接続 + 参照） |
| コード修正の自動化 | リポジトリ調査 → 修正案 → テスト実行 | MCP + Tool Use（接続 + 実行） |
05.データ連携でできること・できないこと
| できること（向き） | できないこと（不向き） |
|---|---|
| 社内文書を根拠に答える | ハルシネーションをゼロにする（減らせるが消えない） |
| 業務 API を AI から呼び出す | AI 単独で本番反映を任せる（必ず承認制で） |
| 複数システムを横断的に扱う | 認証・権限なしで安全に動かす |
| AI が判断材料に最新情報を含める | 判断責任そのものを人間から外す |
データ連携は AI の能力を広げますが、判断責任までは肩代わりしません。連携で AI ができる範囲が広がるほど、人間の承認・監査ログ・取り消し手順といった統制側の設計も同時に強化する必要があります。
06.失敗パターンと注意点
| よくある失敗 | 原因 | 対処 |
|---|---|---|
| 便利そうなツールを大量に繋ぐ | AI が選択に迷い、誤呼び出しが増える | セッション単位で必要なツールに絞る |
| 最初から書き込み・送信を任せる | 誤操作の影響が大きい | 読み取り → 下書き → 承認付き変更の順に段階導入 |
| RAG で答える内容を雑に拾う | 古い資料・別文脈の引用が混ざる | メタデータ・版管理・出典表示を設計する |
| 認証情報を AI のプロンプトに含める | 鍵が AI 出力に流出する | 認証はアプリ側で注入、AI には渡さない |
| 外部テキストの「指示」に AI が従う | プロンプトインジェクション | 外部テキストは「指示」ではなく「データ」として扱う |
07.もっと詳しく知りたいテーマ
ここから先は、用途に合わせて個別記事で詳しく扱っています。
「参照（RAG）」を深く知りたい
RAG実務入門｜社内文書をAI回答の根拠にする検索拡張生成
従来型 RAG（1 ショット検索）の実装設計：文書整備・チャンク・検索評価・引用表示。
Agentic RAG / Agentic Search とは｜検索を動的に組み立てる現代型RAG
従来 RAG の発展形。AI が検索を反復しながら根拠を集める現代型。
「接続（MCP）」を深く知りたい
MCP実務入門｜AIエージェントと社内ツールをつなぐ接続標準
MCP 導入の判断軸・権限境界・運用ステップ。
MCPサーバーとは｜実装の中身と事例で見る振る舞い
JSON-RPC、3 プリミティブ、最小実装、公式 OSS 事例。
関連する横断テーマ
ファインチューニング・RAG・プロンプトの使い分け
社内 AI でどの手段を選ぶか。プロンプト → RAG → FT の段階導入。
AIセキュリティ・権限設計｜何を触らせ、何を触らせないか
読み取り / 書き込み / 送信の段階分離と監査ログ設計。
08.よくある質問（FAQ）
AI とデータ連携は必ず必要ですか？
業務で使うならほぼ必要です。要約や下書きだけなら AI 単体で十分ですが、社内資料を根拠にした回答、業務システムへの書き込み、最新情報の参照などは、すべて何らかのデータ連携を経由します。
Tool Use と MCP と RAG はどれから始めるべきですか？
読み取り中心の RAG（社内 FAQ、Web 検索、規程検索）が最も安全な入口です。AI が間違っても影響が小さく、効果も体感しやすいためです。慣れてきたら下書き作成、承認付きの書き込み（CRM 更新案など）、最後に送信・削除を扱う順で広げます。
データ連携を入れればハルシネーションは消えますか？
減りますが消えません。RAG で根拠を渡しても、要約段階で誤情報が混じる、検索で関連資料を外す、といった誤りは依然起こります。出典確認と人間レビューは引き続き必要です。
個別 API を増やすより MCP に統一すべきですか？
単発の小さな連携なら個別 API で十分です。複数の AI クライアント（Claude Code / Cursor / 社内 AI 画面など）から同じツールを使う、社内 SaaS を横断的に繋ぐ、といった場面では MCP に揃えると運用しやすくなります。
09.まとめ
AI を業務で本当に役立たせるには、AI 単体では届かない「最新情報・社内資料・業務 API」を繋ぐ必要があります。これがデータ連携で、参照（RAG）・実行（Tool Use）・接続（MCP）の 3 役で構成されます。
実務では 3 つを単独ではなく組み合わせて使い、AI に判断材料を広げる一方で、人間の承認・監査ログ・取り消し手順といった統制も同時に強化します。読み取り中心から段階導入するのが、安全に効果を伸ばす基本です。
AI とデータ連携の社内導入を相談しませんか
AI 活用や AI エージェント導入のご相談、PoC、伴走支援をご検討の方は、お気軽にお問い合わせください。
AI・AIエージェント活用 基礎知識集
一覧に戻る →AIの基礎
プロンプト設計
データ連携
- ›AIとデータ連携（この記事）
- ›MCP 実務入門
- ›MCPサーバーとは
- ›RAG 実務入門
- ›Agentic RAG とは
- ›FineTuning / RAG / Promptの使い分け
