この記事は、2026年6月時点での自分の考えを整理したものです。
世の中の意見や別の立場を否定したいわけではなく、あくまで今の自分にはこう見えている、という話として書いています。
AIエージェントや開発現場を取り巻く状況は変化が速いので、今後の経験や環境によって、自分の考え方も変わっていくと思っています。
はじめに
AIエージェント時代の開発について、これまで2本の記事を書きました。
1本目では、AIエージェントを抽象化の歴史の中で見ました。
2本目では、コードを書かないだけでなく、コードを細かく見ない開発感覚について書きました。
今回は、その先にある話です。
最近、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が生成した成果物を観察し、検証し、方向づける存在になっていく。
今だけの感覚かもしれませんが、それは少し怖い変化でもあります。
自分が長く向き合ってきた「プログラム」というものが、自分の手から少し離れていくような感覚があります。
でも同時に、それはソフトウェア開発が次の段階に進んでいるということなのかもしれません。
次の段階に進んだ先で何が待っているのかは、正直まだよく分かっていません。
ただ、少なくとも今の自分には、プログラムはもう人間だけのものではなくなってきたように見えています。
関連記事
この3本は、次の流れで書いています。
1本目では、AIエージェントを抽象化の歴史の中で見ました。
2本目では、コードを書かないだけでなく、コードを見ない開発感覚について書きました。
3本目では、その先にある「プログラムは誰のものなのか」という感覚について書いています。