← 概念辨析に戻る

Concept Contrast Fable

情報環境を管理する工学と、単一の指令を書く工学

先に結論:プロンプトエンジニアリングは単一メッセージの言い回し、構造、例に注目する。コンテキストエンジニアリングは、モデルが呼び出されるたびに目の前に何が見えるか——文書断片、履歴対話、システム指示、ツール出力——そしてそれらの情報の組織化、並べ替え、切り詰め方に注目する。両者を混同すると、言い回しを繰り返し最適化しながら、情報環境の構造的欠陥を見落とすことになる。

プロンプトエンジニアリングは単一メッセージの言い回し、構造、例に注目する。コンテキストエンジニアリングは、モデルが呼び出されるたびに目の前に何が見えるか——文書断片、履歴対話、システム指示、ツール出力——そしてそれらの情報の組織化、並べ替え、切り詰め方に注目する。両者を混同すると、言い回しを繰り返し最適化しながら、情報環境の構造的欠陥を見落とすことになる。

寓話

粥屋で粥を炊く職人と、かまどを管理する職人

南街の粥屋には二人の師匠がいる。劉師匠は粥を専門に炊く——火加減、米と水の比率、かき混ぜる回数、具を入れるタイミング。一碗の粥が卓に運ばれ、客がうまいと言うと、彼は米は三刻浸し、火は文三分にせよと言う。張師匠は粥を炊かず、竈全体を管理する——どの鍋がどの位置にあり、薪をどれだけ高く積み、水缸が竈からどれだけ近く、蒸籠を何段重ね、朝誰が最初に入って竈門を開けるか。

部外者は張師匠も重要だとは思わない。粥は煮てできるもので、竈は粥を煮ないからだ。しかしある年の冬、薪小屋に水が入り、濡れた薪に火が点かず、劉師匠の火加減表は完全に役に立たなかった——彼は乾いた薪の上の粥しか練習していなかった。張師匠は竈の穴を組み直し、煙道を調整し、二つの鍋の位置を入れ替え、半乾きの薪でも粥を八割の水準まで煮上げた。

もう一度、新しい米に替えた時もあった。劉師匠は米と水の比率と攪拌法を変え、粥は確かに二割おいしくなった。しかしその後の二か月、客はますます減った——粥がおいしくないのではなく、食卓に運ばれる粥がいつも温かったのだ。調べると、李師匠が粥を煮る順序を変え、先に煮上がったものを保温桶に移して後を待たせていた。桶の位置は竈から二尺離れ、器を運ぶのに十二歩余分に歩く必要があった。粥を煮る手順は正しく、粥が食卓に届く状態が間違っていた。

張師匠は皆が心服することを一つ行った。彼は竈の上のあらゆる変化を一枚の総図に描いた。どんな米、どんな薪、どんな桶がどの位置にあり、何を先に何を後にし、誰がいつ竈房に入るか。彼は図に粥の炊き方は描かなかった。劉師匠の粥のレシピは図の一番下に貼られた。三行は書き込み、その後に「その他は総図を見よ」と一行書いた。

二人の職人の違いはある日、完全に明らかになった。ある貴客が、一度しか作れない粥を一杯と指名した——材料は一份だけ。劉職人は火を最も弱くし、目を凝らして一巡一巡を見つめた。張職人は竈全体を空にした——鍋一つ、乾いた薪一束、水一杯、そして見守る一人だけを残して。粥は完成した。劉職人は火加減が生死を決めると言い、張職人は竈が火加減の効果を発揮できるかを決めると言った。

若い見習いは店に入るとまず張師匠に3か月ついて学ぶ——かまどの配置、動線、材料の順序、故障時に何を交換すべきかを見る。4か月目になって初めて劉師匠のところへ粥の炊き方を学びに行く。まず手にしているのがどの鍋かを知り、それから鍋の中身の炊き方を学ぶ。

竈は鍋より重要ではないが、竈が間違っていれば鍋は使えない。店は後に二人の台座を分けた。客が味を変えたいときは劉師匠に処方を変えてもらう。提供速度が遅い、大口注文を受けられない、材料を変えると失敗する——これらは張師匠に竈を見てもらう。粥の処方は一言だが、竈は一そろいの情報環境である。

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

モデルが呼び出されるたびの情報環境——システム指示、履歴対話、検索断片、ツール出力の組織、順序、切り詰め——を管理する。モデルが何を見られるか、そしてそれらの情報が推論にどう影響するかを決める。

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

単一のプロンプトの文言、構造、例を設計・最適化し、その呼び出しに対するモデルの応答品質を高める。関心は情報を「どう言うか」であり、「何を与えるか」ではない。

物語の対応

  • 劉師匠の粥づくり:プロンプトエンジニアリング、単一呼び出しのレシピ(言い回し、構造、例)に注目
  • 張師匠はコンロを管理:コンテキストエンジニアリング、情報環境全体の配置、順序、到達可能性を管理
  • 湿った薪の火加減表が無効に:情報環境が変わるとレシピの効果が大きく落ちることを示す
  • 粥は美味しいがぬるい:情報環境のプロセス欠陥が単一指示の最適化効果を打ち消す
  • 竈の変化全体図:コンテキストエンジニアリングの出力は単一の指示ではなく情報環境の全体的な設計である
  • コンロを空にして一杯の粥を炊くためだけに:極端なシナリオでは情報環境が指令の有効性を決める

LLMアプリケーションの性能ボトルネック特定に落とし込む

モデルの回答品質が悪い場合、まずコンテキストエンジニアリングを確認し、次にプロンプトを調整する。よくある落とし穴はプロンプトの文言を繰り返し変えることだが、本当の問題は検索の再現率不足、履歴対話の早期切り捨て、ツール出力の形式不正、あるいは情報の組織順序の混乱である。有効な自己点検プロセス:まず現在の呼び出しの完全な情報フローを描く——システム指示から最新のユーザー入力までのすべてをタイムラインに並べ、どの情報が欠け、どれが冗長で、どれが順序を誤っているかを見る。図を描いてからプロンプトを変えるのであって、結果を見ながらどの言葉を足すか推測するのではない。コンテキストエンジニアリングとプロンプトエンジニアリングの投入比率は、重厚なアプリケーションでは通常逆にすべきである——七割の精力を情報環境に、三割を文言に。

京ICP备2026014272号