従業員データを公開せずに、HR チームが AI で構築したアプリを導入する方法

セキュリティ企業の RedAccess が、AI コーディングツールで構築され、そのツール自身のホスティングで公開されたアプリを調査したところ、セキュリティ対策も認証もほぼないアプリが 5,000 件以上見つかりました。Wired に提供したスクリーンショットには、医師の個人情報を含む、病院の業務割り当てと思われる画面もありました。

AI コーディングツールが簡単にしたのは、アプリを作る部分です。HR チーム向けの AI 構築アプリでデータが露出するのは、その後です。休暇管理ツールや面接評価表がデモと同じ状態で公開され、公開リンクと管理者用ログインが 1 つだけあり、その奥に従業員テーブル全体が置かれているときに起こります。

要約

• 採用や昇進の対象者、または人の評価を決める手助けをするツールは、EU AI Act 上の高リスクに該当する可能性があります。誰かを採点する前に、IT と法務、または DPO に確認を依頼します。
• 従業員記録を AI コーディングツール自身のホスティングに置いてはいけません。基本は、チームが管理し、プライベートネットワークからだけアクセスできるサーバーです。管理職や全従業員のアクセスが必要になったら、入口に会社のアカウントでのサインインを設けます。
• 修正はアプリを作った AI ツールに依頼します。読み取るフィールドを絞り、HR 管理者、管理職、従業員で表示範囲を分け、認証情報をコードから外し、外部へ送るデータを減らし、誰がどの記録を開いたかを記録し、保存要件を考慮して削除要求に対応します。それぞれを確認するのは、自分で実行するチェックです。AI 自身の報告では確認できません。
• ツールへのアクセスは雇用が終わる当日に終了させ、担当者を 1 人明確に定めます。また、サーバーの所在地を選ぶだけで法令に適合するわけではありません。

従業員データを公開してしまう導入上のミス

AI で構築した HR ツールは、リンクを見つけた人、チャットやコードに貼り付けた認証情報を持つ人、他人向けの記録を開く同僚、データ送信先の外部サービス、そして退職者に従業員データを見せてしまうことがあります。しかも、誰が見たかの記録がありません。従業員テーブル全体を読み取れば、これらの経路すべてで露出範囲が広がります。

最初の行は、RedAccess が大量に発見した問題です。RedAccess の調査結果を取り上げた Wired の記事では、AI コーディング企業 4 社のうち 3 社が研究者の主張に反論しました（残る 1 社は回答しませんでした）。しかし、RedAccess が見つけたバイブコーディングによるアプリが無防備な状態で公開されていたことは否定しませんでした。私はこれを、設定の問題と、確認工程を飛ばした結果だと捉えています。

採用、昇進、評価の対象者を決める手助けをするツールか確認する

AI コーディングツールで作られたというだけで、HR ツールが EU AI Act 上の高リスクになるわけではありません。決め手は、そのツールが何をするかです。EU AI Act の附属書 IIIには、人の募集や選考、昇進、解雇、業務の割り当て、または業績の監視・評価に関する判断に使う AI システムが列挙されています。

実行環境を決める前に、ツールについて 1 つ確認してください。採用、昇進、解雇、仕事の割り当て、業績評価に関する判断を行う、またはその判断に影響するでしょうか。

休暇管理ツール、入社手続きチェックリスト、組織の名簿は、記録を保存して表示するため、「いいえ」の側に位置します。候補者を順位付けする面接評価表や、人を採点する業績評価ツール（特に AI モデルで採点するもの）は、「はい」の側かもしれません。どちらか分からない場合、私はいったん「はい」として扱い、IT と法務に判断してもらいます。

この法律は EU 企業だけに適用されるものではありません。第 2 条は、AI システムの出力が EU 内で利用される場合、EU 外に拠点を置く提供者や導入者も対象にします。改正後の第 113 条に基づき、附属書 III の高リスクシステムに関する義務は 2027 年 12 月 2 日から適用されます。義務にはリスク管理体制、データガバナンス、技術文書、記録の保存、導入者に対する透明性、人による監督（第 9 条から第 14 条）が含まれ、その評価は IT と法務が担うべきものです。

答えが「はい」なら、実在の候補者や従業員を 1 人でも採点する前に止めてください。IT と、法務またはデータ保護の責任者（DPO がいる場合は DPO）に相談します。このチェックで個々のツールの適用範囲が確定するわけではなく、誰が判断すべきかが分かります。米国の一部の州でも自動化された採用判断を規制しており、その規則は後の表に示します。

確認作業の準備を進めることもできます。私は AI ツールに、自分の採点を擁護するのではなく、問題点を指摘するよう頼みます。

このアプリは採用候補者または従業員を採点、あるいは順位付けします。点数や順位に使うすべてのデータフィールドと計算手順を列挙してください。それぞれについて、年齢、人種、性別、国籍、民族的出自、障害、妊娠、宗教、性的指向といった保護対象の属性を直接または間接的に反映する可能性があるか説明してください。不確かな場合は推測せず、その旨を伝えてください。そのうえで、この採点の公平性について、私が聞いていないが聞くべき点も指摘してください。

確認：回答は結論ではなく、ツールを確認する人のための初期リストとして扱い、ツール自体と一緒に渡してください。このプロンプトの実行はバイアス監査ではなく、法律上の要件を満たすものでもありません。

HR ツールをどこで動かすべきか

従業員記録を AI ツール自身のホスティングに置かないでください。HR チームだけが使うツールの基本は、チームが管理し、プライベートネットワークからだけアクセスできるサーバーです。管理職や従業員が必要とするようになったら、入口に会社のアカウントでのサインインを設けます。採用判断のチェックを通過しなかったツールや、サーバーの担当者がいないツールは、IT に引き継ぎます。

AI コーディングツール自身のホスティングで公開すると、アプリはベンダーのドメイン上のアドレスを持ちます。公開範囲を非公開に設定しない限り、そのアドレスを見つけた誰もがアクセスできます。RedAccess は、そのドメインを通常の Google と Bing の検索で調べ、このようなアプリを数千件見つけました。プライベートネットワークは逆で、参加した端末にだけツールが応答します。会社のアカウントでのサインイン（シングルサインオン）とは、同僚が既存の会社アカウントでツールを開き、アカウントを管理するサービスである ID プロバイダーが確認する仕組みです。

チーム自身のサーバーで動くまでは、合成データで構築・テストしてください。つまり、本物に似た形式の架空の氏名、給与、休暇日付を使います。ノートパソコンから公開アドレスへつなぐ無料トンネルも、ベンダーのホスティングと同じように公開されるため、デモ段階でのみ使うものです。

既存のログイン画面ではなく、なぜプライベートネットワークなのでしょうか。プライベートネットワークなら、ツールは外部からのアクセスにまったく応答せず、外部の人は読み込み、探索、パスワードの推測ができません。AI ツールが作ったログイン画面だけでは不十分です。誰でも到達でき、その強さは背後の生成コードに依存します。Veracode の 2025 年 GenAI コードセキュリティレポートでは、100 を超えるモデルから得たコードサンプルの 45% が、OWASP Top 10 の脆弱性によりセキュリティテストに不合格でした。これは、重大な Web アプリケーションのセキュリティリスクとして広く使われるリストの項目です。だから私は、AI が書いた鍵に頼るより、アプリの入口に鍵を設けたいと考えます。

引き継ぎ時には、チームが完全に管理するレンタルサーバーである VPS 上で、Coolify や Dokku などの導入ツールを使い、コードからアプリを動かします。Coolify は、問題のある更新をダッシュボードから以前のバージョンへ戻すこともできます。Coolify と Dokku の選択は、主にサーバーで動かすアプリの数と、IT の支援担当者がダッシュボードを好むかによります。プライベートネットワークには Tailscale または WireGuard を使います。Tailscale のほうが短時間で設定できますが、調整サービスは Tailscale が運営し、WireGuard は完全にセルフホストできます。会社のサインインには Authentik や Keycloak などの ID プロバイダーを使います。ログインが Web に面する箇所には、Caddy や Nginx Proxy Manager などのリバースプロキシで HTTPS を追加します。この部分は、最後のチェックリストと一緒に IT の支援担当者へ渡してください。

自分の AI ツールに渡す修正用プロンプト

AI で構築した HR アプリを安全に導入する作業の多くは、作成に使ったツールに任せられます。ただし、依頼した場合に限ります。セキュリティ研究者 Joel Margolis が Wired に話したように、AI コーディングツールは「頼んだことをします。安全に行うよう頼まなければ、わざわざそのための対応をすることはありません」。

以下の各プロンプトは出発点として扱い、フィールド名や役割を自分のツールに合わせて変えてください。私は AI ツールをエンジニア、自分をレビュー担当と考えるため、変更完了の報告も下書きです。証拠になるのは各プロンプトの下のチェックであり、どのチェックもコードを読む必要はありません。失敗したら AI ツールに修正を戻し、教訓をAI ツールのルールファイルへ書き込み、次のセッションの出発点にします。各プロンプトは不確かな点も示すよう求めています。不足を認めるアシスタントのほうが、断言するアシスタントより役に立ちます。コードと架空の記録に対して実行し、実際の記録やパスワードをチャットに貼り付けないでください。

ツールが扱う従業員フィールドを洗い出し、残りへのアクセスを禁止する

ツールが保持していると知らないフィールドは遮断できません。そこで最初のプロンプトは監査です。

このアプリのデータベース、コード、画面、エクスポートを確認してください。従業員または採用候補者の個人データが入り得るすべてのフィールドを列挙します。氏名、従業員 ID、SSN または国民識別番号、納税者番号、生年月日、自宅住所、健康情報、障害の状況、合理的配慮の記録、移民または就労許可の書類、給与、賞与、株式報酬、業績評価、懲戒のメモです。各フィールドについて、使う画面や機能と、アプリの主な目的に必要かを説明してください。分からなければ推測せず、不確かだと示してください。

確認：主な画面とエクスポートを開き、そこに見える個人データのフィールドがすべてリストにあるか確かめます。見えるのに載っていないフィールドがあれば監査の漏れなので、再度依頼してください。

2 つ目のプロンプトでは、不要なものを取り除きます。利用するのは、特定のフィールドだけに制限できるデータベースアカウント、つまりアプリがデータベースと通信するためのアカウントです。

このアプリが次のフィールドだけを読むよう変更してください：[ツールに必要なフィールドを列挙]。それ以外の個人データフィールドは、アプリ側のデータコピー、コード、すべての画面、すべてのエクスポートから削除します。次に、これらのフィールドだけを読み取れ、休暇申請などツール自身が書き込むデータだけを変更できる、アプリ専用のデータベースアカウントを作成してください。アプリをそのアカウントへ切り替えます。変更内容をファイルごとに正確に報告し、できなかった点をすべて説明してください。

画面だけの編集では不十分です。アプリのデータベースアカウントが給与列を読めなければ、AI が書いたコードの別の場所に不具合があっても表示できません。保存時にデータが暗号化されているかは IT に確認すべきです。これはサーバーやディスクの設定に属し、コードを読むアシスタントには確実に見えないからです。

確認：一般ユーザーでサインインし、すべての画面とエクスポートを開きます。削除したフィールドは 1 つも表示されないはずです。次に、サーバーを管理する IT 担当者（または出力を自分に見せる AI ツール）に、アプリのデータベースアカウントで接続し、削除したフィールドを要求してもらいます。権限拒否やフィールドが存在しないというエラーなら合格です。接続、構文、その他の無関係なエラーは合格ではありません。空の列や実際の値が返れば不合格です。削除ツールで使うため、監査リストは保管してください。

HR 管理者、管理職、従業員で表示範囲を分ける

同僚が他人の給与や同じチームの人の合理的配慮のメモを開くと、従業員データは社内にも漏れます。役割に基づくアクセス制御が対策になります。以下のプロンプトでは、どこで確認すべきかを明確にします。

3 つの役割を持つ、役割に基づくアクセス制御を追加してください。ページ上のボタンやリンクを隠すだけでなく、すべてのリクエストをサーバー側で確認します。

- HR 管理者：すべての従業員記録を閲覧・編集できます。

- 人員を管理する管理職：自分の直属の部下の記録だけを閲覧でき、給与、医療、合理的配慮、懲戒、移民関連のフィールドは一切見られません。

- 従業員：自分自身の記録だけを閲覧できます。

それ以外はすべて「アクセス拒否」（403）の応答で拒否します。各ユーザーの役割はサインイン済みアカウントから取得し、ページやアドレスバーでユーザーが入力・変更できるものからは取得しません。チェックを追加した場所をすべて列挙し、対象に含まれるか不確かなページやエクスポートを示してください。

報酬の見直し時に管理職へ給与を見せる会社もあります。自社がそうなら、管理職の行を変更してください。

確認：テスト用の管理職と従業員を作成します。管理職としてサインインし、直属の部下の記録を開き、アドレスをコピーします。記録番号をチーム外の人の番号に変えて読み込むと、「アクセス拒否」になるはずです。従業員としても、同僚の記録番号で繰り返します。その後、管理職の画面に給与、合理的配慮、移民関連のフィールドが一切表示されないことを確認します。

認証情報をコードとチャットから外す

データベースのパスワードや HRIS、給与システムの API トークン（別のシステムへログインするための長いキー）は、現在のコードから消しても、過去に保存したプロジェクトの版に残ることがあります。そのため、プロンプトでは履歴も確認します。コード側の対策は環境変数です。サーバーが起動時にアプリへ渡す値で、コードは実際の値を含めず、名前で参照します。

このプロジェクト内のすべてのパスワード、API キー、アクセストークン、データベース接続文字列を探してください。HRIS、給与、メールシステム用も含めます。コード内の各値を環境変数に置き換え、変数名の一覧を渡してください。.env など実際の値を保持するファイルがコードリポジトリの対象外であることを確認します。次に、古い値がプロジェクト履歴に残る場所をすべて列挙し、交換が必要な認証情報が分かるようにしてください。

最も重要な手順は、このプロンプトでは実行できません。チャットやリポジトリに一度でも現れた認証情報について、HRIS またはデータベースの管理コンソールで新しいものを発行し、古いものを無効にします。

チーム用に保持するパスワードのコピーは、セルフホストの Vaultwarden サーバーなどのパスワードマネージャーで管理します（チームに適した選択肢は別途判断が必要です）。これは人のために認証情報を保存するもので、実行中のアプリへ値を渡すものではありません。アプリは導入ツールから値を受け取ります。実行中のアプリ自身が読むシークレットには、HashiCorp Vault というより大規模な選択肢があり、必要なチームに集中管理のポリシーとローテーションを提供します。

確認：AI ツールに現在のファイルから古い値を検索させ、要約ではなく、表示された検索結果を読みます。現在のファイルに一致はないはずです。履歴内の一致は想定どおりで、消す必要はありません。交換すべき認証情報の一覧になるからです。それぞれが失効した証拠は HRIS またはデータベースの管理コンソールにあります。すべての古い認証情報が失効済みと表示されるか、システムが拒否すると IT が確認します。

どの従業員データがツールの外へ出るか確認する

候補者の面接メモを外部サービスに送った後で、自分のツールの記録を消しても、そのサービスが保持するかもしれないコピーには届きません。対策は、初めから送る量を減らすことです。

このアプリが行うすべての外部呼び出しを監査してください。OpenAI、Anthropic、その他の AI API、HRIS や ATS などの HR システム、分析ツールやエラー追跡ツール、すべての webhook が対象です。各呼び出しで、送信内容に含まれる従業員または候補者のフィールドを正確に列挙します。受信内容を保存したりログに残したりする可能性があるサービスを示し、より少ないデータで動く呼び出しを説明してください。不確かな点も示します。

確認：特徴的な架空の名前を持つ従業員または候補者を作り、外部呼び出しを行う各機能を使います。面接要約の生成、webhook の発火、分析スクリプトを読み込むページの表示などです。分析ツール、エラー追跡ツール、ATS の受信 webhook ログ、リクエストを表示する AI 提供者の利用ログなど、各外部サービス自身のダッシュボードでその名前を検索します。呼び出しにその名前が必要な場所でだけ見つかるはずです。ほかで見つかったら、送るデータを減らすよう AI ツールへ修正を戻し、再確認します。受信内容を表示しないダッシュボードもあります。そのサービスと、従業員データを受け取り続ける必要のあるサービスについては、データ保存条件を社内のベンダー契約締結担当者に渡してください。

誰がどの従業員記録を開いたか記録する

従業員から、前四半期に給与表をエクスポートしたのは誰かと聞かれました。誰がどの記録に何をしたかを継続して記録する監査ログがなければ、誰も答えられません。

監査ログを追加してください。ユーザーが従業員記録を閲覧、編集、エクスポート、削除するたびに、ユーザー ID、従業員記録の ID、操作、変更されたフィールド、時刻を含む行を追加します。アプリのデータベースアカウントがログへ行を追加できても、編集・削除できないようデータベースを設定します。アプリ内でログを読めるのは HR 管理者だけです。編集・削除禁止をどう実施し、どこで実施するか説明してください。

「追記専用」は、アプリが正しく動くという約束ではなく、データベースアカウントの権限で実現する必要があります。誰が誰の記録を見たかを示すログ自体も個人データなので、閲覧できるのは HR 管理者だけです。

確認：HR 管理者として記録を開き、ログを表示して該当する項目があることを確かめます。IT または AI ツールに、アプリのデータベースアカウントでログの行を削除させ、出力を見せてもらいます。権限エラーそのものが表示されるはずです。

保存規則を破らずに削除要求へ対応する

従業員が消去を求めた記録の中に、会社が保持しなければならない給与ファイルがあると、どうなるでしょうか。単純なプロンプト（「全テーブルにあるこの従業員の個人データをすべて削除」）では、それも削除され、2 つの問題が起きます。雇用主には記録の保存義務があることが多く、給与、税務、就労許可の書類が典型例です。また、法律上の義務への対応や法的請求のために処理が必要な範囲では、GDPR の消去権は適用されません（第 17 条第 3 項 (b)、(e)）。すべてを消すボタンを置くこと自体も危険です。安全性を高めた方法では、「要求に応じて削除」と、要求があっても会社が保持すべき保存要件のある記録を分け、何かを削除する前に計画を表示します。

HR 管理者だけが開ける削除要求ツールを作ってください。従業員 ID を入力すると、まずその人のデータを持つすべてのテーブルとフィールドを、フィールド監査の分類ごとに表示します。各分類には、HR 管理者が「要求に応じて削除」または「保持：保存義務あり」の保存設定をします。HR 管理者の確認後、「要求に応じて削除」に設定された分類だけを消します。ログには従業員 ID、時刻、確認者、削除または保持した分類だけを残し、その人のほかの情報は残しません。HR 管理者以外には「アクセス拒否」を返します。

保存設定は、AI ツールや作成者の推測ではなく、コンプライアンス責任者または DPO が決めます。削除後も監査ログに従業員 ID が残ることを伝え、その識別子をいつまで残すか判断してもらいます。バックアップや外部サービスが持つコピーには、それぞれ独自の保存・削除手順が必要です。

確認：2 つの分類に記録を持つテスト従業員を作り、一方を「要求に応じて削除」、もう一方を保存義務ありに設定します。HR 管理者としてツールを実行し、最初の分類だけが消えたことを確認します。次に管理職のアカウントで開き、「アクセス拒否」になることを確かめます。

DPO またはコンプライアンス責任者に相談すべき雇用関連の規則

HR ツールに関わる雇用規則は、構築方法ではなく、何をし、誰のデータを持つかで決まります。以下は DPO またはコンプライアンス責任者に相談するための規則一覧で、法律上の助言ではなく、いずれかが自社に適用されると判断するものでもありません。

ドイツとカリフォルニアの従業員の合理的配慮のメモを持つ休暇管理ツールには、職名だけを持つ人員計画ツールとは異なる規則が関わります。EU AI Act の問題は、採用判断のチェックで扱います。

サーバーの所在地は、記録が物理的に置かれる場所を決めるだけで、上記の規則を単独で満たすものではありません。これらの地域以外の従業員については、該当する国、州、地方のプライバシー・雇用規制当局、または法務・コンプライアンス責任者への確認から始めてください。

雇用終了と同時にアクセスを終了する

退職者の会社アカウントを最終勤務日に無効にすると、メール、カレンダー、ファイルへのアクセスはまとめて閉じます。HR ツールも同じ手順で閉じるべきです。会社のサインインの配下に置き、退職処理で有効なセッションも失効させれば実現できます。会社のサインイン配下にないツールは退職チェックリストに個別項目として載せ、担当者が手動でアカウントを削除します。

ツールの作成者も、いつかは退職者になります。作成者が退職や異動をするときは、管理者としてサインインでき、サーバーの場所を知る、明確に指定された後任へ管理責任を渡し、作成者自身の管理者アカウントを閉じます。退職予告期間に探すのは避けたいので、私は稼働開始前に後任を指名します。

決めた周期で、各役割を誰が持つか、ツールがまだ使われているかを見直します。アクセスを広げるなら、HR チーム、管理職、全従業員の順に 1 段階ずつ進め、そのたびにアドレスバーのテストを繰り返します。使わなくなったら廃止します。データベースアカウントと認証情報を無効にし、削除ツールの保存設定に従ってデータを消し、稼働を停止し、プライベートネットワークやサインインシステムから外します。

指定された後任が引き継ぐのは、誰かが構築したサーバーと、導入ツール、プライベートネットワーク、アクセスを広げる場合の会社のサインインです。当社の Linux VPS は root アクセスを提供し、Coolify、Tailscale、Authentik はそれぞれワンクリックアプリとして導入できるため、IT 担当者は確認作業に時間を使えます。所在地には EU のフランクフルトとアムステルダム、英国のロンドン、米国の複数の都市があります。これでサーバーの所在国は決まりますが、それは DPO と相談するための情報であり、相談に代わるものではありません。

稼働開始前のチェックリスト

従業員記録を入れる前に、以下の各項目が完了したかどうかを確認します。サーバーを設定する担当者に、このリストを渡してください。

1. 採用判断に関する質問に回答し、「はい」の場合はすべて IT と法務へ相談した。
2. AI ツールのホスティングではなく、チームが管理するサーバーでツールが動く。
3. プライベートネットワークまたは会社のサインイン経由でのみアクセスできる。
4. アプリのデータベースアカウントが、列挙したフィールドだけを読む。
5. テスト用の管理職と従業員が、どちらもアドレスバーのテストで「アクセス拒否」を受ける。
6. チャットやコードに出したすべての認証情報を交換し、古いものを失効させた。
7. 外部送信データの監査が完了し、不要なフィールドを取り除いた。
8. 監査ログが閲覧を記録し、アプリのアカウントで編集・削除できない。
9. 保存設定と雇用規則を DPO またはコンプライアンス責任者が確認した。
10. 明確に指定した担当者と予備の担当者がいる。

よくある質問

HR におけるシャドー AI とは何ですか？

HR におけるシャドー AI とは、IT が知らない、または承認していない状態で、AI ツールやそれで作ったアプリを HR データに使うことです。Cornerstone OnDemand が報じた Sapient Insights の 2026 年度 HR システム調査では、HR 専門職の 80% 超が個人用 AI ツールを毎日使う一方、HR システムに組み込まれた AI を使う人は 3% でした。

ツールを構築するときに実際の従業員記録を使えますか？

いいえ。バイブコーディングで HR ツールを作る間、実際の記録をチャットに入れないでください。チャットアシスタントへの貼り付けはアプリ導入とは別のリスクで、ツールが稼働するかどうかに関係なく、貼り付けた瞬間に発生します。チームが管理するサーバーで動くまでは、架空の記録で構築してください。

HR ツールでデータを使うには従業員の同意が必要ですか？

通常、同意は適切な根拠ではありません。EDPB の同意に関するガイドラインは、「現在または将来の従業員の個人データを、雇用主が同意に基づいて処理することは、同意が自由に与えられる可能性が低いため、問題があると考える」としています。GDPR 第 6 条に基づくどの適法な根拠が当てはまるかは、DPO に確認してください。

HR ツールの医療メモは HIPAA の対象ですか？

通常は対象ではありません。HIPAA の保護対象保健情報の定義は、対象事業体が雇用主として保持する雇用記録内の情報を除外します（45 CFR 160.103）。だからといって、そのメモが規制を受けないわけではありません。適用される規則をコンプライアンス責任者に確認してください。