米IBMは10月27日(米国時間)日から29日にかけて、ジョージア州アトランタで年次イベント「IBM TechXchange 2026」を開催した。基調講演では、AIエージェントを企業の本番環境へ実装するためのデータ基盤、開発・統合環境、アイデンティティ管理、セキュリティ、IT運用などに関するサービスや機能が相次いで紹介された。

AIエージェントを「いかにスケールさせるか」

生成AIの進化によって、AIエージェントそのものを作るハードルは下がりつつある。一方、作成したエージェントを既存の業務システムにつなぎ、必要なデータと権限を与え、セキュリティやガバナンスを確保しながら継続的に運用するとなれば話は別だ。

今回の基調講演でIBMが繰り返し示したのは、今年1年を通して課題に挙がったAIエージェントを「作れる」状態から、企業の本番環境へ実装し、実際の業務で継続的に使える状態へどう持っていくかということだった。

IBM Software担当Senior Vice PresidentのDinesh Nirmal氏は「昨年のTechXchangeはAIエージェントを構築することが中心でした。今年は、それをいかにスケールさせるかがテーマです。これからのブレークスルーは、エージェントを作るだけではなく、エージェント同士を連携させ、それをスケールさせることです」と強調した。

  • IBM Software担当Senior Vice PresidentのDinesh Nirmal氏

    IBM Software担当Senior Vice PresidentのDinesh Nirmal氏

AIエージェントの企業実装に必要な「Data」「Deployment」「Runtime」

Nirmal氏が、AIエージェントを企業の本番環境で実際に使える状態にするために重要な要素として挙げたのが「Data」「Deployment」「Runtime」の3つだ。

Dataでは、エージェントが判断し、行動するために必要な最新のコンテキスト(文脈)を供給する。Deploymentは、エージェントを作るだけでなく、WorkdayやSAPをはじめとする既存のアプリケーションやインフラへどう組み込むかが問題となる。Runtimeでは、本番環境で実際に動いているエージェントを安全に制御する。

  • AIエージェントを企業の本番環境で実際に使える状態にするために重要な3要素

    AIエージェントを企業の本番環境で実際に使える状態にするために重要な3要素

Nirmal氏は、問題のあるエージェントの権限をリアルタイムに失効できることや、認証情報を動的にローテーションできることを例に挙げた。つまり、大量のエージェントを生成できるだけでは企業ユースには十分ではない。

判断材料となるデータを届け、既存システムへ組み込み、実行中も安全に管理するところまでを一体として考える必要があるというわけだ。そして、Data、Deployment、Runtimeを具体化するようにIBMの製品や機能が紹介された。

AIエージェントに「現在のコンテキスト」を届けるStreamhouse

Dataについて説明したのが、IBM General Manager, IBM Data and ConfluentのShaun Clowes氏だ。もともとは昨年12月にIBMが買収したConfluentのCPO(Chief Product Officer)を務めていたClowes氏は、AIエージェントによって企業活動そのものの「Clock Speed」が変化すると指摘した。

  • IBM General Manager, IBM Data and ConfluentのShaun Clowes氏

    IBM General Manager, IBM Data and ConfluentのShaun Clowes氏

人間が業務プロセスを担えば、その速度は人間が状況を理解し、判断して行動できる速度に制約される一方で、AIエージェントは機械の速度で判断し、行動できる。それによって新たなボトルネックになるのが、エージェントへ提供するコンテキストの品質と鮮度だという。

Clowes氏は「コンテキストが古く、断片化し、不完全であれば、より速く正しい判断をするのではなく、より速く間違いを起こすことになります」と語った。同氏はコンテキストを「ある仕事を完了するために必要な情報」と定義する。

重要なことは単純なデータの量ではなく、Quality(品質)、Relevance(関連性)、Timeliness(適時性)であり、現在の状態を示す「State」と、現在起きている変化を示す「Change」の双方が必要になるとの見解だ。

しかし、実際の企業におけるデータはハードウェアや業務データベース、SaaS、クラウドサービスなどサイロ化している。エージェントやアプリケーションごとにコネクタやパイプライン、データコピーを作り直していては、大量のエージェントを展開する際の障壁になりかねないという。

そこで提示したのが「Streamhouse」。Streamhouseは、企業内のデータを一カ所に集約することを前提とせず、データが存在する場所を生かしながら、リアルタイムに接続、処理、管理し、AIエージェントやアプリケーションに提供するデータアーキテクチャだ。

  • 「Streamhouse」の概要

    「Streamhouse」の概要

従来のように用途ごとにデータをコピーしてパイプラインを構築するのではなく、ビジネスの現在の状態と変化を継続的に捉え、最新のコンテキストとして再利用できるようにする。AIエージェントが状況の変化に応じて、継続的に判断・行動するためのデータ基盤と位置づけている。Clowes氏は特徴として「Always Current(常に最新)」「Mission Critical(ミッションクリティカル)」「Decentralized(分散的)」の3つを挙げている。

また「IBM Confluent Data Streaming Platform」により、Apache KafkaやApache Flink、Kafka Connect、Schema Registry、Apache Icebergなどを基盤に、このStreamhouseアーキテクチャを実装する。

  • 「IBM Confluent Data Streaming Platform」の概要

    「IBM Confluent Data Streaming Platform」の概要

エージェントごとに必要なデータをその都度組み立てるのではなく、最新のビジネスコンテキストを繰り返し利用できる形で準備しておくことで、AIエージェントの企業実装をデータ面から支える考え方だという。

「IBM Bob 2.0」、開発者からナレッジワーカーへ利用を拡大

続いて、IBM General Manager, Automation and AIのNeel Sundaresan氏が取り上げたのが、エージェントの構築や管理、既存システムとの統合だ。Sundaresan氏は「データが新しい燃料なら、AIはエンジンです。そしてAIがエンジンなら、エージェントはエンタープライズソフトウェアをスケールという旅へ運ぶための乗り物です」と表現した。

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

    IBM General Manager, Automation and AIのNeel Sundaresan氏

その一例として紹介したのが「IBM Bob」だ。前回のTechXchange時点ではIBM社内約6000人が利用する開発者向けIDEだったが、現在は17万人超が利用しているという。このうち開発者は約5万人で、11万人超をナレッジワーカーが占める。

IBM社内では1カ月に500万件を超えるタスクが実行され、200万回を超えるツール呼び出し、50万件を超えるスキルの利用があるという。さらに利用者の90%が毎週Bobへ戻ってきているとした。

  • 「IBM Bob」は17万人超が利用している

    「IBM Bob」は17万人超が利用している

同氏は「彼らは肩書上は開発者ではないが、自分でも気付かないうちにソフトウェアエンジニアになっています。いずれ、すべての人がソフトウェアエンジニアになるでしょう」と話す。

こうした利用実態を踏まえ、IBMは2026年夏に「Bob 2.0」を投入。ナレッジワーカーがコードやファイルを意識せずに利用できる「Bob Desktop」、MCPツールやスキルなどを組織内で発見・共有する「Bob Bazaar」、開発からデプロイ、デバッグ、保守までセキュリティやコンプライアンス、ガバナンスを組み込む「Bob DevSecOps」などが紹介された。

IBMが支援しようとしているのは、AIエージェントを生成する作業だけではない。開発者以外にも構築の裾野を広げ、作ったツールやスキルを組織で再利用し、それを企業の管理ルールの中で展開するところまでが対象となる。

  • IBMは2026年夏に「Bob 2.0」を投入した

    IBMは2026年夏に「Bob 2.0」を投入した

IBM watsonx OrchestrateでAIエージェントを一元管理、既存システムとも接続

もちろん、企業が利用するすべてのAIエージェントがBobで作られるとは限らない。Sundaresan氏は「エージェントがどのように、どこで作られたかは問題ではなく、必要なのは、それらを管理できるコントロールプレーンです」と強調する。

そこで、IBMが提示したものが「IBM watsonx Orchestrate」だ。watsonx Orchestrateは、2024年のThinkでも注力していく姿勢を打ち出していた。同ソリューションは複数のAIエージェントを構築・連携し、企業全体で一元的に管理するためのAIエージェント基盤として提供している。

  • 「IBM watsonx Orchestrate」をコントロールプレーンと位置づけている

    「IBM watsonx Orchestrate」をコントロールプレーンと位置づけている

今回、企業内に存在するAIエージェントなどを把握する「Discover」、エージェントを隔離して安全に実行する「Contain」、品質や精度、コンプライアンスなどを検証・監視する「Evaluate」の3つの機能を提供。同基盤では初のセキュリティ機能が実装された。

DiscoverはAmazon BedrockやMicrosoft Foundry、Google Geminiなど外部のプラットフォームとも接続し、そこで構築されたAIエージェントに加えてモデルやMCPサーバを検出する。

ContainはAIエージェントを分離されたサンドボックス環境で実行し、問題がほかのエージェントなどへ波及することを防ぎ、EvaluateはAIエージェントやモデル、MCPサーバについて、導入前に品質、精度、コンプライアンスを検証するとともに、本番稼働後も継続的に監視する。

Sundaresan氏は、エージェントを導入前、導入中、導入後に評価し、信頼性やスケール、セキュリティを観測するとともに、パフォーマンスや品質、コストを最適化するとしている。

もう1つ、Deploymentを考えるうえで欠かせないのが既存システムとの接続だ。企業にはすでに多数のアプリケーションやAPI、メッセージ、イベントと、それらをつなぐインテグレーション環境が存在する。

Sundaresan氏は「企業にはこれまで構築してきた膨大なシステムがあります。ゼロからやり直すことは難しい側面があります」と指摘。そこで投入する「IBM Integration Intelligence Hub」は、こうした既存の企業資産をAIエージェントから発見、理解、再利用できるようにする。

AIエージェントのために既存システムを全面的に作り直すのではなく、これまで蓄積してきた企業ITへエージェントを接続して活用していく。

「IBM Agent Identity」でAIエージェント自身に固有のID

エージェントを企業システムへ組み込んだ後は、実際に動いているエージェントをどう安全に管理するかというRuntimeの課題がある。

IBM Outbound CTO, AutomationのTyler Lynch氏は、自身が2年前にAWS(Amazon Web Services)向けTerraform Providerのコードレビューを支援するAIエージェントを作った経験を紹介した。同エージェントはローカルで動作し、自身のGitHub SSH認証情報を利用していた。しかし、個人の仕事を効率化するには有効だったが「企業環境へデプロイするために求められる基準を満たすものではなかった」という。

  • IBM Outbound CTO, AutomationのTyler Lynch氏

    IBM Outbound CTO, AutomationのTyler Lynch氏

人間のアイデンティティには入社、異動、退職という「Joiner、Mover、Leaver」の比較的明確なライフサイクルが存在する。他方、AIエージェントの寿命は数秒の場合もあれば、数分、数カ月の場合もあるほか、エージェントが人間のアイデンティティを借りて動けば、その操作を人間自身が行ったのか、AIエージェントによるものなのかを判別しにくいといった側面もある。

ツールを呼び出したり、動的にロールを引き受けたりする過程で、人間が監査・承認していない権限が蓄積する可能性もある。そこで投入するのが「IBM Agent Identity」だ。Lynch氏は「すべてのエージェントを暗号学的に検証可能なIDによって登録する」と説明しており、AIエージェントは人間のアイデンティティを借りるのではなく、それぞれ固有のアイデンティティで動作することが望ましいという。

Agent IdentityはOkta、Auth0、Ping、IBM Verifyなど既存のIdPを補完し、OAuth 2.0などの業界標準を利用する。また、シークレットや認証情報を一元的に管理する「HashiCorp Vault」と組み合わせ、短期間のみ有効な認証情報や最小権限によるアクセスを適用する。エージェントがリスクの高い行動を取った場合には、セッションやアクセスをリアルタイムで失効させる。

さらに「Vault 2.2」では、TPM(Trusted Platform Module)を利用したハードウェアを信頼の起点とする暗号学的アテステーション、SCEP(Simple Certificate Enrollment Protocol)によるプロビジョニング、PKI(Public Key Infrastructure)向けの耐量子計算機暗号(PQC)アルゴリズムなどに対応。そのほか「IBM Secure Hub」は、クラウド、オンプレミス、エッジに配置されたVault環境について、一元的な可視性やレポーティングを提供する。

  • Agent IdentityとVaultによるAIエージェントのアクセス制御

    Agent IdentityとVaultによるAIエージェントのアクセス制御

Runtimeというと単純なAIエージェントの実行環境を想像しがちだが、今回IBMが示した考え方はそれよりも広い。実行中のエージェントが何者なのか、誰から何の権限を委任され、何を許可されているのかを把握し、必要ならアクセスを失効させる。そうした実行時の管理と制御まで含む。

本番投入後のDay 2 Operations、ConcertとTerraformで支援

Data、Deployment、Runtimeを整えてAIエージェントを本番へ投入しても、そこで実装が完了するわけではない。Lynch氏は「顧客から聞いていること、そして私たち自身の経験からも、Day 2 Operationsはキャパシティのおよそ80%を占めます」との見立てだ。

これまでは発生したアラートを後から調査したり、過去30日間のクラウド支出を分析して変更したりする運用が一般的だった。その反面、AI時代にはSRE(Site Reliability Engineering：サイト信頼性エンジニアリング)エージェントによるリアルタイムのトリアージや、分単位で変化するAI関連コストへの対処など、より迅速な対応が求められる。

そこでIBMが紹介したのが「IBM Concert Platform」だ。Lynch氏はConcert Platformを「アプリケーション、インフラ、ネットワーク、セキュリティを横断する統合オペレーションのレイヤとなる。複数のツールが発するシグナルを個別に扱うのではなく、データ、コンテキスト、意思決定を単一のシステム上でリアルタイムにつなぐ」と説明している。

そのうちのセキュリティ機能の1つである「Concert Protect」は、アプリケーションのコンテキストと脆弱性の内容をベースにCVE(共通脆弱性識別子)に優先順位を付け、その影響範囲も把握する。ここにBobやTerraformを組み合わせることで、問題の特定だけでなくインフラ側の修正までつなげるという。

Terraformでは「Terraform Policy」をはじめ、「Terraform Developer Portal」、ホスト型の「Terraform Remote MCP Server」、Terraform管理外のリソースも検索する「Terraform Search」などを用意する。

Terraform PolicyはHCL(HashiCorp Configuration Language)をベースとし、人間とマシンの双方が読み取れることを意識して設計し、組織のポリシーに沿ってインフラ変更を統制する。Terraform Developer Portalでは開発者が組織で用意されたセルフサービスのモジュールやリポジトリを利用できる。

BobからTerraform Remote MCP Serverを介して自然言語でインフラ変更を要求しながら、その変更についてTerraform Policyで組織のルールへの準拠を確認することも可能になる。さらに、クラウドコストの可視化・最適化を支援する「IBM Cloudability」との連携により、コストガバナンスも運用の一部として扱う。

  • Terraform PolicyやMCP Serverを活用したインフラ管理の流れ

    Terraform PolicyやMCP Serverを活用したインフラ管理の流れ

ここで重要なのは、AIに自然言語でインフラ変更を指示できること自体ではない。AIや開発者が変更を実行しやすくする一方で、組織標準の構成やセキュリティ、コンプライアンス、コストといった既存のガードレールから外れない仕組みも同時に用意している点だ。

「AIエージェントを作れる」から「企業が実装できる」へ

IBMではAIエージェントそのものの機能を増やすだけでなく、企業がAIエージェントを本番環境へ持ち込む際に直面する実装上のハードルを埋めようとしている。

DataではStreamhouseによって、AIエージェントの判断に必要な最新のビジネスコンテキストを届ける。Deploymentでは、Bobによって構築の裾野を開発者以外へ広げ、watsonx Orchestrateで異なる環境にまたがるエージェントを管理する。Integration Intelligence Hubによって、企業がすでに持っているアプリケーションやAPIなども再利用する。

Runtimeでは、Agent IdentityやVaultなどを通じ、実行中のAIエージェント自身のアイデンティティと権限、認証情報を管理する。そして本番投入後には、ConcertやTerraformなどで、脆弱性、インフラ変更、ポリシー、コストを含むDay 2 Operationsまで支援する。

個々の製品はデータストリーミング、AIエージェント管理、アイデンティティ、シークレット管理、IaC、IT運用と対象領域は幅広い。しかし、Nirmal氏が示したData、Deployment、Runtimeという3つの観点から眺めると、狙いは共通している。AIエージェントを作るところで終わらせず、必要なデータを与え、組織に組み込み、安全に実行し、本番投入後も継続的に管理するということだ。

Nirmal氏が語った「ビルディングからスケーリング」とは、単純にエージェントの数を増やすのではなく、PoC(概念実証)で動くAIエージェントと、企業の本番環境で継続的に使えるAIエージェントとの間にある壁を越えることだ。

その“実装の壁”を越えるための仕組みを、データから開発・統合、実行時の制御、運用までIBMの製品群全体で整えていく姿勢が鮮明になった。