← 概念辨析に戻る

Concept Contrast Fable

プロンプトエンジニアリングとプロンプト管理

先に結論:プロンプトエンジニアリングが担うのは「良いプロンプトをどう書くか」であり、プロンプト管理が担うのは「100個のプロンプトをどう乱れなく運用するか」だ。前者は単発の効果を気にし、後者はバージョン、テスト、デプロイ、ロールバックを気にする。エンジニアはプロンプトを美しく書けるかもしれないが、チームの10人がそれぞれ勝手に変更し、リリース前に誰も回帰テストを走らせず、問題が起きてもどのバージョンを変えたか誰も知らないなら、美しいプロンプトも本番障害になる。

プロンプトエンジニアリングが担うのは「良いプロンプトをどう書くか」であり、プロンプト管理が担うのは「100個のプロンプトをどう乱れなく運用するか」だ。前者は単発の効果を気にし、後者はバージョン、テスト、デプロイ、ロールバックを気にする。エンジニアはプロンプトを美しく書けるかもしれないが、チームの10人がそれぞれ勝手に変更し、リリース前に誰も回帰テストを走らせず、問題が起きてもどのバージョンを変えたか誰も知らないなら、美しいプロンプトも本番障害になる。

寓話

料理人と厨房のルール

老趙のレストランには彼自身のコンロが一つしかなく、毎日新しい料理を研究していた。紅焼肉では二十通りの糖色の割合を試し、回鍋肉では八通りの豆板醤の配合を調整し、どの料理の味付けのレシピも頭の中に記録していた。客は食べて褒め、老趙の看板はますます評判になった。

レストランが五店舗に拡大し、老趙は五人の竈台師匠を雇い、自分のレシピを小冊子に印刷して配った。最初の二週間は平穏だったが、三週目から問題が起きた。一号店の宮保鶏丁は甘め、二号店の麻婆豆腐は麻が効かず、三号店の魚香肉絲は糖酢味になった。

老趙は各店の厨房を一回りして、各料理人が小さなノートを持ち、そこに自分のメモを書いているのを見つけた。ある人は「砂糖を少なめにした方が売れると思う」と言い、ある人は「常連が辛すぎると言ったので調整した」と言った。誰もがレシピを変え、誰もが変えた後に他の人に伝えていなかった。老趙は自分がいつ料理を確認しに行っても、何版目を食べているのかわからなかった。

老趙は五店の料理長を呼び戻して会議を開き、三つのルールを決めた。第一に、レシピは統一して保管し、変更するには変更申請を提出し、どのパラメータをなぜ変えるのかを明記する。第二に、レシピを一版変えるたびに、同じ食材で三道の料理を作り、三店の品質管理担当がそれぞれ一口試し、採点を通過して初めて有効とする。第三に、すべてのレシピは過去の版を残し、客が先月の魚香肉絲の方がおいしかったと言えば、厨房は先月の版のレシピをすぐに取り出せるようにする。

規則を導入した当初、職人たちはプロセスが遅すぎると不満を言った。二か月後、ある出来事が起きた。三号店が三日連続で客から宮保鶏丁の味が違うと苦情を受けたのだ。老趙がバージョン帳を開くと、一週間前に誰かがピーナッツをカシューナッツに替え、レビュープロセスを通していなかった。老趙は直ちに前のバージョンへロールバックし、問題発見から復旧までわずか五分だった。

これ以来、老趙は二つの職種を理解した。コンロ前の料理人の仕事は、一皿の料理をどうおいしく作るかを研究すること——砂糖何グラム、火加減何秒、材料を入れる順序。料理長の仕事は、すべてのコンロの小帳簿を管理すること——誰が変えたか、なぜ変えたか、変えた後にテストしたか、壊したら一秒で戻せるか。コンロ前の料理人は腕に頼り、料理長はプロセスに頼る。

老趙は後に同業者に冗談めかして言った。一人で店を開くなら、レシピは頭の中にあればいい。五軒の店を同時に開くなら、レシピは金庫に入れなければならず、金庫には暗号が必要で、暗号は誰かが管理しなければならない。店が大きくなるほど、腕は料理そのものではなく、誰がレシピを変えられるか、どう変えるか、変えた後に誰が責任を負うかにある。

ある飲食コンサルタントが調査後にこう書いた:料理の品質のボトルネックは決してコンロ前の料理人の腕ではなく、厨房のルールが拡張速度に追いつけるかどうかだ。ルールが追いつく前に、新店舗の一つひとつが黙ってあなたの看板料理を作り変えており、気づいたときには見る影もなく変わっている。

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

モデル出力の品質を高めるために単一のプロンプトを設計・最適化する技術的実践。プロンプトの構造、言い回し、例の配置、思考連鎖の設計に注目し、単一インタラクションでの最良の効果を目指す。

プロンプト管理

プロンプトのバージョン管理、テスト、デプロイ、ロールバック、協働管理を行うシステムエンジニアリングの実践。変更の追跡、品質ゲート、チーム協働に注目し、プロンプトの品質と保守性を体系的に保証することを目標とする。

物語の対応

  • 老趙が一人で処方を研究する:プロンプトエンジニアリング——単一プロンプトの研磨とチューニング。
  • 5人の職人がそれぞれ黙って処方を変える:プロンプト管理が欠けると、バージョンが混乱し品質が変動する。
  • 三つのルール——申請提出、レビューとテスト、バージョン保持:プロンプト管理の中核プロセス。
  • ピーナッツがカシューナッツに替わってから五分でロールバック:バージョン管理と迅速なロールバックの実践的価値。
  • コンロ前の料理人と料理長の分業:プロンプトエンジニアリングは単体の品質に注目し、プロンプト管理はシステムの信頼性に注目する。

プロジェクトに落とし込む

プロンプトエンジニアリングが60点に達した後は、単一のプロンプトを最適化し続けるよりもプロンプト管理の価値が上回り始める。少なくとも三つのことを行う:プロンプトをバージョン管理に入れる、変更はレビューを通す、リリース前に回帰テストを実行する。規模が大きくなるほど人の記憶に頼ってはいけない——プロンプトが10個ならチャット履歴でも何とかなるが、100個ならツールに頼るしかない。モデル更新のたびにどのプロンプトを再テストすべきかわからないなら、管理がまだ不十分だ。

京ICP备2026014272号