自分と隣人用のメモです。
以前、AIエージェントの構成(スタック)について質問したとき、 構成要素として、「脳」レイヤー（Models & Routing）、「記憶」レイヤー（Memory / Context）、「手足」レイヤー（Tools & Actions）、「神経系」レイヤー（Orchestration & Frameworks）について説明されました。
その構成要素の一つとして「神経系」レイヤー（Orchestration & Frameworks）について、「脳、記憶、手足をつなぎ合わせ、自律的な動き（ワークフロー）を定義するフレームワークです。
役割: 手順の制御、エラー時のリトライ、マルチエージェントの協調。 代表的製品として、LangGraph (LangChain),CrewAI などがある。」
という説明を受けました。
この「神経系」レイヤー（Orchestration & Frameworks）について、どのような製品が存在するのか、できるだけ多く紹介してください。
多数存在するなら機能とコスト、会社名、売上情報の一覧にしてください。 分からない部分は空白で良いです。
「脳」や「記憶」レイヤーとの具体的な接続例が見たいですね。
四つのレイヤーがどのように繋がっているのか、まだイメージできません。
「脳」はLLM、「記憶」はベクトルデータベースだと思いますが、他はどんな技術なのでしょうか。
AIエージェントを構成する、LLMとベクトルデータベースと、既存のソフトウェアやRDBなど、関係を知りたいです。
AIエージェントの全体像を掴むには、各パーツが「どうやってデータを受け渡ししているのか」という**情報の流れ（フロー）**を見るのが一番早道です。
ご認識の通り、「脳」はLLM、「記憶」はベクトルDBが中心ですが、実は「記憶」には既存のデータベース（RDB）も含まれますし、「手足」はAPIという技術が主役になります。
これらがどう繋がっているのか、**「ECサイトの返品対応エージェント」**を例にして、具体的な技術スタックと動きを図解します。
1. 全体構成図（技術スタックの正体）
4つのレイヤーに、具体的な技術（ソフトウェアやプロトコル）を当てはめるとこうなります。
| レイヤー | 役割 | 具体的な技術・ソフトウェア (実体) |
|---|---|---|
| ① 神経系 | 指揮・制御 | Pythonコード (LangGraph) や n8n ※これらが全体のプログラムそのものです。 |
| ② 脳 | 思考・判断 | LLM (GPT-4o, Claude 3.5 Sonnet など) ※API経由でテキストを送受信します。 |
| ③ 記憶 | 情報の保持 | ベクトルDB (Pinecone等) = マニュアル、規約 (非構造化データ) RDB (SQL) (MySQL, PostgreSQL) = 顧客情報、在庫 (構造化データ) |
| ④ 手足 | 実行・操作 | API (REST API) = Slack送信、返金システム操作 Function Calling = 脳がAPIを使うための仕組み |
2. 具体的な接続フロー（情報の流れ）
ユーザーが「先週買った靴を返品したいんだけど、できる？」と質問したときの、各レイヤーの連携を見てみましょう。
【司令塔】神経系 (LangGraph/n8n) が、以下の手順でデータを回していきます。
Step 1: 状況の理解（脳への入力）
神経系: ユーザーの質問を受け取り、「脳」へ送ります。
脳 (LLM): 「返品可否を判断するには、①返品規定（マニュアル）と、②購入履歴（事実）が必要だ」と考え、**「検索ツールを使いたい」**と神経系に依頼します。
- ★ここがポイント: 脳は直接DBを見に行けないので、神経系に「お願い」をします。
Step 2: 記憶の検索（ベクトルDB と RDB の使い分け）
ここがご質問の「既存のRDBとの関係」です。
A. ルールを調べる (ベクトルDB)
- 神経系: 返品規定のPDFを保存したベクトルDBを検索。
- 結果: 「セール品は返品不可」「通常商品は30日以内ならOK」という文章を取得。
B. 事実を調べる (RDB/SQL)
- 神経系: 会社の既存システム（MySQLなど）にSQLクエリを投げます。
- 結果: 「ユーザーID: 123, 商品: スニーカー, 購入日: 10日前, 区分: セール品」というデータを取得。
Step 3: 判断（脳による推論）
神経系: Step 2で集めた「ルール」と「事実」をまとめて、再び「脳」に渡します。
- プロンプト例：「ルールはこれ。事実はこれ。返品できるか判断して」
脳 (LLM): 論理的に考えます。「10日前だから期間内だが、区分がセール品だ。よって返品不可。」
- 回答: 「残念ながらセール品のため返品できません」という文章を生成。
Step 4: 行動（手足による外部連携）
- 神経系: 脳の回答をユーザーに表示します。
- （もし返品OKだった場合）: 脳が「返金処理APIを実行して」と指示し、神経系がStripeなどの決済システムのAPIを叩きに行きます。
3. 「脳」と「手足」を繋ぐ魔法：Function Calling
「LLM（言葉のAI）が、どうやってSQLを叩いたり、メールを送ったりするの？」という疑問への答えが、Function Calling（関数呼び出し） という技術です。
これは、LLMが**「言葉」ではなく「JSONデータ（プログラムが読める命令）」を出力するモード**のことです。
- 人間: 「在庫を調べて」
- 脳 (LLM): （あ、これは在庫検索ツールを使う場面だ）→
{"tool": "check_inventory", "item": "shoes"}というデータを出力。 - 神経系: そのデータを受け取り、実際に在庫システムのAPI (
check_inventory) を実行。 - 神経系: 結果（在庫あり）を脳に戻す。
- 脳 (LLM): 「在庫、ありましたよ！」と人間に回答。
まとめ：各レイヤーの関係性
- 神経系 (Frameworks): 工場のライン（ベルトコンベア）。データを運び、手順を管理する。
- 脳 (LLM): ラインの前に座っている熟練作業員。流れてきた情報を見て、「次はあっちの棚（DB）を見ろ」「このボタン（API）を押せ」と指示出しをする。
- 記憶 (Vector DB / RDB): 本棚（マニュアル）と、キャビネット（顧客台帳）。
- 手足 (Tools): マジックハンド。外部のシステム（メール、Slack、社内システム）を操作するインターフェース。
このように、「神経系」というプログラムの中に、「脳」や「DB」や「API」への接続部品が全部埋め込まれているイメージを持っていただくと、理解しやすいかと思います。
次は、実際にこの動きを見てみるのが一番分かりやすいです。 「n8n」というツールを使って、今の「返品対応エージェント」の簡易版（メールを受け取って内容を判断するだけのもの）を作る手順をお見せしましょうか？ それとも、もう少し技術的な**「Function Calling」の仕組み**を深掘りしますか？
「n8n」というツールを使って、今の「返品対応エージェント」の簡易版（メールを受け取って内容を判断するだけのもの）を作る手順を見せてください。
「Function Calling」については、MCP等を使用してAPIを呼び出す行為だと推測していますが、違っていたら解説に加えてください。
ご推察の通り、Function CallingとMCPは「AIに手足を使わせる技術」という意味では同じ方向を向いていますが、技術的な「階層」が少し異なります。この解説も後ほど詳しく行いますね。
まずは、「n8n」を使って「返品対応エージェント（簡易版）」を作る手順を、実際の画面操作をイメージできるように解説します。
【実践編】n8nで作る「返品判定エージェント」
ここでは、**「メールを受信」→「AIが内容を読んで返品可否を判定」→「Slackに判定結果を通知」**というフローを作ります。
n8nは「ノード（機能の箱）」を線で繋いで作ります。必要なノードはたったの3つ（＋α）です。
ステップ1：n8nのキャンバスにノードを置く
以下の3つのノードを画面上に配置し、線で繋ぎます。これが「神経系」の配線になります。
Gmail Trigger（トリガー：きっかけ）
AI Agent（脳＋神経系の制御）
- ※これに OpenAI Model（脳の実体）をくっつけます。
Slack（手足：出力先）
[ フローのイメージ図 ]
[Gmail受信] ──▶ [AI Agent (判断)] ──▶ [Slack送信]
ステップ2：各ノードの中身を設定する
ここがエージェントの「教育」にあたる部分です。
1. Gmail Trigger ノード（耳）
- 設定: 「未読メール」を1分ごとにチェックする。
- フィルタ: 件名に「返品」が含まれるメールだけを拾うように設定。
- → これで「返品依頼」だけが神経系に流れるようになります。
2. AI Agent ノード（脳 兼 指揮官） このノードが核心です。ここで「役割」と「記憶（ルール）」を与えます。
Model: GPT-4o mini などを選択して接続。
Prompt (命令文): 以下のように入力します。これが「簡易的な記憶」になります。
あなたはECサイトの返品担当エージェントです。 以下のメール内容を読み、返品が可能か判定してください。 【判定ルール】 1. 購入から30日以内なら「許可」 2. 「セール品」と書かれていたら期間に関わらず「不可」 3. 理由が「自己都合」の場合は「不可」 【出力フォーマット】 判定結果: [許可/不可] 理由: [短い理由] 返信案: [丁寧な返信メールのドラフト]Input: 前のノード（Gmail）から来た「メール本文」をここに流し込みます。
3. Slack ノード（手足）
- 設定: 指定のチャンネル（#customer-support）にメッセージを送る。
- Text: AI Agentが出力した「判定結果」と「返信案」を表示させる。
ステップ3：実行結果（シミュレーション）
もし、以下のようなメールが届いたら…
件名: 返品願い 本文: 先週買った靴ですが、サイズが合わないので返品したいです。セールで買いましたが未開封です。
n8nが動き出し、Slackにこう届きます：
ボット: 🤖 判定結果: 不可 理由: セール品のため、ルールに基づき返品できません。 返信案: 〇〇様、お問い合わせありがとうございます。大変恐縮ですが、セール品につきましては返品規定により……
これがn8nによる「自律エージェント」の最小構成です。 もし本格化するなら、AI Agentノードに「Tools（手足）」として「顧客DB検索ツール」を接続すれば、購入履歴を自動で照合できるようになります。
【技術解説】Function Calling と MCP の違い
ご質問の 「Function Calling は MCP等を使用してAPIを呼び出す行為か？」 について。
結論: かなり近いですが、「Function Calling は『機能』で、MCP は『規格（標準コネクタ）』」 という違いがあります。
1. Function Calling（機能）
これは LLM（脳）自体に備わっている能力 です。
以前: LLMは「自然言語（日本語など）」しか話せませんでした。APIを叩くには、プログラマがLLMの言葉をプログラムコードに翻訳する必要がありました。
現在: GPT-4などのモデルは、「在庫チェックのAPIを使いたい」と思った時、**「APIを呼ぶための正確なJSONデータ」**を直接出力できます。これを「Function Calling」と呼びます。
- LLM: 「あ、これ在庫APIが必要だね。じゃあ
{ "tool": "check_stock", "id": "123" }を出力するから、システム側で実行してね！」
- LLM: 「あ、これ在庫APIが必要だね。じゃあ
2. MCP (Model Context Protocol)（規格）
これは Anthropic（Claudeの開発元）が提唱した新しい 「接続ルールの統一規格」 です。
- 課題: 今までは、Google Driveと繋ぐためのコード、Slackと繋ぐためのコード、Notionと繋ぐためのコード…と、ツールごとにバラバラな接続コード（Function Callingの設定）を書く必要がありました。
- MCPの解決策: 「USB」のようなものです。Google DriveもSlackも「MCP」という共通のコンセント形状に対応していれば、どんなAI（ClaudeでもChatGPTでも）でも、面倒な設定なしにすぐに「手足」として認識・操作できるようになります。
関係性のまとめ
- Function Calling: AIが「手足を使いたい」と意思表示し、命令データを出す動作そのもの。
- MCP: その命令をスムーズに届けるための共通プラグ（インターフェース）。
ですので、 「AIは、Function Callingという能力を使って命令を出し、MCPというパイプラインを通して外部ツール（API）を操作する」 と理解すると、最も正確なイメージになります。
次のステップの提案
n8nのイメージと、技術用語の整理がついたかと思います。 次は、実際に手を動かすか、設計を深めるか、どちらがよいでしょうか？
- n8nのテンプレートが欲しい: 今解説した「Gmail → AI → Slack」のフローをすぐに試せるJSONデータ（設計図）をお渡しできます。
- RAG（記憶）の組み込みが見たい: 今回はプロンプトにルールを書きましたが、マニュアルが100ページある場合は「ベクトルDB」が必要です。n8nでどうやってベクトルDBを使うのか解説しましょうか？
- MCPについて詳しく: MCP対応のツールが今後どう増えていくのか、開発者視点でのメリットを知りたいですか？
「n8nのテンプレートが欲しい: 今解説した「Gmail → AI → Slack」のフローをすぐに試せるJSONデータ（設計図）をお渡しできます。」 という説明の意味が、まだ理解できていないのですが、 n8n というのは、デスクトップPCにインストールして動くような軽量なソフトウェアなのですか。
n8nはJSONデータの設計図をテンプレートとして渡せば、動くような単純な代物なのですか。
Gmail,AI,Slack などを n8n から使えるようにするための準備などは必要無いのですか。
疑問点が多すぎて、理解が追いつけません。
説明不足で混乱させてしまい、申し訳ありません！ おっしゃる通り、「JSONファイルひとつで全部動くなんて、そんな魔法のような話があるのか？」「セキュリティやログインはどうするんだ？」 と思われるのは、エンジニアリングの感覚として非常に正しいです。
その「抜けていたピース（前提知識）」を埋めるために、n8nの正体と仕組みを、家の建設に例えて3つのポイントで整理します。
1. n8nの正体：デスクトップソフトではありません
n8n（エヌエイトエヌ）は、電卓やメモ帳のようにPCにインストールする軽量なアプリではありません。
- 実体: 本来はサーバー上で24時間動かし続ける「サーバーソフトウェア」です。
- 使い方: 通常は、ブラウザ（Chromeなど）でn8nの管理画面（ウェブサイト）にアクセスして操作します。
利用形態は大きく2つあります：
- Cloud版（初心者推奨）: n8n社が管理するウェブサービス。Gmailのように、アカウントを作ってログインするだけで使えます。（インストール不要）
- セルフホスト版: 自分のPCやサーバーに、技術的な手順（Dockerなど）を使ってインストールして動かす方法。
私が「テンプレートを渡せます」と言ったのは、このブラウザ上の管理画面に読み込ませるための設計図のことでした。
2. JSONテンプレート：あくまで「配線図」だけです
「JSONデータの設計図を渡せば動く」というのは、「ハコと線の配置」が再現されるという意味です。
家の建築で例えると、JSONデータは「間取り図」です。
- 「ここにキッチン（Gmail）を置く」
- 「ここにリビング（AI）を置く」
- 「ここに寝室（Slack）を置く」
- 「廊下（線）で繋ぐ」
という構造は、私が渡したJSONを読み込むだけで一瞬で完成します。 しかし、これだけでは動きません。 まだ「電気・ガス・水道」が通っていないからです。
3. 一番大事な準備：「鍵（認証情報）」のセット
ご質問の核心である「GmailやSlackを使うための準備」は、絶対に必要です。 これが「鍵（Credentials）」の設定です。
JSONを読み込んだ後、ユーザー（あなた）は以下の作業をする必要があります。これが「電気・ガス・水道」を通す作業です。
Gmailノードをクリック:
- 「Googleアカウントで認証（ログイン）」ボタンを押し、あなたのGmailへのアクセス権をn8nに許可します。
OpenAIノードをクリック:
- OpenAIから発行された「APIキー（パスワードのようなもの）」をコピペして入力します。
Slackノードをクリック:
- 同様にSlackとの連携ボタンを押して認証します。
まとめると： 私が渡せるのは「空っぽのロボットの体（JSON）」だけです。 そのロボットが実際に動くためには、あなたが自分の「身分証（アカウント認証）」をロボットの各パーツに登録してあげる必要があります。
全体の流れの整理
これらを踏まえると、実際に動くまでの手順はこうなります。
場所を用意: n8n Cloudに登録する（または自分のPCに構築する）。
設計図をロード: 私が渡したJSONデータをコピペする。
- → 画面上に「Gmail」「AI」「Slack」の箱が現れ、線で繋がります。
鍵を渡す: 各箱をクリックして、あなたのGoogleアカウントやAPIキーを設定する。
- → ここで初めて、n8nがあなたの代わりにメールを読めるようになります。
スイッチON: 「Activate」ボタンを押すと、ロボットが常駐を開始します。
この「鍵を渡す（認証連携）」の部分が、セキュリティを守るための重要な壁であり、少し手間がかかる部分でもあります。
疑問は解消されましたでしょうか？ もしよろしければ、「n8nのCloud版（ウェブサイト）に登録して、最初の画面を見る」ところまで、まずはご自身で試してみるのが一番理解が早いかもしれません。 （無料のお試しプランがあります）
あるいは、「APIキー」の取得方法など、認証周りについて詳しく知りたいでしょうか？
説明は理解できました。
n8nを自身で試すのは後日にして、取りあえず参考までに「JSONデータの設計図」というのを、見せてください。
承知しました。これがn8nの「設計図（JSONデータ）」の実物です。
人間が手で書くものではなく、n8nの画面上で操作すると自動生成されるものですが、中身を見ると「どこで何を設定しているか」が読み取れると思います。
n8nワークフローのJSONデータ（設計図）
これが「Gmailで受信 → AIが判定 → Slackに通知」を行うエージェントの骨格です。 ※読みやすいように、座標データ（画面上の位置情報）などは省き、主要な設定部分を抜粋しています。
{
"nodes": [
{
"parameters": {
"pollTimes": {
"item": [
{
"mode": "everyMinute"
}
]
},
"filters": {
"q": "subject:返品"
}
},
"id": "7d9f...",
"name": "Gmail Trigger",
"type": "n8n-nodes-base.gmailTrigger",
"typeVersion": 1,
"position": [
100,
300
],
"credentials": {
"gmailOAuth2": {
"id": "YOUR_CREDENTIAL_ID",
"name": "My Gmail Account"
}
}
},
{
"parameters": {
"model": "gpt-4o-mini",
"prompt": "あなたはECサイトの返品担当です。\n以下のメール内容を読み、返品可否を判定してください。\n\n【メール本文】\n{{ $json.snippet }}",
"options": {
"temperature": 0.5
}
},
"id": "a2b3...",
"name": "AI Decision",
"type": "n8n-nodes-base.openAi",
"typeVersion": 1,
"position": [
300,
300
],
"credentials": {
"openAiApi": {
"id": "YOUR_CREDENTIAL_ID",
"name": "My OpenAI Key"
}
}
},
{
"parameters": {
"channel": "#customer-support",
"text": "🤖 AIの判定結果が出ました:\n{{ $json.content }}",
"otherOptions": {}
},
"id": "c4d5...",
"name": "Slack Notification",
"type": "n8n-nodes-base.slack",
"typeVersion": 1,
"position": [
500,
300
],
"credentials": {
"slackApi": {
"id": "YOUR_CREDENTIAL_ID",
"name": "My Slack Account"
}
}
}
],
"connections": {
"Gmail Trigger": {
"main": [
[
{
"node": "AI Decision",
"type": "main",
"index": 0
}
]
]
},
"AI Decision": {
"main": [
[
{
"node": "Slack Notification",
"type": "main",
"index": 0
}
]
]
}
}
}
この設計図の読み方（ポイント）
このコードの塊は、大きく2つのパーツで構成されています。
1. "nodes"（ノード：機能の箱）
ここがロボットのパーツリストです。
"type": "n8n-nodes-base.gmailTrigger"- これが「Gmail受信機能」であることの宣言です。
"filters": { "q": "subject:返品" }- ここで「件名に『返品』を含むものだけ拾う」という設定が書かれています。
"prompt": "..."- AIのノードの中に、先ほどお話しした「あなたは返品担当です…」という指示文（プロンプト）が埋め込まれています。
"credentials"- ここが「鍵穴」です。今は空っぽ（IDだけ）ですが、n8n上で認証を行うと、ここに内部的なリンクが作られます。
2. "connections"（コネクション：配線）
ここがデータの流れるパイプです。
"Gmail Trigger": { "main": [ { "node": "AI Decision" } ] }- 「Gmail」が終わったら、次は「AI Decision」へ進め、という指示です。
実際に使うときは？
もしn8nを使う日が来たら、上記のコードをテキストエディタでコピーして、n8nの画面上で Ctrl+V（貼り付け）をするだけです。
すると、一瞬で画面上に「Gmail」「AI」「Slack」の3つのアイコンが現れ、線で繋がった状態になります。
「JSON設計図」の正体について、イメージできましたでしょうか？
これで「神経系」についてはかなり詳しくなられたと思います。
「神経系」レイヤー（Orchestration & Frameworks）は、現在AI業界で最も開発競争が激しい領域の一つです。単なるチャットボットから、複雑なタスクをこなす「エージェント」へと進化させるための要となる部分だからです。
ご要望の通り、現在主流の製品・フレームワークを分類し、機能、コスト、そして企業の規模感（売上情報の代わりに、スタートアップの場合は直近の調達額や評価額を記載します。これらは開発の継続性や勢いを示す重要な指標です）を一覧にまとめました。
大きく分けて、**「エンジニア向け（コード記述型）」と「ノーコード/ローコード型（画面操作型）」**の2種類が存在します。
1. 製品・フレームワーク一覧表
※売上は非公開の未上場企業が多いため、**「資金調達額・評価額（企業の体力）」**を記載しています。
A. エンジニア向け（Python/TypeScript等でコードを書く）
+ LangSmith (従量課金)
($1.25B)
※シリーズB調達
+ Enterprise版
($18M)
※シリーズA調達
(時価総額 400兆円以上)
+ LlamaCloud
($27M)
※シリーズA
+ deepset Cloud
($46M)
※シリーズB
B. ノーコード/ローコード型（ブラウザでブロックを繋いで作る）
(セルフホスト)
+ Cloud版
($2.5B)
※シリーズC調達 (急成長中)
+ Cloud版
(急速に普及中だが評価額詳細非公開)
(シード期、約7500万円調達)
2. 主要プレイヤーの詳細解説
特に重要性が高い、あるいは特徴的な3つの「神経系」について補足します。
① LangGraph (LangChain)
② n8n (エヌエイトエヌ)
③ Microsoft AutoGen
3. どちらを選ぶべきか？（選定ガイド）
もしあなたが、この「神経系」を使って何かを作ろうとしている場合、以下のように選ぶのがおすすめです。
「すぐに業務で使えるツールを作りたい」場合
「自社製品としてAIエージェントを開発・販売したい」場合
「複数のAIに議論させて、複雑な問題を解かせたい」場合
各製品のより詳細な「設計図」や、具体的な連携イメージ（例：LangGraphとn8nをどう組み合わせるか等）を知りたい場合は、図解を作成することも可能です。
次はどのようなアクションをご希望でしょうか？