Agent Hub：自律型 AI エージェントのためのアーキテクチャガードレール - Archyl Blog

AI コーディングエージェントはコードを高速に書きます。しかしガードレールがなければ、アーキテクチャの逸脱もまた高速です。本日、Agent Hub をリリースします。これは Archyl の新セクションで、適合性ルールの定義、96 個のプリビルトガードレールカタログの閲覧、そして AI エージェントがコードを1行書く前に必要なアーキテクチャコンテキストの提供を可能にします。

Agent Hub：自律型 AI エージェントのためのアーキテクチャガードレール

ソフトウェアの書かれ方に、根本的な変化が起きています。

半年前、エンジニアは新しいサービスの構築に2日をかけていました。ADR を確認し、どのデータベースを使うべきか同僚に相談し、数か月かけて身に付けた命名規則に従い、アーキテクチャを理解しているからこそアーキテクチャに適合するコードをプッシュしていました。

今日、AI エージェントが20分でそれをやります。コードはコンパイルされ、テストも通ります。しかしエージェントはチームが PostgreSQL に統一しているにもかかわらず MongoDB を使いました。構造化ログを使う代わりに fmt.Println をあちこちに散りばめました。3スプリントかけて構築した service 層をバイパスして、HTTP handler から直接データベースクエリを実行しました。

エージェントは速い。しかし、自分が何を知らないかを知りません。

ガバナンスなき速度の本当のコスト

コードの生産速度が事実上無限になる時代に突入しています。Claude Code、Cursor、Copilot Workspace、Devin ——これらのツールは数分でサービス全体を生成できます。週次リリースだったチームが日次リリースに移行しています。ボトルネックは「どれだけ速くコードを書けるか」から「アーキテクチャエントロピーがどれだけ速くシステムを破壊するか」に移りました。

5つの AI エージェントが同時に同じコードベースで作業するとどうなるか考えてみてください：

  • エージェント A が Express パターンで新しい REST エンドポイントを追加。エージェント B が Fiber パターンで別のエンドポイントを追加。同じサービスに2つの API フレームワークが共存することになります。
  • エージェント C がデータベースを直接クエリする支払いモジュールを作成。エージェント D が repository 層を経由する注文モジュールを作成。2つのデータアクセスパターンが生まれます。
  • エージェント E が、テックレーダーで6か月前に非推奨とされたライブラリを採用。完璧に動作しますが、時限爆弾でもあります。

これらはどれもバグではありません。すべて CI を通過します。それぞれ単独では問題なく動作します。しかし合わさると、コードベースを互いに矛盾するパターンの寄せ集めへと静かに変貌させ、解きほぐすのに数か月かかることになります。

これが Agent Hub で解決しようとしている問題です。

アーキテクチャガードレール：アーキテクチャのための Linter

適合性ルールは決定論的なチェックです——AI は関与しません——アーキテクチャ上の意思決定に対してコード変更を検証します。アーキテクチャ版の ESLint と考えてください：構文ではなく、構造を見ます。

7種類のルールタイプが、数百のチームで観察されたガバナンスニーズをカバーします：

Required Pattern —— 最もシンプルで最も強力なルール。コード内に存在しなければならない、または存在してはならないパターンを定義します。Go での fmt.Println、TypeScript での console.log、あらゆる場所での eval() を禁止。すべてのシェルスクリプトで set -euo pipefail を必須に。SQL クエリでの SELECT * を禁止。

Naming Convention —— ファイル、型、関数にわたって命名ルールを強制します。Go ファイルは snake_case でなければならない。React コンポーネントは PascalCase でなければならない。Python モジュールは PEP 8 に従わなければならない。エージェントがコードを生成する際、エージェント自身のデフォルトではなく、チームの規則に従います。

Technology Constraint —— コンテナごとに技術スタックをロックダウンします。バックエンドは Go のみ。フロントエンドは JavaScript ではなく TypeScript。lodash 禁止（ネイティブ JS を使用）。moment.js 禁止（date-fns を使用）。チームが既に否決した依存関係をエージェントが誤って導入することはできません。

Layer Boundary —— ここが真価を発揮する部分です。アーキテクチャの層と、どの層がどの層からインポートできるかを定義します。Domain は adapter からインポートできない。Service は domain からのみ。Handler は service を経由し、repository に直接アクセスしてはならない。Clean Architecture、Hexagonal Architecture、DDD ——コードが誰に（または何に）よって書かれたかに関係なく、すべての変更で自動的に強制されます。

Contract Compliance —— コードのエンドポイントが API 契約に適合しているか検証します。Archyl に OpenAPI 仕様がある場合、適合性エンジンがハンドラーが実際にそれを実装しているかチェックします。存在しないエンドポイントも、欠落したルートもありません。

Dependency Rule —— コード内のすべての import は、C4 model 内で対応する関係を持つ必要があります。Service A が突然 Service B を呼び出し始めたが、アーキテクチャに「uses」関係がない場合、ルールがそれを検出します。アーキテクチャの逸脱が即座に可視化されます。

Event Channel Compliance —— システムが Kafka、NATS、またはその他のメッセージブローカーを使用している場合、このルールはコード内のプロデューサーとコンシューマーがアーキテクチャで宣言されたイベントチャネルと一致するか検証します。無断の topic も、未宣言のコンシューマーもありません。

96 ルール、設定不要

正規表現パターンを書くのは退屈な作業です。そこで 21 の技術をカバーする 96 のプリビルトルールのカタログを構築しました。ワンクリックですぐに使えます。

カタログはカテゴリ別に整理されています：

Security（11 ルール）—— ハードコードされたパスワード、API キー、シークレットの禁止。eval() 禁止。SQL 文字列連結禁止。TLS 検証の無効化禁止。CORS ワイルドカードオリジン禁止。ハッシュに MD5 や SHA1 を使用禁止。これらは提案ではありません——エージェントの時代において、これらは譲れない条件です。AI エージェントは、誰にも止められなければ、設定ファイルにデータベースのパスワードを喜んでハードコードします。

Infrastructure（22 ルール）—— Dockerfile での :latest タグ禁止。Kubernetes マニフェストでのリソース制限必須。特権コンテナ禁止。hostNetwork 禁止。ヘルスチェック必須。GitHub Actions のバージョンを commit SHA に固定。Terraform でのハードコードされた認証情報禁止。ワイルドカード IAM ポリシー禁止。エージェントが Infrastructure-as-Code を生成する際、これらのルールが出力をデモレベルではなく本番レベルにします。

Code Quality（10 言語にわたる 18 ルール）—— Go：panic() 禁止、init() 禁止、グローバルミュータブル状態禁止。TypeScript：any 型禁止、var 宣言禁止。Python：裸の except: 禁止、ミュータブルなデフォルト引数禁止、import * 禁止。Java：System.out.println 禁止、空の catch ブロック禁止。Rust：unwrap() 禁止、unsafe 禁止。各ルールは、AI エージェントがコンテキストなしに一貫してこれらの間違いを犯すことから生まれています。

Architecture（5 ルール）—— Clean Architecture、Hexagonal Architecture、DDD レイヤード、MVC 分離、handler-service-repository の強制。これらは最もコストの高い種類の逸脱——アーキテクチャが誰も設計していないものへとゆっくり変異していく逸脱——を防ぐ構造的ガードレールです。

Testing（3 ルール）—— スキップされたテストのコミット禁止。テストスイートに .only() を残すことの禁止。本番コードでの TODO/FIXME 禁止。AI エージェントが「動く」ことを優先して「準備完了」を軽視したときに生成される雑なコミットを防ぐ小さなルールです。

エージェントコンテキスト：1回の呼び出しで完全な知識

ルールはエージェントに何をしてはいけないかを伝えます。コンテキストはエージェントに何をすべきかを伝えます。

get_agent_context MCP ツールは、接続されたあらゆるエージェントに1回の呼び出しで完全なアーキテクチャブリーフィングを提供します：

  • C4 Model —— プロジェクト内のすべてのシステム、コンテナ、コンポーネント、および関係
  • Architecture Decision Records —— 有効な ADR とその根拠・決定内容
  • Technology Stack —— 組織全体で使用されている技術
  • Active Guardrails —— すべての適合性ルール。エージェントがコードを書く前に境界を把握できます
  • API Contracts —— API サーフェスを定義する OpenAPI、gRPC、GraphQL 仕様
  • Event Channels —— Kafka topic、NATS subject、メッセージスキーマ

このツールは markdown バージョンも生成します——リポジトリにコミットできる CLAUDE.md ファイルです。それを読んだエージェントは、Archyl の MCP サーバーに接続することなく、完璧なアーキテクチャ知識を持って作業を開始できます。

これが、推測するエージェントと知っているエージェントの違いです。動くコードと、あるべき場所に収まるコードの違いです。

なぜ今これが重要なのか

AI コーディングの世界は急速に動いています。半年以内に、ほとんどのプロフェッショナルな開発は何らかの形で AI エージェントを伴うようになるでしょう。1年以内に、マルチエージェントワークフローが一般的になります——異なるエージェントが同じシステムの異なる部分で同時に作業します。

ガバナンスがなければ、これは混乱につながります。劇的な種類の混乱ではなく、ゆっくりとした、潜行性のある混乱です。すべてのコミットが個別には合理的でありながら、累積的な効果はアーキテクチャの腐敗。半年後にコードベースを見て、なぜ3つの異なるログライブラリと2つの ORM パターンがあり、なぜかすべてに依存しているサービスが存在するのか説明できなくなる、そういう種類の混乱です。

アーキテクチャガードレールはこのダイナミクスを根本的に変えます：

AI エージェントを導入するチームへ：アーキテクチャの意思決定は、もはやエージェントがコードを書くときに失われる暗黙知ではありません。それらは自動的に強制されるルールとしてエンコードされます。エージェントは、シニアエンジニアがコードレビューで提供するのと同じガバナンスを受けます——ただし即座に、すべての変更に対して、レビュー疲れなしに。

プラットフォームチームへ：数十のサービスと数百の AI 生成の変更にわたってパターンを標準化でき、一つ一つを手動でレビューする必要はありません。ルールを一度定義し、すべてに適用。チームが AI エージェントで新しいサービスを立ち上げるとき、プラットフォームの規約に自動的に従います。

規制産業へ：コンプライアンス要件を適合性ルールとしてエンコードできます。「すべてのサービスにヘルスチェックが必要。」「ログに PII を含めない。」「保存時の暗号化が必須。」これらは文書化されるだけでなく、検証可能になります。監査証跡が、すべての AI 生成の変更がマージ前にルールに対して検証されたことを示します。

オープンソースメンテナーへ：PR を提出するコントリビューター（人間でも AI でも）は、アーキテクチャ適合性について即座にフィードバックを受けます。コントリビューターが知らなかった規約に違反する PR をレビューする必要はもうありません。ルールはアーキテクチャの期待を実行可能な制約として文書化します。

エージェントの時代に繁栄するチームは、最高の AI エージェントを持つチームではありません。最も明確なアーキテクチャ境界を持つチームです。エージェントは交換可能です。アーキテクチャは交換できません。

はじめる

Agent Hub は、すべての Archyl ユーザーに今すぐご利用いただけます。サイドバーの Agent アイコンをクリックしてください。カタログを閲覧し、いくつかのガードレールを追加し、あなたが定義した境界の中で AI エージェントを動かしましょう。

あなたのアーキテクチャの意思決定は、AI にとってオプショナルであるべきではありません。もうそうではなくなりました。