はじめに
先日、非エンジニアが GitHub の Issue を書くと、AI が要件を質問で詰めて、実装して、PR を出すところまで自動で進む仕組みを作った。
技術的な中身とハマった穴は別記事に書いたので、そっちを読んでほしい
この記事はその続きというか、裏側。作り終えて最初に口から出た言葉が「エンジニアの仕事、無くなっちゃうな」で、そこから数日かけてその直感がどう変わっていったかの話。ポエム寄りだけど、データも置いておく。
僕はコードをほぼ 1 行も書かなかった
まずこれが面白かった。導入作業の 4 日間、アプリのコードはほぼ 1 行も書いてない。なのに振り返ると、ずっとエンジニアリングをしていた。仕事の中身が入れ替わってたんだと思う。何に入れ替わったか、具体例で書く。
その 1: コードを書く代わりに、規約を書いていた
導入の途中で「GitHub 上だと AI の質問が 3〜4 件で頭打ちになる」という不具合があった。調べたら、原因のひとつは AI が「多すぎるかもしれない」と空気を読んで、質問を自分で削ってたこと。
AI は放っておくと無難な平均に回帰する。個人的な言い方をすると、尖ってない。で、その対策として書いたのはコードじゃなくてこういう文章だった。
質問の数に上限は無い。自己検閲を禁止する。聞き漏らして誤った実装をするより、多く聞くほうが常に良い。
自分の哲学を規約に翻訳して、仕組みに焼き込む。手でレビューして直すのは 1 回きりだけど、焼き込んだ規約は以後の全案件に効き続ける。この「焼き込み」の感覚を覚えたのが、今回いちばんの収穫だった。プロンプトエンジニアリングというより、組織のルールブックを書く仕事に近い。
その 2: アプリじゃなくて、AI の働く基盤を直していた
上の「質問が出ない」バグの調査は、ログを読んで、ドキュメントと突き合わせて、仮説を実測で潰す——完全に普通のデバッグだった。違ったのは対象がアプリじゃなくて AI を働かせるパイプラインそのものだったこと。
AI を導入したら仕事が消えるんじゃなくて、AI を働かせ続けるための仕事が生まれる。基盤は壊れるし、直すのはエンジニア。
その 3: 「作る」より「触らせないものを決める」
AI に触らせないパスをどこまでにするか(デプロイスクリプト? CI 定義?)。コストの蛇口をどこに置くか。どのブランチ保護を必須にするか。ここは AI が 1 ミリも決めてくれない。そして、ここの判断の質がそのままシステムの安全性になる。
その 4: 実装の速さより、判断の質
導入中、使い捨ての検証環境をどう建てるかで、AI が設計案を 2 つ丁寧に分析し終えたあとに、こっちの「ローカル開発環境と同じ構成にすればよくない?」の一言でどっちの案よりも良い答えが出た場面があった。既存の安全ガードがそのまま効いて、検証済みの Docker 構成が再利用できて、再現性も上がる。
AI は選択肢を高速で網羅する。でも、文脈を全部知ってる人間の一手はまだ別格。10 割を超えた 12 割側の仕事って、こういうやつだと思う。
で、気づいたこと
そもそも実装なんてエンジニアの仕事の 1 割くらいだったんですよね。
AI が食ったのは、その 1 割の、さらに 7〜8 割にすぎない。要件を聞く、判断する、危険を見積もる、仕組みを設計する、壊れたら直す——残りの 9 割は最初からコードの外にあって、AI が来たことでむしろ輪郭がはっきりした。
世間はどうなのか調べた
自分の感覚が合ってるのか不安になって調べたら、拍子抜けするくらい一致してた。
「AI は 7〜8 割」には名前がついてた。 Google のエンジニアリングリーダー Addy Osmani が 2024 年末に書いた「The 70% Problem」——AI は 7 割まで一気に到達するけど、最後の 3 割(エッジケース・セキュリティ・本番統合)が最難関のまま残る——はこの分野で一番引用される論考のひとつで、2026 年には「The 80% Problem」に更新された。到達点は上がり続けるのに、「最後が最難関」という構造は変わらない。
データも同じ方向を指してる。
- AI 導入チームの実測: PR マージ数 +98%、レビュー時間も +91%(Faros AI 調査)。つまり「コードレビューが新しいボトルネック」
- Stack Overflow 調査: AI 利用率 84%、なのに出力を高く信頼する人は 3%。66% が「"ほぼ正しい" AI コードの修正に使う時間が増えた」と回答
- Google の DORA 調査: AI 導入はスループットを上げるが、デリバリーの安定性とは負の相関
作る速度が上がったぶん、確かめる側に仕事が積み上がってる。世間はこの転換を「implementer(実装者)から orchestrator(編成者)へ」と呼んでた。僕の言葉で言えば「10 割に持っていくのが仕事になる」——ほぼ同じことを、世界中が同時に言ってる。
あと意外だったのは自分たちの位置で、エージェントを日常的に使う開発者は世界でまだ 14% しかいない。大半の「AI 導入」はエンジニアが補完ツールを使う段階で止まってて、非エンジニアまで開いて配線し切った組織は少数派の先頭にいるらしい。先頭には前例がないので、最初に転ぶ役が回ってくる。実際、世界の誰かのブログで読む前に自分たちでバグを踏んで直した。まあ、その転んだ記録がそのまま次のプロダクトへの導入手順書になったので、悪い話でもない。
心配ごとも書いておく
ジュニアの育成問題。最後の 2〜3 割を埋める判断力って、本来「実装の下積み」で育つものだったはず。その下積みが AI に移った結果、米国では若手開発者の雇用が約 2 割減ってる(Forbes)。「10 割化できる人間をどう育てるか」は、調べた限り世界中の誰もまだうまい答えを持ってない。ここは正直、僕も答えがない。
まとめ
仕事は消えるんじゃなくて、上に動く。
30 分かけて文言修正を実装する仕事は、たしかにもう無い。代わりに、何を AI に触らせないか決めて、コストの蛇口を握って、AI のレビュー判定を裁いて、基盤が壊れたら直して、自分の尖りを規約に焼き込んでいく。
AI はすごく優秀で、7〜8 割まで一瞬で来る。でも尖ってない。その先の 10 割、ときどき 12 割。そこがこれからのエンジニアの持ち場になるんだと思う。
4 日間それをやってみた感想としては——結構、面白い持ち場でした。