目的で駆動する、AI時代のアーキテクチャ設計 / purpose-driven-architecture

アーキテクチャConference 2025の登壇資料です。
https://architecture-con.findy-tools.io/2025

Transcript

1. © DMM © DMM 目的で駆動する AI時代のアーキテクチャ設計 2025/11/20 アーキテクチャConference 2025 合同会社DMM.com ミノ駆動
2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部 • コード品質チーム • PF-AX戦略グループ（兼務） 2
3. © DMM 3
4. © DMM 4 下記システムがDMMサービス全体の技術基盤となっています
5. © DMM コード品質チーム 正式名称： プラットフォーム開発本部／第3開発部／ Developer Productivity Group／コード品質チーム ソフトウェアの開発生産性向上に関する取り組みには、 開発プロセスの改善や自動化などがあります。 コード品質の改善によって開発生産性向上を図るのが 本チームのミッションです。 5
6. © DMM PF-AX戦略グループ 正式名称： プラットフォーム開発本部／第3開発部／ PF-AX戦略グループ プラットフォーム開発本部全体の 開発のAX（AI-Transformation）を担う組織です。 開発プロセスのAI化やAI技術検証、組織への展開などを行い、 AIによる組織的な開発生産性向上を狙います。 6
7. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 ITエンジニア本大賞2023技術書部門大賞受賞 台湾版、韓国語版でも翻訳出版 7
8. © DMM ここからが本題
9. © DMM AI駆動開発の広がり AIエージェントやコーディング特化型AIモデルの登場により、 AI駆動開発が本格的な広がりをみせています。 「AIがすごい速さで実装してくれた」 といった話題がSNS上で飛び交っています。 「プロダクションコードのうちxx%はAIが書いたコード」 といったニュースや報告もあります。 9
10. © DMM 新たな課題 一方で、AIによる開発の難しさや問題が上がってきています。 • AIの高速実装に伴い、技術的負債が加速度的に増加 • AIが混乱し、コード実装がいつまで経っても終わらない • AIが既存コードや環境を破壊する etc.. こうした問題があると、AIによる持続的開発が困難です。 せっかくAIを使っても開発がスケールしません。 AIによる持続的開発を可能にする、 なんらかのアプローチが必要です。 10
11. © DMM まずは 「持続的開発」 とは何かを整理します
12. © DMM ソフトウェア開発＝品質特性の作り込み 12 品質特性 説明 品質副特性 機能適合性 機能がニーズを満たす度合い 機能完全性、機能正確性、機能適切性 性能効率性 リソース効率や性能の度合い 時間効率性、資源効率性、容量満足性 互換性 他のシステムと情報共有、 交換できる度合い 共存性、相互運用性 使用性 利用者がシステムを満足に利用できる度合い 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユー ザーインターフェイス快美性、アクセシビリティ 信頼性 必要なときに機能実行できる度合い 成熟性、可用性、障害許容性、回復性 セキュリティ 不正利用から保護する度合い 機密性、インテグリティ、否認防止性、責任追跡性、真正性 保守性 システムを修正する有効性や効率の度合い モジュール性、再利用性、解析性、修正性、試験性 移植性 他の実行環境に移植できる度合い 適応性、設置性、置換性
13. © DMM ソフトウェア開発＝品質特性の作り込み 13 品質特性 説明 品質副特性 機能適合性 機能がニーズを満たす度合い 機能完全性、機能正確性、機能適切性 性能効率性 リソース効率や性能の度合い 時間効率性、資源効率性、容量満足性 互換性 他のシステムと情報共有、 交換できる度合い 共存性、相互運用性 使用性 利用者がシステムを満足に利用できる度合い 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユー ザーインターフェイス快美性、アクセシビリティ 信頼性 必要なときに機能実行できる度合い 成熟性、可用性、障害許容性、回復性 セキュリティ 不正利用から保護する度合い 機密性、インテグリティ、否認防止性、責任追跡性、真正性 保守性 システムを修正する有効性や効率の度合い モジュール性、再利用性、解析性、 修正性、試験性 移植性 他の実行環境に移植できる度合い 適応性、設置性、置換性 持続的開発で 特に重要なのがこれ！
14. © DMM 変更容易性（修正性） なるべくバグを埋め込まず、素早く正確にコード変更できる度合いを 変更容易性といいます。 変更容易性に問題のあるコードは複雑で混乱しています。 些細なコード変更でバグが埋め込まれやすい構造です。 バグを埋め込まないよう、慎重に修正検討しなければなりません。 なかなかコード変更できなくなるため、開発生産性が低下してしまいます。 ソフトウェアの持続的開発を可能にするには、 変更容易性が重要なポジションとなります。 14
15. © DMM ソフトウェアアーキテクチャとは ソフトウェアとはただ作っても品質特性が向上するものではなく、 なんらかの品質特性を促進するために意図をもって アーキテクチャを設計する必要がある、ということですね。 15 望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構 成するかに対する、重要な設計判断が集まったもの 『Design It!』著:Michael Keeling,訳:島田浩二,2019年刊行,オライリー・ジャパン,p.8より引用
16. © DMM アーキテクチャ代表例 16 アーキテクチャ 寄与する品質特性 クラウドネイティブアーキテクチャ 可用性、スケーラビリティ、拡張性など ゼロトラストアーキテクチャ セキュリティ パイプラインアーキテクチャ 再利用性、性能効率性など ヘキサゴナルアーキテクチャ 変更容易性 、テスト容易性 もちろん変更容易性を促進するための アーキテクチャもあります
17. © DMM ここまでの説明で 次のように考えた人がいるかも知れません
18. © DMM 「変更容易性とかアーキテクチャのことを プロンプトとして書けば AIがちゃんとやってくれるんじゃないの？」
19. © DMM 私はそうは思いません 実際AIに指示しても不十分な回答が返ってきます それだけでは持続可能な開発には 課題があります
20. © DMM AIによる持続的開発をより可能にするには もうひとつ大事な概念を取り入れる必要があります それが……
21. © DMM 目的 という概念 本セッションの重要テーマです
22. © DMM 目的が アーキテクチャやモジュールの構造に 大きく影響します
23. © DMM 本セッションでは AI時代において持続的開発を可能にするための 目的駆動の設計について解説します
24. © DMM 目的、目標、手段の定義 24 一般的な定義 目的 目指すべき状態、行動のねらい、目当て 目標 何をもって目的達成とみなすかを示す具体条件 手段 目的を達成するための方法や道具
25. © DMM 目的と手段 私たちの活動には、なんらかの目的があります。 そして目的を達成するための手段（行動や方法）を用います。 あらゆる活動が目的−手段の関係で成り立っています。 25 目的 手段 ダイエットしたい 有酸素運動 美味しいものを食べたい 寿司 髪を乾かしたい ドライヤー
26. © DMM 目的と目標 目的の達成について考えてみます。 たとえば「ダイエットしたい」という目的は、 どうしたら達成したと言えるでしょうか。自己満足して終わりですか？ そうではなく体重や体脂肪率について 具体的な条件や基準を定めるはずです。 この具体条件や基準が目標です。 26 目的 目標 ダイエットしたい ・体重を60kgまで減らすこと ・体脂肪率を17%まで減らすこと
27. © DMM 目的−目標−手段 そして目標を満たすために 適切な手段を用います。 目的、目標、手段の関係が右図となります。 目的、目標、手段の関係を適切に定義する ことで、確実に目的達成できます。 では逆に不適切だったら どうなるでしょうか？ 27 【目的】 ダイエットしたい 【目標】 ・体重60kgまで減らすこと ・体脂肪率を17%まで減らすこと 【手段】 ・有酸素運動 ・バランスの取れた食事
28. © DMM 定義が不適切だと目的達成困難 28 【目的】 ダイエットしたい 【目標】 ・体重40kg以下にすること 【手段】 ・絶食 ・ダイエット番組を見るだけ 身長170cmの人が40kgまで体重を 落とすと明らかに健康に害があります 絶食は健康を害したり、 リバウンドの原因になります ダイエット番組見ただけでは 絶対に痩せません！
29. © DMM 目的、目標、手段は、 私たちが開発するソフトウェアでも同じことが言えます。 顧客の要求（目的）を叶えるための手段として、 私たちはソフトウェアを開発しているのです。 29 目的 手段 商品を売買したい ショッピングサイト 動画を視聴したい 動画投稿サイト 遊びたい ゲームソフト 効率良く勉強したい 学習サイト 私たちは「手段」を開発している
30. © DMM 「目標」は要件や仕様に相当する 30 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 目的を満たすソースコード システムを不具合なく的確に機能させるには、 仕様を決める必要があります。 例えば注文数が負数だと不具合になりますし、 5000兆個といった非現実的な数量も 問題があります。 注文数については 出荷業務の都合などを考慮し仕様を決めます。 こうした要件や仕様が目標に相当します。 目標を満たすようにコードを実施します。
31. © DMM 目的、目標、手段は、ソフトウェア開発では次の位置付けと言えます 31 一般的な定義 ソフトウェア開発における位置付け 目的 目指すべき状態、 行動のねらい （顧客の）要求 目標 目的達成の具体条件 機能要件、仕様、制約 手段 目的達成に用いる 方法や道具 ソースコード
32. © DMM 32 // 注文明細クラス class OrderItem { int orderItemId; int orderId; int productId; int unitPrice; int quantity; // 注文数 } たとえばショッピングサイトにおける「注文」を考えてみます。 注文明細クラスを次のように実装したとします。 quantityは注文数です。
33. © DMM 33 orderItem.quantity = -1; この構造には問題があります。 マイナス注文数といった不正な値を代入できてしまいます。
34. © DMM 34 class Validator { boolean isValidQuantity(OrderItem orderItem) { return 1 <= orderItem.quantity && orderItem.quantity <= 200; } } 正しい注文数だけを受け付けられるよう、 次のようなバリデーションをどこかに実装するかもしれません。 しかしこの実装では、以下のような問題が生じる可能性があります。 • バリデーションを呼び忘れるとバグになる • 別の箇所に重複したコードが実装される可能性 • 注文数の仕様変更時、あちこち探し回らなければならない
35. © DMM 35 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 OrderItem.quantity 【手段】 Validator.isValidQuantityメソッド 目的に対して手段がバラバラになっているのが原因 家電に例えるとドライヤーがバラバラに提供されているような状態
36. © DMM 36 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 Quantityクラス バラバラにしない 目的を一貫して達成できるようひとまとめにする それがカプセル化
37. © DMM 37 class Quantity { private static final int MIN = 1; private static final int MAX = 200; final int value; Quantity(final int value) { if (value < MIN || MAX < value) { throw new IllegalArgumentException("注文数は1以上200以下で指定してください"); } this.value = value; } Quantity add(final Quantity other) { return new Quantity(value + other.value); } } カプセル化とはデータとそのデータを操作するロジックをひとま とめにすること。これで正しい注文数を確実に表現できる。
38. © DMM 38 class YearlyPointBonus { int value; YearlyPointBonus(PurchaseHistory purchaseHistory, boolean isGoldMember) { value = (int)(purchaseHistory.yearlyAmount() * 0.01); if (isGoldMember) { value += 10000; } } } 会員ランク 年間ポイントボーナス仕様 一般会員 年間購入費の1% ゴールド会員 年間購入費の1% + 10000ポイント ショッピングサイトにおけるポイントボーナスを考えてみます。 この仕様を下記のように実装したとします。
39. © DMM 39 class YearlyPointBonus { int value; YearlyPointBonus(PurchaseHistory purchaseHistory, boolean isGoldMember) { value = (int)(purchaseHistory.yearlyAmount() * 0.02); if (isGoldMember) { value += 10000; } } } 会員ランク 年間ポイントボーナス仕様 一般会員 年間購入費の1% ゴールド会員 年間購入費の2% + 10000ポイント ゴールド会員側の仕様が2%に変わり、0.02に実装修正すると、 一般会員側が正しく計算できなくなります。バグになります！
40. © DMM 40 【目的】 一般会員の年間ポイントボーナスを 計算したい 【目標】 年間購入費の1% 【手段】 YearlyPointBonusクラス 【目的】 ゴールド会員年間ポイントボーナスを 計算したい 【目標】 年間購入費1% + 10000ポイント 手段であるYearlyPointBonusが 異なる目的に使い回されているのが原因
41. © DMM 41 【目的】 一般会員の年間ポイントボーナスを 計算したい 【目標】 年間購入費の1% 【手段】 RegularYearlyPointBonusクラス 【目的】 ゴールド会員年間ポイントボーナスを 計算したい 【目標】 年間購入費1% + 10000ポイント 目的それぞれで手段を分ける これが関心の分離 【手段】 GoldYearlyPointBonusクラス
42. © DMM 42 class RegularYearlyPointBonus { private static final double POINT_RATE = 0.01; final int value; RegularYearlyPointBonus(final PurchaseHistory purchaseHistory) { value = (int)(purchaseHistory.yearlyAmount() * POINT_RATE); } } class GoldYearlyPointBonus { private static final double POINT_RATE = 0.01; private static final int FIXED_POINT_BONUS = 10000; final int value; GoldYearlyPointBonus(final PurchaseHistory purchaseHistory) { value = (int)(purchaseHistory.yearlyAmount() * POINT_RATE) + FIXED_POINT_BONUS; } } このように目的ごとに分離することで コード変更影響が生じなくなります。変更に強くなります。
43. © DMM ここまでの説明で 次のように考えた人がいるかも知れません
44. © DMM 「別にわざわざ目的なんて考えを持ち出さなくても カプセル化と関心の分離で説明がつくのでは？」
45. © DMM 目的（要求）と変更容易性は地続きである 要求定義とモジュール設計は違うフェーズのものであり、 モジュール設計時にわざわざ要求定義を踏まえていない、 というのが多くの開発現場で起こっていることではないでしょうか？ しかし前述したように構造化は目的単位であることがわかります。 変更容易性の高い構造の設計には目的は不可欠であり、 目的すなわち要求がモジュール構造と地続きになっている、 というのが目的という概念を持ち出す最大の理由です。 45
46. © DMM 背後にあるのはドメイン駆動設計の考え そしてこの「目的ごとに構造化する」というのは、 実はドメイン駆動設計の考え方を言い換えたものです。 DDDは複雑な問題の解決手段をドメインモデルで構造化する手法。 「じゃあ目的じゃなくてDDDでいいんじゃないの？」 とツッコミがあるかもしれませんが、 「ドメイン」という言葉よりも「目的」の方が馴染みやすいですし、 なにより目的の方が「目的−目標−手段」の関係性で整理しやすいです。 そしてそれだけではなく、 目的を用いた方がさらにアドバンテージがあります（後述）。 46
47. © DMM 「境界付けられたコンテキスト」は大粒度の目的 DDDに登場する「境界付けられたコンテキスト」はいささか分かりにくそう な概念ではありますが、「大きな粒度の目的」と解釈すると腹落ちします。 47 在庫コンテキスト 注文コンテキスト 配送コンテキスト 【大目的】 在庫 【大目的】 注文 【大目的】 配送
48. © DMM アーキテクチャの各レイヤにも目的がある 48 Domain層 目的 : 業務活動を表現するデータの正確な作成、更新 Use Case層 目的 : ユースケースの解決 Presentation層 目的 : クライアント入出力の解決 Infrastructure層 目的 : DBやクラウドサービスといった外界 とのやり取り
49. © DMM 「契約による設計」で目標を厳密に定める 契約による設計とは、正確性の向上を目的に バートランド・メイヤー氏が考案した設計の方法論。 • 事前条件：メソッド開始時に保証されるべき条件 • 事後条件：メソッド終了時に保証されるべき条件 • 不変条件：常に維持されるべき条件 モジュールの機能適合性を保証するテストはこの3条件の検証が基本。 上記3条件は「目的−目標−手段」における目標に相当。 「目的を確実に達成するためにどんな目標が必要か」と考えることで 条件をより的確に設計できます。 49
50. © DMM 目的を教示するとAIの回答精度が向上する そして目的を持ち出す理由として特に重要なのがこれ。 AIの回答精度を高める指示の仕方として有名なテクニックですが、 AIに目的を伝えると回答精度が向上します。 この延長上にあるのがコンテキストエンジニアリング。 目的の背後にある前提や状況をAIに伝えて より的確な回答を生成するアプローチ。 50 # 目的 ◯◯したい # 命令 あなたの仕事はxxxすることである
51. © DMM さてこのように 目的駆動で設計やアーキテクチャを AIに教示すると何が起こるかというと……
52. © DMM AIの判断力がめちゃめちゃ向上します 【変更容易性の高いコード実装】 AIが目的の違うコードを別々のクラスに分けて実装します。 つまり変更容易性の高いコードをAIが書けるようになります。 【コードリーディング性能向上】 コードそれぞれの目的の違いを見分けられるようになります。 「このコードはクレジットカード決済を目的としているCardSettlement クラスにあるべき」といった判断ができるようになります。 【実装の正確性向上】 契約による設計が「ガードレール」になっているのもあり、 AIが迷走せず正確に実装できるようになります。 52
53. © DMM つまり 「AIによる持続的開発を促進できる」 ということを意味します
54. © DMM さてここまでの説明で AIによる持続的開発を推進する上で 目的がいかに重要かを ご理解いただけたかと思います
55. © DMM しかしそうは言っても なかなか上手くいかない現実があります それが……
56. © DMM 目的の認知が難しい問題
57. © DMM 57 こういう仕事をしていませんか？ 仕様書だけ渡され 単に仕様を満たす実装 だけしている 仕様書を書いて プログラマに仕様書を渡し 実装をマルナゲしている 実装と動作させること だけが仕事のゴールに なっている 技術には関心があるが 顧客要求（目的）には ほとんど関心がない こういう仕事の仕方で目的を意識したり理解できるものでしょうか…？
58. © DMM 58 【目標（仕様）】 年間購入費の1% 【手段】 YearlyPointBonusクラス 【目標（仕様）】 年間購入費1% + 10000ポイント 仕様は目的ではありません、目標に相当します。 仕様書だけ眺めていても目的は分かりません。 つまり変更容易性の設計が困難であることを意味します！！
59. © DMM AI駆動開発を推進しても 目的がモジュール構造に影響することを 人間が理解していなければ AIによる持続的開発は困難です まず目的に目を向けるよう意識改革したり 仕事の取り組み方を変える必要があります
60. © DMM 60 ボールペン のり 付箋 はさみ ホッチキス 修正液 別に難しいことを言ってるわけではありません。 みなさん、普段道具を目的ごとに収納していますよね。 ファイルを目的ごとに区分してフォルダに入れてますよね。 PCのデスクトップにファイルが散らかってるわけがないですよね！？
61. © DMM 61 【目的】 普通注文したい 【目的】 予約注文したい 【目的】 抽選注文したい 【手段】 注文クラス こうであっちゃいけないわけです 注文方式それぞれで取り扱うデータやロジックが違います （こういう構造は内部で注文方式をフラグで切り替えている）
62. © DMM 62 【目的】 普通注文したい 【目的】 予約注文したい 【目的】 抽選注文したい 【手段】 予約注文クラス 手段に対して目的がひとつに定まるよう 設計しなきゃいけないわけです 【手段】 普通注文クラス 【手段】 抽選注文クラス
63. © DMM 63 道具箱 フライパン トイレ用ラバーカップ 最悪なのがこういうケース！明らかに異常なのは一目瞭然。 しかしソースコードは味も臭いもしないので、 一緒にして良いものかどうか判断がつきにくい。 コードの目的を見破れるようになりましょう。
64. © DMM さて本セッションはAIがテーマですが AIのテクニックにはほとんど触れていません 目的目標手段という物事を整理する基本や 「カプセル化」「契約による設計」といった ソフトウェア設計の原理原則しか語っていません
65. © DMM つまり
66. © DMM AI時代においても 論理的思考力や ソフトウェアの原理原則 しか勝たない
67. © DMM 基本こそ奥義
68. © DMM 日進月歩なAI技術に右往左往せず 今こそ 基本に立ち返ろう
69. © DMM 今日からあなたができること
70. © DMM 70 目的−目標−手段で物事を整理する考え方は この本で深く学べます
71. © DMM 仕事のタスクを目的−目標−手段で書こう 71 【Issueタイトル】 検索結果画面の表示速度改善 # 目的 ユーザーが快適にアプリを使えるようにし、離脱率を下げたい # 目標（目的の達成条件） 主要な検索キーワードに対する検索結果の初期表示時間を2秒以内にすること # 手段 クエリの実行計画を分析し、不要なJOINを削減する GitHubのIssueやタスク管理ツールのチケットを次の形式で書こう
72. © DMM 72 目的単位で構造化する設計は 拙著『改訂新版　良いコード／悪いコードで学ぶ設計入門』 で学べます
73. © DMM ご清聴ありがとうございました