本記事は連載 「AI駆動開発実践シリーズ」 の第2回です。#1（バイブコーディングとAI駆動開発は何が違うのか）では、個人開発でバイブコーディングから spec駆動へ舵を切った話を書きました。今回はその型を 組織（チーム） へ広げます。

はじめに ― なぜ「組織で」を確かめに行ったのか

#1で書いたとおり、個人開発では、AI駆動開発の効果を自分の手で証明できました（半年で14本）。そこで次に湧いた問いが、これです。

個人では速い。でも、組織（チーム）でも成り立つのか？企業に求められる品質は担保できるの？

それを確かめるために、AWS社が主催するAI駆動開発イベント（3日間の対面形式） に、6人チームのプロジェクトマネージャー（PM） として参戦しました。複数チームが競う中で、幸運にも MVP（最優秀） をいただけました。そして、組織でのAI駆動開発は既に成り立つことが証明されました。
今回は、組織でAIを回すための"型" を、この記事にまとめます。

（※参加企業名や社内情報、扱った実データは出しません。サンプルはすべて公開用に汎用化しています）

大原則：流れは「AIなし」の開発と同じ

最初に、一番大事な前提です。

AI駆動開発でも、基本の流れは従来の開発と変わりません。 企画 → 要件定義 → 設計 → 実装 → テスト。ここに AIを差し込んで加速させるだけ です。

やってはいけないのは、「AIだから、この工程は省いていい」 という発想です。要件定義も、設計も、レビューも、テストも省きません。個人なら勢いで乗り切れても、チームでは省略が即・事故になります（認識のズレ、デグレ、手戻り）。

AIはあくまで「速くする道具」。速くなるぶん、プロセスの規律はむしろ従来より重要になります。ここが、個人のバイブコーディングと組織のAI駆動開発の、最初の分かれ目です。

ただし、「省かない」＝「全部を重くする」ではありません。変更のリスクと複雑さ、AIの作業品質に応じて、レビューやゲートの"厚み"は変えます。AWSのAI-DLCも、複雑な変更は手厚く、単純な変更は軽量に、と適応します（Risk-based）。低リスクな変更にまでフルの重厚プロセスを課さない——このメリハリが、速さと品質を両立させます。

複数人で開発するためのポイント

さて、ここで問題です。個人と組織のAI駆動の一番の違いは何でしょうか？
答えは「一人で開発するか」、「複数人で開発するか」です。笑
重要なのは「チームで決めるべきこと」と「担当範囲を明確にすること」です。

チームで決めること（要件定義〜基本設計の横断標準）＝全員で「読み合わせ」

アーキテクチャ方針・データの持ち方・命名規約・非機能といった 横断的な標準 は、分担しません。ここがズレると、後半で全部崩れるからです。

では、どうやるか。答えはシンプルで、みんなで読み合わせるだけです。

AIに指示を出す「メインファシリテーター」を1人だけ決める。
その人が画面を共有し、AIが生成した要件・設計を、全員で上から順に声に出して読み合わせる。
「ここはこういう意味だよね」「この命名でいい？」を、その場で全員合意で確定していく。

AIは要件定義書や設計書を一瞬で書きます。でも、その一瞬の成果物を全員で承認する場を最上流に作ることで、認識のズレを一番安いところで潰せます。

担当範囲の明確化（基本設計〜実装）＝役割分担＋ガードレール

横断標準が固まったら、まず設計を 「並列に開発できる単位」に割ります。「AIは速い」を最大限活かすには、依存の少ない単位に分解して、複数の担当が同時に走れるようにしておくのが効きます。その上で、各単位に役割分担を明確に定義し、ガードレールを引きます。

ガードレールとは、AI（と人）が、他人の担当領域を勝手に触らないための境界です。AIは文脈が広いと「ついでに直しておきました」を平気でやります。これがチームでは事故のもとです。例えばワークショップでは、システムを 領域（OCR処理・画面・テスト品質…）に分割し、各領域にオーナーを立てました。

役割定義は「2種類」いる

ここが組織ならではのポイントです。AI×人 だけでなく、人×人 の役割定義も必要です。どちらか一方でも曖昧だと、AIも人も"越境"して事故ります。

① AIと人の役割定義（何をAIに任せ、何を人が持つか）

工程・成果物	AIがやる	人がやる（レビュー・承認）
要件定義書	初稿ドラフトの生成と指摘の取り込み	妥当性の判断・優先度決定・承認
基本設計	初稿ドラフトの生成と指摘の取り込み	妥当性の判断・レビュー指摘の起票・承認
実装コード	生成＋自己チェック	実装前にコード規約・設計との整合をサブエージェント化
テスト	ケース・エビデンスの生成	網羅性・妥当性の判断

要は、生成はAI、意思決定と承認は人。ここを言語化しておくだけで、迷いが激減します。

② 人と人の役割定義（誰がどの領域のオーナーか）

領域	オーナー	触ってよい範囲	やってはいけないこと
横断標準（アーキ・データ・命名）	標準化チーム	標準の定義・更新	各領域の実装詳細に口を出す
インフラ	インフラ担当	インフラのフォルダ配下	他領域の変更
OCR処理	OCR担当	OCRのフォルダ配下	他領域の変更
画面	画面担当	画面のフォルダ配下	他領域の変更
バッチ	バッチ担当	バッチのフォルダ配下	他領域の変更
テスト品質	テスト担当	テストのフォルダ配下	プロダクト仕様の変更

AIは「提案」、人は「承認」 ― 各工程に承認ゲートを置く

役割定義とセットで効くのが 承認ゲート です。AI駆動の中核原則のひとつが「エージェントは提案する。重要な意思決定は、人が明示的に承認する」。組織では、これを"制度"として置きます。

各工程（要件・設計・実装・テスト）に"人の承認"を通過条件にする。承認しないと次工程へ進めない。
AIが出す → 人が読んでOK/修正を明示 → 承認できたら次へ。「なんとなく良さそう」で流さない。
承認した人が責任を持つ、を明確にする。

AIは一瞬で大量に進みます。だからこそ"止めどころ"を仕組みで置かないと、気づけば誰も中身を把握していない、が起きます。提案はAI、承認は人。これが組織ガバナンスの背骨です。

ガードレールは「機械的に」効かせる

「気をつけましょう」では守られません。宣言 → 所有 → 自動検査 の3層で、機械的に止めます。

(1) 担当宣言（各フォルダに置く CLAUDE.md）

作業セッションの担当を、フォルダ自身に書いておきます。

# OCRフォルダ/CLAUDE.md（この作業の担当宣言）
このセッションの担当は「OCR処理」だけ。
- 変更してよいのは OCRフォルダの中だけ。
- 画面・テストのフォルダは「読むだけ（変更禁止）」。
- 横断標準のフォルダは変更禁止。必要なら標準化チームに依頼する。

(2) 所有者の宣言（CODEOWNERS）

どのフォルダを誰が責任者とするかを、リポジトリに明記します。

# CODEOWNERS（フォルダごとの責任者）
/ocr/        @OCR担当
/画面/        @画面担当
/test/       @テスト担当
/標準/        @標準化チーム   ← 横断標準は標準化チームだけが変更できる

(3) 自動検査（CIで境界違反を弾く）

担当フォルダの外を触った変更は、CIで機械的に落とします。

# 担当フォルダ外の変更を自動で弾く（イメージ）
- name: 担当領域チェック
  run: |
    変更ファイル一覧=$(git diff --name-only origin/main...)
    # OCR担当の変更が「OCR」「共通ドキュメント」以外を触っていたら失敗させる
    if echo "$変更ファイル一覧" | grep -vqE '^(ocr/|docs/)'; then
      echo "担当領域の外を変更しています"; exit 1
    fi

この3層があると、人のうっかりも、AIの"ついで直し"も、両方止まります。これで初めて、複数人＋複数AIを安心して並走させられます。

組織で回すための「標準化」の仕組み

個人と組織の最大の違いは、「誰がやっても同じ品質」になるを作れるかどうかです。鍵は4つです。

① ドキュメントは必ずリポジトリ（Git等）で共有する
唯一の正本・差分・レビューをチームで回します。個人のローカルやチャットに設計書が散らばると、AIも人も「どれが最新か」で迷い、すぐ破綻します。

② 設計書・テストチェックリストの「型」を先に決め、スキル化する
フォーマットと記載レベルを事前に定義し、スキル（skill） として登録しておきます。すると「誰が書いても同じ章立て・同じ粒度」になります。

# 「設計書作成」スキル（skills/設計書作成/SKILL.md）
名前: 設計書作成
説明: 基本設計書を、決められた章立て・記載レベルで作成する
使う場面: 設計フェーズで設計書を新規作成・更新するとき
手順:
  1. ドキュメント索引(00_index.md)を読み、対象領域の既存設計を確認する
  2. 下のテンプレの全章を必ず埋める（空欄は禁止）
  3. データモデルを変える場合は「データモデル設計書」を先に更新する
テンプレの章立て:
  - 1. 目的 / スコープ
  - 2. 全体構成（図）
  - 3. データモデル（スキーマ / 移行方針）
  - 4. 入出力・API（正常系・エラー）
  - 5. 非機能（性能・セキュリティ）
  - 6. テスト観点への申し送り
チェックリスト:
  - [ ] 既存の命名・アーキ標準に沿っている
  - [ ] 破壊的変更なし（あれば影響範囲を明記）

スキル化するのは設計書だけではありません。テストチェックリスト・レビュー観点・命名規約・コミットメッセージ…と、繰り返す作業はどんどんスキルにしていきます。

③ 規約チェック・テストエビデンス確認は「サブエージェント」にやらせる
人がレビューする前に、機械が一次チェックします。

コード規約チェック担当（サブエージェント）：命名違反・レイヤ違反・禁止APIなどを自動で指摘する。
テストエビデンス確認担当（サブエージェント）：チェックリストの各項目に、証跡（ログ・結果・スクリーンショット）が揃っているかを確認する。

人は「機械が通した後」の、判断が要る部分に集中できます。

④ スキルとサブエージェントは「標準化チーム」が一元管理する
各開発チームは、標準化チームが用意したスキルとサブエージェントを "使うだけ"。これで属人化を防ぎ、組織全体の品質を底上げできます。個人開発で自分用に作っていた"型"を、チーム共有の資産に格上げするイメージです。

この標準化には2つの原則があります。 ひとつは 「正本は一箇所」（同じ内容を複数ファイルに増やさず、派生物は正本から生成する）。もうひとつは 「再現性」——ルールは、担当者やAIモデルが違っても同じ結果になるくらい、明確に書く。曖昧なルールは人差・モデル差でブレを生むので、標準化とは、この"ブレ"を潰す作業でもあります。

ここまで来るとわかったと思います。やってることはAIがない時と一緒です。ポイントはAIに任せる範囲を明確にすることです。

AI生成コードには「必ず通す」セキュリティゲートを置く

#1で触れたとおり、AIが生成したコードは、人が書いたものより脆弱性を含みやすい傾向があります。個人なら自己責任で済みますが、組織では必ず通す自動ゲートにしておくのが安全です。

具体的には、次を CI の通過条件にします。

シークレット検出（APIキー・パスワードの混入を止める）
SAST（静的解析）（インジェクションなどの危険パターンを検出）
依存ライブラリの脆弱性スキャン（使用中ライブラリのCVEを検出）

エンタープライズな開発では、セキュリティ・コンプライアンス・回復性などを"拡張ルール"としてコアの流れに重ね、各段階のブロッキング条件にできるようにしておくと良いでしょう。組織では「満たすまで進めない」を、人の善意ではなく仕組みで担保します。

スピードが上がるほど、"人と人"が効く（AI駆動は「対面」でこそ）

これは、今、一番強く実感していることです。

AI駆動開発は、とにかく速い。 設計から実装まで、待ち時間がほぼ消えます。すると、ボトルネックは技術ではなく 人と人のコミュニケーション に移ります。判断やすり合わせが1つ詰まると、その先に進めず、時間のロスが発生してしまう。

今はリモートワークが当たり前です。でも、AI駆動開発は"対面で集まってこそ"力を発揮する、というのが私の実感です。チャットや定例会議は、この速度に対して遅すぎる。「返信待ち」「次回の定例まで持ち越し」が、致命傷になります。

必要なのは、課題が出たその場で、すぐ相談できる環境です。全員が同じ場所にいて、詰まった瞬間に「ちょっといいですか」で解決できる環境作りも設計の一つです。AI駆動の立ち上げ期ほど、対面・同期の密度を意識的に上げることをおすすめします。

これらを AI-DLC の流れに乗せる

ここまでの工夫（読み合わせ・ガードレール・役割定義・標準化・対面）を、従来の開発手法の流れ に組み込むと、スピードとガバナンスが両立します。速さで事故らないための"重し"が、ちょうど良く効く感覚です。

まとめ

組織のAI駆動開発は「従来プロセス＋ AIで加速＋規律」。工程の省略ではなく 標準化 が肝。
上流は全員で読み合わせ、下流は役割分担＋ガードレール（宣言→所有→自動検査で機械的に守る）。
役割は AIと人／人と人 の両方を定義する。
各工程に承認ゲート（提案はAI・承認は人）。AI生成コードはセキュリティスキャンを必須ゲートにする。
工程は省かないが、リスクに応じてレビュー・ゲートの厚みを変える。
ドキュメントはリポジトリ共有、フォーマットはスキル化、チェックはサブエージェント化、それらを標準化チームが管理する。
そして、速いからこそ人と人の距離が効く。立ち上げ期は対面・同期を厚くする。

個人で証明したAI駆動開発は、規律と標準化と対面を足せば、組織でも十分に成り立ちます。そして、そのスピードは個人とは比較にならないくらい速くなります。

次回予告（#3）：「複数セッション×サブエージェントで作るAIプロジェクト体制」。本記事で触れた"役割分担・標準化"を、実際に Cowork とサブエージェントでどう構成するのか、実装レベルで書きます。更新に気づけるよう、フォロー・ストックしておいてもらえると嬉しいです。