Amazon Web Services ブログ

Kiro の Auto がモデルカスケードで作業に合ったモデルを使い分ける仕組み

稲田大陸 — Sat, 07 Nov 2026 01:51:29 +0000

本記事は 2026 年 11 月 6 日に Kiro ブログで公開された「How Kiro Auto uses model cascading to match the model to the work」を翻訳したものです。

TL;DR：Auto は裏側でモデルカスケードを使っています。どのセッションも効率のよい最初のモデルで始まり、独立したチェックがバックグラウンドで作業を確かめ、必要になったときに Auto はセッションをより高性能なモデルに引き継ぎます。DeepSWE v1.1 を使った社内の評価では、カスケードは高性能なモデル単独とほぼ同じ成績を出し、タスクの約 5 件に 4 件は引き継ぎなしで完了しました。

Kiro では、ほとんどの方に Auto での作業をおすすめしています。モデルのドキュメントにあるとおり、Auto がユーザーに代わってモデルを選び、高い品質の基準を保ちます。有料プランでは、その基準は Claude Opus クラスの品質です。この記事では、Auto がその基準を満たすための方法の 1 つである、モデルカスケードという手法を紹介します。

難しさはセッションが進むにつれて見えてくる

Kiro に、不安定な日付パーサーの修正を頼んだとします。最初の手順は決まりきった作業です。ファイルを読み、関数を見つけ、不具合を再現する、失敗するテストを書きます。ところがそのテストで、ほかの 3 つのモジュールにまたがるタイムゾーンの前提が見つかり、小さな修正がリファクタリングに変わります。逆のことも起きます。大きく見えたタスクが、2 行の変更で済むこともあります。

モデルの性能が上がるにつれて、より大きな仕事を任せるようになり、Kiro のセッションは長くなっています。手順の多い長いセッションは、ファイルを読み、コードを編集し、テストを実行し、やり直すといった多くの手順を踏みます。その難しさは、始まった時点では決まっていません。セッションの難しさには形があり、その形は進めてみて初めて見えてきます。図 1 では、同じセッションを 3 通りのやり方で進めています。

図 1: 難しさはセッションが進むにつれて現れるため、最初に 1 回だけ選んだモデルでは、簡単な区間で性能が余るか、難しい区間で力が足りなくなります。カスケードは進めながら調整します（イメージ図）。1 枚目は途中で難しくなるセッション、2 枚目は簡単なままのセッションです。画像の右上のボタンは原文のインタラクティブな図のもので、この記事では 2 つの状態を 2 枚の画像に分けて載せています。

作業を始める前にモデルを選ぶとき、判断の手がかりは依頼の内容しかありません。高性能なモデルを選べば、効率のよいモデルでも同じようにこなせた決まりきった手順も含めて、すべての手順をそのモデルが担います。効率のよいモデルを選べば、決まりきった手順はうまくこなせますが、作業が難しくなると、行ったり来たりを始めたり、すでに終えた作業をやり直したりすることがあります。次に、図 1 の 2 枚目の、簡単なままのセッションを見てください。依頼が同じなので、最初に選ぶモデルは変わりません。カスケードは最後まで最初のモデルのままです。セッションが、そのモデルで扱える以上に難しくならないからです。

Auto のモデルカスケードのしくみ

モデルカスケードは、1 回のモデルの選択を、エージェントのセッション全体を通して行う一連の判断に変えます。

効率のよいモデルで始める。どのセッションも最初のモデルで始まります。最初のモデルは、日常的な幅広い作業をうまくこなす効率のよいモデルです。多くのセッションでは、このモデルが適切な選択で、作業のすべてをこなします。
バックグラウンドで作業を確かめる。独立したモデルが、セッションの軌跡、つまりここまでに行われた作業を確かめます。チェックは非同期に動くので、セッションがチェックを待つことはありません。また、作業しているモデルが自分の進み具合を採点することもありません。
そのまま続けるか、引き継ぐ。セッションが着実に進んでいるあいだは、何も変わりません。セッションが効率よく進まなくなった兆し（同じコードを繰り返し調べる、すでに終えた作業をやり直す、など）をチェックが見つけると、Auto はセッションをより高性能なモデルに引き継ぎます。引き継ぎではここまでの作業の要点が受け渡されるので、より高性能なモデルは最初からやり直すのではなく、今の状態のセッションをそのまま引き継ぎます。
必要に応じて繰り返す。引き継ぎは、セッションが最も高性能なモデルで動くようになるまで繰り返し起こりえます。現時点では、引き継ぎは上の方向にだけ行われます。セッションを効率のよいモデルへ戻すことは、今後のアップデートで検討します。

モデルへのアクセスを管理しているチームでは、引き継ぎ先も Auto が使えるモデルの中から選ばれるので、引き継ぎにも Auto と同じガバナンスの設定が適用されます。管理者がモデルへのアクセスをどう制御するかは、モデルのガバナンスをご覧ください。

図 2: Auto のモデルカスケードでは、最初のモデルがセッションを始め、独立したチェックがバックグラウンドで作業を確かめます。より高性能なモデルがセッションを引き継ぐのは、その必要がある兆しをチェックが見つけたときだけです。これは考え方を示したイラストで、実際のチェックの動き方を表したものではありません。

担当のエンジニアがチケットに取り組み、その肩越しにレビュアーが作業を見ている場面を考えてみてください。エンジニアは作業を続け、手を止めて自分の進み具合を採点することはありません。それはレビュアーの仕事です。作業が前に進んでいるあいだ、レビュアーは何も言いません。作業が同じところを回り始めたとレビュアーが気づいた時点で、チケットはより腕の立つエンジニアに渡り、そのエンジニアが今の状態から引き継ぎます。

カスケードを既定で動かしても安全なのは、このしくみがあるからです。作業しているモデルは自分の進み具合を採点せず、引き継ぎは最初からやり直すのではなく、すでに終えた作業の上に積み上げます。より高い性能が必要なセッションは途中でその性能を得られ、必要のないセッションは最初のモデルのまま進みます。

測定したこと

カスケードを、Datacurve による、手順の多い長いタスクを扱うソフトウェアエンジニアリングのベンチマークである DeepSWE v1.1 で評価しました。タスクはこのベンチマークのために新しく作られたもので、オープンソースのリポジトリを題材にし、人が書いた、動作を確かめるテストで採点されます。そのため、難しさが途中で変わりうる、何段階にもわたるセッションが必要になります。Kiro のエージェントエンジンで 3 つの構成を動かし、それぞれの構成でベンチマーク全体を 3 回ずつ、独立に実行しました。

最初のモデルのみ。すべてのタスクを、効率のよい最初のモデルで最初から最後まで実行します。
高性能なモデルのみ。すべてのタスクを、より高性能なモデルで最初から最後まで実行します。
カスケード。すべてのタスクを最初のモデルで始め、より高性能なモデルへ引き継げる状態にしておきます。

3 つの構成とも、推論（reasoning）の設定は同じです。違いは、どのモデルが作業を担うかだけです。結果は pass@1（1 回の試行で解けたタスクの割合）を、3 回の実行の平均 ± 1 標準偏差で示します。

高性能なモデル単独とほぼ同じ品質

図 3 は 3 つの構成の pass@1 を比べたもので、その下の表に同じ値を載せています。

図 3: DeepSWE v1.1 で、カスケードの pass@1 は 69.37% でした。高性能なモデル単独（70.57%）とほぼ同じで、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。エラーバーは 3 回の実行の ± 1 標準偏差を示します。

構成	pass@1（3 回の実行の平均 ± 1 標準偏差）
最初のモデルのみ	63.96% ± 2.70
高性能なモデルのみ	70.57% ± 2.08
カスケード（最初のモデルで始め、より高性能なモデルを使える）	69.37% ± 1.56

カスケードはタスクの 69.37% を解きました。高性能なモデル単独（70.57%）とほぼ同じで、その差は実行ごとのばらつきの範囲内です。また、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。3 つの構成のうち、実行ごとのばらつきが最も小さかったのもカスケードでした。つまり、すべてのタスクを最初のモデルで始めても、それが品質の足かせにはなりませんでした。

約 5 件に 4 件は引き継ぎなしで完了

図 4 は、カスケードのタスクがどのモデルで終わったかを示しています。

図 4: DeepSWE v1.1 の 3 回の実行を通して、タスクの 80.48% は最初のモデルだけで完了し、19.52%（約 5 件に 1 件）はより高性能なモデルに引き継がれました。

すべての実行を通して、タスクの 80.48% は最初のモデルで完了しました。残りの 19.52%、約 5 件に 1 件は、途中でより高性能なモデルに引き継がれました。

今回の DeepSWE の実行では、引き継がれたタスクには共通点がありました。最初から最後まで正しく仕上げるのが難しい変更だったことです。たとえば、型や API から CLI や設定まで、多くの層に同時に触れる機能や、保存された状態やキャッシュ、処理の順序に左右される振る舞いです。小さく局所的な変更で引き継ぎが必要になることはまれでしたが、大きな変更が必ず引き継ぎを必要としたわけでもありません。分かれ目になったのは、注意深い設計や、コードの複数の部分のあいだで整合性を保つことが、作業のどれだけを占めていたかでした。

引き継ぎが起きたタイミングにも、同じくらいはっきりした傾向がありました。これらのタスクでは、最初のモデルはほぼ必ず、序盤の手順を自力でこなしていました。コードを書き、多くの場合はビルドとテストを通すところまで進めています。引き継ぎは、そのあとの検証と統合の段階で起きる傾向がありました。最初のモデルが、変更したコード全体ですべての要件が満たされていることを示そうとしている段階で、セッションが効率よく進まなくなった兆しをチェックが見つけたのです。こうしたことは、どれも依頼の内容からは分かりませんでした。チェックが見守り続け、セッションが必要とするどの時点でも引き継ぎが起こりうるので、カスケードは作業がいつ難しくなるかを前もって知る必要がありません。

Auto がクレジット倍率 1x のまま複雑な作業を高い品質でこなせるのは、これが理由の 1 つです。ほとんどのセッションは最初のモデルで完了し、より高性能なモデルが引き継ぐのは作業上必要なときだけです。

ベンチマークの数値についての注意

これらの数値は、社内の評価用ベンチマークの、ある特定の実行で得られたものです。本番環境での見込みではなく、お客様ごとの実際のワークロードでの結果は異なります。

引き継ぎの割合はタスク全体の平均です。セッションがどれくらいの頻度で引き継がれるかは作業によるので、個々のセッションでは異なります。引き継ぎはユーザーには見えません。引き継ぎが起きていることを意識しなくても、品質の面での効果を得られます。

DeepSWE の数値は社内のベンチマーク用の実行環境（ハーネス）で測ったもので、公開されている DeepSWE のリーダーボードの公式の設定と同じではありません。そのため、割合を公開のリーダーボードの数値と比べることはできません。

試してみる

モデルカスケードは Auto のしくみの一部で、効率の面での利点はすべての Kiro のお客様が利用できます。次にセッションを始めるときは、Kiro で Auto を選んでください。Auto とモデルの選択のしくみについては、ドキュメントのモデルの概要をご覧ください。

原文の著者

Vijay Lingam（Applied Science）、Mayank Gupta（Applied Science）、Sudipto Nandi（Engineering）、Neil Kulkarni（Engineering）、Jack Wang（Engineering）、Sai Srinivas Somarouthu（Engineering）

翻訳者について

AWS Managed Services（AMS）で AWS クラウドインフラのセキュリティを強化する

Yosuke Kimura — Fri, 06 Nov 2026 13:06:43 +0000

本記事は 2024 年 2 月 16 日に公開された”Enhance your AWS cloud infrastructure security with AWS Managed Services (AMS)“を翻訳したものです。

はじめに

セキュリティやデータ損失インシデントは、金銭的損失と社会的信用の失墜につながる可能性があります。セキュリティとコンプライアンスは、AWS とお客様の間における責任共有により維持されます。この責任共有では、AWS は「クラウドのセキュリティ」に責任を持ち、お客様は「クラウドにおけるセキュリティ」に責任を持ちます。しかし、クラウドにおけるセキュリティは、特にクラウドインフラおよびオペレーティングシステム(OS)レベルにおいて、より広い範囲に及びます。クラウドにおいて、セキュアでコンプライアンスに準拠した監視環境を大規模に構築するには、高度な自動化、人的リソース、およびスキルが必要です。

このブログでは、「クラウドにおけるセキュリティ」を向上させるために AWS サービスを組み合わせて活用する方法を紹介します。多くの組織にとって、スキル不足やビジネスにおける優先順位により、セキュリティのベストプラクティスを大規模に順守し、導入することは容易ではありません。AWS Managed Services （AMS）が大規模にお客様の AWS インフラのセキュリティおよびコンプライアンス体制を強化してきたベストプラクティスをご紹介します。AMS は、モニタリング、インシデント管理、セキュリティ、パッチ適用、バックアップ、コスト最適化にわたって AWS クラウドでの運用上の優秀性を達成するための能動的・予防的・検出的な機能を提供します。これにより、お客様はイノベーションに集中できます。

例えば、Coinhako が AMS を運用パートナーとして AWS に移行した際、CTO の Gerry Eng 氏は次のように述べています。「AMS に標準搭載されている数多くのセキュリティ機能は、我々が独自に適切に展開するには数ヶ月、場合によっては数年かかっていたでしょう。」詳細はケーススタディをご覧ください。

AWS におけるクラウドセキュリティ管理

予防（Prevention）

「予防は治療に勝る」と言われています。セキュリティ体制を改善し、問題を予防するための領域には、アイデンティティとアクセス管理（IAM）、受信（Ingress）と送信（Egress）トラフィックの保護、バックアップおよび災害復旧、そして脆弱性への対処があります。

AWS は AWS IAM とサービスコントロールポリシー（SCPs）を組み合わせてクラウドリソースへのきめ細かいアクセス制御を提供しています。AWS は IAM サービスのセキュリティベストプラクティスを公開しています。しかし、お客様がその最適な利用状況を長期にわたって監視・統制することは容易ではなく、結果として不正なアクセスや不要なアクセスを招いてしまうことが少なくありません。AMS を活用することで、IAM の変更が AWS のベストプラクティスや AMS の技術基準に適合しているかを継続的に検証することが可能です。また、AMS はカスタム AWS Config ルールを使用して IAM のガバナンスコントロールのベストプラクティスを実装し、異常または逸脱を積極的に検出・修正します。

受信（Ingress）と送信（Egress）トラフィックの観点から、エッジネットワークで AWS WAF（Web アプリケーションファイアウォールサービス）を使用して、Web アプリケーションリソースへ届く HTTP/HTTPS リクエストを検査することができます。AWS WAF は Amazon CloudFront、Application Load Balancer（ALB）、Amazon API Gateway などほとんどの AWS 外部向けサービスとネイティブに統合されています。ネットワーク層では、AWS Network Firewall を使用してファイアウォールルールを定義し、すべての受信（Ingress）と送信（Egress）ネットワークトラフィックをきめ細かく制御できます。Network Firewall は AWS Firewall Manager と連携して、複数の VPC およびアカウントにわたってポリシーを一元的に適用します。AMS は AWS ベストプラクティスを使用して、これらのサービスを継続的にセットアップおよび運用するサポートを提供します。

さらに、定期的なパッチ適用は脆弱性に対する最も効果的な予防策の一つです。Ponemon Institute の調査によると、「侵害被害者の 60% は、パッチが未適用の既知の脆弱性を悪用されて侵害された」と述べています。OS レベルでは、最新の脆弱性から保護するための完全なパッチ管理のために AWS Systems Manager の Patch Manager サービスを活用できます。継続的な脆弱性管理には、Amazon Inspector サービスで、OS の脆弱性のスキャン・特定ができます。しかし、パッチスケジュールの設定、パッチコンプライアンスのレポート、および大規模なパッチ失敗への対応は、困難ではあるもののビジネス上の差別化に繋がらないタスクとみなされることがあります。AMS は自動化とベストプラクティスを駆使し、大規模環境においても、これら一連の作業をお客様に代わって実行します。AMS は Inspector またはお客様のツールによって報告された高リスクまたはゼロデイ脆弱性に対処するための臨時パッチ適用も実行できます。また、AMS を活用して Security Technical Implementation Guide （STIG）ベンチマークに準拠したセキュリティが強化された OS の Amazon Machine Images（AMI）を構築し、安全な EC2 インスタンスをデフォルトで保護することもできます。

最後に、インシデント時のデータ損失に対して、堅牢なバックアップおよび災害復旧戦略が不可欠です。AWS Backup と AWS Elastic Disaster Recovery を組み合わせて AWS クラウドのデータを保護できます。大規模な環境において、バックアップ計画の設定とバックアップコンプライアンスの継続的な監視は複雑になることがあります。AMS は継続的なバックアップの監視・管理を支援するだけでなく、ランサムウェア保護プランを含むデータ復旧のビジネスユースケースに対応した複数のバックアップ計画を提供します。定期的なバックアップのテスト・復元は、予期せぬ問題発生時のビジネスサービスのダウンタイムを最小化するための重要な実践です。AMS はインシデント時の平均復旧時間（MTTR）を短縮するためのサービス復旧に関する SLA を提供します。AMS はお客様のチームとともに、侵害インスタンスやランサムウェアイベントなどのシナリオをシミュレートするセキュリティおよび運用重視のゲームデー（模擬訓練）を実施します。

検出（Detection）

クラウド環境を継続的に監視して異常や潜在的な悪意ある活動を積極的に検出・封じ込め・修正することは非常に重要です。AWS は、ログやイベントの処理、およびモニタリングを通じて、監査、自動分析、アラーム通知を可能にするさまざまな検知統制を実装するためのサービスを提供しています。例えば、Amazon GuardDuty は機械学習（ML）ベースの脅威検出サービスで、アクセス関連アクティビティと不正な動作を継続的に監視して AWS アカウントのワークロードを保護します。GuardDuty は Amazon Macie と組み合わせることができます。Macie はデータセキュリティサービスで、ML とパターンマッチングを使用して AWS アカウント内の機密データの検出・保護を行います。

AWS Security Hub CSPM はクラウドセキュリティ体制管理（CSPM）サービスで、セキュリティのベストプラクティスチェックを実行し、AWS およびサードパーティサービスからのアラートを集約し、修復手順を提案します。しかし、多数の AWS アカウントにわたってこれらのアラートを処理し、修復を実施することは、運用上すぐに困難な状況になることがあります。

AMS は Amazon GuardDuty を活用して、お客様が契約しているすべての AWS アカウントの脅威を監視し、そこから生成されるすべてのアラートを 24 時間 365 日体制でレビューします。AMS は GuardDuty アラートを分析する自動化技術を駆使し、誤検知を減らして、初期トリアージ（優先度判定）を行い、インシデント通知の一環として実用的な対応策を提供します。重大な問題については、AMS は積極的にお客様と連携して共同セキュリティ調査を実施し、修復に必要な承認を取得します。AMS は Amazon Macie の検出結果を監視し、お客様に代わって必要な修復を実施することもできます。

モニタリングとインシデント対応（Monitoring and Incident Response）

Amazon CloudWatch はオブザーバビリティのための AWS ネイティブの基盤サービスで、インフラ、アプリケーション、およびエンドユーザーモニタリングにわたる機能を提供します。Systems Manager の OpsCenter により、オペレーションスタッフは CloudWatch や AWS Config などのサービスによって特定された運用上の問題を表示・調査・修復できます。Systems Manager の Incident Manager 機能は、自動化された対応計画を使用して重要なアプリケーション問題をより迅速に解決するのに役立ちます。OpsCenter と Incident Manager は、Atlassian Jira や ServiceNow などの ITSM およびチケットシステムと統合して、お好みのツールでインシデントの包括的なビューを提供します。Incident Manager は Amazon Q Developer in chat applications とも連携しており、Slack、Microsoft Teams のようなコラボレーションツールを使用して、インシデントの調査や修復対応を行うことができます。(※1)

AMS は、世界各地の複数のサイトに配置されたエンジニアによる 24 時間 365 日のセキュリティ監視とインシデント対応を通じて、クラウドでの運用上の優秀性の達成を支援します。アラートとイベントは AWS Config、Amazon GuardDuty、Amazon Macie、Amazon CloudWatch、AWS CloudTrail などのネイティブサービスから監視されます。セキュリティインシデント対応（SIR）については、AMS は事前定義された National Institute of Standards and Technology （NIST）準拠のランブック（対応手順書）に従い、セキュリティアラートに対して、特定・分析・封じ込め・根絶・復旧の対応を行います。AMS は Systems Manager の OpsCenter を使用してすべての運用項目をログに記録し、AWS サポートケースを通じて通知し、お客様のチームと連携して解決します。Security Incident and Event Management （SIEM）や Endpoint Detection and Response （EDR）などサードパーティまたは自社開発のセキュリティツールを使用している場合、AMS はそれらによって報告された OS および AWS インフラ関連の検出結果を修復する支援も行うことができます。また、AWS Service Management Connector を ServiceNow や Atlassian Jira などの ITSM ツールと統合して、AMS とのシームレスなインシデント・チケット対応を実現することもできます。(※2)

コンプライアンス（Compliance）

AWS の責任共有モデルの下、お客様はゲスト OS、アプリケーションソフトウェア、および AWS アカウント内の AWS サービスの設定と選択に関して、セキュリティとコンプライアンスの責任を負います。さらに、ビジネスニーズに応じて幅広いローカル・グローバルのコンプライアンスフレームワークに準拠する必要があり、それらのフレームワークを AWS セキュリティコントロールにマッピングすることは困難な場合があります。

AMS を使用することで、AWS における全体的なセキュリティ体制を強化するだけでなく、必要なコンプライアンスレベルへの到達を加速できます。まず、AMS というサービス自体が、HIPAA、SOC、ISO27001、FedRAMP、IRAP、NIST、PCI-DSS、GDPR など、多くのグローバルなコンプライアンスフレームワーク、規制、セキュリティ基準に適合し、準拠しています（詳細は AWS コンプライアンスセンターを参照）。そのため、AMS によって管理されるクラウド環境は、特定のコンプライアンス要件や規制要件が求められるアプリケーションをホストするのに適しています。

次に、AMS では利用開始初日から、AWS Config を活用することで、CIS、NIST、PCI、HIPAA という、極めて厳格かつ多岐にわたる 4 つのグローバル・セキュリティ・フレームワークに対するお客様のセキュリティ体制を完全に可視化できます。AMS は、厳選された AWS Config Rules をデプロイし、お客様のアカウント内のリソース状態を継続的に監視することで、これらのコンプライアンス基準やフレームワークの要件への準拠を維持します。これらのルールは、ビジネスのニーズに応じて、自動修復を行うか、インシデントやレポートとして通知を行うかのいずれかに設定することが可能です。例えば、AMS では、AMS アカウント内で AWS CloudTrail によるログ記録がデフォルトで有効化されており、これが必要なときにいつでも行えるレポート作成、アラート通知、および監査に利用されます。この設定だけでも、セキュリティ基準である NIST SP 800-53 の監査と責任（AU）コントロールファミリーにおける AU-06/07（a-c, 1-4）や、ISO 27001 のコントロール A.12.4.1-3 といった複数の管理策を満たす上で有効です。

さらに、AMS はコンプライアンス要件を強化するために、OS レベルと AWS アカウントレベルの両方において、中央集権型のログ記録および監査コントロールを実装しています。AWS アカウント内で行われたユーザーアクセスや変更に関する監査レポートは、Amazon Athena コンソール経由で、AMS が事前構築した厳選されたクエリを使用して簡単に抽出することができます。

レポートとガバナンス（Reporting & Governance）

AWS クラウド環境全体におけるセキュリティ体制や潜在的なリスクを測定・追跡するためには、強固なレポート機能とガバナンスの実践が不可欠です。Key-Value のペアを使ってメタデータを作成する AWS Resource Tagging は、監査、自動化、およびコスト配分を通じて、運用上の優秀性を達成するために極めて重要な役割を果たします。例えば、AWS のメタデータやタグの値は任意の AWS ストレージサービスにエクスポートすることができます。これにより、AWS Glue、Amazon Athena、Amazon Quick Sight といったサービスを活用して、パッチ適用状況やセキュリティコンプライアンスのカバー率に関するレポート、あるいはその他のダッシュボードを構築できます。

AMS は、OS のパッチ適用レベル、バックアップのカバー率、および高緊急度のインシデントに関するレポートを、毎週・毎月セルフサービスで提供します。また、お客様専任の AMS Cloud Service Delivery Manager（CSDM）と Cloud Architect（CA）が信頼できるアドバイザーとして、月次ビジネスレビューを主導します。このレビューでは、管理されているすべての AWS アカウントを横断した中央集中型の追加レポートが提供されます。月次ビジネスレビューには、AWS Well Architected Framework の各柱にわたる主要なクラウド運用リスクへの洞察と高緊急度のアラートに対処するための将来的な計画が含まれています。

AMS のタグまたはお客様独自のカスタムタグを強制適用するために、AMS 管理下にある AWS リソースでは、AMS が提供する Resource Tagger ツールを活用できます。監査やレポート作成に加えて、AMS 固有のタグを使用することで、アクセス制御、監視、パッチ適用、バックアップ、および自動修復にわたる自動化アクションが可能になります。この AMS Resource Tagger とお客様のカスタムタグを組み合わせることで、クラウドガバナンスのための強固なタグ付け戦略を構築できます。

セキュリティオンデマンド（Security On-Demand）

AMS は、Operations on Demand（OOD）サービスを通じて、必要なときに拡張セキュリティサポートを提供しています。AMS OOD を活用することで、AWS サービスに関する変更を行い、AWS クラウドにおけるセキュリティ体制をさらに向上させることができます。このサービスには、既知の、あるいは未対策のセキュリティ脅威から保護するためのセキュリティ関連サービスカタログが含まれており、AWS Network Firewall の運用や、サポート終了が迫っているレガシー OS のアップグレードなどに対応しています。

おわりに

本記事では、AWS クラウドにおけるセキュリティ体制を強化するために実装できる、予防・検出・対応の管理を含む、多くの不可欠なセキュリティベストプラクティスを検討しました。また、お客様の AWS クラウド環境を管理することで、求められる「クラウドにおけるセキュリティ」を実装する信頼できるパートナーとして、どのように AMS を活用できるかを説明しました。AMS は、AWS のベストプラクティスを用いた複数のガードレールの実装に加え、24 時間 365 日のセキュリティインシデント対応および復旧を行うことで、クラウドのセキュリティ体制を強化します。さらに、AMS は初日からお客様の AWS アカウントにログ記録、監査、監視に関する多くの必要なセキュリティ統制とベストプラクティスの導入を支援し、コンプライアンスへの取り組みを加速させます。

セキュリティ特有の機能にとどまらず、AMS はインフラや OS の能動的な監視、アラートの自動復旧、コスト最適化、そして継続的なガバナンスの組み合わせにより、大規模なお客様の AWS クラウド環境における運用上の優秀性の達成を支援します。詳細については、AWS Managed Services の製品ページをご覧ください。

※1 2025 年 11 月 7 日に AWS Systems Manager Incident Manager は新規のお客様への提供を終了しました。AWS は引き続き Incident Manager のセキュリティと可用性への投資を継続し、既存の Incident Manager のお客様は、すでに Incident Manager が有効化されているアカウントにおいて、これまで通りサービスを引き続きご利用いただけます。

※2 2026 年 3 月 31 日に AWS Service Management Connector は新規のお客様への提供を終了しました。既存のお客様は、2027 年 3 月 31 日までサービスを引き続きご利用いただけます。2027 年 3 月 31 日以降、AWS Service Management Connector の機能にアクセスすることはできなくなります。AWS パートナーソリューションへの移行、または直接的な SDK 統合の構築をお勧めいたします。

翻訳はシニアオペレーションズマネージャーの木村が担当しました。原文はこちらです。

【寄稿】両備システムズが挑む、地方自治体ガバメントクラウドのコスト最適化～共同利用（ネットワーク分離方式）で長期継続割引を使いこなし、クラウド利用料を削減～

Hitoshi Ebiko — Fri, 06 Nov 2026 06:19:56 +0000

本稿は、株式会社両備システムズガバメントクラウド推進室岩倉竜太氏による寄稿です。

※本記事でご紹介する効果は、両備システムズの環境における実績であり、すべてのお客様で同等の効果を保証するものではありません。

はじめに

みなさん、こんにちは。株式会社両備システムズでガバメントクラウドの構築・運用を担当している岩倉と申します。私たちは、岡山県を基盤に全国の地方自治体の情報システムを支援しており、現在はデジタル庁が提供するガバメントクラウド上で、複数の地方公共団体の業務システムを運用しています。

図表１：株式会社両備システムズ事業紹介

当社は、行政、医療、ヘルスケアなど、地域社会を支える幅広い分野でシステムを提供しています。私たちがご支援している地方自治体のシステムは、ガバメントクラウドの「共同利用方式」のうち「ネットワーク分離方式」を採用しています。これは、1つのAWSアカウント（LinkedID）を複数の団体で共同利用し、団体ごとにVPC（Virtual Private Cloud）を分離して構成する方式です（図表2）。各団体のリソースはコスト配分タグ（以下、タグ）で識別し、利用状況に応じて費用を按分しています。現在、複数の地方公共団体のシステムを本方式で運用しています。

図表２：ガバメントクラウド共同利用（ネットワーク分離方式）のアーキテクチャ

※本図は考え方を示す概念図であり、実際のシステム構成を示すものではありません。

ガバメントクラウドへの移行が進むにつれ、多くの自治体にとってクラウド利用料の最適化が共通の課題となっています。中でも Amazon EC2 や Amazon RDS といったコンピューティング・データベースの利用割合は大きく、ここに「長期継続割引」（Savings Plans および Reserved Instance）を適切に適用できるかどうかが、コスト最適化の成否を大きく左右します。一方で、「ネットワーク分離方式では長期継続割引を適用できないのではないか」という声を耳にすることがあります。単独利用方式やアカウント分離方式にはない課題があるなど、適用にあたり検討する要素が多いことは事実です。しかし、AWSの仕様を正しく理解し、利用状況や将来計画を踏まえて長期継続割引を適切に活用することで、ネットワーク分離方式においてもクラウド利用料の削減が期待できます。本記事では、私たちがどのようにこの課題と向き合い、実践してきたのかをご紹介します。

コスト最適化の取組みの経緯

私たちがコスト最適化に本格的に取り組み始めたのは、ガバメントクラウドでの運用を開始し、システム運用が安定した時期からです。移行の初期は、まず安定稼働を最優先に環境を構築し、運用が軌道に乗った段階で、クラウド利用料の最適化の取組みを本格化しました。具体的には、2025年度を検討・準備の期間と位置づけ、2026年度は4月1日から長期継続割引を適用できるよう準備を進めてきました。

自治体情報システムの標準化においては、移行後の運用経費を含めたコストの適正化が重要なテーマとなっています。当社においても、この趣旨を踏まえ、クラウド利用料の継続的な最適化に取り組みました。当社が運用する環境には、原則として24時間365日のサービス提供を前提とする業務システムがあるため、稼働時間の調整だけでなく、長期継続割引の活用も必要と考えました。コスト最適化に向け、Cost Explorerを中心としたコストの可視化・分析、インスタンス等のAWS環境の見直し、そして本記事の主題である長期継続割引の適用に、段階的に取り組んできました。2026年度からは、AWS Cost and Usage Report（CUR）等の利用データを基に、各団体の利用状況を確認しています。また、割引適用後の費用については、契約条件および当社が定める算定方法に基づき、各団体への説明可能性を確保しながら取り扱っています。AWSの各種分析・推奨情報も参考にしながら、アプリケーションの性能要件や運用条件、検証結果を総合的に確認し、最適化方針を判断しています。

長期継続割引適用に向けた課題と解決方策

ネットワーク分離方式ならではの課題

長期継続割引（Savings Plans / Reserved Instance）は、1年または3年の期間にわたり、一定の時間当たり利用額または対象リソースの利用をコミットすることで、オンデマンド料金より低い料金が適用される料金モデルです。ガバメントクラウドでは、デジタル庁のガイドラインに基づき、Amazon EC2についてはCompute Savings Plansを、Amazon RDSについてはReserved InstanceまたはDatabase Savings Plansを、いずれも前払いなし（No Upfront）で利用できます。（購入可能なプランや期間などの詳細は、デジタル庁のGCASガイドに掲載されています。参考として本記事にも一覧を掲載します。）

（出典）内閣官房「国・地方デジタル共通基盤推進連絡協議会ワーキングチーム（第10回）」

図表３：ガバメントクラウドにおける長期継続割引の適用方針

ネットワーク分離方式には、単独利用方式やアカウント分離方式とは決定的に異なる難しさがあります。それは、長期継続割引が「アカウント単位」で適用されるという AWS の仕様です。

具体的には、次のとおりです。

・長期継続割引は、AWS 側のロジックに基づき、購入条件に合致する利用へ自動的に適用されます。タグを付けて購入した場合でも、タグ単位で割引の適用先を指定することはできません。

・ Savings Plans の使用率（Utilization）レポートやカバレッジ（Coverage）レポートも、アカウントやリージョン、インスタンスファミリー単位での表示となり、タグ単位（＝団体単位）での内訳は確認できません。

・単独利用方式やアカウント分離方式では、AWSアカウントが団体ごとに分かれているため、割引はその団体のアカウントに正確に反映されます。

しかしネットワーク分離方式では、1つの AWSアカウントを複数団体で共有しているため、「この団体に、この割引を」とタグ単位で割り当てることが仕組み上できないのです。私たちはこの点を正しく理解したうえで、「だから適用できない」と諦めるのではなく、「どうすれば使いこなせるか」という視点で戦略を組み立てました。

長期継続割引適用に向けた戦略と実行

私たちは、長期継続割引の購入を次の検討ステップに沿って進めています。各ステップで、ネットワーク分離方式ならではの難所をどう乗り越えたかをご紹介します。長期継続割引の適用方針は、まず当社で取りまとめたうえで各自治体に説明し、合意を得たうえで進めています。

STEP0：コミット前の最適化

長期継続割引の購入前に、まず不要なリソースの削除やインスタンス構成の見直しなどを実施し、環境の最適化を十分に行います。最適化しないままコミットすると、過大な利用量を前提とした契約となり、無駄なコストを長期間固定化してしまうためです。

また、RDSについては、現行構成をそのまま長期継続割引の対象とするのではなく、費用対効果、性能要件、動作条件および今後の構成変更の可能性を確認しました。そのうえで、本番稼働前の環境については、検証結果を踏まえて第7世代のDBインスタンスファミリーへ変更しています。このように、長期継続割引の購入を検討する前に、継続利用するリソースと今後変更する可能性があるリソースを整理しました。これにより、最適化後も安定的に利用することが見込まれる範囲を見極め、必要以上のコミットを行わないようにしています。

STEP1：購入量（ベースライン）の決定

次に、どれだけの利用量をコミットするかを決めます。私たちは、Cost Explorerのデータをもとに、毎時の最小利用量であるベースラインを見極め、コミット額を算定しています。具体的には、1時間当たりの利用実績を把握したうえで、ガバメントクラウドの料金体系やGCASガイド等を参照し、購入量を検討しました。 Compute Savings Plansについては、稼働中のインスタンスをタイプ別に把握し、24時間連続して稼働する利用量を基準として、Savings Plans適用後の時間単価を積み上げています。ただし、現在の利用量のすべてを対象とするのではなく、構成変更や利用量の変動があった場合にも継続して利用することが見込まれる範囲をベースラインとしています。 RDSについては、Reserved DB Instanceの購入条件と、共同利用アカウント全体における継続的な利用量を確認しました。本番環境については、DBエンジン、DBインスタンスクラス、リージョン、配置方式および数量等を確認し、第6世代のDBインスタンスファミリーを使用し、継続的に稼働する本番環境の利用量を基に、条件に合致するReserved DB Instanceを購入しています。 Reserved DB Instanceの割引は、特定の団体や特定のDBインスタンスを指定して適用するものではなく、共同利用アカウント内で購入条件に合致する利用へ自動的に適用されます。このため、個別の団体やリソースを基準とするのではなく、共同利用アカウント全体で継続的に利用することが見込まれる本番利用量を基に購入量を決定しました。なお、本番稼働前の環境は、STEP0で記載した構成の最適化を行うとともに、今後も構成を変更する可能性があります。変更後を含めた継続的な利用量を現時点で確定することが難しいため、RDSに対するDatabase Savings Plansは2026年度の購入対象としていません。

STEP2：長期継続割引の購入オプションの選択

デジタル庁のGCASガイドに従い、Amazon EC2 については Compute Savings Plans を利用します。Compute Savings Plans はインスタンスファミリーやリージョン、OS、対象サービスを跨いで柔軟に適用されるため、将来のモダン化にも対応しやすいという利点があります。RDS についてはReserved Instanceを選択しています。期間は1年を基本とし、前払いなし（No Upfront）で購入しています。期間を1年としているのは、デジタル庁のGCASガイドに沿った判断です。多くの環境では3年先までの運用状況を見通すことが難しいため、まずは1年での購入を基本としています。

STEP3：年に一度の購入オペレーション

ガバメントクラウドでは、長期継続割引の利用期間がガバメントクラウド利用権付与兼債務引受契約の期間を超えないようにする必要があります。当社の2026年度の購入においては、GCASで示された購入条件およびAWS上の基準時刻を確認し、4月1日午前9時から9時59分までの日本時間内に購入処理を完了する手順としました。Compute Savings Plansは、将来の開始日時を指定した予約購入（キューイング）が可能であるため、事前に予約内容を登録し、開始日時に購入が処理されるようにしています。一方、Amazon RDSのReserved DB Instanceは予約購入に対応していないため、上記の時間帯に担当者がAWSマネジメントコンソールから購入します。限られた時間内で誤りなく購入できるよう、購入内容の事前確認と当日の実施手順をあらかじめ整理しています。

STEP4：購入後のモニタリングと是正

購入後は、使用率（コミットをどれだけ使い切れているか）とカバレッジ（割引対象の利用のうちどれだけを割引でカバーできているか）を継続的に監視します。先に述べたとおり、これらのレポートはアカウント単位で確認するため、長期継続割引が全体として方針どおりの成果を上げているかをチェックしています。また、AWS Cost and Usage Report（CUR）等を用いて各団体の利用状況を確認し、契約条件および当社が定める算定方法に基づいて、割引適用後の費用を取り扱っています。これにより、各団体への説明可能性と透明性の確保に努めています。

取組みの効果

これらの取組みの結果、私たちは長期継続割引をネットワーク分離方式のもとでも有効に活用し、クラウド利用料の削減を実現しています。これらの取組みにより、対象となるAWS利用料について、長期継続割引適用前の料金との比較で最大20％の削減効果を確認しています。なお、削減効果は利用サービス、稼働状況、構成および為替等の条件により異なります。

また、各団体の利用状況と費用の関係を説明できるようにすることで、コストの透明性向上に取り組んでいます。

持続可能なFinOpsの推進に向けて

ガバメントクラウドにおけるコスト最適化は、一度行えば終わりというものではありません。団体の増減、業務システムの更改、AWS の新しいサービスやインスタンスの登場に合わせて、継続的に見直しを続けることが欠かせません。私たちはこれを、FinOps（財務とクラウド運用を密に連携させ、継続的にコストを最適化する取組み）の実践と捉えています。

私たちが最もお伝えしたいのは、ネットワーク分離方式であっても、AWS の仕様を正しく理解すれば長期継続割引は十分に使いこなせる、ということです。「適用できない」という誤解から最適化を諦めてしまうのは、自治体にとっても事業者にとっても大きな機会損失です。そして、持続可能なコスト最適化を実現するには、自治体と運用管理補助者である事業者が、それぞれの役割を共有し、コスト、安定運用、継続的な改善のバランスを取ることが重要です。こうした協力関係を通じて、説明可能性の高い、持続可能なガバメントクラウド運用を目指します。本記事が、同じようにガバメントクラウドの共同利用方式でコスト最適化に取り組む事業者や自治体の皆さまにとって、最初の一歩を踏み出すきっかけになれば幸いです。

著者について

岩倉　竜太（株式会社両備システムズガバメントクラウド推進室次長）

2000年入社。自治体向け健康管理システム「健康かるて」シリーズの導入・保守エンジニアとして、特別区、中核市、市町村を担当。ガバメントクラウド先行事業への参画を経て、ガバメントクラウド推進室の立ち上げからAWSを活用したガバメントクラウド環境の構築・運用を担当。現在は自治体のガバメントクラウド移行や運用最適化の推進に取り組んでいる。

Kiro Crew の Bot のご紹介

稲田大陸 — Thu, 05 Nov 2026 23:31:49 +0000

本記事は 2026 年 11 月 5 日に Kiro ブログで公開された「Introducing bots in Kiro Crew」を翻訳したものです。

図 1: Kiro Crew の Bot の一覧

火曜日の朝、あなたはいくつかのエージェントのセッションを立ち上げるところから 1 日を始めます。1 つは認証モジュールのリファクタリング、もう 1 つは不安定なテスト（flaky test）の原因の調査、3 つ目は新機能のリリースに必要なデータベース移行の計画の下書きです。さらにもう 1 つが、今日このあとの引き継ぎに使うオンコールのまとめを仕上げています。せっかくなので、前から温めていたアイデアを調べるセッションも始めます。自分のコードベースをセマンティック検索できるようにするというアイデアで、業界の優れた事例もあわせて調べさせます。これらを動かしてから、その日最初の打ち合わせに向かいます。戻ってくるころには、作業がかなり進んでいるはずです。

ところが戻ってみると、リファクタリングは、前に承認したはずのツールを信頼するかどうかの判断待ちで、ほぼずっと止まっていました。不安定なテストには修正が入っていますが、なぜその修正にしたのかがはっきりしません。移行計画の下書きはできていますが、大幅な手直しが必要です。引き継ぎのまとめはできたものの、そのエージェントはその後ずっと何もせずに待っています。調査の結果は論文とオープンソースのプロジェクトを集めただけで、どの手法が自分のコードベースに実際に合いそうかの比較はありません。

エージェントは並行して動きました。しかしあなたは、セッションごとにどこで手を止めたかを思い出し、実際に何が終わったのか、何がまだ残っているのか、自分が下すべき重要な判断がどこにあるのかを把握し直さなければなりません。並行して動かすタスクが増えるほど、セッションのあいだでコンテキストを受け渡したり、どのセッションが終わり、どのセッションがあなたの入力を待っているかを確かめたりする時間が増えていきます。作業を止めずに正しい方向へ進め続ける責任は、依然としてあなたにあります。

2026 年 11 月 5 日、Kiro Crew で Kiro の Bot の一般提供が始まりました。Bot は、エージェントによる作業を組み立てて進めるための新しい方法です。ばらばらのセッションで作業する代わりに、作業の特定の部分を受け持つエージェントを Bot として定義し、カスタマイズします。Bot はそれぞれ名前を持ち、長く動き続けます。Bot は自分のメモリを持ち、自分でセッションを動かすので、あなたがセッションを 1 つずつ追いかける必要はなくなります。Kiro Crew はもともと、あなたの仕事の進め方から学習します。Bot によって、その学習が蓄積される場所が変わります。

Bot はそれぞれ名前とアバター、そして続いていく 1 つのチャットを持ちます。あなたはそのチャットで方向を示し、結果を受け取りに戻ってきます。Bot を作るときは、コードベースに合った調査を続ける、といったゴールを決めます。Bot はそのゴールに向けて自分から動きます。作業を追跡するための自分のメモを持っているので、決めたことや未解決の項目を確認できます。Bot が持つものはすべて、Kiro Crew の中のその Bot 専用のワークスペースに置かれます。そこにはあなたがカスタマイズできるダッシュボードもあり、セッションを 1 つも開かずに作業の状況を確かめられます。

図 2: devbot という Bot の、続いていく 1 つのチャット

やるべき作業があると、Bot はセッションを並行して立ち上げて見守り、計画からそれていくものを軌道に戻し、結果を 1 つのチャットに持ち帰ります。あるタスクにあなたの判断が要るときは、Bot はあなたに尋ねつつ、答えに左右されない部分の作業を続けます。チャットでスケジュールを設定することもできます。たとえば、あなたが 1 日を始める前に夜間のビルドの失敗を Bot に調べさせたり、毎週金曜日にリリースノートを用意させたりできます。

Bot には、その仕事に必要なツールと権限だけを与えます。たとえば調査用の Bot は Web を検索し、ファイルを読めますが、ファイルを変更することはできません。デプロイ用の Bot はデプロイのスクリプトを実行でき、変更を加える前に毎回あなたの承認を求めます。Bot がツールの追加をあなたに頼むこともできますが、あなたがその依頼を承認するまで何も変わりません。Bot はそれぞれ自分のメモリを持つので、デプロイ用の Bot がリリースの進め方について学んだことと、調査用の Bot が学んだことは混ざりません。学んだことを分けておくことで、各 Bot はあなたの判断を自分の担当の範囲に当てはめます。

こうして、あなたの手元には、あなたが関わるべき作業が残ります。何をもって良しとするかを決め、結果を確かめ、個々のセッションに逐一指示を出すのではなく、プロセス全体の舵を取ります。

判断の理由を作業と一緒に残す

作業の部分ごとに、判断を左右する固有のコンテキストや細かな事情があります。エージェントがこれらのタスクをまたいで実行するあいだ、あなたは意図とコンテキストを部分から部分へつなぎ、トレードオフをはっきりさせ、各エージェントの判断の背後にある方針を言い直し続けなければなりません。

Kiro の Bot では、あなたの方針が見える形で残り、あとから手直しできます。Kiro Crew の学習は Bot ごとに積み上がっていきます。そのため、単発のタスクではなく、続いていく役割そのものを任せられます。Bot は自分の専門について、あなたが目指す成果、トレードオフの理由、変更に課される制約、すでに下した判断を理解しています。ある Bot が issue の受け付けを受け持ち、別の Bot がリリースの準備を受け持つといった形で、それぞれがその作業のためにあなたが決めたルールに従います。Bot は、ノート PC、Mac mini、EC2 インスタンスなど、あなたが Kiro Crew を動かしている場所で動きます。Bot のクルーは全体として、開発作業のあらゆる場面で、あなたのレビューの基準、リリースのプロセス、あなた独自の好みを支えます。1 つの汎用的なワークフローに押し込められることはありません。

あなたの判断の基準は、続いていく会話と、あなたが返すフィードバックを通じて形になります。あとの作業が同じ判断に依存するとき、Bot はあなたの方針を引き継いで進めます。制約が変わったら Bot に伝えてください。Bot は新しい方針に従い、その内容は確認できるメモとして残ります。Bot があなたとともに変わっていくあいだも、あなたの判断は作業の裏付けとして残り続けます。あなたの役割は、並行するタスクの調整から、方向を決め、あなたの入力が必要なものだけをレビューすることへと移ります。修正や判断を重ねるたびに、Bot はあなたの意図をより正確に理解するようになります。

開発の進め方に合わせてクルーを組む

まず、開発のプロセスを、繰り返し発生する役割や、タスクをまたいで続く役割に分けて整理します。最初は、説明でき、評価もできるプロセスを 1 つ選びます。作業の目的が変わるところや、別のツール、権限、レビューが必要になるところに Bot を足します。作業がどのように Bot に届くか、どの情報源を参照するか、役に立つ引き継ぎとはどういうものか、どんなときにあなたの入力を求めてほしいかについて、境界を決めます。最初は Bot に任せたい作業の範囲と性質に合った境界から始め、結果や無駄を評価しながら少しずつ見直していきます。たとえば issue のトリアージを行う Bot を作り、初めはチケットのキューにだけアクセスできるようにしておき、あとから Slack や、ほかの issue の受け付け経路へのアクセスを足していく、といった進め方ができます。

Bot ごとに専門に合わせて調整する

最初に作る Bot の組み合わせの例を挙げます。Bot ごとに、使えるツール、権限、何をもって作業完了とするかが違います。どの Bot も、ほかの Bot に手を加えずに調整できます。

受け付け用の Bot は、チケットのキューに入った新しい issue を読み、ラベルを付け、重複していそうなものに印を付けます。バグとされたものには、再現手順の下書きを書きます。チケットにコメントはできますが、クローズはできません。
ビルドの健全性を見る Bot は、CI パイプラインを 30 分ごとに確かめます。新しい失敗を、すでに分かっている不安定なテストと切り分け、対応が必要なものだけを持ち帰ります。
コードレビュー用の Bot は、新しいプルリクエストを 1 つずつ、あなたがこれまでに下した判断に照らして確かめます。採用すると決めたエラー処理のパターンや、使わないと決めた依存関係といった過去の判断を覚えているので、レビューが毎回ゼロから始まることはありません。コメントを残したり変更を求めたりはできますが、承認やマージはできません。
リリースの準備を担う Bot は、各リリースの前のチェックリストを受け持ちます。マージされた変更にテストとリリースノートがあることを確かめ、何かを出荷する前にあなたの承認を求めます。

Bot が覚えていることは、どれも表示、編集、削除できます。余計なレビュー、少しずれた結果、無駄な手順が見つかったら、その場で Bot を直接調整することもできます。従うルールを変えたり、ワークフローが変わったときにツールを足したり、権限を絞ったりできます。たとえば、リリースの準備を担う Bot をあなたの作業に合わせて調整していけば、いずれは簡単な変更を CI が通った時点でマージさせることもできるでしょう。Bot ごとに別々に調整できるので、あらゆる種類の作業に 1 つのルールを押し付ける必要はありません。

図 3: Bot の設定。権限、モデル、ワーカーのモデルを Bot ごとに選べる

この調整が積み重なって効いてくるのが、繰り返し行う作業です。ビルドの健全性を見る Bot に、CI パイプラインを 30 分ごとに確かめ、新しい失敗を調べ、対応が必要なものを持ち帰るよう伝えます。スケジュールで動いた記録は作業ログに残り、あなたが見るべき発見や判断が必要な事柄はチャットに戻ってきます。想定済みの失敗を Bot が追いかけていたら、そのことを Bot に指摘してください。以降の実行では、その区別が反映されます。

図 4: Bot のスケジュール。Bot が自分で動くハートビートと、あなたが設定したスケジュールが並ぶ

Bot はそれぞれメモを付けています。メモは、Bot が問題を調べ、タスクを終え、あなたから学ぶにつれて育っていく、プロジェクトについての実務上の理解です。メモを見れば Bot が何を引き継いでいるかが分かり、作業ログを見ればこれまでに何が行われたかを把握できます。何度か実行したら、スケジュールや入力を調整したり、結果にフィードバックを返したりして、プロセスを細かく調整し続けます。

セッションの管理から Bot の管理へ

プロセスの中で自然に引き継ぎが起きる場所ごとに、Bot を作ります。Bot それぞれに固有の要件とアクセス権を与え、前の工程から何を受け取るべきかを決めます。そうして、役割ごとの区別を保ち、それぞれを個別に調整できる状態のまま、クルーを育てていきます。

Bot は、ワーカーエージェントにまたがる並行のセッションを自分で取りまとめられます。ただし、Bot がどこまで自分から動くかは、あなたが許した範囲までです。Bot ごとに動かすモデルを選べ、ワーカーエージェントには別のモデルを選ぶこともできます。Bot は性能の高いモデルで計画を立て、ワーカーエージェントは速くて安いモデルで決まった確認をこなす、という分担ができます。Bot がスケジュールで動く作業や繰り返しの作業を多く担うようになるほど、あなたは結果をレビューし、各 Bot が受け持つ作業によりよく合うように調整することに時間を使えるようになります。

図 5: Bot が動かすワーカーのセッション

Bot が取りまとめている作業は、ダッシュボードで見える形にできます。活動やレポートをどのように見たいかを Bot に伝えると、その作業の今の状態が、Bot が管理するダッシュボードにまとめて表示されます。チャットは、あなたが目を通すべき発見、引き継ぎ、質問に絞られたままです。活動の中身を確かめたいときは、関連するセッションを開いてレビューできます。

図 6: GitHub の issue を扱う Bot のゴールとマイルストーンと、その横に並ぶ Bot が管理するダッシュボード。直近 1 週間に報告された issue をトピックごとに図にしている。原文の記事ではこの画面を動画で紹介しているため、ここではその 1 コマを載せた（動画は原文の記事で見られる）。

時間がたつにつれて、クルーはあなたの実際の開発の進め方を映すようになり、各 Bot は自分が受け持つ作業の要件と境界を担うようになります。そのプロセスをどう変えるか、どこであなたが判断するかは、あなたが決めます。

Kiro の Bot を使ってみる

始めるには、Kiro Crew のサイドバーで Bot のワークスペースを開き、Bot を追加して、ベースにするエージェントとして既定のエージェントかカスタムエージェントを選びます。カスタムエージェントを選ぶと、そのプロンプト、モデル、ツール、スキルを Bot が使うので、今あるチャットを変えずに、すでに使っている設定をもとに Bot を作れます。

まずは、今まさにセッションをまたいでコンテキストをつなぎ直す手間がかかっている役割を 1 つ選びます。1 回で見直せるくらいに範囲が狭く、繰り返す価値があるほど役に立つものがよいでしょう。Bot に名前を付け、何を見てほしいかを伝え、一緒に作業しながら調整し、スケジュールも足してみてください。続いて、プロセスの中の次の役割にも Bot を足し、あなたの仕事がタスクを任せる形からプロセスを任せる形へと変わっていく様子を確かめてください。

Kiro Crew をダウンロードして始めましょう。詳しくは Kiro Crew のページをご覧ください。

原文の著者

Kyle Seaman（Product Lead）、Helen Hasbun（Product Marketing）

翻訳者について

【自動車業界】車載ソフト開発をクラウドネイティブに ─ dSPACE × AWS で加速する次世代クルマづくり（dSPACE Japan User Conference 2026 で発表）

shinwst — Thu, 05 Nov 2026 08:40:26 +0000

はじめに

みなさんこんにちは、ソリューションアーキテクトチームリーダーの白石です。2026 年 9 月 17 日に TAKANAWA GATEWAY Convention Center で開催された「dSPACE Japan User Conference 2026」にて、パートナープレゼンテーションとして「車載ソフト開発をクラウドネイティブに ─ dSPACE × AWS で加速する次世代クルマづくり」というテーマで登壇しました。

車載ソフトウェアは発売前に短期間で作り切るだけでなく、発売後も OTA で更新し続けることが求められるようになり、しかも 1 台に載るソフトウェアは大規模化し続けています。その中で、dSPACE のソリューションを AWS 上で動かすと何が変わるのか？この記事では、セッションの内容を解説するとともに、関連する公開事例と技術ブログをご紹介します。

自動車ソフトウェア開発の 2 つのチャレンジ

自動車ソフトウェア開発のチャレンジは多岐にわたりますが、セッションでは代表的な 2 点を取り上げました。

1 つ目は、OTA (Over-the-Air) による更新が前提になり、発売後も高頻度なリリースが続くため、開発と検証が発売時点で完結しなくなったことです。更新の頻度はメーカーによって大きく異なり、先行するメーカーでは高頻度な更新がすでに常態になっています。

2 つ目は、System of Systems として複雑さが増すことです。クルマの機能を少数の高性能なコンピューターにまとめる流れが進み、ECU の数は減る方向にあります。ある調査会社の Web 記事では、2030 年までに 1 台あたりの ECU が 100 個超から 10 個未満になるという見通しも示されています。一方でソフトウェアの量は増え続けており、2027 年には 1 台あたり 6 億行に達するという予測もあります。より少ないハードウェアの上で、より多くのコードが動くようになります。言い換えれば、ECU の数が減っても検証の負担は減らず、多数の機能を少数の計算基盤に統合するソフトウェアインテグレーションの難易度が格段に上がります。

この 2 つに同時に対応するには、「複雑なものは時間と工数をかけて検証する」という従来の進め方だけでは足りません。セッションでは、これに対して次の 3 つをお伝えしました。

シミュレーションを活用した仮想開発 (Virtual Engineering) は、すでに AWS 上で稼働しており、クルマ開発で利用されている
クラウドに載ると、工程の自動化や作業記録、成果物とエビデンスの保存も仕組みで自動化できる
さらに生成 AI を組み合わせて効率化できる

Virtual Engineering はすでに AWS 上で稼働している

dSPACE のソリューションは、モデルベース開発 (MBD) からデータ駆動開発 (DDD) まで工程全体をカバーしており、特殊なハードウェアを必要とするソリューションを除けば AWS 上で動かせます。dSPACE のソリューションに代表されるような Virtual Engineering は、すでに AWS 上で稼働するようになっています。AWS 上の Virtual Engineering 環境は、大きく 3 つの要素で構成されます。必要なエンジニアリングツールが揃った VDI 環境、ビルドや検証、シミュレーションなどの重い処理を実行するパイプライン、そして開発に使うデータを集約したデータ基盤です。dSPACE のソリューションは、このうち VDI 環境とパイプラインの上で動きます。セッションでは公開事例を 3 つご紹介しました。

トヨタ自動車株式会社 ── VDI 環境
パワートレーン電子開発部では、dSPACE の TargetLink を含む 20 種類以上の開発ツールを Research and Engineering Studio on AWS (RES) の仮想デスクトップに集約しています。社内のソフトウェア教育では、ツール環境のセットアップが丸 1 日から 15 分に短縮され、200 台以上をまとめて配布・更新・削除しています。量産開発へは本格展開の段階です。（導入事例）
日産自動車株式会社 ── パイプライン
Engineering Cloud として CI、機械学習の学習、ソフトウェア評価を AWS 上に構築しています。AWS Lambda による並列処理で、統合 SIL のテスト実行時間をオンプレミス比で 75% 削減しました。（AWS ブログ／導入事例）
本田技研工業株式会社 ── データ基盤
AWS 上に構築した Digital Proving Ground (DPG) により、実車を製造する前にクラウド上で設計とテストを行っています。車両データを集めるデータレイクも同じ基盤の上にあります。（プレスリリース／TECH PLAY の記事前編・後編）

AWS 自身が直接貢献できる部分もあります。車載 ECU と同じ Arm アーキテクチャの AWS Graviton では、Arm 向けのソフトウェアをそのまま動かせます。Graviton 上で仮想 ECU を動かす製品も AWS Marketplace で提供されています。dSPACE とは、dSPACE VEOS で仮想化した ECU と Graviton 上の HPC を接続するコンセプト実証を「AWS における自動車 E/E アーキテクチャのシミュレーション Part 1／Part 2」で公開しています。実機 ECU をつないで検証する HiLS (Hardware-in-the-Loop Simulation) を置き換えるものではなく、その前段における各種検証を充実させる取り組みです。

ここでご紹介した事例で使われている、代表的な AWS サービスは次のとおりです。

	AWS サービス	一言解説
	EC2 Image Builder	ツールをインストールした仮想デスクトップのイメージを作成・更新する
	AWS CloudFormation	環境の構築をテンプレートで自動化する
	AWS Step Functions	ビルドやテストの手順をワークフローとしてつなぐ
	AWS Lambda	サーバーを用意せずに処理を実行し、多数のテストを並列で回す
	AWS CodeBuild	ソースコードのビルドとテストを実行する
	Amazon Elastic Container Registry (Amazon ECR)	ビルド環境や実行環境のコンテナイメージを保管する
	Amazon Elastic Compute Cloud (Amazon EC2)	シミュレーションなど重い処理の計算資源を必要なときに用意する。Graviton による Arm 環境も選べる
	Amazon SageMaker AI	機械学習モデルの学習を実行し、マネージド MLflow で学習条件と結果を管理する
	Amazon Simple Storage Service (Amazon S3)	車両データや検証結果などを大容量で保管する
	Amazon Redshift	集めたデータを分析するデータウェアハウス
	AWS Direct Connect	拠点やテスト車両から大量のデータを専用線で AWS に送る

クラウドに載ると、工程と記録も自動化できる

開発・検証環境が AWS 上にあることの利点は、速さだけではありません。データと成果物 (アーティファクト) が同じ場所に揃うため、次のことを仕組みとして自動化できます。

工程の自動化: ビルド、テスト、学習をパイプラインとして自動で回す。日産自動車の CI 自動化はその一例です
作業記録の自動化: どの版を、どの入力で実行し、どんな結果になったかが、実行と同時に残る
成果物とエビデンスの保存: コード・データ・環境を分けて保存し、同じ実行条件を後から再現できる

dSPACE Japan との共著ブログ「dSPACE と AWS で実現する自動運転 AI 開発の効率化」では、dSPACE RTMaps と IVS によるデータの収集・整備、Amazon SageMaker AI とマネージド MLflow による学習、dSPACE の SiLS (Software-in-the-Loop Simulation)／HiLS による検証を 1 本のパイプラインにつないだ実装を紹介しています。検証結果をデータ条件やモデル情報と結び付け、データセットの見直しへ戻せるため、改善のサイクルが閉じます。

OTA で更新を続けるなら、過去の版を「どの条件で、どう検証したか」引けることが前提になります。ただし、これでトレーサビリティが完成するわけではありません。紐付けるべきデータが揃い、何を証跡とするかを各社の運用で決められるようになります。こうした取り組みはすでに先行する事例が出てきており、これから多くの企業で活用されていくと考えています。

生成 AI でさらに効率化する

データとツールが AWS 上に揃っていると、生成 AI が読める対象が 1 か所にまとまります。こちらも実装例が出始めた段階です。

ツール操作と設計書の自動化

共著ブログ「生成AIで開発ツール操作を自動化 – Kiro × MCP Server × dSPACE ControlDesk」では、Kiro に自然言語で指示すると、dSPACE ControlDesk を操作する Python コードと、その設定を記録した設計書が同時に生成される PoC を紹介しています。dSPACE 社のドキュメントを扱う際の設定を含め、詳しくはブログをご覧ください。

AI 駆動テストオートメーション（会場デモ）

会場のブースでは、生成 AI がテスト仕様書からテストケースを作り、VEOS と ControlDesk で実行し、その結果からテストケースを改善するループを展示しました。生成 AI でテストケースを生成し、実行と合否の判定はツールが担います。詳細は別の記事でご紹介する予定です。

おわりに

このブログでは、dSPACE のソリューションに代表される Virtual Engineering を AWS 上で動かす意義を、3 つに分けてご紹介しました。Virtual Engineering を AWS 上で稼働させることは、すでに各社で実用化されています。一方で、工程と記録の自動化や、生成 AI との組み合わせは、これから広げていく領域です。dSPACE と AWS は、この領域にお客様と一緒に取り組んでいきたいと考えています。

ご関心のある方は、お近くの AWS のアカウントチームまたは AWS for Automotive までご連絡ください。

本セッションの資料作成にあたり、アマゾンウェブサービスジャパンの丹羽伸二、衣笠昭弘、畔柳竜生、長谷川仁志、山田遼太、髙橋佑介、Senthil Sena、保木本祐二の協力を得ました。また、登壇の機会をいただいた dSPACE Japan 株式会社の皆様に感謝いたします。

著者

白石真一 (Shiraishi, Shinichi)

アマゾンウェブサービスジャパン合同会社
グローバル自動車・製造事業本部ソリューションアーキテクトチームリーダー。自動車 OEM で AD/ADAS・コネクテッドカーの車載ソフトウェア開発に 15 年以上従事し、2022 年より現職。博士（工学）。

クレジットプーリングで Kiro のクレジットをチーム全体で共有する

吉村弘明 — Thu, 05 Nov 2026 08:03:25 +0000

本記事は、2026 年 11 月 4 日に Shweta V A、Ranjith Ramakrishnan、Krishna Parab が公開した「Share Kiro credits across your team with credit pooling」を翻訳したものです。

AI 利用料が予算の課題になっている理由

AI コーディングツールが開発の重要な一部になるにつれて、AI のクレジット使用量は急速に増えています。ただし、AI の使われ方は開発者やチームによって一様ではありません。クレジットを個人のサブスクリプションごとに均等に割り当てる方式は、チームのクレジット消費の実態と合いません。その結果、クレジットの使い方に無駄が生じ、毎月の請求額も予測しにくくなります。多くの組織にとって、AI のコストを管理することは、予算計画を立てる際の最大の懸案事項になっています。

心当たりはありませんか。同じ課題を抱えているのはあなただけではありません。よくある状況は次のとおりです。

一部のパワーユーザーがクレジットの大半を消費する一方、ライトユーザーはクレジットを使い切れずに失効させています。
AI エージェントが誰にも気づかれないまま、夜間に想定外の料金を発生させることがあります。
個別のシートライセンスによって請求が分断されます。あるグループの未使用クレジットを、別のグループの超過利用に充てることはできません。
利用上限を簡単に適用する方法がありません。

チームには、AI の購入、共有、ガバナンス、利用予測をより柔軟に行う方法が必要です。今回、この課題に直接取り組みます。クレジットプーリングは、AWS アカウントを通じて請求を行いながら、予測可能な AI 利用料に対するコスト効率、ガバナンス、利用の柔軟性を提供します。Kiro Enterprise のお客様向けに提供を開始しました。チームが AI の利用を共有して統制するための、より賢く経済的な方法です。

クレジットプーリングとは

クレジットプーリングは、Kiro の企業向け料金モデルです。組織全体の Kiro クレジットを 1 つの共有プールにまとめ、チーム全体で使えるようにします。クレジットは全員が引き出せる共有プールに追加されるため、パワーユーザーはライトユーザーが使っていない分のクレジットを利用できます。管理者は各ユーザーに利用上限を設定でき、その利用分は共有プールから差し引かれます。クレジットプーリングでは、購入、可視化、ガバナンスを一元管理できます。請求は AWS アカウントを通じて行われるため、Kiro の料金は他の AWS の支払いと一緒に表示されます。

仕組みと中核となるメカニズム

シートあたり月額 $20（最小 2 シート）：請求サイクルの途中でシートを追加した場合、そのシート料金と、共有プールに追加される 500 クレジットは、残り日数に基づいて初月分が日割りされます。
シートごとに 500 クレジットを含む：各請求サイクルで共有プールに追加されます。毎月リセットされます。
追加クレジットは 1 クレジットあたり $0.04：購入するとすぐにプールに追加されます。購入したクレジットは最長 12 か月間繰り越せます。そのため、1 回の購買手続きで必要な容量をまとめて確保でき、先々の計画も立てやすくなります。
スマートなクレジット消費：チームはまずシート料金に含まれているクレジットを使い、次に追加購入したクレジットを使います。購入分は有効期限が近いものから消費されます。あるチームの余剰分が、別のチームの繁忙期を支えます。
二重請求は発生しません：ユーザーが複数のグループに所属していても、組織が支払うのは 1 シート分だけです。

クレジットプーリングにより、実際のコスト削減、より強固なガバナンス、AI 利用の柔軟性が得られます。

共有クレジットによる実際のコスト削減

クレジットプーリングの中核的な価値はシンプルです。どのチームでも、AI の使用量は一様ではありません。開発者は、スプリントの最中には多くのクレジットを使う一方、コードレビューに集中しているときは使用量が少なくなります。クレジットが個人のシートに紐づいていると、ライトユーザーのクレジットは使われないまま残り、ヘビーユーザーは不足して追加購入が必要になります。プーリングによって無駄が減ります。クレジットを共有すれば、メンバー間の使用量のばらつきを組織全体で吸収できます。あるチームの余剰分が、別のチームの繁忙期を支えます。

例：ある企業が 20 シートを購入し、毎月 10,000 のシート料金に含まれたクレジットを共有プールで得ているとします。エンジニアリング（9 人）、デザイン（5 人）、データサイエンス（6 人）のメンバーは、全員が同じプールから引き出します。クレジットプーリングがない場合、AI コーディングツールをほとんど使わない 3 人の開発者は、毎月合計 1,500 の含まれたクレジット（シートあたり 500）を使わないまま残す可能性があります。一方で、含まれたクレジットを使い切った他のメンバーは、追加クレジットを購入する必要が生じるかもしれません。クレジットプーリングでは、これら 1,500 のクレジットが共有プールに追加され、複雑なリファクタリングを実行しているパワーユーザーが自動的に利用できます。そのため、追加クレジットを購入する前に、これらを使えます。手動でのリバランスは不要です。

チーム間で自然に負荷が分散されることに加えて、グループ単位の購買を積極的に管理する組織では、緊急のクレジット購入が減ります。また、プールの容量を実際のチームの利用パターンに合わせて適正化できるため、さらなる節約につながります。

AI 利用をきめ細かく統制する

クレジットプーリングは、ガバナンスの仕組みとしても機能します。Kiro には、管理者が他の企業リソースと同じように AI 利用を管理できるよう、明確なポリシー、リアルタイムの適用、自動化されたガードレールが備わっています。

3 段階の利用上限の階層

管理者は、プロファイル、グループ、個人の 3 つのレベルで利用上限を設定できます。優先度は、プロファイル、グループ、個人の順に高くなります。複数のグループに所属するユーザーには、ユーザーに有利になるよう、最も高いグループの上限が適用されます。開発者が上限に達すると、管理者が追加クレジットを購入するまで、それ以上の利用はブロックされます。そのため、月末に予期しない料金が発生することはありません。

スマートなしきい値通知

Kiro は、クレジットの使用率が設定したしきい値に達すると、管理者に設定可能なアラートを送信します。初期設定では、次の 3 項目が 80% と 100% に達した時点で通知されます。各ユーザーの限度額に対するクレジット使用率、プールクレジットの限度額、および購入済みシート数に対する割り当て済みシート数の利用率です。管理者は、クレジットが枯渇する前に先手を打てます。

プールメンバーの管理

シートの照合は自動で行われます。グループは手動で作成することも、AWS IAM Identity Center（IdC）から取り込むこともできます。サードパーティの ID プロバイダーによるグループ管理も、近日中に利用できるようになります。請求サイクルの途中でシートを追加した場合も、クレジットは即座にプールに追加されます。ユーザーが退職したり役割を変えたりしても、請求を中断させることなくシートの割り当てが更新されます。

これらの管理機能に対する API は近日提供予定です。プログラムからガバナンスを管理できるようになります。

可視性、柔軟性、予測可能性を高めて計画を立てやすくする

測定できないものは管理できません。クレジットプーリングは、組織のあらゆるレベルの AI 利用料をリアルタイムで管理者に示すとともに、利用状況の変化に合わせて支出を調整する柔軟性を提供します。

リアルタイムのモニタリングダッシュボード

プールレベルのダッシュボードには、組織全体で利用可能、消費済み、残りのクレジットの合計が表示されます。シート使用率の追跡により、どのシートが十分に使われていないかを確認できるため、プールの規模を適正化できます。

より良い計画の立案

クレジットプーリングを使うと、個々のサブスクリプションや割り当て量を都度調整しなくても、利用パターンの変化に対応できます。グループレベルの利用傾向は、長期的な計画に役立ちます。購入したクレジットは最長 12 か月間有効なので、先を見越して追加クレジットを計画的に購入できます。

クレジットプーリングを始める

クレジットプーリングは、企業のエンジニアリングチームが求めていた 3 つのことを実現します。共有クレジットによるコスト効率の向上、きめ細かな制御を備えた一元的なガバナンス、そして、チーム全体で AI 利用料を予測しやすくする利用の柔軟性です。

クレジットプーリングで得られるものは次のとおりです。

コスト効率：ライトユーザーの使われないクレジットを減らす、または無くすことです。パワーユーザーは、チーム全体のプールを利用できます。
ガバナンスの深さ：プロファイル、グループ、個人の各レベルで利用上限を設定できる点です。
計画の確実性：利用状況のダッシュボードとしきい値アラートで、月末の予想外の事態を防げる点です。
企業としての信頼：AWS ネイティブの請求統合と AWS IdC によるグループ管理により、組織全体での AI 利用を支える点です。

チーム内でクレジットを共有する準備はできましたか。新規の Kiro Enterprise のお客様では、クレジットプーリングがデフォルトです。既存の Enterprise のお客様も、準備ができたら有効にできます。チームでの利用を検討するには料金ページを参照してください。パイロット導入をご希望の場合は、お問い合わせください。詳しい設定手順はドキュメントを参照してください。

翻訳は Solutions Architect の吉村が担当いたしました。

Amazon S3 Tables で Apache Hive テーブルから Apache Iceberg へのマネージドな移行が可能に

Sotaro Hikita — Thu, 05 Nov 2026 07:19:47 +0000

本記事は 2026 年 11 月 4 日に公開された「Amazon S3 Tables now offer managed migration of Apache Hive tables to Apache Iceberg」を翻訳したものです。

本日から、データレイクのモダナイゼーションをシンプルかつ低コストで進められるよう、Amazon S3 Tables で Apache Hive テーブルから Apache Iceberg へのマネージド移行が利用できるようになりました。対象となるのは、AWS Glue Data Catalog に登録された Amazon S3 上の Parquet テーブルです。パイプラインの構築やコンピューティングのプロビジョニングをせずに、本番ワークロードを動かしたままデータレイクをアップグレードできます。

Apache Iceberg は、大規模な分析データセットのオープンスタンダードになりました。スキーマ進化、hidden partitioning、タイムトラベルクエリなどの機能でペタバイト規模のテーブルを管理でき、データはオープンな形式のまま、Iceberg 互換の任意のエンジンからクエリできます。Amazon S3 Tables は、Iceberg テーブルが大きくなってもパフォーマンスとコスト効率を保てるように設計されたフルマネージドのストレージです。自動メンテナンス、最適化、レプリケーション、S3 Intelligent-Tiering などの機能を標準で備えています。

新機能の概要
これまで Apache Hive テーブルを Apache Iceberg に移行するには、必要なインフラの構築と管理に数週間のエンジニアリング作業がかかることもありました。データ型の変換やロールバックの仕組みづくりも運用を複雑にしていました。今回、移行を API で操作できるマネージドな処理として利用できるようになりました。

S3 Tables は、データ検証、互換性チェック、型変換、ファイルの再圧縮、コンパクションを含む移行ワークフロー全体を処理します。データをコピーする前に、S3 Tables は対象となるソースオブジェクトをすべて洗い出し、互換性レポートを生成します。同期は必要な回数だけ実行でき、ソーステーブルへの書き込みを止める必要があるのは切り替え時の数分間だけです。準備が整ったら移行を完了でき、テーブルがオフラインになる時間を最小限に抑えられます。

S3 Tables のマネージド移行は、自前で移行する方法と比べてコストを抑えられます。料金はコピーしたデータ分のみで、Hive から Iceberg への変換自体には料金がかからず、S3 Intelligent-Tiering 上のソースオブジェクトは現在のアクセス階層に留まるためです。

移行を試してみる
AWS Glue の Hive テーブルを移行するには、S3 コンソールで移行先のテーブルバケットを選び、Create table from migration を選択します。

移行先の Iceberg テーブルの名前空間とテーブル名を指定します。移行先テーブルは、クエリパフォーマンスとストレージ効率に合わせて調整された推奨のデフォルト設定で作成されます。

移行を開始すると、S3 Tables はソーステーブルを検証して互換性レポートを生成し、データのコピーを始めます。移行中、移行先テーブルは読み取り専用です。移行を完了すると、移行先テーブルは読み書き可能になります。

AWS コンソールから Amazon Athena や Amazon SageMaker Unified Studio との直接統合を使ってすぐにデータを扱えるほか、Apache Iceberg REST API 互換の任意のツールからテーブルを直接クエリすることもできます。詳しくは S3 Tables の移行に関するドキュメントをご覧ください。

AWS Command Line Interface (AWS CLI)、AWS SDK、Agent Toolkit for AWS も利用できます。たとえば、移行ジョブを設定して start-table-migration コマンドを呼び出します。

cat > /tmp/start-migration.json <<'EOF'
{
  "roleARN": "arn:aws:iam::123456789012:role/S3TablesMigrationRole",
  "destinationTable": {
    "tableBucketARN": "arn:aws:s3tables:us-east-1:123456789012:bucket/my-destination-bucket",
    "namespace": "mynamespace",
    "name": "my_destination_table",
    "encryptionConfiguration": {
      "sseAlgorithm": "aws:kms",
      "kmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"
    },
    "storageClassConfiguration": { "storageClass": "INTELLIGENT_TIERING" },
    "tags": { "team": "s3tables", "purpose": "migration" },
    "properties": {
      "writeFormat": "parquet",
      "icebergFormatVersion": 2,
      "compressionCodec": "zstd",
      "dictionaryEncoding": true
    },
    "schema": {
      "type": "struct",
      "schemaId": 0,
      "identifierFieldIds": [1],
      "fields": [
        { "id": 1, "name": "id",      "type": "long",   "required": true, "doc": "primary key" },
        { "id": 2, "name": "payload", "type": "string", "required": false }
      ]
    },
    "icebergSortOrder": {
      "orderId": 1,
      "fields": [ { "sourceId": 1, "transform": "identity", "direction": "asc", "nullOrder": "nulls-first" } ]
    }
  },
  "sourceType": "glueTable",
  "source": {
    "glueTable": {
      "catalogId": "123456789012",
      "databaseName": "my_glue_database",
      "tableName": "my_source_table"
    }
  },
  "dataMigration": {
    "maintenanceSettings": {
      "icebergCompaction": { "targetFileSizeMB": 512, "strategy": "binpack" },
      "icebergSnapshotManagement": { "minSnapshotsToKeep": 3, "maxSnapshotAgeHours": 168 }
    },
    "migrationPolicies": {
      "unmatchedSourceFieldsPolicy": "fail",
      "incompatibleValuesPolicy": "fail"
    }
  },
  "reviewMigrationPlan": false,
  "migrationOutput": {
    "bucket": "arn:aws:s3:::my-report-bucket",
    "prefixes": {
      "tableCompatibilityReport": "reports/table-compatibility/",
      "objectCompatibilityReport": "reports/object-compatibility/",
      "objectMigrationReport": "reports/object-migration/"
    }
  }
}
EOF

aws s3tables start-table-migration \
  --cli-input-json file:///tmp/start-migration.json

ソース側の変更を移行先テーブルに反映するには、移行を完了する前に sync-table-migration を必要な回数だけ呼び出します。同期のたびにコピーされるのは変更分だけです。

Kiro などのコーディングエージェントを使っている場合は、Agent Toolkit for AWS の migrating-hive-tables-to-s3-tables スキルが、エージェント向けの安全ガードレール付きで移行を段階的にガイドします。このスキルでは次のことができます。

既存の IAM ポリシーを分析し、移行先で同等になるポリシーを提案する
開始前に移行計画を検証する
Start → Sync → Complete の API 呼び出しを実行する
ジョブの進行状況を監視し、検証と切り替えをガイドする

詳しくは、スキルの GitHub README ページをご覧ください。

提供開始
Amazon S3 Tables のマネージド移行は、本日から米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、欧州 (フランクフルト、アイルランド、ストックホルム) リージョンで利用できます。提供開始時点では、同一の AWS アカウントかつ同一の AWS リージョン内にある、AWS Glue に登録された Parquet 形式の Hive テーブルに対応しています。新機能について API の呼び出し、ドキュメントの検索、リージョンごとの提供状況の確認、トラブルシューティングをしたい場合は、お好みの AI ツールで AWS MCP Server とプラグインをお試しください。

ぜひ Amazon S3 コンソールでお試しいただき、AWS re:Post for Amazon S3 または普段ご利用の AWS サポート窓口からフィードバックをお寄せください。

— Channy

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

トヨタはいかにして BasisPilot を構築したか – AWS 上の AI アシスト型 SAP 運用プラットフォーム

Koshi Matsumoto — Thu, 05 Nov 2026 03:49:44 +0000

本ブログは、Toyota Motor North America の SAP チーム（Manish Kumar、Anshuman Kowtha、Ashish Patel）との緊密な協力のもと共同執筆されました。

はじめに

Toyota Motor North America（以下、トヨタ）は、AWS 上の大規模な SAP ランドスケープで、AI アシスト型の SAP 運用プラットフォーム BasisPilot を運用しています。現在の BasisPilot の対象範囲は、開発・テスト・ステージング・本番の各環境にまたがる 60 台以上の Amazon EC2 ホスト上の 20 の SAP システムで、複数の AWS アカウントとリージョンに及びます。このプラットフォームは、ABAP および Java のアプリケーションスタックや、マルチテナント構成を含む SAP HANA データベースなど、主要な SAP ワークロードタイプをサポートしています。従来、このランドスケープの運用には、エンジニアがターミナル、SAP GUI、スプレッドシート、AWS コンソールの間を行き来する必要がありました。

トヨタの SAP BTP Platform 部門で、BasisPilot は Amazon Bedrock を活用したツール呼び出し型の AI アシスタントを組み込んだ、単一ダッシュボードの運用プラットフォームとして設計・開発されました。SAP 運用から始まったものの、現在では AWS 上でホストされるワークロードの可視性、ヘルス指標、一般的なトラブルシューティング情報を、手動のステータス更新を待たずに必要とする、権限を持つプロダクト・インフラ・サポートの各チームにとっても有用なプラットフォームになっています。本記事では、このプラットフォームの機能、アーキテクチャ、背後にある AWS サービス、そして AI アシスタントがヘルスチェックから SAP カーネルアップグレードの計画・実行支援に至るまで、承認済みの運用ワークフローをどのように支援しているかを説明します。

社内発のイノベーション

BasisPilot は商用製品ではありません。トヨタ社内で、SAP BTP Platform と SAP 運用ランドスケープに焦点を当てたエンジニアリングの取り組みとして始まりました。

Manish がこのプラットフォームを構想し、運用モデルを定義し、アーキテクチャ・設計・実装を主導しました。その作業には、共通のエビデンスモデル、サーバーレス API、クロスアカウント制御、非同期ワークフローエンジン、SAP の依存関係ロジック、承認境界、そしてツール呼び出し型の AI レイヤーが含まれます。トヨタの関係者と AWS のメンバーは、レビュー、検証、改良で協力しました。このプラットフォームは、監視、ライフサイクル管理、パッチ適用、HA、DR、バックアップ、コスト、セキュリティといった日々の運用を単一のサーバーレスインターフェースに集約し、承認済みで監査可能なワークフローのための AI アシスト運用レイヤーを備えています。その対象範囲は、SAP 運用ダッシュボードから、権限を持つチーム向けの共通の可視化・トラブルシューティングツールへと拡大しています。

実装を加速するための Kiro の活用

BasisPilot のコンセプト、運用モデル、アーキテクチャを定義した後、Manish は AWS の AI 搭載 IDE である Kiro を開発環境として使い、大規模なコードベースの探索、スキャフォールディングの作成、React と Lambda の境界をまたぐ不具合の追跡、テストや技術ドキュメントの改善といった個別の実装作業を高速化しました。特に、1 つの変更が API コントラクト、DynamoDB でのトラッキング、Systems Manager による実行、ユーザーインターフェースにまたがる場合に役立ちました。

SAP の依存関係シーケンス、承認境界、ロールバック要件、クロスアカウント制御、検証基準は Manish の SAP 運用経験に基づくもので、実際のシステムの挙動と照らし合わせて確認されています。彼は提案をレビューして調整し、BasisPilot の規約に統合し、結果をテストし、最終的な設計と実装の責任を担いました。

本記事の内容について

トヨタの公開コンテンツガイドラインに従い、本記事ではアーキテクチャパターン、AWS サービス、設計上の判断のみを説明しています。アカウント ID、社内ホスト名、エンドポイント、認証情報、システム ID、その他の環境固有の情報は含まれていません。

「私は、AI をどこに当てはめられるかを問うところから始めたのではありません。Basis エンジニアがシステムに触れる前に下さなければならない判断、つまり、どのエビデンスを信頼するか、何をどの順序で行うべきか、何があれば作業を止めるべきか、から始めました。BasisPilot は、その判断をプラットフォームの振る舞いとして書き起こすことから生まれたのです。」

– Manish Kumar、Senior SAP Product Owner、Toyota Motor North America

ミッションと目標

BasisPilot は、改善（継続的改善）の精神に基づく 5 つの原則に沿って開発されました。

単一ダッシュボード – SAP システム、AWS ホスト、クラスター、バックアップ、パッチサイクルを、どの AWS アカウントやリージョンにあるかにかかわらず、1 つのダッシュボードで可視化します。
安全な自動化 – 変更を伴うすべての操作は、ロールベースのアクセス制御、環境に応じた承認ゲート、完全な監査証跡を経由します。
汎用チャットボットではなく AI アシスト運用 – アシスタントは質問への回答、承認済みバックエンドツールの呼び出し要求、診断結果の要約、制御されたワークフローのガイドを行い、検証・承認・実行・監査の制御はプラットフォーム側が担います。
共有のセルフサービス可視化 – 権限を持つアプリケーション・インフラ・サポートの各チームが、ヘルス、アラート、トラブルシューティング情報を直接確認できるため、SAP BTP Platform チームによる手動更新への依存が減ります。
サーバーレスでコスト効率が高い – プラットフォーム自体にパッチを当てるべきサーバーはありません。バックエンドは Lambda、DynamoDB、およびリクエスト課金のマネージド AWS サービス上で稼働します。

プラットフォームの機能

BasisPilot は Amazon CloudFront から配信される React のシングルページアプリケーションで、バックエンドはすべてサーバーレス API で構成されています。アクセスはロールベースで、承認済みワークフローを操作できるユーザーもいれば、読み取り専用の可視化、インシデントのトリアージ、ステータス確認にプラットフォームを使うユーザーもいます。ダッシュボードは次の機能モジュールを提供します。

図 1 – 実際の画面からキャプチャした BasisPilot のランドスケープダッシュボード。運用値はオリジナルのままで、キャプチャ範囲にはマスキングが必要な SID、ホスト名、アカウント、IP の値は含まれていません。

Dashboard: 権限を持つチーム向けのランドスケープ全体のヘルス。システムの可用性、リソースのホットスポット、重大アラート、SLA 達成状況、クラウドインフラの概要をひと目で確認できます。

Systems: ABAP と Java の両スタックに対応したシステム単位のビュー。コンポーネントのステータス（ASCS/PAS/AAS または SCS/JAS とデータベース）、ライブメトリクス、起動/停止/再起動の操作を提供します。

Host Manager: ホストレベルの CPU/メモリ/ディスク、SAP プロセスのステータス、ファイルシステムの詳細（HANA のデータ/ログボリュームを含む）、ホストの一括操作を提供します。

Backup Status: HANA バックアップカタログ（フル/差分/増分/ログ）の可視化、ログバックアップの連続失敗の検知、RPO 違反アラートを提供します。

OS Patching: 環境ごとの AWS Systems Manager Patch Manager のコンプライアンス、パッチベースラインの承認日の自動化、パッチウィンドウ、そして承認ゲート付きの SAP を考慮した再起動オーケストレーション（SAP 停止 → 再起動 → SAP 起動）を提供します。

Cluster Status: Pacemaker/Corosync の HA クラスターのヘルス、HANA System Replication の状態、ノードのロール、フェイルオーバー履歴、安全なクラスター操作（メンテナンスモード、スタンバイ、制御されたスイッチオーバー）を提供します。

Disaster Recovery: AWS Elastic Disaster Recovery を使った DR テストのオーケストレーション。模擬訓練と実訓練、人による確認ゲートを伴うステップごとの実行、テストごとの完全な監査を提供します。

Threat Monitor: SAP のセキュリティインテリジェンス。SAP Security Audit Log による重要トランザクションの監視、HANA の監査イベント、SIEM へのエクスポート（CEF、Syslog、CSV、JSON）を提供します。

Security: SAP セキュリティベースラインのコンプライアンスを自動化。標準ユーザーのチェック、クライアント設定、プロファイルパラメータ、システムの変更可能性、HANA ユーザーのセキュリティを定期的に収集します。

Activity Log: ランドスケープ全体のすべての起動/停止/アップグレード/パッチ/ストレージ操作について、誰が何をしたかの完全な監査証跡を、実行中の操作のライブ進捗とともに提供します。

Cost & Optimization: マルチアカウントの支出トレンド、EC2 のライトサイジングと新世代インスタンスの推奨、Amazon S3 のライフサイクル分析、Savings Plans のカバレッジ、古いバックアップの削除機会を提供します。

Findings: 継続的なセキュリティ/コストのインスペクター。オープンなセキュリティグループ、古い IAM キー、暗号化されていない Amazon EBS、パブリックな S3、アイドル状態のリソース、バックアップボールトの衛生状態を検出します。

AI Assistant: 表示中のページを認識するアシスタント。SAP 運用に関する質問への回答、承認済みバックエンドツールの呼び出し、長時間実行タスクの追跡、ダウンロード可能なレポートの作成を行います。

コアプラットフォームチームを超えた共有の可視化

設計上の重要な成果の 1 つは、BasisPilot が特定の専門グループに限定されないことです。同じヘルス、インベントリ、トラブルシューティングのビューを、RBAC を通じて AWS 上でホストされるエンタープライズプラットフォームを管理または利用する他の権限を持つチームにも公開できます。読み取り専用ユーザーに対しては、システムが稼働しているか、どのコンポーネントが異常か、メンテナンスウィンドウが有効か、問題がホストリソース・バックアップステータス・プラットフォームの可用性のいずれに関係しているか、といったよくある質問にアシスタントが答えます。運用操作は、承認されたロールと承認ゲート付きのワークフローに限定されたままです。

メリットを受けるのは誰か

BasisPilot は企業内のさまざまなロールに、それぞれの責任に応じたアクセスで価値を提供します。プラットフォームから最も大きなメリットを得るのは次のグループです。

SAP Basis およびプラットフォームエンジニア – 承認ゲート付きのワークフローを操作します。起動/停止、OS パッチ適用、カーネルおよび HANA リビジョンのアップグレード、HA クラスター操作、DR 訓練、ストレージ移行などです。
SAP 運用担当者およびオンコール対応者 – アクショントラッカーで長時間の作業を追跡し、記憶から Runbook を組み立て直すことなく、永続化された状態に戻れます。
アプリケーションおよびプロダクトチーム – 依存している SAP ワークロードのシステムヘルス、コンポーネントのステータス、有効なメンテナンスウィンドウを、手動更新を待たずに確認できます。
インフラおよびサポートチーム – 読み取り専用の可視化とアシスタントを使い、アカウントやリージョンをまたいだ一次トリアージを行います。
セキュリティおよびコンプライアンスチーム – SAP Security Audit Log のイベントを監視し、ベースラインコンプライアンスのチェックを実行し、検出結果を全社の SIEM にエクスポートします。
FinOps およびコスト責任者 – マルチアカウントの支出トレンド、ライトサイジングの推奨、Savings Plans のカバレッジ、古いバックアップの削除をレビューします。
監査および変更管理の関係者 – 変更を全社の ITSM や SAP Cloud ALM と結び付ける、完全なアクティビティ証跡とエビデンスパックを活用します。

継続的な監視と SLA トラッキング

ダッシュボードの裏側では、スケジュール実行されるコレクター群が、手動ポーリングなしにランドスケープの状態を最新に保っています。

5 分ごとのライブメトリクス – CPU、メモリ、SAP プロセスのステータス、クラスターの状態を、SSM を通じて全ホストから並列に収集します。コレクターは EC2 の状態を認識するため、停止中のインスタンスが古い「グリーン」を表示することはありません。
1 時間ごとのトレンド履歴 – パフォーマンス（CPU/メモリ/ディスク/ロードアベレージ）とファイルシステムごとの使用量を、TTL による 90 日間保持の専用履歴テーブルに書き込み、推定ではなく実データに基づくトレンドチャートを実現しています。
5 分ごとの SLA 測定 – システムごとの可用性サンプルを、環境別の目標値（開発/テストは 99.0%、ステージングは 99.5%、本番は 99.9%）に対する月次の達成率に集計し、専用の SLA ダッシュボードに表示します。
セキュリティおよびコンプライアンスのチェック – SAP Security Audit Log のイベントを 5 分ごと、セキュリティベースラインのコンプライアンスを 30 分ごとに確認します。
重大アラート – コンポーネント停止、バックアップ失敗、リソースのしきい値超過といった状態を、確認（Acknowledge）ワークフローとともにダッシュボードに表示します。

図 2 – SLA ダッシュボード

メンテナンスウィンドウ

計画停止は第一級の概念として扱われています。専用のメンテナンス API により、エンジニアは任意のシステムを個別または一括でメンテナンスウィンドウに入れることができ、開始/終了時刻、理由、担当エンジニアが記録されます。ウィンドウが有効な間はそのシステムのアラートが抑制されるため、計画作業で誰かが呼び出されることはなく、作成/更新/削除はすべて監査ログに書き込まれます。AI アシスタントもこれに関与します。現在および今後のウィンドウの一覧表示、会話による新しいウィンドウのスケジュールが可能で、アシスタント自身の長時間ワークフロー（カーネルアップグレード、パッチ適用）もメンテナンス状態を尊重・参照します。

「BasisPilot で最も感銘を受けたのは、Manish の設計と実装の独創性、深さ、完成度でした。彼はこれを既存の SAP 機能の導入や、バラバラなツールの寄せ集めとして扱いませんでした。ユーザーインターフェース、API、データベース、認証と認可、ロールベースのアクセス制御、バックエンドサービス、AI 機能、そしてそれらを責任をもって運用するために必要なガバナンスモデルを含む、エンドツーエンドのエンタープライズプラットフォームを構想し、構築したのです。このプラットフォームは、アーキテクチャを稼働させるために開発された Python、React、JavaScript にまたがる広範で深く統合されたコードベースを持つ、相当なエンジニアリングの成果です。

最も重要なアーキテクチャ上の選択の 1 つは、データおよびインテリジェンスのプレーンと、統制されたコントロールプレーンを明確に分離したことです。この分離により、ID、認可、承認、実行、検証、監査を決定論的かつ統制された状態に保ちながら、インサイトや AI 機能を進化させることができます。Manish は SAP の依存関係モデルから、AWS アーキテクチャ、アプリケーションアーキテクチャ、セキュリティモデル、実装に至るまで設計を主導しました。単に導入方法を提案するのではなく、SAP 運用の深い知見を、実際に動くクラウドネイティブなシステムへと落とし込んだのです。このアプローチの効果はすでに表れ始めており、複雑な SAP ランドスケープへの理解が深まり、より根拠のある意思決定ができるようになり、SAP に依存するビジネス運用の信頼性、レジリエンス、継続性に対する確信も高まっています。」

Anshuman Kowtha、Manager、Toyota Motor North America

難しい問題: SAP の時間は HTTP の時間に収まらない

SAP のメンテナンスイベントは、単一のコマンドで完結するものではありません。セントラルサービスを停止する前に、アプリケーションサーバーをドレインする必要があります。共有またはマルチテナントのデータベースは、依存するアプリケーションが稼働している間は停止してはなりません。SAP HANA はフラッシュして検証済みの状態に達するまで時間を要します。起動時は Amazon EC2、AWS Systems Manager、データベース、セントラルサービス、アプリケーションインスタンスの順に待つ必要があります。通常の操作でも 10〜90 分かかり、データベースやアップグレードのワークフローの中には数時間続くものもあります。これらはいずれも同期的な Web リクエストとは相容れません。

そこで BasisPilot は、リクエストの時間と操作の時間を分離しています。アクション API は、長時間の作業を開始する前に永続的なトラッカーを作成します。Amazon DynamoDB には、アクション ID、現在のフェーズ、進捗、完了した結果、承認、エラーが保存されます。ホスト側の作業は AWS Systems Manager Run Command が実行し、ダッシュボードとチャットインターフェースはどちらも同じトラッカーを参照します。Lambda 関数自身の残り時間が少なくなると、状態をチェックポイントして自分自身を非同期に再呼び出しし、ブラウザは単にトラッカーのレコードをポーリングします。同じパターンが、AI エージェントの長時間タスク、OS パッチ適用時の再起動、カーネルアップグレード、マルチテラバイト規模のストレージ移行を支えています。このフェーズベースの自己チェックポイント型の設計は、同期リクエストの時間を超える作業に対して AWS が推奨するパターンであり、これによりトヨタは接続を開いたままにすることなく、数時間に及ぶ SAP 操作を Lambda 上で実行できています。

ブラウザを閉じたり更新したりしても、SAP の停止処理が続くかどうかには影響しません。エンジニアは記憶から Runbook を組み立て直すことなく永続化された状態に戻ることができ、より長いアップグレードでは、監視のチェックポイントにより、変更をやみくもに再実行することなく観測を再開できます。

依存関係ゲートが稼働時間と制御されたダウンタイムの両方を守る

シーケンスは画面に表示されるだけでなく、コードで強制されます。停止時、BasisPilot はアプリケーションインスタンスを停止し、停止したことを検証してから、セントラルサービス、データベース、そして要求された場合は Amazon EC2 を停止します。データベースの停止を検証できない場合、インフラの停止はブロックされます。起動時はこの順序が逆になり、EC2 と Systems Manager の準備完了、データベースのヘルス、セントラルサービス、アプリケーションインスタンスの順に進みます。並列作業は安全なレイヤー内では許可されますが、順序を守るべき依存関係をまたいで行われることはありません。

BasisPilot は「コマンドが受け付けられた」ことを中間状態として扱います。成功とするには意図した結果のライブ検証が必要であり、これにより、データベース、エンキューサービス、アプリケーションプロセスがまだ完了していないのに、ランドスケープが利用可能であると報告してしまうことを防いでいます。

ダッシュボードからアシスタントまで共通のエビデンスモデル

ランドスケープダッシュボード、Systems ビュー、Host Manager、Backup Status、アクショントラッカー、AI アシスタントは、同じ運用エビデンスを異なる視点で見せるものです。システムカードはコンポーネントのロールとワークプロセスのヘルスを示します。ホストビューは CPU、メモリ、ディスク、ファイルシステム、上位プロセスを追加します。Backup Status は、フル、差分、増分、ログの各バックアップ履歴に加え、欠落、失敗、古い状態、継続性の状況を追加します。

そのため、「このシステムはメンテナンスしても安全か？」といった質問に対して、アシスタントはシステムの状態、ホストの負荷、バックアップによる保護状況、クラスターの状況、メンテナンスウィンドウ、最近のアクション履歴をまとめることができます。その後に承認済みのアクションが続く場合は、決定論的なワークフローのコードがシーケンス、認可、実行、検証、監査を制御します。生成されたテキストがシェルコマンドになることは決してありません。

ガードレールはアシスタントが「しないこと」も定義する

BasisPilot は、漠然とした質問をランドスケープ全体を調べる許可とはみなしません。たとえばバックアップステータスは、意図的に単一の SAP システムに範囲を限定しています。これは、バックアップやリカバリポイントの情報を返す前に、プラットフォームが正しい HANA データベースのホストとカタログを特定する必要があるためです。ユーザーが「バックアップステータス」とだけ尋ねた場合、アシスタントはどの SAP システムを確認するかを尋ねます。無関係なシステムを統合したり、直近の文脈から対象を推測したりはしません。

この境界は、モデルやツールが実行される前に強制されます。ユーザーがシステム ID を指定すると、リクエストは読み取り専用のバックアップツールにルーティングされます。同じ原則がすべての機能に適用されます。アシスタントは型付けされ範囲が限定されたツールへのインターフェースであり、あらゆるものを調べたり変更したりする包括的な権限ではありません。

図 3a・3b: 実際の BasisPilot チャットボットのやり取り。漠然としたバックアップステータスの要求はスコープ境界で止められ、アシスタントはバックアップデータを照会する前に SAP SID を 1 つ指定するよう求めています。マスキングしているのは例示の SID の値のみで、リクエスト、レスポンス、タイムスタンプ、画面は改変していません。

アーキテクチャ

BasisPilot はハブアンドスポーク型の設計を採用しています。中央のハブアカウントがプラットフォーム（フロントエンド、API、AI エージェント、すべての DynamoDB の状態）をホストします。スポークアカウント（ステージング、本番、DR）には実際の SAP ワークロードが含まれます。ハブからスポークへのアクセスは、厳密に範囲を限定したクロスアカウントロールへの STS AssumeRole のみを介して行われ、ホストレベルの作業はすべて AWS Systems Manager Run Command を経由します。プラットフォームが管理する操作では SSH キーもインバウンドアクセスの開放も不要です。AWS STS と AWS Systems Manager を用いたこのハブアンドスポークモデルは、クロスアカウント運用に対して AWS が推奨するアプローチに沿ったものであり、トヨタは常設の認証情報やインバウンドのネットワークアクセスなしに、すべてのスポークアカウントにアクセスできています。

以下の図では、ハブアンドスポークの全体像から、サーバーレス、AI、監視、アクションの各レイヤーへと、同じアーキテクチャを段階的に詳しく示します。続くデータフローのセクションでは、これらのコンポーネントが実行時にどのように連携するかを説明します。

図 4 – BasisPilot のリファレンスアーキテクチャ: 認証済みユーザーはサーバーレスのハブプラットフォームにアクセスし、Bedrock の AI エージェントと API Lambda は STS と AWS Systems Manager のみを通じてスポークアカウントの SAP システムに作用します。

図 5 – コンポーネントの詳細ビュー: ハブ内のサーバーレスプラットフォームの各レイヤーと、STS AssumeRole と SSM のみを通じてアクセスされるスポークアカウント内の SAP ワークロード。

データフロー

プラットフォームのレイヤー構成を踏まえると、実行時の流れは次のように追うことができます。

検出（Discovery）。フィーダー Lambda がリソースタグを使って SAP の EC2 インスタンスを検出し（1 つのデータベースが複数の SAP システムに対応するマルチテナント HANA のマッピングも含む）、DynamoDB 内のホスト/システムのインベントリを作成します。

収集（Collection）。EventBridge がコレクター Lambda をトリガーします（ライブメトリクス、クラスターの状態、SLA サンプル、セキュリティイベントは 5 分ごと、パフォーマンスとファイルシステムのトレンドは 1 時間ごと、HANA バックアップカタログは 1 日 3 回）。コレクターは SSM を通じてホスト上で読み取り専用コマンドを並列に実行し、CPU、メモリ、ファイルシステム、SAP プロセス、バックアップ、セキュリティ、SLA のデータを DynamoDB に書き込みます。コレクターは EC2 の状態を認識しており、停止中のインスタンスではキャッシュされたプロセス数を積極的にゼロにするため、ダッシュボードが古い「グリーン」を表示することはありません。

提供（Serving）。API Lambda が DynamoDB から読み取り、保護されたルートには Cognito の JWT オーソライザーを設定した API Gateway を通じて React フロントエンドにデータを提供します。EC2 の状態が常に最初に確認され、停止中のインスタンスはキャッシュされたプロセスデータよりも優先されます。

アクション（Action）。変更を伴う操作（起動/停止、パッチ適用、アップグレード、ストレージ変更）は、フェーズベースのワークフローとして実行されます。各 API 呼び出しはゲートウェイのタイムアウトより十分短く完了し、進捗は DynamoDB で追跡され、UI はトラッカーをポーリングし、停滞したフェーズは回数制限付きの冪等なリトライで自己修復します。

設計上の教訓: すべてをフェーズベースに

SAP の操作は通常 10〜90 分かかり、API Gateway や Lambda の制限をはるかに超えます。BasisPilot は長時間の操作をすべて小さなフェーズに分割し、状態を DynamoDB にチェックポイントします。Lambda は自身の残り時間が少なくなると自分自身を非同期に再呼び出しし、ブラウザ（またはチャット UI）は単にトラッカーのレコードをポーリングします。同じパターンが、AI エージェントの長時間タスク、OS パッチ適用時の再起動、カーネルアップグレード、マルチテラバイト規模のストレージ移行を支えています。

使用している AWS サービス

サービス	BasisPilot での使い方
Amazon Bedrock	AI アシスタントの推論レイヤー。BasisPilot はツール使用（tool use）を伴う Converse API を利用し、モデルが構造化されたバックエンドツールを要求できるようにしています。アプリケーションはそれらのツールを検証・認可したうえで実行します。単純なステータスの質問は低レイテンシーの Claude モデルが処理し、診断、根本原因分析、レポートの統合には、より推論能力の高いモデルを使い分けています。
AWS Lambda	バックエンド全体。API、スケジュール実行のコレクター、AI チャットハンドラー、非同期ワークフローワーカー、SAP Cloud ALM / ITSM 連携ワーカーを含む 40 以上の関数で構成されています。Python 3.x で、モジュール化された共有コードレイヤーを使用しています。
Amazon DynamoDB	40 以上のリクエスト課金テーブルにまたがるプラットフォームのすべての状態。システム/ホストのインベントリ、アクショントラッカー、AI タスクと承認、セッションと OTP、セキュリティイベント、ベースラインコンプライアンス、SLA 履歴、バックアップジョブ、メンテナンスウィンドウ、クラスター情報、コストキャッシュ、アップグレードジョブ、DR テスト、検出結果を保存し、一時的なデータには TTL による有効期限を設定しています。
AWS Systems Manager	プラットフォームが管理するホストへの唯一の経路。Run Command は許可リストに登録されたコマンド（sapcontrol、HDB ツール、読み取り専用の hdbsql、df、crm など）を実行し、Patch Manager は OS パッチのコンプライアンスとベースラインを管理します。SSM for SAP は、該当する場合に SAP アプリケーションの可視化や構成チェックに使用します。
Amazon API Gateway	Lambda バックエンドの前段に置く HTTP API。200 以上のルートを持ち、そのうち 160 以上を Cognito の JWT オーソライザーで保護し、CORS はマネージドで設定しています。
Amazon Cognito	パスワードとメール OTP によるサインイン方式でのユーザー認証を行い、API オーソライザーが使用する JWT トークンを発行します。ロールのクレームがフロントエンドのルートガードとバックエンドの RBAC を制御します。
Amazon CloudFront + Amazon S3	React シングルページアプリケーションのグローバル配信と、デプロイ時のキャッシュ無効化を行います。
Amazon EventBridge	すべてのスケジューリング。ライブメトリクス、クラスターの状態、SLA サンプル、SAP セキュリティ監査イベントの 5 分ごとの収集、パフォーマンス・ファイルシステム・クラウドメトリクスのトレンドの 1 時間ごとの収集、30 分ごとのセキュリティベースラインコンプライアンスのチェック、1 日 3 回の HANA バックアップカタログの収集、夜間のクリーンアップジョブ、さらにリリースワークフロー連携のためのイベントルーティングを担います。
AWS Security Token Service (AWS STS)	各スポークアカウント内の範囲を限定したロールへの、短期間（15 分のセッション）のクロスアカウント認証情報。プラットフォームが管理する操作において、ハブとスポークを結ぶ唯一の橋渡しです。
AWS Elastic Disaster Recovery	重要な SAP システムの継続的なレプリケーションと、人による承認ゲートを伴う切り替えステップを含む DR 訓練のオーケストレーションを行います。
AWS Backup / Amazon EBS	リスクの高い変更前の AMI 取得、サイズ変更前のスナップショットによる安全確保、ストライプ化したマルチボリュームの HANA レイアウト、リカバリポイントの衛生状態のレポートに使用します。
AWS CloudTrail	セキュリティ監査ツールのデータソース。不正アクセスの検知、権限昇格の監視、構成変更の追跡、通常と異なる API アクティビティの検出に使用します。
Amazon CloudWatch	Lambda のログ（チャットエージェントからクロスアカウントで検索可能）、メトリクス、S3 の休眠分析に使用するストレージサイズの時系列データを提供します。
AWS Cost Explorer / AWS Compute Optimizer	ライトサイジング、リザベーション、Savings Plans の推奨を、ファンアウト型のコレクターで 1 つのランク付けされた削減リストに集約します。
Amazon SES	OTP の配信、承認通知、実行されたアクションの監査証跡メールを送信します。

AI アシスタント: 制約されているからこそ役に立つ

AI アシスタントは、権限を持つエンジニア、プロダクトオーナー、サポートチームを支援するために設計されており、運用上の責任を置き換えるものではありません。Amazon Bedrock のツール使用を利用し、モデルはプラットフォームの 68 個の型付きツールのいずれかを要求できますが、アプリケーションがその要求を検証し、RBAC を確認し、承認ポリシーを適用したうえで、安全な場合にのみツールを実行します。この分離が重要です。モデルはタスクを推論する手助けはできますが、認可、検証、実行、監査の責任はプラットフォームが負い続けます。

ツールのカテゴリ

カテゴリ	代表的な機能
監視とステータス	システムの一覧、コンポーネントのヘルスを含むシステム/ホストの詳細、上位プロセス、ファイルシステムの使用量、バッチのステータス、パフォーマンストレンド、SLA の概要、メンテナンスウィンドウ、ランドスケープの朝のヘルスチェック。
診断と RCA	インベントリの情報、ホスト横断の並列ライブ SSM チェック、支援付きの根本原因分析を組み合わせた調査パイプライン。症状に応じた診断、SAP・HANA・OS・クラスターのログレビュー、HANA の容量分析。
ライフサイクル操作	SAP とデータベースのレイヤーを正しい順序で起動/停止、EC2 の制御、承認ゲート付きの SAP カーネルアップグレードワークフロー、hdblcm を使った HANA リビジョンのアップグレード、再起動オーケストレーションを伴う SAP を考慮した OS パッチ適用、メンテナンスのスケジューリング。
HANA の高度な操作	原因となったユーザーの特定を含むテーブル肥大化の RCA、デルタマージのステータス確認/強制実行、ガベージコレクションの滞留、DDL 生成と事前バックアップを伴うテーブルパーティショニング、テナント管理、トレース検索、レプリケーション（HSR）のセットアップ/ステータス/テイクオーバー。
ストレージ（LVM）ワークフロー	論理ボリュームの作成/拡張/縮小をフェーズ化したワークフローとして実行: AMI による安全バックアップ → SAP のグレースフル停止 → 並列データコピー（非常に大きな HANA データファイル向けのマルチプロセスのバイト範囲コピー）→ 旧ボリュームを即時ロールバック経路として保持したボリュームの入れ替え → 検証 → 起動。
クラスターと HA	1 回の呼び出しで全ノードにまたがるクラスター調査、制御されたフェイルオーバー/スイッチバック、制約のクリーンアップ、ログに十分なエビデンスがある場合は原因の特定を伴うフェイルオーバー履歴。
コストとセキュリティ	コストの概要、EC2 のライトサイジング、休眠検知を伴う単一バケットの詳細な S3 監査、CloudTrail によるセキュリティ監査、SAP ベースラインコンプライアンスの照会、セキュリティイベントの検索。
レポート	自己完結型のダウンロード可能な HTML ヘルスレポート（システムごと（ライブの SSM データ）またはランドスケープ全体）。

リクエストがエージェント内をどのように流れるか

インテントルーティング。 モデルがリクエストを受け取る前に、軽量なルーティングで利用可能なツールを最も関連性の高い候補に絞り込みます。これによりプロンプトの範囲が狭まり、誤ったツール選択が減ります。「はい」や「進めて」のような単純な確認は直前の保留中のアクションに紐付けられ、信頼度の高い入力（たとえば、エージェントが求めた後に指定されたカーネルメディアのパス）では、追加のモデル呼び出しの代わりに決定論的なファストパスを使用できます。

RBAC ゲート。 呼び出し元のロールは JWT のクレームから取得され、ツールに必要な権限と照合されます。閲覧者ロールは読み取り専用のままで、オペレーターおよび管理者ロールは制御されたアクションを要求できます。

承認ゲート。 環境に応じたポリシーにより、本番環境のアクション、マルチテナントのデータベースホスト、破壊的な操作は、実行されずに必ず保留中の承認が作成されます。ユーザーは何が実行されるかを正確に確認できます。カーネルアップグレードのような複雑なワークフローでは、ライブの事前チェックレポート（現行バージョンと目標バージョン、実行中のプロセス、メディアの検証）が、選択可能な確認/キャンセルボタンとともに表形式で提示された後にのみ承認が求められます。古い承認は自動的に失効します。

入力の検証。 システム ID はパターンで検証され、SSM コマンドは許可リストに登録された操作から組み立てられ、安全でないシェルのメタ文字は拒否されます。アシスタントが自由形式のシェルを受け取って実行することはありません。

実行と検証。 長時間の操作は、チャット内にライブの進捗カードを表示する非同期タスクとして実行されます。ワークフローはキャッシュされた状態を信頼するのではなく、ライブのプロセスチェックで結果を検証し、リスクの高いワークフローには、起動の検証に失敗した場合にバックアップしたカーネルを復元するといったロールバック経路が含まれています。

監査。 すべてのツール呼び出し、承認、結果は、ユーザー ID とともにアクションログに記録されます。これは Activity Log ページが表示するものと同じ証跡です。

ケーススタディ: AI アシスト型の SAP カーネルアップグレードワークフロー

代表的なワークフローの 1 つが、意図した運用モデルをよく示しています。エンジニアが主導権を保ち、アシスタントがチェックと承認済みの実行ステップを調整します。

エンジニアが、あるシステムのカーネルアップグレードを依頼します。アシスタントは、カーネルメディアの場所（ホストのパスまたは S3 のロケーション）を尋ねます。
エンジニアがパスを指定すると、決定論的なファストパスにより非同期の事前チェックが開始されます。現在のカーネルレベル、目標メディアの検証、パッチレベル混在の警告、各ホストで実行中のインスタンス、ディスク容量のチェックです。
アシスタントは、続行/キャンセルボタンとともに計画を表形式で提示します。この時点では何も変更されていません。
承認後、ワークフローはホストごとに実行されます: メディアのステージングと展開 → 現行カーネルのバックアップ → システムのインスタンスを想定どおりの順序で停止 → デプロイ → セントラルサービスから起動 → プロセスのヘルスとカーネルレベルを検証。起動の検証に失敗した場合、ワークフローはシステムを部分的にアップグレードされた状態のまま放置せず、バックアップを復元します。
旧パッチレベルから新パッチレベルへの変化やバックアップの場所を含む最終結果が、チャットに投稿され監査ログに記録されます。パイロット利用期間中、エンジニアの役割は手動の Runbook を実行することから、承認済みワークフローを監督することへと変わりました。2026 年 5 月に実施した 15 件以上のパイロットのカーネルアップグレードの観察に基づくと、システムあたりの推定所要時間は約 2.5 時間から 45 分に短縮され、約 70% 削減されました。エンジニアの実作業工数は個別には測定していません。

得られた教訓: AI ワークフローは他の自動化と共存しなければなりません。初期の社内テスト中、AI アシストによるアップグレードが成功してシステムが再起動した数分後に、停滞していたダッシュボードの停止トラッカーの自己修復リトライが発動し、競合する停止アクションが生じました。修正は表面的なものではなく体系的なものでした。システムごとのワークフローロック、リトライと承認の鮮度ウィンドウ、アクション後の再検証ウィンドウです。複数の自動化が同じランドスケープを共有する場合、リトライは状況が変わっていないと決して仮定してはならず、アクションの前に状態を再確認しなければなりません。

モデル戦略

階層化されたモデル: 単純なステータスの質問は低レイテンシーでコスト効率の高い Claude の階層に、調査、マルチステップのワークフロー、レポートの統合はより推論能力の高い階層に振り分けます。階層はセッション単位ではなくリクエスト単位で選択されます。
ツールループの上限設定: 1 リクエストあたりのツール使用ターンを最大 7 回に制限し、最終ターンでは強制的に回答をまとめることで、レイテンシーとコストを予測可能に保ちます。
結果のキャッシュ: 読み取り専用ツールの結果はツールごとの TTL でキャッシュされ、「refresh」と言えばキャッシュを回避できます。破壊的な操作や確認済みのアクションでは、キャッシュは決して使用されません。
組み込みのナレッジベース: SAP Basis の Runbook（起動/停止のシーケンス、OOM 分析、スプリットブレインからの復旧、EBS の拡張手順）を Lambda にパッケージ化し、アシスタントがワークフローを推奨または開始する前に低レイテンシーで検索できるようにしています。

セキュリティとガバナンス

ID。保護された API ルートでは JWT 検証を伴う Amazon Cognito を使用し、ユーザー ID は常にトークンのクレームから取得し、リクエストボディからは取得しません。
最小権限。スポークアカウントのロールは、プラットフォームが必要とする SSM と読み取りの権限のみを公開し、セッションは短期間です。
ホストを公開しない。プラットフォームが管理する操作では SSH はゼロで、すべてのホストとのやり取りは許可リストのコマンドセットを使った監査可能な SSM Run Command です。
変更管理。本番環境のアクションは常に人が承認します。エビデンスパックとリリースワークフロー連携により、変更を全社の ITSM および SAP Cloud ALM のプロセスに結び付けます。
監査とコンプライアンス。プラットフォームが管理するリソースは全社のタグ付け標準に従い、監査ログはコンプライアンスのトレーサビリティを支え、セキュリティモジュールはイベントを標準形式で全社の SIEM にエクスポートします。
リカバリ。リスクの高いワークフローでは、プラットフォームが対象の状態を変更する前に、安全確保のためのエビデンス（AMI、カーネルのバックアップ、スナップショット）を取得し、ロールバックの選択肢を確保します。

これらの制御を組み合わせることで、AWS のセキュリティのベストプラクティス、最小権限のスポークロール、短期間の STS セッション、Amazon Cognito によるトークンベースの ID が適用され、AI とデータのレイヤーが進化しても、トヨタは ID、認可、監査を決定論的に保つことができています。

「BasisPilot は、断片化したツールと手動の Runbook による SAP 運用を、インテリジェントで統制された 1 つの運用プラットフォームへと変革します。リアルタイムの可視化、AI アシストによる診断、制御された自動化を、エンタープライズ環境が求める承認、検証、監査可能性、ロールバックと組み合わせています。Manish のリーダーシップにより、SAP 運用の深い専門知識が、企業全体に拡張できる能力へと変わりました。」

Ashish Patel、Senior Manager、Toyota Motor North America

成果

アーキテクチャ、運用上のガードレール、人によるレビューのモデルを組み合わせることで、次のような実践的な成果が得られました。

1 つのプラットフォーム: BasisPilot は、SAP アプリケーション、データベース、AWS インフラの情報を、環境やアカウントをまたいで 1 つのインターフェースに集約することで、ターミナル、コンソール、スプレッドシートの間を行き来する必要を減らします。チームは、運用情報の収集と分析に費やす時間が少なくとも 20% 削減されたと見積もっています。これは、画面の切り替えが減ったことと、アシスタントがシステムのエビデンスをまとめ、エンジニアによる結果の解釈を助けることの両方を反映しています。このプラットフォームは、基盤となる SAP や AWS のサービスを置き換えるのではなく、これらのワークフローを統合するものです。
セルフサービスの拡大: 権限を持つチームはシステムのヘルス、アラート、トラブルシューティング情報を直接確認できるため、ステータス確認のために Basis チームに頼る必要が減ります。チームの報告によると、セルフサービスの可視化を導入した後、ステータス関連のチケットが推定 25% 減少しました。この数値はシステムステータスに関する問い合わせに適用されるもので、インシデントの総数やインシデントの解決時間を示すものではありません。
手作業の削減: BasisPilot は、日々のヘルスチェック、SAP プロセスとホスト負荷の分析、バックアップの確認、レポート作成から、ランドスケープの協調的な起動/停止、パッチ適用、アップグレード、ストレージ変更に至るまで、SAP 運用サイクル全体の作業を支援します。エンジニアはダッシュボードと範囲を限定した AI ツールを使って、エビデンスの収集、問題の調査、サポート対象のアクションの調整を行います。プラットフォームは、これらのワークフロー内で依存関係のシーケンス、必要な承認、進捗の追跡、検証、監査記録を処理します。コスト最適化、セキュリティとコンプライアンスのチェック、高可用性と災害対策のビューも、日常的な運用レビューに必要な情報を提供します。
パイロットでの見積もりは、この幅広い対象範囲のうち 2 つの部分を示しています。2026 年 5 月の 15 件以上のカーネルアップグレードの経験に基づくと、エンジニア 1 人・システム 1 つあたりの実作業工数は約 2.5 時間から 45 分に減少し、実作業工数が約 70% 削減されました。また別途、2026 年 3 月の 30 件以上のファイルシステム縮小の観察では、推定所要時間は以前の 3〜4 時間に対して約 1 時間となり、所要時間が約 67〜75% 短縮されました。
より安全な運用: サポート対象の操作は、ロールベースの権限、環境に応じた承認ポリシー、監査ログ、結果のライブ検証に従います。リスクの高いワークフローにはバックアップとリカバリのステップが含まれます。たとえばカーネルアップグレードのワークフローでは、起動の検証に失敗した場合に以前のカーネルを復元できます。これらの制御は、すべての変更が自動的に元に戻せると仮定するのではなく、実装されている箇所で明確なリカバリ経路を提供します。
サーバーレスの運用モデル: BasisPilot のプラットフォームレイヤーは、管理やパッチ適用が必要な専用のアプリケーションサーバーを持たず、マネージドな AWS サービス上で稼働します。コレクターと API は需要に応じてスケールします。2026 年 9 月 25 日時点で、チームの AWS インベントリレビューでは、プライマリのハブリージョンで BasisPilot に関連する 47 個の AWS Lambda 関数と 53 個の Amazon DynamoDB テーブルが確認されました。これらの数にはパイロットおよびレガシーのコンポーネントも含まれます。

まとめ

BasisPilot は、SAP プラットフォームの専門知識を、サーバーレスの AWS サービスと、厳格な認可・監査の制御を中心に構築された AI アシスタンスと組み合わせることで何が可能になるかを示しています。そのアーキテクチャパターン（STS と SSM によるハブアンドスポーク、フェーズベースの長時間ワークフロー、RBAC と承認ゲートの背後でのツール呼び出し、検証ファーストの自動化）は、AWS 上で大規模かつ規制の厳しいワークロードを運用する企業が応用できるものです。

はじめてみましょう

BasisPilot の背後にあるパターンは、お客様自身の SAP やエンタープライズの運用プラットフォームに導入できるマネージドな AWS サービスに基づいています。次のリソースは良い出発点になります。

Amazon Bedrock – バックエンドツールへの統制されたアクセスを備えた、ツール呼び出し型の AI アシスタントを構築できます。Amazon Bedrock のドキュメントを参照してください。
AWS Systems Manager – SSH を使わずに、EC2 ホスト上でエージェントレスかつ監査可能なコマンドを実行できます。
AWS Lambda と Amazon DynamoDB – 永続的な状態追跡を伴う、フェーズベースの自己チェックポイント型ワークフローを実装できます。
AWS STS によるクロスアカウントアクセス – 短期間で範囲を厳密に限定したロールを通じて、スポークアカウントのワークロードにアクセスできます。
SAP on AWS – AWS 上で SAP ワークロードを実行するためのリファレンスアーキテクチャと運用ガイダンスです。

これを組織で実践するには、まず運用上の判断、つまり依存関係、承認ゲート、検証ステップをプラットフォームの振る舞いとして書き起こし、そのうえで、統制されたワークフローへの範囲を限定したインターフェースとして AI アシスタントを追加することから始めてください。

著者:

	Manish Kumar は、Toyota Motor North America（トヨタ）の SAP BTP Platform チームの Senior SAP Product Owner です。SAP のソリューションアーキテクチャ、クラウド移行、システムアップグレード、エンタープライズのモダナイゼーションにわたる経験を持ちます。BasisPilot を構想し、その設計・アーキテクチャ・実装を主導し、SAP の専門知識と、AWS 上での AI アシストによる分析および統制された運用を結び付けました。プロダクトオーナーシップと実践的なエンジニアリングを組み合わせ、信頼性、セキュリティ、人による監督を重視しています。プラットフォームが作業を準備し、すべての変更はエンジニアが承認するという考え方です。SAP BTP ソリューションアーキテクチャ、TOGAF 9、AI ガバナンス（IAPP AIGP）の認定を保有し、IEEE Senior Member および IAPP Fellow of Information Privacy (FIP) でもあります。
	Anshuman Kowtha は Toyota Motor North America の Technical Manager で、同社の SAP および AWS クラウド環境全体のプラットフォーム戦略とデリバリーを率いています。エンタープライズテクノロジーで 23 年、エンタープライズ規模の SAP ランドスケープの統括で 15 年以上の経験を持ち、オンプレミスのインフラからハイパースケールクラウドへ、レガシー SAP から S/4HANA へといった大きなプラットフォームの転換を導き、移行・変革・継続的なモダナイゼーションの期間を通じてミッションクリティカルなシステムを構築・拡張してきました。実践的な技術基盤、徹底した運用の厳格さ、ガバナンスとセキュリティへの強いこだわりをもって、企業がクラウドと ID のプラットフォームを大規模に導入できるよう支援しています。
	Ashish Patel は Toyota Motor North America の SAP Technology 担当 Senior Manager で、トヨタでの 7 年以上を含む 24 年の SAP プラットフォームの経験を持ちます。SAP および ERP プラットフォーム、クラウドインフラ、システム統合を専門とし、テクノロジー戦略をビジネスの優先事項と整合させることに注力しています。プラットフォームの信頼性向上、運用効率の改善、デジタルトランスフォーメーションの支援に向けた取り組みを率いています。そのリーダーシップは、協働、継続的改善、そして複雑な技術課題を実践的なビジネスソリューションに変えるチームの育成を重視しています。複数の SAP Technology Associate および Specialist 認定に加え、AWS Certified Solutions Architect – Associate を保有しています。
	Neill Reidy は AWS の Principal Technical Account Manager で、企業がレジリエントで運用上優れたクラウド環境を構築できるよう支援しています。Linux とネットワークで 29 年の経験を持ちます。AWS re:Invent で登壇し、複数の AWS Professional 認定を保有し、AWS Systems Manager、Amazon Connect、AWS Unified Operations、災害対策に関する AWS ブログ記事やお客様事例を執筆しています。
	Vijay Sitaram は AWS の Principal Technical Account Manager です。データベースと SAP テクノロジーを中心に IT 分野で 26 年の経験を持ち、自動車・製造業のお客様の AWS 上の SAP ワークロードのサポートリーダーを務めています。レジリエンス、コスト、運用の卓越性に重点を置き、お客様が SAP ワークロードを運用・拡張できるよう支援しています。AWS for SAP のブログ記事を複数執筆し、バックアップ、レジリエンス、および SAP 運用向けの MCP を用いた AI 主導の kiro-cli に関する AWS ワークショップを作成しました。AIOPS for SAP MCP Server のオーナーであり、AWS re:Invent の登壇者でもあります。AWS Solutions Architect Professional と GenAI Professional の認定を保有しています。余暇には CrossFit、ウェイトリフティング、マウンテンバイク、原野でのバックパッキングを楽しんでいます。

本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。

AWS セキュリティハンズオン連続開催のご案内

Shota Umeda — Thu, 05 Nov 2026 00:00:47 +0000

2026 年 11 月 5 日: 11 月の全日程（6 回）を掲載しました。11 月 6 日の回は満席のため、同じ内容の回を 11 月 27 日に追加しました。

2026 年 10 月 30 日: 11 月 11 日の回を掲載しました。

2026 年 10 月 29 日: 初版を公開しました。

AWS Japan では、2026 年 11 月から、AWS のセキュリティサービスを実際に操作するオンラインハンズオンを週次で開催します。各回は座学とハンズオンの 2 部構成で、AWS Security Agent (now part of AWS Continuum)、AWS WAF、Amazon Inspector などを題材に、ご自身の組織で試すための最初の一歩までをお伝えします。業界を問わず、ユーザー企業・団体の方を対象としています。

本記事はその案内ページです。2026 年 11 月の開催日程（6 回）がすべて決まりました。12 月以降の日程も決まり次第この記事に追記していきますので、ブックマークしてご活用ください。

これまでの取り組み

AWS Japan パブリックセクター技術統括本部では、2026 年 4 月から、座学とハンズオンを組み合わせたセキュリティワークショップを月 1 回開催してきました。6 月からはフロンティア AI 時代の脅威対策をテーマにしており、7 月には本シリーズで使う AWS Security Agent のハンズオンも実施しています（開催報告: ランサムウェア対策（脅威検知・統合セキュリティ管理）／Claude Mythos 時代の脅威対策（脆弱性管理・AI エージェントによるセキュリティ評価）／耐障害性ライフサイクル／AI 時代の Web アプリケーション防御）。

10 月には「［臨時開催］FY2026 AWS セキュリティセミナー ― フロンティア AI 時代のサイバー攻撃に備える ―」を開催し、多くの方にご参加いただきました。10 月 30 日にも、同じ内容で第 2 回を開催しました。

これらのセミナーでお伝えしたのは「いま何をすべきか」です。次の一歩は、実際に手を動かして、自組織のアプリケーションで試せる状態になることです。

なぜ月 1 回から週次に広げるのか

AI の活用が進み、脆弱性を見つけて直す取り組みを、これまでより早く進められるようになっています。本シリーズは、その取り組みを実際に体験していただく場です。

10 月の臨時セミナーには想定を大きく上回るお申し込みをいただき、あわせて案内した 11 月の対面ハンズオンも、募集開始後すぐに満席となりました。そこで開催の頻度を増やし、より多くのお客様に手を動かして試していただけるよう、ハンズオンをオンラインで毎週繰り返し、日程の合う回にご参加いただける形にしました。

どんなことを体験できるか

各回とも、座学とハンズオンの 2 部構成です。座学で考え方を整理したうえで、ハンズオンでは AWS のセキュリティサービスを実際に操作していただきます。ハンズオンで使う環境は AWS 側で用意します。

現在、次のようなテーマを予定しています。各回のテーマは開催日程の表をご覧ください。

AWS Security Agent (now part of AWS Continuum): AI エージェントによるアプリケーションのセキュリティレビューとペネトレーションテスト
AWS WAF: 公開 Web アプリケーションの入り口での防御
Amazon Inspector: OS やミドルウェアの脆弱性管理
Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策: フロンティアモデルを使ってソースコードの脆弱性を見つけ、対策する方法
AI エージェントと進めるマイグレーション・モダナイゼーション: サポートが終了したランタイムやフレームワークで動くアプリケーションを、AI エージェントと一緒に新しい環境へ移行する方法

テーマは、お寄せいただくご要望に応じて追加・変更します。各回の詳しい内容は、決まり次第この記事と申込ページでお知らせします。

対象となる方

ソフトウェア開発者、DevSecOps エンジニア、セキュリティエンジニアの方
公開 Web アプリケーションや API を開発・運用している組織の方
前提知識: 最新のブラウザが使えること

本ハンズオンは、ご自身のシステムをお持ちのユーザー企業・団体の方を対象としています。パートナー企業の方は、担当の AWS パートナー部門へご相談ください。

開催日程

同じテーマを複数回開催します。ご都合の合う回にお申し込みください。いずれもオンライン開催です。日程が決まり次第、この表に行を追加します。終了した回は一覧から下げていきます。

日時	テーマ	申込
2026 年 11 月 6 日（金）14:30 – 17:30	AWS Security Agent (now part of AWS Continuum) ハンズオン ※ 満席のため、同じ内容の回を 11 月 27 日に追加しました	満席
2026 年 11 月 11 日（水）15:00 – 17:00	Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策ハンズオン	申込ページ
2026 年 11 月 18 日（水）14:30 – 17:30	AI エージェントと進めるマイグレーション・モダナイゼーションハンズオン	申込ページ
2026 年 11 月 20 日（金）14:30 – 17:30	AWS WAF ハンズオン	申込ページ
2026 年 11 月 25 日（水）14:30 – 17:30	Amazon Inspector ハンズオン	申込ページ
2026 年 11 月 27 日（金）14:30 – 17:30	AWS Security Agent (now part of AWS Continuum) ハンズオン（11 月 6 日の回と同じ内容）	申込ページ
2026 年 12 月（日程調整中）	AWS WAF AWS Security Agent Amazon Inspector Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策	準備中

お申し込みについて

申込ページからお申し込みいただくと、参加用の URL がメールで届きます
申込には AWS のイベントサイト（Connected Community）への会員登録（無料）が必要です。勤務先のメールアドレスでご登録ください
定員を超えた場合はキャンセル待ちとなります。枠が空くと自動的に繰り上がり、確認メールが届きます
各回の定員は、当日のサポート体制に合わせて設定しています

ハンズオンの先にあるもの

このハンズオンのゴールは、体験した内容をご自身の組織のシステムで実際に試せる状態になることです。

そのために、各回の最後には、ご自身の環境で始めるときの最初の一歩をご案内します。たとえば、どのシステムから始めるか、まず何を有効にして何を確認するか、といった点です。ハンズオン後に具体的なご相談がある場合は、担当の AWS アカウントチームまでお問い合わせください。

著者

梅田昌太 (Shota Umeda)
アマゾンウェブサービスジャパン合同会社パブリックセクター技術統括本部シニアソリューションアーキテクト
パブリックセクターのお客様の技術支援を担当。2026 年 4 月から、本記事で紹介したセキュリティワークショップシリーズと 10 月の臨時セミナーの企画・運営に携わっています。

AWS Weekly Roundup: GPT-6.1 Terra on Bedrock、エージェントツールとしての Step Functions など (2026 年 11 月 2 日)

Daniel Abib — Wed, 04 Nov 2026 09:25:26 +0000

2026 年 10 月 26 日週、特に印象に残ったエージェント関連の発表は、モデルの性能そのものとはまったく関係ありませんでした。重要なのは、そのリーチについてです。220 を超える AWS サービスを既にオーケストレートしている AWS Step Functions を、エージェントがツールとして利用できるようになりました。これにより、チームが既に信頼しているワークフローを、書き換えることなく呼び出せるようになりました。同じ週に、AI ブログでは、あるエンゲージメントプラットフォームが約 400 の内部 API オペレーションを同じ方法で公開した事例が紹介されました。いずれの事例でも既存のものを再構築する必要はなく、必要なのは、既存のものを記述してエージェントがそれを見つけられるようにすることだけです。

もう 1 つの重要なポイントはコストです。OpenAI の最新の Terra モデルが、他のモデルよりも大幅に下回る料金で Amazon Bedrock に登場しました。また、ポスト量子について、まだ誰も具体的な対応期限を設定できない中で、ポスト量子に関する 2 つのリリースがありました。それでは、今週の AWS ニュースを詳しく見ていきましょう。

主なトピック
OpenAI GPT-6.1 Terra の一般提供が Amazon Bedrock で開始され、私はその性能の高さではなく、むしろその位置付けに注目しています。Terra は、GPT-6 ファミリーの中で日常的なワークロードに対応するモデルです。OpenAI の「Agents’ Last Exam」評価では、GPT-5.6 Terra よりも 15 パーセントポイント高いスコアを記録し、GPT-6 Astra と同等の性能を発揮したほか、両者と比較して 3 倍を超える速度でタスクが処理されました。これらは OpenAI による数値であり、独立したテスト結果ではありません。まず確認すべきは料金です: 入力トークンと出力トークンは、GPT-6.1 Sol と GPT-5.6 Terra よりも少なくとも 50% 低くなっています。テキストと画像入力に対応し、最大 100 万トークンまで入力可能です。Bedrock API または ChatGPT Work および Codex からアクセスできます。

Amazon Bedrock AgentCore Gateway を通じて、AWS Step Functions ワークフローが AI エージェントツールとして利用できるようになりました。Amazon Bedrock AgentCore Gateway は、モデルコンテキストプロトコル (MCP) を介してエージェントとツールを接続します。ここでは役割分担が重要です: エージェントはワークフローを実行するタイミングと渡す入力を決定します。Step Functions は、定義された各ステップを正確に実行します。サポートエージェントが返金をトリガーした場合でも、適格性の確認、マネージャーの承認、およびクレジット処理は毎回同じ順序で行われます。なぜなら、処理順序をモデルが勝手に決定するわけではないからです。既存の Standard および Express ワークフローはコネクタのターゲットとして適格であり、エージェントは実行を検索することもできます。AgentCore Gateway が利用可能なすべてのリージョンで、標準料金でご利用いただけます。

10 月 26 日週のリリース
10 月 26 日週のリリースのうち、私が注目したものをいくつかご紹介します。

AWS Key Management Service がポスト量子キーカプセル化のための ML-KEM のサポートを開始 – AWS KMS キーと、FIPS 140-3 Level 3 検証済みの HSM に格納されたプライベートキーを使用して、ポスト量子アルゴリズムによる共有シークレットを確立できるようになりました。NIST FIPS 203 の 3 つのパラメータセットすべてが、ランダムな 32 バイトの共有シークレットとその暗号文を生成する Encapsulate メソッド、およびそれを復元する Decapsulate メソッドを通じてサポートされています。脅威は Harvest Now, Decrypt Later です: 攻撃者は今日のキー交換を記録し、量子コンピュータの性能が十分に向上した時点でシークレットを復元します。これは、中東 (UAE とバーレーン) および中国リージョンを除く、KMS が稼働しているすべてのリージョンで利用可能です。Amazon Aurora PostgreSQL は、同じ週にバージョン 18 以降でポスト量子 TLS キー交換を追加しました。

AWS IAM アイデンティティセンターがリージョン間の信頼済み ID 伝播のサポートを開始 – お客様は、ユーザーの ID を、リクエストとともに、別のリージョンの AWS サービスに渡すことができるようになりました。これにより、アーキテクチャ上の大きな制約が解消されます: 従来、信頼済み ID 伝播では、その ID にアクセスするすべてのサービスが同じリージョンに存在する必要がありました。そのため、個々のユーザーを区別できない広範な IAM ロールを使用するか、すべてのサービスを単一のリージョンに統合するという、2 つの好ましくない選択肢しか残されていませんでした。今後は、ID がリクエストとともに自動的に渡されるため、ユーザーとグループのメンバーシップに基づいてアクセスを付与し、誰が何にアクセスしたかを監査できます。この機能は、IAM アイデンティティセンターが稼働しているすべての場所で、追加コストなしで利用できます。

Amazon ECS が NVIDIA Multi-Process Service (MPS) との GPU 共有のサポートを開始 – 単一の NVIDIA GPU 上で複数の Amazon ECS タスクを同時に実行できるようになりました。これは、小規模モデル推論やマルチモデルサービングなど、単一の GPU の一部しか使用しない作業における実用的なソリューションです。各コンテナが必要とする GPU メモリを宣言し、必要に応じて GPU コンピューティングの割り当てを制限できます。ECS は、サービスがスケールする中で、コードの変更なしに、利用可能なキャパシティを持つ GPU にタスクを配置します。ECS Managed Instances と ECS on Amazon EC2 で動作し、Managed Instances では MPS コントロールデーモンを監視し、異常が発生した場合はインスタンスを置き換えます。すべての商用リージョンと AWS GovCloud (米国) リージョンで利用可能です。

AWS Lambda が Lambda Managed Instances 向けに Seekable OCI (SOCI) の遅延ローディングをサポート – AWS Lambda は、コンテナイメージ全体を最初にプルするのではなく、起動の各段階で必要なファイルのみを取得できるようになりました。これにより、AWS は、コンテナの起動時間を最大 70% 短縮できます。SOCI インデックスを作成し、Amazon ECR にプッシュして、イメージ URI をインデックス付きタグにポイントすると、Lambda が自動的にそれを検出します。この手法は Amazon SageMaker AI のトレーニングおよび処理ジョブにも適用され、ベンチマークでは、画像サイズにかかわらず、遅延ローディングが 3～11 秒に抑えられました。これは、13.2 GB の画像の場合の中央値である 3 分 42 秒と比較して、8～46 倍の高速化となります。

Amazon EKS Auto Mode が Kubernetes Gateway API のサポートを開始 – Amazon EKS 上で Gateway および HTTPRoute リソースを使用して、別途コントローラーをインストールすることなく、アプリケーションへのトラフィックの到達方法を宣言できるようになりました。また、EKS Auto Mode は、基盤となる AWS ロードバランシングインフラストラクチャをプロビジョニングおよび管理します。HTTP および gRPC ルーティング、クロス名前空間ルーティング、重み付けトラフィック分割、ヘッダーベースルーティング、AWS Certificate Manager を通じた TLS 証明書の自動検出が利用できます。既存の Ingress ワークロードは引き続き並行して動作するため、これは移行ではなく、追加的なものです。Gateway API のサポートは EKS Auto Mode に含まれています。標準のロードバランシング料金が適用されます。

AWS のお知らせに関する詳しいリストについては、「AWS の最新情報」ページをご覧ください。

AWS のその他のニュース
皆さんが興味を持つと思われるその他の記事とリソースをいくつかご紹介します。

Nubank が AWS DevOps エージェントでディザスタリカバリを自動化した方法 – Nubank は、ブラジル、メキシコ、コロンビアで 1 億 4,000 万人を超える顧客にサービスを提供しており、300 を超えるビジネスフローを重要業務として分類し、それぞれ規制当局のスケジュールに基づいてテストを実施しています。Nubank は、証拠収集とレポート作成を AWS DevOps エージェントに任せることで、テストサイクルを約 4.3 時間から約 40 分に短縮し、2026 年にはフローカバレッジを 160 超 (4 倍) に拡大したと報告しています。ある実行では、AWS Fault Injection Service を使用して合成トラフィック下で 900 を超える EKS インスタンスを終了し、規制当局が必要とする証拠を生成しました。

MoEngage が AgentCore Gateway を使用して 400 を超える API をエージェントツールに変換した方法 – 約 400 の内部 REST API オペレーションは、25 のチームによって構築され、7 つのリージョンにまたがるプライベート VPC に配置されていました。テナント ID を、モデルが設定できるパラメータにすることは決して許されませんでした。MoEngage は、このマネージドパスによって、プラットフォームエンジニアリングについて、約 6 か月間に相当する時間を節約できたと推定しています。注目すべき点は、ツールリスト全体を表示したとすれば、接続ごとに 20,000 トークンを超えることになったであろうことから、エージェントは、カタログを受け取るのではなく、タスクの説明に基づいてツールを検索するようにしたことです。

エビデンスベースのライフサイクルルールを使用して、ペタバイト規模の S3 ストレージコストを削減 – 難しいのは、行動を起こすことを決めることではなく、どのデータがコールドデータになっているのか、そして、それらをどこに安全に保存できるのかを把握することです。これは、S3 ストレージレンズグループとストレージクラス分析を使用して、データを移動する前にアクセスパターンを検証します。ご紹介したエンゲージメントでは、Amazon S3 Standard に 5.8 PB のログを保存し、約 241,000 USD/月を費やしたところ、直近 90 日間のアクセス率は 0.1% 未満でした。そこで、Glacier Instant Retrieval に 90 日間移行したところ、コストを約 70% 削減することができました。著者は、この削減率が当該ワークロードに固有のものであると説明しています。

今後開催される AWS イベント
カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。

AWS re:Invent – re:Invent は 11 月 30 日から 12 月 4 日までラスベガスに戻り、2,200 を超えるセッションを開催します。イベントカタログが公開され、予約席も受付中です。ぜひ登録して、満席になる前に席を確保してください。

AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンスです。re:Invent の開催が近づいており、2026 年のシーズンも終盤を迎えています。今後のイベントについては、ハブをご確認ください。

AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。

11 月 2 日週のニュースは以上です。11 月 9 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください!

– Daniel Abib

この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します!

原文はこちらです。

Amazon Web Services ブログ

Kiro の Auto がモデルカスケードで作業に合ったモデルを使い分ける仕組み

難しさはセッションが進むにつれて見えてくる

Auto のモデルカスケードのしくみ

測定したこと

高性能なモデル単独とほぼ同じ品質

約 5 件に 4 件は引き継ぎなしで完了

ベンチマークの数値についての注意

試してみる

原文の著者

翻訳者について

AWS Managed Services（AMS）で AWS クラウドインフラのセキュリティを強化する

はじめに

AWS におけるクラウドセキュリティ管理

予防（Prevention）

検出（Detection）

モニタリングとインシデント対応（Monitoring and Incident Response）

コンプライアンス（Compliance）

レポートとガバナンス（Reporting & Governance）

セキュリティオンデマンド（Security On-Demand）

おわりに

【寄稿】両備システムズが挑む、地方自治体ガバメントクラウドのコスト最適化 ～共同利用（ネットワーク分離方式）で長期継続割引を使いこなし、クラウド利用料を削減～

はじめに

コスト最適化の取組みの経緯

長期継続割引適用に向けた課題と解決方策

ネットワーク分離方式ならではの課題

長期継続割引適用に向けた戦略と実行

STEP0：コミット前の最適化

STEP1：購入量（ベースライン）の決定

STEP2：長期継続割引の購入オプションの選択

STEP3：年に一度の購入オペレーション

STEP4：購入後のモニタリングと是正

取組みの効果

持続可能なFinOpsの推進に向けて

著者について

Kiro Crew の Bot のご紹介

判断の理由を作業と一緒に残す

開発の進め方に合わせてクルーを組む

Bot ごとに専門に合わせて調整する

セッションの管理から Bot の管理へ

Kiro の Bot を使ってみる

原文の著者

翻訳者について

【自動車業界】車載ソフト開発をクラウドネイティブに ─ dSPACE × AWS で加速する次世代クルマづくり（dSPACE Japan User Conference 2026 で発表）

はじめに

自動車ソフトウェア開発の 2 つのチャレンジ

Virtual Engineering はすでに AWS 上で稼働している

クラウドに載ると、工程と記録も自動化できる

生成 AI でさらに効率化する

ツール操作と設計書の自動化

AI 駆動テストオートメーション（会場デモ）

おわりに

著者

クレジットプーリングで Kiro のクレジットをチーム全体で共有する

AI 利用料が予算の課題になっている理由

クレジットプーリングとは

仕組みと中核となるメカニズム

共有クレジットによる実際のコスト削減

AI 利用をきめ細かく統制する

3 段階の利用上限の階層

スマートなしきい値通知

プールメンバーの管理

可視性、柔軟性、予測可能性を高めて計画を立てやすくする

リアルタイムのモニタリングダッシュボード

より良い計画の立案

クレジットプーリングを始める

Amazon S3 Tables で Apache Hive テーブルから Apache Iceberg へのマネージドな移行が可能に

著者について

トヨタはいかにして BasisPilot を構築したか – AWS 上の AI アシスト型 SAP 運用プラットフォーム

はじめに

社内発のイノベーション

実装を加速するための Kiro の活用

本記事の内容について

ミッションと目標

プラットフォームの機能

コアプラットフォームチームを超えた共有の可視化

メリットを受けるのは誰か

継続的な監視と SLA トラッキング

メンテナンスウィンドウ

難しい問題: SAP の時間は HTTP の時間に収まらない

【寄稿】両備システムズが挑む、地方自治体ガバメントクラウドのコスト最適化～共同利用（ネットワーク分離方式）で長期継続割引を使いこなし、クラウド利用料を削減～