週刊生成AI with AWS – 2026/10/19 週

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

いつもご案内している生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラムについて、このプログラムの 1 コースである 「フィジカル AI 開発支援プログラム by AWS ジャパン」第 2 期 の応募受付が始まりました。VLA をはじめとするロボット基盤モデルや、VLM、世界モデルなどの周辺技術を AWS 上で開発する企業・団体が対象で、スタートアップから大企業、大学・研究機関まで応募できます。フィジカル AI のスペシャリストによる技術支援、コスト最適化、コミュニティ形成、GTM 支援が受けられ、第 1 期に応募した方も再応募が可能です。締切は 11 月 16 日（月）なので、ロボティクス × 生成 AI に取り組んでいる方は是非ご検討ください。
また、re:Invent 2026 のセッションカタログも公開されていますのでこちらもチェックしてみてください。

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

さまざまなニュース

• • AWS生成AI国内事例ブログ「約 3 万人のAIネイティブエンジニア体制へ ― NEC は Claude Code をどう全社展開しているのか？ CoE・チャンピオン制度による取り組み」
    NEC は全社員 (最大 12 万人) 向けに Claude Desktop on Amazon Bedrock を展開しています。開発現場では約 3 万人の AI ネイティブエンジニア体制を目指し、Claude Code on Amazon Bedrock の活用を広げています。成功要因として、各事業部門の推進体制 (部門 CoE)、チャンピオン制度、Skills による知見の標準化の 3 つを挙げています。2026 年 7 月と 8 月には NEC と AWS の共催で Claude Code ワークショップを開き、延べ 158 名が参加しました。アンケートでは 93% が開発業務で活用したいと回答しています。生成 AI ツールの定着を進める大規模組織にとって、推進体制と人材育成の組み合わせ方の具体例になります。
  • AWS生成AI国内事例ブログ「株式会社コーテッグ様の「聞くだけ」で分析が完結する AI 分析基盤「Dotta」を Amazon Bedrock AgentCore で実現」
    株式会社コーテッグは、自然言語で問いかけるだけでデータの取得・集計から可視化、レポート生成まで完結する AI 分析プラットフォーム「Dotta」を構築しました。Amazon Bedrock AgentCore を中核にした非同期の AI エージェント基盤です。分析処理は数十秒から数分かかるため、Amazon SQS と AWS Lambda から AgentCore Runtime を呼び出す構成にしています。分析には Claude Opus 4.8 / Sonnet 4.6、軽量な処理には Claude Haiku 4.5 と使い分けています。試算では 1 件 240 分の分析業務が約 10 分になります。長時間実行するエージェントを UI を止めずに本番運用する設計の実例として、エージェント基盤を検討中の方に役立ちます。
  • ブログ記事「Amazon Bedrock API キーの保護: 実装と管理のベストプラクティス」
    AWS は Amazon Bedrock の認証に AWS STS の一時的な認証情報を優先し、使えない場合のみ API キーを検討するよう推奨しています。API キーには短期キーと長期キーの 2 種類があります。短期キーの有効期間は IAM セッションと 12 時間の短い方で、長期キーは 1 日から無期限まで設定できます。防御では bedrock:BearerTokenType など 4 つの条件キーを SCP で使う方法を示します。検知では CloudTrail の callWithBearerToken フラグを拾う Amazon EventBridge ルール、対応では AWS CLI でキーを無効化・削除する手順を扱います。
  • ブログ記事「Amazon Bedrock における最小権限アクセスの実装」
    Amazon Bedrock を使うアプリケーションに最小権限の原則を適用する方法を、モデルの選択・適応・テスト・運用の 4 つのフェーズに沿って解説しています。Anthropic と Amazon のモデルだけを許可リスト方式で使えるようにする SCP や、AWS PrivateLink の VPC エンドポイントポリシーで呼び出せるモデルを限定する例を示します。条件キー bedrock:GuardrailIdentifier で特定のガードレールの利用を強制する方法も扱います。運用フェーズでは、モデル呼び出しログの閲覧権限を 3 つの IAM ロールに分ける構成を提案しています。ポリシー例をそのまま出発点にできるため、生成 AI 基盤の権限設計を任された方の時間を節約できます。
  • ブログ記事「AWS のサービスで構築する生成 AI アプリケーションのセキュアなネットワークアーキテクチャ」
    「生成 AI をセキュアにする」シリーズのパート 5 として、生成 AI アプリケーションを外部脅威から守るネットワーク設計を多層防御の観点で解説しています。DDoS 攻撃、ウェブリクエストフラッド、SQL インジェクションなどの脅威を整理したうえで、AWS PrivateLink による Amazon Bedrock API へのプライベート接続、AWS WAF の Bot Control と Anti-DDoS マネージドルールグループ、AWS Shield、AWS Network Firewall を順に紹介します。最後に Amazon CloudFront を入口にしたリファレンスアーキテクチャをまとめています。一般公開する前に、ネットワーク面の防御に抜けがないか確認するチェックリストとして使えます。
  • ブログ記事「スピードと安全性の両立: AI コーディングエージェントのためのコントロールフレームワーク」
    AI コーディングエージェントは、組織のリスクを理解しないままマシンの速度で動きます。記事はそのためのアプリケーションセキュリティ (AppSec) のフレームワークとして、プロンプトインジェクションやスコープクリープなど 7 つのリスクを整理し、対策を 2 つの柱に分けます。作成時 (author-time) はステアリングドキュメント、レビュー済みの仕様、MCP (Model Context Protocol) のツールアクセス制御で IDE 内の生成を方向付けます。ビルド時 (build-time) はシークレット検出・SAST・SCA・IaC のスキャンと品質ゲート、人間によるレビューで本番到達前に検証します。エージェント導入とセキュリティチームの承認を両立したい開発組織が、どこにガードレールを置くかを決める指針になります。
  • ブログ記事「Amazon Bedrock と LiteLLM による OpenAI ChatGPT Codex の予算・レート制限管理」
    OpenAI Codex のモデル推論を、お客様の AWS アカウント内に置いた LiteLLM ゲートウェイ経由で Amazon Bedrock 上の OpenAI モデルにルーティングする構成を解説しています。LiteLLM はオープンソースの AI ゲートウェイです。Amazon ECS (AWS Fargate) にデプロイし、モデルエイリアス、ユーザーやチーム単位のスコープ付きキー、予算とレート制限を一元管理します。ローカルのツール実行は引き続き開発者側の Codex が担います。代替経路として AWS IAM Identity Center による直接アクセスと Portkey も比較しています。コーディングエージェントの利用が個人の試行から全社導入に広がる段階で、誰がどれだけ使ったかを把握したい方に向いています。
  • ブログ記事「AWS DevOps Agent で調査コストを事前に制御する」
    AWS DevOps Agent の調査で、最初の課金対象クエリを実行する前にコストを見積もって予算と照合する、オープンソースのスキル「Investigation Cost Guardrail」を紹介しています。動詞ベースのルールや有料操作レジストリを含む 4 層で操作を分類し、AWS Price List API から対象リージョンの最新料金を取得します。判定は Proceed・Warn・Halt の 3 種類です。たとえば 9 月全体のログの相関分析は 2,673 GB のスキャンで $13.37 と見積もられ、デフォルト予算の $10.00 を超えるため停止します。GitHub の aws/tools-for-devops-agent から導入できます。エージェントに調査を任せたいが、ログのスキャン料金が読めないという運用チームの不安に直接応える内容です。
  • ブログ記事「AWS Physical AI Toolchain を発表」
    Physical AI Toolchain on AWS は、ロボットなどのフィジカル AI のポリシーを AWS 上でトレーニング・デプロイするための、リファレンスアーキテクチャと Infrastructure as Code を 1 つにまとめた一般公開のコレクションです。NVIDIA の GR00T (VLA モデルのトレーニング)、Isaac Sim (シミュレーション)、Isaac Lab (強化学習)、Cosmos (合成データ生成)、OSMO (オーケストレーション) を AWS のマネージドサービス上で 1 つのパイプラインとして動かします。GitHub の aws-samples リポジトリでワークショップもあります。工程間の引き継ぎに時間を取られているロボティクスチームが、基盤構築を省いてモデル改善に集中できます。
  • ブログ記事「AWS で AI を活用したスタジオを構築するためのガイダンス」
    スタジオが生成 AI をコンテンツ制作に組み込むためのプラットフォームアーキテクチャ「AI-Powered Studio」を紹介しています。設計の軸は Consistency (一貫性)、Context (コンテキスト)、Control (コントロール)、Compliance (コンプライアンス)、Cost (コスト) の 5 つの C です。中核はサーバーレスのオーケストレーションで、AWS AppConfig の設定変更だけでモデルを切り替えられます。来歴 (プロベナンス) は生成時に DynamoDB へ自動記録されます。モデルが数か月で入れ替わる中、特定ツールに依存せずに来歴と権利の説明責任を果たしたいメディア企業にとって、設計の土台になります。
  • ブログ記事「Kiro IDE と CLI にメモリ機能が登場」
    Kiro IDE と Kiro CLI にメモリ機能が導入されました。Kiro は、好みの作業の進め方、リポジトリ固有のコマンドや規約、受けた訂正、デバッグで得た知見、すでに除外したアプローチを覚えます。再び関係する場面で、そのコンテキストを引き継ぎます。メモリはマシンのローカルに保存され、そのマシン上の IDE と CLI で共有されます。IDE では Memories ビューで一覧・検索や削除ができ、CLI では /memories で確認やアクセス設定を行います。既定ではオフで、Kiro IDE 1.4.0 以降と Kiro CLI 2.29.0 以降のローカル V3 セッションで利用できます。セッションごとに同じ前提や訂正を繰り返している方は、その手間を減らせます。
  • ブログ記事「Kiro はどのように自らを修正し、その修正の正しさをどう担保しているか」
    Kiro のファイル読み取り・検索ツールの説明に、ハーネスの動作について事実と異なる一文がありました。この一文は数百のセッションで 61,742 回モデルに届いていました。Kiro チームは実行結果から改善を提案する社内システム kiro-trace を構築しました。変更の提案はモデルが行いますが、受け入れるか退けるかは決定論的なコードが 3 段階のゲートで判定し、最後に人がレビューしてマージします。最初の 1 週間で 7 件の修正がマージされ、会話の要約 (コンパクション) の保持率は 0.82 から 0.92 に改善しました。自社のエージェントを自己改善させたい開発者にとって、「提案する者と判定する者を分ける」という教訓がそのまま使えます。

サービスアップデート

• • Grok 4.7 が AWS GovCloud (US) の Amazon Bedrock で利用可能に
    AWS GovCloud (US) の Amazon Bedrock で、SpaceXAI の Grok 4.7 が利用できるようになりました。コーディング、エージェント型タスク、ナレッジワーク向けのフロンティアモデルです。Grok 4.6 より複数文書を混在させた入力の扱いとリポジトリ規模のコーディングの安定性が向上しています。GovCloud の要件がある米国公共部門のワークロードでも、最新のフロンティアモデルを選択肢に加えられます。
  • Amazon CloudWatch Omni が追加の AWS リージョンで利用可能に
    AI を活用したオブザーバビリティ体験である Amazon CloudWatch Omni が、新たに 8 つの AWS リージョンで利用できるようになりました。追加されたのは、東京リージョンを含む、カナダ (中部)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (ロンドン)、南米 (サンパウロ) です。CloudWatch Omni では、アプリケーションとエージェントの観測やトラブルシューティングを 1 か所で行えます。チャット操作から AWS DevOps Agent による根本原因の特定まで進められます。国内にデータを置いたまま、AI による障害調査を運用に取り入れられるようになります。
  • AWS が TorchNeuron を発表: AWS Trainium 向けのネイティブ PyTorch サポート (パブリックベータ)
    AWS Trainium 向けのオープンソースのネイティブ PyTorch バックエンド、TorchNeuron のパブリックベータが公開されました。PyTorch コードを .to('neuron') に切り替えるだけで Trainium 上で動かせます。eager 実行、torch.compile、標準の PyTorch API との互換性は維持されます。Neuron Kernel Interface (NKI) と統合され、カスタムオペレーターも実装できます。Amazon EC2 の Trainium2 と Trainium3 インスタンスで使えます。既存の PyTorch コードを大きく書き換えずに Trainium のコスト効率を試せる点が、移行を検討するチームにとっての価値です。
  • Amazon Bedrock Advanced Prompt Optimization がプロンプト短縮に対応
    Amazon Bedrock Advanced Prompt Optimization に、評価スコアを維持または改善しながらプロンプトの長さを削減するオプション設定、プロンプト短縮が追加されました。これまでは最適化後のプロンプトが元より長くなることが多く、入力トークンのコストや最初のトークンが返るまでの時間を増やす要因になっていました。有効にすると、元より短く、かつ評価で同等以上のスコアを得た場合にのみ最適化後のプロンプトが返されます。Advanced Prompt Optimization が利用できるすべての AWS リージョンで使えます。品質を落とさずに推論コストとレイテンシーを下げたい本番アプリケーションで、手作業のプロンプト圧縮を置き換えられます。
  • Amazon Bedrock Guardrails がコンテキストグラウンディングチェックの Standard ティアに対応
    Amazon Bedrock Guardrails のコンテキストグラウンディングチェックに Standard ティアが追加されました。この機能は、モデルの応答が参照ソースに基づき、ユーザーの質問に関連しているかを確認してハルシネーションを検出・フィルタリングします。Standard ティアは推論や会話的な内容を含む応答に対応し、対応言語も広がりました。料金は Classic ティアと同じで、利用にはガードレールプロファイルを使ったクロスリージョン推論が必要です。東京リージョンを含む次の AWS リージョンで利用できます: 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、アジアパシフィック (東京)。会話型の RAG アプリケーションでも、同じ料金で根拠のない回答をより確実に抑えられます。
  • Amazon WorkSpaces が、運用・管理するインフラを減らしつつ、エンタープライズクラウドデスクトップへの AI エージェントの安全なアクセスを簡素化
    WorkSpaces for AI agents が、認証とデスクトップ接続をマネージドな MCP (Model Context Protocol) サービスの一部として処理するようになりました。カスタムコードを書かずにエージェントを統制されたクラウドデスクトップに接続でき、MCP に対応するあらゆるクライアントから WorkSpaces を利用できます。手動だったストリーミング URL の生成とローテーションが不要になり、既存の AWS 認証情報を使った OAuth 2.0 で接続のライフサイクルをサービス側が管理します。エージェントのセッションは、人間の従業員と同じネットワーク分離とコンプライアンスの境界内で実行されます。新たに南米 (サンパウロ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (マレーシア) でも利用できます。GUI 操作が必要な社内アプリケーションをエージェントに任せたいが、セキュリティ境界は崩したくない企業にとって現実的な選択肢になります。
  • Polly の Generative エンジンがアップグレード: より自然な音声、14 の新しい音声、2 つの新言語
    Amazon Polly の Generative エンジンに新しい基盤モデルが導入され、より自然で正確な音声を低レイテンシーで出力できるようになりました。9 つのロケールにわたる 14 の新しい音声が追加され、ヒンディー語とフィンランド語が Generative エンジンで初めて一般提供されました。ストリーミング API により、LLM ベースの音声エージェントをリアルタイム会話向けに構築できます。新しい Generative 音声は、東京リージョンを含む次の AWS リージョンで利用できます: 米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ロンドン)、アジアパシフィック (シドニー)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、カナダ (中部)、AWS GovCloud (米国西部)。音声エージェントの応答品質を上げたい方は、東京リージョンでそのまま試せます。
  • Amazon Bedrock で Claude モデルの構造化出力が利用可能に
    Amazon Bedrock が、bedrock-runtime と bedrock-mantle の両エンドポイントで、すべての Anthropic Claude モデルの構造化出力に対応しました。定義したスキーマに従う JSON 応答を受け取れるため、独自のパース処理やリトライロジックは不要です。Claude モデルが利用できるリージョンで使えます。抽出結果の形式崩れに対処するコードを書いて保守してきた方は、その負担から解放されます。
  • AWS Neuron 2.33 がネイティブ PyTorch サポート、Neuron Observer などの新機能を追加
    AWS Neuron 2.33 がリリースされ、AWS Trainium 向けのネイティブ PyTorch バックエンドである TorchNeuron がパブリックベータとして導入されました。PyTorch のモデルを Amazon EC2 Trn2 および Trn3 インスタンス上で eager モードまたは torch.compile で実行できます。あわせてパブリックベータの Neuron Observer が導入され、Trainium の健全性の問題を 1 秒未満で検出し、影響を受けたノードやデバイスを特定します。NKI Library には DeepSeek-V3.2、Qwen3.5、Kimi Delta Attention 向けを含む 25 の実験的カーネルが追加されました。大規模学習でノード障害の特定に時間を取られているチームにとって、Neuron Observer は停止時間の短縮につながります。
  • Amazon SageMaker AI がサーバーレスモデルカスタマイズジョブでカスタムシーケンス長に対応
    Amazon SageMaker AI のサーバーレスモデルカスタマイズジョブで、学習時に使うシーケンス長を設定できるようになりました。これまでは各レシピが固定のシーケンス長で実行されていましたが、モデルと手法の公開上限 (多くのモデルで最大 16K トークン) までの範囲でハイパーパラメータとして指定できます。SFT と DPO では dataset_max_len を、RFT では max_prompt_length と max_response_length を使います。東京リージョンを含む、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用できます。複数ページの文書を学習データにしたいのに切り詰められていた、という課題を解消できます。
  • Reflection の Beam モデルが Amazon SageMaker JumpStart と AWS Trainium で利用可能に
    米国の Reflection が提供する初のオープンウェイトモデル Beam が、Amazon SageMaker JumpStart で利用できるようになりました。推論、コーディング、エージェント型のベンチマークで高い性能を示し、Apache 2.0 ライセンスで公開されています。ファインチューニングや重みの検査・変更を行い、自身の AWS アカウント内で実行できます。AWS Trainium3 向けに最適化され、当初は米国東部 (バージニア北部) と米国東部 (オハイオ) で BF16、FP8、NVFP4 のチェックポイントをデプロイできます。モデルの重みとデータを自社の管理下に置きつつフロンティア級の性能を求める組織にとって、新しい選択肢になります。
  • AWS Continuum for code vulnerabilities が一般提供開始
    AWS Continuum for code vulnerabilities が一般提供を開始しました。コードの脆弱性をマシンスピードで発見、検証、優先順位付けし、修正する機能です。AWS 環境のリソース、アイデンティティ、ネットワーク到達性からコンテキストグラフを構築し、検出結果を隔離されたサンドボックスでテストして悪用可能なものを確認します。修正パッチはプルリクエストとして開発者のワークフローに届きます。利用開始時はユーザーが承認する Learn モードで動作し、信頼が高まれば自律的に動く Enforce モードに切り替えられます。大量のアラートのうち、本当に対処すべきものだけに人手を割きたいセキュリティチームの負荷を下げます。
  • AgentCore Gateway が Bedrock InvokeModel API とモデルフォールバックに対応
    Amazon Bedrock AgentCore Gateway の推論エンドポイントが、Amazon Bedrock の InvokeModel API と InvokeModelWithResponseStream API に対応し、モデルフォールバックルーティングも追加されました。既存の Amazon Bedrock SDK の統合をそのままゲートウェイに向けるだけで、統制された 1 つのエンドポイントから任意のモデルプロバイダーに到達できます。モデルフォールバックでは、プライマリの宛先がスロットリング、容量不足、到達不能の場合に自動で代替のモデルやプロバイダーに振り分け、組み込みのサーキットブレーカーが失敗中の宛先をスキップします。Amazon Bedrock AgentCore Gateway が利用できるすべての AWS リージョン (中国リージョンを除く) で使えます。各クライアントにリトライ処理を書き込まずに、エージェントの可用性を基盤側で確保できます。
  • Amazon OpenSearch Service が Amazon S3 のログとドキュメント向けのインテリジェントインジェストを発表
    Amazon OpenSearch Serverless に、Amazon S3 に保存されたログやドキュメントを OpenSearch Serverless (NextGen) コレクションで検索可能にするフルマネージド機能、インテリジェントインジェストが追加されました。コンソールの数クリック、または 1 回の API 呼び出しで設定でき、JSON 形式のログと、PDF、Word、プレーンテキスト、Markdown 形式の非構造化ファイルに対応します。ドキュメントの解析、画像の説明生成、チャンク化、ベクトル埋め込みの生成、インデックス作成までを自動で行い、料金はアクティブな処理分のみです。東京リージョンを含む AWS リージョンで利用できます。RAG 用のインデックス構築パイプラインを自作・保守してきたチームは、その工程をまるごと置き換えられます。
  • Amazon SageMaker AI がサーバーレスモデルカスタマイズ向けのトレーニングセッション API を発表
    Amazon SageMaker AI のサーバーレスモデルカスタマイズに、トレーニングセッション API が追加されました。GPU インフラを管理することなく、チーム自身がトレーニングループを記述し、カスタム損失関数や新しい RL 報酬信号などを実装できます。forward_backward()、optim_step()、sample() といった操作がライブセッションへの API 呼び出しになり、GPU の割り当て、分散実行、障害復旧は SageMaker AI が担います。課金は処理トークン単位です。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ) で一般提供されています。既成のレシピでは足りない研究寄りのポストトレーニングを、GPU クラスターを持たずに試したいチームに向いています。
  • Amazon SageMaker AI が Muse Glimmer、Qwen 3.8、Ministral 3 モデルのサーバーレスモデルカスタマイズに対応
    Amazon SageMaker AI のサーバーレスモデルカスタマイズが、Muse Glimmer、Qwen3.8 27B、Ministral 3 の 3B、8B、14B モデルに対応しました。教師ありファインチューニング (SFT)、直接選好最適化 (DPO)、強化ファインチューニング (RFT) で適応させられ、LoRA (低ランク適応) とフルファインチューニングのどちらも選べます。東京リージョンを含む、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用できます。小さなモデルを自社データで調整してコストとレイテンシーを下げたい場合に、選べるベースモデルの幅が広がります。
  • Web Search on Amazon Bedrock がドメインフィルタリングとユーザー位置情報の制御に対応
    Web Search on Amazon Bedrock に、ドメインフィルタリングとユーザー位置情報が追加されました。どちらも OpenAI Responses API リクエスト内の web_search ツールで設定します。ドメインフィルタリングでは、最大 100 件の allowed_domains で信頼できるソースに結果を限定したり、最大 100 件の blocked_domains で不要なソースを除外したりできます。ユーザー位置情報では、その地域に関連する結果を返せます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、AWS GovCloud (米国西部) で利用できます。公式サイトや指定ソースだけを根拠にした回答が求められる業務用途で、検索結果の出所を統制できます。
  • Kiro : Claude Haiku 5.5 が利用可能に
    Kiro で Claude Haiku 5.5 が実験的 (Experimental) サポートとして利用できるようになりました。対象は Pro、Pro+、Pro Max、Power のお客様で、us-east-1 (IAD) と eu-central-1 (FRA) において Kiro IDE、CLI、Crew、Web から使えます。1M トークンのコンテキストウィンドウを持ち、クレジット倍率は 100K トークンまでのリクエストが 0.06x、100K トークンを超えるリクエストは 0.3x です。定型的な変更や大量のファイル処理を低コストでこなしたい場面で、クレジットの節約につながります。
  • Kiro : Claude Fable 5.1、Claude Sonnet 5.5、GPT-5.6 Terra、GPT-5.6 Luna が一般提供開始
    Claude Fable 5.1、Claude Sonnet 5.5、GPT-5.6 Terra、GPT-5.6 Luna が、Kiro の完全なサポート付きで一般提供になりました。GPT-5.6 Sol は引き続き Experimental です。Fable 5.1 は米国東部 (バージニア北部) (us-east-1) の Kiro Enterprise 組織向けに、Sonnet 5.5 は Kiro IDE、CLI、Crew、Web で、GPT-5.6 Terra と Luna は Kiro IDE、CLI、Web で利用できます。Sonnet 5.5、Terra、Luna は米国と EU の地域で Pro、Pro+、Pro Max、Power のお客様が利用できます。Preview と Experimental のラベルが外れ、Kiro Excluded Models の補償 (indemnity) 例外も適用されなくなりました。試験的な扱いが理由でこれらのモデルを本番で使えなかった組織は、補償の面でも採用を検討しやすくなります。
  • Kiro CLI 2.34.0 : MCP Elicitation、ワークフローの制御、メモリの削除
    Kiro CLI 2.34.0 では、ローカルの V3 セッションで MCP ツールが入力を求められるようになりました (MCP Elicitation)。追加情報が必要なときにツールが一時停止してフォームやリンクを表示し、利用者は入力、別ページでの操作、拒否を選べます。ワークフローでは、V3 のプラン承認時に変更案を直接入力するとステップの実行前にプランが更新され、新しい Workflow use 設定で Only when asked、Only for large tasks、As much as possible からワークフローを開始するタイミングを選べます。/memories でメモリを削除、/model edit で使わないモデルを非表示にできます。ツールが足りない情報を聞き返せるようになったことで、認証や確認が必要な MCP 連携を途中で諦めずに進められます。
  • Kiro CLI 2.33.1 : ワークフローは依頼したときだけ開始
    Kiro CLI 2.33.1 では、V3 の Workflows の開始方法が変わりました。機能を有効にしただけではワークフローは開始されず、明示的に依頼したときだけ実行されます。修正では、スクリーンリーダー使用時に /tools が各ツールの Source、Status、Description を 1 行ずつラベル付きで表示するようになりました。V2 セッションを V3 で再開する際は、保存済みのツール承認が引き継がれないことと、V3 で承認を維持する方法が案内されます。画像の多い長い V3 セッションがリクエスト上限で失敗する問題なども修正されました。小さな依頼のたびにワークフローが立ち上がって待たされていた方は、通常のチャットの軽快さが戻ります。
  • Kiro CLI 2.33.0 : ワークスペースの信頼、ワークフロープランのステップツリー、Mermaid サブグラフ
    Kiro CLI 2.33.0 では、対話型の V3 セッションにワークスペースの信頼 (workspace trust) が追加されました。フォルダで初めて V3 セッションを開始すると、そのフォルダの hooks、エージェント、MCP サーバー、steering、ワークフロー設定を読み込む前に「Trust this workspace?」画面が表示されます。回答はワークスペースルートごとに ~/.kiro/workspace-roots/ に保存されます。V3 セッションではモデルフォールバックの設定が再び可能になり、ワークフローのプラン承認はコンパクトなステップツリーで表示されます。クローンしたリポジトリに含まれる設定が、許可なくエージェントの挙動を変えるリスクを防げます。外部コードを扱う機会の多い方ほど効果があります。
  • Kiro IDE 1.4.26 : Kiro がワークフローを使うタイミングを選択
    Kiro IDE 1.4.26 では、チャットの Workflows パネルに Use workflows の設定が追加され、Only when asked、Only for large tasks、As much as possible から Kiro がワークフローを開始する頻度を選べるようになりました。新しいチャットは Only when asked で始まり、選択は新しいローカルチャットにも記憶されます。あわせて、Kiro CLI でインストールした Powers が Powers パネルの Installed 一覧に表示され続けるようになり、Memory 設定はレベル未選択の場合にデフォルトの Off が適用されます。タスクの大きさに応じて単発のチャットと多段のワークフローを使い分けたい方が、その判断を Kiro に任せる度合いを自分で決められます。
  • Kiro IDE 1.4.10 : Memory 設定のデフォルトが Off に、ワークフロープランへのフィードバック、Powers の耐障害性向上
    Kiro IDE 1.4.10 では、Kiro Agent: Memory 設定のデフォルトが Off に変わりました。Use and learn、Use but don’t learn、Use only のいずれかを選ぶとメモリの使い方を設定でき、すでに選んでいる場合はその選択が維持されます。ワークフローでは、提案されたプランに変更を求めると、承認後のステップが利用者の修正に沿うようになりました。Powers は、MCP サーバーへの接続に失敗してもそのサーバーなしでターンが実行されます。画像の多い会話が拒否されたりコンパクションに失敗したりする問題に対しては、古い画像を省いて要約を再試行するようになりました。スクリーンショットを多く貼り付けて作業するセッションが途中で止まっていた方には、安定性の改善につながります。
  • Kiro IDE 1.4.0 : チャットセッションをまたぐ Memory
    Kiro IDE 1.4.0 で Memory が導入されました。リポジトリの規約、修正指示、すでに却下したアプローチといった有用なコンテキストを、セッションをまたいで引き継げます。アクティビティバーの Memories アイコンから Memory ビューを開き、Kiro が記憶している内容を確認でき、メモリへのアクセスや変更はチャットに表示されます。Kiro Agent: Memory 設定では、メモリを変更せずに使うだけの Use only も選べます。Markdown Review の検索改善と、Ubuntu 24.04 以降で .deb パッケージからインストールした Kiro が起動しない問題の修正も含まれます。何を覚えさせるかを自分で管理したい方は、Use only から安全に試し始められます。

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

著者について