【提案】VSA × DDD × ハーネス3層を貫く「安定したものを共有、変化するものを分離」という設計原理

• 想定読者： 中〜大規模で AI コーディングと Agentic AI を運用するテックリード、プラットフォームエンジニアリングリード、アーキテクト
• 前提知識： Vertical Slice Architecture（VSA）の基本、Bounded Context など DDD 戦略的設計の概念、AI コーディングエージェントの業務利用経験
• 所要時間： 約35分

本記事の位置づけ: 本記事は 新しい統合提案 であり、VSA × DDD × ハーネス3層を組織で運用した直接事例の報告ではない。VSA × AI、DDD × マルチエージェント、ハーネス設計それぞれの関連パターンから推測した接続案であり、最後にメリット・デメリット・撤退ラインを多角的に検証する。

概要

過去2週間でこのブログは AI 開発の設計判断について3つの記事を出した――VSA は 1スライス＝1コンテキストとして AI 開発と相性がよい、VSA と DDD のハイブリッドは複数の方向性が並走している、ハーネスは組織／共用／プロジェクトの3層に分け、データと外部ツール組織規約に厚く投資する。

3記事は別々のテーマに見える。VSA はコード構造の話、DDD は境界設計の話、ハーネスは AI エージェントの運用基盤の話だ。だが、それぞれを実装に落とそうとする現場では、設計判断が衝突する瞬間がある。VSA は「分けろ・共通化するな」と言う。ハーネス3層は「共通化しろ・各プロジェクトで車輪を再発明するな」と言う。表面的には正反対だ。

この衝突は、3つの記事を別々のレイヤーで読んでいるうちは見えない。だが1人のアーキテクトが「自社の共用ハーネスにどのスキルを置くか」を決める瞬間、両者は同じ机の上で衝突する。共用層に「ドメイン側の意見」を流し込めば、VSA が嫌う早すぎる共通化が運用基盤経由で復活する。逆に共用層を空にすれば、ハーネスの利点が消える。

本記事の主張はこうだ。VSA の「分けろ」と、ハーネス3層の「共通化しろ」は、抽象階層が違うため矛盾ではない。両者は「安定したものを共有し、変化するものを分離する」という単一原理の二つの表現にすぎない。VSA は ビジネスドメイン抽象 の早すぎる共有を警戒する。ハーネス3層は 運用基盤抽象 の散在を警戒する。共有してよい層（運用・規約・データ）と、共有してはいけない層（ビジネスロジック・ドメイン解釈）が別であることを認めれば、両者は同じ判断軸の下で一貫して使える。

そしてこの統一原理を媒介するのが DDD の Bounded Context（境界づけられたコンテキスト） だ。Bounded Context は「ここから先はドメインの意見が変わる」境界を引く。VSA はその境界内で機能スライスを縦に切る。ハーネス共用層はその境界を尊重して並立する（バックエンド共用 / 規制遵守共用 / 在庫共用、のように）。CLI ガードレール（前回記事の mycorp-pr パターン）はその境界をハード強制する道具になる。

実装に持ち帰る視点では、本記事は1つの流れとして読める。小規模で VSA → ナレッジ共有の痛みで ハーネス共用層 → ドメイン分岐の痛みで DDD → 規制ガバナンスの痛みで 組織ハーネス。この4段階を貫いて同じ判断原理（安定→共有、変化→分離）が効く、というのが中心的な提案だ。ハーネスが2回登場すること（共用層と組織層）、DDD のトリガーは「規模」ではなく「ドメイン分岐」であることが、この流れの肝になる。

本記事は §1 で3記事の地図と衝突点を整理し、§2 で表面的矛盾を解消する根底原理を、§3 で接続点を具体化し、§4 でアンチパターン、§5 で段階的導入を扱う。続く §6 では Next.js（複数サイト）+ 一部 Go API という典型的なスタックでの実装パターンを具体化し、§7 で多角的評価を行う。事例ではなく提案であることは最後まで繰り返し強調する。

姉妹記事: 本記事は基盤となる3記事の上に組み立てる統合提案だ。先に VSA × AI VSA × DDD ハーネス3層 のいずれかを読んでいると、本記事の文脈が一気に解像する。

§1. 議論の地図と衝突点

まず3記事を1枚の地図に並べ、それぞれが扱っている層と判断軸を明示する。

3記事それぞれの守備範囲

記事	守備範囲	中心的な判断軸
VSA × AI	コード構造（1リポジトリ内）	機能スライス単位での縦割り、共有抽象の最小化
VSA × DDD	コード構造＋ドメイン境界	Bounded Context での括り、戦略的設計のみ採用
ハーネス3層	AI エージェント運用基盤	組織／共用／プロジェクトの責任分離、データ層への厚い投資

3記事は別々のレイヤー（コード構造、ドメイン設計、運用基盤）を扱っている。が、AI コーディングエージェント時代では、この3層を貫いて同じプロンプトとコンテキストが流れる。エージェントが「どのスライスを編集するか」決める時、「どの Bounded Context のルールに従うか」決める時、「どの共用スキルを使うか」決める時――すべて同じ思考プロセスの中で起きる。設計判断が3記事間で一貫していないと、エージェントの判断が割れる。

衝突点を具体化する

衝突は3つの場面で起きる。

衝突1: 共用スキルにビジネスロジックを書くべきか

ハーネス3層の共用層には「複数プロジェクトで再利用可能なスキル」が置かれる。素直に運用していると、「注文処理スキル」「決済バリデーションスキル」「在庫引当スキル」のようなドメイン寄りスキルが共用層に流れ込みやすい。

VSA の観点では、これは典型的な「早すぎる共通化」だ。販売 Context の『注文』と物流 Context の『注文』は概念が違う。共用層で1つの『注文処理スキル』に押し込めると、Context 固有の差異が押し殺される。

逆に「共用層には書くな」だけだと、各プロジェクトが似たスキルをコピペし始め、ハーネス3層が解こうとした問題が再発する。

衝突2: Bounded Context の境界とハーネスの共用境界をどう整合させるか

ハーネス3層では「バックエンド共用 / フロントエンド共用 / セキュリティ共用」など、技術スタック軸 で共用層を切るのが直感的だ。一方、DDD では「販売 / 在庫 / 規制遵守」など、ドメイン軸 で Bounded Context を切る。

両者が直交していると、共用スキルが Context 境界を踏み越えてしまう。例えば「バックエンド共用」スキルが販売 Context と在庫 Context の両方で同じ振る舞いをすると、Context ごとの差異（用語、不変条件、検証ルール）が消える。

衝突3: スライス境界とコンテキスト供給単位をどう一致させるか

VSA は「1スライス＝1機能＝1コンテキスト」をエージェントに渡す前提で機能している。だがハーネス3層では「組織 RAG が広いコンテキストを供給する」前提もある。両者の関係が曖昧だと、エージェントはスライス内のコードを編集中に組織 RAG から 別 Context の用語 を引いてきて、命名規約を取り違える可能性がある。

flowchart TB
    A[AIエージェントの1つの編集タスク] --> B{どの層の判断が効く?}
    B --> C[コード構造判断<br>どのスライスを編集するか]
    B --> D[ドメイン判断<br>どのBounded Contextのルールか]
    B --> E[運用判断<br>どの共用スキルを呼ぶか]
    C -.->|不整合| F[衝突<br>判断が割れる]
    D -.->|不整合| F
    E -.->|不整合| F

これら3つの衝突は、3記事の議論をそれぞれ単独で読んでいる限り見えない。統合提案が必要な理由はここにある。

§2. 表面的矛盾の解消――根底原理

VSAの「分けろ」とハーネス3層の「共通化しろ」は、抽象階層が違う。VSAが警戒するのは ビジネスドメインの早すぎる共通化¹、ハーネス3層が警戒するのは 運用基盤の散在²――それぞれの背景は元記事に詳しい。

ここで本記事が主張したいのは、この2つの警戒は同じ原理の2つの表現にすぎないということだ。

共有してよいのは「組織として安定しており、長期間変わらない」もの。分離すべきは「文脈ごとに意味が変わる、または短期で陳腐化する」もの。

具体化するとこうなる。

性質	共有してよいもの	分離すべきもの
コード構造（VSA）	横断的技術基盤（HTTP middleware、ORM、ロガー）	ビジネスロジック、ドメイン解釈、機能要件
ドメイン設計（DDD）	Ubiquitous Language（Context内）、戦略的設計のメタパターン	Context間の概念、Aggregate定義、不変条件
運用基盤（ハーネス）	組織RAG・データ・アクセス制御、外部ツール組織規約CLI、Must lint	汎用ワークフロー（公式に置換予定）、API ラッパー（公式に置換予定）

3層の判断軸は同じだ。「変化のタイムスケールと、変化の局所性」 で共有可否が決まる。

flowchart TB
    P[統一原理<br>安定→共有<br>変化→分離]
    P --> V[VSA層の判断<br>技術基盤=共有<br>ビジネス=分離]
    P --> D[DDD層の判断<br>戦略設計=共有<br>戦術詳細=分離]
    P --> H[ハーネス層の判断<br>データ・規約=共有<br>汎用ワークフロー=分離]

この単一原理の下で考えれば、§1 の衝突は再解釈できる。

• 衝突1: 共用スキルにビジネスロジックを書くべきか → 書かない。ビジネスロジックは Context ごとに意味が変わる「変化するもの」だから。共用層には「RAG 検索のお作法」「PR 作成のガードレール」「コードレビューのモード遷移」など、Context 解釈を含まない運用パターンだけを置く。
• 衝突2: Bounded Context とハーネス共用境界の関係 → 共用層は Context 境界を踏み越えない。技術スタック軸の共用層を作ること自体は問題ないが、その中身は「Context 解釈を含まない技術基盤」に限定する。Context 固有のルールは Context 内に置く。
• 衝突3: スライス境界とコンテキスト供給単位 → VSAスライス = エージェントが編集する単位、Bounded Context = エージェントが参照する語彙の単位。RAG は Context タグ付きで応答すべきで、エージェントは現在編集中のスライスがどの Context に属するかを認識した上で RAG を引く。

これが本記事の中心的な発見だ。3記事の判断軸は同じ原理で動いており、衝突は「どの抽象階層で何を共有するか」を取り違えたときに起きる。

§3. 接続点の具体化――3層を一貫した設計判断としてつなぐ

統一原理を運用に落とすには、具体的な接続点を定義する必要がある。本節では3つの接続点を提示する。

接続点1: VSAスライス＝エージェントへのコンテキスト供給単位

VSA × AI³ が示した「1スライス＝1コンテキスト」原則を、ハーネス3層と接続する。

エージェントが編集タスクを受けたとき、スライスフォルダの境界がコンテキストウィンドウの自然な区切りになる。ハーネス共用層の Explore→Plan→Implement ワークフロー²はこの単位で動くべきだ。具体的には：

• Explore モード: 編集対象スライスのファイル群を全件読み込み、隣接スライスは参照しない（ただし依存先の関数シグネチャは確認）
• Plan モード: 計画ドキュメントは「このスライスで何を変えるか」を1ページで完結させる
• Implement モード: 編集が他スライスに波及した瞬間、警告を出す（VSA 違反の検知）

これは VSA の「結合の局所化」原則を、ハーネスのワークフロー実装で機械的に強制することを意味する。ワークフロー本体は共用層に置く（汎用パターン）が、「スライスとは何か」の境界判定はプロジェクト層に置く（プロジェクト固有の features/ パスなど）。

接続点2: DDD Bounded Context＝共用ハーネスの並立境界

ハーネス共用層を「バックエンド共用 / フロントエンド共用 / セキュリティ共用」のように技術スタック軸だけで切ると、§1 衝突2 の問題が起きる。代わりに、Bounded Context 軸を共用層の並立軸の1つとして組み込む。

具体例として、規制遵守 Context（金融機関でいう「KYC・AML」）を考える。この Context には独自の用語（顧客、取引、リスク評価）、独自の不変条件（取引額閾値、本人確認の有効期限）、独自の検証フロー（疑わしい取引報告、当局報告）がある。これらを「規制遵守 Context 共用ハーネス」としてまとめる。

flowchart TB
    subgraph ORG["🏢 組織ハーネス"]
        OG1["RAG: ADR・障害履歴"]
        OG2["Must lint: セキュリティ"]
    end

    subgraph SBE["🛠 バックエンド共用<br>技術スタック軸"]
        BE1["Go テンプレート"]
        BE2["gRPC 規約"]
    end

    subgraph SCO["🛠 規制遵守共用<br>Bounded Context軸"]
        CO1["KYC用語集"]
        CO2["AML 検証フロー"]
        CO3["当局報告テンプレート"]
    end

    subgraph PRJ["📦 プロジェクトハーネス"]
        PR1["販売プロジェクト"]
        PR2["在庫プロジェクト"]
    end

    PRJ ==> ORG
    PR1 -.->|参照| SBE
    PR1 -.->|参照| SCO

ポイントは2つある。

第一に、共用層は1つではなく複数並立する。技術軸の共用層（バックエンド共用、フロントエンド共用）と Context 軸の共用層（規制遵守、注文ライフサイクル、在庫管理）が並立してよい。これは「Learning to Share」論文⁴が示す「全部共有でも全部分離でもない、選別的共有」と整合する。

第二に、Context 軸共用層の中身は『Context 内で安定したもの』に限定する。Context 内で確立された Ubiquitous Language、確定した戦略的決定、変わりにくい検証ロジックだ。Context 間 で意味が変わる概念は、共用層に上がってはいけない。

接続点3: CLI ガードレール＝Bounded Context のハード強制

ハーネス3層が提示した CLI ガードレールパターン（mycorp-pr 等）²は、本来「外部ツール組織規約」の文脈で議論されていた。これを DDD の Bounded Context の境界強制 にも応用できる。

具体的には、Context 境界を越える通信を CLI 経由に限定する。例えば：

• mycorp-context call --from=sales --to=inventory --event=order-placed --schema=... のように、Context 間の呼び出しを必ず CLI ツール経由にする
• CLI 内部で スキーマ検証 と ACL（Anti-Corruption Layer）の翻訳ステップ を強制する
• 違反（直接呼び出し、スキーマ違反）は CI でブロックする

これは Nikita Golovko が AI Coding Summit 2026 で提示した「Bounded Context をエージェントの責任範囲、契約をスキーマ、ACL をセマンティック・ファイアウォール」という整理⁵と同じ方向だ。Golovko は概念整理を提示したが、実装機構は CLI ガードレールにできる、というのが本記事の追加提案だ。

CLI 経由にハード強制する利点は、ハーネス3層²で論じた通り、

• エージェント間で再利用可能（Claude Code / Codex / Cursor 共通）
• ハード強制ができる（説得ではなく不通過）
• 人間も同じ抽象を使える
• 観測可能（exit code、構造化ログ）

これに DDD 境界の機械強制 が加わると、「Bounded Context を引いたが運用で守られない」問題に直接答えが出る。

3層の接続を1枚に

3つの接続点を1枚にまとめるとこうなる。

flowchart TB
    subgraph ENG["AIエージェントの編集タスク"]
        T1["タスク受領"]
        T2["スライス特定"]
        T3["Context判定"]
        T4["共用スキル呼出"]
        T5["編集・検証"]
        T1 --> T2 --> T3 --> T4 --> T5
    end

    T2 -.->|接続点1| V["VSAスライス境界<br>=1コンテキスト単位"]
    T3 -.->|接続点2| B["Bounded Context<br>=共用層の並立軸"]
    T4 -.->|接続点3| C["CLIガードレール<br>=Context境界のハード強制"]

3記事は、この3つの接続点を通じて1つの一貫した設計判断として動く。統一原理（安定／変化）→ 接続点（具体化）→ ガードレール（強制） のチェーンが揃って初めて、組織レベルの一貫性が立つ。

§4. アンチパターン――失敗の典型

統合提案には、典型的な失敗パターンが伴う。直接事例は未発見だが、関連分野のアンチパターンから推測できるものを4つ整理する。

アンチパターン1: 共用層がアーキテクチャ意見を運ぶ

最も警戒すべきパターンだ。共用層に置かれたスキルが、特定のアーキテクチャ判断（イベント駆動 vs 同期 RPC、Aggregate vs Anemic Model など）を暗黙に押し付ける。

たとえば「共用 PR 作成スキル」が「Aggregate Root を変更する PR は Domain Event 発行ステップを追加」というルールを内蔵していたとする。これは販売 Context では理にかなっていても、規制遵守 Context では Event 発行が監査対象になるため別フローが必要かもしれない。共用層の意見が、Context 固有の判断を上書きしてしまう。

対策は、共用層スキルを徹底的に「How（操作手順）」に絞り、「What（ビジネス判断）」を一切含めないこと。判断は Context 層に押し戻す。Bardia Khosravi の AI コーディング規約集⁶も「予測可能なパターンを提示」が目的であり、ビジネス判断の押し付けではないことに注意したい。

Jellyfish のプラットフォームエンジニアリング・アンチパターン調査⁷でも、「The Platform for Everything（過剰設計）」――中央チームがあらゆるケースをテンプレートで吸収しようとしてボトルネック化する――と「Mandated Adoption（強制的な採用）」が代表的失敗として挙げられている。中央チームが「我々のベストプラクティス」を運ぶと、現場の Context 固有の事情が押し殺される。同じ罠が AI ハーネス共用層にも適用される。

アンチパターン2: Bounded Context をハーネス共用境界に流用しすぎる

逆方向の失敗もある。Bounded Context を「ハーネス共用層の唯一の並立軸」にしてしまうと、技術スタック横断の共通化（言語別テンプレート、CI 規約、ロガー設定）が実装しにくくなる。

対策は、共用層を「技術軸」と「Context軸」の2軸で並立させ、両者の重複は明示的に許容すること。例えば「Go バックエンド共用」と「規制遵守 Context 共用」の両方が同じプロジェクトで参照され、両者から validateTransaction() のような関数が呼ばれてもよい。重複は早すぎる抽象化より安い⁸という VSA の原則がここでも効く。

アンチパターン3: CLI ガードレールが開発速度を落とす

CLI ガードレール（mycorp-pr 等）を Context 境界に適用すると、簡単な変更でも CLI を経由しなければならない煩雑さ が発生する。エージェントの自由度も下がる。

対策は2点。

第一に、CLI を呼ぶこと自体を共用層スキルが自動化する。エージェントが PR を作成するときに「mycorp-pr を呼んでください」とプロンプトに書くのではなく、「PR を作成するスキル」が内部で mycorp-pr を呼ぶ。エージェントから見ると、抽象はスキル名のまま、機械強制は CLI が担う。

第二に、ハード強制する境界を絞る。すべての関数呼び出しを CLI 経由にするのは過剰だ。Context 間通信、外部ツール操作（GitHub、Slack、Jira）、デプロイ・本番操作――この3カテゴリだけに絞ると、ガードレールが効きながら開発速度を保てる。

アンチパターン4: 統合一貫性を優先しすぎて個別最適を全否定する

統合採用後、各層で「個別最適なら別の選択がいい」場面が頻繁に出る。たとえば「この Context は Aggregate を共用層に置きたい」「この技術軸共用層は2つの Context にまたがる便利関数を持ちたい」など。

統合の一貫性（§2の安定／変化原理）を絶対視すると、個別最適の正当な要望まで否定してしまい、現場の生産性と信頼を失う。逆に個別最適を許しすぎると統合の利点が崩れる。

対策は、統一原理を「常に従う規範」ではなく「逸脱時に説明責任を負うベースライン」として運用すること。例外を許す代わりに、ADR で逸脱の根拠と撤退条件を残す。これは VSA × DDD × ハーネスを別々に運用しているときには発生しない、統合採用時に固有の運用問題だ。

なお「3層を一気に作る」アンチパターンはハーネス3層² §4-1 で論じた漸進原則の話なので、本記事では §5 の段階的導入で扱う。

§5. 段階的導入――痛みが出た層から1段階ずつ

全体像――きっかけと入れるものの対応

詳細を読む前に、4段階の全体像を 「きっかけ → 入れるもの」 の対応表で示す。

段階	きっかけ（シグナル）	入れるもの
1. 小規模で開始	1リポジトリ・1プロジェクト	VSA
2. ナレッジ共有化	同じスキル・同じ規約を別リポジトリにコピペし始める	ハーネス共用層（技術軸スキル、テンプレ、CLI）
3. ドメイン分岐	「同じ言葉が違う意味で使われる」が頻発する	DDD（Bounded Context）+ Context軸共用層
4. 規制・ガバナンス	規制対応・全社コンプラが経営課題化	組織ハーネス（RAG・Must lint・監査）

この対応表で2つのポイントを強調しておきたい。

ポイント1: ハーネスは2段階に分かれて登場する

ハーネス3層²のうち、共用層 はナレッジ共有の痛みで段階2に入るが、組織層 はガバナンス・規制対応の痛みで段階4に来る。「ハーネスはまとめて1段階で導入する」と考えると、Context 境界が見える前に組織 RAG を作ってしまい、Context タグなしの単一知識ベースになる（後で Context 分割をやり直すのは高くつく）。

ポイント2: DDD のトリガーは「規模」ではなく「ドメイン分岐」

100人規模でも単一ドメインなら DDD は不要、30人でも事業領域が3つあれば DDD が要る。規模軸ではなく「Bounded Context が見えるかどうか」軸 で判定する。「規模が大きくなったから DDD」と捉えると、単純な CRUD なのに DDD を被せて重くなる典型的失敗（VSA × DDD §3 の Dogmatic DDD 批判）に近づく。

この順序が現実的な理由は、痛みが出る順序と、投資 ROI が立つ順序の両方で、この順序が自然だからだ。以下、各ステップの詳細を見る。

ステップ1: VSA 単体で運用を成熟させる

最初は1リポジトリ・1プロジェクトで VSA を採用する。これは VSA × AI で論じた領域だ。

このフェーズで身につけるべきは「機能スライスの境界を引く感覚」と「共有してよいもの／いけないものの線引き」。Rule of Three（同じコードが3回現れるまで抽象化しない）⁸、Bogard の「Don’t share business logic」原則¹、VSA × DDD の戦略的設計のみ採用の判断⁹――これらをチームの規範として定着させる。

このフェーズでは Bounded Context はまだ明示しなくてよい。事実、1プロジェクトの中に複数の Context が見えていない組織のほうが多い。

完了の目安: 同じスキル・同じパターンを複数の機能スライスでコピペし始めたとき。これが次フェーズの合図だ。

ステップ2: 痛みが出てきたらハーネス共用層を立ち上げる

スライス間・プロジェクト間で運用パターンの重複が見え始めたら、ハーネス3層²の共用層に着手する。

このフェーズで重要なのは、共用層を「技術軸」だけで切ること。Bounded Context を明示する前に、技術スタック共通の共用層（バックエンド共用、フロントエンド共用、セキュリティ共用）を1〜2個立ち上げる。

なぜ Context 軸より技術軸を先にやるか。技術軸は「みんなが同意しやすい」からだ。Go の API 雛形、React のフォーム部品、CI 設定――これらは Context 固有判断を含まず、純粋に技術基盤の話だ。チームが共用層運用に慣れる足場として最適だ。

並行して、外部ツール組織規約 CLI（mycorp-pr 等）を立ち上げる²。これも Context 軸を含まないため、技術軸共用層の延長として導入できる。

完了の目安: 共用層スキルが3〜5個運用され、複数プロジェクトで実際に再利用されていること。重複の解消が体感できるレベル。

ステップ3: ドメインの痛みが出てきたら Bounded Context を導入

Context 不一致の問題が顕在化してから DDD の戦略的設計を導入する。具体的なシグナルは：

• 同じ言葉（「注文」「顧客」「在庫」）が異なる機能で違う意味を持つ場面が頻発する
• エージェントが命名規約を取り違える（販売側の用語で在庫側のコードを書く、など）
• スライス間の依存が増えて VSA の利点が弱まる

このフェーズで VSA × DDD の議論⁹を持ち込む。Context 境界を明示し、Context 軸の共用層を技術軸共用層と並立させる。CLI ガードレール（§3 接続点3）を Context 境界のハード強制に拡張する。

完了の目安: 3〜4個の Bounded Context が認識され、Context 間通信が CLI 経由のスキーマ付きで成立していること。Ubiquitous Language が Context ごとに文書化されていること。

ステップ4: 組織ハーネス（RAG・ガバナンス）を立てる

ステップ1〜3を経て、規制対応や全社コンプライアンスが経営課題化したタイミング で組織ハーネス層を立ち上げる。この時点で共用層が複数並立し、Context 境界が明示され、CLI ガードレールが効いている状態にあるはずだ。

組織 RAG は Context タグ付き応答 を返す設計にする。「販売 Context での『顧客』」「規制遵守 Context での『顧客』」をエージェントが区別できるように、RAG の応答メタデータに Context タグを含める。

Must lint（セキュリティ・コンプライアンス）は Context 横断で適用する。これは「組織として絶対に破ってはいけない」項目なので、Context 境界より上位にある。

なぜ組織ハーネスを最後にやるか。Context 境界が見える前に組織 RAG を作ると、Context タグが付かない単一の知識ベースになる。後から Context 分割をやり直すのは高くつく。

flowchart TB
    S1[ステップ1<br>VSA単体で運用成熟<br>1プロジェクト] --> S2
    S2[ステップ2<br>技術軸共用層<br>+ CLIガードレール] --> S3
    S3[ステップ3<br>Bounded Context<br>+ Context軸共用層] --> S4
    S4[ステップ4<br>組織ハーネス<br>RAG・Must lint・監査]

「全部一気に作るほうが早い」という反論もありうる。だがハーネス3層² §4-1 の議論と同じく、漸進アプローチのほうが最終的な投資効率が高い。各ステップで「実際に痛みが出ているか」を確認しながら進めることで、不要な抽象化を避けられる。

§6. 具体例 — Next.js（複数サイト）+ Go API での実装パターン

抽象的な統合提案だけでは、自組織に持ち帰る具体像が掴みにくい。本節では「Next.js で複数サイトを運営し、一部の API を Go で書く」典型的なスタックを前提に、3層の中身と接続点を具体化する。

6-1. 想定するスタック構成

前提:

• monorepo（pnpm workspace + Turborepo）: apps/<site>/ で複数 Next.js サイト、services/<api>/ で複数 Go API サービス
• Next.js: App Router、Server Components、Server Actions を活用
• Go: gRPC または HTTP/JSON API、internal/<context>/features/ で VSA
• 共有パッケージ: packages/ 配下に UI 部品、Context 共有ドメイン、共通 CLI ツール

ディレクトリ構造（例）:

repo/
├── apps/
│   ├── admin/             # 管理画面サイト
│   ├── marketing/         # マーケサイト
│   └── customer/          # 顧客向けサイト
├── services/
│   ├── billing-api/       # Go: 課金API
│   └── notification-api/  # Go: 通知API
├── packages/
│   ├── ui-shared/         # 共通UIコンポーネント
│   ├── domain-auth/       # 認証Context共用ドメイン
│   └── tools-mycorp/      # mycorp-* CLI群
└── harness/
    ├── org/               # 組織ハーネス層
    ├── shared-frontend/   # Next.js共用層（技術軸）
    ├── shared-go/         # Go共用層（技術軸）
    └── shared-auth/       # 認証Context共用層（Context軸）

harness/ を独立ディレクトリにする理由は2つある。第一に、エージェント向けスキル定義と人間向けドキュメントを同居させるため。第二に、共用層が増えたとき（技術軸＋Context軸が並立する§3-2の状態）、それぞれの責任範囲を物理的に分けて視認できるようにするためだ。

6-2. VSAスライスの具体的な切り方

Next.js 側: App Router の Route Group を VSA スライスに対応させる。app/(features)/<feature>/ 配下に1機能のすべて（page、Server Action、データ取得、テスト）を置く。

apps/admin/
└── app/
    ├── (features)/
    │   ├── product-listing/
    │   │   ├── page.tsx              # UI
    │   │   ├── actions.ts            # Server Action
    │   │   ├── query.ts              # データ取得（API呼出）
    │   │   └── product-listing.test.ts
    │   ├── product-editing/
    │   │   ├── page.tsx
    │   │   ├── actions.ts
    │   │   ├── schema.ts             # Zod 検証スキーマ
    │   │   └── product-editing.test.ts
    │   └── inventory-adjustment/
    │       └── ...
    └── api/                          # 必要に応じてAPI Route

Go API 側: internal/<context>/features/<feature>/ で VSA。handler.go、command.go、store.go、テストを同居させる。

services/billing-api/
└── internal/
    ├── billing/                      # Bounded Context: 課金
    │   ├── domain/                   # 最小限のAggregate/VO
    │   ├── acl/                      # 他Contextからの入力翻訳
    │   └── features/
    │       ├── creating_invoice/
    │       │   ├── handler.go
    │       │   ├── command.go
    │       │   └── creating_invoice_test.go
    │       └── cancelling_subscription/
    │           └── ...
    └── shared/                       # 真に横断的なもの

接続点1（VSAスライス＝コンテキスト供給単位）の実装は、エージェント向け規約として CLAUDE.md に書く：「編集タスクは1つの (features)/<feature>/ または features/<feature>/ フォルダ内で完結させる。他スライスに波及するときは Plan モードで明示する」。

6-3. Bounded Context の引き方

複数 Next.js サイトを運営する場合、サイト＝Context にはならない。サイトは UI の単位、Context はドメインの単位だ。

以下はスタック非依存の典型的な分割例だが、本スタックでは Next.js サイト群と Go API サービス群が複数の Context にまたがって走ることになる:

Context	担当ドメイン	関連サイト	関連サービス
認証	ユーザー、セッション、権限	全サイト	auth-api（Go）
コンテンツ	商品、カテゴリ、メディア	admin, customer	content-api（Go）
課金	プラン、請求書、決済	admin, customer	billing-api（Go）
通知	メール、プッシュ、Webhook	全サイト	notification-api（Go）
マーケ	キャンペーン、A/B、解析	marketing	（Next.js Server Action 完結）

ポイント:

• marketing サイトは認証 Context を「使う」が「所有」しない: マーケサイトの (features)/lead-capture/ は認証 Context の ACL を経由して認証ユーザーかを確認する。マーケ Context は「リード」「キャンペーン」を所有し、「ユーザー」は所有しない
• 同じ「ユーザー」概念が認証・課金・マーケで異なる: 認証は「サインインできるか」、課金は「請求対象か」、マーケは「ターゲット属性か」を扱う。それぞれの Context 内でモデルが違う
• マーケ Context のように Go API を持たない Context もある: Next.js Server Action 完結でも Context は成立する。「Context = マイクロサービス」ではない

接続点2（Bounded Context＝共用層並立軸）の実装は、harness/shared-auth/ のような Context 軸共用層を harness/shared-frontend/（技術軸）と並立させる。packages/domain-auth/ には認証 Context の Ubiquitous Language（型、エラー、フロー）を集約し、packages/domain-billing/ には課金 Context のものを集約する。Context 横断の packages/types/ のような「全部の型を集めるパッケージ」は作らない——Context 間で意味が違う型を1パッケージにまとめると、§4 アンチパターン1（共用層がアーキ意見を運ぶ）に直結する。

6-4. CLI ガードレールの具体例

接続点3（CLI ガードレール＝Context境界ハード強制）を、本スタックで具体化する。

例1: スライス雛形生成 CLI

# Next.js のVSAスライスを雛形生成
mycorp-feature new --type=nextjs --site=admin --name=product-listing
# → apps/admin/app/(features)/product-listing/{page.tsx, actions.ts, query.ts, *.test.ts}

# Go のVSAスライスを雛形生成
mycorp-feature new --type=go --context=billing --name=creating_invoice
# → services/billing-api/internal/billing/features/creating_invoice/{handler.go, command.go, *_test.go}

エージェントには「新機能を追加するときは mycorp-feature new を呼ぶ」とスキルで規約化する。これで命名・配置・テストファイル生成が機械的に揃う。

例2: Context 間呼び出しの強制

# Next.js サイトから Go API（別Context）を呼ぶ
mycorp-context call \
  --from=apps/customer \
  --to=billing-api \
  --action=create-invoice \
  --schema=billing.v1.CreateInvoiceRequest
# 内部で：契約スキーマの存在確認、ACL翻訳の存在確認、認証トークン付与

直接 fetch('http://billing-api/...') を呼ぶコードは ESLint カスタムルール（packages/tools-mycorp/lint/）と CI で禁止する。Go 側も internal/<context-A>/ から internal/<context-B>/ への直接 import を go vet カスタムチェックで禁止する。これで Context 境界がコードレベルでハード強制される。

例3: PR 作成のガードレール

mycorp-pr create
# 内部で：
#   - スライス境界外への編集が含まれていないか確認（含まれていれば Plan ドキュメント要求）
#   - CODEOWNERS による承認確認
#   - Context 跨ぎ変更には Context オーナー両方の承認を要求
#   - PII を含む可能性のあるテスト固定値検出

例4: デプロイのガードレール

mycorp-deploy --service=billing-api --env=prod
# 内部で：本番デプロイ前承認、Context オーナー通知、ロールバック手順生成

これらの CLI は packages/tools-mycorp/ に置き、エージェント・人間共に同じインターフェースで使う。実装は AI で雛形生成し、組織規約に合わせて調整する。初版は1〜2日で立つ——Claude Code / Codex に mycorp-feature の雛形生成タスクを投げ、調整を重ねるアプローチが現実的だ。

6-5. 段階的導入の Next.js + Go 版マップ

抽象的な §5 の4ステップを、本スタックで読み替える。

ステップ1（VSA単体）: apps/admin/ 1サイト＋ services/billing-api/ 1サービスから始める。App Router + (features)/ の VSA 構造、Go の internal/billing/features/ 構造を確立。Bounded Context は明示せず（暗黙に1 Context）、CLAUDE.md でスライス境界・命名規約を明示する。

ステップ2（技術軸共用層）: apps/customer/、apps/marketing/ を追加する時期。pnpm workspace で packages/ui-shared/ を立てて Server Component の共通部品を共有。harness/shared-frontend/ に App Router 規約・Server Action 規約・テスト戦略を集約。harness/shared-go/ に Go の handler テンプレート・エラー処理パターンを集約。並行して packages/tools-mycorp/ で mycorp-feature mycorp-pr を立ち上げる。

ステップ3（Bounded Context + Context軸共用層）: 認証・課金・通知が別ドメインだと痛みで気づく時期。services/auth-api/、services/notification-api/ を切り出すか、billing-api 内の internal/<context>/ を増やす。packages/domain-auth/、packages/domain-billing/ を Context Ubiquitous Language の集約場所として立てる。mycorp-context call で Context 間呼び出しを強制する。

ステップ4（組織ハーネス）: 組織 RAG に ADR・障害履歴・設計ドキュメントを Context タグ付きでインジェスト。Must lint として PII 検出、認証バイパスパターン検出、Context 境界違反検出を CI に統合。harness/org/ で監査ログ集約。RAG の応答は「これは認証 Context の文書です」とメタデータを付ける——これでエージェントが Context 間で用語を取り違える事故を減らせる。

flowchart TB
    NS1["ステップ1<br>apps/admin/<br>+ services/billing-api/<br>VSA確立"] --> NS2
    NS2["ステップ2<br>pnpm workspace<br>+ packages/ui-shared<br>+ mycorp-feature/pr"] --> NS3
    NS3["ステップ3<br>services/&lt;ctx&gt;-api/<br>+ packages/domain-&lt;ctx&gt;<br>+ mycorp-context call"] --> NS4
    NS4["ステップ4<br>組織RAG Contextタグ付<br>+ PII/Context違反lint<br>+ harness/org/"]

6-6. このスタックでの注意点

Next.js + Go の組み合わせに固有の落とし穴を整理する。

• Server Component と Server Action の境界: VSA スライス内で Client/Server を混在させると、エージェントが境界を取り違える。use client / use server の位置と意図を CLAUDE.md で明示する。雛形生成時に actions.ts を Server Action 専用、page.tsx を Server Component デフォルトで生成する規約にする
• Route Group の (features) 表記: App Router の Route Group は URL に出ないため、エージェントが構造を見落とすことがある。mycorp-feature new で必ず Route Group 配下に配置する規約を機械強制する
• Go gRPC vs HTTP/JSON: Context 間通信のスキーマ言語を gRPC（proto）か OpenAPI か早期に決める。mycorp-context call の内部実装が変わる。proto なら packages/proto/ を契約スキーマの単一ソースとし、Next.js 側も @bufbuild/connect-web 等で同じスキーマを参照する
• Next.js のキャッシュ無効化: Server Action でデータを変えたら revalidatePath / revalidateTag を呼ぶ規約をスキルに含める。エージェントが忘れがちな箇所で、mycorp-feature new の雛形に「データ変更後の再検証 TODO コメント」を入れておくと事故が減る
• Bounded Context を跨ぐ型共有の誘惑: §6-3 で触れた通り、packages/types/ のような Context 横断型パッケージは作らない。代わりに「Context 間で送受信する DTO」だけを packages/contracts/ または packages/proto/ に置き、Context 内部のドメイン型は packages/domain-<context>/ に閉じ込める
• Server Action の認証チェック忘れ: Server Action は任意の人が叩けるため、認証 Context の ACL を必ず通す。mycorp-feature new の actions.ts 雛形に「requireAuth() 呼び出し」を必須として含めると、エージェントが省略する事故を防げる

§7. 多角的評価と限界――統合特有のメリットとリスク

各記事（VSA × AI / VSA × DDD / ハーネス3層）の単独採用に伴うメリット・デメリットは原典に詳しい。本節では 3つを同時採用したときに初めて立つメリット と、統合採用したからこそ発生するリスク に絞って評価する。VSA単体・DDD単体・ハーネス3層単体のメリット／リスクは、VSA × AI §「VSAの限界」、VSA × DDD §7、ハーネス3層 §5-2 を参照されたい。

統合特有のメリット

統合提案を採用した場合、論理整合性として期待できる効果を整理する（事例での実証はないことを再度強調する）。これらは個別記事の議論からは出てこない、統合したときに初めて立つ効果 だ。

• 設計判断の一貫性: 3層を貫く単一原理（安定／変化）があるため、新しい判断（共用層に何を置くか、Context をどこで切るか、CLI ガードレールを何に適用するか）が同じ軸で評価できる。各記事を個別に運用していると、新しい判断ごとに「どの記事の規範を当てはめるか」で迷う
• 早すぎる抽象化の回避が運用基盤層まで広がる: VSA の警戒（ビジネス抽象の早すぎる共通化）が、ハーネス共用層の設計にも適用される。共用層に「ビジネス判断」が紛れ込む事故を構造的に防げる。個別記事では論じられていない統合効果だ
• Bounded Context の機械強制: 概念整理に留まっていた Bounded Context が、CLI ガードレール（ハーネス3層の実装機構）経由でハード強制される。DDD単体では「規律」「文化」に頼っていた境界維持を、運用基盤レベルで支える。これは DDD × ハーネスの直接接続によって初めて立つ効果
• エージェント判断の一貫性: スライス境界・Context 境界・共用層境界が同じ原理で揃うため、エージェントが「どの規約に従うか」で迷わない。各層がバラバラに設計されていると、AI コーディング時にエージェントが規約間で揺れる

統合特有のリスク

統合提案には、関連分野のリスクが累積する側面と、3層を組み合わせたことで新たに発生するリスク がある。本節は後者に絞る（前者は冒頭で示した個別記事の各セクションを参照）。

リスク1: 統合の認知負荷

3記事を別々に読むより、統合提案を実装するほうがチームへの認知負荷は格段に高い。VSA・DDD・ハーネス3層それぞれの基礎理解が必要で、3層が揃わないと統合の利点が立たない。中規模以下のチームでは「すべての層に等しく投資する」自体が不可能な場合がある。痛みのある層から1段階ずつ整備する §5 の設計はそのためだ。

リスク2: 3層を貫く運用責任の所在

各層に責任者を置いても、「層間の整合性」を見る責任者がいないと統合は崩れる。ハーネス共用層オーナーは「共用スキルを増やすこと」を成果指標にしがちで、VSA / DDD オーナーは「自分の領域でルールを守ること」が指標になりがちだ。統合の判断軸（共用してよいか／分離すべきか）を実際にレビューする横断ロールが必要になる。これは個別記事のいずれにも書かれていない、統合採用時に新たに発生する組織問題だ。

リスク3: 個別最適と統合一貫性のトレードオフ

§4 アンチパターン4 で論じた通り、統合一貫性を絶対視すると個別最適の正当な要望を否定してしまう。逆に個別最適を許しすぎると統合の利点が崩れる。このトレードオフは個別記事には現れない、統合採用時に立ち上がる固有問題だ。逸脱を ADR で明示する運用ルールが必要になる。

リスク4: 直接事例の不在

本提案は VSA × AI³、DDD × マルチエージェント⁵¹⁰¹¹、ハーネス設計² の関連パターンから推測した接続案であり、VSA × DDD × ハーネス3層を組織で運用した直接事例は2026年5月時点で見つけられない。個別記事はそれぞれ実装事例が存在する（特に VSA × DDD は VSA × DDD §1 で複数テンプレートが列挙されている）が、3層統合事例はない。先行採用者は失敗パターンを引き当てる側になることを覚悟する必要がある。

リスク5: プロンプト規約整備の連鎖負債

arXiv 2604.04990¹² が示すように、AI エージェントはプロンプト経由で暗黙的にアーキテクチャ決定をしている。本提案のすべての設計判断（VSAスライス境界、Bounded Context、CLI 規約、RAGコンテキスト供給）は エージェントへのプロンプト・スキル定義・規約文書として明示されなければ機能しない。3層を統合すると、プロンプト規約の整備量も累積する。1層だけでも整備が大変なのに、3層が連動する規約を保守する必要が出る。個別記事を別々に運用するよりも明確に重い負担で、これは統合採用に固有のコストだ。

そして、これら統合特有のリスクは 「AI 開発の組織レベル生産性パラドックス」という背景 の上に乗っている。92.6% の開発者が AI を利用しながら、組織レベルの生産性向上は10%程度に留まるという調査がある¹³。本記事のまとめは「3層を貫く設計判断で組織レベル生産性が動き始める」と論じるが、それは自動的に保証されるものではない。統合提案に投資する前に、自組織の生産性ギャップがどこにあるかを計測するステップが先に来る――これは個別記事それぞれが指摘する留保と同じだが、3層すべてに投資する統合提案ではコストが累積するぶん、この前提確認の重要度はさらに上がる。

採用条件と撤退ライン

採用判断は 「組織規模」ではなく「どの痛みが出ているか」 で決める（§5 ポイント2 で論じた通り、規模軸は誤判定を生む）。組織規模は痛みが出やすいラフな目安にすぎない。

出ているシグナル	推奨スタンス	規模の目安（参考）
知識サイロもドメイン分岐も規制も顕在化していない	本提案は 過剰。VSA 単体で運用、痛みが出てから次へ	〜10人
スキル・規約のコピペが別リポジトリで出始めた	ステップ2まで（VSA + 技術軸共用層 + CLI）。DDD は明示せず	10〜30人
加えて「同じ言葉が違う意味で使われる」が頻発	ステップ3まで（+ Bounded Context + Context軸共用層）。組織ハーネスは最小版	30〜100人
さらに規制対応・全社コンプラが経営課題化	ステップ4まで（フル統合）。プラットフォームチーム専任体制	100人以上

規模は左→右に概ね相関するが、相関であって因果ではない。30人で事業領域3つの組織は3行目、100人で単一ドメインの組織は2行目、というケースは珍しくない。

撤退すべきシグナル:

• 共用層スキルにビジネスロジックが流れ込み始めた → §4 アンチパターン1。共用層スキルを「How に絞る」リファクタリング
• CLI ガードレールが開発速度を体感的に落としている → §4 アンチパターン3。ハード強制する境界を絞る
• 統合一貫性のために現場の正当な個別最適を否定するケースが増えてきた → §4 アンチパターン4。逸脱を ADR で許す運用に転換
• Bounded Context の境界判定で頻繁に揉める → DDD 戦略的設計の基礎理解不足。研修・コーチング先行
• AI エージェントの判断が割れ続ける → プロンプト規約整備の先送り。CLAUDE.md / .cursorrules の整備を優先

限界

• 本記事は提案であり、ケーススタディではない: 3記事の関連パターンから推測した接続案
• 3層を貫く統一原理は1つの整理にすぎない: 別の整理（例えば「責任の局所性」「変更の頻度」など）でも同じ結論に至る可能性がある。本記事の「安定／変化」原理は唯一解ではない
• AI コーディングエージェント側の進化が早い: 1〜2年で「Bounded Context タグ付き RAG」「Context 認識スキル」が公式に組み込まれる可能性が高い。本提案は2026年5月時点での「自前で組む必要がある領域」の整理であり、半年単位で見直す前提
• 政治的・文化的要因は本提案では解決しない: 「中央チームが信頼されていない」「Context 境界の議論が政治で歪む」状態では、技術的整理だけでは動かない

まとめ

VSA × DDD × ハーネス3層は、別々のレイヤーを扱う3つの設計議論だ。だが1人のアーキテクトの机の上では同じ判断軸で動く。本記事は、3記事を1つの統合提案として接続した。

中核メッセージを1行で言うと:

「安定したものを共有し、変化するものを分離する」という原理は、コード構造（VSA）と運用基盤（ハーネス3層）とドメイン設計（DDD）で共通している。3層を貫く一貫した設計判断にしたとき、組織レベルのAI開発生産性が初めて動き始める。

3つの提案を整理する。

提案	内容	統合特有のリスク
原理	VSAの「分けろ」とハーネスの「共通化しろ」は抽象階層が異なるため矛盾しない。両者は「安定／変化」原理の二つの表現	個別最適と統合一貫性のトレードオフ。逸脱の ADR 運用が必要
接続点	VSAスライス＝コンテキスト供給単位／Bounded Context＝共用層並立軸／CLIガードレール＝Context境界ハード強制	3層統合の直接事例不在。先行採用者は失敗パターンを引き当てる
段階的導入	VSA → 技術軸共用層 → Bounded Context → 組織ハーネス の順	層間整合性を見る横断ロール不在で統合が崩れる

採用判断は どの痛みが出ているか で決める。スキル・規約のコピペが出たら共用層、同じ言葉が違う意味で使われ始めたら Bounded Context、規制が経営課題化したら組織ハーネス。組織規模はラフな目安にすぎず、本質はシグナルだ。

「とりあえず3層全部作る」は本記事も最も警戒する失敗パターンだ。

本記事は新しい提案である。直接事例が出てくるまでには時間がかかる。読者の組織で先行的に試す価値があるなら、まず VSA 単体の運用成熟を確認するところから始めるのが穏当だ。VSA が機能している組織は、§5 ステップ2〜4 への移行で本提案の効果が現れる可能性が高い。VSA がまだ機能していない組織は、本記事の統合議論より先に VSA × AI を読むほうが投資効率が高い。

今日試せる1アクション: 自組織の共用層（または共用層の候補）に存在するスキル・テンプレート・規約を列挙し、それぞれに「How（操作手順）」「What（ビジネス判断）」のラベルを付ける。What ラベルが付いたものは Context 層に押し戻す候補だ。共用層が肥大化している組織ほど、What が大量に紛れ込んでいる可能性が高い。30分でその構造が見えてくる。

関連記事

このテーマに関連する他の記事もご覧ください：

• Vertical Slice ArchitectureはなぜAI開発と相性がよいのか — 本記事の基盤となる VSA × AI の議論
• VSAとDDDをAI開発でどう組み合わせるか — VSA × DDD の地図と複数の方向性
• 多段階ハーネスエンジニアリング — 3層モデルとデータ層中心の投資戦略 — 本記事のもう一つの基盤、ハーネス3層モデル
• 組織にコンテキストエンジニアリングを — 個人技から組織能力へ — 組織RAG層の位置づけ
• AIネイティブなエンジニアリングチームの作り方 — チーム規模でAIを活用する際の組織と設計

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

• Harness engineering: leveraging Codex in an agent-first world - OpenAI (2026). 5か月・約100万行・約1,500 PR を手動コード0行で達成した社内事例。本記事の「ハーネス3層」議論の原点。【信頼性: 高】
• Harness engineering for coding agent users - Martin Fowler (2026年4月). outer harnessの概念整理。【信頼性: 高】
• Agent as Bounded Context (Part 1) - Philipp Kostyra, Medium (2025年8月1日). Cognitive Agent / Workspace の2モデル提案。本記事の「Bounded Context = 共用層並立軸」議論と関連。【信頼性: 中】
• Designing Scalable Multi-Agent AI Systems: Leveraging Domain-Driven Design and Event Storming - DZone (2025年6月12日). DDD＋Event Stormingを multi-agent に適用するが、複雑性管理のための境界定義の難しさを指摘。本記事の「採用条件」議論の参考。【信頼性: 中】

1. Vertical Slice Architecture - Jimmy Bogard (2018年4月19日). VSAの原典。「スライス間の結合は最小化、スライス内は最大化」「フィーチャー間でビジネスロジックを共有するな」を提示。【信頼性: 高】 ↩︎ ↩︎²

2. 多段階ハーネスエンジニアリング — 3層モデルとデータ層中心の投資戦略 - 本ブログ前記事 (2026年5月14日). ハーネス3層モデルと自前投資の境界線、CLIガードレールパターンを提示。【信頼性: 自家記事】 ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸ ↩︎⁹ ↩︎¹⁰

3. Vertical Slice ArchitectureはなぜAI開発と相性がよいのか - 本ブログ前記事 (2026年4月26日). 1スライス＝1コンテキストという設計原理とAIコーディングとの親和性を論じる。【信頼性: 自家記事】 ↩︎ ↩︎²

4. Learning to Share: Selective Memory for Efficient Parallel Agentic Systems - arXiv:2602.05965 (2026年2月). 並列エージェント間の選別的メモリ共有メカニズム。「全部共有でも全部分離でもない」効率的な中間解を実証。【信頼性: 中〜高】 ↩︎

5. From Prompt Spaghetti to Bounded Contexts: DDD for Agentic Codebases - Nikita Golovko, Siemens AI Portfolio Architect, AI Coding Summit (2026年2月26日). Bounded Context・契約スキーマ・ACL・Context Map を4原則として提示。【信頼性: 中】 ↩︎ ↩︎²

6. Backend Coding Rules for AI Coding Agents: DDD and Hexagonal Architecture - Bardia Khosravi, Medium (2025年7月12日). AIコーディングエージェント向けDDD/Hexagonal規約。予測可能なパターン提示を目的とする。【信頼性: 中】 ↩︎

7. 9 Platform Engineering Anti-Patterns That Kill Adoption - Jellyfish (2025). 9つのアンチパターン（Rebranding the Operations Team / The Field of Dreams Fallacy / The Magpie Platform / Building the Front End First / The Platform for Everything / Neglecting the Day 2 Reality / The Skill Concentration Trap / Mandated Adoption / Tracking the Wrong Metrics）を整理。【信頼性: 中】 ↩︎

8. Vertical Slice Architecture: Where Does the Shared Logic Live? - Milan Jovanović. VSAでの共有ロジック配置の議論。Rule of Three（3回現れるまで抽象化しない）と「誤った抽象化より重複の方が安い」原則を整理。【信頼性: 中】 ↩︎ ↩︎²

9. VSAとDDDをAI開発でどう組み合わせるか - 本ブログ前記事 (2026年5月13日). VSA × DDD ハイブリッドの方向性と複数の組み合わせ案を整理。【信頼性: 自家記事】 ↩︎ ↩︎²

10. Applying domain-driven design principles to multi-agent AI systems - James Croft, Microsoft Senior Software Engineer (2026年4月8日, 2026年5月4日更新). DDD の Bounded Context・Ubiquitous Language をマルチエージェントAIに適用する個人発信。【信頼性: 中】 ↩︎

11. Transforming Travel: How Domain-Driven Design Unlocks the Power of Agentic Travel AI Systems - AWS Builder Center (2025年9月4日). DDDのBounded Contextをagentic AIに適用し、専門エージェント（航空・ホテル等）の自然境界を定義する事例。【信頼性: 中〜高】 ↩︎

12. Architecture Without Architects: How AI Coding Agents Shape Software Architecture - Phongsakon Mark Konrad et al., arXiv:2604.04990 (2026年4月5日). AIコーディングエージェントがプロンプト経由で暗黙的にアーキテクチャ決定を行うことを実証。同一タスクで141〜827行のコードサイズ変動を報告。【信頼性: 中〜高】 ↩︎

13. 93% of Developers Use AI. Why Is Productivity Only 10%? - ShiftMag (2026). 92.6%の開発者がAIアシスタント利用、組織レベル生産性向上は10%程度に留まる「AI生産性パラドックス」を報じる。【信頼性: 中】 ↩︎