TL;DR

公式MCPサーバー（v1.9.1）は27ツールを公開。アプリ作成→フィールド定義→デプロイ→レコードCRUDまで全部AIから操作できる。完成度は高い
ただし (1) 作った直後のアプリへのレコード追加は「アプリが見つかりません。削除されている可能性があります」という嘘の404になる（実際は未デプロイなだけ）
(2) バリデーションエラーは「入力内容が正しくありません」だけで、REST APIが本来返すフィールド別の詳細がMCP層で消える。AIは何を直せばいいか分からない
(3) フィールド設定を変更しても、デプロイ状況ツールは SUCCESS を返し続ける。「必須にしたつもり」の変更が本番未反映のまま、違反レコードが素通りする（実測）
(4)(5) 全ツールに危険度メタデータ（annotations）が無く、読み取り専用モードも無い。権限は渡したアカウントそのまま。ドメイン横断の全文検索ツールまである
結論: サーバーは悪くない。「全部通ってしまう」ことが危ない。AIにkintoneを触らせる時代の権限設計と検証は、まだほぼ空白領域

背景

サイボウズが2025年8月に公式のローカルMCPサーバーを公開し、Claude DesktopなどのAIツールからkintoneを直接操作できるようになりました（リリースのお知らせ、GitHub）。

「AIが業務アプリを作ってくれる」体験は強力ですが、実務で使うならAIから見える世界がどうなっているかを先に知っておくべきです。そこで本記事では、AIクライアントを介さず、MCPプロトコル（stdio上のJSON-RPC）を生で叩いて「AIにアプリを作らせる」操作列をそのまま再現し、挙動を観察しました。AIの応答という不確定要素を挟まないので、サーバー側の素の挙動が分かります。

検証環境

@kintone/mcp-server v1.9.1（npm・Apache-2.0）
Node.js 22 / macOS
kintone 開発者ライセンス環境・パスワード認証
なお kintone AI（アプリ作成AI等・2026年6月正式版）は開発者ライセンスでは提供されておらず、今回は対象外です（ポータル・アプリ作成・検索のいずれにもAI系UIが出ないことを実機確認）。本記事は「外部AI × 公式MCPサーバー」の話に絞ります

セットアップとプローブ方法

セットアップは3分で終わります。

npm install @kintone/mcp-server

KINTONE_BASE_URL=https://example.cybozu.com \
KINTONE_USERNAME=xxx \
KINTONE_PASSWORD=xxx \
  ./node_modules/.bin/kintone-mcp-server

MCPのstdioトランスポートは改行区切りのJSON-RPCなので、子プロセスに1行ずつJSONを書き込むだけで会話できます。

// initialize → tools/list → tools/call を順に投げる最小クライアント（抜粋）
server.stdin.write(JSON.stringify({
  jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: "2024-11-05", capabilities: {},
            clientInfo: { name: "probe", version: "0.1.0" } },
}) + "\n");

まず全体像: 27ツール

tools/list の結果を分類するとこうなります。

分類	ツール
読み取り（10）	get-app / get-apps / get-form-fields / get-form-layout / get-process-management / get-app-deploy-status / get-general-settings / get-records / get-record-comments / get-space
検索（1）	kintone-search（レコード・スペース・スレッド・コメント・添付を横断する全文検索）
書き込み（12）	add-app / add-form-fields / update-form-fields / update-form-layout / update-general-settings / deploy-app / add-records / update-records / update-statuses / add-record-comment / add-space-from-template / update-space
削除（4）	delete-form-fields / delete-records / delete-space / download-file(保存)

アプリの新規作成からフィールド定義、デプロイ、レコードCRUD、スペース削除まで一通り揃っています。逆に無いものも重要で、一覧（ビュー）設定・アクセス権・通知・プロセス管理の変更・プラグイン設定・JS/CSSカスタマイズ・アプリの削除は操作できません（アプリ削除はそもそもREST APIが存在しない）。

ちなみにREADMEのツール一覧表は26個で、kintone-search は表に載っていません（v1.9.1時点）。ツール表面積は今も増え続けている、ということです。

実験: 「案件管理アプリを作って」をAIの手順で再現

AIクライアントがやるであろう操作列をそのまま実行しました。

kintone-add-app（アプリ名: 案件管理）→ 即座に {"app":"398"} が返る
kintone-add-form-fields（会社名=必須テキスト・金額=数値・状態=ドロップダウン・期日=日付）
kintone-deploy-app → kintone-get-app-deploy-status で SUCCESS 待ち
kintone-add-records でレコード投入
kintone-get-records で確認

全部通ります。アプリ作成からレコード投入まで1分弱。この体験自体は素晴らしい。

問題は、この過程と前後で見つけた次の5つです。

落とし穴1: 作った直後のアプリが「削除されている可能性があります」

手順1の直後（デプロイ前）にレコードを追加しようとすると、こうなります。

[404] [GAIA_AP01] 指定したアプリ（id: 398）が見つかりません。削除されている可能性があります。

実際は削除されていません。kintone-add-app は動作テスト環境にアプリを作るので、kintone-deploy-app で運用環境に反映するまでレコードAPIからは見えない、が正しい説明です。

人間ならヘルプを調べて気づけますが、AIはこのエラー文言を文字通りに受け取ります。「アプリが削除された→作り直そう」と判断されると、未デプロイのアプリがもう1個できる。そして前述の通りアプリを削除するAPIは存在しないので、試行錯誤の残骸アプリはAPIからは永久に消せず、人間がUIから3ステップ×N回の手作業で掃除することになります。

対策: AIに渡す手順書（システムプロンプトやスキル）に「add-app後は必ずdeploy-app→deploy-statusがSUCCESSになるまで待つ。404『削除されている可能性』は未デプロイを疑う」を明記する。

落とし穴2: エラーの詳細がMCP層で消える

数値フィールドに文字列を入れた場合と、必須フィールドを欠いた場合。MCPツールが返すのはどちらもこれだけです。

[400] [CB_VA01] 入力内容が正しくありません。

kintone REST APIを直接叩いた経験がある方はご存知の通り、本来のレスポンスには errors オブジェクトがあり、「record.金額.value : 数値で入力してください」のようなフィールド単位の詳細が入っています。v1.9.1のMCPサーバーはこれを落として先頭メッセージだけを返します。

AIクライアントにとってこの差は致命的です。詳細があれば1回で自己修正できるものが、「何かが正しくない」としか分からないため、当て推量のリトライを繰り返すことになります（トークンも時間も溶けます）。

落とし穴3: 「必須にしたつもり」が本番に反映されないまま検出もできない

一度デプロイした後、kintone-update-form-fields で金額フィールドを required: true に変更しました。この状態で kintone-get-app-deploy-status を叩くと——

{"apps":[{"app":"398","status":"SUCCESS"}]}

SUCCESS です。このツールが返すのは「最後のデプロイ操作の結果」であって、「未反映の変更があるか」ではありません。UIで設定画面を開くと「反映前の変更があります」バナーがはっきり出ているのに、MCP経由の風景からは見えない。

実測で確認できた帰結: この状態で金額なしのレコードを投入すると、普通に成功します。運用環境は旧定義（金額=任意）のまま動いているからです。AIは「必須化した」と報告し、人間はそれを信じ、本番では違反データが溜まり続ける——という筋書きが普通に起こります。

対策: 変更系操作の後は必ず deploy-app を打つこと。さらに厳密には get-form-fields を preview: true と false で両方取得して差分を取ると未反映変更を検出できます（preview パラメータは存在するが、AIが自発的にdiffを取ることは期待できないので、手順書で強制する）。

落とし穴4: 危険度メタデータがゼロ

MCPには、ツールに readOnlyHint や destructiveHint といったアノテーションを付けてクライアントに危険度を伝える仕組みがあります。v1.9.1の27ツールは全てアノテーションなしでした。

つまりクライアントから見ると、kintone-get-app（読むだけ）と kintone-delete-space（スペースを消す）が同格です。読み取り専用モードも、使うツールを絞る設定もありません。AIクライアント側の確認ダイアログ設定だけが最後の砦になります。

落とし穴5: 権限は渡したアカウントそのまま + 横断全文検索

パスワード認証で管理者アカウントを渡すと、AIはそのユーザーに見える全てを読み書きできます。しかも kintone-search はドメイン横断の全文検索（レコード・スペース・コメント・添付ファイル）なので、「経理アプリの給与データをうっかり文脈に取り込む」ことも技術的には普通に起こり得ます。

APIトークン認証（カンマ区切りで最大9個）を使えば対象アプリと権限を絞れます。実測したところ、トークン認証で起動するとツール一覧そのものが27本→20本に絞られ、kintone-add-app・kintone-get-apps・kintone-search・スペース系4種は最初から現れません（tools/list に存在しない）。トークン対象外のアプリへのアクセスも [403] GAIA_AP15 で明確に拒否されます。ここは良い設計です。ただし裏を返すと、「アプリを作らせたい」ならユーザー認証で渡すしかない、という構造は変わりません。

暫定の運用プラクティス

検証を踏まえた現時点の自衛策です。

AI専用ユーザーを作る。管理者アカウントを渡さない。監査ログもユーザー単位なので、AIの操作が人間の操作と区別できるようになる
用途でサーバー設定を分ける。レコード操作だけならAPIトークン認証にする——サーバー自体がアプリ作成・横断検索・スペース系ツールを外してくれる（実測27本→20本）ので、これが実質的な読み書き範囲の絞り込みになる。アプリ構築をさせたい時だけ低権限ユーザーのパスワード認証
本番ドメインでいきなり使わない。開発者ライセンス環境（無料）で挙動を掴んでから
AIの「できました」を信用せず検証する。デプロイ状態・preview/本番の差分・必須/型の充足は、上で見た通り「成功したように見えて反映されていない」パターンがあるため、人かスクリプトで裏取りする
手順書に落とし穴1〜3の対処を明記する。エラー文言をAIが誤読する前提で書く

まとめ

公式MCPサーバー自体はよくできています。1分でアプリが建ち、レコードが入る。批判したいのではなく、むしろ全部通ってしまうからこそ、権限・検証・監査の設計を使う側が持ち込む必要がある、というのが今回の結論です。

ツール表面積はこれからも増えます（READMEの表に載っていない kintone-search が既にいるように）。「AIがkintoneを操作する」が当たり前になったとき、AIが作ったものを誰がどう検証するか・AIに何をどこまで許すかは、まだ誰も答えを持っていない空白地帯です。ここは引き続き追いかけて、分かったことを書いていきます。

検証は2026年7月・v1.9.1時点のものです。kintoneローカルMCPサーバーはAPIサポート窓口の対象外で、仕様は今後変わる可能性があります。バグ報告・機能要望はGitHub Issuesへ。

普段は kintone向けプラグインを Plumeru で開発・配布しています。