AI-DLC v2 で逆解析→設計→コード生成のワークフローを一通り試してみた

AI-DLC v2 で逆解析→設計→コード生成のワークフローを一通り試してみた

Kiro CLI 上で AI-DLC v2 の orchestrator に逆解析結果と改善 intent を渡し、要件定義→設計→コード生成を一連のワークフローで完走させました。題材は CloudFront OAC による Lambda Function URL の保護で、人間がやったのは intent の投入と各フェーズの承認です。
2026.06.02

はじめに

前回の記事では、AI-DLC の逆解析スキルを使って既存 Lambda の現状仕様をドキュメント化しました。その後のテスト導入や改善は、AI-DLC のワークフロー外で Kiro CLI に個別に指示して実施しました。

https://dev.classmethod.jp/articles/ai-dlc-reverse-engineering-vibe-lambda/

本記事では、逆解析で生成した成果物を AI-DLC v2 の orchestrator に渡し、要件定義からコード生成までを一連のワークフローとして実行しました。対象は、公開されている Lambda Function URL を CloudFront OAC で保護し、あわせて Lambda コードで機密ヘッダーを除外する改善です。

実環境へのデプロイや動作確認は本記事の範囲外とし、AI-DLC v2 が生成した設計・コードを中心に確認します。

なお、AI-DLC v2 の逆解析成果物が設計フォーマットに揃っていることは、別記事で扱っています。

https://dev.classmethod.jp/articles/ai-dlc-reverse-engineering-v1-v2-structure-comparison/


題材: 公開 Lambda Function URL

検証用の CloudFormation テンプレート(before.yaml)です。4リソース・約60行の小規模スタックで、リクエストのヘッダーとソース IP をそのまま返す Lambda を認証なしで公開しています。

before.yaml(全文)
AWSTemplateFormatVersion: '2010-09-09'
Description: Public Lambda Function URL - Echo headers and source IP (intentionally unprotected)

Resources:
  LambdaRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Sub '${AWS::StackName}-lambda-role'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

  EchoFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: !Sub '${AWS::StackName}-echo'
      Runtime: python3.13
      Handler: index.handler
      Role: !GetAtt LambdaRole.Arn
      Code:
        ZipFile: |
          import json

          def handler(event, context):
              return {
                  "statusCode": 200,
                  "headers": {"Content-Type": "application/json"},
                  "body": json.dumps({
                      "sourceIp": event["requestContext"]["http"]["sourceIp"],
                      "headers": event["headers"]
                  }, indent=2)
              }

  FunctionUrl:
    Type: AWS::Lambda::Url
    Properties:
      AuthType: NONE
      TargetFunctionArn: !GetAtt EchoFunction.Arn

  FunctionUrlPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunctionUrl
      FunctionName: !GetAtt EchoFunction.Arn
      Principal: '*'
      FunctionUrlAuthType: NONE

Outputs:
  FunctionUrlEndpoint:
    Description: Public Function URL endpoint
    Value: !GetAtt FunctionUrl.FunctionUrl

ポイントは AuthType: NONE + Principal: '*' — URL を知っていれば誰でも直接アクセスできる状態です。本記事の改善は、この Function URL への直接アクセスを CloudFront OAC で制限し、あわせてレスポンスから機密ヘッダーを除外するものです。CloudFront Distribution 自体にエンドユーザー認証を追加するものではなく、CloudFront 経由では引き続き誰でもアクセスできます。


逆解析を実行する

事前準備

AI-DLC v2 を使うには、ワークスペースに .kiro/ ディレクトリ(スキル定義一式)が必要です。

# aidlc-workflows リポジトリから .kiro/ を取得
git clone -b v2 https://github.com/awslabs/aidlc-workflows.git
cp -r aidlc-workflows/dist/kiro/.kiro /path/to/workspace/

配置後のワークスペース:

workspace/
├── .kiro/
│   ├── skills/            ← AI-DLC v2 スキル定義(16スキル)
│   ├── aidlc-common/      ← 共通プロトコル・規約
│   ├── hooks/             ← プロセスチェックフック
│   └── agents/            ← builder / validator エージェント
└── before.yaml            ← 逆解析対象

逆解析の実行

kiro-cli chat --model claude-sonnet-4-6 -a

投入したプロンプト:

/skill aidlc-reverse-engineering --scope before

before.yaml を逆解析してください。公開 Lambda Function URL のエコーサービスです。

逆解析の動作(≈3分で完了)

  1. SKILL.md を読み込み — 出力フォーマット・チャンク戦略を理解
  2. before.yaml を読み込み — 対象の規模を判定(1ファイル・4リソース → シングルチャンク)
  3. clarification(3問) — 解析深度・用途・命名規則を確認(自己回答で進行)
  4. plan 作成 — 生成するファイルを決定(条件付きファイルの要否判断含む)
  5. 成果物生成 — 12ファイルを出力

生成された成果物(12ファイル)

inception/reverse-engineering/before/
├── reverse-engineering-questions.md  ← clarification の記録
├── reverse-engineering-plan.md       ← 何を生成するかの計画
├── technology-stack.md               ← Python 3.13, CFn, Lambda Function URL
├── code-structure.md                 ← 単一テンプレートの構造
├── components.md                     ← 3コンポーネント
├── component-methods.md              ← 各コンポーネントの操作
├── component-dependencies.md         ← 依存関係
├── services.md                       ← HTTP エコーサービス
├── cross-cutting.md                  ← 認証なし(意図的)を事実記録
├── api-contracts.md                  ← Lambda Function URL HTTP API
├── external-dependencies.md          ← AWS サービス依存
└── code-quality-assessment.md        ← Anti-Pattern: 公開エンドポイント

条件付きファイルの判断も行われました:

  • api-contracts.md生成(HTTP API あり)
  • external-dependencies.md生成(AWS サービス依存あり)
  • data-models.mdスキップ(永続化なし)
  • event-catalog.mdスキップ(イベント駆動なし)

逆解析が検出した「穴」

code-quality-assessment.md より:

Issue Severity Description
認証なし公開エンドポイント High(意図的) AuthType: NONE + Principal: '*'
機密ヘッダーの反射 High Authorization 等の機密ヘッダーを含む全ヘッダーをレスポンスに含める
例外処理なし High KeyError が発生し Lambda ランタイムがエラーを返す

逆解析スキルは事実を記録するだけで、改善提案は行いません。「何をどう直すか」は次のステップで人間が判断し、orchestrator に指示します。


orchestrator に改善を指示する

逆解析が完了した同じワークスペースで、orchestrator に改善の意図(intent)を伝えます。orchestrator は intent 成果物を org-ai-kb/aidlc-docs/intent-001-.../ 配下に独立管理します。

投入したプロンプト:

/skill aidlc-orchestrator

逆解析結果を基に、before.yaml に以下の改善を行いたい。

1. 公開 Lambda Function URL を CloudFront OAC で保護する(AuthType: AWS_IAM + OAC)
2. キャッシュ TTL は1分程度を設定し、同一端末からの短時間の大量リクエストがオリジンに届かないようにする。キャッシュヒット率は重視しない
3. User-Agent 等のオリジナルリクエストヘッダーはオリジンに通過させる
4. Lambda コードで、レスポンスに含めるヘッダー一覧から機密情報(Authorization、Cookie 等)を除外する

Workflow Composition

orchestrator が改善に必要なスキルチェーンを compose した結果です:

# Inception phase
requirements-analysis → application-design

# Construction phase (single unit: cloudfront-oac-stack)
nfr-assessment → infrastructure-design → code-generation

スキップされたフェーズ(workflow-rationale.md より):

スキップ 理由
reverse-engineering 既に完了済み
user-stories 新規ユーザー向け動作変更なし
functional-design 新規ドメインロジックなし(ヘッダーフィルタリングは trivial)
build-and-test CATALOGUE 上「🚧 Not yet implemented」

セキュリティ改善を目的とした intent であるため、OWASP レンズは自動有効化されました。

intent に Lambda コード変更を明示したことで、orchestrator は application-design を実行する判断をしました(CloudFront 追加 + Lambda コード変更 = コンポーネント境界変更)。intent の具体度がワークフロー構成に影響する一例です。


Requirements Analysis

orchestrator が 6つの確認事項 を提示し、人間が設計判断を確定しました。各質問には Recommendation(推奨)と他の選択肢が付与されています:

Q 内容 回答
Q1 単一テンプレートで完結するか はい、after.yaml 1ファイルに全リソース
Q2 レスポンスから除外するヘッダーの範囲 Authorization, Cookie, Set-Cookie の3つ
Q3 直接アクセスの遮断方法 Function URL を AWS_IAM に変更し、Lambda Permission を cloudfront.amazonaws.com + SourceArn に限定
Q4 CloudFront ドメイン デフォルト(*.cloudfront.net)のみ
Q5 エラーハンドリング 最小限の try-except のみ追加
Q6 キャッシュキーポリシー 全クエリ文字列をキャッシュキーに含める。ヘッダーはキャッシュキーに含めず、OriginRequestPolicy でオリジンに転送

たとえば Q3(直接アクセスの遮断方法)では、以下の選択肢が提示されました:

  1. OAC + AuthType: AWS_IAM + Resource Policy(推奨)— カスタムコード不要、AWS 管理の署名
  2. Lambda コード内でカスタムヘッダーを検証 — 実装は簡単だが、ヘッダー値の漏洩リスクあり
  3. WAF で IP 制限 — CloudFront エッジ IP の管理が必要

推奨に同意するだけで進められますが、他の選択肢とトレードオフを確認できる点が orchestrator を通す利点です。承認後、requirements.md が生成されました:

機能要件(FR)

# 内容
FR-1 CloudFront Distribution を新規作成し、Lambda Function URL をオリジンとする
FR-2 Lambda Function URL の AuthType を NONE → AWS_IAM に変更
FR-3 OAC(type: lambda, signing: always)を作成し Distribution に関連付け
FR-4 カスタム CachePolicy を作成(MinTTL=DefaultTTL=MaxTTL=60秒)
FR-5 OriginRequestPolicy で Host 以外の全ビューワーヘッダーをオリジンに転送
FR-6 全クエリ文字列をキャッシュキーに含め、オリジンにも転送
FR-7 Lambda ハンドラーで Authorization, Cookie, Set-Cookie をレスポンスボディから除外
FR-8 Lambda ハンドラーに最小限の try-except を追加(500 レスポンス)
FR-9 Lambda Permission で cloudfront.amazonaws.com + SourceArn に限定
FR-10 全リソースを単一テンプレート after.yaml に収める

非機能要件(NFR)

# 内容
NFR-1 Cache TTL は厳密に60秒(MinTTL=DefaultTTL=MaxTTL=60)
NFR-2 CloudFront → Lambda 間は HTTPS-only
NFR-3 レスポンスに Authorization, Cookie, Set-Cookie を含めない
NFR-4 出力テンプレートは有効な CloudFormation 構文であること

Application Design + NFR Assessment

requirements の出力を受けて、application-design が論理コンポーネントを定義し、NFR Assessment が技術選定を確定しました。

Application Design の clarification(3問)

Q 内容 回答
Q1 エラーレスポンスの JSON 形式 {"error": "Internal Server Error"} + Content-Type: application/json
Q2 ヘッダー除外スコープ HTTP レスポンスヘッダーと JSON ボディ内エコー結果の両方から除外
Q3 直接アクセスパスの保持 完全プライベート。全外部トラフィックはエッジプロキシ経由のみ

コンポーネント一覧

# Component Role State
1 EdgeProxy ビューワーリクエストを受け、キャッシュとアクセス制御を適用 New
2 OriginAccessControl エッジプロキシからオリジンへのリクエストを署名 New
3 EchoHandler サニタイズ済みヘッダーとソース IP をエコー Modified
4 AccessPolicy ハンドラー呼び出しを認可済み呼び出し元のみに制限 New
5 CachePolicy エッジプロキシのキャッシュ動作(TTL・キャッシュキー)を定義 New

EchoHandler が「Modified」— 機密ヘッダー除外 + try-except の追加が設計段階で明示されています。

NFR Assessment の clarification(4問)

Q 内容 回答
Q1 サービス分類 非クリティカルな診断サービス。ベストエフォート可用性
Q2 レイテンシ目標 キャッシュミス ≤1s (p99)、キャッシュヒット ≤50ms
Q3 可観測性要件 CloudWatch Logs のみ
Q4 技術制約 インライン ZipFile + 単一テンプレート

Q3 では「CloudFront 標準アクセスログも追加する」選択肢が提示されましたが、S3 バケット依存が増えるため今回は見送りました。本番運用に移行する場合はここで別の判断になります。

Tech Stack Decisions

TSD 決定 根拠
TSD-1 CloudFormation 単一テンプレート維持 Brownfield。NFR-4
TSD-2 Python 3.13 インライン ZipFile 既存ハンドラーと同一
TSD-3 Amazon CloudFront OAC ネイティブサポート。NFR-1, NFR-2
TSD-4 OAC (lambda, sigv4, always) Fail-closed。NFR-2, NFR-3
TSD-5 カスタム CachePolicy(TTL 60s 固定) NFR-1。バースト保護目的
TSD-6 AllViewerExceptHostHeader マネージドポリシー Host 以外の全ビューワーヘッダーをオリジンに転送。FR-5

Infrastructure Design + Code Generation

NFR Assessment の TSD を受けて infrastructure-design が8コンポーネントのインフラ設計を生成し、続いて code-generation が CFn テンプレートを出力しました。

Infrastructure Design の clarification(3問)

Q 内容 回答
Q1 リージョン デフォルト us-east-1
Q2 CloudFront PriceClass PriceClass_100
Q3 Viewer protocol policy redirect-to-https

設計されたコンポーネント(8リソース)

CFn論理ID 変更
Distribution 新規 — PriceClass_100, AllViewerExceptHostHeader OriginRequestPolicy, OAC 関連付け
OriginAccessControl 新規 — type: lambda, signing: always, sigv4
CachePolicy 新規 — TTL 60s 固定、キャッシュキー = URL + 全クエリ文字列(端末単位ではなくキャッシュキー単位でバースト抑制)
EchoFunction 変更 — 機密ヘッダー除外 + try-except
FunctionUrl 変更 — AuthType: NONE → AWS_IAM
FunctionUrlPermission 変更 — Principal: '*' → cloudfront.amazonaws.com + SourceArn
FunctionInvokePermission 新規 — cloudfront.amazonaws.com + SourceArn
LambdaRole 変更なし

CachePolicy のキャッシュキー設計

infrastructure-design.md にトレードオフが記載されています:

キャッシュキーにヘッダーを含めない(HeaderBehavior: none)。CachePolicy の HeaderBehavior は nonewhitelist のみで allViewer がない。OriginRequestPolicy(AllViewerExceptHostHeader)はキャッシュミス時に Host 以外の全ヘッダーをオリジンに転送するが、キャッシュキーには含まれない。

結果: 同一 URL + 同一クエリ文字列で異なるヘッダーのリクエストは、60秒 TTL 内では同じキャッシュレスポンスを返す。キャッシュヒット時はオリジンにリクエストが届かないため、intent で指定した「ヘッダーをオリジンに通過させる」はキャッシュミス時のみ成立する。なお、キャッシュ対象はデフォルトの GET/HEAD のみであり、POST 等の非冪等メソッドはキャッシュされずオリジンに到達する。

許容理由: (1) 主目的はバースト保護であり、リクエストごとのヘッダー反映ではない、(2) 60s TTL で陳腐化は限定的、(3) 診断ツールでありヒット率は非重視。

トラストバウンダリー

Internet (untrusted)
    │ HTTPS

Distribution ──OAC SigV4署名──► FunctionUrl (AWS_IAM)
  PriceClass_100                    │
  CachePolicy (TTL 60s)       FunctionUrlPermission
  AllViewerExceptHostHeader   (SourceArn で特定 Distribution に限定)


                               EchoFunction
                               (機密ヘッダー除外 + try-except)

AuthType: AWS_IAM(未署名リクエストを拒否)、Resource Policy(SourceArn で Distribution 限定)、OAC SigningBehavior: always(常に署名)の3点で直接アクセスを制限しています。

生成されたテンプレート

code-generation は infrastructure-design の設計に基づき after.yaml を生成しました。

Lambda ハンドラーの変更(diff):

  Code:
    ZipFile: |
      import json
-     def handler(event, context):
-         return {
-             "statusCode": 200,
-             "headers": {"Content-Type": "application/json"},
-             "body": json.dumps({
-                 "sourceIp": event["requestContext"]["http"]["sourceIp"],
-                 "headers": event["headers"]
-             }, indent=2)
-         }
+
+     SENSITIVE_HEADERS = {'authorization', 'cookie', 'set-cookie'}
+
+     def handler(event, context):
+         try:
+             headers = event.get('headers', {})
+             filtered = {k: v for k, v in headers.items() if k.lower() not in SENSITIVE_HEADERS}
+             return {
+                 'statusCode': 200,
+                 'headers': {'Content-Type': 'application/json'},
+                 'body': json.dumps({
+                     'sourceIp': event['requestContext']['http']['sourceIp'],
+                     'headers': filtered
+                 }, indent=2)
+             }
+         except Exception:
+             return {
+                 'statusCode': 500,
+                 'headers': {'Content-Type': 'application/json'},
+                 'body': json.dumps({'error': 'Internal Server Error'})
+             }

変更点: (1) SENSITIVE_HEADERS セットで除外対象(authorization, cookie, set-cookie)を定義、(2) event["headers"] → フィルタ済み filtered に置換、(3) try-except で 500 レスポンスを返す

CloudFront + OAC + CachePolicy(新規追加):

before.yaml には存在しなかったリソースです。OAC による署名、60秒キャッシュ、Distribution の構成が追加されています。

  OriginAccessControl:
    Type: AWS::CloudFront::OriginAccessControl
    Properties:
      OriginAccessControlConfig:
        Name: !Sub '${AWS::StackName}-oac'
        OriginAccessControlOriginType: lambda
        SigningBehavior: always
        SigningProtocol: sigv4

  CachePolicy:
    Type: AWS::CloudFront::CachePolicy
    Properties:
      CachePolicyConfig:
        Name: !Sub '${AWS::StackName}-cache-policy'
        MinTTL: 60
        DefaultTTL: 60
        MaxTTL: 60
        ParametersInCacheKeyAndForwardedToOrigin:
          HeadersConfig:
            HeaderBehavior: none
          QueryStringsConfig:
            QueryStringBehavior: all
          CookiesConfig:
            CookieBehavior: none
          EnableAcceptEncodingGzip: true
          EnableAcceptEncodingBrotli: true

  Distribution:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        Enabled: true
        HttpVersion: http2
        PriceClass: PriceClass_100
        Origins:
          - Id: LambdaOrigin
            DomainName: !Select [2, !Split ['/', !GetAtt FunctionUrl.FunctionUrl]]
            CustomOriginConfig:
              OriginProtocolPolicy: https-only
              HTTPSPort: 443
            OriginAccessControlId: !GetAtt OriginAccessControl.Id
        DefaultCacheBehavior:
          TargetOriginId: LambdaOrigin
          ViewerProtocolPolicy: redirect-to-https
          CachePolicyId: !Ref CachePolicy
          OriginRequestPolicyId: b689b0a8-53d0-40ab-baf2-68738e2966ac
          AllowedMethods: [GET, HEAD, OPTIONS, PUT, PATCH, POST, DELETE]

  FunctionUrlPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunctionUrl
      FunctionName: !GetAtt EchoFunction.Arn
      Principal: cloudfront.amazonaws.com
      SourceArn: !Sub 'arn:aws:cloudfront::${AWS::AccountId}:distribution/${Distribution}'
      FunctionUrlAuthType: AWS_IAM

  FunctionInvokePermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !GetAtt EchoFunction.Arn
      Principal: cloudfront.amazonaws.com
      SourceArn: !Sub 'arn:aws:cloudfront::${AWS::AccountId}:distribution/${Distribution}'
      InvokedViaFunctionUrl: true

OriginRequestPolicyId: b689b0a8-... は AWS マネージドの「AllViewerExceptHostHeader」ポリシーです。User-Agent 等のビューワーヘッダーをオリジンに転送しつつ、Host ヘッダーは除外します。

build-and-test スキルは CATALOGUE 上「🚧 Not yet implemented」とされているためスキップされました。一方で、code-generation 内の verification criteria では10項目が確認済みとして記録されています。


注意事項とまとめ

orchestrator の clarification は推奨に同意するだけでも先へ進められます。また、質問の内容を読むだけでも、設計上の見落としや他の選択肢に気づく契機になります。

clarification 気づきの内容
Q2(除外ヘッダー範囲) Set-Cookie も除外対象であること。漏れるとセッション情報がレスポンスに残る
Q3(直接アクセス制限) ヘッダー検証ではなく AuthType + Permission で制御すべきこと
Q6(キャッシュキー設計) CachePolicy の HeaderBehavior に allViewer がない制約。知らずに設計すると意図と乖離する
App-Q2(除外スコープ) HTTP レスポンスヘッダーだけでなく JSON ボディ内のエコー結果にも機密情報が含まれること

逆解析の出力を起点に orchestrator へ intent を渡すことで、要件定義からコード生成までを一連のワークフローとして実行できました。4点を明示した intent を渡したことで、orchestrator は Lambda コード変更を含むフルフローを構成し、application-design も実行しています。今回のようにアプリケーションコードとインフラ(特に CDN のキャッシュキー設計やオリジン認証)が相互に依存する変更では、設計判断の整合性を各フェーズで検証しながら進められる点で、有効性が高いアプローチだと感じました。また、NFR Assessment で可観測性やレイテンシ目標など、機能実装に集中すると見落としがちな非機能要件を設計段階でチェックできる点も利点です。

一方で、すべての変更に orchestrator を通す必要はありません。方針が明確で clarification の余地が少ない小規模修正や、まず実験してから設計を固めたい場合は、先に変更を加えてから逆解析で仕様書を実態に追従させる進め方も選択肢になります。前回の記事のアプローチはこの形です。設計判断を明示しながら進めたい変更は orchestrator に渡し、探索的な小規模変更は直接実装してから逆解析で取り込む、という使い分けがしやすいと感じました。

参考として、同じ before.yaml に対して Kiro CLI に直接プロンプトを渡した場合の結果を示します。

before.yaml の Lambda Function URL を CloudFront OAC で保護してください。

- FunctionUrl の AuthType を AWS_IAM に変更
- OAC (type: lambda, signing: always) を作成
- CloudFront Distribution を作成し、Function URL をオリジンにする
- CachePolicy は TTL 60秒固定、クエリ文字列は全てキャッシュキーに含める
- OriginRequestPolicy は AllViewerExceptHostHeader
- Lambda Permission は cloudfront.amazonaws.com + SourceArn に限定
- Lambda ハンドラーで Authorization, Cookie, Set-Cookie をレスポンスから除外
- 最小限の try-except を追加
- 結果を after.yaml として出力

PriceClass_100、redirect-to-https で。

Claude Sonnet 4.6 で 29秒 で after.yaml が生成されました。機能的にはほぼ同等のテンプレートですが、lambda:InvokeFunction の Permission が含まれていませんでした。Lambda Function URL は 2025年10月のポリシー変更で lambda:InvokeFunctionUrl に加えて lambda:InvokeFunction も必要になっています(猶予期間は2026年11月まで)。現時点では動作しますが、猶予期間終了後は動作しなくなるテンプレートです。orchestrator 版ではこの Permission が設計段階で含まれていました。

orchestrator 経由 直接指示
所要時間 AI処理≈30分 29秒
成果物 設計文書一式 + after.yaml after.yaml のみ
設計判断の記録 clarification・requirements・TSD として残る チャット履歴のみ
lambda:InvokeFunction 設計段階で含まれていた 欠落(猶予期間終了後に動作しなくなる)

検証環境

項目
AI-DLC awslabs/aidlc-workflows branch: v2, commit: 47b4edcf (2026-05-29)
Kiro CLI v2.5.0
モデル Claude Sonnet 4.6(--model claude-sonnet-4-6
OS Fedora Linux Asahi Remix 43 (aarch64)
検証日 2026-05-31

参考リンク

https://github.com/awslabs/aidlc-workflows/tree/v2

https://dev.classmethod.jp/articles/ai-dlc-reverse-engineering-v1-v2-structure-comparison/

https://dev.classmethod.jp/articles/ai-dlc-reverse-engineering-vibe-lambda/

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-lambda.html

https://dev.classmethod.jp/articles/aws-lambda-function-url-change-policy/


生成AI活用はクラスメソッドにお任せ

過去に支援してきた生成AIの支援実績100+を元にホワイトペーパーを作成しました。御社が抱えている課題のうち、どれが解決できて、どのようなサービスが受けられるのか?4つのフェーズに分けてまとめています。どうぞお気軽にご覧ください。

生成AI資料イメージ

無料でダウンロードする

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事