Start
担当者が 1 件を選ぶ
問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。 から 1 件を選び、対象画面、社内 tool、AI に渡せる情報、人間に戻す判断を固定します。
Customer Operations
チケット、契約情報、FAQ、自社 admin を見ながら回答を作っている。AI で一次回答を速くしたいが、顧客情報の露出、誤送信、返金判断の責任境界が曖昧。

Problem
チケット、契約情報、FAQ、自社 admin を見ながら回答を作っている。AI で一次回答を速くしたいが、顧客情報の露出、誤送信、返金判断の責任境界が曖昧。
問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。
よくある問い合わせカテゴリを 1 つ選び、回答下書きと送信前承認を検証します。返金や契約変更は実行せず、承認 UI と audit をレビュー対象にします。
Day In The Life
業務詳細では、担当者が何を持ち込み、AI がどこまで進め、人間がどこで止め、 最後に何を証拠として残すかを時系列で確認します。
Start
問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。 から 1 件を選び、対象画面、社内 tool、AI に渡せる情報、人間に戻す判断を固定します。
Assist
Agent Foundry で CS 調査 agent を定義する。Browser がログイン済み admin とチケット画面を read-only で参照する。AI が回答文、社内メモ、返金可否の根拠を下書きする
Gate
メール / チケット送信 / 返金実行 / 契約変更 / 登録情報変更 は approval、差戻し、保留、または人間確認に戻します。
Review
一次回答時間 / 送信前 approval / 拒否理由 / 問い合わせ履歴の再利用 を検証の evidence として並べ、次の展開可否を決めます。

Operational Evidence Board
担当者が見たもの、AI が出した下書き、人間が止めた判断、レビュー会議に出す証拠を 1 つの board にします。これにより「便利そう」ではなく、運用に入れてよいかを判断できます。
Ticket
CS 担当がチケット ID、顧客要望、参照してよい FAQ / 契約情報を指定する。
AI は契約状況、過去対応、FAQ を読み、回答文、社内メモ、返金可否の根拠を下書きする。
メール送信、返金、契約変更、顧客情報更新は approval 待ちにする。
一次回答時間、下書き修正率、送信前 approval、返金拒否理由を比較する。
Escalation
担当者が AI の根拠を読み、返金条件に不足があれば承認者に escalate する。
AI は返金可、返金不可、追加確認の理由を分け、再下書き候補を出す。
承認者が拒否した場合、拒否理由を AI に返し、送信ではなく再下書きに戻す。
拒否理由、再下書き品質、SLA 影響、返金実行が止まった audit を残す。
Rollout
CS Ops が対象カテゴリを 1 つ選び、採用された回答と修正理由を agent definition に反映する。
Agent Foundry が version、tool call、run history、waiting_input を保持する。
未承認 draft の deploy と highly restricted data を扱う agent を止める。
採用率、修正理由、agent version、送信 / 返金 approval を部門展開の判断に使う。
Before / After / Recovery
利用前の不安は、効果よりも「失敗した時に止められるか」で出ます。利用前、運用後、 失敗時、レビュー会議で見る材料を並べます。
チケット、契約情報、FAQ、自社 admin を見ながら回答を作っている。AI で一次回答を速くしたいが、顧客情報の露出、誤送信、返金判断の責任境界が曖昧。
Agent Foundry で CS 調査 agent を定義する。Browser がログイン済み admin とチケット画面を read-only で参照する。AI が回答文、社内メモ、返金可否の根拠を下書きする。送信、返金、登録、契約変更は承認待ちにして担当者へ戻す。
回答根拠が不足している場合は送信せず調査メモに戻す / 返金条件が曖昧な場合は承認者に escalate する / 顧客情報が mask されない場合は AI 呼び出しを拒否する
現場指標: 一次回答時間、下書き修正率、SLA 影響 / 統制指標: 送信 / 返金 approval、顧客情報 mask、拒否理由 / 導入判断: CS 品質を落とさず、責任境界を人間へ戻せるか
Scenario Walkthrough
利用検討で必要なのは、抽象的な自動化ではなく「この 1 件がどう変わるか」です。現在の作業、viyv 後の処理、解決する問題、レビュー会議で見る判断材料を分けます。

Case
CS 担当者はチケット、契約情報、FAQ、admin、過去対応を見て回答を作る。AI 下書きは便利だが、誤送信、返金実行、顧客情報の露出が怖く、管理者が許可しにくい。
With viyv
CS agent が契約状況と FAQ を読み、回答文、社内メモ、返金可否の根拠を下書きする。メール送信、返金、契約変更は approval 待ちにして、人間が修正理由を残す。
Problem Solved
一次回答の作成時間を削りながら、返金と送信の責任境界を曖昧にしない。拒否理由が AI の再下書きに戻るため、現場のレビュー負荷も測れる。
Decision Moment
対象カテゴリ 30 件で一次回答時間、下書き修正率、SLA 影響、送信前 approval を見て、CS 部門展開へ進むかを決める。
Concrete Run
demo ではなく、現場が毎日扱う 1 件を起点にします。入力、AI の作業、人間に戻す判断、 残す成果物を分けると、検証の範囲が曖昧になりません。
Input
問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。 を対象に、担当者、対象画面、社内 tool、AI に渡してよい情報を 1 つの範囲に固定します。
AI Work
Agent Foundry で CS 調査 agent を定義する。Browser がログイン済み admin とチケット画面を read-only で参照する。AI が回答文、社内メモ、返金可否の根拠を下書きする
Human Gate
メール / チケット送信 / 返金実行 / 契約変更 / 登録情報変更
Output
回答下書き / 社内調査メモ / 返金判断メモ / 拒否理由
Operator Runbook
現場の操作を増やさず、AI の下書きと確認メモを使います。責任が残る操作は approval に戻し、失敗時の扱いも検証条件に入れます。
Evidence Packet
利用前に「AI が便利だった」ではなく、業務効果、統制、責任境界、展開条件を並べます。
CS 回答 / 返金判断 を 1 workflow として、owner は CS Ops、サポート、業務企画 に置きます。
現場指標: 一次回答時間、下書き修正率、SLA 影響
統制指標: 送信 / 返金 approval、顧客情報 mask、拒否理由
導入判断: CS 品質を落とさず、責任境界を人間へ戻せるか
Stakeholder Review
業務部門、情シス、セキュリティ、管理部門が見る論点を分け、検証 の受け入れ条件に変えます。
業務責任者
チケット ID と顧客の要望を AI に渡す / AI が契約状況、FAQ、過去対応を確認した要約を見る / 回答文を修正し、送信前 approval で最終確認する を日次運用に置き、メール / チケット送信 / 返金実行 / 契約変更 / 登録情報変更 は承認待ちに戻します。
一次回答時間 / 送信前 approval
情シス / AI platform
viyv Agent Foundry / viyv Browser / viyv DB を使い、admin read-only / 送信 / 返金 HITL / 電話番号 mask を最初の境界にします。
送信前 approval / 拒否理由 / 問い合わせ履歴の再利用
セキュリティ / 法務
admin read-only / 送信 / 返金 HITL / 電話番号 mask / agent version を検証の統制として固定し、失敗時は 回答根拠が不足している場合は送信せず調査メモに戻す。
送信と返金が全件 approval 待ちになる / 拒否理由が AI の再下書きに反映される
管理部門 / 経営
導入判断: CS 品質を落とさず、責任境界を人間へ戻せるか
対象カテゴリで一次回答時間を比較できる / 送信と返金が全件 approval 待ちになる / 拒否理由が AI の再下書きに反映される
Product Setup
最初から全製品を入れる必要はありません。業務の入力、AI に任せる作業、止める操作に合わせて scope を決めます。
Next Step
対象画面、社内 tool、人間に戻す判断、判断材料を 30 日の検証計画に落とします。