システムへの要求事項を入力に、ODC向けのアーキテクチャ設計を行うsubagentを作ってみる。
アーキテクチャ設計はシステム単位で設計の初期にしかやらないので、なかなか熟練できないことから、精度のいい下書きができると嬉しい、と言う考えから。
sub agentとは
Claude Codeのセッションから起動し、元のセッションのコンテキストから独立して、事前に定義した役割に従って作業してくれるもの。
ここでは、ODC向けのアーキテクチャ設計を実行してくれるものを作ってみる。
ODCのアーキテクチャ設計について
以前書いた記事（公式ドキュメントへのリンクも記事中にある）：
①ODC出掛けの頃にODCのアーキテクチャ設計についてまとめたもの
②ODCでのアーキテクチャ設計周りの変更点を受けて、O11経験者向けに注意点を書いたもの
サンプルシナリオ
Geminiに考えてもらった。
## サンプルシステム化要求案：『スマート物流・配送管理システム』
### 1. システム概要
全国でEC事業者向けに倉庫保管およびラストワンマイル配送を提供する物流企業における、新規の「統合配送・倉庫管理システム」の構築プロジェクト。
---
### 2. 主要なビジネス領域と要求事項
#### ① 顧客（EC事業者）向けポータル（Customer Portal）
* EC事業者が商品の「入庫予約」「在庫確認」「出荷依頼」を行えるようにする。
* 出荷された荷物のリアルタイム配送ステータス（移動中、配達完了など）を確認・追跡できるようにする。
* **ビジネス所有者:** 営業・カスタマーサクセス部門
#### ② 倉庫作業・在庫管理（Warehouse Operations）
* 倉庫作業員がハンディ端末で商品の「受入・棚入れ」「ピッキング」「検品・梱包」を行う。
* 倉庫内のロケーション別在庫数を正確に管理する。
* **ビジネス所有者:** 物流拠点・倉庫運営部門
#### ③ 配送・フリート管理（Fleet & Delivery Operations）
* 配送ドライバーへの自動ルート割り当て、配送ステータス更新機能を提供する。
* 配達完了時の「電子サイン収集」や「置き配写真のアップロード」を行う。
* 配送中の温度変化やドライバーの動態管理を行う。
* **ビジネス所有者:** 配送・運送管理部門
#### ④ 請求・決済管理（Billing & Invoice）
* 顧客（EC事業者）に対する「保管料」「発送手数料」「配送キャリア実費」を計算し、月次請求書を発行する。
* クレジットカード決済および売掛金の回収管理を行う。
* **ビジネス所有者:** 経理・財務部門
---
### 3. 外部システム・共通基盤要求（NFR & Integrations）
* **外部配送キャリアAPI :** 自社配送できない地域について、外部配送会社へ集荷依頼・送り状発行・追跡情報同期を行う。
* **基幹会計システム（SAP）:** 請求データ・売上確定データをSAPへ夜間バッチ（またはREST API）で連携する。
* **認証基盤（IdP / Azure AD）:** 社員（作業員・ドライバー）および顧客のシングルサインオン（SSO）連携。
subagentの材料
アーキテクチャ設計について解説する公式の動画コースArchitecture Design Processの「Materials」ボタンをクリックするとダウンロードできるPDFファイル。
作業用ディレクトリに「references」と言うサブディレクトリを作成し、その配下に配置した。
subagent作成
Claude Codeに依頼したプロンプト
下の要件を満たすsubagentを作成したい
/design_architectureで起動する
入力：ファイルパス（ファイルは、システム化要求を示すドキュメント。サンプルはrequirementsディレクトリに置いてある）
設計ルール：referencesフォルダにあるPDFファイルにルールと手順がある
Claude Codeの返答
PDFの内容(Disclose → Organize → Assemble)を読み込みました。これを踏まえて、/design_architecture <ファイルパス> で起動し、references/ フォルダのPDFをルールソースとして参照しつつODC設計プロセスを実行するsubagentとスラッシュコマンドを作成します。
作成されたファイル
以下の２ファイルが作成された。
slash command
「/」の後にコマンド名を入力することで起動するコマンドを定義する。
.claude/commandsディレクトリの下に配置したmdファイルで定義する。
この定義はパラメータとして要求仕様を定義するファイルのパスを渡すようになっている。
design_architecture.md
---
description: 要求ドキュメントに対してODC(Disclose→Organize→Assemble)のアーキテクチャ設計プロセスを実行する
argument-hint: <requirements-file-path>
---
design-architecture サブエージェントを起動し、次のファイルに対してODCアーキテクチャ設計プロセス（Disclose → Organize → Assemble）を実行してください。
対象ファイル: $ARGUMENTS
サブエージェントには次を明示して依頼すること。
- 分析対象のシステム化要求ドキュメントのパス（上記）
- 設計ルールは `references/` フォルダ内のPDFを正として従うこと
- Disclose（コンセプト抽出）→ Organize（バウンデッドコンテキストへのグルーピング）→ Assemble（アプリケーション/ライブラリ/コネクタへのマッピングとArchitecture Blueprint作成）の順に分析し、Markdown形式で結果を報告すること
対象ファイルパスが指定されていない場合は、実行前にユーザーへファイルパスを確認すること。
subagent
slash command内で起動するように指定されているsubagent。
subagent作成時に参照したPDFを正の情報として、実行時にも参照するように指定されている。ざっとみた感じ、手を入れたくなるところもあるが、大まかに良さそうなので一旦これで実験してみる。
design-architecture.md
---
name: design-architecture
description: システム化要求ドキュメントを読み込み、OutSystems ODC (Disclose → Organize → Assemble) のアーキテクチャ設計プロセスに沿ってドメイン分析とアーキテクチャブループリントを作成する。要求ドキュメントからバウンデッドコンテキストやODCアプリケーション構成へのマッピングが必要なときに使う。
tools: Read, Grep, Glob
model: inherit
---
あなたはOutSystemsのODC (Disclose -> Organize -> Assemble) アーキテクチャ設計プロセスの専門家です。渡されたシステム化要求ドキュメント（ファイルパス）を分析し、`references/` フォルダにあるPDF「Architecture Design Process」の設計ルールに厳密に従って、ドメイン分析とアーキテクチャブループリントを作成してください。
## 進め方
0. **設計ルールの確認**
- `references/` フォルダ内のPDFファイル（Architecture Design Process）を必ず読み込み、最新のルール・手順・図解を確認する。以下の手順は要点の要約であり、内容に矛盾があればPDFの記載を優先する。
- 渡されたファイルパスのシステム化要求ドキュメントを読み込む。ファイルが存在しない・パスが曖昧な場合はユーザーに確認する。
1. **Disclose（開示）— アプリケーションコンセプトの洗い出し**
- 以下の観点で要求ドキュメントを読み解き、コンセプトを抽出する。
- ビジネス要求、業務プロセス、ユーザーストーリー、ペルソナ、ロール
- 情報アーキテクチャ
- 非機能要求（NFR）、連携技術
- ユーザー体験の期待値
- NFRについては次のようなインタビュー観点を参考にし、要求文書内に明記がなければ「不明・要確認」として明示する。
- 外部IDプロバイダとの連携有無
- PDFやレポート生成の必要性
- 外部システム連携の有無・対象システム・認証方式
- 外部データベース連携の有無
- カスタムコードの必要性
- セキュリティ関連の懸念事項
- モバイルアプリの有無・ネイティブプラグイン要件
- 抽出結果を以下の表形式でまとめる。
| Concept | Type (Persona/Role/Business/Integration/NFR) | Description |
2. **Organize（整理）— バウンデッドコンテキストへのグルーピング**
- 抽出したコンセプトを以下の基準でグルーピングし、バウンデッドコンテキスト候補を導出する。
- ユビキタス言語（同じ用語が文脈によって異なる意味を持つ場合は要注意）
- ドメインエキスパートの境界
- 業務プロセスのステップ、データフロー、オーナーシップ
- 依存関係のクラスタリング、コンセプトの凝集度
- グルーピング結果と、コンテキスト間の依存関係（Strong/Weak）を示す。
- 用語の意味が文脈によって変わる箇所（例：同じ単語が業務領域ごとに異なる意味を持つケース）があれば必ず明記し、境界づけられたコンテキストを分離する根拠として扱う。
3. **Assemble（組み立て）— アプリケーション・ライブラリ・コネクタへのマッピング**
- 各バウンデッドコンテキストについて、ビジネスオーナー・ビジネススポンサー・プロダクトチームを要求ドキュメントから特定する（不明な場合は「要ヒアリング」と明示する）。
- 以下のルールを厳守する。
- 1つのアプリケーションに複数のビジネスオーナーを混在させない
- リリースサイクルの独立性を確保するため、ペースの異なるビジネススポンサーを混在させない
- 1つのアプリケーションのオーナーチームは1つに限定する
- 判定基準：
- ビジネスオーナー・スポンサー・プロダクトチームが全て単一 → **Simplified Approach**（単一アプリケーションに全コンテキストを内包し、開発・アーキテクチャ工数を抑える）
- オーナー・スポンサー・チームが複数存在 → **Distributed Approach**（Assembleの基準に従ってバウンデッドコンテキストを複数アプリケーションに分割し、チーム独立性とオーナーシップの明確化を優先する）
- 外部システム連携（例：外部API、基幹システム、IdP等）は個別アプリケーションではなく **Connector / Library** として切り出す。
- 最終的に以下を含む **Architecture Blueprint** を提示する。
- アプリケーション一覧（名称、含まれるバウンデッドコンテキスト、オーナー、スポンサー、プロダクトチーム）
- ライブラリ／コネクタ一覧（対象の外部システム、利用元アプリケーション）
- アプリケーション間・アプリケーションとコネクタ間の依存関係（Strong dependency / Weak dependency）
- 可能であればMermaid graph記法でブループリントを可視化する
## 出力フォーマット
Markdown形式で、上記1〜3の各セクションを見出し付きで出力する。最後に「未確定・要ヒアリング事項」セクションを設け、ビジネスオーナー／スポンサー情報などAssembleの判断に必要だが要求ドキュメントに記載がない情報を箇条書きで列挙する。
Disclose → Organize → Assemble は反復プロセスである。Organize/Assembleの過程でDiscloseの抽出漏れや誤りに気づいた場合は、その時点でDiscloseの結果を修正し、最終出力に反映する。
実験
試しに実行してみた。
sub agent起動
/design_architecture requirements/samplerequirements.md
slash commandを作成したセッション中ではコマンドを認識してくれなかったので、Claude Codeを一旦停止して開き直した。
3分ほどで分析が終了し、結果が共有された。
整形して共有しようか、と言う提案があったので、整形してもらったのが以下。
（プロンプトでは、結果をMarkdownとして作成し、図があればMermaidにするように依頼した）
整形結果：スマート物流・配送管理システム — ODCアーキテクチャ設計分析
-
対象ドキュメント:
requirements/samplerequirements.md -
設計ルール参照:
references/Architecture Design Process.en-US.ODC.pdf - 作成日: 2026-07-26
- 分割方針: Distributed Approach
PDFに示された手順（Where to Start? → Identifying the Concepts → Grouping Concepts → Assemble → Architecture Blueprint）に従い、Disclose → Organize → Assemble の順で分析する。
1. Disclose — コンセプト抽出
要求ドキュメントの4業務領域と外部連携要求から、Persona／Business Process／Integration・NFRの観点でドメインコンセプトを抽出した。
Persona / Role
| Concept | 説明 |
|---|---|
| EC事業者（顧客） | 倉庫保管・配送を利用する荷主。ポータルで入庫予約・在庫確認・出荷依頼を行う |
| 営業・カスタマーサクセス部門 | Customer Portal のビジネス所有者 |
| 倉庫作業員 | ハンディ端末で受入・棚入れ・ピッキング・検品梱包を行う現場担当 |
| 物流拠点・倉庫運営部門 | Warehouse Operations のビジネス所有者 |
| 配送ドライバー | ルート配送、電子サイン収集、置き配写真アップロードを行う |
| 配送・運送管理部門 | Fleet & Delivery Operations のビジネス所有者 |
| 経理・財務部門 | Billing & Invoice のビジネス所有者 |
Business Process
| Concept | 説明 |
|---|---|
| 入庫予約 | EC事業者による商品搬入予約 |
| 在庫確認（顧客向け参照） | 顧客ポータルで参照する在庫サマリー |
| 出荷依頼 | EC事業者からの出荷指示（倉庫のピッキング処理を起動） |
| 配送ステータス追跡（顧客向け表示） | 顧客が閲覧する配送進捗（移動中・配達完了等） |
| 受入・棚入れ | 倉庫内商品受入と格納作業 |
| ピッキング | 出荷指示に基づく商品取り出し |
| 検品・梱包 | 出荷前の検品・梱包作業 |
| ロケーション別在庫（真実のソース） | 倉庫の棚・区画単位の正確な在庫数管理 |
| 自動ルート割当 | 配送ドライバーへの最適ルート自動割当 |
| 配送ステータス更新（ドライバー起点） | ドライバーが更新する配送進捗（追跡表示の元データ） |
| 電子サイン収集 | 配達完了時のサイン取得 |
| 置き配写真アップロード | 置き配証跡の画像アップロード |
| 温度変化モニタリング | 配送中のコールドチェーン等の温度管理（IoT/センサー連携の可能性） |
| ドライバー動態管理 | 車両・ドライバーの位置動態管理（GPS/テレマティクス連携の可能性） |
| 保管料 | 倉庫保管に対する課金項目 |
| 発送手数料 | 出荷処理に対する課金項目 |
| 配送キャリア実費 | 外部キャリア利用時の実費請求項目 |
| 月次請求書発行 | 月締めで発行される請求書 |
| クレジットカード決済 | 顧客決済手段 |
| 売掛金回収管理 | 未回収債権管理 |
Integration / NFR
| Concept | 説明 |
|---|---|
| 外部配送キャリアAPI | 自社配送不可地域向け集荷依頼・送り状発行・追跡情報同期 |
| 基幹会計システム（SAP） | 請求・売上確定データの夜間バッチ／REST API連携 |
| 認証基盤（IdP／Azure AD） | 社員（作業員・ドライバー）・顧客のSSO |
NFRインタビュー観点チェック（PDF準拠）
| 質問項目 | 回答 |
|---|---|
| 外部IDプロバイダとの連携有無 | あり（Azure AD、社員・顧客のSSO） |
| PDF／レポート生成の必要性 | 要確認 — 月次請求書のPDF出力要否は未記載 |
| 外部システム連携の有無・対象・認証方式 | あり（配送キャリアAPI、SAP）。要確認 — 認証方式は未記載 |
| 外部データベース連携の有無 | 要確認 — 未記載（SAP連携がAPIかDB直結か含む） |
| カスタムコードの必要性 | 要確認 — 未記載。温度センサー／GPS連携で必要になる可能性大 |
| セキュリティ関連の懸念事項 | 要確認 — 未記載。PCI DSS対応・個人情報保護等 |
| モバイルアプリ・ネイティブプラグイン要件 | 要確認 — ハンディ端末scan／電子サイン／写真／GPS／温度センサーの性質上、必要な可能性が高い |
2. Organize — バウンデッドコンテキスト
ドメインエキスパート境界（部門境界）と業務プロセスの区切りが一致しているため、4業務領域をそのままバウンデッドコンテキスト候補としてグルーピングした。
ユビキタス言語の注意点（境界づけの根拠）
- 「在庫」の多義性 — Customer Portalの「在庫確認」は顧客に見せる参照用の在庫サマリーであるのに対し、Warehouse Operationsの「ロケーション別在庫」は倉庫内の真実のソース（Source of Truth）である。両者は別のバウンデッドコンテキストとして分離し、Customer Portal側は Warehouse Operations が公開する集計データ（射影）を参照する構造とすべきである。
- 「配送ステータス」の多義性 — Fleet & Delivery Operationsでの「配送ステータス更新」はドライバーが記録する一次データであるのに対し、Customer Portalでの「配送ステータス追跡」は顧客向けの表示専用データである。生成元と参照先が異なるため別コンテキストとして分離し、Fleet & Delivery Operations → Customer Portal への一方向のデータ連携とする。
コンテキスト間依存関係
| From | To | 種類 | 理由 |
|---|---|---|---|
| Customer Portal | Warehouse Operations | Strong | 出荷依頼が倉庫のピッキング処理を直接起動する業務上必須のフロー |
| Customer Portal | Fleet & Delivery Operations | Weak | 配送ステータス表示は参照目的の非同期連携で成立可能 |
| Customer Portal | Billing & Invoice | Weak | 請求書参照・決済実行は独立して非同期に扱える |
| Warehouse Operations | Fleet & Delivery Operations | Strong | 梱包完了荷物の配送引き渡しは業務プロセス上必須の連携点 |
| Warehouse Operations | Billing & Invoice | Weak | 保管実績データは月次バッチで集計連携すれば足りる |
| Fleet & Delivery Operations | Billing & Invoice | Weak | 配送実績（配送キャリア実費等）は月次バッチで集計連携すれば足りる |
| Fleet & Delivery Operations | 外部配送キャリアAPIコネクタ | Strong | 自社配送不可地域の集荷・送り状発行に業務上必須 |
| Billing & Invoice | SAPコネクタ | Strong | 会計確定データ連携は経理業務上必須 |
| 全コンテキスト | IdP／Azure ADライブラリ | Strong | 認証がなければ各アプリが機能しない |
Warehouse OperationsおよびBilling & Invoiceの内部は業務ステップ別（受入棚入れ／ピッキング検品梱包／在庫元帳、料金計算／請求書発行／決済・債権管理）にさらに細分化可能だが、いずれも同一部門・同一オーナー内の違いに過ぎずオーナーシップ分割の根拠がないため、アプリケーション分割ではなく内部モジュール構成候補として留めた。
3. Assemble — Architecture Blueprint
ビジネスオーナー・スポンサー・プロダクトチーム
| Bounded Context | Business Owner | Business Sponsor | Product Team |
|---|---|---|---|
| Customer Portal | 営業・カスタマーサクセス部門 | 要ヒアリング | 要ヒアリング |
| Warehouse Operations | 物流拠点・倉庫運営部門 | 要ヒアリング | 要ヒアリング |
| Fleet & Delivery Operations | 配送・運送管理部門 | 要ヒアリング | 要ヒアリング |
| Billing & Invoice | 経理・財務部門 | 要ヒアリング | 要ヒアリング |
判定: Distributed Approach を採用
PDF「Simplified Approach」の適用条件（One Business Sponsor／One Business Owner／One Product Team）を満たさず、「Distributed Approach」の条件（複数のBusiness Owner／Sponsor／Product Team）に該当する（PDF Scenario 4 相当）。1コンテキスト＝1アプリケーションとし、オーナーの異なるコンテキストを混在させない。
アプリケーション構成
| Application | 含まれるバウンデッドコンテキスト | Owner |
|---|---|---|
| Customer Portal App | 入庫予約・在庫参照・出荷依頼・配送追跡表示 | 営業・カスタマーサクセス部門 |
| Warehouse Operations App | 受入棚入れ・ピッキング・検品梱包・在庫元帳 | 物流拠点・倉庫運営部門 |
| Fleet & Delivery App | ルート割当・配送ステータス・電子サイン・置き配写真・温度／動態管理 | 配送・運送管理部門 |
| Billing & Invoice App | 料金計算・請求書発行・決済・債権管理 | 経理・財務部門 |
ライブラリ／コネクタ
| Library / Connector | 対象の外部システム | 利用元アプリケーション | 種類 |
|---|---|---|---|
| Carrier API Connector | 外部配送キャリアAPI | Fleet & Delivery App | Strong |
| SAP Connector | 基幹会計システム（SAP） | Billing & Invoice App | Strong |
| IdP Connector | 認証基盤（Azure AD） | 全アプリケーション共通 | Strong |
| Telematics / IoT Connector | 仮 — 車両テレマティクス／温度センサー等（具体名称は要求文書に未記載） | Fleet & Delivery App | Strong（想定） |
Architecture Blueprint 図
実線 = Strong（業務上必須の連携）／破線 = Weak（非同期・バッチ連携）
PDFルールとの整合性についての補足
- 要求ドキュメントの4業務領域の区切りとPDFの「ドメインエキスパート境界」「Business Owners」基準が一致していたため、コンテキスト分割は比較的機械的に導出できた。
- 唯一の簡略化点は、Warehouse OperationsとBilling & Invoiceの内部を業務ステップ別にさらに分離しなかったことである。内部ステップは同一部門・同一オーナーであり、Assembleフェーズの分割基準（オーナー・スポンサー・チームの独立性）を満たす理由がないと判断した。
- Telematics/IoT Connectorは要求文書に明記のない外部システムを「温度変化・動態管理」の記述から推測して仮置きしたものであり、Blueprint上は「仮」と明示している。
未確定・要ヒアリング事項
- Customer Portal／Warehouse Operations／Fleet & Delivery／Billing & Invoice それぞれのBusiness Sponsor（経営層側の意思決定者）は誰か
- 各コンテキストを担当するProduct Teamの体制は部門ごとに分かれているか、共通チームが兼任するか
- 月次請求書についてPDF／レポート生成が必要か（必要な場合、様式・出力トリガー）
- 外部配送キャリアAPI・SAP連携の認証方式（APIキー、OAuth2、証明書等）
- 外部データベースへの直接連携（SAPや配送キャリア以外）の有無
- カスタムコードの利用要否（特に温度センサー・GPSデバイスとの連携部分）
- セキュリティ要件（クレジットカード決済のPCI DSS対応、個人情報・位置情報の取り扱い等）
- モバイルアプリ／ネイティブプラグインの要否（倉庫ハンディ端末のバーコード／RFIDスキャン、ドライバー用の電子サイン・カメラ・GPS・Bluetooth温度センサー連携）
- 「温度変化」「ドライバーの動態管理」を実現する具体的な外部システム／IoT基盤の有無・名称（Telematics/IoT Connectorの実体確認）
- Customer Portalでの決済（クレジットカード決済）と、Billing & Invoiceでの決済処理の責務分担（決済処理自体をどちらのコンテキストが担うか）
活用方法について
方法①ODC向けのアーキテクチャ設計ツールとしてsub agentを完成させる
例えば以下のような部分を改良し、できたsub agentの定義ファイルはgitなどでバージョン管理して共有すれば十分に役立つものを作れそう。
- 出力テンプレートを決める（企業ごとの標準に沿うように）
- 元の要求ドキュメントに比べて結果が肥大しすぎている。勝手に補うのは防止する
- 担当者が結果をみて追加プロンプトを入力する手順もまとめる
- インタビュー観点などは、なくていい気がする
- まず、アーキテクチャ設計のルールを企業ごとに公式ドキュメントを元に明確化し、そちらをsub agentの入力にする
- 結果の参照関係のStrong/Weakの解釈が正しくなさそう（こういう技術的な間違いも修正したプロンプトにする必要がある）
方法②技術独立にDDDの戦略的設計を行い、設計・実装を行うチームがODC or 一般言語の選択をできるようにする
ここで検証したアーキテクチャ設計手順は、DDD一般で言うと、戦略的設計に該当するらしいい。その部分は実装技術に中立らしい。
そこで、DDDでいう戦略的設計をsub agentで行い、設計・実装を行うチームの選択で、
- ODCで実装する場合、戦略的設計をODCのアーキテクチャ設計にマッピングする（AIで自動化）
- ODC以外で実装する場合、そのままDDDの戦術的設計に繋ぐ
とするのはどうだろうか。
最近のコーディングエージェントの実力を考えると、実装技術に何を選んでも、実装は大抵AIになる気もするが。