AI時代の戦略的アーキテクチャ〜Adaptable AI をアーキテクチャで実現する〜 / Enabling Adaptable AI Through Strategic Architecture

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 Copyright © 2025 Bitkey Inc. All right reserved. 自己紹介佐藤拓人 Sato Takuto 2015.04 2019.05 2020.01 大学(建築学専攻)卒業後、株式会社ワークスアプリケーションズに入社会計システムのソフトウェア開発を担当特に財務会計の仕訳関連ビットキーへ参画 ECサイトの開発 / 保守、社内システムの開発 TaKuTyの開発今のhomehub事業の前身となるResidenceチームに配属。スマートロックを扱う管理画面やバックエンド、スマホアプリの開発に従事 Now homehub事業のプロダクト責任者複雑な事象を読み解いて構造化し、抽象化 / 汎用化できるように設計し、低コストで多くの価値をだせる開発をすることを好む

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 Copyright © 2025 Bitkey Inc. All right reserved. 自己紹介佐藤拓人 Sato Takuto Background 〜どんな環境でAIと向き合っているの？〜 1. サーバーサイドメイン + Webフロント 2. 既存プロダクトの機能拡張メイン 3. 事業ドメインは「カギ」を扱う領域 4. スタートアップでローンチしてから7年程度 5. homehubという事業領域の中のコア部分の開発がメインのチーム 6. 言語はTypeScript、インフラはGoogle Cloud、IDE はCursor

Slide 9

Slide 9 text

9 Copyright © 2025 Bitkey Inc. All right reserved. 自己紹介佐藤拓人 Sato Takuto Background 〜どんな環境でAIと向き合っているの？〜 1. サーバーサイドメイン + Webフロント 2. 既存プロダクトの機能拡張メイン 3. 事業ドメインは「カギ」を扱う領域 4. スタートアップでローンチしてから7年程度 5. homehubという事業領域の中のコア部分の開発がメインのチーム 6. 言語はTypeScript、インフラはGoogle Cloud、IDE はCursor

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

28 Copyright © 2025 Bitkey Inc. All right reserved. 根拠１：AIは責任を果たすことが難しい・法的責任　：　　AIは契約の当事者になれない、訴訟の対象にならない・経済的責任：　　AIには賠償能力がない、保険の対象にならない・説明責任　：　　AIは「なぜそうしたか」をステークホルダーに説明しきれない・継続的責任：　　AIは長期的なメンテナンスにコミットできない・社会的責任：　　AIは倫理的判断の主体になれない ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

Slide 29

Slide 29 text

29 Copyright © 2025 Bitkey Inc. All right reserved. 根拠その２：人間はAIを信頼しきれるのか？・利用者側の視点で... 　　・プロダクトを安心して利用できるか？　　・トラブルがあった際に適切にサポートを受けることができるか？　　　and more… ・プロダクト提供側の視点で... 　　・ビジネス価値や必要な要件は漏れなく提供できているか？　　・セキュリティやコンプライアンス観点で問題ないか？　　・機能追加や不具合修正でデグレを引き起こさないか？　　　and more… ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

42 Copyright © 2025 Bitkey Inc. All right reserved. AI開発のダークサイド：「Vibe-Driven Development」の脅威 Vibe CodingをはじめとするAIを使ったコーディングは非常に強力であるがリスクもある 1. 定量的リスク：　AI生成コードの45%にセキュリティ脆弱性。AIによる自己レビューの正解率は63-68% 2. 保守性の崖：　「ほぼ正しい」コードが微妙なバグを増殖させ、デバッグコストが増大 3. 確率的負債：　従来の技術的負債と異なり、なぜそう動くか説明不可能な「確率的」な負債が蓄積 4. 組織的リスク：　知識がAIに集中し、チームの「バス係数（Truck Factor）」が低下する（＝リスク増大） 2. 課題：「責任」を脅かすカオス

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

48 Copyright © 2025 Bitkey Inc. All right reserved. 妄想：責任のインフレ・量的なインフレ：　　・AIが加速するほど、AIでは難しい「倫理的・法的判断」が人間に「凝縮」され責任が増大する。・質的なインフレ：　　・AIの成果物を信頼しがたく、求める責任の水準が上昇する　　・AIにより非エンジニアのリテラシーが向上し、定量的な信頼性と適切な説明責任が求められる ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

Slide 49

Slide 49 text

49 Copyright © 2025 Bitkey Inc. All right reserved. 妄想：責任のインフレ・量的なインフレ：　　・AIが加速するほど、AIでは難しい「倫理的・法的判断」が人間に「凝縮」され責任が増大する。・質的なインフレ：　　・AIの成果物を信頼しがたく、求める責任の水準が上昇する　　・AIにより非エンジニアのリテラシーが向上し、定量的な信頼性と適切な説明責任が求められる ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」エンジニアとしてどう備えるか？どう検査するか？

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

69 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 戦略・できるだけAIに委ねて、主観領域の検査削減・SLOは監視し閾値を超えたら修正をする ◼ 4象限・「客観 x 予防」と「客観 x 回復」がメイン・問題検知時に人間がサポートして対応 ◼ 補足・障害検知 → リカバリもAIでできるように組　めば理論上主観の検査は不要とできる・市場で問題が発生するリスクがあるので、受　容できるか次第 3. 戦略的な「検査」ケーススタディ２：ブログサービス / LPなど

Slide 70

Slide 70 text

70 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 戦略・実装はAIに委ねる・事前に最低限のユースケースや、コンポーネ　ントテストの網羅は確認する ◼ 4象限・「客観 x 予防」と「客観 x 回復」はあるが、　「主観 x 予防」が防波堤として機能させる ◼ 補足・事業特性やプロダクト規模や構造によって、　主観 x 予防領域の検査強度は強める 3. 戦略的な「検査」ケーススタディ３：領域が限定的なマイクロサービスなど

Slide 71

Slide 71 text

71 Copyright © 2025 Bitkey Inc. All right reserved. SREという観点も非常に有益です。「客観 x 回復」の検査を大幅に拡充できます今後はAIがメトリクスを計測し、閾値を下回ったら原因をAIが分析し修正した上でメトリクスを監視することが人間がいなくとも実現可能となります。事業によっては、ある程度のリスクを受容して「主観x予防」の検査を排除して、「客観x予防」「客観x回復」の検査のみとする選択肢も検討することとなると思います。 3. 戦略的な「検査」補足：「SRE」も重要！！

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

77 Copyright © 2025 Bitkey Inc. All right reserved. 「主観」領域の検査にかかるコストの本質は認知負荷です。(主にレビューなど) 認知負荷を低減する有効な手段がアーキテクチャです「絡み合った毛糸玉」を「積み木」のような状態に構造的・強制的に分解する唯一の方法がアーキテクチャだからです。そしれこれは主観領域の検査負荷低減だけでなく「客観x予防」「客観x回復」領域の精度向上も期待できます。「主観」領域の検査にかかるコストを最小化するには？ 4. 解決：Divide and Conquer

Slide 78

Slide 78 text

78 Copyright © 2025 Bitkey Inc. All right reserved. ・観点1：限られた範囲で検査可能とする　　・AIの自律性を許容する「境界」を定義し、影響範囲を限定することで、AIの「ブラックボック　　　ス」な振る舞いを検査容易な状態にできる・観点2：人間が認知しやすい状態を維持する　　・人間が認知しやすい単位で分割することで、全体の調整をしやすくするとともに、認知負荷を低　　　減することができるなぜ「Divide and Conquer」が重要なのか？ 4. 解決：Divide and Conquer

Slide 79

Slide 79 text

Slide 80

Slide 80 text

80 Copyright © 2025 Bitkey Inc. All right reserved. 将来的には、人間が行う「検査」は、コードの確認ではなくなる。コードではなく「AIの思考」を検査することとなる最終的に人間は法理や倫理協定を作成し、これに則って AIが活動しているかを監視することとなると予想します。このような世界線になるとしても、プロダクトを構造的に整理された状態を維持することは有益であり、そのような世界線であってもアーキテクチャは重要であると考えます。妄想：「検査」 = 「コードレビュー」か？ 4. 解決：Divide and Conquer

Slide 81

Slide 81 text

81 Copyright © 2025 Bitkey Inc. All right reserved. 具体的な方法 1. 境界づけられたコンテキスト (Bounded Context) 2. Event-Driven Architecture 3. CQRS (Command Query Responsibility Segregation) 4. AVDM (Always-Valid Domain Model) 5. Type First 6. Event Sourcing 4. 解決：Divide and Conquer

Slide 82

Slide 82 text

82 Copyright © 2025 Bitkey Inc. All right reserved. 具体的な方法 1. 境界づけられたコンテキスト (Bounded Context) 2. Event-Driven Architecture 3. CQRS (Command Query Responsibility Segregation) 4. AVDM (Always-Valid Domain Model) 5. Type First アプローチ 6. Event Sourcing 4. 解決：Divide and Conquer 「責任」「信頼」のための検査しやすいアーキテクチャ

Slide 83

Slide 83 text

83 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 説明： DDDで登場する概念で、システム的に独立して開発・運用することができる単位を定めます。境界づけられたコンテキストを定義するためにイベントストーミングなどの手法が用いられます。 ◼ 意義： AI特有の「予測不能な振る舞い」や「意図しない副作用」によるカオスを遮断します。影響範囲を限定することで人間が「責任」を「検査可能」なサイズに留めるための、最も重要な「防波堤」として機能します。またコンテキストごとに異なる検査戦略をとることを可能とする点でも非常に有益です。 ◼ 具体例 Before: 境界がないモノリシックな実装 After: 「注文」「支払」などのコンテキスト境界の定義境界づけられたコンテキスト (Bounded Context) 4. 解決：Divide and Conquer

Slide 84

Slide 84 text

84 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 説明：境界づけられたコンテキスト間のやり取りを、「直接的な命令(同期呼び出し)」ではなく、「イベント(発生した事実)」の通知によって非同期で行う設計アプローチです。 ◼ 意義：「境界づけられたコンテキスト」が「分割(Divide)」という設計 (地図)だとすれば、EDAはその分割を「強制(Conquer)」し、統治するための「交通ルール」です。境界づけられたコンテキスト間を疎結合に保つことを促進させることができます。 ◼ 具体例 Before: 境界の定義があるがソースコードは密結合 After: 境界間のやり取りはイベントを介して非同期に実施 Event-Driven Architecture 4. 解決：Divide and Conquer

Slide 85

Slide 85 text

85 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 説明：コマンド(Command)とクエリ(Query)の責務を分離するという設計パターンです。 ◼ 意義：境界づけられたコンテキスト内をさらにCommand / Queryという観点で分割し認知負荷を低減します。またCommand / Queryで分割することで、検査強度のコントロールを実現しやすくします。 Commandの部分を高強度で検査しつつも、Queryの部分か簡易的な検査で済ませるといった戦略を可能とします。 ◼ 具体例 Before: 登録や更新、取得の処理やDBの構造も混在している After: Command/Queryの観点で処理やDBが分割されている CQRS (Command Query Responsibility Segregation) 4. 解決：Divide and Conquer

Slide 86

Slide 86 text

86 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 説明： Always-Valid Domain Model（常に有効なドメインモデル）とは、ドメインモデル（ビジネスの概念を表現するオブジェクト）が、その生成時から一貫して「常に有効な（=不正な状態を持たない）」状態であることを保証するDDDの設計原則です。 ◼ 意義： AVDMは、「Vibe(直感)」を排除し、「Spec(仕様)」をコードレベルで強制することを可能とします。AIがもたらす確率的な問題をコードレベルで防ぐことが可能となり、主観でチェックしなければならない絶対量を減少させることができます。 ◼ 具体例 Before: DTOスタイル (レビューコスト：高) After: Always-Valid Domain Model (レビューコスト：低) AVDM (Always-Valid Domain Model) 4. 解決：Divide and Conquer

Slide 87

Slide 87 text

87 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 説明：状態や制約を「型」で表現することで、不正な操作をコンパイル時など事前に検出するアプローチです。AVDMをさらに促進し、単一のドメインモデルの中でも状態や制約による分解を促進させることができます。 ◼ 意義： AVDMのメリットをさらに促進させます。実行時エラーではなく Build時のチェックで事前に防ぐことができます。AVDMと比較してよりソースコードレベルで強い制約を課すことが可能となります。型で表現できる制約の幅が広がり、AIの成果物の精度向上が期待できます。 ◼ 具体例 Before: 1つのクラスに全状態が混在 (レビューコスト：高) After: Type Firstによる状態の分離 (レビューコスト：低) Type First 4. 解決：Divide and Conquer

Slide 88

Slide 88 text

88 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 説明： Event Sourcing（イベントソーシング）は、システムの状態を管理する方法の一つです。現在の「状態」を保存するのではなく、「何が起きたか」という全ての「事実（イベント）」を時系列で記録する手法です。 ◼ 意義：モデルという単位からさらにイベントという単位で細分化することを可能とします。「結果」だけでなく、そこに至る全ての「経緯」が事実(イベント)として残るため、過去の追跡による厳格な検査や、SLO等の精緻な計測が可能となり、高度な説明責任を果たせます。 ◼ 具体例 Before: 状態ベースのモデル（「なぜ」が失われる） After: イベントソーシング（全ての「なぜ」を記録） Event Sourcing 4. 解決：Divide and Conquer

Slide 89

Slide 89 text

89 Copyright © 2025 Bitkey Inc. All right reserved. 具体的な方法 1. 境界づけられたコンテキスト (Bounded Context) 2. Event-Driven Architecture 3. CQRS (Command Query Responsibility Segregation) 4. AVDM (Always-Valid Domain Model) 5. Type First 6. Event Sourcing 4. 解決：Divide and Conquer

Slide 90

Slide 90 text

Slide 91

Slide 91 text

Slide 92

Slide 92 text

Slide 93

Slide 93 text

93 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 概要：段階的に導入。特にEvent-Driven ArchitectureやCQRSは切り戻しやすい程度に実施。プロダクト全体に少しずつ導入する方法と、特定領域でがっつり試してみる2つのアプローチで実行。 ◼ プロダクト全体： AVDMを優先的に実施。境界づけられたコンテキストの整理や CQRSも順次実施するが、無理のない範囲で段階的に実施。Type FirstやEvent Sourcingは親和性の高い領域のみで実施。 ◼ AI特区既存実装をリファクタリングして実施中。Event Sourcingなどは既存のデータ構造も配慮しながら実現をする。Event-Driven ArchitectureやCQRSは既存の実装の状況などを加味して無理のない範囲で実行する。 5. 補足：私の現在地戦略・方針

Slide 94

Slide 94 text

94 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 境界づけられたコンテキストイベントストーミングベースで整理をしているが洗練中。戦略/ ルールを明確に分けるには至っておらずでこれから。 ◼ Event-Driven Architecture & CQRS 部分的な適用に留めている。切り戻しやすさなどを考慮してメリットのある部分を適用。CQRSとしても分割がメインであれば DBを分けずとも実現は可能で、実際にDB分けずに処理のみを分けて管理している範囲がほとんど。 ◼ AVDM 全面的に採用して推進。 ◼ Type First & Event Sourcing ゴリゴリに推進していない。新規性がありイベントとの親和性が高い領域でのみ採用して進めている 5. 補足：私の現在地プロダクト全体

Slide 95

Slide 95 text

95 Copyright © 2025 Bitkey Inc. All right reserved. ◼ 境界づけられたコンテキストプロダクト全体の整理と同様。関連箇所のみ実際の実装を通して理解や境界の整理が進んでいる ◼ Event-Driven Architecture & CQRS 部分的な適用に留めるが、分割を強制しやすい構造をベースにリファクタしながら進めている。 ◼ AVDM 全面的に採用して推進。 ◼ Type First & Event Sourcing 全面的に採用して推進。既存のデータとの整合性はとるための配慮はして推進。 5. 補足：私の現在地 AI特区

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

98 Copyright © 2025 Bitkey Inc. All right reserved. ◼ プロダクト全体 AI関係なく、コンテキストの整理は全体の見通しがたちやすくなるため有意義。チーム全体でメンタルモデルを作り込むために定期でケーススタディを継続的に実施中。AVDM, CQRSで比較的レビューは簡易化されたと感じる。修正されるファイルでレビュー強度を調整できる。 ◼ AI特区まだまだ試験的な部分はある (プロダクションリリース未達) が、 AIの生成に任せられる範囲は明確に増えるように感じる。単体テストは事前にいくつかお手本を作りこんでおくことで、だいぶ信頼できるものが生成される。ファイルを分割する分全体のコード量は増加傾向。またファイルを分割することで実行のステップをルール化しやすい。 5. 補足：私の現在地どうなった？どうだった？

Slide 99

Slide 99 text

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Slide 102

Slide 102 text

102 Copyright © 2025 Bitkey Inc. All right reserved. 6. 結び：まとめ 1. 人間の価値は「コードを書く」ことから、「責任を負う」ことへと移行する 2. Vibe Codingはセキュリティ脆弱性、保守性の崖、法的リスクをもたらしうる 3. 責任は遂行するために検査が必要である 4. 検査を4象限で整理することで、事業特性ごとの戦略を立てることができるまとめ

Slide 103

Slide 103 text

Slide 104

Slide 104 text

104 Copyright © 2025 Bitkey Inc. All right reserved. 1. 人間の価値は「コードを書く」ことから、「責任を負う」ことへと移行する 2. Vibe Codingはセキュリティ脆弱性、保守性の崖、法的リスクをもたらしうる 3. 責任は遂行するために検査が必要である 4. 検査を4象限で整理することで、事業特性ごとの戦略を立てることができる 5. 中でもアーキテクチャによって、「主観 x 予防」の領域を中心に大きく改善できる 6. 結び：まとめまとめ

Slide 105

Slide 105 text

Slide 106

Slide 106 text

Slide 107

Slide 107 text

107 Copyright © 2025 Bitkey Inc. All right reserved. 1. 人間の価値は「コードを書く」ことから、「責任を負う」ことへと移行する 2. Vibe Codingはセキュリティ脆弱性、保守性の崖、法的リスクをもたらしうる 3. 責任は遂行するために検査が必要である 4. 検査を4象限で整理することで、事業特性ごとの戦略を立てることができる 5. 中でもアーキテクチャによって、「主観 x 予防」の領域を中心に大きく改善できる 6. AIを恐れるのではなく、AIを「適応（Adapt）」させるアーキテクチャを設計し、　未来の「信頼」を構築することこそが、我々のミッションである 6. 結び：まとめまとめ