monday.comの開発チームで働くBedrockエージェント

monday.comは、Amazon Bedrockを使うAIエージェントを既存の開発チームへ組み込んだ本番アーキテクチャを公開しました。

要点

• Slack、monday.com、GitHubからの依頼を一つのエージェントセッションへ集約します。
• SNS、SQS、EKS、RDS、ElastiCache、EFS、S3を組み合わせ、再試行と永続実行を支えます。
• エージェントには名前、役割、管理者、担当範囲、成績を持たせ、人と同じバックログで管理します。

今回のブログ記事で語られていること

monday.comは、数百のマイクロフロントエンドとマイクロサービスを持つ十年規模のSaaSでAIエージェントを運用しています。社内のSpheraでは、エージェントを単なるジョブではなく、役割、マネージャー、担当範囲、成績を持つチームの一員として表現します。中心例のAtlasはソフトウェアエンジニアとしてチケットを受け、コードを書き、PRを作ります。Slackのメンション、monday.comのアイテムの割り当て、GitHubのレビュー依頼は別システムにせず、同じ記憶と作業領域を持つセッションへ入ります。

外部イベントはSNSからチーム別SQSへ配信され、EKS上の実行基盤が担当エージェントを解決します。この構成により、再試行、デッドレターキュー、Bedrockの流量制限時の逆圧、イベント再生、並行処理を扱えます。RDS、ElastiCache、EFS、S3が状態や作業データを支え、Secrets Managerがセッション別の秘密情報を管理します。モデル呼び出しはBedrockへ送り、ClaudeエージェントSDKを薄い社内SDKで包みます。

導入は、補助、再利用可能なSkillsとサブエージェント、複数エージェントによる一貫配送という三段階で説明されます。公式記事は開発者一人当たりのPR量が半分以上増えたとしますが、重要なのは数字だけではありません。実サービスでは、同じイベントの再送、モデル制限、失敗PR、秘密情報、権限、評価責任を設計する必要があります。自社で試す場合は、読み取りや下書きから始め、誰がエージェントを停止できるか、失敗をどこへ戻すかを明確にしてください。エージェントをチームの一員として扱うなら、停止権限と失敗時の責任分界も人の役割と同じように定義する必要があります。

今回のブログ記事が関係する人

大規模SaaSの開発基盤担当、Bedrock利用チーム、AIエージェントの権限と評価を設計する管理者に関係します。

結局、今回のブログ記事をどう読むべきか

モデル選択より、イベント、状態、責任を既存組織へ接続する実装例です。人と同じ入口で働かせるなら、同じ監査と停止手段も必要です。