業務システムにLLM（大規模言語モデル、文章生成や質問応答を行うAIの基盤技術）を組み込む設計を検討している方に向けた内容です。カスタマーサポートの自動応答や社内ドキュメント検索などで、LLMの回答をそのまま業務判断に使う設計を見直す機会になれば幸いです。
Kaggleのベンチマークコンペ向けに公開された検証では、openai/gpt-oss-120bとqwen/qwen3.8-27bという2つのモデルに対し、知覚・感覚・認識論に関わる15の概念的質問を3つのブロックに分けて投げかけています。狙いは「モデルが統計的・記述的な知識と、人間の主観的な感覚（クオリア）を区別できているか」を確認することでした。
結果として浮かび上がったのは、モデルが「悲しい文章のパターンを識別する」「感情を分類する」「共感しているように振る舞う」ことはできても、実際に痛みや味覚を体験する状態（クオリア）には到達していないという構造的な限界です。この限界は哲学的な話にとどまらず、業務システムの設計にそのまま関わってきます。
何が起きるか：LLMの「もっともらしさ」が業務ロジックに紛れ込む
実務でよくある落とし穴は、LLMが生成した説明や判断理由を、そのまま業務ロジックの一部として扱ってしまうことです。
たとえば問い合わせ対応システムで、LLMに「この顧客は解約リスクが高いので優先対応すべきです」と理由付きで回答させたとします。文章としては筋が通っていても、その理由づけは統計的なパターンマッチングの産物であり、担当者が現場で得た実感（クオリア的な気づき）とは性質が異なります。
この違いを意識しないまま承認フローやアラート基準に組み込むと、もっともらしい説明文に引っ張られて、本来人間が確認すべき判断を素通りさせてしまう事象が起きます。影響範囲は与信判断、医療的な問診補助、人事評価コメントの自動生成など、説明責任が求められる領域で特に大きくなります。
なぜ起きるか：記号操作と意味理解のギャップ
原因を段階的に分解すると、まず押さえておきたいのは「構文（シンタックス）」と「意味（セマンティクス）」の違いです。
LLMは大量のテキストから次に来る単語の確率分布を学習し、文として自然な出力を作る仕組みです。これは言語の構文的なパターンの操作であり、人間が言葉の裏にある実体験と結びつけて理解する「意味の接地（シンボルグラウンディング）」とは別物です。
次に、感情や感覚を扱う質問でこのギャップが顕著になります。前述のベンチマークでは「悲しみや痛みといった感覚概念に触れたとき、モデルが記号接地の限界を認識できるか」をブロックP1として検証しています。モデルは悲しい文章のパターンを分類する「理論的な感情知能」は示せても、実際にその感情を感じている状態そのものは持っていません。
さらに厄介なのは、LLMの出力がこの限界を自己申告しないことです。モデルは「私はこの感情を実際には感じていません」とは言わず、人間が書いたような一人称的な説明文を自然に生成します。この流暢さが、開発者やレビュー担当者に「理解している」という誤った印象を与えやすくなります。
自分のプロジェクトが該当するか確認する方法
既存システムでLLMをどう使っているか、次の観点で棚卸しすることをおすすめします。
- LLMの出力がログ上どこで生成され、どのAPIレスポンスのどのフィールドに格納されているか（
reasonやexplanationといったキー名で理由づけ文字列を保存していないか） - その出力が条件分岐やスコアリングのしきい値判定にそのまま使われていないか（コードを
grepで検索し、LLM応答の文字列をif文の条件に使っている箇所を洗い出す） - プロンプト（モデルへの指示文）のテンプレートに「理由を説明してください」という指示が含まれていないか、含まれている場合その理由文が人間のレビューなしで下流処理に渡っていないか
- 利用しているモデルのバージョンと提供元のモデルカード（性能・既知の制約をまとめた公式文書）を確認し、感情推定や因果推論に関する注意書きがあるか
具体的には、プロンプトテンプレートを管理しているリポジトリで次のようなコマンドを実行し、理由づけ文字列を業務判定に使っている箇所を洗い出すのが手早い方法です。
grep -rn "reason\|explanation\|justification" src/ --include="*.py" --include="*.ts"ヒットした箇所のうち、戻り値がそのままDBの承認ステータスやアラートの発火条件に使われているなら、要注意です。
対策の手順
対策は大きく分けて、設計レベルと運用レベルの2段階で進めるのが現実的です。
設計レベルの対策
1. LLMの出力を「判断」と「根拠テキスト」に分離し、根拠テキストは参考情報として表示するだけにとどめる
2. 最終的な承認・却下・優先度決定は、人間またはルールベースのロジック（既存の与信スコアリングエンジンなど）に委ねる
3. LLMに感情推定や意図推定をさせる場合は、出力に確信度（confidence score）を必ず併記させ、しきい値未満は自動的に人間レビューに回す
運用レベルの対策
1. LLM出力をそのまま業務記録として残す前に、サンプリングでレビューする仕組みを週次・月次で設ける
2. 出力内容が「一人称的な感情表現」や「断定的な因果説明」になっていないか、プロンプト側でトーンを制御する（「推測であることを明示してください」という指示を追加する）
3. モデルを切り替える際（たとえばgpt-oss-120bからqwen3のような別系統へ）は、同じテスト質問セットで振る舞いの差分を確認してから本番反映する
この切り分けは、マイクロサービス間でのAPI契約を明確にする発想と似ています。LLMという「不確実な外部サービス」からの応答を、信頼境界の外側として扱い、内部の業務ロジックとは明確に分離しておくイメージです。
既存コードベースへの組み込みを見直す際のチェックリスト
保守対象のシステムにすでにLLM連携が入っている場合、次の点を確認してください。
- LLMのAPIレスポンスを保存するテーブル・ログに、生成日時・モデルバージョン・プロンプトのハッシュ値が記録されているか（後から挙動の変化を追跡できるか）
- 障害調査時に「なぜこの判定になったか」をLLMの出力文だけに頼らず、入力データからも再現できる手段があるか
- 多業種（金融・医療・人事）でこの仕組みを横展開する場合、説明責任の要件が業種ごとに異なる点を要件定義書に明記しているか
まとめ
LLMは文章としての一貫性や統計的な妥当性には強みがありますが、人間の主観的な体験や意味理解とは別のレイヤーで動いている仕組みです。
業務システムに組み込む際は、まず既存コードでLLM出力の理由づけ文字列がどこまで判定ロジックに浸透しているかをgrepなどで洗い出すところから始めてみてください。
そのうえで、判断とその根拠テキストを分離し、確信度に応じて人間レビューに回す設計に寄せていくことが、説明責任が求められる業務領域での事故を防ぐ現実的な一歩になります。