
AI-DLC v2 で逆解析→設計→コード生成のワークフローを一通り試してみた
はじめに
前回の記事では、AI-DLC の逆解析スキルを使って既存 Lambda の現状仕様をドキュメント化しました。その後のテスト導入や改善は、AI-DLC のワークフロー外で Kiro CLI に個別に指示して実施しました。
本記事では、逆解析で生成した成果物を AI-DLC v2 の orchestrator に渡し、要件定義からコード生成までを一連のワークフローとして実行しました。対象は、公開されている Lambda Function URL を CloudFront OAC で保護し、あわせて Lambda コードで機密ヘッダーを除外する改善です。
実環境へのデプロイや動作確認は本記事の範囲外とし、AI-DLC v2 が生成した設計・コードを中心に確認します。
なお、AI-DLC v2 の逆解析成果物が設計フォーマットに揃っていることは、別記事で扱っています。
題材: 公開 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分で完了)
- SKILL.md を読み込み — 出力フォーマット・チャンク戦略を理解
- before.yaml を読み込み — 対象の規模を判定(1ファイル・4リソース → シングルチャンク)
- clarification(3問) — 解析深度・用途・命名規則を確認(自己回答で進行)
- plan 作成 — 生成するファイルを決定(条件付きファイルの要否判断含む)
- 成果物生成 — 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(直接アクセスの遮断方法)では、以下の選択肢が提示されました:
- OAC + AuthType: AWS_IAM + Resource Policy(推奨)— カスタムコード不要、AWS 管理の署名
- Lambda コード内でカスタムヘッダーを検証 — 実装は簡単だが、ヘッダー値の漏洩リスクあり
- 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 はnoneかwhitelistのみで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 |
参考リンク









