この記事の目次
なぜ同じClaude Codeでも、人によって結果が変わるのか？
結論から言うと、成果の差を生んでいるのはツールの選び方ではなく、指示（プロンプト）の中身の質だ。
Claude Codeは、ターミナル上で動くAIコーディングエージェントで、こちらが自然文で出した指示に沿ってファイルの編集やコマンド実行までを行う。何をどう伝えるかがそのまま作業の質に直結する。ツールそのものの成り立ちはClaude Codeとは何かを解説した記事に譲り、ここでは指示の中身だけを扱う。
結果を左右しているのはツールではなく指示の質
企業向けの研修や個別支援の現場では、Codex か Claude Code かといったツール選びにこだわることが成果にほとんど影響しないと判断している。どちらのツールでも、指示の粗さがそのまま出力の粗さに跳ね返る点は変わらないためだ。
「どのツールを使うか」で悩む時間があるなら、その時間を「何をどう伝えるか」に振り向けたほうが結果に直結する。
「テクニック不足」より「指示の粗さ」が原因になっている実例
複数店舗の美容サロンを経営する非エンジニアの経営者を支援した際、本人が最も印象に残ったと語ったのは高度なテクニックではなく、指示の基礎だった。「大雑把な指示では通らない」「画像は画像だけで送る」という当たり前に見える点が、実は最初のつまずきどころになっていた。
この経営者は支援前、「AIが何でもしてくれる」という前提を持っていたという。テクニックを学ぶ前に、まずこの前提のずれを直すことが近道になる。
効くプロンプトは4つの要素で組み立てる－背景・タスク・出力形式・ルール
背景・タスク・出力形式・ルール。この4つを漏らさず伝えることが、効くプロンプトの土台になる。
どれか1つが欠けても、Claude Codeは欠けた部分を推測で埋めようとする。推測が外れたときに「思っていたのと違う」結果が返ってくる。
背景・役割を伝える
なぜその作業が必要なのか、どんなファイルやシステムを対象にしているのかという背景を先に伝える。「このプロジェクトはNext.jsで書かれたブログで、記事はMarkdownファイルとして管理している」のような一文があるだけで、以降の推測の精度が変わる。
タスクを1つに絞る
「バグを直しつつ、ついでにコードも整理して」のように複数の目的を1つの指示に詰め込むと、どちらも中途半端になりやすい。1回の指示は1つの目的に絞り、別の目的は別の指示として出す。
出力形式を先に決める
差分だけを見たいのか、説明文も欲しいのか、ファイルを直接書き換えてよいのかを先に指定する。「変更前に diff だけ見せてほしい」と一言添えるだけで、後戻りの手間が減る。
守るべきルール・制約を書く
「テストコードは変更しない」「既存のAPIの形は変えない」といった制約は、書かなければ守られない前提で扱う。Claude Codeは制約が明示されない限り、それを破らずにいてくれるとは限らない。
ゴールを決めずに作り始めると何が起きるか
思いつくままに機能やツールを作らせる進め方は、最終的に使われないものが残る結果になりがちだ。個人が試しながら学ぶ段階では一度通る道だが、法人の業務時間でこれを繰り返すと、無駄なやり取りだけが積み上がる。
作り始める前に「これは何のために作るのか」「完成したらどう使うのか」を一言でも書いておくと、途中の判断の軸がぶれずに済む。
Plan Modeに渡す指示と実装指示は分けて書く
Plan Modeは、コードを書かずに実装方針を固める段階だ。機能としての使い方はClaude Codeの使い方ガイドで扱っているので、ここでは渡す指示の中身だけを見る。Plan Modeでは「何を実現したいか」「現状はどうなっているか」「何を変えてはいけないか」「何をもって完了とするか」を渡す。変数名や関数の分け方まで先に決めると、コードを調べてから選ぶ余地を狭めてしまう。
計画が承認された後の実装指示では、対象ファイル、実施する変更、実行するテスト、変更禁止の範囲を具体化する。つまり、Plan Modeでは判断に必要な条件を渡し、実装段階では承認済みの判断を作業単位へ落とす。両方に同じ曖昧な一文を渡すと、計画はできても実装の境界が定まらない。
たとえば計画時は「既存のログイン仕様を保ったまま、認証エラーの原因と影響範囲、検証方法を整理して」と頼む。実装時は「承認済みの方針に沿って対象の2ファイルだけを修正し、認証テストを実行して結果を報告して」と書く。目的と制約は引き継ぎ、指示の粒度を切り替えるのが要点だ。
良い指示と悪い指示の違いは、Before/Afterで比較すると見えてくる
違いを生んでいるのは才能でも経験でもなく、4要素のうちどれが省略されているかだ。
以下は自作したテンプレートで、実際の案件そのものではなく、よくあるやり取りを想定して作成したものである。
Before/After実例1：バグ修正を頼むとき
Before（悪い指示文）
ログイン画面のバグを直してAfter（良い指示文）
背景: /src/pages/login.tsx のログインフォームで、
メールアドレスの形式が正しいのにエラーになる不具合がある。
タスク: 原因を調査し、修正案を提示してほしい。
まだファイルは書き換えずに、原因と修正方針だけ教えてほしい。
出力形式: 原因の箇所（ファイル名と行番号）と、修正案のdiffを
コードブロックで示してほしい。
ルール: バリデーション用のライブラリは変更しない。Beforeは背景・出力形式・ルールがすべて省略されている。「直して」という一語だけでは、どのファイルか、どこまで自動で変更してよいかが伝わらない。Afterでは4要素をひとつずつ埋めることで、いきなりファイルを書き換えられる不安をなくしつつ、必要な情報だけを引き出せる。
すぐ使える短いテンプレ：機能追加を頼むとき
背景: [対象の画面・機能の名前と、現状の挙動]
タスク: [追加したい機能を1つだけ]
出力形式: [まず設計案のみ提示／実装まで進めてよい、のどちらか]
ルール: [触ってほしくないファイルや、変えたくない仕様]すぐ使える短いテンプレ：リファクタを頼むとき
背景: [対象ファイルと、読みにくい・保守しにくいと感じる箇所]
タスク: 挙動を変えずに構造だけを整理してほしい
出力形式: 変更前後のdiffと、変更理由の簡単な説明
ルール: 外部から呼び出しているAPIの名前・引数は変えないすぐ使える短いテンプレ：バグ調査だけを頼むとき（修正はまださせない）
背景: [発生している現象と、再現手順]
タスク: 原因を調査してほしい。修正はまだしなくてよい
出力形式: 原因箇所と、考えられる原因を箇条書きで
ルール: ファイルの変更は行わない調査と修正を分けて頼むと、意図しない書き換えを未然に防げる。特に本番環境に近いコードでは、この一段階を挟む価値が大きい。
既存コードベースや本番運用では「してはいけないこと」を先に書く
4要素の「ルール」は、既存コードベースでは重みが変わる。新規の試作なら壊しても書き直せばよいが、既存コードには守るべき挙動と、積み上がった観測の履歴がある。ここでの制約は品質を上げるための補助ではなく、戻せない変更を防ぐ本体になる。
このブログの自動生成でも、自由な文章生成に任せず、制約をプロンプトへ配線している。記事に書ける実績数値は一次事実台帳にあるものだけに限定し、台帳の各項目には引用できる記事数の上限を設けた。公開後28日未満の記事には、インデックス診断以外の打ち手を適用しない「観察ゲート」も持たせている。これらを構成・執筆・改稿レビュー・改稿・最終ゲートの各プロンプトと公開前の検査につなぎ、途中の判断で制約が抜けないようにしている。
本番向けの指示でも同じで、変わるのは書く順番だ。「このファイルを変える」より先に「この範囲の履歴は書き換えない」を書く。してよいことより、してはいけないことを先に定義すると、作業の境界がこちらの言葉で確定する。
非エンジニアが最初に書くべきは「修正」ではなく「説明」のプロンプト
コードを変更させるのではなく、現状を説明させる。非エンジニアにとって、これが最も安全な入り口になる。
いきなり修正や実装を頼むと、うまくいかなかったときに何が原因かを切り分けられない。まず「読ませる」「説明させる」段階を挟むことで、Claude Codeがどう動くかの感覚がつかめる。
まず「読むだけ・説明させるだけ」の指示から始める理由
ファイルを書き換えさせる前に、現状を言葉にしてもらう。この段階では失敗しても実害がないため、指示の出し方を安全に試せる。
最初の一歩になるプロンプト例（コードを触らせる前に現状を説明させる）
このプロジェクトの構成を教えてほしい。
どんなファイルがあり、それぞれ何をしているのか、
非エンジニアにも分かる言葉で説明してほしい。
まだ何も変更しないでほしい。このような一文から始めると、対象のプロジェクトに対する解像度が上がり、次に出す指示の背景説明が具体的になる。
慣れるまでの2〜3ステップの進め方
- 現状を説明させる（変更なし）
- 小さな調査・小さな修正を1つだけ頼む
- 4要素を意識した指示で、少し大きめの作業を頼む
いきなり3から始めず、1と2で「指示した内容と返ってきた結果が一致する」感覚を掴んでから進むほうが、途中で迷わずに済む。非エンジニアが具体的にどこでつまずくかはClaude Codeで非エンジニアがつまずきやすいポイントでも扱っている。
XMLタグや役割設定、Few-shotはどこまで必要か？
先に断っておくと、XMLタグや役割設定、Few-shotはあくまで補助的な手段だ。4要素の型ができていることが前提になる。
これらは「上乗せ」の技法であって、基礎の代わりにはならない。
XMLタグは効果があるがオプション機能
<background>や<task>のようなタグで指示を区切ると、長い指示文でも要素の境界がはっきりし、意図が伝わりやすくなる。ただし短い指示や、シンプルな依頼にまでタグを使う必要はない。
役割設定・Few-shotが効くケース、効かないケース
「あなたはシニアエンジニアとして」といった役割設定や、良い出力例を先に見せるFew-shotは、出力の文体や粒度を揃えたいときに効果がある。一方で、原因調査のように答えが一意に決まる作業では、役割設定よりも背景情報の正確さのほうが結果を左右する。
Chain of Thought指示はClaude Codeでは前提が違う
Chain of Thought（段階的に考えさせる指示）は、対話型のチャットでは有効な技法として知られている。ただしClaude Codeは、ファイルを読む・検索する・コマンドを実行するといった行動を挟みながら段階的に進める設計になっているため、「順番に考えて」と改めて指示しなくても、実質的に近い動きになっている場面が多い。
拡張思考（think/ultrathinkなど）は、難しい判断のときだけ使う
拡張思考は「深く考えてほしい難所」でこそ効く機能で、万能の底上げボタンではない。
Claude Codeでは、指示文に「think」「think harder」「ultrathink」のような言葉を含めることで、より多くの思考の時間を割り当てる仕組みが公開されている。ただし、それぞれの言葉が具体的にどれだけの思考量に対応するかという詳細な仕様は、この記事の執筆時点で細かく公開されているわけではない。正確な挙動を知りたい場合は、Anthropicの公式ドキュメントで最新の説明を確認するのが確実である。
think/think harder/ultrathinkは何を変えているのか（公式情報で確認できる範囲に限定）
段階が上がるほど、より多くの選択肢を検討してから答えを出す方向に働くとされている。設計判断や、複数のファイルにまたがる影響を見極めたいときに向いている。
使うべき場面と、使うと逆に非効率な場面
タイプミスの修正や、1行だけの単純な変更にまで拡張思考を使うと、応答が返るまでの時間が延びるだけで得られるものが少ない。設計の方針を決める、複雑なバグの原因を特定する、といった場面に絞って使うと、得られるものが大きくなる。
チャット版Claudeと Claude Codeで、書き方は同じでいいのか？
claude.aiとClaude Codeは、そもそも目的が違う道具だ。同じ書き方をそのまま流用すると、噛み合わない場面が出てくる。
両者の違いを比較軸で整理すると、次のようになる。
| 比較軸 | claude.ai（チャット版） | Claude Code |
|---|---|---|
| 主な目的 | 文章・回答を完成させる | ファイルの変更や作業を実行する |
| 指示の単位 | 質問や依頼の文章 | 対象ファイル＋作業内容＋制約 |
| 出力の受け取り方 | 読んで判断する | diffやコマンド実行結果を確認する |
| 繰り返し使う情報の置き場 | 会話内でその都度伝える | CLAUDE.mdに書いておける |
claude.aiのプロンプトは「文章の完成」を目的にしている
claude.aiでは、1回の質問に対して1つの回答が返ってくることを前提に指示を書く。曖昧さが残っていても、回答を見てから追加で質問すればよい。
Claude Codeのプロンプトは「行動の指示」であるという違い
Claude Codeでは、指示がそのままファイルの変更やコマンド実行につながる。曖昧な指示は、曖昧なままの行動として実行されてしまう可能性がある点が、チャット版との大きな違いになる。
プロンプトに書くこと・CLAUDE.mdに書くことの分かれ目
今回だけ変わる目的、対象ファイル、完了条件はプロンプトに書く。コーディング規約、ディレクトリ構成、常に禁止する操作のように、タスクをまたいで守る前提はCLAUDE.mdに置く。この「次の別タスクでも同じ内容を守るか」が判断基準になる。
一時的な条件までCLAUDE.mdに増やすと、別の作業にも不要な制約が残る。反対に、恒久的なルールを毎回のプロンプトに書くと、書き忘れた回だけ挙動が変わる。詳しい設定方法はCLAUDE.mdの書き方ガイドに譲る。定型作業はスラッシュコマンド、役割を分けて独立させる処理はClaude Codeのサブエージェント活用ガイドで扱っている。
長いセッションでは、指示をこまめに区切ったほうがいい
会話が長引くほど、1回の指示に詰め込む作業量は減らしたほうがいい。
セッションが長引くと、以前のやり取りの情報がAIの参照範囲（コンテキスト）を圧迫し、初期の指示内容が反映されにくくなることがある。
1プロンプト=1タスクに分解する理由
4要素の「タスクを1つに絞る」は、長いセッションでは別の理由から効いてくる。単発の指示なら目的が混ざることを防ぐための分割だが、会話が積み上がった状態では、どこまで戻せばよいかを決めるための分割になる。大きな作業を1回の指示にまとめると、途中で意図しない方向に進んだときに、切り分けの単位そのものが無い。小さく区切っておけば、うまくいかなかった箇所だけをやり直せる。
コンテキストが溢れてきたときのサイン
同じ説明を繰り返し求められる、直前に伝えたはずのルールが反映されなくなる、といった様子が見えたら、参照範囲が圧迫され始めているサインと考えてよい。
セッションを区切る・引き継ぐときの書き方
作業の区切りごとに、決まった事項と残っている課題を短くまとめて次のセッションに引き継ぐと、情報が失われにくい。何を社内資料として残すかという運用面は、Claude Codeの運用ルールの作り方でも扱っている。
Claude Codeが誤った変更をしたとき、どう指示し直せばよいか？
「違います」の一言だけでは、AIには何が違うのか判断できない。何がどう違うのかまで具体的に指示し直す必要がある。
「違います」だけでは直らない理由
指示のやり直しも、最初の指示と同じく4要素で組み立てる必要がある。「どの部分が」「どう違って」「何を期待していたか」を書くと、次の出力の精度が上がる。
差し戻し→再指示の型
直前の変更のうち、[具体的な箇所]が意図と違う。
期待していたのは[期待する挙動]で、
実際には[実際に起きたこと]になっている。
この部分だけを修正してほしい。変更内容そのものの確認や取り消しには、gitの差分確認やrevertの操作を組み合わせる。具体的な手順はClaude Codeのgit操作ガイドにまとめている。
深刻な誤りが起きたときの切り分け
意図しないファイルの削除や、想定外の範囲への変更が起きた場合は、まず作業を止めて変更内容を確認することを優先する。よくあるエラーへの対処はClaude Codeのエラー対処ガイドでも整理している。
自己流での改善には、どこに限界があるのか？
自己流の学習は、型を覚えるところまでは届いても、自分の状況に合わせて応用するところで手が止まる。
ガイドを読むだけで直るものと、直らないもの
先述の経営者は、教材や動画、AIそのものに聞くことでは解決に至らなかったと述べている。理由として「インプットはするが自分のアウトプットが分からなくなる」「似た事例はいくらでもあるが100%同じものはない」「AIに聞けば解決すると言われたが自分にはできなかった」を挙げている。ガイドや記事は型を伝えることはできても、その型を自分の業務に当てはめる部分までは代わりにやってくれない。
型を知っていても止まってしまう瞬間
4要素も、Before/Afterの型も理解した上で、いざ自分の業務に応用しようとすると、何を背景として書けばよいのか、どこまでを制約として伝えればよいのかで手が止まることがある。これは知識不足ではなく、自分の状況に合わせた「翻訳」の難しさによるものが大きい。
次に進む選択肢（自己流を続ける／研修で体系立てる／個別に伴走を受ける）
自己流で試行錯誤を続ける、法人向けの研修で体系立てて学ぶ、個別に伴走を受けて自分の業務にあわせて型を作る、という3つの選択肢がある。研修の選び方を比較したい場合はClaude Code研修の選び方、教材そのものを比較したい場合はClaude Codeの学習教材ガイドを参照してほしい。まず自分の手で使えるようになりたい場合は、月額1,980円からの学習コミュニティAI駆動ラボで体系立てて学べる。
まとめ：結局、何から始めればいいのか
まずは自分がよく出す指示を1つ選び、背景・タスク・出力形式・ルールの4要素で書き直せるか確かめてみてほしい。非エンジニアであれば、いきなり修正を頼むのではなく、現状を説明させる指示から始めるのが安全な一歩になる。
型を理解した後は、自分の業務でよく扱う作業を1つ選び、変更してよい範囲と守るべき制約まで書けるかを確かめる。そこで詰まった箇所が、次に補うべき背景情報になる。