アクセス権限

アプリ・レコード・フィールドの3段階で、きめ細かいアクセス制御を設定できます。 デフォルトではアプリへのアクセス権は付与されていないため、明示的に権限を設定する必要があります。

権限の3層構造

すべての権限チェックを通過した操作のみ実行されます。上位の権限で拒否された場合、下位の権限は評価されません。

アプリ権限

アプリ全体に対するアクセスレベルを設定します。設定は「権限設定」タブの「アプリ権限」から行います。

• 優先順位 -- 上位のルールが優先。ドラッグで順序を変更できます
• 「全員」 -- アプリにアクセスできる全メンバーに適用されるベースライン
• 管理権限 -- フォーム設定・権限設定・ワークフロー設定などの管理操作
• インポート/エクスポート -- CSV操作の個別許可

権限の対象

権限ルールの対象として、以下の種別を指定できます。

レコード権限ではこれらに加えて、レコードやログイン状況に応じて動的に判定される対象も指定できます:作成者・更新者・ログインユーザー、および フォーム上のユーザー/組織/グループ選択フィールドの値（例: 「担当者」フィールドにログインユーザーが含まれる場合）。

レコード権限

レコード単位で閲覧・編集・削除の可否を制御します。条件に一致するレコードに対して権限ルールを適用します。

上の例で「作成者だけが自分のレコードを編集・削除でき、他のユーザーは閲覧のみ」になります。ポイントは3つ: ① 対象者を指定しないルールは「全員」に一致します（②のように下に置くと「それ以外」として機能します）。 ② 作成者を許可するルールだけでは、一致しないユーザーは既定で許可されてしまうため、「全員＝不可」ルールを作成者ルールより下に置きます（上のルールが優先。上に置くと作成者も全員ルールに当たって不可になります）。 ③ 前提としてアプリ権限で編集・削除を ON にしておきます（レコード権限はアプリ権限の範囲内でのみ機能します）。

優先順位（first-match）: ルールは上から順に評価され、最初に一致した1つのルールだけが適用されます（以降のルールは評価されません）。「一致」とは対象（誰）と条件（どのレコード）の両方が当てはまることを指します。上の例では、作成者が自分のレコードを操作するときは先にルール1へ一致するためルール2は無視され、編集・削除が許可されます。それ以外のユーザーはルール1に一致せず、ルール2（全員）に一致して閲覧のみになります。どのルールにも一致しない場合は既定で許可されます。ルールの順序は「上へ／下へ」で変更できます。

レコード権限の条件には「フィールド値」も使用できます。例えば、ユーザー選択フィールドの値がログインユーザーと一致する場合のみ編集を許可する、といった設定も可能です。

条件にワークフローステータスを使う（(ステータス)）

ワークフローにステータスを定義したアプリでは、条件フィールドの先頭に特別な項目 「(ステータス)」が追加されます（ワークフロー自体の有効／無効は問いません）。 これは通常のフィールドではなく、レコードの現在のワークフローステータスを 条件に使うための専用の項目です（例:「ステータス = 承認済み → 経理グループのみ削除可」）。

• 演算子は「=」「!=」の2つだけ使用できます（大小比較・部分一致等の他の演算子は選べません）
• 値は、そのアプリで定義済みのステータスから選びます（通常のフィールド条件のようなテキスト入力ではなく、色付きのドロップダウンで選択）
• ワークフローが無効化されている間、レコードは「ステータスなし」として扱われます（そのため、この条件が「=」の場合は常に不一致、「!=」の場合は常に一致になります。意図せず全員に許可が広がる／全員から拒否されることはありません）
• 条件で参照していたステータスが後から削除された場合も同様の帰結になります（「(削除されたステータス)」として表示されたまま条件自体は残りますが、削除されたステータスを指す条件はどのレコードの現在ステータスとも一致しなくなるため、「=」条件は常に不一致、「!=」条件は常に一致になります。 意図せず全員に許可が広がる／全員から拒否されることはありません）
• ワークフローの「ステータスごとの保護設定」（設定 → ワークフロー）と同時に評価され、どちらかが拒否すれば操作は拒否されます。 「承認済みは編集不可」のような単純な制御は、この条件を組む代わりにワークフロー側の保護設定（編集の保護 = ロック 等）で完結させることもできます
• さらに「期間ロック」が設定されている場合、指定した期間・対象者に該当するレコードは、上記のアクセス権やワークフロー保護設定の結果に関わらず編集・削除できません。 期間ロックはアプリ管理者を含め誰にもバイパスできない点が、他の権限設定と異なります

条件にユーザー／組織／グループ選択フィールドを使う

条件フィールドにユーザー選択・組織選択・グループ選択フィールドを選んだ場合、値は自由入力ではなく一覧からの選択（ピッカー）になります（例:「営業担当 = 山田さん → 経理グループは閲覧不可」）。

• 演算子は「=」「!=」の2つだけ使用できます（大小比較・部分一致は選べません）
• 「=」は選んだユーザー（組織／グループ）がフィールドに含まれること、「!=」は含まれないことを意味します。フィールドに複数のユーザーが設定されている場合は、いずれか 1 人が一致すれば「=」に一致します
• フィールドが未設定のレコードは「=」条件には一致しません（「!=」条件には一致します）

フィールドアクセス権

フィールド単位で「新規追加」「編集」「閲覧」の 3 つの画面ごとにアクセス権を制御します。 機密情報を隠す用途だけでなく、 「ステータスは新規時には選ばせない」「契約番号は一度登録したら変更不可」 など 運用上の入力ガード用途にも使えます。

プリセット (= 典型的な 5 パターン)

よく使う組合せはプリセットとして用意されています。 プリセットを選ぶと 3 つの dropdown が 自動で設定されます。 後から個別に dropdown を変更した場合は「カスタム」 表示になります。

典型ユースケース

優先順位と動的対象

優先順位: 同一フィールド内では固有の対象（ユーザー / 組織 / グループ / 動的対象）が「全員」より常に優先されます。 固有の対象が複数該当する場合は上の行が優先されます（行はドラッグで並び替え可能）。 どの固有ルールにも該当しないときに「全員」（既定・フォールバック）が適用されるため、「全員」 は各フィールドの末尾に固定されています。

フィールドアクセス権の対象には、ユーザー / 組織 / グループ / 全員 に加えて、 レコードごとに判定される動的な対象も指定できます:作成者・更新者・ログインユーザー・ワークフローの現在の担当者、 および フォーム上のユーザー / 組織 / グループ選択フィールドの値（例: 「担当者」フィールドにログインユーザーが含まれる場合）。

ワークフローの現在の担当者は、 そのレコードのワークフローで今のステータスの担当者になっている人にだけ一致します。 レコードに担当者がピン留めされている場合は、 そのステータスの担当者設定（指定ユーザー・誰でも等）に関わらず、ピン留めされた人だけが一致します。 例えば「申請中ステータスは申請者本人だけが編集できる」「承認待ちステータスは承認者だけが編集できる」といった、 ステータスごとに編集可能な人を切り替える運用に使えます。 新規作成フォーム（レコードがまだ無い状態）では常に一致しません。 ワークフローが無効なアプリや、 担当者が「誰でも」のままピン留めもされていないステータスでも同様に誰にも一致しません。

ただし、 動的な対象を含むフィールドアクセス権が設定されたフィールドは、検索・絞り込み・並び替え・集計の対象から除外されます。 これはレコードを取得せずにクエリを実行する場面で情報が漏れるのを防ぐための制限です。 CSV エクスポートも同様に保守的に扱われ、 動的な対象（ワークフローの現在の担当者を含む）のルールが設定された列は、 管理者以外のエクスポートでは出力されません（一致する人がレコードごとに変わるため、 一括出力の時点では判定できないことによる制限です）。

サーバー側強制: フィールドアクセス権は UI だけでなくサーバー側 API / CSV インポート / 公開フォーム / 一括更新 / 帳票出力 のすべての経路で強制されます。 UI で隠している field が API 経由で送られても無視され、 閲覧不可の field は API レスポンスから自動で除去されます。

権限による表示の違い

権限の評価ルール

1. アプリ権限をチェック — アプリへのアクセスが許可されているか
2. レコード権限をチェック — そのレコードに対する操作が許可されているか
3. フィールドアクセス権をチェック — そのフィールドが操作中の画面（新規追加 / 編集 / 閲覧）で表示・編集可能か

• 3 つの権限はすべて満たす必要があります（AND）。 アプリ権限で許可されていない操作は、 レコード権限・フィールドアクセス権で許可し直すことはできません（レコード／フィールドアクセス権はアプリ権限の範囲を狭める用途で、 広げることはできません）。 例: アプリ権限で「編集」 を OFF にすると、 レコード権限で作成者に「編集」 を付与しても編集できません。
• レコード権限は、どのルールにも一致しないと既定で許可されます。 特定の人だけに制限したい場合は、 許可ルールに加えて「対象者を指定しない（＝全員）」ルールで他を不可にします（下の活用例を参照）。
• レコード権限の優先順位 — ルールは上から順に評価され、最初に一致した1つのルールだけが適用されます（first-match。 以降のルールは評価されません）。 順序は「上へ／下へ」 で変更できます。
• フィールドアクセス権の優先順位 — 同一フィールド内では固有の対象（ユーザー／組織／グループ／動的対象）が「全員」より常に優先され、 固有の対象が複数該当する場合は上の行が優先されます（ドラッグで並び替え）。
• フィールドアクセス権の 3 軸はそれぞれ独立: 新規追加軸 (createAccess)・編集軸 (editAccess)・閲覧軸 (viewAccess) は別々に判定されます。 たとえば「閲覧軸 = 表示」 でも「編集軸 = 非表示」 なら、 編集画面でその field は見えません。
• アプリ管理者はフィールドアクセス権を含むすべての権限チェックをバイパスします
• 帳票・CSV エクスポート出力時にもフィールドアクセス権 (= 閲覧軸) が適用され、 閲覧軸が「非表示」 の field のデータは出力されません

設定したフィールドアクセス権が一般メンバーにどう見えるかは、フォーム設定の「プレビュー」 で 「視点」 を「すべてのユーザー」 に切り替えると、本番に適用する前に確認できます（非表示フィールドは消え、読み取り専用は ロックアイコンで表示）。

パッケージが最初から設定する権限

自分で作ったアプリの権限が「なし」から始まるのに対し、アプリストアのパッケージには、権限が設定済みの状態で入るものがあります（「勤怠」「共通マスタ」）。導入直後から「他人の勤怠は見えない」状態で使い始められるようにするためです。

• パッケージは役割（「打刻する人」「申請を承認する人」「勤怠を管理する人」など）を宣言しており、導入時にそれぞれの担当者を指定します。指定しなければ宣言された既定が使われます。詳しくはアプリストアと導入済みパッケージを参照してください
• 役割はグループとして作られ、アプリ権限・レコード権限の対象になります。担当者を入れ替えたいだけなら、グループのメンバーを変えるのがいちばん簡単です（アプリを 1 つずつ開く必要はありません）
• パッケージが作った権限に特別な保護はありません。ふつうのアプリと同じように、設定 → 権限から自由に変更・削除できます
• 役割のグループはパッケージをアンインストールしても残ります（他のアプリの権限にも使われている可能性があるため）。不要になったらグループ管理から削除してください

役割を宣言していないパッケージ・サンプルアプリは、これまでどおり導入した人が管理者、レコードは全員が操作できる状態で作られます。業務で使う前に、このページの内容に沿って絞り込んでください。

パッケージのレコード権限を編集するときの注意

レコード単位で絞っているアプリ（勤怠パッケージの日次勤怠・勤怠申請など）では、レコード権限が上から次の順に並びます。マスタ類のようにアプリ権限だけで足りるアプリには、レコード権限が 1 行も入りません。

1. 全件を扱う役割（勤怠を管理する人）＝ 許可
2. 自分に紐づく行だけの役割（本人・その申請の承認者）＝ 許可
3. 最下段に対象者を指定しないルール ＝ 不可（シフト表だけは「閲覧のみ可」）

最下段が絞り込みの本体です。レコード権限はどのルールにも一致しないと許可されるため（前述の評価ルール）、この行を消すと上に並んだ許可ルールは何も制限しなくなり、全員に全件が見えます。「許可ルールだけを並べても絞れない」のはパッケージが作った権限に限らず、レコード権限そのものの性質です。

• 行を足すときは最下段より上に入れてください（下に置いても評価されません）
• 「見えるはずの人に見えない」ときは、その人が役割のグループに入っているかをまず確認します（アプリ権限で許可されていても、レコード権限の最下段で止まります）
• 逆に広げすぎた場合はエラーになりません。権限を編集したら、対象外の利用者でログインして確認するか、フォーム設定の「プレビュー」で視点を切り替えて確かめてください

活用例

誰の権限で書き込むか

レコードへの書き込みは 7 種類の鍵で守られています。アプリ権限、レコード権限、アプリの状態、期間ロック、 ワークフローの編集制限、項目権限、ステータス別の項目権限です。どの鍵が誰に効くかは次の 4 つの規則で決まります。

1. 値を決めた人の権限で項目を書く。 フォームや API で入力した値、転記や複製で別のレコードから写す値は、操作した人の項目権限で判定します。アクションボタンの固定値・現在時刻・本人参照や、入力ルールの自動セットのように管理者が設定で固定した値は、その設定を保存した管理者が書けると決めた項目にだけ書けます (押した人の項目権限は見ません)。
2. 行に触れるかは常に操作した人で判定する。 アプリ権限・レコード権限・ワークフローの担当者制限は、ボタンや自動化でも借りられません。
3. 全員に効く鍵は管理者にもボタンにも効く。 期間ロック、ロック状態、ステータス別の項目権限は、アプリ管理者や作者の設定でも迂回できません。
4. 実行した人は常に記録される。 権限の主体が設定でも、作成者・更新者には操作した人が入ります。

ワークフローの遷移は、ワークフローの担当設定 (担当者・追加で許可した人) が正本です。レコード権限は「閲覧できること」だけを要求し、 編集不可の行でもステータスは動かせます。API トークンは発行者の権限を借りますが、アプリ管理者には昇格しません。

ユースケース別 設定ガイド

よくある業務アプリを例に、現場で求められる権限要件をどう設定するかを解説します。 3つの権限（アプリ／レコード／フィールド）はすべて満たす必要があり（AND）、 レコード／フィールド権限はアプリ権限の範囲を狭める用途で使います。

注意事項

• デフォルトではアプリへのアクセス権はなしです。 明示的に権限を付与してください
• ただしアプリストアのパッケージから導入したアプリは、パッケージが宣言した役割に応じた権限が最初から入っています（前述の「パッケージが最初から設定する権限」）
• アプリの作成者は、作成時に自動付与される管理者権限を持ちます（この権限は他の管理者によって剥奪・別メンバーへの移譲が可能です）
• システム管理者・オーナーはすべてのアプリの設定を変更できます（フォーム・権限・ワークフロー等。作成者やアプリ管理者が退職・異動した場合の引き継ぎのため）。 ただしレコードの閲覧・追加・編集・削除は、そのアプリに設定されたアクセス権に従います（設定を管理できることと、レコードを見られることは別です。詳しくはアプリ管理（棚卸し）を参照してください）
• 権限設定の変更はアプリ管理者、またはシステム管理者・オーナーが実行できます
• フィールドアクセス権はUI と API の両方で強制されます。 UI で隠している field を API 経由で送っても無視され、 閲覧軸が「非表示」 の field は API レスポンス・CSV エクスポート・帳票出力すべてから自動で除去されます

関連設定

• フォームのレイアウト — 設定 → フォーム。 フィールドの並び順や見出しを変更したい場合 (= 単なる並び替えはフォームレイアウトで、 アクセス制御はフィールドアクセス権で行います)
• レコード権限 — 設定 → 権限 → レコード。 「自分の担当レコードだけ閲覧」 などレコード単位の絞り込み
• アプリ権限 — 設定 → 権限 → アプリ。 アプリ全体の閲覧 / 追加 / 編集 / 削除 / インポート / エクスポート / 管理 のベース許可