こんにちは。CData Software Japan の色川です。

企業での AI 活用は、本格化の一途ですよね。試しに使ってみる段階から、業務の中で日常的に使う段階へと進んでいる企業も多いかと思います。

CData にも「AI から業務のデータを使いたい」というご相談をたくさんいただきます。CData では業界最多級のデータソースへの接続をサポートしていますが、その中でも特にご相談が多いもののひとつが kintone です。Claude や ChatGPT、Copilot など自分の好みの AI から、kintone や他の業務システムのデータを使いたいというニーズは大きく伸びていて、CData Connect AI へのお問い合わせも急増しています。

AI から kintone のデータを確かめたり集計したりすることが当たり前になってくると、次に気になってくるのが、kintone の先にある業務システムとの連携部分です。kintone で承認された受注を基幹システムに登録し、受注番号や出荷の結果を kintone に戻す。柔軟で素早く業務アプリを作れる kintone は、こうした基幹システムとの連携とセットで活用いただいているケースが少なくありません。

では、こうした基幹システムとの連携部分まで、AI に丸ごと任せてしまうのがよいのでしょうか。便利そうな一方で、基幹システムへの書き込みとなると、少し慎重になりたいところです。

この記事では、kintone と基幹システムの連携を、Claude などの AI から安全に運用する構成をご紹介します。全体の構成は、以下のようなイメージです。

この記事の狙い（背景）

例えば Claude に「今日承認された受注を、基幹システムに流しておいて」と頼んだとします。kintone と基幹システムの連携を一度でも作ったことがある方なら、次のようなポイントが気になるのではないでしょうか。

もちろん、AI がその場でデータを探したり、1 件を確認して直したりする使い方は、とても便利です。よく使う問い合わせや操作を、あらかじめツールとして用意しておく使い方も、安心して任せやすい方法です。気になるのは、「複数のシステムをまたいで、定型の手順で書き込んでいく一連の業務フロー」を、その都度 AI に組み立てさせることです。

そこでこの記事では、「定型の連携は人がフローとして作っておき、AI にはそのフローを動かして確かめる役だけを渡す」という構成を考えてみます。AI に渡すのは、人が設計した連携フローの「フローを実行する権限」と「状況を参照する権限」だけ、というイメージです。すでに CData Arc で動いている連携フローがあれば、作り直すことなく、そのまま AI からの運用に乗せられるのもポイントです。

AI から使う道具の使い分け

AI から kintone や基幹システムを扱うときの選択肢は、ひとつではありません。この記事では、以下のように使い分けて考えています（この記事独自の整理です）。

その場でのデータの確認や更新は kintone の公式 MCP サーバーや Connect AI、基幹システムへの登録のように、複数のシステムをまたぐ一連の連携は CData Arc のフロー、という住み分けです。どれかひとつを選ぶというよりも、組み合わせて使っていただけるかと思います。

例えば、Connect AI から kintone と基幹システムのデータベース（社内にある場合は Connect Gateway 経由）への接続には、「Select」の権限だけを与えておき、AI には自然言語でデータの状態を確かめさせます。「承認済みなのに、基幹システムに届いていない受注はある？」といった確認です。そのうえで、状態に応じて基幹システムへの登録や結果の書き戻しが必要になったら、その処理は Arc にあらかじめ定義したフローに任せます。自然言語で探索するのは Connect AI、堅牢に実行したいデータ更新は Arc のフロー、と役割を分けておけば、基幹システムへの書き込みの経路を Arc に一本化することができます。

CData Arc

CData Arc は、CData 製品の中で「自動化/Automate」を担うデータ連携ツールです。「B2B 連携をもっとシンプルに」をコンセプトに、ファイル連携 & DB 連携 & API 連携といった B2B 連携に必要なすべてをノーコード・ローコードでつなぐことができるプラットフォームです。

CData Arc の組み込み MCP サーバー

Arc には、Claude Desktop などの AI クライアントから接続できる「組み込み MCP サーバー」が含まれています。Arc 2026 Q3（26.3）で読み取り専用のツールとして登場し、2026 Q4（26.4）で運用系のツールが加わりました。

この記事の執筆時点（Arc 26.4）では、組み込み MCP サーバーは「運用」のためのツール群として提供されています。フローの設定には手を加えず、あらかじめ定義したフローを動かしたり、状況を確かめたりするための仕組みです（組み込み MCP サーバーは今後の機能拡充も予定されています）。だからこそ、基幹システムとの連携を AI から安全に運用する仕組みとして、とてもフィットします。

この記事の構成で特に大事なのは、以下の点です。

• 18 個のツール : 15 個は読み取り専用です（メッセージの検索・追跡、失敗の診断、ワークスペースの健全性の確認など）。運用系のツールは 3 個（コネクタの実行、メッセージの再キュー、クリーンアップ）です。

• 設定はそのまま : 運用系のツールが変えるのは実行時の状態だけで、コネクタの作成や設定は、これまでどおり人が Arc の画面で行います。ただし、フローを動かせば、その先の kintone や基幹システムへの書き込みは、フローに定義したとおりに行われます。

• 確認が必要 : 運用系のツールは、利用者の確認が取れていないと実行されません。ただし、確認が取れたかどうかを判断するのは AI です。人の承認を確実に挟むには、AI クライアント（この記事では Claude Desktop）のツール実行の許可と組み合わせて使います。

• 権限と監査 : Arc のユーザーの権限がそのまま効きます。運用系のツールの実行は、Arc の監査ログに記録されます。

• 秘密情報は出さない : パスワードやトークン、秘密鍵はツールの応答でマスクされます。kintone や基幹システムの資格情報が、AI に渡ることはありません。

もうひとつ、コネクタを実行するツールで AI が指定するのは、主にどのコネクタを動かすか、既にあるどのファイルやメッセージを処理するか、です。この記事のような kintone やデータベースのコネクタでは、取得の条件や業務データは、フローに定義したものがそのまま使われます。AI が動かすのは「人が決めた条件のフロー」そのもの、という安全のための仕組みと考えていただくと良いかと思います。

検証した環境

この記事では、kintone と基幹システムをつなぐ 2 つのフローが動いている CData Arc に、Claude Desktop を組み込み MCP サーバーでつなぎます。Claude がつながるのは Arc の MCP サーバーだけで、kintone や基幹システムには直接つながりません。

AI から動かすフローは、以下の 2 つです。kintone で承認された受注を基幹システムの取込用テーブルに登録するフローと、基幹システムでの結果（受注番号や出荷の情報）を kintone に書き戻すフローです。フローの作り方は「CData Arc で、kintone のプロセス管理と基幹システムを連携する」で詳しくご紹介しています。

普段の連携は、これまでどおり Arc のスケジューラによる定期実行に任せます。この記事での AI の出番は、「いまの状況を知りたい」「次の定期実行を待たずに、いますぐ反映したい」など、人が気になったときをイメージしています。

事前準備

1. AI 用のロールとユーザーを作る

最初に、AI 用のユーザーに割り当てるロールを作ります。Arc の「設定」→「ロール」で「ロールを追加」し、ポリシーを以下のように設定しました。

続いて、「設定」→「ユーザー」で AI 用のユーザーを作り、このロールを割り当てます。ユーザーの「API アクセス」タブで管理 API へのアクセスを有効にすると、authtoken が発行されます。この authtoken は、次の手順で Claude Desktop から接続するときに使います。

なお、Arc の管理 API と MCP サーバーへのアクセスは、「設定」→「セキュリティ」の「グローバルで信頼された IP の範囲」で保護されています。AI クライアントを動かす PC のアドレスを、ここに追加しておきます。これを忘れると、authtoken が正しくても MCP サーバーへの接続は拒否されます。AI 用のユーザーだけに許可したい場合は、ユーザーの「信頼された IP の範囲」タブで、そのユーザーに限って追加することもできます。

2. Claude Desktop に Arc の MCP サーバーをつなぐ

Claude Desktop の設定ファイル（Windows の場合は %APPDATA%\Claude\claude_desktop_config.json）に、Arc の MCP サーバーを追加します。設定ファイルに登録した MCP サーバーは、Claude Desktop が手元で起動するプロセスとやり取りするので、mcp-remote を経由して Arc の MCP サーバーにつなぎます。authtoken は設定ファイルに直接書かず、ヘッダーを書いたファイル（--header-file）から読み込むようにしました。

{"mcpServers":{"arc-mcp":{"command":"cmd","args":["/c","npx","-y","mcp-remote","https://\u003CArc \u306E\u30DB\u30B9\u30C8\u003E:\u003C\u30DD\u30FC\u30C8\u003E/mcp.rsc","--transport","http-only","--header-file","C:\\Users\\\u003C\u30E6\u30FC\u30B6\u30FC\u540D\u003E\\.cdata\\arc-mcp-headers.txt"]}}}

ヘッダーのファイルには x-cdata-authtoken: <AI 用ユーザーの authtoken> の 1 行だけを書き、自分のアカウントだけが読めるようにしておきます。設定の詳細は、ヘルプドキュメントの「Remote MCP Server」を参照してください。

編集が終わったら Claude Desktop を起動し、新しいチャットの「ツール」の一覧に「arc-mcp」が表示されれば準備完了です。

[補足]: カスタムコネクタとして登録する場合

Claude では、設定ファイルを使わずに、「カスタムコネクタ」としてリモートの MCP サーバーを登録することもできます。Arc の MCP サーバーは authtoken をリクエストヘッダーで受け取るので、カスタムコネクタの「Request headers」に設定する形になります。

ただし、カスタムコネクタの場合、MCP サーバーへの通信は利用者の PC からではなく、Anthropic のクラウドから行われます。そのため、Arc をインターネットから到達できる場所に置き、Anthropic が公開している送信元の IP アドレスを「グローバルで信頼された IP の範囲」やファイアウォールで許可しておく必要があります。Anthropic の送信元アドレスは Claude の利用者全体で共通なので、許可したあとは authtoken が実質的に唯一の鍵になります。また、AI 用ユーザーの authtoken は、Claude 側のコネクタの設定に保存されることになります。

基幹システムとつながる Arc を社内のネットワークに置いている場合は、この記事のように設定ファイル（mcp-remote）からつなぐ方が、Arc を外部に公開せずに済みます。一方、Arc をクラウド上で運用していて、インターネットからのアクセスを前提にできる場合は、カスタムコネクタの方が手軽です。どちらがよりフィットするかは、Arc の配置や社内のセキュリティの方針にあわせて選択してください。詳しくは Claude のヘルプ「About custom connectors using remote MCP」や、Anthropic の「IP addresses」を参照してください。

Claude から連携を運用してみる

それでは、Claude Desktop から連携を運用してみましょう。

この記事では、検証の流れを分かりやすくするため、連携フローの起点のコネクタの自動実行を止めておき、今日の 14 時に管理者が手動で一度実行しました。kintone で承認された受注 2 件が基幹システムに登録され、その結果が kintone に書き戻された状態です。そのあと基幹システム側で、以前に登録済みの受注 KT-000006 を出荷済みにしておきました。また、Claude Desktop のコネクタの設定で、arc-mcp の trigger_connector（コネクタの実行）は「承認が必要」にしています。

1. 連携の状況を聞く

まずは「Arc の kintone-approval ワークスペースで、今日の連携の状況を教えて。エラーや滞留はある？」と聞いてみます。

Claude は Arc のメッセージの記録をもとに、エラーや滞留の有無、処理の件数、承認データの取込から結果の書き戻しまでのフローの流れを整理してくれました。起点の 2 つのコネクタで自動実行が無効になっていることにも気づいて、「定期ポーリングで回す想定であれば、このままでは自動では取り込まれません」と指摘しています。Arc の管理画面に慣れていない担当者でも、状況をつかみやすいのではないでしょうか。

2. エラーの有無を聞く

続いて「今日、基幹システムへの登録でエラーになった受注はあった？あれば理由を教えて」と聞いてみます。

今日の 2 件は、どちらも基幹システムに登録済み、と答えています。注目したいのは最後の段落で、「基幹側でエラーになった場合も、Arc の転送自体は Success と記録される。だから結果ステータスの値まで確認した」と説明しています。Arc の処理としての成否と、基幹システムでの業務的な結果を分けて確かめてくれているわけです。

ここで Claude が受注番号や結果ステータスまで答えられたのは、Arc に残っているメッセージの記録（ヘッダーやトランザクションログ）から読み取っているためです。この記事のフローでは、基幹システムの結果をメッセージのヘッダーに載せていて、kintone のコネクタのトランザクションログにも、書き込んだ値が残ります。AI 用のユーザーには、許可したワークスペースのこうした記録が見えて、回答のために AI クライアントに渡る、ということです。AI にどこまで見せるかは、AI 用のロールで許可するワークスペースとあわせて、Arc のログや保持の設定でも考えておくと良いと思います。

3. 基幹システムの結果を、いますぐ kintone に反映する

次に「基幹で出荷済みにした受注を、いますぐ kintone に反映して」と頼んでみます。

Claude は、結果を取得する起点のコネクタ（基幹_結果_Select）の「受信」を実行しようとします。trigger_connector を「承認が必要」にしているので、Claude Desktop では、実行する前にこのように許可を求められます。

「一度だけ許可」を選ぶと実行され、Claude が結果を報告してくれます。

kintone を開くと、受注 KT-000006 に出荷日と送り状番号が書き戻され、ステータスも「出荷済み」に進んでいることが確認できます。

Arc の「アクティビティ」でこのメッセージを開くと、基幹_結果_Select から XMLMap_結果、kintone_結果_書き戻し、XMLMap_ステータス、kintone_ステータス更新まで、どのコネクタをどう流れたかが確認できます。AI が動かしたのは、あくまで人が設計したフローです。どの条件で取得し、どう変換して、どこに書き戻すかは、フローに定義したとおりです。

冒頭で気になる点に挙げた二重登録も、フローの側で防いでいます。取込用のテーブルは kintone のレコード番号をキーに Upsert で書き込み、登録のフローが拾うのは、基幹受注番号がまだ入っていない承認済みの受注だけです。AI が同じフローを続けて動かしても、基幹システムに同じ受注が 2 件入ることはありません（詳しくは「CData Arc で、kintone のプロセス管理と基幹システムを連携する」の「二重に登録されないための仕組み」でご紹介しています）。

4. 実行した人を聞く

続いて「さっきの実行は、いつ、誰が行った？」と聞いてみます。

Claude は自分が実行したことを説明しつつ、「Arc 上でどのユーザーとして記録されたかは見えないので、管理画面で確認してください」と答えています。実は、アプリケーションログやリクエストログを読むには Standard または Admin のロールが、監査ログを見るには Admin のロールが必要です（どちらも、メッセージごとの記録とは別の、Arc 全体のログです）。この記事では AI 用のユーザーに、これらの権限を与えていません。26.4 で強化された、ログとメッセージを紐付けた原因の調査まで AI に任せたい場合は、ログを読めるロールが必要です。そのぶん AI に見える範囲も広がるので、用途にあわせて選んでください。

もうひとつ、回答の最後で Claude は「いますぐ反映して」という指示を、実行の承認とみなしたと説明しています。先に書いたとおり、運用系のツールで確認が取れたかどうかを判断するのは AI です。だからこそ、人が承認する役目は、先ほどの Claude Desktop の許可の画面が担っています。

では、記録はどうなっているでしょうか。管理者が Arc の「アクティビティ」→「ログ」の「監査ログ」を開いてみます。AI 用のユーザーで絞り込むと、MCP サーバーを通じたアクセスが 1 回ずつ記録されていて、その中にコネクタの実行（trigger_connector）も並んでいます。

trigger_connector の記録を開くと、どのワークスペースのどのコネクタを、どの方向で動かし、何件が成功したかまで確認できます。MCP サーバーを通じて AI が起動したものは、このように監査ログで追いかけることができます。

実行するのは AI、承認するのと記録を確かめるのは人、という、この記事で想定した役割分担になっています。

5. 取得の条件の変更を頼む

最後に「基幹_結果_Select の取得条件を変えて、すべての受注を対象にして」と頼んでみます。

Claude は「今使える Arc の MCP ツールでは、コネクタの設定を変更できません」と答えました。組み込み MCP サーバーのツールは実行時の状態を動かすためのもので、AI 用のユーザーにもフローを編集する権限を与えていないためです。

さらに Claude は、全件を対象にすると kintone の値が毎回上書きされることや、完了済みの受注にもステータスの更新が再実行されて失敗が大量に出るおそれがあることを挙げたうえで、「過去分を一度だけそろえたいなら、恒久的に設定を変えるより、開始日時を過去に変えて履歴をリセットし、一度だけ手動実行する方法がおすすめ」と提案してくれました。条件を変えるのは人、という線引きが、画面でもはっきり見える場面です。

運用で気をつけたいこと

・AI の回答は、不完全だったり不正確だったりすることがあります。大事な判断は、Arc の画面で確かめてください（Arc のヘルプドキュメントにも明記されています）。

・この記事のような kintone やデータベースのコネクタでは、コネクタの実行時に取得の条件を渡せません。「この取引先だけ」のような細かい条件が必要なら、フローの側で表現しておきます。

・AI 用のユーザーには、許可したワークスペースのメッセージの記録（ヘッダーやトランザクションログ）や、保持しているメッセージのファイルの中身が見えます。これらは、回答のために AI クライアントに渡ります。AI に見せる範囲は、ロールとあわせて、Arc のログレベルや保持の設定でも考えておきます。

・authtoken は、設定ファイルに直接書かずに保管します。AI 用のユーザーには、必要なワークスペースと操作だけを許可します。

・運用系のツールは、承認のうえで実行されるように使います。この記事のように AI クライアントの設定で「承認が必要」にしておき、「常に許可」にしないことをおすすめします。

まとめ

この記事では、kintone と基幹システムの連携を、Claude などの AI から安全に運用する構成をご紹介しました。

定型にしたい連携業務は人が CData Arc のフローとして作り、AI にはそのフローを動かして確かめる役だけを渡す、という構成を、実際の画面とあわせてイメージいただけたかと思います。現時点における AI と基幹システムの付き合い方のひとつと言えるかも知れません。その場でのデータの確認や更新は kintone の公式 MCP サーバーや CData Connect AI、基幹システムへの登録のように、複数のシステムをまたぐ一連の連携は CData Arc、と使い分けていただけると思います。

この記事で題材にした連携フローの作り方は「CData Arc で、kintone のプロセス管理と基幹システムを連携する」で詳しくご紹介しています。CData での kintone 連携方法に関する全体像については、「kintone ソリューションページ」や「kintone の連携方法を総まとめ」もあわせてごらんください。

CData Arc はシンプルで拡張性の高いコアフレームワークに、豊富なMFT・EDI・エンタープライズコネクタを備えたパワフルな製品です。業界最多級のコネクタにより、業種業界を問わず、企業のデータ連携自動化で幅広く活用いただけます。

皆さんのつなぎたいシナリオでぜひ CData Arc を試してみてください。

kintone と基幹システムの連携や、AI からの連携の運用を検討されている方は、お気軽にセールスまでお問い合わせください。構成のご相談から承ります。

製品を試していただく中で何かご不明な点があれば、テクニカルサポートへお気軽にお問い合わせください。

この記事では CData Arc™ 2026 - 26.4.9792.0 を利用しています