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

> Claudeが意図を理解しないままコードを書き始めるため、間違ったものを作ってしまいます。その理由を解説し、まず質問させるためのすぐ使えるプロンプトを3つ紹介します。

Source: https://ailoot.ai/blog/ja/why-claude-does-the-wrong-thing/
Canonical: https://ailoot.ai/blog/ja/why-claude-does-the-wrong-thing/
Language: ja
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-201
Revision: sha256-af7c347cc2e8d1aa432cc1f17d9ac15d921d75d6d121909f996c755486b0273b


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

Claudeが間違ったものを書くのは、すぐにコードに取りかかり、あなたが望んでいると思ったことを補ってしまうからです。多くの場合、その推測は外れます。問題はほとんどの場合、モデルではありません。どれほど強力なモデルでも、曖昧なタスクでは的を外します。これを一手で直します。まずClaudeに私へ質問させ、意図を引き出してから、書き始めさせます。以下に、コピーしてすぐ使えるプロンプトを3つ紹介します。

</div>

サービスの利用方法については、[Ailootのドキュメント](https://ailoot.ai/docs/)をご覧ください。



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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

Claudeは短い依頼を受け取ると、足りない部分をすぐに補い、自分なりに解釈したタスクに基づいてコードを書き始めます。その解釈はあなたの考えとは異なります。その結果、1行の変更を期待していたのに、差分が14ファイルに及ぶことになります。原因は、あなたが言ったことと考えていたことの隔たりです。モデルにはほとんど関係ありません。

</div>

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

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

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

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

<figure>
<blockquote>
<p>Claudeをすぐにコードへ進ませると、間違った問題を解決してしまう可能性があります。</p>
</blockquote>
<figcaption>— Claude Code Docs, https://code.claude.com/docs/en/best-practices</figcaption>
</figure>

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

モデルの重要性は、一般に考えられているほど高くありません。曖昧なタスクでは、最強のモデルでさえ的を外します。同じ不完全な指示を受け取り、同じように空白を独自の推測で埋めるからです。エージェントを適切に管理している開発者は、最上位モデルでも中堅モデルでも同じ結果を得ています。結局のところ、望むものをどれだけ明確に説明できるかがすべてです。ここではモデルの能力は二次的な要素です。

</div>

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

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

グリリングとは、AIに作業を始める前にあなたへインタビューさせることです。共通認識に至るまで、タスクについて詳しく質問させます。目的は、最初のコードを書く前に、コミュニケーションの隔たりを埋めることです。

</div>

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

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

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



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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

Claudeにタスクを短く説明し、作業開始前にあなたへインタビューするよう明示します。詳細、エッジケース、制約について質問し、最後にすべてを仕様ファイルにまとめさせます。これはAnthropicの公式推奨です。Claude Codeのドキュメントには、すぐ使えるプロンプトのテンプレートがあります。説明を変更してコピーし、セッションの最初に貼り付けてください。

</div>

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

<div class="section" data-semantic="prompt" aria-label="プロンプト">

プロンプト

Claudeにインタビューさせるグリリング用プロンプト

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

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

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

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

</div>

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

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

<figure>
<blockquote>
<p>仕様を正しく整えるために費やす時間は、実装を見守る時間より価値があります。</p>
</blockquote>
<figcaption>— Claude Code documentation, https://code.claude.com/docs/en/best-practices</figcaption>
</figure>

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

AIに質問させるだけでなく、その判断を弁護させましょう。私はタスクに要件を追加します。提案した計画が、思いついた最初の案にすぎないのではなく、最善であり、数手先まで考慮されていることを証明させます。これによりClaudeは「似たようなことをやっておく」モードから批評家モードに切り替わり、実装に時間を費やす前に自分の作業を点検します。

</div>

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

<figure>
<blockquote>
<p>結果を確認できないなら、提出してはいけません。</p>
</blockquote>
<figcaption>— Anthropic, Claude Code Docs, https://code.claude.com/docs/en/best-practices</figcaption>
</figure>

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

<div class="section" data-semantic="prompt" aria-label="プロンプト">

プロンプト

AIに計画を弁護させるプロンプト

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

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

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

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

</div>

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

プレモーテムとは、プロジェクトがすでに失敗したと想像して、その理由をAIに挙げさせる手法です。Claudeは楽観的な「やり遂げます」モードから、通常なら1週間作業した後に明らかになる弱点を探すモードに切り替わります。プロジェクトに時間を投じる前にリスクの一覧を得られ、あらかじめ対処できます。

</div>

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

<div class="section" data-semantic="prompt" aria-label="プロンプト">

プロンプト

プレモーテム用プロンプト：始める前に抜け漏れを見つける

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

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

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

</div>

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

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

Claudeには限られたコンテキストウィンドウがあり、一度に保持できる情報量が決まっています。ウィンドウが半分を超えて埋まると、重要な詳細を失い始め、以前の合意を混同し、記憶する代わりに空白を補い始めます。あらゆる話題を扱う長いセッションは、朝に合意した内容とその日の終わりにAIが行うことがまったく違ってしまう、よくある原因です。

</div>

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

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

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

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

グリリングとPlan Modeは、同じ問題の異なる側面を解決します。グリリングは、計画ができる前に質問を通じてあなたの意図を引き出します。Plan Modeは、すでに理解されたタスクを受け取り、変更計画を示します。あなたが承認するまで何にも触れません。両者は組み合わせて使うと最も効果的です。まずグリリングで何を作るかを明確にし、次にPlan Modeで具体的な方法を確認します。

</div>

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

| 機能 | グリリング | Plan Mode |
|----|----|----|
| 行うタイミング | 計画の前。意図を明確にする | その後。変更計画を作る |
| 誰が誰に質問するか | AIがあなたにインタビューする | あなたが計画を読んで承認する |
| 得られるもの | タスクの仕様 | ファイルごとの変更計画 |
| 主な利点 | 「それは望んでいたものではない」を防ぐ | 「ほかには触らないで」を防ぐ |

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

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

<figure>
<blockquote>
<p>変更を1文で説明できるなら、計画は省略してください。</p>
</blockquote>
<figcaption>— Official Claude Code documentation, https://code.claude.com/docs/en/best-practices</figcaption>
</figure>

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

AIが期待を外す原因は、ほぼすべて5つのタスク設定ミスに集約できます。曖昧な一言だけの依頼、制約の欠如、「まず理解する」段階を設けずに「コードを書いて」と頼むこと、「完了」の定義がないこと、そして何でも1つの長いセッションで済ませることです。どれもClaudeに推測でタスクを補わせます。それぞれの例と、置き換え方を紹介します。

</div>

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

| ミス | 依頼の例 | 代わりにすること |
|----|----|----|
| 曖昧な一言だけの依頼 | 「ダッシュボードを改善して」 | タスクを説明してグリリングを始め、AIの質問で詳細を引き出す |
| 制約がない | 「認証を追加して」 | 壊してはいけないもの、導入してはいけないライブラリ、対象範囲外のものを伝える |
| すぐに「コードを書いて」と頼む | プロンプトを出して、すぐコーディングを始める | まず「理解して質問する」、それからコードを書く |
| 「完了」の定義がない | AIに結果を推測させる | 「動作する」とはどういう意味か、例、参考スクリーンショット、テストで示す |
| 何でも1つのセッションで進める | 1日中1つのチャットを使う | タスクごとに新しいチャットを1つ使い、コンテキストを散らかさない |

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="重要なポイント">

重要なポイント

個別のプロンプトは個別のタスクを解決します。毎回長く説明しなくてもAIに理解してもらうには、仕組みが必要です。グリリングは各タスクの意図を引き出し、セカンドブレインはプロジェクト知識を保存し、コンテキストエンジニアリングはClaudeがプロンプトの前に読むすべてをつなぎます。そうすれば、間違ったものを作る原因がなくなります。推測を避けるのに十分なコンテキストが、常に与えられるからです。

</div>

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

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

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

<div class="section" role="doc-bibliography" aria-label="出典">

### 出典

- [Claude Code Docs - Best Practices (Let Claude interview you, plan mode)](https://code.claude.com/docs/en/best-practices)
- [Anthropic - 2026 Agentic Coding Trends Report](https://resources.anthropic.com/2026-agentic-coding-trends-report)

</div>





[Ailoot](https://ailoot.ai/)について知る。

## Claudeが間違ったものを作る理由：3つのプロンプト：よくある質問

### すぐ実装する代わりに、質問形式のプロンプトを使うのはいつですか？

成果、例外条件、制約が不明確で、誤りの影響が大きい場合です。1つずつ質問し、合意した内容をSPEC.mdへ保存します。誤字や明確な1行の変更なら、直接依頼できます。

### 提案された計画を承認する前に、何を確認しますか？

2〜3案を求め、それぞれが仕様と制約をどう満たすか比較します。次に事前検死のプロンプトで失敗理由を確認し、関係するリスクへ対処してから実装してください。


## Ailoot · 企業とそのプロジェクト群

Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。

企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。

Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。
