エージェントを「作る」から「スケールさせる」へ。IBM TechXchange 2026の基調講演に見る、増えたエージェントを動かし続ける条件
「IBM TechXchange 2026」レポート
日本の現場から見たエージェント導入の実際
野村氏は日本からの参加者向けのQ&Aで、企業への支援経験を踏まえ、エージェントの設計や導入の実態について説明した。
まず、Agent Identityの設計思想についてだ。特定のIdP（Identity Provider）に依存しないオープンな設計を重視し、ベンダーロックインを避けることを目指しているという。OAuth 2.0やOpenID Connect（CIBAを含む）などの標準仕様を利用すれば、同様の仕組みを独自に実装することも可能だ。しかし、これらを個別に実装し、管理・運用するには相応の負担が生じる。標準仕様に基づく認証や権限委譲の仕組みを製品として提供し、GUIを通じて設定・管理できることが価値だと野村氏は説明する。
次に、エージェントの設計についてだ。野村氏によると、顧客は何でもこなす大きなエージェントを1つ作るより、人事やITサポート、経費精算といった業務領域や役割に応じてエージェントを分けて設計するケースが多い。1つのエージェントに多くの役割を持たせると、処理が複雑になり、精度の維持や改善が難しくなる場合があるためだ。製品としてはどちらの設計にも対応しているが、現場では業務上の責務を明確にしながら設計するアプローチが多いという。
基調講演でも、クロウズ氏は導入に向けた6つのステップの最初に「本番のワークフローを1つ選ぶ」ことを挙げていた。まず対象となる業務を明確にし、その実現に必要なエージェントの役割や連携を設計していくという考え方だ。
また、企業がAIエージェントの導入を検討する際には、具体的なユースケースから議論が始まることが多いという。
「お客さまの多くは、まずAIエージェントで何ができるか、どの業務に活用できるかというところから検討を始めます。その後、具体的なユースケースが明確になり、既存システムとの連携や業務の実行が必要になると、エージェントにどのような権限を与え、どう安全にアクセスさせるかという課題が見えてきます。そこで、Agent Identityのような仕組みの重要性が具体的になります」
製品を提供する側としては、Agent Identityの重要性を導入初期から訴求したいところだろう。一方、野村氏が語ったのは、顧客が実際にAIエージェントの導入を検討する際のプロセスだ。まず実現したいユースケースから検討が始まり、既存システムとの連携や業務の実行が具体化する中で、エージェントの認証や権限管理の必要性が明確になっていくという。リンチ氏の失敗談も、システムとの連携においてこうした課題が顕在化した事例だった。
エージェントの活用範囲が広がるにつれて、企業の既存システムとの安全な連携や、適切な権限管理が重要になる。野村氏は、ユースケースの検討と並行して、認証・認可やガバナンスを考慮した設計が必要だと強調した。
詰まるのは作り方ではなく、増えた後の3か所
エージェントが1社で15万に増えたとき、企業はどこで詰まるのか。基調講演の答えは、作り方ではなかった。エージェントに渡すコンテキストの鮮度、作ったエージェントの管理、そして実行時の権限と運用の3か所だ。
ニーマル氏は「データ、デプロイ、ランタイムを取り上げました。さあ、エージェントをスケールさせに行きましょう」と講演を締めた。
発表を層ごとに整理すると、次のようになる。
| 層 | 主な発表 | 提供状況 |
|---|---|---|
| データ | Streamhouse（IBM ConfluentのData Streaming Platformで構成） | アーキテクチャの提唱 |
| デプロイ | Bob Desktop、Bob Bazaar、Bob DevSecOps | 提供時期は未発表 |
| デプロイ | watsonx Orchestrateの評価機能（Evaluate） | 一般提供 |
| デプロイ | watsonx Orchestrateの発見・封じ込め機能（Discover、Contain）、IBM Integration Intelligence Hub | テクニカルプレビュー |
| ランタイム | IBM Agent Identity、Vault 2.2、Terraform Policy、Concert Platform | 一般提供 |
| ランタイム | Secure Hub、Terraform Developer Portal、Terraform MCP Server（リモート版）、Terraform Search with Policy | パブリックプレビュー |
ベンダーを決める前に、自社の現状を測る物差しとしては、次の問いが使える。1と2はクロウズ氏の3つの問いを縮めたもので、3以降は各登壇者がデモで示した点をもとに編集部がまとめた。
- エージェントが行動する対象の現在の状態はどこにあるか。状態と変化の両方を、データのコピーを増やさずに見られるか
- エージェントが行動した結果を、次の判断の前に使えるようにできるか
- 社内で作られたツールやスキルを、どこで共有し、誰が標準を決めるか
- 他社の基盤で作ったものも含め、社内のエージェントを1か所で一覧でき、止められるか
- どのエージェントが、誰の権限で、何をしたかを後から追えるか
- 開発者やエージェントが、承認済みの部品だけを意図で要求できる状態になっているか
この記事は参考になりましたか？
既に会員の方はを行ってください。
- この記事の著者
-
斉木 崇（編集部）（サイキ タカシ）
株式会社翔泳社 ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科（建築学専門分野）を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine（コードジン）」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine（エドテックジン）」...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
