LLMは「判断」を持たない — Claude Code・プロンプト・そして判断外部化という設計構想

近年、LLMの使い方は大きく2つに分かれてきています。

1つは
Claude CodeのようにAIにコードを書かせて実行する方法

もう1つは
プロンプトによって直接答えを出させる方法

どちらも非常に強力で、実務でも急速に広がっています。

しかし、ここで1つ重要な問いがあります。

👉 そのシステムの「判断」はどこに存在しているのか？

プロンプト型AI — 判断しているように見えるが存在しない

例えば、次のようなプロンプトを考えてみます。

この取引は不正ですか？Yes or Noで答えてください
LLMはそれらしい答えを返します。

しかしこのとき、

  • 判断基準はどこにも明示されていない

  • なぜその判断になったのか分からない

  • 同じ入力でも結果が変わる

つまり

👉 判断は存在しているように見えるが、構造として存在していない

状態です。

Claude Code — 判断が固定されたように見えるが実は同じ問題

では、Claude Codeのようなコード生成AIはどうでしょうか。

例えば、

「不正検知のロジックを書いて」

と依頼すると、次のようなコードが生成されます。

if score > 0.8:
 freeze_account()
一見すると、これは明確な判断ロジックに見えます。

しかし実際には

  • なぜ0.8なのか分からない

  • 誰が決めたのか分からない

  • どの条件で変更されるのか分からない

つまりこれは

👉 判断ではなく、判断のように見えるテキストの固定化

です。

共通する問題 — 判断の所在がない

プロンプトとコード生成は、一見異なるアプローチですが、

本質的には同じ問題を抱えています。

方法 状態
プロンプト 判断が暗黙的
コード生成 判断が偶然固定される

どちらも

👉 判断の責任・根拠・変更履歴が存在しない

解決策は「ツール」ではなく「設計構想」

ここで重要なのは、

👉 Claude Codeを使うか、プロンプトを工夫するかではない

という点です。

必要なのは

👉 判断をどのように存在させるかという設計構想（メタ構造）

です。

判断を外に出すというアーキテクチャ

判断はLLMの中に置くものではなく、
外部に明示的な構造として持つ必要があります。

その基本構造は次のようになります。

Ontology

→ 意味の定義

DSL
→ 判断条件の定義

Behavior Tree
→ 実行構造
例えば、
IF fraud_probability > 0.8
THEN freeze_account
ELSE allow_transaction
このように表現することで、

  • 判断基準が明示される

  • 変更が可能になる

  • バージョン管理できる

  • 監査できる

LLMの正しい役割

では、LLMは何をするのか？

答えは明確です。

👉 LLMは判断する存在ではない

👉 判断を支援する存在である

具体的には：

  • Signal（スコア・要約）の生成

  • Ontologyの提案

  • DSLの生成支援

  • 判断理由の説明

つまり

LLM = 判断エンジン
ではなく
LLM = 判断構造の補助エンジン

プロンプトとClaude Codeの正しい位置づけ

ここで初めて、プロンプトとClaude Codeの役割を整理することができます。

まず、それぞれの本質的な役割は次の通りです。

プロンプト

👉 判断構造を「考える」ためのツール

  • 判断基準の言語化

  • 構造の整理

  • 代替案の比較

Claude Code

👉 判断構造を「実装する」ためのツール

  • DSLパーサの生成

  • Behavior Tree実行器の構築

  • Decision Traceの保存

  • APIやUIの生成

プロンプト × Claude Code — 組み合わせて初めて成立する

ここで重要なのは、

👉 この2つは対立するものではなく、組み合わせることで初めて意味を持つ

という点です。

なぜなら、それぞれ単体では明確な限界があるからです。

なぜ単体では不十分なのか

プロンプトだけの場合

プロンプトを使えば、

  • 判断基準は整理できる

  • 構造の説明もできる

しかし、

  • 実行系にならない

  • システムに固定されない

  • ログとして残りにくい

👉 設計はできるが、動かない

Claude Codeだけの場合

Claude Codeを使えば、

  • 実装はできる

  • システムとして動く

しかし、

  • 判断基準が暗黙になる

  • コードに埋め込まれる

  • なぜその判断になったか分からない

👉 動くが、なぜ動いているか分からない

組み合わせると何が起きるか

この2つを組み合わせることで、

👉 設計と実装が分離されたまま接続される

ようになります。

これは非常に重要な構造です。

実際の流れ

Step 1：プロンプトで判断構造を設計する

  • 不正検知の判断基準を整理

  • リスクレベルのOntologyを定義

  • DSLとして条件を表現

  • Behavior Treeの分岐を設計

ここでのポイントは、

👉 判断をコードにする前に、言語として外に出すこと

です。

Step 2：Claude Codeで構造を実装する

  • DSLパーサを生成

  • Behavior Treeランナーを生成

  • Decision Traceの保存処理を実装

  • APIとして外部公開

ここで重要なのは、

👉 すでに定義された判断構造を壊さずに実装すること

です。

この分離がもたらすもの

この構成により、システムは次の性質を持ちます。

1. 判断がコードから独立する

  • DSLとして外部管理される

  • 変更が容易になる

2. LLMの役割が明確になる

  • 設計支援に集中できる

  • 実行責任を持たない

3. システムが説明可能になる

  • 判断理由が追跡できる

  • Decision Traceとして保存される

最も重要なポイント

ここで最も重要なのは、

👉 プロンプト → Claude Code の順番で使うこと

です。

この順番を守らない場合、

  • Claude Codeが暗黙のロジックを生成する

  • 後から説明を付けるだけになる

結果として、

👉 判断が再びブラックボックスに戻る

しかし、この構成にも落とし穴がある

ここが非常に重要です。

👉 設計構想がない状態で使うと、プロンプトもClaude Codeも判断を埋め込んでしまう

プロンプトの場合

→ 会話の中に判断が消える

  • その場では説明できる

  • しかし構造として残らない

  • 次の実行では再現されない

Claude Codeの場合

→ コードの中に判断が固定される

  • 一見すると明示的に見える

  • しかし根拠や変更履歴が分からない

  • 暗黙の前提が埋め込まれる

つまりどちらも最終的には、

👉 判断を再びブラックボックスに戻してしまう

本当に重要なもの

ここで結論です。

重要なのは、

  • プロンプトでもない

  • Claude Codeでもない

👉 判断を外部に存在させる設計構想（メタアーキテクチャ）

です。

なぜこれが重要なのか

この違いは、単なる技術選択の話ではありません。

これは

👉 AIに責任を持たせられるかどうか

という問題です。

判断が構造として存在しない場合

  • 再現できない

  • 改善できない

  • 監査できない

  • 責任が取れない

つまり、

👉 AIは使えても、システムとしては成立しない

結論

  • プロンプトは判断を「語る」ことができる

  • Claude Codeは判断を「実装する」ことができる

しかし

👉 どちらも判断そのものにはなれない

最後に

これからのAIシステムは、

「モデル中心」ではなく

👉 判断構造中心

へと移行していきます。

そしてLLMはその中で、

👉 判断を担う存在ではなく、判断構造を支える部品

として使われるようになります。

👉 重要なのはツールではなく、判断をどこに存在させるかという設計構想である。

コメント

タイトルとURLをコピーしました