AIが代替できないソフトウェアエンジニアリングの領域

AIブームが始まって以来、AIがソフトウェアエンジニアを代替する様々な方法について常に耳にします。プログラミングから計画段階に至るまで、誰もが役割全体を時代遅れにする新たなWeb革命の真っ只中にいると考えているようです。しかし、正しい考え方だとは思いません。AIはソフトウェアエンジニアを代替するのでしょうか。答えはノーです。しかし、そもそもエンジニアリングではなかった業務の一部を代替するでしょう。

本記事の冒頭で結論を述べます。AIはソフトウェアエンジニアを代替しません。しかし、ソフトウェアエンジニアは新しいツールを使用し、プロセスを適応させる必要があります。最も重要なのは、AIを取り入れて活用するように思考を適応させることです。コードを書く負担を取り除くと、残るのはすべてエンジニアリングです。つまり、判断力、システム思考、そして結果に対する認識です。「AIが代替できないものは何か」という問いに対する答えは、人々が考えるよりも具体的です。

AIが実際に代替したもの

2022年にOktaに入社した当時、主な役割はコードサンプルの作成とAuth0ブログでのチュートリアル執筆でした。シンプルなアプリであっても、コードサンプルの構築には時間がかかりました。スキャフォールディングし、APIエンドポイントを書き、すべてをまとめる必要がありました。UIを備えたWebアプリケーションの作成については言うまでもありません（フロントエンドのコードを書くのが好きではないことを考慮すると尚更です）。

今日では、Claude Codeを使えば数分でコードサンプルを作成できます。誰も反論できない事実です。AIはコードを書く「負担を取り除き」ました（一部の人はコードを書くプロセスを楽しんでいますが、別のブログ記事のテーマになるため括弧書きにしています）。AIが代替しなかったのは、何を構築するかを決定するような、コードを書く前の創造的なプロセスです。なぜ失敗するのかを理解し、トレードオフを評価し、コードが安全でないタイミングを把握することです。

現在、新しい「ボトルネック」が存在します。ソフトウェアエンジニアとしての判断力です。判断はこれまで以上に目に見えるようになり、決して簡単ではありません。実際、状況はさらに複雑になっていると言えます。LLMによって生成されたコードは少し扱いにくい場合があり、十分に確認しないとブラックボックスのように感じられることがあるためです。

生成と理解のギャップ

見出しは新しいギャップのように聞こえるかもしれませんが、本当にそうでしょうか。ギャップは常に存在していたと思います。しかし、自分でコードを書かなければならなかった時代には、何が起きているのかを理解する「必要」がありました。今日ではどうでしょうか。コードの観点ではそうではないかもしれませんが、構築している製品の観点では間違いなく理解する必要があります。プログラミング部分は速くなったかもしれませんが、理解する部分は速くなっていません。

ジュニアエンジニアを例に挙げます。現実として、システムが持つ複雑さを理解する前に、機能するアプリ全体を生成できるようになりました。生産性が向上したということでしょうか。短期的にはイエスと言えますが、長期的にはそうではありません。

理解していないコードを出荷できないため、最終的に理解のギャップをもたらします。しかし最も重要なのは、理解していないシステムをエンジニアリングできないということです。わずかな違いがありますが、ジュニアエンジニアが絶望的だという意味ではありません。学習経路が変わったということです。ゼロからコードを書いて学ぶ代わりに、生成されたコードを読み、疑問を持ち、壊すことで学びます。機会は存在しますが、内部で何が起きているのかを理解しようとする意欲と、意図的な好奇心が必要です。

どのエンジニアリング分野にもエンジニアリング設計プロセスが存在し、4つの異なる段階に分けられます（多くの著者が異なる見解を持っていますが、伝えたい内容に最も適していると考えました）。

• 問題の定義
• 概念設計
• 詳細設計
• 学習と一般化

AIは4つの段階（調査、計画、構築、分析）すべてに参加しますが、どれも「所有」していません。各段階でエンジニアが引き続きしていることを見てみましょう。

問題の定義：トピックについて調査し、製品の要件を書き出します。この時点ではまだ人間の思考が多く介在しています。解決したいニーズを理解しているため、何を構築するかを決定します。

概念設計：製品はどのように問題を解決するのでしょうか。エージェントとブレインストーミングできますが、解決策が先に定義した問題にどのように役立つかを「理解」しているのは人間です。

詳細設計：少なくともこの文脈では、プロセスの負担の多くが取り除かれ、エージェントやLLMに委ねられる可能性が最も高い段階です。製品を構築し、レビューし、自信を持てる解決策が得られるまでLLMと反復作業できます。

学習と一般化：プログラムの分析と保守が多く関わってくる段階です。問題と解決策の理解に加えて、お気に入りのAIからのサポートが必要です。

つまり、今日ではソフトウェアエンジニアはタイピングするよりも、読み、評価し、決定することが多くなっています。このスピードにより、判断力がより重要になります。

AIの信頼性が崩れる領域:セキュリティ

アーキテクチャの決定、パフォーマンスのトレードオフ、データモデリング、アクセシビリティなど、ソフトウェアエンジニアリングプロセスのどの段階にも当てはまります。しかし、セキュリティは結果が最も顕著に表れる領域であるため、例として取り上げます。

セキュリティについて考えるとき、エンジニアの判断力は大きな役割を果たします。AIが生成したコードはリンターやテストを通過しますが、依然として微妙な脆弱性を含んでいる可能性があります。入力検証のギャップや競合状態などは、認識して理解し、コードでカバーされていることを確認する必要があります。セキュリティバグは振る舞いのレベルでは見えないためです。コードは機能しますが、安全ではありません。セキュリティが重要な経路でのバイブコーディング（AIが生成したコードをレビューせずに出荷すること）はより複雑です。AIは人間と同じ脅威認識を持っておらず、通常、攻撃対象領域はハッピーパスには存在しないためです。

監査役としてのエンジニア

最初の議論に戻ります。エンジニアの新しい役割は何でしょうか。実装から監査への移行が起きています。現実として、実装を学んだことがなければ、監査は実装よりも困難であり、間違えた場合の代償は小さくありません。

セキュリティの文脈では、生成されたコードから脆弱性を発見する前に、脆弱性がどのようなものかを知る必要があります。OWASP's Top 10 for Agentic Applicationsはエージェントを構築するエンジニア向けに書かれており、必ずしもエージェントを使用するエンジニア向けではありません。しかし、コーディングエージェントを日常的に使用している場合、エージェントがどのように失敗するかを理解することで、コードのどこを間違える可能性があるかを理解するのに役立ちます。

• 予期しないコード実行：エージェントはレビューしていないコードを生成して実行したり、要求していないパッケージをインストールしたり、必要のないシェルコマンドを実行したりする可能性があります。
• ツールの誤用：エージェントは与えられた権限の範囲内で動作しますが、賢明に使用するとは限りません。信頼できない出力をシェルに渡したり、読み取り専用で十分な場所に書き込みアクセスを使用したりする可能性があります。人間のように自身のスコープに疑問を持つことはありません。
• 不適切な出力処理：有効なコードに見えるAIの出力でも、サニタイズされていない入力、ハードコードされたシークレット、またはハッピーパスでは機能するものの敵対的な条件下では壊れるロジックが含まれている可能性があります。

エンジニアは本番環境でコードを実行する前の最後の防衛線です。そのため、監査役として次のような具体的な質問を自問する必要があります。

• ツールに書き込みアクセスは必要か？
• 入力はシェルに到達する前に検証されているか？
• なぜパッケージが取り込まれているのか？
• プロンプトが操作された場合でも安全か（AIアプリケーションを構築する場合）？

成功するエンジニアは、どのAI出力を信頼し、どれを疑うべきかを知っています。疑わしい場合はゼロトラストポリシーを適用します。つまり、決して信頼せず、常に検証します。

エンジニアに残された道

エンジニアの役割はコードの記述者からコードの監査役へと移行しています。今日、エンジニアの仕事はより大きな結果をもたらす決定に焦点を当てます。以前はスタックの選択が構築にかかる時間を決定するため、大きな議論の的でした。エージェントが何でもスキャフォールディングできるようになった現在、プレッシャーはなくなりました。しかし、別の理由で決定は依然として重要です。エージェントが書いたものを監査できるほど、スタックを十分に理解する必要があります。コーディング部分は速くなりましたが、エンジニアリングが簡単になったわけではありません。価値は、間違っている理由を理解したために出荷しないコードにあります。コードを書くことしか学んでこなかった場合、ツールと競合することになります。

AIの判断力は向上しており、最終的にギャップも埋まると主張する人もいるでしょう。そうかもしれません。しかし現時点では、モデルはシステム、ユーザー、または脅威モデルを知りません。知っているのは人間です。システムをエンジニアリングすることを学んだのであれば、ツールが何を構築するかを決定するのは人間です。