検証済みの範囲だけを公開する

公開は、定義した利用者に特定の Agent version を使わせる判断です。Editor の完成度ではなく、確認した動作をもとに判断します。

リリース境界を確認する

公開前に、専門家または責任者が次を確認します。

最初の仕事と期待する結果が明確である。
このリリースの must-pass case が合格している。
Scope 外と高リスクの状況に承認済み fallback がある。
有効な情報源とツールが公開 scope に含まれる。
人による返信が必要な会話の担当者が決まっている。
Pilot チームが既知の制限を理解している。

決まっていない項目がある場合は、利用者を広げずテストを続けます。

リリース記録を準備する

Live 状態を変更する前に、次を記録します。

公開する Agent と正確な version
判断に使った case set、結果、must-pass 条件
対応する仕事、既知の制約、承認済み fallback
チャネル、アクセスモード、最初の利用者
有人返信を担当する運用担当者
Scope を承認した専門家または責任者と、実際に公開操作を行う人
Pilot を停止する条件、または以前の検証済み version に戻す条件

チームが通常使う変更記録または共有文書に残します。これは公開判断の証拠であり、pilot が事業成果を生むという主張ではありません。

ステップ1：未公開のチャネルを作る

最も早く制御された pilot を始めるには、Web チャネルを使います。

workspace で チャネル を選択します。
新規チャネル をクリックします。
画面で求められた場合は、検証済みの Agent から始めます。
分かりやすい名前と安定した slug を入力します。
種類に Web Application を選びます。
チャネルを作成し、まだ 公開 はクリックしません。

新しく作成したチャネルは、公開するまで live になりません。公開 URL には slug が使われるため、共有に適したものを選び、変更する前に既存リンクを確認します。

他の公開方法は安全に公開を参照してください。

ステップ2：公開前にアクセスを制限する

チャネルを live にする前に、顧客 で workspace を ホワイトリスト に設定します。

現在の顧客リストを確認します。既存 workspace を ホワイトリスト に切り替えると、現在の顧客はホワイトリストメンバーになります。
最初は内部テスト用 identity だけを、正しいチャネル種別と External User ID で追加します。
Web チャネル設定の 匿名アクセスを許可 をオフにします。有効にすると、Web または Widget の匿名利用者はホワイトリスト制限を回避します。

URL に到達した人を全員許可する場合だけ オープン を使います。

→ 顧客

ステップ3：検証済み Agent version を公開する

Agent version とチャネルは別々に公開します。

Agent を公開する前に、この workspace にアクセス範囲の広い live チャネルがないか確認します。最初の pilot では専用 workspace が最も安全です。Agent を公開すると、live workspace チャネルから利用可能になる場合があります。

AIエージェント を選択します。
検証した Agent を開きます。
現在の draft と version を確認します。
公開 をクリックします。

Version が公開されると、操作は 公開取り消し に変わります。その後の編集は、更新した version を再度公開するまで利用者に届きません。

ステップ4：チャネルを公開して自分でテストする

チャネルに戻り、アクセス設定と対象 Agent を確認してから 公開 をクリックします。

この段階では内部テスト用 identity だけを使います。

その利用者として live 体験を開く。
Agent の名前、説明、入力欄が利用できることを確認する。
Core scenario を一つ実行する。
重要な boundary を一つ実行する。
会話 に記録されることを確認する。
handoff、form、tool action が期待どおり動くことを確認する。

これにより、Test Suite では実行されない公開とチャネルの問題を見つけられます。安全に確認できない場合は、pilot 利用者を招待する前にチャネルの 公開取り消し を行います。

Client に No agents available と表示される場合

チャネルは公開されていても、対象 Agent version が公開されていない可能性があります。AIエージェント に戻り、検証済み version を公開して client を更新します。

ステップ5：pilot 利用者を追加する

内部確認に合格した後、承認済みの pilot identity をホワイトリストに追加し、そのグループだけに URL を共有します。最初の利用者は、運用担当者が重要な会話を確認し handoff に対応できる範囲にします。

実際の仕事を判断できる人に、次を試してもらいます。

Agent が対応すべき通常の状況
重要な境界または例外
公開 scope にツールがある場合は、そのアクション

特定の回答が誤っている場合は、Improve を使い、結果がどう違うべきだったかを書いてもらいます。実装原因の診断は不要です。

有用なフィードバックは次を示します。

誤っていた回答またはアクション
不足していた質問、根拠、次の行動、handoff
根拠のない示唆や約束
受け入れ可能な結果が行うべきだったこと

ステップ6：維持、修正、拡張を決める

最初の実利用後、次のいずれかを選びます。

維持：公開 scope は適切であり、観察を続ける。
修正：現在の must-pass 動作に限定した修正が必要である。
拡張：繰り返し発生する新しい状況を次の version の case にする。

すべての新しい質問を scope 拡張の許可として扱わないでください。新しい case と Standard が準備できるまで、未検証の仕事には承認済み fallback を使います。

停止または以前の version に戻す

チャネルアクセスを停止する：チャネルで 公開取り消し を使います。Draft 設定を削除せず、チャネルを offline にします。
Agent version を停止する：どの live チャネルもその version を使うべきでない場合は、Agent の公開を取り消します。
検証済み動作に戻す：以前に保存し検証した Agent version を選び、case の証拠を確認して、その version を再度公開します。
インシデントを記録する：停止の理由、判断した人、影響する可能性がある利用者または会話、再公開前に合格すべき条件を残します。

停止または切り戻し後は、pilot アクセスを戻す前に内部の end-to-end check を再実行します。