AI時代はプログラミングスキルがさらに重要になる
こんにちは、@dyoshikawaです。
先日、日課のはてなブックマーク巡回で次の記事を見かけました。
AI時代にはプログラミングスキルが完全に不要になるという主張です。個人的にはCursorとDevinで毎日AIプログラミングしながら割と逆方向のことを考え始めていたので、書いてみます。
AI時代の人間の役割は「エッジケースの探索と解決」
結論からいうと、AI時代の人間の役割はエッジケースの探索と解決なのではないかと考えています。
CursorやCline、Devinでプログラミングしていて思うこととして、インターネット上に正解のサンプルが膨大に存在するようなコードを書くのは非常に得意です。典型的なCRUD APIや、コーポレートサイトのマークアップなどが挙げられます。
また、最近は競技プログラミングも得意なようです。これも問題と解答のサンプルが大量に積み重なった結果といえると思います。
一方で、インターネット空間に情報が全くなかったり、そこまでいかなくてもサンプルコードがやや少なめな処理については途端に出力の精度が落ちる印象があります。
実際に遭遇した試金石的なケースとして、Cursorでコーディングしていたところ、Vitestの vi.mock() についてのAI側の知識が怪しいというのがありました。 vi.mock() でモックした関数の振る舞いをテストケースごとに変更したいというオーダーに対して、AIは vi.mock() がファイルの先頭に巻き上げられるという性質を知らず、 vi.hoisted() を使って変数定義をする提案ができませんでした。
できることは知っているができないことをできないとは知らないきらいもあります。例えば、Ruby on RailsでAPIを書いている時にUNIONを使ったSQLを書いて欲しいと指示したのですが、Active Recordに存在しない .union() メソッドを提案されたこともありました[1]。これは学習データに「〇〇ができる」という記事は多くても「〇〇ができない」という記事は少ないということだと思います。
また、「人間がコーディングをせずAIへの指示だけ」で静的解析とテストコードをPASSし、実行時エラーも解消しつつ、意図通りの仕様への道筋の維持も成り立たせる……を実現するのが非常に難しいと感じています。「あちらを立てればこちらが立たず」で実行時エラーをなくすために仕様を歪めたり、仕様を維持するためにテストコードをPASSはするが無意味な内容にしたりといったことがあります。
「だいたい正しいが細かいところはちょくちょくと誤りがあり、その場合の自己修復が困難」が今のAI（LLM）に対する評価だと思います。そもそも学習データである人間の成果物にも誤りが多く含まれています。そのため細かいミスや知識の抜け漏れ（=ハルシネーション）がゼロになることはないでしょう。
その抜け漏れも埋めていけばいつかなくなるのでは？という向きもありそうです。仕事内容がずっと変わらなければそれはYESなのですが、テック産業では取り組む対象や扱うツール自体がかなりの頻度で塗り替えられます。最近ではドッグイヤー🐕を超えてラットイヤー🐁と呼ばれたりもするようです。ようやく安定したと思ったら次のパラダイムがやってくる世界なので、なかなか根本的な解決は難しい気がしています。
これらの経験から、AIはたくさんの人に散々書かれてきた典型的なコードは書けるが、実際に手を動かさないと遭遇しないエッジケース的な課題を解くのは苦手であると考えています。
先日書いた記事でpit of deathという概念を紹介しました。
Steve Sewell氏の動画より。AIはコーディング中に自己復帰困難な穴（pit of death）に落ちることが多々あり、その都度人間が復帰させる必要がある
人間の仕事はAIをpit of deathに落ちないように誘導すること、また落ちた時に助けることになりつつあります。そしてpit of deathとは大抵AIの知識から抜け落ちているエッジケース的な課題です。
そして私自身、人間のプログラマーとして、よくある処理のコーディングはすぐに終わってしまい、上記のようなエッジケース的課題に取り組んでいる時間の割合がどんどん増えていることを実感しています。
AIが残した2割の仕事に8割の労力を要する
「AIコーディングエージェントが全体の80%のコードを書いてくれるようになった」という話をよく見聞きします。
実際、私もそう感じます。細かく指示を区切りながらではありますが7〜8割くらいのコードは生成できているかも？という印象です。しかしだからといって今まで開発に費やしていた時間の80%が削減されたでしょうか。私は自分が出す成果が5倍になったとはさすがに感じません。じゃあどれくらいなのかと聞かれたら……うーんどうでしょう、1.5倍くらいかなと思っています。
生成AI活用の発信で著名な国内企業としてLayerX社がありますが、そのCTOの松本さんは以下のように述べています。私の感覚値と比較的近いかなと思います。
私の場合、Clineで簡単なデモやPoCを実装しながら、Circlebackで議事録を取り、n8nやnotionとLLMを組み合わせたニュース収集Botが常に様々な情報を集めてくれています。（中略）気づけば私個人の生産性はこの2年で数十％、下手すると倍以上は変わったのかもしれません。
言葉の使い方が正しいかわかりませんが、これはラスト2割の作業に8割の労力がかかるという一種のパレートの法則的なものだと思っています。進捗報告で「大体終わりました、あとちょっとです」と言ってからがめちゃくちゃ長かったという経験がある方は多いのではないでしょうか（私はたくさんあります😇）。
AIにより、ググったら一番上に出てくるような自明な処理の検討や退屈なESLint警告の解消、タイピングをする時間などは奪われましたが、AIコーディング以前から最も大きなウェートを費やしてきた不可解なエラーや挙動と格闘する時間は（嬉しいことに😂）健在です。
上記は2023年のポストであり、さすがに2025年のAIコーディングエージェントとは性能の差分があると思いますが、「80%のコードを生成すること=80%の仕事をすること」という誤認に対する指摘としては今も言えることなのかなと。
下流工程に身を置くことの価値
ソフトウェアエンジニアリングにおいては「AI時代に残る仕事は要件定義や設計である」という見解が有力視されているように思います。
しかし、私は要件定義や設計こそAIに取られる領域かもしれないと思っています。
それは、これらの工程が「できている」「できていない」をはっきりと定量的に評価することが難しい部分があるためです[2]。
実際にAIに要件定義・設計をさせてみるとわかりますが、過去のナレッジの集積と要求のインプットからやるべきことのアウトラインを出力するということはAIの得意フィールドでありかなりそれらしい回答が返ってきますし、仮に今のハイエンドな生成AIモデルに一流とされるテック企業のシステムデザイン面接を受けさせたら通過するくらいの受け答えはできるんじゃないかなと感じます。
今年の初めに大バズりしたAIと翻訳業についての記事では次のように述べられています。
現状の生成AI翻訳はどうみても完璧というには程遠く、依然として人間の翻訳を終わらせるだけの力をもたない。
それではなぜ、人間の翻訳は終わってゆくのだろうか。
それでもなぜ、人間の翻訳は終わってゆくのだろうか。ほかでもなく、人間の側が翻訳に対する要求水準を下げ始めたからである。
個人的には身につまされるものがありました。
AIに代替されるのは（プログラミングを筆頭とする）定量的な仕事であって、創造性やコミュニケーションなど比較的定性的な「人間的な仕事」が残っていく、というようなイメージを持ってしまいがちですが、AIが創造的な業務を担い、人間はAIが雑に仕事をした箇所の修正に追われるという全く逆の未来もあるのかもしれないと思っています。
こんな記事もあり、コミュニケーションとは何かを考えさせられますね🤔
もちろん現場のコンテクストに精通した人であったりその筋の専門家から見たらここがダメだという部分は出てくると思うのですが、雇用者や顧客が「これはもうAIで良い」と考え始める可能性はあるのかなと思いますし、実際にそれで仕事が回せてしまうかもしれません。よくいわれるAIによるホワイトカラー代替論は、AIが実際に人間の能力を超えているかではなく、成果物の受領側の考えがどう変容していくかに本質がある気がします。
この点、AI時代に1次産業職や溶接工職[3]のような労働が生き残りそうといわれるのは得心がいきます。これらの仕事は定量的に評価しやすく、「できている」「できていない」が比較的明確です。AIによって「末端とされていた知識や作業の重要性」が再発見されるという現場労働のリバイバルが起きていると捉えることもできます。そしてソフトウェア業界でいうと、プログラマーがこのラインに該当すると思っています[4]。機能要件と非機能要件を過不足なく満たすためには、AIの出力を高い解像度で評価でき、自分の手で成果物を調整できるということが本当に重要です。
医者や弁護士のような、顧客と対話して内容を整理し解決策を導く筆頭のような知識労働が将来代替されるという声が聞かれる[5]一方で、ソフトウェアエンジニアリング領域では現場労働であるプログラミングより要件定義や設計が聖域のように扱われるのは私にとっては少し不思議に思うところがあります🤔 みなさんはどうでしょうか？
すでに業務に生成AIを取り入れ、AIとの壁打ちを通じて要件定義や設計をエンハンスしているプログラマーの方は結構いらっしゃる気がします。一気通貫ですべての工程を手がけることで、自ら手を動かすことで得たエッジケースナレッジを要件や設計に素早くフィードバックすることができ、ソフトウェアの抽象と具象の相互改善が容易です。
プログラマーこそ安泰なのだという既得権益めいた主張をするつもりはありません。XやこのZennなどを見ているとビジネスサイドであったりプロダクトマネージャーをやっていたような方がAIツールを片手にプログラミングを勉強し実装の世界に降りてきている雰囲気もあります。どちらかといえば上流工程と下流工程の境界が溶けてきていると捉えるのが正確なのかもしれません。
業務における人間とAIの関係は、指示する側とされる側で分かれるのではなく、要件定義、設計、実装、動作確認、デバッグと修正に至るまで協働する関係となり、必要に応じて足りない部分を補完し合うようなところに落ち着くのではないか？と予想しています（今もそうですしね）。
いずれにせよ、「プログラミングは今後AIが全部やってくれるので、AIに指示することが人間の仕事になる」とは限らないんじゃないかというのが言いたいことです。私の考えでは、そこまで細部まで臨機応変、正確に対応できるAIはおそらくコーディングエージェントへの指示もできます。
そして、AIがその境地まで到達した時こそがシンギュラリティに近い状態であり、身体や手先を器用に使うような労働についても持ち前の開発能力を駆使したロボット化により全力で自動化を推し進めようとするはずなので、もう人間が生産活動を行わなくてもいけるようになるユートピアが見えてくるんじゃないかと思っています。
ユートピアは意外と遠い？
では、AIがソフトウェアを完全に自律的に組み上げてくれるユートピアは近いのでしょうか。
「AIの能力はまだまだというが、この技術は今後指数関数的に進化する」 というような予測がよくいわれます。
これは技術のSカーブにおいて、導入期・成長期・成熟期のうち、今が成長期の手前であれば成立します。
技術のSカーブ（ChatGPT作）
しかし、今が成熟期の手前である可能性もあります。
元GoogleエンジニアのNeetCode氏は「This video will change your mind about the AI hype」という動画で次のように述べています。
（内容の一部の要約です）
今後、AIの改善率がどうなるかを予測することは不可能ですが、すでに得られた実績値もあります。
ChatGPTがリリースされてからほぼ2年が経ちましたが、率直に言って、GPT-3.5からGPT-4oまでの改善はGPT-3.5までと比べて明らかに遅いです。
何かをすることに長けている人なら、上達するにつれて、改善するのがどんどん難しくなることを知っています。これは多くのことに似ています。
私が非常に興味深いと思う例は分散システムです。99%の可用性を持つシステムがあり、そのシステムを99.9%の可用性に押し上げたい場合、それは（約）1%の改善にしか思えませんが、これはよくある誤解です。これは実際には10倍の改善です。1%の故障率を0.1%に下げる、つまり故障率を1/10にする必要があります。
９９%の可用性を99.9%にすることは数値上は約1%の改善だが、実際には故障の数を1/10にする労力を払う必要がある
「ソフトウェア開発はいつか100%自動化される」という未来を否定するつもりはありません。歴史的に人間は想像し得ることをすべて実現してきたので、そういう未来はいつか必ず来るでしょう。
ただ、それが数年後なのか、数十年後なのか、もっと先なのかはわかりません。例えば、自動運転技術で「人間の運転手はいなくなる」と言われてからかなりの年数が経ちました。
先の動画より。「2015: 自動運転車が2年以内に実現」「2016: 放射線科医は5年以内に時代遅れに」「2024: 放射線科医が普通の車で通勤中」
また、生成AIによるコーディングの自動化より何年も前から先行していた機械翻訳についてはどうでしょうか？外国語を学ぶ必要はなくなると言われて久しいですが、現在でもアメリカ系の外資企業は応募者に英語要件を課していることが少なくありませんし、日系企業が外国人を雇用する際も日本語要件を設けているでしょう。移民審査に公用語要件を設けていない国も少ないはずです。
世界で最も賢いとされている人々でも、少し未来の株価指数の上下さえ当てることができません。未来は誰にもわかりませんが、いずれにせよ、専門知識を学び続ければ、生きているうちにシンギュラリティが来なかった場合の保険になります。「どうせ全部AIに取られるから」と学ぶのをやめるのはリスクになります。
というわけで、AI時代はプログラミングスキルは不要にならずむしろ重要性を増すのではないかというIn my opinionな話でした。
-
非公式Gemのactive_record_extendedをインストールした場合は
.union()メソッドを使えるようになります。 ↩︎ -
「いや、設計は定量的に評価できるだろ」「定性的な評価も重要」など色んなお声を頂きそうです（書いてて怖くなってきました）。私はそれらもすべてYESだと思います。それでも下流工程に比べると上流工程は比較的定性的な側面が強いかなと思っています（そこに優劣を見出すつもりはありません）。 ↩︎
-
もちろんインフラエンジニアやQAエンジニアといったプログラマー以外の現場職種も含まれます。 ↩︎
-
医学部人気｢20年後も続く｣保証ない深い事情 AI時代の到来で医師のステータスも変わるか | 健康 | 東洋経済オンライン、AIで弁護士も大量に失業する時代が来る ｢士（サムライ）業｣はロボットに勝てない？ | 中原圭介の未来予想図 | 東洋経済オンライン ↩︎
Discussion
確かに要件定義を顧客がやる、という流れが起きたら全く逆の話になりますね。
aiで既存の改修は難しくても、新規設計とかはかなり助けになる可能性があるかも。
aiは足りない部分を無理やり繋ぎ合わせて、辻褄合わせしている感はありますね。
そこが厳密さが求められるプログラミングと合ってない部分もありますね