Business Case Packet
相談前に送るもの
対象 workflow、月間件数、担当者数、1 件あたりの現在時間、過去データ 10〜30 件、除外したい業務。
viyv 側で設計するもの
KYC 10 件、問い合わせ 30 件、read-only API 1 つなど、30 日で検証できる単位へ scope を落とす。
判断に残す証拠
Before baseline、対象件数、現場 owner、Go / Hold / No-Go の最初の仮説。
PoC Design
AI 活用を、判断に足る検証へ変える。
viyv の PoC は、動くデモを作るだけではありません。対象業務、AI に任せる範囲、人間に戻す判断、 統制、監査証跡を最初から決め、社内で説明できる材料を作ります。
PoC Intake Builder
初回相談を、30 日 PoC の設計図に変える。
相談前に完璧な要件定義は不要です。ただし、業務ケース、AI に任せる作業、人間に戻す操作、判断の証拠を 4 つの packet に分けると、初回 meeting で PoC scope と合格条件まで 固定できます。
AI Task Boundary
相談前に送るもの
AI に任せたい読み取り、照合、要約、回答下書き、tool 呼び出し、schema 変更、agent 実行の候補。
viyv 側で設計するもの
AI がやる作業と、AI が絶対に実行しない操作を分け、Browser / MCP / DB / Agent の最小構成を選ぶ。
判断に残す証拠
AI output、下書き修正率、参照した画面 / tool / data、実行しなかった操作。
Human Gate Plan
相談前に送るもの
送信、返金、登録、振込、金額変更、支払先変更、rollback、agent publish の承認者と拒否理由。
viyv 側で設計するもの
HITL approval、read-only policy、dangerous action、拒否理由 taxonomy を PoC 開始前に設定する。
判断に残す証拠
approval decision、拒否理由、policy denial、再下書きログ、承認者ごとの責任境界。
Adoption Evidence Packet
相談前に送るもの
判断で見たい業務効果、mask 対象、token owner、audit metadata、Team / Enterprise の条件。
viyv 側で設計するもの
Data / Action / Connector / Agent の証拠を 30 日 runbook に割り当て、最終会議の decision packet にする。
判断に残す証拠
plan recommendation、残リスク、追加 PoC 条件、90 日 rollout、運用条件に入れる制限事項。
Risk Drills
PoC 中に、あえて危険なケースを試す。
成功例だけでは判断に足りません。データ漏れ、危険操作、token revoke、rollback を意図的に起こし、viyv が止めるべき境界を証拠化します。
PII / confidential leak drill
発火させるケース
KYC や CS 画面で、電話番号、住所、口座番号、契約 ID、自由記述欄を含むケースを AI に読ませる。
期待する挙動
mask 対象は AI input へ渡らず、渡った項目と渡らなかった項目を Data boundary packet に残せる。
失敗した時
自由記述欄や業務固有 ID が漏れる場合は、mask pattern と対象画面を追加して同じケースで再実行する。
判断への使い方
顧客情報を扱う workflow を Team で始められるか、Enterprise の security review に分けるかを判断する。
Write / money movement drill
発火させるケース
送信、返金、金額変更、支払保留、登録、削除など、AI が最後の操作へ進みそうなケースを意図的に作る。
期待する挙動
操作は approval 待ちになり、承認者、拒否理由、再下書き、policy denial が残る。
失敗した時
approval なしに進む操作があれば、その workflow は No-Go。read-only 範囲に戻して policy を修正する。
判断への使い方
危険操作を人間に戻せる証拠として、業務責任者と内部統制の承認に使う。
Token revoke / connector denial drill
発火させるケース
MCP connector の token を revoke し、Claude / GPT / 社内 agent から同じ tool call を再実行する。
期待する挙動
revoke 後の tool call は失敗し、registration、namespace、metadata-only audit に失敗理由が残る。
失敗した時
client ごとに挙動が違う、または token owner が不明な場合は、Enterprise 条件として governance を詰める。
判断への使い方
unmanaged tunnel ではなく、標準 MCP endpoint として採用できるかの platform 判断に使う。
Schema rollback / agent publish drill
発火させるケース
AI DB の列追加、例外 table 変更、agent definition 更新、publish approval を PoC 中に 1 回発火させる。
期待する挙動
purpose、alter reason、migration reason、rollback、agent version、invocation event が残る。
失敗した時
変更理由や rollback を説明できない場合は、AI アプリを本番 workflow に載せず追加 PoC に戻す。
判断への使い方
AI DB / Agent Foundry を個人実験ではなく、部門運用にできるかの判断に使う。
Day-by-Day Runbook
30 日の PoC を、日ごとの判断に分解する。
30 日後に初めて判断するのでは遅すぎます。各期間で何を実行し、何を証拠として残し、 どの条件なら scope を戻すかを決めて進めます。
Day 1-3
1 workflow と除外条件を固定する
実行すること
KYC 10 件、CS 30 件、read-only API 1 つなど、検証対象と除外する業務を決める。
残す証拠
workflow brief、対象件数、参加者、現在の処理時間、失敗時の影響。
判断
対象が広すぎる場合は、この時点で scope を削る。
Day 4-8
AI の役割と human gate を実装する
実行すること
読み取り、照合、要約、下書きだけを AI に任せ、送信・返金・登録・金額変更を approval に戻す。
残す証拠
AI task list、approval rule、read-only policy、拒否理由 taxonomy。
判断
危険操作を止める owner が決まらない場合は、read-only workflow へ戻す。
Day 9-15
業務ケースで evidence run を回す
実行すること
実データまたは過去データで Before / After を測り、AI output と人間修正を比較する。
残す証拠
処理時間、下書き修正率、再作業、承認待ち、mask 前後、tool metadata。
判断
効果が出ない場合は、AI task ではなく workflow 選定を見直す。
Day 16-22
risk drill を意図的に起こす
実行すること
PII leak、write action、token revoke、schema rollback、agent publish を 1 回ずつ試す。
残す証拠
policy denial、approval decision、revoke failure、rollback、agent event。
判断
止まらない操作や説明できないデータ境界があれば Hold にする。
Day 23-30
Go / Hold / No-Go を判断資料にする
実行すること
業務効果、統制、運用 owner、次の workflow、Team / Enterprise 条件を 1 つの packet にまとめる。
残す証拠
Decision packet、plan recommendation、90 日 rollout、残論点。
判断
Team 開始、Enterprise 条件整理、追加 PoC、No-Go のいずれかを選ぶ。
Intake
最初に決める 4 つのこと。
PoC が曖昧なまま始まると、動いたかどうかだけで終わります。判断に進むには、 最初に検証の境界を決めます。
対象業務
KYC、CS、社内 API 接続、AI アプリ開発など、最初に検証する workflow を 1 つに絞ります。
AI に任せる範囲
読み取り、要約、下書き、tool 呼び出し、schema 変更、agent 実行のどこまでを AI に任せるかを決めます。
人間に戻す判断
送信、決済、削除、承認、登録、返金、振込、rollback など、人間が責任を持つ操作を定義します。
レビューに出す証跡
masking、approval decision、token scope、tool metadata、migration reason、agent event をどの形で見せるか決めます。
Request Brief
相談時に送る情報を、最初から具体化する。
「AI を使いたい」だけでは PoC の設計に進めません。以下が分かると、30 日で検証できる workflow と統制範囲に落とせます。
業務と担当者
対象 workflow、担当部門、利用予定人数、作業頻度、現在 1 件にかかる時間。
使う画面 / tool / data
ログイン済み画面、社内 API、MCP、CSV、DB、agent 実行など、AI が触る対象。
AI に任せたい作業
読み取り、照合、要約、下書き、tool 呼び出し、schema 変更、agent 実行のどこまでか。
必ず人間に戻す操作
送信、返金、登録、承認、振込、金額変更、支払先変更、rollback、agent publish。
扱う機微情報
個人情報、顧客情報、口座番号、契約情報、API key、社内 confidential data、mask したい項目。
判断の証拠
削減したい時間、承認ログ、mask 結果、tool metadata、migration reason、Enterprise 要件。
Example Brief
- 対象業務: CS 返金判断。月 300 件、担当者 6 名、1 件あたり平均 12 分。
- AI に任せたいこと: チケット要約、契約確認、FAQ 照合、回答下書き、返金可否メモ。
- 人間に戻す操作: 顧客への送信、返金実行、契約変更、登録情報変更。
- 使う対象: Zendesk、社内 admin、FAQ、契約 DB。admin は read-only から始めたい。
- 機微情報: 電話番号、住所、カード末尾、契約 ID。AI へ渡る前に mask したい。
- PoC 合格条件: 一次回答時間を比較し、送信と返金が全件 approval 待ちになること。
PoC Consultation Scenarios
初回相談で、何を持ち込めば PoC に落とせるか。
相談時点で完璧な要件は不要です。ただし、対象業務、AI に任せたい作業、人間に戻す判断、判断の証拠が見えていると、30 日で検証できる設計にできます。
KYC / 審査レビューを相談する
持ち込む情報
過去の審査 10 件、確認観点、許可したい KYC / 制裁リスト / 台帳ドメイン、mask したい PII 項目。
初回で固定する範囲
AI は照合メモと差戻理由だけを作り、承認・差戻・凍結・リスクランク変更は実行しない範囲に固定する。
PoC 設計
Browser read-only、PII mask、最終判定 approval、許可外ドメイン denial を最初の policy として設計する。
判断の証拠
確認時間、mask 証跡、approval decision、差戻理由の一貫性を見て、Team で審査補助を始めるか判断する。
CS 回答 / 返金判断を相談する
持ち込む情報
問い合わせカテゴリ 1 つ、過去 30 件、FAQ、契約情報、返金条件、admin 画面、送信前レビューの現行ルール。
初回で固定する範囲
AI は回答文、社内メモ、返金可否の根拠を下書きする。送信、返金、契約変更は approval 待ちに戻す。
PoC 設計
Agent Foundry の CS agent、Browser read-only、顧客情報 mask、送信 / 返金 approval、拒否理由 taxonomy を作る。
判断の証拠
一次回答時間、下書き修正率、送信拒否理由、返金 approval、再下書き品質を見て部門展開を判断する。
社内 MCP connector を相談する
持ち込む情報
read-only API 1 つ、利用部署、AI client、namespace 案、token owner、将来 write tool にしたい操作。
初回で固定する範囲
最初は read-only tool だけを MCP 化し、Claude / GPT / 社内 agent へ同じ endpoint で配れるかを見る。
PoC 設計
viyv MCP の namespace / clearance、Gateway registration、token rotation / revoke、metadata-only audit を設計する。
判断の証拠
tools/list、複数 AI client 接続、token revoke、拒否された tool call、registration audit から Enterprise 条件を判断する。
請求書例外 / AI DB を相談する
持ち込む情報
過去の請求書例外 20 件、請求書、発注書、運用条件、入金 CSV、金額変更 / 支払保留の承認ルール。
初回で固定する範囲
AI は差異候補、例外分類、照合理由、修正案を作る。金額変更、消込、支払保留は実行しない。
PoC 設計
viyv DB の purpose / reason、Browser read-only、金額変更 approval、rollback 実演を PoC 条件に入れる。
判断の証拠
分類再現率、例外処理時間、金額変更 approval、migration reason、rollback を見て本番 workflow 化を判断する。
PoC Templates
最初の検証は、この粒度まで具体化する。
PoC の相談時点で、入力、AI に任せる作業、人間に戻す操作、合格条件が見えていると、実装と判断が速くなります。
KYC / 審査レビュー
入力
顧客 ID、本人確認画面、制裁リスト、顧客台帳、確認観点。
AI の役割
照合、差分要約、審査メモの下書き。最終判定は実行しない。
人間に戻す操作
承認、差戻、凍結、リスクランク変更。
合格条件
10 件のレビューで平均確認時間、mask 項目、approval decision を比較できる。
CS 回答 / 返金判断
入力
チケット ID、契約情報、FAQ、過去対応、自社 admin の read-only 画面。
AI の役割
回答文、社内調査メモ、返金可否の根拠を下書きする。
人間に戻す操作
顧客への送信、返金実行、契約変更、登録情報変更。
合格条件
送信と返金が全件 approval 待ちになり、拒否理由が再下書きに反映される。
社内 MCP connector 申請
入力
対象 API、利用部門、read-only tool、namespace、clearance、token 条件。
AI の役割
tool schema を公開し、Claude / GPT / 社内 agent から同じ endpoint を呼べるようにする。
人間に戻す操作
write tool 追加、public token 発行、registration 有効化。
合格条件
2 種類以上の AI client で接続し、token rotation と tool call metadata を確認できる。
請求書例外 / 入金消込
入力
請求書、発注書、運用条件、入金 CSV、会計画面の read-only 参照。
AI の役割
差異候補を抽出し、例外分類、照合理由、修正案を残す。
人間に戻す操作
金額変更、消込実行、支払保留、rollback。
合格条件
過去例外で分類理由を再現し、金額変更が approval なしに進まない。
Kickoff Agenda
初回 meeting で、PoC の成否条件まで決める。
PoC は初回相談から設計します。誰が参加し、何を決め、どの成果物を残すかを先に揃えると、 実装に入る前に判断の道筋が見えます。
業務範囲を 1 つに絞る
参加者
業務 owner、現場 lead、viyv
決めること
KYC 10 件、CS 30 件、read-only API 1 つなど、30 日で検証できる件数と範囲を決める。
残すもの
workflow brief、対象件数、利用者、除外する業務。
AI に任せる作業を分ける
参加者
現場 lead、AI app owner、viyv
決めること
読み取り、照合、要約、回答下書き、tool 呼び出し、schema 変更のどこまでを AI に任せるか決める。
残すもの
AI task list、使用する画面 / API / data、最初の prompt / agent 条件。
人間に戻す操作を固定する
参加者
業務 owner、内部統制、セキュリティ
決めること
送信、返金、登録、振込、金額変更、承認、agent publish など、全件 approval に戻す操作を決める。
残すもの
approval rule、read-only policy、拒否理由 taxonomy。
セキュリティ証拠を決める
参加者
セキュリティ、法務、情シス
決めること
mask する項目、token scope、namespace、audit metadata、本文保存の扱い、レビューに出す証跡を決める。
残すもの
mask pattern、policy 設定、metadata sample、質問票への回答方針。
判断の基準を決める
参加者
管理部門、管理者、業務 owner
決めること
Team で始める条件、Enterprise が必要な条件、PoC 後に増やす workflow / connector / agent を決める。
残すもの
Go / Hold / No-Go 条件、plan recommendation、90 日 rollout draft。
Acceptance Criteria
PoC の合格条件を、先に書く。
30 日後に「動いた」で終わらせないため、判断に必要な合格条件を最初に固定します。
業務効果
対象 workflow の所要時間、再作業、下書き品質、担当者の確認負荷を、検証前後で比較できる。
統制
止めたい操作が policy / approval で止まり、承認・拒否・差戻の結果を説明できる。
データ境界
AI に渡る DOM、screenshot、tool input、DB row の範囲と、mask された項目を確認できる。
運用責任
policy、token、registration、agent version、audit review の owner を決められる。
PoC Decision Board
30 日後に、Go / Hold / No-Go を判断する。
PoC の成功は「動いた」ではありません。対象 workflow ごとに、運用へ進む証拠、 再検証する条件、止める条件を先に決めておきます。
KYC / 審査レビュー
見る証拠
レビュー 10 件の Before / After、PII mask、read-only policy、承認 / 差戻 / 凍結の approval decision。
Go
審査補助として Team で開始し、最終判定は人間に残す運用を承認する。
Hold
mask 対象や許可ドメインが足りない場合は、policy を追加して同じ 10 件で再実行する。
No-Go
AI に渡る個人情報や最終判定操作を説明できない場合は、判断に進めない。
CS 回答 / 返金判断
見る証拠
問い合わせ 30 件の一次回答時間、下書き修正率、送信前 approval、返金拒否理由、再下書きログ。
Go
回答下書きは Team で運用開始し、返金 / 契約変更は追加レビューの対象にする。
Hold
送信前 review が現場負荷を増やす場合は、問い合わせカテゴリと返金条件を絞り直す。
No-Go
回答根拠が出せない、または送信・返金が approval なしに進む場合は採用しない。
社内 MCP connector
見る証拠
tools/list、namespace、registration、token rotation / revoke、Claude / GPT / 社内 agent の複数接続ログ。
Go
read-only connector を platform 標準にし、write tool 追加だけ別 approval route にする。
Hold
namespace owner や token owner が未定なら、運用 owner を決めてから次の connector に進む。
No-Go
client ごとに unmanaged token が増え、metadata audit を説明できない場合は標準化しない。
請求書例外 / AI DB
見る証拠
例外分類の再現率、金額変更 approval、purpose、migration reason、rollback、照合理由。
Go
例外分類と照合メモを本番 workflow に近づけ、金額変更は人間承認で運用する。
Hold
分類理由が曖昧な場合は、対象の例外種別と運用条件を絞って再検証する。
No-Go
金額変更が止まらない、または schema 変更理由と rollback を説明できない場合は進めない。
Evidence Runs
30 日で、どの順番で証拠を作るか。
PoC は実装だけではありません。Before を測り、AI の役割を限定し、止めたい操作を発火させ、 最後に判断へ変える流れで進めます。
Run 01
Before を測る
PoC 前の同じ件数で、処理時間、再作業、確認回数、レビュー負荷、失敗時の影響を記録する。
残すもの
Before baseline、対象件数、担当者、除外条件。
Run 02
AI の役割を限定して動かす
読み取り、照合、要約、下書き、tool 呼び出しなど、AI が担当する作業だけを実行する。
残すもの
AI output、下書き修正率、参照した画面 / tool / data。
Run 03
止める操作を発火させる
送信、返金、登録、振込、金額変更、schema 変更、agent publish を意図的に試し、approval で止まるか見る。
残すもの
approval decision、拒否理由、policy denial、再下書きログ。
Run 04
データ境界を提出物にする
mask 前後、AI に渡った項目、token scope、tools/list、metadata audit をレビュー資料に変える。
残すもの
Data boundary packet、Action boundary packet、Connector / Agent evidence。
Run 05
判断に変える
業務効果、統制、運用 owner、次の workflow、Team / Enterprise 条件を並べて Go / Hold / No-Go を決める。
残すもの
Decision packet、plan recommendation、90 日 rollout draft。
30-Day Plan
30 日で判断材料を揃える。
部門全体の運用計画ではなく、1 つの workflow で価値と統制を確認します。
業務と成功条件を固定する
対象 workflow、関係者、入力データ、完了条件、削減したい作業時間、止めたい危険操作を 1 枚にします。
最小構成で接続する
Browser、MCP Gateway、MCP、DB、Agent Foundry から必要な製品だけを使い、1 業務に必要な接続と policy を作ります。
実業務で evidence を集める
承認待ち、拒否理由、mask された項目、tool call metadata、agent event、schema 変更理由を実際のログで確認します。
本番運用の判断材料にする
業務効果、統制の説明可能性、運用責任、次の展開先、Enterprise 要件を整理し、判断へ進めます。
Deliverables
PoC の最後に残すもの。
判断に必要なのは「動いた」ではなく、業務効果、統制、運用責任、拡張先を説明できる証拠です。
対象業務と scope の 1 枚資料
AI に渡す情報と mask 対象の一覧
人間承認が必要な操作リスト
PoC 中に取得する audit / event / metadata
Team / Enterprise どちらで進めるかの判断材料
次に増やす部門・connector・agent の候補
Contact
まず 1 つの workflow を選ぶ。
現在の業務、利用したい AI client、扱うデータ、止めたい操作を送ってください。PoC の範囲を 30 日で検証できる形に落とします。