境界づけられたコンテキスト

弊社では、業務の意味や変更理由が異なる部分に境界を設け、関連するデータモデルとユースケース（一つの業務上の目的を完了する処理）を、その内側で理解できる構造にします。人とAIが一つの変更に集中できるよう、判断に必要な情報が一緒に収まる範囲まで小さく保ちます。

境界づけられたコンテキスト（Bounded Context）は、同じ言葉とモデルが一貫した意味を持つ範囲です。DDD（業務の知識を中心に設計する考え方）では、モデルをどこに適用し、どこから別のモデルとして扱うかを明示します（Eric Evans: Domain-Driven Design Reference、Bounded Context）。ここでいうモデルは、業務の概念をコードやデータで表したものです。

AIと開発するうえでの理由

データモデルやユースケースが複雑に絡み合うと、一つの修正を判断するために、別の業務の仕様、型、呼び出し元、テストまで追う必要が出てきます。読み込む情報が増えれば、AIのコンテキストウィンドウ（一度の推論で扱える情報量の上限。Anthropicの説明）も、その確認に使われます。

Chromaの2025年の検証では、18のモデルを対象に、入力が長くなると情報検索などの課題で性能が低下する傾向が報告されています。ただし、これは現在使っているモデルの開発品質や、Bounded Contextを導入した効果を直接測った結果ではありません。弊社では、必要な情報を絞り込める構造を選ぶ根拠として扱い、分割後の効果は実際の変更で確かめます。

目指すのは、対象の業務ルール、実装、検証、外との契約を読めば、変更の判断ができる状態です。契約が変わるときは利用側まで確認します。必要な情報を省いて読んだ量だけを減らすと、影響の見落としが残ります。

言葉と変更理由から境界を見つける

境界の候補は、ディレクトリの大きさより、業務で使う言葉と変更の理由から探します。

• 同じ名前のデータでも、業務によって必要な項目、状態、守るルールが違う
• 一方の業務の変更が、他方では必要のない型や条件分岐を増やしている
• 一つの業務の仕様とテストを、他の業務の内部まで読まずに説明できる
• 外へ渡す情報と操作を明示すれば、内部の作り方を独立して変えられる

たとえば、販売で扱う「顧客」には商談の進み具合が必要で、請求で扱う「顧客」には請求先や支払条件が必要になる、という分け方があります。同じ相手を指すIDで関連づけても、それぞれのモデルが持つ意味は異なります。この場合、両方の都合を一つの巨大な顧客型へ詰め込まず、必要な情報を受け渡す契約を決めます。

一つのコンテキストには、複数のモデルやユースケースが入ります。画面ごと、テーブルごと、AIへの依頼ごとに機械的に分割しません。常に同時に判断しなければならないルールや、同時に成功・失敗すべき更新があるなら、そのまとまりを保てる境界を先に検討します。

データの所有と受け渡しを決める

境界を作るときは、次の事項を実装と仕様書から追えるようにします。

• 所有するもの: 業務用語、モデル、更新を担当するユースケース、守るルール
• 外へ提供するもの: 呼び出してよい操作、渡すIDとデータ、成功・失敗の意味、利用側
• 接続の条件: 誰が操作できるか、いつのデータか、失敗や再試行をどう扱うか、どこまで一緒に確定するか

他のコンテキストのデータを更新するときは、その所有側が提供する操作を通します。内部モデルや保存処理を直接参照して書き換える構造では、フォルダを分けても、判断のために読む範囲は広いままです。相手側の形式と意味が異なる場合は、Adapterで自分たちのモデルへ変換します。

横断検索や集計のための読み取りは、アーキテクチャの方針に沿って専用クエリにできます。その場合も、参照するデータ、認可、変更時に確認する利用側を明示します。読み取りの都合で、複数の業務が同じデータの更新責任を持つ構造へ広げません。

まずは同じリポジトリ、同じアプリの中で境界を作れます。共有するデータベースを使う場合も、更新責任と参照のルールを決めます。別のサービスやデータベースへ分ける判断は、運用、障害、整合性の条件が必要になった時点で行います。

AIが読む入口を境界に合わせる

ルートのCLAUDE.mdには、製品全体の前提と、各コンテキストの目的・担当パス・仕様書への入口を残します。詳細な業務ルール、モデル、ユースケース、関連テストは、そのコンテキストから辿れる場所にまとめます。毎回すべてを渡さず、必要な情報へ段階的に進める配置にします（Anthropic: Use progressive disclosure）。

作業を始めるときは、対象の業務とユースケースを特定し、その実装、テスト、外との契約から確認します。境界を越える変更が見つかったら、実際の呼び出し元やデータの利用側へ調査を広げます。対象外の業務を調べる必要が生じた理由も、変更の説明に残します。

AIのコンテキストは、ある時点で読み込んだ情報の集合です。Bounded Contextは、製品のモデルに引く境界です。この二つは対応づけて運用しますが、一回の会話に収まるトークン数で業務の境界を決めません。指示ファイルの読み込み条件はClaude Codeの運用知見、ファイルを近くに置く判断はコロケーションで扱います。

請求のユースケースとデータモデルを起点に、境界づけられたコンテキストの候補を整理して。
この範囲だけで判断できる仕様と、他の業務へ確認が必要な契約を分けて説明して。
必ず一緒に守るルール、データの更新責任、既存の呼び出し元も確認して。まず境界の案と根拠を示して

小さくした効果を確かめる

弊社では、分割後の実際の変更で、読み込んだ仕様や実装の範囲、境界を越えた修正、検証漏れによる手戻りを確認します。比較するときは、変更の難しさや使うモデルなどの条件も残します。AIが読んだファイル数やトークン数だけを品質の証拠にしません。

内部の変更なら、そのコンテキストのルールとユースケースを検証します。受け渡す契約を変えるなら、提供側と利用側の両方で互換性と認可を確認し、境界をまたぐ実際の操作も通します。検証の選び方はテスト戦略に従います。

単純なCRUD（作成・取得・更新・削除）で意味も変更理由も同じなら、境界を増やす必要はありません。小さく分けた結果、毎回複数のコンテキストを同時に直す、同じルールを重複して保つ、連携の調整が作業の中心になる、といった状態なら分け方を見直します。