コンテンツにスキップ

安定した範囲を公開する

最初の検証済みシナリオが Test Suite で安定してから公開します。実際に使う順番は、Agent version を公開し、Web channel を作って公開し、自分で web client を確認し、そのあと数人の stakeholder に検証済み scope だけを試してもらって、気になった返答に直接フィードバックを残してもらう流れです。

ステップ1：先に Agent のバージョンを公開する

channel の公開と Agent version の公開は別です。channel を作る前や URL を共有する前に、Edit Agents に戻って対象 Agent を開き、Agent Editor の Publish をクリックします。

公開が完了すると、ボタンは Unpublish に変わります。これが web client から Agent を実際に読み込める状態になった合図です。

エディターで Agent version の公開が完了した状態

web client に No agents available と出る場合

channel は公開されていますが、Agent バージョンはまだ公開されていません。Edit Agents に戻って現在のバージョンを公開し、公開 URL を再読み込みしてください。

あとで Agent を更新した場合も、web client に反映させるにはもう一度 Publish が必要です。

ステップ2：Web channel を作る

  1. workspace で Channels タブを開きます。
  2. New Channel をクリックします。
  3. 検証済みの Agent 用に channel を作成します。

現在の workspace にある Channels の空状態

ステップ3：分かりやすい slug を決める

channel 作成時に、次を入力します。

  • Name：customer-facing な分かりやすい名前
  • Slug：シンプルで安定した slug
  • Type：Web Application

最初の案が欲しければ Auto-fill from name を使えます。公開 URL にはこの slug が使われるため、そのまま共有して違和感のない名前にしてください。

channel 名、slug、Type を入力した作成ダイアログ

ステップ4：channel を公開する

channel を作成したら、次を行います。

  1. channel の詳細ページを開く
  2. Overview で slug 付き URL を確認する
  3. Publish をクリックする
  4. 公開 URL をコピーして、テスターに送れる状態にする

公開後の Publish Status に表示される live URL

ステップ5：まず自分で web client を開く

ほかの人に送る前に、まず自分で確認します。

  1. 公開 URL を開く
  2. Agent 名、説明、チャット入力欄が見えることを確認する
  3. 簡単なメッセージを 1 件送り、公開画面が本当に動くか確かめる

設定が正しければ、stakeholder にはこの画面が見えます。

公開済み web client が最初のテスト質問に返答している状態

ステップ6：stakeholder に検証済み scope を試してもらう

3 人から 4 人の stakeholder に、同じ検証済み scope を別の角度から試してもらいます。

  • 直接答えるべき core scenario
  • handoff、refusal、form に流すべき boundary scenario
  • first version に tool がある場合は action scenario
  • 分かりにくい、generic すぎる、言い過ぎ、情報不足だと感じた返答へのフィードバック

おかしいと感じた返答があれば、その返答で Improve を押して、何が気になったかを自然な言葉で書いてもらいます。stakeholder 自身が原因まで分析する必要はありません。generic すぎる。human callback をもっと早く出してほしい。 くらいの短いコメントで十分です。

公開済み web client で stakeholder が返答に直接フィードバックを残している状態

最初の公開は小さく、管理しやすい範囲で十分です。広く出すことより、次に扱うべき scenario を見つけることが重要です。未検証の scenario を聞かれたら、Agent はすでにテストした安全な fallback を使うべきです。

良い外部フィードバックとは

役に立つ stakeholder のフィードバックは、たいてい次のどれかに答えています。

  • どの返答が問題だったのか
  • もっと別の質問をすべきか、早く引き継ぐべきか、generic すぎたのか
  • チームが承認していない内容をにおわせていないか
  • stakeholder の立場から見て、より良い返答は何をすべきだったか

アクセス制御を強めるのは後からでよい

最初の pilot は小さく始めてください。あとでより厳密に制御したくなったら、利用者アクセス の whitelist mode を使います。

任意の強化: Request Form

検証済みの boundary または action scenario で構造化情報を集める必要があるなら、Request Form を追加します。scenario が必要性を示していないなら、first pass では不要です。

高度な公開方法

自分の製品やバックエンドから Agent を呼び出したい場合は API Access を使います。最初の pilot では Channels から始めるのが簡単です。

次のステップ