kintone API は、サイボウズの業務アプリ基盤 kintone に対するプログラム連携の窓口だ。kintone は非エンジニアが GUI で業務アプリを組めるノーコード寄りのプラットフォームで、API はそこに「外部システムとの接続」を足す役割を担う。
kintone 導入企業のための接着剤
実務での kintone API の価値は、すでに kintone を社内で使っている企業において発揮される。基幹システムや外部 SaaS と kintone アプリの間でデータを同期したり、Webhook でレコード変更を検知して別システムに通知したり、といった「繋ぎ」の処理が中心になる。レコードの CRUD は一括操作に対応しており、大量データの投入・更新も現実的な速度で回せる。
業務アプリ自体は kintone の画面で素早く作れるので、「アプリの UI は kintone、外部連携は API」という分担が自然に成立する。日本語の業務システムを短期間で立ち上げたい中堅企業に向いている。
スケール時に見える限界
便利な反面、kintone は 1 アプリあたりのレコード件数や、API の実行回数に上限が設けられている。データが数十万件規模に育つ業務や、秒間に多数のリクエストが飛ぶ連携では、この上限が壁になる。kintone は「部署単位の業務アプリ」のスケール感に最適化されており、全社の大規模トランザクション基盤として使うものではない、と理解しておくと設計を誤らない。
利用の前提条件
注意すべきは、API だけを単体で契約・利用することはできない点だ。kintone はユーザー数ベースの月額課金で、API は全プランで使えるが、そもそも kintone プラットフォームの契約が前提になる。「kintone は導入していないが API だけ使いたい」というニーズには応えられない。外部ユーザーを巻き込む場合のゲストユーザーは別単価になる点も、見積もり時に押さえておきたい。
業務システムの API という性格
kintone の API は、汎用的な SaaS の API とは前提が違う。アプリ（＝テーブル）の構造そのものを利用者が自由に作るため、フィールドコードやフィールド型が組織ごとに異なる。つまり「kintone の API を叩くコード」は、そのまま別の組織に持っていっても動かない。連携を作るときは、対象アプリのフィールド定義を先に確認する工程が必ず入る。
kintone のフィールドコードは管理画面から変更可能です。業務側が何気なく変更すると、連携していた API 呼び出しが静かに壊れます。運用に乗せるなら「このアプリは API 連携しているので構造を変えない」という取り決めを、技術ではなく運用ルールとして敷いておく必要があります。
国内業務との噛み合わせ
日本の中小企業で使われている前提の設計なので、日本語の項目名、和暦を含む日付の扱い、国内の承認フローといった要件と素直に噛み合う。海外製のノーコードツールで同じことをやろうとすると、日本語や日本の商習慣まわりで細かく詰まりがちだ。逆に、グローバル展開を見据えて英語圏のユーザーにも使わせる想定なら、国内向けに作り込まれている分だけ制約になる場面もある。