Dynamic Planner：複雑な依頼を段階的な計画に変える AI

たいていの会話に計画は要りません。エージェントに価格や営業時間、あるいは一つのやり方を尋ねる人には、プロジェクトではなく直接の答えを返すべきです。しかし、いくつかの会話は違います。ユーザーはまとまった一つのことを成し遂げようとしていて——会社を登記する、ビザを申請する、破損した家具のクレームを解決する——どこから始めればよいのか、明らかに分かっていません。Dynamic Planner はまさにその瞬間のために存在します。その一つの会話を一時的なストーリーライン（入れ子になった、チェックリスト駆動の計画）に変え、エージェントがそれを一歩ずつ歩みます。

これは Pro の機能で、テナントごとに切り替えられます。計画づくりを行うモデルは、会話の中で選ばれるのではなく、プラットフォーム運営者がテナントごとに割り当てます——だからこそ、データの所在に制約のあるテナントだけをローカルや地域内のモデルに向け、ほかのテナントはホスト型のままにできます。

計画はいつ起動するのか

モデルが「自分で判断して」起動することは決してなく、ユーザーが任意の計画を注文できる自由入力欄から起動することもありません。入り口はちょうど三つで、決定性の高い順に並べるとこうなります。

1. 展開可能なストーリーラインのステップ。 テナントが、著したストーリーラインのあるステップを展開可能と印を付けます。ユーザーがそこに到達すると、エージェントはそのステップをサブ計画へ展開することを提案します。判断は設計時に著者がすでに済ませており、運任せの部分はありません。
2. ユーザーが提案を受け入れる。 どの計画も確認カード（ほかの場所でも使われているのと同じアスクフォームの UI）から始まります。ユーザーはいつでも断ることができ、断られればエージェントはそのセッションの中で再び尋ねません。
3. エスカレーションの判定。 ストーリーラインの外では、専用の小さなモデル呼び出しが毎ターンを見張り、三つの軸——後述——で採点します。三つすべてが通ったときにだけ、ユーザーは提案を目にします。メインのチャットモデルが何かを起動し忘れずにいることに頼ることは、決してありません。判定はエンジンが行う、強制された構造化された呼び出しです。

テナントが著したストーリーラインは常に優先されます。それが会話を駆動している間、プランナーは沈黙します。手で作られたプロセスが、生成されたプロセスに勝ちます。

三つの軸によるエスカレーション判定

判定はタスクの複雑さ、ユーザーの戸惑い、領域の適合を評価し、三つすべてが成り立たなければなりません。ここがこの機能の核心なので、実際のロジックを例とともに示します。

1. 複雑さ——これは本当に複数ステップか？ そのタスクは、完了までに複数のステップ、複数の書類、あるいは複数のターンを要するはずです。一つの質問は計画ではありません。

• ✅ 「EC 向けに米国法人を立ち上げたいのですが、何が必要なのかまったく分かりません」
• ❌ 「デラウェア州の登記費用はいくらですか？」——価格の確認。直接答える
• ❌ 「フォーム SS-4 の 7b 行はどう記入しますか？」——ユーザーがすでに回している手続きの、一つの具体的なステップ

2. 戸惑い——ユーザーは順を追って案内してほしいのか？ 手がかりはこうです。「そもそもどこから始めれば」「何を用意すればいいですか」「全体を通して案内してください」「もう全部は追いきれません」。手続きを分かっていて鎖の一つの環について尋ねる人は、戸惑っていません——計画ではなく、その環を渡してください。

• ✅ 「上司から米国子会社の設立を任されたのですが、こういうことをやったことがありません」
• ✅ 「登記は終わりました——次は何ですか？ 年次報告？ 税務？ 自分では整理しきれないので、代わりに追ってほしいです」
• ❌ 「書類は揃っています。提出先だけ教えてください」——把握できており、戸惑ってはいない

3. 領域の適合——それはこのエージェントの仕事か？ ユーザーが「計画」という言葉を口にしても、それでゲートは開きません。テナントは会話ごとに費用を払っています。会社設立のためのエージェントは、どれほど丁寧に頼まれても、汎用の個人アシスタントになることを断ります。

• ❌ 「三か月のフィットネス計画を、週ごとに詳しく作ってください」——領域外、断る
• ❌ 「ヨーロッパ10日間の旅程を順を追って計画してください」——領域外、断る

生成される計画そのものも領域に制約されます。プランナーはエージェントの担当範囲を受け取り、すべてのステップをその中にとどめなければなりません。

「はい」の後に何が起こるか

確率的な瞬間は計画づくりだけで、それは一度だけ起こります。プランナーのモデルが、計画を構造化データとして起草します——ステップ、ステップごとの指示、何を集めるかのチェックリスト、完了の基準。その草案は、ほかのストーリーラインのグラフと同じように検証されます（不正な計画は再試行され、それでも駄目ならフォールバックのモデルへ回されます。検証を通らない計画は、そもそも走りません）。恒常的な境界のテンプレートが、すべてのステップに決定的に刻み込まれます——矛盾は指摘しなければならない、そのステップのリストにないものを推奨してはならない、承認や価格の約束をしてはならない——ので、ガードレールがプランナーのモデルの書き忘れに左右されることは決してありません。

そこから先の実行は、ストーリーラインのエンジンがいつもどおりのことをするだけです。1ターンに一つの集中したステップ、証拠があるときにだけチェックの入るチェックリスト項目、バナーに表示される進捗、細い進捗バー、そしてエンジンが描画するステップ一覧——だから目に見えているものは実際の状態であって、モデルがそれをどう記憶しているかではありません。計画は入れ子で走ります。ストーリーラインのステップが計画へ展開された場合、計画が完了すると、親のストーリーラインはまさに中断した場所から再開します。