LLMエージェントをAIオーケストレータに組み込む方法 — 生成AIを「判断構造」の中で使う —

LLMエージェントをAIオーケストレータに組み込む方法 — 生成AIを「判断構造」の中で使う —

最近のAIシステムでは、
LLM（Large Language Model）エージェントを
さまざまな場面で利用するようになっています。

例えば

意図理解
要約
推論
意思決定補助
ルール解釈

などです。

しかしここで重要な問題があります。

LLMは非常に強力ですが、

そのまま使うと判断構造が不透明になる

という問題があります。

例えば「ルール解釈」と「意思決定補助」をLLMに任せるケースです。

prompt = f"""
以下の社内ルールに基づいて、この取引を承認すべきか判断してください。

ルール:
- 高リスク国への送金は注意
- 初回取引は慎重に判断
- 金額が大きい場合は追加確認

取引:
- 金額: 500,000円
- 国: 日本 → ナイジェリア
- 取引履歴: なし

承認すべきなら 'approve'、そうでなければ 'reject' と答えてください。
"""

• ルールの解釈

• 条件の統合

• 曖昧な基準の判断

を行っています。

つまり

人間の判断に近い処理

を担っているように見えます。

しかし、この実装には重大な問題があります。

具体的には、

• なぜその判断になったのか

• どのルールが強く効いたのか

• どの条件が無視されたのか

• 判断責任はどこにあるのか

がまったくわからず、記録もされていません。

LLMの内部では

• 確率分布

• 文脈推論

• パターン類似

が働いています。

しかし、これらのプロセスは

外部から直接観測することができません。

つまり私たちは

• どの情報を重視したのか

• どのルールを優先したのか

• どのような推論経路を通ったのか

を取得することができないのです。

その結果、

判断の根拠を構造として記録することができない

という問題が生じます。

そしてこれは単に「説明できない」という問題ではなく

意思決定プロセスが
外部から参照可能な構造として存在していない

という状態になっています。

これはつまり、これまで述べてきた

Decision Trace が存在しない

という状態です。

この問題を解決するためには、

判断構造をLLMの内部ではなく外部に定義する必要があります。

そのためには、LLMを

AIオーケストレータの中の一つのエージェント

として扱う必要があります。

つまり

ではなく

として位置づける必要があります。

LLMエージェントの役割（ミクロ構造）

LLMエージェントの役割は一貫しています。

それは

非構造な情報を構造化されたSignalに変換すること

です。

1. 意図理解（Intent → Signal）

"I want to cancel my subscription"
↓
intent = cancel_subscription
confidence = 0.91

ここでLLMは

• 自然言語の意味を解釈し

• ユーザーの目的を抽出し

• 信頼度付きの構造データに変換しています

2. 知識推論（Context → Signal）

user_segment = "VIP"
risk_score = 0.15
↓
recommended_offer = VIP_discount

ここでLLMは

• ユーザーの文脈（VIP）を解釈し

• リスクレベルを考慮し

• 適切なアクション候補を推論しています

3. 文書解釈（Policy → Signal）

「高リスク国への送金は注意」
↓
risk_flag = high_risk_country
severity = medium

ここでLLMは

• 自然言語で書かれたルールを解釈し

• 抽象的な表現（「注意」）を具体的な意味に変換し

• 判断に利用可能な構造データへ落とし込んでいます

4. 説明生成（Trace → Explanation）

decision_trace → explanation

非構造データ
↓
LLM
↓
構造化Signal

LLMエージェントの内部構造

LLMエージェントはブラックボックスとして扱いません。

Prompt Builder
 ↓
LLM
 ↓
Parser
 ↓
Structured Signal

{
 "intent": "cancel_subscription",
 "confidence": 0.91
}

構造化Signal

になります。

AIオーケストレータ（マクロ構造）

次に、システム全体の構造です。

Event
 ↓
Signal Agents（LLM含む）
 ↓
Decision Engine（Contract / DSL）
 ↓
Policy Check
 ↓
Boundary
 ↓
Execution

ここで重要なのは

👉 判断は必ずLLMの外で行われる

という点です。

LLMとオーケストレータの関係（接続）

LLMとオーケストレータの役割は明確に分離されます。

LLM = Signal生成（意味・文脈）
Orchestrator = 判断制御（ルール・責任・記録）

LLM → Signal（意味理解）
Rules → Decision（判断）
Policy → Validation（適合性）
Boundary → Control（停止・エスカレーション）

それぞれの役割は次の通りです。

• LLM → Signal
  自然言語や文脈を解釈し、判断に必要な情報（Signal）を生成する

• Rules → Decision
  DSLやルールに基づき、条件を評価して最終判断を行う

• Policy → Validation
  法規・企業ルール・制約条件に照らして判断の妥当性を検証する

• Boundary → Control
  リスク閾値や例外条件に応じて、停止・エスカレーションなどの制御を行う

このように責務を分離することで、

• 判断ロジックが明示される

• ガバナンスが確保される

• 責任の所在が明確になる

• Decision Traceが記録可能になる

という効果が得られます。

なぜこの分離が必要なのか

LLMを直接判断に使うと、次の問題が発生します。

再現性（Reproducibility）

LLMは確率的なモデルです。

同じ入力でも
異なる出力になる可能性があります。

👉 判断が安定せず、結果の再現ができない

ガバナンス（Governance）

LLMは

法規
企業ルール
予算制約

といった

明示的な制約体系を内在していません

👉 組織のルールと判断が切り離される

責任構造（Accountability）

LLMは

責任主体ではありません。

👉 判断の責任を帰属させることができない

問題の本質

これらの問題に共通しているのは、

判断がLLMの内部に閉じている

という点です。

• 判断基準が外部から参照できない
• 判断ロジックを固定・変更できない

• 判断プロセスを記録できない

その結果、

判断をシステムとして管理することができない

という状態になります。

解決の方向性

この問題を解決するためには、

👉 判断を外部構造として定義する必要があります

つまり

• 判断ロジックを明示的に記述し

• ルールやポリシーとして管理し

• 実行プロセスを記録可能にする

という構造にする必要があります。

その上で

LLMは

• 判断を行うのではなく

• 判断に必要なSignalを生成する

という役割に限定されます。

Event
 ↓
Signal
 └ LLM Output
 ↓
Decision
 ↓
Policy
 ↓
Boundary
 ↓
Execution

LLM = 推論エンジン（意味理解・Signal生成）
Orchestrator = 判断制御（ルール・責任・記録）

Models
+ LLM Agents（Signal生成）
+ Rules / Contracts（判断）
+ Policies（制約）
+ Human（責任）
+ Ledger（記録）

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance