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

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

Part 1: LLM基礎と2025年AI現況

Part 2: 構造化出力とマルチLLMパイプライン

Part 3: モデル学習方法論

Part 4: RAGアーキテクチャと最新トレンド

Part 5: エージェント設計とマルチエージェントオーケストレーション ← 現在の記事

概要

DeNA LLMスタディシリーズの最終編です。Part 5では、LLMを活用したエージェント設計とマルチエージェントオーケストレーションを扱います。単純なプロンプトエンジニアリングを超えて、自律的に動作するエージェントシステムを構築する方法と、実務で考慮すべきコスト、パフォーマンス、信頼性の問題を集中的に見ていきます。

Part 5 の主要トピック

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

本記事では、DeNAの公式スタディ資料を基に、最新の研究成果と実務事例を追加して包括的にまとめました。

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年のエージェントシステムの核心トレンドは「完全自律」から「オーケストレーション」への転換です。

理由:

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

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%信頼できません。

問題事例:

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

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秒

実務推奨事項:

明確なワークフローがある場合 → SequentialまたはParallel
動的タスク分配が必要な場合 → Supervisor
創造的協働が必要な場合 → 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の利点:

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

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）

所見および感想

DeNA LLMスタディPart 5をまとめて得た核心インサイトです。

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

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

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

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

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

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

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

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

核心戦略:

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

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

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

シリーズ総まとめ

DeNA LLMスタディPart 1〜5をすべて完了しました。全学習過程を振り返ります。

全シリーズから得た洞察

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

参考資料

DeNA公式資料

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

n8nおよびワークフロー

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

メモリシステム

コスト最適化

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

Reading Complete!

概要

Part 5 の主要トピック

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

n8nとは？

ReAct Agent実装

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

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

コアコンポーネント

1. Core（コア）

2. Memory（メモリ）

3. Planning（計画）

4. Tool Use（ツール使用）

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

Self-Healingパターン

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

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

1. Sequential（順次）

2. Parallel（並列）

3. Supervisor（監督者）

4. Hierarchical（階層的）

5. Network（ネットワーク）

6. Custom（カスタム）

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

LangGraph

AutoGen

CrewAI

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

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

MemGPTパターン

Push vs Pull ハイブリッド

階層的メモリ構造

A-MEM（Zettelkasten基盤）

A-MEMアーキテクチャ

5. 実務事例：DeNA NOC Alert Agent

問題定義

ワークフロー設計

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

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

2. レイテンシ問題

3. コスト問題

成果

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

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

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

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

4. 量子化（Quantization）

コスト最適化総合戦略

所見および感想

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

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

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

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

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

シリーズ総まとめ

全シリーズから得た洞察

参考資料

DeNA公式資料

n8nおよびワークフロー

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

メモリシステム

コスト最適化

他の言語で読む

この記事は役に立ちましたか？

著者について

Kim Jangwook

関連記事

Anthropic Code Execution with MCP：AIエージェントの効率を98.7%向上させる革新技術

BigQuery用MCPサーバー構築：Datasetプレフィックスフィルタリング実装ガイド

LangGraphマルチエージェントシステム完全ガイド