monday.com、Amazon Bedrockを活用した本番AIエージェントの運用実績を公開　開発者のPRスループットが5割以上向上

要点

• タスク管理ツールを展開するmonday.comが、Amazon Bedrock上で動作する本番AIエージェントの運用規模とアーキテクチャを公開した。
• 同社内では開発者の90%が毎月AIコーディングツールを利用しており、エンジニア1人あたりのプルリクエスト送信数が50%以上向上した。
• 社内エージェントシステム「Sphera」では、AIエージェントが人間と同じチームメンバーとして扱われ、同一のタスクリストを共有している。
• Slack、GitHub、monday.comの3つの窓口からの要求を、単一のエージェントシステムで統合して処理するアーキテクチャを採用している。

リード文

クラウド型タスク管理ツールを提供するmonday.comは2026年7月22日（現地時間）、Amazon Web Services（AWS）の生成AIサービス「Amazon Bedrock」上で動作するAIエージェントを本番環境で大規模運用している実績と、そのシステムアーキテクチャをAWS ML Blogを通じて明らかにした。同社の報告によると、AIツールの導入によりエンジニア1人あたりのプルリクエスト（開発者が作成したコードの変更を本番環境へ統合するために送る要求）の処理能力が大幅に向上しているという。本番環境へのAIエージェント統合は、10年以上運用されてきた既存の巨大なコードベース（プログラム群）を改修する形で行われた。

本文

10年物の巨大システムへのAIエージェント導入

monday.comは、新規の小規模なシステムではなく、数百万人の有料ユーザーと数百のマイクロサービス（大規模なシステムを、独立して動作する複数の小規模なサービスに分割して構築する開発手法）を抱える歴史ある大規模コードベースに対してAIエージェントを導入した。数百人規模のエンジニア、プロダクトマネージャー、アナリスト、デザイナーが在籍する同社では、稼働中のシステムを維持しながらAIエージェントを稼働させることが極めて重要だったと説明している。

同社におけるAI活用の進展は、以下の3つのレベルに分類されている。

• レベル1（アシスタント）: 開発者がペアプログラマー（二人一組で共同してプログラミングを行う開発の役割）としてAIを使用する段階。同社では、反射的で素早い作業には「Cursor」、負荷の高い作業には「Claude Code」を使い分けており、利用率は前年比でほぼ倍増した。
• レベル2（スキルとサブエージェント）: チームが繰り返し発生する定型業務のために、再利用可能なエージェントを構築する段階。開発者が主導権を握るこの段階において、開発者個人のプルリクエストのスループットが50%以上向上した。
• レベル3（マルチエージェント）: エージェントがタスクの引き受けからコードのデプロイ（開発したプログラムを実際のサーバー環境に配置して利用可能にすること）までをエンドツーエンドで自律的に担当する段階。エンジニアはエージェントの調整役に回り、エージェントはSlackやmonday.com上で人間と対話しながら業務を進める。

人間と並ぶチームメイトとしてのAIエージェント「Sphera」

monday.comが構築した社内のエージェントシステム「Sphera」では、AIエージェントを単なる作業キュー（処理待ちのタスク一覧）ではなく、人間のメンバーと同等の「チームメイト」として定義している。
Spheraのチームページには人間とAIエージェントが混在してリストアップされており、それぞれにプロフィール、マネージャー、担当範囲、およびパフォーマンススコアが割り当てられている。

例えば、同システム内で稼働する「Atlas」というソフトウェアエンジニア向けエージェントは、特定の開発環境を持たず、人間のエンジニアと同じバックログ（システム開発において優先順位付けされた未処理のタスクリスト）からチケットを自律的に取得し、プルリクエストを作成して機能をリリースする役割を担う。エージェントはSlack、GitHub、monday.comなどのツール上で固定の識別情報（アイデンティティ）を持ち、人間のチームメンバーは通常の人材と同様に、エージェントへタスクを割り当てたり、コードレビューを行ったり、必要に応じてエージェントの活動を一時停止したりすることができる。

3つの窓口を統合するアーキテクチャとAWSの連携

monday.comが開発したエージェントは、3つの主要なインボックス（窓口）を持つ。これらは、Slackでの「@メンション」、monday.comの「アイテムへの割り当て」、そしてGitHubでの「プルリクエストレビュー要求」である。これら異なるソースからの要求は、すべて同じエージェントの実行セッションに送られ、ディスク上の共通のメモリやワークスペースを利用して同一の処理フローで処理される。つまり、用途別に複数のエージェントシステムを立ち上げるのではなく、単一のシステムで効率的に運用している点が特徴である。

アーキテクチャの構成によると、これらのイベントは、AWSの通知サービス「Amazon SNS」を起点として、チームごとのキュー（処理待ち行列）を管理する「Amazon SQS」へと流れる。その後、コンテナ（アプリとその実行に必要な環境をパッケージ化して動作させる技術）管理サービスである「Amazon EKS」上で動作するコンシューマーによってイベントが処理され、データベースサービスの「Amazon RDS」やインメモリキャッシュ（データをメモリ上に保存して高速に読み書きする仕組み）の「Amazon ElastiCache」、共有ファイルシステムの「Amazon EFS」、ストレージの「Amazon S3」などと連携しながら、エージェントの実行環境が動作する仕組みとなっている。