8月14日、The Decoderが「Claude Code now runs daily maintenance on Anthropic's software with a 46 percent merge rate」と題した記事を公開した。この記事では、AnthropicがClaude Codeを使って社内アプリの日次メンテナンスを自律実行させた実証実験とその結果について詳しく紹介されている。
46%というマージ率をどう読むか
AIコーディングツールの「実際のところ」は、ベンチマークよりも本番運用でこそ明らかになる。Anthropicは自社のAIコーディングツールClaude Codeを、自社の本番リポジトリに対して毎日走らせるという実験を数週間にわたって実施した。
Claude Codeを開発したAnthropicのエンジニアBoris Chernyによると、この期間中にClaudeは388件のプルリクエストを生成した。自動レビューと人間によるレビューを経て、そのうち180件がマージされた。マージ率は約**46%**だ。
この46%という数字を読む際には、却下の内訳も重要になる。元記事によると、却下されたPRには自動レビューの段階で弾かれたものと、人間のレビュアーが明示的に拒否したものの両方が含まれる。つまり「半数以上が人間に却下された」とは一概には言えず、パイプライン全体での歩留まりとして捉えるのが適切だ。半数以上が最終マージに至らなかったという事実は、AIへの過度な期待を戒める数字でもある。一方で、開発者がほぼ手を動かさない状態で、日常的なコード品質改善のPRが毎日量産されているという点は、従来の開発フローとは異なる世界を示している。Chernyはこの結果を「早期の生存サイン（early signs of life）」と表現している。
※編集部の考察：Claude Codeは2025年5月に一般提供が開始されたツールであり、本実験はリリースから比較的早い段階での社内実証にあたる。GitHub CopilotやCursorといった競合ツールが主にインタラクティブな補完支援を軸とする中、Claude Codeは長時間の自律的タスク実行を強みとしており、今回のような「エージェントとして繰り返しジョブを回す」用途はその特性を直接検証するものと言える。
11種類のルーティンで「コードの雑務」を丸ごと委譲
ClaudeはSlackの専用チャンネル「proj-claude-maintains-apps」を通じて、iOS・Android・デスクトップ・Web・CLI・Agent SDKの全プラットフォームを横断してメンテナンスを実行している。連携にはClaude Tag（SlackのメッセージでClaudeをメンションして呼び出す仕組み）を利用している。
実行されるルーティンは以下の11種類だ。
| ルーティン名 | 機能 |
|---|---|
| Crash Fuzzer | シミュレーターでアプリをランダム操作してクラッシュを検出・修正 |
| Ant-only Shipper | 社内限定機能の配信・削除 |
| Logic Simplifier | ネストされたビジネスロジックの簡略化 |
| Logic Bug Fixer | 複雑なロジックをモデル化してバグを検出・修正 |
| Dup Unifier | 重複実装のマージ |
| Dead Code Removal | 到達不能コードの削除 |
| Useless Test Pruner | 常に成功するだけのテストの削除 |
| Shipped-Feature Inliner | リリース済み機能のフィーチャーフラグ除去 |
| Flaky-Test Fixer | 不安定なCIテストの分析・修正 |
| Abstraction Improver | 過度に複雑な抽象化の簡略化 |
| Abstraction Police | アーキテクチャのレイヤー違反の修正 |
用語を補足しておく。フィーチャーフラグとは、コードを再デプロイせずに機能のオン・オフを切り替えるための仕組みで、段階的なロールアウトや実験的機能の管理に広く使われる。リリース済みの機能については不要になったフラグをコードから取り除く「掃除」作業が生じるが、これを「Shipped-Feature Inliner」が担う。CI（継続的インテグレーション）は、コードの変更をリポジトリにマージするたびに自動でビルド・テストを走らせる開発手法で、「Flaky-Test Fixer」はそのCIパイプライン上で不規則に失敗するテストを自動修正する役割を持つ。
中でもCrash Fuzzerの挙動が具体的だ。アプリをシミュレーター上で起動してランダムにタップし、クラッシュを引き起こし、根本原因を分析してPRを作成するまでを一気通貫で行う。Dead-Code Removerは単純に削除するのではなく、「怪しいが確信が持てないコード」に対してはまずログを仕込んでおき、翌日の実行で実際に未使用かどうかを確認してから削除するという段階的アプローチを取っている。
プロンプトは「普通の英語」で十分
Chernyが公開したSlackでのプロンプトを見ると、特殊なプロンプトエンジニアリングは使われていない。「iOS・Android・デスクトップでクラッシュファジングの日次ルーティンを開始して。モックは使わず実アプリで。クラッシュを起こして、修正のPRを作って」という自然言語の指示だけだ。
運用の現実：失敗したら翌日チューニング
Chernyによると、Claudeは多くの場合、初回の試みでPRを正しく仕上げる。失敗した場合はチームがルーティンを調整し、翌日の実行で改善を確認するというサイクルを回す。このチューニングには数日かかることもある。
Anthropicは現在、こうした機械的な変更に対してマージプロセスを高速化する方法を検討中だという。46%というマージ率の壁をどこまで引き上げられるかが、このアプローチの実用性を左右する。
詳細はClaude Code now runs daily maintenance on Anthropic's software with a 46 percent merge rateを参照していただきたい。
