AI導入戦略

MCPを実運用して分かったこと｜5つ繋いで3つが落ちている

MCP AIエージェント 運用 自動化 生成AI
生成AIを社内システムに繋ぐ規格として、MCPの採用が進んでいる。編集部も5つのサーバーを繋いでいるが、この記事を書いている時点で3つが接続に失敗している。繋ぐこと自体は簡単で、難しいのは繋ぎ続けることだった。

目次

この記事の立ち位置

生成AIを社内のシステムやデータに繋ぐ規格として、Model Context Protocolの採用が進んでいる。接続先ごとに個別の実装を書く必要がなくなり、対応しているAI側から同じ形で使える。

導入の記事は増えたが、運用した記録は少ない。

編集部は5つのサーバーを接続している。この記事を書いている時点で、そのうち3つが接続に失敗している。

この記事は、その状態から見える運用上の実際をまとめたものである。

結論を先に書く。繋ぐこと自体は簡単だった。難しいのは繋ぎ続けることだった。

いま3つが落ちている

接続している5つの用途と、現在の状態である。

用途 状態
ブラウザの操作 正常
デザインの生成 正常
記事の投稿 接続が閉じられた
会計サービスの参照 接続が閉じられた
社内データの参照 認証が拒否された（401）

さらに、別の2つのサービスについては、認証の手続きが対話的にしか行えないため、自動実行の環境からは使えない状態にある。

気づいたきっかけ

起動時に、接続に失敗したサーバーの一覧が通知される。この通知がなければ、使おうとして初めて気づくことになる。

逆に言えば、通知の仕組みがある環境だから気づけている。 仕組みがなければ、落ちたまま運用が続く。

いつから落ちていたかは分からない

正直に書くと、3つがいつから落ちているかを編集部は把握していない。

接続の失敗は起動のたびに通知されるが、その通知は記録として蓄積していない。「今日は落ちている」は分かるが、「先週も落ちていたか」は分からない。

これは計測の設計の問題である。状態の通知と、状態の記録は別の仕組みが要る。 通知だけがあると、その瞬間の状態しか残らない。

同じ問題を、編集部は別の場面でも踏んでいる。動画生成の仕組みで工程ごとの所要時間を記録していなかったため、後から出せなくなった。測っていなければ、その時点のデータは存在しない。

落ちている状態を許容していた

もう1つ書いておくべきことがある。3つ落ちていても、日々の作業は回っている。

回っているので、直す優先度が上がらない。使わないものが落ちていても困らないという状態は、裏を返せば繋ぐ必要がなかった可能性を示している。

繋いだサーバーが使われているかを記録していないため、これも判断できない。

落ちる理由は2種類ある

観測した失敗を分類すると、2つに分かれる。

接続が閉じられた

サーバー側のプロセスが終了した、あるいは起動に失敗した状態である。

原因として起こり得るのは、依存しているソフトウェアの更新、実行環境のパスの変更、サーバー側の仕様変更である。

編集部の別の運用でも、コマンドへのパスが環境の変更で通らなくなり、定期実行が毎日失敗していたことがある。同じ種類の問題である。

認証が拒否された

接続はできるが、認証情報が受け付けられない状態である。返ってきたのは401だった。

原因として起こり得るのは、トークンの期限切れ、権限の変更、認証方式の変更である。

どちらも静かに起きる

共通するのは、使おうとするまで分からないことである。前日まで動いていたものが、今日動かない。

変更したのは自分ではない場合が多い。 サーバー側が更新された、トークンが期限を迎えた、実行環境が更新された。

繋ぐのは簡単、続けるのが難しい

導入時の作業と、運用時の作業を比べる。

導入時

設定ファイルに、サーバーの起動方法か接続先を書く。認証情報を設定する。接続を確認する。

難しくない。 多くの場合、数十分で終わる。

運用時

接続が維持されているかを定期的に確認する。 落ちていても、使わない日は気づかない。

認証情報の期限を管理する。 期限があるトークンは、切れる前に更新する必要がある。

サーバー側の更新に追随する。 仕様が変わると、それまでの使い方が通らなくなる。

どのサーバーが何をできるかを把握しておく。 数が増えると、把握が追いつかなくなる。

費用の構造が似ている

前述の構造は、テスト自動化の費用と同じ形をしている。書く時間ではなく、維持する時間にかかる。

導入の判断をするとき、維持の費用を見積もりに入れる。 入れていないと、動かなくなったときに誰も直さない。

対話用と自動処理用は分ける

編集部の設計として、明確に分けている点がある。

対話しながら作業する場面

人がAIと対話しながら作業する場面では、MCP経由でツールを使う。ブラウザを開いて画面を確認する、デザインを生成するといった用途である。

この場面では、接続が落ちていれば人が気づいて対処できる。

定期実行する処理

定期実行する処理では、MCP経由ではなく、同じ機能のライブラリを直接呼んでいる。

理由は再現性である。定期実行は、人が見ていない時間に走る。 接続の状態に左右される構成にすると、失敗の原因が増える。

この分け方の効果

現在3つのサーバーが落ちているが、定期実行している処理は影響を受けていない。 分けていなければ、止まっていた。

同じ機能でも経路が違う

具体例を挙げる。

編集部では、ブラウザの自動操作を2つの経路で使っている。

対話中はMCP経由。 画面を見ながら、その場で操作する。

定期実行はライブラリを直接。 検査のスクリプトから、Pythonのライブラリを直接呼ぶ。

同じ道具に見えるが別物である

どちらもブラウザを動かすが、依存している経路が違う。 MCP側が落ちても、スクリプト側は動く。

使い分けの基準

場面 経路
人が見ている MCP
人が見ていない ライブラリを直接
探索的な作業 MCP
手順が確定している ライブラリを直接
失敗を人が拾える MCP
失敗を機械で扱う必要がある ライブラリを直接

重複は許容する

同じ機能を2つの経路で持つのは、一見すると無駄である。しかし、依存を減らすほうが運用は安定する。

MCPは接続先を増やすための規格であり、すべてをMCPに寄せるための規格ではない。

MCPの前と後で何が変わったか

規格そのものの説明は公式にあるので、ここでは運用の観点で何が変わったかを書く。

以前：接続先ごとに実装が必要だった

生成AIから外部のシステムを使うには、呼び出せる関数の一覧を定義し、実行する処理を書く必要があった。

この定義は、使うAIごとに書き方が違う。同じ機能を、AIを変えるたびに書き直すことになる。

社内で複数のAIを試している場合、この作業が重複する。

以後：サーバーを1つ用意すればよい

規格に沿ったサーバーを1つ用意すれば、対応しているAI側から同じ形で使える。

社内システムを繋ぐ場合、この違いは大きい。AIを乗り換えても、繋ぎ込みの実装は残る。

ただし、規格は接続の形だけを決める

何を繋ぐか、どの権限を渡すか、落ちたときにどうするかは、規格の外側にある。

導入の記事は接続の方法を説明するが、運用の負担はここから先に発生する。 本記事はその部分を扱っている。

もう1つの効果

規格に沿っていると、サーバー側の実装を他の人が書いたものに差し替えられる。

サービスの提供元が公式のサーバーを出したら、自前の実装をやめてそちらに移れる。保守の負担が減る。

社内システムに繋ぐときの現実

外部サービスに繋ぐ話と、社内システムに繋ぐ話は難しさが違う。

APIが無いことが多い

社内システムは、画面から使う前提で作られていることがある。外部から呼べる仕組みが無い。

この場合、選択肢は3つある。APIを作る、データベースを直接参照する、画面を自動操作する。

それぞれの問題

APIを作るのが本筋だが、既存システムに手を入れる必要があり、時間がかかる。

データベースを直接参照するのは手軽だが、アプリケーション側の整合性の処理を迂回する。 読み取りだけなら比較的安全だが、書き込みは危険である。

画面を自動操作するのは既存システムに手を入れずに済むが、画面が変わると壊れる。 編集部の別の事例では、ボタンの表示文字が変わっただけで自動化が16件失敗した。

その16件の内訳と、同じ時期に見逃していた製品側の実害9件はE2Eテストが16件落ちたに書いた。

読み取りから始める

いずれの方法でも、最初は読み取りに限る。

生成AIが社内システムに書き込む構成は、間違いが起きたときの影響が大きい。書き込みを許すのは、読み取りで運用が安定してからでよい。

データの整合性を誰が担保するか

システムに書き込む処理を生成AI経由にする場合、入力の検証をどこで行うかを決める必要がある。

生成AIの出力を検証せずにそのまま書き込む構成は、壊れたデータが入る経路になる。 検証はサーバー側に置く。

複数人で使うときの設計

1人で使う場合と、チームで使う場合は別の設計が要る。

認証情報を共有しない

1つの認証情報を全員で使うと、誰が何をしたか分からなくなる。

操作の記録が残っても、実行者が全員同じでは意味がない。可能なら、利用者ごとに認証情報を分ける。

権限の差をどう扱うか

社内システムには、役割ごとの権限がある。MCPサーバーがその差を反映していないと、権限の低い人が高い操作をできてしまう。

サーバーが利用者を識別できない構成では、サーバー自体を役割ごとに分けるという対処がある。

設定の配布

各自の環境に設定を入れる必要がある。手順書を配ると、そのとおりに設定されない。

設定ファイルの雛形を用意し、認証情報だけを各自が入れる形にすると、ばらつきが減る。

落ちたときの連絡

誰かの環境で落ちているのか、全員で落ちているのかを切り分ける必要がある。

サーバー側の問題なら全員に影響し、設定の問題なら1人だけである。この切り分けを最初に行う。

費用と負荷の構造

見落としやすい点を書いておく。

道具の定義そのものに費用がかかる

接続したサーバーが持つ機能の一覧は、やり取りのたびに生成AIへ渡される。

つまり、サーバーを増やすほど、毎回の費用が上がる。 使っていない機能の定義も、一覧に含まれていれば渡される。

実測はしていないが、構造は明らか

編集部はこの部分の費用を切り分けて実測していない。ただし、渡す情報が増えれば費用が増えるという構造は明らかである。

前述の「作業に必要なものだけを繋ぐ」は、精度の観点だけでなく、費用の観点でも効く。

応答の量にも注意する

サーバーが返す情報が大きいと、それも費用になる。一覧を丸ごと返すような設計は避け、件数の上限を設ける。

社内システムから数千件を取得して全部返す実装は、費用と精度の両方を悪化させる。

何を測るべきか

導入の効果を判断するなら、業務1件あたりの費用と時間で見る。

「MCPを導入した」ことではなく、その業務が以前より速く終わっているかを測る。測っていなければ、続ける理由も止める理由も出せない。

権限の設計

MCPサーバーは、生成AIに対して外部のシステムへの操作権限を渡す仕組みである。ここが最も注意を要する。

渡す権限を最小限にする

読み取りだけで足りるなら、書き込みの権限を渡さない。

会計サービスや顧客データの参照では、この判断が効く。参照だけができればよい用途に、更新の権限まで渡す必要はない。

対象の範囲を絞る

特定のデータだけで足りるなら、全体へのアクセスを渡さない。

サーバーによっては、範囲の指定ができる。できない場合は、そのサーバーを使わないか、専用のアカウントを作って権限を絞る。

誰が保守しているかを確認する

サーバーの実装は、サービスの提供元が公開している場合と、第三者が作っている場合がある。

第三者の実装を使う場合、何をしているかを確認する。 公式の参照実装と比べて、余計な通信をしていないか。

操作の記録を残す

生成AIが実行した操作の記録を残す。後から「何をしたか」を辿れるようにする。

特に、書き込みの権限を渡している場合は必須である。

認証情報の置き場所

運用で最も事故が起きやすい箇所である。

設定ファイルに平文で置かない

MCPの設定は、多くの場合ファイルに書く。そのファイルがバージョン管理に入ると、認証情報が記録に残る。

一度記録に入った情報は、後から消しても履歴に残る。

編集部の運用

認証情報は、バージョン管理の対象外のディレクトリに置き、読み取り権限を所有者のみに制限している。設定ファイルからは、その場所を参照する形にする。

期限のあるものは期限を記録する

トークンに期限がある場合、いつ切れるかを別に記録しておく。 切れてから気づくと、その時点で作業が止まる。

編集部が現在踏んでいる401は、この種の問題である可能性が高い。

権限の変更は通知されない

外部サービス側で権限が変更されても、こちらには通知されない。 使おうとして初めて分かる。

サービス側の管理画面を定期的に確認する運用が要る。

接続の単位をどこに置くか

設定の置き場所には選択肢がある。

全体に対して設定する

どの作業でも同じサーバーが使える。設定が1か所で済む。

一方で、その作業に不要なサーバーまで接続される。

作業ごとに設定する

その作業に必要なサーバーだけを接続する。権限の範囲を作業ごとに絞れる。

設定が増えるため、管理の手間がかかる。

編集部の構成

全体に対して設定し、作業ごとの追加設定は持っていない。

これは意図した設計というより、そうなっているという状態である。権限を絞る観点では、作業ごとに設定するほうが望ましい。

扱うデータの機微さが高い作業が増えたら、分ける必要がある。

失敗したときの扱いを決める

接続が落ちることを前提に設計する。

起動時に確認する

作業を始める時点で、接続の状態が分かる仕組みがあるとよい。編集部の環境では、起動時に失敗したサーバーが通知される。

この通知がないと、使おうとするまで分からない。

落ちていても作業が続けられるか

ある機能が使えないだけなのか、作業自体が止まるのか。 前者なら代替の手段で進められる。

重要な処理をMCP経由に依存させる場合、代替の経路を用意しておく。

失敗を静かに握りつぶさない

前述の別の事例で、値が無いときに黙って機能を無効化する設計が無音の故障を作った例がある。

MCPでも同じことが起こり得る。接続に失敗したときに、何もせず続行する実装は危険である。 少なくともログに残す。

無音で壊れる形の実例はHTTP 200なのに壊れているにまとめている。

再接続の手順を書いておく

落ちたときに何をすればよいかを、手順として残す。そのときに調べ始めると時間がかかる。

道具が増えすぎる問題

接続するサーバーが増えると、別の問題が出る。

選択肢が増えると精度が落ちる

生成AIは、使える道具の一覧から適切なものを選ぶ。一覧が長くなるほど、選択の精度が落ちる。

これは、前述の「背景知識を12項目追加したら評価が33ポイント下がった」という結果と同じ構造である。渡せる情報量には上限があり、追加は押し出しである。

この実測の詳細はプロンプトは足しても良くならないにある。

作業に必要なものだけを繋ぐ

対処は単純で、その作業に必要なサーバーだけを有効にする。 全部を常時接続しておく必要はない。

前述の「作業ごとに設定する」構成が効くのは、権限の観点だけでなく、この観点でもある。

似た道具を複数持たない

同じことができるサーバーを複数繋ぐと、どちらを使うかの判断が入る。 判断が入る箇所は、間違いが起きる箇所である。

何をMCPに載せるか

繋ぐ価値があるものと、無いものを分ける。

載せる価値があるもの

人が手で見に行っているもの。 管理画面を開いて数字を確認する、といった作業。

複数の場所にまたがるもの。 複数のシステムから情報を集めて突き合わせる作業。

探索的なもの。 何を調べればよいかが事前に決まっていない作業。

載せる価値が薄いもの

手順が確定している定期処理。 ライブラリを直接呼ぶほうが安定する。

大量のデータを扱うもの。 やり取りする情報量に制約があるため、大量のデータの受け渡しには向かない。

失敗が許されないもの。 接続の状態に依存する構成は、確実性を要する処理には向かない。

判断の軸

人が見ているか、手順が決まっているか。 この2つで分けると、おおむね正しく振り分けられる。

MCPを使わない選択肢

繋ぐ前に、繋がないで済まないかを確かめる。

手作業の頻度で判断する

その作業を月に何回やっているか。年に数回なら、手でやるほうが安い。

接続の維持、認証の管理、落ちたときの対応。これらの費用が、削減できる時間を上回る場合がある。

ファイルの受け渡しで足りる場合

データを参照したいだけなら、定期的に書き出したファイルを読ませる方法がある。

接続を維持する必要がなく、外部への通信も発生しない。機微なデータを扱う場合は、こちらのほうが管理しやすい。

欠点は、鮮度が落ちることと、書き出しの仕組みが別に要ることである。

関数の定義を直接書く方法

MCPを使わず、使うAIに対して直接、呼び出せる関数を定義する方法もある。

繋ぐ先が1つで、使うAIも1つに決まっているなら、こちらのほうが単純である。規格の利点は、接続先とAIの組み合わせが増えたときに効く。

既存の自動化で足りる場合

定期実行のスクリプトで済む処理を、わざわざ生成AI経由にする必要はない。

判断が入らない処理は、判断が入らない仕組みで動かす。 生成AIを挟むと、揺らぎと費用が入る。

判断の目安

その作業に「毎回違う判断」が入るかで分ける。入るならMCPを含む生成AIの経路、入らないなら従来の自動化でよい。

編集部の定期実行が MCP に依存していないのは、この基準による。

導入の効果をどう判断するか

繋いだ後、続けるか止めるかを判断する材料が要る。

「便利になった」では判断できない

MCPを繋ぐと、できることが増える。増えたこと自体は、効果ではない。

判断に使うのは、その業務が以前より速く終わっているか、間違いが減っているかである。

比較の基準を先に取る

繋ぐ前に、対象の業務にかかっている時間を測る。繋いだ後に測っても、比較対象がない。

編集部は、動画生成の仕組みで工程ごとの所要時間を記録していなかったため、後から出せなくなった。 同じ失敗を繰り返さないための原則である。

測る単位

業務1件あたりで測る。月の総額や総時間では、量の変動に埋もれる。

議事録1本、問い合わせ1件、報告書1通。この単位なら、前後の比較が成立する。

間違いの数も測る

速くなっても間違いが増えたなら、差し引きで損をしている可能性がある。

やり直しの回数を数える。生成AIを使う作業では、ここが効果を決めることが多い。

止める判断も用意する

導入したものを止める判断は、しにくい。繋いだサーバーが使われなくなっても、設定は残る。

残った設定は、費用と保守の対象として残り続ける。定期的に、使っていないサーバーを外す。

使用の記録を取る

どのサーバーが、どのくらい使われているか。記録がないと、外してよいか判断できない。

編集部の環境では、接続の失敗は通知されるが、使用頻度は記録していない。 これは改善すべき点として記録しておく。

よくある誤解

「MCPを入れれば自動化できる」

接続することと、業務が回ることは別である。繋いだ後の運用が本体である。

「規格に沿っていれば安全」

規格は接続の形を決めるもので、権限の設計や認証情報の扱いは利用者の責任である。

「たくさん繋ぐほど便利」

道具が増えると選択の精度が落ち、毎回の費用も上がる。作業に必要なものだけを繋ぐ。

「一度繋げば終わり」

接続は落ちる。認証は期限を迎える。サーバーは更新される。維持の作業が続く。

「公式のサーバーだから安心」

公式であっても、渡す権限の範囲は自分で決める必要がある。 既定の設定が最小権限とは限らない。

導入の順序

1. 読み取りだけのサーバーから始める

書き込みの権限を渡す前に、参照だけで効果があるかを確かめる。

2. 1つだけ繋ぐ

複数を同時に繋ぐと、問題が起きたときの切り分けができない。

3. 認証情報の置き場所を先に決める

動かしてから直すのは難しい。 最初に、バージョン管理に入らない場所を決める。

4. 落ちたときの手順を書く

繋いだ直後に書く。動いている間は書かない。

5. 定期的に接続を確認する

使わない期間があると、落ちていても気づかない。

6. 自動処理には使わない

少なくとも最初は、対話的な用途に限る。自動処理に広げるのは、運用が安定してからでよい。

運用で決めておくこと

誰が保守するか

接続が落ちたときに直す人を決める。決めていないと、落ちたまま残る。

どの権限を渡しているか

サーバーごとに、渡している権限を一覧にする。増えると把握できなくなる。

操作の記録をどこに残すか

特に書き込みの権限を渡している場合。

認証情報の期限

期限のあるものを一覧にし、更新の時期を決める。

外部に出る情報の範囲

MCPサーバーが外部のサービスに接続する場合、どの情報がどこへ出るかを確認する。社内のデータを扱うサーバーが、外部に通信していないか。

まとめ

MCPを実運用した記録である。

5つ繋いで、この記事を書いている時点で3つが落ちている。 2つは接続が閉じられ、1つは認証が拒否された。さらに2つのサービスは、認証の手続きが対話的にしか行えず、自動実行の環境からは使えない。

繋ぐのは簡単、続けるのが難しい。 導入は数十分で終わるが、接続の維持、認証情報の期限管理、サーバー側の更新への追随が続く。

対話用と自動処理用を分けている。 定期実行する処理は、MCP経由ではなくライブラリを直接呼ぶ。この分け方のおかげで、3つ落ちている現在も定期実行は影響を受けていない。

渡す権限は最小限にする。 読み取りで足りるなら書き込みを渡さない。第三者の実装を使う場合は、何をしているかを確認する。

道具が増えると選択の精度が落ちる。 背景知識を増やしたときと同じ構造である。作業に必要なものだけを繋ぐ。

失敗を静かに握りつぶさない。 接続に失敗したときに何もせず続行する実装は、無音の故障を作る。

明日から試せる3つ

1つ目は、いま接続しているサーバーの一覧と、それぞれに渡している権限を書き出すことである。10分で終わる。書き出せないサーバーがあれば、それは把握できていない。

2つ目は、認証情報がバージョン管理の対象に入っていないかを確認することである。入っていたら、履歴からも消す必要がある。

3つ目は、定期実行している処理がMCPに依存していないかを確認することである。依存しているなら、接続が落ちたときに止まる。

編集部では、AI導入の支援と、こうした接続・運用の設計も行っている。繋いでみたが運用が続かない、という段階の相談については、サービス案内を参照してほしい。

参考にした一次資料

よくある質問

MCPとは何ですか。

生成AIを外部のツールやデータに接続するための共通の規格です。従来は接続先ごとに個別の実装が必要でしたが、規格に沿ったサーバーを用意すれば、対応している複数のAI側から同じように使えます。編集部では、ブラウザ操作、記事の投稿、会計サービスの参照、デザインの生成といった用途で接続しています。

MCPを導入すれば業務が自動化できますか。

接続することと、業務が回ることは別です。編集部は5つのサーバーを接続していますが、この記事を書いている時点で3つが接続に失敗しています。原因は接続が閉じたことと、認証情報が受け付けられなくなったことです。繋ぐこと自体は難しくなく、運用の負担は繋ぎ続けるほうにあります。

接続が落ちたらどうなりますか。

そのツールが使えなくなります。編集部の環境では、起動時に接続の失敗が通知されるため、落ちていること自体は分かります。ただし作業の途中で落ちた場合、失敗した理由が分かりにくい形で現れることがあります。重要な処理をMCP経由に依存させる場合は、失敗したときの扱いを決めておく必要があります。

自動処理にもMCPを使うべきですか。

用途によります。編集部では、対話しながら作業する場面ではMCP経由でブラウザを操作しますが、定期実行する処理では同じ機能のライブラリを直接呼んでいます。自動処理は再現性が重要で、接続の状態に左右されない構成のほうが安定します。両者は別の経路として設計しています。

セキュリティ上の注意点はありますか。

MCPサーバーは、生成AIに対して外部のシステムへの操作権限を渡す仕組みです。渡す権限の範囲を、必要最小限に絞ってください。読み取りだけで足りるなら書き込みの権限を渡さない、特定のデータだけで足りるなら全体へのアクセスを渡さない、という設計にします。認証情報の保管場所も、設定ファイルに平文で置かない形にしてください。

接続できるサーバーはどこで探せますか。

公式に、規格の仕様と、参照実装となるサーバー群が公開されています。加えて、各サービスの提供元が自前でサーバーを公開している場合があります。導入の前に、そのサーバーがどの権限を要求するかと、誰が保守しているかを確認してください。

関連する取り組み

CONNECTED SERIES
AIで投資の壁を越える
18 本の実装記録。AI 投資の「予測不能」と言われる 9 つの壁を、コードと実データで検証した連載。
note で読む →
CONSULTING
AI導入の無料相談
ALLFORCES が、本記事のような失敗パターンを回避する AI 導入支援を提供しています。まずは課題を聞かせてください。
問い合わせる →