ReDevLab
AI技術 14分で読める

AIエージェントの仕組みと実装パターンを基礎から解説

ReActやReflexionなどの設計パターン、LangGraphやAutoGenなどのフレームワーク、Claude CodeやDevinなどの実例を交え、AIエージェントの全体像をエンジニア向けに解説します。

編集部
#AIエージェント#大規模言語モデル#自律型AI#LangGraph#Function Calling
AIエージェントの仕組みと実装パターンを基礎から解説

「AIエージェント」という言葉を最近よく耳にするけれど、ChatGPTのようなチャットボットと何が違うのか——そう感じている方は多いかもしれません。端的に言えば、AIエージェントは自分で計画を立て、外部ツールを使い、試行錯誤しながらゴールにたどり着くソフトウェアです。2023年のAutoGPT登場以降、この分野は急速に進化し、2025年にはClaude CodeやDevinのような実用的なプロダクトが次々登場しています。この記事では、筆者自身がエージェント開発で手を動かしてきた経験も交えながら、設計パターンからフレームワーク選定、運用上の落とし穴まで整理します。

チャットボットとAIエージェントは何が違うのか

まず、両者の違いを具体例で見てみます。

ChatGPTのようなチャットボットに「来週のチーム合宿の宿を予約して」と頼むと、「以下の手順で予約できます：1. じゃらんにアクセスして…」と手順を教えてくれます。丁寧ですが、実際に予約はしてくれません。

一方、AIエージェントに同じことを頼むと、カレンダーからメンバーの予定を確認し、予算内の宿を検索し、空室を問い合わせ、予約を完了してSlackに報告する——という一連の作業を自律的に進めます。つまり、「教える」のがチャットボット、「やる」のがエージェントです。

古典的AIからLLMベースエージェントへ

AI研究の教科書（Russell & Norvig, Artificial Intelligence: A Modern Approach）では、エージェントを「環境を認識し、判断し、行動するもの」と定義しています。この定義自体は1990年代から変わっていません。変わったのは、LLM（大規模言語モデル）の登場により、自然言語だけで認識・判断・行動のすべてを柔軟に扱えるようになった点です。

転機となったのは、2023年3月に公開されたAutoGPTです。GitHubで17万スター以上を獲得し、「AIが自律的にタスクをこなす」可能性を一気に広めました。同年6月にはOpenAIがFunction Callingを導入。LLMが「どのツールを、どの引数で呼ぶか」をJSON形式で構造的に出力できるようになり、エージェント開発の実装コストが大幅に下がりました。

実際に使えるAIエージェント製品の例

2025年〜2026年の時点で、すでに実用化されているAIエージェントをいくつか挙げます。

  • Claude Code（Anthropic）：ターミナル上でコードの読み書き、テスト実行、Git操作までを自律的に行う開発エージェント。本記事を公開しているこのサイト自体も、Claude Codeの支援で構築しています
  • Devin（Cognition）：ブラウザ、エディタ、ターミナルを自分で操作し、GitHub issueからPRの作成までをこなすソフトウェアエンジニアエージェント
  • GitHub Copilot Agent Mode：VS Code内でファイル編集、ターミナル実行、自己修正ループを回す開発支援エージェント
  • OpenAI Operator：Webブラウザを操作して、予約や購入などのタスクを代行するエージェント

これらに共通するのは、単に「回答する」のではなく、外部ツールを使って現実世界に作用する点です。

AIエージェントの内部構造——4つの基本コンポーネント

AIエージェントの設計を理解する上で最も参考になるのが、OpenAI研究者のLilian Wengが2023年6月にまとめたブログ記事 “LLM Powered Autonomous Agents” です。この記事で示されたアーキテクチャ図は、エージェント研究で最も引用されている図の一つです。

Wengの整理によると、LLMベースエージェントは以下の4要素で構成されます。

┌─────────────────────────────────────────────┐
│              AIエージェント                    │
│                                             │
│  ┌─────────┐  ┌──────────┐  ┌───────────┐  │
│  │ Planning │  │  Memory  │  │   Tools   │  │
│  │ (計画)   │  │ (記憶)   │  │ (ツール)  │  │
│  │          │  │          │  │           │  │
│  │ ・タスク  │  │ ・短期   │  │ ・Web検索  │  │
│  │  分解    │  │  (会話)  │  │ ・コード   │  │
│  │ ・自己   │  │ ・長期   │  │  実行     │  │
│  │  振り返り │  │  (DB)   │  │ ・API呼出  │  │
│  └────┬─────┘  └────┬─────┘  └─────┬─────┘  │
│       │            │              │        │
│       └──────┬─────┘──────────────┘        │
│              │                             │
│       ┌──────▼──────┐                      │
│       │  LLM Core   │                      │
│       │  (頭脳)     │                      │
│       └─────────────┘                      │
└─────────────────────────────────────────────┘

出典: Weng, L. (2023). "LLM Powered Autonomous Agents."
https://lilianweng.github.io/posts/2023-06-23-agent/ を元に筆者作成
  • LLM Core（頭脳）：自然言語の理解・推論を担う中核。GPT-4やClaude、Geminiなどが使われます
  • Planning（計画）：タスクを小さなステップに分解し、実行順序を決定します。後述するReActやPlan-and-Executeなどのパターンがここに対応します
  • Memory（記憶）：会話履歴を保持する短期メモリと、ベクトルDBなどに永続化する長期メモリの2層構造です
  • Tools（ツール）：Web検索、コード実行、データベースアクセスなど、LLM単体ではできない外部操作を実行します。Anthropicのtool use機能やOpenAIのFunction Callingがこれにあたります

この「LLM + Planning + Memory + Tools」というフレームワークは、現在のほぼすべてのエージェント設計の基盤になっています。

設計パターン——ReAct・Plan-and-Execute・Reflexion

エージェントの「考え方」を決めるのが設計パターン（アーキテクチャパターン）です。ここでは代表的な3つを、論文の具体的な実験結果を交えて紹介します。

ReAct：考えてから動く、を繰り返す

2022年にPrinceton大学とGoogle Researchが発表したReAct（Yao et al., ICLR 2023）は、最も広く使われているエージェントパターンです。名前は Reasoning + Acting の略で、「考える（Thought）→ 行動する（Action）→ 観察する（Observation）」を1ステップずつ交互に繰り返します。

論文中の例を見ると、仕組みがよく分かります。

質問: "Coloradoオアシスの東にある空港の標高は？"

Thought 1: Colorado Oasisの東にある空港を調べる必要がある
Action 1:  Search["Colorado Oasis"]
Obs 1:     Colorado oasis is a small community in Arizona...

Thought 2: 結果からこの場所はArizonaにあるとわかった。
           東にある空港を調べよう
Action 2:  Search["airport east of Colorado Oasis Arizona"]
Obs 2:     Gila Bend Municipal Airport is located east...

Thought 3: Gila Bend Municipal Airportの標高を調べる
Action 3:  Lookup["elevation"]
Obs 3:     The elevation is 789 feet

Answer:    789 feet

出典: Yao, S. et al. (2023). "ReAct: Synergizing Reasoning and
Acting in Language Models." ICLR 2023. arXiv:2210.03629

ReActの強みはリアルタイムの軌道修正です。検索結果が想定外でも、次のThoughtで方針を修正できます。論文の実験では、HotpotQA（複数ステップの質問応答）でChain-of-Thought単体よりも高い正答率を記録しました。

一方、弱点もあります。ステップごとにLLMを呼ぶためレイテンシとコストが増え、複雑なタスクでは途中で目標を見失う「ゴール漂流」が起きやすくなります。

Plan-and-Execute：最初に全体計画を立てる

ReActが「歩きながら考える」アプローチだとすれば、Plan-and-Executeは「地図を描いてから歩く」アプローチです。2023年にYohei Nakajima氏が公開したBabyAGIがこのパターンの先駆けで、LangChainのPlanning Agentsとして実装が広まりました。

┌──────────────┐
│   Planner    │  「旅行プランを作って」
│  (計画立案)   │  → Step 1: 日程を確認
│              │  → Step 2: フライトを検索
│              │  → Step 3: ホテルを検索
│              │  → Step 4: 予約を実行
└──────┬───────┘
       │
       ▼
┌──────────────┐     ┌──────────────┐
│  Executor    │────▶│  Re-Planner  │
│ (1ステップ    │     │ (計画修正)    │
│  ずつ実行)    │◀────│              │
└──────────────┘     └──────────────┘

Plannerが最初にタスク全体の計画を立て、Executorが1ステップずつ実行します。各ステップ完了後にRe-Plannerが残りの計画を見直し、必要に応じて修正します。

ReActと比べた利点は、全体の見通しが立つことです。複数のサブタスクを含む複雑な処理（例：「競合分析レポートを3社分作って」）では、最初に構造化された計画があるほうが、一貫性のある結果になります。

Reflexion：失敗から学ぶ自己改善ループ

Reflexion（Shinn et al., NeurIPS 2023）は、エージェントに「振り返り」の能力を与えるパターンです。実行結果を自己評価し、失敗した場合は**言語的なフィードバック（verbal reinforcement）**を自分自身に与えて再挑戦します。

タスク → 実行 → 評価 → 失敗
                        │
                        ▼
                 自己振り返り
           「APIのレートリミットを
            考慮していなかった。
            次はリトライ処理を入れよう」
                        │
                        ▼
              再実行（改善版）→ 評価 → 成功 ✓

論文の実験では、HumanEval（コード生成ベンチマーク）でベースラインの80.1%に対してReflexionは91.0%の正答率を達成しています。特にコード生成のような「正解が明確に検証できるタスク」で効果が高く、テストを実行して失敗した場合にエラーメッセージを手がかりに修正する、という人間の開発者と同じようなサイクルを回します。

3パターンの使い分け

パターン向いているタスク具体例
ReAct単発の調査・質問応答「この論文の主要な貢献を調べて」
Plan-and-Execute複数ステップの計画的処理「3社の競合分析レポートを作成して」
Reflexion正解が検証できるタスク「このテストが通るコードを書いて」

実際のプロダクトでは、これらを組み合わせることも珍しくありません。たとえばClaude Codeは、コーディングタスクでPlan-and-Execute的に計画を立て、個々のステップでReAct的にツールを使い、テストが失敗したらReflexion的に自己修正する——という多層構造になっています。

フレームワーク選定——LangGraph・AutoGen・CrewAI

設計パターンを理解したら、次はどのフレームワークで実装するかです。2024〜2025年に主要な選択肢が出揃いました。

LangGraph：グラフで制御フローを定義する

LangGraphはLangChainチームが開発したフレームワークで、エージェントのワークフローを**有向グラフ（ノードとエッジ）**で表現します。

from langgraph.graph import StateGraph

# ノード（処理ステップ）を定義
graph = StateGraph(AgentState)
graph.add_node("research", research_node)
graph.add_node("write", write_node)
graph.add_node("review", review_node)

# エッジ（フロー）を定義
graph.add_edge("research", "write")
graph.add_conditional_edges("review", should_revise,
    {"revise": "write", "done": END})

グラフ構造の利点は、条件分岐やループを明示的に定義できること。どこで繰り返しが起き、どこで分岐するかがコード上で一目瞭然なため、デバッグしやすくなります。公式ドキュメントにはチュートリアルが豊富に揃っています。

AutoGen：エージェント同士の会話で協調する

AutoGenはMicrosoft Researchが開発したフレームワークで、エージェント間の会話を通じて協調させる設計が特徴です。

たとえば「コードレビュー」のシナリオでは、「コーダー」エージェントがコードを書き、「レビュアー」エージェントがフィードバックを返し、コーダーが修正する——というやり取りをプログラムで定義します。研究プロトタイピングに強く、論文の実験再現にもよく使われています。

CrewAI：役割ベースのチーム編成

CrewAIは、各エージェントに**役割（Role）・目標（Goal）・背景（Backstory）**を持たせ、チームとして協働させるフレームワークです。

researcher = Agent(
    role="市場リサーチャー",
    goal="競合製品の最新動向を正確に把握する",
    backstory="10年のリサーチ経験を持つアナリスト",
    tools=[search_tool, scraping_tool]
)

ビジネス寄りのユースケース（マーケティング調査、コンテンツ制作ワークフローなど）で直感的に使えるのが利点です。

どれを選ぶべきか

筆者の経験上、迷ったらまずLangGraphから始めるのが無難です。理由は3つあります。（1）単一エージェントからマルチエージェントまでカバーできる、（2）制御フローが可視化しやすくデバッグが楽、（3）ドキュメントとコミュニティが最も充実している。マルチエージェントの研究用途ならAutoGen、チーム型の業務自動化を素早く組みたいならCrewAIという使い分けが現実的です。

運用の落とし穴——ハルシネーション・暴走・コスト

開発環境で動くエージェントを本番に持っていくと、想定外の問題が出てきます。筆者が実際に経験した事例も含めて整理します。

ハルシネーション：もっともらしい嘘をつく

エージェントがツール呼び出しの結果を無視して、「もっともらしいが事実でない」回答を生成するケースがあります。対策としては、ツール呼び出しの結果を必ず出力に含めるよう指示する「グラウンディング」と、重要な判断には人間の確認を挟む「Human-in-the-Loop」が有効です。

無限ループ：同じ操作を延々繰り返す

エージェントが同じツールを同じ引数で何度も呼び続ける「スタック」は、運用でよく遭遇する問題です。対策は単純で、最大ステップ数の制限（タスクの複雑度に応じて10〜50回）とタイムアウトの設定を必ず入れます。加えて、直前N回のアクションが同一なら強制終了する「繰り返し検知」も効果的です。

コスト爆発：気づいたらAPI料金が跳ね上がっている

エージェントはステップごとにLLMを呼ぶため、1タスクで数十回のAPI呼び出しが発生することもあります。筆者のプロジェクトでは、1記事の生成パイプライン（リサーチ → 執筆 → 品質チェック）で平均8回のLLM呼び出しを行っています。対策としては、ステップごとのトークン消費を記録し、日次・月次の利用額にアラートを設定することが鉄板です。安価なモデル（Haiku等）で済むステップと、高性能モデル（Opus等）が必要なステップを明確に分けるのもコスト最適化の基本です。

まとめ：小さく始めて段階的に自律範囲を広げる

AIエージェント開発で最も重要な原則は、一度にすべてを自動化しようとしないことです。

最初のステップとしておすすめなのは、ReActパターンで1つのツール（Web検索やコード実行）を使う小さなエージェントをLangGraphで組んでみることです。LangGraphの公式チュートリアルは丁寧に書かれており、30分程度で最初のエージェントが動きます。

そこから徐々に、ツールの数を増やす → Plan-and-Executeで計画を立てさせる → マルチエージェントで分業させる → Reflexionで自己改善させる——と段階的に自律範囲を広げていくのが、プロダクション投入への最短経路です。自律度を上げるほどリスクも増えるため、各段階で安全装置（ステップ上限、コスト上限、人間の承認フロー）を入れることを忘れずに。

参考文献

  1. Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023. arXiv:2210.03629
  2. Weng, L. (2023). “LLM Powered Autonomous Agents.” Lil’Log. lilianweng.github.io
  3. Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arXiv:2303.11366
  4. Wang, L. et al. (2023). “Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models.” ACL 2023. arXiv:2305.04091
  5. Wang, L. et al. (2023). “A Survey on Large Language Model based Autonomous Agents.” arXiv:2308.11432
  6. OpenAI. (2023). “Function calling and other API updates.” openai.com
  7. Anthropic. “Tool use with Claude.” docs.anthropic.com

参考文献

s

この記事を書いた人

sisk@sisk_ask

数学科出身のWebエンジニア

共有: