AIに「できません」「それは違います」と言われた時の対処：認識ギャップ解消の5パターン

Claude Code を使っていると、AI から「できません」「それは違います」「その方法は推奨できません」と返されることが定期的にあります。多くの人はここで諦めるか、強引に押し通そうとします。どちらも筋が悪いです。

経験上、これらの返答はエラー（処理できない）ではなく、解釈の相違であることがほとんどです。背景情報の補強・前提の言語化・代替案提示で再構成すると、本来やりたかった作業に戻せます。今後のAI協働で必須になるメタスキルだと感じているので、5つのパターンに整理しました。

なぜ「拒否」を解釈の相違として扱うのか

AIの「できません」は文字通りの不可能ではない

AIが「できません」と返す典型ケースは以下です。

ガードレール（安全性・規約）に触れたと判断した
文脈不足で「何を求められているか」が曖昧と感じた
提示された方法より良い方法を知っていると判断した
過去の学習データから「リスクが高い」と評価した

このうち1番目以外は、こちらの説明を補えば翻意します。AIの「できません」を文字通り「不可能」と受け取ると、可能なはずの作業を諦めることになります。

「強引に押し通す」もダメ

逆に「いや、やってください」と強く出ると、AI は形式的に従いつつ質の低い出力を返してきます。プロンプトインジェクション的な押し方をすると、警戒モードに入って以降のセッションが扱いにくくなることもあります。

中道は、AIの判断根拠を理解した上で、こちらの前提を追加すること。これが一番再現性が高いです。

5つの認識ギャップパターン

パターン1: 安全側に倒した過剰拒否

症状: 普通のリファクタリングや調査依頼に対して「セキュリティ上推奨できません」「破壊的な変更です」と返される。

原因: AIが「破壊的」「削除」「上書き」というキーワードに過敏に反応し、文脈を読まずに警告モードに入る。

対処: 作業の文脈と影響範囲を先に明示します。

1
このコードは個人開発のローカルブランチで、
2
mainにマージする前のドラフト段階です。
3
削除対象のファイルは未追跡で、リモートには
4
存在しません。安全に削除できることを確認した上で、
5
{ファイル名} を削除してください。

「個人開発」「ローカルブランチ」「未追跡」「確認済み」のように、AIが警戒する根拠を1つずつ潰す情報を入れます。

パターン2: 前提が伝わっていない誤解

症状: 依頼通りの実装が返ってこない。AIは「ご要望の通り実装しました」と言うが、出てきたコードが想定と違う。

原因: 自分にとって自明な前提（例: このプロジェクトは Astro / Python 3.12 / pnpm を使っている）を伝えていない。AIは推測で別のスタックを仮定している。

対処: 依頼の前に前提リストを明示します。

1
前提:
2
- フレームワーク: Astro 4 + TailwindCSS
3
- 状態管理: なし（Astro Islandsで部分的に SolidJS）
4
- ビルド: pnpm build
5
- 既存記法: src/content/blog/{slug}.md (frontmatter + Markdown)
6

7
この前提に従って、以下を実装してください。
8
{依頼内容}

CLAUDE.md に書いておけば毎回書く必要はありませんが、CLAUDE.md にない情報（暫定的な制約・実験中のブランチなど）は毎セッション冒頭で宣言します。

パターン3: 「より良い方法」の押し付け

症状: 「もっと良い方法があります」と提案され、本来やりたかった方法に進めない。

原因: AIが過去のベストプラクティスを優先し、今回の特殊事情を無視している。

対処: 「なぜその方法を選んだか」を先に説明します。

1
このAPIエンドポイントは、{特殊事情}のため、
2
標準的な REST 設計ではなく、独自のクエリパラメータ構造を
3
採用しています。背景は以下:
4

5
- 既存クライアント30箇所がこの形式に依存しており、変更不可
6
- マイグレーションコストが効果を上回る試算
7
- 6ヶ月以内に廃止予定で、再設計は無駄になる
8

9
この前提を保ったまま、新規エンドポイントを追加してください。
10
リファクタリング提案は別途検討するので、今回は不要です。

「リファクタリング提案は別途検討する」と明示的に断るのが効きます。AIは「より良い方法」を出すのが仕事だと思っているので、断らないと提案を続けます。

パターン4: 事実誤認による否定

症状: 「その関数は存在しません」「そのライブラリにはその機能はありません」と言われるが、実際には存在する。

原因: AIの学習データが古く、最近追加された機能や、ニッチなライブラリの細部を知らない。

対処: 一次情報を提示します。

1
{ライブラリ名} の最新版（v3.2）には、その機能が
2
追加されています。以下が公式ドキュメントの該当箇所です:
3

4
{公式ドキュメントの URL とコード例}
5

6
この情報を元に、実装を進めてください。
7
不明点があれば質問してください。

可能なら Context7 MCP のような最新ドキュメント参照ツールを併用します。AI に「あなたの記憶より新しい情報がここにある」と示すのが一番確実です。

パターン5: スコープのすれ違い

症状: 小さな修正を依頼したのに、関連箇所まで大規模に書き換えられる。あるいは逆に、依頼した範囲の一部しか触らない。

原因: 「どこまでやるか」のスコープがAIと共有されていない。

対処: スコープを Do / Don’t で明示します。

1
やってほしいこと（Do）:
2
- {ファイル名} の {関数名} のバグ修正
3
- 修正に必要な最小限のテスト追加
4

5
やってほしくないこと（Don't）:
6
- 同ファイル内の他関数のリファクタリング
7
- 命名やフォーマットの改善
8
- 関連ライブラリのバージョンアップ
9
- ドキュメント更新（別タスクで実施）

Don’t を書くのが特に効きます。AI は「気を利かせる」傾向があるので、気を利かせてほしくない範囲を明示しないと、頼んでいない作業まで巻き込まれます。

5パターンを実戦で使うとき

Step 1: AIの返答を「分類」する

AIから否定的な返答が来たら、まず5パターンのどれかを判断します。複数該当する場合もあります（例: スコープのすれ違い + 前提の誤解）。

Step 2: 該当する補強情報を1回で投げる

修正は1回のメッセージで完結させます。何度も小出しにすると、AI が前のメッセージとの整合性を取ろうとして混乱します。

Step 3: 再度否定されたら、技法ではなく別の問題を疑う

補強しても3回拒否されたら、それはこちらの依頼自体が筋が悪い可能性が高いです。例えば「セキュリティ的に本当に問題がある」「設計が無理筋」などです。AIの拒否を「セカンドオピニオン」として受け取り、依頼内容を見直します。

エンジニアにとっての価値

1. 反論する技術はAI上級者の必須スキル

AI が間違えるのを完全に防ぐ方法はありません。間違いを訂正する技術を持っているかが、AI 利用者のレベル差になります。今後さらに多くの場面で AI が判断を返してくるようになると、訂正コストが利用効率に直結します。

2. 「中道」の判断軸が育つ

「AI を信じすぎず、また否定もしすぎない」という中道が身につきます。AI を盲信する人は質の低い出力を放置し、AI を信用しない人は AI の強みを活かせません。根拠を理解して訂正するスキルがあれば、両極端に振れずに済みます。

3. 自分のプロンプトの曖昧さに気づける

AI が拒否や誤解を返したとき、多くの場合は自分のプロンプトが曖昧です。5パターンのどれに該当するかを考える過程で、自分の説明の足りなさが可視化されます。これはチームメンバーへの依頼の仕方にも応用できます。

落とし穴と対処

落とし穴1: AIの拒否を即「バグ」と扱う

「Claude Code が機能しない」と切り捨てる前に、5パターンに当てはまらないか確認します。多くの場合、プロンプト側の問題です。

落とし穴2: 補強情報を出しすぎて文脈を膨らませる

「念のため全部の前提を毎回書く」と、コンテキストウインドウが圧迫されます。依頼に直接関係する前提だけに絞ります。CLAUDE.md に書ける普遍情報と、セッション固有の情報を分けます。

落とし穴3: 「Don’t」を書かずに気を利かせさせる

「気を利かせてほしい」と思って Don’t を省くと、毎回違う範囲が触られて再現性が落ちます。Don’t は明示的に書くのが原則です。

落とし穴4: 拒否の理由を聞かずに押し通す

「なぜ拒否したのか」を聞かずに違うプロンプトを投げると、AIが何に引っかかったかが分からないまま進みます。拒否されたら「なぜ拒否したか教えてください」と1度聞くと、補強すべき情報が分かります。

適用範囲

このスキルが効くシーン：

AI と長時間セッションを回す全ての場面
既存コードベースへの修正依頼
ニッチな技術スタックでの作業
安全側に倒したい変更（破壊的操作・本番環境）
複数の AI ツール（Claude / GPT / Gemini など）を使い分けるとき

まとめ

パターン	症状	対処
1. 過剰拒否	安全側に倒した拒否	文脈と影響範囲を明示
2. 前提誤解	想定と違う実装	前提リストを宣言
3. 押し付け	「より良い方法」提案	採用理由を説明し、他案を断る
4. 事実誤認	存在を否定される	一次情報を提示
5. スコープ違い	やりすぎ / やらなすぎ	Do / Don’t を明示

AI に反論する技術は、これからの全ての AI 利用者に必要なメタスキルです。「AI を信じすぎず、また否定もしすぎない」中道の判断軸が、利用効率を大きく変えます。