CHAPTER 10
kintoneの権限設計|異動・退職で壊れない形
この章で分かること
- 権限の3層(アプリ → レコード → フィールド)を決める順番と、下の層が上の層を超えられないという制約
- 異動・退職で実際に業務が止まる7か所と、そこに個人指定を残さない設計
- 見せてはいけない情報を守る場所・社外への見せ方・ログの見方と、権限の点検10項目
この章の目次(11)
- 17章から引き継ぐ1行
- 2権限は3層+1
- 3個人名で割り当てない
- 4人が動いたとき、どこが止まるか
- 5見せてはいけない情報の守り方
- 6社外に見せるとき
- 7全体の設定と、ログ
- 8どこまで作り込むか
- 9よくある間違いを5つ
- 10費用について
- 11この章の出口
権限が壊れるのは、設定を間違えたときではありません。人が動いたときです。異動・退職・兼務が起きて、設定だけが去年のまま残る——実務で見る壊れ方は、ほぼこれ1種類です。 直し方も1行で言えます。個人名で割り当てないこと。 アクセス権にも、プロセス管理の作業者にも、通知の宛先にも、個人のユーザーを書かない。これだけで、異動の作業が「共通管理で所属を変える」1手になります。 この章は、権限を3つの層に分けて上から決め切り、人が動いても業務が止まらない状態を作るための章です。
この章で分かること
- 権限の3層(アプリ → レコード → フィールド)を決める順番と、下の層が上の層を超えられないという制約
- 異動・退職で実際に業務が止まる7か所と、そこに個人指定を残さない設計
- 見せてはいけない情報を守る場所・社外への見せ方・ログの見方と、権限の点検10項目
7章から引き継ぐ1行
7章で、守る場所を3つに分けました。サーバー側(kintoneの設定)/画面(プラグイン・JavaScript)/運用(人の手順)。
権限は、そのいちばん上——どの経路から来ても効くサーバー側です。画面から見ても、CSVで書き出しても、APIで叩いても、閲覧できない人には返りません。だから7章で「表示制御は秘匿の代わりにならない」と書いた話の決着は、この章にあります。
7章とこの章の違いは目的です。7章は「入力が正しいか」、この章は「見える範囲が正しいか」。 同じ「項目を隠す」でも、入力しやすくするために隠すのは7章の項目の表示切替、見せてはいけないから隠すのはこの章のフィールドのアクセス権です。迷ったらアクセス権にしてください。 表示切替で隠した値は、一覧の列に出せば見えますし、CSVにもAPIにも出ます。
権限は3層+1
| 層 | どこで設定するか | 何を決めるか |
|---|---|---|
| (前提)スペース | スペースの設定 | そのスペースに入れる人。ゲストスペースはここが境界になる |
| 1. アプリ | アプリの設定 → アクセス権 → アプリ | 閲覧・追加・編集・削除・ファイル書き出し・アプリ管理 |
| 2. レコード | 同 → レコード | 条件に合うレコードだけを見せる・編集させる |
| 3. フィールド | 同 → フィールド | 特定の項目だけを隠す・編集させない |
決めるときに守るのは2つだけです(2026年9月時点)。
下の層は、上の層を超えられません。 アプリで閲覧不可にした人は、レコード権限で許可してもそのアプリを見られません。だから設計は必ずアプリ → レコード → フィールドの順に進めます。逆から作ると、細かく作り込んだレコード権限が、アプリの1行で全部無効になっていた、ということが起きます。
設定は上の行から評価され、最初に当てはまった行が適用されます。 Everyone を一番上に置くと、その下に書いた行は一切効きません。Everyone は常に最終行です。ここを間違えたまま「設定したのに効かない」と悩んでいる会社を、何度も見ています。
個人名で割り当てない
営業部の3人に閲覧権を渡したいとき、書き方は2つあります。
| 書き方 | 異動が1件あったとき |
|---|---|
| 田中・佐藤・鈴木(ユーザー)を3行書く | 全アプリの設定を人手で直す。 漏れたら、異動後も前の部署のデータが見え続ける |
| 営業部(組織)を1行書く | 共通管理で所属を変えるだけ。全アプリに一斉に効く |
アプリが10個になれば、個人名の割り当てはアプリ数 × 異動する人数だけ作業が発生します。しかも「どのアプリに誰の名前が書いてあるか」は、画面を1つずつ開かないと分かりません。
組織・グループ・ロールの使い分け
| 単位 | 中身 | 使いどころ |
|---|---|---|
| 組織 | 人事上の所属。上位・下位の階層を持てる | 基本の閲覧・編集はここ。 「営業部(配下を含む)」で一括 |
| グループ | 所属に関係なく集めた人の集合 | 部署をまたぐ役割。kintone管理者、承認者、プロジェクト単位 |
| ロール | スペースやプロセス管理で使う役割 | 「申請者の上長」のような、レコードごとに人が変わる指定 |
実務は「組織で大枠を決めて、グループで役割を足す」の2段で足ります。 ロールまで使うのは、承認ルートが組織階層に沿う場合だけです。
「自分の担当分だけ」も、個人名は書かない
レコードのアクセス権は、フィールドの値を条件にできます(7章で触れた「レコードのアクセス権は条件を持てる」がここです)。
| 条件に使えるもの | 使う場面 |
|---|---|
| ユーザー選択フィールドの値 | 担当者だけが編集できる |
| 組織選択・グループ選択フィールドの値 | 担当課だけが閲覧できる |
| ドロップダウン等の値 | 「区分=人事」のレコードは人事部だけ |
| レコードの作成者 | 申請者本人だけが自分の申請を編集できる |
見本の不動産 ② 反響・顧客 と ③ 内見予約 には 担当者(ユーザー選択)が入っています。この項目があれば、「担当者だけが編集できる」を個人名ゼロで作れます。権限のために項目を足すのではなく、業務で使う担当者項目が、そのまま権限の条件になるのが正しい形です。
1つだけ注意があります。「作成者」を条件にした権限は、その人が異動しても本人に付いていきます。 前の部署で作った申請を、異動後も本人が見続けます。人事・経理のように「部署を離れたら見えなくなる」必要がある業務では、作成者ではなく組織選択フィールドで絞ってください。
人が動いたとき、どこが止まるか
組織で書いていても、フィールドやプロセスの中に残った個人指定が残骸になります。人が動いたら見る場所はここです。
| 場所 | 異動で起きること | 退職で起きること |
|---|---|---|
| アプリのアクセス権(個人指定) | 前の部署のデータが見え続ける | 停止すれば入れないが、設定行は残る |
| プロセス管理の作業者(個人指定) | 承認が止まる | 完全に止まる。 管理者が作業者を変えるまで進まない |
| ユーザー選択フィールド(担当者) | 旧担当のまま。「自分の担当」から消える | 停止ユーザー担当のレコードが宙に浮く |
| 条件通知・リマインダーの宛先(個人指定) | 前の部署の通知が届き続ける | 通知が誰にも届かなくなる |
| APIトークン・Webhook | 影響なし | 作った人がいなくても動き続ける。 誰の管理か分からなくなる |
| スペースの管理者 | 前任のまま | スペースを直せる人がいなくなる |
| アプリ管理権限 | 前任のまま | アプリを直せる人がいなくなる |
太字がすべて「業務が止まる」側です。とくにプロセス管理の作業者を個人名で指定した業務は、退職した瞬間に承認が完全に止まります。 9章で「作業者は組織・グループで指定する」と決めたのは、この章のためでした。
退職時にやること(この順番で)
- cybozu.com 共通管理で、ユーザーを削除ではなく「使用停止」にする(停止ユーザーはライセンスの人数に数えられません)
- その人がアプリ管理権限・スペース管理者になっているアプリとスペースに、後任を付ける
- プロセス管理の作業者に個人指定が残っていないか確認する
- その人が担当になっているレコードを一覧で出し、担当者を付け替える
- その人が作ったAPIトークン・Webhook・JavaScriptの置き場所を確認する(13章)
- 監査ログで、直近のファイル書き出しを確認する
削除ではなく停止にするのは、削除すると過去レコードのユーザー選択フィールドや作成者の見え方に影響が出るためです。停止で困ることは基本的にありません。
異動は、組織で割り当ててさえいれば共通管理で所属を変えるだけです。そのうえで、上の表の「個人指定が残る場所」だけを点検します。アプリが増えてきたら画面で追うのは現実的でないので、APIで一度に洗い出します。手順とスクリプトはkintoneの権限設計にそのまま載せました。USER の行がゼロという状態が、異動で壊れない状態です。
見せてはいけない情報の守り方
| 守りたいもの | 守る場所 |
|---|---|
| 給与・評価 | フィールドのアクセス権(人事部以外を閲覧不可) |
| 原価・仕入単価 | フィールドのアクセス権(営業を閲覧不可) |
| 承認後の金額を触らせない | フィールドのアクセス権(編集不可)、または条件付き入力禁止 |
| 他部署のレコードを見せない | レコードのアクセス権(組織選択フィールドの値で絞る) |
| CSVで丸ごと持ち出させない | アプリのアクセス権でファイル書き出しを外す |
最後の行が、いちばん見落とされます。レコードの閲覧を許した相手は、既定では全件をCSVで落とせます。 「見るのはいいが、持ち出しはさせない」は、書き出し権限を別に外して初めて成立します。添付ファイルも同じで、閲覧できる人はダウンロードできます。
上から3行目は使い分けに注意です。フィールドのアクセス権は条件を持てません(7章)。「承認済のときだけ編集不可」は権限では書けないので、条件付き入力禁止(画面側)か、レコードのアクセス権(レコード全体が編集不可になる)のどちらかを選びます。確実さを取るならレコード権限、項目単位の細かさを取るなら画面側です。
社外に見せるとき
顧客・協力会社・監査法人に一部だけ見せるなら、ゲストスペースを使います。ゲストユーザーは、そのゲストスペースの中のアプリとスレッドしか見られません。社内の他のアプリやポータルには構造的に入れないので、「社内アプリに間違って権限を付けてしまう」事故が起きません。
| 向いている | 向いていない |
|---|---|
| 協力会社に、自社担当分の工事だけ入力してもらう | 不特定多数(ゲストは1人ずつ招待する) |
| 顧客と案件の進捗をやり取りする | 人数が読めない・入れ替わりが激しい相手 |
| 監査法人に期間限定で資料を出す | 既存の社内アプリをそのまま見せたい |
注意は3つです。ゲストユーザーは通常のユーザーと別枠で人数分の費用がかかること、ゲストスペース内のアプリは社内スペースのアプリと分かれる(既存アプリをそのまま見せられない)こと、入れ替わりが多い相手には運用が重いことです。人数が読めない相手に見せる・書いてもらうなら、ゲストスペースではなくフォームやビューアの仕組みを検討します(12章の「外部サーバーが要る領域」)。
全体の設定と、ログ
アプリより上の層として、cybozu.com 共通管理に2段階認証・IPアドレス制限・パスワードポリシーがあります。2段階認証(認証アプリのワンタイムパスワード)は全ユーザーに設定することを勧めます。IPアドレス制限は、オフィス以外から触る運用があるなら、先に働き方を確認してから掛けてください(掛けてから「現場が入れない」と分かるのがいちばん多い事故です。リモートがあるならVPN経由を前提にします)。パスワードポリシーでは最低文字数・定期変更の強制・過去のパスワードの再利用禁止を決められます。自社の情報セキュリティ規程に合わせるだけの項目なので、ここで悩む必要はありません。
自治体・医療のように、庁内・院内の利用手続きがある組織では、設定を設計する前に確認する順番があります。 どの評価制度・調達の基準への対応が求められるか、どの範囲のデータまでクラウドに載せてよいか、この2つを情報政策(情報システム)の担当と先に固めてください。団体ごとに運用が違うため、ここを飛ばして権限の設計に入ると、あとから全部やり直しになります。島根県海士町での構築でも、この確認が庁内の合意の起点になりました。
監査ログでは「誰が・いつ・何をしたか」を検索できます。全部を毎日見るのは続かないので、見る対象を絞ります。
| 見るもの | 頻度 | 何に気づくか |
|---|---|---|
| ファイルの書き出し(CSV) | 月1回 | 想定外の人が全件を落としていないか |
| ログインの失敗 | 月1回 | 不審なアクセス |
| アプリの設定変更 | 月1回 | 誰が何を変えたか |
ログの保存期間には上限があります。証跡として残す必要があるなら、定期的にCSVで書き出して保管してください。
自治体・医療のように、外部への通信が制限された環境で使う場合は、アプリに入れるプラグインが外部と通信するかが別の論点になります。これは12章でまとめて扱います。当社の無料プラグイン23本は、いずれも kintone の公式APIだけで動き、外部のサーバーと通信しません(ライセンスと方針)。
どこまで作り込むか
最初から細かく作り込むと、運用が始まりません。 順番はこうです。
- アプリ管理権限を2人以上に決める(ここだけは初日に)
- 機微な項目(給与・原価・個人の健康情報)だけ、フィールドのアクセス権で先に締める
- 残りは広めに開けて運用を始める
- 1〜2か月使って、「見えて困った」が出たところだけレコード権限で絞る
情報システム部門がない会社では、管理者は「その業務をいちばん分かっている人」+その上長の2人が現実的です。権限を渡さないと誰も直せず、結局使われなくなります(15章)。
よくある間違いを5つ
1. Everyone を一番上に書く——下に書いた設定が一切効かない。設定したつもりで何も守れていない状態になります。
→ 直し方:Everyone は必ず最終行。上から順に「狭い条件 → 広い条件」で並べます。
2. アプリ管理権限が1人だけ——その人が休んだ日、辞めた週に、誰もアプリを直せなくなります。逆に全員に渡すと、誰かが項目を消しても気づきません。 → 直し方:アプリ管理は2人以上・グループで数人まで。主担当と副担当を名前で周知します。
3. 表示切替で隠して守ったつもりになる——値はレコードに残り、一覧の列・CSV・APIから見えます。 → 直し方:見せてはいけない情報はフィールドのアクセス権で閲覧不可にします。表示切替は「入力しやすくする」ためだけに使います。
4. 閲覧を許した全員に、ファイル書き出しも許している——退職前に全件を持ち出せます。 → 直し方:書き出し権限はアプリのアクセス権で別に管理し、必要な人だけに付けます。月1回、監査ログで書き出しを見ます。
5. 誰も設定を見直さない——3年経つと、設定と組織図が別物になります。
→ 直し方:半年に1回、個人指定(USER)の棚卸しを予定に入れます。人事異動の辞令が出たら、退職時の6手順と同じ場所を点検します。
費用について
アクセス権(アプリ・レコード・フィールド)、2段階認証、IPアドレス制限、監査ログは、すべて標準機能で追加費用なしです。ゲストユーザーだけは、通常のユーザーとは別枠で人数分の費用がかかりますので、社外に見せる要件があるときは人数を先に数えてください。
kintoneのライセンス料はスタンダードコース 1ユーザー月1,800円(税抜)・最小10ユーザーでサイボウズ社とのご契約、当社の構築は1業務1アプリまで最大1か月0円、使うと決めていただいた段階で月5万円から(最低12ヶ月)です。
この章の出口
手元に残っているべきものは5つです。組織・グループの一覧、アプリごとのアクセス権の表(個人名ゼロ)、フィールド権限で守る項目の一覧、退職時の6手順、月1回見る監査ログの3項目。そして点検リストで1・2・5 が○になっていること。
ここまでで、作って・流して・見せる範囲を決めるところまで来ました。残っているのは、そこに入れる中身です。多くの会社で、それは何年分ものExcelです。そして取り込みの経路は、7章で書いたとおり画面のチェックが1つも効かない経路です。汚れたまま入れれば、ここまでの設計は初日に破られます。
この章の点検リストを開く(自社の状態を○×で判定する用)
点検リスト:権限の点検(10項目)
対象はアプリ1つではなく、その環境(cybozu.com)全体です。アプリごとの項目は1・5・6・7です。
| # | チェック項目 | ○の条件 |
|---|---|---|
| 1 | 権限を個人ではなく組織・グループに付けているか | アクセス権に個人名の行が無い |
| 2 | 管理者(アプリ管理権限)が2人以上いるか | 1人に依存していない |
| 3 | 退職者アカウントの停止手順が決まっているか | 削除ではなく停止。6手順が文書になっている |
| 4 | 異動時に権限が自動で付け替わる設計か | 組織で付けている(所属変更の1手で済む) |
| 5 | 人事・給与など機微な情報を、フィールド権限で守っているか | 表示制御に頼っていない |
| 6 | 全レコードを閲覧できる人の範囲を決めたか | 決まっている(Everyone が最終行にある) |
| 7 | ファイル添付・CSV書き出しの持ち出しについて方針があるか | 書き出し権限を付ける相手を決めている |
| 8 | 外部公開・ゲストスペースの要否を決めたか | 決まっている(使うなら人数と費用も) |
| 9 | 監査ログを確認する頻度を決めたか | 月1回・見る3項目が決まっている |
| 10 | 二要素認証・IPアドレス制限の要否を決めたか | 決まっている(掛けるなら働き方を確認済み) |
合格ライン=10項目中9つ以上。1・2・5 は必須。
1が×なら、この章は何も進んでいません。2が×の環境は、明日にでも止まります。5が×のまま人事データを載せるのは、権限の設計ではなく、事故の準備です。
この章に関係する記事
更新日 2018年10月20日
