2026.07.09

kintoneをClaude Codeで分析する自作kint-originツール｜AIコンテキスト管理で設定・履歴・差分を追う

majinalife.com

森田ユウゴ

kintoneを管理する原点を目指してみた！

「kintoneをClaude Codeで分析する」と題していますが、この記事の仕組みはClaude Code専用ではありません。CodexやCursorなど、ローカルファイルを読めるAIエージェントでも利用できます。取得物を非公開のGitリポジトリなどで共有すれば、Web版のChatGPT、Claude、Geminiなどから参照する運用も可能です。kintoneとAIの連携方法の一つとして参考にしてください。

この記事では、この仕組みを「kintone設定取得・差分確認ワークフローツール」と呼びます。正式名称は未定ですが、現状のコマンド名はkint-originです。

kintone系のツールには、名前に「kin」を冠する文化があり、その流れを受け継ぎながら、私たちはあえて「kint」という言葉を選びました。

似た英単語のknitには「編む」という意味がある。
単なるAIエージェントツールではなく、業務・人・データ・思想の断片を丁寧に編み合わせ、kintone活用の原点に立ち返るための存在になりたい。

kintoneの“kin”を受け継ぎながら、そこに“it”を編み込む。

kint-originは、kintoneを中心にしながら、業務改善の原点を編み直すことを目指した名前です。

と、大層なそれっぽいストーリーを書いていますが、このツールの2026年7月時点での目的は、kintoneを丸ごと復元できるバックアップを作ることではなく、取得した設定を構成管理して、人間とAIが同じ設定・履歴・差分を根拠に判断できる状態を作ることです。

ただし、実行コマンドによってはcybozu.com共通管理の氏名やメールアドレス含めてデータも全て取得できてしまいます。情報の扱いには十分注意が必要です。

本ツールは私自身のkintone開発者ライセンスの環境、リスク等を説明したうえで利用許可をいただいたお客様にのみ用いています。
本記事をご覧の関係者様はご安心ください。

森田ユウゴ

台湾で「面倒解決エンジニア」として活動している森田ユウゴです！

「面倒くさい！」を原動力に、kintoneカスタマイズやChrome拡張機能開発などを通して、日常や業務の課題をテクノロジーで解決することに注力しています。

2025年12月 kintone認定アプリデザインスペシャリスト取得
2026年01月 kintone認定カスタマイズスペシャリスト取得

ココナラやクラウドワークスなどでご相談いただけます！
下記のお問い合わせフォームからお気軽にご相談ください▼

森田ユウゴへお問い合わせ(Google Formに移動します)

kintone設定を取得し、AIと人間が読める履歴へ変える

Webブラウザからkintoneの管理画面を開けば、現在の設定は確認できます。

しかし、「いつ、何が変わったか」「納品時点からどこが変わったか」を複数アプリにまたがって説明するには、現在の画面だけでは情報が足りません。

5日目から感じていたkintoneの差分管理という課題

2026年2月に「アプリの設定変更の履歴を確認する」という機能が追加されました。のちに取得件数の増加のように機能強化はされていますが、2026年7月現在で「具体的な設定」の差分まで取得することは出来ません。また、あくまで「アプリ単体」の情報となるうえ、API経由での取得は出来ません。つまりAIエージェントと組み合わせて利用するには、まだ微妙な機能です。

チャレンジの序盤から、第三者や自分が設定を変更したあとに、変更前後を追う難しさを感じていました。

そこで5日目に作成したのは「kin-for-Git」というChrome拡張機能でした。

この動画のChrome拡張機能は、開いているアプリの情報を、そのブラウザの認証情報を使って取得する仕組みでした。単一アプリをすぐ確認したい場面では、100日目の今でも十分使えると考えています。実際、その後も自分用に細かく修正しています。

99日目のkintoneプラグイン開発ワークフローでは、開発と反映の工程をコマンドで固定しました。

そして、最終日100日目は、その前提となるkintone環境の設定を、確認可能な履歴へ変えます。

確認方法	分かること	不足すること
kintoneの画面	現在の設定	変更前との差分や取得時点の証拠
Git差分	どのファイルの何行が変わったか	変更の意味や影響範囲の判断
AIによる分析	差分の要約、関連設定の探索、確認候補	権限・保存・公開可否など人間が負う判断

この記事で紹介する「kintone設定取得・差分確認ワークフローツール」は、kintoneの設定を「コンテキスト」としてローカルに保持します。これらの情報を用いることで「差分管理」ができるだけでなく、AIエージェントがアクセスしづらいkintoneの中身を判断させることが出来るのです。

kintone設定取得・差分確認ワークフローツールでできること

「kintone設定取得・差分確認ワークフローツール」の具体的なコマンドはkint-originとしていて、対象ドメインの設定をAPI経由で取得し、jsonを中心としたテキストファイルとして保存するNode.js製ローカルCLIです。

取得単位を、全体・スペース・アプリ・共通管理のユーザー情報から選べます。初回に全体像を保存し、2回目以降は変更されたアプリを中心に取得することで、Gitで追える差分へ変換します。

一部、動画の内容と重複しますが、主な取得系コマンドは次のとおりです。

コマンド	取得する範囲	使う場面
`kint-origin index`	全アプリの索引	最小限のAPIリクエストで対象アプリを把握する
`kint-origin app --id %id%`	指定した1アプリの設定	調査対象が決まっているときに必要な範囲だけ取得する
`kint-origin spaces --id %id%`	指定スペースと配下アプリ	案件や部門など、スペース単位で確認する
`kint-origin kintone`	ドメイン内のスペースとアプリ	kintone側の設定をまとめて取得し、削除も確認する
`kint-origin users`	cybozu.com共通管理のユーザー・組織・グループ	共通管理側の変更履歴が必要なときだけ取得する
`kint-origin all`	kintone設定と共通管理ユーザー	初回など、ドメイン全体の状態を保存する

上記は一例です。他にもレコードと添付ファイルはcli-kintone経由で取得するなど、公式ツール類に積極的に依存した作りにしています。（あくまで公式ツールの機能を補うポジションとして開発）

現在は自分用のツールとして、サイボウズのAPIラボで提供されている開発検討中のAPIにも対応しています。対象機能を有効にした環境では、アプリに追加されているプラグインの設定も取得できます。APIラボの機能は正式提供前のため、仕様変更や提供終了の可能性を前提に扱います。

参考：アプリに追加されているプラグインの設定情報を取得する

https://cybozu.dev/ja/kintone/docs/api-lab/rest-api/apps/get-app-plugin-config

これらのコマンドはサイボウズの各種サービスに依存するため、パフォーマンスやAPI実行回数上限など、細かい点にも配慮して、最小限の実行回数、正しいAPIを正しい間隔で使うよう、内部でチューニングをしています。

【実践編】kintone設定の取得結果とGit差分を検証する

ここからは、kint-origin allによる初回取得、同じ環境の再取得、1項目を変更して元へ戻すまでの結果を紹介します。

初回全量取得と2回目以降の差分取得を比べる

検証では、空の保存先から始める初回取得と、同じ環境をもう一度取得する2回目以降を分けました。実行したコマンドは次のとおりです。

kint-origin all

allではアプリ設定に加え、共通管理のユーザー・組織・グループも取得されます。レコードと添付ファイルは今回の取得対象に含めていません。保存された構成は、概ね次のようになります。名称やIDは説明用に置き換えています。

data/
├─ kintone/
│  ├─ index/apps.json
│  └─ apps/app-000/
│     ├─ form/fields.json
│     ├─ views/views.json
│     ├─ acl/app_acl.json
│     └─ app_settings/settings.json
└─ cybozu-user/
   ├─ users.json
   ├─ organizations.json
   └─ groups.json

2026年7月1日に、私個人の単一環境で測定した結果です。

操作	実測結果	確認できたこと
初回 `kint-origin all`	520.8秒≒約9分。 138アプリ、apps API 2回、space 6回、appDetail 2,346回、2,665ファイル、約2.70MB	空の保存先からの一括取得には時間がかかる
2回目 `kint-origin all`	4.289秒。 138アプリすべてskip、appDetail 0、失敗0	同一状態ではアプリ詳細の再取得を避けられた ※API実行数もCLIのインデックス機能と組み合わせることで最小限に。

当然アプリ数、設定量、APIの実行状況、ネットワーク、サイボウズのサービス環境状況などで結果は変わります。初回と差分が無い2回目以降で処理時間に大きな差が出ました。

1項目の変更・取得・復元を確かめる

次に、検証用のアプリだけで説明文を一時的に変更しました。他の137アプリは読み取りだけで、設定変更はしていません。

操作	実測結果	Gitでの結果
アプリ変更後の取得	3.977秒。説明文1項目が変化	12行の差分
説明文を元に戻した後の取得	3.771秒。リモートが変更前と完全一致	アプリ設定フォルダの差分0
同一状態で再取得	3.598秒	アプリ設定フォルダの差分0

純粋にGETでjsonを取得すると、毎回差分が発生する箇所があります。このような部分については独自にマスキングなどをすることで実データに変更が無い場合、gitの差分に検知されないような作りにしています。

Git差分とClaude Codeで設定変更を分析する

kintoneとAIエージェントの連携では、取得した設定のGit管理が前提条件と言っても良いです。Gitで履歴と差分を固定し、それをAIエージェントに読ませることで、kintone設定をフル活用できます。

Git差分で変更箇所を絞る

設定をJSONなどのテキストファイルにすれば、Gitで変更前後を比較できます。先ほどの検証では、説明文の変更が12行の差分として現れています。

AIエージェントには「前回のコミットから何が変更されましたか？概要を教えてください」この一言を投げるだけでdiffを解説してくれます。

画面のスクリーンショットだけでは、対象が多いほど比較が難しくなります。そもそもスクショしてAIエージェント用に準備が面倒くさい…。

「kintone設定取得・差分確認ワークフローツール」を使えば、変わったファイルと行に確認範囲を絞れます。

Claude Codeには必要な設定だけを読ませる

Claude Code、Codex、Cursorなどには、ローカルに保存したファイルやGit差分を指定して、他にも次のような分析を依頼できます。

変更された設定をレビューしてもらう(kintone AIはアプリ単体、全体として命名に整合性があっているか、その他細かなコンテキストと合わせて判定)
変更によって影響を受けそうなカスタマイズを探す
意図しない変更の候補を挙げる
人間が確認すべき箇所を整理する

AIへ「問題を直して」とだけ依頼するのではなく、Git差分、対象アプリ、確認したい観点を一緒に渡します。AIの役割は、変更内容を断定することではなく、人間が確認する範囲を狭めることです。

たとえば「この差分で変わった権限と、影響を受ける操作を整理してください。推測とファイル上の事実を分け、人間が確認すべき項目を挙げてください」と依頼すれば、差分を根拠にした確認リストを作れます。Claude Codeに限らず、ローカルファイルとGit差分を参照できるAIエージェントで同じ考え方を使えます。

このワークフローの適用範囲と安全な使い方

MCPのライブ操作と、取得時点の履歴確認を使い分ける

公式のkintone MCPサーバーは、生成AIツールからkintoneへ接続するためのローカルMCPサーバーです。公式情報では、アプリ情報・設定情報の取得、レコードの取得・追加・更新・削除、フォームや一般設定の変更、設定反映などが案内されています。

これに対して、kintone設定取得・差分確認ワークフローツールは、取得した時点のファイルとGit履歴を残して読むための仕組みです。MCPの代替ではなく、目的が異なります。

観点	公式kintone MCP	設定取得・差分確認ワークフロー
中心となる用途	AIとの対話からkintoneを取得・操作する	取得時点の設定を履歴と差分で確認する
状態	接続先の現在状態を扱う	ローカルへ保存したスナップショットを扱う
変更操作	追加・更新・削除・設定反映を含む	この記事では取得と確認に限定する
主な注意点	AIに許す操作と権限の範囲を決める	保存する情報とAIに渡す情報を分ける

特に大きいのは、MCPではアプリへのREST APIが都度発生するのに対して、kintone設定取得・差分確認ワークフローツールは取得後はデータとしてローカルに保存されるためkintoneへの通信が発生しないことです。

kintone REST APIは、アプリやレコード、スペースなどを操作するAPIです。MCPや取得ツールの裏側では複数回のAPIリクエストが行われる場合があるため、AIへの質問1回とAPIリクエスト1回を単純に同一視はできません。利用する機能と処理内容を個別に確認します。

バックアップとは言い切らず、読み取りと書き込みを分ける

実はkintoneからpullするだけでなく、pushする仕組みも開発しています。

kintoneのアプリ設定やユーザー情報を取得して展開できるので、ある意味ではバックアップ・デプロイツールに分類されるかもしれません。

ただ、展開コマンドによる影響は大きいため、より検証が必要です。意図的に機能を絞っています。今後の私のAI(Action Item)です。

【注意】AIへ渡す情報と、人が判断する工程を分ける

今回は仕組みの動作確認として、私個人の検証環境で取得した全ファイルをAIが読める状態にしました。しかし、allコマンドにはユーザー・組織・グループ情報も含まれます。個人情報の扱いをAIへ丸投げするリスクは高く、通常の設定問題ではユーザー情報が直接解決に役立つ場面も多くありません。

実運用では、まずGit差分で変更箇所を絞り、必要な設定ファイルだけを選ぶか匿名化してAIへ渡す必要があります。

allで得られるユーザー・組織・グループ情報は、Git差分の対象として保存する価値がある場合でも、AIへそのまま渡す必要はありません。保存先のアクセス権、Gitリポジトリの公開範囲、保持期間、削除方法を決め、AIには問題解決に必要な最小範囲だけを渡します。認証情報は取得物やリポジトリへ含めません。

担当	固定・支援できること	人が判断すること
CLI	設定の取得、保存形式、同一状態のスキップ、同じ手順の再実行	取得対象、実行権限、保存場所、保持期間
Git	変更ファイルと行の記録、変更前後の比較	差分が意図した変更か、どの版を基準にするか
AI	差分の要約、関連箇所の探索、確認候補の提示	AIへ渡す範囲、匿名化、個人情報の取り扱い
人間	取得物と分析結果を根拠に判断する	書き込みの可否、戻し方、本番反映、保存物の削除

CLIは手順を再現可能にしますが、権限や個人情報まで自動で正しく判断してくれるわけではありません。対象範囲、権限、保存、削除、AI利用、書き込み時の戻し方を人間の確認事項として残すことが、このワークフローの前提です。

導入が向いているケースと類似開発の相談先

このワークフローが向いているのは、複数アプリの設定変更をGitで追いたい方、納品時点と現在の差分を確認したい方、Claude Codeなどへ根拠となる設定ファイルを読ませたい方です。一方、レコードや添付ファイルまで含む完全なバックアップ製品を探している方や、AIに本番変更を自動実行させたい方には、そのまま当てはまりません。

99日目のkintoneプラグイン開発ワークフローが「開発と反映の工程」を固定する取り組みなら、今回の仕組みは「環境の設定と変更履歴」を確認可能にする取り組みです。チャレンジ全体はkintone 100日チャレンジ一覧から確認できます。

プラグイン開発で利用しているKinDevSTについても別記事にまとめています。