今こそ聞きたいソフトウェア設計 #2 設計次第で、AIコードの読む量は減らせる
ミノ駆動
本記事では、2026年9月30日に開催されたオンラインイベント「今こそ聞きたいソフトウェア設計 #2 設計次第で、AIコードの読む量は減らせる」の内容をお届けします。
AIコーディングエージェントの普及で、「コードを書くこと」自体の相対的な価値は変わりつつあります。一方で、何をどう設計し、どう判断するかという設計力の重要性は、むしろ高まっています。AIが生成したコードの品質や変更容易性を最終的に担保するのは、人間の設計判断だからです。
本シリーズは、「ソフトウェア設計をこれから学びたい」「改めて学び直したい」というエンジニアに向けて、設計の基本原則や実践知を、第一線で活躍するエンジニアとともに紐解いていく企画です。
第2回となる今回は、『良いコード／悪いコードで学ぶ設計入門』の著者であり、ITエンジニア本大賞2023技術書部門大賞を受賞した合同会社DMM.comのミノ駆動（@MinoDriven）さんが登壇。AIが書いたコード、人間はどこまで読めばいいのか。ミノ駆動さんは「契約による設計」「副作用のない関数」「抽象化」の3つを挙げ、設計次第で読む量は減らせると語りました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
ミノ駆動：ミノ駆動です。合同会社DMM.comのプラットフォーム開発本部で、コード品質チームに所属しています。DMMにはさまざまな事業やサービスがありますが、会員登録や不正対策、決済など、どの事業でも共通して使う基盤を弊社では「プラットフォーム」と呼んでいます。そのコード全体の品質を改善し、生産性を高めるのが僕の仕事です。兼務で、プラットフォーム開発本部全体のAI駆動開発を推進するPF-AX戦略グループにも所属し、AI活用の戦略策定に関わっています。
著書に『良いコード／悪いコードで学ぶ設計入門』があります。変更容易性の高い設計を学ぶ本で、先日、改訂新版が3刷になりました。
AIが書いたコードは、読むべきか
AI駆動開発が加速度的に広がっています。AIという文字を見ない日はないくらいです。AIはあっという間にコードを実装してしまうので、いろいろな現場で、人間のレビューが追いつかないということが起こっているのではないでしょうか。AIを使うと、人間がだんだんボトルネックになってくる。
こうした状況で、AIが書いたコードを読むべきかどうかが、ネット上で物議を醸していますよね。数か月前にも、X上で読む・読まないの論争があったと思います。「読んで理解しないと責任が取れない、デバッグできない」とか、一方で「品質を保証する仕組みを作って、読まなくてよくする」とか、いろんな意見がありますよね。
これについて僕個人の考えとしては、コードをまったく読まなくていいというわけではないかなと思います。でも一方で、ちゃんと適切に設計すれば、読む必要性や労力は低減できると考えています。
今日は、その設計の話をします。読む労力のことを、僕は「リーディングコスト」と呼んでいます。リーディングコストを下げるうえで重要な設計として、 「契約による設計」「副作用のない関数」「抽象化」 の3つを説明します。この3つを理解していただくことが、今日のゴールです。
今回のターゲットは「正しい結果が得られるか分からないコード」
まずは問題を整理しましょう。AIが書いたコードを読まなければならないとされる理由はいろいろあります。AIにまとめさせてリストアップしてみました。
