Claude CodeでAIの迎合を抑える4つのプロンプト

Claude CodeにおけるAIの迎合とは？#

心理学では、ずっと前からこの現象を指す言葉があります。迎合です。会話を続けるために、相手が聞きたいことを言うお世辞屋のようなものです。大規模言語モデルの登場とともに、この言葉はAI研究にも取り入れられ、Anthropicはある公式分析で、モデルがすぐに同意するために正確さをしばしば犠牲にすると率直に認めました。

コーディングでは、次のような形で現れます。Claude Codeにこう書きます。「authMiddlewareのこのエラーを直して。マジックリンクが動かなくなった。」迎合するモデルは確認質問をしません。ログを求めません。使っているライブラリのバージョンも尋ねません。すぐに解決策を提示します。役立つ答えを素早く出すよう訓練されているからです。そして、その解決策は正しそうに見えるでしょう。インポート、エラー処理、コメント。しかし、それは誰か別の人の問題に対する解決策で、Claudeが断片から組み立てた文脈をもとに作り上げたものです。

原因はClaudeではありません。依頼の書き方です。「どう直せばいい？」と尋ねた時点で、すでに修正可能だと決めつけています。迎合するモデルはその前提に乗り、「修正策」を出します。たとえ実際の問題がアーキテクチャやライブラリのバージョンにある場合や、説明した症状がまったく別の根本エラーの結果にすぎない場合でもです。

迎合を招く依頼かどうかを見分ける簡単なテストがあります。「何が具体的に壊れているのか」という質問に3文で答えられないなら、まだ解決に取りかかる準備ができていません。必要なのは診断です。修正はその次です。4ステップのサイクルは、まさにそこから始まります。

ケーススタディ：1時間で8コミットを取り消した話#

2026年4月の具体例です。src/lib/auth/でマジックリンク認証に取り組んでいました。症状は、トークンは検証されるのにセッションが保存されないことでした。ユーザーはメールのリンクをクリックしてサイトに移動しますが、5秒後に/loginへ戻されます。

Claude Codeを開いて、こう入力しました。「マジックリンクの後にセッションが保存されない。src/lib/auth/を調べて直して。」Claudeは3つの確認質問をしてから、すぐに計画を提示しました。「コールバックハンドラーを更新し、JWTシリアライザーを書き換え、Redisへの明示的な保存を追加して、ミドルウェアの競合状態を修正します。」もっともらしく聞こえました。私は計画を承認しました。

18分後、14個のファイルにまたがる差分ができていました。マジックリンクはまだ動きません。それどころか、リフレッシュトークンも動かず、パスワードログインも壊れ、決済ルートには奇妙な500エラーが出ていました。テストも失敗していました。私は変更を戻し始めました。

git reset --hard origin/mainで8コミットを取り消しました。1時間の作業が無駄になりました。役立つものを失わずに正しくロールバックする方法を知りたい方のために、Claude Codeで変更を取り消すガイドで別途説明しています。

私は腰を据えて、きちんと調べました。src/lib/auth/magic-link.ts:42を開いて自分で読み、ログを開き、Redisを確認しました。20分後に原因が分かりました。問題は1行でした。set-cookieヘッダーにSameSite=lax属性がなく、SafariがメールのドメインからサイトへリダイレクトするときにCookieを拒否していたのです。JWTでもRedisでもミドルウェアでもありません。たった1行でした。

Claudeに修正を頼んだとき、ブラウザーのログを見ることはありませんでした。Safariについての文脈もありませんでした。「セッションが保存されない＝シリアライズの問題」というパターンから仮説を組み立てました。それが学習データで最もよくある答えだからです。迎合するモデルは統計的にはもっともらしいものの、私のタスクとは無関係な解決策を出しました。

私はこの教訓をルールとして書き留めました。「どう直せばいい？」とは決して聞かない。常に「事実を確認して」と頼む。あとは、これを実用的なサイクルとして定式化するだけでした。

迎合はどこから来るのか：リリース時のOpus 4.8と2026年5月#

4月にはAnthropicが、Claude Codeのキャッシュバグによってモデルがターン間の推論を「忘れる」仕組みを、エンジニアリングの事後分析で別途調査しました。

モデルが推論の連鎖を忘れると、パターンから答えを「推測」しやすくなります。言い換えれば、さらに迎合的になりやすいのです。

4.8のリリースを踏まえて何をすべきでしょうか。「簡単な」モデルを選んではいけません。4.7に戻ってはいけません。事実に沿うようプロンプトを調整してください。モデルは同意しやすくなっているので、「事実を確認する」ことをより強く求めましょう。Opus 4.8の内部で何が変わったのか、まだ詳しく把握できていない場合は、Claude CodeにおけるOpus 4.8のレビューで詳細に比較しました。

4ステップが必要なとき、時間の無駄になるとき#

具体例です。ウェルカムメールの文面修正なら、直接作業します。サイトに新しいCTAボタンを追加するなら、サイクルなしでPlan Modeを使います。プロジェクトをMySQLからPostgresに移行するなら、4ステップのサイクルが必要です。ローカルで再現できない本番環境の奇妙な500エラーなら、「まず最小再現例を作ろう」という追加の「ゼロ」ステップを加えた4ステップのサイクルが必要です。

サイクルを使うときによくある間違いは、些細なタスクに適用することです。そうすると速度が落ち、すぐにこの方法自体が嫌になります。サイクルが必要なのは、エラーのコストが15分の計画コストを上回る場合です。

サイクルを導入する前に、4つのプロンプトすべてを1回のPlan Modeセッション内で使うことを覚えておいてください。このモードを使ったことがなければ、先にClaude CodeのPlan Modeガイドを読んでから戻ってきてください。

ステップ1. 解決策を禁じ、Claudeに事実を確認させる#

最も重要なステップです。最初の衝動である「解決策はこちらです」をここで止めます。プロンプトは次のとおりです。

次のことが起きました：[症状]。

あなたの今のタスクは、事実を明らかにすることです。
解決策、アイデア、助言は禁止です。次の項目だけを扱ってください。
- 私が観察していること（症状の正確な表現）
- 再現手順（最小限のシナリオ）
- 利用可能なデータ（ログ、バージョン、環境）
- 不足しているデータ（収集が必要なもの）

厳格な停止条件：解決策を提案しないでください。診断の記録だけにしてください。何かを提案したくなったら、代わりに私への質問として書いてください。

この指示の効果です。解決策を明示的に禁じると、Claudeは近道ができません。4つの項目を埋める必要があります。何が見えているか、どう再現するか、何が分かっていて、何が分かっていないかです。最後の項目が最も重要です。たとえば「ライブラリのバージョン、ログの内容、症状が本番環境でも起きるかが分からない」と判明することがあります。これが次のステップへの手がかりです。

ステップ1の落とし穴です。症状の表現があいまいすぎると（「認証が動かない」など）、Claudeは推測に走ることがあります。対策はプロンプト自体にあります。症状を正確に1文で説明し、最小限の3ステップのシナリオを示してください。それができないなら、何が具体的に壊れているかをまだ理解していないということです。その場合、Claudeの回答はどうせ役に立ちません。

ステップ2. 記憶の幻覚ではなく、インターネット上の前例を探す#

2番目の衝動である「記憶から解決策をでっち上げる」を抑えます。プロンプトは次のとおりです。

診断が確定したので、インターネット上で
同様の問題を解決した事例を探してください。

異なるアプローチを少なくとも3つ。それぞれについて：
- 一次情報へのリンク（issue、記事、ドキュメント）
- アプローチの簡潔な説明
- 私たちの状況における長所と短所
- 既知の落とし穴

リンクで確認できない、あなた自身の知識に基づく情報は禁止です。前例が見つからない場合は、そう明記してください。

実際の効果です。Claudeは外部情報を調べ、検証可能なアプローチを持ち帰ります。GitHubのissueやドキュメントへのリンクが示されます。前例を見つけられない場合は、そのタスクが特殊であるか、症状の説明が間違っているという合図です。ステップ1に戻ってください。

うまくいかない場合もあります。Claudeが存在しないリンクを引用することがあります。「リポジトリXのissue番号4291はこちらです」と言いながら、実際のissue 4291は別の内容を扱っている、といった幻覚です。CLAUDE.mdに「引用する前に、必ずWebFetchでリンクを開く」という明示的なルールを追加して対処します。詳しくはCLAUDE.mdを適切に設定するガイドを参照してください。

ステップ3. リスクを先読みした詳細な計画をplans/に書く#

ここでPlan Modeが本来の役割を果たします。プロンプトは次のとおりです。

ステップ2から最善の選択肢を採用し、次のファイルに
詳細な計画を書いてください：plans/YYYY-MM-DD-fix-[name].md

- 変更する具体的なファイル（完全なパスと行番号）
- 追加するものと削除するもの
- 作成するテストと、通過させる必要がある既存テスト
- 2〜3ステップ先を見越したリスク（ユーザーに何が起きる可能性があるか）
- 問題が起きた場合のロールバック計画

各ステップをチェックボックス [ ] にしてください。ファイルは画面1枚に収まる長さにしてください。
計画が200行を超える場合は、フェーズに分割してください。

結果として、計画はチャットの一時的なメモではなく成果物になります。2週間後に読み返したり、別のエージェントに渡したり、/goalコマンドの条件として使ったりできます。Claude Codeの会話より長く残る計画ファイルになります。

重要なのは、2〜3ステップ先を見越したリスクです。これによって、影響を考えない楽観的な計画という、もう1つの迎合パターンを抑えます。Claudeにリスクを明示させると、通常の計画なら黙って見過ごしていたことを見つけます。

ステップ4. 計画をセルフチェックし、迎合的な思い込みを見つける#

最後のフィルターです。プロンプトは次のとおりです。

今すぐ必須のセルフチェックを行ってください。計画を正直に読み直してください。

計画の中に、次の情報で確認していないにもかかわらず、根拠なく書いた箇所はありますか？
- あなたが読んだコード
- ステップ2で引用したドキュメント
- ステップ2の前例

該当する箇所があれば、明示して、修正するか削除してください。

さらに、次の点も確認してください。
- まだインストールされていない、package.jsonにないライブラリに言及していないか
- 私が指定していない環境変数に言及していないか
- 計画のステップが具体的ではなく、一般論で書かれていないか

この指示の効果です。Claudeは自分の推論を再確認しなければなりません。著者が約50回のサイクルで試したところ、少なくとも2〜3個の計画項目がステップ4で修正されました。ステップ3ですり抜けようとした迎合モデルの思い込みを、ステップ4で見つけられるのです。

4つのステップを終えると、計画は承認できる状態になります。「8コミットをロールバックすることになったらどうしよう」と心配せずに、実装へ進めます。

なぜ2ステップでも7ステップでもなく、4ステップなのか？#

Anthropicが公式ドキュメントでClaudeを導くために使っている手法に沿って、理由を説明します。

ドキュメントでは、Explore、Plan、Implement、Commitの4段階のワークフローが推奨されています。

私の4ステップのサイクルは、迎合を抑えるためにPlanフェーズを特化させたものです。Anthropicの4つのフェーズのうち、1つを4つのマイクロステップに拡張します。解決策を禁じ、前例を探し、計画を書き、セルフチェックするのです。こうして詳細な計画を作り、その後のImplementとCommitのフェーズに引き継ぎます。

4つのステップのどれかを省くと何が起きるか、見てみましょう。

表から明らかなように、各ステップはそれぞれ異なる種類のエラーを防ぎます。ステップごとに異なるカテゴリーを見つけるため、4つすべてが必要です。2つで十分に思えるほど小さなタスクなら、本当に小さいタスクです。その場合、Plan Mode自体が不要です。

plans/、/goalコマンド、次のステップの関係#

このサイクルは、次の要素を備えたシステムの中で機能します。

1. Plan Modeが有効になっている（Claude CodeでShift+Tabを2回押す）。
2. 計画を保存するためのplans/フォルダーがリポジトリ内にある。
3. 長い計画を自律的に実行するための/goalコマンドを必要に応じて使う。

plans/フォルダーについて。ステップ3の後に、フェーズとチェックボックスを含むplans/2026-05-27-fix-magic-link.mdファイルができます。これは成果物です。1週間後に開けば、そのアプローチを選んだ理由を思い出せます。3か月後には似たタスクを見つけて再利用できます。6か月後には同僚に見せ、仕事に慣れるための2週間を節約してあげられます。plans/フォルダーは、Claude Codeにおける「セカンドブレイン」という考え方の一部です。

/goalについて。4つのステップを完了し、計画を承認したら、Plan Modeを終了して次を入力します。

/goal plans/2026-05-27-fix-magic-link.md にある全フェーズを実行し、test/auth 内のすべてのテストが通るまで進める。通算30ターンで停止する

ローカルのClaude Codeでは、ターミナルを動かし、パソコンを起きた状態で通信できるように保ちます。対応するスリープ防止環境を明示的に整えていない限り、ふたを閉じないでください。戻ったら履歴を確認します。完了、ターン上限、権限確認待ち、エラーのいずれもありえます。goalはホストのスリープ中の進捗を保証しません。4ステップのサイクルがなければ、/goalは無駄な反復にトークンを消費します。サイクルがあれば、完成した計画をテスト合格まで進めます。

ここから何をするか。Claude Codeを使い始めたばかりなら、次の難易度の高いタスクでこのサイクルを試してください。タイプミスではなく、3個以上のファイルに触れるタスクや、挙動をよく理解していないタスクです。上記のプロンプトをコピーし、自分の詳細を入れてください。ロールバック率がどう変わるかが分かるでしょう。

すでにPlan Modeを使っているなら、リポジトリにplans/フォルダーを追加してください。YYYY-MM-DD-feature-name.mdというファイル名の形式を決めます。1か月で20〜30個、6か月で100個以上のファイルがたまります。こうしてプロジェクトのセカンドブレイン、つまり意思決定の生きた履歴が作られます。プロンプトを書く前のコンテキスト管理をさらに掘り下げたい場合は、Claude Codeにおけるコンテキストエンジニアリングで独立した分野として解説しています。

すでにPlan Modeとplans/の両方を使っているなら、1つの自律タスクで/goalを試してください。普段なら手作業で30〜40分かけるタスクを選びます。4ステップを通して計画を保存し、/goalを開始して、ローカルのターミナルとパソコンを起動状態に保ちます。そのパソコンの電源を切っても続けたいなら、先にリモートかクラウドの実行経路を明示的に設定し、そこで稼働していることを確認してください。