AIは、開発者としての私の考え方と働き方をどう変えたか
ドキュメントを一ページずつ自分で読み、コードを一行ずつ打ち込み、関数をひとつずつ書いていた頃の感覚を、私は今でもはっきり覚えています。書いたコードが動き、プロダクトが少しずつ形になっていくときは、言葉にしづらい高揚感がありました。数年前には、必要な関数の説明をコメントで一行書いただけで、AIが自分の書こうとしていたコードをほぼそのまま提案してくれるようになりました。そして今では、「プロンプト」をひとつ渡すだけで、AIが自走してシステムまるごとを組み上げてしまいます。まだ完璧ではないにせよ、その体験は面白くもあり、同時に少し落ち着かないものでもありました。面白いのは、頭に浮かんだアイデアを簡単に形にできるようになったからです。好きなものは何でも作れます。でも—だとしたら、開発者としての私は何を担う存在になるのでしょうか。
バックエンドはPHP/Laravel、フロントエンドはVue.jsを中心に仕事をしてきた私は、ロジックを一行ずつ自分で書き、自分でデバッグし、自分で調べるというやり方に慣れていました。ところが、AIが進化し、いつの間にか日々の開発フローの一部になっていくにつれて、それが変えたのは働き方だけではないと気づきました。「開発者の仕事とは何なのか」という、私自身の捉え方まで変わっていたのです。
「コードを打つ人」から「解決策を描く人」へ
以前の私は、タスクを受け取ってから「ボイラープレートを書く」段階にかなりの時間を取られていました。LaravelならMigration、Model、Controller、Requestのバリデーション、Vueならコンポーネントの雛形づくりやprops/emitの定義です。どれも難しくはないけれど、同じことの繰り返しで、地味に時間を食う作業でした。
今は、業務の中身と欲しいデータ構造をきちんと説明すれば、リレーションまで揃ったEloquentモデルから、再利用可能なロジックをまとめたVueのComposableまで、AIがその骨組みを一気に用意してくれます。面白いのは、自分の仕事が「一行ずつ書くこと」から「問題を正しく言語化し、返ってきた解決策をレビューすること」へ移っていったことです。プロンプトが曖昧なら、返ってくる答えも同じくらい曖昧になります。だからこそ、コードを書き始める前に、以前よりずっと深く課題を理解しておく必要があります。
もうひとつ、考え方として大きく変わった点があります。「速くコードを打てること」を能力の物差しにしなくなったことです。今の難しさは、生成されたものを読み解き、評価し、リファクタリングして、Laravelの作法やプロジェクトのパターンに沿わせ、既存のアーキテクチャを壊さないようにするところにあります。
実際、大きな規模で成果を出した例もすでに出てきています。たとえばBunのケースです。
JavaScriptランタイムBunの作者であるJarred Sumner氏は、Claude Codeを使ってBunのコードベース約53万5千行を、ZigからRustへわずか11日間で書き換えました。手作業なら、エンジニア3人がフルタイムで1年かかると見積もられていた規模です。注目すべきは「AIが代わりにコードを書いた」ことではなく、書き手・レビュアー・バグ修正役といった役割を複数のAIに割り当て、並列に走らせながら反復し続ける仕組みそのものを設計した点です。詳しくはこちらの記事をご覧ください: Rewriting Bun in Rust。
規模はまったく違いますが、私も同じことのミニチュア版をやっているように感じます。自分で打ち込む代わりに要件をはっきり伝え、AIに解決策を出してもらい、マージ前は自分が「レビュアー」に回る、というやり方です。
「検索して大量のドキュメントを読む」から「聞いて、裏を取る」へ
以前は、見慣れないエラーに出くわしたり、新しいパッケージを調べたりするたびに、Stack Overflow、GitHubのIssue、公式ドキュメント、誰かの個人ブログ……とタブを5つも6つも開いて、自分で情報をまとめていました。無味乾燥な技術文書が延々と並ぶページを何十も行き来しながら必要な情報を掘り当てる作業で、気づけばかなりの時間が消えている、ということもしばしばでした。
今はまず、AIに聞いて全体像をざっと掴むところから始めることが多くなりました。たとえばLaravel QueueとLaravel Horizonの違いや、あるVueライブラリが内部でリアクティビティをどう処理しているか、といった具合です。ありがたいのは、調べる範囲を絞り込むスピードが一気に上がったことです。ただし、これだけは必ず守っています。100%は信じない。 AIの回答はあくまで出発点として使い、そこから公式ドキュメントに当たったり、実際に動かして確かめたりして、要点を押さえた深掘りをします。言い換えれば、AIは私を「情報を探す人」から「情報を見極める人」に変えました。小さな違いのようでいて、実際にはずっと重要なスキルだと思います。
これは私個人の感覚にとどまらず、業界全体の流れでもあります。開発者ならStack Overflowという名前を知らない人はいないでしょう。そして、この行動の変化を最もはっきり物語っているのが、そのStack Overflowの現状です。いくつかの統計によれば、Stack Overflowに投稿される新規質問数は2022年11月のChatGPT登場以降に大きく落ち込み、2025年半ばには、サイトが立ち上がった2009年当時と同じ水準まで下がっています。
出典: Stack overflow is almost dead
最大の変化は、開発者としての思考そのもの
ひとつだけ挙げるなら、自分の役割が「実行する人」から「意思決定し、品質を担保する人」へ移ったことだと思います。
- コードを動かすことだけに集中するのではなく、業務仕様やアーキテクチャ、エッジケース、保守性について考える時間が増えました。
- よい問いを立てる練習をするようになりました。AIの答えの質は、こちらの問いの質にかなり左右されるからです。
- レビューにはより慎重になりました。AIが生成したコードが、いつも正しいとは限らないと分かっているからです。
いつも自分に言い聞かせている「限界」
AIは魔法のように現れましたが、完璧ではありません。だからこそ、自分の批判的思考までAIに明け渡してしまわないよう気をつけています。
- やみくもにコピペしない。とくに決済、権限管理、機微なデータといった重要な業務ロジックでは。
- 仕組みを理解する手間を省かない。AIを「コード生成マシン」として使うだけで、なぜそう書かれているのかを分からないままにしていると、長い目で見て土台となる力が痩せていきます。
- 実戦の経験は今も必要。AIはよくあるパターンには強いものの、プロジェクト固有の業務特性となると、人間の経験と読み解く力に代わるものはありません。
AIが「全部やってくれる」からといって、怠けていいわけではない
この一年あまり、自分に一番よく言い聞かせてきたのがこれです。AIを使うときに一番はまりやすい罠は「使い方を間違えること」ではなく、正しく使い続けているうちに、そもそもなぜ自分が理解しておく必要があったのかを忘れてしまうことです。Controllerも、テスト一式も、込み入ったリファクタリングも数分で片づくようになると、「すべて順調だ」という感覚が、一番大事な一歩—本当に理解できているかを自分に問い直すこと—を飛ばさせてしまいます。
その「怠け」に落ちないために、私が守るようにしているいくつかの原則です。
- AIのこと、業務のこと、そして基礎知識を学ぶ時間を確保する: コードを打たずに済んだぶんの時間は、意識して一部を「読む時間」に回しています。使っているAIツールの新機能のこともあれば、お客様の業務をより深く読み込むこともあります。
- 手を動かすデバッグ力を錆びつかせない: とくに見慣れないエラーでは、AIに聞くのと並行して、自分でもスタックトレースを読み、ブレークポイントを置き、筋道を立てて考えるようにしています。
- 出力だけでなく、コードを読む: 同僚のコードや、使っているパッケージのソースコードを読む時間を意識して取っています。AIが説明できないからではありません。直接読むことでしか保てない、実際のコードベースに対する肌感覚があるからです。要約された回答では、それは代わりになりません。
これからについて—「絶滅」しないために
AIの技術は日々変わり、モデルもどんどん賢くなっています。取り残されないために、毎日少しずつ自分をアップデートしていきましょう。もし時間に余裕があるなら、私がやっていることも参考にしてみてください。
- 流れは追う。ただし、新しいツールすべてを追いかけはしない。出たばかりのAIツールを片端から試す必要はありませんが、大きな流れは理解しておきたいので、読むことは続けています。たとえば、ツールが「オートコンプリート」から、複数のステップを自走して自分の出力を検証する「エージェント」へ移ってきていることなどです。FacebookのAI関連グループに参加するのも、私が日々情報に触れる手段のひとつです。
- 「プロンプトを書く技術」より「AIを束ねる技術」に投資する。先ほどのBunの事例がよく示しています。大きな価値は、ひとつのAIがうまくコードを書くことではなく、複数のAIが連携して互いをチェックするプロセスを設計できることから生まれます。ずっと小さな規模でも、問題を分解し、どこまでAIに任せ、どこで自分が介入すべきかを見極める力は、うまいプロンプトを書く力よりも、ますます重要になっていくはずです。
- AIが最も代わりにくいものに投資する。ドメイン知識とシステムアーキテクチャです。AIはよくあるパターンには強いのですが、その事業ならではの深い理解や、何年も前に下されたアーキテクチャ上の判断の背景となると、時間をかけて人が積み上げるほかありません。今の時代、開発者にとって最も長持ちする資産だと思います。
- 批判的思考を保ち、自分で正しさを判断する力を手放さない。取り残されるというのは「新しいツールを知らない」ことだけではありません。裏も取らずにAIを信じ込み、間違っているときに自分で気づけなくなることもまた、取り残されるということです。
- チームで共有し、一緒に学ぶ。誰がどうAIを使っているか、どのプロンプトが効いたか、どのツールがどのタスクに合うか—チームで話すようになってから、一人ひとりが手探りするよりずっと速くチーム全体が学べるようになったと感じています。
この時代に「絶対に取り残されない」確かな公式があるとは思いません。ただ、取り残されるのは最新ツールの習得が遅い人ではなく、自分の仕事のやり方を問い直すことをやめた人だ、とは思っています。
私にできたのだから、あなたにもできる
振り返ってみると、AIは私を「まったく別の開発者」に変えたわけではなく、自分自身をアップデートする手助けをしてくれました。コードは速く書けるようになり、テストはより手厚くなり、学ぶスピードも上がりました。その代わりに、より深く考え、より良い問いを立て、AIの提案に対してより大きな責任を持つ必要も出てきました。
たぶん、それがこの時代の一番面白いところです。AIは開発者の仕事を奪っているのではなく、「良い開発者とは何か」を定義し直しています。私はきっとAIを使いこなせるようになると信じています。あなたもきっと、そうなれます！
出典: