【後編】良いコード / 悪いコード × AI – AI時代のソフトウェア設計
本記事は 2024/10/11 に開催されたイベント「良いコード / 悪いコード × AI – AI時代のソフトウェア設計」の内容をもとに執筆されました。
「コード×AI ー ソフトウェア開発者のための生成AI実践入門」(以降「コードAI本」)の著者である服部佑樹と、「良いコード／悪いコードで学ぶ設計入門」(以降「ミノ駆動本」)でお馴染みのミノ駆動さんが、AI時代における知的装備について対談しました。（以降敬称略）
本記事は二部構成のうちの後編となります。
持っておくと良い「引き出し」 - 開発者リテラシー
服部:
「引き出し」として、こういった知識を持っておくとAI時代に活用しやすい、というものはありますか？ 参考になる書籍でも構いません。「ミノ駆動本を読め」でもいいですよ（笑）。
ミノ駆動:
もちろん自分の本も参考になりますが（笑）、カプセル化や関心の分離については、さまざまな設計技術書に記載があります。ただし、必ずしも「カプセル化」や「関心の分離」という言葉を使わずに説明している本も多いんです。用語は異なるものの、同様の考え方が深く解説されているケースがよくあります。
そういった書籍を幅広く読むことで、「こんな考え方もあるのか」といった新たな発見が得られます。それが最終的には良いプロンプトを書くための新たな知見につながるんですよね。
服部:
やっぱり技術書を読むことが大事ということですかね（笑）。AIは確かに優秀な学習ツールですが、ある程度自分で「引き出し」を作っておかないと、「どう質問すれば良いコードか悪いコードか判別できるのか」といった判断が難しいですよね。
ミノ駆動:
そうですね。最終的には、指示する側がどれだけ問題の違いを理解しているか、つまり解像度の高さが問われます。多様な技術書や記事を読んで理解を深め、その上で何度も試行錯誤を重ねることで、的確な指示ができるようになると思います。
服部:
コードレビューの重要性はこれからますます高まりそうですね。AIがコードを書くようになり、「書く」よりも「提案されたコードをレビューして修正する」工程が増えるかもしれません。現状、レビューの手法には何か変化がありますか？
ミノ駆動:
現時点ではまだ実験段階ですね。チーム全体に導入して大きく変わるところまでは至っていません。期待はされているのですが、実際には「とにかく早く作ってほしい」という要求もあり、なかなか本格運用には至っていない状況です（笑）。
服部:
組織としてコードレビューのスキルをどう伸ばすかは、大企業やデジタルネイティブ企業でも悩みの種です。最終的には地道に積み上げていくしかない、という結論に戻ってくることが多いですね。
AIが表層的な知識（「Reactでこうした方が良い」程度）を提案するようになっても、その先にある本質的な理解や設計思想は、人間が学び続けてメタ的な理解を深めないといけない。結局、人は学び続ける必要がありますよね。
ミノ駆動:
全く同感です。最終的には、人間が問題の本質を見抜くリテラシーを持たなければなりません。
言語化の重要性
服部:
チャット中に「プロンプトを書くために言語化する過程で、ドメイン知識も増える」というコメントがありました。確かにプロンプトを考えながら、自分自身が学んでいると感じることは多いです。
カプセル化や関心の分離をAIに提案させるには、まずこちらが「なぜ分離するのか」を理解し、それを言語化しなければなりませんよね。AIにコードを見せずに意図的に分離する設計もあるようですし、さまざまなアーキテクチャで工夫している方々も多いようです。
ミノ駆動:
そうですね。AIに投げるコード範囲をあえて分離し、影響範囲を制御する手法はあり得るでしょう。
「将来の拡張性を考えた設計」や「AI時代における分離手法」はまだ模索中ですが、本質的な目標は変わりません。良い設計は、結局同じ目的に沿ってカプセル化・分離が行われるわけです。
依存関係との戦い - 結合度
服部:
イベント前の打合せでも話したのですが、依存関係をどう扱うか悩みますよね。どこまで分離すべきか。DDDなどでもいろいろな面から分離しますが、AIに対してコンテキストが不足する場合もある。
静的解析ツールやIDEのリファクタリング機能との兼ね合いも出てきます。この悩みをどう考えればいいのでしょうか。
ミノ駆動:
これは難しい問題です。依存関係（結合度）は昔からのテーマで、強く関連するものはまとめ、関係の薄いものは分離すべきです。
強い関連があるものを無理に分離すると整合性が崩れますし、最終的に「どこで分けるか」はドメイン知識がなければ判断できません。ドメインを理解しない限り、適切な関心分離は不可能なんです。
生成AIは一般的な答えは示せても、特定のドメイン固有の判断は苦手です。そこがまさに現時点での難しさだと思います。
服部:
結局ドメイン知識がないと厳しい、ということですね。
ファインチューニングと組織としての利用
服部:
組織でAIを活用しようとすると、「自社コードを学習させたい」という声がよく出ます。でも、「学習させるに値するコード」を本当に持っているのか、と問うと、意外にない場合も多い。
ゴールドマンサックスのような例ではファインチューニングしたモデルで生産性を向上させているようですが、そもそも自社がファインチューニングさせるべき価値のあるコードとは何でしょう。
ミノ駆動:
やはり、その企業がコアな価値を発揮する部分だと思います。つまり、コアドメインに関わるコードですね。
コモディティ化した部分を学習させても大きな価値はありません。コアな部分に内包されている独自の知見をAIに学習させることが、有意義だと考えています。
服部:
確かに、自社独自のコア要素がコード化されている企業は意外と少ないものです。
オープンソースライクなインナーソースの取り組みでも、実際には本当にコアとなるコードはわずかだったりします。
結局、プラットフォームチームがまとめた共通基盤や、競争優位性の源泉になるR&D由来のコードくらいしかなかったりします。それを学習させることが価値につながるのでしょうね。
AI時代のエンジニアに求められるスキル
服部:
最後に、スキルについてお聞きします。AI時代に求められるスキル、または採用したい人材像はどのようなものでしょうか。
ミノ駆動:
これまでと変わらない点も多いのですが、AI時代に特に重要になるのは「問題解決能力」だと感じます。
AIを有効に活用するには、まず目の前の問題が何なのかを明確にする必要があります。問題を分析し、言語化し、適切なプロンプトに落とし込む能力。これは結局、人間が問題をしっかり理解する力にかかっています。
服部:
確かに、問題を分解して理解し、結果を確認して学習するプロセスはAIで加速できても、問題を定義するのは人間の仕事ですね。
AIを使いこなす人材は強いですが、その基盤にあるのは問題解決力。ロジカルな思考と試行錯誤が欠かせませんね。
ミノ駆動:
その通りです。AI時代になっても、本質は変わりません。良いコードの定義も品質特性やドメイン知識に左右され、人間がそれを理解していないとAIもサポートできない。
服部:
最初の問いに戻ると、AIにとっての良いコードと、人間にとっての良いコードは違うのか、という話。ここまでの議論を踏まえると、実はそれほど変わらないのではないでしょうか。
ミノ駆動:
私も変わらないと思います。分かりにくいコードは人間にもAIにも扱いづらいですし、本質的な部分は共通しています。
服部:
ありがとうございます！ 今回は「良いコード」という非常に大きなテーマを、AI時代の文脈で品質特性や設計原則、AIツールの活用なども踏まえて議論できてよかったです。
AIとの協働について書いたコードAI本、そしてより成長させやすいコードの書き方と設計を学ぶ入門書のミノ駆動本、ぜひご一読ください！
