この記事は、2026年5月時点での自分の考えを整理したものです。
世の中の意見や別の立場を否定したいわけではなく、あくまで今の自分にはこう見えている、という話として書いています。
AIや開発現場を取り巻く状況は変化が速いので、今後の経験や環境によって、自分の考え方も変わっていくと思っています。
はじめに
AIコーディングエージェントが、いよいよ開発現場のかなり近いところまで入ってきたと感じています。
少し前までは、AIにコードを書かせる話は「補完が便利」「サンプルを出してくれる」くらいの感覚で語られることが多かった気がします。
でも最近は、もう少し違います。
Claude Code、Codex、Copilot、Cursor などの名前が普通に出てきて、AIにタスクを渡し、複数ファイルを編集させ、テストを走らせ、PRや修正案まで持っていく。
そういう話が、個人開発の遊びだけではなく、実務寄りの話題として出てくるようになりました。
OpenAIのGPT-5.5も、コーディング、研究、データ分析などの複雑なタスクを意識したモデルとして紹介されています。
JetBrainsの調査でも、開発者向けAIツールの利用がかなり一般化していることが示されています。
もちろん、調査対象や地域、職種によって体感は違うと思います。
日本の現場では、セキュリティや契約、社内ルールの都合で、まだ自由に使えないところも多いはずです。
それでも、大きな流れとしては、AIコーディングエージェントが「ちょっと便利な補助」から「仕事の渡し方を変える存在」になりつつあるように見えています。
最初は、自分もこの変化を 「書く」から「任せて確認する」へ という言葉で考えていました。
ただ最近は、それだけでは少し足りない気がしています。
AIに作業を任せる。
出てきたものを確認する。
もちろん、それは大事です。
でも本当に変わっていくのは、そこだけではないのかもしれません。
AIエージェントに何を任せるのか。
どこまで任せるのか。
何を禁止するのか。
どのタイミングで人間が止めるのか。
どう検証するのか。
複数のAIエージェントをどう分担させるのか。
そう考えると、プログラマーの仕事は、単に「任せて確認する人」になるというより、AIエージェントが安全に働ける仕組みを設計する人 になっていくのではないか。
今はそんなふうに感じています。
この記事では、その変化について、自分の現場感として整理してみます。
「AIがコードを書く」は、もう珍しい話ではなくなった
今のAIコーディングエージェントは、単に1行の補完をするだけではありません。
リポジトリを読み、実装方針を考え、複数ファイルを変更し、テストを実行し、失敗したら直す。
もちろん、毎回うまくいくわけではありません。
変な実装をすることもありますし、意図を取り違えることもあります。
既存設計を十分に読まずに、少し強引な修正をすることもあります。
それでも、以前の「AIにコードを少し書いてもらう」感覚とは、かなり違うところまで来ていると思います。
自分の体感では、AIに任せられる範囲が広がったことで、開発中に考えていることが少し変わりました。
以前は、次のようなことを、自分の手元で細かく考えていました。
- どういうコードを書くか
- どの関数に分けるか
- どのファイルに置くか
- どのAPIを呼ぶか
- どうテストを書くか
今は、それらの一部をAIに渡して、次のようなことを見る時間が増えています。
- 何を作りたいのか
- どこまで変えてよいのか
- 何を守ってほしいのか
- 出来上がったものが期待通りか
- どこにリスクがありそうか
つまり、仕事の中心が「書く」から「任せる」方向へ少しずつ寄っている感覚があります。
ただし、ここで終わりではない気がしています。
任せるだけなら、AIに詳しい個人の工夫で済むかもしれません。
でも、実務でAIエージェントを使うなら、もっと大事なのは、AIが安全に作業できる環境や流れをどう作るか なのだと思います。
任せるというより、仕事を渡す感覚に近い
ここでいう「任せる」は、丸投げとは少し違います。
AIに何も考えずに投げて、出てきたものをそのまま使うという話ではありません。
むしろ、自分の感覚では、AIコーディングエージェントを使うほど、仕事の渡し方が問われるようになります。
たとえば、次のようなことを伝えないと、AIはそれらしく進めてしまいます。
- この変更の目的
- 変更してよい範囲
- 触ってほしくない領域
- 既存設計で守りたい考え方
- 優先したいこと
- 後回しにしてよいこと
- 確認してほしい動作
人間に仕事を頼むときも同じですよね。
「この画面を直しておいて」だけでは、背景も判断基準も伝わりません。
相手が優秀でも、前提が足りなければ、期待と違うものが出てくることがあります。
AIも同じで、能力が高くなるほど、曖昧な指示に対してもそれらしい答えを出します。
だからこそ、こちらが何を渡し、何を渡していないのかが見えやすくなる気がしています。
AIの使い方の問題に見えて、実は仕事の渡し方の問題だった。
最近はそう感じる場面が増えました。
そしてさらに言えば、仕事を渡すだけでもまだ足りないのかもしれません。
人間のチームでも、仕事を頼むだけではチームは回りません。
役割がある。
責任範囲がある。
レビューの流れがある。
承認のルールがある。
失敗したときの戻し方がある。
やってはいけないことが決まっている。
AIエージェントも、実務で使うなら同じように、作業の仕組みが必要になります。
プログラマーの仕事は「書く量」では測りにくくなる
AIコーディングエージェントが本格的に入ってくると、プログラマーの仕事を「どれだけコードを書いたか」で見るのは、ますます合わなくなると思います。
もともと、コード量は価値そのものではありません。
少ないコードで済むなら、その方がよい場面も多いです。
ただ、AIが大量のコードを書けるようになると、この感覚がさらに強くなります。
人間が1日かけて書いていた実装を、AIが短時間で出してくる。
そうなると、人間の価値は「たくさん書けること」だけでは説明しにくくなります。
代わりに重みが増すのは、こういう部分かなと思っています。
- 作るものの目的を言語化する
- 仕様の曖昧さに気づく
- 変更範囲を見極める
- AIの出力を動かして確認する
- リスクの高い部分を重点的に見る
- 期待と違うところを説明する
- 必要なら前提から見直す
これは、コードを書かなくていい楽な仕事になるという意味ではありません。
むしろ、「何が正しい状態なのか」を人間が定義しないといけない場面が増えるので、別の難しさが出てくると思います。
AIが速く書けるほど、間違った方向にも速く進めてしまいます。
だから、速く書く力よりも、止める力、戻す力、確認する力、前提を整える力の重みが増していくように見えます。
ただ、ここで人間が毎回すべてを手作業で止めたり、確認したりするのも限界があります。
AIエージェントが増えるほど、人間ががんばって見守るだけでは追いつかなくなる。
だからこそ、確認や停止や差し戻しも、仕組みとして設計していく必要があるのだと思います。
確認するだけではなく、確認できる仕組みを作る
AIに任せる開発で難しいのは、確認の仕方です。
以前なら、コードレビューで差分を読み、設計や実装を確認することが中心でした。
もちろん、今でもコードを見ることは大切です。
認証、認可、課金、個人情報、データ削除、権限境界、外部API連携のような部分は、AIが書いたからといって軽く扱うのは怖いです。
ただ、AIが複数ファイルを一気に変更するようになると、すべての差分を人間が同じ粒度で読むのは、だんだん現実的ではなくなってくる気もしています。
そのとき、確認はコードを眺めることだけではなくなります。
- 実際に動かす
- テストを走らせる
- 失敗する条件を探す
- 想定外の入力を試す
- 画面やログを見る
- 差分の中でリスクの高い場所を絞る
- 仕様と照らしてズレを見る
こういう確認の比重が増えていくと思います。
ただ、これも人間が毎回全部やるだけでは厳しいです。
AIエージェント時代には、確認そのものも開発プロセスの中に組み込まれていくのではないかと思っています。
たとえば、次のような仕組みです。
- AIが変更したら自動でテストが走る
- Lintや型チェックが必ず走る
- 危険なファイル変更は人間承認を必須にする
- 認証・認可・個人情報まわりは追加レビューを必須にする
- 変更範囲を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に渡せる仕事を作る」は、単にタスクを細かく書くことではありません。
AIが迷わないように前提を整える。
AIが触ってよい範囲を決める。
確認方法を用意する。
失敗したときに止まる条件を作る。
必要なところで人間が入れるようにする。
そういう設計全体の話です。
整理すると、「任せる仕組み」には、次のような要素があると思います。
| 設計するもの | 内容 |
|---|---|
| タスクの切り方 | AIに渡せる粒度に分解する |
| 前提情報 | 目的、制約、背景、禁止事項を渡す |
| 権限 | どこまで変更・実行してよいか決める |
| 検証 | テスト、ビルド、Lint、動作確認を用意する |
| 停止条件 | どこで人間の確認を挟むか決める |
| ロール分担 | 実装、レビュー、調査、テストを分ける |
| ログ・説明 | AIが何をしたか追えるようにする |
| 差し戻し | 失敗したときに戻せるようにする |
このあたりを考えると、プログラマーの仕事は「AIを操作する人」や「AIを見守る人」だけでは説明しきれない気がします。
むしろ、AIエージェントが成果を出せるように、任せる単位、ルール、確認、責任の流れを設計する人になっていくのかもしれません。
AIエージェントのチームを設計する人になるのかもしれない
さらに進むと、1つのAIエージェントに何でも任せるという形だけではなくなっていく気がしています。
人間の開発チームでも、すべてを1人でやるわけではありません。
調査する人。
設計する人。
実装する人。
レビューする人。
テストする人。
リリースを確認する人。
役割があります。
AIエージェントも、今後は似たように分かれていくのかもしれません。
たとえば、
- 既存コードを読むAI
- 実装方針を考えるAI
- コードを変更するAI
- テストを作るAI
- レビューするAI
- セキュリティ観点を見るAI
- 変更内容を説明するAI
- ドキュメントを更新するAI
というように、役割が分かれていく。
そのとき人間は、1体のAIに「よろしく」と頼むだけではなくなります。
どのAIに何を任せるのか。
どの順番で動かすのか。
どの情報を共有するのか。
どの出力を次のAIに渡すのか。
どこで人間が確認するのか。
どのAIの判断は参考にとどめるのか。
そういう流れを設計する必要が出てきます。
これは、開発チームを設計することに少し似ている気がします。
人間のチームであれば、メンバーの役割、責任範囲、レビューの流れ、リリースの承認、障害時の対応を考えます。
AIエージェントのチームでも、同じように、役割、権限、確認、停止条件、責任の流れを考える必要が出てくる。
そうなると、プログラマーの仕事は「AIに頼む人」ではなく、AIエージェントのチームが安全に成果を出す構造を作る人 に近づいていくのかもしれません。
この表現の方が、自分の感覚にはかなり近いです。
単純にコントロールする人。
単純に見守る人。
そういう結論には、あまりしたくありません。
人間が上からAIを監視するだけ、というより、AIが働ける環境を作り、必要なところで止まり、必要なところで人間が入り、成果物として成立する流れを作る。
その「任せるシステム」を設計することが、これからの開発でかなり重要になっていくのだと思います。
それでも、書けることは無駄にならない
ここまで書くと、「もうコードを書けなくてもいいのか」と読めるかもしれません。
でも、自分はそうは思っていません。
コードを書けること、読めること、仕組みを理解できることは、AI時代でもかなり効いてくると思います。
AIの出力がおかしいときに、どこが怪しいか見当をつける。
テストが落ちたときに、原因の方向性を考える。
設計として変なところに気づく。
セキュリティやデータ破壊の怖さを判断する。
このあたりは、コードを書いてきた経験があるほど強いです。
ただ、その力の使いどころが変わるのだと思います。
全部を自分で書くための力から、AIが出したものを見極めるための力へ。
細部をすべて手で組み立てる力から、全体の方向やリスクを判断する力へ。
そして、AIが安全に作業できる仕組みを設計する力へ。
なので、新人やこれから学ぶ人が、コードを書く練習をしなくていいとは思いません。
むしろ、小さく作って、小さく壊して、小さく直す経験は、AIに任せるようになってからも役に立つはずです。
AIに任せるためにも、最低限の手触りはあった方が安心です。
おわりに
AIコーディングエージェントが本格的に開発現場へ入ってきたことで、プログラマーの仕事は少しずつ変わっていると思います。
以前よりも、コードを一行ずつ書く時間は減っていくかもしれません。
その代わりに、何を作るのかを決め、AIに仕事を渡し、出てきたものを動かし、確認し、必要なら前提から直す。
最初は、この変化を「書く」から「任せて確認する」へ、という言葉で考えていました。
でも最近は、それだけでは少し足りない気がしています。
AIエージェント時代のプログラマーは、単に「書く人」から「任せて確認する人」になるだけではないのかもしれません。
むしろ、AIに任せられる単位を作り、前提を整え、権限を決め、検証を組み込み、必要なところで人間が止められるようにする。
つまり、AIエージェントが安全に働ける仕組みを設計する人 になっていくのではないか。
今の自分には、そんなふうに見えています。
これは、プログラマーの仕事が簡単になるという話ではありません。
書く作業が減る代わりに、任せる単位、確認の仕組み、前提の揃え方、責任の持ち方が問われる。
AIが強くなるほど、人間は「何が正しいのか」「どこまで任せるのか」「どこで止めるのか」「どう検証するのか」を考えることになります。
便利だから使う。
速いから使う。
それだけではなく、AIエージェントが安全に働ける仕組みをどう作るのか。
そこを、しばらく考え続けることになりそうです。