ToolHiveでMCPサーバーを束ねる方法｜社員PCの台帳と隔離

「社員が自分でMCPサーバーを入れて、生成AIに社内のシステムをつないでいる」「どのPCに何が入っているのか、情シスが把握できていない」——AIの道具が社員のパソコンに広がった会社の、情報システム部門から増えている声です。禁止の通知を出しても、MCPサーバーは小さなプログラムなので、入れるのも消すのも利用者の手元で一瞬です。必要なのは取り締まりの強化ではありません。本当は、入れてよいサーバーを情シスが決め、決めたものだけが隔離された形で動く通り道を用意することです。この記事では、MCPサーバーを入れて動かすための管理の道具 ToolHive を例に、2026年10月時点の公式情報をもとに、社員のPCで増えるサーバーを台帳と隔離で束ねる手順を整理します。

ToolHiveとは何をする道具か

公式GitHubによれば、ToolHive は「どんなMCPサーバーでも、安全に、すぐに、どこでも動かす」ための道具です。MCPサーバーを1つずつ独立したコンテナに入れ、最小の権限を書いた設定で包んで動かし、手元のパソコンの認証情報を持たせない、と説明しています。暗号化した秘密情報の管理と、ネットワークの隔離も手元の道具で扱えます。

2026年10月時点の公式ドキュメントでは、ToolHive はMCPサーバーとエージェントのスキルを動かし管理するオープンソースの基盤と位置づけられ、いくつかの部品でできています。社員のパソコンで使うデスクトップの画面版とコマンド版、Kubernetes の上で組織として集中管理するための運用部品、自社が信頼するサーバーの目録を持てる登録簿サーバー、チームが道具を使う入口をまとめるゲートウェイ、です。

つなぎ先のAIの道具として、公式ドキュメントは Claude Code、OpenAI の Codex、Cursor、Google の Antigravity、VSCode（GitHub Copilot）などを挙げています。動かすにはコンテナの実行環境として Docker か Podman が要ります。ライセンスは Apache 2.0 で、2026年10月時点でも公式GitHubの更新は続いています。

この記事で扱うのは、主に社員のパソコンで使う画面版とコマンド版を、情シスがどう束ねるかです。組織で集中管理する部品は、パソコンごとの管理で足りなくなったときの次の段として、後の節で触れます。

提供元のStacklokと、国内でまだ知られていない理由

ToolHive を開発しているのは Stacklok です。公式ドキュメントによれば、同社は ToolHive を中核にした企業向けの有償版 Stacklok Enterprise も提供しており、集中管理、社内のID基盤との連携、強化した配布用のイメージ、ウェブの管理画面などを加えています。オープンソースの ToolHive は単独でも使えます。

2026年10月時点で、ToolHive を日本語で解説した記事はほとんど見当たりません。確かめた範囲で考えられる理由は3つあります。公式の資料が英語であること。社員のパソコンにコンテナの実行環境が入っていることを前提にしており、事務部門の端末にはなじみにくいこと。そして、MCPサーバーを管理する必要そのものが、まだ多くの会社で表に出ていないことです。

MCPサーバーが少数の開発者の手元にあるうちは、管理の道具は話題になりません。生成AIの道具が全社に配られ、営業や企画の担当者まで社内のシステムをつなぎ始めた段階で、初めて「どこに何が入っているか」が問題になります。

MCPとは何か、つなぐ前にどんな確認が要るかは、このサイトの別の記事で整理しています。この記事は、確認を通ったサーバーを、社員のパソコンの上でどう数え、どう隔離し、どう配り、どう止めるかという運用の側に絞ります。

社員のPCで増えるMCPサーバーの何が困るのか

MCPサーバーは、AIの道具に社内外のシステムを操作させるための接続口です。社員が自分で入れる場合、手元のパソコンで直接動き、そのパソコンの利用者と同じ権限でファイルやネットワークに触れます。利用者が読めるファイルは、サーバーも読めるということです。

困るのは、入っていること自体よりも、情シスから見えないことです。どのパソコンに、どの出どころのサーバーが、どの版で入り、どのシステムの鍵を持っているのか。この4つが分からなければ、あるサーバーに問題が見つかったときに、どのパソコンを止めればよいのかを答えられません。

もう1つは、接続の鍵の置き場です。社内のシステムにつなぐサーバーには、アクセスのための鍵が要ります。利用者が設定ファイルに鍵を平文で書き込んでいれば、そのファイルを読める別のプログラムからも鍵が読めます。退職や異動のときに、どの鍵を失効させればよいかも分からなくなります。

こうした状態は、IT資産の台帳が実物とずれていく問題の、新しい形とも言えます。違うのは、MCPサーバーが端末の購入や契約の手続きを経ずに入る点です。台帳の更新を購入の手続きに頼る仕組みでは、そもそも記録に載りません。

束ねる方法の全体像（6つの手順）

社員のパソコンのMCPサーバーを束ねる手順は、次の6つです。ToolHive は手順2から5の多くを道具の機能として担えますが、手順1と手順6、そして各手順の判断は、情シスが持ちます。

順番には意味があります。台帳の形を先に決めないと、登録簿や隔離の設定をしても、それがどのパソコンに反映されたかを追えません。止め方を最後に置くのは、最初の5つが決まっていないと止める手順が書けないからです。以下、手順ごとに決めることを見ていきます。

手順1：台帳を作る。1行に何を書くか

台帳は、パソコン1台とサーバー1つの組み合わせを1行にします。書く項目は、パソコンの識別子と利用者、サーバーの名前と出どころ、版、権限の設定、使っている鍵の名前（鍵の値そのものは書かない）、つないだAIの道具、入れた日、承認した人、です。

ToolHive を通して動かしているサーバーは、道具の側で一覧を出せます。ただ、それはそのパソコンの中の一覧です。会社の台帳にするには、各パソコンの一覧を定期的に集める仕組みが要ります。道具の一覧は台帳の材料であって、台帳そのものではありません。集め方は、既存の資産管理の仕組みに載せるのが続けやすい方法です。

台帳には、ToolHive を通さずに直接入れられたサーバーも載せる必要があります。最初の棚卸しでは、利用者への申告の依頼と、AIの道具の設定ファイルの確認を組み合わせて、今あるものを洗い出します。申告だけに頼ると、使っている自覚のないサーバーが漏れます。

台帳の更新の周期は、月に1回を目安に、登録簿の内容を変えたときにも臨時で突き合わせます。台帳と各パソコンの一覧がずれていたら、それが登録簿の外から入ったサーバーを見つける入口になります。

手順2：入れてよいサーバーの登録簿を決める

ToolHive には、最初から組み込みの登録簿があります。公式ドキュメントによれば、組み込みの登録簿は、最低限の品質の基準を満たした設定の目録です。各サーバーには、公式とコミュニティのどちらの区分かが表示され、ビルドの出どころを検証できる来歴の情報があるかどうかも示されます。

一方で、組み込みの登録簿は誰にとっても同じ目録です。自社が許可したものだけを選ばせるには、自社の登録簿を用意して、道具の参照先をそちらに切り替えます。公式ドキュメントによれば、参照先には、静的な目録のファイルのURL、登録簿のAPIを持つサーバー、手元のファイル、を指定できます。

自社の登録簿を置く場所として、ToolHive の登録簿サーバーがあります。公式の説明では、登録簿サーバーは公式のMCP登録簿のAPIを実装し、認証、複数の情報源からの取り込み、自動の同期を持ち、サーバーを役割や用途でまとめられます。保護された登録簿には、社内のID基盤を通した認証でつなぐ形です。

注意したいのは、参照先の設定を外すと、組み込みの登録簿に戻るという点です。利用者が参照先を自由に変えられる状態では、自社の登録簿は推奨の目録にとどまります。設定を利用者に変えさせないか、変えられたことに台帳の突き合わせで気づける形にしておきます。

登録簿に載せる審査は、情シスが持つ

登録簿は、社員から見れば「会社が入れてよいと言ったサーバーの一覧」です。載せた時点で、会社がそのサーバーの利用を認めたことになります。だからこそ、どのサーバーを登録簿に載せるかは、情シスが審査して決めます。

審査の材料として、組み込みの登録簿の区分と来歴の表示は役に立ちますが、それだけで判断はしません。公式の区分は提供元の判断で、自社の業務に合うかどうかは別の問題です。来歴の情報があっても、そのサーバーがつなぎに行く先のシステムに何を許すかは、自社で決めることです。

審査では、サーバーの提供元、つなぎ先のシステム、そのサーバーに渡す権限の範囲、必要な鍵、更新の頻度、を確かめます。接続の前に確かめる項目の詳しい一覧は、MCPで外部とつなぐ前の確認項目を整理した別の記事に譲ります。ここで決めるのは、その審査を誰がいつ行い、結果をどう登録簿に反映させるかです。

AIの道具には、会話の流れでサーバーの追加を提案するものもあります。AIの道具に自動で接続を足させないことを、利用の規程に明記しておきます。社員からの追加の申請は受け付け、審査を通ったものだけを登録簿に加える流れにします。

手順3：コンテナで隔離して、権限を絞る

ToolHive は、サーバーを1つずつ独立したコンテナで動かします。公式ドキュメントによれば、サーバーごとに1つの権限の設定を持たせ、その中に、読み取ってよい場所、書き込んでよい場所、通信を受け入れる相手、外へ通信してよい宛先とポートを書きます。書き込みを許した場所は、読み取りも許されます。

ここで隔離が効くのは、サーバーがパソコンの利用者と同じ権限で動くのを避けられる点です。設定に書いていない場所のファイルには触れず、書いていない宛先には通信できません。直接入れたサーバーが利用者のファイル全体に触れられるのとは、何かあったときに影響が届く範囲が大きく違います。

権限の設定は、サーバーごとに情シスが決め、登録簿の内容と合わせて管理します。業務に必要な宛先とフォルダだけを書き、すべての宛先を許す設定は、公式も本番の利用には勧めていません。設定を決めたら、試験用のパソコンで動かし、必要な操作ができることと、それ以外ができないことの両方を確かめます。

隔離があるからといって、どんなサーバーでも入れてよいことにはなりません。隔離は、審査を通ったサーバーが想定外の動きをしたときの被害を小さくする網です。審査の代わりにはならない、という順番を崩さないようにします。

既定の設定のままにしない理由

権限の設定には、既定の値があります。公式ドキュメントによれば、組み込みの登録簿のサーバーは、通信の権限を最小に絞った既定の値を持ち、ファイルの権限は既定では何も与えられていません。公式は、この既定の値も自社の方針に照らして見直すよう勧めています。

注意が要るのは、登録簿に載っていない自作のサーバーです。権限の設定を指定せずに動かすと、外への通信をすべて許す設定が既定で使われます。公式はこの設定を開発と試験向けとし、それ以外では宛先とポートを明示した設定を作るよう勧めています。

もう1つの落とし穴は、ファイルの権限だけを書いた設定です。公式ドキュメントは、ファイルの権限だけの設定ではネットワークの通信は止まらず、通信を止めるには隔離の指定を別に足す必要がある、と注意しています。

• 社内で作ったサーバーを、権限の設定を指定しないまま社員に配る
• フォルダの範囲だけを絞り、通信の宛先を絞ったつもりになっている
• 組み込みの登録簿の既定の値を、自社の方針と照らさずにそのまま使う
• 試験の段階で使った、すべての宛先を許す設定が本番のパソコンに残る

こうした取り違えを防ぐには、自社の登録簿に載せるサーバーごとに、使う権限の設定を対にして管理し、配布するときに必ずその設定で動くようにしておきます。

手順4：接続の鍵の置き場を決める

社内のシステムにつなぐサーバーには、鍵が要ります。ToolHive の公式ドキュメントによれば、秘密情報の提供方式は3つあり、同時に使えるのは1つです。既定の暗号化した保管、パスワード管理の製品の保管庫からの読み取り、環境変数からの読み取り、です。後の2つは読み取り専用です。

どの方式でも、鍵はサーバーを動かすときに、コンテナの中の環境変数として渡されます。利用者がAIの道具の設定ファイルに鍵を平文で書く必要がなくなるのが、この仕組みの利点です。鍵の値を設定ファイルに書かせないことを、配布の条件にしておきます。

既定の暗号化した保管には、運用上の注意もあります。公式ドキュメントによれば、暗号化のためのパスワードはOSのキーリングに保存され、それを失ってパスワードも分からなくなると、保管した鍵は復旧できません。パスワードの変更には対応しておらず、保護の方式を新しくする更新は元に戻せないとされています。

こうした性質を踏まえると、会社として鍵を管理するなら、すでに社内で使っているパスワード管理の製品の保管庫から読み取る方式に寄せるほうが、鍵の発行と失効を一か所で扱えます。どの方式を選ぶかは情シスが決め、退職や異動のときに失効させる鍵が台帳から分かる状態にしておきます。

手順5：AIの道具への接続と、キッティングへの組み込み

ToolHive は、AIの道具の接続設定も扱います。公式ドキュメントによれば、対応しているAIの道具を登録しておくと、サーバーの起動・停止・削除に合わせて、その道具の設定が管理されます。AIの道具は、既定の場所に設定ファイルがあるかどうかで見つけられます。設定の変更を反映するには、AIの道具の再起動が要ることがあります。

この仕組みを社員任せにせず、端末の準備の工程に組み込むのが、この手順の要点です。配る前のパソコンに、コンテナの実行環境、ToolHive、自社の登録簿の参照先、標準のサーバーと権限の設定、会社で配るAIの道具の登録、をあらかじめ入れておきます。受け取った初日から、決めた通り道で使える状態にしておけば、自分で別の方法を探す動機が減ります。

コンテナの実行環境が要ることは、配布の対象を決めるうえで大きな条件です。開発や分析の部門のパソコンには入れやすくても、事務部門の端末すべてに入れるのは、性能と管理の手間の両面で重くなります。どの部門に配るかは、MCPサーバーを使う業務があるかで決めます。

既定の場所にないAIの道具は自動では見つからず、手で登録する必要があると公式は書いています。標準の構成から外れた道具を使いたいという申請は、登録簿への追加と同じ審査の流れに乗せます。

グループで、道具ごとに見えるサーバーを分ける

ToolHive には、サーバーをグループにまとめる仕組みがあります。公式ドキュメントでは、役割や用途ごとにサーバーをまとめ、AIの道具を登録するときにグループを指定できることが説明されています。

この仕組みは、部門ごとの標準構成を作るのに使えます。たとえば、営業企画のグループには顧客管理の参照用のサーバーだけ、開発のグループにはコードの管理と課題管理のサーバー、というように分けておけば、業務に要らないサーバーが、AIの道具の選択肢に並ばなくなります。

グループの設計は、台帳と登録簿にもつなげます。台帳にはパソコンごとのグループを書き、登録簿のサーバーには、どのグループに入れてよいかを書きます。異動のときは、グループを付け替え、使わなくなったサーバーの鍵を失効させる、を1つの手続きにします。

グループを細かく分けすぎると、申請と付け替えの手間が増えます。最初は部門単位の3〜4個から始め、例外の申請が多いグループだけを分ける、という順で増やすと運用が回ります。

手順6：止め方と入れ替えの手順

どのサーバーにも、問題が見つかる可能性はあります。提供元から脆弱性の告知が出た、想定していない宛先への通信が見つかった、つなぎ先のシステムの仕様が変わった。そのときに慌てないよう、止め方を先に手順にしておきます。

止める手順は、台帳で影響のあるパソコンを特定する、登録簿から該当のサーバーを外して新たに入れられないようにする、各パソコンでサーバーを止めて削除する、使っていた鍵を失効させる、の順です。ToolHive が接続設定を管理しているAIの道具なら、サーバーを削除すれば、その道具の接続設定からも外れる仕組みです。

入れ替えは、新しい版を試験用のパソコンで確かめ、権限の設定が変わっていないかを見てから登録簿を更新し、台帳の版の欄を書き換える、の順です。版を上げるたびに、必要な権限が増えていないかを確かめます。権限が増える更新は、新しいサーバーを入れるのと同じ重さで審査します。

止めたあとの確認も手順に入れます。台帳の突き合わせの周期を待たず、止めた日から数日のうちに、対象のパソコンの一覧からサーバーが消えたかを確かめます。消えていないパソコンが残れば、利用者に個別に連絡します。

パソコンごとの管理で足りなくなったとき

ここまでの手順は、社員のパソコンで画面版とコマンド版を使う前提です。対象のパソコンが増え、台帳の集約や設定の配布が重くなってきたら、次の段を考えます。

ToolHive には、Kubernetes の上でサーバーと登録簿をまとめて管理する運用部品があります。公式ドキュメントによれば、この上で動くゲートウェイ（仮想のMCPサーバー）は、入ってくる通信を受け、複数のサーバーを1つの入口にまとめ、方針を当てはめる役割を持ちます。サーバーを社員のパソコンではなく社内の基盤で動かせば、台帳は基盤の側の1つで済みます。

観測と監査の記録については、公式ドキュメントが、標準的な観測の仕組みに対応していることと、運用部品・ゲートウェイ・登録簿サーバーそれぞれの監査記録の手引きを挙げています。誰がどのサーバーの道具を呼び出したかを、会社の記録として残せるかどうかが、パソコンごとの管理との大きな違いです。

集中管理や社内のID基盤との連携、ウェブの管理画面まで求めるなら、有償の Stacklok Enterprise が選択肢になります。費用は、対象の利用者やサーバーの数に応じて増える形を想定し、提供元に確かめます。いずれの段でも、登録簿に何を載せるか、権限をどこまで許すかを決めるのは情シスです。

決めること・決める人・道具で担える範囲

6つの手順を、決めることと決める人、ToolHive で担える範囲に分けて1枚にまとめます。

決めること	決める人	道具で担える範囲
台帳の形と集め方	情シス	各パソコンで動いているサーバーの一覧を出す
登録簿に載せるサーバー	情シス（つなぎ先の部門と協議）	自社の登録簿を参照させ、区分と来歴を表示する
サーバーごとの権限	情シス	コンテナで隔離し、場所と宛先を設定どおりに絞る
鍵の保管方式と失効	情シス（つなぎ先のシステムの管理者）	暗号化した保管か保管庫から、コンテナに渡す
配る部門と標準構成	情シスと各部門の責任者	AIの道具の接続設定とグループを管理する
止める判断と入れ替え	情シス	サーバーを止めて削除し、接続設定から外す
AIの道具からの追加の提案	情シス（審査）	担えない。規程で禁じ、台帳の突き合わせで気づく

表の中で、道具が担えるのは決めたことを各パソコンで実行し、記録を出すところまでです。何を許すかの判断は、どの行でも人の側に残ります。道具を入れたことで判断が済んだと受け取られないよう、この表は規程に添付しておきます。

最初からすべての行を埋める必要はありません。まずは台帳と登録簿の2行から始め、権限と鍵、配布、止め方の順に決めていくと、利用者の不便を最小にしながら移れます。

よくある質問

ToolHive を入れれば、MCPサーバーの安全は確保できますか

確保できるのは、決めたサーバーを決めた権限で動かす通り道までです。どのサーバーを許すか、権限をどこまで渡すかは、情シスの審査で決まります。道具は審査の代わりにはなりません。

コンテナの実行環境を全社員のパソコンに入れる必要がありますか

ToolHive でサーバーを動かすパソコンには、Docker か Podman が要ります。ただし、MCPサーバーを使う業務がない部門にまで入れる必要はありません。配る部門を先に決め、それ以外は社内の基盤で動かす形も検討します。

社員が登録簿にないサーバーを使いたいと言ってきたら、どうしますか

追加の申請として受け付け、登録簿に載せる審査と同じ流れで判断します。審査を通れば、権限の設定と対にして登録簿に加え、台帳にも記録します。急ぎの場合も、試験用のパソコンで確かめる工程は省きません。

オープンソースの道具を使い続けて大丈夫ですか

2026年10月時点で、ToolHive は Apache 2.0 のもとで公開され、更新も続いています。それでも、ライセンスや提供条件は変わることがあります。担当を決めて公式GitHubを定期的に確かめ、台帳と登録簿を道具に閉じない形でも持っておくと、乗り換えが必要になっても困りません。

まとめ

ToolHive は、MCPサーバーを1つずつコンテナで隔離して動かし、登録簿からの導入、鍵の受け渡し、AIの道具への接続設定をまとめて扱えるオープンソースの道具です。社員のパソコンで増えるサーバーを束ねるには、台帳を作る、入れてよいサーバーの登録簿を決める、隔離して権限を絞る、鍵の置き場を決める、配布とキッティングに組み込む、止め方と入れ替えを決める、の6つの手順で進めます。道具が担うのは決めたことの実行と記録で、どのサーバーを載せるか、何を許すかを決めるのは情シスです。AIの道具に自動で接続を足させない線も、規程に書いておきます。まずは、今あるサーバーを洗い出す最初の棚卸しから始めてみてください。

• 製品の機能・構成・ライセンスは、ToolHive の公式GitHubと公式ドキュメントを2026年10月14日に確かめた範囲に基づきます。機能や既定の値は更新で変わることがあるため、導入前に最新の原文を確かめてください
• MCPサーバーの審査の観点や、つなぐ前の確認項目は、自社の情報セキュリティの規程に合わせて決めてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。