ループエンジニアリングを支えるのはアーキテクチャ設計｜AIを自走させる前に引く境界

この記事は前回のレポートの続きです。 ・前回：ループエンジニアリングは実際どう使われているか — 海外4事例を「原則」で読み解く：AIに指示を出す人間の役割を「仕組み（ループ）」に置き換える考え方と、海外の実運用4事例 ・今回（本記事）：そのループを自社のコードベースで回すとき、最初に効いてくるのはアプリケーションアーキテクチャの設計だという話

前回のレポートの結論は、ループエンジニアリングの成否はモデルの賢さより「仕組みの設計」で決まる、というものでした。

では、その「仕組み」を自社のコードベースに実際に置こうとすると何が起きるか。ここが今回の本題です。結論を先に書きます。最初に詰まるのはプロンプトでもモデル選定でもなく、アプリケーションアーキテクチャです。 ドメイン駆動設計（DDD）、クリーンアーキテクチャ、モジュラーモノリス、マイクロサービス——これまで「保守性のため」に語られてきた設計論が、ループを回す局面では回るか回らないかを決める前提条件に変わります。

この記事では、まず「なぜループは設計の重要度を押し上げるのか」を整理し、実測データで裏を取り、前回の8原則のうちどれがアーキテクチャに依存するのかを切り分けます。そのうえで、「システムの分け方」と「モジュール内部の組み方」という2つの層に分けて選択肢を比較します。この2層を混ぜると議論が噛み合わなくなるところが、今回いちばん整理したかった点です。最後に、当社が実際にどう組んでいるかも具体的に書きます。

1. ループは、ブレーキを人間から構造へ移す

まず、何が変わったのかをはっきりさせます。

AIに1件ずつ指示して結果を見る使い方では、人間が毎回のゲートに立っています。 変な設計が出てきたら、その場で気づいて止められる。設計の粗さは「人が読んで違和感を持つ」という形で減速されていました。

ループはここを外します。仕組みが作業を見つけ、AIに渡し、検証し、記録し、次へ進む。人間が立つのは関門だけです。前回見た夜間ループのように、朝まで誰も見ていない時間帯が生まれます。

このとき、ブレーキの担い手が「人の目」から「構造と機械的な合否」へ移ります。 ここが設計の重要度が上がる理由の核心です。

「後でリファクタする」という前提が置けなくなる、と言い換えてもいいと思います。ループは待ってくれません。

2. 人が見ている状態でも、構造はすでに崩れている

では実際、AIが書いたコードベースの構造はどうなっているのか。コード分析ツールの GitClear が2026年1月に公開したレポートは、2023年から2026年までの6億2300万件のコード変更を分析しています。

4つとも同じことを言っています。重複が増え、再利用が減り、既存コードに触らなくなった。 つまり「既存の抽象を探して正しい場所に差し込む」代わりに「必要なものをその場に書き足す」方向へ、コードの書かれ方が寄ったわけです。

AIの振る舞いとしては、これは合理的です。目の前のタスクを最短で通すなら、書き足すほうが速い。人間なら3回目のコピーで面倒になって共通化しますが、AIは100回目のコピーも同じコストでこなします。設計の欠落はAIにとって「不便」ではないので、放っておいても埋まりません。

重要なのは、この数字が「人間が毎回レビューしていた状態」で出ていることです。ループはその人間のレビューを関門1箇所に減らします。同じ傾向が、より速く、より広く進むと考えるのが自然でしょう。

セキュリティ側のデータも同じ構図です。Veracode が2026年3月に公開した調査（150以上のモデル×80タスク）では、セキュリティ指示を明示しない場合、AI生成コードの45%が既知の脆弱性を含んでいました。構文の正しさは95%を超えるまで改善したのに、セキュリティは合格率55%のまま1年横ばいです。

内訳がさらに示唆的です。SQLインジェクション（パターンで見つかる種類）は82%通るのに、クロスサイトスクリプティング（データがどこから来てどこへ出るかを追う種類）は15%しか通りません。局所的なパターンは守れるが、データの経路にまたがる判断は落とす。そして経路を決めているのは、まさにアーキテクチャです。

補足として、METR が2025年7月に公開したランダム化比較試験も添えておきます。熟練開発者はAIツールを使うと作業が19%遅くなったのに、本人たちは20%速くなったと感じていました。ツールが変わったのでMETR自身がこの結果を「歴史的なもの」と位置づけていますが、ここで引きたいのは速度の数字ではありません。体感と実測はずれるという事実です。構造の劣化は、劣化のなかでもいちばん体感しにくい種類のものです。人が見ていない時間に進む劣化なら、なおさらです。

参考: GitClear「The Maintainability Gap」 / Veracode Spring 2026 GenAI Code Security / METR

3. ループの8原則のうち、アーキテクチャが決めるもの

前回、うまくいっている海外事例に共通する8つの原則を整理しました。それをもう一度並べ、どれがアーキテクチャ依存なのかを見ます。ここが今回いちばん言いたいところです。

とくに③検証が決定的です。前回「最重要」と書いた⑥評価者と作業者の分離も、突き詰めれば③が成立していなければ意味を持ちません。そして③が成立するかどうかは、ほぼ設計で決まります。

ドメインロジックが外部I/Oに依存していれば、高速に合否を出すテストは書けません。 テストが書けなければ、ループの検証段は「AIが自分の出力を自分で良いと言う」だけの形式になります。それは検証ではありません。依存方向を整理することは、いまや「テストが楽になるから」ではなく「ループの検証段を成立させるため」にやる作業です。

②受け渡しも見た目より重要です。エージェントに「このモジュールの中だけを直して」と渡せるのは、モジュールが実在する場合だけです。境界がなければ、渡せる指示は「このリポジトリを直して」しかありません。

実務報告にもこの形が出ています。約20万行のモノリスにエージェントを向けたところ、複数レイヤーにまたがって自信たっぷりに変更を入れ、触る必要のなかったファイルにまで手を出し、見てもいない箇所を壊したという話です。エージェントの能力の問題というより、変更範囲を閉じ込める構造がなかったという問題です。

そしてもうひとつ、見落としやすい依存があります。コード構造そのものが、ループの中でいちばん長く効き続ける指示だということです。エージェントは指示文だけで書いているわけではなく、周辺ファイル・型定義・ディレクトリ名・既存の実装パターンを読んで「このリポジトリの流儀」を推定します。ループは同じ推定を何百回も繰り返します。CLAUDE.md や AGENTS.md に流儀を書くのは有効ですが、あれは補助です。回数が増えるほど、実体である構造のほうが効いてきます。

4. 「アーキテクチャ」を2つの層に分ける

ここまで「アーキテクチャ設計」と一括りに書いてきましたが、ループ適合度を論じるには2つの層に分ける必要があります。混ぜると話が噛み合いません。

先に結論を書きます。ループの成否を左右するのは下の層です。 上の層は「モジュール境界が実在するか」だけが効き、そこから先（プロセスまで割るか）はループ以前と同じ判断になります。

4-1. システムの分け方：効くのは「境界があるか」だけ

モジュラーモノリスが最適点になる理由は単純で、文脈到達性と閉じ込めを同時に取れるのはここだけだからです。単一リポジトリなのでエージェントはコード全体を辿れる。それでいてモジュール境界があるので変更範囲は閉じ込められる。デプロイを分離する運用コストを払わずに、境界の恩恵だけ受け取れる位置です。

そしてマイクロサービスは、この記事の文脈では少し違う位置づけにあります。 分割すべきタイミングは確かにあります。単一デプロイに収まらない規模、チームを独立にリリースさせたい、障害を物理的に分離したい、コンプライアンス境界を跨がせたくない——こうした理由です。ただし、これらはループエンジニアリング以前から続いてきた議論とまったく同じもので、本記事は新しい判断材料を1つも足しません。 「AIが自走するから分割すべき」も「AIが読み切れないから統合すべき」も、既存の分割判断を覆すほどの重みは持ちません。分割の是非は、いまも規模要件と組織要件で決まります。

ループ側から言えるのは、運用上の注意が1つだけです。すでに分割済みなら、ループの単位を1サービスの内側に閉じる。 契約変更の同期・分散トレース・結果整合性の推論はエージェントがいちばん間違えるところで、人が見ていない時間に跨がせたい領域ではありません。ただしこれも「分割すべきか」ではなく「ループをどう引くか」の話です。

つまり、マイクロサービスはループ適合度で優劣を競う相手ではない、というのが正直なところです。並べて比べる価値があるのは、次の層です。

4-2. モジュール内部の組み方：ここでループ適合度が分かれる

同じモジュラーモノリスでも、モジュールの中身をどう組むかで、エージェントの働き方はかなり変わります。ここが実務でいちばん効く比較です。

クリーンアーキテクチャ：依存方向の価値は上がり、層の枚数の価値は下がる

ループ前提で読むと、クリーンアーキテクチャの価値の内訳が組み替わります。

価値が上がるのは、依存の向きが一方向に決まっていること。 依存が内向き一方向なら「この変更で触ってよい範囲」が機械的に決まり、エージェントが手を広げられる範囲を構造そのもので狭められます。しかもドメイン層が外部I/Oに依存しないので、AIが書いたロジックを高速テストで即判定できる——③検証が成立する条件が、ここで手に入ります。 ループを回したいなら、依存方向の整理は着手順で最上位に来ます。

価値が下がるのは、層・間接・ポートとアダプタの枚数のほうです。 そしてここは、はっきりAIと相性が悪い。

• 1機能の追加で4層に触るので、1タスクあたりの差分が広がります。翌朝レビューする側の負担が増え、⑧歯止め（時間・費用の上限）にも早く当たります
• 1機能を理解するのに辿るファイルが増えるので、エージェントのコンテキストを間接層の把握に食われます。本来ロジックに使ってほしい分が削られます
• ボイラープレート（DTO・マッパー・リポジトリ実装）を、AIは無コストで量産します。 人間なら「これは書きすぎだ」と手が止まるところで止まりません。抽象だけ増えて意味が増えない状態が、GitClear の重複増・接続性低下の傾向と噛み合って悪化します
• 「なぜこの層にこれを置くか」は意図であって、コードには書かれていません。 意図が読めなければエージェントは最短経路を選び、ユースケース層からインフラを直接呼ぶ実装を平気で書きます。機械検査がなければ、層はいずれ貫通されます

まとめると、クリーンアーキテクチャは「依存方向のルール」として採ると効き、「層構成のテンプレート」として敷くと重くなる。 層は薄く、依存規則は機械検査で厳しく——がループ前提の落とし所です。

DDD：戦略は効くが、戦術パターンはAIと噛み合わない

DDDは、戦略と戦術で評価が正反対になります。

戦略（ユビキタス言語・境界づけられたコンテキスト）は、ループでこそ効きます。 ユビキタス言語は、要するにAIに語彙を固定する装置です。「予約」「アポイント」「ブッキング」が社内で混在していれば、エージェントは平気で3つ作ります。1回なら人が直せますが、ループは同じ揺れを何十回も再生産します。用語表を1枚決めて、型名・テーブル名・API名・イベント名へ一貫して反映するだけで、生成物の一貫性は目に見えて上がります。境界づけられたコンテキストは、そのまま②受け渡しの単位になります。

一方、戦術パターン（Entity・値オブジェクト・リポジトリ・ファクトリ・仕様オブジェクト）の全面適用は、AIとの親和性が低い。 理由は2つあります。

ひとつは、戦術DDDの判断材料が暗黙知だからです。「この不変条件はEntityが守るべきか、ドメインサービスへ出すべきか」は、業務知識と設計思想から決まります。コードには結論だけが残り、理由は残りません。エージェントはそれを逆算できないので、ロジックをサービス層へ寄せた貧血モデルを書きます。 しかも一見動き、テストも通ります。人間のレビューでしか気づけない類の劣化——つまりループでは気づけない劣化です。

もうひとつは、型を増やす作業のコストがAIにはゼロだからです。値オブジェクトを100個作れと言えば作ります。判断が要るのは「作らない」側で、そこはAIがいちばん弱い。

したがって、DDDは「AIに書かせるための設計」ではありません。人間が語彙と境界を決めるための道具として使い、戦術パターンの適用は「守るべき不変条件が実在する箇所だけ」と先に線を引く。これが実務的な使い方だと思います。

垂直スライス：ループ適合度がいちばん高い

内部構造の選択肢でループと最も噛み合うのは、**機能単位に縦切りする構成（垂直スライス）**です。1つの機能に必要なもの——入力の受け口、業務ロジック、永続化、テスト——を、1つのディレクトリに同居させます。

効き方が原則にそのまま対応します。②受け渡しの単位・変更差分の範囲・③検証の範囲が、すべて同じ1ディレクトリに一致する。 エージェントに渡すのは「このスライスの中だけ」で済み、差分もそこに収まり、テストもそこで閉じます。辿るファイル数も最小です。

代償は横断的な重複です。似た処理がスライス間に散ります。ここは割り切りが必要で、モジュール境界の内側の重複は、境界を越える結合よりずっと安いと考えます。重複は後から畳めますが、越境した結合は畳めません。ただし許すのは境界の内側だけ。共有したくなったらモジュールの公開インターフェースへ上げる——この線は機械検査で守ります。

当社もモジュールの内部はこの形で組んでいます。具体的には次節に書きます。

Transaction Script：CRUD中心なら、これで足りる

業務ルールが薄く、実質はデータの出し入れが中心の領域なら、薄い手続き型で十分です。層も抽象も少ないほど、エージェントは正確に動きます。

「設計が重要」は「重い設計を敷く」という意味ではありません。 ここを混同すると、単純なCRUDに4層とリポジトリとマッパーを敷いて、ループが読む距離だけを伸ばすことになります。

イベント駆動・CQRS：モジュール内で常用するとループが追えなくなる

最後に、はっきり相性が悪いものを挙げます。モジュールの内側でイベント駆動やCQRSを常用すると、制御フローがコードに現れなくなります。 「誰がこのイベントを受けるか」は実行時に決まり、静的に辿れません。エージェントは影響範囲を読み切れず、検証も複数箇所に跨ります。人が見ていない時間に走らせたい構造ではありません。

使う場所をモジュール間の非同期通信に限定するなら問題ありません。境界を越えるところにだけ置く、が原則です。

なお、研究レベルでも「アーキテクチャを分散させるほどAIエージェントの推論負荷が上がる」という仮説で比較ベンチマーク（ModulithBench）を立ち上げる動きがあります。ただし大規模な実測結果はまだ公開されていません。現時点では仮説として扱うのが正しい距離感です。

参考: ModulithBench の提案（Medium） / 大規模モノリスでのエージェント挙動の報告（Medium）

4-3. 実例：当社はモジュラーモノリス＋垂直スライスで組んでいる

抽象論だけだと使いにくいので、自社の実例を書きます。Grandream では、システムの分け方にモジュラーモノリスを、モジュール内部の組み方に垂直スライスを採用しています。 この記事を生成しているAI記事パイプライン自体が、その実装です。

やっていることは、前節までの内容とほぼ同じです。まず外側の境界から。

• 単一リポジトリのまま、2つの世界に分ける。 対話的に使うスキル層と、自動実行のパイプライン層。両者は別世界として扱い、相互の内部ファイルを import しないと規約で決めています
• 橋渡しは1本に絞る。 スキル層からパイプラインを動かすときは、scripts/ に置いたCLIだけを叩き、契約は「終了コード＋標準出力のJSON1行」のみ。内部実装は覗かせません。これが4-2で書いた公開インターフェースにあたります
• 共有データは設定ファイル経由に限定する。 両方の世界で使う値は config/ のJSONに置き、コードは共有しません
• 各工程はファイル成果物だけで結合する。 直接呼び出し・共有メモリ・グローバル状態は禁止。結果として工程ごとに入出力が独立検証でき、③検証が工程単位で閉じます
• そして、これらを文書だけで終わらせない。 「相互 import が0件であること」を検査するテストと、CLI契約の回帰テストをCIに置いています。文書に書いた規約は、人が見ていない時間には効かないからです

そして内側は、技術レイヤーで横に切らず、機能単位に縦切りしています。

• 1つの役割＝1つのディレクトリ。 記事を書く工程、レビューする工程、画像を作る工程などをそれぞれ独立したディレクトリにし、その中に実装コード・AIへの指示書・テストを同居させています。1工程を直すときエージェントが見る場所は、そのディレクトリだけで足ります
• 設定も機能単位に置き、共通設定へ畳まない。 一見すると設定ファイルが分散して非効率に見えますが、畳むと変更の影響が全機能へ漏れます。階層が名前空間として働き、変更影響がその階層に閉じるほうを取っています
• スキル層も1スキル＝1ディレクトリで自己完結させる。 手順書・スクリプト・参照資料・データをそのスキルの下に置き、他スキルの内部を覗きません
• 横断的な重複は、境界の内側なら許す。 共有したくなった時点でモジュールの公開インターフェースへ上げる。前節で書いた割り切りをそのまま運用しています

こうしておくと、AIに自律実行させたときの差分がモジュールの内側に収まり、翌朝レビューできる粒度で上がってきます。逆に境界と機械検査がなければ、同じループを回しても差分はリポジトリ全体に散ります。同じAI・同じプロンプトでも、結果は構造で決まるというのは、こういうことです。

5. ループを回す前に決める4点

具体的な手順に落とします。すべてループを回し始める前にやることが要点です。順番にも意味があります。

1. 語彙を固定する。 用語表を1枚作り、同義語を潰します。型名・URL・イベント名・DBのカラム名まで反映させます。コストが最も低く、反復回数が増えるほど効きます。

2. モジュール分割と依存方向を先に描く。 図で描いて終わりにせず、機械検査に落とします（dependency-cruiser / ArchUnit / import 制約）。「動いてから直す」は選択肢に入れないでください。GitClear の「移動されたコード3.8%」が示しているのは、後で直すという計画は実行されないということです。なお決めるのは境界と依存の向きだけで、層を厚く積む必要はありません。内部は4-2で書いたとおり、機能単位に縦切りして薄く保つほうがループは回ります。

3. モジュール間の公開インターフェースを決める。 内部実装への直参照を lint で禁止します。エージェントは最短経路を選ぶので、禁止が機械化されていない境界は必ず貫通されます。ここが⑥評価者と作業者の分離の土台にもなります——検証側が実装詳細を覗かずに合否を出せる面が、公開インターフェースだからです。

4. 生成禁止域を宣言する。 認可・課金・DBマイグレーション・個人情報の出力経路。ここは⑦人間の関門を必ず置く領域として、構造上わかる場所に切り出します。Veracode の「XSSは15%しか通らない」が示すとおり、データの流れをまたぐ判断はモデルが最も落とす領域です。

そして4点すべてに共通する原則がひとつ。規約はCIに置く。 md に書いた規約は守られない前提で設計します。逆に合否がCIで出るなら、AI自身がその結果を読んで直せます。機械化された規約は、そのままループの検証段（③）になります。 ここが、設計とループが一本につながる場所です。

6. よくあるアンチパターン

おわりに

前回、ループエンジニアリングの成否はモデルの賢さより仕組みの設計で決まると書きました。今回はその一段下、「仕組みが乗る土台」の話です。

ループの各段——作業を渡す、独立して検証する、作る側と検証する側を分ける、危険な判断を人間に上げる——は、どれもコードベースに境界があることを前提にしています。境界がなければ、渡す単位も、合否を出す単位も、人間に上げる線も引けません。アーキテクチャ設計は、ループを回すための準備作業そのものです。

そのうえで、この記事で分けた2層の結論はこうです。システムの分け方は「モジュール境界を作る」までで十分——マイクロサービスまで割るかどうかは、ループ以前と同じ規模要件・組織要件で決めればよく、自動化の都合で判断を変える必要はありません。差が出るのはモジュール内部の組み方で、ここは層を積むより機能単位に縦切りして薄く保つほうがループは回ります。DDDとクリーンアーキテクチャからは、語彙・境界・依存方向という「機械検査できる部分」だけを持ち出す。層と型の枚数は、AI相手にはむしろ負債になります。

当社の答えも、この2層で言えば**「外はモジュラーモノリス、内は垂直スライス」**です。

いま1つだけ始めるなら、これです。モジュラーモノリスの境界を切り、依存方向の検査をCIに入れ、用語表を1枚作る。 順番はこの通りで、どれも今日から着手できます。そこまで済んでいれば、ループを回す準備はほぼ整っています。

本記事の数値は、GitClear「The Maintainability Gap」（2026年1月、2023〜2026年の6億2300万件のコード変更を分析）、Veracode「Spring 2026 GenAI Code Security Update」（2026年3月24日、150以上のLLM×80タスク）、METR のランダム化比較試験（2025年7月、経験豊富なOSS開発者16名・246タスク／METR自身が現行ツールを反映しない歴史的結果と位置づけ）をもとにしています。ループの8原則は前回のレポートで整理したものです。モジュラーモノリスとマイクロサービスのAIエージェント適合度の比較（ModulithBench）は提案・検証中の段階であり、大規模な実測結果は本記事執筆時点で公開されていません。ツールとモデルの仕様は変化し続けるため、数値は各報告時点の値として扱ってください。