1. はじめに：土台の次は「頼み方」を整える
第2章では、フォルダ・ターミナル・Git（第4回）、権限管理（第5回）、データ保護（第6回）と、Claude Codeを安心して使い始めるための土台を整えました。第3章の最初となる本記事では、Claude Codeとの実際のやり取りに入っていきます。テーマは、プロンプトを「作業依頼書」として設計する考え方です。
Pythonを学んだ経験があると、「AIには自然な言葉で頼めば伝わるはず」という期待を持ちがちです。しかし実際には、依頼が曖昧なほど出力もぼやけ、修正のやり取りが長引きます。第7回は、Python経験者の非エンジニアが、日々の研究・教育・業務でClaude Codeを使うときの「頼み方の型」を身につけることを目的とします。曖昧な指示がなぜ失敗するのかを起点に、良い指示文の構造と、反復改善のリズムを順に整理していきます。
2. この記事のゴール
本記事を読み終えると、次のことができるようになります。
- 曖昧な指示がもたらす4つの失敗パターンを言語化できる
- 「目的・前提・入力・出力形式・制約」の5要素で指示文を組み立てられる
- 悪い指示と良い指示の対比を、自分のタスクで作れる
- 反復改善（指示→出力→評価→修正指示）のリズムを持てる
- Plan modeや会話文脈を、指示設計と組み合わせて使い分けられる
本記事の指示例は、機密情報を含まない架空データや公開データを想定しています。第6回で扱った「渡してはいけない4種類のデータ」の線引きは、指示を工夫しても変わりません。プロンプトに機密を貼らない、アクセスさせたくないファイルを作業ディレクトリや--add-dirで追加するディレクトリに置かない、権限設定や除外設定（.claude/settings.jsonの許可・拒否ルール、.gitignore等）を活用する、といった前提はこの記事でも共通です。
3. なぜ曖昧な指示は失敗するのか
Claude Codeに「このコードをよくして」「ちょっと整理して」「使いやすくして」といった指示を出すと、返ってくる出力の方向がバラつきます。よくある失敗を4つに整理すると、原因が見えやすくなります。
3.1. 目的がぶれる：可読性を上げたかったのに、AI側は「実行速度を上げる」方向で書き換えてしまうケースです。指示の「よくする」が何を指すかを、依頼側が言語化していないと、AIは自分なりの解釈で動きます。
3.2. 前提が伝わらない：Python 3.11で動かしているのか、Colabなのか、社内サーバーなのか。pandasのバージョンやOSは何か。こうした前提は、AIから見ると「聞かない限り分からない」情報です。前提が共有されていないと、環境で動かないコードが返ってきます。
3.3. 入力と出力の形が決まっていない：どんな入力に対して、どんな形の出力が欲しいのか。CSVなのかJSONなのか、関数なのかスクリプトなのか、標準出力なのかファイル書き出しなのか。ここが定義されていないと、AIは「たぶんこれだろう」で書きます。
3.4. やってはいけないことが指定されていない：外部ライブラリを追加してほしくない、既存ファイルを書き換えてほしくない、実行はしないでほしい、といった制約が明示されていないと、AIは自由に動きます。第5回で扱った権限モードや.claude/settings.json（プロジェクト単位の設定ファイル）はハードな枠ですが、指示文の中の制約は「毎回の依頼書に添えるソフトな枠」です。
この4つが、そのまま「良い指示に必要な要素」の裏返しになります。目的・前提・入力・出力形式・制約という5つの軸を意識するだけで、失敗のほとんどは事前に潰せます。
4. 良い指示文の5要素：作業依頼書として書く
Claude Codeへの指示は、AIに対する自然言語のメッセージであると同時に、後から自分が読み返せる「作業依頼書」でもあります。次の5要素をテンプレとして頭に置いておくと、依頼書としての質が安定します。
要素1：目的（何を達成したいのか）
そのタスクで何を達成したいのかを、1〜2文で言語化します。「可読性を上げたい」「バグの原因を特定したい」「pytestが通るようにしたい」「同僚に説明できる程度に整理したい」など、抽象度は場面に応じて構いません。大切なのは、「よくしたい」ではなく、何が良くなればゴールなのかを一段だけ具体化することです。
要素2：前提（AIが知らない文脈）
使っている言語のバージョン、OS、実行環境（Colab／ローカル／サーバー）、依存ライブラリ、扱っているデータの性質、プロジェクトの背景など、AIから見えない情報を渡します。特に、非エンジニアが忘れがちなのは「なぜこの作業が必要か」という背景です。背景が分かると、AIはやり過ぎず、不足なく提案の粒度を調整してくれます。
要素3：入力（何を渡すのか）
コードなのかログなのかデータなのか。1ファイルなのか複数ファイルなのか。全体を読ませたいのか、特定の関数だけなのか。入力の範囲を絞ると、AIは無駄な推測をせず、範囲の中で答えを組み立てます。ファイルパスを直接示す、コードブロックを貼る、という単純な工夫でも効果があります。
要素4：出力形式（どう返してほしいのか）
「日本語で説明してほしい」「関数の骨格だけ提示してほしい」「差分（diff）で示してほしい」「修正パッチとしてファイルを直接編集してほしい」「まずは方針だけ、コードは実装しない」など、返ってきてほしい形を指定します。ここを決めるだけで、後工程（自分が読む、他人に共有する、直接コミットする）とのつながりが滑らかになります。
要素5：制約（やらないでほしいこと）
ライブラリの追加禁止、既存ファイルの上書き禁止、ネットワーク接続の禁止、コミットしない、実行しない、テスト以外は書き換えないなど、境界線を明示します。第5回の.claude/settings.json（プロジェクト単位の権限・許可コマンドを定義する設定ファイル）がプロジェクト全体の枠だとすれば、この制約は「今回のタスクだけの追加ルール」に相当します。
5. 悪い指示と良い指示：同じタスクで対比する
抽象論だけでは掴みにくいので、具体的な依頼で対比を見てみます。題材は「pandasで書かれたCSV集計スクリプトを整理してほしい」という架空のタスクです。
悪い例
このコードちょっとよくしてぱっと見、依頼としては成立しているように見えます。しかし、目的（何をよくしたいのか）・前提（バージョン、環境）・入力（どのコードか）・出力形式（どう返すのか）・制約（禁止事項）のいずれもありません。AIは何を優先すべきか判断できず、無難な整形やリファクタを返して終わり、というパターンになりがちです。
良い例
目的：可読性を上げて、同僚（Python初学者）に引き継げる状態にしたい。実行速度は今のままで良い。
前提：Python 3.11、pandas 2.2、Windows 11 のローカル環境。CSVは最大1万行の売上データ。
入力：sales_report.py（このファイルの内容）。
出力形式：
1. 現在の構造の要約（3〜5行）
2. 改善方針（箇条書き 3〜5個、なぜその変更が必要かを添える）
3. 修正後のコード全体（1ブロック）
制約：
- 新しい外部ライブラリは追加しない（標準ライブラリと pandas のみ）
- ファイルは直接書き換えない（提案として返してほしい）
- 関数の入出力の型（引数と戻り値）は変更しないこの依頼書があれば、AIは「可読性向上」の方向で提案を絞り、Python初学者に説明しやすい変数名・関数分割を選ぶようになります。返ってきた提案を自分で読んで、そのままエディタにコピペするかどうかを判断できます。5要素が揃っていると、後で自分が読み返しても「何を頼んだか」が一目で分かる利点もあります。
6. 反復改善のリズム：一発で決めない
良い指示文を書けば、返ってくる出力の質は上がります。それでも、1回のやり取りで完成に至ることは稀です。ChatGPTのようなチャット型AIと同じく、Claude Codeとの作業も、「指示→出力→評価→修正指示」というループで進めるのが基本になります。
ステップ1：指示を出す
先ほどの5要素で最初の依頼書を書きます。最初は完璧を目指しすぎず、目的と入力・出力形式だけでもきちんと決めておけば十分です。
ステップ2：出力を読む
AIが返してきた提案を、自分の目で読みます。ここが最も大切なステップです。コードなら、まずざっと読んで意図が理解できるかを確認し、次に細部の妥当性（変数名、条件分岐、境界処理）を追います。文章なら、事実誤認や過剰な断定がないかを見ます。
ステップ3：評価する
読んだ結果を、「意図と合っている／ずれている」「使える／使えない」「一部だけ採用したい」に振り分けます。「ずれ」があった場合は、指示の5要素のどれが不足していたかを特定します。目的がぶれたのか、前提が伝わらなかったのか、出力形式がずれたのか、制約を書き忘れたのか。原因を1つに絞れると、次の修正指示が短くなります。
ステップ4：修正指示を出す
「ずれ」の原因に対応した修正だけをピンポイントで伝えます。「もう一度全部やり直して」ではなく、「関数名だけスネークケースに揃えて」「先ほどの2番目の方針は不採用、残りをコードに反映して」といった、差分ベースの依頼が有効です。Claude Codeは会話の文脈を保持するため、前のやり取りを引き継いで、狙ったところだけ修正できます。
このループを2〜3回繰り返すと、多くのタスクは実用レベルに到達します。逆に、ループが5回を超えても収束しないときは、最初の依頼書の設計に戻って、目的か前提を組み立て直すサインです。「同じ指示を強くくり返す」よりも、「一段戻って書き直す」ほうが速いことが多いです。
7. 会話文脈の活用と、その限界
Claude Codeとのやり取りでは、同じセッション内であれば、前のメッセージやAIが読んだファイルの内容が文脈として保持されます。これは強力な特徴で、依頼書を毎回フルセットで書き直す必要はありません。前段で「Python 3.11 前提で」と伝えていれば、次の依頼では省略しても通じます。
ただし、文脈は無限ではありません。長いセッションで大きなファイルを何度も読み込むと、会話履歴が過大になり、AIが古い前提を混同したり、直近の指示を優先しすぎたりする挙動が出ることがあります。1つのセッションが長くなってきたと感じたら、以下のいずれかで整理するのが実務的です。
- タスクの区切りで新しいセッションを立て、直前のセッションの要点だけを最初のメッセージで再提示する
- プロジェクトの共通ルール（Python バージョン、コーディング規約、禁止事項）は
CLAUDE.md（第12回で扱います）に書き出して、毎回のプロンプトから消す - 依頼書の5要素のうち、変わらない部分（前提・制約）は
CLAUDE.md側に寄せ、プロンプトには変わる部分（目的・入力・出力形式）だけ書く
会話文脈は「短期記憶」、CLAUDE.mdは「毎セッションの起動時に読み込まれるプロジェクト指示・持続的な文脈」と捉えて役割分担すると、依頼書の設計が長期的にも軽くなります。CLAUDE.mdは権限設定のように動作を強制するものではなく、AIに参照させる「共通の前提書き」に近いものです。書いた内容が必ず尊重されるとは限らないため、重要な制約は依頼書側にも改めて明記するのが安全です。
8. Plan mode と組み合わせて設計する
第5回で紹介したPlan modeは、5要素の依頼書と相性がよい機能です。Plan modeは、Claude Codeがファイルの読み取りや探索用コマンドの実行は行いつつ、ソースファイルの編集や書き込み系の変更は行わずに、「何をどう変えるつもりか」を計画として提示するモードです。目的と前提だけをしっかり書いた依頼書をPlan modeで投げると、AIはコードを一気に書き換えるのではなく、リポジトリを読み解いたうえで、まず設計方針を返してくれます。
このとき、評価ステップが計画レビューに置き換わるため、コードが実際に書かれる前にずれを検出できるようになります。方向性がずれていれば、実装前に指示を修正する。方針が納得できれば、そのまま実行に進む。この2段階運用は、Python経験者が「AIに任せすぎず、自分の判断を挟む」ためのわかりやすい枠組みです。
研究・教育の現場で、「実行前に一度立ち止まりたい」タスク（データ加工の方針決め、教材の章立て設計、コードの大幅リファクタリングなど）では、Plan modeを既定にしておくと安全側に振れます。
9.よくあるつまずきと、その対処
実際に依頼書型で書き始めると、いくつかの共通のつまずきが出ます。よくあるパターンを3つ挙げます。
依頼書が長くなりすぎる：5要素をすべて書こうとして、依頼が2000字を超えてしまうケースです。長い依頼書はAI側でも読み解きに時間がかかり、依頼側の思考も散らかります。対処は、共通部分（前提・制約）をCLAUDE.mdに移し、プロンプトには変わる部分だけ残すこと。それでも長くなる場合は、タスク自体を分解して複数の依頼に分けます。
出力形式を書いたのに、その形で返ってこない：形式の指定が抽象的すぎることが多いです。「見やすくして」ではなく、「Markdown表で、列は『関数名・目的・入力・出力』の4つ」まで具体化すると、狙った形で返ってきます。それでもずれる場合は、期待するフォーマットのサンプルを1行だけ添えると効果的です。
途中で目的が変わっても、指示を上書きしていない：会話が進むうちに、当初の目的（可読性向上）から派生タスク（バグ修正）に自然に移ることがあります。このとき、AIは前の目的を引きずるので、「ここから目的を変える。以降は◯◯を優先してほしい」と明示的に切り替え宣言をするのが安全です。
10. ファーマAIラボ的視点：薬剤師・研究者にとっての「依頼書化」の価値
薬剤師や薬学研究者の日常業務では、後輩薬剤師・研究員・学生への指示、実験プロトコルの記述、症例検討のまとめ、といった「他者に作業を伝える書き物」が日常的に発生します。依頼書型のプロンプト設計は、これらのスキルとほとんど同じ構造です。目的・前提・入力・出力形式・制約は、そのまま「業務手順書」や「実験プロトコル」の主要要素と重なります。
Claude Codeへの指示を丁寧に書けるようになることは、副次的に、部下・後輩・学生への指示の質を上げることにもつながります。逆に、指示文を書くのが苦手だと感じる方は、Claude Codeを「言葉で指示を組み立てる練習の場」として使うのも有効です。AI相手なら、伝わらなかったときのコストは小さく、何度でもやり直せます。教育現場・研究室運営の場でも、AIとのやり取りを通じて、指示文の型を体で覚える機会として活用できます。
11. まとめ：作業依頼書として指示を組み立てる
本記事では、Claude Codeへの指示を「作業依頼書」として設計する考え方を扱いました。要点をまとめます。
- 曖昧な指示は、目的のぶれ・前提の欠落・入出力の未定義・制約の未指定という4パターンで失敗する
- 良い指示文は、目的・前提・入力・出力形式・制約の5要素で組み立てる
- 反復改善は「指示→出力→評価→修正指示」のループで、差分ベースの修正指示を心がける
- 変わらない部分は
CLAUDE.mdに、変わる部分はプロンプトに、と役割分担する - Plan modeと組み合わせると、実行前にずれを検出できる二段階運用ができる
Claude Codeは指示を「察してくれる」ツールではなく、指示を「そのまま受け取って動く」ツールです。指示の質を上げれば、返ってくる出力の質も比例して上がります。
12. 次回予告
第8回は「PythonコードをClaude Codeに読ませる」です。既存のPythonコードを渡して、機能要約・処理フロー・関数間の依存関係を洗い出させる手順を扱います。他者のコード、あるいは過去の自分のコードを読み解く足がかりとして、Claude Codeをどう使うかを整理します。第7回で身につけた依頼書型の指示を、実際のコード読解シーンに落とし込む回です。
13. 公式ドキュメント参照のリマインド
Claude Codeのプロンプト機能、Plan mode、会話履歴の扱いは短期間で更新される可能性があります。本記事の内容は2026年7月時点の情報を基に執筆していますが、業務・研究での導入時には、必ずAnthropic公式ドキュメント（https://code.claude.com/docs）とClaude Code製品ページ（https://claude.com/product/claude-code）で最新の仕様を確認してください。モデル名（Claude Opus 4.8、Claude Sonnet 4.6、Claude Haiku 4.5など）や利用条件は変更される場合があります。本文中のモデル名は執筆時点の一例であり、固定情報として扱わず、実際に自分のプラン・環境で利用可能なモデルはClaude Code内の/modelコマンドで確認してください。
参考文献・関連リンク
- Anthropic公式：Claude Code Docs（
https://code.claude.com/docs） - Anthropic公式：Claude Code 製品ページ（
https://claude.com/product/claude-code） - Anthropic公式：Prompt engineering overview（プロンプト設計の一般論）
- 本シリーズ第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.7を活用して執筆しています。AI生成情報については、公式ドキュメント・公的機関の公表資料等の一次情報で裏取りした上で掲載しています。読者の皆さまにおかれましても、AIを使って成果物を公開する際は、AI関与の透明化を推奨します。
免責事項
本記事は生成AIを活用して作成しています。内容については十分に精査しておりますが、誤りが含まれる可能性があります。また、Claude Codeおよび関連サービスの仕様・料金は変更される場合があります。最新かつ正確な情報は必ず公式ドキュメントをご確認ください。お気づきの点がございましたら、コメントにてご指摘いただけますと幸いです。なお、本記事の内容に基づいて生じたいかなる損害についても、当サイトは責任を負いかねます。
本記事に関連するおすすめ書籍をご紹介します。 Amazonでこの関連書籍「LLMのプロンプトエンジニアリング ― 生成AIをうまく使いこなすための実践ガイド」を見る