kintoneアクセス権の設定方法｜3層の違いと情報漏えいを防ぐ設計・テスト

2026年9月14日 12:41

「経費申請アプリを作ったら、他の社員の金額まで見えていた」

これは、kintoneの機能が弱いから起きる事故ではありません。多くの場合、管理者の画面だけで動作確認し、一般ユーザーから何が見えるかを確かめていないことが原因です。管理者は広い権限を持つため、自分の画面が正しく見えるほど、利用者側の設定ミスを見落としやすくなります。

kintoneのアクセス権は、アプリ・レコード・フィールドの3段階です。覚え方は「入口・行・項目」。ただし、3種類の意味を知るだけでは不十分です。実務では、どの順番で絞るか、複数条件の優先順位をどう置くか、異動や外部連携までどう試験するかが安全性を決めます。

この記事では、権限設定の違いから、経費・出張申請の設計例、公開前テスト、運用開始後の棚卸しまで、一つの流れで整理します。

kintoneのアクセス権は「入口・行・項目」の3層

公式ヘルプでは、すべてのレコードに対する権限を「アプリ」、特定レコードに対する権限を「レコード」、特定フィールドに対する権限を「フィールド」で設定すると説明されています。

アプリのアクセス権は「誰が入口を通れるか」

アプリ全体について、レコードの閲覧・追加・編集・削除、アプリ管理、ファイル読み込み・書き出しなどを制御します。営業案件アプリを営業部だけに使わせるなら、最初にここで対象外の部署を入口から外します。

見落としやすいのは初期状態です。kintone公式ヘルプによると、アプリ作成直後のEveryoneには、レコードの閲覧・追加・編集・削除が許可されています。機密情報を扱うアプリは「あとで絞る」のではなく、公開前に必ずEveryoneを含む設定を確認します。

また、アプリ管理は日常利用とは別の権限です。フォームやプロセスを変更できる人を増やすと、善意の修正でも入力項目や承認ルートが変わります。小さな組織でも、使う人と設計を変える人は分けるほうが安全です。

レコードのアクセス権は「どの行を見せるか」

同じアプリの中で、レコードごとに閲覧・編集・削除できる人を変えます。社員名簿なら本人と人事、経費申請なら申請者と担当承認者、案件管理なら担当営業と上司だけに見せる、といった設定です。

作成者・更新者・プロセス管理の作業者に加え、ユーザー選択や組織選択フィールドの値を対象にできます。つまり「固定の田中さん」ではなく、「そのレコードの担当者フィールドで選ばれた人」に権限を与えられます。担当替えが多い業務では、個人名を設定画面へ埋め込むより引き継ぎやすくなります。

フィールドのアクセス権は「どの項目を見せるか」

レコードは共有したいが、一部の項目だけ隠したい場合に使います。案件の進捗は営業全員へ共有し、粗利率は経営者だけが閲覧する。日報は全員が見られるが、上司コメント欄は上司だけが編集する、といった使い分けです。

ただし、フィールド権限を増やしすぎると、利用者ごとに画面が違い、問い合わせとテストパターンが増えます。隠したい項目が多いなら、「同じアプリで持つべき情報か」「機密情報だけ別アプリへ分けるべきか」を先に考えます。

設定は「広い範囲から狭い範囲」へ進める

迷ったら、アプリ→レコード→フィールドの順で決めます。最初に入口を絞り、その中で見せる行を分け、最後に例外的な項目を隠す。この順番なら、全体像を失いにくくなります。

設計前に、縦軸へ役割、横軸へ「閲覧・追加・編集・削除・管理・書き出し」を置いた権限表を作ります。設定画面で考え始めると、チェックボックスを埋めることが目的になり、なぜ許可するのかが曖昧になるからです。

たとえば経費・出張申請なら、次のように考えます。

申請者：自分の申請だけを追加・閲覧。申請中は必要な範囲だけ編集
承認者：担当する申請を閲覧し、承認判断に必要な項目を操作
経理：承認済みレコードと請求処理に必要な項目を閲覧
アプリ管理者：設定変更を担当。日常の申請業務とは分離
対象外ユーザー：アプリにも検索結果にも業務情報を出さない

承認済みになった後は、申請者が金額や用途を上書きできないようにします。修正が必要なら、差し戻しや再申請など履歴が残るルートへ戻す。アクセス権とプロセス管理は別機能ですが、実務では一緒に設計しないと「承認した内容が後から変わる」問題が残ります。

設定ミスが起きやすい5つの落とし穴

1．上にある広い条件が、下の制限より優先される

レコードのアクセス権で一人のユーザーに複数の設定が当たる場合、公式ヘルプでは上の行が優先されると説明されています。Everyoneを広く許可する条件が上にあると、下に置いた個別制限が期待どおり効かないことがあります。

条件を増やすほど安全になるとは限りません。「例外を先、一般条件を後」という順序を設計表にも書き、並び順までレビュー対象にします。

2．組織やグループを変えただけで安心する

レコード権限に組織やグループを使っている場合、メンバー情報の変更が既存レコードへすぐ反映されないケースがあります。公式ヘルプでは、最新情報を全レコードへ反映するにはアプリ設定の更新が必要と案内しています。

異動日にはユーザー所属だけでなく、対象アプリの更新と旧所属ユーザーでの再テストまで作業票に入れます。「人事マスターを直したから終わり」にしないことが大切です。

3．画面だけ確認して通知と書き出しを見ない

レコードを開けなくても、通知の件名や本文に顧客名・金額・案件名が表示されれば、情報は伝わります。CSV書き出しやファイル読み込みも日常の閲覧とは別に確認が必要です。

権限テストでは、一覧・検索結果・グラフ・通知一覧・メール通知・CSV・添付ファイルまで経路を洗い出します。「詳細画面が開けない」だけでは合格にしません。

4．例外を個人名で積み上げる

応援担当や代理承認者を個人名で追加し続けると、異動・退職のたびに設定が残ります。役割が継続するなら、組織やグループ（ロール）を使います。kintoneでは静的グループに加え、役職や組織などの条件で構成する動的グループも利用できます。

一時権限には、依頼者・目的・対象・開始日・解除日を残します。権限追加の手順だけがあり、解除の手順がない組織では、アクセス範囲は時間とともに広がります。

5．アプリ内の制限だけで外部連携も安全だと思う

APIや連携サービスが広い権限のアカウントで動けば、kintoneの画面を丁寧に制限しても、外側へ必要以上の項目を渡す可能性があります。連携用アカウント、取得項目、処理対象、結果の戻し先、エラーログの閲覧者を別途決めます。

公開前は4役×4経路でテストする

管理者の確認だけでは足りません。申請者、承認者、経理、対象外ユーザーの4役を用意し、架空の氏名と金額で確認します。本番データを使うと、テストそのものが情報漏えいになります。

最低限、次の項目をチェックします。

画面：アプリ、一覧、レコード、フィールドが役割どおりに見えるか
操作：追加・編集・削除・承認後の変更が想定どおりか
周辺経路：検索、通知、メール、グラフ、CSV、添付ファイルから漏れないか
例外：代理担当、異動者、兼務者、外部協力者で条件が衝突しないか

「見えるべき人に見える」だけでなく、「見えないべき人には、存在も内容も伝わらない」を確認します。さらに権限表へ設定理由と確認日を残せば、後任者が根拠を知らずに制限を外す事故を減らせます。

運用開始後は四半期ごとに権限の“負債”を返す

アクセス権は一度設定して終わりではありません。人が異動し、兼務が増え、アプリが外部サービスとつながるほど、当初の設計と現実がずれていきます。

四半期に一度、退職者・異動者・外部協力者・管理権限・一時権限・連携アカウントを確認します。例外条件が増え、誰にも説明できない設定になったら、権限を追加するのではなく、アプリ分割や業務フロー自体の見直しを検討します。

アクセス権の複雑さは、組織の曖昧さを映す鏡です。「誰が見るか」を決められないときは、設定方法より先に、誰が責任を持つ業務なのかを決める必要があります。

外部サービスとつなぐなら、承認済みデータだけを渡す

出張や購買をkintoneから外部サービスへつなぐ場合も、考え方は同じです。予約や発注に必要な最小項目だけを渡し、承認済みレコードだけを処理対象にし、結果を確認する人を決めます。

株式会社エイチの1Approval for kintoneを検討する場合も、「連携できるか」だけでなく、どのステータスの何の情報を渡すか、エラー時に誰が止めるかまで設計してください。自動化は権限確認を省く仕組みではなく、決めた権限と承認条件を繰り返し実行する仕組みです。

次の一歩：まず権限表を1枚つくる

今日やることは、設定画面を開くことではありません。対象アプリを一つ選び、縦に役割、横に閲覧・追加・編集・削除・管理・書き出しを書いた表を作ることです。そのうえで、入口・行・項目のどこで制限するかを決めます。

kintoneへAIを組み合わせる際の権限・人による確認まで考えたい方は、関連記事「kintone AIは何ができる？検索AI・アプリ作成AIを導入する前の7項目」も参考にしてください。このnoteで扱う業務自動化の全体像は「AIとGoogle Workspaceで、毎週の面倒な仕事を減らすnoteです」にまとめています。

権限表で矛盾を潰してからkintoneへ設定し、最後は対象外ユーザーの画面で確認する。この順番なら、チェックボックスの知識を、実際に情報を守れる運用へ変えられます。