AI駆動開発によるDDDの実践 ディップ株式会社 CTO室 板⾕ 侑樹 

Copyright © DIP Corporation, All rights reserved. 自己紹介 名前：　板谷　侑樹 
 
 所属：　CTO室（開発組織を横断した取り組みをリード） 
 
 役割：
 ● Enablement Unit（社内での新しい取り組みを推進） 
 ● AI-Embedded Unit（プロダクトにAIを組み込む開発） 
 ● 認証基盤Unit　（複数プロダクトで共通して使う認証基盤の開発） 
 

ディップ株式会社 2000年：
 　インターネットの家庭普及率が18%の時代　 
 　求人広告業界初の「ポータルサイト」が誕生 
 
 2010年：
 　スマホ普及率が4%でガラケー全盛期の時代 
 　動画で仕事を探せる機能をバイトルに実装　 
 
 2019年：
 　ユーザーの働く課題を解決するために、 
 　AI・RPAを活用したDXサービスを開始 
 
 2024年：
 　日本初のAIと対話型バイト探しサービス 
 　『dipAI』を時代に先立ってリリース 
 
 

× “誰もが働く喜びと幸せを感じられる社会” Labor force solution company VISION Human work force solution ユーザーファーストな独⾃機能を搭載した、 求⼈情報‧⼈材紹介サービスの提供を通じて、 ユーザーの就業課題を解決しています。 ⼈材サービス事業 Digital labor force solution バイトコミュニケーションアプリ『バイトルトーク』や、 機能を絞ったシンプルなSaaS型の『コボット』を通じて、 職場環境やコミュニケーション課題を解決しています。 DX事業 

Agenda 1 AIコーディングツールの「理想と現実」 2 領域を見極める 3 AIに教える 4 まとめ：AIを使いこなすための 2つの戦略 

1. AIコーディングツールの「理想と現実」 

Copyright © DIP Corporation, All rights reserved. AIコーディングツールの「理想と現実」 ● Copilot, Claude Code, Cursorなど、AIコーディングツールがこの半年で急速に普及 ○ 開発組織のメンバーのうち 95％はなにかしらのツールを導入済み ● 理想と現実のギャップ ○ 理想 ■ AIが全てのコードを自動生成 ○ 現実 ■ お決まりのコードは速いが複雑な「ビジネスロジック」の生成や意図の伝達が困難 ■ AIを使うことで開発時間が 19%伸びるMETRの研究結果 (arxiv.org/abs/2507.09089) なぜAIはビジネスに最も価値のある「ビジネスロジック」の記述が難しいのか？ 

Copyright © DIP Corporation, All rights reserved. AIが「ビジネスロジック」を書くのが難しい理由 AI（特にLLM）の「得意なこと」と「ビジネスロジックのコードの性質」が根本的にミスマッチ ● AIは統計的なパターン学習をしている ○ インターネット上の膨大なコード（ =過去の正解データ）を統計的に学習している ○ LLM(Transformerモデル)は次のトークンを予測する確率モデル * ■ 予測を繰り返しているだけで内容を理解しているわけではないと言われている ● 得意なこと ○ 既知のパターン : 「認証」「 DB接続」「定型 CRUD処理」などよくある処理 ○ 明確な指示 : 「この配列をソートして」など意図が明確なタスクは得意 * Attention Is All You Need(arxiv.org/abs/1706.03762)
 

Copyright © DIP Corporation, All rights reserved. AIが「ビジネスロジック」を書くのが難しい理由 一方、「ビジネスロジック」は「暗黙知」の塊である ビジネスにおける最も価値ある「ビジネスロジック」は、 AIの学習データ（インターネット）には存在しない、その 会社独自の「暗黙知」で構成される ● 独自のロジック ○ 競争優位の源泉であり、「他社が真似できない、独自のビジネスルール」そのもの。 AIは過去に例 のない、全く新しいロジックの「創造」は苦手 ● 文脈依存 ○ ロジックの背景には、会社の歴史や業界特有の事情などのコード化されていない「文脈」が多くあ りこれらを知らない ● 曖昧な要求 ○ 要求は曖昧なビジネスの「意図」から始まるが、 AIはこの曖昧さを解釈できない 

Copyright © DIP Corporation, All rights reserved. AIの特性を理解し分担する ● 先述の通り AIコーディングツールはインターネット上の膨大なコード（ =過去の正解データ）を統計的 に学習しており、出力は統計による予測のため内容を正確に理解をしていないと言われている ● すべてをAIに任せるのではなく最初と最後は人が介入するのが現状の最適解 立上げ（人間） 人間がAIに意図や目的を理解させるための方針を決める 0->10 のフェーズ グロース（ AI） AIが意図や目的を元に AIが一気に作っていく 10->90のフェーズ 仕上げ（人間） ラストワンマイルを人間が意図を整理して仕上げていく 90->100のフェーズ https://www.youtube.com/watch?v=cTRzGzFi3LQ 

2. 領域を⾒極める 

Copyright © DIP Corporation, All rights reserved. 領域を⾒極める ドメイン駆動開発（ DDD）における最初の取り組みソフトウェアが扱う「業務領域」を区別する ● 中核領域 ○ ビジネスの競争優位の源泉。ユニークで複雑なロジック ● 一般領域 ○ 認証、決済など。 SaaSやライブラリで代替可能 ● 補完領域 ○ 中核を支えロジックは比較的単純だが独自開発が必要 💡この3つの領域を意識的に区別することが、 AI活用戦略の第一歩 https://www.oreilly.co.jp/books/9784814400737/ 

Copyright © DIP Corporation, All rights reserved. AI適⽤の「スイートスポット」はどこか？ ● 中核領域: 苦手 ○ 理由: ドメイン知識＝ビジネスの「暗黙知」が多すぎる ● 一般領域: 得意 ○ 理由: 既知のライブラリ利用など ● 補完領域: スイートスポット ○ 理由: 実装が必要だが単純なロジックが多い 

Copyright © DIP Corporation, All rights reserved. 補完領域からまずは使っていく https://speakerdeck.com/masuda220/learning-domain-driven-design-japanese-edition-findy-2024-7 

Copyright © DIP Corporation, All rights reserved. なぜ「補完領域」が効果的なのか？ ● 理由1: AIがコード生成しやすい ○ ロジックが比較的定型的（ CRUD操作、マスタ管理など） ○ AIにとって「何をすべきか」が明確 ● 理由2: 工数削減効果 (ROI) が高い ○ SaaSでは代替できない「独自開発」領域である ○ AI活用による工数削減メリットを直接享受できる 「補完領域」を AIが担当し、エンジニアは「中核領域」に集中させる 

Copyright © DIP Corporation, All rights reserved. 「補完領域」に区分できる判断例 ● LambdaやCloud Run Functionsで作れる処理 ○ コードが複雑になりにくい ○ それぞれの目的が明確 ● ELT, ETLのようなデータを扱うプログラム ○ ルールが単純で明確 ● RFCに準拠する機能 ○ 業務知識が入りづらい ○ インターネットに事例やドキュメントが豊富にある 

Copyright © DIP Corporation, All rights reserved. 「中核」も諦めない 究極のゴールは最も価値のある「中核領域」の開発を AIで加速させること ● どうやって AIに「ビジネスの暗黙知」を教えるか？ ● エンジニアだけではビジネスロジック（暗黙知）を AIに伝えきれない 

3. AIに教える 

Copyright © DIP Corporation, All rights reserved. AI-Driven Development Life Cycle (AI-DLC) ● AWSが提唱する AIと対話をして開発をする新しいフレームワーク ● AIからの質問に回答をすることで要件を客観的に理解し、自分たちが気づい ていない暗黙知や要件不足に気づかせてくれる ● エンジニアだけでなく、企画・ビジネスメンバーを巻き込むことが重要 https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/ 

Copyright © DIP Corporation, All rights reserved. AI-DLCは新しい開発のフレームワーク ● AWSのホワイトペーパーには “速い⾺⾞ではなく⾃動⾞が必要”(We need automobiles and not the faster horse chariots.)とあり、ウォータフォール‧アジャ イルを⾺⾞に例えて、それに代わる新しいフレームワークと説明 ● 会話を ⼈間 → AI に投げる従来の形から逆転させる ○ AI → ⼈間 に質問を投げかけて設計をしていく ○ ⼈間は判断をして承認をすることが主な役割 

Copyright © DIP Corporation, All rights reserved. AI-DLC (AI-Driven Development Life Cycle) 単なるCopilot導⼊ではない。「上流⼯程」からAIを組み込む STEP 1 抽象的な要求 STEP 2 AIがユーザーストーリー⽣成 STEP 3 AIが受⼊基準を策定 STEP 4 AIがタスク分解 

Copyright © DIP Corporation, All rights reserved. AIによる要件定義の効果 従来のプロセス •要求をヒアリング •ユーザーストーリーを手動作成 •受入基準（AC）を定義 •タスクに分解 → 数日〜数週間 AI-DLCのプロセス •抽象的な要求をAIに入力 •AIが「ユーザーストーリー」を自動生成 •AIが「受入基準（AC）」を自動生成 •AIが「タスク分解」まで支援 → 数時間 

Copyright © DIP Corporation, All rights reserved. 各種ツールも同じような手法を提供 2025/10のアップデートで各種ツールの Plan ModeでもInteractive Question Toolのような質問を通じて設計を作れるようになっている ○ Claude Code 2.0.22 ○ VS Code 1.106 ○ Cursor 2.0.21 

4. まとめ：AIを使いこなすための2つの戦略 

Copyright © DIP Corporation, All rights reserved. まとめ：AIを使いこなすための2つの戦略 見極める ● 開発領域（中核 /一般/補完）を見極める ● まずはROIが高い「補完領域」で AIを活用 教える ● 「中核領域」のために AIにドメイン知識を「教える」プロセスを導入 ● 企画サイドを巻き込み、 AIとの「対話」で暗黙知を明文化 ● AIと並走して開発をしていく 19 

Copyright © DIP Corporation, All rights reserved. ご清聴ありがとうございました