連載の締めくくりです。API・MCP・RAGを見てきました。「結局、どれをいつ使えばいいのか」——この使い分けを、全体地図としてまとめます。結論から言えば、4つは競合ではなく、つなぐ対象が違う「層」として組み合わさります。
- 使い分けの大原則は「ルールが明確か／判断が要るか」
- 4技術は競合でなく「層」として連結する（つなぐ対象と役割が違う）
- 「つなぐ＝エンジニアが要る」は思い込み。ただしコスト構造は点検必須
大原則：「ルールが明確か／判断が要るか」
すべての使い分けは、たった一つの問いに集約できます。「その仕事は、手順が決まっているか。それとも、その場の判断が要るか。」
自動化ツールのMakeも同じ線引きをしています——「判断・推論が要る、特に人が書いた文章やメッセージのような非構造データが入力ならAI。ただ手順を実行するだけなら自動化」。現場語に訳すとこうです。
| 手順書どおりの仕事 → 自動化／API | 判断が要る仕事 → AI（MCP・RAG） |
|---|---|
| 受注が入ったら在庫を更新する | 問い合わせ文を読んで、どう返すか考える |
| 毎朝、数字を集めてチャットに投稿 | 契約書を読んで、注意点を洗い出す |
Zapierも「決まりきった連携（CRM×請求ソフトなど）はAPIで直接つなぐ方が速く・正確・直しやすい。何でもAI経由にしない」と戒めています。判断が要る1点だけにAIを差すのが、賢い設計です。
4技術は「層」として重なる——全体地図
4つは「どれが一番いいか」を競うものではありません。つなぐ対象と役割が違う、重なり合う層です。
| 技術 | 何をつなぐか | いつ使うか（現場語） |
|---|---|---|
| API | うちのソフト×よそのソフト | 決まった連携を、速く・正確に・安定して |
| MCP | AI×社内ツール | 判断つきの操作を、その場でAIにやらせたい |
| RAG | AI×社内文書 | 社内の資料・規程・マニュアルに答えさせたい |
| 自動化 | 上記を業務フローに乗せる | 決まった手順を流し、判断点だけAIを差す |
たとえば「問い合わせ対応」を組むなら——自動化が受付→分類の流れを作り、RAGが社内FAQを参照して回答案を出し、APIが顧客管理ソフトと同期し、人が最終送信を承認する。APIは土台の配管、RAGはAIに正しい記憶を、MCPはAIに手を、自動化は全部を流れに乗せる。役割分担して連結するのが本筋です。
「つなぐ＝エンジニアが要る」は思い込みです。ノーコード自動化（Zapier・Make・n8n・Dify）を使えば、非エンジニアでもAIと自社アプリをつなぐ入口に立てます。「社内規程に答えさせたい→RAG型ツール（Difyなど）」「それを業務フローに乗せたい→自動化ツール（n8nなど）」と、目的で選べば十分です。
ただしコスト構造は必ず点検を。たとえばZapier経由でAIにツールを使わせる場合、1アクション＝2タスク分の課金になるなど、「便利＝無料」ではありません。連載07のROIと同じで、使う前に運用コストを試算する。小さく試して、効果と費用を実測してから広げます。
問い合わせ対応の例で4技術を1枚に：下層「API＝配管（顧客DB同期）」→「RAG＝社内FAQを参照し回答案」→「MCP＝AIが手を動かす」→「自動化＝受付→分類→通知→[人の承認]の流れ」。中央に大原則「ルールが明確か／判断が要るか」「判断が要る1点だけAIを差す」。
まとめ
- 使い分けの大原則は「ルールが明確か／判断が要るか」。判断が要る1点だけAIを差す。
- 4技術は競合でなく層として連結。API＝配管、RAG＝正しい記憶、MCP＝手、自動化＝流れ。
- ノーコードで非エンジニアもつなげる。ただしコスト構造は試算してから。