2026年6月4日、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の 第4期における採択事業者 のキックオフが行われました。今回 AWS は NVIDIA B200 Tensor Core GPU を搭載する Amazon EC2 P6-B200 インスタンス ( p6-b200.48xlarge )、NVIDIA H200 Tensor Core GPU を搭載する Amazon EC2 P5en インスタンス ( p5en.48xlarge )、NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge , p5.4xlarge ) 等の学習・推論に必要な仮想サーバーを提供します。 AWS は、 GENIAC バーチャルチーム を中心に、以下の支援を提供します: 計算資源 : Amazon EC2 P6-B200, P5en, P5 インスタンスの提供 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster  を活用した構築・管理の支援 開発者コミュニティ支援 : 海外モデルプロバイダーの開発メンバーとの交流イベントによる最先端の開発動向調査や海外視察、国内の機械学習エンジニア同士の交流による知見共有をはじめとした Meetup の実施 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの Amazon Bedrock Marketplace 、 AWS Marketplace の活用による go-to-market (GTM) 支援、利用企業との AWS 主催イベントを通じたマッチング機会の提供 これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみをアルファベット・五十音順で掲載): 株式会社ABEJA Direava株式会社 株式会社DubGuild 株式会社Preferred Networks 株式会社メルカリ ONESTRUCTION株式会社 Sansan株式会社 株式会社Spectee 採択事業者からコメントを頂きました 株式会社ABEJAは、GENIAC第一期から継続して、LLMの社会実装への貢献を目的に、LLMおよび周辺技術の社会実装に取り組んでまいりました。 第四期では間違いが許されないミッションクリティカル事業への利活用を目的に、LLMおよび領域特化型のAIエージェントの研究開発に取り組みます。その上で、株式会社IDOM様と連携し、自動車整備領域における利活用を実証します。 AWS様の大規模な計算資源および技術支援を活用することで、過去事例など複数の情報ソースから必要な情報を自律的に検索・参照するToolUse能力、多様なデータを用いて論理的・段階的に解答を導き出す多段推論能力の強化を進めてまいります。 このたび新たに開発する技術は、実店舗で「Human in the Loop」の元、運用することを予定しています。精度を継続的に向上させながら、自動車整備領域における人手不足、属人化、技術の高度化による生産性低下といった課題の解決に貢献してまいります。 — 株式会社ABEJA 執行役員 木下 正文 氏   弊社はGENIACサイクル4において、外科手術における「未来予測AI基盤モデル」の開発に注力します。 サイクル3に引き続き、Amazon EC2 P5インスタンスや、大規模分散学習を支える最先端のインフラを継続して活用できることに深く感謝しております。AWS様の強力なサポートのもと、最先端AIの力で一歩先の医療現場を支えるソリューションの開発を加速させてまいります。 — Direava株式会社 CTO 斎藤 洸輔 氏   DubGuildは、大規模な音声インタラクションモデルの研究開発に取り組んでいます。 GENIACプロジェクトでは、B200 GPUを搭載したAWSのP6-B200インスタンスを活用し、30B級の大規模音声言語モデルの開発を進めてまいります。 本取り組みにあたり、Generative AI Innovation Centerをはじめ、AWSの皆様より多大なるご支援を賜っておりますこと、心より感謝申し上げます。 — 株式会社DubGuild CEO 大嵜匡俊 氏   株式会社メルカリは、GENIACプロジェクト4期目において、”Generative Retrieval技術を用いた二次流通市場向け高精度検索・推薦基盤モデルの開発”に取り組みます。Amazon EC2 P5インスタンスを活用し、大規模な学習を行います。AI自身が商品を丸暗記して探す次世代検索モデルによって、世界中の誰もが欲しい物にすぐに出会える最高の買い物体験を目指します。 — 株式会社メルカリ 研究開発組織R4D 所長 小堀 訓成 氏   AWS様には第3期に続き、第4期も引き続き支援いただきありがとうございます。 ONESTRUCTIONは本事業において、建設×AIをテーマに、建設ドメイン知識のAIエージェントへの統合と、それによる3次元設計（BIM）のAIによる自律化を目指します。 AWSの圧倒的なレジリエンスと信頼性に加え、とりわけGenAI Innovation Centerのチームによる世界水準の知見によるバックアップにより、建設業界のAI-Powerdを実現させます、ご期待ください。 — ONESTRUCTION株式会社 AI戦略ユニット Manager 日高 洸陽 氏   防災・危機管理分野からは初の採択となる今回、Specteeは独自の災害データとAI技術を基盤に、危機事象をリアルタイムに抽出する災害検知LLMと、ユーザー固有のBCP等を踏まえて行動を示唆する危機管理AIエージェントの開発に取り組みます。学習には Amazon EC2 P5 インスタンス、データ管理には Amazon S3 を活用し、AWS様のバーチャルチームによる技術支援のもと、人命に関わる領域に求められる高い精度と安定性の実現を目指します。日本発の次世代防災・危機管理基盤として、グローバル展開を見据えて開発を加速してまいります。 — 株式会社Spectee 取締役CRDO 加藤 奈々 氏 まとめ AWS では日本のお客様に対し、2023年の AWS LLM 開発支援プログラム にはじまり、グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。GENIAC においても 第2期 、 第3期 に続き、第4期でも引き続き採択事業者の皆様と伴走し、これまで蓄積してきた知見を活かして日本の生成 AI 基盤モデル開発力の向上に貢献できれば幸いです。

ファインディの森（ @jiskanulo ）と西村（ @sontixyou ）です。 2026年6月11日に開催されたAnthropic主催のイベント「Code w/ Claude: Extended | Tokyo」に終日参加してきました。 claude.com 本記事はその参加レポートです。私たちがセッションを聴いてどう感じたか、セッションの内容をどう活かすかの感想も書いていきます。 Workshopで気になったセッション How we Claude Code Ship your first Managed Agent ドメインエキスパートがソフトウェアを作る What happens when domain experts can finally build The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark まとめ ファインディでは一緒に働く仲間を募集しています Workshopで気になったセッション 西村は主にAnthropicメンバーによるWorkshopへ参加しました。Anthropicが取り入れている設定や仕組みを弊社のプロダクト開発フローに適用できるかを意識して聴きました。 How we Claude Code claude.com Anthropicメンバーが実際に使っているClaude Codeのセットアップ方法を紹介するものです。 今回のイベントでのワークショップで説明された題材は次のリポジトリで公開されています。 github.com このセッションで最も印象に残ったのは「徹底インタビュー」と「HTML先行プロトタイプ」の2つです。 「徹底インタビュー」では、Claude Codeにインタビュアー役を担わせて要件を引き出します。 インタビューでは、つぎのインタビュープロンプトをClaude Codeに渡して、HTMLのプロトタイプを作るための要件を引き出す設計になっていました。 I want to build a bill-splitting app, can you help me brainstorm with me on who the audience is, and then interview me in-depth using the AskUserQuestion tool about what to build, focusing on pulling out any ambiguities to create a spec. 上記のプロンプトを実行し、Claude Codeとのやりとりを通して、要件の曖昧さを潰していき、SPEC.mdを作成する流れが紹介されました。要件の曖昧さを上流で潰すことで、実装のやり直しを減らすという設計思想です。 つぎに「HTML先行プロトタイプ」ではSPEC.mdをもとに、4つの異なるデザインを提案させて、HTMLのプロトタイプを作る流れが紹介されました。 Read ../phase-1-planning for its spec file, then help me figure out the overall design of this app. Explore 4 different designs, and create a set of HTML files with important screens for each. 上記のプロンプトを実行すると、つぎのHTMLのプロトタイプが出力されました。 Markdown形式でデザイン仕様を書き出すのではなく、クリックできるHTMLのプロトタイプを出力することで、見た瞬間に判断できます。 設計するタイミングで、Claude Codeとの認識合わせが視覚的にできることで、実装フェーズでのやり直しが少なくなり、トークン使用量の削減につながります。 また、既に運用しているサービスではデザインシステムといったデザイン基盤があれば、精度よくHTMLを出力できる可能性があります。それによって、新しい機能のデザインをするときの認識合わせがスムーズになりそうだと思いました。 Ship your first Managed Agent claude.com Claude Managed Agents（CMA）の全体像を、インシデントレスポンスのデモを通して整理するワークショップです。 このセッションで印象に残ったスライドが「The brain left the box」でした。 以前のアーキテクチャは、Agent loopとTool executionが同じコンテナの中に同居していました。Managed AgentsではAnthropicが管理する1つのサービスとして動き、ツール実行のSandboxはツールが必要なときだけオンデマンドで起動します。クライアントが切断されていてもループは動き続けるため、ローカルのターミナルを閉じてもセッションが止まりません。 これまで西村の開発環境のClaude Codeの使い方では、ローカルPCでClaude Codeを稼働させているため、プロンプトを入力しないとAIエージェントが動き出せませんでした。また、並列セッション数も最大8が限界でした。 Managed Agentsはこの2点を変えられると感じました。オンデマンドで非同期で動き続ける実行環境があれば、人間の合図を待たずに実装する用途が一気に現実的になります。 試したい用途として思い浮かんだのは、着手できていないイシューの開発・リファクタリング、そして人間が介在せずにPRをマージすることです。 最後の「自律マージ」には前提条件を考えなくてはいけません。最低限必要な前提条件を決めておかなければなりません。 例えば、テストカバレッジが一定基準を超えていること、テストの堅牢性が担保されていることなどです。 これらの前提条件を満たすための仕組みを整えることが、AIエージェントによる自律マージの実現に向けた重要なステップになると感じました。 ドメインエキスパートがソフトウェアを作る 森はFounder stageを中心に話を聞いていました。 いずれのセッションもドメインエキスパートの知識・決定が重要であることを話されていました。 いくつかご紹介します。 What happens when domain experts can finally build claude.com 登壇はクイーンズランド大学のJason Tangen教授。AIネイティブ時代のプロダクトは、汎用的な人材ではなく深いドメイン知識を持つ個人から生まれるという主張です。 「去年までソフトウェアを一行も書いたことがなかった」という彼が、6ヶ月で3つの本番アプリをデプロイしました。 登場したアプリはいずれも学生向けのもので、シラバス生成ツール（classbuild.ai）、法廷証言トレーニング（crosscoach.ai）、学生向け説明ツール、学生の顔と名前を覚えるゲームなど。 専門家の頭の中に眠っていたアイデアが、AIにより作るコストが下がり具現化できるようになりました。 最後に聴衆へ「あなたが何年も密かに欲しいと思っていた小さなツールは何ですか？」「チームの中で、実際にその仕事をやり続けてきた人は誰ですか？」と問いかけられました。 コードを書く能力ではなく、「何を作るべきか」を知っていることが大切なのだと感じました。 The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark claude.com 登壇者はGahee Seo氏。分類の誤りが金銭的損失に直結する貿易コンプライアンス領域で、ドメイン知識とClaudeの組み合わせが基盤モデル単体を超える優位を生むことを示します。 韓国からEUへの輸送など、さまざまな規制が複雑に絡み合う貿易の領域では、どんなAIモデルを使うかよりも専門家の判断フローをどう再現するかが優位を決めるとのことです。 最初のプロトタイプはSingle agentで1件の分類に6分かかっており、また、アウトプット精度にも課題があったとのことです。 課題を解決するために分類器を新しく訓練するのではなく、専門家が5段階で判断するワークフローを複製したという設計思想を発表してくれました。 入力が曖昧なまま処理が走らないようinput gateを設けたこと 全規制ルールをsystem promptに詰め込む設計をやめ、必要な文書を検索する Retrieval と出力結果を検証する Verifierという構想に転換 これらの対応をとりあげていました。さらにエージェントを役割ごとに分割することで30秒まで短縮しました。 アウトプットではなくワークフローを教える、という発言もありました。 期待する出力形式を示すのではなく、専門家がどういう順番で何を見て判断するかをシステム化する。職人芸をインフラに変える、という表現が使われていました。 まとめ 西村が午前に参加したAnthropicのワークショップ2つには、共通した問いがありました。 How we Claude CodeのHTMLプロトタイプは、実装前に人間の判断を前の工程に集約する仕組みです。Ship your first Managed Agentの非同期実行は、後工程での人間の介在を手放すための基盤です。 方向は逆に見えますが、根底にある問いは同じだと感じました。「人間はどこで関与すべきか」を先に設計する、という考え方です。その2点を組み合わせることで初めて、AIと人間の役割分担がきちんと設計できると思いました。 森の参加したセッションは「個人開発者・アーリーステージな創設者向け」という性格のものが多かったです。個人が専門知識を武器にプロダクトを作る事例が多く、それ自体は示唆に富んでいました。 どのセッションでも専門家の知識、決定が大事であるという主張を別の角度から語っていました。 一方で、チームでどう使っていくか・チームの中でどう成長していくかという話はありませんでした。 最近個人的に悶々としている「専門家がいない領域でどう専門性を担保するか」「専門家をどう育てるか、時間をかけるしかないのか」という問いには答えが見つからなかったので引き続き考え続けます。 ファインディでは一緒に働く仲間を募集しています ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

本記事は 2026 年 6 月 3 日 に公開された「 Migrating data from Oracle to Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、サーバーレスで柔軟にスケールする分散 SQL データベースサービスです。複数の AWS リージョンにまたがって、強力な ACID 準拠を実現します。データベースのモダナイゼーションに向けて Amazon Aurora DSQL を検討している場合、サービスの現在の機能と制約の範囲内で既存のエンタープライズデータベースを移行するという課題に直面することがあります。 本記事では、 AWS Database Migration Service (AWS DMS) 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Glue 、 AWS Step Functions を使い、Oracle ソースから Amazon Aurora DSQL へデータを移行する手順を説明します。エンタープライズ規模のデプロイに適した、自動化されたコスト効率の高い移行パイプラインを構築します。 このソリューションの完全なソースコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリで入手できます。 Amazon Aurora DSQL の概要 Amazon Aurora DSQL は、高可用性、スケーラビリティ、パフォーマンスを必要とするアプリケーション向けに設計された、サーバーレスの分散 SQL データベースです。主な特長は次のとおりです。 サーバーレスアーキテクチャ – Amazon Aurora DSQL はフルマネージドのサーバーレスデータベースサービスで、需要に応じてコンピューティング、ストレージ、実行レイヤーを自動的にスケールします。 PostgreSQL 互換性 – Amazon Aurora DSQL は PostgreSQL 互換の SQL 構文と機能を提供するため、PostgreSQL インターフェイスで動作するアプリケーションに適しています。 分散設計 – 分散アーキテクチャを採用し、複数のアベイラビリティーゾーンにわたる高可用性と耐久性を実現します。 マルチリージョン対応 – Amazon Aurora DSQL は、ディザスタリカバリやグローバルアプリケーション向けにマルチリージョンデプロイをサポートします。 IAM 統合 – AWS Identity and Access Management (IAM) と統合し、認証とアクセス制御を行います。 暗号化 – Amazon Aurora DSQL は、データセキュリティのために保管時と転送時の暗号化を提供します。 移行の課題と要件 エンタープライズデータベースを Amazon Aurora DSQL に移行する際には、いくつかの固有の課題に直面します。 認証の複雑さ – Amazon Aurora DSQL では、特定のトークン生成要件を伴う IAM ベースの認証が必要です。必要なロールを引き受けられる AWS サービスは限られているため、直接接続できる手段が制限され、認証を慎重に管理する必要があります。 スキーマ作成の自動化 – Amazon Aurora DSQL では、データをロードする前にスキーマとテーブルを明示的に作成する必要があります。そのため、ソースデータベースからのスキーマ分析と変換を自動化する仕組みが必要です。 データロードの制約 – Amazon Aurora DSQL は主にファイルからの COPY コマンドでのデータロードをサポートしており、移行戦略に固有の要件が生じます。ファイルはデータベースエンジンからローカルにアクセスできる必要があり、移行パイプラインの構成方法に影響します。 コスト最適化 – 中間処理に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使う従来の方法では、特に移行期間が長期にわたる大規模データベースで、ストレージとコンピューティングのコストが大きくなることがあります。 ソリューションの概要 次の図は、ソリューションのアーキテクチャを示しています。 ワークフローは次のステップで構成されます。 パイプラインがオンプレミスの Oracle データベースからデータを抽出します。ソースには、AWS DMS がサポートする他のリレーショナルデータベースを使うこともできます。 AWS DMS がデータを Amazon S3 に移行し、AWS Glue データカタログを作成します。 Step Functions が AWS DMS タスクの進行を開始・監視し、 AWS Lambda 関数と AWS Glue ジョブを起動します。 Lambda 関数が AWS DMS からテーブルマッピングを取得して Step Functions に返し、Step Functions がそれを AWS Glue ジョブに渡します。 AWS Glue がターゲットの Amazon Aurora DSQL データベースに接続し、データカタログを使ってカラムを識別します。続いてターゲットにスキーマを作成し、ターゲットのデータ型にデータを変換します。最後に Amazon S3 からデータを読み取り、Amazon Aurora DSQL データベースにロードします。 前提条件 始める前に、次の前提条件を満たしていることを確認してください。 AWS DMS のレプリケーションソースとして設定し、データベース移行の準備が整ったソース Oracle データベース。 中間データストレージ用の S3 バケット。次の設定を行います。 ブロックパブリックアクセスを有効化。 デフォルト暗号化 (SSE-S3 または SSE-KMS) を構成。 AWS DMS がターゲットとして使用し、AWS Glue がアクセスするために必要な権限。 AWS DMS タスクの監視、Lambda 関数の起動、AWS Glue ジョブの管理を行うサービスロールを引き受ける Step Functions ワークフローを作成するためのユーザー権限。 特定の Amazon Aurora DSQL クラスターにスコープを限定した次の IAM 権限。 iam:CreateServiceLinkedRole 。 dsql:DbConnect 。 dsql:DbConnectAdmin 。 dsql:GenerateDbConnectAdminAuthToken 。 dsql:GenerateDbConnectAuthToken 。 Amazon Aurora DSQL のターゲットインスタンスを作成する Amazon Aurora DSQL クラスターを作成するには、次のステップを実行します。 Amazon Aurora DSQL コンソールのナビゲーションペインで、[ Clusters ] を選択します。 [ Create cluster ] を選択し、[ Single-Region ] または [ Multi-Region ] を選択します。 暗号化設定、削除保護、タグを構成します。 [ Create cluster ] を選択します。 クラスター作成の詳細な手順、高度な設定、マルチリージョンのセットアップオプションについては、 Aurora DSQL の開始方法 を参照してください。 AWS DMS タスクを構成する 次のステップで AWS DMS タスクを構成します。 データ量を処理できる十分な容量のレプリケーションインスタンスを作成します。 接続情報を設定し、転送時の暗号化のために SSL モードを verify-full に設定した Oracle ソースエンドポイントを作成します。 次の設定で Amazon S3 ターゲットエンドポイントを作成します。 DataFormat を CSV に設定。 EncryptionMode を SSE_KMS に設定。 ServerSideEncryptionKmsKeyId を KMS キーの ARN に設定。 GlueCatalogGeneration と IncludeOpForFullLoad を True に設定。 AWS DMS 移行タスクを作成します。 移行タイプに [ full load ] を選択します。 ソーススキーマのテーブルマッピングを構成します。 ラージオブジェクト (LOB) の処理とパフォーマンスに適したタスク設定を行います。 移行タスクの起動設定を [ Manually later ] に設定します。 AWS DMS の詳細な構成手順、エンドポイント設定、タスク構成オプションについては、 Creating a task 、 Using an Oracle database as a source for AWS DMS 、 Using Amazon S3 as a target for AWS Database Migration Service を参照してください。 Lambda 関数を作成する AWS DMS タスクのマッピングからテーブル情報を抽出する Lambda 関数を作成します。この関数は DMS タスクのテーブルマッピングを解析してターゲットのテーブル名を特定し、それを AWS Glue ETL ジョブに渡します。 Lambda 関数の完全なコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 この関数は主に次の処理を行います。 DMS タスクイベントから tableMappings を解析します。 DMS ルールを順に処理し、選択タイプのルールを見つけます。 object-locator からテーブル名を抽出して返します。 Lambda の構成 メモリ – 128 MB (テーブル名の抽出には十分です)。 タイムアウト – 15 秒 (5 秒より長く設定します)。 IAM ロール – 次の AWS DMS 権限を持つ基本的な Lambda 実行ロール。 dms:DescribeReplicationTasks – AWS DMS タスクの詳細とテーブルマッピングを読み取ります。 dms:DescribeTableStatistics – テーブル単位の移行統計にアクセスします。 Lambda の IAM 権限要件の詳細については、 AWS Lambda アクセス許可の管理 および AWS DMS API Reference を参照してください。 AWS Glue ETL ジョブを作成する AWS Glue ETL ジョブは、スキーマの作成、データ型のマッピング、Amazon Aurora DSQL へのデータロードを担います。 データカタログのセットアップ Amazon S3 をターゲットにすると、AWS DMS がデータカタログのエントリを自動的に作成します。別途クローラーを用意する必要はありません。AWS DMS は移行中にデータカタログを生成し、Oracle ソースの適切なスキーマ情報を使ってテーブルをカタログ化します。 ジョブの構成 ジョブタイプ – Spark ETL。 AWS Glue バージョン – 3.0 以降。 依存 JAR のパス – postgresql-42.7.4.jar (JAR ファイルをダウンロードし、S3 のアクセスパスを指定します)。 Python モジュールのパス – boto3>=1.35.95 (Amazon Aurora DSQL の認証に使用します)。 ワーカータイプ – データ量に応じて調整します。 Glue ジョブの IAM 権限 AWS Glue ジョブには、次のサービスにまたがる権限が必要です。完全な IAM ポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 ステートメント アクション 目的 S3Access s3:GetObject , s3:ListBucket 移行データを Amazon S3 から読み取る GlueDataCatalogAccess glue:GetDatabase , glue:GetTable , glue:GetPartitions スキーマのメタデータにアクセスする AuroraDSQLAccess dsql:DbConnect , dsql:DbConnectAdmin ターゲットデータベースに接続する DSQLTokenGeneration dsql:GenerateDbConnectAdminAuthToken , dsql:GenerateDbConnectAuthToken 認証トークンを生成する AWS Glue の IAM 要件の詳細については、 「AWS Glue」 のセキュリティ および Aurora DSQL での Identity and Access Management を参照してください。 AWS Glue ETL ジョブのスクリプト 完全なスクリプトは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 このスクリプトは主に次の処理を行います。 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() を使って IAM 認証トークンを生成します。 スキーマ検出 – AWS Glue データカタログからテーブルスキーマを読み取ります。 データ型マッピング – 次の表のように、Oracle と Glue のデータ型を Amazon Aurora DSQL 向けの PostgreSQL 互換型にマッピングします。 Glue の型 Amazon Aurora DSQL の型 string VARCHAR(255) int INTEGER bigint BIGINT double DOUBLE PRECISION float REAL boolean BOOLEAN timestamp TIMESTAMP date DATE decimal NUMERIC long BIGINT binary BYTEA map JSONB struct JSONB array TEXT[] 入力検証 – SQL インジェクションを防ぐため、テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で検証します。 DDL 実行 – 明示的なトランザクション管理を伴う JDBC 接続を使って、Amazon Aurora DSQL にテーブルを作成します。 データロード – Amazon S3 から CSV データを読み取り、型キャストを適用し、トランザクション分離レベル REPEATABLE_READ とバッチサイズ 9,900 行で JDBC を使って Amazon Aurora DSQL に書き込みます。 Glue ジョブの主な設定 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() メソッドを使用します。 トークンの有効期限 – 最大 24 時間です。ここでは 1 時間に設定しています。 ユーザー ID – サンプルコードで使用するユーザー ID は admin です。 データ型マッピング戦略 – GlueCatalogGeneration を使うと、スキーマのカラムにはソースの値と一致しないことがあるデフォルトのデータ型が割り当てられます。AWS Glue のコードでデータ型マッピング戦略を定義してください。Amazon Aurora DSQL がサポートするデータ型については、 Amazon Aurora DSQL ユーザーガイド を参照してください。 トランザクション分離レベル – Amazon Aurora DSQL ターゲットでは、データ整合性のために REPEATABLE_READ が必要です。 Step Functions ステートマシンを作成する Step Functions ステートマシンが移行ワークフローを制御します。ステートマシンは AWS DMS タスクを開始し、その状態を監視します。AWS DMS タスクが完了すると、テーブルマッピングを抽出してテーブル名を AWS Glue ジョブに渡します。その後、AWS Glue ジョブを起動します。 次の図は、ステートマシンのワークフローを示しています。 ステートマシンワークフローの特徴 AWS DMS の自動開始 – レプリケーションタスクをプログラムで開始します。 進行状況の監視 – AWS DMS タスクの状態を 60 秒ごとにポーリングします。 完了の検出 – stopped ステータスと進行状況 100% を待ちます。 エラー処理 – 失敗した AWS DMS タスクを適切に処理します。 Lambda 連携 – AWS Glue ジョブ向けにテーブル情報を抽出します。 AWS Glue ジョブの起動 – テーブルパラメータを指定して AWS Glue ETL ジョブを開始します。 セットアップの手順 ステートマシンを構成するには、次のステップを実行します。 Step Functions コンソールで、[ Create state machine ] を選択します。 [ Write your workflow in code ] を選択し、ステートマシン定義を入力します。完全なステートマシン定義については、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 定義内の Amazon リソースネーム (ARN) とジョブ名を更新します。 AWS DMS タスクの ARN を、自分のタスクの ARN に置き換えます。 Lambda 関数の ARN を、自分の関数の ARN に置き換えます。 AWS Glue ジョブ名を、自分のジョブ名に置き換えます。 ステートマシンを作成する前に、参照する ARN が存在することを確認します。 次の権限を持つ IAM 実行ロールを作成します。 dms:StartReplicationTask 。 dms:DescribeReplicationTasks 。 lambda:InvokeFunction 。 glue:StartJobRun 。 CloudWatchLogsDeliveryFullAccessPolicy (ステートマシンの実行ログを保存するため)。 ステートマシンのステート ステートマシンは、次のステートを通じて移行を制御します。 ステート タイプ 目的 StartDMSTask Task DMS レプリケーションタスクを開始する GetDMSTaskDetails Task レプリケーションタスクの状態を取得する CheckDMSTaskStatus Choice ステータス (stopped、failed、running) に応じて分岐する WaitForDMSTask Wait 60 秒ごとにポーリングする DMSTaskFailed Fail 失敗したタスクのエラー処理 ExtractTableName Task Lambda を呼び出してテーブル名を取得する StartGlueJob Task テーブル名パラメータを指定して AWS Glue ETL ジョブを起動する Step Functions のセットアップと AWS DMS との統合パターンの詳細については、 AWS Step Functions デベロッパーガイド および Create and run AWS DMS tasks using AWS Step Functions を参照してください。 セキュリティに関する考慮事項 このソリューションでは、機密データを扱う可能性のある複数の AWS サービスを使用します。次のセキュリティのベストプラクティスに従ってください。 責任共有モデル このアーキテクチャは AWS 責任共有モデル に従います。責任は次のように分担されます。 サービス AWS の管理範囲 お客様の管理範囲 Amazon Aurora DSQL データベースエンジン、パッチ適用、高可用性、インフラストラクチャのセキュリティ IAM ポリシー、VPC エンドポイントの構成、暗号化キーの選択 Amazon S3 ストレージインフラストラクチャ、耐久性、可用性 バケットポリシー、暗号化の構成、アクセス制御、ブロックパブリックアクセス AWS DMS レプリケーションインスタンスの OS、エンジンのパッチ適用 エンドポイントのセキュリティ、SSL/TLS の構成、ネットワークアクセス セキュリティ実装の優先順位 データ移行を開始する前に、次の順序でセキュリティ対策を実装してください。 S3 バケットの暗号化 (SSE-KMS) とブロックパブリックアクセスを構成します。 各サービス (AWS DMS、Lambda、AWS Glue、Step Functions) に最小権限の IAM ロールを作成します。 カスタマーマネージド KMS キーで Amazon Aurora DSQL クラスターの暗号化を有効にします。 データがパブリックインターネットを経由しないように、Amazon S3 と AWS Glue の VPC エンドポイントを構成します。 監査とモニタリングのために、AWS CloudTrail と Amazon CloudWatch のログ記録を有効にします。 すべてのデータベース接続で SSL/TLS が強制されていることを確認します。 セキュリティ検証の手順 デプロイ後、次の点を確認します。 # Confirm S3 bucket encryption aws s3api get-bucket-encryption --bucket your-migration-bucket # Confirm Block Public Access aws s3api get-public-access-block --bucket your-migration-bucket さらに、次の点を確認します。 本番環境の IAM ポリシーにワイルドカード ( * ) リソースが含まれていないこと。 DMS レプリケーションインスタンスがパブリック IP を持たないプライベートサブネットに配置されていること。 すべての JDBC 接続文字列で、Amazon Aurora DSQL への接続に sslmode=require が使われていること。 認証トークンが設定した期間内 (AWS は 1 時間を推奨) に失効すること。 移行中のデータ保護 AWS DMS エンドポイントで転送時の暗号化を有効にします (Oracle ソースには SSL/TLS、Amazon S3 ターゲットには SSE-KMS)。 認証トークンをログに出力しないでください。有効期間の短いトークン (1 時間) を使い、設定は環境変数または AWS Secrets Manager に保存します。 aws:SecureTransport 条件を使って、暗号化されていない通信を拒否する S3 バケットポリシーを適用します。完全なバケットポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 AWS Glue ジョブの IAM ロールを、特定の S3 プレフィックスと Amazon Aurora DSQL クラスターに限定します。ワイルドカードの ARN は避けてください。 KMS キーポリシーを使って、移行データを暗号化・復号できるプリンシパルを制御します。 脅威モデル 次の表は、このアーキテクチャで特定し、緩和した脅威を示しています。 脅威 緩和策 過剰な権限を持つ IAM ロール すべての IAM ポリシーを、ワイルドカードではなく特定のリソース ARN に限定します。 テーブル名を介した SQL インジェクション テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で入力を検証します。 認証トークンの盗難やリプレイ 有効期間の短いトークン (有効期限 1 時間) を使い、ログには出力せず、認証情報はコードではなく環境変数に保存します。 S3 中間ストレージへの不正アクセス ブロックパブリックアクセスを有効にし、バケットポリシーを特定の IAM ロールに限定し、SSE-KMS 暗号化を使用します。 コードのセキュリティレビュー 本記事のすべてのコードサンプルは、入力検証、安全な認証処理、最小権限のアクセスパターン、インジェクション攻撃への防御を対象に、手動でセキュリティレビューを実施しています。レビューは、Bandit 1.7 (Python) と ESLint security plugin (JavaScript) による静的解析を使って行いました。 検出結果: Critical または High の重大度の問題は見つかりませんでした。Medium の検出結果 (情報レベルのログ出力) はレビューのうえ、サンプルコードとして妥当と判断しました。 本番環境にデプロイする前に、Amazon Inspector や同等のツール (Bandit (Python)、ESLint security plugin (JavaScript) など) で独自に静的解析スキャンを実行し、組織のセキュリティ基準に照らして検証してください。 Lambda のセキュリティガイドライン インターネットアクセスのない VPC プライベートサブネットに関数をデプロイします。AWS サービスには VPC エンドポイントを使用します。 AWS Key Management Service (AWS KMS) を使って環境変数を暗号化します。 リソースベースのポリシーを適用し、呼び出しを Step Functions のみに制限します。 実行ロールには最小権限の原則を適用します ( dms:DescribeReplicationTasks と dms:DescribeTableStatistics のみ)。 予約済み同時実行数を設定し、呼び出しの暴走を防ぎます。 Step Functions のセキュリティガイドライン AWS KMS カスタマーマネージドキーを使って、ステートマシンの保管時の暗号化を有効にします。 実行履歴のために、暗号化を有効にした Amazon CloudWatch Logs を有効にします。 ステートマシンの入力や出力で機密データ (トークン、パスワード) を渡さないようにします。AWS Systems Manager Parameter Store または AWS Secrets Manager を使用します。 実行ロールが最小権限に従っていることを確認します (AWS DMS、Lambda の呼び出し、AWS Glue の StartJobRun の権限のみ)。 IAM リソースベースのポリシーを使って、ステートマシンへのアクセスを制限します。 クリーンアップ 今後の課金を避けるため、このチュートリアルで作成したリソースを削除します。 Step Functions コンソールで、対象のステートマシンを選択し、[ Delete ] を選択します。 Lambda コンソールで、対象の関数を選択し、[ Actions ]、[ Delete ] の順に選択します。 AWS Glue コンソールで、対象の ETL ジョブを選択し、[ Action ]、[ Delete job ] の順に選択します。 AWS DMS コンソールで、次のリソースをこの順序で削除します。 移行タスク。 エンドポイント (ソースとターゲット)。 レプリケーションインスタンス。 Amazon S3 コンソールで、移行用バケットを空にして削除します。 Amazon Aurora DSQL コンソールで、対象のクラスターを選択し、[ Delete ] を選択します。 IAM コンソールで、このソリューション用に作成した IAM ロールとポリシーを削除します。 カスタマーマネージド KMS キーを使用した場合は、まだ必要かどうかを評価し、適切であれば削除をスケジュールします。 まとめ 本記事では、AWS DMS、Step Functions、Lambda、AWS Glue を使った自動化のアプローチで、Oracle から Amazon Aurora DSQL へ移行する手順を説明しました。このソリューションは、Amazon Aurora DSQL のサーバーレスアーキテクチャ特有の課題に対応します。Amazon S3 を中間ストレージとして使い、ワークフロー全体に十分なエラー処理を組み込むことで、手作業や運用の複雑さを抑えつつ、信頼性の高いデータ移行を実現できます。 Amazon Aurora DSQL の進化に合わせて、この移行フレームワークはデータベースモダナイゼーションを進めるうえで確かな基盤になります。インフラストラクチャのコストと管理の負荷を抑えながら、Amazon Aurora DSQL を最大限に活用できます。 この移行アプローチを始めるには、次の手順を実行します。 GitHub の sample-oracle-to-aurora-dsql-migration リポジトリをクローンします。 テストテーブルを使って、AWS アカウントに Step Functions ワークフローをデプロイします。 本番のワークロード全体に拡張します。 ご質問やフィードバックがあれば、コメントで共有するか、 AWS re:Post community をご覧ください。 著者について Aliasghar Hussain AWS の Database Specialist Solutions Architect です。Amazon RDS、DocumentDB、DynamoDB、ElastiCache といったクラウドデータベース技術で 6 年以上の経験があります。また、複雑なデータベース移行戦略、モダナイゼーション、インフラストラクチャ最適化に関する技術的なガイダンスを提供する分野の専門家として、お客様の AWS におけるクラウド導入の加速を支援しています。 Wasim Shaikh AWS でデータベースを専門とする Senior Solutions Architect です。お客様と協力して、さまざまなデータベースおよび分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を利用する際のソリューションの価値向上を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。