なぜClaude Code開発でLLMの回答精度が落ちるのか。AIへの指示をシステム設計へ昇華させる理由

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

AIエージェントを増やした瞬間に訪れる「精度の壁」

Claude Codeを使い、プロジェクト内に10体以上のエージェントを走らせる。

200行を超えるCLAUDE.mdを書き上げ、開発環境を構築した。

ある時からLLMの回答精度が落ち始める。

「さっき指示したことを忘れる」「JSON形式を崩す」「推論が浅くなる」。

これはモデルの性能限界ではない。

無意識に課している「構文的制約」と「環境的制約」が原因だ。

特定のフォーマットを強制するだけで、推論精度が最大で60ポイント以上変動する。

プロンプトを「文章」ではなく「システム設計」として捉え直す。

プロンプトの「構文」がモデルの脳を削る事実

LLMの推論精度は入力フォーマットによって変化する。

特に「フォーマット税（format tax）」という概念が重要だ。

モデルが特定の構文（JSONやXML）を正しく出力しようと努める際、注意資源（アテンション）が「構文の妥当性」に割かれる。

肝心の「推論」に回るリソースが削られる現象だ。

独立したベンチマーク調査では、ネストされたデータの回答精度において、YAMLは62.1％の正解率を記録した。

対してJSONは50.3％まで低下した。

特定の条件下ではこの差が17.7ポイントに広がる。

トークン効率の面でも、MarkdownはJSONと比較して34〜38％もトークン消費が少ない。

XMLはタグの開閉が必要なため、Markdownよりも80％もトークン量が増大する。

結果として推論コストが約2倍に膨れ上がる。

主要なフォーマットの特性は以下の通りだ。

* Markdown: 学習データが豊富で、モデルにとって自然な構造。トークン効率と推論精度のバランスが良い。

* YAML: ネスト構造の理解において、JSONやMarkdownを凌駕する精度を示す。

* XML: 指示内容と外部入力の境界を明示するのに適するが、トークン消費が激しい。

* JSON: 機械連携には不可欠だが、推論能力を低下させる「フォーマット税」が重い。

* TOON / CSV: 一様な配列データを扱う際に高い精度を発揮する。

「とりあえずMarkdown」や「常にJSON」という選択が、AIの知能をデチューンしている。

しんたろー：
Claude Codeでエージェントを増やすと、指示が複雑になりXMLタグだらけになっていた。
「タグで囲めば分かりやすくなる」という親切心が、AIの脳を「閉じタグ探し」に浪費させていた。
トークン量が増えるだけでなく、肝心のコードのロジックが甘くなる原因はここにある。

開発者視点で解き明かす「入力の構造的欠陥」

LLMを「入出力を持つ制御系システム」として捉える。

ソフトウェア工学では「入力の精度が出力の精度を規定する」のは自明の理だ。

バリデーションのないAPIにゴミデータを投げれば、システムは異常な挙動を示す。

プロンプトも同様で、入力の構造的品質をコントロールできていないことがハルシネーションの主因だ。

ここで重要なのが「ドメイン境界」による認知の盲点だ。

AI研究は「モデルの内部」に焦点を当てるが、ソフトウェア設計は「モデルの外側（入力の構造）」を重視する。

AIのモデル改善を待つのではなく、「入力のバリデーション」をシステム側の責務として実装する。

具体的には、以下の3つのレイヤーでプロンプトを再定義する。

APIスキーマとしてのフォーマット: タスクに応じてYAMLやMarkdownを使い分ける。
実行環境の制約: AIが判断を下す際の足場となる「環境ルール」を固定する。
参照範囲の安定化（止まり木）: 会話の途中でAIがどこを見ればいいのかを明示する。

AIとの対話が長くなるほど、AIが参照している「前提」は揺らぐ。

これを防ぐために「止まり木（Perch）」と呼ばれる参照ポイントを定義する。

「この仕様書の第3項について話している」「この関数のリファクタリングだけを考えている」という物理的な参照範囲を固定する。

長文の対話でも文脈が崩れにくくなる。

しんたろー：
制御工学のPID制御と同じで、フィードバックループが安定してないとシステムは発散する。
プロンプトを「お願い」として書いているうちは、AIは気まぐれな役者のままだ。
.claude/agents/の中身を、単なる指示書ではなく「システム構成定義ファイル」として書き直すと、挙動が安定する。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

AIを「安定したシステム」に変えるための具体的アクション

推論精度を最大化するためのアクションアイテムを整理した。

* 「思考」と「整形」を完全に分離する（2-pass方式）:

JSONでの出力が必要な場合でも、最初のプロンプトで直接JSONを書かせない。

まずMarkdownやYAMLで自由に思考・推論を行わせ、その結果を次のステップでJSONに変換させる。

複雑なロジックの正解率が向上する。

* ネストした構造にはYAMLを採用する:

設定ファイルや複雑な依存関係を読み取らせる際は、Markdownの箇条書きよりもYAMLの方が推論ミスが少ない。

階層が深い指示を与えるなら、YAMLを選択する。

* 「環境ルール」でAIの立ち位置を固定する:

「このプロジェクトでは、常に原因を確認してから変更を行う」「仕様にない内容は勝手に補完しない」といった、判断の前提となる環境ルールを定義する。

プロフェッショナルとしての「思考プロセス」を安定させる。

* 境界明示にはXML、ただし最小限に:

ユーザーの入力コードとAIへの指示が混ざり合う場合は、XMLタグによる境界設定が有効だ。

トークン消費が激しいため、重要な境界線のみに使用を限定する。

* 「止まり木」を会話の中に設置する:

「今からこのコードの32行目から45行目について議論する」と、参照範囲を絞り込む。

AIが特定の枝（止まり木）に降り立って思考できる状態を作る。

これらの手法は、Claude CodeのようなCLIツールでの開発において威力を発揮する。

プロジェクトのコンテキストが巨大化するほど、「構造による制御」の差が開発スピードの差となって現れる。

しんたろー：
AIを賢く使うコツは「AIに余計なことを考えさせない」ことだ。
構文のチェックはAIの脳の無駄遣いである。
開発者が「入力の型」を定義することで、AIは本来の推論パワーを全開にできる。
ThreadPostの開発でも、この「思考と整形の分離」を意識してから、バグの発生率が減った。

AI活用に関するFAQ

Q1: JSONで出力させると精度が落ちる場合、どうすればいいですか？

JSONは機械連携には最適ですが、推論には不向きな「フォーマット税」が高い形式です。解決策は「思考と整形を分ける」ことです。まずMarkdownやYAMLで思考・推論を行わせ、その結果を最後にJSONへ変換させる2-pass方式を採用してください。モデルは構文の妥当性を保つための注意資源を推論に集中でき、精度低下を防げます。

Q2: AIとの会話が途中でズレていくのを防ぐには？

会話のズレは、AIが参照している「前提」が揺らいでいることが原因です。単に役割を与えるだけでなく、その会話がどの仕様やどの段落を参照しているのかを明示する「止まり木（参照範囲）」を定義してください。また、会話の初期段階で「環境ルール」を固定し、AIが判断を下す際の足場を安定させることで、長文の対話でも文脈の崩れを最小限に抑えることができます。

Q3: 入力の構造化はどこまでやるべきですか？

入力バリデーションをシステム側の責務と考えてください。ユーザーの入力をそのままLLMに投げるのではなく、MarkdownやXMLで見出しや境界を明確にするなど、モデルが構造を理解しやすい形式に正規化することが重要です。これは「モデルの改善」に頼るよりも、入力の構造的品質を高める方が、コスト対効果の高いハルシネーション対策となります。情報の階層と境界を明確にすることには妥協しないでください。