AI開発における「境界づけられたコンテキスト」の引き直し方

この記事でわかること:

• 従来のDDDコンテキスト境界の課題
• AI時代における境界の引き直し方
• 具体的なリファクタリング手順

結論: 境界はAIの「読みやすさ」で引き直す

ドメイン駆動設計（DDD）の「境界づけられたコンテキスト（Bounded Context）」は、業務領域の言語の違いに着目して引かれてきました。しかし2026年、AIエージェント時代には「AIが1回の読み込みで把握できる範囲」を境界の基準にする動きが広がっています。

従来のDDD境界の課題

従来のDDDでは、業務領域ごと（受注／在庫／請求／配送）に境界を引いてきました。これは人間のチーム編成には合っていましたが、AI時代には2つの問題があります。

1. 境界が細かすぎる: 1機能で複数コンテキストにまたがり、AIが全体を読めない
2. 境界が曖昧: 「ユーザー」が複数コンテキストに分散し、AIがどれを参照すべきか迷う

AI時代の境界の引き方

基準1: 1コンテキスト=1リポジトリ or 1ディレクトリ

AIが1コンテキストを丸ごと読み込めるサイズに調整します。経験的には1コンテキスト1〜3万行が上限です。これを超えるとAIの理解度が顕著に落ちます。

基準2: コンテキスト内で型・スキーマが完結

コンテキストAとBで「User」型が別定義になっていてもよいですが、その変換は明示的にUserAdapterを介します。AIが境界越えのバグを検知しやすくなります。

基準3: コンテキスト間通信を明示

同期API・非同期イベント・共有DBのどれを使うかをコンテキストごとに決めます。曖昧だとAIが「直接DBを触る」「同期APIで呼ぶ」など、勝手な実装をします。

境界の引き直し手順

ステップ1: 既存コードのコンテキスト棚卸し

AIに「このリポジトリのコンテキストを抽出して」と指示し、ドメイン用語を列挙させます。重複や曖昧さが見えてきます。

ステップ2: AIの読解単位を計測

各コンテキストの行数・ファイル数を計測し、AIが1回で読めるサイズに収まっているか確認します。超えていれば分割、過小なら統合を検討します。

ステップ3: 用語の統一

「ユーザー／顧客／メンバー」のように同じ概念が違う名前で散在していないか調査し、コンテキストごとに用語を統一します。ユビキタス言語はAI時代にもなお有効です。

ステップ4: 境界の物理的表現

境界をディレクトリ構造・モジュール境界・lintルールに反映します。境界違反を検知する仕組みがないと、境界はすぐに崩れます。

具体例: 受注システムの引き直し

あるECチームでは、当初「注文／在庫／配送／請求」の4コンテキストでしたが、機能追加のたびに4箇所変更が必要で、AIが全体を読めていませんでした。

引き直した結果、「注文ライフサイクル」「請求」の2コンテキストに統合しました。注文・在庫・配送は密結合のため、分けるメリットより読みやすさのデメリットが大きかったためです。

結果、AIエージェントによる機能追加の一発通過率が42%から74%に向上しました。

過剰統合の警告

「全部1コンテキストにすればAIが読みやすい」と考えるのは間違いです。1コンテキストが10万行を超えると、AIのコンテキスト窓を圧迫し、応答品質が落ちます。適度な分割が重要です。

境界をAIに監視させる

2026年は、境界違反の検知自体をAIに任せるチームが増えています。PRごとに「このPRはコンテキスト境界を越えていないか」をAIにチェックさせ、越境があれば理由をADRに残させる、という運用です。これによって境界の侵食を半自動で防げます。

まとめ

AI時代のコンテキスト境界は、業務領域だけでなく「AIの読解単位」を基準に引き直す必要があります。1コンテキスト1〜3万行、型は内部完結、境界越えは明示—この3原則で再設計してみてください。2026年のドメイン設計は、AIとの協働を前提に進化しています。