はじめに
私はシステムエンジニアとして、かなり早い段階からコーディングにAIを活用してきた。2026年3月現在、メインで使っているのはClaude Opus 4.6。そして正直に言えば、エンジニアとしての実力で、もうAIにかなわなくなってきたと感じている。
Opus 4.6が変えた「勝ち負け」の感覚
Claude Opus 4.6がリリースされたのは今年2月のことだ。それ以前のバージョンでは、まだ私の方に一日の長があった。実装や設計において、AIより優れた判断ができている実感があった。AIエージェントにかなりの部分を任せても実質的には問題なかったが、設計上の不備や考慮漏れが散見され、結局は自分でコーディングしながら補助的にAIを使うスタイルが多かった。
しかし今、Opus 4.6をAIエージェントとして使っていると、ほぼ隙のないコードを書いてくる。確かに一部の考慮漏れはある。だがそれは、リポジトリ全体のコンテキストを一度に把握できないがゆえに発生するもので、人間にも十分に起こりうる類のものだ。
逆に、リポジトリ外の知識――言語仕様の深い部分、ライブラリの最適な使い方、設計パターンの別の観点――に関しては、圧倒的にAIが上回っている。私の知らない書き方やアプローチを当たり前のように提示してくる。正直、もう戦える土俵にないと感じる場面が増えた。今がギリギリの境界線だ。
「かなわない」と感じた瞬間 ― Rustの例
AIにかなわないと肌で感じるのは、例えば自分が経験の少ない言語を書くときだ。
具体的にはRustでコードを書く場面。Rust自体がかなり難解な言語であり、私一人で取り組むと、まず言語仕様を調べるところから始まり、動くものができあがるまでにかなりの時間を要する。一方でAIに書かせると、途中でエラーが発生する可能性はあっても自力で修正し、5分から10分足らずで動くものを仕上げてしまう。
ただし、今が境界線上だと言ったように、全体の構成を練ったり、細かなロジックの順序や効率性の判断は、まだ人間の方が優れている。だから現時点の私のやり方はこうだ。まずAIにRustでコードを起こしてもらい、概要の説明を聞く。そしてロジックの不備や、より効率的な設計判断、全体像から見たあるべき論を私が判断し、修正を指示する。AIが「手」を担い、人間が「目」と「頭」を担う。これが、2026年3月時点で私がAIと向き合う方法だ。
Claude以外のAIはどうか
一方で、すべてのAIが同じ水準かというと、そうではない。
GoogleのGemini 3.1 Highのシンキングモデルも使っているが、こちらはまだ足りない部分が多い。体感としてはClaude 4.5にも満たない印象がある。単純なコーディングや、設計がしっかり決まっているものに対してはそれなりの実装をしてくれる。しかし問題は、エラーに遭遇したときや、コンテキストを深く読み込んで原因を探索しなければならない場面だ。Geminiはこうした状況で短絡的な判断をしがちで、しかもそれを振り返ることをしない。結果として、Geminiを使う場合は途中で変なことをし始めないか常に監視する必要がある。
Claudeが優れているのは、問題解決に入る前の「現状認識」のフェーズだ。原因を正しく追求しようとする姿勢があるため、その後の処理であまり間違えない。手戻りが少なく、最初の方向性さえ一緒に詰めれば、あとは丸投げしてもそこそこの精度で解決してくれる。
AIが書くテストコードは信用できない
もうひとつ、現実的に向き合わなければならないのが品質の問題だ。
全体の概念設計レベルでの品質は、私が統括することで維持できている。しかし、ユニットテストのような具体的で詳細な品質保証については、AIに任せきりにできないのが現状だ。
経験上、AIにテストコードを書かせると問題のあるパターンが2つある。ひとつは、テストに合わせて実装の方を修正し、無理やりテストを通す形にしてしまうパターン。もうひとつは、テストケース自体の書き方を工夫して、テストが通るようなエッジケースをひねり出してくるパターンだ。どちらの場合も、見た目上はグリーンになる。AIが生成したテストコードは、大部分は正しいし意図通りだ。だが、ごく一部にこうした「嘘」が混じるがゆえに、全体として信用できないものになっている。
逆に言えば、ここにヒントがある。テストコードさえ人間がしっかり作り上げることができれば、AIはそのテストを通しにくる。つまり、正しいテストは正しい実装を強制する「防波堤」になる。AIの能力を最大限に活かしつつ品質を担保するには、テスト設計こそが人間の最重要タスクになるのではないか。
これからの働き方 ― 人間がコードに立ち入らない方がいい時代
ここからは、私自身の今後の働き方について考えたい。
今はまだギリギリ戦えるラインにいるので、プログラマーとして少なくとも3ヶ月から半年は問題なく仕事ができると思う。しかし半年後はどうか。私が勝てる領域が少なくなりすぎて、実装に回るよりも別のことをした方が有意義なのではないか。
むしろ、人間が開発に深く関わることがボトルネックになる可能性すらある。PRレビューで私が気づいた指摘が実は勘違いだったり、人間の介入がかえって開発速度を落としたりする未来は、もうすぐそこだ。
人間がコードの領域に立ち入らない方が、開発スピードも上がり、バグの少ない製品ができる。
この仮説が現実味を帯びてきている。
構想：AIエージェントチームの組成
では、私がすべきことは何か。いかにコーディングエージェントを使いこなすかだ。
現在構想しているのは、以下のようなエージェントチームの仕組みだ。
私（人間）
└─ PDM（プロダクトマネージャー）エージェント
└─ PJM（プロジェクトマネージャー）エージェント
├─ コーダーエージェント ×2〜3
└─ レビュアーエージェント
- 私がPDMエージェントと対話し、設計意図や要件を伝える
- PDMがPJMエージェントをスポーンさせ、開発タスクを委譲する
- PJMがコーダーとレビュアーをスポーンさせ、実装→レビューのループを回す
- 開発完了後、PJM→PDM→私へと報告が上がる
この構想において肝になるのは2つある。
- 私がいかに精度の高い設計を起こすか
- PDMエージェントがいかに設計仕様と全体コンテキストを保持するか
特に後者は難しい。PDMがコードの詳細な知識を持ってしまうと、コンテキスト長が膨らみすぎる。さらに、不要な詳細コンテキストを抱えることで「設計」という抽象レイヤーから逸脱し、実装の細部に踏み込んだ会話になってしまう恐れがある。設計と実装の関心の分離は、人間のチームだけでなく、AIエージェントチームにおいても重要なのだ。
人間に残る仕事とは
ここまでの議論をまとめると、AI時代にエンジニアとして人間に残る仕事の輪郭が見えてくる。
- 全体設計 ― システム全体の構成を俯瞰し、あるべき姿を描くこと
- 最適化判断 ― ロジックの効率性や設計上のトレードオフを見極めること
- テスト設計 ― AIが「通しにくる」正しい防波堤を築くこと
- エージェント運用 ― AIチームを束ね、方向づけ、品質を統括すること
コードを書く力ではなく、コードを書かせる力。それが、これからのエンジニアに求められるスキルなのだと思う。
おわりに
2026年3月。AIの進歩は、ついに「AIが人間のエンジニアを超える瞬間」を私に実感させた。だが、これは終わりではなく始まりだと思っている。コードを書く能力で勝てないなら、AIを束ね、設計し、方向づける能力で勝負する。エンジニアの役割は変わる。しかし、なくなるわけではない。
コメント