どのエンジニアリングチームも知っている儀式があり、Rescaleも例外ではありませんでした。夜間のテストスイートが失敗する。オンコールのエンジニアがログを引き出し、根本原因を分類し、適切なチームに振り分ける――そして翌朝、同じ作業を繰り返す。分散型サービスと数十のリポジトリにまたがる大規模環境では、この儀式がオンコールのローテーションの中に隠れた常駐業務へと変わってしまうのです。
Rescale は、AI時代のために構築されたデジタルエンジニアリングプラットフォームです。航空宇宙、自動車、エネルギー、ライフサイエンス、半導体、製造業の各分野の研究開発およびエンジニアリングチームは、Rescaleプラットフォームを活用してイノベーションを加速させ、インテリジェントHPC、高度なモデリングおよびシミュレーション、エージェント型デジタルエンジニアリング、AI物理を単一のプラットフォーム上に統合しています。
コーディングにとどまらず、Rescaleは計画、設計から実装、テスト、レビュー、運用に至るエンジニアリングのライフサイクル全体でAIを活用していますが、その結果に対する責任はエンジニアが負います。AIは提案し実行することはできますが、範囲を定め、成果物を検証し、本番環境への変更を承認するのは人間です。それにより、エンジニアはアーキテクチャ、プロダクトの判断、そして複雑な分散システムを運用するために必要なコンテキストに集中できます。
この投稿では、Rescaleがどのように AI駆動開発ライフサイクル(AI-DLC) AWS上のフレームワークを使ってインテリジェントなトリアージエージェントを構築しました。彼らは問題定義からステージング環境へのデプロイまで5日で、本番環境への展開まで数週間で到達しました。この投稿では、RescaleがAI-DLCをエンジニアリング組織全体にどのように拡張しているかについても取り上げています。
課題
Rescaleのプラットフォームが成長するにつれ、それを稼働し続けるための運用負荷も増大していきました。エンジニアたちは、反復的でありながら重要なタスク、すなわち自動化されたエンドツーエンドテストの失敗の分類に、多くの時間を費やしていました。スイートでは何百ものテストケースが実行され、失敗が発生すると、すべてのアラート、バグレポート、エスカレーションを分類し、優先順位を付け、適切なチームに振り分ける必要がありました。振り分け後、エンジニアはデバッグを始める前の段階として、複数のロギング・監視システムやいくつかのソースリポジトリから証拠を集める必要がありました。エンドツーエンドテストに合格することが本番環境へのサービスのデプロイの条件であったため、こうしたシステム障害のデバッグは、新たな変更を本番環境に届けるためのクリティカルパス上にありました。
手動のワークフローでは、エンジニアはテストレポートからログ、過去のパターン、ソースコードへと辿って障害を分類し、担当チームの見当をつけていました。これらの統合テストは週次の本番リリースのゲートになっているため、未解決の障害があると、デプロイが許可されるまでに複数のチームを数時間にわたる調整へと巻き込む可能性がありました。
チームには、どのような解決策が望ましいのか明確なイメージがありました。それは、課題を自動的に分類およびルーティングできるインテリジェントエージェントです。彼らが求めていたのは、その理解から本番環境で動作するシステムへと進むための構造化された方法、しかもその後、このアプローチを他のユースケースに拡張できるだけの十分な構造を備えた方法でした。
なぜRescaleはAI-DLCを選んだのか
Rescaleのトリアージエージェントは、厳しいタイムラインを持つ、範囲が明確に定められた課題でした。チームには、そのペースに合わせて進めながらも、システムが本番環境で機能するかどうかを左右するアーキテクチャ上の決定を見過ごさない開発アプローチが必要でした。
The AI駆動開発ライフサイクル(AI-DLC) は、2つのアイデアを軸に構築された、オープンソースのAI中心のソフトウェア開発手法です:
- AIが実行し、人間が決定する:AIは作業計画の作成、コードの記述、アーキテクチャの提案を行いますが、推測で進めるのではなく、決定ポイントを明示し、確認のための質問を投げかけます。人間は各ステップで検証し、方向付けを行います。
- チームセッションが非同期の引き継ぎに取って代わります。1人だけで構築し、後からレビューを依頼する代わりに、AI-DLCでは集中したグループセッションを用います。Mob Elaboration(一緒に要件を定義する)とMob Construction(AIが実装を担当する間に一緒に構築する)です。意思決定はリアルタイムに行われます。
AI-DLCが適していたのは、難しい部分がコードを書くことではなかったからです。難しかったのは、AIにチームが何を構築したいのかを確実に理解させることでした。モブセッションでは、RescaleのエンジニアがAIの質問に一緒に答え、AIが次に進む前に各計画を承認したため、何も推測のまま放置されることはありませんでした。
ソリューション概要
Rescaleのトリアージエージェントは、夜間に実行されるエンドツーエンドテストの失敗の分類とルーティングを自動化します。これは、Amazon Elastic Kubernetes Service（Amazon EKS）上のRescaleの既存のArgo Workflowsによる継続的インテグレーション／継続的デリバリー（CI/CD）パイプライン内のステップとして実行されます。数百のテストケースからなる夜間のPlaywrightスイートで失敗が発生すると、パイプラインがトリアージエージェントのPodを起動します。
エージェントは以下の手順を実行します:
- Amazon Bedrock上でClaude Opus 4.8を呼び出し、各障害を根本原因カテゴリ(インフラ問題、コードのバグ、不安定なテスト、環境問題)に分類します。
- ナレッジベースから関連する過去の障害パターンを取得し、追加のコンテキストとして利用します。
- 分類を裏付ける実行時のエビデンスを得るため、Model Context Protocol (MCP) を通じてポッドのログを照会します。
- エンジニアが対応前に確認できるよう、具体的なファイル参照、関数名、推奨修正内容を含む構造化された是正レポートを生成します。
エージェントはこのワークフローを数秒で完了し、チームの既存のレポーティングパイプラインに直接出力します。次の図は、これらのコンポーネントがどのように組み合わされているかを示しています:
図1: RescaleのAIトリアージエージェントのアーキテクチャ。Amazon EKS上で稼働し、分類にはAmazon Bedrock、過去の障害パターン用のナレッジベース、Amazon CloudWatch連携を通じたMCPベースのログ取得を利用
AI-DLC ワークショップの体験
この取り組みは、5日間の対面ワークショップとして実施されました。AWSのアーキテクトがビルドをガイドし、Rescaleのエンジニアが自らキーボードを操作して、リアルタイムで共同構築を行いました。
inception フェーズ(1〜2日目): ビジョンから検証済み要件へ
チームはまず要件のスコープ定義から始め、ビルドを開始する前に、インテントをビジョンドキュメントと技術環境ドキュメントに記録して作業の基盤を固めました。そのインテントは「AIを活用したテストトリアージにより、障害を分類し、修復方法を推奨したい」という一文から始まりました。モブ形式で協働しながら、チームはAIが生成した20以上の明確化質問に回答しました。その結果、Phase 1の境界が明示的に定義され、Phase 2の項目が先送りされた、スコープ化された要件ドキュメントが作成されました。5つのユーザーストーリーが4つの作業単位に統合されました:
- 過去の障害パターン用のナレッジベース。
- 中核的な分類および修復エンジンとしてのAIトリアージエージェント。
- トリガー、インフラ、デプロイのためのArgo Workflow統合。
- 精度測定とリグレッションゲーティングのためのEvaluation Harness。
重要な境界は人間の意思決定が担いました。Phase 1とPhase 2のどちらに属するか、優先順位の付け方、そして自動プルリクエスト(PR)生成のような先送りされた機能です。
Construction フェーズ(2〜4日目): アーキテクチャから動作するコードへ
チームはインターフェース契約とデータスキーマを定義し、機能要件および非機能要件の設計上の質問を完了させ、アーキテクチャを承認しました。ビルド中に2つのアーキテクチャの方向転換が発生しましたが、チームはそれぞれ変更前に検証を行いました。
1つ目は、当初チームはエージェントをAmazon Bedrock AgentCoreでホストする予定でしたが、RescaleがすでにArgo WorkflowsのCI/CDパイプラインを稼働させているAmazon EKSに移行しました。エージェントを既存のクラスターに置くことで、運用すべき新しいランタイムが不要になり、Argoからの直接的なトリガーパスが得られました。2つ目は、初期のビルドではエージェントがMCPを通じてサードパーティのロギングサービスからログエビデンスを取得していた点です。チームはログ取得をAmazon CloudWatchに移行し、依存チェーンを簡素化しました。MCPのパターンは同じままで、背後のソースだけが変わりました。AI-DLCは要件と設計の決定を共有ドキュメントに保持するため、チームはそれらをその場で更新し、コンテキストを失うことなく構築を続けました。
エージェントはStrands SDKを使用して構築され、JSONおよびHTMLでの構造化出力を伴う並行障害分析をサポートし、Amazon EKS上でコンテナ化されました。
4日目までに、完全なパイプラインがステージング環境で稼働しました: Argoワークフロートリガー、トリアージエージェントPod、MCPログクエリ、ナレッジベース検索、そして構造化されたトリアージ出力です。
Operations フェーズ(5日目): 評価と引き継ぎ
チームはライブモードとスタブモードを備えたPyTestベースの評価フレームワークを構築し、エージェントの測定と改善の基準となる初期の分類一致率ベースラインを確立しました。エージェントはRescaleのCTOとエンジニアリング担当VPに対してライブでデモされ、インフラ障害と実際のコードバグの両方を、具体的なファイルレベルの修正提案付きで正しく分類しました。
AI-DLCが複雑さに応じた厳格さを拡張した方法
すべての作業単位が同じ扱いを受けるわけではありません。ナレッジベースは最小限の設計で済み、Terraformを使用して数時間でデプロイされました。トリアージエージェントには完全な厳格さが適用されました: アーキテクチャレビュー、インターフェース契約、12の設計質問、そして反復的なコードレビューです。Argo統合はインフラ契約とIAMに焦点を当てました。Evaluation Harnessは軽量な設計と重量級の実装を使用しました。AI-DLCは深さを複雑さに自動的に適合させました。
5日目の終わりまでに、エージェントはステージング環境で稼働し、測定された精度ベースラインと本番環境への明確な道筋を持って、実際のテスト障害を処理していました。
本番環境での成果
トリアージエージェントはワークショップ以降、本番環境で稼働しています。夜間のエンドツーエンドテストの障害を自動的に分類し、手動の一次トリアージを、エンジニアが検証する自動化された一次処理に置き換えています。各障害について、エージェントは生のログではなく、実行可能な次のステップを含む構造化された修復レポートを生成します。エージェントの人間のトリアージとの分類一致率は、初期デプロイ時の44%から現在は68%に上昇しています。チームがゴールデンデータセットとプロンプトエンジニアリングを繰り返し改善するにつれ、さらに向上し続けています。
トリアージエージェントが本番環境に投入されて以来、テスト障害の分析中に本番デプロイをブロックする時間が20%減少したことをチームは測定しています。これらのテストはRescaleの週次本番リリースのゲートとなっているため、この削減は変更が本番に到達する速さに直接反映されます。エンジニアはオンコールローテーションにおいても、反復的な分類作業に費やす時間が減っています。
ワークショップ後の生活: 1つのエージェントからAIファーストの実践へ
ワークショップは1つの本番エージェントをもたらしましたが、より大きな効果はRescaleがエンジニアリング業務に取り組む方法に及びました。トリアージエージェントは、AI時代に向けたデジタルエンジニアリング機能を提供するというRescaleのより広範な取り組みの一部です。社内では、RescaleはAIから得られたこれらと同じメリットを自社のエンジニアリング組織全体に適用しています。AI-DLCは、Rescaleのエンジニアにその方向性を実践に移すための構造化された再現可能な方法を提供しました。
組織全体へのAI-DLCの拡大
Rescaleは社内のAI-DLC Center of Excellenceを評価しています。これは、ベストプラクティスを成文化し、他のチームが独自にこの方法論を採用できるよう支援する小規模なグループです。
参加したエンジニアはすでに学んだことを実践に応用しています。あるエンジニアは、このプロセスは「今後のワークフローの一部になる」と述べ、エージェントの構築だけでなく、AIが貢献できるあらゆる複雑な開発作業にも適用されるとしています。
より広範なAIネイティブ開発
Rescaleは現在、新しいエンジニアリングシミュレーション製品向けの標準的なソフトウェア開発ライフサイクルにAI-DLCを組み込んでいます。このフレームワークは、シミュレーションドメインの専門知識、製品要件、プラットフォームアーキテクチャ、検証、運用を1つの構造化された設計プロセスにまとめます。チームは重要な問いに早期に答え、レビュー済みの決定を実行可能な仕様として記録し、明確な受け入れ基準とともに焦点を絞った作業をコーディングエージェントに任せます。これにより、エンジニアが製品の正確性に対する責任を負い続けながら、製品の構想から検証済みの実装までの道のりが短縮されます。
同じアプローチは、製品を支えるプラットフォームの作業やエージェントシステムですでに活用されています:
- HPCシミュレーションアプリケーションカタログの管理。
- 政府のコンプライアンス要件に対応したコンテナの脆弱性追跡と修復。
- ワークフローベースのクラウドコーディングエージェント。
まとめ
トリアージエージェントにとって、AI-DLCの最も有用な成果物はコードそのものではありませんでした。それは、最初のアイデアからレビュー済みのシステム設計までの構造化された道筋、つまり明確化のための質問、範囲を限定した要件、評価基準でした。
その仕様により、コーディングエージェントにはより狭く、より明確に定義された解決すべき問題が与えられました。アーキテクチャを実装しながら推測させる代わりに、チームは人間がすでにレビューした決定に基づく焦点を絞った構築作業にエージェントを活用できました。その結果、より焦点が絞られ、レビューしやすく、統合や改善が容易な成果物が得られました。Rescaleにとって、これが再現可能なパターンです。AI-DLCを使って設計の議論を構造化し、その決定を仕様に変換し、そしてコーディングエージェントを使って実装を加速させるのです。
主なポイント
- 実際の問題から始める。 Rescaleのトリアージエージェントが成功したのは、エンジニアリングの課題を解決したからです。解決策ではなく問題が主導しました。
- 人間の監督は加速をもたらし、減速をもたらしません。 システムを改善したすべてのアーキテクチャの転換は、AIの提案に対する人間の検証から生まれました。AIが生成し人間が検証するモブ形式は、単独で作業するよりも速いものです。
- AWSスタックはエージェントに必要な各レイヤーを提供しました。 Amazon Bedrockは、Rescaleがすでに利用していた環境において分類のための基盤モデルへのアクセスを提供したため、チームは追加のモデルインフラストラクチャの負担を負うことなくトリアージワークフローを構築できました。Strands SDKがエージェントフレームワークを提供し、Amazon EKSがコンテナ化されたエージェントをRescaleの既存のパイプライン内でホストしました。
AI-DLCを始める
- 手法を理解する: 以下を読む: AI-DLCの紹介ブログ および アダプティブワークフローの詳細解説.
- サービスを調べる: Amazon Bedrockの詳細を見る.
- 今すぐ試す: オープンソースのAI-DLCワークフロールールをクローンする: github.com/awslabs/aidlc-workflows.
- 実際の活用を見る: 以下を参照: Amazon Q Developer を使った実践的な AI-DLC ビルド.
- つながる: AWSのアカウントチームに連絡し、AI-DLCを貴社の具体的なエンジニアリングワークフローに合わせて調整する方法についてご相談ください。