EU AI Act高リスク規制目前、AIエージェントの統治設計

Gartnerは2025年8月のプレスリリースで、「2026年末までに企業アプリケーションの40%がタスク特化型AIエージェントを組み込む」と予測しました。

前年の2025年時点では5%未満だったとされる数字です。

一方でGartnerは同時期のプレスリリースで、「2027年末までに、エージェント型AIプロジェクトの40%以上が中止される」とも予測しています。

導入は急拡大し、同じくらいの割合で失敗も見込まれている——これが2026年半ばのAIエージェントを取り巻く実際の空気感です。

この記事では、なぜ「作ること」自体はもう難所ではなくなり、「どう統治するか」が新しい難所になっているのかを、私たち自身の自動化運用の視点から整理します。

規制が「努力目標」から「期限」に変わる

象徴的なのが、EU AI Actの高リスクAIシステムに関する規定です。

信用スコアリング、採用選考、保険の引受判断など特定用途のAIシステムは「高リスク」に分類され、2026年8月2日にその義務規定が本格適用される見通しとされています（2026年7月時点の情報。EU側で適用時期の一部見直し協議が進んでおり、最終的な適用範囲・時期は変更される可能性があります）。

対象となる事業者には、適合性評価の実施、人による監視体制の確保、ログの一定期間（6か月以上）の保存、影響評価の実施などが求められるとされています。

こうした規定はEU域内の話に見えますが、実務上はグローバルに展開するサービスの設計基準に波及しやすいものです。

「動くAIエージェントを作れるか」はここ数年でかなりの企業がクリアしました。

これからの数か月で問われるのは、「そのAIエージェントが何をしたか説明できるか」「誰が何をどこまで任されているか統制できているか」という、もう一段上の設計です。

インフラ側も「統治」を前提に動き始めた

この変化は、AIエージェントを提供する側の動きにも表れています。

Anthropicは2026年6月29日、Claude Codeを組織導入する際の管理基盤として「Claude apps gateway」を発表しました。

これは、開発者ごとの認証情報を配布する代わりに、企業のシングルサインオンと連携し、利用者・グループ・組織単位でロールベースのアクセス権限と支出上限を一元的に設定できる、自社ホスト型の管理レイヤーです。

利用状況の追跡や支出上限の設定が、個別のAPIキー管理ではなく仕組みとして提供されるようになった、という点が重要です。

私たちの理解では、これは「AIエージェントに何を任せるか」という話が、個々の利用者の裁量から、組織としてのポリシー設計の話に移ってきたことの表れです。

つまり、統治の単位が「人」から「仕組み」に移り始めています。

私たちが自動化運用で置いている前提

私たちは、日々の自動化運用（ブログ生成パイプラインや日英コンテンツ制作など）を、Claude Codeを中核に自社で構築・運用しています。

そこで最初から前提にしているのは、「説明できない自動化は止められない」という考え方です。

自動化がなぜその出力を出したのか、どの工程を経てきたのかを追えなければ、問題が起きたときに何を直せばいいのかも分かりません。

この前提から、私たちは次のような設計を基本にしています。

• 生成物は必ず検出→修正→再検証の2パスを経てから次の工程に進める
• 無人運用であっても、出力は下書きとして残し、公開判断は人が最後に行う（ヒューマン・イン・ザ・ループ）
• 各工程の判断(何を採用し、何を見送ったか)を、ログや記録として残す

これは規制対応のために組んだものではありません。

自分たちの自動化を安心して任せられる状態にするための、素朴な設計原則です。

ただ結果として、これはEU AI Actが求める「人による監視」「ログの保存」といった要件と、方向性としてかなり近いものになっています。

規制の詳細をそのまま読み込む前に、自分たちの自動化がそもそも「何をしたか説明できる」状態になっているかを確認しておくと、規制対応の負担そのものが軽くなる、というのが実感です。

導入前に見ておきたい実務ポイント

規制の是非にかかわらず、AIエージェントを業務に組み込む際に確認しておくと後で楽になる点を、いくつか具体的に挙げます。

「誰が」「どこまで」を先に決める

AIエージェントに与える権限を、個人の裁量ではなく役割(ロール)単位で設計する。

同じ業務でも、下ごしらえ的な作業と、対外的に公開する判断とでは、任せてよい範囲がまったく違います。

権限設計を後回しにすると、後から「誰が何を許可したのか分からない」状態になりやすく、そこが最初につまずくポイントです。

ログは「トラブル対応用」ではなく「説明責任用」として設計する

障害調査のためだけにログを残すのではなく、「なぜこの出力になったか」を第三者に説明できる粒度で記録しておく。

生成AIの出力は再現性が完全ではないため、事後に「その時何が入力され、どの工程を経たか」を追える記録がないと、説明そのものが成立しません。

「止められる」設計を先に作ってから広げる

権限やログの整備より先に自動化の範囲だけを広げると、問題が起きたときに戻す手順がなく、影響が大きくなります。

私たちは新しい自動化を組み込むとき、先に「異常時にどう止めるか・どう戻すか」を決めてから、対象範囲を広げるようにしています。

規制は最終期限ではなく、設計を見直すきっかけとして使う

EU AI Actのような規制は、対象事業者にとっては期限つきの義務ですが、対象外の企業にとっても「他社がどこまで統治を作り込んでいるか」の参考になります。

規制が定める最低ラインを、そのまま自社の目標にする必要はありません。

むしろ、規制が要求する水準を手がかりに、自分たちの自動化がどこまで説明可能か棚卸しする機会として使うのが実務的だと考えています。

よくある誤解

「AIエージェント導入は今からでは遅い」——そうは思いません。

Gartnerの予測が示す40%という数字は、裏を返せば半分以上の企業はまだこれからだということでもあります。

また同じGartnerが「導入プロジェクトの4割以上が中止される」とも予測しているとおり、早く始めた企業のすべてがうまくいっているわけでもありません。

急いで範囲を広げること自体に価値はなく、任せる範囲と統治の設計が伴っていることのほうが重要です。

「統治の仕組みを整えると、AIエージェントの良さである速さが失われる」——これも半分だけ正しい誤解だと考えています。

権限設計やログ整備は、たしかに初期の手間を増やします。

ただ、その手間は「何かあったときに素早く原因を特定し、戻せる」という別の速さに変わります。

私たちの実感では、統治の設計がないまま広げた自動化のほうが、後になって「何が起きているか分からず止められない」形で速度を失いやすいと考えています。

「規制対応は法務やコンプライアンス部門の仕事」——技術を実装する側にとっても他人事ではありません。

権限設計・ログ設計・停止手順は、実装段階で組み込んでおかないと後から足すのが難しい部分です。

法務が求める水準を、実装の初期段階から意識しておくほうが、結果的に手戻りは少なくなります。

まとめ

2026年後半のAIエージェントを取り巻く変化を一言でまとめると、「作れるか」から「統治できるか」への重心移動です。

EU AI Actのような規制の期限、インフラ側が用意し始めた管理基盤、どちらも同じ方向を指しています。

私たちが自社の自動化運用で置いている「検出→修正→再検証」「ヒューマン・イン・ザ・ループ」「止められる設計」という前提は、もともと規制対応のために作ったものではありません。

ただ、規制や業界標準が追いついてきたことで、こうした地味な設計原則の価値が、あらためて裏付けられつつあると感じています。

AIエージェントを広げる前に、まず「今動いている自動化について、何を、どこまで、なぜ任せているかを説明できるか」を確認してみることを、実務上のはじめの一歩としておすすめします。

※ 本記事の規制・統計に関する記述は2026年7月時点で確認できた情報に基づきます。

EU AI Actの適用範囲・時期は今後の制度上の見直しにより変更される可能性があります。

導入判断にあたっては、最新の公式情報・専門家の助言をご確認ください。