新人エンジニア向けAI仕事術トップ5|AIを賢い相棒に変える使い方を具体例で解説
こんにちは。ゆうせいです。
今回は、新人エンジニア向けに「AI仕事術トップ5」を解説します。
AIを使っても仕事が楽にならない理由
AIを使い始めた新人エンジニアの中には、こう感じる人がいます。
分かります。
AIは便利なはずなのに、使い方を間違えると「仕事を減らす道具」ではなく「確認作業を増やす道具」になります。
新人エンジニアにとって大切なのは、AIに完璧な答えを一発で出させようとしないことです。
AIは、自動販売機ではありません。
ボタンを押せば正解が出る道具ではなく、会話しながら考えを整理する相棒です。
たとえるなら、AIは優秀だけれど少し早とちりする先輩です。
知識は多い。
作業も速い。
でも、こちらの状況を完全には分かっていません。
だから、AIを使う側が「何を渡すか」「どう確認するか」「どこで止めるか」を設計する必要があります。
新人エンジニア向けAI仕事術トップ5
| 順位 | 仕事術 | 新人エンジニア向けの意味 |
|---|---|---|
| 第5位 | プロジェクト機能を使う | 毎回同じ前提説明をしない |
| 第4位 | 音声・画像を渡す | 会議内容や画面情報をそのままAIに渡す |
| 第3位 | 一旦出させる | 最初から完璧な指示を書こうとしない |
| 第2位 | 簡潔に答えさせる | AIの勘違いを早く見つける |
| 第1位 | 「つまり、こういうことですか?」と確認する | 自分の理解のズレを潰す |
では、1つずつ見ていきましょう。
第5位:プロジェクト機能を使う
AIを使うたびに、毎回同じ説明をしていませんか?
新人エンジニアがAIに相談するとき、この前提説明だけで疲れてしまうことがあります。
そこで使いたいのが、AIのプロジェクト機能です。
プロジェクト機能とは、特定の仕事や案件に関する前提情報をあらかじめAIに持たせておく機能です。
たとえば、「研修用Spring Bootアプリ」というプロジェクトを作り、次の情報を入れておきます。
すると、毎回ゼロから説明しなくても、AIがその前提を踏まえて答えやすくなります。
新人エンジニアでの具体例
たとえば、あなたが在庫管理アプリを作っているとします。
プロジェクト機能に、次のような情報を入れておきます。
商品テーブル
在庫テーブル
入出庫履歴テーブル
Controller、Service、Repositoryの役割
バリデーションルール
画面の命名規則
その状態で、AIにこう聞きます。
在庫数がマイナスにならないようにするチェック処理を考えてください。
すると、AIはプロジェクトの前提を踏まえて、より現実に近い回答を出しやすくなります。
毎回「うちのアプリはこういう構成で」と説明しなくてよくなるのです。
ただし、何でも入れすぎない
プロジェクト機能に入れる情報は、更新頻度が低いものに絞りましょう。
| 入れてよい情報 | 入れすぎ注意の情報 |
|---|---|
| 技術スタック | 日々変わるタスクメモ |
| 設計方針 | 昨日の会議メモ |
| コーディング規約 | 一時的なエラー内容 |
| 画面一覧 | 毎日変わる進捗状況 |
| DB設計の基本方針 | 未確定の仕様メモ |
日々変わる情報まで入れると、プロジェクト情報が古くなります。
古い情報をAIが信じてしまうと、回答もズレます。
プロジェクト機能は、AI用の「案件フォルダ」です。
何でも入れる倉庫ではありません。
第4位:音声・画像を渡す
新人エンジニアは、AIに説明するために長文を打ちがちです。
今日の会議では、ログイン機能のエラー処理について話して、 ユーザーが存在しない場合とパスワードが違う場合を同じメッセージにして、 あとバリデーションも追加することになって、 それから画面の文言も変更になって……
このように手で入力すると、時間がかかります。
しかも、抜け漏れが起きます。
そこで、音声や画像を使いましょう。
AIはテキストだけでなく、音声の文字起こしや画像の内容理解にも使えます。
つまり、情報を「文章に整えてからAIに渡す」のではなく、「現場で発生した情報に近い形でAIに渡す」のです。
音声を渡す例
会議やレビューの内容は、許可を取ったうえで録音して文字起こしすると便利です。
文字起こしをAIに渡して、次のように依頼します。
この文字起こしをもとに、新人エンジニアが対応すべきタスクを整理してください。 タスク、背景、確認事項、期限に分けてください。
すると、聞き逃しやメモ漏れを減らせます。
画像を渡す例
エンジニアの仕事では、画面の情報がとても大切です。
エラー画面
ブラウザの開発者ツール
DB設計書
画面レイアウト
シーケンス図
ログのスクリーンショット
たとえば、エラー画面のスクリーンショットをAIに渡して、こう聞きます。
このエラー画面から考えられる原因を、新人エンジニア向けに整理してください。 確認すべき順番も教えてください。
長い説明を手で入力するより、画像を渡したほうが早いことがあります。
特に、画面崩れ、エラー表示、ログの一部、設定画面などは画像のほうが伝わりやすいです。
注意点:機密情報は必ず確認する
音声や画像をAIに渡すときは、機密情報や個人情報に注意してください。
| 注意する情報 | 例 |
|---|---|
| 個人情報 | 氏名、メールアドレス、電話番号、住所 |
| 認証情報 | パスワード、APIキー、トークン |
| 顧客情報 | 顧客名、契約内容、問い合わせ内容 |
| 社内機密 | 未公開の仕様、障害情報、売上情報 |
AIに渡す前に、必ずマスキングしましょう。
便利さより安全性を優先してください。
第3位:一旦出させる
AIに指示を出すとき、最初から完璧なプロンプトを書こうとしていませんか?
もちろん、丁寧な指示は大切です。
しかし、最初から完璧な指示を書こうとすると、時間がかかります。
しかも、時間をかけたのに欲しい回答が出ないことも多いです。
そこで、新人エンジニアにおすすめしたいのが「一旦出させる」です。
まずは粗くAIに出力させます。
その回答を見て、「何が違うのか」「何が足りないのか」を自分で見つけます。
たとえるなら、いきなり清書を書くのではなく、下書きを作るイメージです。
コード生成での例
たとえば、ログイン機能のバリデーションを作りたいとします。
最初から完璧な指示を書くのではなく、まずこう投げます。
Spring Bootでログインフォームのバリデーション例を作ってください。AIの回答を見ると、次のような違和感が出るかもしれません。
自分のプロジェクトではThymeleafを使っているのに、REST API前提になっている
エラーメッセージの出し方が研修のルールと違う
DTOではなくEntityにバリデーションが書かれている
BindingResultの位置が違う
この違和感こそが、次の指示の材料です。
次にこう修正します。
このように、一旦出させると、自分が本当に欲しいものが明確になります。
一旦出させるメリット
| メリット | 説明 |
|---|---|
| 欲しい成果物が明確になる | 回答を見て違和感に気づける |
| 資料のノイズに気づける | AIが余計な情報を拾った場合、添付資料の問題を発見できる |
| 指示文を改善しやすい | 何を追加すべきか分かる |
| 作業が早くなる | 最初のプロンプト作成に時間を使いすぎない |
最初の出力は、完成品ではありません。
設計図を作るためのたたき台です。
まず出せ!
そこから直しましょう。
第2位:簡潔に答えさせる
AIの回答が長すぎて、読むのが大変になったことはありませんか?
新人エンジニアは、AIにこう頼みがちです。
悪い指示ではありません。
ただし、最初から長い説明をもらうと、AIの勘違いに気づきにくくなります。
たとえば、あなたが「既存ユーザー向けの改善施策」を相談したのに、AIが「新規ユーザー向けの施策」として回答していたとします。
回答が長文だと、そのズレを見逃しやすいです。
だから、最初は簡潔に答えさせます。
短い回答なら、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はこう返すかもしれません。
ここで、自分の理解のズレに気づけます。
この確認をしないまま実装すると、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へ質問するとき、回答を読んだあとに「つまり、私は〇〇すればよいという理解で合っていますか?」と聞き返すところから始めてみましょう!
セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。
投稿者プロフィール


