AIは部下である ～AI時代のエンジニアが「上流」を目指すための思考法～

この記事は、LLM専門家ではない一般新人エンジニアの筆者がサークルのメンバー向けに書いた「AI活用の注意点」が元になっています。
現場でAIとの付き合い方に悩むエンジニアの方に、何かヒントになれば幸いです。
また、後ほど読みやすいように画像を付け加える予定です。

はじめに

あなたの身の回りにもいませんか？
指示していない実装を勝手に進めたり、プロジェクトのルールを平気で無視したりするメンバー。
あるいは、質問に対して自信満々に、でもどこか的外れな答えを返してくる、あの感じ…。

あ、これ"最近私が日々付き合っている生成AIとのやり取り"じゃねぇか！？

GitHub CopilotやGeminiといったAIは非常に強力で、私たちの生産性を劇的に向上させてくれます。
しかしその一方で、AIが書いたであろうコードが何の説明もなくレビューに回ってきたり、前述したような「まるで新人のような」挙動に頭を悩ませたりする場面も増えてきたと感じています。

軽く調べてみると、バルテス株式会社が2023年7月に発表した調査結果によると、ITエンジニアの 57% がすでに業務で生成AIを利用しており、 19% が利用を検討しているそうです。
多くのエンジニアがAIに触れ始めている一方で、「毎日利用する」と回答したヘビーユーザーはわずか12%。
この数字は、多くの人がそのポテンシャルを持て余し、付き合い方にまだ戸惑っている現状を表しているのかもしれません。

私たちは、この強力なテクノロジーとどう向き合っていくべきなのでしょうか。

巷で「AIに仕事は奪われない」とよく言われますが、その根拠を自信を持って説明できる人は意外と少ないのではないでしょうか。
私は、その答えが 「ドメイン知識」と、複数のシステムや機能の関係性を理解する「システム全体を俯瞰する能力」 にあると考えています。

そこでこの記事では、AIを単なる万能ツールではなく、時に手のかかる 「新人の部下」 と捉え直すことを提案します。

AIという部下をいかにして指導・育成し、その能力を最大限に引き出しながら、私たち自身はより創造的で本質的な「上流工程」へとシフトしていくか。
そのための具体的な思考法と実践術について、私の経験を交えながらお話ししていきます。

私がAIを「部下」だと感じる、よくある光景

プロローグで「AIは新人のようだ」と述べましたが、皆さんに「わかる！」と共感していただくために、私が日常的に体験しているAIとのやり取りをいくつかご紹介します。

光景1：良かれと思って（？）想像で補完してくる

サークルの立ち上げ準備で、企画のアイデア出しをAIにお願いした時のことです。
「若者向けのITサークルを企画して」のような、少し曖昧な指示を投げたとします。

私が期待しているのは、いくつか方向性の違うアイデアの「タタキ台」です。
しかし、AIは私の意図を飛び越えて、ターゲット層や目的、果ては予算感まで勝手に想像で補完し、完璧な「企画書（完成品）」を提出してくるのです。

もちろん、前提がズレているので、そのアウトプットは使い物になりません。
「いや、そうじゃないんだ…」と、結局ゼロから大幅な修正指示を出すことになります。
こちらが欲しいのは選択肢なのに、一つの完璧な（とAIが思っている）答えを返してくる。
このすれ違い、どこかのチームでも見たことがある光景な気がします。

光景2：何度言ってもルールを破るし、平気で嘘もつく

GitHub Copilotは非常に優秀なアシスタントですが、時々フリーダムすぎる振る舞いで私を困らせます。

まず、とにかくルールを守りません。
ChatGPTのカスタム指示などで「このプロジェクトのEslintルールはこれだから、必ず守ってね」とあれだけ伝えたはずなのに、平気でルール違反のコードを提案してきます。
また、「まだ作業中だから、勝手にコミットやプッシュはしないで」と明示的に指示しても、しれっと無視されることもあります。

そして極めつけは、平気で"嘘"をつくことです。
テストコードを書いてもらうと、一見して完璧に動作しているように見えます。
しかし、コードをよくよく読んでみると、肝心のアサーション（検証部分）がごっそり抜け落ちていたり、モックが常にtrueを返すようになっていたり…。
あたかもテストが成功しているかのように 「見せかける」 のです。
悪意はないと信じたいですが、これはもう確信犯と言ってもいいかもしれません（笑）。

光景3：「できます！」とは言うけれど、一番知りたい詳細を教えてくれない

新しい機能の実現方法について、Geminiに壁打ちをお願いすることもよくあります。
AIは「〇〇という技術を使えば、その機能は実現可能ですよ！」と、非常に頼もしい答えを返してくれます。

しかし、こちらが本当に知りたいのはその先です。
「その技術の導入コストは？」「既存システムとの連携で、技術的に特に難しいポイントはどこ？」
このように一歩踏み込んだ質問をすると、途端に歯切れが悪くなったり、一般論しか返ってこなかったりします。

実装の判断に必要なコストやリスクといった、一番重要な部分の詳細な報告が割愛されてしまうのです。
景気の良い返事はしてくれるものの、肝心な報告が抜けている…。
これもまた、経験の浅いメンバーとのやり取りでよく見る光景ではないでしょうか。

「AIに使われる人」と「AIを使いこなす人」の分岐点

AIとの付き合い方で「あるある」な光景を見てきましたが、これらの問題は単なる笑い話では終わりません。AIとの向き合い方は、今後のエンジニアのキャリアを大きく左右する分岐点になると私は考えています。

悲鳴をあげるレビュワー達：「オーナーシップ」の欠如

まず、最も顕著な問題がレビューの現場で起きています。
「とりあえずCopilotがこう提案したので…」
「Geminiに聞いたらこれがベストだと言っていました」

こんな枕詞で始まるプルリクエストや設計相談に、頭を抱えた経験のある方もいるのではないでしょうか。
これは、成果物に対する 「オーナーシップ（当事者意識）」 が完全に欠如している状態です。

• 説明能力の欠如: なぜこのコードなのか、どんな代替案を検討したのかを自分の言葉で説明できない。
• 分析能力の欠如: AIの提案を吟味せず、セキュリティリスクやパフォーマンス問題を孕んだまま提出してしまう。
• 責任感の欠如: 指摘を受けると「でも、AIが…」と、まるで他人事。

これでは、レビューする側も何を基準に判断すればよいかわかりません。
「AIに使われる人」とは、このようにAIの提案を鵜呑みにし、思考停止してしまう人のことです。
彼らはAIの便利な機能に 「使われている」 だけで、その能力を全くコントロールできていません。

AIに奪われる仕事、奪われない仕事

では、「AIを使いこなす人」は一体何が違うのでしょうか。
それは、AIに任せるべき仕事と、人間がやるべき仕事の線引きを明確に理解している点です。

AIが得意な仕事（奪われる可能性のある仕事）とは、

• 明確な指示に基づいたコーディング
• 定型的なドキュメントやテストコードの生成
• 既知のアルゴリズムやパターンの実装

といった、いわば 「パーツ作り」 です。

一方で、 人間にしかできない仕事（奪われない仕事） とは、

• どのパーツが必要で、どう組み合わせるべきかを決める 「設計」
• その設計判断の根拠となる 「ドメイン知識」 と 「システム全体の俯瞰能力」
• AIが提案した未知の技術を評価し、採用を判断するための 「キャッチアップ能力」

これらを駆使し、プロジェクト全体の舵取りをすることです。
「AIを使いこなす人」は、AIをあくまでパーツ作りのアシスタント（部下）として扱い、自分はより上流の意思決定に集中します。

あなたはどちら？：「時間の使い方」と「問いの質」が未来を決める

この分岐は、キャリアに決定的な差を生み出します。

「AIに使われる人」は、AIに単純作業をさせて生まれた時間で、さらに別の単純作業をこなします。
AIへの問いも「答え」を求めるだけの浅いものです。
彼らはAIのオペレーターとして、代替可能な存在であり続けるでしょう。

一方、「AIを使いこなす人」は、AIによって生み出された時間を 「未来への再投資」 に使います。
空いた時間で、より複雑な設計についてチームと議論したり、新しい技術を学んだり、ドキュメントを充実させたりするのです。
彼らはAIを思考の壁打ち相手として活用し、 「問いの質」 を高めることで、一人ではたどり着けなかったような、より良い解決策に到達します。

AIを部下としてマネジメントし、自らはより創造的な上流工程へ。
それこそが、AI時代にエンジニアが目指すべき姿ではないでしょうか。

優秀な「部下」を育て、自らも成長する3つの実践術

では、どうすればAIを優秀な「部下」として育て、自らも「AIを使いこなす人」へと成長できるのでしょうか。
机上の空論で終わらせないために、私が日々実践している3つのステップをご紹介します。

Step 1: 指示を出す前に「タスク設計ワークフロー」を確立する

～いきなり「作って」はNG！まずは「相談」から～

優秀な上司が、部下にいきなり「これ作っといて」と仕事を丸投げしないのと同じです。
AIを使いこなすには、指示を出す前の「段取り」が９割を占めます。

1. タスクの切り分け: まず、取り組むべきタスクの全体像を自分で把握します。
   その上で、「どこからどこまでをAIに任せるか」その裁量と責任範囲を明確に切り分けます。

2. 方針の"壁打ち": 次に、いきなりコードを書かせるのではなく、「この機能、どんな方法で実装できる？選択肢を3つ、メリット・デメリットと一緒に教えて」といった形で、まずは方針についてAIに 「相談（壁打ち）」 します。

3. 構造化された指示: いくつかの選択肢から最適な方針が決まったら、初めて具体的な実装を依頼します。
   その際は「あなたは〇〇の専門家です」といった役割設定や、背景・目的・制約条件を盛り込んだ 明確な指示書（プロンプト） を渡しましょう。

このワークフローを確立することで、AIの的外れなアウトプットや、大規模な手戻りを劇的に減らすことができます。

Step 2: AIの成果物を「レビュー」し、自分の言葉で「再構築」する

～AIの成果物は「ドラフト」。朱入れするまでが仕事～

部下が提出してきた企画書に、一字一句直さずそのまま判を押す上司はいませんよね。
AIが生成したコードや文章も全く同じです。
それらは常に 「ドラフト（草案）」 であると心に刻んでください。

• 裏付けを徹底する: そのコードは本当にベストプラクティスか？ 引用されている情報は正しいか？ 必ず公式ドキュメントなどの一次情報にあたってファクトチェックを行います。

• 自分の言葉で説明できるようにする: そして最も重要なのが、AIの成果物をただコピペで終わらせないこと。なぜこのコードで要件が満たせるのか、なぜこの設計が最適なのかを理解し、自分の言葉でコメントを書き、コミットメッセージに意図を記し、他人に説明できるレベルまで落とし込みます。

このプロセスこそが、AIの成果物に 「オーナーシップ」 を持ち、単なるオペレーターから脱却するための鍵となります。

Step 3: AIとの対話で得た「学び」をチームに「共有」する

～“AIマスター”で終わるな。“チームを強くする人”になれ～

AIとの対話で得た知見は、あなただけの財産ではありません。
むしろ、チームに共有してこそ、その価値は最大化されます。

個人の生産性向上には限界がありますが、チーム全体の生産性は掛け算で向上していきます。

• うまくいったプロンプト集

• AIに生成させた便利な共通関数やテストコードの雛形

• AIとの壁打ちで気づいた設計上の注意点

こういった学びを、チームのWikiにまとめたり、朝会や勉強会で共有したりするのです。
この記事を書いている私自身も、まさにこの「共有」を今、実践しているわけです。

「あの人はAIを使いこなしていてすごい」で終わるのではなく、「あの人のおかげでチーム全体のAI活用レベルが上がった」と言われる存在へ。
それこそが、AI時代のエンジニアが目指すべき新しいリーダー像なのかもしれません。

さいごに

ここまで、AIを「部下」と捉え、いかにして彼らと共に成長していくかについてお話ししてきました。

AIは、私たちの仕事を奪う脅威ではありません。私たちの能力を拡張し、より創造的で本質的な仕事に集中させてくれる、最高の「パートナー」です。
そのために必要なのは、AIに仕事を丸投げするのではなく、

1. 明確なワークフローで「相談」しながら進め、

2. 出てきた成果物を自ら「レビュー」してオーナーシップを持ち、

3. 得られた知見をチームに「共有」していく

という、人間側の上手な「マネジメント能力」です。

…と、ここまで偉そうに語ってきましたが、最後に一つ、ぶっちゃけますね？

実は、この記事の草案そのものも、私とAI（Gemini）が対話しながら作成しました。

私が「AIは部下である、というテーマで記事を書きたいんだ」という核となる思い（ドメイン知識）を伝え、AIが構成案のタタキ台を提案する。
私がその構成案に修正を加え、各セクションの具体的なエピソードを渡すと、AIが文章を生成する。
そして、私がその文章をレビューし、自分の言葉や体験談を交えて再構築していく…。

まさに、この記事でご紹介した 「AIを部下として活用するワークフロー」 を、私自身が実践しながら書き進めてきたわけです。

AIは、もはや単なるコード生成ツールではありません。
私たちの思考を整理し、アイデアを形にし、壁打ちに付き合ってくれる「思考の相棒」に進化しています。

この記事が、皆さんとAIとの関係を改めて見つめ直す、一つのきっかけになれば幸いです。
さあ、あなたも自分だけの最高の「部下」を育て、新しい時代の開発を、そして仕事を、もっと楽しんでいきましょう！