{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreihakdqfhmjsivts5lbmzgvs6fi3k3vg5gkz44zyrvqlmyl3h3onzq",
"uri": "at://did:plc:ctnrfotecqqhvo7kl5cgtpwt/app.bsky.feed.post/3mhwtphjjvfb2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreiaxacrdc2ysysufis2wos6noxlwj2nojfh5onfdofpzekw3rmonga"
},
"mimeType": "image/png",
"size": 651738
},
"path": "/entry/2026/03/26/100000",
"publishedAt": "2026-03-26T01:00:00.000Z",
"site": "https://toranoana-lab.hatenablog.com",
"tags": [
"以前の記事",
"gihyo.jp",
"toranoana-lab.co.jp"
],
"textContent": "こんにちは、虎の穴ラボのY.Fです。\n\n以前の記事で紹介していますが、筆者の虎の穴ラボでの仕事としては、最新技術の導入だったりセキュリティ関連だったりします。\n\n今回の記事では、どちらかと言うと最新技術寄りである、AIに関しての本を読んだ感想になります。\n\ngihyo.jp\n\nコンテキストエンジニアリングということで、AIにどうやって指示や意思を伝えるのが良いか、などについて書かれている本になります。\n\n# 本書を読んだ理由\n\n上記で述べた通り、自分の立場上技術的に難易度が高かったり、今まで社内に知見が無いようなプロダクトの開発に携わることが多々あります。 その中に、AIを利用したサービスの提供なども増えてくるようになりました。\n\nAI利用サービスを提供するにあたり、いつも課題になるものに以下のようなものがありました。\n\n * どうやってAIに指示だったり意思を伝えて、思ったとおりに動かせばいいかの試行錯誤に時間を使う\n * 上手く行ったとしても、プロンプトの改善って意外に言語化が難しく、根拠に欠ける\n * 対象の情報を与える必要があるが、RAGにしても直接投入するにしてもどれが良いか1からの試行錯誤になる\n\n\n\n要するに、結果的に思ったような動作だったり出力をさせることはできているが、それがどこがどう効いているか上手く言語化できてないという感じです。 もちろん、Open AI社などが出しているドキュメントやネット上の資料などには目を通していましたが、もう少し補強する必要があるなと感じていました。\n\n今回紹介するコンテキストエンジニアリングを読んだ理由は、上記で挙げた課題のように、AIに対してどのように入力情報を与えればよりよい回答ができるかについて、 論理的に理解し、説明できるようになりたいといったところがモチベーションになります。\n\n# 目次\n\n目次\n\n\n 第1章 LLMの仕組みから見るコンテキストの正体 1.1 LLMの動作を知る意義 1.2 LLMを構成するニューラルネットワークの基本 1.2.1 ニューラルネットワークの歴史 1.2.2 機械学習における基本的な考え方 1.2.3 推論の呼称について 1.2.4 機械学習における学習の流れ 1.3 LLMによるトークン生成のしくみ 1.3.1 ニューラルネットワークの強力な応用「Transformer」 1.3.2 LLMのベースとなるTransformerにおけるデコーダ 1.3.3 LLMによるトークン生成における処理の概要 1.4 対話型LLMに施された工夫や注意点 1.4.1 ロール指定による振る舞いの切り替え 1.4.2 応答例への追従性 1.4.3 入力テキストの位置による認識精度の差（Lost in the Middle） 1.4.4 過去会話の揮発性 1.4.5 言語間の性能格差 1.5 Reasoningモデルの進化へ 1.5.1 Reasoningモデルの登場経緯 1.5.2 Reasoningモデル特有の挙動 1.6 まとめ 第2章 APIサービス利用におけるコンテキストの扱いと基礎機能 2.1 LLMのAPIサービスの概要 2.2 LLMベンダーが直接提供するAPIサービス 2.2.1 OpenAI API 2.2.2 Claude API 2.2.3 Google AI Studio 2.2.4 その他のLLMベンダー提供API 2.3 クラウドベンダーが提供するAPIサービス 2.3.1 Azure OpenAI Service （Microsoft Foundry） 2.3.2 Amazon Bedrock 2.3.3 Google Cloud Vertex AI 2.4 APIやモデルの選定基準 2.4.1 回答品質の判断 2.4.2 コストの考え方 2.4.3 コンテキストキャッシュの有無 2.4.4 コンテキストウィンドウの大きさ 2.4.5 モダリティの種類 2.4.6 コンテンツフィルター機能の有無や種類 2.4.7 組み込みツールの種類と性能 2.4.8 その他の着目すべき機能 2.5 APIの基本的な使い方 2.5.1 APIキーの取得 2.5.2 APIクライアントのセットアップ 2.5.3 APIリクエストの基礎とコンテキストとの関係 2.5.4 レスポンスの取り扱い 2.6 LLMによるツール利用 2.6.1 Function Callingを使ったツール利用 2.6.2 Model Context Protocol（MCP）を通じたツール利用65 2.6.3 API組み込みのツール利用 2.6.4 組み込みツール使用のリクエスト 2.7 出力スキーマの固定化 2.7.1 LLMによる構造化出力の必要性 2.7.2 Sturctured Outputの概要 2.7.3 Structured Outputの例 2.8 Function CallingとStructured Output使用時のテクニック 2.8.1 パラメータ出力の精度の向上のアイデア 2.8.2 出力順序の意識 2.9 コンテキストキャッシュの仕組み 第3章 指示プロンプト開発の基礎 3.1 前提となるリファレンス 3.2 指示プロンプト開発時に把握しておくべき全体指針 3.2.1 曖昧語の排除、具体性・再現性の確保 3.2.2 英語の使用 3.2.3 否定形を避ける 3.2.4 指示を矛盾させない 3.2.5 複数項目の指示・出力はなるべく避ける 3.2.6 重要な情報は冒頭に書く 3.2.7 HowよりWhatを重視する 3.3 指示プロンプトの記述に活用される記法 3.3.1 ベースとなる記法Markdown 3.3.2 XMLライクなタグの活用 3.3.3 複雑な結合や入れ子の表現で活躍するHTML 3.3.4 柔軟なデータ表現や出力に用いるJSON 3.3.5 可読性が高くトークン消費が少ないYAML 3.4 指示プロンプトの基本構造 3.4.1 Role 3.4.2 Task 3.4.3 Input 3.4.4 Output Format 3.4.5 Guidelines 3.4.6 Prohibited Actions 3.4.7 Timestamp・User Informationなど 3.4.8 Knowledge Base 3.4.9 Example 3.5 指示プロンプトの管理 3.6 指示プロンプトの精度向上の技法 3.6.1 Few-Shot Prompting 3.6.2 モデルから得るコンテキストを活用するChain of Thought 第4章 RAGにおけるコンテキスト整備 4.1 RAGとは 4.2 検索エンジン関連用語の整理 4.3 RAGの全体のフロー 4.4 RAGを使うかどうかの判断 4.5 RAGで用いられる基盤技術 4.5.1 フルテキスト検索 4.5.2 ベクトル検索 4.5.3 ハイブリッド検索 4.5.4 リランク 4.5.5 取得結果のデータの構成 4.6 検索を伴うRAGの精度向上のための工夫 4.6.1 実務で見るべきチューニングポイント 4.6.2 検索エンジンの選定と設定 4.6.3 適切なクエリの作成 4.6.4 ファイル形式ごとのテキスト抽出方法 4.6.5 中間生成テキストの作り方の基本 4.6.6 インデックス化（チャンク・検索対象テキストの抽出） 4.6.7 RAGの監視・評価の重要性 4.7 その他の話題 4.7.1 高度なRAG手法に本書で触れない理由 4.7.2 CAGという選択肢 4.7.3 MCPの活用によるRAGの再利用 4.7.4 マネージドRAGによるコンテキスト取得 4.7.5 データを知識グラフ化して参照するGraph RAG 第5章 AIエージェント×ワークフローによる作業自動化 5.1 AIエージェントはなぜ注目されたのか 5.1.1 チャットUIのLLMアプリケーションの問題点 5.1.2 市場におけるAIエージェントへの期待 5.1.3 最も簡単なAI エージェント―――プロンプトベースエージェント 5.1.4 プロンプトベースエージェントの限界 5.1.5 AIエージェントの精度低下の根本原因と対策 5.2 ワークフロー化によるコンテキストの分散 5.2.1 ルールベース処理 5.2.2 シンプルなAI/ML処理 5.2.3 AIエージェント 5.2.4 ワークフロー化の注意点と弊害 5.3 市場が期待した「AIエージェント」の正体 5.4 エージェントワークフローに関連するリファレンス 5.5 具体例を見ながらエージェントワークフロー設計を学ぶ 5.5.1 AIエージェントの本書での取り扱い 5.5.2 サンプルシナリオの概要 5.5.3 自動化対象フローの整理 5.5.4 エージェントワークフローにおけるUX/UI 5.5.5 プロンプトベースエージェントのコンテキスト開発 5.5.6 コンテキスト削減のためのワークフロー化へ 5.6 コンテキスト肥大化に伴うその他の課題と対策 5.6.1 ツール定義の肥大化 5.6.2 ターン経過によって肥大化するコンテキスト 5.6.3 コンテキストによるコスト増大への対策\n\n# 全体の感想\n\n狙い通り、論理的にどのようにAIに指示をすればいいのか、全体を通して理解できる本だったかと思います。\n\nLLMのコンテキストにおける中間情報が抜けやすい、Lost in the middleについて事前知識は持っていましたが、 1章、2章で何がどの順でコンテキストに含まれるかの説明があり、より具体的に何がLost in the middleにつながるかなどの実感が持てたかなと思います。\n\nその後の章ではより具体的にどのようにコンテキストを組み立てるかについて記載があり、現実のAIアプリケーションへの応用に関しても実感が持てるいい内容だったと感じました。\n\n個人的には、単に「プロンプトの書き方」を説明する本ではなく、LLMの内部的な都合やAPIの仕様、RAGやワークフローの設計まで含めて、なぜその工夫が必要になるのかを説明してくれるところが良かったです。 最近はAI関連のノウハウがテクニック集のような形で流れてくることも多いですが、本書はその場しのぎの小手先ではなく、背景にある理屈から整理してくれるので腹落ちしやすい構成だと思いました。\n\nまた、実務をやっていると「たまたま上手くいったプロンプト」を抱えて前に進むことはできてしまいますが、それを再利用可能な知見にするのが難しいと感じます。 本書は、その曖昧になりがちな部分に対して、コンテキストという共通の観点で整理してくれるのがありがたかったです。 AIを使った機能開発をしている人はもちろん、これからAI機能を組み込む立場の人にとっても、かなり実践的な内容だと思いました。\n\n# 1章の感想\n\n1章では、まずLLMが何をしているのかという基礎の部分から説明されています。\n\nTransformerやAttention機構、デコーダーによるトークン生成など、すでに名前だけは広く知られている話題が中心ではあるのですが、 本書ではそれらが単なる用語解説で終わらず、「コンテキストをどう読むか」という話につながる形で書かれているのが印象的でした。\n\n特に、LLMは最終的にはトークンの出力確率を元に次の単語を出しているだけ、というかなり基本的なところから、 チャット形式のやり取りが成立しているのは、roleやメッセージ形式を含む入力の作り込みがあるからだ、という説明まで流れで読めるのがよかったです。 普段ChatGPTや各種APIを使っていると、どうしても会話している感覚になりますが、裏側ではかなり機械的に「次を予測している」だけという点を改めて意識できました。\n\nまた、この章で特に印象に残ったのはやはりLost in the Middleです。 重要な情報を入れれば良い、というだけではなく、どこに置くかで拾われやすさが変わるというのは、実際に触っていても感じるところでした。 本書では、末尾・冒頭・中盤で認識されやすさが違うことや、会話履歴が増えると過去の情報が揮発しやすいことが整理されており、 「なぜ長いプロンプトを書いたのに効かないことがあるのか」を説明しやすくなった気がします。\n\nReasoningモデルについての説明も興味深かったです。 思考過程を経由することでコンテキストを厚くし、より複雑な問題に対応しやすくなる一方で、当然ながら遅くなるし、設定次第では性能の落ち方も極端になるという話は実務的でした。 最近はReasoningを使えば何でも解決、という雰囲気もありますが、ちゃんとトレードオフとして捉える必要があるなと思いました。\n\n全体として1章は、以降の章を理解するための土台になっている章だと感じました。 すでにLLMを触っている人にとっても復習では終わらず、「だからコンテキスト設計が重要なのか」と納得しやすい内容だったと思います。\n\n# 2章の感想\n\n2章ではAPIの利用方法や、実際のLLMサービスの機能がコンテキストとどう関係しているかについて説明されています。\n\nこの章でよかったのは、ベンダー比較やモデル比較を必要以上に神格化していないところです。 もちろん各社で差はありますし、得意不得意もありますが、実務上は比較に時間を使いすぎるより、まずは主要な選択肢で試しつつ、要件に応じて見極める方が現実的だと思っています。 そういう意味で、品質・コスト・コンテキストウィンドウ・キャッシュ・モダリティ・フィルター・ツール群、といった観点で整理されているのはかなり実践向きでした。\n\n個人的には、APIの機能説明の中で「全部コンテキストに含まれる」という話がきちんと出てくるのが印象に残りました。 ツール定義やStructured Outputのスキーマ、会話履歴など、便利だからと何でも足していくと当然コンテキストを圧迫します。 実際、コーディングやRAG、ツール呼び出しを組み合わせると、思っている以上に入力領域がすぐ埋まる感覚はあるので、その感覚が言語化されているのがありがたかったです。\n\nFunction CallingとMCP、RAGの違いをきちんと整理している点も良かったです。 この辺りは世の中でも用語が混ざって語られがちですが、情報取得なのか、関数呼び出しなのか、インターフェースの標準化なのかを分けて理解しないと設計を誤りやすいと思います。 特にFunction Callingは「関数を実行してくれる魔法」ではなく、呼び出しに必要なパラメータをうまく出させる仕組みとして捉えた方が理解しやすい、という整理には納得感がありました。\n\nResponse APIや会話履歴の扱いの話も印象に残っています。 通常のメッセージ配列だけでは思考過程を十分に扱えない場合があるため、previous_response_idなどを利用して前の応答をつなぐほうが都合が良い、といった話は、単にAPIリファレンスを読んでいるだけでは見落としやすいポイントだと思いました。 また、コンテキストキャッシュが先頭一致に近い形で効いてくるので、出力定義やツール定義を頻繁に変えるとヒットしづらいという話も、運用時のコスト感覚に直結する内容でした。\n\nこの章はかなり実務の匂いが強く、APIの使い方を覚えるというより、どこでコストや精度が落ちるのかを理解する章だと思いました。 AIアプリケーションを作る側としては、かなり刺さる内容でした。\n\n# 3章の感想\n\n3章は、いわゆる指示プロンプト開発の章です。 個人的には、本書の中でも特にすぐ業務に持ち帰りやすい章だったと思います。\n\n書かれている内容自体は、一見するとすでに見聞きしたことがあるものも多いです。 曖昧な表現を避ける、否定形を避ける、矛盾を作らない、重要な情報を目立つ位置に置く、といった話は定番かと思います。 ただ、本書のよいところは、それを単なる経験則として並べるのではなく、前の章までで説明されたLLMの性質やコンテキストの扱い方と結びつけて説明しているところだと思います。\n\nたとえば「HowよりWhatを重視する」という話は、個人的にもかなり納得感がありました。 細かいテクニックをこね回すより、何を達成したいのか、何を入力として持ち、どういう完了条件なら成功なのかを明確にした方が安定する、というのは実務でもその通りだと感じます。 結局、良い出力を得るためには、モデルに与える文章の書き方だけではなく、要件そのものをちゃんと定義する必要があるわけで、そこをコンテキストエンジニアリングとして扱っているのが本書らしいところでした。\n\nまた、Role、Task、Input、Output Format、Guidelines、Prohibited Actionsといった構成要素を整理してくれているのも実用的でした。 普段なんとなく書いていたプロンプトを、「これは役割の説明」「これは出力形式」「これは禁止事項」と分解して見直せるようになるので、保守性も上がりそうです。 テンプレート管理やFew-Shotの入れ方、Chain of Thoughtの使いどころまで触れられているので、単発の実験だけでなく、継続的に運用するプロンプトの設計にもつながる章だと思いました。\n\n一方で、この章を読んで改めて思ったのは、人間向けの丁寧な仕様書をそのまま全部入れれば良いわけではないということです。 ルールを増やしすぎれば精度が上がるわけでもなく、むしろノイズになります。 その意味では、必要な指示を必要な構造で整理し、モデルが読みやすい形にして渡すというのが大事なのだと再確認できました。\n\nプロンプトを書いていると、つい呪文のような方向に行きがちですが、この章はそうではなく、構造化された設計の話として読めるのが良かったです。\n\n# 4章の感想\n\n4章はRAGの章ですが、単に「ベクトル検索を使いましょう」という話になっていないのが良かったです。\n\nRAGというと、どうしてもベクトル検索の話ばかりが前に出がちですが、本書では全文検索やハイブリッド検索、リランクなども含めて整理されていました。\n\n特に印象に残ったのは、クエリ作成とインデックス化の話です。 ユーザーの入力をそのまま投げるだけで上手くいくことは少なく、タイプミス補正や知識補完、Step Backのような上位概念の生成、複数クエリ生成など、 検索前にひと手間入れることで結果が大きく変わるという話は実務的でした。 検索の質はストレージの選定だけで決まるのではなく、何をどう探すかの設計でもかなり差が出る、というのを改めて感じました。\n\nまた、ファイルごとのテキスト抽出や中間表現の作り方にかなり踏み込んでいるのも面白かったです。 現場では、元の文書が必ずしも検索しやすい形をしていないことが多いですし、図や表、画像が重要な情報源になっていることも珍しくありません。 そのため、単純に文字列を抜き出して終わりではなく、検索しやすい説明文を追加したり、画像を説明テキスト化したりする必要がある、という話は非常に実感がありました。\n\nチャンク化の話も印象的でした。 機械的に一定長で切れば良いわけではなく、意味のまとまりを壊すと精度が落ちるので、前後関係を見ながら中間表現を設計する必要がある、という話がありました。 また、具体的に例を上げてどういうチャンクだったりインデックスだったりを設計するかについて触れられていて、実感を伴いやすいと思いました。\n\n評価についても、クエリ・検索結果・回答の三段階で見る必要があるという整理が良かったです。 AIの出力だけを見て良し悪しを判断してしまいがちですが、そもそも検索が悪いのか、回答合成が悪いのかを分けて見ないと改善できません。 LLM as a Judgeのような評価方法も含めて、運用しながら改善していくための視点があるのが実践的でした。実際に以前チャットボットなどを作ったときはLLMを使って評価を行っていたので、方向性としてはズレてなかったんだなと思いました。\n\nRAGをこれから作る人にも、すでに作っていて精度に悩んでいる人にも、かなり参考になる章だと思います。\n\n# 5章の感想\n\n5章は、AIエージェントとワークフローの章です。 最近はAIエージェントという言葉がかなり広く使われていますが、本書ではその中身をやや冷静に整理してくれているのが良かったです。\n\n特に印象に残ったのは、1つのエージェントに何でもやらせようとすると、結局はコンテキストが膨らみすぎて不安定になる、という話です。 やることもツールも判断材料も全部詰め込めば賢くなるわけではなく、むしろ精度が落ちるというのはかなり実感に近い話でした。\n\nそのため、ルールベースで十分な処理は普通のプログラムに任せて、曖昧さが残る部分だけをLLMに任せる、という考え方にはかなり納得感がありました。 また、ワークフローとして処理を分割し、その段階ごとに必要な情報だけを持たせる、という設計も実務的だと感じました。\n\nAIエージェントというと派手な言葉に見えますが、本書を読むと本質は責務分離とコンテキスト整理なのだと思います。 個人的にも、何でも1つの高機能なエージェントに押し込むのではなく、どこまでを決め打ちにして、どこにだけ柔軟性を持たせるかを意識して設計したいと感じました。 流行りのキーワードに寄りすぎず、かなり地に足のついた章だったと思います。\n\n# まとめ\n\n今回紹介した「コンテキストエンジニアリング」は、AIに対してどう指示を書くかという狭い話ではなく、 LLMの性質、APIの仕様、プロンプト設計、RAG、エージェントワークフローまで含めて、入力情報全体をどう設計するかを扱った本でした。\n\n読んでみて感じたのは、AIアプリケーション開発において問題になりやすいことの多くが、結局はコンテキストの設計に集約されるのだなということです。 プロンプト単体の改善に見える話も、RAGの検索精度の話も、エージェントの不安定さの話も、どの情報をどの順番で、どの粒度で与えるかという問題として見ると整理しやすくなります。\n\nまた、本書の後半で扱われていたワークフローやAIエージェントの話も面白く読めました。 個人的には、何でも1つの高機能なエージェントに押し込むのではなく、ルールベースで良い部分は分離し、必要なところだけLLMに任せるという考え方にはかなり共感しました。 最近はAIエージェントという言葉が先行しがちですが、実際にはコンテキストの分割や責務の整理の方が本質なのだろうと思います。\n\nAI関連の情報は変化が速く、手法だけ追いかけているとすぐに古くなりがちですが、本書は比較的長く使える考え方が中心になっていると感じました。 AIを使ったプロダクトや社内機能を作る立場の人にとって、かなり役立つ一冊だと思います。\n\n自分としても、今後AI関連の機能開発を進めるうえで、なんとなく上手くいった手法を積み上げるのではなく、 なぜそれが効いたのか、どのコンテキストが効いているのかを意識して設計していきたいなと思いました。 AIを触っているけれど、プロンプトやRAGやエージェントの話がそれぞれ別物に見えている方には、特におすすめできる本です。\n\n# 採用情報\n\n虎の穴ラボでは一緒に働く仲間を募集中です！\nこの記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧ください。\ntoranoana-lab.co.jp",
"title": "『コンテキストエンジニアリング』を読んで、AI活用の解像度を上げよう",
"updatedAt": "2026-03-26T01:00:02.000Z"
}