実践LLMをCoTで考えさせるリスク - AIの体調診察シリーズ (1)

AI LLM

はじめに

こんにちは、LegalscapeでAIを開発しているエンジニア、Dannyと申します。

Legalscapeでの弁護士向けのリーガルAIを作る上で最も重要なことの一つは、基盤となるモデル（主に大規模言語モデル：LLM）のfailure mode（失敗モード）に注意を払うことです。特に、外部データソースとのインタラクションを伴うスキャフォールディング・ロジック（たとえばRAGシステム）が関わる場合はなおさらです。

AI「診察」とその難しさ

まずやるべき仕事は、モデルの望ましくない挙動を観察し、その根本原因を特定し、修正を試みることです。このプロセスを、エンジニアより「医者のように考える」とよく表現します。症状を観察して（挙動を観察）、診断して（原因を特定し）、治療する（修正する）。これをLLMに対して行います。

LLMの失敗モードは一般的に「ハルシネーション」と呼ばれますが、これは実際には非常に広い症状群をざっくりとまとめた言葉です。もう少し厳密に定義すると、ハルシネーションはLLMの多くの失敗モードのうちの一つに過ぎません。たとえば、ハルシネーション、欺瞞（deception）、迎合（sycophancy）、長文コンテキストの失敗、推論（inference）の失敗、脱獄（jailbreak）、エージェント的／システム的失敗など、他にもさまざまです。

では、LLMを構成するプロセス・ビルディングブロック、はどうなっているのでしょう？ これも複雑です。訓練データ、モデルアーキテクチャ、学習目的、トレーニングカリキュラム、推論プロセス、エージェント的オーケストレーション…と続きます。

それぞれの失敗モードが複数の構成要素に根ざしているため、これらは複雑なマトリックスを形成し、LLMのエラー診断は非常に難しい課題になります。

さらに厄介なのは、私たちが日常的に使っているLLMのほとんどが、その構築過程や構成要素についての透明性を欠いていることです。透明性の欠如にも程度があり、プロプライエタリ（商用）モデルは、訓練データや手順、さらには「Chain of Thought, CoT」トークンまで完全に非公開です。一方、オープンウェイトモデルでも、訓練データや具体的な訓練手順の透明性が不足しています。

このことも診断を難しくしています。

だからこそAI研究が重要なのです。そして、AI研究が今回および今後のブログポストの基盤になります。オープンなAI研究と交流は、複雑なマトリックスのパズルピースを少しずつ理解・整理していく地道な努力です。

また、TransformerベースのLLMという研究の方向性について。LLMのインフラ（データセンターやハードウェア）への巨額投資を考えると、統計的手法で訓練されたトランスフォーマーベースのLLMの研究をさらに深めることは理にかなっています。得られる知見は、少なくとも近未来には有用でしょう。

この記事のフォーカス

この記事は、実際のシステムにおけるLLMのfailure mode（特にRAGやマルチエージェント構成も含む）を理解するためのシリーズの第1回目です。今回は「診断」、つまり「何が間違っているのか」「その根本原因は何か」をまず特定することにフォーカスします。「Treatment（治療）」はまた次回にする。

もっと具体的には、今回は、CoT関連のトピックにフォーカスします。

信頼できる証拠と洞察を得るために、このテーマに関する最近の研究論文を読みます。研究が「最近のものである」（理想的には過去3か月以内）ことが重要です。この分野の変化があまりにも速いからです。

Taxonomyで見る診察の複雑さ

主な失敗モード（症状）

まず、注目すべき失敗モードを、もう少し体系的に整理してみます。 2025年に発表されたハルシネーション関連の論文約50本をレビューした結果、おおよそ次のようなマップが描けます。

  1. ハルシネーション（意図しない誤情報）
  2. 欺瞞・虚偽・策略（意図的な誤情報）
  3. 迎合（Sycophancy）
  4. 長文コンテキスト失敗
  5. CoT reasoning・planningの失敗（今回のフォーカス）
  6. ショートカット学習
  7. Jailbreak／プロンプトinjection脆弱性
  8. Alignment／Calibrationの失敗
  9. agent／システム統合の失敗

LLMの構成要素

次に、診断のターゲットになり得る構成要素・コンポーネントを整理：

  1. 訓練データ
  2. モデルアーキテクチャ
  3. 学習目的とカリキュラム
  4. 推論設定（inference setup）
  5. agent的オーケストレーション
  6. 評価とモニタリング

失敗モードの分類にはさまざまなやり方があり、これも完璧なtaxonomyではありません。特にこの分野の動的・進化的な性質を考えれば、厳密な定義は難しいです。ただし目的はあくまで実践的でアクションにつながるガイドを作ることです。何か「アクション」が得られれば十分です。

上記の2つのリストを見てわかるように、両者の関係は一対一ではなく複雑なマトリックスになります。すべてを網羅するのは無理なので、ここでは特にin practice的に興味深いものをピックアップして掘り下げます。

最近の研究での調査

CoT関連の症状に注目

最初に目を引いたのは「Why Chain of Thought Fails in Clinical Text Understanding（なぜCoTは臨床テキスト理解で失敗するのか）（公開日2025年9月26日）」という論文でした。

この研究は、一般的なベンチマークではなく、現実の臨床テキストデータを使ってLLMの能力を評価しようというものです。データは多言語（9言語）に渡るさまざまな臨床タスクを含んでおり、日本語のような非英語言語を主に扱うLegalscapeのプロダクトにとって非常に参考になります。

具体的には、モデルへのプロンプトを「zero-shot」と「CoT（Chain-of-Thought）」の2モードで比較しました（これは上の構成要素Dに対応します）。CoTとは、モデルに明示的な推論をさせてから答えさせる手法で、一方ゼロショットは直接答えを出す方式です。

結果はこうでした：

  1. モデルの86.3%が、ゼロショットよりもCoTで性能が低下した
  2. 入力された臨床内容に「根ざしていない（groundedでない）」長いreasoningチェーンは失敗しやすい
  3. LLMは数値reasoningに脆弱で、数値・単位・測定関連のトークンが誤答の多くを占めた

LLM研究を追っている人なら、CoTがむしろハルシネーションを増やす可能性があることは驚かないでしょう。しかし②と③は「何が壊れているのか」を具体的に示しており、失敗検知のヒントになります。 「入力に根ざしていない」とは、入力テキストと推論文の類似度をテキスト解析で測るという意味です。類似度が低いほど、回答の正確性が低くなるということです。

どちらも価値ある発見です。③は、AIチームの内部実験でも観察されていた現象を裏付けています。②は、実運用環境で推論時にハルシネーションを検出する方向性を示しています。

ただし、限界もあります。この実験は、GPT-5やClaude 4のような最新の推論特化モデルでは行われていません。また、多くのモデル提供者が「Reasoningトークン」へのアクセスを許可していないため、この手法を実装できないという問題もあります。

Real-worldでのテストでCoT関連の症状が明らかになって、これをさらに理解し診断したいです。

前の論文で出てきた「grounded reasoning trace（根ざしたreasoning経路）」という概念は興味深いものでした。reasoningトレースをknowledge graph上のパス（経路）だと考えると、入力コンテキストに近いパスが「grounded」で、離れたものが「ungrounded」です。例えば、どのタイミングで逸脱が起こるのかを知りたいですよね。

これに関連して「Lost at the Beginning of Reasoning（公開日2025年6月26日）」という論文があります。

要約すると、reasoningチェーンの最初のステップでのエラーが、その後の推論全体の品質を著しく低下させるという結果でした。最初のreasoningステップが間違っている場合、最終予測の正確性は平均で40%低下します。彼らはこれを、推論トレースの最初のステップと最終出力のテキスト類似度を比較することで測定しました。

さらに、最初のステップだけで答えが出せる場合でも、LLMはしばしば冗長にトークンを出力し続ける（いわば“考えすぎる”）傾向があると指摘しています。

ここでいくつかの疑問が湧きます。 何が「grounded」なreasoningトレースを生むのか？また、もし最初のステップが最終出力を決めるなら、長い明示的なreasoningは本当に必要なのか？

「Is Chain-of-Thought Reasoning of LLMs a Mirage? A Data Distribution Lens（LLMのCoTは蜃気楼か？）（公開日2025年8月2日）」という論文が関連するインサイトを与えています。 モデルは本質的に「考えている」のではなく、推論的に見えるテキストを模倣している（つまりパターンマッチングしている）に過ぎず、無関係な情報に非常に脆弱だというのです。

つまり最初のメディカルの論文の結果も、「入力に無関係または馴染みのない（トレーニングデータにない）情報が含まれていると、長いCoTは失敗しやすくなる」という説明が成り立ちます。

ここで他のさらに深くreasoningトレースをグラフ構造としてモデリングする研究が有用になります。 たとえば「Teaching LLMs to Plan: Logical Chain-of-Thought Instruction Tuning for Symbolic Planning（LLMにプランニングを教える）（公開日2025年9月14日）」という論文。

この論文のキーフレーズは次の通りです：

  • 望ましい状態は、LLMが構造化された「反省」を通じて自らのplanningプロセスを自己修正する
  • Systematicな検証スキルをモデルに組み込む必要がある

この論文では、現在のCoTは論理的推論や体系的検証のための構造を欠いているため、planningタスクには不向きだと主張しています。また、LLMは自分のreasoningを信頼性高く批判・修正（self-correct）できないことを指摘しています。これは先ほどの「Lost at the Beginning of Reasoning」でも言及していました。

つまり？

これだけ多くの証拠がCoTの信頼性の低さを示しているなら、もうCoTは捨てるべきなのでしょうか？ これは複雑な問題で、ちゃんと回答するには色々分解が必要ですし、どんな手法にもトレードオフがあります。 それらを一旦無視して個人的にはshort answerは「NO」です。特に法務AIシステムを作る立場から言えば、CoTは訓練段階でも推論段階でも非常に効果的であることが多くの証拠で示されています。

では、CoTにどう向き合うべきか？

全てのCoT関連の症状をまとめて診断すると、少なくとも「構成要素」のABCDFと関連することになります（Eもセーフとはいえない）。「治療」するには、一つずつ問題を解決・抑制していく必要があります。

上記も含めさらに掘り下げたい論文や、診断に限らず治療（解決策）の面からもっと分析したいトピックは無数にありますが、今回は時間切れです。次回に持ち越します。

余談

LLMを使ったAIシステムの出力には、見たように、無数の潜在的なエラーソースがあります。Reasoning関連（test-time computeの一部しかない）だけでも「構成要素」のABCDFに関連し、治療が難しい。

AIアプリは従来型のソフトウェアとは違い、ユーザー体験がほぼ機械学習モデルの生出力そのものの上に乗っています。

それで重要になるのは「ホワイトボックス的なAIの使い方」。

AIの使い方には2つのアプローチがあります：

  • ブラックボックス型：モデルを神託（oracle）のように扱い、不確実性や内部構造を無視する。多くの大手AI企業はこの方向を目指しています。
  • ホワイトボックス型：ユーザーや開発者が内部をある程度理解・アクセスできる。訓練データ、手順、設計上の選択、reasoningトレースなどを把握し、システムの限界を理解して使う。

特に高リスク分野でAIを活用する場合、user educationに投資するホワイトボックス的アプローチが極めて重要だと考えています。

We Are Hiring

上記のような問題を抑制してユーザーに届けるAIを作るのチャレンジをLegalscapeで一緒にしたいですので、ぜひ検討してください！

参考資料