プロンプトエンジニアリング実践

プロンプトの構造 -- 4要素フレームワーク

なぜ構造が必要なのか

「いい感じに要約して」と「あなたはテクニカルライターです。以下の議事録を経営層向けに3行で要約してください。決定事項と未決事項を明記すること」では、出力の質がまるで違います。差を生むのはプロンプトの構造です。

思いつきで書いたプロンプトは、AIに「何を求めているか」が曖昧になりがちです。4つの要素を意識するだけで、出力の精度と再現性が劇的に上がります。

%%{init:{'theme':'dark','themeVariables':{'primaryColor':'#00A5BF','primaryBorderColor':'#007A8F','primaryTextColor':'#e8e8e8','lineColor':'#00A5BF','secondaryColor':'#1a1a1a','background':'#141414','mainBkg':'#1a1a1a','nodeBorder':'#00A5BF'}}}%%
graph TB
  R["Role
役割の指定"] --> C["Context
背景情報の提供"]
  C --> CN["Constraints
制約条件の設定"]
  CN --> O["Output Format
出力形式の指定"]
  style R fill:#1a1a1a,stroke:#00A5BF,stroke-width:2px
  style C fill:#1a1a1a,stroke:#00A5BF,stroke-width:2px
  style CN fill:#1a1a1a,stroke:#00A5BF,stroke-width:2px
  style O fill:#1a1a1a,stroke:#00A5BF,stroke-width:2px

要素1: Role(役割)

AIに「誰として」答えてほしいのかを明示します。「あなたは10年経験のある人事コンサルタントです」と書くだけで、回答のトーン、専門性、視点が変わります。役割を指定しないプロンプトは、AIが汎用的な回答に落ち着いてしまう原因のひとつです。

要素2: Context(文脈)

AIはあなたの業務背景を一切知りません。「誰が」「何のために」「どんな状況で」使うのかを伝える必要があります。文脈が抜けると、見当違いの回答が返ってきます。

要素3: Constraints(制約)

「やってほしくないこと」「守ってほしいルール」を明示します。文字数制限、禁止ワード、対象範囲、使用言語など。制約がないと、AIは自分の判断で勝手に範囲を広げたり、不要な情報を付加します。

• 文字数制限 -- 「300文字以内で」「箇条書き5項目で」
• トーン制約 -- 「カジュアルに」「敬語で」「技術者向けに」
• 範囲制約 -- 「2025年以降の情報のみ」「日本市場に限定」
• 禁止事項 -- 「推測で答えない」「URLを生成しない」

要素4: Output Format(出力形式)

どんな形で出力してほしいかを具体的に指定します。「表形式で」「JSON形式で」「Markdown箇条書きで」と書くだけで、後続作業が楽になります。形式を指定しないと、長文の説明が返ってきて加工に手間がかかるケースが多いでしょう。

4要素を組み合わせた完成形

基本テクニック -- Zero-shot / Few-shot / CoT

プロンプトの「型」を知っているかどうかで、同じタスクでも出力品質に差が出ます。3つの基本テクニックを押さえましょう。

Zero-shot: 指示だけで解かせる

例示を一切与えず、指示だけでタスクを実行させるのがZero-shot。最もシンプルで、簡単なタスクには十分です。ただし「どんな出力が良いか」のイメージがAIに伝わりにくく、出力のブレが大きくなりがちという弱点があります。

Few-shot: 例を見せて学ばせる

2〜5個の入出力例をプロンプトに含める手法です。AIは例から「パターン」を読み取り、それに倣って出力します。分類タスクや、特定のフォーマットに従わせたい場合に強い。Zero-shotで出力がブレる場合、例を3つ追加するだけで安定することが多い。

Chain of Thought (CoT): 段階的に考えさせる

「ステップバイステップで考えてください」と指示するだけで、AIの推論精度が上がります。2022年のGoogle Brainの論文で効果が実証されました。特に数学的推論、論理問題、複雑な分析タスクで威力を発揮します。

理由は単純で、LLMは「次のトークン」を1つずつ生成する仕組みです。途中の推論過程を出力させることで、それが次のトークン生成のコンテキストになり、飛躍的な間違いを抑制できます。

テクニック使い分け表

高度テクニック -- ToT / ReAct / メタプロンプト

基本テクニックで対応しきれない複雑なタスク -- 多面的な分析、試行錯誤が必要な問題、プロンプト自体の生成 -- には、より高度なテクニックが必要です。

Tree of Thought (ToT): 探索的推論

CoTが「1本道の思考」だとすれば、ToTは「複数の思考ルートを並行探索し、最良の結論を選ぶ」手法です。2023年のPrinceton/Google DeepMindの論文で提案されました。

人間が難しい問題を考えるとき、「AとBの2つのアプローチがあるな。Aで進めてみよう...いや、行き詰まった。Bに切り替えよう」と試行錯誤しますよね。ToTはこの思考プロセスをAIに再現させます。

ReAct: 推論 + 行動の交互実行

Reasoning(推論)とAction(行動)を交互に繰り返すフレームワークです。AIエージェントの基盤技術でもあります。「考える → 行動する → 観察する → また考える」のループで、外部ツールやデータソースを組み合わせた問題解決が可能になります。

現時点でチャットUIで完全なReActを再現するのは難しいですが、プロンプトで「思考と行動を交互に記述せよ」と指示することで、ReAct的な出力を得られます。

メタプロンプト: プロンプトを生成するプロンプト

「最適なプロンプトを作ってくれ」とAIに依頼する、一段上のテクニックです。自分でプロンプトを書く労力を省けるだけでなく、AIが持つプロンプト設計の知識を活用できます。特に、自分が不慣れな領域のプロンプトを作る場面で有効です。

Self-Consistency: 多数決で精度を上げる

同じ質問を複数回投げて、最も多い回答を採用する手法です。単発の回答よりも信頼性が上がります。特に「正解がある」タイプのタスク(分類、計算、事実確認)で有効です。

マルチモーダルプロンプト -- 画像 / PDF / 音声

テキスト入力だけがプロンプトではありません。画像、PDF、音声ファイルをAIに渡して処理させる「マルチモーダル」が、2025年以降の標準になりました。

画像入力: スクリーンショットから一発で分析

写真やスクリーンショットをAIに渡すだけで、内容の説明、データの抽出、改善提案が得られます。手作業でテキスト化する必要がなくなりました。

PDF入力: 長文レポートの瞬間解析

数十ページのPDFをアップロードし、要約、特定情報の抽出、比較分析を指示できます。Claude(200Kトークン対応)やGemini(100万トークン対応)は、1冊の書籍分の情報を一度に処理可能です。

音声入力: 会議メモから文書生成

音声ファイルの書き起こし(Whisper、Geminiの音声対応)と、その内容に基づく文書生成を組み合わせられます。会議音声 → 議事録 → アクションアイテム抽出が1つの流れで完結します。

マルチモーダル対応ツール比較

画像入力のプロンプト設計パターン

画像をAIに渡すとき、プロンプトの書き方で出力の粒度と方向性が大きく変わります。漠然と「この画像を見て」と投げるのと、観点を絞って指示するのとでは、得られる価値がまるで違います。

パターン1は情報量は多いがアクションに繋がりにくい。パターン2・3は目的が明確な分、出力が即座に使えます。実務では2と3を使う場面が圧倒的に多いでしょう。

画像入力のプロンプトパターン -- 汎用記述、分析指示、評価指摘の3パターン

パーソナルAI構築 -- Gem / GPTs / Claude Projects

毎回同じ指示を書くのは非効率です。主要3プラットフォームには、カスタム指示とナレッジベースを組み込んだ「自分専用AI」を作る機能があります。

3プラットフォーム比較

Gem / GPTs / Claude Projects 機能差異の詳細比較

カスタム指示書の設計フレームワーク

どのプラットフォームでも、カスタム指示の「型」は共通です。以下の7項目を埋めるだけで、業務に即したAIアシスタントが作れます。

ナレッジベースの設計

添付するファイルの選び方で、AIの回答品質が大きく変わります。

• FAQ集 -- よくある質問と回答を構造化して格納。最も効果が出やすい
• 社内マニュアル -- 業務手順書、ルールブック。AIが「社内のやり方」を理解する
• 過去の成果物 -- 過去の提案書、レポート。出力のトーンや品質の参考にさせる
• 用語集 -- 業界/社内固有の用語。誤った用語の使用を防ぐ

業務別テンプレート集 -- 議事録 / レビュー / 分析 / 提案書

実務で繰り返し使えるプロンプトテンプレートを4カテゴリ分用意しました。テンプレートをそのまま使うのではなく、自社の文脈に合わせてカスタマイズして使ってください。

カテゴリ1: 議事録処理

テンプレート1-1: 議事録の構造化

テンプレート1-2: 議事録からアクションアイテム抽出

テンプレート1-3: 議事録の要約メール生成

カテゴリ2: コードレビュー

テンプレート2-1: 包括的コードレビュー

テンプレート2-2: プルリクエストの説明文生成

カテゴリ3: データ分析

テンプレート3-1: CSVデータの傾向分析

テンプレート3-2: KPIダッシュボードレポート

カテゴリ4: 提案書作成

テンプレート4-1: 業務改善提案書

テンプレート4-2: 比較検討資料

テンプレート4-3: 経営層向けエレベーターピッチ

評価と改善サイクル -- A/Bテスト、スコアリング

同じプロンプトでも、実行するたびに出力が微妙に異なります。「なんとなく良さそう」ではなく、定量的に評価し、改善する仕組みが必要です。

なぜ評価が必要か

LLMはtemperatureパラメータで出力のランダム性を制御しています。デフォルト設定では同じプロンプトでも出力にバラつきが生じます。さらに、モデルのアップデートで出力傾向が変わることもある。プロンプトを「書いて終わり」にすると、いつの間にか品質が劣化するリスクがあります。

評価の5軸

A/Bテストの方法

2つのプロンプト(AとB)で同じタスクを実行し、出力を比較します。変更するのは1要素だけにしてください。複数要素を同時に変えると、どの変更が効果をもたらしたか判別できません。

%%{init:{'theme':'dark','themeVariables':{'primaryColor':'#00A5BF','primaryBorderColor':'#007A8F','primaryTextColor':'#e8e8e8','lineColor':'#00A5BF','secondaryColor':'#1a1a1a','background':'#141414','mainBkg':'#1a1a1a','nodeBorder':'#00A5BF'}}}%%
graph LR
  A["プロンプトA
(現行版)"] --> T["同一タスク
で実行"]
  B["プロンプトB
(改善案)"] --> T
  T --> E["5軸で
スコアリング"]
  E --> D{"Bが上回る?"}
  D -->|Yes| AD["Bを採用"]
  D -->|No| K["Aを維持
別の改善を検討"]

スコアリングシートの使い方

5軸それぞれを1〜5点で評価し、合計25点満点でスコアリングします。20点以上を「実用レベル」、15〜19点を「改善の余地あり」、14点以下を「要修正」とする基準が実用的です。

改善サイクル

評価 → 問題特定 → 仮説立て → 修正 → 再評価の5ステップを回します。

1. 評価: 5軸スコアリングで現状を定量化する
2. 問題特定: スコアが低い軸を特定する(例: 完全性が2点)
3. 仮説: なぜ低いのか仮説を立てる(例: 出力形式の指定が曖昧)
4. 修正: 仮説に基づいてプロンプトを1箇所修正する
5. 再評価: 修正後のプロンプトを再度スコアリングし、改善を確認する

セキュリティ -- インジェクション防御、ガードレール設計

プロンプトを業務で運用する以上、セキュリティは避けて通れません。AIの出力が安全であること、指示が悪用されないことを担保する設計が必要です。

プロンプトインジェクションとは

ユーザーの入力に「システムプロンプトを無視して...」のような悪意ある指示を紛れ込ませ、AIの挙動を乗っ取る攻撃手法です。Webアプリの文脈でSQLインジェクションがあるように、LLMにはプロンプトインジェクションがあります。

防御の3層構造

層1: システムプロンプトでの防御

層2: 入力バリデーション

ユーザーの入力がシステムに到達する前に、危険なパターンをフィルタリングします。

• 文字数制限 -- 異常に長い入力をブロック
• パターンマッチング -- 「ignore previous instructions」等の既知パターンを検出
• 言語検出 -- 想定外の言語(エンコーディング攻撃)をブロック

層3: 出力バリデーション

AIの出力が安全かどうかを、出力後にチェックします。

• 個人情報検出 -- 正規表現でメールアドレス、電話番号等をスキャン
• 禁止ワード検出 -- 出力に含まれてはいけないキーワードのリスト
• 人間レビュー -- 高リスクな出力はリリース前に人間が確認

ガードレール設計のテンプレート

ガードレール設計の3層構造

ガードレールを「入力」「処理中」「出力」の3層で設計すると、各層の責務が明確になり、運用中の改善もしやすくなります。

%%{init:{'theme':'dark','themeVariables':{'primaryColor':'#00A5BF','primaryBorderColor':'#007A8F','primaryTextColor':'#e8e8e8','lineColor':'#00A5BF','secondaryColor':'#1a1a1a','background':'#141414','mainBkg':'#1a1a1a','nodeBorder':'#00A5BF'}}}%%
flowchart TB
  U["ユーザー入力"] --> L1
  subgraph L1["Layer 1: 入力フィルタ"]
    F1["文字数制限
最大2000文字"] --> F2["パターン検出
ignore / 無視して / forget"] --> F3["言語・エンコード検査
Base64攻撃等をブロック"]
  end
  L1 --> L2
  subgraph L2["Layer 2: システムプロンプト防御"]
    S1["ロール固定
絶対に変更不可"] --> S2["禁止事項の優先順位
セキュリティ指示 > ユーザー入力"] --> S3["対応範囲の限定
範囲外は定型文で拒否"]
  end
  L2 --> L3
  subgraph L3["Layer 3: 出力検査"]
    O1["PII検出
メール/電話番号/住所"] --> O2["禁止ワード検出
システムプロンプト断片等"] --> O3["ログ記録
全入出力を監査用に保存"]
  end
  L3 --> R["AIの応答をユーザーに返す"]

ガードレール3層設計 -- 各層が独立して機能するため、1層が突破されても次で食い止められる

総合ハンズオン: 業務特化AIアシスタント3つを完成

ここまでに学んだ全てを統合して、実務で使えるAIアシスタントを3つ構築します。各アシスタントにカスタム指示書、テストケース、評価スコアを設定してください。

%%{init:{'theme':'dark','themeVariables':{'primaryColor':'#00A5BF','primaryBorderColor':'#007A8F','primaryTextColor':'#e8e8e8','lineColor':'#00A5BF','secondaryColor':'#1a1a1a','background':'#141414','mainBkg':'#1a1a1a','nodeBorder':'#00A5BF'}}}%%
graph LR
  S1["Sec01-03
テクニック"] --> BUILD["3つのAI
アシスタント構築"]
  S4["Sec04-05
マルチモーダル
パーソナルAI"] --> BUILD
  S6["Sec06
テンプレート"] --> BUILD
  S7["Sec07
評価"] --> BUILD
  S8["Sec08
セキュリティ"] --> BUILD
  BUILD --> A1["1. 議事録AI"]
  BUILD --> A2["2. コードレビューAI"]
  BUILD --> A3["3. データ分析AI"]

テンプレートダウンロード

本コースで使用したテンプレート集です。業務に合わせてカスタマイズして使ってください。