はじめに 業界調査（2024〜2026年） によると、SAP のネットワーク障害は企業に平均で1時間あたり10万ドルのコストをもたらすと推定されています。それにもかかわらず、従来のトラブルシューティングでは依然として複数のツールをまたいで2〜4時間の手作業が必要です。 Kiro-CLI と AWS Model Context Protocol (MCP) Servers（Agent Toolkit の一部） は、この状況を変えます。このエージェント型 AI アプローチにより、数十個の CLI コマンドを暗記する代わりに自然言語を使って、複雑な SAP ランドスケープ全体のネットワーク接続性の問題を数分で診断・解決できます。 今日、SAP のネットワーク運用チームの作業を遅らせている課題は3つあります。 複雑なネットワーク診断：複数の AWS サービスに関する深い知識が求められ、インシデント対応に何時間も上乗せされます。 時間のかかる接続性分析：VPC Flow Logs、ルートテーブル、セキュリティグループを手作業で突き合わせると、私たちの経験ではインシデントあたり運用チームに2〜4時間かかることがあります。 断片化したネットワークヘルス監視：複数のネットワーク境界が存在する RISE with SAP のデプロイメントで顕著です。 本記事では、以下の方法を学びます。 MCP Server と Kiro-CLI を組み合わせて SAP のネットワークトラブルシューティングを簡素化する。 自然言語コマンドで自動ネットワークヘルスチェックを実行する。 複雑な CLI 構文を平易な英語のクエリに置き換えて診断を効率化する。 実例を用いて、よくある5つの SAP ネットワーク問題を解決する。 接続が AWS アカウント境界をまたぐ RISE with SAP 環境を監視する。 次の図は、RISE with SAP on AWS のデプロイメントにおける MCP Server と Kiro-CLI のユースケースシナリオを示しています。 図1. RISE with SAP 環境における MCP Server と Kiro-CLI の連携を示すアーキテクチャ図 Kiro-CLI とは？ Kiro-CLI は、AI 支援によるトラブルシューティングをコマンドラインのワークフローに直接もたらします。複雑な VPC Flow Log のクエリ構文を暗記する代わりに、「SAP アプリケーションサーバーで拒否されたすべてのネットワークトラフィックを見せて」といった質問をするだけで、Kiro がそのリクエストを正しい CLI コマンドに変換して実行します。 SAP 管理者やネットワークエンジニアにとって、この変換こそが中核機能です。Kiro-CLI は会話形式のリクエストを、VPC・サブネット・セキュリティグループの構成にまたがる正確なネットワークコマンドに変換します。単一のコマンドにとどまらず、関連するコマンドも提案するため、ドキュメントを探すことなく包括的なネットワーク分析を実行できます。また、何らかの障害が発生した場合には、複雑なネットワーク問題に対するステップバイステップの修復ガイダンスを返します。さらに、構成変更を適用する前にその影響を説明してくれるため、少数の専門家に依存するのではなく、チーム全体が時間をかけてネットワークの専門知識を蓄積できます。 SAP ネットワーク診断のための MCP Servers マネージドな AWS MCP Server が、本ブログで使用するネットワーク機能を提供します。これは、すべての AWS API アクセスを単一のエンドポイントに集約し、AWS CloudTrail による監査を組み込んでいます。次の表は、各サーバーを適用可能なユースケースに対応付けたものです。 Kiro-CLI と MCP Servers の連携 Kiro-CLI は自然言語インターフェイスであり、MCP Servers は AWS 環境に手を伸ばす「手」です。リクエストを入力すると、Kiro-CLI が意図を解釈し、適切な MCP Server のツールを選択し、サーバーがユーザーに代わって基盤の AWS API を呼び出します。結果は平易な英語で読むことができ、Kiro-CLI がコンテキストを保持するため、同じセッション内でフォローアップの質問ができます。セットアップは30〜60分の一度きりの作業で、その後はすべての診断がひとつのプロンプトで完了します。 大まかには、2つを連携させるには3つのステップがあります。コマンドラインツールをインストールし、使用する MCP Servers を登録し、環境に到達できることを確認します。まず、macOS・Linux・Windows それぞれのプラットフォーム手順に従って Kiro-CLI をインストール します。次に、Kiro-CLI の構成ファイルに MCP Servers を登録し、単一のマネージド AWS MCP Server を構成します。最後に、「list my VPCs」のようなシンプルな読み取り専用プロンプトを実行し、本格的な診断を試みる前に Kiro-CLI が認証してアカウントに到達できることを確認します。 その効果は、CLI の複雑さから平易な英語への移行です。次の比較は、ネットワークエンジニアが通常入力する手作業のアプローチと、それに相当する Kiro-CLI のリクエストを示しています。 従来の CLI（「ビフォー」） Kiro-CLI（「アフター」） aws ec2 describe-flow-logs –filter … の後に aws logs start-query –log-group-name … –query-string ‘fields … | filter action=”REJECT” …’、続いて get-query-results をポーリングし、describe-security-groups の出力を手作業で相互参照する 「過去12時間で SAP アプリケーションサーバーに対して拒否されたすべてのネットワークトラフィックを見せて。どのセキュリティグループルールがブロックしているかも教えて。」 正確なフラグ構文、ロググループ名、CloudWatch Logs Insights のクエリ言語を思い出し、3〜4個のコマンドにまたがって手作業で相関を取る必要があります。 一文で済みます。Kiro-CLI が適切な MCP Server ツールを選択し、クエリを実行し、相関の取れた回答を返します。 このメンタルモデルを踏まえ、次のセクションでは初回実行の前に必要なものを正確に列挙します。 前提条件 初回実行の前に、おおよそ30〜60分を確保し、AWS ネットワーキングと SAP Basis 管理に関する中級レベルの知識があることを確認してください。作業はインフラストラクチャ、監視、ツール、IAM 権限、セキュリティの5領域に分かれます。以下のチェックリストは飛行前点検のように扱ってください。ほとんどの SAP ランドスケープはインフラと監視の項目をすでに満たしているため、実際のセットアップ時間は Kiro-CLI のインストールと MCP Servers の登録に費やされます。 インフラストラクチャ： AWS Launch Wizard for SAP を使用して高可用性構成でデプロイした SAP S/4HANA。該当する場合は Amazon VPC ネットワーキング と AWS Transit Gateway を構成します。 VPC Flow Logs を有効化します。 監視： VPC Flow Log ストリームを受け取るように構成した ロググループ付きの Amazon CloudWatch を有効化します。別途、 Transit Gateway flow logs を有効化します。 ツール ： Kiro-CLI をインストール します。その後、 AWS MCP Server を構成します。 IAM 権限 ：CloudWatch ネットワーク監視、VPC Flow Log アクセス、Transit Gateway 監視、AWS Systems Manager の実行。最小権限アクセスを適用します。 セキュリティ： ネットワーク構成変更のために AWS CloudTrail を有効化し、ネットワークトラフィックの暗号化を実装し、Kiro-CLI のセキュリティベストプラクティスを確認します。 ユースケース1：SAP ネットワークヘルスチェック SAP 環境が複数の VPC とアベイラビリティーゾーンにまたがると、手作業のネットワーク検証は大きなボトルネックになります。構成の不備があるコンポーネントは可視性のギャップを生み、チームは1つずつヘルスを検証するのに何時間も浪費させられます。単一の自然言語プロンプトで、すべてのコンポーネントにわたる包括的なヘルスレポートを同時に生成できます。 サンプルプロンプト Perform a comprehensive network health check for our SAP S/4HANA 2023 system. Analyze VPC Flow Logs, security group configurations, and network performance metrics. Generate a complete health report including executive summary, performance metrics, and security analysis. 出力（要約） === SAP S/4HANA 2023 Network Health Report === Network Uptime: 100% (last 24 hours) Accepted Connections: 225,301 | Rejected: 4,676 (blocked by SG rules) Overall Health Score: 96.6 / 100 Avg Latency (app-to-DB): 1.2 ms | Peak Bandwidth: 68% | Packet Loss: 0.00% SAP App Server <-> DB Layer: HEALTHY RISE with SAP endpoints: REACHABLE | Transit Gateway attachments: ACTIVE Scorecard: Connectivity 98 | Security 96 | Performance 95 | Redundancy 98 Forecast: No capacity constraints projected for next 30 days 要点 単一コマンドでの可視化： ひとつのプロンプトで、エグゼクティブ向けヘルススコアカード、セキュリティ体制の分析、30日間のキャパシティ予測を生成します。これは以前は複数のツールと手作業の相関付けを必要とした作業です。 セキュリティ検証を標準装備： セキュリティグループ違反がゼロであること、そして拒否された4,676件の接続試行を確実にブロックしていることが、即座の監査証跡になります。 プロアクティブなキャパシティ洞察： 30日間の予測により、運用チームは飽和イベントに反応するのではなく、事前に計画を立てる時間を得られます。 図2. ネットワークヘルスチェックの出力 — マルチ AZ の SAP インフラストラクチャ状態（スコア：96.6/100） ユースケース2：RISE with SAP — 504 Gateway Timeout RISE with SAP 環境の Application Load Balancer (ALB) で発生する 504 Gateway Timeout を解決するには、ネットワーク・セキュリティ・アプリケーションのいずれの障害かを迅速に切り分ける必要があります。分離された複数のコンソールをまたぐ手作業の検証は、クリティカルな SAP 環境には遅すぎます。Kiro-CLI はこの多層検査を自動化し、何時間もかかる診断の探索を単一コマンドの実行に変え、根本原因を数秒で提示します。 サンプルプロンプト Troubleshoot the 504 Gateway Timeout error on our RISE with SAP system. The ALB health checks are failing. Analyze network connectivity, security group configurations, and application health on port 44300. 出力（要約） === RISE with SAP Connectivity Troubleshooting Report === Step 1: Target 10.0.1.45:44300 - Status: UNHEALTHY Reason: sg-0a1b2c3d blocking ALB health check source on /sap/public/ping Step 2: SAP ICM service: RUNNING | Port 44300 from within VPC: YES Step 3: VPC routing: CORRECT | TGW attachment: ACTIVE | NACLs: No blocks Root Cause: sg-0a1b2c3d missing inbound rule from ALB SG (sg-alb-9x8y7z) on 44300 Fix: Add inbound rule - Source: sg-alb-9x8y7z | Port: 44300 | Protocol: TCP Resolution: ALB health check -> HEALTHY | 504 errors resolved 要点 構造化された3ステップ診断： Kiro-CLI は、正確な根本原因を特定する前に、ALB ターゲットのヘルス、アプリケーションのヘルス、ネットワークインフラストラクチャという各潜在原因を体系的に排除します。 アプリケーションとネットワークの切り分け： 出力は SAP ICM サービスが正常であり、ポート 44300 が VPC 内から到達可能であることを確認し、問題がアプリケーションではなく単一のセキュリティグループルールにあることを特定します。 図3. 504 Gateway Timeout — SAP ICM プロセスの根本原因調査と解決 ユースケース3：クロス AZ レイテンシー診断 クロス AZ レイテンシーは、MRP や期末決算といったクリティカルな SAP バッチジョブを運用上のボトルネックに変えてしまいます。本記事の例のシナリオでは、バッチサーバーの配置ミスによってパフォーマンスが約10倍低下しています。これを解決するのに、Amazon CloudWatch メトリクスや配置データをめぐってチーム間で何時間も責任を押し付け合う必要はありません。レイテンシーがサプライチェーンや財務決算を遅延させるのを止めるには、即座の可視性が必要です。 サンプルプロンプト Analyze cross-AZ network latency for our SAP S/4HANA system. Identify which application servers are communicating cross-AZ to the HANA database. Compare measured latency against SAP recommended thresholds and recommend optimizations for performance-critical batch jobs. 出力（要約） コンポーネント AZ レイテンシー（24時間平均） SAP しきい値ステータス HANA Primary DB us-east-1a — — App Server 1 us-east-1a（同一 AZ） 0.18 ms ✓ GOOD (<0.3 ms) App Server 2 us-east-1b（クロス AZ） 0.92 ms ✗ BELOW AVG (>0.7 ms) App Server 3 us-east-1c（クロス AZ） 0.85 ms ✗ BELOW AVG (>0.7 ms) 根本原因：App Server 2（u-6tb1.metal）の C-state 構成がデフォルトのままであり、レイテンシーを 0.7 ms から 0.92 ms に押し上げています。この例では processor.max_cstate=1 を設定することでレイテンシーが約 0.15 ms に低減しました。バッチサーバーグループ ZBATCH には現在 App Server 2 と 3 が含まれており、ここで測定した MRP およびバックフラッシュのジョブで RFC 実行が4〜8倍遅くなっていました。 要点 即座の根本原因特定： 大型のメタルインスタンスにおける C-state のチューニングは、このシナリオで最も効果の大きい単一の修正でした。インフラストラクチャを変更することなくレイテンシーを約5倍低減しました。 インフラ変更不要の修正が利用可能： バッチサーバーグループ ZBATCH を同一 AZ の App Server 1 に再割り当てするには SAP の構成更新だけで済み、バッチジョブのパフォーマンスを即座に改善できます。 SAP しきい値によるベンチマーク： SAP Note 1100926 のしきい値（≤0.7 ms）に照らして測定することで、生のレイテンシー数値を実行可能な合否基準に変換します。 図4. クロス AZ レイテンシー — アプリケーションサーバーから HANA へ、パフォーマンス最適化の推奨事項付き ユースケース4：セキュリティグループのドリフト検出 1つのセキュリティグループの削除が、SAP ランドスケープ全体を静かに麻痺させることがあります。こうした変更は明確なエラーメッセージをほとんど発生させないため、チームは壊れた箇所を見つけるためだけに、複数の AWS サービスをあてもなく探し回って貴重な時間を浪費します。 サンプルプロンプト Our SAP application servers lost RFC connectivity to the central instance after last night's maintenance window. Analyze VPC Flow Logs for rejected traffic on SAP ports, identify which security group changes caused the issue, and recommend the fix. 出力（要約） === SAP Security Group Drift Analysis === Rejected Traffic (last 12 hours): Port 3200 (SAP Dispatcher): 12,847 packets | Source: 10.0.2.0/24 Port 3300 (SAP Gateway): 3,221 packets | First rejection: 02:14:00 UTC CloudTrail Attribution: Change: 2024-09-15 02:12:33 UTC | SG: sg-0abc1234 (sap-central-instance-sg) Action: RevokeSecurityGroupIngress User: arn:aws:iam::123456789012:user/network-admin Removed: TCP 3200-3399 inbound from 10.0.2.0/24 Root Cause: Cleanup script mistook SAP dispatcher/gateway rule for legacy rule Fix: Add inbound rule - Ports 3200-3399 | Source: 10.0.2.0/24 | Protocol: TCP Security Validation: Internal subnet only ✓ | No internet exposure ✓ 要点 数秒での確定的な原因特定： 拒否されたトラフィックのタイムスタンプを CloudTrail イベントと相関させることで、正確なユーザー、正確なタイムスタンプ、削除された正確なルールを特定でき、何時間もの当て推量を排除します。 安全な修復： 推奨される修正は適用前にセキュリティのベストプラクティスに照らして検証されるため、過度に緩いルールが導入されることはありません。 プロアクティブな保守体制： メンテナンスウィンドウのたびにこのクエリを実行すれば、ユーザーが障害を報告する前にドリフトを検出でき、リアクティブな対応をプロアクティブなガバナンスに変えられます。 図5. RFC 接続障害 — セキュリティグループのドリフト診断フローと根本原因分析 ユースケース5：ネットワークキャパシティ予測 SAP のネットワーク飽和は一夜にして起こるものではありません。オーガニックなビジネス成長がユーザーアクティビティを押し上げ、より負荷の高いデータベースクエリがパイプラインに重い負担をかけるにつれて、静かに蓄積されていきます。これらの複合要因が障害を引き起こすまで待つことは、ネットワーク管理を完全にリアクティブなものにします。60日分の過去スループットを分析し、実際の成長率をインスタンスの上限に対して予測することで、この流れを逆転できます。運用に支障をきたす30〜60日前に、正確なネットワーク制約を特定できます。 サンプルプロンプト Analyze network capacity trends for our SAP production VPC over the last 60 days. Identify any components approaching capacity limits and forecast when we will need to scale. Focus on instance bandwidth, Transit Gateway throughput, and NAT Gateway utilization. 出力（要約） コンポーネント 現在のピーク 上限 使用率 予測される超過 HANA DB (x2idn.32xlarge) 42 Gbps 50 Gbps 84% 38日 — 対応が必要 App Server 1 (r6i.8xlarge) 8.1 Gbps 12.5 Gbps 65% ✓ 11か月 — 対応不要 Transit Gateway (SAP Prod) 38 Gbps 50 Gbps 76% 57日 — 45日以内に計画 NAT Gateway 32 Gbps 100 Gbps 32% ✓ 12か月以上 — 対応不要 コストを考慮した推奨事項： [緊急 — 30日] HANA DB を x2idn.metal（100 Gbps）に移行するか、トラフィック最適化を適用する（構成のみの場合は月額0ドルに対し +2,340ドル/月）。 [計画 — 45日] 負荷分散のために2つ目の TGW アタッチメントを追加する。 [監視] すべてのコンポーネントに対して使用率80%のしきい値で CloudWatch アラームを設定する。 要点 プロアクティブな検出： HANA DB の帯域幅超過に対する38日前の事前警告により、緊急対応ではなく計画的なメンテナンスが可能になります。 データ駆動のタイムライン： 実際の60日間のトラフィックパターンから算出した成長率により、キャパシティ計画チームは正確で説明可能な予測を得られます。 コストを考慮した優先順位付け： インフラのアップグレードとゼロコストの構成変更の両方の選択肢が提示されるため、予算の制約に応じて選択できます。 図6. ネットワークキャパシティトレンド（60日間）とスケーリング要件を含む予測 コストに関する考慮事項 主なコスト要因は、スキャンした GB 単位で課金される Amazon CloudWatch Logs Insights のクエリと、VPC Flow Log のストレージです。したがって、支出は保持するログデータ量とクエリの実行頻度に応じて増減します。 デプロイメント階層別の月額コスト概算 月額コストの概算はデプロイメントの規模によって異なります。次の表は代表的な3つの階層を示しています。 階層 月額コスト概算 プロファイル Basic $25〜$35 単一 VPC、開発/テストワークロード、低いクエリ量 Development $60〜$80 マルチ AZ の SAP ランドスケープ、中程度の監視、時折のユースケース実行 Enterprise $150〜$250 マルチ VPC の本番 SAP、高頻度のヘルスチェック、全ユースケースの自動化、CloudTrail 監査ログ 実際の VPC Flow Log 量とクエリ頻度に基づくコスト見積もりには AWS Pricing Calculator をご利用ください。 まとめ Kiro-CLI と AWS MCP Servers を組み合わせることで、SAP のネットワークトラブルシューティングを、何時間もの断片的な手作業から、自然言語で駆動する数分の診断へと変革できます。本記事の数値や出力は、外部でベンチマークした結果ではなくリファレンスデプロイメントからの説明用の例であり、実際の結果はランドスケープの規模やログ量によって異なります。5つの実世界のユースケースを通じて、このアプローチが以下を実現する様子をご覧いただきました。 単一のプロンプトによる包括的なネットワークヘルスチェックとスコアリング。 RISE with SAP の 504 エラーに対する体系的な根本原因分析。 SAP Note 1100926 （SAP S* ユーザー ID が必要）のしきい値に照らしてベンチマークしたクロス AZ レイテンシー診断。 CloudTrail の相関を用いたセキュリティグループドリフトの確定的な原因特定。 コストを考慮した推奨事項付きのプロアクティブな60日間ネットワークキャパシティ予測。 次のステップ：実装ロードマップ このセクションでは、ゼロから動作する SAP ネットワークトラブルシューティング環境を構築するために必要なすべて、すなわち見込むべき総時間、必要なダウンロードとドキュメント、そして運用開始後に専門性を深める場所をまとめます。まずは以下の時間見積もりから始めてください。 初回のフル実行にはエンドツーエンドでおおよそ2〜3時間を見込んでください。継続利用はクエリあたり数分で済みます。 フェーズ アクティビティ 所要時間の目安 セットアップ Kiro-CLI をインストールし、AWS マネージド MCP Servers を構成する 30〜60分 セットアップ SAP VPC で VPC Flow Logs と CloudWatch ロググループを有効化する 20〜30分 セットアップ 最小権限の IAM 権限を適用し、CloudTrail を有効化する 15〜20分 初回実行 ユースケース1を実行してネットワークヘルススコアのベースラインを確立する 10〜15分 導入 残りのユースケース（2〜5）を運用 runbook に追加する 30〜45分 継続運用 自然言語プロンプトによるクエリごとの診断 数分 必要なドキュメントとダウンロード 開始前に以下のリンクを揃えておいてください。最初の3つはインストールと構成を、残りはインフラストラクチャ、監視、しきい値、コスト見積もりのためのリファレンス資料です。 Kiro-CLI — インストールガイド マネージド AWS MCP Server（Agent Toolkit の一部） VPC Flow Logs を有効化する VPC Flow Logs を CloudWatch Logs に送信する Transit Gateway Flow Logs AWS CloudTrail を有効化する AWS Launch Wizard for SAP（HA デプロイメント） SAP Note 1100926 — レイテンシーしきい値（SAP S* ユーザー ID が必要） AWS Pricing Calculator — 月額コストの見積もり この先へ — さらに深く ベースラインが整ったら、同じ Kiro-CLI と MCP Server の基盤からさらに価値を引き出す5つの方法を紹介します。 運用に組み込む： 最もよく使うプロンプトをチームの runbook にまとめ、メンテナンスウィンドウのたびに自動的に実行して、セキュリティグループのドリフトを早期に検出します。 アラートを自動化する： 使用率80%のしきい値で CloudWatch アラームを設定し、キャパシティ予測をプロアクティブなスケーリングチケットに変えます。 カバレッジを拡大する： 同じ MCP + Kiro-CLI のパターンを隣接領域（IAM、コスト、オブザーバビリティの MCP Servers）に拡張し、統一された自然言語の運用コンソールを実現します。 マネージドに移行する： 単一エンドポイントアクセスと大規模での CloudTrail 監査の組み込みのために、マネージド AWS MCP Server を実装します。 クレジットと謝辞 本ブログは、AWS の SAP on AWS チームおよび AWS Network Specialist チームの貢献により作成されました。AWS マネージド MCP Servers と Kiro-CLI プロダクトチームのサポートに特に感謝します。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

本記事は、2026 年 10 月 14 日に Mike Landi と Doug Clauson が公開した「 Local sandboxing in Kiro: keep agent commands within boundaries 」を翻訳したものです。 Kiro のローカルサンドボックスは、ローカルのファイルや認証情報を保護する機能です。エージェントが実行するコマンドやスクリプトについて、アクセスできる範囲を制限します。この制限はオペレーティングシステムが強制するため、誤ったコマンドや信頼できないスクリプトによる影響を小さく抑えられます。本機能は、現在 Kiro IDE と Kiro CLI で一般提供中です。 多くのお客様は、Kiro IDE や CLI のエージェントをローカルマシン上で直接実行しています。ローカルで実行すると、エージェントはあなたと同じファイルシステム、インストール済みのツールチェーン、localhost のサービスを参照できます。そのため、エージェントは離れた場所からプロジェクトについて推測する代わりに、実際にビルドしてテストすることが可能です。その代償は、エージェントが実行するすべてのコマンドがあなたの権限を持ち、あなたとして動作することです。コマンドはファイルシステムにもネットワークにもフルアクセスできます。また、オペレーティングシステムのレベルには、エージェントが選んだコマンドとあなた自身が入力したコマンドを区別する仕組みがありません。これまでは、あなたが自分の注意力でこうしたコマンドを制御してきました。セッションを見守り、承認する前に各コマンドを読んで、おかしなものがあれば止めるという方法です。 エージェントを見張る注意力がボトルネックになる理由 エージェントの能力が上がり、開発者が並列で動かすエージェントが増えるにつれて、あなたの注意力がシステム全体のボトルネックになりかねません。タスクが長くなればコマンドが増え、コマンドが増えれば承認疲れが起きます。2 つ目のセッションを始めたり、リファクタリングの途中で席を外したりすると、次のどちらかになります。コマンドがブロックされたまま止まるか、あなたがコマンドを読まなくなるかです。さらに、問題を引き起こすのは悪意のある攻撃者だけではありません。たった 1 回の誤ったツール呼び出しや意図の取り違えが、実際のインシデントにつながる可能性があります。しかも、これまでエージェントが実行できたアクションの範囲は広いものでした。たとえば、Kiro の信頼モデルでは、エージェントが read_file ツールで ~/.aws や ~/.ssh を読み取ることをすでに拒否しています。しかし、粘り強いエージェントがシェル経由でスクリプトを実行すれば、同じファイルを読めてしまう可能性がありました。要求はブロックされても、エージェントは別の方法でファイルを読み取れたのです。IDE、CLI、Web で利用できる Kiro のクラウドサンドボックスは、エージェントを隔離された環境で実行することでこの問題に対処しました。ただし、ローカルにとどめる必要がある作業も数多くあります。たとえば、データレジデンシーの規則によりコードをクラウドに置けない場合や、localhost のサービスや VPN の内側にあるリソースを使う場合です。Xcode と Apple のツールチェーンが必要な iOS ビルドも該当します。 ローカルサンドボックスの仕組み ローカルサンドボックスでも、エージェント自体はこれまでどおりネイティブに動作します。一方、エージェントがあなたの代わりに実行するコマンドは、カーネルが強制するサンドボックスを経由する仕組みです。使用するサンドボックスは、macOS では Seatbelt、Linux では bubblewrap、Windows では AppContainer です。Kiro のツール呼び出しに対する権限チェックに加えて、オペレーティングシステムがこれらの制限を強制します。サンドボックスに与える権限は、あなたが選べます。たとえば、書き込みできるのはプロジェクトディレクトリと一時領域だけです。カーネルは、よく使われる認証情報のパスの読み取りを拒否します。そのため、エージェントが ~/.ssh/id_rsa を要求しても、判断を挟むまでもなく拒否されます。この拒否は、要求が read_file 、シェルのワンライナー、読み取りを代行させるために書かれたスクリプトのどれを経由した場合でも同じです。ネットワークアクセスは、ドメイン単位でフィルタリングするローカルプロキシを必ず経由します。この仕組みは、クラウドサンドボックスですでに使われているモデルと同じです。エージェントはパッケージレジストリなどの承認済みサービスにアクセスでき、それ以外の宛先へのアクセスはブロックされます。 エージェントをサンドボックスの外に置く理由 私たちは、エージェント自体を意図的にサンドボックスの外に置きました。制限されるのはエージェントが実行するコマンドだけです。そのため、セッションの途中でサンドボックスのオンとオフを切り替えたり、セッションを再起動せずにポリシーを変更したりできます。境界を変更しても、次のコマンドをどのようにラップするかが変わるだけだからです。この設計判断から 3 つの利点が得られます。まず、マシンの ID はサンドボックスの中に入りません。マシンの ID とは、エージェントがモデルを呼び出したり Kiro のバックエンドにアクセスしたりするときに使う認証情報です。そのため、サンドボックス内のプロセスが暴走しても、その認証情報を使ってあなたの名義で外部と通信することはできません。次に、ローカルの MCP サーバーはホストのネイティブプロセスとして、変更なしでそのまま動作します。MCP サーバーの動作も制限したい場合は、サンドボックスを経由させることもできます。最後に、従来の意味でのサンドボックスは存在せず、あるのは制限された子プロセスだけです。つまり、サンドボックスに何かを注入する必要もなければ、最初のコマンドを実行する前にコンテナ、イメージ、VM を起動する必要もありません。 サンドボックスによる保護を有効にすると、ローカルでの作業はオペレーティングシステムが強制する制限の範囲内で行われます。リファクタリング、ビルドとテストのループ、依存関係のアップグレードは、これまでどおり手元のマシンで実行されます。ただし、これらの作業で実行されるコマンドがアクセスできるファイルとネットワークの宛先は、制限の対象です。サンドボックスを有効にすると、承認済みのコマンドが実行できる操作を制限できます。 有効化する 現時点では、サンドボックスはデフォルトで無効になっています。ワークスペースで有効にするには、 sandbox.json を使用してください。グローバルのデフォルトとして設定する場合は ~/.kiro/settings/sandbox.json に、プロジェクト単位で上書きする場合は <project-root>/.kiro/settings/sandbox.json に配置してください。 { "enabled": true } ファイルを編集せずに有効にすることもできます。Kiro CLI では、ローカルセッション（ kiro-cli chat --v3 ）で /sandbox on を実行するか、 /sandbox を開いてグローバルまたはプロジェクトのスコープとネットワークモードを選択してください。Kiro IDE では、コマンドパレットから Kiro: Open User Sandbox Config (JSON) を実行してください。有効になると、ステータスバーに Command sandbox: Active と表示されます。Windows では、最初に 1 回だけ管理者権限でのセットアップが必要です。IDE ではセットアップを促すプロンプトが表示されます。CLI では /sandbox setup を実行してください。 デフォルトのポリシーを適用するには、ここまでの設定で十分です。デフォルトのポリシーでは、プロジェクトディレクトリへの書き込みが許可され、一般的な認証情報のパスへのアクセスは拒否されます。ネットワークアクセスはローカルプロキシを経由します。エージェントが触れられる範囲を細かく調整したい場合は、 permissions.yaml にルールを追加してください。このファイルは、現在すでにツールの認可を管理しているポリシーファイルと同じものです。ローカルサンドボックスは、既存の Workspace Trust モデルとは別に 2 つ目の権限システムを導入するものではありません。同じ fs_read 、 fs_write 、ネットワークに関する capability ルールが、ツールの境界に加えて OS カーネルでも強制されるようになります。以下は ~/.kiro/settings/permissions.yaml の例です。 rules: - capability: fs_write match: ["./**"] effect: allow - capability: fs_read match: ["~/.aws/**", "~/.ssh/**"] effect: deny - capability: sandbox_network match: ["internal-registry.corp.example.com"] effect: allow Workspace Trust と permissions.yaml でポリシーを設計する エージェントによる ~/.ssh/id_rsa への read_file ツール呼び出しを拒否するルールは、カーネルレベルでのサンドボックスの読み取りも拒否します。エージェントがそのファイルにたどり着く手段が read_file 、シェルのワンライナー、読み取りを代行させるために自分で書いたスクリプトのどれであっても同じです。1 つの信頼ポリシーが 2 回強制されます。1 回目はエージェントがツール呼び出しを通じて行儀よく要求したとき、2 回目は OS がその下で実際のシステムコールをチェックするときです。ツール呼び出しのチェックは必要ですが、それだけでは十分ではありません。ポリシーエンジンが認識しているツールを経由したリクエストしか捕捉できないからです。カーネルのチェックは、前述の Python スクリプトによる回避策を含め、それ以外のリクエストをすべて捕捉します。サンドボックスが読み込むのは、既存のポリシーそのものです。そのため、ポリシーエンジンがすでにサポートしているすべてのスコープ（管理者、ユーザー、ワークスペース、エージェント、セッション）が自動的に引き継がれます。 よくある質問 デフォルトで有効になっていますか？ いいえ。グローバルに有効にするには ~/.kiro/settings/sandbox.json 、特定のプロジェクトで有効にするには <project>/.kiro/settings/sandbox.json を使用してください。CLI で /sandbox on を実行するか、IDE のサンドボックス設定から有効にすることもできます。 どのオペレーティングシステムがサポートされていますか？ macOS では Seatbelt を使用します。Linux では bubblewrap を使用します。bubblewrap は socat と一緒に、お使いのディストリビューションのパッケージからインストールしてください。Windows では、1 回限りの管理者権限でのセットアップを行ったうえで AppContainer を使用します。 Kiro が承認を求めなくなるのですか？ いいえ。サンドボックスは、承認済みのコマンドで実行できる操作が制限されています。 ローカルサンドボックスは Kiro IDE と CLI で利用できます。設定の詳細やネットワークモードについては local command sandbox docs を、 sandbox_network ルールについては permissions docs を参照してください。 試すには、Kiro IDE 1.3 以降、または Kiro CLI 2.31 以降（ローカルの V3 セッション）にアップデートしてください。 翻訳は Solutions Architect の吉村が担当いたしました。

アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、2026 年 9 月 24 日（木）に、AWS ジャパン オフィスで「Kiro Meetup #8」を開催しました。Kiro Meetup は、Kiro を使っている方が集まり、使い方の工夫や最新アップデートを共有するコミュニティイベントです。今回はオフィス移転後の新しい会場での開催となりました。 当日は、AWS から Kiro の最新アップデートと Kiro Crew の詳細を紹介したあと、三菱電機株式会社の中村 信夫 氏と小森 裕之 氏、東海旅客鉄道株式会社の倉澤 瑞希 氏、株式会社オープンアップシステムの藤牧 正和 氏にライトニングトークでご登壇いただきました。同じ日の午後には、同会場でハンズオン「手を動かして実感する、Kiro が変える開発体験」も開催しています（ ハンズオンの開催報告 もあわせてご覧ください）。本記事では、Meetup の模様をレポートします。 イベント概要 開催日時: 2026 年 9 月 24 日（木）18:00〜20:30 会場: AWS ジャパン オフィス アジェンダ Kiro の最新アップデート: AWS ジャパン Developer Transformation エンゲージメントマネージャー Katz Ueno (カツ) Kiro Crew Dive Deep: AWS ジャパン ソリューションアーキテクト 小西 杏典 お客様ライトニングトーク 三菱電機株式会社 中村 信夫 氏、小森 裕之 氏 東海旅客鉄道株式会社 倉澤 瑞希 氏 株式会社オープンアップシステム 藤牧 正和 氏 クロージング ネットワーキング 本イベントの司会進行は AWS ジャパン 事業開発マネージャー 井形 健太郎が務めました。 開会のご挨拶 冒頭では、シルバーウィーク明けの平日夜に集まった参加者へのお礼とともに、Kiro Meetup の成り立ちを紹介しました。Kiro Meetup は 2025 年に Amazon Q Developer の Meetup として始まり、Amazon Q Developer や Kiro を使っている方がユースケースやアップデートを共有し、和気あいあいと過ごす場として続けてきました。オフィス移転の影響で間が空いたものの、今後も継続して開催していく予定です。 Kiro の最新アップデート スピーカー: AWS ジャパン Developer Transformation エンゲージメントマネージャー Katz Ueno (カツ) 最初のセッションでは、Katz が前回の Kiro Meetup（2026 年 3 月）以降の半年間を振り返り、86 件の Changelog から注目の 8 件を紹介しました。大きな流れは、Kiro Web の一般提供や Kiro Crew のオープンソース公開で使える場所が増えたこと、そして Cloud Sessions などで実行場所がローカルからクラウドへ広がったことです。 Kiro IDE 1.0 / 1.1 : エージェントとのやり取りに集中できる画面「Agent Focus」が加わりました。権限はワークスペースごとにも全体共通でも設定でき、カスタムエージェントは Markdown で定義できます。Windows と Linux の ARM64 環境でもネイティブに動作するようになりました。 Kiro Web の一般提供開始（9 月 1 日） : ブラウザだけで開発できるようになりました。対話しながら進める Collaborative モードと、計画から PR の作成までを自律的に進める Autonomous モードがあります。 Kiro CLI 2.0 と V3 : Windows 11 でネイティブに動作するようになり、CI/CD に組み込めるヘッドレスモードも加わりました。IDE や Web と同じハーネスで動く V3 も、プレビューとして公開されています。 Cloud Sessions と Configuration Sync : セッションをクラウド上で動かせるようになり、別のマシンから続きを再開できます。 .kiro の設定も、クラウドを通じて複数のマシンで同期できます。 モデル : OpenAI の GPT-5.6 と、Anthropic の Claude Opus 5、Claude Sonnet 5 が使えるようになりました。9 月 16 日には、Kiro Enterprise 向けに Claude Fable 5.1 のプレビュー提供が始まっています。 ガバナンスとコンプライアンス : Kiro が ISO/IEC 27001:2022 の認証範囲に加わり、IDE と CLI は HIPAA 適格になりました。利用状況のメトリクスを OpenTelemetry で送信できるほか、超過利用に上限を設定することもできます。 仕様駆動開発の強化 : タスクを並列で実行できるようになりました。途中の承認を挟まずに要件・設計・タスクをまとめて作る Quick Spec（公開時の名称は Quick Plan）と、要件のあいまいな点や矛盾を洗い出す Analyze Requirements も加わっています。 Kiro Crew の登場 : 複数の Kiro CLI をまとめて動かす、常駐型のエージェント基盤です。詳しくは次のセッションで紹介されました。 最後に、登壇で使った資料は Kiro Crew で下書きしたことを種明かし。アップデートの一覧とリンクなど、Kiro Crew が Changelog を読み込んで作成したことを紹介しました。あわせて、開発者向けコミュニティ AWS Builder Center をご紹介。相互のコミュニケーションが取れることもアピールしました。 Kiro Crew Dive Deep スピーカー: AWS ジャパン ソリューションアーキテクト 小西 杏典 続いて、ISV/SaaS 業界のお客様を支援するソリューションアーキテクトで、Kiro CLI のコントリビューターでもある小西が、Kiro Crew の仕組みを解説しました。 小西はまず、いまの AI エージェント開発には、人が席を離れると作業が止まる、セッションをまたぐと前の会話を忘れる、セッションが直列にしか動かない、という 3 つの課題があると指摘しました。Kiro Crew は、これらを解決する「永続的なオープンソースのワークスペース」で、次の 4 つの特徴を備えています。 永続的かつ自己改善型 : メモリとスケジュールがセッションや再起動をまたいで残り、ユーザーからの修正は「レッスン」として蓄積されます。 マルチエージェントオーケストレーション : cron や Webhook をきっかけに複数ステップのタスクを自律的に実行し、サブエージェントを並列に動かします。 オープンで拡張可能 : App SDK で独自のアプリを組み込め、Slack や Teams などのメッセージチャネルからも操作できます。 セキュアで、あなたの管理下に : OS のサンドボックス、段階的な承認ゲート、自社のハードウェア上での実行、監査ログを備えています。 編集・実行・デバッグを繰り返す「インナーループ」は Kiro CLI や Kiro IDE で対応できますが、スケジュール実行や CI の監視のように人が離れても動き続ける「アウターループ」には常時稼働のゲートウェイが必要です。Kiro Crew はこのゲートウェイとしてセッション、メモリ、セキュリティなどを管理し、その裏で Kiro CLI がエージェントとして動きます。セキュリティは多層防御で、 ~/.aws や ~/.ssh へのアクセスはどの設定でも解除できない基本制限としてブロックしています。 まとめとして小西は、1 つのセッションで開発を進めるなら Kiro IDE / CLI、セッションをまたぐ記憶やスケジュール実行、継続的な運用には Kiro Crew、という使い分けを示しました。 お客様ライトニングトーク ここからは、Kiro を活用している 3 社にライトニングトークでご登壇いただきました。 三菱電機株式会社 中村 信夫 氏、小森 裕之 氏「Kiro が組織に広がってきた！」 三菱電機株式会社 中村 信夫 氏と、小森 裕之 氏にご登壇いただきました。 前半の中村氏は、「重厚長大」の風土が残る電力部門で Kiro をどう広げたかを紹介しました。中村氏の部門では、社員と協力会社が参加する約 700 名のコミュニティ「YOKOHAMA UNITED」を運営しており、毎週の勉強会はこれまでに 137 回を数えます。2025 年 7 月の Kiro 発表の直後から使い始め、AWS を講師に招いた勉強会には約 100 名が参加しました。2026 年 1 月には、約 30 名が 3 日間参加する AI-DLC Unicorn Gym を、トップダウンで開催しました。定員 16 名で募集した社内ハンズオンに 90 名を超える社員が集まったほか、新入社員向けのアジャイル研修では、例年のマシュマロチャレンジの代わりに Kiro を使い、各チームが 2 回のスプリントで飲み会の日程調整システムを作り上げたといいます。中村氏は「組織トップダウンとコミュニティボトムアップのシナジー」が大切だったと振り返りました。 後半の小森氏は、Kiro を開発ワークフローに組み込み、部門のソフトウェア開発フローを標準化する取り組みを紹介しました。部門内の Kiro のユーザーは約 900 名にのぼります。AWS がオープンソースで公開している開発手法 AI-DLC V2 のワークフローを Kiro の上で動かし、2 つの工夫を加えています。1 つ目は、実装とレビューを別のモデルに担わせることです。生成 AI は自分の出力を正しいと思い込みやすいため、Kiro で OpenAI と Anthropic の両方のモデルを選べる点を生かし、Claude のモデルで要件・設計・実装を行い、AI-DLC V2 の工程ごとの AI レビューは GPT-5.6 に任せ、最後に人が確認して承認します。2 つ目は、AI-DLC V2 のレビューの重さを工程ごとに選べるようにしたことです。既定では敵対的検証によるレビューが 2 回走りますが、「重い」という声があったため、工程に応じて回数を減らすなど、品質と時間のバランスを取る設定を試しています。 東海旅客鉄道株式会社 倉澤 瑞希 氏「現場の『こうしたい』を、動くものへ ～Kiro で変わった技術開発の進め方～」 東海旅客鉄道株式会社 倉澤 瑞希 氏にご登壇いただきました。 倉澤氏は新幹線の保線の現場を長く経験したあと、技術開発部の DX チームへ異動し、アプリ開発の経験がないところから取り組みを始めました。Kiro は 2025 年 12 月から利用しており、用途は、データ分析やシミュレーター、3D 点群の可視化などの実装 PoC、要件定義やレビュー、報告資料や研修資料などのドキュメント作成、CI/CD や GitLab などの環境構築・運用の 4 つに広がっています。 代表的なプロダクトとして、駅の改良工事で資材の置き場所が旅客の流れを妨げないかを検証する「駅旅客流動シミュレーション」と、ベテラン社員の暗黙知を AI がインタビュー形式で引き出して蓄積する「熟練者ナレッジ蓄積」についてプロトタイプを短期間で実装した例を紹介しました。 倉澤氏がプロダクト以上に大きかったと話したのは、技術開発の進め方の変化です。以前は研究員が要望と業務知識を整理してベンダーやメーカーに伝え、設計・実装してもらっていました。Kiro の導入後は、研究員が自然言語で「こうしたい」を言語化し、Kiro がスペック化と実装を担い、研究員が確認して判断する、というサイクルを自ら高速に回せるようになりました。倉澤氏は「Kiro は魔法ではなく増幅器」と表現し、0 を 100 にするのではなく、研究員が持つドメイン知識や現場の課題という「1」を大きくしてくれるものだと説明しました。そのうえで、Kiro を導入するだけでなく、使い方そのものをチームで育てることが大切だと締めくくりました。 株式会社オープンアップシステム 藤牧 正和 氏「人的資本経営による AI 導入と直面した課題のご紹介」 株式会社オープンアップシステム 藤牧 正和 氏には、AI 駆動開発を進める中で直面した失敗や課題を中心にご紹介いただきました。 同社は社員 700 名弱のシステム開発会社で、2025 年 1 月から AI の研究を始め、同年 3 月には Amazon Q Developer を使い始めました。約 1 年半の試行錯誤を経て、AI を中心にシステム開発ができる段階にたどり着き、現在は大手 SIer からの AI 開発導入の相談にも応じています。全部門で AI を使っており、最もよく使われているのは Kiro です。 直面した課題として、藤牧氏は次のような点を挙げました。「自分の仕事が増えるだけ」という抵抗は、新人が 1 か月かけてもできるかどうかだった作業が 1 時間ほどで終わったことをきっかけに解消し、一気に広まりました。セキュリティはガイドラインとオプトアウト設定で対応し、プロンプトの上手い下手による差は Steering で AI の動かし方を標準化して埋めました。プロンプトの工夫に時間をかけすぎるバイブコーディングの限界にぶつかったことから、仕様駆動開発で正確に開発できる Kiro に全員で移行しています。現在の課題は、AI に指示する力を持つ人材と、上流から開発全体を見通してコーディネートできる人材の育成で、採用と育成の方針も見直したといいます。 最後に藤牧氏は、AI を導入しても仕事は減らず、むしろできることが増えて仕事も増えると述べ、人を資本として活かす「人的資本経営」の観点で AI への投資を進めていると語りました。 おわりに 今回の Meetup では、Kiro の半年分のアップデートと Kiro Crew の仕組みを紹介し、3 社に Kiro を組織に広げる取り組みを語っていただきました。三菱電機株式会社様は、トップダウンとコミュニティによるボトムアップの両輪で利用を広げています。東海旅客鉄道株式会社様は、研究員が自ら「こうしたい」を実装まで回せるようになりました。株式会社オープンアップシステム様は、全部門での AI 活用で直面した課題と人材育成の見直しを共有してくださいました。3 社に共通していたのは、Kiro を導入するだけで終わらせず、使い方そのものを組織で育てている点です。 AWS ジャパンは、今後も Kiro Meetup を継続して開催し、Kiro を使う皆様が知見を共有できる場を提供してまいります。ご登壇いただいた皆様、ご参加いただいた皆様、ありがとうございました。 登壇資料 Kiro の最新アップデート: Kiro Meetup #8 Kiro アップデート (2026/3/21〜2026/9/24) Kiro Crew Dive Deep: Kiro Crew Dive Deep 三菱電機株式会社 中村 信夫 氏、小森 裕之 氏「 Kiro が組織に広がってきた！ 」 東海旅客鉄道株式会社 倉澤 瑞希 氏「 現場の『こうしたい』を、動くものへ ～Kiro で変わった技術開発の進め方～ 」 株式会社オープンアップシステム 藤牧 正和 氏「 人的資本経営による AI 導入と直面した課題のご紹介 」