AI駆動コードモダナイゼーションの準備6ステップをAnthropicのエンジニアが解説。承認をどこに残すかが一発でわかる

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。今回は、Anthropicの現場担当エンジニアが書いた「AI駆動コードモダナイゼーションの準備6ステップ」という記事を紹介するね。

Jonah Ezekiel, Lexie Tonelli（Claude by Anthropic公式ブログ）

“Once agents accelerate writing the changes, the bottleneck shifts from producing changes to mobilizing the organization around them.”
（日本語訳: エージェントが変更を書くスピードを上げると、詰まる場所は変更を作ることから、それを組織としてどう動かすかへ移る。）

銀行のような重要システムでは、1つの変更ごとに変更管理・レビュー・承認という重いプロセスが必須。これは「人間が1つずつ書き、人間が1つずつレビューする」前提で作られてきた仕組み。

この一文、読んだ瞬間にドキッとしました。

私はCockpitでAI秘書の凛ちゃんに子タスクを何十体も走らせています。原稿を書かせる。画像を作らせる。記事を投稿させる。速いです！とにかく速いんです。でも速さが上がったからって、私が楽になったかというと、そう単純じゃなかった。むしろ「これ、このまま公開していいのか」を判断する私の側が詰まるようになりました。作る速さが10倍になっても止まりません。判断する人間が1人のままなら、渋滞する場所が変わるだけなんですよね。任せる相手が人間からAIに変わっても、詰まる場所の引っ越し方は同じだったんです。

AI氣道『AIに任せたのに確認作業が増える｜一人社長の「渡す領域」の切り方』より

「一人社長は特にキツい。人に聞ける相手がいないから、確認の全部が自分に乗る。しかも自分がボトルネックになってることに気づきにくい。」

詰まる場所が変わる。これ、一人社長だと自分の机の上で起きます。AIが速くなるほど、確認が自分に積み上がる。詳しくは『AIに任せたのに確認作業が増える｜一人社長の「渡す領域」の切り方』で書いています。

🎯 今日やること: 自分が今AIに任せている作業を1つ思い浮かべて、「速くなった分、どこで自分が止まっているか」を紙に1行書き出してみてください。

同記事より（Jonah Ezekiel, Lexie Tonelli／Claude by Anthropic公式ブログ）

“Both positions are reasonable, but if the question is left unresolved it resurfaces later as an argument over whether a given change is ‘correct.’”
（日本語訳: どちらの言い分も正しい。でもこの問いを未解決のまま放っておくと、「この変更は正しいのか」という言い争いとして後で必ず再燃する。）

モダナイゼーションには3種類ある（同じスタックのバージョンだけ上げるUplift／挙動を変えずに別スタックへ移すTransform／挙動ごと作り直すReimagine）。どれを選ぶかで揉めがちなので、最初に組織で合意しておく必要がある。

分身AIを作るときにも、私は最初にこれをやりました。

「分身AIは何を変えて、何を変えないのか」を先に決めないまま作り始めたら、絶対に途中で揉めます。だから核心から生やす委任条件、というものを決めました。過去・魂・背景という根から目的を通す。実在する文脈を削らず、本人が置いていない分類や物語を足さない。この2つだけは譲りません！ターゲットを最初に決めておく。それだけで後の言い争いはぐっと減るはずです。

AI氣道『AIにDockerを片付けさせる前に。公式スキルDocker Skillsが書いた「消す前に止まる」ルール』より

「「何をやらせるか」より先に、「何を勝手に消させないか」を決めておく。」

あとで蒸し返されないように、先に決める。Dockerの公式スキルも、消してよい物と消させない物を最初に分けていました。詳しくは『AIにDockerを片付けさせる前に。公式スキルDocker Skillsが書いた「消す前に止まる」ルール』で書いています。

🎯 今日やること: AIに任せる前に「変えていいもの」と「絶対に変えないもの」を1行ずつ、箇条書きで先に決めてください。

Jonah Ezekiel, Lexie Tonelliの解説（Claude by Anthropic公式ブログ）

“Each condition should be checkable without a human in the loop, so the agentic workflow can iterate on a change until it meets the certificate or flag it for human review if it can’t.”
（日本語訳: それぞれの条件は人間を介さずに機械的にチェックできるものにする。そうすればエージェントは合格するまで自分で直すか、無理なら人間レビューへ回せる。）

certificate（合格証明）とは、ある変更がターゲットに対して正しいと機械的に判定するための条件のリスト。元のテストが通る・新規テストが通る・性能が範囲内・独立レビューで問題なし、など11項目が例示されている。

健康診断を思い出しました。

妻から行くように言われた瞬間、正直ありがたいとは思っていませんでした。でも、がんが見つかって、行かなかったら死んでたと分かったんです。健康診断という機械的なチェック項目があったから、私の身体は「合格・不合格」を人間の勘ではなく数値で判定してもらえました。結果は結果。そこに執着するかどうかだけ、というのが今の実感です。certificateも同じだ、って思いました。感覚で「たぶん大丈夫」と判断するのをやめて、先に条件を決めておく。そうすれば、AIも人間も同じ土俵で合否を見られるようになるんですよね。

AI氣道『Loop Engineeringは「手放し」をどう作る？DeNA AI活用100本ノック』より

「何が完成で、どこで私の判断に戻すのかを先に決めているから、仕込みを任せられます。」

合格の条件が先。任せるのは後。DeNAのLoop Engineeringも、テストとレビューを通ってから出す作りでした。詳しくは『Loop Engineeringは「手放し」をどう作る？DeNA AI活用100本ノック』で書いています。

🎯 今日やること: 今やっているAI委任の仕事で「合格・不合格」を人間の感覚だけで決めていないか、1つ点検してみてください。

出典: Jonah Ezekiel, Lexie Tonelli（Claude by Anthropic公式ブログ）

“Fix recurring flags at the source. Group and analyze the flagged changes over time. When the same kind of flag keeps recurring, fix the cause in the agentic workflow or the certificate rather than reviewing each one.”
（日本語訳: 繰り返す指摘は根元で直す。同じ種類の指摘が続くなら、1件ずつレビューするのではなく、ワークフローか合格証明そのものの原因を直す。）

エージェントは人間のレビュー速度をはるかに超えて変更を出す。だから影響範囲とAIの自信度で変更を階層分けし、どの深さで人間が見るかを事前合意しておく、という昇格ポリシーの考え方が紹介されている。

がんで強制的に朝LIVEを中断したときのことを思い出します。

入院して、配信できなくなった。ただっちが代わりに続けてくれました。病室からその様子を見た瞬間、正直「居場所を奪われた」って思いました。複雑でした。でも結果はどうだったか。ただっちも成長して、番組はより良くなって、私の負担も減った。手放したら全部良くなった！生きた証拠です。これ、まさに「毎回全部を自分で見る」から「階層を決めて任せるところは任せる」への切り替えなんですよね。同じ指摘を私が何度も繰り返しているなら、直すべきは相手じゃなくて、任せ方の設計そのものなんだと思います。

AI氣道『Claude Code「/insights」で使い方を診断。枠は何%燃えて、何が返ってくるのか【実測】』より

「見張る仕事を、人間の目からルールと検査に移す。」

同じ指摘を、毎回口で言う。私も3週間で何十回もやっていました。直すのは相手ではなく仕組みの側です。詳しくは『Claude Code「/insights」で使い方を診断。枠は何%燃えて、何が返ってくるのか【実測】』で書いています。

🎯 今日やること: 最近同じ指摘を2回以上した相手（AIでも人でも）がいたら、直すべきは「相手」じゃなく「頼み方」かもしれません。1つ書き出してみてください。

Jonah Ezekiel, Lexie Tonelli（Anthropic Forward Deployed Engineers・公式ブログ）

“We recommend starting with the code modernization plugin, and putting everything the workflow may need on the file system or over MCP, where Claude can reach it. … This forms the central knowledge base for the project.”
（日本語訳: まずは公式のコードモダナイゼーションプラグインから始め、ワークフローが必要とする全てをファイルシステムかMCP経由でClaudeが届く場所に置く。これがプロジェクトの中心的な知識ベースになる。）

環境（専用ホスト・テスト環境）、コードベースとCI/CD（依存マップ・コードフリーズ方針）、他チームとの合意、セキュリティ（最小権限・秘密情報のマスク・全変更のトレース）の4分野を、本格実行の前に並行して整える必要がある。

実家の惣菜屋、山口屋の厨房を思い出します。

仕込みをちゃんとやっていない日は、忙しい時間帯に必ず崩れます。食材が届く場所、包丁の置き場所、火加減のメモ。全部が仕込みの段階で決まっていないと、本番のスピードにお店が耐えられないんです。Cockpitの子タスクも同じで、必要なファイルやルールが手元に揃っていないまま走らせると、後から「あれも渡し忘れてた」の連続になります。地味だけど、この前段の準備を惜しむと、本番でエージェントが迷子になる時間の方が長くなるんですよね。

🎯 今日やること: AIに次に任せる作業で「渡し忘れているファイルや前提条件」が無いか、走らせる前に1回だけ棚卸ししてください。

同記事の続き（Jonah Ezekiel, Lexie Tonelli／Claude by Anthropic公式ブログ）

“First, complete the modernization end to end on a small part of the codebase … Fix anything that doesn’t work while it’s still cheap, repeat the process until you are confident, then scale to the full codebase.”
（日本語訳: まずコードベースの小さな一部分だけで、エンドツーエンドを1回通す。安いうちに問題を潰し、自信が持てるまで繰り返してから、全体へスケールする。）

小範囲でレビューから昇格までを含めて1回通してから、初めて全体へ広げる。ライブのシステムを止められない場合は、末端の区画から少しずつ凍結・現代化していく手法も紹介されている。

マリオカートのタイムアタックと同じだ、と思いました。

ワクワク夢中に遊び探求して、目の前のコースを最短最速で攻略していく。走れば走るほど体で覚えるんです。考えないで体が動くようになる。最初から完璧なタイムを狙って全コースぶっ通しで走る人はいません。1コースだけを何周も試して、体に覚えさせてから、次のコースへ行く。AIへの委任も同じ順番のはずなのに、私も最初の頃は「一気に全部任せよう」としてよく失敗しました。小さく試して自信がついてから広げる。遠回りに見えて、これが一番早いんですよね。

AI氣道『AIに任せた仕組みは静かに壊れる｜6つ中2つが止まっていた話』より

「AIエージェント同士がメッセージし合う時代になるほど、動いている数は増えます。増えるほど、止まったことに気づく仕組みの価値が上がる。」

広げる前に、1回通す。数が増えてからでは、どこで止まったかが見えません。任せていた6つのうち2つが止まっていた話は『AIに任せた仕組みは静かに壊れる｜6つ中2つが止まっていた話』で書いています。

🎯 今日やること: 次にAIへ大きな作業を任せる前に、全体の1/10くらいの小さな範囲だけで1回、最初から最後まで通してみてください。

Jonah Ezekiel, Lexie Tonelli（Claude by Anthropic公式ブログ・原文より）

“When completing the modernization on a small part of the codebase, measure token-usage and use that to extrapolate for the rest of the run.”
（日本語訳: 小さな範囲でモダナイゼーションを終えたら、トークン使用量を実測して、残り全体の分量を見積もる材料にする。）

トークン使用量の主な変動要因は「読む量と書き換える量の比率」「合格証明の厳しさ」「テスト修復の量」「他チームとの調整の量」。安いモデルを機械的な大量作業に、性能の高いモデルを難しい変換や敵対的レビューに使い分ける、という示唆もある。

この「小さく測ってから全体を見積もる」という順番、まさに私がAI秘書の凛ちゃんに任せる時にいつもやっていることと同じでした。

案だけ出して終わりにせず、実際に動かしてみる。何文字読んで、何文字書いて、どれだけ時間がかかったか。感覚じゃなく数字で見る。そうしないと「たぶんこれくらい」という当てずっぽうが、そのままひとり歩きしてしまいます。小さく動かしてから実測する。これは記事のStep6が言っている話そのものでした。

🎯 今日やること: 今週AIに頼んだ作業のうち1つだけ、実際にどれだけの時間や工程がかかったかを数字で書き出してみてください。

AIエージェントが変更を書く速さは、これからも上がり続けます。だからこそ詰まる場所がどこへ移るかを先に知っておくことには意味があります。

ターゲットを決め、合格条件を機械化し、レビューの深さを事前に階層化する。前提を整えてから、小さく試して確信を得てから広げる。この順番は、規制業界の巨大システムだけの話ではありません。

私自身、CockpitでAI秘書の凛ちゃんに任せる範囲を広げるたびに、同じ壁にぶつかってきました。今回の記事は、その壁の正体を言葉にしてくれた1本でした。