生成AIを業務で活用する際、プロンプトエンジニアリングは重要な技術の一つです。
同じAIモデルでも、指示の与え方によって回答の品質や安定性が変わるケースがあります。
プロンプトは長く詳細に書けばよいわけではなく、目的に応じて必要な情報を伝えることが大切です。
本記事では、代表的な技法と、IT業務での具体的な活用方法を紹介します。
1. プロンプトエンジニアリングとは
プロンプトエンジニアリングとは、生成AIから目的に合った結果を得るために、入力する指示や情報を設計・改善する技術です。
役割・対象者・目的・条件・出力形式などを指定する方法がありますが、すべてを指定する必要はありません。
例えば、「会議の内容をまとめて」という単純な指示でも、AIは会議内容を要約してくれます。
ただし、議事録として利用したい場合は、単なる要約ではなく、決定事項や今後の対応を整理した結果が必要になります。
そこで、次のように回答例を添えて指示します。
以下の例と同じ形式で、会議内容を整理してください。
出力例
- 決定事項：新機能のリリースを11月に実施する
- 今後の対応：担当者が10月末までにテストを完了する
- 未決定事項：リリース後の運用体制
対象：（ここに実際の会議内容を入力）
このように、期待する出力例を提示することで、AIが回答の形式や整理方法を把握しやすくなり、求める結果を得られる可能性が高くなります。
これは、後述する One-shot（ワンショット）という技法を用いた例です。One-shotとは、1つの具体例を提示して、AIに期待する回答の形式や傾向を伝える方法です。
重要なのは、すべての条件を細かく指定することではなく、「目的に応じて必要な情報や例を与えること」です。
2. 代表的なプロンプトエンジニアリング技法
プロンプトエンジニアリングにはさまざまな技法があります。ここでは、その中から代表的なものを紹介します。
少し情報量が多く感じるかもしれませんが、まずは気軽に目を通してみてください。
技法名や細かな手順を暗記する必要はありません。「こういう指示の仕方もあるんだ」「この方法なら普段の業務にも活用できそうだ」と、AIの使い方の選択肢を知っていただくことが目的です。
| 技法 | 概要 | 使用例 |
|---|---|---|
| Zero-shot | 例を与えず、そのまま指示する | 「このエラーログの原因を説明して」 参考：Zero-shotの実行例 |
| One-shot | 1つの入出力例を与える | 「この形式を参考に、次のログも整理して」 |
| Few-shot | 複数の入出力例を与える | 「以下の3つの例と同じ基準で問い合わせを分類して」 |
| Chain-of-Thought（CoT） | 中間的な推論を利用して複雑な問題を解く | 「考慮すべき条件を整理し、解決方法を導いて」 |
| Self-Consistency | 複数の推論経路を生成し、回答の一致度などから結論を選ぶ | 「複数回独立に解き、結果を比較して」 |
| Tree-of-Thought（ToT） | 複数の解決候補を枝分かれさせて探索・評価する | 「3つの構成案を検討し、それぞれの発展案を評価して」 参考：Tree-of-Thought（ToT）の実行例 |
| Least-to-Most | 複雑な問題を小さな問題に分解し、順番に解決する | 「必要な前提条件から順番に問題を解いて」 参考：Least-to-Mostの実行例 |
| ReAct | 推論と外部ツールによる行動を組み合わせる | 「公式ドキュメントを検索し、確認結果をもとに回答して」 |
| Self-Refine | 生成結果を評価し、改善を繰り返す | 「作成したコードをレビューし、問題点を修正して」 |
| Generated Knowledge | 回答前に関連知識を生成して活用する | 「関連する技術概念を整理してから比較して」 |
| Prompt Chaining | 複数のプロンプトを連結して処理する | 「要件抽出→設計→レビューの順番で処理して」 |
| RAG | 外部情報を検索して回答に利用する | 「社内設計書を検索し、その内容に基づいて回答して」 |
※ ReActは推論と外部ツールの利用を組み合わせる手法、RAGは外部情報を検索・参照して回答に活用する仕組み、Prompt Chainingは複数のプロンプトを段階的につなぐ方法です。また、Self-ConsistencyやToTは、複数回の生成や探索を組み合わせて実装する場合があります。
3. IT業務で知っておくと便利な技法
IT業務として、目的にあった使い方があれば活用するとよいと思います。
例えばIT業界におけるSIer業務だと大雑把に以下のようなケースが存在しています。
1.仕様・設計
2.コーディング
3.テスト
4.調査
5.ドキュメント作成
身近な業務を例に、技法の活用方法を紹介します。
今回は「仕様・設計」について。
4 仕様・設計 にAIを使う場合の技法
仕様書の作成、要件整理、システム構成の検討などでは、複数の案を比較したり、作業を分解したりする技法が役立ちます。
① 新規システムの設計
既存の構成が決まっていない場合、複数の設計案の比較や、要件の段階的な整理に活用できます。
どのような形で要件を伝えられるかは状況によりますが...
AI利用関係なしに以下のように整理をしたと仮定します。
作業依頼と現時点で分かっている要件
【作業依頼】
社内の問い合わせ対応を効率化するため、社内マニュアルやFAQを参照して回答するAIチャットシステムを新規構築したい。実現方法を検討してほしい。
【現時点で分かっている要件】
■ 業務目的
社内問い合わせへの対応工数を削減したい
■ 利用者
社内従業員約500名
■ 機能要件
・チャット形式で質問できる
・社内マニュアルやFAQを参照して回答する
・回答の根拠となった文書を表示する
■ 非機能要件
・社外からアクセスできないようにする
・平日日中の利用を想定する
■ 制約条件
・AWS環境を利用する
■ 未決定事項
・システム構成
・使用サービス
・データ保存方式
・性能要件
・詳細なセキュリティ方式
・予算など
要件としてはある程度情報が揃っていますが、どう実現するかはまだ決まっていない状況です。
AIに読み込ませるための「目的や条件」をまとめた状態です。これを用いつつプロンプト技法を用いることで効果が期待できます。
| おすすめ技法 | 活用例 | 期待できる効果 | 指示例 |
|---|---|---|---|
| ToT | 複数のシステム構成案を探索・比較する | 一つの構成案に偏らず、コスト・性能・運用負荷などを多角的に検討できる | 「構成案を3つ作成し、それぞれの改善案を検討したうえで比較して」 |
| Least-to-Most | 要件を段階的に具体化する | 複雑な要件を整理しやすくなり、設計上の検討漏れを減らせる | 「業務要件から機能要件、非機能要件、システム構成の順に整理して」 |
② 実行例：3つの技法を比較
今回は同じ要件を使用し、ChatGPT（GPT-6）で Zero-shot・ToT・Least-to-Most の3つを試します。
| 技法 | 指示の進め方 | 今回の注目点 |
|---|---|---|
| Zero-shot | 要件を渡して、そのまま回答を求める | どこまで具体化されるか |
| ToT | 複数案を出し、評価・改善して選ぶ | 比較・改善の過程 |
| Least-to-Most | 課題を小さく分けて順番に解く | 要件から構成案へのつながり |
3つの技法の進め方
① Zero-shot
② Tree-of-Thought（ToT）
③ Least-to-Most
読み方：各技法の「入力プロンプト」と「AI回答全文」は、技法別の別記事にまとめています。実行結果の比較・分析は本章の最後にまとめています。
Zero-shot
技法の特徴： 回答例を与えず、要件から直接回答を求める方法です。普段の質問でも自然に使われています。
実行例（入力プロンプト・AI回答全文）
Tree-of-Thought（ToT）
技法の特徴： 複数の候補を作成し、評価・選択・改善・再評価を行う方法です。
実行例（入力プロンプト・AI回答全文）
Least-to-Most
技法の特徴： 大きな課題を小さな課題に分解し、前の結果を利用しながら順番に解決する方法です。
実行例（入力プロンプト・AI回答全文）
3つの技法の実行結果の比較・分析
各技法の実行結果を、共通の観点で比較します。
| 比較観点 | Zero-shot | ToT | Least-to-Most |
|---|---|---|---|
| 検討の進め方 | 要件から直接構成案を提示 | 3つの構成案を評価・選択し、改善・再評価 | 課題を分解し、前段階の結果を利用して順番に検討 |
| 構成案の比較・選定 | AWSサービスや構成案を提示したが、評価基準・選定理由は不十分 | 案ごとのメリット・デメリットや評価理由を整理 | 要件を段階的に整理したうえで構成案を提示 |
| 未決定事項の扱い | 未確定の性能要件に根拠のない仮の数値を設定 | 性能要件や予算を確認事項として整理 | 確定事項と不足情報を区別して整理 |
| 検討根拠の明確さ | サービス選定の理由が十分に説明されなかった | 複数案の評価と改善の過程を提示 | 各段階の検討結果と構成案のつながりを提示 |
| 課題・注意点 | 数値の根拠、サービス選定理由、セキュリティ詳細の確認が必要 | 評価基準や改善後の選定結果について妥当性の確認が必要 | 段階的に検討しても、最終構成の妥当性が保証されるわけではない |
各技法の特徴・課題
Zero-shot
特別な技法を指定しなくても、AWSサービスの選定、構成図、セキュリティ対策、構築スケジュールなど、幅広い提案が得られました。一方、未決定事項を仮定で補っている部分があり、提案内容の妥当性を確認する必要があります。
Tree-of-Thought（ToT）
複数の構成案を比較し、それぞれの弱点を改善する過程が回答に表れました。ただし、評価や改善が行われていても、評価基準や最終的な選定結果が適切であるかは別途確認が必要です。
Least-to-Most
要件や課題を分解し、前段階の結果を利用しながら構成案を具体化する過程が回答に表れました。ただし、段階的に検討したことだけで、最終構成の妥当性が保証されるわけではありません。
5. まとめ
今回の比較では、同じ要件を与えても、使用するプロンプトエンジニアリング技法によって、回答の内容や検討の進め方に違いが見られました。
Zero-shotでは直接的な構成案の提示、ToTでは複数案の比較・改善、Least-to-Mostでは課題の分解と段階的な検討という、それぞれの技法の特徴が回答に表れています。
このように、プロンプトエンジニアリング技法を変えることで、同じ課題に対しても異なる観点や検討過程を持つ回答が得られることを確認できました。
実際の業務で活用するには、追加情報の収集や、提案内容の妥当性を確認するレビュー・検証が必要です。
プロンプトエンジニアリングは回答の質を高める手段であり、AIの回答をそのまま正解とせず、人間が判断することが重要です。
常にZero-shotから会話を開始し、追加の質問や条件を重ねながら少しずつ設計を固めていく方法でも問題ありませんが、会話は最初の回答に引きずられることが懸念となります。
長期間の会話を行う想定であれば、このような技法による出発も試してみてください。
「コーディング・テスト・調査・ドキュメント」に関しては次回以降紹介いたします。