AI時代に生きる若手エンジニアが、AIを使う上で備えておくべき知識

はじめに

生成AIが当たり前になった今、「AIを使えること」はもはやアドバンテージではなくなりつつあります。

画像、動画、音声、文章、リサーチ、プログラミング——「なんでもできる」は言い過ぎにしても、自分の能力だけではできなかったことがAIのおかげでできるようになった場面は確実に増えました。ちょっと指示を出せば何かしら形になるし、雑な指示でも「おっ、すごい」と思える出力が返ってくることもあります。

一方で、
「期待どおりのものを、短時間で作れている」と胸を張って言える人はどれくらいいるのでしょうか？

イメージ通りにいかなくて、結局プロンプトを何十回も書き直す。出力を手作業で直しているうちに「自分でやった方が早かったのでは」と思い始める。
こんな経験、心当たりはありませんか？

同じAIなのに、出せる成果が違う

この「使いこなせている感のなさ」は、特に若手エンジニアに顕著だと感じています。

というのも、ベテランと若手では、同じAIを使っていても見えている世界がまるで違う からです。

ベテランは、長年の経験と知識をベースにAIへ具体的な指示を出せます。「このAPIの認証はOAuth2で、リフレッシュトークンの有効期限も考慮して」——こうした指示が自然に出てくるのは、何度もシステムを作ってきた引き出しがあるからです。期待値のコントロールが上手く、AIの出力を的確に軌道修正できます。

一方、若手はどうでしょうか。

• AIに開発を任せたいが、アプローチや考慮事項を具体的に伝えられず、使えない成果物が出てきてしまう
• 指示を出したいが、自分の中の期待値がぼんやりしていて「いい感じにして」としか言えない
• 表現が適切でなくて、意図したものとまったく違うアウトプットが返ってくる

従来であれば、こうした知識や経験は上司や先輩から段階的に受け継がれてきました。しかしAIの登場によって「まず自分でAIに聞いてみて」という場面が増え、その育成プロセスにかける時間は急速に短縮されつつあります。裏を返せば、知識の土台がないまま高度なツールだけ手渡されている 状態とも言えます。

この記事について

では、若手エンジニアが本当の意味でAIを使いこなし、成果を出すには何を意識すればいいのか？

AI過渡期に新卒でIT業界に入った筆者が、AIと格闘する日々の中で気づいたあれこれをまとめました。

1. AIの「得意」と「苦手」を知る

AIをうまく使うために最初に必要なのは、AIに何ができて、何ができないのかを正しく把握すること です。
もはや当たり前すぎて何を今さらと思うかもしれませんが、ここを誤解したまま使い続けると、思わぬところで時間を溶かすことになります。

エンジニアにとっての「得意」と「苦手」

「苦手」の多くは、使い方で克服できる

ここで一つ大事なことを補足しておきます。

上に挙げた「苦手」は、AIの絶対的な限界ではなく、素のまま使った場合の限界 です。実は、使い方を工夫すればかなりの部分は克服できます。

• 最新仕様の把握 → 公式ドキュメントをコンテキストに渡す、Web検索機能付きのAIを使う、MCPでドキュメントを参照させる
• プロジェクト全体の設計判断 → 関連ファイルやアーキテクチャ図を読み込ませる、コーディングエージェント(Claude Codeなど)に複数ファイルを横断的に見せる
• 動くコード vs 正しいコード → テストコードを一緒に書かせる、レビュー観点を指示に含める、「エッジケースも考慮して」と明示する
• ハルシネーション対策 → 「不明な場合は不明と答えて」と伝える、一次ソースとの突き合わせを指示する

つまり、「AIの苦手」と言われるものの多くは、AI単体の限界というより、使い手の工夫不足 だったりします。

よくある"ハマりどころ"

それでも若手エンジニアがやりがちな失敗を一つ紹介します。

新しめのライブラリの使い方をAIに聞いて、返ってきたコードをそのまま動かしたら、AttributeError: module 'xxx' has no attribute 'yyy' が出る——。実はそのメソッド、バージョンアップで名前が変わっていたり、そもそも存在しなかったりするパターンです。

これはAIが悪いというより、素の状態のAIに最新仕様を聞いてしまったこと、そしてその出力を検証せずに使ってしまったこと が原因です。同じ質問でも、公式ドキュメントを一緒に渡したり、Web検索を有効にしたりすれば、結果はまったく違ってきます。

「限界」と「工夫の余地」を見極める

得意・苦手のリストは、実際に使っているうちにもっと細かくアップデートされていきます。

大事なのは、苦手に見えることに出くわしたとき、「AIには無理だな」と諦めるのではなく、「これは使い方で何とかなる苦手か、それとも本当に任せるべきでない仕事か」を見極めること です。

道具の限界を知り、その限界を押し広げる工夫ができる人だけが、道具を最大限に活かせます。

2. 「作りたいモノ」を言葉にする力

当たり前ですが、AIはあなたの頭の中を読めません。
AIを使って何かモノを生成したい場合、「こういうものが欲しい」を言葉にできなければ、AIへの指示(プロンプト)は書けない のです。

突然ですがこの画像と同じ画像を1回の指示で作ることはできますか？実際に作ってみてください。

うまく生成できましたかね？
参考までにプロンプトの例を提示しておきます。

プロンプト例

赤いリンゴの水彩イラスト。

右奥に丸ごとのリンゴを1つ配置。
左手前に半分にカットされたリンゴを大きめに配置し、断面と種が見えるようにする。
さらに手前中央に、薄くスライスされたリンゴを1枚置く。

全体が三角構図になるように、互いに少し重なるよう自然でバランスよく配置。
余白を広めに取り、やさしく抜け感のある構図。

透明感のある水彩のにじみ、
柔らかい筆跡、
温かみのある赤・オレンジ・黄色の色合い。

背景は白ベースで、
淡い黄色とオレンジの水彩のにじみを薄く入れる。

絵本のような優しい雰囲気。
手描き感のあるナチュラルなタッチ。
リアルすぎず少し可愛いデフォルメ。
高品質な水彩画、paper texture、soft lighting

例えば、明確なイメージが定まっておらず、雰囲気で作り出した成果物をあとづけで評価するようなVibe Codingの場合は「いい感じの○○○作って」といったプロンプトで出来上がったものでも満足できるかもしれません。
しかし、業務でAIを活用となると大体は制限下でアウトプットの期待値が決まっていて、雰囲気で作っていると使い物にならなかったり、修正に時間がかかってAIを活用している恩恵を受けることができないので、事前に、期待する成果物を言葉で表現できるかどうかは重要です。

言語化力を高めるための3ステップ

① ゴールを明確にする
「何のために」「誰に向けて」「どんな結果が欲しいのか」をまず自分の中で整理する。

② 条件や制約を洗い出す
使う言語・フレームワーク、パフォーマンス要件、既存コードとの整合性、避けたいパターン——境界線をはっきり伝える。

③ 具体例を添える
「こんな感じ」というサンプルコードや既存実装の一部を示すだけで、アウトプットの精度は格段に上がる。

言語化の力は、AIに限らずエンジニアの仕事のあらゆる場面で武器になります。設計レビュー、PRの説明、障害報告、チームへの技術共有——すべて「伝える力」が土台です。

3. 隣の領域まで「広く浅く」知っておく

AI登場以前は、「自分の専門領域を深く掘ること」が評価されてきました。狭く深いT字型のタテ棒を、いかに長く伸ばすか——という世界です。

しかし、AIに作業を任せられる今、深さの一部はAIが肩代わりしてくれます。 代わりに価値を持ち始めたのが、「自分の専門の隣にある領域を、広く浅く知っていること」 です。

これは「同じ領域の深さ」ではなく、横方向に職種をまたいだ広がり の話です。

エンジニアにとっての「隣の領域」とは

たとえばバックエンドエンジニアにとっての隣の領域は、こんなところです。

• フロントエンド: コンポーネント設計、状態管理、UXの基本原則
• インフラ/SRE: CI/CD、コンテナ、監視、コスト構造
• デザイン: 情報設計、デザインシステム、アクセシビリティ
• プロダクト: ユーザーストーリー、KPI、ロードマップの優先順位
• セキュリティ: 認証認可の基礎、よくある脆弱性

これらをざっくり把握しているだけで、AIに頼める内容の幅が一気に広がります。

なぜ「広く浅く」で十分なのか

深い知識はAIが補ってくれるからです。あなたに必要なのは、「この領域には何があって、AIに何を頼めるか」を判断できる地図 だけ。

たとえば「ログイン機能を作りたい」と思ったとき、認証方式に何があるか(セッション認証、JWT、OAuth、パスキー……)を耳にしたことがあれば、AIに「OAuthのGoogle連携で、認可コードフローで実装して」と具体的に指示できます。一方、認証を「ログインするやつ」としか認識していなければ、「いい感じにログイン機能作って」しか言えません。

つまり、地図の広さがそのままAIに頼める仕事の広さになる のです。

地図の広げ方

特別な勉強法は必要ありません。日常の中で意識を少し変えるだけで、地図は自然に広がっていきます。

• 自分の仕事の前工程・後工程を意識する(誰から仕様をもらい、誰に渡しているか)
• 隣の職種の入門書を1冊だけ読む(深追いせず、目次レベルで頭に入れる)
• デザイナーやPMと雑談する機会を持つ(用語に触れるだけで地図は描ける)
• わからない単語を後回しにしない(その場で30秒だけググる癖をつける)

地図を持たずに旅に出れば、遠回りするか、迷子になるか、最悪たどり着けません。AIに指示を出せる範囲は、あなたが持っている地図の広さ に比例します。

4. 物事を「抽象的に」捉える力

セクション3が「横方向の広がり(隣接領域を知る)」だとすれば、こちらは「縦方向の抽象度(同じ領域の中で具体と抽象を行き来する)」の話です。

AI時代に求められるのは、技術の細かい構文を暗記することではありません。
「何ができるか」をざっくり知っていて、必要なときにその情報を引き出せること——つまり、物事を抽象的に捉える力です。

プログラミングで考えてみる

たとえばどの言語を学んでも最初に、for文の書き方やif文の細かい構文を覚えますよね。もちろん知っていて損はありませんが、AI時代において本当に大事なのはそこではありません。

重要なのは、こういう抽象的な理解です。

• 「条件付きで繰り返し処理」 ができる
• 「条件によって処理を分岐させる」 ことができる
• データを 「一時的に保存しておく」 仕組みがある(変数、キャッシュ、セッション……)
• 外部サービスと 「データをやり取りする」 方法がある(HTTP、gRPC、メッセージキュー……)
• 処理を 「あとで実行する」 仕組みがある(非同期、ジョブキュー、cron……)

この粒度で理解していれば、AIに対して「ユーザー一覧を取得して、年齢が20歳以上の人だけを抽出して、CSVに書き出すバッチ処理を作って」と指示できます。for文やif文の具体的な書き方を知らなくても、AIが具体的なコードに落とし込んでくれるのです。

「引き出しの多さ」が武器になる

抽象的な理解のメリットは、一つの知識が複数の場面で使い回せること です。

「繰り返し処理ができる」という知識は、Pythonでも、JavaScriptでも、Goでも、SQLのループでも、シェルスクリプトでも活きます。具体的な構文に縛られた知識は、その言語でしか使えません。

「非同期処理」という概念を抽象的に理解していれば、JavaScriptのasync/awaitでも、Pythonのasyncioでも、Goのgoroutineでも、「やりたいこと」をAIに伝えられます。

つまり、抽象度を上げて物事を捉えるほど、あなたの「引き出し」は増えていきます。引き出しが多い人ほど、目の前の課題に対して「あの仕組みが使えそうだ」「この方法と組み合わせればいけるかも」と発想できる。AIへの指示の幅と精度は、この引き出しの数で決まる と言っても過言ではありません。

AIを使って「抽象から具体に降りる」

抽象的に捉える力は、AIと組み合わせるとさらに強力になります。抽象的なキーワードさえ知っていれば、AIに聞きながらトップダウンで具体まで降りていける からです。

たとえば、「非同期処理ってどこかで聞いたな」というレベルの理解しかなくても、こんな掘り下げ方ができます。

1. 「非同期処理って何？同期処理と何が違うの？」(概念の理解)
2. 「JavaScriptで非同期処理を書くにはどんな方法がある？」(選択肢の把握)
3. 「async/awaitとPromise.thenはどう使い分ける？」(比較の理解)
4. 「実際にAPIを3つ並列で叩くコードを書いて」(具体への落とし込み)

ポイントは、最初に「非同期処理」というキーワードを引き出せること。このキーワードさえあれば、あとはAIが地図を埋めてくれます。逆に、キーワードを知らなければ「非同期処理について聞きたい」と尋ねること自体ができません。

これは隣の領域を学ぶときも同じです。「Kubernetesって聞いたことあるな」→「Kubernetesは何を解決するもの？」→「Podって何？」→「うちのプロジェクトに導入するメリットは？」と、抽象から具体へ階段を降りるように深掘りできます。

書籍を読むより速く、検索より文脈に沿った答えが得られる。「キーワードだけ知っていればAIが教えてくれる」という前提に立つと、学び方そのものが変わります。

横の広がりと縦の抽象度はセット

セクション3の「隣の領域」と、このセクションの「抽象度」は、両方そろってはじめて力を発揮します。

• 横(隣接領域)だけだと、知識が浅く広がるだけで、AIに具体的な指示ができない
• 縦(抽象度)だけだと、自分の専門領域は深く理解できても、AIに頼める仕事の幅が狭い

両方を意識して鍛えていくことが、AI時代のエンジニアにとっての地力になります。

5. 生成物に「責任」を持てること

AIが作ったコード、AIが書いたドキュメント、AIが提案した設計——それを世に出したとき、 責任を取るのはAIではなく「あなた」 です。

責任を持つとは、具体的にどういうことか

① 中身を理解できるレベルで使う
AIが出力したコードの意味がわからないまま本番環境にデプロイするのは、読めない契約書にサインするようなものです。「なぜこの実装になっているのか」「他の選択肢ではなくこれを選ぶ理由は何か」を説明できる範囲で使いましょう。

② 事実確認を怠らない
AIは自信満々にウソをつきます(ハルシネーション)。存在しない関数、間違ったAPIの引数、古いバージョンの構文——必ず公式ドキュメントや実際の動作で裏を取る習慣をつけましょう。

③ 「最終チェックは人間」を原則にする
AIは優秀な下書き職人ですが、最終稿の品質を保証するのはあなたです。コミット、マージ、デプロイの前に、必ず自分の目でコードを読み、テストを通すプロセスを組み込みましょう。

責任を持てるということは、AIの出力を"ブラックボックス"にしないということ です。中身がわかるからこそ、修正できるし、レビューで説明できるし、障害が起きたときに原因を追える。それが本当の意味で「AIを使いこなしている」状態だと考えます。

まとめ:AIは優秀なアシスタントに過ぎない

AIは間違いなく強力なツールです。しかし、ツールの価値を決めるのは、使う人間の側 です。

「AIにできることを全部任せて、人間は何もしなくていい」——そんな未来は来ないと思っています。むしろ、AIが賢くなればなるほど、 「何を作りたいのか」「なぜそれを作るのか」「それは正しいのか」を考えられるエンジニアの価値 が高まっていきます。

明日から始められることは、たぶんこんなところです。

• AIに何かを頼む前に、3秒だけ「ゴールと制約」を頭の中で言語化してみる
• AIが返してきたコードを、一行ずつ「なぜこうなっているか」説明してみる
• 普段触らない領域のドキュメントを、目次だけでも眺めてみる

焦らず、自分のペースで

最後に一つ。

日々進化し続けている生成AI界隈の情報を追うのも、一苦労なはずです。新しいモデル、新しいツール、新しい使い方——SNSを開けば毎日のように流れてきます。

ただでさえ若手は、日常業務でたくさんの知識を取り込んでいる最中。そこに別の新しい情報を取り入れ続けるのは、正直しんどいと思います。

一方で、実際に使ったり、現場に身を置かないと使いこなせないのも事実 です。本を読むだけ、記事を眺めるだけでは、AIを使いこなす感覚は身につきません。

だからこそ、ストレスのない範囲で、日常に少しずつ取り込んでみる意識は持ってほしいと思います。流行りのツールを全部追いかけなくていいし、毎日プロンプトを工夫しなくてもいい。自分のできる範囲で、無理なく続けることのほうがずっと大事です。

そして、むやみやたらにAIを使って効率化することにこだわらず、AIを使えるだけの基礎を築くことにも目を向けてほしい なと思います。

土台のないところに高いビルは建ちません。AIという便利な道具を本当に活かせるかどうかは、結局、あなたがどれだけ「自分の土台」を育てられるかにかかっています。

AIを優秀なアシスタントにできるかどうかは、あなた次第です。