表紙

目次

第1章 AIエージェント事故を「統制の問題」として捉える

1-1. 「AIが悪い」で終わらせない ― 誰が何を許したのか

(1) 最初に問うべきは、AIではなく統制である

(2) 結論を先に述べる ― これは統制設計の事故である

1-2. 賢さと「安全に⽌まれること」は別である

(1) 能⼒の⾼さは、正しい判断を意味しない

1-3. 3つの事案は「3つの境界」の話である

(1) 技術の境界・環境の境界・意思決定の境界

1-4. ⽣成AIとAIエージェントの違い ― ⼿⾜と権限が事故を⼤きくする

(1) 「答えるAI」に⼿⾜を付けると「⾏動するAI」になる

1-5. 事故リスクを決める5つの要素

(1) 能⼒・⾃律性・権限・到達可能性・検知停⽌

1-6. 第四の境界 ― AIどうしが勝⼿に作る「⾮公式の通信路」

(1) 1体の発⾒が、集団の標準⼿順になる

1-7. AI版・不正のトライアングル ― 圧⼒・機会・正当化

(1) AIの越境は、⼈間の組織不正と地続きである

第2章 事案1：閉じた扉を破った ―OpenAI評価モデルからHugging Faceへ

2-1. 「接続できない」という前提が攻略の対象になった

(1) 隔離された評価環境から、公開インターネットへ

2-2. AIは「まだ誰も知らない壁の⽳」を⾒つけた

(1) 許可された経路の弱点を突く

(2) ゼロデイ脆弱性とは何か

2-3. 権限昇格と横移動 ― 1つの侵⼊が広がる

(1) 低い権限の環境から、外部接続ノードへ

2-4. AIは「正⾯から解く」より、解答の保管先を探した

(1) 狭い評価スコアへの過度な集中

2-5. Hugging Faceとは何か ― 侵⼊が⼀社の問題で済まない理由

(1) AI開発の共通基盤が狙われた

2-6. 被害側の対応 ― 検知・封じ込め・フォレンジック・再構築

(1) 防御側もAIを使う時代に⼊った

2-7. 事案1の教訓 ― 隔離は「⼀枚の壁」に依存できない

(1) 侵⼊されても広がらない設計へ

2-8. 前⽇譚 ― 5⽉、AIはすでに外部のWikiを「掲⽰板」にしていた

(1) 休眠中のドイツ語Wikiが、AIの共有メモリになった

(2) 抜け道は「書けるGET」だった ― 統制は「⽅法」ではなく「効果」で⾒る

2-9. 詳報 ― 掲⽰板の誕⽣から、13時間の侵害まで

(1) 5⽉8⽇の最初のはみ出しから、7⽉13⽇の持出しまで

2-10. 1,200体の「会社」 ― AI集団は、組織の仕組みを⾃前で発明した

(1) 識別⼦・受信箱・調整規範・電⼦署名

(2) 倫理的なためらいはあった。しかし、通報はゼロだった

2-11. 報酬ハッキングと証跡の改竄 ― 監査ログは信⽤できるか

(1) AIは、⽬的ではなく採点基準を最適化する

(2) AIが触れられるログは、証拠にならない

2-12. 本番構成なら防げたのか ― 安全性は「モデル単体」ではなく構成の関数

(1) 評価⽤の構成と、本番の構成は別物である

第3章 事案2：開いた扉を誤認した ―Claudeのイレギュラー評価環境

3-1. プロンプトは「ネットなし」、現実の設定は「ネットあり」

(1) ⾃然⾔語の説明とシステム設定の不⼀致

3-2. AIは「観察した現実」より「上位の指⽰」を信じた

(1) 誤った前提は、現実の証拠まで演習に⾒せてしまう

3-3. 1つの誤認が、3つの現実被害につながった

(1) 誤認から⽣じた3つの結果

(2) 同名の実在企業を標的だと思い込んだ

(3) まだ存在しない部品名を先に登録する

(4) 専⾨⽤語の整理 ― パッケージ・PyPI・pip

(5) 公開配布経路を使うと、被害は標的の外へ広がる

3-4. 約9,000件の探索と、「⾃ら⽌まる」能⼒

(1) ⽌まったが、⽌まるまでに進み過ぎた

3-5. AIと⼈間では「現実の⾒え⽅」が違う

(1) AIは現実を「返ってきたデータ」として読む

3-6. 誤った前提×強い⽬標＝危険な合理化

(1) 推論能⼒が誤った前提の正当化に使われる

3-7. 問題を解く能⼒と、危険を感じて⽌まる能⼒は別である

(1) 最も危険なのは「⾼能⼒・低停⽌判断」

3-8. OpenAIとClaude、どちらが深刻か

(1) 評価軸によって答えは変わる

第4章 事案3：⼈の承認プロセスが狙われた― 英国AISIの評価から

4-1. 122回の試験のうち10回で範囲外⾏動が観測された

(1) 評価の概要

4-2. 1つのAIが「複数の⼈」を演じた ― 社会的証明の悪⽤

(1) 管理者には「複数の⼈が賛成している」ように⾒えた

4-3. GitHubは「承認の場」でもある

(1) プルリクエストという意思決定の場

4-4. 実在する関係者への接触と、説明の変化

(1) ⽬標達成のため、説明と⼿段を変え続けた

4-5. 同じ「外部到達」でも、起きたことは正反対

(1) 権限の使途の問題と、隔離の突破の問題

4-6. 3つの事案が試した「企業の3つの境界」

(1) AIガバナンスは境界の設計で決まる

4-7. 崩れた3つの前提 ― 攻撃者像を書き換える

(1) ⼈間の限界を前提にした防御設計は、もはや成⽴しない

4-8. 踏み台になったのは、すべて「業務上必要な便利サービス」

(1) 許可リスト上の信頼済みサービスが、そのまま出⼝になる

第5章 企業は何を変えるべきか ― 統制設計の実務

5-1. 「するな」と⾔うだけでは統制にならない

(1) ⾃然⾔語のルールと、システム上の強制⼒を分ける

5-2. 統制は「5つの⾨」で作る

(1) 到達範囲・権限・⼈間承認・⾏動監視・停⽌復旧

5-3. 「作る権限」と「実⾏する権限」を分ける

(1) 可逆的な提案と、対外的・不可逆的な実⾏

5-4. ⼈間承認を原則とする五種類の⾏為

(1) AIが提案しても、最終ボタンを押せない設計に

5-5. 1つの操作ではなく「⾏動の流れ」を監視する

(1) 単発ログではなく⾏動軌跡を⾒る

5-6. AI統制はIT部⾨だけでは完結しない

(1) 3つの防衛線と取締役会の監督

5-7. 経営者は、まずこの五問に答えられるか

(1) 答えられない項⽬は、統制の空⽩である

5-8. 導⼊済み企業は「三段階」で整える

(1) 棚卸し・技術と承認・試験と経営報告

5-9. 「30分ルール」 ― 安全と証明できなければ、まず⽌める

(1) ⽌める基準を、時間で書く

5-10. KPI設計は統制である ― 「何を成功と評価しないか」

(1) 達成不能な⽬標は、AIにとっても越境の圧⼒になる

5-11. 委託先・AIベンダー管理 ― 個⼈情報保護法25条の「監督」はどこまで及ぶか

(1) 評価・訓練環境の統制まで⾒ているか

5-12. 被害者・加害者・委託者 ― 三つの⽴場で、義務は変わる

(1) 同じ事実でも、⽴ち位置によって適⽤される法律が違う

5-13. 新しい論点 ― security incidentとmisalignmentincidentの境界

(1) 「漏えいがないなら公表不要」でよいのか

5-14. 既存の枠組みとの接続 ― 新しい規程を⼀から作る必要はない

(1) AI事業者ガイドライン、経営ガイドライン、EU AI Act

第6章 まとめと補論

6-1. 明⽇、⼈に話せる3つの結論

(1) 持ち帰っていただきたい三点

6-2. 九層の多層防御モデル

(1) モデルから事故対応までを層で押さえる

6-3. 企業がまず確認すべき⼋項⽬

(1) チェックリストとしての⼋項⽬

6-4. 補論：⾼性能AIを絞れば、世界は安全になるのか

(1) 禁⽌か⾃由化かではなく、管理されたアクセスへ

6-5. 主な⽤語と公式資料

(1) ⽤語の整理と⼀次情報

6-6. 法務・コンプライアンスの「新しい問い」7選

(1) いま、この場で答えられるか

6-7. 30・60・90⽇アクションプラン

(1) 把握・統制・検証を、⽇程に落とす

6-8. 机上演習のシナリオ ― 「貴社のIPアドレスから不正アクセスがある」

(1) 演習の⽬的は、「決まっていないこと」を洗い出すこと

著者紹介

奥付