こんにちは。 アプリケーションサービス本部、DevOps担当の兼安です。 本記事はこちらの記事の続きです。 blog.serverworks.co.jp 前回、マルチAIコーディングエージェントにおける mcp.json の書き方の整理と、APIキーなどの環境変数化を行いました。 今回はそれに加えて、AIが環境変数を読み込まないようにする設定ができるかを調べました。 調査対象は前回同様、Kiro・Claude Code・GitHub Copilot Agent Mode で、Kiro については CLI/IDE の両方を調べています。 本記事のタイトルに「調査」とある通り、残念ながら直接的な読…

こんにちは！クロスイノベーション本部 AIトランスフォーメーションセンターの杉江です。 今回は、電通総研の「OJTリーダー制度」における半年間のOJT期間で、私が配属先で経験したことを紹介したいと思います。 先に公開された、私のOJTリーダーを担当してくださった村本さんの記事とあわせて読んでいただくと、OJTリーダー目線と新人目線で、同じOJT期間をどう捉えていたのかの違いも見えてくるかもしれません。 tech.dentsusoken.com 配属先について 新人教育制度の詳細は OJTリーダー側の振り返り記事 で説明されているので、ここでは私の配属先について軽く触れておきます。 私は新人研修後、AIトランスフォーメーションセンター（AITC）のAIコアソリューショングループに配属されました。概要は以下のとおりです。簡単にまとめると、 生成AIソリューション「Know Narrator（以下、KN）」の開発メンバーとして配属された ということです！ AITCは電通総研の中にあるAIに特化したプロジェクトチームになります。さらにAITCの中でもソリューション系グループ（ソリューションコア・ソリューションアプリ）とコンサルティンググループに分かれており、私と新入社員の方はソリューションコアグループに所属しています。ソリューション系グループでは、エンタープライズ向け生成AIソリューション「Know Narrator」の開発、魅力向上に向けた技術検証等を行っています。 Know Narratorは自社開発を行っているプロダクトになりますので、ソリューション系グループが連携しながら開発をしています。つまり、新入社員の方は開発チームの一員となり、プロダクト開発における様々なスキルを身に着けながら、プロダクトの魅力向上に貢献していくことが大きな目標となっていきます。 配属当初の自分と、半年後の自分 半年で取り組んだことを紹介する前に、配属当初の自分がどのような状態だったのか、そしてOJT期間を半年過ごした後にどう変わったのかを先に紹介したいと思います。 配属当初の自分 まず、配属当初の自分の状態について紹介します。 経歴 情報工学専攻の大学院卒 基本情報技術者試験：合格 わかっていたこと プログラミング ：大学の授業や研究を通じて、プログラミングの経験はある程度あった 不安だったこと クラウド ： AWSやAzure等をほとんど触ったことがない AI : ChatGPTやGitHub Copilotを使ったことがある程度 チーム開発 ： ちゃんと取り組んだのは新人研修が初めて こうして振り返ると、配属当初の自分は開発チームのメンバーとして、戦力になれる状態では全くありませんでした。 ただ、これは特別なことではなく、多くの新卒社員が似たような状態で配属されるのではないかと思います。 配属半年後の自分 半年後には、配属当初に感じていた不安がすべてなくなったわけではありませんが、少なくとも 「何もわからない状態」 からはかなり前に進めたと思います。不安だったポイントも以下のように変わりました。 不安だった点が、半年後にはどう変わったか クラウド ： Azureの資格を二つ取得 し、業務の中でもAzureの画面の簡単な操作ができるようになった。 AI : 生成AIソリューションの機能開発を担い 、普段の開発でもAIを活用している。また、 最新技術を調査してチームに共有 する経験を通して、理解を深めた。 チーム開発 ： 開発チームに本格的に入り、Know Narratorの主要機能の1つを 仕様整理から実装、テストまで一貫して主担当としてかかわり、周囲と連携しながらリリースに貢献できるようになった。 配属当初の自分が抱えていた不安は、半年のOJT期間を通じて、 実際に手を動かしながら少しずつ埋めていくことができました 。 具体的な取り組みとその感想 ここから、どのような取り組みを通じて成長できたかについて時系列で振り返っていきます。 10月〜11月：まずは0から作って学ぶ OJTリーダー側の振り返り記事 では、この時期の取り組みが次のように整理されています。これを踏まえて、自分でも振り返りたいと思います。 【主に取り組んだこと】 Know Narratorを1ユーザーとしていろいろ触って機能の理解を深める OJTリーダーが個別にタスクを指示し、新人はそのタスクを達成するための実装を行う 1からリポジトリを作り、環境を構築し、実装‧テストまで行う実装プロセスはKN開発を踏襲し、タスク分解→実装→テスト→コードレビューの流れで進める 【狙い、身に着けてほしいスキル】 「できた」という感覚を味わっていただくために、完全に0から始めて自力で少しずつ実装し簡単な生成AIアプリを作る KN開発でのお作法をこちらでも導入しながら進めることで、お作法になれるタスクの進め方や困ったときの相談など、OJTリーダーとの会話を通して慣れていただく実際に製品導入が予定されている機能の先駆け検証‧チーム共有を行うことで、チーム‧製品への貢献を感じていただく 共有時にどのように情報を整理すれば伝わるかなどをチーム内で経験する 10月〜11月は、製品開発に直接関わるというより、まずは Know Narratorがどのような製品なのかを知ることと、Know Narratorの開発環境で使われている技術のキャッチアップ を進めることに取り組みました。 まずKnow Narratorという製品を知るために、まずは実際にシステムを触ってみることから始めました。 ここでは、ユーザー目線で押せるボタンを一通り触り、何が起きるかを見たり、裏側でどう処理されているのか気になった点を日報に書いたりしながら進めました。当時は「新人に任せる仕事がないから、やっているのかな？」と思っていた部分もありました。しかし、開発に関わるシステムを理解するために非常に重要な時間だったと、今になって思います。 技術のキャッチアップでは、Gitのリポジトリを1から作り、簡単なAIチャットアプリを作りながら、開発で必要なAIや開発環境の知識、プログラミングのお作法などを学びます。 OJTリーダーから小さなタスクを一つずつもらい、対象の技術をキャッチアップしながら、実装、Pull Requestの作成、レビューという流れで進めました。 基本的にはまず自分なりに進め、その成果物に対してOJTリーダーの村本さんだけでなく、他の開発メンバーからもコメントやアドバイスをいただけたので、タスクを進めるたびに新しい気づきを得ることができました。 下図は実際に作っていたアプリです。 リポジトリを1から作ることのメリットは、リポジトリ内のすべてのコードを自分が把握している状態で進められることにあると感じました。既にプロジェクトとして時間が経っているチームに後から入ると、既存のコードを理解するのに大きな労力がかかります。また、開発環境の構築や設計のように、既に整備されている部分を自分で作る経験も得にくいと思います。 開発チームでは、コードフォーマッターやリンター、GitHubでPull Requestを出したときに動く自動テストやレビューなど、品質を保つための仕組みがいくつも整備されています。こうした仕組みについても、自分で1から構築したことで、のちに開発メンバーとして本格的に入ったときも、 「なんか勝手にいい感じに動いている」ではなく、裏側でどのような仕組みが動いているのかをイメージしやすく なりました。 また、キャッチアップと同時に、製品に今後導入予定だった技術の調査と検証を実施しました。検証では上記チャットアプリに技術を組み込み、そのノウハウをドキュメント化。開発チームに連携しました。 公式ドキュメントの内容をそのまままとめるだけではなく、気になったところを追加で調べたり、実際に動かしたコードを載せたりすることで、初めてチーム内で価値のあるドキュメントにできたと感じています。このとき作成したドキュメントが、その後の開発で他のメンバーの参考になったのは、自分にとってもうれしい経験でした。 この時期にAzureの基礎的な資格も二つ取得しました。とはいえ、資格だけでは業務にほとんど応用できないことを後々感じることが多かったです。来年以降は、作成したチャットアプリをAzure上でデプロイしてみてもいいかなとも思います。 11月〜1月：KN開発に入って感じた壁と、慣れるまで 11月の後半から1月について取り組んだことは以下のとおりです。（ OJTリーダー側の振り返り記事 から引用） 【主に取り組んだこと】 Know Narratorの開発環境を構築、環境構築手順資料の改善を行う Know Narratorでリリース前に行っているシナリオテスト行う軽微なバグの修正作業や、コードのリファクタリングを行う 社内で開催されていたAI Coding学習会に参加する 【狙い、身に着けてほしいスキル】 環境構築をしながら既存の環境構築資料をどう改善すればよりわかりやすくなるか考えていただく Know Narrator開発におけるタスクをこなしながら、チーム開発‧チームメンバーとのコミュニケーションに慣れる Know Narratorのコードベースに対する理解を深める 11月からは本格的に開発チームの一員として、タスクを進めることになりました。 まずはKnow Narratorを開発するための 環境構築 をしました。村本さんから、「わかりづらいドキュメントだなと不満に感じたら、次から入ってくる人も感じるところなのでガンガン直してくれたら嬉しい」みたいなことをよく言われていたので、実際にいくつか修正したり、自分で新しくドキュメントを作ったりもしました。 実際、二年目の先輩が昨年環境構築した際に残していたドキュメントに大変助けられたりしたので、 ドキュメントを残すことの重要性 や、足りなかったら自分で直すという意識づけがここで徹底できたかなと思います。 環境構築が終わった後に最初の大きなタスクとなったのが、 リファクタリング でした。 実は最初に取り組むはずだった機能開発を進めるにあたり、コードベース上にいくつかの課題があったのです。この課題を解決しないことには実装作業が進められないと判断され、リファクタリングをやってみましょうという流れになりました。 初めて本格的にやるタスクがリファクタリングということで、進め方など村本さんにかなりサポートはしてもらったものの、ここでだいぶ苦戦しました。 リファクタリングは外から見た動作を変えずに内部のソースコードを整理することなので、リファクタリングの影響範囲のコードがどう動いていて、どこに依存関係があるかを理解しないと前に進めません。製品の既存コードを理解するところが特に大変でした。 最初はかなり時間がかかりましたが、タスクを進めるうちに次第に理解するスピードが速くなり、なんとか進めていけました。結局、量を読むことが鍵でした（笑）。加えて、既存のコードベースが開発・保守しやすいようにきれいな階層で分けられていたため、それぞれの役割を理解し、処理の流れをイメージできるようになったことも大きかったです。 コードベースの設計思想については村本さんと1on1の時間で一度しっかりコミュニケーションをとって、自分の認識のズレや既存の設計でモヤモヤしていた点を解消できたのが大きかったです。 この経験から、 コードを読むだけでなく、人と話すことの重要性 を学びました。 また、この時期からリリース前の シナリオテスト も担当するようになりました。 シナリオテストはKnow Narratorの毎月のアップデート前に、意図する動作になっているかをチェックするために実際に触って確認するテストのことです。 シナリオテスト自体は特別面白い作業ではないですが、10月にKnow Narratorを触りまくったときと同じように、製品に対する理解が進みました。また、これまでのタスクではOJTリーダーの村本さんとのコミュニケーションが中心でしたが、テストを進める中で、テストを作成したメンバーや機能を開発したメンバーとやり取りする機会が増えました。パートナー会社の方や開発チームの他メンバーとも関わることができ、連携の幅を広げる良い機会になりました。 2月〜3月：自分が実装した機能のリリースを経験する 2-3月に取り組んだことは以下のとおりです。（ OJTリーダー側の振り返り記事 から引用） 【主に取り組んだこと】 継続してKnow Narrator開発の様々なタスクを担う Know Narratorとして大きなアップデート要素となりえる主要機能を作り切る 【狙い、身に着けてほしいスキル】 自分が実装した機能が製品に乗る喜びを味わっていただく大きな機能開発を通して、設計や実装、テストはもちろん、自身のタスク整理やコミュニケーションのリードを経験してもらうプロダクトオーナーやビジネスオーナーに対して、機能の開発状況や仕様について説明する経験をしていただく 2月・3月で新しく開発タスクとして行ったことは大きく分けて2つです。 Know Narratorで採用予定だった新技術のキャッチアップと動作確認 3月末のアップデートの機能の一つを仕様整理から開発・テストまでを一貫して行い、KNのアップデートに自分が作った機能を載せる まず一つ目の技術調査についてです。 11月でもすでに技術調査を行いましたが、2月の技術調査では、単に調査して手元で動かすだけでなく、Know Narratorのプロジェクト上でテストコードを実装し、 Know Narratorの環境でも実際に動作することを確認するまで をゴールとした検証を行いました。 手元で簡単に動かすのとは違って、既存のプロダクトコードを見ながら、使えるところは共通化して実装するところに、より難しさを感じました。また同時にIDEのデバッグモードを活用したデバッグについても学ぶことができました。 二つ目の機能開発についてです。 ここで感じたことは、二つあります。 一つ目は、機能の仕様を考えることは前提を考えるのとセットであることです。 最初に仕様を決める際に、仕様について開発チームの先輩に相談したところ、この機能が使われるときの前提条件があるはずだから、それを元に判断すれば良いというコメントをもらいました。 二つ目は、タスクを整理することの難しさです。 今までは割り当てられたタスクをこなす側であることがメインだった一方で、このタイミングでは、タスクを整理して作る側に回ることを経験しました。この点は村本さんにかなりサポートをしてもらって、タスクの切り分けの単位や、画面デザイン作成の依頼、一部実装のパートナー会社の方への依頼なども一緒に進めてもらえました。 一人では開発が進まず、先回りしてコミュニケーションを取りながら開発を進めることが重要だと感じました。 タスクの進め方には課題が多くありましたが、自分の開発した機能をOJT期間にリリースするところまで持っていけたので、自信にもつながりました。 チームとのコミュニケーション ここでは、OJT期間中に感じたチームとのコミュニケーションについて振り返ってみます。 開発部屋 私が所属するAITCの開発チームは、リモートワークがメインで、基本的に一日中 開発部屋 と呼ばれるTeamsのオンライン会議に入って開発を進めています。配属直後は、メンバー全員がいる場で声を出して質問することに少しためらいがありました。 ただ、慣れてくると、開発部屋にいることでどのメンバーが会話できるかがすぐにわかったり、会話を聞いていた他の先輩がプラスアルファでコメントをくれたりして、とても仕事のしやすい環境だと感じるようになりました。 開発部屋については別記事でも紹介されているので、気になる方は見てみてください。 tech.dentsusoken.com 1on1 10月の配属直後には、開発チームのメンバーと基本的に 対面で1on1 をする機会をいただきました。オンライン中心だとコミュニケーションが少しドライに感じることもありましたが、対面で話すことで人となりがわかり、とてもよかったです。 また、OJTリーダーの村本さんとは 隔週で1on1 をしていて、 日々の雑談から仕事の進め方で迷っているところの相談 までしていただき、とても助かりました。 新人用Teamsチャネル 10月から12月は、新人が基本的にTeamsの一つのチャネルを見るだけで必要な情報を得られるように、新人用チャネルを用意してもらっていました。 ここには、業務でよく参照するサイトのリンクや事務的な連絡、TODOリスト、気になることを質問できるスレッドなどが一つのチャネルにまとまっていて、 とりあえずこのチャネルを見れば大丈夫 という状態になっていました。 よく「〇〇サイトの\~~というページを開いてください」的なことを指示されると、どこを見ればよいか迷うこともありますが、このチャネルのおかげで「どうやって行くんだっけ」と探す手間はほぼなかったです。 同チャネルで日報の作成も行っていました。日報はYWTP形式（やったこと・わかったこと・次やること・問題）で書いていましたが、自分のW（わかったこと）やP（問題）に対して、OJTリーダー以外の方もフィードバックとアドバイスをいただけて、非常に助かりました。 日報はOJT期間が終わった後も、開発チーム内で同じ形式で実施していて、日々メンバーが考えていることや発見がわかったり、アドバイスをいただけたりして大変ありがたいです。 OJTリーダーとのやり取り 村本さんは実は関西支社の方で、東京にいる私とはオンラインでのコミュニケーションがメインでした。最初は少し驚きましたが、オンラインでも日々のチャットや1on1等でしっかりコミュニケーションを取っていただいたので、不満は全くありませんでした。やり方次第でどうにでもなるんだなと感じました。 10月から12月までは毎日村本さんと朝会をしていて、日報をもとに進捗確認やフィードバック、つまずいているところの相談等をしていました。 タスクを進める中で出る質問は開発部屋で行う形にしていました。ただ、村本さんが忙しくて開発部屋にいらっしゃらないことが多い時期は、進め方に少し苦労しました。他のメンバーの方は私のタスクを詳細に把握していないケースがあったため、手が止まってしまう時間もありました。 今振り返ると、自分がもっと他の先輩にも頼るようにコミュニケーションを取ればよかったと感じます。そのうえで、特定の一人に頼りきりにならない体制や、気軽に相談できる相手を増やしておくことも、受け入れをやりやすくするうえで大事だと思いました。 半年を振り返ってみて OJT期間半年を通して、開発チームのお荷物と勝手に感じてしまうような状態からは脱却できたかなと思っています。半年間で自分でも成長できたという実感があります。 OJT期間で私が恵まれていたと感じることは、 とにかくゆっくり自分が納得するまでやっていい というスタンスで見守ってもらえたことです。特に今は生成AIが発達しているので、理解せずとも形にできてしまう部分はあるのですが、自分の成長を優先してもらえたことで、技術力の向上につながり、精神的にもいい意味で楽な状態で半年間過ごすことができました。 OJTリーダー側の視点を受けて ここで、 OJTリーダー側 からはどう見えていたのかも振り返ります。 『「新人さん」ではなく「新しいメンバー」をチームで受け入れる』ことが、私のOJT期間のテーマ になっていたようです。 特に配属後の2〜3か月は、このスタンスを強く感じていました。オンボーディング中は、暗黙知を知らない立場だからこそ気づける点を踏まえて、チーム内ドキュメントの整備をしっかり任せてもらったり、やりづらいところを丁寧に聞いていただいたりしました。 そうしたやり取りを通じて、新人・ベテランに関わらず、これから新しく開発チームに加わる人に向けたオンボーディングの改善につなげようという意識を感じました。自分自身も、 オンボーディングの改善に貢献するという意味で責任感を持って取り組む ことができたので、オンボーディング中に感じるやりづらさも前向きに捉えられたような気がします。 こういった環境や自分の成長につながるタスクを用意してくださった村本さんはじめAITCの先輩方に感謝し、今後新しく入ってくるメンバーに対しては、自分が直近でオンボーディングを経験したメンバーとして力になりたいと考えています。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sugie.naoki レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは！ラクスのエンジニア採用担当です。 今回はラクスのエンジニア職のサマーインターン 「RAKUS Tech Lab」 を紹介します。 このインターンシップは、単にコードを書く体験ではありません。 チームで開発を進めながら、「何を作るべきか」から考えるプロセスを体験していただくプログラムです。 ラクスのエンジニアがどのようにプロダクト開発に向き合っているのか。 その一端を、3日間で感じていただけます。 インターンで大切にしている考えや、実際の流れ、参加いただいた方の声を紹介します。 ラクスが大切にしている「顧客志向」 インターンシップ「RAKUS Tech Lab」について 3日間の流れ Day1：顧客理解と開発スタート Day2：開発と改善の繰り返し Day3：成果のまとめと発表 RAKUS Tech Lab 2026 プログラム日程詳細 RAKUS Tech Labを通して得られる経験とスキル AI開発×顧客志向の開発体験 チームで成果を発揮する開発体験 実務に近いフィードバック 実際に参加した学生の声 インターンシップでお会いしましょう！ ラクスが大切にしている「顧客志向」 ラクスでは、開発を「機能を作ること」だけとは考えていません。 大切にしているのは、「誰のどんな課題を、なぜ解決するのか」を「顧客志向」を起点に考えることです。 （こちらの記事で実際の取り組みを紹介しています。） tech-blog.rakus.co.jp たとえば新しい機能を作るときも、 どのユーザーにとっての課題なのか その課題は本当に解くべきものなのか なぜその実装や設計を選ぶのか といった前提を整理したうえで、開発を進めていきます。 また、AIを活用した開発が広がる中で、 「速く作る」だけではなく、 AIの提案をそのまま使わずに検証すること なぜその実装にしたのかを説明できること も、重要な力だと考えています。 このインターンでは、こうした開発の考え方を実際に体験していただきます。 インターンシップ「RAKUS Tech Lab」について 4～5名のチームでWebアプリケーションの企画から実装までを行う、短期集中型の開発インターンです。 ラクスでは、Claude CodeやGitHub Copilot等のAI開発ツールを積極的に開発に取り入れています。 本プログラムでは、それらツールを使いながら、単に実装を進めるだけでなく、生成された内容を検証し、適切な意思決定を行う開発プロセスを体験していただけます。 開発中は、社員メンターがビジネス視点や設計思想についてフィードバックを行います。 技術力を高めるだけでなく、「ユーザーに使われるサービス」をどう生み出すか。 ラクスが実践する「AIを活用しながら、顧客課題に向き合い、意思決定する開発」を、持ち帰っていただけるプログラムです。 3日間の流れ Day1：顧客理解と開発スタート 顧客ヒアリングを実施し、チームで課題設定・方向性を決め、開発に着手します。 各チームに社員メンターがつき、方針や設計についてフィードバックを行います。 Day2：開発と改善の繰り返し 実装を進めながら、チームで議論し、必要に応じて方向性を見直します。 技術面だけでなく、価値や設計の妥当性についてもレビューを行います。 Day3：成果のまとめと発表 完成したアプリの発表を行います。 現役エンジニアから、実際の開発現場と同じ視点でフィードバックを受けていただきます。 RAKUS Tech Lab 2026 プログラム日程詳細 ■開催日程 　●東京①コース：8/5(水)、8/6(木)、8/7(金) 　●東京②コース：9/2(水)、9/3(木)、9/4(金) 　●大阪コース　：8/26(水)、8/27(木)、8/28(金) ■各日開催時間 　●1日目／10:00～18:00　オリエンテーション、チーム開発 　●2日目／10:00～18:00　チーム開発 　●3日目／10:00～18:00　チーム開発、成果発表、懇親会 RAKUS Tech Labを通して得られる経験とスキル AI開発×顧客志向の開発体験 単に実装を進めるのではなく、「何を作るべきか」「なぜその実装にするのか」を考えながら開発を進めます。AIツールも活用しつつ、生成された内容をそのまま使うのではなく、顧客視点に立って検証し、適切な選択を行います。 ラクスが大切にしている「AI開発と顧客志向を掛け合わせた開発」を体験いただきます。 チームで成果を発揮する開発体験 開発は個人で完結するものではなく、チームで進めていくものです。 ラクスではひとり一人が力を発揮し、チームに貢献することや互いに助け合うことを大切にしています。 本インターンでは、メンバー同士で議論しながら方針を決め、実装を進めていきます。 意見が分かれたり、進め方に迷う場面もありますが、 そうしたプロセスを通じて、チームで開発を進める難しさと面白さの両方を体験いただきます。 実務に近いフィードバック 開発中は、社員メンターが技術面だけでなく、設計や価値の観点からフィードバックを行います。「なぜこの実装にしたのか」 「他に選択肢はなかったのか」といった問いを通じて、実際の開発現場に近い視点を学ぶことができます。 実際に参加した学生の声 実際に参加いただいた方の声をご紹介します！ 国内最大級のエンジニア学生のデータベースを持つ株式会社サポーターズ社発表、「参加してよかったエンジニアサマーインターンシップランキング2025」TOP26位にランクインしました！ biz.supporterz.jp インターンシップでお会いしましょう！ RAKUS Tech Labでは、AIを活用しながら、顧客視点に立ち 「何を作るべきか」を考え、選択し、その理由を言語化する。 そんな開発の進め方に、向き合っていただきます。 実際の開発現場に近い環境で、ラクスのエンジニアの働き方もぜひ体感してください。 エントリーの詳細は以下からご覧いただけます。 https://rakus-newgraduate.snar.jp/jobboard/detail.aspx?id=lTWVvD66xME 少しでも興味を持っていただけた方は、ぜひご応募ください。 みなさんとお会いできることを楽しみにしています！