AI Coding Meetup #3 AI時代の開発スピードと品質のバランス術 の視聴メモ t_wadaさんと naoyo_itoさんと teyamaguさんのパネルトークでした。
興味深いトピックが多かったけれど、特に気になるところについてメモを残しておく。
トピックは下記の4つ。
AIによるテストコード拡充の問題点と対策
AIが生成するモデル・ドキュメントの品質と向き合い方
「生まれたばかりのモデル」とAIの引き算（捨象）が苦手な問題
AIの成果物の「平均への回帰」と事業の競争力
/icons/hr.icon
AIによるテストコード拡充の問題点と対策
この動画では、AIによるテストコードの生成が開発プロセスに与える影響について、多角的に議論されています。AIがテストコードの作成ハードルを下げる一方で、いくつかの重要な課題も浮上しています。
1. 問題点
1. 見かけ上のコードカバレッジ向上と誤った安心感
AIの助けにより、テストコードの量が爆発的に増え、コードカバレッジの数値が向上します。しかし、これはAIが力ずくで書いたテストコードと、力ずくで書いたモックオブジェクトによるもので、必ずしもテストの品質を示すものではありません。
これにより、開発者は「テストがあるから大丈夫」という誤った安心感を抱きがちになり、本質的な品質問題を見過ごす可能性があります。
2. モックオブジェクトの乱用とメンテナンス負荷
AIが生成するテストコードでは、モックオブジェクトが多用される傾向があります。これは、過去にユニットテストに熱心に取り組んだ時代に「モック地獄」として経験された問題と共通しています。
モックが増えすぎると、テストが本物の挙動から乖離し、テスト自体の信頼性が低下します。また、システム変更時に多数のモックオブジェクトを更新する必要が生じ、メンテナンスコストが大幅に増加します。
3. 「引き算的思考」の欠如
AIは学習データに基づき「機能が多いほど良い」という足し算思考でコードやテストを生成しがちです。そのため、不要なエラーハンドリングや、特定の制約下では考慮不要なコーナーケースまで網羅しようとします。
これにより、テストコードが冗長になり、本質的なビジネスロジックやドメインに特化した重要なテストが埋もれてしまう可能性があります。人間が行う「これは不要」「あえてやらない」といった引き算的な判断がAIには苦手です。
4. コード品質の低下とレビューコストの増加
AIが生成するコードは、時に「雑な増え方」をすることがあり、長期的なメンテナンス性を考慮しないものになる可能性があります。
開発者ではないデザイナーやディレクターがAIを使ってコード変更を直接行うケースも出ていますが、その際にコード変更の規模や品質を適切に見積もることが難しく、結果としてレビュー担当者（エンジニア）の負荷が増大し、本来の業務が圧迫される可能性があります。
「AIに書かせたままプルリクを投げるな」というテックリードの声が示すように、人間がコードの品質責任を持つことの重要性が改めて問われています。
5. 本質的な問題への取り組みの停滞
AIによる単純作業の効率化で時間が生まれたとしても、その時間を「より本質的な課題（例：ドメインモデリング、複雑なビジネスロジックの設計）」に充てるとは限りません。
AIは既存のシステムの深い業務ドメインのモデル変更にはまだ適用が難しく、そこが全体のスループット改善を妨げるボトルネックとなっています。AIはテキストで表現できないような複雑な業務フローや暗黙知を理解するのに限界があります。
2. 対策
1. 人間の理解と責任の維持
AIが生成したコードやテストであっても、人間がその内容を責任持って読み込み、理解することが不可欠です。AIはあくまで補助ツールであり、最終的な品質保証は人間の役割であることを明確にする必要があります。
「これは本質ではない」「これは不要」といった引き算的な判断は、ドメイン知識を持つ人間にしかできません。
2. テストコードの「型」と模範の提示
AIにただテストコードを書かせるのではなく、チーム内で「テストの型」や模範となる高品質なテストコードを事前に作成し、それをAIに模倣させる ことで、一定の品質を担保できます。
これにより、AIは単にコードを生成するだけでなく、チームのコーディングスタイルや品質基準に沿ったテストを作成できるようになります。
3. モック地獄からの学びとユニットテストの再考
過去の「モック地獄」の経験から学び、モックオブジェクトを多用しない「古典派」のユニットテストアプローチを再評価することが重要です。
I/O分離など、本体コードの設計を良くすることで、モックを使わずにテストしやすいコード構造を目指すべきです。
補足: 「単体テストの考え方、使い方」や「Googleのソフトウェアエンジニアリング」といった古典的な書籍が示唆するように、テストしやすい設計とテスト自体の品質向上が、AI時代でも引き続き重要です。
4. コンテキストに応じたテスト戦略
プロダクトのビジネス上の価値や位置づけに応じて、テストの深度や範囲を調整する必要があります。使い捨てに近い小規模なツールであれば、テストコードの品質にそこまでこだわる必要はないかもしれません。
しかし、事業の中核をなすような重要なシステム（例：料金計算、予約システム）であれば、高品質なテストと堅牢な設計が不可欠です。
補足: この考え方は「テストピラミッド」の原則と一致します。UIテストや結合テストといった上位のテストは実行コストが高く、その分ユニットテストを充実させることで、効率的かつ効果的なテスト戦略を構築できます。
5. ドメインモデリングと設計への集中
AIはコード生成のスピードを上げる一方で、人間はより上流の工程、特にドメインモデリングや設計といった「考える」部分に時間を割くべきです。
AIを壁打ち相手として活用し、人間がモデルに対する理解を深め、概念を整理するためのツールとして使うことは非常に有効です。
ただし、チーム活動においては、モデルの共通認識を確立するための議論やコミュニケーションは引き続き人間が行うべきであり、AIがこの領域に与える影響は限定的です。
6. AIの活用領域の明確化
AIは、不慣れな言語やドメインでコードを書く際の叩き台としては非常に有効です。人間がゼロから始めるよりも、AIが生成したコードを修正する方が効率的です。
しかし、その際にもAIの出力するコードの特性（例：冗長性、平均的な設計への偏り）を理解し、適切な指示と修正を行う必要があります。
補足情報 (動画で明示的に言及されていない知識)
モック地獄の深掘り:
モック地獄とは、テスト対象のコンポーネントが依存する他のコンポーネントをすべてモックで置き換えることで、テストが本来の挙動から乖離し、テスト自体の価値が失われる状態を指します。
問題点：
テストの脆さ (Fragile Tests): 実装の些細な変更でもテストが壊れやすくなる。
過剰な結合: テストコードがプロダクトコードの内部実装に密結合し、リファクタリングの障壁となる。
誤った信頼: モックで満たされたテストがすべてパスしても、本番環境でバグが発生する可能性が残る。
対策としては、実際の依存関係をそのまま使用する「統合テスト」や、振る舞いを検証する「インテグレーションテスト」を適切に組み合わせることが推奨されます。
テストピラミッド:
テストピラミッドとは、テストの種類を階層的に分類し、それぞれのテストの量を適切に配分することで、効率的かつ効果的なテスト戦略を実現するための概念です。下層ほどテストの数を多くし、上層ほど数を少なくします。
ユニットテスト: 最も数が多く、実行が速く、コストが低い。AIによる拡充が期待されるが、品質管理が重要。
サービス/インテグレーションテスト: コンポーネント間の連携を確認。
UI/E2Eテスト: ユーザー視点での最終確認。数が少なく、実行が遅く、コストが高い。
AIがユニットテストを増やすことで、テストピラミッドが逆転した「テストアイスクリームコーン」アンチパターンに陥るリスクがあります。
プロンプトエンジニアリングの重要性:
AIに意図通りのテストコードを生成させるためには、より具体的で質の高いプロンプトが必要になります。
例えば、「〇〇の機能に対するテストコードを、〇〇のテストフレームワークと〇〇のテストパターン（例：Arrange-Act-Assert）に従って生成してください。ただし、モックは最小限に抑え、実際のデータを使用してください。」といった具体的な指示を出すことが有効です。
テストスイートの信頼性指標:
単なるコードカバレッジだけでなく、ミューテーションテストのような、テストスイートの品質を評価するより高度な指標を導入することも検討できます。ミューテーションテストは、プロダクトコードに意図的に小さな変更（ミューテーション）を加えて、テストがその変更を検出できるかを測ることで、テストの有効性を評価します。
AIによるテストコードの拡充は、開発プロセスの多くの側面を変革する可能性を秘めていますが、そのメリットを最大限に引き出すためには、人間の深い理解と適切な戦略的判断が不可欠です。
/icons/hr.icon
AIが生成するモデル・ドキュメントの品質と向き合い方
動画で語られているように、AIは既存のコードベースから設計モデルを抽出したり、仕様ドキュメントを生成したりする能力を持っていますが、その成果物は完璧にはほど遠いのが現状です。その品質の特性を理解し、適切に付き合うことが極めて重要です。
1. AI生成物の品質：70点の「叩き台」としての価値と限界
AIが生成するモデルやドキュメントの品質は、一言で言えば 「一見それっぽいが、本質的な部分が間違っていることが多い」というものです。
良い点：ゼロから始めるより遥かに効率的
既存の巨大なコードベースを人間がゼロから読んで理解するのに比べ、AIは瞬時にコードの構造を解析し、モデルの雛形やドキュメントの草案を提示してくれます。これは、真っ白なページを前に途方に暮れる状態を防ぎ、議論の出発点（叩き台）として非常に価値があります。
問題点：コンテキストの欠如と「平均への回帰」
1. 暗黙知や「なぜ」の欠如: AIはコードに書かれている「何をしているか（What）」は抽出できますが、その背景にあるビジネス上の制約、歴史的経緯、チームでの議論といった 「なぜそうなっているか（Why）」 を理解できません。そのため、抽出されたモデルは表層的で、重要なドメインのルールが抜け落ちていることがほとんどです。
2. 競争優位性の喪失: AIは学習データに基づき、世の中の「一般的で平均的な」設計（例：典型的なECサイトのモデル）を提示しがちです。しかし、ビジネスの競争優位性は、その「平均」からの逸脱、つまり独自の業務フローや他社にはないユニークなドメインルールにこそ存在します。AIの生成物を鵜呑みにすると、その独自性が失われ、ありきたりなシステムになってしまう危険性があります。
3. 誤った理解の助長: AIの出力は非常に流暢で説得力があるため、ドメイン知識が浅い人が読むと「これが正しいのだ」と誤解してしまうリスクがあります。動画内で「詳しい人が見ると全然ダメ」と指摘されていたのはこの点です。
2. 生成物との付き合い方：「壁打ち相手」としてのAI
AIが生成したモデルやドキュメントは、完成品ではなく、思考を深めるための「仮説」または「問い」 として扱うべきです。
間違い探しと議論の活性化: AIが提示した不正確なモデルは、チームにとって最高の 「壁打ち相手」 になります。「なぜこのモデルは間違っているのか？」「本来あるべき関係性は何か？」「我々のビジネスの最も重要なルールは何か？」といった対話が強制的に生まれます。このプロセスを通じて、チームメンバーの頭の中にある暗黙的なメンタルモデルが言語化され、共通認識が形成されていきます。
人間による「引き算」と文脈の付与: AIはあらゆる可能性を考慮し、足し算的（Additive）に機能を盛り込みがちです。それに対して、人間は「この機能は我々のビジネスでは不要」「この制約はあえて設けている」といった引き算的（Subtractive）な思考でモデルを洗練させる必要があります。 人間が介在し、ビジネスコンテキストという彫刻刀でAIが持ってきた大きな石材から本質を削り出すイメージです。
3. 本来あるべき理想の関係：AIを「思考の触媒」とするワークフロー
AIと人間の理想的な関係は、AIに単純作業を任せ、人間はより創造的で本質的な思考に集中する、という分業です。
1. 抽出（AI）: AIがコードベースをスキャンし、モデルの第一稿やドキュメントの草案を高速で生成する。
2. 検証と修正（人間）: チームでその草案をレビューする。明確な間違いを修正し、不正確な部分を指摘する。
3. 文脈の付与と深化（人間）: なぜその修正が必要なのか、背景にあるビジネスルールや設計思想をドキュメントに追記する。図やプレゼンテーションなど、テキストだけでは表現しきれない情報を補い、モデルを豊かにする。
4. 共通認識の形成（チーム）: この一連の共同作業を通じて、チーム全体で対象ドメインへの解像度を高め、生きた知識としてのドキュメントを育てていく。
このワークフローにおいて、AIは単なる「ドキュメント生成ツール」ではなく、チームの対話を促し、深い思考へと導く「触媒（Catalyst）」 として機能します。AIの不完全さこそが、人間の知性を刺激し、より良い設計とチームの成長につながるのです。
最終的に、ドキュメントやモデルの価値は、その正確性だけでなく、「チームがどれだけ深く思考し、共通の理解を築けたか」 というプロセスそのものにあると言えるでしょう。AIを賢く使うことで、この本質的な活動を加速させることが、これからの開発における鍵となります。
/icons/hr.icon
「生まれたばかりのモデル」とAIの引き算（捨象）が苦手な問題
これは、ソフトウェア開発の本質に迫る非常に重要な論点です。AIがまだ人間には及ばない、創造的な「捨象」の領域と言えます。
🤔 問題の核心：なぜAIは引き算が苦手か？
AIは「可能性の探求者」である: AIの強みは、学習データからあらゆるパターンと関係性を抽出し、「これもできる」「あれも考慮すべき」と可能性を網羅的に提示することにあります。これは足し算的な思考です。
人間は「目的の体現者」である: 一方で、新しい業務モデルを創る過程は、無数の可能性の中から「我々のビジネスにとって本質的なのはこれだけだ」と、目的達成に不要なものを大胆に切り捨てる行為です。これは引き算的な思考であり、ドメインへの深い理解と、未来に対する意思決定そのものです。
この関係は、彫刻家と大理石の塊に似ています。AIはあらゆる形になる可能性を秘めた巨大な大理石を持ってきます。しかし、最終的に「ダビデ像」を彫り出すのは、完成形を心に描き、不要な部分を削り落とせる彫刻家（=ドメインエキスパート）の役割です。
💡 人類はAIをどう活用すべきか？
AIに「モデルを創れ」と命じるのではなく、「モデルを創るための思考の壁打ち相手」 として活用するべきです。
1. 発散フェーズでの活用（AIの得意領域）:
役割: ブレーンストーミングのパートナー
具体的な使い方:
「この手作業のプロセスに含まれる登場人物、情報、ルールをすべてリストアップして」
「考えられる例外パターンやコーナーケースを10個挙げて」
効果: 人間だけでは見落としがちな要素を網羅的に洗い出し、思考の材料を揃えることができます。AIが足し算で大量の選択肢（大理石の塊）を提供します。
2. 収束フェーズでの活用（人間の得意領域）:
役割: 意思決定の補助・検証ツール
具体的な使い方:
（人間が絞り込んだモデルを提示し）「このシンプルなモデルで、先ほど挙げた例外パターンのうち対応できないものはどれ？」
「このモデルの弱点や矛盾点を指摘して」
効果: 人間が引き算で削り出したモデルの妥当性を、AIを使って多角的に検証できます。思考の漏れをチェックし、モデルの強度を高めることができます。
このワークフローでは、戦略的な意思決定（何を捨て、何を残すか）の主導権は常に人間が握ります。 AIはあくまで思考を加速させ、精度を高めるための最高の副操縦士（コパイロット）です。AIの「引き算が苦手」という特性を欠点と捉えるのではなく、人間の「捨象」という高度な知的能力を際立たせるための触媒として利用するのです。
/icons/hr.icon
AIの成果物の「平均への回帰」と事業の競争力
AIの生成物が「平均的」であることは、諸刃の剣です。これを戦略的に使い分けることが、事業会社にとってのAI活用の勘所となります。
⚔️ どこで「平均」を受け入れ、どこで「独自性」を追求するか？
事業領域を 「競争領域」 と 「非競争領域」 に分けて考えるのが有効です。
非競争領域（Commodity）: 積極的にAIの「平均」を活用すべき領域
概要: ユーザー認証、定型的なUIコンポーネント、CI/CDパイプライン、社内管理画面など、他社と差別化する必要がなく、「標準的で安定していること」が価値となる領域。いわゆる「車輪の再発明」を避けるべき部分です。
AI活用の是非: 「是」。 ここでAIの「平均的で無難な成果物」を使うことは、開発コストを劇的に削減し、スピードを向上させます。浮いたエンジニアのリソースを、本来注力すべき競争領域に振り向けることができます。これは賢明な経営判断です。
競争領域（Core Competence）: AIの活用は慎重に、補助的に行うべき領域
概要: その会社の「秘伝のタレ」にあたる部分。独自の価格決定アルゴリズム、マッチングロジック、長年の業務で培われたドメインモデルなど、事業の根幹をなす競争力の源泉です。
AI活用の是非: 「非」。 ここでAIが生成した「平均的なモデル」をそのまま採用することは、自社の競争優位性を放棄するに等しい行為です。誰もがAIで生成できるロジックは、もはや参入障壁にはなりません。
🍳 競争領域における賢いAIとの付き合い方
競争領域でAIを完全に排除する必要はありません。使い方を限定し、人間の創造性を増幅させるツールとして利用します。
結論として、事業会社は 「非競争領域」の徹底的な効率化のためにAIの平均性を歓迎し、「競争領域」では人間の独自性を守り、磨き上げるための補助輪としてAIを慎重に活用する という、戦略的な使い分けが求められます。AI時代における企業の競争力は、この見極めの巧拙にかかっていると言えるでしょう。