この記事では、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などを使った状態管理付きエージェントの導入