「kintoneにデータは溜まっているけど、うまく活用できていない」
「AIツールとの連携って、どうやって始めればいいんだろう」
社内でkintoneを運用している情報システム担当者の方なら、こうした悩みを一度は感じたことがあるのではないでしょうか。私自身、kintoneの市民開発を推進する立場として、日々増え続けるアプリの品質管理に頭を抱えていました。
そんな中、Difyの公式kintoneコネクタが実装されたことをきっかけに、実際にAIを活用したアプリ設定の自動レビューシステムを開発してみました。この記事では、その過程で得られた技術的な知見と、運用上の壁、そして今後の可能性について、実務担当者の視点から詳しくお伝えします。
※本記事はkintoneに保存した日々の作業メモを元に、Dify（AIエージェント）を活用して構成・執筆しています。
kintone×Dify連携を検討する前に知っておくべき基礎知識
Difyとは何か
Difyは、LLM(大規模言語モデル)と外部ツールをノーコードで連結できるAI開発プラットフォームです。
単なるチャットボット構築ツールではなく、条件分岐や繰り返し処理を伴う複雑なワークフローの自動化が可能な点が特徴です。
私がDifyに注目したのは、社内でClaude、n8nなどのAI活用が活性化していた時期のこと。
業界イベントでDify×kintone連携の情報を得て、すぐに検証を開始しました。従来のAPI連携と異なり、ノーコードで複雑な業務フローを構築できる可能性に魅力を感じたのです。
kintone公式コネクタの実装で何が変わったのか
Difyの公式kintoneコネクタが実装されたことで、データの取得・更新プロセスの構築コストが大幅に低下しました。これまで複雑なAPI連携が必要だった処理が、ノーコードで実現できるようになったのです。
主な利点は以下の通りです：
- 構築コストの大幅低下
- ノーコード化による実装時間短縮（簡易的なチャットボットであれば10分程度で作成可能）
- kintoneポータルへの埋め込みがスムーズに実施可能
この手軽さは、かつてkintoneが「脱エクセル」を実現した時の感覚に近いものがあります。
初期検証で分かった構築の容易さと実務適用のギャップ
ただし、基本構築が容易である一方で、実務に即した高度な自動化を実現するには、Difyの内部構造やワークフロー制御の習得が不可欠だと感じました。
特に、複数のアプリを横断した処理や、条件に応じた分岐処理を組み込む際には、ノーコードツールとはいえ、ある程度の技術的理解が求められます。
この「簡単に始められるが、奥が深い」という特性は、kintoneと非常に似ています。だからこそ、kintone運用経験者にとっては親和性が高く、学習曲線も緩やかだと感じました。
kintoneアプリ設定の自動レビューAIを開発した背景と実装
市民開発の拡大で顕在化したアプリ品質管理の課題
私たちの組織では、業務ユーザーにもkintoneアプリの市民開発を推進しています。アプリ作成ルールは定めているものの、日々アプリが増えていく中で、全てを人力でチェックすることが現実的に難しくなっていました。
具体的には、以下のようなルールを設けています：
- 有効フラグを作成する（削除権限を無効にするため）
- 重複禁止設定の確認（複数項目で重複禁止になっている場合、不都合が多い）
- フィールドコードは半角英数字
- レコード削除権限をはずす（kintoneはレコード削除すると永久に失われるため）
これらを毎回手作業で確認するのは、時間的にも精神的にも大きな負担でした。
公式レビューAIで期待通りの結果が得られなかった理由
kintone公式のアプリ設定レビューAIも存在していますが、実際に使ってみるといくつかの課題が見えてきました。
例えば、有効フラグ項目が存在するのに、設定不備として判定されるなど、期待通りの出力が得られません。また、毎回回答が異なることも問題でした。
さらに、1つずつしかレビューができないため、複数のアプリを一括でチェックしたい場合には時間がかかりすぎるという実務上の制約もあります。
Difyワークフローによる一括レビューの技術構成
そこで、Difyを使って一括レビューできるAIアプリの開発に着手しました。
ワークフローの全体像は以下の通りです：
- kintoneから複数のアプリIDを取得
- アプリID毎に、フィールド情報やアクセス権情報を取得
- LLMでレビュー
- 結果をkintoneに返す
- 終わるまでイテレーションで繰り返す
kintoneアプリの構成には、テンプレートにある「アプリ管理」を流用し、レコードはCSVアプリ一覧の内容をレコード登録する形にしました。
使用したノードは、kintoneレコード取得、コード実行、イテレーション、kintoneアクセス権取得（カスタムノード）、kintoneフィールド情報取得（カスタムノード）、LLM、kintoneレコード更新です。
カスタムノードでkintoneアクセス権取得機能を実装した手順
公式プラグインにアクセス権取得機能が含まれていなかったため、Difyのカスタム機能で取得するツールを作成する必要がありました。
具体的には、kintoneのAPIリファレンスをGeminiに読み込ませて、OpenAPI仕様のスキーマを出力してもらいました。OpenAPI仕様テンプレートをベースに、必要な情報を構造化していく作業です。
この過程で、AIを使ってAPI仕様を理解させ、それを別のAIツールで活用するという、メタ的な構造に面白さを感じました。
AIが複数のレイヤーで連携する時代が来ていることを実感できたのです。
LLMプロンプト設計|4つのレビュー項目と対象外フィールドの定義
LLMに渡すプロンプトでは、以下の4つの確認項目を明確に定義しました：
- 有効フラグ項目の確認：チェックボックス、フィールド名「有効フラグ」、項目「yes」、初期値「yes」、フィールドコード「valid_flag」
- 重複禁止設定の確認：重複禁止フィールドが1つのみ、社員番号・店舗コードなど適切か確認
- フィールドコードの確認：半角英数字とアンダースコアのみ、日本語なし
- アクセス権設定の確認：recordDeletableの値がfalse
また、以下のシステムフィールドは対象外として明示しました：
- カテゴリー
- ステータス
- レコード番号
- 作成日時
- 作成者
- 作業者
- 更新日時
- 更新者
出力時の注意点として、XMLタグを含めない、改行は実際の改行、バックスラッシュやスラッシュは出力しないといった細かい指定も行いました。
これらの指定がないと、出力結果がkintoneに書き戻す際に正しく表示されないためです。
なお、kintoneの情報を都度LLMに渡すとトークン消費が多くなるため、JavaScriptのコード実行ノードで必要な情報だけを抽出する処理を挟んでいます。
例えば、total_countだけを取り出して次の処理に渡すといった工夫です。
AIモデル別の精度差|SonnetとHaikuの出力比較
同じプロンプトでも、使用するAIモデルによって出力の詳細度が異なることが分かりました。
Sonnetの特性：
- フィールドコードの修正例まで具体的に出力される
- 例：「レコードの最終更新日」というフィールド名に対して「record_last_updated」といった修正例まで提示
- 精度が高く、詳細な指摘が得られる
Haikuの特性：
- フィールド項目までの出力にとどまり、詳細度は劣る
- 処理速度が速い
- コストが低い
実務運用では、精度とコストのバランスを考慮してモデルを選択することが重要です。
初期検証ではSonnetで詳細な出力を確認し、本格運用ではHaikuで効率化するといったアプローチも有効でしょう。
実装後に直面した2つの運用上の壁
設計通りにレビューしてくれるようになり、OK/NGが一目でわかり、具体的にどこを修正すればよいのかも明確になりました。
しかし、実際の運用に向けては、2つの大きな壁が立ちはだかりました。
Webhook利用時の永久ループ問題|同一レコード書き戻しによる循環参照
kintoneの「レコード編集」をWebhookのトリガーに設定している場合、永久ループが発生する可能性があります。
具体的な発生フローは以下の通りです：
- ユーザーがレコードを保存する
- Webhookが飛び、DifyのAIが動く
- Difyが計算結果やレビュー結果を、同じレコードの特定のフィールドに書き戻す
- kintone側は「レコードが更新された」とみなし、再度Webhookを飛ばす
- 1〜4が永遠に繰り返される
この問題は、ステータスの更新やアプリ循環の更新など、Webhookを使用する際に常に意識しなければならない課題です。同一レコードへの書き戻しによる循環参照を避けるための設計が不可欠だと痛感しました。
対策としては、以下のようなアプローチが考えられます：
- 更新対象フィールドを限定する
- ステータスで処理済みを判定する
- 別レコードに結果を記録する
外部AIに渡すユーザー権限のジレンマ|アプリ設定閲覧とレコード操作権限の分離不可
もう一つの大きな壁が、権限設計の問題です。
外部AI(DifyやClaude等)にkintoneのアプリ構造を理解させつつ、セキュアに運用する際の権限ジレンマに直面しました。
アプリの設定情報を一括取得するには「kintone共通管理者」権限が必須です。しかし、これを与えるとシステム共通管理画面の全操作が可能になり、ガバナンス上のリスクが極めて大きくなります。
一方、アプリごとに権限を振る方法もありますが、全てのアプリに設定作業が必要になり、アプリ数が多い場合は現実的ではありません。
各ユーザー権限における「アプリ設定閲覧」の限界も明確になりました：
システム共通管理者の場合、全アプリのアプリ設定が閲覧可能ですが、スペースに所属しなければレコード操作は防げるものの、システム共通管理画面の権限そのものを外部ツールに渡すのはセキュリティ上極めて危うい状況です。
システム管理者や通常ユーザーの場合、アプリ設定を見るには「スペースへの所属」および「アプリ管理権限」が必要ですが、スペースに所属した時点でレコード操作が可能になってしまいます。
理想的には、「レコードの取得・登録・更新・削除」といったデータ操作権限を一切持たせない、あるいは明確に除外できる設定情報参照(Read-only)への特化が求められています。
全アプリの構造(フィールド情報・設定値)のみを取得できる専用権限があれば、この問題は解決するのですが、現時点ではそうした仕組みは存在しません。
この権限設計の課題は、kintoneとAIツールを連携させる上で、多くの組織が直面するであろう普遍的な問題だと感じています。
開発を通じて得られた成果と今後の展望
設計通りのレビュー実現|OK/NG判定と具体的修正箇所の可視化
公式のレビューでは毎回回答が異なっていましたが、Difyで構築したシステムでは、設計通りに安定したレビューが実現できました。
OK/NGが一目でわかることに加え、具体的にどこを修正すればよいのかも明確に提示されるため、実務上の価値は非常に高いと感じています。
技術的な課題は残っているものの、「AIが人間の作業を補完し、品質を担保する」という仕組みの可能性を実感できたことは、大きな成果でした。
kintone導入時に似た「脱手作業」への期待感
容易なAIアプリ作成やkintone連携により、kintone導入時の「脱エクセル」に似た高揚感を実感しています。
従来の手作業（ポチポチ確認）から解放されるという強い期待感があります。
この「ワクワク感」は、新しい技術を導入する際の大きなモチベーションになります。
完璧でなくても、少しずつ改善していけば、いずれ大きな業務効率化につながるという確信があります。
エコシステムの親和性|学習リソースとコミュニティの充実
Difyには、活発なユーザー会、豊富な学習リソース(YouTube、Udemy、書籍)など、kintoneと共通した「学びやすく、繋がりやすい」文化圏があります。
サポート体制が充実しており、kintoneに近いコミュニティの熱量を感じられることも、大きな魅力です。
技術的な課題に直面した時、同じような悩みを持つ仲間がいて、情報交換できる環境があることは、実務担当者にとって非常に心強いものです。
最後に
kintone×Dify連携は、まだ発展途上の領域です。
権限設計やWebhook設計など、解決すべき課題も多く残っています。
しかし、だからこそ、今このタイミングで取り組む価値があると感じています。
もしあなたの組織でkintoneを運用していて、「データをもっと活用したい」「AIとの連携を検討したい」と考えているなら、まずは小さな検証から始めてみてください。
完璧を目指すのではなく、一つずつ課題を解決していく過程そのものが、大きな学びになるはずです。
私自身も、この開発を通じて多くの気づきを得ました。
今後も試行錯誤を続けながら、実務に即したAI活用の形を模索していきたいと思います。
あなたの組織での小さな一歩が、やがて大きな業務効率化へとつながることを願っています。