← 概念辨析に戻る

Concept Contrast Fable

プロンプトとプロンプトエンジニアリング、一つ一つのレンガは材料で、全体の設計図はエンジニアリング

先に結論:プロンプトとは、あなたがモデルに送る単回の入力テキスト——指示、質問、文脈の一部です。プロンプトエンジニアリングとは、テンプレート設計、品質管理、バージョン管理、評価プロセス、継続的改善を含む体系的な設計手法です。単一のpromptをprompt engineeringと呼ぶのは、レンガ一つを建築工学と呼ぶようなものです。

プロンプトとは、あなたがモデルに送る単回の入力テキスト——指示、質問、文脈の一部です。プロンプトエンジニアリングとは、テンプレート設計、品質管理、バージョン管理、評価プロセス、継続的改善を含む体系的な設計手法です。単一のpromptをprompt engineeringと呼ぶのは、レンガ一つを建築工学と呼ぶようなものです。

寓話

一通の密書と密書司、前者は紙の上の文字、後者は伝信の仕組み全体

辺境の軍営は密書で兵を動かす。将軍は一通の手紙を書き、敵情、目的、禁忌を記す。斥候は手紙に従って行動する。手紙が明確なら一度の行動は順調に進み、曖昧なら斥候は間違った山道を行くかもしれない。

ある時、将軍が「日没後に北斜面を偵察せよ」を「暮れの太鼓の後に北斜面を偵察せよ」に変え、その夜の行動はうまくいった。副将は、手紙を美しく書けば軍情は安定すると思った。副将は美しい言い回しを集め始め、「必ず」「速やかに」「慎重に」を便箋いっぱいに書いた。斥候は読んで血が沸いたが、分かれ道でまず命を守るのか、まず偵察するのかはわからなかった。

ほどなく連鎖任務に直面した。道の偵察、報告、哨戒の交代、誤報処理、緊急撤退。一通の手紙がどれほど良くても、状況ごとに斥候の理解が異なるのは防げない。地図を忘れる者もいれば、捕虜に会った時尋問すべきか分からない者もいた。将軍の最初の補救は、各任務をより長く書くことだった。長い手紙は新たな問題を生んだ。斥候は雨の夜に読み切れず、重要な制限が中ほどに挟まり、見落としやすくなった。

老参軍はそこで密信司を設立した。よくある任務には決まった形式があり、危険な言葉は避け、返信には必ず証拠を添え、失敗サンプルは台帳に記録して振り返る。新しい手紙を出す前には、過去の戦例で試し読みし、誤解を招かないか確認する。密信司も当初はテンプレートだけを扱っていた。後に古いテンプレートが新しい地形に遭遇し、斥候を誤らせかけたため、テストと振り返りも職務に組み込んだ。

密信司はさらに、手紙を出した後は結果を回収するよう定めた。斥候がどこで誤解し、どの文が役に立ち、どの文が余分だったかをすべて帳簿に記録した。次の手紙はひらめきから始まるのではなく、前回の誤りから始まる。

副将は後に依然として自ら一通の密書を書きましたが、それが単なる材料であることを知っていました。本当に軍営を安定させるのは、密信司の背後にある形式、テスト、振り返り、更新です。この仕組みがなければ、良い文句は時々場を救うだけです。

後に軍営は区別できるようになった:一通の密書は、ある作戦の指令である。密書司の整套の仕組みこそが、多くの密書を持続的に信頼できるものにするエンジニアリングである。一文を直せば一晩は救えるが、書くこと、試すこと、振り返り、反復を管理してこそ、一季の戦いを守れる。

プロンプト

ユーザーがモデルに送る単一の入力テキストで、指示、質問、文脈、例を含む。これは具体的な入力インスタンスであり、プロンプトエンジニアリング体系で生み出される基本単位である。

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

プロンプトを体系的に設計、テスト、反復、管理する方法論。テンプレート設計、バージョン管理、品質評価、境界テスト、継続的最適化プロセスを網羅し、単一のテキストではなく一連のエンジニアリング実践である。

物語の対応

  • 一通の軍情信:単一の prompt——具体的な入力テキストの実例
  • 傅書吏の職責:prompt engineering——フォーマット設計、研修、品質検査、イテレーション
  • 若い書吏が一行の注記を加えた:一つの prompt 変更——テキスト修正は数秒で済む
  • 三か月で導入:prompt engineering——制度調整、研修、プロセス適合
  • ラベルが乱用される(すべてを緊急と表示):検証制約の欠如——engineeringには品質ゲートが必要
  • 第二回目の反復で検証ルールを追加:prompt engineering の完全なサイクル——設計、テスト、分析、反復
  • 傅書吏のまとめ:信仰の変更と制度の変更は、それぞれ別の作業量と別の責任体制である

チームの役割分担と納品期待に落とし込む

チームでは prompt 最適化と prompt engineering を一つの役割として扱わないこと。prompt を書く人は単一入力の構成とデバッグを担当し、一度きりの仕事かもしれない。prompt engineering を行う人はテンプレート体系、評価基準、バージョン管理、反復プロセスを担当する——この仕事は製品のライフサイクル全体にわたって続く。prompt 設計を外注するとテキストの束しか得られないかもしれないが、prompt engineering は製品、データ、評価チームと協働して機能する必要がある。立ち上げ時に prompt 設計の工数だけを報告してシステムの安定性を約束すれば、3か月後には継続的な反復メカニズムの欠如により必ず効果が落ちる——新しい場面が入るたびにゼロから書かなければならない。

京ICP备2026014272号