この動画では、プロンプトが失敗する主な原因である意図の不明確さを解決する革新的手法「契約ファーストプロンプティング」を紹介している。従来の曖昧な質問に頼る手法とは異なり、エンジニアリングチームが使うサービス契約のように、LLMとの間で明確な作業合意を事前に構築する技術的アプローチである。この手法により、ゴールまでのギャップを体系的に特定し、95％の確信度に達するまで段階的に詳細を詰めることで、トークン効率的かつ高精度な結果を実現する。
プロンプト失敗の根本原因と意図伝達の困難さ
ほとんどのプロンプトが失敗するんは、意図がはっきりと伝わらんからや。人間の言葉っちゅうのは、意図を表現するんにめちゃくちゃ荒っぽいんや。これは特定の言語の問題やないし、人間の言葉やからっちゅう問題でもない。
問題なんは、俺ら個人個人が持ってる専門知識がめちゃくちゃ多いっちゅうことや。俺らは情熱も持ってるし、エネルギーも持ってる、そして特定の分野で働きたい内容に対する経験もぎょうさん持ってるんや。
そんで俺らはそれを言葉でLLMに伝えようとして「これ一緒にやってくれや」って言うんやけど、プロンプティングでそれなりに経験のある俺でも、時々イライラすることがあるんや。俺でも、LLMが理解できるような形で意図を伝えるんに苦労することがあるんや。
契約ファーストプロンプティングという新手法
今日、俺が他では見たことのない手法を提案したいと思うんや。俺が成功してきた手法なんやけど、それを「契約ファーストプロンプティング」って呼んでるんや。
契約って聞いて、何か署名するもんかって思うかもしれんけど、そういう意味やない。俺が言うてるんは、エンジニアリングチームが使うような契約のことや。彼らがお互いの間で契約や合意を書いて、マイクロサービス同士がどう連携するか、サービスレベルアグリーメントはどうなるか、レイテンシはどうなるか、そういう技術仕様を全部決めるんや。
同じように、俺らもLLMと一緒に意味のある仕事をする前に、非常にタイトで技術的な共通理解を持つ点まで到達せなあかんのや。これまでそれをやるんがめちゃくちゃ難しかったんや。
よくある答えは「LLMに明確化のための質問をしてもらえばええ」っちゅうやつやけど、俺はそれに満足してないんや。確かにみんなそれで成功したって報告してるし、俺も多少の成功はあったんやけど、強調したいんは、これは実際にこの問題を解決するんには非常に散発的で非プロ的なアプローチやっちゅうことや。
あんたはLLMに、曖昧さの海で泳いでるLLMに、役に立つかもしれんと思う質問を自由に選ばせてるんや。その質問セットに対して、正しく理解できたかどうか、あんたの意図を理解したかどうかを知るためのパラメータや構造を本当には与えてないんや。
やから明確化のための質問は役立つかもしれんけど、十分やないんや。
契約ファーストプロンプティングの具体的な構造
せやったらもっとええ方法は何や？契約ファーストプロンプティングってどんなもんや？そう聞いてくれて嬉しいわ。実際に俺が書いた、契約ファーストプロンプティングを説明するプロンプトを見てもらおうと思うんや。楽しいで。
ここの重要な要素を一つずつ指摘していきたいと思うんや。俺はプロンプティングに魔法の言葉があるなんて主張する気はないんや。全部に理由があるんやけど、明らかにあんたも自分に役立つ方法でこれらを構築できるんや。やから、これが契約ファーストプロンプトを構築する唯一の方法やないんや。
俺があんたに持って帰ってもらいたいんは、魔法の言葉やなくて意図なんや。
まず最初に、LLMに使命を与えるんはいつでもええことや。「あんたのゴールは、俺の大まかなアイデアを非常に明確な作業指示書に変えることや」。ここで俺は、あんたが重要な仕事を持ってることを前提にしてるんや。例えば教育資料を作ったり、PowerPointプレゼンテーションを作ったり、PowerPointプレゼンテーションのスクリプトを作ったりするかもしれん。
ChatGPTがPowerPointプレゼンテーションで素晴らしい仕事をするとは期待してないけどな。もしくはソフトウェアを構築するかもしれん。何でもええんやけど、意味のある仕事で、俺ら両方がそれが正しいって合意した後にのみ作業を提供するっちゅうのが、この契約の重要な部分なんや。
ギャップ特定と段階的な詳細化プロセス
せやったらこの中に何が入るんや？まず第一に、ゴールまでのギャップは何か、意図までのギャップは何かを理解させなあかん。
あんたがこれを最初にチャットに書いて「始めて」って言うたら、まず「準備できた。何が必要や？」って言うてくる。そしたらあんたはただ取り留めのない一文か二文を書くだけでええんや。仕事を定義するとき、俺らは一文か二文以上のことを知らんことがよくあるからな。それが最初により良いプロンプティングをするのを止めてる理由なんや。
やから、あんたが持ってるものをそのまま書けばええんや。めちゃくちゃ散らかってても構わん。そしたらここの0番に入って、まだ必要な事実や制約を静かにスキャンしてリストアップするんや。そして掘り下げを始めるんや。正しい結果を提供できるって95％の確信を得るまで、一度に一つの質問をするんや。
これは掘り下げる場所の例を示してるんや。目的、対象者、事実、成功基準、長さ、技術スタック（コードの場合）、エッジケース、リスク、許容度なんかや。でも経験から言うと、これは網羅的なリストやない。他の場所にも行くんや。
ここで本当に役立つ例があるんやけど、俺は非常に曖昧な人間のプロンプトで本当にそれを試してみたかったんや。せやから1660年以降のバルカン半島の歴史の500語要約を頼んだんや。なんでかって？それはかなり曖昧やからや。1660年以降のバルカン半島ではぎょうさんのことが起こってるからな。
そんで何を理解したと思う？良い500語要約を書くための重要なレバレッジポイントの一つが、その時代全体を通じた政治的実体とその命名規則の進化をどう扱うかやったっちゅうことを理解したんや。
俺の作業課題にとって意味のある形で歴史の弧をカバーできるように、俺がどんな範囲を望んでるかを理解する必要があったんや。せやから制約として名前は挙げられてなかったんやけど、この500語の説明に対する政治的実体の議論や説明に関する俺の意図を分析してもらうために、3、4回の質問ラウンドがあったんや。
ちなみに、なんで俺が500語って入れたか？それに挑戦させたかったからや。短い方が長いより難しいからな。そして最終的に、1660年以降のバルカン半島史の本当にしっかりした要約を500語で得ることができたんや。そのすべての明確化が本当に役立ったんや。
エコーチェックと作業確認システム
エコーチェックは、それが近づいてると思うときや。せやから簡潔な文で返答してくる。成果物を述べる。含める必要があると分かってることを述べる。そしてあんたが関われる作業の非常に読みやすい要約にするために設計されたハードな制約を述べるんや。
そしてこのプロンプトには効果的にミニプログラムが入ってるんや。「はい」って言ってロックできる。編集できる。何が起こってるかのブループリントやアウトラインを求めることができる。もしくはリスクを指摘して、現状のプロンプトについて何がリスキーかをLLMに定義してもらうことができる。そしてここで何をするかの指示を与えるんや。
「はいでロック」の処理方法は非常に直感的やし、編集も直感的やけど、LLMが理解できるようにブループリントとリスクを定義してるんや。
構築と自己テストをするとき、コードの処理方法について特別な指示を与えるんや。せやから責任を持って、コードをレビューすることを思い出させるんや。これはドキュメントなんかにも拡張できたんやけど、コードはよくエラーが起こりやすいから、それだけの価値があると思ったんや。そしてリセットするオプションも与えてるんや。
これは本当に短いんや。どうやってこれが機能するんやって思うかもしれん。実は、契約ファーストの意図に到達するために必ずしも長いプロンプトは必要ないっちゅうことが分かったんや。ステップの順序について明確性が必要なだけなんや。
シンプルな3ステップのプロセス
俺らがやってることは全部、一つ目：ゴールまでのギャップをリストアップする（これは俺がプロンプトでほとんど見たことがない）。二つ目：95％の確信度に到達するまでそのギャップを掘り下げる。そして三つ目：そこから俺が選択してコントロールできる前進の道を提供する。俺らが一緒に契約を書こうとしてるからや。
これが契約ファーストの意図を書く唯一の方法か？絶対にそうやない。唯一の方法やない。意図の明確性に到達することについて話すのに本当に役立つ方法か？せやな。
そして俺は歴史だけでこれをやったんやない。ソフトウェアでもやったんや。実際に俺はソフトウェアプロジェクトに取り組んでるんや。複数のチャンネルにわたるライブストリームのコメントを一元化することに興味があるからや。せやからそのソフトウェアアイデアで遊んでるんや。
そしてそれはまた曖昧なんや。何個のチャンネル？何を含める？何がカウントされる？MVPって何？ユーザー数は？これらすべてのことを最初に重いPRDプロンプトに入れようとすることもできるんやけど、俺はまだそこまで到達してないんや。本当にそれについて話したいんや。そして構造化された方法で話したいんや。
これはそのために本当に役立ったんや。実際に「これのためのPRDを作ってほしいんやけど、まだ意図がないんや。せやから俺と一緒に掘り下げて、明確で清潔な意図でPRDを作成するための合意された作業契約に到達するまでやってくれ」って言えたんや。そしてそれをやってくれたんや。
人間らしさを前提とした効率的なアプローチ
それを見て、当たり前やって感じるなら、おめでとう。それは世界に存在すべきやから、試してみるべきや。でも俺はかなり掘り下げて調べたんやけど、あんたが思うほど明らかやないで。これは俺が他の場所で見つけることができない技術なんや。そして俺はちょっと驚いてるんや。これは人間が人間やって前提に立った時の、意図の明確性に到達するための非常にトークン効率的な方法やと思うからや。
そして俺は人間が人間やって前提に立つプロンプティング技術にますます興味を持ってるんや。俺らは完璧やない。いつもフルプロンプトを書き切るわけやない。いつも完全で鮮明で完璧な意図を持ってるわけやない。実際、ほとんどの場合、そんなものは何一つ持ってないんや。
俺らが持ってるんは、膨大な文脈と経験に裏打ちされた曖昧な人間のアイデアや。そしてそれを俺らの頭から釣り上げて明確性に到達するための助けが必要なんや。
それが契約ファーストのプロンプティングアプローチが求めてることなんや。LLMがこの作業に対するあんたの意図を深く、完全に、完璧に理解できる点に、あんたがただそれと会話して、質問させて、あんたのために掘り出させることができるような形で、どうやって到達できるかっちゅうことや。
幅広い適用範囲と共通の失敗パターン
これはプロダクトマネージャーだけのもんやって思うかもしれん。PMは要件を書くときに意図の明確性を得る必要があるからな。もしくはこれだけ、あれだけのためのもんやって思うかもしれん。これは意図的に幅広い範囲のプロンプトセットなんや。意図を最初に定義する必要がある実質的にあらゆる真剣な仕事に対して機能するもんとして設計されてるんや。
そして俺は意図的にそういう風に書いたんや。俺らのAIの使用例は本当に幅広いと思うからや。俺らがAIをどう使ってるかについてのあらゆる調査、あらゆるホワイトペーパーを見ても、俺らはぎょうさんの異なる種類の真剣な仕事をしてるんや。でも共通の失敗パターンは意図の明確性のままなんや。これがそれを修正するために設計されたもんなんや。
これが楽しかったら、気に入ったら、素晴らしい。契約ファーストプロンプトを実行してみてくれ。どう機能したか教えてくれ。もしくはもうこれに対する言葉を持ってるなら、もしくはもう使ってるなら、それについて聞かせてもらいたいんや。
俺がこういうプロンプトビデオをやるとき、よく人が「ああ、俺はこれに対して違う言葉を持ってるけど、家で試してたんや。それが一つのもんやって知らんかった」って言うんや。俺らがこれについて話す理由の一部は、共通の専門用語が何かを一緒に学ぶことやからな。
そういうわけや。契約ファーストプロンプティングや。
コメント