見出し画像

【教えてAI先生】MCPって何？ AIに道具を渡す前に考えたいこと

アリさん

最近、AI界隈で MCP という言葉をよく聞くようになりました。

MCP対応。
MCPサーバー。
MCPでツール連携。
MCPでエージェント化。

そんな話が、かなり増えてきた気がします。

見かける記事や投稿は、どちらかというと、MCPの可能性を前向きに紹介するものが多い印象です。

AIがいろいろなツールにつながる。
エージェント化が進む。
外部データを参照できる。
AIに業務ツールを使わせられる。

たしかに便利そうです。

ただ、個人的には少し気になるところもあります。

AIが外部ツールにつながるということは、AIが見える情報や操作できる範囲が広がるということでもあります。

便利になる一方で、扱いを間違えると危ないのではないか。

MCPをただ便利な接続規格として見るだけではなく、

「何を見せるのか」
「何を操作させるのか」
「どこで人間が止めるのか」

まで含めて考える必要があるのではないか。

そんな疑問も含めて、AI先生に聞いてみました。

言葉だけだと少し分かりにくいので、まずはイメージ図で全体像を見てみます。

MCPは、AIと外部のツールやデータをつなぐための仕組みです。

ただし、MCPを入れれば安全に全部使える、という話ではありません。
何をつなぐのか、どこまで使わせるのかは、別できちんと考える必要があります。

では、ここから順番に整理していきます。

まず一言でいうと

MCPは、AIが外部のツールやデータに接続するための共通規格です。

もう少し乱暴に言うと、

AIと外部ツールをつなぐための「土管」や「共通の接続口」

のようなものです。

たとえば、人間が仕事をするときには、いろいろなものを見に行きます。

メールを見る。
カレンダーを見る。
ファイルを見る。
社内Wikiを見る。
チケットを見る。
DBを見る。
検索する。
必要なら何かを更新する。

AIにも同じことをさせたい。

でも、ツールごとに接続方法がバラバラだと大変です。

そこで、

AIと外部ツールを、共通のやり方でつなげるようにしよう

という考え方が出てきました。

それがMCPです。

ただし、MCPは万能な安全装置ではない

ここは最初に強調しておきたいです。

MCPは便利です。

AIが外部のデータを見たり、ツールを使ったりしやすくなる。
エージェント化とも相性が良い。
AIを単なるチャットから、実際の仕事環境につなげやすくなる。

ただし、MCPを導入したからといって、細かい権限制御や安全設計まで自動で解決するわけではありません。

MCPは、あくまで「つなぐ仕組み」です。

何を見せるのか。
何を操作させるのか。
どこまで実行させるのか。
削除を許すのか。
外部送信を許すのか。
本番環境に触らせるのか。
人間承認をどこで挟むのか。

こうした設計は、MCPそのものが勝手に全部やってくれるわけではありません。

接続先のシステム側。
MCPサーバー側。
AIを動かすホスト側。
そして、導入する人間側。

そこで、きちんと設計する必要があります。

つまり、

MCPは「つなぐ仕組み」。
だからこそ、つないだ先で何を許すかを慎重に決める必要がある。

ここを軽く見ると危ないと思います。

API連携と何が違うのか

外部ツールにつなぐだけなら、API連携でもできるのでは？
と思います。

たしかにできます。

ただ、API連携は基本的に、アプリごと、ツールごとに個別対応になります。

このAIアプリには、このAPIをつなぐ。
別のAIアプリには、また別の方法でつなぐ。
ツールが増えるたびに、接続方法を考える。

これだと、組み合わせが増えるほど大変になります。

MCPは、そこに共通の接続口を作ろうとするものです。

AIごとに個別接続するのではなく、共通の方式で外部ツールやデータにつなぐ。

そう考えると、MCPは「AI向けの共通接続規格」と言えそうです。

USB-Cみたいなもの、という説明

MCPの説明では、よく USB-C のたとえが使われます。

USB-Cがあると、パソコンにいろいろな周辺機器をつなげます。

モニター。
キーボード。
外付けストレージ。
充電器。

機器ごとに完全に別々の専用口を作るのではなく、共通の口でつなぐ。

MCPもそれに近いイメージです。

AIアプリ側がMCPに対応している。
ツール側もMCPサーバーとして用意されている。
すると、AIがそのツールを使いやすくなる。

ただし、ここでも注意が必要です。

USB-Cの口があるからといって、何をつないでも安全なわけではありません。

何をつなぐのか。
つないだ機器が何をできるのか。
どこまでアクセスできるのか。

そこは別に考える必要があります。

MCPも同じです。

「つながる」ことと「安全に使える」ことは別です。

MCPサーバーって何？

MCPを調べていると、MCPサーバーという言葉も出てきます。

これも少し分かりにくいです。

ざっくり言うと、MCPサーバーは、

AIに対して「このツールはこう使えますよ」と提供する側

です。

たとえば、ファイル検索用のMCPサーバーがあるとします。

そのサーバーは、AIに対して、

「このフォルダを検索できます」
「このファイルを読めます」
「この形式で結果を返します」

という機能を提供します。

DB用なら、

「このDBを検索できます」
「このテーブルを参照できます」
「このクエリを実行できます」

のような機能を提供します。

AIアプリは、MCPクライアントとしてMCPサーバーに接続し、その機能を使う。

そんなイメージです。

ただし、ここでも大事なのは、

MCPサーバーが何を公開するか

です。

ファイルを全部見せるのか。
一部のフォルダだけ見せるのか。
DBを読み取り専用にするのか。
更新も許すのか。
削除まで許すのか。

ここを雑にすると、MCPは一気に危なくなります。

MCPサーバーは便利な窓口ですが、窓口である以上、何を外に出すかを慎重に決める必要があります。

何がうれしいのか

MCPがうれしいのは、AIが孤立したチャットではなくなることです。

普通のチャットAIは、基本的にその会話の中で答えます。

でも仕事で本当に使うなら、AIには外部の情報を見てほしい。

最新の資料を見る。
過去の議事録を見る。
チケットの状態を見る。
カレンダーを見る。
ファイルを検索する。
場合によっては、何かを作成する。

MCPがあると、こうした外部ツール連携を共通のやり方で扱いやすくなります。

つまり、MCPはエージェント化とも相性が良いです。

エージェントが仕事を進めるには、道具が必要です。

調べる道具。
読む道具。
書く道具。
更新する道具。
通知する道具。

MCPは、AIエージェントにその道具を渡すための共通規格、と見ると分かりやすいです。

でも、便利さと危険さはセット

ここが一番大事だと思います。

MCPは便利です。
でも、便利さと危険さはセットです。

AIがファイルを読める。
DBを検索できる。
チケットを更新できる。
Slackに投稿できる。
メールを書ける。
外部サービスを操作できる。

ここまで行くと、もう単なるチャットではありません。

AIが業務環境に手を伸ばすことになります。

だから、MCP導入で大事なのは「つながった、便利になった」で終わらせないことです。

むしろ、つながるからこそ、考えることが増えます。

どの情報を見せるのか。
どの操作を許すのか。
読み取りだけなのか。
書き込みも許すのか。
外部送信は人間承認を挟むのか。
ログは残るのか。
誰が止められるのか。
本番環境に触れないようになっているのか。

ここを設計せずにMCPを入れるのは、かなり危ないと思います。

MCPは「土管」。だからこそ流すものに注意する

自分なりに言うと、MCPはかなり「土管」に近いです。

AIと外部ツールをつなぐ土管。

土管があると、いろいろなものを流せるようになります。
それは便利です。

でも、土管そのものが、

「これは流してよい情報です」
「これは流してはいけない情報です」
「この人にはここまで見せてよいです」
「この操作は危険なので止めます」

と、すべて判断してくれるわけではありません。

何を流すか。
どこまで流すか。
誰に流すか。
逆流しないようにするか。
外に漏れないようにするか。

そこは、土管の外側の設計が必要です。

MCPも同じです。

MCPは「つなぐ仕組み」として有用。
でも、細かい業務権限や安全柵は、元の仕組みやMCPサーバー側でちゃんと絞る必要がある。

ここを強く意識した方がいいと思います。

まずは読み取り中心が安全

MCPを使うなら、最初は読み取り中心が安全だと思います。

たとえば、

資料を読む。
ファイルを検索する。
カレンダーを確認する。
チケットの状態を見る。
社内Wikiを検索する。

このあたりです。

つまり、AIに「見る」ことを許す。

次の段階で、

下書きを作る。
更新案を作る。
Issue候補を作る。
返信案を作る。
PR案を作る。

ここまでは、まだ人間が確認しやすいです。

一方で、最初から、

メールを送る。
Slackに投稿する。
チケットを更新する。
DBを更新する。
ファイルを削除する。
本番環境を操作する。

こういうところまで許すのは、かなり慎重にした方がいいです。

AIに道具を渡すなら、最初は安全な道具から。

読み取り中心。
下書きまで。
人間承認あり。
ログあり。
削除なし。
本番操作なし。

このくらいから始めるのが現実的だと思います。

読み取り専用にするには、どこで絞るのか

ここで気になるのは、

「MCPを使えば、読み取り専用みたいな制御が自動でできるのか？」

という点です。

自分の理解では、ここもかなり重要です。

MCPそのものが、業務上の細かい権限制御を全部やってくれるわけではありません。

読み取り専用にしたいなら、基本的には、

MCPサーバー側で、読み取り専用の機能だけを公開する。
さらに、接続先の元システム側でも読み取り専用の権限にしておく。

という設計が必要になります。

たとえば、ファイルを扱うMCPサーバーなら、許可するものは、

  • ファイル一覧を見る

  • ファイルを読む

  • ファイルを検索する

くらいにする。

逆に、

  • ファイルを書く

  • ファイルを削除する

  • ファイルを移動する

  • フォルダ構成を変更する

といった機能は、そもそもMCPサーバーから公開しない。

DBを扱うなら、

  • SELECTだけ許可する

  • 参照用ビューだけ見せる

  • 読み取り専用ユーザーで接続する

といった形にする。

逆に、

  • INSERT

  • UPDATE

  • DELETE

  • DROP

  • 権限変更

  • 管理系操作

はできないようにしておく。

S3なら、読み取り用のIAM権限だけを渡す。
GitHubなら、read権限だけにする。
社内Wikiなら、閲覧可能な範囲だけを見せる。

つまり、読み取り専用にするには、MCPだけでなく、

  • 接続先システム側の権限

  • MCPサーバーが公開する機能

  • AIホスト側の承認設定や利用制限

を組み合わせて絞る必要があります。

ここを雑にすると、

「読み取りだけのつもりだったのに、実は更新系のツールもAIから呼べる状態だった」

ということが起きかねません。

なので、MCPを導入するときは、

AIに何を見せるのか。
AIに何を操作させるのか。
MCPサーバーがどのtoolを公開しているのか。
接続先の権限は本当に読み取り専用になっているのか。

を確認する必要があります。

MCPは便利な接続口です。

でも、安全に使うには、接続口の先にある権限をちゃんと絞る必要がある。

ここが導入時のかなり大事なポイントだと思います。

エージェント化との関係

前回のエージェント化の話ともつながります。

エージェント化は、AIに仕事の一部を進めてもらうことでした。

でも、仕事を進めるには材料と道具が必要です。

会議ログを見る。
資料を見る。
メールを見る。
カレンダーを見る。
チケットを見る。
必要なら下書きを作る。

MCPは、その材料や道具への接続口になります。

つまり、

エージェント化が「AIに仕事を任せる話」なら、
MCPは「AIが仕事に必要な道具へつながる話」

です。

ただし、道具を持たせるほど、権限管理と安全柵が重要になります。

AIに道具を持たせる。
でも、何でも持たせてよいわけではない。

ここを間違えると、エージェント化どころか、事故の入口になりかねません。

今日の理解

MCPは、AIが外部ツールやデータに接続するための共通規格。

AIを孤立したチャットから、仕事の環境につなげるための仕組みです。

ただし、MCPは万能な安全装置ではありません。

MCPは「つなぐ仕組み」です。
だからこそ、何をつなぐのか、どこまで使わせるのかを慎重に設計する必要があります。

AIが見られる情報が増える。
AIが使える道具が増える。
AIができる操作が増える。

それは便利です。

でも、便利さと危険さはセットです。

まずは読み取り専用から。
必要な範囲だけ。
書き込みや送信は人間承認。
ログを残す。
削除はさせない。
本番環境には触らせない。

MCPは、AIに道具を渡すための規格。
でも、どの道具を渡すかを決めるのは人間。

そして、その道具をどこまで使わせるかは、MCP任せではなく、MCPサーバーと元の仕組みで絞る必要がある。

今日の理解としては、そんな感じです。

いいなと思ったら応援しよう！