kintoneとは？情シスが導入前に確認すべき権限設計・連携・運用ルール

kintone（キントーン）とは、サイボウズが提供する、プログラミングなしで業務用のデータベースアプリを作れるクラウドサービスです。案件管理や問い合わせ管理、申請の受け付けといった、これまでExcelやメールで回していた業務を、権限と履歴の付いたアプリとして共有できます。

現場の部署が自分でアプリを作れることがkintoneの強みですが、情シスから見ると、その自由さがそのまま管理の穴になります。誰がどのレコードを見られるか、外部のシステムとどうつなぐか、増え続けるアプリを誰が面倒を見るかを、導入の前に決めておかないと、1年後には持ち主のわからないアプリとAPIトークンが残ります。ここでは機能の紹介より、情シスが先に決めておくべき権限設計・連携・運用ルールを中心に整理します。

kintoneとは：アプリ・スペース・プロセス管理の関係

kintoneの中心は「アプリ」です。アプリは1つの表（データベースのテーブル）と、その入力フォーム、一覧画面、グラフをまとめたもので、1件分のデータを「レコード」、項目を「フィールド」と呼びます。フォームはドラッグ＆ドロップで作れ、文字列、数値、日付、ドロップダウン、ユーザー選択、添付ファイルなどのフィールドを並べるだけで、入力画面と一覧が同時にできあがります。

アプリどうしは「ルックアップ」（別アプリのデータを入力時にコピーする）と「関連レコード一覧」（条件に合う別アプリのレコードを表示する）でつなぎます。たとえば「顧客マスタ」アプリと「案件管理」アプリを作り、案件の入力時に顧客名をルックアップで引く、という形です。ただしこれはリレーショナルデータベースの外部キーとは違い、ルックアップはコピーした時点の値を持つだけなので、マスタ側を修正しても既存のレコードには自動では反映されません。

業務の流れを表すのが「プロセス管理」で、「申請中 → 承認待ち → 完了」のようなステータスと、各ステータスで操作できる作業者を設定します。コミュニケーションの場としては「スペース」と「スレッド」があり、部署やプロジェクト単位で掲示板のように使えます。社外の取引先を招く場合は、ゲストスペースにゲストユーザーを招待します。

Excelや共有フォルダーとの違い

kintoneを検討するきっかけの多くは、「共有フォルダーのExcelが壊れる、誰が更新したかわからない」という悩みです。違いを情シスの管理項目で比べると次のようになります。

判断の軸ははっきりしていて、「複数人が同じデータを入力・更新し、見せる範囲を人によって変えたい」業務はkintoneに向き、「1人が大量のデータを加工・分析する」業務はExcelやBIツールのほうが向いています。入力と共有はkintoneで行い、集めたデータをCSVやAPIで取り出してExcelで分析する、という分担がよく機能します。

権限設計：3段階のアクセス権と評価の順番

kintoneのアクセス権は、アプリ、レコード、フィールドの3段階で設定します。アプリのアクセス権は「このアプリでできる操作」（レコードの閲覧・追加・編集・削除、アプリの管理、ファイルからの読み込みや書き出しなど）を決め、レコードのアクセス権は「どのレコードを見せるか」を条件で絞り、フィールドのアクセス権は「どの項目を見せるか」を絞ります。対象はユーザー、組織、グループ（ロール）で指定でき、組織には「下位組織に継承する」の指定があります。

設計で最もつまずくのは評価の順番です。アクセス権の設定は一覧の上から順に評価され、上にある行が優先されます（執筆時点のヘルプの説明）。「Everyone：閲覧のみ」を上に置き、その下に「営業部：編集可」を置くと、営業部の人も上の行に先に一致して閲覧しかできません。例外的な扱いをしたい人や組織を上に、全体に効かせる行を一番下に置くのが原則です。

新しく作ったアプリは、既定でEveryone（全ユーザー）にレコードの閲覧や編集を許す設定になっています（執筆時点）。部署で作ったアプリが全社から見えていた、という事故の多くはこの既定値のままの公開です。アプリを本番で使い始める前に「アプリのアクセス権」を開き、Everyoneの行を残すかどうかを必ず判断してください。CSVへの書き出しを誰に許すかも、同じ画面で確認します。

プロセス管理の「作業者」は、そのステータスで操作できる人を決めるだけで、レコードを閲覧する権限を与えるものではありません。承認者がレコードのアクセス権で除外されていると、承認の通知は届くのにレコードが開けない状態になります。承認フローを組んだら、承認者の立場のテストユーザーで実際に開けるかを確かめます。

権限の割り当てにはユーザー個人ではなく、組織とグループを使います。個人を並べると、異動や退職のたびに全アプリの設定を直す必要があり、直し漏れがそのまま情報漏えいの経路になります。人事異動を反映した組織情報をcybozu.com共通管理に取り込み、アプリ側は組織を指定する形にしておけば、異動の処理は組織の所属を変えるだけで済みます。

連携：REST API・Webhook・プラグイン・JavaScript

kintoneはREST APIを備えていて、レコードの取得・登録・更新や、アプリの設定変更ができます。認証方式には、ユーザーのログイン名とパスワード、アプリごとに発行するAPIトークン、OAuthがあります。システム間の連携には、アプリ単位で権限を絞れるAPIトークンを使うのが基本で、トークンには「レコード閲覧」「レコード追加」「レコード編集」「レコード削除」「アプリ管理」の中から必要なものだけを付けます。リクエストでは X-Cybozu-API-Token ヘッダーにトークンを入れます。

大量のデータを扱う連携では、APIの制限を最初に確認します。執筆時点の開発者向け資料では、レコード取得は1回500件まで、offset で読み飛ばせるのは10,000件までで、それを超える一括取得にはカーソルAPIを使う仕様です。1アプリあたりの1日のリクエスト数にも上限があるため、夜間にレコードを1件ずつ更新するような連携は、一括更新のAPIにまとめる設計にします。n8nのような自動化ツールにはkintoneの専用ノードがない場合もあり、その場合はHTTP Requestノードでこのヘッダーを付けて呼び出します（n8nのセルフホスト手順で設定例を示しています）。

外部への通知にはWebhookが使えます。レコードの追加・編集・削除、コメントの書き込み、ステータスの更新をきっかけに、指定したURLへ内容を送ります。受け側では、送られてきたデータをそのまま信用せず、必要ならAPIでレコードを取り直して確認する作りにすると、偽のリクエストで処理が動く事故を防げます。

画面の動きを変えたいときは、プラグインかJavaScriptによるカスタマイズを使います。プラグインはkintoneシステム管理者がシステムに読み込み、アプリ管理者がアプリごとに有効にする2段階の仕組みです。プラグインやJavaScriptは、それを開いた利用者の権限でkintoneのデータにアクセスでき、外部のサーバーにデータを送ることもできます。導入前に、提供元、通信先、保守の継続性を確認するルールを設けてください。なお、APIやJavaScript、プラグインは上位のコース（執筆時点ではスタンダードコース以上）でしか使えないため、連携を前提にするならコース選びの段階で確認します。

APIトークンやカスタマイズの担当者が退職すると、「誰が何のために発行したか分からないトークン」が残ります。APIトークンはアプリの設定画面で一覧できますが、用途までは記録されません。発行時に、用途、発行者、連携先のシステム、見直し日を社内の台帳（SaaS台帳など）に記録するルールにしておくと、棚卸しのときに止めてよいトークンを判断できます。

セキュリティ設定：cybozu.com共通管理で最初にやること

ユーザーやセキュリティの設定は、kintoneの画面ではなく「cybozu.com共通管理」で行います。管理者の権限も、cybozu.com共通管理者（ユーザー、組織、セキュリティ全体）、kintoneシステム管理者（kintone全体の設定、プラグインの読み込み）、各アプリの管理者、という3層に分かれています。全員をcybozu.com共通管理者にせず、日常の運用はkintoneシステム管理者とアプリ管理者に任せる分担にします。

最初に検討するセキュリティ項目は次のとおりです。メニュー名は変わる可能性があるため、公式ヘルプで現在の場所を確認してください。

SSOを入れた場合でも、アカウントの作成と削除まで自動化できるとは限りません。IdPからのアカウント同期（SCIMなど）への対応状況や、SSOを必須にしたときの管理者の緊急ログイン手段は、契約前に確認しておく項目です。確認の観点はSaaSのSSO/SCIM対応チェックリストにまとめています。

アプリが増えすぎて使われなくなる典型パターン

kintoneをやめる、あるいは「役に立たない」と言われる組織には、構造的に似た経緯があります。どれも製品の機能不足というより、運用ルールがないまま自由に作らせた結果です。

• 同じ目的のアプリが部署ごとに作られ、どれが正しいデータか分からなくなる
• 作った担当者が異動し、項目の意味や計算式を説明できる人がいなくなる
• プラグインやJavaScriptに頼った画面が、提供元の保守終了や仕様変更で動かなくなる
• 閲覧しかしない人にもユーザーライセンスが必要なため、利用者を増やすたびに費用が膨らみ、費用対効果を問われる
• 1つのアプリに何年分ものレコードを入れ続け、一覧の表示や検索が遅くなる

防ぐための運用ルールは、作成の許可、記録、見直しの3点に集約できます。アプリを作れる人をkintoneシステム管理の設定で限定し、アプリごとに「業務の責任者」「アプリ管理者」「連携先」を記録し、半年に一度は最終更新日を見て使われていないアプリを整理します。フィールドコード（APIや計算式が参照する項目の内部名）は、連携や計算式が参照しているため、本番運用後に変えると連携が壊れます。テスト用のアプリで変更を試してから本番に反映する手順も決めておきます。アプリの台帳を他のSaaSと一緒に管理する方法はSaaS管理の始め方で扱っています。

導入の判断基準と進め方

kintoneが向いているのは、複数の部署が同じデータを入力・参照し、ステータスで業務が流れる業務です。問い合わせ管理、案件・商談管理、備品や契約の台帳、社内申請などが典型です。逆に、会計や給与のように正確な整合性と法令対応が必要な業務、数十万件単位のデータを頻繁に集計する業務、帳票を細かいレイアウトで出力し続ける業務は、専用システムかBIツールのほうが向いています。

進め方は、情シスがルールを先に用意し、1つの業務で試してから広げる順番が安全です。

1. 権限設計のひな形（組織とグループの使い方、Everyoneの扱い）と、アプリ作成・API・プラグインの承認ルールを決める
2. 1つの業務でアプリを作り、テストユーザーで権限とプロセス管理の動きを確かめる
3. SAML認証か2要素認証を設定し、退職時のアカウント停止の手順に組み込む
4. アプリとAPIトークンを台帳に登録し、見直しの時期を決める
5. 2つ目以降の業務は、ひな形とルールを渡して部署に作ってもらい、情シスは承認と棚卸しに回る

よくある質問

kintoneで何ができるのか？

ノーコードで業務用のデータベースアプリを作り、複数人で入力・検索・集計できます。問い合わせ管理、案件管理、備品台帳、社内申請などが代表例で、ステータス管理（プロセス管理）や通知、コメントも付けられます。上位のコースでは、REST APIやWebhookで他のシステムと連携できます。

kintoneとExcelの違いは何ですか？

複数人が同時に同じデータを更新できる点、レコード単位の変更履歴が残る点、アプリ・レコード・フィールド単位で権限を分けられる点がkintoneの強みです。一方で関数やピボット、マクロによる自由な計算や分析はExcelのほうが得意なので、入力と共有はkintone、分析はExcelという分担が向いています。

キントーンの欠点は何ですか？

複数のアプリにまたがる集計や、リレーショナルデータベースのような整合性の担保が苦手で、ルックアップはコピーした時点の値しか持ちません。閲覧だけの人にもライセンスが必要で、利用者が増えると費用が伸びます。プラグインやJavaScriptに頼ると、保守を外部に依存しやすい点も注意が必要です。

キントーンの月額料金はいくらですか？

利用するユーザー数に応じた月額課金で、APIやプラグインを使えるかどうかなどによってコースごとに単価が異なり、最低契約ユーザー数も決まっています。価格は改定されることがあるため、金額はサイボウズの公式サイトの料金ページで確認してください。ゲストユーザーや追加ディスクは別料金です。

まとめ

kintoneは、現場がアプリを作れる自由さと引き換えに、権限と運用のルールを情シスが先に用意する必要があるサービスです。アクセス権は上から順に評価されること、新規アプリはEveryoneに広く開いていることを前提に設計し、APIトークンとプラグインは用途と責任者を記録して承認制にします。SSOか2要素認証で入口を固め、半年ごとの棚卸しで使われないアプリを整理してください。

次に読む

• SaaSのSSO/SCIM対応チェックリスト：kintoneをIdPとつなぐ前に確認する項目
• n8nとは？セルフホストでSaaS連携とAIワークフローを自動化する：APIトークンを使ったkintone連携の組み方
• SaaS管理の始め方：アプリとAPIトークンを台帳で棚卸しする仕組み