コードは書けても、「何を作るか」の判断はAIに丸投げできない ―― 現場でAIを使って見えてきた、エンジニアの仕事の変化

2026.08.25

「AIならコードは書ける」という現実

生成AIの進化によって、コードを書くという行為そのものが大きく変わりつつあります。
設計書を渡せばコードの叩き台が出てくる、エラーメッセージを貼り付ければ原因と修正案が返ってくる
――こうした体験は、もはや特別なものではなく「日常」になりました。

中でも最近よく耳にするのが「バイブコーディング」という言葉です。
細かい設計書や仕様書を用意しなくても、「こういうものが欲しい」という一言をAIに伝えるだけで、動くコードのたたき台が返ってくる――そんな開発スタイルを指します。
ここまで来ると、率直に言って「コードを書く」という作業そのものは、もうAIに十分任せられるレベルに達していると感じます。

では、SE/PGはいらなくなるのか

だとすると、素朴な疑問が浮かびます。コードが書けるのがAIなら、SE/PGはもう要らなくなるのではないか、という問いです。
「コードを書くこと」がエンジニアの仕事の中心だと考えるなら、この疑問は決して的外れではありません。
実際、エンジニアとしての経験を積んできた身として、多少の危機感を持ちながらバイブコーディングを試してきました。

しかし、実際に使い込んでみると、少し違う景色が見えてきました。

実際に使うことで、見えてきたこと

たとえばKintoneのように、扱う機能やAPIの仕様がドキュメントとして明確に定義されている領域では、「こういう機能が欲しい」と伝えるだけで、驚くほど精度の高い実装がその場で返ってきます。
ここだけを見れば、たしかにコードを書く力はもうAIに代替できるように思えます。

ところが、要望をそのままAIに渡す場面に目を向けると、様子が変わってきます。ここで起きていることは、「AIがコードを書けない」という問題ではなく、もっと別のところにありました。

① ユーザーの要望をそのままAIに渡してしまうケース

ユーザーから「こういうことをしたい」と言われた内容を、そのままAIに投げると、表面的にはもっともらしい解決策が返ってきます。
しかしそれが本当にそのユーザーにとって適切かどうかは、また別の話です。

たとえば、

前提条件の提示漏れ
- 予算感や規模感
  本格的なシステム開発が必要な要望に対して、AIは技術的に可能な解決策を提示してくれますが、それが依頼者の予算内で実現できるかは考慮してくれません。
- セキュリティ・コンプライアンス
  個人情報保護や業界特有のルールといった法令・社内規定に関わる制約は、当然のように考慮される事項としてユーザーの言葉には出てこなかったり、伝達事項として漏れることがあります。
  AIはこうした制約を自発的に考慮してはくれないため、扱うデータの性質によっては、要望をそのまま実現すること自体がリスクになる場合もあります。
ヒアリングによって見えてくるユーザー事情
- ITスキル
  AIが提示する運用方法が、実際にその業務を回す担当者のITリテラシーに見合っているとは限りません。
  「使いこなせない仕組み」を作ってしまうリスクがあります。
- 本当に解決したいこと
  ユーザーの発言そのものが、必ずしも「本当の課題」を正確に言い当てているとは限りません。
  たとえば「〇〇の入力を自動化したい」という一言の裏には、「入力ミスを減らしたい」「確認作業に時間がかかりすぎるのを何とかしたい」「特定の人しかできない作業を誰でもできるようにしたい」など、いくつもの背景が隠れていることがあります。
  AIに要望をそのまま渡せば、言葉通りの仕組み（自動化そのもの）は作ってくれますが、その奥にある「なぜそれをしたいのか」までは汲み取ってくれません。
  ここを人間が一段掘り下げて言語化しないと、出来上がったものが「動くけれど、結局困りごとは解決していない」という結果になりかねません。

このような場面では、予算や制約といった前提条件、ユーザー抱える課題や本当の目的といった方針を人間側があらかじめ整理した上でAIに指示を出す、という一段階が欠かせません。

この一段階（AIが適切に考えられるだけのコンテキストへ変換するという仕事）は従来エンジニアが実施しているユーザーへの詳細なヒアリングによってシステム開発の方針、概要を決める、という仕事と同じです。

つまり、AIの登場によって作業が大きく変わった（なくった）わけではなく、何を前提としているのか、解決すべきことは何かという整理する仕事が人間側には残っていて、その仕事の重要性が大きくなっているといえます。

② 実装したい機能をそのままAIに聞いてしまうケース

仕様やAPIがはっきり定まった機能を、その作法の範囲内で使う分には、AIは非常に頼りになります。
ただし、機能の実現だけを目的にして伝えてしまうと、思わぬ形でその前提が崩れることがあります。

まず見落とされがちなのが、AIが参照している情報そのものが古い可能性があるという点です。
AIの学習データが古い場合、すでに非推奨・廃止予定になっているAPIやバージョンを、あたかも現役であるかのように提案してしまうことがあります。
仕様が明確な領域であっても、「AIが知っている情報」が「今の正しい情報」とは限らない、という前提は忘れてはいけません。

さらに、実現したい要望が標準機能の範囲を超えていたり、正攻法での実現が難しかったりする場合、AIは「とにかく動く形にする」ことを優先し、次のような形で応えてくることがあります。

裏技的な実装
正攻法での実現が難しい要望に対して、本来推奨されていない内部的な仕組みや力技のハードコーディングなどを使い、無理やり動く形に仕立ててしまうことがあります。
要望を詰め込みすぎた結果の複雑化
一つひとつの要望に律儀に応えようとするあまり、コードが冗長・複雑になり、結果的に人間側での整理（リファクタリング）が前提になってしまうことがあります。
セキュリティやエラー処理の考慮不足
正常に動くことを優先するあまり、権限チェックや入力値の検証、例外処理といった「地味だが重要な部分」が手薄になりがちです。

AIは「今、目の前の要望を動く形にする」ことには非常に長けていますが、「半年後・1年後も安全に保守・運用できるか」という視点までは、指示をしない限り考慮してくれません。
だからこそ、AIが出してきた実装案を鵜呑みにせず、常に人間がレビューし、必要であれば正攻法に近い形へ方針を変えるというプロセスを、開発フローの中に組み込んでおく必要があると感じています。

難しいのは「コードを書くこと」ではなく「何を作るべきかを判断すること」

①②を通して見えてきたのは、AIが苦手なのは、目の前の要望の背景を汲み取り、実装方針の妥当性を判断することだという点です。
これは、予算やITスキル、本当の目的、保守性や拡張性といった判断軸は、そもそもAIに渡す「入力」の外側にあるためです。

AIは与えられた情報の中では判断できますが、何を条件として与えるべきか、そもそも何を問題とするかは人間側で整理しなければなりません。

AIが「コードを書く」ことを担うようになるほど、エンジニアの仕事がなくなるわけではなく、その重心が「書く」ことから「整理し、判断する」ことへと移っていく――これが、実際に使ってみて得た実感です。

まとめ ―― 「入口の整理」と「出口のレビュー」に技術力が宿る

バイブコーディングは、パターンがある程度決まっている実装やたたき台の実装などでは非常に強みを感じる場面が多くあります。
一方で、アウトプットのイメージを持たないまま、ふわっとした要望や機能名だけをそのままAIに投げてしまうと、結果がどう転ぶか分からない状態になってしまいます。

これは、ある意味でインターフェース（I/F）設計に近い話だと感じています。
適切な入力情報を渡し、返ってきた出力情報をどう使うかを判断する
――このプロセスをきちんと設計できるかどうかが、AIをうまく使いこなせるかどうかを大きく左右します。

入力情報の整理
要望の背景（予算・スキル・本当の目的・法令面の制約）等の必要な情報の収集、整理を行いAIに渡す情報の質を上げる
出力情報のレビュー
AIが出してきたアウトプットを鵜呑みにせず、保守性・拡張性・セキュリティの観点でレビューし、意図通りかどうかを判断する

コードを「書く」作業がAIに置き換わっていくほど、逆説的に、この入力と出力を設計する力の比重は増していきます。

AIは間違いなく開発のスピードと可能性を広げてくれる強力な武器であり、今後も更なる発展が見込まれます。
現在のAIの能力でも必要な情報さえ渡せば、ある程度こなしてくれますが、この能力は今後さらに伸びていき、出力結果の品質も向上していくはずです。

だからこそAIという強力な武器から何を引き出し、どう使うかを決めるのは、これまでもこれからも人間の技術力なのだと思います。

この記事を書いた人について

平山和昭: オーシャン・アンド・パートナーズ株式会社　システムエンジニア

顧客をリードし、最適なシステムを構築、提供できる技術者を目指しています。
コラムでは若手技術者向けを中心に今までの経験を踏まえた実際の開発現場で役立つ情報を発信していきます。
プライベートでは家族の足（専属運転手）となり、今ではかねてからやりたかった日々の送り迎えが日課になっています。