なぜ「判断量」が問題になるのか
マルイユナイトは内製開発を強く志向しているが、その出発点は厳しいものだった。丸井グループにはもともとエンジニアが存在せず、システム開発はすべて外部委託に依存していた。マルイユナイトの設立を機に正社員エンジニアの採用を開始したが、800万人規模のサービスを支えるシステムを、まだ10人規模のチームで刷新しなければならない現実がある。エンジニアがボトルネックになることは自明で、だからこそAI駆動開発が戦略の核に据えられた。
ツールとしてはClaude（Anthropic社の大規模言語モデル）とCursor（AIを統合したコードエディタ）を主に活用している。しかし巣籠氏はすぐに、AIへの丸投げが機能しないことを実感する。
「AIに丸投げしても、うまくいかない。しかも、やってほしいタスクほどアウトプットがいまいちになる」
その原因として巣籠氏が挙げたのが、「人間の処理能力の限界」と「AIのアウトプットの不安定さ」という2つの問題だ。なかでも講演で重点的に語られたのが前者である。
AIが登場する以前、エンジニアが機能を実装する際には、自然と3つのステップを踏んでいた。まず現状のコードを読み解く「理解」、次にどう変えるかを考える「設計」、そして実際にコードを書く「実装」だ。これらのフェーズはそれぞれ異なる思考様式を要求し、人間はそれを順を追って処理していた。
ところがAIは、この3ステップを一度に処理してしまう。コードベースを読み込んで現状を把握し、設計方針を考え、実装まで一気に行う。その結果、人間がレビューするアウトプットには「理解・設計・実装」が混在した状態で出力される。前後の文脈なしに、どこが設計判断でどこが実装上の選択なのかを読み解かなければならない。
AIによってコードを書く速度が飛躍的に向上した一方で、人間が下すべき判断の量も同じように膨らんでしまった。巣籠氏はボトルネックの本質はコード量ではなく、この理解・判断量の増加にあると指摘する。これが「丸投げしてもうまくいかない」理由の核心だ。
フェーズ分離という解法──「書かせること」と「書かせないこと」を定義する
この問題に対してマルイユナイトが採用したのが、「フェーズ分離」というアプローチだ。AIによるアウトプットを「理解（Research）」「設計（Plan）」「実装（Implement）」の3フェーズに明示的に分割し、各フェーズでAIにやらせることとやらせないことを厳密に定義する。
具体的には、Claude向けにフェーズ別の「Skills」を定義し、理解.md・設計.md・実装.mdという3つのファイルを用意して、それぞれに別々の役割を与えている。
各スキルの役割は対応するフェーズに限定されている。フェーズをまたいだアウトプットは、AIに書かせない──これがタイトルに込められた意味だ。
各フェーズではさらに、「やっていいこと（Do）」と「やってはいけないこと（Do Not）」を明確に規定している。
理解フェーズ（Research）では、AIに求めるのは事実の収集と記録のみだ。ファイルパスや依存関係を明示し、「何が起きているか」だけを書かせる。ここで重要なのはDo Notの徹底であり、「改善案の提示」「既存設計への批評」「『ここがおかしい』という評価」は一切禁じている。
理解フェーズでAIが独自の評価を加えてしまうと、その仮定が後続フェーズ全体に波及し、最終的なアウトプットの土台が崩れる。巣籠氏はこの状態を「後続のすべてが仮定に汚染される」と表現し、だからこそこのフェーズでは判断を一切させないと強調した。
設計フェーズ（Plan）では、理解フェーズの結果を根拠とした設計を行う。設計プランのトレードオフを複数提示させること、そして「不明点を質問として顕在化させること」がDoの重要な項目となっている。AIだけで判断できない技術選定や設計上の選択肢があった場合、AIが勝手に実装するのではなく、その不明点を質問として残し、人間が意思決定する構造を作っているのだ。
Do Notとして定められているのは「曖昧な前提を残すこと」「未決定事項を残したまま進行すること」、そして「実装を始めること・実装しながら考えること」だ。設計しながら実装するという、人間のエンジニアがついやりがちな作業スタイルも、ここでは明示的に禁じられている。
実装フェーズ（Implement）では、AIはただの「作業者」として機能させる。設計フェーズで固まった設計に忠実に実装するだけであり、「勝手な最適化」「計画外の変更」「問題への自己判断」はすべてDo Notだ。実装中に想定外の事態が発生した場合は、自己判断で解決しようとせず、処理を止めて人間に判断を委ねる。
このフェーズ分離の効果は2つある。ひとつはAIのアウトプットの品質安定化、もうひとつは人間の判断コストの削減だ。3フェーズに分けることで、人間が本当に判断すべき箇所が設計フェーズに集約される。理解フェーズと実装フェーズでは、基本的には確認を中心に進めつつ、想定外が発生した場合のみ人間が介入する構造となり、エンジニアが迷う場面が大幅に減る。
AIに期待すべきは「賢さ」ではなく「制約下での再現性」
フェーズ分離の本質を理解するうえで、巣籠氏が提示したフレームは示唆に富んでいる。
「AIに期待しているのは『賢さ』ではなく、『制約下での再現性』です」
生成AIの中核にある大規模言語モデル（LLM）は、確率的なモデルである。入力に対して確率分布からトークンを選択して出力を生成するため、同じ入力でも毎回わずかに異なるアウトプットが生じる。
コンテンツ生成などの用途であればこのブレは許容できるが、事業システムの開発においては毎回アウトプットが変わることは品質保証の観点から許容しがたい。では、再現性を高めるにはどうするか。答えは「制約を設けること」だ。制約によってAIの出力空間を絞り込み、確率的なブレを抑制することで、アウトプットを決定論的な振る舞いに近づけていく。フェーズ分離はその一形態であり、各フェーズで「問いを一つにする」という制約が、AIのアウトプットの方向性を安定させる。
この考え方は、個人や組織の差別化要因にもつながる。どのような制約（スキル・エージェント定義）を構築するかが、そのまま組織の技術資産となる。汎用的なAIツールを使っていても、その使い方を定義するプロンプトやワークフローの設計に独自性が宿るのだ。
また、フェーズ分離は、複数のエージェントを同時に立ち上げて並列で走らせる場合にも有効だという。各エージェントにフェーズを割り当てることで、精度のばらつきを抑えながらスループットを高めることができる。
大規模なレガシーシステムの刷新においては、「ストラングラーパターン」（既存システムを一度に置き換えるのではなく、新システムを外側から少しずつ侵食させていく手法）も組み合わせている。このパターン自体も一種の制約であり、取り組むドメインを絞ることでコンテキスト長の問題にも対処できるという。フェーズ分離とストラングラーパターンは、「制約によってAIと人間の作業を安定させる」という思想で一貫している。
「何をさせないか」という問いが組織を救う
このセッションが提示した最も重要な知見は、AIの活用を語る際の問いの立て方を根本から変えるものだ。多くの議論が「AIに何をさせるか」「どのツールを使うか」に集中する中、巣籠氏は「AIに何をさせないか」「人間がどこで判断するか」を問いの中心に据えた。
これは単なる開発手法の話ではない。少人数チームが大規模課題に向き合うとき、人間のリソースは常に希少だ。AIを導入することで「何でもできる」という錯覚に陥ると、かえって人間の判断コストが爆発する。AIの能力を最大化するためにこそ、AIの行動範囲を明示的に制限するという逆説的なアプローチが、持続可能な開発体制を支える。
今後AIモデルの性能がさらに向上すれば、人間によるレビューが不要になる領域は広がるだろう。しかしその未来においても、再現性という概念は消えない。むしろ、アウトプットが安定して再現されることが確認できてはじめて、人間はレビューを手放せる。再現性の高い仕組みを今から作り込んでおくことが、将来的な自動化への道を開く。
エンジニア10人規模という小さなチームで、800万人規模のシステム刷新に挑む現実は厳しい。しかし「AIに書かせないことを決める」というシンプルな原則が、そのギャップを埋める鍵になりうる。AIとの協働において「制約の設計者」たる人間の役割を問い直すこと──それが本セッションの核心的なメッセージだ。
マルイユナイトからのお知らせ
マルイユナイトではエンジニアの仲間を募集しています。開発環境やカルチャー、現在募集中のポジションなど、詳しくは採用情報ページをご覧ください。
