Claudeが間違ったものを作る理由：3つのプロンプト

サービスの利用方法については、Ailootのドキュメントをご覧ください。

Claudeはなぜ間違ったものを作るのか？#

あなたは「製品ページにフィルターを追加して」と書きます。あなたの頭の中では、チェックボックスをいくつか置いてリストを更新するという意味です。同じ依頼を受けたClaudeは、本格的なフィルタリングエンジンを作ろうとします。独自の状態ストア、独立した入力遅延ロジック、URLとの同期、そして十数個のヘルパー関数です。URLパラメーターをいくつか使えば済んだところに、何百行ものコードが生まれます。

このような場合、結論は明らかです。エージェントが間違えたのではなく、必要以上に大きな問題を解いたのです。望む結果を簡潔かつ正確に説明できていなかったことが問題でした。

鍵となる言葉は「意図」です。あなたの頭の中にはありますが、Claudeにはありません。Claudeが見ているのは、依頼の文章と、その依頼までのコンテキストすべてです。そして、空白を推測で埋めます。依頼が短いほど推測が増え、結果はあなたの望みから遠ざかります。

AnthropicはClaude Codeのドキュメントで、はっきりこう述べています。

私自身のプロジェクトでも経験しました。認証画面を1つ修正してほしいと頼んだところ、隣接するモジュールの半分に影響する差分ができました。Claudeのせいではありません。私が1行の依頼を出し、残りをClaudeが自分で補ったのです。それ以来、誤字修正より大きなタスクでは、まず質問から始めます。Claudeが私に質問するのです。

本当にモデルの問題なのか？最強のモデルでさえなぜ外すのか？#

毎週のように、前より「賢い」モデルが登場します。そしてそのたびに、ついにAIがわずかな言葉から私たちを理解する時が来た、と感じます。しかし、そうはなりません。より強力なモデルはコードを速く書き、複雑なロジックをよりうまく扱えますが、それでもあなたの心は読めません。タスクの枠組みが曖昧なら、見事に書かれていても間違ったものが返ってきます。

ここから得られる教訓は簡単です。AIがよりうまく推測できるように最新モデルを追いかけても、行き止まりです。推測しなくて済むようにタスクを与える方法を学ぶほうが、安くて確実です。次にその方法を見ていきます。

グリリングとは？AIとの認識のずれをどう解消するのか？#

直感に反するように聞こえるかもしれません。私たちは作業を速く進めるためにAIを使うのに、今度はペースを落として、先に質問させるようにと言われています。しかし、コードを書く前の5分間の質問で、その後の1時間の修正を省けることがあります。

問題は、Claudeにうまく説明できなかったことだけではありません。多くの場合、あなた自身もタスクを十分に考えられていません。どのケースを考慮するのか、境界はどこか、何が最も重要なのか。グリリングは質問を通じて、こうした点を引き出します。会話が終わる頃には、AIが理解できるタスクだけでなく、あなた自身のタスクも、ようやく詳細に言葉になっています。

これがコンテキストエンジニアリングの仕組みです。主な作業はプロンプトの最中ではなく、その前に行われます。魔法のようなプロンプト文を探すのではありません。余計な説明なしに理解できるまで、Claudeに必要なことを事前に整理するのです。

Claudeに先に質問させるには？#

Anthropicはこの方法を認めているだけでなく、推奨しています。ドキュメントには「Claudeにインタビューさせる」というセクションがあり、すぐ使えるプロンプトも掲載されています。実用的なバージョンを紹介します。

[タスクの簡単な説明]を作りたいです。

コードを書く前に、詳しく私にインタビューしてください。実装、インターフェース、エッジケース、リスク、トレードオフについて質問してください。明らかな質問は避け、私が考え抜けていないかもしれない難しい部分を掘り下げてください。

一度に1つずつ質問し、私の回答を待ってください。質問ごとに、推奨する回答もすぐに提案してください。

すべてを網羅するまで続けてください。その後、SPEC.mdというファイルに完全な仕様をまとめてください。

このプロンプトを単なる飾りではなく、役立つものにするポイントは3つあります。第一に、「一度に1つずつ質問する」ことです。AIが10個の質問をまとめて投げると、圧倒されて表面的に答えてしまいます。第二に、「答えを提案する」ことです。すべてを一から考える必要はなく、同意するか、訂正すれば済みます。第三に、「仕様をファイルにまとめる」ことです。引き出された意図が文書になり、失われずに残ります。

Anthropicは、努力に対する成果を次のように説明しています。

インタビューの後、新しいセッションを開き、完成した仕様を渡してください。整理されたコンテキストと明確な意図があれば、Claudeは最初から的を射た結果を返します。

「これが最善の計画だと証明して」という手法#

グリリングはあなたの意図を引き出します。しかしAIにはもう1つ癖があります。もっともらしい最初の解決策に飛びつくことです。Anthropicはこれを「信頼するが検証する」という隔たりと呼びます。Claudeは、エッジケースで通用しない、もっともらしい実装を生成します。対策は、コードを書く前に根拠を求めることです。

私はほとんどの場合、プロンプトに「証明して」セクションを追加します。実際に使っている文面を紹介します。

コードを書く前に、批評家のようにタスクを分析してください。

解決方法を2-3通り考えてください。それぞれについて、独自の複雑さを加えているだけでなく、本当に私のタスクを解決することを証明してください。コードを書くこと自体を目的に、コードを書いてはいけません。

その後、1つを選び、それが最善の解決策であり、数手先まで考慮されていることを証明してください。プロジェクトの成長に伴い何が壊れますか？今、何を見落としていますか？

その後で初めて、実装を提案してください。

このセクションがなければ、Claudeは最初に見つけた実用的な案を提示します。あれば、Claude自身が行き止まりを除外し、選択理由を説明し、ファイルに一切触れる前に推論を確認できます。完成したコードが期待どおり動かない理由を1時間かけて調べる代わりに、2分で読める短い文章を確認すれば済みます。

プレモーテム：始める前に、AIに失敗の理由を10個探させる#

これは私のお気に入りの手法で、心理的なものです。AIに「うまくやって」と頼むと、成功する方向に意識が向き、穴を見過ごしがちです。失敗を想像するよう頼めば、以前は見落としていたことに気づき始めます。プロンプトは短いものです。

今から1年後を想像してください。私たちが計画しているプロジェクトは失敗しました。

失敗した理由を10個書き出してください。最初に考慮できなかったこと、過小評価したこと、手を抜いた箇所、誤りだと分かった前提は何ですか？

次に、それぞれの理由について、対処するために今すぐ修正できることを教えてください。

私は計画を承認する前に、このプロンプトを使います。挙がる理由の半分は見当違いですが、残り半分は、1週間後に直面していたはずの本当の落とし穴です。計画段階で対処すれば10分で済みます。完成したプロジェクトで遭遇すれば、調査に数日かかります。

組み合わせは簡単です。グリリングで意図を引き出し、「証明して」で判断を弁護させ、プレモーテムで抜け漏れを見つけます。コードを書く前に貼り付ける、3つの短い文章です。Claudeを、急いで作業する実行役から、まず考える協力者へと変えます。

コンテキストが詰まりすぎるとClaudeが馬鹿になるのはなぜ？#

タスクの枠組みを完璧に整えても、散らかったコンテキストで作業すれば崩れてしまいます。仕組みはこうです。新しい依頼をするたびに、チャットの履歴全体がClaudeの作業コンテキストに入ります。セッションが長いほど、ウィンドウは早く埋まります。半分以下に保ってください。それを超えると、AIは馬鹿になったように振る舞い、最初に話し合った重要なことを失い始めます。

私の苛立ちを最も減らしてくれるルールはこれです。1つのタスクにつき、チャットは1つ。関数が完成したらチャットを閉じ、次のタスク用に新しく開きます。すべてを1つのウィンドウで済ませるほうが便利な時もありますが、コンテキストを失い、的外れな回答が返ってくることになります。

Anthropicはこの失敗モードを「がらくた入れセッション」と呼んでいます。対策は簡単です。関係のないタスクの間に/clearを使ってウィンドウをクリアし、前のタスクの雑多な情報を新しいタスクに持ち込まないようにします。

長時間のセッションを使っていて、お金やAIの注意力がどこへ向かっているのか分からない場合は、Claude Codeのトークンの行き先のガイドで別途説明しています。また、Claudeが起動のたびに読む永続的なコンテキストの基本は、CLAUDE.mdの設定のガイドにまとめました。

グリリングとPlan Modeはどう違い、どう組み合わせるのか？#

この2つの手法はよく混同され、どちらか一方だけでよいと思われがちです。実際には、作業工程の異なる段階に位置しています。

Anthropicは、標準的な4段階のワークフローを説明しています。最初にExplore（Claudeが調査して質問する）、次にPlan（変更を加えずに計画を作る）、続いてImplement（計画に沿ってコードを書く）、最後にCommit（結果を記録する）です。グリリングは第1段階、Plan Modeは第2段階で行います。第2段階の詳細は、Claude CodeのPlan Modeのガイドをご覧ください。

Anthropic自身による重要な注意点があります。小さなタスクにこの方法を使って負担をかけないでください。

誤字修正、名前の変更、1行の変更なら、インタビューや計画をせず、そのまま依頼してください。グリリングが役立つのは、曖昧さがあり、間違えた場合のコストが高いタスクです。些細なタスクに使うと、進行を遅らせるだけです。

AIが間違ったものを作る原因となる、タスクの枠組み設定での5つのミス#

よくある落とし穴を表にまとめました。左側は多くの人が行い、うまくいかないこと。右側は代わりに行うことです。

AIが間違った回答をした直近のプロンプトを見直してください。おそらく、この5つのうちどれかが原因です。最も多いのは最初のミスです。短いひと言を渡し、Claudeが残りを正しく補うと期待したのです。Claudeは確かに残りを補いました。ただし、あなたが考えていた方法ではありませんでした。

次にすること：短い言葉でAIに理解してもらう仕組みを作る#

このガイドで紹介した3つのプロンプト、グリリング、「証明して」、プレモーテムは、目の前のタスクに対応します。それだけでも大きな効果があります。1行の変更だけを望んでいたのに、14ファイルの差分が返ってくることはなくなります。

しかし、グリリングにも限界があります。毎回ゼロから意図を引き出すには時間がかかります。本当の変化は、コンテキストが常に用意されているときに訪れます。プロジェクト知識をまとめたフォルダー、起動のたびにClaudeが読むCLAUDE.mdファイル、スキルに記述したあなたの方法論です。そうすればAIは、あなたの事業、目標、スタイルをすでに把握した状態でタスクに取りかかります。コンテキストの半分をあらかじめ整理しておいたため、短い言葉でも理解できるのです。

Anthropicの最近の分析によると、開発者は仕事の約60%でAIを使っていますが、完全に信頼できるタスクはわずか0-20%です。残りには、あなた自身の理解、監督、そして何を作るべきか説明する能力が必要です。伸ばす価値があるのはそのスキルであり、最も賢いモデルを追いかけることではありません。

Ailootについて知る。