AIの世界で最も影響力のある人物の一人、アンドリュー・ン氏（DeepLearning.AIの創設者）が「AIアプリを作って動かすうえで本当に必要なスキル」について自身の見解を公開しました。技術者向けに書かれた内容ではありますが、その中身を紐解くと、エンジニア以外の会社員にも直結するヒントが随所に含まれています。この記事では、その提言の核心を整理しながら、30〜40代の会社員がどう受け取ればよいかを具体的な仕事の場面と合わせて考えます。
アンドリュー・ン氏が言う「最重要スキル」の正体
アンドリュー・ン氏が挙げるスキルリストで特徴的なのは、「プログラミングさえできればいい」という発想を明確に否定している点です。AIアプリを動かすうえで求められるのは、コードを書く技術だけでなく、「何を作るかを判断する力」「動いている状態を評価する力」「現場にフィットさせる力」の三つが組み合わさって初めて機能すると述べています。
これは、ソフトウェア開発の世界でよく言われる「動けばいい」という基準がAIの領域では通用しないという話でもあります。AIアプリは、同じ入力に対して毎回同じ出力が出るわけではありません。回答の品質が確率的に変動するため、「期待通りに動いているかどうか」を継続的に確認するための評価の仕組みが不可欠になります。つまり、作ること以上に、「正しく動き続けているかを見届けること」がスキルとして問われるわけです。
この視点は、エンジニアではない会社員にとっても他人事ではありません。自社で導入したAIツールが「思ったより使えない」「最初はよかったのに段々おかしくなった」と感じるケースの多くは、評価の仕組みを持たないまま運用を始めたことに原因があります。
エンジニアでなくても関係する「評価」の考え方
AIアプリ開発の文脈で「評価（Evaluation）」と呼ばれるプロセスは、要するに「AIが正しい答えを返しているかどうかを測る仕組みを作ること」です。エンジニアならコードでテストを書きますが、同じ発想は業務の現場でも応用できます。
例えば、カスタマーサポートにAIチャットを導入した会社の場合を考えてみましょう。30代のCS部門リーダーがこの評価の考え方を持っていたとすると、「1週間ごとに回答のサンプルを抜き取って担当者がチェックする」「誤回答のパターンを記録してカテゴリ別に集計する」「問い合わせ解決率の変化を週次で追う」といった運用設計が自然に出てきます。これはコードを書く仕事ではなく、業務フローを設計する仕事です。ここにAIスキルが絡んでいるとすれば、「AIの出力は信頼できるが検証なしに使うのは危険」という感覚を持っていることそのものが、すでにスキルの一部です。
アンドリュー・ン氏の提言を読むと、こうした「AIの限界を理解したうえで運用設計を考える力」は、技術者よりもむしろ現場の業務担当者に近い領域の話として捉えられます。プロンプトエンジニアリングの基礎でも触れているように、AIへの指示の出し方を工夫するだけで出力の品質は大きく変わります。評価の仕組みを持つことは、その品質変化を「気づかずに放置する」か「すぐに検知して対処できる」かの分岐点になります。
「プロンプト設計」はスキルの出発点に過ぎない
AIに慣れ始めた会社員がまず手を付けるのは、プロンプト（AIへの指示文）の改善です。この段階は確かに重要ですが、アンドリュー・ン氏の提言では、それはあくまで入り口に過ぎないと位置づけられています。
プロンプトを改善すると出力が良くなる。しかし、「なぜ良くなったのか」を言語化できないと、次に別の問題が起きたときに対処できません。ここで求められるのが、AIの出力に対する「なぜ」を問う習慣です。出力が変わった原因がプロンプトの変更なのか、使用するモデルの違いなのか、入力データの質なのかを切り分けられるようになると、再現性のある改善が積み上がっていきます。
これは40代のマーケティングマネージャーが広告コピーの生成にAIを使う場面に置き換えても同じです。「このプロンプトで良いコピーが出た」で終わるのではなく、「どのプロンプトのどの要素が効いたのかを記録しておく」ことが、チームで再利用できる資産になります。感覚的な試行錯誤から、記録と検証に基づいた運用へ移行すること——それ自体がアンドリュー・ン氏の言う「デプロイのスキル」の一部です。
実際に求められるスキルを整理すると
以下は、アンドリュー・ン氏の提言と、それを会社員の業務に当てはめたときの対応関係をまとめたものです。エンジニア向けの表現をそのまま受け取るのではなく、自分の仕事に引き寄せた読み替えが重要です。
| アンドリュー・ン氏が挙げるスキル | 会社員が現場で実践できる対応 |
|---|---|
| プロンプト設計と反復改善 | 指示文のテンプレートを作り、バージョン管理する |
| 評価（Evaluation）の設計 | 出力サンプルを定期チェックする運用フローを作る |
| RAGやファインチューニングの理解 | 「なぜAIが社内情報を知らないのか」を説明できる |
| モデル選定の判断基準 | 用途ごとにどのツールを使うか基準を決めておく |
| 本番運用での継続的モニタリング | 週次・月次でAIツールの成果指標を見直す |
RAG（Retrieval-Augmented Generation）は「外部の情報をAIに参照させて回答精度を上げる技術」のことです。ファインチューニングは「特定の用途に特化させるためにAIを追加学習させること」を指します。これらの詳細な実装はエンジニアの仕事ですが、「そういう方法がある」「それを使えばできることとできないことが変わる」という認識を持っておくだけで、社内のAI導入プロジェクトへの関わり方が変わります。
「作れる人」より「動かせる人」が希少になる
AIを使ったアプリやツールを試作するコストは、この2〜3年で劇的に下がりました。プログラミングの知識が薄くても、AIを活用してプロトタイプを作ること自体は以前より難しくなくなっています。AIを使った副業や新しい働き方を模索している人が増えているのも、その流れと無関係ではありません。
しかしアンドリュー・ン氏が強調するのは、「作ること」よりも「動かし続けること」のほうが難しく、かつそこにスキルの希少価値があるという点です。試作は誰でもできるようになった。でも、それを実際の業務フローに組み込み、品質を維持しながら運用し、問題が起きたときに原因を特定して直す——この一連の流れを担える人はまだ少ない。
これは日本企業でも同様の状況が起きています。ChatGPTのアカウントを取得した社員は増えたが、それを業務の中でどう定着させるかを設計できる人材は限られています。「AIを触れる人」と「AIを動かし続けられる人」の間には、評価・改善・運用設計という大きな差があります。その差を埋める経験こそが、今後のキャリアで差別化につながる部分です。
まとめ
アンドリュー・ン氏の提言が示すのは、AIスキルの重心が「作れるかどうか」から「動かし続けられるかどうか」に移っているという構造的な変化です。エンジニアでない30〜40代の会社員にとって、これは「自分はコードが書けないからAIは関係ない」という考えを手放すきっかけになります。評価の仕組みを持つこと、プロンプトの改善を記録に残すこと、ツールの成果を定期的に見直すこと——これらはすべて、コードなしに始められる「AIを動かす仕事」です。あなたの職場で、「誰も見ていないまま動いているAIツール」はどこにありますか。
