https://roboco.io/ja/tags/gatekeeping/ Recent content in Gatekeeping on ROBOCO Hugo ja Fri, 27 Mar 2026 00:00:00 +0900 https://roboco.io/ja/posts/openclaw-gatekeeping-architecture/ Fri, 27 Mar 2026 00:00:00 +0900 https://roboco.io/ja/posts/openclaw-gatekeeping-architecture/ <blockquote> <p>31万スターのプロジェクトに押し寄せる数千件のPRと、8つのAIエージェントによる並列コミット。この混沌のなかで品質が崩れない秘訣は、5層の自動化されたゲートキーピングにあります。</p> </blockquote> <figure><img src="https://roboco.io/posts/images/Dohyun.png"><figcaption> <h4>チョン・ドヒョン - ROBOCO首席コンサルタント</h4> </figcaption> </figure> <hr> <p>以前の記事では、OpenClawの<a href="https://roboco.io/ja/posts/openclaw-agents-md-productivity-secrets/">AGENTS.mdに込められた生産性の原則</a>を分析しました。あの記事の核心は「ルールを書くこと」でした。しかし、ルールを書くことと、ルールを<strong>強制すること</strong>はまったく別の問題です。</p> <p>OpenClawはGitHubで最も多くのスターを集めたリポジトリ（31万以上）であり、バイブコーディングの代表的な事例です。<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> このプロジェクトは、2つの極端な圧力を同時に受けています。1つはメンテナーのPeter Steinbergerが3〜8個のAIエージェントを同時に走らせながら生み出す<strong>内部変更</strong>であり、もう1つは世界中のコントリビューターがAIの補助で作成して提出する<strong>数千件の外部PR</strong>です。</p> <p>AGENTS.mdに「これをするな」と書くのはソフトガードレールです。AIエージェントはたいてい従いますが、常に従うとは限りません。外部コントリビューターは、そのルールの存在すら知らない可能性があります。そこでOpenClawは、ルールの上に<strong>5層の自動化された強制メカニズム</strong>を積み上げました。この記事では、そのメカニズムを解剖します。</p> <h2 id="tldr">TL;DR</h2> <ul> <li>OpenClawの品質管理はルール文書だけではなく、プリコミット、<code>pnpm check</code>、CI、PR自動化、リリースゲートが重なった5層構造で機能しています。</li> <li>自動修正できる問題はツールが直し、型エラー・セキュリティ・アーキテクチャ境界のような危険な問題は遮断するという形で、多層防御をつくります。</li> <li>バイブコーディング時代の目標は、AIが悪いコードを絶対に書かないようにすることではなく、悪いコードが本番に到達しないようにすることです。</li> </ul> <hr> <h2 id="第1層コミット前に捕まえる--ローカルのプリコミット">第1層：コミット前に捕まえる — ローカルのプリコミット</h2> <p>OpenClawの最初の防衛線は、コードがリポジトリに到達する前から機能します。<a href="https://github.com/openclaw/openclaw/tree/main/git-hooks"><code>git-hooks/pre-commit</code></a>は<code>package.json</code>の<code>prepare</code>スクリプトを通じて自動的に有効化され、コミットのたびに実行されます。</p> <p>動作の順序が興味深いところです。</p> <ol> <li>ステージされたファイルを種類別にフィルタリング</li> <li><strong>oxlint</strong> <code>--type-aware --fix</code> — リントエラーを<strong>自動修正</strong></li> <li><strong>oxfmt</strong> <code>--write</code> — フォーマットを<strong>自動修正</strong></li> <li>修正されたファイルを再びステージング</li> <li><code>pnpm check</code> — 品質ゲート全体を実行</li> </ol> <p>核となる設計は<strong>自動修正と遮断の分離</strong>です。フォーマットやリントエラーのように機械的に直せる問題は、フックが自分で直して通します。しかし、型エラーやアーキテクチャ境界の違反のように判断を要する問題は、コミット自体を遮断します。この区別がないと、エージェントは些細なフォーマットエラーで止まるか、構造的な欠陥をそのまま通してしまうかのどちらかになります。</p> <p>これに加えて<a href="https://github.com/openclaw/openclaw/blob/main/.pre-commit-config.yaml"><code>.pre-commit-config.yaml</code></a>は、CIの<code>security-fast</code>ジョブでも実行される17個のセキュリティ・品質フックを定義しています。<code>detect-private-key</code>と<code>detect-secrets</code>でシークレットの流出を遮断し、<code>zizmor</code>でGitHub Actionsワークフローのセキュリティを監査し、<code>pnpm-audit-prod</code>で本番依存関係の既知の脆弱性を検査します。</p> <hr> <h2 id="第2層1つのコマンドで10種類を検証する--pnpm-check">第2層：1つのコマンドで10種類を検証する — <code>pnpm check</code></h2> <p><code>pnpm check</code>は、ローカルのフックとCIの両方で実行される<strong>単一の品質ゲート</strong>です。1つのコマンドの背後に10個以上のチェックがチェーンされています。</p> <pre tabindex="0"><code>pnpm check = check:no-conflict-markers # マージコンフリクトマーカーがないこと check:host-env-policy:swift # Swiftホスト環境のセキュリティポリシー check:base-config-schema # 設定スキーマのドリフトチェック check:bundled-plugin-metadata # プラグインメタデータの一貫性 check:bundled-provider-auth-env-vars # プロバイダー認証の環境変数の一貫性 format:check (oxfmt) # フォーマット検証 tsgo # TypeScriptネイティブ型チェック plugin-sdk:check-exports # プラグインSDKのエクスポート一貫性 lint (oxlint --type-aware) # 型認識リンティング + 約15個のカスタムアーキテクチャ境界リントスクリプト </code></pre><p>ここで最も注目すべきは最後の行です。一般的なリンターは「使われていない変数」や「セミコロンの欠落」といったコードレベルの問題を捕まえます。しかしOpenClawのカスタム境界ガードスクリプトは、<strong>アーキテクチャレベルの違反</strong>を捕まえます。Extensionがコアの<code>src/**</code>を直接インポートしたり、プラグインSDKの内部パスを参照したり、パッケージルートの外へ相対パスを伸ばしたりするのを検出します。</p>