Start
担当者が 1 件を選ぶ
新規ベンダー登録、支払先変更、調達申請、契約更新前チェック。 から 1 件を選び、対象画面、社内 tool、AI に渡せる情報、人間に戻す判断を固定します。
Vendor Operations
取引先登録 / 調達申請 を viyv で動かす。
新規取引先登録は、会社情報、反社チェック、与信、契約書、振込先を複数画面で確認する。AI に下調べを任せたいが、登録、支払先変更、承認操作は誤ると影響が大きい。
Problem
この業務で、何が詰まっているか。
新規取引先登録は、会社情報、反社チェック、与信、契約書、振込先を複数画面で確認する。AI に下調べを任せたいが、登録、支払先変更、承認操作は誤ると影響が大きい。
始めるきっかけ
新規ベンダー登録、支払先変更、調達申請、契約更新前チェック。
最初の 30 日
新規登録ではなく、既存申請の再現から始めます。AI の下書き精度、支払先変更の停止、社内 API 接続の audit を確認してから本番申請に近づけます。
Day In The Life
現場の 1 件が、判断材料までどう流れるか。
業務詳細では、担当者が何を持ち込み、AI がどこまで進め、人間がどこで止め、 最後に何を証拠として残すかを時系列で確認します。
Assist
AI が下調べと下書きを行う
AI が会社情報、契約書、過去取引、公開情報を読み取る。Browser が取引先管理画面を read-only で参照し、登録内容を下書きする。MCP が社内チェック API や申請情報を権限付き tool として渡す
Gate
責任が残る操作を止める
新規取引先登録 / 支払先 / 振込先変更 / 調達申請の最終承認 は approval、差戻し、保留、または人間確認に戻します。
Review
判断材料に使う証拠を残す
登録準備時間 / 支払先変更の停止 / tool call metadata / 承認者と拒否理由 を検証の evidence として並べ、次の展開可否を決めます。
Operational Evidence Board
取引先登録 / 調達申請 の現場実行を、レビュー用の証拠にする。
担当者が見たもの、AI が出した下書き、人間が止めた判断、レビュー会議に出す証拠を 1 つの board にします。これにより「便利そう」ではなく、運用に入れてよいかを判断できます。
Application
新規ベンダー申請の下調べをまとめる
担当者が見るもの
管理部門担当が申請番号、会社名、契約書 URL、支払先変更の有無を指定する。
AI の出力
AI は公開情報、運用条件、社内チェック API を照合し、不足情報と登録下書きを作る。
人間が止める判断
新規登録、支払先変更、調達申請の最終承認は human gate に戻す。
レビューに出す証拠
登録準備時間、不足情報の検出、tool call metadata、承認者を並べる。
Payment Risk
支払先変更を必ず二者承認にする
担当者が見るもの
経理担当が支払先差分を確認し、変更理由と証憑が揃っているかを見る。
AI の出力
AI は支払先差分、運用条件との差分、反社チェック結果を要確認リストにする。
人間が止める判断
支払先変更は approval なしに進めず、二者承認または差戻しにする。
レビューに出す証拠
支払先変更 approval、拒否理由、namespace 外 API の denial を監査証跡にする。
Stakeholder Review
管理部門・経理・内部統制で同じ packet を見る
担当者が見るもの
管理部門責任者が 5 件分の再現結果を見て、本番申請に近づけるか判断する。
AI の出力
AI は申請ごとの不足情報、登録下書き、支払先 risk、承認待ち状態を一覧化する。
人間が止める判断
owner、承認者、支払先変更ルールが揃わない場合は追加検証に戻す。
レビューに出す証拠
申請準備時間、支払先変更停止、MCP metadata、承認ログをレビューに出す。
Before / After / Recovery
利用前後と、失敗時の戻し方を同じ画面で見る。
利用前の不安は、効果よりも「失敗した時に止められるか」で出ます。利用前、運用後、 失敗時、レビュー会議で見る材料を並べます。
利用前
新規取引先登録は、会社情報、反社チェック、与信、契約書、振込先を複数画面で確認する。AI に下調べを任せたいが、登録、支払先変更、承認操作は誤ると影響が大きい。
運用後
AI が会社情報、契約書、過去取引、公開情報を読み取る。Browser が取引先管理画面を read-only で参照し、登録内容を下書きする。MCP が社内チェック API や申請情報を権限付き tool として渡す。登録、支払先変更、承認ボタンは全件 HITL approval に戻す。
失敗時
会社情報の一致率が低い場合は登録下書きを作らず不足情報にする / 支払先変更を検出したら必ず二者承認にする / namespace 外の社内 API 呼び出しは拒否して metadata に残す
レビュー会議
現場指標: 登録準備時間、不足情報の検出率、再申請数 / 統制指標: 支払先変更 approval、namespace 拒否、tool metadata / 導入判断: 下調べを短縮し、登録と支払先変更を安全に止められるか
Scenario Walkthrough
現場の 1 件を、運用後の流れまで具体化する。
利用検討で必要なのは、抽象的な自動化ではなく「この 1 件がどう変わるか」です。現在の作業、viyv 後の処理、解決する問題、レビュー会議で見る判断材料を分けます。
Case
新規ベンダー登録前に、会社情報・反社チェック・支払先を確認する
管理部門担当は申請書、会社情報、契約書、社内チェック API、支払先情報を別々に確認する。AI に下調べを任せたいが、登録や振込先変更を誤ると内部統制上の事故になる。
With viyv
AI に任せる作業と、人間に戻す判断を分ける
AI が公開情報、運用条件、社内チェックを照合し、不足情報と登録下書きを作る。支払先変更、登録、最終承認は approval で止まり、MCP tool call metadata が残る。
Problem Solved
この workflow で解決できる問題
下調べと不足情報検出を速くしつつ、支払先変更や登録操作は人間の承認に戻せる。管理部門、経理、内部統制が同じ証拠を見られる。
Decision Moment
レビュー会議で見る判断材料
既存申請 5 件で登録準備時間、不足情報検出、支払先変更 approval、namespace 拒否ログを確認し、本番申請へ近づけるか判断する。
Concrete Run
1 件の業務を、こう流す。
demo ではなく、現場が毎日扱う 1 件を起点にします。入力、AI の作業、人間に戻す判断、 残す成果物を分けると、検証の範囲が曖昧になりません。
Input
現場が持ち込むもの
新規ベンダー登録、支払先変更、調達申請、契約更新前チェック。 を対象に、担当者、対象画面、社内 tool、AI に渡してよい情報を 1 つの範囲に固定します。
AI Work
AI に任せる作業
AI が会社情報、契約書、過去取引、公開情報を読み取る。Browser が取引先管理画面を read-only で参照し、登録内容を下書きする。MCP が社内チェック API や申請情報を権限付き tool として渡す
Human Gate
人間が止める判断
新規取引先登録 / 支払先 / 振込先変更 / 調達申請の最終承認
Output
残す成果物
取引先登録下書き / チェック結果 / 不足情報リスト / 承認ログ
Operator Runbook
担当者が触る場所と、止める場所を分ける。
現場の操作を増やさず、AI の下書きと確認メモを使います。責任が残る操作は approval に戻し、失敗時の扱いも検証条件に入れます。
担当者の操作
- 申請番号、会社名、契約書 URL を AI に渡す
- AI が公開情報、社内チェック、契約条件を照合する
- 不足情報と登録下書きを管理部門の担当者が確認する
人間に戻す判断
- 新規取引先登録
- 支払先 / 振込先変更
- 調達申請の最終承認
失敗時の止め方
- 会社情報の一致率が低い場合は登録下書きを作らず不足情報にする
- 支払先変更を検出したら必ず二者承認にする
- namespace 外の社内 API 呼び出しは拒否して metadata に残す
検証合格条件
- 既存申請 5 件で登録準備時間を比較できる
- 支払先変更が approval なしに進まない
- 社内チェック API の tool call metadata を確認できる
Evidence Packet
検証の証拠を、判断材料に変える。
利用前に「AI が便利だった」ではなく、業務効果、統制、責任境界、展開条件を並べます。
業務範囲
取引先登録 / 調達申請 を 1 workflow として、owner は 管理部門、経理、総務、内部統制 に置きます。
測る効果
現場指標: 登録準備時間、不足情報の検出率、再申請数
見る統制
統制指標: 支払先変更 approval、namespace 拒否、tool metadata
判断材料
導入判断: 下調べを短縮し、登録と支払先変更を安全に止められるか
Stakeholder Review
社内の誰に、何を説明できるか。
業務部門、情シス、セキュリティ、管理部門が見る論点を分け、検証 の受け入れ条件に変えます。
業務責任者
現場のどの作業が短くなり、どの判断は人間に残るか。
回答
申請番号、会社名、契約書 URL を AI に渡す / AI が公開情報、社内チェック、契約条件を照合する / 不足情報と登録下書きを管理部門の担当者が確認する を日次運用に置き、新規取引先登録 / 支払先 / 振込先変更 / 調達申請の最終承認 は承認待ちに戻します。
見る証拠
登録準備時間 / 支払先変更の停止
情シス / AI platform
既存画面、社内 API、AI client の境界を説明できるか。
回答
viyv Browser / viyv MCP / Viyv MCP Gateway を使い、vendor admin read-only / 支払先 mask / 登録 HITL を最初の境界にします。
見る証拠
支払先変更の停止 / tool call metadata / 承認者と拒否理由
セキュリティ / 法務
AI に渡らない情報、止まる操作、失敗時の扱いは明確か。
回答
vendor admin read-only / 支払先 mask / 登録 HITL / MCP namespace を検証の統制として固定し、失敗時は 会社情報の一致率が低い場合は登録下書きを作らず不足情報にする。
見る証拠
支払先変更が approval なしに進まない / 社内チェック API の tool call metadata を確認できる
管理部門 / 経営
判断に進む条件と、広げる前の保留条件は何か。
回答
導入判断: 下調べを短縮し、登録と支払先変更を安全に止められるか
見る証拠
既存申請 5 件で登録準備時間を比較できる / 支払先変更が approval なしに進まない / 社内チェック API の tool call metadata を確認できる
Next Step
取引先登録 / 調達申請 の検証範囲を決める。
対象画面、社内 tool、人間に戻す判断、判断材料を 30 日の検証計画に落とします。