はじめに
2026年3月31日、総務省・経済産業省から「AI事業者ガイドライン（第1.2版）」が公表されました。
AI事業者ガイドライン（第1.2版）
令和8年3月31日 総務省 経済産業省
— 総務省 公式掲載ページ
前版（v1.1）が出たのは2025年3月。たった1年で改定されたわけですが、この1年で何が起きたかを振り返れば当然の流れです。
- Claude CodeやCursorが「コードを書くAI」から**「自律的にタスクを遂行するAIエージェント」**へ進化
- OpenAI OperatorやDevinが「人間の代わりにブラウザを操作する」世界を実現
- マルチエージェント連携（A2A、MCP）が実用段階に
- litellmへのマルウェア混入など、AIサプライチェーン攻撃が現実に
v1.1の時点では「AIエージェント」はまだ用語の言及レベルでしたが、v1.2では定義・リスク・対策が本格的に書き込まれた。ガイドラインが現実に追いついてきた改定です。
本記事では、v1.2の内容を実務に落とし込む視点で読み解き、**企業のAI活用担当者やエンジニアが「結局何をすればいいのか」**をまとめます。
本記事は技術者・事業担当者向けの解説です。正式な法的解釈については原文をご確認ください。
そもそもAI事業者ガイドラインとは
日本のAI規制は3本柱
| 柱 | 名称 | 性質 | 状況 |
|---|---|---|---|
| 法律 | AI推進法 | 基本法（罰則なし） | 2025年9月施行済み |
| 国家計画 | 人工知能基本計画 | 閣議決定 | 2025年12月決定 |
| ガイドライン | AI事業者ガイドライン | 任意（ソフトロー） | v1.2 公開 |
「ソフトロー＝守らなくてもいい」ではありません。AI推進法に基づき、ガイドラインに沿った取り組みを行わない事業者に対しては行政指導や事業者名の公表がありえます。実質的に「守ること前提」の文書です。
対象となる3つの主体
ガイドラインは以下の3つの立場ごとに遵守事項を定めています。1つの企業が複数の立場を兼ねることもあります。
| 主体 | 例 |
|---|---|
| AI開発者 | モデルやAIシステムを作る企業 |
| AI提供者 | AIをサービスに組み込んで提供する企業 |
| AI利用者 | 業務でAIを使う企業・組織 |
v1.2の重要な変更として、社内でRAGを構築したりファインチューニングをしている企業は、単なる「利用者」ではなく「開発者」としての責任を負う可能性がある、と明確化されました。これについては後述します。
10の共通原則
全主体が遵守すべき原則は以下の10個です。v1.1から変わっていませんが、v1.2ではそれぞれの具体的な内容が大幅に拡充されています。
- 人間中心 — 全原則の基盤
- 安全性
- 公平性
- プライバシー保護
- セキュリティ
- 透明性
- アカウンタビリティ
- 教育・リテラシー
- 公正競争
- イノベーション
v1.1 → v1.2 で何が変わったのか
変更点を整理すると、大きく以下のカテゴリに分けられます。
| カテゴリ | 変更の概要 | 実務インパクト |
|---|---|---|
| 定義の追加 | AIエージェント・フィジカルAI・エージェンティックAIを公式定義 | 高 |
| HITL必須化 | エージェントの外部アクション時に人間の承認を要求 | 極めて高 |
| 責任範囲の拡大 | RAG構築・ファインチューニングで「開発者」責任が発生 | 高 |
| 新リスクの追加 | ハルシネーション誤動作、合成コンテンツ、感情操作、AI過度依存 | 高 |
| リスクベース強化 | 「リスクゼロ」ではなく優先順位付けを明確化 | 中 |
| トレーサビリティ | 監査ログ・委任チェーンの追跡を強化 | 中 |
| 攻めのガバナンス | 制限一辺倒でなくイノベーション促進とのバランス | 中 |
| 活用の手引き | 中小企業向け段階的導入ガイドを新設 | 低〜中 |
以下、特にインパクトの大きいものを掘り下げます。
1. AIエージェントの定義が公式に入った
v1.2で初めて、以下の用語が政府の公式文書に定義されました。
| 用語 | 定義 |
|---|---|
| AIエージェント | 特定の目標を達成するために、環境を感知して自律的に行動するAIシステム |
| フィジカルAI | センサーや駆動系（ロボット等）を通じて現実世界に直接働きかけるAI |
| エージェンティックAI | 複数のAIエージェントが自律的に連携するシステム |
なぜこれが重要なのか
定義が入ったということは、ガバナンスの対象として公式に認識されたということです。
今まで「Claude CodeやCursorでコーディングしている」のは曖昧な領域でしたが、v1.2の定義に照らせばこれは明確に「AIエージェントの利用」です。したがって、v1.2が求めるエージェント関連の安全対策が適用されます。
また「エージェンティックAI」の定義は、LangGraphやCrewAIで組むマルチエージェントワークフロー、A2A（Agent-to-Agent）プロトコルによるエージェント連携が対象になることを意味します。
確認ポイント: 自社でAIエージェント（Claude Code、Cursor、Copilot、カスタムエージェント等）を使っている場合、v1.2のエージェント関連要件の適用対象です。
2. Human-in-the-Loop が「推奨」から「必須」へ
v1.2で最もインパクトの大きい変更です。
v1.1では「人間の関与が望ましい」レベルでしたが、v1.2ではAIエージェントが外部に対してアクションを実行する場合に、具体的な仕組みの構築が求められるようになりました。
v1.2が具体的に求めているのは以下の4点です。
(1) クリティカルな意思決定での人間の承認メカニズム
AIエージェントが「メール送信」「ファイル削除」「購入処理」「本番デプロイ」などの外部アクションを実行する場合、人間が承認するフローを挟む必要があります。
「AIが勝手に発注した」「AIが誤ってデータを削除した」は、もはや「AIだから仕方ない」では済まされません。
(2) 最小権限の原則
AIエージェントに与える権限は必要最小限に制限する。管理者権限をそのまま渡す、全データベースへの書き込み権限を付与するなどは避ける。
(3) 緊急停止メカニズム
AIエージェントが意図しない動作をした場合に、即座に停止できる仕組みを用意しておく。
(4) 継続的モニタリング
「導入して終わり」ではなく、運用中もAIの動作を監視し続けるインフラを整える。
企業が取るべきアクション
- AIエージェントが実行する操作のうち、外部に影響を与えるものを洗い出す
- それぞれの操作に対して、人間の承認が必要かどうかを判断しルール化する
- 承認フロー、ログ記録、異常時のアラート・停止の仕組みを構築する
- 定期的にログをレビューし、想定外の動作がないか確認する
3. 「RAGを組んだら開発者」— 責任範囲の拡大
v1.2で実務的にもう一つ大きいのが、責任の境界線が変わったことです。
以前は「OpenAIやAnthropicのAPIを叩いているだけなら利用者」でした。しかしv1.2では、以下を行う場合に開発者としての責任が発生する可能性があると明記されました。
| 行為 | 従来の立場 | v1.2での立場 |
|---|---|---|
| LLM APIを直接呼ぶだけ | 利用者 | 利用者 |
| 社内データでRAGを構築 | 利用者 | 開発者の可能性 |
| 既存モデルをファインチューニング | 利用者 | 開発者の可能性 |
| AIエージェントに独自ツールを接続 | 利用者 | 開発者の可能性 |
LangChainでRAGパイプラインを組んでいるチーム、MCP Serverを自作してClaude Codeに接続しているチーム — ほぼ全てが対象になりえます。
開発者に求められること
利用者と比べて、開発者には追加の責務が発生します。
- RAGに取り込むデータの品質管理と権利確認
- システムプロンプトの安全設計（間接プロンプトインジェクション対策）
- RAG検索結果に攻撃コードや有害コンテンツが混入しないかの検証
- 開発したAIシステムの性能範囲・限界の明示
確認ポイント: 社内でRAGを運用しているなら、v1.2の「開発者」向け遵守事項を一度確認することをお勧めします。
4. 新たに追加されたリスク — 「AIエージェントならでは」の脅威
v1.2では、従来のセキュリティリスクに加えてAIエージェント時代に特有の4つのリスクが明示されました。
(1) ハルシネーション起因の誤動作
AIがハルシネーション（もっともらしい嘘）を生成するだけなら「人間がチェックすれば済む」話でした。しかしAIエージェントは出力に基づいて自律的に行動するため、ハルシネーションが直接「行動」につながります。
v1.2では具体例として以下が挙げられています：
- 不正な購入の実行 — 存在しない商品やサービスを発注
- ファイルの意図しない削除 — 誤った判断でデータを消去
- 誤った外部通信 — 間違った宛先への情報送信
これは「出力の正確性」の問題ではなく、「自律的行動のリスク管理」の問題です。
(2) 合成コンテンツ・フェイク情報の生成
ディープフェイク動画・音声、偽ニュース記事、捏造されたデータや統計。AIがこれらを容易に生成できるようになった現実を受け、v1.2ではリスクとして明記されました。
(3) AIへの過度依存・フィルターバブル
「AIの回答をそのまま鵜呑みにする」「人間の判断プロセスを省略する」ことで、判断力の低下や思考の均一化が起きるリスクです。
特にAIエージェントが意思決定プロセスに深く組み込まれている場合、「AIが出した結論＝正しい」と無批判に受け入れる組織文化は危険です。
(4) アルゴリズムによる感情操作
AIがユーザーの不安や恐怖を煽って購入を促す、心理的脆弱性を突いて意思決定を歪めるといったリスクです。いわゆる「ダークパターン」のAI版です。
企業が取るべきアクション
| リスク | 対策 |
|---|---|
| ハルシネーション誤動作 | 破壊的操作・外部通信の前に人間の確認フローを挟む。自動実行の範囲を制限 |
| 合成コンテンツ | AI生成コンテンツのラベル付け。生成物の用途・公開範囲の管理 |
| 過度依存 | AIの出力は必ず人間が検証するルールの策定。クリティカルな判断にはダブルチェック |
| 感情操作 | 顧客向けAI出力のトーン・内容のモニタリング。恐怖訴求・緊急性の演出を制限 |
5. 「攻めのガバナンス」という考え方
v1.2の隠れた重要ポイントが「攻めのガバナンス」の導入です。
これまでのAIガバナンスは「何をしてはいけないか」の制限が中心でした。しかしv1.2では、制限だけでは企業のイノベーションを阻害するという認識が明確に示されています。
リスクをゼロにするのではなく、リスクの大きさや発生確率を踏まえて対策の優先順位を決める
つまり：
- リスクが高い操作（データ削除、外部送信、本番変更）→ 厳格に管理
- リスクが低い操作（情報検索、コード補完、要約生成）→ 過度な制限を避ける
- 組織のリスク許容度に応じて段階的にガバナンスを整備
「全部禁止」でも「全部放任」でもなく、リスクに応じたグラデーションで管理する。これが「攻めのガバナンス」です。
6. トレーサビリティの強化 — 「何が起きたか追跡できる状態」の維持
v1.2ではトレーサビリティ（追跡可能性）の重要性がより強調されました。
具体的に求められているのは：
- データパイプライン全体を通じた来歴追跡
- インシデント発生時の調査に耐えうる記録の保持
- エージェント間の委任関係の追跡（マルチエージェント環境）
「AIが何をしたか」を事後的に再現・説明できる状態を、運用前から設計しておく必要があります。
最低限記録すべきもの
| 項目 | 例 |
|---|---|
| いつ | タイムスタンプ（ISO 8601） |
| 誰が | ユーザーID、エージェントID |
| 何を | ツール名、操作対象、入力内容 |
| 結果 | 成功/失敗/ブロック、リスク判定 |
| なぜ | 適用されたポリシー、マッチしたルール |
7. 中小企業向け「活用の手引き」の新設
v1.2に合わせて、ガイドラインに初めて取り組む企業・中小企業向けの「活用の手引き」が新たに作成されました。
ガイドラインの本文は300ページ超の大部な文書ですが、活用の手引きではエッセンスが凝縮されています。AI活用を始めたばかりの組織は、まずここから入るのがよいでしょう。
まとめ — 企業が今すぐ始めるべき7つのアクション
v1.2の内容を踏まえて、企業が取るべきアクションをまとめます。
1. 自社の立場を再確認する
自社が「開発者」「提供者」「利用者」のどれに該当するか棚卸し。特にRAGやファインチューニングをしている場合は開発者責任の有無を確認。
2. AIエージェントの利用状況を把握する
Claude Code、Cursor、Copilotから社内カスタムエージェントまで、AIエージェントがどこで何をしているかを可視化。
3. Human-in-the-Loopの設計
外部アクション（送信・削除・購入・デプロイ等）を実行するエージェントに対して、人間の承認フローを構築。
4. 最小権限の原則を適用
エージェントに管理者権限を渡さない。操作範囲をポリシーで明示的に制限。
5. 監査ログ基盤の整備
全てのエージェント操作を記録し、事後的に追跡可能にする。「何が起きたかわからない」をなくす。
6. 新リスクへの対策
ハルシネーション起因の誤動作、合成コンテンツ、過度依存、感情操作 — v1.2で追加された4つのリスクを自社のリスクアセスメントに組み込む。
7. 段階的に始める
「攻めのガバナンス」の考え方に則り、全部を一気にやろうとしない。リスクの高い領域から段階的に対策を実装していく。
技術的な実装をどう進めるか
ここまで「何をすべきか」を整理しましたが、実際にエンジニアリングチームが実装するとなると、以下のような課題に直面します。
- エージェントの全操作をどうログに残すか
- 入出力スキャンのパターンをどう管理するか
- ポリシーベースの操作制御をどう実装するか
- v1.2の37要件に対するカバレッジをどう証明するか
こうした技術的な実装基盤として、筆者はOSSのLLMセキュリティライブラリ ai-guardian を開発しています。
ai-guardian でできること
| v1.2 の要件 | ai-guardian の対応 |
|---|---|
| Human-in-the-Loop | レビューキューと承認フロー |
| 最小権限の原則 | YAMLポリシーによる操作制御（allow/deny/review） |
| 監査ログ | 全操作の自動記録（JSONL） |
| 入出力スキャン | 96+検知パターン（日英対応） |
| 新リスク検知 | ハルシネーション誤動作・合成コンテンツ・感情操作・過度依存パターン |
| コンプライアンス証明 | v1.2全37要件のマッピングレポート自動生成 |
pip install aig-guardian
aig init
aig report # v1.2 全37要件の対応状況をレポート出力
ゼロ依存（Python標準ライブラリのみ）で、FastAPI / LangChain / LangGraph / OpenAI / Anthropic にドロップイン統合できます。詳細は以下をご覧ください。
参考資料
v1.2 原文・公式資料:
解説記事:
- Uravation — AI事業者ガイドラインv1.2を解説
- Zenn — AI事業者ガイドライン第1.2版のポイント
- 法務ノート — 第1.2版のポイントと第1.1版からの変更点
- Innovatopia — AIエージェント・フィジカルAI時代の攻めのガバナンス
関連: