2026 年 7 月 20 日週、私のチームは AWS Korea User Group (AWSKRUG) のリーダーの皆さんに会うためにソウルを訪問しました。AWSKRUG は韓国最大のクラウド開発者コミュニティで、トピックや領域ごとに 20 のミートアップグループが設けられ、主にソウルを中心に毎年 100 以上のイベントが開催されています。 私のチームは定期的にアジア太平洋地域の国々を訪問し、ユーザーグループのリーダーからのフィードバックに耳を傾け、コミュニティの支援に取り組んでいます。今回の会議では、リーダーの皆さんから、上半期の成果、改善が必要な点、AWS Developer Experience チームへの要望について率直な意見を共有していただきました。また、一緒に チメク を囲んで和やかな会話を楽しみました。 それでは、 7 月 20 日週の主なリリースを詳しく見ていきましょう。 7 月 20 日週、最も目を引いたのは、 コーディングエージェント向けのワンクリック Lambda セットアッププロンプト です。このプロンプトを使用すると、AWS サーバーレススキルとサーバーレスモデルコンテキストプロトコル (MCP) サーバーをエージェントに設定し、サーバーレスのベストプラクティスを初めから組み込むことができます。このプロンプトでは、Claude Code、Kiro、Cursor、GitHub Copilot、Codex、Devin Desktop、および OpenCode のインストールコマンドを含む、Lambda エージェントセットアップガイドが参照されます。 開始するには、Lambda コンソール画面で [エージェントプロンプトをコピー] ボタンを選択するか、 fetch https://docs.aws.amazon.com/lambda/latest/dg/samples/aws-lambda-agent-setup.md を直接コピーして、この URL を任意の AI エージェントに貼り付けます。 Agent Toolkit for AWS を使用して、コーディングエージェントに AWS に関する最新の知識とリソースへの安全なアクセスを提供することもできます。AWS MCP サーバーのインストールには fetch https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md を使用してください。  7 月 20 日週のリリース 7 月 20 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Bedrock での OpenAI GPT-5.6 Sol、Terra、Luna : 高いパフォーマンス、セキュリティ、信頼性を実現するように構築された Bedrock の次世代推論エンジンで、OpenAI のこれまでで最もスマートなモデルファミリーを使用できます。この 3 つのモデルは、主力級の推論 (Sol)、バランスの取れたパフォーマンス (Terra)、高速でコスト効率の高い推論 (Luna) という異なる機能階層があり、すべて Amazon Bedrock の Responses API からアクセスできます。 Amazon S3 Standard-IA および S3 One Zone-IA への即日移行 : S3 Standard の 30 日間の最小保持期間が撤廃され、作成日にすぐに S3 Standard 低頻度アクセス (S3 Standard-IA) と S3 One Zone 低頻度アクセス (S3 One Zone-IA) にオブジェクトを移行できるようになりました。これらのストレージクラスは、S3 Standard よりもストレージコストを最大 40% 低く抑えながら、必要に応じてミリ秒単位でアクセスできるため、データが数時間または数日でコールドデータとなるバックアップ、ログ分析、コンプライアンスワークロードに最適です。 AWS Lambda でのセルフマネージド型コードストレージ : コードストレージにセルフマネージド型 Amazon S3 バケットを使用すると、Lambda によって中間コピーを作成することなく、独自の S3 バケットからソースコードを直接参照できます。コピーステップが不要になることで、コードストレージの制限がなくなり、関数の作成と更新後の関数のアクティブ化時間が短縮されます。 Amazon Cognito でのパスワードハッシュを含むユーザーのインポート : CSV ユーザーインポートでパスワードハッシュを含めてユーザーをインポートできるようになりました。これまでは、インポートされたユーザーは最初のサインイン時にパスワードをリセットする必要がありました。CSV インポートにパスワードハッシュを含めることができるようになったため、ユーザーは既存の認証情報ですぐにサインインできます。CSV インポートを作成するときに、ソースシステムで使用されるパスワードハッシュアルゴリズムを指定します。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんが興味を持つと思われるその他のニュースをいくつかご紹介します。 Amazon SQS が誕生 20 周年に: 大規模かつ信頼性の高いメッセージングを支えてきた 20 年間 : 2006 年 7 月に Amazon SQS の一般提供が開始されると、このパターンは AWS のすべてのお客様にご利用いただけるようになりました。20 年経った今でも、プロデューサーとコンシューマーを分離するというその中核的な機能こそが、お客様が SQS を使用する理由となっています。 Jeff の 15 周年記念の記事 投稿以降の重要なマイルストーンを振り返ってみましょう。 Strands Agents SDK でのオープンプロトコル : MCP、A2A、UTCP、AG-UI、x402 といったオープン AI プロトコルがどのように連携して AI エージェントを構築するのかを Strands Agents SDK を実装例として用いて説明します。なお、これらのパターンはどのエージェントフレームワークにも適用できます。 オープンソースの Bulk Executor for Amazon DynamoDB : これまでは、テーブルのすべての項目に対して一括操作を実行するにはカスタムコーディングが必要でした。 Bulk Executor for DynamoDB を使用すると、このような一括タスクが簡略化されます。この機能を使用して、 count 、 find 、 delete 、 update などのコマンドを呼び出すことができます。大規模に実行する場合でも、コーディングは不要です。 Kiro CLI による AWS サポートケースワークフローの変革 : Kiro CLI の MCP 統合により、AWS Glue ジョブの失敗、AWS Lambda コールドスタートの調査、AWS WAF の誤検知分析という 3 つの実際のシナリオにおいて、調査、ドキュメントのルックアップ、ケースの作成を単一の対話型インターフェイスにまとめることで、サポートケースワークフローを加速させる方法を説明します。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS について詳しく学び、次に予定されている AWS 主催の対面イベントとバーチャルイベント 、 スタートアップイベント 、 AWS Summits などの 開発者向けイベント を調べて参加しましょう。 AWS Builder Center にもご参加ください。ビルダーとつながり、ソリューションを共有して、開発をサポートするコンテンツにアクセスできます。 最後に、 7 月 20 日週末に一部のお客様において、 Cost Explorer で不正確な請求見積データが表示される 問題が発生しました。これにより、予算とコストに関する誤った異常検知アラートが通知されたり、見積コストと使用量データが実際より高く表示されたりした可能性があります。この問題は解決され、すべての AWS サービスが正常に動作しています。このインシデントによりお客様にご心配をおかけしたことをお詫び申し上げます。このようなイベントの再発を防ぐため、また請求インシデントが発生した場合の対応を改善するために、徹底的な事後調査を実施しています。詳細については、 AWS Health Dashboard にアクセスしてください。 2026 年 7 月 20 日週のニュースは以上です。7 月 27 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

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

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 AWS Summitが終了し、各チームからはAWSブログを通じて、より詳しい解説が公開されています。ぜひチェックしてみてください。 私が所属する流通小売事業部のブースでは、飲食店舗などで活用できるソリューションとして、AmiVoiceと連携したデモを出展しました。こちらは、AmiVoiceを提供されているアドバンスト・メディア様との共著でブログ「 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 」として公開しています。 飲食店舗に限らず、「音声認識 × Agentic AI」を検討されている方にとって参考になる内容ですので、ぜひご一読ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月13日週の主要なアップデート 7/13(月) Amazon SageMaker HyperPod が Slurm クラスターでカスタム AMI をサポート Amazon SageMaker HyperPod が､Slurm でオーケストレーションするクラスターでカスタム AMI (Amazon Machine Image) を利用できるようになりました｡ユーザーは HyperPod の性能最適化済みベース AMI をもとに､セキュリティエージェントやコンプライアンスツール､専用ライブラリ､ドライバーをイメージに組み込めます｡これまでライフサイクル設定スクリプトで起動後に実行していたセットアップ処理を AMI 側に取り込めるため､クラスターの起動時間を短縮でき､ノード間の構成の不整合を抑えられます｡カスタム AMI は CreateCluster / UpdateCluster / UpdateClusterSoftware の各 API で指定でき､HyperPod がサポートするすべての AWS リージョンで利用できます｡ OpenAI privacy-filter による PII 検出とマスキングが Amazon SageMaker JumpStart で利用可能に OpenAI が開発した PII 検出･マスキング用モデル privacy-filter が Amazon SageMaker JumpStart で利用できるようになりました｡テキスト中の個人識別情報 (PII) を検出する双方向トークン分類モデルで､1 回の forward pass で入力全体にラベルを付与します｡アカウント番号･住所･メールアドレス･氏名･電話番号･URL･日付･secret の 8 カテゴリを検出できます｡SageMaker Studio の Models セクションまたは SageMaker Python SDK から数クリックで自分の AWS アカウントにデプロイでき､データサニタイズ (無害化) のワークフローを構築できます｡ Voxtral-Mini-4B-Realtime をリアルタイム音声文字起こし向けに Amazon SageMaker JumpStart で提供開始 AWS は Mistral AI のリアルタイム音声文字起こしモデル Voxtral-Mini-4B-Realtime-2602 を Amazon SageMaker JumpStart で利用できるようにしました｡ このモデルは音声を逐次処理するストリーミングアーキテクチャを備え、500ms 未満の遅延で文字起こしを出力できます｡ 13 言語に対応し、文字起こしの遅延を 240ms から 2.4s の範囲で設定してレイテンシと精度のバランスを調整できます｡ SageMaker Studio の Models 画面または SageMaker Python SDK から数クリックで自分の AWS アカウントにデプロイできます｡ Gemma-4-E2B-it が Amazon SageMaker JumpStart で利用可能に AWS は 2026 年 7 月 13 日に､ Google DeepMind の gemma-4-E2B-it を Amazon SageMaker JumpStart で提供開始しました｡ このモデルはテキスト･画像･音声を入力として受け取り､ テキストを出力するマルチモーダルの指示調整済みモデルです｡ ステップごとに思考する reasoning モードを内蔵し､ 有効パラメータ 2.3B (埋め込み込みで 5.1B) という小型構成でエッジ寄りの効率的な実行に最適化されています｡ SageMaker Studio の Models セクションまたは SageMaker Python SDK から数クリックでデプロイできます｡ OpenAI GPT-5.6 Sol、Terra、 Luna が Amazon Bedrock で一般提供開始 OpenAI の GPT-5.6 ファミリー (Sol、Terra、Luna) が Amazon Bedrock で一般提供 (GA) されました｡3 モデルはフラッグシップの推論特化 (Sol)、バランス型 (Terra)、 高速低コスト型 (Luna) という 3 階層で構成され、いずれも `bedrock-mantle` エンドポイント上の Responses API 経由で利用します｡コンテキストウィンドウは 272K トークンで、prompt caching により再利用コンテキストのキャッシュ読み取りが 90% 割引になります｡料金は OpenAI の first-party レートと同等で、 利用額は既存の AWS コミットメントに算入されます｡ 7/14(火) AWS Security Hub が組織全体の AI アセットを可視化する AI インベントリの提供を開始 AWS Security Hub に AI インベントリ機能が追加されました｡ この機能は組織全体の AI アセット (エージェント､ モデル､ パイプライン) を継続的に検出し､ そのセキュリティ状態を中央のセキュリティチームが確認できるようにするものです｡ 検出は AWS Config リソース､ Amazon Inspector の SBOM 分析､ Amazon GuardDuty の DNS テレメトリという 3 つの方法で自動的に行われます｡ 検出された各アセットは基盤インフラにマッピングされ､ GuardDuty の脅威検出を含むセキュリティ検出結果と関連付けられます｡ この機能は Security Hub Essentials に含まれ､ 追加費用はかからず､ 新たな有効化操作も不要です｡ Amazon GuardDuty AI Protection を発表 (AWS AI ワークロード向け脅威検知) Amazon GuardDuty に AI Protection が追加され、 Amazon Bedrock と Amazon SageMaker AI のワークロードを対象とした脅威検知に対応しました｡CloudTrail の管理イベントとデータイベントを解析し、 異常なモデル呼び出し、 コストハーベスティング攻撃、 プロンプトインジェクションの 3 種類を検出します｡検出結果は AWS Security Hub に集約され、 AWS Organizations で組織全体に一元的に有効化できます｡GuardDuty 利用者は 30 日間の無料トライアルで利用を開始できます｡ AWS Lambda コンソールにコーディングエージェント向けワンクリックセットアッププロンプトを追加 AWS Lambda コンソールに､コーディングエージェントを 1 クリックでサーバーレス開発向けに構成するセットアッププロンプトが追加されました｡このプロンプトは AWS Serverless skills と Serverless Model Context Protocol (MCP) server をエージェントにインストールするよう指示します｡従来は複数のドキュメントを参照する必要があったエージェント設定の手間がなくなります｡Claude Code、 Kiro、 Cursor、 GitHub Copilot、 Codex、 Devin Desktop、 OpenCode の 7 種類のエージェントに対応します｡AWS GovCloud (US) を含む Lambda 提供リージョンで利用でき、 Middle East (Bahrain) と Middle East (UAE) は対象外です｡ 7/15(水) AWS Lambda が self-managed code storage に対応 AWS Lambda は､関数のデプロイパッケージをユーザー自身の Amazon S3 バケットから直接参照する self-managed code storage に対応しました｡従来 Lambda は関数や layer の作成時にコードを Lambda 管理ストレージへコピーしていましたが､`S3ObjectStorageMode` を `REFERENCE` に設定することでコピーを行わず S3 上のコードを直接参照します｡これによりコードストレージの上限が実質的に S3 バケットの容量まで拡張され､コピー処理が省かれるため関数の作成/更新後の有効化時間が短縮されます｡あわせて Lambda 管理ストレージのデフォルト上限が 75GB から 300GB per Region に引き上げられました｡self-managed code storage の利用に Lambda 側の追加料金は発生せず､S3 の標準料金のみが発生します｡ Amazon Cognito がパスワードハッシュ付きのユーザーインポートに対応 Amazon Cognito の CSV ユーザーインポートで、パスワードハッシュを含めてユーザーを取り込めるようになりました｡ 従来は CSV でインポートしたユーザーは初回サインイン時にパスワードリセットが必須でしたが、本機能によりインポート済みユーザーは既存の認証情報でそのままサインインできます｡ 対応アルゴリズムは bcrypt、scrypt、Argon2id、PBKDF2 with SHA-256 の 4 種類です｡ Amazon Cognito が利用可能な全 AWS リージョンで使えます｡ ただし、本機能のリリース前に作成された一部の user pool ではパスワードハッシュのインポートを利用できません｡ 7/16(木) Amazon S3 が S3 Standard-IA および S3 One Zone-IA への移行における 30 日間の最低保持期間を撤廃 Amazon S3 は､オブジェクト作成後 S3 Standard に 30 日間保持してから S3 Standard-IA および S3 One Zone-IA へ移行するという従来の制約を撤廃しました｡これにより S3 Lifecycle ルールで作成後 0 日 (作成当日) からこれらの Infrequent Access クラスへ移行できます｡両クラスは S3 Standard と比べて最大 40% 低いストレージコストで､必要時にはミリ秒単位でアクセスできます｡バックアップ､ログ分析､コンプライアンスなど数時間から数日で低頻度アクセスになるデータで効果があります｡なお､IA クラス自体の 30 日間の最低課金保持期間は引き続き適用される点に注意が必要です｡ AWS Sustainability に取水量 (water withdrawals) データを追加 AWS は AWS Sustainability サービスにおいて、従来の炭素排出量データに加え、ワークロードに関連する年間取水量 (water withdrawals) データを確認できるようにしました｡データは AWS リージョン別、サービス別、AWS アカウント別に年次で提供され、コンソールと API の両方から参照できます｡取水量はデータセンター運用のために取り込まれた水の総量を表し、効率改善は取水量の減少として反映されます｡このデータは対象リージョンすべてで追加料金なしに利用できます｡ Amazon S3 Event Notifications がシステム生成タグを含むように Amazon S3 Event Notifications が､ バケットに付与された system-generated tags (AWS サービスが自動付与するタグ) をイベントメッセージに含めるようになりました｡ 対応先は Amazon EventBridge､ Amazon SQS､ Amazon SNS､ AWS Lambda の全てです｡ これにより､ 数千個のバケットを個別に列挙せず 1 つの EventBridge ルールでタグを条件にイベントをフィルタリングできます｡ 追加料金はなく､ 全 AWS リージョンで利用でき､ 既存の設定変更も不要です｡ Billing and Cost Management Dashboards に Cost Efficiency ウィジェットを追加 AWS Billing and Cost Management (BCM) Dashboards に Cost Efficiency ウィジェットが追加されました｡コスト効率スコアの推移を、Cost Explorer、Budgets、Savings Plans/Reserved Instance のカバレッジ･使用率レポートと同じ 1 枚のダッシュボードで確認できます｡ウィジェットは Cost Optimization Hub のコンソールに直接リンクし、節約の推奨事項があればそのまま対処できます｡全ての AWS 商用リージョンで追加料金なしで利用できます｡ それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。