はじめに

「このエラーを直して」とClaudeに投げたら、「セキュリティグループを確認してください」と返ってきた——
そんな経験はないでしょうか。

AIへの頼み方を少し変えるだけで、回答の質は大きく変わります。
この記事では実はやっても意味がない頼み方と本当に効く5つの習慣を、インフラ業務の具体例とともに紹介します。

やっても意味がない「プロンプトの都市伝説」3選

都市伝説①：チップを払う・脅す

「$200のチップを払います」「これができなければ解雇します」といった表現でAIの回答が改善するという話を
SNSで見かけたことはないでしょうか。

Wharton大学が2025年に発表した研究（GPQA全198問、各4,950試行という大規模検証）では、
チップ提示も脅しも、ベンチマーク性能に有意な効果はないという結論が出ています。

一部の事例で「回答が長くなった」という観察はあるものの、それは長さの変化であって精度の向上ではありません。
これらのフレーズに時間を使うくらいなら、質問の内容を1行具体的にした方が確実に効きます。

都市伝説②：ペルソナを与えると精度が上がる

「あなたはAWSの専門家です」「10年以上のインフラ経験を持つエンジニアです」と
冒頭に書くと回答が良くなると思っていませんか？

2024年のEMNLP Findingsに掲載された研究では、162種類のペルソナ設定を4モデル・2,410問で検証した結果、
ペルソナを付与しても客観的な精度は向上しないことが示されています。

ただし誤解してほしくないのは、ペルソナは文体やトーンの制御には有効だという点です。
「辛口のレビュアーとして」と書けばフィードバックが鋭くなりますし、
「初心者向けに説明する講師として」と書けば平易な説明が返ってきます。
精度ではなく、文体を変えたいときに使いましょう。

都市伝説③：推論モデルに「ステップバイステップで考えて」と言い続ける

「Let’s think step by step」は、2022年ごろの旧世代LLMでは劇的な効果（MultiArithで17.7%→78.7%）を発揮した名プロンプトです。

しかし現在のClaude（拡張思考モード）やOpenAIのo3/o4-miniなどの推論モデルは、内部で既に段階的な思考を行っています。
OpenAIの公式ドキュメントには「これらのモデルに『ステップバイステップで考えて』と促すのは不要であり、
むしろ性能を落とす場合がある」と明記されています。

もしClaude Sonnet 4.6や最新の推論モデルを使っているなら、
このフレーズは削除してシンプルな質問に変えた方が良い結果が出ることがあります。

本当に効く5つの習慣

習慣①：明確・具体的に書く ＋ 理由を添える

Anthropicの公式ドキュメントには「Claudeを、職場の慣習を知らない優秀な新入社員だと思え」という表現があります。
つまり文脈を何も知らない状態から始まるという前提で書く必要があります。

Before（よくある頼み方）

このTerraformのエラーを直して

After（本当に効く頼み方）

AWS VPCにAmazon EC2を構築するTerraformで、以下のエラーが出ています。
セキュリティグループとNACLは確認済みで、インバウンドの許可設定は問題ありません。
原因として考えられる仮説を3つ挙げて、確認すべき順番に並べてください。

【エラー内容】
（エラーをここに貼り付ける）

【現在の構成】
（関係するtfファイルをここに貼り付ける）

「ルートテーブルの設定ミスでは？」という具体的な仮説が返ってきます。
前者との差は一目瞭然です。

また、なぜそのような制約があるのかを書くと、Claudeが意図を汎化して周辺的なケースにも適切に対応します。

# 悪い例
省略形を使わないで

# 良い例
顧客向けの手順書として作成するため、省略形は使わず正式名称で統一してください
（例：「SG」ではなく「セキュリティグループ」）

習慣②：XMLタグで構造化する

ClaudeはXMLタグを含むデータで学習されているため、XMLタグを使って構造化するとプロンプトの解釈が安定し、
指示・文脈・データの取り違いが大幅に減ります。これはClaude固有の強力なテクニックです。


既存のAWS環境に、新しいWebアプリケーション用の構成を追加しようとしています。
本番環境のため、セキュリティ要件を最優先にしています。



以下の構成図について、セキュリティ上の懸念点を指摘してください。



（構成図の内容をここに記載）



- 問題点
- 理由
- 推奨する修正案
の3点セットで、優先度の高い順に3件出力してください。

特に長いプロンプトや複数の情報を組み合わせる場合に効果が出ます。
長い文書はプロンプトの上部に、質問・指示は最後に置くのがポイントで、
これだけで回答品質が最大30%向上するとAnthropicの公式ドキュメントに記載があります。

習慣③：出力例（few-shot）を3〜5個添える

「どんな形式で答えてほしいか」を言葉で説明するより、例を見せた方が確実に伝わります。

Anthropicは「3〜5個の例をタグで囲んで示す」ことを推奨しています。
インフラ業務での活用例を挙げます。


以下のAWSリソースについて、コスト最適化の観点からレビューしてください。



  
    Amazon EC2: t3.xlarge × 3台（24時間稼働）
    
    - 問題：夜間・週末の低負荷時間帯でも常時稼働している
    - 影響：月額概算 $xxx の過剰コスト
    - 推奨：Auto Scalingの導入、またはスケジュールに基づくt3.mediumへのダウンサイジング
    
  
  
    Amazon RDS: db.r5.2xlarge（Multi-AZ、使用率平均15%）
    
    - 問題：平均使用率15%に対してインスタンスサイズが過大
    - 影響：月額概算 $xxx の過剰コスト
    - 推奨：db.r5.largeへのダウンサイジング、またはAmazon Aurora Serverlessへの移行を検討
    
  



（実際のリソース情報）

例を示すことで、フォーマットだけでなくレビューの粒度や観点まで揃えることができます。

習慣④：Claude Code では CLAUDE.md と ultrathink を活用する

Claude Codeを日常業務に組み込んでいる方向けの習慣です。

CLAUDE.md は、毎会話の冒頭でClaudeが自動的に読み込む設定ファイルです。
「Bashコマンドはこれを使う」「変数名はスネークケース」「Terraformのバージョンはxx」といった
プロジェクト固有のルールを書いておくと、毎回説明する手間がなくなります。

# CLAUDE.md の記載例（Terraformプロジェクト）

## 環境
- Terraform: v1.9.x
- AWS Provider: v5.x
- 対象環境: 本番(prod) / 開発(dev)

## コーディング規則
- リソース名は snake_case
- 変数はすべて variables.tf に定義
- tagsブロックには必ず Environment, ManagedBy, Project を含める

## 禁止事項
- ハードコードされたアクセスキーを絶対に含めない
- count と for_each を同一リソースで混在させない

また、複雑なアーキテクチャ判断や難易度の高いバグ追跡では、
ultrathink というキーワードをプロンプトに含めると、Claudeの内部思考予算が増加し、より深い分析が返ってきます。

ultrathink: このマルチリージョン構成でのDR設計について、
RTO 15分・RPO 5分を満たすための具体的な構成案を提案して

「think」「think hard」「ultrathink」の順に思考の深さが増します。
重要な設計判断には惜しまず使いましょう（処理時間とコストは増加します）。

習慣⑤：AIの「追従」を意識して抑制する

AIは、あなたが「正しい」と思っていそうな答えを返そうとする傾向（追従・sycophancy）があります。
「この設計どう思う？」と聞けば、たいてい「良い設計ですね」と返ってくるのはこのためです。

英国AI Safety Instituteの研究では、疑問文で質問すると追従が大幅に減ることが示されています。

# 追従しやすい聞き方
この設計は正しいと思うんだけど、どう思う？

# 追従しにくい聞き方
この設計が失敗するリスクを3つ挙げて、それぞれの理由と深刻度を教えて

また、設計レビューや意思決定の場面では、あえて批判的な役割を与えることが有効です。

あなたは担当したシステムのインシデント原因を追跡するSREです。
以下のアーキテクチャ設計について、障害が起きやすいポイントと
その改善案を厳しく指摘してください。
良い点は不要です。

「辛口のレビュアー」という設定は、追従ではなくスタイルの制御として機能するため、
ペルソナ付与の中では有効なパターンです。

そのまま使えるプロンプト集（インフラ業務版）

場面 プロンプト
エラー調査 「このエラーの原因仮説を3つ、確認すべき順番に並べて。試したことはこちら：[内容]」
コードレビュー 「セキュリティ・コスト・可読性の3軸でTerraformをレビューして。良い点は不要、問題点のみ」
設計相談 「この設計が失敗するリスクを3つ挙げて、それぞれの深刻度と対策を教えて」
ドキュメント化 「以下の作業ログを、次の担当者が再現できるよう手順書形式に整理して。省略は禁止」
サービス選定 「この要件を満たすAWSのサービス候補を3つ挙げて、コスト・運用負荷・制約の観点で表にして比較して」
ハルシネーション抑制 「わからない場合は『わからない』と言って。推測の場合は必ず推測と明示して」
追従抑制 「私に同意せず、批判的に検討して。私の前提が間違っている可能性も指摘して」
Claude Code 深い思考 「ultrathink: [複雑な設計課題]」

毎回書かなくていい：一度設定しておく3つの方法

ここまで紹介した習慣を「毎回手打ちするのは現実的でない」と思った方も多いはずです。
実際その通りで、上手なAI活用の本質はよく使う設定を一度だけ書いて、使い回す仕組みを作ることにあります。

方法①：Claude.ai の「Personal preferences」に書いておく

Claude.aiの設定（Settings）から「Personal preferences」に定型指示を書いておくと、全会話に自動で適用されます。
一度設定すれば、毎回書く必要はありません。

# Personal preferences の記載例

- 回答は結論から先に書いてほしい
- 前置きや「もちろんです！」などの定型句は不要
- わからない場合は「わからない」と言ってほしい。推測は推測と明示すること
- インフラ・クラウド領域での質問が多いため、AWS/Google Cloud/Terraformの文脈で考えてほしい

方法②：Claude.ai の「Projects」にプロジェクト単位の指示を書く

案件や用途ごとにProjectを作成し、その中に定型指示を書いておきます。
「このProjectの会話はすべてこの指示に従う」という設定になるため、
案件ごとの文脈（使用するAWSリージョン、Terraformのバージョン、顧客向けの表記ルールなど）を毎回書かずに済みます。

# AWS構築案件用 Project の指示例

- 対象はAWS上の新規構築案件（Terraformで管理）
- 構成を説明する際は、採用理由と検討した代替案を併記すること
- ドキュメントは顧客共有前提のため、省略形（SG、SGW等）は使わず正式名称で統一

方法③：よく使うプロンプトをテキスト展開ツールに登録する

「エラー調査」「コードレビュー」「設計レビュー」など、
定番の質問パターンはテキスト展開ツール（macOSなら標準の「テキスト置換」、WindowsならPhraseExpressなど）に
登録しておくと、短縮キーワードを打つだけでプロンプトが展開されます。

# 登録例（;err → 以下のテキストに展開）

このエラーの原因として考えられる仮説を3つ、確認すべき順番に並べてください。
試したことはこちら：
【エラー内容】

【試したこと】

たった3行の設定で、毎回ゼロから書く手間がなくなります。

まとめ

やめていいもの

  • チップを払う・脅す（研究で無効が証明済み）
  • ペルソナで精度を上げようとする（スタイル制御には使ってOK）
  • 推論モデルに「ステップバイステップで」と言い続ける（削除で改善することも）

続けるべき5つの習慣

  1. 明確・具体的に書く ＋ 理由・文脈を添える
  2. XMLタグで構造化する（Claude特有の強み）
  3. few-shot例示を3〜5個添える
  4. CLAUDE.md と ultrathink を活用する（Claude Code）
  5. AIの追従を意識して、批判的な視点を引き出す

毎回手の込んだプロンプトを書く必要はありません。
Personal preferences・Projects・テキスト展開ツールで一度仕組みを作れば、
あとは普通に質問するだけで質の高い回答が返ってきます。
まずは自分がよく使う質問パターンを1つだけ登録することから始めてみてください。

参考資料