OpenClawの5層ゲートキーピング：AIエージェント時代の品質管理

31万スターのプロジェクトに押し寄せる数千件のPRと、8つのAIエージェントによる並列コミット。この混沌のなかで品質が崩れない秘訣は、5層の自動化されたゲートキーピングにあります。

以前の記事では、OpenClawのAGENTS.mdに込められた生産性の原則を分析しました。あの記事の核心は「ルールを書くこと」でした。しかし、ルールを書くことと、ルールを強制することはまったく別の問題です。

OpenClawはGitHubで最も多くのスターを集めたリポジトリ（31万以上）であり、バイブコーディングの代表的な事例です。¹ このプロジェクトは、2つの極端な圧力を同時に受けています。1つはメンテナーのPeter Steinbergerが3〜8個のAIエージェントを同時に走らせながら生み出す内部変更であり、もう1つは世界中のコントリビューターがAIの補助で作成して提出する数千件の外部PRです。

AGENTS.mdに「これをするな」と書くのはソフトガードレールです。AIエージェントはたいてい従いますが、常に従うとは限りません。外部コントリビューターは、そのルールの存在すら知らない可能性があります。そこでOpenClawは、ルールの上に5層の自動化された強制メカニズムを積み上げました。この記事では、そのメカニズムを解剖します。

TL;DR

OpenClawの品質管理はルール文書だけではなく、プリコミット、pnpm check、CI、PR自動化、リリースゲートが重なった5層構造で機能しています。
自動修正できる問題はツールが直し、型エラー・セキュリティ・アーキテクチャ境界のような危険な問題は遮断するという形で、多層防御をつくります。
バイブコーディング時代の目標は、AIが悪いコードを絶対に書かないようにすることではなく、悪いコードが本番に到達しないようにすることです。

第1層：コミット前に捕まえる — ローカルのプリコミット

OpenClawの最初の防衛線は、コードがリポジトリに到達する前から機能します。git-hooks/pre-commitはpackage.jsonのprepareスクリプトを通じて自動的に有効化され、コミットのたびに実行されます。

動作の順序が興味深いところです。

ステージされたファイルを種類別にフィルタリング
oxlint --type-aware --fix — リントエラーを自動修正
oxfmt --write — フォーマットを自動修正
修正されたファイルを再びステージング
pnpm check — 品質ゲート全体を実行

核となる設計は自動修正と遮断の分離です。フォーマットやリントエラーのように機械的に直せる問題は、フックが自分で直して通します。しかし、型エラーやアーキテクチャ境界の違反のように判断を要する問題は、コミット自体を遮断します。この区別がないと、エージェントは些細なフォーマットエラーで止まるか、構造的な欠陥をそのまま通してしまうかのどちらかになります。

これに加えて.pre-commit-config.yamlは、CIのsecurity-fastジョブでも実行される17個のセキュリティ・品質フックを定義しています。detect-private-keyとdetect-secretsでシークレットの流出を遮断し、zizmorでGitHub Actionsワークフローのセキュリティを監査し、pnpm-audit-prodで本番依存関係の既知の脆弱性を検査します。

第2層：1つのコマンドで10種類を検証する — `pnpm check`

pnpm checkは、ローカルのフックとCIの両方で実行される単一の品質ゲートです。1つのコマンドの背後に10個以上のチェックがチェーンされています。

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個のカスタムアーキテクチャ境界リントスクリプト

ここで最も注目すべきは最後の行です。一般的なリンターは「使われていない変数」や「セミコロンの欠落」といったコードレベルの問題を捕まえます。しかしOpenClawのカスタム境界ガードスクリプトは、アーキテクチャレベルの違反を捕まえます。Extensionがコアのsrc/**を直接インポートしたり、プラグインSDKの内部パスを参照したり、パッケージルートの外へ相対パスを伸ばしたりするのを検出します。

これは以前の記事で分析したAGENTS.mdのインポート境界ルールがコードとして実装されたものです。ルール文書に「するな」と書いたことを、CIが実際に検証して遮断します。ルールと検証の二重の壁です。

第3層：15個の並列ジョブがすべての変更を検査する — CIワークフロー

OpenClawのci.ymlは、PRとmainへのプッシュで実行されるメインのゲートキーパーです。約15個の並列ジョブで構成され、ドラフトPRはスキップします。

スマートルーティング：速度と徹底性の両立

すべての変更にすべてのテストを走らせれば徹底的ですが、遅くなります。関連するテストだけを走らせれば速いものの、見落としが生じます。OpenClawはpreflightジョブでこのジレンマを解決します。

preflightジョブは変更されたファイルのスコープを検出し、CIマニフェストを生成します。ドキュメントだけを変更したならドキュメントチェックだけを、Swiftファイルに触れたならmacOSのビルドとテストを追加し、特定のExtensionだけを変更したなら該当Extensionのテストだけを実行します。このスマートルーティングが、「遅いが徹底的な」CIと「速いが不完全な」CIのあいだのバランスをつくります。

CIジョブの全体構造

カテゴリ	ジョブ	チェック内容
セキュリティ	security-fast	秘密鍵の検出、Actionsのセキュリティ監査、依存関係の監査
品質	check	`pnpm check`全体 + strict smoke build
アーキテクチャ	check-additional	15個以上の境界ガード、スキーマドリフト、SDK APIベースライン
ビルド	build-artifacts	`pnpm build` + UIビルド
テスト（Linux）	checks（シャーディング）	vitestユニットテスト、チャネルテスト、Node 22互換
テスト（Windows）	checks-windows（シャーディング）	テストスイート全体
テスト（macOS）	macos-node（シャーディング）	テストスイート全体
Extension	checks-fast, extension-fast	コントラクトテスト、変更されたExtensionを対象としたテスト
ネイティブアプリ	macos-swift, android	Swift/Kotlinのビルド + テスト + リント
ドキュメント	check-docs	フォーマット、リンク監査、i18n用語集
スモーク	build-smoke	CLIの`--help`/`--version`、起動メモリチェック
リリース	release-check（mainのみ）	リリースコンテンツの検証

とりわけ印象的なのは、check-additionalジョブのアーキテクチャ境界ガードです。プラグイン→Extensionのインポート違反、Extension SDKの内部パス参照、生のwindow.openの使用、ゲートウェイwatchの回帰などをカスタムスクリプトで検出します。一般的なCIパイプラインでは見られない、バイブコーディング環境に特化したガードレールです。

第4層：数千件のPRを人手なしで仕分けする — PRライフサイクルの自動化

31万スターのプロジェクトには、数千件のイシューとPRが押し寄せます。メンテナーが1つずつ仕分けるのは不可能です。OpenClawは3つの自動化ワークフローでこの問題を解決しています。

自動ラベリング：変更ファイルがそのままラベルになる

labeler.ymlワークフローは、PRが開かれると変更されたファイルパスを分析してラベルを自動付与します。21個のチャネルラベル（channel: discord、channel: telegramなど）、4個のアプリラベル（app: ios、app: androidなど）、8個の領域ラベル（gateway、agents、securityなど）、30個以上のExtensionラベルが定義されています。

さらに、PRサイズラベル（XS/S/M/L/XL）を行数ベースで自動付与し、メンテナーラベルをチームメンバーシップから判別し、beta-blockerラベルをPRタイトルから自動検出します。これらのラベルが、次の段階の自動応答システムをトリガーします。

自動応答：ノイズを自動でふるい落とす

auto-response.ymlは、ラベルにもとづいてPRとイシューを自動処理します。このワークフローのルールは、実際の運用経験から蓄積されたものです。

スパム／ノイズの遮断：

r: spamまたはr: moltbookラベル → 自動クローズ + ロック
dirtyラベル、またはラベルが20個を超えるPR → 「noisy PR」メッセージとともにクローズ

コミュニティ行動の制限：

非メンテナーのオープンPRが10個を超えると → r: too-many-prsラベルを付与して自動クローズ
イシュー／PRでメンテナーを3名以上メンションすると → スパムping警告メッセージ

適切なチャネルへの案内：

r: skill → スキル関連の質問はClawHubへ案内してクローズ
r: support → サポート要請はDiscordへ案内してクローズ
r: no-ci-pr → CI設定のみを変更するPRを却下

1人あたりPR10個の上限は、とりわけバイブコーディング時代に重要です。AIツールでPRを大量生産しやすくなった環境で、1人がレビューキューを独占するのを防ぎます。CONTRIBUTING.mdもこれを明示しています。“Keep PRs focused (one thing per PR; do not mix unrelated concerns)”²

ライフサイクル管理：放置されたPRは自動で整理する

stale.ymlは毎日実行され、放置されたイシューとPRを整理します。イシューは7日後にstale表示 → 5日後にクローズ、PRは5日後にstale → 3日後にクローズ。クローズされたイシューは48時間後にロックされます。enhancement、maintainer、pinned、securityラベルが付いた項目は免除されます。

PRの寿命がイシューより短いのが目を引きます（5+3日 vs 7+5日）。コード変更は時間が経つほどコンテキストから遠ざかり、コンフリクトの可能性が高まるからです。

PRテンプレート：証拠を構造的に要求する

OpenClawのPRテンプレートは、一般的な「何をしたか」のレベルを超えて、証拠にもとづくレビューを強制します。

必須セクションのなかでも、とくに注目すべき部分です。

What did NOT change (scope boundary)：変更していない範囲を明示的に宣言します。AIエージェントがつくった変更はスコープが広がりやすいため、意図的な境界を宣言させることで、レビュアーがスコープクリープを検知できるようにします。
Security Impact：権限、シークレット、ネットワーク、ツール実行、データアクセスの変更有無をそれぞれYes/Noでチェックします。「セキュリティに影響がありますか？」という曖昧な問いの代わりに、具体的な表面を1つずつ点検させます。
Evidence：失敗→成功のテスト、トレース／ログ、スクリーンショットのうち最低1つの添付が必須です。
Human Verification：検証したシナリオ、エッジケース、そして検証していないことを明示します。

最後の項目がとくに重要です。「何をテストしたか」だけを問えば、PR作成者は成功したケースだけを並べます。「何をテストしていないか」を問えば、レビュアーはリスク領域をただちに把握できます。

第5層：取り消せない行動の前で立ち止まる — リリースゲート

CIは完全自動ですが、リリースは決して自動ではありません。OpenClawのリリースパイプラインは、手動トリガー + 環境承認 + 多段階検証で構成されています。

NPMリリース：19段階のシーケンス

openclaw-npm-release.ymlはworkflow_dispatchでのみトリガーされます。自動リリースはありません。実行されると、次の検証を順番に通過します。

タグフォーマットの検証
pnpm check + pnpm build + pnpm release:check
npmバージョンの一意性の確認
npm-release環境の承認 → @openclaw/openclaw-release-managersチームメンバーによる明示的な承認が必須
mainブランチからの実行のみを強制
その後の19段階シーケンス：タグ作成 → npm preflight → mac preflight（公開＋非公開）→ 実際のパブリッシュ → アセット検証 → appcastの更新

CODEOWNERS：セキュリティ表面を物理的にロックする

CODEOWNERSは、GitHubが強制するハードガードレールです。AGENTS.mdの「セキュリティファイルに触れるな」がソフトガードレールだとすれば、CODEOWNERSは該当チームのレビュー承認なしにはマージ自体を不可能にします。

@openclaw/secops が保護する表面：

セキュリティコード：src/security/、src/secrets/、ゲートウェイの認証／シークレット、エージェントサンドボックス
セキュリティインフラ：dependabot、CodeQL、SECURITY.md
セキュリティドキュメント：認証、サンドボックス化、シークレット関連のドキュメント全体

@openclaw/openclaw-release-managers が保護する表面：

リリースワークフロー、パブリッシュスクリプト、リリースドキュメント

CODEOWNERSファイル自体は@steipete（創始者）だけが修正できます。ゲートキーパーを保護するゲートキーパーです。

AIエージェント用のスキルゲート

リリースとPR管理のためのAIエージェントスキルにも、ゲートがあります。

$openclaw-pr-maintainerスキルは、バグ修正PRに対して証拠の基準を強制します。イシューのテキストやAIの推論だけではマージできません。症状の証拠、検証された根本原因（ファイル／行レベル）、関連するコードパスの修正、回帰テストが必要です。一括クローズ／再オープンが5件を超える場合は、必ずユーザーの確認を得なければなりません。

$openclaw-release-maintainerスキルは、バージョン番号の変更とnpm publishの両方について、各段階ごとにオペレーターの承認を要求します。スキルは自動化を助けますが、不可逆な行動は依然として人間が最終決定します。

5層がつくる多層防御

この5層を1枚の図として見ると、コードが本番に到達するまでに通過する多層防御（defense in depth） が浮かび上がります。

[開発者／エージェント]
       ↓
  第1層：プリコミット ── フォーマット／リントの自動修正、型／境界違反の遮断
       ↓
  第2層：pnpm check ─── 10以上のチェックのチェーン、15以上のアーキテクチャ境界ガード
       ↓
  第3層：CI ─────────── 15個の並列ジョブ、クロスプラットフォーム、セキュリティスキャン
       ↓
  第4層：PR自動化 ───── ラベル仕分け、ノイズフィルター、証拠ベースのテンプレート、stale整理
       ↓
  第5層：リリース ───── 手動トリガー、環境承認、CODEOWNERS、19段階の検証
       ↓
  [本番]

各層は独立しています。プリコミットが失敗してもCIが捕まえ、CIを迂回してもPRレビューが引っかけ、PRが通ってもリリースゲートが止めます。1つの層が破られても、次の層が防御します。

設計原則7つ

OpenClawのゲートキーピングから抽出した設計原則を整理します。

1. 自動修正と遮断を分離する

フォーマット／リントエラーは自動修正、型／境界違反はハード遮断。エージェントのフローを不必要に断ち切らずに、構造的な欠陥は通さないようにします。

2. スマートルーティングで速度を維持する

すべての変更にすべてのテストを走らせません。変更のスコープを検出し、関連するジョブだけを実行します。速いフィードバックと徹底した検証は両立できます。

3. ルール文書と自動検証を重ねる

AGENTS.mdに「するな」と書き、CIで実際に違反を検出します。ソフトガードレールとハードガードレールの二重の壁が、多層防御をつくります。

4. PRに証拠を構造的に要求する

「何をしたか」だけでなく、「何をしなかったか」「どんな証拠があるか」「セキュリティ影響はあるか」を構造的に問いましょう。レビュアーが判断すべき情報を、作成者にあらかじめ提供させるのです。

5. コミュニティのノイズを自動でフィルタリングする

1人あたりPR10個の上限、staleの自動クローズ、ラベルにもとづく自動クローズ／案内、メンテナーへのpingスパム検出。メンテナーのアテンションは有限な資源であり、自動トリアージがその資源を守ります。

6. 不可逆な行動の前では立ち止まる

CIは完全自動でも、リリースは手動トリガー + 環境承認。AIエージェントスキルも、バージョン変更とパブリッシュは毎段階の承認が必要です。「速く動く。ただし、取り消せない行動の前では立ち止まる」ということです。

7. ゲートキーパーを保護するゲートキーパーを置く

CODEOWNERSファイルは創始者だけが修正できます。リリースワークフローはリリースマネージャーチームだけが修正できます。セキュリティコードはsecopsチームの承認なしにはマージできません。ゲートキーピングのシステム自体を保護するメタ層があるのです。

自分のプロジェクトに適用するには

OpenClawの5層すべてを一度に導入する必要はありません。難易度順に整理すると、次のようになります。

段階	導入項目	効果
即座に	pre-commitフック（lint+formatの自動修正）	些細なエラーでCIが失敗する無駄を除去
即座に	PRテンプレートに証拠／セキュリティのセクションを追加	レビュー品質が即座に向上
1週間	CIに型チェック + テストゲート	基本的な品質の下限を確保
1週間	CODEOWNERSでセキュリティ機微ファイルを保護	セキュリティ表面をハードロック
2週間	staleボット + 自動ラベリング	PRキュー管理の自動化
1か月	カスタムアーキテクチャ境界ガードスクリプト	アーキテクチャの腐食を防止
1か月	スマートルーティング（変更スコープにもとづくCIジョブ選択）	CI速度の最適化
四半期	リリース環境の承認 + 多段階検証	リリースの安全性を確保

最もROIが高いのは、pre-commitフックとPRテンプレートです。どちらも1日以内に導入でき、効果もすぐに現れます。残りは、プロジェクトの規模とリスクに合わせて段階的に追加していけばよいでしょう。

バイブコーディング時代の品質管理は、「AIが悪いコードを書かないようにすること」ではありません。AIはときどき悪いコードを書きます。人間も同じです。核心は、悪いコードを本番に到達させないことです。OpenClawの5層ゲートキーピングは、その方法を示してくれます。