業務責任者 / 管理部門
業務効果メモ
証明すること
同じ件数の利用前後で、作業時間・下書き修正率・承認待ち時間を説明できる。
判断への動かし方
Team で始める対象 workflow と利用人数を決める。
Proof Pack
本番利用に進める証拠を、検証の最初から集める。
viyv の評価は「AI が動いた」では終わりません。業務効果、止められた危険操作、 AI に渡らなかった情報、監査 metadata、運用責任を並べ、社内で判断できる材料にします。
Evidence Submission Room
検証のログを、社内説明に貼れる提案へ変える。
証跡は集めるだけでは判断に進みません。業務効果、統制、運用責任、運用条件を読み手ごとに束ね、 Team で始めるか、Enterprise 条件を詰めるか、追加検証に戻すかを一枚で説明します。
セキュリティ / 法務
統制証跡メモ
証明すること
AI に渡る情報、渡らない情報、マスク、読み取り専用、保存期間、監査メタデータを説明できる。
判断への動かし方
顧客情報を扱う業務を進めるか、Enterprise 条件 / 追加検証に分ける。
情シス / AI 基盤
運用責任メモ
証明すること
ポリシー担当、トークン担当、登録担当、監査レビュー周期、agent 版の責任者が決まっている。
判断への動かし方
Team で運用できる範囲と SSO / SIEM / 接続管理条件を分ける。
管理部門 / 経営
提案メモ
証明すること
選ばなかった案、残リスク、利用プラン、90 日展開計画、運用条件が明文化されている。
判断への動かし方
Team / Enterprise / 追加検証 / No-Go の結論を社内説明に載せる。
Operational Review Drills
社内説明で出る反論を、見せる証拠に変える。
利用前に止まる理由はだいたい決まっています。効果、データ境界、危険操作、 運用責任の 4 つを会議で実際に突かれる前提で、どの画面・ログ・メモを見せるかを固定します。
業務効果は本当に本番利用に進めるほどあるのか
会議で再現する場面
KYC 10 件、CS 30 件、請求書例外 20 件など、同じ件数で現行作業と viyv 実行を並べる。
その場で見せる証拠
利用前後の確認時間、下書き修正率、再作業、承認待ち、AI 利用で増えた確認負荷。
判断への返し方
削減時間だけでなく、増えたレビュー負荷も見せ、Team で始める対象 workflow と人数を決める。
顧客情報や社内情報を AI に渡していないと言えるのか
会議で再現する場面
ログイン済み業務画面で、AI が読む DOM / screenshot / tool input / DB row を確認する。
その場で見せる証拠
mask 前後、読み取り専用、token scope、AI に渡った項目、渡らなかった項目、拒否された tool call。
判断への返し方
セキュリティと法務がレビュー資料に貼れる形で、進める業務と追加検証に戻す業務を分ける。
AI が送信・返金・登録まで進めてしまわないか
会議で再現する場面
送信、返金、登録、金額変更、schema 変更、agent publish を意図的に試して止める。
その場で見せる証拠
approval modal、承認 / 拒否 decision、拒否理由、policy denial、再下書き、再実行 event。
判断への返し方
危険操作は HITL 必須の運用条件にし、read-only workflow から Team 利用を始める。
検証後に誰が運用するのか
会議で再現する場面
policy、token、registration、audit review、agent version の owner を実名で割り当てる。
その場で見せる証拠
owner 一覧、review cadence、connector 状態、token rotation、audit reviewer、Enterprise に残す条件。
判断への返し方
Team で運用できる範囲と、SSO / SIEM / VPC / 複数部門 rollout の Enterprise 条件を分ける。
Evidence Map
利用前に、何を証拠として見るか。
便利そうな demo ではなく、レビューで問われる業務・統制・運用の観点に分けて確認します。
Work
どの作業時間が減ったか
手入力、画面横断、確認、下書き、検索、tool 呼び出しのどこが減ったかを、対象 workflow ごとに見る。
Action
どの危険操作が止まったか
送信、削除、返金、振込、発注、schema 変更、agent 実行が、人間承認や policy で止まるかを見る。
Data
AI に渡らない情報は何か
DOM、screenshot、tool input、DB row の中で、mask された項目と token scope で届かない範囲を見る。
Audit
本文なしで説明できるか
tool 本文を保存せず、org、user、registration、tool、時刻、成否、byte 数、approval decision を追えるかを見る。
Owner
誰が運用するか
policy、token、registration、agent version、audit review を、業務部門と platform のどちらが持つか決める。
Expansion
次に増やす先が見えるか
最初の 1 workflow から、次の部門、connector、agent、Enterprise 要件へ広げられるかを見る。
Evidence Recipes
証拠を、業務別の作り方まで落とす。
同じ viyv でも、使う理由は業務ごとに違います。検証 で何を実行し、何を集め、どの懸念を潰せば判断に進めるかを固定します。
KYC レビュー時間を削減したい
実行する workflow
本人確認、制裁リスト、顧客台帳の 3 画面を 10〜20 件で比較する。
集める証拠
利用前の確認時間、AI 下書き後の確認時間、PII mask、最終判定 approval、差戻理由。
証明すること
AI は照合メモまでを担当し、凍結・承認・差戻の責任は人間に残せる。
潰す懸念
法務・セキュリティが PII と最終判断の責任境界を承認できない。
判断に進む signal
read-only と HITL が通り、審査補助を Team の最初の workflow にできる。
CS の一次回答と返金判断を速くしたい
実行する workflow
過去チケット 30 件で、回答下書き、FAQ 参照、契約確認、返金可否メモを比較する。
集める証拠
一次回答時間、下書き修正率、送信 approval、返金拒否理由、agent version、再下書き履歴。
証明すること
AI が調査と下書きを行い、送信・返金・契約変更は人間承認で止められる。
潰す懸念
誤送信や返金ミスの責任を CS Ops が説明できない。
判断に進む signal
SLA 改善と内部統制が両立し、回答下書きから Team 利用を始められる。
社内 MCP を複数 AI client に配りたい
実行する workflow
read-only API を 1 つ選び、Claude、GPT、社内 agent から同じ tool を呼ぶ。
集める証拠
tools/list、namespace、registration、token rotation / revoke、複数 client 接続、metadata-only audit。
証明すること
vendor 別 tunnel を増やさず、標準 remote MCP endpoint として governance できる。
潰す懸念
connector ごとに token と監査が分散し、AI platform の運用責任が増える。
判断に進む signal
Enterprise 条件として SSO / SIEM / connector governance を詰める根拠が揃う。
AI が作る DB / Agent を本番運用したい
実行する workflow
調査 table、例外 table、agent definition の作成・変更・再実行を 1 workflow で見る。
集める証拠
purpose、alter reason、migration reason、rollback、agent version、invocation event、publish approval。
証明すること
AI の table 変更や agent 実行を、個人実験ではなく運用履歴として説明できる。
潰す懸念
検証後に schema、memory、agent prompt、run history が誰の責任か決まらない。
判断に進む signal
部門利用は Team、複数部門 agent と監査連携は Enterprise と切り分けられる。
Proof Walkthroughs
1 件の業務から、判断材料がどう生まれるか。
検証の証拠は後から集めるものではありません。業務の実行中に、作業時間、承認、 mask、tool metadata、変更理由を同時に残します。
KYC 10 件で、審査補助の証拠を作る
業務中に起きること
担当者が顧客 ID と確認観点を渡し、AI が本人確認・制裁リスト・台帳の差分メモを下書きする。
発生する証拠
利用前後の確認時間、PII mask、read-only policy、承認 / 差戻 / 凍結 approval、差戻理由。
誰が読むか
業務責任者は処理時間と差戻率を見る。セキュリティは PII mask と read-only を見る。管理部門は Team 開始の対象人数を見る。
判断への使い方
最終判定を人間に残せるなら Team で審査補助を開始し、監査部門向け evidence pack が必要なら Enterprise 条件にする。
CS 30 件で、回答下書きと送信停止の証拠を作る
業務中に起きること
AI が契約情報、FAQ、過去対応を読み、回答文と返金可否メモを下書きする。送信と返金は approval 待ちにする。
発生する証拠
一次回答時間、下書き修正率、送信 approval、返金拒否理由、再下書きログ、agent version。
誰が読むか
CS Ops は SLA と品質を見る。内部統制は返金 approval を見る。AI アプリ owner は agent version と run history を見る。
判断への使い方
回答下書きは Team で始め、返金・契約変更・複数拠点 rollout は Enterprise の security review に分ける。
read-only API 1 つで、MCP 配布の証拠を作る
業務中に起きること
viyv MCP で read-only tool を定義し、Gateway から Claude / GPT / 社内 agent に同じ endpoint で配る。
発生する証拠
tools/list、namespace、registration、token rotation / revoke、複数 AI client 接続、metadata-only audit。
誰が読むか
AI platform は connector 運用を見る。セキュリティは token scope を見る。管理部門は Enterprise 条件の有無を見る。
判断への使い方
unmanaged tunnel を増やさず標準 connector route にできるなら、Enterprise を前提に SSO / SIEM / governance を詰める。
AI DB / Agent で、変更理由と運用履歴の証拠を作る
業務中に起きること
AI が調査 table を作り、列追加の reason を残し、Agent Foundry が agent version と invocation event を保存する。
発生する証拠
purpose、alter reason、migration_info、rollback、agent definition、run history、publish approval。
誰が読むか
AI アプリ責任者は再利用性を見る。監査は rollback と変更理由を見る。管理部門は部門運用か Enterprise かを分ける。
判断への使い方
1 部門の業務メモリなら Team で始め、複数部門 agent や監査連携が必要になった時点で Enterprise に進む。
When Proof Is Not Enough
社内説明で止まる理由を、追加証拠に変える。
「よさそうだが不安」という反応を放置しません。利用前に足りない証拠を特定し、 Team で始める範囲と Enterprise で詰める条件に分けます。
効果は見えるが、本番利用に進めるほどの確証がない
足りない証拠
削減時間だけが出ており、増えた確認時間、再作業、承認待ちが見えていない。
追加する evidence
Before / After workflow sheet に、処理時間、下書き修正率、承認待ち、差戻件数を同じ件数で追加する。
判断への戻し方
対象 workflow を 1 つに絞って Team 開始。次の workflow は 30 日後に再判定する。
セキュリティが AI に渡る情報を承認できない
足りない証拠
mask 前後、read-only、token scope、保存される metadata の範囲が資料化されていない。
追加する evidence
Data boundary evidence に、AI に渡った項目、渡らなかった項目、拒否された tool call を並べる。
判断への戻し方
顧客情報を扱う workflow は evidence 追加後に進め、公開情報中心の workflow から開始する。
AI が危険操作をしてしまう不安が残る
足りない証拠
送信、返金、登録、schema 変更、agent publish が実際に止まった証拠がない。
追加する evidence
Action approval log に、approval modal、承認 / 拒否 decision、拒否理由、再下書き結果を追加する。
判断への戻し方
危険操作は HITL 必須の運用条件にし、read-only workflow から Team 利用を始める。
検証後に誰が運用するか決まっていない
足りない証拠
policy owner、token owner、registration owner、audit reviewer、agent version owner が未定。
追加する evidence
Operations plan に owner と review cadence を書き、Team で運用できる範囲と Enterprise 条件を分ける。
判断への戻し方
owner が決まった範囲だけ利用し、SSO / SIEM / VPC は Enterprise 検討項目として残す。
Scenario Evidence
シナリオ別に、判断まで見る。
どの業務で、何が変わり、どの証跡を見れば判断に進めるかを具体化します。
Scenario
KYC / 審査レビュー
利用前
本人確認、制裁リスト、顧客台帳を人間が横断し、AI 利用は PII と最終判定の不安で止まる。
運用後
Browser が許可済み画面だけを読み、AI が照合メモを作り、承認・差戻・凍結は HITL に戻す。
見る証拠
mask された項目、read-only policy、approval decision、レビュー時間の変化。
判断
AI を審査補助として使い、最終判断は人間に残す運用を承認できるか。
Scenario
CS 回答 / 返金判断
利用前
チケット、契約情報、FAQ、自社 admin を見ながら回答を作るが、誤送信と顧客情報の扱いが曖昧。
運用後
Agent が調査し、Browser が admin を read-only で参照し、回答文を下書きして送信前に止める。
見る証拠
一次回答時間、送信前 approval、拒否理由、問い合わせ履歴の再利用。
判断
SLA 改善と責任境界を両立できるか。
Scenario
社内 MCP 配布
利用前
Claude 用、GPT 用、社内 agent 用で tunnel、token、OAuth、監査が分散している。
運用後
MCP Gateway の registration と public endpoint に集約し、connector は outbound だけでつなぐ。
見る証拠
1 MCP の複数 client 接続、token rotation、registration audit、enabled toggle。
判断
ベンダー別 tunnel 運用から、標準 MCP endpoint 管理へ移せるか。
Scenario
AI DB / Agent 実行
利用前
AI が扱う memory、調査 table、agent prompt、run history が個人実験として散らばる。
運用後
DB が purpose / reason 付きで schema を進化させ、Foundry が definition、deploy、event を保存する。
見る証拠
migration reason、rollback 実演、agent version、invocation event、correlation ID。
判断
AI アプリを検証で終わらせず、運用できる製品面に載せられるか。
Evidence Packet
検証の証拠を、レビューの packet に変える。
証拠はログの羅列では足りません。誰が owner で、何を含め、どの状態なら判断材料に使えるかを packet として整理します。
業務責任者
Workflow summary
含めるもの
対象業務、担当者、頻度、AI に任せた作業、人間に戻した判断。
合格条件
削減した作業と残した責任境界を、現場と管理者が同じ言葉で説明できる。
セキュリティ / 法務
Control evidence
含めるもの
mask 結果、read-only policy、approval decision、token scope、metadata retention。
合格条件
AI に渡る情報、止まる操作、保存されるログの範囲をレビュー資料に載せられる。
情シス / AI platform
Operations plan
含めるもの
policy owner、token owner、registration、connector 状態、audit review cadence。
合格条件
Team で運用できる範囲と、Enterprise 条件へ進む範囲を分けられる。
管理部門 / 経営
Adoption decision
含めるもの
利用人数、対象 workflow、次の展開先、利用 plan、残論点。
合格条件
Free / Team / Enterprise のどれで進むか、検証の証拠から判断できる。
Proof Review
証拠を見て、Go / Hold / No-Go を決める。
検証 の最後にログやスクリーンショットを並べても、判断基準がなければ社内説明は進みません。 各証拠をどう読めば運用へ進むか、保留か、止めるべきかを分けます。
作業時間の証拠
見る証拠
同じ件数での Before / After、下書き時間、確認時間、再作業時間、承認待ち時間。
Go
削減時間だけでなく、AI 利用で増えた確認時間も見える。業務 owner が次の workflow へ広げる理由を説明できる。
Hold
一部の担当者だけ短縮した、またはレビュー負荷が増えた。対象件数や workflow を絞り直して再評価する。
No-Go
demo は動いたが、現場指標に変換できない。判断材料には進めない。
危険操作の証拠
見る証拠
送信、返金、登録、削除、振込、schema 変更、agent 実行の approval decision と拒否理由。
Go
止めたい操作が全件 HITL / policy で止まり、拒否理由が AI の再下書きや運用改善に使える。
Hold
一部操作は止まるが、例外 URL や write tool の分類が曖昧。policy を追加して再実行する。
No-Go
AI が最終操作まで進める、または誰が承認したか説明できない。
データ境界の証拠
見る証拠
mask 前後、read-only 画面、AI に渡った項目、token scope、拒否された tool call。
Go
顧客情報や内部情報が AI に渡らない範囲を、セキュリティと法務が資料に載せられる。
Hold
mask pattern は効くが、業務固有の ID や自由記述欄に追加対策が必要。
No-Go
AI に渡るデータ範囲を説明できず、顧客情報を外部に出す懸念が残る。
運用責任の証拠
見る証拠
policy owner、token owner、registration owner、audit reviewer、agent version owner。
Go
Team で運用する owner と cadence が決まり、Enterprise が必要な条件だけが残論点になる。
Hold
業務 owner は決まったが、token / audit / connector の owner が未確定。
No-Go
検証後に誰が管理するか決まらず、運用負荷が社内判断を止める。
拡張計画の証拠
見る証拠
次の workflow、次の connector、DB / Agent Foundry 追加、90 日 rollout、利用 plan。
Go
最初の workflow から次の展開先が決まり、Team / Enterprise の運用条件に落とせる。
Hold
効果はあるが、次に増やす workflow が未確定。利用範囲を限定して始める。
No-Go
単発検証で終わり、運用後の利用シナリオがない。
Evidence Submission Pack
検証後に提出する証拠を、レビュー資料の形にする。
証拠はスクリーンショットやログを集めるだけでは使えません。何を証明し、誰が読み、 どの判断材料に使うかまで揃えて提出します。
業務責任者 / 管理部門
Before / After workflow sheet
証明すること
AI を入れて、どの作業時間と再作業がどう変わったか。
含めるもの
対象件数、担当者、利用前の平均処理時間、運用後の処理時間、下書き修正率、承認待ち時間。
判断への使い方
削減時間と増えたレビュー負荷を両方見て、Team 運用の対象 workflow を決める。
セキュリティ / 法務
Data boundary evidence
証明すること
AI に渡らない情報と、mask / scope が実際に効いていること。
含めるもの
mask 前後、AI に渡った項目一覧、read-only policy、token scope、拒否された tool call。
判断への使い方
顧客情報・個人情報を扱う workflow を検証から本番利用へ進められるか判断する。
業務責任者 / 内部統制 / 監査
Action approval log
証明すること
送信、返金、登録、振込、schema 変更、agent 実行が人間承認で止まること。
含めるもの
approval modal、承認 / 拒否 decision、拒否理由、再下書き、policy denial、承認者。
判断への使い方
AI に任せる範囲と人間に残す責任境界を承認できるか判断する。
情シス / AI platform
Connector and token report
証明すること
MCP connector、registration、token、namespace を継続運用できること。
含めるもの
tools/list、registration 一覧、token rotation / revoke、複数 AI client 接続、metadata-only audit。
判断への使い方
部署ごとの unmanaged tunnel を増やさず、platform 標準として採用するか判断する。
AI アプリ責任者 / 監査
DB / Agent change history
証明すること
AI が作った table、schema 変更、agent version、run history を後から説明できること。
含めるもの
purpose、alter reason、migration reason、rollback、agent version、invocation event、correlation ID。
判断への使い方
AI アプリを個人実験から本番 workflow へ載せられるか判断する。
Evidence Decision Board
証拠を、Go / Hold / No-Go の判断材料に変える。
検証の最後に提出物が揃っても、結論が曖昧なら判断は進みません。証拠の状態から、 Team、Enterprise、追加検証、No-Go を分けます。
Go: Team で始める
必要な証拠
1 workflow、3〜10 名、作業時間、approval、mask、運用 owner、次の workflow が揃っている。
判断への使い方
標準 Team 運用で開始し、30〜90 日で拡張先と Enterprise 条件を再判定する。
Go: Enterprise 条件を詰める
必要な証拠
複数部門、SSO / SCIM、SIEM、connector governance、DPA、retention、VPC / on-prem 条件が出ている。
判断への使い方
個別契約、security questionnaire、support 条件、運用責任分担を管理部門・法務と詰める。
Hold: 追加検証
必要な証拠
効果はあるが、mask 対象、承認者、token owner、audit reviewer、agent publish owner が未確定。
判断への使い方
不足 evidence を 2〜4 週間の追加検証に限定し、次回会議で Go / No-Go を決める。
No-Go: 今回は利用しない
必要な証拠
demo は動いたが、現場指標、止めたい操作、データ境界、運用 owner、次の展開先に変換できない。
判断への使い方
対象 workflow を再選定するか、現時点では別案で進める。
Stakeholders
誰が、どの証拠を見るか。
判断は 1 人では終わりません。検証の成果を、業務・セキュリティ・platform・管理部門の それぞれが読める形に分けます。
業務責任者
削減した作業、残した人間判断、再利用できる workflow、次に広げる部門を確認する。
セキュリティ / 法務
AI に渡る情報、masking、HITL、audit metadata、データ保持方針を確認する。
情シス / platform
token scope、registration、connector 接続、policy 管理、SIEM / VPC 要件を確認する。
管理部門 / 経営
Free / Team / Enterprise の境界、検証後の利用人数、利用前の残論点を確認する。
Next Step
証拠から逆算して検証を始める。
対象 workflow、止めたい操作、mask したいデータ、残したい metadata を決めると、 30 日の検証を判断材料に直結させられます。