Google Workspace Studioの主な管理者向け機能 まずは、Google Workspace管理者がWorkspace Studioに対して制御できる項目を一覧で整理します。

はじめに こんにちは。技術戦略部CTOブロックの ikkou です。ZOZOでは毎年、独自の新卒研修を実施しています。さらに昨年からは、日本CTO協会の新卒エンジニア合同研修にも参加しています。参加は任意として、興味を持つ研修を自身で選択できるようにしました。本年度は2名の新卒エンジニアが参加しました。本記事では参加者によるレポートをお伝えします。 目次 はじめに 目次 日本CTO協会の新卒エンジニア合同研修とは 第1回：関係の質を上げるファシリテーション 第2回：Google Cloudで実現するクラウドネイティブ・アーキテクチャ 第3回：エンジニアの働き方とキャリア論 第4回：Codexを使った開発 第5回：GMOペパボによるサーバー解体研修 第6回：Alibaba Cloudから学ぶクラウドの基礎 第7回：合同ISUCON研修 印象に残った学び 業務・キャリアに活かしたいこと まとめ 日本CTO協会の新卒エンジニア合同研修とは 日本CTO協会は、企業の技術責任者が集まり、日本のDX（デジタルトランスフォーメーション）とCX（コーポレートトランスフォーメーション）の推進を目指す団体です。新卒エンジニア合同研修は、その会員企業の新卒エンジニアを対象とした取り組みで、2024年度に始まり、今年で3年目を迎えました。1社では用意しきれない学びの機会を企業の枠を越えて持ち寄り、業界全体で新卒を育てるという趣旨の研修です。 2026年度は全7回で、回ごとに異なる会員企業が講義を担当し、会場もその企業のオフィスへと変わります。扱われた領域は、ファシリテーションからクラウド、キャリア、コーディングエージェント、物理サーバー、パフォーマンスチューニングまで多岐にわたりました。参加者は各社の新卒エンジニア約100名で、講義だけでなくグループワークや懇親会を通じて他社の同期と交流できるのも、この研修の特徴です。 第1回：関係の質を上げるファシリテーション 第1回は北島が担当いたします！　今回は、株式会社メンバーズさんの神尾武志さんによる「関係の質を上げる」ためのファシリテーションを学ぶ講義で、最後にグループワークを実践するという研修でした。 ファシリテーションとは「人々の活動が容易にできるよう支援し、うまくことが運ぶよう舵取りすること」と定義されています。そのために必要なのが参加者同士の関係の質、つまり心理的安全性や相互理解です。この土台を作るのがファシリテーターの役割だという話でした。 具体的な立ち回りとして「伝える・場を見る・働きかける」の3つが紹介されました。 まず「伝える」では、参加者はファシリテーターより情報が少ない状態でその場に来ます。はじめにアジェンダ・趣旨・ゴールを伝えて心の準備をしてもらうことで、参加者が安心して場へ入れるようになります。途中でまとめを挟んで「今どこにいるか」を共有するのも、透明性を保つための大切な作法です。 次に「場を見る」では、参加者同士が議題を介して自走できているかを観察します。うまくいっていないなら介入し、回っているなら手を引く。どちらの判断も「働きかけ」であり、ファシリテーターが場全体を俯瞰して舵取りする姿勢が関係の質を守ります。 最後に「働きかける」では、問いの設計と仕組みの設計が肝でした。「質問ありませんか？」は答えにくく、「どちらかといえば？」「一言だけ感想を」のようにクローズな問いや小さな問いから入るほうが参加しやすくなります。発言しない人に対しても「やる気がない」と捉えるのではなく、事前に書いてもらう、その場で書く時間を取るなど、場の設計で引き出せるという視点は新鮮でした。 グループワークは「懇親会でもっとお互いを知りたくなる自己紹介を作る」がテーマでした。 私のグループは「話したいエピソードを選んで話す」というお題にし、私はファシリテーターを担当しました。 エンジニアならではのエピソードを中心に、お題を自由に選べる形式にしました。その結果、心理的安全性が保たれ、相互理解も自然に進みました。共通点が見えた瞬間に場の雰囲気はぐっと変わり、ファシリテーションの効果を実感しました。 第2回：Google Cloudで実現するクラウドネイティブ・アーキテクチャ 第2回も北島が担当いたします！　今回は、Google Cloudさんによる「次世代のクラウドネイティブ・アーキテクチャ」をテーマにした講義でした。 コンピュートは仮想マシン → コンテナ → サーバーレスという流れで進化しており、今の新規開発ならCloud Runが主流だという話でした。コンテナを渡すだけでデプロイでき、アクセスがなければ料金もかかりません。このシンプルさが強みです。 データベースもAI目線で見ると選び方が変わってきていて、ベクトル検索に対応しているAlloyDB（PostgreSQL互換の高性能版）が今注目されているとのことでした。 その流れで出てきたデータ基盤の話に、最も関心を引かれました。「統合・品質・可読性」の3条件が揃っていないと、AIエージェントは正しく動かないという話でした。散在データを集めて正確にし、人間とエージェントの双方が理解できる形にします。SREが「信頼性」と向き合うときの考え方と同じだと感じました。 こうしたデータ基盤の上に乗るのがGeminiです。テキスト・画像・動画をまとめて処理できるマルチモーダル性が他社との違いで、さらにGemini Roboticsとして映像・音声・物理動作を統合した身体性AIへの展開も紹介されていました。AIが「考える」から「動く」へ変わっていく様子には、少しゾクっとしました。 全体を通して伝わってきたのは、Google Cloudの強みがデータ基盤とGeminiを同じプラットフォームでつなげられる点にあり、AI活用の本質は技術より先にデータを整えることにあるということです。 懇親会ではGoogleのサービスに関するクイズがありました。結果は100人中9位でした。 第3回：エンジニアの働き方とキャリア論 第3回は、佐藤が担当いたします！　今回は、株式会社LayerX代表取締役CTOの松本勇気さんによる発表でした。テーマはエンジニアの働き方とキャリアです。ご自身の経験を交えながら、「キャリアを投資として考える」「フォロワーシップとマネジメント」「LLM時代のエンジニアのキャリア論」という三部構成でお話を伺いました。 第一部のテーマは、キャリアを投資家の視点で捉えるという考え方です。自分が持っている時間、体力、知識、経験、信用、これらはすべて資産であり、キャリアとはその資産を運用し続けるプロセスだと説明されました。そうであれば、投資と同じようにバランスシートやポートフォリオを意識できるはずです。手元の資産をどこへ配分し、どんなリターンを期待するのかを常に考える、という発想です。 興味深かったのは、リスクの取り方についての話です。大きな挑戦にはレバレッジが効く一方で、当然ながら失敗する可能性もあります。しかし、その経験自体も知識として蓄積され、次の判断の精度を上げてくれます。何もしないという選択にもリスクとリターンがある、という指摘には考えさせられました。もう1つ強調されていたのが、周囲のコミュニティです。友人、一緒に働く上司や同僚、社外のエンジニアコミュニティなど、どのような人たちと時間を共にするかが、そのまま自分の成長につながります。コミュニティを充実させること自体が、資産を増やすための投資の1つだといえます。 第二部では、チーム開発とマネジメントについての話がありました。そもそも、なぜチームで開発するのでしょうか。1人で開発すれば意思決定は速く、他人への配慮も要らないため、効率のよい面もあります。それでもチームを組むのは、大規模なものを作るには人数が必要だからです。1人では視点や考慮も不足します。そのうえでチームの効率を落とさないために欠かせないのが、マネジメントだと説明されました。 ここで出てきたのがフォロワーシップという考え方です。マネージャーも完璧ではありません。だからこそメンバー側から自己開示をしたり、自分の考えを言語化して伝えたりすることで、マネージャーが動きやすい状況を作れます。マネジメントされるのを待つのではなく、こちらからも働きかけていくという姿勢です。この話は個人的にとても面白く聞きました。マネジメントは上司から一方通行で受け取るものだと思っていたのですが、実際にはメンバー側からフォロワーシップという形で応えられます。働くうえで自分たちが楽しいと感じられる状態を作るために、こちらから動く余地があるという視点は、これまで持っていなかったものです。 第三部のテーマは、LLMの登場によってエンジニアのキャリアがどう変わるのかです。結論として示されたのは、デザイナーやエンジニアといった職種の垣根が今後どんどん低くなるという見立てでした。LLMを使って設計からデザイン、実装までを一人で担います。そうした働き方が当たり前になっていくという話です。ここで出てきたキーワードがAI builderです。LayerXでは、この言葉を実際に使っているそうです。 では、新卒は何をすればよいのでしょうか。挙げられていたのは、まず師匠を探すことでした。ロールモデルになる人や、優秀だと思える上司の近くで学ぶ価値は大きいという話です。もう1つが、軸をずらして戦うという戦略です。経理とエンジニアリング、営業とエンジニアリングのように、本来は別々だった職種を掛け合わせて自分の立ち位置を作るという考え方です。掛け合わせが差別化になるという指摘は、今後のキャリアを考えるうえで役に立ちそうだと感じました。 第4回：Codexを使った開発 第4回も佐藤が担当いたします！　今回はオンラインでの開催で、OpenAIでCodexの開発に携わる方による講義でした。前半はCodexの使い方の解説、後半は実際にCodexでアプリを作るハンズオンという構成です。 はじめに扱われたのが、コンテキストとは何かという話でした。コンテキストはエージェントのワーキングメモリであり、そこに何をどれだけ載せるかがエージェントの振る舞いを決めます。コンテキストウィンドウには限りがあるため、必要な情報を必要なだけ渡す設計が重要です。あわせて、SkillsとMCPが何を担うものなのか、両者の違いについても解説がありました。 講義でとくに時間が割かれていたのが、Skillsの作成です。面白かったのは、スキルを作るためのスキルが用意されている点でした。作りたい処理の要件をエージェントと対話しながら整理し、改善を重ねて1つのスキルに落とし込んでいきます。手続きを頭の中に置いたまま毎回プロンプトで説明するのではなく、繰り返す作業をスキルとして切り出していく進め方です。さらに、他の人が使っているスキルを自分のCodexでもそのまま動かせるように環境を整える、という話もありました。個人の工夫で終わらせず、チームで共有できる資産にしていく発想です。 複数のエージェントを並行して動かす場合は、それぞれに必要な処理をどう組み込むかが課題になります。ここで紹介されたのが、ツールを実行するタイミングの設定でした。ある処理の前に動かすもの、後に動かすもの、セッションの開始時に動かすものといった設定を組み合わせることで、エージェントが動く土台そのものを設計できます。いわゆるハーネスエンジニアリングにあたる考え方だと理解しました。 登壇者が強調されていたのが、Auto-reviewの機能です。Codexでは、エージェントが操作できる範囲を定めるサンドボックスと、範囲外の操作をする際の承認方法を組み合わせて設定できます。通常の設定では、ワークスペース内の一般的な操作はそのまま実行でき、設定された境界を越える場合に人間へ承認を求めます。Auto-reviewを有効にすると、こうした承認要求の一部を別のレビューエージェントが審査し、その判定に応じて実行を制御します。人間が逐一確認する手間を減らしつつ、無制限に権限を渡すリスクも避けられる仕組みだといえます。このほかにも、デフォルトの設定の考え方、プランモードの使い方、画像を渡した開発の進め方など、実践的なTipsを数多く紹介いただきました。 講義の後半は、実際にCodexを使ったアプリ開発です。私は、自社のキャラクター（箱猫マックスくん）を題材にしたポモドーロタイマーの拡張機能を作りました。作業と休憩の時間を管理するシンプルなツールです。 驚いたのは、そのスピードでした。作りたいものの要件を伝えてから、動くところまでこぎつけるのにかかった時間は10分ほどです。完成したものが次の画面で、集中する時間をカウントダウンし、残り時間に応じてキャラクターがバーの上を進んでいきます。 この規模のアプリケーションであれば、思いついたその場で形にして試せます。わざわざ作るまでもないと諦めていたアイデアも、まず動かしてから判断できるようになります。手元の道具をこうして気軽に作れるという感覚は、講義を聞くだけでは得られないものでした。 普段からコーディングエージェントは使っていましたが、開発している当人から設計の意図を聞けたのは貴重な機会でした。エージェントにどこまで任せ、どこを人間が握るのかの線引きを、権限の設定という具体的な形で考えられるようになったのが一番の収穫です。 第5回：GMOペパボによるサーバー解体研修 第5回は北島が担当いたします！　今回は、GMOペパボさんによる物理サーバーの話でした。 クラウド全盛の今でも物理サーバーには独自の強みがあるという話は、新鮮に感じられました。コストはクラウドより安く抑えられ、メガクラウドや為替レートにも左右されません。クラウドやAIであっても「末端は物理ハードで動いている」という言葉には、強く納得しました。デジタルガジェットとして楽しい、という言い方も好きでした。 ただ管理の大変さも正直に話していただきました。ラッキングやケーブリング、部品交換、温湿度・入退室管理、深夜のトラブル対応など、クラウドなら画面の操作で済むところが、すべて自前になります。スペック選定もシビアで、買ったら変更できない分、過剰でも不足でも損をします。寿命も3〜5年で、老朽化したら計画的なリプレースとデータ移行が必要になるという話をしていただきました。 その話を聞いた後で、実際にサーバーを解体する体験がありました。CPU、ECCメモリ、ストレージ、マザーボード、冗長電源、NIC、冷却ファン、そしてOSが止まっていても遠隔操作できるリモート管理カード（iLO・iDRAC）まで、構成要素を一通り手で触りました。話で聞いていた「管理が大変」の意味が、実物を目の前にすると一気に腑に落ちました。 普段はKubernetesやクラウドの抽象レイヤーの上で仕事をしているので、こうして物理を触る機会はなかなかありません。重さがあり、熱を持ち、騒音も出します。そうした実体のあるコンピューターと向き合うと、インフラへの解像度は一段上がった気がしました。 第6回：Alibaba Cloudから学ぶクラウドの基礎 第6回は佐藤が担当いたします！　今回のテーマはAlibaba Cloudです。中国の巨大ECを運営するアリババグループ傘下のクラウド事業会社が提供するパブリッククラウドサービスです。欧米含めグローバルに30リージョン・104のアベイラビリティゾーンを展開しており、アジア太平洋地域では1位、世界では4位という立ち位置にあると紹介されました。中でも特にアジア市場に集中的に投資をしており、中国をはじめとするアジア市場との結びつきが強いのも特徴といえます。講義はクラウドの基礎から始まり、後半はAI時代に向けたクラウドの話へと進んでいきました。 まず扱われたのが、クラウドとオンプレミスの違いです。自社でサーバーや機器を購入して設置、管理するのがオンプレミス、プロバイダーが管理するインフラをネットワーク越しに借りるのがクラウドという整理でした。クラウドのメリットとしては、負荷に応じてリソースを増減できるスケーラビリティと、使った分だけ支払えばよいコスト効率が挙げられます。 面白かったのは、この違いを会計の視点から捉え直す話です。オンプレミスはサーバーという資産を購入するため、初期に大きな投資が発生します。これがCapEx、資本的支出です。対してクラウドは月々の利用料として支払うため、発生した期に費用として計上されます。こちらがOpEx、運用費用にあたります。CapExでは、ピーク時の負荷を事前に予測して設備を購入しなければなりません。予測が外れれば過剰投資になり、逆に足りなければ機会損失につながります。OpExであれば需要に応じてコストが変動するため、事業の変化に追従しやすくなります。クラウドが選ばれる理由を技術面だけでなく経営面から説明されると、腹落ちの度合いが違いました。 続いて、どこまでをプロバイダーに任せるかによる分類、クラウドサービスモデルの話です。まずは、仮想マシンやネットワークなどインフラ環境を提供するIaaSがあります。そのうえに、アプリケーションの実行基盤まで用意するPaaS、アプリケーションそのものを提供するSaaSと続きます。プロバイダーに任せる範囲が広がるほど、利用者が管理する範囲は狭くなります。さらに近年は、AIの大規模モデルをサービスとして利用できるMaaS（Model as a Service）も加わってきているという話がありました。クラウドの分類そのものが、AIの登場によって更新されつつあるということだと理解しました。 構成の話として紹介されたのが、ハイブリッドクラウドとマルチクラウドです。ハイブリッドクラウドは、パブリッククラウドとプライベートクラウドやオンプレミスを組み合わせる構成を指します。一方のマルチクラウドは、AWSとGoogle Cloudのように複数のパブリッククラウドを組み合わせる構成です。ベンダーロックインを避けられる、それぞれの強みを活かせるといった利点がある反面、運用や監視が各クラウドで異なるため複雑になるという課題もあります。この話は、自分の業務と結びつけて聞けました。ZOZOでも複数のクラウドを併用しており、普段はその上で開発をしています。当たり前のものとして使っていた構成に名前と理由がついた感覚です。なぜこうなっているのかを考える良いきっかけになりました。 講義の終盤で取り上げられたAIとセキュリティの話には、特に興味を引かれました。AIの普及によって、必要な電力量やリクエストの量が急増し、AIのためのデータ基盤も求められるようになっています。そうした変化のなかで、AI時代のクラウドのセキュリティをどう担保するかに力を入れているという話でした。インフラや資源に強みを持つからこそ描ける展望があるのだと感じました。 第7回：合同ISUCON研修 第7回は北島が担当いたします！　今回は株式会社PR TIMESさんによるISUCON研修 *1 です。Webアプリケーションのパフォーマンスチューニングに取り組みました。チーム戦ではなく個人戦で、AIをどう活用できるかが問われる内容でした。 GETのインデックス最適化、DBのJOIN最適化、POSTの非同期処理と順番にチューニングし、結果は90人中7位でした。スコアが上がるたびに手応えはありましたが、40万点あたりで完全に詰まってしまい、1位の60万点には遠く及びませんでした。 壁にぶつかって気づいたのが、「計測が先、最適化は後」とするべき順番を逆にやっていたということです。アクセスログを集計してどのエンドポイントが遅いかを可視化し、スロークエリを洗い出してからボトルネックを潰していくという順番が正解です。自分は「これが遅そう」という勘で先に手を動かしていました。やったこと自体は間違いではありませんが、どこに時間を使うべきかが見えていないままでした。 AIの使い方も、同じ話でした。後半で引き出しが尽きてきたとき「なんか遅い気がするんだけどどうすればいい？」のような質問をしてもスコアはまったく伸びませんでした。AIは事実ベースで動くため、感覚を渡しても答えは出てきません。「このエンドポイントのレイテンシが〇ms出ている、原因として何が考えられる？」という具体的な数字があってはじめて、有効な回答が返ってきます。 裏を返せば、わからないことやぼんやりした概念はそのままにせず、AIに聞いて解消してしまうのが一番いい使い方です。AIには納得がいくまで質問でき、聞けばすぐ答えてくれます。ぼんやりしたまま放置する理由はありません。事実をつかみ、わからないことをなくしていくのがAI時代の学び方だと思いました。 印象に残った学び 全7回を振り返ると、扱われた領域はキャリアからインフラ、AIまで幅広いものでした。それでも通して聞くと、回をまたいでつながる話がいくつもあります。2人に共通して印象に残ったのは、次の3つです。 1つ目は、AIとの向き合い方が具体的な設計の問題として語られていたことです。第4回では、コマンドの実行権限をどう設定するか、どのタイミングでどのツールを動かすかという形で、エージェントが動く土台そのものを設計する話がありました。第7回では、感覚を投げても答えは返ってこず、具体的な数字を渡してはじめて有効な回答が得られるという経験をしました。第3回で出てきたAI builderという言葉も、AIを前提に自分の仕事の範囲を引き直す姿勢を指しています。AIを使いこなすというと、うまい指示を出す技術の話に聞こえがちです。しかし研修を通して見えてきたのは、どこまでを任せ、何を渡し、どこで人間が判断するのかを決める設計の話でした。 2つ目は、抽象化されたレイヤーの下には実体があるということです。第5回のサーバー解体は、普段の開発では意識しない層に触れる機会でした。第2回と第6回でクラウドの話を聞いた後だったこともあり、抽象化されたサービスの下には物理的な実体があるという当たり前の事実を、実感を伴って理解できました。第6回で出てきたCapExとOpExの話も、同じ方向を向いています。クラウドを使うというのは、本来自分たちが抱えるはずだったコストとリスクを、誰かに預けるという判断です。何が抽象化されているのかを知っていれば、預けている範囲も、自分たちが引き受けるべき範囲も見えてきます。 3つ目は、場や関係性も設計できるという視点です。第1回のファシリテーションと第3回のフォロワーシップは、扱っている題材こそ違うものの、根っこは同じでした。参加者が発言しないのは、やる気がないからではなく場の設計に理由があるのかもしれません。マネジメントがうまく回らないのは、マネージャーだけの問題ではなくメンバー側から働きかける余地があるのかもしれません。どちらも、目の前の状況を所与のものとして受け取らず、自分の側から設計できると捉える見方です。チームで働くとき、技術と同じくらい実践的な考え方だといえます。 業務・キャリアに活かしたいこと 私たちは配属されたチームが異なり、日々向き合っている技術も違います。それでも研修を終えて、共通して持ち帰りたいと考えたことが3つありました。 1つ目は、計測を先に置くことです。第7回で痛感したとおり、勘を頼りに手を動かしても、どこに時間を使うべきかは見えてきません。改善の施策を考える前に、何が起きているのかを数字で押さえることが重要です。当たり前でありながら、忙しくなるほど飛ばしてしまいがちな手順だと反省しました。 2つ目は、エージェントに任せる範囲の設計です。日々の開発でコーディングエージェントを使う場面は増えていますが、その多くは個人の工夫にとどまっています。繰り返す作業をスキルとして切り出し、チームで共有できる形にしていくことは、今すぐ始められる改善だと感じました。 3つ目は、チームへの働きかけです。ミーティングの進行や他チームとの相談の場面で、自分から場を作れるようになりたいと考えています。関係の質が土台にあるという第1回の話は、そのまま日々の仕事に持ち込めるものでした。 キャリアという長い時間軸で見ると、第3回の軸をずらして戦うという話が心に残っています。新卒の今は、複数の領域を掛け合わせられる場所に自分を置いていくための資産を積む時期なのだと考えています。 まとめ 全7回を終えて振り返ると、扱う領域は毎回まったく違っていたにもかかわらず、繰り返し語られていた話題があります。AIによって仕事がどう変わるのか、という問いです。 各回で語られていたのは、たとえば次のような話です。 職種の垣根は低くなり、1人が担える範囲は広がっていく エージェントに任せる範囲を決め、動く土台を整えることが仕事になる データが整っていなければAIは力を発揮できない 感覚ではなく事実を渡してはじめて、有効な答えが返ってくる それぞれ別の会社の、別のテーマの講義でしたが、いずれも同じ変化を違う角度から説明しているように聞こえました。 共通していたのは、AIが人の仕事を奪うという語り口ではなかったことです。むしろ、手を動かす部分をAIが担えるようになったからこそ、何を任せて何を自分で判断するのかを決める仕事の比重が増していくという見立てでした。新卒としては不安を覚えてもおかしくないテーマですが、研修を終えた今は、自分から動かせる余地の大きさのほうを強く感じています。 そしてもう1つ、この研修ならではの価値が、他社の同期と過ごす時間でした。同じ年に社会人となった人たちが、それぞれ違う環境で何を考えているのかを知ることができました。グループワークや懇親会で交わした会話は、講義とは別の刺激になりました。来年以降に参加する方にも、ぜひこの時間を楽しんでもらえたらと思います。 ZOZOでは、新卒・中途に限らず、一緒にサービスを作り上げてくれる方を募集中です。ご興味ある方は以下のリンクからぜひご応募ください。 corp.zozo.com *1 : 「ISUCON」は、さくらインターネット株式会社の商標または登録商標です。

こんにちは。スタメンでCTOしております、ちゃんたく ( @tnir / @takuya_stmn ) です。 先日7月12日にTUNAGプロダクトは10周年を迎えました。（2026-07-12 14:41 JSTコミット） 2016年7月12日git init 私たちは当社主幹プロダクトであるTUNAGの日々の開発にGitHubをフル活用しており、コードの品質とセキュリティを高く保つための取り組みを継続しています。 その一環として、最近GA（一般提供）されたGitHubのネイティブなコードスキャンツールであるCodeQL-powered analysis for Code Qualityを導入し、高度なコードセキュリティ機能をフル活用しています。そのコア技術となっているCodeQLのおかげで、脆弱性の早期発見が可能になり、より安全なプロダクト開発が実現できるように設計しています。 しかし、CodeQLを運用していく中で、とある大きな「壁」にぶつかりました。 今回は、10年以上の歴史を持つリポジトリに約8年間潜んでいたレガシーコードを発見・分離し、実行時間を平均20分から3分へと短縮した取り組みをご紹介します。 課題：長すぎるCodeQLの実行時間（平均20分）とセキュリティ上のリスク CodeQLは非常に強力なツールですが、私たちのメインリポジトリで実行すると、完了するまでに平均で約20分もかかってしまっていました。 20分という時間は、CI/CDパイプラインにおいて致命的です。Pull Requestを作成してから結果が出るまで長時間待たされるため、開発者のフィードバックループが遅延し、開発体験（DX）の著しい低下を招いていました。 さらに重大な問題として、平均20分も時間がかかると、Pull RequestにおけるCIステータスのクオリティゲート（必須ワークフロー）として組み込むことができないという点がありました。マージのたびに20分待たせる運用は現実的ではなかったためです。 その結果、高度なコードセキュリティ機能を導入したものの、 CI/CDプロセス自体はセキュリティ対策として脆弱な状態（危険なコードのマージをCIでブロックできない状態） のまま運用せざるを得ないという本末転倒な状況に陥っていました。 私たちのリポジトリは10年以上にわたって運用されてきた歴史があり、コードベースの肥大化は認識していましたが、セキュリティクオリティゲートを正常に機能させるためにも、この20分という実行時間は絶対に解決すべき課題でした。 Datadog CI/CD Optimization (CI/CD Explorer) を用いた GitHub Code Quality (CodeQLパート) の実行時間分析 原因の特定：導入者は不在…しかし「Gitの歴史」が答えを教えてくれた なぜこれほどまでに時間がかかっているのか、解析のログや対象ファイルを詳細に調査しました。 しかし、調査対象となったコードは、現在在籍しているエンジニアやマネージャーの誰も背景を知らないブラックボックスと化していました。大昔に導入されたものであり、当時の関係者はすでに社内に一人も残っていなかったためです。 ここで力を発揮したのが、すべての変更履歴を正確に記録し続けていたGitでした。 Gitのコミット履歴やそのblameを遡って調査した結果、約8年前にサードパーティーから購入し、リポジトリ内に配備された 「管理画面用のUIライブラリ」 が原因であることが判明しました。一般的な社内エンジニアが実装したJSライブラリやビジネスロジックではなく、静的ファイルとしてリポジトリ内に鎮座し続けていたベンダー製のコードでした。 CodeQLは律儀にこの約8年間放置されていた外部ライブラリの隅々まで脆弱性スキャンを行っていました。私たちが日常的に手を加えることのない古いベンダーコードの解析に、CIの貴重な時間を大量に奪われていました。 解決策：235 MBに及ぶコードの切り出しと別リポジトリでの分離運用 原因が特定できれば、やるべき方針は明確でした。 今回特定されたサードパーティー製ライブラリは、コードの分量が約100 MBにも及ぶ非常に巨大なものでした。これほど大規模なコードを、メインプロダクトの単一リポジトリ内で維持し続ける必要性はありません。 あえてモノリシックに維持するのではなく、メインプロダクトとは明確に 「ライフサイクルの異なるソフトウェア」として、意図的に別リポジトリへ切り出して独立管理するのが適切である と判断しました。 そこで、メインリポジトリからはこの100 MBのUIライブラリを完全に削除し、別リポジトリとして独立させて異なるライフサイクルで管理する施策を実行しました。 驚きの結果とセキュリティクオリティゲートの実現 この235 MBのレガシーコードをメインリポジトリから削除した結果、CodeQLの実行時間は平均20分から「3分」へと劇的に短縮されました！ 実行時間が3分になったことで、CodeQLをPull Requestの必須クオリティゲートとして正式に設定可能となり、セキュリティリスクを抱えたコードがマージされるのをCI上で確実にブロックできるようになりました。 開発者のフィードバックループ（DX）が飛躍的に向上しただけでなく、CI/CDパイプライン全体のセキュリティ強度を真の意味で高めることができました。 ビルドパイプライン ビルドパイプラインは創業時の2016年7月よりRuby on Railsに付属のSprocketsベースのアセットビルドを利用していました。7年強続いたアセットパイプラインを2023年秋に見直していたため、Yarn+esbuildによる実装に修正するプロジェクトがあり、そこから3年ほどはアプリケーションレイヤーのフロントエンドアセットパイプラインを問題なく維持運用していました。 なお、ベースとなるサードパーティー製ライブラリはgulpが設定されていましたが、当該プロダクトへの導入時点よりwebpackでのビルドとして開発されていました。この点はフロントエンドパイプラインをモダナイズする上ではとても助かる点でした。 Bootstrap 4ベースのUIライブラリ 今回切り出した「サードパーティー製ライブラリ」はBootstrap 4.0.0 (alpha) ベースであり、かなりレガシーでした。筆者自身は5年以上前からBootstrap 5.0、そして、最新の5.3に関わるまで1ユーザーでもあるものの、Tailwind CSS v4.3（執筆時の最新バージョン）ベースに切り替えるプロジェクトを未着手のまま温めている状況です。 当該ページ群を使うユーザーはTUNAG全体の大規模なユーザーベースと比べると少ないのですが、いつかはやらなくてはならないタスクだと認識しており、LLMを使って一気に対処してくれるエンジニアを継続募集しています。 読者の皆様へのTakeaway（持ち帰り知識） 今回の私たちの経験から、皆さんの開発現場でも活かせるポイントをまとめました。 CI実行時間の短縮は「セキュリティクオリティゲート化」の絶対条件 セキュリティスキャンツール（SAST）を導入しても、実行時間が長いとPRの必須チェックに設定できず、セキュリティプロセスが形骸化・脆弱化してしまいます。「スキャンを高速化し、必須クオリティゲートとしてCIに組み込むこと」こそが、堅牢なCI/CDセキュリティを実現する鍵となります。 ライフサイクルが異なる巨大コードは別リポジトリへ分離する 200 MBを大幅に超える巨大なサードパーティー製ライブラリをメインリポジトリに含め続けると、静的解析やビルド時間のボトルネックになります。プロダクト本体とライフサイクルが異なるソフトウェアは、あえて同一リポジトリで維持せず、別リポジトリとして分離・運用することがアーキテクチャ上も有効です。 Gitの履歴は属人化したナレッジを救う最強のドキュメント 当時の担当者が一人も残っていない状況でも、Gitの履歴がしっかり残っていれば「いつ・なぜ・何が導入されたのか」を正確に突き止めることができます。歴史あるリポジトリの調査において、Gitのログを辿る重要性を再確認しました。 おわりに CodeQL-powered analysis for Code Qualityは、スキャン対象を最適化しプロジェクトの構成を適切に保つことで、本来の優れたパフォーマンスを発揮してくれます。 10年以上の歴史があるリポジトリでも、適切な棚卸しとアーキテクチャの見直しを行えば、DXとセキュリティの両立は十分に可能です。もし「CIが遅くて必須化できない」とお悩みの場合は、リポジトリ内に長年鎮座している外部コードや分離可能なモジュールがないか、ぜひ探してみてください！ また、われわれと一緒にレガシーアプリケーションの継続的モダナイズをしたいエンジニアを募集しています。詳しくは当社採用サイトをご覧ください。