Start
担当者が 1 件を選ぶ
新しい社内 API connector、部署別 AI agent、Claude / GPT への tool 追加申請。 から 1 件を選び、対象画面、社内 tool、AI に渡せる情報、人間に戻す判断を固定します。
AI Platform
社内 MCP connector 申請 を viyv で動かす。
社内 API を AI に渡したい相談が増えるが、MCP server、token、OAuth、公開 URL、監査が案件ごとにばらつく。セキュリティレビューも毎回やり直しになる。
Problem
この業務で、何が詰まっているか。
社内 API を AI に渡したい相談が増えるが、MCP server、token、OAuth、公開 URL、監査が案件ごとにばらつく。セキュリティレビューも毎回やり直しになる。
始めるきっかけ
新しい社内 API connector、部署別 AI agent、Claude / GPT への tool 追加申請。
最初の 30 日
部署横断で使う read-only API を 1 つ選び、Claude と GPT の両方から同じ endpoint を呼びます。write tool は後回しにし、認可と audit を先に通します。
Day In The Life
現場の 1 件が、判断材料までどう流れるか。
業務詳細では、担当者が何を持ち込み、AI がどこまで進め、人間がどこで止め、 最後に何を証拠として残すかを時系列で確認します。
Assist
AI が下調べと下書きを行う
viyv MCP で read-only tool から connector を作る。namespace、clearance、JWT を定義し、tools/list と tools/call を制御する。MCP Gateway に outbound 接続し、標準 remote MCP endpoint を発行する
Gate
責任が残る操作を止める
write tool 追加 / public token 発行 / registration 有効化 / 無効化 は approval、差戻し、保留、または人間確認に戻します。
Review
判断材料に使う証拠を残す
1 MCP の複数 client 接続 / token 失効 / tool call metadata / connector 状態 を検証の evidence として並べ、次の展開可否を決めます。
Operational Evidence Board
社内 MCP connector 申請 の現場実行を、レビュー用の証拠にする。
担当者が見たもの、AI が出した下書き、人間が止めた判断、レビュー会議に出す証拠を 1 つの board にします。これにより「便利そう」ではなく、運用に入れてよいかを判断できます。
Request
read-only API から connector を始める
担当者が見るもの
AI platform が対象 API、利用部門、namespace、token owner、接続したい AI client を指定する。
AI の出力
viyv MCP が tool schema を作り、Gateway が endpoint、registration、metadata audit を管理する。
人間が止める判断
write tool 追加、public token 発行、registration 有効化は approval にする。
レビューに出す証拠
tools/list、namespace、token owner、connector status、metadata-only audit を残す。
Client
Claude と GPT から同じ endpoint を呼ぶ
担当者が見るもの
platform 担当が 2 種類以上の AI client に同じ Gateway endpoint を設定する。
AI の出力
Gateway は client 別の call、scope、token rotation、失敗 metadata を記録する。
人間が止める判断
scope mismatch、想定外 namespace、切断 connector は tools/list から隠す。
レビューに出す証拠
複数 client 接続、token revoke、registration audit、失敗 metadata を示す。
Standardize
案件ごとの tunnel を標準 endpoint に変える
担当者が見るもの
情シスが connector 申請を Gateway 登録、審査、失効、監査の標準手順にする。
AI の出力
MCP / Gateway が connector registry、tool schema、audit metadata を 1 つにまとめる。
人間が止める判断
本番公開前に owner、scope、失効手順、監査提出先が揃っているかを見る。
レビューに出す証拠
connector 追加時間、client 追加時の設定差分、token rotation を Enterprise 判断に使う。
Before / After / Recovery
利用前後と、失敗時の戻し方を同じ画面で見る。
利用前の不安は、効果よりも「失敗した時に止められるか」で出ます。利用前、運用後、 失敗時、レビュー会議で見る材料を並べます。
利用前
社内 API を AI に渡したい相談が増えるが、MCP server、token、OAuth、公開 URL、監査が案件ごとにばらつく。セキュリティレビューも毎回やり直しになる。
運用後
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 を中央で管理する。
失敗時
想定外 namespace の tool は tools/list に出さない / connector が切断したら endpoint 側で失敗 metadata を返す / token 漏洩時は registration 単位で rotation / revoke する
レビュー会議
現場指標: connector 追加時間、client 追加時の設定差分 / 統制指標: namespace、token rotation、registration audit / 導入判断: 社内 MCP を vendor 別 tunnel ではなく標準 endpoint で配れるか
Scenario Walkthrough
現場の 1 件を、運用後の流れまで具体化する。
利用検討で必要なのは、抽象的な自動化ではなく「この 1 件がどう変わるか」です。現在の作業、viyv 後の処理、解決する問題、レビュー会議で見る判断材料を分けます。
Case
社内 read-only API を、Claude と GPT の両方から安全に呼ぶ
AI platform チームには connector 申請が増えるが、MCP server、token、OAuth、公開 URL、監査が案件ごとに違う。レビューを毎回やり直すため、展開速度が落ちる。
With viyv
AI に任せる作業と、人間に戻す判断を分ける
viyv MCP で read-only tool を定義し、namespace と clearance を付ける。Gateway が endpoint、public token、OAuth、registration、metadata audit を中央管理する。
Problem Solved
この workflow で解決できる問題
vendor 別 tunnel を増やさず、同じ MCP を複数 AI client に配れる。write tool 追加や token 発行は人間 gate にでき、platform 標準として説明しやすい。
Decision Moment
レビュー会議で見る判断材料
1 つの MCP を 2 client から呼び、token revoke、tools/list の可視性、metadata-only audit を確認して Enterprise 条件を決める。
Concrete Run
1 件の業務を、こう流す。
demo ではなく、現場が毎日扱う 1 件を起点にします。入力、AI の作業、人間に戻す判断、 残す成果物を分けると、検証の範囲が曖昧になりません。
Input
現場が持ち込むもの
新しい社内 API connector、部署別 AI agent、Claude / GPT への tool 追加申請。 を対象に、担当者、対象画面、社内 tool、AI に渡してよい情報を 1 つの範囲に固定します。
AI Work
AI に任せる作業
viyv MCP で read-only tool から connector を作る。namespace、clearance、JWT を定義し、tools/list と tools/call を制御する。MCP Gateway に outbound 接続し、標準 remote MCP endpoint を発行する
Human Gate
人間が止める判断
write tool 追加 / public token 発行 / registration 有効化 / 無効化
Output
残す成果物
connector 登録 / tool schema / public endpoint / audit metadata
Operator Runbook
担当者が触る場所と、止める場所を分ける。
現場の操作を増やさず、AI の下書きと確認メモを使います。責任が残る操作は approval に戻し、失敗時の扱いも検証条件に入れます。
担当者の操作
- 対象 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 を確認できる
Evidence Packet
検証の証拠を、判断材料に変える。
利用前に「AI が便利だった」ではなく、業務効果、統制、責任境界、展開条件を並べます。
業務範囲
社内 MCP connector 申請 を 1 workflow として、owner は 情シス、AI platform、developer productivity に置きます。
測る効果
現場指標: connector 追加時間、client 追加時の設定差分
見る統制
統制指標: namespace、token rotation、registration audit
判断材料
導入判断: 社内 MCP を vendor 別 tunnel ではなく標準 endpoint で配れるか
Stakeholder Review
社内の誰に、何を説明できるか。
業務部門、情シス、セキュリティ、管理部門が見る論点を分け、検証 の受け入れ条件に変えます。
業務責任者
現場のどの作業が短くなり、どの判断は人間に残るか。
回答
対象 API と利用部門を 1 つ選び、read-only tool から定義する / namespace と clearance を付けて tools/list の見え方を確認する / Gateway endpoint を Claude / GPT の両方に設定する を日次運用に置き、write tool 追加 / public token 発行 / registration 有効化 / 無効化 は承認待ちに戻します。
見る証拠
1 MCP の複数 client 接続 / token 失効
情シス / AI platform
既存画面、社内 API、AI client の境界を説明できるか。
回答
viyv MCP / Viyv MCP Gateway を使い、deny-all 既定 / namespace / registration を最初の境界にします。
見る証拠
token 失効 / tool call metadata / connector 状態
セキュリティ / 法務
AI に渡らない情報、止まる操作、失敗時の扱いは明確か。
回答
deny-all 既定 / namespace / registration / token rotation を検証の統制として固定し、失敗時は 想定外 namespace の tool は tools/list に出さない。
見る証拠
token rotation と revoke を管理画面で説明できる / tool input/output 本文なしで metadata を確認できる
管理部門 / 経営
判断に進む条件と、広げる前の保留条件は何か。
回答
導入判断: 社内 MCP を vendor 別 tunnel ではなく標準 endpoint で配れるか
見る証拠
同じ MCP を 2 種類以上の AI client から呼べる / token rotation と revoke を管理画面で説明できる / tool input/output 本文なしで metadata を確認できる
Next Step
社内 MCP connector 申請 の検証範囲を決める。
対象画面、社内 tool、人間に戻す判断、判断材料を 30 日の検証計画に落とします。