AIエージェント入門 — 4要素・開発手法・MCPと、問い合わせ対応のDify／LangGraph比較

リード

こんにちは、ぽまらのです。

AIエージェント勉強記 では、X投稿の文案＋校正を題材に、小さく作って測る話を書きました。一方で仕事の現場では、「チャットAIと何が違うのか」「どう作るのか」「最近よく聞く MCP とは何か」といった 全体像 の方が先に必要になることもあります。

この記事では、次の順で整理します。

  1. これまでのAIとAIエージェントの決定的な違い
  2. 構成する4つの要素（思考・記憶・ツール・自己反省）
  3. 開発手法 — ビジュアルとコード、それぞれの有名ツール
  4. MCP（Model Context Protocol）
  5. 事例 — 顧客問い合わせを複数エージェントで回す
  6. 同じ事例を Dify / LangGraph / MCP でどう組むかの概要（詳細は続編）

続編の予定:

回内容
本記事全体像・4要素・手法・MCP・事例の論理構成
次Difyでの構築詳細（準備中）
その次LangGraphでの構築詳細（準備中）

勉強記は「1題材の深掘り」、本シリーズは「仕事で選ぶ地図 → 実構築」です。概念の補足は 第1回 もあわせてどうぞ。

この回の全体像

flowchart TB
  A["対話型 AI vs 自律型エージェント"]
  B["4つの要素"]
  C["開発手法<br/>ビジュアル / コード"]
  D["MCP"]
  E["事例: 顧客問い合わせ"]
  F["Dify / LangGraph / MCP で組む"]

  A --> B --> C --> D --> E --> F

  classDef concept fill:#e8f4fc,stroke:#3d7ea6,stroke-width:2px,color:#1a1a1a
  classDef build fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1a1a1a
  class A,B,C,D concept
  class E,F build

1. 決定的な違い — これまでのAI vs AIエージェント

1-1. 従来のチャットAI（対話型）

ChatGPT や Claude のチャットに近い使い方です。

  • 人間が 都度プロンプト を出す
  • モデルは 答える・文章を作る が中心
  • 次の一手や外部システム操作は、基本的に人間が決める

「相談相手」「下書き係」としては強い一方、同じ手順を毎日・大量に回すには、毎回説明し直す負荷が残ります。

1-2. AIエージェント（自律型）

エージェントは、ゴールを渡すと 観察 → 判断 → 実行 を繰り返します。

  • 目的（例: 問い合わせの返信下書きを作る）が先にある
  • 必要なら検索・API・ファイルなど ツールを自分で選んで呼ぶ
  • 結果を見て、足りなければもう一度考える（ループ）
観点チャットAI（対話型）AIエージェント（自律型）
姿勢受け身 — 指示に応答能動的 — 目的に向けて進める
指示都度の会話ゴール + ルール（spec）
作業範囲主にテキスト生成ツール実行・多段の手順まで
成果物会話が中心ファイル・チケット・下書きなど 残る出力
人間対話のたびに関与半自動 — 重要判断だけ確認、も選べる

対立ではなく使い分けです。壁打ちはチャット、型の決まった業務はエージェント、が分かりやすい線です。

2. AIエージェントを構成する「4つの要素」

実装ツールは違っても、中身を分解するとだいたい次の4つに落ち着きます。

flowchart LR
  T["思考<br/>Brain / LLM"]
  M["記憶<br/>Memory"]
  A["ツール<br/>Action"]
  R["自己反省<br/>Reflection"]

  T --> A
  M --> T
  A --> R
  R --> T

  classDef e fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1a1a1a
  class T,M,A,R e
要素役割問い合わせ事例での例
思考（Brain / LLM）状況を理解し、次の行動を決めるカテゴリ判断、返信文の生成
記憶（Memory）短期の会話・長期のナレッジ・業務データFAQ、過去対応、注文情報の参照
ツール利用（Action）外部世界への作用チケット検索、注文API、メール下書き保存
自己反省（Reflection）出力を見直し、やり直しや修正をする禁則チェック、トーン修正、再生成

勉強記 の「文案＋校正」は、思考で書き、自己反省（別体の校正）で見直す形に近いです。記憶とツールを足すと、仕事のシステムになります。

3. 開発手法

大きく分けると ビジュアル開発 と コードベース開発 です。有名どころをそれぞれ3つ挙げます。本記事で 実際に構築して試す のは、ビジュアル側の Dify と、コード側の LangGraph です。

3-1. ビジュアル開発（ノーコード・ローコード）

画面上でノードやフローを繋ぎ、エージェントやワークフローを組みます。

ツール特徴向く場面
Difyエージェント／ワークフロー、ナレッジ、API公開業務PoC、社内FAQ・問い合わせ
n8n多数のSaaS連携、自動化ハブ既存ツールをつないだ業務自動化
Microsoft Copilot StudioMicrosoft 365／企業向けマネージド情シス・既存Microsoft環境

試す対象: Dify — 分類→下書き→チェックのフローを可視化しやすく、ナレッジ（FAQ）も載せやすいため。

3-2. コードベースの開発（プログラミング）

状態・分岐・再試行・社内APIを、コードで明示的に制御します。

ツール／枠組み特徴向く場面
LangGraph状態付きグラフ、複数ノード／エージェント直列・分岐・再試行がある業務
OpenAI Agents SDK公式SDKでエージェント＋ツールまず公式の型で小さく始める
LlamaIndex検索・RAG・ナレッジパイプラインFAQ・文書根拠が重要な用途

試す対象: LangGraph — 問い合わせの「分類→下書き→チェック」を State とノードで表現しやすく、後からAPI連携を足しやすいため。

3-3. どちらを先に触るか

優先第一候補
速さ・社内への説明しやすさDify
既存API・細かい制御LangGraph

よくある進め方は、Difyで論理フローを固め、足りない連携だけ LangGraph（やその周辺）に移す、です。

4. 最近の超重要トレンド — MCP（Model Context Protocol）

MCP（Model Context Protocol） は、AIアプリ／エージェントが 外部のツールやデータソースと話すための共通的な繋ぎ方 です。

これまでツール連携は、各製品ごとにプラグインや独自Function Callingを書くことが多かったです。MCPでは、次のような分離がしやすくなります。

役割内容
MCPサーバーファイル、DB、チケット、ブラウザなどを「ツール」として提供
MCPホスト／クライアントClaude Desktop、IDE、自作エージェントなどがサーバーを呼ぶ

エージェント開発での意味はシンプルです。

  • 記憶（ナレッジや業務データ）と ツール（Action） を、アプリ本体から切り離して差し替えできる
  • Dify でも LangGraph でも、同じMCPサーバーを共有する、という設計が現実的になる
  • 「モデルを変えても、繋ぎ口はMCPのまま」に寄せられる

注意点もあります。権限・秘密情報・監査は、MCPにしたから自動化されるわけではありません。どのサーバーを許可するか は人間の設計です。

5. AIエージェント事例 — 顧客問い合わせ対応

題材は 顧客問い合わせの半自動対応 です。送信は人間が行います。

5-1. なぜ複数エージェントか

体役割4要素との対応
① 分類カテゴリ・緊急度を決める思考（＋必要なら記憶）
② 下書きカテゴリに応じた返信案思考・記憶・ツール
③ チェックトーン・禁則・必須項目自己反省（＋思考）
flowchart LR
  U["問い合わせ"]
  A1["① 分類"]
  A2["② 下書き"]
  A3["③ チェック"]
  H["人間が確認・送信"]

  U --> A1 --> A2 --> A3 --> H

  classDef agent fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1a1a1a
  classDef io fill:#eceff1,stroke:#607d8b,stroke-width:2px,color:#1a1a1a
  class A1,A2,A3 agent
  class U,H io

5-2. 人間との分担

担当作業
エージェント分類、下書き、チェック
人間確認、手直し、送信

完全自動返信は、誤送信リスクが高いので本事例では扱いません。

6. 事例を Dify / LangGraph / MCP で組む — 4要素の対応

同じ論理構成を、実際に試す2手法と、MCPを軸にした繋ぎ方で見ます。

6-1. 比較の全体表

4要素Dify での置き場LangGraph での置き場MCP を使う場合
思考LLMノード（分類／下書き／チェック）各ノードの LLM 呼び出しホスト側のLLMが計画・呼び出し
記憶ナレッジ／会話変数Vector store・DB・StateMCPサーバー経由で文書・DB
ツール組み込みツール・HTTPリクエストPython関数・APIクライアントMCPツール（チケット、注文照会など）
自己反省チェック用LLMノードreview ノード、不合格なら再実行検証用ツール＋LLMの見直しループ

6-2. Dify で構築する場合（ビジュアル・実試行）

狙い: フローを画面で見せながら、分類→下書き→チェックを回す。

flowchart TB
  IN["問い合わせ入力"]
  C["LLM: 分類"]
  IF{"カテゴリ分岐"}
  D["LLM: 下書き<br/>+ ナレッジ"]
  V["LLM: チェック"]
  OUT["下書き + メモ"]

  IN --> C --> IF --> D --> V --> OUT

  classDef agent fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1a1a1a
  classDef io fill:#eceff1,stroke:#607d8b,stroke-width:2px,color:#1a1a1a
  class C,D,V agent
  class IN,IF,OUT io
4要素Dify での具体
思考ワークフローのLLMノードを3つ（分類／下書き／チェック）
記憶FAQ・対応マニュアルをナレッジに登録。変数でカテゴリを保持
ツール必要ならHTTPで注文照会。最初はナレッジのみでも可
自己反省チェックノードで禁則リスト照合。ダメなら修正して出力

手順のイメージ（概要） — ノード設定・プロンプト・テスト手順は 続編（Dify構築詳細） に譲ります。

  1. ナレッジにFAQ／テンプレを入れる
  2. ワークフローで分類ノード → 条件分岐 → 下書き → チェック
  3. 分類の出力は自由文ではなく 固定ラベル（JSON）
  4. 公開はAPIまたはチャット。送信は人間

向く点: PoCが速い、非エンジニアにも説明しやすい。
弱い点: 複雑な再試行や基幹連携は、後からコード側が楽なことが多い。

6-3. LangGraph で構築する場合（コード・実試行）

狙い: State を明示し、ノード単位で分類・下書き・チェックを実装する。

flowchart TB
  S["State<br/>inquiry / category / draft / flags"]
  N1["classify"]
  N2["draft"]
  N3["review"]
  H["人間レビュー用キュー"]

  S --> N1 --> N2 --> N3 --> H
  N3 -.->|要修正| N2

  classDef agent fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1a1a1a
  classDef io fill:#eceff1,stroke:#607d8b,stroke-width:2px,color:#1a1a1a
  class N1,N2,N3 agent
  class S,H io
4要素LangGraph での具体
思考各ノードのプロンプト＋LLM
記憶State の短期記憶、FAQはRetriever、注文はDB/API
ツールdraft から注文照会関数などを呼ぶ
自己反省review ノード。不合格なら draft へエッジで戻す

概念コードや State 定義、条件付きエッジでのやり直しは 続編（LangGraph構築詳細） に譲ります。

向く点: 再実行・ログ・社内APIを細かく制御できる。
弱い点: 初期の足場（環境・デプロイ・認証）に時間がかかる。

6-4. MCP を利用して組む場合（4要素の繋ぎ直し）

Dify単体・LangGraph単体でも動けますが、記憶とツールをMCPサーバーに切り出す と、次が楽になります。

flowchart LR
  H["ホスト<br/>Dify or LangGraph"]
  M1["MCP: FAQ検索"]
  M2["MCP: 注文照会"]
  M3["MCP: チケット下書き保存"]

  H --> M1
  H --> M2
  H --> M3

  classDef host fill:#e8f4fc,stroke:#3d7ea6,stroke-width:2px,color:#1a1a1a
  classDef mcp fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#1a1a1a
  class H host
  class M1,M2,M3 mcp
4要素MCP 利用時の置き場
思考これまでどおりホスト側のLLM／エージェント
記憶「FAQ検索」MCPサーバー（または社内文書サーバー）
ツール「注文照会」「チケット更新」などをMCPツール化
自己反省ホスト側のチェックノード＋、必要なら検証用MCP

実試行の進め方（現実的な順）

  1. まず Dify か LangGraph で、MCPなしの3体フローを動かす
  2. 注文照会など「外部I/O」だけを MCP サーバーに切り出す
  3. 同じMCPを、もう一方のホストからも叩けるか試す

こうすると、「手法を変えてもツール側は再利用」が体感できます。

7. どう選ぶか（短い指針）

状況推奨
まずは業務フローを固めたいDify で実試行
基幹APIや再試行が本丸LangGraph で実試行
複数ホストから同じ社内ツールを使いたいMCP でツール／記憶を外出し
勉強記のように品質を測りたいチェック体を分け、合格率を記録（第3回 の考え方）

まとめ

  • チャットAI は対話型、エージェント は目的に向けてツールも使いながら進む自律型
  • 中身は 思考・記憶・ツール・自己反省 の4要素で読むと、製品が変わっても比較しやすい
  • 開発はビジュアル（Dify / n8n / Copilot Studio）とコード（LangGraph / Agents SDK / LlamaIndex）。本記事で試すのは Dify と LangGraph
  • MCP は、記憶とツールの「差し替え可能な繋ぎ口」として重要
  • 事例の顧客問い合わせは 分類→下書き→チェック。送信は人間の半自動が安全

次は Dify、その次は LangGraph で、同じ事例の構築詳細を書きます。試してみて気になった点があれば、コメントや X で教えてもらえると嬉しいです。

スポンサーリンク

コメント