この記事では、Slackからの質問に応答するAIエージェントを構築する際に、設計思想（Clean Architecture × DDD）を整理・検討してみました。
📘 Slack MCP Agent - Architecture Guide
🎯 設計思想：Clean Architecture × DDD
本プロジェクトは Clean Architecture と Domain-Driven Design (DDD) を基盤とし、変更容易性・再利用性・テスト容易性を実現します。
- ビジネスロジックは外部依存から独立
- ユースケースがドメインとインフラを仲介
- I/Oは外部に押し出す
- 各層の責務を厳格に分離
📊 アーキテクチャ図（Mermaid）
🗂 ディレクトリと責務
| ディレクトリ | 説明 |
|---|---|
app/domain/models/ |
ビジネスの核を成す Entity / ValueObject。状態と振る舞いを定義 |
app/domain/repositories/ |
Repository のインターフェース。インフラ層に依存しない抽象 |
app/usecases/ |
アプリケーションの振る舞い。外部の要求を実現する処理単位 |
app/infrastructure/ |
外部との接続（DB, APIクライアント, Adapter, 設定など） |
app/interfaces/ |
FastAPIによる Web / Slack のエンドポイントと依存注入層 |
app/agent/ |
LangChain / MCP による AI 構成。Prompt定義・Runner実装など |
app/shared/ |
JWT, 認証、Slackヘルパーなどの共通処理 |
app/core/ |
設定ファイル読込・スケジューラなど汎用サービス |
app/database/ |
DB初期化など、1回限りの処理群（DDLなど） |
🔁 各層の依存関係（矢印の方向）
UI (HTML/Slack)
↓
Interfaces (FastAPI Routes)
↓
Usecases (Application Services)
↓
Domain (Entity / Interface)
↑
Infrastructure (DB/API/Adapter)
→ 依存の向きはすべて内側へ
🚀 モジュール追加時の拡張指針
例：X（例：Teams連携）を追加したい場合
| 対象 | 対応内容 |
|---|---|
domain/ |
必要があれば ValueObject を定義（例：Message） |
usecases/teams/ |
Teams 連携ユースケースを新設（例：teams_usecase.py） |
infrastructure/apis/teams_client.py |
Teams API クライアントを新設 |
interfaces/routes/teams.py |
POSTエンドポイントやWebhookイベントを追加 |
shared/utils/teams_helper.py |
共通フォーマット処理が必要ならヘルパーで切り出し |
ポイント：
- 常に「ビジネスロジック→ユースケース→インフラ→I/O」の責務分離を維持
- インターフェースの実装（
implements）はインフラ層に限定
✅ ベストプラクティスまとめ
- ドメイン層は最も重要、かつ不変
- ユースケース層は「何をするか」に集中
- インフラ層は「どう実現するか」に限定
- インターフェース層は「どこから来たか」の責務
📌 推奨資料
📝 まとめ
- 本記事では、Slackからの質問に応答するAIエージェントの設計思想を、Clean ArchitectureとDDDに基づいて整理しました。
- 各層の責務を明確に分離することで、拡張性・テスト容易性・保守性を高めることができます。
- Mermaidを活用したアーキテクチャ図やディレクトリ構成の整理により、全体像が直感的に把握できるようにしました。
🔭 今後の展望・課題
- ChatGPTだけでなく、ClaudeやGeminiなど複数のLLMへの切り替え対応
- SaaS連携の追加（例：Notion, Confluence, Miroなど）に対応するユースケースの設計
- WebSocketベースのブラウザ連携や、Slackとのマルチチャネル対応
- LangGraphやAgentExecutorなどを使った状態管理付きエージェントの導入