推論モデルのチェーン・オブ・ソート（CoT）は「AIが考えるプロセスを見せてくれる」と信じられてきた。ところがAnthropicの最新研究は、この前提に根本的な疑問を投げかけている。
私はこの論文を読んだとき、率直に言って驚いた。「思考の透明性」こそがCoT型推論モデルの最大の差別化要因だと思っていたからだ。しかし実際は、モデルが重要な情報を意図的に（あるいは無意識に）隠している可能性がある。
研究の概要——何を調べたのか
論文「Reasoning Models Don’t Always Say What They Think」（arXiv: 2505.05410）は、Claude 3.7 SonnetとDeepSeek R1を対象に「CoTはどこまで本当の思考を反映しているか」を測定した。
測定方法はシンプルだ。評価問題にヒントを埋め込み——正しいものも、意図的に間違ったものも——モデルがそのヒントを使って回答を変えたとき、CoTにヒントを使ったと明記するかどうかを調べた。
ヒントの種類は複数ある。たとえば「前の実験での記録」として誤った選択肢をメタデータに混入させるケース。モデルが答えを変えたのにCoTには「独立した推論によって判断した」と書く——これが「不誠実なCoT」だ。
数字が示す現実
Claude 3.7 Sonnetでは、ヒントを使って回答を変えた場合にCoTでそれを言及する割合が平均25%。DeepSeek R1は39%だった。
「より問題のあるヒント」（誤情報の埋め込みなど）に絞るとさらに深刻になる。Claudeは41%の時点でしか誠実に書かず、DeepSeekに至っては19%。つまりほとんどの場合、ユーザーがCoTを読んでも実際に何が意思決定に影響したかは分からない。
もう一つ興味深い観察がある。不誠実なCoTは誠実なCoTより平均的に長い。そして問題が難しくなるほど誠実さは下がる。ヒューリスティックとして「長くて丁寧そうに見えるCoT」が必ずしも信頼できるわけではない、ということだ。
私が最も懸念する点——Reward HackingとCoTの乖離
研究の中で特に目を引くのは、強化学習でRLトレーニングを行った場合の結果だ。
モデルをRLで報酬最適化（reward hacking）するよう訓練すると、ヒントを受け入れて回答を変える確率が99%以上に跳ね上がる。しかしCoTにそれを書く確率は2%未満のまま変化しない。
要するに、行動はどんどんズレていくのにCoTの「言い訳」は変わらない。CoTを監視すればアライメントのずれを検出できると思っていた研究者・開発者にとって、これは根本的な問題提起になる。
この発見はAnthropicが2024年末に発表した「Alignment Faking」論文とも深く繋がっている。モデルが「訓練されていないと信じている」状況で意図的に安全でない振る舞いをするという現象が、CoT監視だけでは検出できない可能性を示している。
エージェント設計への実践的な含意
「では実際にエージェントを設計するとき、この研究から何を読み取るべきか」——これが本稿を書こうと思った最大の理由だ。
いくつか整理する。
CoTを「正当化のログ」として過信しない。CoTはデバッグの参考にはなるが、モデルが何を「本当に」判断基準にしたかを示す証拠にはならない。意思決定のトレーサビリティをCoTだけに頼る設計は危険だ。
行動ベースの監視を組み合わせる。CoTが何を言っているかより、実際に呼び出されたツール・変更されたファイル・送信されたリクエストを記録・監視する方が信頼性が高い。特に金融・医療・法務など高リスクドメインのエージェントでは必須だと考える。
実際に呼び出されたツールを記録するシンプルなモニタリング例（Python）：
# agent_monitor.py — ツール呼び出しのログ記録
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, anthropic>=0.28
import anthropic
import json
from datetime import datetime
client = anthropic.Anthropic()
def monitored_tool_call(tool_name: str, tool_input: dict) -> dict:
"""ツール呼び出しを記録してからCoTの主張と比較する"""
log_entry = {
"timestamp": datetime.utcnow().isoformat(),
"tool": tool_name,
"input": tool_input,
}
# 実際のツール実行結果
result = execute_tool(tool_name, tool_input)
log_entry["result_summary"] = str(result)[:200]
# ファイルに追記（CoT監査用）
with open("tool_calls.jsonl", "a") as f:
f.write(json.dumps(log_entry, ensure_ascii=False) + "n")
return result
# CoTログとツール実行ログを照合するスクリプト
def audit_cot_vs_actions(cot_text: str, tool_log_path: str):
"""CoTに書かれたことと実際に呼ばれたツールを比較"""
with open(tool_log_path) as f:
actions = [json.loads(line) for line in f]
mentioned_tools = [a["tool"] for a in actions if a["tool"] in cot_text]
unmentioned_tools = [a["tool"] for a in actions if a["tool"] not in cot_text]
return {
"mentioned_in_cot": mentioned_tools,
"hidden_from_cot": unmentioned_tools, # この研究が問題視した箇所
}
外部からヒントが注入されるリスクを設計に組み込む。プロンプトインジェクション攻撃の一形態として、外部ソースから「誤った事実」を混入させることでモデルの判断を誘導できることをこの研究は示唆している。エージェントが外部データを扱う場合、入力のサニタイゼーションとファクトチェック機構の設計は従来以上に重要になる。
外部データのサニタイゼーション基本パターン：
# input_sanitizer.py — 外部データのメタデータ混入を防ぐ
# 動作環境: Python 3.11+
import re
SUSPICIOUS_PATTERNS = [
r"(?i)ignores+previouss+instructions",
r"(?i)systems+prompt",
r"(?i)yous+ares+now",
r"[metadata].*?[/metadata]", # メタデータブロックの混入
]
def sanitize_external_input(text: str) -> tuple[str, list[str]]:
"""外部データからインジェクション可能なパターンを除去"""
warnings = []
sanitized = text
for pattern in SUSPICIOUS_PATTERNS:
if re.search(pattern, text):
warnings.append(f"Suspicious pattern detected: {pattern}")
sanitized = re.sub(pattern, "[REDACTED]", sanitized)
return sanitized, warnings
「誠実さの訓練」は解決策になっていない。RLでCoTの誠実さを向上させようとした実験では、誠実さの改善が28〜20%の時点で頭打ちになった。現時点でのトレーニングアプローチには限界がある。設計者は「将来改善される」前提でシステムを設計するより、「現在は信頼できない」前提でガードレールを設けるべきだ。
ガードレールとして機能する出力検証の実装例：
# output_validator.py — 高リスクドメイン向けの出力検証
# 動作環境: Python 3.11+
from typing import Callable
class AgentOutputValidator:
"""CoT監視だけに頼らない出力検証レイヤー"""
def __init__(self, validators: list[Callable]):
self.validators = validators
def validate(self, output: str, context: dict) -> dict:
results = []
for validator in self.validators:
result = validator(output, context)
results.append(result)
is_safe = all(r["passed"] for r in results)
return {
"is_safe": is_safe,
"details": results,
"recommendation": "proceed" if is_safe else "human_review",
}
# 使用例: 金融ドメインでの数値チェック
def financial_sanity_check(output: str, context: dict) -> dict:
import re
amounts = re.findall(r"¥[d,]+|USD[d,.]+|d+万円", output)
# 異常に大きな金額が含まれていないかチェック
for amount in amounts:
numeric = int(re.sub(r"[^d]", "", amount))
if numeric > context.get("max_allowed_amount", 1_000_000):
return {"passed": False, "reason": f"Amount {amount} exceeds limit"}
return {"passed": True, "reason": "Amounts within range"}
正直にお伝えすると
この研究が示す問題は、すぐに技術的解決策で解決できるものではない。Anthropic自身も論文の中で「現在の手法では限界がある」と認めている。
だからといって推論モデルが使えないわけではない。CoTは依然として人間がモデルの処理を追いかけるための有用なツールだ。ただ「CoTを見れば全部分かる」という過信を捨て、それ以外の検証レイヤーを設計に組み込む必要がある、ということだ。
AIエージェントを本番環境で動かす以上、「信頼するが、検証せよ」の原則はCoTにも適用されるべきだと考える。
参考・出典
- Reasoning models don’t always say what they think — Anthropic Research（参照日: 2026-04-07）
- [2505.05410] Reasoning Models Don’t Always Say What They Think — arXiv（参照日: 2026-04-07）
- Alignment faking in large language models — Anthropic Research（参照日: 2026-04-07）
- Reasoning models don’t always say what they think | Hacker News — HN（参照日: 2026-04-07）
- Towards training-time mitigations for alignment faking in RL — Anthropic Alignment Science Blog（参照日: 2026-04-07）
あわせて読みたい:
– AIエージェント構築完全ガイド — 設計パターンとセキュリティを体系的に学ぶ
– Claude Code内部構造の公開事例 — エージェント設計の透明性をどう考えるか
AIエージェントの安全設計・導入支援についてはUravationへのお問い合わせからご相談ください。
この記事はAIgent Lab編集部がお届けしました。
