AIが書けるからこそ、書かせない──少人数内製チームがフェーズ分離で挑む、大規模レガシー刷新の現実解

【20-B-3】AIが書けるからこそ、書かせない ― 少人数内製チームが、AI駆動開発で大規模なレガシー刷新に立ち向かう現実解

　AIが書けるからこそ、書かせない──。生成AIの進化によってコードを書く速度は大きく上がった一方で、「AIに丸投げしてもうまくいかない」という現実に直面するチームも多い。特に重要なタスクほど、アウトプットのどこかがズレる。その背景には「人間の判断量が飛躍的に増えること」と「AIのアウトプットが不安定になりやすいこと」がある。丸井グループのテックカンパニー・マルイユナイトのCTO（登壇時）・巣籠悠輔氏は、エポスカード（会員数約800万人）を支える20年物のレガシーシステムを、10人規模の内製チームでAI駆動開発により刷新を進めている。鍵は「AIに何をさせるか」ではなく「AIに何をさせないか」、そして「人間がどこで判断するか」を明確にすることにある。その思想と具体的な手法を紹介する。

なぜ「判断量」が問題になるのか

　マルイユナイトは内製開発を強く志向しているが、その出発点は厳しいものだった。丸井グループにはもともとエンジニアが存在せず、システム開発はすべて外部委託に依存していた。マルイユナイトの設立を機に正社員エンジニアの採用を開始したが、800万人規模のサービスを支えるシステムを、まだ10人規模のチームで刷新しなければならない現実がある。エンジニアがボトルネックになることは自明で、だからこそAI駆動開発が戦略の核に据えられた。

　ツールとしてはClaude（Anthropic社の大規模言語モデル）とCursor（AIを統合したコードエディタ）を主に活用している。しかし巣籠氏はすぐに、AIへの丸投げが機能しないことを実感する。

　「AIに丸投げしても、うまくいかない。しかも、やってほしいタスクほどアウトプットがいまいちになる」

　その原因として巣籠氏が挙げたのが、「人間の処理能力の限界」と「AIのアウトプットの不安定さ」という2つの問題だ。なかでも講演で重点的に語られたのが前者である。

株式会社マルイユナイト CTO（登壇時） 巣籠 悠輔氏

　AIが登場する以前、エンジニアが機能を実装する際には、自然と3つのステップを踏んでいた。まず現状のコードを読み解く「理解」、次にどう変えるかを考える「設計」、そして実際にコードを書く「実装」だ。これらのフェーズはそれぞれ異なる思考様式を要求し、人間はそれを順を追って処理していた。

　ところがAIは、この3ステップを一度に処理してしまう。コードベースを読み込んで現状を把握し、設計方針を考え、実装まで一気に行う。その結果、人間がレビューするアウトプットには「理解・設計・実装」が混在した状態で出力される。前後の文脈なしに、どこが設計判断でどこが実装上の選択なのかを読み解かなければならない。

AIは「理解」「設計」「実装」を一度に進めてしまうため、人間のレビュー負荷が高まる

　AIによってコードを書く速度が飛躍的に向上した一方で、人間が下すべき判断の量も同じように膨らんでしまった。巣籠氏はボトルネックの本質はコード量ではなく、この理解・判断量の増加にあると指摘する。これが「丸投げしてもうまくいかない」理由の核心だ。

フェーズ分離という解法──「書かせること」と「書かせないこと」を定義する

　この問題に対してマルイユナイトが採用したのが、「フェーズ分離」というアプローチだ。AIによるアウトプットを「理解（Research）」「設計（Plan）」「実装（Implement）」の3フェーズに明示的に分割し、各フェーズでAIにやらせることとやらせないことを厳密に定義する。

　具体的には、Claude向けにフェーズ別の「Skills」を定義し、理解.md・設計.md・実装.mdという3つのファイルを用意して、それぞれに別々の役割を与えている。

マルイユナイトでは、AI駆動開発をResearch／Plan／Implementの3フェーズに分離して運用している

　各スキルの役割は対応するフェーズに限定されている。フェーズをまたいだアウトプットは、AIに書かせない──これがタイトルに込められた意味だ。

　各フェーズではさらに、「やっていいこと（Do）」と「やってはいけないこと（Do Not）」を明確に規定している。

　理解フェーズ（Research）では、AIに求めるのは事実の収集と記録のみだ。ファイルパスや依存関係を明示し、「何が起きているか」だけを書かせる。ここで重要なのはDo Notの徹底であり、「改善案の提示」「既存設計への批評」「『ここがおかしい』という評価」は一切禁じている。

　理解フェーズでAIが独自の評価を加えてしまうと、その仮定が後続フェーズ全体に波及し、最終的なアウトプットの土台が崩れる。巣籠氏はこの状態を「後続のすべてが仮定に汚染される」と表現し、だからこそこのフェーズでは判断を一切させないと強調した。

　設計フェーズ（Plan）では、理解フェーズの結果を根拠とした設計を行う。設計プランのトレードオフを複数提示させること、そして「不明点を質問として顕在化させること」がDoの重要な項目となっている。AIだけで判断できない技術選定や設計上の選択肢があった場合、AIが勝手に実装するのではなく、その不明点を質問として残し、人間が意思決定する構造を作っているのだ。

設計フェーズでは、不明点を残したまま進めず、人間の意思決定を先に済ませる

　Do Notとして定められているのは「曖昧な前提を残すこと」「未決定事項を残したまま進行すること」、そして「実装を始めること・実装しながら考えること」だ。設計しながら実装するという、人間のエンジニアがついやりがちな作業スタイルも、ここでは明示的に禁じられている。

　実装フェーズ（Implement）では、AIはただの「作業者」として機能させる。設計フェーズで固まった設計に忠実に実装するだけであり、「勝手な最適化」「計画外の変更」「問題への自己判断」はすべてDo Notだ。実装中に想定外の事態が発生した場合は、自己判断で解決しようとせず、処理を止めて人間に判断を委ねる。

　このフェーズ分離の効果は2つある。ひとつはAIのアウトプットの品質安定化、もうひとつは人間の判断コストの削減だ。3フェーズに分けることで、人間が本当に判断すべき箇所が設計フェーズに集約される。理解フェーズと実装フェーズでは、基本的には確認を中心に進めつつ、想定外が発生した場合のみ人間が介入する構造となり、エンジニアが迷う場面が大幅に減る。