AIエージェント・オーケストレーションと知識工学

実践技術教科書 · マルチエージェント / ローカルLLM / ハイブリッド検索

対象読者: Claude Code / LLM を日常的に使用し、マルチエージェント・ローカルLLM・ベクトルDBに興味のあるエンジニア 本書の目的: AIエージェントの並列オーケストレーション、ローカルLLM運用、ハイブリッド検索基盤、特許工学の自動化を体系的に理解する

マルチエージェントオーケストレーションの原理
Smart Model Routing — コスト最適化の自動判定
ベクトル検索とハイブリッド検索の原理
MoE（Mixture of Experts）アーキテクチャ
Reflexionパターン — 自己改善ループ
量子化（Quantization）— メモリ効率と品質のトレードオフ
ETL・UPSERT・VIEW — データ統合の基本パターン

第Ⅰ部　技術概念と原理

1. マルチエージェントオーケストレーションの原理

単一のLLMに全てを任せるのではなく、専門化された複数のエージェントを協調動作させる設計パターン。人間の組織における分業と同じ原理。

なぜ分業するのか

LLMは万能に見えるが、プロンプトが長くなるほど精度が下がる（注意力の分散）。タスクを分割し、各エージェントに短いコンテキストで専門タスクを割り当てることで、全体の品質が向上する。

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

(A) Orchestrator-Worker     (B) Pipeline             (C) Swarm
   ┌──────────┐             ┌──┐→┌──┐→┌──┐→┌──┐    ┌──┐ ┌──┐ ┌──┐
   │Orchestrator│            │A │ │B │ │C │ │D │    │1 │ │2 │ │3 │
   └──┬──┬──┬──┘            └──┘ └──┘ └──┘ └──┘    └──┘ └──┘ └──┘
      ▼  ▼  ▼               逐次実行                独立並列実行
    ┌─┐┌─┐┌─┐               （バトンリレー）         （全員同時）
    │W││W││W│
    └─┘└─┘└─┘

Orchestrator-Worker: 中央のオーケストレーターがタスクを分解し、ワーカーに並列配信。品質管理を集中制御。
Pipeline: タスクを逐次ステージに分解。前ステージの出力が次ステージの入力になる。品質ゲートを各段に設置可能。
Swarm: 独立タスクを同時実行。依存関係がないタスクの処理時間を最小化。

実行モード階層

autopilot（完全自律: idea → code）
 └── ralph（永続ループ: verify + fix 反復）
      └── ultrawork（並列実行: 独立タスク同時発射）

autopilotはralphを内包し、ralphはultraworkを内包する。階層を上がるほど自律度が高く、コストも増加する。

2. Smart Model Routing — コスト最適化の自動判定

原理

LLMにはコストと品質のトレードオフがある。全タスクに最高品質モデルを使うとコストが爆発する。タスクの複雑度を自動判定し、適切なモデルにルーティングすることで、品質を維持しながらコストを30-50%削減できる。

タスク到着
    │
    ▼
┌──────────────┐
│ 複雑度判定器  │ キーワード + トークン数 + コンテキスト
└──────┬───────┘
       │
  ┌────┼────┐
  ▼    ▼    ▼
HIGH  MED   LOW
 │     │     │
 ▼     ▼     ▼
大規模  中規模  小規模       コスト（入力100万トークンあたり）
モデル  モデル  モデル        $15    $3     $0.25

エスカレーション

小規模モデルで処理を試み、品質不足なら中規模に昇格、さらに不足なら大規模に昇格する。最大2回のエスカレーションで、必要最小限のモデルで処理を完了する。

ローカルLLMとの統合

クラウドAPIの最小モデルの代わりに、ローカルで動作するオープンモデル（Ollama経由）を使えば、LOWティアのコストをゼロにできる。ただし推論速度がクラウドの1/5程度になるため、バッチ処理向き。

3. ベクトル検索とハイブリッド検索の原理

キーワード検索の限界

クエリ: "解約 引き止め"
LIKE '%解約%' AND LIKE '%引き止め%'
→ "顧客の離脱を防ぐ施策" はヒットしない（文字列が異なるため）

ベクトル検索の仕組み

テキストを高次元ベクトル（数値配列）に変換し、意味的な距離を計算する。

"解約の引き止め方法"     → [0.023, -0.156, 0.871, ..., -0.033] (768次元)
"顧客の離脱を防ぐ施策" → [0.021, -0.152, 0.868, ..., -0.031] (768次元)

コサイン類似度 = 0.98 → 「ほぼ同じ意味」と判定

HNSW（Hierarchical Navigable Small World）

全ベクトルとの比較（O(N)）は遅い。HNSWは多層グラフ構造で、O(log N)の計算量で近傍を発見する。15万件のデータでも約17回の比較で近傍を発見（全探索の9,000倍高速）。

ハイブリッド検索

SQL（構造化フィルタ）とベクトル（意味的類似性）を統合する。

SQL検索の強み: 完全一致、範囲指定、属性フィルタ
ベクトル検索の強み: 同義語・類似概念を自動発見

ハイブリッド:
  1. SQLで属性フィルタ（domain="カスタマーサポート"）
  2. ベクトルで意味的検索（"チャーン防止"）
  3. 両結果をスコアで統合ランキング

4. MoE（Mixture of Experts）アーキテクチャ

Denseモデルとの違い

Dense Model:
  入力 → 全パラメータが活性化 → 出力
  14Bモデル → 14B全てが毎トークンで計算

MoE Model:
  入力 → Router（ゲート関数）→ Expert 2-3個だけ活性化 → 出力
  26Bモデル → 3.8Bだけが毎トークンで計算

  メモリ: 全Expert分必要（26GB相当）
  計算量: 活性化Expert分のみ（3.8B相当 → 高速）
  品質:   全Expert分の知識にアクセス可能（26B相当）

Routerの役割

入力トークンの特徴を見て、どのExpertに処理を送るか決定する。数学的な質問は「数学Expert」に、言語的な質問は「言語Expert」に送られる。これにより、計算量を抑えながら大規模モデルの知識を活用できる。

5. Reflexionパターン — 自己改善ループ

LLMが自身の出力を評価し、反省文を生成して再試行する自己改善パターン（Shinn et al., 2023）。

実行 → 出力 → 自己評価 → OK → 完了
                   │
                   └→ NG → 反省文生成 → 再実行（反省文をコンテキストに追加）
                              └→ ループ（最大N回）

特許明細書のような高品質要求のタスクで有効。品質スコア8.0以上になるまで自動反復する。

6. 量子化（Quantization）— メモリ効率と品質のトレードオフ

FP16（16bit）: パラメータ1つ = 2バイト → 高精度・大サイズ
Q4_K_M（~4.5bit）: パラメータ1つ ≈ 0.56バイト → 85%品質・1/4サイズ

例: 14.8Bパラメータモデル
  FP16:    14.8B × 2B = 29.6GB（一般的なPCに載らない）
  Q4_K_M:  14.8B × 0.56B = 8.6GB（16GB RAMに収まる）

K = K-quantization（重要な重みには高精度を割り当てる混合精度）
M = Medium設定

7. ETL・UPSERT・VIEW — データ統合の基本パターン

ETL（Extract, Transform, Load）

Extract:   ソースDBからデータ抽出
Transform: 国名正規化（「米国」→「US」）、ID体系変換
Load:      ターゲットDBにUPSERT

UPSERT（INSERT or UPDATE）

INSERT INTO table (...) VALUES (...)
ON CONFLICT(unique_key) DO UPDATE SET
  col = excluded.col  -- "excluded" = 新しい値を参照する仮想テーブル

冪等性を保証する。同じデータを何回投入しても結果が同じ。

VIEW（仮想テーブル）

CREATE VIEW v_deadlines AS
SELECT ...
  CASE WHEN deadline < date('now') THEN 'OVERDUE' ... END AS urgency
FROM deadlines d LEFT JOIN applications a ON d.app_id = a.app_id

データを持たず、SELECTするたびにリアルタイム計算。二重管理を回避。

第Ⅱ部　用語辞典

8. 用語辞典