読み込み中
豆知識
本番環境では、操作の種類に応じて以下のテーブルへ操作記録が残ります。
audit_logs ・ 全般的な操作document_audit_log ・ 書類の作成・編集・確定（電子帳簿保存法 7 年保持）journal_audit_log ・ 仕訳の作成・取消（電子帳簿保存法 7 年保持）link_audit_logs ・ 書類と銀行取引のリンク変更Admin 権限を持つメンバーがいない場合でも、Override 系操作はサポート（kensaurus@gmail.com）への申請を経た上で、サービス側のオペレータが事後確認前提で実行します。
一人社長は既定で自分の会社のオーナーであり、すべての操作を行えます。会社に協力者（記帳担当・レビュアー等）を招く「チーム機能」を使うと、招いたメンバーに次の 4 段階のロールを割り当てられます。
ロールは account_members.role に保存され、上位ロールは下位ロールの操作をすべて含みます。
| ロール | 位置づけ | できること（要点） |
|---|---|---|
owner |
会社のオーナー（＝あなた自身） | 自分の会社のすべての操作。メンバー管理を含む。メンバー行としては保存されない合成ロール |
admin |
管理者 | 業務データの作成・編集に加え、メンバーの招待・取り消し・ロール変更 |
editor |
編集者 | 業務データの作成・編集・削除（メンバー管理は不可） |
viewer |
閲覧者 | 閲覧のみ |
権限の序列は viewer < editor < admin < owner です。保存済みのロール値は viewer / editor / admin の 3 つで、過去の互換ロールは viewer に正規化されます。
flowchart LR
Viewer[viewer<br/>閲覧のみ] --> Editor[editor<br/>+ 業務データの作成・編集・削除]
Editor --> Admin[admin<br/>+ メンバー招待・取り消し・ロール変更]
Admin --> Owner[owner<br/>会社のオーナー本人]
サーバー側でロールを強制しているのは、いまのところメンバー管理の 3 操作だけです（requireRole('admin')）。
| 操作 | 必要ロール | 未満のとき |
|---|---|---|
メンバーを招待する（POST /members/invite） |
admin 以上 |
403 INSUFFICIENT_PERMISSIONS |
メンバー／招待を取り消す（DELETE /members/:id） |
admin 以上 |
403 INSUFFICIENT_PERMISSIONS |
ロールを変更する（PUT /members/:id/role） |
admin 以上 |
403 INSUFFICIENT_PERMISSIONS |
requireRole は上流ミドルウェアが解決した req.accountContext.role を読み、ROLE_ORDER（viewer=1 / editor=2 / admin=3 / owner=4）で比較します。自分の会社の操作（他人のアカウントに入っていない場合）は暗黙的に owner として扱われます。
アプリの画面では useActiveAccountRole フックがロールから次の派生値を計算し、書き込み系のボタンを出し分けます。これは UX のためのガードで、セキュリティ境界ではありません（最終的な拒否はサーバーの requireRole が行います）。
canWrite（作成・編集・削除の UI を表示）: owner / editor / admincanManageMembers（メンバー管理の UI を表示）: owner / adminviewer: 閲覧のみX-Account-Id（段階導入中）メンバーがアカウント切り替えで別のオーナーの会社を選ぶと、クライアントは X-Account-Id: <オーナーのユーザー ID> ヘッダーを送ります。サーバーはこのヘッダーからアクティブなアカウントのコンテキスト（req.accountContext）を解決します。
ただし業務データの読み取りをアカウント単位でスコープする処理は段階的に導入中で、現時点では多くの経路でメンバーは自分自身のデータを見ます。したがって、上記メンバー管理以外の「ロール別のデータ操作可否」はまだサーバーで強制されていません（[検証中]）。ドキュメント上でも、確認できていない権限セルは断定せず [検証中] として扱います。
税理士に帳簿を見てもらう場合は、チームのメンバーロールではなく共有リンクを使います。/auditor/:token の読み取り専用ビューで、証憑・ご確認事項・ご確認用資料一式を閲覧できます。トークンは失効・無効化でき、書き込みは一切できません。詳細は「税理士共有」を参照してください。
月次ロック（月末バリデーション）は、確定済み期間への書き込みをブロックする独立した仕組みです。ロックの解除など期間ロックまわりの操作とチームロールの結線は [検証中] で、確認でき次第このページに追記します。
member.service.ts（MemberRole = 'viewer' | 'editor' | 'admin'、normalizeMemberRole）require-role.middleware.ts（requireRole, ROLE_ORDER）auth.middleware.ts（resolveAccountContextMiddleware, X-Account-Id）use-active-account-role.ts（computeActiveAccountRoleState）このページは実装済みの挙動のみを記載しています。導入中の項目は [検証中] と明記し、確認でき次第更新します。
読み込み中
豆知識