Claude Codeのプロンプト完全ガイド【2026年最新】：CLAUDE.md・システムプロンプト・ベストプラクティスまで徹底解説

この記事を読むと、Claude Codeでのプロンプトの書き方、CLAUDE.mdの活用、システムプロンプトのカスタマイズ方法が一通り理解できます。「なんとなく使っている」から「意図通りに動かせる」レベルに上がりたい方に向けた内容です。

室谷代表取締役

今回はClaude Codeのプロンプトについて深掘りしましょう。これ、.AI（ドットエーアイ）コミュニティでもよく聞かれるんですよね。

「Claude Codeへのプロンプト、どう書けばいいんですか？」って。

テキトー教師DotAI 認定講師

わかります。講座でも「Claude Codeのプロンプトって何を書けばいいんですか？」が初日の定番質問です。

でも実は、Claude Codeのプロンプトって「ChatGPTに送るメッセージ」とは根本的に意味が違うんですよ。

室谷代表取締役

そうなんですよね。一般的なチャットAIへの「お願い文」じゃなくて、もっと複雑な構造になってる。

大きく分けると「チャットで打ち込むプロンプト」「CLAUDE.md（プロジェクト設定ファイル）」「システムプロンプト」の3層があって・・・

テキトー教師DotAI 認定講師

そこを最初に整理しておくのが大事ですよね。コミュニティのメンバーさんが混乱するのって、この3つを同じもの扱いして考えてしまうからだと思いますよ。

今日はその構造から丁寧に解説していきましょう。

Claude Codeのプロンプト構造：3つの層を理解する

室谷代表取締役

まずClaude Codeのプロンプト構造を整理しましょうか。Claude Codeって、実は3種類の「指示経路」があるんですよね。

テキトー教師DotAI 認定講師

そうですね。「Claude Code プロンプト」と一口に言っても、整理すると、こういう構造です。

チャットプロンプト: ターミナルやWebで直接打つ一回限りの指示
CLAUDE.md: プロジェクト（またはユーザー）ごとに永続する設定ファイル
システムプロンプト: Claude Code本体が内部で持つ基盤プロンプト（カスタマイズ可能）

室谷代表取締役

で、面白いのがCLAUDE.mdの動き方なんですよね。これ、最初に1回読まれるだけじゃないんですよ。

テキトー教師DotAI 認定講師

ここ、ほんとに重要なポイントです。先月、Claude Codeのソースコードが流出したとき、コミュニティで一番盛り上がった発見がここでしたよね。

室谷代表取締役

そうなんです。流出コードの分析から「CLAUDE.mdは毎ターン、システムプロンプトとして再注入される」ことが判明してて。

つまりどんなに長い会話でもCLAUDE.mdの内容は忘れられない・・・

テキトー教師DotAI 認定講師

これは教える立場からすると、かなりインパクトのある話でした。「長い会話でClaude Codeが指示を忘れる」ってよく言われるんですけど、CLAUDE.mdの内容については忘れにくい設計になってるということですね。

室谷代表取締役

ただ、逆に言うとCLAUDE.mdが長ければ長いほど、消費トークンが増えるんですよ。文字数 × 会話ターン数 = コスト、という計算式になる。

もっともプロンプトキャッシュで実コストはかなり軽減されますが・・・

テキトー教師DotAI 認定講師

だからこそ「何をCLAUDE.mdに書くか、何を書かないか」の取捨選択が重要なんですよね。ここが一番の設計思想です。

チャットプロンプトと永続設定の違い

室谷代表取締役

チャットプロンプトは「1セッション内の会話」として扱われます。次のセッションには引き継がれないし、コンテキストウィンドウが埋まったら圧縮・省略される。

テキトー教師DotAI 認定講師

一方、CLAUDE.mdは毎セッションの冒頭で読み込まれる。だから「このプロジェクトでは常にこれを守ってほしい」ということはCLAUDE.mdに書く、「この作業だけお願いしたい」ことはチャットで打つ、と使い分けるのが基本ですね。

室谷代表取締役

MYUUUだと全プロジェクトのCLAUDE.mdに最低限の設定（コーディング規約、テストの走らせ方、よく使うパス）を入れてます。それ以外は都度チャットで指示する形ですね。

テキトー教師DotAI 認定講師

「毎回同じことを説明している」と気づいたらCLAUDE.mdに移す、という判断基準がわかりやすいですよね。

チャットプロンプトの書き方：具体的で効果が出る指示の作り方

Claude Code Best Practicesページ：具体的なプロンプト戦略の解説（公式サイトより）

室谷代表取締役

じゃあ実際のプロンプトの書き方に入りましょう。公式のベストプラクティスとして「Provide specific context in your prompts（プロンプトには具体的なコンテキストを入れる）」というのがあって・・・

テキトー教師DotAI 認定講師

これ、当たり前に聞こえるんですけど、実際にできていない人が多いんですよ。コミュニティのメンバーさんのプロンプトを見ていると、「バグを直して」「テストを書いて」みたいな漠然とした指示になってることが多い。

室谷代表取締役

具体的には、公式ドキュメントに4つのパターンが紹介されていますね。

パターン	NG例	OK例
ファイル・スコープを指定	「foo.pyのテストを書いて」	「foo.pyのログアウト状態のエッジケースをテストして。モックは使わないで」
根拠を示す	「ExecutionFactoryってなんでこんなAPIなの？」	「ExecutionFactoryのgit履歴を見て、APIがどう進化したか教えて」
既存パターンを参照	「カレンダーウィジェットを追加して」	「HotDogWidget.phpのパターンを参考に、月選択・年の前後移動ができるカレンダーウィジェットを作って」
症状と期待値を伝える	「ログインのバグを直して」	「セッションタイムアウト後にログインが失敗する。src/auth/のトークンリフレッシュを確認して。失敗するテストを先に書いてから修正して」

テキトー教師DotAI 認定講師

この表、講座でよく使うんですが、一番効くのが「症状と期待値を伝える」パターンですね。「バグ直して」じゃなくて「この症状が出ていて、こうなれば解決」という形式。

室谷代表取締役

Claude Codeって「コードを読む→計画する→実行する」の順で動くので、目的地が明確だと効率が全然違うんですよね。曖昧だとあちこち探索して無駄なトークンを消費することもある・・・

テキトー教師DotAI 認定講師

あと見落としがちなのが「検証手段を与える」こと。公式ドキュメントで「最もレバレッジが高い一手」として挙げられているんですよね。

室谷代表取締役

そうなんです。「テストがある」「スクリーンショットで確認できる」「この出力になれば成功」という検証基準を渡すと、Claudeが自分でチェックしながら進められる。

人間がフィードバックループに入る必要がなくなるんですよね。

テキトー教師DotAI 認定講師

整理すると、検証手段を渡すパターンはこうなりますね。

UIの変更 → 「スクリーンショットを撮って元のデザインと比較して、違いを直して」
ロジックの実装 → 「実装後にこのコマンドを実行して、全テストが通ることを確認して」
バグ修正 → 「まず失敗するテストを書いてから修正して、エラーを握りつぶさず根本原因を直して」

室谷代表取締役

MYUUUのエンジニアには「Claudeに検証手段を渡すのが仕事の一部」と言ってます。そこを省略すると、結局人間が確認ループに入ることになって時間が変わらない・・・

マルチライン入力とプロンプトエディタの使い方

テキトー教師DotAI 認定講師

あと地味に大事なのが、複数行のプロンプトをどう入力するか問題ですね。CLIで複数行入力する場合は、Escapeキーを押してからEnterで改行できます。

室谷代表取締役

または --print フラグを使う方法もありますね。

テキトー教師DotAI 認定講師

エディタで書いてからCLIに渡したい場合は、EDITOR 環境変数を設定しておくとVimやVSCodeで長いプロンプトを書いてから実行できます。

室谷代表取締役

ファイルからプロンプトを読み込む使い方も実用的なパターンです。

bash

# ファイルからプロンプトを読み込む
claude -p "$(cat my-prompt.md)"

# または非対話モードで
claude --print "$(cat my-prompt.md)"

テキトー教師DotAI 認定講師

繰り返し使うプロンプトはファイル管理しておくと便利ですよね。これって実はSkillsとも近い話になってくるんですが・・・

室谷代表取締役

そうですね。同じプロンプトを何度も使うならSkillsに昇格させた方がいい。

でもとりあえず試したい段階ではファイルから読み込む形が手軽です。

CLAUDE.mdの書き方：プロジェクトに永続する設定ファイルを作る

Claude Code公式ドキュメント：CLAUDE.mdとオートメモリの仕組みの解説ページ（公式サイトより）

室谷代表取締役

CLAUDE.mdはClaude Codeで一番重要な「永続設定」ですね。毎セッション冒頭で読み込まれて、Claudeの行動を規定する。

テキトー教師DotAI 認定講師

公式の定義だと「Claudeにプロジェクト・個人ワークフロー・組織全体の指示を渡すMarkdownファイル」ということですね。置く場所によってスコープが変わる。

室谷代表取締役

配置場所と用途を整理すると、こうなります。

スコープ	場所	用途
組織全体	macOS: `/Library/Application Support/ClaudeCode/CLAUDE.md`	IT/DevOpsが管理するポリシー
プロジェクト	`./CLAUDE.md` または `./.claude/CLAUDE.md`	チームで共有する設定
ユーザー全体	`~/.claude/CLAUDE.md`	個人の全プロジェクト共通設定
プロジェクト個人	`./CLAUDE.local.md`	.gitignore推奨の個人設定

テキトー教師DotAI 認定講師

この階層構造を理解してる人、実はそんなに多くないんですよね。「CLAUDE.mdってプロジェクトのルートに1つ置くもの」だと思ってる人が多い。

室谷代表取締役

ユーザーレベルの ~/.claude/CLAUDE.md は全プロジェクトに効くので、「自分は常にこのコーディングスタイルで書いてほしい」という個人の好みをここに書くと便利です。MYUUUだと個人レベルで「TypeScript型定義は明示的に書く」とか「コミットメッセージは英語で」とか入れてる人もいます。

CLAUDE.mdに書くべきこと・書かないこと

テキトー教師DotAI 認定講師

CLAUDE.mdで最もよくある失敗が「書きすぎ」なんですよ。公式も「200行以内を目標に」と明記していて。

室谷代表取締役

CLAUDE.mdは毎ターン再注入されるから長いほどトークン消費が増える。でも長くなる理由はたいてい「本来書かなくていいことを書いてる」からなんですよね・・・

テキトー教師DotAI 認定講師

公式が示している基準が明快で参考になります。

書くべき内容:

Claudeが自分で推測できないBashコマンド（ビルドコマンド、テスト実行コマンド）
デフォルトから外れるコードスタイルのルール
テスト手順と優先するテストランナー
リポジトリのルール（ブランチ命名規則、PR規約）
プロジェクト固有のアーキテクチャの決定事項
開発環境の特殊設定（必須の環境変数など）

書かないべき内容:

Claudeがコードを読めばわかること
標準的な言語の慣習（Claude自身が知っている）
詳細なAPIドキュメント（リンクだけ貼れば十分）
頻繁に変わる情報
長い解説や説明文
「クリーンなコードを書く」などの自明な話

室谷代表取締役

各行に「これを消したらClaudeが間違いを犯すか？」と問いかけて、NOならカットする、というシンプルな判断基準が良いですよね。

テキトー教師DotAI 認定講師

「IMPORTANT」や「YOU MUST」を使うと遵守率が上がるというのも公式で触れられていますね。どうしても守ってほしいルールは強調する価値があります。

/initコマンドでCLAUDE.mdを自動生成する

テキトー教師DotAI 認定講師

CLAUDE.mdを1から書くのが大変な人には、/init コマンドが便利です。Claude Codeがコードベースを分析して、ビルドシステム・テストフレームワーク・コードパターンを検出して雛形を生成してくれます。

室谷代表取締役

/init は既存のCLAUDE.mdがあっても動くんですよ。既存ファイルがあれば上書きせずに「改善案を提案してくれる」モードになる。

完全に1から書くよりも、まずこれで基本を生成して手を加えるのが効率的ですね。

テキトー教師DotAI 認定講師

CLAUDE_CODE_NEW_INIT=1 という環境変数を設定すると、インタラクティブな多段階フローが使えます。CLAUDE.md・Skills・Hooksのどれをセットアップするか選んで、コードベース分析→追加質問→提案レビューという順で丁寧に作ってくれる。

室谷代表取締役

新しいプロジェクトを始めるときは必ずまず /init を走らせる、というフローにするといいですよね。

@インポート構文でCLAUDE.mdをモジュール化する

Claude Code公式ドキュメント：.claude/rules/ディレクトリによるルール分割の解説（公式サイトより）

テキトー教師DotAI 認定講師

プロジェクトが大きくなると、CLAUDE.mdが肥大化してくる問題があって。そのための解決策が @インポート 構文です。

室谷代表取締役

@path/to/file という形式で外部ファイルを参照できます。まとめると、こんな書き方になります。

markdown

# CLAUDE.md

プロジェクト概要は @README を参照。

# コーディングガイドライン
@docs/coding-guide.md

# テスト規約
@docs/testing.md

テキトー教師DotAI 認定講師

インポートはネストで最大5段階まで使えます。大規模チームの場合は .claude/rules/ ディレクトリを使う方法もあって、トピックごとにファイルを分割できる仕組みです。

例えば frontend.md、backend.md、testing.md という形でテーマ別に管理できる。

室谷代表取締役

さらにパス指定で「このファイルを編集するときだけこのルールを読み込む」という細かい制御もできます。巨大プロジェクトだとこの粒度の設定が効いてくるんですよね。

テキトー教師DotAI 認定講師

AGENTS.mdを使っている他のAIエージェントとの共存も考えられていて、CLAUDE.mdから @AGENTS.md をインポートすれば両方のツールが同じルールを読める。実際の業務では複数のAIツールを使うことが多いので、これは地味に便利ですよ。

システムプロンプトとカスタマイズ：--append-system-promptの使い方

室谷代表取締役

次はシステムプロンプトの話をしましょうか。「claude code system prompt」「claude code custom system prompt」で調べている人が多いんですよね。

テキトー教師DotAI 認定講師

そうですね。Claude Codeの内部システムプロンプトはAnthropicが公開していない、というのが公式の立場です。

「Claude Code's internal system prompt is not published.」と明記されてます。

室谷代表取締役

でも、カスタマイズする手段が提供されていて。--append-system-prompt フラグを使うと、内部システムプロンプトの末尾に追記できます。

bash

# CLIオプションでシステムプロンプトに追記
claude --append-system-prompt "常に日本語で回答してください。コードにはコメントを付けてください。"

テキトー教師DotAI 認定講師

CLAUDE.mdと --append-system-prompt の違いで混乱する人が多いんですよ。整理すると、こういう使い分けになります。

方法	特徴	向いている用途
CLAUDE.md	プロジェクト・ユーザーレベルで管理、Gitで共有可能	チームのコーディング規約、アーキテクチャ方針
--append-system-prompt	セッション起動時に指定、フラグで渡す	CI/CDや自動化スクリプトでの一時的な指示

室谷代表取締役

実務でよく使うのは、非対話モードと組み合わせるパターンですね。自動化スクリプトで「このタスクだけ特定の振る舞いをさせたい」ときに --append-system-prompt で渡す。

テキトー教師DotAI 認定講師

一方、プロジェクト全体で共有したい設定はCLAUDE.mdに書く、という役割分担ですよね。

システムプロンプトの流出と「何が書かれているか」

室谷代表取締役

Claude Codeのソースコード流出で、実は内部システムプロンプトの構造についてかなり詳しいことが判明してて。

テキトー教師DotAI 認定講師

これ、興味深い話ですよね。公開はされてないけど、研究者やコミュニティの分析で「こういう構造らしい」という知見が出てきてる。

室谷代表取締役

流出コードから判明した主要な設計思想として、「never delegate understanding（理解していないタスクをサブエージェントに丸投げするな）」という指示が内部に含まれていることがわかってます。これが最近のアップデートで追加された。

テキトー教師DotAI 認定講師

この「理解してから委任する」原則は、教える立場から見ると非常に理にかなってます。自分が内容を把握していない状態でサブエージェントに振ると、エラーが重なって全体が崩壊することがある。

室谷代表取締役

そうなんですよ。エージェントが「わからないまま委任→サブエージェントも的外れ→手戻り」というループにはまる問題を防ぐための設計思想ですね・・・

プロンプトキャッシング：コスト削減の重要なメカニズム

室谷代表取締役

「claude code prompt caching」「claude code disable prompt caching」で調べている人も多いので、プロンプトキャッシングについても触れておきましょう。

テキトー教師DotAI 認定講師

CLAUDE.mdが毎ターン再注入されるとコストが心配になりますよね。でも実はプロンプトキャッシングで実コストはかなり抑制されてます。

室谷代表取締役

Anthropicの公式ドキュメントによると、プロンプトキャッシングには2種類の方法があります。

自動キャッシング（Automatic caching）:

リクエストのトップレベルに cache_control フィールドを1つ追加するだけ
会話履歴が増えていくと自動的に最適なキャッシュポイントに適用
マルチターンの会話に向いている

明示的なキャッシュブレークポイント（Explicit cache breakpoints）:

個別のコンテンツブロックに直接 cache_control を配置
キャッシュする部分を細かく制御したいときに使う

テキトー教師DotAI 認定講師

CLAUDE.mdの場合、内容が変わらない限りキャッシュが効くんですよね。だからCLAUDE.mdは「安定した内容」を書くべきで、頻繁に変わる情報を入れるとキャッシュが無効化されてコスト増になる。

室谷代表取締役

なるほど、「頻繁に変わる情報はCLAUDE.mdに書かないべき」という原則の理由がここにもあるんですよね。キャッシュ効率が落ちるから。

テキトー教師DotAI 認定講師

ちなみに claude code disable prompt caching を調べている人は、APIを直接使っていてキャッシュをオフにしたいケースが多いと思います。パフォーマンスの計測や、特定の条件でキャッシュを使いたくない場合ですね。

室谷代表取締役

API利用の場合、キャッシュの有効期間は1時間です。同じプロンプトを1時間以内に繰り返し送ると、入力トークンのコストが大幅に削減できる。

詳しくはAnthropic公式のプロンプトキャッシングドキュメントに料金計算が書いてあります。

「プロンプトが長すぎる」エラーの対処法

テキトー教師DotAI 認定講師

「claude code prompt is too long」「claude code prompt too long」で検索してる人も多いので、これも解説しておきましょう。

室谷代表取締役

これ、コンテキストウィンドウが埋まったときに出るエラーですよね。Claude Codeが扱えるコンテキスト量には限界があって、その上限に達すると起きる。

テキトー教師DotAI 認定講師

具体的な対処法が複数あります。

対処法1: /compact コマンドを使う

コンテキストを圧縮して整理します。会話の重要部分は維持しつつ、不要な詳細を省略してくれます。

対処法2: 新しいセッションを開始する

長くなった会話をいったん終了して、必要な情報だけ伝えながら新しいセッションを始める方法です。

対処法3: CLAUDE.mdで不要な内容をそぎ落とす

CLAUDE.mdが肥大化している場合は、必要なルールだけに絞り込む。

室谷代表取締役

「claude code web prompt is too long」というのは、WebブラウザのClaude Codeインターフェースで起きる問題ですね。ブラウザ版でもコンテキスト上限は同じなので、長いプロンプトを一度に入力しようとすると引っかかることがある。

テキトー教師DotAI 認定講師

実際の業務でよくあるパターンが「大きいファイルを丸ごと読ませようとして詰まる」というやつです。特定のファイルやディレクトリを事前に確認しながら作業するのが良いですよね。

室谷代表取締役

公式ドキュメントの「Explore the context window」ページに、セッション開始時に何がコンテキストに入っているかをインタラクティブに可視化するウォークスルーが公開されています。コンテキスト管理を真剣にやるなら一度見ておく価値がありますよ。

テキトー教師DotAI 認定講師

カスタムステータスラインを設定して、コンテキスト使用量をターミナルに常時表示させる方法もあります。これを入れておくと使いすぎを事前に防げますよね。

再利用可能なプロンプトの管理：Skillsとプロンプトライブラリ

室谷代表取締役

「claude code reusable prompts」「claude code prompt library」「claude code prompt templates」というKWがあって、繰り返し使うプロンプトをどう管理するかの話ですね。

テキトー教師DotAI 認定講師

ここはSkillsの出番です。Skillsは「カスタムコマンドで呼び出せるプロンプトテンプレート」で、 /review-pr や /deploy-staging のような繰り返しワークフローをパッケージ化できます。

室谷代表取締役

Skillsは .claude/skills/ ディレクトリにMarkdownファイルとして保存します。ファイル名がそのままコマンド名になる形ですね。

markdown

# .claude/skills/code-review.md

コードレビューを実施してください。以下の観点でチェックしてください：

1. バグやエラーハンドリングの漏れ
2. パフォーマンス上の問題
3. セキュリティ上のリスク
4. コードの可読性と保守性
5. テストカバレッジ

レビュー結果をMarkdown形式で出力してください。

テキトー教師DotAI 認定講師

こうしておくと /code-review と入力するだけで呼び出せる。コミュニティのメンバーさんに教えると「これ便利すぎる！」ってなるやつですよね（笑）

室谷代表取締役

CLAUDE.mdとSkillsの使い分けも大事ですね。CLAUDE.mdは「常に適用されるルール」、Skillsは「呼び出したときだけ使うテンプレート」。

コンテキストに常駐させたくない重めの指示はSkillsに切り出すのが賢い設計です。

テキトー教師DotAI 認定講師

チームで共有するプロンプトライブラリとして使う場合も、Gitリポジトリで .claude/skills/ を管理すれば全員が同じコマンドを使えるようになります。

室谷代表取締役

「claude code prompts github」で検索してる人は、GitHubで他の人のSkillsや設定を参考にしたいんだと思います。実際コミュニティでも「うちのチームのCLAUDE.md公開してみました」みたいな投稿がよく出ますよね。

テキトー教師DotAI 認定講師

そういうの見ると「こういう書き方があるのか」って学びになりますよね。プロンプトエンジニアリングは属人化しがちなので、チームで共有することに価値があります。

プロンプトエンジニアリングの実践：Claude Codeに特化したベストプラクティス

室谷代表取締役

「claude code prompt engineering」「claude code prompt engineering best practices」というKWも多いので、Claude Code固有のプロンプトエンジニアリングのポイントを整理しましょう。

テキトー教師DotAI 認定講師

一般的なLLMプロンプトエンジニアリングとClaude Code向けの書き方って、実はかなり違うんですよね。チャットと違ってClaude Codeはエージェントとして動くので。

室谷代表取締役

大きな違いが3つあります。

1. 「探索→計画→実行」を分けて指示する

いきなり「これ全部実装して」という大きな指示より、最初はPlanモードで計画だけ出させるアプローチが効果的です。shift + tab でPlanモードに切り替えると、Claudeは実装せずに計画書を出すだけになる。計画を確認してから実装を承認する流れが安全です。

2. コードベース探索の指示を先に出す

「このバグを直して」と言う前に「まず関連するファイルを探してリストアップして」と言う。先に地図を作ってもらってから実装に入る形ですね。

3. 「なぜ」を添える

指示の意図を伝えると品質が上がります。「テストにモックを使わないで（なぜなら統合テストを重視しているから）」という形ですね。

テキトー教師DotAI 認定講師

3番目の「なぜを添える」は、教える立場から言うと非常に効果があります。指示の背景を知っているClaudeは、予期しないケースでも意図に沿った判断ができるようになる。

室谷代表取締役

海外の事例でも「意図を伝えたら明らかに品質が変わった」というレポートがよく出てきますよね。単なるルールより「なぜそのルールがあるか」を伝える方が遵守率が高い。

テキトー教師DotAI 認定講師

あとは「探索と実装を混ぜない」というのも大事ですよね。コードベースを調べながら同時に書こうとすると、探索コストでコンテキストが詰まって後半に品質が落ちることがある。

室谷代表取締役

実務では「フェーズ1: 調査（ファイルを読む、コードを把握する）」「フェーズ2: 計画（何を変えるか整理する）」「フェーズ3: 実装（書く）」を明示的に分けてプロンプトするのが効果的ですね。MYUUUでもこのパターンを基本にしてます。

プロンプトの書き方でよくある失敗パターン

テキトー教師DotAI 認定講師

講座でよく見るプロンプトの失敗パターンをいくつか挙げると・・・

失敗1: スコープが大きすぎる

「このアプリ全体をリファクタリングして」という指示は、Claude Codeにとっては「どこから手をつけるかわからない」状態になりがちです。「src/api/handlers/userHandler.tsのエラーハンドリングを整理して」のように具体的なスコープを示す方が良い結果が出ます。

失敗2: 制約を後から追加する

最初に「ログイン機能を実装して」と言ってから「あ、このライブラリは使わないで」「ファイル構造はこうして」と後から条件を追加すると、手戻りが発生しやすい。最初から全条件を伝える方が効率的です。

失敗3: 完了定義が曖昧

「いい感じに整理して」「ちゃんと動くようにして」という指示は、Claudeが「完了」の判断をしにくい。「このテストが全部通れば完了」「このコマンドの出力がXXになれば完了」という明確な完了条件を付けることが重要です。

室谷代表取締役

この3つの失敗パターン、うちのチームでも最初は全部やってましたよ（笑）。試行錯誤して「プロンプトの書き方自体が仕事のスキル」だと気づいてから改善しました。

テキトー教師DotAI 認定講師

プロンプトを「書いて終わり」ではなく「改善していくもの」として捉えるといいですよね。CLAUDE.mdと同じように、使いながらアップデートしていく。

Skillsを使ったプロンプト自動化：カスタムコマンドの実際

室谷代表取締役

「claude code prompt skill」「claude code custom prompts」という話で、Skillsを実際にどう活用するかをもう少し具体的にやりましょうか。

テキトー教師DotAI 認定講師

Skillsって概念を知っていても「具体的にどんなSkillsを作るといいか」がわからない人が多いんですよね。

室谷代表取締役

実際に効果が高いSkillsの例を挙げると・・・ベストなClaude Codeプロンプト（best claude code prompts）として参考にしてほしいのが、こういったパターンです。

コードレビュー系:

/security-review : セキュリティの観点でコードを確認する
/performance-review : パフォーマンスボトルネックをチェックする
/review-pr : PRの差分をレビューして問題点をリストアップする

開発フロー系:

/create-tests : 実装済みコードのテストを自動生成する
/update-docs : コードの変更に合わせてドキュメントを更新する
/commit : ステージングされた変更の適切なコミットメッセージを提案する

プロジェクト管理系:

/deploy-staging : ステージング環境へのデプロイ手順を実行する
/check-deps : 依存パッケージのバージョンを確認して更新が必要なものを提案する

テキトー教師DotAI 認定講師

このリスト、講座で見せると「全部作りたい！」ってなるんですよ（笑）。でも実際は「チームで毎週やっている作業」から始めると効果が高いです。

繰り返し手動でやっていることをSkillsにするのが一番インパクトがある。

室谷代表取締役

MYUUUだと /review-pr と /create-tests が特に効いていますね。PRレビューにかかる時間が体感で半分以下になりました。

テキトー教師DotAI 認定講師

Skillsのプロンプト自体にも品質があって、最初から完璧なのを作ろうとしなくていいです。まずシンプルな版を作って、使いながら「ここをもっと詳しく指示したら良くなった」という改善を重ねていく方が現実的ですね。

オートメモリとセッション間の知識継承

室谷代表取締役

「claude code default system prompt」「claude code global prompt」の話で、セッションをまたいで知識を引き継ぐ「オートメモリ」という機能も紹介しておきましょう。

テキトー教師DotAI 認定講師

CLAUDE.mdは人間が書くもので、オートメモリはClaudeが自分で書くもの。この対比が面白いですよね。

室谷代表取締役

オートメモリはClaude Codeが作業中に「このプロジェクトのビルドコマンドはこれ」「このデバッグパターンで解決した」といった知見を自動的に保存する仕組みです。セッションをまたいでも活用できる。

テキトー教師DotAI 認定講師

保存場所は「ワーキングツリーごと」なんですよね。つまりプロジェクトルートに保存されて、そのプロジェクトで作業するたびに読み込まれます。

室谷代表取締役

/memory コマンドで保存された内容を確認・編集できます。「Claudeが勝手に覚えたこと」を定期的に見直して、間違ったことを覚えていないか確認するのも良いプラクティスですね。

テキトー教師DotAI 認定講師

オートメモリとCLAUDE.mdの使い分けとしては・・・

CLAUDE.md → チームで共有すべき安定したルール
オートメモリ → 個人のワークスタイルや、Claudeが発見した知見

という役割分担になりますね。サブエージェントも独自のオートメモリを持てるので、エージェントチームの場合はそれぞれが知見を蓄積していく設計になっています。

室谷代表取締役

これ、経営的な観点で言うと「AIが自分で学習して組織知識を蓄積していく」という流れなんですよね・・・。人間のナレッジマネジメントに近い話になってきてる。

よくある質問（FAQ）

テキトー教師DotAI 認定講師

よく聞かれる質問をまとめておきましょう。

Q: CLAUDE.mdとプロンプトの違いは何ですか？

室谷代表取締役

CLAUDE.mdは「毎セッション自動的に読み込まれる永続設定」で、チャットプロンプトは「そのセッションの1回限りの指示」です。CLAUDE.mdはプロジェクトの設定ファイルとして考えると整理しやすいですね。

Q: システムプロンプトは見られますか？

テキトー教師DotAI 認定講師

Claude Codeの内部システムプロンプトはAnthropicが公開していないので、直接確認はできません。ただ --append-system-prompt で追記することは可能です。

Q: プロンプトが長すぎてエラーになります

室谷代表取締役

/compact コマンドでコンテキストを圧縮するか、新しいセッションを開始してください。CLAUDE.mdが長すぎる場合は、不要な内容を削って200行以内に収めることをおすすめします。

Q: チームで同じプロンプトを共有したい

テキトー教師DotAI 認定講師

.claude/skills/ にSkillsファイルを作ってGitで管理するのが一番スムーズです。CLAUDE.mdも .claude/settings.json もGitで共有できます。

CLAUDE.local.md だけは個人設定なのでGitignoreに入れておきましょう。

Q: プロンプトを改善したいが何から始めれば？

室谷代表取締役

「毎回同じことを伝えているプロンプト」から始めるのがおすすめです。繰り返し使っているものをCLAUDE.mdかSkillsに移していくと、自然にプロンプト品質が上がっていきます。

まとめ

室谷代表取締役

今回のポイントをまとめると、Claude Codeのプロンプトには3つの層がある、という話でしたね。

テキトー教師DotAI 認定講師

「チャットプロンプト」「CLAUDE.md」「システムプロンプト」の3層で、それぞれの役割が違う。ここを理解してから使うと、「なんとなく使う」から「設計して使う」フェーズに移れます。

室谷代表取締役

CLAUDE.mdについては「200行以内」「書くべきことと書かないことの区別」「@インポートでのモジュール化」が実践のポイントです。あとCLAUDE.mdが毎ターン再注入されるという仕組みを知ってからは、書き方の考え方が変わりましたよね・・・

テキトー教師DotAI 認定講師

チャットプロンプトについては「具体的なスコープ」「既存パターンの参照」「検証手段を渡す」の3つが効果的です。繰り返しパターンはSkillsに昇格させて、チームで共有していく。

室谷代表取締役

プロンプトエンジニアリングは「書いて終わり」じゃなくて継続的に改善していくものです。CLAUDE.mdもSkillsも、使いながら育てていくイメージで取り組むのがいいですね。

テキトー教師DotAI 認定講師

次回は実際のSkillsの書き方をもっと深掘りしていきましょう。今回の内容と組み合わせるとワークフローの自動化が格段に進みますよ。

Claude Codeのプロンプト完全ガイド【2026年最新】：CLAUDE.md・システムプロンプト・ベストプラクティスまで徹底解説