コードは書ける、でも"AIを理解してない"エンジニアが増えている現実😭
前置き
AI系プロジェクトのプロジェクトリーダーを数年間担当して私が最近感じていることを書きます。
今回はAIアプリエンジニアに限った話をします。
もちろん特定のテック企業やIT系企業、SIerでは当てはまらないと思いますが、おそらく事業会社では多くのパターンで共通する課題ではないかと感じています。
ここで言う「AIアプリエンジニア」とは、生成AI(LLM)を活用した社内アプリやプロトタイプを開発するエンジニアを指しています。
現状の課題感
「AIアプリエンジニアが急増しているが…」
AIアプリエンジニアという肩書きを持つ人は確実に増えています。
これは生成AI、いわゆるLLMが普及し、誰でも比較的容易に活用できるようになったことが大きな要因でしょう。
しかし実際のところ、AIそのものへの理解や理論的な知識を持たずに開発しているケースも少なくありません。
「OpenAI APIを使える」「LangChainを組める」といった“ツールとしてのスキル”はあっても、AIの挙動や構造を理解したうえで設計している人は限られています。
「コードは書けるのに、結果が出ないケースをよく見る」
最近はノーコード/バイブコーディングツールの普及によって、誰でも短期間でMVP(最小実行可能プロダクト)を作れるようになりました。
しかし現場レベルで実際に運用・定着するプロダクトになるケースは非常に少ないように感じます。
一見“動く”ものを作ることはできても、“使える”・“価値を生む”レベルまで育てるのが難しい。
また、社外にPRされているAI事例の中にも、実際には一部組織内だけの限定的活用にとどまっているものも少なくないようです。
問題提起:何が起きているのか
ノーコード/サンプルコードの充実によって、AIアプリを短期間で作ること自体は簡単になりました。バイブコーディングという神ツールも爆誕しました。

従来時間のかかっていたコーディング時間は半減し、確実にMVPを作るまでは早くなりました。
ただし、“動く”状態から“使える”状態に引き上げるには、きめ細かなチューニングと、AIの仕組みへの理解が不可欠です。
このチューニングには、モデル構造やプロンプト設計、データセット設計の知識が求められます。
しかし、AIをブラックボックスとして扱っていると、どこを調整すればよいか判断できません。
結果として、APIを呼び出すだけの構成にとどまり、課題を根本的に解決できないまま止まってしまうことが多いのです。
私の周囲でも、「ベクトルDBをとりあえず繋いでいる」「プロンプトを変えてみるだけ」といった状態で止まっている例をよく見かけます。特にプロンプトを変えてみるだけはすごく多いパターンです。RAGであれば、そもそも構造的にプロンプトチューニングの限界があるから、仕組み的にリトリーバーの改善を。。リトリーバーを変えたっということはベクトルDBのメタデータを。。といったような思考プロセスを持ち合わせる人が少ない印象です。
つまり、技術的に"リーチングアウト"できるエンジニアは、非常に少数です。
考察:なぜそうなるのか
LLMのような生成AIに“何でも神頼み”
生成AIの進化によって、「LLMに任せればなんでもできる」「マルチモーダル=すごい」という空気感が広がりました。
しかし、現場業務のような特定のタスクに特化したアプリケーションを作るほど、実は汎用的なLLMだけでは十分に対応できることってかなり少ないです。
モデルの限界や誤答特性を理解し、適切な技術や設計を組み合わせていく地道な調整が必要です。
成果物重視・SaaS依存構成による「原理」の理解の欠落
事業会社ではスピードが求められるたり、予算に限りがあったり。。、SaaSや既存APIを組み合わせて素早く成果物を出す傾向があります。
ただし、それが積み重なると、バックエンドではAPIを叩いているだけになり、AIそのものへの理解を深める機会が減ってしまいます。もちろんSaaSの真価が早いので追いつけないとかもあります。
成果物を優先する判断は正しい場面も多いのですが、理解の機会を意識的に確保することが必要です。
評価基準が曖昧になり、“すごいっぽいデモ”で終わる
「デモは盛り上がったけど、実務では使われない」というパターンも非常に多いです。
原因は明確で、定量的な評価指標やデータセット設計の知見が不足しているからです。
AIアプリを改善するには「なぜこの出力が良いのか/悪いのか」を測れる指標が欠かせません。
評価手法を持つことは、エンジニアとしてだけでなくプロジェクトの信頼性を担保するビジネススキルにも直結していると思います。なぜなら相手を説得しやすいのは数値ですから。。
提案:本当に有用なAIアプリを作るために必要な理解
-
基礎的な基礎
例えばLLMの出力は確率的であり、設定や入力次第で大きく変化しますとか。RAGであればキーワード検索はBM25の頻度計算をベースに...のような理解が必要です。ベースの技術を理解できていればうまく行かない時のチューニングの方針や次のアクションを早く決めることができます。もちろんアジャイル開発であれば、次のスプリントのバックログを事前に計画できるので、プロジェクトとして計画的に進めることもできます。 -
評価軸(正確さ・再現性・効率性など)を明確にする
“すごい”ではなく“安定して成果が出る”状態を目指すために、評価指標を定義し、可視化すること(=見える化)が重要です。 -
小さく検証 → 定量化 → 改善、というループを設計する
大きなアプリを一気に作るのではなく、検証サイクルを短く回す。この地道なプロセスが、結果的に品質を押し上げます。そう言った進め方をクライアントもしくは現場と綿密に擦り合わせることも大事です。
まとめ:AI時代のエンジニアに求められる姿勢
AIアプリエンジニアが数多く登場し、社内外でAI活用が広がる中で、いまようやく「本当の課題はクオリティ」だと気づき始めているのではないでしょうか。
AIに対する理解を深め、“使える”レベルまで磨き上げる姿勢が、これからのエンジニアには求められます。
「AIを使える人」は増えました。
でも、「AIを理解して活かせる人」こそがこれからの時代に強いのだと思います。
もちろん、私自身もまだ学びの途中です。
仕組みを理解しながら、より現場で本当に役立つAIを作っていけるよう、これからも探求していきたいと思います。
最後に
この記事は、特定の人や組織を批判するものではありません。むしろ、AI開発が広がる中で多くの人が抱える共通の課題を整理し、次のステップを考えるきっかけになればと思っています!
Discussion