はじめに：Claude Codeへの指示は「作業依頼書」
第6回までで、フォルダ・ターミナル・Gitの基礎（第4回）、権限管理（第5回）、データ保護（第6回）という「事前準備と安全」の土台が整いました。第7回からは第3章（基本操作）に入り、いよいよClaude Codeとの実際のやり取りを扱います。最初のテーマは、もっとも成果を左右する「指示の出し方」です。
Claude Codeは優秀な相棒ですが、こちらの頭の中までは読めません。同じ作業でも、指示が曖昧だと何度も手戻りが発生し、指示が整っていれば一度でほぼ意図どおりに動きます。本記事では、Python経験者の非エンジニア向けに、プロンプト（AIへの指示文）を「作業依頼書」として設計する考え方を、具体例とともに一歩ずつ整理します。
この記事のゴール
本記事を読み終えると、次のことができるようになります。
- 曖昧な指示がもたらす典型的な失敗パターンを説明できる
- 「目的・前提・入力・出力形式・制約」の5つの軸で指示文を組み立てられる
@によるファイル参照やPlan modeなど、指示を助けるClaude Codeの機能を使える- 「指示→出力→評価→修正指示」という反復改善のリズムを身につけられる
- よく使う指示をCLAUDE.mdやカスタムコマンドとして資産化する方向性を理解できる
安全に関する留意事項
指示文やAIに読ませるファイルには、第6回で扱った機密データ（APIキー・患者情報・学生情報・未公開研究データ）を含めないことが大前提です。良い指示を書こうとするほど具体的な情報を盛り込みたくなりますが、その情報が「渡してよいものか」を毎回確認する習慣を保ってください。
なぜ指示の質が出力の質を決めるのか
Claude Codeは、与えられたプロンプトと、読みに行ったファイルの中身を手がかりにして応答を組み立てます。逆に言えば、こちらが渡していない前提や、言葉にしていない期待は、基本的に反映されません。「いい感じに直して」という指示で出てきた結果が期待と違うのは、AIの能力不足ではなく、こちらが「いい感じ」の中身を伝えていないからです。
Pythonを学んだ方には、関数の引数を思い浮かべると分かりやすいかもしれません。引数（入力）が曖昧なら、戻り値（出力）も曖昧になります。プロンプトは、AIという関数に渡す引数そのものです。引数を丁寧に設計するほど、期待する戻り値に近づきます。
指示の質を上げる利点は、単に一発で当たりやすくなることだけではありません。指示が明確だと、出てきた結果が良いか悪いかを自分で評価できるようになります。「何を頼んだか」がはっきりしていれば、「頼んだとおりになっているか」を確認できるからです。これは、AI生成物を無検証で使わないという本シリーズの基本姿勢とも直結します。
曖昧な指示が生む典型的な失敗
まず、よくある曖昧な指示と、そこで起きがちな失敗を整理します。いずれも「AIが悪い」のではなく「依頼の仕方に改善余地がある」例です。
- 「このコードを直して」：どこが、なぜ問題なのかを伝えていないため、意図しない箇所まで書き換えられたり、こちらが気にしていた点が直っていなかったりします
- 「いい感じにして」：評価基準（速度なのか、可読性なのか、行数なのか）が曖昧なため、AIが推測で動き、結果がぶれます
- 「全部やっておいて」：作業範囲が無制限に解釈され、触ってほしくないファイルまで変更されるリスクがあります
- 「エラーが出たから何とかして」：エラーメッセージや再現手順を渡していないため、推測ベースの修正になり、根本原因にたどり着きにくくなります
共通しているのは、「目的」「対象」「期待する結果」「やってはいけないこと」のいずれかが抜けている点です。次の章で、これらを埋める枠組みを示します。
良い指示の5つの軸：目的・前提・入力・出力形式・制約
良い作業依頼書には、共通する構造があります。私は次の5つの軸を意識すると、指示の抜け漏れが大きく減ると考えています。
1. 目的（何のために・どうなれば成功か）
その作業で最終的に何を達成したいのか、どうなれば成功と言えるのかを最初に示します。「処理を速くしたい」「他人が読んでも分かるコードにしたい」「テストを通したい」など、ゴールが定まると、AIは手段を選びやすくなります。
2. 前提（背景・環境・制約条件）
使っているOS（Windowsなど）、Pythonのバージョン、利用しているライブラリ、プロジェクトの目的といった背景情報です。「このスクリプトは薬局の在庫集計に使う」「pandasは使ってよいが新しいライブラリは追加しないでほしい」といった前提があると、的外れな提案を避けられます。
3. 入力（どのファイル・どのデータが対象か）
作業の対象を具体的に示します。「analysis.pyのsummarize()関数」「data/sample.csvの列構成」のように、ファイル名・関数名・データの形を伝えます。Claude Codeでは、後述する@記法でファイルそのものを参照させると、こちらが説明する手間が減り、誤解も減ります。
4. 出力形式（どんな形で返してほしいか）
結果をどの形で受け取りたいかを指定します。「修正後のコード全体を見せてほしい」「変更点だけを差分（変更前後の比較）で示してほしい」「まず方針を箇条書きで説明し、コードはその後にしてほしい」など、形式を指定すると受け取った後の確認が一気に楽になります。
5. 制約（やってはいけないこと・守るべきルール）
守ってほしい境界線を明示します。「main.py以外は変更しない」「外部ライブラリを追加しない」「既存の関数名は変えない」「振る舞いを変えずに改善する」といった制約は、暴走を防ぐ安全装置になります。第5回で扱った権限管理が「操作の範囲」を制限する仕組みなら、この制約は「依頼内容そのもの」で範囲を絞る工夫です。
実例：5つの軸で依頼を組み立てる
抽象論だけでは伝わりにくいので、具体例で比べてみます。題材は「CSVファイルを集計するPythonスクリプトの改善」です。
まず、改善前のよくある曖昧な指示です。
sales.py を見やすくしてこれでは、何を基準に「見やすく」するのか、どこまで触ってよいのかが伝わりません。次に、5つの軸を盛り込んだ指示です。
目的：sales.py を、他の薬剤師が読んでも理解できるように可読性を上げたい。
前提：Windows、Python 3.12、pandas 利用可。月次の売上CSVを集計するスクリプト。
入力：対象は @sales.py のみ。集計ロジックは正しく動いている。
出力形式：まず改善方針を箇条書きで説明し、その後に修正後のコード全体を示してほしい。
制約：処理結果（集計値）は変えないこと。新しいライブラリは追加しないこと。
関数名 main は変更しないこと。後者であれば、AIは「振る舞いを変えずに、可読性だけを上げる」という意図を正確に受け取れます。「まず方針を説明してから」と指定しているので、こちらは方針を確認したうえで、コードに進む前に軌道修正もできます。指示が長くなりすぎたと感じるかもしれませんが、慣れれば数十秒で書ける定型です。手戻りの時間を考えれば、十分に割に合います。
なお、指示は「長ければ良い」わけではありません。要点を構造化して伝えるのが目的であって、関係のない背景を延々と書くと、かえって重要な指示が埋もれます。5つの軸に沿って、必要なことを過不足なく書くのがコツです。
ファイルとコンテキストの上手な渡し方
Claude Codeには、指示を助ける機能がいくつも用意されています。指示文の質と合わせて使うと効果が高まります。
@によるファイル参照：プロンプトの中で@ファイル名と書くと、Claude Codeがそのファイルを読み込んでから応答します。ファイルの場所や中身を言葉で説明するより、対象を直接指し示すほうが確実です。複数ファイルをまとめて参照することもできます。なお、ファイルを指定した場合はその中身が渡されますが、フォルダ（ディレクトリ）を指定した場合は中身全体ではなくファイルの一覧が渡される点に注意してください。フォルダ内の特定ファイルの内容を見てほしいときは、そのファイルを直接指定します。
範囲を絞って渡す：巨大なコード全体を一度に渡すより、関係する関数やファイルに絞ったほうが、AIは要点に集中できます。「どこを見てほしいか」を絞ること自体が、良い指示の一部です。
スクリーンショットや図の活用：エラー画面やグラフなど、言葉にしづらい情報は画像で渡せます。その際は、第6回で触れたとおり、機密情報や個人情報が映り込んでいないかを必ず確認してください。
Plan mode（計画モード）：いきなりファイルを書き換えさせるのではなく、まず作業計画を立てさせてから実行に移すモードです。大きめの変更や、影響範囲が読みにくい作業では、Plan modeで方針を確認してから進めると、意図しない変更を防げます。これは第5回の権限管理とも相性のよい、安全側の進め方です。
反復改善のリズム：指示→出力→評価→修正指示
もうひとつ大切なのが、「一発で完璧を狙わない」という姿勢です。良い指示を出しても、最初の出力が100点とは限りません。そこで効いてくるのが、反復改善のリズムです。
流れはシンプルです。①指示を出す、②出力を受け取る、③期待と照らして評価する、④ずれている点を具体的に伝えて修正を依頼する。この④の修正指示こそ、5つの軸の出番です。「もっと良くして」ではなく、「この関数の引数名が分かりにくいので、日本語のコメントを添えてほしい」のように、ずれた一点を具体的に伝えると、次の出力は確実に良くなります。
会話が長くなって論点がぼやけてきたら、思い切って仕切り直すのも有効です。Claude Codeには会話の文脈を整理・リセットする機能（/clearで会話をリセット、/compactで過去のやり取りを要約して圧縮、/contextで現在の文脈の使用状況を確認）が用意されています。学んだことを踏まえて、より具体的な指示で新しく始め直したほうが、長い会話を引きずるより速く解決することは少なくありません。
プロンプトを資産化する：CLAUDE.mdとカスタムコマンド
毎回同じ前提や制約を書くのは手間です。Claude Codeには、繰り返す指示を「資産」として蓄える仕組みがあります。
ひとつはCLAUDE.md（Claude Codeにプロジェクト固有のルールや前提を伝えるMarkdownファイル）です。「このプロジェクトはWindows・Python 3.12」「新しいライブラリは追加しない」といった毎回共通の前提を書いておけば、個々の指示から前提部分を省けます。バージョンによっては、セッション中に#に続けてメモを書くことで、エディタを開かずにメモリ（CLAUDE.md等）へ追記できる場合があります。ただし、この操作方法やキー入力はバージョンによって異なることがあるため、最新の手順は公式ドキュメントで確認してください。CLAUDE.mdの詳しい書き方は第12回で扱います。
もうひとつは、よく使う指示を呼び出せるようにする工夫です。Claude Codeには多数の組み込みスラッシュコマンド（/で始まる操作コマンド）があり、自分専用のコマンドを定義することもできます。現在は.claude/skills/に置くスキル形式（/名前で呼び出せ、Claude自身による自動起動にも対応）が推奨されています。従来の.claude/commands/に置く形式も引き続き利用できます。「いつも同じ手順でレビューを頼む」といった定型作業は、こうした形でコマンド化しておくと再現性が上がります。
よくあるつまずきとその対処
第7回の段階で多くの方が遭遇する、代表的なつまずきを挙げておきます。
- 背景を省いて結果だけ求めてしまう：「速くして」だけでは基準が伝わりません。目的と評価基準（何をもって成功とするか）を1行添えるだけで、出力は大きく安定します
- 一度の指示で全部を盛り込もうとする：「読みやすくして、テストも書いて、ドキュメントも作って」と一度に頼むと、どれも中途半端になりがちです。作業を分割し、一つずつ確認しながら進めるほうが結果的に速くなります
- 修正指示が抽象的になる：「違う、そうじゃない」では伝わりません。どこが、どう違うのかを具体的に示すと、次の出力で直ります
- 出力をそのまま信用してしまう：指示が良くても、出力の検証は別問題です。AI生成コードは必ず自分で読み、可能なら動かして確認します。検証の具体的な方法は第9回（デバッグ）・第11回（テスト）で扱います
よくある質問（FAQ）
第7回に関して、読者から寄せられやすい疑問をまとめます。
Q. 指示はどのくらい詳しく書けばよいですか。
A. 「目的・前提・入力・出力形式・制約」の5つが埋まっていれば十分です。逆に、関係のない背景まで延々と書くと重要な指示が埋もれるため、構造化して過不足なく書くのがコツです。簡単な作業なら5つすべてを書かなくても、目的と制約だけで通じることもあります。
Q. 日本語で指示しても大丈夫ですか。
A. 日本語の指示で問題ありません。本記事の例もすべて日本語です。大切なのは言語ではなく、依頼の構造が整っているかどうかです。専門用語や固有名詞（ファイル名・関数名）は、誤解を避けるため原文の表記のまま書くと確実です。
Q. 一度に多くを頼むのと、小分けに頼むのはどちらがよいですか。
A. 慣れるまでは小分けをおすすめします。一つの作業を頼んで結果を確認し、問題なければ次へ進むほうが、間違いに早く気づけて手戻りも小さくなります。反復改善のリズムとも相性がよい進め方です。
ファーマAIラボ的視点：指示書を書く力は薬剤師・研究者の強み
「良い指示を書く」と聞くと、エンジニア特有の難しいスキルのように感じるかもしれません。しかし、医療・研究の現場で働く方は、すでにこの力の土台を持っています。
薬剤師がSOAP形式で薬歴を記録するとき、研究者が実験プロトコルや手順書を書くとき、教員がシラバスや課題の評価基準を示すとき――いずれも「目的・前提・対象・期待する成果・守るべき条件」を構造化して相手に伝えています。これは、本記事で紹介した5つの軸とほとんど同じ構造です。あいまいさを残さず、第三者が再現できる形で指示を書く訓練を、専門職として日常的に積んできているわけです。
その意味で、良いプロンプトを書く力は、まったく新しい能力を一から習得する話ではありません。これまで培ってきた「正確に伝える力」を、相手がAIに変わっただけと捉えて、そのまま応用していただければと思います。
第7回のまとめ：指示を「作業依頼書」として設計する
本記事では、Claude Codeに良い指示を出す方法を扱いました。要点は次のとおりです。
- 出力の質は指示の質で決まる。AIは読心術ではなく、渡された情報から応答を組み立てる
- 良い指示は「目的・前提・入力・出力形式・制約」の5つの軸で組み立てる
@でのファイル参照、範囲を絞る工夫、Plan modeを組み合わせると精度が上がる- 一発で完璧を狙わず、「指示→出力→評価→修正指示」の反復改善で仕上げる
- 繰り返す指示はCLAUDE.mdやカスタムコマンドとして資産化する
- 指示が良くても出力の検証は別。AI生成物は必ず自分で確認する
良い指示を出せるようになると、Claude Codeとのやり取り全体が一気にスムーズになります。次回以降の「コード読解」「デバッグ」でも、この5つの軸が土台になります。
次回予告
第8回は「PythonコードをClaude Codeに読ませる」です。第3章（基本操作）の2回目として、既存のPythonコードを渡して機能要約や処理フローの説明を得る方法を扱います。自分が書いていない他者のコードや、過去の自分のコードを読み解く足がかりを得るのがゴールです。本記事で学んだ「良い指示の5つの軸」が、さっそく役立つ回になります。
公式ドキュメント参照のリマインド
Claude Codeの機能（スラッシュコマンド、Plan mode、ファイル参照の記法など）や推奨される使い方は短期間で更新されます。本記事の内容は2026年6月時点の情報を基に執筆していますが、実際の操作にあたっては、必ずAnthropic公式ドキュメント（https://code.claude.com/docs）の最新版を確認してください。とくにコマンド名やキー操作は、バージョンによって変わる場合があります。
参考文献・関連リンク
- Anthropic公式：Claude Code Docs（
https://code.claude.com/docs） - Anthropic公式：Best practices for Claude Code（
https://code.claude.com/docs/en/best-practices） - Anthropic公式：Claude Code 製品ページ（
https://claude.com/product/claude-code） - Anthropic公式：Prompting best practices（Claude API Docs）
- 本シリーズ第5回：Claude Codeを安全に使うための権限管理入門
- 本シリーズ第6回：APIキー・個人情報・研究データを守るための注意点
- 本シリーズ第8回（次回）：PythonコードをClaude Codeに読ませる
- 本シリーズ第12回：CLAUDE.mdで作業ルールを伝える
- 本シリーズの公式コンセプト：claude-code-python-blog-series-plan.md（ファーマAIラボ内部資料）
本記事の位置づけに関する注記
本記事は、Anthropicが公開しているClaude Code関連情報を参考に、Python学習経験のある非エンジニア向けに筆者が独自に構成・解説したものです。AnthropicまたはClaude Codeの公式記事ではありません。仕様、料金、対応環境、利用条件、コマンド体系は変更される可能性があるため、最新情報は公式ドキュメントをご確認ください。
制作ノート
本シリーズの記事およびサンプルコードは、Claude Code／Claude Opus 4.8を活用して執筆しています。AI生成情報については、公式ドキュメント等の一次情報で裏取りした上で掲載しています。読者の皆さまにおかれましても、AIを使って成果物を公開する際は、AI関与の透明化を推奨します。
免責事項
本記事は生成AIを活用して作成しています。内容については十分に精査しておりますが、誤りが含まれる可能性があります。また、Claude Codeおよび関連サービスの仕様・料金・コマンド体系は変更される場合があります。最新かつ正確な情報は必ず公式ドキュメントをご確認ください。お気づきの点がございましたら、コメントにてご指摘いただけますと幸いです。なお、本記事の内容に基づいて生じたいかなる損害についても、当サイトは責任を負いかねます。
本記事に関連するおすすめ書籍をご紹介します。 Amazonでこの関連書籍「大規模言語モデルを使いこなすためのプロンプトエンジニアリングの教科書」を見る