開発チームに入ってセキュリティを向上するということ
「カミナシ レポート」の開発・運用をしている、AWS インフラが得意な Security Engineering の furuya です（属性過多）。妙に流行り物に乗っかるときがあるのですが、「超かぐや姫!」を見てきました。よかったです。それはさておき今回は「カミナシ レポート」の開発におけるセキュリティ向上施策のお話です。 カミナシでは開発チームに Security Engineer を派遣する取り組みがあります。 kaminashi-developer.hatenablog.jp 気がつけば、この記事の公開から1年が経過していました。ここでそれを振り返ってみたいと思います。 サービスにおけるコンテキストを把握する 派遣されるセキュリティエンジニアは基本的には最初の半年から1年程度は開発チームの1メンバーとして、ともに開発や運用を行います。ですので、障害対応やインシデント対応、お客様からの通常のお問い合わせなどのオンコール担当としても活動します。 この1年を通して「カミナシ レポート」の開発・運用に携わりました。私自身のキャリア的にコーディングから離れていたのでその点は AI の力も借りながらそこそこに、代わりに得意なインフラ・運用面で改善をしたり、オンコールに入ることでチームメンバーの負荷を軽減したりして貢献しました。およそ最初の半年くらいでチームには馴染めたと思っており、そこで得たコンテキストから残りの半年は重めのインフラ・セキュリティ改善に取り組むことが最優先であると判断し、チームとしても合意の上で対応を進めることができました。 施策のテスター その欠陥を修正することにより獲得したナレッジを他サービスチームに共有することができ、セキュリティ上の欠陥が埋め込まれるのを未然に防いだり改善することが狙いとしてあります。 欠陥の修正ではないのですが、全チーム対応しないといけないようなセキュリティ施策（AWS Security Hub CSPM の新しいコントロールへの対応など）をまず最初に「カミナシ レポート」の開発チームで実施し、対応するための手順や Terraform のコード、ハマりどころを公開して他のチームの工数を削減する、といった取り組みを行いました。サービスを運用する中での変更になるので特有のワークアラウンドが必要なこともあり、単純にマニュアル通りにいかないケースで役に立ったかと思います。 セキュリティナレッジの共有 また、セキュリティエンジニアが持っているナレッジや考え方などをサービスチーム内で共有することにより、エンジニアがセキュリティを意識しながら開発や運用を行えるようになることを目的としています。 私自身セキュリティを専門としたキャリアを歩んでいないのでナレッジの共有といっても手探りではあります。ただ、だからこそ「セキュリティどうしたらいいかわからない開発者」の気持ちにもなれます。やはり開発する身になってみると「セキュリティ、いつどこでどうしたらいいかわからない」というのが真っ先に思い浮かびます。 「いつどこで」がわからない、というのはセキュリティを気にするべきタイミング・ポイントに気付けなければ実施・対策しようがない、ということでもあります。何にせよまずは知識を得るところが大事なのではないか、と思っていたときにちょうど「開発者はどこまでセキュリティを気にすればいいのか」という問いをメンバーからもらいました。そのときの話をセキュリティエンジニアの西川さんがブログに書いてくれています。 kaminashi-developer.hatenablog.jp そういう気に掛けることができるかどうかというのがすごく大事で、そのような気付きがあったときに「一旦セキュリティエンジニアに聞いてみようかな」というマインドセットを持てるかどうかが重要だと思っています。 気付ける筋肉みたいなものがあると思っており、それはやはり知識と実践で養われていきます。気付けさえすれば自分で解決することもできますし、できなくてもセキュリティエンジニアに聞くというアクションがとれます。 前置きが長くなったのですがやっぱりまずは座学で知るところからが一番でしょう、ということで開発者が気にすべきセキュリティの勉強会を開催しています。 geminiに作ってもらったセキュリティ対策全体像 第1回は「設計で気付けるとよいポイント」ということで脅威モデリングのワークショップを、第2回は「普段の実装の中で気付けるポイント」として SAST（Static Application Security Testing。コードの脆弱性チェック）の紹介および運用に取り入れる方法について議論をしました。もっと自然にチームメンバーが「気付くことができる」ように、定期的に実施していきたいです。 想定外の効果 すべてのチームにセキュリティエンジニアが派遣できればよいのですが、人数も限られており実現はできていません。しかし、派遣されなかったチームにも心境の変化があったようです。具体的には、派遣されないならされないなりに自分たちでよりセキュリティを高めていくぞ、というオーナーシップの醸成に繋がったチームがありました。実際、（個人的に）悔しいながらそのチームが一番セキュリティが出来ていそうなので、副次的ではありますが他のチームにいい影響を与えることができたのではないかと思っています（ここから挽回していきたいです）。 これから この1年を通して開発・運用をしながらそのコンテキストを理解したうえでセキュリティ対策をしたり、セキュリティ文化の醸成に取り組んだりしてきました。まだやるべきことはたくさんあります。この1年でようやく土台が整ってきたところなので、ここから『「カミナシ レポート」の開発チームって息をするようにセキュリティできてるよね』と言われるようになりたいです。 「カミナシ レポート」はカミナシのフラッグシッププロダクトということもあり、昔から積み上がった課題が複数残っています。これらに対処しつつ、先程のSASTなどを「開発速度を落とさないように」運用にのせて一段上のセキュリティレベルを目指しつつ、チームメンバーがもっとセキュリティに「気付ける」ようにしていきたいと思っています。
- セキュリティ
- AWS
- Terraform
- チームビルディング
デブサミ2026 Day2 初参加レポート
はじめに 「カミナシ レポート」を開発しているかわりくです！ 日本最大級のテックカンファレンス、Developers Summitに初参加してきました。 2日目のセッションの感想や持ち帰れそうなことをメモっております。 会場の雰囲気は、デデデデカイ！規模がデカい！今まで参加したどのカンファレンスよりも人の数と会場のキャパシティと、ブースの数が桁違い...！スタッフさんも多い...!ありがとうスタッフさん...! タダでサンドイッチもらってごめんなさい...!スタッフさんの分まで楽しみます！ 興奮しながらの入場となりました。 （2026/2/19終了後、最速レポとして投稿されたものです。） beyond the code（デブサミ26のキャッチコピー） セッションレポート LLM利用率80%への道筋：ピクシブが実践した「People・Process・Technology」三位一体の変革とは？ 登壇者: bash（ピクシブ） 川口 修平（GitLab） セッション詳細 ざっくりまとめ ピクシブさんが自社の開発者向けにLLMの利用を推進していく中で、組織にどんな変化が起きたか？という話。Technology、Process、Peopleの3つの要素が相互に変化を起こし続けるのがポイント。 (Technology)開発プロセスをツールチェーンで構築するのではなく、AIによる開発支援の強力なパイプラインを持つプラットフォーム(GitLab)を採用。ツールの選定やアップデート、チーム間の知見共有のコストをごっそり削減した。 (Technology)リリース前にセキュリティ診断を「一方通行で」やるんじゃなくて、GitLabの基盤で常にセキュリティ診断が回り続ける仕組み（DevSecOps）を作った。 (Process)開発プロセスに対する健康診断の仕組みでボトルネックを特定する。経営層もAI推進にコミットする。 (People)開発プロセスの全てを行うWhole Teamとしてチームを設計する。AIをチームメンバーと考えてチーム設計をする。 クローズアップ 「エンジニアリングとは、再現可能なプロセスを確立して継続することである。」ピクシブさんの社内Docに書かれた言葉らしい。AIによってエンジニアは不要になる・何を作るか？だけが重要になる。といった言説が増えたが、エンジニアの価値は再現性とそれを持続すること。そう考えると、AIが爆速でコードを書いてくれることと、エンジニアの本質的な価値はバッティングしないどころか、互いに補完しあう存在だと思った。 統合開発プラットフォーム（GitLab）に組織横断的なAIパイプラインを敷くことで、ツールや開発プロセスのサイロ化を防ぐ。一方で、コーディングツール（Claude CodeやCodexなど）やハードウェア（PC）といった手足の部分には一定の選択の自由度を残す。全てをトップダウンで強制しない、このバランス設計が良いと思った。 持ち帰り 再現性が高く、持続的な仕組みを作る。短期的な再現できない成果"だけ"を求めない。 自チームだと、QAフェーズをもっと開発チームが主体的に取り組むことができるはずなので、Whole Teamとして、QAフェーズにもオーナーシップを持って進められる仕組みをつくる。 意志を実装するアーキテクチャモダナイゼーション 登壇者: nwiizo セッション詳細資料 ざっくりまとめ 書籍からの引用と、登壇者の考えを交えながら、レガシーシステムをモダナイゼーションするためのhowとマインドセットの話。 実装はAIがこなせる時代になったが、組織や事業ドメインを織り込んだアーキテクチャ設計はできない。人が意志を持ってアーキテクチャを設計する。 AIが進化しても、組織の構造や人間の感情など、人の性質は変化しない。組織（人）と技術が相互作用しながら開発を進めるための技術がこれからも必要。 コンウェイの法則（システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう）は避けられない。むしろ利用する。そのためにはドメイン境界をうまくモデリングすることが重要。 技術的負債は事業課題になる。変化に耐えられないシステムは競合に負ける。 クローズアップ ソシオテクニカル。俺たちはコーディングから逃げられたとしても人間からは逃げられない... モダナイゼーションは派手な技術選定より、地味な現状把握。説明しやすい嘘より、説明しにくい真実を話す。 技術負債は開発者体験やデリバリー速度が低下するだけじゃない...!プロダクトが...会社が終わる...! 持ち帰り 技術的負債について議論する時、技術的な課題に閉じずに、組織的な課題をセットで考えます。はい。やります。 人と向き合う時を増やす。 短期的で派手な成果よりも、地道な本質と向き合う。 2重リクエスト完全攻略HANDBOOK 登壇者: 三谷 昌平 セッション詳細資料 ざっくりまとめ フィンテック（2重リクエストが起きたら洒落にならない領域）の開発者が、Webサービスにおける2重リクエストの問題と対策をフロントからバックエンドまで段階的に解説してくれた。 まずフロントで発生頻度を下げる。submitボタンのdisabled化、PRGパターンでリロード対策。これはやらない理由がない。 バックエンドではDBのユニーク制約や状態遷移のバリデーションで、仮にリクエストが到達しても不整合なデータを作らせない。 さらに排他制御（悲観的ロック）やAPIレスポンスキャッシュで、並行リクエストやリトライにも対応する。 意図的なリクエストと事故を区別するために、idempotency-keyヘッダという選択肢もある。 クローズアップ 技術の概要だけでなく、実例が多く、ユースケースがイメージしやすかった。実例があると取り入れやすい。 2重リクエスト対策はめちゃくちゃ手段があって、それぞれのメリデリがあるので、パターンを知っておいて、適切に選択できる必要がある。人が意思を持って選ぶんだ！ 持ち帰り 自分のプロダクトで2重リクエストが起きたら何が困るか、一度洗い出してみる。プロダクトの性質に合わせて優先度を整理して、なんらか解消してみます。やるゾス。 Claude Codeで実践するスペック駆動開発入門 登壇者：吉田 真吾(ジェネラティブエージェンツ/セクションナイン) セッション詳細 ざっくりまとめ 実践Claude Code入門の 著者によるスペック駆動開発（SDD）の話。仕様書を信頼できる唯一の情報源として、コード生成はAIが行うというアプローチとAI-DLCを比較しながら解説。 AIエージェントとは、目標に向けて環境と相互作用しながらタスクをこなす知能システム。ツールを実行し続けるループで目標を達成する。 SDD（Spec-Driven Development）では、spec（要件定義書・実装の設計・タスクリスト）を整備して、AIに実装させる。作業単位で永続的なドキュメントを作ってメンテしていく。 コーディングスタイルだけでなく、spec駆動のやり方自体もclaude.mdでポリシーとして定義しておく。 さらにAI-DLC（AI Development Life Cycle）という概念も紹介されていた。（ちょっと時間内だとSDDとAI-DLCの違いが理解しきれなかった...出直してきます） 簡素なSDDだと、laude.mdの肥大化によるコンテキスト消費、監査ログが残らない、ユーザーとのやり取りの詳細が不十分、といった課題もある。 クローズアップ 「Spec駆動開発は試してみるというフェーズを終えて、当たり前になりつつある」 持ち帰り AI-DLCを理解して、開発プロセスに取り入れます。 コードが物理世界を動かす興奮と責任 ～フィジカルAIの最前線でソフトウェアエンジニアは何と戦っているのか～ 登壇者：梅田 弾(ティアフォー)、山田 勲(T2) 司会：森崎 修司(名古屋大学) セッション詳細 ざっくりまとめ 自動運転業界がどのようにAI開発をしているのか、というパネルディスカッション。 自動運転といっても、センサーやハードだけじゃなく、ソフトウェアもクラウドもめちゃくちゃある。 ハードウェアの制約（計算資源、電源、センサーのタイムスタンプ同期...）がある中での最適化が必要。泥臭い。 あらゆるパーツが壊れても安全に動作する冗長なシステム設計が求められる。（人命かかりすぎてる。尊敬します。すごい。） 以前は技術導入すると後戻りできなかったが、今はシミュレーション環境が整ってきて、新しい技術もスピーディーに試して導入判断ができるようになった。 クローズアップ 「泥臭くやる」を登壇者が何度も強調していたのがカッコ良かった。最先端のAIも、データのタイムスタンプ合わせや電源の接続不良みたいな地味な問題と戦っている。華やかさの裏にある泥臭さ。 ソフトウェア開発を支えるためのソフトウェア。みたいなものをたくさん開発している。（データ不整合に気づく仕組みなど） 持ち帰り webシステムの開発でも「ソフトウェアのためのソフトウェア」（データ品質の自動検出、開発プロセスの自動化）という発想はもっと取り入れられるはず。開発を支える仕組みに投資する意識を持つ。 おわりに day2はサミットの熱量を最速で届けるレポートでしたが、day2,3の通しのレポートは日を改めて公開いたしますので、そちらもチェックお願いします！ 弊チーム積極採用しております！来年はご一緒にデブサミいきましょう！ herp.careers
- 生成AI
- アーキテクチャ
- セキュリティ
- SRE
- 開発プロセス
Claude Codeを使ったSaaSセキュリティチェックの自動化
コーポレートエンジニアの @sion_cojp です。 この記事では、Claude Code を使って SaaS セキュリティチェックを自動化した取り組みについて紹介します。 SaaSセキュリティチェックとは？ 従業員が新しい SaaS を業務で利用したい場合、その SaaS がセキュリティ面で問題ないかを、コーポレートエンジニアが事前にチェックします。 チェック項目の一部を挙げると以下のような内容です。 公的認証資格を取得しているか（SOC など） MFA（多要素認証）／二段階認証に対応しているか 解約後にデータは完全に削除されるか 準拠法・管轄裁判所の確認 また近年では、SaaS に AI 機能が標準搭載されるケースも増えており、 学習への利用をオプトアウトできるか 入力データがモデル改善に使われるかどうか といったAI 特有の観点もチェック対象になっています。 これらを総合的に確認したうえで、業務利用可能かどうかをカミナシでは判断します。 Claude Code導入前のつらみ 従来は、以下のような情報を人力で収集・確認していました。 利用規約 プライバシーポリシー FAQ セキュリティ関連ページ その他チェック項目をジャッジするためのページ その結果、次のような課題がありました。 一定以上のリサーチスキルと知識が必要 項目をすべて埋めるまでに時間と労力を消耗 情報収集漏れにより、チェックが不十分になる可能性 多くの文書が英語で書かれている AI の進歩に伴い、新規 SaaS の登場や既存 SaaS の AI アドオンによる、チェック依頼の件数が急増 これらを改善するために、 Claude Code にリサーチとチェック項目・一次レポート生成を任せ、コーポレートエンジニアはレビューに専念する という運用に切り替えました。 Claude Codeとは？ Claude Code は、Anthropic 社が開発した、ターミナル（CLI）上で動作する AI コーディングツールです。今回の用途で特に有用だった点は以下です。 Web Search 機能: 外部インターネットにアクセスし、公式ドキュメント等を自動検索 Custom Slash Command: Markdown でルールを定義すると、それに従って作業を実行できる Custom Slash Commandのサンプル 今回は /saas-check という Custom Slash Command を作成して利用しています。 .claude/commands/saas-check.md の一部は次のような内容です （※ 公開できない部分は ***** で伏せています。またチェック項目も省略しています）。 --- allowed-tools: Read, Glob, Grep, Bash, Write, WebSearch, WebFetch description: 利用規約、プライバシーポリシーなどのpdfファイルを解析し、要約と重要ポイントを抽出する --- # Your task 各SaaSやソフトウェアの利用規約、プライバシーポリシーなどのpdfファイルを解析し、以下の情報を抽出してください。 ファイル群は `saas-security-check/{SaaS or ソフトウェア名}/*.pdf` に格納されています。 ## 入力 ### ステップ1: 対象SaaSの選択 - `saas-security-check/` ディレクトリ内のフォルダ一覧を表示し、どのSaaS/ソフトウェアをチェックするか選択させる ### ステップ2: 必須ヒアリング項目（すべて確認すること） **重要: 以下の5項目すべてをユーザーに確認してください。AskUserQuestionツールを使用し、すべての項目を2回で呼び出しで質問してください。** 1. **情報種別**（必須・選択式） - 社外秘情報を含む - 公開情報のみ 2. **利用用途**（必須・自由入力） - ユーザーに直接入力させてください - 例: 「社内ミーティングの文字起こし」「顧客データの分析」など 3. **申請者のメールアドレス**（必須・自由入力） - ユーザーに直接入力させてください - 例: `example@kaminashi.jp` 4. **サービスURL**（必須・自由入力） - ユーザーに直接入力させてください - 例: `https://example.com` 5. **保存される情報**（任意・自由入力） - ユーザーに直接入力させてください - 未回答の場合は「未回答」と記録 ### ステップ3: 調査実行 - 指定されたSaaS/ソフトウェア内の全pdfを調査 - pdfファイル名を指定された場合: そのファイルのみ再調査 - 最後に、最終更新と命令履歴を更新 ## 出力先 `saas-security-check/{SaaS or ソフトウェア名}/result.md` マークダウンファイルを出力 ## 調査手順 1. **PDF読み込み**: ***** 2. **Web調査**: ***** 3. **会社・資本確認**: ***** 4. **出力生成**: ***** 5. **判断**: ***** ## 実装差分情報の活用 - **`saas-security-check/` ディレクトリ**: 各SaaSのチェック結果が格納されている - ファイル命名規則: `{SaaS or ソフトウェア名}.md` - 例: `Supabase.md`, `tl;dv.md` ### 注意事項 ***** ### 判断ガイドライン ***** ## 出力フォーマット ### マークの意味 | 記号 | 意味 | |-----|-------------------------| | ✅ | 機能があったり、規約に書いてある | | ⚠️️ | 機能があったり、規約に書いてあるが、注意が必要 | | 🚫️ | 機能がない、規約に書いてない | | ⬜️ | 未チェック | ### 理由のフォーマット - テーブルに記載する理由のフォーマットは下記となります \``` - {具体的な理由を記載してください} - > {ソースとなるファイル名} - > {ソースとなる文章} \``` - 理由内は、文章が読みやすいように `<br>` をうまく使ってフォーマットしてください。 `<br>` の理由はmarkdownレンダリング時に改行されるためです - 箇条書きの場合は、`・ ` で始めてください ### テンプレート \```markdown # {SaaS/ソフトウェア名}: セキュリティチェック結果 **最終更新**: {YYYY-MM-DD HH:MM} # 前提 - 本審査では、{SaaS/ソフトウェア名}の業務利用可否を審査する - カミナシ社内の利用者が本 SaaS にカミナシの下記情報を格納するユースケースを持つことを前提として、審査を実施する（セキュリティハンドブックの情報資産の分類を参照） - ⬜ 社外秘情報を含む - ⬜ 公開情報のみ # 申請情報 | 項目 | 内容 | |------|------| | 申請者 | {申請者のメールアドレス} | | サービスURL | {サービスのURL} | | 利用用途 | {利用用途} | | 保存される情報 | {保存される情報。任意項目のため、未回答の場合は「未回答」と記載} | # 審査結果 ## 結論 - {業務利用可 or 条件付きで利用可 or 業務利用不可} - {なぜ利用可能 or 不可能としたか記載する} ## 例外 - {「このデータは扱ってはいけない」など、例外があれば記載してください} ## 例外の背景 - {例外がある場合、理由を書いてください} ## 重要と思われる補記事項 - {AIのデータ取り扱いなど、リスクがありそうな点などがあれば記載してください} # 利用用途 - {このSaaS/ソフトウェアは一般的にどのような用途で利用するか記載してください} # マークの説明 - ✅: 機能があったり、規約に書いてある - ⚠️: 機能があったり、規約に書いてあるが、注意が必要 - 🚫: 機能がない、規約に書いてない - ⬜: 未チェック # 共通チェック項目 ### MUST | No | 項目 | マーク |理由 | |--- |--- |--- |--- | ### SHOULD | No | 項目 | マーク | 理由 | | --- | --- | --- | --- | # 特定の分野 ## AI ### MUST | No | 項目 | マーク | 理由 | | --- | --- | --- | --- | ### SHOULD | No | 項目 | マーク | 理由 | | --- | --- | --- | --- | ## 参照したpdfのパス一覧 {参照したpdfのパス一覧を箇条書きで書いてください。相対パスかつ、リンクを貼ってください} ## 参照したWebページ一覧 {Web調査で参照したURLを箇条書きで書いてください} ## 命令履歴 | 日時 | 命令内容 | |------|---------| | {YYYY-MM-DD HH:MM} | {初回調査} | \``` 実際の運用方法 関連ドキュメントの収集 Claude Code に十分なコンテキストを与えるためと、Web Searchの時間を減らすために、事前に以下のようなチェックに必要なドキュメントを収集し、ディレクトリに保存します。 利用規約 プライバシーポリシー セキュリティ関連ページ Custom Slash Commandを実行 Claude Code を起動し、Custom Slash Command を実行します。 今回は「カミナシ」の自社サービスをセキュリティチェックする例です。 claude /saas-check 実行後、AskUserQuestion によりチェック対象のSaaSなど「必須ヒアリング項目で定義したもの」のヒアリングをされるので、選択または入力します。 最後にSubmitを選ぶと、リサーチが開始されます。 Claude Codeのサマリ出力 調査が完了すると、Claude Code からサマリ結果が表示されます。 このサマリの良い点は以下です。 重要なポイントを簡潔にまとめてくれる 確認が必要な項目のレコメンド PDF 化が必要なサイトなど、実務目線のレコメンドを出してくれる <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kaminashi-developer/20260206/20260206150724.png" wid
- Claude Code
- 生成AI
- セキュリティ
カミナシ Tech Night #1 - AWS re:Invent 2025 Recap Specialを開催しました！
こんにちは、ソフトウェアエンジニアのいちび (@itiB_S144) です。 2026年1月28日 (水) に「カミナシ Tech Night #1 - AWS re:Invent 2025 Recap Special」を開催しました！カミナシのエンジニアチームとしては初めての外部の方も参加可能なイベントの開催で、準備段階からドキドキしていましたが、当日は大盛況で無事に終えることができました。 今回のテーマは AWS re:Invent 2025 の recap (復習) イベントということで、実際にカミナシから現地参加したエンジニア 5 名と豪華なゲストの方々がそれぞれの視点でセッションレポートをお届けしました。イベントには社外からも 13 名ほど参加いただき、会場は熱気に包まれていました！ 本ブログではイベントのレポートをお伝えします。 カミナシ Tech Night とは カミナシのエンジニアを中心に業務や趣味で触れた技術についてわいわい発表するイベントを企画しています。今回は #1 としており、今後も継続して開催していく予定です。 イベント概要 日時: 2026年1月28日(水) 19:00〜21:00 (開場時間：18:45~) 会場: 株式会社カミナシオフィス 5F (神田駅徒歩5分) kaminashi.connpass.com 時間 内容 登壇者 18:45 - 開場・受付 19:00 - オープニング 19:05 - AWS 上での脅威と向き合うために 西川 彰 19:15 - みんなだいすき ALB、NLB の仕組みから最新機能まで総おさらい 古屋 啓介 19:25 - なんとなく知っていた Cache を学ぶ いちび 19:35 - 休憩 19:45 - re:Invent 2025を振り返る 【ゲスト】Noritaka Sekiyama 19:55 - カミナシの re:Invent 補助事情 Tori Hara 20:00 - やっぱり EC2 / JAM の勝ち方 [検索] 【ゲスト】星 北斗 20:10 - re:Invent Lv.500 セッションの歩き方 LLM の未知の未知を知る 高井 真人 20:20 - クロージング 20:25 - 懇親会 ゲスト紹介 re:Invent の現地でカミナシメンバーと交流のあった方々にもゲストとしてご登壇いただきました。 ご登壇くださりありがとうございました🙌 星 北斗 様 (@kani_b) 株式会社LayerX 執行役員 CISO 兼 バクラク事業部 VPoE 2024年1月に株式会社 LayerX に入社。コーポレートエンジニアリング室 室長、バクラク事業部 PlatformEngineering部 SRE グループマネージャーを務め、2025年10月より現職。クラウドとセキュリティと料理が好き。 Noritaka Sekiyama 様 (@moomindani) 通りすがりのData Professional。 セッションレポート AWS 上での脅威と向き合うために - カミナシ 西川 彰 (@nishikawaakira) トップバッターは西川さん。脅威モデリングについてのお話でした。 リスクマネジメントで用いられる脅威モデリングについてのアプローチ手法の変化について紹介してくださいました。 昨今は LLM の進歩もあり開発者がより脅威モデリングをしやすくなっています。LLM フレンドリーなドキュメントを書くことでより実りある脅威モデリングやリスク分析ができるものの、開発者がレビューするのも難しく LLM の扱い方を検討する必要が今後来そうと考えているとのことでした。 みんなだいすき ALB、NLB の仕組みから最新機能まで総おさらい - カミナシ 古屋 啓介 (@saramune) 古屋さんは「ALB/NLB の内部実装から最新機能まで」について学んだセッションを紹介してくださいました。ALB がどのように AWS の裏側で実現されているか、スケールするかなどを解説してくださいました。 ALB に新たに追加された新規の機能として「Target Optimizer」の紹介もあり、Target Optimizer を使うことで ALB がターゲットに流れる通信の同時実行数を制限することができるとのことです。 以下に古屋さんが Target Optimizer について書いたブログがあるので良ければ参考にしてみてください！ dev.to なんとなく知っていたCacheを学ぶ - カミナシ いちび (@itiB_S144) 私自身も LT をさせていただきました。私の発表は「Cache me if you can, Valkey edition」という Valkey というメモリベースのデータベースについてのワークショップセッションをレポートしました。 自分のイメージとして持っているキャッシュは「画像を CloudFront でキャッシュすると読み込みが早い」「ログイン状態やカートを Redis に保存する」程度でしたがこのセッションでは書き込み時にキャッシュを作るWrite through や Write Behind などの実装パターンを知ることができました。 特にセッションの中で面白かったのは「生成 AI の結果をキャッシュする」という発想でした。 与えられたプロンプトをハッシュ化してキャッシュにヒットすれば返す、なければベクトル類似度検索で近いプロンプトの解答をキャッシュから返す。それでもヒットしなければようやく生成 AI に問い合わせるというキャッシュの活用テクを教わりました。 re:Invent を振り返る - ゲスト Noritaka Sekiyama 様 (@moomindani) ゲストの moomindani さんのセッションです。 re:Invent 2025 は AI Agent 祭りだったと一言でまとめつつ、そんなかでも moomindani さんの注目したアップデートをいくつかピックアップして紹介してくださいました。 Iceberg v3 のスペックが出てきて、いろんなサービスでサポートされた S3 Tables が進化して、テーブルレプリケーションなどができるようになりより便利に Iceberg テーブルを扱えるようになった SageMaker Unified Studio がかなり変わって、簡単に始められるようになった S3 Tables は 2024 の re:Invent で登場して以来、大幅にアップデートされていることをまとめて知れて非常にありがたかったです！現地で Iceberg のセッションにいくつか参加しましたが、どれも大盛況で盛り上がりを感じたので要注目のテクノロジーだと感じています。 カミナシの re:Invent 補助事情 - カミナシ 原トリ (@toricls) カミナシの CTO であるトリさんからはカミナシの re:Invent 参加補助制度について紹介していただきました。 カミナシでは「全額補助(普通の出張)、一部補助、業務時間扱い、有給を使って勝手に行く」など柔軟に会社から受けられる補助を選択でき、それぞれの補助ごとに出すべきアウトプットなどの成果が決められています。 柔軟に自分の re:Invent にかける思いに合わせて補助を決められるいい制度だなぁと感じています やっぱり EC2 / JAM の勝ち方 [検索] - ゲスト 星 北斗 様 (@kani_b) 2人目のゲストセッションでは LayerX の星さんに登壇していただきました。 星さんは世の中はサーバレスに染まっているがこだわりを持って EC2 のセッションを受けてきたとのこと。 昨今の EC2 はインスタンスの種類が豊富で様々な選択肢があります。適切に選ぶことでコスト効率がよくなることや Flex インスタンスなどの紹介をしていただきました。 また今回の re:Invent で AWS JAM（競技形式の技術演習）で優勝したとのことで星さん流、勝ち方のポイントを教えてくださり、さらに優勝景品を紹介していただけました。 教えていただいた勝ち方のポイントは私も勝ちたいのでここには書きません^^ re:Invent Lv.500 セッションの歩き方 LLM の未知の未知を知る - カミナシ 高井 真人 (@manaty0226) 最後はカミナシエンジニアのまなてぃさんの発表です。 re:Invent や re:Inforce, AWS Summit ではセッションごとに難易度別に Level がつけられています。Level 500 のセッションに参加しどんな紹介があったか、どんな雰囲気だったかを紹介していただけました。 詳細についてはブログでも記載してくださっているのでそちらを御覧ください！ kaminashi-developer.hatenablog.jp 懇親会の様子 発表が終わったあとは懇親会として re:Invent の話しで盛り上がりつつ、技術の話しで盛り上がりました。 会場の案内をするごーとん(弊社マスコット) まとめ カミナシ Tech Night #1 大成功だったと思います！ご参加いただけた皆様、ありがとうございます。 初開催で緊張しましたが、登壇者の皆さんの熱い発表と参加者の皆さんの温かい雰囲気のおかげで、とても良いイベントになりました。re:Invent に行った人も行けなかった人も、最新のAWSの動向をキャッチアップできる良い機会になったのではないでしょうか。 また Tech Night を開催したいと思いますのでぜひお楽しみに！ 来年の re:Invent 2026 に向けて、すでにカミナシメンバーは何人か航空券を予約済みとのこと。Slack には「re:Invent 2026」チャンネルが爆誕しています。 re:Invent 2026 でお会いしましょう！
- AWS
- セキュリティ
- AI
- データベース
- インフラ