はじめに
新卒エンジニア研修を担当しました、ugo、yukyan、てつを、どすこい、haruotsuです！
2026年度も新たな新卒エンジニアを迎え、講師陣一同で研修を実施しました。本記事では、各研修を設計・実施した講師陣が、カリキュラムの設計意図や工夫、実施の様子を紹介します。新卒エンジニア研修の設計に携わる方々の参考になれば幸いです。ぜひ最後までご覧ください。
- はじめに
- 2026年度新卒エンジニア研修概要
- Webアプリケーション研修(バックエンド)
- フロントエンド研修
- モデリング/設計研修
- インフラ/仮想化研修
- SRE研修
- セキュリティ研修
- 機械学習＆データエンジニアリング研修
- おわりに
2026年度新卒エンジニア研修概要
今年の新卒エンジニア研修は「Agentic Engineering時代における作り上げる力」をテーマに、次の3つを目的として設計しました。
- 自分が何を知らないかを知り、自律的に学び続けられる状態になる
- 配属後すぐに事業インパクトを出せる助走をつける
- AIを前提とした技術選定・判断・実装ができ、顧客体験まで考えられるようになる
AIがコードを書いてくれる時代だからこそ、専門職としてのエンジニアとなることを重視しました。 AIの出力の表面をなぞるのではなく、背後の技術体系を理解し実践していること。 将来の事業価値に、開発がどのように結びつくのか議論できること。 リリースした先の運用まで責任を持てること。AIが速く賢くなっても、説明責任と運用責任は人間が引き受けるものだと考えました。
こうした狙いのもと、Webアプリケーション開発を足掛かりとしました。そのうえで、AIエージェントを用いた開発で重要となるもの、AIエージェントを組み込んだサービス開発で重要となるものを基準に、研修の単元を選定しました。
各研修は次の順で実施しました。
| 実施順 | 研修 | 日数 | 担当 |
|---|---|---|---|
| 1 | Webアプリケーション研修(バックエンド) | 5.5日 | harachan、shiorin |
| 2 | フロントエンド研修 | 4日 | nacal、てつを |
| 3 | モデリング/設計研修 | 3日 | donokun、はらちゃん |
| 4 | インフラ/仮想化研修 | 9日 | drumato、homirun、n01e0 |
| 5 | SRE研修 | 5日 | pochy、homirun |
| 6 | セキュリティ研修 | 2日 | n01e0 |
| 7 | 機械学習＆データエンジニアリング研修 | 2日 | miyakey |
去年の新卒エンジニア研修について気になる方は、目指せシニアエンジニア！2025年度新卒エンジニア研修資料を一部公開しますもぜひご覧ください。
ここからは各研修の講師陣が、それぞれのカリキュラムを紹介します。
Webアプリケーション研修(バックエンド)
- 担当: harachan、shiorin
Webアプリケーション研修(バックエンド)は、新卒エンジニア研修の一番最初のステップとして、harachanとshiorinで担当しました。この研修でまず体感してもらいたかったことは3つあります。
- Webアプリケーションを1から作る際にどんな言葉が出てきて何が行われているのかという「索引(インデックス)」を持つこと
- チーム・複数人で開発を進めるとはどういうことかを知ること
- AIとともにチーム開発を円滑に進める方法を考えること
「MVC」「マイグレーション」「セッション」といった言葉を全く知らない状態から、聞いたときに「ああ、あの辺りの話か」となんとなく思い浮かぶ状態までいければ十分、というくらいの解像度を目指しました。索引を先に持っておけば、その先の研修や配属後に実際に必要になったタイミングで、自分で調べにいけるはずだと考えたためです。
題材にはRuby on Railsを選びました。20年分のWeb開発のベストプラクティスが型として詰まっているためです。そのRailsチュートリアルを5.5営業日(昨年からおよそ半分に圧縮した日数)で完走することを、受講者全員が満たすべき要件としてセットしました。ただ内容の理解が置き去りにならないよう、Claude Codeとともに実装を進めながらPRを立ててもらいました。そのPRをまず受講者同士でレビューし、そのあと講師である私たちがレビューする、という2段階の体制をとりました。
受講者同士のレビューでは、誰かと一緒にPRを返しながら開発を進めるとはどういうことか、レビューではどんな観点を見るとよいか、そしてレビューにおける責任を実感してもらうことを狙いました。講師レビューでは、AIがただコードを書いて動いただけの状態にならないよう、「このパターンだったらどうなる？」「どうしてこの実装になっているんだろう？」と問いを投げて理解を深めてもらいました。同時に、普段の業務でどんな観点・コメントの仕方でレビューしているかを見て学び取ってもらうことも意識しました。
受講者同士でPRレビューを進めている様子
実際にやってみると、8名それぞれが自分の実装を進めながら、レビューという新しいタスクにも同時に向き合うことになり、そのバランスの取り方に苦戦する様子が見られました。
一番最初に受ける研修だからこそ、与えられた要件を甘く見ずにマストとして完遂する姿勢は、配属後の実務でも重要になると考えました。そこで研修の後半に一度立ち止まってもらい、受講者同士だけで相談する時間を設けました。講師はあえて入らず、残りの日数で完走するにはどうすればいいか、「完走」を具体的にどこに置くか、全員がその要件を満たすにはどうすればいいかを考えてもらいました。伝えた要件は、Railsチュートリアルの最後の章まで到達し、そこで作る機能がすべて動くようにすること、そして冒頭に掲げていたインデックスを少しでも貼れる状態にすることの2つです。
受講者たちが自分たちで考え直した進め方を、講師陣は「無理のない計画か」「要件を満たしているか」という観点を中心にレビューしました。残りの少ない日数で本当にやり切れるのか、不安に思っている部分は一緒に解消していきました。特に「インデックスを貼れる状態にする」という抽象的な要件は、何を満たせば達成と言えるのかを受講者側と講師側ですり合わせました。そうやってお互いに「これならいける」と思える状態を作ったうえで、残りの日数を進めてもらいました。
受講者たちが集まって見積もり会を行っている様子
この相談の中では、受講者たちから「PRを通じて講師側が身につけてほしいと考えていたスキルはもう掴めたので、ここから先は進捗を優先してレビューを任意にしたい」という提案がありました。当初必須としていた相互レビューについて、求められていたことの本質を自分たちで言語化し、それを踏まえて講師陣と交渉して合意を得て運用を変えたのです。マネージャーなど要件を出した相手と優先順位や認識をすり合わせ、説得して合意を得るという実務そのものの動きを研修の中で経験できていて、講師としてもとても嬉しい出来事でした。
その結果、全員が昨年の半分の日数である5.5営業日でRailsチュートリアルを完走できました。何より大きかったのは、受け身だった空気が「どうすれば達成できるか」を自分たちで考える能動的なマインドに変わったことです。講師があえて手を引いて、受講者同士で考える時間を作ったことが効いていました。講師側が進め方を決めすぎず、受講者自身に委ねたほうが、双方にとって良い結果につながる。この研修を通して、そういう気づきを得られました。最終日には振り返り会も開き、次の研修にどう向き合うといいかまで自分たちで考えられるようになっていました。新卒エンジニア研修に最終日まで一緒に取り組む「チーム」として、能動的に立ち向かう一歩を踏み出せたと感じています。
Webアプリケーション研修を担当したharachanとshiorin
Rubyコミュニティに触れるきっかけをつくるため、5/21に開催されたRailsTokyo#4へ、受講者全員で参加しました。業務時間扱いで参加し、社内外のRubyistと交流する時間も持てました。「コミュニティへ参加する楽しさ」を体感してもらう一歩になったと考えています。
AIと一緒に開発を進められる時代だからこそ、要件を自分ごととして捉えてチームでやり切る経験を、配属前の早い段階でしてもらえたことには大きな意味がありました。この研修で掴んだ「まずは自分たちで考え抜く」感覚を、今後の研修や実際の業務でも活かしてもらえれば嬉しいです。
フロントエンド研修
- 担当: nacal、てつを
今年のフロントエンド研修は「最高のフロントエンド」について考えてもらうことをテーマとし、nacalとてつをの2名で、4日間実施しました。
研修全体のテーマとして「Agentic Engineering時代における作り上げる力」が置かれている中で、AIを活用すれば、ある程度動くフロントエンドは誰でも容易に実装できるようになってきています。その中でフロントエンドを実装するエンジニアとして、最高のプロダクトにするには何をすべきか、何を意識すべきかを考えてもらいます。その周辺知識を入り口に深く潜り込んでいくことを主な目的として、このテーマを設定しました。
具体的な研修内容としては、SUZURI APIを利用したECサイトのWebフロントエンドを実装してもらい、それぞれ工夫した点や意識したポイントについて発表してもらいました。
成果発表の一例。VLMにブラウザを操作させてUIをタスクベースで定量評価し、失敗タスクの分析をもとにAIが生成した添削付きの改善モック
受講者には、Webフロントエンド未経験の人もいました。それでも成果発表では、アクセシビリティやWeb Core Vitalsといった定量的な指標を自ら発見して評価項目とする人や、理想のUXから逆算して技術スタックを提案する人が現れました。それぞれが自分のアプローチで「最高のフロントエンド」を考えて実現するところまでやり切ってくれて、短い期間で横断的にフロントエンド領域の理解を深められたと感じています。
「最高のフロントエンド」に唯一の正解はありません。だからこそ、それぞれが自分なりの切り口で問いを立て、答えにたどり着くまで試行錯誤したこと自体が、フロントエンドに限らずどんな領域でも通用する財産になるはずです。
AIが「動くもの」を素早く生み出せるようになった今、その先の「最高とは何か」を自ら問い、技術で形にする力の価値は、これまで以上に高まっていくと考えています。この研修が、受講者それぞれにとって「最高のプロダクトとは何か」を追い求め続けるための出発点になれば嬉しいです。
モデリング/設計研修
- 担当: donokun、harachan
設計研修は、ペパボの新卒エンジニア研修で「設計」を独立したコンテンツとして扱う初めての試みです。donokunとharachanの2名で、3日間実施しました。
配属後の受講者には、コードを書く前に「何をどう変えるか」を文書にまとめ、レビューを通じて合意してから実装に進む、という仕事の進め方が待っています。はじめて「設計を書いてみて」と言われたとき、そもそも何を出せば設計と呼べるのかがわからない。この最初のつまずきをなくすことを研修の目的に置き、ゴールを「Webアプリケーションへの変更の提案を書け、その提案の良し悪しを判断し、レビューを受けて補強できる状態」と定めました。
研修は「書き方」「考え方・伝え方」の2章で構成しました。
「書き方」は、設計を表現する道具を身につける章です。静的な構成を表すC4モデルの抽象化レイヤと、動的な振る舞いを表す図（シーケンス図、状態遷移図、データフロー図）を学び、実際に図を描いて講師のフィードバックを受けます。
「考え方・伝え方」は、表現された設計の良し悪しを判断する章です。品質特性、なかでも変更容易性と複雑さの関係を学びます。Railsチュートリアルで作ったアプリケーションへの機能追加を題材に、提案を書いてレビューを受けて改稿するまでを実践します。
最終日には、受講者が機能追加の実現方式を複数案比較した提案ドキュメントを書き上げ、レビューを受けて改稿するところまで完走しました。実務で設計を任されたときに何を作ることが求められているのか、その像を持って配属に向かってもらえたはずです。
配属後、施策を任された際に、この研修で体験した「要件を抽出して設計書に落とし込む」経験が活かせたようで、スムーズに業務を行えたという嬉しいフィードバックもありました。
課題も見つかりました。演習中、コーディングエージェントの提示する知識や意見に受講者が振り回される、という場面があったのです。AIの出力を自分の評価軸で判断するには、各技術領域の知識がもう少し必要でした。設計研修をエンジニア研修の後半に配置する、演習の題材を実際のプロダクトに近づける、といった改善案を来年に引き継ぎます。
インフラ/仮想化研修
- 担当: drumato、homirun、n01e0
インフラ/仮想化研修は、2年間続いていたコンテナ研修をさらに拡大した、今年度から新しく設計された研修です。drumatoとhomirun、n01e0の3名で、9日間実施しました。
ソフトウェアエンジニアに求められる貢献のベースラインはAIによって引き上げられました。それぞれのエンジニアは自身の専門性と関心領域についてパフォーマンスを出すだけではなく、自身の価値を提供するまでの一連のサイクルを完遂する、そのためにパフォーマンスの領域を広げる力が求められています。
そこで、本研修の前提を 今日において、知とパフォーマンスの領域はAIによって広げられる とおきました。価値提供に関わるすべてのプロセスに関われるエンジニアとして、不必要にレベルを下げずにインフラ/仮想化技術を学ぶ内容です。
具体的には、以下のような内容を含む研修として実施されました。
- LinuxのNetwork namespaceを利用したネットワーク入門。VM上でNetwork namespaceを利用して仮想ホストを構築してもらいました。プロトコルキャプチャによるネットワークプロトコルの理解や、ルーティングの設定を体験してもらいました。
clone(2)を利用したミニマムなコンテナランタイム自作。受講者それぞれが好きな言語でコンテナランタイムを自作しながら、既存のコンテナランタイムと比較してもらいました。- Virtualization frameworkを利用したVM自作。コンテナ技術とのトレードオフを理解してもらうために、Virtualization frameworkを利用したVM作成を体験してもらいました。
- Kubernetesクラスタの思想と設計から学ぶ実運用の課題。ここまでの技術の整理として、ペパボで主に採用されているKubernetesを仕組みから理解してもらいました。そのうえで、実際のサービス運用における関心と課題を導入しました。
講義全体を通して意識したことは、技術書やWeb上の記事などで当たり前に解説されているこれらインフラ技術について考察してもらうということでした。「このような技術がないとどう困るだろうか」「この技術は何を解決し、どのような関心を持ち込んだか」といった観点です。AI時代において特に重要なのは課題抽出ができ、意図が説明できることです。この具体的なシミュレーションとして適切な題材だったと考えています。
研修後半では、受講者それぞれに作りたいものを考えてもらい、講師と議論しながら1つのレポートを完成させてもらいました。テーマはAIエージェント用のサンドボックス/ロードバランサ/eBPFイベントトレース/PyTorch Compiler/Gateway API Controller/楕円曲線暗号など多彩でした。それぞれの技術特性と解決される課題について議論できました。
SRE研修
- 担当: pochy、homirun
過去二年間「オブザーバビリティ研修」として続いた枠でしたが、今年は満を持して「SRE研修」と名付けました。
その内容は「障害対応100本ノック」としました。この節では、実施した内容と設計意図、その効果を記します。
障害対応100本ノックの概要
この研修では、受講者には5営業日の間、システムの管理者として障害対応をしつづけることを求めました。
この研修で実施したことを説明します。準備として講師は研修用のKubernetesクラスタを用意し、その上に3つのサービスを稼働させました。このとき、それぞれのサービスには主に可用性の観点で脆弱な実装やアーキテクチャを複数（100個）仕込みました。また、それぞれのサービスのソースコードを管理するリポジトリは用意したものの、リリースフローの自動化やIaCは不十分な状態としました。 研修初日に、受講者にそのクラスタへのadmin権限を与えました。講師は5営業日間、事前に仕込んだ障害が起きるようにシステムに負荷をかけ続けました。受講者には、比喩や誇張ではなく実際に100本の障害へ対応することを求めました。
この研修においてはロールプレイとして、受講者はそのシステムの管理者であるとしました。また、講師2名は、「Slackにはいるものの、たまたま2名とも遠くへ旅行に行っている」という設定にしました。すなわち、「詳しい人」は実際に作業できないが、「現場にいて権限がある人」がなんとかして障害へ対応しなければいけない、という状況設定です。
また、座学用のテキストも用意しました。ただ状況を与えるだけでは何をしたらいいか分からなくなる懸念があったので、リリース自動化や監視、可観測性の整備などに必要な知識はテキストファイルにして読める場所に配置しておきました。具体的にはArgoCD、GitHub Actions、Grafanaなどの技術要素と、それらが必要になる背景を読み物として執筆しました。
5営業日の最後の2時間程度は、ポストモーテムの時間としました。起きた障害に対して、何が起きていたのか、何がうまくいったか、次はどのようにしたらもっとうまくできるかを講師がファシリテーションしつつ受講者間で議論してもらいました。
設計意図
この研修は、ロールプレイによる実践を主として、SREのプラクティスをその身を以て学ぶことを目的としました。
研修設計を考える際に主にインスパイアされたのはAnthropicによるSREについての報告記事でした。曰く、複雑なシステムで根本原因を究明するためには「痛い目に遭う」必要があるとのことです。生成AI技術が全盛を極め続けるこの時代においては、知りたい技術や知識は湯水のように手に入ります。だからといって、SREで必要なトラブルシューティング能力がすぐさま手に入るわけではないと私は感じています。そこで、ひたすら「痛い目に遭う」ような研修を思いつきました。
3サービスは、講師がそれまでにペパボの中で運用を担当したサービスの中から、アーキテクチャが異なる3つを模したものにしました。様々なアーキテクチャのシステムに立ち向かえる能力を養うことと、実務ですぐに使える知識を獲得することがこの決定の目的です。
仕込んだ障害には、すべて過去にペパボの中で起きた障害の機序を使いました。ペパボの中ではポストモーテム文化が浸透しているため、過去の障害履歴を参照することが容易です。起こした障害の例は次のとおりです。
- 大量のN+1クエリによるレスポンス遅延
- キャッシュ戦略の不備による参照データの競合
- k8s podのliveness probeの瑕疵による可用性毀損
パフォーマンス問題やデータ不整合問題などさまざまなレイヤの問題を配置することによって、原因究明のために可観測性技術を習得しなければいけない状況を作りました。 受講者には研修が完了した後に、起きた障害はすべて過去のポストモーテムから引用したものであることを伝えました。自分たちの対応が実務に繋がるものだと伝えること、そしてペパボのポストモーテム文化を知ってもらうことを目的とした設計です。
リリースフローの自動化やIaCが不徹底な状態から取り組んでもらったのは、ソフトウェアの偉大さを感じてもらうためです。SREのプラクティスの1つに、トイルの解消があります。自動化が何もない状況で障害対応をしてもなかなか捗りません。そこで、最初に対応が遅くなったとしても少しずつ自動化を進めることで、時間のレバレッジによって最終的には多量の成果を出すことができる経験をしてもらいたいという意図を込めました。
受講者8名に対して3サービスを用意した意図は、実際の運用で頻発するコミュニケーションを実践してもらうためです。3サービスが与えられたことで、受講者は自然と3チームに分かれました。しかし3サービスはKubernetesクラスタやDBインスタンス、ArgoCDサーバーを共有する構成になっていました。すなわち、「複数サービスが共有しているリソースがボトルネックになる」事象が発生します。これによって、チーム間でどのようにコミュニケーションをとってボトルネックの解消に取り組むと効果が出やすいのか、あるいは出にくいのかを体感してもらえる研修になりました。ペパボのエンジニア組織が掲げるバリューの1つに「すべてが自分ごと」というフレーズがあります。担当サービスの外だからという理由で誰かが直してくれるのを祈っているだけでは何も解決しないので、どうにかして直そうとする姿勢が必要であると知る機会にしてほしいという意図も込めました。
効果
概ね、期待した効果が得られたのではないかと考えています。
講師として印象的だったのは、チーム間での越境の動きです。チーム分けは講師が明示したものではなく自然発生的にできたものではあるものの、一度決まったチームを越境することは心理的な負担が大きいと私は思っています。そのような中で、共有リソースがボトルネックだと見抜いてチューニングに取り組む動きや、あるアプリケーションでのチューニング方法を受講者間で共有する動きが見えました。これは頼もしかったです。また、講師がちらっと口に出した「推測するな、計測せよ」や「監視で気付けない障害が起きていたら負け」といったフレーズがふりかえりの際に受講者の口からも出てきたことは講師冥利に尽きるなあと思いました。
一方で、AI時代と言っても、5営業日で100本は多いということもわかりました。実際に解消された障害は50本程度で、他は検知されつつも直しきれなかったり、そもそも検知すらされない障害もありました。次からは50本ノックに調整してもよさそうです。
セキュリティ研修
- 担当: n01e0
今年もセキュリティ研修を担当しました。セキュリティ対策室のn01e0です。日程は色々あって2日間での開催となりました。昨年と大きな違いはありませんが密度が高くなっています。
期間が短い為、座学はほとんど設けず導入にとどめ、ほとんどの時間をハンズオンに費やしてもらいました。
セキュリティレビュー体験
初日は他のイベントも重なっており、作業時間があまり多く取れなかったため、セキュリティレビュー体験を行いました。 Webアプリケーション研修で作成したリポジトリに対し、事前に私が作成した脆弱性のある機能追加のPRをレビューしてもらいました。
今回は受講者が8人いる為、それぞれのリポジトリに対して異なる機能や様々な脆弱性を埋め込むのが講師としての課題でした。しかし研修目的だと言うと、Agentもすんなり受け入れて意図的な脆弱性を埋め込んでくれました。気を使ってくれたのか、指示していない・意図していない脆弱性もいくつか埋め込んでくれました。助かります。
セキュリティレビューはもちろんですが、コードレビューをする際、「どのような意思決定の結果、マージされるコードが出来上がったのか」が大事だと私は考えています。
そのため、今回の研修では「一度出したPRを修正するのが面倒なVibe Coder」として振る舞い、以下の点を明示してもらうようにしました。
- 具体的に脆弱性の原因となっているコード
- なぜそれが脆弱性となるのか
- どういったリスクがあるのか
- 悪用の可能性はあるのか
- どのように修正すれば良いのか
- どんなテストを追加すればよいのか
これは暗に「PRの裏に相手のCoding Agentがいる」という現状に合わせた内容でもあります。レビューでの指摘を具体的にするほど、相手のAgentにも具体的な指示を伝えられます。
脆弱性診断の体験
昨年に引き続き、Rails製の脆弱なやられアプリの脆弱性を発見・修正してもらうハンズオンです。
私が目指す脆弱性診断の民主化を意識し、ツールやテクニックは共有しつつ、受講者主体で動いてもらいました。 既にAgentの使い方が身についており、続々と大量の脆弱性を発見してくれます。教える事など無いんじゃないか？と感じる所ですが、先輩風を吹かせたいので頑張ります。
「XSSを見つけた」「LFIを見つけた」という所までは、Agentに簡単な指示を出すだけでもできます。しかし診断では「それらの脆弱性に最大でどういうリスクがあるのか」を理解・説明しなければなりません。そのうえで一般論でなく、今回のアプリケーションにおける具体的な攻撃を考えて、対応の優先度や方針を決めます。
「LFIで本来見えないはずのファイルが見える」で終わらせないことを意識してもらいました。「LFIで/proc/self/envを見るとDBのクレデンシャルが書いてある」「XSSで管理者アカウントのCookieを窃取できる」「マウントされたホストのディレクトリを操作できる」。こういった事を実際に動かしながら理解してもらえて良かったです。
機械学習＆データエンジニアリング研修
- 担当: miyakey
ペパボ研究所のmiyakeyです。機械学習＆データエンジニアリング研修として「AIエージェントを前提としたサービス設計と開発」を担当しました。
例年この研修では機械学習やAI活用の基礎知識を扱ってきましたが、今年はAIエージェントがサービス体験そのものを形づくり、開発プロセスの前提にもなりつつある状況を受けて内容を大きく組み替えました。狙いは、AIエージェントを「サービス体験の一部」として設計できること、そしてコーディングエージェントと協働しながら「何を作るか・何を満たすべきか」を自分たちで定義できることの2つです。AIから成果物を受け取るだけでなく、AIが投げかけてくる問いを受け取り、自分たちの判断基準を更新していける力を、設計と開発の両面から鍛えることを目的としました。
演習では、二人一組で「Webサービス内でユーザーまたは運用者を支援するAIエージェント機能を1つ設計・実装する」ことに取り組んでもらいました。作るものは完成度の高いアプリではなく、エージェントの振る舞いとその機序を説明できるプロトタイプです。設計にあたっては3つの要件を明示し、そのまま最終発表の評価軸としました。AIチャットや単純な自動化ではなくエージェントとして実現する理由があること（必然性）。Tool実行・状態保持・ワークフローとして実装可能であること（実現性）。どんな入力になぜそのToolを使い、なぜその応答になるのかを説明できること（了解性）です。「動くもの」はAIの力で誰でも作れる時代だからこそ、その振る舞いに必然性があり、機序を人間が説明できるかを問うことに重きを置いています。
実装は、Google Agent Development Kit（ADK）でToolを実装し、LM Studio上のローカルLLMに接続する制約を課しました。あえて手元のローカルモデルで動かすのは、強力なモデルなら雑な設計でもそれらしく動いてしまうためです。限られた性能で意図通りに動かそうとすると、Toolの切り分けや状態の持たせ方といった設計そのものと向き合わざるを得ません。エージェントの機序を自分の手で理解してもらううえで、この制約はよく効いたと感じています。
2日間の研修はDay1で設計とレビュー、Day2で実装・評価・発表という構成とし、「何を満たすべきか」を先に言語化する流れを体験してもらいました。最終発表では、設計と機序の理解を一緒に確かめました。短い期間ながら各チームが「この場面でこそエージェントが要る」という必然性を自分の言葉で説明し、ローカルLLMとToolで振る舞いを形にし、なぜそう動くのかを説明しきってくれました。この経験を、配属後のサービス開発でAIや機械学習を積極的に活用していく土台にしてもらえれば嬉しいです。
おわりに
2026年度の新卒エンジニア研修は、「Agentic Engineering時代における作り上げる力」をテーマに実施しました。AIとの開発が当たり前になった時代で求められる力を、各講師がそれぞれの領域で問い直すカリキュラムとなりました。
振り返ってみると、どの研修にも共通していたのは、AIの出力をそのまま受け取るのではなく、その背後にある技術体系や課題を自分の言葉で説明できることを受講者に求めていた点です。Railsチュートリアルを自分たちで計画を立て直して完走する、障害対応で「痛い目に遭う」、エージェントの振る舞いの必然性と機序を説明しきる。形は違えど、「動くものはAIが作れる。ではエンジニアは何に責任を持つのか」という問いに、受講者たちは正面から向き合ってくれました。
この記事が、新卒エンジニア研修の設計のヒントになれば幸いです。
