AI時代の生存戦略〜Divide and Conquerなアーキテクチャで信頼実現〜
はじめに
5〜10年後、あなたはエンジニアとして何をしているでしょう？AIがコードレビューをこなし、設計書を書き、時にはアーキテクチャの提案までする時代が来るかもしれません。現在、多くのエンジニアにとって、AIは便利なツールであると同時に脅威でもあります。
本記事では私の考えをもとに、今後10年以上にわたり何が重要とされ、そのためにどんな準備が今からできるのか？についてまとめます。
対象読者
- 今後のキャリアに悩んでいるエンジニア
- 今後中長期的にAIとどう向き合っていけば良いか不安な人
本記事の主張
- 「信頼の獲得」こそ最後の砦
- 社会的側面、感情面から考えても完全にAIを信頼しAIに責任を果たさせるのは難しい
- AIをうまく使いつつ「信頼を獲得」できる状態を維持すること、が今後強く求められる
- 「信頼の獲得」のために、SREやアーキテクチャ観点での知見が必要
- 「Divide and Conquer」で、AIに任せつつ信頼を実現しやすい状態の維持が必要
- 「境界づけられたコンテキスト」「Event Driven」「CQRS」「Always-Valid Domain Model」「Type First」「Event Sourcing」を活用することが現時点において重要
既知の生存戦略
AI時代のエンジニアの生存戦略として、よく目にするアプローチとして以下があると思います。
- AIが苦手な領域で勝負する
- AIをうまく活用できるようにする
- 個人/組織の能力を高める
すてぃおさんの記事では「AIディレクター型」「アーキテクト特化型」「ドメインエキスパート型」「AI回避型」「ビジネス統合型」の5つのポジショニング戦略が紹介されています。
t_wadaさんの発表では、以下のような表現がされています。
- AIで時が加速したが、問題の構造、根本的原因は同じ。歴史から学んだ知見が今こそ重要
- AIから引き出せる性能は、個人と組織の能力に比例する。能力向上への投資が不可欠
uhyoさんの発表では、以下のような表現がされています
- AIを超える技術力が必要
- 創造的になる必要がある
どれも的を射ている内容ではあると思いますが、本記事では少し違う角度でのアプローチでまとめます。
前提：最終的にAIは人間を凌駕しえる
完全な主観ですが、AIは最終的に全ての領域で人間を凌駕すると考えています。なんだかんだ人間も情報の積み重ねで物事を判断しているに過ぎず、AIとの本質的な差異はない（なくなる）と考えているからです。現時点ではAIが苦手な要件定義や設計といった上流工程、コミュニケーション、マネージメントといった領域も、徐々に置き換わっていくものと推察します。
とはいえ、すぐに全での領域が置き換えられるわけではありません。最後まで残る領域の1つが「信頼の獲得」であると考えています。
なお「信頼」とは以下を指しています。
- 利用者側の視点で
- プロダクトを安心して利用できるか？
- トラブルがあった際に適切にサポートを受けることができるか？
- プロダクト提供側の視点で
- ビジネス価値や必要な要件は漏れなく提供できているか？
- セキュリティやコンプライアンス観点で問題ないか？
- 機能追加や不具合修正でデグレを引き起こさないか？
…など
AIが完璧な成果物を出しても、完全に「信頼する」ことは難しいと考えます。特に（現時点においては）AIが責任を果たすことが難しいことが、明確なボトルネックとなると考えます。
- 法的責任：AIは契約の当事者になれない、訴訟の対象にならない
- 経済的責任：AIには賠償能力がない、保険の対象にならない
- 説明責任：AIは「なぜそうしたか」をステークホルダーに説明しきれない
- 継続的責任：AIは長期的なメンテナンスにコミットできない
- 社会的責任：AIは倫理的判断の主体になれない
人間はちゃんと果たせるか、というと必ずしもそうではないと思います。しかし、人間は明確な個として存在し、生命が続く限り継続的に存続し続け一定のライフサイクルを保証しやすいです。逆にAIは明確な個やライフサイクルの縛りもないため、構造上責任を負わせることが難しいと考えます。
またこ構造上の話だけでなく、感情面の課題もあると考えます。構造上の課題が解決されても、AIに責任を任せられない、信頼しきれない、という感情が最後まで残り続ると考えています。
そのためAIに大部分を任せつつも、最終的に人間が責任を持つ構造がしばらく続くと考えています。人間はいかにAIに大部分を任せつつ、責任を果たせる状態（≒信頼を獲得し続けられる状態）とするかが重要なミッションになると予測します。
信頼獲得の鍵
AIに大部分を任せつつ、責任を果たせる状態（≒信頼を獲得し続けられる状態）とするために重要な要素として、SRE的な観点とアーキテクチャの観点から以下が特に重要となると考えます。
- プロダクトが健全に稼働していることを計測する
- 問題が混入する確率と影響を極小化するプロセス/アーキテクチャ
- 問題が混入しづらいアーキテクチャ
1. プロダクトが健全に稼働していることを計測する
内部のプロダクトの作りは完全なブラックボックスとしても、実際に稼働しているプロダクトの SLO や Four Keys の指標などをもとに健全であるか否かの判断をしつつ、健全な状態を維持するアプローチです。
SRE観点での信頼性指標例：
- SLI (Service Level Indicator): 可用性、レイテンシ、エラー率、スループット
- SLO (Service Level Objective): 具体的な目標値（例：可用性99.9%以上）
- エラーバジェット: 許容される障害の量を定量化
- MTTR (Mean Time To Recovery): 平均復旧時間
- MTBF (Mean Time Between Failures): 平均故障間隔
これらの指標により、「なんとなく安定している」ではなく、「99.95%の可用性を達成している」など定量的に説明できます。
人間は、必要な指標の定義とその閾値、なぜ健全であるといえるかの説明責任を果たすこと、が求められるようになると考えます。
2. 問題が混入する確率と影響を極小化するプロセス/アーキテクチャ
SRE観点では「今、システムは健全に動いているか？」を測定できますが、未来のことについては効力を発揮しづらいです。問題が市場で発生しないように、また発生したとしてもその影響をできるだけ限定的にするように開発プロセスを整えるアプローチが必要となります。自動テストやカナリアリリース、冗長性を持たせた構成とするなどが該当します。
プロセス/アーキテクチャによるリスク軽減例：
- 自動テスト: 要所要所の振る舞いを確認し、退行を防ぐ
- 段階的リリース: カナリアリリース、ブルーグリーンデプロイメント
- フィーチャーフラグ: 問題が起きた際に即座に機能を無効化
- 冗長構成: 単一障害点を排除し、影響範囲を限定
人間は、どんなプロセス/アーキテクチャであれば問題が混入する確率や与える影響を極小化できるか、という説明責任を果たすことが求められると予測します。
ただし、「テストが網羅的であれば中身はなんでも良い」という考え方は危険です。膨大なテストケースを人間が検証するのは現実的でなく、構造が適切であることの方が重要です。
3. 問題が混入しづらいアーキテクチャ
そもそも問題が混入させなければ良いですし、事業や修正内容によってはコストをかけてでも問題が混入していないか検査する必要がある場合もあります (ビットキーのようにカギを扱う場合など)。そのような領域では、人間が修正内容に問題ないことの説明責任を果たすことが求められると予測します。
ここで重要となる観点が、アーキテクチャであり、 Divide and Conquer (分割統治) だと考えます。
本記事では「問題が混入しづらいアーキテクチャ」を 「Divide and Conquer (分割統治)」の視点で、実現方法含めてまとめます。
Divide and Conquer (分割統治)の重要性
複雑なシステムをそのまま扱うのは困難です。AIが生成したコードや設計をレビューする時も、影響範囲や全体の構造が不明瞭だと検証できません。適切に分割することで、各分割要素ごとの責務を明確にしつつ影響範囲も限定的にでき、全体の構造も理解しやすくできます。そして統治(管理)しやすい状態にできます。
Divide and Conquer (分割統治) の実現手段
Divide and Conquer (分割統治) を実現する手段として、重要と考えているものを紹介します。詳細については本記事では触れませんが、どんな観点で重要と考えているかについてまとめています。
※ 参考
1. 境界づけられたコンテキスト (Bounded Context)
DDDで登場する概念で、システム的に独立的に開発・運用することができる単位を定めます。境界づけられたコンテキストを定義するためにイベントストーミングなどの手法が用いられます。
システムとして明確な境界を引くことで、各境界づけられたコンテキストごとに独立して開発しやすい状態を実現します。特に既存実装への修正時に、他への影響を限定的にできることと、合わせて修正内容の妥当性を把握しやすくすることができる点で有用と考えます。
2. Event-Driven Architecture
境界づけられたコンテキスト間の変更やアクションを「イベント」として扱い、イベントを発行・購読して疎結合で協調することです。境界づけられたコンテキストやりとりをイベント駆動とすることで、境界づけられたコンテキスト間を疎結合に保つことを容易化します。
境界づけられたコンテキストでシステムを分割しても、手続き型の実装では結合度が高まり、独立的な開発が難しくなります。Event-Drivenにすることで、各コンテキストの独立性を高め、より独立的に開発しやすくします。
3. CQRS (Command Query Responsibility Segregation)
CQRSは、コマンド(書き込み)とクエリ(読み込み)の観点で分割することです。CQRSを活用することで、境界づけられたコンテキスト内で、さらに分割を促進し統治しやすい状態とできます。
コマンド(書き込み)とクエリ(読み込み)では一般に求められる要件が異なります。これらを分割して実現することで、修正時に考慮する観点やレビュー時にチェックする範囲を限定し修正内容の妥当性を把握しやすくできます。
4. Always-Valid Domain Model
ドメインモデルが常に有効な状態であることを保証するDDDの設計原則です。境界づけられたコンテキスト、CQRS、からさらに「ドメインモデル」の単位で分割することができます。
DTOスタイルと比較して、バリデーションの処理などをドメインモデルに集約させやすく、またモデルの単位の考察を促進し、より適切な分割を実現しやすくする点で有用と考えます。
修正時にもドメインモデルの単位で確認をすればよく、ユースケースなどにおいてもバリデーションなどは考慮不要で、ドメインモデルをどのように協調させるかに注力することができます。
5. Type First アプローチ
状態や制約を「型」で表現することで、不正な操作をコンパイル時など事前に検出するアプローチです。Always-Valid Domain Modelをさらに促進し、単一のドメインモデルの中でも状態や制約による分解を促進させることができます。
状態や制約ごとに、どんな要素を有しているか？何ができるか？をドメインモデルの視点で明示することができ、使う側としてもどんな状態や制約のモデルに対して操作するのかを明示することができます。
Type First アプローチを用いることで、暗黙的な仕様が介在する余地を少なくすることができ、特定の修正が適切であることを保証しやすくするとともに、問題が発生しづらくさせることができます。
6. Event Sourcing
Event Sourcing（イベントソーシング）は、システムの状態を管理する方法の一つです。現在の「状態」を保存するのではなく、「何が起きたか」という全ての「事実（イベント）」を時系列で記録する手法です。境界づけられたコンテキスト、CQRS、Always-Valid Domain Model、Type First、からさらに「イベント」という観点でも、分割を促進することができます。
Type Firstで状態や制約ごとに分割したモデルを、さらにモデルの起因となる「イベント」と「イベント」からモデルを復元する処理に分割します。特に起因となる「イベント」は登録や取り消し、名前の変更などより細かい単位で定義可能で、特にイベントを作成するコマンドの処理を通常のユースケースなどと比較して、イベントを軸により細かく再利用しやすい形式で実装を進めやすくすることができます。
※ 参考
まとめ
- 「信頼の獲得」こそ最後の砦
- 社会的側面、感情面から考えても完全にAIを信頼しAIに責任を果たさせるのは難しい
- AIをうまく使いつつ「信頼を獲得」できる状態を維持すること、が今後強く求められる
- 「信頼の獲得」のために、SREやアーキテクチャ観点での知見が必要
- 「Divide and Conquer」で、AIに任せつつ信頼を実現しやすい状態の維持が必要
- 「境界づけられたコンテキスト」「Event Driven」「CQRS」「Always-Valid Domain Model」「Type First」「Event Sourcing」を活用することが現時点において重要
補足 / 宣伝
本記事の内容をもとにより実践的なアプローチに踏み込んだ内容で、アーキテクチャConference2025 Day1 の 11/20 (木) 11:45-12:25 で発表予定です。※ 発表に利用した資料も別途公開予定です。
Discussion