この記事は、2026年6月時点での自分の考えを整理したものです。
AIエージェントや開発現場の変化について、世の中の正解としてではなく、今の自分にはこう見えている、という話として書いています。
今後の経験や環境によって、自分の考え方も変わっていくと思っています。
はじめに
最近、自分の開発作業では、AIエージェントをかなり使うようになりました。
少し前までのAI活用というと、次のような使い方が中心だったと思います。
- コードのたたき台を作ってもらう
- エラーの原因を相談する
- テストコードの案を出してもらう
- 既存コードを読ませて要約してもらう
でも、最近の感覚は少し違います。
AIにコードの案を出してもらうというより、
AIエージェントに実装してもらって、テストしてもらって、修正してもらう
というところまで進んできています。
もちろん、最終的な確認や判断は人間がします。
ただ、以前のように自分で一行ずつコードを書いている時間はかなり減りました。
自分の手元だけを見ると、開発の進み方はかなり変わっています。
一方で、まわりの仕事の進み方や、以前からある現場の仕事の流れを見ていると、別の違和感もあります。
実装は明らかに速くなっている。
でも、仕事全体はそこまで速くなっていないのではないか。
最近感じているのは、AIエージェントによってボトルネックが少し移動しているのではないか、ということです。
以前は、実装そのものに時間がかかっていました。
コードを読む、書く、直す、テストする。
そこにかなりの時間が使われていました。
でもAIエージェントで実装が速くなると、今度は別のものが目立つようになります。
- 仕様確認待ち
- 影響範囲の確認待ち
- レビュー待ち
- 承認待ち
- 作業範囲の判断待ち
- 次の指示待ち
つまり、実装が速くなったことで、これまで見えにくかった「仕事の流れの遅さ」が見えやすくなってきた気がしています。
この記事では、AIエージェントそのものの話というより、
AIで実装速度が上がっても、仕事の渡し方や進め方が変わらないと、開発全体は思ったほど速くならないのではないか
という感覚を書いてみます。
AIエージェントで、手元の開発はかなり変わった
AIエージェントを使うと、個人の開発作業はかなり変わります。
以前なら、まず自分でコードを読んで、修正箇所を探して、実装して、エラーを見て、直して、テストして……という流れでした。
今は、ある程度やりたいことを伝えると、AIエージェントがかなりの部分を進めてくれます。
たとえば、以下のようなことです。
- 既存コードを読んで、修正方針を出す
- 必要なファイルを変更する
- テストを実行する
- エラーが出たら原因を見て直す
- 変更内容を説明する
- 追加で必要そうな確認観点を出す
もちろん、任せっぱなしにはできません。
AIが間違えることもありますし、意図と違う修正をすることもあります。
既存の設計や現場の事情を読み違えることもあります。
それでも、以前の「コードのたたき台を作ってもらう」段階とはだいぶ違います。
自分で全部手を動かすというより、
AIエージェントに作業を進めてもらい、人間が方向を見て、確認して、必要なところを直す
という感覚に近くなっています。
この状態になると、実装だけを見ればかなり速くなります。
少なくとも、自分の手元では「AIで開発が速くなる」という感覚はあります。
大きめの単位で任せられると、AIの効果は出やすい
ここで少し補足しておくと、今の自分は、たまたま比較的大きな単位で作業できる場面があります。
たとえば、次のような流れを、ある程度まとめて進められる場面があります。
- 調査する
- 方針を考える
- 実装する
- 動作確認する
- 必要ならテストする
- 結果を整理する
こういう場合、AIエージェントの効果を感じやすいです。
なぜなら、途中で細かく止められずに、AIと一緒に一連の作業を前に進められるからです。
「この範囲を直したい」
「この仕様に合わせたい」
「このエラーを解消したい」
「動くところまで確認したい」
こういう単位で進められるなら、AIエージェントはかなり頼りになります。
なので、今の自分自身の作業だけを見ると、
AIを使っても全然速くならない
とはあまり思っていません。
むしろ、かなり速くなっています。
ただ、これは自分が特別うまくやれているという話ではありません。
たまたま、AIに任せやすい単位で作業できている場面があるだけです。
もし自分の作業も、
- 調査だけ
- この数行だけ
- 実装はまだしない
- 判断は別の人
- 次の指示が来るまで待つ
という切られ方になったら、たぶん同じようにAIの効果は狭くなると思います。
だから、これは自分とは関係ない現場の話ではありません。
仕事の渡され方や、任される範囲が変われば、自分もすぐ同じ問題の中に入ると思っています。
問題は、AIを使う人の能力だけではなく、AIに任せられるくらいの仕事のまとまりがあるかどうか なのだと思います。
仕事の切り方が細かいままだと、AIの効果は出にくい
AIエージェントは、ある程度まとまった目的があると強いです。
「この機能を直したい」
「この画面を作りたい」
「この不具合を調査して修正したい」
「この処理を整理したい」
こういう単位なら、調査、実装、テスト、修正をまとめて進めやすくなります。
一方で、仕事の切り方が細かいままだと、AIの効果はかなり出にくい気がします。
たとえば、こんな形です。
- まずこの部分だけ調査してください
- 実装はまだしないでください
- この1ファイルだけ見てください
- 修正はこの数行だけでお願いします
- テスト観点だけ出してください
- 判断は別の人がします
- 次の指示が来るまで待ってください
こういう仕事の渡され方だと、AIエージェントを使っても、速くなる範囲はかなり狭いです。
AIエージェントは、もう少し広い文脈を持たせた方が力を出しやすい気がします。
でも、仕事の単位が細かすぎると、AIに任せられる範囲も小さくなります。
結果として、AIで速くなるのは、切り出された小さな作業の中だけ になります。
仕事全体の流れは、あまり変わりません。
実装が速くなっても、待ち時間は速くならない
AIエージェントで実装が速くなると、逆に目立つものがあります。
それは、待ち時間です。
- 仕様確認待ち
- 影響範囲の確認待ち
- レビュー待ち
- 承認待ち
- 次のタスク待ち
- 「一旦確認します」で止まる時間
- 「そこは別担当です」で止まる時間
こういう時間は、AIを入れただけでは短くなりません。
極端な話、AIエージェントを使って実装が1日から1時間になったとしても、その後にレビュー待ちで2日止まるなら、仕事全体としてはそこまで速くなっていません。
むしろ、実装が速くなった分だけ、待ち時間の長さが目立つようになります。
以前は、実装そのものにも時間がかかっていたので、待ち時間がそこまで見えにくかったのかもしれません。
でもAIで実装が短くなると、
あれ、結局止まっているのはコードを書くところじゃなかったのでは？
という感じになります。
この差は、次のように見ると分かりやすい気がします。
| 速くなったところ | まだ速くなりにくいところ |
|---|---|
| 実装 | 仕様確認 |
| テスト実行 | レビュー待ち |
| エラー修正 | 承認待ち |
| 既存コードの調査 | 担当者間の調整 |
| 修正内容の説明 | 作業範囲の判断 |
| 確認観点の洗い出し | 次の指示待ち |
もちろん、右側にあるものもAIで支援できる部分はあります。
仕様確認のための論点整理や、レビュー観点の洗い出し、影響範囲の説明などはAIでかなり助かります。
ただ、最終的に誰が判断するのか。
どこまで進めてよいのか。
その変更を本当に入れてよいのか。
このあたりは、AIだけでは決められません。
だから、実装が速くなるほど、今度は人間側の判断や、現場の流れがボトルネックとして見えやすくなるのだと思います。
任される範囲が狭いほど、AIの効果は小さくなる
これは現場によると思います。
ただ、任される範囲が狭い働き方では、このズレが出やすいのではないかと思っています。
SESや客先常駐のような働き方では、特に見えやすいかもしれません。
作業者が自分の判断で進められる範囲が限られやすいからです。
AIエージェントを使っていると、作業中にいろいろ見えてきます。
たとえば、次のようなことです。
- この処理は少し整理したほうがよさそう
- この設計だと別の箇所にも影響しそう
- このテストも追加したほうがよさそう
- ここまで直すなら、周辺も確認したほうがよさそう
- そもそも仕様を少し確認したほうがよさそう
でも、現場の進め方によっては、そこで止まります。
- そこまでは今回の作業範囲ではないです
- 指示されたところだけでお願いします
- その判断は社員側でします
- お客さんに確認してからになります
- まずはこのチケットの範囲だけでお願いします
もちろん、これは悪いことだけではありません。
契約や責任範囲がありますし、勝手に作業範囲を広げるのは危険です。
特に受託や客先常駐では、慎重に進める必要があります。
ただ、AIエージェントによって個人ができることが増えているのに、仕事の任せ方が以前と同じままだと、効果はかなり制限されると思います。
AIで先まで見える。
AIで先まで作れる。
でも、仕事の仕組みとしては、そこまで進めることを求められていない。
このズレがあると、AIの効果は「手元の作業短縮」で止まりやすいです。
これはSESや客先常駐だけの話ではありません。
社内開発でも、受託開発でも、大きな組織でも、分業が強いチームでも起きると思います。
チケットの切り方が細かすぎたり、判断できる人が限られていたり、レビューや承認の流れが重かったりすれば、同じようなことは起きます。
問題は働き方の名前ではなく、AIで進められる範囲と、現場で任されている範囲がズレていること なのだと思います。
「AIを使える人」だけ増えても、現場は速くならない
最近は、案件や現場でも「AI活用経験」という言葉を見ることがあります。
でも、AIを使える人を入れただけで、現場全体が速くなるわけではないと思います。
AIエージェントを使える人がいても、仕事の流れが以前のままだと、効果は限定的です。
たぶん、AIを使う人を増やすだけでは足りなくて、
AIエージェントを使う前提で、仕事の渡し方を変えること
が必要なのだと思います。
たとえば、以下のようなことです。
- もう少し大きな単位で作業を任せる
- 調査から実装、検証まで一連で任せる
- 判断に必要な情報を最初から渡す
- どこまで自走してよいかを決める
- レビューや確認の待ち時間を減らす
- AIをどこまで使ってよいかを決めておく
- AIで速くなった後の次の流れも考える
AIエージェントは、単に「コードを書く人を速くする道具」ではなくなってきていると思います。
調査、実装、テスト、修正、整理までをまとめて進めるためのものになりつつあります。
それなのに、仕事の渡し方が「この小さな作業だけお願いします」のままだと、AIの良さはかなり消えてしまいます。
これは、AI活用を個人の努力だけに閉じない方がいい、という話でもあります。
もちろん、個人がAIを使えるようになることは大事です。
ツールに慣れることも、プロンプトの出し方を工夫することも、AIの出力を確認できるようになることも必要です。
ただ、それだけでは現場全体の速度にはつながりにくいです。
個人の手元が速くなったあとに、現場のどこで止まるのか。
誰が判断するのか。
どこまで任せるのか。
どの単位で仕事を渡すのか。
そこまで変えないと、AIの効果は小さな作業短縮で終わってしまう気がしています。
まとめ
自分自身は、AIエージェントで開発がかなり速くなっていると感じています。
コードのたたき台を作ってもらうというより、実装してもらい、テストしてもらい、直してもらうところまで進んできています。
ただ、その効果が出やすいのは、ある程度まとまった単位で作業できる場合だと思います。
まわりの仕事の進み方や、以前からある現場の流れを見ていると、仕事の渡し方が細かいままだったり、判断待ちや確認待ちが多かったりして、AIの効果がかなり狭い範囲に閉じてしまうことがありそうです。
だから最近感じているのは、こういうことです。
実装は速くなった。
でも、仕事の流れが変わらないと、仕事全体は速くならない。
AI活用というと、どうしてもツールやプロンプトの話になりがちです。
でも本当に大事なのは、AIエージェントを使う前提で、仕事をどの単位で渡すのか、どこまで任せて、どこで人が見るのか なのかもしれません。
個人の実装速度が上がることと、現場全体の開発速度が上がることは同じではない。
AIエージェントを使うようになって、むしろその差がはっきり見えるようになってきた気がします。
実装が速くなったことで、仕事のボトルネックが消えたわけではない。
むしろ、ボトルネックがどこにあるのかが見えやすくなった。
今の自分には、そんなふうに見えています。