こんにちは。ITコンサルティングと受託開発、それにプログラミングスクールをやっている会社の代表、沼田です。17人・フルリモートで、そのうち8人が高専卒の会社をやっています。
先月、中堅製造業のお客さんのところで、AIエージェントの話をしていたときのことです。「いまはMCPという規格が標準になっていて、AIから社内システムを触れるようになります」と説明したら、情シスの方が、少し困った顔でこう言いました。
「……MCP対応してるツールなんて、うちの現場には1つもないですよ」
その場で言葉に詰まりました。というより、彼が正しかった。今日は、この「標準規格の外側にいる会社」の話です。
標準化の恩恵が届く会社と、届かない会社
まず、MCPがどれだけ広がっているか。数字を並べると、SDKの月間ダウンロードは9,700万回、公式レジストリに登録された公開MCPサーバは1万件に迫り、ソフトウェア企業の41%が限定的な範囲を含めて本番運用に載せている（Stacklok「State of MCP in Software 2026」）。もう「流行っている」ではなく、事実上の標準です。AIエージェントが社内のツールを触るための、共通の差込口。それがMCPだと思ってもらえればいい。
ただ、この恩恵が届いているのは、どこか。GitHub、Slack、各種SaaS。もともとAPIが整っていて、モダンな側にいたツールです。MCP対応は、叩けるAPIがあって初めて成立します。つまり「まだ対応していない」のではなく、「対応する前提が揃っていない」システムが大量にある。
一方、うちのお客さんの現場にあるのは、生産管理、在庫、受発注。10年、15年動いてきた基幹システムです。当然、MCPには対応していません。経産省のレガシーシステムモダン化委員会の総括レポートでも、ユーザー企業の61%（大企業では74%）がレガシーを抱えていて、31%が「既存システムの複雑さ」をモダン化の壁に挙げている。設計書がない、作った人はもう辞めている。そういう箱です。
つまり、標準化が進めば進むほど、繋がる側と繋がらない側の分断が広がっている。「AIエージェントで業務が変わる」という話は本当ですが、それは繋がる側にいる会社の話であって、日本の中堅企業の現場の多くは、まだ標準規格の外側にいます。
全社基盤を作る前に、1本だけ架ける
ここで多くのプロジェクトが取る道は、2つです。ひとつは「基幹を刷新してから、AIを入れましょう」。もうひとつは「全社の連携基盤を作りましょう」。どちらも正論ですが、どちらも年単位・億単位になり、たいてい途中で止まります。
うちがやったのは、もっと小さいことでした。1業務・1テーブルだけを対象に、薄いアダプタを1本だけ架ける。
具体的には、在庫の照会だけ。「この品番、いまいくつある？」にAIが答えられる。それだけです。生産管理の全機能ではなく、受発注でもなく、在庫参照の1本。基幹システム側には一切手を入れず、参照用のビューを1つ切って、その上に薄いMCPサーバを立てただけ。工数は、大がかりな刷新に比べれば、比較になりません。
ポイントは、AIに"全部"を触らせないことです。全社基盤を作ろうとすると、「どのシステムを、どこまで、誰の権限で」を全部決める必要があり、その合意形成だけで半年溶けます。1業務なら、その場で決まる。
最初に決めるのは「渡さないデータ」
この設計で、僕らが最初に決めるのは、渡すデータではありません。渡さないデータです。
原価、仕入先ごとの単価、個人情報。これらは「今回は渡さない」と先に線を引く。そのうえで、残ったものだけをAIから見えるようにする。この順番を逆にすると、「何を出していいか」の議論が延々と続きます。出さないものを先に決めると、残りは自動的に決まる。
そしてもう一つ、まず読み取り専用から始める。AIが在庫数を「書き換えられる」設計は、一段も二段も難しくなります。承認をどうするか、取り消せるか、誤発注の責任は誰か。全部ついてくる。だから最初は読むだけ。読むだけでも、現場の問い合わせ対応は目に見えて軽くなります。
読み取り専用にはもう一つ効能があって、「誰が、いつ、何を見たか」のログさえ残しておけば、後から範囲を広げる判断がしやすくなる。実際に使われた問い合わせの中身が、次に何を繋ぐべきかを教えてくれるからです。
繋ぎ方も、格好つける必要はありません。参照用のビューでいい。中間テーブルでいい。リアルタイムが要らない業務なら、夜間バッチで前日分をコピーしてくるだけでも足りる。前職のスタートアップITコンサルにいた頃、僕は「正しいアーキテクチャ」から入る癖がありました。でも独立して自分の会社で受託をやるようになって、現場が明日から使えるかどうかのほうが、はるかに重いと分かりました。24歳で起業して3期目（27歳）、この学びが一番効いています。
「正しい設計」より「明日動くもの」を選べるエンジニアへ
K.Platinumの受託は、こういう判断の連続です。標準規格の外側にあるシステムを前に、どこまで削って何を残すかを、お客さんと一緒に決めていく。年次や資格ではなく、その判断ができるかどうかで評価される環境です。興味を持っていただけたら、K.Platinumのエンジニア募集要項を覗いてみてください。
1本架かると、刷新の議論が具体になる
この在庫照会の1本が動き出したあと、面白いことが起きました。
現場から「じゃあ、受注残も見たい」「この画面、もう要らないかも」という声が出てきたんです。それまで「基幹刷新、どうしますかね……」と抽象的に止まっていた議論が、急に具体になった。AIから触れる範囲を1つ作ると、システムのどこに価値があって、どこが要らないかが、現場の言葉で出てくる。
刷新の要件定義を先にやろうとすると、たいてい「今あるものを全部残す」という結論になります。誰も捨てる判断ができないからです。でも、小さく繋いで実際に使ってみると、捨てられるものが見えてくる。1本のアダプタは、AI連携の入口であると同時に、刷新の議論を動かすための道具でもありました。
まとめ
MCPは標準になりました。でも、標準は「繋がる側」がいて初めて意味を持つ。日本の中堅企業の基幹システムは、まだその外側にいます。
だから、全社基盤の前に1本だけ架ける。渡さないデータを先に決める。読み取り専用から始める。ビューでも夜間バッチでも構わない。もし今、「AIエージェントの話は分かるけど、うちのシステムは対応してないから関係ない」と思っているなら、それは半分だけ正しい。対応していないシステムに、こちらから差込口を1つ作ればいいだけの話です。
沼田海斗（ぬまた・かいと）
株式会社K.Platinum 代表。ITコンサルティングと受託開発、プログラミングスクールを手がける。17人・フルリモートの体制で、レガシーシステムを抱える企業のAI活用支援に取り組んでいる。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。