著者：野原琉海（業務効率化に特化したエンジニア）
「AI開発ツールを使えば開発が早くなるって聞いた。その前提で工期を組んでほしい」
こういった発言をする経営者が、ここ1〜2年で明らかに増えた。GitHub Copilotや Claude Codeが業界内で話題になり、「開発が何倍も速くなる」というメッセージが広まった結果だ。
実際にGitHubが行った調査では、GitHub Copilotを使ったエンジニアはタスクを55%速く完了できたというデータがある。この数字は本物だ。ただし、「コーディングが55%速くなる」という話と「プロジェクトが55%早く終わる」という話は、まったく別の話だ。
業務効率化に特化したエンジニアとして、この誤解が実際にどんな問題を起こすかを何件も見てきた。この記事では、AI開発ツールが本当に何を速くして、何を速くしないのかを整理する。外注先への発注・社内エンジニアへの指示・進捗確認のどの場面でも使える知識として書く。
AI開発ツールが速くする工程・速くしない工程
まず構造の整理から始める。
AI開発ツール（GitHub Copilot、Claude Code等）が速くするのは、主に「コードを書く作業」の部分だ。繰り返しパターンの実装、既存コードの修正案の提示、バグ候補の検出——こういった作業でエンジニアの手作業が減る。
一方、開発プロジェクト全体を見渡すと、「コードを書く作業」が全体に占める割合は思ったより小さい。
| 工程 | AIで速くなるか | 全体工数の目安 |
|---|---|---|
| 要件定義（何を作るかの確認） | 速くならない | 15〜20% |
| 業務フローの理解（現場ヒアリング） | 速くならない | 10〜15% |
| コーディング（実装作業） | 速くなる（55%程度） | 20〜30% |
| 外部システムとの連携調整 | ほぼ速くならない | 10〜20% |
| テスト・品質確認 | ほとんど速くならない | 20〜30% |
| 修正・レビュー対応 | 部分的に速くなる | 10〜15% |
この表を見ると分かるが、コーディングが全体の20〜30%を占めているとして、そこが55%速くなったとしても、全体工期への影響は計算上では10〜16%の短縮にとどまる。
実際の現場で経験してきたことを言うと、要件定義と業務フローの確認だけで全体の3分の1以上を使うことはざらにある。ここはどれだけ優秀なAIがあっても短縮できない。経営者や現場担当者と「何を作るか」「どの業務フローに組み込むか」を確認する作業は、人間同士の会話でしか進まない。
「55%速くなる」という数字の正確な意味
GitHubが2022年に発表した研究では、GitHub Copilotを使った開発者は使わなかった開発者よりもタスクを55%速く完了したという結果が出ている。また、4800人以上を対象にしたフィールド実験では、26%の生産性向上が確認されている。
これらの数字は、コーディング作業に絞った計測値だ。プロジェクト全体の工期を計測したものではない。
もう少し解像度を上げると、AI開発ツールが効果を発揮しやすい状況と、あまり変わらない状況の差がある。
| AI開発ツールが効果を発揮する場面 | 効果が薄い場面 |
|---|---|
| 定型処理・CRUD操作の実装 | 要件が曖昧で何度も確認が必要な場面 |
| 既存コードのバグ修正 | 業界特有のルールや例外処理の設計 |
| ドキュメントの自動生成 | 他社システムとの連携調整 |
| テストコードの雛形作成 | 業務フローそのものの再設計 |
| コードのリファクタリング | 現場ユーザーのテストとフィードバック対応 |
ニフティの全社導入事例では、GitHub Copilotの提案採用率（実際にエンジニアが採用した提案の割合）は約30%という結果が報告されている。生成された候補をそのまま使えるケースは3割で、残り7割はレビューして修正が必要だということだ。AIが書いたコードは必ずエンジニアがチェックする必要がある。この確認作業の時間はゼロにならない。
業務効率化に特化したエンジニアとして正直に言うと、「AIを使えば開発が一気に楽になる」というのは部分的な事実であって、全体像ではない。コーディングの一部が速くなるが、設計・確認・テストのサイクルは以前と変わらない。
全体工期への現実的な影響 ── 経験から言う10〜20%
AI開発ツールを適切に活用しているチームが、品質を落とさずにプロジェクトを完了した場合、全体工期がどの程度短縮されるかを実際に見てきた範囲で言う。
現実的な短縮幅は10〜20%だ。
「半分になる」「3分の1になる」というのは特殊なケースだ。要件がほぼ完全に固まっていて、コーディング比率が高く、テストがシンプルで、現場担当者の確認が素早い——そういった条件が揃ったプロジェクトでなければ、極端な短縮にはならない。
あるプロジェクトで実際に起きたことを書く。AI開発ツールを使うエンジニアがコーディングを通常よりも速いペースで進めた。1週間予定のコーディングが5日で完了した。ところが、テストを始めると「この動作は実際の業務フローと合っていない」という問題が3件発生した。要件確認の時間を十分に取れていなかったことが原因だった。結果として、コーディングで短縮した分の時間が修正と再テストで消えた。最終的な工期は当初の予定とほぼ同じだった。
コーディングが速くなると、要件確認が不十分なまま実装が進むリスクが上がる。これは逆説的だが本当のことだ。「書ける」と「正しいものを作る」は別の問題だ。
開発プロジェクト全体の工期比較（概算）
| プロジェクトの種類 | AI活用なし | AI活用あり | 短縮幅 |
|---|---|---|---|
| 要件が明確・連携なし・シンプルなCRUD | 2ヶ月 | 1.5〜1.7ヶ月 | 15〜25% |
| 要件確認に時間がかかる案件 | 3ヶ月 | 2.7〜2.9ヶ月 | 5〜10% |
| 外部システム連携・複雑な業務ロジック | 4ヶ月 | 3.5〜3.8ヶ月 | 5〜12% |
| 要件が途中で変わりやすい案件 | 変動大 | 変動大 | ほぼ変わらない |
矢印で「MatrixFlowを活用すると通常3ヶ月の案件が1.5ヶ月で納品できた」という事例報告が出ている。これは本物の事例だが、条件が揃ったケースの数字だ。「AIを使えばこうなる」と汎用化して使うのは危険だ。
短縮しやすいプロジェクト・しにくいプロジェクムの見分け方
AI開発ツールの効果は、プロジェクトの特性によって大きく変わる。発注前にどちらに近いかを判断することで、工期設定の現実感が出る。
短縮しやすいプロジェクムの特徴（AI活用効果が出やすい）
- 要件が書面で整理されており、変更が少ない
- 既存の業務フローをデジタル化するだけで、業務プロセスの再設計がない
- 連携先のシステムのAPI仕様が整備されている
- テスト担当者が業務を深く理解しており、フィードバックが素早い
- 使うフレームワーク・言語が標準的（独自仕様がない）
短縮しにくいプロジェクムの特徴（AI活用効果が出にくい）
- 「使いながらイメージを固める」という進め方をする案件
- 紙管理・Excel管理からの移行で、データ整備が必要な案件
- 連携先システムの仕様が不明確で交渉が必要
- テストに現場スタッフの立ち会いが必要で、日程調整が難しい
- 担当者の退職・異動など、途中で関係者が変わる可能性がある
業務効率化に特化したエンジニアとして多くのプロジェクトを見てきた経験から言うと、中小企業のシステム開発案件の多くは「短縮しにくい」側の特性を持っている。現場の業務は複雑で、担当者がいないと進められない確認が多く、要件も最初から完全には固まっていない。これは中小企業の規模の問題ではなく、業務の自然な姿だ。
システム開発を外注するときの失敗パターンについてはシステム開発の外注で失敗するパターンと回避策で詳しく整理しているので、あわせて参考にしてほしい。
「AIを使うなら工期を短くしてほしい」という交渉が起こすリスク
外注先への交渉として「AI開発ツールを使うなら工期を短く・費用を下げてほしい」という話が出ることがある。経営者の立場からすると当然の発想だが、この交渉が意図しない結果を生むリスクを説明したい。
リスク1: 見えないところで何かが削られる
工期を10%短縮した分、作業量は変わらないのだから、何かの工程が削られる。削られやすいのは「やらなくても動く」工程だ。テストの実施回数、要件確認の丁寧さ、レビューの深さ——これらが削られた状態でシステムが納品される。納品後に問題が発覚し、追加修正費用が発生するケースは珍しくない。
リスク2: AI使用の強制が逆効果になるケース
エンジニアによってAI開発ツールの習熟度は大きく異なる。熟練したエンジニアはAIの提案を的確に判断して取捨選択できる。一方、経験が浅いエンジニアがAI生成コードをレビューなしに使うと、品質問題が発生しやすい。「AIを使っているから安い・速い」を前提にした契約は、後者のリスクを増やす。
リスク3: ベンダーとの関係悪化
「AIを使えば早いはずだ」という前提で一方的に工期短縮を求めると、外注先との信頼関係が傷む。まともな外注先ほど「無理な工期は品質を下げる」という経験則を持っているため、無理な要求には応じないか、応じた場合に品質が落ちるかのどちらかだ。
正しいアプローチ
「AIを使うから工期を短く・費用を下げる」という交渉ではなく、「AI開発ツールを使うことで、このプロジェクトの中でどの工程がどう変わるか」を具体的に聞く方が実態に近い。
具体的には：「今回の案件でどのAI開発ツールを使いますか？それによってどの工程が変わりますか？品質担保はどうしますか？」という聞き方が有効だ。
フリーランスエンジニアへの依頼方法と確認事項についてはフリーランスエンジニアの探し方｜中小企業が開発を依頼するための基礎知識でもまとめているので参考にしてほしい。
経営者が開発進捗を確認する方法
「エンジニアに任せているが、本当に進んでいるのか分からない」という状態は、AI開発ツールの有無に関わらず起きる。しかしAI活用が広まった現在、「AIが書いているんだから速いはず」という思い込みが、進捗確認をおろそかにする原因になっている。
週次確認で見るべき3点
- 今週何が完成したか：「○○画面が完成した」「△△の処理が動くようになった」という具体的な状態。「進めています」という報告は確認ではない
- 遅れがあるなら原因は何か：技術的な問題か、要件確認の待ちか、外部連携の調整かを区別する
- 来週末までに何が完成する予定か：1週間単位の具体的な予定を確認する
AI開発ツールを使っているかどうかに関わらず、プロジェクト途中で工数が増える原因はほぼ同じだ。
| 工数増加の原因 | 頻度 | AIの有無との関係 |
|---|---|---|
| 要件の変更・追加（依頼側から） | 高い | AI活用に関係なく発生 |
| 連携先システムの仕様が想定と違った | 中程度 | AI活用に関係なく発生 |
| テストで想定外の問題が多発 | 中程度 | AI生成コードでも発生 |
| 業務フローの問題がコーディング後に発覚 | 高い | 要件確認が薄いと増加 |
| AI生成コードの品質問題による修正 | AI活用時に発生 | AI使用での新リスク |
「AIを使っているのに遅い」という評価をする前に、上記のどれに当たるかを確認する。工数増加の原因の多くはAI使用率と無関係だ。ただし4番目と5番目の組み合わせは、AI活用が広まった近年に増えているパターンだ。
自社でもコンテンツ制作にAIを活用しているが、AIが生成したものをそのまま使うことはしない。必ず確認・修正のプロセスを入れる。そのプロセスを省いた場合、出来上がったものの品質は確実に落ちる。開発も同じだ。
まとめ：経営者が持つべき現実的な期待値
AI開発ツールは本物だ。ただし、「何が変わって何が変わらないか」を正確に把握した上で使わないと、現実とのギャップが問題を起こす。
| 経営者がよく持つ期待 | 現実的な見方 |
|---|---|
| 開発期間が半分になる | 全体では10〜20%短縮が現実的な上限。コーディング以外の工程は変わらない |
| AI使用で費用が大幅に下がる | 短縮分は品質向上・難易度の高い機能開発に充てられることが多い |
| AI生成コードはバグが少ない | バグは発生する。レビューと品質管理のプロセスは引き続き必要 |
| 要件だけ伝えれば後は全部任せられる | 要件確認・フィードバック・テストへの依頼側の関与は変わらず必要 |
| AI使用を前提に短い工期で発注できる | 工程別に何が変わるかを確認してから工期を決めるべき |
GitHubの調査による「55%速い」という数字は、コーディング作業という特定の場面での計測値だ。同じ条件で「プロジェクト全体が55%速く終わる」という意味ではない。この区別を持った上で、外注先・社内エンジニアと工期の合意を作ることが、トラブルを減らす最大の方法だ。
業務効率化に特化したエンジニアとして言えるのは、期待値を現実に合わせることと、AI活用の恩恵を享受することは同時にできる、ということだ。過剰な期待をせず、かつ「うちには関係ない」と距離を置くのでもなく、何が変わるかを正確に理解することが第一歩だ。
AI顧問サービスや外部専門家の活用についてはAI活用を内製するvsAI顧問に外注する｜中小企業向け判断基準で判断軸を整理しているので、参考にしてほしい。
