kintone MCPサーバーを使えば、生成AIとの対話だけでレコードの集計やアプリの設定変更ができます。ただし通常の構成では、考える側のAIはクラウドのモデルです。kintoneから取り出したレコードの中身が、LLM事業者のサーバーへ送られることになります。

これが引っかかるのは、個人情報や取引先の情報を含むアプリを扱うときです。社内規程や取引先との契約で、外部サービスへ送れるデータの範囲があらかじめ決められている。そんな職場は珍しくありません。そうした環境では、AI活用そのものを見送るか、当たり障りのないアプリだけに限定するか、という判断になりがちでした。

この推論部分を手元のPCに寄せる方法として、今回扱うLM Studioは、モデルの入手からMCPサーバーの登録まで、ほぼすべてをアプリの画面内で完結できます。ターミナルを使うのは、kintone MCPサーバーをインストールする1コマンドだけです。

本記事では、Windows環境でLM Studioとkintone公式MCPサーバーを接続し、ローカルモデルからkintoneを操作するまでの手順を解説します。記載している構成は、LM Studio 0.4.23、Qwen3.5 9B、@kintone/mcp-server 1.9.3の組み合わせで実際に接続を確認したものです。

kintone MCPサーバーそのものの概要・認証・制限については、概要編と実践編で扱っています。Claude以外のクライアントから使う話はCodex編にまとめました。あわせてご覧ください。

■構成：LM Studioが「MCPホスト」として動く

まず全体像を押さえます。LM Studioは0.3.17以降、MCPホストとして動作します。MCPホストとは、MCPサーバーを起動して、そのツールをモデルに使わせる側のアプリのことです。Claude DesktopやCodex CLIが担っていた役割を、LM Studioがそのまま引き受けると考えれば分かりやすいはずです。

データの流れは4段になります。

肝は、1段目と2段目が同じPCの中で完結することです。「どのツールをどう呼ぶか」という判断も、返ってきたレコードを読んで要約する処理も、すべて手元のGPUとメモリの上で起きます。外部のAIサービスにレコードの中身が渡ることはありません。

■事前準備

作業を始める前に、次の5つを確認します。

■手順1：ツール呼び出しに対応したモデルを選ぶ

この構成で最初につまずきやすいのが、モデル選びです。アプリ側がMCPに対応していても、モデルにツール呼び出しの能力がなければ、kintoneのツールは一度も呼ばれません。

選ぶ基準は2つだけです。

本記事ではQwen3.5 9Bを使います。9Bのdenseモデルで、ネイティブのコンテキスト長は262,144トークン。ツール呼び出し向けに学習されており、9B級としては指示の解釈が安定しています。Discoverタブで検索し、量子化はQ4_K_M（6.55GB）を選びました。

より大きいモデルを載せられるなら、ツール選択の精度はさらに上がります。逆に4B以下の小さなモデルでは、kintoneのように20個以上のツールが並ぶMCPサーバーを扱いきれず、間違ったツールを呼んだり引数を欠いたりしやすくなります。

■手順2：kintone MCPサーバーを用意する

ターミナルを使うのはここだけです。PowerShellを開いて、npmでグローバルインストールします。

npm install -g @kintone/mcp-server

検証時にインストールされたのは1.9.3でした。この時点ではまだ何も起動しません。MCPサーバーは、LM Studioが必要なときに子プロセスとして起動し、使い終われば終了します。自分で常駐させておく必要はありません。

■手順3：mcp.jsonに登録する ― Windowsはフルパス指定が確実

LM Studioの右サイドバーでProgramタブを開き、Install → Edit mcp.jsonを選びます。アプリ内エディタでmcp.jsonが開くので、ここにkintoneのサーバーを追記します。ファイルの実体は次の場所にあります。

Windows：C:\Users\（ユーザー名）\.lmstudio\mcp.json

この設定ファイルはCursorの記法に準拠しています。そのため、他のAIツール向けに書かれた設定例をほぼそのまま持ち込めます。素直に書くと次の形です。

{

　"mcpServers": {

　　"kintone": {

　　　"type": "stdio",

　　　"command": "kintone-mcp-server",

　　　"args": []

　　}

　}

}

ここでWindows特有のつまずきがあります。コマンド名だけを書くと、LM Studioがサーバーを見つけられないことがあります。 npmがグローバルにインストールするのはkintone-mcp-server.cmdというバッチファイルで、LM Studioが起動する子プロセスからは、この拡張子の解決に失敗する場合があるためです。

確実なのは、Node.js本体とスクリプトのパスを直接書く方法です。検証環境で動いたのは、この指定でした。

"command": "C:\\Program Files\\nodejs\\node.exe",
"args": ["C:\\Users\\（ユーザー名）\\AppData\\Roaming\\npm\\node_modules\\@kintone\\mcp-server\\dist\\index.js"]

JSONの中ではバックスラッシュを2つ重ねる点に注意してください。書き換えたらSaveを押します。なお、既存のMCPサーバーが登録済みの場合は、mcpServersの中に並べて追記する形になります。ファイル全体を上書きしないよう気をつけてください。

■手順4：認証情報はmcp.jsonに書かず、環境変数で渡す

設定例では、ベースURLやAPIトークンをenvとして直接書く方法がよく紹介されます。手軽ですが、mcp.jsonは平文のテキストファイルです。アプリ内エディタで開けば誰の目にも入りますし、設定を共有しようとしてトークンごと渡してしまう事故も起こりえます。

そこで検証環境では、認証情報をWindowsのユーザー環境変数に置き、mcp.json側には一切書かない構成にしました。MCPサーバーはLM Studioの子プロセスとして起動するため、ユーザー環境変数はそのまま引き継がれます。設定するのは次の2つです。

ユーザー名・パスワード認証を使う場合は、代わりにKINTONE_USERNAMEとKINTONE_PASSWORDを設定します。ここで一点、事故が起きやすいポイントがあります。パスワード認証とAPIトークン認証を同時に指定した場合、パスワード認証が優先されます。 APIトークンで権限を絞ったつもりが、実際にはユーザー権限で動いていた、という状態になりかねません。片方だけを設定してください。

選んだ認証方式によって、モデルに見えるツールの数が変わります。 同じv1.9.3のサーバーに対して、認証方式だけを変えてツール一覧を取得すると、次の差が出ました。

APIトークンのときに現れない7個は、kintone-get-apps（アプリ一覧の取得）、kintone-add-app（アプリ作成）、kintone-search、そしてスペース関連の4つです。いずれもアプリ単位のAPIトークンでは実行できない操作で、サーバー側があらかじめ除外していると考えられます。

この差は、動かしてみると分かりやすい形で表に出ます。APIトークン認証のまま「アクセスできるアプリの一覧を取得して」と頼むと、モデルは「アプリ一覧を取得する機能がありません」と答えます。これはモデルの能力不足ではなく、そのツールが渡されていないだけです。APIトークン認証で始めるなら、最初の指示にはアプリIDが必要だと覚えておいてください。

添付ファイルをダウンロードするツールを使う場合は、保存先としてKINTONE_ATTACHMENTS_DIRも必要です。指定しないまま実行するとエラーになります。

環境変数を設定したら、LM Studioをいったん終了して起動し直します。 起動中のプロセスには新しい環境変数が反映されません。ここを飛ばすと、Integrationsの一覧にPlugin process exited unexpectedly with code 1と表示されます。公式ドキュメントのエラー一覧にある「Either KINTONE_USERNAME/KINTONE_PASSWORD or KINTONE_API_TOKEN must be provided」に相当する状態で、認証情報がサーバーに届いていないことを意味します。

紛らわしいのは、再起動したのに直らない場合があることです。環境変数は、プロセスが起動した時点の値を引き継ぎます。設定した直後にLM Studioを起動しても、起動元（たとえば古いまま残っていたエクスプローラーやターミナル）が新しい値を知らなければ、そこから渡される環境も古いままです。改善しないときは、いったんサインアウトするか、Windowsを再起動してから試すのが確実です。

■手順5：読み取り専用の指示で動作確認する

準備が整ったら、新しいチャットを開いてQwen3.5を読み込み、kintoneのMCPサーバーを有効にします。最初の指示は読み取り系に限定してください。

APIトークン認証の場合、最初の指示にはアプリIDを含めます。kintoneでアプリを開いたときのURL（https://（サブドメイン）.cybozu.com/k/AppID(アプリIDの数字を入力)/）の数字部分がアプリIDです。

▶ 入力：kintoneのアプリID 5 のフィールド構成を教えて

モデルがツールを呼び出そうとすると、LM Studioが実行確認ダイアログを表示します。ここでどのツールに、どんな引数が渡されようとしているかが読めます。検証時に表示されたのは次の内容でした。

Model wants to call kintone-get-form-fields
Arguments: { "app": "5" }

ツール名も引数も正しく組み立てられています。ダイアログにはProceed（実行）、Deny（拒否）、Deny with Reason（理由を添えて拒否）の3つがあり、下には「このツールを常に許可する」「このサーバーの全ツールを常に許可する」というチェックボックスが並びます。最初のうちは、このチェックは付けないでください。 毎回中身を確認する手間が、そのまま安全弁になります。

Proceedを押すと、フィールドコード・ラベル・種別・必須の一覧が表として返ってきます。

■どこまで任せられるのか ― アプリ作成からレコード集計まで

読み取りが通ったら、次はどこまで任せられるかです。認証をユーザー名・パスワードに切り替えると、アプリ一覧の取得とアプリ作成が使えるようになります。検証環境で、次の1つの指示を投げてみました。

▶ 入力：「記事検証用メモ」という名前でkintoneアプリを新規作成して。作成したら、そのアプリに次の3つのフィールドを追加して。タイトル（文字列1行、フィールドコードは title）、本文（文字列複数行、フィールドコードは body）、優先度（ドロップダウン、フィールドコードは priority、選択肢は 高・中・低）。最後に運用環境へ反映まで実行して。

Qwen3.5 9Bは、この指示を4つのツール呼び出しに分解して順番に実行しました。

最後の1つは指示していません。モデルが自発的に、自分の作業結果を確認しにいきました。 そのうえで、各ステップの成否を表にまとめて返してきます。9B級のローカルモデルでも、ここまでは任せられるということです。

続けてレコードを3件登録させ、取得と集計まで頼みました。kintone-add-recordsでkintone形式のレコード配列を組み立て、kintone-get-recordsで取得したうえで、優先度ごとの件数を表にまとめるところまで通りました。

ただし、速度は実用的とは言えません。 検証環境では、1回のやり取りに2〜3分かかりました。内訳は、3万トークン超のツール定義を読み込むプロンプト処理と、ツール実行ごとに人が確認ダイアログを押す時間です。上のアプリ作成では、確認ダイアログが4回出ています。クラウドのモデルなら十数秒で終わる作業だと考えると、差は明らかです。

それでも、この構成には代えがたい点があります。アプリの構成もレコードの中身も、外部のAIサービスを一度も経由していません。 速度と引き換えに何を得るのか、という判断になります。

■つまずいた点:コンテキスト長 ― ここが最大の関門

この構成で一番つまずいたのが、コンテキスト長でした。結論から書くと、LM Studioの初期値（8,192）はもちろん、32,768でもkintone MCPサーバーは動きません。

コンテキスト長32,768で最初の指示を送ったところ、返ってきたのはこのエラーでした。

request (33532 tokens) exceeds the available context size (32768 tokens)

会話はまだ1往復もしていません。ツール定義（名前・説明・引数のスキーマ）を読み込んだだけで、約33,500トークンを消費しているということです。kintoneのツールは引数のスキーマが細かく、20個も並べばこの量になります。公式ドキュメントも、MCPサーバーはトークンを大量に使うことがあり、ローカルモデルではコンテキストが溢れやすいと注意を促しています。

65,536に上げたところ、問題なく動きました。 実務で使うなら、この65,536を出発点にするのが現実的です。Qwen3.5 9Bのネイティブ上限は262,144なので、余裕があればさらに広げられます。

ただし、広げた分だけメモリを食います。検証環境（Radeon RX 6800／GPUオフロード最大）では、Qwen3.5 9BのQ4_K_Mで、コンテキスト長8,192のとき推定7.21GB、32,768で8.14GBでした。コンテキスト長を4倍にすると、およそ1GB増えるという感覚です。モデル本体だけを見てVRAMの余裕を判断すると足りなくなります。

もう一つ、体感に直結するのがプロンプト処理の時間です。3万トークン超のツール定義を読み込む必要があるため、最初の応答が始まるまでに数十秒かかります。2回目以降はキャッシュが効いて速くなりますが、新しいチャットを開くたびにこの待ち時間が発生します。チャットは開きっぱなしで使い回すほうが快適です。

会話が進んでからも、レコードを大量に取得して集計する場面では容量を圧迫します。数百件のレコードがそのまま会話履歴に載るためです。対策は、取得条件を絞って渡すこと。「5件だけ」「今月の未完了レコードだけ」「必要なフィールドだけ」と指示に含めるほうが、結果的に速く正確に終わります。

■その他注意点

実際に運用に載せる前に、まず押さえておきたいのが次の3点です。

そのうえで、認証方式はできることの範囲そのものを変えます。アプリ単位のAPIトークンでは、まだ存在しないアプリを作る権限を渡せません。kintone-add-appやアプリ一覧の取得まで試すフェーズは、検証環境でユーザー名・パスワード認証を使う必要があります。逆に日々のレコード操作は、権限を絞ったAPIトークンのほうが安全です。フェーズによって使い分けるのが現実的な運用になります。

そのほか、把握しておきたい制約は次のとおりです。

■まとめ

LM Studioでkintone MCPサーバーを動かす手順は、突き詰めると次の5ステップです。

設定作業そのものは「MCPサーバーの起動コマンドを1箇所に書く」だけで、Ollama構成のように複数のソフトを噛み合わせる必要はありません。それでいて、推論は手元のGPUで完結します。

実際につまずくのは、コンテキスト長と認証方式のほうです。どちらも公式ドキュメントを読んだだけでは気づきにくく、動かして初めてエラーとして現れます。この2つを先回りして押さえておけば、残りは素直に繋がります。

ローカルモデルには制約もあります。応答速度も、複雑な指示の通りやすさも、クラウドのモデルには届きません。コンテキスト長の制約から、扱えるレコード件数にも上限があります。それでも、顧客情報や商談内容といったkintoneの実データを外部のLLMに送りたくないという要件がある場面では、検討に値する選択肢です。まずは検証環境と閲覧専用のAPIトークンを用意して、手元のマシンがどこまでやれるかを確かめてみてください。

■参考情報（一次情報）

※本記事は2026年9月時点で公開されている公式情報と、LM Studio 0.4.23／Qwen3.5 9B（Q4_K_M）／@kintone/mcp-server 1.9.3／Node.js v24.19.0／外部GPU(16GB)の組み合わせで行った検証をもとに作成しています。トークン数・メモリ使用量・処理時間はいずれもこの環境での実測値であり、応答内容や画面構成もあわせて、環境・バージョン・モデルによって異なります。LM Studioおよびkintone MCPサーバーはいずれも更新頻度が高いため、最新の仕様は各公式ドキュメントをあわせてご確認ください。また、kintoneの認証情報の扱いやAPIトークンの権限設計については、自社のセキュリティポリシーに沿ってご判断ください。