あらすじ
◆「LLMの挙動を左右するコンテキストをどう扱うか」AI時代のエンジニアの最重要スキル◆
大規模言語モデル（LLM）へ与える、プロンプトを含む多様な入力情報である「コンテキスト」。LLMの挙動を健全にコントロールするために、どんなコンテキストを構築するか――限られた入力領域において、何を与え、何を捨て、どのようにして良いコンディションを保つのか――この技術の総体が「コンテキストエンジニアリング」であり、LLM活用を目指すエンジニアが知るべき最重要トピックです。本書では、AIモデルの基礎の仕組みやAPIの挙動をコンテキストの観点から順にひも解き、RAG（Retrieval-Augmented Generation）やAIエージェントなど実践的な開発において発生し得るコンテキストエンジニアリングのテクニックを存分に紹介します。
■目次
第1章 LLMの仕組みから見るコンテキストの正体
・1.1 LLMの動作を知る意義
・1.2 LLMを構成するニューラルネットワークの基本
・1.3 LLMによるトークン生成のしくみ
・1.4 対話型LLMに施された工夫や注意点
・1.5 Reasoningモデルの進化へ
・1.6 まとめ
第2章 APIサービス利用におけるコンテキストの扱いと基礎機能
・2.1 LLMのAPIサービスの概要
・2.2 LLMベンダーが直接提供するAPIサービス
・2.3 クラウドベンダーが提供するAPIサービス
・2.4 APIやモデルの選定基準
・2.5 APIの基本的な使い方
・2.6 LLMによるツール利用
・2.7 出力スキーマの固定化
・2.8 Function CallingとStructured Output使用時のテクニック
・2.9 コンテキストキャッシュの仕組み
第3章 指示プロンプト開発の基礎
・3.1 前提となるリファレンス
・3.2 指示プロンプト開発時に把握しておくべき全体指針
・3.3 指示プロンプトの記述に活用される記法
・3.4 指示プロンプトの基本構造
・3.5 指示プロンプトの管理
・3.6 指示プロンプトの精度向上の技法
第4章 RAGにおけるコンテキスト整備
・4.1 RAGとは
・4.2 検索エンジン関連用語の整理
・4.3 RAGの全体のフロー
・4.4 RAGを使うかどうかの判断
・4.5 RAGで用いられる基盤技術
・4.6 検索を伴うRAGの精度向上のための工夫
・4.7 その他の話題
第5章 AIエージェント×ワークフローによる作業自動化
・5.1 AIエージェントはなぜ注目されたのか
・5.2 ワークフロー化によるコンテキストの分散
・5.3 市場が期待した「AIエージェント」の正体
・5.4 エージェントワークフローに関連するリファレンス
・5.5 具体例を見ながらエージェントワークフロー設計を学ぶ
・5.6 コンテキスト肥大化に伴うその他の課題と対策
■著者プロフィール
蒲生 弘郷（がもう ひろさと）：外資系IT企業所属のクラウドソリューションアーキテクト、エバンジェリスト。上智大学大学院 応用データサイエンス学位プログラム 非常勤講師。大手システムインテグレーターにてキャリアをスタート。社会インフラ関連領域のデータサイエンティストとしての活動、ブロックチェーンを活用した異業種間データ流通サービスの立ち上げなどを経て現職へ。ChatGPTの登場した2022年以来、Azure OpenAI Serviceなどを使ったLLMアプリケーションの構築支援・アドバイザリーおよび技術情報の発信に従事。「ChatGPT - Azure OpenAI大全」などの資料が「2023 Most Viewed Deck 25」に選出。共著に『Azure OpenAI ServiceではじめるChatGPT/LLMシステム構築入門』。
感情タグBEST3
Posted by ブクログ
私は仕事でエンジニアの方にRAGやAIエージェントの開発方法を教える講師業をしているのですが、この本は私が受講者に伝えようとしていることがたくさん書いてあって、首がもげそうになるくらいうなずきながら読みました。すごく良い本だと思うので、簡単に感想をまとめます。
■ この本のよいところ
現場で実際に苦労された方が書かれている
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
現場寄りの話がたくさん書かれていて、業務でRAGやAIエージェントに取り組まれている方には非常にオススメです。
私は前職でAIチャットボットやRAGサービスのカスタマーサクセスチームを率いていたのですが、オンボーディングは本当に大変でした。AIはまだまだ万能ではなく、導入するためにも運用するためにも顧客の協力が重要です。評価データセットの準備、データ側の整備、運用開始後の改善サイクルを主体的に回してもらうための計画作りなど、システムを導入するよりも大変な作業がたくさんあります。この本には、そのような現場を知っている著者の方の経験がふんだんに盛り込まれています。
道具に振り回されないRAGの解説
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
RAGの手法の解説に留まらず、実践するための解説になっています。RAGで苦労されている方は必読です。
私は前々職で全文検索エンジンや文書管理パッケージのエンジニアをやっていて、企業内の情報活用やナレッジマネジメントで戦ってきた経験があるのですが、情報の利活用というのは非常に難しいテーマです。RAGの手法をいくつか試して良いものを選べば終わり、という世界では全くありません。RAGの導入のコツは、いきなり万能なものを作ろうとしないことです。テーマを絞り、対象文書を絞り、データの取り込み方法を検討し、テストデータセットを用意し、改善を繰り返し育てていく必要があります。この本を読めば、泥臭くがんばらないといけない世界の理解と、そんな中での光明が見出せるのではないかと思います。
AIエージェントの現在地や現場の話
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
繰り返しになりますが、AIエージェントについても手法の解説に留まらず、現場で実践するための解説になっています。これが非常に有用です。
少し前までは、プロンプトベースのエージェントでは複雑な業務はこなせなかったのですが、今なら本にあるように、まずプロンプトベースのエージェントで試すというアプローチが有効だと思います。それにしても、AIエージェントをワークフロー化するお話のところの次の一文にはしびれました。
> 本来的には使いたくない苦渋の選択であることを忘れてはいけません。（5章5.2.4節より）
これは非常に重要なことだと思います。今は過渡期なので（AIの世界は常に過渡期ですが）、技術の変遷における現在位置を把握しておかないと、作ったシステムがあっという間に陳腐化してしまいます。最新の手法を追うのも重要ですが、その手法が生まれた背景や技術の根っこをきちんと理解して、変化に備えていくことがとても大切です。
■ この本で気になったところ
すごく些細なところですが、4章4.5.1節で解説されている「フルテキスト検索の弱点」が少し過剰になっていたのが気になりました。たとえばOSSで普及しているApache Lucene／Elasticsearch／Apache Solrは、同義語（シノニム）による語彙ミスマッチの対策や正規化による表記ゆれの対策などを搭載しているので、一部の弱点はある程度緩和できます。
■ おわりに
業務でRAGやAIエージェントの開発に取り組まれている方へ、非常にオススメの1冊です！
Posted by ブクログ
AIエージェントが発展していく過程で重要になるコンテキストエンジニアリング。プロンプトだけにとどまらない、様々な要件や最適化を行うTipsが網羅されている良書。自動化のワークフローに対する考え方も参考になった。
Posted by ブクログ
普段、社内向け業務アプリの設計・開発をしていますが、本書は、整理して言語化するのが難しいテーマを丁寧に整理しており、実務に直結する示唆が非常に多いと感じました。設計思想と実装に結びつく具体策の両立がうまく取れている点が特に印象的です。
著者はMicrosoftでのLLM導入支援に関わってきた方とのことで、現場での実践知が非常に豊富。理屈だけでなく「現場でどのような問題が起きるか」「どう設計すべきか」の視点で説明が進むため、納得感を持って読み進められます。
特にコンテキスト設計の扱い方が印象的でした。情報を詰め込むのではなく、何を入れ、何を削り、どう並べるか──その設計思想を「コンテキストエンジニアリング」として整理し、Transformerの挙動と結びつけて説明している点が非常に良かったです。経験談に留まらず原理から納得させる構成になっています。
API周りの解説も実践的です。Responses APIやMCP、Structured Outputといったトピックについて、表面的な紹介ではなく「どう使うとハマるか」「どう設計すると安定するか」まで踏み込んでいるため、実際に触っている人ほど得られるものが大きいと思います。
プロンプトの構造化、コンテキストキャッシュ、JSON出力の精度改善といった実装上の工夫も多く、読んだらすぐ試したくなる内容が続きます。単なるノウハウ集ではなく、API経由での組み込み・精度・コスト・保守性を考える人にとっても非常に有意義な一冊だと思いました。
第4章では、RAGの設計と運用について、これまでの章で示された設計思想を実務に落とし込む具体的な指針が示されます。検索のタイミング設計やデータ整備の重要性、ログを通じた改善サイクルなど、「どこから手を付けるべきか」を整理してくれる内容で、単なる技術解説に留まらず、運用を前提とした思考の枠組みが補強された印象です。RAGを導入する際のチェックポイントが明確になり、設計レビューの観点としても非常に有用だと感じました。
第5章では、AIエージェントとワークフローによる作業自動化がテーマになります。自律性への期待と現実的な制約の整理、プロンプトベースでどこまで行くか、精度が出ない場合にどのようにワークフローへ切り出すか、といった設計上の判断基準が示されます。コンテキスト肥大化への対策やUI設計、状態管理の重要性など、実装・運用面の注意点も具体的に触れられています。一方で、内容自体は著者自身も試行錯誤中の印象を受けました。
全体として、「プロンプトのノウハウ集」というよりは、LLMを組み込んだシステムをどう設計し、どう運用し、どこで分割し、どこを人や従来技術に任せるかまでを考える実務者向けの一冊だと思います。特に第4章までの内容は、設計指針として常日頃から手元に置いておきたいレベルでした。おススメです。
Posted by ブクログ
・気になるところ（第3章指示プロンプトの開発の基礎と第5章AIエージェント）だけ読んだ。
・仕事でも個人でもclaude codeをそこそこ使っているので、答え合わせのような感じで読めた。
・Resoningの性能が上がっているのは事あるごとに実感していたので、プロンプトエンジニアリングに懐疑的だったのが、今はコンテキストエンジニアリングになっていると言う言語化でスッキリした。
・ただ、あまりソフトウェア開発で使えそうな各論はなかった（既にやっている）し、LLM自体の振る舞いの復習ができたという印象
・AIエージェント構築してみたいと思った（と思ったけど、既にsaasとしてワークフロー定義出来るやつの存在を思い出したので自分でやる必要ないなと。）
Posted by ブクログ
【メモ】
llmの基本挙動制御：
指示プロンプトの設計・構造化、Chain of Thoughtや例示、出力の自己修正、出力形式制御
llmによるツール使用：
ツール選択のための定義情報の付与、適切なツールパラメータの抽出、取得情報の選別・整形・構造化
長文処理や圧縮：
オンライン・オフラインで肥大化してくる長文をどう処理して制御していくか
サーベイ論文：
ファインチューニング、LLMに関する深い知識
Transformer：
当初は翻訳のような系列変換を題材に作られたアーキテクチャ
Attention Is All You Need.論文
BERT：
テキスト分類などを活用
Vision Transformer：
画像系タスクに応用
Tokenize：テキストのトークン化
Embedding：トークンのベクトル化
Self-Attention：トークン同士の関係性の計算
Feed Forward：ニューラルネットワーク内部の知識とトークンの関連付け
API
revious_response_id：思考過程を含んだ会話を継続
web_search：Web検索ツール
image_url：画像
temperture：創造性（多様性）
max_output_tokens：出力トークン数学の制限
effort：思考の深さを制御
summary：思考の過程の要約が詳細に出力
RAG
LLMが外部のデータソースからコンテキストを取得し、その内容をもとに回答を生成する技術的な概念
外部から取得（Retrieval）した情報をLLMに与えて（Augmentation）そのコンテキストを基に回答を生成（Generation）する手法
Function Calling
リクエスト時にツール定義を添えることでLLMがツールを呼び出すためのパラメータを抽出し、そのパラメータで取得した結果を基に回答を生成するAPI
Pydantic
より簡単にスキーマ定義
text_format：出力フォーマットの指定。正規表現や数値の範囲指定などかなり高度な制約を設けることも可能。
コンテキストキャッシュ
一度APIに送信したコンテキストに基づくニューラルネットワークの計算結果を保持しておき、次回以降に同じ計算が発生した場合に再利用することでコストを削減したり、レイテンシを向上させる仕組み
入力コンテキスト
出力スキーマ定義→指示プロンプト→ツール定義→会話履歴の順で結合されてLLMに読まれる
最低限英語にしておく必要があるコンテキスト
制約・禁止事項（英語の方が明確に指示しやすい）
関数名や変数名
IT固定用語
JSON出力時のキー名
XMLタグ
条件分岐・繰り返し記述
否定形を避ける
×選ばないでください
⚪︎禁止されています
⚪︎以外を選んでください
指示を矛盾させない
複数項目の指示・出力はなるべく避ける
重要な情報は冒頭に書く
出力スキーマ
指示プロンプト
ツール定義
対話履歴
ユーザーからの入力
HowよりWhatを重視する
「遠慮せずに、全力を尽くしてください」（プロンプトガイド推奨）
役割（ロール・Role）
タスク以外にも暗黙的にそのキャラクターとして振る舞ってほしい場合において書いた方が無難
ポジティブなキーワード推奨（「優秀」など）
Task
目的背景：なぜこのタスクを実行するのか
スコープ：範囲や制約（やっていけないことも含む）
手順・チェックポイント：タスクを遂行するための具体的なステップや達成されるべきこと
完了条件：完了したとみなされる条件
Input
LLMから入力される情報の形式や内容を定義
Output Format
出力スキーマを指定
Guidelines
タスク外のルールや諸注意（振る舞いや言葉遣い）
肥大化の恐れがあるのでまずはRoleに指定してから
Prohibited Actions
禁止事項（繰り返し書いて強調しておく）
Timestamp
タイムスタンプ
User Information
ユーザー情報
Knowledge Base
参照すべき知識を与える（問い合わせ頻度の高いものなどあらかじめ入れておく）
Jinja2 ライブラリ
動的に内容を生成する
オーバーフィッティング
与えた例を過度に追従してしまう
Few-shot Prompting
少数の例をコンテキストに含めるのみ
1ケースにおける追加コストは推論時のトークン消費のみ
もともと学習されてないタスクはいくら例示しても意味がないことがある
ファインチューニング
モデルの再学習プロセスが必要で、専門的な知識が求められる
多数の質の高いデータセット（数百以上）の準備の人的コスト
モデルの学習時コスト
APIによって別途コンピューティング費用
モデルの内部パラメータが調整されるため、本来対応できないタスクが可能になることがある
レコード
検索対象テキストごとに作られている複数のフィールドを持ったデータ単位
インデックス
レコード群が検索可能な形で検索エンジンに登録されたもの
検索対象テキスト
レコード内で検索用に用いられるフィールドのテキスト
取得対象テキスト
レコード内でLLMに返送されるフィールドのテキスト
ドキュメント
一般的な文書全体を指すことが多く、検索エンジンのレコードとは区別する
フルテキスト検索のクエリ生成ポイント
表記ゆれの修正
同義語・ドメインの固有語辞書の活用
具体性と抽象性のバランス
AND, OR, NOTまで含めた条件設定
ベクトル検索のクエリ生成ポイント
明確で情報密度の高いテキスト形式でのクエリ生成（対象・観点・制約）
検索対象テキストで使われる表現への寄せ
複数の観点からのクエリ生成
固有名詞や記号的情報に頼らない調整
ベクトル検索の弱点
固有名詞への弱さ
類似度の意味のあいまいさ
解釈の困難さ（意味的に類似してるからと曖昧になりがち）
PRF
各検索手法でのランキング順位を基にスコアを統合する手法
リランク
検索エンジンから取得した初期結果を、LLMが再評価・再順序付する手法
Pandoc ライブラリ
内部でドキュメント変換ツールを呼び出し、Wordドキュメント（.docx）を直接HTMLに変換できる
Posted by ブクログ
コーディングエージェントを使いまくってコンテキストを意識しており、更にコンテキストを減らしたくて読んだ。具体性に欠け、目新しいことはなかった。
