生成AIの利用は、すでに多くの企業で当たり前になりました。総務省の令和8年版情報通信白書によると、何らかの業務で生成AIを利用している日本企業は86.4%に達し、前年度調査の55.2%から一年で大きく伸びています。一方で「組織的な取り組みはない」と回答した企業は27.0%を占めます。米国11.7%、ドイツ22.1%、中国7.8%という数字と並べると、日本は「現場では使われているが、会社としてのルールが追いついていない」状態が突出していることがわかります。実は、その社内ルールの拠り所そのものが2026年3月に更新されました。総務省と経済産業省が公表した「AI事業者ガイドライン（第1.2版）」です。AIエージェントが正式に定義され、想定すべきリスクと留意事項が具体的に書き込まれました。本記事では、改訂の要点と、社内規程をどう直すべきかを実務手順に落として整理します。1. 第1.2版で何が変わったのかまずは改訂の全体像を押さえます。第1.2版は既存の内容を書き換えた「別物」ではなく、技術の進展に合わせて記述を足し、曖昧だった言葉を定義し直した「精緻化」の改訂です。だからこそ、既存の社内規程を捨てる必要はなく、差分だけを当てにいく対応が有効になります。1.1. 公表日と位置づけAI事業者ガイドライン（第1.2版）は、2026年3月31日に総務省と経済産業省が公表しました。前版である第1.1版の公表が2025年3月28日ですから、およそ1年ぶりの更新です。構成は従来どおりで、理念と指針を示す「本編」と、実践方法を示す「別添」に分かれています。ここで重要なのは、このガイドラインが法律ではないという点です。日本のAI関連法である「人工知能関連技術の研究開発及び活用の推進に関する法律」（AI推進法）は2025年5月28日に成立し、同年6月4日に公布・施行されました（第3章および第4章は同年9月1日施行）。同法は事業者に対して積極的な活用と国の施策への協力を求めていますが、違反に対する罰則は設けられていません。つまり日本は、罰則で縛るのではなく、指針を示して自主的な取り組みを促す方式を取っています。2025年12月23日には「人工知能基本計画」が閣議決定され、政策の方向性も明確になりました。罰則がないからこそ、有事の際に「何を基準に判断したのか」を説明できるかどうかが企業の防波堤になります。その基準として最も参照されるのが、このガイドラインです。1.2. 実務に効く3つの変更点第1.2版の更新は7つの論点に整理されていますが、社内規程に直接影響するのは次の3点です。第一に、AIエージェントとフィジカルAIの定義・便益・リスク・留意事項が新たに追加されました。第二に、リスクへの向き合い方として「リスクベースアプローチ」が明記されました。第三に、「学習」「推論」「データ」といった用語の定義が整えられ、AI開発者・AI提供者・AI利用者という主体区分の役割分担が具体例で示されました。残る4つの論点は、初心者や小規模事業者でも使えるようにするユーザビリティ改善、国内外のガバナンス動向の反映、取組事例コラムの更新、脚注やリンクの更新です。特にユーザビリティ改善として、2026年3月には「AI事業者ガイドライン活用の手引き」が併せて公表され、総務省からはガイドラインの該当箇所を検索できるチャットボットも提供されています。本編と別添を合わせると相当な分量になるため、まず手引きから入る進め方が現実的です。2. AIエージェントの定義とリスクが明記された意味ここが今回の改訂の核心です。生成AIの「相談相手」としての利用と、AIエージェントの「実行者」としての利用は、リスクの質がまったく違います。第1.2版は、その違いを公的文書として言語化しました。2.1. 「自律的に行動するAI」という線引き第1.2版はAIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAI」と定義しました。あわせてフィジカルAIも、センサーによる物理環境情報の取り込み、AIモデルによる処理、アクチュエータを介した物理的行動という流れで実世界に働きかけるものとして定義されています。なぜ定義が重要なのでしょうか。定義があると、社内規程の適用範囲を切り分けられるようになるからです。たとえば、文章の下書きを依頼するチャット利用と、メール送信や外部システムへの書き込みまで代行するエージェント利用を、同じ「生成AI利用規程」で一括管理するのは無理があります。前者の主なリスクは情報の入力と出力の誤りですが、後者には「意図しない実行」というまったく別のリスクが加わります。便益の面でも、AIエージェントについては複数システムとの連携による調整・分析・意思決定の効率化が新たに挙げられました。別添では、コーディングの自動生成やSNS運用の自律実行、営業トークスクリプトの自動作成、店頭ロボットによる自動接客といった活用場面が示されています。効果が大きいからこそ、線引きが必要になるという構造です。2.2. 追記された6つのリスク第1.2版でAIエージェントやフィジカルAIに関して追記されたリスクは、次のように整理されています。自律的な行動による意図しない動作、攻撃対象と攻撃手法の増加、複雑な機構による制御の困難化、悪意のあるコードの生成、自然言語由来の攻撃、そして内部データの不正な外部送信です。注目したいのは「自然言語由来の攻撃」です。従来のシステム攻撃は、脆弱性を突く技術的な行為でした。しかしエージェントは自然言語の指示で動くため、外部から読み込んだWebページや受信メールの中に紛れ込ませた文章が、そのまま指示として解釈される可能性があります。人が悪意を感じない普通の日本語が攻撃の入口になる、という点が従来と決定的に異なります。もう一つ実務で見落とされやすいのが「内部データの不正な外部送信」です。エージェントに社内ドキュメントへのアクセス権と外部送信の権限を同時に与えると、この二つが結び付いた瞬間に情報流出の経路が完成します。権限を個別に見れば妥当でも、組み合わせで危険になる。だからこそ、権限は機能単位ではなく「経路」で点検する必要があります。2.3. 主体別に示された留意事項第1.2版は、留意事項を主体ごとに書き分けています。ここを読み分けられると、自社が何をすべきかが一気に具体化します。AI開発者に対しては、人間の判断を介在させる仕組みの構築と最小権限の設定が重要である旨が明記されました。あわせて、AIモデルの真正性確認、データ最小化による被害抑止も挙げられています。特に示唆的なのは、大規模言語モデルが提示する根拠は内部ロジックの説明ではなく「もっともらしい理由の出力に過ぎない」と明記された点です。AIの回答に添えられた理由をそのまま監査証跡として扱ってはいけない、という警告になっています。AI提供者に対しては、オープンソースの開発元の信頼性確認、権限設定による意図しない操作の防止、人間の判断を介在させる仕組みの構築、ハードウェアに残存するデータへの配慮、外部システムと連携するツールの制限が挙げられました。SaaSにAI機能を組み込んで提供する事業者は、この項目群が自社の責任範囲にあたります。そしてAI利用者、つまり多くの企業が該当する立場に対しては、定期的な操作履歴の確認と報告、生成されたコードの保守や更新が困難になることへの対応、社内へのノウハウ蓄積、出力が重大な影響をもたらす場合の人間の判断の介在が挙げられています。要するに、導入して終わりではなく「動いた記録を見続ける体制」が利用者側の責務として位置づけられました。3. 社内規程を直す4つの実務ステップここからは具体的な進め方です。ガイドラインは各社の事業内容に応じたカスタマイズを前提としており、そのままテンプレートとして使うものではありません。以下の順番で自社仕様に落とすのが実務的です。3.1. ステップ1：AI利用の棚卸しと主体区分の確認最初に行うのは、社内で稼働しているAIの棚卸しです。部署ごとに、使っているサービス名、対象業務、扱うデータの機微度、外部連携の有無を一覧化します。この時点で想定外のツールが出てくることは珍しくありません。次に、洗い出した用途ごとに自社がどの主体にあたるかを判定します。第1.2版では主体区分の役割が具体例で整理され、ファインチューニングのようなモデルの事後学習はAI開発者の役割、RAGの導入実装はAI提供者の役割として示されました。自社製品にAI機能を載せているなら開発者や提供者としての責務が加わり、単に業務でSaaSを使っているだけなら利用者の責務が中心になります。同じ会社の中でも、部署によって立場が変わる点に注意が必要です。たとえば情報システム部門が社内向けにRAG検索を構築していれば提供者、営業部門がそれを使うだけなら利用者です。この切り分けを飛ばすと、規程が「誰に対する義務なのか」が曖昧になり、結果として誰も守らない文書になります。3.2. ステップ2：エージェントの権限設計と人間の介在点棚卸しが終わったら、AIエージェントを使う業務について権限と介在点を設計します。ここで軸になるのは、第1.2版が繰り返し強調する最小権限の設定と、人間の判断を介在させる仕組みの構築です。具体的には、業務ごとに「AIが単独で完了してよい行為」と「人の承認を必須とする行為」を線で分けます。社内の下書き作成や情報の要約はAI単独でよいとしても、社外へのメール送信、顧客データの更新、費用が発生する処理、権限や設定の変更は承認必須に置く、といった整理です。第1.2版がAI利用者に求める「出力が重大な影響をもたらす場合の人間の判断の介在」を、この線引きで具体化します。権限そのものも絞り込みます。読み取り専用で足りる業務に書き込み権限を渡さない、参照範囲を必要なフォルダやラベルに限定する、外部連携先をあらかじめ許可したサービスに限る、といった設定です。あわせて、AI提供者向けに挙げられた「外部システムと連携するツールの制限」も参考になります。連携できる先が少ないほど、意図しない実行が起きたときの被害範囲は小さくなります。3.3. ステップ3：操作履歴の確認を運用に組み込む設計したルールは、記録を見なければ守られているかどうかがわかりません。第1.2版がAI利用者の留意事項として「定期的な操作履歴の確認・報告」を挙げているのは、この点を突いています。実務としては、確認する対象と頻度、報告先をあらかじめ決めておきます。エージェントが実行した処理のログ、外部送信の履歴、承認をスキップした例外処理、想定外のエラーで停止した件数などが対象です。頻度は月次を基本に、影響が大きい業務は週次で見る運用が現実的でしょう。重要なのは、誰かが気づいたときに見るのではなく、カレンダーに載った定例作業にすることです。このとき、AIが出力した理由の記述を証跡として扱わないよう注意します。前述のとおり第1.2版は、大規模言語モデルの根拠提示が内部ロジックの説明ではないことを明記しました。監査に耐えるのは、システム側が残す実行ログや承認記録です。人が読みやすいAIの説明文と、機械が残す事実の記録は、役割を分けて管理します。3.4. ステップ4：リスクベースで優先順位をつけて規程を改訂する最後に規程本体を改訂します。ここで第1.2版のもう一つの柱、リスクベースアプローチが効いてきます。第1.2版は、リスクの大きさと発生可能性を加味して対策の優先順位を検討する考え方を明記し、参考文献としてEUのAI法などを追加しました。すべてのリスクに同じ強度の対策を当てると、規程は膨らみ、現場は守れなくなります。そこで棚卸しした用途を、影響の大きさと発生可能性で並べ替え、上位から対策を厚くします。社外に出る出力や金銭が動く処理は厳しく、社内限定の下書き用途は軽く。この強弱こそが、実効性のある規程と読まれない規程を分けます。考え方の変化を示す例として、第1.2版では差別的な出力が「技術的リスク」から「倫理・法に関するリスク」へ再分類されました。技術特性だけでは決まらず、法的・倫理的な評価に基づく問題だという整理です。裏を返せば、技術部門だけで抱えるべきリスクではないということでもあります。改訂作業には、法務やコンプライアンス、事業部門を最初から巻き込むべき理由がここにあります。なお、別添にはカスタマイズを前提としたチェックリストとワークシート（別紙7）が用意されています。ガバナンス取組事例のコラムも更新され、新たにIBMとAmazon Web Servicesの事例が追加されました。後者ではAIマネジメントシステムの国際規格であるISO/IEC 42001の認証取得が紹介されており、自社の体制を設計する際の比較材料になります。まとめAI事業者ガイドライン第1.2版が示したのは、AIが「答えるもの」から「実行するもの」へ変わったという事実と、それに伴って企業が持つべき統制の形です。定義が示され、リスクが列挙され、主体ごとの留意事項が具体化された今、社内規程を昨年のまま運用し続ける理由はありません。とはいえ、いきなり完璧な規程を作る必要はありません。まずは自社のAI利用を棚卸しし、AIエージェントを使う業務について「AI単独で完了してよい行為」と「人の承認を必須とする行為」の線を引いてみてください。この一枚があるだけで、権限設計とログ確認の議論は驚くほど具体的になります。判断の拠り所は、公的な一次情報に置くことをおすすめします。総務省と経済産業省のサイトには本編、別添、チェックリスト、そして「活用の手引き」が公開されています。まずは手引きに目を通し、自社が該当する主体の章から読み進める。その一歩が、AIエージェント時代の統制の土台になります。