メインコンテンツにスキップ

パート8: チームの標準にする

最初の7つのパートはすべて一人の開発者に機能します。チームが関与した瞬間、余分な障害モードが現れます：ハーネスがドリフトします。ある人のルールファイルはある内容を言い、別の人のは別の内容を言い、エージェントの動作がチーム全体で再現不可能になり、規律が静かに侵食されます。このパートは、ワークフローを共有されて持続可能な標準にすることについてです。

念頭に置いておくべき根本的な原則：AIはその中に入るエンジニアリングカルチャーを増幅します。 強力なテスト、明確な標準、健全なレビューを持つチームは、これらのツールから劇的に多くのものを得ます。それらを持たないチームは、より速く問題を生み出します。標準化のポイントは、良いカルチャーを最も抵抗の少ない道にすることです。

ハーネスをコードとして扱う​

ルールファイル、システムプロンプト、エバリュエーションスイート、スキルライブラリは個人設定ではありません — それらは共有インフラです。コードとまったく同じように扱いましょう：

  • プロジェクトと共にバージョン管理する。
  • 他の変更と同様にプルリクエストでレビューする。
  • 名前付きオーナーを割り当て、意図を持って保守し、腐らせない。

これがなければ、すべての開発者のエージェントは微妙に異なる動作をし、誰も他の人の結果を再現できなくなります。

デモではなくエバリュエーションでゲートを設ける​

動作するデモは、エージェントが一度成功できることを証明します。合格したエバリュエーションスイートは、それが安定して成功することを証明します。この2つは同じではなく、デモの強さでリリースすることが、信頼性のないエージェントが本番環境に到達する仕組みです。

テストカバレッジでサービスにゲートを設けるのと同様に、エバリュエーションカバレッジをリリースの前提条件にしましょう。しかし、明確なルーブリックのないエバリュエーションは何も計測しません — だから何をスコアリングするかを定義しましょう：

  • タスク成功率
  • ツール使用品質
  • 軌跡コンプライアンス
  • 幻覚率
  • 応答品質

CIゲートが実際のものにします：

# ci: block merge if the agent's eval suite regresses
agent-evals:
  run: eval-suite --rubric rubric.yaml --min-score 0.9
  on: [pull_request]
  required: true

生成コードのためにコードレビューを再設計する​

生成コードは人間のコードと同じ、あるいはそれ以上の精査が必要です — そしてレビュワーはその特定の障害モードを知る必要があります。幻覚された依存関係、薄いエラー処理、一見問題ないように見える正確性のギャップ（パート5）を探すよう訓練しましょう。変更なしに古い人間コードのチェックリストを再利用するのではなく、それらのパターンに合わせてレビューチェックリストを調整しましょう。

プロトタイプ/本番の境界線を明示する​

素早く大雑把な探索と規律ある本番作業はどちらも有効です — ただし、誰もがどちらか分かっているときに限り。境界線を明示しましょう：

  • どのリポジトリが本番でどれがサンドボックスか。
  • どのブランチが完全な規律を必要とするか。
  • エージェントのアウトプットがどの環境に到達できるか。

この境界線を曖昧にしたままにするチームは、意図せずプロトタイプをリリースします。書かれた境界線は、探索を速く、本番を安全に同時に保ちます。

ハーネスを一度構築し、何度も改善する​

再利用可能なプロンプト、スキルライブラリ、ツール接続、エバリュエーションハーネスは、プロジェクトをまたいで複利で効きます。AI開発から最も多くを得ているチームは、この共有ハーネスを一度構築して改善し続けるチームです。各人がゼロから自分のものを再構築するのではなく。インフラとして扱いましょう：ドキュメント化され、保守され、意図的に改善されるものとして。

判断力のある人材を採用・昇進させる​

実装が安くなるにつれて、ボトルネックは仕様、評価、アーキテクチャ上の判断に移ります。これからの数年間で最も価値あるエンジニアは、エージェントをうまく指示できる人々です — 最もコードを入力できる人々ではありません。採用、レベル評価、人材育成でそれを反映させましょう：実装速度よりも仕様スキル、評価の厳密さ、システム設計を重視してください。

最も強力なセットアップは設計によってハイブリッドです：人間が方向を設定し、エージェントが実装し、明確な引き渡しプロトコルが境界を管理します。コードレビュー、オンコール、チーム構造はすべて、エージェントをただのツールではなく参加者として扱うように進化します。

自分のワークフローをセットアップする​

  • ルールファイル、プロンプト、エバリュエーション、スキルをリポジトリに移し、変更にはPRレビューを要求する。
  • 共有ハーネスのオーナーを割り当てる。
  • エバリュエーションスイートが閾値を下回ったときにマージをブロックするCIゲートを追加する。
  • 生成コードの障害モードのための1ページのレビューガイドを書く。
  • プロトタイプと本番の境界線を文書化する：リポジトリ、ブランチ、環境。
  • 次の採用ループで、コーディングテストだけでなく仕様と評価のエクササイズを追加する。

出典：The New SDLC With Vibe Coding（Google）— https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding