業務責任者 / 現場 lead
現場で毎日繰り返す作業を選ぶ
選ぶ候補
KYC の一次確認、CS 一次回答、請求書例外など、担当者が複数画面を見て同じ判断メモを作る業務。
避ける候補
年に数回しか起きない例外、owner が曖昧な横断業務、AI に任せる範囲がまだ決まっていない業務。
初回実行
過去 10〜30 件を使い、AI の読み取り・要約・下書きが現場の確認時間を減らすかを見る。
判断材料
Before / After、下書き修正率、担当者の再確認回数、次に広げる workflow。
Workflow Library
自社業務から、
viyv の使い方を見る。
製品名ではなく、KYC、CS、調達、経理、AI platform、リサーチのような実業務から検証 対象を選びます。現在の問題、viyv を入れた後の流れ、必要な統制、判断材料まで具体化します。
Workflow Selection Board
最初の workflow は、
判断材料から選ぶ。
検証は「AI が動くか」ではなく、現場の作業時間、危険操作の停止、社内 tool の境界、AI データの再利用を説明できるかを見る場です。最初の workflow を選ぶ時点で、誰が何を確認するかを分けます。
現場 lead / セキュリティ
人間に戻す判断が明確な業務を選ぶ
選ぶ候補
送信、返金、登録、支払先変更、金額変更、最終判定など、事故時の責任が明確な操作を含む業務。
避ける候補
危険操作が言語化されていない業務、承認者が決まっていない業務、拒否理由を残せない業務。
初回実行
AI は下書きまで進め、危険操作は全件 HITL approval に戻す。拒否理由が再下書きに反映されるか確認する。
判断材料
承認待ち件数、拒否理由、policy denial、再下書き品質、承認者。
情シス / AI platform
社内 tool 接続が増えている業務を選ぶ
選ぶ候補
部署ごとに API connector や MCP server の相談が増え、token、OAuth、監査 metadata が散らかり始めた業務。
避ける候補
単発の個人 automation、write tool の責任者が決まっていない connector、利用部門が未定の API。
初回実行
read-only API を 1 つ MCP 化し、Gateway 経由で 2 種類以上の AI client から同じ endpoint を呼ぶ。
判断材料
tools/list、namespace、token rotation、revoke、複数 client 接続、metadata-only audit。
Data owner / AI app owner
AI の出力を次回も使う業務を選ぶ
選ぶ候補
調査メモ、請求書例外、顧客分類、agent 実行履歴など、AI の判断理由を保存して次回に使いたい業務。
避ける候補
保存する record の owner が決まらない業務、schema 変更理由を説明できない業務、根拠 URL が残らない調査。
初回実行
purpose 付き table と record を作り、必要な列追加には reason を残す。後続 agent が検索して再利用する。
判断材料
semantic search、schema change reason、rollback、agent run history、参照 data。
Adoption Routes
workflow ごとに、使う理由と反対理由を先に分ける。
利用検討では、便利そうな demo より「誰が、何を見て、どの不安を解消して使うか」が重要です。 workflow ごとに最初の証拠、よく出る反対、答え方を整理します。
How To Pick
最初の workflow は、効果と統制が同時に見えるものを選ぶ。
AI ができることから始めると、検証が demo で終わりがちです。業務頻度、危険操作、 証拠の残しやすさから逆算します。
最初の workflow を 1 つ選ぶ
部門全体ではなく、日次・週次で繰り返され、AI に読み取りや下書きを任せやすい業務から始めます。
AI に任せる範囲を分ける
読む、探す、要約する、下書きする、tool を呼ぶ、schema を変える、実行する、のどこまでを任せるかを固定します。
人間に戻す操作を決める
送信、削除、返金、振込、登録、承認、金額変更、agent 実行など、責任が残る操作を approval に戻します。
判断材料を残す
作業時間、mask、approval decision、tool metadata、migration reason、agent event を検証の受け入れ条件にします。
Validation Week Runbook
最初の 1 週間で、判断に必要な会話を前倒しする。
30 日の検証を始める前に、最初の 4 日で scope、data boundary、実務再現、商用判断を 固定します。ここを曖昧にすると、検証は動いても社内説明で止まります。
Day 1
対象 workflow と責任境界を固定する
会議
業務責任者、現場 lead、情シス、セキュリティで、対象件数、AI に任せる作業、人間に戻す操作を決める。
成果物
workflow brief、許可画面 / tool、危険操作リスト、承認者、検証合格条件。
戻す条件
ここで workflow が広すぎる場合は、検証を始めず 1 業務へ戻す。
Day 2
AI が読む範囲と mask / tool scope を通す
会議
許可 URL、read-only、mask、namespace、token scope、metadata audit を確認する。
成果物
policy 設定、mask 前後、tools/list、token owner、監査 metadata のサンプル。
戻す条件
顧客情報や tool output の扱いを説明できなければ、判断ではなく追加設計に戻す。
Day 3
過去データで実務の流れを再現する
会議
過去 10〜30 件で AI の読み取り・要約・下書き・承認待ちを回し、現場が実際に修正する。
成果物
作業時間、下書き修正率、承認待ち件数、拒否理由、再下書き品質。
戻す条件
現場確認が増えるなら workflow を絞る。危険操作が止まらないなら policy を戻す。
Day 4
レビューに出す evidence を整理する
会議
業務、情シス、セキュリティ、管理部門で同じ evidence を見て、Team / Enterprise / Hold を分ける。
成果物
Proof Pack、Go / Hold memo、Plan fit、Enterprise 追加条件、90 日 rollout。
戻す条件
owner、証拠、商用条件が揃わない場合は、判断ではなく 2 週間の追加検証に戻す。
Starter Matrix
最初に選ぶ workflow を、現場の詰まりで決める。
「どれから試すか」が曖昧だと、検証は広がりすぎます。業務頻度、危険操作、社内 tool、 AI データのどこに詰まりがあるかで、最初の 1 workflow を決めます。
日次で画面横断が多い
始める候補
KYC / 審査レビュー、CS 回答、請求書例外
選ぶ理由
担当者の確認時間が測りやすく、AI の読み取り・要約・下書きの効果を短期間で比較できます。
見る証拠
作業時間、下書き修正率、read-only、mask、approval decision。
危険操作を止めたい
始める候補
CS 返金、取引先登録、請求書金額変更
選ぶ理由
送信、返金、支払先変更、金額変更のように、人間に戻すべき操作が明確です。
見る証拠
承認待ち、拒否理由、二者承認、policy denial。
社内 tool 接続が増えている
始める候補
社内 MCP connector 申請
選ぶ理由
複数 AI client に同じ tool を配る課題があり、Gateway の価値を technical buyer に見せやすい。
見る証拠
tools/list、namespace、token rotation、複数 client 接続、tool metadata。
AI の出力を次回も使いたい
始める候補
競合調査 / 業務メモリ、請求書例外
選ぶ理由
AI が作った table、分類、signal、agent history を保存し、次の実行へ再利用する価値を示せます。
見る証拠
purpose、schema 変更 reason、semantic search、rollback、agent run history。
Workflow Brief Templates
検証計画に持ち込む情報を、workflow ごとに揃える。
「この業務で試したい」と言うだけでは、検証 範囲が広がります。最初に持ち込む入力、初回実行、止める操作、判断材料を揃えると、 30 日の検証が設計しやすくなります。
KYC / 審査レビュー
持ち込む情報
過去審査 10 件、確認観点、許可ドメイン、mask したい PII、最終判定ボタン。
初回実行
AI に顧客 ID と確認観点を渡し、照合メモを下書きさせる。承認、差戻、凍結は全件 approval 待ちにする。
止める操作
本人確認ステータス変更、リスクランク変更、凍結 / 承認 / 差戻。
判断材料
平均確認時間、mask 証跡、read-only、approval decision が揃えば Team 検討へ進む。
CS 回答 / 返金判断
持ち込む情報
問い合わせ 30 件、FAQ、契約情報の参照画面、返金条件、送信前レビュー担当。
初回実行
AI がチケット、契約状況、過去対応を読み、回答文と返金可否メモを下書きする。
止める操作
メール送信、返金実行、契約変更、顧客情報更新。
判断材料
一次回答時間、下書き修正率、拒否理由、返金 approval が説明できれば部門検証へ広げる。
取引先登録 / 調達申請
持ち込む情報
過去申請 5 件、会社情報、契約書、反社チェック API、支払先変更ルール。
初回実行
AI が会社情報と運用条件を照合し、取引先登録下書きと不足情報リストを作る。
止める操作
新規登録、支払先変更、調達申請の最終承認。
判断材料
登録準備時間、支払先変更 approval、tool metadata が揃えば管理部門・経理レビューへ進む。
請求書例外 / 入金消込
持ち込む情報
過去請求書例外 20 件、運用条件、入金 CSV、会計画面、金額変更ルール。
初回実行
AI が差異候補を抽出し、viyv DB に例外分類と照合理由を purpose 付きで保存する。
止める操作
金額変更、消込実行、支払保留 / 解除。
判断材料
例外分類の再現率、金額変更 approval、migration reason、rollback が見えれば本番検討へ進む。
社内 MCP connector 申請
持ち込む情報
read-only API 1 つ、利用部門、namespace 案、token owner、接続したい AI client。
初回実行
viyv MCP で tool を定義し、Gateway 経由で Claude / GPT / 社内 agent から同じ endpoint を呼ぶ。
止める操作
write tool 追加、public token 発行、registration 有効化。
判断材料
tools/list、token rotation、revoke、複数 client 接続が確認できれば platform 標準化へ進む。
競合調査 / 業務メモリ
持ち込む情報
調査テーマ、比較軸、対象サイト、保存したい signal、公開資料へ転記する条件。
初回実行
AI が signal table を作り、調査中に必要な列を reason 付きで追加し、過去 signal を検索する。
止める操作
重要示唆の採用、外部共有資料への転記、agent publish。
判断材料
schema 変更理由、根拠 URL、semantic search、agent run history が見えれば DB / Foundry 運用へ進む。
Workflow Scenarios
具体的に、こう使う。
各 workflow は、現場担当者が読んで自分の業務に置き換えられる粒度まで落としています。
Financial Operations
KYC / 審査レビュー
コンプライアンス、審査、金融 backoffice
今の問題
本人確認、制裁リスト、顧客台帳、取引画面を人間が横断している。AI に照合や要約を任せたいが、個人番号、口座番号、最終判定が AI 側へ流れる懸念で止まりやすい。
始めるきっかけ
新規口座開設、継続的顧客管理、取引モニタリングの一次確認。
viyv を入れた後
- 担当者が顧客 ID と確認観点を AI に渡す
- Browser が許可済み KYC / 制裁リスト / 台帳画面だけを AI に読ませる
- AI が照合結果、差分、確認メモを下書きする
- 承認、差戻、凍結、登録などの最終操作は HITL approval で止める
担当者の操作
- 顧客 ID と確認観点を AI に渡す
- AI の照合メモを審査画面の横で確認する
- 差分がある項目だけ原本画面で再確認する
人間に戻す判断
- 承認 / 差戻 / 凍結
- 本人確認ステータス変更
- リスクランク変更
失敗時の止め方
- 制裁リスト結果が曖昧なら自動判定せず差戻メモにする
- mask 対象が検出されたら AI への再送信を止める
- 許可外ドメインへ遷移したら policy denial として記録する
検証合格条件
- レビュー 10 件で平均確認時間を比較できる
- 最終判定ボタンが全件 approval 待ちになる
- PII mask と承認ログをセキュリティレビューに出せる
統制
- KYC ドメイン allow
- 顧客台帳 read-only
- PII mask
- 最終判定 HITL
成果物
- 審査メモ
- 照合差分
- 差戻理由
- 承認 / 拒否ログ
判断材料
- レビュー時間の短縮
- mask された項目
- approval decision
- read-only policy
最初の 30 日
まず 1 つの審査種別に絞り、3〜5 名で読み取り、下書き、承認待ちの流れを確認します。最終週にレビュー時間、拒否理由、mask 証跡を並べ、部門展開の可否を判断します。
現場指標: 平均確認時間、差戻率、担当者の再確認回数
統制指標: PII mask、read-only policy、最終判定 approval
導入判断: 審査補助として使い、最終判断は人間に残せるか
viyv BrowserViyv MCP Gateway
Customer Operations
CS 回答 / 返金判断
CS Ops、サポート、業務企画
今の問題
チケット、契約情報、FAQ、自社 admin を見ながら回答を作っている。AI で一次回答を速くしたいが、顧客情報の露出、誤送信、返金判断の責任境界が曖昧。
始めるきっかけ
問い合わせ一次回答、返金可否確認、契約変更依頼、障害影響調査。
viyv を入れた後
- Agent Foundry で CS 調査 agent を定義する
- Browser がログイン済み admin とチケット画面を read-only で参照する
- AI が回答文、社内メモ、返金可否の根拠を下書きする
- 送信、返金、登録、契約変更は承認待ちにして担当者へ戻す
担当者の操作
- チケット ID と顧客の要望を AI に渡す
- AI が契約状況、FAQ、過去対応を確認した要約を見る
- 回答文を修正し、送信前 approval で最終確認する
人間に戻す判断
- メール / チケット送信
- 返金実行
- 契約変更 / 登録情報変更
失敗時の止め方
- 回答根拠が不足している場合は送信せず調査メモに戻す
- 返金条件が曖昧な場合は承認者に escalate する
- 顧客情報が mask されない場合は AI 呼び出しを拒否する
検証合格条件
- 対象カテゴリで一次回答時間を比較できる
- 送信と返金が全件 approval 待ちになる
- 拒否理由が AI の再下書きに反映される
統制
- admin read-only
- 送信 / 返金 HITL
- 電話番号 mask
- agent version
成果物
- 回答下書き
- 社内調査メモ
- 返金判断メモ
- 拒否理由
判断材料
- 一次回答時間
- 送信前 approval
- 拒否理由
- 問い合わせ履歴の再利用
最初の 30 日
よくある問い合わせカテゴリを 1 つ選び、回答下書きと送信前承認を検証します。返金や契約変更は実行せず、承認 UI と audit をレビュー対象にします。
現場指標: 一次回答時間、下書き修正率、SLA 影響
統制指標: 送信 / 返金 approval、顧客情報 mask、拒否理由
導入判断: CS 品質を落とさず、責任境界を人間へ戻せるか
viyv Agent Foundryviyv Browserviyv DB
Vendor Operations
取引先登録 / 調達申請
管理部門、経理、総務、内部統制
今の問題
新規取引先登録は、会社情報、反社チェック、与信、契約書、振込先を複数画面で確認する。AI に下調べを任せたいが、登録、支払先変更、承認操作は誤ると影響が大きい。
始めるきっかけ
新規ベンダー登録、支払先変更、調達申請、契約更新前チェック。
viyv を入れた後
- AI が会社情報、契約書、過去取引、公開情報を読み取る
- Browser が取引先管理画面を read-only で参照し、登録内容を下書きする
- MCP が社内チェック API や申請情報を権限付き tool として渡す
- 登録、支払先変更、承認ボタンは全件 HITL approval に戻す
担当者の操作
- 申請番号、会社名、契約書 URL を AI に渡す
- AI が公開情報、社内チェック、契約条件を照合する
- 不足情報と登録下書きを管理部門の担当者が確認する
人間に戻す判断
- 新規取引先登録
- 支払先 / 振込先変更
- 調達申請の最終承認
失敗時の止め方
- 会社情報の一致率が低い場合は登録下書きを作らず不足情報にする
- 支払先変更を検出したら必ず二者承認にする
- namespace 外の社内 API 呼び出しは拒否して metadata に残す
検証合格条件
- 既存申請 5 件で登録準備時間を比較できる
- 支払先変更が approval なしに進まない
- 社内チェック API の tool call metadata を確認できる
統制
- vendor admin read-only
- 支払先 mask
- 登録 HITL
- MCP namespace
成果物
- 取引先登録下書き
- チェック結果
- 不足情報リスト
- 承認ログ
判断材料
- 登録準備時間
- 支払先変更の停止
- tool call metadata
- 承認者と拒否理由
最初の 30 日
新規登録ではなく、既存申請の再現から始めます。AI の下書き精度、支払先変更の停止、社内 API 接続の audit を確認してから本番申請に近づけます。
現場指標: 登録準備時間、不足情報の検出率、再申請数
統制指標: 支払先変更 approval、namespace 拒否、tool metadata
導入判断: 下調べを短縮し、登録と支払先変更を安全に止められるか
viyv Browserviyv MCPViyv MCP Gateway
Finance Operations
請求書例外 / 入金消込
経理、財務、経営管理
今の問題
請求書、発注書、契約、入金データを照合し、例外だけを人間が判断する運用にしたい。既存システムは API 化されておらず、照合理由や例外分類も属人的に残りやすい。
始めるきっかけ
月次締め、未入金確認、請求書差異、契約条件との照合。
viyv を入れた後
- AI が請求書と契約条件を読み、差異候補を抽出する
- viyv DB が例外分類と照合メモを purpose 付き table として保存する
- Browser が会計画面を read-only で確認し、修正案だけを下書きする
- 消込、金額修正、支払保留は人間承認に戻す
担当者の操作
- 請求書、発注書、契約条件、入金 CSV を AI に渡す
- AI が差異候補を分類し、例外 table に理由を残す
- 経理担当が修正案だけを会計画面で確認する
人間に戻す判断
- 金額変更
- 消込実行
- 支払保留 / 解除
失敗時の止め方
- 契約条件と請求書の照合根拠がない場合は例外として保留する
- 金額変更が発生したら必ず approval と理由入力を求める
- 誤った分類 table は migration reason から rollback する
検証合格条件
- 過去例外で分類理由が再現できる
- 金額変更が approval なしに進まない
- schema 変更と rollback を実演できる
統制
- 会計画面 read-only
- 金額変更 HITL
- purpose / reason
- rollback
成果物
- 例外一覧
- 照合理由
- 修正案
- rollback 可能な変更履歴
判断材料
- 例外処理時間
- 金額変更の停止
- migration reason
- rollback 実演
最初の 30 日
まず過去の請求書例外を使い、AI が例外分類 table を作る流れを検証します。金額変更は実行せず、reason と rollback を合格条件に入れます。
現場指標: 例外処理時間、分類の再現率、保留件数
統制指標: 金額変更 approval、migration reason、rollback
導入判断: 経理の例外判断を速め、金額変更の責任を人間に残せるか
viyv DBviyv Browser
AI Platform
社内 MCP connector 申請
情シス、AI platform、developer productivity
今の問題
社内 API を AI に渡したい相談が増えるが、MCP server、token、OAuth、公開 URL、監査が案件ごとにばらつく。セキュリティレビューも毎回やり直しになる。
始めるきっかけ
新しい社内 API connector、部署別 AI agent、Claude / GPT への tool 追加申請。
viyv を入れた後
- viyv MCP で read-only tool から connector を作る
- namespace、clearance、JWT を定義し、tools/list と tools/call を制御する
- MCP Gateway に outbound 接続し、標準 remote MCP endpoint を発行する
- public token、OAuth、registration、tool metadata を中央で管理する
担当者の操作
- 対象 API と利用部門を 1 つ選び、read-only tool から定義する
- namespace と clearance を付けて tools/list の見え方を確認する
- Gateway endpoint を Claude / GPT の両方に設定する
人間に戻す判断
- write tool 追加
- public token 発行
- registration 有効化 / 無効化
失敗時の止め方
- 想定外 namespace の tool は tools/list に出さない
- connector が切断したら endpoint 側で失敗 metadata を返す
- token 漏洩時は registration 単位で rotation / revoke する
検証合格条件
- 同じ MCP を 2 種類以上の AI client から呼べる
- token rotation と revoke を管理画面で説明できる
- tool input/output 本文なしで metadata を確認できる
統制
- deny-all 既定
- namespace
- registration
- token rotation
成果物
- connector 登録
- tool schema
- public endpoint
- audit metadata
判断材料
- 1 MCP の複数 client 接続
- token 失効
- tool call metadata
- connector 状態
最初の 30 日
部署横断で使う read-only API を 1 つ選び、Claude と GPT の両方から同じ endpoint を呼びます。write tool は後回しにし、認可と audit を先に通します。
現場指標: connector 追加時間、client 追加時の設定差分
統制指標: namespace、token rotation、registration audit
導入判断: 社内 MCP を vendor 別 tunnel ではなく標準 endpoint で配れるか
viyv MCPViyv MCP Gateway
Research / Strategy
競合調査 / 業務メモリ
事業開発、プロダクト、リサーチ、R&D
今の問題
調査中に新しい評価軸や signal が見つかるたび、人間が表を作り直す。AI が集めた情報も一時的な会話に残り、後続の調査や agent 実行へつながりにくい。
始めるきっかけ
競合比較、価格調査、規制調査、顧客インサイト整理、事業仮説検証。
viyv を入れた後
- AI が調査テーマに合わせて logical table を purpose 付きで作る
- Browser や MCP から収集した signal を DB に保存する
- 必要な列を reason 付きで追加し、semantic search で再利用する
- Agent Foundry が調査 agent の version と run history を保存する
担当者の操作
- 調査テーマ、比較軸、収集対象サイトを AI に渡す
- AI が signal table を作り、発見した情報を分類して保存する
- 途中で追加された列と reason を人間が確認する
人間に戻す判断
- 重要示唆の採用
- 外部共有資料への転記
- agent の publish / deploy
失敗時の止め方
- 根拠 URL がない signal は採用せず確認待ちにする
- 列追加の reason が曖昧なら migration を拒否する
- agent 出力が古い table を参照した場合は run を差し戻す
検証合格条件
- 調査中の schema 変更理由を後から説明できる
- semantic search で過去 signal を再利用できる
- agent version と run history を追跡できる
統制
- purpose 必須
- alter reason
- semantic search scope
- agent version
成果物
- 市場 signal table
- 競合比較
- 調査メモリ
- agent run history
判断材料
- schema 変更理由
- 検索再利用率
- rollback
- agent event
最初の 30 日
既存調査テーマを 1 つ選び、AI が table を作るところから始めます。途中で列追加を発生させ、reason、検索、rollback が説明できるか確認します。
現場指標: 過去 signal の再利用率、調査 table の更新速度
統制指標: schema 変更 reason、根拠 URL、agent version
導入判断: AI の調査結果を一時的な会話ではなく業務メモリとして運用できるか
viyv DBviyv Agent Foundryviyv Browser
After 検証
1 workflow の証拠を、次の展開へ変える。
検証の最後に「よかった」で終わらせず、同じ部門、社内 connector、agent 運用、 判断材料 packet のどこへ広げるかを決めます。
同じ部門で workflow を増やす
KYC から継続的顧客管理へ、CS 返金から契約変更へ、同じ owner と承認ルールで範囲を広げます。
画面操作から MCP connector へ移す
最初は Browser で既存画面を扱い、効果が見えた API は MCP / Gateway に移して標準 tool にします。
下書きから agent 運用へ移す
人間が修正していた下書きパターンを Agent Foundry に登録し、version と run history を追えるようにします。
検証証拠を確認 packet にする
作業時間、mask、approval、tool metadata、migration reason を Proof / Buyers / Pricing の判断材料へ変換します。
Next Step
自社の workflow を 1 つ選んで検証に落とす。
似ている workflow があれば、対象画面、社内 tool、人間に戻す操作、残したい証拠を 30 日の検証計画に変えます。