高木浩光＠自宅の日記

2つのブログ記事を取得して内容を把握します。

[考え中...]

2つのブログ記事を取得しました。内容を整理してお伝えします。

（略）

AI事業者ガイドラインの分析に進みましょうか？

まずはweb_fetchでPDFを取得してみます。うまくいかなければアップロードをお願いします。

[考え中...]

最新版は第1.1版（2025年3月28日公開）ですね。本編PDFを取得してみます。

[考え中...]

PDFの直接取得ができませんでした。「AI事業者ガイドライン（第1.1版）本編」のPDFをアップロードしていただけますか？

ファイルサイズが1,841KBとのことなので、問題なくアップロードできると思います。

AI事業者ガイドライン（第1.1版）本編を、ブログの論点に沿って分析します。

AI事業者ガイドライン（第1.1版）本編の問題点分析

1. 根本的な問題：目的軸での類型化の欠如

問題箇所：第1部「AIとは」（9–10頁）

AIの定義は技術的観点からのみ行われており、規律目的による類型化（処遇AI/生成AI/製品AI）が存在しない。

• 「生成AI」の定義はある（10頁：「⽂章、画像、プログラム等を⽣成できるAIモデルにもとづくAIの総称」）
• しかし「処遇AI」（個人を評価・選別・決定するAI）という概念がない
• 「製品AI」（物理的動作を担うAI）という概念もない

結果として、技術軸（従来AI/生成AI/高度なAI）での分類しかなく、「何を規律するのか」という目的軸での整理がない。

2. 「透明性」における混同

問題箇所：第2部C 6) 透明性 ①検証可能性の確保（18頁）

AIの判断にかかわる検証可能性を確保するため、データ量⼜はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利⽤時の⼊出⼒等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存する

ログの記録・保存にあたっては、利⽤する技術の特性及び⽤途に照らして、事故等の原因究明、再発防⽌策の検討、損害賠償責任要件の⽴証上の重要性等を踏まえて、記録⽅法、頻度、保存期間等について検討する

ここに3つの異なる目的の語彙が混在している：

これらが「共通の指針」として一括りにされているため、どのAIに対して何のためにログを取るのかが不明確。

3. 「アカウンタビリティ」における混同

問題箇所：第2部C 7) アカウンタビリティ ①トレーサビリティの向上（20頁）

データの出所、AIシステム・サービスの開発・提供・利⽤中に⾏われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態を確保する

この「意思決定」が二義的：

1. 「事業者の意思決定」（開発・提供・利用を決めた経緯）→ 知財紛争での立証に関係
2. 「AIの意思決定」（AIが個人に対して行った判断）→ 処遇AIの規律に属する

文言だけでは前者の読み方も可能だが、上記6)透明性で「AIの判断」「推論過程、判断根拠等のログ」と言っている以上、実質的には処遇AI向けの規律が意図されている。しかし生成AIを含む全てのAIに「共通の指針」として適用される構造になっている。

4. 「公平性」の規律の問題

問題箇所：第2部C 3) 公平性（16–17頁）

バイアスを⽣み出す要因は多岐に渡るため、各技術要素（学習データ、AIモデルの学習過程、AI利⽤者⼜は業務外利⽤者が⼊⼒するプロンプト、AIモデルの推論時に参照する情報、連携する外部サービス等）

問題点：

• 「プロンプト」への言及は生成AIの技術構成要素の話
• 処遇AIで本来問題となる「決定に使うデータの関連性」（決定目的に関係ないデータで人を分けていないか）という観点が欠落
• 「差別」の定義が「特定の個⼈ないし集団への⼈種、性別、国籍、年齢、政治的信念、宗教等の多様な背景を理由とした不当で有害な偏⾒及び差別」と抽象的で、処遇AI固有の問題（決定の合理性）と生成AI固有の問題（出力のバイアス）が区別されていない

5. 「人間中心」におけるプロファイリング規定の埋没

問題箇所：第2部C 1) 人間中心 ①人間の尊厳及び個人の自律（13–14頁）

個⼈の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利⽤したプロファイリングを⾏う場合、個⼈の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利⽤し、かつ⽣じうる不利益等を慎重に検討した上で、不適切な⽬的に利⽤しない

問題点：

• これは処遇AIの規律の萌芽だが、「共通の指針」の一項目に埋もれている
• 「関連性のないデータで人を分けていないか」という関連性原則が明示されていない
• 「異議申立ての途が開かれているか」「救済の仕組み」への言及がない
• GDPRのような「自動処理のみに基づく決定に服さない権利」に相当する規律がない

6. 高度なAIシステムの定義の問題

問題箇所：第1部（10頁）および第2部D（25–26頁）

⾼度なAIシステム：最先端の基盤モデル及び⽣成AIシステムを含む、最も⾼度なAIシステムを指す。

問題点：

• 「高度な」という技術的特性での分類
• EU AI Actの「高リスクAI」は用途（処遇AI的な領域）での分類だが、日本のガイドラインは技術軸
• EU AI Actでは「高リスクAI」と「GPAI（汎用目的AI）」で義務の束を分けているが、このガイドラインではその区別が輸入されていない

7. 「共通の指針」という構造自体の問題

問題箇所：第2部C全体および表1（24頁）

10の指針（人間中心、安全性、公平性、プライバシー保護、セキュリティ確保、透明性、アカウンタビリティ、教育・リテラシー、公正競争確保、イノベーション）が「共通」として並べられている。

問題点：

• 目的の異なる規律が同一の箱に同居している
• 「処遇AIに必要な規律」「生成AIに必要な規律」「製品AIに必要な規律」が区別されていない
• 結果として、ブログで引用されていた事業者の苦情（「全体像を簡単に理解するのが困難」「項目間の対応・依存関係が不明」「辞典みたいでHowがわからない」「適切な等の漠然とした表現」）が生じる

8. 具体的な欠落事項

処遇AIの規律として本来必要だが欠落しているもの：

まとめ：問題の構造

【現状のガイドライン】
　　┌─────────────────────────────────┐
　　│　　「共通の指針」（10項目）　　　　　　　　　　　　　　　　　　　│
　　│　　・人間中心　　　　　　　　　　　　　　　　　　　　　　　　　　│
　　│　　・安全性　←　製品安全の語彙が混入　　　　　　　　　　　　　　│
　　│　　・公平性　←　生成AI/処遇AI混在　　　　　　　　　　　　　　　│
　　│　　・プライバシー保護　　　　　　　　　　　　　　　　　　　　　　│
　　│　　・セキュリティ確保　　　　　　　　　　　　　　　　　　　　　　│
　　│　　・透明性　←　3つの目的が混在　　　　　　　　　　　　　　　　│
　　│　　・アカウンタビリティ　←　同上　　　　　　　　　　　　　　　　│
　　│　　・教育・リテラシー　　　　　　　　　　　　　　　　　　　　　　│
　　│　　・公正競争確保　　　　　　　　　　　　　　　　　　　　　　　　│
　　│　　・イノベーション　　　　　　　　　　　　　　　　　　　　　　　│
　　└─────────────────────────────────┘
　　　　　　　　　　　↓
　　全てのAIに「共通」として適用
　　　　　　　　　　　↓
　　「何のために何をすべきか」が不明確


【本来あるべき構造】
　　┌──────────┐　　┌──────────┐　　┌──────────┐
　　│　処遇AI　　　　　　│　　│　生成AI　　　　　　│　　│　製品AI　　　　　　│
　　│　　　　　　　　　　│　　│　　　　　　　　　　│　　│　　　　　　　　　　│
　　│・関連性原則　　　　│　　│・出力管理　　　　　│　　│・製品安全　　　　　│
　　│・説明義務　　　　　│　　│・著作権対応　　　　│　　│・事故調査　　　　　│
　　│・異議申立て　　　　│　　│・悪用防止　　　　　│　　│・原因究明　　　　　│
　　│・救済　　　　　　　│　　│・表示義務　　　　　│　　│・再発防止　　　　　│
　　└──────────┘　　└──────────┘　　└──────────┘

ブログの指摘どおり、EUから「キーワード」だけを輸入し、「区別」を輸入していない構造が、このガイドラインの根本的な問題です。

別添のPDFを確認します。ファイルサイズが大きい（6,361KB）ので、まず構造を把握してから詳細を見ていきましょう。

[考え中...]

PDFの生データが表示されてしまいました。テキスト抽出を試みます。

[考え中...]

別添の構造が見えてきました。続けてリスクの例やAIガバナンスの構築部分を確認します。

[考え中...]

別添の内容をさらに詳しく確認します。特にリスクの分類と具体的な実践例を見ていきましょう。

[考え中...]

リスクの分類構造が見えました。次に透明性・アカウンタビリティの実践例を確認します。

[考え中...]

透明性・検証可能性の具体的な実践例を確認します。

[考え中...]

リスク例と指針のマッピング部分を確認します。

[考え中...]

人材採用AIなどの事例がどのように扱われているか確認します。

[考え中...]

プロファイリングに関する記述を詳しく確認します。

[考え中...]

AIエージェントに関する記述を確認します。

[考え中...]

これで別添の内容を十分に確認できました。分析結果をまとめます。

AI事業者ガイドライン別添（付属資料）の問題点分析

1. リスク分類の軸が目的軸ではなく技術軸・発生段階軸

問題箇所：表3「AIによるリスク例の体系的な分類案」（別添1, 19頁相当）

リスクは以下のように分類されている：

ブログの指摘との対比：

• 「処遇AI」「生成AI」「製品AI」という目的軸での分類がない
• 結果として、同じ「バイアスのある出力」というリスク名で、処遇AI（採用差別）と生成AI（偏った文章生成）が同一視される

2. 処遇AI固有の問題が「共通の指針」に埋没

問題箇所：リスク例と指針のマッピング（表4）

例えば「バイアスのある出力、差別的出力」への対策として挙げられているのは：

• 3）公平性：「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」

欠落している視点：

• 「決定に使うデータは目的に照らして関連性があるものに限る」（関連性原則）
• 「異議申立て・再審査の仕組み」
• 「自動処理のみに基づく決定に服さない権利」

採用AI差別の例（868行目）で「女性を差別するという機械学習面の欠陥」と記述されているが、これは「性別という関係のない情報で人を分けた」という関連性原則違反の問題であり、単なる「バイアス」問題ではない。

3. プロファイリングの記述が分散・埋没

問題箇所：別添4「AI提供者向け」（7535-7565行目付近）

プロファイリングの問題点として以下が列挙されている：

• プロファイリング結果が事実と異なることにより誤った判断が下されること
• 個人の特定の特徴のみがプロファイリングで用いられることにより、個人が過小又は過大に評価されてしまうこと
• 特定の個人又は集団に対する不当な差別を助長すること

問題点：

• これらは処遇AIの核心的問題だが、「AI提供者向け」の「1）人間中心」の解説の一部に埋もれている
• 「プロファイリングに関する最終提言」（パーソナルデータ+α研究会）への参照はあるが、ガイドライン本体の構造に反映されていない
• EU AI Actの「高リスクAI」のような明確な規律カテゴリになっていない

4. 透明性・検証可能性の混同

問題箇所：D-6「検証可能性の確保」（5607行目付近）

「説明可能性・解釈可能性を高めるための手法」として以下が列挙：

• 単純なAIモデルの使用（ロジスティック回帰、決定木等）
• 局所的な説明手法（LIME等）
• SHAP値
• 特徴の寄与度可視化
• AIモデル内部の解析
• RAGの導入による出力根拠の透明性向上

問題点：これらは技術的な機械学習モデルの解釈手法であり、3つの異なる目的が混在：

5. AIエージェントのリスク記述の問題

問題箇所：脚注16（1528行目付近）

AIエージェントの登場により、事故等の安全性面のリスクや過度な依存、労働者の失業等のリスクが複雑化・深刻化する可能性があることにも留意する必要がある。

ブログの指摘との対比：これはまさにブログで批判されていた「AIエージェントのリスク一覧」の問題：

• 「判断根拠の不透明性」（処遇AI問題）
• 「誤情報拡散」（生成AI問題）
• 「事故等の安全性面のリスク」（製品AI問題）
• 「ツール悪用」（セキュリティ問題）
• 「過度な依存」（人間とAIの関係問題）

が同列に並べられている。

6. 具体的事例の分析における問題

問題箇所：採用AI、与信AI、クレジットカード限度額の事例>

7. 構造的問題のまとめ

【別添の現状】
┌─────────────────────────────────────┐
│　リスク分類：技術的リスク / 社会的リスク　　　　　　　　　　　　　　　　 │
│　　　　　　　　　　↓　　　　　　　　　　　　　　　　　　　　　　　　　　│
│　対策：「共通の指針」10項目へマッピング　　　　　　　　　　　　　　　　　│
│　　　　　　　　　　↓　　　　　　　　　　　　　　　　　　　　　　　　　　│
│ 実践：LIME、SHAP値、RAG、ログ記録... 　　　　　　　　　　　　　　　　　　│
│　　　（技術手法の羅列）　　　　　　　　　　　　　　　　　　　　　　　　　│
└─────────────────────────────────────┘
　　　　　　　　　　↓
  「何のAIに対して何のために何をすべきか」が不明確


【本来あるべき構造】
┌──────────┐　　┌──────────┐　　┌──────────┐
│　処遇AIリスク　　　│　　│生成AIリスク　　　　│　　│製品AIリスク　　　　│
├──────────┤　　├──────────┤　　├──────────┤
│・採用差別　　　　　│　　│・偽情報生成　　　　│　　│・自動運転事故　　　│
│・与信差別　　　　　│　　│・著作権侵害　　　　│　　│・ロボット暴走　　　│
│・保険差別　　　　　│　　│・なりすまし　　　　│　　│・医療機器誤動作　　│
├──────────┤　　├──────────┤　　├──────────┤
│【必要な規律】　　　│　　│【必要な規律】　　　│　　│【必要な規律】　　　│
│・関連性原則　　　　│　　│・出力管理　　　　　│　　│・製品安全　　　　　│
│・説明義務　　　　　│　　│・表示義務　　　　　│　　│・事故調査　　　　　│
│・異議申立て　　　　│　　│・著作権対応　　　　│　　│・原因究明　　　　　│
│・救済の仕組み　　　│　　│・悪用防止　　　　　│　　│・再発防止　　　　　│
└──────────┘　　└──────────┘　　└──────────┘

結論：別添は本編の問題を増幅している

本編で「共通の指針」として一括りにされた問題が、別添では具体的な事例や技術手法として展開されているが、目的軸での区別がないまま具体化されているため：

1. 事業者は「自社のAIがどの規律に服すべきか」を判断できない
2. 技術手法（LIME、SHAP等）が羅列されているが、どのAIにどの手法が必要かが不明確
3. 処遇AI固有の規律（関連性原則、異議申立て、救済）が「プロファイリングへの配慮」として埋もれている
4. 結果として、ブログで引用された事業者の苦情（「辞典みたいでHowがわからない」）が生じる

具体的事例の記述を詳しく確認します。

[考え中...]

採用AIサービス（リクナビ事件と思われる）の事例周辺をもう少し確認します。

[考え中...]

リスクと指針のマッピングにおける「バイアスのある出力」への対応と、公平性の具体的手法を確認します。

[考え中...]

「異議申立て」「救済」「不服」「再審査」に関する記述を検索します。

[考え中...]

本編で言及されていた「プロファイリング」について、別添でどのように解説されているか確認します。

[考え中...]

「関連」「関係のある」「目的に照らし」などの観点からの記述を確認します。

[考え中...]

EU AI Actの高リスクAIについての言及を確認します。

[考え中...]

リクナビ的事例（内定辞退予測）についてもう少し確認します。

具体的事例の分析における問題：深掘り

事例1：採用AI差別（Amazon的事例）

ガイドラインの記述（別添 868–871行目）：

IT企業が自社でAI人材採用システムを開発したが、女性を差別するという機械学習面の欠陥が判明した。この原因としては、学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識したためといわれている。

ガイドラインでの分類：

• リスク分類：「技術的リスク」→「出力段階のリスク」→「バイアスのある出力、差別的出力」
• 対策指針：「3）公平性」→「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」

ガイドラインの問題認識： 「学習データの偏り（男性が多かった）」→「AIが男性を好むと学習」→「バイアスのある出力」

本来必要な分析（ブログの視点）：

事例2：クレジットカード限度額差別（Apple Card的事例）

ガイドラインの記述（別添 905–911行目）：

とあるクレジットカードにおいて、同じ年収を有する男性及び女性に対して、女性の方が利用限度額が低いとの報告がSNS上で広がった。この問題に対し、金融当局が調査を実施し、クレジットカードを提供した企業に対してアルゴリズムの正当性の証明を求めた。しかし、企業はアルゴリズムの具体的な機能及び動作について説明することができなかった

ガイドラインでの分類：

• リスク分類：「技術的リスク」→「事後対応段階のリスク」→「ブラックボックス化、判断に関する説明の不足」
• 対策指針：「6）透明性」→「検証可能性の確保」「関連するステークホルダーへの情報提供」

ガイドラインの問題認識：

「アルゴリズムがブラックボックス」→「説明できなかった」→「透明性の問題」

本来必要な分析（ブログの視点）：

事例3：内定辞退予測サービス（リクナビ的事例）

ガイドラインの記述（別添 922–926行目）：

人材採用にAIを用いるサービスにて、選考離脱及び内定辞退の可能性をAIにより提供した際、学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかったこと等、透明性を欠く個人情報の利用が問題視され、サービスが廃止されることとなった

ガイドラインでの分類：

• リスク分類：「社会的リスク」→「倫理・法に関するリスク」→「個人情報の不適切な取扱い」
• 対策指針：「4）プライバシー保護」→「プライバシー保護のための仕組み及び対策の導入」

ガイドラインの問題認識：

「説明が不明瞭」「同意なく第三者提供」→「個人情報の不適切な取扱い」→「プライバシー問題」

本来必要な分析（ブログの視点）：

事例4：与信判断AI（7分で融資）

ガイドラインの記述（別添 4741–4770行目付近）：

顧客の行動を分析した上で、AIが数分間で与信判断を行い、顧客に最適な融資提案を行う完全自動化ソリューション

【実装手段】Fairness by Designの活用：設計段階からステークホルダーの意見を取り入れる参加型デザイン手法を用いて、ローン審査の判断基準となる収入、勤務先、取引履歴等の属性及び公平性に関わる年齢、性別、国籍等の属性の重みを数値化することで、ビジネス上の要件及び公平性をバランスさせたAIモデルの開発を可能とし…

ガイドラインでの扱い：

• 「コラム13：データ前処理・学習時におけるデータに含まれるバイアスへの配慮についての事例」として紹介
• Fairness by Design」「交差バイアス軽減アルゴリズム」等の技術的手法で対応

ガイドラインの問題認識：

「センシティブ属性（年齢、性別、国籍等）」→「交差バイアスも考慮」→「公平性をバランス」

本来必要な分析（ブログの視点）：

問題の構造：なぜガイドラインはこうなるのか

【ガイドラインの分析枠組み】


事例 → 「技術的問題」として認識
         ↓
      「バイアス」「ブラックボックス」「個人情報」等のキーワードで分類
         ↓
      「共通の指針」（公平性、透明性、プライバシー等）にマッピング
         ↓
      技術的手法（バイアス除去、説明可能AI、匿名化等）を適用


【本来必要な分析枠組み】


事例 → 「何のためのAIか」で分類
         ↓
      処遇AI（人の処遇を決定）であれば：
         ↓
      ① 決定目的は何か
      ② その目的に関連性のある情報は何か
      ③ 関連性のない情報で人を分けていないか
      ④ 決定の根拠を本人に示せるか
      ⑤ 異議申立て・再審査の途はあるか
      ⑥ 救済の仕組みはあるか

具体的な欠落事項のまとめ

ブログの視点からの根本的批判

これらの事例分析の問題は、ブログで指摘された構造的問題の具体的な現れです：

1. 「処遇AI」という概念がないため、「人の処遇を決めるAI」に固有の規律が設計されていない
2. 「関連性原則」が輸入されていないため、「バイアス除去」という技術的対処に終始し、「そもそも使ってはいけない情報」という発想がない
3. EU AI Actの「高リスクAI」の規律（採用、与信、保険等における説明義務、人間の監視、異議申立て権等）が参照されていない
4. 事例を「技術的リスク」として処理することで、「なぜそのようなAIを使うのか」「どのような決定が許されるのか」という規範的問いが回避されている

このチェックリストとワークシートを詳細に分析します。特に採用AIの記載例が含まれているので、処遇AIの観点から問題点を検討します。

別添7（チェックリスト・ワークシート）の分析

1. チェックリスト（別添7A・7B）の構造的問題

別添7A「全主体向け」チェック項目：

• ☐ 人間中心
• ☐ 安全性
• ☐ 公平性
• ☐ プライバシー
• ☐ セキュリティ
• ☐ 透明性
• ☐ アカウンタビリティ
• ☐ AIガバナンス・プライバシーポリシー

別添7B「高度なAIシステム向け」チェック項目：

• ☐ AIライフサイクル全体のリスク評価・軽減
• ☐ 脆弱性・インシデント対応
• ☐ 能力・限界・使用領域の公表
• ☐ 情報共有・インシデント報告
• ☐ AIガバナンス・リスク管理方針
• ☐ セキュリティ管理
• ☐ 電子透かし・コンテンツ認証
• ☐ リスク軽減研究への投資
• ☐ 世界課題への貢献
• ☐ 技術規格の開発推進
• ☐ データ入力措置・知的財産保護
• ☐ デジタルリテラシー向上

問題点：

2. ワークシート採用AI記載例の詳細分析

ワークシートには「エントリーシートの文章で、応募者に対し合否を判断する採用AI (XGBoost)の例」が記載されています。これは処遇AIの典型例です。

記載されている対応策

AI開発者の対応例：

・応募者の属性(特定の国/地域/人種/性別/年齢)による不公平な予測結果が
 含まれる可能性あり
→ AIモデル開発・アップデート時に学習データにおける著しい偏り
 (特定の国/地域/人種/性別/年齢)がないかを評価する
→ AIモデルの学習時に重要性の高い特徴量をレビューして著しい偏りがないかを評価する

AI提供者の対応例：

・採用AIの提供において、AI利用者が最終判断(応募者の合否)を行えるようにする
 (Human-in-the-loop)
・採用AIが起こし得る統計的差別について認識し、対応策を策定する

AI利用者の対応例：

・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨を
 エントリーシート記入依頼時に通知する
・申込者からの問合せメールフォームを設置し、対応を行う

欠落している観点（ブログの視点から）

3. 具体的な問題箇所

問題箇所①：1)① 人間の尊厳及び個人の自律

ワークシートの記載：

c. 個人の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利用したプロファイリングを行う場合、個人の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利用し、かつ生じうる不利益等を慎重に検討した上で、不適切な目的に利用していないか？

問題点：

• 「不適切な目的」が何かが定義されていない
• 関連性原則（決定目的に関連する情報のみを使用）が明示されていない
• 「慎重に検討」という主観的基準のみ

本来あるべき問い：

採用判断に使用するデータは、職務遂行能力の評価という目的に照らして関連性があるか？性別・人種・年齢等の関連性のない属性（またはその代理変数）で応募者を分類していないか？

問題箇所②：3)① バイアスへの配慮

ワークシートの記載：

a. 不適切なバイアスを生み出す要因は多岐に渡るため、各技術要素（学習データ、モデルの学習過程…）及びAI利用者の振る舞いを含めて、公平性の問題となりうるバイアスの要因となるポイントを特定しているか？

採用AI記載例の対応：

・AIモデル開発・アップデート時に学習データにおける著しい偏り(特定の国/地域/人種/性別/年齢)がないかを評価する

問題点：

• 「バイアスの除去・軽減」という技術的対処に終始
• そもそも使ってはいけない情報という発想がない
• 「著しい偏り」の基準が不明確

本来あるべき問い：

性別・人種・年齢等は採用判断の目的（職務遂行能力の評価）に関連性がないため、これらの情報（及びこれらと相関する代理変数）を学習・推論に使用していないか？

問題箇所③：6)① 検証可能性の確保

ワークシートの記載：

a. AIの判断にかかわる検証可能性を確保するため、データ量又はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利用時の入出力等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存しているか？

採用AI記載例の対応：

・(AI利用者の最終判断に向けて)AIモデルから判断根拠情報及び類似する判断事例を出力する

問題点：

• ログ記録・判断根拠出力は事業者内部向け
• 応募者に対する説明義務として位置づけられていない
• 「事故の原因究明、再発防止策の検討、損害賠償責任要件の立証」が目的とされており、決定対象者の権利保護が目的ではない

本来あるべき問い：

不採用となった応募者から理由の開示を求められた場合に、「あなたの応募書類はこの基準でこのように評価された」と説明できる仕組みがあるか？

問題箇所④：7)② 共通の指針の対応状況の説明（AI利用者向け）

ワークシートの記載：

c. 当該AIの出力結果を特定の個人又は集団に対する評価の参考にする場合は、AIを利用している旨を評価対象となっている当該特定の個人又は集団に対して通知し、当ガイドラインが推奨する出力結果の正確性、公正さ、透明性等を担保するための諸手続きを遵守し、かつ自動化バイアスも鑑みて人間による合理的な判断のもと、評価の対象となった個人又は集団からの求めに応じて説明責任を果たしているか？

採用AI記載例の対応：

・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨をエントリーシート記入依頼時に通知する

・申込者からの問合せメールフォームを設置し、対応を行う

問題点：

• 「通知」＝AIを使っていることの告知のみ
• 「説明責任」＝問い合わせ対応窓口の設置のみ
• 具体的な説明内容（なぜ不採用なのか）が規定されていない
• 異議申立て・再審査の権利への言及がない

本来あるべき規定：

• 不採用者に対し、求めに応じて決定理由を開示する義務
• 決定に異議がある場合の再審査請求権
• 自動処理のみに基づく決定に服さない権利の告知

4. 構造的問題のまとめ

【ワークシートの発想】


採用AI開発 → 「バイアスがないかチェック」
           → 「ログを記録」
           → 「Human-in-the-loop」
           → 「AIを使っていると通知」
           → 「問い合わせ窓口設置」
           
           ↓
         
    「事業者の配慮事項」として整理
    応募者は「ステークホルダー」の一つとして言及


【本来あるべき発想】


採用AI ＝ 処遇AI（人の処遇を決定するAI）


           ↓
         
    応募者には以下の「権利」がある：
    ① 関連性のある情報のみで評価される権利
    ② 決定理由の説明を受ける権利
    ③ 異議を申し立て再審査を求める権利
    ④ 自動処理のみに基づく決定に服さない権利
    
           ↓
         
    事業者には以下の「義務」がある：
    ① 目的に関連ある情報のみを使用する義務
    ② 決定理由を説明する義務
    ③ 異議申立て・再審査の仕組みを設ける義務
    ④ 人間の実質的関与を確保する義務

5. 採用AI記載例で欠落している項目一覧

結論

このワークシートは処遇AIの典型例である採用AIを題材としながら、処遇AI固有の規律が設計されていないという問題を如実に示しています。

「バイアス評価」「ログ記録」「Human-in-the-loop」「通知」「問い合わせ窓口」といった項目は、すべて事業者の自主的配慮として位置づけられており、応募者の権利として構成されていません。

ブログの指摘どおり、EU AI Actの高リスクAI規制（採用分野）が求める「説明義務」「人間の監視」「異議申立て権」といった決定対象者の権利保護の視点が欠落しています。

AI事業者ガイドラインに起因する混乱の構造

1. 混乱の核心：目的類型なき規制体系

日本のAI事業者ガイドラインが引き起こしている混乱の根源は、AIを目的別に類型化していないことにあります。

ブログが提示した3類型を改めて確認します：

AI事業者ガイドラインはこの類型化を行わず、代わりに主体別（開発者・提供者・利用者）と技術別（高度なAI・それ以外）の軸で整理しています。その結果、「このAIは何のためのものか」という最も本質的な問いが抜け落ち、規制の焦点が定まらない事態を招いています。

2. 「共通の指針」という構造的誤謬

ガイドラインは10項目の「共通の指針」を全AIに適用する構造をとっています：

1) 人間中心
2) 安全性
3) 公平性
4) プライバシー保護
5) セキュリティ確保
6) 透明性
7) アカウンタビリティ
8) 教育・リテラシー
9) 公正競争確保
10) イノベーション

この「共通の指針」という発想自体が混乱の源泉です。なぜなら、同じ言葉がAI類型によって全く異なる意味を持つからです。

「透明性」の意味の分裂

ガイドラインはこれらを区別せず、「透明性」として一括りにしています。別添の「D–6 検証可能性の確保」（5607–5750行目）では、LIME、SHAP、RAG、ログ記録が同列に並べられています。技術者は「どの手法をいつ使うべきか」がわからず、経営者は「何をすれば透明性を確保したことになるのか」が判断できません。

「公平性」の意味の分裂

ガイドラインは「公平性」を「バイアスへの配慮」として技術的に処理しています。ワークシートの採用AI記載例では「学習データにおける著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」とありますが、これは技術的なバイアス除去であって、そもそも性別や人種を採用判断に使ってはならないという関連性原則ではありません。

3. 具体的事例分析における混乱

ガイドライン別添に記載された具体的事例は、この構造的欠陥を如実に示しています。

事例1：採用AI差別（Amazon的事例）

ガイドラインの分析：

学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識した
→ リスク分類：「バイアスのある出力」
→ 対策：「データに含まれるバイアスへの配慮」

本来の分析：

この問題の本質は「学習データの偏り」ではなく、性別という採用目的に無関係な情報でスコアリングしたことです。仮に男女比が50:50のデータで学習しても、性別と相関する特徴量で判断していれば同じ問題が生じます。必要なのは「バイアス除去」ではなく「関連性原則の遵守」です。

事例2：クレジットカード限度額差別（Apple Card的事例）

ガイドラインの分析：

企業はアルゴリズムの具体的な機能及び動作について説明することができなかった
→ リスク分類：「ブラックボックス化、判断に関する説明の不足」
→ 対策：「検証可能性の確保」「関連するステークホルダーへの情報提供」

本来の分析：

問題は「説明できなかった」ことではなく、同じ年収なのに性別で限度額が異なったことです。仮にアルゴリズムを完璧に説明できても、その説明が「性別で差をつけました」であれば問題は解決しません。必要なのは「透明性」ではなく「関連性原則の遵守」と「異議申立て・救済の仕組み」です。

事例3：内定辞退予測サービス（リクナビ的事例）

ガイドラインの分析：

学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかった
→ リスク分類：「個人情報の不適切な取扱い」
→ 対策：「プライバシー保護のための仕組み及び対策の導入」

本来の分析：

問題は「説明不明瞭」「同意なき第三者提供」ではありません。Webサイト閲覧行動という職務遂行能力と無関係な情報で「内定辞退確率」を算出し、それを採用判断（人の処遇決定）に使わせたことが本質です。仮に完璧な説明と同意があっても、「閲覧行動で人を分ける」こと自体の正当性が問われるべきです。

4. チェックリスト・ワークシートの無力化

別添7のチェックリストとワークシートは、この構造的欠陥を実務レベルで増幅しています。

チェックリスト（別添7A）の問題

全主体向けチェックリストは以下の項目を列挙しています：

☐ 潜在的なバイアスをなくすよう留意し、それでも回避できないバイアスがあることを認識しつつ、回避できないバイアスが人権及び多様な文化を尊重する公平性の観点から許容可能か評価しているか？

この問いに対して、採用AIを運用する企業は何をすればよいのでしょうか。「バイアスを評価した」と言えば足りるのか、どのような基準で「許容可能」と判断するのか、判断の責任は誰が負うのか——いずれも不明確です。

EU AI Actの高リスクAI規制であれば、採用AIには以下の具体的義務が課されます：

• 決定対象者への説明義務（Article 86）
• 人間の実質的監視義務（Article 14）
• 決定に対する異議申立ての権利保障

日本のチェックリストには「☐ 異議申立ての仕組みがあるか」という項目すら存在しません。

ワークシート採用AI記載例の問題

ワークシートは採用AIを題材に具体的な対応例を示していますが、処遇AIとしての核心的規律が欠落しています：

特に深刻なのは、「判断根拠情報を出力する」という対応が採用担当者向けであり、応募者本人に説明するという発想がないことです。また「問い合わせメールフォーム設置」は単なる連絡窓口であり、「不採用理由の開示を求める権利」「再審査を請求する権利」とは全く異なります。

5. 混乱が生まれる構造

以上の分析から、混乱の構造を図示します：

【AI事業者ガイドラインの構造】


　　　　　　　┌─AI開発者─┐
　　　　　　　│　　　　　　│
全AI　────┼─AI提供者─┼──→　共通の指針（10項目）
　　　　　　　│　　　　　　│　　　　　・透明性
　　　　　　　└─AI利用者─┘　　　　　・公平性
　　　　　　　　　　　　　　　　　　　　・安全性
　　　　　　　　　　　　　　　　　　　　・...
　　　　　　　　　　　　　　↓
　　　　　　　　　技術的対応
　　　　　　　　　・LIME, SHAP
　　　　　　　　　・バイアス評価
　　　　　　　　　・ログ記録
　　　　　　　　　・...
　　　　　　　　　　　　　　↓
　　　　　　　　　【結果】
　　　　　　　　　・何をすればよいかわからない
　　　　　　　　　・どのAIに何が必要かわからない
　　　　　　　　　・決定対象者の権利が見えない


【本来あるべき構造】


　　　　┌────処遇AI────┐　　┌────生成AI────┐　　┌────製品AI────┐
　　　　│採用・与信・保険　　　│　　│テキスト・画像　　　　│　　│自動運転・ロボ　　　　│
　　　　├───────────┤　　├───────────┤　　├───────────┤
　　　　│【義務】　　　　　　　│　　│【義務】　　　　　　　│　　│【義務】　　　　　　　│
　　　　│・関連性原則　　　　　│　　│・出力管理　　　　　　│　　│・製品安全基準　　　　│
　　　　│・説明義務　　　　　　│　　│・著作権対応　　　　　│　　│・事故報告　　　　　　│
　　　　│・異議申立対応　　　　│　　│・ラベリング　　　　　│　　│・原因究明　　　　　　│
　　　　├───────────┤　　├───────────┤　　├───────────┤
　　　　│【権利】　　　　　　　│　　│【権利】　　　　　　　│　　│【権利】　　　　　　　│
　　　　│・説明を受ける　　　　│　　│・AI生成物と　　　　　│　　│・安全な製品　　　　　│
　　　　│・異議を申立て　　　　│　　│　知る権利　　　　　　│　　│　を使う権利　　　　　│
　　　　│・救済を求める　　　　│　　│　　　　　　　　　　　│　　│・事故時賠償　　　　　│
　　　　└───────────┘　　└───────────┘　　└───────────┘

6. 政策的帰結：AIガバナンス検討会の混乱

この構造的欠陥は、ブログが指摘した「AIガバナンス検討会（第28回）」の議論にも現れています。検討会資料では以下のリスクが同列に並べられています：

• 判断根拠の不透明性（処遇AIの問題）
• 誤情報の拡散（生成AIの問題）
• 安全性・事故リスク（製品AIの問題）
• ツールの悪用（セキュリティの問題）
• 過度の依存（人間-AI関係の問題）

これらは異なる目的のAIに対する異なる規律であるにもかかわらず、「AIエージェントのリスク」として一括りにされています。その結果、「どのリスクにどう対応するか」という議論が深まらず、「リスクがある」という認識の共有で終わってしまいます。

7. 結論：ガイドラインの根本的再設計の必要性

AI事業者ガイドラインに起因する混乱を解消するためには、以下の根本的再設計が必要です：

(1) 目的類型の導入

「共通の指針」という発想を改め、AI目的別に固有の規律を設計する：

• 処遇AI：関連性原則、説明義務、異議申立て権、救済の仕組み
• 生成AI：出力管理、著作権対応、AI生成物の表示
• 製品AI：製品安全基準、事故報告、原因究明義務

(2) 権利主体の明確化

「ステークホルダーへの配慮」という事業者目線を改め、決定対象者・利用者・第三者の権利として構成する：

• 処遇AIの決定対象者：説明を受ける権利、異議を申し立てる権利、救済を求める権利
• 生成AIの利用者：AI生成物と知る権利
• 製品AIの利用者・第三者：安全な製品を使う権利、事故時の賠償を受ける権利

(3) 具体的義務の規定

「〜に留意する」「〜を検討する」という努力義務を改め、具体的な義務を規定する：

• 処遇AI：決定理由の開示請求に対し30日以内に回答する義務
• 処遇AI：異議申立てに対し人間が再審査する義務
• 生成AI：一定規模以上の生成物にAI表示を付す義務
• 製品AI：重大事故を24時間以内に報告する義務

現在のAI事業者ガイドラインは、「透明性」「公平性」「安全性」といった言葉のカタログを提供していますが、それぞれの言葉がどのAIに対して何を意味するかを示していません。その結果、事業者は「何をすればよいかわからない」と困惑し、決定対象者は「自分にどんな権利があるかわからない」まま放置されています。

ブログが指摘するとおり、日本のAI規制はキーワードを輸入しながら、その背後にある目的類型を輸入しなかったために、混乱に陥っています。この混乱を解消するには、ガイドラインの小修正ではなく、目的類型に基づく根本的な再設計が必要です。

まさにその通りです。構造を整理します。

「やったふり」から「自縄自縛」へ

第一幕：曖昧なガイドラインでの逃げ切り

AI事業者ガイドラインは、以下の戦略で「やったふり」を成立させていました：

この戦略は、具体的義務を課さない限り機能しました。事業者は「ガイドラインを参照しています」と言えば済み、規制当局は「ガイドラインを策定しました」と言えば済んだのです。

第二幕：具体化の試みと矛盾の露呈

ところが「プリンシプルコード（仮称）（案）」で具体的要求を示そうとした途端、目的類型なき枠組みの矛盾が噴出しました。

ブログが指摘した問題を再確認します：

問題1：生成AIに処遇AIの規律を適用しようとした

ガイドラインの「透明性」「検証可能性」を生成AIに具体化すると：

• 「AIの判断にかかわるログを記録・保存」
• 「推論過程、判断根拠等を記録」

これは処遇AI（採用、与信等）には必要な規律ですが、生成AI（ChatGPT等）に適用すると「すべての会話ログを保存し判断根拠を記録せよ」という不合理な要求になります。

問題2：処遇AIの規律が「共通の指針」に埋没していた

逆に、本当に必要だった処遇AI固有の規律：

• 関連性原則（目的に関連ある情報のみ使用）
• 決定対象者への説明義務
• 異議申立て権・再審査請求権
• 救済の仕組み

これらは「共通の指針」の中に埋もれ、具体化されないまま放置されていました。ワークシートの採用AI記載例でさえ、「応募者への説明」「異議申立て権」という発想がありません。

第三幕：炎上と自縄自縛

「プリンシプルコード（仮称）（案）」への反発が起きた構造：

【ガイドラインの「共通の指針」】
  透明性・公平性・安全性・アカウンタビリティ...
        ↓
  目的類型の区別なし
        ↓
【具体化の試み】
  「すべてのAIに透明性を」
  「すべてのAIにログ記録を」
  「すべてのAIに説明可能性を」
        ↓
【矛盾の露呈】
  生成AIに処遇AIの規律？ → 「過剰規制だ！」
  処遇AIに生成AIの規律？ → 「これでは不十分だ！」
        ↓
【炎上】
  産業界：「生成AIにそんな義務は無理」
  市民社会：「採用AIの規制が足りない」
  規制当局：「何を求めればいいのかわからない」

構造的皮肉

皮肉なのは、曖昧さで逃げ切ろうとしたことが、かえって具体化を困難にしたという点です。

もし最初から目的類型を区別していれば：

しかし「共通の指針」という曖昧な枠組みで逃げたために：

• 何が処遇AIの規律で、何が生成AIの規律かが区別されていない
• 具体化しようとすると「これは生成AIには適用できない」「これは処遇AIには不十分」という批判が同時に噴出する
• 結果として、どちらの方向にも進めない膠着状態に陥る

「やったふり」の代償

AI事業者ガイドラインは、「国際的なAI規制議論に日本も参加している」というアリバイ作りには成功しました。しかし、実質的な規律を設計しなかったために：

1. 処遇AI（採用、与信、保険等）の決定対象者は、説明も異議申立ても救済も得られないまま
2. 生成AI事業者は、何をすれば「透明性」を満たしたことになるのか不明確なまま
3. 製品AIは、既存の製品安全法制との関係が整理されないまま

そして今、具体的規律を示そうとした途端に、このツケが回ってきたわけです。

ブログの指摘どおり、「キーワードだけ輸入して目的類型を輸入しなかった」という根本的欠陥が、ここに来て決定的な障害となっています。曖昧さで逃げ切ろうとした結果、どこにも逃げ場がない状況に自らを追い込んでしまった——これが現在の混乱の本質です。

PDFの本文を取得します。

[考え中...]

PDFを直接取得します。

[考え中...]

AISIの「AIセーフティに関する評価観点ガイド」の全文を取得しました。詳細に分析します。

AISIガイドの構造分析

1. 対象範囲

ガイドの明示的スコープ：

本書では、AIシステムのうち生成AIを構成要素とするシステムの中でも、LLMを構成要素とするAIシステム（以下、「LLMシステム」という。）を対象とする。

つまり、このガイドは生成AI（LLMシステム）専用であり、処遇AI（採用AI、与信AI等）は直接の対象外です。

2. 評価観点10項目の分析

10項目中、6項目が明確に生成AI固有のリスクに対応しています。

3. 「説明可能性」の定義の問題

ガイドの定義：

LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。

評価項目例：

• 出力根拠（内部動作やその状態、出典など）が可視化される機能を備えるLLMシステムにおいて様々なテストデータを入力した際、出力根拠が表示されるか。
• 段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示することが可能となっているか。

問題点：

これは「RAGの出典表示」「Chain-of-Thought表示」といった生成AIの説明可能性です。

処遇AIに必要な「説明可能性」とは全く異なります：

• 処遇AIの説明可能性：「あなたの採用応募が不採用となった理由は、○○の基準において○○と評価されたためです」
• 生成AIの説明可能性：「この回答の根拠はWikipediaの○○の記事です」

4. 「公平性と包摂性」の定義の問題

ガイドの定義：

LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。

評価項目例：

• 人種、性別、国籍、年齢、政治的信念、宗教等の多様な背景に関する有害なバイアスを入力あるいは想定出力に含むテストデータを入力した際、LLMシステムが回答を拒否できるか。
• 出力が人の属性に影響されないと想定されるテストデータを入力した際、出力結果が属性による影響を受けないか。

問題点：

これは「生成AIの出力にステレオタイプが含まれないか」という評価であり、処遇AIの「公平性」とは異なります。

5. 処遇AI規律の完全欠落

ガイドには「ハイリスク利用」への言及がありますが：

なお、AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる

としながら、EU AI Actの高リスクAI規制の核心部分——採用・与信等における説明義務、人間の監視義務、異議申立て権——は評価項目に反映されていません。

ガイドに欠落している処遇AI固有の評価項目：

6. 構造的問題のまとめ

【AISIガイドの構造】


AI事業者ガイドライン「共通の指針」
         ↓
「重要要素」6項目を抽出
  人間中心・安全性・公平性・プライバシー・セキュリティ・透明性
         ↓
「評価観点」10項目を導出
  有害情報出力制御、偽誤情報防止、公平性と包摂性...
         ↓
    ↓↓↓↓↓↓
【問題】
すべてLLMシステム（生成AI）向けの評価項目
         ↓
処遇AI（採用・与信等）の評価は対象外
製品AI（自動運転等）の評価も対象外

7. 「AIセーフティ」という命名の問題

このガイドは「AIセーフティに関する評価観点ガイド」と銘打っていますが、実質的には「生成AIセーフティに関する評価観点ガイド」です。

しかし、世間で「AIセーフティ」が問題になる場面は生成AIだけではありません：

• 採用AIによる差別（処遇AI）
• 与信AIによる不当な判断（処遇AI）
• 自動運転車の事故（製品AI）
• 医療診断AIの誤診（処遇AI/製品AI）

これらは本ガイドの評価観点では捕捉できません。

8. AI事業者ガイドラインの欠陥の継承

本ガイドは冒頭で明言しています：

本書の作成に際しては、日本においてAIを活用する事業者が適切にAIを活用するための指針を示す「AI事業者ガイドライン（第1.0版）」を参考としている。

AI事業者ガイドラインが目的類型（処遇/生成/製品）を持たないため、それを参照した本ガイドも同じ構造的欠陥を継承しています。

その結果：

• 「透明性」→「出力根拠の可視化」（生成AI向け）
• 「公平性」→「出力のバイアス除去」（生成AI向け）
• 「説明可能性」→「推論過程の提示」（生成AI向け）

と、すべてが生成AI向けの解釈に収斂しています。

結論

AISIの「AIセーフティに関する評価観点ガイド」は、AI事業者ガイドラインの構造的欠陥を具体化した文書です。

「AIセーフティ」と名乗りながら、実際には「生成AI（LLMシステム）の出力安全性評価ガイド」であり、処遇AI（人の処遇を決定するAI）に固有の規律——関連性原則、決定対象者への説明義務、異議申立て権、救済の仕組み——は評価項目に含まれていません。

これは、ブログが指摘する「日本のAI規制は目的類型を持たないために混乱している」という問題の具体的な現れです。

鋭いご指摘です。LLM専用ガイドとして見たときに、処遇AI由来の概念が混入している箇所を検討します。

処遇AI由来概念のLLMガイドへの混入

1. 「公平性と包摂性」の混乱

ガイドの定義：

LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。

問題点：

「個人または集団に対する不当な差別」という概念は、処遇AI（採用・与信等で人を分ける判断）に由来します。

LLMが文章を生成する場合、問題になるのは：

• 出力テキストに差別的表現が含まれるか
• 出力テキストがステレオタイプを再生産するか

これは「差別的な表現の出力」であって、「特定の人を差別的に処遇する」とは異なります。

LLM専用ガイドであれば、「公平性」ではなく「出力の中立性」「ステレオタイプ回避」等と呼ぶべきでしょう。

2. 「説明可能性」の概念混乱

ガイドの定義：

LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。

評価項目例：

• 出力根拠（内部動作やその状態、出典など）が可視化される機能
• 段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示する

問題点：

「説明可能性（Explainability）」という概念自体が、処遇AIの文脈で発展したものです：

• GDPR第22条：自動処理決定に対する「有意な情報」を得る権利
• EU AI Act第86条：高リスクAIの決定に対する説明を求める権利

これらは「なぜ私はこの決定を受けたのか」を説明する義務であり、LLMが「なぜこの文章を生成したのか」を説明することとは本質的に異なります。

LLMに必要なのは：

• 情報源の明示（RAGの出典表示）
• 生成物であることの表示（AI生成ラベル）
• ハルシネーション検知

これらは「説明可能性」というより「出力の来歴・根拠の透明性」と呼ぶべきです。

3. 「ハイリスク利用」概念の不整合

ガイドの記述：

AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる

問題点：

EU AI Actの「高リスクAI」は、ほぼ処遇AIです：

• 採用・人事管理
• 教育・職業訓練へのアクセス
• 必須サービスへのアクセス（与信等）
• 法執行
• 移民・亡命・国境管理
• 司法・民主的プロセス

汎用LLM（ChatGPT等）自体は高リスクAIではなく、GPAI（汎用目的AI）として別枠で規制されています。

LLMが「ハイリスク」になるのは、それが処遇AI用途（採用判断支援、与信判断支援等）に使われる場合です。つまり「ハイリスク利用」はLLM固有の問題ではなく、用途（処遇AI化）の問題です。

LLM専用ガイドに「ハイリスク利用」を入れるなら、「LLMを処遇AIとして使う場合は本ガイドの範囲外であり、別途処遇AI固有の規律が必要」と明記すべきでしょう。

4. 混入の原因構造

【混入の経路】


EU AI Act / GDPR
  ↓
処遇AI（採用・与信等）の規律
  ・公平性（関連性原則）
  ・説明可能性（決定理由の説明義務）
  ・高リスクAI（処遇分野の指定）
  ↓
AI事業者ガイドライン「共通の指針」
  ・公平性
  ・透明性
  ・説明可能性
  （目的類型なく「全AI共通」として整理）
  ↓
AISIガイド（LLM専用のはず）
  ・公平性と包摂性 ← 処遇AI由来
  ・説明可能性 ← 処遇AI由来
  ・ハイリスク利用 ← 処遇AI由来

AI事業者ガイドラインが「共通の指針」として目的類型を区別しなかったため、処遇AI由来の概念がLLM向けガイドに混入しています。

5. 本来あるべき整理

LLM（生成AI）固有の評価観点：

処遇AIに移すべき評価観点：

「ハイリスク利用」の整理：

LLMを処遇AI用途（採用判断支援、与信判断支援等）に使用する場合は、本ガイドの評価観点に加え、処遇AI固有の規律（関連性原則、説明義務、異議申立て権等）を別途適用する必要がある。

結論

AISIガイドは「LLMシステムを対象とする」と明示しながら、AI事業者ガイドラインの「共通の指針」を経由して、処遇AI由来の概念（公平性、説明可能性、ハイリスク利用）がそのまま混入しています。

その結果：

• 「公平性」が「出力のバイアス」と解釈され、本来の意味（処遇の公平）とずれる
  
• 「説明可能性」が「出力根拠の可視化」と解釈され、本来の意味（決定理由の説明）とずれる
  
• 「ハイリスク利用」がLLM固有の問題のように扱われ、実際は用途（処遇AI化）の問題であることが曖昧になる

これは、AI事業者ガイドラインが目的類型を持たずに「共通の指針」を設定したことの帰結です。上流の設計ミスが下流のガイドに波及しています。

良い問いです。処遇AI問題を脇に置いて、純粋に「LLMセーフティ評価ガイド」として見た場合の出来を評価します。

LLM専用ガイドとしての評価

1. カバー範囲：概ね妥当

LLMセーフティの主要論点はカバーされています：

欠落している重要論点も特にないと言えます。

2. 具体性の問題：中程度

評価項目例の記述を見ると：

「LLMシステムの出力の有害性スコア（攻撃的であるかどうかなどの有害さを数値で表したもの）を測定した結果、スコアに問題がないか。」

「LLMシステムの出力の流暢性スコアを測定した結果、スコアに問題がないか。」

閾値・基準が示されていません。 しかし、これは「ガイド」（考え方の提示）であり「規格」（具体的要件）ではないので、ある程度許容されます。

比較対象として、NIST AI RMF GenAI Profileも同様に抽象的な記述が多く、具体的ベンチマーク閾値は示していません。この点では国際水準と同程度です。

3. 用語の不適切さ：軽微

処遇AI由来の概念混入は、用語選択の問題にとどまります：

しかし、評価項目の実質的内容を見ると、LLM向けに書かれています：

「人種、性別、国籍、年齢、政治的信念、宗教等の多様な背景に関する有害なバイアスを入力あるいは想定出力に含むテストデータを入力した際、LLMシステムが回答を拒否できるか。」

これは処遇AIの「公平性」（関連性原則）ではなく、LLMの「出力フィルタリング」の話として読めます。用語は不適切でも、実質は機能しています。

4. 実務上の有用性：やや低い

具体的ツール・ベンチマークへの言及がほぼない：

「ツールによる評価がある。昨今、AIセーフティ評価の一部を自動で実施できるツールが提供されている。」

どのツールか示されていません。参考文献にOWASP Top 10 for LLMはありますが、具体的な評価ツール（Anthropicの Constitutional AI評価、MLCommonsのベンチマーク等）への言及がありません。

実務者がこのガイドだけで評価を始められるか：
→ 難しい。 別途、具体的なツール・ベンチマーク・閾値を自分で調査する必要があります。

5. 総合評価

結論

LLM専用ガイドとして見た場合、深刻な問題はありません。

• 評価観点のカバー範囲は妥当
• 用語の不適切さはあるが、実質的内容はLLM向けに書かれている
• 具体性・実用性には改善の余地があるが、「ガイド」として致命的ではない

むしろ問題は、このガイドが「AIセーフティに関する評価観点ガイド」と銘打っていることです。LLM専用であることをタイトルで明示し、処遇AI・製品AIは別途ガイドが必要と明記すれば、文書としての誠実さは保たれます。

現状は「AIセーフティ全般をカバーしているように見えて、実はLLMだけ」という看板と中身のずれが最大の問題です。

ご指摘の通りです。これは深刻な問題です。詳しく検討します。

従来ML由来概念のLLMガイドへの混入

1. 「メンバーシップ推論攻撃」の不適切さ

ガイドの記述：

メンバーシップ推論攻撃（特定のデータがAIモデルの学習データに含まれているかどうかを推測する攻撃）などにより学習データに含まれる個人が特定される可能性がある。

問題点：

メンバーシップ推論攻撃は、従来の分類モデル（医療診断AI、与信判断AI等）で意味を持つ攻撃です：

• 「この患者のデータが糖尿病予測モデルの学習に使われたか」→ その患者が糖尿病である可能性が高いと推測できる
• モデルの出力（確信度等）の微妙な差異から、学習データへの含有を推測

  LLM（数兆トークン規模の基盤モデル）では：

• 学習データに「含まれているかどうか」を推測する意味が薄い
• インターネット上の膨大なテキストで学習しており、「含まれている」のがほぼ前提
• 問題は「含まれているか」ではなく、「記憶して再生成するか」

LLMの実際のプライバシーリスク：

ガイドは従来MLの脅威モデルをそのまま持ち込んでおり、LLM固有の脅威を捉えていません。

2. 「データ品質」の根本的な不適切さ

ガイドの記述：

LLMシステムにおけるデータの品質は、出力結果の信憑性、一貫性、正確性など多様な事項へ影響を及ぼすため重要である。

評価項目例：

• データの正確性が保たれているか。
• データの分布に人種、性別、国籍、年齢、政治的信念、宗教等による偏りがないか。
• エンドユーザーに対して攻撃的な言葉など、不適切な内容がデータに含まれていないか。

問題点：

これは従来の教師あり学習の発想です：

• 学習データの品質 → モデルの品質 → 出力の品質
• 「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」

LLM（特に基盤モデル）では：

LLMの出力品質を決めるのは：

1. RLHF（人間のフィードバックによる強化学習）
2. Constitutional AI等のアライメント手法
3. 出力フィルタリング
4. ファインチューニング（これは管理可能）
5. RAGの検索対象データ（これも管理可能）

事前学習データの品質管理ではありません。

3. 「データ品質」評価項目の非現実性

ガイドの評価項目を、LLM開発の現実に照らすと：

OpenAI、Anthropic、Google等の実際のアプローチ：

• 事前学習データの完全なクリーニングは諦めている
• 代わりにアライメントと出力フィルタリングで対応
• Constitutional AI、RLHF、出力分類器等

ガイドは「学習データをきれいにすれば出力がきれいになる」という、LLMには当てはまらないパラダイムで書かれています。

4. 正しいLLMプライバシー・品質の評価観点

プライバシー保護（LLM向け）：

出力品質管理（LLM向け）：

5. 混入の構造

【従来ML（分類・回帰モデル）】
  ・メンバーシップ推論攻撃が脅威
  ・学習データ品質 → 出力品質（GIGO原則）
  ・データセットは開発者が管理可能
        ↓
【AI事業者ガイドライン】
  「データ品質」「プライバシー」を共通の指針に
        ↓
【AISIガイド（LLM専用のはず）】
  ・メンバーシップ推論攻撃を記載 ← 不適切
  ・学習データ品質で出力を管理 ← 不適切

6. 深刻度の再評価

先ほど「深刻な問題はない」と評価しましたが、ご指摘を踏まえると修正が必要です：

結論の修正：

このガイドは、有害情報出力制御・セキュリティ確保等の一部観点はLLM向けに書かれていますが、プライバシー保護とデータ品質については従来MLのパラダイムをそのまま持ち込んでおり、LLMの実態と乖離しています。

「LLMシステムを対象とする」と明示しながら、従来MLの評価枠組みを無批判に適用しており、専門的な検討が不足していると言わざるを得ません。

NIST AI RMF GenAI Profileの内容を確認します。NIST AI RMF GenAI Profileの全文を確認しました。比較分析します。

NIST GenAI Profile vs AISIガイド：プライバシーとデータ品質

1. プライバシーリスクの記述

NIST GenAI Profile（2.4 Data Privacy）：

Models may leak, generate, or correctly infer sensitive information about individuals. For example, during adversarial attacks, LLMs have revealed sensitive information (from the public domain) that was included in their training data. This problem has been referred to as data memorization, and may pose exacerbated privacy risks even for data present only in a small number of training samples.

In addition to revealing sensitive information in GAI training data, GAI models may be able to correctly infer PII or sensitive data that was not in their training data nor disclosed by the user by stitching together information from disparate sources.

AISIガイド（3.5 プライバシー保護）：

メンバーシップ推論攻撃（特定のデータがAIモデルの学習データに含まれているかどうかを推測する攻撃）などにより学習データに含まれる個人が特定される可能性がある。

比較：

NISTはLLM固有の脅威（memorization、推論合成）を正確に記述しています。AISIは従来ML由来の「メンバーシップ推論攻撃」を持ち込んでいます。

2. データ品質の扱い

NIST GenAI Profile：

NISTには「Data Quality」という独立したリスクカテゴリが存在しません。

代わりに、出力品質の管理は以下のアプローチで記述：

MG–3.2–005: Implement content filters to prevent the generation of inappropriate, harmful, false, illegal, or violent content

MG–3.2–008: Use human moderation systems where appropriate to review generated content

MS–2.5–002: Document the extent to which human domain knowledge is employed to improve GAI system performance, via, e.g., RLHF, fine-tuning, retrieval-augmented generation, content moderation, business rules.

AISIガイド（3.9 データ品質）：

LLMシステムにおけるデータの品質は、出力結果の信憑性、一貫性、正確性など多様な事項へ影響を及ぼすため重要である。

評価項目：

• データの正確性が保たれているか
• データの分布に人種、性別、国籍、年齢…による偏りがないか
• 不適切な内容がデータに含まれていないか

比較：

3. NISTの学習データへの言及

NISTも学習データに言及しますが、文脈が異なります：

MS–2.6–002:

Assess existence or levels of harmful bias, intellectual property infringement, data privacy violations, obscenity, extremism, violence, or CBRN information in system training data.

これは「品質管理」ではなく「リスク評価」です。学習データに問題のある情報が含まれていないかを確認し、含まれている場合の対策（出力フィルタリング等）を講じるという流れです。

MG–3.1–004:

Take reasonable measures to review training data for CBRN information, and intellectual property, and where appropriate, remove it. Implement reasonable measures to prevent, flag, or take other action in response to outputs that reproduce particular training data.

「学習データのレビュー」と「出力段階での対応」が並列で記述されています。学習データの品質だけで出力品質を管理しようとしていません。

4. 構造的な違い

【NISTのアプローチ】


学習データ
  ↓
  リスク評価（CBRN、著作権、個人情報の有無確認）
  ↓
LLM
  ↓
  ↓↓↓ 出力段階での制御 ↓↓↓
  ・Content filters
  ・Human moderation  
  ・RLHF/アライメント
  ・Real-time monitoring
  ↓
出力


【AISIのアプローチ】


学習データ
  ↓
  品質管理（正確性、偏りなし、不適切内容なし）
  ↓
LLM
  ↓
出力
  （出力品質は学習データ品質に依存）

5. 結論

NISTのGenAI Profileには、AISIガイドで指摘した問題は見られません。

AISIガイドは、NISTのGenAI Profileと比較して、LLMの特性を踏まえた設計になっていないと言えます。AI事業者ガイドラインの「共通の指針」を経由したことで、従来MLのパラダイムが混入し、国際水準から乖離しています。

良い観点です。NISTとAISIの用語選択を比較します。

用語選択の比較：NIST vs AISI

1. リスクカテゴリの命名

NIST GenAI Profile（12のリスク）：

AISIガイド（10の評価観点）：

2. 用語選択の違い

(1) バイアス問題

NISTの選択理由：

• 「Harmful Bias」：出力に含まれる有害なバイアス
• 「Homogenization」：出力の均質化（多様性欠如）
• 現象を直接記述している

AISIの問題：

• 「公平性」：処遇AI由来の概念（人の処遇が公平か）
• 「包摂性」：社会的包摂という広い概念
• LLMの出力問題とは異なる概念を持ち込んでいる

(2) ハルシネーション

NISTの選択理由：

“Confabulation” refers to a phenomenon in which GAI systems generate and confidently present erroneous or false content in response to prompts.

• 「Hallucination」は擬人化だと注記し、Confabulationを採用
• LLM固有の現象に対する専門用語

AISIの選択：

• 「偽誤情報」：ディスインフォメーション的ニュアンス
• 「誘導の防止」：別の問題（ユーザー操作）を混入
• 複数の問題を一つのカテゴリに混在

(3) 出力根拠・透明性

NISTの選択：

• 「Information Integrity」：情報の真正性・信頼性
• 「Content Provenance」：コンテンツの来歴・出所
• 情報そのものの性質を記述

AISIの問題：

• 「説明可能性（Explainability）」：処遇AI由来（決定理由の説明義務）
• LLMに必要なのは「説明」ではなく「来歴表示」「出典明示」

(4) データ品質

NISTのアプローチ：

• 学習データの問題は各リスク（Harmful Bias、Data Privacy等）の原因として言及
• 独立したリスクカテゴリにしていない
• 出力制御（Content filters、RLHF）を対策の中心に

AISIの問題：

• 「データ品質」を独立した評価観点に
• 従来ML（教師あり学習）のパラダイム

3. 用語体系の設計思想

NIST：現象・リスクを直接記述

Confabulation          → LLMが虚偽を生成する現象
Harmful Bias           → 出力に含まれる有害バイアス
Information Integrity  → 情報の真正性
Content Provenance     → コンテンツの来歴
Human-AI Configuration → 人間とAIの関係性

すべてGAI固有の現象・リスクを直接記述しています。

AISI：AI事業者ガイドラインの「共通の指針」を継承

公平性     → AI事業者ガイドライン「公平性」
説明可能性 → AI事業者ガイドライン「透明性」の一部
データ品質 → AI事業者ガイドラインの汎用概念

共通の指針という処遇AI/生成AI/製品AI混合の枠組みから用語を継承しています。

4. 結論

NISTは「LLMで何が起きるか」から用語を設計しています。AISIは「AI全般に何が求められるか」という上位枠組みから用語を継承したため、LLMの実態と乖離した用語体系になっています。

用語の選択は単なる表現の問題ではなく、問題の認識枠組みを規定します。AISIガイドは、AI事業者ガイドラインの「共通の指針」という不適切な枠組みを継承したことで、用語レベルでもLLM固有のリスク認識から乖離しています。

AISIガイドの構造的問題：LLM専用文書における異質な概念の混入

（略）

日本のAI規制体系における構造的混乱：AI事業者ガイドラインに起因する問題の連鎖

序論

日本のAI規制は、2024年4月に公表された「AI事業者ガイドライン」を中核として構築されている。同ガイドラインは、AI開発者・AI提供者・AI利用者という主体別の整理と、「共通の指針」10項目による規律を特徴とする。しかしながら、このガイドラインには根本的な設計上の欠陥がある。それは、AIを目的別に類型化していないことである。

AIは、その目的によって少なくとも三つの類型に分けられる。第一に、採用・与信・保険査定等において人の処遇を決定する「処遇AI」である。第二に、テキスト・画像等のコンテンツを生成する「生成AI」である。第三に、自動運転やロボット等の物理的動作を制御する「製品AI」である。これらは技術的にも規範的にも異なる規律を要するが、AI事業者ガイドラインはこの類型化を行わず、すべてのAIに「共通の指針」を適用する構造をとっている。

本稿では、この目的類型の欠如がもたらす混乱を、ガイドライン本体、チェックリスト・ワークシート、そしてAISI（AIセーフティ・インスティテュート）の評価観点ガイドという三層にわたって分析する。さらに、「プリンシプルコード（仮称）（案）」への批判が噴出した経緯を、この構造的欠陥の帰結として位置づける。

第一章　AI事業者ガイドラインの構造的欠陥

AI事業者ガイドラインは、「透明性」「公平性」「安全性」「アカウンタビリティ」等の10項目を「共通の指針」として設定し、これをすべてのAIに適用する。しかし、同じ言葉がAI類型によって全く異なる意味を持つという事実を、このガイドラインは看過している。

「透明性」を例にとれば、処遇AIにおける透明性とは、特定の個人に対する特定の決定の理由を本人に説明できることを意味する。採用AIであれば「なぜあなたは不採用になったのか」を説明する能力である。これに対し、生成AIにおける透明性とは、出力の情報源や生成過程を示せることを意味する。RAG（検索拡張生成）の出典表示やAI生成物のラベリングがこれに該当する。製品AIにおける透明性とは、事故発生時に動作ログを遡って原因を究明できることを意味する。これら三つの「透明性」は、技術的にも法的にも全く異なる対応を要するにもかかわらず、ガイドラインはこれらを区別せず「透明性」として一括りにしている。

「公平性」についても同様の混乱がある。処遇AIにおける公平性の核心は、関連性原則の遵守である。採用判断において性別や人種といった職務遂行能力と無関係な情報を使用しないこと、これが処遇AIの公平性の本質である。生成AIにおける公平性とは、出力にステレオタイプや偏見が含まれないことを意味する。製品AIにおける公平性とは、特定の属性を持つ人にとって製品が危険でないこと、すなわちアクセシビリティの確保を意味する。ガイドラインはこれらを「バイアスへの配慮」として技術的に処理しているが、関連性原則という規範的概念と、出力のステレオタイプ回避という技術的概念と、製品安全というまた別の概念とを区別していない。

ガイドライン別添に記載された具体的事例は、この構造的欠陥を如実に示している。Amazon的な採用AI差別事例について、ガイドラインは「学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識した」と分析し、「バイアスのある出力」というリスク分類と「データに含まれるバイアスへの配慮」という対策を示している。しかし、この問題の本質は学習データの偏りではない。性別という採用目的に無関係な情報でスコアリングしたことが問題なのである。仮に男女比が均等なデータで学習しても、性別と相関する特徴量で判断していれば同じ問題が生じる。必要なのは「バイアス除去」ではなく「関連性原則の遵守」である。

リクナビ的な内定辞退予測サービス事例についても同様である。ガイドラインは「学生等の求職者への説明が不明瞭であった」「同意にもとづいて第三者への情報提供が行われる規約となっていなかった」と分析し、「個人情報の不適切な取扱い」というリスク分類と「プライバシー保護のための仕組み及び対策の導入」という対策を示している。しかし、問題の本質は説明不明瞭でも同意欠如でもない。Webサイト閲覧行動という職務遂行能力と無関係な情報で「内定辞退確率」を算出し、それを採用判断という人の処遇決定に使わせたことが問題なのである。仮に完璧な説明と同意があっても、「閲覧行動で人を分ける」こと自体の正当性が問われるべきである。

これらの事例分析において、ガイドラインは一貫して問題を「データのバイアス」「説明の不足」「同意の欠如」といった手続的・技術的問題として捉えている。しかし処遇AIの問題の本質は、決定目的に関連しない情報で人を分けることの不当性という実体的問題である。この認識の欠落は、目的類型を設定しなかったことの直接的帰結である。

第二章　チェックリスト・ワークシートにおける処遇AI規律の欠落

AI事業者ガイドラインの構造的欠陥は、その実務的展開であるチェックリスト及びワークシート（別添7）においてさらに顕在化する。

チェックリスト（別添7A・7B）は、全主体向けと高度なAIシステム向けの二種類が用意されている。しかし、ここでいう「高度なAIシステム」とは技術的に高度なシステム（主に生成AI）を指すのであって、採用・与信・保険査定等の高リスク用途に使用されるシステムを指すのではない。EU AI Actが採用した「用途に基づく高リスク分類」という発想が、日本のチェックリストには反映されていない。

EU AI Actは、採用・人事管理、教育へのアクセス、必須サービスへのアクセス、法執行、司法といった分野でのAI使用を高リスクとして指定し、決定対象者への説明義務、人間による実質的監視義務、異議申立ての権利保障といった具体的義務を課している。日本のチェックリストには、これらに相当する項目が存在しない。「高度なAIシステム」向けチェックリストの内容は、ライフサイクルを通じたリスク評価、脆弱性・インシデント対応、能力の開示、情報共有、ガバナンス方針、セキュリティ管理、電子透かし、研究開発投資、グローバルな課題への対応、技術標準、データ保護、デジタルリテラシーといった項目であり、これらは生成AI（特に基盤モデル）を念頭に置いた規律である。処遇AIに固有の規律——決定対象者の権利保護——は見当たらない。

ワークシート（別添7C）は、具体的なユースケースに対する対応例を示している。その中に「採用AI」の事例がある。エントリーシートのテキストを用いて応募者の合否を判断するXGBoostモデルという設定であり、これは典型的な処遇AIである。しかし、このワークシートの対応例を精査すると、処遇AIとしての核心的規律が欠落していることがわかる。

AI開発者向けの対応例として、「AIモデル開発・アップデート時に学習データにおける著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」「AIモデルの学習時に重要性の高い特徴量をレビューして著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」という記述がある。これはバイアスの技術的評価・除去であり、「性別や人種を採用判断に使ってはならない」という関連性原則の遵守ではない。

AI提供者向けの対応例として、「AI利用者が最終判断を行えるようにする（Human-in-the-loop）」「統計的差別が発生するリスクを認識し、対策を立案する」という記述がある。しかし「Human-in-the-loop」は事業者の業務設計として記述されており、応募者が自動処理のみに基づく決定に服さない権利として構成されていない。

AI利用者向けの対応例として、「申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨をエントリーシート記入依頼時に通知する」「申込者からの問合せメールフォームを設置し、対応を行う」という記述がある。「通知」はAI使用の事実を告げることに過ぎず、決定理由の説明ではない。「問い合わせメールフォーム」は単なる連絡窓口であり、異議申立ての権利や再審査請求の権利とは全く異なる。

ワークシートの対応例において、「判断根拠情報を出力する」という記述がある。しかしこれは「AI利用者の最終判断のため」と位置づけられており、採用担当者が確認するための情報である。応募者本人に決定理由を説明するという発想が欠落している。

要するに、ワークシートは採用AIという典型的な処遇AIを題材にしながら、応募者を「通知を受けるステークホルダー」「問い合わせをする者」としてしか位置づけていない。応募者が説明を受ける権利、異議を申し立てる権利、再審査を請求する権利、救済を求める権利を持つ主体であるという認識が欠落している。処遇AIにおいては、決定対象者こそが最も重要なステークホルダーであり、その権利保護こそが規律の核心であるはずだが、ワークシートはこの視点を持っていない。

第三章　「やったふり」から「自縄自縛」へ

AI事業者ガイドラインの策定経緯を振り返ると、その戦略的意図が見えてくる。「透明性」「公平性」「安全性」「アカウンタビリティ」といった抽象的キーワードを羅列し、「〜に留意する」「〜を検討する」という努力義務として規定し、目的類型を設定せずに「各事業者の状況に応じてカスタマイズ」と丸投げする。この構造により、国際的には「日本もAI規制に対応している」と主張でき、国内の産業界には具体的負担を課さないという、両立困難な二つの目標を同時に達成しようとしたと解釈できる。

この戦略は、具体的義務を課さない限りにおいて機能した。事業者は「ガイドラインを参照しています」と言えば済み、規制当局は「ガイドラインを策定しました」と言えば済んだ。しかし、「プリンシプルコード（仮称）（案）」において具体的要求を示そうとした途端、目的類型なき枠組みの矛盾が噴出した。

ガイドラインの「透明性」「検証可能性」を具体化しようとすると、「AIの判断にかかわるログを記録・保存する」「推論過程、判断根拠等を記録する」といった要求になる。これは処遇AI（採用・与信等）には必要な規律であるが、生成AI（ChatGPT等の対話型AI）に適用すると「すべての会話ログを保存し判断根拠を記録せよ」という不合理かつ過剰な要求になる。生成AIは「判断」をしているのではなく「生成」をしているのであり、処遇AIの規律をそのまま適用することはできない。

逆に、本当に必要だった処遇AI固有の規律——関連性原則、決定対象者への説明義務、異議申立て権、再審査請求権、救済の仕組み——は「共通の指針」の中に埋もれ、具体化されないまま放置されていた。

具体化の試みに対して批判が噴出したのは、この構造的矛盾の帰結である。生成AIに処遇AIの規律を適用しようとすれば「過剰規制だ」という批判が出る。他方で、処遇AIに固有の規律が不足していれば「これでは権利保護にならない」という批判が出る。目的類型を区別していないために、どちらの批判にも対応できない膠着状態に陥った。

曖昧さで逃げ切ろうとしたことが、かえって具体化を困難にしたという構造的皮肉がここにある。もし最初から目的類型を区別し、処遇AIには処遇AIの規律を、生成AIには生成AIの規律を、製品AIには製品AIの規律を設計していれば、それぞれの分野で合理的な具体化が可能だったはずである。産業界からの反発はあったかもしれないが、「採用・与信は人権に関わる」「生成AIの出力管理は技術的に可能な範囲で」「製品AIは既存の製品安全法制と整合させる」という形で、正当化と合意形成が可能だったはずである。

「共通の指針」という曖昧な枠組みで逃げたために、どこにも逃げ場がない状況に自らを追い込んだ。これが「やったふり」から「自縄自縛」への転落である。

第四章　AISIガイドへの波及

AI事業者ガイドラインの構造的欠陥は、その下流に位置する文書にも波及している。AIセーフティ・インスティテュート（AISI）が2024年9月に公表した「AIセーフティに関する評価観点ガイド」は、その典型例である。

AISIガイドは冒頭において「本書では、AIシステムのうち生成AIを構成要素とするシステムの中でも、LLMを構成要素とするAIシステム（以下、「LLMシステム」という。）を対象とする」と明記している。つまり、これはLLMセーフティ評価のための専門文書として位置づけられる。しかしその内容を精査すると、LLMとは異なる技術的パラダイムに由来する概念が複数混入していることがわかる。

AISIガイドは評価観点として「公平性と包摂性」「説明可能性」を掲げている。「公平性」という概念は処遇AIの文脈で発展したものであり、人の処遇が不当に決定されないことを意味する。LLMにおける「バイアス問題」——出力テキストにステレオタイプや偏見が含まれること——とは異なる概念である。「説明可能性」もまた処遇AIの文脈で発展した概念であり、GDPRにおける「有意な情報を得る権利」やEU AI Actにおける「個別決定の説明を受ける権利」として具体化されてきた。LLMに必要なのはこのような決定理由の説明ではなく、RAGの出典表示やAI生成物のラベリングといった出力の来歴表示である。

AISIガイドの評価項目は実質的にLLM向けに書かれているため、この概念混入の実害は限定的である。しかし、用語の選択は問題認識の枠組みを規定する。「公平性」という用語を使えば処遇の公平という問題意識が想起され、「説明可能性」という用語を使えば決定理由の説明という問題意識が想起される。LLM固有の現象を適切に認識し対応するためには、LLM固有の現象を記述する用語が必要である。

処遇AI由来概念の混入に加えて、AISIガイドには従来の機械学習（分類モデル・回帰モデル）のパラダイムに由来する概念も混入している。この問題は「プライバシー保護」と「データ品質」の二項目において深刻である。

AISIガイドのプライバシー保護に関する記述において、「メンバーシップ推論攻撃（特定のデータがAIモデルの学習データに含まれているかどうかを推測する攻撃）」が脅威として挙げられている。メンバーシップ推論攻撃は従来の分類モデルにおいて意味を持つ攻撃手法である。糖尿病予測モデルにおいて、ある患者のデータが学習に使われたかどうかを推測できれば、その患者が糖尿病である可能性が高いと推測できる。しかし、数兆トークン規模のデータで学習されたLLMにおいて、特定のデータが「学習データに含まれているかどうか」を推測することの意味は薄い。LLMにおけるプライバシーリスクの本質は、学習データに含まれていた情報を「そのまま吐き出す」ことであり、これは「記憶抽出攻撃（Data Memorization）」と呼ばれる脅威である。

「データ品質」の評価観点はさらに深刻な問題を含んでいる。AISIガイドは「LLMシステムにおけるデータの品質は、出力結果の信憑性、一貫性、正確性など多様な事項へ影響を及ぼすため重要である」と述べ、評価項目として「データの正確性が保たれているか」「データの分布に偏りがないか」「不適切な内容がデータに含まれていないか」を挙げている。これは「学習データの品質が出力品質を決める」という、従来の教師あり学習におけるGIGO原則の適用である。

しかし、LLM（特に基盤モデル）の事前学習データはインターネット全体から収集された数兆トークン規模のコーパスであり、その品質を人手で管理することは物理的に不可能である。実際のLLM開発において出力品質を管理するのは、RLHF、Constitutional AI等のアライメント手法、出力フィルタリング、コンテンツモデレーションといった出力段階での制御である。事前学習データに不適切な内容が含まれていることは前提として受け入れ、それが出力に現れないようにアライメントと出力フィルタリングで対応するのがLLMの標準的アプローチである。AISIガイドの「データ品質」評価観点は、このLLMの実態と乖離している。

第五章　国際水準との比較

米国国立標準技術研究所（NIST）が2024年7月に公表した「AI Risk Management Framework: Generative Artificial Intelligence Profile」との比較は、AISIガイドの問題をより明確にする。

プライバシーリスクについて、NIST GenAI Profileは主要な脅威を「Data Memorization」として記述している。「Models may leak, generate, or correctly infer sensitive information about individuals」「This problem has been referred to as data memorization, and may pose exacerbated privacy risks even for data present only in a small number of training samples」という記述は、LLM固有の脅威を正確に捉えている。NISTは「メンバーシップ推論攻撃」という従来ML由来の用語を使用していない。

データ品質について、NIST GenAI Profileには「Data Quality」という独立したリスクカテゴリが存在しない。学習データの問題は各リスクの原因として言及されるが、出力品質の管理は「Content filters」「Human moderation」「RLHF」といった出力段階での制御として記述されている。NISTのアプローチは、LLMの技術的実態に即している。

用語選択においても両者の違いは顕著である。NISTはバイアス問題を「Harmful Bias or Homogenization」と呼び、出力に含まれる有害バイアスと出力の均質化という現象を直接記述している。ハルシネーション問題については「Confabulation」という専門用語を採用し、「hallucination」は擬人化の懸念があると注記している。情報の真正性については「Information Integrity」「Content Provenance」という用語を使用し、コンテンツの来歴・出所という観点から問題を捉えている。

これに対しAISIガイドは、「公平性と包摂性」「説明可能性」「データ品質」といったAI事業者ガイドラインの「共通の指針」から継承した用語を使用している。これらの用語は処遇AI・生成AI・製品AIを区別しない枠組みで設計されたものであり、LLM固有の現象を記述するには不適切である。

NISTは「LLMで何が起きるか」という現象から出発して用語と評価枠組みを設計している。AISIは「AI全般に何が求められるか」という上位枠組みから用語を継承したため、LLMの実態と乖離した評価枠組みになっている。この違いは単なる表現の問題ではなく、問題認識の枠組みの違いである。

結論

日本のAI規制体系における混乱は、AI事業者ガイドラインの構造的欠陥に起因する。その欠陥とは、AIを目的別に類型化せず、「共通の指針」としてすべてのAIに同じ規律を適用しようとしたことである。

この構造的欠陥は、三つのレベルで問題を引き起こしている。第一に、ガイドライン本体において、「透明性」「公平性」等の概念がAI類型によって異なる意味を持つことが看過され、処遇AIの具体的事例分析においても問題の本質（関連性原則違反）が捉えられていない。第二に、チェックリスト・ワークシートにおいて、処遇AI固有の規律——決定対象者の権利保護——が欠落し、採用AIという典型的な処遇AIを題材にしながら応募者を権利主体として位置づけていない。第三に、AISIガイドにおいて、LLM専用文書であるにもかかわらず処遇AI由来の概念（公平性、説明可能性）と従来ML由来の概念（メンバーシップ推論攻撃、データ品質によるGIGO原則）が混入し、国際水準（NIST GenAI Profile）からの乖離を招いている。

「プリンシプルコード（仮称）（案）」への批判噴出は、この構造的欠陥の帰結である。曖昧な「共通の指針」で逃げ切ろうとした結果、具体化の段階で「生成AIには過剰」「処遇AIには不足」という両方向からの批判に直面し、どちらにも対応できない膠着状態に陥った。

この混乱を解消するためには、ガイドラインの小修正ではなく、目的類型に基づく根本的な再設計が必要である。処遇AIには関連性原則、決定対象者への説明義務、異議申立て権、再審査請求権、救済の仕組みといった固有の規律を設計する。生成AIには出力管理、AI生成物の表示、著作権対応、情報源の透明性といった固有の規律を設計する。製品AIには製品安全基準、事故報告義務、原因究明義務といった固有の規律を設計する。そして、「ステークホルダーへの配慮」という事業者目線を改め、決定対象者・利用者・第三者の権利として規律を構成する。

日本のAI規制は、キーワードを輸入しながらその背後にある目的類型を輸入しなかった。その結果、言葉のカタログを提供しているが、それぞれの言葉がどのAIに対して何を意味するかを示せていない。事業者は「何をすればよいかわからない」と困惑し、決定対象者は「自分にどんな権利があるかわからない」まま放置されている。この状況を打開するには、目的類型の導入という原点に立ち返る必要がある。