開発チームに入ってセキュリティを向上するということ
「カミナシ レポート」の開発・運用をしている、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
- 開発プロセス