最近、Aima Service をリファクタリングしました。だいたい1週間かかり、その過程でいろいろなことを考える羽目になりました。ここにそのメモを書き残します。
Emergency Room
Aima Service は、毎日開くような種類のツールではありません。デバイスのための救急外来のようなものです。普段は考えません。何かが壊れたときにだけ、はじめて必要になります。
これが、気まずい力学を生みます。成功はユーザーにとっては「何もなかった」のと同じに感じられるのです。問題は解決されて「まあ、よかったね、了解」。そしてユーザーは去っていきます。そもそも痛みを体験していないので、解決がどれだけ大きかったかに気づけません。
一方で、失敗のほうがずっと面白い。
失敗にも種類があります。エージェントは真剣に試したが直せなかったため、「タスクは失敗した」と伝える——これが1つ。テストしてみたら実は成功していないのに「成功しました」と主張する——これがもう1つ（偽の成功）。そして最悪なのは、チャネル自体が壊れるケースです。処理の途中でクラッシュしたり、フリーズしたり、切断されたりする。
最初の2つはまだ扱えます。救急外来に行ったら医者が治せなかった——それなら、別の場所へ行くだけです。最後の1つは許しがたい。あなたは 120（救急）に電話し、救急車が来たのに、到着したときには救急外来が閉まっている。あるいは中に入って受付システムが落ちていて、医師が途中でいなくなり、「すみません、本日は閉院しています」と誰かが出てくる。
それが本当のクラッシュです。
Decor Doesn't Matter, Doctors Must Be There
これを理解すると、優先順位がはっきりします。
救急外来では、派手な内装は役に立ちません。座り心地のいいソファも役に立ちません。重要なのは2つだけです。ドアが開いているか。そして医師は患者を診られるのか。
前のバージョンは、機能的にはなんとか足りていましたが不安定でした。タスクはしょっちゅうバグにぶつかり、絶えずクラッシュし、原因不明のフリーズにも悩まされました。救急外来のドアは開いているのに、医者がいない。
そこで、完全にリファクタリングしました。新機能は追加せず、土台を作り直しただけです。
Two Models Alternating
今回のリファクタリングでは Claude Code と Codex を使い、両者を交互に動かしました。
まず、ドキュメントシステムを設計し、両方のモデルにドキュメントとコードを読ませて、やるべきことをリスト化しました。次に Claude Code がリファクタリングの第1ラウンドを実行し、その成果を Codex に渡して第2ラウンドを行い、また交互に繰り返します。
なぜ1つだけにしなかったのか？ 試しましたが、どうしてもズレが出やすいからです。Claude Code はアーキテクチャの感覚が強く、構造レベルの問題を見つけられる一方で、時々保守的すぎます。Codex は速く、大胆に動き、細部を拾うためにぐるっと回って戻ってくるのですが、たまに荒っぽくなります。どちらか一方に任せると、その弱点が増幅されます。交互にすることで、最良のリズムが生まれます。片方が見つけた問題は、多くの場合もう片方が直せるからです。
後で確認して、NeurIPS 2025 の論文「Lessons Learned」を見つけました。そこには、異なる LLM が互いをどう補完し合うかを具体的に分析した上で、最適なのはだいたい 3 体のエージェントで、それ以上は限界効用が落ちると結論づけていました。私の体験とまったく一致しています。
各ラウンドでは、モデルがエージェントチームを立ち上げて並列に実行できます。1つのタスクが 3〜4時間かかるのは普通です。いずれにせよ非同期なので、自分の作業をして、たまに様子を見て数問質問するだけです。
CI/CD Ate More Time Than Expected
機能面のリファクタリング自体は、だいたい1週間でおおむね完了しました。時間を本当に食ったのは、その後に起きたことです。
コードは大きく変更しました。リリース前に何を担保するべきでしょうか？ 自動テスト、ビルドチェック、統合検証——どれも省略できません。パイプライン1回の実行には数十分かかります。何かを直したら、もう一度走らせて、さらに数十分。さらに後から、テストケースを調整し、パイプラインを最適化し続ける。テストコードを書くことだけで、数万行を書きました。
AIコーディングの話をするとき、人々は「どれだけ速いか」に注目します。でも実際に本番へ到達するには、CI/CD とテストがエンジニアリング工数の半分以上を占める可能性があります。AIもこの部分はできますが、何度も回してデバッグする必要があり、急いで済ませることはできません。
1.3 Million Lines
リファクタリングのあと、レポートを生成して数値を見ました。
機能面では新しいことは何も追加していないので、見た目は目立ちません。しかしアーキテクチャは「どこでもバグのあるタスクを回す」から、「10万人級のユーザーを扱える設計」へと変わっています。モジュールはきれいに分割され、分散ワーカーと海外向けフェデレーションまで最初から組み込んであります。
コード量には驚きました。ドキュメントを除くと約130万行、ドキュメント込みだと170万行。8〜9日、非専門家が1人、AIモデルが2つ。
そして、ふとあることを思い出しました。
The Moat Dried Up
数年前には、よく知られた格言がありました。コード量はソフトウェア企業の「堀」だ、と。何百万行ものコードが積み上がれば、他社は（たとえやりたくても）それをコピーできない。
当時それを読んで、「なるほど、理にかなっている」と思ったのを覚えています。Cisco IOS XE は 1億9000万行のコードで、3000人以上が保守し、年間700以上の新機能をリリースしています。SAP の ABAP コードは 2億5000万行を超え、理解できる人はますます減っています。これらの会社は本当に「これが複雑すぎて誰にも置き換えられない」を頼りにしているのです。
ですが、よく考えるとコード量が「堀」のすべてだったことはありません。Cisco の堀は、1億9000万行のコードに加えて、生態系とスイッチングコスト、そしてブランドです。SAP の障壁は、ABAP が書くのが難しいからではありません。42万5,000社のうち、7年以内に S/4HANA へ移行したのはたった5%しかないことが問題なのです。Lidl は試して、500百万ユーロを燃やして諦めました。Revlon は売上で 6400万ドルを失いました。複雑さが生むロックイン効果は、コードそのものよりもはるかに頑固です。
しかし今、状況が面白くなってきました。今年の初め、Marek Kowalkiewicz が「Drying the Moat」を書き、Anthropic が AI による COBOL システムの読み取りとモダナイズを実証した後、IBM がたった1日で時価総額 400億ドルを失ったことに触れました。コードの複雑さは実際に「理解の非対称性」を生みます。つまり、あなたは私のコードを読めないから、私から離れられない。AI がその非対称性を消し去ってしまったのです。
振り返って自分を見ると、8〜9日、1人が2つのモデルを交互に回して、コード行数130万行のシステムがすでに本番で動いています。分散アーキテクチャ、CI/CD パイプラインがあります。
130万行は確かに Cisco の 1億9000万行とは違い、桁が2つも違います。エコシステムや顧客ロックインは、コードでは置き換えられません。しかし「コードの複雑さ」という土台となる柱は、すでに抜かれ始めています。残りの柱がどれくらい持ちこたえられるかは、正直言ってわかりません。
Do It When You Think of It
全体を振り返って、いくつかの考え。
AI はプロダクトレベルのソフトウェアなら作れます。ここで生まれた成果物は、すでにアクティブユーザーを持つ本番環境で動いています。デモではありません。難しい部分は CI/CD とテストで、時間はかかりますが、AI もそれらはできます。ただし回数を重ねる必要がある。
リファクタリングは、もうそんなに怖くありません。以前は、ぐちゃぐちゃのレガシーコードを引き継いで、まず何をしているのかを把握するだけで数週間かかりました。今ではモデルが数分で読んで、アーキテクチャ図まで描ける。混沌から新しいアーキテクチャへ、わずか1週間で。人手でやるよりも、技術的負債はずっときれいに掃除できました。
最大の変化は、たぶんマインドセットです。以前は、リファクタリングは大きな意思決定でした。人員計画、スケジュール、リスクを計算していた。今は、コードベースがそれ自体を維持できないなら、ただ作り直すだけです。新しい技術が出てきたら、それを使って最初から作り直す。コードはますます「消費されるもの」になりつつあります。
もちろんコードはいまもプロダクトの骨格で、それは変わっていません。ですが、その骨格を作るコストは、以前と同じ桁ではなくなっています。
返却形式: {"translated": "翻訳されたHTML"}もともとは https://guanjiawei.ai/en/blog/emergency-room-vanishing-moat に掲載されました
