kintoneの権限が壊れるのは、ほぼ例外なく「人が動いたとき」です。設定そのものを間違えるケースより、異動・退職・兼務で設定が現実と合わなくなるケースのほうが圧倒的に多いです。
壊れない作り方は1行で言えます。個人名で割り当てないこと。 アプリのアクセス権にも、レコードのアクセス権にも、プロセス管理の作業者にも、個人のユーザーを直接書かない。これだけで、異動の作業が「共通管理で所属を変える」1手になります。
この記事は「運用で壊れない権限の設計」に絞っています。IPアドレス制限や2段階認証を含む全体のセキュリティ設定は10章 権限とセキュリティを見てください。
権限は3層＋1
| 層 | どこで設定するか | 何を決めるか |
|---|---|---|
| （前提）スペース | スペースの設定 | そのスペースに入れる人。ゲストスペースはここが境界になる |
| アプリ | アプリの設定 → アクセス権 → アプリ | 閲覧・追加・編集・削除・ファイル書き出し・アプリ管理 |
| レコード | 同 → レコード | 条件に合うレコードだけを見せる・編集させる |
| フィールド | 同 → フィールド | 特定の項目だけを隠す・編集させない |
下の層は上の層を超えられません。 アプリで閲覧不可の人は、レコード権限で許可してもそのアプリを見られません。設計するときは必ずアプリ → レコード → フィールドの順に決めます。
もう1つ、覚えておくべき挙動があります。アクセス権の設定は上の行から評価され、最初に当てはまった行が適用されます。 Everyone を一番上に置くと、その下に書いた細かい設定は一切効きません。Everyone は常に最終行です。
なぜ個人名で割り当ててはいけないのか
営業部の3人に閲覧権を渡したいとき、2つの書き方があります。
| 書き方 | 異動があったとき |
|---|---|
| 田中・佐藤・鈴木（ユーザー）を3行書く | 全アプリの設定を人手で直す。 漏れたら、異動後も前の部署のデータが見える |
| 営業部（組織）を1行書く | 共通管理で所属を変えるだけ。全アプリに一斉に効く |
アプリが5個・10個と増えると、この差が決定的になります。個人名の割り当ては、アプリの数 × 異動する人数だけ作業が発生し、しかも「どのアプリに誰の名前が書いてあるか」を誰も把握していない状態になります。
組織・グループ・ロールの使い分け
| 単位 | 中身 | 使いどころ |
|---|---|---|
| 組織 | 人事上の所属。上位・下位の階層を持てる | 基本の閲覧・編集はここ。 「営業部（配下を含む）」で一括 |
| グループ | 所属に関係なく集めた人の集合 | 部署をまたぐ役割。kintone管理者、承認者、特定プロジェクト |
| ロール | スペースやプロセス管理で使う役割 | 「申請者の上長」のような、レコードごとに人が変わる指定 |
実務では「組織で大枠を決めて、グループで役割を足す」の2段で足ります。ロールまで使うのは、承認ルートが組織階層に沿う場合です。
レコード権限を「担当者」で絞るとき
「自分の担当分だけ編集できる」を作るときも、個人名は書きません。ユーザー選択フィールド（担当者）の値を条件にします。
| 条件に使えるもの | 使う場面 |
|---|---|
| ユーザー選択フィールドの値 | 担当者だけ編集できる |
| 組織選択・グループ選択フィールドの値 | 担当課だけ閲覧できる |
| ドロップダウン等の値 | 「区分＝人事」のレコードは人事部だけ |
| レコードの作成者 | 申請者本人だけが自分の申請を編集できる |
ここで1つ注意があります。「作成者」を条件にした権限は、その人が異動しても本人に付いていきます。 前の部署で作った申請を、異動後も本人が見続ける状態になります。これが困る業務（人事・経理）では、作成者ではなく組織選択フィールドで絞ってください。
異動・退職で実際に何が起きるか
設定を組織で書いていても、フィールドやプロセスの中に残った個人指定が残骸になります。人が動いたときに見る場所を並べます。
| 場所 | 異動で起きること | 退職で起きること |
|---|---|---|
| アプリのアクセス権（個人指定） | 前の部署のデータが見え続ける | 停止すればログインできないが、設定行は残る |
| プロセス管理の作業者（個人指定） | 承認が止まる（本人がもういない業務の承認者のまま） | 完全に止まる。 管理者が作業者を変えるまで進まない |
| ユーザー選択フィールド（担当者） | 旧担当のまま。一覧の「自分の担当」から消える | 停止ユーザーが担当のレコードが宙に浮く |
| 条件通知・リマインダーの宛先（個人指定） | 前の部署の通知が届き続ける | 通知が誰にも届かなくなる |
| APIトークン・Webhook | 影響なし | 作った人がいなくなっても動き続ける。 誰の管理か分からなくなる |
| スペースの管理者 | 前任のまま | スペースを直せる人がいなくなる |
| アプリ管理権限 | 前任のまま | アプリを直せる人がいなくなる |
太字がすべて「業務が止まる」側です。とくにプロセス管理の作業者を個人名で指定している業務は、退職した瞬間に承認が完全に止まります。 ここは組織かグループ、または「申請者の上長」のようなロールで指定してください（→プロセス管理で承認フローを自動化）。
退職時にやること（順番どおり）
- cybozu.com 共通管理で、ユーザーを削除ではなく「使用停止」にする（停止ユーザーはライセンスの人数に数えられません）
- その人がアプリ管理権限・スペース管理者になっているアプリとスペースに、後任を付ける
- プロセス管理の作業者に個人指定が残っていないか確認する
- その人が担当になっているレコードを一覧で出し、担当者を付け替える
- その人が作ったAPIトークン・Webhook・JavaScriptの置き場所を確認する（→13章 JavaScript・API・外部連携）
- 監査ログで、直近のファイル書き出しを確認する
削除ではなく停止にする理由は、削除すると過去レコードのユーザー選択フィールドや作成者の見え方に影響が出るためです。停止で困ることは基本的にありません。
異動のときは、組織で割り当ててさえいれば共通管理で所属を変えるだけです。そのうえで、上の表の「個人指定が残る場所」だけを点検します。これが1手で済む状態を作るのが、権限設計の目的です。
見せてはいけない情報の守り方
項目の表示・非表示で情報は守れません。 条件によって項目を出し分ける機能（や項目の表示切替のようなプラグイン）は、画面から消しているだけで、値はレコードに残っています。CSVの書き出し、API、印刷用画面からは取得できます。
守るのはフィールドのアクセス権です。
| 守りたいもの | やり方 |
|---|---|
| 給与・評価 | フィールドのアクセス権で人事部以外を閲覧不可 |
| 原価・仕入単価 | 同、営業を閲覧不可 |
| 承認後の金額を触らせない | フィールドのアクセス権（編集不可）、または条件付き入力禁止 |
| 他部署のレコードを見せない | レコードのアクセス権（組織選択フィールドの値で絞る） |
| CSVで丸ごと持ち出させない | アプリのアクセス権でファイル書き出しを外す |
最後の「ファイル書き出し」は見落とされがちです。レコードの閲覧を許した相手は、既定では全件をCSVで落とせます。 閲覧だけ許して持ち出しは許さない、は書き出し権限を外すことで実現します。
ゲストスペースの使いどころ
社外の人（顧客・協力会社・施工業者）に一部を見せるときは、ゲストスペースを使います。
ゲストユーザーは、そのゲストスペースの中のアプリとスレッドしか見られません。 社内の他のアプリやポータルには一切アクセスできないので、「社内アプリに間違って権限を付けてしまう」事故が構造的に起きません。
| 向いている | 向いていない |
|---|---|
| 協力会社に、自社担当分の工事だけ入力してもらう | 不特定多数に見せる（ゲストは1人ずつ招待する） |
| 顧客と、案件の進捗をやり取りする | 人数が読めない、入れ替わりが激しい相手 |
| 監査法人に、期間限定で資料を出す | 社内アプリのデータをそのまま見せたい（別アプリになる） |
注意点は3つです。ゲストユーザーは通常のユーザーとは別枠で人数分の費用がかかること、ゲストスペース内のアプリは社内スペースのアプリと分かれる（既存アプリをそのまま見せられない）こと、そして入れ替わりが多い相手には運用が重いことです。不特定多数に見せる・書いてもらうなら、ゲストスペースではなくフォームやビューアの仕組みを検討します。
監査ログで見るもの
cybozu.com 共通管理の監査ログで、「誰が・いつ・何をしたか」を検索できます。全部を毎日見るのは続かないので、見る対象を絞ってください。
| 見るもの | 頻度 | 何に気づくか |
|---|---|---|
| ファイルの書き出し（CSV） | 月1回 | 想定外の人が全件を落としていないか |
| ログインの失敗 | 月1回 | 不審なアクセス |
| アプリの設定変更 | 月1回 | 誰が何を変えたか（定着の運用と合わせて見る） |
ログの保存期間には上限があります。証跡として残す必要があるなら、定期的にCSVで書き出して保管してください。
設定を棚卸しする
アプリが増えてくると、「どのアプリに個人名の割り当てが残っているか」を画面で追うのが現実的でなくなります。APIで一度に洗い出せます。
// ブラウザのコンソールで実行する。個人指定（USER）が残っているアプリを洗い出す
(async () => {
const APPS = [10, 11, 12]; // 調べたいアプリID
const found = [];
for (const app of APPS) {
const info = await kintone.api('/k/v1/app', 'GET', { id: app });
// アプリのアクセス権
const appAcl = await kintone.api('/k/v1/app/acl', 'GET', { app });
for (const r of appAcl.rights) {
if (r.entity.type === 'USER') {
found.push({ アプリ: info.name, 層: 'アプリ', 対象: r.entity.code });
}
}
// レコードのアクセス権
const recAcl = await kintone.api('/k/v1/record/acl', 'GET', { app });
for (const right of recAcl.rights) {
for (const e of right.entities) {
if (e.entity.type === 'USER') {
found.push({ アプリ: info.name, 層: 'レコード', 対象: e.entity.code });
}
}
}
}
console.table(found);
if (found.length === 0) console.log('個人指定は残っていません');
})();
USER の行が出てきたら、組織かグループに置き換えられないかを検討します。ここが空になっている状態が、異動で壊れない状態です。フィールドのアクセス権は /k/v1/field/acl で同じように取れます。
やりがちな失敗
| 失敗 | 何が起きるか | どうするか |
|---|---|---|
Everyone を一番上に書く |
下の設定が一切効かない | Everyone は必ず最終行 |
| アプリ管理権限が1人だけ | その人が休むとアプリを直せない | 2人以上にする（最重要） |
| 全員にアプリ管理権限 | 誰かが項目を消して気づかれない | 管理はグループで数人に絞る |
| 表示の出し分けで隠したつもり | CSV・APIから見える | フィールドのアクセス権で閲覧不可にする |
| 閲覧を許した全員にファイル書き出しを許す | 全件を持ち出せる | 書き出しは必要な人だけ |
| プロセス管理の作業者が個人名 | 退職で承認が止まる | 組織・グループ・ロールで指定 |
| 誰も設定を見直さない | 3年で現実と合わなくなる | 半年に1回、上のスクリプトで棚卸し |
権限をどこまで作り込むか
最後に現実的な話をします。最初から細かく作り込むと、運用が始まりません。 順番はこうです。
- アプリ管理権限を2人以上に決める（ここだけは初日に）
- 機微な項目（給与・原価・個人の健康情報）だけ、フィールドのアクセス権で先に締める
- 残りは広めに開けて運用を始める
- 1〜2か月使って、「見えて困った」が出たところだけレコード権限で絞る
情報システム部門がない会社では、管理者は情シスではなく「その業務をいちばん分かっている人」＋その上長の2人にするのが現実的です。権限を渡さないと誰も直せなくなり、結局使われなくなります（→15章 運用・定着と内製化）。
まとめ
- 権限はアプリ → レコード → フィールドの順で決める。下の層は上の層を超えられない
- アクセス権は上の行から評価される。
Everyoneは必ず最終行 - 個人名で割り当てない。基本は組織、横断する役割だけグループ
- 「作成者」条件の権限は、異動しても本人に付いていく。人事・経理では使わない
- 退職は削除ではなく使用停止。そのうえでアプリ管理者・スペース管理者・作業者・APIトークンを点検する
- プロセス管理の作業者に個人名を書くと、退職の瞬間に承認が止まる
- 表示の出し分けでは情報を守れない。フィールドのアクセス権を使う
- 閲覧を許すとCSVで全件落とせる。ファイル書き出し権限は別に考える
- アプリ管理権限は必ず2人以上。半年に1回、個人指定の棚卸しをする
→ kintone導入支援の詳細 → 10章 権限とセキュリティ → プロセス管理で承認フローを自動化 → kintoneを定着させる
よくある質問
kintoneのアクセス権は個人とグループのどちらで設定すべきですか
組織（部署）またはグループで設定してください。個人名で割り当てると、異動のたびに全アプリの設定を人手で付け替えることになり、付け替え漏れが必ず出ます。組織で割り当てておけば、共通管理で所属を変えるだけで、そのユーザーの見える範囲が全アプリで一斉に切り替わります。
組織とグループはどう使い分けますか
組織は人事上の所属（営業部・総務課）、グループは部署をまたぐ役割（kintone管理者・承認者・プロジェクト単位のメンバー）に使います。基本の閲覧・編集は組織で割り当て、横断的な役割だけグループで足す、という二段構えにすると設定が読みやすくなります。
社員が退職したらkintoneのアカウントは削除すべきですか
削除ではなく「使用停止」にしてください。停止すればログインできなくなり、ライセンスの人数にも数えられません。削除すると、そのユーザーが入っていたユーザー選択フィールドや作業者の表示、過去レコードの作成者の見え方に影響が出ます。停止のうえで、APIトークンとWebhookの見直し、ファイル書き出しログの確認まで行います。
見せたくないフィールドは、条件で非表示にすれば隠せますか
隠せません。画面上の表示制御で消した項目も、値そのものはレコードに残っていて、CSVの書き出しやAPI、印刷用画面からは取得できます。見せてはいけない情報はフィールドのアクセス権で「閲覧不可」にしてください。表示の出し分けは、入力しやすくするための機能であって、秘匿の手段ではありません。
社外の人にkintoneを見せるにはどうすればいいですか
ゲストスペースを使います。ゲストユーザーはそのゲストスペースの中のアプリとスレッドしか見られないため、社内の他のアプリに触れる心配がありません。ゲストユーザーは通常のユーザーとは別枠の扱いで人数分の費用がかかるため、必要な人数と単価をサイボウズの料金ページで確認してから設計してください。
