ルールブックとしてのプロンプト - 基本的な指示を超えてLLMエージェントを導く

大規模言語モデル（LLM）を従来のAPIと統合する旅の中で、私たちはプロンプトが新しい「APIドキュメント」となり、ツールができることを説明することを見てきた。最初はとてもシンプルに聞こえるだろう。LLMにいくつかのツールへのアクセス権を与え、それらを記述すれば、ほら、インテリジェントなエージェントの出来上がりだ！しかし、私たちの多くが発見しているように、ツールを使えるLLMと、より広い文脈でツールを賢くあるいは効果的に使うLLMとの間には決定的な違いがある。これは、私たちがシンプルなカレンダーアシスタントで見た課題に直接取り組んでいます。

ここで、私が「熱心なインターン」症候群と呼ぶものにしばしば遭遇する。あなたのLLMエージェントは、熱心ではあるが経験の浅いインターンのように、ツールに関する明確な指示に熱心に従う。しかし、明文化されていないルールや微妙な人的要因、あるいは "全体として最良の結果 "を直感的に考慮する経験豊富な従業員のような熟練した判断力に欠けているかもしれない。現在のLLMは、与えられた文章を理解し、実行することには非常に長けているが、真の成功を左右することが多い、暗黙の文脈やタスクの背後にある微妙な「なぜ」を本質的に把握していない。

つまり、開発者として、私たちの役割は進化するのです。単にツールの機能を説明するだけでなく、複雑な意思決定プロセスを通してLLMを導きながら、プロンプトの中にルールブックを綿密に作り上げるのだ。

ケーススタディ思いやりのある」カレンダー・アシスタント

パート2の "カレンダー・アシスタント "ツールをもう一度見てみましょう。メインのLLMエージェントが、定義した2つの主要な機能にアクセスできると想像してください：

1. CreateMeeting(attendees, subject, startTime, duration, location):ミーティングを予約する。
2. FindFreeTime(attendees, duration, timeWindow):利用可能なスロットを検索します。

これらのツールの初期プロンプトは、基本的な解釈を処理し、各従業員の標準的な勤務時間、例えば月曜日から金曜日の午前8時から午後6時（現地時間）を尊重するように設定されています。

さて、ロンドンを拠点とするチームリーダーのユーザーからこんな依頼があった：「来週早々、プロジェクト・アトラスのために1時間の重要な戦略セッションが必要だ。参加者は私、マリア（同じくロンドン在住）、ベン（エディンバラ在住）の3人です。これには参加者全員にかなりの準備が必要です。ロンドン本部でスケジュールを組んでください。"

熱心なインターン」エージェントは仕事に取りかかる。FindFreeTimeを使ってカレンダーを検索し、月曜日午前8時30分（グリニッジ標準時）が、定義された標準労働時間内であれば、誰にとっても技術的に "フリー "であることを発見する。

• と呼びかける： CreateMeeting(attendees=["[email protected]", "[email protected]", "[email protected]"], subject="Project Atlas Strategy Session", startTime="<Next Monday @ 08:30 GMT>", duration="1 hour", location="London HQ").

技術的にはミーティングが予定されている。しかし、それは良い結果なのだろうか？その意味を考えてみよう：

1. 移動の考慮は無視：エジンバラを拠点とするベンにとって、午前8時半にロンドンで直接会うのは非常に問題がある。月曜の早朝に移動するか、日曜の夕方に移動しなければならない可能性が高い。このエージェントは、カレンダーの "8-6時の勤務時間 "だけを見ただけで、早朝のミーティングに多大な出張が必要であるというロジスティクスの非現実性と個人的な影響をまったく考慮しなかった。地元の出席者のための午前8時30分の枠と、物理的に出席する必要のある遠隔地の出席者のための枠を区別しなかったのだ。
2. 見過ごされた準備時間：ユーザーは、これが「重要な準備」を必要とする「重要な戦略セッション」であると明言している。月曜の朝一番（8:30am）にスケジュールを組むことは、このような早いスタートに備えたいのであれば、週末の個人的な時間を使って準備をするよう、参加者に暗に圧力をかけることになる。

これは、開発者として、エージェントが明確なカレンダーの空き状況に基づいてタスクを実行したが、重要な暗黙の人的要因や実用的な考慮事項を見逃していたことに気づく瞬間である。純粋に効果的で思いやりのある結果を保証するための判断が欠けていたのです。

経験」と「考察」をプロンプトにエンコードする

インターン」を「経験豊富なアシスタント」に昇格させるためには、より洗練されたロジックを組み込む必要がある。 メインエージェント・ガイディング・プロンプト (または、ツールをオーケストレーションする際に従う包括的な指示）。これは、単に FindFreeTime または CreateMeeting ツールそのものだ。エージェントには より思いやりのある行動をするには.

この場合、エージェントに "第3のツール"、つまり追加的な情報やロジックのレイヤーを探して使用するように指示することが多い。この場合、それは 出席者の所在地、移動の状況、会議の性質。 私たちのエージェントは、暗黙的に（あるいは、次のような別のツールを使って明示的に）、次のようなことを行う必要があるかもしれません。 GetUserProfile(email)) アクセスする、あるいは推測する：

• 各出席者の主な勤務地
• 会議のタイプ（例：対面かバーチャルか）。
• 会議の重要性とタイミング（例：「重要な月曜日の朝の会議」）の意味合い。

この "文脈データ "にアクセスすることで、エージェントのマスタープロンプトに "if...then... "スタイルの指示リストを追加する必要がある：

改訂版エージェント・プロンプト・ロジック・スニペット（概念的）：

"...会議の日程調整を任されたとき：

1. 強化されたコンテクストを集める： 各出席者について、彼らがどこにいる可能性が高いかを判断する。 GetUserProfile(attendee_email)).会議が「対面式」と指定されている場合、および出席者が遠隔地にいる場合に注意すること。
2. 直接会う会議のための出張を考慮する：
   • もし 会議は対面式である、 と 参加者は遠隔地にいる、 と 早朝枠（例：会議開催地の現地時間午前10時以前）を提案する：
     • 次に、依頼者にこのフラグを立てます。例えば、『ベンはこの直接ミーティングのためにエジンバラから移動します。月曜日に快適に移動できるよう、ミーティングは午前10時30分以降に開始することをご希望ですか？
3. 重要な会議の準備時間を考慮する：
   • もし 会議が「重要」、「重要」、または「重要な準備」を必要とするものである。 と 月曜日の早い時間帯（あるいは休日直後）に予定されている：
     • そして、依頼者に確認を求める。例えば、『準備が必要な重要な月曜日のセッションの場合、午前8時30分の開始時間であれば、月曜日の朝自体に全員が十分な時間を取ることができますか、それとも、当日の準備を可能にするために午前10時ごろの枠の方が適していますか？
4. 一般的なタイムゾーン／労働時間の競合に対処する（前述）：
   • (「コアな社交の場」を優先し、それ以外の時間帯に対応するためのロジックを組み込み、バーチャルな会議であっても、場合によっては異なるタイムゾーンにまたがる都合の悪い時間帯の確認を求める)。
5. 明示的なユーザーオーバーライドを尊重する：
   • もしユーザーが不都合な手配を明示的に確認したら（例えば、"はい、ベンは承知しており、日曜日に旅行する予定です"）、おそらく最終確認とともに、"了解しました。確認したとおりにスケジューリングします。"

プロンプト簡単な説明から複雑なアルゴリズムまで

ご覧の通り、メインエージェントのプロンプトは大きく進化した。もはや利用可能なツールのリストではない。詳細で条件付きの決定木だ。自然言語で表現されたアルゴリズムのミニチュアだ。これらの "if...then... "ステートメントは、エージェントの "推論 "プロセスのバックボーンとなり、単なる解決策ではなく、より良い解決策へと導きます。

このような潜在的な落とし穴を予見し、「経験」、「会社の方針」、または「一般的な礼儀」をLLMの指示に直接エンコードすることです。LLMは信じられないほどの力をもたらすが、その力を真に有用で思いやりのあるアプリケーションへと導く開発者の仕事は、これまで以上に重要であることを証明している。それは、「熱心なインターン」を信頼できる経験豊富なデジタル仲間に変えることであり、一回一回慎重に作られたプロンプトなのだ。

将来的には、これらのエージェントが、最も詳細なプロンプトベースのルールブックを超えて進化し、行動の結果から真に「学習」できるようになることを目指している。今日、われわれは経験を綿密にコード化しているが、次のフロンティアには、自律的に戦略を改良できるエージェントが含まれる。エージェントが、仕事を遂行するためのツールやデータにアクセスできるだけでなく、それらの行動が望ましいビジネス成果を達成するための成否に関する継続的なフィードバックにもアクセスできることを想像してみてほしい。例えば、私たちのカレンダーアシスタントは、もし午後12時のミーティングの招待が「ランチに出かけている」という理由で特定のユーザーによって拒否されるのを一貫して観察していれば、開発者が「ユーザーXの正午のミーティングは禁止」というルールを明示的にプログラムしなくても、その個人のためにこのスロットの優先順位を下げたり、あるいは提案を避けたりすることを、時間の経過とともに学習することができます。

次に、この学習能力をより複雑なビジネスプロセスに拡張してみよう。例えば、顧客のオンボーディングやサプライチェーンのロジスティクスのための一連の手順で最初にプログラムされたエージェントは、主要なパフォーマンス指標を測定し、実際の結果を観察することによって、非効率性を特定したり、より最適な経路を発見し始めることができる。時間が経つにつれて、アプローチを微妙に調整したり、ステップの優先順位を変えたり、あるいは開発者が最初に設計した基本プロセスの修正を提案するようになるかもしれない。したがって、将来的には、開発者は単にエージェントの動作を最初に設計するだけでなく、エージェントが自身の運用「アルゴリズム」を徐々に洗練・最適化し、ビジネス目標を達成するための真の意味でダイナミックな学習パートナーとなるようなシステムを育成する立場になるかもしれない。