業務 owner / 導入責任者
本番移行メモ
使い方
PoC で通った業務、対象人数、除外する操作、初月の成功条件を固定する。
進める条件
誰が使い、何件で始め、どの操作を人間に戻すかを導入後すぐ説明できる。
Implementation
PoC を、本番運用へ移す計画まで見せる。
viyv は demo で終わらせません。PoC で確認した業務、方針、トークン、監査、運用責任を 90 日で部門運用へ移し、次の接続や agent へ広げます。
Go-Live Command Center
導入後に迷わないよう、初月の運用判断を先に置く。
本番導入の失敗は、技術設定よりも owner と会議体の曖昧さで起きます。PoC の証拠を、本番移行メモ、統制引き渡し、運用レビュー、拡張と戻し方の判断条件 に変換し、導入後 30 日で何を動かすかを固定します。
セキュリティ / 情シス
統制引き渡し
使い方
マスク、読み取り専用、承認、トークン、登録、監査メタデータを本番設定へ移す。
進める条件
ポリシー担当、トークン担当、監査レビュー担当が決まり、拒否ログを読める。
現場 lead / 基盤 owner
運用レビュー周期
使い方
週次・隔週・月次で見る指標を分け、作業時間、拒否理由、接続状態、実行版を確認する。
進める条件
導入後に誰が何を見て改善するかが、会議体と指標まで決まっている。
管理部門 / 管理者
拡張 / 戻し方判断
使い方
増やす業務、止める条件、Enterprise に上げる条件、戻し方を 90 日計画に入れる。
進める条件
Team 開始、Enterprise 条件、追加 PoC、停止の判断を同じ資料で分けられる。
Production Scenarios
導入後の最初の 1 か月を、業務別に具体化する。
本番導入は抽象的な rollout では進みません。PoC で証明した workflow を、どの設定・owner・review cadence で日次運用に入れるかを決めます。
KYC 補助を審査チームの日次運用に入れる
最初の 1 か月
3〜5 名の PoC から、審査種別を 1 つ増やして 10〜20 名に広げる。AI は照合メモと差戻理由の下書きだけを担当する。
本番設定
KYC ドメイン allow、顧客台帳 read-only、PII mask、最終判定 approval、差戻理由 taxonomy を production policy に移す。
運用レビュー
週次で確認時間、差戻率、approval 待ち件数、policy denial、mask 漏れを確認する。
広げる条件
審査補助が安定したら、継続的顧客管理や取引モニタリングへ同じ control を展開する。
CS 回答 agent を部門 workflow にする
最初の 1 か月
問い合わせカテゴリを 1 つ追加し、回答下書き、社内メモ、返金可否メモを daily queue に入れる。
本番設定
Agent Foundry の agent version、Browser read-only、送信 / 返金 approval、拒否理由 taxonomy、run history retention を設定する。
運用レビュー
週次で一次回答時間、下書き修正率、送信拒否理由、返金 approval、agent version drift を見る。
広げる条件
回答品質が安定したら、返金判断、契約変更、障害影響調査 agent へ広げる。
MCP Gateway を connector 申請の標準 route にする
最初の 1 か月
read-only API connector を 1 つ本番 route にし、新規 connector 申請は namespace、token owner、registration owner を必須にする。
本番設定
registration、relay key、public token、OAuth 条件、token rotation、write tool approval、metadata-only audit を標準手順にする。
運用レビュー
隔週で connector 状態、tools/list、token revoke、client 追加要求、拒否された tool call を確認する。
広げる条件
read-only connector が安定したら、write tool は別 approval route で追加する。
AI DB / Agent を業務メモリとして運用する
最初の 1 か月
競合調査または請求書例外の table を本番 workflow にし、agent が参照する data scope と publish 承認を固定する。
本番設定
purpose / reason、migration_info、rollback、agent definition、version、invocation event、run history retention を設定する。
運用レビュー
月次で schema 変更理由、rollback 実績、agent run failure、参照 data、次の agent 候補を確認する。
広げる条件
業務メモリが再利用されるようになったら、部門 agent と semantic search の対象を増やす。
Expansion Gates
広げてよい条件と、止める条件を分ける。
本番導入後は、勢いで workflow や connector を増やしません。最初の運用証拠から、 何を広げてよいか、どこで Hold するか、誰が承認するかを決めます。
Workflow を増やす
広げてよい signal
最初の workflow で作業時間、下書き品質、approval 待ち、拒否理由、mask 証跡を安定して確認できている。
次に増やす先
同じ部門内の隣接 workflow。KYC なら継続的顧客管理、CS なら返金判断、請求書なら支払保留。
Hold 条件
拒否理由が分類できない、現場レビュー負荷が増えている、または AI output の修正率が高い。
承認する owner
業務 owner が対象 workflow、セキュリティが追加 mask、platform が policy 配布を承認する。
Connector を増やす
広げてよい signal
read-only connector で namespace、tools/list、token rotation、revoke、metadata-only audit が定期レビューできている。
次に増やす先
同じ owner の read-only connector から追加する。write tool は別 approval route で申請する。
Hold 条件
token owner、registration owner、write tool approval、client 追加手順のいずれかが未定。
承認する owner
AI platform が connector owner、情シスが token owner、セキュリティが namespace と metadata を承認する。
Agent を公開する
広げてよい signal
agent version、run history、approval decision、失敗 run の差戻理由が揃い、利用部門が品質を確認している。
次に増やす先
個人 prompt ではなく部門 agent として公開する。送信、返金、契約変更、publish は approval 必須にする。
Hold 条件
agent version drift、参照 data scope、publish owner、rollback 手順が説明できない。
承認する owner
AI アプリ責任者が agent definition、業務 owner が利用条件、監査が run history retention を承認する。
Enterprise に上げる
広げてよい signal
複数部門、SSO / SCIM、SIEM、DPA、VPC / on-prem、audit export、複数 AI client が管理部門条件になる。
次に増やす先
Team の部門運用から、Enterprise 運用の governance、security review、support 条件へ移る。
Hold 条件
利用人数や対象 workflow は増えたが、SSO / SIEM / audit reviewer / retention の owner が未定。
承認する owner
管理部門、セキュリティ、情シス、業務 owner が Enterprise 条件と 90 日 rollout を承認する。
90-Day Rollout
30 日の PoC から、90 日の部門運用へ。
最初から全社展開を狙わず、PoC で証明した workflow を部門運用に移し、接続と agent を段階的に増やします。
Days 1-30
PoC を導入判断に変える
1 workflow、3〜5 名、1 つの統制に絞り、作業時間、approval、mask、tool metadata を確認します。
- 対象 workflow
- PoC 合格条件
- 承認 / 拒否ログ
- Team / Enterprise 判断
Days 31-60
部門運用に載せる
利用者を 1 チームへ広げ、policy owner、token owner、audit reviewer を決めます。承認ルールと拒否理由を業務ルールに合わせます。
- policy owner
- 利用者ロール
- 承認ルール
- audit review cadence
Days 61-90
接続と agent を増やす
最初の workflow で効果が出たら、社内 MCP、DB、Agent Foundry を必要な範囲だけ足します。SIEM、SSO、VPC 要件もここで整理します。
- 追加 connector
- agent catalog
- SIEM / SSO 要件
- 次部門 rollout
Migration Paths
PoC で終わらせず、業務別に本番条件へ進める。
本番移行は抽象的な rollout ではなく、PoC で確認した workflow ごとに次の利用範囲、 owner、review cadence を決めて進めます。
KYC / 審査レビュー
PoC 後の状態
3〜5 名で 10 件の審査を再現し、mask、read-only、approval を確認済み。
本番へ進める作業
審査種別を 1 つ増やし、承認者ロール、差戻理由、policy denial の review cadence を定義する。
owner
業務 owner が合格条件、セキュリティが mask / audit、情シスが policy 配布を持つ。
ready signal
審査時間、差戻率、mask 証跡、承認ログを月次で見られる。
CS 回答 / 返金判断
PoC 後の状態
回答下書き、社内メモ、返金可否メモを作り、送信と返金を全件 approval 待ちにできた。
本番へ進める作業
問い合わせカテゴリを 1 つ追加し、拒否理由 taxonomy、回答テンプレート、agent version 更新手順を決める。
owner
CS Ops が回答品質、現場 lead が承認判断、AI アプリチームが agent version を持つ。
ready signal
一次回答時間、送信拒否理由、返金承認、再下書きの改善を追跡できる。
社内 MCP connector
PoC 後の状態
read-only API を 1 つ MCP 化し、Claude / GPT / 社内 agent から同じ endpoint を呼べた。
本番へ進める作業
registration owner、token rotation、namespace 命名、write tool 追加申請の gate を標準化する。
owner
AI platform が connector、情シスが token、セキュリティが namespace / metadata を持つ。
ready signal
tools/list、token revoke、connector 状態、tool call metadata を定期レビューできる。
Day 0-14 Runbook
最初の 2 週間で、導入判断に必要な証拠を作る。
PoC は「試して終わり」ではなく、初日から証拠作りとして設計します。範囲、設定、実行、 review、導入判断までを 2 週間の runbook にします。
Day 0
対象 workflow と失敗条件を固定する
owner
業務 owner / 現場 lead
実行すること
KYC 10 件、CS チケット 30 件、read-only connector 1 つなど、PoC で扱う範囲を数字で決める。AI が触ってはいけない画面、送信・返金・登録など必ず人間に戻す操作も同時に決める。
残すもの
workflow brief、禁止操作、Go / No-Go 条件、参加者リスト
Days 1-3
policy、mask、token、connector を最小構成で設定する
owner
情シス / セキュリティ
実行すること
許可ドメイン、read-only 画面、mask pattern、MCP namespace、token scope を 1 workflow 用に設定する。最初は広げず、拒否ログが読める状態を優先する。
残すもの
policy file、mask pattern、connector registration、token owner
Days 4-7
現場で 1 回目の実行を回す
owner
現場担当 / AI app owner
実行すること
AI に読み取り・要約・下書きを実行させ、送信・登録・返金・承認で止まるかを確認する。拒否した場合は理由を残し、AI が再下書きできるかを見る。
残すもの
実行ログ、approval decision、拒否理由、下書き修正メモ
Days 8-10
レビュー会で証拠を見せる
owner
業務 owner / セキュリティ / platform
実行すること
作業時間、mask 前後、approval、tool call metadata、migration reason を並べ、懸念が解消したものと残ったものを分ける。
残すもの
evidence packet、未解消リスク、追加設定、次回実行条件
Days 11-14
導入判断へつなげる
owner
管理部門 / 管理者
実行すること
Team で始められる条件、Enterprise が必要な条件、次に増やす workflow / connector / agent を整理する。社内説明には削減時間だけでなく、止められた操作と監査証跡を載せる。
残すもの
plan recommendation、seat 数、Enterprise 条件、90 日 rollout draft
Production Handoff Board
PoC の証拠を、本番の設定と運用 owner に引き渡す。
PoC で集めた証拠をそのまま残しても、本番運用にはなりません。証拠ごとに production 設定、owner、review cadence へ変換します。
業務 owner / 現場 lead
Workflow evidence
PoC から渡すもの
対象件数、Before / After、下書き修正率、承認待ち件数、拒否理由。
本番設定
対象 workflow を部門運用に登録し、成功条件、例外処理、承認者、月次レビュー指標を固定する。
運用レビュー
週次で作業時間、下書き品質、拒否理由を見て、次に増やす workflow を決める。
セキュリティ / 法務
Data boundary evidence
PoC から渡すもの
mask 前後、AI に渡った項目、read-only policy、token scope、policy denial。
本番設定
mask pattern、許可ドメイン、read-only page、metadata retention を production policy に移す。
運用レビュー
月次で mask 漏れ、policy denial、監査質問票への回答更新を確認する。
業務 owner / 内部統制
Action approval evidence
PoC から渡すもの
送信、返金、登録、振込、schema 変更、agent publish の approval decision と拒否理由。
本番設定
危険操作ごとに承認者、二者承認条件、拒否理由 taxonomy、再下書きの扱いを設定する。
運用レビュー
週次で承認待ち件数、拒否理由、誤承認リスク、現場負荷を確認する。
情シス / AI platform
Connector / token evidence
PoC から渡すもの
registration、tools/list、namespace、token rotation / revoke、複数 AI client 接続。
本番設定
connector owner、token owner、namespace 命名、write tool 追加 approval、client 追加手順を標準化する。
運用レビュー
隔週で connector 状態、revoke 実績、tool metadata、client 追加要求を確認する。
AI アプリ責任者 / 監査
DB / Agent evidence
PoC から渡すもの
purpose、alter reason、migration reason、rollback、agent version、run history。
本番設定
agent publish 承認、version 管理、rollback 手順、run history retention、参照 data scope を固定する。
運用レビュー
月次で schema 変更理由、失敗 run、agent version drift、次の agent 候補を確認する。
Rollback / Change Control
本番で失敗した時の戻し方を、導入前に決める。
AI の本番利用では、止めるだけでなく戻し方が重要です。画面操作、data boundary、 connector、DB / agent それぞれで検知、rollback、owner を分けます。
業務 owner / 内部統制
誤った画面操作 / 誤送信
検知するもの
approval なしの送信、登録、返金、金額変更、許可外ドメイン遷移を検出する。
戻し方
操作前 approval で止める。拒否理由を残し、AI に再下書きを要求する。実行済みの場合は業務 owner の incident process に移す。
セキュリティ / 法務
mask 漏れ / data boundary 逸脱
検知するもの
AI に渡った項目一覧、mask 前後、policy denial、security review での指摘を確認する。
戻し方
対象 workflow を一時停止し、mask pattern と許可ドメインを更新して同じ件数で再実行する。
情シス / AI platform
connector token / namespace の誤設定
検知するもの
tools/list の可視性、拒否された tool call、token owner、revoke 後の失敗 metadata を確認する。
戻し方
registration を disable し、public token と relay key を rotate / revoke する。write tool は再承認まで無効化する。
AI アプリ責任者 / 監査
AI DB schema / agent version の誤変更
検知するもの
migration reason、agent version、run failure、publish approval、参照 data の差分を見る。
戻し方
migration_info から rollback し、agent version を前版に戻す。publish gate を再確認してから再実行する。
Operating Model
誰が、何を運用するか。
AI 導入は「使う人」と「管理する人」が分かれます。導入後に揉めないよう、 owner と確認 cadence を先に決めます。
Environment Patterns
どの導入パターンから始めるか。
viyv は suite ですが、最初に全部を入れる必要はありません。業務画面、MCP、DB / Agent のどこが詰まっているかで構成を決めます。
Local-first
合う状態
Mac 利用部門で、ログイン済みブラウザ操作を安全に試したい
構成
Browser daemon、Chrome extension、local policy、HITL approval
見るもの
mask 漏れ、承認 UX、許可ドメイン、ローカル audit
Gateway-first
合う状態
社内 MCP を Claude / GPT / 社内 agent に同じ管理面で配りたい
構成
MCP registration、outbound connector、public endpoint、token / OAuth
見るもの
connector 接続状態、token rotation、tool metadata、namespace
Data / Agent-first
合う状態
AI が作る table、agent definition、run history を運用したい
構成
viyv DB、purpose / reason、Agent Foundry、invocation event
見るもの
migration reason、rollback、agent version、event retention
Production Readiness
本番移行前に確認すること。
PoC が成功しても、運用条件が揃わないと導入は止まります。導入前にこの checklist を揃えます。
最初の workflow で合格条件を満たした
承認が必要な操作と owner が決まっている
policy、mask、token、registration の管理者が決まっている
本文を保存しない audit metadata で説明できる
次に増やす workflow / connector / agent が決まっている
Team で足りるか Enterprise が必要か判断できる
Next Step
PoC の最後に、本番導入計画まで残す。
導入判断の材料だけでなく、導入後 90 日の owner、policy、connector、agent 拡張まで整理します。