ソフトの基本、今こそ問われる──AI Engineer

AI がコードを書く時代、なぜ「設計力」が最も重要になるのか

AI によるコード生成が普及する今、「仕様書さえ書けば AI が全てやってくれる」という考え方が広まっています。しかし、このアプローチはコードの品質を急速に低下させ、最終的には維持不可能な「ゴミコード」を生み出す危険性があります。むしろ、AI を活用できるかどうかを決めるのは、人間が持つソフトウェアの基礎的な設計スキルなのです。

「仕様からコードへ」の罠とエントロピー

現在、多くの開発者が「Spec-to-Code（仕様からコードへ）」という手法を試しています。これはアプリケーションの動作を記した仕様書だけを書き、AI に任せてコードを生成し、問題があれば仕様書を修正して再実行するというサイクルです。

しかし、このアプローチには重大な欠陥があります。私は実際に試しましたが、コンパイラ（AI）を何度も回すたびに、出力されるコードは劣化の一途を辿りました。最終的に得られたのは、理解不能で変更も困難なゴミのようなコードでした。

「仕様書さえ書いておけば AI が管理してくれる」という考え方は、別の名前の「コーディング」に過ぎません。

この現象は、ソフトウェア工学の古典的な概念である「エントロピー」によって説明できます。エントロピーとは、物事が自然にバラバラになり、崩壊へと向かう状態を指します。コードベースに変更を加える際、その変更点だけを気にしてシステム全体の設計を顧みない場合、コードは確実に悪化していきます。

「コードは安い」という言葉が流行していますが、これは誤りです。悪いコードほど高価なものは過去にありませんでした。なぜなら、変更が困難なコードベースでは、AI が提供する恩恵のすべてを受けられないからです。良いコードベースこそが、AI を最大限に活用するための土台となります。

共通設計概念を共有する「Grill me」スキル

AI と人間の間に最も大きな壁となるのは、「何を作っているか」という共通理解（デザインコンセプト）の欠如です。人間は頭の中にイメージを持っていても、それを AI に正確に伝えることは容易ではありません。

この課題を解決するために推奨されるのが、「Grill me（私を尋ねろ）」というスキルです。

これは、AI に対して執拗に質問させる手法です。「私の計画のすべての側面について、共通の理解が得られるまで私をインタビューしてください」と指示します。AI は通常、すぐに計画を立てて実行しようとする傾向がありますが、このスキルを使うことで、AI は設計の各分岐や意思決定間の依存関係を一つずつ確認し始めます。

AI に 40 問、あるいは 60 問も質問させることで、対話を通じて共通の理解が得られます。その後の生成物は、単なるコードではなく、製品要件文書や具体的なイシューとして機能します。

このアプローチは、AI が「計画モード」で安易に実行するのを防ぎ、人間と AI の間で確固たる設計コンセプトを共有させる効果があります。

ドメイン駆動設計（DDD）による「普遍的言語」の構築

AI と対話している際、「同じ言葉を使っているつもりでも、意味がズレている」という経験はありませんか？これは、開発者とドメイン専門家（あるいは AI）の間で「共通言語」が確立されていないことが原因です。

この問題を解決するのが、ドメイン駆動設計（DDD）の概念である「ユビキタス言語（普遍的言語）」の活用です。これは、開発者、ドメイン専門家、そして AI の間で用語を統一するためのルールセットです。

具体的な実践方法は以下の通りです：

1. 用語リストの作成: コードベースをスキャンし、重要な用語や概念を抽出します。
2. Markdown ファイル化: これらの用語とその定義、意味合いを明確にした Markdown ファイルを作成します。
3. AI との共有: このファイルを AI に渡し、対話や計画立案の際に常に参照させます。

AI が思考する際、この「普遍的言語」ファイルを開いておくことで、AI の思考が簡潔になり、実装内容が計画と一致するようになります。これは間違いなく強力なツールです。

インターフェース設計の優先と「深いモジュール」

AI を効果的な「現場のプログラマー」として活用するためには、人間の役割を「インターフェース（境界）の設計」に集中させる必要があります。複雑な実装の中身は AI に委譲し、人間はテスト可能なインターフェースとモジュールの境界を設計します。

ここで重要なのが、John Ousterhout が提唱する「深いモジュール」の概念です。

• 浅いモジュール: 機能が少なく、インターフェースが複雑。AI は無数の小さな塊を探索する必要があり、依存関係を理解できずに迷走しやすい。
• 深いモジュール: 機能は豊富だが、背後に隠れており、シンプルで明確なインターフェースを持つ。外部からはその中身を見なくても動作を理解できる。

良いコードベースとは、テストしやすいコードベースです。深いモジュールを採用することで、AI は複雑な実装の中身を探索する必要がなくなり、設計されたインターフェースを通じて正確に動作します。

このアーキテクチャを確立すれば、人間は「グレーボックス（中身は見えないが入出力は確認できる）」として扱えるようになります。重要な部分や金融システムなどでは詳細を確認する必要がありますが、多くのモジュールにおいては、「インターフェースだけを設計し、実装は AI に任せる」という戦略が可能になります。

結論：AI は戦術的プログラマー、人間は戦略家

AI を活用する上で最も重要なのは、テスト駆動開発（TDD）の徹底です。AI はデフォルトで一度に大量のコードを生成しようとする傾向がありますが、フィードバックループの速度がスピードリミットとなるため、小さなステップを踏む TDD が不可欠です。

AI を「現場の軍曹」や「戦術的プログラマー」として使いこなすには、その上には「戦略レベルで思考できる人間」が必要です。それは、過去 20 年以上にわたって培われてきたソフトウェアの基礎スキル——設計力、アーキテクチャ思考、そして深いモジュールによる構造化の知識です。

コードは安価ではありません。むしろ、良い設計こそが AI の力を引き出す鍵となります。AI 時代において、人間のエンジニアが果たすべき役割は、コードを書くことではなく、システム全体の設計と戦略を担うことにあります。