はじめに

こんにちは、KDDIアイレット株式会社の伊藤です。
2026年7月30日にGoogle Cloud Next Tokyo ’26に参加してきました。

本記事では、我が社のセキュリティ事業部門部長である廣山さんがスピーカーとして参加するJagu’e’r のセッション「コミュニティリーダーが語る、AI と働く時代のエンジニアの役割と育て方」を聞いてきました。

この記事はセッションのレポートではありません。話を聞きながら自分の中に浮かんだ問いと、それに対して今の自分なりに出した答えを書いてみたいと思います。生成 AI を毎日使って働いているエンジニアの一人として、耳が痛い話も、背中を押される話もあったからです。

「AI で作りました。どうでしょうか」に、ドキッとした

セッションで最初に刺さったのは、生成 AI の社内推進の話の中で出てきた、エピソードでした。AI に作らせたドキュメントを「AI で作りました。どうでしょうか」とそのままレビューに回してくる人がいる。確認してみると、内容が薄かったり、事実関係が間違っていたりする。

正直、ドキッとしました。そのままレビューに回すという極端なことはありませんが、AIの力を必要以上に信じ込み確認が薄くなってしまうといったような節がゼロとは言えないからです。

生成 AI を使うと、アウトプットが出てくるまでの時間は劇的に短くなります。問題は、その速さに「自分が内容に責任を持つまでの時間」が付いてきていないことだと思います。以前なら、資料を書き上げるまでの数時間の中で、自然と内容を吟味し、事実を確かめ、自分の言葉として消化していました。AI に任せると、その消化のプロセスごとスキップできてしまう。

聞きながら決めたのは、「レビューの第一号は常に自分」というルールを崩さない ことです。AI の出力を他人に渡す前に、自分が一番厳しいレビュアーとして読む。「AI が作ったから」は品質の説明にならない、むしろ「AI が作ったからこそ自分が全部確認した」と言える状態で渡す。速くなった分の時間は、次の作業ではなく、まずこの確認に充てるべきなのだと思います。

「AI を新入社員として育てる」という視点に、自分の仕事の変化を見た

もうひとつ印象的だったのは、「2025 年はできるだけ自分ではコードを書かない」という方針の話です。何を作るか、どんな仕様にするかを人間が考え、実装は AI に任せる。そして AI を単なるツールではなく、新入社員のような存在として捉え、育てていく——。

この「育てる」という言葉が、聞いた後もずっと頭に残っています。

振り返ると、自分が AI にうまく仕事を任せられたときは、いつも「新人に仕事を頼むときと同じこと」をしていました。背景と目的を伝える。参照すべき資料を渡す。期待するアウトプットの形を示す。一度でうまくいかなければ、指示の何が曖昧だったかを考えて直す。逆に、雑に投げて雑な結果が返ってきたときに AI のせいにするのは、新人に丸投げして「使えない」と言う上司と同じです。

だとすると、AI 時代に伸ばすべきスキルは、コーディングの速さそのものではなく、仕事を定義して任せる力 なのだと思います。仕様を言語化する力、良し悪しを判定する基準を先に決めておく力、失敗したときに指示側の問題を切り分ける力。これは今までマネージャーやテックリードに求められてきた能力で、それが全エンジニアに要求される時代になった、と捉えるのがしっくりきます。

自分への問いとしてはこうです。「この指示を新人に渡したら、期待どおりのものが返ってくるか?」 返ってこないと思うなら、それは AI に渡しても同じ。まず自分の指示を磨く。

「説明できるか」を、自分の学びの基準にする

セッションでは、AI にコードを書かせることについて、立場の異なる二つの意見が交わされていました。ひとつは「まずは一度、自分でコードを書いた経験があったほうがいい。トラブルが起きたとき、AI でも解決できず自分も仕組みを理解していなければ対処できない」という意見。もうひとつは、機械翻訳やコンパイラの歴史を引きながら「技術の抽象化によって、すべてを理解しなくても扱える人が増えることで社会全体の生産性は上がる。ただし、AI が作ったものについて、何のために作ったのか、どこを確認すべきかを説明できることが重要」という意見です。

一見対立しているようで、聞いているうちに、二つは同じ場所を指していると感じました。境界線は 「自分が説明責任を持てるかどうか」 です。

これは自分の学び方の戦略に、そのまま使える基準だと思いました。AI があらゆることを教えてくれる時代に、何をどこまで深く学ぶべきかは、正直ずっと悩んでいたテーマです。全部のレイヤーを極めるのは無理で、かといって全部 AI に任せると、トラブル時に手も足も出ない。

セッションを聞いて、自分の中で整理がつきました。

  • 自分が仕事で責任を負う領域は、「説明できる」深さまで学ぶ。 AI の出力に対して「なぜこの設計なのか」「どこが壊れやすいか」を語れる状態を保つ。そのためには、その領域の基礎は一度自分の手で作った経験が要る。
  • それ以外の領域は、遠慮なく抽象化の恩恵を受ける。 全部をアセンブリから理解する必要がないのと同じで、専門外の領域で AI に頼ることを恥じない。ただし「自分は説明できない領域を扱っている」という自覚だけは持つ。

言い換えると、「何を学ぶか」より先に 「どこで説明責任を持つ人間になるか」を決める。学びはそこから逆算する。これが自分なりの結論です。

AI に何でも聞ける時代に、それでも人と会う理由

セッション後半のテーマは、コミュニティの価値でした。AI に質問すれば大抵のことは教えてもらえる時代に、人と直接会って話す意味はあるのか。

セッションで語られていた答えは明快で、「AI に聞いたことより、人から聞いたことのほうが記憶に残っている」「コミュニティは教える側と教わる側に分かれる場所ではなく、お互いに与え合う場所」というものでした。中でも面白かったのが、M-1 グランプリになぞらえて仕事上の失敗談を共有する社内企画をやった、という話です。失敗を隠すのではなく、失敗した人がその経験を共有することで、同じ失敗をする人を減らせる。しかも面白い。

これを聞いて、AI と人の情報の違いが自分の中で言語化できました。AI が返してくれるのは、世の中に書かれたことの要約。人が話してくれるのは、まだどこにも書かれていないこと です。特に失敗談は、体裁を整えた事例記事からは削ぎ落とされがちで、当事者の口からしか聞けません。そして自分の経験上、本当に役に立つのはいつも失敗談のほうです。

もうひとつ、役職や経験が上がるほど「こんなことも知らないのかと思われたくない」という心理が働く、という指摘にも心当たりがありました。AI の登場は、実はこの問題への救いにもなっていて、初歩的な質問は AI に聞けば恥をかかずに済みます。でも、だからこそ人に会ったときには、AI には聞けないこと——生々しい失敗、判断に迷った話、うまくいかなかった取り組み——を話すべきなのだと思います。自分から失敗談を差し出せる人でいたい。それが、AI 時代のコミュニティへの参加の作法なのかもしれません。

産業革命の現場で、自分はどう働くか

セッションの締めくくりで、今を「産業革命と呼べるような時代」と表現し、「その大きな変化のタイミングに立ち会えているのは、とても幸せなこと」という言葉がありました。

変化の速さに疲れを感じる日もありますが、この捉え方は素直にいいなと思いました。蒸気機関の時代に立ち会った人たちが歴史の教科書に載っているように、今この瞬間の試行錯誤も、いつか「あの転換期」として振り返られるのかもしれません。だったら、傍観者ではなく当事者でいたい。

最後に、セッションを聞いて決めた自分の行動指針をまとめておきます。

  1. AI の出力のレビュー第一号は自分。 「AI が作ったから」を品質の説明にしない。
  2. AI への指示は新人への依頼のつもりで書く。 うまくいかないときは、まず自分の指示を疑う。
  3. 説明責任を持つ領域を決め、そこは手を動かして学ぶ。 それ以外は抽象化の恩恵を堂々と受ける。
  4. 人に会ったら、AI に聞けないことを話す。 特に失敗談は、隠さず差し出す。

AI と働く時代のエンジニア像に、完成された正解はまだないのだと思います。ただ、このセッションで語られていたのは、突き詰めれば「AI が速くしてくれた分、人間は責任と理解と、人とのつながりに時間を使おう」ということでした。自分もその方向で、AI と一緒に成長していきたいと思います。