はじめに
「AIがコードを書く時代になり、エンジニアは不要になるのではないか？」
技術系ニュースやSNSで、このような言葉をよく目にするようになりました。GitHub CopilotやClaude、ChatGPTなどを日常的に使い、コードやスクリプトを生成させている方も多いと思います。
筆者は入社2年目でAIプロダクトの開発チームに所属していて、日常的にAIを使っています。その立場から考えると、エンジニアが不要になることはなく、求められる役割が変わっていくのだと思っています。
本記事では、AI時代にどんな作業の価値が下がり、どんなスキルの価値が上がるのかを、「コンテキスト（文脈）」と「ガードレール（安全装置）」というキーワードを中心に整理します。
1. 価値が下がるのは「作業」、上がるのは「思考と接続」
AIの普及で起きているのは、エンジニアがいらなくなることではなく、役割が変わることです。
価値が下がること
- 構文やAPI、コマンドのオプションを暗記していること
- 指示された仕様どおりに、コードや設定ファイルをゼロから書く作業
価値が上がること
-
問題定義力（「問い」を立てる力）
指示どおりに作るのではなく、そもそも何が本当の課題なのかを見つける力。AIは与えられたタスクを解くのは得意ですが、課題そのものを決めることはできません。 -
コンテキスト（文脈）を言語化する力
自社や自分たちのプロジェクト固有のルール、制約、過去の経緯を整理して、AIが理解できる形にする力。 -
ガードレール設計と品質判断力
AIが出力したコードの危険性やハルシネーションに気づき、本番環境を守る仕組みを整える力。 -
ビジネスと技術をつなぐ力
非エンジニアや事業側の要望を理解したうえで、技術的なトレードオフを説明し、合意を取る力。
AIは、コードを書くのがとても速い一方で、自分たちのルールや背景を知らない新人エンジニアのようなものだと考えると分かりやすいです。
コードを書く作業が中心の役割から、問題を見つけ、AIに必要な文脈を渡し、出てきたものを評価して、ビジネスにつなげる役割へ。この移り変わりにどう対応するかが、これからの分かれ目になると思います。
2. ボトルネックは「コンテキストの不足」
「AIにコードを書かせても、結局そのままでは使えない」という経験はありませんか？
これはAIの性能が足りないというより、コンテキストが足りていないことが原因の場合が多いです。
なぜAIは「そのままでは使えないコード」を出すのか
LLMは、Web上の公開情報（一般的な書き方や教科書的な構成）は知っていますが、現場固有の情報は知りません。
- 使っているフレームワークやライブラリのバージョン、既存の設計方針
- 命名規則やコーディング規約
- 過去の障害から生まれたルールや、セキュリティポリシー
- 暗黙の了解になっている運用や慣習
「コンテキストエンジニアリング」という考え方
たとえば「ユーザー登録APIを書いて」とだけ頼むと、AIは一般的な実装を返します。それは動くかもしれませんが、自分たちのプロジェクトの規約には合っていないことがあります。
プロジェクトのルールや制約を、AIが読み取れる形（ドキュメントやプロンプト）で渡すことが、これからのエンジニアに求められる力です。
あまり良くない指示：
ユーザー登録APIを書いて
文脈を渡した指示：
プロジェクトの設計方針（docs/design.md）に従って、ユーザー登録APIを実装して。
・使用フレームワークはFastAPI、Pythonは3.12
・エラーレスポンスは社内共通の形式（docs/error.md）に合わせる
・パスワードはハッシュ化して保存し、ログには出さない
・単体テストも pytest で一緒に書く
暗黙知を言語化して、AIに正しく文脈を渡せると、やり直しが減って生産性が大きく変わります。
3. 「静かに壊れる」コードとガードレール
AIを使うときに一番厄介なのは、構文エラーではありません。エラーが出れば気づいて直せるからです。
問題になるのは、エラーなく動くのに、意図と違う挙動をする「静かに壊れる」コードです。
静かに壊れる例
- 存在しないオプションや引数を指定していたのに、無視されてデフォルトの動作になっていた
- 例外を握りつぶしていて、失敗してもエラーにならない
- デフォルト設定が緩く、意図せず公開範囲が広がっていた
- 境界値や空のデータを想定しておらず、特定の入力でだけ誤った結果が出る
- 削除や上書きに関するフラグが、意図せず有効になっていた
2つのガードレール
静かに壊れるコードから本番環境を守るには、2種類のガードレールが必要です。
[ AIのコード生成 ]
↓
【ガードレール1：仕組みによる自動検証】
・テスト（単体・結合）
・リンターや静的解析、セキュリティスキャン
・CI/CDでの自動チェック、破壊的変更のブロック
・AI生成コードを試すための隔離環境
↓
【ガードレール2：人によるコードレビュー】
・基礎知識に基づいて「なぜ動くのか」を確認する
↓
[ 本番環境へデプロイ ]
仕組みのガードレール
AIが想定外のコードを出しても、テストやCI/CD、最小権限の設定によって、本番が壊れない仕組みを用意しておくこと。
人のガードレール
一見動いているコードについて、裏で何が起きているのかを基礎から理解して確認し、ハルシネーションに気づくこと。
4. コードが増えるほど、検証と運用の仕事が増える
AIのおかげで、コードを書くスピードは大きく上がりました。その分、世の中に存在するコードやシステムの量も増えていきます。
コードが増えると、次のような問題も増えます。
- 構成が複雑になり、保守やコストの負担が増える
- セキュリティ上の問題や、権限設定の不備が増える
- 実行基盤への負荷や、障害のリスクが増える
こうした部分を見て、安全で安定した仕組みを作れるエンジニアの重要度は、これから上がっていくと思います。
構文を調べたり、定型的なコードを手で書いたりする時間はAIで減りました。その時間を、可用性やコスト、セキュリティ、設計といった、もう一段上のレイヤーの検討に使えるようになっています。
まとめ：明日からできること
-
定型作業はAIに任せる
コードの初期案、テストの雛形、ログの解析、データ形式の変換などは、AIに任せて作業時間を減らす。 -
空いた時間で、基礎と問題定義を学ぶ
「なぜこの設定やこの実装が必要なのか」「裏でどう動いているのか」を理解して、現場の課題を見つける力を養う。 -
ルールや設計の考え方を文章にしておく
AIに渡せる文脈を整えておくことが、チーム全体の生産性を上げる土台になる。
AIは仕事を奪うものではなく、面倒な作業を引き受けてくれる道具です。うまく使いこなしながら、設計や問題解決など、人が考えるべき部分に時間を使っていければと思います。