agentic codingに「責任」だけは渡せない

この記事でわかること

• なぜAIがコードを書いても「デリバリー速度」が上がらないのか
• エンジニアがAIに絶対に渡してはいけない「責任」の正体
• 責任を取れる状態を維持する具体的な方法

コードレビューで止まっているのは、いつも私だった

この半年、コーディングという行為のかなりの部分がagentic codingに置き換わっていった。

CursorやClaude Codeがコードを書き、指摘すれば修正し、テストまで生成してくれる。それでも、プロダクトのデリバリー速度が劇的に上がったかというと、そんなことはなかった。

理由は単純だ。AIがコードを書くスピードに、人間の判断が追いついていない。

とくに顕著なのが、コードレビューだ。他のメンバーがAIと作ったPRを、私がレビューする。このとき、私がボトルネックになっている。

差分を読み、意図を理解し、設計の妥当性を判断する。AIは「パターンとして正しいか」は見てくれるが、「このプロダクトに合っているか」は見てくれない。そこはまだ、人間の仕事だ。

テストも同じだ。AIはテストコードを生成できる。でも「何をテストすべきか」「どこまでやれば十分か」「どうやって検証するか」を決めるのは人間で、ここでも立ち止まる。

つまり、コーディングという行為の前後に存在する「判断」の工程で、人間が律速になっている。この「判断」の正体をたどっていくと、結局は「責任」に行き着くのだと気づいた。

AIと人間、それぞれの領分

AIはコードを書ける。でも、そのコードが誰にどう届くかの責任は取れない。

責任とは「これで大丈夫です」と言える状態のことだ。自信を持ってリリースボタンを押せるかどうか。その自信の根拠を集める作業こそが、コードレビューであり、テストの範囲決めであり、設計の検討なのだ。

そして責任は、AIに代替できない。これは技術の限界ではなく、構造の問題だ。責任を負う主体が人間でなければ、誰もそのプロダクトを使わない。

エンジニアの仕事の重心は「責任を取れる状態」に移っている

こう整理してみると、エンジニアの仕事の重心は「コーディング」から「責任を取れる状態を維持すること」に移っている。

私がフロントエンドエンジニアだからというのもあるが、最近はコーディングそのものよりも、以下を考える時間が増えている。

• WCAGへの配慮
• 使い勝手、直感的に理解できるUI
• 品質保証の観点

これらは「コードを書く前」か「書いた後」の工程だ。

コードを書くという行為は、もはや人間の価値ではないのかもしれない。価値があるのは、そのコードが誰かの役に立つと判断し、責任を持って届けることだ。

責任のまわりにあるカオスを整える

一方で、責任を取るための準備作業には、まだまだ非効率な部分が多い。

• 影響範囲の調査
• 仕様の確認
• 関係者とのすり合わせ

このあたりの「カオス」には自動化の余地がある。ここを整備していくことが、これからの各ロールの価値になっていく。

そもそも、AIに判断を委ねすぎると自分で考えなくなってしまう。Xで「認知的降伏」と呼ばれる現象だ。自分の頭で考えられなければ、責任も取れない。

フロントエンドで言えば、以下は「責任を取れる状態」を豊かにする仕組みだ。

• アクセシビリティチェックの自動化
• ビジュアルリグレッションテストの整備
• デザインシステムによる一貫性の担保

責任そのものは人間にしか負えないが、そのまわりにあるカオスはAIや自動化でかなり整理できる。

まとめ：責任を手放さないために今日からできること

Agentic codingがコーディングを吸収していく時代に、エンジニアが手放してはいけないのは「責任」だ。責任はAIに代替できないからこそ、人間の価値になる。

コーディングの速度ではなく、責任を取れる状態をどれだけ豊かにできるか。これが、これからのエンジニアに求められることなんじゃないかと思う。

責任を取れる状態とは、設計が環境の変化に追いついているかを常に把握することでもある。理にかなった設計がいつのまにか悪い設計になるように、状況は変わっていく。その変化に気づき続けるのも人間の仕事だ。

コードを書かなくなってもエンジニアとして研鑽を続ける理由については、5ヶ月間AIに任せ続けた長期実験で詳しく書いた。

効率化や最適化のやりすぎで壊れてしまう「最適化疲れ（Over-Optimization Backlash）」も、エンジニアが意識すべきリスクの一つだ。やりすぎない線を引くことも、ある意味で責任の取り方だと思う。