考察ノート：Anthropicのプロンプト講座 /w Claude
Claudeはプロンプトエンジニアリングの推進者であり、モデル性能は今一だけども、（システム）プロンプト能力が優れていると言われている。プロンプトエンジニアリングのコンテンツも公開している。
今回は、"Prompt Engineering 101"を見た。話者は、Hannah Moran, Applied AI at @anthropic-ai Christian Ryan, Applied AI at @anthropic-ai
お題は、交通事故のレポート。事故の様子をあらわす手書きの図から、レポートの定型フォーマットを埋めるという課題。最後の「感想」で少しプロンプトエンジニアリングの必要性について考察してみた。
Prompt Engineeringセッション開始
今回は、複数ターンのやり取りではなくて、プロンプトを工夫して一発で回答をえるという設定。
0 最初のトライアル
最初は、単に、手書きメモとフォームの画像を添付して、直接指示を行う場合。
そして最初のClaude 4 Sonnetの回答は、スキー事故と認識されて、、、
最初のトライアルとしては、悪くないというのが話者の感想だそうだが、ここで今回のセッションのテーマである、「プロンプトエンジニアリング」についての紹介。
最初のプロンプトからスタートして、科学実験のように、プロンプトを工夫、実行、振り返りと修正を繰り返すという話だ。
Prompt Structure
このセッションでは、チャットでくり返しながら洗練化するというよりも、一発プロンプトで解決する方法をとる。それには以下のような構造が必要である。
1、２のセンテンスで、AIの役割(role)や、高レベルでのタスクの説明をつける。
動的に与える、あるいは、RAGのように抽出されたコンテンツ
タスクの詳細なインストラクション
n-shotの例(オプション）
そして、（LLMは長いコンテキストだと忘れやすいから）重要なインストラクションの繰り返し。
という基本構造をもつ。右には、この構造に対応するプロンプトのテンプレートが展開される。
Prompt Structure(詳細版)
そして、このプロンプトの構造を詳細化したものが、次のスライドで、この10の部分に沿って、説明を続ける。
最初は、Task contextとTone context、まずもともと入力って、警察などが事故を分類とかするチェック表があって、
一方、手書きの事故状況のイラストがある。
まず、これらの、画像についての説明を追加する、車の事故のレポート作成であり、チェックボックスと、手書きの図、そしてセッションの目的は、車のどちらかの過失を主張できるか、あるいはより詳細な情報ならどんな情報が必要かがわかるというのを明確化。
そしてClaudeの回答がこちら、こんどはスキー事故じゃなくて、車の事故と認識し、そして、どういう情報がないので、fully confidentでないかを説明してくれる。
3 Background data, documents, images
xmlタグを用いて、各セクションが明確化されているが、これはxmlが単にトークンが少ない、範囲指定が明確ということで採用しえているだけだとの説明があった。
なぜかここで、System promptに（いままではUser Prompt)、詳細なバックグラウンドの説明を入力し始める。
4 Detailed task description and rules
事故の絵について、車両A,Bがあって、どっちがどうでとか。それからフォームの説明。
Fromを埋めるためのルールを明確化。
User プロンプトは前回と同じで、実行。
こんどは、Claudeが、図をちゃんと理解し、またフォームの内容も事前にsystem promptで分かっているのでスムーズに解析が進む。"I can confidently determine fault in this accident"ということで、確信度も高いという回答が返った。
7. Immediate task description or request
"5. example"や"6. history"は飛ばして、"7. Immediate task description or request"のところの説明に入り。
この部分の指示の例としては、ハルシネーションの防止を紹介。
8 Thinking step by step/ take a deep breath
そして、detail list of taskをsystem promptに追加。
ここでの詳細なステップとは、例えば、先にチェックボックスをみて何がよ級されているかを調べて、自分の中でリスト化してから、図を見るというような、XをみてからYをみる、それにはYをみるまえにXの知識が役に立つみたいな、ちょっとマクロなステップ指示となっている。
Claudeの反応はちゃんとチェックボックスを先にみるので、それを埋めることが図を見ることの目的になり、結果としてチェックボックスは埋まる。
しして、スケッチの分析、
そして、これらの情報から、過失の決定ということで、車両Ｂに過失があるという推定を導き出す。
9 output formatting
そして、最後に"output"の指示、
出力に関するガイドラインそして、<final_verdict>タグで推定の結果を明示的に示すことを支持。
そして、ちゃんと所望の出力を得る。
10 Prefilled response
出力の指示は、claudeの責任を、回答を事前に埋めておいて、明らかにして、指示するみたいな説明だった。
What about extended thinking?
いや、プロンプトエンジニアリングで頑張るのか、いやそれとも、extended thinkingを使えば済むじゃん？という話には、まずextended thinkingの中身をトレースすればプロンプトエンジニアリングの役に立つという話と、毎回extended thinkingやるってのは、このようなノウハウとか手順を毎回、「車輪の再発明」しているようなものだし、それに確率的な回答になってしまうという話。
感想
さすがAnthropicのプロンプトエンジニアリングの説明。しっくりくるところがある、解像度の話とも通じていて、ちゃんとバックグランドの情報とか図の説明とか、LLMの認知負荷を下げつつ、フォームの説明や埋め方のルールを教える、すなわち自分でも明確にしている。また、手順の提示も単なるstepの指示ではなく、Ｘをみて、理解した上でＹを実行といった、解き方の方策を示唆する提示、つまりClaudeの能力（ちゃんと理解し、ときに忖度してくれる）をちゃんと生かすような、指示もあって、さすがに、手練れだと感じた。
いや、これが普通の人にできるか？いや、半分メンタルモデルがLLM化している（と職場でもいわれる）私でも何とか、プロンプトの裏にある意図をなんとか読み取ったぐらいのので、難しいかも。モデルの性能が上がれば、プロンプトって不要という意見はあるが、結局、課題の解像度を上げてゆくというのは、人間側にも有効なわけで、これなしに、ガラガラポンで答えが出てくると思ったら、それは間違えであり、正しい期待値の設定の仕方ではない。
正しい期待値の設定の仕方とは、LLMはこれくらいのことはできるだろうな、例えば足らない情報の補完とか、推論とか、を思いはせながら、結果を楽しみに見る。そうすると、その期待する能力の発揮を自分で確認できる。そういうのが正しい期待値で、これを人間側も身につけないといけない。
