8月4日、Towards Data Scienceが「Prompt, Context, Loop: The Three Engineering Layers Every RAG System Is Built On」と題した記事を公開した。RAGシステムを構成する3つのエンジニアリング層（プロンプト・コンテキスト・ループ）の役割と、それぞれがいつ・なぜボトルネックになるかという構造的な分析を詳しく紹介している。
RAGの議論が噛み合わない理由
RAGシステムについての技術的な議論がしばしば混乱するのは、立っている「層」が違うからだ——この記事はそう主張する。
著者が提示するのは、プロンプトエンジニアリング・コンテキストエンジニアリング・ループエンジニアリングという3層の枠組みだ。この3つを区別すれば、「どのアプローチが正しいか」という水掛け論の多くは解消される。
3つの層が担う責任範囲
Layer 1：プロンプトエンジニアリング
「この1回のLLM呼び出しで、モデルに何を読ませるか」を決める層だ。システムメッセージ、ユーザーメッセージ、出力スキーマ、ツール定義——{"role": "system"}から応答までの間にある全てがここに属する。
GPT-3.5とChatGPTが登場した2022〜2023年に広まった概念で、現在では最も成熟した層とされる。最新モデルは以前よりはるかに少ないプロンプト工夫で流暢な回答を返すため、この層がレートリミッターになることは減った。
Layer 2：コンテキストエンジニアリング
「モデルのコンテキストウィンドウに何を入れ、何を出すか」を制御する層だ。LangChainが整理した4つの戦略が実務の標準になっている：
- Write：ターンをまたいで変わらないキャッシュ済みプレフィックス（システムプロンプト、ツール定義）
- Select：より大きなプールから「今」関連するものを選ぶ検索・メモリ想起
- Compress：要約や切り詰めによってオーバーフローを防ぐ圧縮
- Isolate：サブエージェントの呼び出しを独立したウィンドウで行い、中間結果をメインコンテキストに入れない分離
Andrej KarpathyやShopifyのTobi Lütkeが2025年に公言し始め、Anthropicが「Effective context engineering for AI agents」を公開したことで用語として定着した。
コンテキストエンジニアリングが失敗したときの特徴は静かに間違えることだ。モデルは流暢に回答するが、取得したコンテキストが誤っていたために内容が間違っている——プロンプトの失敗のように「明らかにおかしい」とはならない。
Layer 3：ループエンジニアリング
「次の呼び出しをいつ発火させ、ループをどこで止め、失敗からどう回復し、結果をどう検証するか」を管理する層だ。4つの制御面がある：
- トリガー：次の呼び出しを発火させる条件
- 終了条件：「完了まで」「予算まで」「空になるまで」のどれか
- リカバリー：リトライ、大きなモデルへのフォールバック、人間へのエスカレーション、スキップ
- 検証：別エージェントがその答えを論駁しようと試みる敵対的検証
2026年5月、Boris Chernyがループ駆動の開発スタイルについて言及した趣旨の発言と、Anthropicのダイナミックワークフロー公開によって、この層の名前が定着した。
ループエンジニアリングの失敗は高コストだ。ループが同じペイロードで何度もスピンし、トークン予算を燃やした末にタイムアウトする。
「進化の物語」は半分だけ正しい
記事が最も力を入れているのが、この指摘だ。
「プロンプト→コンテキスト→ループ」という順序は、後付けの物語だという。各層のパターン自体は、その名前が生まれるずっと前から存在していた：
- ReAct（推論＋行動ループ）：2022年10月（Princeton・Google）——「ループエンジニアリング」という言葉より3年以上前
- AutoGPTの自律ループ：2023年3月
- RAGの原論文（Lewis et al.）：2020年——「プロンプトエンジニアリング」という言葉より2年前
正確な読み方は、「3つの層が順番に生まれた」ではなく、「どの層がそのときの本番環境でボトルネックだったかが変わった」というものだ。
ボトルネックが上に移動する3つの力
なぜボトルネックはスタックを上に移動するのか。記事は3つの力を挙げる：
- モデルが下の層を自動解決する：GPT-4はGPT-3が無視した指示に従った。Claude 3.5は以前のモデルが散文で包んでいたJSONを直接返した。次世代モデルは、今日の「コンテキストエンジニアリング」の多くを不要にするだろう
- コンテキストウィンドウが拡大する：2023年初頭は4kトークン、Claude 2で100k、Gemini 1.5で100万トークン。ただしコンテキストロット（コンテキストウィンドウの中央付近に置かれた情報をモデルが見落としやすくなる現象。"Lost in the Middle"とも呼ばれる）は名目上の上限より手前で始まる。問題は「どうやって全部入れるか」から「何を除外するか」に変わった
- 本番ユースケースが長期化する：2022年のユースケースはシングルショットのQAだった。2026年のユースケースは40ターン・6時間・サブエージェントのファンアウトを伴うエージェントだ。ループを設計する必要がないシステムには、ループエンジニアリングは不要だった
ループエンジニアリングのパターンと1つのルール
元記事では、Anthropicのダイナミックワークフローが定義したプリミティブと実践者の文献を組み合わせた複数のパターンが紹介されている。具体的な個数については原文を参照いただきたいが、共通しているのはこれらが順番に使うものではなく語彙だという点だ。実際のループは複数を組み合わせて使う。例えば、「ファンアウト」で3つのサブエージェントに質問を投げ、「敵対的検証」でその答えを別エージェントが論駁しようとし、「完了まで繰り返す」で完全性を担保するといった合成が実エンジニアリングになる。
カタログを束ねるルールはシンプルだ：リトライのたびに何かを変えなければならない。ペイロード（検索スコープを広げる）、モデル（小さいモデルが失敗したら大きいモデルに渡す）、戦略（キーワード検索が外れたら次はdense retrieval）のいずれかが変わっていないリトライは、トークンを燃やしているだけだ。
次のボトルネックはどこか
※以下は元記事の記述をもとにした紹介であり、将来予測の部分は著者の見立てによるものだ。
3層の枠組みは自身の陳腐化を予測している。下の層が安定するにつれてボトルネックは上に移動するなら、ループエンジニアリングの「上」が次に名付けられる層になる。候補はすでに非公式な名前を持っているが、コンセンサスはまだない——スキルエンジニアリング（Anthropicのエージェントスキル）、メモリエンジニアリング（セッションをまたぐ状態管理）、ゴールエンジニアリング（長期目標の維持）といった言葉が登場し始めている。
なお、シリーズのコンパニオンノートブックはdoc-intel/notebooks-vol1でGitHubに公開されており、実際のPDFを使って3つの層が動く様子を確認できる。
詳細はPrompt, Context, Loop: The Three Engineering Layers Every RAG System Is Built Onを参照していただきたい。
