kintone公式MCPサーバーはClaude専用ではありません。OpenAIのCodex CLIから同じローカルサーバーを呼び出し、自然言語でkintoneを操作するまでを実践解説。設定の手順、ChatGPT本体との違い(stdio vs リモート)での注意点までまとめます。

これまでの記事では、kintone MCPサーバーの概要と、Claude Desktopでのハンズオンを扱いました。そこで自然に出てくるのが「これってClaude専用なの?ChatGPTやCodexからは使えないの?」という疑問です。結論から言うと、kintone公式MCPサーバーは特定のAIに依存しない“共通規格(MCP)”のサーバーなので、Claude以外のクライアントからも使えます。本記事では、その代表としてOpenAIのCodex CLIから実際にkintoneを操作するまでの手順を、つまずきやすい点とあわせて解説します。

先に結論 ― クライアント別「使えるか」早見表

AIクライアント

使える?

繋ぎ方

Claude Desktop

◎ そのまま

MCPBファイルをドラッグ&ドロップ(最も手軽)

Claude Code / Cursor

◎ そのまま

設定ファイル(.mcp.json / .cursor/mcp.json)に登録

Codex CLI

◎ そのまま

config.toml または codex mcp add で登録(追加ホスティング不要・本記事で詳説)

ChatGPT本体(Developer mode)

△ 条件付き

リモート化が必要(記事後半で解説)

表のとおり、ローカルで動くタイプのAIクライアント(Claude各種・Codex CLI)は、ほぼ同じ作法でそのまま繋がります。一方、ChatGPT本体は事情が少し異なります。まずは「なぜ使い回せるのか」から押さえましょう。

なぜ「Claude以外」でも使えるのか ― MCPは“共通規格”だから

MCP(Model Context Protocol)は、AIモデルと外部ツールをつなぐためのオープンな共通プロトコルです。kintone公式MCPサーバーは、その規格に沿ったローカルの「stdio型」サーバーとして提供されています。stdio型とは、AIクライアントがサーバーをローカルの子プロセスとして起動し、標準入出力でやり取りする方式のこと。つまり「stdioに対応したMCPクライアントなら、どれでも同じ起動コマンドで繋がる」という設計です。

Claude Desktop・Claude Code・Cursor、そして今回のCodex CLIは、いずれもこのstdio型に対応しています。とくにCodexはCLIとIDE拡張の両方でMCPをサポートし、ローカルのstdioサーバーとネットワーク越しのStreamable HTTPサーバーのどちらも扱えます。今回のkintone公式サーバーはstdio型なので、Codexにとってはもっとも素直に繋がる構成です。

「どのAIで操作するか」と「どこに繋ぐか」は別の話。 MCPサーバーはkintone REST API経由でkintoneとやり取りします。AIクライアント側は、その共通の窓口(MCP)に話しかけるだけ。だからクライアントがClaudeでもCodexでも、kintone側の動きは変わりません。使い慣れたAIのまま、kintone操作を足せるのがMCP連携の利点です。

今回のゴール ― Codexと会話してkintoneを動かす

まずは早見表で「◎ そのまま」だったCodex CLIで、実際に繋いでみます。流れは次の4ステップ。難しいコードは書かず、設定ファイルを整えてCodexに登録するだけです。

ステップ

やること

使うもの

1

kintone MCPサーバーを用意する

npm または Docker

2

Codexにkintone MCPサーバーを登録する

codex mcp add / config.toml

3

接続できているかを確認する

Codex TUIの /mcp

4

自然言語でkintoneを操作する

Codexへの指示

準備 ― 必要なものと「試す場所」の決め方

前提として、Codex CLIが導入済みcodex コマンドが使える状態)であることとします。加えて、kintone MCPサーバーを動かすためにNode.js もしくは Docker のどちらかが必要です。そして当然ながら、操作対象となるkintoneの認証情報(ベースURLと、ユーザー名/パスワード または APIトークン)を用意します。

まずは「壊れても困らない環境」で。 AIにkintoneの操作を任せる以上、いきなり本番環境に繋ぐのは避けます。検証用のサブドメインやテスト用アプリなど、試行錯誤しても問題ない場所で動作を確かめてから本番に広げるのが鉄則です。

認証の使い分け ― 「アプリ作成」だけは少し注意

kintone MCPサーバーは、ユーザー名/パスワード認証APIトークン認証のどちらにも対応しています(APIトークンはカンマ区切りで最大9個まで指定可)。日々のレコード操作は権限を絞ったAPIトークンが安全ですが、「まだ存在しない新規アプリの作成」だけはアプリ単位のAPIトークンでは権限を渡せないという構造があります。アプリ作成・フィールド設計まで試したいフェーズは検証環境+ユーザー名/パスワード認証、固まってからの運用はAPIトークンを読み取り専用から段階導入、という整理が自然です(この考え方は前回のハンズオン記事と共通です)。

ステップ1 ― kintone MCPサーバーを用意する

サーバーの実体は、npmパッケージかDockerイメージで入手できます。Codexから起動するので、ここでは「起動コマンドが手元で通るか」を押さえておけば十分です。MCPサーバーはCodexが必要時に子プロセスとして起動し、終了後は停止します。Docker版で --rm を付けるとコンテナは一覧に残りません。

方法A:npm(Node.js)

npm install -g @kintone/mcp-server

インストール後、次のコマンドで起動できます(--base-url / --username / --password は、環境変数 KINTONE_BASE_URL / KINTONE_USERNAME / KINTONE_PASSWORD でも指定可能です)。

kintone-mcp-server \
  --base-url https://example.cybozu.com \
  --username your-login \
  --password your-password

方法B:Docker

docker run -i --rm \
  -e KINTONE_BASE_URL=https://example.cybozu.com \
  -e KINTONE_USERNAME=your-login \
  -e KINTONE_PASSWORD=your-password \
  ghcr.io/kintone/mcp-server

環境を汚したくない、チームで構成を揃えたいといった場合はDockerが向いています。どちらの方法でも、次のステップでCodexに登録する「起動コマンド」が変わるだけで、考え方は同じです。

ステップ2 ― Codexにkintone MCPサーバーを登録する

Codexは、MCPの設定を config.toml(既定では ~/.codex/config.toml)に保存します。プロジェクト単位で .codex/config.toml(信頼済みプロジェクトのみ)に置くこともできます。登録方法は2通りです。

方法A:codex mcp add コマンドで登録する

もっとも手軽なのはCLIから追加する方法です。-- の後ろに、ステップ1で確認したサーバーの起動コマンドを書きます。npmでグローバルインストールした場合は次のようになります。

codex mcp add kintone \
  --env KINTONE_BASE_URL=https://example.cybozu.com \
  --env KINTONE_USERNAME=your-login \
  --env KINTONE_PASSWORD=your-password \
  -- kintone-mcp-server

Dockerで動かす場合は、-- の後ろをdockerの起動コマンドに置き換えます。

codex mcp add kintone \
  --env KINTONE_BASE_URL=https://example.cybozu.com \
  --env KINTONE_USERNAME=your-login \
  --env KINTONE_PASSWORD=your-password \
  -- docker run -i --rm \
     -e KINTONE_BASE_URL -e KINTONE_USERNAME -e KINTONE_PASSWORD \
     ghcr.io/kintone/mcp-server:latest

方法B:config.toml を直接編集する

細かく制御したい場合は、~/.codex/config.toml[mcp_servers.<名前>] のテーブルを書きます。npm版はシンプルにこう書けます。

[mcp_servers.kintone]
command = "kintone-mcp-server"

[mcp_servers.kintone.env]
KINTONE_BASE_URL = "https://example.cybozu.com"
KINTONE_USERNAME = "your-login"
KINTONE_PASSWORD = "your-password"

Docker版は commanddockerargs に起動オプションを並べます。

[mcp_servers.kintone]
command = "docker"
args = [
  "run", "-i", "--rm",
  "-e", "KINTONE_BASE_URL",
  "-e", "KINTONE_USERNAME",
  "-e", "KINTONE_PASSWORD",
  "ghcr.io/kintone/mcp-server:latest"
]

[mcp_servers.kintone.env]
KINTONE_BASE_URL = "https://example.cybozu.com"
KINTONE_USERNAME = "your-login"
KINTONE_PASSWORD = "your-password"

CLIとIDE拡張は設定を共有します。 一度 config.toml に登録すれば、Codex CLIとIDE拡張のどちらからでも同じkintoneサーバーを使えます。APIトークンで認証する場合は、KINTONE_USERNAME / KINTONE_PASSWORD の代わりに KINTONE_API_TOKEN(カンマ区切りで最大9個)を渡します。なお、ユーザー名/パスワードとAPIトークンを同時に指定した場合はパスワード認証が優先されます。

ステップ3 ― 接続できているか確認する(/mcp

登録できたら、Codexを起動し、TUI(ターミナルUI)で /mcp と打ちます。稼働中のMCPサーバーと、そのサーバーが提供するツール一覧が表示されれば成功です。kintoneサーバーなら、kintone-get-apps(アプリ一覧取得)や kintone-get-records(レコード取得)、kintone-add-records(レコード追加)といったツールが並びます。

一覧に出てこないときは。 まず起動コマンド自体が手元で通るかを確認します(npmなら kintone-mcp-server にパスが通っているか、Dockerならイメージを取得済みか)。起動に時間がかかる場合は、config.tomlstartup_timeout_sec(既定10秒)を延ばすと改善することがあります。企業プロキシ環境では HTTPS_PROXY 環境変数の設定も必要です。

ステップ4 ― 自然言語でkintoneを操作する

接続できれば、あとはClaude Desktopのときと同じ感覚です。kintoneの画面を開かずに、Codexへの指示だけでデータを引き出したり集計したりできます。

Claude Desktopでのハンズオンで作成したアプリの設定を利用してます。

▶ 入力:
kintoneのアプリ一覧を見せて。そのうち「案件・商談管理」アプリのレコードを取得して、フェーズごとの件数と金額合計を表にまとめて。

◆ 出力:

ここでも役割分担は明快です。「kintoneからデータを引き出す」のがMCPサーバー、「引き出したデータを集計・整形する」のがCodex(AIモデル)本体。この切り分けがイメージできると、レコードの抽出条件を変えたり、出力をMarkdownの表やCSVにしたりと、応用範囲が一気に広がります。

ChatGPT本体ではどうか ― 「stdio vs リモート」の壁

では、早見表で「△ 条件付き」としたChatGPT本体はどうでしょうか。ChatGPTもDeveloper modeでMCPに対応していますが、ここには明確な違いがあります。ChatGPTのMCP連携はリモート(HTTPSでアクセスするサーバー)にしか対応しておらず、ローカルのstdioサーバーには繋がりません。さらに、ChatGPT本体でのMCP連携は、Developer modeやCustom MCPの利用可否がプラン・ワークスペース設定に依存します。利用時点の公式ドキュメントを確認してください。

kintone公式サーバーはローカルのstdio型なので、ChatGPT本体からはそのままでは利用できません。どうしても使う場合は、次のいずれかで「リモート化」するひと手間が必要です。

つまり、同じ「Claude以外」でも難易度はクライアント次第です。手元のPCでさっと試すなら、追加のホスティングが要らないCodex CLIが圧倒的に簡単。ChatGPT本体は、社内に閉じたリモートエンドポイントを用意できる場合の選択肢、と捉えるのが現実的です。

つまずきポイントとコツ

場面

気づき・対処

コマンドが見つからない

npmグローバル版の kintone-mcp-server にパスが通っているか確認。通らなければDocker版に切り替えると環境差を吸収しやすい。

認証エラー

ユーザー名/パスワードとAPIトークンを同時指定していないか(同時指定はパスワードが優先)。ベースURLの綴りも確認。

権限エラー

APIトークンに必要な権限(閲覧/追加/編集/削除)が付いているか。ゲストスペース内アプリは非対応

アプリ作成ができない

アプリ単位のAPIトークンでは新規アプリ作成はできない。作成まで試すならユーザー名/パスワード認証で。

書き込みが不安

Codexのツール承認モードdefault_tools_approval_mode = "prompt")や、enabled_tools / disabled_tools の許可・拒否リストで、読み取り系だけを許可するなど制御できる。

セキュリティと運用上の注意

AIにkintoneの読み書きを任せる以上、権限とツールの制御は最優先です。

検証環境から、最小権限で始める。 まずは検証用サブドメインやテスト用アプリで。APIトークンは「閲覧のみ」から始め、必要に応じて「追加」「編集」へと段階的に広げます。削除を行わないならトークンに削除権限は付けません。

クライアント側のツール制御を活用する。 Codexはツール単位の承認モードを設定できます。書き込み系ツール(kintone-add-recordskintone-update-records など)を approveprompt にして実行前に必ず人間が確認する、disabled_tools で危険な操作を無効化する、といった「安全側の初期設定」をおすすめします。

認証情報の取り扱い。 config.toml にはベースURLや認証情報が平文で書かれます。リポジトリにコミットしない、共有しない、環境変数やシークレット管理の仕組みに寄せる、といった基本を徹底してください。なお、kintoneローカルMCPサーバーはAPIサポート窓口の対象外(OSS)である点も把握しておきましょう。

まとめ ― 「Claude専用」ではない

kintone公式MCPサーバーはMCPという共通規格に沿ったstdio型サーバーなので、Claudeに限らずstdio対応クライアントから利用できます。「ChatGPTやCodexからでも使えるのか?」への答えは、Codex CLIならYES(そのまま)、ChatGPT本体なら条件付きでYES(リモート化が必要)です。とくにCodex CLIは、公式のstdioサーバーを config.toml に登録するだけで連携でき、追加のホスティングも要りません。/mcp で接続を確認したら、あとは使い慣れたAIのまま、自然言語でkintoneのデータ取得や集計を任せられます。

「どのAIを使うか」はもう制約ではありません。手元で素早く試すならCodex CLI、組織のChatGPT環境に組み込むならリモート化、と目的に合わせてクライアントを選べばよい段階に来ています。次回は、ここで触れたChatGPT本体向けにkintone MCPをリモート公開する手順を取り上げる予定です。KintoNaviでは引き続き、クライアントを問わないkintone×AIの実践パターンを追いかけていきます。


参考情報(一次情報)

※本記事は2026年6月時点で公開されている公式情報をもとに作成しています。記事中の「指示の例」「AIの動き(イメージ)」は、kintone MCPサーバーで提供されている機能をもとにした説明用の例であり、実際の応答内容や画面表示は環境・バージョン・AIモデル・クライアントのバージョンによって異なります。kintone MCPサーバーおよびCodex・ChatGPTの仕様は継続的に更新されるため、最新の機能・対応プラン・制限事項についてはGitHubリポジトリおよび各公式ドキュメントをあわせてご確認ください。各ステップのスクリーンショット(/mcp の実行画面、実際の応答画面など)は、実環境で撮影して挿入してください。認証情報の取り扱いやツール権限の設計は、自社のセキュリティポリシーに沿ってご判断ください。