新人エンジニア向けAI仕事術トップ5|AIを賢い相棒に変える使い方を具体例で解説

こんにちは。ゆうせいです。

今回は、新人エンジニア向けに「AI仕事術トップ5」を解説します。

AIを使っても仕事が楽にならない理由

AIを使い始めた新人エンジニアの中には、こう感じる人がいます。

Danger

AIに聞いても回答が長すぎる
結局どこを読めばいいか分からない
コードを出してもらっても動かない
設計相談をしたのに話がズレる
説明が丁寧すぎて逆に読むのが大変
何度も修正しているうちに自分でやった方が早い





分かります。

AIは便利なはずなのに、使い方を間違えると「仕事を減らす道具」ではなく「確認作業を増やす道具」になります。

新人エンジニアにとって大切なのは、AIに完璧な答えを一発で出させようとしないことです。

AIは、自動販売機ではありません。

ボタンを押せば正解が出る道具ではなく、会話しながら考えを整理する相棒です。

たとえるなら、AIは優秀だけれど少し早とちりする先輩です。

知識は多い。

作業も速い。

でも、こちらの状況を完全には分かっていません。

だから、AIを使う側が「何を渡すか」「どう確認するか」「どこで止めるか」を設計する必要があります。

新人エンジニア向けAI仕事術トップ5

順位仕事術新人エンジニア向けの意味
第5位プロジェクト機能を使う毎回同じ前提説明をしない
第4位音声・画像を渡す会議内容や画面情報をそのままAIに渡す
第3位一旦出させる最初から完璧な指示を書こうとしない
第2位簡潔に答えさせるAIの勘違いを早く見つける
第1位「つまり、こういうことですか?」と確認する自分の理解のズレを潰す

では、1つずつ見ていきましょう。

第5位:プロジェクト機能を使う

AIを使うたびに、毎回同じ説明をしていませんか?

Danger

このプロジェクトはSpring Bootを使っています
DBはPostgreSQLです
フロントはThymeleafです
ログイン機能があります
命名規則はこうです
Controller、Service、Repositoryに分けています


新人エンジニアがAIに相談するとき、この前提説明だけで疲れてしまうことがあります。

そこで使いたいのが、AIのプロジェクト機能です。

プロジェクト機能とは、特定の仕事や案件に関する前提情報をあらかじめAIに持たせておく機能です。

たとえば、「研修用Spring Bootアプリ」というプロジェクトを作り、次の情報を入れておきます。

Success

使用技術
ディレクトリ構成
コーディング規約
DB設計方針
画面一覧
エラー処理方針
過去に作ったサンプルコード


すると、毎回ゼロから説明しなくても、AIがその前提を踏まえて答えやすくなります。

新人エンジニアでの具体例

たとえば、あなたが在庫管理アプリを作っているとします。

プロジェクト機能に、次のような情報を入れておきます。

商品テーブル
在庫テーブル
入出庫履歴テーブル
Controller、Service、Repositoryの役割
バリデーションルール
画面の命名規則





その状態で、AIにこう聞きます。

在庫数がマイナスにならないようにするチェック処理を考えてください。

すると、AIはプロジェクトの前提を踏まえて、より現実に近い回答を出しやすくなります。

毎回「うちのアプリはこういう構成で」と説明しなくてよくなるのです。

ただし、何でも入れすぎない

プロジェクト機能に入れる情報は、更新頻度が低いものに絞りましょう。

入れてよい情報入れすぎ注意の情報
技術スタック日々変わるタスクメモ
設計方針昨日の会議メモ
コーディング規約一時的なエラー内容
画面一覧毎日変わる進捗状況
DB設計の基本方針未確定の仕様メモ

日々変わる情報まで入れると、プロジェクト情報が古くなります。

古い情報をAIが信じてしまうと、回答もズレます。

プロジェクト機能は、AI用の「案件フォルダ」です。

何でも入れる倉庫ではありません。

第4位:音声・画像を渡す

新人エンジニアは、AIに説明するために長文を打ちがちです。

今日の会議では、ログイン機能のエラー処理について話して、
ユーザーが存在しない場合とパスワードが違う場合を同じメッセージにして、
あとバリデーションも追加することになって、
それから画面の文言も変更になって……

このように手で入力すると、時間がかかります。

しかも、抜け漏れが起きます。

そこで、音声や画像を使いましょう。

AIはテキストだけでなく、音声の文字起こしや画像の内容理解にも使えます。

つまり、情報を「文章に整えてからAIに渡す」のではなく、「現場で発生した情報に近い形でAIに渡す」のです。

音声を渡す例

会議やレビューの内容は、許可を取ったうえで録音して文字起こしすると便利です。

Success

仕様確認ミーティング
コードレビューの指摘
設計相談
先輩からの説明
障害対応の振り返り


文字起こしをAIに渡して、次のように依頼します。

この文字起こしをもとに、新人エンジニアが対応すべきタスクを整理してください。
タスク、背景、確認事項、期限に分けてください。

すると、聞き逃しやメモ漏れを減らせます。

画像を渡す例

エンジニアの仕事では、画面の情報がとても大切です。

エラー画面
ブラウザの開発者ツール
DB設計書
画面レイアウト
シーケンス図
ログのスクリーンショット





たとえば、エラー画面のスクリーンショットをAIに渡して、こう聞きます。

このエラー画面から考えられる原因を、新人エンジニア向けに整理してください。
確認すべき順番も教えてください。

長い説明を手で入力するより、画像を渡したほうが早いことがあります。

特に、画面崩れ、エラー表示、ログの一部、設定画面などは画像のほうが伝わりやすいです。

注意点:機密情報は必ず確認する

音声や画像をAIに渡すときは、機密情報や個人情報に注意してください。

注意する情報
個人情報氏名、メールアドレス、電話番号、住所
認証情報パスワード、APIキー、トークン
顧客情報顧客名、契約内容、問い合わせ内容
社内機密未公開の仕様、障害情報、売上情報

AIに渡す前に、必ずマスキングしましょう。

便利さより安全性を優先してください。

第3位:一旦出させる

AIに指示を出すとき、最初から完璧なプロンプトを書こうとしていませんか?

Danger

背景を書いて
目的を書いて
制約を書いて
出力形式を書いて
参考資料を添付して
注意点も全部入れて……


もちろん、丁寧な指示は大切です。

しかし、最初から完璧な指示を書こうとすると、時間がかかります。

しかも、時間をかけたのに欲しい回答が出ないことも多いです。

そこで、新人エンジニアにおすすめしたいのが「一旦出させる」です。

まずは粗くAIに出力させます。

その回答を見て、「何が違うのか」「何が足りないのか」を自分で見つけます。

たとえるなら、いきなり清書を書くのではなく、下書きを作るイメージです。

コード生成での例

たとえば、ログイン機能のバリデーションを作りたいとします。

最初から完璧な指示を書くのではなく、まずこう投げます。

Spring Bootでログインフォームのバリデーション例を作ってください。




AIの回答を見ると、次のような違和感が出るかもしれません。

自分のプロジェクトではThymeleafを使っているのに、REST API前提になっている
エラーメッセージの出し方が研修のルールと違う
DTOではなくEntityにバリデーションが書かれている
BindingResultの位置が違う





この違和感こそが、次の指示の材料です。

次にこう修正します。

Success

Thymeleafを使う画面遷移型のログインフォームとして作り直してください。
EntityではなくFormクラスにバリデーションを書いてください。
ControllerではBindingResultをFormクラスの直後に置いてください。
新人エンジニア向けに理由も説明してください。





このように、一旦出させると、自分が本当に欲しいものが明確になります。

一旦出させるメリット

メリット説明
欲しい成果物が明確になる回答を見て違和感に気づける
資料のノイズに気づけるAIが余計な情報を拾った場合、添付資料の問題を発見できる
指示文を改善しやすい何を追加すべきか分かる
作業が早くなる最初のプロンプト作成に時間を使いすぎない

最初の出力は、完成品ではありません。

設計図を作るためのたたき台です。

まず出せ!

そこから直しましょう。

第2位:簡潔に答えさせる

AIの回答が長すぎて、読むのが大変になったことはありませんか?

新人エンジニアは、AIにこう頼みがちです。

Warning

できるだけ丁寧に詳しく説明してください。





悪い指示ではありません。

ただし、最初から長い説明をもらうと、AIの勘違いに気づきにくくなります。

たとえば、あなたが「既存ユーザー向けの改善施策」を相談したのに、AIが「新規ユーザー向けの施策」として回答していたとします。

回答が長文だと、そのズレを見逃しやすいです。

だから、最初は簡潔に答えさせます。

Success

まず3行で答えてください。
結論だけ先に教えてください。
箇条書きで5点以内にしてください。
前提が合っているか確認したいので、短く答えてください。





短い回答なら、AIの前提ミスをすぐに見つけられます。

新人エンジニアでの具体例

たとえば、AIにこう聞いたとします。

Spring Bootでログイン失敗時のエラーメッセージを出す方法を教えてください。
まず3行で概要を答えてください。





AIがこう返したとします。

REST APIで401を返します。
フロント側でエラーレスポンスを受け取り表示します。
認証失敗時はJSONでエラー内容を返します。





ここで気づけます。

「あれ?自分が作っているのはREST APIではなく、Thymeleafの画面遷移型だ」と。

長文で説明される前に、前提のズレを修正できます。

今回はREST APIではなく、Thymeleafの画面遷移型です。
ログイン失敗時に同じ画面へ戻し、エラーメッセージを表示する方法で説明してください。

このように、簡潔な回答は手抜きではありません。

ズレを早く見つけるためのチェックポイントです。

簡潔に答えさせるときのコツ

目的指示例
前提確認まず前提を3行で整理してください
方針確認実装方針だけを5点以内で答えてください
エラー調査原因候補を可能性が高い順に3つだけ出してください
設計相談結論、理由、注意点をそれぞれ1行で答えてください

詳しい説明は、後から求めれば大丈夫です。

最初は短く。

ズレがないと分かってから深掘りしましょう。

第1位:「つまり、こういうことですか?」と確認する

第1位は、「つまり、こういうことですか?」とAIに聞き返すことです。

ここが最も重要です。

AIの回答を読んだとき、人は分かった気になります。

しかし、実際には自分の理解がズレていることがあります。

AIが間違えている場合は、まだ気づける可能性があります。

しかし、自分の理解が間違っている場合、自分だけでは気づきにくいです。

だから、AIに確認します。

つまり、今回の方針は〇〇という理解で合っていますか?

この一言で、自分の勘違いを発見できます。

新人エンジニアでの具体例

たとえば、AIが次のように説明したとします。

Service層では業務ロジックを扱い、Controller層ではリクエストを受け取って画面やレスポンスを返します。





あなたはこう理解したとします。

つまり、Controllerには処理を書かず、全部Serviceに書けばいいということですか?

すると、AIはこう返すかもしれません。

Success

近いですが、少し違います。
Controllerにも入力値の受け取り、画面遷移、BindingResultの確認などの役割があります。
ただし、在庫数を更新する、注文を確定する、といった業務判断はServiceに置くのが基本です。





ここで、自分の理解のズレに気づけます。

この確認をしないまま実装すると、Controllerが薄すぎたり、逆にServiceが何でも屋になったりします。

「つまり」で聞き返す例

場面聞き返し例
設計相談つまり、この処理はControllerではなくServiceに置くべきという理解で合っていますか?
エラー調査つまり、今回のエラーはDB接続ではなく、リクエストパラメータ名の不一致が原因の可能性が高いということですか?
SQL学習つまり、GROUP BYは行をまとめるためで、WHEREはまとめる前に絞り込むためという理解で合っていますか?
Git学習つまり、commitはローカル保存で、pushはリモートへ送る操作ということですか?
テスト設計つまり、正常系だけでなく、入力漏れや境界値も確認すべきということですね?

「つまり」は、自分の理解を言語化するための言葉です。

AIに説明させるだけではなく、自分の理解をAIにぶつけて確認しましょう。

分かった気になるな。

「つまり」で確認しろ!

新人エンジニア向けの独自視点:AIは答えを出す道具ではなく、認識合わせの相手

ここから、独自の視点を追加します。

新人エンジニアがAIを使うとき、最も危険なのは「答えをもらう感覚」で使うことです。

AIは便利ですが、回答が常に正しいとは限りません。

また、正しい回答でも、自分のプロジェクトには合わない場合があります。

だから、AIは答えを出す道具ではなく、認識合わせの相手として使うべきです。

使い方危険な点おすすめの使い方
AIに答えを出させる間違いをそのまま信じるAIに案を出させ、自分が確認する
AIにコードを書かせる動かないコードを貼るコードの意図、前提、注意点も確認する
AIに説明させる読んで分かった気になる「つまり」で理解を確認する
AIに長文で答えさせるズレに気づけない最初は短く答えさせる

新人エンジニアにとって、AIは先生でもあり、壁打ち相手でもあります。

ただし、先生の言うことを丸暗記するのではなく、「この理解で合っていますか?」と確認しながら進むことが重要です。

AI仕事術トップ5の実務活用例

ここでは、日常業務にどう使うかを整理します。

業務AIの使い方ポイント
コードレビュー対応指摘内容を貼り、修正方針を整理させる最後に「つまり」で理解確認する
エラー調査エラー画面やログを渡し、原因候補を出させる最初は3つだけ候補を出させる
設計相談プロジェクト前提を入れて、方針案を出させる一旦出させてから修正する
会議後のタスク整理文字起こしを渡してタスク化する許可と機密情報に注意する
学習短く説明させ、自分の理解を確認する「つまり、〇〇ですか?」と聞き返す

AIを使うときの注意点

AIを使うときは、次の点に注意してください。

注意点説明
機密情報を入れない顧客情報、APIキー、パスワード、未公開情報は入力しない
回答を鵜呑みにしないAIは自然に間違うことがある
自分の環境で検証するコードは必ず実行して確認する
公式ドキュメントも確認するライブラリやフレームワークの仕様は最新情報を見る
レビューを省略しないAIが書いたコードも人間がレビューする

AIは作業を速くしてくれます。

しかし、責任を取ってくれるわけではありません。

最後に確認するのは、エンジニアであるあなたです。

まとめ

新人エンジニアがAIを使いこなすには、AIに完璧な答えを一発で出させようとしないことが大切です。

大事なのは、AIとのやり取りを設計することです。

順位仕事術実務での使い方
第5位プロジェクト機能を使う案件や技術構成の前提を毎回説明しない
第4位音声・画像を渡す会議、画面、ログを効率よくAIに渡す
第3位一旦出させるたたき台を見て、欲しい成果物を明確にする
第2位簡潔に答えさせるAIの前提ミスを早く見つける
第1位「つまり、こういうことですか?」と確認する自分の理解のズレを防ぐ

一言でまとめるなら、AI仕事術とは「AIに任せる技術」ではなく、「AIと認識を合わせながら仕事を進める技術」です。

新人エンジニアは、AIの回答をそのまま使わないでください。

まず短く答えさせる。

一旦出させる。

画像や音声も使う。

プロジェクトの前提を整える。

そして最後に、必ずこう聞いてください。

つまり、こういう理解で合っていますか?

この一言が、AI活用の精度を大きく変えます。

前提を整える
        ↓
音声や画像も使って情報を渡す
        ↓
一旦出させる
        ↓
簡潔に答えさせる
        ↓
つまり、と聞き返す
        ↓
AIとの認識ズレが減る
        ↓
仕事が速く正確になる




今後の学習では、AI仕事術に加えて、プロンプト設計、コードレビューでのAI活用、エラー調査、設計相談、テストケース作成、セキュリティ上の注意点、公式ドキュメントの読み方を順番に学ぶとよいです。まずは次にAIへ質問するとき、回答を読んだあとに「つまり、私は〇〇すればよいという理解で合っていますか?」と聞き返すところから始めてみましょう!

セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。

投稿者プロフィール

山崎講師
山崎講師代表取締役
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
海外放浪の末、2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します!
この記事に間違い等ありましたらぜひお知らせください。

学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。