Business Owner
現場の作業時間と再作業は、本番利用に足るだけ減るか。
見る証拠
同じ件数の Before / After、下書き修正率、承認待ち件数、現場担当者が増やす確認作業。
判断への変え方
効果が出て、追加レビュー負荷が許容できるなら Team 開始。効果が薄いなら workflow 選定へ戻す。
Evaluation
viyv を必要な状態か、先に判断する。
viyv は AI そのものでも、単なる workflow tool でもありません。AI が業務システムへ届く地点に、 実行・接続・データ・agent の統制境界を置くための suite です。
Evaluation Decision Room
評価会議で、誰が何を見て提案するかを分ける。
比較表だけでは社内判断に進みません。同じ workflow の証拠を、業務 owner、Security、 Platform、Operations がそれぞれ見て、Team 開始、Enterprise 条件、追加 検証、別案のどれに進むかを決めます。
Security / Legal
AI に渡るデータと実行環境を、社内レビューで説明できるか。
見る証拠
mask 前後、read-only、token scope、metadata-only audit、本文保存方針。
判断への変え方
顧客情報の境界を説明できるなら Go。mask 対象や retention が未確定なら Enterprise 条件か追加検証。
Platform Owner
connector と AI client が増えても、運用が散らからないか。
見る証拠
registration、namespace、tools/list、token rotation / revoke、複数 AI client 接続ログ。
判断への変え方
標準 endpoint と owner が決まるなら Enterprise 条件へ。単一 client 実験なら別案でもよい。
Executive / Operations
なぜ今 viyv を必要なか、別案ではない理由を説明できるか。
見る証拠
選ばなかった案の理由、Plan recommendation、残リスク、90 日 rollout、運用条件に入れる条件。
判断への変え方
運用条件まで書けるなら Go。証拠がログの羅列なら Hold にして decision packet を作り直す。
Evidence Packets
業務ごとに、比較材料を判断材料へ変える。
評価会議に必要なのは、抽象的な機能比較ではありません。対象業務、代替案、同じ件数での test run、viyv で出す証拠、判断に進む条件を 1 packet にまとめます。
KYC / 審査レビュー
本人確認、制裁リスト、顧客台帳を AI に読ませたいが、PII と最終判定を外へ出せない。
比較する相手
クラウド AI browser、Playwright 自作、既存審査 admin の手作業。
同じ条件で試すこと
過去審査 10 件で、AI には照合メモと差戻理由だけを作らせる。承認、差戻、凍結、リスクランク変更は実行させない。
レビューに出す証拠
mask 前後、読み取り専用、危険操作の denial、承認ログ、確認時間、差戻理由の一貫性。
採用条件
顧客情報を扱う本番画面でデータ境界と停止点を説明できるなら、審査補助として Team 開始。
Customer Support / 返金判断
問い合わせ、運用条件、返金ルールを AI が読めば速くなるが、誤送信と返金実行の責任境界が曖昧。
比較する相手
個人 prompt、FAQ bot、既存 workflow tool、CS admin の手作業。
同じ条件で試すこと
問い合わせ 30 件で、回答下書き、社内メモ、返金可否の根拠を作る。メール送信、返金実行、契約変更は止める。
レビューに出す証拠
一次回答時間、下書き修正率、送信前承認、返金拒否理由、再下書き品質、担当者の追加確認時間。
採用条件
回答下書きは Team、返金・契約変更は Enterprise の security review 条件として切り分ける。
AI Platform / MCP connector
1 つ目の MCP は作れても、部署ごとに token、namespace、監査、AI client 接続が散らかる。
比較する相手
内製 MCP server、AI ベンダー別 connector、個別 tunnel。
同じ条件で試すこと
読み取り専用 API 1 つを Claude / GPT / 社内 agent から呼び、write tool は入れず運用だけを比較する。
レビューに出す証拠
tools/list、registration、token rotation、revoke 後の失敗、複数 AI 接続、本文なし metadata audit。
採用条件
connector を増やす前提なら、標準 endpoint、owner、監査方式を Enterprise 条件として詰める。
Finance / 請求書例外
請求書例外や入金消込を AI に下書きさせたいが、金額変更、支払先変更、会計登録は止めたい。
比較する相手
既存 RPA、workflow tool、スプレッドシート運用、会計画面の手作業。
同じ条件で試すこと
請求書例外 20 件で、差異分類、照合理由、例外 table 保存を試す。金額変更と支払先変更は承認待ちにする。
レビューに出す証拠
例外処理時間、分類再現率、金額変更承認、purpose / reason、rollback、支払先変更の二者承認。
採用条件
固定 RPA ではなく AI が例外分類と data model を更新する価値が出るなら、経理業務へ段階利用。
Alternatives
他の選択肢と、どこが違うか。
viyv が常に最適とは限りません。検討者が現実的に比較する選択肢ごとに、向いていること、 詰まりやすいこと、viyv が補う境界を整理します。
自作で browser / MCP / agent 実行をつなぐ
向いていること
最初の demo は速い。自社要件だけに合わせられる。
詰まりやすいこと
policy、HITL、masking、token、audit、rollback、agent event が別々に実装され、セキュリティレビューのたびに説明が増える。
viyv が補うこと
実行・接続・データ・agent の境界を suite として用意し、validation evidence まで一貫して見せられます。
クラウド AI browser を使う
向いていること
セットアップが軽く、ブラウザ操作の体験は早く試せる。
詰まりやすいこと
ログイン済み画面、DOM、スクリーンショット、操作履歴が外部実行環境に寄りやすく、金融・人事・顧客情報で止まりやすい。
viyv が補うこと
ローカル / VPC 実行、masking、read-only、approval を使い、実ブラウザ操作を企業の統制下に置きます。
AI ベンダーごとの tunnel / connector を使う
向いていること
単一 vendor の中では設定がまとまりやすい。
詰まりやすいこと
Claude 用、GPT 用、社内 agent 用で MCP 公開、token、OAuth、監査が分かれ、将来の client 追加で運用が増える。
viyv が補うこと
MCP Gateway を標準 remote MCP endpoint とし、registration、relay key、public token、audit を中央に寄せます。
workflow / RPA tool に寄せる
向いていること
固定手順の業務自動化や既存 RPA 資産には向いている。
詰まりやすいこと
AI が動的に画面を読み、tool を選び、schema を変え、agent として実行する場合、統制点が workflow の外に漏れやすい。
viyv が補うこと
AI client と業務システムの間に置き、読む前・実行する前・終わった後の境界を管理します。
Comparison Labs
同じ業務で、代替案と viyv を比較する。
比較は機能表だけでは不十分です。実際の業務 1 つを選び、代替案でも viyv でも同じ入力・同じ件数・同じ証拠で評価します。
クラウド AI browser
KYC 10 件で cloud browser と比較する
比較 setup
同じ KYC 10 件を使い、顧客台帳、本人確認、制裁リストを読む。AI には照合メモだけを作らせ、最終判定は実行しない。
viyv で見る証拠
Browser の read-only、PII mask、許可ドメイン、最終判定 approval、policy denial を証拠として出す。
選定条件
DOM / screenshot の扱いと危険操作の停止を社内レビューで説明する必要があるなら viyv を選ぶ。
MCP connector 内製
read-only API 1 つで自作 MCP と比較する
比較 setup
社内 read-only API を 1 つ選び、Claude と GPT の両方から呼ぶ。write tool は入れず、運用と監査だけを見る。
viyv で見る証拠
namespace、tools/list、registration、token rotation、revoke 後の失敗、metadata-only audit を確認する。
選定条件
connector を今後も増やし、AI client を増やすたびにレビューをやり直したくないなら viyv を選ぶ。
既存 workflow / RPA
請求書例外で RPA / workflow tool と比較する
比較 setup
過去の請求書例外を使い、差異分類、修正理由、金額変更 approval、例外 table の更新を比較する。
viyv で見る証拠
purpose / reason、schema 変更履歴、rollback、会計画面 read-only、金額変更 approval を確認する。
選定条件
固定手順だけでなく、AI が例外分類や data model を変える業務を扱うなら viyv を選ぶ。
個人 prompt / workflow tool
CS agent で prompt 個人管理と比較する
比較 setup
問い合わせカテゴリ 30 件で、回答下書き、返金可否メモ、送信前 approval、再下書き品質を比較する。
viyv で見る証拠
agent definition、version、invocation event、Browser read-only、送信 approval、拒否理由の再利用を確認する。
選定条件
成功パターンを個人 prompt ではなく部門 agent として再利用したいなら viyv を選ぶ。
Decision Scenarios
比較検討で、どの結論を出すか。
viyv を使う理由は「機能が多い」ではありません。既存の選択肢では説明しにくい境界を、 検証で証拠として出せる時に選ぶべきです。
クラウド AI browser と迷っている
今の迷い
KYC、CS、経理 admin など、ログイン済み画面を AI に読ませたい。体験は早く試したいが、DOM と screenshot が外部実行環境に出る説明が難しい。
評価方法
同じ 10 件の業務で、クラウド実行と viyv Browser を比較し、mask、read-only、approval、policy denial の証拠を並べる。
viyv を選ぶ条件
顧客情報を扱う画面で、AI が読む範囲と危険操作の停止を社内レビューに出す必要がある場合。
MCP connector を自作するか迷っている
今の迷い
最初の MCP server は作れるが、部署ごとに token、namespace、監査、公開 endpoint が増え、AI client 追加のたびに運用が重くなる。
評価方法
read-only API を 1 つ選び、自作案と viyv MCP / Gateway で、tools/list、token rotation、metadata、複数 client 接続を比較する。
viyv を選ぶ条件
connector を継続的に増やし、Claude / GPT / 社内 agent へ同じ管理面で配りたい場合。
RPA / workflow tool と迷っている
今の迷い
固定手順は自動化できるが、AI が画面を読み、tool を選び、判断メモを作り、schema や agent 実行を変える流れを扱いにくい。
評価方法
請求書例外や CS 調査のように入力が変わる workflow で、AI の下書き、承認待ち、理由保存、再実行を比較する。
viyv を選ぶ条件
固定シナリオだけでなく、AI の動的判断と人間承認を同じ業務に入れたい場合。
Evaluation Scorecard
検証の評価を、合格・失格条件まで落とす。
評価会議では印象ではなく、境界・運用・効果・拡張性を同じ表で見ます。viyv を選ぶかどうかは、各項目で証拠が出せるかで判断します。
Data Boundary
比較するもの
DOM、screenshot、tool input、DB row のうち、AI に渡るものと渡らないもの。
合格条件
mask 前後、read-only、token scope を証拠として見せられる。
失格条件
「AI 側で気をつける」以外の制限がなく、顧客情報を渡す範囲を説明できない。
Action Boundary
比較するもの
送信、返金、登録、削除、決済、schema 変更、agent 実行をどこで止めるか。
合格条件
HITL approval、policy denial、拒否理由、再下書きログを 1 workflow で確認できる。
失格条件
AI が最後の click まで進める、または人間承認の証跡が残らない。
Connection Operations
比較するもの
MCP connector、token、namespace、public endpoint、AI client 追加の運用。
合格条件
registration、token rotation、revoke、複数 client 接続、tool metadata を確認できる。
失格条件
client ごとに tunnel と token が分かれ、connector owner と監査 owner が決まらない。
Business Outcome
比較するもの
対象 workflow の作業時間、下書き品質、再作業、承認待ち件数。
合格条件
Before / After を同じ件数で比較し、削減時間と増えたレビュー負荷を両方出せる。
失格条件
demo は動くが、現場指標や運用後の運用 owner に変換できない。
Expansion Path
比較するもの
最初の workflow から、次の connector、DB、agent、部門 rollout へ広げる条件。
合格条件
Team で始める条件、Enterprise が必要な条件、次の 90 日計画を分けられる。
失格条件
検証後に何を使うか、誰が運用するか、どの要件で Enterprise になるかが曖昧。
Evaluation Run Sheet
4 日で、判断に進むか戻すかを決める。
検証を長い探索にしません。最初の workflow を固定し、データ境界、危険操作の停止、社内判断までを短い評価会議で確認します。
Day 1
Workflow baseline を固定する
実施するテスト
KYC、請求書例外、CS 調査のいずれか 1 つを選び、代替案と viyv で同じ 10〜30 件を処理する。
残す証拠
現行の確認時間、下書き時間、再作業件数、承認待ち件数を Before として残す。
合格条件
現場 owner、security owner、policy owner が同じ成功条件に合意している。
判断材料
ここで owner が決まらない場合、判断ではなく追加設計に戻す。
Day 2
Data boundary を証拠化する
実施するテスト
DOM、screenshot、tool input、DB row のうち、AI に渡るものと渡らないものを同じ画面で確認する。
残す証拠
mask 前後、read-only 制限、token scope、metadata-only audit を評価資料に貼れる形で残す。
合格条件
顧客情報・社内情報の扱いをセキュリティレビューで説明できる。
判断材料
データ境界の説明が通るなら、検証は効果測定へ進める。
Day 3
Action stop を実際に起こす
実施するテスト
送信、返金、登録、削除、schema 変更、agent publish のうち 1〜2 個を意図的に止める。
残す証拠
HITL approval、policy denial、拒否理由、再下書き、再実行の event を残す。
合格条件
AI が危険操作の直前で止まり、人間が判断してから進められる。
判断材料
危険操作が止まる証拠が出たら、業務部門の利用条件を詰められる。
Day 4
Decision verdict を書く
実施するテスト
Team 開始、Enterprise 条件整理、追加検証、今回は別案の 4 つから 1 つを選ぶ。
残す証拠
選ばなかった案の理由、必要な運用 owner、次の 90 日 rollout、運用条件に入れる条件を残す。
合格条件
社内説明資料に転記できる比較結果と証拠が揃っている。
判断材料
Team で始める条件と Enterprise に上げる条件を分けて判断材料へ進む。
Evaluation Battlecards
比較会議で、viyv を選ぶ条件と選ばない条件を分ける。
viyv を売り込むためではなく、既存案で十分なケースと、viyv が必要なケースを明確にします。比較対象ごとに同じ検証データで判断します。
Browser 自動化を自作する案
会議で出る問い
Playwright / RPA / 社内 script で十分ではないか。
比較方法
KYC または CS admin 10 件で、DOM / screenshot mask、read-only、危険 click の停止、承認ログを同じ条件で比較する。
viyv を選ぶ条件
自作案が画面操作はできても、mask、approval、policy denial、audit を製品運用として説明できない場合。
別案でよい条件
対象が個人 demo または内部 toy workflow で、顧客情報・監査・人間承認が不要な場合。
MCP connector を内製する案
会議で出る問い
1 つ目の MCP server は社内で作れるのではないか。
比較方法
read-only API 1 つで、namespace、tools/list、token rotation、複数 AI client 接続、tool metadata を比較する。
viyv を選ぶ条件
connector を部署ごとに増やし、Claude / GPT / 社内 agent に同じ governance で配りたい場合。
別案でよい条件
単一 client、単一 tool、短期実験で、registration や token owner を中央管理する必要がない場合。
クラウド AI browser を採用する案
会議で出る問い
クラウド実行のほうが利用が速いのではないか。
比較方法
顧客情報を含むログイン済み画面で、外部実行環境に出る DOM / screenshot、mask の証拠、操作停止点を比較する。
viyv を選ぶ条件
金融、人事、顧客 admin など、AI が読む範囲と実行環境を社内レビューで説明する必要がある場合。
別案でよい条件
扱う画面が公開情報中心で、ログイン済み業務画面や顧客情報を読ませない場合。
既存 workflow / RPA tool に寄せる案
会議で出る問い
既存の自動化基盤に AI step を足せばよいのではないか。
比較方法
請求書例外または調査 workflow で、AI の動的判断、schema 変更理由、agent run history、人間承認を比較する。
viyv を選ぶ条件
固定手順ではなく、AI が tool を選び、table を変え、agent として再実行する業務を運用したい場合。
別案でよい条件
手順が固定され、AI の判断・schema 変更・agent 実行を業務システム側で扱わない場合。
Fit / Not Fit
合う状態、合わない状態。
利用前に、viyv が解くべき問題かを切り分けます。単なる demo ではなく、統制・監査・運用が 問題になっている時に価値が出ます。
viyv が合う
- AI に業務画面を触らせたいが、送信・決済・削除・承認は人間に戻したい
- 社内 MCP を Claude / GPT / 社内 agent へ同じ管理面で配りたい
- AI に渡るデータ範囲、token scope、audit metadata をセキュリティレビューで説明したい
- AI が作る DB schema や agent 実行履歴を、検証後も製品として管理したい
まだ合わない可能性が高い
- 単発の個人 demo だけで、policy や監査が不要
- 固定 RPA の置き換えだけが目的で、AI client や MCP 接続を使わない
- すべての業務データをクラウド AI 実行環境に渡しても社内承認上問題ない
- 検証の成功条件が未定で、どの操作を止めたいか決められない
Checklist
評価で見るべき 5 つの質問。
Data
AI に渡る DOM、screenshot、tool input、DB row はどこで制限するか。
Action
送信、削除、決済、schema 変更、agent 実行をどこで人間に戻すか。
Connection
社内 tool を inbound なしで、複数 AI client にどう配るか。
Audit
本文を持たずに、誰が何をいつ呼んだかをどう説明するか。
Operation
policy、token、registration、agent version を誰が管理するか。
Decision Verdicts
評価会議の最後に、提案を分ける。
viyv が合うかどうかだけでは足りません。Team で開始するか、Enterprise 条件を詰めるか、追加検証に戻すか、今回は別案にするかを明文化します。
Team で開始
判断する状態
1 workflow、3〜10 名、標準条件で始められ、SSO / SIEM / VPC なしでも運用 owner と承認者を決められる。
必要な証拠
Before / After 指標、mask、approval decision、対象 workflow、利用者、次に広げる業務が揃っている。
注意点
利用部門が 1 つでも、セキュリティ owner と policy owner が未定なら利用前に Hold する。
Enterprise 条件を詰める
判断する状態
複数部門、SSO / SCIM / SIEM、DPA、VPC / on-prem、OAuth connector、監査連携が管理部門条件になる。
必要な証拠
registration、token rotation、metadata audit、data boundary、90 日 rollout、運用責任分担が揃っている。
注意点
Enterprise 要件を全部検証前に固定しようとすると遅い。最初の workflow 証拠から条件を分ける。
追加検証
判断する状態
効果は見えたが、止めたい操作、mask 対象、token owner、agent publish 承認者のいずれかが未確定。
必要な証拠
不足している証拠の一覧、追加で見る workflow、合格条件、次回会議の owner。
注意点
曖昧なまま判断に進むと、運用後に security review や現場運用で止まる。
今回は別案
判断する状態
個人 demo、公開情報の収集、固定 RPA、単一 client / 単一 connector で、統制・監査・承認が運用条件にならない。
必要な証拠
viyv が解く境界が現時点では管理部門条件ではない、という比較メモ。
注意点
将来、顧客情報、ログイン済み画面、複数 AI client、agent 運用が出た時に再評価する。
Evaluation Output
評価会議の最後に残すもの。
「よさそう」では社内説明に進めません。比較した選択肢、採用条件、検証 で確認した証拠を、判断資料に変えます。
比較した選択肢と、選ばなかった理由
対象 workflow のBefore / After 指標
AI に渡したデータ範囲と mask 証跡
人間承認で止まった操作と拒否理由
token / namespace / metadata / rollback の確認結果
Team / Enterprise 運用へ進む条件
Proof Before Adoption
評価結果を、判断材料に変える。
viyv が合うと判断した後は、検証で見るべき証拠を固定します。ここが曖昧なままだと、 demo は成功しても社内説明で止まります。
業務効果を測れるか
単なる成功例ではなく、対象 workflow の確認時間、下書き時間、再作業、承認待ち件数を比較できるか。
止めたい操作が実際に止まるか
送信、削除、決済、登録、schema 変更、agent 実行が policy / HITL で停止し、拒否理由を残せるか。
データ境界を見せられるか
DOM、screenshot、tool input、DB row のうち、AI に渡らない情報と token scope を説明できるか。