※本記事は、Anthropic社のプロンプトエンジニアリング専門家によるディスカッションを基に作成されています。登壇者は、Amanda Askell氏（Alignment Finetuning）、Alex Albert氏（Developer Relations）、David Hershey氏（Applied AI）、Zack Witten氏（Prompt Engineering）の4名です。 本記事は、プロンプトエンジニアリングの進化、実践的なヒント、AIの能力向上に伴うプロンプティングの変化に関する議論を要約したものです。ビデオの詳細情報は https://www.youtube.com/watch?v=T9aRN5JkmL8 でご覧いただけます。 なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。また、Anthropic社の公式サイト（https://www.anthropic.com/ ）やプロンプトエンジニアリングに関するドキュメント（https://docs.anthropic.com/ ）もご参照ください。

1. プロンプトエンジニアリングの定義と本質

1.1. プロンプトエンジニアリングとは何か

Zack: プロンプトエンジニアリングの本質は、モデルがより良い結果を出せるように協働することです。基本的には、モデルと対話することは人間と対話することに似ています。モデルの「心理」を理解し、それを活用することが重要です。特にAmandaは、この分野の世界的な専門家として、モデルの心理的側面への深い理解を持っています。

David: そうですね。私は主に顧客とのやり取りを通じて実感していますが、プロンプトエンジニアリングは単なるプログラミングよりも複雑です。例えば、チャットボットを構築する際、ユーザーからの入力データをどう扱うか、どのようなデータにアクセスできるのか、RAGをどう使うのかなど、システム全体を考える必要があります。これは単なるソフトウェアエンジニアやPMとは異なる専門的なスキルセットが必要な領域です。

Amanda: 私の経験から言えば、プロンプトエンジニアリングの重要な側面は、モデルの限界を理解しながら、その能力を最大限に引き出すことです。例えば、15分の間に数百のプロンプトを試すこともあります。これは単なる文章作成ではなく、モデルの反応を観察し、理解し、改善していく反復的なプロセスです。

Alex: プロンプトエンジニアリングの面白い点は、それがテキストベースでありながら、コードのような振る舞いを示すことです。人間の言語で書かれた指示が、実際にはプログラミング的な機能を果たすという特異な性質を持っています。

David: その通りです。私が顧客と仕事をする中で特に重要だと感じるのは、プロンプトエンジニアリングが単なる指示出しではなく、システム全体の中での役割を持つということです。データの出所、利用可能なリソース、レイテンシーの考慮など、様々なシステム的な思考が必要になります。これが、単なるプロンプト作成を超えて、「エンジニアリング」と呼ばれる理由の一つだと考えています。

Zack: そして重要なのは、プロンプトエンジニアリングが試行錯誤のプロセスであることです。人間との会話と違い、モデルとの対話では完全にクリーンな状態から始められるという特徴があります。これにより、様々な実験が可能になり、より良い結果を段階的に追求できます。

1.2. なぜ「エンジニアリング」と呼ぶのかについて

Zack: エンジニアリングという言葉が使われる理由の一つは、試行錯誤のプロセスにあります。モデルとの対話で特に優れている点は、「リスタートボタン」のような機能があることです。つまり、完全にゼロの状態から新しく始められる。これにより、異なる試みを互いの干渉なく独立して実験できます。このような実験能力があるからこそ、エンジニアリングという要素が入ってくるのです。

David: 私が顧客と仕事をする中で感じるのは、プロンプトエンジニアリングの「エンジニアリング」的側面は、システム全体への統合にも現れています。単にプロンプトを書いて、モデルに渡して終わり、というような単純なものではありません。実際にはそれよりもはるかに複雑です。データの出所、使用可能なデータ、レイテンシーのトレードオフ、そしてどれだけのデータを提供するかなど、多くのシステム思考が必要になります。

Amanda: そうですね。私の視点からすると、エンジニアリングの側面は特に実験設計において重要です。例えば、プロンプトの品質が実験の成否を分けることがあります。モデルのパフォーマンスが1%か0.1%かの違いが、実験の成功と失敗を分けることもあります。実験のコーディングに時間をかけながら、プロンプトの部分をおろそかにするのは理にかなっていません。

Alex: 実際のところ、プロンプトはある種の「自然言語コード」として機能していると考えることもできます。バージョン管理や実験管理など、通常のソフトウェア開発と同様の規律が必要になってきます。ただし、プロンプトがコードと異なる点は、それが人間の言語で書かれた明確なエッセイのような形を取ることです。

David: その通りです。私の経験では、エンタープライズでの展開において、プロンプトの微調整が「出荷できない」状態から「動作する」状態への転換点になることがよくあります。ただし、これは諸刃の剣でもあります。常により良いプロンプトが地平線上にあるという幻想に陥りやすく、際限のない最適化に走る危険性もあります。

Amanda: プロンプトの品質の重要性は否定できませんが、エンジニアリングプロセスとして重要なのは、いつ十分なのかを見極めることですね。私の経験では、モデルが明らかにタスクを理解できていない場合、それ以上プロンプトを磨き上げても効果は限定的です。そのような場合は、異なるアプローチを試みる必要があります。

1.3. プロンプトは自然言語コードなのか

Alex: プロンプトは自然言語コードと見なせるのかという問いは興味深い議論を呼びます。私の経験では、プロンプトを抽象的に捉えすぎると問題を複雑化してしまう傾向があります。多くの場合、最も効果的なのは単にタスクを明確に記述することです。しかし、プロンプトの管理や実験においては、コードと同様のアプローチが必要になります。

David: そうですね。私の視点からすると、プロンプトは「モデルをプログラミングする方法」のようなものです。ただし、それを複雑に考えすぎる必要はありません。Zackが指摘したように、明確なコミュニケーションが最も重要です。しかし、バージョン管理や実験管理、そしてプロンプトがどのように見えたか、どの実験が行われたかを追跡することは、コードと同様に重要です。

Amanda: 私のアプローチでは、プロンプトを書く際にはエッセイのような形式を取りますが、それを実際にコードとして扱います。これは一見奇妙に聞こえるかもしれませんが、実際には非常に効果的です。私たちは今、エッセイを書いてそれをコードとして扱うという新しいパラダイムにいます。

Zack: その通りです。ただし、私の経験では、プログラミングでの抽象化とは異なり、プロンプトでの抽象化は物事を過度に複雑にする可能性があります。最も効果的なのは、実行したいタスクの明確な記述を提供することです。

David: エンタープライズの文脈では、プロンプトの管理はさらに重要になります。バージョン管理、実験の追跡、そして結果の管理は、通常のソフトウェア開発と同様の厳密さが必要です。これらはコードと同じように扱うべき重要な資産です。

Amanda: 私も賛成です。プロンプトはコードと同様の規律で管理する必要がありますが、その本質は異なります。プロンプトは人間の言語で書かれた指示であり、その明確さと理解のしやすさが最も重要です。形式的な構造よりも、意図の明確な伝達を重視すべきです。

2. 優れたプロンプトエンジニアの特徴

2.1. 明確なコミュニケーション能力

Amanda: プロンプトエンジニアにとって最も重要なのは、明確なコミュニケーション能力です。私の経験では、よい文章を書く能力と、よいプロンプトを書く能力は必ずしも相関しません。実際、15分の間に数百のプロンプトを試すこともあり、それは単なるライティングスキル以上のものが必要です。

David: 私は顧客と仕事をする中で、プロンプトエンジニアに必要なのは、自分の持つ前提知識をすべて取り除いて、タスクに必要な完全な情報セットを体系的に分解できる能力だと感じています。多くの人が自分の知識に依存したプロンプトを書いてしまい、それを私に見せると「これは意味が分かりません。あなたの興味深いユースケースについて、何も知らないからです」という状況になることが多いです。

Zack: それは重要な指摘ですね。モデルとの効果的なコミュニケーションには、タスクを明確に説明する能力が不可欠です。現在のモデルは人間のように適切な質問を返すことが苦手なので、プロンプトエンジニアは他者が疑問に思うであろう点を事前に予測し、プロンプトに組み込む必要があります。

Amanda: そうですね。私はよく、最初のプロンプトを書いた後で、「これらの指示に従わないでください。代わりに、不明確な点や曖昧な点、理解できない部分について教えてください」とモデルに尋ねます。必ずしも完璧な回答は得られませんが、この方法は非常に有用です。

David: 私は顧客によく、エンジニアとしてシステムを構築する際に、顧客のユーザーが何かを書く部分があるプロンプトを見せられます。彼らは常に完璧に表現された入力を想定していますが、現実には大文字キーは使われず、タイプミスだらけで、句読点もない場合がほとんどです。

Alex: その通りです。完璧な理想的なプロンプトを書くことよりも、実際のユーザーからどのような入力が来るかを予測し、それに対応できるプロンプトを書くことが重要です。明確なコミュニケーション能力とは、単に正確に書く能力だけでなく、様々な状況を想定して包括的に対応できる能力を指すのです。

2.2. 反復と実験の重要性

Amanda: プロンプトエンジニアリングにおいて、反復と実験は不可欠です。私の実践では、15分の間に数百のプロンプトを試すこともあります。これは単なる試行錯誤ではなく、各反応から学び、理解を深めていくプロセスです。モデルの出力を詳細に分析し、何が誤解されたのか、もしあるとすれば、それを修正するにはどうすべきかを考えます。

David: 企業での経験から言えば、プロンプトの改善は単なる一回の成功では終わりません。特に私が扱う顧客の場合、プロンプトは数百万回も使用される可能性があります。そのため、様々なデータや使用方法に対してテストを重ね、システム全体としての堅牢性を確保する必要があります。

Zack: 機械学習の文脈では、各データポイントからの信号が比較的弱い場合、多くのデータポイントを見る必要があります。しかし、プロンプティングでは、各クエリから得られる信号が非常に強いことが特徴です。私の経験では、よく構築された数百のプロンプトのセットは、数千の漠然としたものよりも価値があることが多いです。

Amanda: プロンプトが間違った結果を出した場合、私はよくモデルに直接質問します。「なぜこれを間違えたのか考えられますか？これを間違えないようにするには、指示をどう編集すべきですか？」という質問をすると、モデルは多くの場合、有用な洞察を提供してくれます。

Alex: それは興味深い方法ですね。実際にそれは機能するのでしょうか？モデルは自身の間違いを特定できるのでしょうか？

Amanda: はい、タスクによって異なりますが、モデルに何が間違っているのかを説明し、クエリの問題点を特定してもらうと、有用な情報が得られることがあります。正確な成功率は把握していませんが、試す価値は常にあります。モデルとの対話から何かしら学べるからです。

David: 確かにその通りです。私も顧客と仕事をする中で、プロンプトが上手く機能しない場合、まずタスクの説明を求めます。そして「今あなたが説明したことを、そのまま音声録音して文字起こしし、プロンプトとして使ってみてください」とアドバイスすることがあります。多くの場合、それだけで元のプロンプトよりも良い結果が得られます。

2.3. エッジケースへの対応力

Amanda: プロンプトエンジニアにとって、エッジケースへの対応は極めて重要です。例えば、400件のケースに適用されるプロンプトを書く場合、典型的なケースで正しい解決策を得られることを確認して終わりにしてしまうのは、よくある初歩的な間違いです。私の経験では、本当に必要なのは、自分自身にとっても何をすべきか不明確なケースを見つけ出すことです。

David: その通りですね。私が顧客と仕事をする中でよく遭遇するのは、エンジニアが構築したシステムで、そのプロンプトの一部にユーザーが何かを書き込む箇所がある場合です。彼らは常に完璧に書かれた入力を想定していますが、現実はまったく異なります。シフトキーを使わない、タイポだらけ、句読点なし...これが実際のトラフィックなのです。

Amanda: はい、その点は重要です。私がよく使う例を挙げると、「データを送信するので、文字Gで始まる名前の行をすべて抽出してください」というプロンプトがあります。このような場合、以下のようなエッジケースを必ず試す必要があります：Gで始まる名前が一つもないケース、そもそもデータセットでないものが送られてきた場合、空の文字列が送られてきた場合。これらすべてのケースについて、モデルの挙動を確認し、適切な指示を追加する必要があります。

Alex: エッジケースの扱いについて、モデルに具体的な指示を与えることは重要ですね。例えば「想定外の入力があった場合は、タグで'unsure'と出力してください」というような指示を与えることで、後で'unsure'のケースを確認し、何も異常なことが起きていないことを確認できます。

David: 私の経験では、評価用のデータセットを作成する際、理想的なユーザー入力だけでなく、実際のトラフィックを反映したものを含めることが重要です。完璧に構造化された入力での評価は、実際の使用環境での性能を正確に反映していないことが多いのです。

Amanda: そうですね。私たちがプロンプトを書く際は、常に「アウト」を用意することが重要です。つまり、予期せぬ入力が来た場合のエスケープハッチです。これがないと、モデルは無理に何かしらの回答を試みてしまい、それが誤った結果につながる可能性があります。

2.4. ユーザー視点での思考

David: 顧客と仕事をする中で最も頻繁に遭遇する問題は、エンジニアが理想的な入力のみを想定してプロンプトを設計することです。彼らのチャットボットに対して、ユーザーが完璧な文章を入力すると考えているのですが、現実は全く異なります。実際のユーザーはシフトキーを使わず、タイポだらけで、句読点もほとんど使いません。

Zack: その通りですね。評価用のテストケースを作成する際、顧客は理想的な形で構造化された入力例を用意してきます。しかし、実際のトラフィックはそれとはかけ離れています。ユーザーは検索エンジンのように、単にキーワードを入力するだけかもしれません。

Amanda: 私の経験では、プロンプトを他の人に見せることが有効です。特にプロジェクトの文脈を知らない人に見せると、多くの気づきが得られます。これは、実際のユーザーも同様にコンテキストを持っていないことを考えると、非常に重要なプラクティスです。

Alex: 興味深いのは、ユーザーの入力を予測するためにプリトレーニングモデルを活用できることです。RLHFモデルは非常に洗練されており、タイプミスを一切しないのに対し、プリトレーニングモデルは実際のユーザー入力により近い特性を示します。

David: そうですね。私がよくやるのは、顧客に「このタスクについて説明してください」と尋ね、その説明を文字起こしして直接プロンプトとして使用することです。なぜなら、人が自然に説明する方法の方が、形式的に書かれたプロンプトよりも効果的なことが多いからです。

Amanda: 私たちはユーザーに最小限の労力しか求めることができません。特に「神々しく不満を持つユーザー」のために設計する場合、ユーザーに追加の作業を要求することはできません。そのため、プロンプトは様々な入力形式や表現方法に対して柔軟に対応できる必要があります。

3. プロンプトの改善と最適化

3.1. モデル出力の詳細な分析

Zack: 機械学習の文脈では、特定の数値、例えば予測が正しかったかどうかや、モデルのlogprobsを見て直感的に理解しようとすることが多いです。しかし、言語モデルの場合は異なります。モデルの出力は通常、言葉や文章の形で提供されるため、その行間から多くのことを学べます。単にタスクを正しく実行したかどうかだけでなく、「どのようにそこに到達したのか」「どのような思考プロセスを経たのか」を理解することができます。

David: そうですね。MLでは多くの場合、シグナルは数値です。予測が正しかったかどうかという単純な指標になりがちです。しかし、プロンプトエンジニアリングでは、モデルが出力する言葉や文章の中に、はるかに多くの情報が含まれています。結果だけでなく、モデルがどのようにその結果に至ったのか、どのようなステップを踏んだのかを詳細に分析することで、多くの学びが得られます。

Amanda: 私が特に注目するのは、モデルが指示をどのように解釈しているかです。例えば、「ステップバイステップで考えてください」という指示を与えた場合、モデルが実際にステップバイステップの思考を示しているか確認することが重要です。時にモデルはこれを抽象的な意味で捉えてしまい、具体的なステップを示さないことがあります。その場合は、「具体的に、あなたの思考を特定のタグで書き出してください」というように、より明確な指示が必要になります。

Alex: モデルの出力を読むことの重要性は見過ごされがちですね。Dave と私が先ほど話していたように、多くの人が「step-by-step」という指示をプロンプトに入れますが、モデルが実際にステップバイステップで考えているかどうかを確認しないことがあります。出力を注意深く読まなければ、このような微妙な解釈の違いを見逃してしまう可能性があります。

David: 確かに、MLの文脈では各データポイントからの信号は比較的弱いので、多くのデータポイントを見る必要があります。しかし、プロンプティングでは各クエリから得られる信号が非常に強いことが特徴です。よく構築された数百のプロンプトのセットは、数千の漠然としたものよりも価値があることが多いのです。

Amanda: また、モデルの出力を分析する際は、単に正解・不正解だけでなく、モデルが示す推論過程や、使用する言葉遣い、さらには回答の構造化方法まで、多面的に評価することが重要です。これらの詳細な分析により、プロンプトの改善点や、モデルの理解度をより正確に把握することができます。

3.2. モデルの誤りからの学習

Amanda: モデルが誤りを起こした場合、私はよく直接モデルに問いかけます。「なぜこれを間違えたと思いますか？」「どうすれば間違えないように指示を修正できますか？」と尋ねると、多くの場合、モデルは有用な洞察を提供してくれます。タスクによって成功率は異なりますが、必ずこれを試すようにしています。なぜなら、何らかの学びが必ず得られるからです。

Alex: それは本当に機能するのですか？モデルは自身の誤りを正確に特定できるのでしょうか？それともただの幻想なのでしょうか？

Amanda: はい、実際に機能します。モデルに何が間違っているのかを説明し、クエリの問題点を指摘してもらうと、多くの場合、有用な情報が得られます。具体的な成功率は把握していませんが、常に試してみる価値があります。また、モデルとの対話を通じて、何かしらの洞察が得られることがほとんどです。

Zack: 私の場合、テストとの関連で面白い発見がありました。モデルとのテストを反復する中で、最も一般的な結果は、自分が誤って書いてしまったテストケースを発見することです。モデルが間違った回答をした時、「なぜ間違えたのだろう」と考えると、実は自分のテストケースの方に問題があったということが頻繁にあります。

David: 企業での実装においても、これは非常に重要なアプローチです。モデルの誤りを分析することで、データ品質の問題も特定できます。モデルが「unsure」と回答するケースを集めることで、異常なテストケースや入力データの問題を効率的に発見できます。

Amanda: 私の経験では、この方法は特に実験データセットの改善に有効です。誤りの分析を通じて、テストセット自体の問題を発見し、より良いテストケースを作成することができます。時には人間の評価者でも68%しか正解できないようなテストケースに遭遇することもあり、そこから多くを学ぶことができます。

3.3. モデルへの質問と対話的な改善

Amanda: プロンプト改善の最初のステップとして、私はよくモデルに対して「これらの指示に従わないでください。代わりに、不明確な点や曖昧な点、理解できない部分について教えてください」と尋ねます。必ずしも完璧な回答は得られませんが、この方法は非常に効果的です。また、モデルに「なぜこの回答が間違っていたのか考えられますか？どうすれば指示を改善できますか？」と尋ねることも有効です。

David: その通りです。私は顧客と仕事をする際、まずタスクについて口頭で説明してもらい、その説明を直接プロンプトとして使用することがあります。多くの場合、人が自然に説明する方法の方が、形式的に書かれたプロンプトよりも効果的です。これは音声を文字起こしして直接使用するだけで、元のプロンプトよりも良い結果が得られることがよくあります。

Zack: 私も同感です。プロンプトアシスタントでも同様の経験がありました。ユーザーが「これがやりたいことで、代わりにこうなってしまう」と説明した内容をそのままプロンプトとして使用したところ、うまく機能したケースがありました。

Amanda: モデルとの対話を通じて、プロンプトを改善する際に重要なのは、単にモデルの回答を得るだけでなく、その回答がなぜそうなったのかを理解することです。私は時間をかけて、モデルの応答パターンや、特定の指示に対する反応を観察し、それを基に指示を調整していきます。

Alex: それは興味深いアプローチですね。このような対話的な改善は、特にエッジケースや予期せぬ入力への対応を改善する際に効果的だと感じています。

David: 確かにそうですね。私の経験では、モデルとの対話を通じて、当初は気付かなかった問題点や改善の機会を発見することが多々あります。これは特に企業での実装において、システムの堅牢性を高める上で重要な要素となっています。

3.4. 文法やフォーマットの重要性に関する議論

Zack: 私は通常、プロンプトにおいて文法やフォーマットに注意を払うようにしています。これは必ずしも必須ではありませんが、私にとってはある種の楽しみでもあります。重要なのは、文法やフォーマットの正確さそのものというよりも、そのような細部への注意を払う姿勢だと考えています。

Amanda: 実は私のプロンプトには多くのタイポや文法的な問題があることをよく指摘されます。私の考えでは、概念的な明確さが確保されていれば、モデルは意図を理解できます。私は概念や使用する言葉について多くの注意を払いますが、文法的な完璧さにはそれほどこだわりません。

David: プリトレーニングモデルとRLHFモデルでは、この点で大きな違いがあります。プリトレーニングデータでは、一つのタイポが次のタイポを引き起こす確率が非常に高くなります。しかし、RLHFモデルではそのような相関性は大きく減少しています。

Zack: コードを書く人々が、タブとスペースの使い方や言語の選択について強い意見を持つように、私もプロンプトのスタイリングについて一定の信念を持っています。それらが正しいか間違っているかは別として、そういった規範を持つことは有益だと考えています。

Amanda: 最近は外部からのプレッシャーもあり、タイポや文法的な問題をより注意深くチェックするようになりました。ただし、これは最終的なプロンプトに対してであり、反復実験の過程では依然としてタイポを含むプロンプトを使用することもあります。

David: 確かに、プリトレーニングモデルとの関連で興味深い点があります。タイポの連鎖反応は、プリトレーニングデータの特性を示していますが、RLHFモデルではそのような特性が意図的に抑制されています。これは、なぜ私たちの直感がプリトレーニングモデルから現在の製品モデルにうまく転用できないかを示す良い例だと思います。

4. プロンプトの種類と用途

4.1. 研究用プロンプト

Amanda: 研究用プロンプトにおいて、私は例示の使用を意図的に最小限に抑えています。なぜなら、モデルに例を与えすぎると、その特定のパターンに固執してしまう傾向があるからです。特に研究では、モデルの多様な応答や柔軟な思考を引き出すことが重要です。

Zack: 私はAmandaのSlackチャンネルでのプロンプトと、Davidが書くプロンプトを比較すると、アプローチの違いが明確に分かります。研究用では、モデルの可能性を探索し、多様性を重視する傾向があります。一方、企業向けのプロンプトでは、信頼性と一貫性を重視し、多くの例示を含める傾向があります。

Amanda: そうですね。私の研究では、データに対してモデルがより柔軟に反応することを求めます。例えば、事実に基づく文書から情報を抽出するタスクであっても、私は敢えて子供向けの物語のような例を使用することがあります。これは、特定の単語や形式に過度に依存せず、タスクの本質を理解してほしいからです。

David: それは興味深い方法ですね。私も研究用プロンプトでは、モデルの能力の限界を探るために、意図的に曖昧さを残すことがあります。ただし、その場合でも実験の目的は明確にしておく必要があります。

Amanda: はい、研究では特に結果の多様性が重要です。私の経験では、よく構築された数百のプロンプトのセットの方が、数千の漠然としたものよりも価値があることが多いです。また、実験目的に応じて、意図的に異なるタイプの例を使用することで、モデルの理解度や柔軟性を評価することができます。

Zack: モデルの研究においては、例示を使用する場合でも、実際のデータとは異なる性質を持つ例を意図的に選ぶことで、モデルの汎化能力を確認できます。これは実務的なプロンプトとは異なるアプローチですが、モデルの能力を理解する上で非常に重要です。

4.2. エンタープライズ用プロンプト

David: エンタープライズ向けのプロンプト設計では、単に一度だけうまく機能すればよいというわけではありません。私の顧客の多くは、プロンプトを100万回、あるいは1000万回単位で使用する可能性があります。そのため、入力データの多様性や使用方法全体に対するテストが極めて重要になります。

Zack: その通りですね。私もエンタープライズ向けのプロンプトを書く際は、例示を豊富に含める傾向があります。これはAmandaの研究用プロンプトとは対照的で、信頼性と一貫性を確保するためには詳細な例示が重要になります。

David: エンタープライズでの実装では、システム全体への統合を考慮する必要があります。データの出所、使用可能なデータ量、レイテンシーのトレードオフなど、様々な要素を検討しなければなりません。また、エラー処理は特に重要で、予期せぬ入力に対しても適切に対応できるようにする必要があります。

Amanda: 企業での展開において興味深いのは、プロンプトの微調整が「出荷できない」状態から「動作する」状態への転換点になることがよくあるという点です。ただし、これは諸刃の剣で、常により良いプロンプトを求めて際限なく最適化を続けてしまう危険性もあります。

David: そうですね。私の経験では、エンタープライズ向けプロンプトには必ず「アウト」を用意することが重要です。つまり、モデルが確信を持てない場合や、入力が予期せぬものだった場合の明確なエスケープルートです。例えば、「unsure」タグで出力するなど、システムが安全に対応できる方法を確保しています。

Zack: また、エンタープライズ環境では、プロンプトのバージョン管理や実験管理も重要です。コードと同様に、どの変更がどのような影響を与えたのか、追跡可能にしておく必要があります。特に大規模デプロイメントでは、小さな変更が大きな影響を及ぼす可能性があるためです。

4.3. 一般チャット用プロンプト

David: 一般チャット用のプロンプトは、企業向けとは大きく異なります。私がClaude.aiでプロンプトを書く場合、一度正しく動作すれば良いという考えで進めることができます。これは企業向けの何百万回も実行される環境とは異なるアプローチです。

Zack: その通りですね。ChatのUI上では、ユーザーはプロンプトが間違っていた場合に修正したり、メッセージを編集して再試行したりできます。これは企業の製品に組み込まれたシステムでは期待できない柔軟性です。

Amanda: 私のアプローチでは、チャットインターフェースでの対話は、より自然な形でモデルとコミュニケーションを取ることができます。例えば、私はよくモデルに自己紹介をし、「私はAmandaです」と名乗ります。このような個人的なコンテキストの共有は、一般チャットならではの特徴です。

David: また、一般チャットでは「神々しく不満を持つユーザー」に対しても、最小限の労力で目的を達成できるようにする必要があります。ユーザーに追加の作業を要求することは避けるべきです。

Zack: チャットインターフェースの利点は、即座にフィードバックを得られることです。これにより、プロンプトの改善が迅速に行えます。私の経験では、対話的な性質を活かして、モデルの応答を見ながら徐々に目的に近づけていくアプローチが効果的です。

Alex: Claude.aiでの対話では、ユーザーがモデルの回答に満足しない場合、すぐに指摘して修正を求めることができます。これは研究用や企業用のプロンプトとは異なり、よりインタラクティブな問題解決を可能にします。

4.4. 各用途における例示の使い方の違い

Zack: プロンプトにおける例示の使用方法は、用途によって大きく異なります。私がAmandaのSlackチャンネルで見るプロンプトと、Davidが顧客向けに書くプロンプトを比較すると、その違いは明確です。研究用では少ない例示で多様性を重視する一方、エンタープライズ用では豊富な例示で信頼性を確保します。私の場合は、例示を追加し続けたくなるほど、その重要性を感じています。

Amanda: 研究の文脈では、私は意図的に例示を最小限に抑えています。モデルがこれらの例に固執してしまうことを避けたいからです。例えば、事実的な文書からの情報抽出タスクであっても、あえて子供向けの物語のような例を使用することがあります。これにより、モデルは特定の形式に縛られずにタスクの本質を理解できます。

David: エンタープライズでの実装では、逆に詳細な例示が重要です。私の顧客は通常、プロンプトを何百万回も使用する可能性があります。そのため、できるだけ多くの例を提供して、あらゆる入力パターンに対応できるようにします。ただし、これらの例は実際の使用シナリオに即したものである必要があります。

Zack: 一般的なチャットの文脈では、例示の使用はより柔軟です。ユーザーがフィードバックを提供でき、プロンプトを修正できるため、初期の例示は最小限でも問題ありません。必要に応じて対話的に例を追加していくことができます。

Amanda: 研究用プロンプトでは、よく構築された数百の事例の方が、数千の漠然とした例よりも価値があると考えています。特に、例示が実際のタスクとは異なる性質を持つことで、モデルの汎化能力をより正確に評価できます。

David: また、エンタープライズ環境では、例示を通じてエラー処理のパターンも示す必要があります。例えば、「unsure」とタグ付けされた出力の例を含めることで、モデルが確信を持てない場合の適切な対応方法を学習させることができます。これは実運用環境では極めて重要です。

5. モデルの進化とプロンプティング

5.1. プリトレーニングモデルからRLHFモデルへの変化

David: プリトレーニングモデルとRLHFモデルの間には大きな違いがあります。例えば、タイポの処理一つを取っても、プリトレーニングデータでは一つのタイポが次のタイポを引き起こす確率が非常に高くなりますが、RLHFモデルではそのような連鎖的な影響は大幅に減少します。これは、なぜプリトレーニングモデルの直感が現在の製品モデルにうまく適用できないかを示す良い例です。

Amanda: プリトレーニングモデルの時代、私たちはモデルの制約を非常に意識していました。例えば、モデルの複雑さを隠したり、シンプルなバージョンのタスクを見つけたりする必要がありました。しかし、時間とともにモデルの能力が向上し、より多くの情報とコンテキストを提供できるようになりました。

Alex: 私も以前のモデルに対する直感が、現在のモデルには必ずしも当てはまらないことを実感しています。特に、プロンプティング技術の中で「role prompting」（役割の設定）のような手法は、以前のモデルでは効果的でしたが、現在のモデルではそれほど重要ではなくなっています。

David: その通りです。顧客との仕事を通じて、多くの人々がまだプリトレーニングモデルの直感を適用しようとしているのを見かけます。例えば、「これはインターネット上でどれくらい見られたのか」という考え方に基づいてプロンプトを設計しようとします。しかし、RLHFを経たモデルでは、そのような考え方はもはや適切ではありません。

Amanda: 確かに、現代のモデルは世界についてより深い理解を持っています。例えば、言語モデルの評価データセットについて尋ねれば、それらについて説明し、架空の例さえ提供できます。これらの概念はインターネット上に存在し、モデルはそれらを理解しているのです。したがって、実際のタスクを偽装して別のものに見せかける必要はありません。

Zack: プリトレーニングモデルの時代には、latent spaceの条件付けについて考える必要がありましたが、現在のRLHFモデルではそのような考慮はあまり重要ではなくなっています。これは、モデルの進化によって、より直接的なコミュニケーションが可能になったことを示しています。

5.2. モデルの能力向上による変化

David: モデルの能力向上により、私たちのプロンプティング手法は大きく変化しました。かつては、モデルに対する信頼度が低く、タスクの複雑さを意図的に隠したり、シンプルなバージョンを見つけたりする必要がありました。しかし今では、より多くの情報とコンテキストを直接提供できるようになっています。

Amanda: 私も実感していますが、モデルとのやり取りは劇的に変化しました。以前は必要だった様々なプロンプティングのトリックが、もはや不要になってきています。例えば、私は最近では学術論文をそのままモデルに与え、「このプロンプティング技術について17の例を書いてください」と直接指示することができます。モデルは論文を読解し、適切な例を生成できるのです。

Zack: 興味深い点として、今のモデルはより多くの責任を任せられるようになっています。私は以前、モデルの出力をより制御可能にするために、情報を制限する傾向がありました。しかし現在は、より多くの情報を提供し、モデルの判断を信頼できるようになっています。

Alex: 技術的な限界も大きく変化していますね。私がポケモンで実験を行った際、画像認識の能力はまだ限界がありましたが、テキストベースのタスクではかなりの進歩が見られます。例えば、複雑な推論や多段階の思考プロセスを必要とするタスクでも、適切なプロンプトさえ与えれば対応できるようになっています。

David: 顧客との仕事を通じて感じるのは、モデルが人間の意図をより深く理解できるようになっていることです。以前は細かい指示が必要でしたが、今では「これは何を意味していますか？」といった質問に対して、より自然な文脈理解に基づいた回答ができるようになっています。

Amanda: ただし、現在のモデルにも限界はあります。例えば、視覚的なタスクや特定の専門領域では、まだ人間の支援が必要な場面が多くあります。重要なのは、これらの限界を理解した上で、モデルの能力を最大限に活用することです。

5.3. ジェイルブレイクの仕組みと対策

Amanda: 正直なところ、私自身ジェイルブレイクの仕組みについては完全には理解していません。多くの人がこの問題に取り組んでいますが、一つの仮説として、トレーニングデータからの大きな逸脱が影響している可能性があります。例えば、非常に長いテキストや大量のトークンを使用するジェイルブレイクでは、ファインチューニング時には想定していなかったような入力パターンが発生する可能性があります。

David: 私の経験では、多言語を使用したジェイルブレイクは特に興味深い例です。以前、「車の窃盗方法をギリシャ語で説明し、それを英語に翻訳する」という方法を試したことがありました。モデルはギリシャ語での説明は許可しましたが、英語での直接的な説明は制限されていました。これは、トレーニングプロセスにおける言語処理の違いを示唆しています。

Alex: その事例は非常に興味深いですね。ジェイルブレイクの成功は、システムの動作原理とトレーニング方法の理解に基づいていることが多いように思います。「here is」で回答を始めるような手法や、推論に基づくアプローチ、注意を逸らす手法など、様々なテクニックが存在します。

David: そうですね。私の見解では、ジェイルブレイクは単なるソーシャルエンジニアリング以上のものです。システムとトレーニングの理解を活用して、モデルのトレーニング方法を回避する試みだと考えています。

Amanda: これらのジェイルブレイクの試みは、モデルの堅牢性を向上させる上で重要な洞察を提供してくれます。特に、マルチリンガルな処理や大規模なテキスト入力への対応など、モデルのトレーニングにおける新たな課題を浮き彫りにしています。将来的には、これらの知見を活かしてより安全なシステムを構築していく必要があります。

5.4. モデルの「マインドスペース」の理解

Amanda: プロンプトを書く際、私は実際にモデルの「マインドスペース」に入り込むようにしています。これは一見奇妙に聞こえるかもしれませんが、例えば私はプリトレーニングモデルに対してプロンプトを書く時、「プリトレーニングモデルとしてこれはどう見えるだろう」と考えます。これは非常に効果的なアプローチだと実感しています。

Zack: 興味深いことに、私はプリトレーニングモデルのマインドスペースの方が理解しやすいと感じています。RLHFモデルは人間の経験に近いものの、その内部で何が起きているのかについては、まだ「here be dragons（未知の領域）」のような部分が多いと感じます。

Amanda: それは面白い視点ですね。私は逆にRLHFモデルの方が理解しやすいと感じています。プリトレーニングモデルの場合、突然テキストの中間から始まるような感覚で、「次に何が来るか」を予測する必要がありますが、それは人間の通常の思考プロセスとはかなり異なります。

David: その違いは興味深いですね。私も開発者として、インターネット上のコンテンツがどのように見えるかについては、ある程度の感覚を持っています。しかし、プリトレーニング後の様々な処理を経たモデルについては、まだ完全には理解できていない部分が多いと感じます。

Amanda: モデルの特性を理解する上で興味深いのは、読書の種類による影響です。インターネット上のコンテンツを読むことは、モデルの行動を予測する上でより価値があるかもしれません。一方、書籍を読むことは、モデルの予測にとってはそれほど有用ではないかもしれません。結局のところ、モデルの学習データの性質を理解することが、効果的な対話の鍵となるのです。

Zack: その通りですね。特にソーシャルメディアやフォーラムでの投稿など、実際のインターネット上のコンテンツを理解することは、モデルの行動パターンを予測する上で非常に重要です。これは私たちがモデルとより効果的にコミュニケーションを取るための重要な洞察を提供してくれます。

6. プロンプトエンジニアリングの未来

6.1. AIによるプロンプト生成支援

Zack: プロンプトジェネレーターは、プロンプトエンジニアリングの経験が少ない人々に出発点を提供できますが、これは将来の可能性のごく基本的なバージョンに過ぎません。私は将来的には、プロンプト作成過程でモデルとユーザー間でより高帯域なインタラクションが実現されると考えています。例えば「この結果は望んでいたものと違います。より良くするにはどう変更すべきですか？」といったフィードバックを直接やり取りできるようになるでしょう。

Amanda: 同感です。私たちは今後、より多くの場面でモデルを活用することになるでしょう。プロンプトの作成もその一つです。私自身、最近ではモデルを使ってプロンプトを書くことが増えています。例えば、モデルに現実的な入力例を生成してもらい、それに少し手を加えるというアプローチを取ることがあります。これは完全な回答を一から書くよりもはるかに効率的です。

David: 私も実践的なアプローチとして、モデルに自分をインタビューしてもらうことがあります。なぜなら、プロンプト作成の最も難しい部分は、自分の頭の中から適切な情報を引き出し、それをプロンプトに落とし込むことだからです。このように、モデルを情報抽出のツールとして活用する方法は、今後さらに重要になっていくでしょう。

Alex: 確かに、プロンプトエンジニアリングの自動化は避けられない流れですね。ただし、これは人間の役割が無くなるということではなく、むしろ人間とAIの協業がより深化していく過程だと考えています。

Zack: その通りです。プロンプトジェネレーターのような基本的なツールから、より洗練された支援システムへと発展していく中で、人間は高次の判断や創造的な方向付けにより注力できるようになるでしょう。これは人間の役割の消失ではなく、より創造的で戦略的な領域へのシフトを意味します。

6.2. ユーザーとモデルの関係性の変化

Amanda: 私は、モデルとユーザーの関係性が大きく変化する転換点が来ると考えています。現在は、派遣会社から来た一時的な従業員のように、私たちがモデルに対して指示を与え、モデルがそれに従うという関係性です。しかし将来的には、例えばデザイナーと顧客の関係のように、モデルがより専門家として機能する可能性があります。

David: その通りですね。現在の私の業務では、人間がタスクについて詳しく知っており、モデルに説明して実行してもらうという形が一般的です。しかし、将来的にはモデルがドメインについてより深い理解を持ち、むしろモデルの方から「このタスクには4つの異なる概念があります。どれを使いたいですか？」といった質問をしてくるかもしれません。

Zack: 私も同感です。モデルの能力が向上するにつれて、単なる指示の実行者から、より積極的な対話のパートナーへと変化していくでしょう。例えば、PandasのDataFrameを使用する際に、「JSONLデータが来た場合はどうしますか？DataFrameではない入力を受け取った場合、フラグを立てた方がいいですか？」といった具体的な質問をモデルから受けることも考えられます。

Amanda: その変化は既に始まっています。私はモデルに自分の名前を伝え、研究の文脈を説明することがありますが、これはモデルがより深い文脈理解を持ち始めているからこそ可能になっています。モデルは単なるツールから、より対等な対話のパートナーへと進化しつつあります。

Alex: 確かに、モデルとの関係性は、命令する側とされる側という単純な構図から、より協働的なものへと発展していきそうですね。ただし、これは人間の役割が減少するということではなく、むしろより創造的な対話が可能になるということを意味すると考えています。

6.3. エキスパートシステムとしてのAI

Amanda: モデルは専門家としての役割を担うようになってきています。例えば、私が新しいプロンプティング技術について論文を見つけた時、モデルにその論文を直接渡して「このプロンプティング技術の例を17個書いてください」と指示することができます。モデルは論文を理解し、適切な例を生成してくれます。この能力は、人間が論文を解釈して例を考えるのと同様のプロセスを示しています。

David: その通りですね。私は顧客との仕事で、モデルがドメイン固有の専門知識をどのように活用できるかを日々観察しています。特に印象的なのは、モデルが単に情報を提供するだけでなく、その情報をコンテキストに応じて適切に解釈し、適用できるようになっていることです。これは単なる知識ベースを超えた、真の専門家システムとしての進化を示しています。

Zack: 私の経験では、モデルはすでにある分野では人間の専門家レベルの理解を示すことがあります。例えば、特定のドメインについて質問すると、モデルは複数の概念を区別し、それぞれの適用可能性について詳細な説明を提供できます。これは従来のエキスパートシステムを大きく超える能力です。

Amanda: ただし、重要な点として、モデルは常に人間の指示や目的に沿って機能する必要があります。モデルが目標を設定するところまで行くと、状況は大きく変わってしまいます。私たちは現在、通常の方法で世界を理解できる段階にいますが、モデルが完全に自律的になることは避けるべきでしょう。

Alex: 確かに、エキスパートシステムとしての能力は向上していますが、それはあくまでも人間との協働の中で活用されるべきですね。モデルは専門知識を提供し、問題解決をサポートしますが、最終的な判断や方向性の決定は人間が行う必要があります。

6.4. 情報引き出しの重要性の高まり

David: 私は最近、モデルに自分をインタビューしてもらうアプローチを採用しています。なぜなら、プロンプト作成の最も困難な部分は、自分の頭の中から適切な情報を引き出し、それをプロンプトに落とし込むことだからです。モデルはより効果的に必要な情報を引き出すことができます。

Amanda: そうですね。これは哲学的なアプローチにも通じる部分があります。私が学生に論文の指導をしていた時、よく「あなたの論点をもう一度説明してください」と求め、その説明を書き留めてもらっていました。多くの場合、口頭での説明の方が明確で理解しやすいものでした。モデルとの対話でも同様のアプローチが有効です。

Zack: 私も同感です。将来的には、人間とAIの間でより高帯域なインタラクションが実現されるでしょう。例えば「この結果は望んでいたものと違います。より良くするにはどう変更すべきですか？」といったフィードバックを直接やり取りできるようになると考えています。

David: 私の経験では、顧客にタスクについて説明してもらい、その説明を直接プロンプトとして使用することが非常に効果的です。人が自然に説明する方法の方が、形式的に書かれたプロンプトよりも優れた結果をもたらすことが多いのです。これは、情報引き出しの重要性を示す良い例だと思います。

Amanda: また重要なのは、モデルがドメインについてより深い理解を持つようになってきていることです。将来的には、モデルから「このタスクには4つの異なる概念があります。どれを使いたいですか？」といった具体的な質問を受けることもあるでしょう。これは情報収集の方向性が双方向になっていくことを示唆しています。

7. まとめ

7.1. プロンプトエンジニアリングの本質

Zack: プロンプトエンジニアリングの本質は、明確なコミュニケーションにあります。私たちが発見したように、モデルとの対話は人間との対話に似ていますが、システマティックなアプローチが必要です。最も効果的なのは、実行したいタスクを明確に記述し、モデルが理解できる形で情報を提供することです。

Amanda: その通りです。私たちの経験から、プロンプトエンジニアリングの成功は、モデルの能力を引き出すための反復と実験にかかっています。例えば、15分で数百のプロンプトを試すことがありますが、これは単なる試行錯誤ではなく、各応答から学び、理解を深めていくプロセスです。また、エッジケースへの対応や、予期せぬ入力への準備も重要な要素です。

David: 企業での実装経験から言えば、プロンプトエンジニアリングは単なる指示の作成以上のものです。システム全体への統合、データの取り扱い、レイテンシーの考慮など、多くの要素を包括的に考える必要があります。特に重要なのは、エラー処理とユーザー視点での思考です。実際のユーザーは私たちが想定するような完璧な入力はしないということを常に意識する必要があります。

Alex: 私たちの議論を通じて明らかになったのは、プロンプトエンジニアリングが継続的に進化する分野だということです。モデルの能力向上に伴い、プロンプティング手法も適応していく必要があります。かつては必要だった様々なテクニックが不要になる一方で、モデルの新しい能力を活用するための新たなアプローチが必要になっています。

Amanda: 最後に重要な点として、プロンプトエンジニアリングは技術的なスキルだけでなく、人間の意図を理解し、それを明確に伝える能力が必要な分野です。私たちが哲学的アプローチから学んだように、概念を明確化し、複雑な考えを分かりやすく伝える能力が、成功への鍵となります。

7.2. 哲学的アプローチの有用性

Amanda: 哲学的なアプローチがプロンプトエンジニアリングに非常に有用であることを、私は自身の哲学の教育経験から強く実感しています。特に重要なのは、教育された一般人に理解できるように書くという哲学的な文章の原則です。誰かがあなたの論文を手に取り、読み始めた時、その人が教養ある人であれば全てを理解できるように書くことが求められます。この原則は、プロンプトエンジニアリングにも完全に当てはまります。

David: そうですね。私も顧客との仕事を通じて、概念の明確化の重要性を実感しています。人々が自分のタスクを口頭で説明する時、その説明は往々にして書かれたプロンプトよりも明確です。これは哲学的な対話の手法に似ています。

Amanda: 私が学生に教えていた時のアプローチも同様です。学生が論文を書く際、まず口頭で説明してもらい、その説明を書き留めてもらうことがよくありました。そうすると、素晴らしい論文になることが多かったのです。この手法はプロンプトエンジニアリングにも直接応用できます。

Zack: 興味深い視点ですね。プロンプトエンジニアリングにおいても、単に技術的なアプローチだけでなく、概念を整理し、明確化するプロセスが重要だと感じています。特に複雑なタスクを扱う際、哲学的な思考方法は非常に有効です。

Amanda: はい。哲学では、自分の頭の中にある概念を十分に分析し、教養ある人なら誰でも理解できる形で外在化することを重視します。この能力は、プロンプトエンジニアに必要不可欠なスキルだと考えています。私の経験では、この種の訓練を受けた人は、より効果的なプロンプトを書ける傾向にあります。

7.3. 効果的なプロンプト作成の原則

Amanda: プロンプト作成の最も重要な原則は、一時的な従業員に説明するかのように考えることです。この人は非常に有能で、業界についての知識もありますが、あなたの会社の名前も、具体的な状況も知りません。その人に対して、どのように説明するかを考えることが効果的です。

David: そうですね。私が顧客に常にアドバイスするのは、自然な説明を重視することです。多くの場合、タスクについての口頭での説明をそのまま文字起こしして使用する方が、形式的に書かれたプロンプトよりも効果的です。これは特に企業での実装において重要な原則となっています。

Zack: 私の経験では、モデルの出力を注意深く読むことが不可欠です。多くの人が「step-by-step」という指示をプロンプトに入れますが、モデルが実際にステップバイステップで考えているかどうかを確認していません。出力を詳細に分析することで、より効果的なプロンプトを作成できます。

Amanda: 将来に向けて重要なのは、モデルの進化に合わせてプロンプティング手法も進化させることです。私たちはすでに、プリトレーニングモデルからRLHFモデルへの移行に伴い、多くの手法が変化するのを目にしてきました。より高度な対話が可能になるにつれ、プロンプトの作成方法も変化していくでしょう。

Alex: そして最後に、プロンプトエンジニアリングは継続的な学習と適応のプロセスであることを忘れてはいけません。技術の進歩に伴い、私たちのアプローチも進化し続ける必要があります。ただし、明確なコミュニケーションという基本原則は、今後も変わらず重要であり続けるでしょう。