業務責任者
どの社内 tool を AI に渡すか
確認する問い
HR、Finance、CS などで、自然言語ではなく tool schema に落とす作業が決まっているか。
見る証拠
tool 名、input schema、利用者、承認が必要な action、業務時間の変化。
判断材料
担当者が同じ tool を繰り返し使う業務なら、connector 化の投資対効果が出やすい。
Secure MCP framework
社内ツールを MCP 化するための、Python 実装基盤。
decorator で tool、resource、prompt、HTTP endpoint を定義し、StreamableHTTP と stdio の両方に対応する MCP サーバを少ない boilerplate で作れます。
Adoption Review Packet
MCP をレビューに出す時、誰が何を見るか。
機能説明だけでは社内説明に進めません。業務責任者、情シス、 セキュリティ、管理部門がそれぞれ確認する問い、見る証拠、判断材料を分けます。
セキュリティ / 法務
tool 呼び出しの認可を説明する
確認する問い
AI client、user、scope、tenant、rate limit、dangerous action の扱いが分かれているか。
見る証拠
認可条件、拒否された call、scope mismatch、audit event、token 失効履歴。
判断材料
tool surface を標準化してから権限を絞れるなら、社内 API 公開の不安を下げられる。
情シス / platform
connector の運用 owner を決める
確認する問い
schema version、test、deploy、障害時 rollback、既存 API 変更時の owner が決まっているか。
見る証拠
connector version、test result、変更履歴、失敗 call、rollback 手順。
判断材料
個別 script ではなく管理された MCP server として運用できるなら、横展開しやすい。
管理部門 / 管理者
Gateway まで必要かを切り分ける
確認する問い
複数 AI client、公開 URL、token 管理、監査一元化が最初から必要か。
見る証拠
利用 client、connector 数、token owner、監査提出先、公開範囲。
判断材料
connector 実装が主課題なら MCP から始め、配布統制が出たら Gateway を足す。
Problem
企業のどの問題を解くのか。
各チームが MCP サーバを個別に作ると、schema 生成、transport、JWT、監査、外部 MCP bridge の実装が散らばります。viyv MCP は MCP サーバの作り方とセキュリティ面を標準化します。
MCP Connector Playbook
社内 API を、AI が安全に呼べる tool surface に変える。
MCP の価値は Python で tool を書けることだけではありません。社内 API を AI に渡す時に、schema、namespace、clearance、deny log を揃え、業務チームごとに増える connector を企業標準に寄せます。
HR / Platform
HR: 社員情報 API を read-only tool にする
利用前の問題
社員検索、組織図、有休残高などを AI から使いたいが、人事データは誰に何が見えるかの境界が厳しく、API をそのまま渡せない。
viyv での流れ
- employee_search を @tool で定義し、入力 schema と返却項目を最小化する
- namespace='hr'、clearance='internal' を付け、tools/list から見える client を制限する
- 給与や評価のような confidential tool は別 namespace / higher clearance に分ける
止める操作
namespace がない token、clearance 不足、write 系 endpoint、PII の過剰返却を deny する。
利用前の evidence
tools/list に出る tool、許可された呼び出し、拒否された呼び出し、schema、返却データの mask 方針をレビューできる。
使う理由
人事 API チームが個別に認可実装を作らず、情シスとセキュリティに共通の connector 標準として説明できる。
Finance / Backoffice
Finance: 請求・支払 API を段階的に MCP 化する
利用前の問題
請求書検索、支払先確認、入金消込 API を AI に使わせたいが、金額変更や支払実行まで開けるとレビューが通らない。
viyv での流れ
- 最初は invoice_search と vendor_status の read-only tool だけを公開する
- write 系 tool は別 namespace に分け、検証では tools/list に出さない
- 呼び出し結果、latency、失敗理由を JSONL audit として残す
止める操作
支払実行、金額変更、支払先更新、権限外 vendor 参照は検証範囲外として deny する。
利用前の evidence
read-only tool だけで何件の調査を短縮できたか、どの tool が拒否されたか、write 系を未公開にできたかを示す。
使う理由
Finance 責任者には調査時間、セキュリティには write endpoint を閉じた証拠、管理部門には次段階の Gateway 接続条件を示せる。
AI Enablement
既存 MCP: ばらついた connector を標準化する
利用前の問題
filesystem、検索、SaaS connector など既存 MCP が増え、設定、命名、token、監査の粒度がチームごとに違う。
viyv での流れ
- 外部 MCP を bridge config で child process として読み込む
- group / namespace / security_level を tool 単位または connector 単位で上書きする
- viyv_mcp の HTTP endpoint として再公開し、必要なら Gateway へ outbound 接続する
止める操作
起動失敗した外部 MCP、namespace 未設定 tool、clearance 不足、想定外の tool name を隔離する。
利用前の evidence
bridge 前後の tool 一覧、override された namespace、拒否 log、Gateway へ announce された tool surface を比較する。
使う理由
既存資産を捨てずに、社内 MCP の作り方と公開前レビューを標準化できることが platform 採用の根拠になる。
Concrete Scenarios
実際の業務では、こう使う。
ただの機能一覧ではなく、担当者、現在の詰まり、viyv を入れた後の流れ、統制が発火する場所まで具体化します。
01社内 platform / 情シス開発チーム
HR データ API を権限付き MCP にする
給与、評価、在籍情報などの API は AI に渡したいが、部署ごとに見える tool と実行できる tool を分ける実装が重い。
- Python 関数を @tool で定義し、型ヒントから input schema を生成
- namespace='hr'、security_level=1 のように tool ごとの認可を付ける
- JWT の trusted namespace と clearance で tools/list と tools/call を制御
deny-all 既定namespace visibilitynumeric clearanceJSONL audit
各業務 API チームが MCP の認可実装を作り込まず、共通パターンで安全に tool 化できます。
02AI enablement / platform チーム
既存 MCP を bridge して標準化する
filesystem、検索、業務 SaaS などの MCP が増え、設定・命名・権限・監査がチームごとにばらついている。
- JSON config で外部 MCP を child process として起動
- group、namespace、security_level を一括または tool 単位で付与
- viyv_mcp の HTTP endpoint として再公開し、Gateway へ接続
外部 MCP ごとの namespacetool 単位 override起動失敗の分離audit logging
既存資産を捨てずに、企業で管理できる MCP surface に寄せられます。
03社内 tool を公開したくない開発者
ローカル connector を Gateway に outbound 接続する
社内ネットワークや個人端末上の MCP は inbound を開けづらく、Claude / GPT へつなぐたびに tunnel 設定が増える。
- connect mode で Gateway の /ws/bridge に接続
- native tool と bridged tool を announce
- Gateway の public endpoint 経由で AI クライアントから呼び出す
relay keyreconnect with backofftool announcepublic token は Gateway 側
MCP server 側は公開ポートを持たずに、外部 AI から使える connector になります。
Capabilities
具体的にできること。
型ヒントから MCP tool schema を生成
Python 関数に `@tool` を付けるだけで、同期・非同期関数を MCP tool として公開し、Pydantic metadata から schema を生成します。
StreamableHTTP と stdio を同じ実装で提供
クラウド公開、ローカル開発、CLI 起動のどれでも同じ tool surface を使えます。stateless HTTP mode で multi-worker 展開も可能です。
namespace と clearance による JWT 認可
tool の可視性は namespace、実行可否は numeric clearance で制御。deny-all 既定で、production の bypass を防ぎます。
外部 MCP と Gateway 接続を bridge
既存 MCP を child process として再公開し、connect mode で Viyv MCP Gateway に outbound 接続できます。
Use Cases
どんな業務に使えるのか。
社内 DB / API / SaaS を MCP サーバ化
HR、営業、経理などの業務 API を、権限付き tool として AI エージェントに提供します。
既存 MCP のセキュリティラップ
filesystem、検索、業務 API などの外部 MCP を bridge し、namespace、clearance、audit を足して再公開します。
Gateway へ outbound 接続する connector
公開 inbound を開けずに、社内 MCP を Gateway 経由で Claude / GPT から使えるようにします。
Implementation Path
どう利用を始めるか。
1 つの業務 API から始める
まず read-only tool を @tool で定義し、schema と audit を確認してから書き込み系 tool を増やします。
namespace 設計を最初に決める
hr、finance、sales、common のように可視性の単位を決め、agent の trusted namespace と対応させます。
Gateway 接続は bridge config から段階導入する
既存 MCP は JSON config で bridge し、新規 MCP は decorator authoring で作ると、移行負荷を抑えられます。
Product Validation Brief
MCP で検証計画する時に、最初に揃えるもの。
製品詳細を読んだ後は、相談時に何を決めるかまで落とします。最初の workflow、 持ち込む情報、通す統制、判断材料を 1 枚にできます。
Start
最初の workflow
HR データ API を権限付き MCP にする を起点に、担当者、入力、AI の役割、人間に戻す判断を 1 つずつ決める。
Bring
相談時に持ち込む情報
社内 platform / 情シス開発チーム が使う画面 / tool / data、現在の作業時間、AI に任せたい作業、止めたい操作を整理する。
Control
最初に通す統制
deny-all 既定 / namespace visibility / numeric clearance / JSONL audit
Decision
判断材料
MCP サーバ開発の boilerplate を減らす。チームごとの認可・監査実装のばらつきを抑える。この変化を検証の証拠で説明できれば、Team / Enterprise の検討へ進む。
Pilot Design
判断に必要な検証を、最初から設計する。
検証は「触ってみる」だけでは足りません。対象業務、必要な統制、成功条件、次の展開先を 1 枚で説明できる状態にしてから始めます。
Start Workflow
HR データ API を権限付き MCP にする
給与、評価、在籍情報などの API は AI に渡したいが、部署ごとに見える tool と実行できる tool を分ける実装が重い。
Control Scope
最初に通す統制
- deny-all 既定
- namespace visibility
- numeric clearance
- JSONL audit
Success Evidence
レビューで見る証拠
- MCP サーバ開発の boilerplate を減らす
- チームごとの認可・監査実装のばらつきを抑える
- ローカル、社内、クラウドの transport を同じコードで扱う
Adoption Signals
こういう状態なら、検証の価値があります。
MCP server がチームごとに増え、認可・監査・schema 品質が揃っていない
Python で業務 API を素早く MCP 化したい
既存の official SDK MCP を変更せず Gateway へつなぎたい
stdio と HTTP の両方を同じ tool 実装で支えたい
Product Selection Board
MCP を選ぶ条件と、別製品から始める条件。
viyv は suite なので、最初の製品選びが重要です。必要な状態、まだ別製品から始めるべき状態、 利用前に集める証拠、次に足す製品を 1 枚で確認できます。
Choose
MCP を選ぶ条件
- MCP server がチームごとに増え、認可・監査・schema 品質が揃っていない
- Python で業務 API を素早く MCP 化したい
- 既存の official SDK MCP を変更せず Gateway へつなぎたい
Start Elsewhere
別製品から始める条件
- 既存 SaaS / admin 画面を AI に触らせることが最初なら Browser から始める
- connector 実装よりも公開 URL / token / 監査の一元化が問題なら MCP Gateway を先に見る
- agent catalog や run history の管理が主課題なら Agent Foundry を先に見る
Proof
利用前に集める証拠
- HR データ API を権限付き MCP にする を対象に、担当者・入力・出力・人間判断を 1 枚で説明できる
- 最初に通す統制: deny-all 既定 / namespace visibility / numeric clearance
- 運用後に期待する変化: MCP サーバ開発の boilerplate を減らす / チームごとの認可・監査実装のばらつきを抑える
Next Product
次に足すなら MCP Gateway
- MCP で tool surface を標準化した後、Gateway で接続、token、監査、OAuth を中央管理する。
- MCP サーバ開発の boilerplate を減らす
Adoption Decision
MCP を使う判断を、検証の証拠に落とす。
製品の機能だけでは判断に進めません。どの状態なら必要なか、まだ早いか、検証 で何を集めるかを明確にします。
Buy When
こういう状態なら検討価値が高い
- MCP server がチームごとに増え、認可・監査・schema 品質が揃っていない
- Python で業務 API を素早く MCP 化したい
- 既存の official SDK MCP を変更せず Gateway へつなぎたい
Not Yet
この状態なら、先に検証設計を詰める
- 対象 workflow、利用者、成功条件がまだ決まっていない
- AI に任せる作業と、人間に戻す判断を分けられていない
- セキュリティレビューに出す mask / approval / audit 証跡が決まっていない
Proof
利用前に集める証拠
- HR データ API を権限付き MCP にする を対象に、担当者・入力・出力・人間判断を 1 枚で説明できる
- 最初に通す統制: deny-all 既定 / namespace visibility / numeric clearance
- 運用後に期待する変化: MCP サーバ開発の boilerplate を減らす / チームごとの認可・監査実装のばらつきを抑える
Stakeholder Answers
社内の誰に、何を説明できるか。
業務責任者
どの作業時間を削るか、どの判断を人間に残すかを、具体シナリオと成功指標で説明できます。
情シス / platform
認可、接続方式、監査、既存システムとの境界を architecture と implementation path で整理できます。
セキュリティ / 法務
AI に渡る情報、保存されるログ、人間承認が必要な操作を control scope として切り出せます。
Buyer Review Questions
MCP を社内で説明する時に、先に答える質問。
製品詳細の最後に、役割ごとの確認事項を整理します。業務、platform、 セキュリティ、管理部門がそれぞれ何を聞き、どの証拠で判断するかを分けます。
業務責任者
MCP で、どの作業や判断が変わるのか。
回答
HR データ API を権限付き MCP にする を起点に、現在の詰まりを Python 関数を @tool で定義し、型ヒントから input schema を生成、namespace='hr'、security_level=1 のように tool ごとの認可を付ける、JWT の trusted namespace と clearance で tools/list と tools/call を制御 という流れに変えます。
見る証拠
MCP サーバ開発の boilerplate を減らす / チームごとの認可・監査実装のばらつきを抑える
情シス / platform
既存システムとの境界と運用 owner は説明できるか。
回答
Authoring: @tool / @resource / @prompt / @entry で Python から定義 / Security: JWT、namespace、clearance、JSON audit logging / Bridge: 外部 MCP や Gateway へ接続し tool surface を再公開
見る証拠
1 つの業務 API から始める / namespace 設計を最初に決める
セキュリティ / 法務
AI に渡る情報、止める操作、残る証跡をどう説明するか。
回答
deny-all 既定 / namespace visibility / numeric clearance / JSONL audit
見る証拠
HR データ API を権限付き MCP にする を対象に、担当者・入力・出力・人間判断を 1 枚で説明できる / 最初に通す統制: deny-all 既定 / namespace visibility / numeric clearance
管理部門 / 管理者
検証から運用へ進む条件は何か。
回答
MCP server がチームごとに増え、認可・監査・schema 品質が揃っていない 状態なら、1 workflow の検証で fit を確認します。
見る証拠
HR データ API を権限付き MCP にする を対象に、担当者・入力・出力・人間判断を 1 枚で説明できる / 最初に通す統制: deny-all 既定 / namespace visibility / numeric clearance / 運用後に期待する変化: MCP サーバ開発の boilerplate を減らす / チームごとの認可・監査実装のばらつきを抑える
30-Day Rollout
30 日で判断まで進める。
最初から全社展開を狙わず、1 つの業務・1 つの統制・1 つの成功条件に絞って、継続利用すべきかを判断します。
対象業務を 1 つに絞る
HR データ API を権限付き MCP にする を起点に、担当者、入力、出力、人間が判断する地点を決めます。
統制と接続を実装する
まず read-only tool を @tool で定義し、schema と audit を確認してから書き込み系 tool を増やします。
実業務でログを見る
拒否理由、承認待ち、tool 呼び出し、schema 変更、実行 event など、判断材料に使う証跡を集めます。
次の展開先を決める
MCP サーバ開発の boilerplate を減らす かを確認し、部門追加、connector 追加、Enterprise 要件を整理します。
Buyer FAQ
利用前によく出る質問。
既存の AI クライアントは置き換える必要がありますか。
置き換えません。Claude、GPT、Cursor、社内 agent などの前後に置き、接続・統制・監査の境界を追加します。
最初に何を準備すれば検証できますか。
対象業務、利用する画面または tool、許可したい操作、止めたい操作、レビューしたいログを 1 つずつ決めれば始められます。
セキュリティレビューでは何を見せられますか。
AI に渡る範囲、認可条件、人間承認、masking、audit metadata、失効・rollback の運用を、製品ごとの検証証跡として提示します。
Business Outcomes
利用で変わること。
- MCP サーバ開発の boilerplate を減らす
- チームごとの認可・監査実装のばらつきを抑える
- ローカル、社内、クラウドの transport を同じコードで扱う
- Gateway 連携により公開設定なしで社内 tool を外部 AI に届ける
Architecture
どう動くのか。
Authoring
@tool / @resource / @prompt / @entry で Python から定義
Security
JWT、namespace、clearance、JSON audit logging
Bridge
外部 MCP や Gateway へ接続し tool surface を再公開