本記事には広告（アフィリエイトリンク）が含まれます。

プロンプトエンジニアリング入門

2026.03.08
広告

プロンプトエンジニアリング入門

このシリーズ：生成AIを武器にするインフラエンジニアへの道
① プロンプトエンジニアリング　← 現在の記事
② AIエージェントエンジニアリング
③ コンテキストエンジニアリング
📝 この記事について
この記事は生成AI（Claude）を活用して執筆し、運営者が内容を確認・編集しています。

はじめに

インフラエンジニアが生成AIを業務で使う場面は確実に増えています。障害対応時のログ解析、設定ファイルの生成、手順書の作成など、日常的にAIに質問する機会がある方も多いはずです。

一方で、「なんとなくチャット欄に質問を打ち込んでいる」という状態にとどまっている方も少なくありません。同じAIモデルを使っていても、指示の書き方ひとつで出力の品質は大きく変わります。

プロンプトエンジニアリングとは、AIモデルからより良い出力を得るために、指示（プロンプト）を構造化・設計・改善する技術体系です。プログラミングのようにコードを書く必要はなく、「指示の書き方」を学ぶだけで、AIの出力品質を引き上げることができます。

この記事では、プロンプト単体の設計技術を扱います。APIを使ったプログラムからの呼び出しやエージェント連携は記事②、情報全体の設計（コンテキストエンジニアリング）は記事③で扱います。

この記事を読むと、以下の3つができるようになります。

  1. プロンプトの6つの構成要素を理解し、意図して組み立てられる
  2. Zero-shot / Few-shot / Chain-of-Thought を場面に応じて使い分けられる
  3. インフラ業務（障害対応・設定生成・ドキュメント作成）でプロンプト設計を実践できる

前提条件

この記事は、以下の前提知識を持つ方を対象としています。

  • コマンドライン操作（Linux / Windows）の基本ができる
  • ChatGPTやClaudeなどの生成AIを業務またはプライベートで使ったことがある
  • プログラミング経験は不要

記事中のプロンプト例はすべてClaude Sonnet 4.6（Anthropic公式Web UI）で動作確認しています。

ℹ️ ポイント
この記事のプロンプト例はClaude Sonnet 4.6で検証しています。ChatGPTなど他のモデルでも基本的な考え方は共通ですが、XMLタグによる構造化などClaude固有の機能については、他モデルでは効果が異なる場合があります。該当箇所にはその旨を明記しています。

プロンプトの6つの構成要素

プロンプトは「ただの質問文」ではなく、複数の構成要素を組み合わせた「設計物」です。Anthropicの公式ドキュメントが推奨する6つの構成要素を順に説明します。

構成要素英語名説明
役割RoleAIにどのような専門家として振る舞うかを指定する
タスクTask何をしてほしいかを具体的に指示する
制約Constraintsやってはいけないこと・守るべきルールを定める
コンテキストContext背景情報・状況説明を提供する
出力形式Output Format出力の形式・長さ・構造を指定する
例Examples期待する入出力のサンプルを提示する

1. 役割（Role）

AIにどのような専門家として振る舞うかを指定します。

インフラ業務での例：「あなたは10年以上の経験を持つLinuxサーバー管理者です。」

役割を指定することで、AIの回答の視点と専門性の深さが変わります。「Linuxサーバー管理者」と指定すれば、セキュリティやパフォーマンスを意識した回答が返りやすくなります。

2. タスク（Task）

何をしてほしいかを具体的に指示します。

インフラ業務での例：「以下のnginxアクセスログから、5xx系エラーの発生パターンを分析してください。」

「分析してください」だけでなく、「何を」「どのように」分析するかまで書くと、意図した出力に近づきます。

3. 制約（Constraints）

やってはいけないこと、守るべきルールを明示します。

インフラ業務での例：「rootユーザーでの直接ログインを許可する設定は含めないでください。セキュリティベストプラクティスに従ってください。」

制約がないと、AIは最も一般的な回答を返します。本番環境で使う設定を生成する場合、セキュリティ要件を制約として明記することが重要です。

4. コンテキスト（Context）

背景情報や状況説明を提供します。

インフラ業務での例：「対象サーバーはAlmaLinux 10で、nginxのバージョンは1.26系です。バックエンドはポート8080で動作するアプリケーションサーバーです。」

AIはコンテキストがなければ一般的な前提で回答します。OS、ミドルウェアのバージョン、ネットワーク構成などの情報を与えることで、回答の精度が上がります。

5. 出力形式（Output Format）

出力の形式・長さ・構造を指定します。

インフラ業務での例：「nginx.confのserverブロック形式で出力してください。各ディレクティブにコメントを付与してください。」

出力形式を指定しないと、散文で返ってきたり、不要な説明が混ざったりします。「設定ファイル形式」「表形式」「番号付きリスト」など、用途に応じて指定します。

6. 例（Examples）

期待する入出力のサンプルを提示します。

インフラ業務での例：ログ1行とその分析結果のペアを2〜3個示し、同じ形式で残りのログも分析させます。

例を与えると、AIは出力のトーン・フォーマット・粒度を合わせて回答します。後述するFew-shotテクニックの核となる要素です。

6要素すべてを使った統合プロンプト例

以下は、6つの構成要素すべてを盛り込んだプロンプトの例です。nginxのリバースプロキシ設定を生成させます。

<role>
あなたは10年以上の経験を持つLinuxサーバー管理者です。
nginx設定のベストプラクティスに精通しています。
</role>

<context>
対象サーバー: AlmaLinux 10（nginx 1.26系）
バックエンド: localhost:8080 で動作するNode.jsアプリケーション
ドメイン: app.example.com
SSL証明書: Let's Encryptで取得済み（/etc/letsencrypt/live/app.example.com/）
</context>

<task>
上記環境に対応するnginxのリバースプロキシ設定ファイル（serverブロック）を作成してください。
</task>

<constraints>
- HTTP（ポート80）はHTTPSにリダイレクトすること
- HTTP/2を有効にすること
- セキュリティヘッダー（X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security）を付与すること
- アクセスログとエラーログのパスを /var/log/nginx/app.example.com/ 配下に設定すること
</constraints>

<output_format>
nginx.confに貼り付け可能なserverブロック形式で出力してください。
各ディレクティブの意味をインラインコメント（#）で簡潔に付記してください。
</output_format>

<examples>
# 出力形式のイメージ（抜粋）:
server {
    listen 443 ssl http2;           # HTTPS + HTTP/2で待ち受け
    server_name app.example.com;    # 対象ドメイン
    ...
}
</examples>

このプロンプトのポイント:

  • <role> でAIの専門性を定義し、回答の視点を固定している
  • <context> でOS・ミドルウェア・証明書パスなどの環境情報を網羅している
  • <task> は1つの明確な依頼に絞っている
  • <constraints> でセキュリティ要件を4項目に限定して列挙している
  • <output_format> で出力形式とコメント付記を指定し、そのまま使える出力を促している
  • <examples> で出力の粒度・スタイルを例示している
⚠️ 注意
Claude Sonnet 4.6 / Opus 4.6では、Adaptive Thinkingがデフォルト機能として搭載されており、過度に細かい指示がかえって逆効果になる場合があります。まずはシンプルに書き、必要に応じて制約を追加する方針が有効です。

Anthropicは「同僚に見せて混乱するなら、Claudeも混乱する」と述べています。プロンプトを書いたら、一度自分で読み返して、人間が読んでも迷わない指示になっているか確認する習慣をつけると効果的です。

3つの基本テクニック ― Zero-shot / Few-shot / Chain-of-Thought

プロンプト設計には、目的に応じて使い分ける基本テクニックがあります。ここでは最も実用頻度の高い3つを取り上げます。

Zero-shot（例示なしの直接指示）

定義: 入出力例を示さず、指示文のみでタスクを実行させる方法です。

適する場面: 単純な分類・翻訳・要約など、タスクが明確で出力形式にこだわらないケース。

インフラ業務での例：

以下のエラーログの原因を日本語で1行で説明してください。

※ Apache + ModSecurity環境のエラーログ形式です
[Mon Mar 08 10:23:45 2026] [error] [client 192.168.1.50] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Rx' with parameter `(?:etc/passwd)' against `REQUEST_URI'

このプロンプトのポイント:

  • タスクが「原因を1行で説明」と明確なので、例示なしで十分な結果が得られる
  • 「日本語で」「1行で」という出力制約を最小限だけ付与している

Zero-shotは最もシンプルな手法です。まずはZero-shotで試し、出力が不十分な場合にFew-shotやChain-of-Thoughtへ切り替えるのが効率的な進め方です。

Few-shot（入出力例の提示）

定義: 3〜5個の入出力例を提示し、AIに出力パターンを学習させる方法です。Anthropic公式ドキュメントでも推奨されているテクニックです。

適する場面: 出力フォーマットを厳密に制御したい場合、独自の分類基準で判定させたい場合。

インフラ業務での例（ログの重要度分類）：

以下のルールに従い、サーバーログの重要度を分類してください。

## 分類ルール
- IGNORE: 正常動作のログ。対応不要。
- CHECK: 注意が必要だが即時対応は不要。翌営業日に確認。
- URGENT: 即時対応が必要。サービス影響の可能性あり。

## 分類例

ログ: INFO  [httpd] GET /health 200 - 3ms
分類: IGNORE
理由: ヘルスチェックの正常応答

ログ: WARN  [disk] /var usage 82% threshold 80%
分類: CHECK
理由: ディスク使用率が閾値を超過したが即時障害ではない

ログ: ERROR [mysqld] Too many connections (max: 151)
分類: URGENT
理由: DB接続数が上限に達しており、新規接続が拒否される状態

## 分類対象

ログ: ERROR [nginx] upstream timed out (110: Connection timed out) while reading response header from upstream

このプロンプトのポイント:

  • 3つの入出力例（IGNORE / CHECK / URGENT）を提示し、分類基準を具体的に示している
  • 各例に「理由」を含めることで、AIが判断根拠も出力するよう誘導している
  • 独自の3段階分類ルールを使っており、Zero-shotでは正確な基準を伝えにくい

Chain-of-Thought（段階的推論の誘導）

定義: 中間推論ステップを明示的に求め、複雑な問題を段階的に解かせる方法です。

適する場面: 複雑な推論、根本原因分析、複数の選択肢の比較検討が必要なケース。

インフラ業務での例（障害の根本原因分析）：

<role>
あなたはインフラエンジニアとして障害対応を行っています。
</role>

<task>
以下のログと状況から、障害の根本原因を段階的に推論してください。
</task>

<context>
状況: Webアプリケーションの応答が急激に遅くなった（レスポンスタイム 200ms → 5000ms）
発生時刻: 2026-03-08 14:30 JST
環境: AlmaLinux 10 / nginx 1.26 / PHP-FPM 8.3 / MariaDB 10.11

関連ログ:
[14:28] nginx: upstream timed out (110: Connection timed out)
[14:29] php-fpm: pool www: server reached max_children setting (50)
[14:29] mariadb: Aborted connection 8423 to db: 'appdb' (Got timeout reading communication packets)
[14:30] kernel: Out of memory: Killed process 2847 (php-fpm)
</context>

<output_format>
以下のステップで分析してください。
1. 各ログエントリの意味を個別に整理する
2. ログの時系列から因果関係を推定する
3. 根本原因の候補を挙げる（最も可能性が高い順）
4. 推奨される対処手順を優先度順に列挙する
</output_format>

このプロンプトのポイント:

  • <output_format> で4つの分析ステップを指定し、いきなり結論に飛ばず段階的に推論させている
  • 時系列のログを <context> で提供することで、因果関係の推定に必要な情報を揃えている
  • 「根本原因の候補を可能性が高い順に」と指定することで、複数の仮説を比較させている

Chain-of-Thought（以下、CoT）は「ステップバイステップで考えてください」の一文を追加するだけでも効果がある場合があります（Zero-shot CoT）。より精度が求められる場合は、上記のように具体的な分析ステップを指定します（Few-shot CoT）。

使い分けの判断基準

3つのテクニックを「タスクの複雑さ」と「出力形式の厳密さ」の2軸で整理します。

テクニックタスクの複雑さ出力形式の厳密さ代表的な場面
Zero-shot低い低い〜中程度単純な翻訳・要約・分類
Few-shot低い〜中程度高い独自フォーマットでの出力、カスタム分類
Chain-of-Thought高い中程度〜高い根本原因分析、複数要素の比較検討

使い分けの判断フロー

ステップ1: タスクの種類を確認する

ℹ️ 判断基準
  1. 複雑な推論や多段階の分析が必要 → Chain-of-Thought を使う
    例: 障害の根本原因分析（ログから原因を段階的に推論）
  2. 出力形式を厳密に制御したい → Few-shot を使う
    例: ログの重要度分類（INFO/WARN/ERRORの判定基準を例示）
  3. 上記に該当しない単純なタスク → Zero-shot を使う
    例: エラーログの要約（原因を1行で説明させる）
出力形式: 自由出力形式: 厳密
タスク: 単純Zero-shotFew-shot
タスク: 複雑Chain-of-ThoughtFew-shot + CoT 併用
📝 メモ
近年はTree-of-Thought、Self-Consistency、ReActなど、より高度な手法も提案されています。これらはいずれも上記3テクニックの応用・拡張として位置づけられます。基本の3テクニックを使いこなせるようになった段階で、必要に応じて公式ドキュメントを参照してください。

Claude固有の推奨パターン

ここまでの内容はどの生成AIモデルにも共通する基本です。この章では、Claudeで特に効果が高いパターンを3つ紹介します。

ℹ️ ポイント
XMLタグ構造化はClaude固有の強みです。ChatGPTなど他モデルでは効果が異なる場合があります。

XMLタグによる構造化

Claudeは <role> <task> <constraints> <output_format> などのXMLタグでプロンプトを構造化すると、各要素の境界を正確に認識し、指示に忠実な出力を返しやすくなります。

以下に、構造化なしのプロンプトとXMLタグで構造化したプロンプトのBefore/After比較を示します。

❌ Before（悪い例）
firewalldでHTTPとHTTPSとSSH（ポート22022）を許可するルールを作ってください。
それ以外は全部拒否してください。永続設定にしてください。
出力はfirewall-cmdコマンドの一覧にしてください。

改善ポイント: 各要素をXMLタグで明確に分離し、制約を箇条書きで列挙することで、AIが各セクションの意図を正確に把握できるようになります。

ℹ️ After（改善例）
<role>
あなたはLinuxサーバーのセキュリティ管理者です。
</role>
<task>
firewalldのルール設定コマンドを作成してください。
</task>
<constraints>
- 許可するサービス/ポート: HTTP（80）、HTTPS（443）、SSH（ポート22022）
- 上記以外の受信トラフィックはすべて拒否する
- 設定は永続化すること（--permanent オプション使用）
- 設定反映のための reload コマンドも含めること
</constraints>
<output_format>
実行順に番号付きで firewall-cmd コマンドを列挙してください。
各コマンドの右側にインラインコメント（#）で目的を記載してください。
</output_format>

改善のポイント:

  • Beforeは1つの文章に役割・タスク・制約・出力形式が混在しており、AIが各要素の境界を誤認する可能性がある
  • Afterは各要素をXMLタグで明確に分離しているため、Claudeが各セクションの意図を正確に把握できる
  • 制約を箇条書きで列挙したことで、漏れや曖昧さが減っている

長文コンテキストの配置ルール

プロンプトが長くなる場合、情報の配置順序が出力品質に影響します。Anthropicの公式データによると、20K+トークンの長文データを扱う場合、データ（ドキュメント等）をプロンプトの上部に配置し、クエリや指示をその下に配置すると、最大30%の品質向上が確認されています（Anthropic公式データ）。

推奨する配置順序は以下のとおりです。

  1. 役割（Role） ― 最初にAIの立場を固定する
  2. コンテキスト（Context） ― 背景情報・環境情報を提示する
  3. タスク（Task） ― 何をしてほしいかを指示する
  4. 制約（Constraints） ― 守るべきルールを列挙する
  5. 出力形式（Output Format） ― 出力の構造・形式を指定する
  6. 例（Examples） ― 必要に応じて入出力例を提示する

この順序は「AIに前提知識を与えてからタスクを指示する」という流れに沿っています。人間に仕事を依頼するときも、いきなり「やって」と言うよりも、まず背景を説明してから依頼する方が伝わりやすいのと同じ考え方です。

Adaptive Thinkingの活用

Claude Sonnet 4.6 / Opus 4.6ではAdaptive Thinkingがデフォルト機能として搭載されています。これは、モデルがタスクの複雑さに応じて自律的に思考の深さを調整する機能です。

実務上のポイントは以下の2点です。

  • 複雑な分析タスクでは「考えてから回答してください」と一言添えるだけで、推論品質が向上するケースがある
  • ただし、単純なタスクに対して「必ず10ステップで考えてください」のような過度な思考指示を与えると、かえって冗長な出力になる

つまり、思考の深さはモデルに委ねる設計になっているため、「考えてほしい」という意図だけを伝えれば十分です。具体的な思考ステップ数を強制する必要はありません。

インフラ業務での実践例

ここでは、3つの業務シナリオで実際に使えるプロンプトを完成形で示します。

業務使用テクニック難易度概要
障害対応
ログ解析と根本原因分析		Chain-of-Thought + XMLタグ構造化上級nginxのアクセスログから異常パターンを検出し、原因候補を段階的に推論させる
設定ファイル生成
nginx仮想ホスト設定		Zero-shot + 6構成要素中級要件を指定して、nginx仮想ホスト設定ファイルを一発で生成する
ドキュメント作成
サーバー構築手順書		Few-shot初級手順書のフォーマット例を提示し、AlmaLinux 10のApache+PHP構築手順書を生成する

障害対応 ― ログ解析と根本原因分析

状況: Webサーバー（nginx）のアクセスログから異常パターンを検出し、原因候補を挙げたい。

<role>
あなたは大規模Webシステムの運用経験を持つインフラエンジニアです。
障害の根本原因分析（RCA）を専門としています。
</role>

<context>
環境: AlmaLinux 10 / nginx 1.26 / バックエンド: Gunicorn + Django（ポート8000）
発生事象: 2026-03-08 09:00頃からHTTP 502エラーが断続的に発生
直前の変更: 前日にDjangoアプリのデプロイを実施

以下はnginxのerror.logの抜粋です:
2026/03/08 09:01:12 [error] 1234#1234: *5678 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.50, server: app.example.com, request: "GET /api/v1/users HTTP/1.1", upstream: "http://127.0.0.1:8000/api/v1/users"
2026/03/08 09:01:15 [error] 1234#1234: *5679 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.51, server: app.example.com, request: "GET /api/v1/orders HTTP/1.1", upstream: "http://127.0.0.1:8000/api/v1/orders"
2026/03/08 09:03:22 [error] 1234#1234: *5702 upstream prematurely closed connection while reading response header from upstream, client: 192.168.1.52, server: app.example.com, request: "POST /api/v1/data HTTP/1.1", upstream: "http://127.0.0.1:8000/api/v1/data"
2026/03/08 09:05:00 [error] 1234#1234: *5730 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.50, server: app.example.com, request: "GET /api/v1/health HTTP/1.1", upstream: "http://127.0.0.1:8000/api/v1/health"
</context>

<task>
上記のログと状況から、障害の根本原因を段階的に分析してください。
</task>

<output_format>
以下の順序で回答してください。
1. ログの各エントリが示す内容の整理
2. 時系列に基づく因果関係の推定
3. 根本原因の候補（可能性の高い順に最大3つ）
4. 各候補に対する確認コマンド
5. 推奨対処手順（優先度順）
</output_format>

このプロンプトのポイント:

  • Chain-of-Thoughtとして5段階の分析ステップを出力形式で指定し、論理的な推論を促している
  • <context> に「直前の変更」情報を含めている。障害対応では「何が変わったか」が原因特定の重要な手がかりになる
  • 「確認コマンド」の出力を求めることで、分析結果をすぐに検証できる実用的な出力になる

設定ファイル生成 ― nginx仮想ホスト設定

状況: 新規Webサイト用のnginx設定ファイルを、要件を指定して生成したい。

<role>
あなたは本番環境のnginx設定を管理するインフラエンジニアです。
</role>

<context>
サーバーOS: AlmaLinux 10
nginx: 1.26系
用途: 社内向けWebアプリケーション（静的ファイル配信 + リバースプロキシ）
ドメイン: internal-app.example.local
バックエンド: localhost:3000（Node.js）
SSL: 自己署名証明書（/etc/pki/tls/certs/internal-app.pem, /etc/pki/tls/private/internal-app.key）
</context>

<task>
上記要件に合致するnginx仮想ホスト設定ファイルを作成してください。
</task>

<constraints>
- HTTPはHTTPSにリダイレクトすること
- 静的ファイル（/static/）はnginxが直接配信し、キャッシュヘッダーを30日に設定すること
- それ以外のリクエストはlocalhost:3000にリバースプロキシすること
- WebSocket接続（/ws/）に対応すること
- クライアントのリクエストボディサイズ上限を10MBに設定すること
</constraints>

<output_format>
/etc/nginx/conf.d/internal-app.conf としてそのまま配置可能な形式で出力してください。
各ディレクティブの右にインラインコメント（#）で説明を付記してください。
</output_format>

このプロンプトのポイント:

  • 6構成要素（例を除く5要素）をすべて使い、曖昧さを排除している
  • 制約で「WebSocket対応」「静的ファイルのキャッシュ」など具体的な要件を列挙している
  • 出力形式で「そのまま配置可能な形式」と指定し、追加編集なしで使える出力を促している
⚠️ 注意
生成された設定ファイルは必ず検証環境でテストしてから本番適用してください。nginx -t による構文チェックと、実際のリクエストによる動作確認の両方を行うことを推奨します。

ドキュメント作成 ― サーバー構築手順書

状況: AlmaLinux 10にApache + PHP環境を構築する手順書を作成したい。

以下のフォーマットに従って、AlmaLinux 10にApache 2.4 + PHP 8.3環境を構築する手順書を作成してください。

## 手順書フォーマット（この形式に従ってください）

### ステップ1: システムの更新
コマンド:
sudo dnf update -y

期待結果:
「Complete!」が表示され、パッケージが最新になる

補足:
本番作業前にスナップショットを取得しておくこと

---

### ステップ2: EPELリポジトリの有効化
コマンド:
sudo dnf install -y epel-release

期待結果:
epel-releaseパッケージがインストールされる

補足:
一部のPHP拡張モジュールがEPELに依存するため必要

---

## 作成する手順の範囲
1. システム更新
2. Apache（httpd）のインストールと起動
3. PHP 8.3のインストール（dnfモジュール使用）
4. 必要なPHP拡張モジュール（mbstring, xml, mysqlnd, opcache）のインストール
5. Apache + PHP連携の動作確認（phpinfo()で確認）
6. firewalldでHTTP/HTTPSを許可

## 制約
- 各ステップに「コマンド」「期待結果」「補足」の3項目を必ず含めること
- コマンドはコピー&ペーストでそのまま実行可能な形式にすること
- SELinux有効環境を前提とし、必要なSELinux設定があれば含めること

このプロンプトのポイント:

  • Few-shotとして、冒頭に2つのステップを「フォーマット例」として提示している
  • AIはこの例に合わせて、残りのステップも同じ形式（コマンド・期待結果・補足の3点セット）で出力する
  • 「手順の範囲」を番号付きで列挙することで、抜け漏れを防いでいる

よくある失敗パターンと改善（Before/After）

プロンプト設計でありがちな5つの失敗パターンを、Before（悪い例）とAfter（改善例）のセットで紹介します。

パターン1: 曖昧な指示

問題: タスクが漠然としていると、AIは「何をどこまで回答すべきか」を推測する必要があり、的外れな出力が返りやすくなります。

❌ Before（悪い例）
nginxの設定を教えて

改善ポイント: 「何を」（リバースプロキシ設定）「どの条件で」（TLS必須・HTTP/2有効）「どの形式で」（serverブロック形式）を明示します。

ℹ️ After（改善例）
<role>
あなたはLinuxサーバー管理者です。
</role>
<task>
nginxでリバースプロキシを設定するためのserverブロックを作成してください。
</task>
<context>
バックエンド: localhost:8080
ドメイン: api.example.com
</context>
<constraints>
- TLS（Let's Encrypt証明書）を使用すること
- HTTP/2を有効にすること
</constraints>
<output_format>
nginx.confのserverブロック形式で出力してください。
</output_format>

パターン2: 情報不足

問題: エラー内容も環境情報もない状態では、AIは一般的な可能性を列挙するしかなく、的確な回答ができません。

❌ Before（悪い例）
このエラーを直して

改善ポイント: エラーログ全文、OS・ミドルウェアのバージョン、再現手順を提供し、AIが原因を特定するために必要な情報を過不足なく揃えます。

ℹ️ After（改善例）
<role>
あなたはLinuxサーバーのトラブルシューティング担当者です。
</role>
<context>
OS: AlmaLinux 10
ミドルウェア: Apache 2.4.62 / PHP 8.3.15
発生エラー:
[Mon Mar 08 10:00:00 2026] [error] [pid 1234] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 67108864 bytes) in /var/www/html/app/process.php on line 245
再現手順:
1. ブラウザで https://app.example.com/process にアクセス
2. 大量データ（10万行のCSV）をアップロード
3. 処理中に上記エラーが発生
</context>
<task>
上記エラーの原因と、修正方法を提示してください。
</task>
<output_format>
1. エラーの原因（1〜2文で簡潔に）
2. 修正方法（設定変更が必要な場合はファイルパスと変更内容を記載）
3. 恒久対策（再発防止策）
</output_format>

パターン3: 出力形式の未指定

問題: 出力形式を指定しないと、AIは散文で回答する傾向があります。手順書として使いたい場合、散文のままでは使いにくい出力になります。

❌ Before（悪い例）
サーバー構築の手順を教えて

改善ポイント: 出力形式を「番号付きリスト、各ステップに3項目」と具体的に指定し、そのまま手順書として使える形式を促します。

ℹ️ After（改善例）
AlmaLinux 10にnginx + PHP-FPM環境を構築する手順を作成してください。
出力形式:
- 番号付きリストで各ステップを記載
- 各ステップに以下の3項目を含めること:
  (1) 実行コマンド（コピー&ペースト可能な形式）
  (2) 期待結果（コマンド実行後に確認すべきこと）
  (3) 補足（注意点や背景情報）
- 対象範囲: nginxインストールからPHP-FPM連携の動作確認まで

パターン4: 制約の欠如

問題: セキュリティ要件を指定しないと、AIはデフォルト設定（rootログイン許可、パスワード認証有効など）で回答する場合があります。本番環境に適用するとセキュリティリスクになります。

❌ Before（悪い例）
SSHの設定ファイルを作って

改善ポイント: セキュリティ要件を制約として列挙し、「何を許可するか」だけでなく「何を禁止するか」を明示します。

ℹ️ After（改善例）
<role>
あなたはセキュリティを重視するLinuxサーバー管理者です。
</role>
<task>
sshd_configファイルを作成してください。
</task>
<constraints>
- rootユーザーの直接ログインを禁止する（PermitRootLogin no）
- パスワード認証を無効にし、公開鍵認証のみ許可する
- SSHポートを22022に変更する
- 許可ユーザーをadminのみに限定する（AllowUsers admin）
- ログインの試行回数を3回に制限する
</constraints>
<output_format>
/etc/ssh/sshd_config としてそのまま配置可能な形式で出力してください。
各ディレクティブにインラインコメントで説明を付記してください。
</output_format>

パターン5: 過度な指示

問題: Claude Sonnet 4.6 / Opus 4.6はAdaptive Thinkingにより、タスクの複雑さに応じて自律的に思考の深さを調整します。過度に細かい制約を大量に並べると、AIが各制約の優先度を判断しにくくなり、かえって出力品質が下がることがあります。

❌ Before（悪い例）
以下のログを分析してください。
制約:
1. 必ず時系列順に並べ替えること
2. 各ログのタイムスタンプをISO 8601形式に変換すること
3. ログレベルごとに色分けの提案をすること
4. 各ログの発生元プロセスを特定すること
5. 関連するRFCがあれば番号を記載すること
6. 類似のログパターンをグループ化すること
7. 各グループに重要度スコア（1-10）を付けること
8. 過去に同様の障害があった場合の一般的な対処法を記載すること
9. ログの保存先パスを推定すること
10. 各ログに対して監視アラートの閾値を提案すること
11. 英語での要約も併記すること
12. Markdown形式とJSON形式の両方で出力すること

改善ポイント: 12個の制約を本質的な3つに絞り、残りはAIの自律的な判断に委ねます。制約は3〜5個が目安です。

ℹ️ After（改善例）
<role>
あなたはインフラエンジニアとして障害対応を行っています。
</role>
<task>
以下のログから障害の根本原因を分析してください。
</task>
<constraints>
- 時系列順に整理すること
- 根本原因の候補を可能性の高い順に最大3つ挙げること
- 各候補に対する確認手順を記載すること
</constraints>
<output_format>
Markdown形式で出力してください。
</output_format>
上記以外の分析の進め方はベストプラクティスに従ってください。

まとめ

この記事で扱った内容を整理します。

  • 6つの構成要素: 役割・タスク・制約・コンテキスト・出力形式・例。この6要素を意識するだけで、プロンプトの品質は大きく向上します
  • 3つの基本テクニック: Zero-shot（例示なし）、Few-shot（入出力例の提示）、Chain-of-Thought（段階的推論）。タスクの複雑さと出力形式の厳密さに応じて使い分けます
  • Claude固有パターン: XMLタグ構造化、長文コンテキストの配置順序、Adaptive Thinkingの活用
  • 実践例: 障害対応・設定ファイル生成・ドキュメント作成の3シナリオで、実際に使えるプロンプトを示しました

次にやること

以下の3つを、普段の業務で実践すると効果的です。

  1. 既存のプロンプトを1つ選び、6構成要素に分解して書き直す。 「どの要素が欠けていたか」を確認するだけでも、改善点が見つかります
  2. 同じタスクをZero-shot / Few-shot / CoTそれぞれで実行し、出力の違いを比較する。 テクニックによる出力差を体感すると、使い分けの判断が身につきます
  3. XMLタグ構造化を1つのプロンプトで試す。 構造化前後で出力品質がどう変わるか確認する

次の記事

プロンプト設計の次のステップとして、AIにツールを持たせて自律的にタスクを実行させる「エージェント」の構築方法を扱います。

次の記事 → ② AIエージェントエンジニアリング