AI時代の「一人開発」とバス係数問題：レビューアーが即座に引き継げる体制は必要か

• 想定読者: エンジニアリングマネージャー、テックリード、一人または少数で開発を担当するエンジニア
• 前提知識: Git、コードレビュー、CI/CDの基礎知識
• 所要時間: 約12分

---

概要

AIコーディングアシスタントの進化により、一人で高い生産性を発揮できる時代が到来しました。しかし、DORA 2025レポートが示すように「AIはチームを修正するのではなく、既にあるものを増幅する」¹のであれば、一人開発体制の脆弱性もまた増幅されるのではないでしょうか。

本記事では、AI-Nativeエンジニアリングチームの構築で解説したSDLCの変革と、組織レベルでの課題と対策で提示したコードレビュー体制を踏まえ、「バス係数」という組織リスクの観点から、一人開発体制のあり方を考察します。

---

「AIは増幅器」がもたらす一人開発の光と影

生産性の増幅

AI-Nativeエンジニアリングチームの構築で解説したように、AIコーディングエージェントはSDLCの全フェーズで開発者を支援します。OpenAI内部（エンジニアの92%が使用）では週あたりのPRマージ数が70%増加²、GitHub Copilotの制御実験では55.8%の速度向上³が報告されています。

これにより、従来はチームが必要だった開発作業を一人で完遂できるようになりました。

リスクの増幅

しかし、DORA 2025レポートの核心的メッセージを思い出してください：

“AI doesn’t fix a team; it amplifies what’s already there.” （AIはチームを修正するのではなく、既にあるものを増幅する）¹

これは、一人開発体制の脆弱性もまた増幅されることを意味します。

flowchart TB
    subgraph Amplification["AIによる増幅効果"]
        direction TB
        Good["生産性の増幅<br>（一人で多くの成果）"]
        Bad["リスクの増幅<br>（一人への依存度上昇）"]
    end

    subgraph Result["結果"]
        direction TB
        R1["高い個人生産性"]
        R2["バス係数1"]
        R1 --- R2
    end

    Good --> R1
    Bad --> R2

---

バス係数問題：AI時代の新たな側面

バス係数（Bus Factor）とは、「何人のチームメンバーが突然いなくなったらプロジェクトが危機に陥るか」を示す数値です⁴。バス係数1は、チーム内に単一障害点（SPOF）が存在することを意味します。

AI時代には、従来の属人化リスクに加えて以下が追加されます：

新しいリスク	説明
サイロ化したAI知識	個人が最適化したプロンプト、AGENTS.md設定が共有されない5
AI出力への過信	「AIが書いたから大丈夫」という心理的距離感1
高生産性の罠	一人で多くのことができるため、知識共有の必要性を感じにくい

---

全レベル共通：共有基盤の整備

どのプロジェクトでも、以下の「共有基盤」は整備してください。 これが引き継ぎ可能性の土台となります。

flowchart TB
    subgraph Foundation["共有基盤（全レベル共通）"]
        direction TB
        F1["README.md<br>環境構築手順"]
        F2["AGENTS.md/CLAUDE.md<br>AI設定の標準化"]
        F3["技術スタックの明文化"]
        F1 --- F2 --- F3
    end

    Foundation --> L1["レベル1"]
    Foundation --> L2["レベル2"]
    Foundation --> L3["レベル3"]

最低限必要なドキュメント

ドキュメント	内容	工数目安
README.md	環境構築手順、基本的なアーキテクチャ	2-3時間
AGENTS.md/CLAUDE.md	AI設定、コマンド、プロジェクト構造	1-2時間
技術スタック一覧	言語、フレームワーク、インフラ	30分

AGENTS.mdの基本構成

AI-Nativeの記事で解説したAGENTS.mdは、引き継ぎ可能性を高めるツールとしても機能します⁶：

# AGENTS.md

## Commands（コマンド）
npm test              # テスト実行
npm run build         # ビルド
npm run deploy:staging # ステージングデプロイ

## Project Structure（プロジェクト構造）
src/
  ├── components/   # UIコンポーネント
  ├── services/     # ビジネスロジック
  └── api/          # API層

## Code Style（コードスタイル）
- 命名: camelCase（変数）、PascalCase（コンポーネント）

---

プロジェクト規模に応じた体制の選び方

共有基盤を整備したら、プロジェクトの性質に応じて追加の対策を選択します。

flowchart TB
    Start["プロジェクト開始"] --> Base["共有基盤の整備<br>（全プロジェクト必須）"]
    Base --> Q1{"期間は<br>3ヶ月以上？"}
    Q1 -->|No| L1["レベル1<br>最小限対策"]
    Q1 -->|Yes| Q2{"ビジネス<br>クリティカル？"}
    Q2 -->|No| L2["レベル2<br>標準体制"]
    Q2 -->|Yes| L3["レベル3<br>フル体制"]

レベル1: 最小限対策（短期・実験的プロジェクト）

対象： 3ヶ月以内、プロトタイプ、実験的開発、即座に再構築可能なシステム

共有基盤に加えて：

対策	工数	内容
コードへのコメント	都度	複雑なロジックへの説明

体制イメージ：

開発担当（1名）+ AI → 共有基盤 → 誰でも参照可能

引き継ぎ時間目安： 1-2週間

---

レベル2: 標準体制（中期・通常の業務システム）

対象： 3ヶ月〜1年、社内システム、中程度の重要度

レベル1に加えて：

対策	工数	内容
定期レビューアーの設置	週1-2時間	別プロジェクト兼務でOK
ADR（設計判断記録）	都度15-30分	重要な意思決定を記録
月1回のコードウォークスルー	月30分	レビューアーへの知識共有

体制イメージ：

flowchart TD
    Dev["開発担当者 + AI"] -->|"PR"| R1["レビューアー<br>（兼務可）"]
    R1 -->|"承認"| Dev
    Dev --> Shared["共有基盤<br>README / AGENTS.md / ADR"]
    R1 -.-> Shared

ポイント： レビューアーは「承認者」ではなく「潜在的な引き継ぎ者」として位置づけ、コードの理解を深めてもらいます。

引き継ぎ時間目安： 3-5日

---

レベル3: フル体制（長期・ビジネスクリティカル）

対象： 1年以上の長期運用、ビジネスクリティカル、規制産業（金融、医療等）

レベル2に加えて：

対策	工数	内容
複数レビューアー体制	週2-4時間	2名以上で冗長性確保
CI/CDへのドキュメント自動生成組み込み	初期構築	APIドキュメント、変更履歴
四半期ごとの引き継ぎシミュレーション	四半期1-2日	実践的な検証
バス係数スコアの定期測定	月1回	継続的な改善

体制イメージ：

flowchart TD
    Dev["開発担当者 + AI"]
    Dev -->|"PR"| R1["レビューアー A"]
    Dev -->|"PR"| R2["レビューアー B"]
    R1 -->|"承認"| Dev
    R2 -->|"承認"| Dev
    Dev --> Shared["共有基盤（自動更新）<br>README / AGENTS.md / ADR<br>APIドキュメント / 変更履歴"]
    R1 -.->|"引き継ぎ可"| Shared
    R2 -.->|"引き継ぎ可"| Shared

引き継ぎ時間目安： 1-2日

---

レベル別の比較

	レベル1	レベル2	レベル3
初期工数	3-5時間	5-10時間	1-2日
継続工数	ほぼなし	月2-3時間	週2-4時間
レビューアー	なし	1名（兼務）	2名以上
引き継ぎ時間	1-2週間	3-5日	1-2日
リスク許容度	高い	中程度	低い

---

バス係数の測定（レベル2以上で推奨）

「いつでも引き継げる状態」を客観的に測定するため、以下のスコアリングを使用できます。

バス係数スコア（5点満点×5項目=25点）：

観点	1点（危険）	3点（注意）	5点（良好）
環境構築	口頭説明が必要	README.mdで概ね可能	完全自動化
コード理解	開発者のみ理解	コメント・ADRあり	レビューアーも理解
デプロイ	手動・属人的	スクリプト化	CI/CD完全自動化
障害対応	開発者のみ対応可	Runbookあり	レビューアーも対応可
設計判断	暗黙知のみ	部分的にADR	ADR完備

目標スコア：

• レベル2: 15点以上（各項目3点以上）
• レベル3: 20点以上（各項目4点以上）

---

引き継ぎシミュレーション（レベル3で推奨）

四半期に1回、擬似的な引き継ぎ訓練を実施することで、本当に引き継げる状態かを検証します。

# 引き継ぎシミュレーション チェックリスト

## フェーズ1: 準備（1日目）
- [ ] 開発担当者が1週間「不在」と仮定
- [ ] レビューアーが主担当として対応

## フェーズ2: 実践（2-5日目）
- [ ] 環境構築: ドキュメントのみで開発環境を構築
- [ ] コード理解: 直近1ヶ月の変更を理解
- [ ] バグ修正: 軽微なバグを1件修正
- [ ] デプロイ: ステージング環境へのデプロイを実行

## フェーズ3: 振り返り（5日目）
- [ ] 不足していたドキュメントの特定
- [ ] 暗黙知の明文化
- [ ] 改善アクションの策定

---

まとめ

AI時代の開発は、少数精鋭または一人での高い生産性を可能にしました。しかし、DORAレポートが示す「AIは増幅器」という原則は、一人開発体制の脆弱性もまた増幅されることを意味します。

プロジェクトの性質に応じた体制を選択してください：

プロジェクト	推奨レベル	最低限必要なこと
短期・実験的	レベル1	共有基盤（README.md、AGENTS.md）
中期・通常業務	レベル2	+ レビューアー1名 + ADR
長期・クリティカル	レベル3	+ 複数レビューアー + 引き継ぎシミュレーション

重要なのは、「一人でできる」ことと「一人でやるべき」ことは異なるという認識です。 どのレベルでも「共有基盤」は整備し、プロジェクトの重要度に応じて追加の対策を講じてください。

---

関連記事

本記事と関連するテーマを扱った記事です：

• AI-Nativeエンジニアリングチームの構築：OpenAI Codexガイド解説 - SDLCの7フェーズでの人間とAIの役割分担、AGENTS.mdの活用方法を解説。

• AIによるコーディング時代のコードレビューのあり方：組織レベルでの課題と対策 - DORA 2024/2025レポートに基づく階層的レビュー体制、品質メトリクスの詳細を解説。

---

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

• Bus Factor in Practice - Bilkent University (2022). arXiv（ICSE 2022 SEIPで発表）. 【信頼性: 高】

---

引用の正確性について： 本記事で引用した研究は、学術データベース（arXiv、Google Scholar等）および公式サイトで確認しています。

研究の限界について：

• GitHub Copilot論文（Peng et al., 2023）: 95人の専門開発者を対象とした制御実験。JavaScriptでのHTTPサーバー構築タスクに限定。
• OpenAI Codex: OpenAI内部での使用データ。外部企業での再現性は未検証。
• DORA 2025: 約5,000人を対象とした自己申告型調査。

1. Announcing the 2025 DORA Report - Google Cloud Blog (2025). 【信頼性: 高】 ↩︎ ↩︎² ↩︎³

2. OpenAI DevDay 2025での発表。以下で報道: Everything OpenAI Released on DevDay 2025, Explained - The Neuron (2025). 【信頼性: 中〜高】 ↩︎

3. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot - Peng, S., et al. (2023). arXiv（査読前プレプリント）. 【信頼性: 中〜高】※95人の専門開発者を対象とした制御実験。タスク完了時間が55.8%短縮。 ↩︎

4. Bus factor - Wikipedia - Wikipedia. 【信頼性: 中〜高】 ↩︎

5. 生成AIが”個人最適化”を加速させる——ナレッジ共有の崩壊は始まっている - CIO (2024). 【信頼性: 中〜高】 ↩︎

6. How to write a great agents.md: Lessons from over 2,500 repositories - GitHub Blog (2025). 【信頼性: 中〜高】 ↩︎