AI にコードを書かせるようになって、3年ほどが経った。
最初はチャット欄にコードを貼る使い方だったが、その間に、自分の仕事のやり方はまるごと変わった。今は設計も実装もまず AI に任せ、自分はその理解に追いつく側に回っている。
ここでいう AI は、チャットで質問に答えてくれる AI のことではない。Cline 以降の、自分でコードを読み、どこを直すかを考え、実装まで終わらせるコーディングエージェントのことだ。
こうした変化の先で、人間がコードを書く時代は終わると私は考えている。現場で毎日 AI と働いている一人のエンジニアとして、そう考えるに至った経緯と、それでも今日をどう働くかについて書く。
Mythos が登場し、Fable の一般提供が始まった（どちらも最先端の AI モデルの名前である）。AI の進化を見るたびに、その考えは強くなっている。
この記事は、同じ立場の現役エンジニアと、AI を事業にどう活かしていくかを考えている人たちに向けて書いている。結論を先に書くと、AI に置き換わるのはコードを書くことだけではない。どの職種にも同じことが起きる。その結果、「職種」という区切りそのものが溶け、みんながソフトウェアエンジニアリングを実践するようになる。
その先がどうなるかは、わからない。だからこそ伝えたい。AI を敵とみなさず、今のポジションに固執せず、AI に任せる構えで目の前の仕事に集中してほしい。
前提：プログラミングとソフトウェアエンジニアリングは別物だ
この記事では、「プログラミング」と「ソフトウェアエンジニアリング」を分けて使う。
プログラミングは、コードを書いて、動くものを作ることだ。ソフトウェアエンジニアリングは、それより広い。作ったものを長く動かし、状況に合わせて変え続けられるようにするための、判断の積み重ね全体を指す。『Software Engineering at Google』には、こう書かれている。
software engineering can be thought of as “programming integrated over time.”
ソフトウェアエンジニアリングとは「時間で積分したプログラミング」だ、ということだ。
今 AI に移っているのは、プログラミングだけではない。どう組み立てるかという設計の手も、すでに AI に移りつつある。それでも人間に残るものがある。何を達成したいのかを決め、それをチームでそろえることだ。長く動かし、変え続けるには、それが欠かせない。この記事で「人間がコードを書く時代は終わる」と言うとき、終わるのは作る手のほうであって、このソフトウェアエンジニアリングの芯ではない。
Cline で「コードを書く作業はほとんど代替された」と感じた
最初に危機感を覚えたのは、2024年ごろに Cline（エディタの中で動く AI コーディングツール）が出てきたときだ。
それまでの AI の使い方はこうだった。不具合の原因や機能を追加する場所は、人間がソースコードとアーキテクチャを読んで特定する。該当するコードをチャット欄に貼りつけ、AI に解決策を提案してもらう。返ってきたコードをコピーして貼るか、参考にして自分で書く。
Cline は、この地道な作業をまるごと引き受けた。Cline は内部のツールを使ってプロジェクトのソースコードを読み、モデルに必要なコンテキスト（判断材料として AI に渡す情報）を自分で集める。そのうえでアーキテクチャを把握し、要件に対してどこを直し、どこにコードを足すべきかを特定して、実装まで終わらせる。
これを見たとき、エンジニアがコードを書くためにやってきた作業は、ほとんど代替されてしまったのだと感じた。いずれはコードを書くこと自体が必要なくなるのだろう、とも思った。ただ、それはもっと先の話だと考えていた。
その後、mizchi さんの「CLINEに全部賭けろ」（2025年2月）という記事を読んで衝撃を受けた。mizchi さんは、プログラマの価値についてこう書いている。
プログラマというのはコードを書く作業員ではなく、対象のドメインを抽象して構成要素を分解・再構築する思考訓練を受けた専門家だと思っているからだ。
コードを書く作業が AI に移っても、その思考こそがプログラマの価値として残る、という見方だ。
私も、コードを書く作業が人間の手を離れていくという点では同じ考えである。違うのは、その先だ。ドメインを抽象化して分解・再構築する思考も、プログラマだけの専門性ではなくなっていくと、今の私は考えている。そう考えるようになったのは、その後の1年半あまりの進化を目の当たりにしたからである。
Fable で、レビューで指摘することがなくなった
2025年の終わりから2026年にかけて、Opus 4.5 以降のモデルと AI エージェントは目に見えて進化していった。そのたびに危機感は強くなった。そして Fable で、ついにソースコードを読んでも指摘することがほとんどなくなった。指摘があったとしても、レビュー10回のうち2回くらいだろうか。しかも、その数少ない指摘でさえ、こちらが納得させられて終わることがある。
日本語で要件を伝え、AI に実装させる。この精度がとてつもなく高い。書かれたコードを一つひとつ人間がレビューする必要性を、私はもうあまり感じていない。全体の目線合わせまで要らないという意味ではないが、それは後で書く。
AI に反論されて、納得してしまった
象徴的だった出来事がある。
あるとき、トランザクションまわりのフォールバック処理について、可用性が損なわれるのではないかと指摘したことがある。細かい内容はもう覚えていない。ただ、AI から返ってきた説明はとても具体的で、私のほうが納得してしまった。（私は AI の出力をいきなり否定しない。まず「なぜこう書いたのか」と理由を聞く。答えに穴があれば、そこで初めて修正を頼む。そういう進め方をしている。）
そのとき最初に思ったのは「自分の考えを押し通さなくてよかった」ということだ。そして同時に、この作業はもう人間がやらなくてもいいのではないか、とも思った。
私の仕事は、AI の設計に理解を追いつかせることになった
今の私の仕事の進め方はこうだ。やりたい事だけ可能な限り具体的に伝え、設計は AI に丸投げし、大枠を描かせる。気になったところを質問し、ブラッシュアップしていく。
ただ、このブラッシュアップは、AI の設計を私が直す作業ではない。私の理解を AI の設計に追いつかせる作業と言ったほうが近い。AI が出してきたものを真っ向から否定することは、今はもうほとんどない。
それでも理解に追いつこうとしているのは、上司やチームに説明する責任があるからだ。ただ、これも半分は私の個人的なこだわりである。本当に生産性に振り切るなら、細部の理解はスキップしていいのではないか。そう思っている自分もいる。
普通のエンジニアの実装力は、もう AI が超えている
少なくとも私の体感では、今の AI は一般的なエンジニアを超えている。
納得させられたことが、AI が正しかった証明にならないのは分かっている。私のエンジニアとしての能力が、トップエンジニアから見ればそれほど高くないから見抜けなかった、という可能性もある。それでも、一般的なエンジニアくらいの能力はあると自負している。その私が、指摘する箇所をほとんど見つけられなくなった。
これは私一人の感覚ではない。数学の世界では、AI が人類の見つけられなかった答えを見つけ始めている。2026年5月、OpenAI の AI モデルが、ポール・エルデシュが1946年に立てた単位距離問題の予想に反例を見つけた。80年近く、誰も崩せなかった予想である。The Conversation の記事は、この成果をこう評している。
This breakthrough also represents the first major mathematical open problem solved with AI with minimal human intervention beyond the initial prompt.
最初の指示のほかはほとんど人の手を借りずに、AI が数学の大きな未解決問題を解いた初めての例だ、ということだ。フィールズ賞を受けた数学者のティモシー・ガワーズも、人間がこの論文を数学の最高峰の学術誌に投稿していたら「ためらいなく」掲載を推薦しただろう、と述べている。
数学でさえそうなのだ。コードの世界で、AI が普通のエンジニアを超えていても不思議ではない。
ドラゴンボールで例えるなら、たいていのプロジェクトにいるのはクリリンである。サイヤ人には及ばないが、地球人としてはかなり頑張っている。そのくらいのエンジニアだ。そして、そのレベルはもう完全に AI が超えている。
コードを書く力で AI を上回れるのは、トップオブトップのエンジニアくらいだろう。ただ、トップオブトップが必要な現場は、実はそれほど多くない。それほどの人材は報酬の高いところにしか行かないから、普通の事業会社でコードを書く仕事は、AI が担うようになっていくのではないだろうか。
AI は自然言語のコンパイラになった
かつて人間は、プログラミング言語でコードを書き、コンパイラがそれを機械語に変換していた。今は、人間が自然言語で要件を書き、AI がそれをプログラミング言語に変換する。AI は、自然言語をプログラミング言語に置き換えるコンパイラになった。
こう書くと「では、要件を正確に言葉にできる人が新しいプログラマになるのか」と思うかもしれない。言語化の能力は、たしかに必要だ。ただ、それはすべてのビジネスパーソンに昔から求められてきた力であって、新しく必要になったものではない。
つまり、プログラミングというスキルはもう特別なものではなくなった。言語化を磨き続けてきたビジネスパーソンは、エンジニアであってもなくても、引き続き活躍できるだろう。市場がその人を求め続けるのであれば、だが。
AI に任せる線引きを、会社が先に決める
AI 導入がうまくいかない会社は多い。その原因は、AI に権限を渡せないことにあると私は考えている。ここで言う権限とは、作業の実行や承認を AI に任せることだ。
任せるには、AI にコンテキストを渡さなければならない。コンテキストを渡すとは、何を渡して何を渡さないかを決めることである。つまり線引きの対象は、任せる業務の範囲と、渡す情報の範囲の両方だ。この線引きこそが決断であり、ここで怖がる会社、結論を先送りにする会社が負けていく。
社内の承認フローが AI を想定していない。PR のマージ（コードの変更を本体に取り込む最終承認）は必ず人間がやる。こうしたルールも、AI に権限を渡せていない例である。
線引きを会社として先に決めた例もある。DeNA は2025年、AI イノベーション事業本部で、新しいプロダクトの企画の進め方を変えた。ITmedia AI＋の記事はこう伝えている。
新規プロダクトの企画時は、まず生成AIなどで開発したプロトタイプを持ってくること、企画書のみ提出はNG
対象はエンジニアだけではない。ビジネス職やデザイナーも含めた本部の全員である。さらに全社では、社員一人ひとりの AI 活用レベルを5段階で測る指標を設け、半期ごとに目標を立てて追っている。人事評価に直結させるのではなく、等級ごとに期待される要素として扱っているという（ITmedia AI＋）。
AI を使うかどうかを個人の判断に任せず、仕事の進め方と目標の側に組み込んでいる。どこから任せるかを、会社が先に決めているのだ。
人間を挟んだところが、遅れにも穴にもなる
人間が監督しなければならない場面は、まだある。ただ、それは AI に渡せていないコンテキストがあるからだと思う。
人間の手を挟む余地を作ると、そこで人間が何を考え、何を基準に判断したかは、AI からは見えなくなる。そして、その見えない範囲がボトルネックになる。その結果、流れが遅くなるだけでなく、AI の知らない判断が紛れ込んでずれの元にもなる。普通は人間のチェックを安全装置だと考えるが、私は逆に、そこが穴になると見ている。
これは私だけの見方ではない。Google Cloud の研究チームである DORA は、2019年の State of DevOps Report で、変更を本番に出す前に外部の承認を挟む重いプロセスを調べている。DORA の解説ページによれば、結果はこうだった。
no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates.
より正式な承認を挟んでも、変更の失敗が減るという証拠は見つからなかった、ということだ。DORA が調べたのは外部の重い承認プロセスについてだが、人間の関門が安全装置になるとは限らないことは示している。むしろ承認が重いほどリリースは遅れて大きな塊になり、かえってリスクが上がるという。安全装置のつもりで挟んだ人間の関門が、守りにならず、流れを止めているのである。
では、人間は何をするのか。一つひとつの変更を承認する役から、何を達成したいのかを決めて AI と共有する役へ移るのだと思う。全体の整合を守るのは、承認の関門ではなく、最初にそろえた目線である。
これは遠い未来の話ではない。私の現場では、AI の判断に納得させられることがすでに増えている。だから、人間に作業を戻さない前提で、任せる範囲を今決めるべきだ。
会社が AI を活かせるかは三つで決まる
日々、最先端の AI 活用を現場で実践している立場から言えば、会社が AI を活かせるかどうかは三つで決まると考えている。AI に何を渡すかの線引きを、先送りせずに決められるか。承認フローを、AI が担う前提で組み直せるか。そして、任せるという判断を上から下せるか、である。
日本では、ベンチャーにジャイアントキリングのチャンスがある
この三つを一番速く決められるのは、身軽な会社だ。日本では、ベンチャーが勝つと私は考えている。
今の制度では、人を辞めさせることが難しい。人を多く抱える大企業にとって、それは足枷になっていく。人件費を払い続けながら、AI のコストも払うことになるからだ。
一方でベンチャーは、期待値の高い事業を提案して資本家から投資を集め、そのお金を人ではなく AI に回し、少人数でビジネスを始められる。身軽さと資本の両方を持てる。これはベンチャーがジャイアントキリングを起こすチャンスである。
溶けていくのは「職種」という区切りだ
何を達成したいのかという目線をそろえる力は、職種を問わず誰もが持つべき基礎になる。そして職種の垣根なしに、残った仕事にみんなで取り組むようになる。
ここまで読むと、こう反論したくなる人もいるだろう。それでも、大きなシステムの設計にはエンジニアが要るのではないか、と。
Ruby on Rails の作者である DHH も、2026年8月の Lex Fridman Podcast #501 で似た話をしている。Basecamp 5 の最後の追い込みで、DHH のチームはデザイナーに AI を使って好きに機能を作らせた。PR 一つひとつは問題なかったが、合わさるとこうなった。
taken all together, destroyed the architecture of the system. And we actually had to clean up manually, mop it up by hand, by human hand
ただ、DHH はこう付け加えている。
that was February, by the way. Things are quite different now.
あれは2月の話で、今はかなり違う、ということだ。
ここで、私の言う「レビューが要らない」の範囲をはっきりさせておきたい。私が不要だと感じているのは、書かれたコードを一つひとつ見るレビューのほうだ。全体として何を目指すのかがそろっていなければ、正しい部品をいくら積み上げても壊れる。Basecamp 5 で起きたのは、誰か個人の落ち度というより、一つひとつの PR をつなぐ目線をそろえる仕組みがまだなかった、ということだと思う。
その目線をそろえる役は、エンジニアという職種だけが担うものではない。AI に何かを作らせる人なら、職種を問わず誰もが身につけなければならない基礎になる。言語化と同じだ。
プログラミングに限らず、どの職種にも AI に置き換わる部分がある。それが抜け落ちたあとに残ったものを、職種の垣根なしにみんなで取り組む。私が思い描いているのは、そういう姿である。
みんながソフトウェアエンジニアリングを実践するようになる
冒頭の前提で書いたとおり、人間に残るのは、何を達成したいのかを決め、チームでそろえることだ。これはエンジニアだけの仕事ではない。むしろエンジニア以外の人にも広がり、みんなが実践するものになっていくのだと思う。
そろえるとは、具体的には、何を達成したいのかという目線と、その解像度をチームで共有できていることだ。
だから、目線と解像度をそろえられない人数で物を作るべきではない。人数が少なくても、それができないのであれば、一人でやるほうがいい。チームの人数を決めるのは、作業の量ではなく、目線をそろえられるかどうかになる。
DHH は、同じポッドキャストでこうも話している。
the bottleneck is rarely implementation. It's human bandwidth and communication.
ボトルネックは実装ではなく、人間の処理能力とコミュニケーションだ、という話である。これも、先に書いた「人間を挟んだところが穴になる」も、根っこは同じだと思う。挟まった人の判断が AI から見えず、目線がずれていくから、そこが遅れにも穴にもなるのだ。
得意な枝葉にこもるほど、AI とぶつかる
解像度が共有できていないと感じるのは、幹の話をせずに枝葉の議論を好む人がいるときだ。ここで言う幹とは、会社のビジョンに照らして何を達成したいのか、という話である。
なぜ人は枝葉の議論を好むのか。枝葉のほうが自分の得意分野で、安心できるからだと思う。長年かけて身につけた知識が活きるし、議論すれば自分の価値を示せる。
ただ、その枝葉、たとえば実装の細部やコーディング規約は、まさに今 AI が人間より上手くこなす領域である。私自身、規約を細かく伝えても、AI に筋の通った反論を返された。得意分野にこもるほど、AI と真っ向からぶつかる場所に立ち続けることになる。AI を敵だと捉えてしまう人の具体的な姿は、これなのだと思う。
偉そうに書いたが、私にとってもプログラミングは、得意で安心できる枝葉だった。幹のほうへ目線を移そうとしているが、正直に言えば、まだ移っている途中である。私を枝葉へ引き戻すのも、やはりそこが自分の得意な領域だからだ。
この先どうなるかは、わからない
ここから先は、さらに遠い未来の話になる。近い未来の本線は、ここまで書いてきた「みんながソフトウェアエンジニアリングを実践する」姿だ。そのさらに先には、もっと厳しい可能性も見えている。
最後はお金を持つ人が勝つのかもしれない
AI が AI を呼ぶサブエージェント（AI が別の AI に仕事を振り分ける仕組み）が進めば、人間のように役割をリレーして仕事を進められるようになる。そうなれば、人間の社員はいずれ要らなくなる。資本家や社長が一人で、ビジョンを描き、お金を払い、システムをデプロイ（本番環境に公開すること）する。
そこでは、お金を持つ人がさらにお金を稼ぎやすくなる。お金がなければ、AI の利用料を払えない。何かを作っても、公開する環境を用意できない。外部のサービスと連携したくても、その料金を払えない。やりたいことがあって、お金もある人が独り勝ちする。これが、私の思い描く最終形の一つである。
それでも、未来を予測しすぎない
ここまで遠い未来まで書いておいてなんだが、自分でも自信はない。職種の垣根を越えてみんなで取り組む「残ったもの」は、ずっと人間の仕事として残るのだろうか。それとも、それもいずれ AI に置き換わるのだろうか。
正直に言うと、わからない。
DHH は先ほどのポッドキャストで、若い開発者へのアドバイスを聞かれて、最初にこう答えている。
Don't try to anticipate anything. You will literally go crazy.
未来を予測しようとするな、本当におかしくなるぞ、という意味だ。業界で一番賢い人たちでも、2モデル先に何が起きるかはわからない。だから今に集中しろ、という趣旨である。
私もそう思う。遠い未来の予測は、行動の根拠にしない。ただ、今すでに起きていることには、今決断する。未来が読めないからこそ、今日の決断を先送りしないことが大事なのだと思う。
寂しさはある。それでも、次に行くしかない
ここで、私自身の気持ちを書いておく。
プログラミングは、私が情熱を注いできたものだ。それがもう人間の仕事ではなくなりつつあることに、寂しさは感じている。
ただ、次に行くしかない。仕事そのものが目的の人なら、寂しさはもっと大きく、今のポジションを守りたくなるだろう。私はどちらかというと仕事を手段だと捉えているので、そこは割とさっぱり切り分けられている。
これからエンジニアを目指す人には、黙々とコードを書く仕事は、これからほとんどなくなると伝えたい。大事になるのは、人とのコミュニケーションと、作りたいものがはっきりしていること、つまり自分の考えを持つことだ。社会が求めているものと、自分が達成したいこと。その二つの一番前向きな落としどころを見つけ、そこに集中してほしい。
AI を敵とみなさず、ポジションを手放す構えで今に集中する
最後に伝えたいのは、AI との付き合い方である。
AI を、自分の立場を脅かす敵だと捉えている人こそ一番危ない。自分のポジションに固執せず、いざとなったらすぐ捨てられる状態にしておく。今の自分の立場がなくなるかもしれない、いわば破滅の未来を、前向きに受け入れる。
私自身は、設計もまず AI に任せ、否定する前に理由を聞くようにしている。そして、得意な枝葉の議論から、何を達成したいのかという幹の話へ、少しずつ目線を移そうとしている。エンジニアにとっての構えは、ここから始まると考えている。事業を動かす側にとっては、AI に何を渡すかの線引きを先送りせず、任せる判断を上から下せるかどうかがすべてだと思う。
そういう構えで、今日の仕事に臨むことが大事なのだと思う。