「個人の効率化」から「チームのインフラへ」～AIエージェントを組織規模でスケールさせるアーキテクチャの裏側・パート１

お伝えしたいポイント: 個々の開発者がAIエージェントを使用することで2～5倍の生産性向上が見られますが、チーム全体にスケールさせるにはインフラが必要です。mablでは、リポジトリごとの運用マニュアル、検証パイプライン、エージェントと人間の共有ツール、そして「AIが不適切なコードをブロックし、マージの承認は必ず人間が行う」という階層化されたガバナンスを備えた、４層のシステムを構築しました。その結果、開発者の数はそのままに、AI支援によるコミットは10%から30%に増加、プルリクエストの処理速度を77%向上させました。本ブログでは、エージェント型開発を本番環境のスケールで運用するための、mablのリファレンスアーキテクチャをご紹介します。

2026年を迎えるにあたり、mablではある変化が起きているのを感じていました。mablの開発者たちはエージェント型コーディングツールを活用することで、効率の向上を実感していました。mablのシステムを深く理解している一部の開発者は、さらに劇的な生産性の向上を目の当たりにしていました。プロダクトマネージャーやその他の社員も、mablのコードベースに貢献できるようになり始めていました。既存のパターンに従う機能であれば、ほぼ手を触れずに実装できるようになったのです。
mablにおける経験は業界のトレンドと一致していました。Anthropic社が12月上旬に発表したレポートによると、業務の60%でClaudeを活用している従業員は、50%の生産性向上を報告しています。同時に、ClaudeユーザーがLLMに完全に任せられている作業は20%未満であることも報告されています。

直面した課題: 個々の開発者の枠を超えて、エージェント型開発をどうスケールさせるか

mablには、100以上のリポジトリを管理する25人のエンジニアがいます。チームは月に200以上のプルリクエストをプッシュし、40以上の本番リリースを行っています。これはエージェント型開発によって加速する前の数字です。

エージェント型ソフトウェア開発プロセスの導入を拡大しようとした際、スケーリングに関して、いくつか重要な課題がありました。

リポジトリ間の調整: ある機能の変更の影響範囲が３つのリポジトリ(例えば、APIの変更、フロントエンドの更新、共有ライブラリ)にまたがる場合、エージェントはどのリポジトリが互いに依存しているかをどうやって知ればいいのでしょうか？ ライブラリが先にリリースされてもAPIが壊れないようなマージの順序をどう決定すればいいのでしょうか？ 依存関係のグラフは誰が管理し、エージェントはどうアクセスすればいいのでしょうか？ 世に出回っているAIを活用した開発ツールのほとんどが、実は単一のモノリポから始めることを前提にしているため、実際の開発現場への導入をさらに複雑にしています。

開発はコーディングだけにとどまらない: mablの開発者は、Jiraチケットでカスタマーサポートとやり取りし、変更したコードを検証するためにアプリをローカルでビルドし、フィードバックのためにプルリクエストを確認するなど、多くの作業を行っています。規模を拡大していこうとすると、コードを書く以外の活動がエージェントにとってさらに重要になります。なぜなら、これらの活動を通して初めて、『変更したコード』が『実際にテスト可能な振る舞い』として裏付けられる(グラウンディングされる)からです。

高速化するAIのコード生成と、人間によるレビューの限界: チーム全体でAIによってコーディングのスループットが3～5倍に増加した場合、人間によるコードレビューがボトルネックとなります。低リスクの変更(依存関係の更新、Lintの修正、テストの更新など)が多い中で、開発者が週に300件ものプルリクエストをレビューするというのは不可能です。人間のレビュアーが時間を割く前に、形式的なミスはAIに検出させることで、開発者が「真に人間の判断を必要とするプルリクエスト」に集中できる仕組みが必要でした。

スケールする運用: プルリクエストの数がけた違いに増えるということは、ビルドおよびリリースパイプラインにおけるスケーリングと調整の課題に、これまでよりもはるかに早く直面することを意味します。

QA(品質保証)のスコープ拡大: 開発速度の向上に加え、コーディングやプルリクエストのレビューが、(コードの行単位ではなく)より高い視点での『仕様(要件)』ベースに移行していることにより、ソフトウェア開発は「品質を担保するための自動テスト(自動化)」に、これまで以上に大きく依存しなければならなくなっています。同時に、プルリクエストやデプロイの前にローカル環境で的確な検証を可能にすることで、コーディングエージェント自身が的確に動作を検証(グラウンディング)できるようになります。 

2025年半ばまでに、私たちは岐路に立たされていました。2025年8月時点では、コミットの約10%がAI支援によるものでしたが、これらはすべて個々の開発者がツールを属人的に使用している状態でした。2026年2月までには、その数字は全体で39%、インフラストラクチャのリポジトリでは60%に達しました。これらの数字は『AIエージェントが自律的にコミットしたもの』だけをカウントしており、開発者がコードアシスタントと共同で記述し、コミットしたコードは含まれていません。

課題は「エージェントにコードを書かせること」ではありませんでした。25人のエンジニアが75以上のリポジトリにまたがって、エージェントを安全に使用できる「インフラを構築すること」だったのです。
以下がmablで構築したアーキテクチャです。

アーキテクチャ

最終的なシステムは、摩擦(フリクション)に直面するたびに層(レイヤー)を重ねて設計された進化の産物であり、エージェントをmablでの開発エコシステムにおける自律的な貢献者に変える、３つのコンポーネントから構成されています。

クロスリポ基盤 (ルール + 依存関係グラフ) — 個々のリポジトリをまとめた上位に位置する疑似的なモノリポ。リポジトリの規則、依存関係、アーキテクチャパターン、セキュリティ制約など、mablの開発者が持っているのと同じコンテキストをエージェントに提供することで、暗黙知によるボトルネックを解消します。

スキルシステム (MCPサーバー + 再利用可能なスキル) — エージェントは、人間の開発者と全く同じツールと環境で作業を進めます。Jiraチケットのクエリ、テストの実行、UI変更の視覚的な検証、環境の管理などを、１つの統合されたインターフェースから行えます。

運用とガバナンス — AIによるコードレビューが問題のあるプルリクエストをブロックしますが、AIがプルリクエストを「承認」することは明示的に禁止されています。自動修正エージェントは、Lintの修正やインポート忘れなどの単純なCIエラーを処理しますが、修正と失敗の無限ループを防ぐための安全装置(サーキットブレーカー)を備えています。最終的なマージの決定は常に人間が行います。

そして、これらをすべて統合し、個々のチケットの設計、計画、実装を行うための３段階の状態遷移(ステートマシン)に従う自動ワークフローにまとめました。特筆すべきは、この自動化ワークフローが、人間のエンジニアがClaudeと協働する際と『全く同じルールとスキル』を共有して動いているという点です。

レイヤー１: クロスリポ基盤

直面した課題: エージェントは「暗黙知」を持っていません。長く開発が続いている大規模なコードベースにおいて、エージェントは、目の前の課題だけを解決する局所的な最適化には長けていても、システム全体(アーキテクチャ)の構造を無視した、その場しのぎの設計をしてしまうことがよくあります。Claude Codeに「Webアプリに新しいレポートを作成して」と指示すると、利用可能なAPIエンドポイントやバックエンドのPDF生成サービスを完全に無視して、嬉々として何かをハックしてしまいます。これは比較的単純な例です。私たちは、エージェントが生成したコードにより節約できた時間よりも、プルリクエストの段階でコンテキストを提供し、不適切なアプローチを却下することに多くの時間を費やしていました。

構築した仕組み: あらゆる配下のリポジトリのルートに位置する、中央集権型の「クロスリポ基盤」

この基盤リポジトリには、一連の共通ルールとスキルが含まれています。

• エンジニアリングガイド

• Java および TypeScript の一般的なベストプラクティス

• デザインパターン

• 標準ワークフロー

• Google Cloud 関連のツール、および社内用ツール

• (次のセクションで詳述する)様々なスキル
  
  

各リポジトリは、そのリポジトリ固有のルールや例外を含む独自の CLAUDE.md ファイルを保持しています。CLAUDE.md ファイルの複雑さは、リポジトリの複雑さや、スコープ、標準からの乖離度合いによって異なります。

リポジトリの目的: このリポジトリは何を行うか、システム全体にどう適合するか

アーキテクチャ: このリポジトリのコアコンポーネントは何か

依存関係: どのリポジトリがこのリポジトリを利用しているか(または利用されているか)。例: 「mablの shared-node-utils はAPI、UI、mabl-cliから使用されており、破壊的変更を行う場合は、これらリポジトリと連携したプルリクエストが必要です。」

開発の規則: コミットフラグ ([skip ci], [bump:patch])、Terraformパターン、テストのシャーディング設定、ビルドコマンド

ステップバイステップのワークフロー: 人間とエージェントの双方が理解できる、自然言語で記述された10ステップの「新しいAPIエンドポイントの追加方法」ガイド

これと並行して、GitHub組織 mablhq 内のすべてのリポジトリ間の依存関係をマッピングする中央リポジトリ「リポジトリ調整グラフ」を維持管理しています。850行以上あるこのグラフは、79リポジトリをカバーし、詳細な依存関係グラフ、Pub/Subのトピックマップ、データベーステーブルの所有権、あらかじめ定められたリリース順序が含まれています。エージェントが複数リポジトリにまたがる機能に取り組む際には、このグラフをクエリすることで以下を決定します。

• 更新が必要なリポジトリ

• マージ順序 (ライブラリを利用する側のコードよりも先に、上流ライブラリをマージする)

• GitHubの CODEOWNERS ファイルと依存チェーンに基づく、タグ付けすべきレビュアー

• Pub/Subのトピックマップとデータベーステーブルの所有権
  
  

また、分離された並列実行のために Git Worktrees を使用しています。エージェントが同時に３つのリポジトリで作業する場合、それぞれが独自のワークツリーを取得するため、状態の汚染リスクはありません。エージェントが誤ったワークスペースのファイルを編集するのを能動的に防ぐ、ワークツリー関係性フックも構築しました。エージェントがワークツリーで作業中にメインワークスペース(または別のワークツリー)のファイルを編集しようとすると、フックが編集をブロックし、正しいパスを提案します。これは、マルチリポ・エージェントシステムにおける「誤って別のファイルのコピーを編集してしまう」という現実の失敗パターンを解決します。

さらに、エージェントに対し、ファイルの場所(パス)やコードを引用する際には、必ずそのファイルやコードが実在するかを検証することを義務付ける「コードグラウンディング必須ルール」を適用しています。存在しないファイルやコードを捏造すること(ハルシネーション)は許されません。エージェントは Glob または Read を使用してファイルが存在することを確認し、実際に読んだコードから特定の行番号を言及しなければなりません。コードにアクセスできないのであれば、エージェントは推測するのではなく、その旨を明確に述べる必要があります。

解決した結果: クロスリポ基盤によってコンテキストが提供されなければ、エージェントを呼び出すたびに人間の側でコンテキスト(「このリポジトリはTerraformモジュールの命名パターンXを使用し、リポジトリYに依存しており、プルリクエストのレビューには Z さんが必要」など)を用意しなければいけませんでした。クロスリポ基盤により、エージェントはmablのシニアエンジニアが持っているのと同じコンテキストを理解した上で動作します。これにより、コンテキストのドリフト(エージェントがタスクの途中で規則を見失うこと)は、失敗の約40%から5%未満に減少しました。

レイヤー２: スキルシステム(共有ビルディングブロックとしてのMCPサーバー)

直面した課題: 開発者は、バグの修正や新機能の開発に取り組む際、当然のように膨大なコンテキストの中で仕事を進めます。Claude Codeは当初、開発者が使用するのと同じツールや機能にアクセスができなかったため、分析したコードだけを頼りに推測で多くの作業を行っていました。一方、開発者はJiraチケットを詳細まで読み、スクリーンショットを参照し、アプリを起動し、Slackでやり取りし、社内用ツールを使ってデータを確認しながら作業を進めているのです。Claude Codeが開発者と同じ土俵に立って仕事を進めることができないのであれば、Claude Codeにハンデを負わせたままの勝負になってしまいます。

構築した仕組み: Claude Codeも開発者と同様に、既存のツールを活用して調査が進められるよう、mablではツールが提供するMCPサーバー機能をClaude Codeに統合したり、40近いスキルの整備を行ってきました。 

その中でも、開発者向けの以下の重要なツールに、Claude Codeもアクセスできるようになりました。

1. アトラシアン MCP サーバー — エージェントと開発者は、Claude Codeから直接、チケットの検索や、ステータスの更新、コメントの追加、ドキュメント(Confluence)の検索、ラベルの移行を行うことが可能です。チケットに取り組んでいるエージェントは、プルリクエストをサブミットすると、自動的にチケットを「計画待ち」から「実装待ち」に移動できます。

2. mabl テスト実行 MCP サーバー — エージェントはmablのテスト実行をトリガーし、結果を解析し、新たな変更が既存のテストを壊していないか判断できます。自動修正エージェントがCIエラーを発見すると、このmabl テスト実行 MCPサーバーに問い合わせを行い、エラーの原因が(無視してよいような)テストのフレーキーさに由来するものなのか、実際のデグレなのか(修正が必要なのか)を確認します。さらにテスト環境の管理や、新しいmablテストの作成も行います。

3. mabl デスクトップ自動操作 MCP サーバー — エージェントは、mablデスクトップやトレーナーを起動し、Playwrightを介してUI操作を行ったり、スクリーンショットをキャプチャする機能を持ちます。これにより、「視覚を持たないエージェントに、どうやって画面の変更を確認させるか」という問題が解決しました。mablデスクトップやトレーナーの表示に関わる変更が行われたと検証ルーターが判断すると、実装エージェントは単体テストを実行するだけでなく、このMCPサーバーを使用することで視覚的に結果を検証できます。

これらは、.mcp.jsonを使用してワークスペースレベルで構成されているため、Claude CodeやCursorを使用していれば、個別に設定を行わなくても、標準で同じツールにアクセスすることが可能です。

３つのコアMCPサーバーに加え、エージェントと開発者が/commandを介して呼び出せる、専門的な知識モジュールである36以上の再利用可能な「スキル」を構築しました。

• ワークフロースキル: ワークツリー管理、リポジトリのセットアップ、ビルドおよび依存関係に基づく待機、プレビュー版のデプロイ、変更履歴(チェンジセット)の作成

• クロスリポビルドスキル: API + Web UI + デスクトップアプリをすべてローカルで接続して実行

• 検証スキル: リポジトリごとのテストランナー(Java/Gradle, React/Vitest, TypeScript/Jest, Playwright/Electron)、mabl MCPを介したE2Eテスト実行、変更されたファイルに基づいて正しいテストスイートを自動選択する検証ルーター

• 分析および計画スキル: タイプ別(バグ/新規機能/技術的負債)の分析や計画、難易度見積もり、チケットの分類

• 運用スキル: カスタムランタイムイメージでのテスト再実行、実行ログの取得、mablテストの作成

初期のエージェントインフラから長足の進歩を遂げ、すべての開発者が新しいスキルやルールを継続的に提供できるベースラインを作成することで、組織として日々賢くなっています。

解決した結果: MCPサーバーとスキルは、私たちのエージェントを単なる「コードジェネレーター」から「フルスタックエンジニア」に進化させました。エージェントは、Jiraチケットを読み、実装計画を生成し、コードを書き、テストを実行し、(検証ルーターが必要と判断すれば)UIの変更を視覚的に検証し、プルリクエストをサブミットし、チケットを「レビュー待ち」に移動させることができます。これらすべてを人間の介入なしに行います。人間は、各フェーズ間の確信度ゲートと、最終的なプルリクエストの承認の際にのみループに参加します。

レイヤー３: 運用とガバナンス

直面した課題: AIによってコーディングスループットが3～5倍に増加したことで、人間のレビューをボトルネックにすることなく、品質管理をスケールさせる必要がありました。プルリクエストが増加することで、コンフリクトも増加し、開発者はビルド問題の修正、マージコンフリクトの解決、パイプラインを通じたビルドの監視にこれまで以上の時間を費やしていました。
構築した仕組み: プルリクエストのレビューと運用プロセスにエージェントを組み込みながら、コンフリクトの発生源を徹底的に排除しました。

AIコードレビュー

すべてのプルリクエストは、claude-pr-review ワークフローを介してAIコードレビューを受けます。クロスリポ基盤の共通ルールやリポジトリ固有のCLAUDE.mdファイルを取り込むことで、セキュリティ、正確性、コーディング標準に関し「ブロックすべき問題」をサンプルを交えながら、レビューエージェントに対する明確なガイダンスとして提供します。レビューエージェントは以下のアクションを実行できます。

• REQUEST_CHANGES (ブロック): 問題が解決されるまでプルリクエストはマージ不可

• COMMENT (非ブロック): マージをブロックしない提案

自動修正エージェント

オープン中のプルリクエストがあるフィーチャーブランチでCIが失敗した場合、自動修正ワークフローが失敗を診断し、修正コミットをプッシュします。最初はスコープを小さく保ち、Lintエラー、インポートの欠落、単純な型エラー、未使用変数の警告などの単純な修正に焦点を当てました。

テストアサーションの失敗、セキュリティの脆弱性、依存関係の欠落、ビルド構成のエラー、アーキテクチャの変更を必要とする複雑なバグなど、より多くの判断と監視を必要とする複雑な問題は避けるよう、エージェントに明示的に指示しています。

このワークフローには、修正と失敗のループや、開発者と自動修正エージェント間の競合を防ぐための安全装置(サーキットブレーカー)も備わっています。例えば、直近の２つのコミットが両方とも  [auto-fix],とタグ付けされている場合、ワークフローは停止します。また、プルリクエスト作成者が以前に自動修正コミットをリバート(取り消し)していた場合、ワークフローは同じ修正を再度試行しません。作成者が「この問題には人間の注意が必要だ」と意図的に決定したことを認識するのです。

プルリクエスト用スラッシュコマンド (ChatOps)

コマンドハンドラーワークフローにより、プルリクエスト時のコメントを通じて ChatOps スタイルのコマンド実行が可能になります。つまり、開発者はプルリクエストにコメントすることで、特定のアクションをトリガーできます。

• /claude-review および @claude — AIコードレビューのトリガー (すべてのリポジトリで利用可能)

• リポジトリ固有のコマンド: /run-integration-tests, /run-all-tests, /deploy-preview, /run-functional-tests, /run-playwright-builds, /build-images, /run-browser-tests

コマンドは絵文字リアクションとステータスコメントで承認されます。これにより、開発者はワークフローファイルを編集することなく、何を実行するのかを細かく制御できます。

全体像の統合

これを GitHub ネイティブなマージキュー、および Terraform で管理されたルールセットと統合しました。

• 組織レベルのルール: 人間による承認が１つ必要。Squashマージ(細かな修正履歴を１つにまとめて反映)のみで、フォースプッシュ(サーバー側の履歴を強制的に上書き)禁止、ブランチ削除禁止。

• リポジトリレベルのルール: 必須のステータスチェック(ビルド、テスト、セキュリティスキャン)、構成可能な同時実行数の制限

エージェントが作成したプルリクエストの典型的なフローは以下の通りです。

1. プッシュ前検証ゲートを通過後、エージェントがプルリクエストを作成
   

2. AIコードレビューが自動的に実行され、REQUEST_CHANGES または COMMENT を実行
   

3. Lintエラーや型の問題でCIが失敗した場合、自動修正エージェントが安全装置(サーキットブレーカー)が有効な状態で修復を試行
   

4. 人間のレビュアーが、AIのレビューコメントを参考にプルリクエストを評価
   

5. 人間が承認 (または変更を要求)
   

6. プルリクエストがマージキューに入り、完全なテストスイートを実行
   

7. プルリクエストがマージされる

   解決した結果: 2026年2月時点で、アプリケーションリポジトリだけで月に370件以上のプルリクエスト(2025年8月の230件/月から増加)のペースで処理しています。AIコードレビューは、人間のレビュアーが時間を割く前に問題をキャッチします。自動修正エージェントは、些細なCIエラー(セミコロンの欠落、未使用のインポート、型の不一致)を人間の介入なしで解決します。人間のレビュアーは、アーキテクチャの決定、セキュリティへの影響、複雑なロジックなど、真に判断が必要なプルリクエストに集中できるようになりました。
   
   

これがインフラストラクチャです。つまり、共通のコンテキスト、共通のツール、そして人間をボトルネックにすることなく、人間が主導権を握り続けられるようにするガバナンスです。しかし、エージェントが実際にそのインフラストラクチャをうまく活用できなければ、インフラストラクチャは意味をなしません。

パート２では、これら３つのレイヤーをどのように機能させるかについて解説します。Jiraチケットをコンセプトからプルリクエストのマージまで導く４フェーズのパイプラインと、エージェントがいつ自律的に進行し、いつ停止して助けを求めるのかを決定する「確信度に基づくゲート」について説明します。また、その結果と、エージェントがまだ失敗する点についても共有いたします。