Products
viyv は単体ツールの寄せ集めではありません。ブラウザ操作、社内 tool 接続、 データ構造化、agent 実行の各地点に、企業が必要とする統制と監査を置きます。
Product Selection Room
viyv の製品選定は、機能比較から始めません。業務画面、社内 tool、AI が作るデータ、部門 agent のどこで詰まっているかを先に決め、検証 で出す証拠と次に足す製品を分けます。
業務責任者 / 現場 lead
viyv Browser から始め、必要になったら MCP Gateway を足す。
担当者が SaaS、admin、金融画面を見て確認しているが、顧客情報と送信・登録・返金の責任境界で止まる。
許可 URL、read-only 画面、mask 対象、HITL 条件を決め、AI には読み取り・要約・下書きまで任せる。
処理時間、mask 前後、拒否された操作、承認待ちに戻った操作、下書き修正率。
3〜10 名の Team で始め、高リスク操作や複数部門展開が出たら Enterprise 条件を詰める。
情シス / AI platform
viyv MCP + Gateway から始め、必要になったら viyv DB を足す。
MCP server、token、OAuth、endpoint、監査が案件ごとに増え、Claude / GPT / 社内 agent への配布が標準化できない。
read-only API を 1 つ MCP 化し、Gateway で複数 AI client から同じ connector を呼べるようにする。
tools/list、namespace、token rotation、revoke 後の拒否、client 別 metadata audit。
platform 標準として採用し、write tool、SSO / SIEM、connector governance は Enterprise 条件に分ける。
Finance / Ops / Data owner
viyv DB から始め、必要になったら Agent Foundry を足す。
請求書例外、調査メモ、顧客分類の判断理由がチャットや個人メモに散り、後から検索・説明・再利用できない。
purpose、record、schema change reason、検索で再利用したい項目を決め、1 workflow で保存と rollback を実演する。
semantic search、alter reason、rollback、後続 agent が再利用した record、data owner。
データ責任者が説明できる状態なら Team で開始し、継続実行する agent が必要になったら Foundry を足す。
AI アプリ責任者 / 部門 owner
Agent Foundry から始め、必要になったら Browser + Gateway を足す。
validation agent は作れるが、version、実行履歴、approval、差戻し、利用部門ごとの設定が運用責任に乗らない。
agent definition、参照 tool、承認条件、失敗時の差戻し、version 更新ルールを決める。
run event、待機中 approval、差戻し理由、version 更新理由、再実行結果、運用 owner。
部門 agent として本番化し、画面操作が必要なら Browser、社内 connector が増えたら Gateway を足す。
Local browser automation
クラウド型 AI ブラウザは DOM、スクリーンショット、操作履歴が外部に流れやすく、金融・人事・顧客情報を扱う部門では IT 承認を取りにくい。viyv Browser は、AI が業務画面を触る地点に policy、承認、マスキングを挟みます。
Secure MCP framework
各チームが MCP サーバを個別に作ると、schema 生成、transport、JWT、監査、外部 MCP bridge の実装が散らばります。viyv MCP は MCP サーバの作り方とセキュリティ面を標準化します。
Multi-vendor MCP hub
ベンダー純正 tunnel を別々に運用すると、同じ社内 MCP を Claude 用、OpenAI 用に重複設定することになります。Gateway はベンダー非依存の rendezvous として、MCP 接続、public token、OAuth、監査を統一します。
AI-native database MCP
従来は人間が schema を決め、migration を書いてから AI が query します。しかし調査や業務自動化では、AI が問題理解に合わせてデータモデルを変えられることが重要です。viyv DB はその変更理由を DB 自身に残します。
Managed agent runtime
業務チームが agent を使い始めると、prompt、tool、runtime、version、実行履歴、承認待ち、監査が散らばります。Foundry は agent の定義から実行までを管理し、workflow orchestration とは独立した foundation layer を提供します。
First Adoption Scenario
利用前の比較では、機能表よりも「最初にどの業務で使うか」が重要です。各製品は 1 つの業務境界から始め、検証で見せる evidence と次に足す製品を分けます。
KYC、CS、経理など、担当者が SaaS / admin を開いて確認している業務。
AI は画面を読めるが、送信・登録・決済は人間の approval に戻す。PII は mask し、許可ドメイン以外は触らせない。
1 つのログイン済み画面、許可 URL、read-only policy、HITL 条件を決める。
AI の読み取り結果、mask された項目、拒否された操作、承認待ちに戻った操作ログ。
画面の裏にある社内 API を使う必要が出たら MCP Gateway を足す。
HR、Finance、Ops の read-only API を AI client から使いたい業務。
社内 API を MCP tool として定義し、schema、JWT、namespace、deny log を案件ごとに作り直さない。
read-only tool を 1 つ選び、input schema、権限 scope、監査 metadata を固定する。
tools/list、許可された呼び出し、拒否された呼び出し、schema の再利用性。
複数 AI client や複数部門に配る段階で MCP Gateway を足す。
Claude、GPT、社内 agent に同じ MCP connector を安全に配る platform 業務。
connector を inbound 公開せず、client ごとに token、namespace、revoke、audit を分ける。
既存 MCP server、許可 client、token rotation、revoke 条件、監査粒度を決める。
複数 client からの接続、token rotation、revoke 後の拒否、client 別 audit log。
connector がデータを生成し始めたら viyv DB、実行履歴が必要なら Foundry を足す。
請求書例外、調査メモ、顧客分類など、AI の判断理由を残したい業務。
チャットに散った判断理由を purpose 付き schema と record にし、検索、変更理由、rollback を残す。
保存する record、purpose、schema change reason、検索で再利用したい項目を決める。
semantic search、alter reason、rollback、後続 agent が再利用できる record。
継続的に同じ判断を回すなら Agent Foundry を足す。
CS 調査、リサーチ、バックオフィスなど、部門 agent を運用したい業務。
validation agent を definition、version、run history、approval、差戻しまで含む運用単位にする。
agent の入力、参照 tool、承認条件、失敗時の差戻し、version 更新ルールを決める。
run event、待機中の approval、差戻し理由、version 更新理由、再実行結果。
画面操作は Browser、社内 connector 公開は Gateway、記憶は DB を足す。
Alternative Gaps
viyv は「自作より高機能」だけを言いたい製品ではありません。AI が業務システムへ届く時に、 データ境界、危険操作、接続運用、監査証拠を同時に説明できるかで見ます。
最初の画面操作や demo は早い。対象画面が少なく、個人の検証なら十分に進められる。
mask、HITL、read-only、監査 metadata、失敗時の rollback が後付けになり、業務部門とセキュリティへ同じ証拠を出しにくい。
Browser、DB、Foundry まで含めて、読む前・実行前・実行後の境界を検証の最初から残します。
単一の AI client だけで使うなら設定がまとまりやすく、初期利用の体験は軽い。
Claude、GPT、社内 agent ごとに token、namespace、OAuth、監査が分かれ、connector が増えるほど platform 標準から外れます。
MCP / Gateway で connector registration、token rotation、revoke、metadata audit を中央に寄せます。
固定手順、決まった画面、例外の少ない作業には向いている。既存 RPA 資産も活かしやすい。
AI が動的に画面を読み、tool を選び、判断理由を DB に残し、agent として再実行する流れは workflow の外へ漏れやすい。
AI client と業務システムの間に置き、画面・tool・データ・agent 実行を同じ判断材料にします。
Problem First
利用前に必要なのは、全部の機能を理解することではありません。AI が最初に触る画面・tool・データ・agent 実行を特定し、そこで発生するリスクを止められるかを確認します。
SaaS、admin、金融画面などが API 化されておらず、担当者が画面を開いて確認している。AI に読ませたいが、顧客情報と最終操作の責任境界が曖昧。
viyv Browser
許可ドメイン、read-only、mask、HITL approval を設定し、送信・承認・決済が人間に戻ることを見せる。
部署ごとに MCP server を作り始め、schema、JWT、token、公開 endpoint、監査 metadata がばらついている。
viyv MCP / Viyv MCP Gateway
read-only tool を 1 つ MCP 化し、Claude / GPT / 社内 agent から同じ endpoint を呼び、namespace と token rotation を確認する。
調査メモ、例外分類、判断理由がチャットに散り、後続の agent や担当者が再利用できない。schema 変更の理由も残らない。
viyv DB
purpose 付き table、alter reason、semantic search、rollback を 1 workflow で実演し、後から説明できる状態にする。
validation agent は作れるが、version、run history、失敗時の差戻、承認待ち、利用部門ごとの設定が運用に乗らない。
viyv Agent Foundry
agent definition、run event、approval、再下書き、version 更新を 1 つの CS / 調査 workflow で確認する。
Compare
viyv は suite ですが、最初から全部を使う必要はありません。いま止まっている業務と、 判断材料で見たい証拠に合わせて 1 製品から始めます。
Local browser automation
クラウド型 AI ブラウザが顧客情報・社内画面を理由に止まっている
ロボアド、銀行、証券向けの lockdown policy を起点に、許可 URL、read-only 画面、承認必須画面を整理します。
Secure MCP framework
MCP server がチームごとに増え、認可・監査・schema 品質が揃っていない
まず read-only tool を @tool で定義し、schema と audit を確認してから書き込み系 tool を増やします。
Multi-vendor MCP hub
Claude / GPT / 将来の AI client へ同じ社内 MCP を接続したい
社内 DB、SaaS、ファイル検索、個人 connector を registration 単位に分け、team 共有か personal かを決めます。
AI-native database MCP
AI にメモリや業務データを持たせたいが、人間 migration がボトルネック
最初は read / data で運用し、schema 権限は trusted agent や開発環境に限定すると導入しやすくなります。
Managed agent runtime
prompt と tool 設定が個人管理で、agent として再利用できない
Anthropic key がなくても、stub-backed API で agent catalog、deployment、invocation、event stream の体験を検証できます。
Selection Questions
製品一覧を眺めるだけでは、最初の判断は進みません。以下の質問に答えると、 最初に検証すべき製品と、次に足す製品が決まります。
既存画面なら Browser、社内 API なら MCP / Gateway、AI が作る記憶なら DB、部門 agent なら Foundry から始めます。
送信・決済・承認なら Browser の HITL、tool 実行なら Gateway の namespace / token、schema 変更なら DB の reason / rollback、agent 実行なら Foundry の version / event で止めます。
業務責任者には削減時間、情シスには接続境界、セキュリティには mask / audit、管理部門には Team / Enterprise へ進む条件を見せます。
Selection Failure Modes
viyv は suite ですが、始め方を間違えると検証 が抽象的になります。選定時点で失敗パターンを分け、誰に何を見せるかを明確にします。
関係者が増えすぎて、誰がどの証拠を見て判断するのかが曖昧になる。
最初の 1 workflow を決め、Browser / MCP / Gateway / DB / Foundry のどれが最初の詰まりを解くかに絞る。
MCP、browser automation、agent などの実装方式の話になり、業務責任者が価値を判断できない。
削減したい作業、止めたいリスク、承認が必要な操作を先に書き、そこから製品を選ぶ。
デモは動いたが、security、情シス、管理部門に渡す evidence が同じ資料に混ざってレビューが止まる。
mask / deny log / token rotation / rollback / run history のように、製品ごとの evidence を分ける。
1 製品の検証は成功しても、運用後にどう広げるかが見えず、部門限定の実験で止まる。
画面、tool、データ、agent のどの境界を次に足すかを、検証終了時の運用条件に入れる。
Decision Packet
すべての製品で同じ資料を作る必要はありません。最初の検証 では、製品ごとに「動く証拠」「次に足す境界」「判断に進む条件」を分けて見せます。
ログイン済み画面を読み、送信・登録・決済を承認待ちに戻せるか。
画面操作で扱う社内 API が増えたら MCP Gateway を足す。
mask / read-only / HITL の audit をセキュリティに渡し、業務部門には削減時間と拒否理由の内訳を見せる。
業務 API を 1 つ MCP tool にして、schema、JWT、namespace を再利用できるか。
複数部門や複数 AI client へ配る段階で MCP Gateway を足す。
connector の実装標準、権限境界、deny log を platform チームの標準化資料として使う。
社内 connector を inbound 公開せず、Claude / GPT / 社内 agent から使えるか。
connector が業務データを作り始めたら viyv DB、実行履歴が必要なら Foundry を足す。
token rotation、namespace、client ごとの監査ログを、情シスとセキュリティのレビュー evidence にする。
AI が作る調査メモや判断理由を、purpose 付き schema と検索可能な record として残せるか。
その data を継続実行する部門 agent が必要になったら Agent Foundry を足す。
schema change reason、rollback、semantic search の再現性を、データ責任者と業務責任者へ見せる。
部門 agent の definition、run history、approval、version 更新を運用単位で回せるか。
画面操作が必要なら Browser、社内 tool 接続が増えたら Gateway を足す。
失敗時の差戻、承認待ち、version 更新理由を、運用責任者と監査担当の判断材料にする。
Adoption Route
既存 SaaS や admin 画面の手作業を AI に任せたい場合は Browser から始めます。送信・承認・ masking を検証 で見せると、セキュリティレビューに進めやすくなります。
社内 API や DB を AI client へ安全に出したい場合は MCP または MCP Gateway から始めます。接続、認可、監査の標準化が判断材料の中心になります。
AI が扱う記憶、データ、agent 実行を製品として育てたい場合は DB と Agent Foundry から始めます。履歴、version、rollback、実行イベントを検証します。
Suite Adoption Scenarios
viyv は 1 製品から始められますが、運用後は workflow に合わせて境界を足していきます。部門ごとに、どの順番で組み合わせると判断しやすいかを整理します。
Suite Patterns
運用後の拡張が見えない製品は、検証で止まりやすい。viyv は最初の課題から、 次に足すべき接続・データ・agent 実行までを同じ suite で伸ばします。
API 化されていない画面操作から始め、徐々に社内 MCP connector を増やす。業務部門の即効性と platform の標準化をつなぎます。
Python で業務 API を MCP 化し、Gateway で Claude / GPT / 社内 agent へ配る。connector 開発と公開運用を分離します。
AI が作る記憶や調査データを DB に残し、Foundry の agent 実行履歴と合わせて、 知識と実行を継続的に改善します。
部門 agent が実ブラウザで下書き・確認を行い、最終操作は Browser の承認に戻す。agent 実験を業務運用へ近づけます。