CSVファイルの規約におけるセル内改行の扱いや、スクリプトで加工する際の注意点について解説します。PowerShellやPythonのライブラリなど、改行を含むCSVデータを正しく処理する方法についても触れています。

本記事は 2026 年 4 月 29 日に公開された、 Features and workflows with Amazon Timestream for InfluxDB 3 を翻訳したものです。 本記事では、時系列データベースの技術を大きく進化させた Amazon Timestream for InfluxDB 3 のアーキテクチャ設計、機能、ケイパビリティについて、技術的な観点で解説します。この次世代時系列データベースは、従来のエンジンバージョンからアーキテクチャが再設計されています。コア性能を支える Rust、列指向データ処理を実現する Apache Arrow 、効率的なストレージを提供する Apache Parquet 、高性能クエリを可能にする Apache Arrow Flight SQL といったモダンなテクノロジーでゼロから構築されています。 このマネージドサービスは、InfluxData の最新データベースと AWS のインフラストラクチャおよびツールを組み合わせ、お客様の時系列データワークフローをサポートします。Amazon Timestream for InfluxDB 3 を今すぐ使い始めるには、 ドキュメント をご覧ください。 新しいエンジンの機能 InfluxDB 3 のコアエンジンは、ストレージフォーマット、クエリエンジン、ネットワークプロトコルにオープンソースのテクノロジーを使用してゼロから設計された、オープンソースソリューションです。Apache Arrow Flight SQL が InfluxDB 3 の新しい高性能 SQL インターフェイスとして導入されたことで、バージョン 2 で使われていた Flux のような独自言語を使用してクエリする必要がなくなりました。ネイティブ SQL のサポートにより、データベースとのやり取りの障壁が下がり導入が容易になるだけでなく、 Amazon S3 などのオブジェクトストレージに大量のデータを保存できるエンジンの特性を活かし、分析指向のユースケースにも対応しやすくなります。オブジェクトストレージを活用することで、大規模なデータセットを手頃なコストで保持しつつ、Parquet の効率的な列指向フォーマットと Apache Arrow のインメモリ機能により優れたパフォーマンスを実現します。 InfluxDB 2 から得た知見を基に、InfluxDB 3 は InfluxDB 2 では対応できなかったユースケースに対応しています。InfluxDB 3 では、アーキテクチャの変更により、事実上無制限のカーディナリティをサポートしています。変動の大きいデータセットでも、インデックス付きタグとデータベースパフォーマンス低下のトレードオフを気にする必要がなくなりました。InfluxDB 3 はコアなストレージレイヤーとして Amazon S3 を使用しており、Amazon S3 のマルチ AZ アーキテクチャと 99.999999999% のデータ耐久性の恩恵を受けながら、永続ストレージのコスト削減も実現します。 InfluxDB 3 には、時系列データの収集、整理、変換のための新しくて強力な処理エンジンが統合されています。処理エンジンは InfluxDB 3 に組み込まれた Python 仮想マシンであり、時系列データに対してゼロコピー操作を実行できます。例えば、ストレージコストとデータ量を削減するためのダウンサンプリングや、閾値条件や異常検知に基づいて通知をトリガーするためのアラームといった、リアルタイムでのデータ処理機能が利用できます。Python で記述されたプラグインで、トリガーイベントを契機として処理エンジンがデータに対して何をどのように実行するかを定義します。トリガーイベントの種類には、スケジュールされたイベントと WAL フラッシュイベントがあります。Amazon Timestream for InfluxDB 3 には、セキュリティ強化が施された処理エンジンプラグインが用意されています。Timestream for InfluxDB 3 で利用可能なプラグインの一覧は、 処理エンジンのドキュメント で確認できます。 豊富な新機能により、InfluxDB 3 は変動の大きいデータを扱うシステム、直近のデータに対する最適化されたクエリを必要とするワークフロー、マルチノードソリューションを必要とする大量のデータ取り込みに最適です。ユースケースとしては、システムモニタリング、アプリケーションモニタリング、IoT センサーデータなどがあります。また、InfluxDB 3 は、現在メンテナンスモードにある Amazon Timestream for LiveAnalytics の後継として、拡張された機能、優れた柔軟性、そして AWS における時系列ワークロードの今後の道筋を提供します。 Core エディションと Enterprise エディション AWS では、InfluxDB 3 を Core エディションと Enterprise エディションの 2 つで提供しており、それぞれ特定のユースケースに最適化された異なる機能を備えています。両エディションともストレージレイヤーに S3 を使用していますが、アーキテクチャ、想定されるワークロード、料金モデルは大きく異なります。 Amazon Timestream for InfluxDB Core は、直近のデータ（集計要件やタイムスタンプの粒度に応じて通常は過去 3〜5 日間）を常時効率的にクエリする必要があるリアルタイムモニタリングシナリオ向けに設計されています。Core は、高速なクエリレスポンスタイム、ディスクレスアーキテクチャ、Parquet ファイルの永続化、処理エンジンなど、時系列ワークロードに不可欠な機能を提供します。ただし、Core クラスターは単一ノードデプロイに制限されており、データの取り込み、クエリ、圧縮、プロセッシングの 4 つの主要機能が同一インスタンス上で実行され、これらの機能が限られたコンピューティングリソースを共有して使用します。特に、Core にはコンパクター（圧縮を行うコンポーネント）が含まれていないため、大量の時系列履歴データを効率的に保存およびクエリする機能が制限されます。そのため、直近のデータに焦点を当てたユースケースに最適です。 Core クラスターの場合、コストは主にコンピューティングとストレージの料金で構成されます。例えば、バージニア北部リージョン (us-east-1) で db.influx.large インスタンス (2 vCPU) を 1 台使用する場合、コンピューティング料金は 1 時間あたり約 $0.264 × 月 730 時間 = 月額 $192.72 に加え、ストレージ料金が 1 GB あたり $0.023 となります。Core の料金の詳細については、 料金ページ をご覧ください。 Amazon Timestream for InfluxDB Enterprise は、履歴データの保持と分析を必要とする本番ワークロード向けに設計されており、Core の機能を拡張します。Enterprise クラスターにはコンパクター（圧縮を行うコンポーネント）が含まれており、大量の履歴データを保存しつつ、パフォーマンスへの影響を最小限に抑えて効率的にクエリできます。また、Enterprise はマルチノードクラスターデプロイをサポートしており、異なるノードに個別の役割を割り当てることで、データの取り込み、クエリ、圧縮、プロセッシングの各機能を分離し、リソース使用率を最適化できます。Enterprise のその他の機能には、細かいアクセス制御、より柔軟に設定可能なデータ保持ポリシー、高負荷な本番環境向けに強化されたスケーラビリティが含まれます。 InfluxDB 3 Enterprise は、データの取り込みとクエリ負荷の要件に合わせて最大 15 ノードのクラスター構成で利用できます。1〜4 のライターノード、0〜13 の読み取り専用ノード、1 つのコンパクターノードから選択できます。すべてのマルチノードデプロイメントでは、クラスターの可用性を最大化するために異なるアベイラビリティゾーンにインスタンスを分散させます。 Enterprise の料金には、コンピューティングとストレージのコストに加えて、 AWS Marketplace を通じて自動的に有効化される InfluxDB 3 Enterprise ライセンスが含まれます。Enterprise ライセンスは従量課金制で、ノードあたりの時間単位で課金されます。例えば、バージニア北部リージョン (us-east-1) で db.influx.large インスタンス 3 台のクラスターを使用する場合、おおよそのコストは以下のとおりです。 コンピューティング : $0.264/時間 × 3 ノード × 730 時間 = $578.16/月 ライセンス : $0.264/時間 × 1.5 × 3 ノード × 730 時間 = $867.24/月 コンピューティング + ライセンスの合計 : $1,445.4/月、これにストレージ料金 1 GB あたり $0.023 が加算 Enterprise の料金の詳細については、 AWS Marketplace listing をご覧ください。 InfluxDB 3 への時系列データの書き込み 時系列データに InfluxDB を使用するメリットの 1 つは、データ取り込みに使用される人間が読みやすいラインプロトコルテキスト形式です。ラインプロトコルはシンプルで可読性が高いため、InfluxDB が初めてでも始めやすく、複雑なフォーマット要件なしにデータ取り込みのテスト、データモデルの微調整、取り込みパスのデバッグを迅速に行えます。ラインプロトコルは InfluxDB 1 から使用されており、InfluxDB 3 でも引き続き標準として採用されているため、既存ユーザーは継続して使用できます。InfluxDB 1 または 2 からワークフローを移行する際、ラインプロトコルをそのまま使い続けられるだけでなく、InfluxDB 3 では v1・v2 との下位互換性がある書き込みエンドポイントも利用できます。この互換性により、既存のアプリケーション、スクリプト、ツールは変更なしにデータの書き込みを行うことができ、InfluxDB 3 へのアップグレード時に既存の時系列ワークフローの移行をスムーズに行えます。 InfluxData は、InfluxDB 3 へのデータ取り込み用のクライアントライブラリセットを提供しています。これらのライブラリはアプリケーションと統合することで、バッチ処理、ラインプロトコルの構築、gRPC を使用した Arrow Flight プロトコルによるクエリのためのボイラープレートコードを別途記述することなく、データの書き込みとクエリを実行できます。クライアントライブラリは C# .NET、Go、Java、JavaScript、Python で利用可能です。クライアントライブラリの詳細については、「 Client libraries for InfluxDB 3 」を参照してください。 クエリと DSL InfluxDB 3 は、Apache DataFusion をクエリエンジンとして、Apache Arrow Flight SQL をネットワークプロトコルとして使用することで、標準 SQL を主要なクエリ言語として採用しました。このアーキテクチャの転換により、InfluxDB 2 の Flux スクリプト言語が、馴染みのある SQL 構文に置き換わり、学習コストが大幅に低下するとともに、既存の SQL ツールやビジネスインテリジェンスアプリケーションとのシームレスな統合が可能になります。 Apache Arrow Flight SQL は、効率的な列指向データ転送と gRPC ベースの通信を使用して、従来の HTTP ベースのインターフェイスと比較して優れたパフォーマンスの向上を実現します。基盤となる Apache Arrow の列指向フォーマットにより、ベクトル化実行や述語プッシュダウンが可能になり、大規模なデータセットに対する生データクエリと集計クエリの両方でパフォーマンスが向上します。Apache DataFusion のクエリオプティマイザは、フィルターやプロジェクションのプッシュダウンによりデータ処理を最小化し、パフォーマンスをさらに向上させます。 InfluxDB 3 は、リアルタイム分析向けに設計された専用キャッシュ戦略により、時系列ワークロードのクエリパフォーマンスを最適化します。2 つのインメモリキャッシュが最も一般的なクエリパターンを高速化します。 Last Value Cache (LVC) は各フィールドの最新値を保存し、リアルタイムダッシュボードで使用される「最終ポイント」を取得するクエリをミリ秒のレスポンスタイムで返します。 Distinct Value Cache (DVC) はテーブル内の一意なタグ値とフィールド値を保持し、ホスト名やセンサー ID の一覧表示などのメタデータクエリを高速化します。これらのキャッシュにより、一般的なクエリパターンがほぼ瞬時に実行され、大量のデータ取り込みが行われている最中でもダッシュボードの応答性が維持されます。これらの最適化により、InfluxDB 3 は直近のデータ（通常は過去 3〜5 日間）に焦点を当てたモニタリングユースケースに特に効果的であり、これはリアルタイム分析向けの Core エディションの設計と合致しています。 移行の互換性と幅広いデプロイシナリオに対応するため、InfluxDB 3 はモダンな SQL インターフェイスに加えて v1 互換の InfluxQL エンドポイントを提供しており、レガシーアプリケーションを変更なしに引き続き運用できます。InfluxDB 3 Explorer と Timestream for InfluxDB の利用を開始するには、 InfluxData のドキュメント を参照してください。 Explorer ユーザーインターフェイス InfluxDB 3 は、InfluxDB 3 Explorer のグラフィカルインターフェイスを通じて管理できます。 InfluxDB 3 Explorer を使用すると、データベースの管理、データの取り込みやクエリ、可視化など、さまざまな操作を実行できます。Timestream for InfluxDB 3 で InfluxDB 3 Explorer を使用するには、 InfluxData のクイックスタートガイド に従って Docker で Explorer を実行してください。 データベースの管理 Explorer では、InfluxDB 3 インスタンスのホストアドレスと、関連付けられたトークンを指定して新しい接続を作成できます。インスタンスが追加され検証されると、Explorer を使用してデータベースを管理できます。Explorer では、新しいデータベースの作成や既存のデータベースの削除が可能です。 データのクエリと可視化 InfluxDB 3 Explorer 内の Data Explorer を使用すると、SQL クエリを実行したり、自然言語を使用してデータを確認できます。InfluxDB 3 の SQL 実装の詳細については、 InfluxData の SQL reference documentation を参照してください。 結果は Explorer 内で折れ線グラフや棒グラフとして表示でき、CSV、JSON、Parquet にエクスポートすることもできます。さらに、結果をダッシュボードに追加して、データのインサイトを整理することもできます。 現行バージョンの Explorer は、Timestream for InfluxDB 3 エンジンの基本を理解し、クエリ構文を試し、管理オプションに慣れることを目的として設計されている点に留意してください。パフォーマンステスト、複雑なクエリパターン、本番ワークロードに必要な機能は、InfluxDB CLI または API ですべて利用できます。Explorer は、より高度なツールに移行する前にシステムの基本を安全に学べる学習環境として活用してください。 データの取り込み Explorer から直接データを取り込むことができます。Explorer には、ラインプロトコル、InfluxDB 3 のクライアントライブラリ、InfluxDB 3 の REST API、Telegraf の使用方法、CSV や JSON データのインポート方法、サンプルデータの取り込み方法など、InfluxDB へのデータ書き込みを支援するガイドが用意されています。 すぐに使い始められるよう、Explorer 内からサンプルデータを取り込むことができます。サンプルデータセットには、大気質センサーデータ、鳥の渡りデータ、ビットコインの過去の価格と取引量データ、気候データが含まれます。 デプロイメントの監視 インスタンスのデプロイ後、サイジングの妥当性を検証し、最適化の余地がないかを確認するため、パフォーマンスをモニタリングすることが重要です。Amazon CloudWatch は、CPU 使用率やメモリ使用量など、Timestream for InfluxDB 3 の重要なメトリクスを提供します。InfluxDB 3 の処理エンジンに含まれる System Metrics Plugin は、CloudWatch と同様のサーバーレベルのパフォーマンスデータを収集します。これには、詳細な CPU 統計（全体およびコアごと）、メモリ使用量の内訳、ディスク I/O パフォーマンス、ネットワークインターフェイス統計が含まれます。 データベース固有のパフォーマンスメトリクスについてより深い洞察を得るには、メトリクスエンドポイントをスクレイピングすることで、クエリパフォーマンス、書き込みスループット、その他のサービスレベル指標を詳細にモニタリングするための包括的な内部メトリクスを収集できます。Timestream for InfluxDB インスタンスの /metrics エンドポイントをスクレイピングする包括的なメトリクス収集ソリューションを提供しています。このソリューションは、Telegraf を実行する EC2 インスタンスをデプロイし、クエリパフォーマンス、書き込みスループット、メモリ使用パターンなどの内部エンジンメトリクスを継続的に収集した後、CloudWatch に取り込み、事前設定された Grafana ダッシュボードで可視化します。ダッシュボードには、インスタンスのサイジング仕様に基づく主要パフォーマンス指標をモニタリングするパネルが含まれており、サイジングの判断の検証と最適化の機会の特定に役立ちます。 デプロイ手順、設定オプション、サンプルスクリプトについては、 GitHub リポジトリ をご覧ください。リポジトリには、Telegraf の設定から Grafana ダッシュボードの作成まで、セットアッププロセスを自動化する完全な CDK アプリケーションが含まれています。 まとめ Apache Arrow、Parquet、Flight SQL を採用した InfluxDB 3 の再設計により、ビジネスニーズに対してパフォーマンス上のメリットと長期的な相互運用性を提供するオープンソースフレームワークが構築されました。ネイティブ SQL サポートにより独自のクエリ言語を学ぶ負担が軽減され、処理エンジンの組み込み Python ランタイムによりゼロコピーのデータ変換が可能になります。 InfluxDB 3 Explorer は、データベース管理、クエリの実験、データの可視化に使用できます。本番環境への移行に際しては、CloudWatch 統合やメトリクス収集によるモニタリングソリューションがパフォーマンス特性の可視性を確保します。 InfluxDB 3 は、統合された処理エンジン、無制限のカーディナリティサポート、コスト効率の高い S3 データストレージにより、強力な新機能を提供します。 Amazon Timestream for InfluxDB 3 にアクセスしてクラスターをデプロイし、この新しい時系列データベースで利用可能なすべての機能を実際にお試しください。 著者について Victor Servin Victor は AWS の Amazon Timestream チームのシニアプロダクトマネージャーです。プロダクトレッドグロース戦略やスケーラブルなアーキテクチャでスタートアップを支援してきた長年の専門知識を持ち、データドリブンなアプローチで Timestream のような分析プロダクトの普及を推進しています。豊富な経験とカスタマーサクセスへの取り組みにより、お客様が効率的に目標を達成できるようサポートしています。 Forest Vey Forest は Improving 社のチームリードです。時系列およびサーバーレステクノロジーの経験を持ち、クラウド開発と組み込みシステムへの情熱が高まっています。ソフトウェア開発の学習以外の時間では、友人とのロッククライミングやハイキングを楽しんでいます。 Trevor Bonas Trevor は Improving 社のシニアソフトウェア開発者です。時系列データベースと ODBC ドライバーの開発経験があります。プライベートでは小説の執筆や、ゲーム開発にも取り組んでいます。 Fred Park Fred は Improving 社のシニアソフトウェア開発者で、時系列データベースと AI エージェントのオブザーバビリティを専門としています。VR やクラウドサービスから量子コンピューティングまで幅広いバックグラウンドを持ち、新しいテクノロジーに惹かれています。コーディング以外の時間は、ハイキングに出かけたり友人と音楽を作ったりしています。 本記事の翻訳はクラウドサポートエンジニアの平出が担当しました。

みなさん、こんにちは。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 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。