Coding Agent を本格的に使い始めて4ヶ月ほど経った。CLAUDE.md やスキル定義、TDD、SDD……色々なテクニックが語られているけど、結局のところ 既存のコードベースが最大のコンテキスト だと思っている。何を作るかはさておき、「どう作るか」に関してはまさにそう。

「いやいや、ルールファイルやプロンプトの方が直接的に効くでしょ」と思うかもしれない。確かにルールはまあまあ書いたし、既存のプロジェクトではそれなりに機能する。ただ、同じルールを新しいプロジェクトに持っていくと全然ダメだった。Agent はまず最初にコードベースを検索するので、そこから受ける影響がルールの比じゃないくらいデカい。コードベースが空っぽ、あるいは質が低ければ、いくらルールを整備してもゴミが出てくる。

コードベースの質 = 生成コードの質

ここから導かれるのは単純な話で、コードベースを良い状態に保てば、新たに生成されるコードも良い状態になっていくということ。Agent が既存コードを参考にして書くのだから、参考元の質がそのまま出力に反映される。

なぜ既存コードに似た出力が出てくるのか。これは妄想だけど、チャット LLM が人間に同意しがちなのと同じ原理が働いていると思っている。RLHF 的な学習で「人間が承認するコード」が強化されるなら、既存コードベースのスタイルに寄せた方が変更承認率が上がる。つまり Agent にとって既存コードに合わせるのは、品質判断ではなく承認最適化の結果なんじゃないかと。だからこそ、参考にされるコードベース自体の質が重要になる。

では「良い状態」をどう維持するか。Agent との協業を前提にするなら、DDD がめちゃくちゃ合っていると感じている。

なぜ DDD が効くのか

ここで言う DDD は、とにかく型定義するだけの「なんちゃって DDD」ではなく、Aggregate でトランザクション境界を定める方の DDD のこと。

Aggregate を定めると、自然とドメインロジックがその中に閉じ込められる。結果としてコードベース全体の凝集度が上がる。小さいコンテキストの中に莫大なドメインロジックが凝縮される上に、レイヤードアーキテクチャ的にコア中のコア部分なので、ここを神聖視させることで他の処理を追従させる上下関係が生まれる。

レビューも Aggregate さえ合っていれば、他は割とどうでもよくなる。Aggregate がドメインの不変条件を守っている以上、外側のレイヤーは機械的な変換にすぎないので、そもそも間違えようがない。レビューコストも大幅に下がる。

Agent の行動を制約する

これは単に「コードベースを良い状態にする」というだけの話ではない。もう少し正確に言うと、Agent に変なところに手を出させない という効果の方が大きい。

Aggregate が「ここがドメインロジックの置き場所だ」と明示していれば、Agent はそこに倣ってロジックを書く。逆にこの境界が曖昧だと、HTTP コントローラーの末端で「ここに実装できるから実装しました！」みたいなコードが平気で出てくる。Aggregate の存在が、Agent の行動範囲を自然に制約してくれる。

完全ではないけれど、何もないよりは遥かにマシ。結果的に凝集度が高いまま保たれる。

単一責任の徹底

もう一つ効果を感じているのが、単一責任の徹底。

Agent がコードを読む時にあちこち読まなくて済むし、どこに追加すべきかも明確になる。結果的に Agent が参照するコンテキストが減り、限られたコンテキストウィンドウの中でノイズが減る分だけ本質的な情報の密度が上がるので、出力の品質も上がる。責務が増えてきたなと思ったらすぐに分割する——これを愚直にやるだけで Agent の出力はかなり変わる。

まとめ

• Coding Agent にとって最大のコンテキストはコードベースそのもの。ルールやプロンプトの影響はそれに比べると小さい
• コードベースの質が生成コードの質に直結する。良いコードが良いコードを生む
• DDD（Aggregate によるトランザクション境界の設定）はコードベースの凝集度を高め、Agent の行動範囲を自然に制約する
• 単一責任の徹底は Agent が参照するコンテキストを減らし、出力品質を上げる
• 要するに、Agent 時代だからこそコードベースそのものに投資するのが最もリターンが大きい