AI 2026年4月22日

「工数が少ない方で」はもう終わり――AI時代、アーキテクチャの判断軸が静かに変わった

𝕏 シェアする

「工数が少い方で行きましょう」という言葉、もう一度考えてみる

設計レビューの終盤、こんな言葉が出たことはないだろうか。「理想はA案だけど、工数を考えるとB案が現実解ですね」。

これは怠惰ではなかった。制約の中での合理的な判断だった。ただ、その制約の前提が、AIによって静かに書き換わりつつある。

zenn.devに掲載されたfixUエンジニアの記事「AI時代のアーキテクチャ意思決定」は、その変化を実例付きで言語化した、読み応えのある一本だ。

なぜ今、この話が重要なのか

従来の設計判断は、シンプルな天秤だった。「堅牢性の差」と「工数の差」を比べて、だいたい工数が少ない方が選ばれる。実装工数がtie-breakerとして機能してきた、というわけだ。

なぜそうなるかといえば、エンジニアの手と時間は有限で、リリース遅延は機会損失に直結するから。将来の便益は「将来」のものだが、工数は「今」のコストとしてダイレクトに効いてくる。そういう構造だった。

AIエージェント（Claude Codeなど）を日常的に使うようになると、この構造の一辺が崩れる。具体的には「実装工数は希少資源」という前提が揺らぐ。

定型CRUDやDTO変換は数時間かかっていたものが数十分に。命名変更や責務分離といった形式的なリファクタは半日かかっていたものが数十分に。コードベースの探索（「認証の処理ってどこだっけ」）は1〜数時間かかっていたものが数秒〜数分に。体感で数倍から十数倍のスピードアップが効く、と記事では整理されている。

「工数が2倍違う2案」の差が、AIの文脈では相対的に小さくなる。これが「工数はtie-breakerではなくなった」の根拠だ。

具体的に何が起きたか――上位vs下位、どちらに階層を持たせるか

記事の冒頭に登場するDB設計の実例が、この話を一番わかりやすく説明している。

fixUサービスでの大規模な機能追加の場面。ドメインに2つのエンティティがあり、どちらかに親子関係（階層構造）を持たせる必要があった。選択肢は2つ。

案A：上位エンティティ（事業主体側）に階層構造を持たせる
案B：下位エンティティ（運用単位側）に既存の親子構造を拡張して流用する

既存コードベースとの整合性で言えば、案Bが綺麗に噛み合う。新規テーブルも大きなマイグレーションも不要で、修正範囲も局所的。実装工数の見積もりでは、案Bは案Aの半分以下だったという。

一方でドメインモデルとしての「正しさ」は案Aに軍配が上がる。今回の機能の本質は「事業主体側の階層構造」を表現することで、下位エンティティに親子関係を載せると「運用単位のツリー」と「事業主体側のツリー」が混線し、将来的に権限設計や集計ロジックが複雑化する予兆があった。

採用したのは案A。案Bの2倍強の実装工数がかかる選択だ。

結果として、ビジネス概念をモデル上で一意に表現できるようになり、上位側と下位側のツリーが明確に分離されたことで集計ロジックや権限ロジックが直線的に書けるようになった。著者が特に強調しているのが「読むたびに認知負荷を発生させない構造」になったという点。「脳のワーキングメモリを食わない」という性質は、チームの日常的な開発速度にゆっくり効いてくる利得だ、と。

AIが圧縮するコストと、しないコスト

ここが記事の核心部分だ。AIが圧縮するコストと、圧縮しないコストを整理すると、判断軸が自然と変わってくる。

AIが圧縮しないコストとして記事が挙げているのは主に4つ。

認知負荷：コードは書くのは1回、読むのはN回。ドメインモデルと実装が一致していないコードは、読むたびにコストを払う負債になる。これはAIでは圧縮できない。
テスト・検証工数：E2Eテスト、セキュリティ検証、ユーザー受け入れテストなど「動作を人間が確認する」工程は、AIではほとんど圧縮されない。むしろAIが大量に提案するぶん、確認すべき差分は増えがちだ。
将来の変更コスト：モデルを「現実に合わない形」で固めてしまうと、数ヶ月後・数年後に必ず歪みが出る。「過去の判断を取り消す改修」は、AIがあっても工数が圧縮されにくい。影響範囲の把握が「コードを読む速さ」ではなく「組織の歴史を思い出す速さ」に律速されるからだ。
意思決定そのもの：どちらの設計が正しいかという判断は、AIに丸投げできない。ドメイン知識、組織の慣習、将来の事業方針――こうした文脈は人間が提供しない限りAIも判断できない。

ここに、個人的に「なるほど」と思った視点がある。AIが実装を担うようになるほど、人間が担うべき意思決定の密度は上がるという逆説だ。AIが楽にしてくれた分、浮いたエネルギーが「設計の質」に向かうべき、という話は綺麗事に聞こえがちだが、「意思決定の密度が上がる」という表現の方が実態に近い気がする。

8マイクロサービスのhard forkが教えてくれたこと

もう一つの実例も印象的だ。fixU RebootプロジェクトでのLaravelモノリスから9マイクロサービス構成への分割。そのなかで8サービスをモノリポから独立リポジトリにhard forkする作業を、AIマルチセッション並列運営（親セッション1つ＋サブセッション9つ）で実施した。

想定工数は数日。実際は4〜5日かかり、9リポジトリ横断で約270万行を削除、約72本のPRを捌く規模になったという。単純な実装工数で見れば、モノリポに留めた方が楽だったのは間違いない。

それでもhard forkを選んだのは、サービス境界を物理的に強制できる（越境参照がビルドエラーになる）、サービスごとのCI/CDが独立する、AIマルチセッション運営と設計が自然に一致する、という長期の構造便益があったから。結果として以降の機能追加や品質改善が「サービス単位で閉じる」形になり、AIマルチセッション運営との相性も噛み合ったと記事は述べている。

ここで著者が示している姿勢がシンプルで刺さる。「工数見積もりは事後にほぼ必ず超過する前提で意思決定する」。工数を過小見積もりしてリスクを取るのではなく、工数は超えるかもしれないが、アーキテクチャが正しければ事業として損しないという土台で判断する、と。