アクセス権限

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

権限の3層構造

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

アプリ権限

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

• 優先順位 -- 上位のルールが優先。ドラッグで順序を変更できます
• 「全員」 -- アプリにアクセスできる全メンバーに適用されるベースライン
• 管理権限 -- フォーム設定・権限設定・ワークフロー設定などの管理操作
• インポート/エクスポート -- CSV操作の個別許可
• 「編集」「削除」は「閲覧」を含みます -- 「編集」または「削除」を許可した行は、「閲覧」も許可された形で保存されます（閲覧できないレコードは編集・削除もできないため）。API や AI 連携 (MCP) で設定した場合も同じです。「追加」だけを許可する設定はそのまま使えます

権限の対象

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

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

レコード権限

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

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

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

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

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

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

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

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

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

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

参照値で「本人」を決める

レコード権限の対象「フォームのユーザーフィールド」には、ユーザー選択フィールドのほかに、参照値フィールドも選べます（候補には「(参照値)」と付いて出ます）。 たとえば明細アプリが社員番号のルックアップで社員マスタを参照し、社員マスタの「対応ユーザー」を参照値で持っていれば、 「その社員本人だけが自分の明細を見られる」を、明細に本人を書き写さずに設定できます。社員マスタの対応ユーザーを直すと、明細の「本人」も自動で変わります。

使える条件と、設定の形（満たさない設定は保存できず、理由が表示されます）:

• 参照値の元をたどった先が「ユーザー選択」フィールドであること。参照値がさらに別の参照値を参照していてもかまいませんが、行き着く先がユーザー選択でないもの（氏名の文字列など）・組織やグループを参照するもの・集計や計算のフィールドは選べません（候補に出ません）
• 最後のルールを「対象者なし（全員）・条件なし・閲覧 / 編集 / 削除すべて不可」にすること。レコード権限は、どのルールにも一致しない人を既定で許可します。この最後のルールが無いと、参照値が空のレコード（社員マスタに対応ユーザーが未設定など）が全員に見えてしまうためです。条件を付けたルールは、この最後のルールの代わりになりません
• 参照値で対象を決めるルールより後ろに、許可を含むルールを置かないこと。参照値が空のレコードや、参照元の変更がまだ届いていないレコードが、後ろの許可に当たって意図より広く見えるのを防ぐためです。許可のルール（管理者・担当部署など）は参照値のルールより前に置きます。参照値のフィールドを 2 つ以上使うときは、1 つのルールの対象に並べます

動き方:

• 参照値が空のレコードは、本人のルールでは誰にも見えません（参照元に対応するレコードが無い・対応ユーザーが未設定）。前に置いたルールで許可した人（管理者・担当部署など）には見えるので、その人が参照元を直します
• 参照元の変更は、少し遅れて届きます（ふだんは 1 分ほど。大きな取り込みの直後などは、数分かかることがあります）。届くまでは、変更前の人が本人として扱われます（変更前の人に見え、変更後の人にはまだ見えません）
• 本人が変わっても、レコードの更新日時・変更履歴は動きません。いつ変わったかは、参照元のアプリ（社員マスタなど）の変更履歴で確かめます
• 参照元のフィールド（社員マスタの「対応ユーザー」など）を書き換えられる人は、そのレコードの本人を変えられます。 つまり、参照元の値を自分（や別の人）に書き換えるだけで、参照値の本人で守っているレコードを過去の分まで全部見られる状態を作れます （本人で閲覧を許可しているレコードの側の変更履歴には残りません）。 参照元のアプリの編集の権限（アプリの権限・レコードの権限・フィールドの権限）は、守っているレコードを見てよい人に絞ってください
• 公開ビューはレコード権限を見ません。公開ビューの設定で選んだレコードとフィールドが、そのまま公開されます（参照値で本人を決めていても、公開ビューには効きません）

参照元を変えるときの注意（アプリの管理者を含む全員に見えなくなる操作）:

次の操作をすると、参照値で本人を決めているアプリのレコードが、アプリの管理者・前のルールで許可した人を含む全員に見えなくなります（壊れた参照のまま、誰かに誤って見せないための安全側の動きです。レコードは消えていません）。

• 参照値の元になっているフィールド（参照先のアプリの「対応ユーザー」など）を削除する・フィールドの種類を変える
• 参照値がたどるルックアップの参照先を、別のアプリへ付け替える
• 参照先のアプリをゴミ箱に入れる
• 参照先のアプリのキーのフィールド（ルックアップが突き合わせるフィールド）を削除する
• 参照値がたどるルックアップのフィールドそのものを削除する（参照値のフィールドを残していても同じです）

フォームの設定で、参照値の元になっているフィールド・参照先のアプリのキーのフィールド・参照値がたどるルックアップのフィールドを削除して反映しようとすると、 反映の確認に「このフィールドを元にした参照値で、閲覧の権限を決めているアプリがあります」という予告が出ます（影響するアプリの名前つき）。 参照の段数やアプリの数が多くて調べ切れなかったときは、「使われている可能性があります」という予告になります。どちらの予告でも、反映する前にそのアプリのレコード権限を見直してください（権限の設定は自動では変わりません）。 次の場合は、この予告が出ません:

• フィールドの種類を変える反映（API・AI（MCP）で種類を変えた下書きを反映する場合）。反映は通り、上と同じく全員に見えなくなります
• 参照値をワークフローの「実行できるユーザー」だけに使っていて、閲覧の権限には使っていない場合。元のフィールドを削除すると、その操作は誰も実行できなくなります（ワークフロー）

直し方は、参照を元どおりたどれる状態に戻す（ゴミ箱から戻す・付け替えを戻す・削除したフィールドの代わりのユーザー選択フィールドを作って、参照値の参照元に設定し直す）か、権限の設定を直す（参照値の対象を外す・別のフィールドに替える）かのどちらかです。 参照先のアプリをゴミ箱から戻したときは、そのアプリを参照しているアプリのレコードの計算し直しが自動で始まり、終わると本人が元どおり入ります。

本人に使っている参照値フィールドの種類を変える・削除するとき:

• フィールドの種類を参照値へ変えた直後は、レコードの計算し直しが届くまで、そのアプリのレコードは本人のルールでは誰にも当たりません（前のルールで許可した人には見えます）。計算し直しは自動で始まります（レコードの数が多いアプリほど時間がかかります）
• 本人に使っている参照値フィールドを削除すると、そのフィールドは権限の対象から外れます（その対象だけのルールは、ルールごと削除されます。本人のルールが消えるので、本人にはレコードが見えなくなります）。同じフィールドコードで作り直しても、権限の対象は戻りません（フォームの設定で「削除して同じコードで追加」を 1 回の反映で行った場合も同じです）。 権限の設定 → レコードで、対象を選び直して保存してください。選び直した後も、レコードの計算し直しが届くまでは本人のルールは誰にも当たりません（計算し直しは自動で始まります）

ユーザー選択フィールドで本人を決めているアプリを、参照値に切り替える手順:

1. フォームの設定で、新しい参照値フィールドを追加して反映します（例: 「本人（マスタ）」= 社員番号のルックアップをたどって、社員マスタの「対応ユーザー」を参照）
2. 数分待ちます（既存のレコードの計算し直しが自動で走り、新しい参照値に値が入ります。待たずに次へ進んでも他の人に見えることはありませんが、計算し直しが届くまで本人にレコードが見えません）
3. 権限の設定 → レコードで、最後のルールが「対象者なし・条件なし・すべて不可」になっていることを確かめ（無ければ追加）、本人のルールの対象を、ユーザー選択フィールドから新しい参照値フィールド（「(参照値)」と付いた候補）に替えて保存します
4. 元のユーザー選択フィールドが不要なら削除します

API・AI（MCP）でフィールドの種類そのものをユーザー選択から参照値へ変える場合は、先に最後の「全員: すべて不可」のルールを追加して保存し、そのあとで種類を変えてください。 あわせて、本人のルールより後ろに、許可を含むルールが無いことも確かめてください（在れば、本人のルールより前へ移してから種類を変えます）。 順番が逆だったり、後ろに許可のルールが残っていたりすると、設定の形を満たさないまま参照値になるため、権限の設定を直すまで、アプリの管理者を含む全員にレコードが見えなくなります。

フィールドアクセス権

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

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

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

典型ユースケース

優先順位と動的対象

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

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

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

閲覧が制限された項目（検索・絞り込み・集計での扱い）

次のいずれかに当たる項目は、その人にとっての「閲覧が制限された項目」として扱われます。

• フィールドアクセス権で、その人が一部または全部のレコードで閲覧できない項目（動的な対象のルールで、レコードによって見えたり見えなかったりする項目を含みます）
• ワークフローのステータス毎のフィールド権限で、いずれかのステータスの「閲覧」を外している項目（アプリの管理者にも適用されます）
• 上の項目を使って計算する計算項目（サブテーブルの合計なども含みます）。閲覧できない項目を計算に使っている計算項目は、そのレコードでは値も表示されません（計算結果から元の値が分からないようにするため）

閲覧が制限された項目は、レコードを 1 件ずつ確かめずに値を扱う操作には使えません。件数や並び順から見えない値が推測されるのを防ぐための制限です。

• 絞り込み・並べ替え・グラフの分類軸と集計フィールド・CSV 書き出しの条件・メールの一斉配信の対象条件・CSV 取り込みの更新キー・一覧のスキャンアクションのキー項目には使えません
• キーワード検索と全体検索では、検索の対象から外れます（エラーにはなりません）
• 保存済みのビュー・グラフ・書き出しの条件にこれらの項目が含まれている場合、グループを使わない条件と並べ替えは、その条件を外して表示・集計・書き出しします。その場合、一覧・グラフ・エクスポートの画面に「条件を適用していません」という注記と外した項目の名前が表示されます（件数はその条件を除いた結果です）。 条件グループや表の条件に含まれている場合は「絞り込み条件が正しくありません。条件を確認してください。」と表示され、その一覧やグラフを開けません。 グラフの分類軸・集計フィールドに使っている場合は「閲覧が制限された項目は、この操作に使えません」と表示されます。いずれも、条件・軸から該当の項目を外してください
• 項目がこの扱いになるかは見る人ごとに決まります。ステータス毎のフィールド権限で閲覧を外した項目は、アプリの管理者の一覧・グラフでも使えません

一方、一覧・詳細・CSV 書き出し・帳票に出す値はレコードごとに判定します。一部のレコードでだけ見えない項目は、見えるレコードでは値が出て、見えないレコードでは空欄になります （列ごと出さないのは、すべてのレコードで見えないと分かる場合だけです）。

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

権限による表示の違い

権限の評価ルール

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

• 3 つの権限はすべて満たす必要があります（AND）。 アプリ権限で許可されていない操作は、 レコード権限・フィールドアクセス権で許可し直すことはできません（レコード／フィールドアクセス権はアプリ権限の範囲を狭める用途で、 広げることはできません）。 例: アプリ権限で「編集」 を OFF にすると、 レコード権限で作成者に「編集」 を付与しても編集できません。
• レコード権限は、どのルールにも一致しないと既定で許可されます。 特定の人だけに制限したい場合は、 許可ルールに加えて「対象者を指定しない（＝全員）」ルールで他を不可にします（下の活用例を参照）。
• レコード権限の優先順位 — ルールは上から順に評価され、最初に一致した1つのルールだけが適用されます（first-match。 以降のルールは評価されません）。 順序は「上へ／下へ」 で変更できます。
• フィールドアクセス権の優先順位 — 同一フィールド内では固有の対象（ユーザー／組織／グループ／動的対象）が「全員」より常に優先され、 固有の対象が複数該当する場合は上の行が優先されます（ドラッグで並び替え）。
• フィールドアクセス権の 3 軸はそれぞれ独立: 新規追加軸 (createAccess)・編集軸 (editAccess)・閲覧軸 (viewAccess) は別々に判定されます。 たとえば「閲覧軸 = 表示」 でも「編集軸 = 非表示」 なら、 編集画面でその field は見えません。
• アプリの管理者（権限行で管理者にされた人）にも、レコードのアクセス権・フィールドアクセス権がそのまま適用されます。管理者だからといって暗黙に制限を外れることはありません。管理者にすべて見せたい・触らせたいときは、レコード権限・フィールドアクセス権の 対象に「アプリの管理者」（上の「権限の対象」参照）を選び、明示的なルールを作ります。レコード権限・フィールドアクセス権に 規則を初めて追加すると、画面が先頭に「アプリの管理者: 全許可」の行を自動で置きます（保存前であれば消せます）。この先頭の 行を外した状態、または管理者を含まない・許可しない先頭の行のまま保存しようとすると、「アプリの管理者にも見えなくなる可能性があります」 という確認が表示されます。また、ワークフローのステータス毎のフィールド権限で「閲覧」を外した項目（とそれを使う計算項目）は、 「アプリの管理者: 全許可」の行があっても、そのステータスのレコードでは管理者にも表示されず、検索・絞り込み・集計にはどのレコードについても使えません。 なお、システム管理者・オーナーが自動で持つ管理権限はアプリの設定だけが対象で、レコードの データには関与しません（下の「注意事項」を参照）
• 閲覧できないレコードは、存在しないレコードと同じ扱いです。レコードを指定した更新・削除や、CSV 取り込みでの既存レコードとの照合では「見つからない」として扱われます （API ではレコードが無いときと同じ 404 を返します）
• 帳票・CSV エクスポート出力時にもフィールドアクセス権 (= 閲覧軸) が適用され、 閲覧軸が「非表示」 の field のデータは出力されません
• 一部または全部のレコードで閲覧できない項目は、絞り込み・並べ替え・集計・検索に使えません（上の「閲覧が制限された項目」を参照）

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

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

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

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

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

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

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

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

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

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

活用例

誰の権限で書き込むか

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

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

ワークフローの遷移は、ワークフローの担当設定 (担当者・追加で許可した人) が正本です。レコード権限は「閲覧できること」だけを要求し、 編集不可の行でもステータスは動かせます。API トークンは発行者の権限を借りますが、アプリ管理者には昇格しません。 アプリ管理者のための「強制的にステータスを変更する」「担当者を付け替える」などの管理の操作は、これらとは別の判定 （設定の管理 ＋ そのレコードをアクセス権で閲覧・編集できること）で行われます。詳しくはワークフローのページを参照してください。

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

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

注意事項

• デフォルトではアプリへのアクセス権はなしです。 明示的に権限を付与してください
• ただしアプリストアのパッケージから導入したアプリは、パッケージが宣言した役割に応じた権限が最初から入っています（前述の「パッケージが最初から設定する権限」）
• アプリの作成者は、作成時に自動付与される管理者権限を持ちます（この権限は他の管理者によって剥奪・別メンバーへの移譲が可能です）
• システム管理者・オーナーはすべてのアプリの設定を変更できます（フォーム・権限・ワークフロー等。作成者やアプリ管理者が退職・異動した場合の引き継ぎのため）。 ただしレコードの閲覧・追加・編集・削除は、そのアプリに設定されたアクセス権に従います（設定を管理できることと、レコードを見られることは別です。詳しくはアプリ管理（棚卸し）を参照してください）
• 権限設定の変更はアプリ管理者、またはシステム管理者・オーナーが実行できます
• 「管理」を持つ行をすべて外す保存（最後のアプリ管理者を外す保存）では、 「アプリの管理者がいなくなります」という確認が出ます。了承すると保存され、そのアプリはシステム管理者・オーナーだけが管理できるようになります。 もともとアプリ管理者の行が無いアプリ（パッケージから導入したアプリなど）は、確認なしでそのまま保存できます。 AI（MCP）からは最後のアプリ管理者を外す変更はできません（画面で確認のうえ保存してください）
• アプリ管理者が自分自身の「管理」を外す保存（ほかにアプリ管理者が残る場合）では、 「あなた自身がこのアプリを管理できなくなります」という確認が出ます。了承すると保存され、アプリのレコード一覧へ移ります。 以後は自分では元に戻せないため、ほかのアプリ管理者かシステム管理者・オーナーに依頼してください。 行の優先順位を当てはめた結果として自分の「管理」が残る場合（自分が属するグループや組織の行で管理できるなど）と、 システム管理者・オーナーの場合は、確認は出ません
• グループ・組織を削除すると、そのグループ・組織だけを対象にしていたレコード権限のルールは、一緒に削除されます（対象が無くなったルールを残すと「全員」が対象のルールに変わってしまうためです）。ほかの対象が残るルールは、そのグループ・組織が対象から外れるだけで残ります。 削除されたルールは、アプリの設定変更履歴に記録されます。同じ名前のグループ・組織を作り直しても、ルールは戻りません
• フィールドアクセス権はUI と API の両方で強制されます。 UI で隠している field を API 経由で送っても無視され、 閲覧軸が「非表示」 の field は API レスポンス・CSV エクスポート・帳票出力すべてから自動で除去されます

関連設定

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