結論：AI時代でも「人の判断」が必要な工程は残る——工数変化の全体像
Photo by Arnold Francisca on Unsplash
AIツールの普及によって、システム開発の現場では確かに工数の変化が起きています。しかし「AIを導入すればすべての工数が削減される」というのは実態とは異なります。工数の変化は大きく次の3つに分類できます。
- 削減される工程：繰り返し作業や定型処理が多い領域。コーディング補助・テスト自動化・ドキュメント生成など。
- 増加する工程：AI活用を前提とした設計・検証・ルール策定など、新たに発生する作業。要件定義の複雑化・AIアウトプットのレビュー・プロンプト設計など。
- 継続してかかる工程：人の判断・合意形成・現場定着支援など、自動化になじまない領域。導入支援・運用保守・ステークホルダーとの調整など。
この3分類を念頭に置くことで、AI導入の効果を過大評価も過小評価もせず、現実的な計画を立てることができます。以下では工程ごとに詳しく解説します。
工程別｜AI導入で工数が削減される領域
Photo by Austin Distel on Unsplash
コーディング・実装フェーズ：最も恩恵を受ける工程
GitHub CopilotやCursorなどのAIコーディング支援ツールの活用により、定型的なコード生成・補完・リファクタリングにかかる時間が短縮されるという報告が複数あります。特にCRUD処理（データの作成・読み取り・更新・削除）やAPIの雛形生成など、パターンが明確な実装作業では、体感として大きな時間短縮が得られるケースが多いとされています。
ただし、AIが生成したコードをそのまま本番環境に適用することはリスクを伴います。生成コードのレビューと修正は引き続き人間が担う必要があり、「実装工数が減った分、レビュー工数が増える」という側面も忘れてはなりません。
テスト自動化・バグ検出：繰り返し作業の大幅圧縮
AIを活用したテストケース自動生成や、静的解析ツールによるバグ検出は、手動テストに比べて繰り返し作業の工数を大きく圧縮できるとされています。回帰テスト（既存機能が壊れていないかを確認するテスト）の自動化は特に効果が出やすい領域です。
一方で、テストシナリオの設計やエッジケース（特殊な条件下での動作確認）の洗い出しは、依然として人間の経験と判断が必要です。
ドキュメント生成・仕様書作成：AIによる自動ドラフト化
会議の議事録作成・API仕様書のドラフト・コードコメントの自動生成など、ドキュメント作業はAIが得意とする領域のひとつです。ゼロから書き起こす時間が短縮され、担当者が「確認・修正・承認」に集中できる体制が作りやすくなります。
工程別｜AI導入でむしろ工数が増える領域
Photo by David Travis on Unsplash
ヒアリング・要件定義：AI活用前提の設計が複雑化
AIを組み込んだシステムを開発する場合、従来の要件定義に加えて「どの業務にAIを使うか」「AIの判断をどこまで信頼するか」「人間の介在ポイントをどこに設けるか」といった設計判断が必要になります。これはAI導入以前には存在しなかった論点であり、ヒアリングと要件定義の工数は増加する傾向があります。
また、AIの出力結果に対するビジネスオーナーの期待値調整も重要な工程です。「AIが何をできて、何をできないか」を正確に伝え、合意を取ることは、プロジェクト後半のトラブルを防ぐために欠かせません。
AIアウトプットのレビュー・品質検証：新たなチェック工程の発生
AIが生成したコード・文章・データ分析結果は、必ずしも正確とは限りません。「ハルシネーション（AIが事実と異なる内容を自信を持って出力する現象）」のリスクがあるため、AIアウトプットに対する品質検証は新たな工程として追加されます。
特に業務クリティカルなシステムでは、AIの判断ログの確認・異常値の検知・人間による最終承認フローの設計など、従来の開発では不要だった工程が発生します。
プロンプト設計・AI運用ルール策定：ゼロから構築が必要
プロンプトエンジニアリング（AIに対して適切な指示文を設計する技術）は、AIシステムの品質を左右する重要な工程です。また、RAG（Retrieval-Augmented Generation）（社内データベースなどの外部情報をAIに参照させて回答精度を高める手法）やファインチューニング（特定業務に合わせてAIモデルを追加学習させること）を活用する場合は、さらに専門的な設計工数が必要になります。
これらはプロジェクト初期にゼロから構築する必要があり、経験のある担当者がいない場合は特に工数がかさむ傾向があります。
工程別｜引き続き工数がかかり続ける領域
Photo by Dylan Gillis on Unsplash
導入支援・変更管理：人への定着は自動化できない
新しいシステムやAIツールを現場に定着させるためのトレーニング・マニュアル整備・問い合わせ対応は、AIで代替できる部分が限られています。特に現場スタッフの不安解消や業務フローの変更に伴う抵抗感への対応は、人が丁寧に関わる必要があります。
運用・保守・継続改善：AIシステムは「育てる」必要がある
AIシステムは導入して終わりではありません。時間の経過とともにデータの傾向が変化し、モデルの精度が低下する「モデルドリフト」が発生することがあります。定期的なモデルの再学習・精度モニタリング・フィードバックの収集と反映など、継続的な改善工数は従来のシステム保守に上乗せされる形で発生します。
ステークホルダーとのコミュニケーション・合意形成
AI導入プロジェクトでは、経営層・現場部門・情報システム部門・法務・外部ベンダーなど、多くの関係者との調整が必要になります。AIの活用範囲・データの取り扱い・責任の所在・セキュリティポリシーなど、合意すべき事項が多岐にわたるため、コミュニケーション工数は従来プロジェクト以上にかかるケースが少なくありません。
工数変化サマリー表：工程×変化方向の一覧
Photo by Luke Chesser on Unsplash
| 工程 | 変化方向 | 主な理由 |
|---|---|---|
| コーディング・実装 | 削減 | AIコーディング支援による定型実装の高速化 |
| テスト自動化・バグ検出 | 削減 | 繰り返しテストの自動化・静的解析の活用 |
| ドキュメント生成 | 削減 | 議事録・仕様書のAIドラフト化 |
| ヒアリング・要件定義 | 増加 | AI設計の複雑化・期待値調整の必要性 |
| AIアウトプットのレビュー | 増加 | 品質検証・ハルシネーション対策の新設 |
| プロンプト設計・AI運用ルール | 増加 | ゼロからの設計・専門知識が必要 |
| 導入支援・変更管理 | 継続 | 人への定着支援は自動化になじまない |
| 運用・保守・継続改善 | 継続（一部増加） | モデル監視・再学習・フィードバック対応 |
| ステークホルダー調整 | 継続 | 合意形成・責任範囲の設計は人が担う |
なぜラボ型開発支援がAI時代に適しているのか
ラボ型とは何か：従来の請負・SES型との違い
システム開発の外部委託形態には大きく3つあります。
- 請負型：成果物を定義して一括発注。仕様変更に弱く、追加費用が発生しやすい。
- SES型（準委任）：エンジニアの稼働時間を購入する形態。スキルのマッチングが課題になりやすい。
- ラボ型：専任チームを組成し、中長期にわたって伴走する形態。要件の変化に柔軟に対応できる。
ラボ型開発支援では、クライアント企業の専任チームとして機能するため、プロジェクトの文脈・業務知識・技術スタックを継続的に蓄積できます。
AI時代の不確実性に対応できる「伴走型」の強み
AI導入プロジェクトは、要件が途中で変わりやすく、試行錯誤が不可欠です。「まずPoC（概念実証）を小さく試して、効果が出たら本格展開する」というアプローチが現実的であり、そのためには仕様変更のたびに契約を結び直す請負型よりも、継続的に伴走できるラボ型の方が適しています。
また、プロンプト設計・モデル選定・品質検証といったAI固有の工程は、プロジェクトを深く理解したチームが担当する方が精度が上がります。
工数変化に柔軟に対応できる契約・体制設計
前述のとおり、AI導入では削減される工程と増加する工程が混在します。ラボ型では月次・四半期単位でリソース配分を見直せるため、「今月はプロンプト設計に注力し、来月はテスト自動化に移行する」といった柔軟な対応が可能です。
ラボ型開発支援の標準的な開発フロー
Phase 1：ヒアリング・現状分析（AI活用可能性の棚卸し）
- 人の役割：業務課題のヒアリング・現行システムの調査・AI活用の優先順位付け
- AIの役割：類似事例のリサーチ補助・議事録の自動生成
- ポイント：「どこにAIを使うか」を決める最重要フェーズ。スキップや手抜きはプロジェクト全体に影響します。
Phase 2：要件定義・AI設計（人とAIの役割分担を設計）
- 人の役割：機能要件・非機能要件の定義・AIと人間の判断境界の設計・ステークホルダー合意形成
- AIの役割：仕様書ドラフトの生成補助・類似要件のサジェスト
- ポイント：プロンプト設計の方針やRAG活用の有無など、AI固有の設計判断をこのフェーズで確定します。
Phase 3：開発・実装（AI支援コーディングと品質管理）
- 人の役割：アーキテクチャ設計・AIコード生成のレビュー・品質基準の管理
- AIの役割：コード補完・テストケース生成・ドキュメント自動生成
- ポイント：AI生成コードのレビュープロセスを標準化することで、品質と速度を両立します。
Phase 4：導入支援・トレーニング（現場定着まで伴走）
- 人の役割：現場スタッフへのトレーニング・マニュアル整備・問い合わせ対応・変更管理
- AIの役割：FAQ自動応答・操作ガイドのドラフト生成
- ポイント：技術的な完成度よりも「現場が使いこなせるか」が成否を分けます。
Phase 5：運用・継続改善（AIモデルのチューニングと監視）
- 人の役割：モデル精度のモニタリング・フィードバック収集・改善方針の意思決定
- AIの役割：ログ分析・異常検知・レポート自動生成
- ポイント：AIシステムは「育てる」前提で運用体制を設計することが重要です。
ラボ型開発支援を選ぶ際のチェックポイント
ラボ型開発支援企業を選定する際は、以下の観点で確認することをお勧めします。
技術面
- AI開発（LLM活用・RAG・ファインチューニング）の実績があるか
- コーディング支援ツールやテスト自動化ツールの活用実績があるか
- セキュリティ・データガバナンスへの対応方針が明確か
体制・契約面
- 専任チームの構成（PM・エンジニア・QA・AI専門家）が明示されているか
- 月次でリソース配分を調整できる柔軟な契約形態か
- 知的財産権・成果物の帰属が契約書に明記されているか
コミュニケーション面
- 定例ミーティングの頻度・報告フォーマットが明確か
- 要件変更時の対応プロセスが定められているか
- 導入後の運用・保守まで一貫して対応できるか
AI開発支援の実績と、業務理解を深めながら伴走できる体制の両方を確認することが、パートナー選定の核心です。
AI時代の開発プロジェクトでは、技術力だけでなく「変化に対応し続ける柔軟性」がパートナーに求められます。ラボ型開発支援の活用を検討している場合は、まず現状の課題と目指す姿を整理した上で、複数社に相談してみることをお勧めします。
よくある質問（FAQ）
AI導入で開発工数はどのくらい削減できますか？
工程や活用方法によって大きく異なります。コーディング補助ツールの活用で実装工数が一定程度短縮されるという報告がある一方、要件定義やAI品質検証など増加する工程もあります。「全体として何割削減できる」という一律の数値は存在せず、プロジェクトの性質・チームのAIリテラシー・活用ツールの組み合わせによって変わります。
要件定義の工数はAI時代でも変わらないのですか？
むしろ増加する傾向があります。AIを組み込んだシステムでは「どこにAIを使うか」「AIの判断をどこまで信頼するか」「人間の介在ポイントをどこに設けるか」といった従来にはなかった設計判断が加わるためです。要件定義の質がプロジェクト全体の成否を左右するため、このフェーズへの投資は重要です。
AIを使うと品質検証の工数が増えると聞きましたが本当ですか？
その通りです。AIが生成したコードや文章には誤りが含まれる可能性があるため、従来の品質検証に加えて「AIアウトプットのレビュー」という新たな工程が発生します。特にハルシネーション（AIが誤った情報を自信を持って出力する現象）のリスクがある領域では、人間による確認プロセスの設計が不可欠です。
ラボ型開発支援と従来のSES・請負開発の違いは何ですか？
請負型は成果物を一括発注する形態で仕様変更に弱く、SES型はエンジニアの稼働時間を購入する形態でスキルマッチングが課題になりやすいです。ラボ型は専任チームが中長期にわたって伴走し、業務知識・プロジェクト文脈・技術スタックを継続的に蓄積できる点が特徴です。AI導入のように試行錯誤が必要なプロジェクトに適しています。
AI時代にラボ型を選ぶメリットはどこにありますか？
AI導入プロジェクトは要件が変化しやすく、PoCから本格展開まで段階的に進めることが多いため、仕様変更のたびに契約を見直す必要がある請負型よりも、継続的に伴走できるラボ型が適しています。また、プロンプト設計やモデル選定などAI固有の工程は、プロジェクトを深く理解したチームが担当する方が精度が上がります。
運用フェーズでAIを使うと工数はどう変わりますか？
ログ分析・異常検知・レポート生成などはAIで効率化できる部分がありますが、モデルの精度監視・再学習の判断・フィードバックの収集と反映など、AIシステム固有の保守工数が新たに発生します。従来のシステム保守工数が単純に削減されるわけではなく、「AIを育てる」ための継続的な工数を見込む必要があります。
プロンプト設計はどの工程で誰が担当するのですか？
主に要件定義・AI設計フェーズで方針を確定し、開発フェーズで具体的な設計・検証を行います。担当者はAIエンジニアまたはプロンプトエンジニアリングの知識を持つ開発者が適しています。業務知識と技術知識の両方が必要なため、クライアント側の業務担当者とベンダー側のAI担当者が協力して進めることが一般的です。
AI開発支援企業を選ぶ際に確認すべきポイントは何ですか？
AI開発（LLM活用・RAG・ファインチューニング）の実績、セキュリティ・データガバナンスへの対応方針、専任チームの構成、契約の柔軟性（リソース調整の可否）、知的財産権の帰属、導入後の運用・保守対応の有無などを確認することをお勧めします。技術力だけでなく、業務理解と伴走姿勢も重要な選定基準です。
ラボ型開発の契約形態はどのようなものが一般的ですか？
月額固定または時間単価×稼働時間の準委任契約が一般的です。月次または四半期単位でリソース配分を見直せる形態が多く、プロジェクトの進捗に応じてチーム構成を調整できる柔軟性がラボ型の特徴のひとつです。契約期間は3ヶ月〜1年程度の更新型が多いとされています。
AI導入後の運用・保守はどのくらいの工数を見込めばよいですか？
システムの規模・AIの活用範囲・モデルの種類によって大きく異なります。一般的には、従来のシステム保守工数に加えてモデル監視・精度評価・フィードバック対応の工数が上乗せされると考えておくと現実的です。導入前の計画段階で「運用フェーズの体制と工数」を明確にしておくことが、プロジェクト成功の重要な要素のひとつです。
