アーキテクチャはポリシーである：ガバナンスをAIスタックにコンパイルする

現代のAIシステムにおいて、ガバナンスは往々にして後付けの人間によるレビューと見なされがちですが、Riddhi Mohan Sharmaは真のガバナンスとはデプロイメントの保証であると考えています。彼は自身のウェブサイトRiddhimohan.comを再構築するにあたり、従来の方法を拒否し、このサイトを生きたインフラストラクチャと見なし、企業向けAIエージェントのために設計したガバナンスアーキテクチャを適用しました。

このアーキテクチャの中核は「倫理的超高速」（Ethical Hyper-Velocity）という概念であり、プロフェッショナルな存在感を拡大しながら、エンタープライズレベルの構造的整合性を維持することを目的としています。Sharma氏は、手動によるガバナンスはスケール時に失敗すると強調します。なぜなら、人間のレビュー速度がシステムの反復速度に追いつかないからです。そこで彼はガバナンスをデプロイメントフローに直接コンパイルし、自動化されたガードレールによってすべてのコミットが最高基準を満たすことを保証しています。

自動化ガードレールの役割

このアーキテクチャでは、各デプロイメントはカスタムの自動化ガバナンスガードレールによる監査を受けます。例えば、コンテンツガードレールはプロフェッショナルな主張の一貫性を強制し、その厳格さは銀行が取引サービスに対して行うものと同等です。旧バージョンのタイトルが本番環境に送られようとすると、ガードレールはパイプラインをブロックします。これらのガードレールはメタデータを契約書として扱います。

Sharma氏は、企業にとっての課題はエージェンティックAIを構築することではなく、人間の監査能力を超える速度でそれをガバナンスすることだと指摘します。彼のサイトでは、各ビルドがGoogle PageSpeed Insightsに対してベンチマークされ、デスクトップパフォーマンススコアはビルド時に常に100/100を達成しています。

受動的監視から能動的エージェントへ

このアーキテクチャは3つのフェーズからなります。フェーズ1は構造的ガードレール、フェーズ2ではCore Web Vitals（CWV）メトリクスを物理法則として扱い、監視するだけでなく是正権限を持つAIエージェントが強制します。フェーズ3で運用が完了します。

重要な違いは、従来のガードレールがアラートを発するだけなのに対し、エージェンティックガードレールは介入することです。例えば、Largest Contentful Paint（LCP）が遅い場合、AIエージェントは違反したコード変更を見つけ出し、アーキテクチャの根本原因を特定し、修正を生成します。デプロイメントは修正が実行されるまで阻止され、通常はエージェント自身が修正を行います。

コア技術構造

このビルドは3つの異なるエージェントロールに基づいています：

• 観察者（Observer）：ランタイムおよびビルド時のパフォーマンス監査を継続的に実行。Lighthouse CI、メトリクスライブラリ、Puppeteerを使用。
• 立法者（Lawmaker）：交渉不可能なしきい値を定義（「物理法則」）。cwv-guard.mjs、budget.json。
• 是正者（Remediator、AIエージェント）：回帰を分析し修正を適用。LLM駆動の差分分析、画像調整API、Next/Image自動化。

具体的な実装：

1. 物理法則層（プリコミット/プリプッシュ）：スクリプトが「シャドウビルド」を実行。LCPが1.2秒超またはCLSが0.1超の場合、「ハードフェイル」とマーク。
2. エージェンティック是正ループ：物理法則が破られた場合、AIエージェントがLighthouse JSONレポートと現在のGit差分を取得し、根本原因を分析（例：新しいヒーロー画像にfetchPriorityがない）、是正差分を生成。
3. エージェンティックワークフロー統合：開発者がコードをプッシュすると、観察者エージェントがヘッドレス監査を実行、回帰を検出、是正者エージェントがReactコンポーネントを評価し修正を生成、PRがブロックされコメントが付与される。

技術的影響と検証

Sharma氏は、フォントサブセットが1キロバイトでも制限を超えるとサイトがシャットダウンすると述べ、コードの各行が古い色やアクセシビリティ準拠をチェックされることを強調します。すべてのアセットは絶対パス参照でプリロードされ、ハッシュ衝突を回避します。

サイトの自動化デプロイメントパイプラインのスクリーンショットは、すべてのガードレールが緑の場合にのみ本番環境にデプロイできることを示しています。デスクトップパフォーマンススコアは100/100、モバイルは87/100、アクセシビリティとSEOは100/100です。モバイルチューニングはブランドの明瞭性に重点を置き、低帯域幅のフォントシミュレーションではなく全忠実度のフォントプリロードを使用してレイアウトシフトをゼロにしています。

提起された課題

この作業はいくつかの疑問を提起します。エージェンティック是正のスケーラビリティ：数千のマイクロサービスを管理する場合、LLM駆動の差分分析の計算オーバーヘッドはどうなるか？ガバナンスレイテンシ：「ハードフェイル」モデルは高速CI/CD環境で受け入れがたい摩擦を生じさせないか？偽陽性：合法的なアーキテクチャ革新が一時的にレガシーパフォーマンスバジェットを破る場合、エージェント立法者がそれをブロックするのをどう防ぐか？

また、このアプローチはエージェンティック是正に必要なモジュール性を欠くレガシーモノリシックアーキテクチャには適用できません。そのようなシステムでは、物理法則層がカスケード障害を引き起こし、現在の是正者は生産安定性をリスクにさらさずに問題を特定できません。

結論

Sharma氏の核心メッセージは、「基準について語るのをやめ、自動化し、さらに自動化に自己修正を教えよ」です。ガバナンスをスタックにコンパイルすることで、信頼と速度はトレードオフではなく双子であることを示しています。このアーキテクチャはNext.js 16とturbopack上で動作し、カスタムCSSとアクセシビリティガードを使用し、ガバナンスエンジンはカスタムNode.jsスクリプトとLLMによって駆動されています。

この記事は単なる技術ケーススタディではなく、ポリシーはシステムにコンパイルされて初めて執行されるという哲学を示しています。