Cornerstone OnDemand, Inc. (Cornerstone)は186カ国で140百万のユーザーにサービスを提供する、人材即戦力ソリューションのグローバルリーダーです。同社は、データベース運用を事後的な火消しからプロアクティブかつ自己オーケストレーション型のワークフローへと変革するマルチエージェントAIシステムを構築しました。Orion AIと呼ばれるこのシステムは Amazon Bedrock と、AWSのオープンソースエージェントオーケストレーションフレームワークである Strands Agentsを使用して、専門化されたエージェント群を調整しています。
Orion AIの導入以前、CornerstoneのEnterprise DataOpsチームは、データベースインシデント1件につき最大45分を、システムビューの手動クエリやログの相互照照査に費やし、その後チーム間で引き継いでいました。Orion AIの導入により、データベース診断は45分から10分に短縮され、78%の削減を実現しました。3名のチームが6か月でこのシステムを構築しました。
本記事では、Cornerstoneが直面した運用上の課題、Orion AIの設計方法、測定された成果、そして他のチームが再利用できる設計上の判断について解説します。
運用上の課題
Orion AIの導入以前、CornerstoneのEnterprise DataOpsチームはリアクティブに運用しており、4つの繰り返し発生する課題を抱えていました:
- データベースパフォーマンスの調査にはインシデントあたり約45分かかり、複数のツールとシステムビューにまたがって行われていました。
- データベースのライフサイクルワークフローには、接続の確立からステータス更新の連絡まで、10以上の手動ステップが必要でした。
- サイト信頼性エンジニアリング(SRE)チームとデータチーム間のレポートは、15分の遅延で運用されていました。
- 重複し重なり合うアラートがノイズを生み、重要なシグナルを埋めてしまっていました。
これらが合わさることで、エンジニアは問題の解決ではなく手動の調整に時間を費やすことになっていました。
ソリューション:Orion AI
Orion AIは、調整役のエージェント(メタオーケストレーター)が、ハブアンドスポーク型トポロジーで配置された専門の子エージェントに作業を委任するマルチエージェントシステムです。エンジニアはWebアプリケーションを通じてこのシステムとやり取りし、既に運用作業の調整を行っている同じ場所で質問を行い、アクションを承認します。エージェントは、インフラストラクチャの監視、データベース診断、データベースのライフサイクル運用、カスタマーアナリティクス、ナレッジドリブンなサポートを担当します。
構築の指針となった2つの原則は、 共有責任モデルに基づくAWSのコントロールを用いたデータプライバシーと、既存の運用ツールとの深い統合でした。Amazon Bedrockが基盤モデルへのマネージドアクセスを提供し、Strands Agentsがオーケストレーション層を提供しました。
結果
Orion AIは、診断の速度と精度の両面で測定可能な改善をもたらし、チームを手動の調整作業から解放しました。手動のボトルネックを自動化し、チーム間のワークフローを合理化することで、Cornerstoneは以下の成果を達成しました。
| 指標 | 導入前 | 導入後 | 改善 |
| データベース診断時間 | 45分 | 10分 | 78% 高速化 |
| 手動のライフサイクル手順 | 10 以上のステップ | 1 回の操作 | 70% の削減 |
SRE-to-data-team レポート作成の遅延 |
15 分 | 即時性 | リアルタイム |
| 重複アラート | 高いベースライン負荷 | フィルタリング済み | 65%削減（中央値） |
パフォーマンス障害切り分けの高速化
データベース診断時間の削減は、Orion AI によるこれまでで最大の単一効率向上でした。以前は、エンジニアが影響を受けた SQL Server インスタンスに手動で接続し、システムビューを照会してブロッキングチェーンや待機タイプを調べ、ログを突き合わせて長時間実行クエリを特定し、証拠を関連付けて根本原因の仮説を構築していました。このプロセスにはインシデントあたり平均約45分かかっていました。
Orion AI では、3つの専用エージェントが調査を分担し、それぞれが異なる段階を担当します。診断にとどまらず、Orion AI は問題を修復まで担当します。根本原因の特定、修正案の提案、適切なオンコールエンジニアに割り当てられた入力済みの Jira チケットの作成です。4ステップの手動ハンドオフが1回のやり取りに集約されます。
データベースライフサイクル管理の自動化
以前は、データベース接続の確立からシステム間クエリの実行、ステータス更新の連絡まで、10以上の手動ステップを必要としていたタスクが、現在では単一の自然言語によるやり取りで実行されます。Orion AI が適切なツールとデータソースを特定し、複数のシステムにわたってクエリを実行し、結果を検証して、統合された応答を返します。エンジニアから見ると、作業は Orion AI へのプロンプト入力と、返される調査結果の検証だけに簡素化されます。
リアルタイム監視とアラート疲労の軽減
Orion AI は15分の SRE-to-data-team レポート遅延を解消し、定期的な手動チェックを継続的なシステム横断的な可視性に置き換えました。
Orion AI は、重複排除、しきい値フィルタリング、およびシグナル間相関によって、重複アラートを中央値で65パーセント削減しました。以前生成されていた10件のアラートのうち、現在エンジニアに届くのは3〜4件のみです。アラートは中間のアラート層を介さず、直接担当チームにルーティングされます。
主要な設計原則
3つの決定が Orion AI を形作りました。これらは読者自身のマルチエージェントプロジェクトにも適用できます。
- タスクの複雑さではなくドメイン別にエージェントを分割する：各エージェントは、1つの運用ドメインに対応する狭い範囲のツール統合を保持します。これにより、モデルのコンテキストが集中し、ツール選択の精度が向上します。1つの汎用エージェントにすべてを任せるのではありません。
- デフォルトではキーワードルーティング、必要に応じてセマンティック検索にフォールバックする：予測可能なリクエストは速度のためにキーワードでマッチングします。曖昧なリクエストは精度のためにセマンティック検索にフォールバックします。これにより、難しいクエリでの正確性を犠牲にせずに、レイテンシーを低く保てます。
- 会話メモリをセッションに限定し、ライブメトリクスではバイパスする：永続メモリはマルチターンの会話をサポートしますが、運用に関する質問では常に現在のシステム状態を読み取ります。ライブメトリクスでメモリをバイパスすることで、古いデータがリアルタイム診断を汚染するのを防ぎやすくなります。
アーキテクチャ概要
Orion AI は、 Amazon Elastic Container Service （Amazon ECS）上のコンテナ化されたサービスとしてデプロイされています。ユーザーは Web アプリケーションを通じてやり取りし、このアプリケーションが各リクエストを適切なエージェントにルーティングし、必要なツールを呼び出し、応答を組み立てます。次の図は、これらのコンポーネントが AWS Cloud 内でどのように接続されているかを示しています。
図1：Orion AI アーキテクチャ：Amazon ECS 上のメタオーケストレーターがリクエストを専用エージェントにルーティングし、エージェントは Portal-Tools MCP サーバーを通じてデータソースにアクセスし、モデル、長期メモリ、検索拡張生成のために Amazon Bedrock を使用する
アーキテクチャ詳細
前述の設計原則は、アーキテクチャの中に具体的に反映されています。このセクションの残りの部分では、Orion AI のコアコンポーネントを順に見ていきます。
Strands Agents を用いたハブアンドスポークパターンの構築
Orion AI は、少数の Strands Agents プリミティブを使ってそのトポロジーを表現しています。 Agent class は、専門エージェントとメタオーケストレーターの両方の構成要素です。各エージェントのツールは、 @tool decorator です。これにより、関数の型ヒントと docstring からツールの仕様が導出されるため、別途管理すべきスキーマが不要になります。 BedrockModel 各エージェントが実行される Amazon Bedrock モデルをラップし、 MCPClient エージェントを外部ツールサーバーに接続します。
トポロジー:
- ハブは、メタオーケストレーター(TaskExecutor)として機能する単一の Strands Agent です。ドメインツールは一切保持せず、ルーティングツールのみを持ちます(
find_relevant_agents,call_agent）と制御フローツール（emit_plan_step,emit_confirmation_gate)そのため、リクエストを段階的に推論することができます。 - スポークは独立しています
Agentデコレータベースのレジストリを通じて遅延ロードされるインスタンス。各インスタンスはそれぞれ独自のモデル、ドメインツール、ローカライズされたシステムプロンプトを持ちます。
実行時、ハブは登録された call_agent ツールです。各スペシャリストは独自のツール呼び出しループを実行し、合成されたテキストをハブに返します。ハブはそれを組み合わせて最終的な応答を組み立てます。
ハイブリッドルーティング
Orion AIは、キーワード優先のルーティングを採用し、フォールバックとしてセマンティック検索を使用します。約80パーセントのクエリは、メモリ内のキーワード高速経路によって1ミリ秒未満で処理されます。キーワードだけでは意図を判定できない場合、システムは以下によって動作するセマンティック検索にフォールバックします。 Amazon Titan Text Embeddings V2 意味によるルーティングを実現します。AWSリージョンごとのモデル提供状況については、以下を参照してください。 Amazon BedrockにおけるAWSリージョン別サポートモデル.
直接ツール呼び出しが適切でない場合、フォールバックチェーンが有効になります。 Amazon Bedrock Knowledge Bases管理型のRetrieval Augmented Generation（RAG）機能である、は運用ドキュメントを検索し、文脈なしに生成するのではなく、承認された手順に基づいた回答を返します。
ドメイン特化型エージェントとその境界線
Orion AIは13のドメイン特化型エージェントを使用します。3つのSQL Serverエージェントは、ドメイン分割が実際の調査の各段階にどのように対応するかを示しています。
- データベース診断エージェント ブロッキングチェーン、待機タイプ、および長時間実行クエリを検出し、技術的な調査結果をビジネスへの影響と改善推奨事項に翻訳します。「何が起きていて、それが何を意味するのか」に答えます。
- セッションブロック分析エージェント 推論モデルを用いた多段階の調査を実行し、ブロッキングの連鎖を根本的なブロッカーまで突き止めます。「なぜこの事象が起きており、根本原因は何か」に答え、即時のセッション終了から中長期的なアーキテクチャの修正に至るまで、優先順位付けされた推奨事項を提供します。
- リアルタイムSQL診断エージェント Cornerstone の DATAOPS API を通じて SQL Server インスタンスに直接問い合わせを行い、リアルタイムのブロッキングデータや高 CPU セッションの分析を行います。つまり「今この瞬間の真実」に答えるものです。
残りのエージェントも、同じく限定された責務の原則に従っています。インフラストラクチャ監視、運用分析、データベースライフサイクル管理、顧客分析、ランブックからのナレッジ検索、通知ルーティング、複合クエリの分解、可用性グループ（Availability Group）リスナーの解決、そしてモデル接続のウォームアップです。
ツール統合とサービス接続性
Orion AIは2つのパターンを通じてデータソースにアクセスします:
- Model Context Protocol(Model Context Protocol) (MCP) 複数のエージェントが共有するツール向けです(例：リアルタイムSQL診断)。Strands
@tool関数は呼び出しますMCPClientStreamable HTTP経由でPortal-Tools MCPサーバーに接続され、そこからSQL ServerとDATAOPS APIに到達します。Jira統合も、外部のAtlassian MCPツールを通じて同じアプローチに従います。 - Direct SDK または REST API 呼び出し 共有MCPインターフェースを必要としないソース向けです。これには、メトリクスやダッシュボード、オンコールスケジュール、そしてAmazon Bedrock Knowledge Bases(経由の接続)が含まれます。 AWS SDK for Python (Boto3).
この分離により、各エージェントはそのソースに適した最も軽量なメカニズムを使用し、MCP サーバーが複数のエージェントで共有されるツールを一元管理します。これらの接続は TLS 上で実行され、MCP トークンや REST API 認可などの資格情報はリクエストごとに供給され、エージェントのコードに埋め込まれることはありません。
会話メモリ
Amazon Bedrock AgentCore「, あらゆるフレームワークやモデルで大規模にエージェントを構築・接続・最適化するプラットフォーム」は、セッションを跨ぐメモリ層を提供します。Orion AI は中央メモリマネージャーを通じてコンテキストを調整し、3つの階層から並行して読み取りを行います。各階層には独自のタイムアウトとトークン割り当てが設定されています。
Orion AIは3つの階層にわたってコンテキストを調整します。短期メモリは同一セッション内のコンテキストを保持します Amazon DynamoDBデフォルトで保存時暗号化されており、ローリング方式の会話サマリーと組み合わせられており、 Amazon Nova 2 Lite は非同期的に生成します。長期メモリは、Amazon Bedrock AgentCore の機能である AgentCore memory を通じてクロスセッションの記憶を提供し、ユーザー ID で名前空間化されます。タスク完了時に、Orion AI は create_event 自動的な抽出、要約、統合を実行させるためのものです。第3の階層であるエージェント間メモリ(inter-agent memory)は、単一のタスク内でサブエージェントのステップ間にわたって調査結果を受け渡す、一時的なインメモリのスクラッチパッドです。
メモリマネージャーは、4,000トークンの予算に対して500ミリ秒のハードタイムアウト以内に各ティアを横断して取得を行い、LRU(Least-Recently-Used)キャッシュに支えられています。リクエストが現在のシステム状態に関するものである場合、エージェントはメモリを完全にバイパスしてライブデータを読み取るため、古いコンテキストがリアルタイムの診断を汚染することはありません。
責任あるAIとガードレール
DataOpsの安全性は、どのデータベース操作が破壊的であるかといったドメイン固有のルールに依存するため、チームは汎用的なコンテンツフィルターに頼るのではなく、カスタムのガードレールロジックを構築しました。Orion AIは4つのレイヤーにわたって制御を適用します:
- プロンプトレベルの安全制約 。すべてのエージェントのシステムプロンプトに注入され、危険な推奨事項(例： 重要なデータベースプロセスの終了)をブロックし、非破壊的な方法を強制します。
- ヒューマンインザループの確認ゲート 。破壊的な操作を、ユーザーが5分以内に確認するまで一時停止し、タイムアウト時にはデフォルトで拒否します。
- 入力検証のためのカスタムガードレールモジュール (長さ制限、プロンプトインジェクションおよびSQLインジェクションのブロック)、出力サニタイズ(シークレットおよび個人を特定できる情報の削除)、レート制限、ロールベースのアクセス制御、リクエストごとのコスト追跡。
- ルーティングレベルの保護 。運用に関するクエリにメモリから回答することをブロックし、現在の状態に関する質問にはライブのツール実行を強制します。
オブザーバビリティ
Orion AIは、モニタリングとデバッグに標準のAWSオブザーバビリティサービスを使用しています。 Amazon CloudWatch は、ルーティングの信頼度、レイテンシー、エージェント呼び出しアクティビティに関するメトリクスと構造化ロギングを提供します。 AWS X-Ray は、エージェント実行全体の分散呼び出しをトレースし、エンドツーエンドのリクエストパスの可視性を提供します。
学んだ教訓
Orion AI を可能にした設計上の決定は、再利用できるものです。エージェントをドメインごとに分割することで、単一のモデルのコンテキストを肥大化させることなく、各エージェントが限定されたツール統合を担えるようになりました。デフォルトでキーワードルーティングを使い、セマンティック検索をフォールバックとすることで、曖昧なリクエストに対する精度を犠牲にせずに低レイテンシーを維持しました。会話メモリをセッション単位に限定し、ライブメトリクスではこれをバイパスすることで、リアルタイム診断の信頼性を保ちました。
チームはまた、実用的なインフラストラクチャの選択も行いました。彼らはコンピューティングを Amazon ECS にデプロイしました。なぜなら、プロジェクト開始時点では Amazon Bedrock AgentCore ランタイムである Amazon Bedrock AgentCore の機能が利用できなかったからです。現在、彼らは将来の移行オプションとしてこれを検討しています。今日構築する場合は、自分のスタックについて同じトレードオフを検討してください。今安定していて利用可能なものから始め、マネージド機能が成熟したら再検討するのです。
結論
Orion AI はデータベース診断を 45 分から 10 分に短縮し、手動のライフサイクルステップの 70 パーセントを削減し、アラートノイズを 65 パーセント減少させました。3 名のチームが Amazon Bedrock 上で 6 か月でこれを提供しました。これらの成果の背後にあるパターンは、他の運用チームも採用できるものです。ドメインスコープのエージェント、ハイブリッドルーティング、ライブメトリクスのバイパスを備えたセッションスコープのメモリです。
AWS でのマルチエージェントオーケストレーションを始めるには、次を参照してください。 AWS Solutions Library のガイダンス.