MCPとは何か｜中小企業の業務システムがAIと繋がる仕組み

「AIは賢いのに、うちの業務システムには触れない」問題

生成AIは確かに優秀です。ChatGPTやClaudeに質問すれば、ほんの数秒で鮮やかな文章が返ってきます。でも、あなたの会社の顧客データはAIから見えません。チャット履歴も見えません。タスク管理システムも、会計ソフトも、ホームページも——すべて暗黒です。

だから何が起きるか。あなたが人間として、AIと自社システムの間で「コピペ係」になります。顧客データをAIに貼り付けて→答えをもらって→自分で直接入力する。この往復が日中ずっと続きます。業務は変わらず、手間も減りません。

この壁を壊す仕組みが「MCP」です。MCPとは何かというと、AIと業務システムを直結させるための規格で、AIに自社データを読ませたり、システムを操作させたりするための技術的な約束事です。

僕は非エンジニアの経営コンサルタント（ハンズバリュー株式会社代表、ITコーディネータ）ですが、自社で12個のプロダクトにMCPサーバーを導入済みです。プログラミングはできません。それでもAIを使って自分で実装し、今も毎日運用しています。この記事は「専門家の解説」ではなく「非エンジニア経営者の実務家の実感」で書きます。

本記事は概念解説です。実装の詳細はChatwork MCPサーバーの実装記に、自社開発ツール全体の構成は19個の全体記に譲ります。

生成AIの業務活用が「文章生成止まり」になる構造

多くの中小企業は今、生成AIをこう使っています：

「この顧客データから提案文を作ってもらう」「メール本文をAIに磨いてもらう」「競合分析のレポートをAIに書かせる」

もちろん便利です。でも限界がすぐ来ます。

なぜなら、AIチャットは「答える」ことはできても、「読む」ことも「操作する」こともできないからです。

あなたの会社のチャット（Chatwork）には今、未読メッセージが何件あるか。タスク管理システムには今月やることが何項目あるか。ホームページへのアクセスは先月比で増えているか減っているか。AIに「教えて」と言っても、AIはそれらのシステムにアクセスして自分で確認することができません。AIが見えるのは、あなたが直接提供した情報だけです。

代わりに何が起きるか。あなたが「教える」係になる。

チャットのスクリーンショットをAIに見せて、「この中から対応が必要な案件を拾い出して」と言う。タスク管理システムを開いて、「来月までにやることはこの3つです」と自分で読み上げ、それをAIに説明する。アクセス解析画面を共有して、「この数字、何が原因だと思いますか」と相談する。その度に、あなたが間に入って「通訳」をする。データをAIに渡すため、答えをシステムに転記するため、この運搬作業が一日中続く。これでは業務の本質は何も変わりません。新しい道具（AI）が増えた分、あなたの手作業も増えている状態です。

もう1つの構造的な壁があります。中小企業でも、業務データは複数のシステムに分散しています。チャット、タスク管理、サイト監視、会計ソフト、分析ツール。それぞれが別々のシステムで、別々の場所に住んでいます。これまで、AIの前ではすべてが孤立していました。「AIに複数システムを横断させる入り口がない」——これが根本問題です。AIはいくら賢くても、システムの壁は越えられない。その壁を越えるための「共通の規格」がなかったのです。

MCPは、この構造的な問題を「規格」として解決する仕組みです。

MCPとは — AIと業務システムをつなぐ「共通の差し込み口」

MCPは「Model Context Protocol」の略。日本語で説明すれば、AIと外部システムをつなぐための共通規格です。

イメージとしてはUSBポート。かつて、電子機器の接続は機器ごとにバラバラでした。スマートフォンはiPhone用の専用ケーブル、AndroidはMicro USB、別のメーカーはまた別の形——機器の種類だけプラグインの形も違う。でも規格が統一されたおかげで、今はすべての機器が同じUSB-Cの差し込み口で繋がります。形が統一されたから、1本のケーブルが複数の機器で使える。その簡潔さと便利さが、規格の力です。

MCPもそれと全く同じ仕組みです。これまで、AIと業務システムを繋ごうとするたびに、システムごとに専用の「つなぎ方」を一から作っていました。ChatworkならChatwork向けの接続、タスク管理なら別の接続——毎回新しい道具が必要です。MCPは、この繰り返しを終わらせます。「AIと業務システムをつなぐための共通規格」として、どのシステムにも同じ方式で接続できるようにしました。

では、その構成がどうなっているのか。MCPとは、実は3段階の構造になっています：

• 第1段：AIアシスタント（Claude等の生成AI）
• 第2段：MCPサーバー（AIが使える「道具」の束を定義したプログラム）
• 第3段：業務システムのAPI（システム同士がやり取りするための窓口。Chatwork、タスク管理、会計ソフト等、あなたの会社が日々使っているシステム群の入り口です）

ここが重要な理解ポイントです。AIは直接、業務システムを触りません。その代わり、MCPサーバーが「あなたはこれこれこんな操作ができますよ」と定義した道具だけを使います。MCPサーバーが定義していない操作は、AIにとって存在しない操作と同じです。

ここが最も重要な設計思想です。AIは何でもできる自由な手ではなく、「許可制の手足」です。この点が、経営者にとって最大の安心材料になります。

「チャットの未読メッセージを全部見てもらう」という操作を例にとります。MCPサーバーが「未読サマリーを取得する」というツールを定義していれば、「OK、それはできます」とAIは実行します。一方で「給与データベースを直接編集してもらう」という指示には、「NO、その操作は許可制の手足に含まれていないから、私はできません」と返します。この拒否は、AIの能力不足ではなく、「そもそもそのツールが存在しない」という設計の結果です。

なぜこんな制限が必要か。AIは優秀であるほど「任せたい」という誘惑が増えます。その一方で、給与を勝手に変更されたら、経営管理データを削除されたら——と考えると、安全性との両立が不可欠です。MCPの設計は、その懸念をシステムレベルで解決します。危険な操作は、そもそもツールとして繋がない。人間が「どこまで許すか」を先に決めておくから、AIは能力の限界内でしか動けない。これは、従業員に職務権限を設定するのと、全く同じ発想です。

うちでは、この仕組みを使って、毎朝の横断報告や議事録の自動カード化を回しています。次のセクションで、その実物を見てもらいます。

MCPサーバーの中身 — 「ツール」の実物を見る

「MCPサーバー」という言葉だけ聞くと、大がかりなシステム開発を想像するかもしれません。サーバールームにラックが並んで、エンジニアが何人も張り付いて——そういう風景です。

実物は、まったく違います。

うちで本番運用しているChatwork用のMCPサーバーは、1ファイル・全318行・9ツール構成です（wc -l実測・2026-07-20時点）。318行というのは、プログラムとしてはかなり小さい部類です。A4に印刷すれば数枚に収まる。この数枚の紙が、AIとChatworkをつないでいます。

抽象論で終わらせたくないので、その中から「ツール」の定義を1本、そのまま見てもらいます。毎朝、AIがChatworkの未読を確認するときに使っている道具です。

// 未読サマリー（おはようプロトコル用）
server.tool(
  "unread_summary",
  "未読メッセージのサマリーを取得（おはようプロトコル用）",
  {},
  async () => {
    const rooms = await chatworkAPI("/rooms");
    const unread = rooms.filter((r) => r.unread_num > 0 || r.mention_num > 0);
    if (unread.length === 0) {
      return { content: [{ type: "text", text: "Chatwork: 未読なし" }] };
    }
    const summary = unread.map(
      (r) => `- ${r.name}: 未読${r.unread_num}件`
    );
    return { content: [{ type: "text", text: `Chatwork未読:\n${summary.join("\n")}` }] };
  }
);

プログラムが読めなくても大丈夫です。構造は3手しかありません。

1手目は、ツールの名前と説明文です。冒頭の “unread_summary” が名前、その次の行が説明文です。

未読メッセージのサマリーを取得（おはようプロトコル用）

ここが肝心な部分で、AIはツールの説明文を読んで、どの道具を使うかを自分で選びます。人間が「このボタンを押せ」と操作手順を教え込むのではなく、AIが道具箱のラベルを読んで、目的に合う道具を自分で取り出す。だから説明文は、日本語で普通に書けばよいのです。

2手目は、処理の中身です。ChatworkのAPIを呼び出して、部屋の一覧を取り、未読のある部屋だけを絞り込んで集計しています。

3手目は、結果をAIに返す部分です。「Chatwork: 未読なし」あるいは「どの部屋に未読が何件」というテキストを渡すと、AIはそれを読んで朝の報告に組み立てます。

実装には公式SDK @modelcontextprotocol/sdk を使用しています（バージョン^1.12.1）。土台は公式が用意してくれているので、自社で書くのは「AIにどんな道具を持たせるか」の部分だけです。

接続方式にも軽く触れておきます。接続方式には stdio（標準入出力・手元のPCでAIと直結）と HTTP（サーバー上で常時稼働）があり、うちではChatwork MCP=stdio、政府統計取得MCP=HTTPと両方式を運用しています。最初の1本ならstdioで十分です。ここは深入りせず、実装の詳しい手順はChatwork MCPサーバーの実装記に譲ります。

MCPで会社はどう変わるか — 12サーバー運用の実務風景

規格の説明はここまでにして、導入後の実務風景をお見せします。

うちの朝は、AIの横断報告から始まります。朝、僕が出勤すると、AIがチャット未読・約100社のサイト監視・タスクを横断で確認して、一本の報告書として渡してくれます。その報告を読むだけで、会社全体のその日の状況が把握できる。僕がやることは、その報告を読んで「ここに対応して」「あれ、確認して」と指示を出すことだけです。従来なら、Chatworkを開いて未読を数え、監視ダッシュボードを開いてアラートを確かめ、タスク管理を開いて今日の期限を拾う——複数の画面を行ったり来たりしていたこの作業が、丸ごと消えました。AIが代わりにやってくれます。

議事録の処理も根本的に変わりました。2026年4月、タスク管理システム（つなぐKanban）にMCPサーバーを自社実装し、会議後に議事録を処理するだけで宿題が自動でカード化されるようにしました。会議の中で「来週までに見積もりを出す」と決まれば、その議事録をシステムに渡すだけでタスク管理に新しいカードが立ちます。従来は、会議後に人間が「誰が何をいつまでに」を手で読み取って、カードを作成していました。その転記作業が、工程ごと消えるということです。

日常の操作も劇的に変わりました。AIエージェントから「カードを作って」「期限切れを教えて」と、自然言語でシステムを操作できます。管理画面の使い方を一から覚える必要もありません。日本語で頼めば、システムが動く。これまでとは全く異なるインタフェースです。

なぜこんなことが可能になったのか。従来のシステム連携との根本的な前提の違いを、僕はこう整理しています。

既存SaaSのAPIは「人間がプログラムを書いて呼び出す」前提で設計されている。MCPサーバーは「AIエージェントが自然言語の指示を受けて呼び出す」前提で設計される。

これまで、システム連携は「プログラムを書ける人」の領域でした。経営者や一般社員の視点では、システムはツール提供者が作った「完成品」で、その使い方は決まっていました。MCPは、その概念を逆転させます。入り口を「日本語で指示できる人」まで広げるのです。専任のIT部門を持たない中小企業にとって、この差は決定的です。

現在うちでは、12プロダクト・計約110ツールをMCP経由でAIから操作できます。1本318行の小さなサーバーの積み重ねが、会社の業務システム全体をAIの手の届く場所に変えました。どんな道具を積み上げてきたか、その全体像はAI社内ツールの棚卸し記事にまとめています。

MCPの誤解と注意点 — 「繋げば安心」ではない

ここまで読むと、「MCPを入れればAIが何でもやってくれる」と思われるかもしれません。それは誤解です。

実際は逆で、AIはツールとして定義した操作しかできません。MCPサーバーという「道具箱」に入れていない道具は、AIにとって存在しないのと同じです。AIに「給与を編集しろ」と指示しても、そのツールが道具箱に入っていなければ、AIは「できません」と返します。裏返せば、「何をツールにするか」の設計が全てを決めるのです。MCPの導入とは、プログラムを書く行為ではなく、「AIに何を許すか、何を禁止するか」を先に決めることだと考えてください。

だから注意点の第一は、権限設計です。危険な操作は、そもそもツールとして繋がない。うちでは給与・勤怠系システムのMCPは読み取り専用を原則としています。AIが給与データを「見る」ツールはあっても、「書き換える」ツールは最初から道具箱に入れていません。さらに、社内運用ルールには次の一文を明文化しています。

本番データベースへの直接操作（マイグレーション以外）は絶対に行わない

AIが賢いかどうかは関係ありません。どんなに聡明な操作者だとしても、組織が「触らせない」と決めた領域には触らせない。その規則を先に引いておく。これは、人間の従業員に職務権限を設計するのと、全く同じ発想です。

注意点の第二は、認証情報の管理です。MCPサーバーは業務システムのAPIを呼び出すため、APIトークン——「システムに入るための鍵」——を持つ必要があります。うちではそのAPIトークンをコードに直接書かず、環境変数で渡す設計にしています。環境変数が未設定なら、起動時にエラーで止まります。もし、鍵をコードに書いたまま、そのファイルをうっかり共有してしまったら。それは合鍵をばら撒くのと同じ事故です。

反対事実を考えてみます。もし、うちが権限設計なしに「とりあえず全部繋ぐ」をやっていたら、どうなっていたでしょうか。AIが何か間違った操作をしたとき、本番データが直撃ダメージを受けるリスクを、毎日抱え続けることになります。繋がなかったから守れている領域が、確実にあります。

繋ぐ範囲を絞る判断こそが、MCP活用の本体です。「AIに全部任せる」という判断をした会社ではなく、「AIに任せる範囲を意識的に決めている」会社が、この仕組みを安全に使いこなせます。

自社の業務にMCPを取り入れるには

では、どこから手をつけるか。読者の状況によって、道は2つに分かれます。

社内にIT担当がいる、あるいは業務を言語化できる経営者がいるなら、自作は現実的です。ここまで見てきた通り、実物は318行程度の小さなプログラムから始められます。手順を追いたい方には、Chatwork MCPサーバーの実装記が出発点になります。

自作が重いと感じる場合は、出来上がった形で使う道があります。当社はChatwork常駐型AIアシスタント「つなぐAIアシスタント」を開発中です（2026年7月時点・先行案内段階）。ホームページ側は先行して形になっており、顧客向けプロダクト群は「接客AIクラウド」として商品化し、ホームページ制作のクライアント約100社を対象に提供しています。守る・知る・書く・話すの4機能の中身は接客AIクラウドの紹介ページにまとめています。

「うちの業務なら、何から繋ぐべきか」という個別のご相談は、お問い合わせからお寄せください。繋ぐ順番の設計こそ、この分野でいちばん相談する価値のある論点です。

まとめ — MCPとは「AIを操作者にする」ための規格

要点は3つです。

第一に、MCPとはAIと業務システムをつなぐ共通規格であり、AIを「許可制の手足」にする仕組みだということ。AIは定義された道具しか使えません。

第二に、実物は大がかりではないこと。うちのChatwork MCPサーバーは全318行です。この規模の小さなプログラムから始められます。

第三に、本丸は技術ではないこと。「何を繋ぎ、何を繋がないか」の設計が、MCP活用の成否を分けます。

最後に、次のアクションを1つだけ。自社の業務システムのうち、「AIに読ませたいデータ」を1つ挙げてみてください。チャットの未読か、タスクの期限か、ホームページのアクセス数か。それが、あなたの会社の最初のMCPサーバーが持つべき、最初の道具になります。

著者: 島田慶資（ITコーディネータ）