顧客接点の
エージェンティック変革
「ユースケースが先か、エージェントが先か」。ボード討議で浮かんだこの論点を、
思考の順序と資産の持ち方という2つの問いに分解し、v1のAgent整理と統合したフレームとしてまとめる。
フロー（思考・提案）はWhat起点、
ストック（資産・開発）はHow単位で持つ。
どちらを「先」にするかは一つに決めなくてよい。ユースケースは価値の単位、エージェントは資産の単位。
両者はCapabilityカタログと横断会議体で接続する。有人対応は上位概念ではなく、AIファーストのフロー後段に置く。
論点の分解 — 「先」には2つの意味がある
ユースケース起点（ビジネス側の思考）とエージェント起点（開発側の思考）は対立しているように見える。
実際には性質の異なる2つの問いが混ざっており、分けて答えると対立は解消する。
価値を考え、提案する順序は？
→ ユースケース起点（What → How）
顧客は「Phone Agentが欲しい」のではなく「CS対応を変革したい」。What（変革したい業務）をJourneyに分解し、各ステップを担う手段としてエージェントが決まる。
開発資産・責任をどの単位で持つ？
→ エージェント単位（How）
エージェント（チャネル×手段）は数が少なく長寿命。ユースケース単位で資産を持つとCapabilityが重複開発され、顧客体験も分断される。
Agentの定義 — 5つのプロダクトラインとv2での再解釈
v1で定義した5つのAgent。名前は引き続き使えるが、v2の「チャネル×手段」モデルにより
AvatarとOperatorは位置づけが変わる。
- Site Agentは「Webサイト上の接客Agent」という意味で採用。
- v1では「Web Site」だとAvatar Agentと軸がぶつかるため命名を避けた。v2ではavatarを手段側に置くことでこの衝突自体が解消される。
- Operator Agentは有人チャット / 有人ボイスの支援を含む。v2では特定チャネルに紐づかない全Agent共通の部品群として扱う。
全体構造の考え方 — Agent × Use Case × Capability
AgentとUse Caseは1対1で結びつけない。Agentはプロダクトライン、Use Caseは各Agent上で提供するソリューション、
CapabilityはUse Caseを支える共通機能。3つの掛け算で全体を捉える。
手段（How）の分解 — 顧客接点チャネル × コミュニケーション手段
| 顧客接点チャネル | chat | voice | avatar |
|---|---|---|---|
| LINE | ○ | — | — |
| WEB（site） | ○ | ○ | ○ |
| 電話 | — | ○ | — |
| メール | ○ | — | — |
| アプリ | ○ | ○ | ○ |
※ 結線は例。対象顧客・案件に応じて組み合わせを選定する。
整理フレーム — Use Case → Journey → Agent → Capability → Backlog
思考はWhatから流れ、成果物はHow側のバックログに蓄積される。
この5ステップがフロー（価値の流れ）とストック（資産の置き場）をつなぐ整理の型になる。
例 — Customer Support を分解する
整理フレームを Customer Support に適用した例。
Use Case を6つのJourneyに分解して各Journeyを担うAgentを割り当てる。1つのUse Caseに複数のAgentが関与する。
| Journey | Site | Phone | LINE | avatar手段 | 有人接続 | 概要 |
|---|---|---|---|---|---|---|
| 1. 問い合わせ受付 | ○ | ○ | ○ | — | — | 各接点で問い合わせを受け付ける |
| 2. FAQ一次回答 | ○ | ○ | ○ | — | — | FAQ検索・一次回答 |
| 3. 注文 / 契約照会 | ○ | ○ | ○ | — | — | 注文・契約情報の確認・案内 |
| 4. 変更 / キャンセル受付 | ○ | ○ | ○ | — | — | 変更・キャンセルの受付 |
| 5. エスカレーション | — | — | — | — | ○ | 有人対応へのエスカレーション |
| 6. 対応後フォロー | ○ | — | ○ | — | ○ | 対応後のフォロー・アンケートなど |
※ avatar手段は、対面に近い体験が必要なシナリオ（カウンセリング・面談など）で追加されるケースを想定。
セルごとのCapability分解 — 「2. FAQ一次回答」の場合
同じJourneyでも、担うAgentによって必要なCapabilityは異なる。
共通部品化できるもの（FAQ検索エンジン等）と、Agent固有のもの（IVR連携等）を切り分けてバックログに落とす。
Site Agent（WEB × chat / voice / avatar）
- FAQ検索
- チャットUI・履歴保持
- 認証前の一般的な回答
Phone Agent（電話 × voice）
- 音声FAQ回答・読み上げ
- IVR連携・ガイダンス
LINE Agent（LINE × chat）
- テキストFAQ回答
- リッチメニュー誘導
有人接続（共通Capability群）
- エスカレーション時の会話要約
- 回答案提案・承認送信支援
プロダクト開発の考え方 — 開発の主語は各Agent
各Agentは「その接点での対話体験を最適化するプロダクト」として開発する。
各Agentの上で、複数のUse Caseを開発していく。
顧客提案の考え方 — 提案の主語はUse Case
顧客との会話は基本的にUse Case起点で始まる。
ただしUse CaseをAgentに直接結びつけず、Journeyに分解してから手段を決める。
顧客の入り口はいつもWhat
そのため、以下の流れで整理する
AIファーストと有人接続
有人は上位概念ではなく、対応フローの後段に位置づける。
あくまでAIでの完結を目指し、完結が難しいケースではAIの先に有人が控える設計とする。
できない場合
開発責任の持ち方 — 二層の責任と接続点
開発責任は各Agentごとに存在する前提。
そのうえで、複数Agentにまたがるユースケースの優先順位を横断で決める仕組みを持つ。
全体のまとめ — 整理の型とポイント
- 開発は各Agent起点、提案はUse Case起点で考える
- Use CaseをJourneyに分解し、担当Agentを割り当てる
- 必要なCapabilityを定義し、各AgentのBacklogに落とす
- 開発責任は各Agentが持ち、横断ユースケースは会議体などで推進する