初めまして！ NTTドコモビジネス情報セキュリティ部の池山と申します。 未経験からセキュリティ分野に飛び込み、現在は脅威情報を中心に業務を担当しています。 2026年6月13日に開催された「第5回セキュリティ若手の会」にて、ドコモグループ（NTTドコモ・NTTドコモビジネス）はゴールドスポンサーとして協賛し、講演の機会をいただきました。 この記事では、初の外部登壇かつ初参加となった「セキュリティ若手の会」について、ギリギリ若手（社会人3年目）の視点から当日の様子をご紹介します。 セキュリティ若手の会とは？ 当日の様子 LT＆交流会 スポンサー講演登壇 最後に セキュリティ若手の会とは？ 「セキュリティ若手の会」は、将来セキュリティエンジニアを目指す学生や、セキュリティ業務に携わるエンジニアのためのコミュニティとして2024年10月に設立されました。 15歳以上の学生から新卒3年目の社会人までが参加可能となっており、セキュリティに関する技術や業務内容、進路やキャリアについて、直接話し合える機会が提供されています。 このコミュニティの特徴は、「実務志向の話題やキャリアに関する話」と「ユーザー企業・ベンダー企業双方の視点」に重きを置いている点です。 オンライン会場がないため、オフラインイベント（対面）ならではのリアルな話を聞ける場となっており、普段は知る機会の少ない現場の課題や意思決定の背景について理解を深めることができます。 また、若手参加者にとっては、さまざまな立場の方々と交流しながら自身のキャリアを考える貴重な機会となっています。 ドコモグループは、第3回に続き2回目の協賛となります。 協賛にあたっては、ドコモグループの採用担当とも連携しながら、事業内容やセキュリティエンジニアの採用についても広く紹介しています。 セキュリティ若手の会の詳細は以下リンクをご覧ください。 当日の様子 第5回はLT(ライトニングトーク)＆交流会イベントで、東京・日本橋のNICTイノベーションセンターにて開催されました。 学生・社会人あわせて約100名が参加し、テクニカルな話題から就職活動、業務の実情まで、幅広い内容の発表や議論が行われました。 LT＆交流会 当日は6件のLTと、3社によるスポンサー講演、交流会が実施されました。 どのLTも非常にレベルが高く、参加者の皆さんがセキュリティに対して強い好奇心を持ち、知識や技術を深めている様子が伝わってきました。正直なところ少し焦りを感じる場面もあり、身の引き締まる思いでした。 交流会では多くの方とお話しする機会をいただき、業務上の悩みや就職活動の相談、社会人としての心構えなど、若手ならではのテーマについて、学校や会社の垣根を越えて意見交換ができました。 （学生さんの自作名刺がかっこいいデザインのものばかりだったことも非常に印象的でした。すごい。） スポンサー講演登壇 スポンサー講演では、「等身大すぎる業務紹介」をテーマに、NTT Com-SIRTとしての業務をご紹介しました。 学生時代にセキュリティの学習経験がほとんどない状態で入社し、現在CSIRTメンバーとしてどのような業務を担当しているのかを、少しユーモアも交えながら率直にお話ししました。 当日使用した資料はSpeaker Deckにて公開しております。 今回の発表では、自身の経験や業務内容を中心にお伝えする構成としました。 今後は、より技術に踏み込んだ内容も外部で発表できるよう、研鑽を積んでいきたいと考えています。 あわせて、ネットワーキングの場でも話題に困らないセキュリティトークのデッキを増やし、余裕を持って対応できるエンジニアを目指したいと思います。 最後に ドコモグループ（NTTドコモ・NTTドコモビジネス）は、セキュリティ若手の会の活動に賛同し、ゴールドスポンサーとして第5回セキュリティ若手の会の開催を支援しました。 次回のセキュリティ若手の会は2026年10月に開催予定です。 セキュリティ若手の会の公式Xアカウントからぜひ最新情報をゲットしてみてください！ 今回、初めての外部登壇ということもあり、非常に緊張していました。 一方で、創立者の方から「若手が登壇経験を積む場になれば嬉しい」という思いを伺い、この貴重な機会をいただけたことに感謝しています。 今回の経験を糧に、組織のセキュリティ向上にも引き続き貢献していきたいと思います！ 今後も、NTTドコモビジネス情報セキュリティ部ではエンジニアブログを通じて情報発信をしていく予定です。 エンジニアブログのセキュリティカテゴリもぜひご覧いただけますと幸いです。 最後まで読んでいただき、ありがとうございました！^^

こんにちは。ファインディのPlatform開発チーム（以降、SREチーム）でSREを担当している原（ こうじゅん ）、富田（ @Cooking_ENG ）、松本（ @mozumasu ）です。 2026年6月25日・26日に幕張メッセで開催された「AWS Summit Japan 2026」に、SREチームの3名で参加してきました。 aws.amazon.com それぞれが印象に残ったセッションを1本ずつ取り上げ、ファインディの現状と紐づけてお届けします。 スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速するPlatform Engineeringの実践 TBSテレビ「ラヴィット！」大規模配信の裏側とAWSサーバーレス設計 実践！Amazon RDSとAmazon Auroraのコスト最適化とパフォーマンス向上 まとめ スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速するPlatform Engineeringの実践 SREチームの 原 です。 私が印象的だったのは、株式会社ログラスの中井綾一さんによるセッション「スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速するPlatform Engineeringの実践」です。 ファインディはECSを中心に構成していますが、今後Platformをどのようにしていくかという判断軸を持ち帰りたいと考え、このセッションに参加しました。 ログラスは経営管理サービス「Loglass」を中心にマルチプロダクト戦略を進めている会社で、本セッションではAmazon EKSをベースにしたPlatform基盤の導入から、1年で社内に広げていくまでの実践が紹介されました。 中井さんがEKS導入を判断した時点でのチーム規模は、次の通り紹介されていました。 エンジニア約50名 プロダクト2つ SREチーム4名 「マルチプロダクト戦略・SRE4名」という条件で、なぜ「重い」と言われがちなEKSを選んだのか、というのが本セッションの主題でした。 特に印象に残ったのは、技術選定の軸として中井さんが繰り返し言い切っていた「『今の規模』ではなく『数年後の事業にフィットするか』で判断する」という言葉でした。 基盤選定をする際には、「現時点で十分」「今の人数で運用できる」という現在地ベースになりがちですが、中井さんからはPlatform構築は1〜2年かかる長期投資で、課題が顕在化してから着手したのでは間に合わない、というメッセージが繰り返されていました。 実際に、SRE4名で導入を進めたPlatform基盤上で、1年で5チーム・約20サービスまで展開されたとのことです。 もう1つ刺さったのが「AI時代だからこそEKSプラットフォームに価値がある」という主張です。Coding Agentが高速に変更を生む時代には、Namespace分離・RBACやAdmission Controllerによってチーム・サービスごとの権限境界やポリシーを機械的に担保でき、開発効率と品質・統制を両立できる、という観点でした。 ここで気になるのが、ファインディの現在地です。 ファインディは現在、マルチプロダクト展開、SREチーム4名、基盤はAmazon ECS中心で、インフラ構築はTerraform汎用モジュールを介して開発者主体で進められる体制を整えてきました。 tech.findy.co.jp 直近のSREチーム全体の取り組みは、次のFindy Tech Talkでも紹介しています。 tech.findy.co.jp マルチプロダクトと開発者主体での運用がさらに広がったときに、SREチームがボトルネックにならないPlatformの形をどう先回りで仕込むかの重要性を感じました。「事業に対してPlatformをどう先回りで仕込むか」という考え方は大変勉強になりました。 TBSテレビ「ラヴィット！」大規模配信の裏側とAWSサーバーレス設計 SREチームの 富田 です。 私が参加したのは、株式会社TBSテレビの亀田遼さんによるブレイクアウトセッション「TBSテレビ『ラヴィット！』大規模配信の裏側とAWSサーバーレス設計」です。 『ラヴィット！忘年会 '25』を、想定視聴者数6万人規模で配信した際の裏側を紹介する内容でした。 全く宣伝できていませんでしたが、AWS Summitで初登壇しました！！ お聞きいただきありがとうございました🙏 #AWSSummit pic.twitter.com/PtQwcKdcxY — Ryo (@ry_km_u_u) 2026年6月25日 x.com 『ラヴィット！忘年会 '25』の配信プラットフォームには、KustamieというTBSテレビが開発している自社サービスが使われています。配信者と参加者の双方向なやりとりを充実させ、「参加感」を高めるためのイベント向けプラットフォームです。 アーキテクチャはサーバーレス中心で、データ管理にAmazon ECSとAmazon Aurora Serverless v2、クライアントAPIにAmazon API GatewayとAWS Lambda、映像とリアルタイム通信にAmazon IVS (Interactive Video Service) を利用しています。 大規模配信に向け、既存のクライアントAPI構成には次のような課題があったそうです。 キャッシュを前提とした構成になっていなかった 配信参加時のAPIレスポンスに最長12秒程度かかっていた 負荷試験を実施したことがなく、高負荷時の挙動が未知数だった これらの課題に対する解決策の中で、特に印象に残ったのが多段キャッシュ構成によるレスポンス改善のお話でした。 採用されたのは、Amazon API Gatewayのステージキャッシュ・AWS Lambda関数のグローバル変数・Amazon ECSと併設したAmazon ElastiCache (Valkey) を組み合わせた3層構成です。 API GatewayステージキャッシュでGET系レスポンスをエッジから返し、Lambdaのグローバル変数でホットスタート時の関数初期化を省き、ElastiCacheで後段のDBアクセスを軽くする、という形で多段にキャッシュが効くようにしていました。 結果として、最長12,000ms程度かかっていた配信参加時のAPIレスポンスが、平均150ms程度まで改善したそうです。 Amazon SQSとAWS Step Functions Expressによる非同期化も合わせて実施されており、設計全体で大きな改善幅が出ていました。 負荷試験にはOSSの負荷試験ツールGrafana k6が使われており、待機配信前→待機配信中→本編配信中の3フェーズで指数的にVUを増やすシナリオで本番のアクセスパターンを再現したそうです。 直近、私もk6とDatadogでファインディの負荷試験環境を構築していたところだったので、シナリオ設計や規模の見立てが自分の作業と重なって、特に身近に感じられた話題でした。 ファインディでの負荷試験環境構築の取り組みは次の記事で紹介しています。 tech.findy.co.jp 6万人規模の同時アクセスをサーバーレス中心の構成でさばく事例として、設計の引き出しを増やせたセッションでした。 ファインディでも「Findy Conference」を中心に瞬間的なアクセス集中は発生するため、「キャッシュをどの層で重ねるか」「どこを非同期に逃がすか」を設計初期から意識する姿勢は参考にしたい考え方でした。エッジ・Lambda・ElastiCacheで多段にキャッシュを効かせる発想は、今後の負荷特性の変化に備える引き出しとして持ち帰りたいと感じています。 また、Amazon IVSのように、ライブ配信向けに使えるAWSサービスをユースケースとセットで知れたことも収穫でした。 Kustamieは2026年秋にベータ版提供開始予定とのことです。どんなイベント体験が広がっていくのか、リリースが楽しみです。 実践！Amazon RDSとAmazon Auroraのコスト最適化とパフォーマンス向上 SREチームの 松本 です。 私が印象に残ったのは、アマゾン ウェブ サービス ジャパン合同会社の塚井知之さんによるブレイクアウトセッション「実践！Amazon RDSとAmazon Auroraのコスト最適化とパフォーマンス向上」です。 「パフォーマンス向上」と「コスト最適化」は両立できる、というテーマのもと、架空のEC支援企業「AnyCompany」が直面する課題と、その解決策を追体験していく構成のセッションでした。 AnyCompanyには「レポートクエリによる運用DBの圧迫」「複雑クエリでの一時オブジェクト書き出しによるI/Oボトルネック」「メモリに乗り切らないホットデータ」「バックアップコストの肥大化」といった、実務でよく遭遇する課題が並んでいました。 セッション全体で繰り返し問われていたのが、「大きいインスタンスへの垂直スケーリングは、最もコスト効率の良い選択か？」という問いです。 特に印象に残ったのが、垂直スケーリングに頼らずにコストとパフォーマンスを両立する3つのパターンでした。 リードレプリカへのクエリオフロード（レポートクエリを逃がす） RDS Optimized Reads（一時オブジェクトをローカルSSDに逃がす） Aurora Optimized Reads（バッファキャッシュをローカルSSDに拡張する） 1つ目は、リードレプリカへのクエリオフロードです。 社内データアナリストのレポートクエリが運用DBを圧迫している状況で、インスタンスを1段階上げる代わりに、小さめのリードレプリカを足してレポートを逃がす構成にすることで、約15%のコスト削減と顧客APIの安定化を同時に実現できる、という試算でした。 「先に分けることでむしろ安く済む」という発想は、Amazon RDSまわりの構成判断でも応用が効く話だと感じました。 2つ目は、RDS Optimized Readsで一時オブジェクトをローカルSSDに逃がすパターンです。 複雑なクエリで生成される一時オブジェクトがAmazon EBSに書き出されてレイテンシが伸びる、というボトルネックに対し、ローカルNVMe SSDを搭載したインスタンスへ載せ替えて一時ファイルの書き出し先をローカルSSDに切り替える、というアプローチでした。 垂直スケーリングと比べて約43%のコスト削減かつ最大2倍の読み取り性能向上というのは、知らないと選べない選択肢だと痛感しました。 3つ目は、Aurora Optimized ReadsでバッファキャッシュをローカルSSDに拡張するパターンです。 メモリに乗り切らないホットデータをディスクから読み直してしまう、というボトルネックに対し、ローカルNVMe SSDをバッファプールの第2階層として使う「階層型キャッシュ」で対処します。 同等のインメモリキャッシュを得るために大きなインスタンスに上げる代わりに、小さめのインスタンス + I/O-Optimizedの組み合わせを選ぶことで、約90%のコスト削減と最大8倍の読み取り性能を実現する事例でした。 判断のステップとして BufferCacheHitRatio や AuroraEstimatedSharedMemoryBytes でワーキングセットを把握してから選ぶ、という手順も合わせて示されており、「まず可視化してから手を打つ」という基本がここでも徹底されていたのが印象的でした。 バックアップ面でも、自動バックアップの保持期間を短くし、それより古い分はAmazon S3へのParquet形式スナップショットエクスポートに切り替えることで、30%のコスト削減ができるという試算が紹介されていました。 障害復旧のためのリストア要件は直近のデータで足りる一方、監査や過去データの参照は必ずしも即時のリストアを必要としないため、S3への安価なエクスポートに逃がせます。この「リストア要件」と「参照要件」を分けて考えるとコスト構造が大きく変わる、というのはファインディの運用でもすぐに見直せそうな観点です。 どの課題でも、Database InsightsやPerformance Insightsでまずワークロードを可視化し、ボトルネックに応じて適切なインスタンスファミリー・ストレージタイプ・キャッシュ階層を選び直す、という流れで進められていたのが印象的でした。 「見えないものは改善できない」という基本を、AnyCompanyの課題を通して追体験できる構成になっていたと感じました。 まずは BufferCacheHitRatio や VolumeReadIOPs ・ VolumeWriteIOPs を見直し、I/O-OptimizedやOptimized Readsが効くワークロードがないかを棚卸しするところから始めたいと思います。 まとめ 2日間を通して、各社の事例や最新サービスに直接触れられる濃いインプットの機会となりました。負荷試験のシナリオ設計や、Amazon RDS/Auroraのコスト最適化、マルチプロダクト時代のPlatformの形といった、現地で持ち帰った論点を、SREチームの日々の取り組みに少しずつ活かしていきます。 ファインディでは、SREメンバーを募集しています。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに ITD2-2-3のI.Hです。今回、RubyKaigi 2026 in 函館に参加する機会をいただきました。 RubyKaigiは、Ruby本体やエコシステムに関する最新の知見が集まる技術カンファレンスです。 今回の参加を通して、Rubyそのものについて学べたのはもちろん、他社エンジニアとの交流やスポンサーイベントでのLT登壇など、普段の業務だけでは得られない多くの経験をすることができました。 この記事では、Rubyに関する知見の共有だけでなく、技術イベントに参加すること自体の意味や価値についてもあわせてまとめました。 Day0(イベント前日) 函館に前日入り 場所が北海道の函館と言うことで、当日出発では間に合わないため前日の夜に出発しました。 空港に到着すると、空港の至る所にRubyKaigiの看板や垂れ幕がありました。 また、路面電車の車内外にもRubyKaigiの看板が。町おこしさながらの盛り上がりでした。 空港で明らかにrubyistの方（第一rubyist）を見かけたので、タクシーに相乗りしました。 有名なラーメン屋さんで降りるとのことだったので、一緒に食べながら技術の話やお互いの会社の制度・AIツールの導入状況などに花を咲かせました。 Day1 会場へ 会場は、JR函館駅から市電で30分ほどの場所にある「 函館サーモン・まるなまアリーナ/ホール 」でした。命名権を地元の水産会社が取得されたらしく、函館感全開の良い会場名とロゴになってました。 チェックインすると、首から掛けるストラップと名札をいただきました。 会場で「どこの会社の方ですか？」と度々聞かれるので弊社のロゴを手書き。 なんとか伝わりました。 基調講演 The Journey of Box Building 発表資料はこちら 初日の講演は、rubyコミッターでもある田籠 聡さんの基調講演から始まりました。 内容は、2025年12月25日にリリースされた  Ruby4.0.0  の新機能の一つである、 Ruby::Box  についてでした。 Ruby Boxはクラス等の定義の分離／隔離のための機能を提供する、実験的機能です。 実験的な機能として位置付けられているとのことでしたが、安全にコードの分離ができるようになる点は業務にも活かせそうでした。 Exploring RuboCop with MCP 発表資料はこちら Keynote以外の公演は基本的に大ホール・小ホール・サブアリーナで行われ、同時刻に開催される講演に同時に参加することはできないため、タイムスケジュールと発表内容を見て選ぶ形式でした。 英語での講演も多く、同時翻訳アプリで聴くことにも挑戦しましたが、やはり日本語の講演の方が理解しやすく、自然と日本語の講演を選ぶことが多かったです。 そんな中で、初日の午後に参加した伊藤浩一さんの RuboCop  x MCPの話が印象に残りました。 RuboCopは人間や他のプログラムによってトリガーされていました。AI時代においては、AIエージェントが新たなトリガーとして登場しました。本講演では、生成型AIとリンターおよびフォーマッターを組み合わせる実践的な方法について議論します。 決定性がLinterとしての価値だった中で、非決定性を持つLLMを組み合わせることでどんな価値が創出できるのか（又は失われるのか）という試行錯誤の話が面白く、こういったイベントに参加して直接コミッターの方のお話を聞く醍醐味だと感じました。 Day2 基調講演 Twenty Years of JRuby 2日目は20年以上 JRuby （Java仮想マシン上で動作するRubyの処理系）を開発している、Charles Nutterさんの基調講演から始まりました。 内容はJRuby が誕生してからの20周年の振り返りと、JRuby 10.1 のリリースについてでした。 業務を含めこれまでCRuby（C言語で実装されたRubyの処理系）しか触ったことがなかったのですが、JRubyやMRubyのような別の処理系にも興味が湧きました。 Practical TypeProf: Lessons from Analyzing Optcarrot 発表資料はこちら 2日目は TypeProf 開発者の 遠藤侑介さん の講演が印象に残りました。 メインの話は、TypeProfを実際に適用してみた事例です。題材に選ばれたのは、発表者自身が開発したRubyで書かれたNES（ファミコン）のエミュレータで、約6000 行の複雑なコードに TypeProf を適用したところ600個以上のエラーが出たとのことです。 対応としては、型推論結果に強く影響する箇所にRBSを書くことと、TypeProf 側の誤認識の根本原因を直すことの2方向から進められ、最終的には Ruby 55行＋RBS 67行、合計122行の変更でゼロエラーに到達したとのことでした。SteepやSorbetと比べても、既存コードへの変更量がかなり少ないという結果でした。 終盤では、AI コーディングエージェントが普及する中でTypeProfをどう位置づけるのか、という問いも提示されていました。エディタ支援を主目的としてきたツールが、AI 時代にどんな価値を持てるのかという点についても言及されていました。 Day2の交流会 2日目の夜は、Drink Upに参加し、LT枠が空いていたので発表しました。 3日目のRubyKaigiがより面白く聞けるようにと思い、Rubyが実行されるプロセスをParserの話からGCの話まで、一通りまとめてみました。 資料は marp  + Opus4.6で作成 Day3 Lightning-Fast Method Calls with Ruby 4.1 ZJIT 発表資料はこちら RubyKaigi最終日は、 国分崇志 さんのZJITの講演が印象に残りました。 注目度の高い ZJIT ですが、今回の発表では特にメソッド呼び出しの高速化に焦点が当てられていました。 Rubyでは依然としてメソッド呼び出しのオーバーヘッドが大きく（動的型付けだから仕方ないが）、YJIT によって改善が進んできた現在でも、なお大きなボトルネックとして残っているそうです。ZJIT ではこの処理の最適化が大きなテーマになっており、バックトレースや例外処理、ローカル変数アクセスに必要なメタデータをどう保持しつつ、無駄なメモリライトを減らすかが論点になっていました。 そこで紹介されていたのがLightweight Framesでした。これは、メソッド呼び出し時に必要なフレーム情報を最初からすべてメモリに書き込むのではなく、必要になるまで遅延させ、まずは最小限の情報だけを持つことでコストを下げるアプローチです。 Rubyの柔軟な書き心地は維持しつつ、高速に動くようにしていく取り組みをしていただいてる事に感謝です Matz Keynote もちろん最後は、Rubyを作った「 まつもと ゆきひろ 」さん（Matz）の基調講演でした。 ここ半年くらいは自分でコードを書かずに、ほぼ全てAIに書かせるという縛りを自らに課しているとのことでした。コードレビューやプロンプトを細かく制御できるからこそできる事だと思いますが、実務の現場でもAIエージェントは欠かせない存在になってきているのではないでしょうか。 そんな中で大きなトピックは、新しいRubyのAOTコンパイラ「 Spinel 」の発表です。RubyコードをC言語に変換してからコンパイルすることで、ネイティブバイナリを生成するという試みで、すぐに業務レベルで役立てられるものではなさそうですが、インタプリタ言語×AOTコンパイルという発想と開発過程が興味深かったです。（Rubyは動的機能が多いので、機械語にできる=高速化ではないことに注意してください） まとめ RubyKaigiに行って良かったと思う1番のポイントは、Rubyやプログラミングが大好きな人達の「熱」を感じられたことでした。普段「仕事」としてプログラミングをしていると商業的な観点で価値を測り測かられる癖がついてしまって、楽しいとか知的探求という側面を忘れていたなぁと思いました。 また、現地での他社のエンジニアとの交流も刺激的でした。今まで自分がマイナビ色に染まっている自覚はありませんでしたが、他社のエンジニアと交流すると明らかに各社個性というか雰囲気があって、たまには視野を広げるためにも交流して新しい知見を持ち帰ってくる必要があると感じました。