最近、自宅のOpen WebUI環境にMCPを登録していたら、気が付けば26個になっていた。AWS、Azure、Google Cloud、GitHub、Notion、Tailscale、Docker、Kubernetes……。もはやAIツールというより、自分のIT資産の棚卸しに近い。
もはや個人の棚卸しに近い。これでもvSphereやProxmoxなどの仮想環境やちょくちょく仕事で触っていた環境も登録していたらゆうに30は超えていたかもしれない。MCPは原理さえわかれば、ものによっては自作もできてしまう。
最初は単純に、
AWSやAzure、GCPをチャットから操作できたら便利そう
という軽い気持ちだった。
しかし実際に構築してみると、MCPサーバを利用可能な状態にするまでには、思った以上に高い壁がいくつも存在することが分かった。
まず一つ目は、MCPサーバが必要とする実行環境の問題である。
例えば Azure MCP を使うなら
az コマンドが必要になるし、Google Cloud MCP なら gcloud、Tailscale MCP なら bunや node が必要になる場合がある。つまり、単純に MCP の設定を書くだけでは動かず、MCP
↓
必要なコマンドやライブラリ
↓
認証情報
↓
実際のサービス
という階層構造になっている。
MCPOコンテナに必要なコマンドやライブラリが入っていなければ、まずコンテナイメージ自体を作り直さなければならない。
二つ目は認証の壁だ。
GitHub、Notion、AWS、Azure、Google Cloudなどは当然ながら認証が必要になる。
特に Azure や Google Cloud はブラウザ認証を伴うため、コンテナ内で認証を通すだけでも一苦労だった。
そして三つ目は、MCPサーバそのものが正常に起動するかという問題である。
環境変数が足りなかったり、依存ライブラリが不足していたり、コマンドのバージョンが合わなかったりするだけで、MCPはあっさり起動しなくなる。
結局、
-
必要なコマンドやライブラリを揃える
-
認証情報を設定する
-
MCPが正常起動することを確認する
という三段階を突破して、初めて利用できるようになる。気が付けば、私のMCPOコンテナは 1GB を軽く超えるサイズになっていた。インストールパッケージを改めて見るともはやあらゆるツールがインストールされている踏み台サーバみたいになっていた。
なぜそこまでしてMCPを使うのか
理由は単純だ。
私はAWS、Azure、Google Cloud、Kubernetes、Dockerなどを日常的に触っている。しかし、しばらく使わないとコマンドを忘れる。コマンド補完で済む話ならまだいい。
問題は、そもそも何をやれば実現できるんだっけ？という状態になった時だ。
そのたびにドキュメントを探し、検索し、調べ直すのは意外と時間がかかる。
一方で MCP があれば、
Azureで仮想マシンを作りたい
GCPのバケットを確認したい
GitHubのIssueを整理したい
とチャットで指示するだけで、Agentが必要な情報を調べ、適切なツールを使って作業を進めてくれる。もちろん最終確認は必要だが、作業の入口にかかる時間は劇的に短くなる。
「知識」より「解決手段」を持つ時代
MCPを使っていて感じるのは、昔のように
「製品のコマンドを全部覚えている人」
が強い時代ではなくなりつつあることだ。
もちろん基礎知識は必要だ。
しかし本当に重要なのは、
「問題をどう解決するかを知っている」こと
であり、
その「解決手段を実行できる環境を持っている」こと
なのではないかと思う。
今後、運用エンジニアやインフラエンジニアの価値は、
「コマンドを暗記していること」から、
「適切なAgentとMCPを設計し、安全に運用できること」
へ移っていくのかもしれない。
さらに言えば、セキュリティ侵害を狙う攻撃者も今やAIを利用している。AIを使えば、情報収集、コード生成、脆弱性探索、フィッシングメール作成などを驚くほど短時間で行える。攻撃者の頭脳と手足が同時に強化されるようなものだ。もし運用側が従来通り手順書を見ながら作業しているだけだとしたら、その差は今後さらに広がっていくかもしれない。最近、大手企業や金融機関が最新のAIモデルの利用を積極的に進めているのも、単なる効率化だけではなく、こうした変化への対応という側面があるのではないかと思う。
そんなことを考えながらMCPを増やしていたら、思わぬ発見があった。それが Open WebUI Server と Open WebUI Desktop の存在意義である。
1. Open WebUI Server と Open WebUI Desktop の違い
当初の認識
Open WebUI Desktop
↓
簡単セットアップ版
だと思っていた。
実際、インストールするだけで一通り、LLMも含めて使えるようになる。しかし実際にMCPを大量に登録してみると、
Open WebUI Desktop
↓
個人専用Agent環境
としての意味が大きいことに気付いた。
共有すると効率のいいもの
Ollama
Qdrant
SearXNG
Tika
Docling
共有したくないもの
GitHub
Notion
Azure
GCP
AWS
Tailscale
Memory
Workspace
Chat履歴
MCP
つまり
共有AI基盤
↓
Open WebUI Server
個人Agent環境
↓
Open WebUI Desktop
という住み分けが自然ではないか。
2. MCPは共有向きではないものが多い
MCPを登録していて気付いたのは、MCPには大きく2種類ある。
共有しやすいもの
Time
Weather
Draw.io
Fetch
Calculator
共有しにくいもの
GitHub
Notion
Azure
AWS
GCP
Tailscale
例えば Notion MCP。
自分のNotionアカウントを認証すると、
Open WebUI
↓
Notion MCP
↓
自分のNotion
になる。
もし共有Open WebUIに登録すると、
理論上
他ユーザー
↓
自分のNotion
にアクセスできる。
つまり
MCP
=
個人資産への入口
になりやすい。
3. Agentに権限を与え過ぎる危険性
MCPは便利だ。便利すぎる。
例えば
Azure MCP
GCloud MCP
GitHub MCP
を登録すると、チャットで
仮想マシンを作って
と言うだけで、Agentが必要な手順を実行できる。
しかし逆に言うと、
権限のある人
↓
Agent
↓
クラウド
という構造になる。
つまり
Agent
=
権限の代理人
である。
便利だからといって、
全部の権限
全部のクラウド
全部のMCP
を無造作に渡すのは危険。
運用現場で使うなら、
何をAIに任せるか
何を人間が承認するか
を決める必要がある。
4. Terminalは究極のMCPである
実はMCPを色々試していて、一番強力なのはMCPではなかった。
それが、Open WebUIについている
Terminal
である。
以下は、MCPサーバではなく、ターミナルを使ってとだけ伝えている。
例えば踏み台サーバに
AWS CLI
Azure CLI
gcloud
kubectl
docker
ssh
が全部入っていたとする。
すると
Open WebUI
↓
Terminal
↓
踏み台サーバ
だけで
AWS
Azure
GCP
Kubernetes
Docker
全部操作できてしまう。
つまり
Terminal
=
汎用MCP
あるいは
究極のMCP
である。
だから
MCPは危険
ではなく、
本当に危険なのは
権限のあるTerminal
へのアクセスだったりする。
最後の結論
最終的に辿り着いた結論は、
共有するもの
↓
LLM
Embedding
RAG
個人で持つもの
↓
MCP
Memory
Workspace
Agent
という構成だった。
その意味では、
Open WebUIサーバは
共有のチャットやRAG
Open WebUI Desktopは
単なるOpen WebUIの簡易版ではなく、Agent時代における
個人専用AIワークステーション
としての価値を持っているのかもしれない。
そして、ちょうどそのタイミングでNVIDIAがDGX SparkのノートPC版のような製品を発表した。
MCPを触る前は、「AIは巨大なGPUサーバに集約して使うもの」だと思っていた。しかし実際にAgentやMCPを運用し始めると、共有したいものと共有したくないものが明確に分かれてくる。
- 共有したいのは、GPUやモデル、Embedding、RAG基盤だ。
- 共有したくないのは、権限、認証情報、履歴、Memory、Workspace、そしてAgentそのものである。
そう考えると、これからのAI環境は「GPUやモデルは共有し、Agentや権限は個人で持つ」という方向に進んでいくのかもしれない。
Open WebUI Desktopを単なる簡易版だと思っていた私が、最終的に「個人専用AIワークステーション」として再評価するようになったのも、その延長線上にある。
もしかすると、Agent時代の主役は巨大なAIサーバではなく、一人ひとりが持つAgent環境なのかもしれない。
MCPを登録していて面白かったのは、AIそのものではなく、自分が普段何を使っているのかを棚卸しできたことだった。AI活用というと議事録作成や資料作成が注目されがちだが、実際には日々の業務の大半は地味な確認作業や繰り返し作業で占められている。MCPやn8nが本当に効果を発揮するのは、そうした目立たない作業を自動化する場面なのかもしれない。