オライリーのLLMのプロンプトエンジニアリングは、LLMプロダクト開発者の教科書
表題の通りです。この本は、LLMプロダクト開発者にとって必読の教科書です。
簡単にいうと、LLMの仕組みを理解してLLMの気持ちになってどういうコンテキストを与えたらうまくいくのか？どうやれば安定したLLMプロダクトを開発できるのか？というLLMプロダクト開発の基本が書かれた本です。
内容はいささか古く（おそらく2024年中頃までに書かれている）、この本から即座に実践に入れる類いの本ではないので、まさに「教科書」です。この本を索引として、必要な知識を深掘りする必要性があります。
この本に書かれている知識のまま、知識更新を怠ると極めて危険です。いろいろな情報がアップデートされています。
この記事に間違いとか解釈違いとかあったら、是非ご連絡ください！
コーディングエージェント使いが読むべきか？
非エンジニアが読むべきか？
内容の解説
という構成です。
コーディングーエージェント使いが読むべきか？
最近コーディングエージェントを使う人が一気に増えました。そういったコーディングエージェントを使う人が読んで価値があるのか？あるかもしれないし、無いかもしれない、です。
コーディングエージェントの場合、基本的にはコーディングエージェント（Cline/Roo/Cursor/Windsurf/Codexなど）そのもののプロンプトエンジニアリングが最重要です。コンテキスト（プロンプト）の組み立てはコーディングエージェントというLLMプロダクトがやっているためです。
そのため、Cline/RooのようなOSSをforkするか、運頼みにしかならないです。コンテキストの組み立てをソフトウェアに握られている以上そこはどうしようもないです。
もちろん、ルールファイルと呼ばれるようなプロンプトブックや、対話で与える指示も、プロンプトの一部として反映されるため、プロンプトエンジニアリングの基本は知っておくべきではあります。
ただ「LLMのプロンプトエンジニアリング」の本は、プロンプトエンジニアリングの基本が詰め込まれているけど、応用に関しては自力で調べ上げる必要があります。教科書を読んで眠くならないタイプの人ならいいでしょう。関連する論文を一通り退屈せずに読める人なら、おすすめです。
非エンジニアが読むべきか？
例えばLLMプロダクトの、プロダクトオーナーとか関係者が読むべきか？内容は非エンジニアにはかなりハードだと思います。
一つありかもしれないのは、オライリーのEBOOKを購入して、epub/pdfをダウンロードしてNotebookLMに食わせる方法です。これで要約してもらったりPodcast作ってもらったり、質問を投げ続けるといいかもしれません。ただし、このやり方は著作権的には気をつけてください。
NotebookLMやRAGにおいて、食わせたテキストの著作権は適切に扱う必要があり、少なくとも「チーム内で共有」みたいなことは完全にアウトです。
「個人利用で自分の理解のためにのみ使う」のは、著作権法としては適法と僕は認識してるんですが、間違ってるかもしれません。
エンジニアに説明してもらうとか、教えてもらうというのがいいかもしれません。
内容の解説
まず先にざっくりと全体像を説明すると、この本は
LLMの仕組みを説明
どういうプロンプト（コンテキスト）ならLLMがどういう応答を返してくれるのか？
1と2を理解したうえで、LLMをうまく御すための方法論を解説
3を理解したうえで、どういった開発サイクルであればLLMプロダクトを作れるのか？
について説明してくれる本です！
第一部
第一部はLLMとはなんぞやを中心に本当の基礎の基礎について書いてあります。基礎といいつつ、知らない人には全然優しくないです。Attention is all you need. 位読んでて当然やろくらいの勢いで書いてます。
でも第一部の序盤は割と重要で、LLMが返す応答の癖を把握するためには、仕組みや歴史に対する理解が必要だからです。
僕は社内勉強会でTransformerやLLMの構造について宮脇先生に教わって、完全に理解したポプ子の状態ですが、それくらいの知識はあるとlogprobsってなんぞや？とか、様々な背景が理解しやすいです。
LLMが一つのトークンを生成する工程:
文章を全部トークンに変換し
トークンの配列が内部vector(embedding)になって
Transformerでいい感じにまぜこぜされて
最終的にはlogitsというvectorになって
temperatureやtop_p/top_kを元に「次のトークン」が選ばれる（文中に出てくるlogprobsはこのlogitsに関して知るための手段）
たとえばこういった構造を知っておくと、トークン単位でしか物事を考えられないんだから、文字数を数えるのは苦手だよね？とか、temperatureを高めるとどうなるのか？どうしてlogprobsが役立つのかとかが理解しやすくなります。
赤ずきん原則だのチェーホフの銃だのがありますが、結局のところ、LLMというのは与えられたcontextに対する文章予測タスクだけをひたすら極めたものなので、contextによって出力が決まります。
学習っていうのはどういう工程で、だからこそ、LLMの応答には「癖があるんだよ」という説明がされています。この癖を理解することが、LLMの気持ちを理解する重要な鍵となります。
さて、第一部では引き続き、LLMの仕組みを背景として理解したうえで、LLMの気持ちをひたすら理解していきます。
お膳立ての重要性がかかれています。特に gpt-3.5-turbo-instruct モデルのような text completion API経由では、お膳立てのテクニックが実感しやすい形になっています。
本書ではそれ以外にChat Completion API が説明されていて、これが主流なんですが、最近は Response API がメインラインになろうとしている点には注意が必要です。
第4章や第6章に出てくる「ミニスニペット」の考え方は面白いです。筆者もミニスニペットを動的に組み立てるためのプロンプトジェネレータを作っていたりします。
第二部
この本でも書かれていますが few-shot はメリデメがあるため、割と取り扱いを注意しないといけないです。最近のLLMはfew-shotいらない説が増えています。
RAGの説明はとても簡素で、これだけでRAGを作ることは困難です。出てきた単語を元にいろいろ深掘りする必要性があります。langchainやLlamaIndexのソースを読んだり、RAG関連の論文を20個くらい読むのがおすすめです。
本書では、要約タスクを text completions API と gpt-3.5-turbo-instruct でやっていますが、2025年5月現時点では、コスパ・速度・精度的に、間違いなく Gemini-2.0-Flash Lite か Gemini-2.0-Flash か Gemini-2.5-flash あたりが最善手です。この三つのうちどれかを検討した方がいいです。
「インセプション」のテクニックは、この本では text completions APIを前提に書いていますが、もちろんChat Completions/Response APIでも使えるテクニックです。
たとえば、Anthropic Claude APIでは、構造化出力がサポートされてないため、JSON出力を強制するためには `assistant` の発言に `{` を入れた状態でAPIに投げると、序盤をJSONに固定ができるようになります。
本書では軽くしか触れられていませんが、AnthropicのArtifactsのプロンプトからは学ぶことがめちゃくちゃ多いです。プロンプトエンジニアたちが reasoning/thinking について本格的に世界中で議論を巻き起こしたのはこのタイミングからです。
CoTを使ったreasoning自体はそれより以前からある重要テクニックです。特に構造化出力との相性はとてもよいです。ところが、構造化出力は、本書の表現でいうなら「構造化出力税」を支払ってると考えられます。つまりLLMの持つ能力が構造化出力によって落ちるという説がありますが、XMLを使ったreasoning/thinking は、文章全体を構造化するわけじゃないので、精度が落ちない、と考えられています（要出典）
もちろんここら辺の精度については、様々な状況で変わりうるため、数ヶ月後にどうなってるかはわかりません。学習の仕方次第でなんとでもできてしまうため「XMLでもJSONでもYAMLでも精度が一切落ちないモデル」が出ても何ら不思議ですらありません。
第七章のlogprobsは、それを悪用することで、内部構造の推測や特定レイヤーの取り出しなどが可能になるという、商業的には脆弱性と言われてもおかしくないレベルの問題（探せば20種類以上の論文）があるため、OpenAIとしては廃止したいお気持ちを有しているようです。
たとえばResponseAPIにはlogprobsは存在しません。元々学術的なAPI利用が多かった頃の名残です。Anthropic Claude APIや、Google Geminiの最新モデルも、logprobsをサポートしていません。
logprobsを確実に使いたい場合はローカルLLMを使いましょう。ローカルLLMなら `logits` をいくらでも参照可能です。
第8章はtool (いわゆるfunction calling) について取り扱っています。現状ではOpenAI/Anthropic/Google Gemini どれもtoolが使えるうえ特にAIエージェントではtoolを触らない訳にもいかないため、理解しておいて損はありません。なお、Anthropicは前述の通り構造化出力を持っていませんがtool_use(Anthropicでのtoolの名称)を使えば、構造化出力を取り出すことができます。
ほかにも第8章ではtoolに必要な説明として、CoTやReAct(by Google)について触れられています。これらの考え方やテクニックそのものは今でも本当に重要な基礎中の基礎なのでしっかり理解しておいた方がいいです。できればNotebookLMを使ってでもいいのでオリジナルの論文や、関連の論文を一通り読んだ方がいいです。
第9章は、AIエージェントを作りたい人は必読です。まぁ、ひたすら泥臭くやるしかないです。やりましょう。
第10章は、LLMプロダクトを作る場合に絶対に避けて通れない「評価」の話です。評価は本当に難しい問題です。
LLMで「評価」をする場合、SOMAアセスメントはマジで重要です。LLMにスコアをつけさせると雰囲気でスコアリングしてしまい無意味になりますが、たとえば5段階の明確な指標があれば精度が変わります。
まとめ
LLMプロダクト開発者必読です。
コメント