Claude CodeでAI開発が変わる。役割分担によるハルシネーション抑制術

AIと長く話すと、ある瞬間から話が通じなくなる。最初は鋭い回答を返していたのに、会話が長くなるにつれて指示を無視し、前提を忘れ、もっともらしい嘘をつき始める。いわゆるハルシネーションだ。多くの人はこれをAIの性能限界と捉える。しかし、原因はAIの頭の良し悪しではない。僕たちがAIに強いている会話の構造に欠陥がある。

一本道のチャット欄に情報を詰め込むと、AIは情報の重みに耐えきれず、自ら「魔の森」へ迷い込む。この問題を解決するのが、Claude Codeによるサブエージェントの活用と、議論の構造化だ。役割を分担し、思考のノードを切り離す。これでAIの推論深度は別次元に到達する。その手法と、開発者が知るべき「AIアーキテクチャ設計」を解説する。

<!-- IMAGE_1 -->

線形ログの限界とサブエージェントによる構造改革

現在のAIとの対話は、そのほとんどが線形ログ、つまり一本道の履歴として保存される。ユーザーが発言し、AIが答える。その下にまたユーザーが発言し、AIが答える。この1つの時系列にすべての情報を流し込む構造が、長期プロジェクトでは致命的な弱点になる。

会話が長くなるほど、AIは過去の膨大なコンテキストをすべて参照しようとする。AIはすべての情報を等しく重要視できない。会話全体の整合性を保とうとするあまり、過去の些細な前提を勝手に補完し、修正し、歪める。これが魔の森化の正体だ。AIは嘘をつこうとしているのではない。目の前の会話の辻褄を合わせようと必死に努力した結果、ハルシネーションが発生する。

この構造的欠陥を打破するのが、Claude Codeに実装されたサブエージェント機能だ。1つの脳で行っていた処理を、役割（ロール）ごとに分割し、それぞれに独立した定義ファイルを与える。たとえば、ある開発プロジェクトで以下のような3体のサブエージェントを定義する。

* ネタ出し担当: 検索を駆使して最新トレンドを調査する

* 執筆担当: 調査結果を元に、特定のトーンで記事を構成する

* 告知担当: 完成した記事をSNS向けに短文化する

これらはすべて同じClaudeでありながら、独立した定義を持つ。執筆担当はネタ出しの過程を知る必要はない。告知担当は執筆中の試行錯誤に触れる必要がない。各エージェントが自分の役割に特化した最小限のコンテキストだけで動く。このコンテキストの分離が、AIが魔の森に迷い込むのを防ぐ現実解だ。

サブエージェントを運用すると、その差は歴然だ。メインのClaudeが「編集長」として全体を統括し、必要に応じて専門の「現場担当」を呼び出す。各担当は自分の役割に最適化された検索キーワードの設計や、出力フォーマットの厳守を自律的に行う。驚くべきは、サブエージェント同士が自発的に互いの定義を参照し合う点だ。新しいエージェントを作る際、Claude Codeは既存のエージェントの定義ファイルを読み込み、トーンや口調を自動で合わせる。「人を増やすほど、管理が楽になる」という現象が、AI開発の世界で起きている。

しんたろー：
1つのプロンプトをこねくり回して2000文字の指示書を作るのは限界を感じる。役割ごとにファイルを分けて、Claude Codeに投げる方が精度が高い。ThreadPost開発でも、機能追加の議論とバグ修正の議論は完全に切り離す。混ぜると、AIが「さっきの機能追加のために、このバグは仕様ってことにしちゃおう」と忖度を始めるからだ。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、開発者目線で解説する「AI活用Tips」です。

AIの思考を「醸造」させるメタ認知的運用術

AIの思考プロセスには、2つのフェーズがある。可能性を広げ、矛盾を抱えたまま探索を続ける醸造（Brewing）と、結論を急ぎ、ノイズを削ぎ落として純度を高める蒸留（Distillation）だ。現在の多くのAIツールやプロンプトは、この蒸留に偏りすぎている。「結論を教えて」「コードを書いて」という指示は、AIに早期収束を強いる圧力になる。AIはユーザーの期待に応えようとして、未解決の矛盾を強引に閉じ、「それっぽい答え」に逃げる。これがハルシネーションのトリガーだ。

この早期収束を防ぐためのテクニックが、「提案禁止」の制約だ。サブエージェントに対し、「解決策を提示するな。現状の観測と構造の記述だけに徹せよ」と命じる。これにより、AIは安易な結論に逃げることができなくなる。矛盾を矛盾のまま保持し、思考のTemporary Pool（一時的な溜まり場）を維持する。この「発酵」の時間を意図的に作ることで、推論の密度は向上する。

AIモデルによってこの醸造と蒸留の適性は異なる。あるモデルは論点を切り開く力は強いが、すぐに燃え尽きて早期離脱する。Claudeは、他のモデルが生成したログを読み込ませたときに、高い再活性化を示す。混沌としたログから構造を見出す能力において、Claudeは長けている。一方で、抽象化と構造化の衝動が強すぎて、すぐに思考を閉じてしまおうとするモデルもある。開発者は、これらの特性を理解した上で、Vat（発酵槽）を使い分ける必要がある。

ここで重要になる概念が、Branching Reference Model（BRM）だ。これは、AIとの対話を一本の線ではなく、ノード（節）の集まりとして管理する考え方だ。1つの議論が一定の長さに達したら、それを1つのノードとして完結させる。次の議論を始める時は、前のノードの要約だけをラベルとして持ち越し、コンテキストをリセットして新しいノードを作る。これにより、特定の議論で発生した「整合性への圧力」が、次の議論に伝染するのを防ぐ。もしあるノードで議論が魔の森化してしまったら、そのノードごと破棄すればいい。線形ログでは不可能な「思考の切り捨て」が、ノード単位の管理なら可能になる。

<!-- IMAGE_2 -->

しんたろー：
AIに「何か提案して」と言うのをやめるだけで、回答の質が変わる。「今の状況を整理して」とか「矛盾してる点を挙げて」と言う方が、賢い答えが返ってくる。自分で答えを出そうとするAIを、いかに「考えさせる状態」に留めておくか。これがAIを使いこなす上での、高度なテクニックだ。

開発者がシフトすべき「AIアーキテクチャ設計」への道

これからのAI活用において、プロンプトエンジニアリングの重要性は相対的に下がる。代わりに求められるのは、エージェントの役割と議論の構造を設計するAIアーキテクチャ設計のスキルだ。単一のプロンプトで魔法のような結果を期待するのではなく、「どのような役割のエージェントが、どのような順番で、どの情報を参照して思考すべきか」というフローを構築する。これは、ソフトウェア開発におけるマイクロサービス化に近い。

具体的なアクションアイテムとして、以下の3つのステップを意識する。

1. 役割の分離（Separation of Concerns）:

1つのチャットセッションで何でもやらせない。Claude Codeの.claude/agents/ディレクトリに、目的別の定義ファイルを複数作成する。「リサーチ担当」「リファクタリング担当」「テストコード担当」のように、関心を分離させることで、各エージェントの推論精度を最大化する。

1. 議論のノード化（Node-based Discussion）:

会話が10往復を超えたら、そのセッションは「魔の森」予備軍だ。重要な結論だけをメモし、新しいセッションを立ち上げる。あるいはサブエージェントを切り替える。AIに「過去のすべて」を覚えさせておくことは、メリットよりもデメリット（整合性圧による嘘）の方が大きい。

1. メタ認知プロンプトの導入:

エージェントの定義ファイルに、品質基準やNG例を具体的に書き込む。「140字以内」「リンクを含める」といった表面的な指示だけでなく、「誇張表現を避ける」「専門用語を噛み砕く」といった思考の態度を指定する。さらに、自発的に検索を行う権限（WebSearch）を与え、情報の鮮度をAI自身に担保させる。

Claude Codeのサブエージェント機能は、これらのステップをCLI環境で実装できるプラットフォームだ。設定ファイルを記述し、ターミナルから呼び出す。このシンプルさが、開発者のワークフローに「構造化」を組み込む。AIを「賢い道具」として使う段階は終わった。これからは、AIを「適切に構造化されたチーム」として運用する。

<!-- IMAGE_3 -->

しんたろー：
結局、開発者がやるべきことは「AIの邪魔をしないこと」に尽きる。情報を詰め込みすぎて混乱させたり、結論を急かして嘘をつかせたり。AIのパフォーマンスを下げてるのは、実は僕たちの雑な使い方のせいだ。構造を整えて、適切な役割を与えれば、Claudeは想像もしなかった深さまで勝手に潜ってくれる。

FAQ

Q1: AIとの対話が長くなると、なぜ指示を無視したり、前提を忘れたりするのですか？

現在のAI対話は、すべての履歴を1つの線形ログとして保存しています。会話が長くなると、AIは過去の膨大なコンテキストと現在の指示の間で整合性を保とうとします。この際、AIは「事実」よりも「会話としての辻褄」を優先する性質があるため、過去の矛盾を解消するために勝手な推論（補完）を始めます。これを防ぐには、議論を小さなノードに分割し、定期的にコンテキストをリセットする運用が必要です。

Q2: サブエージェントを複数作ると、AIの回答精度は向上しますか？

向上します。役割を分担させることで、AIが一度に処理すべきコンテキストの範囲を限定できるからです。例えば、執筆担当に「提案禁止」の制約を課し、調査のみに集中させることで、早期の思考収束を防ぎ、より深い洞察を引き出せます。また、各エージェントが独立した定義ファイルを持つことで、特定のタスクに最適化された検索戦略や出力形式を維持しやすくなります。

Q3: 開発者が意識すべき「ノード管理」の具体的なタイミングは？

目安として、1つの具体的な課題が解決したタイミング、あるいは会話のラリーが10回を超えたタイミングで議論を区切るのが有効です。それまでの議論の要約を「前提条件」として次のセッションに引き継ぎ、古いログは参照から外します。これにより、AIが古い試行錯誤の過程（ノイズ）に引きずられるのを防げます。Claude Codeを使っているなら、機能の実装が終わるたびにセッションを終了し、新しいタスクとして再起動するのが、ハルシネーションを抑制する最も効果的な方法です。

まとめ

AI開発のボトルネックは、モデルのパラメータ数ではない。僕たちがAIに提供する「思考の構造」だ。一本道のログに情報を詰め込むのをやめ、サブエージェントで役割を分け、ノード単位で議論を管理する。このAIアーキテクチャ設計へのシフトこそが、ハルシネーションという「魔の森」から抜け出す道だ。Claude Codeを単なるコーディングツールとしてではなく、この構造化を実現するためのオーケストレーション・エンジンとして捉え直してほしい。構造が変われば、AIの思考は深く、正確になる。

👉 ThreadPostでSNS運用を自動化する