DeNA LLM スタディ Part 5: エージェント設計とマルチエージェントオーケストレーション

シリーズ: DeNA LLMスタディ (5/5 - 最終回)

1. Part 1: LLM基礎と2025年AI現況
2. Part 2: 構造化出力とマルチLLMパイプライン
3. Part 3: モデル学習方法論
4. Part 4: RAGアーキテクチャと最新トレンド
5. Part 5: エージェント設計とマルチエージェントオーケストレーション ← 現在の記事

自律エージェントからオーケストレーションへ

シリーズの最終編です。プロンプト1行でLLMを動かす段階はもう過ぎました。今回は、自分で判断してツールを呼び出すエージェントをどう設計するか、そして複数のエージェントをどう束ねて回すかを扱います。ただ、自律性ばかり追うとコストが爆発し、挙動が制御できなくなります。だからこそ、実務でぶつかるコスト、パフォーマンス、信頼性の問題も合わせて見ていきます。

Part 5 の主要トピック

1. n8nを活用したLLMワークフロー - ノーコード/ローコード自動化プラットフォームでエージェント構築
2. エージェント設計原則 - コアコンポーネントとSelf-Healingパターン
3. マルチエージェントオーケストレーション - 6つのパターンとフレームワーク比較（LangGraph、AutoGen、CrewAI）
4. メモリおよび状態管理 - MemGPT、A-MEM（Zettelkasten基盤）
5. 実務事例 - DeNA NOC Alert Agent
6. コストおよびパフォーマンス最適化 - セマンティックキャッシング、バッチング、SLM活用

土台はDeNAの公式スタディ資料です。そこに最新の研究成果と実務事例を重ねました。

この内容が役立つとき、読み飛ばしてよいとき

エージェント設計やマルチエージェントは格好よく見えますが、すべての問題に合う道具ではありません。本文を読む前に、いま作ろうとしているものに本当にこの構造が必要なのかをまず見極めてください。

この内容が役立つ状況:

• 1回のLLM呼び出しでは終わらず、複数の段階を経て答えが出る作業（調査のあと分析、分析のあと執筆など）
• 外部ツールやAPIをLLM自身が選んで呼び出す必要がある場合（DB照会、Web検索、チケット作成など）
• 段階ごとに必要な専門性が異なり、役割を分けるのが自然な場合（調査担当と検証担当の分離）
• 長時間実行され、過去の文脈を覚えておく必要があるシステム（カスタマーサポートボット、個人秘書）
• 1日数百件以上を処理しつつ、コストとレイテンシを削る必要があるプロダクションパイプライン

読み飛ばしてよい状況:

• 単純な分類、要約、翻訳のように1回の呼び出しで終わる作業。ここではエージェントではなく関数ひとつで十分です。
• 入力と出力が固定された決定論的な処理。正規表現やルールエンジンのほうが安く速く安定します。
• プロトタイプ段階で、まず動作を確認したいとき。マルチエージェントはデバッグコストが大きいので、単一呼び出しで検証してから必要に応じて分割しましょう。
• コスト上限を制御できないのにNetwork（自由対話）パターンを使おうとする場合。対話の長さが暴走すると請求書も一緒に暴走します。

一言でまとめると、こうです。「複数段階 + ツール呼び出し + 記憶」が同時に必要なときだけエージェントを取り出し、どれか一つでも欠けるならまずもっと単純な道具を疑え。 マルチエージェントのコストの罠はAIエージェントのコストの現実で、オーケストレーションをもう一歩深く掘り下げた話はマルチエージェントオーケストレーション改善記で続きます。

1. n8nを活用したLLMワークフロー

n8nとは？

n8nはノーコード/ローコードワークフロー自動化プラットフォームです。2025年時点で422以上の統合をサポートし、LLMエージェント構築に特化した機能を提供します。

主な特徴:

• ビジュアルワークフロービルダー
• LangChain、Ollamaなど主要LLMフレームワーク統合
• ReAct Agentパターンネイティブサポート
• セルフホスト可能（データプライバシー保証）

ReAct Agent実装

n8nでReAct（Reasoning and Acting）パターンを実装する例です：

// n8n ReAct Agentワークフロー例
{
  "nodes": [
    {
      "type": "n8n-nodes-langchain.agent",
      "name": "ReAct Agent",
      "parameters": {
        "agentType": "react",
        "systemMessage": "あなたはデータ分析の専門家です。ユーザーの質問を分析し、適切なツールを選択して回答してください。",
        "tools": ["webSearch", "calculator", "database"]
      }
    }
  ]
}

2025年トレンド：オーケストレーション > 完全自律

DeNAスタディ資料と最新研究によると、2025年のエージェントシステムの核心トレンドは「完全自律」から「オーケストレーション」への転換です。

理由:

1. コスト爆発：自律エージェントの無制限API呼び出し
2. 予測不可能性：エージェント行動の制御困難
3. 信頼性不足：プロダクション環境での不安定性

n8nのようなワークフローツールが注目される理由は、まさに明示的なオーケストレーションを提供するためです。

2. エージェント設計原則

コアコンポーネント

LLMエージェントは4つのコアコンポーネントで構成されます：

graph LR
    Agent[AI Agent] --> Core[1. Core]
    Agent --> Memory[2. Memory]
    Agent --> Planning[3. Planning]
    Agent --> Tools[4. Tool Use]

    Core --> Prompt[Prompt Template]
    Core --> LLM[LLM Engine]
    Core --> Parser[Output Parser]

    Memory --> ShortTerm[Short-term<br/>対話履歴]
    Memory --> LongTerm[Long-term<br/>知識ベース]

    Planning --> ReAct[ReAct]
    Planning --> PlanExecute[Plan-and-Execute]

    Tools --> FunctionCall[Function Calling]
    Tools --> ToolRegistry[Tool Registry]

    style Core fill:#7B2CBF,color:#fff
    style Memory fill:#0066CC,color:#fff
    style Planning fill:#00A896,color:#fff
    style Tools fill:#F77F00,color:#fff

1. Core（コア）

エージェントの中心エンジンです。

構成要素:

• Prompt Template：システムメッセージ、ペルソナ定義
• LLM Engine：Claude、GPT-4、Geminiなど
• Output Parser：LLM出力を構造化データに変換

2. Memory（メモリ）

エージェントの記憶システムです。

Short-term Memory:

• 現在の対話セッションの履歴
• 一般的に最後のN個のメッセージ（N=5〜10）
• Context Windowに直接含める

Long-term Memory:

• 永続保存知識ベース
• Vector Database（Pinecone、Weaviateなど）
• RAGパターンで必要時に検索

3. Planning（計画）

エージェントが複雑なタスクを実行する戦略です。

ReActパターン:

Thought: ユーザーが会社の売上データを要求した。
Action: query_db
Action Input: SELECT revenue FROM sales WHERE year=2024
Observation: [結果: $1.5M]
Thought: 昨年との比較が必要だ。
Action: query_db
Action Input: SELECT revenue FROM sales WHERE year=2023
Observation: [結果: $1.2M]
Thought: 増加率を計算する必要がある。
Action: calculate
Action Input: ((1.5 - 1.2) / 1.2) * 100
Observation: 25%
Final Answer: 2024年の売上は$1.5Mで、前年比25%増加しました。

4. Tool Use（ツール使用）

LLMが外部ツールと相互作用するメカニズムです。

関数呼び出しの信頼性問題

DeNAスタディ資料で指摘された重要な問題：LLMの関数呼び出しは100%信頼できません。

問題事例:

1. 誤ったパラメータ：必須フィールドの欠落、型の不一致
2. ハルシネーション：存在しないツールの呼び出し
3. 無限ループ：同じツールの繰り返し呼び出し

Self-Healingパターン

エージェントがエラーを自動復旧するメカニズムです。

class SelfHealingAgent {
  async execute(task: Task): Promise<Result> {
    const maxRetries = 3;
    let attempt = 0;

    while (attempt < maxRetries) {
      try {
        const result = await this.runTask(task);
        return result;
      } catch (error) {
        attempt++;

        // エラー分析
        const analysis = await this.analyzeError(error);

        // 復旧戦略の選択
        if (analysis.recoverable) {
          task = await this.adjustTask(task, analysis);
          console.log(`Retry ${attempt}: ${analysis.suggestion}`);
        } else {
          throw new UnrecoverableError(error);
        }
      }
    }

    throw new Error("Max retries exceeded");
  }
}

3. マルチエージェントオーケストレーション

6つのオーケストレーションパターン

複雑なタスクを複数のエージェントで分散処理するパターンです。

1. Sequential（順次）

1つのエージェントの出力が次のエージェントの入力になる線形構造です。

使用事例:

• ブログ投稿作成：リサーチ → 下書き → 編集 → 公開
• データパイプライン：収集 → 精製 → 分析 → 可視化

利点:

• 実装が簡単
• デバッグが容易
• コスト予測可能

2. Parallel（並列）

複数のエージェントが同時に独立して作業する構造です。

使用事例:

• コンテンツ検査：品質検査 + 法的レビュー + 事実確認を同時実行
• マルチモーダル分析：テキスト + 画像 + オーディオを並列処理

3. Supervisor（監督者）

中央監督者がタスクを分配し、結果を統合する構造です。

使用事例:

• 複雑なリサーチ：監督者がサブトピックを複数のワーカーに分配
• コード生成：監督者がモジュール別実装をワーカーに割り当て

4. Hierarchical（階層的）

複数段階の監督者-ワーカー関係がツリー構造を成す方式です。

使用事例:

• 大規模プロジェクト管理：PM → チームリーダー → 開発者
• 複雑なシステム設計：アーキテクト → モジュール設計者 → 実装者

5. Network（ネットワーク）

エージェント間がP2P方式で自由に通信する構造です。

使用事例:

• 創造的な協働：アイデアブレインストーミング
• 民主的意思決定：投票ベースの合意

6. Custom（カスタム）

特定の問題に最適化された独自パターンです。

フレームワーク比較：LangGraph vs AutoGen vs CrewAI

3大マルチエージェントフレームワークの特徴を比較します。

特徴	LangGraph	AutoGen	CrewAI
コア概念	グラフベースワークフロー	対話ベースエージェント	役割ベースチーム
状態管理	明示的状態グラフ	対話履歴	内蔵メモリ
学習曲線	中	高	低
本番準備度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐

LangGraph

哲学：グラフですべてを表現

利点:

• 明確な制御フロー：すべてのパスがグラフに明示
• デバッグが容易：状態追跡可能
• 本番安定性：予測可能な動作

AutoGen

哲学：エージェント間の対話で問題解決

利点:

• 自然な協働：人間チームの対話方式を模倣
• 柔軟性：動的な対話フロー
• 創発的行動：予想外の問題解決

欠点:

• コスト爆発リスク（無制限対話）
• 予測不可能
• デバッグ困難

CrewAI

哲学：役割ベースのチーム構成

利点:

• 直感的：役割概念が理解しやすい
• 迅速なプロトタイプ：少ないコードで実装
• 内蔵メモリ：自動コンテキスト管理

欠点:

• ログ不足（デバッグ困難）
• 複雑なワークフローで限界
• 細かい制御が困難

パターン選択によるコスト差

実際のプロジェクトでパターン選択がコストに与える影響を分析します。

シナリオ：ブログ投稿生成（リサーチ + 作成 + 編集）

パターン	API呼び出し回数	予想コスト	処理時間
Sequential	3回	$0.15	90秒
Parallel	3回（同時）	$0.15	30秒
Supervisor	7回（監督者2 + ワーカー3 + 統合2）	$0.35	60秒
Network（AutoGen）	15〜50回（対話）	$0.75〜$2.50	120〜300秒

実務推奨事項:

1. 明確なワークフローがある場合 → SequentialまたはParallel
2. 動的タスク分配が必要な場合 → Supervisor
3. 創造的協働が必要な場合 → Network（ただし、コストリミット設定必須）

4. メモリおよび状態管理

MemGPTパターン

MemGPTは、オペレーティングシステムの仮想メモリ概念をLLMに適用した革新的アプローチです。

核心アイデア:

• Main Context（主メモリ）：LLMのContext Window
• External Storage（外部ストレージ）：ベクトルDB、リレーショナルDB
• Memory Manager（メモリマネージャー）：重要度によってswap in/out

Push vs Pull ハイブリッド

MemGPTは2つのメモリ戦略を結合します。

Push（能動的）:

• LLMが重要だと判断した情報を自動保存
• 例：「このユーザーはTypeScriptを好む」 → 保存

Pull（受動的）:

• 必要時に外部ストレージから検索
• 例：ユーザーが「私の好みを考慮して」と言えば → 検索

階層的メモリ構造

MemGPTは3段階のメモリ階層を提案します。

L1: Working Memory（Context Window）
    ├─ 現在の対話（5〜10メッセージ）
    ├─ アクティブタスク状態
    └─ システムプロンプト

L2: Recent Memory（短期保存）
    ├─ 最近のセッション（1週間）
    ├─ 頻繁に参照される情報
    └─ 一時タスクデータ

L3: Long-term Memory（長期保存）
    ├─ ユーザープロファイル
    ├─ ドメイン知識
    └─ 蓄積された学習データ

A-MEM（Zettelkasten基盤）

A-MEMは2025年にRutgers大学で提案された革新的メモリシステムです。Zettelkasten（ドイツ語で「メモボックス」）方法論をLLMエージェントに適用しました。

Zettelkastenとは？

• ニクラス・ルーマン（社会学者）が開発したメモ整理法
• 各メモに固有ID付与
• メモ間の接続（リンク）で知識ネットワーク構築
• 創発的洞察生成

A-MEMアーキテクチャ

A-MEMの核心はエージェントが自らメモリを組織化する点です。

実装例:

class AMem {
  notes: Map<string, Note>;
  graph: Graph;

  async createNote(content: string, metadata: Metadata): Promise<string> {
    const noteId = generateId();
    const note = new Note(noteId, content, metadata);

    // 自動タグ付け
    const tags = await this.extractTags(content);
    note.tags = tags;

    // 既存ノートとの類似度計算
    const similar = await this.findSimilarNotes(note);

    // 自動接続生成（類似度 > 0.7）
    for (const [relatedNote, similarity] of similar) {
      if (similarity > 0.7) {
        this.linkNotes(noteId, relatedNote.id, {
          type: "related",
          strength: similarity,
        });
      }
    }

    this.notes.set(noteId, note);
    return noteId;
  }
}

A-MEMの利点:

1. 動的組織化：手動構造化不要
2. 関連性ベース検索：直接マッチング + 間接的接続
3. 創発的洞察：ノート間の新しい接続発見
4. 拡張性：知識が増えても効率維持

5. 実務事例：DeNA NOC Alert Agent

DeNAで実際にプロダクションに適用したNOC（Network Operations Center）Alert Agent事例です。

問題定義

背景:

• 運用チームに1日100〜200件のアラート到着
• アラートの70%は誤検知（false positive）
• エンジニアが手動でアラート分類および対応

目標:

• アラート自動分類および優先順位指定
• 誤検知フィルタリング
• 対応ガイド自動生成

ワークフロー設計

graph TD
    Alert[アラート発生] --> Classifier[分類エージェント]

    Classifier --> |緊急| Escalate[エスカレーション]
    Classifier --> |一般| Analyzer[分析エージェント]
    Classifier --> |誤検知| Archive[アーカイブ]

    Analyzer --> Context[コンテキスト収集<br/>- ログ<br/>- メトリック<br/>- 履歴]

    Context --> RCA[根本原因分析<br/>Root Cause Analysis]

    RCA --> Guide[対応ガイド生成]

    Guide --> Ticket[チケット生成]
    Escalate --> OnCall[オンコールエンジニア呼び出し]

    style Classifier fill:#F77F00,color:#fff
    style Analyzer fill:#0066CC,color:#fff
    style RCA fill:#7B2CBF,color:#fff

プロダクション適用時の考慮事項

実際の展開過程で発見した問題と解決策です。

1. ハルシネーション問題

問題：LLMが存在しないログやメトリックに言及

解決:

// ツール呼び出し結果検証
class ToolExecutor {
  async execute(toolName: string, input: any): Promise<any> {
    const tool = this.registry.get(toolName);

    // 入力検証
    if (!this.validateInput(tool, input)) {
      return {
        error: "Invalid input",
        suggestion: "Please check the tool documentation",
      };
    }

    // 実行
    const result = await tool.execute(input);

    // 出力検証
    if (this.isEmpty(result)) {
      return {
        error: "No data found",
        suggestion: "Try different search parameters",
      };
    }

    return result;
  }
}

2. レイテンシ問題

問題：アラート → 対応まで平均45秒（目標：10秒）

解決:

• 並列処理：ログ/メトリック/履歴を同時収集
• キャッシング：頻繁に使用されるクエリ結果をキャッシング
• ストリーミング：部分結果を即座に表示

3. コスト問題

問題：1日200件 × $0.20 = $40（月$1,200）

解決:

• 誤検知プリフィルター：明確な誤検知はルールベースで先にフィルタリング
• バッチング：類似したアラートをまとめて処理
• SLM活用：簡単な分類は小さいモデル使用

成果

6ヶ月運用結果：

• 誤検知フィルタリング精度：92%
• 対応時間短縮：平均15分 → 3分
• エンジニア負担軽減：週20時間節約
• 月間運用コスト：$1,200 → $350（最適化後）

6. コストおよびパフォーマンス最適化

LLMエージェントシステムの最大課題はコストとレイテンシです。4つの核心最適化技法を紹介します。

1. セマンティックキャッシング（90%コスト削減）

概念：意味論的に類似したクエリはキャッシュされた応答を再利用

// セマンティックキャッシング実装
class SemanticCache {
  private cache: Map<string, CacheEntry> = new Map();
  private embeddings: EmbeddingModel;

  async get(query: string): Promise<string | null> {
    // クエリ埋め込み
    const queryEmbedding = await this.embeddings.encode(query);

    // 類似度検索
    for (const [cachedQuery, entry] of this.cache) {
      const similarity = cosineSimilarity(queryEmbedding, entry.embedding);

      // 類似度 > 0.95ならキャッシュヒット
      if (similarity > 0.95) {
        console.log(`Cache hit! (similarity: ${similarity})`);
        return entry.response;
      }
    }

    return null;
  }
}

効果:

• キャッシュヒット率60%達成時 → コスト60%削減
• レイテンシ95%減少（ネットワーク遅延除去）

2. バッチング（50%削減）

概念：複数のリクエストをまとめて一度に処理

効果:

• バッチサイズ10の場合 → コスト約50%削減
• ただし、レイテンシは若干増加（待機時間）

3. SLM（Small Language Model、14倍削減）

概念：簡単なタスクは小さいモデルを使用

// モデルルーティング
class ModelRouter {
  private smallModel: SLM; // Llama 3.2 (8B)
  private largeModel: LLM; // Claude Sonnet 4

  async route(task: Task): Promise<Response> {
    const complexity = this.assessComplexity(task);

    if (complexity < 0.3) {
      // 簡単なタスク：SLM ($0.001)
      return await this.smallModel.execute(task);
    } else {
      // 複雑なタスク：Large Model ($0.014)
      return await this.largeModel.execute(task);
    }
  }
}

効果:

• タスクの70%がSLMで処理可能な場合
• コスト：70% × $0.001 + 30% × $0.014 = $0.0049（平均）
• Large Modelのみ使用時：$0.014
• 削減率：65%（約14倍安価、SLM単独使用時）

4. 量子化（Quantization）

概念：モデルの重みの精度を下げてサイズとコストを削減

量子化レベル	モデルサイズ	精度損失	推論速度	使用事例
FP16（元）	16GB	0%	1x	ベンチマーク基準
8bit	8GB	〜1%	1.5x	プロダクション（精度重要）
4bit	4GB	〜3%	2x	ローカル実行、実験
2bit	2GB	〜10%	3x	プロトタイプ、デモ

コスト最適化総合戦略

4つの技法を組み合わせた実際の事例です。

Before（最適化前）:

// すべてのリクエストをClaude Sonnet 4で処理
const response = await claude.generate(query);
// コスト：$0.014 per request
// レイテンシ：2秒

After（最適化後）:

async function optimizedQuery(query: string): Promise<string> {
  // 1. セマンティックキャッシング（60%ヒット率）
  const cached = await cache.get(query);
  if (cached) return cached; // コスト：$0、レイテンシ：50ms

  // 2. 複雑度評価およびモデルルーティング
  const complexity = assessComplexity(query);

  let response: string;

  if (complexity < 0.3) {
    // 3. SLM使用（70%リクエスト）
    response = await smallModel.generate(query);
    // コスト：$0.001、レイテンシ：500ms
  } else {
    // 4. Large Model（30%リクエスト）
    response = await largeModel.generate(query);
    // コスト：$0.014、レイテンシ：2秒
  }

  // キャッシュ保存
  await cache.set(query, response);

  return response;
}

コスト計算:

キャッシュヒット（60%）：$0 × 0.6 = $0
キャッシュミス中：
  - SLM（28%）：$0.001 × 0.28 = $0.00028
  - Large（12%）：$0.014 × 0.12 = $0.00168

平均コスト：$0.00196 per request
削減率：86%（Before $0.014 → After $0.00196）

所見および感想

Part 5を終えて、頭に残ったことを書き留めておきます。

1. 「完全自律」より「オーケストレーション」

2025年トレンドの核心です。エージェントがすべてを自ら決定させるよりも、明確なワークフロー内で自律性を発揮させることが実務でより効果的です。

2. メモリがエージェントの真の知能を作る

MemGPT、A-MEMのような高度なメモリシステムは、エージェントを単純な「プロンプト実行機」から「学習し進化するシステム」に変えます。

3. マルチエージェントパターンは問題に合わせて選択

6つのパターンの中で「万能」はありません。各パターンは明確な長所と短所があります。

4. コスト最適化は必須、選択ではない

実務でLLMエージェントシステムの最大障壁はコストです。

核心戦略:

1. セマンティックキャッシング - すべてのシステムに適用（60%ヒット率だけでも大きな効果）
2. SLMルーティング - 簡単なタスク（70%）は小さいモデルで
3. バッチング - リアルタイム不要なタスクはまとめて処理
4. プリフィルター - 明確なケースはルールベースでフィルタリング

5. プロダクションエージェントは「Self-Healing」必須

LLMは確率的システムです。100%正確な応答は不可能です。

シリーズ総まとめ

これで全5編が終わりました。ここまでの道のりを少し振り返ってみます。

全シリーズから得た洞察

1. LLMはツールだ：万能ではない。問題に合った正しい使い方が重要だ。
2. プロンプト > ファインチューニング：90%の問題はプロンプトで解決可能だ。
3. RAGは必須：最新情報、ドメイン知識にはRAGが答えだ。
4. エージェントはメモリが命：状態のないLLMにメモリを付与することが真のエージェントだ。
5. コスト最適化は設計段階から：後で最適化しようとするとコストが10倍かかる。

参考資料

DeNA公式資料

• DeNAテックブログ
• DeNA LLMスタディ発表資料（社内資料、2024）

n8nおよびワークフロー

• n8n公式ドキュメント
• n8n AI Agentガイド

マルチエージェントフレームワーク

• LangGraph公式ドキュメント
• AutoGen GitHub
• CrewAI公式サイト

メモリシステム

• MemGPT論文
• A-MEM論文
• A-MEM GitHub

コスト最適化

• Semantic Caching論文
• LLM Cost Optimizationガイド

エージェント設計（一次資料）

• ReAct: Synergizing Reasoning and Acting in Language Models（論文）
• Building Effective Agents（Anthropic公式）
• How we built our multi-agent research system（Anthropic公式）

---

DeNA LLMスタディシリーズを完了しました！ このシリーズが皆様のLLMエージェント開発の旅に役立つことを願っています。