概要
https://zenn.dev/hideyuki_toyama/articles/horizontal-guard-rails
詳細内容
## 「横のガードレール」でAIにアーキテクチャを教えるのをやめた話
https://zenn.dev/hideyuki_toyama/articles/horizontal-guard-rails
AIがアーキテクチャを破壊する問題を、ESLintとカスタムスクリプトによる「横のガードレール」の自動検証で解決し、AIが自律的に仕様を遵守する環境を構築する。
**Content Type**: 🛠️ Technical Reference
**Language**: ja
**Scores**: Signal:5/5 | Depth:5/5 | Unique:5/5 | Practical:5/5 | Anti-Hype:5/5
**Main Journal**: 68/100 | **Annex Potential**: 68/100 | **Overall**: 100/100
**Topics**: [[AI駆動開発, クリーンアーキテクチャ, カスタムガードレール, TypeScript型解析, 自律型AIエージェント]]
AI（Claude CodeやCodex）を使用した開発において、当初は指示通りの構成（クリーンアーキテクチャ等）で生成されても、開発が進むにつれレイヤー境界が侵食されアーキテクチャが崩壊していく問題は多くの現場で共通の悩みだ。著者は、この問題に対し「AIにアーキテクチャを教え続ける」アプローチを捨て、実装品質を静的に強制する「横のガードレール」を構築することで解決を図っている。
本記事の核心は、ESLintだけでは不可能な高度な制約の自動化にある。例えば、OpenAPI仕様（YAML）と実際の実装ルートが一致しているかの照合や、リポジトリの戻り値として`Result`型を強制し、業務エラーを型安全に扱わせる仕組みなどが挙げられる。これらはTypeScriptのAST（抽象構文木）解析などを活用したカスタムスクリプトとして実装され、`prepush`時に実行される。
著者が強調するのは、ガードレールが「AIを教育するSSOT（信頼できる唯一の情報源）」として機能する点だ。各検査には`@what` / `@why` / `@failure`というAI向けのメタデータが付与されており、エラー発生時にAIが自ら理由を理解し、修正案を導き出せるよう設計されている。これにより、セッションごとにアーキテクチャを説明する手間が省け、AIは「REDが出たからOpenAPI仕様を確認して修正する」といった自律的な行動をとるようになる。
また、ガードレールを「立法（定義）」、「行政（実行）」、「司法（CI）」という三権分立のメタファーで整理するディレクトリ構成も、AIネイティブな開発組織における責務の明確化として非常に示唆に富む。単なるツール紹介に留まらず、AIが生成するコードの品質を「人間によるレビュー」から「システムによる強制」へとシフトさせる、大規模AI駆動開発のプラクティスとして極めて実用的な知見である。