アスクフォーム（チャット内フォーム）とは？
エージェントが会話の途中で組み立てる小さなフォーム——選択肢、数値、日付——タイプして答える質問の段落ではなく、タップするものとして描画される。
たいていの商談には、エージェントが役立つ前に四つの特定のものを必要とする瞬間があります。通貨、金額、期間、日付です。
散文として尋ねると、それは四つの質問を含む段落になります。返ってくるのは、そのうち二つへの、あなたが尋ねていない順序での、金額が「160万くらい」と書かれた答えです。それから追いの質問、それがドルだったかどうかの確認。
アスクフォームはそれをいくつかのタップに置き換えます。
エージェントが組み立てられるもの
エージェントはフォームそのものを、会話の途中で、その瞬間に必要なものから書きます。あらかじめ設計してトリガーに配線したフォームではありません。
一つのフォームに混ぜられる、五種類のフィールド：
- single と multi——列挙可能な選択肢からの選択
- number——単位と範囲付き。桁区切りは顧客に表示され、エージェントが値を見る前に取り除かれるので、誰も「160万」を解釈しなくて済む
- date——許容範囲付き
- text——本当に自由回答なその一つのために
顧客が記入し、送信すると、答えがメッセージとして戻り、エージェントはそこから続けます。
面白いのは抑制の部分
この手の機能の誘惑は、常に使ってしまうことで、あらゆる質問にフォームで答えるエージェントは、決してフォームを使わないエージェントより悪いものです。
そこでエージェントは、選択が本当に列挙可能で、実質的な選択肢が少なくとも二つあり、前に進むために必要なときにだけフォームを使うよう指示されています。開かれた質問——「あなたの状況を教えてください」——は質問のままです。締めの挨拶も同様です。誰も「他に何かありますか？」のラジオボタンを望みませんし、「会話を終える」と書かれた単一選択肢を提示するフォームは、それが置き換えた文よりも悪いものです。
なぜビジネスエージェントにとって重要か
データが構造化されて戻ってきます。 数値は解釈すべき語句ではなく数値であり、次のステップが整数を期待する見積もりツールの呼び出しであるときに効いてきます。
同じ地点まで少ないターンで。 6メッセージの確認ではなく、一度のやり取りで四つの事実——そして余計なやり取りはどれも、顧客が離れていける場所です。
顧客の言語で機能します。 エージェントは他のすべてと同じようにラベルを書くので、スペイン語の問い合わせはスペイン語のフォームを受け取り、誰もその5言語版を保守しません。
答えはどこへ行くか
送信されたフォームはデータベース書き込みではありません——エージェントが推論するメッセージとして戻ってきます。それが重要なのは、次のステップがたいてい他の部品の一つだからです。MCP ツールにそのまま渡される数値、Skillのどの分岐が走るかを決める選択肢の組、あるいはその顧客のスペースに記憶され、来月また尋ねなくて済む事実。
フォームはエージェントごとに有効化されるので、質問に答えるだけであるべきエージェントが、質問を始める能力を得ることは決してありません。
これはエージェントがモデルに何を加えるかの良い例です。モデルは何を尋ねるかを決めます。それをタップできるものとして描画し、戻ってきたものを検証し、きれいな数値を次のツールへ渡すのは、すべてハーネスです。
エージェントへのページごとのブリーフィング——あらかじめ知っておくべき背景、開始の一言、いくつかの推奨質問——訪問者がチャットを開いた URL から自動的に選ばれる。
エージェントが特定の未来の瞬間に対してコミットする仕事——送ると決めたフォローアップや、繰り返しのリマインダー——誰かが先に話しかけるのを待つのではなく、スケジューラーが時間どおりに実行する。
一人の顧客の会話、文書、記憶を保持する隔離されたコンテナ——データベースレベルで強制されるため、ある顧客の資料が別の顧客の会話に現れることはない。
ユーザーが提供したテキスト、またはエージェントが読み取るドキュメント、Webページ、メールに隠されたテキストが、コンテンツではなく新しい指示としてモデルに扱われる攻撃です。これにより、エージェントはルールを放棄したり、アイデンティティを変更したり、システムプロンプトを漏洩させたりします。攻撃は正当な入力と同じチャネルを通じて到達するため、より厳格なプロンプトを作成しても修正できません。有効な防御策は、モデルの前と後に配置されます。