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

© 2025 Bitkey Inc. AI時代の戦略的アーキテクチャ〜Adaptable AI をアーキテクチャで実現する〜株式会社ビットキー佐藤拓人
2025/11/20

2 Copyright © 2025 Bitkey Inc. All right reserved. 0.
前提：本発表のスタンス

3 Copyright © 2025 Bitkey Inc. All right reserved. AIをどう使うか
(How to) 　より　どう向き合うか (Why / What) 0. 前提：本発表のスタンス

4 Copyright © 2025 Bitkey Inc. All right reserved. 短期的な実利
(プロンプト) 　より　中長期的な備え (アーキテクチャ) 0. 前提：本発表のスタンス

5 Copyright © 2025 Bitkey Inc. All right reserved. [keyword]
「責任」「信頼」「分割」「統治」 0. 前提：本発表のスタンス

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

佐藤拓人 Sato Takuto

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

14 Copyright © 2025 Bitkey Inc. All right reserved. ・誰がいつどこにアクセスできるかを管理
・アクセスするために必要な処理を実施様々なユースケースに対して利便性と安全性を向上するための機能拡張を実施

15 Copyright © 2025 Bitkey Inc. All right reserved. 目次
0. 前提：本発表のスタンス 1. 構想：AIの進化と人間の新たな「役割」 2. 課題：「責任」を脅かすカオス 3. 戦略：戦略的な「検査」 4. 解決：Divide and Conquer 5. 補足：私の現在地 6. 結び：まとめ

構想：AIの進化と人間の新たな「役割」

構想：AIの進化と人間の新たな「役割」 AI時代の生存戦略よく見かけるパターン 1. AIが苦手な領域で勝負する 2. AIをうまく活用できるようにする 3. AIを使って自身の能力を高める

18 Copyright © 2025 Bitkey Inc. All right reserved. 「Claude
Code時代のソフトウェアエンジニア生存戦略」by すてぃおさんポジショニング戦略が鍵・「AIディレクター型」・「アーキテクト特化型」・「ドメインエキスパート型」・「AI回避型」・「ビジネス統合型」 1. 構想：AIの進化と人間の新たな「役割」

19 Copyright © 2025 Bitkey Inc. All right reserved. 「AI時代のソフトウェア開発を考える」by
t_wada さん・AIで時が加速したが、問題の構造、根本的原因は同じ。歴史から学んだ知見が今こそ重要・AIから引き出せる性能は、個人と組織の能力に比例する。能力向上への投資が不可欠 1. 構想：AIの進化と人間の新たな「役割」

20 Copyright © 2025 Bitkey Inc. All right reserved. 「AI時代、“平均値”ではいられない」by
uhyo さん・AIを超える技術力が必要・創造的になる必要がある 1. 構想：AIの進化と人間の新たな「役割」

21 Copyright © 2025 Bitkey Inc. All right reserved. (前提として...)
AIはいずれ人間を凌駕するものとして備えておくべき ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

22 Copyright © 2025 Bitkey Inc. All right reserved. 人間にしかできない領域がある？
・設計は人間にしかできない？・提案はAIにできない？・AIには創造性はない？ … 1. 構想：AIの進化と人間の新たな「役割」

23 Copyright © 2025 Bitkey Inc. All right reserved. 人間にしかできない領域がある？
・設計はAIにできない？・提案はAIにできない？・AIには創造性はない？ … 1. 構想：AIの進化と人間の新たな「役割」ほんとうに？

24 Copyright © 2025 Bitkey Inc. All right reserved. AIはいずれ人間を凌駕する
そしてそれは段階的に行われる ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

25 Copyright © 2025 Bitkey Inc. All right reserved. 何が残るのか？
※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

26 Copyright © 2025 Bitkey Inc. All right reserved. 「責任」と「信頼」
※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

27 Copyright © 2025 Bitkey Inc. All right reserved. 「責任」と「信頼」
※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」なぜ？

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

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

30 Copyright © 2025 Bitkey Inc. All right reserved. AIの「責任」「信頼」は
構造的/技術的には解決可能かもしれないが社会的/感情的に受け入れ難いのでは？ ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

構想：AIの進化と人間の新たな「役割」人間の役割は「責任」と「信頼」

39 Copyright © 2025 Bitkey Inc. All right reserved. (仮説)
人間が責任を取るステークホルダーはその人間を介してプロダクトを信頼をする構造はしばらく維持されるのでは？ ※ 個人的な意見 / 考え方です 1. 構想：AIの進化と人間の新たな「役割」

40 Copyright © 2025 Bitkey Inc. All right reserved. 変遷(予想)
1. 構想：AIの進化と人間の新たな「役割」人間が操縦 AIがサポート AIが操縦人間がサポート AIが完全操縦人間は管理/制御フルAI 人間は責任をとる

課題：「責任」を脅かすカオス

42 Copyright © 2025 Bitkey Inc. All right reserved. 責任は問題なく取ることができるのか？
・ちゃんと動くのか？・不具合はないのか？・セキュリティ的に問題ないのか？・倫理的に問題ないのか？など... 2. 課題：「責任」を脅かすカオス

43 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. 課題：「責任」を脅かすカオス

AI時代に必要なこと

AI時代に必要なことリスクあり

AI時代に必要なことリスクありどう責任とる？

AI時代に必要なことリスクありどう責任とる？検査が重要！

48 Copyright © 2025 Bitkey Inc. All right reserved. 人間のミッション
人間がAIへの盲目的な「信頼」を拒否し厳格な検査 (「責任」の実行) を行いステークホルダーからの「信頼」を獲得する ※ 個人的な意見 / 考え方です 2. 課題：「責任」を脅かすカオス

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

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

戦略：戦略的な「検査」

戦略：戦略的な「検査」ソフトウェアエンジニアとして何が求められるか？

53 Copyright © 2025 Bitkey Inc. All right reserved. リスクあり
どう責任とる？検査が重要！ 3. 戦略：戦略的な「検査」

どう責任とる？検査が重要！例：・レビュー・Build / Lint チェック・自動テスト 3. 戦略：戦略的な「検査」

戦略的な「検査」専門的な知見を基にした検査方法の立案や妥当性の説明が求められるようになる

戦略的な「検査」専門的な知見を元にした検査方法の立案や妥当性の説明が求められるようになる「アーキテクチャ」「QA」「SRE」「データサイエンス」

戦略的な「検査」「検査」を「タイミング」「基準」で構造化する

戦略的な「検査」「検査」を「タイミング」「基準」で構造化する客観 x 予防主観 x 予防客観 x 回復客観 x 回復

戦略的な「検査」「検査」を「タイミング」「基準」で構造化する主観 x 予防客観 x 予防客観 x 回復客観 x 回復

戦略的な「検査」象限ごとの特性・人間の対応が必要で・ボトルネックとなる → 縮小させたい

戦略的な「検査」象限ごとの特性・AIや仕組みで解決可能・スケールしやすい → 拡大させたい

戦略的な「検査」象限ごとの特性・リリース前に検査可能・市場で問題発生しない → 強化させたい

戦略的な「検査」象限ごとの特性・リリース後の検査となる・市場で問題発生するかも → リスクの予防も必要

戦略的な「検査」ケーススタディ１：プロトタイピング / 社内ツールなど ◼ 戦略・AIに委ねる・Build / Lintチェックはしつつも、テストもAI に書かせて、AIに自律的に開発させる ◼ 4象限・ほぼ「客観 x 予防」のみ・最後の動作確認だけ人間がチェックする

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

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

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

解決：Divide and Conquer

どう責任とる？検査が重要！ 3. 戦略：戦略的な「検査」

76 Copyright © 2025 Bitkey Inc. All right reserved. Divide
and Conquer (分割統治) 4. 解決：Divide and Conquer

77 Copyright © 2025 Bitkey Inc. All right reserved. 象限ごとの特性
・人間の対応が必要で・ボトルネックとなる → 縮小させたい 4. 解決：Divide and Conquer

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

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

80 Copyright © 2025 Bitkey Inc. All right reserved. なぜ「Divide
and Conquer」が重要なのか？ PRごとの行数が多いと精度が落ちる 4. 解決：Divide and Conquer コードの詳細を知っているからこそ効果的なAIコーディングができる → 限られた範囲で検査可能とする → 全体の構成を認知しやすい状態を維持する

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

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

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 「責任」「信頼」のための検査しやすいアーキテクチャ

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

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

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

説明： 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

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

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

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

補足：私の現在地

補足：私の現在地私のチーム / プロダクトでは実際どうなのか？

補足：私の現在地私のチーム / プロダクトでは実際どうなのか？ぜんぜん完璧ではないまだ試験段階中 ...

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

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

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

補足：私の現在地 AI特区の構成概要 Command Query Projector

補足：私の現在地 AI特区の構成概要 (要確認箇所) Command Query Projector

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

結び：まとめ

結び：まとめ 1. 人間の価値は「コードを書く」ことから、「責任を負う」ことへと移行する 2. Vibe Codingはセキュリティ脆弱性、保守性の崖、法的リスクをもたらしうる 3. 責任は遂行するために検査が必要であるまとめ

どう責任とる？検査が重要！まとめ 6. 結び：まとめ

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

結び：まとめまとめ

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

境界づけられたコンテキスト 2. Event-Driven Architecture 3. CQRS 4. AVDM 5. Type First 6. Event Sourcing 6. 結び：まとめまとめ

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

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

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

More Decks by 株式会社ビットキー / Bitkey Inc.

Other Decks in Technology

Featured

Transcript

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

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