AI時代の開発体制論 — 人から人へのプルリクはもう要らない

FableとOpusをフル活用した開発を続けるなかで、4つの違和感が出てきました。人から人へのプルリクが非効率になった。AIに渡すタスクの塊がアプリ単位・機能群単位まで大きくなった。コードのデバッグが消え、やるのは最終ユーザーとしての動作チェックだけになった。そして、1人で進めるのは簡単なのに、チームになると難しい。

この4つは同じ一点を指しています。難しさの正体は「コードの粒度で人間同士が同期すること」です。この資料では、チームで共有するものをコードから「設計・接続ルール・受け入れ基準」に移し、チームを「並列するソロ開発者の集合＋接続ルール」として再定義する体制を、体制（人とAIの役割分担）・設計（任せても壊れない仕組み）・実行（1ボックスから始める3段階と4つの指標）の3部構成・13枚にまとめました。

AI推論を入れない処理の見極め、AIが時々後退することへの劣化防止策、判断と失敗を溜めるナレッジループ、そして「人がコードを読まない」を成立させるトリアージ型AIレビューまで含んでいます。bajji（16人のAIネイティブスタートアップ）で実際に運用する前提で書いた叩き台です。自社で試す方の参考になれば幸いです。

Transcript

1. AI 時代の開発体制 人から人へのプルリクは、 もう要らない ▶ Fable / Opus をフル活用した開発体制 ̶ 体制・設計・実行の3部構成 小林 慎和 2026年9月 bajji, Inc.
2. 01 Before / After ① 体制（人とAIの役割分担） Before 人間だけの開発 同期の単位 コード（人→人のプルリク） After AI（Fable / Opus）フル活用 仕様・接続ルール・受け入れ基準 コードは人がレビューしない アプリ単位・大機能群単位 タスクの粒度 チケット単位・関数単位 人間の仕事 実装・デバッグ・コードレビュー 最初の設計／境界の合意／最終ユーザーとしての動作チェック チームの形 分担して1つのコードを共同で編集 並列するソロ開発者の集合＋接続ルールのレビュー 1人が1ボックスを丸ごと所有 ▶ チームでコードを共有する時代から、設計・接続ルール・受け入れ基準を共有する時代へ
3. 02 Before / After ② 設計（任せても壊れない仕組み） Before 人間だけの開発 品質ゲート AIに任せる線引き 劣化への対処 学びの蓄積 人のレビューと手動テスト 設計判断なし。AIは補助ツール 人の記憶とレビューで気づく 個人の経験と口伝 After AI（Fable / Opus）フル活用 CI（型・lint・テスト・E2E）＋別セッションのAIレビュー 決定論・検証可能・責任・コストの4軸で先に線を引く 真ん中の処理系にAI推論は入れない 受け入れテストの資産化・差分ゲート・スナップショットで機 械が検出 decision-log → 週次蒸留 → ルール改訂。人が同期するのはコ ードでなく判断履歴 ▶ 「良いコードを人が守る」から「任せる範囲を線引きし、仕組みで守り、学びをルールに溜める」へ
4. 03 全体像：体制・設計・実行の3部構成 第1部 04 共創の体制 05 全体像 並列ソロ＋接続ルール 06 人の仕事 設計・境界・動作チェック 運用リズム 週次デモ・接続変更会 人とAIの役割分担 接続ルール 体制ではボックスを分ける単位、設計ではAIが越えてはいけない線。全体を貫く唯一の共有物 第2部 任せるための設計 07 08 線を引く 09 守る → AI推論を入れない処理の見極め 学ぶ → 劣化防止 ナレッジループ 体制を壊さない仕組み 第3部 実行計画 10 具体例 予約完了機能を1ボックスで 11 移行 3段階ロードマップ 12 指標 健全性を測る4つ どう始めて何で測るか ▶ 上が「誰が何をやるか」、中が「任せても壊れないか」、下が「どう始めて何で測るか」 13 リスク 反論と対処
5. 04 並列するソロ開発者 ＋ 接続ルール 第1部 共創の体制 人がやる AI・機械がやる 共有層（人がレビューする唯一のもの） 仕様書 ／ 接続ルール（API・スキーマ・イベントの境界） ／ 受け入れテスト ／ ルール体系 （CLAUDE.md・decision-log） ボックス A ボックス B ボックス C ボックス D … アプリ／機能群 アプリ／機能群 アプリ／機能群 アプリ／機能群 最大10前後 接続 接続 接続 接続 • 所有者1人：設計・動作チェック • 所有者1人：設計・動作チェック • 所有者1人：設計・動作チェック • 所有者1人：設計・動作チェック • 所有者1人：設計・動作チェック • Fable/Opus：実装・テスト • Fable/Opus：実装・テスト • Fable/Opus：実装・テスト • Fable/Opus：実装・テスト • Fable/Opus：実装・テスト 設計 → 生成 → 動作チェック 設計 → 生成 → 動作チェック 設計 → 生成 → 動作チェック 設計 → 生成 → 動作チェック 設計 → 生成 → 動作チェック 機械層（人は介在しない） PR は AI → CI への提出物。型・lint・テスト・セキュリティ・E2E をマージ条件に、別セッション／別モデルの AI レビューを1段挟む コンウェイの法則の逆用：ボックス間は接続ルールでしか繋がらない構造にすれば、「1人なら簡単」を並列に並べただけになる ▶ 難しさの正体は「コードの粒度で人間同士が同期すること」。同期対象を上下の層に移す
6. 05 人間の仕事を3つに絞る ① 最初の設計 ② 第1部 共創の体制 境界の合意 ③ 動作チェック 成果物：仕様書 成果物：接続ルール 成果物：受け入れテスト 何を作るか、どのボックスに切るかを決め API・スキーマ・イベントの境界を定義。 最終ユーザーとして触って合否を出す。受 る。ここが最も価値が高く、AIに委ねられ ボックス間が繋がる唯一の接点なので、こ け入れテストの記述自体はAIに書かせ、人 ない工程 こだけ人の承認（PR文化）を残す はそれを承認する AI と CI が担う中間工程 人がやらないこと（意識的に捨てる） 実装 → テスト生成 → 別セッションAIレビュー → 修正ループ → CI合格 → マ コードを読まない ／ デバッグしない ／ AIの途中経過を見ない ／ 実装方針に口 ージ を出さない ／ 他ボックスの中身に触らない それでも人の判断に残るもの（AIの根拠がどれだけ強くても） テストが無いままリリースするか ／ デプロイ中の停止を許容するか ／ 権限・公開範囲を広げるか ／ 取 り消せないデータ変更を通すか ／ 継続的に増える費用を負担するか。事実確認はAI、許容の判断は人 ▶ 中間工程（実装・デバッグ・コードレビュー）は AI と CI が回す。人は入口・境界・出口だけ
7. 06 1 運用ルールと導入時の留意点 同期のリズム 2 品質ゲートは機械に置く 3 接続ルールの変更だけ PR を残す 4 生産性差への対策 第1部 共創の体制 日次スタンドアップは廃止。週次デモ（動くものを見せる会）と、接続ルールを変える時だけ集まる接続変 更会の2種類のみ マージ条件は CI。AI が書いたものを AI がレビューする段を、別セッション・別モデルで1段挟む（文脈が 溜まるほど味方バイアスが増えるため） 境界を勝手に変えると並列が壊れる。ここだけ人が承認する AI主導に慣れた人とそうでない人で10倍以上の差が出る。プロセス設計より研修期間の方が効く。bajji 16 人ならボックス数は10前後に抑える ▶ 体制設計より先に、全員を「ボックス所有者」として自走できる水準に引き上げる
8. 07 AI 推論を入れない処理の見極め 第2部 任せるための設計 判定の4軸：ひとつでも Yes なら AI なしの処理系に置く 決定論 同じ入力に同じ出力が必要か 検証可能 責任 コスト・遅延 正解が定義でき、テストで証明でき 金額・権限・法務など間違いが許さ 高頻度・大量・低遅延が求められる るか れないか か 処理系（AI なし）に固定するもの AI 推論に任せてよいもの（入口と出口だけ） • 計算・集計・課金・ポイント付与 • 自然言語・音声・画像など非定型入力の理解 • データ変換・整形・マイグレーション • ルールで書ききれない曖昧な分類・意図推定 • バリデーション・権限判定・認証 • 文章・提案・要約の生成 • スケジューリング・通知の発火条件 • 探索的な分析・仮説出し • ルールで書ける分類・フィルタ・ソート ── ただし出力は必ず処理系のスキーマで受け、検証してから流す • 監査ログ・冪等性・リトライ制御 設計原則：AI は境界（理解と生成）だけ。真ん中のデータ処理は決定論的なコードで固め、AI 推論の呼び出し箇所は仕様書に明記して数を管理する ▶ AI に「書かせる」コードと、AI が「実行時に判断する」コードは別問題。後者は最小に絞る
9. 08 劣化防止：AI は時々後退する 第2部 任せるための設計 なぜ後退するか AI は「今回のタスク」に最適化し、既存の動作を守る動機を持たない。文脈が溜まるほど既存コードを正として扱い、静かに仕様を書 き換える 1 受け入れテストを資産化 2 既存動作のスナップショット 3 差分ゲート 人が合格を出した動作チェックはそのまま自動テ 画面・APIレスポンス・DBスキーマの現状を固 変更行数・触ったファイル数の上限、タスクと ストに変換し、リグレッションスイートに積む。 定。差分が出たら「意図した変更か」を必ず人 無関係なファイルの変更は自動で拒否。「ついで 一度通ったものは二度と人が確認しない に問う に直した」を許さない 接続ルールの自動検証 5 4 AI レビューはトリアージで出す 6 小さく出して戻せる 境界のテストを別リポジトリに置き、ボックス 指摘の列挙ではなく「判断が要る／見なくてよ 機能フラグと段階リリース。後退が本番で出ても 側の変更では書き換えられない構造にする。仕 い（根拠の型＋path:line）／未確認」に仕分 即ロールバックできる前提で回す 様書やPR本文の誤りはAIが引き継ぐので、正は け。根拠が「読んでそう思った」だけなら未確認 実環境とテスト へ。人は判断が要る2〜4件だけ読む 参考：DevelopersIO 及川正基「実装が AI に移ったあと、レビューで人間に残る判断は何か」（2026.08） ▶ 後退は「気づく仕組み」がなければ検出できない。人の記憶ではなく、テストと差分ゲートに守らせる
10. 09 1 ナレッジループ：設計から体制へ戻す 2 動作チェック 不具合・違和感・仕様のズレを人 が発見 → 3 decision-log なぜそう判断したか／何が壊れた かを記録（Stop hook で催促） → 第2部 任せるための設計 4 週次蒸留 headless Claude が log を読 → み、ルール改訂 PR を提案 ルール体系の更新 人がマージ。憲法は削る方向の み、条例は30行以下を維持 次の生成に反映（CLAUDE.md・rules が全ボックスの前提になる） 何を溜めるか コードは溜めない。溜めるのは「判断（なぜ）」「失敗（何が後退したか）」「接続ルールの変更履歴」の3つ 誰が回すか ボックス所有者は log を書くだけ。蒸留と PR 提案は AI、マージ判断は人。人の負担は週30分に抑える 劣化を防ぐ ルールは増やすと守られなくなる。追加1件につき1件削るか統合する。効かなかったルールは判例として残し、法令からは外す ▶ 溜めるのはコードではなく「判断と失敗」。ループが回らない体制は、同じ後退を毎週繰り返す
11. 10 具体例：予約完了機能を1ボックスで 第3部 実行計画 仕様書（人） 接続ルール（人が承認） 受け入れテスト（人が合格を出す） サロン会員が LINE から空き枠を選び予約を確定 POST /reservations（会員ID・店舗ID・枠ID・ ①空き枠を選んで確定できる ②同じ枠の二重予約 する。対象：CS Inc. 200店舗。ホットペッパー メニュー）→ 予約ID。イベント が弾かれる ③確定後に LINE 通知が届く ④店舗 経由を自社導線へ置換。予約データは bajji が所 reservation.confirmed を発行。店舗マスタと空 側の管理画面に即時反映 ⑤キャンセルで枠が戻る 有し Realogue の対話解析に接続 き枠は既存 API を読むだけで書かない 処理系（AI 推論なし） AI 推論（入口と出口だけ） Fable/Opus が回す工程 枠の空き判定・二重予約ロック・料金計算・通知 会員の自由文「来週の夕方でカットとカラー」→ 実装 → 単体・E2E テスト生成 → 別セッションレ の発火条件・権限チェック。すべて決定論的コー 候補枠の抽出。確定後の案内文生成。出力は必ず ビュー → CI → マージ。差分ゲート：予約以外の ドで固め、テストで証明する 接続ルールのスキーマで受けて検証 ファイル変更は自動拒否 ▶ 人が書くのは上の3枚だけ。下は仕組みが回す。この1枚がボックス所有者の「仕事の全量」
12. 11 移行ロードマップ：3段階 第3部 実行計画 Phase 1 Phase 2 Phase 3 パイロット（1ボックス・1人） 仕組みの整備（2〜3ボックス） 全ボックス展開（〜10ボックス） 10 の予約完了機能を1人のボックス所有者で CI ゲート・差分ゲート・別セッション AI レビ 研修を経た全員がボックス所有者に。使わなく 完走。仕様書・接続ルール・受け入れテストの ュー・接続ルールの自動検証を全ボックス共通 なったプロジェクトの仕分けと統合を同時に実 雛形をここで作る 基盤として整備。週次蒸留を開始 施 → → 完了条件：人がコードを読まずにリリースでき 完了条件：接続ルール変更が PR で回っている 完了条件：12 の4指標が四半期で改善／人が た／受け入れテストが自動テストに変換された ／後退が本番前に1件以上検出された／週次デ コードを読む時間がゼロに近い／ボックス数 ／decision-log が10件以上溜まった モが2回連続で成立 10 ▶ 一気に全員を変えない。1ボックスで型を作り、仕組みを固めてから広げる
13. 12 体制の健全性を測る4つの指標 1 2 3 4 リードタイム 人がコードを読んだ時間 後退の検出率 接続ルールの変更頻度 仕様確定 → 週次デモまでの日数 ボックス所有者の週あたり時間 検出件数 （検出＋本番流出） 週あたりの接続変更 PR 数 短くなるほど、AI に任せられてい ゼロに近づくほど正しい。増えて 検出件数がゼロなのは守れている 多すぎれば境界の切り方が悪い。 る。伸びるなら仕様か接続ルール いるなら「捨てる」ができていな 証拠ではなく、見えていない証拠 ゼロなら硬直。適正帯を決めて監 に問題 い Before：週〜月 標：日 → After 目 Before：週の半分 目標：ほぼゼロ 第3部 実行計画 視 → After 目標：本番流出ゼロ、検出は月数 件あって正常 ▶ 「良くなった」を印象で語らない。4つの数字が同時に良くなって初めて、体制が機能している 目標：ボックスあたり月1〜2件
14. 13 想定される反論とリスク ボックス所有者の属人化 接続変更会が実質日次になる AI 生成コードのセキュリティ責任 トークンコストの上限 AI 主導に慣れない人の処遇 休んだら止まる、辞めたら消える 第3部 実行計画 ▶ 仕様書・接続ルール・受け入れテスト・decision-log が揃っていれば、別の人が同じ AI で再生成 できる。属人化するのはコードではなく判断で、それを log に落とすのが 09 境界の切り方が悪ければ毎日集まる羽目 ▶ Phase 1 で切り方の型を作る。変更頻度は 12 で監視し、閾値を超えたら会議を増やすのではな に くボックスを切り直す 誰も読んでいないコードが本番にある 並列させるほど請求が膨らむ 10倍差が開くと組織が割れる ▶ 読まない代わりに、セキュリティスキャンと権限チェックを CI で必須化。処理系（07）に AI 推 論を入れないことで、攻撃面を境界だけに限定する ▶ ボックスあたりの月額上限を設定し、12 の指標と並べて見る。人件費との比較で判断し、上限に 当たるなら粒度を見直す ▶ 研修期間を体制構築より先に置く（06）。ボックス所有者以外に「接続ルールの番人」「受け入 れテストの設計者」という役割を用意する ▶ 反論はすべて実在する。「わかったうえで進める」を示すための1枚
15. 14 自己紹介 bajji, Inc. 16人のAIネイティブスタートアップ。資本金1億円。 受賞 Google Play Best of 2020 大賞 ／ 超DXサミット最優秀賞 ／ IBM BlueHub賞 社外取締役 日本M&Aセンターホールディングス（東証プライム） 福祉 障害児童のための福祉施設を運営 小林 慎和 Noritaka Kobayashi bajji, Inc. 代表取締役 AIオーケストレーター 小説家（筆名・坂本一朗） 農家 マラソンランナー 野村総合研究所（M&Aアドバイザリー）→ GREE シンガポール → シンガポール 経歴 で起業 → 日本初のICO。登録暗号資産交換業、Exit→ bajji。起業15社、Exit 2 社、累計調達約40億円 @noritaka88ta 学歴・著作 ▶ この資料の体制は、bajjiで実際に回している体制です。 大阪大学 博士（工学）／ コロンビア大学 EMBA ／ 著書5冊 ／ BBT大学元教授