レビュー
概要
大規模言語モデル（LLM）を「便利な自動文章生成」ではなく、再現性のある業務ツールとして扱うためのプロンプト設計をまとめた本。
プロンプトを思いつきの一発勝負にせず、目的・前提・制約・出力形式・評価軸を分解して組み立てる。そのうえで、LLMの限界（もっともらしい誤り、前提の読み違い、指示の抜け落ち）を踏まえ、品質管理まで含めて実務に落とし込む、という方向性が一貫している。
「プロンプトの書き方」だけで終わらず、チームで使うときの合意形成（期待値合わせ）や、運用で事故を起こさないためのガードレールの発想まで扱うのが特徴だと思う。
読みどころ
- 「期待値合わせ」から始まる：LLMは万能でも検索エンジンでもない。最初に「できる／できない」「前提にしてよい情報」「出力の合否基準」を揃えることで、作業が“人間のチェック待ち”で止まりにくくなる。
- 構造化の徹底：要約・抽出・分類・JSON出力など、タスクが変わっても共通する「骨格」を示している。指示に加えて、背景、入力データの扱い、禁止事項、出力フォーマットをセットにすると、結果が安定しやすい。
- リファイン（反復）を手順化：一度で完璧を狙うより、出力を評価→不足を追記→再生成、という反復を“最初から設計”する考え方が実務的。ここがあると、プロンプト改善が属人芸になりにくい。
- 安全性・品質管理の視点：出力をそのまま採用しない、検証手順を組み込む、社内データの取り扱いを明示する、といった「運用の型」が強い。LLM導入の現場で起きがちな事故を先回りできる。
この本の「型」（最小セット）
本書の考え方を自分なりに最小化すると、プロンプトは次の箱に分けるのが強い。
- 目的：何を達成したいか（例：要約、比較、抽出）
- 前提：対象・背景・用語の定義
- 制約：やってほしくないこと（推測、断定、個人情報の扱い等）
- 出力形式：見出し、箇条書き、JSONなど
- 評価軸：良い／悪いの判断条件（網羅性、正確性、根拠の明示など）
この箱が揃うと、LLMの出力を「良し悪し」で揉めるのではなく、「どの箱が足りないか」で修正できるようになる。
類書との比較
ツール別の実装例を大量に集めた本が「すぐ試せる」方向だとすると、本書は「どう設計すれば失敗しにくいか」に重心がある。テンプレートとチェックリストが中心なので、部署・職種が違っても共通言語として使いやすい。
逆に、特定ツールの細かな設定やAPI実装を深掘りしたい場合は、別の技術書と組み合わせるのがよいと思う。
こんな人におすすめ
- 企業でLLMのPoCを動かす責任者。構造化されたプロンプト設計を提示することで、部署間の共通言語を作れる。
- プロンプトの結果が安定しない開発者。期待値調整とリファインメントの章が、再現性の高いやり直しを可能にする。
- プロンプトを社内に浸透させたい教育担当者。チェックリスト付きのワークが、研修でのアウトプット練習にぴったり。
使い方（最初の1週間でやること）
読むだけで終わらせないなら、次の順で試すのが早い。
- 自分の業務で「毎回同じ形のアウトプットがほしい」タスクを1つ決める（議事録要約、FAQ抽出、比較表作りなど）
- 本書の枠組みで、目的・前提・制約・出力形式・評価軸を1ページにまとめる
- 出力を見て、評価軸に照らして修正点を“箱”で特定し、反復して改善する
この手順を一度回すだけで、プロンプトが「運任せ」から「改善できる対象」になる。
注意点
LLMは、もっともらしく言い切ることがある。だから本書が強調するように、出力の検証を前提に組み込むのが重要だと思う。特に、社内文書や顧客情報に触れる場面では、入力データの扱い（共有範囲、保存、機密情報）を先に決めておきたい。
感想
この本を読んで一番よかったのは、プロンプトを「文章」ではなく「仕様」に寄せて考えられるようになったこと。
うまくいかなかったときに、以前は「言い回しが悪かった」で終わりがちだった。でも本書の枠組みで見ると、原因はだいたい特定できる。前提が曖昧、制約が抜けた、出力形式が指定されていない、評価軸が定義されていない——といった具合に、改善点が“箱”として見える。
また、LLMの導入は「精度」だけでは決まらない。現場で回るか、事故が起きないか、説明責任を果たせるかが重要になる。本書はそこを最初から扱っていて、プロンプトを作る人だけでなく、運用する人・教える人にも効く設計になっている。
LLMを仕事で使うなら、まずこの本で「型」を持ってから、各種ツールのノウハウに進むのが近道だと思う。
