米ジョージア州アトランタで10月27日(米国時間)から29日にかけて、年次イベント「IBM TechXchange 2026」を開催したIBM。2日目の基調講演では、AIエージェントの自律性が高まる中、ソフトウェア開発からアイデンティティ管理、ランタイム、インフラまでをどのように保護するのか、その対応策が示された。

AIエージェントの自律性向上、セキュリティ対策はインフラまで

初日の基調講演は、AIエージェントを「作る」から「企業で使う」フェーズに向けて、AIエージェントの企業実装に必要な「Data」「Deployment」「Runtime」の重要性を説き、その中でも開発ライフサイクル全体の最適化と、企業システム刷新の効率化を支援する「IBM Bob」への期待値は想像以上だった。

2日目の基調講演の冒頭に登壇した、IBM General Manager, Automation and AIのNeel Sundaresan氏は「Bobはセキュリティファーストを掲げ、セキュリティ、脆弱性、ガバナンス、コンプライアンスを、開発からデプロイ、運用までソフトウェア開発ライフサイクル全体に組み込みます」と説明した。

  • IBM General Manager, Automation and AIのNeel Sundaresan氏

    IBM General Manager, Automation and AIのNeel Sundaresan氏

AIを活用した開発では、成果物はコードだけではなく、プロンプトや利用したモデル、スキル、ツール、MCPサーバなども含めて管理する必要がある。IBM Bobが目指すのは、AIが生成したコードだけを安全にすることではなく、AIがソフトウェアを構築するプロセスそのものを安全にすることだという。

また、AIエージェントが企業全体で利用され、自律性を高めていけば、セキュリティの対象はソフトウェアだけでなくインフラにも広がる。AIエージェントをどの環境で動かし、どのような制御を適用するのか。その重要性は一段と高まるとのことだ。

この問題について基調講演では、IBM Infrastructure CTO兼GM of Innovation, IBM FellowのHillery Hunter氏をモデレーターに、Red Hat CTOのChris Wright氏、NVIDIAでAI CybersecurityのDeveloper Relationsを担当するChris White氏、IBM Director, Product ManagementのDrew Roy氏が対談した。

AIで脆弱性発見も加速、Red Hatは「インターネット全体にパッチ」

まず、Hunter氏はTechXchangeに参加する技術者がデータベースの管理や物流システムの構築、数万個規模のIoTセンサの監視、メインフレームの運用などミッションクリティカルな業務を担っていることに触れ「こうした領域でエージェントについて考える際には、安全性、信頼性、セキュリティについて問うことになる」と議論の口火を切った。

  • IBM Infrastructure CTO兼GM of Innovation, IBM FellowのHillery Hunter氏

    IBM Infrastructure CTO兼GM of Innovation, IBM FellowのHillery Hunter氏

最初の論点となったのは、AI時代のオープンソースと脆弱性対応だ。Red HatのWright氏は「AIによってソフトウェア開発ライフサイクルそのものが変わりつつある一方、AIが脆弱性を見つける能力も高めています」と指摘する。

  • Red Hat CTOのChris Wright氏

    Red Hat CTOのChris Wright氏

オープンソースソフトウェアはインターネット上で広く公開されているため、同じくインターネット上のデータを学習したAIモデルも、そのコードやプロジェクトについて多くの情報を持つ。AIのサイバーセキュリティ能力が向上すれば、それだけ脆弱性を発見するスピードも速くなる。

Wright氏によると、現在は月に約1万件、1日当たり約300件のペースで脆弱性が発見されており、そのうち高リスクに分類されるものは1日1件程度だという。そこで、Red Hatが取り組んでいるのが、脆弱性へのパッチ適用や修正を支援する「Project Lightwell」だ。

企業が利用するアプリケーションには、多数のオープンソースソフトウェアと依存関係が含まれている。Lightwellでは依存関係を把握し、スキャンによって脆弱性の所在を特定したうえで、本番環境で実際に使われているバージョンに合わせたパッチを提供する。同時に、修正をオープンソースコミュニティにも還元するという。対象となるソフトウェアプロジェクトは約100万規模に及ぶ。

  • 「Lightwell」によるオープンソースの脆弱性修正の仕組み

    「Lightwell」によるオープンソースの脆弱性修正の仕組み

Wright氏は「私たちは、インターネット全体にパッチを当てているようなものです。1つのプロジェクトに数人のエンジニアを割り当てれば、数百万人のエンジニアが必要になる。それではまったくスケールしません」と話す。

そのため、ビルドから脆弱性の発見、修正、パッチの提供まで、一連のワークフローにAIを組み込むことが不可欠だとの見方を示した。

IBM Agent IdentityでAIエージェントに固有ID、権限は必要なときだけ

一方、コードの脆弱性とは異なり、AIエージェントそのものが動的に行動することで新たな課題も生じる。

IBMでHashiCorp製品と、IAM(ID・アクセス管理)ソリューション「IBM Verify」を担当するRoy氏が問題視したのは、AIエージェントが人間のオペレータになりすまし、人間に与えられた権限を使って処理することだ。

同氏は、企業がより安全にAIエージェントを利用するには、エージェント自身に検証可能な固有のアイデンティティを持たせる必要があると説明。さらに、エージェントが企業内で実行すべき処理に応じて、利用できる権限を限定する。

鍵となるのがエージェントの「Intent(意図)」だ。Roy氏は「エージェントが特定のリクエストで何をしようとしているのかを把握し、その“意図”にもとづいてアクセス範囲を決める必要があります」と話す。

  • IBM Director, Product ManagementのDrew Roy氏

    IBM Director, Product ManagementのDrew Roy氏

これは、必要な認証情報やアクセス権をジャストインタイムで付与し、タスクを完了すれば失効させる考えだ。ここでシークレットや認証情報を一元的に管理する「HashiCorp Vault」と、Oktaなど既存のIdP(Identity Provider)を補完し、OAuth 2.0などの業界標準を利用する「IBM Agent Identity」を組み合わせる。

AIエージェントを隔離された環境で実行すると同時に、接続先のシステムにアクセスするための認証情報をエージェントに永続的に保持させない。必要になった時点でVaultなどから取得することで、仮にエージェントに問題が生じても、ほかのシステムへ継続的にアクセスされるリスクを抑える。

Roy氏は「これにより問題発生時の影響範囲の縮小と、エージェントの行動を後から検証できる監査性の確保につながります」と説く。

NVIDIA OpenShellでAIエージェントをサンドボックスで制御

さらに、AIエージェントが実際に動作するランタイムを保護する仕組みとしてNVIDIAのWhite氏が説明したものが、同社の「OpenShell」だ。同氏は「エージェントは、取り込むコンテキストや利用するツール、ユーザーから与えられるプロンプトによって振る舞いが変化し、目的自体が時間とともに変わる可能性があります」と指摘。

そこでOpenShellでは、AIエージェントをサンドボックス環境で実行し、アクセス可能なファイルシステム、利用できるファイル、プロセスが接続できるエンドポイント、接続可能なネットワークなどを制御する。

Linuxカーネルの制御機能を利用することで、AIエージェントが許可された範囲から外れない実行基盤を構築する。NVIDIAでは、IBMとAgent Identityとの統合、Red HatとはOpenShiftとの連携を進めている。

Wright氏は「考えるべきなのは1つのエージェントではなく、企業全体でスケールするエージェントです」と話す。

  • NVIDIA Director, Cybersecurity Developer RelationsのChris White氏

    NVIDIA Director, Cybersecurity Developer RelationsのChris White氏

企業では数百人のユーザーが数千のAIエージェントを起動する可能性がある。OpenShiftやKubernetesを通じ、各エージェントに対して「ネットワークのどこへ接続できるのか」「ファイルシステムのどこへアクセスできるのか」といったポリシーを適用することで、大規模な環境でも制御可能にする。

NVIDIA Sentryでハードウェア側からAIエージェントを監視

一方、サンドボックスの外側からAIエージェントを監視する役割を担うのが「NVIDIA Sentry」だ。White氏は「エージェントを制御するためには、エージェントが行っていることを把握できる可視性が不可欠です」と説明する。

NVIDIAのVera Rubinアーキテクチャでは、Vera CPU側でOpenShellのランタイムやサンドボックスを動かす一方、DPU(Data Processing Unit)側にセキュリティ機能を配置する。

エージェントのネットワークトラフィック、ツール呼び出し、各種アクセス、推論で利用するモデルとの通信などを、エージェントの実行環境とは分離されたSentry側から監視する構成となっている。

ポイントは、エージェント自身から見えない場所で、その振る舞いを監視することで、エージェントが想定外の振る舞いを始めたり、サンドボックスの制御を抜け出そうとしたりした場合にも、迅速に停止できるようにする。

なお、OpenShellとSentryともにAIエージェントの動作をソフトウェアからインフラまでの複数層で制御するオープンなリファレンスデザイン「NVIDIA Open Agent Safety Platform」を構成するプロダクトだ。

AIエージェント導入でも既存のセキュリティ基盤を生かす

アイデンティティ管理、認証情報管理、サンドボックス、ハードウェア監視とレイヤを重ねれば、企業側には「AIエージェントのために既存のセキュリティ基盤を全面的に入れ替える必要があるのか」という疑問も生じる。

Roy氏は「これは全面的な入れ替えではありません」と明確に否定した。IBMが重視するのは、企業がすでに利用しているIdPやセキュリティツールを生かしながら、AIエージェントのアイデンティティや行動管理を追加することだ。

例えば、オペレータがAIエージェントへ指示してから、エージェントがIdPへ認可を要求し、Vaultから認証情報を取得してシステムへアクセスするまで、エージェントのアイデンティティと意図を一貫して追跡する。

これによって「何にアクセスしたのか」「いつアクセスしたのか」「なぜアクセスしたのか」を記録できる。さらに、監視ツールなどがエージェントの異常な振る舞いを検出した場合には、IdPと連携してエージェントのセッションを失効させたり、Human-in-the-Loopへ切り替えて人間による追加認証を要求したりすることも可能になる。

Roy氏は「既存のテクノロジースタックをすべて再構築してほしいわけではありません。すでに行ってきた投資を、より価値のあるものにしたいのです」と説明した。

AIエージェントの自律性が高まるほど「人間による統制」が重要に

対談の最後、企業はどこから着手すべきかという問いに対し、White氏はまず「Secure Runtime」を決めることが重要だとした。

Wright氏は、ガバナンスについて興味深い見方を示す。ガバナンスは一般的に、手続きを増やして開発や運用を遅くするものと捉えられがちだ。しかし、エージェントが従うべきポリシーを事前に明確にし、それをシステムとして実行可能にしておけば、むしろ迅速にAIを使えるようになるという。

Roy氏は、各AIエージェントに固有のアイデンティティを与えたうえで「このエージェントは誰なのか」「誰の代理として行動しているのか」「何をしようとしているのか」「接続先システムで何をしたのか」を一貫して追跡する必要があると話した。

  • 対談の様子

    対談の様子

Sundaresan氏が示したように、AIエージェントの自律性が高まれば、守るべき対象は生成されたコードだけではなく、開発プロセス、アイデンティティ、認証情報、ランタイム、さらにはハードウェアへ広がっていく。

一方で、すべてを新しく作り直すのではなく、既存のIdPやOpenShift、Vaultなど企業がすでに持つ仕組みと連携させながら、必要な場所に制御を追加する。AIエージェントにどこまで自律性を与え、それをどのレイヤで制御するのか。AIを企業で本格的に動かす局面に入ったからこそ、人間による判断とガバナンスをシステムとして実装することの重要性が浮き彫りになっている。