1人+Claude Code≒5〜7名チーム：AI駆動開発で個人が到達できるシステム規模

本番で24時間稼働する自動化システムを、1人で開発・運用しています。AIなし（従来型開発）で同じシステムを構築・運用するなら、5〜7名のチームが必要だと見積もっています。

本記事では、システムの規模を定量的に示し、従来型チームの各役割と対応づけることで、「1人 + Claude Code」がどのレベルまで到達できるかを検証します。同時に、この体制の限界と、AI駆動開発の強みが「速度」ではなく「人件費圧縮」と「コンテキスト集中」にあることも率直に書きます。

システムの全体像

まず、現在のシステムの規模を数字で示します。

これは「個人の趣味プロジェクト」の規模ではありません。複数の外部APIと連携し、3環境で運用し、90ジョブが毎日自動実行されるシステムです。

従来型チームなら何名必要か

このシステムを、AIなしの従来型開発で構築・運用する場合の人員構成を見積もります。

バックエンドエンジニア：2〜3名

3つのエンジンはそれぞれ独立したプロダクト規模です。

• データ収集エンジン: 外部APIからデータを取得し、分析指標を計算し、トリガーファイルを生成する。411指標の計算ロジックと6つのAPI連携を含む
• 国内データエンジン: 国内市場のデータ処理。Windows VM経由のProxy構成という特殊なインフラを含む
• 海外データエンジン: 海外市場のデータ処理。RSA署名によるAPI認証、SDK経由のバッチ処理

6つのAPIは認証方式が全て異なります（HMAC-SHA256、Bearer Token、パスワード→トークン交換、リフレッシュトークン、API Key + Secret、RSA署名）。1人のエンジニアが全APIの認証仕様を把握するのは、従来型チームではリスクが高いです。担当を分けるのが一般的です。

さらに、循環的複雑度60のメソッドを19に下げるリファクタリング、統合分析アーキテクチャへの刷新（処理時間18時間→3時間）なども含まれます。これらは通常、シニアエンジニアが担当する作業です。

インフラ/SREエンジニア：1名

90ジョブの運用だけで専任が必要になります。

• launchd管理: 90個のplistファイル生成・構文検証・スケジュール管理
• 3環境の運用: 本番/Pre/開発のワークスペース分離、DB分離、plistのオフセット設定
• ヘルスチェック: validate_launchd_health.shによるplist構文・ログ鮮度・エラーパターンの自動検証
• Git-Flow運用: main/pre/develop/feature/* のブランチ戦略とリリーススクリプト
• サイレント障害対策: ハートビートパターン、ログ鮮度チェック、緊急停止ファイル

plist 30ファイル破損事故（json.dump()で生成してしまった問題）や、launchdキャッシュの罠（壊れたplistでもジョブが動き続ける）といった、macOS固有の運用知識も必要です。

QAエンジニア：1名

7,484テストの維持・拡張は片手間では無理です。

• テスト戦略の設計: クリティカルパスから着手し、回帰テスト→カバレッジ駆動の3フェーズで拡大
• テストファクトリの整備: create_signal_data()のようなファクトリ関数で、テストデータ生成を標準化
• カバレッジ閾値の運用: --cov-fail-under=80でCIに組み込み、テストなしのコードを許さない仕組み
• 実行時間の管理: 7,484テストを3分以内に実行する工夫（外部APIのモック化、-xオプション、-kフィルタ）

「AIが書いたテスト」のレビューも重要な仕事です。AIはassert result is not Noneのような「通るだけで意味のないテスト」を書くことがあります。ドメイン知識に基づくテストの検証は、人間の仕事です。

データエンジニア：1名

411指標の分析パイプラインは専門性が高いです。

• パイプライン設計: 統合分析アーキテクチャ（計算と判定の分離）
• データ形式管理: CSVからParquetへの移行、スキーマ管理
• DB設計: PostgreSQL + TimescaleDBのhypertable設計、time_bucket集約
• IMPACT_ANALYSIS: データパイプライン変更時の6段階チェックリスト運用

データパイプライン変更は392件のインシデントの30%を占める最大カテゴリでした。変更箇所と影響箇所が別ファイルに分散するため、grepベースの影響範囲特定と、DDL→Reader→Writer→Test→Deployの実施順序管理が必要です。

PM/PdM：0.5〜1名

111施策の管理、施策間競合分析、Go/No-Go判定はフルタイムではありませんが、ゼロでは回りません。

• WBS管理: 53アクティブ施策のステータス・依存関係の追跡
• 施策間競合分析: 1,378ペアの組み合わせを6カテゴリでチェック
• Go/No-Go判定: 30処理以上のサンプルで統計的に判定（Wilson信頼区間）
• 優先順位付け: 効果見積もり、実装コスト、既存施策との競合を考慮した判断

合計：5〜7名

ただし「5〜7名の速度」ではない

重要な注意点があります。「5〜7名チームと同じ速度で開発している」わけではありません。

1
従来型チーム（5〜7名）:
2
  → 並列作業が可能（エンジンAとBを同時に開発）
3
  → 3〜6ヶ月でシステム構築
4
  → 人件費: 月額400〜600万円（5〜7名 × 月60〜80万円）
5

6
1人 + Claude Code:
7
  → 逐次作業が基本（1施策1セッション）
8
  → 約12ヶ月でシステム構築
9
  → 人件費: 月額数万円（Claude Code利用料）

AI駆動開発の強みは開発速度ではなく、以下の2点です。

強み1：人件費の圧縮

5〜7名チームの年間人件費は5,000〜8,000万円。1人 + Claude Codeなら数十万円。コスト比は100倍以上の差があります。

個人開発で「5名分の人件費を払ってチームを組む」選択肢は現実的ではありません。AIがなければ、このシステムは存在していませんでした。

強み2：コンテキスト集中

1人の頭に全体像があります。3つのエンジン、6つのAPI、90ジョブの関係を把握している人間が1人いるのは、チーム開発にはない強みです。

チーム開発では「エンジンAの担当者がエンジンBの仕様を知らない」問題が頻発します。施策間競合分析（1,378ペアのチェック）が必要になるのは、この「知識の分断」が原因です。1人ならそもそも分断が起きません。

ただし、CLAUDE.mdに460行のルールを書いて「AIにコンテキストを共有する」仕組みがなければ、セッション間で知識が失われます。コンテキスト集中の恩恵を受けるには、永続化の設計が不可欠です。

AI駆動開発の限界

1人では並列作業ができない

チーム開発なら「エンジンAのリファクタリング」と「エンジンBの新機能」を同時に進められます。1人 + AIでは、1施策1セッションの原則に従い、逐次で進めるしかありません。

レビューの客観性がない

チーム開発にはコードレビューがあります。「この設計は本当に正しいか」を別の視点で検証できます。1人 + AIでは、AIのレビュー（/sc:analyze）はありますが、人間の別視点は存在しません。

392件のインシデントの一部は、この「レビューの不在」が遠因です。

専門性の深さに限界がある

5〜7名チームなら、DBの専門家やインフラの専門家がいます。1人 + AIでは、全領域を「そこそこのレベル」でカバーすることになります。TimescaleDBの最適化やlaunchdの深いトラブルシューティングは、専門家がいるチームに比べて手探りになりがちです。

CLAUDE.mdが「チームの知識」を代替する

チーム開発で暗黙知として共有される情報——「この設計は過去に却下された」「このAPIのエラーコード5012はキーの種別間違い」「plist生成はjson.dumpではなくplistlib.dumpを使う」——を、CLAUDE.mdに明文化しています。

1
チーム開発の暗黙知:
2
  → 「先輩に聞けばわかる」
3
  → 「前任者のドキュメントに書いてある（かもしれない）」
4

5
AI駆動開発の明文知:
6
  → CLAUDE.md（460行のルール + 教訓）
7
  → ADR（設計判断の記録）
8
  → PARAMETER.md（パラメータの値と理由）
9
  → WBS（施策の進捗と依存関係）

皮肉なことに、チーム開発で問題になる「暗黙知の属人化」は、AI駆動開発では構造的に解消されます。AIはCLAUDE.mdに書かれていないことを知らないので、全てを明文化せざるを得ないからです。

学んだこと

1. AIは「5〜7名分の手」であって「5〜7名分の頭」ではない

AIは実装・テスト生成・競合検出を高速に行います。しかし「何を作るか」「どの施策を優先するか」「このリスクは許容するか」の判断は人間の仕事です。AIは優秀な実行者ですが、意思決定者ではありません。

2. コンテキスト集中は諸刃の剣

全体像が1人の頭にあるのは強みですが、その1人が倒れたらプロジェクトは止まります。チーム開発の冗長性（誰かが休んでも回る）は、1人開発にはありません。CLAUDE.md・ADR・PARAMETER.mdによる明文化は、この「バス係数1」問題の緩和策でもあります。

3. AI駆動開発の本質は「参入障壁の破壊」

従来、年間5,000〜8,000万円の人件費を投じなければ構築できなかったシステムが、個人の副業レベルのコストで構築可能になりました。これは「既存チームの効率化」ではなく「個人が新しい市場に参入できるようになった」というパラダイムシフトです。

まとめ

1人 + Claude Codeで5〜7名チーム相当のシステムを構築・運用できた要因は以下の3点です。

1. AIが「手」を提供する: 実装の80%、テストの80%、競合検出、リファクタリング。人間は「何を作るか」と「判断」に集中
2. コンテキスト集中: 全体像が1人の頭にあることで、知識の分断が起きない。ただしCLAUDE.md等で永続化しなければセッション間で失われる
3. 参入障壁の破壊: 年間数千万円の人件費が不要に。個人開発で本番稼働するシステムを構築できる時代になった

5〜7名チームと同じ「速度」ではありませんが、同じ「到達点」に至れます。それがAI駆動開発の現在地です。