kintoneのMCP、リモートとローカルどちらを選ぶ？

結論：見るべきは「アクセス権をどこで統制するか」

kintoneをAIと連携させる方法には、大きく分けて「リモートMCP」と「ローカルMCP」の2つがあります。

どちらが優れているかという話ではありません。ただ、選ぶときに最初に見るべき点は、導入の手軽さでも環境の置き場所でもありません。そのAIが誰の権限でkintoneを見にいき、その権限を誰がどこで管理し続けるのかです。

組織で使い始めると、この違いがそのまま運用の負担になって表れます。判断に使えるよう、3つの問いに分けて整理します。

そもそもMCPとは

MCP（Model Context Protocol）とは、AIがkintoneのような外部サービスを直接操作するための接続の仕組みです。

普段AIに「今日の予定を教えて」と聞いても、AI自身はkintoneやGaroonの中身を直接見にいくことはできません。MCPは、AIとkintone・Garoonの間をつなぐ接続点です。これがあることで、AIが情報を取得したり、レコードを登録したりできるようになります。担当者が毎回kintoneの画面を開いて確認・入力する手間を、AIとの会話に置き換えられます。

この接続点となる「MCPサーバー」を自社の手元で動かすか、外部が用意した接続を経由して使うかで、ローカルMCPとリモートMCPの2つに分かれます。そして、どこで動かすかの違いは、そのまま認証方式の違いになります。

ローカルMCP — サイボウズ公式kintone MCPを例に

ローカルMCPは、AIとkintoneをつなぐ接続点を自社の環境の中で動かす方式です。サイボウズ公式が提供するkintone MCPが代表例で、公式自身が「kintone MCPサーバー」という名称で案内しています。

稼働する場所は手元や社内のサーバーです。stdio・Docker・npm・Claude Desktop拡張機能といった手段で自社の環境に立ち上げて使います。AIとkintoneのやり取りが自社の環境内で完結し、構成やアップデートの管理も自社で担います。

認証方式は、APIトークンかユーザー名/パスワードのどちらかを設定します（公式リポジトリに設定項目が記載されています）。この2つは、アクセス権の観点では性質が違います。

APIトークンは「人」ではなく「アプリの鍵」

kintoneのAPIトークンは、アプリに対して発行する鍵です。トークンごとに閲覧・追加・編集・削除の権限を設定できます。

押さえておきたいのは、トークンは「誰が使っているか」を区別しないことです。トークンを設定したMCP経由でAIがkintoneを見にいくと、動くのはトークンに設定された権限であって、そのAIを使っている人の権限ではありません。結果として、本来その人には見えないはずのアプリやレコードにも、AI経由なら手が届く状態が生まれ得ます。

これはAPIトークンの欠陥ではなく、仕様どおりの正しい挙動です。システム間の自動連携では、人に依存せず一定の権限で動いてくれることがむしろ利点になります。ただし「人がAIを通して使う」場面では、この性質が権限設計とかみ合わなくなります。

ユーザー名/パスワードは本人の権限。ただし認証情報を手元に置くことになる

ユーザー名/パスワードで認証すれば、そのアカウントの権限で動きます。権限のズレという意味では、APIトークンより素直です。

一方で、認証情報をどこに置くかという課題が出てきます。公式リポジトリに掲載されている設定例では、MCPクライアントの設定ファイルの中に、ユーザー名とパスワードをそのまま記述する形が示されています。環境変数として外から渡すこともできますが、いずれにしてもkintoneにログインできる認証情報が利用者の端末に置かれることに変わりはありません。

これはサイボウズ公式に限った話ではなく、手元で動かすタイプのMCPサーバー全般に共通する性質です。

リモートMCP — スキル39のkintoneMCP・GaroonMCP

リモートMCPは、自社の環境にサーバーを構築しなくても、接続するだけで会話からkintoneやGaroonを操作できる方式です。ジョイゾーはスキル39のサービスとして、kintoneMCP・GaroonMCPを提供しています。

ジョイゾーのリモートMCPはOAuth認証です。利用者本人がkintoneに対して接続を許可する形をとるため、先ほどの3つの問いへの答えが変わります。

• AIは常に接続した本人の権限でkintoneにアクセスします。営業担当が接続すれば営業担当に見える範囲、経理担当が接続すれば経理担当に見える範囲です
• 利用者にパスワードやトークンを配る必要がありません。本人が許可するだけなので、認証情報を端末に置かずに済みます
• 誰が何を見られるかは、これまでどおりkintoneのアクセス権設定だけで決まります

活用例は次のとおりです。

• GaroonMCPで複数人の空き予定を確認し、そのまま予定を登録する（日程調整が会話だけで完結する）
• GaroonMCPで1週間分の予定を取得し、kintoneMCPで週報アプリに週報の元ネタを登録する（週次の作業を会話から始められる）

どちらも環境構築なしで、会話の中で完結します。「毎週発生するけれど地味に時間を取られる作業」から使い始めると、効果を実感しやすい領域です。

「自社に閉じている＝安全」とは限らない

方式を選ぶとき、「データが社外の経路を通らない方が安全だ」という判断をよく聞きます。

ただ、中小企業においては逆のことも起こります。専門のチームが常時対策しているクラウドに対して、同じ水準を自社環境で維持し続けるのは簡単ではありません。人材の確保という点で、多くの中小企業にとっては現実的な負担になります。

そしてAI連携で実際に問われるのは、経路がどこを通るかだけではありません。その先で誰の権限が使われ、それを誰が管理しているかです。自社の環境に閉じていても、共用の認証情報が権限を越えて配られていれば、統制は効いていません。

環境を閉じることと、アクセス権を正しく効かせることは、別の問題として考える必要があります。

どちらを選ぶ？情シスの判断チェックリスト

次の問いに順番に答えていくと、自社に合う方が見えてきます。

• AIには使う人自身の権限で動いてほしいですか？ → YesならリモートMCP寄り
• アクセス権の管理をkintoneの設定に一元化したいですか？ → YesならリモートMCP寄り
• 認証情報の配布・棚卸しまで担える体制が社内にありますか？ → NoならリモートMCP寄り
• 環境を自社に閉じたい、管理主体も自社に置きたいですか？ → YesならローカルMCPも選択肢

なお、どちらか一方に決め切る必要はありません。人が会話で使う用途はリモートMCP、システム間の自動連携は権限を絞ったトークンとローカルMCP、というように用途で使い分ける形もあります。まずリモートMCPで小さく試し、手応えを見てから環境構築を検討するという順番も現実的です。

迷ったら「何にどう使うか」から一緒に決める — スキル39

MCPはあくまで手段です。大事なのは「何のためにAIとkintoneをつなぐか」という目的から考えることで、そこが整理できていないと、リモートかローカルかを選ぶ以前に活用が進みません。

スキル39は、1時間×3回のセッションで、生成AIを自社の業務にどう活かすかを一緒に設計するサービスです。初回の60分は「生成AIによる業務フロー分析＆課題の抽出」として無償で受けられるので、まずは自社の業務に当てはめて相談し、続けるかどうかをそこで判断できます。どちらのMCPが向いているかも、アクセス権の設計と合わせてこの中で整理していけます。

詳しくはスキル39のサービスページをご覧ください。