AIを一番使ったメンバーが、一番進捗が遅かった話

皆さんこんにちは！
現役IT執行役員のグイグイです⚡

AI駆動開発を本格的に現場へ入れてみて、さっそく考えさせられることが起きました。

AIを一番使ったメンバーが、一番進捗が遅かったんです。

これは感覚の話ではありません。

GitHub Copilot EnterpriseのAIクレジット消費量と、実際の開発進捗を見比べた結果として見えたことです。

「AIを使えば使うほど生産性が上がる」という単純な話ではないことが、本格稼働してわずか1週間で見えてきました。

前提として、軽い開発ではありません

今関わっているのは、エンタープライズ領域のシステム刷新プロジェクトです。

Spring Boot / Spring Batchへの移行。
既存システムからの刷新。
一定のセキュリティ要件を伴う業務システム開発です。

仕様も複雑で設計も重い。

バッチ処理、データ連携、既存仕様の読み解き、テスト観点、セキュリティ要件など、いろいろな要素が絡みます。

その現場で、2026年6月からGitHub Copilot EnterpriseのAIエージェントモードを使ったAI駆動開発を本格導入しました。

開発者は6名。
経験1年目の若手から20年超のベテランまでいます。

6月頭から一斉に第1機能の開発を始めました。

利用指針は、事前にかなり具体化していました

ただ雑に「AI使っていいよ」としたわけではありません。

GitHub Copilotは2026年6月からAI Creditsによる従量課金制に移行しています。

インライン補完やNext Edit Suggestionsは引き続き無料ですが、Chat、Plan、AgentのようにAIに考えさせたり横断的に作業させたりする使い方ではAI Creditsを消費します。

特にAgentは消費が大きい。

そのため、AIエージェントの利用指針を整備してチームに展開していました。

基本はシンプルです。

新規実装・初回JUnitテストは、Plan → 承認 → Agent。

いきなりAgentに投げない。

まずPlanモードで方針を出させて、人間が確認・承認してからAgentに作業させる。

修正・追加作業については作業規模に応じて使い分ける方針にしました。

1〜数行の単純修正は手動または補完。
複数ファイルや複数レイヤにまたがる修正はPlan → Agent。
静的解析の単純違反は手動。
プロジェクト外の調査はMS365 Copilotを使う。

一言でまとめると、こうです。

考えさせる・横断的に直させるならPlan → Agent。
書くだけなら補完。
直すだけなら手動。

また、Agentに依頼するときは、対象SPECS、使用プロンプト、変更対象パッケージ、共通部品の扱い、セキュリティ上の注意点まで指定するようにしていました。

AIに余計なところまで触らせないためです。

特に今回のようなエンタープライズ開発では、ログ出力、例外メッセージ、既存方式からの逸脱、過剰実装などを慎重に見る必要があります。

1週間で、クレジット消費量に差が出た

第1機能の開発が進み、レビュー → 修正 → 再テストのラリーが始まりました。

ここでAIクレジットの消費量が一気に増えました。

全員同じ月間上限クレジットを設定している状態で、第1機能の完了時点に近いタイミングで消費量を確認したところ、こんな差が出ていました。

• 最も消費が少ないメンバー：26%前後

• 中間のメンバー：50%前後

• 最も消費が多いメンバー：78%

ここだけ見ると、「78%使っている人が一番AIを活用している」と見えるかもしれません。

でも実際は逆でした。

一番クレジットを使っていたメンバーが、一番進捗が悪かったんです。

これは利用量の差ではなく、使い方の差でした。

78%使っていたメンバーに起きていたこと

消費量が最も多かったメンバーの動きを見ると、パターンがありました。

エラーが出るたびに、まずAIエージェントに投げる。
仕様を十分に読まずに「直して」と依頼する。
JUnitが失敗しても、原因を自分で追う前にAIへ再依頼する。
数行で済む修正までAgentモードに任せる。
Planの確認を飛ばして、いきなり作業させる。

しかもこれは、利用指針がなかったから起きた話ではありません。

Plan → 承認 → Agent。
小さな修正は手動または補完。
対象SPECSや変更範囲を明示する。
同じ修正をAgentに何度もやり直させない。

こうした方針は事前に展開していました。

それでも実際の作業では守れていなかった。

本人としては、一生懸命AIを使っていたんだと思います。

ただ実務で見ると、これは「AIを使いこなしている」というより、分からないことをAIに丸投げし続けている状態に近い。

AIは手を動かす速度を上げてくれます。

でも、前提がズレていれば、そのズレた方向にも速く進みます。

消費量が少ないメンバーは、渡す前に整理していた

消費量が26%前後のメンバーは、進捗も良好でした。

AIを使っていないわけではありません。

ただ、Agentに渡す前に自分で整理していました。

まずログを見て、仕様を確認して、修正範囲を絞ってから依頼する。

補完で済むところは補完。
手で直した方が早いところは手で直す。
横断的に影響がある部分だけAgentに任せる。

AIに丸投げするのではなく、AIに渡す仕事を切り出していたんですよね。

何を直すべきか。
どこまで直してよいか。
その修正が仕様に合っているか。

この判断を手放していませんでした。

AIは、ベーススキルの差を消してくれない

今回あらためて感じたのは、AIを導入してもベーススキルの差は消えないということです。

むしろ見えやすくなる。

Javaの基礎理解。
Spring Batchの理解。
仕様書を読む力。
エラー原因を切り分ける力。
テストコードを読む力。
修正範囲を判断する力。

こういう地味な力がある人は、AIを使うと速くなります。

一方で、ここが弱いままAIに作業を渡すと、AIの出力を判断できない。

判断できないからまたAIに聞く。
AIが直す。
別のエラーが出る。
またAIに聞く。

このループに入りやすくなります。

AIが悪いという話ではありません。

使う側が、どこまで自分で考えて、どこからAIに任せるかを切り分けられているかどうか。

そこに差が出ます。

ルールを作っても、運用で崩れる

もう一つ現実的だなと思ったことがあります。

ルールを整備しても、実際の作業では崩れることがある。

レビュー指摘が返ってきて、エラーが出て、テストが落ちる。

その瞬間に焦る。

分からない。
早く直したい。
とりあえずAIに投げたい。

その気持ちは分かります。

ただその状態でAgentに丸投げすると、結果的に遠回りになることが多い。

だからAI駆動開発では、ツールを導入してルールを作るだけでは足りません。

消費量を見る。
進捗を見る。
必要なら介入する。
あとから振り返る。

ここまで含めて運用しないと、現場では普通に崩れます。

クレジット消費量は、使い方を見る指標になる

今回気づいたのは、クレジット消費量は単なるコスト管理の数字ではないということです。

その人がAIをどう使っているかを見る指標にもなる。

消費量が少なすぎるなら、そもそもAIを使えていない可能性がある。

多すぎるなら、投げすぎている可能性がある。

消費量が多いのに進捗が悪い場合は特に注意が必要で、「積極活用」ではなく作業の切り分けができていない状態かもしれない。

消費量。
進捗。
品質。
手戻りの量。
利用指針に沿っているか。

このあたりをセットで見ると、感覚ではなく実際に何が起きているのかが見えてきます。

まとめ

AI駆動開発を本格的に現場へ入れて1週間で、かなり分かりやすい現象が起きました。

AIを一番使ったメンバーが、一番進捗が遅かった。

しかもそのメンバーは、事前に展開していたAIエージェント利用指針を守れていませんでした。

AI駆動開発で差がつくのは、AIを使う量ではないと思っています。

利用方針を理解して、自分で判断しながら、任せる範囲を切り分けられるかどうか。

そしてAgentに任せない判断力が、任せる力と同じくらい必要だということが、この1週間で見えてきました。

AI駆動開発はまだ始まったばかりです。

きれいごとではなく、現場で起きたことをそのまま書いていきます。

#生成AI
#AI駆動開発
#GitHubCopilot
#エンジニア
#システム開発
#ソフトウェア開発
#開発現場
#AI活用
#プログラミング
#業務改善