kintoneに溜まった案件情報を生成AIから引けるようにしたい——という相談は増えています。API連携そのものは難しくありません。実務で止まるのは、その手前と後ろです。
実際の案件で遭遇した順に、詰まる箇所を5つ挙げます。
1. 権限をどう引き継ぐかが決まっていない
kintoneの権限は3種類あります。公式ドキュメントではこう分かれています。
| 種類 | 何を制御するか |
|---|---|
| アプリのアクセス権 | アプリの管理と、レコードの閲覧・追加・編集・削除・書き出し |
| レコードのアクセス権 | フィールドの値を条件に、レコードごとに権限を変える |
| フィールドのアクセス権 | 特定のフィールドだけ、閲覧のみ／閲覧と編集／不可 |
この細かさが、そのままAI連携の難所になります。
混ざったことに、誰も気づかない
決めずに連携すると、本来見えないはずのレコードがAIの回答に混ざります。厄介なのは混ざったことに誰も気づかないまま運用が続くことです。回答文だけを見ても、それがどのレコードから来たのかは分かりません。
| 方式 | 実装 | 向くケース |
|---|---|---|
| 共通の閲覧アカウント | 簡単 | 全社公開のアプリだけを対象にする |
| 利用者の権限を引き継ぐ | 重い | 人事・与信など機密を含む |
| アプリを限定する | 簡単 | まず成果を出したい段階 |
実務的には3番から始めるのが扱いやすいはずです。権限の議論が発生しないアプリだけを対象にして、動くものを先に出す。そこで有効性が確認できてから、機密を含むアプリの権限設計に進みます。
APIトークンの権限は、アプリ設定より優先される
公式ドキュメントに明記されています。APIトークンに設定したアクセス権は、アプリ側の設定に関わらず優先されます。
つまり共通アカウント型（APIトークン）を選ぶと、アプリ側でどれだけ細かく権限を切っていても、それはAI経由の参照には効きません。これが1番の方式で権限を引き継げない技術的な理由です。方式の選び方は権限の引き継ぎ方をどう決めるかで整理しています。
2. フィールドの表記が揺れている
長く運用されているkintoneほど、同じ意味のフィールドが複数あります。
- 「担当者」「営業担当」「担当営業」が別アプリに並存している
- 選択肢フィールドに「株式会社」「(株)」「㈱」が混在している
- 使わなくなったフィールドが非表示のまま残っている
人間は文脈で読み替えられますが、AIは別物として扱います。「担当者が田中さんの案件」と聞いても、「営業担当」フィールドに入っているレコードは拾えません。
非表示ではなく削除する
見落とされやすいのがこれです。kintoneの「非表示」は画面上の設定であって、APIからは取得できます。使わなくなったフィールドを非表示にしただけだと、AIはその古い値を読んで回答に使います。
「非表示」には2種類あり、APIへの影響が違う
フォーム上の表示制御（JavaScript APIの setFieldShown() など）は画面の見た目を変えるだけで、REST APIには影響しません。値はそのまま返ります。
一方フィールドのアクセス権で「閲覧と編集が不可（NONE）」に設定した場合の挙動は、公式ドキュメントに明記がありません。実際にAPIを叩いて確認してください。
いずれにせよ、連携前に一度APIで実際に返ってくるフィールド一覧を出力すべきです。画面で見えているものと一致しないことがあります。
使わなくなったフィールドを非表示にしただけだと、AIはその古い値を読んで回答に使います。連携前に一度、APIで実際に返ってくるフィールド一覧を出力してください。画面で見えているものと一致しないことが、かなりの確率であります。
3. 自由記述欄に何が書かれているか把握できていない
案件管理アプリの「備考」「メモ」欄は、実は最も価値のある情報が入っている場所です。同時に、最も危険な場所でもあります。
備考欄は、最も価値があり、最も危険
担当者の主観、社内でしか言わない評価、取引先への率直な所感。これらがAIの回答に引用されて画面に出ると、問題になります。
対処は2つです。
- 自由記述欄を参照対象から外す（安全だが、情報量が落ちる）
- 一度サンプリングして中身を確認し、対象にするか判断する
後者を選ぶ場合、全件を読む必要はありません。ランダムに50〜100件を抜いて目視すれば、傾向は掴めます。
4. レコード間の関係がAIに伝わらない
kintoneはアプリ間をルックアップや関連レコードで繋ぎます。人間は画面上でその繋がりを追えますが、APIで1アプリずつ取得すると関係が失われます。
「A社の案件で、担当が誰で、いくらの見積を出したか」を答えるには、案件アプリ・顧客アプリ・見積アプリの3つを繋いだ状態で渡す必要があります。単純に3アプリを別々にインデックスしても、この問いには答えられません。
先に「答えたい質問」から設計する
ここが設計の分かれ目です。アプリから積み上げるのではなく、実際に社内で交わされている質問から逆算すると、繋ぐべき関係が自動的に決まります。
先に質問を20件集める
「あの会社の前回の見積いくらだっけ」「この案件の担当誰だっけ」といったものです。この20件に答えられる構成になっているかが、設計の合否判定になります。アプリから積み上げると、繋ぐべき関係が決まりません。
5. 更新頻度と鮮度のトレードオフ
案件情報は日々更新されます。連携時点のスナップショットを持つのか、都度APIで取りに行くのかで、鮮度と応答速度が変わります。
| 方式 | 鮮度 | 速度 | API負荷 |
|---|---|---|---|
| 定期同期（1日1回） | 最大1日遅れ | 速い | 低い |
| 更新検知して差分同期 | 数分〜1時間 | 速い | 中 |
| 参照時に都度取得 | 常に最新 | 遅い | 高い |
実務では「毎日同期＋更新頻度の高いアプリだけリアルタイム参照」の組み合わせが扱いやすいです。全部をリアルタイムにすると、応答が目に見えて遅くなり、kintone側のAPI制限にも当たります。
「今日の更新を今すぐ引きたい」は本当にあるか
「今すぐ引きたい」は本当にあるか
要件として挙がりやすいものの、実際の業務を確認すると必要ないことが多い項目です。本当にその瞬間性が必要な業務があるかを、具体的な場面で確認してください。無いのに全件リアルタイムにすると、コストと遅延だけが増えます。
順番をまとめると
- 社内で実際に交わされている質問を20件集める
- その質問に答えるのに必要なアプリと、アプリ間の関係を洗い出す
- 権限の議論が要らないアプリだけで、まず動くものを作る
- フィールドの表記ゆれと、残存フィールドを整理する
- 自由記述欄を対象にするか判断する
- 同期方式を決める（多くの場合1日1回で足りる）
API連携の実装は、この6つが決まっていれば難しくありません。逆にここが曖昧なまま実装から入ると、動いた後に作り直しになります。
連携機能が本体と別条件になっていないか、確認した結果です
主要4サービスの契約条件をまとめた表です。Microsoftは「エージェントは各エージェントのプライバシーステートメントと利用規約を確認せよ」と公式に明記しています。拡張機能・コネクタが本体と別扱いになる箇所を、サービスごとに書いています。
どのアプリから始めるべきか、3分で分かります
どの質問に答えたいか、どこまで権限を切るか。かんたんな設問に答えるだけで診断します。設計に入る前に見ておくと、後戻りが減ります。費用はかかりません。
この記事について：権限の3種類とAPIトークンの優先順位は、cybozu developer network および kintone ヘルプの記載に基づいています。フィールドのアクセス権をNONEに設定した場合のREST API応答については、公式に明記がないため断定していません。実装前にご自身の環境で確認してください。
