AI時代のソフトウェアエンジニアリングに関する考察

AI時代のソフトウェアエンジニアリング 2026年6月28日 ご存知ない方のために申し上げると、小説を書かないときは、ソフトウェアエンジニアとしてコードを書く日々を送っています。最近のソフトウェア業界は、人工知能に大きく依存しています。AIは、何兆行もの公開されているソースコードを学習し、コードがテスト可能な正しい解決策と間違った解決策で問題を解決し、コードがコンピューターに理解されるように特別に構造化されているため、コードを書くのが非常に上手になりました。 プログラマーがAIを使う前は、一般的なワークフローは次のようでした。 誰かに既存のプログラムに機能を追加するよう依頼されます。その機能が何をするべきか（そしてすべきではないか）、ユーザーがどのようにアクセスできるか、そして正しく動作していることをどのようにテストするかを記述した正式な定義を作成します。この機能を実装するのに最適なデータ構造、アルゴリズム、コードライブラリ、外部サービスを調査するのに時間を費やします。新しい機能を作成するためのコード、それが期待どおりに動作することを確認するためのテスト、ユーザーに使い方を伝え、他のエンジニアにそれを保守およびデバッグするために知っておくべきことを伝えるドキュメントを作成します。そして、「プルリクエスト」を作成し、組織内の他のエンジニアに新しいコードのレビューとコメントを求め、最終的に製品での使用を承認するよう求めます。 AIがかなり良いコードを一貫して生成できるようになった現在、ソフトウェア開発者のワークフローは次のようになります。 AIに新しい機能を作成するよう促すプロンプトを作成します。AIが書いたものをレビューし、必要に応じて変更を加えるか、AIエージェントにそれらの変更を依頼します。新しいコードを既存のコードベースに自分でマージするか、他の誰かにレビューしてマージしてもらうためにプルリクエストを作成します。 古いワークフローでは、創造的なプロセスは主にあなたの心の中で起こっていました。新しいプロセスでは、AIの内部機構の中で展開される創造的なプロセスを監督します。AIに仕事を始めるように促すために、簡潔で、思慮深く、正確なプロンプトを作成するのに多少の努力をしましたが、自分でコードを書くときにするような難しい思考はしていません。AIからコードが返ってきたとき、あなたは本質的に編集者として行動しています。なぜなら、AIはコードを書くことはできますが、あなたがプロジェクト全体を把握しているようには必ずしも把握しておらず、この新しいコードが問題を引き起こさないことを確認する必要があるからです。 AIは、追加したばかりのコードが製品に適用される法的要件に違反するかどうかを知りません。外部システムへのリクエストが10ミリ秒かかるか10分かかるかを知りません。そのコードの動作が、3週間後にチームメイトが追加するであろう新しい機能と衝突するかどうかを知りません。先月書いた機密情報を扱う別の関数と連携する際に、書いたばかりの関数が新しいセキュリティ上の問題を引き起こす可能性があるかどうかを知りません。シニア開発者はこれらのことを知っています。だからこそ、AIのコードが「ただ動作するように見える」ものであっても、それを精査し、しばしば修正する必要があるのです。シニア開発者にとって、AIは有能で、仕事が速いジュニアまたは中堅開発者であり、適切に指示すれば、ほとんどの場合堅実な仕事を生み出しますが、あなたが過去20年間で培ってきた組織的知識と深く広範なシステムレベルの知識を欠いています。 さて、少し立ち止まってアナロジーを考えてみましょう。あなたは歴史小説の作家だとします。あなたのワークフローはどのようなものになるでしょうか？おそらく次のようになるでしょう。 1760年のロンドン、セントポール大聖堂の外で2人の政治家が議論しているシーンを思い描きます。このシーンを正確に書くために何を知る必要があるかを考えます。これには、服装、通りの雰囲気、政治状況などが含まれます。何冊かの本を開き、次のようなことについてメモを取り始めます。 彼らの社会経済的地位と社会における役割に基づいて、あなたの登場人物はどのような服装をしているでしょうか？彼らと一緒に通りにいるのは誰でしょうか？物売り？馬車に乗ったタクシー運転手？それらはどのような見た目でしたか？その時間帯に煙突掃除人は出ていましたか？売春婦や法執行官はどうでしたか？あなたの登場人物が議論する主要な政治家は誰で、その時点での彼らの立場は何ですか？最近の数週間または数ヶ月の歴史的出来事で関連するものは何で、それらは登場人物の議論にどのように影響するでしょうか？ 執筆に戻り、歴史的事実を想像力から紡ぎ出したシーンに織り交ぜます。小説家とソフトウェア開発者には多くの共通点があります。実際には、小説家は執筆を始める前に多くの歴史的調査を行っているでしょう。ちょうどソフトウェア開発者が、長年の先行作業から、新しい機能に適したデータ構造やアルゴリズム、どの種類のキャッシュやデータベースが適切かを知っているのと同じです。 両方の労働者に共通しているのは、作成している素材への深い没入感です。彼らは仕事に完全に没頭し、時間の感覚を失うことがよくあります。小説執筆とソフトウェア開発の両方において、私や多くの同僚が時計を確認し、問題に没頭し、10分後に時計を見ると4時間が過ぎていた、というのはよくあることです。これは、心理学者ミハイ・チクセントミハイが1990年のベストセラー『フロー体験 喜びの現象学』で述べた「最適な経験」の状態です。作家、ソフトウェア開発者、画家、ミュージシャン、その他すべての創造的な人々は、時間と状況が許せばこの状態に入ります。多くのソフトウェアエンジニアは、定時外に自宅で働くのは、通常の営業時間外に会議やその他の中断がないため、この状態に入ることができるからです。 さて、歴史小説家をソフトウェア開発者の立場に置いてみましょう。彼女は出版社から電話を受け、2年に1冊だったのが、毎年4冊を市場に出す方法を見つけたと告げられます。彼らは、非常に安価で1日5ページもの有能な文章を量産できる優秀な高校生や大学生を多数採用しました。出版社は、歴史小説が元の作家の卓越したレベルを維持するか、少なくともそれに近いレベルであることを望んでいるため、彼女を編集者として雇い続けることにしました。小説家の仕事は、学生たちの作品を編集することになりました。学生たちは皆、少し手を加えれば首尾一貫した章にまとめられるようなページを書くように注意深く指示されています。高校生や大学生の作品を採点したことがある人なら誰でも、これが一般的に報われる仕事ではないことを知っています。週に100本の論文を採点しなければならなかったことがあるなら、それがどれほど骨の折れる仕事であるかを知っているでしょう。小説家も、ソフトウェアエンジニアも、もはや自分の仕事に深く没頭していません。編集は創造ではありません。想像力に身を委ねることはありません。発明のプロセスに心と感情を没頭させることもありません。その代わりに、問題を根絶し、ぎこちない言い回しや冗長な説明を修正しようとします。フロー状態は失われます。あなたは、あなたの創造性やそれを発揮する必要性を本当に評価しない、より大きなプロセスの一部に過ぎなくなります。さらに悪いことに—そして私はAI生成コードを数ヶ月間レビューした後に個人的にこれを経験しました—あなたのスキルは急激に低下します。新しい問題が発生したとき—実装すべき機能や、修正すべき厄介なバグ—それに数時間を無駄にするという考えは侮辱的に感じられます。Claudeが5分でバグを見つけて修正案を書き始めることができるのに、なぜ私がそのすべてのコードを掘り下げなければならないのでしょうか？本当にその通りです。私たちのかつて好きだったこと、今では雑用に感じることに、なぜ私たちや私が精神的なエネルギーを投資しなければならないのでしょうか、ボットがそれをやってくれるのに？AIと数ヶ月間一緒に働いた結果、少なくともコーディングに関しては、私は著しく怠惰になり、愚かになりました。（私は執筆するときにAIを使いません。なぜなら、執筆自体が自分の思考を整理し明確にする行為だからです。ボットに書かせると、誰かに自分のために運動してもらうようなものです。