「AIはこう言っています」に、私は「で、君はどう思うの？」と返した。〜未経験若手を育てるチームリーダーが辿り着いた、AI時代のエンジニア育成論〜
📋 1分で読めるこの記事の要約
- 現場の違和感: 「調べてみて」と指示した若手から「AIはこう言っています」と返ってきたとき、リーダーが覚えるモヤモヤの正体は「主語が自分からAIへ消えてしまう危うさ」にあります。
- 物理の現実: 結果的にAIの回答が正しかったとしても、セキュアな本番環境や閉域網、緊急トラブルの現場では「いつもAIに聞けるとは限りません」。
- 育成の処方箋: AIを禁止するのではなく、「AIに聞く前に3分だけ自分の仮説をメモさせる」指導へ転換します。AIを「答えを出す機械」から「仮説を検証する壁打ち相手」へ変えることが、自走するエンジニアを育てる鍵になります。
プロローグ：あの日、ネットワークがつながらない現場で
「すみません、拠点間の通信が通りません」
ある日の午後、請負チームの若手エンジニアから声がかかりました。彼は異業種からIT業界へ飛び込んできた、意欲あふれる未経験採用のメンバーです。
画面を見ると、新設した拠点ルーターの先にある検証サーバーへ ping が届いていません。設定ミスなのか、物理配線の問題なのか、あるいはルーティングの経路情報が届いていないのか。
私は彼にこう伝えました。
「一度、どこで通信が止まっているか調べてみてくれる？」
数分後、キーボードを叩いていた彼が振り返り、少し誇らしげにこう言いました。
「先輩、 AIはこう言っています 。サブネットマスクの設定が怪しいそうです」
その言葉を聞いた瞬間、私の口から自然と出たのは、次の問いかけでした。
「そっか。 で、君はどう思うの？ 」
彼は一瞬きょとんとした表情を浮かべ、言葉に詰まって黙り込んでしまいました。
意地悪で試したわけではありません。実は、 私自身もその場で正解を知っていたわけではない からです。
ネットワークの障害対応では、現地で調査してみないとベテランでもその場ですぐに答えはわかりません。しかし、私の中にはいくつかの 「仮説」 がありました。
「さっきコンフィグを流し込んだとき、VLANの割り振りを間違えたんじゃないか」
「ルーティングテーブルを見る限り、対向のゲートウェイでパケットを破棄されているんじゃないか」
答えはわからなくても、仮説は持っていたのです。
第1章：結果的に「AIの言うとおり」だったとしても、残るモヤモヤ
その後、調査を進めると、驚いたことに 結果はAIの言った通り でした。サブネットマスクの表記が1文字ズレていたのです。
通信は無事に開通しました。若手メンバーは「AIって本当に便利ですね！」と笑顔を見せてくれました。
問題は解決しました。業務も前に進みました。ツールとしてのAIは満点の結果を出しました。
それなのに、私の胸の奥には 言葉にしにくい強いモヤモヤ が残っていました。
この違和感の正体は何だろうか。その日の夜、自宅の検証環境を触りながら、私はその理由を深く考えました。
1-1. 主語が「自分」から「AI」へ消えてしまう怖さ
最大の危うさは、 思考の主語が「自分」から「AI」へすり替わってしまうこと です。
- ⭕ 健全な報告: 「私はルーターのルーティング設定を疑っています。なぜならログにエラーが出ているからです」
- ❌ 思考停止の報告: 「AIはサブネットマスクが怪しいと言っています」
前者の報告には、「自分の観察」と「自分の推論」があります。もし仮説が間違っていたとしても、「なぜ外れたのか」を振り返れば、次はより精度の高い推論ができるようになります。失敗がエンジニアとしての血肉になります。
しかし後者の報告には、本人の頭を通った形跡がありません。AIというブラックボックスから出てきた文字列を、人間がただの伝書鳩として先輩へ運んでいるだけです。
もしその設定を入れて、本番システム全体が停止したらどうするのでしょうか。
「AIがそう言ったから設定しました」では、プロのエンジニアとして責任を取ることはできません。
1-2. 「正解」は出ても、「思考の回路」が頭に残らない
AIに答えを聞けば、一瞬で正解へ辿り着けます。
しかしそれは、 数学の問題で途中計算を一切書かずに、巻末の解答ページだけを書き写している状態 に似ています。
「なぜそのコマンドを打つのか」
「パケットがケーブルの中をどう流れて、どこで弾かれたのか」
その因果関係を頭の中で組み立てる訓練を飛ばしてしまうと、何度トラブルを経験しても、本人の頭の中に「トラブルシュートの回路」が育ちません。
第2章：インフラ現場の真実――「いつもAIに聞けるとは限らない」
「でも、AIで素早く解決できるなら、結果オーライではないですか？」
そう思う方もいるかもしれません。現代のIT開発において、AIのスピード感を活かすのは当然の戦略です。
しかし、私がインフラエンジニアとして、そして情報処理安全確保支援士・ネットワークスペシャリストとして痛感している現実があります。
それは、 「現場では、いつもAIに聞けるとは限らない」 という物理的な制約です。
2-1. ネットもスマホも遮断された「本番環境・閉域網」の修羅場
金融機関の基幹システム、官公庁の閉域ネットワーク、データセンターのサーバルーム。
私たちが守るべき重要なインフラ環境の多くは、外部のインターネットから厳重に隔離されています。スマートフォンの持ち込みすら制限されるセキュリティエリアも珍しくありません。
そこにはChatGPTもなければ、Copilotも存在しません。
黒い画面のコンソール（CUI）と、点滅するルーターのLEDランプ。そして目の前で止まっている重要な業務システム。
その張り詰めた空間に放り出されたとき、 手元で頼れるものは「自分の頭の中にある知識と仮説」だけ です。
2-2. 画面が固まった数分間、何を手がかりに動くのか
日常的に「まずAIに聞く」という手順に慣れきってしまったエンジニアは、外部ツールが遮断された瞬間に手足が完全に止まってしまいます。
pingが通らないとき、どのレイヤーから順番に疑うかtcpdumpやパケットキャプチャのログを見て、何を異常と判断するか- ルーターの統計情報から、どのインターフェースでパケットロスが起きているかを読み取るか
基礎的な物理モデルが頭の中に構築されていない人は、AIの補助輪が外れた途端に一歩も動けなくなります。
だからこそ、若手のうちに「自分の頭で仮説を組み立てる経験」を積んでおく必要があるのです。
第3章：リーダー自身の反省――「指示の出し方」をどう変えたか
ここまで若手の行動について書きましたが、実は 最も反省すべきはリーダーである私自身 でした。
翌朝、私は自分の指導方法を振り返りました。
「調べてみて」という指示は、あまりにも言葉足らずで不親切だったのではないか。
ネットを開けばAIが常駐している現代において、未経験の若手が真っ先にAIへ質問するのは、ある意味で最も合理的で自然な行動です。
若手が思考停止していたのではなく、 リーダーである私が「思考を促す指示」を出せていなかった のです。
そこで私は、チーム内での指示の出し方とルールを次のように刷新しました。
3-1. ルール①：検索する前に「3分だけ自分の仮説をメモする」
何かのエラーやトラブルに直面したとき、すぐにブラウザやAIツールを開くことを禁止しました。
その代わり、 「調べる前に、怪しいと思う箇所を1行だけ手元のメモに書く」 というルールを設けました。
- 「インターフェースのステータスが down になっているのではないか」
- 「ACL（アクセス制御リスト）でポートが遮断されているのではないか」
最初は見当違いの仮説でも構いません。大切なのは、 「自分の頭で因果関係を一度想像してみる」というワンクッションを挟むこと です。
3-2. ルール②：AIへの質問文を「答え探し」から「仮説検証」へ変える
AIの使い方そのものも根本から変えました。
単にエラー文を貼り付けて「直してください」と聞くプロンプトを改め、 「自分の仮説をぶつける壁打ち相手」 として使わせるようにしました。
❌ 従来のプロンプト（答え探し）:
「拠点間のルーターで ping が通りません。原因と解決策を教えてください」
⭕ 改善後のプロンプト（仮説検証）:
「拠点間で ping が通りません。
現在のコンフィグとログを見る限り、私は『OSPFのエリア設定の不一致』または『MTUサイズの不整合』を疑っています。
この私の仮説の妥当性を評価してください。
また、私が現場で見落としている可能性のある観点があれば3点挙げてください」
この聞き方をすると、AIの出力は劇的に変わります。
AIは単なる答えではなく、「あなたの仮説はここが正しい」「ただし、このログが出ているなら別の要因も考えられる」と、 極めて優秀な技術メンターのような回答 を返してくれるようになります。
若手自身も、自分の仮説とAIの指摘を比較しながら読むため、理解の深さが段違いになります。
3-3. ルール③：「なぜ？」を説明できない設定は承認しない
コードレビューやコンフィグ確認の基準も変更しました。
「動いているから合格」ではなく、 「変更した各行の意図を、自分の言葉で説明できるか」 を確認するようにしました。
「AIがこのパラメータを推奨した理由は理解できた？」
「もしこの数値を2倍にしたら、システムはどう振る舞うと思う？」
意地悪な質問ではなく、対話を通じて若手自身の言葉で語ってもらいます。
自分の言葉で説明できた瞬間、若手の表情は「AIに言われた通りにやった作業員」から、「自分の意志でシステムを動かしているエンジニア」の顔つきへと変わっていきます。
第4章：AI時代に「本当に伸びる未経験エンジニア」の共通点
私自身、30代未経験の異業種からIT業界へ飛び込みました。
当時は生成AIなどなく、分厚い技術書と格闘し、自宅に中古サーバーを置いて夜中までパケットを飛ばし、泥臭く失敗を繰り返しながらネットワークスペシャリストや情報処理安全確保支援士、PMPを取得してきました。
その経験があるからこそ断言できます。
AIは、未経験エンジニアにとって 「史上最強の武器」 です。昔なら数日かかっていた環境構築や文法理解が、数時間で完了します。AIを使いこなす若手の成長速度は、従来の5倍から10倍に達します。
AIを排除する必要はまったくありません。差がつくのは、ツールの使い方です。
① AIに対する認識の違い
- ❌ 伸び悩む人: AIを単なる「カンニングペーパー（答えの丸写し）」にする
- ⭕ 劇的に伸びる人: AIを「24時間いつでも質問できる専属メンター」として使い倒す
② エラーに遭遇したときのアクション
- ❌ 伸び悩む人: エラー文をそのまま投げて、出てきた答えを何も考えずにコピペする
- ⭕ 劇的に伸びる人: 「自分はここが原因だと思うがどうか？」と仮説をぶつけて妥当性を検証させる
③ トラブル解決後の行動
- ❌ 伸び悩む人: エラーが解消して動いたら、「なぜ直ったか」を追わずに終わる
- ⭕ 劇的に伸びる人: 動いた後に「なぜこれで解決したのか」をAIに解説させて仕組みを自分のものにする
④ ツールが使えない状況への適応力
- ❌ 伸び悩む人: 外部ツールやネットが止まると手足が完全に止まる
- ⭕ 劇的に伸びる人: 基礎の物理モデルを頭の中に持ち、AIをあくまで道具として操る
本当に伸びるエンジニアは、AIに思考を委託しません。
AIを使って「自分の思考のスピードと深さ」を加速させています。
おわりに：時代が変わっても、エンジニアの本質は変わらない
「昔の先輩の役割」は、答えを知っている人でした。マニュアルのありかを知っていて、トラブルの解法を暗記している人が優秀とされました。
しかし、知識の検索をAIが肩代わりしてくれる現代において、リーダーの役割は大きく変わりました。
今のリーダーに求められているのは、 「答えを教えること」ではなく、「良質な問いの立て方と、仮説の検証プロセスを教えること」 です。
自分の頭でうんうん唸りながら仮説を立て、コマンドを打ち込み、通信がパッと通った瞬間のあの胸の高鳴り。
「あ、自分の仮説が当たった！」という感動こそが、エンジニアという職業の最大の醍醐味だと私は信じています。
どれだけテクノロジーが進化しても、その純粋な知的好奇心と考える楽しさだけは、次の世代のエンジニアから奪わずに手渡していきたい。
画面の向こうで悩むチームメンバーの背中を見ながら、私はそう考えています。
LEE
SIチーム管理職
2024年よりSIチームの管理職に従事。技術とマネジメントの両立をモットーに、現場のリアルな知見を発信しています。趣味は車とガジェット。