2026年の初め、AIが開発者の生産性に与える影響を調べていた研究者たちは、ひどく人間的な問題に直面しました。AIなしで作業する可能性のあるタスクを、引き受けたくないと考える開発者が現れたのです。
研究者はそれを「選択バイアス」と呼びました。けれど私には、小さな告白のように聞こえます。
少し前まで、AIはサイドパネルに置かれた実験的な機能でした。補完がうまくいかないときや、正規表現を考えるのが少し億劫になったときだけ開くものだったはずです。今では多くの開発者にとって、AIはただそこにいる存在になりました。朝エディタを開くときも、何年も触られていないリポジトリを引き継ぐときも、夜遅くテストが赤くなったときも、同じ部屋にいます。
パネルを閉じることはできます。エージェントを止めることもできます。コードの書き方を忘れたわけではありません。
それなのに、AIなしで働くことが、もう片手を失ったように感じられるのはなぜでしょう。
AIが引き受けたのは、仕事ではなく「間」だった
AIは「あなたの仕事を奪います」と宣言して開発現場に入ってきたわけではありません。小さな安堵を一つずつ運び込むようにやってきました。
最初は、書こうとしていた一行を補ってくれただけでした。次に、先延ばしにしていたテストを書き、知らない関数を説明し、スタックトレースを普通の言葉に直し、もう一度読む気になれなかったドキュメントの奥から設定項目を見つけてくれました。
それは依存には感じられませんでした。前に進んでいる感覚でした。
最後にAIアシスタントが使えなくなったときのことを思い出してみてください。不安だったのは、言語の文法を忘れたことではなかったはずです。最初の一手を出す前の静けさです。どこを探すか、自分で決めなければならない。わからなさを一人で抱えなければならない。仮説が生まれるまで、エラーを見つめ続けなければならない。
かつて、その時間は当たり前でした。今では摩擦のように感じます。
AIが最も深く変えたのは、答えの作り方だけではないのかもしれません。私たちが、問いと二人きりでいられる時間の長さまで変えてしまったのです。
救われているのも本当だ
AIへの依存を語るとき、開発者が規律を捨てて楽を選んだかのように扱うのは簡単です。でもそれでは、仕事の内側でこの道具がどんな存在なのかを見落とします。
ソフトウェア開発には、驚くほど多くの「誰にも言えない恥ずかしさ」があります。基本的なコマンドの書き方を忘れたシニアエンジニア。もう一度質問したら、周囲の不安を確信に変えてしまうのではないかと怯える新入社員。母語ではない言語で働き、問題はわかっているのに説明をすぐ言葉にできない開発者。重要な判断が誰かの記憶にしか残っていない、10年前のコードベースに加わった人。
AIは、その全員に辛抱強く付き合います。
同じことを聞いてもため息をつきません。「それくらい知っているべきだ」とも言いません。午前2時にも返事をし、真っ白な画面を、少なくとも反論できる何かに変えてくれます。答えが不完全でも、何かが返ってくるだけで「始めること」の重さは変わります。
これは小さなことではありません。生産性に見えるものが、実は安堵であることがあります。行き詰まる恐怖が減る。恥ずかしさが減る。何も説明してくれない機械の前で、一人きりだと感じる時間が減る。
AIによって、好きな仕事に使う力を取り戻した開発者もいます。定型コード、繰り返しのテスト、移行のひな型、何度目かわからないAPIクライアントを任せれば、頭が疲れ切る前に面白い問題へたどり着けます。
それを単なる近道として片づけるべきではありません。人に「試してみよう」と思う勇気を返す道具には、本当の価値があります。
ただし、安心と依存は同じ根から育ちます。
信じ切れないものを、使い続ける
開発者向けの調査では、いつも同じ不思議な関係が浮かびます。私たちはAIを日常的に使いながら、その答えを完全には信用していません。
自信に満ちた回答が、たった一つの境界条件で崩れるのを見た人なら、この感覚がわかるでしょう。コードは正しそうで、名前も整い、説明も落ち着いている。三つ目のテストが落ちて初めて、存在しないメソッドを作っていたこと、業務ルールを読み違えていたこと、本当の問題より簡単な問題を解いていたことに気づきます。
それでも次に詰まったとき、私たちはまた尋ねます。
これは矛盾ではありません。信頼にはいくつもの層があります。
最後の判断は任せられなくても、最初の方向は示してもらえる。パッチは信じられなくても、会話によって考えの結び目がほどけることは信じられる。答えそのものを疑っていても、空白の代わりに何かが現れることは期待できる。
AIは、mainブランチへ直接マージする権限だけは絶対に渡せない同僚です。それなのに、部屋からいなくなった瞬間、妙に寂しくなります。
次の足場がすぐ現れるから、私たちは速く進める。その足場が体重を支えられるかを確かめる責任は、今も私たちにある。
つまずかなくなったとき、失われるもの
行き詰まったときにしか身につかない知識があります。
AIがなかった頃、見慣れないエラーは、スタックトレースから呼び出し元へ、そこからドキュメントへ、そして最後には自分でも気づいていなかった前提へと私たちを連れていきました。効率の悪い道でした。でもその道を歩くうちに、コードベースはファイルの集まりではなく「場所」になりました。
私たちは、一度抵抗してきたシステムをよく覚えています。
午後を丸ごと奪ったバグは、状態が本当はどこにあるのかを教えます。本番障害は、退屈に見えた安全策がなぜ必要だったのかを教えます。三度読み違えたライブラリは、やがて誰かに説明できるライブラリになります。
AIが抵抗を取り除くとき、学びを記憶に残す物語まで取り除いてしまうことがあります。
未知のライブラリを学ぶ開発者を対象にした初期の研究は、感覚的にも納得できる違いを示しました。作業を丸ごと委ねた人より、概念を質問し、自分の理解を確かめるためにAIを使った人のほうが多くを学んでいたのです。大切なのは「AIを使うかどうか」ではなく、AIが思考を置き換えたのか、それとも思考に参加したのかでした。
これは若手開発者にとって特に難しい問題です。経験者が怪しい抽象化に気づけるのは、以前に自分で間違った抽象化を作ったことがあるからです。整ったパッチがシステムに馴染まないと感じられるのは、そのシステムの傷を知っているからです。では、触れる前にすべての角が丸められてしまったら、次の世代はその勘をどこで手に入れるのでしょう。
メンタリングは、答えを渡すことだけではありませんでした。何を怖がるべきか、いつ止まるべきか、どの妥協が後で高くつくのか、なぜ「動く」だけではまだ完成ではないのか。そうした感覚を、時間をかけて手渡すことでした。
AIはそれらを説明できます。しかし、誰かが「あなたが学ぶ間、ここにいる」と選んでくれたときの感覚までは、まだ再現できません。
近道は本物かもしれない。それでも理解は、その距離を自分で渡らなければならない。
コードには、かつて書き手の指紋があった
もう一つの変化は、人と人のあいだで起きるため、さらに測りにくいものです。
人が書いたコードには、しばしば書き手の痕跡があります。変わったヘルパー関数には、それを必要とした障害の記憶があるかもしれません。不器用なコメントからは、どこで迷ったのかが伝わります。レビューで見ているのは変更そのものだけではありません。そこに至った思考をたどり直し、質問をすると、歩いた道を知る本人が答えてくれます。
AIが生成したコードには、その道がないことがあります。
見た目は整い、技術的にももっともらしい。それでも、どこか持ち主がいないように感じられます。作者は何を頼んだかは説明できても、なぜ結果がこの形になったのかまでは説明できない。するとレビューする側が、本来は書き手も担っていた仕事を引き受けます。意図を組み立て直し、前提を確かめ、誰も覚えていない判断の端を探すのです。
AI生成のプルリクエストをめぐる多くのコミュニティでの議論の底には、この違和感があります。不満は単に「コードが悪い」ということではありません。悪いコードなら昔からありました。もっと深い不安は、人と人との約束が変わってしまったことにあります。
一人は数分で大きな変更を作れる。けれど別の誰かは、それを理解するために今までどおり人間の注意を使わなければならない。キーボードで節約された時間は、コードレビューや保守、セキュリティ対応、あるいはシステムが止まった夜に、静かに戻ってきます。そのとき誰かが、生成されたパッチが何をしようとしていたのかを説明しなければなりません。
コードはずっとコミュニケーションでした。生成がほとんど無料になるほど、注意が希少になります。そして注意は、人間のものです。
技術は消えるのではなく、場所を変えるのかもしれない
この変化を、喪失だと感じない開発者もいます。むしろ、ずっと望んでいた高さで仕事ができるようになったと感じています。
書く行数は減り、問題の形を整える時間が増える。ひとつに決める前に複数の設計を比べる。ユーザー、アーキテクチャ、失敗の仕方、エージェントが越えてはいけない境界を考える。技術の中心が、一つひとつを自分で作ることから、全体を導くことへ移っていきます。
それは本当の進化になり得ます。アセンブリが機械語を置き換えたときも、フレームワークが手作業の基盤を置き換えたときも、私たちは開発者であることをやめませんでした。ソフトウェアは、抽象化によって上の層へ進み続けてきました。
ただし、どんな抽象化も、その下を理解する誰かに支えられています。
AIを指揮する開発者にも、良し悪しを見分ける感覚が必要です。レビューする人には、今も頭の中のモデルが必要です。アーキテクトは、美しい図が遅いネットワークや壊れたメッセージ、疲れ切ったチーム、不安を抱えたユーザーに出会ったとき、何が起きるかを知らなければなりません。
AIが実装の多くを書くようになっても、人間の判断が重要でなくなるわけではありません。ただ、見落としやすく、育てにくくなります。
希望のある未来とは、開発者の価値が下がる未来ではありません。文脈、思いやり、疑い、責任、そして技術的には正しい答えが「このシステム、この人たち」にとっては間違いだと気づく力。人にしか背負えないものを、これまで以上に意識して守る未来です。
自分を置き去りにせず、AIとともにいる
私たちは、まだAIから離れられるのでしょうか。
個人としてなら、離れられます。明日パネルを閉じればいい。ただ、仕事としての答えはすでに複雑です。期待される速度は変わり、コードベースには生成された成果物が増えています。新しい開発者はキャリアの途中ではなく、最初の日からAIに出会います。自分ではアシスタントを使わない人も、AIが作ったコードをレビューし、保守することになります。
AI以前のソフトウェア業界へ、一人だけで戻る道はありません。
でも、離れることだけが自由の尺度ではないのかもしれません。もっと大切なのは、AIがそばに残っても、私たち自身が仕事の中に残れるかどうかです。
そこに残るとは、すべてのテストが通っていてもパッチを読むことです。動いたあとに「なぜ」を尋ねることです。説明できない変更をマージしないことです。若手が苦労する時間を無駄と呼ばず、もっともらしい間違いからシステムを守るレビューの見えない仕事を正当に評価することです。
そして、アシスタントがすぐには答えない時間を残すことでもあります。純粋さを証明するためではありません。自分の思考の声を、もう一度聞くためです。
私たちの多くは、これからもAIを使い続けるでしょう。救われているのも本当です。可能性があるのも本当です。同時に、違和感も依存も、好きだった仕事の何かが静かにこぼれ落ちていくような不安も、本物です。
否定するか、明け渡すか。その二つから選ぶ必要はありません。
ソフトウェアの未来を決めるのは、AIが何パーセントのコードを書くかではありません。受け入れる前に理解するか。答えを転送するだけでなく、誰かに教えるか。他人の注意を守るか。そして生成されたコードが現実の世界に届いたとき、なお責任を引き受けるか。未来は、そんな小さな瞬間の積み重ねで決まります。
AIは、ここにいていい。
私たち自身も、ここに残らなければなりません。
