Software Architecture in an AI- Driven World AI時代のソフトウェアアーキテクチャ @atty303 / Koji AGAWA 

本スライドの構成 ここには（なるべく）中立な知識が書かれています。 図は書くのが苦手なので無いです。 🤔💭 ここには筆者の（偏っているかもしれない）私見が書かれています。 1/54 

阿川 耕司 ソフトウェアエンジニア （株）サイバーエージェント AI事業本部 協業リテールメディアDiv. ミライネージ 2014年1月入社 Scala/Rust/関数型が好き #times_atty303 🤔💭 バズワード感があって名乗りたくないけどフ ルスタックエンジニアと呼ばれるような仕事 をしています。 2/54 

イントロダクション 0 

本研修のゴール 皆さんが、AIを "部下" として使いこなし、その能力を最大限に引き出すアーキテクチャを設計 できるようになること。そのための考え方と キーワードを認知 し、実践の機会が訪れたときに 引き出すこと ができるようになることです。 本講義で分からないところもAIに聞いてください。 3/54 

アーキテクチャとはなにか？ アーキテクチャは、システム全体の 「設計思想」 を表すものであり、技術的な詳細や実装に とらわれない。 変化しやすいものを柔軟に受け入れられるようにするための、変化しない部分がアーキテク チャ。 技術詳細、ビジネス要求は変化しやすい。 システムの根幹となる思想や原則は、安定して維持できるように。 🤔💭 不確実な未来に完璧に対応できるアーキテクチャを最初から設計することは不可能か、コストが非常に高くなります。 とはいえ選択は必要なので、変化への適応コストが最小限になることを意識して決定します。 4/54 

AI活用の不可避性：競争環境の変化 ソフトウェア開発の競争環境は、AIによって一変した 競合は必ずAIを活用してくる コード生成、テスト自動化、ドキュメント作成、技術調査… あらゆる場面でAIによる効 率化が進む。 より少ないリソースで、より速く、より多くの価値を生み出すチームが現れる。 「AIを使わない」という選択がもたらすもの （相対的に見て）開発速度の劇的な遅延 イノベーションの機会損失 開発者のモチベーション低下 5/54 

AIの活用は、もはや「選択肢」ではなく「必須事項」 競争優位性を確立し、市場で生き残るためには、AIを積極的に導入し、開発プロセス全体を革新 していく必要がある。 6/54 

AI × アーキテクチャ AIを最大限に活用するためには、AIの特性を理解し、AIが能力を発揮しやすい環境を人間 が主体的に構築する必要がある。 これからは、AIが最高のパフォーマンスを発揮できる「舞台＝アーキテクチャ」 を設計する ことが重要。 AIによるコード生成量が増えるほど、初期のアーキテクチャ決定の影響は増大。 良い設計はAIの力を増幅し、悪い設計はAIによる混乱を招く。 🤔💭 今現在、人がマシン語・アセンブリ言語を手書きすることがないように、将来は人がプログラミング言語を書くことがな くなるかもしれません。それらが実装詳細となったときも、アーキテクチャは必要なままでしょう。 7/54 

今日深掘りする3本柱 1. 分割統治 (Divide & Conquer) AIが集中し、理解しやすい単位に、システムをどう「分ける」か？ 2. コード化 (Everything as Code) 設計の意図やドメイン知識を、AIが「読める」形でどう表現するか？ 3. 品質 (Quality) AIで代替できない、人間が変わらず責任を負う必要がある部分とは？ 8/54 

講義 (約2時間) Part 0: イントロダクション (今ココ！) Part 1: AI基礎ブロック Part 2: 原則ブロック Part 3: DDD戦略設計 Part 4: レイヤード & マイクロサービス設計 Part 5: AIリスク Part 6: 未来展望 Part 7: まとめ Agenda 

AI基礎ブロック 1 

AIコーディングエージェントの三類型 タイプ 特徴 代表例 得意なこと 苦手なこと・課題 自律型エー ジェント 大規模タスク、曖昧な指示にも挑戦。自律的に計 画・実行。 Devin 複雑な問題解決の試み、広 範囲のコード修正 安定性、コスト、完全な自律 性、巨大コンテキスト 協調型アシ スタント 対話を通じてコード生成、リファクタリング、デバ ッグ等を支援。人間との協調が前提。 Cursor 特定範囲のコード生成、質 問応答、アイデア出し 大規模改修、深いドメイン知 識の理解 補完型ツー ル コーディング中のリアルタイムなコード片提案。 GitHub Copilot 定型コード、スニペット生 成、単純な補完 文脈理解の限界、複雑なロ ジック生成 9/54 

AIの最大課題：巨大で複雑なシステムの理解 10/54 

コンテキストウィンドウの壁 LLM (大規模言語モデル) が一度に処理できる情報量には限界がある。 例：Claude 3.7 Sonnet (20万トークン) 1トークン ≈ 英語で約3.5文字 (あくまで目安) 20万トークン ≈ 英語で約70万文字 の情報を一度に扱える。 コード量とコンテキストウィンドウの試算例 (あくまでイメージ) 大規模の入り口である10万行のコードベース (1行平均50文字 = 500万文字) を LLMに読ませようとすると… 総想定トークン数: 500万文字 / 3.5文字/トークン ≈ 約143万トークン コンテキストウィンドウの大きいGeminiの200万トークンなら処理できるが…… 11/54 

ここでミライネージのコードベースを見ると…… =============================================================================== (長いので言語別は一部省略) Language Files Lines Code Comments Blanks =============================================================================== GraphQL 423 19811 18376 11 1424 HCL 221 18285 15371 324 2590 Java 91 7061 5485 548 1028 JavaScript 27 1181 989 83 109 JSON 100 116383 116376 0 7 Kotlin 367 32045 27072 1410 3563 Markdown 118 5486 0 3516 1970 Protocol Buffers 53 5506 4250 194 1062 Python 5 763 627 33 103 Rust 11 528 447 3 78 Scala 4348 259755 227290 6033 26432 Shell 49 7147 4936 1299 912 SQL 471 11833 10875 175 783 TSX 326 24522 22240 296 1986 TypeScript 335 28406 25143 645 2618 Vue 273 7526 7003 29 494 XML 174 56475 56266 42 167 YAML 77 8123 6918 801 404 =============================================================================== Total 7604 617168 554770 15565 46833 12/54 

5年経過したコードベースの実際 =============================================================================== Language Files Lines Code Comments Blanks =============================================================================== Total 7604 617168 554770 15565 46833 =============================================================================== Gitチェックアウト直後でビルド結果は含まず、自動生成ファイルもコミットしていない おおよそ50万行のコードベース (1行平均50文字 = 2500万文字) 総想定トークン数: 2500万文字 / 3.5文字/トークン ≈ 約714万トークン 全コード = 最高解像度だが最悪のトークン効率 13/54 

現状のAIは、巨大なコードベース全体を一度に丸ごと理解 するのは困難 🤔💭 人間も一度に丸ごとは理解できないですが、AIならできるということもないのです。 14/54 

コンテキスト圧縮の必要性 AIに効率よく、かつ正確に情報を与えるためには、情報を「圧縮」して渡す 必要がある。 15/54 

Layer 1: Docs (ドキュメント、設計書など) サイズ 数KB～数MB 内容 人間が読むための設計思想、背景、ビジネスルール、ドメイン知識。 巨大なコードからこれらの情報を都度抽出するのは無駄なので、あらかじめ整理して おく必要がある。 形式 Markdown、YAMLなど 16/54 

Layer 2: Spec (スキーマ定義、インターフェース) サイズ 数KB～数MB 内容 AIが直接解釈できる「公開言語」。システムの境界と機能を定義。 BDDフィーチャーファイル: システムの振る舞い (AIがテストケースを理解) 形式 OpenAPI, GraphQL Schema, gRPC .protoなど 17/54 

Layer 3: Code (実際のソースコード) サイズ 数MB～数GB以上 内容 具体的な実装。AIが直接全てを読むのは困難な場合が多い。 だからこそ、Layer 1, Layer 2の情報でAIに「何を作るべきか」を正確に伝え、AIが Layer 3のコード生成に集中できるようにする「分割」と「コード化」が重要になる。 🤔💭 人がこのLayer 3を触らなくなる日がそう遠くない未来に来るかもしれません。 18/54 

原則ブロック 2 

原則1. コンテキスト分割 AIの課題 一度に多くの情報を処理できない (トークン上限) 解決策 AIが扱う情報 (コンテキスト) を適切に「分割」し、一度に処理する量を限定する。 鍵となる概念: Bounded Context (境界づけられたコンテキスト) ドメイン駆動設計 (DDD) の中心的な概念。 ビジネスドメインにおける特定の関心事を明確な境界で区切ったもの。 1つのBounded Context = 1つのAIコンテキスト 1つのAIエージェントが責任を持って扱える、適切なサイズと複雑性の単位。 コンテキスト境界は“公開言語”(OpenAPI/GraphQL)で接合 19/54 

ミライネージの例 signage : サイネージ事業のコアドメイン retail : 小売の関心事のコンテキスト 自社の販促掲示物、店舗の管理、広告掲載による収益 demand : 広告主の関心事のコンテキスト 広告の管理、クリエイティブ、キャンペーン予算 delivery : コンテンツ配信の関心事のコンテキスト 小売、広告主の配信要求からサイネージが再生すべきコンテンツを決定 sdm : サイネージ端末の支援サブドメイン 死活監視、アプリの更新、リモートメンテナンス authn : 認証の汎用サブドメイン Auth0を利用 20/54 

原則2. Project as Code (PaC) "Everything as Code" の思想を設計にも適用 ソースコードだけでなく、設計情報、ドメイン知識、API仕様などもバージョン管理し、 機械可読な形式で記述する。 なぜPaCがAI活用に重要なのか？ 最小トークンで最大の意味を伝えるコツ。 現在のAIは人間と違い、ドメインに長く係わっていてもその経験から学習したりしない ので、毎回ドメインの知識をゼロから与えないといけない。 人間は経験から学習するので暗黙知になりがちだった。 AIとチームメンバーは同じ AIのための準備はチームにジョインする人も同じく恩恵を受ける。 せっかくオンボーディングの準備をするならAIも活用できるようにしたほうがいい。 21/54 

具体的なPaCの対象ファイル例 domain.md : ユビキタス言語、主要ドメイン概念、ビジネスルール designdoc.md : Design Doc adr.md : Architecture Decision Record openapi.yaml / schema.graphql : APIの公開言語 (契約) spec/*.feature : BDDのフィーチャーファイル (振る舞い定義) 🤔💭 ミライネージでは実装に必要だったGraphQLスキーマはありますが、他はあまり実践できていないです。AI活用のた めにこれから作っていこうとしています。 22/54 

原則3. 品質 ＝ テスト + HITL AIが生成したコードも、人間が書いたコード以上に品質担保が不可欠。 AIには「責任」がない。 人間がAIに代って責任を負う必要がある。 人間が指示した「意図」通りに動くかどうかは人間が確認する必要がある。 ただしテストは自動化しないと人間がボトルネックになる。 現在よりテストの重要性が増す。 🤔💭 AI社会のためのソフトウェアであれば人間が介在する必要はないですが、当面ソフトウェアの適用先が人間社会である 以上、人間が責任を負う必要は将来にわたってあり続けると思います。 23/54 

HITL (Human In The Loop) AIの実装はあくまで「提案」。鵜呑みにせず、人間がレビューし最終決定。 3段階のHITLゲート（レビューポイント） Spec-PR (仕様・設計レビュー) domain.md , openapi.yaml , *.feature のレビュー。AIが誤解しない明確な指 示になっているか？ AI-PR (AI生成コードレビュー) AIが生成したコードのプルリクエストレビュー。ロジック、セキュリティ、パフォーマ ンス、可読性。 24/54 

余談: Vibe Coding AIが生成したコードを、そのまま受け入れるスタイル。雰囲気コーディング。HITLの対極。 小さいプロジェクトなら機能するだろうが、50万行規模ではどうだろうか？ コンテキスト分割を適切に行い、小規模なコンテキストに限っては有効かもしれない。 🤔💭 いくつかのタスクをAIエージェントにやらせた感覚では、大規模プロジェクトでの保守性を維持する品質のコードは出 てこないです（Publicコードが学習元だと仮定するとライブラリやフレームワーク、サンプルコードが大半で、開発チェ ーンの末端となる実運用されている大規模アプリケーションのコードが少ない気がします）。もちろん自分たちのPaC も不足しているし、プロンプトでの工夫も出来ていないので良くなる希望は全然あります。 25/54 

DDD戦略設計 3 

DDD (ドメイン駆動設計) とは何か？ 複雑なドメインの問題を解決するための設計アプローチ ドメイン：ソフトウェアが対象とする業務領域や問題領域のこと。 ソフトウェアの核心は、そのドメインの複雑性に立ち向かうことにある。 大きくわけて戦略的設計と戦術的設計がある。 本講義ではアーキテクチャと関連深い戦略的設計にフォーカスする。 戦術的設計は実装の手法なので、アーキテクチャの視点では詳細である。 26/54 

DDDの戦略的設計と戦術的設計 戦略的設計 (Strategic Design) ドメイン全体を俯瞰し、どのように分割するかを考える。 Bounded Context や Context Map を定義する。 ドメインの全体像を把握し、システムのアーキテクチャを設計する。 戦術的設計 (Tactical Design) 各 Bounded Context 内での具体的な設計を行う。 エンティティ、値オブジェクト、集約、ドメインサービスなどの設計を行う。 ドメインモデルを具体化し、実装に落とし込む。 🤔💭 DDDの原典で解説されている戦術的設計はオブジェクト指向パラダイムに偏った方法論で、昨今の関数型パラダイム と親和性が低い部分も多く、そこは割り引いて考えたほうが良いと思います。 27/54 

ドメインの分類 Core Domain (コアドメイン): ビジネスにとって最も重要で、 競争優位性の源泉 となる領域。 最も多くの時間とリソースを投入して開発・洗練させるべき。 AIを活用する場合も、このCore Domainの理解と設計が最優先。 Supporting Subdomain (支援サブドメイン): Core Domainを支援するが、それ自体は競争優位性を持たない領域。 カスタム開発が必要な場合もある。 Generic Subdomain (汎用サブドメイン): どのビジネスでも共通して必要となる一般的な機能 (例: 認証、通知)。 SaaSやOSSの利用を検討。 28/54 

Ubiquitous Language (ユビキタス言語) プロジェクト関係者 (ドメインエキスパート、開発者、ビジネス、etc.) 全員が、特定のドメイ ンについて話す際に一貫して使用する厳密な言語。 なぜ重要か？ 誤解を防ぎ、コミュニケーションを円滑にする。 AIへの指示やドキュメント記述の基盤となる。 AIに「顧客」と指示したときに、それが何を指すのか明確でなければならない。 作成のポイント: Markdownの定義リストなどで管理する (原則2. Project as Code)。 最初から完璧を目指さず、継続的に改善する。 作った言語は浸透させる。 29/54 

ユビキタス言語の例 お題: ECサイトの「商品レビュー機能」 # Ubiquitous Language - レビュー - : 商品に対する顧客からの評価・コメント - 評価点 - : 1～5の星で表される満足度 - 投稿者 - : レビューを書き込んだ認証済みユーザー 30/54 

Bounded Context (境界づけられたコンテキスト) 原則1. 「コンテキスト分割」の核となる概念。 定義 特定のモデルが定義され、適用される明確な境界。その境界内では、用語や概念が一 貫した意味を持つ。 逆に異なるBounded Context間では、同じ用語でも異なる意味を持つことがあ る。 各Bounded Contextが、AIにとって扱いやすい単位 (AIコンテキスト) となる。 🤔💭 同じチームが複数のBounded Contextを担当する場合、異なる意味の同じ用語は定義しないほうが無難でしょう。 31/54 

ECサイトの例 受注コンテキスト: 「顧客」は商品を注文する人。 「商品」は価格や数量を持つ注文対象。 商品カタログコンテキスト: 「商品」は詳細な説明や画像を持つ掲載アイテム。 「レビュー」はこのコンテキストの主要な関心事。 請求コンテキスト: 「顧客」は支払い義務のある請求先。 「商品」は請求明細の一部。 32/54 

Context Mapping (コンテキストマップ) 目的: 複数のBounded Contextがどのように連携し、影響し合っているかを明確にす る。 主要な関係性パターン: Shared Kernel (共有カーネル): 2つのコンテキストがモデルの一部を共有。慎重な 運用が必要。 Customer-Supplier (顧客-供給者): 一方が他方の要求を満たす形でサービスを 提供。 Anti-Corruption Layer (ACL / 腐敗防止層): 外部コンテキストのモデルが内部 に影響を与えないよう隔離する層。 Open Host Service (OHS / 公開ホストサービス): 標準化されたインターフェース でサービスを公開。 33/54 

Project as Code & AIコンテキスト (再び) OpenAPI / GraphQL Schema: Bounded Context間のインターフェースを定義する「公開された言語」。 AIはこれらのスキーマを読み解くことで巨大な実装詳細を知らずとも、APIを通じて 他のコンテキストと連携できる。 明確なAPIスキーマは、AIがBounded Contextの責務と機能を理解するための鍵とな る。 34/54 

レイヤード & マイクロサービス設計 4 

マイクロサービスとは？ 定義: 単一のビジネス機能を持つ独立したサービス。 各サービスは独自のデータベースやインフラを持ち、APIで通信する。 サービス間は疎結合で、独立してデプロイ可能。 各サービスは異なる技術スタックを使用できる。 なぜマイクロサービスか？ 関心事の分離、技術的多様性、スケーラビリティ、デプロイの独立性など。 35/54 

マイクロサービスの分割 Bounded Contextに基づく分割 (推奨) DDDのBounded Contextをマイクロサービスの境界とする。 各サービスが明確なビジネス責務を持つため、AIもその責務を理解しやすい。 チーム組織に基づく分割 (逆コンウェイの法則) チームの構造に合わせてサービスを分割。 異なるチームが同じコードベースを触るのは混沌なので現実的な選択肢だが、ドメイン と乖離するとDDDの効果が薄れる。 36/54 

いつマイクロサービスを選択すべきか？ マイクロサービスは開発オーバーヘッドが大きいので、いきなり選択すべきではない。 単一のチームで複数のマイクロサービスを運用するのはコストだけ嵩みメリットが薄 い。 組織が拡大しチーム分割が必要になってからマイクロサービス化する。 複数のチームでモノリスを触るのはマイクロサービスより難しい。 モノリスであってもBounded Contextによる分割とAPIによる疎結合を意識する（モジ ュラーモノリス）ことで、マイクロサービス化しやすい設計が可能。 🤔💭 マイクロサービスは組織構造と密接に関連していると思っており、「1チーム＝2ピザ」という言葉があるように、ビジネ スが拡大し組織が大きくなるとチームを分割する必要が出てきます。そのタイミングでマイクロサービス化するのが良 いと思います。ミライネージはマイクロサービスではありません。 37/54 

サービス間通信 同期通信 (HTTP/REST, GraphQL, gRPC) メリット：即時性、シンプルなリクエスト/レスポンス。 デメリット：呼び出し元と先の結合度が高い、障害時の連鎖的影響。 非同期通信 (メッセージキュー: SQS, Kafkaなど) メリット：疎結合、耐障害性、スケーラビリティ。 デメリット：結果整合性、複雑なエラーハンドリング。 38/54 

サービスをまたがる整合性 強い整合性 (Strong Consistency): 従来のRDBのような即時一貫性。マイクロサービ スでは実現が難しい。 結果整合性 (Eventual Consistency): 時間の経過とともに最終的にデータが一致す る。非同期通信でよく採用される。 補償トランザクション (Compensating Transaction): 一連の処理の途中でエラーが発生した場合、それまでの処理を取り消す操作を実行す る (Sagaパターンで利用)。 🤔💭 ドメインの性質にもよりますが、できるだけ結果整合性を選択しておくとスケーラビリティで問題になりにくいです。 39/54 

サービスごとのアーキテクチャ 40/54 

伝統的な4レイヤアーキテクチャ責務早見表 レイヤー 主な責務 具体例 AIとの相性・活用のヒント Presentation ユーザーインターフェース、 APIエンドポイントの公開、リ クエスト/レスポンス処理 REST Controller, GraphQL Resolver, Webページ API仕様(OpenAPI)があれば、AIはエンドポイ ントの雛形やリクエスト/レスポンスのDTOを生成 しやすい。 Application ユースケースの実現、複数のド メインオブジェクトやインフラ サービスを利用した処理フロ ーの調整 〇〇UseCase, △△Workflow 処理フローが明確であれば、AIは定型的な呼び出 しコードを生成可能。複雑な分岐やエラー処理は 人間の設計が重要。 Domain ビジネスロジック、エンティテ ィ、値オブジェクト、ドメインサ ービス。システムの核。 Productエンティティ, Orderド メインサービス 最もAIによる自動生成が難しく、人間の深い理解 と設計が求められる。ただし、ユビキタス言語やド メインモデルが明確なら、AIも一部支援可能。 Infrastructure データベースアクセス、外部サ ービス連携、メッセージングな ど技術的詳細の実装 UserRepositoryImpl, EmailSender, S3Client インターフェースが明確であれば、AIは具体的な DBアクセスコード(SQL)や外部API呼び出しコー ドを生成しやすい。 41/54 

各種レイヤードアーキテクチャスタイル Clean, Onion, Hexagonalといった名前の付いたレイヤード派生アーキテクチャ（同心 円図のやつら）があるが、どれも用語が違うだけで本質的な目的は同じ。 ドメインを中心に据える 関心の分離 テスト容易性 レイヤードは少し古く、ドメイン層がインフラ層に依存している。前述の新しいアーキテクチャ はこの関係をDependency Inversion Principleに従って逆転させ、ドメイン層がイン フラ層に依存しないようにしてテスト容易性を高めている。 42/54 

レイヤードアーキテクチャの選択 バックエンドでテスト容易性を追求すると結局Cleanアーキテクチャのような形に行き着く ので、最初からその形にしておくのが良い。 開発者の共通言語になるのでどれか1つ好みのアーキテクチャを選択するのが良い。 一般的なフロントエンドはコアとなるドメインがない（バックエンドに委譲している）ので、フ ロントエンド内でCleanアーキテクチャのような形を採用するメリットがない。 ブラウザ上で動くビジネスロジックがヘビーな場合は、フロントエンドでもCleanアー キテクチャを採用することがある。 🤔💭 自分はOnionアーキテクチャの用語が好みです。 43/54 

余談：良いアーキテクチャのサイン 宣言的・冪等性 あるべき状態を宣言し、現在の状態からその状態に到達するための手続きを定義。 例：Terraform 不変性 (Immutability) 変更されないデータ構造を使用し、変更はコピーして新しいものを作成する。 Mutablityが必要になるのはパフォーマンスやストレージなどの制約から。 純粋（副作用なし） 関数型プログラミングの考え方で、関数は同じ入力に対して常に同じ出力を返す。 上記の考え方と相性が良い。 例：React 44/54 

AIリスク 5 

サプライチェーン攻撃 ソフトウェアサプライチェーンとは？ ソフトウェアが開発され、ユーザーに届くまでの全てのプロセス、ツール、依存関係。 AI時代における新たな脅威: AIモデルへのポイズニング攻撃 (Model Poisoning) 悪意のある学習データを注入し、AIモデルの判断を誤らせる。 プロンプトインジェクション (Prompt Injection) AIへの指示 (プロンプト) を不正に操作し、意図しない動作を引き起こす。 45/54 

AIエージェントのリスク AIエージェントにコード生成や変更を任せる際の安全策が不可欠。 例：業務で利用しているPCでAIエージェントを動かし、ディスクに保存されている業務 機密情報がネットに公開される。 例：本番環境へのアクセス権限があるPCでAIエージェントを動かし、本番環境を破壊 するコマンドを実行される。（開発環境であっても復旧の手間がかかる） 悪意のある攻撃でなくとも、AIが危険なコードを生成する可能性は常にある。 人間がいちいち確認すれば防げるが、AIの生成速度を活かせないし、裏で放置できないの で付きっきりになってしまう。 46/54 

サンドボックス環境 AIエージェントが動作する環境を隔離し、そもそも本番環境や機密情報にアクセスできない ようにする。 サンドボックスとしてのDevContainerの活用: プロジェクトごとに、開発ツール、ライブラリ、OS設定などをコード化し、一貫した開発 環境を提供。 AIエージェントも、この定義済みの安全な環境内で作業させることができる。 人間も同じ環境で開発し、AIエージェントと同じ条件で開発を行うことで、AIエージェ ントで自動化しやすくなる。 基本は最小限の権限をもち、人間だけがMFAを要求するsu的な操作で開発環境への フルアクセス権限を持てる。 47/54 

AIガバナンス AIを導入するだけでは不十分。適切に管理し、説明責任を果たせる状態にする必要がある。 ログ収集、アクセス制御、コスト管理など。 🤔💭 そもそもAIの利用が手探りなので、ここはまだ実践できていないです。AI活用が進むにつれて、ここの重要性が増して いくでしょう。 48/54 

未来展望 6 

開発プロセス全体のAI化 現状 特定タスクの自動化 (コード補完、ユニットテスト生成など) 未来のイメージ コードに限らず、より広範な開発プロセスをAIエージェント群が連携して実行 アーキテクトはAIエージェントの連携を設計し、最適化する役割にシフト 49/54 

AI化された開発バリューストリーム フェーズ アクター 内容 Idea 人間 ビジネスアイデア、解決したい課題を提示 Planning AI+HITL 要求分析支援、仕様の明確化、タスク分解 Coding AI 設計に基づき、ソースコード、テストコード、ドキュメントを生成 Review AI+HITL AIによる自動レビュー + 人間による重要箇所のレビュー CI/CD AI ビルド、多段階テスト (ユニット、結合、E2E) の自動実行 安全なデプロイ戦略 (カナリアリリース、ブルーグリーンデプロイ) の実行 Monitoring AI 本番環境の監視、異常検知、パフォーマンス分析。障害発生時の原因特定支援、自己修復の試み これは夢物語ではない: 部分的には既に実現しつつあり、今後さらに進化していく。 50/54 

まとめ 7 

本日のキーポイント 分割 (Divide & Conquer) AIが集中し、理解しやすい単位に、システムをどう「分ける」か？ Bounded Context こそが、AIにとっての最適なコンテキスト単位。 コード化 (Everything as Code) 設計の意図やドメイン知識を、AIが「読める」形でどう表現するか？ Markdown, OpenAPI, BDDフィーチャーファイルなどがAIへの重要な指示書とな る。 品質 (Quality) AIと共に、システムの「品質」をどうコントロールするか？ 自動テスト、HITL (Human In The Loop)で人間が責任を持つ。 51/54 

AI時代のアーキテクトの役割 変化する役割: 従来: 詳細な設計図を描き、実装を指示する。 AI時代: AIが最高のパフォーマンスを発揮できる「舞台」を設計し、AIの提案を評価・ 判断し、最終的な意思決定を行う。 求められるスキル: 技術的スキル (アーキテクチャ設計、プログラミング) に加え、 ドメイン理解力: AIに何をさせるべきかを的確に指示する力。 コミュニケーション能力: AIとの対話、チーム内外との連携。 批判的思考力: AIの提案を鵜呑みにせず、多角的に評価する力。 倫理観と責任感: AIの利用に伴うリスクを理解し、責任ある開発を推進する力。 52/54 

導入に向けて 本日お話しした内容の全てを、すでに完璧に実践できているチームは稀でしょう。 大切なのは、現状を認識し、AIと共に進化していく意志を持つこと。 小さなことからで良いので、チームで話し合い、試行錯誤しながら、皆さんの現場に合った AI活用アーキテクチャを育てていきましょう。 53/54 

明日からできる小さなアクション 担当システムの「Core Domain」をMarkdownで記述してみる まずは小さな範囲から。あなたの言葉で、ビジネスの中心的な価値やルールを整理して みましょう。 （例：主要なエンティティ、ユビキタス言語、ビジネスフローなど） 問題領域としてのドメイン、解決領域としての境界づけられたコンテキストを意識しま しょう。 54/54 

Q&Aセッション 本日の講義内容全体を通して、ご質問、疑問点、もっと詳しく聞きたいことなど、何でもどう ぞ！