内部ポリシーの承認を追跡するWebアプリを作る

ポリシー承認トラッキングが解決する課題

ポリシー承認トラッキングとは、特定の人が特定の内部ポリシーの特定のバージョンを、特定の時刻に承認したことを記録するプロセスです。「従業員のポリシー承認」を想像してください。ただし、後で検索できて一貫性があり、証明しやすい形で保存されます。

誰が使うか（そしてその理由）

異なるチームが異なる理由で関心を持ちます：

• 人事（HR）：ハンドブック更新、職場行動、リモートワーク、福利厚生、休暇ルール
• IT/セキュリティ：許容される使用、パスワード/2FA基準、デバイス管理、データ取り扱い
• 法務／コンプライアンス：規制ポリシー、利害関係の衝突、内部通報手続き
• マネージャー：チームが必要な承認を完了したことを確認（特に変更後）

なぜメールやPDFの署名が破綻するか

メールスレッドや「返信で確認」ワークフローは単純に見えますが、きれいに証明する必要が出たときに問題になります。

よくある失敗例：

• 証拠が散逸する：返信が個人の受信箱、共有メールボックス、古いチケットに埋もれる
• バージョン管理がない：更新後に誰がどの文言を承認したか証明できない
• レポーティングが弱い：「最新の更新をまだ承認していないのは誰か？」の回答が手作業になる
• 監査が大変：内部レビューや外部監査に信頼できる記録を用意するのに何日もかかる

トラッキングアプリの目標

Webアプリは監査対応可能な承認記録を生成すべきです。つまり、改ざんに強い問いに対する明確な答えを出せること：

• 誰が承認したか
• どのポリシーか
• どのバージョンか
• いつ（可能ならどのセッション／システムからか）

多くの場合、社内ポリシーに対する本格的な署名ツールを使うほどではない場面での実用的な電子署名の代替になります。

期待値の設定：小さく始める

まずは必須項目（ポリシー、バージョン、ユーザー、タイムスタンプ）をキャプチャし、基本的なリマインダーをサポートするMVPから始めます。これが機能したら、SSOやアクセス制御、エスカレーション、自動化、より強いレポーティングやエクスポートを追加していきます。

要件とステークホルダーの定義

画面設計や技術選定の前に、システムの利用者と組織上の "承認" の意味合いを合意しておきましょう。HR、セキュリティ、法務が後でギャップを指摘すると手戻りが生じます。

ステークホルダーの特定（とそれぞれのゴール）

多くのツールは以下の4つの主要な利用者にサービスを提供します：

• 従業員：どのデバイスでも素早くアクセスして承認できること
• ポリシーオーナー（HR、セキュリティ、法務、ファイナンス）：更新を公開し、適切な対象に配信し、完了状況を確認すること
• 管理者（IT、People Ops）：ユーザー、グループ、連携、例外（退職者、契約者、名前変更）を管理すること
• 監査人／マネージャー：編集できない形で「誰が何をいつ承認したか」を証拠として取得すること

各グループの成功基準を明文化しましょう。例：セキュリティは「入社後7日以内の承認」を重視するかもしれませんし、人事は「特定の勤務地に適用されること」を重視するかもしれません。

「承認」とは何かを定義する

必要な証拠レベルを明確にします：

• チェックボックス＋送信（一般的なベースライン）：「読んで同意しました」とタイムスタンプ
• 氏名の入力：誤クリックの主張を減らす
• OTP／再認証ステップ：フル電子署名なしでリスクの高いポリシーに有効
• 電子署名の代替：法務がより強い否認防止を求める場合、最小限の管理（本人確認、改ざん検知ログ）を文書化

承認が有効となる条件（ポリシーを開くだけで良いのか、閲覧／スクロールが必須か）もルール化しておきます。

追跡するポリシーの種類と適用範囲

まず追跡したいポリシーを書き出します：行動規範（Code of Conduct）、情報セキュリティ、リモートワーク、NDA追加条項、各国・地域の規制に基づく確認など。ポリシーが国や法人、役割、雇用形態（従業員 vs 契約者）で分かれるかも記録します。

サポートすべきコンプライアンス要件

最低限確認すべき点：

• 監査証跡と承認イベントの不変性
• 保持期間（保持後はどうするか）
• **エクスポート（CSV/PDF）**を誰が生成できるか
• 内部レビュー向けの証拠と外部監査向けの証拠の差

既存のプロセス（オンボーディングチェックリスト、HRISワークフロー）と重なる部分があれば今のうちにメモしておき、後の連携設計に役立てます。

承認ワークフローのマッピング

明確なワークフローは承認を一貫して監査対応可能にします。まずは最小限の経路を決め、規制やリスク、研修要件がある場合にのみオプションを追加します。

最もシンプルなエンドツーエンドフロー

1. ポリシーを公開：管理者がポリシーを「公開済み」にし、発効日を設定

2. 従業員に通知：システムがメール／Slack／Teamsでポリシーへのリンクを送信

3. 従業員が承認：従業員がログインしてポリシーを読み、「承認する」をクリック。タイムスタンプとポリシーバージョンを記録

4. レポート：コンプライアンスや人事が完了率を確認し、承認リストをエクスポート

この流れで多くの組織は十分です。重要なのは「誰が」「どのバージョンを」「いつ」承認したかを信頼できる形で証明できることです。

検討すべきオプションステップ

クイズや理解度チェック

安全性、財務、規制に関わるポリシーには短いクイズを入れて理解度を測り、スコアを保存します。合格しないと承認を許可しないかどうかも決めます。

更新時の再承認

ポリシーが更新された場合、それがマイナーな修正（再承認不要）か重要な変更（再承認必須）かを判断します。実用的には、発行者が新バージョンで「承認が必要」を選択した場合のみ再承認をトリガーする方法が使いやすいです。

マネージャーのフォローアップ

マネージャー向けに、誰が期限超過かが見える軽量ビューを追加し、督促や例外の記録を行えるようにします。

承認ウィンドウとエスカレーション

標準の承認ウィンドウ（例：通知から14日）とエスカレーションルールを定義します。例：

• 7日後にリマインダー（未承認の場合）
• 12日後に2回目のリマインダー
• 14日でマネージャーやHRへエスカレーション

例外（休職、契約者、役割ベースの除外）は明確にします。

承認がアクセスを制御すべきか？

リスクの高いポリシーでは、特定のツール利用前に承認を要求することが考えられます（例：経費システム、顧客データプラットフォーム）。その場合はワークフローで「未承認の場合はアクセスを制限」するか「アクセスは許すがエスカレーションする」かを明記し、実運用への影響が最小になる選択をします。

ポリシーのコンテンツ、バージョニング、チェンジコントロール

監査や内部レビューで通用する承認記録を得るには、各承認が正確なポリシーバージョンを指している必要があります。「行動規範を承認した」は曖昧ですが、「行動規範 v3.2（発効 2025-01-01）を承認した」は検証可能です。

公開された各ポリシーバージョンを不変として扱う

ポリシーは公開後に編集されることがよくあります（誤字修正、フォーマット修正、追記）。もしアプリが単に「最新の本文」しか保存しないと、過去の承認がいつの間にか異なる本文を指すことになります。

代わりに、公開ごとに新しいバージョンを作成し、そのバージョンを読み取り専用で保存します：

• 不変のスナップショット（一般的には生成されたPDF）を保存する、または
• 承認時に表示されたレンダリング済みのHTMLを正確に保存してロックする

こうすることで、従業員が「何を見たか」を後から再現できます。

バージョンごとに保存すべきメタデータ

ポリシー本文とポリシー識別子は分けて管理します。安定したPolicy ID（例：HR-COC-001）があるとすべてのバージョンを紐づけられます。

各発行バージョンには次を保存してください：

• バージョン番号（v1.0, v1.1 など）
• 発行日／有効日
• オーナー（担当チーム／人）
• 変更概要（何が変わったかを平易に記載）

このメタデータは従業員の信頼を高め、なぜ再承認が必要かを説明できます。

再承認ルール（重大変更 vs 軽微変更）を定義する

すべての編集で再承認を要求する必要はありません。シンプルなルール例：

• 重大な変更（義務、罰則、安全手順の変更）：再承認を必須にする
• 軽微な変更（フォーマット、リンク修正、誤字）：再承認不要

UI上はバージョンごとに「再承認が必要」フラグを用意し、承認画面で短い理由を表示します。

データモデル：保存すべきもの

明快なデータモデルこそが承認トラッキングを信頼できるものにします。目標はいつでも「誰が何をいつまでに承認する必要があり、どんな証拠があるか」を答えられることです。

コアテーブル／オブジェクト

最低限想定するオブジェクト（名称は技術スタックに合わせて変更可）：

• Users：従業員ID、メール、氏名、ステータス（在籍／退職）、部署、勤務地、マネージャーなど
• Policies：恒常的なコンテナ（例：Code of Conduct）、タイトル、オーナー、カテゴリ、ステータス（下書き／公開／廃止）
• PolicyVersions：各発行リビジョン。バージョン番号、発行日、有効日、コンテンツ参照（HTML/markdownまたはファイルストレージへのポインタ）
• Assignments：誰がどのPolicyVersionを受けるか。部署／場所／グループ／特定ユーザーでターゲティングし、期日とルールを持たせる
• Acceptances：承認イベント（user + policyVersion + assignment に紐づく）
• Reminders（任意）：スケジュールされた通知、最終送信時刻、エスカレーションレベル

ステータスとターゲティング

ステータスはユーザー×バージョン単位で管理します：

• pending（割り当て済みだが未承認）
• accepted（このバージョンを承認済み）
• expired（新しい必須バージョンにより以前の承認が無効）
• exempt（明示的に対象外、理由あり）

ターゲティングのために、部署や勤務地はUserレコードに含めるか、結合テーブル（Departments, Locations, UserDepartments）で管理します。

証拠フィールド（あなたの「証拠」）

Acceptancesには次を記録します：

• 承認のタイムスタンプ（サーバー時刻）
• policyVersionId（承認された正確なテキスト）
• 任意でIPアドレスやユーザーエージェント（プライバシーポリシーが許す場合）
• 承認方法（web、mobile、kiosk）
• 追加で、整合性チェック用に「承認文言」やハッシュを保存することも可能

認証、ロール、アクセス制御

承認アプリの信頼性はアイデンティティと権限に依存します。各「承認」が正しい人物に紐づき、誰が何を変更できるかが明確であることが重要です。

サインインオプション

中〜大規模組織ではSingle Sign-Onを推奨します：

• SSO（OIDC または SAML）：中央管理、パスワード削減、オフボーディングが容易
• メール＋パスワード：IdPがない小規模組織向け。可能ならMFAを追加

両方をサポートする場合は、利用可能ならSSOを優先し、パスワードログインは契約者やパイロット向けのフォールバックにします。

役割と権限

役割は現実の責任に即したシンプルさを保ちます：

• Employee：割り当てられたポリシーを閲覧し、承認・履歴を見る
• Policy owner：下書き作成、編集提案、完了監視。公開後に履歴を書き換えられない
• Admin：ユーザー管理、オーナー割当、設定、公開制御
• Auditor（読み取り専用）：記録検索とエクスポート。ポリシーや割り当ては変更不可

ミスを防ぐためのアクセスルール

認可レイヤーにいくつかの厳格なルールを設けます：

• 公開できるのは管理者のみ（バージョンの公開／非公開／廃止）
• オーナーは下書きを作成できるが、公開後に履歴を上書きできない
• 監査人はエクスポートできるが、その操作はログ化され、スコープ制限されるべき

オフボーディングと記録保持

ユーザーが退職しても承認記録を削除してはいけません。代わりに：

• アカウントを無効化（IdPでの無効化に依存しても良い）
• 承認はユーザーID＋当時の表示名／メールを残して保持
• 退職者のプロファイル表示は管理者／監査人に制限し、履歴は監査対応可能な形で保存

アプリに含めるべきUX画面

良いUXは「ポータルがある」から「実際に期日通り完了する」へと変えます。画面は少なく、次のアクションが明確で、後で何が起きたかを証明しやすい設計にします。

従業員向け画面

1) My Policies（ダッシュボード）

最もよく使われるホーム画面です。割り当てられたポリシーに対して次を表示します：

• 期日と緊急度（例：「あと5日で期限」）
• ステータス（未着手／開封済み／承認済み）
• 明確な主要アクション（「確認して承認」）

「延滞」「完了済み」の簡易フィルタと、大規模組織向けの検索を加えます。

2) Read & Accept（閲覧して承認）

閲覧体験は気が散らないように。ポリシータイトル、バージョン、有効日を見せ、末尾に目立つ承認セクションを置きます。

PDFを表示する場合はモバイルで読めるように（レスポンシブビューア、ズーム、ダウンロードリンクのフォールバック）。アクセシビリティのためにHTML版も提供すると良いです。

3) Acceptance History（承認履歴）

従業員自身が何をいつ承認したか確認できるようにします。ポリシー名、バージョン、承認日時、承認したバージョンへのリンクを表示し、サポート問い合わせを減らします。

管理者／オーナー画面

1) ポリシーエディタ

管理者はポリシーレコードを作成し、コンテンツをアップロードし、将来の再承認サイクルのために短い「何を変更したか」の概要を書ける必要があります。

2) 公開と対象割当

下書きと公開は分けます。公開画面は誤って古い版を送らないようにし、誰に割り当てられるか（部署、場所、ロール、もしくは全社員）を明確に示します。

マネージャー画面（任意）

シンプルな「チーム完了状況」ページがあれば十分です：完了率、延滞者リスト、一括で督促を送るワンクリックなど。

アクセシビリティの基本

UIラベルは平易にし、キーボード操作をサポート、スクリーンリーダー用の適切な見出しとボタンラベルを用意し、コントラストを高く保ちます。モバイルファーストで設計して、従業員がラップトップなしでも承認できるようにします。

監査証跡と承認の証明

監査証跡は信頼に足るものでなければ意味がありません。監査人や内部調査では「どのポリシーバージョンが提示され、誰に配信され、どのアクションがいつ行われたか」を改ざん不能な形で示す必要があります。

監査証跡を信頼できるものにする要素

強い証跡は次の4点を備えます：

• 不変のイベント：一度記録されたイベントは編集／削除できない（修正が必要なら新しいイベントで説明）
• 信頼できるタイムスタンプ：全イベントにサーバー側のタイムスタンプとタイムゾーンを記録
• 実行者の識別：誰が行ったか（従業員、マネージャー、管理者、システム）とユーザーID、認証方法を保存
• コンテキスト：ポリシーID＋正確なバージョン、ユーザーがターゲットになった割当スコープ（チーム、場所、ロール）を保存

ログすべきイベント

最低限ログに残すべきイベント：

• ポリシー公開（バージョン番号と有効日を含む）
• 割当の作成／変更（誰が割り当てられたか、どのルールや管理者アクションによるか）
• リマインダー送信（チャネル、受信者、使用したテンプレート／バージョン）
• 承認送信（ユーザー、タイムスタンプ、ポリシーバージョン、Web/モバイル等）

他にも「ポリシーのアーカイブ」「ユーザー無効化」「期限変更」などを追加できますが、コアイベントは一貫して検索可能にしておきます。

監査向け記録を守るためのセーフガード

信頼性を損なう機能は避けます：

• 承認を削除できないようにする（UIやDBから削除不可）。無効化が必要ならvoidedフラグと理由を付け、その操作をログに残す
• 管理者ノートでの訂正：管理者が訂正を行う場合は元の承認を編集するのではなく説明イベントを追加する
• 証拠フィールド：必要に応じてIPアドレス、ユーザーエージェント、送信ハッシュを保存して署名なしでも証明力を高める

「既読」通知と承認の違い

ページの開封やスクロール、滞在時間は「既読」シグナルであり、証明力は弱いです。承認は明示的なアクション（チェックボックス＋送信、氏名入力、"承認"ボタン）であり、特定バージョンに紐づきます。既読は補助的なメタデータとして扱います。

通知、リマインダー、エスカレーション

通知は「ポリシーを公開した」だけで終わらせず、確実に承認を集める仕組みの一部として設計します。

人々の働き方に合ったチャネルを選ぶ

多くのチームが複数チャネルを使います：

• メール：公式で検索可能
• Slack／Teams：迅速な対応率が高い
• アプリ内通知：ポータル内のユーザー（特に管理者／マネージャー）向け

管理者はポリシーキャンペーンごとに使うチャネルを切り替えられるとスパムを避けられます。

リマインダールールの設計（止め方も明確に）

推奨カデン：初回通知、3日後にリマインダー、その後は期限まで週次で。止める条件を明確に：

• 承認後は即停止
• 免除やプロファイル無効化、キャンペーン終了で停止

期限超過者には（従業員→マネージャー→コンプライアンス）とエスカレーションします。エスカレーションは日数ベースで行い、常に期日を含めます。

アクションを促すテンプレートを使う

テンプレートは自動で以下を含めるようにします：

• ポリシー名
• バージョン／有効日
• 期日（ある場合）
• 承認画面へのワンリンク（例：/policies/123/accept）

文面は短く具体的に、チャネル間で一貫させます。

ローカライズを忘れずに

多言語の従業員がいる場合はテンプレート翻訳を保存し、ユーザーの優先言語に基づいて送信します。最低限、件名とコールトゥアクションはローカライズし、翻訳がない場合はデフォルト言語にフォールバックします。

レポート、ダッシュボード、エクスポート

レポーティングによってポリシー承認トラッキングが実務的なコンプライアンスツールになります。目的はチャートで埋め尽くすことではなく、頻出の質問に迅速に答えること：「完了しているか？」「誰が遅れているか？」「このバージョンを証明できるか？」

重要な指標

まずはアクションにつながる指標を表示：

• 各ポリシーバージョンの完了率（accepted / assigned）
• 延滞ユーザー（数と一覧、マネージャーやチームでグルーピング）
• 時間経過における承認数（日次／週次トレンド）
• 任意で：承認までの日数（割り当てから承認までの中央値）

ダッシュボードでこれらを一目で見られるようにします。

フィルタとドリルダウン

数値はクリック可能にして、基となる人物や記録へドリルダウンできるようにします。一般的なフィルタ：

• 部署／チーム
• 場所／サイト
• ポリシーとポリシーバージョン
• 日付範囲（割当日、期日、承認日）
• ステータス（承認済み、未承認、延滞、免除）

契約者などのワーカー種別をサポートする場合は、必要な場合のみフィルタを追加します。

エクスポートと「監査パケット」

監査要求にはエクスポートが最速の場合が多いです：

• CSVエクスポート：スプレッドシート分析用（安定ID、タイムスタンプ、ポリシーバージョンを含む）
• PDFエクスポート：人が読む用の要約
• ポリシーバージョンごとの監査パケットビュー：ポリシータイトル＋バージョン、公開／有効日、割当られた人、承認した人（タイムスタンプ付）、未承認／延滞の一覧を1ページにまとめる

監査パケットはワンクリックでPDF保存できるように設計します。フルトレイルのページがあるならそこへのリンクも付けます（例：「完全なイベント履歴を表示」）。

収集の最小化

レポーティングは「いざというときのために」余計な個人情報を集める理由にしてはいけません。承認を証明し、フォローアップを管理するために必要な情報だけを扱います：

• 敏感な属性は避け、部署／勤務地などで代替
• エクスポートに含める個人情報は最小限（氏名、業務用メール／ID）
• フリーテキストは制御され、エクスポートに出すなら理由を限定

余計なデータを集めないことでセキュリティ管理が楽になり、通常はコンプライアンス要件を満たすのに十分です。

セキュリティ、プライバシー、データ保持

承認アプリは監査や人事紛争の証拠源になるため、レコードシステムとして取り扱い、セキュリティと保持の判断を明確に文書化して説明できるようにします。

セキュリティの基本（必須事項）

全トラフィックでHTTPSを使い、HSTSを有効にしてHTTPへのダウングレードを防ぎます。

セッションはハードニング：secureかつhttpOnlyなクッキー、管理者の短いアイドルタイムアウト、CSRF対策、安全なパスワードリセットフロー（SSO主体でも）を実装。オフボーディング時は全デバイスでのログアウトを行います。

最小権限の適用を徹底します。ほとんどの従業員はポリシー閲覧と承認のみで十分です。公開、バージョン変更、エクスポートは限定された役割にします。

プライバシー：正当化できるものだけ収集

精密なデバイスフィンガープリント、継続的な位置情報、過剰なIP履歴などをむやみに集めないでください。多くの組織ではユーザーID、タイムスタンプ、ポリシーバージョン、最小限のメタデータで十分です。

IPアドレスやユーザーエージェントを記録する場合は透明性を持たせ、何をいつまで保存するかを明記します。内部の説明文書とアプリの挙動を一致させてください。

データ保持（証明可能にする方法）

レコードタイプごとに保持方針を定めます：ポリシードキュメント、承認イベント、管理アクション、エクスポート。法務／HRの要件に合わせて承認記録を保持し、期限後は削除または匿名化を一貫して実行します。

管理者向けに保持設定を表示するページ（理想的には /security のような内部ページ）を用意すると、「いつまで保持するか？」への回答が簡単になります。

バックアップと災害復旧

データベースとアップロードされたポリシーファイルの両方をバックアップし、定期的に復元テストを行います。復旧後の整合性を示すために（いつ、どこへ、成功したか）を記録し、レコードの不変識別子（ユニークIDと作成時刻）を保持し、誰が上書きや完全削除を行えるかを制限します。

構築計画：MVPの範囲、技術選定、テスト

コンプライアンス価値を証明するMVPから始める

最初のリリースは次の問いに答えられること："誰がどのポリシーバージョンをいつ承認したかを証明できるか？" その他はオプションにします。

MVPの範囲（小規模チームで4〜6週間程度）：

• 管理者がポリシーを作成、バージョンを公開、対象を選択（全社員 or 特定グループ）できる
• 従業員が割り当てられたポリシーを表示し「承認する」をクリックできる（タイムスタンプ付き）
• システムがバージョン化された承認記録を保存し、監査用の簡易CSVエクスポートを生成できる
• 基本的なリマインダー（例：3日と7日のメール）と完了ダッシュボード

より早く進めたい場合は、vibe-coding のようなワークフローを使う選択肢もあります。例えば Koder.ai はチャット駆動の仕様からコアアプリ（React UI、Goバックエンド、PostgreSQL）を生成し、その後プランニング・スナップショット・ロールバック・ソースコードエクスポートで自分たちのコードベースに移行できます。

シンプルで現実的なスタック

採用しやすくデプロイが簡単なスタックを選びます：

• サーバー：Node.js（NestJS / Express）または Python（Django）
• データベース：PostgreSQL
• UI：React（Next.js）または移動部品を減らしたいならサーバーサイドレンダリングのDjango UI
• バックグラウンドジョブ：BullMQ（Node）または Celery（Python）でリマインダーやエスカレーションを処理
• 認証：可能なら OIDC/SAML を用いた SSO

段階的に構築して停滞を避ける

フェーズ1（MVP）：承認、バージョニング、エクスポート、基本リマインダー

フェーズ2：HRIS（Workday/BambooHR 等）同期で自動プロビジョニングとグループマッピング、マネージャービュー、エスカレーション

フェーズ3：高度なレポーティング、API連携、ポリシー作成の改善

連携のアイデア：HRISから夜間にユーザー属性を同期、期日超過時にJira/ServiceNowチケットを作成、/pricing にプランの上限を表示、/blog/policy-versioning-best-practices のような解説記事を追加。

テストチェックリスト（省かないでください）

• 役割と権限：管理者、マネージャー、従業員のアクセス制御を厳格に
• バージョン再承認：新バージョン公開後にユーザーが再承認を要求されること、古い承認は不変であることを確認
• リマインダー：送信対象、タイミング、停止条件が正しいこと、承認後に送られないこと
• エクスポートの正確性：CSVが正しいバージョン、タイムスタンプ、ユーザー識別子を反映し、ダッシュボードの集計と一致すること
• エッジケース：HRIS同期で退職者が除外される、ユーザーの部署変更、割当が途中で変わった場合の挙動