はじめに
2025年、私は GitHub Copilot によるコード補完やコミットメッセージ作成、Gemini を用いた週次のミーティング資料作成や手順書作成といった形でLLMを利用していました。
2026年2月からは Claude Code を使い始め、コーディングや資料作成の多くを、このツールで行うようになりました。2026年7月時点では手作業で書いていたコードは、ほぼAIによって書いたものとなっています。
この変化は、エンジニア界隈でのLLM利活用の知見が体系化されたり、新しい使い方が提案されたりすることで、より便利になっていった結果だと考えます。
そうした効率化が進んだ先に、どのような役割が生まれるのか、私なりの考えを述べていきます。
自動化の広がり
歴史としては、18世紀後半のイギリスで起きた産業革命は、工業における生産のあり方を大きく変えました。それまで手作業が中心だった生産は、工場と機械による自動化に置き換わり、大量生産を可能にしました。農業や部品製造など、第一次産業や第二次産業において効率化が進んでいます。
第三次産業でも、ソフトウェアやツールを用いたコンピューター上での業務効率化・自動化、Webサービスによる価値提供は進んでいました。これまではエンジニアリングとして、課題の深堀り、構造化、言語化をし、仕様設計に落とし込み、プログラミング言語やそれに類するツールを用いてコーディングしていた人材が必要でした。
そこに LLM が登場したことにより、さらに広がりを見せていると考えます。非エンジニアがプロンプトでリクエストすれば、それに対応するプログラムがLLMにて生成され、実際に業務に取り入れられる場面が増えているのだと思います。これは、ソフトウェアによってソフトウェアを構築できる時代に入りつつあることを示しているのだと考えます。
ソフトウェア開発における役割の変化
これまでのソフトウェア開発は1人、または複数人によって進められてきました。要件定義や仕様設計、コーディング、テスト、リリースといったウォーターフォールモデルに準える工程があり、これらを少人数のチームで一気通貫して担うストリームアラインドな働き方や、工程ごと、機能ごとに分業する働き方があります。
この工程の中で人が担っていた部分が、LLM に置き換わりつつあります。コーディングが顕著であり、AI エージェントが生成した成果物を、人が品質検証したり、ハーネスなどでチェックしていると思います。
LLM によって浮いた工数を、要件定義の段階から深く関与する働き方に振り向ける動きがあり、その文脈で FDE（Forward Deployed Engineer）などの役割が注目されています。
生産工場の例で考える
たとえば、自動車工場について考えます。
フレームやタイヤは機械によって作られ、それぞれの部品は品質検査を経たうえで機械によって組み合わされ、車体となります。完成した車にも品質テストが行わたうえで納品されます。
生産ラインにおいて人がどこに介在しているかを考えます。
おそらく、工場の作業を一気通貫で監督する人がいるかもしれませんが、実際に手を動かしているものは主に機械だと思います。その機械を操作するときに人が介在し、また、機械が作った成果物を検査するときに人が介在すると考えます。別途、機械自体に不具合が発生した場合、機械を操作している人、または機械を製造した会社の担当部署が機械を直す対応をすると考えられます。
AI エージェントによるソフトウェア開発の例で考える
では、AI エージェントによるソフトウェア開発はどうでしょうか。同様の構造が当てはまるかもしれません。
要件定義を担当する人が Issue を作成すると、それをトリガーに AI エージェントが仕様設計、コーディング、Pull Request の作成までを行います。各工程で品質検証に人が介在する場合もあれば、介在しない場合もあります。最終的には AI エージェントが作成した成果物を人が検証し、リリースします。
仕組みが一度整ってしまうと、要件を伝える人が AI エージェントに逐次指示を出す必要がなくなります。このような開発ワークフローであると、次の人の役割が現れます。
- Issue を作成する人: 要件を伝え、開発のきっかけを作る
- 品質検証を担う人: AI エージェントが作った成果物を検査し、リリースの可否を判断する
- AI ワークフローを作る人: AI エージェントがソフトウェアを作成する仕組みを設計し構築する
それぞれの役割は同一人物でも構わないと思います。品質検証については LLM の出力の再現性が担保されない限りは何かしら必要になってきます。人が介在しなくてもハーネスによって担保されることも考えられます。そうなると、要件を伝える、開発を行ってもらうなどの中核は AI エージェントになってくるのだと思います。
高級言語と機械語による抽象化
LLM による開発では、プロンプトなど自然言語によって開発が行われます。
ここで、高級言語と機械語を整理したいと思います。
高級言語とは、人が読みやすい形式で書くことができるプログラミング言語のことを指します。高級言語で書かれたコードは、コンパイラなどによって機械語に変換され、実行できるようになります。
エンジニアの方々は高級言語で書く一方、そこから変換された機械語を把握している人はどのくらいいるのでしょうか。ある種、裏側の仕組みを知らなくても業務自体は成り立ちます。
LLM による開発も同様のことが言えるかもしれません。プロンプトなどが書ければ、高級言語や機械語がブラックボックスの状態であってもプログラムを作ることができます。もちろん、プログラミング言語の構文やモデル、コントローラー、ビューなどの知識には価値があります。OS、アセンブリ、ネットワークといった低レイヤーの知識も同様に価値があります。しかし、AI 時代において、高級言語よりもさらに上位のレイヤーとなり得る言語、プロンプトやスキル、それに類するドキュメントフォーマットをどう書くかが重要になってくると考えられます。
プロンプトにも、ゼロショットやフューショットといった体系化の試みがあったり、ドキュメントに関しても Open Knowledge Format（OKF）のように AI エージェントに知識を渡すための形式が提案されています。2026年7月時点ではトライアンドエラーによる知識の積み上げが行われている段階でありますが、数年後には体系化されているのだろうと思います。
おわりに
私たちは、高級言語を書かせ、LLMから期待通りの結果を得るためのメタな言語に挑戦している段階にあります。
ソフトウェアを作るソフトウェア、AIワークフローを作ることは、プロンプトやスキルという新しいレイヤーの言語を設計し、それを AI エージェントに解釈させて高級言語や機械語を書かせる仕組み、いわばメタソフトウェアを作ることに近いものです。
この変化がどの速度で、どの範囲まで進むかは分かりません。
高級言語が機械語を覆い隠していったように、この新しいレイヤーの言語もまた高級言語を覆い隠していくのだとすれば、その言語を設計する側に、これからの価値は移っていくはずです。