コンテキストエンジニアリング

💡 学習ガイド：プロンプトエンジニアリングが解決するのは「どうやって明確に伝えるか」であり、コンテキストエンジニアリングが解決するのは「モデルに適切なタイミングで適切な情報を見せること」です。本章では次の問いを中心に展開します：限られたコンテキストウィンドウの中で、どうすればモデルに意図を理解させつつ、コストを抑えられるのか？

始める前に、以下の2つの「基礎知識」を先に押さえておくことをおすすめします：

• トークンとは何か：大規模言語モデル入門 の「トークン化とトークン」セクションを先にご覧ください。
• プロンプトとは何か：System / User / Assistant の基本構造にまだ慣れていない場合は、プロンプトエンジニアリング を先にお読みください。

---

0. はじめに：なぜ会話が進むと忘れたり、コストがどんどん上がるのか？

1Current round

1200Token usage

$0.0024Current cost

✅Memory intact

Context Window Limit (4000)

System Prompt (1000)

New Input

Drag the slider to add conversation rounds:

Round 1Round 20

💡 Everything is normal：The current token count (1200) is still within the window. The model can recall all conversation details.

多くの人が大規模言語モデルを実際に使うと、こんな状況に遭遇します：

• 会話の途中で、モデルが突然それまで話していた重要な条件を「忘れる」；
• 長い会話の中で、前後の回答が矛盾し、同じ設定を維持できなくなる；
• 会話のターン数が増えるほど、料金がタクシーメーターのように上がり続ける。

直感的には「このモデルは記憶力が悪い」と思ってしまいがちです。 しかし、ほとんどの場合、問題はモデルが「覚えられない」ことではなく、私たちがモデルに見せるコンテキストを適切に設計していないことにあります。

Problem

• Context is hard to keep consistent：As conversations grow, earlier and later meaning can drift apart.
• Key facts are easy to lose：Information given early can be hard to reference accurately later.
• Call cost keeps rising：Every round has to process a large amount of history again.

Likely causes

• The model only sees the current call：It can only rely on the context provided in this round.
• Information is not structured：Important facts and minor details are mixed together, making stable memory hard.
• History is recomputed repeatedly：Large fixed prefixes are processed again and again across turns.

Impact

• Answer quality becomes unstable：Longer conversations make consistency and traceability harder.
• Cost is hard to estimate：Context size fluctuates heavily from turn to turn.
• Production systems become hard to maintain：Without a clear context strategy, systems are hard to operate and extend.

こうした課題に対して、単に「良いプロンプトを書く」だけでは対応しきれません。限られたウィンドウと予算の中で、モデルに最も重要な情報を常に届けるための、より体系的なエンジニアリング手法が必要です。それがまさにコンテキストエンジニアリングが解決しようとしている問題です。

---

1. 「コンテキストエンジニアリング」とは？（定義とユースケース）

まずは簡潔な作業定義を示し、それから典型的なシナリオを見ていきましょう。

コンテキストエンジニアリングとは、LLM のために「情報環境」を構築・管理するエンジニアリング手法であり、モデルが「何を見て、何を無視し、いつ見るか」を決定することで、限られたコンテキストウィンドウ内で安定的にタスクを完了させるものです。

簡単に言えば、次の3つのことに集約されます：情報の整理、ウィンドウの制御、コストの管理。 よく使われるシナリオは以下の通りです：

• 対話型エージェントやカスタマーサポートボット
• コード・ドキュメントアシスタント
• 複数ターンのツール呼び出しや長時間のワークフロー編成

それでは、ある実際のチームの「苦い経験」から出発し、彼らがどのようにして「プロンプトを書くだけ」から「コンテキストエンジニアリングを行う」へと進化していったのかを見ていきましょう。

---

2. 「苦い経験」から始まる：Manus チームが踏んだ落とし穴

本章の事例は Manus（汎用 AI エージェント）によるものです。 通常の対話とは異なり、Manus は自律的に計画を立て、ツールを呼び出して長時間のタスク（数十から数百ターンのインタラクション）を完了する必要があります。

これが中心的な矛盾を生み出します：

• 覚えていない場合：重要な情報が失われ、タスクが中断する。
• すべて覚えている場合：コストと遅延が爆発し、ウィンドウの制限すら超えてしまう。

Manus チームは何度もアーキテクチャの再構築を経験し、ようやく一つの真理を理解しました：コンテキストは「書く」だけではダメで、「設計する」ものだ。

2.1 4度の再構築が教えてくれたこと

Manus の共同創業者である季逸超氏は、彼らの「失敗の歴史」をこう共有しています：

段階	直面した問題	当時の考え	結果
1回目	AI が会話の途中で忘れる	「プロンプトをもっと書けばいい」	書けば書くほど長くなり、コストも増大
2回目	重要な情報がいつも押し出される	「重要なものは何度もコピーしよう」	テキストがさらに長くなり、コストも増加
3回目	請求額が驚くほど高い	「以前の計算を再利用できないか？」	重複計算のコストを下げる方法を発見
4回目	長文ドキュメントが処理できない	「必要な時に検索すればいいのでは？」	「図書館＋オンデマンド検索」の仕組みを構築

核心的な学び：多く覚えればいいのではなく、巧く覚えることが重要なのだ。

2.2 AI の「記憶力」は何に例えられるか？

従来のコンピュータメモリ = ハードディスク：

• 大容量：大量のデータを長期間保存可能；
• 低価格：1年間保存するコストは比較的低い；
• 読み書き速度は比較的遅く、情報の検索には一定の時間がかかる。

AI のコンテキスト = 小さな黒板：

• 読み書きが速い：モデルは1回の呼び出しでコンテキスト全体を直接見ることができる；
• 容量に限りがある：いっぱいになると古い内容を消さざるを得ない；
• 1トークン書き込むごとに追加の計算と費用が発生する。

Manus の経験：小さな黒板は節約して巧く使い、百科事典を保存する場所にしてはいけない。

---

3. 第一歩：コストを理解する - あなたのお金はどこに消えているのか？

3.1 なぜ最初にコストを見るのか？

典型的な AI 対話で、あなたのお金がどのように使われているかを見てみましょう：

💰 コスト構成（1回の対話）：
├─ 70% 過去の内容を繰り返し見る（「さっき何を話したっけ？」）
├─ 20% 新しい内容を処理する（「今何を言っている？」）
└─ 10% 返信を生成する（「どう答える？」）

驚くべき発見：70% のお金が、AI にあなたが前に言ったことを再読させるために使われている！

3.2 KV Cache とは？（プレフィックス再利用）

価格の話に入る前に、まず重要な技術概念を理解する必要があります：KV Cache（キーバリューキャッシュ）です。 この技術用語に怯えないでください。これは要するに AI の「短期記憶の早見表」です。

• KV Cache がない場合：AI は毎回、この文章を初めて読むかのように、最初の文字から読み直し、理解し、計算し直します。
• KV Cache がある場合：AI は既に読んだ部分（Pre-fill）の計算結果を保存します。次回、冒頭部分が変わっていなければ、記憶をそのまま呼び出し、再計算の必要がありません。

これはちょうど次のようなものです：

あなたは試験会場にいます。 ケース A：毎回教科書全体を最初から読み直してから問題を解き始める。（遅い、疲れる、高い） ケース B：教科書の内容を完璧に暗記しており（キャッシュ）、座ってすぐに解答できる。（速い、楽、安い）

クラウドベンダーの料金表では、「暗記済みの本」（キャッシュヒット）は通常「新しく読む本」（キャッシュミス）より 90% 以上安くなります。

3.3 「暗記」vs「その場で調べる」の価格差

Claude を例にとると：

• その場で調べる（キャッシュなし）：$3.00 / 百万トークン
• 暗記してから使う（キャッシュあり）：$0.30 / 百万トークン
• 10倍の差！

Manus の実践：AI に「暗記」させることで、コストを $0.15 から $0.02 に削減し、87% 節約しました！

13Tokens written so far

/

100Maximum tokens on the board

13.0%

🧠The small board the model can see (context window)

ContextEngineeringmeansoptimizingtheinformationprovidedtoalargelanguagemodel.

Input content

Context Engineering means optimizing the information provided to a large language model.

💡Note: The context window is like a small board for the model. The board has limited space, so old content must be erased before new content can fit. Once it overflows, the earliest content disappears from the model view.

3.4 落とし穴ガイド：タイムスタンプでキャッシュを台無しにしないで

多くの開発者は「現在時刻」を System Prompt の最初の行に書く習慣があります。それを厳密で良いと思っているのです。 しかしこれは、コンテキストエンジニアリングにおける最大のアンチパターンの一つです。

想像してみてください：あなたが歴史の教科書一冊分（System Prompt）を丸暗記したのに、その本の1行目が「現在の秒数」だったら。 もしこの行が毎秒変わるなら、1秒前に暗記した内容はすべて次の秒には無駄になり、また最初から暗記し直さなければなりません。

これがプレフィックス再利用（KV Cache）の致命的な弱点です：先頭が変わるだけで、後続すべてを再計算しなければならない。

悪い例：動的情報を先頭に置く

System: 現在は 2024-01-01 12:00:01 です。あなたはアシスタントです...
(1分後)
System: 現在は 2024-01-01 12:01:01 です。あなたはアシスタントです...

結果：数文字しか変わっていないのに、先頭にあるため、後続の 99% の固定内容がキャッシュを再利用できず、毎回のリクエストが初回同様に遅くて高くつきます。

正しい方法：静的と動的の分離

System: あなたはアシスタントです... (ここに数千文字の固定ルールや知識ベースを配置)
User: (ここでツール呼び出しやユーザーメッセージを通じて現在時刻を渡す)

メリット：先頭の数千文字のルールは永遠に変わらないため、AI は一度「暗記」すれば済みます。以降のリクエストは直接記憶を呼び出し、非常に高速です。

👇 クリックして試してみましょう： 下のスイッチをクリックして「暗記加速」をオンにし、「新しいリクエストを送信」を複数回クリックしてください。 最初のブロックが「暗記済み」になったとき、応答開始速度（TTFT） がどう変化するか観察してみましょう。

Enable prefix reuse / KV Cache

⚙️Fixed opening prompt (System Prompt)

You are a helpful AI assistant... (about 500 tokens)

💬Recent chat history

User: hello... (about 200 tokens)

❓New question for this turn

Write a Python snippet for me (about 50 tokens)

0ms

Time to first token (TTFT)

0

Tokens processed this time

0

Approximate compute cost

⏱️Without cache:Every request recomputes attention from the beginning, like rereading a textbook from page one every time.

---

4. 第二歩：スライディングウィンドウ - 「記憶」が「コスト」になるとき

会話が長くなるにつれて、最初に直面する問題は：ウィンドウがいっぱいになったらどうするか？

4.1 なぜ「先入れ先出し」は問題なのか？

最もシンプルな記憶管理はスライディングウィンドウ（Sliding Window）：新しいものが入り、古いものが出ていく。 これは公平に聞こえますが、実際のタスクでは大惨事を引き起こします。

シナリオ再現：

会話履歴：
[1] ユーザー：私は張三です。決済システムを担当しています
[2] ユーザー：プロジェクトは Go 言語で開発しています
[3] ユーザー：データベースは PostgreSQL です
...
[20] ユーザー：インターフェースを作成してください

結果：20文目まで会話が進むと、1文目の「私は張三です」は既にウィンドウの外に押し出されています。AI はあなたが誰かも、何のシステムを担当しているかも完全に忘れてしまいます。

問題の本質：この戦略は重要な情報（身元、技術スタック）と無駄話（「了解」「承知しました」）を同等に扱い、一緒に追い出してしまうことです。

4.2 「中間忘却症」 - なぜ AI は重要な情報を見落とすのか？

「すぐ忘れる」ことに加えて、AI にはもう一つの癖があります：「見落とす」ことです。 研究によると：AI は先頭と末尾に最も敏感で、中間部分が最も無視されやすいことが分かっています。これが有名な Lost in the Middle（中間での喪失） 現象です。

U字型記憶曲線：

位置：先頭 → 中間 → 末尾
記憶： 高  →  低  →  高

👇 クリックして試してみましょう：

1. まず「スライディングウィンドウ」を試してください：下のチャットボックスで複数メッセージを送信し、古い会話がどのように無情に「押し出される」かを見てみましょう。
2. 次に「中間での喪失」を見てみましょう：重要な情報が文章全体の中間部分に隠されているとき、検索成功率が最も低くなることを観察してください。

Maximum remembered messagesUp to 4

🗑️ Forgotten content

Nothing has been pushed out yet

⬆ Outside the window, invisible to the model

⬇ Inside the window, still visible to the model

🖼️ Conversation still in memory

Start chatting here and watch old messages get pushed out

💡Note: A sliding window is the simplest memory strategy: new content enters and old content leaves. It never overfills the context, but once content slides out, the model forgets it completely.

Where is the key fact in the full context: 50%

Start (System)

End (Query)

📍

Key fact

Recall probability

Position in context

40.0%

Retrieval success

Middle area, highest risk

Position description

🔍Observation:When a key fact is hidden in the middle of a long context, the model is most likely to miss it.
The reliable approach is to place important instructions at the very front in the System Prompt or at the end in the latest user query.

解決策：重要な情報を先頭（システムプロンプト）または末尾（ユーザーの質問）に配置すること。

---

5. 第三歩：選択的保持 - 重要な情報をどう「ピン留め」するか？

「先入れ先出し」が当てにならないなら、どうすればいいのでしょうか？ Manus の答えは：「情報のヒエラルキー制度」を構築すること。

5.1 なぜ情報にランク付けが必要か？

すべての情報を平等に扱うのではなく、重要度に応じて取捨選択します：

ランク	情報タイプ	扱い	コストへの影響
VIP	システム設定、ユーザー身元	永続的に保持	+15% コスト
重要	現在のタスク目標	タスク期間中保持	+10% コスト
一般	通常の会話履歴	直近5ターン保持	基準コスト
破棄可	検索可能な知識	必要な時に検索	-60% コスト

核心思想：25% のコスト増加で、90% の重要情報を保持する。

5.2 「ピン留め」戦略

コンテキストウィンドウを黒板に例えると：

• VIP 情報：釘で黒板の一番上にしっかり固定（System Prompt）。
• 重要情報：磁石で黒板の中央に貼り付け（Context Injection）。
• 通常の会話：黒板の下半分に書き、いっぱいになったら古いものを消す（Sliding Window）。

👇 クリックして試してみましょう： 下のデモで、ある重要な会話を「ピン留め」してみてください。 会話を続けると、ピン留めされた情報はずっと残り、ピン留めされていない情報は押し出されていく様子を観察しましょう。

3Messages remembered now

/

6Maximum messages on the board

📌Pinned area for important information1 now

System

You are a helpful AI assistant focused on coding.

📜Regular FIFO conversation2 now

User

Hi, I want to learn Vue.

AI

Sure! Vue is a progressive framework.

💡Note: Selective retention means pinning important information to the board while ordinary messages slide away. System prompts are usually pinned permanently, and key user facts such as names, accounts, or preferences can be pinned through memory modules or RAG.

---

6. 第四歩：RAG - 「記憶」に「図書館」が必要なとき

時には、扱う情報が多すぎて（数百ページの技術文書など）、黒板には到底書ききれないことがあります。そんな時に必要なのが外部の頭脳——RAG（検索拡張生成）です。

6.1 なぜ「小さな黒板」では足りないのか？

Manus が百万語レベルの技術文書に直面したとき、2つのアプローチを比較しました：

1. 全量投入：すべての内容を一度にコンテキストに詰め込む。
   • 結果：黒板が一瞬で埋まり、処理は極めて遅く、しかも「中間での喪失」理論により、AI は中間部分をまったく覚えられない。
   • コスト：約 $50/回、待ち時間15秒。
2. オンデマンド検索（RAG）：まず図書館（データベース）で検索し、関連する数段落だけを黒板に書き写す。
   • 結果：黒板はすっきりして、AI は重要な情報に集中できる。
   • コスト：約 $0.5/回、待ち時間2秒。

99% のコスト削減、87% の時間短縮！

6.2 「資料検索」のベストプラクティス

Manus の経験からのまとめ：

• 1冊の本をどのくらいのサイズに切り分けるか？ 500〜1000 トークンが最適。
• 一度に何冊検索するか？ 3〜5冊、多すぎるとかえって干渉する。
• どの程度関連する本を検索するか？ 類似度 > 0.7、無関係な内容を「無理に当てはめる」のを避ける。

👇 クリックして試してみましょう： 検索ボックスに質問（例：「パスワードをリセットする方法」）を入力し、システムが大量の文書の中から最も関連性の高い数件だけをどのように見つけ出すかを見てみましょう。

1User Query

🔍

2Library retrieval

📄Password reset guide

Users can reset their password by clicking the "Forgot password" link on the settings page. The system sends a verification email.

📄Pricing policy

Basic is $10 per month, Pro is $29 per month. Enterprise customers should contact sales for a quote.

📄API documentation

All API requests must include a Bearer Token in the Header for authentication.

📄Account security

For account security, enable two-factor authentication and change passwords regularly.

✂️ Copy into context

3Final Prompt

SYSTEM You are a professional AI assistant. Answer the user question using the retrieved materials below.

USER Waiting for a question...

---

7. 第五歩：圧縮 - 「小さな黒板」にもっと密に書くには？

情報がどれも重要で、どうしても削除できず、かつ検索もしたくない場合はどうすればいいか？ その場合は文字を小さく書くしかありません——これがコンテキスト圧縮です。

7.1 いつ「要約」が必要か？

• 検索で取得した資料が厚すぎる（>2000 文字）。
• 会話履歴が冗長すぎる（黒板の >80% を占有）。
• 素早く回答する必要があり、AI に長文を読ませたくない。

7.2 「要約」の3つのレベル

圧縮方式	圧縮率	保持するもの	適したシーン	節約効果
要約式	70%	主な意味	クイック理解	30% 節約
要点式	50%	キーポイント	構造化出力	50% 節約
表形式	30%	コアデータ	プログラム処理	70% 節約

👇 クリックして試してみましょう： 異なる圧縮戦略を選択し、長文がどのように短く洗練されていくかを見てみましょう。

1. Choose compression strategy

Original text420 tokens

Context Engineering means optimizing the prompt and information provided to a large language model so it has what it needs to generate accurate and relevant responses. One major challenge is the limited context window, which restricts how much text a model can process at once. Developers use techniques such as summarization to condense long documents while preserving key information. Retrieval-augmented generation fetches only the most relevant snippets for a user query. Converting unstructured text into structured data such as JSON can also reduce redundancy and increase information density.

⬇️

Compressed

Click a button above to start compression

---

8. システム統合：AI の「記憶の宮殿」を構築する

ここまで、私たちは積み木を組み立てるように、さまざまな独立した戦略を学んできました：

• KV Cache：コスト削減に役立つ（第3章）
• スライディングウィンドウ：スペース確保に役立つ（第4章）
• ランク別保持：重要点の維持に役立つ（第5章）
• RAG：外部拡張を可能にする（第6章）

今こそ、これらの積み木を組み立てて完全な城を築く時です——私たちはこれを Manus の「記憶の宮殿」と呼びます。

8.1 家を建てるようにコンテキストを組み立てる

コンテキストをごちゃごちゃした文字の集まりとして見るのではなく、階層化された建築物として見てください。各層には独自の機能と「居住ルール」があります。

👇 クリックして試してみましょう： 「建設開始」をクリックして、この宮殿をどのように一層ずつ築き上げていくかを見てみましょう。

🔍

Layer 4: Library (RAG)

Knowledge retrieved on demand

💬

Layer 3: Living Room (Chat)

Most recent 5-10 conversation turns

📌

Layer 2: Pillar (Task)

Current task goal and user profile

🏛️

Layer 1: Foundation (System)

System identity, role, and principles

🚧 Empty lot: click the button below to build the memory palace

Progress: 0/4

8.2 なぜこの設計が最強なのか？

この宮殿の設計哲学は、実は3つの矛盾を解決するためのものです：

1. 基礎（System Prompt）—— 「高い」問題を解決

   • 矛盾：システム設定（あなたは誰か、ルールは何か）が最も長く、毎回送信しなければならない。
   • 解法：これを最下層に配置し、KV Cache 技術を活用することで、変更さえしなければ AI は「全文を暗唱」できる。後続の数百ターンの会話で、この部分の計算コストはほぼ 0 になる。

2. 柱（Task Context）—— 「忘れる」問題を解決

   • 矛盾：会話が長くなると、AI は最初のタスク目標（例：「スネークゲームを作る」）を忘れがちになる。
   • 解法：ランク別保持戦略を活用し、タスク目標を第二層に「ピン留め」する。何ターン会話が続いても、この層は決して削除されず、AI が初心を忘れないようにする。

3. 最上階（Chat & RAG）—— 「混乱」問題を解決

   • 矛盾：新しい会話と検索した資料が混在し、混乱しやすい。
   • 解法：
     • リビングルーム（会話）：スライディングウィンドウで管理し、直近 5〜10 文のホットな会話だけを保持。
     • 図書館（RAG）：資料は使い終わったらすぐに片付け、場所を取らない。

8.3 実戦効果

Manus チームがこのアーキテクチャを本番環境に導入した後、効果は即座に現れました：

• コスト削減：基礎部分が「暗記」されたため、各ターンの会話コストが 84% 急減。
• 高速化：AI が毎回数千文字を最初から読む必要がなくなり、平均応答時間が8秒から 2秒 に短縮。
• 精度向上：重要な情報が「ピン留め」され、会話の途中で自分の役割を忘れることがなくなった。

---

9. 実戦テンプレート：そのまま使える設計図

この仕組みがどのように動作するかをより直感的に理解できるよう、全リンクシミュレーションを用意しました。

シナリオを選んで「次へ」をクリックし、ユーザーの質問から AI の回答までの数秒間に、記憶の宮殿がどのようにコンテキストを動的に呼び出し、組み立て、クリーンアップするかを見てみましょう。

📱 User view (Chat)

Help me write a Python snake game...

Step 1 / 5

🧠 AI view (Context Construction)

🏛️Layer 1: Foundation (System)KV Cached

System: You are a senior Python engineer...

📌Layer 2: Pillar (Task)Pinned

Task: Build a snake game with Pygame...

💬Layer 3: Living Room (Chat)Sliding

(No chat history yet)

📚Layer 4: Library (RAG)Temp

(No retrieval needed now)

💡 What happened in this step: Initialize: load the foundation (System) and task. Layers 1 and 2 are established.

📝 すぐに使える実戦設計

Manus のようなシステムを設計する場合、プロンプトの書き方だけに注目するのではなく、システムアーキテクチャがどのようにコンテキストをスケジューリングするかにより注意を払う必要があります。

以下は2つの古典的なシナリオのシステム設計青写真で、プロンプト設計とコードロジック（疑似コード）を含んでいます。

シナリオ1：フルスタックエンジニア Agent（長期的記憶型）

中心的課題：タスクサイクルが長く、最初の要件やプロジェクト背景を忘れやすい。 解決戦略：System 層（身元）+ Task 層（目標をピン留め）+ Chat 層（スライディングウィンドウ）。

1. システムプロンプト (Layer 1 & 2)

# Layer 1: 身元設定 (System Prompt) - 永遠に不変、KV Cache を活用
あなたはシニアフルスタックエンジニアで、Python と Vue3 に精通しています。
コードスタイル：
- 変数命名は PEP8 に厳密に従う
- 重要なロジックには必ずコメントを含める
- プロジェクト既存のユーティリティ関数を優先して使用する

# Layer 2: タスク固定 (Task Context) - タスク期間中は削除禁止
現在のタスク：決済モジュール (payment_module) のリファクタリング
コア制約：
1. 旧バージョン API インターフェース v1.0 との互換性を必ず維持すること
2. データベースマイグレーションスクリプトは冪等であること
3. 締切：今週金曜日

2. コンテキスト組み立てロジック (疑似コード)

def build_engineer_context(user_input, chat_history, task_info):
    context = []

    # 1. 基礎層：身元設定 (KV Cache でキャッシュを利用)
    # この部分は数百ターンの会話でも変わらず、計算コストはほぼ 0
    context.append(SYSTEM_PROMPT)

    # 2. 柱層：タスク固定 (Pinned)
    # 会話がどれだけ長くなっても、この部分は常に System の後に挿入される
    context.append(f"現在のタスク：{task_info}")

    # 3. 検索層：コードスニペット (RAG)
    # ユーザーの質問に基づいて、コードベースから関連コードを検索
    relevant_code = search_codebase(user_input)
    if relevant_code:
        context.append(f"参考コード：\n{relevant_code}")

    # 4. インタラクション層：会話履歴 (Sliding Window)
    # 直近 10 ターンのみを取得し、コンテキストの膨張を防ぐ
    recent_chat = chat_history[-10:]
    context.extend(recent_chat)

    # 5. 最新の入力
    context.append(user_input)

    return context

シナリオ2：インテリジェントカスタマーサポート Agent（正確回答型）

中心的課題：コストに敏感で、かつ絶対にでたらめを言ってはいけない。 解決戦略：System 層（強い制約）+ RAG 層（動的注入）。

1. システムプロンプト (Layer 1)

# Layer 1: 身元設定 (System Prompt)
あなたはプロのECカスタマーサポート担当者です。
回答原則：
1. 口調は柔らかく、プロフェッショナルで、簡潔に
2. 事実を捏造することは**絶対に禁止**、[参考資料] のみに基づいて回答する
3. 資料に答えがない場合は、直接「申し訳ございません。この問題は有人サポートにお繋ぎする必要があります」と回答する

2. コンテキスト組み立てロジック (疑似コード)

def build_support_context(user_input):
    context = []

    # 1. 基礎層：身元設定
    context.append(SYSTEM_PROMPT)

    # 2. 図書館層：動的検索 (RAG)
    # カスタマーサポートのシナリオでは、RAG こそが主役であり、中間位置に配置
    docs = vector_db.search(user_input, top_k=3)

    context.append("【参考資料 開始】")
    for doc in docs:
        context.append(doc.content)
    context.append("【参考資料 終了】")

    # 3. インタラクション層：極めて短い履歴
    # カスタマーサポートは通常、長期的な記憶を必要とせず、直近 3 ターンで十分
    context.extend(get_recent_chat(limit=3))

    context.append(user_input)

    return context

---

10. 用語対照表

英語用語	日本語対照	説明
Context Window	コンテキストウィンドウ	モデルが一度に処理できるテキストの最大長（入力と出力を含む）。制限を超えた内容は切り捨てられるか忘れられる。
Token	トークン	LLM がテキストを処理する最小単位。通常 1 トークンは約 0.75 英単語または 0.5 漢字に相当。課金とウィンドウ制限はすべてこの単位で行われる。
KV Cache	KV キャッシュ	推論高速化技術。既に計算されたアテンションのキー・バリューペアをキャッシュすることで、重複するプレフィックスに対する再計算を回避し、遅延とコストを大幅に削減する。
RAG	検索拡張生成	質問に回答する前に、まず外部知識ベースから関連情報を検索し、それをコンテキストとしてモデルに提供することで、ハルシネーションを減らし知識の境界を拡張する。
Sliding Window	スライディングウィンドウ	最も基本的なコンテキスト管理戦略。ウィンドウ内のトークン数を一定に保ち、新しい内容が入ると自動的に最も古い内容を削除する。
Lost in Middle	中間での喪失	大規模モデルの限界の一つ。研究によると、モデルは長いコンテキストの先頭と末尾の情報を最もよく記憶し、中間部分の情報を見落としやすい。
System Prompt	システムプロンプト	対話の最初に位置する指示で、モデルの身元、行動規範、回答スタイル、コアタスクを設定するために使用される。
Few-shot	少数例学習	プロンプト内にいくつかの「質問-回答」の例を提供し、モデルがタスクパターンと出力形式を素早く理解できるようにする。
Chain of Thought	思考の連鎖	最終的な答えを出す前に、まず推論ステップを出力するようモデルを導く手法。複雑な論理や数学問題を解く能力を著しく向上させる。
Hallucination	ハルシネーション	モデルが一見もっともらしいが実際には誤っているか存在しない情報を、自信を持って生成する現象。
Embedding	ベクトル化	テキストを高次元の数値ベクトルに変換する技術。意味的に類似したテキストはベクトル空間内で距離が近くなり、セマンティック検索の基礎となる。
Vector DB	ベクトルデータベース	ベクトルデータの保存と検索に特化したデータベース。類似度検索を通じて、クエリに最もマッチする文書断片を素早く見つけることができる。
Temperature	温度	モデルの出力のランダム性を制御するハイパーパラメータ。値が高いほど（例：0.8）出力は多様で創造的に、低いほど（例：0.2）出力は確定的で厳密になる。
TTFT	初回トークン遅延	Time to First Token。ユーザーがリクエストを送信してからモデルが最初のトークンを出力するまでにかかる時間で、インタラクション体験を測る重要な指標。

---

まとめ：コンテキストエンジニアリングの本質

Manus の4度の再構築が教えてくれること：

実践の観点から：多く覚えればいいのではなく、構造的かつ選択的に覚えることこそが重要である。

コストの観点から：

• 無駄の大部分は固定プレフィックスの再計算から生じるため、プレフィックスの安定化とキャッシュメカニズムによって解決する必要がある；
• 重要な情報の誤削除は、「すべてを同等に扱う」スライディングウィンドウに起因することが多く、情報のランク付けとピン留め戦略によって解決する必要がある；
• 超長文ドキュメントや知識ベースに直面した場合、単にコンテキストウィンドウを拡大するだけでは現実的でなく、検索と圧縮のメカニズムを組み合わせなければならない。

目標は：与えられたモデルとコンテキスト上限の下で、すべてのトークンの投入に明確な目的を持たせることである。