みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 さて、 re:Invent 2026 のセッションカタログ はもうチェックされましたでしょうか？2200を超えるセッションが登録されておりカタログを参照するだけでも楽めます。 10月になり、builders.flash も生成 AI 関連の記事が 新規公開されました。ぜひこちらもご覧ください。 builders.flash 記事 builders.flash 記事「 既存プロダクトに Amazon Bedrock AgentCore runtime でLLM ワークフロー基盤を後付けした設計判断 」 株式会社うるるの入札情報速報サービス「NJSS」には、エリアと業務内容を自然な言葉で入力すると LLM を使ったワークフローが入札市場の分析レポートを生成する「AI リサーチ機能」が、2026 年 6 月下旬に β 版としてリリースされました。この機能を Laravel（PHP）で動く既存バックエンドに後付けするにあたっての 5 つの設計判断がテーマです。LangGraph のワークフローの実行環境に Amazon Bedrock AgentCore runtime を選んだ理由、SSE（Server-Sent Events）で配信する API を FastAPI の別サービスとして AWS Fargate 上に分けた理由、会話履歴と実行状態を Amazon DynamoDB に保存した理由が、ブラウザを閉じても処理を完走させる要件とあわせて率直に書かれています。既存プロダクトに LLM ワークフローを追加するときの判断材料になります。 builders.flash 記事「 AI にデータを渡すと何が変わる ? – Amazon Quick の構造化データ活用とセマンティックレイヤー – 」 Amazon Quick で構造化データ（データベースや CSV などの数値データ）を自然言語で分析する際、その精度を左右するのが「セマンティックレイヤー」です。データセットにビジネスコンテキストを自然言語で付与する Dataset Enrichment と、複数のデータセットをリレーション定義で論理的に統合する Multi-Dataset Topic の 2 つの仕組みが解説の中心です。金融事業会社の取引データを例に、社内用語の「対面」をデータ上の値「店頭」に対応づける定義や「売上」が指すカラムの指定で AI の回答がどう変わるか、顧客マスターとの自動 JOIN で地域別の融資延滞件数に答えられるようになる様子を画面イメージで示しています。AI の解釈や前提、計算ロジックをボタンひとつで確認できる Chat Explainability にも触れています。毎回プロンプトで背景を説明する代わりに、データとビジネスルールを事前に仕込んでおくという考え方を整理するのに役立つ内容です。 builders.flash 記事「 サーバーレス30秒クッキング 「作りたいもの」を書くと構成図とサンプルコードを作ってくれる AI エージェント 」 AWS Summit Japan の Serverless TFC ブースで展示した「サーバーレス 30 秒クッキング」は、来場者が作りたいアプリのアイデアを入力すると Strands Agents SDK で作った AI エージェントがサーバーレス構成を設計し、AWS 公式アイコンの構成図と AWS CDK のコードを生成して QR コードで持ち帰れるデモアプリです。その制作の裏話と、ブースで分かったことを紹介しています。技術的な核は、エージェントに diagram_output という自作ツールを 1 つ持たせ、サービス・接続・グループを構造化した JSON として出力させている点です。あわせて、AWS Agent Plugins として公開されている AWS Serverless プラグインの Skills でベストプラクティスを構成に反映させる工夫や、人が待つ構成図の生成には Claude Sonnet、裏側の IaC 生成には Claude Opus を使うというモデルの使い分けも紹介しています。30〜50 秒の待ち時間をリスのシェフ（シェフリス）の調理アニメーションに見立てた体験設計も読みどころです。現在はサンプルコードとして公開できるよう準備が進められています。 それでは 10 月 5日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 株式会社アテナが Claude Code on Amazon Bedrock で実現した、非エンジニア向け生成 AI 全社展開 」 BPO サービスを提供する株式会社アテナ様が、非エンジニアの社員を中心とした生成 AI の全社利用基盤を Amazon Bedrock で構築しました。Claude の Team プランを 100 名弱で契約していましたが、使わない社員の分まで固定費がかかる点や、静的な API キーを端末に長期保存させたくない点、処理を日本国内に限定したい点が課題でした。そこで Claude Desktop の接続先を Amazon Bedrock に向ける構成を 2〜3 か月で作り上げました。認証は Microsoft Entra ID との OIDC フェデレーションで行い、AWS STS から有効期限 12 時間の一時的な認証情報を取得するため、端末に静的な API キーは置きません。推論には、東京・大阪リージョンにのみルーティングされる日本国内クロスリージョン推論を使います。誰が使えるかは Entra ID、AWS 上の権限は IAM ロール、端末の接続先や機能は MDM で配布するレジストリで統制しています。有志 22 名で 9 営業日の費用を実測すると、月額換算の合計は Team プラン 22 席分の約 3.9 倍でした。一方で 1 稼働日あたりの費用には利用者間で約 51 倍の開きがあり、利用の偏りがはっきり分かりました。「どのサービスを使うか」より「既存の ID 運用と端末管理にどう載せて統制するか」が問われるという指摘は、全社展開を検討する企業の参考になります。 ブログ記事「 AI-Driven Modernization – AIエージェントに規律ある移行作業をさせる「AI Modernization Flow」を公開しました 」 AWS Japan では、従来は過大な工数やコストで断念していたアプリケーションのモダナイゼーションを AI で実現する取り組みを「AI-Driven Modernization」と呼んでいます。その中核となるツールが、AWS Samples に公開した AI Modernization Flow（AIMF）です。ビジネスロジックを変えずに技術スタックを最新化する Refactor 型の移行作業を、Kiro や Claude Code などの AI エージェントに決められた手順で進めさせるワークフローです。AI に「移行して」と頼むだけでは、ビルドもテストも通ったのに一部の機能が動かない、機能を勝手に削る、実装の理由を説明できないといった問題が繰り返し起きていました。AIMF は移行を分析から最終確認までの 6 つの Phase で進めます。インターフェースの変更や機能の除外、Phase の境界では AI が作業を止めて人の判断を求め、その理由を ADR（Architecture Decision Record）に残します。工程の完了はビルドの成功ではなく、検証スクリプトによるテストで判定します。約 15 万行の Apache Roller を Java 11 から Java 21 や Jakarta EE 10 の構成へ、人とのやり取りを含めて 4 日間で移行した実例も紹介されています。 ブログ記事「 Amazon Bedrock の自動推論ポリシーの自動改善 」 Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）は、形式検証で回答の正しさを証明する機能です。ただ、自動推論ポリシーをテストで検証しながら仕上げる反復的なチューニングが、ポリシー開発の最大のボトルネックになっていました。今回発表されたポリシーの自動改善では、改善エンジンが失敗したテストを診断して形式論理の修正案を提示します。お客様が承認した変更だけが DRAFT ポリシーに反映されます。改善モードは 2 つです。自然言語から変数への変換は正しいのに検証結果が期待と合わないルールの問題には、ソースドキュメントと任意のフィードバックを基にルールや変数の変更を提案する Iterative Refinement を使います。TRANSLATION_AMBIGUOUS が返る変換のあいまいさには Ambiguous Variable Refinement が対応し、重複する変数の統合や明確な変数の説明を提案します。コンソールでは提案された差分とテストへの影響を確認してから、承諾か破棄を選びます。記事では人事ポリシーを例にしたウォークスルーと、4 つのベストプラクティスも紹介しています。訳注のとおり、2026 年 9 月現在、自動推論チェックが対応する言語は英語です。 ブログ記事「 Amazon Bedrock の自動推論チェックが変える生成 AI のコンプライアンス 」 別の大規模言語モデルに出力を評価させる LLM-as-a-judge パターンは、確率的なシステム同士の検証にとどまります。そのため、規制業界が求める形式的で監査可能な保証は得られません。Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）は、数理論理学に基づく形式的検証で AI の出力を定義済みのルールと制約に照らして検証します。違反があれば、どのルールにどのような理由で違反しているかを特定します。記事では 6 つの業界の活用例を紹介しています。Amazon Logistics は電気自動車充電ポイントの設置提案のエンジニアリングレビューを約 8 時間から数分に、Lucid Motors は PwC および AWS と協力して予測の生成を数週間から 1 分未満に短縮しました。教育分野の First Education & Technology Group は PwC および AWS と協力し、Safer Technologies 4 Schools の原則を変換した 10 個の形式論理ルールで生徒向け生成 AI の応答を検証して、ルール設定の作業を最大 80%、継続的なコンプライアンスの運用負荷を 50% 削減しました。確率的な確信から数学的な証明へ進むための道筋を示す記事です。 ブログ記事「 Agent Skills で Amazon Bedrock の自動推論ポリシーのライフサイクルを自動化 」 Amazon Bedrock の自動推論チェック（Automated Reasoning checks）のポリシーを作るには、SMT-LIB（自動定理証明器の標準入力形式）でのルール記述や、ビルド・テスト・改善のループに慣れる必要があります。Agent Skills は、Anthropic が提供するオープンなフォーマットです。この記事では、そのスイートを使ってポリシーの構築からテスト、デプロイ、検証までをコーディングエージェントから一貫して行う方法を紹介しています。スイートは builder、reviewer、tester、debugger、deployer、validator の 6 つのスキルで構成され、ライフサイクルの各段階を 1 つずつ担当します。Kiro、Claude Code、Cursor、Codex など、このフォーマットに対応するエージェントにインストールできます。育児休暇の人事ポリシーを例にしたウォークスルーでは、3 文のソーステキストから 6 つのルール、4 つの変数、1 つのカスタム型が抽出されました。SATISFIABLE はポリシーと矛盾しないものの証明もされない回答を示す判定であり、失敗ではないという教訓も共有されています。 ブログ記事「 AWS Continuum が自律型コードセキュリティの新たな基準を確立: CyberGym-E2E で成功率 89.0% を達成 」 AWS が、自律型セキュリティの AWS Continuum for code vulnerabilities を公開ベンチマーク CyberGym-E2E で評価しました。CyberGym-E2E は、エージェントが実際のコードベースから脆弱性を見つけ、動作する概念実証で実証し、プロジェクトのテストでカバーされた動作を損なわずに修正するまでを評価するベンチマークです。139 のオープンソースプロジェクトで過去に OSS-Fuzz が検出した脆弱性に基づく 920 件のタスクで構成されます。エンドツーエンドの成功を測る主要指標 S3（パッチ適用後も機能テストにパスする）で、Continuum は 920 件中 819 件をパスし、成功率 89.0% を達成しました。従来の公開最高値 65.9% を 23.1 ポイント上回る結果です。Continuum は発見、検証、修復の各フェーズに専用のエージェントを置くマルチエージェントシステムです。記事では、CyberGym-E2E が C および C++ のメモリ安全性の脆弱性に焦点を当てており、デプロイコンテキストを踏まえた優先順位付けは評価範囲外である点も明記しています。 ブログ記事「 AI を活用した脆弱性検出ハーネス (パート 1 構築編): 3 層パイプラインによる検出結果の絞り込み 」 脆弱性スキャナーが生成する検出結果は、手動のトリアージで処理できる速度を上回っています。その多くは悪用される可能性が低いものです。記事では、未加工の検出結果を、悪用可能性の証拠が文書化された優先順位付きの少数の検出結果に絞り込む 3 層のパイプラインを紹介しています。第 1 層では複数のスキャナーを独立して実行し、2 つ以上が同じ検出結果を示すかで妥当性を確認します。第 2 層ではコードの抽象構文木（AST）を使い、スキャナーが説明した関数やファイルが実在し、データがその経路で流れ得るかを照らし合わせます。確認できない検出結果は却下します。第 3 層では CloudFormation や Terraform などの IaC テンプレートを読み込み、AWS WAF ルールやネットワーク分離、認証要件、入力検証といった既存のコントロールを攻撃者が回避できるかを段階的な尺度で評価します。AI が生成した主張は人がレビューする前に検証が必要であることや、ハーネスはコードの修正や人によるレビューの代わりにはならないことも明確に示されています。 ブログ記事「 AI を活用した脆弱性検出ハーネス (パート 2 設定編): ステアリングファイルで実現する証拠ベースの脆弱性トリアージ 」 前編で紹介した 3 層パイプラインの中で、モデルの動作を制御するステアリングファイルを解説しています。同じフロンティアモデルでも、指示次第で捏造した攻撃チェーンや過大な重大度を出力します。モデルの能力は変わりません。設定で変えられるのはモデルの判断です。ステアリングファイルは、Kiro の .kiro/steering/ 配下の Markdown や Claude Code の CLAUDE.md のように、AI コーディングアシスタントがセッション開始時に読み込む永続的な指示です。記事では 5 つの設定セクションの設計判断を解説しています。報告前にコード構造との照らし合わせを必須にする構造的検証では、ステアリングなしのモデルの検出結果の約 30% が存在しないコード構造を参照していましたが、指示を加えた後のテストではゼロになりました。信頼度は自己申告ではなく、テイント分析によるフロー確認など 5 つの二値シグナルの重み付きの式で計算します。コントロールの乗数や脅威インテリジェンスのブーストを加えたうえで、P0 から P3 の 4 階層に分類します。既知の脆弱性 10 件を含む検証用アプリケーションでは、ステアリングありのモデルが 10 件中 9 件を検出し、緩和済みの 2 件を根拠付きで P3 に引き下げました。ステアリングファイルは GitHub で公開されています。 ブログ記事「 【開催報告】AWS Cashless Frontier ― 決済業界のフロントランナーと描くAI × デジタル通貨の未来 」 2026 年 9 月 2 日に AWS 麻布台ヒルズオフィスで開催され、決済業界の IT 推進・ビジネスリーダー約 30 社 60 名が参加しました。AWS からは国内外の最新動向に加えて、USDC を利用したエージェントコマースを支える買い手側の Amazon Bedrock AgentCore Payments と、売り手側の AWS WAF の機能を紹介しました。Customer Lightning Session には 3 社が登壇しました。三菱UFJニコス株式会社様は Amazon Connect の導入経緯と、AWS Transform、Kiro、AWS Security Agent の検証を発表しました。SP.LINKS株式会社様は CCoE 主導のクラウド標準化と、AWS DevOps Agent や Kiro の活用を共有しました。株式会社ネットプロテクションズ様は「NP後払い」のコンタクトセンターに 3 段階のガードレールとヒューマン・イン・ザ・ループを組み込み、対象カテゴリーで AI 回答率 80% 以上を達成した取り組みを紹介しました。パネルディスカッションでは、株式会社インフキュリオンの丸山 弘毅 様と GMOペイメントゲートウェイ株式会社の三谷 隆 様が、エージェンティック・コマースの現在地から 2030 年のキャッシュレスビジョンまで 4 つのテーマで議論しました。 ブログ記事「 Kiro CLI V3 をデフォルトのエクスペリエンスとして順次展開します 」 Kiro CLI V3 は、Kiro IDE や Kiro Web と同じエージェントハーネスをターミナルで使えるようにするもので、6 月からオプトインで提供されてきました。10 月 12 日から、10 月末の CLI 3.0 リリースに先立って V3 への切り替えを案内する起動時のプロンプトが順次展開されます。プロンプトを待たずに kiro-cli --v3 で試すこともできます。V3 では、クラウドセッション（現時点では米国東部（バージニア北部）のみ）、チャットセッションをまたぐメモリ、spec モード、 /tangent 、バックグラウンドで計画・実装・レビューを進める workflows（オプトイン）などが使えます。プロンプトの選択肢は「Switch to V3 and upgrade my configs」「Remind me later」「Don’t ask again」の 3 つです。ただし最後を選んでも、10 月末の CLI 3.0 リリース時点で V3 にアップグレードされます。V3 には use_aws ツールがなく、AWS CLI のコマンドはシェルツール経由で実行されます。CLI 3.0 ではシェルのインライン自動補完と CLI デスクトップアプリ、Classic エクスペリエンスが廃止されます。 サービスアップデート 音声エージェント向けに推論を改善した Amazon Nova 2.5 Sonic を発表 Amazon Nova 2.5 Sonic が一般提供開始となりました。リアルタイムの音声エージェント向けの最新の speech-to-speech モデルで、推論、指示追従、ツール呼び出しの精度が改善され、レイテンシーも低くなりました。音声エージェントがコンテキストを保持し、複数ステップの指示に従い、接続したツールで顧客のタスクを完了できます。たとえばカスタマーサービスのエージェントが、1 つの会話の中で注文を検索し、返品の可否を確認し、返品手続きを開始できます。7 言語の表現力のある音声や制御可能なターンテイキング、256K のコンテキストウィンドウといった既存の機能も引き継いでいます。あわせて一般提供となった Strands Bidi Agents と組み合わせると、本番向けの音声エージェントを数行のコードで構築できます。東京リージョンを含む米国東部（バージニア北部）、米国西部（オレゴン）、欧州（ストックホルム）、アジアパシフィック（東京）の Amazon Bedrock で、Nova 2 Sonic と同じ料金で利用できます。 AWS Continuum for Penetration Testing が CI/CD パイプラインに直接統合された継続的なペネトレーションテストに対応 AWS Continuum for Penetration Testing（旧 AWS Security Agent）が、既存の CI/CD システムに直接統合した継続的なペネトレーションテストにパブリックプレビューで対応しました。これまでも第三者のベンダーと契約せずに継続的かつオンデマンドのペネトレーションテストを提供していましたが、今回の統合でペネトレーションテストがデプロイ時のイベントになります。開発者は重大度、影響を受けるエンドポイント、修復ガイダンスを含む検出結果をパイプラインの出力で直接受け取れます。セキュリティに関係しない変更は目立った遅延なく完了し、修復後はパイプラインが手動の再トリガーなしに再テストして修正を検証します。利用開始にセキュリティの専門知識は不要で、自動生成されるパイプラインスニペットを既存のパイプラインに貼り付けるだけで 5 分以内に設定できます。アプリケーションのコンテキストは初回実行時に自動で準備されるため、事前にフルのペネトレーションテストを実施しておく必要もありません。 Z.ai の GLM 5.3 が Amazon Bedrock で一般提供開始 Z.ai の GLM 5.3 が Amazon Bedrock で一般提供開始となりました。エージェンティックコーディングや長期にわたるソフトウェアエンジニアリング作業向けの新しい選択肢です。GLM 5.3 は Z.ai のフラッグシップモデルで、総パラメータ 753B、トークンあたりの活性パラメータ約 40B の Mixture-of-Experts アーキテクチャを採用しています。GLM 5.2 と同じベースモデルの上で、ポストトレーニングの規模を広げて改善しました。100 万トークンのコンテキストウィンドウと最大 128K の出力トークンを備え、推論は常に有効です。レイテンシーとトークン消費をタスク性能と引き換えにできる effort レベルも選べます。Amazon Bedrock ではシステムプロンプトとメッセージにキャッシュポイントを置く明示的なプロンプトキャッシュに対応しており、呼び出しをまたいでコンテキストを再利用する際のレイテンシーと入力コストを抑えられます。対象となるエンタープライズのお客様が、US および Global のクロスリージョン推論プロファイル経由で利用できます。 Claude Haiku 5.5 が AWS で利用可能に Anthropic の Claude Haiku 5.5 が AWS で利用可能になりました。Claude 5.5 ファミリーで最も高速かつ効率的なモデルで、サブエージェントや大量でコストに敏感な処理向けに設計されています。Anthropic によれば、ほとんどのタスクで Claude Haiku 4.5 より約 75% 低コストです。コーディング、ツール使用、コンピュータ操作、エージェントの各面で Haiku 4.5 から大きく進化し、タスクごとにコストと知能のバランスを調整できる effort 制御を備えた初の Haiku でもあります。音声エージェントのようなリアルタイムの体験や、分類や要約などの大量処理に向いています。Claude Opus 5.5 のような高性能なモデルが作業を計画し、明確に定義されたタスクを Haiku に引き渡せば、多数のエージェントを並列に動かす構成も現実的です。利用方法は Amazon Bedrock と Claude Platform on AWS の 2 つです。Amazon Bedrock ではリージョン内のデータレジデンシーを保ちながら Guardrails や Knowledge Bases と組み合わせて使えます。Claude Platform on AWS では、Anthropic と直接取引する場合と同じ API や機能、コンソール体験を AWS の請求と認証に統合した形で利用できます。 Claude Haiku 5.5 が AWS GovCloud (US) で利用可能に Claude Haiku 5.5 が AWS GovCloud (US) でも利用可能になりました。Claude 5.5 ファミリーで最も高速かつ効率的なモデルで、Anthropic によればほとんどのタスクで Claude Haiku 4.5 より約 75% 低コストです。effort 制御を備えた初の Haiku として、音声エージェントなどのリアルタイムの体験や、分類・要約といった大量処理、サブエージェントとしての利用に向いています。AWS GovCloud (US) では Amazon Bedrock を通じて、リージョン内のデータレジデンシーを保ちながら Guardrails や Knowledge Bases と組み合わせて利用できます。 TwelveLabs Pegasus 1.5 モデルが Amazon Bedrock で利用可能に TwelveLabs の Pegasus 1.5 が Amazon Bedrock で利用可能になりました。動画から構造化されたタイムコード付きのメタデータを生成する video-to-text モデルです。これまで大規模な動画ライブラリから特定の瞬間を見つけるには、質問する前にどこを探すべきかを知っている必要がありました。Pegasus 1.5 は動画全体を読み取り、何がいつ起きたかにラベルを付けて、映像をアプリケーションから問い合わせできるデータに変えます。編集上のセグメントや話者の切り替わり、スポーツのプレー、ブランドの登場など、ビジネスにとって重要な事柄を定義しておくと、該当する瞬間をタイムスタンプ付きで返します。画面に映るもの、音声、画面上の文字を 1 回のパスで分析するため、事前のインデックス作成や取り込みパイプラインの構築は不要です。US および Global のクロスリージョン推論プロファイル経由で利用できます。 OpenAI GPT-6.1 Sol が Amazon Bedrock で Ultrafast モードに対応 OpenAI の GPT-6.1 Sol が Amazon Bedrock で Ultrafast モードに対応しました。Ultrafast モードは、速度を最も重視するワークロード向けにより高速な推論を提供します。リアルタイムのコーディングアシスタントやインタラクティブなエージェント、素早く質の高い応答が求められる顧客向けの体験など、レイテンシーに敏感なアプリケーションに向いています。GPT-6.1 Sol は機能の構築、問題のデバッグ、複雑なコードベースの調査、複数ステップのワークフローの完了を支援します。既存の AWS のコントロールでワークロードの保護、アクセスの統制、モデル呼び出しの監査ができ、Amazon Bedrock コンソールまたは対応する Amazon Bedrock API から利用を開始できます。 Amazon Quick がブランドに沿ったプレゼンテーションとドキュメントのためのブランドテンプレートに対応 Amazon Quick にブランドテンプレートをアップロードし、承認済みのビジュアルアイデンティティに沿ったプレゼンテーションやドキュメントを作成できるようになりました。ブランドマネージャーが PowerPoint や Word のテンプレートをアップロードするか、SharePoint のような接続済みのファイルストアから取り込むと、Quick が色、フォント、ロゴ、レイアウト、ブランドルールを抽出します。ブランドマネージャーはその内容を確認・編集したうえで組織全体に公開します。利用者はチャットごとに正しいファイルを探さなくても、ブランドに沿った成果物を得られます。Quick はテンプレートのルールに従ってアセットを作成し、リクエストがルールに反する場合はその理由を説明してブランドに沿った代替案を提案します。テンプレートはブランドマネージャーが書いたガイダンスに基づいてタスクごとに選ばれますが、利用者が別のテンプレートを選ぶこともできます。作成・公開できる人はカスタム権限で管理者が決められます。ブランドアセットは Amazon Quick デスクトップアプリで一般提供されています。 Amazon Bedrock が OpenAI モデルの reasoning summary に対応 Amazon Bedrock が、Responses API を通じて OpenAI モデルの reasoning.summary パラメータに対応しました。モデルの応答とあわせて、推論内容の人が読める要約をリクエストできます。コーディングや分析、複数ステップの問題解決といった複雑なタスクにモデルがどう取り組んだかが分かり、応答の評価やアプリケーションのデバッグに役立ちます。モデルの考え方をユーザーに示す用途にも使えます。要約は、reasoning 出力アイテムの summary 配列で回答と並んで返されます。リージョン内推論、地理的（GEO）クロスリージョン推論、グローバルクロスリージョン推論を含め、OpenAI の GPT モデルが利用できるすべての AWS リージョンで、Amazon Bedrock 上のすべての OpenAI モデルに対して利用できます。 Anthropic Claude Sonnet 5.5 と Claude Opus 5.5 が AWS GovCloud (US) の Kiro で利用可能に AWS GovCloud (US) リージョンの Kiro IDE と Kiro CLI で、Anthropic の Claude Opus 5.5 と Claude Sonnet 5.5 が利用可能になりました。Claude Opus 5.5 は Anthropic の Opus モデルとして最も高性能で、長時間のエージェンティックなコーディング作業で Opus 5 から進化しています。リクエストごとにタスクに必要な労力を判断して思考し、Kiro の内部ベンチマークでは Opus 5 と比べて約 40% 少ないツール呼び出しと約半分のトークンでタスクを完了します。1M のコンテキストウィンドウと 2.0x のクレジット倍率で提供され、倍率は Opus 5 の 2.2x から下がりました。Claude Sonnet 5.5 はこれまでで最も高速な Sonnet で、出力は 30% 以上速くなり、実際のコーディングやナレッジワークの性能は Opus 5.5 に近づいています。1M のコンテキストウィンドウと 1.3x のクレジット倍率で提供されます。IDE または CLI を最新バージョンに更新して再起動すると、モデルセレクターから選べます。 Kiro CLI 2.29 : チャットセッションをまたぐ Memory Kiro CLI 2.29 では、ローカルの V3 セッションで Memory が使えるようになりました。リポジトリのコマンドや規約といった作業中に得たコンテキストを Kiro が学習し、後のチャットセッションで呼び出すため、同じ説明を繰り返さずに済みます。たとえばローカルデータベースをシードしないと統合テストが失敗すると学習していれば、次のセッションでは先にシードできます。管理はローカルの V3 セッションで /memories と入力し、 config から read & write 、 read only 、 off を選びます。アクセス設定の変更は次のセッションから反映されます。 read & write のときは Automatic memory updates を有効にでき、セッション終了後も含めてメモリの作成と改良を Kiro に許可できます。信頼していないワークスペースでは読み取りのみで、追加・変更・削除はできません。 list では保存済みメモリの検索やプレビューができ、修正や削除はチャットで Kiro に依頼します。あわせて、エージェント JSON ファイルを V2 と V3 の両方が読める形式にする kiro-cli agent upgrade の追加など、改善と修正も含まれています。 Kiro IDE 1.2.56 : Workflows のフィードバック、Powers の検索、柔軟な Hook マッチング Kiro IDE 1.2.56 では、Workflows のフィードバックリンクが追加され、ワークフローの信頼性や spec 専用コマンド、Hook のマッチングが改善されました。チャット、ターミナル、ソースコントロールの多くの問題も修正されています。デスクトップアプリでは、チャットの Workflows ドロワーから短いフィードバック調査を開けます。この調査は GovCloud、AWS isolated Regions、China Regions では利用できません。Available Powers ビューでは名前でカードを絞り込めるようになり、 /quick-spec 、 /architecture-selection 、 /bug-fix は spec セッションでのみ表示されます。PreToolUse と PostToolUse の Hook では、ツール ID を個別に列挙する代わりに shell 、 read 、 write 、 @builtin 、 @mcp 、 @server 、 @server/tool というカテゴリとセレクタでツールのグループをマッチできます。修正では、複数リポジトリのワークスペースで Generate Commit Message が誤ったリポジトリを使う問題や、長いチャットでメモリ使用量が増え続ける問題などが解消されました。 Kiro CLI 2.28 : Classic から 3.0 への切り替え、カテゴリベースの Hook マッチング、より安定した V3 セッション Kiro CLI 2.28 では、Classic ユーザーがターミナルを離れずに 3.0 へ切り替えられるようになりました。3.0 を実行できるホストでインタラクティブな Classic セッションを開始すると、Kiro が切り替えを提案します。「Switch to 3.0 and upgrade my agent configs」を選ぶと、3.0 がデフォルトとして保存され、エージェント設定がアップグレードされ、コマンドが 3.0 で再実行されます。断った場合はおよそ週に一度、再度案内されます。V3 セッションでは、ツールの前後に実行する Hook を内部のツール ID だけでなく、shell、read、write や特定の MCP サーバー・ツールといったカテゴリでマッチできます。 /model と /effort は Kiro の作業中でもピッカーを開けるようになり、選択は現在のターンの終了後に適用されます。V3 は終了したターンをメモリに保持せず解放するため、長いチャットでの蓄積が抑えられます。このほか、 /settings > Display > Full Screen への Copy on select の追加など、改善と修正も含まれています。 生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。

はじめに LaravelでAIに開発を任せる際は、プロジェクトのルールをコンテキストで伝えるだけでなく、生成コードを機械的に検査する品質ハーネスも設けています。AIの出力は確率的で、指示だけでは規則を毎回守るとは限らないためです。 静的解析やテストの結果をAIに返し、修正と再検査までを完了条件にします。これにより、コードの書き方や型、プロジェクト固有の規約について、同じ指摘を繰り返す手間を減らせます。 この記事では、新規のLaravelプロジェクトを例に、何を検査し、開発中にどう回すかを紹介します。 何を確認するかで検査を分ける 分類 確認すること 使用するツール

はじめに 自己紹介 2023年にアジアクエストへ新卒未経験で入社した、文系学部出身のエンジニアです。 普段の業務では主に設計と開発を担当しており、得意言語は React や PHP/Laravel です。