AI-DLC(AI-Driven Development Lifecycle)とは何ですか?
AI-DLCは AI中心のソフトウェア開発アプローチ これにより、AIは計画から運用に至るライフサイクルのあらゆる段階で主要な実行者として位置づけられ、人間は戦略的方向性、承認、監督を提供します。
AWSによって導入され、現在は業界全体で採用されているこのツールは、 AI支援 コード化 AI駆動 工学。
主な特徴:
速度を前提に作られています: 組織 出荷 AI生成コード 前の速度の10倍の場合、その速度に特化したライフサイクルが必要です。 古いモデルにAIを付け込むことで、セキュリティと品質が崩壊します。
これは構造化された方法論です: AI-DLCはそれを超えています バイブコーディング. LLMの力を厳格に定義されたフロー構造(インセプション、構築、運用)や規定された儀式(モブの展開、モブ構築)に根ざしています。
それは道具ではありません. AIがほとんどの実行を担う中で、チームがどのように計画、構築、テスト、デプロイ、運用しているかを組織する方法だと考えてください。
Securing AI Agents 101
This one-pager explainer breaks it all down: What makes something an AI agent, where risk emerges (and why it’s hard to see), practical steps to reduce exposure, and what teams can do to secure AI pipelines.
なぜ従来のSDLCがAIファーストの世界で不十分であるのか
慣例 SDLC 開発者がコードを書き、レビュアーが読み、テスターが検証し、運用チームがデプロイする人間主導の連続ワークフロー向けに設計されました。 すべてのハンドオフは人間の著者と人間の速度の反復を前提としています。 AIコーディングアシスタントをこのモデルに組み込むと、プロセスが崩れ始めます。
なぜそうなのかを理解するには、AIの関与範囲を見てみましょう。
AI支援: 副操縦士は既存のSDLC段階内でのコード完了を提案します(狭すぎる)。
AI自律型: AIは最小限の人間のガバナンスで手を離してシステムを構築します(リスクが高すぎます)。
AI-DLC(中間の道): AI実行を支援するために、ライフサイクル自体を再構築し、厳格な人間の監督を得ています。
標準的な2週間のスプリントを考えてみましょう: AIエージェント コード、テスト、IaCを数日ではなく数時間で生成できるようになりました。 コードを書くことはもはや時間のかかるボトルネックではありません。 審査列やセキュリティゲートがそうです。 従来のSDLCがここで失敗するのは以下の点です:
スプリント計画はAIの処理能力ではなく、人間の能力に合わせて速度を調整します。
定期的な手動スキャン用に設計されたセキュリティゲートは、継続的なAI出力に追いつくことはできません。
人間のミスパターンに特化したレガシーテスト戦略は、AI特有の脆弱性クラスを見逃してしまう。
旧モデルはコードの速度が人間のタイピング速度に制限されると仮定しています。 新たな現実は、速度が審査、セキュリティ、ガバナンス能力によってのみ制限されるということです。
AI-DLCはどのように機能するのですか?
この手法は、AIがワークフローを開始しつつ、すべての段階で持続的なコンテキストを維持しつつ、3つのフェーズ(導入、構築、運用)で動作します。 これらは直線的な滝ではなく、連続したループを形成しています。
| Phase | AI role | Human role | Key artifacts | Security checkpoint |
|---|---|---|---|---|
| Inception | Generates plans, architecture proposals, user stories, clarifying questions | Validates direction, resolves ambiguities, approves plan | Specs, context documents, intent definitions | Review which services, data, and permissions the plan assumes |
| Construction | Writes code, generates tests, creates IaC templates, builds CI/CD configs | Reviews, steers, approves at defined checkpoints | Source code, test suites, IaC manifests, container images | Automated SAST, SCA, secrets, IaC scanning at every commit |
| Operations | Handles deployment orchestration, monitors runtime, detects anomalies | Approves production changes, escalates incidents | Deployment configs, monitoring dashboards, runbooks | Runtime validation that code behavior matches what was scanned |
設立
AI-DLCでは、モブの作り込みのような手法が導入されます。 AIエージェント 高度な人間の意図に基づいてプロジェクト計画、アーキテクチャ提案、ユーザーストーリー、明確化質問を生成します。 人間はコードを書く前に方向性を検証し、曖昧さを解決し、計画を承認します。
この段階では構造化仕様書やコンテキストドキュメントが作成され、構築段階に残り、AIエージェントが正しく構築するためのメモリとガードレールを提供します。 セキュリティ上の影響は非常に重要です。インセプションで下された決定(どのクラウドサービスを使うか、どのデータにアクセスするか、どのアイデンティティモデルに従うか)が、下流の攻撃面を定義します。 この段階でのセキュリティレビューにより、リスクのクラス全体がコードに到達するのを防ぎます。
建設
従来のスプリントは "ボルト、" (より短く、より集中的な作業サイクル)は週ではなく時間単位や日単位で測定されます。 この変化は手法を強調しています'スピードと継続的デリバリーへの重視。 モブの建設中、 AIエージェントはコードを書きますテストを生成し、IaCテンプレートを作成し、CI/CD構成を構築する間に、人間が指定されたチェックポイントでレビュー、ステアリング、承認を行います。
InceptionとConstructionの間に永続的なコンテキストフローが流れ、AIがアーキテクチャ上の決定、セキュリティ要件、ビジネス上の制約を見失うことはありません。 ここでのセキュリティ上の問題は単純明快です。AI生成コード、依存関係、IaCテンプレートはすべて、この段階で自動スキャンが必要です。なぜなら、量と速度が多すぎて手動で行ごとを確認するのは非現実的だからです。 AIエージェントが1日に数十件のプルリクエストを生成する場合、 SAST, SCA(ソフトウェア作文分析)、秘密検出、IaCスキャンが継続的に実行されます。
オペレーションズ
AI-DLCは展開や監視にも及びます。 AIエージェントが展開を担当します オーケストレーション、実行時の挙動を観察し、異常を検出し、是正策を提案します。 人間は、本番の変更やインシデントのエスカレーション決定のための承認ゲートを通じてガバナンスを維持します。
オペレーションフェーズでは、その学びをインセプションにフィードバックし、生産の洞察が将来の計画に反映されるクローズドループを作り出します。 本番環境で動作するAIエージェントは厳密に限定された権限を必要とし、ランタイムモニタリングはコードでスキャンされた内容がクラウド上で実行されているものと実際に一致しているかを検証しなければなりません。 リポジトリ内では無害に見えた脆弱性が、展開されたワークロードがインターネットにさらされ、高特権のアイデンティティで動作し、個人情報(PII)を保存するデータベースに到達できる場合に重大なものになる可能性があります。 そのため、コードの発見をランタイムのクラウドコンテキストに結びつけ、ワークロードを実際のアイデンティティにマッピングし、ネットワーク露出やデータアクセスを行うセキュリティプラットフォームは、AI-DLC運用に不可欠です。
AI-DLCとSDLC:主な違い
| Column A | Column B | New Column |
|---|---|---|
| Lifecycle model | Waterfall or agile stages | Continuous three-phase loop (Inception, Construction, Operations) |
| Code authorship | Human-written | AI-generated with human approval |
| Cycle time | Weeks (sprints) | Hours or days (bolts) |
| Roles | Developers write code | Developers review and steer AI output |
| Governance model | Periodic reviews and gates | Continuous automated checks with human approval gates |
| Security checkpoints | Periodic scans and gates | Embedded scanning at every phase plus runtime validation |
| Documentation | Human-authored specs | AI-generated specs validated by humans |
| Feedback loop | Retrospectives at sprint end | Continuous closed-loop from operations back to inception |
セキュリティチームにとって最も重要な違いはこれです。AIDLCはコードが人間がレビューするよりも速く生成されると想定しています。 つまり、セキュリティコントロールは自動化され、文脈に応じ、実行時の挙動と結びついていなければなりません。 定期的な手動レビューだけに頼るだけではうまくいきません。
AI-DLCの利点
AI主導の開発は、チームがこの手法を自動スキャン、承認ワークフロー、クラウドランタイムの可視性と組み合わせることで具体的な成果をもたらします。 これらの規制がなければ、発電速度が速くなることでリスクがパイプラインに速く流れ込むことになります。
配送サイクルを数週間から数時間に短縮する: AIは実行重視の作業(コーディング、テスト生成、IaCの作成)を担当するため、チームは計画やレビューを省くことなく迅速に出荷できます。
開発者の作業を単なるコーディングから創造的な問題解決へと昇華させる: 開発者は定型文を書くよりも、アーキテクチャ、デザインの決定、承認に時間を割くため、成果物の質や仕事の満足度が向上します。
AIによるパターンによる一貫性の向上: AIエージェントは毎回同じコーディング標準、セキュリティポリシー、アーキテクチャパターンを適用し、異なる開発者が異なる解釈でガイドラインを解釈する際のドリフトを減らします。
迅速な市場対応を可能にする: ゼロデイ脆弱性が開示されると、AIDLCチームは次のスプリントに修正を予定することなく、数時間で影響を受けたコンポーネントを再生成し、再スキャンし、再展開できます。
意図から展開までの組み込みトレーサビリティを確立します: AI-DLCは仕様、計画、コード、テスト結果、デプロイ設定など各段階で構造化された成果物を生成するため、チームは事後再構築ではなく、デフォルトで監査記録を得られます。
100 Experts Weigh In on AI Security
Learn what leading teams are doing today to reduce AI threats tomorrow.
AI-DLCのセキュリティリスクと課題
AI-DLCの最大の強み(速度)は、同時に最大のセキュリティ脆弱性でもあります。 コードが数週間ではなく数時間で出荷されると、設定ミスや漏洩した秘密が本番環境に速く届きます。 ウィズは 5つの最も一般的な検証された秘密のうち4つ 公開リポジトリで見つかったものはAI関連であり、プロンプトやAPIキーがソース管理にいかに速く漏れるかを示しています。
この膨大な量は人間のレビュー能力を簡単に超え、いくつかの特定のリスクカテゴリーを複雑にしています。
微妙なコードの脆弱性: AIはしばしば構文的に正しく基本的なリンティングを通過するコードを作成しますが、隠れた論理的欠陥や安全でないデフォルトを含んでいます。 (ある研究では、AI生成ファイル全体で4,241件のCWEインスタンスが特定されています。) これらを把握するには、AI搭載のSASTとランタイムコンテキストが必要です。
パッケージの幻覚によるサプライチェーン攻撃: AIエージェントは人間の審査を省き、依存関係を自律的に選択します。 AIパッケージの推奨の約20%が存在しない依存関係を参照しているため、攻撃者は以下を悪用できます。 "スロップスクワッティング" ソフトウェアのサプライチェーンを損なうためです。
スケールドインフラの誤構成: AIがIaCを生成する場合(TerraformやKubernetesのマニフェストなど)、公開されたS3バケットや過剰な権限を持つIAMロールのような単一のエラーが、誰にも気づかれないうちに数十回のデプロイに複製されることがあります。
CI/CD権限によるより広い爆風半径: AIエージェントは、ビルド、テスト、デプロイのために高度なパイプライン認証情報を必要とします。 これらの許可があまりにも広範囲であれば、幻覚や汚染された要因が広範囲にわたる環境被害を引き起こす可能性があります。
もっともらしいが欠陥のあるセキュリティ設定: AIの幻覚は、IAMポリシーや暗号化設定など、見た目は完全に正しいものの、不正なネットワーク侵入を許すなど微妙で重大なエラーを含むセキュリティルールを生成することがあります。
実際の様子は以下の通りです: AIエージェントはコンテナ化されたマイクロサービスを生成し、既知のCVEを持つベースイメージを選択し、公開用のロードバランサーをプロビジョニングし、機密データストアへのアクセスを持つ過剰特権のサービスアカウントを接続し、すべて自動化されたパイプラインを通じて展開します。 各アーティファクトは狭いスキャンを通過するかもしれませんが、その組み合わせがコード、クラウド、アイデンティティ、データのコンテキストをつなげたときにのみ見える重要な攻撃経路を生み出します。
純粋なセキュリティを超えて、AI-DLCへの移行はより広範な組織上の障壁をもたらします。
作戦準備態勢: チームはAI実行者を効果的に管理・統治するために新しいスキルとワークフローを身につけなければなりません。
コードからクラウドへのトレーサビリティ: NISTのAIリスク管理フレームワークEU AI法およびSOC 2 Type IIは厳格な出所追跡の施行を開始しています。 規制当局は現在、機械が作成したものと人間が承認したものを正確に証明するために、明確な監査記録を求めています。
AI主導の開発ライフサイクルの確保
もしスキャンが夜のクローンジョブで動いているのに、AIエージェントが毎時間コードを送っているなら、ギャップができます。 セキュリティ管理はAI主導の開発と同じ速度で動作しなければなりません。
事前展開だけでなく、すべての段階での自動スキャン: SAST、SCA、シークレット検出、IaCスキャン、機密データスキャンはIDE内で、PR時に、CI/CDで、そして本環境で継続的に実行されなければなりません。 これがAI生成のペースに匹敵する唯一の方法です。
実行時の検証は、コードの発見を実際のデプロイ曝露に結びつけます: コードリポジトリの脆弱性は理論上のもので、そのコードがデプロイされているか、ワークロードがインターネットに露出しているか、どのアイデンティティ権限を持っているか、どのデータにアクセスできるかがわかりません。 セキュリティプラットフォームはコードの発見を実際のクラウド環境にマッピングする必要があります。
AI搭載のトリアージが、コード量に合わせて調査をスケールアップします: AIが1日に何百件もの発見を生成するため、人間のレビュアーはすべてをトリアージすることはできません。 発見が悪用可能である理由(または誤検知の可能性が高いとマークする)AI支援のトリアージが不可欠になります。
ガバナンスとコンプライアンスのためのコード・トゥ・クラウド・トレーサビリティ: 規制当局や監査人は、配布されたアーティファクトをそのソースリポジトリ、生成したAIエージェント、承認した人間、そしてそれを統治するポリシーにたどり着く必要があります。 このチェーンを自動的に維持する統合プラットフォームは非常に重要です AI-DLCガバナンス.
AIエージェント自身の最小権限の強制: CI/CDパイプラインやクラウド環境で動作するAIエージェントは厳密に限定された認証情報が必要であり、セキュリティチームはエージェントが持つ権限と実際に何をしているかを可視化する必要があります。
AI-DLCが求めるアーキテクチャは、コード、クラウド、アイデンティティ、データのコンテキストを単一のリスクモデルに関連付ける統一プラットフォームです。 その相関関係がなければ、セキュリティチームは孤立状態で調査結果をトリアージし、重要な本番環境への露出と無害な開発部門のアーティファクトを区別できません。
次のようなシナリオを考えてみましょう:セキュリティチームが SAST AI生成コードにおけるSQL注入の検出。 クラウドコンテキストがなければ、コードがデプロイされているのか、ワークロードがインターネット対応なのか、PII付きのデータベースにアクセスできるのかも分かりません。 コードをクラウドにマッピングするプラットフォームがあれば、脆弱なコードが公開コンテナで動作し、本番データベースにアクセスできるため重要な優先度となっているか、あるいはデプロイされていない開発部門にしか存在せず優先度が低いことを即座に見分けることができます。
ウィズ'AIDLCの確保アプローチ
AIエージェントがコードを生成し、依存関係をプルし、インフラをプロビジョニングし、本番環境に展開するなら、エンドツーエンドで同じ経路をたどるセキュリティが必要です。
WizはAIアプリケーション保護プラットフォームを通じてAI開発ライフサイクル全体を保護しています(AI-APP).
このコード・トゥ・クラウドのアプローチは統合されています ウィズコード (アプリケーションおよびサプライチェーンセキュリティ)、 AI-SPM (姿勢/在庫管理)、および ウィズ・ディフェンド (ランタイム保護)を統合した可視性とリスク優先順位付けを提供する AIパイプライン全体にわたって。
ウィズ'Sのゼロ設定コードからクラウドへのマッピングは、ソースコードをCIパイプラインからコンテナレジストリ、さらには実行中のワークロードへと自動的に追跡します。 すべてのコード発見はクラウドのコンテキストで豊かになります。このコードは実際に展開されているのでしょうか? 作業量はインターネットに露出していますか? どんなアイデンティティ権限を持っているのでしょうか? どのようなデータにアクセスできるのでしょうか?
Wizセキュリティグラフはこれらのシグナルを統合されたリスクモデルに結びつけています。 個別の発見をトリアージする代わりに、セキュリティチームは既知のCVEを持つAI生成コンテナ、公開エンドポイント、過剰な特権を持つサービスアカウント、機密データへのアクセスなど、有害な組み合わせを目にします。 これは、数千件のアラートのリストと、実際に重要な問題の短いキューとの違いです。
AI-DLCが生み出す大量のコードレベルの成果に対して、Wizは'AI搭載のSASTトリアージエージェントは、発見が悪用可能である理由を説明したり、誤検知の可能性をマークします。 これにより、1日に数百件のAI生成結果を手作業でレビューする手間を管理可能な数に削減できます。
Wizはまた、AIコーディングエージェント向けのプラグインを通じて、脆弱なコードが本番環境に届くのを防ぐのを支援しています。 これらのプラグインはコード生成後にSCA、SAST、シークレット、IaCスキャンをオーケストレーションし、チームが問題を事前に発見しやすいタイミングで修正できるようにします。
Green Agentを活用し、Wizは脆弱性修復を直接エージェントワークフローに注入します。 既に存在する問題については、セキュリティチームがグリーンエージェントにAIコーディングエージェントに修復コマンドを送るよう指示できます。 開発側からは、開発チームはWizスキルを使って既存の課題を直接IDEやCLIに取り込み、重大な問題の詳細なリストを取得し、グリーンエージェントの提案に基づいて自動的に修正を適用できます。
Wiz AI SPMは、実際のリスクを理解するために必要なクラウドコンテキストでモデル、パイプライン、推論サービスへの可視性を提供することで、AIアプリケーションにもこの保護を拡張しており、それが助けとなりました コンベルソはクリティカルゼロを達成します GenAIプラットフォームのために。
コードからクラウドまでAI駆動の開発ライフサイクルを安全に守る準備はできましたか? デモの予約をしてください Wizがコード、クラウド、ランタイムのコンテキストをどのように統一リスクモデルに結びつけ、チームが本番環境で実際に重要なエクスポージャーに集中できるようにしているかを見てみましょう。
Develop AI applications securely
Learn why CISOs at the fastest growing organizations choose Wiz to secure their organization's AI infrastructure.
