はじめに 業界調査（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 松本がレビューしました。原文は こちら です。

お盆ど真ん中に100人超！社内イベント「Codex祭り Sol Ultra」を開催！ Codex a ...

本記事は、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 の吉村が担当いたしました。