
はじめに
前半の記事では、新卒合同研修の第1回から第3回までの内容をご紹介しました。 前半の記事もぜひご覧ください!
後半となる本記事では、第4回から第6回の講義についてお伝えします!
後半の研修は、より実践的な内容が盛りだくさんでした。実際にサーバーを解体してハードウェアの仕組みを学んだり、ISUCON形式でパフォーマンスチューニングに挑戦したり、最新の生成AI技術について学んだりと、エンジニアとして知っておきたい幅広い知識を身につけることができました。
それでは、各回の内容を見ていきましょう!
6/4開催 4回目 サーバー解体研修
こんにちは、開発1部 デリッシュキッチンAWG PUの黒髙です。私の方からはGMOぺパボ株式会社様に主催していただいた「サーバー解体研修」について紹介します。
GMOインターネットグループ株式会社様の会場提供により、GMO Yoursで開催されました。
サーバー基礎講座
前半は、デル・テクノロジーズ株式会社の福田さんに「サーバー基礎講座」と題して、大きく以下三つの内容を講義していただきました。
- サーバーの基礎 - パソコンが「個人」で使うことを想定しているのに対し、サーバーは「みんな」で使うことを前提としており、24時間365日の連続稼働や高い信頼性が求められる、といったお話でした。
- サーバーの構造 - CPU, DRAM, SSD/HDD, NICといった各構成部品の説明。データの正確性を保つECCメモリや、ストレージの冗長化を実現するRAID構成など、サーバーならではの部品についても学びました。
- サーバーならではの付加機能 - PowerEdgeサーバーのリモート管理ツールであるiDRAC(integrated Dell Remote Access Controller)について解説いただきました。
私が特に興味深かったのは、サーバーがいかに「停止しないこと」を重視して設計されているかという点です。電源や冷却ファンの冗長化、リモートでの管理機能など、すべてがサービスの継続性を支えるための工夫であり、普段利用しているPCとの設計思想の根本的な違いを理解することができました。
このように事前にハードウェアの知識をインプットしたことで、より一層「サーバーの内部を見てみたい」という気持ちが高まりました。
サーバー解体作業
続いて、研修の目玉である後半のサーバー解体についてレポートしていきます。 会場にはサーバーが複数台用意されており、任意のチームに分かれてそれぞれ解体を進めていきました。

こちらが私たちのチームで解体していくサーバーになります。データセンターのラックに効率的に搭載するため、一般的なタワー型PCよりも横向きに細長い「ラックマウント型」と呼ばれる形状をしています。この一台で軽自動車が買えるほどの値段がすると聞いた時は、大変驚きました。
まずは天板を外します。CPU、メモリ、電源ユニットなど、基本的なパーツ構成は通常のPCと同じですが、各パーツの信頼性や拡張性は大きく異なっていました。例えば、電源ユニットは二重化されており、片方が故障してもサーバーは停止しません。また、冷却ファンが多数搭載されている様子からも、高性能なパーツを安定して動かす強力な冷却性能が見てとれます。

各チームのサーバーはそれぞれ構成が異なっており、私たちのものは特にメモリの搭載量が多いモデルでした。GPUを搭載しているチームもあったようで、少し羨ましかったのを覚えています。
解体作業に特定のマニュアルはなく、各メンバーが「これは何だろう?」と興味の赴くままに、ときには協力し合いながら進めていきました。 その結果、以下のように多くのパーツを取り出すことができました。

工具を使わない範囲での解体だったため限界はありましたが、裏を返せば、交換頻度の高いメモリやストレージなどのパーツは、専門的な技術者でなくても簡単に扱えるよう設計されていることもわかりました。
復元作業とメンテナンス性
さらに、ここから元の状態に戻す「復元作業」も行います。 目に入ったものを次々と取り出していく解体作業よりも、パーツを取り付ける順序などを考慮する必要があるため、少し身構えました。 しかし、実際にはそこまで難しくありませんでした。各パーツは所定の場所にしか収まらないように工夫されており、メンバーと確認しながら作業を進めることで、意外とすぐに元の状態に戻すことができました。
この一連の作業を通して、サーバーがいかにメンテナンス性を考慮して設計されているかを実感しました。実際に、このサーバーのストレージ(HDD/SSD)や電源はホットプラグ(サーバーの電源を入れたまま部品の交換ができる仕組み)に対応しているというお話を聞き、まさに常時稼働が求められるサーバーならではの特徴だと感じました。
HDDの解体
懇親会では、特別にHDDの解体もさせていただきました。HDDは、プラッタ(データを記録する円盤)とヘッド(データを読み書きする部分)の隙間が数ナノメートルと非常に狭く、空気中の微細な塵が付着するだけでも壊れてしまうため、このHDDが再び動くことはありません。普段目にすることのできない精密な内部構造に、思わず見入ってしまいました。

普段触れることのできないハードウェアにたくさん触れることができ、とても貴重な体験でした!
まとめ
AWSなどクラウドサービスの利用が当たり前になり、私たちにとってサーバーはより抽象的な存在になりつつあります。しかし、物理的なサーバーの仕組みを理解することは、クラウド上で発生するパフォーマンスの問題や障害に対して、より深いレベルでの洞察を与えてくれます。 そのため、今回得られたハードウェアの知識は、インフラの設計や障害対応など、より低いレイヤーを扱う際に必ず役に立つと感じました。
もはやクラウドを採用するのが当たり前のようになっている昨今ですが、サービスの特性やコスト、セキュリティ要件といった運用のユースケースに応じて柔軟なインフラ選択が求められます。その中で、自社でサーバーを持つオンプレミスも、必要に応じて選択肢に入れるべきだと感じました。
6/11開催 5回目 ISUCON研修
開発1部 デリッシュキッチンMS DRMの鈴木です。私からはISUCON研修の紹介をします。
ISUCONとは、「いい感じに スピードアップ コンテスト」の略称で、お題となるWebサービスを決められたレギュレーションの中でどれだけ高速化できるかを競う大会のことです。
今回のISUCON研修では、本番のISUCONのようにチームで与えられた問題に取り組む形式で行われました。
事前準備
私はISUCON初挑戦だったのですが、事前にISUCON出場経験のある先輩にISUCONでよく使われるツールやテクニックに関する知見を共有して頂きました。
ツールとしては以下のようなものがあり、研修当日に活用しました。
- pt-query-digest
- slowqueryの解析に使うツール
- mysqlのログを解析してsqlが遅い順に表示される
- alp
- NGINXのアクセスログの解析に使うツール
- 遅いエンドポイント順に表示される
研修当日
Step 0: 準備 - Gitでのコード管理
本格的な改修を始める前に、まずEC2インスタンス上にあったコードをGit管理下に置き、GitHubリポジトリにプッシュしました。これにより、変更履歴の追跡や、問題発生時の切り戻しが容易になり、安心して作業を進めるための基盤が整いました。
Step 1: N+1クエリの特定と解消 - DB負荷の最大の原因を叩く
課題
アプリケーションの動作を分析したところ、トップページを表示するだけでデータベースに大量のクエリが発行されていることが判明しました。これは、投稿の一覧を表示するループ処理の中で、投稿ごと・コメントごとに個別のSQLクエリを発行してしまう、典型的な「N+1クエリ問題」でした。
分析
問題となっていたのは、app.goのmakePosts関数です。以下のように、forループの中で都度DBアクセスが発生していました。
// 問題のあったコード(抜粋) for _, p := range results { // ループごとにコメント数やユーザー情報を取得していた db.Get(&p.CommentCount, "SELECT COUNT(*) FROM `comments` WHERE `post_id` = ?", p.ID) db.Select(&comments, "SELECT * FROM `comments` WHERE `post_id` = ?", p.ID) // ... }
解決策
ループの外側で、必要なデータを一度にまとめて取得する方式に変更しました。
- 表示対象となる投稿のIDをすべて集める。
- SQLの
IN句を使い、関連するコメント情報やユーザー情報を一括で取得する。 - 取得したデータをGoの
mapに格納する。 - ループの中ではDBにアクセスせず、
mapからデータを参照して構造を組み立てる。
この修正により、発行されるクエリ数は、投稿数に関わらず一定(数回)にまで激減しました。
Step 2: データベースインデックスの追加 - 検索速度の向上
課題
N+1問題を解決した後、次にpt-query-digestを使ってスロークエリログを分析したところ、特定のクエリが依然として遅いことがわかりました。特にORDER BY created_at DESCによるソート処理がテーブル全体をスキャン(フルテーブルスキャン)しており、大きなボトルネックとなっていました。
解決策
パフォーマンスを改善するため、以下のインデックスをデータベースに追加しました。
-- トップページの投稿一覧表示を高速化 CREATE INDEX idx_posts_created_at ON posts (created_at); -- ユーザーページの投稿一覧表示を高速化 CREATE INDEX idx_posts_user_id_created_at ON posts (user_id, created_at); -- コメント一覧の取得を高速化 CREATE INDEX idx_comments_post_id_created_at ON comments (post_id, created_at);
これにより、検索やソートがインデックスを使って効率的に行われるようになり、クエリの実行速度が大幅に向上しました。
Step 3: 高コストな外部コマンド呼び出しの排除 - CPU負荷の削減
課題
CPU使用率を調査する中で、ユーザー登録やログイン時に呼ばれるパスワードのハッシュ化処理がボトルネックとなっている可能性が浮上しました。コードを確認すると、exec.Commandを使って外部のopensslコマンドを呼び出していました。
// 修正前の digest 関数 func digest(src string) string { out, err := exec.Command("/bin/bash", "-c", `... | openssl dgst -sha512 | ...`).Output() // ... }
外部プロセスの起動は非常に高コストな処理です。
解決策
この処理を、Goの標準ライブラリcrypto/sha512を使って、Goのプロセス内で完結するように書き換えました。
// 修正後の digest 関数 import ( "crypto/sha512" "encoding/hex" ) func digest(src string) string { hasher := sha512.New() hasher.Write([]byte(src)) return hex.EncodeToString(hasher.Sum(nil)) }
この修正により、プロセス起動のオーバーヘッドがなくなり、CPU負荷を大幅に削減できました。
Step 4: ページネーションによるデータ取得の効率化
課題
主要なボトルネックを解消していくと、それまで隠れていた新たな問題が見えてきました。トップページでは20件の投稿を表示しているにもかかわらず、SQLでは全件の投稿データを取得しており、無駄な処理が行われていました。
解決策
トップページの投稿を取得するクエリにLIMIT 20を追加しました。
-- 修正前 SELECT `id`, `user_id`, `body`, `mime`, `created_at` FROM `posts` ORDER BY `created_at` DESC -- 修正後 SELECT `id`, `user_id`, `body`, `mime`, `created_at` FROM `posts` ORDER BY `created_at` DESC LIMIT 20
この単純な修正により、DBからアプリケーションへのデータ転送量が削減され、メモリ使用量とDB負荷の両方が改善されました。
(なお、あとになって気づくのですが、削除済みユーザーのフィルタリングによる表示数不足を補うために、少し多くLIMIT 30くらいにしないといけません。)
しかしながら、残り1時間を切ったところで問題が発生しました。用意されたデータを誤って削除してしまったようです。 運営の皆さんに助けを求めたところ、新しいEC2を立てていただきました。皆さん、データバックアップは取っておきましょう、、、
終了時刻が刻一刻と迫ってくる中、なんとかスコアを伸ばそうと、手早く「データベースインデックスの追加 」、「ページネーションによるデータ取得の効率化」を行いました。なお、ページネーションでは、余裕を持ってLIMIT 50にしておきました。
まとめ
最終的に、私たちのチーム「アポヒ」は21350点で43チーム中17位という結果になりました。1時間弱の格闘ではこの点数が限界でした、、

データバックアップを取っていなかったことが一番の反省点ですが、同時に実践形式で学ぶことも多く有意義な研修でした。ぜひ本家ISUCONにリベンジしたいと思います。
6/18開催 6回目 生成AI活用
開発1部 デリッシュキッチンMS DRMの惟高です。 私からは生成AI活用の紹介をします。
本研修は、大きく2つのテーマで構成されていました。 1. マイクロソフトの変遷とAIエージェントの概念 2. AI時代におけるソフトウェアエンジニアの役割の変化
AIの進化
AIの進化は、私たちがテクノロジーと関わる方法を大きく変えようとしています。
これまで、エンジニアのコーディングをアシストするCopilotのようなAIツールがありましたが、 マイクロソフトでは、2025年をAIエージェント元年と位置づけ、自然言語であらゆる操作や管理を可能にする新たな挑戦が進められています。
AIエージェントとは、ユーザーがタスクを割り振ると自律的に完遂する「代理人」のような存在です。 マイクロソフトは複雑な業務を自律的にこなすエージェントの提供を始めており、将来的にはエージェント同士が連携するマルチエージェントの世界が構想されています。
エンジニアの役割の変化
AIが発展する以前のエンジニアは、顧客課題の発見から設計、コーディング、チューニング、システムの監視に至るまで、人間主導型であらゆる工程をこなす必要がありました。
しかし、AIの登場によりこれまで人間が行っていた多くの作業をAIに任せられるようになりました。 今後は、AIに対して適切な指示を出し、その出力を評価し、最終的により良いアウトプットを形成する役割が重要とのことでした。
誰もがフルスタックエンジニアになれる可能性を秘めている一方で、これまでのエンジニアのようにあらゆるタスクを人手のみでこなすのではなく、AIを活用して全体の調和を取りながらプロジェクトを推進するような姿勢に変わらなければ、エンジニアとして生き残るのが難しいと感じました。
開発スタイルの変化
GitHubの統計によると、AIを利用した開発者数は2024年の2割未満から2028年には9割近くに増加すると予測されています。 つまり、数年後には社会全体でAIを使って効率化していこうというムーブメントが起こる可能性があるということです。
現状のAIによる開発がコーディングに限られているのに対して、将来的には企画・設計・実装・テスト・運用といったソフトウェア開発のライフサイクル全体に活用されることで、開発スタイルが大きく変わると考えられています。
コーディングスタイルの変化では、現在のCopilotによるAI支援(ペアプログラミング)から、AIが自律的に作業を行うチームの一員(ピアプログラミング)へと進み、さらに2030年には、AIがほぼ完全に自律的にソースコードを実装する時代が到来すると予測されています。
この未来では、エンジニアの主な役割は「要件定義」と「AIが作成したものがその要件を満たしているかの確認」となり、プロダクトマネージャーのような、サービス・製品の方向性を定める役割が重要視されます。
人間がやり続けること
AIがコードを生成する時代においても、そのコードの正しさを理解するためのプログラミングの基礎知識は依然として重要とのことでした。 しかし、AIがコードを書けてしまうため、今後は実践的な力よりも知識として知っておくことが求められるようになるそうです。
それよりも重要になってくるのが、AIに意図を正確に伝えるための「プロンプトエンジニアリング」の能力です。 AIは推論の中でハルシネーションを起こす可能性もあるため、目標を明確に宣言し、自然言語で要件や意思を的確に記述するスキルが不可欠だと説明いただきました。
また、AIは限界値テストや倫理的な判断が苦手なため、最終的なテストは依然として人間が行うべきとのことでした。 企業倫理やガバナンス、国のポリシーなど、人間の価値観に基づく判断は、今後も人間の重要な役割として残ると考えられています。
まとめ
本研修を通して、ここから数年の内にAIが自律的に実装する時代が来ると再認識しました。(もうすでに来ているのかもしれません...)
AIは私が考えているよりも身近なものになり、今後は「息をするようにAIを使う」ことが重要になってくると感じました。
またAIに対しては、何をして欲しいかといった指示を的確に伝える能力が必要になり、言語化能力がより必要になってくると感じました。
今後はAIを使い倒し、少しでも効率よく開発ができるように試行錯誤していきたいと思います。
おわりに
全6回の新卒合同研修を通じて、本当にたくさんのことを学ぶことができました。
技術的な知識はもちろんですが、何より良かったのは他社の新卒エンジニアの皆さんと出会えたことです。同じような悩みを抱えていたり、違う視点でものを見ていたり、刺激をもらうことがたくさんありました。研修後も連絡を取り合う仲間ができたのは、この研修の大きな収穫の一つです。
また、各分野の第一線で活躍されている講師の方々から直接学べたのも貴重な経験でした。最新技術のトレンドや現場での実践的な情報など、参考書では学べない生きた知識を得ることができました。
この研修で得た知識や経験、そして仲間たちとのつながりを大切にしながら、これからもエンジニアとして成長していきたいと思います。
最後に、このような素晴らしい機会を提供してくださった日本CTO協会の皆様、各回の講師の皆様、そしてスポンサーをしていただいた企業様に心から感謝いたします。ありがとうございました!