Engineering-Management on ROBOCO

バイブコーディング時代、リポジトリ規則と個人の好みの境界

Thu, 26 Mar 2026 17:26:21 +0900

AGENTS.mdの役割は開発者を複製することではなく、事故を防ぐべき境界だけを固定することにある。

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディングを導入したチームは、まもなく似たような問いに直面します。リポジトリごとにAGENTS.mdやCLAUDE.mdを置いてAIエージェントに規則を伝え始めると、どこまでを共通規則として固定し、どこからを個人の好みとして残しておくべきなのかが曖昧になるからです。この境界を誤ると、二つの問題が同時に生じます。必ず守るべき安全規則は緩くなり、逆に好みに近い選択は不必要に硬直化するのです。

最近のバイブコーディング論議で頻繁に登場する観点も似ています。人間はシステムアーキテクチャや好みのような高次の判断に集中し、実装やボイラープレート、反復的なリファクタリングはエージェントに任せよ、というものです。これを実務的に翻訳すれば単純です。リポジトリには「誰が作業しても同じでなければならないもの」を残し、人によって違ってもよい領域はあえて強制しないことです。

この問いは理論にとどまりません。先に整理した[OpenClaw事例分析]¹と[OpenClawのAGENTS.md解剖]²を見ると、実際に生産性を生んだ規則は好みの統一ではなく、境界の明示性でした。Steinbergerもまた、最近はコードをすべて読むわけではないが、システム構造と設計はずっと握り続けていると説明しています。³⁴ OpenClawが強く固定したのもタブとスペースではなく、import boundary、ビルドゲート、マルチエージェントの安全規則、そして不可逆な作業の承認境界です。⁵

肝心なのは多く書くことではなく、何を閉じて何を開いておくかを設計することです。

TL;DR

リポジトリ規則はチームの好みを複製する文書ではなく、事故のコストが大きい境界を固定する文書であるべきです。
ビルド、テスト、セキュリティ、Gitの安全規則、アーキテクチャ境界はリポジトリとともに管理しなければなりません。
命名のニュアンスやコメントスタイルのような好みは、formatter、linter、テンプレート、個人プロンプトで扱うほうが適しています。

なぜこの区分が重要なのか

AIエージェントは規則を素早く守ります。問題は、規則の性格を自分では区別できないという点にあります。リポジトリの指針にビルドコマンド、シークレットの扱い、ブランチの安全規則のように必ず守らなければならない制約と、「私ならこう書く」という水準の好みが混ざっていると、エージェントは両者を同じ重さで扱います。すると重要な規則は埋もれ、さほど重要でない規則は過度に増幅されます。

たとえばpnpm testを通さずにマージすればバグが出ます。実際のシークレットをコミットすれば事故になります。認証フローや決済の権限ロジックを十分な検討なしに変えれば運用リスクが生じます。こうしたものは議論の余地のない運用契約です。一方、関数名をfindUserにするかgetUserByIdにするか、テストファイルをソースの隣に置くか__tests__にまとめるか、importをどの順序で並べるかは、結果に影響を与えることはあっても、たいていは正解が一つに固定されるわけではありません。

この違いを区別しなければ、リポジトリの文書はすぐに肥大化します。あらゆる選好を中央の規則に引き上げれば、エージェントは文書を読むことにより多くのコンテキストを使い、チームは些細なスタイル合意に不要なエネルギーを費やします。逆に客観的な制約を好みの水準で扱えば、マルチエージェント環境で衝突と手戻りが繰り返されます。

結局、良いAGENTS.mdはチームの好みの辞書を作る文書ではなく、事故のコストが大きい領域の境界を明確に引いておく文書であるべきです。

OpenClawが実際に示したもの

以前の記事で整理したとおり、OpenClawのAGENTS.mdは単なるスタイルガイドではなく運用契約です。² 興味深いのは、その文書が「開発者をどう複製するか」よりも「エージェントがどこで事故を起こしうるか」にはるかに強く集中している点です。実際の指針を見ると、ビルド成果物やモジュール境界に影響を与えうる変更にはpnpm buildの通過をハードゲートとして要求し、@ts-nocheckのような典型的な回避パターンも明示的に禁止しています。⁵

たとえばOpenClawは、拡張が内部実装に直接手を出せないようにimport境界を規則としてロックしています。またgit stashの禁止、任意のブランチ切り替えの禁止、原子的なコミットの維持といったマルチエージェントの安全規則を置いています。ビルドとテストもハードゲートとソフトゲートに分け、いつ必ず検証しなければならないのかを明確に書いてあります。²⁵

逆にその文書は、「セミコロンを必ず使え」「関数名は必ずこういうトーンでつけろ」といった個人の好みを中心に設計されてはいません。つまりOpenClawが示した核心は単純です。リポジトリ文書が扱うべきなのは美的な統一感ではなく、構造的な安全性なのです。

リポジトリとともに管理すべき規則

以下はリポジトリとともにバージョン管理されるべき領域です。共通点は一つです。違反したときにバグ、衝突、セキュリティ事故、運用の混乱が発生するという点です。

ビルドとテストのコマンド
マルチエージェント環境におけるGitの安全規則
公開APIサーフェス、import boundary、パッケージ境界のようなアーキテクチャ制約
シークレット、個人情報、運用設定値のようなセキュリティ境界
認証、決済、権限、DBスキーマのように手動レビューが必要な高リスク領域
PR／コミットの単位のような変更管理の原則
Research → Plan → Implementのように誤りのコストを下げる作業順序
AI利用時の透明性要件
チームがすでに検証済みの品質ゲートと自動化基準

これらの項目は「良さそうな推奨」ではなく、リポジトリの運用契約に近いものです。

たとえばビルドコマンドがnpm run buildなのかpnpm buildなのかを、人によって別々に解釈してはいけません。自動化パイプラインとローカル検証が同じコマンドを基準に動かなければならないからです。Gitの規則も同様です。マルチエージェントで同時に作業する環境では、任意のstash利用、要求されていないブランチ変更、広範囲の非原子的なコミットが実際の衝突を生みます。

セキュリティ境界については言うまでもありません。実際の電話番号、本番環境の環境変数、非公開鍵、顧客データのサンプルといったものは、チームのスタイル選好ではなく禁止リストです。こうした内容は個人プロンプトや暗黙知に置いてはならず、リポジトリの文書と自動スキャンの規則にともに残っていなければなりません。

ワークフローの順序も同じ文脈です。実装の前に既存コードを読み、計画を立て、それから変更させるという手順は、単なる形式主義ではありません。エージェントは質問を減らすほど速くなりますが、誤った仮定の上で速くなれば、後でより高くつきます。ですから探索と計画を先に要求する規則は、好みではなくコスト削減の装置です。

ここでもう一つ重要なポイントがあります。チームがすでに自動化に依存しているなら、その自動化が期待する形式もまた共通規則になります。たとえばConventional Commits形式がリリースノート、チェンジログ、CIルーティングに結びついているなら、それはもはや好みではありません。逆に単に「読みやすい」水準の形式選好であれば、チームレベルの合意であってよく、必ずしもリポジトリの中核規則に格上げする必要はありません。

反復手順をどこに置くかも同じ基準で見ることができます。OpenClawはリリースやセキュリティ点検のような複雑な反復業務をAGENTS.mdの本文に長く書くのではなく、別のスキルとして分離しています。²⁶ これもまた良い区分です。リポジトリの中核文書には原則と境界を残し、手続き的な詳細は再利用可能な実行面として分離するほうが長持ちします。

個人の好みとして残してよい領域

逆に次のような領域は、個人やチームの好みとして残しておくことができます。もちろんチームが一貫性のために標準化することはできますが、それがリポジトリの中核的な安全契約である必要はありません。

セミコロンの使用有無、空白の数、trailing commaのようなフォーマットの細部
関数名や変数名の細かなニュアンス
importの並べ方
コメントをどの程度まで書くかというスタイル
テストファイルの配置方法とテストの記述スタイル
抽象化を早く行うか遅く行うかという選好
feature-based構造とlayer-based構造の間の選好
エラー処理パターンの細かな選択
プロンプトを長く書くか短く書くかといった個人の作業スタイル

こうした項目は、互いに異なる選択肢がいずれも合理的でありうるものです。たとえばあるチームはstrictな型設定を好み、あるチームはオンボーディングのコストを下げるために段階的に厳格度を上げます。あるチームはResultパターンを好み、あるチームは例外ベースのフローのほうが明確だと感じます。どちらであれ一貫して運用されるなら、十分に合理的でありえます。

重要なのは、こうした好みを完全に無視しようという意味ではないという点です。好みも生産性に影響します。ただし、それをどこに置くかが重要なのです。リポジトリの中核契約として扱うよりも、formatter、linter、テンプレート、サンプルコード、個人プロンプト、チームプレイブックのような軽い装置で扱うほうが適しています。そうしてこそ、好みは維持しつつリポジトリの指針が過度に重くならずに済みます。

とりわけバイブコーディングでは、この違いがいっそう重要になります。エージェントにあらゆる好みを強く注入すれば、コード生成はかえって硬直し、小さな変化でも規則の衝突が多く発生します。一方、好みは緩やかなガイドとして置き、安全と品質に直結する境界だけを強く固定すれば、エージェントははるかに安定して働きます。

バイブコーディング導入のための組織設計

Fri, 20 Mar 2026 21:23:40 +0900

バイブコーディングの成否は、AIがつくった変更をチームが反復可能で安全な方法で検証し、デプロイできるようにする組織設計にかかっています。

チョン・ドヒョン - ROBOCO首席コンサルタント

多くの組織は、バイブコーディングを「開発者がコードをより速くつくる方法」程度に理解しています。だからこそ導入の議論も、たいていツールの導入から始まります。しかし実際の現場で成否を分けるのは、ツールやモデルの性能よりも組織の構造です。

バイブコーディングはオートコンプリートではなく、働き方の再設計に近いものです。組織のメンバー一人ひとりがより広い領域をカバーし、チーム間のハンドオフとコミュニケーションのコストを減らせるとき、生産性は大きくなります。とはいえ、目標が人員削減だというわけではありません。核心は、同じ組織がより多くのことを、より速く、より安全に届けられるようにすることにあります。そのためには、要求をどう分解するか、どの変更をAIに任せてどの変更を人が直接判断するか、どんなテストと承認の手続きを通過すればデプロイするのかを設計しなければなりません。その設計がなければ、AIは生産性を高めるどころか混乱を大きくします。

この記事は、OpenClawの事例と最近のエンタープライズAI導入の流れに共通して現れた教訓をもとに、バイブコーディングを実際の製品開発組織に定着させるための組織設計の原則を整理したものです。

TL;DR

バイブコーディング導入の成否は、ツールよりも、AIがつくった変更を検証しデプロイする組織構造と責任体系にかかっています。
リポジトリの指針だけでは足りず、共用プラグイン・ガードレール・承認条件を中央で管理し、現場のチャンピオンがチームの文脈に合わせて調整する必要があります。
運用モデルは Research → Plan → Implement → Auto Review → Monitor の流れで設計し、人はすべてのレビューではなく、例外と高リスクの判断に集中すべきです。

コードを減らして書くのではなく、コードを生成するシステムを設計すること

バイブコーディングの環境で、人間の役割がなくなるわけではありません。役割の中心が変わるだけです。直接コードをタイピングする時間は減り、代わりに次の活動の比重が大きくなります。

作業を小さな単位に分解すること
エージェントが従うべき制約とルールを文書化すること
承認ポリシーと遮断のしきい値を設計すること
テスト、レビュー、デプロイのゲートを自動化すること
事故と失敗を、ふたたび指針とルールへ還元すること

この変化は、開発者個人のプロンプティングスキルだけでは支えきれません。組織レベルの運用契約が必要です。たとえばリポジトリごとにCLAUDE.md/AGENTS.mdのようなエージェント指針ファイルを置き、ビルド方法、テストコマンド、禁止領域、レビュー基準、セキュリティ境界を機械が読める形で維持しておくことは、いまや選択ではなく基本に近いものです。

結局、重要な問いは「私たちの組織は、AIが生み出した変更をどんな規律とどんな責任構造のなかで扱うのか」です。

リポジトリの指針だけでは足りない。全社共用のプラグインシステムが必要だ

リポジトリ単位のAGENTS.mdは、ローカルな文脈を固定するのに有用です。しかし組織への導入はここで終わりません。チームごとにプロンプトやツール接続をばらばらにコピーして使い始めると、同じ業務を何度も定義することになり、権限統制は散らばり、良いワークフローは一部の個人のノウハウとしてしか残らなくなります。

だからこそ、組織レベルのバイブコーディングには共用プラグインシステムが必要です。ここでいうプラグインとは、単なるプロンプトの寄せ集めではなく、特定の役割や業務に必要なメモリ（ルール）、スキル、フック、コネクター、承認条件を1つの配布単位にまとめた運用パッケージです。言い換えれば、共通スキルは独立した配布物ではなく共通プラグインの一部であり、実際のガードレールは、プラグイン内のルール、実行スキル、自動呼び出しフックが一緒に働いてはじめて強制されます。Anthropicが2026年2月24日に発表したClaude Coworkのアップデートも、同じ方向を示しています。管理者は社内専用のプラグインマーケットプレイスをつくり、承認されたコネクターをバンドルし、非公開のGitHubリポジトリをプラグインのソースとして接続し、チームまたはユーザー単位で自動インストールとアクセスを制御できるようになりました。¹

個人のプロンプトは個人の生産性を高めます。共用プラグインは組織の一貫性をつくります。重要な運用単位は「誰がうまく使うか」ではなく、「誰が使っても同じ境界と品質基準が適用されるか」でなければなりません。

組織レベルのプラグインシステムは、少なくとも次のことを行うべきです。

検証済みのワークフローを再利用可能な形で配布すること
承認されたコネクターとデータアクセス範囲を中央で統制すること
チームごとの文脈の違いを、プラグインのバージョンと設定で吸収すること
使用量、コスト、ツール呼び出しを観測し、どの自動化が実際に効果的かを測定すること

結局のところ、リポジトリの指針は「このコードベースでどう働くか」を定義し、共用プラグインは「私たちの組織でAIがどんなやり方で働くか」を定義します。前者がローカルな運用契約なら、後者は組織共通の運用プロダクトです。

なぜ多くのAI導入は思ったほど効果を出さないのか

バイブコーディングの導入が期待ほど効果を出さない理由は、たいてい似ています。生成の速さだけを見て、統制の構造を後から付け足すからです。序盤は誰もが速いと感じます。PRが速く上がり、ドキュメントの草案もあっという間にでき、テストコードも以前より簡単につくれます。ところが数か月が経つと、レビューの疲労度が上がり、誰が何に責任を持つのかが曖昧になり、運用の安定性が揺らぎ始めます。

こうした現象は不思議なことではありません。エンジニアリングの基礎が弱い組織ほど、AIは速度を上げる前にノイズを先に大きくします。小さなバッチで頻繁にデプロイする習慣がなく、テストの信頼度が低く、コードレビューの基準が曖昧な状態なら、AIはボトルネックを解決するどころか、ボトルネックにより多くの変更を押し込みます。

ですからバイブコーディングの導入は、生産性プロジェクトではなく運用設計プロジェクトとして扱うべきです。速度は結果であって出発点ではありません。まず答えるべき問いは、次の4つです。

どの変更はAIが自律的に実行してよいのか
どの変更は必ず人間の承認を経なければならないのか
どんな証跡があればレビュアーは安心して承認できるのか
失敗から得た教訓をどこに蓄積するのか

この問いに答えられないままツールだけを配布すれば、組織はほどなく「AIを使ってはいるが、かえって疲れた」という状態に到達します。

推奨する組織モデル：中央プラットフォーム + 現場チャンピオン + 最終オーナーシップ

ほとんどの組織にとって最も現実的な答えは、ハイブリッドモデルです。中央のプラットフォームチームだけがすべてを統制する方式はボトルネックになり、各プロダクトチームがばらばらにツールを使う方式は速く断片化します。

ハイブリッドモデルは3つの層で構成されます。

第一に、中央のAIプラットフォーム・ガードレールチームが共通インフラを提供します。モデルルーティング、アクセス制御、共用プラグインマーケットプレイス、承認されたコネクター、共通のプロンプト・スキルテンプレート、リポジトリ統合、ログとコストの観測、ポリシーの自動化といった基盤機能は、ここが担うべきです。

第二に、各プロダクトスクワッドにAIチャンピオン、あるいはAIスペシャリストを置きます。この役割はツールを代わりに使ってあげる人ではなく、チームの実際の業務フローに合わせて指針とプラグインを整え、どの作業をAIに委譲するかを判断し、失敗パターンをプラットフォームチームへ返す結節点です。

第三に、最終的な責任は依然としてプロダクトチームが負います。AIがコードをつくったからといって、運用責任がプラットフォームチームへ移ってはいけません。サービス障害、セキュリティ問題、品質問題の最終オーナーは、そのサービスを運用しているチームであるべきです。

この構造を簡単に描くと、次のようになります。

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'background': 'transparent',
    'primaryColor': '#1f2937',
    'primaryTextColor': '#f9fafb',
    'primaryBorderColor': '#60a5fa',
    'secondaryColor': '#0f766e',
    'secondaryTextColor': '#f9fafb',
    'secondaryBorderColor': '#5eead4',
    'tertiaryColor': '#374151',
    'tertiaryTextColor': '#f9fafb',
    'tertiaryBorderColor': '#fbbf24',
    'lineColor': '#94a3b8',
    'clusterBkg': '#111827',
    'clusterBorder': '#64748b',
    'defaultLinkColor': '#94a3b8'
  }
}}%%
flowchart TB
    CTO[CTO / Head of Engineering] --> Platform[AI Platform & Guardrails]
    CTO --> Squads[Product Squads]
    CISO[CISO / Security] --> Governance[AI Security & Governance]

    Platform --> Gateway[LLM Gateway]
    Platform --> DevEx[Repo / IDE / CI Integration]
    Platform --> Evals[Evals & Quality Gates]
    Platform --> Observe[Cost / Logs / Observability]

    Squads --> Leads[EM / Tech Lead]
    Squads --> Champions[AI Champions]

    Governance -. policy .-> Platform
    Governance -. high-risk approval .-> Squads
    Champions -. field feedback .-> Platform

核心は明確です。標準化と共用配布は中央で、文脈の反映は現場で、責任はプロダクトチームが担います。