本日の主なトピック #
- Claude Opus 4.6: Amazon Bedrock で利用可能に。コーディングやエージェントタスクに最適な最上位モデル。
- EC2 新インスタンス: 第8世代 (C8id, M8id, R8id) が一般提供開始。G7e がオレゴンで、U7i-6TB が GovCloud で利用可能に。
- ECS: NLB を使用するサービスで、リニアおよびカナリアデプロイメントをネイティブサポート。
- AWS Batch: Amazon EKS 上のアンマネージドコンピューティング環境をサポートし、インフラの完全な制御が可能に。
- Bedrock: 構造化出力 (Structured Outputs) をサポートし、JSON スキーマに準拠したレスポンス生成が容易に。
¥3,520 Amazonで見る
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本(ソフトカバー) – 2025/7/11
Amazon EC2 C8id, M8id, および R8id インスタンスの導入 #
投稿日: 2026年02月04日
何ができるようになったのか #
カスタム Intel Xeon 6 プロセッサを搭載した新しい Amazon EC2 インスタンス、C8id(コンピューティング最適化)、M8id(汎用)、R8id(メモリ最適化)の一般提供が開始されました。 これらのインスタンスは、最大 384 vCPU、3TiB のメモリ、および前世代の3倍となる 22.8TB の NVMe SSD ストレージを提供します。 また、インスタンス帯域幅設定 (Instance Bandwidth Configuration) をサポートしており、ネットワーク帯域と EBS 帯域の間でリソースを 25% 柔軟に割り当てることが可能です。
何が嬉しいのか #
前世代(C6id, M6id, R6id)と比較して、最大 43% のパフォーマンス向上と 3.3倍のメモリ帯域幅を実現しています。 I/O 負荷の高いデータベースワークロードでは最大 46% のパフォーマンス向上、リアルタイムデータ分析では最大 30% のクエリ高速化が見込まれます。 さらに、インスタンス帯域幅設定により、ワークロードの特性に合わせてリソースを最適化できるため、効率的な運用が可能です。
これまでとどう変わるのか #
- これまで: 第6世代の C6id, M6id, R6id インスタンスが利用されていました。ストレージ容量やメモリ帯域幅には制限があり、ネットワークとEBS帯域幅の割り当ては固定されていました。
- これから: 第8世代となり、Intel Xeon 6 プロセッサによる処理能力の向上に加え、ローカル NVMe SSD ストレージ容量が3倍に増加しました。また、帯域幅の柔軟な割り当てが可能になったことで、ネットワーク集約型やストレージ集約型など、変動する要件に動的に対応しやすくなりました。
具体的なユースケース #
- C8id: 高性能 Web サーバー、バッチ処理、分散分析、広告配信、ビデオエンコーディング、ゲームサーバーなどの計算集約型ワークロード。
- M8id: アプリケーションサーバー、マイクロサービス、エンタープライズアプリケーション、中規模データベースなどのバランス型ワークロード。
- R8id: インメモリデータベース、リアルタイムビッグデータ分析、大規模インメモリキャッシュ、科学計算などのメモリ集約型ワークロード。
Amazon EC2 G7e インスタンスが米国西部 (オレゴン) リージョンで利用可能になりました #
投稿日: 2026年02月04日
何ができるようになったのか #
NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載した Amazon EC2 G7e インスタンス が、米国西部 (オレゴン) リージョンで利用可能になりました。
何が嬉しいのか #
G7e インスタンスは、前世代の G6e と比較して最大 2.3倍の推論パフォーマンスを提供します。 GPU あたり 96 GB のメモリを搭載し、最大 8 つの GPU 構成が可能なため、大規模言語モデル (LLM)、エージェント型 AI、マルチモーダル生成 AI、物理 AI モデルのデプロイに最適です。また、空間コンピューティングや、グラフィックス処理と AI 処理の両方を必要とするワークロードにおいて最高のパフォーマンスを発揮します。
これまでとどう変わるのか #
- これまで: G7e インスタンスは米国東部 (バージニア北部) および米国東部 (オハイオ) で利用可能でしたが、米国西部リージョンでは利用できませんでした。
- これから: 米国西部 (オレゴン) リージョンでも利用可能になり、同地域のユーザーや、地理的冗長性を必要とするワークロードでの選択肢が広がりました。
具体的なユースケース #
- 大規模な生成 AI モデルの推論およびファインチューニング。
- 3DレンダリングとAI処理を組み合わせた高度なデジタルツインやシミュレーション。
- 複数の GPU 間での高速通信(NVIDIA GPUDirect P2P および RDMA サポート)を活用した、小規模なマルチノード分散処理。
Amazon EC2 ハイメモリ U7i-6TB インスタンスが AWS GovCloud (米国西部) で利用可能になりました #
投稿日: 2026年02月05日
何ができるようになったのか #
6TB のメモリを搭載した Amazon EC2 ハイメモリ U7i インスタンス (u7i-6tb.112xlarge) が、AWS GovCloud (米国西部) リージョンで利用可能になりました。
何が嬉しいのか #
U7i インスタンスは第4世代 Intel Xeon スケーラブルプロセッサ (Sapphire Rapids) を搭載し、6TiB の DDR5 メモリを提供します。 これにより、急速に増大するデータ環境においてもトランザクション処理のスループットをスケールさせることが可能です。 また、最大 100 Gbps の EBS 帯域幅とネットワーク帯域幅をサポートし、データのロードやバックアップを高速化します。
これまでとどう変わるのか #
- これまで: AWS GovCloud (米国西部) では、最新世代である U7i の 6TB メモリモデルが利用できませんでした。
- これから: 政府機関や規制の厳しい業界の顧客が、GovCloud 環境内で SAP HANA、Oracle、SQL Server などのミッションクリティカルなインメモリデータベースを実行するために、最新の高性能な大容量メモリインスタンスを利用できるようになりました。
具体的なユースケース #
- 大規模な SAP HANA インメモリデータベースのホスティング。
- 公共部門における、高速なデータアクセスを必要とする大規模データ分析基盤。
Amazon ECS が Network Load Balancer (NLB) を使用したリニアおよびカナリアデプロイメントのサポートを追加 #
投稿日: 2026年02月04日
何ができるようになったのか #
Amazon ECS は、Network Load Balancer (NLB) を使用するサービスに対して、リニア (Linear) および カナリア (Canary) デプロイメント戦略のネイティブサポートを開始しました。 これにより、TCP/UDP ベースの接続、低遅延、長期間の接続、または静的 IP アドレスを必要とするアプリケーションにおいても、ECS から直接、管理された段階的なトラフィックシフトを利用してアップデートを展開できるようになりました。
何が嬉しいのか #
新しいバージョンへの移行時に、トラフィックを段階的(例: 10%ずつ増加)に移行したり、最初に少量のトラフィック(カナリア)で検証してから全展開するといった制御が可能になります。 各ステップでアプリケーションの挙動を監視し、Amazon CloudWatch アラームと統合することで、問題が検出された場合に自動的にデプロイを停止またはロールバックできるため、オンラインゲームのバックエンドや金融システムなど、NLB を利用する重要なワークロードの更新に対する信頼性と安全性が大幅に向上します。
これまでとどう変わるのか #
- これまで: ECS で NLB を使用する場合、高度なデプロイ戦略(リニア、カナリア)を実施するには、AWS CodeDeploy を個別に設定・管理する必要があり、構成が複雑になる場合がありました。標準のローリングアップデートでは、段階的なトラフィック制御や自動ロールバックの細かい制御が難しく、一気に切り替わる挙動に近いものでした。
- これから: ECS サービスの構成(コンソール、CLI、IaC ツール)の一部として、ターゲットグループやリスナーとともにデプロイ戦略を直接選択できるようになりました。これにより、複雑な外部設定なしに、ECS ネイティブの機能として安全なデプロイフローを構築できます。
具体的なユースケース #
- オンラインゲーム: プレイヤーの接続を維持したまま、新しいゲームサーバーロジックへ徐々にトラフィックを移行し、ラグや切断がないか確認する。
- 金融トランザクション: 決済処理システムの新バージョンを 5% のトラフィックでテストし、エラー率を監視してから全体に適用する。
Amazon EKS が AWS GovCloud (米国) リージョンにおける EKS アドオンへの IAM 権限付与を簡素化 #
投稿日: 2026年02月04日
何ができるようになったのか #
AWS GovCloud (米国) リージョンにおいて、Amazon EKS アドオンと EKS Pod Identity の直接統合が可能になりました。 これにより、EKS コンソール、CLI、API、eksctl、CloudFormation などの IaC ツールを使用して、EKS アドオンの操作を通じて EKS Pod Identity を直接管理できるようになります。
何が嬉しいのか #
Kubernetes クラスターの運用ソフトウェア(アドオン)が AWS リソースと連携するために必要な IAM 権限の管理プロセスが大幅に簡素化されます。 クラスター作成時に EKS コンソールからインストールできる、Pod Identity 互換の EKS アドオンの選択肢が拡大し、セットアップの手間が削減されます。
これまでとどう変わるのか #
- これまで: EKS アドオンに IAM 権限を付与するためには、主に IAM Roles for Service Accounts (IRSA) が使用されていましたが、OIDC プロバイダーの設定や信頼ポリシーの管理など、構成が複雑になる場合がありました。また、商用リージョンで先行していた EKS Pod Identity のアドオン統合が、GovCloud では利用できない場合がありました。
- これから: AWS GovCloud (米国) リージョンでも、EKS Pod Identity を活用してアドオンへの権限付与を行えるようになり、よりシンプルでスケーラブルな権限管理が可能になります。
具体的なユースケース #
- AWS Load Balancer Controller や VPC CNI などのアドオンに対し、IRSA の複雑な手順を踏むことなく、EKS Pod Identity を使用して迅速かつ安全に IAM 権限を割り当てる。
Amazon RDS for MySQL が新しいマイナーバージョン 8.0.45 および 8.4.8 をサポート #
投稿日: 2026年02月02日
何ができるようになったのか #
Amazon RDS for MySQL において、MySQL コミュニティによってリリースされた最新のマイナーバージョンである 8.0.45 および 8.4.8 が利用可能になりました。
何が嬉しいのか #
これまでのバージョンに含まれていた既知のセキュリティ脆弱性が修正されるほか、バグ修正、パフォーマンスの向上、および新機能の追加といった恩恵を受けることができます。データベースのセキュリティと安定性を維持するために、最新バージョンへのアップグレードが推奨されます。
これまでとどう変わるのか #
- これまで: これらのバージョンより前のマイナーバージョン(例: 8.0.44 や 8.4.7 など)を利用していました。
- これから: RDS 管理コンソールから新しいデータベースを作成する際や、既存のデータベースを変更する際に、バージョン 8.0.45 および 8.4.8 を選択できるようになります。「マイナーバージョンの自動アップグレード」を有効にすることで、メンテナンスウィンドウ中に自動的に適用することも可能です。
具体的なユースケース #
- セキュリティコンプライアンス要件を満たすために、最新のセキュリティパッチが適用されたバージョンへデータベースエンジンを更新する。
- Amazon RDS ブルー/グリーンデプロイメントを活用して、リスクを最小限に抑えつつ、新しいマイナーバージョンへの切り替えを行う。
Amazon Redshift がマルチクラスター環境向けの自律機能 (Autonomics) をサポート #
投稿日: 2026年02月04日
何ができるようになったのか #
Amazon Redshift の自律機能(自動最適化機能)が、マルチクラスター環境に対応しました。 これにより、自動テーブル最適化 (ATO)、自動テーブルソート (ATS)、Auto Vacuum、Auto Analyze といった機能が、共有データにアクセスするすべてのコンシューマークラスター(読み取り用クラスターなど)のクエリパターンを考慮して、テーブルレイアウトやメンテナンス操作をインテリジェントに実行できるようになりました。 また、特定のデータ共有エンドポイントや AWS アカウントが最適化の判断に影響を与えないようにする「拒否リスト (denylist)」機能も追加されました。
何が嬉しいのか #
これまでは、データの所有者(プロデューサークラスター)側での最適化が、必ずしもコンシューマークラスター側のクエリパターンに最適化されているとは限りませんでした。 今回のアップデートにより、複数のビジネスユニットが共有データにアクセスするような環境において、すべてのワークロードパターンを考慮した包括的な最適化が自動で行われるようになり、手動でのパフォーマンスチューニングの手間が削減されます。
これまでとどう変わるのか #
- これまで: Redshift の自律機能は、主にそのデータを持つクラスター(プロデューサー)内でのクエリパターンに基づいて最適化を行っていました。データ共有を使用している場合、コンシューマークラスターからのアクセスパターンが十分に反映されず、手動調整が必要な場合がありました。
- これから: プロデューサークラスターの自律機能が、連携しているコンシューマークラスターのクエリワークロードも学習・考慮するようになり、システム全体として最適なパフォーマンスを発揮するようにテーブル設計(ソートキーや分散キーなど)やメンテナンスを自動調整します。
具体的なユースケース #
- 中央のデータウェアハウス(プロデューサー)のデータを、マーケティング部門や財務部門など複数の部門(コンシューマー)がそれぞれのクラスターから参照している環境で、全社的なクエリパフォーマンスを自動的に最適化する。
- 組織外へのデータ共有など、特定の共有先からのクエリパターンを最適化ロジックに影響させたくない場合に、拒否リストを使用して制御する。
Amazon SageMaker Unified Studio (IDC ベースドメイン) で Apache Spark のリネージが利用可能に #
投稿日: 2026年02月04日
何ができるようになったのか #
AWS IAM Identity Center (IDC) ベースのドメインを使用している Amazon SageMaker Unified Studio において、Amazon EMR および AWS Glue 上で実行される Apache Spark ジョブのデータリネージ (Data Lineage) が利用可能になりました。
何が嬉しいのか #
EMR-EC2、EMR-Serverless、EMR-EKS、および AWS Glue で実行された Spark ジョブから、データ資産やカラムのスキーマ変更、変換(トランスフォーメーション)の履歴を自動的にキャプチャできるようになります。 これにより、SageMaker Unified Studio 上でデータの流れを視覚的なグラフとして確認したり、API を使用してクエリすることが可能になります。 複雑なデータパイプラインの問題発生時の根本原因分析や、変更が下流に与える影響範囲の特定、さらには過去の変換履歴との比較などが容易になり、データガバナンスとトラブルシューティングが強化されます。
これまでとどう変わるのか #
- これまで: Spark ジョブの実行結果としてのデータがどこから来て、どのように加工されたか(リネージ)を追跡するには、独自に仕組みを構築するか、サードパーティツールを使用する必要があり、統合的な可視化が困難でした。
- これから: SageMaker Unified Studio 内でネイティブに Spark ジョブのリネージが可視化されるため、データエンジニアやデータサイエンティストは、追加のツールを導入することなく、データの信頼性を確認し、デバッグや監査を効率的に行えるようになります。
具体的なユースケース #
- データ品質の問題が発生した際に、どの Spark ジョブのどの変換処理が原因でデータが破損したかをグラフで遡って特定する。
- テーブルのカラム定義を変更する前に、そのカラムを使用している下流のジョブやダッシュボードを特定し、影響範囲を見積もる。
AWS Batch の ListJobs API が配列ジョブのステータスサマリーを提供するようになりました #
投稿日: 2026年02月03日
何ができるようになったのか #
AWS Batch の ListJobs API のレスポンスに、配列ジョブ (Array Job) のステータスサマリーが含まれるようになりました。これにより、追加の API 呼び出しを行うことなく、子ジョブのステータス分布(SUBMITTED, PENDING, RUNNABLE, STARTING, RUNNING, SUCCEEDED, FAILED の各状態にある子ジョブの数)を即座に把握できるようになりました。
何が嬉しいのか #
大規模なワークロードのモニタリング効率が向上します。複数の配列ジョブの進捗状況を、キュー内の単一の API 呼び出しで確認できるようになるため、運用上の可視性が高まります。また、金融サービスや自動車産業など、数千の並列ジョブを監視することが不可欠な業界での大規模バッチ処理において特に価値があります。
これまでとどう変わるのか #
- これまで:
statusSummaryフィールドはDescribeJobsAPI 呼び出しのレスポンスでのみ利用可能でした。そのため、配列ジョブのステータス内訳を知るにはDescribeJobsを別途呼び出す必要がありました。 - これから:
ListJobsAPI を呼び出すだけで、配列ジョブのstatusSummary(各ステータスの子ジョブ数)とstatusSummaryLastUpdatedAt(ステータス情報の更新時刻)を取得できるようになり、ワークロード管理やトラブルシューティングのための判断がより迅速に行えるようになりました。
具体的なユースケース #
- 金融シミュレーションやレンダリング処理など、大量の並列ジョブ(配列ジョブ)を実行する際に、管理画面や監視ツールで各配列ジョブの進捗率(例: 「成功: 500, 実行中: 200, 失敗: 10」)を一覧表示するパフォーマンスが向上し、API コール数を削減できます。
AWS Batch が Amazon EKS のアンマネージドコンピューティング環境をサポート #
投稿日: 2026年02月04日
何ができるようになったのか #
AWS Batch が Amazon EKS 上のアンマネージドコンピューティング環境 (Unmanaged Compute Environments) をサポートしました。 これにより、ユーザーは独自の EKS クラスターと Kubernetes ノードの構成を完全に制御しつつ、AWS Batch のジョブスケジューリングおよびオーケストレーション機能を利用できるようになります。
何が嬉しいのか #
セキュリティ、コンプライアンス、または独自の運用要件により、インフラストラクチャを厳密に管理する必要がある場合でも、AWS Batch の強力なジョブ管理機能(依存関係管理、リトライロジック、優先順位付けなど)を活用できます。 AWS Batch がインフラを自動スケーリングする「マネージド」環境とは異なり、ユーザー自身でノードのプロビジョニングや設定を行えるため、特殊なハードウェア構成やネットワーク設定が必要なケースにも柔軟に対応できます。
これまでとどう変わるのか #
- これまで: AWS Batch on EKS を利用する場合、主に AWS Batch がスケーリングを管理する「マネージドコンピューティング環境」が中心でした。既存の固定的なクラスター構成や、独自の自動化ツールで管理されたノード群に対して Batch を適用するのは柔軟性に欠ける場合がありました。
- これから:
CreateComputeEnvironmentAPI またはコンソールから、既存の EKS クラスターと Namespace を指定してアンマネージド環境を作成できるようになりました。kubectlを使用して対象の EKS ノードにラベルを付けることで、そのノードを AWS Batch のコンピューティングリソースとして関連付けることができます。
具体的なユースケース #
- セキュリティポリシーにより、AWS のサービスによる自動的なインスタンスの起動・削除が制限されている環境で、事前にプロビジョニングされた固定ノード群を使ってバッチ処理を行う。
- Karpenter や独自のオートスケーラーを使用してインフラのスケーリングを制御しつつ、ジョブのキューイングと実行管理には AWS Batch を利用する。
AWS Builder ID が「Sign in with Apple」をサポート #
投稿日: 2026年02月05日
何ができるようになったのか #
AWS Builder ID のログインオプションとして、新たに 「Sign in with Apple」 が追加されました。 これにより、AWS Builder Center、AWS Training and Certification、AWS re:Post、AWS Startups、そして Kiro などの AWS アプリケーションにアクセスする際に、Apple アカウントを使用してサインインできるようになりました。
何が嬉しいのか #
これまでの Google アカウントによるソーシャルログインに加え、Apple ユーザーにとっても使い慣れた認証情報を使用してシームレスに AWS サービスへアクセスできるようになります。 新しいパスワードを作成・管理する手間が省け、パスワード忘れの問題も減少するため、新規登録や再ログインのプロセスがよりスムーズになります。
これまでとどう変わるのか #
- これまで: AWS Builder ID を作成するには、メールアドレスとパスワードを設定するか、Google アカウントを使用する必要がありました。
- これから: Apple デバイスや Apple ID を日常的に使用している開発者やビルダーは、追加の設定なしに既存の Apple ID を使って即座に認証を行い、学習や開発作業を開始できます。
具体的なユースケース #
- iPhone や Mac ユーザーが、外出先で AWS re:Post のコミュニティディスカッションに参加したり、AWS Training and Certification のコースを受講したりする際に、Face ID や Touch ID と連携したスムーズなログインを行う。
Amazon EC2 と VPC コンソールがセキュリティグループの関連リソースを表示可能に #
投稿日: 2026年02月04日
何ができるようになったのか #
Amazon EC2 および VPC のマネジメントコンソールにおいて、セキュリティグループの詳細画面に新しく 「関連リソース (Related resources)」タブ が追加されました(一般提供開始)。 このタブでは、その特定のセキュリティグループに関連付けられているすべての AWS リソース(依存リソース)を統合ビューで確認できます。
何が嬉しいのか #
セキュリティグループを変更または削除する前に、影響を受けるリソースを特定する作業が大幅に効率化されます。 これまでは、どのリソースがそのセキュリティグループを使用しているかを確認するために複数のサービス画面を行き来する必要がありましたが、今後は一箇所で一覧を確認できるため、誤設定や意図しない影響を防ぎ、自信を持って構成変更を行えるようになります。
これまでとどう変わるのか #
- これまで: セキュリティグループの依存関係を確認するには、EC2 インスタンス、ENI、RDS データベース、ElastiCache クラスターなど、各サービスのコンソールを個別に確認して回る必要があり、手動で時間がかかりエラーが発生しやすいプロセスでした。
- これから: EC2 または VPC コンソールでセキュリティグループを選択し、「関連リソース」タブを開くだけで、そのグループがアタッチされている全リソースを即座に特定できます。
具体的なユースケース #
- セキュリティグループのルールを厳格化する前に、予期せぬ通信遮断が発生しないよう、アタッチされている本番環境の RDS インスタンスや ELB がないか確認する。
- 不要になったと思われるセキュリティグループを削除する前に、本当にどのリソースからも使用されていないかを最終確認する。
Cartesia Sonic 3 テキスト読み上げモデルが Amazon SageMaker JumpStart で利用可能に #
投稿日: 2026年02月04日
何ができるようになったのか #
Cartesia の最新のテキスト読み上げ (TTS) モデルである Sonic 3 が、Amazon SageMaker JumpStart で利用可能になりました。
何が嬉しいのか #
Sonic 3 は、状態空間モデル (SSM) を採用したストリーミング TTS モデルで、42言語をサポートし、以下の特徴を持っています。
- 高い自然性: 人間の話し方のニュアンスや感情、声のトーンの変化を捉えます。
- 低遅延: 100ミリ秒未満のレイテンシーを実現し、リアルタイムの会話型 AI に最適です。
- 高度な制御性: API パラメータや SSML タグを使用して、音量、速度、感情を細かく調整可能です。自然な笑い声の生成や、ボイスエージェント向けの安定した声、キャラクター向けの表現豊かな声もサポートします。 SageMaker JumpStart を通じて、数クリックでこの高性能なモデルを独自の AWS 環境にデプロイし、セキュアに利用できるようになります。
これまでとどう変わるのか #
- これまで: 高品質かつ低遅延な多言語 TTS モデルを自前でホストするには、複雑なモデルの選定やチューニング、インフラ構築が必要でした。
- これから: SageMaker JumpStart のモデルカタログから Sonic 3 を選択するだけで、すぐに本番環境向けの TTS エンドポイントを立ち上げることができ、音声対話アプリケーションやコンテンツ生成ワークフローに組み込むことが容易になります。
具体的なユースケース #
- リアルタイム音声対話エージェント: ユーザーの入力に対して、人間のような自然な反応速度と感情表現で応答する AI アシスタント。
- 多言語コンテンツの自動生成: ニュース記事や教育用コンテンツを、42言語に対応した高品質な音声で読み上げる。
Claude Opus 4.6 が Amazon Bedrock で利用可能に #
投稿日: 2026年02月05日
何ができるようになったのか #
Anthropic の最新かつ最もインテリジェントなモデルである Claude Opus 4.6 が、Amazon Bedrock で利用可能になりました。 このモデルは、200K トークンのコンテキストウィンドウに加え、プレビュー機能として 100万トークン (1M) のコンテキストウィンドウもサポートしています。
何が嬉しいのか #
Anthropic によると、Opus 4.6 はコーディング、エンタープライズエージェント、および専門的な業務において世界最高のモデルとされています。
- エージェントタスク: 多数のツールにまたがる複雑なタスクを高い信頼性で管理し、サブエージェントをプロアクティブに立ち上げて、人間の監督を減らしつつ自律的に作業を進める能力に優れています。
- コーディング: 要件定義から実装、保守に至るまで、長期的なプロジェクトや大規模なコードベースを扱えます。
- エンタープライズワークフロー: 数日かかる手作業を要する財務分析や、微細な攻撃パターンを検出するサイバーセキュリティ、アプリケーション間でデータを移動させるコンピュータ操作ワークフローなどを高度に実行します。
これまでとどう変わるのか #
- これまで: Claude 3.5 Opus やその他のモデルが最高峰とされていましたが、さらに推論能力と信頼性が向上したモデルが登場しました。
- これから: 1M トークンのコンテキストにより、膨大なドキュメントやコードベース全体を一度に読み込ませて処理することが可能になり、より深く複雑なコンテキストを理解した上での回答や作業が期待できます。
具体的なユースケース #
- 大規模なレガシーコードのリファクタリング計画の立案と実行。
- 企業の全財務データを読み込ませ、複雑なシナリオに基づいたリスク分析レポートを生成する。
- 複数のSaaSアプリケーションを操作して、エンドツーエンドの業務プロセス(例:入社手続きの自動化)を代行する自律型エージェントの構築。
Amazon Bedrock で構造化出力 (Structured Outputs) が利用可能に #
投稿日: 2026年02月04日
何ができるようになったのか #
Amazon Bedrock が 構造化出力 (Structured Outputs) をサポートしました。 これにより、事前に定義した JSON スキーマに厳密に準拠した、一貫性のある機械可読なレスポンスを基盤モデルから取得できるようになります。 この機能は、Anthropic Claude 4.5 モデルおよび一部のオープンウェイトモデルで、Converse API や InvokeModel API を通じて一般提供 (GA) されました。
何が嬉しいのか #
これまでは、モデルに「正しい JSON を出力して」とプロンプトで指示しても、余計なテキストが含まれたりフォーマットが崩れたりすることがあり、アプリケーション側でバリデーションや再試行の実装が必要でした。 構造化出力を使用すると、モデルは指定されたスキーマに従った出力を生成することが保証されるため、API 連携やデータ抽出などのダウンストリーム処理が壊れるリスクを低減し、開発工数と運用オーバーヘッドを削減できます。
これまでとどう変わるのか #
- これまで: プロンプトエンジニアリングで出力形式を制御し、正規表現やパースロジックで JSON を抽出・検証する必要がありました。エラーが発生した場合はリトライ処理が必要でした。
- これから: API リクエスト時に JSON スキーマを渡すか、厳密なツール定義(Strict Tool Definitions)を使用するだけで、予測可能で型安全なレスポンスが得られます。
具体的なユースケース #
- 非構造化テキストから、顧客名、住所、注文IDなどの特定のフィールドを抽出し、データベースに保存する。
- エージェントが外部 API を呼び出す際に、その API が要求する正確な JSON パラメータを生成させる。