はじめに：2026年、AIの「使い方」だけを追いかけていないか

2026年に入り、AIの主戦場は「エージェント」に移りました。

AIが"答える存在"から、"実行する存在"へ変わりつつあります。象徴的なのは、ファイルやブラウザを自律的に操作してタスクを完了させる機能が、各社から次々に出てきたことです。AnthropicのClaude Cowork、OpenAIのOperator——いずれも「対話」ではなく「実行」を前提にした設計です。

YouTubeやSNSでは「AI Agentの使い方」「プロンプト術」「業務効率化」があふれています。それは有益です。しかし、ガバナンス・セキュリティ・プライバシーの実務に携わる立場から見ると、語られていない領域がかなり大きい。

本記事では、「動かす」だけでなく「安全に使う（統制する）」ために何を考えるべきかを、複数の専門領域を横断する視点から整理します。

1. 「答えるAI」と「実行するAI」は、リスクの構造が根本的に違う

従来の対話型AIは、基本的に「情報を返す」存在でした。誤った情報を返しても、それを判断して行動するのは人間です。

AI Agentは違います。ファイルを読み書きし、APIを叩き、ブラウザを操作し、場合によっては別のAIエージェントに指示を出す。判断と実行が近接している——ここがリスク構造の根本的な転換点です。

攻撃面（Attack Surface）の拡大。 プロンプトインジェクションの影響が「おかしな回答」ではなく「ファイル削除・データ流出」といった実害に近づきます。Webページや文書に埋め込まれた隠し指示がエージェントの行動を乗っ取る——これはすでに実証されている攻撃パターンです。OWASP Top 10 for LLMsではプロンプトインジェクションが最上位に位置づけられていますが、エージェントの文脈ではその影響範囲が「回答の汚染」から「実行の乗っ取り」に拡大します。MITRE ATLASが体系化しているAIシステム固有の攻撃手法——データポイズニング、モデル窃取、推論操作なども、エージェントが外部ツールやAPIと接続する分だけ現実的な脅威になります。

権限（Identity）の問題。 AI Agentは「誰として」行動しているのか。多くの場面で、エージェントは人間ユーザーの権限を借りて動いています。そのエージェントが自律的に別のエージェントを起動したとき、権限の連鎖は追跡可能なのか。ここを設計していない組織は非常に多い。

速度の問題。 人間のオペレーションミスは数時間から数日のスパンで顕在化します。AIエージェントの誤動作は、数分で大量のデータを処理してしまいます。検知して止める時間が、従来の前提では足りません。

2. ガバナンスの議論が追いつきにくい理由

AI Agentは、既存のガバナンス体系の"隙間"に入りやすい存在です。

従来のセキュリティ管理は「人間のユーザー」と「決定論的に動くプログラム」を前提に設計されてきました。

AI Agentは、人間のように判断し、プログラムのように速く動き、しかも非決定的（同じ入力でも出力が揺れる）です。IAM（Identity and Access Management）もGRC（Governance, Risk, Compliance）も、このような「第三の存在」を正面から想定していません。

この問題意識は国際的にも前面化しています。2026年2月に公表された「International AI Safety Report 2026」では、汎用AIの能力とリスク、特にエージェントの自律的動作がもたらすリスクが主要テーマとして整理されています。シンガポールIMDAが「Agentic AI」に関するガバナンス枠組みを2026年1月に公表し、キルスイッチ（強制停止）や目的拘束（purpose binding）といった技術的統制を明示したことも、同じ方向性です。

しかし、フレームワークが出ることと、現場の統制が回ることは別の話です。これはセキュリティだけの問題でも、プライバシーだけの問題でも、AI倫理だけの問題でもありません。複数の領域を横断して俯瞰しなければ、運用設計として成立しない——そういう種類の問題です。

3. 開発者がガバナンス側に来たからこそ分かること

私のキャリアは、もともとソフトウェア開発から始まっています。20年以上、認証基盤や決済システムといったミッションクリティカルな領域でコードを書き、設計し、運用してきました。その後セキュリティ、プライバシー、AIガバナンスへと軸足を移しましたが、移ったからこそ痛感していることがあります。

「作ったことがない人間が書くガバナンスは、現場で回らない」ということです。

これは従来のセキュリティ領域でも同じでした。

開発プロセスを知らない人間がセキュリティポリシーを書くと、現場は形骸化した運用で"やってる風"にするしかなくなる。

逆に、開発の経験があれば「ここに穴が開く」「この設計だと運用で破綻する」が肌感覚で分かるし実際の攻撃も行える。（もちろん法の範囲で）

つまり机上の空論になりがちなケースが多いので、実際作る。と言うのが私のスタイルです。

AI Agentの世界でも、まったく同じ構造が再現されています。だから私は、既製エージェントを評価して使うだけでなく、ローカル環境でマルチエージェントシステムを自分で設計・構築することを続けています。

具体的には、LangGraphを用いたグラフベースのワークフローで、複数のAIノード——生成・批判・統合・保存といった役割を分離したパイプラインを動かしています。

さらにオープンソースLLMにLoRA（Low-Rank Adaptation）を適用し、特定の判断パターンや出力形式を再現する専用モデルを育てています。夜間に自律的に回す設計です。

やってみると、フレームワークの解説書には載っていないことが次々に見えてきます。ノード間の情報の受け渡しでスキーマが崩れる。UIが参照するログ形式とエージェント本体の保存形式が噛み合わない。こうした「泥臭い現実」は、作った人間にしか見えません。

もう一つの論点はデータ主権（Data Sovereignty）と監査可能性です。ローカルで動くエージェントは業務データをクラウドLLMベンダーに送信しません。

入力→推論→出力→実行の全プロセスのログを自分の管理下に保持し、後から第三者が検証できる形で記録できます。クラウドとローカルをリスクと用途に応じてハイブリッドに設計する

——その判断軸は、両方を触った経験からしか出てきません。

4. 「出力」と「判断」を分離する習慣

AI Agentを「放置して回す」こと自体が目的ではありません。目的は、人間の判断を、次の生成に反映できる形で蓄積することです。

私自身がAIの出力を扱う際に重視しているのは、以下の3層への明示的な分解です。

• Facts（事実）：入力データに基づく確認済みの情報

• Inferences（推測）：モデルによる推論。根拠と確度を必ず付記

• Open Questions（未確定論点）：追加の確認や人間の判断が必要な事項

この形式に寄せると、レビュー可能になり、"それっぽい文章"が混入しにくくなります。そして人間のフィードバック——どこが誤りで、どこが妥当か——を次のサイクルに反映しやすくなります。

これはISO/IEC 42001やNIST AI RMFの文脈でも「AIの出力に対する適切な理解と管理」として求められている方向性ですが、実務レベルでどう実装するかは、まだほとんどの組織で設計されていません。

5. 横断しなければ設計できない時代

AI Agent時代の問題は、単一領域の専門家だけでは解けません。

エージェントの権限設計にはIAMの知識が要る。データの流れを追うにはプライバシーエンジニアリングが要る。出力の信頼性を評価するにはAIリスク管理が要る。そしてそもそも、エージェントがどう動いているかを理解するにはコードが読めなければ話にならない。

セキュリティ、プライバシー、AIガバナンス、そして開発。この4つのどれか1つだけでは、現場で回る統制設計にならない。逆に言えば、これらを横断できる人間が「何がどう壊れるか」を見ながら設計を組めれば、組織はAIを止めずに済みます。

自分で作り、壊し、直した経験に基づいて統制を設計する——これが、フレームワークの解説やツールの使い方紹介とは異なる、私のアプローチです。

おわりに：「使えること」と「統制できること」の両立へ

AI Agentは確実に業務の形を変えていきます。止める話ではありません。

ただ「使える」だけを追うと、統制の死角が積み上がります。いま導入しているAI Agentは、誰の権限で動いていて、どのデータにアクセスし、どのログが残り、誰が最終責任を持つのか

——この問いに答えられる構造があるからこそ、AIを安心して加速できます。

革新と安全性はトレードオフではありません。

CYBER-SECUREでは、セキュリティ・プライバシー・AIガバナンスを横断し、「作る側の視点」を持った統合的なコンサルティングを提供しています。AI Agentの導入・統制設計・リスク評価でお困りの際は、お気軽にお問い合わせください。

本記事は2026年2月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。