本ブログは 2026 年 4 月 2 日に公開された AWS Blog “ Four security principles for agentic AI systems ” を翻訳したものです。 エージェンティック AI は、ソフトウェアの動作のあり方を質的に変えるものです。従来のソフトウェアは決定論的な命令を実行します。生成 AI は人間のプロンプトに応答して出力を生成し、人間はその出力を確認したうえで、自らの判断で利用します。エージェンティック AI は、そのどちらとも異なります。エージェントはソフトウェアツールや API に接続し、大規模言語モデル (LLM) を推論エンジンとして使用して、一連のアクションを機械処理の速度で自律的に計画し、実行します。そして、その結果は現実世界に影響を及ぼします。この変化は、情報セキュリティに新たな問いを投げかけています。2026 年 1 月、NIST の Center for AI Standards and Innovation (CAISI) は、こうしたシステムを保護する方法について業界の意見を求める RFI (Request for Information: 情報提供依頼) を発行しました。AWS は、エージェンティック AI サービスの構築と運用の経験に基づいて 回答を提出しました 。この記事では、その回答の中核となる 4 つのセキュリティ原則と、それらを実装するアーキテクチャの構成要素について紹介します。 NIST のエージェンティック AI に関する RFI CAISI は、開発者、デプロイ担当者、セキュリティ研究者に対し、自律的に動作する AI システムを業界としてどのように保護すべきかについて意見を求めました。この RFI では、5 つの領域にわたって問いが提示されています。エージェンティックシステムはどのような固有のセキュリティ上の考慮事項をもたらし、システムの自律性が高まるにつれて、それらの考慮事項はどのように変化するのか? 開発とデプロイにおいて、どのようなプラクティスがセキュリティを向上させるのか? 組織は、エージェンティックシステムのセキュリティをどのように評価するのか? デプロイ環境をどのように制約し、監視できるのか? そして、業界は今後どの分野の研究に注力すべきか? なぜこれが重要なのか リスクとメリットを保守的に分析したとしても、多くの領域ではエージェンティック AI のメリットがリスクを明らかに上回るという結論になるでしょう。企業や政府機関でエージェンティックテクノロジーの導入が急速に進んでいることも、それを裏付けています。しかし、エージェントの価値はまさにその自律性と適応性にあり、こうした特性そのものがセキュリティ上の課題を生み出します。エージェンティックシステムは、意図しないアクションを、人間が介入する間もなく機械処理の速度で実行してしまう可能性があります。人間であれば、何かがおかしいと感じたときに作業を中断したり、エスカレーションしたりします。しかしエージェントは、人間には明らかなあいまいさを自ら認識できるとは限らず、明文化されていないポリシーの境界を直感的に把握できるとも限りません。 さいわいなことに、エージェンティック AI のセキュリティ対策をゼロから考える必要はありません。 NIST Cybersecurity Framework 、 NIST AI Risk Management Framework 、 Secure Software Development Framework などの既存のセキュリティフレームワークは引き続き有効です。これらを置き換えるのではなく、エージェント固有の考慮事項に合わせて拡張すべきです。中でも最も重要なのは、アーキテクチャ面での拡張です。AWS は NIST への回答の中で、この拡張の進め方を示す 4 つの基本的なセキュリティ原則を挙げました。 エージェンティック AI の 4 つのセキュリティ原則 これらの原則は、エージェンティック AI に新しいセキュリティパラダイムは必要ないものの、既存のプラクティスは進化させる必要があるという前提に基づいています。最初の 2 つの原則は従来から引き継がれる要素を扱い、残りの 2 つの原則は真に新しい要素を扱います。 原則 1: セキュアな開発ライフサイクルのプラクティスは、システムのすべてのコンポーネントに適用されます。 エージェンティック AI システムは、従来のソフトウェアコンポーネント (API、データベース、オーケストレーションロジック) と、基盤モデル、プロンプトテンプレート、検索パイプラインなどの AI 要素を組み合わせたものです。セキュアな開発ライフサイクルは、この両方のコンポーネントを対象とする必要があります。従来のコンポーネントについては、コードレビュー、静的解析、依存関係のスキャン、脅威モデリングなどの確立されたプラクティスが引き続き不可欠です。ただし、これらのプラクティス自体も、AI ベースのツールによって強化されつつあることに留意してください。一方、AI コンポーネントには異なる課題があります。基盤モデルは確率的に動作するため、従来の回帰テストは必要ですが、それだけでは十分ではありません。組織は、動作テスト、敵対的評価、継続的なモニタリングによって回帰テストを補完し、AI コンポーネントが想定された範囲内で動作することを検証する必要があります。 動作のドリフトに対処するには、定期的な再評価も同様に重要です。モデルが更新されれば、動作が変わる可能性があります。チームがエージェントの機能を改良していくにつれて、プロンプトテンプレートも変化します。新しいツールやデータソースが追加されれば、エージェントの運用上の対象領域も広がります。こうした変更のたびに、新たな障害モードや潜在的なセキュリティ上の問題が生じる可能性があります。組織は、評価を一度きりの関門ではなく、継続的な運用プラクティスとして扱う必要があります。これには、モデル更新後の自動テスト、デプロイ済みのエージェントに対するレッドチーム演習、時間の経過に伴う動作のドリフトを検出するモニタリングが含まれます。 原則 2: 従来のセキュリティ制御は引き続き完全に適用されます。 エージェンティック AI は新たな考慮事項をもたらしますが、既存のセキュリティリスクがなくなるわけではありません。従来のセキュリティ制御は、そのすべてが引き続き適用されます。エージェンティック AI システムは、従来のソフトウェアと、LLM とツールを組み合わせた新しい処理ループで構成されています。エージェンティックな要素を支える健全な基盤を整えるために、組織は既存のソフトウェア、ツール、設定を既知のリスクから保護する必要があります。 権限昇格、混乱した代理問題 (confused deputy)、セッションハイジャック、コードインジェクション、サプライチェーンリスクは、そのままエージェンティックシステムにも当てはまります。エージェンティックなコンテキストでは、これらのリスクの一部がさらに増大します。エージェントは人間よりも大規模かつ高速に動作するため、過剰な権限が意図しない結果を招く可能性も高くなります。つまり、エージェンティックなコンテキストでアクセス管理に最小権限の原則を適用することは、従来のシステムと同等か、それ以上に重要です。サプライチェーンの攻撃対象領域も広がります。エージェンティックシステムが利用するのは、サードパーティのコード依存関係だけではありません。基盤モデル、プラグイン、ツールサーバー、データ取得ソースも利用します。API を呼び出したり、データベースに対してクエリを実行したり、コードを生成したりするエージェントは、ツールとの境界に新たなインジェクションの攻撃対象領域を生み出す可能性があります。AI 固有の制御は、こうした基盤となるセキュリティを置き換えるものではなく、その上に追加するものでなければなりません。 原則 3: 決定論的な外部制御が、エージェンティックセキュリティの出発点です。 これは、エージェンティック AI のセキュリティにとって最も重要なアーキテクチャ原則です。組織は、エージェント自身の推論、内部のガードレール、プロンプトベースの指示に頼るのではなく、エージェントの推論ループの外部にあるインフラストラクチャレベルの決定論的な制御によって、セキュリティを強制すべきです。理由は単純です。LLM は確率的な推論エンジンであり、セキュリティを強制するための仕組みではありません。開発者は LLM に特定のリクエストを拒否するよう指示できますが、プロンプトインジェクションの手法によってその指示が上書きされる可能性があります。LLM にアクセスの境界を守るよう指示することはできても、LLM にはその境界を確実に強制する仕組みがありません。プロンプトやアライメントだけでエージェントの動作を制約しようとするアプローチは、未知の状況に動的に適応できるというエージェント本来の価値に反するものです。 効果的なセキュリティを実現するには、完全に定義された決定論的な制御をエージェントの外部に配置し、その制御によって、エージェントがアクセスできるツール、実行できる操作、到達できるデータを管理する必要があります。モデルを操作しても、これらの制御を回避することはできません。AWS はこれを セキュリティボックス (security box) と呼んでいます。セキュリティボックスはエージェントの外部に置かれ、決定論的に適用され、対象を網羅的にカバーします。エージェントと外部とのやり取りはすべて、このボックスを経由します。 Agentic AI Security Scoping Matrix を活用すると、組織はシステムの自律性レベルに応じて、これらの制御の厳格さを調整できます。スコープは、すべてのアクションの前に人間による明示的な承認を必要とするシステムから、外部イベントに基づいて自らアクティビティを開始する完全自律型のシステムまで多岐にわたります。 セキュリティボックスは、エージェントの価値を制限するものではありません。むしろ、その価値を責任ある形で実現するための前提条件です。エージェンティックテクノロジーが成熟するにつれて、このボックス自体も進化し、エージェンティックな要素を含むようになると考えられます。他のエージェントのスコープを制御するように設計された専用の AI エージェントが、時間の経過とともに一部の決定論的な制約に取って代わる可能性があります。そうしたエージェントは、新しい情報とコンテキストを活用し、人間が複雑な決定論的制御を管理する場合よりも適切な判断を自動で下せるようになる可能性があります。 原則 4: より大きな自律性は、継続的な評価を通じて獲得していくべきです。 組織は、エージェントの自律性をデフォルトで付与するのではなく、実証されたパフォーマンスに基づいて段階的に拡大すべきです。出発点は、影響の大きい操作について人間が意思決定を行うことです。価値の高い本番データの変更、金融取引の開始、機密情報の外部への送信につながる可能性のあるアクションにエージェントが直面した場合は、人間が最終的な判断を下します。エージェントが推奨し、人間がそれを承認または却下するという形です。 ただし、このアプローチには、よく知られたリスクがあります。エージェントのすべてのアクションに人間の承認が必要になると、判断すべき件数がレビュー担当者の処理能力を超えてしまう可能性があります。その結果、承認が熟慮ではなく反射的に行われるようになり、失敗せざるを得ない立場に置かれた人間に責任が押し付けられることになります。組織は、人間による監督の対象を真に影響の大きい操作に絞り込み、リスクの低い日常的なアクションにまで安易にヒューマンインザループ (human-in-the-loop) の設計を求めないようにする必要があります。 人間による監督から自律性の拡大へと進む道筋は、評価によって切り開かれます。エージェントが何を推奨し、人間が何を決定し、実際に何が起きたかを組織が体系的に記録していくことで、自律性の拡大を裏付けるエビデンスが蓄積されます。これらの記録から、エージェントの推奨が人間の判断や実際の結果と継続的に整合していることが確認できれば、組織は事前承認から事後レビューへ、さらに最終的には特定の種類の操作について完全な自律へと移行できます。この移行は、関連性のない幅広いタスクに一括で適用するのではなく、操作またはワークフローの単位で進めるべきです。 この移行は一方通行ではありません。組織は、エビデンスから必要と判断される場合には、人間による監督を再導入できるよう備えておく必要があります。また、一部の決定論的な境界は、予見可能な将来にわたって恒久的に維持される可能性が高いでしょう。こうした境界が存在するのは、エージェントが信頼を獲得していないからではなく、合理的なリスク分析に照らして、特定のアクションがもたらす結果が許容できないからです。全体としてのモデルは、実証された能力によって自律性を獲得し、評価によって統制され、恒久的な制約によって範囲が限定され、継続的なレビューの対象となるというものです。いずれ、専門化された 境界エージェント (boundary agent) が、純粋に決定論的な制御よりも優れた成果をもたらす可能性があります。ただし、その選択肢は、経験と評価を積み重ねる中で、時間をかけて初めて実現するものです。 原則から実践へ 4 つの原則は、目指すべき目標を定めるものです。目標を達成するには、セキュリティボックスとより広範なセキュリティアーキテクチャを構成する、具体的なアーキテクチャの構成要素が必要です。NIST への回答では、これらの構成要素をより詳しく説明しています。ここではその概要を紹介します。AWS はこれらの構成要素を Amazon Bedrock AgentCore に実装しています。Amazon Bedrock AgentCore は、セキュリティを基礎から組み込んだ、エージェンティック AI システムを構築、デプロイ、運用するためのフレームワークです。 コンピューティングの分離。 エージェントのコンピューティング環境は、実行を分離し、エージェント間のデータ漏洩を防ぎ、定義された境界内にエージェントを封じ込める必要があります。Amazon Bedrock AgentCore は、エージェントを Firecracker 上で実行します。Firecracker は Rust で記述されたオープンソースの仮想マシンマネージャーです。Linux KVM とハードウェアベースの仮想化を基盤とする軽量なマイクロ VM を提供し、コンテナ並みの速度と、完全な仮想マシンと同等の分離特性を両立しています。Firecracker のセキュリティ上重要な中核要素は AWS のチームによって形式検証済みであり、Rust によるメモリ安全性に加えて、さらなる保証を提供しています。 アイデンティティとアクセス管理。 エージェントには、固有のアイデンティティ、安全な認証情報の保管、インフラストラクチャレベルで強制される最小権限の認可が必要です。 AgentCore Identity は、エージェントにマシンアイデンティティを提供し、OAuth と安全な認証情報のフローを管理します。また、きめ細かなアクセス制御を実現するために AWS Identity and Access Management (IAM) と統合されています。属性ベースのアクセス制御をサポートし、追跡可能な委任チェーンを維持することで、エージェントのアクションと呼び出し元のユーザーとの関係を監査可能な状態に保ちます。 ツールアクセスとポリシーの適用。 エージェントがアクセスできるツールが増えるたびに、その有用性と潜在的なリスクの両方が拡大します。エージェントごとにツールへのアクセスを個別に管理すると、組み合わせが爆発的に増加し、管理しきれなくなります。AgentCore Gateway は、エージェントとツールの間で一元的な仲介役として機能し、単一の制御ポイントで認証と認可を適用します。API レベルだけでなく、個々のパラメータに至るまでツール呼び出しを検査できます。 AgentCore Policy は、オープンソースの Cedar 認可言語に基づいて構築されており、形式検証済みのポリシー適用を実現します。チームは Cedar ポリシーを自然言語で作成してからレビューできるため、LLM の柔軟性と形式手法の厳密性を両立できます。 オブザーバビリティ。 オブザーバビリティのインフラストラクチャには、リアルタイムのモニタリングと調査に十分なコンテキストを取得できること、そして監視対象のエージェント自身から保護されていることが求められます。組織が従業員に自分の監査ログの編集を許可しないのと同様に、この原則はエージェントにも当てはまります。AgentCore は、 AgentCore Gateway 、セッションレベルのテレメトリ、内部の状態変化を記録する詳細なトレースを通じてオブザーバビリティを提供します。これらの機能は、AgentCore の外部で実行されているエージェントにも適用できます。 モデル実行環境。 モデル実行環境のセキュリティは、エージェント自体のセキュリティと同じくらい重要です。 Amazon Bedrock は、AWS もモデルプロバイダーもお客様のプロンプトとレスポンスにアクセスしない、分離されたネットワーク環境でモデルを実行します。お客様がログ記録を有効にした場合、そのログは保存時に暗号化され、カスタマーマネージドキーによって保護されます。こうしたアーキテクチャレベルの分離は、政府機関や企業のお客様が Amazon Bedrock を採用している主な理由の 1 つです。 訳注: カスタマーマネージドキーによる保護を適用するには、ログの配信先の Amazon S3 バケットでカスタマーマネージドキーを使用する SSE-KMS を設定するか、Amazon CloudWatch Logs のロググループにカスタマーマネージドキーを関連付けて暗号化を設定する必要があります。参照: CloudWatch Logs と Amazon S3 を使用してモデル呼び出しをモニタリングする 決定論的な外部制御は、AI 処理ループ内の制御によって補完されます。 Amazon Bedrock Guardrails は、 分類器 (classifier) と呼ばれる小規模な AI モデルを使用してプロンプトとレスポンスを検査し、プロンプトインジェクションなどの課題に対処します。自動推論チェックはさらに一歩進んでおり、開発者は特定の知識領域の形式モデルを作成し、LLM の出力がそのモデルに準拠していることを検証できます。その結果は決定論的であり、正しさを証明できるものになります。 今後の展望 エージェンティック AI はソフトウェアの動作のあり方を変えますが、そのセキュリティ対策は数十年にわたって確立されてきたプラクティスの上に成り立っています。既存のフレームワークは適切な基盤となります。取り組むべきは、既存のフレームワークをエージェント固有の考慮事項に合わせて拡張することです。組織は、セキュアな開発ライフサイクルのプラクティスを AI コンポーネントに適用し、従来のセキュリティ制御を維持する必要があります。また、エージェントの外部にある決定論的な制御によってセキュリティを強制し、体系的な評価を通じてより大きな自律性を獲得していくべきです。 これらの原則は理論上のものではありません。AWS がエージェンティック AI サービスの構築と運用を通じて得た経験を反映したものであり、AWS のインフラストラクチャ設計にも組み込まれています。NIST が業界からの意見を基にガイダンスを策定していく中で、AWS は、お客様がエージェンティック AI システムを安心して構築、運用できるよう支援するための投資を今後も続けていきます。 AWS がお客様の AI ワークロードの保護をどのように支援しているかの詳細については、「 AWS AI Security 」ページをご覧いただくか、「 Amazon response to the CAISI Request for Information regarding Security Considerations for Artificial Intelligence Agents 」をお読みください。 Mark Ryland Mark は AWS の Office of the CISO のディレクターです。テクノロジー業界で 30 年以上の経験を持ち、サイバーセキュリティ、ソフトウェアエンジニアリング、分散システム、技術標準化、公共政策の分野でリーダーを務めてきました。現職に就く前は、AWS World Public Sector チームで Director of Solution Architecture and Professional Services を務めていました。 Riggs Goodman III Riggs は AWS の Principal Solution Architect です。現在は AI セキュリティに注力しており、お客様とパートナーが AWS で AI ワークロードを構築できるよう、技術的なガイダンスとアーキテクチャパターンを提供し、リーダーシップを発揮しています。社内では、お客様とパートナーの課題を解決するため、AWS のサービスチーム全体で技術戦略とイノベーションを推進しています。 Todd MacDermid Todd は Amazon AI Security Group の Principal Security Engineer です。Amazon で 15 年以上にわたり、主に AWS Security に携わってきました。Amazon に入社する前は、10 年間、レッドチームのコンサルティングや、アプリケーションおよびネットワークのセキュリティに従事していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

数字の中には、しばらく向き合ってみないと想像しにくいものもあります。2026 年 10 月 5 日週、プライムデー 2026 のメトリクスを公開しましたが、私が心に残ったのは 2.3 京件です。これは、イベント中に Amazon ElastiCache がピークに達した毎日のリクエスト数です。プライムデーは6月に開催されたため、この投稿はいつも振り返りとして公開されており、その時間差が読む価値を生む要因の1つです。数字があなたのもとに届く頃には、それが実際に起きたという唯一の証拠は、何も問題が起きなかったということだけです。 その週の残りは別の方向に進みました。より小さく、より安く、より制約のある方向です。Claude Haiku 5.5 が Amazon Bedrock で利用可能になり、Haiku 4.5 と比べて約 75 パーセントのコスト削減を実現しました。Amazon Nova 2.5 Sonic は音声エージェントの応答をより素早くし、Strands Box はエージェントが実行できることに対して明確な境界を設けるために登場しました。それでは、10 月 13 日週の AWS ニュースを見ていきましょう… 主なトピック All the numbers: Amazon Prime Day 2026 powered by AWS は、2016 年まで遡る伝統の最新版であり、その規模は依然として頭の中に収めるのが難しいものです。Prime Day の 4 日間で、 Amazon DynamoDB は 59 兆件を超えるリクエストを処理し、ピーク時には 1 秒あたり 1 億 9,200 万件のリクエストに達しましたが、一桁ミリ秒のレスポンスを維持しました。 AWS Lambda は 1 日あたり 2.3 兆件を超える呼び出しを処理しました。 Amazon EBS は 24.8 兆回を超える I/O 操作のピークに達し、毎日 1 エクサバイト以上のデータを転送しました。 Amazon ECS は AWS Fargate 上で 1 日平均 1 億 5,830 万タスクを起動し、前年比 47.7 パーセント増となり、 AWS Graviton は Amazon.com が使用した Amazon EC2 コンピューティングの最大 49 パーセントを支えました。 ただし、私が何度も立ち返ってしまう数字は、スループットの記録ではありません。チームはイベントに先立ち、44,000 件を超える AWS Fault Injection Service 実験を実施しました。これは 2025 年に実施した数の 6 倍以上です。これらは意図的に注入された障害であり、数か月前から仕込まれることで、上記の何兆件ものリクエストが普通の買い物の午後に変わるのです。自社のピークタイムに備えているなら、 AWS Countdown Premium はまさにそのような計画のために作られています。 10 月 5 日週のリリース 10 月 5 日週のリリースのうち、私が注目したものをいくつかご紹介します。 Claude Haiku 5.5 が AWS で利用できるようになりました — Amazon Bedrock と Claude Platform on AWS で、Claude 5.5 ファミリーの最速モデルを利用できるようになりました。ほとんどのタスクで、Claude Haiku 4.5 よりも約 75% 少なくてすみます。effort コントロールを備えた初の Haiku であり、ワークロード全体で 1 つの設定を固定するのではなく、タスクごとにコストと知能のバランスを調整できます。Claude Opus 5.5 と自然に組み合わせられます。Opus が計画を立てて判断を下し、Haiku は高速で安価なため、ルーティング、分類、多数のファイルにまたがる小さなコード変更のために、多くの Haiku サブエージェントを並列で実行できます。 音声エージェント用 Amazon Nova 2.5 Sonic — 音声から音声への Amazon Nova モデルでリアルタイム音声エージェントを構築できるようになりました。これにより、推論、指示の追跡、ツール呼び出しの精度が向上し、レイテンシーも低くなります。この組み合わせはマルチステップの作業に重要です。サポートエージェントは 1 つの会話の中で注文を検索し、返品資格を確認し、返品を開始できます。7 言語での表現力豊かな音声、制御可能なターンテイキング、256K のコンテキストウィンドウを維持し、 now generally available となった Strands Bidi Agents と組み合わせることで、数行のコードで本番用の音声エージェントを起動できます。 Amazon GuardDuty RDS Protection now detects data exfiltration and destruction – Amazon GuardDuty は、 Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL において、ログインの異常を超えてクエリ自体を監視するようになりました。データアクティビティ向け RDS Protection は行動ベースラインを構築し、ML ベースの異常検知と脅威インテリジェンスを組み合わせて異常なデータアクセスを検出します。エージェント、追加インフラストラクチャ、データベース設定の変更は不要です。これにより実際のギャップが埋まります。攻撃者がフィッシングや設定ミスにより有効な認証情報を入手すると、そのクエリはあなたのアプリケーションのクエリと見分けがつかなくなる可能性があります。 AWS Lambda supports OAuth for self-managed Apache Kafka event sources – Amazon Cognito や Okta などのエンタープライズ ID プロバイダーを通じて Lambda Kafka コンシューマーを認証できるようになりました。イベントソースマッピングは以前、SASL/PLAIN、SASL/SCRAM、mTLS のみをサポートしていたため、規制業界のチームは Kafka ESM をまったく使用できませんでした。これにより、Kafka ESM の自動スケーリング、バッチ処理、エラー処理、イベントフィルタリングを、他のあらゆる場所で適用しているのと同じ ID ガバナンスとともに利用できます。セルフホスト型クラスターおよび Confluent Cloud、Aiven、Redpanda などのマネージドサービスで動作します。 Amazon Redshift adds Apache Iceberg materialized views – 高コストな結合と集計を Amazon Redshift で一度事前計算し、その結果を Amazon S3 に Iceberg テーブルとして保存し、 AWS Glue Data Catalog に登録できるようになりました。使い慣れた SQL で作成でき、結果は Amazon Athena 、Apache Spark、Trino、Snowflake など、Iceberg 互換のあらゆるエンジンからすぐにクエリできます。Redshift は変更された部分のみを再計算することで、これらを最新の状態に保ちます。詳細を知りたい場合は、 AWS Big Data ブログの優れた深掘り記事 をご覧ください。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんが興味を持つと思われるその他の記事とリソースをいくつかご紹介します。 Introducing Strands Box: AI agent sandboxes powered by Dogwood – より多くの人が、すべてのステップを承認することなくエージェントにシェルコマンドを実行させたり API を呼び出させたりするようになると、分離だけでは十分ではなくなります。 Strands Box は、OS レベルの封じ込めと Dogwood で記述されたきめ細かいポリシーを組み合わせたオープンソースサンドボックス (Apache 2.0、開発者プレビュー) であり、権限をエージェントがすでに行った内容に依存させることができます。「エージェントにインシデントチャンネルへの投稿を許可するが、10 分間に 3 回まで」と指定し、それをエージェントのプロセス外から強制できます。また、実際の認証情報をエグレスゲートウェイで付与することで、エージェントの環境から認証情報を排除します。 AWS Continuum は、自律型コードセキュリティの新しい標準を打ち立てました – このテーマに関連して、AWS Continuum for Penetration Testing がパブリックプレビューで CI/CD パイプラインに統合されるようになりました 。これにより、ペネトレーションテストは外部で起こることではなく、デプロイ時のイベントに変わりました。開発者は、重大度、影響を受けるエンドポイント、修復ガイダンスを含む検出結果をパイプラインの出力で直接受け取り、パイプラインが修正を検証するために再テストします。 How Postman runs Agent Mode for 40 million developers on Amazon Bedrock – 非常に大規模な開発者オーディエンスにサービスを提供する機能の背後にあるアーキテクチャの紹介です。エージェント機能をデモから実際のトラフィックに耐えうるものへ移行する予定なら、読む価値があります。 ICYMI: 2026 年 9 月に AI ビルダー向けに登場したもの – 数多くのモデルリリースがあった月を見逃した方は、これが一か所でまとめてキャッチアップできる tidy な記事です。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – re:Invent が 11 月 30 日から 12 月 4 日までラスベガスに戻って開催され、予約席が現在受付中です。セッションカタログが公開されたので、 登録 して、チャークトーク、ワークショップ、ビルダーセッションの席が埋まる前に確保しましょう。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンスですが、今はまさに多忙な時期を迎えています。今後の開催地には、 サンフランシスコ (10 月 13 日)、 マイアミ (10 月 14 日)、 ブリスベン (10 月 16 日)、 ケープタウン (10 月 16 日)、 マルタ (10 月 16 日)、 ムンバイ (10 月 17 日) が含まれます。ここブラジルでは、 コミュニティカレンダー に年末までにさらに多くの開催回が追加される予定です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 10 月 13 日週のニュースは以上です。10 月 19 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本記事は 2026 年 10 月 1 日 に公開された「 Working with foreign key constraints in Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は外部キー制約をサポートしているため、アプリケーションの参照整合性をデータベース側で直接保証できます。制約の適用方式は、分散型かつロックを使わないワークロード向けに最適化されています。 PostgreSQL では、外部キーのチェック時に参照先の行に対して FOR KEY SHARE ロックを取得します。そのため、キー列を変更したり行を削除したりするトランザクションは、その行を参照中のトランザクションが終わるまで待たされます。Aurora DSQL は、トランザクションの実行中にストレージのスナップショットに対して外部キー制約をチェックし、同時実行による競合をコミット時に解決するため、行レベルのブロッキングが発生しません。同時実行性やスループットを犠牲にせずに、参照整合性を保証できます。 本記事では、Aurora DSQL での外部キー制約の定義、即時チェックと遅延チェックの設定、ダウンタイムなしで既存テーブルに制約を追加する方法、楽観的同時実行制御 (OCC) で同時実行時の競合を解決する仕組みを説明します。また、スケールしても安全な外部キー (FK) 関係の設計についても取り上げます。EC サイトの注文パイプラインやデータ移行ワークフローといった実践的な例に加えて、OCC の競合に対するアプリケーション側のリトライロジックの指針も紹介します。 ソリューションの概要 Aurora DSQL は、外部キー制約を分散環境向けの検証の仕組みとして実装しています。外部キー関係にかかわるデータをトランザクションが変更すると、Aurora DSQL はステートメントの実行時にスナップショットベースの検証を行い (即時チェックの制約の場合)、コミット時に最終的な判定を行います。コミット済みのトランザクションが外部キー制約に違反することはなく、チェックの実行中にトランザクション同士がブロックし合うこともありません。 Aurora DSQL の外部キーサポートの主な特徴: PostgreSQL 互換の構文: 標準の REFERENCES 句と FOREIGN KEY 句を使用できます。すべての参照アクション (NO ACTION、RESTRICT、CASCADE、SET NULL、SET DEFAULT)、両方のマッチタイプ (デフォルトの MATCH SIMPLE と MATCH FULL)、遅延可能な制約をサポートしています。 OCC ベースの競合検出: 行レベルのブロッキングはありません。参照整合性はステートメントの実行時にスナップショットに対して検証され、競合は楽観的同時実行制御によってコミット時に解決されます。 キー以外の列の更新に対する最適化: Aurora DSQL は、暗黙的な KEY SHARE によって参照先のキー列を追跡します。同時に実行される FK チェックと競合するのは、キー列の変更だけです。 非同期の ALTER TABLE: NOT VALID を指定して既存テーブルに外部キーを追加し、 ALTER TABLE ASYNC ... VALIDATE CONSTRAINT で非同期に検証できます。ダウンタイムなしでスキーマを変更できます。 重要: カスケードアクション (CASCADE、SET NULL、SET DEFAULT) は、参照先の行が更新または削除されたときに、参照元テーブルの行を自動的に変更します。カスケードアクションには Aurora DSQL のトランザクションあたりの行数制限が適用されるため、注意して使わないと予期しない失敗の原因になります。子行の数に上限がない、または予測できない外部キー関係では、NO ACTION または RESTRICT を使用してください。詳細については、Aurora DSQL ユーザーガイドの「Aurora DSQL のデータベースの制限」を参照してください。 前提条件 本記事の手順を試すには、以下が必要です。 AWS アカウントの要件: Aurora DSQL クラスターが稼働している有効な AWS アカウント Aurora DSQL では、すべての接続で Transport Layer Security (TLS) による暗号化が必要です。安全に接続するには、クライアントシステムが Amazon Root Certificate Authority (Amazon Root CA 1) を信頼している必要があります。 必要な権限: 外部キー制約付きのテーブルを作成するための、スキーマに対する CREATE 権限 既存テーブルに制約を追加するための ALTER 権限 制約を削除するための DROP 権限 必要なツールとソフトウェア: PostgreSQL 互換のクライアント (psql、DBeaver、またはアプリケーションのデータベースドライバー) Aurora DSQL エンドポイントに接続できるように設定された SQL クライアント 外部キー制約付きのテーブルを作成する 外部キーは、標準の PostgreSQL 構文で、列へのインライン指定またはテーブルレベルの制約として定義します。 列制約のインライン構文 単一列の外部キーでは、列定義に REFERENCES キーワードを直接指定します。 CREATE TABLE customers ( customer_id INT PRIMARY KEY, name TEXT NOT NULL, email VARCHAR(255) UNIQUE ); CREATE TABLE orders ( order_id INT PRIMARY KEY, customer_id INT REFERENCES customers(customer_id), order_date DATE DEFAULT CURRENT_DATE, total_amount DECIMAL(10,2) ); 列リストを省略すると、Aurora DSQL は参照先テーブルの主キーを使用します。 CREATE TABLE orders ( order_id INT PRIMARY KEY, customer_id INT REFERENCES customers, order_date DATE DEFAULT CURRENT_DATE, total_amount DECIMAL(10,2) ); 名前付きのテーブルレベル制約の構文 複合外部キーや遅延可能な制約が必要な場合は、CONSTRAINT … FOREIGN KEY 構文を使用します。 CREATE TABLE products ( product_no INTEGER PRIMARY KEY, name TEXT UNIQUE, price NUMERIC ); CREATE TABLE order_items ( order_id INTEGER PRIMARY KEY, product_no INTEGER, quantity INTEGER, CONSTRAINT fk_product FOREIGN KEY (product_no) REFERENCES products (product_no) DEFERRABLE INITIALLY IMMEDIATE ); 複合外部キーの例 複合主キーや複合一意制約を参照する場合、外部キーを複数の列にまたがって定義できます。 CREATE TABLE inventory ( warehouse_id INTEGER, product_no INTEGER, quantity INTEGER, PRIMARY KEY (warehouse_id, product_no) ); CREATE TABLE shipments ( shipment_id INTEGER PRIMARY KEY, warehouse_id INTEGER, product_no INTEGER, FOREIGN KEY (warehouse_id, product_no) REFERENCES inventory (warehouse_id, product_no) ); 自己参照の外部キー 外部キー制約では、制約が属するテーブル自体を参照することもできます。たとえば、ツリー構造は次のように表現できます。 CREATE TABLE tree ( node_id INTEGER PRIMARY KEY, parent_id INTEGER REFERENCES tree, name TEXT ); 最上位のノードは parent_id が NULL になります。parent_id が NULL でない行は、テーブル内の有効な行を参照するよう制約されます。 参照アクションの例 参照先の行が削除または更新されたときの動作を指定できます。 CREATE TABLE orders ( order_id INTEGER PRIMARY KEY, product_no INTEGER REFERENCES products ON DELETE RESTRICT, quantity INTEGER ); RESTRICT を指定すると、注文から参照されている製品を削除しようとした時点ですぐにエラーになります。デフォルトの NO ACTION では、制約が DEFERRABLE として宣言されていれば、チェックをトランザクションの終了時まで遅延できます。 既存テーブルに外部キーを追加する 既存テーブルには、ALTER TABLE … ADD CONSTRAINT … NOT VALID で外部キー制約を追加できます。NOT VALID オプションを指定すると、既存データを検証せずに制約を追加するため、データ定義言語 (DDL) の実行時にテーブル全体をスキャンせずに済みます。 ALTER TABLE order_items ADD CONSTRAINT fk_product FOREIGN KEY (product_no) REFERENCES products (product_no) NOT VALID; 制約の追加後は、新しいデータ操作言語 (DML) の操作が制約に対して検証されます。書き込みをブロックせずに既存データを非同期で検証するには、次のようにします。 ALTER TABLE ASYNC order_items VALIDATE CONSTRAINT fk_product; 既存の制約の遅延可否を変更することもできます。 ALTER TABLE order_items ALTER CONSTRAINT fk_product DEFERRABLE INITIALLY DEFERRED; 外部キー制約を管理する 設定した制約は、削除したり内容を確認したりできます。 制約を削除する テーブルから外部キー制約を削除するには、次のようにします。 ALTER TABLE order_items DROP CONSTRAINT fk_product; 外部キー制約を確認する システムカタログをクエリして、外部キーの定義を確認します。 SELECT conname AS constraint_name, conrelid::regclass AS child_table, confrelid::regclass AS parent_table, pg_get_constraintdef(oid) AS definition FROM pg_constraint WHERE contype = 'f'; 制約の即時チェック 制約のタイミングが即時 (デフォルト) に設定されている場合、Aurora DSQL はステートメントの実行時にトランザクションのスナップショットをクエリして参照整合性を検証します。違反はその場で拒否されます。 有効な挿入は成功する INSERT INTO products VALUES (1, 'Laptop', 999.99); INSERT INTO products VALUES (2, 'Mouse', 29.99); INSERT INTO products VALUES (3, 'Keyboard', 79.99); -- Valid order referencing an existing product succeeds. INSERT INTO order_items VALUES (100, 1, 2); 存在しない親を参照するとすぐに失敗する -- Order for non-existent product fails immediately. INSERT INTO order_items VALUES (101, 999, 1); -- ERROR: insert or update on table "order_items" violates foreign key constraint "fk_product" 参照されている親行の削除は失敗する DELETE FROM products WHERE product_no = 1; -- ERROR: update or delete on table "products" violates foreign key constraint "fk_product" on table "order_items" 子行が孤立するような親の主キーの更新は失敗する UPDATE products SET product_no = 99 WHERE product_no = 1; -- ERROR: update or delete on table "products" violates foreign key constraint "fk_product" on table "order_items" 参照されていない親行は削除できる -- Product 3 has no orders referencing it. DELETE FROM products WHERE product_no = 3; -- OK 制約の遅延チェック 制約が遅延可能として定義されていれば、トランザクション内で SET CONSTRAINTS を使って遅延チェックに切り替えられます。遅延させると検証はコミット時に移るため、親より先に子行を挿入し、コミットまでに制約を満たせば問題ありません。データのロード時や、複数のステートメントからなる複雑なトランザクションで役立ちます。 注: Aurora DSQL では、SET CONSTRAINTS は外部キー制約にのみ適用されます。主キー、一意、NOT NULL、CHECK の各制約は常に即時チェックされ、遅延できません。 参照先の行より先に参照元の行を挿入する BEGIN; SET CONSTRAINTS fk_product DEFERRED; INSERT INTO order_items VALUES (200, 80, 1); -- product 80 doesn't exist yet INSERT INTO products VALUES (80, 'Monitor', 349.99); COMMIT; -- OK: constraint satisfied at commit time コミット時の遅延チェックでの違反 COMMIT までに違反が解消されない場合、トランザクション全体がロールバックされます。 BEGIN; SET CONSTRAINTS fk_product DEFERRED; INSERT INTO order_items VALUES (201, 777, 1); -- product 777 never created COMMIT; -- ERROR: insert or update on table "order_items" violates foreign key constraint "fk_product" -- entire transaction rolled back すべての外部キー制約をまとめて遅延させる SET CONSTRAINTS ALL DEFERRED を実行すると、トランザクション内の遅延可能な外部キー制約がすべて遅延されます。 BEGIN; SET CONSTRAINTS ALL DEFERRED; INSERT INTO order_items VALUES (202, 90, 1); INSERT INTO products VALUES (90, 'Speakers', 129.99); COMMIT; -- OK トランザクションの途中で即時チェックに戻す トランザクション内で制約を IMMEDIATE に戻すと、スナップショットに対する検証が強制的に実行されます。Aurora DSQL は、遅延していた未チェックのデータ変更をその時点でチェックします。 BEGIN; SET CONSTRAINTS fk_product DEFERRED; INSERT INTO order_items VALUES (203, 888, 1); -- no error yet (deferred) SET CONSTRAINTS fk_product IMMEDIATE; -- triggers check NOW -- ERROR: insert or update on table "order_items" violates foreign key constraint "fk_product" ROLLBACK; 同時実行と OCC の動作 Aurora DSQL は、ロックを使わない同時実行制御の仕組みである OCC を採用しています。そのため、従来の PostgreSQL 環境でよく見られる行レベルのブロッキング、デッドロック、ロック待ちのタイムアウトが発生しません。行の読み書き時にロックを取得する代わりに、各トランザクションは開始時点で取得したデータベースの一貫したスナップショットに対して処理を行います。複数のトランザクションが互いを待つことなく、同じ行を同時に読み書きできます。同時に実行された 2 つのトランザクションが同じデータに競合する形でアクセスしたかどうかは、コミット時に初めて Aurora DSQL のアジュディケータが判定します。競合が見つかると、一方のトランザクションは成功し、もう一方はシリアル化エラー ( SQLSTATE 40001 ) で失敗します。アプリケーションは失敗したトランザクションをリトライできます。 Aurora DSQL は、2 つのステップで参照整合性を維持します。 スナップショットによる検証 : すべてのトランザクションは、開始時点で取得した一貫したスナップショットに対して実行されます。参照元の行を挿入すると、Aurora DSQL はそのスナップショット時点の参照先テーブルを読み取り、参照先のキーが存在することを確認します。参照先のキーを削除または更新すると、Aurora DSQL はそのスナップショット時点の参照元テーブルを読み取ります。RESTRICT の場合は参照元の行が存在しないこと、NO ACTION の場合は操作によって孤立する行が残らないことを確認します。 コミット時の競合解決 : スナップショットによる検証で分かるのは、トランザクションの開始時点で制約が満たされていたことだけです。その後、同時に実行された別のトランザクションが参照先のデータを変更している可能性があります。Aurora DSQL はコミット時に、同時実行中のトランザクションが自分のトランザクションの参照整合性に影響を与えたかどうかを検出し、競合があれば OCC エラーでトランザクションを失敗させます。 重要: 参照先または参照元のテーブルに対する DML はすべて、参照整合性を維持するための追加の読み取りを伴います。テーブルに外部キー制約を追加する前に、ワークロードのベンチマークを行い、性能特性が想定どおりであることを確認してください。 -- Seed the products used by the concurrency examples INSERT INTO products VALUES (4, 'Cable', 9.99); INSERT INTO products VALUES (5, 'Dock', 199.99); INSERT INTO products VALUES (6, 'Charger', 19.99); 親の DELETE と子の INSERT の同時実行: 競合する -- Session A: BEGIN; DELETE FROM products WHERE product_no = 4; COMMIT; -- succeeds -- Session B (started concurrently, before Session A committed): BEGIN; INSERT INTO order_items VALUES (103, 4, 1); COMMIT; -- ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) 2 つのセッションは同時に実行されます。Aurora DSQL はコミット時に競合を解決するため、削除済みの製品を指す注文が残ることはありません。 親の主キーの UPDATE と子の INSERT の同時実行: 競合する -- Session A: BEGIN; UPDATE products SET product_no = 50 WHERE product_no = 5; COMMIT; -- Session B (concurrent): BEGIN; INSERT INTO order_items VALUES (104, 5, 1); COMMIT; -- ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) キー以外の列の更新が競合しない理由 競合を判定するために、Aurora DSQL は参照先の行に対して暗黙的に KEY SHARE の追跡を適用します。同時に実行中の外部キーチェックを無効にするのは、キー列 (PRIMARY KEY の列、または部分インデックスや式インデックスではない UNIQUE インデックスの列) の変更だけです。製品の価格のようなキー以外の列を更新しても、その製品を参照する新しい子行の挿入とは競合しません。 キー以外の列 (price) の更新: 競合しない -- Session A: BEGIN; UPDATE products SET price = 29.99 WHERE product_no = 6; COMMIT; -- succeeds -- Session B (concurrent): BEGIN; INSERT INTO order_items VALUES (105, 6, 1); COMMIT; -- succeeds -- Updating price (a non-key column) doesn't conflict with the foreign key on product_no. キー列 (UNIQUE インデックスを持つ name) の更新: 競合する -- Session A: BEGIN; UPDATE products SET name = 'Fast Charger' WHERE product_no = 6; COMMIT; -- Session B (concurrent): BEGIN; INSERT INTO order_items VALUES (108, 6, 1); COMMIT; -- ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) products テーブルの name は TEXT UNIQUE として宣言されたキー列なので、競合が発生します。 同じ親に対する複数の子行の挿入: 誤った競合は起きない 同じ親を参照する子行を 2 つのトランザクションが同時に挿入しても、互いに競合しません。 -- Session A: BEGIN; INSERT INTO order_items VALUES (106, 2, 1); COMMIT; -- Session B (concurrent): BEGIN; INSERT INTO order_items VALUES (107, 2, 2); COMMIT; -- OK: both succeed 人気のある親行 (売れ筋の製品など) に対して数千件の子行の挿入が同時に行われても、競合は発生しません。 スケールを考慮した設計 注: ここから先の例では、前のセクションで作成したテーブルとは別の、UUID ベースのスキーマを使用します。実際に試す場合は、先に前のテーブルを削除するか、新しいセッションを使用してください。 従来のデータベースでは、上限のない一対多 (1:M) の外部キー関係があると、テーブルロック、インデックスの肥大化、削除の遅延といったリスクがあります。Aurora DSQL では OCC によってロックのリスクはなくなりますが、性能とコストのリスクは残ります。さらに、Aurora DSQL ではトランザクションで変更できる行数が 3,000 行に制限されているため、CASCADE アクションがかかわる場合は特に注意が必要です。 外部キーを追加する前に、その関係が今後どのようにスケールするかを検討してください。 スケールしても問題にならない関係 次の関係は件数が自然に抑えられるため、規模が大きくなっても問題になりません。 厳密な一対一 (1:1): 子テーブルが UNIQUE な外部キーで親を参照します。子が親より大きくなることはありません (例: user_id を使った users → user_profiles)。 多対一の参照: 数百万の行が、静的またはゆっくりとしか増えない設定テーブルを参照します。増えるのは「多」の側で、親の件数は抑えられたままです (例: 小さな countries テーブルを参照する数百万のユーザー)。子行を挿入するたびに親行に対する検証が行われます。親のキー以外の列 (国の display_name など) の更新は競合せずに処理されます。ただし、親のキー列 (参照される country_id など) を更新すると、同時に実行中の子行の挿入と競合します。そのため、頻繁に参照される参照用の行のキー列は、事実上変更できなくなります。通常はこれが望ましい動作です。参照テーブルのキーは安定しているべきで、変更が必要な属性はキー以外の列に持たせます。 上限のある一対多: 子テーブルは親 1 件に対して複数の行を持てますが、現実的な制約によって件数は少なく抑えられます (例: orders → order_items。一般的なショッピングカートの商品数は数十件程度です)。削除の影響を受ける子行の数に上限があるため、この場合は CASCADE を安全に使えます。 規模が爆発的に大きくなるリスクのある関係 問題を引き起こすのは次のような関係です。子の側に上限がなく、1 つの親行に時間とともに数百万の子行が蓄積されることがあります。 グローバルな「何でも紐付ける」アンカー: 大量のログ、監査、イベントデータを、1 つのテナントやユーザーに直接紐付けるケースです (例: 利用の多い法人アカウントが audit_logs テーブルの数十億行のアンカーになる)。Aurora DSQL では、この親に対する CASCADE 削除はトランザクションの行数制限を超えて失敗します。 急激に拡散するエンゲージメント機能: ユーザーのアクティビティを 1 つのコンテンツに直接紐付けるケースです。1 件の投稿が話題になると post_likes に数百万行が蓄積されることがあり、その投稿に対する CASCADE 削除はトランザクションの行数制限を超えます (例: posts の人気のある 1 行が、突然 post_likes の 10,000,000 行のアンカーになる)。子行を挿入するたびに、その 1 つの親行に対して FK 検証の読み取りが発生します。量が多くなると、無視できないコストになります。 大量に売れる製品: EC サイトでは、products → order_items の関係は爆発的に大きくなりがちです。1 つの人気製品 (あるいは全注文に共通する「送料」項目) が、過去の数百万件の注文行のアンカーになることがあります。CASCADE 削除を実行すると、その製品の過去の注文明細をすべて削除しようとして失敗します。 Aurora DSQL 固有の影響: Aurora DSQL では、上限のない FK 関係があると、子行の挿入や親行の更新のたびに FK 検証のための追加の読み取りコストが発生します。また、子行の同時挿入中に親のキー列が変更されると OCC の競合が発生します。 Aurora DSQL 向けのアーキテクチャ上の対策 関係に上限がなくなる可能性がある場合は、次の対策を適用します。 1. 上限のないキーには CASCADE を使わない。 件数の多い外部キー (product_id や tenant_id など) では ON DELETE CASCADE を避けてください。Aurora DSQL では、数千の子行を持つ親を削除するとトランザクションの行数制限を超えて失敗します。代わりに論理削除 ( is_active = false ) を使い、子行はバックグラウンドのトランザクションでバッチ処理してクリーンアップします。 -- AVOID: CASCADE on unbounded relationship CREATE TABLE order_items ( line_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), product_id UUID REFERENCES products ON DELETE CASCADE, -- dangerous at scale quantity INTEGER ); -- PREFERRED: RESTRICT + soft-delete pattern CREATE TABLE order_items ( line_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), product_id UUID REFERENCES products ON DELETE RESTRICT, quantity INTEGER ); -- Soft-delete the product instead of hard-deleting: UPDATE products SET is_active = false WHERE product_id = 'prod-xyz'; -- replace with actual UUID -- Clean up old order_items in batched transactions (≤3,000 rows each) 2. 変わりうる属性は書き込み時にスナップショットとして保存する。 注文のようなトランザクションデータでは、時間とともに変わる属性 (price や product_name など) を、トランザクションの実行時に子テーブルへ直接コピーします。親テーブルの現在の状態に頼らずに、顧客が実際に支払った金額や注文時の製品名を残せます。sku のように変わらない識別子は親テーブルにだけ持たせれば十分で、FK による参照で事足ります。 CREATE TABLE order_items ( line_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), order_id UUID REFERENCES orders, product_id UUID REFERENCES products, quantity INTEGER NOT NULL, -- Snapshot mutable attributes at order time unit_price NUMERIC NOT NULL, product_name TEXT NOT NULL, created_at TIMESTAMPTZ DEFAULT NOW() ); 3. クエリにはページネーションと期間の制限を必ず付ける。 SELECT * FROM order_items WHERE product_id = X のような範囲を限定しないクエリは許可しないでください。期間の制限やカーソルベースのフィルターを必ず使います。タイムスタンプを比較する際に両辺のデータ型をそろえると、クエリプランナーがインデックスを効果的に使えます。 -- AVOID: unbounded query without time bounds or pagination SELECT * FROM order_items WHERE product_id = 'prod-xyz'; -- replace with actual UUID -- PREFERRED: time-bounded with index support SELECT * FROM order_items WHERE product_id = 'prod-xyz' -- replace with actual UUID AND created_at >= NOW() - INTERVAL '30 days' ORDER BY created_at DESC LIMIT 100; 4. 固定の列挙値には、FK による参照ではなく CHECK 制約を使う。 カーディナリティの低いテーブル (ステータスコード、種別、カテゴリなど) を参照すると、挿入のたびに FK 検証の負荷がかかりますが、値が変わることはないため実質的なメリットはありません。 -- AVOID: FK to a 5-row lookup table CREATE TABLE task_statuses (status_id INT PRIMARY KEY, label TEXT); CREATE TABLE tasks (task_id UUID PRIMARY KEY, status_id INT REFERENCES task_statuses); -- PREFERRED: CHECK constraint (no FK overhead, no parent-row reads) CREATE TABLE tasks ( task_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), status VARCHAR(20) CHECK (status IN ('open', 'in_progress', 'done', 'blocked', 'cancelled')) ); 実践的な例 ここまでのセクションでは構文と動作を説明しました。以下のシナリオでは、本番環境でそれらをどのように組み合わせるかを紹介します。 EC サイトの注文パイプライン スケールを考慮した FK 設計のスキーマ: CREATE TABLE customers ( customer_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name TEXT NOT NULL, email VARCHAR(255) UNIQUE ); CREATE TABLE products ( product_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), sku VARCHAR(50) UNIQUE, name TEXT, price NUMERIC, is_active BOOLEAN DEFAULT true -- soft-delete instead of hard-delete ); CREATE TABLE orders ( order_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id UUID REFERENCES customers, status VARCHAR(20) DEFAULT 'pending', created_at TIMESTAMPTZ DEFAULT NOW() ); CREATE TABLE order_lines ( line_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), order_id UUID, product_id UUID REFERENCES products ON DELETE RESTRICT, -- unbounded: never CASCADE quantity INTEGER NOT NULL, -- Snapshot mutable attributes at order time unit_price NUMERIC NOT NULL, product_name TEXT NOT NULL, created_at TIMESTAMPTZ DEFAULT NOW(), CONSTRAINT fk_order FOREIGN KEY (order_id) REFERENCES orders (order_id) ON DELETE CASCADE -- bounded: safe to CASCADE DEFERRABLE INITIALLY DEFERRED ); このスキーマには、前述の「スケールを考慮した設計」の対策を適用しています。CASCADE は上限のある関係 (orders → order_lines) だけに使い、上限のない関係 (products → order_lines) には RESTRICT を使っています。また、製品データは注文時にスナップショットとして保存しています。 遅延制約を使った注文の登録: fk_order 制約は DEFERRABLE INITIALLY DEFERRED なので、親の注文行より先に注文明細を挿入できます。また、注文時の製品名と価格をスナップショットとして保存します。 -- Setup: seed the referenced parents first INSERT INTO customers (customer_id, name, email) VALUES ('d3eebc99-9c0b-4ef8-bb6d-6bb9bd380a44', 'Alice', 'alice@example.com'); INSERT INTO products (product_id, sku, name, price) VALUES ('b1eebc99-9c0b-4ef8-bb6d-6bb9bd380a22', 'WM-100', 'Wireless Mouse', 49.99), ('c2eebc99-9c0b-4ef8-bb6d-6bb9bd380a33', 'HUB-200', 'USB-C Hub', 129.99); -- Now place an order with deferred FK on order_id BEGIN; -- Insert order lines first (fk_order to orders is deferred; product FKs are immediate -- but the products already exist above, so they pass instantly) INSERT INTO order_lines (order_id, product_id, quantity, unit_price, product_name) VALUES ('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11', 'b1eebc99-9c0b-4ef8-bb6d-6bb9bd380a22', 2, 49.99, 'Wireless Mouse'), ('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11', 'c2eebc99-9c0b-4ef8-bb6d-6bb9bd380a33', 1, 129.99, 'USB-C Hub'); -- Insert the order header (satisfies the deferred fk_order at commit) INSERT INTO orders (order_id, customer_id, status) VALUES ('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11', 'd3eebc99-9c0b-4ef8-bb6d-6bb9bd380a44', 'pending'); COMMIT; -- OK: fk_order validated at commit time; product FKs were checked immediately and passed Aurora DSQL Loader によるデータ移行 別のデータベースからデータを移行する場合は、Aurora DSQL Loader の使用をお勧めします。Aurora DSQL Loader はオープンソースの CLI で、並列化、コネクションプーリング、競合とリトライの処理、AWS Identity and Access Management (IAM) 認証を担います。Aurora DSQL では、前述の行数の制限に加えて、書き込みトランザクションあたりの変更データ量が 10 MiB、実行時間が 5 分に制限されています。Loader はこれら 3 つの制限の範囲内に収まるよう、自動的にバッチ処理します。 ステップ 1: 移行元のデータベースからデータをエクスポートする -- From PostgreSQL: COPY customers TO '/export/customers.csv' WITH (FORMAT csv, HEADER true); COPY products TO '/export/products.csv' WITH (FORMAT csv, HEADER true); COPY orders TO '/export/orders.csv' WITH (FORMAT csv, HEADER true); COPY order_lines TO '/export/order_lines.csv' WITH (FORMAT csv, HEADER true); ステップ 2: 親テーブルを先にロードし、次に子テーブルをロードする # Load parent tables first (no FK dependencies) aurora-dsql-loader load \ --endpoint cluster-id.dsql.us-east-1.on.aws \ --source-uri /export/customers.csv \ --table customers aurora-dsql-loader load \ --endpoint cluster-id.dsql.us-east-1.on.aws \ --source-uri /export/products.csv \ --table products # Load child tables after parents are loaded aurora-dsql-loader load \ --endpoint cluster-id.dsql.us-east-1.on.aws \ --source-uri /export/orders.csv \ --table orders aurora-dsql-loader load \ --endpoint cluster-id.dsql.us-east-1.on.aws \ --source-uri /export/order_lines.csv \ --table order_lines 別の方法: FK なしでロードし、後から制約を追加する ロード時間を短縮するには、ロード中は FK 制約を設定せず、後から追加します。 -- Step 1: Load all data (no FK constraints yet - maximum throughput) -- Use aurora-dsql-loader for each table in any order -- Step 2: Add constraints without validating existing data (instant DDL) ALTER TABLE order_lines ADD CONSTRAINT fk_order FOREIGN KEY (order_id) REFERENCES orders (order_id) NOT VALID; -- Step 3: Validate existing data asynchronously (non-blocking) ALTER TABLE ASYNC order_lines VALIDATE CONSTRAINT fk_order; -- Step 4: Monitor progress SELECT * FROM sys.jobs WHERE job_type = 'VALIDATE_CONSTRAINT'; -- Or block the session until validation completes: CALL sys.wait_for_job('<job_id>'); FK を後から追加する 2 段階の方法では、取り込み時に FK の負荷がかからないため初回ロードが速くなり、本番稼働の前に参照整合性も検証できます。 OCC の競合に対するアプリケーションのリトライロジック Aurora DSQL は OCC を使うため、競合するトランザクションはロックを待つのではなく、コミット時に SQLSTATE 40001 で失敗します。アプリケーション側でこのエラーを処理する必要があります。Aurora DSQL では、次の 2 種類の競合を区別しています。 OC000 (データの競合): 2 つのトランザクションが同じ行を変更しました。トランザクション全体をリトライしてください。 OC001 (スキーマの競合): セッションにキャッシュされたスキーマが古くなっています (同時に実行された DDL の後など)。セッションがカタログキャッシュを更新するため、通常は 1 回のリトライで成功します。 Aurora DSQL のリトライロジックの基本原則: 常にトランザクション全体をリトライする: 40001 エラーの後、トランザクションはロールバックされています。BEGIN から再実行してください。 ジッター付きのエクスポネンシャルバックオフを使う: リトライまでの待機時間にランダム性を持たせるとリトライのタイミングが分散し、次の試行で同じトランザクション同士が再び衝突する可能性を下げられます。 リトライすべきエラーを見極める: SQLSTATE 40001 は OCC の競合なので、トランザクションをリトライします。スキーマの競合 ( OC001 ) は、セッションが最新のカタログを取得するため、通常は最初のリトライで解消されます。一方、外部キー違反 ( 23503 ) は一時的な競合ではなく、データ自体の問題です。リトライしても解決しないため、アプリケーションのロジックを確認してください。 リトライ回数に上限を設け、発生率を監視する: ワークロードに合ったリトライ回数の上限を設定します。上限に達しても失敗する場合、一時的な競合ではなく、同時書き込みが集中しすぎているホットな親行が原因と考えられます。本番環境では 40001 エラーの発生率を追跡してください。発生率が継続的に上がっている場合は、スキーマの見直しが必要です (前述の「スケールを考慮した設計」を参照)。 クリーンアップ 本記事で作成したリソースを削除するには、次を実行します。 -- Drop children before parents (respecting FK dependencies) DROP TABLE IF EXISTS order_lines; DROP TABLE IF EXISTS order_items; DROP TABLE IF EXISTS shipments; DROP TABLE IF EXISTS tasks; DROP TABLE IF EXISTS task_statuses; DROP TABLE IF EXISTS orders; DROP TABLE IF EXISTS inventory; DROP TABLE IF EXISTS products; DROP TABLE IF EXISTS tree; DROP TABLE IF EXISTS customers; まとめ Aurora DSQL の外部キー制約を使うと、参照整合性をアプリケーションコードではなくデータベースのレベルで保証できます。Aurora DSQL は行レベルのロックではなく OCC を使うため、同時実行されるトランザクションは互いをブロックせずに処理され、競合はコミット時に検出されます。また、キー以外の列の更新が外部キーチェックに影響することはありません。遅延チェック、制約の非同期検証、本記事で紹介したスケールを考慮した設計パターンを活用すれば、高スループットの分散ワークロードでも安心して外部キーを導入できます。詳細については、 Aurora DSQL ユーザーガイド の「 同時実行制御 」のページを参照してください。 著者について Rekha Reddy Anupati AWS のデータベーススペシャリストソリューションアーキテクトです。AWS のマネージドデータベースサービスを使った、スケーラブルなデータベースソリューションの設計と実装をお客様と共に進めています。 Arnab Chowdhury AWS のデータベーススペシャリストソリューションアーキテクトです。AWS 上でのデータベースアーキテクチャの設計、移行、最適化を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。