monday.com、Bedrock で AI エージェントを運用

AI ティーメイトは、Amazon Bedrock 上で動作する自律型 AI エージェントです。monday.com のように、本番環境でこれほどの規模で運用しているエンジニア組織はそう多くありません。

先般の半年前と比較すると、今ではエンジニアの 9 割が毎月 AI コーディングツールを利用しています。1 人あたりのプルリクエスト（PR）処理量も半分以上増加しました。この記事で紹介するすべての数値は、monday.com の内部で実際に収集された本番環境データに基づいています。

ここでは、これらの成果を支えるアーキテクチャと、10 年以上の歴史を持つ既存コードベースへの導入プロセス、そして完全な自律化に向けたギャップを埋めるための「自信スコア付きマージ戦略」について解説します。

これはゼロからの開発ではない

monday.com のコードベースはすでに 10 年の歳月を重ねており、数百万人の有料ユーザーを抱え、数百ものマイクロフロントエンドやマイクロサービスが稼働しています。エンジニア、プロダクトマネージャー、アナリスト、デザイナーなど「ビルダー」と呼ばれるメンバーも数百名に及びます。

AI エージェントが作成した PR は、次のデプロイでもシステムが確実に動作し続けることを期待する数百万人のユーザーの目に触れることになります。新規プロジェクト（グリーンフィールド）でのデモは容易ですが、オンコール体制や顧客対応、コンプライアンス要件を伴うエンタープライズ SaaS 環境でエージェントを実行することは、それとは次元の異なる難易度です。

AI エンジニアリングの 3 つの段階

この取り組みは、以下の 3 つのレベルとして捉えることができます：

L1 はアシスタントです。エンジニアは AI をペアプログラマーとして活用しています。素早い反復作業には Cursor を、重厚な処理には Claude Code を使い分けています。採用数は前年比でほぼ倍増しました。

L2 はスキルとサブエージェントです。チームは繰り返し作業用の再利用可能なエージェントを構築し、エンジニアが主導権を握ります。現在 monday.com の運用の大部分がこのレイヤーで行われており、開発者あたりの PR 処理量が半分以上向上しました。

L3 はマルチエージェントです。完全に自律したエージェントが、工程全体を責任持って担当します。エンジニアは調整役として、ボードからタスクを引き受け、Slack や monday.com でコミュニケーションを取りながら、人間と共にコードをリリースします。

エージェントは同僚であり、職ではない

Sphera は monday.com 内部のエージェントシステムです。最初に目に飛び込んでくるのはジョブキューではなく、「チーム」ページです。そこには人間とエージェントが混在し、それぞれにプロフィール、管理者、担当範囲、パフォーマンススコアが設定されています。本稿の中心となる Atlas もその一人であり、役割は「ソフトウェアエンジニア」、業務は「チケットを引き受け PR を作成し機能をリリースする」、IDE は不要で、他のメンバーと同じバックログを共有します。

これは単なる飾りではありません。これが基本スキーマです。すべてのエージェントには一貫したアイデンティティがあり、Slack、GitHub、monday.com を通じて流れます。そのため人間は、他の同僚と同様に、タグ付けや割り当て、コードレビュー、あるいは無効化を行うことができます。実際に成果を生み出すエージェントは、本物のチームに所属し、本質的な業務を遂行し、結果に対して責任を負います。

システムアーキテクチャ

このシステムは、エージェントが監視する受信トレイから、各イベントを運ぶ AWS サービスに至るまで、どのように連携しているのかを以下に示します。

3 つの受信トレイと 1 つのエージェント

monday.com が構築したエージェントには、主要な 3 つの受信トレイが用意されています。Slack のメンション、monday.com のアイテム割り当て、そして GitHub の PR（プルリクエスト）レビュー依頼です。これら 3 つはすべて同じエージェントセッションに到達し、ディスク上のメモリとワークスペースも共有されます。つまり、異なる形式のイベントであっても、キューや処理パスは共通です。私たちは 3 つのエージェントシステムを並行して運用しているわけではありません。1 つのシステムで全てを処理しています。

アーキテクチャをまとめた図

私たちが利用した AWS サービスは以下の 7 つです。Amazon Simple Notification Service (Amazon SNS)、Amazon Simple Queue Service (Amazon SQS)、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Relational Database Service (Amazon RDS)、Amazon ElastiCache、Amazon Elastic File System (Amazon EFS)、そして Amazon Simple Storage Service (Amazon S3) です。これらに加えて、AWS Secrets Manager がセッションごとのシークレット管理を担当します。モデルへの呼び出しは Amazon Bedrock が処理し、各エージェントランナーのポッド内では monday-agent-sdk が稼働しています。

イベントパス：SNS から SQS、そして monday Builders CoWORK へ

外部からのトリガーはすべて SNS に着信し、トピックとルーティングキーに基づいて各チーム専用の SQS キューに配信されます。EKS 上で稼働する *monday Builders CoWORK* はこれらのキューからメッセージを引き出し、どのエージェントが担当するかを特定した上で、適切なエージェントランナーのポッドへ転送します。

この Pub/Sub とキューを組み合わせたアーキテクチャには、手放せない 4 つの利点があります。まずは、標準でリトライ機能とデッドレターキューが用意されている点です。次に、Amazon Bedrock がスロットリング（処理制限）を行った際にバックプレッシャーをかけることができる点、パッチ適用後のビルドに対して過去 1 日分のイベントを再実行してプロモーション前に検証できる「永続的な再生」機能、そして並列でのファンアウト処理が可能です。もし Claude Agent SDK のランタイム層でより優れた仕組みが登場すれば、自前の実装は削除します。ただし、このハッチ（枠組み）自体は維持し続けます。

monday-agent-sdk：意図的に薄く設計されたラッパー

Claude Agent SDK が実行時の基盤となりますが、私たちはあえて 3 つの理由からその周りをラッパーで包んでいます。

• 呼び出し元でのプロバイダー中立性の確保：エージェントによる LLM の呼び出しは、Amazon Bedrock のモデルエンドポイントへルーティングされます。
• コールドスタートコストの削減：ランナーにはウォームアップ済みの node_modules とプラグインキャッシュが同梱されているため、最初のモデル呼び出しは通常 1 秒未満で完了します。
• 独自のハッチ（枠組み）の実装：実行環境自体はコモディティ化されつつありますが、ハッチこそが私たちの考え方が反映される場所です。ここではエージェントの評価方法やプラグインの組み合わせ方、Slack や monday、GitHub との連携方法、そして出力が monday の基準に合致しているかのレビュープロセスなどを定義しています。実行環境については他者に任せる一方で、このハッチは自社のものとして維持・管理します。

ステート、メモリ、セッション

エージェントには少なくとも三種類のステートが存在します。これらすべてを一つのストレージに格納すると、コスト、レイテンシ、あるいは正し性のいずれかが犠牲になります。

ライブなステートは Amazon ElastiCache へ移行しました。ここでは、現在のタスク、実行カーソル、分散ロック、ハートビート、そしてエージェントと人間のメッセージログを管理しています。サブミリ秒での読み取りが可能で、キーには自己期限設定も可能です。Amazon DynamoDB でも対応可能ですが、このアクセスパターンにおいては ElastiCache の方が安価かつ高速です。

セッションとメモリは Amazon Elastic File System (EFS) に保存されます。各アクティブなセッションは、共有ファイルシステム上のディレクトリとして表現されます：

/sessions//

├── repos/ # チェックアウトされたワークスペース

├── secrets.json # セッションごとに暗号化されたシークレット

└── messages/ # 時系列のイベントログ

/agents//

├── MEMORY.md # セッション横断型のメモリ

└── diary/2026-04-21.md # 日付ごとのジャーナル

S3 を使わないのには二つの理由があります。第一に、Claude Agent SDK とほとんどのプラグインは、git や npm、ファイル編集などを扱うために、本物の POSIX ファイルシステムを前提としています。これにより、「開発環境では動くが、ワーカー環境で壊れる」というバグのクラスを根本から排除できます。

第二に、実行が別の EKS ポッド上で再開された場合でも、そのポッドは同じ EFS パスをマウントして、中断した場所から継続して処理を進めることができます。

Atlas のデイリー・ダイアリーも実在するファイルです。以下はその一部（機密情報を伏字にしたスニペット）：

diary/2026-04-21.md

進行中のタスク

• ENG-3491: レート制限ヘッダーの確認。ステージング環境で検証し、その後 PR を公開する。
• ENG-3502: 依存関係の更新。Guardrails のセキュリティ境界ルールに関する標準オーナーからのレビュー待ちのためブロック中。

前回セッションで学んだこと

• accounts-api チームは、PR を開く前に必ず新しいエラーコードを共有レジストリに登録します。前回は同じ PR に含めていたため却下されましたが、今回は登録処理を先に完了させました。このファイルこそが、Atlas が翌朝に作業を再開する際の根拠となります。Atlas はそのファイルを確認し、「accounts-api チームはエラーレジストリの更新を別個に行うべきだ」という過去の合意を思い出して、作業を開始します。

記憶はディスク上のファイルとして保存され、複数のポッドがマウントして共有できます。

永続的な記録は S3 に格納されます。最終的なトランスクリプト、スナップショット、アーティファクト、評価結果はすべてセッション ID をキーとして管理されています。EFS は作業用メモリ（ワーキングメモリ）を保持し、S3 が監査証跡の役割を果たします。

モデルファブリックとしての Amazon Bedrock

Amazon Bedrock は単にトークンを提供するための場所ではありません。コスト、安全性、キャパシティを管理しながら数百ものエージェントを実行できるサービスです。スケールした環境でエージェントを展開する際の運用要件の多くは、すでに Amazon Bedrock の機能として備わっています。

• アプリケーション推論プロファイルはすべてのモデル呼び出しをルーティングするため、コスト追跡とキャパシティプランニングを一箇所に集約できます。

• すべてのモデル呼び出しに対する監査証跡が一元化されます。セキュリティ担当者や規制当局から「特定の時間帯にエージェントがどこへ何を送信したか」と問われた際にも、一箇所で回答可能です。

• AWS リージョンのレート制限発生時にはクロスリージョンフェイルオーバーを自動実行します。エージェント側のコードには一切影響を与えません。

• AWS PrivateLink エンドポイントにより、モデル間の通信トラフィックは仮想プライベートクラウド（VPC）内部に閉じ込められます。

EKS 上で稼働中

計算リソースの基盤は Amazon EKS です。アクティブなエージェントセッションごとに 1 つの Pod を起動し、そのセッション用の EFS ワークスペースをマウントします。クラッシュ時の隔離もセッション単位で行われます。オートスケーリングは KEDA（Kubernetes-based Event Driven Autoscaler）によって制御され、Datadog で計測した Pod 全体の平均アクティブセッション数に基づいて実行されます。ワーカーイメージは単一に統一しています。リポジトリは EFS にキャッシュされ、セッション間で再利用されます。サービスメッシュやオーケストレーターをさらに管理する層は導入していません。負荷分散は EKS、SQS、そしてキャッシュレイヤーが担っています。

すべてを機能させた 5 つの改修

アーキテクチャは土台に過ぎません。以下に挙げる 5 つの改修こそが、10 年以上前のコードベースの中でエージェントを実用的なものにした要因です。どれも特殊な技術ではありません。しかし、実際に直面するまでその重要性には気づかない、いわば「見落としがちだった」ポイントたちでした：

アップグレード前の評価

アトラスの初期の PR には「見た目問題なし」が基準でした。しかし、処理量が増えるとすぐに不具合が発生しました。そこで導入したのが 2 つの評価レイヤーです。1 つ目は各エージェントごとの決定論的指標（マージされた PR の数、リバーター率、自動マージ率）で、2 つ目は各 PR に対する LLM による評価です。評価は「意図と判断」「実行と成果物」「完全性と有用性」「指示と境界条件」「効率性」の 5 つの次元で行われます。これら両方の結果がハッチ（評価環境）にフィードバックされます。

アトラスのバージョンを順次更新する過程で、モデルもプロンプトも人間の介入も一切変えていません。評価基準だけを変更したところ、すべての次元でスコアが向上しました。

メモリはベクトルストアではなくファイル

セッション 1 でアトラスが機能を実装しても、セッション 2 ではその事実を覚えていませんでした。過去のトランスクリプトにコンテキストを追加したり、ベクトル検索を行ったりしましたが、どちらもうまくいきませんでした。

実際に効果を発揮したのは、各エージェント専用の「MEMORY.md」と、セッション終了時に作成され、次の開始時に読み込まれる「diary/YYYY-MM-DD.md」です。埋め込み（embeddings）も、想起スコアリングも、エージェント型 RAG の複雑な手続きも不要です。ただのプレーンテキスト Markdown ファイルで十分でした。

人間のレビュー前のリモートサンドボックス

アトラスが作成した最初の dozen の PR はローカルテストでは通過しましたが、CI（継続的インテグレーション）環境では壊れていました。monday.com 規模のコードベースには、実際の環境にしか存在しない依存関係があるからです。例えば機能フラグやサードパーティ製サービス、本番トラフィックなどがそれです。

そこで、セッションごとにアトラス用のリモートサンドボックスを用意し、すべての PR を自動的にそこにデプロイするようにしました。人間のレビューを依頼する前に、テスト、チェック、そして再現された本番トラフィックが実行されます。もし不具合があれば修正して再度デプロイするまで、人間の介入は一切ありません。

PR ガイドライン：monday の基準に対する自動レビュー

Atlas のリリース頻度が高まるにつれ、人間のレビューがボトルネックになっていました。そこで私たちは、monday のエンジニアリング標準をすべて自動化されたレビュアーに変換しました。具体的には、メトリクスのタグ付け、フィーチャーフラグの整理、Datadog の活用、セキュリティ境界の設定、データベースおよびマイクロサービスの規約、テスト品質、ドキュメントなどです。これらの項目の一部は必須（ブロック）要件となっています。各基準は、monday の MCP サーバーを通じて内部ナレッジと連携しており、レビュー担当者は標準を策定したチームと同じ文脈を確認できます。

すべての PR は、エージェントが作成したものも人間が作成したものも問わず、Guardrails を通過する必要があります。大規模な運用では、月間数万件の PR が評価され、数十万件の基準チェックが実行されます。約 5 件に 1 件の PR が少なくとも一つの基準に抵触して却下され、人間の承認（オーバライド）が必要なケースは数件程度です。このシステムは、基準の適用を人間ではなく自動で管理しています。

Builders CoWORK：共有状態レイヤーとしての monday ボード

最もコストのかかる失敗事例の一つが、孤立したエージェントが誰も所有していない PR を作成してしまうというものでした。これを解決するため、CoWORK ワークスペースを追加しました。これは、イベントをルーティングする monday の「Builders CoWORK」のユーザー向けインターフェースです。これにより、エージェントのタスク、ステータス、ブロック事項、引き継ぎ情報が、チームと同じ monday ボード上に存在するようになりました。その結果、責任所在の問題はシステム側の課題から解消され、monday は人間に対してすでにこの解決策を提供していたのです。

一つのボトルネックから次のへ

2026 年第 1 四半期後半には、開発のボトルネックはコード生成から人間によるレビューへと移っていました。ガードレールが以前人間が行っていたチェックを担うようになった一方で、すべてのプルリクエスト（PR）はまだ人間の承認待ちの状態でした。これが次なる壁です。

数多くの成果の先駆け：Morphex

Morphex は、monday.com が初めて完全自律型で運用するエンジニアリングエージェントです。このエージェントは、他の開発者（Builder）と同じリポジトリ、CI パイプライン、ガードレール、そしてロールバックプロトコルの中で動作します。Morphex による PR のうち約 80% は、レビューをスキップしているわけではなく、すべての審査基準をクリアした結果として自動的にマージされます。承認された PR は、人間の介入なしにそのまま本番環境へリリースされます。

Morphex が月間に開く PR の数は、多くのエンジニアを上回ります。一方で、却下される PR も人間が作成した場合と同じ理由によるものです。具体的には、不安定なテスト、曖昧な仕様、あるいは未処理のエッジケースなどが原因です。

この 80% という成功率は上限ではなく、あくまで下限値に過ぎません。今後の重要な課題は、事前に「どの PR が人間の承認なしで安全にマージできるか」を判断するシグナルを見出すことです。

そのシグナル：最近の厳格な分析

主要な PR 生成エージェント（選別されたデータではなく）を対象とした最新の厳密な分析では、結果は明確に示されています。PR の約 3 割がマージされ、そのうち約 75% は人間の編集をゼロで行われました。また、ロールバック率は低く、一桁台にとどまっています。さらに、PR が人間の手元に届く前にガードレールによって検出・却下されたケースも全体の約 4 分の 1 に達しています。

この最後の数字こそが最も重要です。ガードレール機能により、PR の四分の一がシステムによって「準備不足」と判断されブロックされました。その結果、事前フィルタリングされたマージ対象のプールが残ります。このプールにおけるリバート率が低く単一の数値に収まっていることは、信頼度に基づく自動マージの実現可能性を示すシグナルです。

信頼度スコアによる自動マージ

PR が開かれた瞬間に取得可能な 4 つの信号を組み合わせることで、信頼度スコアが算出されます。

• 決定論的ガードレールの結果：すべての必須基準を満たしている必要があります。
• エージェントごとの評価軌跡：そのバージョンのエージェントに関する直近の評価スコアのウィンドウデータです。
• （エージェント×リポジトリ×変更クラス）ごとの歴史的リバート率：リスクの低いサービスでの依存関係更新でリバート率がほぼゼロであることは、モノリス移行における高いリバート率とは全く異なる状況を示します。
• サンクボックスの結果：Retrofit 3 からのグリーン判定は必要条件ですが、十分条件ではありません。

この閾値を超えれば PR は自動的にマージされます。下回れば、どの信号が失敗したかを特定して人間にルーティングされます。これは L2 から L3 への移行です。人間を排除するのではなく、システムの判断信号が十分に強く、人間の介入が結果の改善につながらないケースから人間を外すのです。今後 2 クォーターで目指しているのは、レビュー担当者が付かずにリリースされるエージェント PR の割合を高めることであり、その一方でリバート率は横ばい、あるいは改善させることです。

AI エンジニアリングとは、完璧なエージェントを作るものではありません。不完全なエージェントであっても安全に信頼でき、かつ人間の時間を節約できるフィードバックループを構築することなのです。

率直な結び

monday.com のやり方で構築した理由

価値があるのは実行環境そのものではありません。それは Claude Agent SDK を包む単なる枠組みに過ぎません。真の価値は、その周りに整備されたすべての仕組みにあります。そして、そのすべてが monday.com ならではの設計です。

• 共有状態層としての monday ボード: エージェントのタスク、ステータス、引き継ぎ情報は、ビジネス関係者が普段確認している場所に置かれます。
• 基盤となる monday MCP サーバー: ガイドラインや標準規格は、ここに直接接続されます。
• monday.com の認証とアイデンティティ管理: すべてのエージェントが、Slack、GitHub、monday.com 上の実在するユーザーとして振る舞います。権限管理（RBAC）も人間と同じルールで統一されています。
• デプロイパイプライン: エージェントのコードも、他のビルダー同様に CI/CD パイプラインを通じてリリースされます。

人間と状態、アイデンティティ、インフラを共有するエージェントには、別個のガバナンス層は不要です。既存の仕組みがそのまま適用されるからです。これにより、監査可能性、巻き戻し機能、信頼性は「追加されたもの」ではなく、「最初から備わっているもの」となります。もし標準的なテンプレートシステムを使っていたら、こうした要素すべてを他社のモデルに依存する形になっていたでしょう。

改めてやるならこうしたいこと三点

1. 評価（Evals）機能は初日から組み込むべきでした。9 ヶ月目になってから導入したのは遅すぎました。Atlas がスコアで示した改善幅こそが最大の成果でしたが、私たちはベクトルストアへの投資を過剰に行い、「MEMORY.md を EFS に保存するのが正解だった」と気づくのが遅れました。
2. 最初の CoWORK は別ワークスペースに作ってしまいました。これにより、人間はエージェントの動作を確認するためにコンテキストを切り替える必要がありました。これを monday ボード上に統合すべきだったのは、後から修正するのではなく、最初の一歩として決断すべきことでした。

結論

monday-agent-sdk をオープンソース化することはありません。ラッパー自体は小さく、その価値の大部分を占めるのはハッチ（枠組み）ですが、これは monday.com に特化したものであり、他社が活用できるような汎用的なものではありません。

私たちが共有するのは、アーキテクチャと運用の手引きです。大規模に生産環境でエージェントを運用するチームが、何が機能しているかを率直に語ることで、業界全体のスピードは上がります。

エンジニアリングチームにエージェントを組み込もうとしているなら、私たちと同じ壁にぶつかることになるでしょう。しかし、私たちはすでにその壁を越えています。お気軽にご相談ください。monday.com の AI エンジニアリングチーム、あるいは Amazon Bedrock チームが、知見をお伝えする準備があります。

さらに詳しく知る

Amazon Bedrock