みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 気づけば 8 月も残りわずかとなりました。朝晩には少しずつ秋の気配も感じられますね。今週は国内のお客様事例が豊作です。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、8 月 17 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「PKUTECH が Amazon Bedrock を活用して実現した AI-CSPM「Egeria-Security」のセキュアな設計」を公開 PKUTECH 様は、システムインテグレーション事業を展開し、生成 AI を活用した自社プロダクト開発に注力する企業です。従来の CSPM ツールには、チェックの根拠がブラックボックス化しやすく、カスタムルール作成のハードルが高いという課題がありました。AI-CSPM「Egeria-Security」は、自社のコンプライアンス文書を起点に Amazon Bedrock でスキャンポリシーを自動生成することでこれを解決しています。PoC では取り込んだ観点の約 50〜60% のポリシー自動生成を確認し、MVP 完成までの期間も想定 12〜18 ヶ月から約 4〜6 ヶ月に短縮されました。ハルシネーション対策や閉域推論など、機密データを扱う AI SaaS の設計判断も具体的に語られています。 AWS生成AI国内事例ブログ「株式会社日新 × AWS：人とAIが協働する新しい物流「オプティマAI」」を公開 株式会社日新様は、1938 年創業のグローバルな国際物流企業です。貿易書類の作成・照合や HS コード (税番) の判定に、多大な時間と専門知識を要する課題がありました。「人とAIの協働」をコンセプトに、Amazon Bedrock の RAG で税番候補を根拠付きで提示する「オプティマHS」と、AI-OCR で貿易書類を照合する「オプティマAI-OCR」を実用化しています。AI が候補を提示し人が最終判断する設計で、生産性向上とノウハウ継承を両立しました。将来は顧客と日新の AI 同士が MCP などで連携する、サプライチェーン全体の最適化を構想しています。 AWS生成AI国内事例ブログ「サンリオのエンジニア 6 名が 2 日間で体感した AI 駆動開発の可能性 — AI-DLC Unicorn Gym 座談会」を公開 サンリオ様のデジタル事業開発部と開催した、AI 駆動開発ライフサイクル (AI-DLC) 体験ワークショップのレポートと座談会記事です。2 チーム 6 名が Kiro を活用して実プロダクトを題材に全フェーズを体験し、inception 開始から本番マージまで約 5 時間で完了したストーリーもあります。AI との対話の結果「あえて実装しない」判断に至った話など、AI で実装が速くなるほど「何を作らないか」に価値が生まれるという気づきが印象的です。 AWS生成AI国内事例ブログ「Amazon Bedrock とロボティクスで目指す「未来の実験室」 ― AWS Summit Japan 2026 の Physical AI ―」を公開 コニカミノルタ様と共同執筆した、AWS Summit Japan 2026 での Physical AI 展示の解説記事です。「緑色を作ってください」という自然言語の指示を Amazon Bedrock 上の基盤モデルが構造化し、ロボットアームがフィルムを重ねて目標色に近づける閉ループ実験を紹介しています。LLM の役割を中間表現への変換に絞り、座標制御は決定論的な制御層に任せる設計で、軽量モデルでも安全性と速度を両立している点が読みどころです。 AWS生成AI国内事例ブログ「【開催報告】AWS Summit Japan 2026 レポート：SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX」を公開 AWS Summit Japan 2026 に出展された SUMCO 様のブース展示を共同で振り返る開催報告です。半導体ウェーハ製造のビッグデータを Amazon Redshift 中核の基盤に集約し、データ加工の仕組み「RedPulse」と、生成 AI で自然言語データ解析を行う「SynchroFabAI」により、組織全体のデータ活用の底上げを図る取り組みを紹介しています。厳しいセキュリティ要件下でデータと生成 AI の活用を検討する製造業の方におすすめです。 ブログ記事「AWS Bedrock LLM Day Japan【開催報告】」を公開 2026 年 7 月 28 日に東京で開催された「AWS Bedrock LLM Day Japan」の開催報告です。最新アップデートの紹介に加え、NEC 様 (Claude Cowork を 2 週間で 12 万人規模に本番展開)、丸紅様、ファストドクター様、リクルート様、jinjer 様の 5 社が本番運用の実践知を共有しました。生成 AI を PoC から本番へスケールさせるヒントが凝縮されています。 ブログ記事「AWS ジャパン地域創生支援プログラム（LEAP by AWS ジャパン）を発表 — 地域経済のAIトランスフォーメーションを包括支援」を公開 地域経済の AI トランスフォーメーションを包括支援する日本独自の新プログラム「LEAP by AWS ジャパン」が発表されました。地域企業の AI・クラウド活用支援 (条件を満たせば最大 5 万 US ドル相当の AWS クレジット)、地域 IT サービス企業のスキル強化、デジタル人材育成、地域データ活用支援の 4 つのメニューで構成されます。8 月 18 日から 28 日に全国 8 か所で開催される「デジタル社会実現ツアー」でも順次紹介されます。 ブログ記事「どの Kiro アプリを選べばいい？」を公開 Kiro は IDE、CLI、Web、Mobile、Kiro Crew という複数のアプリとして利用できます。本記事では、これらが単一のエージェントハーネスに接続する「玄関口」であることを解説し、用途に応じて使い分けるための判断フレームワークを紹介しています。どのアプリでも同じエージェントと設定が付いてくるので、Kiro をどこから触るか迷っている方はぜひご一読ください。 サービスアップデート Amazon Quick の Microsoft 365 拡張機能が一般提供開始 Excel、PowerPoint、Word、Outlook の中で Amazon Quick が直接タスクをこなす Microsoft 365 拡張機能が一般提供開始されました。ピボットテーブルの作成、組織テンプレートに沿ったスライド生成、変更履歴付きの文書編集、受信トレイの整理といった作業を、Quick が持つ業務データを踏まえて AI に任せられます。東京リージョンを含む 6 リージョンで利用可能です。 Amazon Quick がカスタム権限のデフォルト拒否に対応 Amazon Quick のカスタム権限に、新しい AI 機能をユーザーに届く前に自動で制限するガバナンス設定 Deny by default が追加されました。これまで新機能はリリースと同時に全ユーザーが利用可能になるため、管理者は事後の対応を迫られていました。カスタム権限プロファイルで AI 機能カテゴリを制限しておけば、以後の新機能はリリース時点で自動的に拒否され、管理者が準備できたものから個別に許可できます。詳細は こちらのドキュメント をご参照ください。 AWS Security Agent が予算コントロールと検出結果の再検証に対応 AI エージェントが Web アプリケーションの脆弱性を自律的にテストする AWS Security Agent (現在は AWS Continuum の一部) が、タスク時間の上限設定と検出結果の再検証に対応しました。テストは上限に達するとそれまでの検出結果を保持したまま停止するため、コストを予見しながらペネトレーションテストを実行できます。また修正のデプロイ後に特定の検出結果だけを再検証して解消済みかどうかの判定を得られるようになり、フルテストの再実行なしで修正確認が完結します。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock が OpenAI モデルの API サポートを拡大し Cross Region Inference を導入 OpenAI の GPT-5.6 (Sol、Terra、Luna) が bedrock-runtime エンドポイントに対応し、Responses、Chat Completions、Converse の各 API から利用できるようになりました。あわせて Global および Geo (US) の Cross Region Inference に対応し、容量管理なしで高いスループットと低いトークン単価を利用できます。ログやコスト配分を他のモデルと共通の仕組みで扱える点も嬉しい改善です。 Amazon Bedrock で OpenAI GPT-5.6 Sol の値下げを発表 Terra、Luna に続き、GPT-5.6 Sol の API 価格が引き下げられました。入力は 100 万トークンあたり 4 USD (20% の値下げ)、出力は 20 USD (33.3% の値下げ) となり、少なくとも 2026 年 11 月 21 日までこの価格が適用されます。エージェンティックコーディングに強いモデルを、大量トークンを消費するワークロードでも使いやすくなりました。 Amazon Bedrock が SpaceXAI Grok 4.6 をサポート コーディングやエージェントタスク向けのフロンティアモデル SpaceXAI Grok 4.6 が Amazon Bedrock で利用可能になりました。US Geo と Global の Cross Region Inference に対応し、データ処理を米国内に保ちながらのスケールと、需要ピーク時の高スループットを両立できます。 AgentCore payments が Amazon Bedrock AgentCore で一般提供開始 AI エージェントが有料の API、MCP サーバー、コンテンツを自律的に発見・支払いできる AgentCore payments が一般提供開始されました。Coinbase や Stripe Privy のウォレット統合、インフラレイヤーで強制される支払い上限、AgentCore Observability による可観測性を備え、「取引するエージェント」を本番で安全に運用できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore の Web Search がフィルタリング機能を追加、東京リージョンに拡大 AI エージェントの回答を最新の Web 情報でグラウンディングする AgentCore の Web Search Tool が、東京リージョンとアイルランドリージョンに拡大されました。あわせてツール呼び出しごとにドメインの許可/除外リストや公開日の期間を指定できるようになり、情報源と鮮度に統制が求められるエージェントを構築しやすくなりました。国内でエージェントを運用している方には待望のアップデートです。 Amazon SageMaker の生成 AI 推論レコメンデーションが SageMaker AI Studio で利用可能に 生成 AI モデルのデプロイに最適なインスタンスや最適化戦略を提案する Generative AI Inference Recommendations が、SageMaker AI Studio からノーコードで利用できるようになりました。ユースケースと最適化目標を選ぶだけで実 GPU 上のベンチマークが実行され、計測データ付きの推奨構成が返ります。数週間かかっていた構成探索を数時間に短縮でき、東京リージョンを含む 7 リージョンで利用可能です。 AWS Console-to-Code が対応サービスを 32 に拡大、クロスリージョン記録に対応 コンソール操作を記録して IaC コードに変換する Amazon Q Developer の Console-to-Code が、対応サービスを 6 から 32 へ拡大しました。リージョンやブラウザタブをまたいだ操作も 1 つのリストに統合して記録できるようになり、マルチリージョン構成も文脈を失わずにコード化できます。詳細は こちらのドキュメント をご参照ください。 Kiro の週次アップデート (Web の Okta / Microsoft Entra ID 対応、CLI 2.19 ほか) Kiro Web が Okta と Microsoft Entra ID によるサインインに対応し、既存の OIDC アプリケーションの設定追加だけでチーム利用を開始できるようになりました (Kiro Pro 以上)。Kiro CLI 2.19 では、スペックレビューのマウス操作対応と、接続断やスロットリングからの自動復旧が入り、長時間セッションの安定性が向上しています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本記事は 2026 年 8 月 18 日 に公開された「 Fresher insights, faster decisions: talabat’s near-real-time analytics across AWS and Google Cloud 」を翻訳したものです。 talabat は、中東・北アフリカ (MENA) 地域をリードする日常生活アプリです。レストランや小売店の幅広い選択肢から、食品、食料品、その他の日用品を手軽に注文でき、パーソナライズされた体験を提供しています。2004 年にクウェートで創業した talabat は、アラブ首長国連邦、オマーン、カタール、バーレーン、ヨルダン、イラク、エジプトに事業を拡大し、2025 年 12 月時点で月間アクティブユーザー 700 万人以上にサービスを提供しています。本社はアラブ首長国連邦のドバイにあり、2024 年 12 月にはドバイ金融市場 (DFM) で新規株式公開 (IPO) を完了しました。Delivery Hero SE の子会社として、グローバルな知見を活かしてサービス向上と事業拡大に取り組んでいます。パートナーとライダーのネットワークを通じて、顧客が必要なものを必要なときに届ける、地域全体の日常の利便性を支えています。 本記事では、talabat がハイブリッドなマルチクラウドレイクハウスを構築し、ストリーミングデータの Apache Iceberg コピーを AWS 上に一元的に保持しながら、 Google Cloud Platform (GCP) からガバナンスの効いたニアリアルタイム分析を実現した方法を紹介します。 talabat におけるデータ データは talabat のビジネスの中枢です。顧客が「注文」ボタンを押した瞬間からドアベルが鳴るまで、システムは瞬時にデータドリブンな意思決定を行い、価格設定、配車、ルーティング、注文の不正検知をリアルタイムで最適化しています。長年にわたり、talabat のアプリケーションは 2 つのパブリッククラウドにまたがる環境へと成長しました。トランザクションおよびオペレーション基盤は AWS 上で成熟し、エンジニアリングチームがサービスを構築・運用しています。一方、多数のアナリスト、データサイエンティスト、分析エンジニアリングパイプラインは Google Cloud Platform のウェアハウスである Google BigQuery を標準としています。 どちらへの投資も深く、どちらも価値を生み出しています。戦略的な問いは「どちらのクラウドに統合するか」ではなく「両者の境界をまたいでデータをどうスムーズに流すか」でした。この前提がアーキテクチャ全体を形作っています。課題はクラウド間だけでなくリージョン間にも及びます。AWS サービスは EU リージョンでホストされ、GCP のデータは US リージョンにあります。 次の図は、AWS 上のオペレーションプレーンと GCP 上の分析プレーンの間における talabat のデータフローを示しています。 図 1: AWS 上のオペレーションプレーンと Google Cloud 上の分析プレーン間のデータフロー これまでデータエンジニアリングチームは、2 つのクラウド間のデータ移動をオーケストレーションしており、AWS から GCP へ、EU から US への物理的なデータ移動が必須でした。従来の ETL (抽出、変換、ロード) ツールやフレームワークでの移動は、複数のホップを経てデータの遅延と重複を引き起こしていました。具体的には、 Amazon Relational Database Service (Amazon RDS) から Amazon Simple Storage Service (Amazon S3) EU AWS リージョンへ、Amazon S3 EU から Amazon S3 US リージョンへ、そして最終的に Amazon S3 US から BigQuery US への移動です。 各ホップはコピーであり、コピーのたびにリスクが積み重なりました。障害点の増加、レイテンシーの累積、冗長なコンピューティングとストレージ、型の忠実性、そして最も重要なのはクロスリージョンおよびクロスクラウドのデータ転送料（エグレスコスト）です。 要するに、従来の設計は自ら作り出した問題、すなわち BigQuery がデータを読めるようにデータを移動するという問題の解決に、コスト、レイテンシー、信頼性の代償を払っていました。典型的なデータウェアハウスのボトルネックです。代わりにオープンデータレイクを使えないか？使えます。しかし分析の利用は BigQuery に集中しており、オープンソースのデータレイク層を通じたアクセスが制限されています。そこで再設計は逆の前提から始めました。AWS にコピーを 1 つ保持し、BigQuery にそのままの場所で読み取らせる。本記事の残りで説明するのは、この talabat のレイクハウスです。 課題 オペレーションシステムは、注文ライフサイクルの変更、ベンダー、メニュー、ロジスティクスやライダーのシグナル、決済情報といったビジネスイベントを継続的にストリームとして発行し、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 上の Apache Kafka にパブリッシュしています。これらのイベントは Protocol Buffers でエンコードされ、 Confluent Schema Registry に登録された後方互換スキーマで管理されているため、プロデューサーとコンシューマーが安全に進化できます。 分析側の要件は、簡単に述べられるものの実現は困難です。イベントを正しい型で、生成から数分以内にクエリ可能にし、各チームが既に使っているツールからクエリできるようにすることです。 2 つのクラウドを持つことを技術的負債と見なしがちですが、talabat のようなリアルタイムビジネスにとっては単に地形であり、それぞれの側に本来の強みがあります。 イベント基盤は AWS 上にある。トランザクションおよびストリーミングシステムが Amazon MSK にパブリッシュしている。これらのイベントを最も低レイテンシーかつ低リスクに参照・処理できるのは、同じ AWS リージョン内、イベント基盤のすぐ隣です。 分析基盤は Google Cloud 上にある。何千もの下流のモデルやダッシュボード、そしてそれらを構築する人々が、BigQuery をクエリサーフェスとして前提としています。 どちらか一方に統合するには数年規模のマイグレーションが必要であり、片方のユーザーグループにとっては大幅な機能後退を意味します。単にインジェストと分析の間の継ぎ目を取り除くためだけに。データエンジニアは、その継ぎ目を排除するのではなく設計することに決めました。設計目標は一文にまとまります。データの物理コピーを AWS に 1 つ保持し、両方のクラウドからネイティブに読み取れるようにする。ハイブリッドデータレイクハウスにより、「どちらのクラウドか」という問いはアーキテクチャ上の分岐ではなくアクセスパスの選択肢になります。 最初に試したこと: ホットパス上のクロスクラウド書き込み 最初の試みでは、最終的に採用したフローとは逆のアプローチを取りました。Raw (Bronze とも呼ばれる) レイヤーのデータを AWS から直接 Google Cloud Storage 上の BigQuery マネージド Iceberg テーブルに書き込みました。理論上、最大の参照者基盤に最も近い場所にデータが配置されます。しかし実際には、常時稼働のストリーミングパスでクラウドをまたいで書き込むことで、長期的に許容できない問題が生じました。 インジェストパスにおけるクロスクラウド依存。マイクロバッチのたびに、リモートクラウドの書き込み API の可用性とレイテンシーに結合していました。 ストリーミング書き込み API の障害がインジェスト障害として顕在化。リモート書き込みが脆弱なリンクとなり、読み取り側の問題が書き込み側の障害に転化しました。障害を吸収する場所としては最悪です。 プレビュー段階の機能が物理レイアウトを制約。特定のパーティショニング動作や機能が一般提供されておらず、コストとパフォーマンスのためのデータ編成が制限されていました。 教訓は明確でした。書き込みパスはシフトレフトすべきです。書き込みパスは短く、ローカルで、シンプルであるべきです。クロスクラウドの課題は読み取りパスに属し、読み取り専用、キャッシュ可能、リトライ可能であり、インジェストに影響しません。この再構成が、現在稼働しているアーキテクチャに直結しました。 BigQuery が AWS 上のデータを読み取る方法の選択 フローを反転させ (Raw データは AWS 上、読み取りは Google Cloud から)、BigQuery が物理的に AWS 上にあるテーブルを読み取る 3 つの方法を評価しました。4 つの基準に照らして評価しました。 データ移動なし。 オープンテーブルフォーマット。 ガバナンス可能な信頼モデル。 最小限の運用面。 アプローチ 評価 Google Cloud Storage へのクロスクラウド書き込み Bronze を Google Cloud Storage 上の BigQuery マネージド Iceberg に書き込み続ける方法。前述の理由で却下しました。インジェストのホットパスにクロスクラウド依存とクロスリージョンレイテンシーが生じるためです。 BigQuery Omni BigQuery Omni のマネージドなクロスクラウドコンピュートを通じて AWS 上のデータをクエリする方法。読み取り専用の Bronze レイヤーに対して必要以上のマネージド面と制約が生じ、カタログと信頼モデルを直接制御したかったため不採用としました。 Lakehouse フェデレーテッド Apache Iceberg REST カタログ (IAM 認証) BigQuery が Amazon S3 Tables (マネージド Apache Iceberg テーブルを提供する Amazon S3 の機能) 内のデータを、AWS Glue Data Catalog のメタデータを同期するフェデレーテッドカタログを通じて読み取る方法。アクセスはクロスクラウド IAM 信頼で認証されます。4 つの基準をすべて満たしたため、この方法を選択しました。 決め手となったのは、Raw データが AWS から出ないこと、フォーマットがオープンな Apache Iceberg であること ( Amazon Athena 、Spark、Iceberg 互換エンジンが同じテーブルを読める)、そしてクロスクラウドの関係が定期的なコピージョブではなくアイデンティティと信頼として表現されることです。 Amazon S3 Tables を選んだ理由 AWS 上に単一の Iceberg コピーを保持するアーキテクチャが決まった後、スケーラブルな Iceberg に特化したストレージレイヤーが必要でした。Amazon S3 Tables は運用面を追加せずに要件を満たしました。テーブルメンテナンス (コンパクション、スナップショット期限切れ、未参照ファイル削除) はサービスマネージドポリシーとして自動実行され、テーブル数に比例して増える外部オーケストレーションジョブが不要です。同様に重要な点として、各テーブルが Amazon Resource Name (ARN) でアドレス指定可能なリソースです。IAM ポリシーで個別テーブルへのアクセスを許可・拒否でき、他の AWS リソースに適用するのと同じ最小権限モデルが使えます。また、 AWS CloudTrail がすべてのアクセス判定を記録します。信頼境界が IAM のみで表現されるクロスクラウド設計では、テーブルがファーストクラスの IAM リソースであることは利便性ではなく前提条件です。S3 Tables により、マネージド Iceberg ハウスキーピングときめ細かく監査可能なアクセス制御が単一の構成で実現し、エンジニアリングチームはストレージ層の実装ではなくストリーミングロジックに集中できました。 ソリューション概要 システムは、オープンテーブルフォーマットで接続される 2 つの部分で構成されています。 AWS 上の短くローカルな書き込みパス。 BigQuery がデータを参照できるようにする読み取り専用のクロスクラウドハンドシェイク。 唯一の信頼できるソース (Single Source of Truth) は、Amazon S3 Tables 内の Apache Iceberg データです。すべてのコンシューマーがこの 1 つの物理コピーを読み取ります。 次の図は、イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャを示しています。 図 2: イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャ 書き込みパス: 短く、ローカルで、信頼性が高い Kafka トピックごとに 1 つの Amazon EMR Serverless Spark Structured Streaming ジョブ (プリベイクされた Docker イメージ、ARM64/Graviton 上の emr-7.13.0 ) を、Amazon MSK と同じ AWS リージョン (eu-west-2) で実行しています。コンピュートをイベント基盤と同じ場所に配置することで、マイクロバッチあたりのデータ転送量を最小化し、コストとレイテンシーを削減しています。各ジョブは Spark の foreachBatch オペレーションをトリガー間隔約 1〜5 分、at-least-once デリバリーで実行します。各マイクロバッチは 5 つのステップを実行します。 Kafka から コンシューム する。 登録済みスキーマを使用して Protocol Buffers を デコード する。 ターゲットの Iceberg スキーマに 変換 する。 Amazon S3 Tables 内の Iceberg テーブルに 追記 する。 オフセットを コミット する。 このサイクルが中断なく繰り返されます。 このパスは AWS のみで完結します。クロスクラウド依存はなく、意図的なクロスリージョンホップが 1 つだけあります。コンピュートは欧州 (ロンドン) リージョン (eu-west-2)、ストレージは米国東部 (バージニア北部) リージョン (us-east-1) です。標準の AWS リージョン間データ転送コストが発生しますが、これは BigQuery からのクロスクラウド読み取りが同一リージョン内に収まるようにするための意図的な選択です。 不正レコードはストリームをブロックしません。専用のデッドレターキュー (DLQ) テーブル ( <table>_dlq ) が別の S3 Tables バケットに配置され、生のペイロード ( raw_value_b64 ) と skip_reason が保存されます。暗黙のドロップは発生しません。DLQ テーブルは Lakehouse を通じて AWS Glue Data Catalog に登録されているため、エンジニアは Amazon Athena または BigQuery から障害を検査できます。 この時点から、Amazon S3 Tables が信頼できるソースとなります。 核心: クロスクラウドハンドシェイク ここが設計の中核です。BigQuery は Lakehouse フェデレーテッド Apache Iceberg REST カタログ を通じて S3 Tables の Iceberg データを読み取ります。Google Cloud 側の読み取り専用カタログが AWS 上のテーブルを参照する仕組みです。3 つのメカニズムで実現しています。 オープンなカタログ契約 (Iceberg REST) 。 Amazon S3 Tables は Apache Iceberg REST カタログ インターフェースを公開し、 Google Lakehouse も同じ標準を使用します。双方が Iceberg のオンディスクフォーマットと REST カタログプロトコルに合意しているため、変換レイヤーもデータコピーも不要です。BigQuery は Athena や Spark が読み取るのと同一の Iceberg データファイルを読み取ります。 Google Cloud 側では単一の Lakehouse フェデレーテッドカタログ です。アナリストにはテーブルが talabat-data.s3tables-glue.catalog.orders として表示されます。 クロスクラウドのアイデンティティと信頼 (IAM と OIDC) 。 Lakehouse カタログは、Google マネージドのサービス ID (Lakehouse REST カタログサービスアカウント) として AWS に認証します。 AWS Identity and Access Management (IAM) ロールが accounts.google.com との OpenID Connect (OIDC) フェデレーションを通じてこのサービス ID を信頼し、 sts:AssumeRoleWithWebIdentity でサービスアカウントの数値 ID をロールの信頼ポリシーにピン留めしています。S3 Tables Iceberg エンドポイントへのリクエストは SigV4 署名されます。他の AWS SDK が使用するのと同じ AWS リクエスト署名スキームで、S3 Tables サービスにスコープされています。つまり、ハンドシェイクはプロプライエタリなコネクターではなく、信頼された外部 ID が実行する標準の AWS リクエスト署名です。 信頼は AWS 側で Infrastructure as Code (IaC) としてコード化されており、最小権限が付与され、いつでも取り消し可能です。次の図は認証シーケンスを示しています。 図 3: Lakehouse カタログと AWS IAM 間のクロスクラウド認証シーケンス この信頼関係のステップバイステップのウォークスルー (IAM ロールの作成、トークンのオーディエンスとサブジェクトの検証、信頼ポリシーへの Lakehouse サービスアカウント ID のピン留め) については、 Create and manage AWS Glue federated datasets および Set up cross-cloud Lakehouse for AWS Glue を参照してください。 メタデータ同期 (約 5 分間隔のリフレッシュ) 。 フェデレーテッドカタログは、S3 Tables のフロントとなる AWS Glue Data Catalog からテーブルメタデータを定期的に同期します。新しく作成されたテーブルや新データは、短いリフレッシュサイクル (約 300 秒) で BigQuery から参照可能になります。読み取りはライブの Iceberg データに対して行われ、同期されるのはカタログポインターのみです。 結果として、AWS 上で一度書き込まれたテーブルは BigQuery で通常のカタログオブジェクトとして表示され、標準 SQL でクエリできます。一方で、バイトは AWS から出ず、フォーマットはオープンなままです。 Infrastructure as Code: クロスクラウド信頼面 以下のセクションでは、アーキテクチャ図に示した認証ハンドシェイクを説明します。Lakehouse カタログサービスアカウントが Google OIDC JSON Web Token (JWT) を提示し、AWS が IAM OIDC プロバイダーを通じて検証し、読み取り専用の S3 Tables アクセスにスコープされた短期間の認証情報を返します。 Google を信頼された ID プロバイダーとして登録する。Lakehouse カタログのサービスアカウントにスコープされます。 resource "aws_iam_openid_connect_provider" "google" { url = "https://accounts.google.com" client_id_list = [var.lakehouse_sa_audience] #Lakehouse REST-catalog serviceaccount } 信頼を特定の ID に限定する。ここがセキュリティの核心です。ロールは、サブジェクトがサービスアカウントに一致する Google 署名トークンを通じてのみ引き受け可能です。sub クレームの条件が他のすべてのプリンシパルを排除します。 data "aws_iam_policy_document" "trust" { statement { actions = ["sts:AssumeRoleWithWebIdentity"] principals { type = "Federated" identifiers = [aws_iam_openid_connect_provider.google.arn] } condition { test = "StringEquals" variable = "accounts.google.com:sub" values = [var.lakehouse_sa_subject_id] # nobody else can assume the role } } } resource "aws_iam_role" "lakehouse_read" { name = "bq-lakehouse-read" assume_role_policy = data.aws_iam_policy_document.trust.json max_session_duration = 43200 # 12-hour sessions, then re-issued } 読み取り専用の最小権限を付与する。引き受けたロールには、AWS Glue を通じたカタログメタデータの読み取りと S3 Tables を通じた Iceberg データへのアクセスに必要な権限のみが含まれ、IAM ポリシーで保護され、書き込み可能なものはありません。 statement { actions = [ "glue:Get*", "s3tables:GetTable", "s3tables:GetTableData", "s3tables:ListTables", "s3tables:ListTableBuckets", "s3tables:GetTableMetadataLocation", "s3tables:ListNamespaces", "s3tables:GetNamespace","s3tables:GetTableBucket" ] resources = [var.s3tables_bucket_arn, "${var.s3tables_bucket_arn}/*"] } Google 側のカタログをこのロールに紐付ける。Lakehouse フェデレーテッドカタログ自体はパイプラインとは別に事前作成 (一回限りの gcloud コマンド) され、前述のロールに紐づけられるため、すべての読み取りが信頼された ID を提示します。AWS キーが Google Cloud に存在することはありません。 gcloud iceberg catalogs create s3tables-glue \ --federated-catalog-type=GLUE --glue-aws-region=us-east-1 \ --glue-aws-role-arn=arn:aws:iam::<account>:role/bq-lakehouse-read これら 4 つのステップがハンドシェイクの全体像です。信頼された発行者、サービスアカウントのみが引き受けられるロール、最小権限の読み取り許可、そしてそのロールにバインドされたカタログです。 運用上の教訓: メタデータをファーストクラスの関心事として扱う オープンなフェデレーテッドカタログをクラウド間で運用する中で、テーブルメタデータをファーストクラスの運用上の関心事として扱うことの重要性を学びました。具体的には以下を意味します。 スナップショット保持 : Iceberg のスナップショット保持期間を短く設定し、テーブルごとのメタデータをコンパクトに保ち、確実に同期できるようにする。 コンパクション : S3 Tables 組み込みのメンテナンス設定を通じて、テーブルメンテナンス (コンパクションとスナップショット期限切れ) を統一的なサービスマネージドポリシーとして標準化する。 スキーマ進化 : Protobuf スキーマが進化 (後方互換の追加) すると、Spark ジョブが S3 Tables 内の Iceberg スキーマにカラムを追加・削除する。フェデレーテッドカタログは次の同期サイクルで変更を検出し、BigQuery は手動介入なしに変更を反映する。 設定方法さえ分かってしまえば小さく明確な設定項目にすぎませんが、カタログが正常に動作するか、時間とともにずれていくかの分かれ目です。 データ参照はエンジンの選択であり、コピーの選択ではない ソースがライブになった後、同一の Iceberg テーブルに 1 つの物理データセットから 3 つの方法でアクセスできます。 BigQuery ユーザー は標準 SQL でクエリし、Google Cloud ウェアハウスの他のデータと結合できる。 インフラエンジニア はアドホック確認や継続的インテグレーション (CI) バリデーションのために Amazon Athena で同じクエリを実行できる。 データサイエンティスト は BigQuery や Athena を経由せず、Spark で直接テーブルを読み取れる。 夜間エクスポートを待つ必要はなく、3 つの異なるコピーを照合する必要もありません。コピーは 1 つだけです。 パフォーマンスとコストへの影響 定性的なメリットは既に明らかです。 ニアリアルタイム分析のための数分レベルの鮮度を持つ Raw データ。従来アーキテクチャのレイテンシーはデータ量の問題ではなく設計上の制約でした。インジェスト自体は 5 分間隔で実行されていましたが、下流の 1 時間バッチジョブがエンドツーエンドの鮮度を 60〜90 分に制限していました。カタログフェデレーションにより、同じデータが生成から数分以内にクエリ可能になります。イベントの 95% が 5 分以内、レイテンシーに敏感なミッションクリティカルなワークロードでは 100% をカバーするようにパイプラインを調整する選択肢もあります。 S3 Tables に 1 つのストレージコピー、3 つのコンピュートエンジン。BigQuery、Athena、Spark またはその他の Iceberg 互換エンジンが Amazon S3 Tables 内の単一の物理 Iceberg データセットを読み取り、ストレージの重複とコピー同期に伴う照合コストを回避します。 ホットパスでのクロスクラウドエグレスなし。インジェストは AWS 内で完結します。唯一のクロスクラウドトラフィックは読み取り時のメタデータ同期とクエリ読み取りであり、継続的な書き込みストリームではありません。月次の AWS および Google Cloud データ転送料金、オーケストレーションオーバーヘッド、多層 ETL ワークフローコスト、ストレージバックアップ料金の内部比較に基づき、talabat は同等のデータボリュームでデータ移動コストを約 40% 削減しました。比較は継続的レプリケーションパイプラインの削除前後の 2 か月間にわたり、月間数百テラバイトの反復的なクロスリージョンおよびクロスクラウドデータ転送を排除しました。 オープンテーブルフォーマット、ロックインなし。Raw の Bronze データレイヤーが Amazon S3 Tables 内の Apache Iceberg であるため、データは特定のクエリエンジンやクラウドに囲い込まれません。新しいコンシューマーはエクスポートを要求する代わりに、Iceberg 対応のインターフェースで接続するだけです。 ガバナンス可能なクロスクラウドアクセス。クロスクラウドの境界は、常時稼働のデータパイプラインではなく、IAM 信頼関係 (最小権限、監査可能、取り消し可能) で保護されています。BigQuery 内のエンドユーザーアクセス制御は、GCP のネイティブなロールベースアクセス制御 (RBAC) とフェデレーテッドカタログのきめ細かなアクセス制御で別途管理されます。 今後の拡張 今後は、残りの高価値イベントストリームとバッチストアをハイブリッドな単一設定パターンに取り込み、ソースカバレッジを拡大する予定です。エンドツーエンドの鮮度目標とその周辺のオブザーバビリティ (バッチレベルのメトリクス、デッドレター監視、カタログ同期の正常性) を形式化しています。テーブル数が増加してもクロスクラウドカタログが高速かつ信頼性の高い状態を維持できるよう、スナップショット保持とコンパクションの調整を続けます。より広い観点では、Bronze レイヤーを超えた新しいデータセットについても「一度書き込み、任意のエンジンで読み取り」をデフォルトにし、クラウド間の接続基盤としてオープンテーブルフォーマットをさらに活用していく方針です。 まとめ 2 つのクラウドを使うことは、マイグレーションすべき問題として捉えられがちですが、talabat にとっては単に地形です。イベント基盤は AWS が中心であり、分析コミュニティは BigQuery で活動しています。Apache Iceberg を搭載した Amazon S3 Tables を AWS 上の唯一の信頼できるソースとし、クロスクラウド IAM 信頼で保護された Lakehouse フェデレーテッド Iceberg REST カタログを通じて BigQuery に読み取り専用で参照させることで、2 つのクラウドという制約を数分以内にエンジンが読み取れる単一のガバナンスされたデータセットに変えました。書き込みパスは短く、ローカルで、信頼性が高いままです。クロスクラウドの課題は、あるべき場所、すなわち読み取りパスに存在し、データ移動ではなくオープン標準とアイデンティティで表現されています。 これがハンドシェイクです。AWS 上にデータのコピーを 1 つ、オープンなカタログ契約、そしてクラウドの境界を越えてデータを読み取るための署名された、信頼された、取り消し可能なアイデンティティです。 本記事では BigQuery から AWS 上のデータを読み取ることに焦点を当てました。他のシステムから AWS Glue Data Catalog へのカタログフェデレーションを含む、より広範なマルチクラウド Lakehouse パターンについては、 Multi-cloud Lakehouse architecture on AWS for agentic AI を参照してください。 著者について Harish Ramesh Harish は、talabat の Staff Data Engineer です。小売、ヘルスケア、メディア、物流、ホスピタリティ、FMCG など幅広い業種で大規模データプロダクトを構築してきた経験を持ち、talabat でデータプラットフォームの構築と管理に注力しています。 Raghunandana Krishna Murthy Sanur Raghu は、talabat における Data Engineering and Machine Learning Platform の Senior Manager です。データおよび機械学習プラットフォームのアプリケーションとインフラストラクチャを開発するチームのリードを専門としています。 Lakshmi Nair Lakshmi は、AWS の Principal Analytics Specialist Solutions Architect です。業界横断で高度な分析システムの設計を専門とし、クラウドベースのデータプラットフォームの構築、リアルタイムストリーミング、ビッグデータ処理、データガバナンスの確立に注力しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 6 月 25 日から 26 日に幕張メッセで開催された AWS Summit Japan 2026 の開催報告です。AWS for Industries Zone に出展した株式会社 SUMCO のブース展示 「Amazon Redshift × 生成 AI で挑む 半導体ウェーハメーカーの DX」 の内容を、SUMCO と AWS が共同で振り返ります。 図 1: AWS Summit Japan 2026 の SUMCO ブース。実物の 300mm シリコンウェーハとともに、生成 AI を活用したデータ分析の取り組みと AWS 基盤のアーキテクチャを展示した。 SUMCO と半導体を支えるシリコンウェーハ SUMCO は半導体デバイスの基板材料となるシリコンウェーハの製造・販売を手がける企業です。社名は「Silicon United Manufacturing Corporation」に由来します。スマートフォンや自動車、データセンターに至るまで、あらゆる半導体デバイスの起点となる素材がシリコンウェーハであり、その品質は半導体の進化を根底から支えています。 シリコンウェーハは珪石から多結晶シリコンを精製し、単結晶を引き上げてインゴットとし、スライシング・ラッピング・ポリッシング・洗浄といった多数の工程を経て、鏡面ウェーハとして出荷されます。この一連の製造プロセスの各工程で、製造装置・検査装置から膨大なデータが生成されます。 図 2: SUMCO のデータ活用。各工程の検査情報・経路情報・製造装置の稼働情報を Amazon Redshift に集約し、データの意味を解釈してシリコンウェーハの状態を推定する。 背景と課題：ビッグデータを“価値”に変えるために SUMCO が目指すのは、単一工程内の改善にとどまらず、製造装置・検査装置から生じる膨大なデータ、つまりビッグデータを収集・解析することで複数工程をまたいだ改善を実現することです。前工程が後工程に与える影響を把握し、工程間の装置の組み合わせまで見据えて最適化することで、より高精度・高品質なシリコンウェーハの製造につなげます。 一方でビッグデータを実際の価値へと変えていくには乗り越えるべきテーマがありました。分析を担う人材と製造現場とでは、得意とする領域が異なります。データ分析の専門人材であるデータサイエンティストは分析手法に、製造現場は工程や品質の知見に、それぞれ強みを持ちます。この双方の強みを結びつけ、限られた専門人材だけに頼るのではなく、現場を含む組織全体でデータを活用できる状態をつくることが取り組みの出発点です。 取り組み：3 つの要素で組織のデータ活用を底上げする AWS Summit での展示は、SUMCO のデータ活用を次の 3 つの要素でご紹介しました。セキュアな基盤という土台と、その上で動く RedPulse・SynchroFabAI という 2 つのデータ活用の取り組みです。RedPulse と SynchroFabAI はいずれも SUMCO が開発した仕組みの名称です。 A. 基盤 セキュアな AWS 環境。製造データをクラウドで安全に扱うための土台 B. RedPulse 大量データの加工・比較を支えるデータ処理の仕組み C. SynchroFabAI 生成 AI で自然言語によるデータ解析を行う取り組み 図 3: データ分析基盤の全体像。SynchroFabAI（生成 AI アプリ）と RedPulse（データパイプライン＋データ処理）が、Amazon Redshift を中核とする基盤とともに構成される。 A. 基盤：製造データを安全にクラウドで活用する 製造データをクラウドで安全に活用するための土台となるのが、AWS 上に構築されたセキュアな基盤です。半導体業界はセキュリティ要件が厳しく、製造データをクラウドで扱うこと自体が挑戦的な取り組みであるため、その土台には堅牢なガバナンスが不可欠でした。 SUMCO の AWS 基盤は工場と AWS を安全につなぎ、用途ごとにアカウントを分離した構成をとっています（図 4）。この基盤はネットワーク統制と権限統制の 2 つの観点で運用されています。 ネットワーク統制（閉域網の構築） AWS 環境からインターネットへの直接通信を禁止 AWS Direct Connect を用いたオンプレミスと AWS 間の専用ネットワーク接続 権限統制 AWS Identity and Access Management (IAM) による必要最小限の権限付与 AWS Organizations のサービスコントロールポリシー (SCP) による組織全体への予防的統制 AWS 環境に対して社内 IP アドレス以外からのアクセスを制限 図 4: AWS 基盤の全体構成。Organization・User・DWH のアカウントを分離し、AWS Transit Gateway で接続。工場からは AWS Direct Connect 経由で取り込み、DWH アカウントの Amazon S3・Amazon Redshift にデータを集約する。 運用から、社内向けシステムの企画・ソリューション提供へ SUMCO 社内の AWS チームの役割は基盤の運用にとどまりません。IAM の最小権限設計や AWS サービスの払い出し、社内向けの AWS サポート・教育を担いながら、さらに AWS の技術を使った社内向けシステムの企画から、現場へのソリューション提供までへと取り組みを広げています。この社内 AWS チームの活動が、次に紹介する 2 つのデータ活用の取り組みを支えています。 図 5: SUMCO 社内 AWS チームの取り組み。基盤構築・運用・教育を土台に、社内向けシステムの企画とソリューション提供へと役割を広げている。 B. RedPulse：データ加工の知見を組織で共有する RedPulse は大量データの加工・比較を支えるデータパイプラインとデータ処理の仕組みです。製造装置が生成する製造中の時系列データを抽出し、複数の装置や時間帯といった条件で比較できます。これまで熟練者の経験に根ざしていたデータ加工の手順を仕組み化し、誰もが同じ手順で大量データを扱えるようにすることで、分析の入口となる作業を組織の共有資産にします。 図 6: RedPulse。製造中の時系列データを抽出し、複数の装置・時間の条件で比較できる。 実装面では、工場から取り込んだデータを Amazon Simple Storage Service (Amazon S3) に CSV / Parquet 形式で格納します。その後 AWS Lambda や Amazon Elastic Container Service (Amazon ECS) でデータパイプラインを通じた処理を実行し、 Amazon Redshift を中核とするデータ分析基盤に集約しています。 図 7: RedPulse のアーキテクチャ。工場のデータを Amazon S3 に格納し、AWS Lambda・Amazon ECS でデータパイプラインとデータ処理を行い、Amazon Redshift に集約する。 RedPulse で取得・整形した時系列データは、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析へとつながります。RedPulse は、こうしたデータ分析業務を支える役割を担っています。 C. SynchroFabAI：生成 AI で意味づけ・分析の知見を組織で共有する SynchroFabAI は生成 AI を活用して自然言語でビッグデータを解析する取り組みで、本記事執筆時点では PoC 段階です。データの意味を説明し、分析手法を提案・実行することで、分析の専門人材でなくても自然言語での対話だけでデータ分析を進められることを目指しています。 図 8: SynchroFabAI。自然言語での問いかけに対し、AI がデータの意味を説明し、分析手法を提案・実行する。 実装面では、オンプレミス環境に配置した AI エージェントの Cline が Amazon ECS 上に構築した Model Context Protocol (MCP) サーバーを介して、AWS 上の Amazon Redshift のデータソースを参照します。Cline の推論においては、 Amazon Bedrock で大規模言語モデルを利用します。Cline の振る舞いは Rules や Skills、および分析手法を記述した参照ファイルによって制御しています。 図 9: SynchroFabAI の実装。オンプレミスの Cline から、MCP を介して AWS 上の Amazon Bedrock・Amazon Redshift を利用する。 SynchroFabAI では、AI に持たせる知識の設計、すなわち製造現場の知見のうち何を、どのような形式で AI に渡すかの見極めを工夫しています。大量データへのクエリ生成を助ける専門用語集や、データと製品状態を紐づけるためのカタログ情報を AI に与え、「異常状態の推測」や「因果関係の推測」といった役割を担わせます。本 PoC では、データ・意味づけ・分析での解釈・AI の振る舞いという各層について、AI にどこまでの役割を担わせられるか、そしてデータと製品状態の紐づけや分析手法の選択・結果解釈の妥当性を検証しています（図 10）。こうして確立した意味づけ・分析の知見を仕組みに蓄積し、組織全体で共有・再利用していくことを目指しています。 図 10: SynchroFabAI へのデータ分析フローの実装。データ・意味づけ・分析での解釈・AI の振る舞いの各層について、AI に担わせる役割と、PoC で検証している内容を対応づけている。 “RedPulse では、Amazon Redshift の処理性能を引き出すことを念頭に SQL を作成・チューニングすることで、これまで時間を要していた大量データの集計が現実的な時間で回るようになり、Amazon Redshift のパワーを強く実感しました。SynchroFabAI では、生成 AI がデータの意味づけまで踏み込んで担う点が新鮮であり、集計や可視化の先にある「解釈」の領域にまで仕組みを広げられることは、現場のデータ活用の裾野を大きく広げると感じています。加えて、SynchroFabAI の設計にあたっては、専門用語集やカタログ情報として生成 AI に渡す知識の設計、そして意味づけ・分析手法の提案までを AI に担わせ、結果の妥当性の確認は人が担うという役割分担を、データサイエンティストと議論を重ねながら形にしていきました。実装側の視点だけでは辿り着けない分析の観点や知識に触れられたこの設計の過程こそ、本取り組みならではの面白さだったと感じています。” ― 株式会社 SUMCO AI推進本部 ICT推進部 荒木 亮 氏 今後の展望：データ活用を一部の専門人材から組織全体の力へ SUMCO の取り組みは単なる分析ツールの導入にとどまりません。多品種生産という SUMCO の事業価値を支えるには、品種・工程に合わせた分析やアプリケーションが必要になります。データ加工の知見である RedPulse と、意味づけ・分析の知見である SynchroFabAI を組織の共有資産としていくことで、限られた専門人材への依存を減らし、現場を含む組織全体のデータ活用の底上げを図ります。 セキュアな AWS 環境という土台の上に、データ基盤の確立、そして生成 AI の活用へと、SUMCO は着実に歩みを進めてきました。この積み重ねの先に、現場を含む組織全体でデータを活かせる状態の実現を見据えています。 “データは当社の競争力の源泉であり、それを一部の専門人材だけでなく組織全体で活用できるようにすることは、多品種生産を強みとする当社にとって不可欠な変革です。今回の取り組みは、その第一歩として大きな手応えを感じています。セキュアな基盤の上で現場と分析をつなぎ、変化に素早く対応できる組織へ。AWS とともに、この歩みをさらに加速させていきます。” ― 株式会社 SUMCO AI推進本部 ICT推進部 部長 武富 太志 氏 おわりに AWS Summit Japan 2026 の SUMCO ブースでは、実物のシリコンウェーハとともにデータ活用の取り組みを紹介しました。厳しいセキュリティ要件のもとで製造データをクラウドと生成 AI で活用する SUMCO の挑戦は、同じ課題に向き合う製造業の皆さまにとって、参考となる点があるのではないかと考えています。 SUMCO と AWS は、これからもデータ活用 DX の歩みをともに進めてまいります。本記事が、製造業におけるデータと生成 AI の活用を検討されている皆さまの一助となれば幸いです。 図 11: AWS Summit Japan 2026 の SUMCO ブースにて。展示を支えた SUMCO の皆さまと、AWS メンバー。 執筆者について 武富 太志 株式会社SUMCO AI推進本部 ICT推進部 / 部長 「データを、現場の力に変える」をテーマに、工場で生まれる膨大なデータをAIやクラウドで活用し、ものづくりの現場をスマートにする取り組みを率いる。難しいIT技術を社員が使いこなせるよう教育にも力を注ぎ、「一部の専門家だけでなく、全員でデータを使いこなせる会社」を目指して日々奮闘中。 荒木 亮 株式会社SUMCO AI推進本部 ICT推進部 半導体業界において、製造装置の制御技術と工場のデータ基盤、双方の実務領域にエンジニアとして関わってきた。SUMCOでは製造現場の知見をシステムとして具現化することで、ITを軸とした自動化とデータ活用に取り組んでいる。社内ではいつの間にか「万屋（よろずや）」と呼ばれるようになり、静かに受け入れつつも、熱量に限ってはその肩書きが窮屈らしい。 大森 敬太 株式会社SUMCO ウェーハ技術部 プロセス企画課 / データサイエンティスト 2021年にSUMCOへ入社後、ICT部門に配属。SEとしてIT知識を習得しながら、製造現場の見える化推進に取り組む。その後、システム開発やデータ分析業務など幅広いICT関連業務を経験。2023年よりデータサイエンス課に配属。現在、データサイエンス分野の博士後期課程に社会人博士として在学中。製造現場とデータ分析をつなぐ役割を担い、組織全体のデータ活用推進に取り組んでいる。 酒井 賢 アマゾン ウェブ サービス ジャパン合同会社 ハイテク＆ヘルスケア・ライフサイエンス部 / シニアソリューションアーキテクト IT 業界で 20 年以上の実務経験を持つソリューションアーキテクト。2020 年の AWS 入社後、製造業を中心にさまざまな業種の企業を支援し、現在は半導体業界を専門としている。企業がクラウドソリューションを計画・実装し、AWS 上で安全かつ高性能で柔軟な費用対効果の高い環境を構築することへの支援に注力している。