生成AIに負けないために新卒一年目は"品質"にオールインしました 

©BrainPad Inc. Strictly Confidential 経歴 キャリア要約 所属 役割 2 SAITO KOTARO データエンジニアリングユニット ML/アプリケーション開発 所属 役割 2020 九州工業大学 知能情報工学科 メディア情報工学専攻 2022 九州大学システム情報科学府 情報理工学専攻 出身：福岡県 趣味：ポーカー、MLB 機械学習エンジニア 経歴 好きな技術 自己紹介 写真 斉藤 虎太郎 2024- 株式会社ブレインパッド 機械学習エンジニア 配属されてから 期間 案件 テーマ 7月~8月 （空き） ソフトウェア設計についてひたすら勉強 8月〜3月 小売業界 コンシューマ向けチャットボット開発 3月 生命保険 チャットボット開発・運用支援 4月〜7月 小売業界 動画 x 生成AI 8月〜 社内案件 いい感じのテーマ 

3 ©BrainPad Inc. Strictly Confidential コーディングエージェントの発展は目覚ましく、日々様々なアップデートがされている。うまくこの大波を乗りこなした い。 コーディングエージェントの発展が目覚ましい お気に入り 

4 ©BrainPad Inc. Strictly Confidential AIが生成したコードをレビューし、成果物の品質、特にコード品質を維持するために必要なポイントを把握できます。 本発表で知れること できた！ ここ直して あれこれ ここで何を考えているか 

©BrainPad Inc. Strictly Confidential エンジニアの責任 

6 ©BrainPad Inc. Strictly Confidential 講義や研究などでとにかく動くものを作ることが 求められる 開発物への責任が大きくなる。自分が実装したコードが利益・損失・顧客満足へ直結する。 学生と社会人の開発の違い 学生時代 品質や利益に関する責任が大きくなる。 社会人 耐震性は？ メンテナンス性は？ 利益になる？ 

7 ©BrainPad Inc. Strictly Confidential バグやインシデントで顧客からの信頼を失う・余分な開発工数が発生する・チームのモチベーションが下がる 品質が悪いと何が起きるのか？ ヨロシク こことここも修正... これはどうやって追加しよう... プロダクト コスト コスト コスト コスト ① ② 開発が遅れてます。 あとシステムがダウンしました。 あとエンジニアが数人辞めました。 誠にすみません。 開発コスト コスト 

©BrainPad Inc. Strictly Confidential AIコーディングエージェント 

9 ©BrainPad Inc. Strictly Confidential 一般的な知識 よく知られているアルゴリズムの知識などが豊 富 ▲ 品質の保証 テスト書いてと指示したら非本質的なテストを 書くことがある ▲ ドメイン知識に基づいた設計 システムがどれくらい運用されるか？拡張・変 更の可能性がどのくらいあるか？など 現状のAIが得意なこと・苦手なことを整理する。 生成AIの得意なこと・苦手なこと 得意なこと 苦手なこと ちゃんと動くコードを素早く書く とにかくはやい。複雑ではない実装は人間より AIにやらせた方がいい。 

10 ©BrainPad Inc. Strictly Confidential 開発コストが指数的に増大する低品質システムが建築される（可能性が結構ある）。 つまり何も考えずにVibe Codingすると... プロダクト 全部OK！ 開発コスト 

©BrainPad Inc. Strictly Confidential AIのコードをレビューするための知識 

12 ©BrainPad Inc. Strictly Confidential ビジネスドメインの将来を見越した設計がなされ、拡張性と保守性に優れたシステムを目指すべきである。 目指すべき品質 追加機能OKです！ xx人月でいけます！ システム正常に動きます！ エンジニア xx人月あれば他部署 展開もできます！ 

13 ©BrainPad Inc. Strictly Confidential まずはリーダブルコード、クリーンアーキテクチャ、ドメイン駆動設計の三冊を読む。弊社のエンジニアではほぼ必読書 籍とされている。 必要な知識 コードレベルでのわかりやすさ システム全体のわかりやすさ こちらを簡単に解説します 

14 ©BrainPad Inc. Strictly Confidential システムに関する知識を具体と抽象で整理し、システムは具体から抽象の方向に依存関係を持つべきという設計思想。 以下はLLMチャットシステムの簡単な例である。 クリーンアーキテクチャ 抽象 （ドメイン知識） 具体 （非本質的） 認証・認可されたユーザーのみシステムを利用できる ユーザーはチャット形式で対話することができる ユーザーは過去の会話ログを閲覧することができる ユーザーは相手の回答のフィードバックを送信できる Firebase Authenticationを使って認証機能を実装する Reactを使う。Geminiで回答を生成する。 会話履歴はFirestore（NoSQL）で永続化する フィードバックはFirestore（NoSQL）で永続化する 依存の方向 

15 ©BrainPad Inc. Strictly Confidential 依存とは何か？以下は「テキストで回答する」という抽象的な知識が、OpenAIやMySQLという具体的な知識に深く依存し ている例である。 悪い例 

16 ©BrainPad Inc. Strictly Confidential 良い例 一方でこちらの実装は具体が抽象に依存している。OpenAIではなくGeminiに、MySQLではなくFirestoreにという意思決定 がしやすい。 

17 ©BrainPad Inc. Strictly Confidential 左側はクリーンアーキテクチャの全体像である。 チャットシステムの例で噛み砕くと右側の図のようになる。 クリーンアーキテクチャ エンティティ User、Chatのようなクラス ユースケース 回答を生成し、履歴を保存するというロジック コントローラー インタフェースを相互変換 インフラ Web APIやDB、UIなどの実装。 重要 重要じゃない ユースケース エンティティ コントローラー インフラ 

18 ©BrainPad Inc. Strictly Confidential 依存していい方向が決まっている 具体→抽象の方向で依存しなければいけ ない オブジェクトの粒度や依存関係に規律が生まれる。明確な規律があれば人間もAIもミスをしにくい。 つまり何がいいのか？ エンティティ User、Chatのようなクラス ユースケース 回答を生成し、履歴を保存するというロジック コントローラー インタフェースを相互変換 インフラ Web APIやDB、UIなどの実装。 データ構造そのもの ユーザーが何を実現したいか インタフェースの仲介 機能の提供、データの永続化など 各オブジェクトが単一の責務を持つ オブジェクトの種類や機能に着目して、 ファイル・ディレクトリに集約すると良 い 

19 ©BrainPad Inc. Strictly Confidential ビジネスロジックをモデル化し、ドメイン知識をドメイン層に集約するという設計思想。つまり、クリーンアーキテクチ ャでいうところのエンティティをどう設計するか？に近い。 ドメイン駆動設計 エンティティ User、Chatのようなクラス ユースケース 回答を生成し、履歴を保存するというロジック コントローラー ユースケースとインフラの橋渡し インフラ Web APIやDB、UIなどの実装。 エンティティ エンティティ ユーザーはid、username、emailを持つ 値オブジェクト usernameは50文字以内。 ドメインサービス usernameは被ってはいけない。 

©BrainPad Inc. Strictly Confidential まとめ 

21 ©BrainPad Inc. Strictly Confidential こんなことを考えながらVibe Codingしています。 まとめ できた！ ここ直して 依存関係 結合度・凝集度 ドメイン知識 動く？ システムの将来性 パフォーマンス セキュリティ 可読性 

22 ©BrainPad Inc. Strictly Confidential 品質とスピードはトレードオフではない。品質について学び、生成AIと協力することで爆発的に生産性が向上することはほ ぼ間違いない。 まとめ 品質無視のスピード開発 高品質開発 O(k ^ N) O(N) 開発コスト 

23 ©BrainPad Inc. Strictly Confidential 大体1.5ヶ月でインプット、残り1.5ヶ月でアウトプットしつつ定着させました。 私の学習スケジュール 2024/07 新卒研修 2024/8 2024/09 2024/10 空き ～～～～ 案件配属 社内案件で先輩のコードを読む 配属された案件で頑張る ※履修済み 

©BrainPad Inc. Strictly Confidential 24 使用素材： ● Gemini CLIロゴ（Apache2.0） ● Lobe Icons（MIT） ● いらすとや（20件まで可） ● TypeScript ロゴ © Microsoft, 商標使用ガイドラインに準拠 ● React ロゴ © Meta (旧Facebook), CC BY-SA 1.0 ● Vue.js ロゴ © Evan You, CC BY 4.0 ● Terraform ロゴ © HashiCorp, 公式ブランドガイドラインに準拠 ● Python ロゴ © Python Software Foundation, 商標使用ガイドラインに準拠 出典（表紙画像のみ使用）： ● 「Clean Archtecture」, Robert C. Martin, KADOKAWA, 2018. ● 「ドメイン駆動設計入門」, 成瀬 允宣, 翔泳社, 2020. ● 「リーダブルコード」, Dustin Boswell, オライリージャパン, 2012. 出典・引用