はじめに 2026年6月25日、26日に幕張メッセで開催された AWS Summit Japan 2026において、AIエージェントによる建設機械のフリート管理デモ「産業機械の自律診断とリアルタイム安全監視」を展示しました。本記事では、このデモの技術的な構成と考え方を解説します。 建設機械や産業機械の保全業務では、機械の異常をいかに早く検知し、いかに早く適切な対処につなげるかが稼働率を左右します。また、日本をはじめ多くの国で熟練技術者の高齢化と労働力不足が進行しており、保全業務の担い手の確保は年々困難になっています。フリート運用の現場では、機械の情報が現場や機体ごとに分散して全体状況が把握できないこと、故障対応が熟練者の経験に依存することが課題となり、結果として復旧に時間と人手がかかります。センサーデータに基づく予知保全はこの課題への代表的なアプローチですが、従来の機械学習による異常検知には「異常が起きていることは分かるが、なぜ起きているのか、何をすべきかまでは分からない」という限界がありました。異常スコアを受け取った保全担当者は、結局マニュアルを調べ、過去の類似事例を探し、対処方針を自分で組み立てる必要があります。 本デモはこの課題に対し、IoT による遠隔監視で分散した情報を集約して機械の状態を可視化し、生成 AI エージェントが異常の一次分析と情報収集を自動で行うことで、保全担当者が判断と対処に集中できる環境を作る構成としています。エージェントが原因候補と対処手順をあらかじめ提示することで、経験の浅い担当者でも初動対応に着手しやすくなり、熟練者は高度な判断が求められる場面に集中できます。人手による報告、古典的な機械学習、そしてエージェント型の予知保全という3 つのアプローチを同一のフリートに対して並べて体験できる構成とし、それぞれの特性の違いが分かるようにしています。さらに、検知した異常に対する診断、チケット起票、オペレーターへの音声通知、実機の遠隔操作までを含めたエンドツーエンドのデモとして構築しました。 デモ概要紹介の動画は こちら からご覧いただけます。 デモの全体像 デモのシナリオは、建設機械メーカーのアフターサービス部門が、顧客先で稼働する 20 台の掘削機を遠隔監視し、サポートを提供するという設定です。東京エリアの各現場に散らばる掘削機はエンジン温度、エンジン回転数、油温、油圧、冷却水温度、クーラント残量、燃料残量といったテレメトリを送信しており、ダッシュボードではフリート全体の状態を一覧できます。 フリートマップは Amazon Location Service で構築しており、各機体の位置と状態 (Operational / Warning / Critical / Offline)を地図上に表示します。展示では、20 台のうち 19 台が正常に稼働し、1 台が異常状態にあるというシナリオを用いました。異常機体の存在を把握しマシン一覧に進むと、該当機体のエンジン温度と油温が異常に高いことをテレメトリから確認できます。分散していた機体の情報が一画面に集約されているため、異常の発見から状況の把握までがダッシュボード上で完結します。 Analytics 画面ではエンジン温度、エンジン回転数、油圧、燃料残量などの時系列チャートをリアルタイムに描画します。 デモ全体のアーキテクチャは、実機・エッジ・クラウドの 3 層で構成されています。実機側には ESP32 を搭載した掘削機の模型と、NVIDIA Jetson Orin Nano とカメラを組み合わせたエッジ推論環境があり、クラウド側では AWS IoT Core 、 AWS IoT SiteWise 、 AWS Lambda 、 Amazon DynamoDB を中心としたデータ基盤の上に、 Amazon Bedrock AgentCore と Strands Agents によるエージェント層を構築しています。詳細は後述します。 設計の考え方 デモの各機能を紹介する前に、設計にあたって重視した 2 つの考え方を説明します。なお、本デモの考え方は AWS Summit Japan 2026 のセッション「情報を集め、判断し、行動する時代へ:データ基盤・AI エージェント・エッジ AI で変わる製造現場」(IND327) でも解説しています。セッション資料は こちら からダウンロード可能です。 データにコンテキストを付与する センサーから届く生データは、センサー ID、タイムスタンプ、値、単位といった情報しか持ちません。「75.3 ℃」という値だけでは、それがどの現場の、どの機体の、どの部品の温度なのかが分からず、AI はもちろん人にも意味のある判断ができません。どの機体か、どの部位か、どの機種かといったコンテキストをデータに付与 (エンリッチ) して初めて、その値を「この機種の冷却系としては高すぎる」と解釈できるようになります。データの質と流れが AI の判断力を決める、というのが本デモの土台にある考え方です。本デモでは AWS IoT SiteWise のアセットモデルで機体・部位と計測値の関係を構造化し、エージェントが参照するテレメトリに機体のコンテキストが伴う状態を作っています。 人間と AI の役割分担を設計する AI を組み込んだシステムには、ルールベースの自動化、AI による支援、ゴール駆動型エージェントとの協働、完全自律型のエージェントというように、自律性の異なる段階があります。どの段階を採用するかは、対象業務のリスクと複雑性に応じて設計するものであり、既存のプロセスを単に AI に置き換えれば良いわけではありません。本デモの 3 種類のアラート(人手・古典的 ML・エージェント)は、後半に向けて自立度が高くなります。またデモ全体を通して、異常の検知や分析に必要な情報収集はエージェントが担い、機械を止めるか、現場に作業員を派遣するかといった判断は人間が行う、という役割分担で設計しています。 予知保全の 3 つのアプローチ 本デモの中心は、同じフリートに対する 3 つの異常検知アプローチの比較です。 人手による報告(Alerts – Human Driven) 最も基本的な形態として、現場の作業者が観察した異常を手動で報告するフォームを用意しました。機械、深刻度、タイトル、詳細を入力して起票します。人の観察は「油圧ポンプから変な音がする」といった、センサーには現れにくい定性的な情報を含む点で価値がありますが、報告のタイミングと粒度が人に依存し、状態を定量的に捉えて比較・追跡することができません。フリートが大きくなるとスケールしないという限界もあります。 古典的な機械学習(Alerts – Classical PM) 次の段階として、Amazon SageMaker AI 上に構築した古典的な機械学習パイプラインによる異常検知を実装しました。このパイプラインは、正常運転時のテレメトリから学習したモデルで各機体を継続的にスコアリングし、平常時からの逸脱が大きいときにアラートを発報します。デモの画面では、フリート 20 台それぞれの異常スコアと、予測値と実測値の乖離をチャートで確認できます。異常が進行している機体では、エンジン温度の実測値がモデルの予測レンジから外れていく様子が見て取れます。このアプローチはスケールし、人の観察より早く統計的な逸脱を捉えられます。一方で、アラートに含まれるのは異常スコアという数値だけで、原因や対処までは示されません。異常が起きていることは検知できても、なぜ起きているのかは説明できない。この点が古典的な機械学習による予知保全の限界であり、次のエージェント型アプローチが価値を発揮するところです。 エージェント型予知保全(Alerts – Agentic PM) エージェント型の予知保全では、Amazon Bedrock AgentCore と Strands Agents で構築した AI エージェントがテレメトリを監視し、異常を検知した際に原因分析と推奨アクションを含むアラートを生成します。たとえばデモでは「エンジン温度 95.2 ℃ と油圧低下 48.5 PSI の組み合わせはエンジン故障が差し迫っているリスクを示している。ただちに掘削機を停止し、点検を実施すること」といった、複数のテレメトリを組み合わせた解釈と具体的な対処指示を含むアラートが発報されます。単一メトリクスの閾値超過ではなく、エンジン温度と油圧の同時異常からオイルシステムの問題を推定するといった、保全担当者が行う推論に近い分析が行われる点が古典的 ML との違いです。アラートを受け取った担当者は、原因の調査から始めるのではなく、提示された分析と対処の妥当性を確認するところから対応を始められます。 もうひとつの特徴は、アラートルールの管理を自然言語で行える点です。「エンジン温度が 90 ℃ を超えたら警告して」「燃料レベルのアラートを無効化して」といった指示を入力すると、エージェントが予知保全モニターの使用するルールを更新します。閾値の調整のたびに設定画面を操作したりコードを変更したりする必要がなく、運用者の意図を直接ルールに反映できます。アラートの感度調整は運用を続けながら繰り返し行う作業であるため、この調整を運用者自身で完結できることは運用負荷の軽減につながります。 検知から対処までをエージェントで支援 異常の検知は保全業務の入口にすぎません。本デモでは、検知の後工程である診断、起票、通知、対話までをエージェントで支援する構成としました。 チケットの起票と AI 分析 アラートが発報された後のチケット起票は、人間が行います。担当者はアラート画面からエージェントに原因と対応策の分析を指示します。アラートはアラート画面で管理しますが、メールや SMS で通知することも可能です。人間から指示を受けた後、エージェントはマニュアルやテレメトリデータを自動で収集し、原因の特定と現場作業員向けの作業指示を作成します。チケットサービスはデモ内に MCP 経由で接続されており、担当者は分析結果を確認したうえで、アラート画面からそのままチケットを起票できます。起票されたチケットには、エージェントの分析結果が日本語で付与されます。たとえば「掘削機 001 はエンジン冷却水温度が 94.7 度と高く、C62 および C65 のオーバーヒート関連の故障診断コードが検知されています」といったように、テレメトリの値と診断コードを突き合わせた診断が記載されます。 異常の検知と、分析に必要な情報の収集はエージェントが行い、現場に作業員を派遣するかどうかの判断とチケット起票は人間が行う — このように分担することで、複雑な現場保全を効率的に進められます。分析にあたってエージェントは、後述する Knowledge Base を検索し、機器マニュアルや診断コードの定義を参照します。テレメトリ (定量データ) と技術文書 (定性情報) を組み合わせて、状況を総合的に判断させています。チケットには深刻度とステータスが付与され、Ticketing 画面で一覧・検索できます。診断コードの意味をマニュアルで調べるという一次診断と、機体名やテレメトリ値の転記が不要になるため、担当者の作業は分析内容の確認と派遣の判断に絞られます。また分析結果が日本語で記載されるため、現場の担当者がそのまま読んで対応に移れます。 Knowledge Base による技術文書の検索 Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless で、機器マニュアル、診断コード一覧、保守手順書を検索できるナレッジベースを構築しました。「掘削機のオーバーヒートに関する診断コードは何か」「油圧ポンプの交換手順は」「緊急停止の手順は」といった質問に、文書に基づいた回答を返します。このナレッジベースは、チケット起票時の AI 分析と、次に述べる音声通知の両方から参照されます。 Amazon Connect による音声通知 検知と診断の結果を現場のオペレーターに届ける手段として、 Amazon Connect による架電機能を実装しています。エラーコードを指定すると、エージェントが Knowledge Base からトラブルシューティング手順を検索し、その要約を Text-to-Speech で読み上げる電話をオペレーターにかけます。同じ内容はメールでも送付されます。ダッシュボードを見ていない現場の担当者にも、異常の内容と初動手順が音声で届くという体験です。 双方向の音声対話 通知にとどまらず、AI エージェントとオペレーターがリアルタイムに双方向で会話する音声対話も実装しています。エージェントは対象機体のライブテレメトリと診断結果のコンテキストを保持した状態で通話するため、オペレーターからの質問に答え、トラブルシューティングを対話的にガイドし、必要に応じてエスカレーションできます。一方向の読み上げと異なり、手順の途中で生じた疑問にその場で答えられるため、担当者への折り返し確認を減らせます。音声対話の基盤には Amazon Nova Sonic を利用しています。 AI Assistant これらの機能とは別に、フリート全体を対象としたチャット形式の AI Assistant も用意しています。Strands Agents によるマルチエージェント構成で、「フリートの状態は?」「掘削機-001 を診断して」「掘削機-003 のテレメトリを読んで」といった問い合わせに対し、フリート状態の照会、機体診断、ドキュメント検索を担当するエージェントが連携して回答します。現場の作業員はタブレットやスマートフォンからこのアシスタントを利用でき、展示ではエンジン温度が異常に高い機体への対応方法を質問する流れを紹介しました。診断コードやマニュアルの知識を持つ熟練者でなくても、その場で対応方法を引き出せることがこの機能の狙いです。 エッジと実機 クラウド側の機能に加えて、実機とエッジ推論を組み合わせた構成も実装しています。なお、今回の展示ではこの部分のデモフローは割愛しました。以下では、実装した構成を紹介します。掘削機の模型には ESP32 を搭載し、モーター、センサー、LED を MQTT で AWS IoT Core に接続しています。掘削機制御画面からは走行、キャビン旋回、アームの上下、非常停止(E-STOP)を遠隔操作でき、掘削機の状態は Unreal Engine で構築した 3D デジタルツインに反映されます。エッジ推論としては、NVIDIA Jetson Orin Nano 上で YOLO による物体検出と VLM(Vision Language Model)を組み合わせ、映像から安全に関わる状況をエッジ側で判定する構成を実装しました。また、 Amazon Kinesis Video Streams 03:06 PM と WebRTC による低遅延のライブ映像配信の上で、Amazon Bedrock による映像分析を行う構成も実装しています。「機材の近くに人が近づいたら通知して」のように監視条件を自然言語で定義でき、条件に合致するイベントが検出されると指定の方法で通知されます。この構成では、人の接近検知のような安全に関わる即時判断を Jetson 上のエッジ推論が担い、フリート全体の分析や診断をクラウド側のエージェントが担う分担を想定しています。 アーキテクチャ詳細 最後に、デモ全体のアーキテクチャを整理します。 データ基盤の層では、掘削機のアセット情報を AWS IoT SiteWise で管理し、実機からのテレメトリは MQTT で AWS IoT Core に取り込み、機体状態を Amazon DynamoDB に保持します。アラート、チケット、チャット履歴もそれぞれ DynamoDB のテーブルで管理し、生成・更新の処理は AWS Lambda と AWS Step Functions で実装しています。 エージェント層は Strands Agents で実装しています。アシスタント、シナリオ、ナレッジベース検索、チャット履歴といったエージェントは AWS Lambda(コンテナ)上で稼働し、音声対話エージェントは Amazon Bedrock AgentCore 上で稼働させています。エージェントから AWS IoT SiteWise などの OT/IT システムへのアクセスは MCP(Model Context Protocol) サーバーを介して行い、エージェントは目標に応じて必要なツールを自律的に選択・実行します。AgentCore はランタイム管理、認証、メモリ、可観測性といった、エージェントを本番運用するための基盤機能を提供します。ナレッジベースは Amazon Bedrock Knowledge Bases と Amazon OpenSearch Service で構成し、音声対話には Amazon Nova Sonic を利用しています。音声通知は Amazon Connect、メール等の通知は Amazon SNS が担います。 フロントエンドは Amazon CloudFront と AWS WAF を通じて配信し、認証には Amazon Cognito を利用しています。リアルタイム性が求められるテレメトリ配信には Amazon API Gateway の WebSocket API を、その他の操作には REST API を使い分けています。映像系は Amazon Kinesis Video Streams、地図表示は Amazon Location Service です。 まとめ 「産業機械の自律診断とリアルタイム安全監視」デモでは、建機フリートの予知保全を題材に、人手による報告、古典的な機械学習、生成 AI エージェントという 3 つのアラート発火のアプローチを比較できる形で実装しました。古典的な機械学習が「異常の検知」を担い、エージェントが「原因の分析と対処の提示」、さらに「起票・通知・対話」までを担うという役割分担は、製造業や建設業における保全業務の実務に近い形で生成 AI を組み込む際のひとつの参考になると考えています。さらに、検知後に人が担っていた調査・起票・連絡といった作業をエージェントに任せることで、担当者は判断と実際の対処に集中できるようになります。 本記事で紹介した構成の多くは、標準的な AWS サービスの組み合わせで実現しています。自社の設備データへの適用をご検討の際は、ぜひ AWS の担当ソリューションアーキテクトにご相談ください。 著者 新澤 雅治(Niizawa Masaharu) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 深澤 真愛(Fukasawa Mana) — Solutions Architect。入社以来、製造業を中心に、様々な業界のお客様の AI 活用やデータ活用の技術的支援に携わる。

こんにちは。Developer Engagementブロックの @wiroha です。2026年7月10日、11日に「 SRE NEXT 2026 」が開催されました。ZOZOはSilverスポンサーとして初協賛し、スポンサーブースを出展しました。 本記事ではZOZOから登壇したセッションと気になったセッションの紹介、協賛ブースの様子についてお伝えします！ ZOZOエンジニアの登壇セッション ZOZOTOWNの進化と信頼性を両立する負荷試験 — 年十数回、現場の課題と効率化（LT） speakerdeck.com ZOZOTOWNの会員ID基盤では、年十数回の負荷試験を実施しています。新機能の追加やリプレイスなどプロダクトの進化が続く中で、信頼性をどう担保し続けるか — その要が負荷試験の運用です。しかし実施要否の検討・シナリオ作成・mock準備・想定RPSの見積もりなど、試験前に積み重なる判断と調整が、見えないコミュニケーションコストを生み、運用を試験を回すだけで精一杯の状態にしていました。 今回のLTでは、要否判定の属人化解消・シナリオ資産の使い回し・分析工程の仕組み化・結果のテンプレート化など、現場で有効だった運用改善と、これから取り組みたい効率化の方向性を共有しました。 登壇者からのコメント SRE部 会員ID基盤SREブロックの松石です。今回初めてのカンファレンス登壇となりました。このセッションでは、弊社で頻繁に行っているマイクロサービス負荷試験とその課題、改善について発表しました。 負荷試験は、ECサイトのようにスパイクが頻繁に起こりえるサービスでは重要な試験観点となってきます。一方で、マイクロサービスの依存が増えることやサービス要件により、観点や事前準備が日々複雑になっており試験を行う際の工数は無視できない規模になってきました。今回の発表で、新しい気づきや弊社の取り組みへの興味を持ってくださった方がいたら嬉しく思います。 また、発表を行うことで、ブースや懇親会で負荷試験について興味を持ってくださった方、似た悩みを抱える方と密な意見交換をできました。今回得た知見などは、チーム内でも展開し、サービスの信頼性向上に努めたいと考えています。 良く情報を発信する人間のところに情報は集まってくると言われますが、そのことを体感した2日間で非常に有意義な時間でした。 エンジニアが気になったセッションの紹介 サンプリングは統計学である：数理的根拠に基づき、オブザーバビリティのコストと精度を両立する　山口 能迪 speakerdeck.com SRE部 カート決済SREブロックの北島です。4月に新卒入社して、少しずつ業務に慣れてきました。リプレイスプロジェクトにサブとして参加しながら、Datadogのダッシュボードやトレースを確認したりという日々です。各マイクロサービスのデータがDatadog上で可視化されていますが、「これは本当に正しいものなのか」とどこか引っかかっていました。 このセッションでは、「全てのlogのデータを保持するにはコストがかかるため、サンプリングする。けれど『データを捨てる』という行為なので、捨てていい場合と捨ててはいけない場合がある。その判断基準が統計学にある」という内容が語られました。 具体的には、以下の4点が軸になっていました。 Datadogに表示されるメトリクスが推定値になりうること 推定値として読むためには許容誤差を先に決めてサンプリング率を逆算する必要があること 多段構成だと保持率が積み重なって補正が難しくなること メトリクスとトレースはそもそも責務が違うので分けて考えるべきこと この日のセッションで、自分の引っかかりの正体が少しわかった気がしました。 「Datadogに表示される数字は事実ではなく推定値かもしれない。この数値は本当に信頼できるのか？」を問えるSREになりたいと思いました。 数字を見るたびに「なぜ」を繰り返して、何か起きたときに根拠を持って動けるよう意識していきたいと改めて思いました。 CSに"SLO"は要らない、経営層に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則　川崎 雄太 speakerdeck.com SRE部 会員ID基盤SREブロックの田中です。私が所属するチームでは現在SLOの策定を進めており、その目的・対象・運用方法について議論を重ねています。 その中で、SLOの設定や運用改善はSREだけで完結するものではなく、開発チームやプロダクトマネージャーをはじめとするさまざまな部署と連携し、共通認識を形成する必要があるため、その難しさを実感していました。 本セッションでは、組織にSREを浸透させる際に直面する課題を、1. 専門用語の壁、2. 温度差の壁、3. 完璧主義の壁の3つに整理し、それぞれを「翻訳レイヤー設計」「ビジネスインパクトへの変換」「役割別Include設計」というアプローチで乗り越えた事例が紹介されました。 特に印象に残ったのは、専門用語や指標を部署ごとの視点に合わせて再定義したり、それぞれの立場で必要となる情報に合わせてSREやSLOの価値を伝えたりする工夫です。技術的な正しさだけでなく、相手に伝わる形へ翻訳することが、組織全体でサービス信頼性を向上させるために重要であることを改めて認識しました。 SLOの策定に取り組んでいる現在の私たちのチームにとっても、多様なステークホルダーとの認識合わせはまさに直面している課題です。本セッションを通じて、SLOの運用に限らず、サービス信頼性向上を組織全体で推進するための具体的な考え方やアプローチを学ぶことができ、非常に参考になる内容でした。今後、より多くの部署と連携しながら活動を進めていく上で、ぜひ実践していきたいと感じました。 分散システム、なんですぐ死んでしまうん？耐障害性を高めたいあなたのためのレジリエンスパターン入門 ZOZOMO部SREブロックの蔭山です。私からは1日目の『分散システム、なんですぐ死んでしまうん？耐障害性を高めたいあなたのためのレジリエンスパターン入門』を紹介します。 speakerdeck.com 本セッションでは分散システムにおけるレジリエンスパターンについて、実際の取組事例を交えながら紹介されました。 レジリエンスパターンの手法についてTimeoutやRetry、Request Hedging、Circuit Breaker、Load Shedding、Graceful Degradationが解説され、それを実現するService Meshとライブラリそれぞれでの実装方法、ケーススタディとしてメルカリでのレジリエンス実践の実例も紹介されました。 私たちが担当しているシステムでは分散システムを扱うことが多く、TimeoutやRetryなどは普段の実装から意識しているものもありました。それでもTimeout PropagationやRetry Budgetなどは初めて知った概念でした。特にRetry Budgetは、Retryの回数を制御することで、システム全体の負荷を抑えつつ、サービスの可用性を高めることができるという点で非常に興味深かったです。 また導入を諦めていたService Meshの導入やCircuit Breakerの導入も、今回の実際にサービスを守れた事例を聞いて改めて検討する価値があると感じました。私が担当しているシステムでは、まだまだレジリエンスパターンの導入が十分ではないため、今回のセッションで学んだことを活かして、システムの耐障害性を高める取り組みを進めていきたいと思います。 ポストモーテム！DDoSからサイトは守れた。でもビジネスは守れなかった。 speakerdeck.com ZOZOMO部SREブロックの𠮷富です。本セッションでは、弁護士ドットコムが実際に直面したDDoS攻撃の事例が紹介されました。 同社は継続的なDDoS攻撃を受けましたが、WAFによる防御や関係部署の連携によってサービスのダウンタイムは発生せず、「可用性」を守り切ることができました。しかしその一方で、攻撃による大量のリクエストによりインフラコストが平常時の約40倍まで膨れ上がり、「事業」という観点では大きな損失が発生していました。 この事例で興味深かったのは、コスト急増への初動が遅れた原因です。日次のコスト急増アラートが、偶然にも毎月送られてくる予算アラートと似た金額だったため、担当者は「いつもの月末アラートだろう」と思い込み、異常に気が付きませんでした。また、毎月鳴る予算超過アラートが常態化し、形骸化していたことも見逃しにつながっていました。これは個人の不注意ではなく、人が見逃してしまうことを前提としたアラート設計になっていなかったことが根本原因でした。 また、エンジニアが「可用性」を優先しがちであるという課題も挙げられていました。システムを止めないことを重視する一方で、クラウドでは従量課金そのものが攻撃対象になり得るため、サービスを維持できていても事業としては大きな損失につながる可能性があります。そのため、「システムが動いているから大丈夫」とは言えず、コストも含めてサービス全体の健全性を捉える視点が必要であることを学びました。 このセッションを通して、SREは技術的な課題を解決するだけではなく、事業を守るためのコミュニケーションを担う存在でもあることを改めて認識しました。「どの時点でサイトを停止するのか」「誰が判断するのか」といった基準を、平時から関係者間で共有しておく必要があります。また、技術的な事象をコストやリスクといった経営の言葉に翻訳することが、迅速で適切な意思決定につながります。技術だけでなく、事業全体を見据えた視点を持つことの重要性を強く感じたセッションでした。 なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 speakerdeck.com ZOZOMO部 SREブロックの中村です。私の所属するチームはSREとして立ち上がって約2年ほどです。 SREとは何か、SREとしてのベストプラクティスは何かについて輪読会を行いながら、チームとして日々正解を探し続けています。 オンコール体制整備、SLOの設定、オブザーバビリティの強化改善、SREとしてどのように価値や存在感を出していくのかを考え、実行してみるのですが、思った効果が得られなかったりする場合があります。 今までチームでやっていなかったSREとしての役割を果たそうとすると、あまりうまくいかず、とても悩んでいました。 このセッションでは、他組織の事例や書籍の内容通りにSREプラクティスを実践してもうまくいかないと感じている人向けに、なぜシステムより先に組織を見るべきなのか、組織を見るときに何をチェックすればよいのかを、事例とともに紹介されていました。 セッションの冒頭では、SREプラクティスを行ったときに起こる問題について話されていました。ポストモーテムを導入したりモニタリングを強化したりしても、SRE以外がポストモーテムを書かない、アラートやダッシュボードを作成してもメンテナンスをSREだけが行う状況が起こりえます。 その原因としては、SREが整備してもSRE以外に扱い方が浸透していなければ、そのまま誰も意識しないようになりますし、そのためにドキュメントを用意しても誰も読みたがらず、そのまま風化していきます。 このような問題は、SREプラクティスをやりたいという気持ちだけで進めてしまうことで起こると、セッションを通して認識できました。 SREプラクティスを機能させたいのであれば、自組織の文化や価値観がすでに形成されていることを前提に、それをしっかり守るための手段としてSREプラクティスを設計する必要がある、という話にとても納得感を得られました。また、SREチーム内だけで完結する内容はSREプラクティスとして成果が見えやすい一方、うまくいかないと感じるときはSREチーム外の関係者が必要な領域に踏み込んでしまっている、という話がありました。 今後SREとして何か実践するときには、ただシステムを見るだけでなく、「組織の文化はどうなっているのか」「それを守るためには何が足りていないのか」「足りていないものを補うには何を追加すべきか」「追加する際の影響はどの範囲まで及ぶのか」を意識したうえで、SREチームとしてたくさんチャレンジしていきたいと思いました。 誰のためのReliability？ SRE部カート決済SREブロックの伊藤です。2日目の基調講演『誰のためのReliability？』を紹介します。 speakerdeck.com この講演はデザインリサーチの専門家であるアンカーデザイン株式会社の木浦幹雄さんが「SREの言うユーザーとは誰なのか」を正面から問うものでした。 デザインの世界では、ユーザーを属性だけでなく「属性・文脈・目的」の組み合わせで捉え、それを「ペルソナ」としてチームの共通理解にするそうです。一方で木浦さんいわく、SREの本を何冊読んでもペルソナという言葉は出てこなかったとのことでした。SREは「ユーザー」という漠然とした言葉のまま、誰がどんな状況で何のためにサービスを使っているのかを具体化できていないのではないか、という問いかけが印象に残りました。 私が担当しているZOZOTOWNのカート決済機能は、止まればユーザーの購入がそのまま止まってしまう、ECサイトの根幹となる機能です。セールやクーポン期限前の駆け込みなど、注文が集中するタイミングはデータとして把握しています。ただそれを「負荷の波」として見るだけでは足りず、「期限内にクーポンを使い切りたい人」「セール開始と同時に狙った商品を確保したい人」の活動として捉え直すと、見えるものが変わります。同じ稼働率99.9％でも、平日の昼間と、「今買えないと機会を逃す」人が殺到するセール終了間際とでは、下回ったときにユーザーの活動へ与える影響は大きく違うはずです。 こうした重みの違いまで含めて可視化し、SLOの根拠として語れるようになれば、「誰のためのSLOか」に答えられるようになるのではないかと思いました。 もう1つ考えさせられたのは、この問いはサービスの利用者だけでなく、一緒に働く開発者にも向けるべきだ、ということでした。SREが用意する監視の仕組みや運用ルールは、開発者にとってのプロダクトでもあります。その提案は開発者が望むものと本当に合っているのか。どんな状況で何のために使われるのかを確かめずに、良かれと思って作っていないか。「ユーザー像は、妄想で決めない」というデザインの教訓は、社内の開発者に対しても当てはまるはずです。「誰のためか」を問い続けることが、SREの仕事をより確かなものにするのだと気づかされた講演でした。 End-to-Endで考える信頼性 — LINEアプリにおけるクライアント開発×SRE連携の実践 speakerdeck.com SRE部 会員ID基盤SREブロックの中根です。私の所属ブロックでは、ZOZOTOWNの会員情報やログインに関する機能のSRE業務を担当しています。機能単体の信頼性向上には深く取り組めている一方で、End-to-Endでの信頼性は見えづらいという課題感があります。 こちらのセッションは、障害発生時にユーザー操作へ影響を出さないための設計と運用について、End-to-Endでの取り組みを解説する内容でした。ユーザーが操作した際に「画面が真っ白な状態」を絶対に避けるべき状態として定義し、オフラインファーストで吸収する取り組みが印象的でした。 クライアントでのキャッシュの取り扱いとして指数バックオフによるリトライ制御や部分障害時の選択的リトライ、負荷過多時の優先制御、クライアント視点のログの継続的な分析など、過負荷を避けつつ体験を守る工夫が具体的に紹介されていて学びが多いセッションでした。 また、そういった対応を実践するためには各チームが横断的に取り組むことが何より重要である点や、その文化を醸成するには時間を要する点が紹介されていました。 アプリケーションとバックエンドは組織も要素技術も異なる場合が多く、関連ブロックが増えるほど横断的な連携は難しくなりがちです。 その中で、早い段階からサーバー・クライアント・SRE・QAが一丸となり、仕様やエラーケースを議論する取り組み方は大変参考になりました。私も組織や機能にとらわれず、お客様のより良い体験のために機能や部門の垣根を越えた改善が行えるように取り組んでいきたいです。 ZOZOブースの紹介 LTでの発表内容にあわせて、スポンサーブースでは負荷試験の構成図を中心に展示しました。 「負荷試験に取り組みたいがまだ実践できていないため参考にしたい」といった参加者の方々にも多くお立ち寄りいただき、設計や運用に関する質問など活発な意見交換が行われました。また、初めての協賛ということもあり、ZOZOについて知っていただけるようZOZOTOWNのシステム構成図もご用意しました。こちらも注目を集めていました。 また、ノベルティとして「シューズ用クリーナー消しゴム」を配布しました。スニーカー等のソールの汚れをこすって落とせる便利アイテムです。 「こんなグッズがあるんだ！」「便利！」と好評いただき、ファッションを軸に事業を展開するZOZOらしさも感じていただけたのではないかと思います。 おわりに SRE NEXTへの初協賛を通して、ZOZOのことが少しでも来場者のみなさまに伝わっていれば嬉しいです。ありがとうございました！ ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

G-gen の佐々木です。当記事では、Google Cloud の Sensitive Data Protection （旧称 Cloud Data Loss Prevention）による機密データの匿名化（de-identification）について解説します。 概要 Sensitive Data Protection とは 匿名化（de-identification）とは 匿名化と個人情報保護法 匿名化の基本 匿名化の概要 infoType infoType 変換とレコード変換 対象データの種類 処理ロケーションとデータレジデンシー 匿名化の変換方式 変換方式の一覧 置換と秘匿化 マスキング バケット化 日付シフトと時刻部分抽出 トークン化（Pseudonymization） トークン化とは 暗号方式の比較 サロゲートと再識別 暗号鍵の指定方法 匿名化テンプレート 料金 使用例 概要 Sensitive Data Protection とは Sensitive Data Protection は、Google Cloud 内外の機密データを検出・分類・匿名化するためのフルマネージドサービスです。氏名、メールアドレス、クレジットカード番号といった個人情報をはじめとする機密データを対象に、以下の4つの機能を提供します。 機能 説明 検出（discovery） 組織・フォルダ・プロジェクト単位でデータ資産をスキャンし、機密データの所在とリスクを示すデータプロファイルを生成する 検査（inspection） 個々のリソースを詳細に検査し、機密データが存在する箇所を検出結果（Finding）としてレポートする 匿名化（de-identification） 検出した機密データを、マスキングや置換、トークン化など様々な方式で別の値に変換する リスク分析（risk analysis） BigQuery の構造化データを対象に、匿名化後のデータから個人が再識別されるリスクを統計指標で分析する 当記事では、このうち 匿名化 機能の仕様を解説します。検出機能やリスク分析機能の詳細には立ち入りませんが、匿名化は検査機能と組み合わせて動作するため、必要な範囲で検査機能の仕組みにも触れます。 参考 : Sensitive Data Protection の概要 匿名化（de-identification）とは 匿名化（de-identification） とは、データから個人などを識別できる情報を取り除く処理です。Sensitive Data Protection では、テキストや表形式データに含まれる機密データを検出し、マスキング、置換、暗号化ベースのトークン化など、複数の変換方式で別の値に置き換えられます。 匿名化後のデータは、元の値に戻せるかどうかで大きく2種類（不可逆・可逆）に分けられます。マスキングや秘匿化のような不可逆な変換はデータを完全に無効化する一方、暗号鍵を使用するトークン化では、権限を持つ利用者だけが後から元の値に復元（再識別）できます。 代表的なユースケースには、本番データを開発・テスト環境に安全に提供する場合や、個人情報を秘匿したまま分析基盤にデータを連携する場合などがあります。 参考 : 機密データの匿名化 参考 : 機密データの匿名化と再識別 匿名化と個人情報保護法 匿名化は、日本の個人情報保護法との関係でも重要な意味を持ちます。同法は、個人情報を法定の基準に従って加工した 仮名加工情報 と 匿名加工情報 について、通常の個人情報より緩やかな取り扱いを認めています。 仮名加工情報は、それ単体では特定の個人を識別できないように加工した情報です。ただし、作成した事業者は通常、元の個人情報を保有しており、これを照合することで特定の個人を識別できる場合は、加工後の情報も個人情報に該当します。第三者提供は原則として禁止されており、主に組織内での分析用途を想定した区分です。 匿名加工情報は、特定の個人を識別できず、かつ元の個人情報を復元できないように加工した情報です。こちらは個人情報に該当せず、本人の同意なく第三者提供を含む幅広い利用ができます。ただし、作成時や第三者提供時には、加工した情報の項目の公表などの義務が課されます。 以下のような、氏名・生年月日・住所・購入金額の4列からなるデータがあったとします。特定の個人を識別できるため、個人情報保護法上、これは個人情報に該当します。 氏名 生年月日 住所 購入金額 佐藤太郎 1985-04-12 東京都港区芝公園○-○-○ 152000 鈴木花子 1992-11-03 大阪府大阪市北区梅田○-○-○ 48000 高橋一郎 1978-07-25 福岡県福岡市博多区博多駅前○-○-○ 1980000 この元データを仮名加工情報に加工すると、以下のようになります。氏名を復元できない仮 ID に置き換えたうえで、住所と生年月日の組み合わせから特定の個人を識別できないように、住所は市区レベルに、生年月日は生年月に一般化しています。加工後の情報は単体では特定の個人を識別できませんが、仮 ID と氏名の対応表を保有する事業者は、照合によって個人を識別できます。 仮 ID 生年月 住所 購入金額 a8f3e21c 1985-04 東京都港区 152000 b7d9c04e 1992-11 大阪府大阪市 48000 c2e6a58f 1978-07 福岡県福岡市 1980000 同じ元データを匿名加工情報に加工した例は以下のとおりです。氏名にあたる列を削除したうえで、生年月日は年代に、住所は都道府県に一般化し、購入金額は丸めた値にしています。また、特異な値である3行目の購入金額は「1000000以上」に置き換え、元の値を推測しにくくしています。 年代 居住地 購入金額 40代 東京都 150000 30代 大阪府 50000 40代 福岡県 1000000以上 組織内でのデータ活用を目的とする場合は、仮名加工情報が選択肢になりやすい区分です。匿名加工情報より加工の要件が緩やかで元データの情報量を保ちやすいためです。一方、将来的に外部への提供や公開が想定される場合や、個人情報としての取り扱い義務を完全に切り離したい場合は、匿名加工情報が適しています。 Sensitive Data Protection による変換は、いずれの区分の加工を実装する手段としても使用できます。ただし、これらの区分に該当するには法令が定める加工基準を満たす必要があり、変換を適用するだけで直ちに要件を満たすとは限らない点には注意が必要です。 参考 : 個人情報の保護に関する法律についてのガイドライン（仮名加工情報・匿名加工情報編） 参考 : 匿名加工情報と仮名加工情報の違いは何ですか 参考 : 個人情報である仮名加工情報と個人情報でない仮名加工情報とは何ですか 匿名化の基本 匿名化の概要 匿名化は「検査」と「変換」の2段階で構成されます。まず後述の infoType 検出器によってデータ内の機密データを特定し、次に特定された値へ変換を適用します。「どの infoType を対象に」「どの変換方式を適用するか」という組み合わせが匿名化設定の基本単位です。 匿名化を実行する手段には、以下の2方式があります。 方式 説明 ストレージメソッド Cloud Storage 上のファイルを対象に、 Deidentify アクションを指定した 検査ジョブ として非同期に実行する。匿名化済みのコピーが入力とは別のバケットに作成される コンテンツメソッド API リクエストに含めたデータを対象に、 content.deidentify メソッドで同期的に実行する。匿名化済みのデータをレスポンスとして受け取る 可逆な変換で匿名化した値を元に戻す際は、 content.reidentify メソッドを使用します。 参考 : メソッドタイプ 参考 : 機密性の高い Cloud Storage データの匿名化 参考 : 機密データの匿名化 infoType infoType は、氏名、メールアドレス、電話番号、クレジットカード番号といった機密データの種類を表す概念です。Sensitive Data Protection には数百種類の組み込み infoType 検出器が用意されており、各国の政府発行 ID、金融情報、医療情報、認証情報なども検出できます。各検出器には機密度スコア（ SENSITIVITY_LOW / SENSITIVITY_MODERATE / SENSITIVITY_HIGH ）が設定されています。 組み込み infoType で対応できない固有のデータには、カスタム infoType を定義できます。カスタム infoType には、正規表現による検出、単語リスト（辞書）による検出、大規模な辞書を保存して使用する検出の3方式があります。 なお、組み込み infoType 検出器による検出は、完全な精度を保証するものではない旨が公式ドキュメントに明記されています。匿名化したデータを組織外に公開するような場合は、カスタム infoType の併用や結果のサンプリング確認など、検出漏れを前提とした運用を検討してください。 参考 : infoType と infoType 検出器 参考 : InfoType 検出器リファレンス infoType 変換とレコード変換 変換の適用単位には、infoType 変換とレコード変換の2カテゴリがあります。 infoType 変換は、コンテンツ内で特定の infoType として検出された値だけに変換を適用します。自由記述のテキストのように、機密データがどこに現れるか事前に分からない非構造化データに適しています。 レコード変換は、表形式（構造化）データに対して使用します。特定の列の値全体に変換を適用するほか、条件に応じてレコード（行）自体を削除することもできます。BigQuery のテーブルのように、どの列にどのようなデータが入っているか既知のデータでは、レコード変換で列を指定する方が確実です。 参考 : 機密データの匿名化 - 匿名化変換 対象データの種類 匿名化の対象は、非構造化テキスト、表形式の構造化データ、画像の3種類です。テキストと構造化データには、後述する各変換方式を適用できます。画像に対しては、 image.redact メソッドを使用して、機密データが写っている領域を塗りつぶす秘匿化のみが可能です。 処理ロケーションとデータレジデンシー Sensitive Data Protection の API エンドポイントには、 グローバルエンドポイント と リージョンエンドポイント の2種類があります。処理を実行するロケーション（リージョン）は、どちらのエンドポイントでも、リクエスト URL のパスに locations/asia-northeast1 のように挿入して指定します。東京リージョン（asia-northeast1）を例にすると、それぞれの URL は以下のとおりです。 エンドポイント URL の例 説明 グローバルエンドポイント https://dlp.googleapis.com/v2/projects/<プロジェクトID>/locations/asia-northeast1/content:deidentify リージョン指定を省略する場合の例 https://dlp.googleapis.com/v2/projects/<プロジェクトID>/content:deidentify 標準のエンドポイント。処理を実行するリージョンはパスで指定し、パスの locations/<ロケーション> 部分ごと省略した場合はグローバルロケーションで処理される（ locations/global を指定した場合と同じ扱い） リージョンエンドポイント https://dlp.asia-northeast1.rep.googleapis.com/v2/projects/<プロジェクトID>/locations/asia-northeast1/content:deidentify 特定リージョン専用のエンドポイント。ホスト名自体にリージョン名を含む。対応リージョンは限られる データレジデンシーの観点では、この2つで保証の範囲が異なります。グローバルエンドポイントでは、パスでロケーションを指定しても、保証されるのは処理が実行されるロケーションのみで、転送中のデータが指定リージョン内に留まることは保証されません。保存中・使用中・転送中のすべてでデータをリージョン内に留める必要がある場合は、リージョンエンドポイントを使用します。一方でグローバルエンドポイントを使用すると、レイテンシとネットワーク帯域幅の面でメリットがあります。 参考 : 処理を行うロケーションの指定 参考 : Sensitive Data Protection のグローバル エンドポイントとリージョン エンドポイント 匿名化の変換方式 変換方式の一覧 2026年7月現在、匿名化で使用できる主な変換方式は以下のとおりです。 変換方式 API 上の設定名 説明 可逆性 秘匿化（Redaction） RedactConfig 検出値を削除する 不可逆 置換（Replacement） ReplaceValueConfig 指定した固定値に置き換える 不可逆 辞書置換 ReplaceDictionaryConfig 単語リストからランダムに選択した値に置き換える 不可逆 infoType 置換 ReplaceWithInfoTypeConfig 検出値を infoType 名に置き換える 不可逆 文字マスキング CharacterMaskConfig 指定した文字数を * などの代替文字で置き換える 不可逆 確定的暗号化 CryptoDeterministicConfig AES-SIV による暗号化でトークンを生成する 可逆 フォーマット保持暗号化 CryptoReplaceFfxFpeConfig 入力と同じ長さ・文字種のトークンを生成する 可逆 暗号ハッシュ CryptoHashConfig HMAC-SHA-256 によるハッシュ値に置き換える 不可逆 固定サイズバケット化 FixedSizeBucketingConfig 数値を固定幅の範囲値に丸める 不可逆 カスタムバケット化 BucketingConfig ユーザー定義の範囲と置換値で丸める 不可逆 日付シフト DateShiftConfig 日付をランダムな日数だけずらす 不可逆 時刻部分抽出 TimePartConfig 日付から一部分だけを残す 不可逆 このうち、暗号鍵を使用する確定的暗号化・フォーマット保持暗号化・暗号ハッシュの3方式は、 トークン化（Pseudonymization） と総称されます。トークン化については次章で詳しく解説します。 参考 : 変換のリファレンス 置換と秘匿化 置換系の変換は、検出値を別の値に置き換える最も基本的な方式です。基本の 置換 （ ReplaceValueConfig ）では [REDACTED] のような任意の固定値を、infoType 置換（ ReplaceWithInfoTypeConfig ）では [EMAIL_ADDRESS] のように infoType 名を代替値として使用します。 辞書置換 （ ReplaceDictionaryConfig ）は、あらかじめ用意した単語リストからランダムに選択した値へ置き換える方式で、匿名化後もデータの見た目の自然さを保ちたい場合に使用します。 infoType 置換 を使用すると、どの種類の機密データがあったかという情報を残したまま値を秘匿できます。 秘匿化 （ RedactConfig ）は、検出値そのものを削除する方式です。置換と異なり代替値を残さないため、機密データが存在したことを示す痕跡も残りません。 変換方式 変換前の例 変換後の例 置換 taro@example.com [REDACTED] 辞書置換 taro@example.com izumi@example.com infoType 置換 taro@example.com [EMAIL_ADDRESS] 秘匿化 taro@example.com （削除） マスキング マスキング （ CharacterMaskConfig ）は、検出値の全部または一部の文字を * などの代替文字で置き換える方式です。マスクする文字数や方向（先頭から・末尾から）を指定できるため、電話番号の末尾4桁だけを残す、といった部分的なマスキングが可能です。値の形式をある程度保ったまま秘匿できるため、画面表示用のデータなどに適しています。 変換方式 変換前の例 変換後の例 文字マスキング 0312345678 ******5678 バケット化 バケット化 は、具体的な値を範囲値に丸めて一般化（generalization）する方式です。 固定サイズバケット化 （ FixedSizeBucketingConfig ）では、バケットの幅を指定して数値を等間隔の範囲に丸めます。 カスタムバケット化 （ BucketingConfig ）では、範囲の境界と置換値を個別に定義できます。 バケット化は値を完全に消すのではなく粒度を粗くする変換のため、統計的な有用性を保ちながら個人の特定可能性を下げたい分析用途に適しています。 変換方式 変換前の例 変換後の例 固定サイズバケット化 27 20-30 カスタムバケット化 95 High 日付シフトと時刻部分抽出 日付シフト （ DateShiftConfig ）は、日付をランダムな日数だけ前後にずらす方式です。実際の日付は秘匿しつつ、日付間の間隔という情報を保持できます。コンテキストとして列を指定することで、同じ ID を持つレコード群に同じシフト量を適用でき、たとえば同一人物のレコード間で日数の差分を維持したまま匿名化できます。 時刻部分抽出 （ TimePartConfig ）は、日付や時刻から年・月・曜日などの特定の部分だけを残す方式です。たとえば生年月日から年だけを残せば、年代の分析には使用できる形でデータを一般化できます。 変換方式 変換前の例 変換後の例 日付シフト 2009-06-09 2009-07-17 時刻部分抽出 2009-06-09 2009 トークン化（Pseudonymization） トークン化とは トークン化 （Pseudonymization、仮名化とも呼ばれます）は、機密データの値を暗号的に生成したトークンに置き換える匿名化手法です。 トークン化の重要な性質として、 参照整合性（referential integrity） があります。同じ入力値からは常に同じトークンが生成されるため、複数のテーブルやリクエストにまたがって、値の対応関係を保ったまま匿名化できます。たとえば顧客 ID をトークン化しても、テーブル間の結合キーとして引き続き使用できます。 なお、 コンテキスト（context） として別の列を指定すると、同じ入力値でもコンテキスト列の値ごとに異なるトークンを生成できます。参照整合性が有効な範囲を意図的に狭めることで、データセットをまたいだ突合や、パターン分析による推測を防げます。 参考 : 仮名化 暗号方式の比較 トークン化に使用できる暗号方式は3種類です。 変換方式 API 上の設定名 アルゴリズム 再識別（復元） 形式・長さの保持 入力の要件 確定的暗号化 CryptoDeterministicConfig AES-SIV 可能 されない 1文字以上 フォーマット保持暗号化（FPE-FFX） CryptoReplaceFfxFpeConfig FPE-FFX 可能 される 2文字以上の ASCII 文字 暗号ハッシュ CryptoHashConfig HMAC-SHA-256 不可能 されない（常に一定長） 文字列または整数 確定的暗号化 は、トークン化の基本となる方式です。入力の文字種や長さに制限がなく、再識別も可能なため、形式の保持が不要であればまずこの方式を検討します。 フォーマット保持暗号化 は、入力と同じ長さ・同じ文字種のトークンを生成できる点が特徴です。データベースの列に桁数や形式の制約があり、既存システムの形式要件を変えられない場面で有効です。 暗号ハッシュ は、再識別できない一方で参照整合性は保たれる方式です。元の値に戻す必要はないものの、値の同一性の判別だけは必要である、という用途に適しています。 変換方式 変換前の例 変換後の例 確定的暗号化 0312345678 TOKEN(36):Ab3dF9+k… フォーマット保持暗号化 0312345678 9250183460 暗号ハッシュ 0312345678 XlTCv8h0Gwr…= サロゲートと再識別 再識別を前提としたトークン化では、トークンに サロゲート（surrogate） と呼ばれるラベルを付与できます。サロゲートは <サロゲート名>(<文字数>):<トークン> の形式でトークンの先頭に付き、そのトークンがどの種類のデータを匿名化したものかを識別可能にします。 再識別（ content.reidentify ）には、匿名化時と同じ暗号鍵、サロゲートを含むトークン全体、匿名化時に指定したコンテキストが必要です。特に非構造化テキストでは、テキスト中のどの部分がトークンであるかを特定する手がかりがサロゲートしかないため、再識別を前提とする場合はサロゲートの付与が必須です。構造化データでは列単位で変換を管理できるため、サロゲートは省略できます。 参考 : 仮名化 - トークン化された値の比較 暗号鍵の指定方法 トークン化に使用する暗号鍵の指定方法は3種類です。 指定方法 概要 主な用途 Cloud KMS でラップされた暗号鍵 Cloud KMS の鍵で暗号化（ラップ）した鍵を指定する 本番環境（推奨） 一時的な暗号鍵 リクエストごとに自動生成され、処理後に破棄される 単一リクエスト内での一貫性のみ必要な場合 ラップ解除された暗号鍵 base64 エンコードした生の鍵をリクエストに直接含める テスト用途 再識別を前提とする場合は、匿名化に使用した鍵を安全に保管し続ける必要があるため、Cloud KMS でラップされた暗号鍵の使用が推奨されています。一時的な暗号鍵はリクエストをまたいだ参照整合性を持たず、後から再識別することもできません。ラップ解除された暗号鍵はリクエスト本文に生の鍵が含まれるため、本番環境での使用は推奨されていません。 可逆なトークン化を使用する場合は、暗号鍵の管理が重要です。鍵を失うと匿名化したデータは二度と再識別できず、鍵が漏洩すると第三者がデータを再識別できてしまいます。Cloud KMS による鍵の保護と、IAM による鍵・テンプレートへのアクセス制御を合わせて設計してください。 匿名化テンプレート 匿名化テンプレート は、どの infoType をどの変換方式で匿名化するかという設定（ DeidentifyConfig ）を、再利用可能な形で保存したものです。作成したテンプレートは、 content.deidentify リクエストや検査ジョブから名前で参照できます。 テンプレートを使用することで、何を検出しどのように匿名化するかという構成を、アプリケーションの実装から分離できます。組織内で匿名化ポリシーを標準化する場合や、同じ設定を複数のパイプラインで使い回す場合に有効です。また、トークン化の設定（暗号鍵やサロゲート）をテンプレートとして保持しておくことで、匿名化と再識別の間で確実に同一の設定を使用できます。 参考 : 機密データの保護の匿名化テンプレートの作成 料金 匿名化の料金は、処理したデータ量（バイト数）に基づく従量課金です。課金は検査と変換の2要素に分かれており、 content.deidentify および content.reidentify メソッドでは両方が課金されます。2026年7月現在、コンテンツメソッドの料金は以下のとおりです。 課金要素 月あたり 1 GB まで 1 GB 超 1 TB 超 検査 無料 3.00米ドル/GB 2.00米ドル/GB 変換 無料 2.00米ドル/GB 1.00米ドル/GB infoType の検査を伴う単純な秘匿化（ RedactConfig および ReplaceWithInfoTypeConfig ）では、変換分のバイト数は課金対象になりません。また、リクエストごとに最低 1 KB 分が課金されます。 Cloud Storage 上のデータを検査ジョブ（ストレージメソッド）で匿名化する場合は、コンテンツメソッドより低い単価（データ量に応じて 1 GB あたり0.60〜1.00米ドル）が設定されています。最新の料金と詳細な条件は、公式の料金ページを参照してください。 また、Sensitive Data Protection 自体の料金のほかに、Cloud KMS でラップされた暗号鍵を使用する場合の Cloud KMS の料金や、検出結果を BigQuery に保存する場合の料金など、関連サービスの料金が別途発生します。 参考 : Sensitive Data Protection の料金 使用例 コンテンツメソッドによる匿名化の例として、 content.deidentify メソッドでテキスト中のメールアドレスを infoType 置換で匿名化します。まず、以下の内容でリクエスト本文のファイル（ request.json ）を作成します。 { " item ": { " value ": " 山田さんの連絡先は taro@example.com です。 " } , " inspectConfig ": { " infoTypes ": [ { " name ": " EMAIL_ADDRESS " } ] } , " deidentifyConfig ": { " infoTypeTransformations ": { " transformations ": [ { " infoTypes ": [ { " name ": " EMAIL_ADDRESS " } ] , " primitiveTransformation ": { " replaceWithInfoTypeConfig ": {} } } ] } } } inspectConfig で検出対象の infoType を指定し、 deidentifyConfig で「どの infoType を対象に」「どの変換方式を適用するか」という組み合わせを指定します。この例では、 EMAIL_ADDRESS として検出された値に infoType 置換（ ReplaceWithInfoTypeConfig ）を適用しています。匿名化テンプレートを使用する場合は、 deidentifyConfig の代わりに deidentifyTemplateName でテンプレート名を指定します。 作成したリクエスト本文を指定して、API を呼び出します。 x-goog-user-project ヘッダーには、API 使用量の計上先となる割り当てプロジェクトを指定します（ユーザー認証情報で実行する場合、このヘッダーがないと 403 PERMISSION_DENIED エラーが発生します）。 $ curl -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " x-goog-user-project: <プロジェクトID> " \ -H " Content-Type: application/json " \ -d @request.json \ " https://dlp.asia-northeast1.rep.googleapis.com/v2/projects/<プロジェクトID>/locations/asia-northeast1/content:deidentify " この例では、東京リージョンのリージョンエンドポイント（ dlp.asia-northeast1.rep.googleapis.com ）を使用し、URL パスでも同じリージョンを指定して匿名化を実行しています。エンドポイントの種類とデータレジデンシーの考慮事項については、前述の「処理ロケーションとデータレジデンシー」節を参照してください。 レスポンスでは、 item.value に匿名化後のテキストが格納されるほか、 overview に変換されたバイト数と infoType ごとの変換結果の内訳が含まれます。 { " item ": { " value ": " 山田さんの連絡先は [EMAIL_ADDRESS] です。 " } , " overview ": { " transformedBytes ": " 16 ", " transformationSummaries ": [ { " infoType ": { " name ": " EMAIL_ADDRESS ", " sensitivityScore ": { " score ": " SENSITIVITY_MODERATE " } } , " transformation ": { " replaceWithInfoTypeConfig ": {} } , " results ": [ { " count ": " 1 ", " code ": " SUCCESS " } ] , " transformedBytes ": " 16 " } ] } } 参考 : Method: projects.content.deidentify 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は法律の勉強にも目覚め、2級知的財産管理技能士を取得。 Follow @sasashun0805