職場は常に変化している。1970年代の「オフィス」を覚えている人なら、今日とはかなり異なる環境の姿を思い描くことができるだろう。携帯電話の代わりにポケットベル、長い昼休み、喫煙、そして現在では（ほとんど）進化を遂げた様々な態度や言葉遣いは別として、コンピュータ自体が少なく、あったとしても、おそらくコモドールPETかアップルIIだっただろう。
半世紀強の間に、私たちは新しい機械、ソフトウェア、職場の構造を目の当たりにしてきた。
予測型、生成型、エージェント型AIサービスが職場の運営方法を再構築し始めるにつれ、労働力自体が新しい基準によって再定義されている。仕事を遂行するのは従業員だけでなく、業務フローシステムや運用記録システム、取引システムなどのソフトウェアベースのシステムも含まれる。これらすべてがAIエージェントのオーケストラと連携する必要があり、私たちは全員が調和を保ち、同じ楽譜に従わなければならない。では、どこから始めればよいのだろうか？
エージェントの原点：インフラストラクチャ
この分野での一般的な議論は、エージェント型AIが繁栄できるよう、基本レベルに立ち返り、インフラストラクチャサービスが正しく整列されていることを確認する必要性に集中しているようだ。良質なデータと適切な言語モデルの必要性（そう、データよりも重要なのは、ゴミを入れればゴミが出るという達人たちを一瞬黙らせるために）の前に、技術チームはエージェントサービスのコアフレームワークコンポーネントを管理するための管理ツールキットを必要としている。
この戦略を追求しているソフトウェアベンダーについては、すべての企業が取り組んでいる。現在この分野で最も熱心な声の一部を探すと、エンタープライズ向けエージェント型オートメーション企業のCamundaが最近、コアプラットフォームの提供を拡張・強化し、デプロイメントの簡素化、セキュリティの向上、柔軟性の向上を実現している。これにより、データサイエンスの実務者やソフトウェア開発者は、重要なビジネスプロセスにおいてAIエージェントを設計・オーケストレーションできるようになる。
エージェント・オーケストレーションが自律性を決定づける
「ほとんどのエージェント型AIプロジェクトがパイロット段階で停滞するのは、モデルの能力不足が原因ではなく、リスクなしにエージェントを重要なビジネスプロセスにデプロイするためのガードレールを提供するアーキテクチャがまだ存在しないからだ」とCamundaのCTO、ダニエル・マイヤー氏は述べている。「エージェント・オーケストレーションはその方程式を変え、企業がエージェントにどれだけの自律性を与えるかをコントロールし、必要な場所にコントロールを、AIが輝く場所に柔軟性をもたらす。決定論的フローとダイナミックなエージェントを融合させることで、組織は生産性の向上を達成できる。私たちは動的な推論と決定論的なガードレールを組み合わせ、組織が信頼と自律性のためのAIエージェントを設計できるようにしている」
Camunda（ラテン語の「capere」（理解する）と「munda」（清潔である）に由来）は、エージェント・オーケストレーションの調和をもたらし、複雑なプロセス（多くの場合、専門化されたエージェントが同時に作業する必要がある）を、マルチエージェント通信プロトコル、エージェント、プロセスのサポートで統合・接続できるようにすると述べている。マイヤー氏はここで決定論的ガードレールについて言及している。これらは本質的に、エージェントが操作できる「決定テーブル」を管理するのに役立つ、監査可能でコントロール可能なルールと境界である。少しブランディングが行われており、「ダイナミック」オーケストレーションは非決定論的と同じだが、より否定的でない響きがある。
ここで参照・説明されているように、これらのデプロイメントシナリオではモデルコンテキストプロトコルが機能しており、MCPコネクタが特徴となっている。
このレベルのエージェント型オートメーションをサポートするために、エージェントは時間の経過とともに学習、記憶、適応する能力が必要である。CamundaのAIエージェント構成可能な短期記憶は、エージェントに「会話コンテキスト」を提供し、カスタムコードやパフォーマンスのトレードオフなしにフォローアップの質問やフィードバックループを処理できるようにする。同社によれば、このアプローチにより、組織はエージェントとのやり取りを孤立したタスクから継続的でコンテキストを認識したプロセスに変えることができるという。
牙のないトラは噛まない
「単にDMS、ERP、CRM、SCM、HCMシステムに『エージェントを投入する』だけでは、ボットが既存のビジネス運用システム（本質的にコアビジネスロジックに整合している）と統合・整合されることなく、あちこちに出現することになる。これは結局、サイロで運用され、ビジネス価値を追加できないことを意味する。つまり、牙のないトラのようなものになり、信頼されず、本来パフォーマンスを発揮すべきタスク中心のワークロードに対応できなくなる」とCamundaのCEO、ヤコブ・フロイント氏は述べている。
Camundaはこの市場で決して孤立していない。マイクロソフトも当然ながらこの分野で懸命に取り組んでおり、10月の最近のブログ投稿では、レッドモンドがグラフベースのオーケストレーションを、AIエージェントの構築、オーケストレーション、デプロイのためのマルチ言語フレームワーク全体に提供するよう取り組んでいることが示されている。.NETとPythonの両方の実装をサポートするMicrosoft Agent Frameworkは、シンプルなチャットエージェントから、グラフベースの相互接続の豊かさを持つ複雑なマルチエージェントワークフローまで、あらゆるものを提供すると言われている。
既存のプロジェクト技術の実質的な統合であるこの取り組みにより、マイクロソフトは「あらゆるスキルレベル」のソフトウェアアプリケーション開発者がAIエージェントを作成・オーケストレーションし、どれだけの自律性を付与するかを調整できるようにするオープンソースのソフトウェア開発キットを提供している。
「[エージェントのオーケストレーションと管理に必要な基盤技術に関して]マイクロソフトでは、この問題の最前線に立ってきました」とマイクロソフトのプロダクトマネジメントブロガーであるタクト・ヒグチ氏、ショーン・ヘンリー氏、イライジャ・ストレート氏がMicrosoft devblogsでブログを投稿している。「Semantic Kernelでは、エンタープライズシステム、コンテンツモデレーション、テレメトリへのコネクタを備えた安定したSDKを開発者に提供しました。Microsoft Researchで先駆的に開発されたAutoGenでは、コミュニティにインスピレーションを与えた実験的なマルチエージェントオーケストレーションパターンへの扉を開きました。どちらも熱心なユーザーがいましたが、それぞれにギャップがありました。開発者は私たちに尋ねました：AutoGenのイノベーションとSemantic Kernelの信頼性と安定性を一つの統一されたフレームワークで持つことはできないのか？ それがまさに私たちがMicrosoft Agent Frameworkを構築した理由です」
Google Geminiとその広範な（本当に広い）プラットフォーム全体に現れているエージェント型インテリジェンスを考えると、Agent Builderとそれに付随するオーケストレーション機能を備えたGoogle Vertex AIについても言及するのは当然かもしれない。予想通り、ここではGoogle Cloudの全体系との深い統合がある。ノーコード（完全に）のAgent Builderサービスも特徴で、これはソフトウェア開発者とデータ実務者がモデルとそれが利用するデータにまたがるエージェントオーケストレーションツールを磨き、使用できるように設計されている。
市場で最も安価なサービスではなく、ハイパースケーラーのロックインの可能性もあるが、これはある意味ではまだ胎児期の技術であるため、Googleのノーコードコンソールを超えた高度なエージェントパターンを管理するために追加のソフトウェアエンジニアリング作業が必要になることを予想するのは不合理ではないかもしれない。
マルチエージェントの具現化
APIゲートウェイとサービスメッシュ管理会社Soloのプロダクト担当バイスプレジデントであるキース・バボ氏は、AI中心のソフトウェアアプリケーション開発チームがマルチエージェントの世界に足を踏み入れる際の飛躍（あるいは少なくとも拡張への努力）を認識している。多くのIT部門がまだエージェント型デプロイメントの最初の一歩を踏み出している段階であること（その一部はまだ本番段階のソフトウェアシステムに公開されていないプロトタイプ構造）を強調しながら、バボ氏はこの分野での警鐘を鳴らしている。AI開発のペースは多くの場合、理解しがたいほど急速であり、エージェント型AIの自律性は私たちが考えているよりもずっと近いかもしれないからだ。
「単一エージェントのデプロイメントからマルチエージェントアーキテクチャへの移行は、単なるルーティングとオーケストレーション以上のものを必要とします。異なるモデル、ツール、エージェントフレームワーク、環境全体でセキュリティ、可観測性、ガバナンスを管理するためのコンテキスト認識ランタイムが必要です」とバボ氏は述べている。「kagentプロジェクトはこの基盤をKubernetesにもたらし、セキュリティ、ポリシー、可観測性が異種のエージェントフレームワーク全体にどのように適用されるかを標準化するベンダー中立のランタイムを確立します」。KubernetesでプラットフォームエンジニアリングソフトウェアチームがAIエージェントを構築・実行するためのクラウドネイティブフレームワーク技術であるkagent（またはKagent）は、可観測性と構成コントロールに加えてトラブルシューティングとセキュリティ機能を提供するという意味でもエージェントオーケストレーターである。
この市場の他のベンダーには、Agent Workbenchを持つOutSystemsのローコードエージェントオーケストレーションサービス、エージェントサービスが存在する場所でエンドツーエンドのプロセスオーケストレーションを提供し、変化に適応する自己修復オートメーションも備えたUiPathの同名のAgentic Automationプラットフォームがある。完全を期すために、エージェントオーケストレーションサービスを探しているソフトウェア購入者は、金融などの規制産業におけるコンプライアンスワークフローのオートメーションを組み合わせるように設計されたソフトウェアシステムのノウハウであるIBMのwatsonx Orchestrateも検討するかもしれない。さらに、マルチチャネルエージェント向けの会話型AIオーケストレーションを提供するKore、Aisera、Moveworks、Beam AI、Sendbird、LangChain、Salesforce、AWS、Lindy、Hippocratic AIもある。
AIにどれだけの自律性を求めるのか？
これらのツールが登場している今、エージェント型AIのオーケストレーションが調和を保ち、より豊かなハーモニーを生み出しながら、これまで想像もしなかった新しい複雑なシンコペーションを織り交ぜるために自らを拡張し始めるかどうかを問うことができるだろうか。そして第二に（おそらく最も重要なことに）、今日のエージェント型AIサービスからどれだけの自律性を求めているのかを評価することは可能だろうか？
マイクロソフトの（上述の）開発者の最前線の経験が質問の一部に最も正直に答えている。つまり、開発者はこのまだ新興の技術分野のための革新的なサービスを望んでいた（それは利用可能だったが、より脆弱で堅固でないサービスセットを使用するというコストがかかった）。そして彼らは安定性とスケーラビリティを望んでいた。彼らが構築するものが、あらゆる状況（ここではすべてのデータフロータイプ、速度、頻度、システム需要レベルを意味する）で耐えられるようにするためだ。これは多くを求めることである。
どれだけの自律性を求めるかという質問について、アナリストハウスGartnerのサイカット・レイ氏は、今日「AIは意思決定者というよりも意思決定強化者としての役割を果たしている。その現実は変化しており、エージェントが非構造化データをより有能に扱い始めるにつれて（銀行、金融、保険は成長しており、ヘルスケアや政府も同様）、特に組織が開発を促進するためのエクセレンスセンターを形成する環境で、新しい分野での成長が見られるだろう」と述べている。
CamundaのフロイントCEOは、エージェントの自由度の問題を強調するために、バランスの取れた考慮された回答を持っている。つまり、十分なガードレールとガバナンスコントロールを設定しながら、ユーザー自身が急進的に新しい技術に触れた際に自然に見出す受容曲線も考慮に入れれば、（段階的に）自律性に移行できるということだ。
「自動運転車の展開方法（一部の場所や操作の範囲内で）と似ていないわけではないが、自律走行車の大規模な展開はまだ実現していない。そして私は、ビジネスプロセスのためのエージェント型自律性についてもまだ完全には達成されていないと主張するだろう」とフロイント氏は述べている。「これは、運用上の例外や異常がまだ存在するからだ（特に医療、政府、金融、ビジネスで高リスクの決定が必要な場合）。そのため、人間がループに入る必要がある。しかし、組織が自律性を『上げる』準備ができている近い将来を確かに想像できる。2000人の会社がゼロになるとは思わないが、2000人から200人、最終的には20人に移行する可能性はある。しかし、これは明日のことではない」
この多様で競合他社が多く存在する市場では、時間（1年）を与えれば、ソフトウェア業界は間違いなく、ここで働くプレーヤーを一望できるいわゆる「単一のガラス窓」を提供する「オーケストレーターのオーケストレーター」と銘打ったサービスを作り出すだろう。今や私たちを救えるのはベアメタルだけだ。
