👨‍💻

AI時代におけるソフトウェアエンジニア考

に公開

はじめに

AI技術の進化に伴い、プログラミングの分野においてもAIの活用が目覚ましく発展している。特にエージェントと類されるAIコーディングツールは自律的な動作を特徴とし、人が直接コードを書く機会を劇的に減少させ、AIが主体となってコードを生成するという手法をプログラミングに導入した。この発展の最中にあって、遠くない将来に「AIがプログラマーの仕事を代替する」「エンジニアやプログラマーといった職業が失われる」といった意見もある。

しかしながら、筆者はそのような意見には懐疑的である。筆者はWeb系のソフトウェアエンジニア(以下「エンジニア」)だが、少なくとも自分の職務上のプログラミングにおいては、AIがその仕事を完全に代替するとは考えていない。

本稿では、筆者の経験を元に、現代のソフトウェア開発とAIの活用を考察する。その結論として、AIはプログラミングの形を変えはするものの、依然として専門知識を有したエンジニアはソフトウェア開発における重要な部分を担うこと、AI技術は従来のソフトウェア技術と一線を画すパラダイムシフトであることを認めつつも、同時にソフトウェア開発においては、これまでも連続的に起こっている技術とツールの変化の過程であり、過剰な情報の喧伝には現実的な視座をもって判断すべきだということを、主張する。

NotebookLMによる音声解説

プログラミングにおけるAI活用の変遷

プログラミングにおけるAIの活用は段階を経て発展してきた。初期においては、ChatGPTなどのチャットインターフェースをもつAIに、プログラミングに関する質問をして回答させたり、コードの断片を生成させた。次にエディタやIDEのような開発環境と連携したツールが登場した。代表的なものはGithub Copilotである。これは従来からあったコード補完機能を、AIによって強力に拡張したもので、これまでの静的解析によるコード補完の範囲を超えて、より柔軟かつ広範囲にコードを生成する。

そして2025年7月現在、この分野で最先端にあるのはエージェントと呼ばれるAIツールである。具体的な実装としてはClineやClaude Codeなどで、この類のツールではプログラマーはソースコードを直接書かず、自律的に動作するAIに指示をすることに注力し、AIが人に代わって大部分の実装を行う。

自律的と称されるのは、AIがコマンドなどのアクションを実行する権限をもち、抽象的な指示から具体的な計画を立案し、その計画を実行する中で、AI自体が単独でフィードバックループを回すという動作をするため、目的に対して人のインタラクションが最小限になるようにデザインされているからである。

またMCP(Model Context Protocol)によって、AIがさまざまなリソースにアクセスする手段が標準化されつつあることにより、より「人が作業する」ことと同等のことが、コンピューターにできるようになってきている。

このようなAIプログラムは、AIエージェント(AI Agents)またはエージェンティックAI(Agentic AI)などと呼ばれる。一般的に、AIエージェントは前述した計画立案やAIで完結したフィードバックループを行わず、比較的シンプルなタスクを実行するのに対し、エージェンティックAIは計画立案とフィードバックループ、場合によっては、複数のAIエージェントを操作することも含めて、より複雑なタスクを、多様な手段を駆使して解決するAIシステムと解釈される。

本稿ではそのような分類は行わず、自然言語による指示でプログラミングを自動で行うAIプログラムを、総じて「AIエージェント」と呼び、以後の論述を行うものとする。

AIエージェントの課題と実態

AIエージェントによる、コードを直接書かずに、自然言語による指示だけでプログラムが実装できるという体験は、過去に類を見ない。これまでコードが書けなかった人も、プログラムを作ることができるようになる。そしてAIの性能向上が進めば、生成されるコードはより高品質になり、いずれ人が書くプログラムより優れたものを生成する。すでに一部ではそうなっているし、急速なAIの進化が、ソフトウェア開発の世界をその方向に推し進めるトレンドを形作っている。これが「エンジニア不要論」のような議論を生み出している。

しかし筆者の経験上、このようなAIエージェントを、現実の職務上のプログラミングに使用した場合、実際には簡単とはいえない課題に直面するのである。

AIエージェントへの指示

まず、AIといえど明確に指示したこと以外は、基本的にやってくれない。AIが「気を利かせて」やってくれることもあるが、伝えていない暗黙の情報をAIが推測するという不確定な要素が生じ、確認のための追加のステップや誤りを誘発する要因になる。

これは従来からある、他者に作業を依頼するのと、実質的に同じ課題を含んでいる。AIに作業を任せる場合、人間に任せるのと同様に、指示の内容が重要となる。特にソフトウェア開発のタスクは複雑であり、AIに期待通りのコードを生成させるためには、適切な情報を提供する必要がある。このこと自体が手間のかかる作業であり、AI以前、昔からあった問題でもある。

ソフトウェア開発では「仕事を依頼する」ことそれ自体に一定の難しさがある。

情報の不完全性

単に人からAIへの指示が難しいということに加えて、そもそも実際のソフトウェア開発の現場では、完全な情報をAIに与えることは、現実的に不可能であるケースも多い。ソフトウェア開発における必要な情報は、直接コードに表現される、実装の情報だけでなく、その仕様となる背景であったり、仕様を決定する関係者の要求や意図など、多岐にわたるためだ。そもそも誰も、本当に必要な情報を、認識すらしていないケースも往々にしてある。プロジェクト進行中に仕様や要求が変更されることもある。

これもまた、AIに関わらず従来からあった問題である。ソフトウェア開発プロジェクトにおける情報の共有、管理について過去から現在に至るまで、様々な手法やツールが生まれているが、多くのプロジェクトにおいて、現在でも継続的な取り組みを必要とする、プロジェクトマネジメント上の重要な課題の1つである。

現実のソフトウェア開発プロジェクトでは不確定な要素が多く、それがソフトウェア開発を本質的に困難にしている。それはAIの時代においても変わりがない。AIは人の作業を代替できる能力を備えつつ、かつコンピューターとしての高速な処理、継続的な実行能力を発揮できる存在ではあるが、不完全な情報環境における課題を魔法のように解決できるものではない。

実用上のAIの性質

筆者の解釈では、AIがこの領域にもたらした最大の発明は「抽象的であいまいな入出力」をコンピューターが扱えるようになったことにある。従来のコンピューターとソフトウェアは「決められた仕様の入力に対して、決められた仕様の出力を戻す」という動作が基本であり、それが計算機としてのコンピューターの最大の特性であった。この性質により、コンピュータープログラムによる処理は、厳格な再現性と正確性をもち、誤りを犯すという人の性質を補完する重要な機能を提供し、発展してきた。

今日のAIはそのようなコンピューターの基本性質を拡張するものであり、それがAIを利用する周辺のソフトウェアやAIエージェントなどの新しい開発ツールのパラダイムシフトの根幹を担っている。抽象的であいまいな表現である自然言語によるプロンプトが、プログラムの入力として機械が解釈できるようになり、バラエティ豊かで柔軟な出力が可能になった。

ここで筆者が主張したいことは、AIによってプログラムの入出力が、これまでにない高度な柔軟性と拡張性を得たとしても、与えられた問題に対してシステム全体として論理的に解決可能なパスがなれけば、精度の高い解は得られないということである。

「XXXというプログラムを作って」というプロンプトで生成できるコードは、原理的にAIが持つ知識、AIがアクセス可能な情報リソースから導出される。不足している情報は、AIがその知識ベースから推測することで埋められるものと考えられるが、推測である以上、確実性が低下し、それが出力の精度低下につながる。最悪なケースは虚偽の情報をAIがでっち上げることだ。これはハルシネーションと呼ばれ、今やAIの利用における基礎的な注意事項になっている。

そして、ビジネス上の現実的なソフトウェア開発において、AIに与えられる情報が不完全なのは前述したとおりである。これが、過剰に評価されるAIの能力と、実務利用における性能のギャップを生んでいる、と筆者は考えている。

数ステップのプロンプトで、AIエージェントがあっという間にプログラムを生成するデモが、ソーシャルメディアなどで拡散されている。しかしそれは、AIが推測して補足する情報のブレを、成果物の品質の評価対象としていなかったり(例えばWebのランディングページを生成させて、細部のデザインや内部実装を「おまかせ」で問題ないとしているケース)、あるいは成果物が、AIの知識ベースにおいてブレなく推測しやすいものである場合(例えば「テトリスを作って」など。テトリスのゲームとしての仕様は良く知られている)など、「デモ」を出力する前提だからである。

能力を拡張するツール

AIを使ってもデモ以上の実用的なプログラムを作れない、などと言いたいわけではない。実際、ChatGPTやAIエージェントを使って、エンジニア職でない人間が、独力で業務上のプログラムを実装した事例を、筆者はいくつか知っている。彼らは、もともとITリテラシーの高い人たちではあったが、従来の常識では専業のエンジニアでなければ難しいと思えるプログラムを実装した。

筆者が重要視すべきだと考えているのは、前述のAIの性質を踏まえ、ツールとして適切に使うということである。重要なのは自分の仕事、自分の能力に合わせてツールとしてAIを活かせるか、ということである。

先ほど言及したAIを活用した非エンジニアの一人は、Webサービスのプロデューサー職で、自身が携わるWebサービスの内部データを別のサーバーに移行するためのプログラムをPythonで実装した。彼のケースがうまくいったのは、ITリテラシーがあり、タスクが独立していてゴールが明確であり、そのWebサービスに対して知見があり、そして目的を達成するまで取り組む継続力があったからだ。

筆者を含め、仕事にAIを活用しようとしているエンジニアが今実際にやっていることは、ツールの性質を把握し、自分の仕事にあわせて、利用環境や使い方を調整し、AIによる出力精度を上げるための試行錯誤をする、ということである。具体的には、情報を整理し、タスクをAIが扱いやすいように分割し、プロンプトを工夫する、などがある。実際、スコープを限定してエージェントに書かせたコードは「自分で書くより早く実装できて良い」となることも多く、筆者は積極的にAIを利用している。

ソフトウェア開発にAIを活用するということを、AIが人の仕事をまるごと置き換えるもの、として捉えるのは現実に即していない。それよりもソフトウェア開発に携わる人間のプログラミング能力を、0から1に、あるいは10から100にするような、能力を拡張するツールとして捉えるほうが、実態にはあっている。そして多くのケースで、ツールとしてのAIを活用する現実的な手段は、地道で漸進的な業務の最適化と使用者自身のスキルの向上なのである。

非エンジニアのプログラミング能力が0から1になることで、今までエンジニアに依頼せざるをえない仕事を独力で処理できる人が出てきて、その意味でエンジニアの仕事は減少する。これは既に起こっていることで、例にもあげた。一方で、エンジニアのプログラミング能力は10から100になる。そしてその100に拡張された能力は、依然としてソフトウェア開発の複雑性の中で必要不可欠なものである。

責任の所在

筆者の理解では「エンジニア不要論」は、人より圧倒的に賢いAIがコードを生成するので、知識労働者としてエンジニアは優位性を失い最終的に不要になる、というものだが、これはソフトウェアを単なるコーディングの結果の成果物としてしか捉えていない見方であり、その点でも筆者の見解と異なる。

職務上で実装したソフトウェアには責任がともない、これは社会的、人間的な要素と切り離せないからだ。

現実社会にあるソフトウェア

ビジネスとして書かれるソフトウェアには、通常、自分以外のステークホルダーが存在している。その場合、コードをAIに生成させたとして、そのコードに対する責任は依然として人間が負う必要がある。

たとえば、ある会社がシステム開発の仕事を請け負ったとして、そのシステムのプログラムをAIに生成させたとする。そのプログラムにバグがあった場合、単に「これはAIが作りました」という回答をして、果たして顧客は納得するだろうか?通常、その次に起こることは「なぜ『あなたは』AIにバグがあるプログラムを作らせてしまったのか?」という責任問題への追求である。AIはツールであり、使用者である人間がその結果に責任を負うというのは、当然の帰結だ。

この場合、顧客が求めているのは「要求を満たすシステムの実装」であり、責任とはそれを遂行する義務である。さらに現実社会においては、要求を遂行するだけでなく、そのプロセスを通してステークホルダーに「納得感」を醸成することも必要になる。不測の事態においては判断ミスを認めて、関係者に謝罪するなどもその1つだろう。これらは極めて社会的、人間的な活動であり、AIが完全に代替することが難しい領域だ。

ソフトウェア開発という仕事においては、人間がAIを使ってプログラミングをするようになるというだけで、AIが人を代替するということにはならない、というのが筆者の基本的な考えである。

正解のない課題と判断

ソフトウェア開発プロジェクト、特にビジネス上のシステム開発では「正解がない」状況での判断がしばしば求められる。どのような設計をし、どのような実装方針をとるのか。どのような技術選定をするのか。ソフトウェア設計上の意思決定は、多くの場合、課題となる要素に対するトレードオフである。

システムの将来的なスケーラビリティ、予期される問題への対処、コードの保守性(堅牢性、拡張性、可読性)を考慮したフレームワークの選定やシステム構成の決定には、唯一絶対の「正解」は存在しない。これらは、単なる技術的な優劣だけでなく、プロジェクトの文脈、チームのスキルセット、コスト、将来のビジネス要件など、多岐にわたる要素を複合的に考慮する必要があるためだ。

扱うべき情報は複雑で不完全であり、確度の高い未来予測をすることは不可能である。正解のない状況で、それでも判断を下してプロジェクトを進行させなければならないのが、ソフトウェア開発のもっとも難しく、そして重要なところである。

AIには、この判断を下すことができない。いや「判断して」と指示すれば判断はする。しかし、それは表面的なもので、AIが下した判断を採用するかの最終的な意思決定は、依然として人に依存する。

未来が不確実である以上、その時点での正解は誰にもわからない。そこで下す判断にはリスクがあり、リスクとは現実社会と人への悪影響の可能性であり、それ故、その責任は人にしかとることができない。

AIの進化は課題を解決するのか

現在のAIの限界と課題について論じると「それはAIの性能向上によって、いずれ解決する問題である」という反論がなされることが少なくない。実際、生成AIの進化のスピードは凄まじいものであり、現在の課題は、AIの性能向上を前提に考察すべきなのは確かである。しかしAIの進化を無条件に「どんな課題も正解に導く能力」のようにとらえて展開する未来予想は適切ではない。

プログラミングの抽象化

情報技術の発展は抽象化の歴史でもある。ここでの抽象化とは、技術的な詳細を隠蔽し、汎用性を高めたインターフェースを導入することで、技術の利用用途の拡張や、利便性を高めることである。多くの情報技術では、この抽象化が層(レイヤ)を形成している。

たとえばコンピューターネットワークはOSI参照モデルと呼ばれる、技術的な抽象化レイヤを構成している。この仕組みにより、筆者のようなWebアプリケーションのプログラマーは、コンピュータが物理的にどのように接続され、どのように電気信号を送受信しているかなどの低レイヤの技術を意識することなく、プログラムを実装できるのである。

プログラミング言語においては、コンパイラやアセンブラといったソースコードを変換するプログラムが抽象化レイヤとして機能している。コンピューターのCPUが直接解釈可能なのは、0と1を並べた機械語と呼ばれるビット列だけである。しかし、アプリケーションを実装するプログラマーは、機械語の知識がなくともプログラミングが可能で、それは前述のソースコードから機械語を出力する仕組みがあるからである。

AIエージェントのコード生成が、この抽象化概念における新しい上位レイヤとなって、現在のプログラミング知識が不要になるという意見がある。つまり今現在のプログラミングが、コンパイラが出力する機械語を知らなくても問題がないように、将来のプログラミングは、AIが出力するプログラミング言語を知らなくても問題がなくなる、という理屈だ。

この論理展開は、現在のAIが出力するコードの品質、可読性、メンテナンス性などの問題が過渡期のものだと主張する。高度に発達したAIに、人間の認識能力を前提としたソースコードの可読性や構造を問題とするのはナンセンスであり、もはや人がコードを読む必要はない。我々が機械語を直接読むことがなく、その「読みにくさ」を問題にしていないように。

システムとしての性質の混同

筆者は、このような未来予測には懐疑的である。全体として改善はされていくが、根本的な解決「プログラミング言語を知らなくても問題にならない」には到達しないと考えている。その根拠は、このような論理展開は、生成AIが持つ「あいまいな入出力」という性質と、従来のコンピュータープログラムが持つ「厳密な入出力」という性質を都合よく混同していると、考えられるからだ。

コンパイラが機械語を出力することと、AIがソースコードを出力することは、似て非なるものだ。コンパイラは入力としてのソースコードの仕様が厳密に規定されているからこそ、機械語の出力に再現性が保証される。この再現性と完全性があるからこそ、コンパイラによる抽象化は下位の技術詳細を隠蔽でき、人の機械語からの脱却を可能にしている。コンパイラ(が解釈するプログラミング言語)のルールに従う限り、完全に意図した通りの機械語が出力されるので、機械語を直接扱わなくて済むのである。

一方、AIは入力の厳密性を要求しないので、柔軟な情報入力が可能であり、それによってプログラミングの新たな手段と、高度なコード生成を実現している。反面その出力から厳密性や再現性は失われている。意図した通り動くコードは、原理的にその意図を100%情報として伝えなければ、再現性をもって生成できない。そして、それを最もコンパクトな形として表現しているのは現在のソースコードそれ自体にほかならない。

AIの能力で、プログラミングを現在のソースコードから脱却させて、新しい概念に引き上げるというのは「あいまいな入力」を受け取るAIに、従来のコンピュータープログラムのような「再現性のある厳密な出力」を要求している。それは原理的に実現困難なことである、というのが筆者の認識である。

ボトルネックの混同

AIの性能は今後も向上していくと考えられる。しかし現実のソフトウェア開発の課題解決においては、AIそのものより、AIを扱う人や社会がボトルネックになっているケースも多い。このことは、情報の不完全性や責任の所在という観点から、すでに本稿で論じた。AIの性能向上はこれらの解決には直接的に寄与しない。

AIが品質の高いコードを出力できない理由としては、AIの性能よりも、システムの仕様を適切な情報量で伝達できないことのほうが、支配的な要因なのである。

AI時代のプログラミング

筆者の実体験では、仕事によっては8割以上のコードをAIエージェントに生成させているケースもある。しかし、それはプログラミング作業の8割で人手が必要なくなった、ということとイコールではない。これを解説するためには、プログラミングという仕事を分解して、実際に何がどのようにAIの影響を受けたのか(そして何が影響を受けていないのか)を、個別に見ていく必要がある。

キーボードでのソースコード入力は減る

これは文字通りの「手作業」を減らすという意味で、確実な作業の効率化がなされる。ソースコードはAIエージェントか、Github CopilotのようなAIによる補完機能によって、機械的に生成できる場面が格段に多くなった。生産させるソースコード量に対して、手を動かすという物理的な動作が少なくなる、ということに加えて、タイプミスなども軽減される。

一般的なロジックの実装はAIで代替できる

プログラムには「ロジックは分かっているし、書こうと思えば書けるだろうが、ゼロから自力で書くのが難しいか面倒」というコードが少なくない。例えばソートや探索といったアルゴリズムの実装やテストコード、などである。特に要求する実装が、誰が書いても同じようなコードになり得る一般的なロジックだと、AIの利用において有利に働く。これらは、必要となる情報が、AIがもつプログラミングの知識に含まれていたり、指示とその結果が明確になりやすい傾向があるため、AIによって代替しやすい作業になっている。

また、生成されたコードは、通常見れば理解できるので、AIによる間違いを早期に発見しやすいということも重要だ。これは「難しい漢字を書くことはできないが、読むことができる」という状況に似ている。AIのサポートによって、これまで実装に必要だった技能を一部スキップすることが可能になる。

パターン化された実装はAIで代替できる

一般的なロジックに似たものとして、プロジェクト内でパターン化された実装もまた、AIによって生成しやすいコードである。職務上のプログラムでは「すでにある実装と大体同じだが、少しだけ違う」コードを書くことがしばしばある。AI以前ではエディタの置換機能を使ったり、スクリプトを書いたりすることで自動化することもあったが、細部の違いを完全にカバーできない場合も多く、煩雑な手作業を排除しにくいタスクでもあった。

AIはこのような作業をかなり上手く処理することができる。AIエージェントに対し、参考にするソースコードを明示し、変更の内容を説明することで、期待した実装を生成できるケースはかなり多い。

要求される思考は大きく変わらない

筆者の職責には、コードの品質を管理、保証することも含まれる。これを遂行するためには、内部実装の詳細を把握する必要があるため、AIが生成したコードであっても、必ず読んで「理解する」という作業が発生する。従来では、コードを「書く」という行為に、理解するという作業が暗黙的に含まれていたが、AIによるコード生成はこれをスキップするので、生成されたコードを理解するという補完的な作業が、現実的に欠かせないものとなっている。

そして、品質保証のためのコード理解とは、単に生成されたコードのロジックを読み取ることだけではない。全体のアーキテクチャにおいて一貫性が保たれているか、他のコードや機能との矛盾や不整合はないか、将来におけるリスクになり得ないかなど、複雑な思考と判断が必要とされるケースもある。

これらの作業のための認知負荷は、従来のプログラミングと大差がない。思考のタイミングがコードを書いているときか、書き終わった後かの違いである。むしろAIツールの使い方によっては、この負荷は高まることもある。自分が直接書いていないコードを解析する場合、そこに至るまでの様々な文脈がスキップされている。そのため、一度により多くの未知の情報を処理する必要があり、認知負荷が高まる可能性があるためだ。

最適化を必要とする

筆者の経験則では、コードを理解するのに最も有効な方法はコードを実際に書くことである。コードを書くことは、単にプログラムを実装するという作業に加えて、その行為の過程で、そのプログラム全体に関する理解を脳内に構築するという側面がある。つまり、ある種の学習プロセスがそこに含まれている。学習し、理解が進めば進むほど、プログラマーの思考と認知にかかる負荷は軽減され、より高速な意思決定が行えるようになる。

AIを活用した開発においては、このようなコードの実装と学習プロセスを見直し、最適化する必要がある。人が直接コードを書く機会は減少する。それでも品質と責任のために、依然としてコードを理解する必要がある。AIが人の作業を代替してコードを生成することに対して、それを扱う人間の認知能力が追いついていないことが、重大なボトルネックになる。

取り組むべき対策はいろいろ考えられる。

  • 認知負荷を下げるために、一度に生成されるコード量がコンパクトになるようにAIへの指示を工夫する。
  • テストコードで、実装の詳細を解析しなくても、検証結果が得られるようにする。
  • そのために、テストコードをAIに書かせやすいように、アーキテクチャを改善する。

これらはあくまで、筆者の職務上におけるAI活用の課題であり、誰もがこのような対応をしなければならない、という主張ではない。たとえば、プロトタイプを作成する業務であるなら、内部実装の品質確保のプライオリティは下がるだろう。その場合そもそもAIが生成したコードを、詳細まで把握すること自体をしなくてよいかもしれない。

自分の仕事にあったAIツールの利用方法を見つけ、ボトルネックを排除し、最適化する必要がある。これらは、従来のソフトウェア開発の環境改善と本質的に同じ仕事である。ツールは適材適所で使用する。フィードバックを得て、自分の仕事、自分のプロジェクトにあったツールと手法を選択する。万人に適用できる解決策は存在しない。AI時代においてもそのことに変わりはない。

結果として、AIエージェントを使った開発は、コード生成の恩恵により開発体験として実装スピードは上がるが、その分プログラマーがコードを把握するための認知負荷が増す。そこには従来のプログラミング知識が必要不可欠で、ツールを最適化するための改善といった取り組みも依然として必要である、というのが筆者の体験による一定の結論である。

現実を見据える視座

本稿では、ソフトウェア開発におけるAI技術の活用を考察してきた。AIの進化の過程を言及し、過剰ともいえる機能性への認識に対しては、AIのもつ性質や実社会における責任などの課題を取り上げて反論し、現実的な開発ツールとして解釈すべきであることを論じた。

ソフトウェア技術は変化の速い世界である。新しい情報にアンテナを張ることは必要なことであり、エンジニア職における基本的な生存戦略といってもよい。しかし、日々新しいツールや新しいモデルがリリースされるAI技術の情報の多さとその過熱ぶりに、辟易する人もいるだろう。特に「AI驚き屋」と揶揄されるタイプの情報発信は、ソーシャルメディア上でアテンションを引くための過激な表現とともに流布されるため、厄介である。

筆者は、職業エンジニアであり、自身の直接的な業務改善におけるAI活用に興味があり、本稿での考察がやや近視眼的なものであることは認める。しかし、未来は現在と繋がった先にあり、AIを含め情報技術は万能の魔法ではない。課題の解決には論理的な根拠が必要で、それを現在の現実的な視点で考察することは、過熱する情報の真偽を判断する有効な手段になり得るはずだ。

現実のプロジェクトを見る

最も重要なのは「それが自分にとって有用なのか」である。ソフトウェア開発にはAI技術以前から多種多様なツールが存在している。設計のためのアーキテクチャやプロジェクトマネジメントの手法も数多く存在している。しかし、そのどれにも「唯一の正解」と言えるものは存在しない。

AIも例外ではない。プロジェクトの規模と性質、チームのスキルセットなど、ツールがうまく機能するかはプロジェクト固有の条件を前提にしなければ判断できない。可能なら実際にツールの導入を検証してみるべきだ。それで有用なら採用すればよいし、ボトルネックがあるなら改善できるか検討する。新しいツールが常に「正しい」とも限らない。実際のプロジェクトでの検討と検証、フィードバックを得ることが重要なのだ。

拡散目的でソーシャルメディアに投稿されるAIコーディングのデモは、架空のプロジェクトの架空のプロダクト、架空の仕事でしかない。そこから導かれる「エンジニア不要論」で、架空のエンジニアの仕事の未来を心配することに意味はない。

ソフトウェア開発は常に変化している

AIはプログラミングに変化をもたらしたが、そもそもプログラミング、ソフトウェア開発は常に変化してきている。筆者のエンジニアとしてのキャリアは20年以上にわたるが、現在の仕事で利用しているプログラミング技術やツールの多くは、20年前には存在しなかったものだ。

スマートフォンは20年前には存在しなかった。筆者はスマートフォンアプリの開発も仕事の一つとしているが、これは20年前には存在しなかった仕事である。

AI技術が特別に大きな変化であることは間違いない。だが技術的なパラダイムシフトであることが、まるで人知を超えた制御不能な構造改革を起こすかのように考えるのは、間違っている。変化は起きる。しかし、それは技術的な知見を元に、観察を怠らず、好奇心を働かせれば、適応可能である、というのが筆者の見解である。

Discussion