MENU
カジュアル面談

10名未満で7プロダクトを回すAIネイティブ開発の仕組み

AI駆動開発

ClassLab Engineering の Dev チームメンバーが執筆しました。

*この記事は、AI駆動開発プロセスやチーム生産性の向上に興味があるテックリード・EM向けです。*

目次

1. 背景

ClassLab のエンジニアリングチームは10名未満です。この少人数で、ライフライン基幹システム、AI研修プラットフォーム、不動産アプリ、業務自動化ツール群など、7つ以上のプロダクトを開発・運用しています。

「人が足りない」は常にある状態です。しかし採用を待つだけでは事業のスピードについていけません。私たちが選んだアプローチは、AIツールを全員が日常的に使うことで、個人の生産性を引き上げることでした。

Claude CodeとGitHub Copilotの全員導入は、「一部のメンバーが試している」段階を超え、チーム全体の開発プロセスに組み込むことで初めて効果を発揮しました。その仕組みを共有します。

2. 課題

課題 影響 定量データ
エンジニア不足 プロダクトあたり1-2名しかアサインできない 7プロダクト / 10名未満
コードレビューのボトルネック レビュー待ちでPRが滞留 特定メンバーに集中
多言語対応 PHP/TS/Python/Dart/Apex全てに精通する人がいない 6言語が社内に共存
ドキュメント不足 開発に追われ、ドキュメントが後回し 暗黙知が増加
テストの手薄さ テストを書く時間がない カバレッジにばらつき
障害対応の属人性 特定プロダクトの障害対応が特定メンバーに依存 深夜・休日対応のリスク

3. 設計（AIネイティブ開発プロセス）

開発フローへの組み込み

AIツールを「便利なオプション」ではなく「標準プロセスの一部」として組み込みました。

flowchart LR
    PLAN[設計<br/>Claude Code] --> CODE[実装<br/>GitHub Copilot]
    CODE --> REVIEW[レビュー<br/>Claude Code]
    REVIEW --> TEST[テスト生成<br/>Claude Code]
    TEST --> DOC[ドキュメント<br/>Claude Code]
    DOC --> DEPLOY[デプロイ]

ツール選定と使い分け

フェーズ ツール 使い方
設計 Claude Code アーキテクチャ設計、技術選定の壁打ち
実装 GitHub Copilot インラインコード補完、ボイラープレート生成
レビュー Claude Code コード品質チェック、セキュリティ分析
テスト Claude Code テストケース生成、カバレッジ向上
ドキュメント Claude Code API仕様書、ADR、READMEの生成
デバッグ 両方 Copilotでログ分析、Claude Codeで仮説検証

AIツールの導入判断基準

すべての開発タスクにAIを使うわけではありません。以下の基準で使い分けています。

AIが効果的な場面 人間が優先する場面
ボイラープレートコードの生成 ドメインロジックの設計判断
テストケースの網羅的な洗い出し ビジネス要件の解釈
不慣れな言語でのコードレビュー セキュリティの最終判断
ドキュメントの草案生成 ユーザー体験の設計
デバッグ時の原因仮説生成 障害対応の優先度判断

この使い分けが明確でないと、「AIに任せたから大丈夫」という過信や、「AIは信用できない」という過度な不信が生まれます。

全員導入のための3つの工夫

1. 設定の標準化

各リポジトリにCLAUDE.mdを配置し、プロジェクト固有のコンテキスト（技術スタック、コーディング規約、デプロイ手順）をAIに共有しています。これにより、どのメンバーがどのプロダクトに取り組んでも、AIが同じ品質のサポートを提供します。

2. 成果の可視化

AIを活用した開発の成果を定量的に計測し、チーム内で共有しています。「AIを使ったら速くなった」ではなく「PRのリードタイムが何%短縮された」という具体的な数値で効果を示すことで、懐疑的だったメンバーも自然に使い始めました。

3. 段階的な導入

最初からすべてのフェーズでAIを使うのではなく、最もボトルネックだった「コードレビュー」から導入しました。レビュー待ちの解消という目に見える効果が出たことで、他のフェーズへの展開がスムーズに進みました。

4. 実装（具体的な活用事例）

事例1: 不慣れな言語でのレビュー

Flutterのコードレビューができるメンバーは限られています。Claude Codeにプロジェクトのコンテキスト（CLAUDE.md + コーディング規約）を渡すことで、言語の壁を超えたレビューが可能になりました。

もちろん、AIレビューだけで完結させるわけではありません。AIが検出した問題をベースに、ドメイン知識を持つメンバーが最終判断を行います。AIは「第一レビュアー」、人間は「最終レビュアー」という役割分担です。

事例2: テスト生成による品質底上げ

テストの手薄さが課題だったプロダクトで、Claude Codeにテストケースの生成を依頼しました。既存コードの入出力パターンを分析し、エッジケースを含むテストを自動生成します。

重要なのは、生成されたテストをそのまま使わないことです。AI が生成したテストはビジネスロジックの意図を正確に反映していない場合があります。生成されたテストを出発点として、ドメイン知識を持つエンジニアが意図を確認・修正します。

事例3: ドキュメント自動生成

開発に追われてドキュメントが後回しになる問題に対し、コードの変更をトリガーにClaude CodeでADR（Architecture Decision Records）やAPI仕様書の草案を自動生成する仕組みを構築しました。草案生成→人間レビュー→マージというフローで、ドキュメントの鮮度を維持しています。

事例4: PRレビューの自動トリアージ

PRが作成されると、変更内容に応じてレビューの優先度と焦点を自動判定する仕組みを導入しました。セキュリティ関連のコード変更（認証・暗号化・入力バリデーション）が含まれるPRは自動的に「要人間レビュー」にフラグが立ち、UIの軽微な変更は AIレビューで完結させます。これにより、人間のレビュー時間を本当に必要なPRに集中できるようになりました。

事例5: 障害対応でのAI活用

本番障害が発生した際、Claude Codeにエラーログとスタックトレースを渡して原因仮説を生成させ、調査の初動を高速化しています。特に深夜や休日の障害では、対応者が当該プロダクトの専門家でないケースがあります。そのような場合でも、AIが「このエラーパターンはこの箇所で発生する可能性が高い」と絞り込むことで、復旧までの時間を短縮できています。

やってはいけないこと

AIネイティブ開発の導入で学んだ失敗パターンもあります。

  • AIの出力を無検証で本番投入: 特にセキュリティ関連のコードは必ず人間がレビューする
  • AIに「全部任せる」姿勢: 設計判断やドメインロジックの最終責任は人間が持つ
  • ツールの強制: 各自が最も生産性が上がる使い方を見つけることが重要

    • 5. 結果（数値）

    指標 Before After 改善率
    PRレビューの平均待ち時間 1-2営業日 当日中 大幅短縮
    1人あたりの月間PR数 約15件 約25件 +67%
    テストカバレッジ（主要プロダクト平均） 約40% 約70%（バグ検出率も併せて計測） +30pt
    ドキュメント更新頻度 月1回程度 コード変更ごと 大幅増加
    新プロダクトの初期実装期間 4-6週間 2-3週間 -50%

    6. 展望

    次に取り組む課題

    • AIエージェントによる自動化: 依存関係の更新、セキュリティパッチ適用、定期的な品質チェックをAIエージェントに委任する基盤。次のエンジニアと一緒に設計したい領域です
    • 組織知のAI参照基盤: ADR（Architecture Decision Records）をCLAUDE.mdに蓄積し、新メンバーが「なぜこの設計にしたのか」をAIに聞ける環境の構築。オンボーディング高速化の鍵です
    • 効果測定の精緻化: A/Bテスト的手法で「どのフェーズでAIが最も効果を発揮するか」をデータで示し、投資判断を定量化する

      • 関連記事

      採用情報

      ClassLab では、AIを活用して少人数で大きなインパクトを出す開発をリードするテックリード・シニアエンジニアを募集しています。AI駆動開発プロセスの設計から参画できるポジションです。

      ClassLab Engineering チームメンバーが執筆しました。

      ClassLab.では、一緒にプロダクトを作るエンジニアを募集しています。

      カジュアル面談も大歓迎です！

      Findyで話を聞く | 採用情報を見る

AI駆動開発
AI駆動開発 Claude Code GitHub Copilot 生産性向上
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

ClassLab Engineeringのアバター ClassLab Engineering

関連記事

目次