AI coding agent が見落としやすいのは、syntax error よりも「今回の変更で構造が少し歪んだ」ことだ。Helper が一段上の layer を import した。Service が本来の boundary を迂回した。小さな修正のはずが、触る範囲を別 package まで広げた。Build と test は通るかもしれないが、repository の形は変わっている。これを code review だけで追うのは重いし、model に全依存関係を覚えさせるのも現実的ではない。

今日見るのは enola-labs/enola。これは architecture intelligence の tool だ。Local code から facts を抽出して repository graph を作り、変更前後の構造差分を比較する。狙いは、古い問題を全部 current PR に押しつけることではなく、今回の変更で増えた coupling、layer violation、cycle、scope spillover、その他の structural signal を示し、どの policy が build を止めるべきかを明確にすることだ。

GitHub repository API、README、LICENSE、Languages API、Commits API、Tags API、Releases API を 2026-08-27 06:45 Asia/Shanghai 時点で確認すると、enola-labs/enola は 191 stars、15 forks。GitHub の primary language は C で、Languages API には Go、Go Template、C++、Shell も出ている。License は Apache-2.0。Repository created time は 2026-02-10 13:18:28 UTC、latest public push は 2026-08-26 18:15:39 UTC、default branch は main。Latest release は v0.4.8 で、published time は 2026-08-25 09:06:28 UTC。Latest public commit は 5163e43、commit time は 2026-08-26 18:15:36 UTC。内容は repository-scoped fact を、変更が触った file として扱わないようにする修正だ。

プロジェクト概要

項目内容
リポジトリenola-labs/enola
位置づけLocal code structure analysis、architecture regression check、agent/CI feedback
Stars191
Forks15
主要言語C
その他の言語Go、Go Template、C++、Shell
ライセンスApache-2.0
作成日時2026-02-10 13:18:28 UTC
Latest push2026-08-26 18:15:39 UTC
Default branchmain
最新 Releasev0.4.8
キーワードarchitecture regression、code graph、CI gate、MCP、agent workflow

見たいのは「この変更が構造に何をしたか」

Code analysis tool の多くは、大きな map を作る。Dependency graph、complexity hotspot、call relation、file relation。Map そのものは役に立つが、日々の開発では reviewer が知りたいことはもっと狭い。今回の diff が何を壊したのか、何を広げたのか、どの boundary を越えたのかだ。Enola の README はこの点を中心にしている。Before/after を比較し、既存の技術的負債ではなく、今回の change に紐づく結果を出す。

この方向は agent workflow と相性がいい。Agent は編集前に repository graph を読み、対象領域の依存関係を把握できる。編集後には check を走らせ、増えた coupling、layer violation、cycle、hotspot、unused route、messaging coverage などの signal を agent や CI に返せる。Agent が context window の中で全体構造を推測するのではなく、source code から抽出された facts を使う。

もうひとつの大事な点は local execution だ。README では、基本分析に model、embedding、upload、account、license check を使わないと説明されている。Private repository や enterprise codebase では、これは派手な feature より重要になる。Architecture check を pre-commit、agent hook、CI に入れるなら、linter のように repeatable で audit できるほうが扱いやすい。

default で fail しないのは現実的

Enola で面白いのは、default では findings を report するだけで、build を失敗させないところだ。これはかなり実務的な判断だと思う。すべての structural signal が、すべての language や team で同じ意味を持つわけではない。Go の import cycle は compiler が先に止める。Rails や大きな frontend app では、runtime relationship を static graph だけで即アウトにできないこともある。Tool が初日から「これは間違い」と宣言すると、CI から外されやすい。

Enola は policy を project 側に残す。Layer violation だけを fail にすることも、intent、cycle、constraints を gate に入れることもできる。Heuristic な check には confidence floor を指定できる。突然の強制 rule ではなく、少しずつ締められる structural instrument として入れられる。

これは agent にとっても大事だ。Agent に必要なのは、曖昧な「architecture risk が高い」という評価ではなく、具体的な feedback だ。今回の変更でどの edge が増えたのか、どの layer boundary を越えたのか、target directory の外へどれだけ spillover したのか。Fail するかは project policy が決めればいいが、report は修正できる粒度でなければならない。

MCP と hook で開発 loop に入る

README には二つの integration path がある。ひとつは普通の CLI。enola --explain で現在の repository structure を見て、enola baseline pin で変更前の構造を固定し、enola check で変更後と比較する。CI では --fail-on を使って、どの findings が build を止めるかを指定する。

もうひとつは agent 向けだ。enola install --hooks は、すでに存在する agent config に instruction を追加し、hook で session の前後に structure feedback を渡す。さらに MCP 接続も用意されている。Claude Code、Copilot、Cursor、Codex、その他 MCP client は enola を local server として使い、編集前に graph、編集後に verdict を受け取れる。

この能力は派手ではないが、問題にかなり近い。Agent の弱点は file を編集できないことではなく、ある変更が hidden boundary を越えたかどうかを見落とすことだ。多 service repository、layered backend、plugin system、business rule が複数 package に散っている monorepo では、この feedback loop の価値が出やすい。

最近の maintenance signal

Project はまだ大きくないが、maintenance signal は悪くない。GitHub API では latest push が 2026-08-26 18:15:39 UTC、今回の執筆時点から一日以内だ。Latest release v0.4.8 は 2026-08-25 09:06:28 UTC に出ている。最近の commits は repository-scoped fact、reviewer routing、documentation wording の調整に触れており、core model と developer experience がまだ動いていることが分かる。

README も concept だけではない。Read-only trial、baseline/check、CI action、agent hook、MCP config、Rails wrapper、policy example、exit semantics がまとまっている。Architecture analysis tool が graph の demo だけで止まると、日常の workflow には入りにくい。Enola は verdict をどう development loop に戻すかを重視している点がよい。

注意点として、GitHub の primary language は C だが、Languages API では Go もかなり大きい。Repository language badge だけで技術スタックを判断せず、install script、release artifact、docs、source tree を見るほうがよい。

向いている使い方

一つ目は、agent による code change が増えている team だ。Agent は diff を速く作れるが、review pressure は「触ってはいけない boundary を越えていないか」に移る。Enola はその一部を repeatable check にして、reviewer が business semantics に集中しやすくする。

二つ目は monorepo や multi-module backend だ。ある import が自然な依存なのか、layer の逆流なのかは、grep だけでは判断しにくい。Layer intent を書き、変更前後を比較することで、「今回は一時的に迂回しただけ」が長期的な構造崩れになるのを減らせる。

三つ目は、CI gate を段階的に強くしたい project だ。最初は report only で走らせ、false positive、runtime、team reaction を観察する。納得できた rule だけ --fail-on に入れる。いきなり大量の rule を fail にするより、この導入のほうが現実的だ。

Caveats

第一に、project はまだ若い。Repository created time は 2026-02-10、現在 191 stars、release は v0.4.8。Production CI では、まず report-only mode でしばらく走らせ、誤検知、実行時間、team fit を見るべきだ。

第二に、architecture rule は project 側で表現する必要がある。Enola は graph を抽出できるが、layer order、intent、target scope は team が明文化しなければならない。Policy がなければ structure observer に近く、policy があって初めて gate になる。

第三に、static structure check は test、type system、review の代替ではない。新增 dependency、boundary crossing、complexity outlier、impact scope は見えるが、business behavior の正しさは分からない。Agent hook、local check、CI の間に置き、review input の一部にするのがよい。

まとめ

enola-labs/enola の面白さは、architecture concern を「reviewer の勘」から「今回の変更で増えた structural facts」へ寄せるところにある。Local source を parse し、repository graph を作り、before/after を比較し、その verdict を agent、CLI、CI に返す。

万能の quality gate として入れる tool ではないし、初日から全 heuristic を fail にするべきでもない。ただ、agent に書かせる code が増えている team や、monorepo の boundary を人力だけで守るのがつらくなっている team なら、Enola は試す価値がある。補うのは test coverage ではなく、structure feedback loop だ。

プロジェクトアドレス：https://github.com/enola-labs/enola