AIでコードを書く速度が上がった後にエンジニアは何を設計するのか

Claude CodeやCodexを使っていると、コードを書く速度はかなり上がります。新しいコンポーネントを作る、テストを追加する、既存コードを読んで修正方針を出す。以前なら数十分かけていた作業が、数分で叩き台まで進む場面は珍しくありません。

ただ、使えば使うほど、少し違う問題が見えてきました。コードを書く速度が上がっても、何を作るべきか、どこまで作るべきか、誰が確認するべきか、作った後にどう運用するかは自動では決まりません。むしろ実装が速くなるほど、曖昧な判断がそのまま形になり、後から手戻りとして返ってきます。

正直、最初は「AIに任せられる工程を増やせば、開発全体が速くなる」と考えていました。しかし実際には、AIに任せるほど、人間側で設計すべき対象が増えます。エンジニアの仕事はコードを書くことから消えるのではなく、AIが迷わず動ける状態を設計する方向へ広がっていく、という感覚に近いです。

速くなったのは実装の手前までではない

AI駆動開発で分かりやすく変わるのは、実装速度です。

たとえば、要件を渡して画面を作る、既存の型定義に合わせてAPIクライアントを直す、エラー内容を読ませて修正案を出させる、といった作業はAIと相性がよいです。入力と出力の関係が比較的明確で、既存コードやエラーログという具体的な材料もあります。

一方で、AIが速くしているのはコードを書く工程だけではありません。Jiraの説明から設計メモを作る、設計メモから実装タスクを分解する、差分からレビュー観点を抽出する、テスト観点の漏れを洗い出す。こうした「情報を別の形へ変換する工程」も、かなりAIに寄せられます。

ここまでは便利です。問題は、その変換の前提が曖昧なままだと、AIは曖昧さを抱えたまま出力を作ることです。AIは足りない情報を推測で補ってくれますが、その推測が業務上正しいとは限りません。

何を作るかは速くならない

AIにとって扱いやすいのは、入力と出力の対応が見えている作業です。

既存の実装パターンに合わせてコードを書く。エラーから原因候補を出す。仕様書をチェックリストに変換する。こうした作業は、文脈を十分に渡せばかなり安定します。

しかし、何を作るべきかを決める作業は別です。

どの顧客課題を優先するのか。この機能を入れることで、運用担当者の負担は増えないのか。今のリリースで入れるべきか、次のフェーズに回すべきか。失敗したときに誰が気づき、誰が戻せるのか。こうした判断には、コードベースだけではなく、事業上の優先度、現場の制約、運用体制、利用者の期待値が関わります。

AIは論点を整理できます。選択肢も出せます。過去のパターンに基づいてリスクを列挙することもできます。ただし、最終的にどの制約を重く見るかは、人間側が決める必要があります。

この線引きを曖昧にしたままAIへ任せると、「動くもの」は速くできます。しかし、その動くものが本当に課題を解いているかは別問題です。

エンジニアが設計する対象はコードから文脈へ広がる

AIでコードが速く書けるようになると、エンジニアが設計する対象はコードそのものから、コードの外側に広がります。

具体的には、次のようなものです。

• どの課題を解くのか
• どの制約を守るのか
• どこまでをAIに任せるのか
• どの出力を合格とみなすのか
• 失敗したときに何を見て切り分けるのか
• 作った後に誰が運用するのか

これらは、従来から重要だった要素です。ただ、実装速度が上がる前は、実装作業そのものに時間がかかるため、曖昧さが途中で露出することも多くありました。実装者が手を動かす過程で、「この仕様だと運用できないのでは」「この分岐は誰が確認するのか」と気づく余地がありました。

AIを使うと、この気づきの前にコードが出てきます。便利である一方、設計の不足が実装スピードに隠れやすくなります。

だからこそ、エンジニアはAIに依頼する前に、課題、制約、検証観点を言語化する必要があります。これは単なるプロンプト作成ではありません。AIが作業できる形に、開発の文脈を再設計する作業です。

AIに任せやすい工程と人間が判断すべき工程

個人的には、AIに任せる工程を次の3つで考えると整理しやすいです。

1つ目は、同じ粒度の変換です。Jiraの内容を設計メモにする、設計メモをタスク一覧にする、差分をレビュー観点にする、といった作業です。入力と出力の対応関係が比較的明確であれば、AIに任せやすい領域です。

2つ目は、具体から抽象への整理です。エラーログから原因候補を出す、複数のレビューコメントから共通する問題を抜き出す、失敗した出力から評価観点を作る、といった作業です。人間が見落としやすいパターンを拾う補助として使えます。

3つ目は、抽象から具体への展開です。新しい施策を決める、要求から仕様を確定する、優先順位を決める、といった作業です。ここでもAIは壁打ち相手として有効ですが、判断まで丸ごと渡すのは危険です。入力にない業務制約や組織事情を、AIが正しく知っているとは限らないからです。

この分類を持っておくと、「AIに任せるかどうか」ではなく、「どの部分をAIに変換させ、どの部分を人間が判断するか」を考えやすくなります。

良い依頼は詳しい依頼ではなく検証できる依頼である

AIへの依頼を書くとき、つい詳しく書けばよいと考えがちです。もちろん具体性は重要です。ただ、詳細な依頼でも、成功条件が曖昧なら出力の良し悪しを判断できません。

たとえば「使いやすい管理画面を作ってください」では、AIはそれらしいUIを作れます。しかし、何をもって使いやすいと判断するのかは分かりません。検索条件が保存できることなのか、一覧で異常値に気づけることなのか、非エンジニアが迷わず操作できることなのかで、設計は変わります。

AIに渡すべきなのは、作ってほしいものだけではなく、確認可能な条件です。

目的:
  問い合わせ対応担当者が、過去の対応履歴を見ながら次の返信案を確認できるようにする。

制約:
  個人情報を画面上で不要に露出しない。
  返信案は自動送信せず、必ず人間が確認する。

合格条件:
  担当者が未対応、対応中、完了を一覧で判別できる。
  AI返信案には根拠となる履歴への参照が付いている。
  送信前に人間の確認ステップが必ず入る。

このような入力にすると、AIは単に画面を作るだけでなく、どの制約を守るべきか、どこに人間の判断を残すべきかを踏まえて作業できます。

AIが速いほどレビューは重要になる

AIで実装が速くなると、レビューも軽くしてよいように見えます。しかし実際には逆です。速く作れるからこそ、レビューではコードの細部だけでなく、前提の妥当性を見る必要があります。

AI生成コードのレビューで見たいのは、単にバグがあるかどうかだけではありません。

• そもそも要求を取り違えていないか
• 入力にない仕様を勝手に補っていないか
• 失敗時の挙動が設計されているか
• 運用担当者が確認できるログが残るか
• 将来変更しやすい境界になっているか

この観点は、LLMOpsにも近いです。LLMアプリケーションでは、出力がそれらしく見えても、根拠、評価、トレース、コスト、失敗時の復旧が見えなければ運用できません。AI駆動開発も同じで、コードが動くことと、開発プロセスとして信頼できることは別です。

まとめ

AIでコードを書く速度が上がるほど、エンジニアの価値は「速く書くこと」から「何を、どの条件で、どう検証できる形にするか」へ移っていきます。

これは、コードを書く仕事が消えるという話ではありません。むしろ、AIがコードを書けるようになったことで、コードの外側にあった課題、制約、運用、評価をきちんと設計する重要性が上がっています。

個人的には、AI駆動開発の本質は、エンジニアをコード生成機から解放することではなく、課題解決の前提をより明確にすることだと考えています。AIに任せられる工程は増えます。ただし、何を成功とみなすのか、どのリスクを許容しないのか、誰が運用するのかは、人間が設計し続ける必要があります。

コードを書く速度が上がった後に残る仕事は、思ったより地味です。しかし、その地味な設計こそが、AI時代の開発品質を左右します。