AIで速く書けるだけのエンジニアは、もう危ない

AIは、分かっている人を強くし、分かっていない人をごまかす

リクステップでは、業務アプリ、AI活用、社内システム、プロダクト開発の現場でAIをかなり使っています。 使うほど分かるのは、AIは「分かっている人」をさらに強くする一方で、「分かっていない人」を分かっているように見せてしまうということです。

前者は、AIの提案を材料にして設計を前に進めます。後者は、AIの提案をそのまま自分の判断の代わりにします。 見た目の成果物は似ています。けれど、障害対応、仕様変更、セキュリティレビュー、顧客説明の場面で差が出ます。

僕が現場で見ている分岐点は、AIを使ったかどうかではありません。最終的な説明責任を、自分の側に残しているかどうかです。 ここをAIに渡した瞬間、その人の成長は止まります。

AIに任せていい仕事、任せきってはいけない仕事

僕は、すべてを自分で書くべきだとは思っていません。定型的なコンポーネント、CRUD、スキーマ変換、テストケースのたたき台、ドキュメントの初稿。 こうした仕事は、AIに任せた方がいい場面が多い。

逆に、業務ルール、権限、課金、会計、個人情報、障害時の復旧導線のような領域は、絶対に任せきってはいけません。 そこは会社の信頼や顧客の業務に直結します。AIが出したコードでも、責任は実装者とチームに残ります。 「AIがそう書いた」は、障害報告にも顧客説明にもなりません。

AI生成コードを見るときの4つの確認

AIが出したコードは、完成品ではありません。レビュー対象です。 ここを読み飛ばす人は、実装を速くしているのではなく、事故の発見を後ろに送っているだけです。 僕は少なくとも次の4点を見ます。

AIを使っても技術力を落とさない開発フロー

AI活用を禁止する必要はありません。むしろ積極的に使うべきです。 ただし、次のように「AIに任せる部分」と「人間が持つ部分」を分けると、速度と学習を両立しやすくなります。

研究からも、同じ方向の示唆が出ている

これは感覚論だけではありません。 AnthropicのAI支援とスキル形成に関する研究では、新しいライブラリを学ぶ場面で、AI支援が生産性だけでなく理解度にどう影響するかを調べています。 重要なのは、AIを使うこと自体ではなく、説明を求める・概念を確認する・自分で考える余地を残す、といった使い方の違いです。 AIを「答えを出す機械」として使うのか、「自分の理解を鍛える相手」として使うのかで、数カ月後の差はかなり大きくなります。

MIT Media Labの「Your Brain on ChatGPT」や、LLMへのアクセス順序が意思決定に影響することを扱った研究も、同じ問いを投げかけています。AIを最初に置くのか、自分の仮説を置いてからAIを使うのか。順番は思った以上に大きい。

最後に——AIに奪われるのは仕事ではなく、考える機会かもしれない

AIによって、エンジニアの仕事は減る部分もあれば、むしろ難しくなる部分もあります。 書く量は減る。判断の重さは増える。だからこそ、日々の開発で「自分はこの変更を説明できるか」を問い続ける必要があります。

次にAIへ依頼する前に、まず一文だけでいいので「自分は何が問題だと思っているか」を書いてみてください。 その一文があるだけで、AIは代行者ではなく、思考を進めるための相手になります。