管理部門 / 経営管理
提案 memo
元になる証拠
対象 workflow、利用人数、削減時間、残す人間判断、Team / Enterprise の境界、90 日 rollout。
納得させる点
検証が単なる実験ではなく、どの予算で、誰が owner になり、いつ次の workflow へ広げるかが分かる。
足りない時の扱い
利用人数、運用 owner、plan fit が未定なら、見積もりではなく追加検証の設計に戻す。
Buyer Guide
判断材料を、
関係者ごとに分ける。
viyv の判断は、業務責任者だけでも、情シスだけでも完結しません。現場、情シス、 セキュリティ、管理部門が見る証拠を整理します。
Submission Package
検証後に、そのまま提出できる package を作る。
レビュー会議で止まるのは、証拠がない時だけではありません。誰向けに、何を提出し、 何が欠けると保留になるかを先に分けることで、管理部門とセキュリティの手戻りを減らします。
セキュリティ / 法務
Data boundary sheet
元になる証拠
mask 前後、policy denial、approval decision、namespace、token scope、metadata-only audit、本文保持方針。
納得させる点
AI に渡る情報、渡らない情報、止まる操作、ログに残る情報を同じ evidence で説明できる。
足りない時の扱い
顧客情報や tool input/output の扱いを説明できない場合は、運用条件ではなく security 設計を先に詰める。
情シス / AI platform
Operating owner map
元になる証拠
policy owner、connector owner、token owner、agent owner、rollback 手順、incident 時の連絡 route。
納得させる点
運用後に誰が設定変更、失効、connector 追加、agent publish、問い合わせ対応を持つかが明確になる。
足りない時の扱い
検証実施者と本番運用 owner が違う場合は、利用前に support route と change process を固定する。
業務責任者 / 現場 lead
Workflow adoption plan
元になる証拠
Before / After、下書き修正率、承認待ち件数、拒否理由、次に広げる workflow、現場 training。
納得させる点
現場が何を続け、AI に何を任せ、どの判断を人間に戻すかが日次運用として説明できる。
足りない時の扱い
現場レビューが増えた、拒否理由が再下書きに反映されない場合は、対象カテゴリを絞って再検証する。
Buyer Journey Walkthrough
利用までの判断を、
具体化する。
役割別の説明だけでは判断は進みません。部門相談、検証 設計、実務検証、判断材料、運用後の展開までを同じ証拠でつなげます。
01 / 部門相談
AI 利用相談を、業務単位に変える
会議で起きること
業務責任者と現場 lead が、KYC 10 件、CS 30 件、請求書例外 20 件など最初の対象を 1 つに絞る。
viyv の使い方
Browser、MCP Gateway、DB / Agent Foundry のどれを使うかではなく、AI に任せる読み取り・要約・下書きと、人間に戻す送信・登録・承認を分ける。
見る証拠
workflow brief、対象件数、現状の平均処理時間、失敗時の影響、承認者。
判断
30 日の検証に進む。対象が広すぎる場合は 1 workflow へ戻す。
02 / 検証設計
セキュリティと管理部門が見る証拠を、開始前に決める
会議で起きること
情シス、セキュリティ、法務、管理部門が、mask 対象、read-only 範囲、token scope、audit metadata、利用人数を確認する。
viyv の使い方
policy、HITL approval、namespace、token rotation、metadata-only audit を検証の受け入れ条件に入れる。
見る証拠
mask 前後、policy denial、approval decision、tools/list、token revoke、plan fit。
判断
Team で測れる範囲と、Enterprise 条件として追加確認する範囲を分ける。
03 / 実務検証
現場が使う日の流れを、数字と拒否理由で残す
会議で起きること
担当者が AI の下書きを使い、承認・拒否・再下書きを記録する。便利だった感想ではなく、修正率と待ち時間を見る。
viyv の使い方
AI は候補、要約、回答文、判断メモを作る。送信、返金、登録、金額変更、最終判定は approval に戻す。
見る証拠
Before / After、下書き修正率、承認待ち件数、拒否理由、再下書き品質。
判断
現場負荷が増えるなら対象カテゴリを絞る。責任境界が守れるならレビュー会議へ進む。
04 / 判断材料
Go / Hold / Enterprise を、同じ packet で判断する
会議で起きること
業務責任者、platform owner、セキュリティ、管理部門が、validation evidence と商用条件を同じ画面で確認する。
viyv の使い方
Proof Pack、Pricing、Security、Implementation の情報を合わせ、提案 memo と 90 日 rollout に変える。
見る証拠
削減時間、残す人間判断、data boundary、運用 owner、利用人数、Enterprise 追加条件。
判断
Team で開始、Enterprise 条件を詰める、追加検証、今回は見送りの 4 つから 1 つを選ぶ。
05 / 運用後 90 日
運用後に広げる workflow と owner を先に決める
会議で起きること
初回利用の対象 workflow、次に増やす部署、policy owner、connector owner、agent owner を rollout 計画に入れる。
viyv の使い方
同じ approval、mask、namespace、agent event を次の workflow に再利用し、部門展開の判断材料を増やす。
見る証拠
90 日 rollout、追加 workflow、owner map、support route、次の budget gate。
判断
初回利用の成果を次の部門予算へつなげる。owner 未定なら利用範囲を広げない。
Stakeholder Questions
役割ごとの疑問に、具体的に答える。
同じ検証 でも、見るべき証拠は役割ごとに違います。各担当者が自分の観点で読めるように、 問い、viyv の答え、確認すべき証拠、関連ページを分けます。
業務責任者
どの作業時間を削り、どの判断を人間に残すか。
気になること
AI 利用の話は増えているが、現場の作業時間が本当に減るのか、事故が起きた時に誰が責任を持つのかが見えない。
viyv の答え
workflow ごとに、AI に任せる読み取り・要約・下書きと、人間に戻す承認・送信・判断を分けて設計します。
見る証拠
- 利用前後の作業時間
- 下書き品質
- 承認 / 拒否ログ
- 次に広げる workflow
現場担当
AI に任せても、自分が最後に止められるか。
気になること
AI が画面を読み、入力や下書きをしてくれるのは便利だが、誤送信、誤登録、誤返金まで進むと使いづらい。
viyv の答え
Browser の policy と HITL approval で、送信、登録、返金、振込、削除などを実行前に止めます。
見る証拠
- 承認 UI
- 拒否理由
- read-only 画面
- mask された顧客情報
情シス / AI platform
社内 tool を複数 AI client に出しても、管理面が散らからないか。
気になること
Claude、GPT、社内 agent ごとに tunnel、token、OAuth、監査が分かれると、接続先が増えるたびに運用が重くなる。
viyv の答え
MCP と MCP Gateway で connector 開発、registration、public endpoint、token、OAuth、audit metadata を分けて管理します。
見る証拠
- registration 一覧
- token rotation
- tool call metadata
- connector 接続状態
セキュリティ / 法務
AI に渡る情報、止まる操作、残るログを説明できるか。
気になること
AI の便利さよりも、個人情報、顧客情報、業務画面、tool input/output、監査ログの扱いを先に確認したい。
viyv の答え
DOM / screenshot masking、namespace、token scope、HITL、ZDR 方針の audit metadata を検証の証拠として確認します。
見る証拠
- mask 結果
- policy 設定
- approval decision
- metadata のみの audit
管理部門 / 経営
Free、Team、Enterprise のどこから始めるべきか。
気になること
検証が動いても、利用人数、運用責任、監査要件、SSO / SCIM / SIEM の必要性が整理されないと社内説明が進まない。
viyv の答え
検証の最後に、対象 workflow、削減した作業、必要な統制、利用人数、Enterprise 要件を decision packet にします。
見る証拠
- 対象 workflow
- 利用人数
- 運用 owner
- Enterprise 追加条件
AI アプリ開発チーム
AI が作るデータと agent 実行を、実験で終わらせないか。
気になること
AI が作った table、prompt、tool 設定、agent 実行履歴が個人の実験として散らばり、製品運用に載らない。
viyv の答え
viyv DB が purpose / reason 付きで schema 変更を残し、Agent Foundry が definition、deploy、invocation event を管理します。
見る証拠
- migration reason
- rollback
- agent version
- invocation event
Adoption Readiness
運用へ進める状態か、保留すべき状態かを見分ける。
検証が動いても、業務範囲、責任境界、セキュリティ、運用 owner、商用条件が揃っていなければ判断は止まります。管理部門前の readiness を横断で確認します。
業務責任者
業務範囲
Ready
対象 workflow、利用者、入力、AI に任せる作業、人間に戻す判断が 1 枚で説明できる。
Hold
部門全体や複数 workflow が混ざり、30 日で何を証明するかが決まっていない。
見る証拠
workflow brief、対象件数、利用前後の作業時間、次に広げる workflow。
現場 lead / 業務 owner
責任境界
Ready
送信、返金、登録、承認、金額変更、agent publish など責任が残る操作が approval に戻る。
Hold
AI がどこまで実行できるかが曖昧で、事故時に誰が止めるか説明できない。
見る証拠
HITL approval、拒否理由、承認待ち件数、再下書きログ。
セキュリティ / 法務
セキュリティ
Ready
AI に渡る情報、mask する項目、token scope、audit metadata、本文保持方針が整理されている。
Hold
顧客情報、業務画面、tool input/output、ログ保持の扱いが資料化されていない。
見る証拠
mask 前後、policy denial、namespace、token rotation、metadata-only audit。
情シス / AI platform
運用 owner
Ready
policy、connector、agent definition、token、rollback、incident 対応の owner が決まっている。
Hold
検証実施者と本番運用 owner が違い、運用後の問い合わせ先や変更手順が曖昧。
見る証拠
owner map、registration owner、agent owner、rollback 手順、support route。
管理部門 / 経営管理
商用条件
Ready
Free / Team / Enterprise の判断、利用人数、SSO / SCIM / SIEM など追加条件が分かれている。
Hold
検証は成功したが、利用 plan、追加条件、90 日 rollout、予算 owner が未整理。
見る証拠
plan fit、利用人数、Enterprise 条件、90 日 rollout、Go / Hold memo。
Decision Room
レビュー会議で、誰が何を見て判断するか。
検証の最後にログを並べるだけでは、判断は進みません。会議ごとに参加者、最初の問い、 出す証拠、決めることを分けます。
業務部門の Go / Hold 会議
参加者
業務責任者、現場 lead、セキュリティ、利用 owner
最初の問い
この workflow は、現場の作業時間を減らしながら責任境界を守れているか。
出す証拠
利用前後の処理時間、承認待ち件数、拒否理由、下書き修正率、最終判断 approval、次に広げる workflow。
決めること
1 workflow で Team 運用へ進む。送信・登録・返金など高リスク操作は Enterprise 条件の追加レビューに分ける。
情シス / AI platform の標準化会議
参加者
AI platform owner、情シス、セキュリティ、connector 開発者
最初の問い
社内 tool を AI client ごとに個別 tunnel で増やさず、標準 endpoint として運用できるか。
出す証拠
registration、tools/list、namespace、token rotation、revoke 後の失敗、複数 AI client 接続、metadata-only audit。
決めること
read-only connector の標準 route として採用する。write tool 追加、OAuth、SSO / SIEM は Enterprise 要件として整理する。
セキュリティ / 法務レビュー
参加者
情報セキュリティ、法務、DPO / privacy、管理部門
最初の問い
AI に渡る情報、保存される情報、止まる操作、監査 metadata を説明できるか。
出す証拠
mask 前後、policy denial、approval decision、namespace、token scope、tool metadata、本文保持方針、運用 owner。
決めること
対象 workflow と data boundary を限定して判断に進む。DPA、retention、SIEM、SSO が必要な場合は Enterprise 条件に移す。
管理部門 / 経営のレビュー会議
参加者
管理部門、経営管理、業務 owner、platform owner
最初の問い
Free / Team / Enterprise のどこで始めれば、効果と統制を説明できるか。
出す証拠
対象 workflow、利用人数、運用 owner、削減時間、残す人間判断、Enterprise 追加条件、90 日 rollout。
決めること
Team で始められる範囲と Enterprise が必要な条件を分ける。運用後の最初の 90 日で追加 workflow と owner を固定する。
Adoption Review Scenarios
検証後の会議で、Go / Hold を判断する。
判断では、成功条件だけでなく保留条件も先に決めます。どの証拠が揃えば運用へ進み、 何が欠けたら再検証するかをシナリオ別に分けます。
審査責任者
KYC / 審査レビューで Team 運用へ進む
会議に出す証拠
過去 10 件で確認時間が短縮し、PII mask、read-only、最終判定 approval、差戻理由が揃っている。
Go 条件
審査補助として使い、最終判定は人間に残す。Team で 3〜5 名から開始し、次月に継続的顧客管理へ広げる。
Hold 条件
mask できない項目が残る、または承認なしで判定操作へ進める場合は、policy 設計を戻して再検証する。
CS Ops / 品質管理
CS 回答 / 返金判断で部門展開へ進む
会議に出す証拠
問い合わせ 30 件で一次回答時間、下書き修正率、送信前 approval、返金拒否理由、再下書き品質を比較できる。
Go 条件
回答下書きは Team で運用開始し、返金と契約変更は Enterprise 条件のセキュリティレビューに進める。
Hold 条件
回答根拠が不足する、拒否理由が次の下書きへ反映されない、送信前レビューが現場負荷を増やす場合は対象カテゴリを絞る。
AI platform owner
MCP Gateway を platform 標準にする
会議に出す証拠
read-only API 1 つで tools/list、複数 AI client 接続、token revoke、registration audit、metadata-only log を確認できる。
Go 条件
新規 connector 申請の標準 route に置き、write tool 追加だけ別 approval にする。Enterprise 要件は SSO / SIEM から判断する。
Hold 条件
namespace の owner が決まらない、token rotation の責任が曖昧、本文ログの扱いを説明できない場合は platform 運用設計を先に固める。
AI アプリ責任者
DB / Agent Foundry を AI アプリ運用へ載せる
会議に出す証拠
schema 変更理由、rollback、semantic search、agent version、run history、参照 data の説明が揃っている。
Go 条件
1 つの調査 / 業務メモリを本番 workflow にし、次の 90 日で部門 agent と evaluation packet を増やす。
Hold 条件
AI が作った table の owner が曖昧、根拠 URL が残らない、agent publish の承認者が決まらない場合は運用 owner を先に決める。
Decision Memo Templates
社内説明に貼れる文章まで、検証の出口を具体化する。
本番利用に進める状態とは、担当者が「何を使うか」だけでなく「なぜ今使うか」を 説明できる状態です。代表的な memo を業務別に用意します。
審査責任者
KYC / 審査補助を Team で開始する
現状の問題
本人確認、制裁リスト、顧客台帳の横断確認に時間がかかり、AI 活用は PII と最終判定の責任境界で止まっている。
提案
viyv Browser で許可済み画面だけを read-only 参照し、AI は照合メモと差戻理由を下書きする。承認、差戻、凍結は HITL approval に戻す。
検証の証拠
10 件の確認時間、PII mask、approval decision、差戻理由、policy denial を検証証拠として提出する。
承認依頼
3〜5 名の Team 運用で審査補助を開始し、継続的顧客管理への拡張可否を 30 日後に判断する。
CS Ops / 品質管理
CS 一次回答を部門 workflow にする
現状の問題
チケット、契約情報、FAQ、admin を横断して回答を作っており、AI 下書きは便利だが誤送信と返金判断が利用を止めている。
提案
Agent Foundry の CS agent と Browser read-only を使い、回答文と社内メモを下書きする。送信、返金、契約変更は approval 待ちにする。
検証の証拠
問い合わせ 30 件の一次回答時間、下書き修正率、送信 approval、返金拒否理由、再下書き品質を提出する。
承認依頼
回答下書きは Team で開始し、返金・契約変更は Enterprise 条件の security review に分ける。
AI platform owner
MCP Gateway を connector 標準にする
現状の問題
部署ごとに MCP server、token、OAuth、tunnel、監査方法が増え、AI client 追加のたびにレビューが発生している。
提案
viyv MCP で read-only tool を標準化し、MCP Gateway で registration、endpoint、token、OAuth、metadata audit を中央管理する。
検証の証拠
tools/list、namespace、token revoke、複数 AI client 接続、metadata-only audit、connector 状態を提出する。
承認依頼
read-only connector 申請の標準 route として採用し、write tool と SSO / SIEM は Enterprise 条件にする。
AI アプリ責任者
AI アプリの DB / Agent 運用を本番化する
現状の問題
AI が作った table、調査メモリ、prompt、agent 実行履歴が個人実験として散り、業務 workflow に残らない。
提案
viyv DB で purpose / reason 付き schema 変更と rollback を管理し、Agent Foundry で agent version と invocation event を管理する。
検証の証拠
schema 変更理由、rollback 実演、semantic search、agent version、run history、参照 data を提出する。
承認依頼
1 つの調査 / 業務メモリを本番 workflow にし、90 日で部門 agent と監査 packet を増やす。
Objection Handling
社内説明で出る反論を、検証の証拠で返す。
判断では、期待よりも懸念の方が具体的に出ます。よくある反論を先に想定し、検証 でどの証拠を集めれば回答できるかを決めます。
業務責任者
AI 利用で現場が混乱し、結局レビュー工数が増えるのでは。
回答
検証は 1 workflow に絞り、AI の役割を読み取り・要約・下書きに限定します。承認待ち件数、拒否理由、再作業時間を測り、増えた工数も判断材料に入れます。
必要な証拠
Before / After 作業時間、承認待ち件数、拒否理由、下書き修正率。
現場担当
AI が勝手に送信や登録を進めるなら使いたくない。
回答
送信、返金、登録、振込、削除は HITL approval で止めます。拒否した理由は AI に戻り、次の下書きへ反映できます。
必要な証拠
承認 modal、拒否理由、read-only policy、再下書きログ。
情シス / AI platform
AI client ごとに connector と token が増えると運用できない。
回答
MCP Gateway に registration、public endpoint、token rotation、tool metadata を寄せ、Claude / GPT / 社内 agent から同じ connector を呼べるようにします。
必要な証拠
registration 一覧、tools/list、token revoke、複数 client 接続ログ。
セキュリティ / 法務
顧客情報や tool input/output が AI 側やログに残る説明ができない。
回答
Browser は AI に渡す前に DOM / screenshot を mask し、MCP は namespace / token scope で実行範囲を分けます。audit は本文ではなく metadata を中心に残します。
必要な証拠
mask 前後、policy 設定、tool call metadata、approval decision。
Approval Packet
社内説明に、そのまま載せる説明を用意する。
viyv は「AI が便利そう」では判断を進めません。誰が何を依頼し、どのリスクをどう止め、 どの数字で Go / No-Go を決めるかを、検証開始時点で文章にします。
業務責任者 / 現場 lead
業務部門からの承認依頼
現在の状況
KYC、CS、調達、請求書例外など、担当者が複数画面を見て判断メモや回答下書きを作っている。
承認してほしいこと
30 日の検証で 1 workflow を選び、AI には読み取り・要約・下書きまでを任せ、送信・登録・返金・承認は人間に戻す。
Go / No-Go 条件
対象件数、平均処理時間、下書き修正率、承認待ち件数、拒否理由を測り、Team 運用へ進むかを判断する。
AI platform / 情シス開発
情シス / AI platform からの承認依頼
現在の状況
部署ごとに MCP connector や AI client 接続が増え、token、endpoint、監査 metadata、公開範囲がばらつき始めている。
承認してほしいこと
read-only connector を 1 つ MCP / Gateway へ載せ、複数 AI client から同じ endpoint を呼べるか、token rotation と revoke が効くかを確認する。
Go / No-Go 条件
registration 一覧、namespace、tools/list、tool call metadata、revoke 後の失敗ログを出し、標準 connector 基盤として採用できるかを判断する。
管理部門 / セキュリティ / 法務
管理部門 / セキュリティへの承認依頼
現在の状況
AI 活用の要望はあるが、顧客情報、業務画面、tool input/output、監査ログ、SSO / SCIM 要件の説明が揃わない。
承認してほしいこと
検証中に mask 前後、policy、approval decision、metadata audit、利用人数、Enterprise 条件を decision packet にまとめる。
Go / No-Go 条件
Team で開始できる条件、Enterprise が必要な条件、利用前に追加確認する条件を分け、社内説明で反論が残らない状態にする。
Internal Meeting
社内説明は、この順番で進める。
検証前のキックオフや、検証後のレビュー会議で使える順番です。
業務から始める
対象 workflow、担当者、作業頻度、失敗した時の影響を最初に固定します。
AI と人間の境界を分ける
AI に任せる読み取り・下書きと、人間に戻す判断・送信・登録を分けます。
証拠を先に決める
作業時間、mask、approval、tool metadata、migration reason、agent event を受け入れ条件にします。
運用条件へ落とす
Team で足りるか、SSO / SCIM / SIEM / VPC など Enterprise 条件が必要かを判断します。