本日、 Kiro IDE と CLI にメモリ機能を導入します。Kiro は、あなたが好む作業の進め方、リポジトリ固有のコマンドや規約、受けた訂正、デバッグで得た知見、すでに除外したアプローチを覚えておけるようになります。それらが再び関係する場面になると、Kiro はあなたのコンテキストを引き継ぎます。コンテキストを説明し直したり同じ訂正を繰り返したりする時間が減り、Kiro は言われなくてもあなたの好みに沿って動けるようになり、使い込むほど役に立つ存在になります。 (元記事では、Kiro CLI でメモリを操作するターミナルの録画を掲載しています。 元記事 でご覧ください。) 作業の途中で出てきたことを覚える ルールやプロジェクトドキュメント は、あらかじめ意図して書き出せるコンテキストを、Kiro に一貫して適用させたい場合に向いています。メモリは、作業を進めるうちに出てきて、放っておけば書き留められないままになりがちなコンテキストのためのものです。 たとえば、ある種のロジックをどこに置くべきかについて Kiro を訂正することがあるでしょう。デバッグ中に、ローカルのサービスを起動してからでないと統合テストが通らないと気づくこともあります。Kiro に変更をどう進めてほしいかという好みが固まることもあります。メモリを有効にすると、Kiro はこうした細かな点を、出てきたその場で記録します。 メモリは過去の会話を再生するのではなく、後の作業に役立つ具体的なコンテキストを保持します。理解が変われば、Kiro はメモリを更新して精度を上げられます。メモリはお使いのマシンのローカルに保存され、そのマシン上の Kiro IDE と CLI の間で共有されます。そのため、一方のクライアントで記録したコンテキストをもう一方でも使えます。各メモリはグローバルにも特定のリポジトリにも適用でき、Kiro は全般的な作業の好みと、特定のコードベースに属するコンテキストを区別できます。 Kiro が覚えている内容を確認し、管理する IDE では、Kiro がメモリにアクセス、作成、更新、削除したときにチャットに表示されるので、Kiro が覚えている内容をいつ使い、いつ変更しているかがわかります。アクティビティバーから Memories ビューを開くと、Kiro が覚えている内容を一覧・検索でき、各メモリの適用範囲を確認し、個々のエントリを詳しく見て、もう残しておきたくないものを削除できます。CLI では、呼び出されたメモリがチャットに Memory エントリとして表示され、 /memories で保存済みのメモリを検索、プレビュー、表示できます。 今回のリリースでは、メモリは既定でオフになっています。IDE と CLI のどちらでも、Kiro が既存のメモリを使えるかどうかと、メモリを作成・更新できるかどうかを設定できます。呼び出されたメモリは Kiro が使えるコンテキストの一部になるため、メモリを使うとコンテキストの使用量が増えることがあります。これらの設定によって、Kiro に何を引き継がせるか、そして作業を進めながら学習を続けさせるかどうかを決められます。 使い始める Kiro IDE では、アクティビティバーから Memories ビューを開いて設定を開き、 Use and learn を選びます。これで Kiro は既存のメモリを使い、作業に合わせてメモリを自動的に作成・更新するようになります。有効にした後は、いつもどおり Kiro と作業してください。Memories ビューにはいつでも戻って、Kiro が覚えている内容を確認したり、不要になったメモリを削除したり、メモリの動作を変更したりできます。 Kiro CLI では、メモリはローカルの V3 セッションで利用できます。 /memories と入力すると、保存済みのメモリを確認したり、アクセスを設定したりできます。 read & write アクセスにすると、メモリの自動更新を有効にでき、Kiro が作業に合わせてメモリを作成・更新するようになります。メモリのアクセス設定の変更は、新しい CLI セッションから反映されます。 提供状況 メモリは Kiro IDE 1.4.0 以降と、Kiro CLI 2.29.0 以降のローカル V3 セッションで利用できます。メモリは既定でオフになっており、IDE と CLI のどちらからでも有効化と設定ができます。 同じ説明を繰り返す時間を減らし、作業を前に進めることに時間を使いましょう。次の Kiro セッションでメモリをオンにしてみてください。設定と管理の詳細は メモリのドキュメント をご覧ください。 この記事は Kiro ブログの Introducing memory in Kiro IDE and CLI を翻訳したものです。

本ブログは 2026 年 7 月 30 日に公開された AWS Blog “ Balancing speed and safety: A control framework for AI coding agents ” を翻訳したものです。 AI コーディングエージェントは、今や開発者のツールチェーンの一部です。Kiro や Claude Code などのツールは、自然言語のプロンプトから、機能やテストのコード、リファクタリングによるコード変更を生成します。1 つのエージェントが、午後だけで複数のリポジトリにまたがって数十件のプルリクエスト (PR) を作成することもあります。ただし、この生産性にはトレードオフがあります。エージェントは組織のリスクを理解しないまま、マシンの速度でタスクの完了を最優先に動作します。 Model Context Protocol (MCP) などのプロトコルを通じて、エージェントは統合開発環境 (IDE) の外にも手を伸ばし、API の呼び出し、データベースへのクエリ、インフラストラクチャの変更、さらには環境全体の変更まで行います。その結果、アプリケーションセキュリティチームが守るべきリソースの範囲が広がっています。 本記事では、AI コーディングエージェント向けのアプリケーションセキュリティ (AppSec) のコントロールフレームワークを紹介します。このフレームワークは 2 つの柱で構成されています。作成時 (author-time) のコントロールは、IDE でエージェントが生成するものを方向付けます。ビルド時 (build-time) のコントロールは、本番環境に到達するものを検証し、通過可否を判定します。既存のセキュアなソフトウェア開発ライフサイクル (SDLC) のコントロールも引き続き有効であり、多層防御のセキュリティ戦略に欠かせません。このフレームワークは、エージェント主導の開発に合わせて AppSec をスケールさせるために、どこにガードレールを追加すべきかを示します。また、特定のツールやクラウドには依存しません。本記事では全体を通して、AWS のサービス (IDE では Kiro 、ビルドでは AWS CodePipeline ) を具体例として使用します。ご自身のツールチェーンに合わせて応用してください。 リスク 以下の各リスクには、対策の概要を記載しています。実装の詳細は、本記事後半の「 コントロールフレームワーク 」セクションで説明します。リスクは重大度順に並べており、影響が最も大きいものから順に記載しています。 R001. プロンプトとコンテキストのインジェクション エージェントは、Issue の説明、ウェブページ、MCP のレスポンス、サードパーティパッケージ内の README ファイルなど、信頼できないコンテンツを読み込みます。外部から持ち込まれたテキストによって、エージェントがシークレットを漏洩したり、許可されていない PR を作成したり、ユーザーの同意なしにツールを呼び出したりするよう誘導される可能性があります。このリスクは プロンプトインジェクション と呼ばれ、 OWASP Top 10 for LLM Applications で最上位のリスクに位置付けられています。MCP の有無にかかわらず、外部のコンテンツを読み込むエージェントはすべてこのリスクにさらされます。ツールを接続すれば、その分だけ影響範囲が広がります。 対策 : 開発者以外からの入力は信頼できないものとして扱います。大規模言語モデル (LLM) は単一のコンテキストウィンドウ内で指示とデータを確実には区別できないため、それを前提にアーキテクチャを設計します。具体的には、信頼されたアクションをオーケストレーションするエージェントと、信頼できないコンテンツにさらされるエージェントを分離し、後者には読み取り専用かつ最小権限のアクセスのみを付与します。元に戻せないアクションには人間による承認を必須にします。また、ステアリングファイルをバージョン管理し、気付かないうちに改ざんされることを防ぎます。 R002. 意図しないデータ漏洩と過度に緩い設定 エージェントは作業を完了させることを最優先します。チェックせずに放置すると、エージェントが生成するコードは、ワイルドカードを使用した IAM ポリシー、開放されたセキュリティグループ、暗号化されていないストレージをデフォルトで使用したり、シークレットマネージャーを参照せずに機密性の高い値をコードに埋め込んだりする可能性があります。現在、ほとんどのコーディングエージェントにはこうした事態を起こりにくくする安全メカニズムが組み込まれていますが、完全ではありません。そのため、こうした可能性に備えたコントロールが引き続き必要です。 対策 : ステアリングドキュメントにセキュリティ要件を記述したうえで、IDE とパイプラインで Policy as Code によるスキャン (Checkov、cfn-nag) を実施します。詳しくは「 セキュリティコントロールとしてのコンテキスト 」を参照してください。 R003. 管理されていない変更の本番環境への到達 ゲートによる検証を受けていないコードが本番環境に到達すること自体は新しい問題ではありませんが、AI エージェントはこの問題を増幅させます。マシンの速度でコードが生成されるため、欠陥のあるパターンが発見される前に複数のリポジトリへ広がってしまう可能性があります。 対策 : PR の承認を必須とするブランチ保護ルール (人間が介在する Human-in-the-Loop のチェックポイント)、セキュリティチェックのための pre-commit フック、保護されたブランチへの直接プッシュを防ぐサンドボックス化されたエージェント実行を組み合わせます。人間によるレビューと自動化による速度のどちらをどの程度重視すべきかは、変更のリスクプロファイルによって異なります。リスクの低い多くの変更では自動チェックだけで十分な場合もありますが、リスクの高い変更には人間によるチェックポイントを設けるべきです。 R004. サプライチェーンのリスク エージェントは、現在のベストプラクティスと古いパターンを常に区別できるとは限りません。非推奨のパッケージを提案したり、新たな CVE (Common Vulnerabilities and Exposures) が報告されたライブラリバージョンを参照したり、存在しないパッケージ名をハルシネーションで生成したりすることがあり、依存関係の混同 (dependency confusion) のリスクを招く可能性があります。 対策 : パイプラインでソフトウェアコンポジション解析 (SCA) を実施し (例: Amazon Inspector のコードスキャンや Dependabot)、脆弱な依存関係や予期しない依存関係にフラグを立てます。さらにコントロールを強化するには、 AWS CodeArtifact のようにスコープを限定したレジストリから依存関係を解決します。完全にキュレーションされたレジストリがない場合でも、ロックファイルの検証と重要なパッケージの許可リスト登録によって、リスクへの露出を減らせます。 R005. 管理されていない外部アクセス エージェントは MCP やツール統合を通じて、データベースへのクエリ、API の呼び出し、インフラストラクチャの変更を行います。エージェントがアクセスできるツールやデータに制約がなければ、設定を誤った統合が 1 つあるだけで、機密性の高いリソースへの意図しないアクセスが生じます。 対策 : MCP サーバーが提供するツールとリソースを最小権限の範囲に限定し、外部接続には認証 (AuthN) または認可 (AuthZ) を適用したうえで、ツールの呼び出しを監査します。コントロールポイントとなるのは設定ファイルです。設定ファイルは、 AWS Identity and Access Management (IAM) ポリシーと同じようにレビューしてください。 R006. ハルシネーションと誤ったコード エージェントは、もっともらしく見える出力を生成します。コンパイルが通り、リンティングをパスし、一見妥当に見えるコードでも、機能的には誤っていることがあります。例えば、API の誤用、微妙なロジックエラーの混入、セキュリティ上重要な操作の誤った実装などです。ビルドに失敗するコードはすぐに検出されますが、継続的インテグレーション (CI) をパスしてしまう誤ったコードはレビューをすり抜けてしまいます。 対策 : 決定論的な検証 (静的アプリケーションセキュリティテスト (SAST)、単体テスト) と、非決定論的なレビュー (仕様に照らした LLM 支援のスクリーニング) を重ねて多層化します。どちらか一方だけで、すべての問題を検出することはできません。 R007. スコープクリープ (依頼範囲外の変更) バグ修正を指示するプロンプトを与えられたエージェントが、周辺コードのリファクタリング、不安定なテストの無効化、インポートの整理まで行ってしまうことがあります。依頼されていない変更はリグレッションを引き起こし、レビューを複雑にします。 対策 : 変更すべきものと変更してはならないものを定義したレビュー済みの仕様ドキュメントを用意し、提案された変更に的を絞ったレビューと組み合わせます。詳しくは「 スコープの境界としての仕様 」を参照してください。 これらのリスクには共通点があります。エージェントは人間がレビューできる速度を超えて出力を生成し、しかも自らの出力を修正するためのコンテキストを持っていないという点です。 以下で紹介するフレームワークは、このギャップに対処するものです。このフレームワークでは、コントロールを 2 つの柱に整理しています。作成時 (コードの生成前と生成後) と、ビルド時 (パイプライン内で、コードが本番環境に到達する前) です。作成時のコントロールはエージェントが生成するものを方向付け、ビルド時のコントロールはそれを検証します。どちらか一方だけでは不十分ですが、両方を組み合わせることで、人間のレビュー担当者に届く問題の量と重大度を減らせます。 決定論的な緩和策と非決定論的な緩和策の比較 決定論的な緩和策 [D] は、毎回同じ結果を返します。リンター、SAST スキャナー、シークレット検出、Policy as Code は、ルールに照らしてパターンを照合し、セキュリティの不変条件を定義します。例えば、重大度が Critical の検出結果がないこと、ハードコードされたシークレットがないこと、ワイルドカードを使用した IAM ポリシーがないことなどです。条件をルールとして表現できる場合に使用します。組織は既にこれらを導入しており、今後も引き続き適用する必要があります。 非決定論的な緩和策 [ND] は、モデルの判断を活用します。ステアリングドキュメント、LLM-as-judge によるレビュー、仕様準拠チェック、スコープクリープの検出などがこれに当たり、パターンではなく意図を評価します。ルールでは見逃される新しい問題を検出できる一方、結果は確率的です。評価にコンテキストや複数ファイルにまたがる推論が必要な場合に使用します。これは、AI が生成するコードに対応するために必要となる新しいレイヤーです。エージェントは、決定論的なチェックをすべてパスしながらも機能的には誤っているコードを生成する可能性があるためです。 人間によるレビュー [H] は、どちらの種類のツールでも下せないリスクベースの判断を担う最後のレイヤーです。 人間によるレビューは、すべての箇所ではなく判断が必要な箇所に適用します 。すべての変更を人間に回すと承認疲れ (consent fatigue) を招き、レビュー担当者が反射的に承認するようになって、コントロールが形骸化します。すべてを人間に回すことが反射的な対応になりがちですが、それが常に正しいとは限りません。人間の判断は、本当に必要な意思決定に限定してください。 コントロールフレームワーク このフレームワークでは、コントロールを 2 つの柱に整理しています。作成時のコントロール (柱 1) は、コードの生成前と生成直後に、IDE でエージェントが生成するものを方向付けます。ビルド時のコントロール (柱 2) は、本番環境に到達する前に、パイプラインでその出力を検証し、通過可否を判定します。各柱のコントロールには、決定論的 [D]、非決定論的 [ND]、人間 [H] のタグを付けています。 柱 1: 作成時のコントロール (コードの生成前と生成後) 作成時のコントロールは、開発者とエージェントがまだ完全なコンテキストを保持している IDE 内で機能します。PR が作成される前の段階で、プロンプトと生成された出力を方向付けます。この段階では、以下のコントロールを適用します。 セキュリティコントロールとしてのコンテキスト [ND] コントロールステートメント: すべての開発者環境がセッション開始時に読み込むステアリングドキュメントに、セキュリティの不変条件を自然言語の制約として記述します。R002 に対処します。 AI コーディングエージェントのリスクの多くは、1 つの共通する根本原因から生じています。経験豊富な開発者が暗黙のうちに持っているセキュリティのコンテキストを、エージェントが持っていないことです。セキュリティチームは、 Amazon Simple Storage Service (Amazon S3) バケットには暗号化が必要、API ゲートウェイには相互 TLS が必要、認証情報は AWS Secrets Manager から取得する必要がある、といったポリシーを定めています。しかし開発者は、構築作業の最中にこれらの要件を常に参照できるとは限りません。開発者が作るのは、セキュリティ要件に準拠したものではなく、動作するものです。AI エージェントは、組織のセキュリティポスチャを認識しないまま、トレーニングデータで主流だったパターンをデフォルトで採用するため、このギャップをさらに広げてしまいます。 その主要な緩和策がステアリングです。セキュリティチームはこれらの不変条件を自然言語のガイダンスとしてステアリングドキュメントに一度記述し、開発者が IDE で利用できる共有リソースとして配布します。エージェントはセッション開始時にこのファイルを読み込み、その内容を常に守るべき要件として扱います。 IAM ポリシーは最小権限の原則に従うこと。ワイルドカードを使用した Amazon リソースネーム (ARN) は使用しないこと。 ソースコードに認証情報をハードコードしないこと。シークレットマネージャーを使用すること。 セキュリティグループで無制限のインバウンドアクセスを許可しないこと。 これにより、コード生成が始まる前の段階までセキュリティをシフトレフトできます。 ステアリングは生成結果をセキュアなデフォルトに近づけますが、それを保証するものではありません 。ステアリングは強力なデフォルトとして位置付け、準拠していないコードのマージをブロックする後述の決定論的なゲートと組み合わせてください。セキュリティチームがルールを一度定義すれば、すべての開発者環境に自動的に引き継がれます。ステアリングによってパイプラインに到達する問題の量は減りますが、下流のスキャンが不要になるわけではありません。 効果的なステアリングルールの書き方: 各ルールは具体的かつテスト可能な内容にし、対象を具体的なリスクの分類に絞ります。エージェントがコンテキスト内に保持できるようルールセットは簡潔に保ち、スキャナーやレビュー担当者が見つけた問題を基に継続的に改善します。 スコープの境界としての仕様 [ND] コントロールステートメント: コード生成を開始する前に、レビュー済みの仕様を必須にします。変更すべきものと変更してはならないものを定義します。R007 に対処します。 仕様駆動のワークフローでは、コードを生成する前に、あいまいなプロンプトをレビュー可能な仕様に変換します。これにより、セキュリティに関する意思決定が行われる設計フェーズに、人間によるチェックポイントを設けることができます。 要件 は、エージェントがコードを 1 行も書かないうちに監査できるよう、テスト可能な記法で記述します。例えば、EARS (Easy Approach to Requirements Syntax) では WHEN [condition] THE SYSTEM SHALL [behavior] という形式を使用します。 タスク は実装ステップの順に並べ、それぞれを要件に対応付けます。 バグ修正の場合、仕様には、 変更後も維持すべき動作の文書化 という重要な要素が加わります。これは、修正後も引き続き正しく機能しなければならない動作を明示したリストであり、スコープクリープを防ぐ明文化された境界としてエージェントに提示されます。 このモデルでは、仕様が主要な成果物となり、コードは仕様から派生するものになります。人間によるレビューの労力は、実装の差分を 1 行ずつ読むことではなく、仕様が適切な制約のもとで適切な問題を解決しているかどうかの確認に集中します。 MCP を使用したツールアクセスの制御 [D + ND] コントロールステートメント: 各 MCP サーバーが提供するツールを、エージェントが必要とする最小限のものに限定し、開発者自身の認証情報ではなく、権限を絞り込んだ専用の認証情報を付与します。レビュー済みの MCP サーバーの許可リストを維持します。R005 に対処します。 MCP サーバーは、エージェントと外部ツール、データとの間で、管理されたゲートウェイとして機能します。 依存関係の管理 – プライベートパッケージレジストリの前段に配置した MCP サーバーは、パブリックインターネットではなく、キュレーションされたパッケージから依存関係を解決します。これはサプライチェーンリスクに対する決定論的な制約となります。 インフラストラクチャツール – 現在のリソース設定を可視化することで、既存のインフラストラクチャと競合するテンプレートの作成を防ぎます。 範囲を限定したアクセス許可 – 各 MCP サーバーは、定義されたツールとリソースのセットを公開します。エージェントがアクセスできる対象を厳密に選べるため、統合レイヤーで最小権限を実現できます。この専用の認証情報は、エージェントの設定を通じて提供します (Kiro では env ブロックを使用して .kiro/settings/mcp.json で指定します)。 autoApprove: ["*"] を設定すると、すべてのツール呼び出しで人間による承認プロンプトが表示されなくなるため、使用は避けてください。 IDE でのコードスキャン [D] コントロールステートメント: IDE でリアルタイムの静的解析を実行し、開発者 (およびエージェント) が完全なコンテキストを保持しているうちにセキュリティの問題を洗い出します。R002、R006 に対処します。 リアルタイムの診断により、開発者が入力している最中に構文エラー、型の不一致、設定の問題を検出できます。不正な形式の IAM ポリシーは、エージェントがそれを前提にさらに構築を進める前に検出されます。その上にセキュリティに特化した拡張機能 (ESLint のセキュリティプラグイン、Checkov、SAST) を重ねることで、コードの内容がコンテキストに残っているうちに即座にフィードバックを得られます。 フック: アクション発生時点での自動化されたガードレール [D + ND] コントロールステートメント: ファイル保存イベントには決定論的なチェックを、タスク完了イベントには非決定論的な検証を関連付けます。R002、R007 に対処します。 シェルコマンドフック [D] – ファイルの保存時にトリガーされ、リンター、フォーマッター、セキュリティスキャナーを実行します。毎回同じ結果を返し、厳格なルールを適用します。 AI を活用したフック [ND] – タスクの完了時にトリガーされます。実装が仕様と一致しているかを検証し、テストされていないエッジケースや、タスクの範囲外で変更されたファイルがないかを確認するよう、エージェントにプロンプトを送ります。 柱 2: ビルド時のコントロール (パイプライン内) ビルド時のコントロールは、コードがコミットされてから本番環境に到達するまでの間に、パイプラインで実行されます。エージェントが生成したものを検証して通過可否を判定し、作成時のコントロールで見逃された問題を捕捉します。この段階では、以下のコントロールを適用します。 多層的なセキュリティスキャン [D] コントロールステートメント: シークレット検出、静的解析、依存関係のスキャン、Infrastructure as Code (IaC) のスキャンを順番に実行します。重大度が Critical の検出結果が 1 つでもあれば、ビルドを失敗させます。R002、R003、R004 に対処します。 シークレット検出は、最もコストが低く、かつ重大度の高い種類の問題に対処できるため、最初に実行します。AI エージェントが誤って含めてしまう可能性のある、ハードコードされた API キー、データベース接続文字列、認証情報をスキャンします。 SAST は、インジェクションの問題、安全でないデシリアライゼーション、リソースリークがないかソースコードをスキャンします。カスタムルールを使用すると、過度に広範な例外処理、非推奨の API、プレースホルダーの認証情報、 eval() による動的なコード実行など、AI 特有のアンチパターンも検出対象にできます。 SCA は、依存関係に含まれる既知の CVE を特定します。AI が生成したコードは、非推奨のパッケージを参照したり、ハルシネーションによって存在しないパッケージ名を生成して依存関係の混同を招いたりする可能性があるため、SCA は特に重要です。 IaC のスキャンでは、 AWS CloudFormation 、 Terraform 、 AWS Cloud Development Kit (AWS CDK) のテンプレートを、デプロイ前にセキュリティポリシーに照らして検証します。エージェントが作成した過剰な権限を持つ IAM ロール、暗号化されていないストレージ、パブリックに公開されたリソースを検出します。 いずれかのステージが失敗すると、パイプラインは停止します。結果は、コンプライアンス監査に利用できるよう標準形式の SARIF (Static Analysis Results Interchange Format) でエクスポートされ、下流の人間のレビュー担当者に渡されます。オープンソースの Automated Security Helper (ASH) は、シークレット、SAST、SCA、IaC の各スキャナーを 1 つのコマンドにまとめたツールです。ローカル環境と AWS CodeBuild のどちらでも実行でき、後続のゲートで利用できるよう SARIF を出力します。 品質ゲート [D] コントロールステートメント: スキャンの種類ごとに合格/不合格のしきい値を定義します。重大度が Critical または High の検出結果が 1 つでもあれば、デプロイをブロックします。R003 に対処します。 品質ゲートは、スキャン結果を「進めるか止めるか」の判断に変換します。重大度ごとにしきい値を定義し、Critical の検出結果はブロック、High は正当な理由の説明を求め、Medium は追跡対象とします。ゲートは決定論的に動作し、しきい値を超えた場合はパイプラインが停止します。例外を認める場合は、文書化された承認が必要です。 ブロッキングモードとアドバイザリーモードを使い分けます。main ブランチでは失敗としてブロックし、フィーチャーブランチではアドバイザリー (警告のみ) とします。ゲートが開発の妨げとなり、チームがゲートを迂回するような事態は避けてください。 AI 支援レビュー [ND] コントロールステートメント: 人間がレビューする前に、LLM をレビュー担当者として使用し、すべての PR について仕様への準拠、スコープクリープ、セキュリティのアンチパターンを事前スクリーニングします。R001、R006、R007 に対処します。 仕様への準拠 – 実装は要件ドキュメントと一致しているか? スコープの検証 – タスクで定められた範囲外のファイルが変更されていないか? セキュリティパターンのレビュー – SAST を通過しても意図に反するロジックエラー、API の誤用、安全でないパターンはないか? この事前スクリーニングにより、人間のレビュー担当者はフォーマットや明らかな問題ではなく、実質的なリスクに集中できます。AWS では、 AWS Security Agent (英語原文が公開された 2026 年 7 月 30 日の時点で、コードレビュー機能はプレビュー中) が、AWS マネージドのセキュリティ要件とカスタムのセキュリティ要件に照らして PR をチェックします。LLM のレビュー担当者はスクリーニングを行って検出結果を提示しますが、マージの判断は人間が行います。 重要な原則: コードを書いたエージェントに、そのコードをレビューさせてはいけません。 別のセッションを使用すれば自己確証バイアスを避けやすくなりますが、セッションを分けるだけでは、生成側の盲点を必ずしも回避できません。同じモデルであれば、2 つのセッションが同じ盲点を共有している可能性があるためです。可能であれば、レビューには別のモデルを使用し、レビュー担当者が同じ系統的な弱点を引き継ぐ可能性を低減してください。 Human-in-the-Loop のレビュー [ND + H] コントロールステートメント: ほとんどの PR、特にセキュリティ上重要なコードや影響範囲 (blast radius) の大きいコードにかかわる PR では、人間による承認を必須にします。ツールが成熟するにつれて、リスクの低い変更はエージェント支援による承認や完全に自動化された承認の対象にできる可能性があります。レビュー担当者が十分な情報に基づいて迅速に判断できるよう、スキャン結果、LLM による事前スクリーニングの出力、仕様のコンテキストを提供します。R003 に対処します。 レビューの深さは、変更のリスクに応じて調整します。リスクの低い変更や定型的な変更はより簡易なレビューで対応できますが、セキュリティ上重要な変更や新しいロジックを含む変更には、詳細なレビューを必須とし、2 人目のレビュー担当者を加えるべきです。 スキャナーは既知のパターンを検出できますが、コードが意図したビジネスロジックを実装しているかどうかは判断できません。人間によるレビューは、 エージェントをどこまで信頼できるかの見極め にも役立ちます。チームは、エージェントが得意とする領域 (定型コード、テストの作成) と、これまで苦手としてきた領域 (新しいビジネスロジック、セキュリティ上重要な操作) について感覚をつかんでいきます。ただし、この境界はモデルの進化に伴って変化することを念頭に置いておく必要があります。 承認ゲートは 2 か所に配置します。1 つはセキュリティスキャンの後 (レビュー担当者はスキャン結果をコンテキストとして参照しながら、正確性とビジネスロジックに集中します)、もう 1 つは本番環境へのデプロイ前 (統合テスト後の最終承認) です。人間によるレビューは保証ではなく、二次的なコントロールとして扱ってください。レビュー担当者自身も非決定論的であり、問題を見逃すことがあります。そのため、人間によるレビューは決定論的なゲートに取って代わるものではなく、その上に重ねるものと考えてください。 AWS でのフレームワークの実践 このフレームワークは特定のツールに依存しませんが、AWS には各柱を実現するための構成要素がそろっています。以下のサービスは、前述のコントロールに直接対応します。作成時のガードレールには Kiro を、ビルド時のゲートには CodeBuild と CodePipeline を使用します。 Kiro: 構造化された AI 開発 Kiro は柱 1 に対応し、開発者とエージェントが完全なコンテキストを共有している IDE に作成時のコントロールを組み込みます。以下に挙げる各機能はそれぞれ 1 つのコントロールを実装するもので、リポジトリ内の .kiro/ 配下で設定します。そのため、ガードレールは開発者ごとに設定されるのではなく、バージョン管理されたうえでチーム全体で共有されます。 ステアリングドキュメント – .kiro/steering/ 内の Markdown ファイルが、セッション開始時にエージェントのコンテキストに読み込まれます。fileMatch を使用した条件付きの読み込み (例: ["**/*.tf"] ) により、IaC 固有のルールを関連する場合にのみ読み込めます。 仕様駆動のワークフロー – レビューのチェックポイントを備えた 3 フェーズの仕様 (EARS による要件、設計、タスク) を使用します。バグ修正の仕様では、変更されない動作を明示的に記録します。 エージェントフック – ファイルの保存、ツールの呼び出し、タスクの完了時にトリガーされます。シェルフックは決定論的なチェック (リンター、テスト) を実行し、 Ask Kiro フックは非決定論的なレビューのために AI プロンプトを実行します。例えば、セキュリティ用の pre-commit スキャナーフックを使用すると、エージェントがタスクを完了した時点で、ハードコードされた認証情報にフラグを立てることができます。 プロパティベーステスト – 仕様やフックの指示に基づいて、Kiro は数百とおりのランダムな入力を試すプロパティベーステストを生成できます (例えば、hypothesis ライブラリを使用)。これにより、手作業で書いたテストスイートでは見逃しがちなエッジケースを洗い出せます。 MCP 統合 – Kiro をプライベートパッケージレジストリ、社内ドキュメント、Issue トラッカー、インフラストラクチャツールに接続し、前述の管理されたツールアクセスのパターンを実現します。 エンタープライズ環境向けに、Kiro は AWS IAM Identity Center によるシングルサインオンをサポートしており、サブスクライバーには知的財産権 (IP) に関する補償を提供しています。Kiro のドキュメントで 現在利用可能なリージョンを確認してください。 AWS CodeBuild と AWS CodePipeline: パイプラインのコントロール CodeBuild は、各スキャンツール (シークレット、SAST、SCA、IaC のチェック) をビルドアクションとして実行します。終了コードが 0 以外の場合はアクションが失敗し、ステージは OnFailure の設定に従って停止またはロールバックします。検出結果はコンプライアンス対応のために SARIF 形式で Amazon S3 にエクスポートされ、CodePipeline のアクション変数を通じて下流の承認アクションに渡されます。 CodeBuild の終了コード により、スキャンが失敗した場合にパイプラインを停止します AWS Lambda 呼び出しアクション により、設定可能なしきい値に照らしてスキャン結果を評価し、合格/不合格の判断を返します 手動承認アクション により、パイプラインを一時停止し、 Amazon Simple Notification Service (Amazon SNS) で通知を送信して、レビュー用のアーティファクトへのリンクを提供します。判断内容とレビュー担当者の ID は監査用にログに記録されます 以下の表は、フレームワーク全体を 1 つにまとめたもので、SDLC の各ステージと、そこで適用される決定論的 [D] および非決定論的 [ND] のコントロールを示しています。どのステージにも両方のコントロールが含まれているのは、どちらか一方だけでは不十分であることを表しています。 ステージ 決定論的 [D] 非決定論的 [ND] IDE (生成前) ステアリングファイルの読み込み ステアリングドキュメント、仕様駆動の制約 IDE (生成後) シェルフック: リンター、フォーマッター、型チェッカー、シークレットスキャン AI を活用したタスク完了フック、コンテキストの制約 PR SAST、SCA、IaC のスキャン LLM による PR の事前スクリーニングとスコープの検証 パイプライン (デプロイ前) セキュリティスキャン一式、統合テスト、Policy as Code 人間の承認者向けの AI 支援レビュー デプロイ後 ランタイムモニタリングと異常検出 AI を活用したインシデントトリアージ まとめ 本記事では、レビューされていないリスクを本番環境に持ち込むことなく、マシンの速度で AI コーディングエージェントを活用するためのフレームワークを紹介しました。このフレームワークでは、2 つのポイントでガードレールを重ねます。 作成時のコントロール – ステアリング、仕様、範囲を限定したツールによって、IDE でエージェントが生成するものを方向付けます。 ビルド時のコントロール – スキャン、品質ゲート、多層的なレビューによって、本番環境に到達する前に生成物を検証します。 単一のレイヤーだけでは十分ではありません。決定論的なゲートが厳格なルールを適用し、非決定論的なレビューがそこで見逃された問題を検出し、人間の判断は、本当に必要な意思決定にのみ用います。これらを組み合わせることで、エージェント主導の開発に合わせて AppSec をスケールさせることができます。 今日から取り組めること ステアリングと仕様から始める – セキュリティ要件をステアリングとして記述し、新機能の開発には仕様を活用します。最小限の労力で最大の効果が得られます。すぐに使える出発点としては、オープンソースの Project CodeGuard (Amazon がコントリビューティングメンバーとして参加している OASIS Open の Coalition for Secure AI のプロジェクト) があります。一般的なリスクの分類 (ハードコードされた認証情報、IaC の設定ミス、サプライチェーン、MCP のセキュリティ) に対応した再利用可能なステアリングルールが公開されており、ご自身の AWS 環境に合わせて応用できます。 決定論的なパイプラインゲートを追加する – SAST、SCA、シークレット検出を統合します。AI を使用しているかどうかにかかわらず、最低限必要な対策です。 調整と改善を繰り返す – コントロールが検出した内容を確認し、繰り返し発生する問題に応じてステアリングを調整します。信頼が高まるにつれて、エージェントの自律性を広げていきます。 責任の所在 – リリースするもののセキュリティに責任を負うのは、引き続き開発者です。AI エージェントは開発を加速させますが、責任の所在を移すものではありません。 詳細情報 Kiro のドキュメント AWS CodePipeline ユーザーガイド AWS Agentic AI Security Scoping Matrix Daniel Begimher Daniel は AWS の Senior Security Engineer です。AWS 初のお客様向け AI セキュリティエージェントを構築し、リリースしました。AI インシデント対応エージェントが行動を起こす前にどれだけ深く調査するかを測定するベンチマーク SIR-Bench と、オープンソースのスキャナー Automated Security Helper (ASH) の開発者でもあります。AWS の Application Security Technical Field Community を共同でリードしており、AWS re:Invent、re:Inforce、Cyber Week などのカンファレンスで講演しています。 Danny Cortegaca Danny は Principal Security Specialist Solutions Architect で、AWS Security and Compliance Technical Field Community のアプリケーションセキュリティ領域を共同でリードしています。2021 年に AWS に入社し、世界有数の大規模組織と連携して、複雑なセキュリティ環境や規制環境への対応を支援しています。お客様とアプリケーションセキュリティについて語り合うことが大好きで、多くのお客様が脅威モデリングを実践に取り入れられるよう支援してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

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