AI Agentの落とし穴：LLMの「非決定性」を理解し、実務で制御する3つの実践手法

2024年から2025年にかけて「AI Agent」という言葉が業界を席巻しました。しかし実際に本格的なAgent開発に取り組むと、多くの開発者が同じ壁にぶつかります。それが**LLMの非決定性**です。

非決定性とは、全く同じプロンプトとパラメータを与えても、実行するたびに出力が変化する性質を指します。この特性は創造的なタスクでは利点になりますが、業務システムやレビュー用途では深刻なリスク要因となります。

出力の揺らぎが引き起こすリスク

LLMの非決定性は、タスクの複雑さに比例して大きくなります。特に問題となるのは以下のシナリオです：

例えば、セキュリティ脆弱性を検出するAgentを開発した場合、今日は重大な脆弱性を発見できても、明日の実行では見逃す可能性があるのです。これは「たまたま動いた」という不安定な状態であり、プロダクション環境では許容できません。

temperature=0でも完全には制御できない

多くの開発者が最初に試みるのが`temperature`パラメータを0に設定する方法です。しかし、これでも完全な決定性は保証されません。

理由は以下の通りです：

1. **モデル内部のサンプリングプロセス**：温度を下げても確率的な選択は残る

2. **インフラレベルの変動**：分散システムでの計算順序の違い

3. **モデルバージョンの更新**：API側で静かにモデルが更新される

従来の決定的システムとの根本的な違い

従来のルールベースシステムや機械学習モデルとLLMの最大の違いは、この非決定性の「制御不可能性」にあります。

**従来のシステム**では：

**LLMベースのシステム**では：

メリットと注意点の両面分析

**非決定性のメリット**：

**注意すべき重大なリスク**：

適用範囲の明確な切り分けが必須

実務では、タスクを以下のように分類すべきです：

**非決定性を許容できるタスク**：

**決定性が必須のタスク**：

後者のタスクでLLMを使う場合は、次のセクションで紹介する対処法が不可欠です。

1. 複数回実行して結果を統合する

最もシンプルで効果的な方法は、**同じタスクを複数回実行し、結果をマージする**アプローチです。

# 疑似コード例
results = []
for i in range(3):  # 3回実行
    result = llm.review_code(code_snippet)
    results.append(result)

# 和集合を取る：いずれかの実行で指摘された問題をすべて集約
all_issues = merge_and_deduplicate(results)

**ポイント**：

2. 構造化出力とバリデーションの徹底

LLMに自由形式のテキストではなく、**JSON等の構造化フォーマット**で出力させることで、後処理での制御性が向上します。

# プロンプト設計例
prompt = """
コードをレビューし、以下のJSON形式で問題点を出力してください：
{
  "issues": [
    {
      "severity": "high|medium|low",
      "line_number": 123,
      "category": "security|performance|style",
      "description": "問題の詳細"
    }
  ]
}
"""

# バリデーション
response = llm.generate(prompt)
try:
    parsed = json.loads(response)
    validate_schema(parsed)  # スキーマ検証
    return parsed
except Exception as e:
    # リトライロジック
    return retry_with_correction(prompt, error=e)

**効果**：

3. タスクの細分化と段階的処理

複雑なタスクほど非決定性が増すため、**小さなサブタスクに分割**することで各段階での揺らぎを抑制できます。

**悪い例（一度に全部やらせる）**：

「このコードをレビューし、問題を見つけ、優先順位をつけ、修正案を提示してください」

**良い例（段階的に処理）**：

ステップ1: 「このコードから潜在的な問題箇所を列挙」
ステップ2: 「各問題のseverityを判定」（問題リストを明示的に渡す）
ステップ3: 「high severityの問題について修正案を生成」

各ステップで中間結果を保存し、次のステップに明示的に引き継ぐことで、処理全体の透明性と制御性が向上します。

アクション1: 既存のAgent処理を複数回実行してみる

今使っているLLM処理を、まったく同じ入力で5回連続実行してください。出力がどの程度変動するか観察することで、あなたのユースケースでの非決定性リスクを定量的に把握できます。

**チェックリスト**：

アクション2: temperatureとtop_pパラメータを調整実験

以下の組み合わせで同じプロンプトを試し、出力の安定性を比較してください：

クリティカルなタスクには最初の設定を、アイデア生成には最後の設定を使うなど、用途別の最適値を見つけましょう。

アクション3: 構造化出力への移行プランを立てる

現在自由形式テキストで出力させている処理を1つ選び、JSON Schema を定義してみてください。Claude や GPT-4 では構造化出力がネイティブサポートされています。

{
  "type": "object",
  "properties": {
    "conclusion": {"type": "string"},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "reasoning_steps": {"type": "array", "items": {"type": "string"}}
  },
  "required": ["conclusion", "confidence"]
}

これにより、出力の品質が向上し、後続処理の堅牢性も高まります。

LLMの非決定性は欠点ではなく、**特性**です。重要なのは、その特性を理解した上で適切に設計することです。

クリティカルなタスクでは決定性を高める工夫を徹底し、創造的なタスクでは非決定性を活かす。この使い分けがAI Agent開発の成否を分けます。

この情報は @大杉 海斗｜BloomBlock さんの投稿を参考にしています。