Module BoundaryはAI Coding AgentのContext Boundaryとしても機能しうる

Module Boundaryはdependency governanceだけでなく、AI coding agentがrepositoryを探索するときの Context Boundary としても機能する可能性がある。

Repository-level codingでは「modelがコードを書けるか」だけでなく、「どのfile・symbol・dependencyを読むべきか」を特定するlocalizationが重要になる。RepoCoderはrepository内に散らばる情報をretrieverで取得し、generation結果を使って再retrievalする反復方式でin-file baselineを10%以上改善した。AgentlessもSWE-bench系の修正をlocalization → repair → patch validationという明示的な3段階へ分け、複雑なagent loopなしでも強いbaselineを示した。

ここからArchitecture側へ逆向きの問いを立てられる。ModuleがPublic API、Internal、Allowed Dependenciesを明示していれば、agentはまず「どのModuleがこのCapabilityをownerするか」を特定し、そのModule内部へretrieval範囲を狭められる。必要なcross-module dependencyもPublic APIから辿れる。

Issue / Task
   ↓ module localization
Module Catalog
   ↓ slice/symbol localization
Relevant Context
   ↓
Edit + Test

これは「Module化すればLLM性能が必ず上がる」という実証済み結論ではない。RepoCoderやAgentlessは特定のModule Architectureを評価した研究ではない。ここでの主張は、localizationが主要コストなら、Architecture metadataをretrieval priorとして使えるのではないかという設計仮説である。

2026年のICLR論文でも、repository memoryとしてkey moduleのfunctionality summaryやcommit historyを利用し、localization改善を報告している。Module summaryやdependency graphを機械可読に保つ Application CatalogはArchitectureをAIとToolが読めるMachine-readable Dataにする は、この方向と接続しやすい。

反対に、Module境界が形式的すぎて実際のchange setが頻繁に境界を跨ぐなら、agentは誤ったpriorに縛られる。Context Boundaryは硬いsandboxではなく、探索の初期範囲として使う方がよい。

出典

• RepoCoder: Repository-Level Code Completion Through Iterative Retrieval and Generation
• Agentless: Demystifying LLM-based Software Engineering Agents
• ICLR 2026: Improving Code Localization with Repository Memory
• Spring Modulith: Fundamentals