>
>
公開日
最終更新日
チャット型のシャドーAIに代わり、API呼び出し、データベース更新、ファイル操作まで自律的に進める「野良AIエージェント」が新たな管理対象になっています。従業員が未承認のAIへ文章を入力するだけだった段階と異なり、エージェントの誤動作はデータ変更や外部送信、トークン費用の増大に直結します。
Databricksが発表したOmniGentは、異なるAIエージェントを組み合わせ、共通ポリシーで制御・共有するオープンソースのメタハーネスです。本記事では、OmniGentのアーキテクチャ、AIエージェントガバナンス、FinOps、隔離実行、認証、監査の設計を整理します。記載内容はDatabricksの公開ブログ・公式GitHubリポジトリ・各種調査レポートをもとにした情報整理であり、筆者による実環境での動作検証を経たものではありません。製品仕様の詳細は公式リポジトリの最新リリースノートで確認してください。全面禁止に頼らず、利用状況を把握して安全な公式経路へ集約したい情シス、セキュリティ、DX推進担当者が主な対象です。
Omnigentとは？複数AIエージェントを統合するOSS
Databricks Omnigentとは、複数のAIエージェントを共通レイヤーから扱い、セッション共有、ポリシー、サンドボックス、チーム協働を提供するオープンソースのメタハーネスです。
本記事のポイント
確認済み：Databricksは、OmnigentをClaude Code、Codex、Cursor、Pi、自作エージェントを共通レイヤーで扱うベータ版のメタハーネスとして案内しています。
確認済み：Databricksの管理サービスでは、ワークスペースID、Unity AI Gateway、MLflow Tracing、Databricks Sandboxとの統合が案内されています。
設計例：人間承認、最小権限、短命な非人間ID、隔離実行、監査証跡、費用上限は、Omnigent単体の標準機能として一括で断定せず、周辺基盤を含めた運用設計として扱います。
設計例：OmnigentとAdminaは直接統合が確認された一体型製品ではなく、実行制御とSaaS管理を分担する補完的な構成として検討します。
Omnigentの定義と対象範囲
Omnigentの中心的な役割は、異なるエージェントハーネスを切り替えまたは組み合わせ、セッション、ツール、プロンプト、スキル、ポリシーを横断的に扱うことです。
Databricksは2026年6月17日、Omnigentをベータ版のコーディングエージェント用メタハーネスとして公開しました。Databricksの公式ドキュメントでは、Claude Code、Codex、Cursor、Pi、自作エージェントを共通レイヤーで扱い、ハーネスやモデルを切り替えてもツール、プロンプト、スキル、ポリシーを維持する構成が説明されています。公式表記は「Omnigent」です。本記事でも、引用箇所を除き「Omnigent」に統一します。公式情報はOmnigent on DatabricksおよびOmnigent公式リポジトリで確認できます。
従来のシャドーAIは、従業員が管理外の生成AIサービスに文章やファイルを入力する問題が中心でした。野良AIエージェントは、認証情報を使って業務システムへ接続し、検索、更新、送信、コード実行を連続して行います。そのため、管理対象はSaaS契約の有無だけでは足りません。「誰が導入したか」に加え、「どのIDで動くか」「どのツールを呼べるか」「どのデータを書き換えられるか」「停止手段があるか」まで台帳化します。
情シスとセキュリティ部門の対象業務
Omnigentの検討対象は、複数のコーディングエージェントや業務エージェントが部門ごとに動き、個別監視だけでは統制しにくい組織です。
一つのエージェントしか使わず、外部システムへの書き込みも認証情報の利用もない検証環境では、メタハーネスを先に導入すると管理対象が増える場合があります。一方、Claude Code、Codex、Cursor、自作スクリプト、ワークフロー型エージェントなどが併存し、同じデータやAPIを利用している場合は、共通ポリシーと共通ログを置く設計を比較対象に含めます。
導入判断では、エージェント数だけを基準にしません。外部送信、個人情報へのアクセス、データ更新、クラウド資源の作成、従量課金APIの利用のいずれかがある場合は、少数でも統制対象に含めます。読み取り専用で匿名化データだけを扱う場合は限定検証へ進み、削除や外部公開を行う場合は、人間承認と停止手段を実証できるまで本番接続を保留します。
製品名の正しい表記
Databricksの公式ドキュメント、リリースノート、公式GitHubリポジトリでは「Omnigent」が使われています。記事内の正式名称、台帳、設計書、検索キーワードは「Omnigent」に統一します。
OmniAgent、Ominigent、Omnigen、OmniGentは検索時に生じ得る類似表記ですが、本記事が扱うOSSおよびDatabricksのベータ版サービスはOmnigentです。画像生成モデルなどで使われるOmniGenとも区別します。社内台帳、設計書、リポジトリ名で正式表記を用いれば、脆弱性情報、リリースノート、更新履歴の取り違えを抑えられます。
メタハーネスの構造と既存エージェント基盤との違い
メタハーネスとは、個別のエージェントハーネスを包み込み、セッション、実行環境、アクセス制御、ポリシーを共通化する上位レイヤーです。
エージェントハーネスとメタハーネスの境界
エージェントハーネスが一つのエージェントの推論とツール実行を支えるのに対し、メタハーネスは複数ハーネス間の切り替え、共有、統制を担います。
LangGraph、CrewAI、AutoGenは、複数の役割や処理ノードを定義し、タスクの流れを構築するためのフレームワークです。Claude CodeやCodexのようなコーディングエージェントは、リポジトリを読み、コード編集やコマンド実行を進めます。DatabricksはOmnigentを、既存ハーネスを置き換える単一の推論フロー実装ではなく、ハーネスやモデルを切り替え、共通のツール、プロンプト、スキル、ポリシーを扱うレイヤーとして案内しています。
たとえば、調査に強いエージェントから実装に強いエージェントへ切り替える際、利用者が背景情報を最初から入力し直すと、情報の欠落や機密データの再送信が起きます。メタハーネスでセッションを扱う場合でも、無制限に履歴を共有する設計にはしません。データ分類に応じて、削除、要約、マスキングを切り替え前に実行し、許可された文脈だけを次のエージェントへ渡します。
比較軸 | Omnigent | LangGraph・CrewAI・AutoGen | Claude Code・Codex |
|---|---|---|---|
主な役割 | 複数ハーネスの切り替え、合成、共有、ポリシー適用 | エージェントや処理ノードのワークフロー構築 | コード調査、編集、テスト、コマンド実行 |
管理単位 | セッション、エージェント、実行環境、ポリシー | グラフ、タスク、役割、状態 | 開発セッション、リポジトリ、端末 |
ガバナンスの位置 | 複数エージェントにまたがる上位レイヤー | 各アプリケーション内で個別実装 | 各製品や端末の設定に依存 |
得意な領域 | 文脈共有、切り替え、横断ポリシー | 業務フローとマルチエージェント設計 | 開発作業の自動化 |
置き換え関係 | 既存ハーネスを包む構成として利用できる | Omnigentと併用する実行対象になり得る | Omnigentと併用する実行対象になり得る |
主な注意点 | 上位レイヤー追加による構成と障害点の増加 | アプリごとにポリシーが分散しやすい | 端末権限や認証情報が広いと被害範囲が拡大 |
セッション共有とポリシー適用の流れ
安全なセッション共有では、入力、取得データ、ツール実行、出力を同じ信頼境界として扱わず、受け渡しごとに許可判定を行います。
利用者とエージェントのIDを解決し、所属、目的、利用期限をセッションへ関連付けます。
入力データを公開、社内限定、機密、個人情報などに分類します。
呼び出すエージェントとツールの許可範囲をポリシーで絞ります。
別エージェントへ切り替える前に、引き継げる履歴だけを抽出します。
ツール呼び出し、使用量、承認者、結果を監査イベントとして残します。
静的なIP制限だけでは、許可済み端末から実行された危険な操作を止められません。「直前に大量の顧客データを取得した後で外部ストレージへ書き込もうとしている」といった文脈を判定し、許可、拒否、人間承認へ分岐させます。DatabricksはOmnigent on Databricksで組み込みのコンテキストポリシーを案内していますが、対象操作、閾値、承認経路、失敗時動作は利用組織側で設計します。
公開仕様から見た制約
Omnigentはガバナンス全体を単独で完成させる製品ではなく、ID管理、データ権限、ログ保管、端末管理を別の統制基盤で補う構成です。
Databricksの公式ドキュメント（Omnigent on Databricks）では、Omnigent on Databricksはベータ版であり、組み込みのコンテキストポリシーのみをポリシーハンドラーとしてサポートし、任意コードを実行するカスタムポリシー関数はサポートしないと案内しています。また、Databricks Sandboxは選択されたリージョンで提供され、サンドボックス利用には別のプレビュー有効化が必要です。対象ワークスペースのプレビュー設定とリージョンごとの提供状況は同ドキュメントおよび公式リポジトリのリリースノートで確認でき、対応ハーネスと固定バージョンの再現性を確認できた場合は限定検証へ進み、確認できない場合は本番データへ接続しません。
▶ 関連記事: MCP企業導入のセキュリティ完全ガイド｜ガバナンスとリスク対策
▲ メタハーネス（OmniGent）と既存エージェント基盤の階層構造
AIエージェントオーケストレーションが必要な背景
AIエージェントオーケストレーションが必要になる背景には、本番導入の速度に対して、全社ガバナンスと非人間アイデンティティの管理が追い付かないという課題があります。
シャドーAIから野良AIエージェントへの変化
近年のリスクは、未承認AIへの入力管理だけでなく、AIがAPI連携、ファイル更新、データベース操作を連続して実行する場合の管理へ広がっています。
Claude Code、Cursor、OpenCode、自作スクリプトなどを使えば、現場担当者が短期間でエージェントを作成できます。Vibe Codingで生成した処理が、環境変数から認証情報を読み、顧客データを取得し、結果を外部サービスへ送る構成も作れます。利用者が一回の指示しか出していなくても、エージェント側では推論、検索、ツール実行が連鎖します。
従来のSaaS台帳は契約名、利用者、料金、管理者を記録すれば一定の役割を果たしました。エージェント台帳には、所有部門、責任者、使用モデル、実行ID、接続先、読み書き権限、データ分類、費用上限、承認対象操作、ログ保存先、停止方法、最終棚卸し日を追加します。これらが空欄のエージェントは、公開情報だけを扱う隔離環境へ移し、本番システムへの接続を停止します。
導入率とガバナンスの差
AIエージェントの利用拡大を示す調査は増えていますが、調査対象、地域、質問文、成熟度の定義が異なるため、異なる調査の数値を直接比較しません。
Deloitte、Economist Impact、Gartner Japan、OktaなどはAI導入、ガバナンス、アクセス権限に関する調査や見解を公開しています。ただし、本記事の確認範囲では、従来記載していた成熟度割合、導入率、懸念割合について、調査票、対象母集団、調査時点、原典の該当箇所を同一条件で確認できませんでした。そのため、特定の割合を導入判断の根拠には用いません。
実務上は、外部調査の順位や割合より、自社の台帳と技術ログを突き合わせます。IdPのアプリ一覧、OAuth同意、クラウド監査ログ、APIゲートウェイ、経費精算、端末上の実行状況を比較し、所有者不明、接続先不明、停止手段不明の対象を先に洗い出します。
2025年から2026年の規制とガイドライン
規制対応では、AIモデルの性能だけでなく、利用目的、データ、実行履歴、人間の監督、停止手順を説明できる状態を作ります。
欧州連合のRegulation (EU) 2024/1689、いわゆるEU AI Actは段階的な適用を定めています。禁止されるAI慣行とAIリテラシーに関する規定は2025年2月2日から、汎用AIモデルに関する規定は2025年8月2日から適用が始まり、多くの規定は2026年8月2日から適用対象となりました。ただし、高リスクAI、製品安全法制との関係、対象者区分、経過措置には例外があります。欧州委員会のAI Act公式案内とEUR-Lex掲載条文（Regulation (EU) 2024/1689）を参照し、自社の役割が提供者、導入者、輸入者、販売者のどれに当たるかを法務部門と整理します。
総務省と経済産業省は「AI事業者ガイドライン」（2024年4月公開）でAIガバナンス、リスク管理、透明性などの考え方を示しています。IPAもAI活用時のセキュリティ関連情報を継続的に更新しています。法令、ガイドライン、将来の改正議論は混同せず、施行済みの義務、契約上の要求、社内統制として採る対策を台帳で分けます。個人情報保護法に関する論点は、現行法の安全管理措置、委託先監督、第三者提供の整理を先に行い、改正案は施行日と経過措置が確定した時点で管理表へ反映します。
企業によるデータ・AI統合の事例
先進企業は、エージェントだけを導入するのではなく、データ権限、カタログ、監査を同じ基盤へ寄せています。
Databricksは、7-Elevenの公開事例で、Mosaic AIとLangGraphを組み合わせたマルチエージェントアシスタントを紹介しています。店舗運営やマーケティング担当者が対話形式で情報を参照できる構成であり、データ側のガバナンスとエージェント実行を分離しない設計例として参照できます。公開事例の要約では全社的な費用削減率までは確認できないため、数値を推測して投資効果へ転用しません。
Databricksが公開した国内事例では、マネーフォワード、IVRy、データ・ワンがUnity Catalogを軸にデータとAIの統合を進めています。定量成果は企業・対象ワークロードごとに異なります。マネーフォワードの事例では、バッチ処理時間を2〜3時間から1時間以内へ短縮した成果が紹介されています。IVRyでは半分以上のコスト削減、データ・ワンでは約4割のコスト削減が、それぞれ対象条件を伴う個別事例として紹介されています。
企業・業種 | 導入時期 | 課題 | 施策 | 公開された成果 |
|---|---|---|---|---|
7-Eleven・小売 | Databricks公開事例の掲載時点 | 複数データを横断した店舗・販促判断 | Mosaic AIとLangGraphによるマルチエージェント化 | 対話型のデータ活用を実現。定量的な全社効果は非公開 |
マネーフォワード・金融SaaS | Databricks国内事例の掲載時点 | 分散したデータ処理と権限管理 | データ・インテリジェンス基盤とUnity Catalogの活用 | バッチ処理時間を2〜3時間から1時間以内へ短縮 |
IVRy・電話SaaS | Databricks国内事例の掲載時点 | サービスデータの拡大とAI活用 | データとAIワークロードの統合 | 個別事例で対象ワークロードのコストを半分以上削減 |
データ・ワン・データマーケティング | Databricks国内事例の掲載時点 | 大規模データの処理費用と統制 | Unity Catalogを中心とする一元管理 | 個別事例で対象ワークロードの処理コストを約4割削減 |
Omnigentのコア機能とコスト・実行環境の統制
確認済みのOmnigentの機能は、エージェントやハーネスの切り替え、共有セッション、コンテキストポリシー、サンドボックスなどです。一方、Spend Capという固有名称の費用上限制御、使い捨てクラウドサンドボックスの具体的な破棄方針、MLflowやUnity Catalogへの監査項目の完全自動連携は、導入バージョンと運用構成によって変わる設計事項として扱います。
Compositionによるエージェントの合成（公式ドキュメント上の概念名）
DatabricksはOmnigentの説明で、異なるハーネスを切り替え、または組み合わせる構成を案内しています。本記事では、この運用上の使い分けをCompositionとして説明します。
調査、実装、レビューを一つのエージェントへ詰め込むと、プロンプトが肥大化し、不要な権限まで与えやすくなります。調査エージェントには読み取り専用の検索権限、実装エージェントには隔離された作業領域への書き込み権限、レビューエージェントには差分参照権限だけを与えれば、侵害時の範囲を狭められます。
合成のデメリットは、エージェント間の依存関係が増えることです。前段の出力形式が変わると後段が誤解し、複数エージェントが同じ処理を繰り返す場合もあります。運用台帳には、入力元、出力先、再試行回数、タイムアウト、失敗時の停止位置を記録します。依存関係を図示できない構成は、本番接続前に処理単位を分割します。
Controlによる文脈型ポリシー
DatabricksはOmnigent on Databricksで組み込みのコンテキストポリシーを案内しています。本記事では、利用者、データ分類、過去の実行、ツールの危険度を評価し、操作を許可、拒否、承認待ちへ分岐させる運用設計をControlとして扱います。
「削除という単語を含む命令を止める」といった静的フィルターだけでは、同義語や間接的なAPI操作を見逃します。反対に、正当な削除作業まで止めれば現場は管理外ツールへ移ります。文脈型ポリシーでは、対象件数、実行環境、データ分類、直前の取得量、外部送信先を組み合わせます。
たとえば、検証環境の一時テーブルを10件削除する処理は自動許可し、本番の顧客テーブルを更新する処理は承認待ちにします。1,000件を超える更新、権限変更、外部メール送信、新規クラウド資源の作成は、人間が承認するまで停止させます。ポリシー評価サービスが応答しない場合に処理を拒否するフェイルクローズは、意図しない操作を抑える設計です。顧客対応や障害復旧など可用性を優先する業務では、対象操作、代替手順、復旧責任者を事前に定義し、判断可能な運用へ分けます。
Collaborationによる安全な共有
DatabricksはOmnigentの共有セッションとチーム協働を案内しています。本記事では、セッション、成果物、意思決定の根拠を許可された利用者や別エージェントと共有する運用をCollaborationとして説明します。
共有対象は会話全文ではなく、業務に必要な要約、参照データ、承認履歴へ分けます。個人情報を含む入力は次のエージェントへ渡す前にマスキングし、秘密情報は参照先の識別子だけを共有します。人間が途中参加する場合は、承認者の氏名だけでなく、承認時刻、対象操作、差分、期限を記録します。
Human-in-the-Loopをすべての操作へ入れると、承認待ちが滞留して自動化の効果が消えます。閲覧、作業領域内のファイル作成、単体テストなどは自動化し、削除、公開、送信、権限変更だけを承認対象にすると、処理量と統制のバランスを取りやすくなります。
FinOpsと費用上限による費用管理
AIエージェントのFinOpsでは、月次請求を後から確認するのではなく、セッションと業務単位で使用量と推定費用を把握します。
Spend Capは、Omnigentの公式ドキュメントで標準機能名として確認できた仕様ではありません。本記事では、モデル呼び出し回数、トークン量、推定費用、再試行回数に上限を設ける一般的な導入設計を指します。Omnigent、Unity AI Gateway、モデル提供者、API Gateway、ジョブ基盤のどこで上限を実装できるかを確認し、実装できるなら即時停止、低価格モデルへの切り替え、承認要求を業務別に設定し、実装できないなら高額になり得る自動実行を限定します。
費用上限だけでは、同じタスクを複数エージェントが重複実行する無駄を見つけられません。情シスは、部門、エージェント、モデル、ツール、業務IDごとに費用を集計します。予算100万円の検証なら、警告を70万円、承認必須を85万円、停止を100万円に設定し、停止後の例外解除には予算責任者とシステム責任者の二者承認を使います。
Disposable Cloud Sandboxesによる隔離
Databricksは、Omnigent on DatabricksでDatabricks Sandboxを案内しています。本記事でいう使い捨てクラウドサンドボックスは、処理終了後に環境、認証情報、作業データをどこまで破棄するかを定めた隔離実行の設計例です。
ローカルPCでエージェントを動かすと、ホームディレクトリ、SSH鍵、ブラウザ情報、環境変数、別案件のソースコードまで探索対象になる場合があります。サンドボックスには対象リポジトリの作業コピーと短命な認証情報だけを渡し、外向き通信を許可リストで制限します。永続化する対象は、監査ログと承認済み成果物に絞ります。
隔離環境にも、起動時間、クラウド費用、デバッグの難しさというデメリットがあります。機密データや書き込み権限を扱う処理はサンドボックスを必須にし、公開情報の要約だけを行う処理は権限を落とした共有環境で動かすと費用を抑えられます。Databricks Sandboxのリージョン提供状況、プレビュー有効化、ネットワーク制限の仕様を確認できれば対象業務を限定して検証し、確認できなければ社内ネットワークや機密データへの接続を許可しません。
▲ エージェントの操作リクエストにおけるリスク判定と実行制御フロー
対応エージェントと認証・監査ログの設計
Omnigentを安全に運用するには、対応エージェントの確認に加え、短命な認証情報、端末保護、MLflow Tracing、Unity Catalog、SIEMを組み合わせる責任分界を設計します。
対応エージェントとアダプターの管理
Databricksの公式ドキュメントでは、OmnigentはClaude Code、Codex、Cursor、Pi、自作エージェントを共通レイヤーで扱う構成として案内されています。
対応という表現は、すべての機能とバージョンの動作保証を意味しません。エージェント側のCLI、認証方式、出力形式が変わるとアダプターが動かなくなる場合があります。導入時は本番環境へ自動更新を入れず、Omnigent、アダプター、対象エージェント、ランタイムのバージョンを一組として固定します。
LangGraph、CrewAI、AutoGenで作成した独自エージェントは、個別エージェントとメタハーネスの役割を分けて評価します。標準アダプターまたは自社実装の接続部で、固定バージョンのセッション受け渡し、停止処理、ログ取得を再現できれば限定検証へ進みます。再現できない場合は、カスタム接続部分を自社管理コードとして脆弱性診断と変更審査の対象にします。
Databricks OAuthと秘密情報の管理
Databricksの公式案内では、Omnigent on DatabricksはワークスペースIDを利用し、ユーザーはDatabricksログインによって認証されます。自分のマシンをOmnigentホストとして登録するCLI利用時も、Databricksワークスペースに対する認証を用います。
OSS版の認証設定、状態ファイルの保存先、トークンの扱いは、採用するリリースとプロバイダー構成で異なります。従来記載していた~/.ucode/state.jsonを、すべてのOmnigent導入で共通する認証状態ファイルとして扱いません。公式リポジトリの採用タグ、Databricks認証仕様、端末上の実ファイルを確認し、保存場所、更新、失効、権限範囲を設計します。
MDMでは、フルディスク暗号化、画面ロック、OS更新、EDR、端末紛失時のリモートワイプを強制します。状態ファイルの中身を収集すると秘密情報が新たな場所へ複製されるため、棚卸しでは内容ではなく、ファイルの有無、所有者、更新日時、端末IDだけを取得します。管理端末でファイルの存在と利用者を関連付けられる場合は継続利用とし、関連付けられない場合はトークンを失効させて再認証します。
Claude系ツールを組織で扱う際の基本的な権限整理は、既存のClaudeのエンタープライズ向けガイドラインも参照できます。個人用アカウントと業務用アカウントを分け、共有APIキーではなくエージェントごとのIDを割り当てます。
非人間アイデンティティの最小権限
AIエージェントには人間用SSOセッションを使い回さず、用途と期限を限定した非人間アイデンティティを割り当てます。
人間の管理者アカウントをエージェントへ渡すと、エージェントが本来不要な顧客情報、請求情報、権限設定まで操作できます。エージェント用IDは、所有者、目的、接続先、発行日、有効期限、ローテーション日を登録します。読み取りと書き込みを同じIDへまとめず、削除や権限変更は別の短命IDで実行します。
委任チェーンもログへ残します。「従業員AがエージェントBを起動し、エージェントBがツールCのIDを取得してデータDを更新した」という関係を追跡できれば、利用者だけでなく実行主体と更新対象を特定できます。所有者が退職または異動したIDは自動停止し、後任が用途と権限を再承認した場合だけ再発行します。
MLflow TracingとUnity Catalogによる観測可能性
観測可能性では、最終回答だけでなく、モデル呼び出し、検索、ツール実行、承認、失敗を一続きの事象として記録します。
Databricksは、管理版のOmnigentをMLflow Tracingへ接続した構成として案内しています。MLflow Tracingは、エージェント実行をスパン単位で記録し、遅延、入出力、モデル呼び出し、ツール利用を追跡するために使えます。Unity Catalogは、データやAI資産の権限と系譜を管理する役割を担います。Omnigentが実行制御、MLflowがトレース、Unity Catalogがデータ権限と資産管理を担当する構成は、Databricks環境で検討できる設計例です。
ただし、OmnigentからMLflow TracingやUnity Catalogへ、ツール引数、実行者、承認者、費用を含むすべての監査情報が自動連携される範囲は、管理版・OSS版、採用バージョン、実装内容に依存します。標準連携またはラッパー層で必要な項目を取得できるならSIEMへ自動転送します。取得できない項目がある場合は、欠落項目が埋まるまで高リスク操作を自動化しません。
ログ項目 | 最低限記録する内容 | 保存目的 | 欠落時の判断 |
|---|---|---|---|
主体 | 利用者ID、エージェントID、ツールID | 委任チェーンの特定 | 主体不明の書き込みを停止 |
入力・出力 | 分類、ハッシュ、マスキング済み要約 | 情報流通の追跡 | 機密データの外部送信を停止 |
ツール実行 | ツール名、引数、対象、結果 | 変更内容の監査 | 更新・削除権限を付与しない |
費用 | モデル、トークン、推定額、業務ID | 予算超過の検知 | セッション上限を低く設定 |
承認 | 承認者、時刻、対象差分、期限 | Human-in-the-Loopの証跡 | 高リスク操作を実行しない |
▶ 関連記事: 【2026年8月最新】Claude Code 企業利用の統制ガイド｜APIキー管理・MCP連携・シャドーAI対策
情シスが管理するAIエージェントの5大セキュリティリスク
情シスが優先して管理するリスクは、未把握のエージェント、データ流路、過剰権限、費用暴走、監査不能の五つです。
未把握エージェントの増加
最初のリスクは、誰がどのエージェントを動かし、どのSaaSやデータへ接続しているか分からない状態です。
現場が個人アカウントやローカルスクリプトで利用を始めると、契約台帳だけでは検出できません。IdPのアプリ一覧、経費精算、ブラウザ拡張、端末上の実行ファイル、OAuth同意、クラウド監査ログ、APIゲートウェイの通信先を突き合わせます。発見したエージェントを直ちに削除すると利用が地下化するため、所有者と用途を登録できる短い承認経路を用意します。
外部調査の割合を管理目標として転用するのではなく、台帳と技術ログが一致する割合を管理指標にします。利用禁止の社内規程を配布しただけでは、未登録の実行ID、OAuth同意、個人契約、ローカル実行を把握できません。
不透明なデータ流路
二つ目のリスクは、エージェントが取得した機密情報を、別モデル、プラグイン、外部SaaSへ連鎖的に渡すことです。
プロンプトだけを検査しても、検索結果、添付ファイル、ツール応答に含まれる情報は見落とされます。入力、検索、推論、ツール、出力を一つのデータフローとして追跡し、各境界で分類を再評価します。個人情報を含むデータはマスキング済みビューから取得し、原本への接続は承認された用途だけに限定します。
IBMは「Cost of a Data Breach Report 2025」でシャドーAIを含むAI関連リスクを扱っていますが、本記事では、従来記載していた平均追加コストの数値を個別の投資判断へ使いません。侵害コストは、業種、国、検知時点、対象データ、復旧範囲で大きく変わります。社内試算では、外部統計を固定換算せず、自社のデータ分類、復旧時間、契約上の通知義務、利用する予算レートを明記します。
過剰権限とプロンプトインジェクション
三つ目のリスクは、エージェントが人間と同等の権限を持ち、外部データに埋め込まれた命令でその権限を悪用されることです。
Webページ、メール、チケット、文書に含まれる命令をエージェントが正規の指示と誤認すると、秘密情報の取得や外部送信を試みる場合があります。システムプロンプトで秘密を出さないと書くだけでは防げません。外部コンテンツを信頼しない入力として分離し、ツール実行前にポリシーエンジンが対象、件数、送信先を検査します。
AIに付与されるアクセス権限が人間用IDと同じ範囲へ広がると、誤動作と侵害の両方で被害範囲が大きくなります。管理者権限を持つ人間用SSOを使い回さず、エージェントごとの短命IDと読み取り専用権限を基本にします。権限昇格が発生した場合は、承認理由と有効期限を記録し、処理完了後に自動失効させます。
トークンとクラウド費用の暴走
四つ目のリスクは、再試行ループ、長大な履歴、重複処理、無制限のツール実行による従量課金の増大です。
月次請求書で異常を見つける運用では停止が遅れます。リクエスト単位、セッション単位、日次、月次の四段階で上限を設定し、推定額を実行前後に計算します。費用をモデル別に見るだけでは業務価値と結び付かないため、チケット番号、案件ID、部門コードなどの業務識別子を付けます。
上限到達時に無条件で処理を終了すると、顧客対応や障害対応を中断する場合があります。通常業務は停止、優先業務は低価格モデルへの切り替え、緊急業務は予算責任者の承認で一時枠を発行する三段階に分けます。例外枠には終了時刻を設定し、恒久的な上限緩和へ変わらないようにします。
監査不能と規制対応の不備
五つ目のリスクは、最終出力は残っていても、利用データ、ツール操作、人間の承認を説明できない状態です。
AIエージェントは同じ指示でも異なる経路を選ぶため、結果だけから処理を再現できない場合があります。モデル名とバージョン、プロンプトテンプレート、取得データ、ツール引数、ポリシー判定、承認、出力ハッシュを関連付けます。ログ自体に個人情報や秘密情報を複製しないよう、原文ではなく分類、ハッシュ、マスキング済み要約を保存します。
ログを取得できないエージェントは、公開データを使う読み取り専用の検証へ限定します。書き込み操作まで追跡できる場合は本番の限定範囲へ進み、削除、外部公開、権限変更の証跡まで取得できる場合にだけ自動化範囲を広げます。この段階判定により、機能の便利さを理由に監査要件を後回しにする事態を防げます。
▶ 関連記事: 【2026】生成AIセキュリティのベストプラクティスと情シス対策
AIエージェントガバナンスの5大失敗パターンと対策
AIエージェント管理で失敗しやすいのは、全面禁止、静的ルール、人間用IDの流用、個別監視、承認設計の不足です。
失敗パターン | 起こる問題 | 実務上の対策 | 完了の判断基準 |
|---|---|---|---|
全面禁止による地下化 | 個人端末や個人アカウントへ利用が移り、ログを取得できない | 承認済みエージェント、隔離環境、短時間で終わる利用申請を用意する | 未登録通信と経費明細が前月から減少し、利用者と台帳が一致する |
静的ルールの過信 | 文脈に応じて計画を変えるエージェントが単語フィルターを回避する | 利用者、データ分類、対象件数、送信先を評価する文脈型ポリシーを使う | 危険操作の試験シナリオが拒否または承認待ちになる |
人間用SSOの使い回し | 誤動作や侵害時に人間と同じ広い権限が悪用される | 非人間アイデンティティを発行し、用途、所有者、期限、最小権限を登録する | 共有IDがなく、各実行をエージェントIDまで追跡できる |
エージェント別の個別監視 | ログ形式とポリシーがサイロ化し、監査工数が増える | 共通スキーマで実行イベントを集約し、SIEMへ転送する | 共通項目で検索でき、同じ検知ルールを複数エージェントへ適用できる |
Human-in-the-Loopの不足 | 削除、外部送信、権限変更が自動実行される | 操作の危険度と対象件数に応じて承認を強制し、期限切れは拒否する | 高リスク試験で承認前に状態変更が発生しない |
全面禁止を避ける公式利用経路
利用を可視化するには、禁止通知より先に、業務で使える承認済みの実行環境と申請経路を用意します。
申請項目が多すぎると、現場は既存の個人アカウントを使い続けます。初回申請は、所有者、用途、接続データ、実行する操作、想定月額、停止方法に絞ります。公開データの読み取りだけなら自動承認し、社内限定データは部門責任者、個人情報や書き込みはデータ責任者とセキュリティ担当者が承認します。
発見した未登録エージェントを一律停止せず、48時間以内に所有者と接続先を登録できれば隔離環境へ移行します。所有者不明、停止方法不明、管理者権限ありのいずれかに該当する場合はトークンを失効させます。これにより、業務停止を最小化しながら高リスクな実行だけを切り離せます。
停止基準と例外処理
停止基準は事故発生後に決めず、データ量、費用、権限、ログ欠落の閾値として事前に定義します。
許可されていない外部ドメインへの送信を検知した場合は、セッションと関連トークンを即時停止します。
予定件数の10倍を超える読み取りや更新が発生した場合は、処理を中断して所有者へ通知します。
日次予算の80％で警告、100％で停止し、例外枠は終了時刻付きで発行します。
監査イベントが5分以上欠落した場合は、書き込み操作を停止して読み取り専用へ切り替えます。
所有者の退職、異動、委託終了を検知した場合は、非人間アイデンティティを自動失効させます。
例外を認める場合も、口頭承認だけで処理を再開しません。対象セッション、許可する操作、上限額、終了時刻、承認者を記録し、期限到達後は自動的に通常ポリシーへ戻します。例外件数が月ごとに増える場合は、現場の逸脱ではなく標準ポリシーの設計不良として見直します。
OmnigentとAdminaによる2層ガバナンス
OmnigentとAdminaは直接連携を前提とする一体型製品ではなく、エージェントの実行制御とSaaS・アカウント管理を分担する2層のガバナンス設計です。
実行レイヤーと管理レイヤーの責任分界
Omnigentはエージェントのセッション、ハーネス、ポリシー、実行環境を扱うレイヤーとして評価し、Adminaは組織で使われるSaaS、アカウント、契約、ライセンスの可視化を担う管理基盤として評価します。
情シスが把握したい対象は、エージェント内部の挙動だけではありません。誰が生成AIサービスを契約したか、退職者のアカウントが残っていないか、同じ機能のSaaSへ重複課金していないかも管理対象です。Adminaで利用サービスとアカウントを棚卸しし、Omnigentまたは周辺の実行制御基盤で承認済みエージェントの実行を制御すれば、入口と実行中の両方を扱えます。
一方、AdminaがAIエージェントの推論過程やすべてのAPI操作を直接停止するわけではありません。Omnigentも、経費精算に現れた個人契約や組織全体のSaaSライセンスを自動的に最適化する製品ではありません。両者を連携製品と表現せず、補完的な運用構成として責任範囲を分けます。
管理領域 | Omnigent | Admina | 関連する既存基盤 |
|---|---|---|---|
AIエージェントのセッション | 切り替え、共有、ポリシー適用 | 原則として管理対象外 | ワークフロー基盤、開発基盤 |
ツール実行と費用上限 | ポリシーと実行構成で統制対象にできる | SaaS契約費用の可視化で補完 | AI Gateway、API Gateway、FinOps基盤 |
SaaSアカウントとライセンス | 原則として管理対象外 | 利用状況、契約、アカウントの棚卸し | IdP、人事マスター |
非人間アイデンティティ | エージェント実行IDとの関連付け | 接続可能なSaaSアカウント情報で補完 | IdP、PAM、秘密情報管理 |
端末上の状態ファイル | 認証に利用する構成がある | 直接の端末保護は対象外 | MDM、EDR |
監査とインシデント検知 | 実行イベントを生成または連携対象にする | アカウント・利用情報を提供 | SIEM、SOAR |
AIエージェント台帳の共通項目
二つの管理レイヤーをつなぐ実務部品は、製品間APIではなく、共通IDを持つAIエージェント台帳です。
台帳項目 | 記入例 | 取得元 | 未記入時の処理 |
|---|---|---|---|
エージェントID | AGT-CS-001 | Omnigent・開発台帳 | 本番接続を許可しない |
所有部門と責任者 | カスタマーサポート・部門責任者 | 人事・申請情報 | 所有者不明として停止候補へ移す |
利用SaaS | CRM、チケット管理、生成AI | Admina・IdP・経費 | 外部接続を読み取り専用へ制限 |
非人間ID | NHI-CS-001 | IdP・秘密情報管理 | 人間用SSOの流用を停止 |
データ分類 | 社内限定・個人情報あり | Unity Catalog・データ台帳 | 公開データ以外への接続を拒否 |
予算上限 | 月10万円、日5,000円 | FinOps・AI Gateway・実行基盤 | 低い暫定上限を設定 |
停止方法 | トークン失効と実行キュー停止 | 運用手順書 | 本番稼働へ移行しない |
技術的な直接連携の公開状況
OmnigentとAdminaの専用コネクターや双方向API連携は、本記事の確認対象とした公開情報では公式仕様として確認できません。
そのため、Adminaが検知したSaaS利用をOmnigentへ自動登録できる、またはOmnigentのツール実行をAdminaが直接停止できるとは断定しません。両者の情報を結び付ける場合は、エージェントID、所有者ID、SaaSアプリIDを台帳またはSIEM上で関連付けます。
監査ログをAPIで取得できる場合は日次で自動集約し、API取得できない場合はCSVエクスポートと差分確認へ切り替えます。自動停止まで実装できない場合は、IdPまたは秘密情報管理基盤でトークンを失効させる手順を代替の停止手段にします。この責任分界を設計書へ明記すれば、「検知できるが止められない」状態を見落としにくくなります。
▶ 関連記事: シャドーMCP対策ガイド｜AIコーディングが招く新たなデータ漏洩リスクと検知の入口
▲ AdminaとOmniGentによる2層ガバナンスの役割対比
OmnigentとAIエージェント管理のよくある質問
Omnigentの導入判断、用語、既存ツールとの関係について、情シス部門から挙がりやすい疑問へ簡潔に回答します。
Q：Omnigentとは何ですか？
Omnigentは、複数のAIエージェントハーネスを切り替えまたは組み合わせ、共有セッション、ポリシー、サンドボックス、協働を扱うオープンソースのメタハーネスです。Databricksは2026年6月17日にベータ版として公開しました。
Q：メタハーネスとLangGraphの違いは何ですか？
LangGraphはエージェントや処理ノードの流れを構築するフレームワークで、メタハーネスは複数のハーネスを上位から統合するレイヤーです。OmnigentはLangGraphを単純に置き換えるものではなく、接続方式と運用設計によっては併用対象になります。
Q：野良AIエージェントと従来のシャドーITの違いは何ですか？
シャドーITは未承認のSaaSや端末の利用を指し、野良AIエージェントは管理外のAIがAPI、データベース、ファイルを自律的または連続的に操作する状態です。契約の把握だけでなく、実行ID、権限、データ流路、費用、停止手段まで管理します。
Q：OmnigentだけでAIガバナンスは完成しますか？
Omnigentだけでは完成しません。IdP、Unity Catalog、MLflow Tracing、SIEM、秘密情報管理、MDM、SaaS管理を組み合わせ、ID、データ、ログ、端末、契約を分担して管理します。
Q：AdminaとOmnigentは直接連携しますか？
確認対象とした公開情報では、両製品の専用コネクターや技術的な直接連携は確認できません。Omnigentは実行レイヤー、AdminaはSaaS・アカウント・ライセンス管理レイヤーとして、補完的な構成で扱います。
Q：OmniAgent、Ominigent、Omnigenは同じ製品ですか？
本記事が扱う正式名称はOmnigentです。OmniAgent、Ominigent、Omnigen、OmniGentは類似表記または検索時の誤記として扱い、社内資料、リポジトリ、台帳ではOmnigentへ統一します。
Q：本番導入へ進める最低条件は何ですか？
エージェントID、最小権限、費用統制、監査ログ、停止手順の五つを確認できることが最低条件です。採用バージョンの公式ドキュメント、ワークスペース設定、実行ログで五つを確認できれば限定された本番範囲へ進み、いずれかを確認できなければ公開データを扱う読み取り専用の隔離環境に限定します。
まとめ
AIエージェントガバナンス確立に向けた最初の一歩
Omnigentは、個別のAIエージェントを単純に置き換える製品ではなく、複数ハーネスの切り替え、共有セッション、ポリシー、サンドボックスを扱うメタハーネスです。Databricksは管理版でワークスペースID、Unity AI Gateway、MLflow Tracing、Databricks Sandboxとの統合を案内しています。ただし、SaaS契約、端末、非人間アイデンティティ、データ権限、監査保管、費用上限を単独で完結させるものではありません。Admina、IdP、MDM、Unity Catalog、MLflow、SIEMとの責任分界を先に決めます。
AIエージェント管理の初動チェックリスト
社内で動くAIエージェントを、端末、IdP、経費、OAuth同意、クラウドログから洗い出した
各エージェントへ所有者、用途、利用期限、停止方法を登録した
人間用SSOを使い回さず、用途別の非人間アイデンティティを割り当てた
接続するSaaS、データベース、APIと読み書き権限を記録した
トークン、セッション、日次、月次の費用上限を、利用中のAI Gatewayまたは実行基盤で設定できるか検証した
削除、外部送信、権限変更、公開操作へ人間の承認を入れた
ツール引数、承認者、結果、費用を監査ログとして取得した
ログ欠落、予算超過、所有者不明が起きた際の停止処理を試験した
期間 | 実施内容 | 完了条件 |
|---|---|---|
初日から3日目 | AIサービス、エージェント、APIキー、OAuth同意を収集する | 所有者不明の対象を一覧化できている |
4日目から7日目 | 台帳へ接続先、権限、データ分類、予算、停止方法を追加する | 高リスク対象を読み取り専用または停止へ移せている |
2週目 | 非人間ID、費用統制、承認フロー、サンドボックスを限定導入する | 危険操作の試験が拒否または承認待ちになる |
3週目から4週目 | 監査ログをSIEMへ集約し、例外と停止の訓練を行う | 主体、操作、費用、承認を一つの事象として追跡できる |
最初に着手する作業は、ツール選定ではなく稼働状況の棚卸しです。所有者、実行ID、接続先、権限、予算、停止方法の六項目を埋め、空欄があるエージェントを隔離します。その後、複数エージェントへ同じポリシーを適用する必要があり、採用バージョンの公式ドキュメントとワークスペース設定で対応範囲を確認できた場合に、Omnigentを限定評価します。SaaSとアカウントの棚卸しはAdminaなどの管理基盤で補完します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
