人事 問い合わせ AI の3層設計｜社内FAQボットが流用できない理由

人事 問い合わせ AI の3層設計｜社内FAQボットが流用できない理由

社内の問い合わせ対応を生成AIで減らす取り組みは、タイの日系工場でも珍しくなくなりました。ところが人事 問い合わせ AI だけは、他部門で動いたボットをそのまま持ち込んでも期待どおりに動きません。理由は単純で、人事に来る質問の大半が「聞いた人ごとに答えが違う」からです。就業規則は誰が読んでも同じですが、有給残日数と給与明細は本人のものしかありません。この構造の違いを設計に落とさないまま流用すると、使われないか、他人のデータが見えるかのどちらかになります。

本記事では、この違いを層として切り分けたうえで、タイの日系製造拠点を想定した独自試算で「どの層に投資すると回収し、どの層は回収しないか」までを数字で示します。社内問い合わせ全般の自動化については社内問い合わせ自動化2026で扱っていますが、人事だけは別の設計が必要になる、というのが本記事の主張です。

社内問い合わせには2種類ある｜共有知識型と個人紐付き型

社内に飛んでくる問い合わせを、答えの性質で2つに割ると、設計の議論が一気に整理されます。

共有知識型は、誰が聞いても同じ答えが返る問い合わせです。就業規則の解釈、休暇制度の日数、経費精算の締め日、社内システムの操作方法。答えは文書のどこかに書いてあり、質問者が誰であるかは答えに影響しません。総務や情報システム部門に来る問い合わせは、ほぼこちらに寄っています。

個人紐付き型は、答えが質問者本人のデータで決まる問い合わせです。自分の有給が今何日残っているか、先月の給与明細のこの控除項目は何か、先週の打刻が抜けているのはなぜか、社会保険料が今月から変わったのはなぜか。同じ質問文でも、聞いた人が違えば答えが違います。そして、その答えは本人以外が見てはいけない情報です。

世に出ている社内チャットボットの導入事例は、圧倒的に共有知識型に偏っています。文書を検索して根拠付きで答える、という形が作りやすいからです。ところが人事に来る問い合わせの実感値は逆で、件数の過半は個人紐付き型が占めます。共有知識型だけを自動化した人事FAQボットを入れても、人事担当者の手元に残る仕事はほとんど減らないというのが、この非対称の帰結です。

就業規則 チャットボットは「入口」であって「本体」ではない

就業規則 チャットボットという言い方で語られる仕組みは、この分類では共有知識型に当たります。作りやすく、失敗しにくく、社内の理解も得やすい。最初の一歩としては妥当です。

ただしタイの日系工場では、就業規則を読ませても答えが出ない質問が多く残ります。タイの労働者保護法は、1年以上継続勤務した従業員に年6日以上の年次有給休暇を付与する義務を定めていますが、勤続年数に応じて法定の付与日数が自動的に増える仕組みは持っていません。増やすかどうかは各社の就業規則次第です。病気休暇は年間30日まで有給、個人用務休暇は年間3日まで有給という枠も別に定められています。

つまり、従業員が本当に知りたい「自分は今、何日使えるのか」は、法令でも就業規則でもなく、本人の取得実績と会社の付与ルールを突き合わせて初めて出てくる数字です。規程を読ませるだけのチャットボットは、この最後の一歩に届きません。

総務 問い合わせ 削減の設計を人事にそのまま持ち込めない理由

共有知識型の問い合わせを減らす標準的な作り方は、社内文書を検索可能な形にしておき、質問が来たら関連文書を引いてモデルに渡し、その文書に基づいて答えさせる方式です。RAGと呼ばれる構成で、総務 問い合わせ 削減の文脈ではこれで十分に成果が出ます。

この構成が人事に流用しにくいのは、次の3点が同時に効いてくるからです。

第一に、検索の単位が違います。 共有知識型のRAGは、全社共通の文書群を横断検索します。誰が質問しても同じインデックスを引き、同じ文書が返ります。ところが個人紐付き型では、引くべきなのは「質問者本人の1行」です。文書の横断検索ではなく、人事給与システムの特定レコードへの参照になります。ここは検索の問題ではなく、権限とAPIの問題です。

第二に、権限の粒度が違います。 共有知識型のRAGでも権限制御はしますが、その単位はたいてい部門や役職です。役員向け資料は一般社員には出さない、といった制御で足ります。個人紐付き型では、権限の単位が「人」まで下がります。同じ課の同じ役職の2人でも、互いの有給残日数は見えてはいけません。この行レベル(本人単位)のアクセス制御は、部門単位の権限設計をどれだけ細かくしても到達しません。設計の考え方そのものを切り替える必要があります。

第三に、認証の強度が違います。 社内ポータルに載っている規程を読むだけなら、ログインの強度はそこまで問われません。しかし給与明細の内容を返す口を開けるなら、質問している相手が本当に本人であることを確認できていなければ話になりません。チャットのアカウントと人事システムの従業員コードが確実に紐づいていること、その紐づけが人事異動や退職で確実に更新されることが前提になります。

ここを詰めずに既存のRAGを人事データに向けて拡張すると、典型的には次のような形で事故が起きます。人事給与システムから抽出したデータを、規程文書と同じインデックスに一緒に投入してしまう。すると検索は質問者を区別しないため、質問の仕方によっては別の従業員の給与情報や有給残日数が回答に混ざります。「本人だけが自分のデータを見られる」という当たり前の性質は、既存の社内問い合わせボットには最初から入っていないという前提で設計を始めてください。

回答してよい範囲を先に線引きするという考え方自体は、社外向けの窓口でも同じです。回答権限の階層設計については顧客対応チャットボット2026で詳しく扱っています。人事の場合、その線引きが「話題の範囲」ではなく「データの持ち主」で引かれる点が違いです。

タイPDPAで見た人事データ｜通常の個人データと機微情報の線引き

タイに拠点を持つ企業の場合、この設計はそのまま個人データ保護法(PDPA)の話になります。ここは「人事データはすべて危ない」という粗い理解で止めると、必要な投資と不要な投資の区別がつかなくなります。線を2本引いておきます。

1本目は、通常の個人データと機微(センシティブ)な個人データの線です。タイPDPA第26条は、機微な個人情報として民族や血筋、政治的信条、宗教や哲学上の信念、性行動、犯罪歴、健康情報、身体障害、労働組合情報、遺伝情報、生体データなどを定義しています。これらは原則として収集が禁止され、データ主体の明示的同意(Explicit Consent)がある場合などの例外でのみ収集が認められます。

2本目は、同意なしで扱える根拠があるかどうかの線です。GVA Professional Groupのタイ労働法制の解説では、給与情報は雇用契約の履行に必要な場合、本人の同意なく会計事務所などの外部へ開示できるとされています。一方で健康診断結果などの機微情報は、原則として従業員本人の明確な同意がない限り収集できません。同解説は、使用者と従業員のパワーバランスの下では同意取得の有効性そのものが問題になりうる点にも触れています。

この2本を人事の問い合わせに当てはめると、次のように整理できます。

ここで実務上いちばん効くのは、4行目と5行目です。有給残日数や給与明細は「本人以外に見せない」設計をきちんと作れば扱えます。ところが病気休暇の理由や診断書に紐づく情報は、設計を作り込んでも明示的同意という別の要件が先に立ちます。したがって、初期の設計では機微情報に触れる問い合わせを意図的に対象外に置き、人へエスカレーションする経路だけを用意するのが現実的です。

タイのPDPAが実際に執行されている点も押さえておく価値があります。One Asia Lawyersが公開している解説では、政府機関の案件で各組織に153,120バーツ、私立病院の案件で病院に1,210,000バーツと従業員に16,940バーツ、テクノロジー小売業者に合計7,000,000バーツ、化粧品会社に2,500,000バーツ、玩具小売業者の案件で小売業者に500,000バーツとベンダーに3,000,000バーツといった制裁金の事例が紹介されています。金額そのものより、実際に処分が出ている制度だという事実のほうが、社内の合意形成では効きます。

生成AIの利用を社内規程としてどう定めるかは生成AI利用規程2026で扱っています。人事データを扱う場合、その規程に「本人以外に返さないための技術的措置」と「機微情報を対象外にする範囲」を書き足す必要がある、と考えてください。

バックオフィス 問い合わせ 自動化の3層モデル｜層A・層B・層C

ここまでの整理を、投資判断できる単位に分けます。バックオフィス 問い合わせ 自動化を人事に適用する場合、次の3層に切ると費用と効果が層ごとに分解できます。

層Aは、既存の社内ヘルプデスクボットの延長で実現できます。個人データを扱わないため、PDPA上の論点も限定的です。タイの拠点では日本語・タイ語・英語の3言語で同じ回答を返す必要がありますが、多言語の設計そのものはチャットボット導入の費用と進め方で扱っている考え方をそのまま使えます。

層Bが本記事の中心です。有給残日数 確認 AI や給与明細 確認 AI として語られる機能は、すべてこの層に属します。ここに踏み込んだ瞬間、必要なものが「文書の整備」から「システム連携と権限設計」に変わります。技術構成をどう選ぶかはセキュア生成AI環境2026で整理した3構成の考え方が参考になりますが、人事データを扱う場合は、テナント統制だけでは足りず、本人単位の権限が最後まで残る点に注意してください。

層Cは、休暇申請の一次受付や勤怠訂正申請の起票など、データを書き込む操作です。読むだけの層Bと違い、誤操作が実データを壊します。承認ワークフローとの接続と、取消・差し戻しの経路が必須になります。

この3層は、そのまま費用の層でもあります。次の対応関係を押さえたうえで試算に入ります。

独自試算｜タイの日系工場で人事の問い合わせをいくら減らせるか

ここから数字を置きます。以下はTOMAS TECHが想定モデルとして組んだ試算であり、特定企業の実績値ではありません。前提を変えれば結論も変わるため、自社の数字に置き換えて読んでください。

現状の問い合わせ量と、それに投入されている時間を置きます。

計算式は「月間件数 × 1件あたり所要時間 ÷ 60 = 月間時間」、「月間時間 × 12 = 年間時間」です。年間2,268.0時間を人時単価150バーツで金額に直すと、340,200バーツになります。

この189.0時間という月間投入時間は、人事・総務6名の月間所定労働時間の合計1,056時間に対して17.9%に当たります。ゴウリカ株式会社が2026年1月下旬に実施した大企業の人事職の業務実態調査では、人事職の業務時間構成はコア業務47.5%、専門的定型業務29.0%、定型業務23.5%とされ、ノンコア業務全体で52.5%を占めています。本試算の17.9%は、この定型業務23.5%の内数として無理のない水準です。むしろ控えめな設定だと考えてください。

層ごとの削減時間

自動応答率は、定着後の水準として層ごとに置きます。層Aは規程文書に答えが書いてあるため高めに、層Bは本人確認や例外が入るためやや低めに、層Cは承認判断が人に残るため半分に設定しています。

層Bの計算を例に示すと、780件 × 70% = 546件、546件 × 10分 ÷ 60 = 91.0時間/月、91.0時間 × 12 = 1,092.0時間/年、1,092.0時間 × 150バーツ = 163,800バーツ/年です。

この表の時点で、すでに1つの結論が出ています。削減時間の72.5%は層Bから出ています。 層Aは17.6%、層Cは10.0%にとどまります。共有知識型だけを自動化する設計が人事で成果を出しにくいのは、この配分が理由です。

層ごとの費用

費用は層ごとの増分として置きます。層Bは層Aの上に、層Cは層Bの上に積む前提です。

年間運用費には、モデル利用料とホスティングのほか、制度改定時の文書更新、権限テーブルの棚卸し、監査ログの保管が含まれます。人事は制度改定が毎年発生する領域なので、運用費を薄く見積もると初年度で破綻します。

純便益と回収年数

積み上げ範囲ごとに、年間純便益(年間削減額 − 年間運用費)と単純回収年数(初期投資 ÷ 年間純便益)を出します。

層ごとの増分で見ると、性格の違いがさらにはっきりします。

この2つの表から読み取るべき点は3つあります。

層A単独では、運用費が削減額をほぼ食い切ります。 年間削減額39,780バーツに対して年間運用費が30,000バーツなので、残る純便益は9,780バーツです。初期投資180,000バーツの回収には18.4年かかります。就業規則 チャットボットを単独案件として稟議に載せると、金額だけで見れば通らない、というのが試算上の結論です。層Aは層Bへ進むための土台として位置づけるべきで、単体で費用対効果を主張する層ではありません。

層Bは、単独の増分で見れば最も効率がよい層です。 増分初期投資420,000バーツに対して増分純便益103,800バーツ、回収は4.0年です。3層のうち唯一、投資規模に見合う効果を持ちます。

層Cを足すと、全体の回収年数がむしろ悪化します。 層A+層Bの5.3年に対し、層Cまで積むと8.1年に伸びます。層Cの増分純便益は-7,500バーツで、削減額22,500バーツを年間運用費30,000バーツが上回るためです。

層Cの非対称性はなぜ生まれるか

層Cだけが逆転する理由は、3つ重なっています。

第一に、申請という行為はもともと速いことです。休暇申請はすでにフォーム入力で完結しており、人事側の1件あたり所要時間は5分と、個人紐付き型の照会10分の半分しかありません。削減できる原資がそもそも小さいわけです。

第二に、自動化率が上がらないことです。申請の一次受付をAIが担っても、承認判断は人に残ります。ここを自動化すると別の統制上の問題が出るため、率を上げること自体が目的になりません。

第三に、初期投資が重いことです。承認ワークフローとの接続、起票API、そして誤操作時の取消と差し戻しの設計は、読み取り専用の層Bより実装と検証の手間がかかります。書き込みは失敗が実データを壊すため、テストの網も細かくする必要があります。

つまり層Cは、削減原資が小さいのに実装コストは大きいという組み合わせになります。層Cには申請漏れの防止や24時間受付といった金銭化しにくい価値もありますが、回収年数だけで正当化することはできません。層Bを先に完成させ、運用が安定してから改めて判断する順序が妥当です。

感度分析｜定着率で回収年数は2倍以上動く

上の試算で最も不確実なのは、層Bの自動応答率です。ここだけを50%・70%・85%で振ります。層Aの65%は固定します。規程FAQは回答の完成度が読みやすく、定着率の振れが小さいためです。層Cは増分純便益がマイナスなので、この分析からは外します。

自動応答率が50%か85%かで、層Bの増分回収年数は7.4年と3.0年に分かれます。投資額でも技術構成でもなく、使われるかどうかで2倍以上動くということです。ここが人事 問い合わせ AI の投資判断で最も軽視されやすい変数です。定着率を上げる施策、たとえば給与支給日の前後に告知を集中させる、工場の現場端末からも使える導線を用意する、タイ語の回答品質を先に固めるといった打ち手は、追加のシステム投資よりも回収年数への効き目が大きくなります。

複数拠点で見ると結論が変わる

1拠点だけで見ると、基準ケースの層A+層Bでも回収は5.3年です。投資回収3年以内を基準にしている企業では、この時点で不成立になります。

ところが、同規模の拠点を3か所持つグループで見ると結論が変わります。2拠点目以降は、文書の構造、権限モデル、PDPAの同意フロー、API連携の仕様といった設計資産を再利用できるため、初期投資は1拠点目の40%で済むと置きます。一方、運用費は拠点ごとの就業規則の違いがあるため、2拠点目以降も70%はかかると置きます。

3拠点の初期投資は600,000 + 600,000 × 40% × 2 = 1,080,000バーツ、年間運用費は90,000 + 90,000 × 70% × 2 = 216,000バーツ、年間削減額は203,580 × 3 = 610,740バーツです。回収年数は1,080,000 ÷ 394,740 = 2.7年となり、3年基準を満たします。

同じ層B投資が、単一拠点では不成立で、3拠点では成立します。 人事の問い合わせ対応は拠点ごとに同じ構造を繰り返しているため、設計を1度作れば横展開の限界費用が下がるからです。タイに複数拠点を持つグループ、あるいはASEAN他国にも拠点があるグループでは、最初から横展開を前提に設計しておく価値があります。逆に単一拠点の企業では、層Bを人件費削減だけで正当化するのは難しく、他人のデータを返さない仕組みを持つことのリスク低減効果を併せて評価する必要があります。

「まず小さく」が回収を悪化させる場合

もう1つ、直感に反する結果を確認しておきます。単一拠点で層Bが重いなら対象を絞ればよい、という発想は自然です。そこで、層Bの対象を有給残日数の照会だけに限定し、給与システムには接続せず勤怠システム1系統だけと連携する案を試算します。個人紐付き型780件のうち有給残日数の照会が330件を占めると置き、初期投資240,000バーツ、年間運用費42,000バーツ、自動応答率70%とします。

330件 × 70% = 231件、231件 × 10分 ÷ 60 = 38.5時間/月、38.5時間 × 12 = 462.0時間/年、462.0時間 × 150バーツ = 69,300バーツ/年。年間純便益は69,300 − 42,000 = 27,300バーツで、回収年数は240,000 ÷ 27,300 = 8.8年です。

層Bをフルで作った場合の増分回収4.0年より、絞ったほうが悪化します。理由は、本人認証と行レベル権限とPDPAの同意管理という費用が、対象を絞っても比例して下がらないからです。層Bの初期投資の大部分は、扱う項目の数ではなく「本人のデータを本人だけに返す」という仕組みそのものに使われます。一度その仕組みを作るなら、有給残日数だけでなく給与明細も勤怠実績も社会保険料も、同じ土台に載せたほうが単位あたりの回収は良くなります。

スモールスタート自体を否定するものではありません。ただし、絞るべきは扱うデータ項目の範囲ではなく、対象部署や対象人数です。認証と権限の土台は最初から本設計で作り、利用者を一部の部署から広げていく順序であれば、回収を悪化させずに立ち上げられます。

導入の進め方｜層Bを本命に据えた順序

試算を踏まえると、進め方は次の順序になります。

• 現状の問い合わせを1か月分だけ記録し、共有知識型と個人紐付き型に仕分けて件数と所要時間を実測する
• 個人紐付き型の内訳を項目別に出し、人事給与システムと勤怠システムのどのテーブルを参照すれば答えられるかを確認する
• 機微情報に触れる問い合わせを洗い出し、初期の対象範囲から除外して人へのエスカレーション経路を設計する
• チャットのアカウントと従業員コードの紐づけ方法、および入社・異動・退職時の更新経路を決める
• 層Aを土台として構築し、同時に層Bの権限設計と同意管理の要件定義を進める
• 層Bを一部の部署で稼働させ、自動応答率と誤回答の発生率を実測する
• 実測値をもとに全社展開と、他拠点への横展開を判断する
• 層Cは、層Bの運用が1年以上安定してから改めて費用対効果を評価する

この順序で重要なのは、層Aの構築時点で層Bの権限設計を始めておくことです。層Aを完成させてから層Bの要件定義に入ると、認証の紐づけ方や監査ログの取り方を作り直すことになり、層Aの実装をやり直す羽目になります。試算では層Bの増分初期投資を420,000バーツとしましたが、これは層Aの設計時点で層Bを見込んでいた場合の数字です。

よくある質問(FAQ)

人事 問い合わせ AI とは何ですか

人事部門に寄せられる従業員からの問い合わせに、生成AIが一次回答を返す仕組みを指します。ただし総務や情報システム向けの社内FAQボットとは設計が異なります。人事の問い合わせは、就業規則のように誰が聞いても同じ答えになる共有知識型と、有給残日数や給与明細のように本人のデータで答えが決まる個人紐付き型に分かれ、件数の過半は後者が占めます。個人紐付き型に対応するには、人事給与システムとのAPI連携、本人認証、行レベルのアクセス制御が必要になり、文書検索の延長では実現できません。

人事FAQ AI の導入費用はどれくらいかかりますか

扱う範囲で大きく変わります。本記事の想定モデル(タイ国内の日系製造拠点1か所、従業員800名)では、規程FAQだけを扱う層Aが初期投資180,000バーツ・年間運用費30,000バーツ、本人データの照会まで踏み込む層Bが増分で初期投資420,000バーツ・年間運用費60,000バーツ、申請の起票まで含む層Cが増分で初期投資260,000バーツ・年間運用費30,000バーツという置き方をしています。これは想定モデルの試算であり、既存システムの連携しやすさや対象言語の数で変動します。稟議に載せる数字は、自社の問い合わせ件数を1か月実測してから作ってください。

有給残日数 確認 AI や給与明細 確認 AI で他人のデータが見えてしまうことはありませんか

設計を誤ると起こりえます。特に危険なのは、人事給与システムから抽出したデータを、規程文書と同じ検索インデックスに一緒に投入してしまう作り方です。この構成では検索が質問者を区別しないため、質問の仕方によって別の従業員の情報が回答に混ざる可能性があります。防ぐには、チャットのアカウントと従業員コードを確実に紐づけたうえで、参照先を本人の行に限定する行レベルのアクセス制御を実装する必要があります。加えて、誰がいつどの本人データを参照したかの監査ログを残しておくと、事故が起きた場合の範囲特定ができます。

タイでPDPAに抵触しないために、最初に決めるべきことは何ですか

対象外にする範囲を先に決めることです。タイPDPA第26条は、健康情報や労働組合情報などを機微な個人情報と定義し、原則として収集を禁じたうえで、データ主体の明示的同意がある場合などの例外でのみ収集を認めています。病気休暇の理由や診断書に紐づく情報はここに該当しうるため、初期の設計では対象外に置き、人へエスカレーションする経路だけを用意するのが現実的です。一方、給与情報は雇用契約の履行に必要な範囲であれば本人の同意なく扱えるとされています。扱えるかどうかと、本人以外に漏らさない仕組みがあるかどうかは別の問題なので、両方を分けて確認してください。

生成AIの社内活用は、そもそもどの程度進んでいますか

帝国データバンクが2026年3月に実施した生成AIに関する企業の動向調査(有効回答1万312社)では、生成AIを活用していると答えた企業は34.5%、活用していないと答えた企業は36.9%でした。課題として最も多く挙がったのは情報の正確性50.4%で、情報漏洩のリスクも33.5%が挙げています。人事部門に限ると、パーソル総合研究所の人事部トレンド定量調査2026では、人事部でAIを日常的に活用している企業は39.2%とされ、AI活用の課題として機密情報漏洩リスクを挙げた割合は34.8%でした。人事は他部門より活用が進んでいる一方、漏洩リスクへの懸念も同程度に高い領域だと読めます。

まとめ｜人事の問い合わせは「誰が聞いたか」で答えが変わる

本記事の内容を整理します。

社内の問い合わせは、誰が聞いても同じ答えが返る共有知識型と、本人のデータで答えが決まる個人紐付き型に分かれます。総務や情報システム向けの社内FAQボットは前者だけを扱っており、人事に流用してもほとんどの問い合わせに答えられません。人事に必要なのは、文書の横断検索ではなく、人事給与システムの本人の行を参照する仕組みです。

この違いは、検索の単位、権限の粒度、認証の強度という3点に現れます。特に権限は、部門単位ではなく行レベル(本人単位)まで下げる必要があります。既存のRAGを人事データにそのまま拡張すると、別の従業員の有給残日数や給与情報が回答に混ざる事故が起きえます。

タイPDPAの観点では、線を2本引きます。給与情報や有給残日数は通常の個人データで、雇用契約の履行を根拠に扱えます。一方、病気休暇の理由や診断書に紐づく情報は第26条の機微情報に該当しうるため、明示的同意なしに生成AIへ流し込むこと自体がリスクになります。初期設計では機微情報を対象外に置いてください。

想定モデルの試算では、削減時間の72.5%が層B(本人データの照会)から出ました。層A単独は回収に18.4年かかり、層Cは増分の純便益がマイナスで、足すと全体の回収年数が5.3年から8.1年に悪化します。層Bが本命で、層Aはその土台、層Cは後回しという順序が数字から出てきます。

そして、同じ層B投資が単一拠点では5.3年で不成立、3拠点では2.7年で成立します。層Bの費用の大部分は「本人のデータを本人だけに返す」土台に使われるため、対象データを絞っても回収は改善せず(絞った場合は8.8年に悪化)、むしろ拠点や利用者を広げるほど効率が上がります。感度分析では、層Bの自動応答率が50%か85%かで増分回収年数が7.4年と3.0年に分かれました。投資額よりも定着率のほうが、結果を大きく動かします。

自社の問い合わせがどの層に何件寄っているのか、既存の人事給与システムから本人単位でデータを引ける口があるのか、機微情報をどこで線引きするのか。この3点は、見積りを取る前に整理しておいたほうが後の手戻りが小さくなります。まだ検討の初期段階で「そもそも自社は層Bまで踏み込むべきか」を判断したい、という段階でのご相談も承っています。タイの拠点特有の事情や複数拠点での横展開の設計も含めて、お問い合わせフォームからお気軽にご連絡ください。

参考情報

1. 生成AIに関する企業の動向調査

生成AIを活用している企業が34.5%、活用していない企業が36.9%であること、課題として情報の正確性が50.4%、情報漏洩のリスクが33.5%挙げられていることの出典です。調査期間は2026年3月17日から3月31日、有効回答は1万312社です。

生成AIに関する企業の動向調査 | 帝国データバンク

2. 人事部トレンド定量調査2026

人事部でAIを日常的に活用している企業が39.2%であること、AI活用の課題として機密情報漏洩リスクを挙げた割合が34.8%であることの出典です。調査期間は2026年3月4日から3月16日、回答数は2,000名で、企業規模300名以上・係長以上が対象です。

人事部トレンド定量調査2026 | パーソル総合研究所

3. 日本の大企業の人事職の業務実態調査

人事職の業務時間構成がコア業務47.5%、専門的定型業務29.0%、定型業務23.5%で、ノンコア業務全体が52.5%を占めることの出典です。2026年1月下旬に実施され、従業員1,000人以上の大企業のビジネスパーソン1,020人から回答を得ています。

日本の大企業の人事職の業務実態調査 | ゴウリカ株式会社

4. タイの休暇制度

タイの労働者保護法が1年以上継続勤務した従業員に年6日以上の年次有給休暇の付与を義務づけていること、勤続年数による法定の逓増義務がないこと、病気休暇が年間30日まで有給、個人用務休暇が年間3日まで有給であることの出典です。

タイの労務における休日・休暇 | Avance Legal Group

5. タイPDPAにおける機微な個人情報

タイPDPA第26条が民族・血筋、政治的信条、宗教・哲学上の信念、性行動、犯罪歴、健康情報、身体障害、労働組合情報、遺伝情報、生体データ等を機微な個人情報として定義し、原則収集禁止としたうえでデータ主体の明示的同意がある場合などの例外でのみ収集を認めていることの出典です。

タイ個人情報保護法の概要 | Business and Law

6. タイPDPAの実務解説

上記の機微な個人情報の区分と、明示的同意の位置づけについて補足的に参照した解説記事です。

タイのPDPA解説 | Bigbeat Thailand

7. タイPDPAの執行事例

政府機関の案件で各組織に153,120バーツ、私立病院の案件で病院に1,210,000バーツと従業員に16,940バーツ、テクノロジー小売業者に合計7,000,000バーツ、化粧品会社に2,500,000バーツ、玩具小売業者の案件で小売業者に500,000バーツとベンダーに3,000,000バーツの制裁金が科された事例の出典です。

タイPDPAの執行事例 | One Asia Lawyers

8. 従業員の個人情報の取扱い

給与情報が雇用契約の履行に必要な場合に本人の同意なく会計事務所等の外部へ開示できること、健康診断結果などの機微情報は原則として従業員本人の明確な同意がない限り収集できないこと、および使用者と従業員のパワーバランス下では同意取得の有効性が問題になりうることの出典です。

タイの労働法制と実務 vol.14 従業員の個人情報の取扱い | GVA Professional Group