Plan-Then-Execute パターンは、まず計画を固定することで LLM エージェントを制約する。エージェントは、信頼できないコンテンツに触れる前に、どのツール呼び出しを行うかを決め、そのうえでその計画を実行する。ツールの出力はエージェントに戻ることが許されるが、それが届くのは、エージェントがすでに実行を確定させた内容を変えるには遅すぎる時点である。プロンプトインジェクションから LLM エージェントを守るためのデザインパターン の要約によれば、論文はこれを、フィードバックをまったく受け付けないやり方よりも許容度の高いアプローチとして説明している。ツールの出力からエージェントへのフィードバックを認めつつ、それらの出力がエージェントの取る行動の選択に影響するのを防ぐのである。
用法
挙げられている具体例は、今日の予定を指定された受信者に送るという依頼であり、これは事前に、カレンダーの読み取りと、その受信者宛てのメールの書き込みとして計画される。保護は部分的であり、その境界は明確である。カレンダーの読み取りで返されたテキストは送信されるメールの本文を汚染するかもしれないが、メールの送信先を変えることはできない。受信者は、信頼できないものが何も読まれないうちに確定していたからである。
内容は危険にさらされるが制御フローはさらされない、というこの切り分けこそが、このパターンがもたらすものである。フィードバックをまったく受け付けないパターンよりも高度な一連の行動を可能にしつつ、ある行動が指示を持ち込み、それが後で計画外の有害な行動を引き起こすというリスクを伴わない。
適用される場面
このパターンが適用されるのは、外部データを参照する前に、ユーザーの依頼だけから有用な計画を立てられる場面である。どのツールを実行するか、そしてどのような取り消し不能なパラメータで実行するかという重大な決定がすべて、計画の時点で確定できることを前提としている。適切な次のステップが、取得した内容に本当に依存する場面では機能しない。信頼できないコンテンツを読んだ後に計画を立て直すエージェントは、このパターンが拠って立つ性質を手放してしまっているからである。また、後のステップの内容は無防備なままなので、攻撃者が与えうる被害がメッセージの送り先ではなくメッセージの内容にある場合には、適用を誤っていることになる。
これは、レビュー対象の論文において、順位付けされたリストとしてではなく、エージェントの有用性と プロンプトインジェクション への耐性とのトレードオフとしてまとめて提示されている 6 つのパターンの 1 つである。ここで参照できる説明は、論文そのものではなく、その論文のレビュアーによるものである。
関連用語
- Action-Selector パターン — より厳格な隣接パターンで、ツールの出力をまったく受け付けない
- LLM Map-Reduce パターン — 信頼できないコンテンツをサブエージェント経由で処理することで、このパターンが残す無防備な部分に対処する
- プロンプトインジェクション — 制約の対象となる攻撃
- プロンプトインジェクションから LLM エージェントを守るためのデザインパターン — この説明の出典