9月11日、Toward Data Scienceが「Software Design in the Age of AI」と題した記事を公開した。AIがコードを書く時代においてソフトウェア設計の重要性はむしろ高まるという論点を、「AI-SDEをステークホルダーに加える」という具体的な設計観点から論じた内容だ。GitHub CopilotやCursorといったAIコーディングツールが開発現場に浸透するなか、「設計不要論」への正面からの反論として注目に値する。
「AIがコードを書くなら設計は不要」は間違いである
AIコーディングツールの普及により、「エンジニアリングの重要性が下がる」という議論が絶えない。しかしこの記事が指摘するのは、その逆である。
ソフトウェア開発は、要件定義・設計・コーディング・検証・サポートという5つの活動で構成される。AIが担えるのはコーディングの部分にすぎない。そして、AIがコード生成を担うほど、設計の品質がシステム全体の成否を左右する構造になる。
記事の核心を一文で表せば、「AIはコード生成を楽にするが、それはソフトウェア設計をより重要にする」ということである。
ソフトウェアが「特別な機械」である理由
記事はまず、ソフトウェアの本質的な特性を整理する。
飛行機や建物も複雑なシステムだが、稼働中に大規模な改修を受けることはほぼない。一方ソフトウェアは、サービスを継続しながら絶え間なく変更され続ける。これは「生涯を通じて継続的に改修される複雑なシステム」という、自然界にも人工物にも類を見ない性質だ。
この特性がソフトウェア設計に決定的な含意をもたらす。設計者は「今日存在するシステム」だけでなく、「明日そのシステムがどう理解・修正・拡張されるか」まで設計しなければならない。
ステークホルダーとしての「AI-SDE」
記事の最も興味深い視点は、AIコーディングツールそのものをソフトウェアのステークホルダーとして扱うという発想である。
従来のソフトウェア設計では、ステークホルダーとして次の6種類を考慮する：
- ユーザー（システムを使う人）
- 管理者（システムを運用する人）
- コードオーナー（コードを所有する組織）
- コードクライアント（外部からコードを利用する組織）
- コードコンシューマー（他の開発者がコードを呼び出す側）
- 将来の開発者（保守・改修を担う人）
AIコーディングツールが普及した現在、コードコンシューマーと将来の開発者の役割をAI-SDE（AI Software Development Engineer）が担うケースが増えている。
AIがコードを「読む」ときに何が起きるか
人間の開発者は、ドキュメントが不完全でも、チームメンバーへの質問や「暗黙知」で補完できる。しかしAI-SDEが頼れるのは明示的に存在する情報だけである。
例えば、AIがデータベースへの値の保存処理を実装する場合を考える。設計上は既存のデータベースライブラリを使うべきだが、そのライブラリのドキュメントが不完全・陳腐化していた場合、AI-SDEはライブラリを使わずに独自のデータベース処理コードを再生成してしまう可能性がある。結果としてコードの重複、一貫性の欠如、設計の意図からの乖離が生じる。
これは人間の開発者であっても起きうる問題だが、AIが大量のコードを高速に生成する環境では、設計の不備が指数関数的にシステム全体へ伝播するリスクがある。
設計の「フレンドリー」属性が今こそ重要になる
記事は、将来の開発者（およびAI-SDE）がソフトウェアを修正する際の典型的なプロセスを以下のように整理している：
- 要件変更の把握
- コードへの影響範囲の特定
- 設計とテストケースの更新
- 変更の実施
- テスト
このプロセスをスムーズにするために、ソフトウェアは次の3つの「フレンドリー」属性を持つべきだとされる：
- ナビゲーションフレンドリー（Navigation-friendly）：ユーザー要件から最小のコードコンポーネントまでトレースできること。例えばSSOの要件がどのテーブル・モジュールで実装されているか追跡できる設計。
- 修正フレンドリー（Modification-friendly）：シンプルなインターフェースを持つモジュール構成、共通処理の適切な集約。
- 封じ込めフレンドリー（Containment-friendly）：変更の影響をシステムの最小部分に限定できること。データベーステーブルの変更がシステム全体に波及しない設計。
これらはSOLID原則や関心の分離といった従来から言われてきた設計原則と地続きの概念だが、AIが修正の主体になることで、明示的・機械可読な設計情報としての整備が不可欠になる点が新しい。暗黙知に頼った設計は、人間の開発者には通じてもAI-SDEには通じない。
設計はコーディング前の「一度きり」の作業ではない
記事が強調するもう一つの重要な点は、設計はコーディング前のフェーズに限られないということである。
- コーディング前：システムの大枠を設計
- コーディング中：データベーステーブル名・関数名・変数名の決定なども設計行為
- サポートフェーズ：新しい要件に応じて設計は進化し続ける
コーディング中に決定されることも、それが設計ガイドラインに従った判断である限り、設計活動の一部である。AIがコーディングを担う場合でも、このガイドラインを明示的に提供するのは人間のエンジニアの役割となる。
AIが大量のコードを生成できる時代だからこそ、「何を作るか・どう構造化するか」という設計判断の価値は下がるどころか上がる。AI-SDEという新たなステークホルダーを設計の対象に含めるという視点は、GitHub CopilotやCursorを本格活用するチームにとって即座に実践へ落とし込める示唆を持つ。
詳細はSoftware Design in the Age of AIを参照していただきたい。
