今こそ聞きたいソフトウェア設計 #2 設計次第で、AIコードの読む量は減らせるのトップ画像

今こそ聞きたいソフトウェア設計 #2 設計次第で、AIコードの読む量は減らせる

投稿日時:
ミノ駆動のアイコン

合同会社DMM.com / エンジニア

ミノ駆動

Xアカウントリンク

本記事では、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にまとめさせてリストアップしてみました。

この記事のつづきを読もう✨
新規登録/ログインしたらできること
  • すべての記事を制限なく閲覧可能
  • 限定イベントに参加できます
  • GitHub連携でスキルを可視化
ログイン
アカウントをお持ちでない方はこちらから新規登録
20
20