コードは書ける、でも"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
今、まさにプログラムは出来ませんがAIとの対話で共深化をするという実験をしています。
AIから聞いて何となく内部で起こっていることは理解できましたが、それを証明する術がなく本職のプログラマーの協力者が必要と考えていた矢先にGoogleおすすめに出ていてコメントをさせていただきました。
アイシンさん
コメントありがとうございます。AIとの対話で共深化をする、興味深いです。
人⇔AIのインタラクションはチャットベースだけでなく、例えば車との対話、ロボットとの対話等様々なユースケースに展開できるような話だと感じています。
以上、コメントです。
現場で感じていた課題を、ここまで整理して言語化されているのが本当にすごいです。
「AIを使える」と「AIを理解して活かせる」はまったく別物。
動くものを作るのは早くなったけれど、“使える構造”にするには仕組みの理解が欠かせない。
共感と敬意しかありません。
僕のスコープはもっと狭くて恐縮ですが、構造化していくリテラシーがAI活用には欠かせないと考えています。
こん太ぱぱさん
コメントありがとうございます＆お褒めの言葉ありがとうございます。
実はこの記事では、私が本当に率直に思ったことを5,10分程度でそのまま書いただけです（笑）
ここまで共感されるとは思っていませんでした。
構造化の話、とっても重要ですよね。そして、とても悩ましいですよね。
私は２つくらいのアプローチがあると思っています。①従来ナレッジを構造化 or ②そもそものデータを正規化する、です。①も②もそれぞれメリットデメリットがあるので、なかなか決めきれません、、
返信ありがとうございます。
言語化が適切にできないと、正しい正解は導き出せない。
返ってくる答えはあくまで統計的平均であることを理解し、自分にとって適切か判断して調整すること。
日ごろそう感じていたので、本当に深く共感してしまいました😂
この記事を見て、歴史は繰り返すものだと思いました。
かつて、世にあふれたLinuxサーバー構築本のおかげ(せい)で、理屈を知らないまま手順だけ知ってる人が、仕事として非常に脆弱な構築のサーバーを乱立させて、そういった他社の仕事の後始末に奔走してた時期がありました。
また、古くはVB系や、あるいはPHPやRuby、Python等のスクリプト言語と様々なフレームワークのおかげで、動くプログラムを作ることの敷居はどんどん下がりましたが、適切に運用できるシステムを作れる人は、割合としては今でも多く無いと感じています。ログ出力？例外のハンドリング？デプロイ？なにそれおいしいの？みたいな人(達)と一緒に仕事するのはとても大変でした。
今また、AIにちゃんと仕事させるために、設計書の作成に四苦八苦していたところに、この記事を見てちょっと笑いました。
時代は変わっても、案外人の本質って変わらないものですねえ。
Dさん
コメントありがとうございます！
まさにおっしゃる通りで、“手順が普及すると理解が置いていかれる” という現象は、技術の歴史の中で何度も繰り返されていますよね。
それこそ、アセンブリ言語のような古典的な言語から始めた方が、いまのPythonのようなオブジェクト指向言語を見ると驚かれるのも頷けます。
一方で、記載のあるLinuxサーバーの細かい原理については、私自身はまったく詳しくなく（笑）、改めて今こそちゃんと理解しておくべきだなと感じます。AIエージェントも振り返り(reflect)は非常に大事ですが、人間も大事だなと。
やはり時代が変わっても、人は案外進化していないのかもしれませんね。
それでも、まずは“手順を覚え”、その後に“原理を理解する”意識を持つだけでも、仕事のクオリティはぐっと上がるのではないかと感じます。
とてもよく分かる実情だと思います。
ただ言えることは、これって今始まったことでは無いと感じました。
スマホが流通しマッシュアップという用語が流行り始めた頃から、中身がわらからないけど便利なものを活用し、組み合わせて作り上げる形の開発形態が増えたと感じています。
wordpressやjQueryを始めとする、フレームワークの中身を理解せず利用するエンジニアが多いですね。不具合が出たときにクライアントから質問されても、平気で「利用してるフレームワークの不具合なんで分かりません」って答えてしまう。
これってエンジニアと呼べるのか？疑問に感じる人材が最近多いと感じています。
コメントありがとうございます！
まさにおっしゃる通りで、中身を理解せずに便利なものを組み合わせる開発という流れは、実はAIに限らず過去から何度も繰り返されていますよね。
動くもの」簡単に作れるようになった一方で、なぜ動くのか、どこが問題なのか、を説明できる人は明らかに減ってると思います。
その背景には、オブジェクト指向言語をブラックボックスのまま扱うようになったことや、システム全体が昔よりもかなり複雑化してフルスクラッチ開発がほとんどなくなったことも大きいのかなと思います。
もはや全容を理解すること自体が難しいと言いますか。たとえば、大手の事業会社、やTier1 SIerは特に同じような状況なのかなと感じます。
ただ、そうした便利さの上で今の技術が発展してきたのも事実なので、「使うこと」と「理解すること」の両立をどう実現するかがこれからの課題だと感じています。
AIもまさにその延長線上にありますね。
便利だからこそ、ブラックボックスの中身を少しでも理解しようとする姿勢が、今後さらに大事になる気がします。特にAIの場合は、説明性や責任問題が大きくつきまとうので、説明できません、が許されなくなる時も来ると思います。(※もちろん私自身のレベルもまだまだなので精進せねばなのですが汗)