はじめに こんにちは、情報セキュリティ部の 兵藤 です。日々ZOZOの安全を守るためSOC業務に取り組んでいます。 本記事では、開発環境におけるサプライチェーン対策として、Takumi Guardを全社展開した事例について紹介します。 また、情報セキュリティ部ではその他にもZOZOを守るための取り組みを行っています。詳細については以下の「Claude CodeがSOC業務を全自動でやってくれるってさ」をご覧ください。 techblog.zozo.com 目次 はじめに 目次 背景と概要 Takumi Guardとは Takumi Guardの対応エコシステム Takumi Guardの適用範囲 Takumi Guardの全社展開 コンテナでのTakumi Guard利用 MDMでのTakumi Guard配布 シークレットの問題 Takumi Guardの爆速アップデート対応 許可の設定をEntra側に寄せる シークレットの閲覧 デバイススクリプトの更新権限 Push Ruleset 展開後のログ画面 おわりに 背景と概要 昨今ではサプライチェーン攻撃の脅威が増しており、2026年3月には開発環境でよく使われる axios などが侵害されました。 このような事例から開発環境におけるセキュリティ対策の重要性が高まっています。特に、開発者が使用するツールやパッケージの安全性を確保することは、プロダクトセキュリティに直結します。 そこで、私たちは開発環境におけるサプライチェーン対策として、Takumi GuardをMDM経由で全社展開しました。 Takumi Guardとは Takumi Guard は、GMO Flatt Securityが提供する、悪意のあるパッケージの検知・ブロックを行うツールです。個人利用であれば無償ですが、組織として全端末に展開したり、ログを収集したりする場合は有償の契約が必要です。 詳しくは公式ドキュメント 1 をご覧ください。 Takumi Guardの対応エコシステム Takumi Guardはエンジニアが利用する開発言語における悪意のあるパッケージを検知・ブロックできます。2026年7月27日時点では、以下のエコシステムに対応しています。 npm PyPI RubyGems Go Packagist 2026年4月当初はまだ npm や PyPI までしか対応していませんでしたが、現在では RubyGems や Go 、 Packagist にも対応しており、開発速度が凄まじいです。 Takumi Guardの適用範囲 Takumi Guardの適用範囲は、大きく開発端末とCI/CD環境の2つに分けられます。 弊社ではGitHub ActionsをCI/CD環境として利用しています。このCI/CD環境にもTakumi Guardを導入でき、 公式ドキュメント に簡易手順が記載されているため導入は容易です。手順に記載されているBot IDを利用すると、GitHub Organizationに紐づくリポジトリへTakumi Guardを導入し、ログを後から確認できます。 BotはTakumi Guardのポータルから以下の項目で追加できます。 Botの追加 作成されたBotは「設定」の項目から確認可能です。 Botの確認 Takumi Guardの全社展開 Takumi Guardを全社展開するにあたり、弊社では以下の項目に対応しました。 開発ガイドラインへのTakumi Guardの記載 GitHub Actions環境へのTakumi Guardの導入 全社端末へのMDM経由でのTakumi Guardの導入 これらの対応の中で工夫した点について紹介します。 コンテナでのTakumi Guard利用 GitHub Actions上でコンテナを利用する場合、コンテナ内でのレジストリプロキシについては flatt-security/setup-takumi-guard-npm@v1 などのActionsだけでは対応できません。 これらのActionsの outputs で registry-url や token を取得し、コンテナ内部に渡す必要があります。 この点には注意が必要です。ビルド時に渡す場合、 --mount=type=secret を利用してコンテナ内部に token を渡します。そして、 npm install などを実行する際には同じ RUN 内で完結させる必要があります。別の RUN で実行すると、イメージのレイヤーに token が残ってしまうため、セキュリティ上の懸念があります。 DockerfileやGitHub Actionsのワークフローについては以下のようなものを参考として作成し、全社へ共有しました。 FROM node:20 WORKDIR /app COPY package.json package-lock.json ./ # secretマウントし、そのRUNの中だけで .npmrcを作って使い、最後にrm RUN --mount=type=secret,id=takumi_token \ printf 'registry=https://npm.flatt.tech/\n//npm.flatt.tech/:_authToken=%s\n' \ "$(cat /run/secrets/takumi_token)" > /tmp/.npmrc && \ export NPM_CONFIG_USERCONFIG=/tmp/.npmrc && \ npm ci && \ npm install some-extra-package && \ rm -f /tmp/.npmrc - name : Build image env : TAKUMI_TOKEN : ${{ steps.takumi.outputs.token }} run : | docker build \ --secret id=takumi_token,env=TAKUMI_TOKEN \ -t myapp . PyPIの場合は pip install を実行した際、 ~/.cache/pip にレスポンスの情報などが残ってしまいます。トークンがそのまま残るわけではありませんが、 --no-cache-dir を利用してキャッシュを残さないようにするのがベターです。 FROM python:3.13-alpine WORKDIR /app ... # Takumi Guardのトークン入りPIP_INDEX_URLをsecretとしてマウント RUN --mount=type=secret,id=pip_index_url \ export PIP_INDEX_URL="$(cat /run/secrets/pip_index_url)" && \ pip install --no-cache-dir --upgrade pip && \ pip install --no-cache-dir -r requirements.txt - name : Build image run : docker build --secret id=pip_index_url,env=PIP_INDEX_URL -t myapp . 上記の渡し方は一例のため、開発環境に合わせて適宜変更してください。 MDMでのTakumi Guard配布 ZOZOではMDMとしてMicrosoft Intuneを利用しています。Intuneでは、Macについては シェルスクリプト を利用してTakumi Guardのラッパースクリプトを配布できます。Windowsについては 修復スクリプト を活用できます。検出スクリプトをダミーで作成し、修復スクリプトでTakumi Guardのラッパースクリプトを配布する形です。 これらのスクリプトはIntuneで定期実行しています。何らかの理由でTakumi Guardが外れてしまった場合でも、次回の定期実行時に再度配布されます。 Takumi Guardのラッパースクリプトについては 公式ドキュメント に記載されています。 これらのスクリプトを利用することで、全社端末にTakumi Guardを配布できます。 シークレットの問題 Intuneでシェルスクリプトを配布する場合、シークレットをうまく扱えないという問題があります。この点が今後の課題です。対策としては、SCEP方式の証明書を端末に配布した後、中間APIサーバを立ててAzure Key Vaultからシークレットを取得する方法などが考えられます。 この作業には各部署との調整や、ラッパースクリプトの大幅な改修が必要です。また、少数チームにとっては実装と運用のコストが高くなります。 このため、Takumi Guardの展開遅延の懸念がありました。昨今のサプライチェーン攻撃の脅威を考え、Takumi Guardのトークンを払い出すだけのBotシークレットの権限であれば一旦このリスクは許容し、速度を優先することにしました。 この方法を実施する場合は、定期的にBotのシークレットのローテーションを行うなど、リスク軽減を図る必要があります。 またトークンの異常な発行が行われていないか発行量を適宜確認し、必要に応じて対応することも求められます。この点はKey Vaultなどを利用した場合も同様です。 Takumi Guardの爆速アップデート対応 上記以外にも対応すべきことはありました。それは、爆速で行われるTakumi Guardのアップデートへの追従です。 前述の通りTakumi Guardは日々アップデートされています。展開の仕組みを整えている途中でRubyGems対応の機能が追加された時は、その速度感に驚愕したことを覚えています。 この速度に追従するためには、利用する側でも同様のデプロイの仕組みを整えておく必要がありました。ZOZOではGitHub Actions経由でIntuneのラッパースクリプトを更新する仕組みを整え、Takumi Guardの爆速アップデートへ追従できるようにしました。 以下がmacOSにおけるラッパースクリプトの更新のワークフローです。 name : Deploy Takumi Guard macOS script to Intune on : push : branches : - main paths : - scripts/install_takumiguard.sh permissions : contents : read id-token : write concurrency : group : intune-takumi-guard-mac cancel-in-progress : false jobs : deploy-macos-script : name : Deploy Takumi Guard macOS script runs-on : ubuntu-latest timeout-minutes : 30 steps : - name : Checkout uses : actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with : persist-credentials : false - name : Azure Login uses : azure/login@532459ea530d8321f2fb9bb10d1e0bcf23869a43 # v3.0.0 with : client-id : ${{ vars.AZURE_CLIENT_ID }} tenant-id : ${{ vars.AZURE_TENANT_ID }} allow-no-subscriptions : true - name : Fetch TG Bot API key from Key Vault id : keyvault env : AZURE_KEY_VAULT_NAME : ${{ vars.AZURE_KEY_VAULT_NAME }} run : | set -euo pipefail : "${AZURE_KEY_VAULT_NAME:?Set AZURE_KEY_VAULT_NAME in GitHub Actions variables}" api_key="$(az keyvault secret show \ --vault-name "${AZURE_KEY_VAULT_NAME}" \ --name tg-bot-api-key-mac \ --query value \ -o tsv)" if [ -z "${api_key}" ] ; then echo "Failed to fetch tg-bot-api-key-mac from Key Vault ${AZURE_KEY_VAULT_NAME}" > &2 exit 1 fi echo "::add-mask::${api_key}" echo "api_key=${api_key}" >> "${GITHUB_OUTPUT}" - name : Resolve target Intune macOS script env : INTUNE_TAKUMI_MAC_SCRIPT_ID : ${{ vars.INTUNE_TAKUMI_MAC_SCRIPT_ID }} run : | set -euo pipefail : "${INTUNE_TAKUMI_MAC_SCRIPT_ID:?Set INTUNE_TAKUMI_MAC_SCRIPT_ID in GitHub Actions variables}" echo "TAKUMI_MAC_SCRIPT_ID=${INTUNE_TAKUMI_MAC_SCRIPT_ID}" >> "${GITHUB_ENV}" echo "TAKUMI_MAC_SCRIPT_RESOURCE=deviceManagement/deviceShellScripts" >> "${GITHUB_ENV}" - name : Update Intune macOS script shell : bash env : SCRIPT_PATH : scripts/install_takumiguard.sh TG_BOT_API_KEY_MAC : ${{ steps.keyvault.outputs.api_key }} run : | set -euo pipefail : "${TG_BOT_API_KEY_MAC:?Failed to resolve tg-bot-api-key-mac from Key Vault}" echo "::add-mask::${TG_BOT_API_KEY_MAC}" build_script_content() { local api_key_literal api_key_literal="$(printf '%s' "${TG_BOT_API_KEY_MAC}" | perl -0pe 's/([\\\"\$`])/\\$1/g' )" API_KEY_EXPORT_LINE="export TG_BOT_API_KEY=\"${api_key_literal}\"" awk ' /^export TG_BOT_API_KEY=/ { print ENVIRON["API_KEY_EXPORT_LINE"] replaced += 1 next } { print } END { if (replaced != 1) { printf("Expected one TG_BOT_API_KEY export line, found %d\n", replaced) > "/dev/stderr" exit 1 } } ' "${SCRIPT_PATH}" | base64 -w 0 } script_content="$(build_script_content)" access_token="$(az account get-access-token \ --resource https://graph.microsoft.com \ --query accessToken \ -o tsv)" echo "::add-mask::${access_token}" response="$(printf '%s' "${script_content}" \ | jq -Rnc '{scriptContent: input}' \ | curl -sS -w " \n %{http_code}" \ -X PATCH "https://graph.microsoft.com/beta/${TAKUMI_MAC_SCRIPT_RESOURCE}/${TAKUMI_MAC_SCRIPT_ID}" \ -H "Authorization: Bearer ${access_token}" \ -H "Content-Type: application/json" \ --data-binary @-)" http_status="${response## *$'\n' } " if [ "${http_status}" = "200" ] || [ "${http_status}" = "204" ] ; then echo "Updated Takumi Guard Intune macOS script (${http_status})" else echo "Failed to update Takumi Guard Intune macOS script (${http_status})" echo "Response body omitted to avoid leaking scriptContent." exit 1 fi - name : Verify Intune macOS script update shell : bash env : SCRIPT_PATH : scripts/install_takumiguard.sh TG_BOT_API_KEY_MAC : ${{ steps.keyvault.outputs.api_key }} run : | set -euo pipefail : "${TG_BOT_API_KEY_MAC:?Failed to resolve tg-bot-api-key-mac from Key Vault}" echo "::add-mask::${TG_BOT_API_KEY_MAC}" build_script_content() { local api_key_literal api_key_literal="$(printf '%s' "${TG_BOT_API_KEY_MAC}" | perl -0pe 's/([\\\"\$`])/\\$1/g' )" API_KEY_EXPORT_LINE="export TG_BOT_API_KEY=\"${api_key_literal}\"" awk ' /^export TG_BOT_API_KEY=/ { print ENVIRON["API_KEY_EXPORT_LINE"] replaced += 1 next } { print } END { if (replaced != 1) { printf("Expected one TG_BOT_API_KEY export line, found %d\n", replaced) > "/dev/stderr" exit 1 } } ' "${SCRIPT_PATH}" | base64 -w 0 } access_token="$(az account get-access-token \ --resource https://graph.microsoft.com \ --query accessToken \ -o tsv)" echo "::add-mask::${access_token}" expected_script_content="$(build_script_content)" actual_script_content="$(curl -sS \ "https://graph.microsoft.com/beta/${TAKUMI_MAC_SCRIPT_RESOURCE}/${TAKUMI_MAC_SCRIPT_ID}" \ -H "Authorization: Bearer ${access_token}" \ -H "Accept: application/json" \ | jq -r '.scriptContent // empty' )" if [ "${actual_script_content}" != "${expected_script_content}" ] ; then echo "Takumi Guard macOS scriptContent verification failed" > &2 exit 1 fi echo "Verified Takumi Guard Intune macOS scriptContent" ポイントがいくつかあるため、以下の章で解説します。 許可の設定をEntra側に寄せる GitHub Actionsのワークフローでは Azure Login のOIDCでEntraのサービスアカウントにログインします。固定のシークレットを極力持たせたくないため、この構成を採用しました。 シークレットの閲覧 シークレット情報はGitHub Organizationの権限で管理するのではなく、EntraやARM側に寄せました。GitHub ActionsのワークフローからはEntraのサービスアカウント経由でAzure Key Vaultからシークレットを取得する形です。 取得のために Key Vault Secrets User のRoleを対象のKey Vaultに絞って、このサービスアカウントへ付与する必要があります。 Actions上ではメモリ上でシークレットを扱い、ログに出力されないように ::add-mask:: を利用してマスクしています。 ただ、前述のとおりIntune上ではシークレットが残ってしまいますが、この閲覧権限もIntuneの権限を付与できるEntraで管理できるので、Entraでの権限設定が重要です。 デバイススクリプトの更新権限 この権限もEntra側のサービスアカウントに付与します。 Microsoft Graph APIの deviceManagement/deviceShellScripts のエンドポイントを呼び出す必要があります。これは強い権限のため、上記ワークフローを実施するスクリプトの main ブランチへの変更を厳しく確認する必要がありました。 Push Ruleset そもそも、このリポジトリを閲覧できるアカウントを絞ることが前提です。加えて、そのアカウントによるPushにも制限が必要です。 このActionsは、 main ブランチへのpushかつ scripts/install_takumiguard.sh に変更があった場合のみ実行されるようにしています。 この変更についてはGitHubの Rulesets で管理しています。以下の項目を設定しておくとPRでレビューの通ったものがマージされるようになります。 Restrict deletions Require a pull request before merging Block force pushes 基本的にこのRuleのバイパスは設定せず、一律PRのレビューを通すようにしています。これにより、リポジトリの変更がある場合は必ずレビューが入るようになります。 レビュー者は .github/CODEOWNERS で設定しておくと、PR作成時に自動でレビュー依頼が飛びます。 展開後のログ画面 パッケージのダウンロードログはTakumiのポータルから確認できます。ブロックなどの条件で絞り込むことで、どのパッケージがブロックされたかを簡単に確認できます。 展開後のログ画面 おわりに 本記事では、開発環境におけるサプライチェーン対策として、Takumi Guardを全社展開した事例について紹介しました。 まだまだ課題はありますが、Takumi Guardの導入により、開発環境におけるサプライチェーン攻撃のリスクを低減しました。 ZOZOでは、一緒に安全なサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ hrmos.co Takumi Guard ↩

商社系DX組織3社（Digital Experts様、MBKデジタル様、Insight Edge）が集まり、AI活用戦略から組織改善の取り組みなど互いの知見を共有する情報交流会を開催しました。 ※本記事では、企業名を併記する際は、Insight Edge以外をアルファベット順に記載しています（各社の取り組みLTは発表順）。 今回はInsight Edgeが発起し、CTO猪子のリードのもと、この記事の筆者の肥塚が共有会の企画や運営を行わせていただきましたので、共有会を企画するに至った経緯、共有会の内容、企画・運営した際の学びを共有させていただきます。 Insight Edgeについて Insight Edge（弊社）は、住友商事グループのDX内製組織として https://insightedge.jp/business/ で紹介されている通り、総合商社のDX施策を非常に幅広い面から支援・実装しています。 ソフトウェアエンジニア、データサイエンティスト、プロジェクトマネージャー、コンサルタント、デザイナーなど幅広い人材が所属し、価値を共創していることが特徴です。 今回の交流会の企画に至った経緯について 弊社は、住友商事グループのDX内製組織ですが、他の総合商社グループにも技術面から価値創造を行っている企業様がいらっしゃいます。 それらの企業様と組織改善のヒントを互いに伝え合う手段が欲しいという声が上がったため、丸紅グループのDigital Experts様、三井物産グループのMBKデジタル様と共に、今回の「商社系企業情報交流会」の企画に至りました。 交流会の概要について 以下の要領にて実施しました。 場所: MIRAI LAB PALETTE 日時: 2026年5月21日 参加企業: Digital Experts様、MBKデジタル様、Insight Edge 参加人数: 42名 ※参加企業は、Insight Edge以外をアルファベット順に記載しています。 アジェンダ 以下のアジェンダにて実施しました。 オープニング 弊社CTO猪子からご挨拶 各社の概要紹介 各社の取り組みLT 立食 クロージング 弊社CEO小坂からご挨拶 立食形式にて皆さんにご歓談いただきましたが、大変盛況でした！ 立食の様子。写真は参加者の許可を得て掲載しています。 各社の取り組みLTについて アジェンダの中でも、各社の取り組みLTでは各社のカラーがよく出ていたので、ご紹介いたします！ ※本記事に記載されている他社製品情報は公開情報です ※各社の取り組みLTは、発表順に記載しています。 MBKデジタル様のご発表 MBKデジタル様のCTO岩尾様から 「AI モデルが賢くなるほど強くなる組織をつくる — 情報資産・プロダクト・プロセスの設計 —」 という題にてご発表いただきました。 従来はAIの新しいモデルやツールを個別に追いかけるのが主流でしたが、MBKデジタル様では会社としてAIの進化を享受しやすいように、以下の点にて整備を行っているということでした。 情報資産 議事録、案件情報、商談履歴などのデータをAIが読める形に蓄積し、後でAIが活用しやすくする プロダクト AIの進化を会社の提供価値とするべく、データからAIが自然言語で示唆出しを行う「BI Suite」や、業務に特化したAIアプリをGUIで構築できる「AI Craft」を開発・外販している 開発・業務プロセス 実装などの開発プロセス、資料づくりなどの業務プロセスを人間が最初からやるのではなくAIに実行させ、人間は「判断・検証・説明責任」に寄せる Digital Experts様のご発表 Digital Experts様の技術部長の松原様から 「組織強化の観点から見るDigital Experts の取り組み - 制度・技術・人財」 という題にてご発表いただきました。 「内製組織」と「外部展開」の2つを支える軸として「組織強化」を据え、以下の観点についてご共有いただきました。 社内プロセス改善 制度をプロダクトとして捉え、継続的にアップデートする トップダウンではなく、全員がフラットに議論してその場で決める、現場発の意思決定 技術カルチャー 2週間に1回の頻度で持ち回りでLT会を行う AIを業務に導入。有志でプロトタイプ開発を行い、効果検証後に標準化 丸紅グループ全体に展開されたMarubeni Chatbot 外部展開体制の強化 内製したプロダクトの外販を行う。限られたリソースで運用するべく自動化や生成AIの利用を徹底すると共に、商社の幅広い販売チャネルを活用 FTO調査や自社特許の取得促進などの知財戦略の強化 採用 生成AIを活用した自走力の高い方を採用する一方、心理的安全性を担保する組織づくり Insight Edge 弊社では「みんなでやる」精神のもと、市川とニャットの2名にて発表を行いました。 市川からは「技術向上WGの取り組み」、ニャットからは『「やってみる?」のひとことから始まった、初めてのアドベントカレンダー』という題で発表いたしました。 技術向上WGの取り組み 業務で利用するLLM周辺領域をテーマに、ケイパビリティ向上や認知拡大、客観的な技術力の証明を目的とした取り組みを紹介しました。 特に言語処理学会第32回年次大会（NLP2026）においては、Insight Edgeは大手企業を上回る7件の発表（参加企業中5位、社内集計より引用）を行い、注目を集めました。 「やってみる?」のひとことから始まった、初めてのアドベントカレンダー 2025年度にテックブログのアドベントカレンダーに挑戦した時の取り組みを紹介しました。記事のレビューエージェントや企画を盛り上げるSlackボットなど、ユニークな施策のもとアドベントカレンダーを無事に完走し、Insight Edgeのバリューである「やってみる」「みんなでやる」「やり抜く」を体現した企画でした。詳細は こちら からご覧ください。 交流会実施の結果 実施後、Insight Edgeの参加者に対してアンケートを行いました。 発表や食事含めて大変好評でした。 Insight Edge社内アンケート結果（2026年5月実施） いくつかの声をご紹介します。 Digital Experts様、MBKデジタル様が推進している自社プロダクトの外販について興味を示す声が多いのが印象的でした。 各社の変遷やその中での課題についてInsight Edgeと通ずるものがあり参考になりました。 生成AIの社内業務活用の例をもっと聞きたかったです。 このように、各社の多彩な取り組みに興味を示す声がとても多く寄せられました。 個人的には、LTをお聞きし、OAMチームの一員として保守運用における生成AI活用深化や社内事例の整備を行っているので、とても参考になりました。 ご参加いただきましたDigital Experts様、MBKデジタル様につきましても、情報交換する中で刺激になったためまたご相談させてほしいという声や、同業他社でありながら異なる規模の会社の話を聞けて面白かったという声をいただきました。 交流会実施の感想 今回の商社系企業情報交流会では、CTO猪子のリードのもと、自分が運営全般業務や司会を担当しました。 Insight Edge内外の皆さんが、準備や後片付けに快くご協力くださり、大変ありがたく感じました。 また、発表時やご歓談時は大変盛り上がり、商社らしいなあと感じました。 特にLT発表会では、「AI技術をどう使い、自社、ひいては自社グループの価値創造に貢献するか？」という点に各社それぞれのカラーが出ていて興味深かったです！ 次回実施する機会があれば、またぜひ運営に参加したいと思います。 一緒に価値を創る仲間を募集しています 今回の交流会を通じて改めて感じたのは、生成AIの進化によって技術そのものは急速に変化していく一方で、組織として学び続け、挑戦し続ける文化こそが競争力になるということです。 技術を磨くだけではなく、 新しい技術を実際の事業価値につなげたい方 生成AI時代のエンジニアリングやデータ活用のあり方を一緒に切り拓いていきたい方 そんな方とぜひ一緒に働きたいと考えています。 少しでもInsight Edgeに興味を持っていただけた方は、ぜひ採用ページもご覧ください。カジュアル面談も歓迎しています。 👉 https://herp.careers/v1/insightedge 今後も、このような企業間の交流を通じて得られた知見を積極的に発信し、日本全体のDX・AI活用の発展にも貢献していきたいと思います。

こんにちは！ 株式会社スタメン 、プラットフォーム部のもりしたです。 7月10日（金）・11日（土）の2日間、東京のTOC有明で開催された SRE NEXT 2026 に参加してきました！ 昨年の SRE NEXT 2025 （昨年のブログは こちら ）ではLOGOスポンサーとしての参加でしたが、今年は SILVERスポンサー としてブース出展を行いました。 本記事では、ブース企画の様子と印象に残ったセッションについてレポートします。 SRE NEXT 2026 スポンサーボードの前で記念撮影。SILVERスポンサーにスタメンのロゴが！ SRE NEXT 2026 の雰囲気 昨年に引き続き、TOC有明での開催でしたが、ブース会場の部屋が変わったこともあってか、昨年よりも広く感じました。 公式の来場者数は確認できていませんが、昨年と比べて参加者が増えた印象で、ブース会場全体に活気がありました。 ブース会場の様子。中央にスタメンブースが見えます 懇親会は昨年と同じ会場でした。 食事もお酒も充実しており、楽しい時間を過ごせました。 懇親会の様子。鏡開きも行われ大いに盛り上がりました スタメンのブース出展 SRE関連カンファレンスでのスポンサーは、今年5月に名古屋で開催した クラウドネイティブ会議 に続き2回目です。 2日間で約 180名 の方にお越しいただきました！ カンファレンス中の運営メンバーはすべて東京本社で働いているスタメンのエンジニアです。写真には載っていないメンバーを含めて、合計 6名 でブースを運営しました。 スタメンブースの様子。お揃いのベースボールシャツでお出迎え！ ブースに設置したパネルはデザイン部が担当。複数の部署が協力してカンファレンスの準備を進めています。 ブース企画：アンケートに答えてスタメンオリジナルのノベルティをGETしよう！ ブースでは、アンケートにお答えいただいた方にスタメンオリジナルのノベルティをお渡しする企画を実施しました。 ノベルティ キーキャップキーホルダー （スタメンの s, t, m, n の文字入り） スタメンロゴ入りマイクロファイバークロス アンケート結果 アンケートパネル。シールを貼って回答いただきました アンケートは2問で、以下のような結果になりました。 Q1. 今年カンファレンスに参加した回数は？ 選択肢 結果 2〜3回 🥇 1番多い 1回（SRE NEXT 2026 が初） 🥈 2番目に多い 4〜5回 🥉 3番目 6回以上 4番目 1月に開催された SRE Kaigi 2026 に参加され、今回の SRE NEXT 2026 が2回目という方が多かったです。中には クラウドネイティブ会議 にも参加されたという方もいらっしゃいました。 tech.stmn.co.jp Q2. あなたの組織の「SRE」の現状は？ 選択肢 結果 独立したSREチームがある 🥇 圧倒的に多い 各開発チームにSRE担当がいる 🥈 2番目に多い これからSREを立ち上げる・検討中 🥉 3番目 SREチームの立ち上げ予定がない 4番目 SREのカンファレンスということもあり、「独立したSREチームがある」が圧倒的に多い結果でした（笑）。 「各開発チームにSRE担当がいる」は 『独立したSREチームも別にあるんですよね』というお話をいただくことが多く、開発チームにSRE担当がいる場合でも、横断的なSREチームが存在するケースが多いと感じました。 「SREチームの立ち上げ予定がない」は、エンジニア組織の規模的にSRE相当の役割を兼務で担っているケースや、SRE立ち上げの支援を行っている企業のため自社にはチームがないというケースがありました。 学びがあったセッション Day1・Day2 を通じていくつかのセッションを聴講しました。 すべて学びがありましたが、それぞれ1つずつピックアップしてご紹介します。 Day1：ABEMAにおける Incident Management 再設計 株式会社AbemaTV SRE/EM 宮﨑 大芽さんによるセッション speakerdeck.com 障害対応自体は回っているものの、「誰が指揮をとるのか」「役割が明確でない」といった課題を抱えていた AbemaTV 社が、Incident Management を再設計した事例のお話でした。 障害対応に関わる定義の明確化や、障害対応をサポートする Bot のブラッシュアップが紹介されました。 Bot では SEV（Severity：障害重大度）判定を直感的に行える仕組みが導入されるなど、実践的な改善が印象的でした。 特に心に残ったのは、 「仕組みを提供しただけでは組織に浸透しない」 というお話です。 Incident Commander の役割を明確に定義したにもかかわらず、実際に障害が発生すると、メンバーは慣れた動き方でぱぱっと対応を進めてしまい、再設計した定義に沿った動きにはならなかったそうです。 私自身も昨年、障害対応の流れや Incident Commander の担当ルールなどを整理した障害対応マニュアルを作成しましたが、現実にはその通りに運用できていない部分があります。 組織への浸透の難しさ、そして難しくても地道に浸透させていくことの大切さに改めて気付かされたセッションでした。 Day2：SREとQA、二人三脚で進めるSLO運用 株式会社estie SRE 杉田 毅博さんによるセッション speakerdeck.com マルチプロダクト体制への移行期に障害が多発する中、SRE と QAE（QA Engineer）が協力して CUJ（Critical User Journey）を定めた事例のお話でした。 発表タイトルは「SLO運用」でしたが、セッションの内容は CUJ の整備と SRE・QAE の協力体制が中心でした。 SRE と QAE は同じ「顧客価値」という目標を異なる視点から見ており、協力し合うことでお互いの強みを活かし、品質を高めていけるという内容に学びがありました。 この事例では、Platform 型の SRE は多くのプロダクトを横断的に見ているため、個々のプロダクトへの理解は深くありません。 一方、QAE はプロダクトのチームに深く入り込み、CUS（Core User Scenarios）という最重要ユーザーシナリオをチームとの合意のもとに作成していました。 SRE は QAE と協力して CUS の中から最も重要なものを CUJ として選定することで、本来最も難しい「チームとの合意」を経た CUJ を整備することができたのです。 私自身もこの事例の Platform 型 SRE と同様の立場にあり、プロダクトに深く入り込めているとは言えません。 深い知見はプロダクト開発メンバーや QAE の方が持っています。 互いの強みや視点の違いは対立するものではなく、補完し合うもの。1つのチームに閉じていたら進まなかった課題も、チームを越えた協力で解決できるという学びを得たセッションでした。 ブース運営を経験して 私自身は今年に入って RubyKaigi 2026、クラウドネイティブ会議、そして SRE NEXT 2026 と、7月時点で3回のブース運営を経験しました。 長くエンジニアをやっていても、ブース運営の経験がある人は意外と少ないのではないでしょうか。今年だけで3回も担当できたことは、とても貴重な経験だと感じています。 普段お話しする機会のない他社のエンジニアや学生の皆さんとの会話はいつも楽しく、よい刺激をいただいています。 さいごに SRE NEXT 2026 では、ブース出展を通じて多くの方と交流でき、セッションからも実践的な学びを得ることができました。今回の学びを日々の業務に活かし、スタメンのプラットフォームをより信頼性の高いものにしていきたいと思います。 今回レポートした Site Reliability Engineer (SRE) や Platform Engineering の領域にご興味のある方は、ぜひご応募ください！ herp.careers