「Claude に頼んだら、思っていたのと違う形の答えが返ってきました」
「前は “必ず” と書くとよく守ってくれたのに、最近は融通が利かない気がします」
プロンプトの書き方は、テクニックを覚えるより先に、原則を押さえるのが近道です。しかも Claude は、モデルの世代が変わるたびに指示の受け取り方が少しずつ変わります。
第4回では、Anthropic が公式に示しているプロンプトのベストプラクティスと、2026年9月時点の最新世代（Claude Opus 5.5・Sonnet 5.5。この連載では「5.x 世代」と呼びます）で変わった点を確かめます。後半では、よく使う指示を一度だけ書いておく場所と、筆者が使っている調査・事実確認の共通ルール、インフラの仕事で使う6つのひな形を紹介します。
明確に、背景と理由を添える
公式のプロンプトのベストプラクティスは、Claude を「優秀だが、社内の事情を知らない新入社員」と考えるよう勧めています。
原則は「事情を知らない同僚が読んで迷うなら、Claude も迷う」です。
- 何のための作業か、誰が読むのか、どんな制約があるのかを書く
- 期待以上の成果が欲しいなら、それも明示する
- 指示には理由を添える
理由の効き目は大きく、たとえば「省略記号を使うな」とだけ書くより、「音声で読み上げるので省略記号は使わない」と書くほうが、Claude は意図をくみ取り、似た場面にも正しく応用します。インフラの作業なら「本番環境なので、変更前に必ず差分を見せて」のように、理由とセットで伝えます。
よくある頼み方の直し方
| よくある頼み方 | 足りないもの | 直した例 |
|---|---|---|
| 「nginx の設定を見て」 | 目的・観点・出力の形 | 「来週本番に反映する nginx の設定です。セキュリティと性能の観点で気になる点を、重大度付きの表で挙げてください。ファイルはまだ変更しないでください」 |
| 「手順書を作って」 | 読み手・構成・元の資料 | 「下のメモから、初めてこの作業をする人向けの手順書を作ってください。作業前の確認→手順→確認方法→切り戻しの順にしてください」 |
| 「このエラーの原因は？」 | 環境・状況・分からないときの扱い | 「RHEL 9 の nginx で、10時ごろから 502 が出ています。ログを貼ります。原因の仮説を3つ、根拠の行を引用して挙げてください。分からないことは分からないと書いてください」 |
例示・XMLタグ・長い資料
- 例を見せる：関連があって多様な例を3〜5個。
<example>タグで囲む - XMLタグで分ける：指示・資料・入力をタグで区切る。タグ名は一貫させる（
<document>、<instructions>など、名前は自由） - 長い資料（2万トークン以上）は先頭に置く：質問は最後に書く。公式によると、品質が最大30%上がる
- 引用させる：回答の前に、資料の該当箇所を引用させる
<document>（障害時のログ・設定ファイルを貼る）</document>
<instructions>
上のログから、エラーの原因と思われる行を引用してから、
原因の仮説を3つ挙げてください。本番環境なので、変更案は提案だけにしてください。
</instructions>資料と指示をタグで分けておくと、ログの中に紛れた文を、Claude が指示と取り違えにくくなります。
出力と行動を指示する
- 「〜するな」より「〜せよ」：避けたいことより、してほしいことを書く
- 書式を合わせる：プロンプトの書式を、欲しい出力の書式に合わせる（箇条書きで欲しければ、プロンプトも箇条書きで書く）
- 提案か実行かをはっきりさせる：「提案して」と書くと提案だけで終わる。変更させたいなら「変更して」と書く
- 取り消せない操作は確認させる：削除、force push、外部への投稿の前に確認を求めさせる
- 推測させない：開いていないファイルやコードについて推測しないよう指示する
- 分からなければ分からないと言ってよい：こう伝えると、もっともらしい誤り（ハルシネーション）が減る
特に「提案か実行か」は、ファイルの変更やコマンドの実行ができる Claude Code（第5回）で大事になります。
5.x世代で変わった点
Opus 5.5・Sonnet 5.5 は、以前のモデルより指示を文字どおりに受け取ります。以前の書き方のままだと、効きすぎたり、範囲が狭くなったりします。
| 観点 | 以前のモデルでの書き方 | 5.x世代（Opus 5.5・Sonnet 5.5） |
|---|---|---|
| 指示の範囲 | 1か所に書けば全体に広げてくれた | 書いたとおりにだけ守る。適用範囲を明示する（例：「全セクションに適用」） |
| 強い言い回し | 「CRITICAL」「必ず〜せよ」で強調した | 効きすぎる。普通の言い方で書く |
| 「よく考えて」 | 考えさせるために入れた | Opus 5.5 では不要。削除しても品質は落ちず、応答が速くなる（考える量は Effort で決める。第3回） |
| 絞り込み | 「重大なものだけ」と書いても広めに拾った | 忠実に守るので、レビューで拾う件数が減ることがある |
| 抽象的な指示 | 「AIっぽくしないで」 | 効きにくい。避けたい書き方を具体的に並べる |
| 変わりうる事実 | 知識で答えさせた | 「検索で確認して」と明記する |
以前のモデル向けに入れていた「徹底的にやれ」「迷ったらツールを使え」といった指示は、弱めるか削除します。手元に「プロンプト集」や定型の指示があるなら、一度見直す価値があります。
利用者向けの基本（Claude 101）
Anthropic の学習サイト Claude Academy の入門コース「Claude 101」は、アプリで使う利用者向けに、次の基本を挙げています。
- 読み手・役割・制約・長さを書く：「インフラの初級者向けに、A4で1枚」のように
- 形式は例で示す：表の見出し、見本の1行を添える
- 最初の出力はたたき台：直してほしい点を具体的に伝えて仕上げる
- 話がそれたら新しい会話を始める：長い会話は最初の指示を見失いやすい
- 事実は自分で確かめ、出典を求める：存在しないリンクを出すこともある
- 自分の定型業務5〜10件で試す：どの作業に向くかを自分で確かめる
最後の「自分の業務で試す」は、第3回のモデル選びでも公式が勧めている方法です。記事や評判より、自分の作業での結果がいちばん確かな判断材料になります。
指示を書く場所
同じ指示を毎回貼る代わりに、効く範囲に合わせて書く場所を選びます。
| 場所 | 効く範囲 | 向いている内容 |
|---|---|---|
| Claude アプリの設定の「Claudeへの指示」 | アプリのすべての会話（Chat と Cowork の統合後は Cowork も） | 調べ方・答え方の共通ルール |
| Projects の指示 | そのプロジェクトの会話 | 案件ごとの前提・用語 |
~/.claude/CLAUDE.md | 自分のすべての Claude Code のセッション | 調べ方などの共通ルール |
プロジェクトの CLAUDE.md | そのリポジトリ（Git でチームと共有） | 作業の規約、よく使うコマンド |
| Skills | 関係する作業のときだけ読み込まれる | 繰り返す作業の手順 |
アプリの設定の指示が Claude Code のセッションにも反映されるかは、公式に記載が見つかりません。Claude Code でも同じルールを効かせたい場合は、~/.claude/CLAUDE.md にも同じ文を書いておきます。CLAUDE.md と Skills は第5回で詳しく扱います。
共通の指示：調査・事実確認のルール
筆者は、次の指示をアプリの設定の「Claudeへの指示」と ~/.claude/CLAUDE.md の両方に書いています。製品の仕様や設定値を調べることが多い、インフラの仕事向けのルールです。
# 調査・事実確認のルール
製品の仕様・設定値・制限・料金・バージョンなど、変わりうる事実を答えるときは、
記憶だけで答えず、Web検索やドキュメントの取得で確認してください。
回答は設計や顧客への説明に使うため、根拠がはっきりしていることを重視しています。
- 根拠の優先順位
1. 製品のベンダー自身が公開している公式ドキュメントと、RFCなどの標準化文書
（例：AWS https://docs.aws.amazon.com/ 、Microsoft https://learn.microsoft.com/ ）
2. ベンダーの公式ブログ・リリースノート・サポート記事
3. それ以外（個人ブログ、Q&Aサイト、ニュース記事など）
- 1・2に明記されている内容は確定情報とし、3の内容は参考情報として分けて示す
- 公式と非公式が食い違う場合は公式を採用し、食い違いがあったことも書く
- 公式に記載が見つからない場合は、推測で補わず「公式には記載が見つからない」と書く
- 回答には出典のURLを付け、確認したバージョン・日付を書くこの指示が効く理由
| 指示の部分 | 基づく公式の原則 |
|---|---|
| 記憶だけで答えず、検索で確認する | Sonnet 5.5 のガイド：検索ツールがあるなら「変わりうる事実は検索で確認せよ」と明記する |
| 回答の使い道（理由）を書く | 指示には理由を添えると、意図をくみ取って似た場面にも応用する（前半） |
| 「公式」を例ではなく原則で書く | 5.x 世代は書いたとおりにだけ守る。例の2サイトだけでは、ほかのベンダーを判断できない |
| 見つからなければ「記載なし」と書かせる | 「分からなければ分からないと言ってよい」と伝えると、ハルシネーションが減る |
| 出典URLとバージョン・日付を書かせる | 結果を見極める（Discernment、第6回）ための材料になる |
この指示が効くには、Web検索が使える必要があります。アプリでは、会話の入力欄のツールの設定で Web 検索がオンになっているかを確かめます（組織のプランでは、管理者が組織の設定で有効にします）。
ユースケース① 障害の一次調査
- 使うもの：Claude Code（手元の端末、または SSH でつないだサーバー。第2回）。Sonnet 5.5（Effort は medium）。原因が絞り込めなければ Opus 5.5 に上げる（第3回）
- 効かせている原則：変更させない（提案と実行を分ける）、根拠の引用、推測させない、未確認を明示
Webサーバー（web01・web02）で、10:00ごろから502エラーが出ています。原因の一次調査をしてください。
本番環境なので、変更は一切せず、読み取りのコマンドだけを使ってください。
- nginx・アプリのログ、systemctl status、ディスクとメモリの状態を確認する
- 原因の仮説を可能性の高い順に3つ挙げ、それぞれ根拠となるログの行を引用する
- 確認できなかったことは「未確認」と書く
- 対処案は提案だけにし、実行しない「読み取りのコマンドだけ」と書くのに加えて、Claude Code の権限ルール（第5回）で書き込みのコマンドを確認必須にしておくと、二重に守れます。
ユースケース② playbookの作成と実行
- 使うもの：Claude Code（手元の端末・WSL・SSH）。Sonnet 5.5（medium〜high）
- 効かせている原則：目的と範囲の明示、既存の規約に合わせる、検証手段を渡す（第5回）、本番は人が判断
inventory/stg の webservers グループのchronyの設定を、社内NTP（ntp1〜ntp3.corp.example.jp）に
統一するplaybookを作ってください。
- 既存の roles/ の書き方に合わせ、変数は group_vars に置く
- 何度流しても同じ結果になる（冪等な）書き方にする
- 作成後、ansible-lint と、stgへの --check --diff を実行して差分を見せる
- 本番（inventory/prod）には実行しない。差分を見て私が判断するユースケース③ 手順書の作成
- 使うもの：Claude Code（md で残す）または Chat。Sonnet 5.5
- 効かせている原則：資料は先頭に置く、読み手を書く、形式を指定する、補った部分を明示させる
<document>（作業メモ・コマンドの履歴を貼る）</document>
上のメモから、RHEL 9のカーネル更新作業の手順書をmdで作ってください。
読み手は、この作業を初めて行う初級エンジニアです。
- 構成：作業前の確認 → 手順 → 確認方法 → 切り戻し の順の番号付きリスト
- 各手順に、実行するコマンドと、期待する結果を書く
- メモに無い手順を補った場合は、補ったことが分かるように書く「補ったことが分かるように」と頼むのは、Claude が一般的な手順で空白を埋めることがあるためです。補った部分だけを重点的に確かめれば、見直しの手間も減ります。
ユースケース④ 公式情報の調査・比較
- 使うもの：Claude Code（結果を md に残す）。Sonnet 5.5。推奨まで判断させるなら Opus 5.5。サブエージェント（第5回）は使用量が増えるので、必要なときだけ
- 効かせている原則：目的（使い道）を書く、観点を指定する、出典と未確認の明示、出力の形式
Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL を、社内の中規模システム
（DB 500GB、読み取り中心）の移行先として比べてください。上司への提案資料の材料にします。
- 比べる観点：可用性、バックアップ、スケール、料金の考え方、運用の手間
- AWSの公式ドキュメントで確認し、各項目に出典のURLを付ける
- 公式に記載が見つからない点は「未確認」と書く
- 結果は表にまとめ、最後に推奨とその理由を3行で書くユースケース⑤ 設定・スクリプトのレビュー
- 使うもの：Claude Code。Sonnet 5.5、Effort は high
- 効かせている原則：5.x 世代は「重大なものだけ」と書くと忠実に絞り、拾う件数が減る。すべて挙げさせて重大度を付けさせる
この nginx の設定ファイルをレビューしてください。来週、本番に反映する予定です。
- セキュリティ・可用性・性能の観点で、気になる点をすべて挙げる（軽微なものも含める）
- 各指摘に、重大度（高・中・低）と、該当する行を付ける
- 修正案は差分の形で示す。ファイルはまだ変更しない公式の Sonnet 5 のガイドは、「重大なものだけ」「控えめに」のような指示を忠実に守る結果、コードレビューで見つけた問題を報告する率が下がることがあると注意しています。絞り込みは、重大度を見て人が行います。
ユースケース⑥ お客様向け報告の下書き
- 使うもの：Chat。Sonnet 5.5
- 効かせている原則：資料は先頭に置く、読み手を書く、構成を指定する、断定させない
<memo>（障害の経過メモを貼る）</memo>
上のメモから、お客様向けの障害報告の下書きを作ってください。
読み手は、技術に詳しくないお客様のご担当者です。
- 構成：概要 → 影響 → 原因 → 対応 → 再発防止策
- 専門用語には短い説明を添える
- メモから分からないこと（原因が確定しているかなど）は断定せず、[要確認] と書くお客様の名前やシステムの構成など、外に出せない情報を貼る前には、使っているプランのデータの扱い（第6回）と、勤務先のルールを確かめてください。
考えてみよう
- 最近 Claude に頼んだ作業を1つ思い出してください。目的・読み手・制約・理由のうち、書いていなかったものはどれですか。
- レビューを頼むときに「重大なものだけ挙げて」と書くと、5.x 世代ではどうなりやすいでしょうか。ユースケース⑤のひな形では、代わりにどう書いていますか。
- 自分がよく頼む作業を1つ選び、6つのひな形のどれに近いかを考えて、自分用のひな形を作ってみてください。
ヒント：事情を知らない新入社員の原則、5.x 世代で変わった点の表、6つのひな形の「効かせている原則」を見直してください。
まとめ
- Claude は優秀だが事情を知らない新入社員。目的・読み手・制約を書き、理由を添える
- 例は3〜5個、資料と指示はXMLタグで分け、長い資料は先頭に置いて質問は最後に。提案か実行かを明示する
- 5.x 世代は書いたとおりにだけ守る。強い言い回しは効きすぎ、「よく考えて」は不要。絞り込みは忠実に効くので、レビューはすべて挙げさせて重大度を付けさせる
- よく使う指示は、効く範囲に合わせてアプリの設定・Projects・CLAUDE.md・Skillsに一度だけ書く
- 調べものには、公式の情報を確定情報にし、出典と未確認を明示させる共通の指示が効く
- 作業ごとの指示は、目的・範囲・検証・人の判断を入れたひな形から始める
次回は、Claude Code を使うときの公式のベストプラクティス（探索→計画→実装→検証、CLAUDE.md、コンテキストの管理、権限）を扱います。
連載「Claude活用入門」全6回
- Claudeの全体像とプラン
- Chat・Cowork・Codeの使い分け
- ModelとEffort
- プロンプトの基本と指示の例（この記事）
- Claude Codeのベストプラクティス
- 安全に使う
コメント