週刊生成AI with AWS – 2026/9/14 週

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。

9 月 17 日に更新された About Amazon の記事「AWS、米国とアイルランドを結ぶ海底ケーブル Fastnet を展開」では、米国メリーランド州とアイルランドのコーク県を結ぶ大西洋横断の海底光ファイバーケーブル Fastnet が紹介されています。2028 年の運用開始時には 320 Tbps を超える設計容量（HD 映画 1,250 万本の同時ストリーミングに相当）を備え、従来のケーブル回廊から離れた陸揚げ地点によって、他の海底ケーブルに問題が起きてもサービスを継続できる経路の多様性を確保します。増え続ける AI のトラフィックを見据えた設計で、生成 AI やエージェントを支える土台となるネットワーク層にも AWS の投資が続いていることが分かります。AWSを支えるインフラの裏側に興味がある方は是非読んでみてください。
また、お昼休みの 30 分で最新情報を知れる「もぐもぐAWS」では、AI をテーマにした会が予定されています。是非カレンダーをチェックしてご参加ください。

それでは 9 月 14 日週の生成 AI with AWS界隈のニュースを見ていきましょう。

さまざまなニュース

• • AWS生成AI国内事例ブログ「AWS Professional Services と実現する第一興商カラオケ聴感採点 AI の開発」
    株式会社第一興商と Amazon Web Services Japan の共同執筆記事です。通信カラオケ「DAM」シリーズの採点機能を高度化するため、第一興商は AWS Professional Services と共同で人間の聴感に即した歌声評価 AI「聴感採点モデル」を開発し、フラッグシップモデル LIVE DAM WAO! に搭載された採点機能「精密採点Ai Heart」の中核として活用しています。従来の機械採点は音程・リズム・ビブラートなどの音響パラメータを機械的に評価する方式で、人間が心地よいと感じる歌声のニュアンスを十分に評価できず、機械的に高得点を狙う「採点歌い」を過大評価しがちという課題がありました。最も困難だったのは「人間の聴感」を表す教師データの作成で、当初の 5 段階尺度法は審査員のブレが大きかったため、AWS Professional Services の提案で 2 つの歌声を聴き比べる一対比較法に切り替え、約 15 万回のラベル作業を経て Bradley-Terry 法で聴感スコアに変換しています。歌唱音源はオープンソースの深層学習モデル Audio Embedding Generator で 1 秒ごとに 128 次元のベクトルに変換し、AWS Fargate for Amazon ECS による最大 1,000 並列の基盤で約 13 万ファイルを 1.5 時間で処理しました。ラベリングには Amazon SageMaker Ground Truth、モデルの学習には AutoGluon Tabular と Amazon SageMaker AI を使い、製品化の際には DAM 端末のスペックに合わせた軽量化も行っています。人の感性という定量化しにくいものを教師データに落とし込む工程の工夫は、他分野の機械学習にも参考になります。
  • AWS生成AI国内事例ブログ「【寄稿】株式会社レスター、Amazon Bedrock で顧客課題とグループの解決力をつなぐ情報プラットフォームを構築」
    半導体・電子部品の販売やソリューション提供などを手がける株式会社レスターによる寄稿記事です。事業領域の拡大とグループ再編で顧客基盤や商材、知見が広がる一方、他の会社・事業・部門が何を得意とし、どの顧客と接点を持つのかを把握しにくいという課題に対し、分散していた営業情報を一つの土台に集める AI 情報プラットフォームを構築しています。中核となるレスターマッチングサービス（RMS）は、顧客ニーズと解決手段を結びつけるマッチングの仕組みであると同時に、顧客・取引実績・担当者・商材・議事録などを関係性を保ったまま蓄積するグループ共通のデータウェアハウスです。情報の流れを「データ化」「蓄積・統合」「引き出して提案へつなぐ」の 3 段階に整理し、AI 議事録では商談の録音を Amazon Transcribe で文字起こし・話者分離したうえで Amazon Bedrock 上の Anthropic Claude が議事録として整理し、AI チャットボットでは LangGraph で構築したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless による RAG（検索拡張生成）で社内文書や議事録を検索します。録音時の同意取得、議事録ごとに参照対象へ含めるかの選択、競合情報の閲覧制限、人による最終判断といった運用ルールに加え、モデルの追加学習と RAG での参照を混同しないよう「AI に学習させる」ではなく「社内 AI 回答時の参照対象に含めるか」と表現する工夫も紹介されています。
  • AWS生成AI国内事例ブログ「NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第1回）：フィジカルAI領域でのML開発への適用」
    株式会社NTTドコモ モバイルイノベーションテック部が、AWS が提唱する AI-DLC（AI-Driven Development Lifecycle）の TTT（Train The Trainer）に参加し、フィジカル AI（現実世界で物理的に動作する AI）領域の機械学習パイプラインを 3 日間のチーム開発で構築した取り組みを、全 2 回で紹介する寄稿記事の第 1 回です。対象は SO-101 ロボットアームで「キューブを持ち上げる」タスクで、模倣学習モデル（ACT）は人手で収集した 10 件のデモデータでは成功率 10%、NVIDIA の COSMOS や Mimic によるデータ増幅で 45% まで向上したものの改善が頭打ちになったため、模倣学習で得た動作知識を軽量なポリシーに蒸留し強化学習で改善する RPD（Refined Policy Distillation）論文のアプローチを採用しています。個人が AI と対話しながら進める Vibe Coding では判断やコンテキストが蓄積されないという課題意識から、要件の構造化と設計レビューを重視する AI-DLC を ML 開発に適用し、Inception フェーズではチーム全員が Kiro を囲むモブスタイルで論文や専門情報を読み込ませながら、4 つのタスクリストと 3 つの実装ユニットを定義しました。Kiro による設計レビューでは、チェックポイント形式の不一致や入力次元の食い違いなど 11 個の不整合を実装前に検出し、Inception フェーズだけで 30 以上の構造化ドキュメントを生成しています。「コードが動くが出力が正しくない」不具合が起きやすい ML 開発で、設計段階の整合性チェックが手戻りの削減につながるという実感が語られています。
  • AWS生成AI国内事例ブログ「NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第2回）：2チーム並行開発の実験結果と知見」
    第 2 回は、Construction フェーズにおける 2 チーム並行開発の実験結果と知見です。両チームは蒸留から PPO（強化学習）、評価までのパイプライン構造を共有しつつ、チームピンクは KL ペナルティの効果検証、チームブルーは蒸留初期化そのものの効果検証と、細部の設計判断を分けて比較しました。実装開始直後に ACT の学習環境構築に想定以上の工数がかかると判明したチームブルーは、AI-DLC のプロセスに従って Inception フェーズに立ち戻り、タスクリストの優先度を根拠にスコープを絞る軌道修正を行っています。3 日間の結果は、模倣学習のみのベースライン 45% に対し、チームブルーで蒸留あり 64%、蒸留なし 90% と「蒸留初期化は逆効果」に見えるものでしたが、TTT 後に構造化された実験記録を読み返して Inception に立ち戻ったところ、座標変換の欠落が真因だったことが数時間で判明しました。座標変換を修正し損失関数を変更して再蒸留したうえで PPO を実行した結果、成功率は 97% に到達し、蒸留なしの 90% を統計的に有意に上回っています。1 日で 3 回の実験サイクルを回せたこと、専門家が不在でもパイプラインを構築でき専門家は品質の最終確認に集中できる状態になったこと、そして失敗の記録が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する利点として整理されています。
  • ブログ記事「【開催報告】ファッション・アパレル業界向け 第一回ナレッジ共有会 〜 SMART から始まる業界共通課題への挑戦と学びの場」
    2026 年 7 月 29 日に開催された、ファッション・アパレル業界のお客様 6 社 20 名が参加したナレッジ共有会の開催報告です。AWS Prototyping Program から生まれ 2026 年 4 月に GitHub（aws-samples）で公開された店舗業務支援 AI エージェント SMART（Store Manager Agent for Retail Tech）と、Kiro も活用した合同ブートキャンプを起点に、各社が取り組んできた AI エージェント開発の実践ナレッジを企業の垣根を越えて共有する場です。サザビーリーグ IRIS 様は、グループの飲食ブランドである麺屋 猪一を対象に、SMART をベースとした週報・月報の自動生成機能を Amazon Bedrock、Amazon EventBridge、AWS Lambda、Amazon S3 Tables、Amazon Athena、Amazon SNS などで約 1 ヶ月半で開発し、店舗 PoC では約 15 分かかっていた週報作成が 0 分になり、現在は全 4 店舗で利用が始まっています。ジンズ様は店舗出身で IT 未経験のメンバーが Kiro とともに 2 週間で、Amazon Transcribe による音声テキスト化、Amazon Bedrock による感情分析・ペイン分類、改善案の自動生成、Excel 出力までを行う店舗フィードバック収集 Web アプリを構築し、アンドエスティ HD 様は「AI は判断しない。作戦を複数提示し、人が決める」という設計思想のもと Amazon Bedrock AgentCore を活用した在庫消化 Agent の開発を 2.5 ヶ月進めています。
  • ブログ記事「セキュリティにおける AI の現在地: 信頼構築に最も重要な指標の測定」
    AWS は、AI モデルが実際の脆弱性と「危険に見えても本当は安全なコード」を区別できるかを直接測定する初のベンチマーク Deception Benchmark を公開しました。16 のプログラミング言語、70 を超える CWE（Common Weakness Enumeration）カテゴリにわたる 14,822 個のサンプルで構成され、パラメータ化されたステートメントで SQL インジェクションのパスが閉じられている Flask エンドポイントのように、脆弱性パターンは見えるが緩和策によって悪用不可能になっているコードが含まれます。従来のベンチマークは AI が脆弱性を発見・悪用できるかを測るものでしたが、本ベンチマークは誤検出を見分ける防御側の適合率を測る点が新しく、5 社 12 モデルを評価した結果、標準的なプロンプトでは適合率が 50% 台半ばにとどまり、偽陽性率（安全なコードを脆弱と判定する率）と偽陰性率（実際の脆弱性を見逃す率）の両方を本番利用の最低基準とする 10% 未満に抑えられた構成はありませんでした。エクスプロイトの実証を求めるプロンプトでは偽陽性率が 17〜74 ポイント下がる一方で実際の脆弱性の 7〜44% を見逃すなど、どのモデルにも同じ失敗パターンが見られます。サンプルと評価ワークフローは GitHub で公開されており、ベンチマークが暗記の問題にならないようラベルは非公開です。AI セキュリティツールを評価する際は、脆弱性を発見できるかだけでなくどのくらいの頻度で誤るかをベンダーに確認し、リスクの高いコードパスでは人間の検証と組み合わせることが推奨されています。
  • ブログ記事「自動推論に立ちはだかる 3 つの難題」
    Amazon の vice president 兼 distinguished scientist である Byron Cook 氏が 2025 年 8 月に Amazon Science Blog に公開した記事の翻訳です。生成 AI ベースのシステムで正しい推論を実現する際に最も厄介な 3 つの側面として、あいまいな自然言語を構造化された言語へ変換すること、絶えず変化し時には矛盾するルールのもとで何を真理とするかを定義すること、そして組み合わせの数が天文学的になる中で確定的に推論することを挙げ、Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）がそれぞれにどう対処しているかを解説しています。自然言語の変換では、形式言語への変換候補を複数生成してソルバーで等価かどうかを証明・反証し、意味が食い違えばユーザーに確認を求めます。確定的な推論では SAT（充足可能性問題）ソルバーを活用しつつ、自身の判定結果を参照して矛盾を生むルールのように正しい答えが存在しないケースを Gödel の不完全性定理と結び付け、無矛盾性と完全性を同時に満たせない中で AWS は無矛盾性を選んだと述べています。自動推論チェックの背景にある考え方を理解するのに役立つ記事です。
  • ブログ記事「はじめての自動推論」
    同じく Byron Cook 氏が 2021 年 12 月に Amazon Science Blog に公開した記事の翻訳で、上記「自動推論に立ちはだかる 3 つの難題」を読む前の予備知識としておすすめです。自動推論についてまったく知識のない業界の実務者向けに書かれており、必要な前提知識は短い C と Python のコード断片を読めることだけです。x + y == y + x を返す関数が false を返し得るかを unsigned int の全組み合わせで網羅的にテストすると 1,360 年以上かかる一方、自動推論ツールは代数を使ってミリ秒単位で答えを出せるという例から始まり、ループが必ず停止するかを推論する少し複雑な例を通じて、ツールが制御構造、最終的に真になること、常に真であることをどう推論しているかを直感的に説明します。末尾には書籍、国際会議、ツール、講演やブログへのリンクが豊富にまとめられており、さらに学びたい方の出発点になります。
  • ブログ記事「自動推論による数学的確実性の 10 年: Automated Reasoning Group が歩んだ道」
    こちらも同じくByron Cook 氏が 2026 年 8 月に Amazon Science Blog に公開した記事の翻訳で、2016 年に発足した Amazon の Automated Reasoning Group（ARG）の 10 年を振り返ります。2016 年の第 1 回 Demo Day で紹介された、VPC ネットワークに関する質問に答えるツール Tiros は Amazon Inspector のネットワークセキュリティ分析や Reachability Analyzer の基盤になり、そこから派生した Zelkova は S3 Block Public Access や IAM Access Analyzer などポリシーを分析するツールの基盤になっています。現在 ARG の本番サービスは 1 日あたり数十億件のクエリを処理し、生成 AI 向けには Amazon Bedrock Guardrails の自動推論チェックがモデルの応答をポリシーに照らして形式論理で検証しています（検証精度は最大 99%）。自動推論が AWS のセキュリティと信頼性をどう支えてきたのか、その全体像をつかめる記事です。
  • ブログ記事「エージェント型 AI による ERP ビジネスプロセス運用の変革」
    ある大手企業の Direct Ship（直送）請求業務では、ERP における手作業の例外処理が請求の遅延や収益認識への影響を招いていました。Accenture は Amazon Bedrock や Amazon Bedrock AgentCore などを用いたエージェント型 AI ソリューションを 5 週間で稼働させ、SOP（標準作業手順書）やジョブエイド、組織内のナレッジを一元化して自然言語で質問できる Digital Assistant と、SAP S/4HANA や認証用の Okta といった既存エンタープライズシステムとの統合機能を提供しています。アーキテクチャは、基盤モデルを提供する Amazon Bedrock、ツールの選択とワークフローのオーケストレーションを担う Strands Agents SDK、複数ターンの会話コンテキストを保持する Amazon Bedrock AgentCore、SAP S/4HANA へ安全に接続する AWS Lambda、事前処理した例外レポートを保存する Amazon RDS、レポートデータのロードを制御する AWS Step Functions の 6 つのサービスで構成されています。複数システムを行き来せずに SAP データへ即時アクセスでき、価値の高い注文を事後対応ではなくプロアクティブに処理できるようになったほか、新しいチームメンバーが対話を通じて組織のナレッジにアクセスできるようになった点が成果として挙げられ、同じパターンは調達や在庫管理など他の SAP モジュールにも拡張できるとしています。
  • ブログ記事「ERP例外処理をAWSエージェント型標準作業手順書（SOP）で自動化」
    ERP の例外処理を AI エージェントで自動化するためのフレームワークとリファレンスアーキテクチャを解説する翻訳記事です。請求書の例外や購買発注（PO）の承認ブロック、月次決算などで発生する手作業の介入に対し、SAP ユースケース向けの AWS Agentic AI Solutions Framework と、その中核となるエージェント型標準作業手順書（Agentic SOP）を紹介しています。Agentic SOP は、業務プロセスごとに別々のエージェントを作るのではなく、ナレッジベースから SOP を動的に解釈し、SAP と非 SAP システムをまたいで複数ステップの例外を自律的に解決する単一の AI エージェントで、判断や承認が必要な箇所ではヒューマン・イン・ザ・ループの制御が働きます。フレームワークは、アドバイザリーモードから監督付き実行、自律的な解決へと段階的に信頼を獲得する仕組み、SOP 駆動の統合エージェントアーキテクチャ、決定論的で監査可能なアクションのためのガード付き MCP（Model Context Protocol）サーバー、ID を意識したセキュリティとコンプライアンス、監査水準の永続的な状態管理という 5 つのコア機能で構成されます。リファレンスアーキテクチャでは、Amazon EventBridge がスケジュール実行する AWS Lambda で SAP OData サービスから例外を検知し、Amazon DynamoDB に状態と監査証跡を記録しながら、Amazon Bedrock AgentCore 上の Strands エージェントが Amazon Bedrock Knowledge Bases から SOP と SAP OData API 仕様を取得して SAP への操作を実行し、必要に応じて Amazon SES 経由で人間へエスカレーションします。あるグローバル製造企業では、1,000 件を超えるアクティブな PO にまたがる 2 億 5,000 万ドル超の購買管理において、1 決算サイクルあたり 30 日超かかっていた手作業が PO あたり数分で完了するようになったとしています。
  • ブログ記事「月刊 AWS 製造 2026 年 9 月号」
    製造業向けに 8 月に公開されたブログとサービスアップデートをまとめた月刊記事です。今月のピックアップトピックは「エージェントに現場を任せるとき、境界線をどこに引くか」で、PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあると指摘しています。コニカミノルタ様の「未来の実験室」では AI の担当を目標色・操作候補・停止条件へ分解した JSON の中間表現までに絞って座標制御は人が設計した決定論的な制御層が担うこと、SUMCO 様の SynchroFabAI では AI に任せるのは異常状態と因果関係の推測までで操作は人間が実施すること、AWS Summit の Physical AI デモではエージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ったことなど、AI の判断と現実世界への操作を直結させない共通の構図を取り上げています。境界を決める物差しとしては Amazon Science の SOP-Bench を挙げ、不要なツールを追加すると成功率がほぼ半減した実験結果を紹介したうえで、決めた境界を Amazon Bedrock AgentCore の時間的ポリシーや AgentCore Payments でインフラ側から強制する考え方をまとめています。
  • ブログ記事「Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応」
    Kiro の IDE、CLI、Web のすべてで、GPT‑5.6 Sol、Terra、Luna が 100 万トークンのコンテキストウィンドウに対応しました。272K から 1M への拡大により、コードベース全体や長文ドキュメント、長く続いたマルチターンのエージェント履歴を、チャンク分割や要約を挟まず細部を失わないまま 1 回のリクエストで処理できます。記事では、レガシー移行や依存関係のマッピングといったリポジトリ規模の理解、API レイヤーやスキーマ、アプリケーションの状態が絡み合うバグのエンドツーエンドのデバッグ、セッションの全履歴を視界に残したまま進める長時間のエージェンティックなタスクの 3 つを、1 回のパスで可能になる仕事の例として挙げています。
  • ブログ記事「Kiro Web の自律モードで技術的負債に大規模に立ち向かう」
    Kani Rust Verifier や CBMC といったオープンソースの形式検証ツールの保守や開発を担う AWS Automated Reasoning Group が、2025 年 11 月時点で 916 件あったオープン issue に Kiro Web の自律モードで取り組んだ事例です。app.kiro.dev でタスクを記述するか、GitHub issue に kiro ラベルを付けるか、コメントで /kiro とメンションすると、Kiro は隔離されたサンドボックスにリポジトリをクローンし、issue と関連コードの分析、作業の分解、変更の実装、テストスイート全体の実行を経てプルリクエストを開きます。Kiro はマージ権限を持たず、人間が書いたコードと同じ承認要件の対象になります。2 か月で Kiro は 87 件のオープン issue に対応するプルリクエストを提出し、これはそれまでの 22 か月でチームが対応した 94 件に迫る数で、マージされた Kiro 生成コードが持ち込んだリグレッションはゼロでした。2 年以上バックログに残っていた Kani コンパイラのクラッシュの issue を人間の作業 5 分未満で修正とリグレッションテストを含むプルリクエストにつなげたケーススタディのほか、CI は通るが修正を検証していないテスト、アーキテクチャ的に誤った修正、プラットフォーム固有の失敗、フォーマット違反といったうまくいかなかったパターンも紹介されています。
  • ブログ記事「Claude Fable 5.1 が Kiro で利用可能になりました」
    Anthropic の Claude Fable 5.1 が、Kiro のエンタープライズ顧客向けに利用可能になりました。バグ修正や関数のリファクタリングといったインタラクティブなタスク、大規模なリファクタリングや長時間の自律実行のような複数ステップにわたるタスク、大規模なコードベース全体にまたがる推論を必要とするセキュリティやシステムレベルの複雑なタスクの 3 種類で到達点を引き上げるとしています。モデルはセッション全体を通して計画を保持し、Kiro の spec 駆動のアプローチによりタスクが成功しないと判断された場合には早期に停止してクレジットの消費を抑えます。
  • ブログ記事「Kiro Crew でソフトウェアファクトリーを構築し、1 週間で 1000 件の PR をマージした方法」
    Kiro Crew をフルタイムで開発する 3 人のエンジニアが、7 日間で 1,000 件のプルリクエストをマージした経緯を振り返っています。1 日あたり 120 件を超えるプルリクエストはすべて CI とレビューを通っており、この数字は狙ったものではなく、並行開発の限界にぶつかるたびに 1 人がより多くのセッションを回せる進め方を生み出してきた結果だとしています。Kiro Crew 自体はこの 3 人を中心に 500 人近いコミュニティコントリビューターとともに開発されています。その変化は、1 セッションを手作業で回す段階、複数のタブを人間がつなぐ段階、memory・ダッシュボード・cron・workflow でセッションが温まった状態から始まる段階（10〜20 セッション）、triage・実装・レビュー・マージを独立したステージとキューでつなぐ agent pipeline の段階（20 セッション以上）、そしてセッションの外側に立つエージェントがゴールの分解・割り当て・巡回・受け入れ・順序付けを担い人間はゴールを持つだけになる Crew Mode の段階（50 セッション以上）の 5 つに整理されています。同時に、エージェント間の調整、memory の境界、ホスト側で強制する権限制御、エージェントが書き換えられない監査ログという 4 つのガバナンス上の問題と、数百セッション規模で立ち上がるコストの問題にも踏みこんでいます。

サービスアップデート

• • 新しい AgentCore Runtime が Amazon Bedrock AgentCore で利用可能に
    Amazon Bedrock AgentCore 内のサーバーレス microVM コンピュートである AgentCore Runtime の次世代版が利用可能になりました。新しい Runtime は、セッション中に使われなくなったメモリを回収する弾力的なメモリ管理によってピーク値ではなく実際の使用量に対して課金されるようになり、エージェント環境を一度準備してスナップショットを取り、新しいインスタンスはそこから復元する仕組みによって、コンテナイメージのサイズや同時実行数に関係なく一貫したコールドスタート時間を実現します。事前プロビジョニング不要、ゼロへのスケール、ハードウェアで強制されるセッション分離、使った分だけの支払いというサーバーレスモデルはそのままです。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（東京）で利用でき、ランタイムの作成または更新時に platformVersion を V2 に設定することで使い始められます。
  • Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始
    Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始となりました。Moonshot AI によれば、Kimi K3 は同社で最も高性能なモデルで、2.8 兆パラメータに到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模リポジトリにまたがる長時間のコーディングセッション、スキャンしたページやスクリーンショットを含む複数ドキュメントの分析、長く続くエージェントワークフローに向いています。クロスリージョン推論を通じて、Amazon Bedrock が利用できるすべての AWS リージョンで利用できます。
  • Qwen3.6-35B-A3B-NVFP4 と Wan2.1-T2V-1.3B-Diffusers モデルが Amazon SageMaker JumpStart で利用可能に
    NVIDIA の Qwen3.6-35B-A3B-NVFP4 と Alibaba の Wan2.1-T2V-1.3B-Diffusers が Amazon SageMaker JumpStart で利用可能になりました。Qwen3.6-35B-A3B-NVFP4 は Alibaba の Qwen3.6-35B-A3B を NVIDIA が量子化したモデルで、総パラメータ 35B のうちトークンあたり 3B（256 のエキスパートのうち 8 つ）のみを活性化する Mixture-of-Experts 構成です。262K トークンのコンテキストウィンドウは YaRN スケーリングで約 1M まで拡張でき、NVIDIA の ModelOpt フレームワークで NVFP4 に量子化することで、会話ターンをまたいだ thinking の保持、マルチトークン予測、複数ステップのエージェントパイプライン向けのツール呼び出しを、メモリ使用量を抑えながら利用できます。Wan2.1-T2V-1.3B-Diffusers は 1.3B パラメータのテキストから動画への生成モデルで、8.19 GB の VRAM で動作し、RTX 4090 で 5 秒の 480p 動画を約 4 分で生成できます。いずれも SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。
  • Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 モデルが Amazon SageMaker JumpStart で利用可能に
    Mistral AI の Ministral 3 ファミリーから、Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 が Amazon SageMaker JumpStart で利用可能になりました。いずれもエッジ展開やリソースの限られた環境向けに設計された、ビジョン対応のコンパクトな言語モデルです。3B モデルは 3.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 では 8GB の VRAM に収まりながら 256K トークンのコンテキストウィンドウに対応し、英語、フランス語、スペイン語、ドイツ語、中国語、日本語、韓国語、アラビア語を含む数十言語での指示追従、システムプロンプトへの高い遵守性、構造化 JSON 出力を伴うネイティブな関数呼び出しを Apache 2.0 ライセンスで提供します。8B モデルは 8.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 なら 12GB の VRAM に収まり、より大きな Mistral Small 3.2 24B に匹敵する能力を備えます。SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。
  • Gemma-4-31B-it-assistant と Gemma-4-31B-IT-NVFP4 モデルが Amazon SageMaker JumpStart で利用可能に
    Google DeepMind の Gemma-4-31B-it-assistant と NVIDIA の Gemma-4-31B-IT-NVFP4 が Amazon SageMaker JumpStart で利用可能になりました。Gemma 4 のフラッグシップである 31B の dense モデルを、フル精度版と量子化版の両方で利用できます。Gemma-4-31B-it-assistant はアシスタント向けにチューニングされたモデルで、テキストと画像（フレーム列としての動画を含む）を入力としてテキストを出力し、256K トークンのコンテキストウィンドウと 140 以上の言語に対応します。
  • granite-speech-4.1-2b、kanana-2-30b-a3b-instruct、OpenFold3 モデルが Amazon SageMaker JumpStart で利用可能に
    IBM の granite-speech-4.1-2b、Kakao の kanana-2-30b-a3b-instruct、OpenFold Consortium の OpenFold3 の 3 モデルが Amazon SageMaker JumpStart で利用可能になりました。granite-speech-4.1-2b は英語、フランス語、ドイツ語、スペイン語、ポルトガル語、日本語を対象とした多言語の自動音声認識（ASR）と双方向の音声翻訳（AST）向けに構築された 2B パラメータのモデルで、単語誤り率 5.33%、リアルタイムファクター約 231 の性能を Apache 2.0 ライセンスで提供します。kanana-2-30b-a3b-instruct は Kakao が開発した韓国語・英語バイリンガルの指示追従とエージェント型 AI ワークフロー向けモデルで、Multi-head Latent Attention（MLA）と Mixture-of-Experts（MoE）を採用し、30B の総パラメータのうちフォワードパスごとに 3B のみを活性化、YaRN スケーリングで最大 128K トークンに対応します。OpenFold3 は OpenFold Consortium とコロンビア大学の AlQuraishi Lab が開発した拡散ベースのモデルで、タンパク質、DNA、RNA、小分子リガンドを含む生体分子複合体の全原子構造予測を行い、コンピュータ支援創薬などの研究に活用できます。
  • Amazon SageMaker AI がトレーニングジョブと処理ジョブのインスタンス優先リストに対応
    Amazon SageMaker AI のトレーニングジョブと処理ジョブで、インスタンスの優先リストを指定できるようになりました。これまではジョブ投入時に 1 つのインスタンスタイプしか指定できず、需要の高い GPU ではそのインスタンスが確保されるまで待つか、複雑なリトライロジックを組むか、異なるインスタンスタイプで複数のジョブを同時に投入して対処する必要がありました。今回のアップデートでは、たとえば ml.g6.48xlarge を 2 台、または ml.g5.48xlarge を 4 台といった優先順位付きのリストを渡すと、SageMaker がリストを順に確認し、容量が確保できた最初の構成でジョブを起動します。同じジョブ投入の中で、オンデマンドと予約済みの SageMaker Flexible Training Plans のどちらから容量を調達するかも設定できます。既存のトレーニング・処理ジョブの API の範囲で使え、SageMaker が利用できるすべての AWS リージョンで CLI、API、SDK、コンソール UI から利用できます。
  • Amazon Q Console で CloudTrail イベントを自然言語で分析
    AWS CloudTrail が Amazon Q Console と統合され、AWS アカウントのアクティビティを自然言語で調査できるようになりました。クエリを書いたりログファイルを手作業で解析したりせずに、CloudTrail のトレイルが適切に設定されているか、ロギングのカバレッジに抜けがないか、どのデータイベントソースを記録しているかといった設定の確認から、特定の IAM ロールに誰がアクセスしたか、VPC 設定にどんな変更が加えられたか、過去 1 週間に不正なアクセス試行がなかったかといったセキュリティ調査、特定のリソースを作成・削除したのは誰か、どの API 呼び出しがエラーを発生させているか、なぜ請求が急増したのかといった運用上のトラブルシューティングまで質問できます。Amazon Q Console がサポートされているすべての AWS 商用リージョンで利用できます。
  • Amazon Quick が個別シートの生成と画像からの分析作成に対応
    Amazon Quick の Generate Analysis が拡張され、ダッシュボードをより速く作るための 2 つの方法が追加されました。Generate Sheet では、既存の分析の中に追加したいシートを自然言語で説明すると、データに合わせて選ばれたビジュアル、フィルターコントロール、前年比や前月比といった計算フィールドを含むシートが追加され、ビジュアルを 1 つずつ手作業で組まなくても分析を拡張できます。画像からの分析生成では、他の BI ツールのダッシュボードを含む既存ダッシュボードの画像をプロンプトに添付すると、Amazon Quick がサポートする範囲で編集可能な分析として再作成します。ローンチ時点では Enterprise サブスクリプション / Author Pro ユーザーが利用でき、組織がアクセスを制限していない場合は Author も Amazon Quick Enterprise の一部として 2026 年 12 月までプロモーションアクセスで利用できます。Amazon Quick が利用できるすべての AWS リージョンで一般提供されています。
  • Kiro IDE 1.1 : Agent Artifacts とネイティブ ARM64 ビルド
    Kiro IDE 1.1 では、エージェントの出力を後から見返せる成果物として扱う Agent Artifacts が加わりました。ドキュメント、図、コード、画像などのエージェント出力をチャットの履歴に埋もれさせず永続的なアーティファクトとして残し、会話からコンパクトなプレビューを開く、Agent Focus でチャットの横に全体を表示してレビューする、Agent Focus のコンテキストパネルから後で戻る、といった使い方ができます。あわせて Windows と Linux 向けのネイティブ ARM64 ビルドが提供され、x64 エミュレーションに頼らずダウンロードページから各プラットフォーム用の ARM64 版を選べます。エディタの基盤は Code OSS 1.131 に更新され、コンパクションされた会話が適切なコンテキストを保持するようになったほか、MCP の失敗が分かりやすくなり、Hooks の信頼性が向上し、エンタープライズプロファイルが選択したリージョンへリクエストをルーティングするようになりました。
  • Kiro Model : GPT-5.6 Sol、Terra、Luna が 1M コンテキストウィンドウにアップグレード
    2026 年 9 月 14 日付の Kiro のモデル changelog です。Kiro IDE、CLI、Web で GPT-5.6 Sol、Terra、Luna のコンテキストウィンドウが 272K から 1M トークンに拡張され、あわせて GPT-5.6 ファミリーのクレジット倍率が更新されました。詳細は上記のブログ記事「Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応」をご参照ください。
  • Kiro CLI 2.22 : フルスクリーンチャットとセッション一覧の効率化
    Kiro CLI 2.22 では、インタラクティブな TUI セッションと Lite セッションでフルスクリーンチャットが使えるようになりました。/fullscreen と入力すると、現在の会話がシェルの履歴とは独立したスクロール可能な専用のターミナル画面に移り、もう一度 /fullscreen と入力するとインライン表示に戻ります。V2 と V3 のどちらでも利用でき、マウスやタッチパッド、キーボードでスクロールし、クリックとドラッグで選択したテキストをコピーできます。今後の TUI セッションを常にフルスクリーンで始めたい場合は /settings の Display で Start fullscreen をオンにします。V3 のセッションダッシュボードも整理され、/sessions では検索・フィルター・ソート・グループ化のコントロールがセッション一覧から分離され、最終利用順のフラットな一覧として開き、最終利用・セッション名・メッセージ数でのソートと選択内容の記憶に対応し、Tab キーでコントロールと結果の間を移動できます。あわせて、長時間にわたる作業の信頼性も改善されています。
  • Kiro Model : Claude Fable 5.1 のプレビューが Kiro Enterprise 向けに展開開始
    Kiro Enterprise の組織向けに、Claude Fable 5.1 のプレビューが Kiro の各クライアントで段階的に展開され始めました。1M のコンテキストウィンドウと 6 倍のクレジット倍率で提供され、推論は米国東部（バージニア北部）（us-east-1）のみで実行されます。有効化の手順やデータ保持の扱いなど詳細は上記のブログ記事「Claude Fable 5.1 が Kiro で利用可能になりました」をご参照ください。

最後に生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「AWS ジャパン生成 AI 実用化推進プログラム」をご用意しています。ぜひご活用ください。

今週は以上です。それでは、また来週お会いしましょう！

著者について