3連続やられて立ち位置かえたら、むしろ有用になった話
MCPのことは、わりと前から知っていた。
自分が用意されたものをつかうこと、いや、存在を意識することなくつかうことはあっても——用意する側になるとは、思っていなかった。
Model Context Protocol。AIが外部のツールやデータに直接アクセスするための仕組みで、これを使うとClaude や ChatGPT に「このSaaSのデータを読んで」「このシステムに書き込んで」と頼めるようになります。APIキーを渡してプロンプトに貼り付ける、という手作業がなくなる。（参照：MCP公式サイト）
非エンジニアがAIと一緒に業務を回すには、このMCPが鍵になると思いました。そして日本のSMBにとって、その「用意する側」があまりいないのではと思いました。
日本のSMBには空白地帯がある
海外の主要SaaSはMCPへの対応が進んでいますが、日本のSMB向けSaaSはまだ手薄な状態でした。
freee、マネーフォワードクラウド、kintone——中小企業がよく使う業務システムですが、AIから直接触れる手段がない。DGBTの仕事でこれらのシステムをつかっていて、AIとの連携ができれば業務自動化の幅がかなり広がると感じていました。
「誰かがつくるだろう」と思って待っていましたが、待てなくなって自分でつくることにしました。
freeeから始めた
最初に着手したのは freee の会計APIです。
請求書の作成・参照・仕訳の確認あたりを自然言語でできるようにすれば、経理周りの作業がかなり楽になるはずでした。APIのドキュメントを読んで、MCPサーバーの構造を学んで、少しずつ実装を進めていきました。
次はマネーフォワードクラウド、その次は kintone、と積み上げていく予定でした。
3連続でやられた
freee の実装がある程度形になってきたころ、freee が公式MCPを公開しました。2026年3月のことです。会計・人事労務・請求書など主要領域をカバーした、フルスペックのものでした。（参照：freeeプレスリリース）
さすがに笑いました。
「じゃあ、マネーフォワードに切り替えよう」と思ったら、同じ時期にマネーフォワードクラウドも公式MCPを全プランで開放。（参照：マネーフォワードプレスリリース）
その2ヶ月後には kintone も公式のクイックスタートガイドをだしてきました。（参照：cybozu developer network）
自分がつくろうとしていたものが、3本連続で公式からでてきたのです。
3連敗のタイムライン
2026/3/2 freee 公式MCP公開
2026/3/26 マネーフォワード 公式MCP公開
2026/5 kintone 公式MCP公開
方向を変えた
落ち込んだかというと、そうでもありませんでした。
公式がでたならそちらをつかえばいい。ベンダーが自分でメンテするMCPが一番信頼できるし、API仕様の変更にも追従してもらえます。自作のものを維持し続けるコストを考えると、「公式に任せる」は正しい判断です。
ただ、改めて整理してみてわかったことがあります。コネクタの数そのものは、あまり意味がない。REST APIがあれば誰でも数時間で実装できるし、公式MCPがでれば一瞬で陳腐化する。本数を競うのは消耗戦です。
問題は、何を作るかです。
整理してみると、答えはシンプルでした。公式がでないであろうSaaSをうめる。大手や海外展開を目指しているSaaSはいずれ自分たちで対応するかもしれない。でも、日本のSMBローカルで動いているシステムは、ベンダーがMCPをだす動機が薄い。
ここに空白地帯が残ります。
今つくっているもの
現在アクティブなコネクタは34サービスです。
日本SMB向けのメインどころはこのあたりです。
Lステップ（LINE公式アカウントのMA）— 全19エンドポイント実装済み
KING OF TIME / AKASHI / HRMOS勤怠（勤怠管理）
SmartHR（人事・労務）
カオナビ / HERP Hire / Talentio（採用・タレントマネジメント）
Mazrica Sales（SFA）
invox / Misoca / MakeLeaps（請求書・見積書）
スマレジ（POSレジ）
クラウドサイン（電子契約）、board（経営管理）、Garoon（グループウェア）ほか
どれも「日本のSMBが実際につかっているが、公式MCPがない」カテゴリです。Lステップだけ全19エンドポイントを網羅していて、他はそれぞれ主要操作を5ツールでカバーした段階です。
つくるより、動かし続けるほうが難しい
実装は、入口です。
業務でAIコネクタを使おうとすると、すぐに別の問題が出てきます。APIキーをどこで管理するか。複数のメンバーがつかうとき、誰がどの操作をしたか記録が必要になる。ローカルにインストールしてつかうのは、ITリテラシーが高くないメンバーには障壁になる。
コネクタの「上」にあるこういう部分——鍵管理、操作ログ、常時稼働の仕組み——のほうが、実は難しくて、価値が乗る部分だと思っています。OSSで実装を公開しながら、この領域を整えていくのが、このプロジェクトの本題です。
公式がでたら乗り換える、でないところは自分でうめる
mcp-jp のリポジトリには、公式MCPがでたコネクタを archive/ に退避させるルールを設けています。「これは公式が出たから使わなくていい」と明示して、能動的に整理していく。
追いかけるのではなく、ベンダーが手を出さない場所に居続けること。そういうプロジェクトにしたいと思っています。
立ち位置が決まったその後、実際に動き出したプロジェクトと、みなさんへのお願いがあります。あわせて読んでください👇
その後、
このプロジェクトの発信用Xアカウントが「偽装行為」で凍結されるという事件が起きました。顛末はこちら👇
