#DDD #アーキテクチャ #ai #engineering

🐙AIエージェント構築プラットフォームにDDDは役立つのか

subaru · · —

問い

AIエージェント構築プラットフォームを開発していると、こんな疑問が浮かぶ。

DDDは「業務ロジックが複雑なシステム」のためのものだ。受発注や在庫管理のような現実業務をシステムに落とし込むわけでもない我々のプラットフォームに、DDDは意味があるのか？

答えは 「ある」 だが、理由は一般的な説明とは少し違う。

前提の誤解を解く

「DDDは業務ロジック整理のためのツール」という理解は、DDDの一側面しか捉えていない。

Eric Evansが定義した原文は「ソフトウェアの核心にある複雑さを、ドメインのモデリングによって制御する」だ。「業務」という言葉はどこにも出てこない。

業務ドメインがないのではなく、ドメインの種類が違うだけだ。AIエージェント構築プラットフォームには、プラットフォーム固有のドメインがある。

プラットフォームのドメインを分類する

DDDでは「コアドメイン・サポートドメイン・ジェネリックドメイン」という3種の分類がある。これをAIエージェントプラットフォームに当てはめると：

種類説明具体例
コアドメイン競合優位の源泉。ここを疎かにすると差別化できないワークフロー実行エンジン、エージェントオーケストレーション
サポートドメイン必要だが汎用ではない。独自実装が必要テナント管理、ツールレジストリ、タスク・プラン管理
ジェネリックドメイン汎用的。外部サービスに任せてよい認証（OIDC）、通知、ログ集計

この分類は思想的な話ではない。リソース配分の判断基準だ。

コアドメインには最も優秀なエンジニアと設計コストをかける。サポートドメインは適切に実装する。ジェネリックドメインは既製品を使う。この判断を「なんとなく」ではなく明示的に下せるようになる。

Bounded Context：「言葉の意味」を境界で守る

AIエージェントプラットフォームには「ワークフロー」「エージェント」「タスク」「ツール」「メッセージ」といった概念が乱立する。

厄介なのは、これらの言葉がサービスやチームによって微妙に違う意味を持つことだ。「タスク」はエージェントエンジンでは実行単位だが、フロントエンドではUIのTODO項目だったりする。

Bounded Contextはこの問題を構造的に解決する。

[Agent Execution Context]
  └─ Task: エージェントが実行する1単位の処理
  └─ Plan: Taskの実行順序とその依存関係

[Conversation Context]
  └─ Message: ユーザーとエージェント間の1往復
  └─ Session: Messageの集合と状態

[Tool Registry Context]
  └─ Tool: 外部API・関数の呼び出し定義
  └─ Version: Toolのスキーマと後方互換性

各Contextは「その境界内では概念の意味が一貫している」ことを保証する。

そしてContext Mapping（Anti-Corruption Layer等）によって、境界を越える際の変換を明示的にする。たとえば「Tool Registryのバージョンアップが、Agent Executionに無自覚に波及しない」という設計はACLで実現する。

Ubiquitous Language：コードとプロンプトを統一する

ここがAIエージェントプラットフォーム特有の話になる。

通常のシステムでユビキタス言語が効くのは「コード・ドキュメント・チームの会話」の3つだ。AIエージェントプラットフォームでは4つ目がある。LLMへのシステムプロンプトだ。

エージェントに渡す「Taskとは何か」「Toolの呼び出し規約はどうか」という定義が、コードと乖離していると：

  • LLMが誤った前提で推論する
  • エージェントの出力が設計意図と食い違う
  • デバッグが困難になる（コードが正しいのかプロンプトが正しいのかわからない）

ユビキタス言語を確立することで、コード・プロンプト・ドキュメントが同じ概念を指すようになる。これはAIシステムにおいて特に重要な性質だ。

Agent as Bounded Context

2025年以降、「エージェント自体をBounded Contextとして設計する」という観点が登場している。

マルチエージェントシステムでは、各エージェントが固有の責任範囲と知識を持つ。これはBounded Contextの概念と構造的に一致する：

  • エージェントは自身のBounded Context内の「専門家」として振る舞う
  • エージェント間の通信はContext Mappingとして設計する
  • あるエージェントの内部実装の変化が、他のエージェントの振る舞いを壊さない

この観点はシステム設計だけでなく、LLMへのコンテキスト管理にも応用できる。関連ツールをBounded Contextとしてグルーピングし、エージェントに必要なContextだけをロードする設計（Meta-Toolパターン）は、トークン消費を大幅に削減しながらエージェントの能力を保つ。

組織設計への波及

DDDは実はコード設計だけの話ではない。コンウェイの法則が示す通り、システムの構造とチームの構造は互いに影響する。

複数のサービスが並ぶプラットフォームで、Bounded ContextとTeam Topologiesを組み合わせると：

  • 各チームがBounded Contextと一致した責任を持つ
  • チーム間のインターフェースがContext Mappingとして明示化される
  • 「このContextはあのチームが所有者だ」という判断が明確になる

チームが曖昧な責任を押し付け合う状況は、Bounded Contextの境界が引かれていないことの表れだ。

まとめ

AIエージェント構築プラットフォームにDDDが役立つ理由を整理すると：

DDDの概念プラットフォームでの価値
サブドメイン分類コアへのリソース集中と外部調達の判断基準
Bounded Context概念の意味を境界で守り、サービス間の暗黙的な依存を排除する
Ubiquitous Languageコード・プロンプト・チーム間の概念を統一する
Context Mappingサービス間の変換を明示的にし、波及を制御する
Agent as BCマルチエージェント設計への直接的な応用

業務ロジックがないのではなく、プラットフォーム固有のドメインロジックがある。

ワークフローの定義・エージェント間の依存・ツールのバージョニング・テナント間の分離——これらはすべてドメインの問題であり、モデリングの対象だ。DDDはそれを整理するための道具として、業務システムと同じように機能する。

参考