何が起きたか
Claude Codeの生みの親であるAnthropicのエンジニア、Boris Cherny氏によれば、同社は「ここ数週間」、自社の社内アプリの日常保守をClaude自身に任せています。起点はproj-claude-maintains-appsという専用のSlackチャンネル。そこからTag経由で、iOS、Android、デスクトップ、Web、CLI、Agent SDKという6つのプラットフォームに対して毎日ルーティンが走ります。
結果は最初の数週間で388件のプルリクエスト（PR）が生成され、Claude Code自身による自動レビューと人間のレビューを経て180件がマージ。Cherny氏はこれを「surprisingly positive（驚くほど良好）」、実験全体を「early signs of life（生命の兆し）」と表現しています。
ルーティンの中身が「AIに任せられる仕事」の輪郭を示す
注目すべきは件数より、任せている作業の種類です。記事では12種類とされ、一覧には11種類が並びます。
Crash Fuzzerはシミュレータで実際のアプリを起動し、ランダムにタップしてクラッシュを誘発、根本原因を解析して修正まで作ります。Dup Unifierは「似ているが微妙に違う抽象」をコードベース全体から探し、統合を提案します。Dead-Code Removerは静的に到達不能なコードを削除しますが、判断が怪しい箇所にはまずログを仕込み、翌日「本当に使われていないか」を確認してから手を入れます。
この「翌日確認する」という設計が、単発のAIコーディングとの決定的な違いです。1回のセッションで完結させず、日をまたいで観測しながら判断する。ほかにもFlaky-Test Fixer（不安定なCIテストの修正）、Useless Test Pruner（絶対に落ちないテストの削除）、Shipped-Feature Inliner（全公開済み機能のフィーチャーフラグ除去）、Abstraction Police（レイヤー違反の是正）、Ant-only Shipper（忘れられた社内限定機能の公開または削除）など、いずれも「重要だが後回しにされ続ける」種類の作業が並びます。
凝ったプロンプトは存在しない
Cherny氏がSlackで共有した指示文には、手の込んだプロンプトエンジニアリングはありません。iOS・Android・デスクトップでクラッシュファジングの日次ルーティンを始めること、モックではなく実アプリを使うこと、クラッシュを起こすこと、修正のPRを作ること——を平易な言葉で伝えるだけです。
作り込む対象はプロンプトではなく、運用のループのほうです。Claudeは多くの場合一発で正しいPRを出しますが、外したときはルーティン側を調整し、翌日の挙動を改善する。この調整に数日かかることもあるといいます。
マージ率46%をどう読むか
半分以上のPRは通っていません。これは限界であると同時に、可能性の指標でもあります。落ちたPRのコストはレビュー工数だけで、リポジトリには何も残らない。一方でAnthropicは今、こうした機械的な変更のマージ手続きをどう高速化するかを検討し始めています。ボトルネックが「AIが書けるか」から「人間が承認しきれるか」へ移り始めた、ということです。
💼 事業会社視点：これは自社にどう効くか
受託開発・SIer：保守運用は人月で稼ぐ領域です。Crash Fuzzerやデッドコード削除のような定型保守が日次で自動化できるなら、「保守要員の常駐」を前提とした見積もりは早晩通用しなくなります。値付けを工数からSLA・稼働率ベースへ移す検討を、契約更改の1サイクル前に始めるべきです。
SaaS・自社プロダクト：狙い目は技術的負債の返済です。フィーチャーフラグの残骸、flakyテスト、重複実装は、放置コストが見えにくいまま開発速度を削ります。Anthropicが1ルーティン=1目的に分割している点は重要で、「リファクタして」と丸投げせず、Shipped-Feature Inliner相当の単機能から始めるのが再現性の高い入り方です。
EC・アプリ事業：アプリのクラッシュは離脱と売上に直結するため、クラッシュ検出→修正PRのループは投資対効果を経営会議で説明しやすい最初の一歩になります。
役員が握るべきKPI：生成PR数ではなく、マージ率と差し戻し理由の分類です。Anthropicですら46%であり、残る半分を捨てられるレビュー体制と、機械的変更を人間の承認待ちで滞留させないマージ動線の設計こそが、経営判断の対象になります。