## はじめに
「プロンプトエンジニアリング」と聞くと、どうしても「魔法の呪文集」のような印象を受けてしまいます。「ステップバイステップで考えてください」と書けば精度が上がる、といったTips集です。
本書はそういう本ではありませんでした。むしろ、LLMを組み込んだアプリケーションをどう設計するかという、アーキテクチャの本として読むべき一冊です。著者の2人はGitHub Copilotの初期開発者であり、本番環境で数百万人規模のユーザーを相手にLLMを動かしてきた経験がそのまま書かれています。
設計やアーキテクチャに関心のあるエンジニアにとって、得るものが多い本だと感じましたので、内容を整理してご紹介します。
書誌情報
| 項目 | 内容 |
|---|---|
| 書名 | LLMのプロンプトエンジニアリング ―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発 |
| 原書 | Prompt Engineering for LLMs |
| 著者 | John Berryman、Albert Ziegler |
| 訳者 | 服部 佑樹、佐藤 直生 |
| 出版社 | オライリー・ジャパン |
| 発行日 | 2025年5月14日 |
| ISBN | 978-4-8144-0113-0 |
著者のJohn Berryman氏は検索エンジニア出身で、『Relevant Search』の共著者でもあります。Albert Ziegler氏はGitHub Copilotの創設エンジニアとして、そのプロンプトエンジニアリングシステムを設計した人物です。「検索」と「LLM」という2つの専門性が交差しているのが、本書の内容にそのまま表れています。
全体を貫くたった1つの原則
本書には、最初から最後まで繰り返される主張があります。
LLMは本質的に、トレーニング中に提供されるテキストを模倣するテキスト補完エンジンにすぎない。
チャットモデルも、ツール呼び出しも、この事実の上に載った薄い糖衣にすぎない、というのが本書の一貫した立場です。この視点を持つと、LLMの挙動に対する見え方がかなり変わります。
たとえばチャットAPIは、内部では<|im_start|>system <|im_start|>user <|im_start|>assistant といった特殊トークンで区切られたトランスクリプトを補完しているだけです。ツール呼び出しも、TypeScript風の型定義がシステムメッセージに埋め込まれ、assistant to=functions.set_room_temp のような構文を補完しているだけです。
つまり、APIの抽象を1枚剥がすと、全部ドキュメント補完である。この理解が、後半のエージェント設計やワークフロー設計の議論にそのままつながっていきます。
本書の構成
3部11章の構成です。
- I部 基礎（1〜4章）: LLMの内部動作、チャットモデルへの進化、アプリケーション設計の全体像
- II部 中心的なテクニック（5〜7章）: プロンプトに何を入れるか、どう組み立てるか、出力をどう制御するか
- III部 プロンプト作成のエキスパート（8〜11章）: エージェント、ワークフロー、評価、そして展望
以下、印象に残った部分を章ごとに拾っていきます。
I部 基礎
2章 LLMを理解する
LLMの内部構造の解説ですが、行列演算や活性化関数の話は意図的に省かれています。「プロンプトを書くために必要な理解」だけに絞られている点が好印象でした。
特に納得感があったのが、トランスフォーマーを「ミニブレイン」の集合として説明する比喩です。トークンごとに1つのミニブレインが割り当てられ、各層で左側のミニブレインに質問を投げ、回答を受け取る。情報は左から右へ、下から上へしか流れない。
この一方向性から、設計上重要な帰結が導かれます。
- レイヤ
iにおける推論の連鎖は、最大でもiステップの深さまでしか到達できない - 後の層で得た洞察を前の層に戻して再処理することはできない
- 唯一の例外が「トークンを出力して次のミニブレインの入力にする」経路であり、これが思考の連鎖（CoT）の理論的基盤になっている
本書はこれを、次の一文にまとめています。
関連する知識をすべて頭に入れた人間の専門家が、一度も立ち戻りや修正、メモ取りなしで、このプロンプトに対する回答を書き上げられるだろうか？
LLMに何を期待してよいかを判断する、実用的なリトマス試験紙だと思います。
また、ハルシネーションについての説明も明快でした。モデルの視点ではハルシネーションと正しい回答は区別がつかないため、「勝手に作り話をしないで」という指示はほとんど効果がありません。有効なのは、検証可能な形で出力させることです。「ある英国の王がいとこと結婚した」より「ジョージ4世がブラウンシュヴァイクのキャロラインと結婚した」の方が検証しやすい、という例が挙げられています。
さらに、モデルには「真実バイアス」があり、プロンプトに書かれた前提を疑わずに受け入れる傾向があります。これは反事実シナリオの評価に活用できる一方で、プログラムでプロンプトを組み立てる場合には危険でもあります。誤情報や非論理的な要素が混入しても、モデルは訂正してくれません。
3章 チャット形式への移行
RLHF（人間のフィードバックによる強化学習）の解説です。ベースモデル → SFTモデル → 報酬モデル → RLHFモデルという4つのモデルと3段階のファインチューニングを、GPT-3の実データ（SFT用約13,000件、報酬モデル用約33,000件、RLHF用約31,000件）とともに追っていきます。
面白かったのは、なぜSFTだけでは不十分なのかという説明です。
SFTのトレーニングデータは人間が書きます。しかし人間のアノテーターは、モデルが内部的に何を知っていて何を知らないかを把握できません。その結果、次の2つの失敗が起きます。
- 人間がモデル以上の知識を前提に回答例を作る → 「知らないことをでっち上げてもよい」と学習する
- 人間がモデルの知識を過小評価してぼかす → 「確信があっても常にぼかす」と学習する
RLHFでは回答を生成するのがSFTモデル自身なので、評価者は「モデルの内部知識と矛盾しない回答」に高評価を与えられます。だから「正直さ」が学習できる。この筋道は、言われてみればなるほどという内容でした。
一方で「アラインメント税」（有用・正直・無害に最適化する過程で知能が犠牲になる現象）にも触れられており、バランスの取れた記述になっています。
4章 LLMアプリケーションの設計
ここから設計の話が本格化します。本書はLLMアプリケーションを、ユーザーの問題ドメインとモデルのテキストドメインを橋渡しする変換レイヤと定義します。
ユーザーの問題は、以下の4つの次元で複雑さが変化します。
- 問題が提示される媒体（テキストが最も自然）
- 抽象度レベル
- 必要なコンテキスト情報
- 状態管理の必要性
校正アプリケーションは全次元で低複雑度、旅行計画アプリケーションは全次元で高複雑度、といった整理がされています。この4軸は、自分が作ろうとしているものの難易度を見積もる際に使えそうです。
そしてここで登場するのが、本書のもう1つのキーワード「赤ずきんの原則」です。
モデルがトレーニングされた「道」から外れないようにすること
プロンプトがトレーニングデータ中のドキュメントに近いほど、補完結果は予測可能で安定します。独自のフォーマットを発明するより、Markdownやレポート形式など、インターネット上にありふれた形式に寄せる方がうまくいく。地味ですが、実務上かなり効く原則だと思います。
II部 中心的なテクニック
5章 プロンプトのコンテンツ
プロンプトに入れる情報を「静的」と「動的」に分けて整理します。
- 静的なコンテンツ: 問題を定義・構造化・明確化するボイラープレート、Few-shotの例。ユーザーが変わっても変化しない
- 動的なコンテンツ: 特定のユーザーや状況に関するコンテキスト。実行時に収集する
Few-shotプロンプティングについては、有効性だけでなく3つの欠点が丁寧に列挙されています。
- コンテキストが増えるほど扱いづらくなる: 例ごとに大量のコンテキストが必要な場合、ウィンドウを圧迫し、かつ「どの情報が誰のものか」でモデルが混乱する
- 例示された情報に偏る（アンカリング）: レビュー評価の例で1〜5を均等に並べると、モデルは「均等分布」と解釈してしまう。実際には星5が圧倒的多数なのに
- 誤ったパターンを示唆する: 例を昇順に並べる、正常系を先・異常系を後に並べる、といった意図しない順序をモデルが拾ってしまう
3つ目は特に盲点でした。「良いものを先に、悪いものを後に」という自然な並べ方が、モデルを不当に悲観的にするという指摘は、実際に手を動かしていないと気づけない類の知見です。
動的なコンテキストの収集については、待ち時間の観点からアプリケーションを3段階に分類しています。
| 緊急度 | 例 | 制約 |
|---|---|---|
| 低 | メール要約アシスタント（後放置型） | 収集にどれだけ時間をかけてもよい |
| 中 | オンデマンド型のアシスタント | 複数回のLLM呼び出しは現実的でない |
| 高 | タイピング中の補完アシスタント | 数ミリ秒の遅延も許容されない。事前準備が必須 |
RAGの節では、ニューラル検索と語彙検索が公平に比較されています。世間ではベクトル検索一択のような空気がありますが、本書は語彙検索の利点（実績、デバッグのしやすさ、フィールド単位の重み調整）を明確に挙げています。GitHub Copilotが開いているタブからコード断片を探す際にジャッカード類似度を使っている、という具体例も興味深いです。
もう1つ、「チェーホフの銃の誤謬」という概念が紹介されています。無関係なスニペットを取得してしまうと、モデルは「ここに置かれている以上、重要な情報のはずだ」と深読みしてしまう。人間が学習データを通じてこの原則に従っているため、モデルもそれを模倣してしまうわけです。
6章 プロンプトの組み立て
個人的に最も実務に効いた章です。
無関心の谷（Valley of Meh） という概念が提示されます。これは2つの既知の現象の組み合わせです。
- コンテキスト内学習: プロンプト末尾に近い情報ほど影響が大きい
- Lost in the Middle: 冒頭と末尾は思い出しやすいが、中間は活用が難しい
結果として、冒頭を過ぎたあたりから中盤にかけて、コンテキストがうまく使われないゾーンが生まれます。対策は「重要な要素を谷の外に置く」「プロンプトを簡潔に保つ」しかありません。
プロンプトの理想的な構造として、以下が提示されています。
- 導入部: 作成するドキュメントの種類を明確化し、モデルの焦点を早期に絞る
- コンテキスト要素: 各種スニペット
- リフォーカス: 本題の質問を再提示する（サンドイッチ手法）
- 移行: 問題提示から問題解決へ視点を切り替える。回答の書き出しを与える「インセプション」も有効
そして、ドキュメント形式の選択肢が3つ挙げられています。
- アドバイスの会話: 最も汎用的。チャットモデルと相性がよく、複数ラウンドのやり取りに向く
-
分析レポート: Markdownで書くことを一貫して推奨。目次を使ってスクラッチパッド（
# アイデア# 分析を# 結論の前に置く）や停止シーケンス（# 参考文献）を仕込める - 構造化ドキュメント: XML / YAML / JSON。出力の解析が容易
分析レポート形式で目次を活用するテクニックは、すぐに真似できて効果が大きいと感じました。
技術的に細かいですが、トークン数は加算的ではないという指摘も実装者には重要です。
"be" + "am" → "beam" : 1 + 1 → 1 トークン
"cat" + "tail" → "cattail" : 1 + 1 → 3 トークン
スニペット単位でトークン長をキャッシュする設計にする場合、要素間を空白で区切る、スニペットは空白で始めて空白では終わらせない、といった配慮が必要になります。
章の締めくくりでは、プロンプト組み立てを最適化問題として定式化しています。要素には「ポジション」「重要度」「依存関係（必須条件・非両立条件）」があり、トークン予算内で全体価値を最大化する。これは0-1ナップサック問題に近く、加算的貪欲法と減算的貪欲法という2つの実装方針が図示されています。
さらに「伸縮自在なスニペット」という発想も紹介されます。同じ情報を長尺版から短尺版まで複数バージョン用意しておき、「入れるか入れないか」ではなく「どのバージョンなら入るか」で判断する。プロンプト構築をコンポーネント設計として扱う視点は、アーキテクチャに関心があるエンジニアには特に響くはずです。
7章 モデルの制御
出力側の制御がテーマです。
「無意味な要素（fluff）」への対処は実務的です。RLHFモデルは冗長で丁寧なレスポンスを生成しがちですが、プログラムから使う場合これは邪魔です。本書の推奨は「本題の回答を先に、追加情報を後に」という形式に組み替えること。認識可能な開始と終了を設計し、停止シーケンス（\n# など）やストリーミング＋キャンセルでトークン生成を打ち切ります。
そして本章の目玉が logprob の活用です。
- 品質評価: 補完の初期トークンの確率を平均すると、全体品質の予測指標になる。閾値を設けて「自信がないときだけ再試行する」「自信があるときだけユーザーに割り込む」といった制御ができる
-
分類: 選択肢はそれぞれ一意のトークンで始まるようにする。
North AmericaとNortheast Asiaは両方Northから始まるため確率が合算され、実際には最有力でない選択肢が選ばれてしまう - キャリブレーション: logprobに定数を加算して閾値を調整する。多くのAPIが「ロジットバイアス」として提供している
-
プロンプトの驚き検出:
echoを有効にするとプロンプト側のlogprobも取得できる。低いlogprobはタイプミスや意外な箇所を示す
logprobを使った分類の話は、他ではあまり読んだことがない内容でした。
モデル選択の節では、知能・スピード・コスト・使いやすさ・機能・特別な要件という6軸が挙げられ、「モデルの選択をコードに織り込みすぎない」「使えると思うより少し大きいモデルでプロトタイプを作る（リリース時には安くなっている）」という実践的な助言が続きます。
ファインチューニングの分類も簡潔にまとまっています。
| 種類 | 学習できること | 必要なドキュメント数 | 所要時間 |
|---|---|---|---|
| 完全なファインチューニング / 継続的な事前トレーニング | まったく新しい領域 | 数万 | 数週間〜数ヶ月 |
| LoRAなどのPEFT | 既存ドメイン内の期待値、解釈、形式 | 数百〜数千 | 数日 |
| ソフトプロンプティング | プロンプトに含まれる情報 | 数百 | 数時間 |
「LoRAは新しいテクニックを教えるのではなく、すでにできるテクニックのどれをどう使うかを教える」という説明は、直感的で分かりやすいと思います。
III部 プロンプト作成のエキスパート
8章 会話型エージェント
ツール呼び出しの内部表現を解剖する節が白眉です。OpenAIの内部プロンプトを推定し、ツール定義がTypeScript風の型定義としてシステムメッセージに埋め込まれていることを示します。そしてツール呼び出しの生成過程を、6つの連続した分類問題として分解します。
- 誰が話すべきか（APIが強制）
- ツールを呼び出すべきか
- どのツールを呼び出すべきか
- どの引数を指定すべきか
- 引数がどのような値を持つか
- これで終了なのか
同一のニューラルネットワークが、10〜20トークンの範囲で5つの専門的な推論を階層的に実行している、という見方です。
ツール設計のガイドラインも実務的です。
- ツールの数は制限する。多いほど混乱する
- Web APIをそのままコピーしない。単純なツールほどよい
- 名前は自己文書化されているべき。
retrieveemailのような小文字連結は避ける - 引数のハルシネーションに注意（
my-orgmy-repoのようなプレースホルダーを勝手に埋める） - OpenAIはJSON、AnthropicはXMLタグで引数をエンコードするため、長い引数の扱いやすさが異なる
危険なツールの扱いについては、はっきりと釘を刺しています。
ツールの説明で「実行前にユーザーに必ず確認してください」と書いておけば大丈夫だろう、と単純に考えてしまいがちです。しかしそれは間違いです。
モデルは確率的に動作するため、指示に反する行動を低確率で必ず取ります。したがって、アプリケーション層で危険なリクエストを検知し、明示的な承認を得るのが唯一の正しい設計です。プロンプトをセキュリティ境界にしてはいけない、という当たり前ですが重要な指摘です。
推論のテクニックとしては、CoT、ReAct、Plan-and-Solve、Reflexion、Branch-Solve-Mergeが順に紹介されます。ReActについては、ファインチューニング前は標準プロンプティングより劣っていたという事実まで含めて書かれており、誠実な記述だと感じました。3,000例のファインチューニング後に一気に首位に立ち、8Bモデルが62Bモデルを、62Bモデルが540Bモデルを上回るという結果になります。
9章 LLMワークフロー
本書で最も設計論的な章です。冒頭で提示される軸が明快です。
LLMは従来の機械学習より強力で汎用的だが、AGIには到達していない。むしろ、一般性と強みの間にトレードオフがある。
ChatGPTのような純粋なチャットは極めて一般的だが弱い。ドメインを絞りツールを与えたエージェントは、一般性を失う代わりに強くなる。さらに構造を固めたワークフローは、もっと狭く、もっと強い。
具体例として、「Shopify店舗を収集し、各店舗向けのプラグインを考案し、宣伝メールを送る」というタスクが取り上げられます。会話型エージェントでこれを試みると、検索が素朴になり、メールが定型文になり、作業単位の管理ができず破綻します。
そこでワークフローの出番です。構築手順は5ステップ。
- 目標を定義する
- タスクを指定する（各タスクの入出力スキーマを明確に）
- タスクを実装する
- ワークフローを実装する
- ワークフローを最適化する
トポロジーは、パイプライン → DAG → 巡回グラフの順に柔軟性と複雑性が増します。本書はDAGを強く推しています。巡回グラフは、失敗情報の再結合、全タスクでの失敗情報の考慮、無限ループ防止と、複雑さが一気に跳ね上がるためです。
そして繰り返し強調されるのが、「LLMを使わずに済むなら使うな」 という原則です。
- HTMLの取得はウェブクローラーでよい
- DBへの格納は機械的な処理でよい
- 分類はBERTベースで済むならその方が速く安く確実
- タスクごとに異なるモデルを使ってよい（簡単なタスクには軽量モデル）
- 人間の介在を組み込んでよい
LLMは「従来のソフトウェアよりも高価で、遅く、非決定論的で、信頼性が低い」と明言されています。LLM本の中でここまではっきり書いているのは好感が持てます。
後半の「高度なLLMワークフロー」では、ワークフロー自体をLLMエージェントが駆動する構成、ステートフルなタスクエージェント、役割と委任（AutoGen、CrewAI）が紹介されますが、「安定性が低く理解が難しくなる」という警告付きです。
10章 LLMアプリケーションの評価
GitHub Copilotで最初に書いたコードが評価だった、というエピソードから始まります。プロキシでもプロンプトでもUIでもなく、評価。この一点だけでも読む価値があると思いました。
オフライン評価は、以下の技術ツリーで整理されます。
サンプルの入手方法
- 既存のレコードをマイニングする
- アプリケーションの利用履歴から蓄積する
- LLMで合成する（トピック × 側面の組み合わせ爆発を活用する）
Copilotの場合、「ユーザーが次に何を入力したいか」の直接的なコーパスは存在しないため、OSSリポジトリから関数本体を削除して補完させる、という代理タスクを設計しています。理想的ではないが、ほぼ無限のサンプル源になる。この「ラボと現実の間の足がかり」という表現が印象に残りました。
解決策の評価方法
- 判断基準との一致（完全一致 / 部分一致）
- 機能テスト（Copilotなら単体テストが通るか）
- LLMアセスメント
LLMアセスメントについては、注意点が明確です。まず、絶対評価としては機能せず、相対的な品質判断としてのみ有効。そして、モデルに「自分自身の成果物を採点している」と思わせてはいけない。第三者を採点していると認識させた方が精度が高くなります。
その上で SOMAアセスメント が提案されます。
- Specific questions（明確な質問）: 「これは正しいか」ではなく、具体的な観点を問う
- Ordinal scaled answers（順序尺度の回答）: 1〜5の尺度にし、各段階の意味を明記する
- MultiAspect coverage（複数の側面のカバー）: 意図と実行を分ける、ゴルディロックスの質問（十分か / やりすぎでないか）は分解する
そして、SOMAの妥当性は人間の評価と突き合わせて検証する。ケンドールのタウで測った人間評価者間の不一致が、モデルを1人加えても安定したままかを確認する、という手続きまで書かれています。
オンライン評価では、メトリクスが5種類に分類されます。
- 直接フィードバック（Good/Badボタン）
- 機能の正確性（コンパイルが通ったか、メールが送信トレイに入ったか）
- ユーザーの受け入れ（提案を採用したか）
- 達成された影響（実際に利益があったか）
- 付随的メトリクス（待ち時間、会話時間など）
Copilotの経験では、受け入れ率が、より高度な影響指標よりもユーザーの報告する生産性向上と強く相関したとのことです。
11章 未来を見据えて
マルチモダリティ、UI/UX、知能の向上という3方向の展望です。
UXの節では、状態を持つ対話オブジェクトという概念が提示されます。現在のチャットアプリケーションでは、関数を修正しようとしても過去の出力を更新できず、会話の中にN個のバージョンが積み上がってしまう。これに対する一歩がAnthropicのArtifactsですが、本書は「変更のたびに全体を書き直している」「複数同時操作が難しい」「ユーザー側から編集できない」といった課題も具体的に指摘しています。
知能の向上については、ベンチマークの飽和（本当に賢くなったのか、ベンチマークがトレーニングデータに混入して「ずる」をしているのか）、知識蒸留、量子化などが触れられています。
そして最後に、こう釘を刺します。
モデルはより賢くなっていくとはいえ、決して超能力者にはなりません。プロンプトに「あなた自身が」問題を解決するのに必要な情報が含まれていないのであれば、モデルにとっても不十分である可能性が高いのです。
設計・アーキテクチャ視点での読みどころ
設計に関心のあるエンジニアとして、特に価値を感じた点を挙げます。
1. プロンプトを「文字列」ではなく「コンポーネントのツリー」として扱う
6章のプロンプト要素モデル（ポジション、重要度、依存関係）は、プロンプト構築を最適化問題として定式化します。テンプレート文字列を書き散らすのではなく、要素を独立したオブジェクトとして管理し、組み立てエンジンを設ける。この設計は、アプリケーションが成長したときに効いてきます。
2. 責務分離の原則がそのまま適用できる
9章のワークフロー論は、要するに「大きな責務を小さな責務に分割し、明確なインターフェースで接続する」という古典的な設計原則の適用です。タスク単位で評価・最適化・デバッグできるのは、モジュール化の恩恵そのものです。
3. 信頼境界の置き方
「プロンプトはセキュリティ境界ではない」という主張が、8章（危険なツール）と3章（プロンプトインジェクション、ユーザーコンテンツをシステムメッセージに入れてはいけない）の両方で繰り返されます。確率的コンポーネントを含むシステムでの信頼境界の引き方として、一般化できる知見だと思います。
4. 評価を最初に作る
10章の主張は、テスト駆動開発の精神とそのまま重なります。非決定論的なコンポーネントを扱う以上、変更が改善なのかリグレッションなのかを判定する仕組みがなければ、開発は勘に頼ることになります。
気になった点
情報の鮮度
原書は2024年執筆で、日本語版は2025年5月刊です。モデル名やAPI仕様は当然古くなっています。ただし本書の主張の大半は、モデルの世代に依存しない構造的な話なので、実害は小さいと感じました。むしろ「今日高すぎるものは明日安くなる」という前提が本書自身に織り込まれています。
コード例は最小限
Pythonのコード例はありますが、動くアプリケーションを一から作るタイプの本ではありません。手を動かしながら学びたい場合は、各章末の「さあ、やってみよう」の課題を自分で実装していく必要があります。
OpenAI寄り
APIの具体例はほぼOpenAIです。Anthropicなど他社への言及もありますが、内部プロンプトの解剖などはOpenAIが中心です。
どんな人におすすめか
おすすめできる方
- LLMを組み込んだアプリケーションを設計・実装している、またはこれから始める方
- 「なぜこのプロンプトだとうまくいくのか」を構造的に理解したい方
- エージェントやRAGを既に作っていて、次に評価やワークフロー設計に進みたい方
- 設計・アーキテクチャの観点からLLMを捉え直したい方
あまり向かない方
- ChatGPTを効率的に使うための即効性のあるTipsを求めている方
- LLMの数理的な内部構造を厳密に学びたい方（本書は意図的に省いています）
- 特定のフレームワーク（LangChainなど）の使い方を学びたい方（本書はフレームワーク非依存の立場です）
まとめ
本書を読み終えて残ったのは、次の2つの教訓です。これは著者自身が最終章でまとめているものでもあります。
- LLMは、学習時に見たテキストを模倣するテキスト補完エンジンにすぎない
- LLMに共感し、その思考方法を理解する必要がある
2つ目の「共感」については、本書は具体的な特性として整理してくれています。
- LLMは気が散りやすい（役立つかもしれない情報でプロンプトを埋めない）
- LLMはプロンプトを解読できるはず（人間が理解できないプロンプトはモデルも理解できない）
- LLMは何かに導かれる必要がある（明示的な指示と例を与える）
- LLMは超能力者ではない（必要な情報はこちらが渡す）
- LLMには内的な独り言がない（声に出して考えさせる）
プロンプトエンジニアリングを「呪文の探索」ではなく「確率的コンポーネントを含むシステムの設計」として捉え直させてくれる一冊でした。LLMアプリケーションの設計に関わる方には、広くおすすめできると思います。