ソフトウェアエンジニアとしてこの先生きのこるには(2026)
作成日: 2026-05-22 作成者: Morix
キャリア迷子になりつつあるので、一回自分の中でソフトウェアエンジニアの生き方を整理してみる。
この記事を書いてから4か月くらい経った。
コーディングエージェントのモデル性能は更に増した。細かい指示をしなくともいい感じに解釈してくれることが増えた。
しかし使い方はそんなに変わっていない。AIが自律的に開発するための一連のワークフロー（いまはこれをハーネスエンジニアリングと呼んでいるようだ）を微調整しているくらい。
現状はこんな感じ：
- Claude Codeのauto modeのおかげで、開発が止まることがほぼなくなった。計画を立てて承認すれば必要な検証フローをすべて実施し様々な視点でレビューを行い、さらにダメ押しで別モデルのCodexのレビューをするようにした結果、完全に動くものが出来上がる状態になった
- 今は1人でプロダクト開発に勤しんでいるが、もし誰かエンジニアが入ってきてもすぐにこのワークフローを使ってプロダクト開発ができるようにしているので、チーム開発対応もバッチリ
ってことで、やりたいことを詳細にAIに伝えることができ計画の妥当性を確認できれば、エンジニアじゃなくてもタスクを進めることが可能なわけだ。
「やりたいことを詳細に伝える」も別にエンジニアがやらなくてもいい。プロダクトに必要な知識をドキュメントやスキルとしてちゃんと整備していれば、ビジネスの人だってやれる。
なのでエンジニアだけがやれる仕事としては「計画の妥当性を確認すること」「開発完了後の内容確認」「動作確認」「AI開発環境を整える」になるのかな。
それぞれどんな仕事なのか考えていく。
計画の妥当性の確認
LLMが出した実装計画が妥当かを確認するのがエンジニアの責務かなーと思ってる。
僕が作っているプロダクトの実装計画（Claude Codeのplanモードの出力をイメージしてほしい）では、次のフォーマットで計画ファイルを出力している。
- 計画の目的 — 何を達成するか
- 変更の概要 — 何が変わるか / 誰に・何のために / 実装方針サマリ(修正ファイル一覧は書かない)
- ドキュメント影響 — ドキュメントへの影響をチェックリスト形式で判定
- 検証内容 — 観点ベースのチェックリスト
- レビュー — 使用するレビューエージェントはどれか。コード品質やセキュリティなどいろんな観点ごとのレビューエージェントがある
- タスク計画 — 5フェーズ構成
- 実装フェーズ(TDD)
- 検証フェーズ
- レビューフェーズ
- 最終チェックフェーズ
- 報告フェーズ
重要なのは1〜4。計画を実行する過程と結果のイメージが人間とLLMで合ってるかを確認するために必要で、どんな検証をして、結果こうなります が分かればいい。
3のドキュメント影響に関しては、機能追加なら機能一覧ドキュメントが修正されてるべきだし、アーキテクチャを変更するような複雑な修正を要請した場合はシステム系のドキュメントが修正されているべきなので、そういうのも漏れないよねっていうチェックのために見る。
5と6は全く見てない。これは完全にLLM向けの内容だからだ。
じゃあ1〜4の確認はエンジニア以外だと難しいのか？僕は難しいとおもっている。もっというと4の検証内容確認が難しいと思っている。
というのも、対象のプロダクトのアーキテクチャ・ドメインロジック・テスト手法・セキュリティリスクなどが頭に入っていないと、修正に対する検証内容の網羅性を承認することができないからだ。
この確認はAIに置き換わることはないはず。なぜなら承認をするということは責任を取るということで、責任を取ることは人間しかできないから。
あとここの内容が実装の品質にも関わってくるので手を抜けるところではないってのもあるな。
開発完了後の内容確認
計画がおわり、LLMが実装完了を報告してきた後の話。
計画からのずれの確認や、実際の成果物を見てそれを承認するわけだが、これもエンジニアが見ないといけないと思っている。理由は単純でコードを見る必要があるから。
とはいえ1行1行見る必要はない。ざっくりどんな方法でタスクを実装したのかを知れれば良い。エンジニアであればタスクをどう実装するのかイメージではできているはず。そのイメージとずれがないかここで確認するのだ。（もちろん計画段階でも見るが、成果物を見るほうがずれの確認がしやすい。）ここでずれが発生した場合、LLMと話して修正させるのか、計画からやり直しさせるのかを決める。
またLLMが実装した内容を見て、よりよい実装を思い浮かぶこともある。
最近あった出来事を例として挙げてみる。AIエージェントを作っていて、今までLLMに生成を任せていたセリフがあった。なぜ任せていたかというと「◯◯というセリフをこのタイミングでは喋ること」というシンプルなルールだったからだ。しかしそのセリフの生成ロジックが複雑になってきてそのためのプロンプトも増えてきた。プロンプトが大きいとLLMの精度は落ちるしコストが高くなる。
このセリフを生成するというものは今まではずっとLLMの責務としていたので、それを踏襲するとプロンプト改修となるのだが、その生成ロジックは機械的に生成可能だ。だからプログラムでセリフを生成したほうがいいのだが、その発想の転換はLLMは自発的にはしない。AIのレビュー観点に入れたとしてもこういうケースに対応するには曖昧な指示しかできないので、有効なものにはならないだろう。
このような発想の転換やひらめきというのは現時点で人間にしかできないし今後もあやしい。ゆえにプロダクトの仕組みの理解やどんな修正をしたのか・その方針は正しそうかという確認が今後も求められるので、プロダクトの運用保守にエンジニアは必要になる。
動作確認
主にStaging環境など検証環境での話。
CIでE2Eテストを回し、検証環境で自動テストを回していればデグレによる問題はほぼ防げるのでその観点ではエンジニアはいらなくなる。修正した機能のテストも検証項目の洗い出しや実際のテストはLLMに極力やらせたい。
エンジニアがやるべきなのは、その検証項目の妥当性の確認とLLMの検証結果の確認だ。
検証項目の妥当性は前述したように知識がないとレビューすることはできない。
LLMの検証結果の確認は、「どんな操作をしてその結果どうなったか」を確認することだ。なので操作ログを残すような工夫が必要となる。
動作確認の承認とはそれすなわち責任を負ってリリースをするということだ。責任を取れるのは人間なので、その責任をとっても問題ないかきちんとテストの証跡を確認する必要がある。LLMは嘘をつくのでテスト結果だけ見るのでは足りず、その過程を見ることが重要なのだ。
あと動作確認でもう一つ重要なことがある。モンキーテストだ。
修正機能を人間も触ることが重要。LLMの検証の裏付けという一面もあるが、それよりも「ひらめき」を重視している。
検証環境（あるいは本番と同様の環境）でポチポチ触ってみて、UI/UXの気づき・処理速度の気づきなどが得られることがある。
ただこれに関しては必ずしもエンジニアじゃないといけないわけではないが、エンジニアの視点でのひらめきがあることがあるので、エンジニアも積極的にモンキーテストすべきだ。
AI開発環境を整える
リポジトリの内容がソースコードしかない場合、その状態でLLMに作業をお願いしてもうまくいかないだろう。
それはLLMが自律的に開発完了するための仕組みがないためだ。そんな仕組みはなくても動くものはできることもあるが、正しく動くものなのか？漏れはないか？など不安が残るし、それを確認するのは大変なことだ。
だから人間が安心することができる成果物を生成するための環境を整えるのがエンジニアの仕事だ。
ここで言う「環境」とは、使用しているAIコーディング支援ツール(Claude Codeのようなもの)の流儀に則った開発フローや仕組みのことだ。
LLMがうまくタスクを実行できるようにAIコーディング支援ツールをラップする「俺が考えた最強のAIコーディングツール」のことではない。あの種のツールはLLMが決められた手順でタスクを進めることを強制するツールという認識で、そういうものは支援ツールやモデル自体の進化で不要になる。そんなものに時間を取るのは無駄だと思っている。なんならそのようなツールは個人利用の枠を出ないことが多々あるので、チームの開発生産性向上を阻むものとしてむしろ害になるとも思っている。
Claude Code（あるいは他の支援ツール）の流儀に則った開発フローや仕組みとはなんだろう？
例えばplanモードであったり、スキルやサブエージェントのことだ。これらを駆使しLLMに必要な知識や検証手段を与え、LLMによる実装の計画と結果を人間が見やすいよう出力を定義し強制させることを仕組み化する。
必要な知識や検証手段はプロダクトやチームごとに異なるため、LLMがよしなに生成することはできない。必ず人間の知識を必要とする。そして1回作っただけでは終わりとはならない。LLMと開発していく中で意図した動きをしないことは多々ある。開発を重ねるごとにこの仕組みを洗練させていく必要がある。この進化を補助することもエンジニアの役目だ。
検証手段について触れたが、ユニットテストやE2Eテストを作らせることも重要。AIの自律的な開発において検証手段を用意することは必須。これがないと完全に動くものを作る確率が大幅に下がる。また人間にとってもこのようなテストがないとデグレってないか確認ができないし、成果物が動くことの確認がしづらい。
ただ作らせるだけでもダメで、タスク完了後にどんなテストを実装したか解説させ、それが十分かどうか確認することも必要。
ソフトウェアエンジニアとしてこの先生きのこるには
以上の話をまとめると、次の仕事は依然としてエンジニアの仕事として残っていくだろう。
- LLMが出した計画の妥当性の確認
- LLMが生成した成果物の確認
- LLMが生成した成果物の検証環境や本番環境での動作確認
- AI開発環境を整えること
しかしこのうち3つは承認作業だし、AI開発環境を整えることも四六時中やる作業ではない。つまりこれらに時間を多く費やすことはもうないのだ。
だから今まで実装作業に費やしていた時間を他のところに当てる必要がある。
例えば・・・
- 顧客理解や要望抽出に時間を使ったり
- プロダクトの体験を上げるための調査検証を行ったり
- プロダクトで得たAI開発知見を他チームにも展開し生産性を高めたり
- チーム全体の生産性をあげるための施策を検討したり
上記のような、より広範囲な仕事を担える存在にならなくてはならない。そしてそれらの仕事もLLMを駆使し、効率的にこなしていく必要がある。
このような世界観になると、チームに必要なエンジニアの数は間違いなく減る。1人で行えるタスク量が増えたからだ。
チームメンバーの数が多いと意思決定が遅くなるので、チームは2名、多くて3名体制が主流になりそう。
じゃあ職に困ることがありそうかというと、どうだろう？困らないんじゃないかと思ってる。
事業が上手く行っている会社であれば、新たな事業がポンポン出てくるのでエンジニアの頭数が必要になるのは変わらない。まぁそんな会社ばかりじゃないから今あるIT企業で必要なエンジニアの頭数自体は減るかも知れない。SIerはよくわからん。
ただいままでエンジニアを採用していなかった企業がAI導入によってエンジニアを必要とするケースは増えてくるんじゃないかな。だから市場全体で必要なエンジニアはひょっとすると変わらないのかもなーと思った。
エンジニアに求められる能力はより上流になった。AIをマネジメントする能力が必要だからだ。この能力がないエンジニアは今後生き残れないだろうなー・・・
番外編: プロダクトの立ち上げについて
↑では触れなかったけど、 0→1フェイズでのプロダクトの立ち上げも当然だけどエンジニアは必要。よく知らない人がバイブコーディングだけで企業として金を取れるシステムは作れない。
なぜか？
- AI開発環境を整える必要があるから
- 長期の運用保守を考えた適切なアーキテクチャ・インフラ設計が求められるから
- プロダクトとそれに依存するインフラやAPIに繋ぐ必要上、そのものについての知識を求められるから
これらの知識はLLMに聞けばわかることもあるが、それが真実であるか・妥当かどうか判断する知識がないといけない。
ただ知識さえあれば1人でプロダクト立ち上げはできる。そういう意味ではフルスタックなスキルを持っているエンジニアの需要はさらに上がっていくんじゃないかなと思っている。