Claude Code 実践テンプレート集
はじめに
Claude Codeは便利なツールですが、「何を」「どう」指示すればいいかが最初の壁になります。
同じ機能追加でも、指示の仕方ひとつで返ってくるコードの質が大きく変わります。逆に言えば、指示の型（テンプレート）をいくつか持っておくだけで、Claude Codeとのやり取りは驚くほどスムーズになります。
このテンプレート集は、実際の開発でよく使うシーンを想定し、「そのままコピペして使える指示文」をまとめたものです。Claude Codeを使い始めたばかりの人はもちろん、毎回どう指示すればいいか迷っている人にも役立つように作成しています。
なぜこのテンプレート集を作ったのか
正直なところ、最初のきっかけは「毎回ゼロから指示を書くのが面倒だった」というシンプルな理由です。
Claude Codeに何かを依頼するたびに、状況を説明する文章を一から考えるのは地味に時間がかかります。しかも、その場で思いついた言葉で雑に指示を出すと、返ってくる回答の精度や方向性が毎回バラバラになることに気づきました。
逆に、過去にうまくいった指示の型を残しておいて、それを少し書き換えるだけで依頼するようにしたところ、回答の質が安定するようになり、開発のスピードも落ち着いてきました。「調査だけ依頼する」「方針を確認してから実装してもらう」といった型を持っているだけで、手戻りの数自体が減った感覚があります。
自分用のメモとして溜めていたこれらの指示文を見返していたときに、「同じように毎回の指示に悩んでいる人は他にもいるはずだ」と思い、テンプレートとして整理し直して公開することにしました。
このテンプレート集の使い方
今の状況に近いテンプレートを探す
コピペ用テンプレートの【】部分を自分の状況に書き換える
そのままClaude Codeに貼り付けて実行する
「指示のポイント」「注意点」を参考に、必要に応じて調整する
最初は型通りに使ってみて、慣れてきたら自分用にアレンジしていくのがおすすめです。
テンプレート一覧
現在は「開発」「バグ調査」「ドキュメント作成」「記事作成」の4カテゴリ・10個のテンプレートを収録しています。今後は「AI活用」「SNS運用」などのカテゴリも追加していく予定です。
開発
プロジェクト全体を把握してもらう指示
既存コードを読んで仕様を整理してもらう指示
機能追加を依頼する指示
リファクタリングを依頼する指示
Gitコミットメッセージを作成してもらう指示
次の開発フェーズを提案してもらう指示
バグ調査 7. バグ調査を依頼する指示 8. エラー内容から原因を調査してもらう指示
ドキュメント作成 9. READMEやドキュメントを作成してもらう指示
記事作成 10. 変更内容を記事用にまとめてもらう指示
開発
1. プロジェクト全体を把握してもらう指示
用途 新しいプロジェクトや久しぶりに触るコードについて、Claude Codeに全体構造を理解させるための指示です。
使うタイミング 新しいリポジトリを開いた直後、過去に自分で書いたコードに久しぶりに触る時、他の人（や別のAI）が書いたコードを引き継ぐ時に使います。
コピペ用テンプレート
このプロジェクトの全体像を把握してください。
以下の観点で整理して教えてください。
・使用している言語・フレームワーク・主要ライブラリ
・ディレクトリ構成とそれぞれの役割
・主要な処理の流れ（エントリーポイントから何が動くか）
・気になる点や改善余地があれば軽く触れる
まだ何も変更しないでください。まずは現状把握だけお願いします。
指示のポイント 「まだ何も変更しないでください」と明示するのが重要です。把握フェーズと実装フェーズを分けることで、的外れな修正を防げます。
注意点 プロジェクトが大きい場合、一度に全部を読み込めないことがあります。「特にこのディレクトリを中心に」など対象を絞ると精度が上がります。
実践例
状況：AI仮想通貨トレーダーの開発で、価格データの取得とSQLiteへの保存まで作った後、数日空けて再開した時に使いました。自分で書いたはずの構成を忘れていて、どこから手をつければいいかわからない状態でした。
Claude Codeの回答：ディレクトリ構成を一覧にした上で、「価格取得処理」「DB保存処理」「分析用データ出力処理」の3つに役割が分かれていることを整理し、さらに「分析用データの出力部分がまだ薄い」という指摘も加えてくれました。
判断できたこと：次にやるべきことが「分析用データ出力の強化」だとすぐに判断でき、迷う時間をかけずに作業に入れました。
ワンポイント 「特に〇〇ディレクトリを中心に」のように対象を絞ると、回答の精度が上がります。
2. 既存コードを読んで仕様を整理してもらう指示
用途 仕様書が存在しない、または古くなっているコードについて、「実際に動いている仕様」をドキュメント化してもらう指示です。
使うタイミング 引き継いだコードを修正する前、自分が書いたコードを数ヶ月ぶりに開いた時、仕様書とコードの内容がずれていそうな時に使います。
コピペ用テンプレート
【対象ファイル・ディレクトリ】の内容を読んで、現在の仕様を整理してください。
以下を含めてください。
・この機能が何をするものか
・入力と出力の形式
・想定している正常系・異常系の挙動
・なぜそのような実装になっているか推測できる場合はそれも記載
コードの良し悪しの評価は不要です。「今こうなっている」という事実の整理を優先してください。
指示のポイント 「何をしているか」だけでなく「なぜそうなっているか」まで聞くと、設計意図が見えてきて後の修正がしやすくなります。
注意点 Claude Codeが整理した内容が必ずしも100%正確とは限りません。重要な仕様は実際のコードと突き合わせて確認しましょう。
実践例
状況：価格データをAIが読みやすいJSON形式に変換する処理を、数週間前に書いていました。出力フォーマットの細かいルール（キー名や桁数など）を自分でも忘れていた状態で、このテンプレートを使いました。
Claude Codeの回答：DBのレコードとJSON出力のマッピングを項目ごとに整理し、「タイムスタンプはUNIX秒で出力されている」など、自分でも気づいていなかった細かい仕様まで言語化してくれました。
判断できたこと：仕様書を新たに書く手間をかけずに、その内容をそのまま次の実装（ニュース分析側との連携）に進めていいと判断できました。
ワンポイント 「なぜそうなっているか」もセットで聞くと、設計意図まで言語化されて手戻りが減ります。
3. 機能追加を依頼する指示
用途 要件が固まった新機能を、既存のコードに違和感なく組み込んでもらうための指示です。
使うタイミング 追加したい機能の内容がある程度明確になった段階で使います。
コピペ用テンプレート
以下の機能を追加してください。
【背景・目的】
【追加したい機能の内容】
【制約・条件（あれば）】
実装前に、既存コードのどこに影響が出そうかを教えてください。
私が確認したうえで、実装を進めてもらいます。
指示のポイント 「実装前に影響範囲を教えてください」という一文を入れることで、いきなりコードを書き始めるのを防ぎ、方針確認のワンクッションを作れます。
注意点 一度に複数の機能をまとめて依頼すると、それぞれの実装精度が落ちやすくなります。機能ごとに分けて依頼するのがおすすめです。
失敗例
最初の指示：開発を始めたばかりの頃は、「価格分析機能を追加してください」とだけ伝えて実装を依頼していました。
結果：返ってきたコードは一見動いていましたが、既存のDB保存処理の呼び出し方が変わってしまい、別の処理でエラーが出るようになりました。
原因：影響範囲を確認させずに、いきなり実装させてしまったことが原因でした。
実践例（成功した使い方）
状況：その後、「実装前に既存コードのどこに影響が出そうか教えてください」という一文を必ず入れるようにしました。ニュース分析（OpenAI）と価格分析（Claude）で役割分担している設計を崩さずに、新しい分析モジュールを追加したい場面で使いました。
Claude Codeの回答：「価格データ取得部分のインターフェースは変更せずに、新しい分析モジュールを追加する形になります」という方針が先に返ってきました。
判断できたこと：既存の役割分担を崩さずに進められると事前に確認できたため、安心して実装を任せられました。
ワンポイント 「既存の出力形式は変えない」など制約を先に伝えておくと、的外れな実装を防げます。
4. リファクタリングを依頼する指示
用途 動作は変えずに、コードの可読性や保守性を改善してもらうための指示です。
使うタイミング コードが複雑になってきた、同じような処理が複数箇所にある、後で読み返した時に理解しづらいと感じた時に使います。
コピペ用テンプレート
【対象ファイル・関数】を、動作を変えずにリファクタリングしてください。
目的：可読性・保守性の向上
範囲：【対象範囲を明記】
変更後、何をどう変えたか、なぜその変更が良いのかを説明してください。
動作が変わるリスクがある箇所があれば、必ず教えてください。
指示のポイント 「動作を変えずに」と明記することで、機能変更とリファクタリングが混ざることを防げます。
注意点 テストがない状態でのリファクタリングは、見た目はきれいになっても動作が変わってしまうリスクがあります。可能であれば事前に簡単な動作確認の方法を用意しておきましょう。
失敗例
最初の指示：「リファクタリングしてください」とだけ伝えて、対象範囲を指定せずに依頼したことがありました。
結果：価格取得処理だけを直してほしかったのに、関係のないニュース分析側のコードまで「ついでに」整理されてしまい、差分が大きくなって確認に時間がかかりました。
原因：対象範囲を明確に指定していなかったことが原因でした。
実践例（成功した使い方）
状況：以降は「価格取得処理のファイルのみ、動作を変えずに」のように範囲を明確に指定するようにしました。
Claude Codeの回答：変更箇所が指定したファイルのみに限定され、差分も小さくまとまった状態で返ってきました。
判断できたこと：差分が小さく安全な変更だと判断でき、その日のうちにそのまま取り込めました。
ワンポイント リファクタリング前に対象範囲の動作確認方法を決めておくと、変更後の検証がスムーズです。
5. Gitコミットメッセージを作成してもらう指示
用途 変更内容に対して、わかりやすく規約に沿ったコミットメッセージを作成してもらうための指示です。
使うタイミング コミットする直前、複数の変更をまとめてコミットする時に使います。
コピペ用テンプレート
以下の変更内容（git diff）をもとに、コミットメッセージを作成してください。
【git diffの内容、または変更の概要】
条件：
・形式：【例：Conventional Commits（feat / fix / refactor など）】
・1行目は変更内容が一目でわかる簡潔な要約
・必要であれば本文に変更の理由も記載
指示のポイント diffの内容、もしくは変更点の具体的な説明を渡すことが前提です。情報がないと、抽象的なメッセージしか作れません。
注意点 「コミットメッセージ作って」だけでは、何を変更したか伝わらず的外れな内容になりがちです。差分や変更点は必ず添えましょう。
実践例
状況：開発日記として毎日の作業を記録する関係で、こまめにコミットする必要がありましたが、毎回メッセージを考えるのが地味な負担でした。
Claude Codeの回答：diffを渡すと「feat: 価格データのJSON出力にタイムスタンプ項目を追加」のように、変更内容を一言で要約した上で、本文に変更理由まで添えてくれました。
判断できたこと：コミット履歴を見返すだけでその日にやったことが振り返れるようになり、記事を書く時の材料探しが楽になりました。
ワンポイント diffだけでなく「なぜこの変更をしたか」を一言添えると、より文脈のわかるメッセージになります。
6. 次の開発フェーズを提案してもらう指示
用途 現状を整理した上で、次に取り組むべきことを提案してもらうための指示です。
使うタイミング ひとつの実装が完了した直後、次に何をすべきか方向性に迷った時に使います。
コピペ用テンプレート
現在の開発状況は以下の通りです。
【現状（完了したこと・今ある機能）】
【最終的なゴール】
【制約（時間・スキル・予算など）】
この状況を踏まえて、次にやるべきことをいくつか提案してください。
それぞれの選択肢について、メリット・デメリット、想定される難易度も教えてください。
指示のポイント ひとつの答えだけでなく、複数の選択肢とその比較を求めるのがポイントです。判断材料が増え、自分で意思決定しやすくなります。
注意点 提案された内容をそのまま採用するのではなく、自分の時間やスキルに本当に合っているかを必ず自分で判断しましょう。
実践例
状況：価格データの取得・保存までが完成した段階で、次にニュース分析と価格分析のどちらを先に作るべきか迷っていました。
Claude Codeの回答：「ニュース分析を先に作る場合」「価格分析を先に作る場合」の2パターンで、必要な作業量とリスクを比較して提示してくれました。
判断できたこと：平日1〜2時間という自分の作業時間でも進めやすいのは価格分析側だと判断し、そちらを先に着手することにしました。
ワンポイント 「制約（時間・スキルなど）」を具体的に伝えるほど、現実的な提案が返ってきます。
バグ調査
7. バグ調査を依頼する指示
用途 発生しているエラーや想定外の動作について、まず原因を特定してもらうための指示です。
使うタイミング バグが発生したが原因がすぐにわからない時、修正前に状況を整理したい時に使います。
コピペ用テンプレート
以下のバグについて、原因を調査してください。まだ修正はしないでください。
【発生している問題】
・期待する動作：
・実際の動作：
・再現手順：
・エラーメッセージ（あれば）：
考えられる原因を、可能性が高い順にいくつか挙げてください。
それぞれの原因について、どこを確認すれば特定できるかも教えてください。
指示のポイント 「修正して」ではなく「原因を調査して」と分けて依頼するのが最大のポイントです。原因の特定が曖昧なまま修正に進むと、対症療法的な直し方になりがちです。
注意点 再現手順やエラーメッセージを省略すると、的外れな仮説が返ってくることが多くなります。情報はできるだけ具体的に渡しましょう。
実践例
状況：価格データを取得する外部APIからのレスポンスが想定通りに取得できず、DBへの保存処理でエラーが出ました。
Claude Codeの回答：「まだ修正はしないでください」と伝えた上で調査を依頼したところ、可能性のある原因を3つ（レスポンス形式の変更・タイムアウト・文字コード）、確認すべき箇所付きで提示してくれました。
判断できたこと：実際にログを確認すると、最も可能性が高いとされていた「レスポンス形式の変更」が当たっていて、的外れな修正をせずに済みました。
ワンポイント 再現手順は「どんな操作をしたら起きるか」を時系列で書くと、原因の絞り込みが早くなります。
8. エラー内容から原因を調査してもらう指示
用途 実行時に出たエラーログやスタックトレースをもとに、原因を特定してもらうための指示です。
使うタイミング プログラムの実行中にエラーが発生し、エラー文だけでは原因がすぐにわからない時に使います。
コピペ用テンプレート
以下のエラーが発生しました。原因を調査してください。
【エラー内容（全文をそのまま貼る）】
【実行環境】
・言語・バージョン：
・関連ライブラリ：
・実行したコマンドや操作：
考えられる原因と、確認すべき箇所を教えてください。
指示のポイント エラー文は要約せず、全文をそのまま貼るのが基本です。一部を省略すると、重要な手がかりが失われることがあります。
注意点 環境情報（バージョンなど）を伝えないと、的外れな原因を提示されることがあります。環境差によるエラーは特に情報量が重要です。
失敗例
最初の指示：エラーメッセージの一部だけをコピーして、「このエラーの原因を教えてください」と聞いたことがありました。
結果：情報が少なすぎたため、「一般的な原因としては〜」という一般論しか返ってきませんでした。
原因：エラー文を全文貼らず、実行環境の情報も伝えていなかったことが原因でした。
実践例（成功した使い方）
状況：エラー全文と実行環境（言語のバージョン、使用しているライブラリ）をすべて貼って、改めて調査を依頼しました。
Claude Codeの回答：ライブラリのバージョン差によって引数の渡し方が変わっていることが原因だと、具体的に特定して提示してくれました。
判断できたこと：ライブラリのバージョンを固定する対応で解決できると判断でき、調査にかける時間を減らせました。
ワンポイント エラー文は要約せず全文を貼ること。環境情報（バージョンなど）も忘れずに伝えると精度が上がります。
ドキュメント作成
9. READMEやドキュメントを作成してもらう指示
用途 プロジェクトの説明書やセットアップ手順書を作成・更新してもらうための指示です。
使うタイミング プロジェクトを公開・共有する前、しばらく経って手順が古くなっている時に使います。
コピペ用テンプレート
このプロジェクトのREADMEを作成（または更新）してください。
想定読者：【例：このコードを初めて触る自分自身、または引き継ぐ人】
含めてほしい項目：
・プロジェクトの概要
・セットアップ手順
・使い方
・ディレクトリ構成
・注意点（あれば）
実際のコードの内容に基づいて書いてください。想定や一般論での記述は避けてください。
指示のポイント 「実際のコードに基づいて」と指定することで、もっともらしいが実態と異なる説明文が生成されるのを防げます。
注意点 既存のREADMEがある場合は、ゼロから書き直すのではなく「差分を更新してください」と伝えると、不要な情報の消失を防げます。
失敗例
最初の指示：「READMEを作ってください」とだけ依頼したことがありました。
結果：技術的に詳しすぎる内容になり、数週間後に見返した自分にとっても少し読みにくいものになりました。
原因：想定読者を指定していなかったことが原因でした。
実践例（成功した使い方）
状況：「想定読者は数週間後の自分自身」と明記して依頼し直しました。
Claude Codeの回答：セットアップ手順や注意点が簡潔にまとまり、見返した時にすぐ理解できる内容で返ってきました。
判断できたこと：想定読者を明示するだけで、ドキュメントの実用性が大きく変わると実感できました。
ワンポイント 既存のREADMEがある場合は「差分を更新してください」と伝えると、過去の情報が消えずに済みます。
記事作成
10. 変更内容を記事用にまとめてもらう指示
用途 実装した内容や進捗を、note記事などのアウトプット用に要約してもらうための指示です。
使うタイミング 機能追加やバグ修正が一区切りついた時、開発の進捗を記録・発信したい時に使います。
コピペ用テンプレート
今回行った以下の変更内容を、note記事用に要約してください。
【変更内容】
条件：
・初心者にもわかりやすい言葉で
・技術的に誇張のない、正確な表現で
・うまくいった点だけでなく、つまずいた点や工夫した点も含める
・「〜ができるようになりました」のような完成形の宣言ではなく、検証中のニュアンスを残す
指示のポイント 「誇張しないでください」と明示するのが重要です。AIは成果を実際より大きく書く傾向があるため、事前に歯止めをかけておくと修正の手間が減ります。
注意点 出てきた文章をそのまま使うのではなく、実際の体感（不安だった部分、地味だった作業など）を自分の言葉で補うと、記事としての説得力が増します。
実践例
状況：開発日記シリーズの記事を書く際、その日にやったことを記事用にまとめる必要がありました。
Claude Codeの回答：変更内容を渡すと、初心者向けの言葉で要約しつつ、「〜ができるようになりました」という言い切りを避けた、検証中のニュアンスを残した文章を返してくれました。
判断できたこと：そのまま下書きとして使える文章量があり、自分はそこに実際に感じた不安な部分を加えるだけで記事を仕上げられると判断できました。
ワンポイント 出てきた文章はそのまま使わず、自分が感じた不安や工夫した点を一言加えると、記事としての説得力が増します。
私のおすすめの使い方
テンプレートは単体で使うよりも、組み合わせて使うことで価値が高まります。AI仮想通貨トレーダーの開発では、だいたい次のような流れで使っています。
Step1：プロジェクト全体を把握（テンプレート1） 作業を始める前に、現状を整理してもらいます。
↓
Step2：仕様整理（テンプレート2） 触る予定の機能について、現在の仕様を確認します。
↓
Step3：機能追加を依頼（テンプレート3） 影響範囲を確認した上で、実装を進めてもらいます。
↓
Step4：バグ調査・原因調査（テンプレート7・8） エラーが出た場合は、修正の前に必ず原因調査だけを依頼します。
↓
Step5：リファクタリング（テンプレート4） 必要であれば、範囲を絞って整理してもらいます。
↓
Step6：コミットメッセージ作成（テンプレート5） 変更内容を記録します。
↓
Step7：変更内容を記事化（テンプレート10） その日の作業を、開発日記用の文章としてまとめてもらいます。
↓
Step8：次フェーズを相談（テンプレート6） 次に何をすべきか方向性を確認し、Step1に戻ります。
この流れを一通り回すと、「実装→記録→発信」までが一つのサイクルとして自然に回るようになりました。テンプレートを個別に使うより、この組み合わせを意識した方が、結果的に開発も記事執筆も安定する感覚があります。
まとめ
テンプレートを使う上で、特に意識したいコツが4つあります。
いきなり実装させない 最初から「作って」と頼むと、前提のズレに気づかないまま実装が進んでしまうことがあります。
まず調査・整理を依頼する 現状把握や原因調査を先に行うことで、的外れな修正や実装を防げます。
変更前に方針を確認する 「実装前に影響範囲を教えてください」のように、一度立ち止まって確認する一文を入れると、後からの手戻りが減ります。
実装後に変更内容をまとめてもらう 作業が終わったら、変更点を要約してもらう習慣をつけると、振り返りや記事化がスムーズになります。
Claude Codeは「指示した分だけ正確に動く」ツールです。今回のテンプレートを起点に、自分の開発スタイルに合わせて少しずつアレンジしていってもらえればと思います。
今後追加予定のテンプレート
このテンプレート集は、今後も実際の開発で使いながら増やしていく予定です。現時点で追加を検討しているものは以下の通りです（あくまで予定です）。
開発関連
テストコード作成
コードレビュー依頼
API設計
DB設計
パフォーマンス改善
Pull Requestレビュー
リリース前チェック
AI活用
AI記事作成
SNS運用
X投稿作成
将来的には30〜50個程度まで増やし、開発・バグ調査・ドキュメント作成・AI活用・記事作成・SNS運用といったカテゴリごとに整理していく予定です。テンプレートが増えたタイミングで、随時このページに追記していきます。
