これは書籍 LLMのプロンプトエンジニアリング - O’Reilly Japan を NotebookLM を用いてブログ記事風にまとめてもらったものです。

LLM開発の羅針盤！『LLMのプロンプトエンジニアリング』書評：GitHub Copilot開発者が贈る、実践者のための必携ガイド

現代社会に深く浸透しつつある大規模言語モデル（LLM）は、私たちの仕事や生活に革新をもたらしていますが、その強力な機能を最大限に引き出し、期待通りの成果を得るためには、単に問いかけるだけでは不十分です。「プロンプトエンジニアリング」は、LLMがユーザーの意図を正確に理解し、望ましい出力を生成するための、まさに中核となる技術です。ジョン・ベリーマンとアルバート・ジーグラーによる書籍『LLMのプロンプトエンジニアリング』は、この不可欠な分野において、実践者にとっての決定版と言えるでしょう。

GitHub Copilotの開発を牽引してきた著者らは、コード生成の最適化、ユーザーとのインタラクション設計、そして幻覚（ハルシネーション）の抑制といった数々の現実的課題に直面し、それを乗り越えてきました。数百万規模のユーザーにサービスを提供するAIシステムの構築を通じて得られた彼らの知見は、本書に学術的な裏付けと、現場で実証された深い実践的洞察の融合をもたらしています。プロンプトの設計原則、効果的なコンテキスト管理、そしてモデルの意図的なアラインメント（調整）といった複雑なテーマに対し、具体的な解決策と深い理解を提供するのが、本書の大きな特徴です。

LLMアプリケーション開発を体系的に学ぶ：3部構成のロードマップ

本書は、LLMアプリケーション開発の全工程を網羅する3つのパートで構成されており、プロンプトエンジニアリングの基本から最先端の応用、そしてその未来までを体系的に探求できます。

第1部：基礎の確立 – LLMの本質を掴む

このパートでは、プロンプトエンジニアリングの理解に不可欠な基礎知識を簡潔に解説します。LLMは、 GPTアーキテクチャの進化を通じて、現在のAI革命の火付け役となりました。開発者は、LLMがテキストを「トークン」という単位で認識し、統計的に最も自然な続きを生成する「ドキュメント補完エンジン」であるという本質を理解することが不可欠です。モデルが学習データ内のパターンを模倣しようとすることが、時に事実と異なる「ハルシネーション」（幻覚）を引き起こす根源であることも明かされます。

単なる補完エンジンだったLLMが、ユーザーと対話可能なアシスタントへと進化した背景には、 RLHF（人間のフィードバックによる強化学習）があります。これにより、モデルはユーザーの指示に従い、より有用で、正直で、無害な応答を生成するように調整されました。このアラインメントのプロセスは、プロダクトマネージャーが製品の信頼性とユーザー体験を向上させる上で重要な要素となります。

OpenAIのチャットAPIが導入後わずか4ヶ月で全APIトラフィックの97%を占めるまでになった事実が示す通り、対話形式でのLLM活用が現代のスタンダードであることが強調されています。プロンプトエンジニアリングは、LLMとの「脚本作成」に例えられ、開発者がアプリケーションの意図をモデルに伝えるための創造的な作業であることが示唆されます。

第2部：実践的テクニック – 効果的なプロンプトの構築術

このパートは、開発者がLLMから望ましい出力を引き出すための具体的な戦略を、プロダクトマネージャーがLLM機能の品質と信頼性を確保するための基盤を深く理解できるよう、詳細に掘り下げられています。

プロンプトコンテンツの設計とRAGによる知識拡張

プロンプトに組み込む情報は、アプリケーションの普遍的な指示を担う「静的コンテンツ」と、特定の状況に応じた背景を提供する「動的コンテンツ」とに区分されます。
開発者は、静的コンテンツを用いて、Markdown形式での出力やハイパーリンクの使用禁止など、タスクの全体像や望ましい形式をモデルに明確に指示することで、アプリケーションの振る舞いを定義します。
プロダクトマネージャーは、この区分けがLLMアプリケーションの柔軟性とパーソナライズにどう寄与するかを理解することで、より豊かなユーザー体験設計に繋げられるでしょう。

RAG（検索拡張生成）の深掘り

動的コンテンツの収集において、RAG（Retrieval-Augmented Generation：検索拡張生成）は極めて重要な役割を果たします。LLMの知識は訓練データに限定され、最新情報や特定のデータベースにはアクセスできません。RAGは、外部の情報源（検索結果、特定のドキュメント、ユーザー履歴など）から関連性の高い情報を動的に取得し、それをプロンプトに組み込むことで、LLMの知識の限界を補い、ハルシネーションを大幅に軽減する強力な手法です。

開発者はRAGの実装プロセスとして、以下のステップを理解し、適用する必要があります。

1. インデックス化（オフライン）: 大規模なドキュメント群を意味のある「スニペット」に分割し、それぞれを「埋め込みモデル」で数値ベクトルに変換します。これらのベクトルと元のスニペットは「ベクトルデータストア」に保存されます。
2. 検索（リクエスト時）: ユーザーのクエリもベクトルに変換され、ベクトルデータストア内で意味的に最も近いスニペットが効率的に検索・取得されます。検索手法には、キーワードの一致に頼る「語彙検索」と、単語の「意味」に基づいて関連性を判断する「ニューラル検索」があります。ニューラル検索は埋め込みモデルにより同義語や表現の揺れにも対応し、より高度な関連性発見が可能です。
3. プロンプトへの組み込み: 取得したスニペットを、LLMへのプロンプトに動的コンテキストとして挿入します。

プロダクトマネージャーは、RAGが、最新性、正確性、信頼性が求められるアプリケーション（例：医療チャットボット）において、製品の品質とユーザーの信頼を獲得するための不可欠な要素であることを認識すべきです。

プロンプトに含めたいコンテキストがトークン予算を超える場合、LLM自身を使った「要約」が有効です。開発者は、階層的要約や、特定の目的に特化した要約を実装することで、重要な情報を失うことなくコンテキストを圧縮できます。

プロンプトの構造化とモデル出力の制御

プロンプトの組み立てでは、「導入部、コンテキスト、リフォーカス、移行」という理想的な構造が提示されています。これは、モデルの注意を効果的に引きつけ、タスクの核心へと導くための指針です。モデルが学習時に頻繁に接したドキュメント形式にプロンプトを合わせる「赤ずきんの原則」は、開発者が予測可能で安定した出力を得るための鍵となります。例えば、アドバイス会話、分析レポート、構造化ドキュメントなどの形式を利用します。

モデル出力の厳密な制御

LLMの出力を厳密に制御するためには、APIパラメータの活用が不可欠です。

• max_tokensパラメータで生成されるトークンの最大数を設定することで、出力の長さを制限し、アプリケーションの効率とコストを最適化できますが、補完が途中で不自然に切れるリスクもあります。
• stopシーケンスを設定することで、特定の文字列が出現した時点で生成を停止させ、回答の本体が終わったことを示すマーカー（例：セクションの終了を示すヘッダーなど）を検知して、きれいに補完を終了させることができます。

LLMが各トークンを生成する際に提供する「logprob」（トークン確率の自然対数）は、開発者にとって高度な分析ツールとなります。

• 補完全体の平均 logprob を計算することで、モデルがその補完をどれだけ「確信して」生成したかの指標を得られます。
• logprob はテキスト分類タスクにも有効で、例えばあるレビューが肯定的か否定的かを判断する場合、positiveとnegativeという2つのトークンの logprob を比較することで分類できます。
• プロンプト内の各トークンがどれだけ「注目」されたか（アテンションの重み）を分析することで、モデルがどの単語やフレーズを重要視したかを知り、プロンプトを改善するための手がかりが得られます。

生成される出力の「創造性」を調整する「temperature」パラメータも重要です。

• temperatureが 0 の場合、モデルは最も確率の高いトークンのみを選択し、決定論的で再現性の高い出力（コード生成に最適）を生成します。
• 0.1〜0.4 は、最有力候補にごくわずかに劣るトークンを拾わせ、少数の異なる回答候補を生成してからフィルタリングする戦略や、temperature が 0 の場合より少し創造的な回答を望む場合に適します。
• 0.5〜0.7 は、バランスの取れた創造性（マーケティングコピーなど）を追求する場合に利用されます。
• temperatureが 1より大きい場合、トレーニングデータよりも「雑」な出力や、標準的な流れから逸脱した奇妙な継続を選びやすくなり、エラー率が徐々に増加するリスクが高まります。

モデルの選択は、プロダクトマネージャーと開発者双方にとって戦略的な決定です。

1. 商用サービス（MaaS）: OpenAI、Anthropic、Googleなどが提供し、セットアップが容易で最新モデルを利用できますが、コストとデータプライバシーの懸念があります。
2. オープンソースモデル: Hugging Faceなどで公開され、自社インフラにホストすることでデータプライバシーを制御でき、コストを抑えられる可能性がありますが、セットアップとメンテナンスに専門知識が必要です。
3. ファインチューニングされたモデル: 自社データで既存モデルを再トレーニングすることで、特定のドメインやタスクに特化できますが、計算リソース、データ、時間が必要です。 アプリケーションの要件（パフォーマンス、コスト、プライバシー、カスタマイズ性など）に応じて最適なモデルを選択することが、成功への道筋となります。

第3部：エキスパートの領域 – 高度なLLMアプリケーションの創造

このパートでは、単なるQ&Aを超え、より複雑な目標を達成するLLMアプリケーションの設計と構築に焦点を当てます。開発者は具体的な実装テクニックを、プロダクトマネージャーは製品の可能性と戦略的展望を深く理解できるでしょう。

LLMエージェントによる実世界との連携と高度な推論

LLMが知識の陳腐化、計算能力の欠如、実世界での実行能力の欠如といった制約を克服するためには、外部のAPIやサービスを呼び出す「ツール」の使用が不可欠です。

ツールの使用とエージェントの構築

開発者は、モデルがいつ、どのツールを、どのような引数で呼び出すかを判断できるように、ツールの定義（関数名、引数、説明）を正確に設計する必要があります。アプリケーションはモデルからのツール呼び出しリクエストを解釈し、対応する関数を実行して、その結果を tool という役割を持つメッセージとして会話履歴に追加します。この「思考→アクション→観察」のループを繰り返すことで、エージェントは複雑なタスクを遂行できるようになります。

ツール定義のガイドラインには、以下の考慮事項が含まれます。

• ツールの選択: モデルが一度にアクセスできるツール数を制限し、各ツールは単一の明確なタスクを実行するよう設計します。
• 命名: 人間が理解しやすい自己記述的な名前を付けます。
• 定義: 簡潔ながら、モデルが使用法を理解できる十分な詳細を含めます。
• 引数: できるだけ少なく単純にし、モデルが推測できない場合はユーザーに尋ねるか、アプリケーション側でデフォルト値を設定します。
• 出力: モデルが解釈しやすい簡潔で一貫性のある形式（テキストまたは構造化データ）にします。
• エラー処理: モデルが問題を理解し再試行できるよう、意味のあるエラーメッセージを返します。
• 「危険な」ツールの実行: 実世界に変更を加える可能性のあるツールについては、実行前に必ずユーザーの明示的な承認を得るステップをアプリケーションに組み込みます。

プロダクトマネージャーは、ツール連携が製品の機能性を飛躍的に拡張し、ユーザーがLLMを通じて実世界とインタラクションできるようになる（例：会議の招待、旅行予約など）ことを理解し、潜在的なリスク（「危険な」ツールの実行前のユーザー認可）にも配慮したUX設計が求められます。

推論能力の強化

LLMの推論能力を向上させるために、「思考の連鎖（CoT）プロンプティング」や「ReAct（Reasoning and Acting）」といったテクニックが紹介されています。

• 思考の連鎖（CoT）プロンプティングは、モデルに最終回答に至るまでの思考プロセスを段階的に明示させることで、より論理的な推論を促します。
• ReAct は、CoTの推論とツールの実行（アクション）を組み合わせ、「思考→アクション→観察」のサイクルを繰り返すことで、複雑な多段階のタスクを解決します。

さらに、ReActを超えて、「Plan-and-Solveプロンプティング」（まず包括的な計画を立ててから実行）、「リフレクション」（失敗の理由を自己分析し学習）、「Branch-Solve-Merge」（問題を複数のエージェントに渡し、解決策を統合）といった高度な推論テクニックも探求されます。開発者はこれらの推論フレームワークを実装することで、より堅牢でインテリジェントなエージェントを構築でき、プロダクトマネージャーは、複雑なユーザーの課題に対し、より確実で信頼性の高い解決策を提供できるようになります。

会話型エージェントの構築においては、コンテキストウィンドウの制約内で、システムメッセージ、過去の会話履歴、現在のやり取りといった多様な情報源から、最も関連性の高いコンテキストを選択し整理することが、開発者にとって重要な課題です。プロダクトマネージャーは、エージェントが応答を生成している間の「処理中の表示」、ツールの使用状況を示す「ツールの可視化」、ユーザーによる修正や認可のステップなど、「ユーザー体験（UX）」の考慮が製品の信頼性と使いやすさを高める上で不可欠であることを理解すべきです。

LLMワークフローによる自律的なタスク遂行と評価

会話型エージェントが台本のないオープンエンドな問題解決に有効である一方、目標が明確でプロセスが定型的なタスクには「LLMワークフロー」が適しています。

LLMワークフローの基本と実装

基本的なワークフローは、あらかじめ定義された一連のタスクを、決められた順序で実行するものです。プロダクトマネージャーは、タスクの性質に応じてエージェントかワークフローかを選択する戦略的判断が求められます。

開発者はワークフローを以下の5つのステップで構築します。

1. 目標定義: ワークフローが達成すべき最終出力を特定します。
2. タスク指定: 目標を達成するための一連のサブタスクに分割し、各タスクの入出力を定義します。
3. タスク実装: 各タスクを個別に実装します。LLMを使用するタスクでは、テンプレート化されたプロンプトや、構造化されたコンテンツ抽出のためのツールベースのアプローチが有効です。
4. ワークフロー組み立て: タスクを相互に接続します。組み立て形式には、単純な「パイプライン」、複雑な依存関係を持つ「有向非巡回グラフ（DAG）」、フィードバックループを実装する「巡回グラフ」などがあり、開発者はタスク間の接続方法を設計します。
5. 最適化: 品質、パフォーマンス、コストの観点からワークフローを改善します。

高度なLLMワークフロー

基本的なワークフローは硬直的で、設計外のシナリオに適応できません。LLMにさらに自律性を与えることで、より高度なワークフローを構築できます。

• LLMエージェントによるワークフローの駆動の許可: ワークフローのタスク間の流れ自体を、LLMエージェントに決定させることができます。
• ステートフルなタスクエージェント: 各タスクを、自身の状態（アセット）を管理する独立したエージェントとして実装します。
• 役割と委任: 複数のエージェントに異なる役割を与え、チームとして協力させるアプローチです（例：AutoGen）。

LLMアプリケーションの評価戦略

アプリケーションの品質を確保するためには「評価」が不可欠です。LLMの出力は非決定的であるため、従来のソフトウェアテストとは異なるアプローチが必要です。

オフライン評価は、実際のユーザーに公開する前に行われる評価です。

• サンプルスイート: 現実世界のタスクを反映したプロンプトと、それに対する理想的な応答のペアを集めたデータセットを使用します。
• 解決策の評価手法: 生成された解決策（補完）を評価するために、「LLM-as-Judge」（別の強力な LLM に評価させる） や「人間による評価」などが行われます。SOMA（Subjective Objective Metric Alignment）アセスメントは、主観的な品質と客観的な指標の相関を評価する手法です。

オンライン評価は、アプリケーションを実際のユーザーに公開して行われる評価です。

• A/Bテスト: 異なるバージョンのアプリケーションをユーザーグループに割り当て、パフォーマンスを比較します。
• メトリクス: 「直接的なフィードバック」（役に立ったかの質問）、「機能の正確性」（コードのコンパイル、予約完了など）、「提案の受け入れ」（Copilotの補完受け入れ率など）、「付随的メトリクス」（応答時間、会話の長さなど）を追跡します。

開発者はこれらの評価手法を実装することで、アプリケーションの品質を客観的に測り、問題を特定できます。プロダクトマネージャーは、オンライン評価を通じて製品の価値とユーザー満足度を測定し、継続的な改善サイクルを回すための指標とします。

本書の価値と対象読者

本書の強みは多岐にわたります。複雑な概念を明瞭に解説し、実践で即座に役立つプロンプトパターンを豊富に提供している点、そしてAI開発における倫理的側面にも深く言及している点です。何よりも、学術的な知見と現場で実証された実践的ノウハウが密接に結びついている点が、本書を唯一無二の存在にしています。

一方、わずかな課題も指摘されています。API参照部分は技術の進化が速いため、急速に時代遅れになる可能性がある点 や、PythonやAPIに不慣れな初心者にとっては、高度な内容を扱う章の理解が難しいかもしれないという点 です。しかし、これらは本書が提供する本質的な価値を大きく損なうものではありません。

本書は、特に以下のような読者にとって計り知れない価値を提供します。

• LLMを活用した革新的なアプリケーションを構築しようとしている開発者。
• AI機能の導入や評価を担うプロダクトマネージャー。

結論

総じて、『LLMのプロンプトエンジニアリング』は、単なるAPIの利用方法を超え、堅牢で拡張性の高いLLMアプリケーションを設計・構築しようと志すエンジニアにとって、まさしく指針となる一冊です。プロンプトの設計原則から評価のフレームワークに至るまで、本書で紹介される体系的な方法論は、今後のLLMアプリケーション開発の揺るぎない基礎であり続けるでしょう。

LLMが生活の隅々にまで浸透し、その機能が遍在的となる一方で、その本質が時に誤解されがちな現代において、本書は極めて重要な洞察を提供します。それは、LLMが根源的に「学習時に見たテキストパターンを模倣する、テキスト補完エンジンである」という理解、そして「LLMの思考様式に共感し、その特性を理解した上で、必要な情報を適切な形で提供することの重要性」です。

この変革の時代において、開発者は本書から得たツールと知識を武器に、革新的なアプリケーションを構築する責務を負います。プロダクトマネージャーは、本書を通じてLLMの真の可能性と限界を理解し、ユーザーに真に価値あるAI機能を提供する戦略を練るでしょう。流動的な変化を恐れず受け入れ、実験を重ね、創造性を失うことなく、LLMの力を最大限に活用し、未来を形作っていくための確かな道標が、この一冊にはあります。