Weekly Google Cloud アップデート情報 - 2026年10月13日 ~ Gemini Enterprise: Antigravity 機能へのアクセス制御 ~ 皆さま、こんにちは。先週 (2026/10/02 - 2026/10/08) の主な Google Cloud（旧GCP）のアップデート情報を紹介します。 ※本記事の引用元:Google Cloud リリースノート 注目のアップデート Gemini Enterprise: Antigravity 機能へのアクセス制御 管理者は、組織内のユーザーが以下の Google Antigravity 機能へアク

本記事は 2026 年 10 月 5 日 に公開された「 Materialize once, query anywhere: Introducing Iceberg materialized views in Amazon Redshift 」を翻訳したものです。 Amazon Redshift は Apache Iceberg との統合を段階的に深めてきました。今年初めには、AWS Graviton を搭載した Amazon Redshift RG を発表しました。RG にはデータレイク向けにゼロから設計・統合されたベクトル化クエリエンジンが搭載されています。スキャンを別のフリートに送信するのではなく、ベクトル化された Parquet スキャン、スマートプリフェッチ I/O サブシステム、パーティションおよびファイルレベルのプルーニング、改良されたブルームフィルター、JIT Analyze による Iceberg 統計の自動収集を活用し、クラスター上でネイティブにスキャンを実行します。これらを組み合わせることで、 RA3 と比較して Apache Iceberg クエリが最大 2.4 倍高速化 され、vCPU あたりのコストは 30% 低く、データレイククエリにテラバイト単位のスキャン課金も発生しません。このパフォーマンス基盤の上で、 INSERT 、 CTAS 、 UPDATE 、 DELETE 、 MERGE による完全な ACID 準拠の Iceberg テーブルへの直接書き込みも可能です。アクセス制御は、外部スキーマの IAM ロールを通じた AWS Identity and Access Management (IAM) 権限、またはエンジン横断できめ細かな制御を行う AWS Lake Formation で管理できます。 Amazon Redshift は Iceberg マテリアライズドビューの作成と更新にも対応しました。マテリアライズドビュー (MV) は、コストの高い結合や集計を一度だけ事前計算し、その結果を Amazon Simple Storage Service (Amazon S3) または Amazon S3 Table Buckets 上の標準的な Apache Iceberg テーブルとして、AWS Glue Data Catalog に登録した状態で格納します。おなじみの SQL ( CREATE MATERIALIZED VIEW ... USING ICEBERG ) で作成でき、Amazon Athena、Amazon EMR 上の Apache Spark、AWS Glue をはじめとする Iceberg 互換エンジンからすぐにクエリできます。Amazon Redshift はインクリメンタルリフレッシュで MV を最新に保ち、結果は AWS Glue Data Catalog 上の通常の Iceberg テーブルであるため、他のカタログテーブルと同様にガバナンスや検出が可能です。 あるチームが Amazon Redshift で分析を行っているケースを考えてみましょう。変換処理はすでに Amazon Redshift SQL で書かれており、メンバーは Amazon Redshift に精通し、クエリエンジンへの投資も行っています。足りないのは、コストの高い事前計算済みの結果を、組織内の他のエンジン (Spark を使うデータサイエンスチームや Athena を使うアドホックレポーティングチームなど) と共有する手段です。データのエクスポートや別の変換スタックの構築なしにはそれができません。すでに運用しているエンジンから相互運用性と高速化を両立させたい、というのがこのチームの課題です。 Iceberg マテリアライズドビューを使えば、普段書いている SQL で Amazon Redshift 上に MV を作成するだけで、事前計算された結果がオープンな Iceberg テーブルとして格納されます。Spark や Athena のチームは、コピーや別パイプラインを管理せずに同じ結果を直接読み取れます。新しいデータが到着すると、インクリメンタルリフレッシュが変更分のみを再計算します。最もコストの高いクエリに対する単一の信頼できるデータソースを、すべてのエンジンで共有できるようになります。Amazon Redshift チームは 1 つのエンジンでエンドツーエンドの変換パイプラインを実行し、MV を生データ、クレンジング済みデータ、サービングレイヤー間のビルディングブロックとして活用できます。複数のエンジンをステージごとにつなぎ合わせる必要はありません。 オープンか高速かの二択ではありません。レイテンシーに敏感なダッシュボード向けには、Iceberg マテリアライズドビューを Amazon Redshift Managed Storage (RMS) にロードし、ネイティブな RMS マテリアライズドビューとして利用できます。 Iceberg MV と Amazon Redshift (RMS) マテリアライズドビューの使い分け Iceberg マテリアライズドビューは Amazon Redshift の標準的なマテリアライズドビューを置き換えるものではなく、異なるニーズに対応します。Amazon Redshift マテリアライズドビューは結果を Amazon Redshift Managed Storage (RMS) に格納し、Amazon Redshift からの高速な読み取りに最適化されています。一方、Iceberg マテリアライズドビューは結果をオープンな Iceberg テーブルとして Amazon S3 に格納し、任意のエンジンから読み取れます。結果をどこでどのように使うかに応じて選択してください。 Amazon Redshift (RMS) マテリアライズドビューを使う場面: クエリを Amazon Redshift からのみ実行する場合。 最も低い読み取りレイテンシーが必要な場合。インタラクティブなダッシュボードやサブ秒のルックアップでは、RMS からの読み取りは Amazon S3 上の Iceberg テーブルからの読み取りよりも大幅に高速です。 Amazon Redshift のみのワークロードで最もシンプルな選択肢を求める場合。 Iceberg マテリアライズドビューを使う場面: 事前計算した結果を Amazon Redshift 以外のエンジン (Athena、Spark、Amazon SageMaker AI、サードパーティエンジン) からデータのコピーなしに読み取りたい場合。 相互運用性のために Apache Iceberg を標準化しており、高速化を Amazon Redshift 専用のストレージ形式に依存させたくない場合。 エンドツーエンドのパイプラインを 1 つのエンジンで実行し、すべての下流コンシューマーが同じオープンな結果を共有する構成にしたい場合。 両者は補完関係にあります。 一般的なパターンとして、まずオープン性とエンジン横断アクセスのために Iceberg マテリアライズドビューでデータを構築・変換し、最もパフォーマンスが求められる結果だけを RMS マテリアライズドビューにロードしてインタラクティブなダッシュボードに使います。データはデフォルトでオープン、必要なところだけ高速にする構成です。 本記事では、以下の内容を扱います。 Iceberg マテリアライズドビューの意義と主なユースケース インクリメンタルリフレッシュとエンジン横断アクセスの仕組み 前提条件の設定 (IAM、Amazon S3、AWS Glue) 最初の Iceberg マテリアライズドビューの作成 Amazon Athena と PyIceberg からのエンジン横断アクセスの検証 このソリューションでは以下の AWS サービスを使用します。 Amazon Redshift (Serverless またはプロビジョニングされた RG) AWS Glue Data Catalog Amazon S3 (汎用バケットまたは Amazon S3 Tables) AWS Identity and Access Management (IAM) AWS Lake Formation (オプション、ガバナンス付きアクセス制御用) ソリューションの概要 Iceberg マテリアライズドビューを使えば、Amazon Redshift で集計を一度計算し、結果を Amazon S3 または Amazon S3 Table Buckets 上の標準的な Apache Iceberg テーブルとして格納できます。Iceberg 互換エンジンは、事前計算された結果を直接クエリできます。 図 1: Iceberg 互換エンジンが Amazon S3 から事前計算済みの MV を直接クエリ Amazon Redshift Serverless と Amazon Redshift RG で動作 Iceberg マテリアライズドビューは以下の環境でサポートされます。 Amazon Redshift Serverless – フルマネージドでオートスケーリングするコンピューティング。MV のリフレッシュとアドホッククエリを容量計画なしに並行実行できる、ワークロードが変動する環境に適しています。 Amazon Redshift RG (AWS Graviton 搭載のプロビジョニングインスタンス) – AWS Graviton プロセッサ上で動作するプロビジョニングクラスターで、独自に構築・統合されたベクトル化クエリエンジンを搭載。 データレイクワークロードで RA3 インスタンスと比較して最大 2.4 倍のパフォーマンスを vCPU あたり 30% 低い価格で実現 します。 注: Amazon Redshift RA3 および DC2 インスタンスタイプでは Iceberg マテリアライズドビューはサポートされません。 Amazon Redshift が Serverless またはプロビジョニングされた RG インスタンスで重い計算を一度実行します。すべての Iceberg 互換エンジン (Athena、Spark、SageMaker、AWS Glue) は、Amazon S3 または Amazon S3 Tables から事前計算済みの Iceberg MV を標準的な Amazon S3 の読み取りコストで利用できます。コンシューマー側に追加のコンピューティング課金は発生しません。 ユースケース Iceberg マテリアライズドビューは、分析、コスト最適化、AI ワークロードにわたるさまざまなパターンをサポートします。 1. 最適化を共有するメダリオンアーキテクチャ 課題: Bronze → Silver → Gold アーキテクチャでは、Silver/Gold レイヤーでの最適化は計算を実行したエンジンだけが恩恵を受けます。 Iceberg MV の場合: Amazon Redshift RG がインクリメンタルリフレッシュ付きで Silver と Gold レイヤーを Iceberg MV として計算します。出力は Amazon S3 上の標準的な Iceberg テーブルなので、追加のコンピューティングなしにすべてのコンシューマーが恩恵を受けます。 2. エージェント型 AI、フィーチャーストア、生成 AI ワークロードの強化 課題: AI エージェント、機械学習 (ML) パイプライン、生成 AI アプリケーションは、移動平均、顧客生涯価値、エンゲージメントスコアなどの事前計算済みフィーチャーを、データウェアハウスへの直接接続なしにフレームワークが利用できる形式で必要とします。 Iceberg MV の場合: 重い計算 (複雑な結合、ウィンドウ関数、統計集計) は Amazon Redshift Serverless または RG で一度だけ実行されます。ウィンドウ関数や COUNT、SUM 以外の集計を使用するマテリアライズドビューは、リフレッシュのたびにインクリメンタルではなく全体が再計算されます。MV が計算されて標準的な Iceberg テーブルとして Amazon S3 に格納されると、さまざまなコンシューマーがネイティブにアクセスできます。 Amazon SageMaker ノートブックとトレーニングジョブ は、JDBC ドライバー不要で PyIceberg を通じて Amazon S3 からフィーチャーを直接読み取ります。 Amazon Bedrock エージェント は、Retrieval Augmented Generation (RAG) 用の構造化データとして事前計算済みの分析結果にアクセスします。 Amazon EMR 上の Apache Spark は、大規模 ML トレーニングパイプライン向けに spark.table() でフィーチャーを利用します。 Amazon Athena は、アドホック分析やダッシュボード向けにマテリアライズ済みフィーチャーへのサーバーレス SQL アクセスを提供します。 インクリメンタルリフレッシュでフィーチャーを最新に保てます。インクリメンタルリフレッシュの対象条件については、 Apache Iceberg テーブルとして格納されたマテリアライズドビュー を参照してください。 3. コンピューティング統合によるコスト最適化 課題: 同じ集計を複数のエンジン (Amazon Redshift、Athena、Spark、サードパーティツール) で個別に再実行すると、各エンジンで重複したコンピューティングに課金が発生し、コンシューマーの数に比例してコストが増加します。 Iceberg MV の場合: Amazon Redshift Serverless または RG の 1 回のリフレッシュで集計を一度だけ計算します。コンシューマーは事前計算済みの結果を Amazon S3 から標準的なストレージ読み取りコストで直接読み取り、エンジン間の重複コンピューティングを解消します。統合するコンシューマーエンジンの数に応じてコスト削減効果は拡大します。 4. データ移動なしのガバナンス付きデータ共有 課題: チーム間で分析結果を共有するには、データのコピーやエンジン固有の共有メカニズムが必要です。 Iceberg MV の場合: 出力は AWS Lake Formation で管理されます。単一の権限モデルでアクセスを付与し、コンシューマーは好みのエンジンを使用できます。 5. 分析エンジン全体で単一の信頼できるデータソース 課題: 複数のチームが Spark、Amazon Redshift、Athena、カスタムツールにわたって同じ指標を個別に再計算し、不整合な数値が生まれます。 Iceberg MV の場合: 1 つの CREATE MATERIALIZED VIEW ... USING ICEBERG で Amazon Redshift Serverless または RG 上で指標を一度だけ計算します。すべてのエンジンが Amazon S3 から同じ Iceberg テーブルを読み取り、同じ数値、同じスナップショットで、突合作業は不要です。 仕組み Iceberg MV は Amazon Redshift のネイティブなマテリアライズドビュー機能を USING ICEBERG 句で拡張します。 CREATE MATERIALIZED VIEW awsdatacatalog.analytics.daily_revenue USING ICEBERG LOCATION 's3://amzn-s3-demo-analytics/daily_revenue/' PARTITIONED BY (day(order_date)) AS SELECT order_date, region, SUM(amount) AS total_revenue, COUNT(*) AS transaction_count FROM awsdatacatalog.source.transactions GROUP BY 1, 2; MV は Amazon S3 Table Buckets にも格納できます。 LOCATION 句を省略すると、Amazon S3 Tables がストレージを自動管理します。 インクリメンタルリフレッシュ Amazon Redshift はリフレッシュ間で Iceberg スナップショット ID を追跡します。 REFRESH MATERIALIZED VIEW の実行時に、変更されたソースパーティションを特定し、差分のみを再計算します。 インクリメンタルリフレッシュをサポートするパターン: GROUP BY 付きの SUM および COUNT 集計 集計なしのクエリ (行レベルの差分追跡) Iceberg テーブル間の INNER JOIN フルリフレッシュとなる構文 (サポートはされています): DISTINCT、外部結合、ウィンドウ関数、サブクエリ 集合演算 (UNION ALL、UNION、INTERSECT、EXCEPT) MIN、MAX、AVG、COUNT(DISTINCT)、SUM(DISTINCT) GROUPING SETS、ROLLUP、CUBE クロスクラスターリフレッシュ MV は作成したクラスターに紐付きません。適切な IAM ロールを持つ Amazon Redshift クラスターや Serverless ワークグループからリフレッシュできます。複数のクラスターが同じ MV を同時にリフレッシュしようとした場合、Amazon Redshift は AWS Glue Data Catalog を通じて調整し、一度に 1 つのリフレッシュのみが成功するようにして競合を自動的に防止します。同時実行の処理の詳細については、 Amazon Redshift Iceberg マテリアライズドビュー のドキュメントを参照してください。 エンジン横断アクセス 結果は標準的な Iceberg テーブルであり、特別なドライバーは不要です。以下の例のように、さまざまなエンジンから MV を読み取れます。 Amazon Athena: SELECT * FROM analytics.daily_revenue WHERE region = 'us-east'; Amazon EMR 上の Apache Spark: spark.table("analytics.daily_revenue").filter(col("region") == "us-east") Amazon SageMaker / PyIceberg: from pyiceberg.catalog import load_catalog catalog = load_catalog("glue", **{"type": "glue"}) df = catalog.load_table("analytics.daily_revenue").scan().to_pandas() 前提条件 Iceberg MV のセットアップには IAM、Amazon S3、AWS Glue の設定が必要です。以下の手順に従って環境を準備してください。 コンソールのスクリーンショット付きの詳細な手順については、Amazon Redshift ドキュメントの Iceberg マテリアライズドビューの開始方法 を参照してください。 設定するリソースの一覧は以下の通りです。 リソース 用途 作成するステップ IAM ロール (IcebergMvDefiner) MV 操作用の definer ロール (2 サービスの信頼ポリシー) ステップ 1–2 S3 バケット Iceberg MV データ (Parquet ファイル) の格納 ステップ 3 AWS Glue データベース AWS Glue Data Catalog で MV メタデータを管理 ステップ 4 クラスターロールの関連付け Amazon Redshift クラスターに definer ロールの引き受け権限を付与 ステップ 5 ステップ 1: IAM ロールの作成 以下の信頼ポリシーを持つ IcebergMvDefiner という名前の IAM ロールを作成します。2 つのサービスプリンシパルが必要な点に注意してください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "redshift.amazonaws.com", "glue.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } 2 つのプリンシパルが必要な理由: Amazon Redshift はマテリアライズドビュー操作を実行するためにロールを引き受ける必要があります。AWS Glue はマテリアライズドビューの definer ロールに代わって、ベーステーブルの権限を確認する必要があります。 ステップ 2: IAM ポリシーのアタッチ IcebergMvDefiner ロールに以下のスコープ付きインラインポリシーをアタッチします。Iceberg マテリアライズドビュー操作に必要な最小限の権限を提供します。 S3 アクセス (バケットにスコープ): s3-mv-access という名前のインラインポリシーを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::<>", "arn:aws:s3:::<>/*" ] } ] } AWS Glue Data Catalog アクセスポリシー (データベースにスコープ): glue-mv-access という名前のインラインポリシーを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetPartitions", "glue:BatchGetPartition" ], "Resource": [ "arn:aws:glue:<>:<>:catalog", "arn:aws:glue:<>:<>:database/<>", "arn:aws:glue:<>:<>:table/<>/*" ] } ] } IAM PassRole ポリシー (definer ロールにスコープ): mv-access という名前のインラインポリシーを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::<>:role/IcebergMvDefiner" } ] } ステップ 3: S3 バケットの作成 MV ストレージ用の S3 バケットを作成します。命名規則として iceberg-mv- を推奨します。デフォルト暗号化 (SSE-S3) を有効にし、パブリックアクセスをすべてブロックしてください。 ステップ 4: AWS Glue データベースの作成 AWS Glue Data Catalog に iceberg_mv という名前のデータベースを作成します。シンプルな create-database コマンドを使用します。データベースはデフォルトで IAM_ALLOWED_PRINCIPALS を継承し、Amazon Athena などのエンジンからのアクセスが可能です。 ステップ 5: ロールと Redshift の関連付け IcebergMvDefiner ロールを Amazon Redshift クラスターまたは Serverless 名前空間に関連付けます。 aws redshift modify-cluster-iam-roles --cluster-identifier --add-iam-roles arn:aws:iam:::role/IcebergMvDefiner ステップ 6: 大文字小文字の区別の設定 Amazon Redshift クラスターに接続し、以下を実行します。 SET enable_case_sensitive_identifier TO FALSE; 最初の Iceberg MV の作成 前提条件が整ったら、外部スキーマ、ベースの Iceberg テーブル、最初のマテリアライズドビューを作成できます。 ステップ 7: 外部スキーマの作成 CREATE EXTERNAL SCHEMA iceberg_schema FROM DATA CATALOG DATABASE 'iceberg_mv' REGION '<>' IAM_ROLE 'arn:aws:iam:::role/IcebergMvDefiner'; ステップ 8: サンプルデータ付き Iceberg ベーステーブルの作成 CREATE TABLE iceberg_schema.orders USING ICEBERG LOCATION 's3://<>/iceberg_mv_blog/orders' AS SELECT 1 AS id, 'us' AS region, 100 AS amount UNION ALL SELECT 2, 'eu', 200 UNION ALL SELECT 3, 'jp', 150; ステップ 9: Iceberg マテリアライズドビューの作成 CREATE MATERIALIZED VIEW iceberg_schema.sales_by_region USING ICEBERG LOCATION 's3://<>/iceberg_mv_blog/sales_by_region' AS SELECT region, SUM(amount) AS total, COUNT(*) AS num_orders FROM iceberg_schema.orders GROUP BY region; ステップ 10: MV の内容の確認 SELECT * FROM iceberg_schema.sales_by_region; 図 2: リージョン別に集計されたマテリアライズドビューの初回クエリ結果 ステップ 11: インクリメンタルリフレッシュのテスト ベーステーブルに新しい行を挿入し、MV をリフレッシュします。 INSERT INTO iceberg_schema.orders VALUES (4, 'us', 300), (5, 'eu', 50); REFRESH MATERIALIZED VIEW iceberg_schema.sales_by_region; SELECT * FROM iceberg_schema.sales_by_region; 図 3: 新しい行の挿入とリフレッシュ後のマテリアライズドビュークエリ結果 エンジン横断での検証 マテリアライズドビューは AWS Glue Data Catalog 上の標準的な Iceberg テーブルとなり、Amazon Redshift への接続なしに互換エンジンからアクセスできます。 Amazon Athena: SELECT * FROM iceberg_mv.sales_by_region WHERE region = 'us'; 図 4: Amazon Athena からのマテリアライズドビューのクエリ Amazon SageMaker / PyIceberg: from pyiceberg.catalog import load_catalog catalog = load_catalog("glue", **{"type": "glue"}) df = catalog.load_table("iceberg_mv.sales_by_region").scan().to_pandas() print(df) Amazon EMR 上の Apache Spark: spark.table("iceberg_mv.sales_by_region").filter(col("region") == "us").show() ビジネスケース 以下の表は、複数のエンジンで共通の集計を計算する代表的なシナリオを示しています。 比較項目 従来型 (サイロ化) Serverless/RG での Iceberg MV コンピューティングコスト 月額約 $7,500 (4 エンジン) 月額約 $1,500 (1 回のリフレッシュ) 指標の整合性 3～4 バージョン 1 バージョン 新しい指標の追加所要時間 数日 (エンジンごと) 数時間 (1 つの定義) ガバナンス エンジンごとの ACL IAM + オプションで Lake Formation コスト試算は、中規模の集計 (入力 1 TB、出力 100 GB) を Athena ($5/TB スキャン)、Amazon EMR 上の Spark ($0.096/hr × 4 ノード)、Amazon Redshift Serverless (8 RPU)、サードパーティエンジンの 4 つで日次実行する想定です。実際の削減額はワークロードにより異なります。 現在の制限事項 サポートされる SQL 構文、インクリメンタルリフレッシュの対象条件、既知の制限事項の最新リストについては、Amazon Redshift ドキュメントの Apache Iceberg テーブルとして格納されたマテリアライズドビュー を参照してください。 (オプション) Lake Formation ガバナンスの追加 組織でエンジン横断の一元的なアクセス制御が必要な場合は、IAM のみの設定に加えて AWS Lake Formation ガバナンスをレイヤーとして追加できます。Iceberg MV に対する Lake Formation 権限は粗粒度 (データベースおよびテーブルレベル) です。きめ細かなアクセス制御 (行フィルター、列フィルター) は Iceberg マテリアライズドビューではサポートされません。以下の追加手順は、本記事のウォークスルーと同じ環境で検証済みです。 IAM ロールの信頼ポリシーに lakeformation.amazonaws.com を追加します (redshift.amazonaws.com と glue.amazonaws.com に加えて)。 ロールのインラインポリシーに lakeformation:GetDataAccess を追加します。 S3 バケットを Lake Formation データロケーションとして登録します。 aws lakeformation register-resource --resource-arn arn:aws:s3::: --role-arn arn:aws:iam:::role/IcebergMvDefiner --region AWS Glue データベースを空の CreateTableDefaultPermissions で再作成します (Lake Formation がテーブルレベルのアクセス制御の権限を持つようになります)。 aws glue delete-database --name iceberg_mv --region aws glue create-database --region --database-input '{"Name":"iceberg_mv","CreateTableDefaultPermissions":[]}' definer ロールに Lake Formation 権限を付与します。S3 バケットへの DATA_LOCATION_ACCESS、データベースへの CREATE_TABLE/DESCRIBE/ALTER/DROP、テーブルへの ALL (付与オプション付き) を設定します。 Lake Formation の詳細な手順については、 Amazon S3 Tables と Iceberg マテリアライズドビューの合理化された権限の使い方 を参照してください。 クリーンアップ 継続的な課金を避けるため、本記事のウォークスルーで作成したリソースを削除してください。 DROP MATERIALIZED VIEW iceberg_schema.sales_by_region; DROP TABLE iceberg_schema.orders; DROP SCHEMA iceberg_schema; 注: DROP MATERIALIZED VIEW は AWS Glue カタログのエントリを削除しますが、Amazon S3 上の基盤データは削除されません。データを削除するには、Amazon S3 プレフィックスを手動で削除してください。 aws s3 rm s3://<>/iceberg_mv_blog/ --recursive まとめ Iceberg マテリアライズドビューは、オープンレイクハウスの約束をさらに前進させます。最適化そのものがポータブルになるのです。Amazon Redshift は Serverless または AWS Graviton 搭載の RG インスタンスで重い計算を一度だけ実行し、他のすべてのエンジンや ML パイプラインが追加のコンピューティングなしにその恩恵を受けます。まず 1 つの MV から始めてみてください。初めてエンジン間で数値が一致するのを確認できるはずです。そこからスケールしていきましょう。 参考資料 Getting started with Iceberg materialized views (Amazon Redshift documentation) Getting started with Apache Iceberg write support in Amazon Redshift (AWS Blog, Nov 2025) Achieve 2x faster data lake query performance with Apache Iceberg on Amazon Redshift How to use streamlined permissions for Amazon S3 Tables and Iceberg materialized views Meet Amazon Redshift RG 著者について Sudipta Bagchi AWS の SQL Analytics 担当シニアスペシャリストソリューションアーキテクトです。Amazon Redshift とオープンレイクハウスパターンを活用した高パフォーマンスの分析アーキテクチャ設計を支援しています。 Dhaval Shah AWS の SQL Analytics 担当シニアスペシャリストソリューションアーキテクトです。AI と大規模分析を支えるデータ基盤の構築を支援しています。 Srishti Mittal AWS のプロダクトマネージャーです。オープンデータレイクの高パフォーマンス化と分析エンジン間の相互運用性に注力しています。Apache Iceberg などのオープンテーブルフォーマットのプロダクト戦略をリードし、顧客やフィールドチームと連携して実際のデータレイクの課題をプロダクト機能に反映しています。 Gaurav Saxena AWS の Database Services (DBS) Amazon Redshift チームのプリンシパルエンジニアです。 Andre Hernich AWS の Database Services (DBS) Amazon Redshift チームのプリンシパルソフトウェアエンジニアです。 この記事は Kiro が翻訳を担当し、Solutions Architect の Yui Numazawa がレビューしました。

こんにちは、NTTドコモビジネス情報セキュリティ部です。 NTTドコモビジネスを含めたドコモグループでは今年も現場受け入れ型インターンシップを開催いたしました。 情報セキュリティ部でも5つのポストに対して8人のインターンシップ生に来ていただき、2週間にわたるプログラムに取り組んでいただきました！ インターンシップ生の目線で、ポスト紹介や体験した業務内容、振り返りをまとめてもらいました。 この記事では、それらをポストごとにご紹介します。 インターンシップ生目線のよりリアルな体験記を通して、次回以降に応募を検討される方の一助となれば幸いです。 【D1】CSIRTでのサイバー攻撃への対応実践と高度分析 ポスト紹介① 体験した業務内容① 演習1日目 演習2日目 振り返り① ポスト紹介② 体験した業務内容② Linuxのフォレンジック演習 Windowsのフォレンジック演習 振り返り② 【D10】CSIRT運用業務の効率化に向けたDX化 ポスト紹介 体験した業務内容 振り返り 【D11】CSIRTで脅威インテリジェンスをハンドリングするセキュリティエンジニア ポスト紹介 体験した業務内容 振り返り 【D12】ネットワークセキュリティ製品を活用したデータ/脅威分析、実装および運用高度化 ポスト紹介 体験した業務内容 NDR製品を用いた模擬攻撃の詳細調査 NDR製品における一次調査の手順書作成 振り返り 【D13】攻撃者視点で社内防御力を高めるセキュリティエンジニア ポスト紹介 体験した業務内容 ペネトレーションテストの実施とWriteup作成 改善提案表の作成 MITRE ATT&CKマッピング 振り返り おわりに 【D1】CSIRTでのサイバー攻撃への対応実践と高度分析 D1ポストは、2つのチームの合同ポストです。それぞれのチームの業務を体験していただきました！ ポスト紹介① EDR（Endpoint Detection and Response） 1 やSIEM（Security Information and Event Management） 2 からのアラート対応、および社内外から報告されたインシデントへの対応が体験できるポストです。インターンシップでは、隔離された検証環境において模擬攻撃を実施し、EDRのアラート精度を検証しました。 体験した業務内容① MITRE社が開発し、現在はApache Software Foundationにおいて開発が進められている攻撃シミュレーションツール「 Apache Caldera 」を用い、さまざまな攻撃手法を再現しました。そのうえで、「どのような操作やコマンドがEDRに検知されるのか」「逆に、どのような挙動が検知されにくいのか」という観点から分析をしました。 演習環境は、攻撃するためのVM1台と、攻撃対象となるVM2台で構成されていました。 演習1日目 1日目は、模擬攻撃によって発生したEDRのアラートを分析し、インシデント対応を体験しました。 具体的には、提示された4件のアラートについて、以下の観点から調査・検討しました。 なぜアラートが発生したのか EDRはどのような挙動を検知したのか どのような脅威が考えられるのか 実際の運用ではどのような対応が必要になるのか 単にアラートの内容を確認するだけでなく、想定される脅威や必要となる対処を考えることで、インシデント対応担当者に求められる考え方を学ぶことができました。 演習2日目 2日目は、Apache Calderaを用いてオリジナルの攻撃シナリオを作成し、その挙動がEDRにどのように検知されるのかを検証しました。 攻撃シナリオを自ら設計することで、攻撃側の視点と防御側の視点の両方からセキュリティ対策を考えることができました。 また、実際にシナリオを実行して検知結果を分析することで、EDRがどのような振る舞いを重視して監視しているのか、理解を深めることができました。 今回追加した攻撃シナリオの例は以下のとおりです。 ネットワークをスキャンして、隣接IPを調査 見つけたIPに対してポートスキャン cuppをcloneして、パスワードリストを作成 作成したリストを使ってHydraでログイン試行 特定したパスワードでログイン 振り返り① 今回の演習を通じて、アラート対応業務への理解を深めることができました。実際の運用では重大なインシデントが発生することは多くなく、日々発生するアラートの中には誤検知が多いことを学びました。このことから、多数のアラートの中から誤検知を適切に判断し、迅速に対応することの重要性を理解しました。また、IoC（Indicators of Compromise） 3 だけでなくIoA（Indicators of Attack） 4 に着目した検知の考え方にも触れ、どのような振る舞いをルール化すれば効果的な検知につながるのかを考える良い機会となりました。 今回の演習から、実際の環境におけるEDRの具体的な使い方や運用方法を学ぶことができました。また、自ら攻撃シナリオを作成し、発生したアラートを調査するという一連の流れを経験しました。この過程で、攻撃側と防御側が相互に技術を高め合うことの重要性を確認できました。今後は、攻撃側と防御側、双方の視点から捉えて技術を高めていきたいと思います。 EDRを実際に使用することで、これまで不明瞭であったCSIRTの具体的な業務プロセスについて理解を深められました。また、実際の対応においては、Red Teamの視点を持つことの重要性と、チーム内での連携やコミュニケーションが不可欠であることを学びました。今回の経験を踏まえ、今後の学習においてもApache Calderaを日常的に活用していきたいと考えています。 ポスト紹介② Blue Teamの一員として、デジタルフォレンジック調査や脆弱性管理などを実施する業務です。インターンでは、フォレンジック演習に取り組みました。 体験した業務内容② 本ポストの業務では、LinuxとWindowsを対象としたフォレンジック演習に取り組みました。 Linuxのフォレンジック演習 Linuxのフォレンジック演習では、DrupalのRCE（Remote Code Execution）脆弱性 を悪用した攻撃を題材として扱いました。RCEは、攻撃者がネットワーク越しに対象サーバやアプリケーション上で任意のコードを実行できてしまう脆弱性です。 演習では、Apacheのアクセスログや認証ログ、コマンド実行ログなどを調査し、攻撃の痕跡や侵入後の活動を分析しました。 集めた攻撃の証拠を時系列で確認することで、攻撃者によるコマンド実行や権限昇格、バックドア用のユーザ作成による永続化、Webシェルの設置まで、攻撃の流れを追跡しました。 Windowsのフォレンジック演習 Windowsのフォレンジック演習では、被疑端末から取得した各種アーティファクト（システムや利用者の活動履歴を示すデータ）を調査しました。 具体的には、ファイル操作の履歴を確認できる「MFT（Master File Table）」、Windowsのイベントを記録する「イベントログ」、実行されたプログラムの情報が残る「Prefetch」や「Amcache」、ユーザ操作の痕跡を確認できる「UserAssist」、ネットワーク通信を分析する「PCAP（Packet Capture）」などを用いて、不審な活動の有無を分析しました。 その結果、ユーザ端末上でコードエディタ製品の正規ツールを装ったマルウェアが実行され、端末のユーザ情報やIPアドレスなどの情報が攻撃者側へ送信されていたことを確認しました。 振り返り② LinuxおよびWindows環境のフォレンジック演習を通じて、インシデント発生時にどのログを優先的に確認すべきか、またどのような観点で調査を進めるべきかを再確認できました。時系列で事象を整理する重要性は理解していましたが、ログから痕跡を効率的に見つけ出す視点も重要であると学びました。特にWindowsでは、UserAssistだけでなくPrefetchやAmcacheなど複数のアーティファクトを組み合わせて分析することで、プログラムの実行時刻や実行回数をより正確に把握できることが印象的でした。答え合わせや他の参加者との議論を通じて、知らなかったアーティファクトや調査手法についても学ぶことができ、大変有意義な経験となりました。 演習を通じて、フォレンジック調査に必要となる各種ツールの用途や使用方法を学ぶとともに、実際の解析に至るまでの具体的な業務フローを把握できました。また、社員の方からの解説を聞く中で、ログから抽出・推測できる情報や調査手法について、自分のフォレンジックに関する知識は十分でないと痛感しました。今回の経験を踏まえ、今後はログ分析やフォレンジックに関する知見をさらに広げ、継続して学習に取り組みたいと考えています。 フォレンジック演習を通じて、フォレンジックの実務についてより具体的な理解を得ることができました。特に、参加者3名がそれぞれ異なる手法を用いて調査を進めている点を確認でき、調査における多角的な視点の重要性を認識しました。また、実際の過程を通じて、OSの仕組みをはじめとする、自身に不足している知識が明確になりました。今後はこれらの領域についても継続的に学習を進め、技術的な理解を深めていきたいと考えています。 【D10】CSIRT運用業務の効率化に向けたDX化 ポスト紹介 セキュリティオペレーションの効率化と高度化を目的とした開発業務を体験しました。 具体的には、①アラートメールの自動チケット化と、②問い合わせ時の通知機能の自動化に取り組みました。 体験した業務内容 まず、①アラートメールの自動チケット化について説明します。 メール受信ボックスにセキュリティアラートメールが届いた際に、メールの内容を抽出してチケット管理システムに自動起票し、添付ファイルを保管領域に保存したうえで、コミュニケーションツールにアラートの発生を知らせる通知システムを開発しました。 今回は、インシデントレスポンスに必要な情報かどうかという観点から、以下の3種類のメールごとに実装を分けました。 初報メールの場合、新たにチケットを作成し、通知する 更新メールの場合、既存のチケットを更新し、通知する 週間レポートメールの場合、何もせずに処理を終了する 本格的なシステムの作成前に、まず2人で要件定義の洗い出しを行いました。 これまで要件定義の経験がなかったため、実際に作成しながら学ぶことが多くありました。 特に、エラーなどの異常系をどこまで想定して記載すべきかについては、2人で悩みながら検討を重ね、試行錯誤しながら完成させました。 要件定義を作成したことで、今後何を作成しなければならないのかが明確になりました。 その後は、要件定義の内容を基に各自でフローチャートを作成し、処理の流れや実装内容への理解を深めることができました。 技術的に不明で調査が必要な箇所には吹き出しでメモを残し、開発前にモックアップを作成して技術調査をしました。 本実装では、これまで整理してきた要件や調査結果を基に、自動化ツールを用いてワークフローを作成しました。 アラートメールに含まれる情報を抽出し、チケット管理システムへ必要な情報を自動で起票するとともに、コミュニケーションツールへの通知を自動化する仕組みを構築できました。 実装の過程では、初めての自動化開発ということもあり、エラー対応や処理の実装方法に悩む場面が多くありました。 しかし、その都度原因を調査し、設定や処理内容を見直しながら試行錯誤を重ねることで、ひとつひとつ課題を解決できました。最終的には要件を満たすワークフローを完成させることができ、技術的な成長を実感するとともに、大きな達成感を得ることができました。 次に、②問い合わせ時の通知機能の自動化について説明します。 ①で自動化ツールを用いた開発への理解を深めた後は、それまでに学んだ知識や経験を活かし、チケットシステムの利用者から送信される問い合わせをフォームとリストで管理し、新たな問い合わせが届いた際にチケットシステムの運用担当者へ通知するシステムを開発しました。 前回の開発で得た知見を活用しながら設計・実装を進めることで、サービス間の連携や自動化について、さらに理解を深めることができました。 また、問い合わせフォームが送信されると、その内容が管理リストに投稿されます。 このとき、コミュニケーションツールへの通知だけでなく、状態ステータスも変更する仕様を実装しました。 新規の問い合わせが登録されると、問い合わせ内容を含む通知が関係者へ自動送信される仕組みを実装しました。 また、通知内のアクションボタンを操作することで、リストで管理している問い合わせの状態を「受付」から「対応中」へ、「対応中」から「完了」へ更新できるようにしました。 これにより、問い合わせ対応状況の管理を効率化し、運用担当者が迅速に対応できる仕組みを実現できました。 振り返り 今回のインターンシップで、会社での開発は、他のチームの方々や開発したツールを使用する利用者、今後新たに機能を拡張する他の開発者のことまで考えながら進めるものであると、身をもって実感しました。特に、実装方法が複数考えられる場合に、どのパターンを選ぶかの判断基準が利用者や他の開発者にあることを知ることができ、インターンシップに参加してよかったと感じました。 2週間のインターンシップを通して、期間内に成果物を完成させるための時間・スケジュール管理の必要性や、業務を進めるうえでの情報共有・コミュニケーションの重要性、トライアンドエラーを繰り返して問題を解決する力を理解し、身につけました。この経験を活かし、さらなる自己研鑽を進め、応用や拡張にも適応できる人間に成長したいと考えています。 【D11】CSIRTで脅威インテリジェンスをハンドリングするセキュリティエンジニア ポスト紹介 サイバー攻撃による社内システムへのインシデント被害の最小化と未然防止をミッションとしている、セキュリティエンジニアのポストです！ チーム内で行っている業務はさまざまですが、代表例として、公開情報から脅威アクターの動きを観測しています。 また、日々更新される脆弱性情報の中からリスクの高いものをレポーティングし、関連部署へシステムのバージョン管理やアップデートを促しています。 体験した業務内容 社内システムに関連する脆弱性が公開された際に、他部署へ注意喚起するためのインテリジェンスレポートを、ClaudeのSkillを用いて自動的に作成できるよう実装しました。 フロンティアAIの登場により脆弱性の報告数が増加し、対応に追われている組織も多く、私が参加したチームでも同様の課題を抱えていました。 この課題を解決するために、取り上げるに値する脆弱性のスコープごとにSkillをオーケストレーションすることで、網羅性を確保しつつ利用者の調査業務の時間短縮につながるように設計した点がポイントです。 実際にこのSkillを使用することによって、業務上で改善された点は3つあります。 1つめは、インテリジェンスレポートの品質の担保です。これまでは各メンバーがそれぞれLLMを用いてレポートの草案を作成していましたが、プロンプトの与え方や参照ソースの選び方がメンバーごとに異なるため、同じCVEを扱っても出来上がる草案の粒度や観点にばらつきが生じていました。 今回作成したSkillでは、収集すべき情報源・記事の構成・文体指針をあらかじめ定型化したことで、誰が実行しても一定の水準を担保できる状態にしました。 2つめは、レビュー工数の削減です。従来はレビュアーが草案を受け取ってから複数回の指摘・修正のやり取りが発生していましたが、Skill側で文体チェック、参照リンクの生存確認、未確認項目の可視化までを自動で行うようにしたため、レビュー工数が実質1回で済むようになり、レポート作成全体に要する時間が大幅に短縮されました。 最後に、作成コストの安さです。1本のインテリジェンスレポートを生成するのにかかる費用はOpus 4.7で500〜600円程度に収まっており、頻繁に運用しても負担にならない水準を実現できました。 振り返り 本課題を始める前に、脅威インテリジェンスとは何かを知るため、5つのSTEPからなる総合演習で構成されるコースワークに取り組みました。 その際、インテリジェンスという抽象的で説明しがたい概念を理解するため、アメリカ統合参謀本部が公開している「JP 2-0 5 」を読みましたが、「インテリジェンスとは何か」がますます理解できなくなり困りました。 理解が及ばない部分については、抽象的な概念をつかむために脅威インテリジェンスの教科書を読み込みました。インターンシップ期間中は四苦八苦しましたが、基礎的かつ重要な事項を、苦しみながらも自分の言葉で表現できたときはとても嬉しかったです。 本課題では、チームの日常業務の効率化とリスクの明確化を目標に、ClaudeのSkillでインテリジェンスレポートの自動生成に取り組みました。 文章だけで見ると「あまりたいした実装ではないのでは……？」と思われるかもしれません。しかし今回の実装は、現場でも「何が課題なのか、何ができると嬉しいのか」を要件定義しきれていない暗黙知を扱うものであり、私個人で完結できる内容ではありませんでした。 そのため、メンターの方々や上長を含むチームメンバーと議論を重ねながら進める必要があり、相応の時間を要する難易度の高い取り組みとなりました。 要件を定義しづらい課題にチームメンバーと協働しながら取り組んだ経験は、これまでの個人開発では決して得られないものであり、本課題を通して課題設定力と、短い期限のなかで冷静に優先順位を判断し物事を推進する力が身についたと感じています。 最後に、本インターンシップ全体の学びを書いて終わりたいと思います。脅威インテリジェンスは、科学的な検証によって確実性が保証される領域ではありません。仮説から捕捉できた脅威はエッジケースかもしれませんし、逆に何もわからなくても、それが現時点でのベストエフォートかもしれません。 だからこそ、直感的な洞察と論理的な分析の双方から解釈した情報を意思決定に活かすことがアナリストの責務ではありますが、これを成し得るには蓋然性を正しく判定するためのプロセスを踏み続ける必要があり、この営みを継続することの難しさを学びました。 【D12】ネットワークセキュリティ製品を活用したデータ/脅威分析、実装および運用高度化 ポスト紹介 本ポストでは、新たに導入するセキュリティ製品の評価や、組織で活用していくための運用支援業務を行っています。 その中で私は、ネットワーク上の不審な通信を検知・分析するNDR（Network Detection and Response）において、模擬攻撃を詳細に調査し、その知見を誰もが活用できるよう手順書の作成に取り組みました。 体験した業務内容 NDR製品を用いた模擬攻撃の詳細調査 NDRで検知されたアラートの詳細調査を実施しました。アラートに関連する通信を条件で絞り込みながら確認し、実際にどのような攻撃行動が行われていたのかを分析しました。 調査を通じて、得られた情報をもとに攻撃者の行動を推測し、攻撃のシナリオを組み立てながら通信内容を分析することの重要性を学びました。 上記の図は、アラートに関連する通信をSQL文を用いてフィルタリングした結果です。 NDR製品における一次調査の手順書作成 NDRでアラートが発生した際に、一次調査で使用する手順書を作成しました。手順書の作成にあたっては、製品の機能や操作方法を整理するだけでなく、実際にアラートが発生した際の調査の流れを想定しながら内容を検討しました。 また、利用者が必要な情報に迷わずたどり着けるよう、実際の運用で求められる確認事項や判断材料を意識して文書化を行いました。 上記の図は、実際に作成した手順書の一部です。手順書の作成にあたっては、実際のNDRの操作画面のスクリーンショットを使用し、図中の確認箇所をナンバリングして本文との対応関係を明確にしました。 また、模擬攻撃の詳細調査を実施した際に理解や判断に迷った箇所については、調査時の観点や確認ポイントを補足するなど、利用者が迷わず調査を進められるよう工夫しました。 振り返り 今回のインターンシップでは、セキュリティ製品そのものだけでなく、組織における運用についても学ぶことができました。特に手順書の作成では、操作方法をまとめるだけでなく、その情報がどのように活用されるのかを意識する必要がありました。 また、実際の運用では他組織との連携も求められるため、利用者の視点で必要な情報を整理し、分かりやすく伝えることの重要性を学びました。 今後は、本インターンシップで得たセキュリティ製品の知識や運用設計の考え方を活かし、実際の運用を見据えたシステム設計や仕組みづくりができるエンジニアを目指したいと考えています。 【D13】攻撃者視点で社内防御力を高めるセキュリティエンジニア ポスト紹介 NTTドコモビジネス社内の組織やサービスに対して脅威ベースのペネトレーションテストを実施し、セキュリティ対策の状況をRed Teamの立場で継続的にチェックする業務を行っているチームに所属させていただきました。 具体的には、攻撃ツールの検証や環境構築、攻撃シナリオの整備、改善提案などに従事しました。 体験した業務内容 ペネトレーションテストの実施とWriteup作成 VulnHubから入手した脆弱なLinuxマシン2台に対してペネトレーションテストを実施し、Writeupを作成しました。 ペネトレーションテストは、情報収集、脆弱性調査、初期侵入、権限昇格の順で行いました。 1台目は、DrupalというCMS（Content Management System） 6 のRCE脆弱性を悪用して初期侵入を実施し、SUIDの設定不備を悪用して権限昇格をしました。 2台目は、2台目は、WordPressのプラグインの脆弱性を悪用してサーバ上のファイルを読み取るLFI（Local File Inclusion） によりパスワード情報を取得できました。LFIは、本来アクセスできないサーバ内のファイルを読み取れてしまう脆弱性です。 その後、保存されていたパスワードをリバースブルートフォースすることで侵入できました。 また、実施した攻撃手法のうち、チームのナレッジ集になかったものを追加させていただきました。 改善提案表の作成 発見した脆弱性について、仮想の会社で脆弱性を悪用された際に想定されるリスクや改善案などをまとめた改善提案表を作成しました。 メンター社員の方からアドバイスをいただきながら、実際の業務に近い改善提案をできました。 MITRE ATT&CKマッピング MITRE ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge） は、サイバー攻撃者が用いる戦術や攻撃手法を整理したナレッジベースです。 本演習では、実施した攻撃をMITRE ATT&CK Navigator上でマッピングし、どのような攻撃手法が用いられたかを可視化しました。 濃い赤は2台に共通していた攻撃手法、薄い赤は片方のマシンでのみ使用した攻撃手法です。 振り返り 今回のインターンシップを通じて、本ポストでは攻撃を成功させるための技術力だけでなく、運用側にどのような改善を促すかを考える提案力も重要であると学びました。特に改善提案表の作成では、場当たり的な対策を提示するだけでなく、脆弱性を生まないために業務プロセスをどのように改善していくべきかまで踏み込んで考えることができました。 また、Writeupの作成では、相手に伝わりやすいレポートの作成方法についても学ぶことができました。 おわりに 本記事では、2週間のプログラムに取り組んでいただいたインターンシップ生の皆さまに、それぞれのポストでの業務と、そこで得た学びを綴っていただきました。ご多忙のなか快くご協力いただき、ありがとうございました。 本記事を読んで少しでも興味を持たれた29卒以降の方は、ぜひ来年度のインターンシッププログラムへご応募ください。皆さまとお会いできることを楽しみにしています！ Endpoint Detection and Response。PCやサーバなどの端末上の動作を継続的に記録・監視し、不審な挙動の検知と、その後の調査・対応を支援する仕組みです。 ↩ Security Information and Event Management。各種機器やソフトウェアが出力するログを一元的に集約し、相関分析によって脅威の兆候を検知する仕組みです。 ↩ Indicator of Compromise（侵害指標）。マルウェアのハッシュ値や通信先のIPアドレス・ドメインなど、侵害が発生したことを示す個別の痕跡を指します。 ↩ Indicator of Attack（攻撃指標）。個々の痕跡ではなく、攻撃者が目的を達成するまでにとる一連の振る舞いに着目した指標で、進行中の攻撃の兆候を捉えることを狙いとします。 ↩ Joint Publication 2-0「Joint Intelligence」。アメリカ統合参謀本部議長の指揮のもとで整備される統合ドクトリンのうち、情報（インテリジェンス）分野の基幹文書にあたります。統合作戦における情報の役割や基本原則、情報が生み出されるまでの一連のプロセスがまとめられています。文書は 統合参謀本部のサイト で公開されています。 ↩ Contents Management System。Webサイトのテキストや画像などのコンテンツを、HTMLを直接編集することなく作成・管理・公開できるようにするシステムです。本記事に登場するDrupalやWordPressがこれにあたります。 ↩