AWS Console-to-Codeとは?対応サービス・生成形式・無料枠の実際【2026年版】
AWSマネジメントコンソールで作った検証環境を、そのまま本番用のコードに落とし込みたい。その入口になるのがAmazon Q Developerの機能であるConsole-to-Codeです。2023年11月のプレビュー公開を経て2024年10月10日に一般提供が始まり、その後も記録できるサービスが増えています。ここでは2026年8月時点の公式ドキュメントをもとに、記録できるサービス、生成できるコード形式、必要なIAM権限、そして情報が錯綜しがちな無料枠の実際を整理します。既存リソースのコード化を担うCloudFormation IaC generatorとの役割分担まで踏み込みます。
まとめ
- Console-to-CodeはAmazon Q Developerの機能で、コンソール操作を記録し、AWS CLIコマンドとIaCコードを生成します。2024年10月10日に一般提供が始まり、その発表では全商用リージョンで利用できるとされています。
- 記録できるのはAmazon EC2・Amazon VPC・Amazon RDS・Amazon DynamoDB・Amazon Cognito・AWS IoTの6サービスです(2026年8月時点の公式ドキュメント)。DynamoDBは2025年8月6日に追加されました。
- 生成形式はCDK(Java・Python・TypeScript)とCloudFormation(JSON・YAML)の5種類。CLIコマンドは記録一覧からコピーでき、AWS CloudShellでそのまま実行できます。
- CLIコマンドの取得に月間の固定上限はありませんが、CDK・CloudFormationのコード生成には月間上限があります。一般提供の発表時点では月25回で、現在の料金ページにはConsole-to-Codeの行がないため、回数は公式ページで都度確認してください。
- すでに動いている既存リソースをコード化する用途はConsole-to-Codeの守備範囲外です。CloudFormation IaC generatorのリソーススキャン、またはcdk migrateを使います。
Console-to-Codeの現在地と記録対象サービス
Console-to-CodeはAmazon Q Developerの一機能として提供され、コンソールでの操作を記録したうえで、生成AIが同等のAWS CLIコマンドとIaCコードを提案します。単体サービスではないため、料金も権限もAmazon Q Developerの枠組みに従います。Amazon Q Developer全体の機能構成はAmazon Q Developerの主要機能と特徴:開発支援の新しい形で確認できます。
記録できるAWSサービスと追加の経緯
一般提供の開始時点で対応していたのはAmazon EC2・Amazon RDS・Amazon VPCの3つでした。2026年8月時点の公式ドキュメントでは、これにAmazon DynamoDB・Amazon Cognito・AWS IoTが加わり6サービスになっています。DynamoDBについては2025年8月6日のWhat’s Newで追加が告知され、商用リージョンで一般提供されています。ただし同じドキュメント内の操作手順は「Amazon VPC、Amazon RDS、Amazon EC2のいずれかのコンソールへ」という一般提供当初の3サービス表記のまま更新されていません。手順ページだけを読むと対応範囲を狭く見誤ります。
対応サービスのコンソールを横断しても、記録は1本にまとまります。Amazon VPCでサブネットとセキュリティグループを作り、Amazon EC2でインスタンスを起動し、Amazon RDSでDBインスタンスを配置する、という一連の流れを1つの記録として扱えます。サービスごとに記録を取り直す必要はありません。
記録セッションが終わる条件
Console-to-Codeのサイドパネルは自前の状態を持ち、ブラウザタブが開いている間はコンソール内を移動しても記録を保持します。セッションが終わるのは、ブラウザタブを閉じたときか、AWSマネジメントコンソールのセッションが切れたときのどちらか早い方です。つまり、長い構築作業をタブを閉じながら小分けに進めると記録が失われます。作業単位を1タブ・1セッションに収める前提で段取りを組んでください。
なお、記録そのものに追加料金は発生しませんが、記録中に作成したリソースの料金は通常どおり請求されます。EC2インスタンスの起動を記録すれば、そのインスタンス代はかかります。
生成できるコード形式と選び分けの基準
Console-to-Codeが生成できるIaCの言語・形式は、CDK Java、CDK Python、CDK TypeScript、CloudFormation JSON、CloudFormation YAMLの5つです。これに加えて、記録した操作に対応するAWS CLIコマンドを一覧から取得できます。個別コマンドのコピーのほか、CloudShellのアイコンを押すとCloudShellが開いてコマンドが入力済みの状態になり、選択した複数コマンドをまとめて実行することもできます。
形式の選び方は運用の持ち方で決まります。一度きりの再現や手順の共有ならCLIコマンドで足ります。作成したリソースをスタックとして継続管理するならCloudFormation、条件分岐やループを含む構成を書くならCDKです。CloudFormationのテンプレート構造はAWS CloudFormationとは?テンプレートの書き方から使い方までわかりやすく解説、CDKの仕組みと言語選択はAWS CDK(cdk)とは?仕組み・使い方とCloudFormation・Terraformとの違いで扱っています。
HashiCorp Terraformの形式には対応していません。Terraformで統一している環境では、生成物をそのまま持ち込めない点が最初の判断材料になります。
記録から生成までの3ステップと必要なIAM権限
手順は3段階です。第1に、対応サービスのコンソールでConsole-to-Codeのアイコンを選び、サイドパネルで記録を開始します。第2に、コード化したい操作を実行し、終わったらパネル上部の停止を押します。第3に、記録された操作を絞り込んだうえでCLIコマンドを取得するか、コード化したい操作にチェックを入れて言語と形式を選び、生成を実行します。生成されたコードは、対応するCLIコマンドと並べて表示されます。
権限は2種類必要です。1つはConsole-to-Codeを使うためのq:GenerateCodeFromCommands、もう1つは記録する操作そのものを実行する権限です。公式ドキュメントが示すポリシー例は次のとおりです。
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAmazonQConsoleToCode",
"Effect": "Allow",
"Action": "q:GenerateCodeFromCommands",
"Resource": "*"
}
]
}
この権限について、AWS DevOps Blogの解説記事(2025年9月30日)は「既定で付与され、利用者側の追加対応は不要」と説明しています。したがって通常のコンソール利用では意識せずに使えます。問題になるのは、SCPやアクセス許可境界でq:*をまとめて制限している組織です。生成ボタンだけが失敗する場合は、記録対象の操作権限ではなくAmazon Q Developer側のアクションが除外されていないかを確認してください。
無料枠の実際:月25回という数字の出どころ
コスト面は説明が食い違いやすい箇所です。公式ドキュメントの記述は次のとおりです。無料利用枠では、操作の記録とCLIコマンドの生成に月間の固定上限はありません。一方、記録した操作からCDKまたはCloudFormation向けのコードを生成する回数には月間上限があり、上限に達した後はProティアでの認証が必要になります。Proティアでは、CDKとCloudFormationのコード生成に月間の固定上限はありません。
回数の具体値は、一般提供を告知した2024年10月10日のAWS公式ブログに「CDKとCloudFormation形式のコード生成には月25回の無料枠があり、それを超えるとAmazon Q Developerのサブスクリプションが必要」と記載されています。ただし2026年8月時点のAmazon Q Developer料金ページにはConsole-to-Codeという項目自体がなく、無料枠として表に並ぶのは月50回のエージェント型リクエストとJavaアップグレード変換の月1,000行です。この1,000行はJavaコード変換の枠であり、Console-to-Codeのコード生成量ではありません。「Console-to-Codeの無料枠は月1,000行まで」という解説はこの2つの混同で、行数はConsole-to-Codeの課金単位ではない点に注意してください。
Proティアは1ユーザーあたり月19ドルで、利用にはIAM Identity Centerに登録されたユーザーであり、そのIDがAmazon Q Developer Proにサブスクライブされていることが条件です。料金体系は改定されるため、回数の上限を根拠に運用設計する場合は公式の料金ページで最新の表記を確認してください。
既存リソースのコード化はIaC generatorの担当
Console-to-Codeは「これから行う操作」を記録する仕組みです。すでに稼働している環境をまとめてコード化する用途には使えません。ここを取り違えて、既存環境の棚卸しにConsole-to-Codeを使おうとする設計は失敗します。既存リソースが対象なら、CloudFormationのIaC generatorを使ってください。CloudFormationの管理下にないリソースをスキャンし、そこからテンプレートを生成する機能です。
スキャンの範囲とクォータ
IaC generatorのスキャンはリージョン単位で行われ、結果は30日で失効します。失効までの間は同じスキャン結果から複数のテンプレートを作れます。主なクォータは次のとおりで、フルスキャンと部分スキャンで値は同一です。
| 項目 | 上限 |
|---|---|
| 1回のスキャンで処理できるリソース数 | 100,000 |
| 1日のスキャン回数(1万リソース未満) | 10回 |
| 1日のスキャン回数(1万リソース超) | 1回 |
| 1テンプレートでモデル化できるリソース数 | 500 |
| 1テンプレート生成で同時にモデル化できるリソース数 | 5 |
| アカウントあたりの同時テンプレート生成数 | 5 |
| アカウントあたりの生成テンプレート数 | 1,000 |
| スキャン結果の有効期間 | 30日 |
対象はCloud Control APIが対応するリソースタイプに限られます。コンソールを使わずCLIで進める場合の流れは、スキャン開始、進捗確認、対象リソースの一覧取得、テンプレート生成の4段階です。
aws cloudformation start-resource-scan
aws cloudformation describe-resource-scan --resource-scan-id <resource-scan-arn>
aws cloudformation list-resource-scan-resources --resource-scan-id <resource-scan-arn>
aws cloudformation create-generated-template --generated-template-name my-template --resources file://resources.json
--resource-scan-idに渡すのは短いIDではなくスキャンのARNです。またcreate-generated-templateで必須なのは--generated-template-nameだけで、--resourcesを省くとエラーにはならず、リソースを1つも含まないテンプレートが黙って作られます。対象リソースは必ず指定してください。
cdk migrateでCDKアプリへ移す場合
生成済みのテンプレートをCDKアプリにするなら、ローカルのテンプレートを指定します。
cdk migrate --from-path "./template.json" --stack-name "myCloudFormationStack"
IaC generatorを自分で操作せず、デプロイ済みリソースから直接CDKアプリを作ることもできます。この場合はAWS CDK CLIが内部でIaC generatorを呼び出して新規にスキャンを実行するため、1日あたりのスキャン回数を消費します。
cdk migrate --from-scan --stack-name "myCloudFormationStack"
ただしcdk migrateは2026年8月時点でもプレビューリリースであり、仕様変更の可能性があります。生成されるのはL1コンストラクトのみで、アプリは単一スタック構成になります。データベースのパスワードのようにIaC generatorが読み取れない書き込み専用プロパティは移行後に自分で埋める必要があり、対象はプロジェクトのReadMeに警告として列挙されます。ステートフルなリソースを扱うときは、論理IDとスタック名が既存と一致しているかを移行後に必ず確認してください。
生成コードを本番へ載せる前の確認点
公式ドキュメントは、生成されたコードを出発点として扱い、用途に合わせてカスタマイズして本番対応にすることを前提としています。コンソールのワークフローを通しているためパラメータの組み合わせに矛盾がない、という点が生成物の強みで、逆に言えばそれ以上の保証はありません。本番投入前に見るべき箇所は次のとおりです。
- AMI IDやサブネットIDのように環境ごとに変わる値が直接埋め込まれていないか。埋め込まれていればパラメータやコンテキストに切り出します。
- 命名規則とタグ付けが社内標準に沿っているか。生成物はコンソールで入力した値をそのまま反映します。
- 削除保護やバックアップ設定など、検証環境では省いた設定が抜けていないか。
- テンプレートの静的検査を通したか。CloudFormationならCloudFormation Linter(cfn-lint)とは?ツールの概要・機能と特徴を詳しく解説で扱うcfn-lintが使えます。
最初の項目が最も手戻りを生みます。コンソールで選んだAMI IDやサブネットIDは、生成物では固定値として書き出されます。別リージョンや別アカウントで流用した時点で失敗するため、パラメータへ切り出してください。AMI IDはSSMパブリックパラメータを参照する形にしておくと、更新のたびにテンプレートを書き換えずに済みます。
Parameters:
LatestAmiId:
Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64
SubnetId:
Type: 'AWS::EC2::Subnet::Id'
Resources:
AppInstance:
Type: 'AWS::EC2::Instance'
Properties:
ImageId: !Ref LatestAmiId
InstanceType: t3.micro
SubnetId: !Ref SubnetId
Tags:
- Key: Name
Value: app-server
上のテンプレートはcfn-lint 1.46.0で検査し、指摘なし(終了コード0)を確認しています。
使わない方がよい場面もはっきりしています。すでにCloudFormationスタックで管理しているリソースをコンソールから触って記録すると、スタックの実態と乖離した設定変更を持ち込むことになります。管理下のリソースはテンプレート側を直してください。Terraformで統一している環境も同様で、Console-to-Codeの出力形式にTerraformは含まれないため、CLIコマンドを参考情報として読む以上の使い道はありません。Terraform側の運用設計はHCP Terraformとは?旧Terraform Cloud(名称変更)の機能・料金とHCPでの位置づけを解説を参照してください。
よくある質問
Console-to-Codeは無料で使えますか?
操作の記録とAWS CLIコマンドの取得は、無料利用枠で月間の固定上限なく使えます。CDKまたはCloudFormation形式でのコード生成には月間上限があり、超えるとAmazon Q Developer Proでの認証が必要です。一般提供の発表時点では月25回と案内されていましたが、現在の料金ページにはConsole-to-Codeの行がないため、最新の回数は公式ページで確認してください。
対応しているAWSサービスはどれですか?
2026年8月時点の公式ドキュメントでは、Amazon EC2、Amazon VPC、Amazon RDS、Amazon DynamoDB、Amazon Cognito、AWS IoTの6サービスです。一般提供開始時はEC2・RDS・VPCの3つで、DynamoDBは2025年8月6日に追加されました。
Terraform形式のコードは生成できますか?
できません。生成できるのはCDK(Java・Python・TypeScript)とCloudFormation(JSON・YAML)、およびAWS CLIコマンドです。Terraformを使う環境では、記録したCLIコマンドを設定値の確認に使う程度にとどまります。
ブラウザのタブを閉じても記録は残りますか?
残りません。Console-to-Codeのセッションは、ブラウザタブを閉じたときか、AWSマネジメントコンソールのセッションが切れたときのどちらか早い方で終了します。ただしタブを開いたままであれば、EC2・VPC・RDSなど複数サービスのコンソールを移動しても1本の記録として継続します。
すでに作成済みのリソースをコード化するには?
Console-to-Codeではなく、CloudFormationのIaC generatorを使います。CloudFormation管理下にないリソースをリージョン単位でスキャンし、テンプレートを生成できます。生成したテンプレートをCDKアプリにする場合はAWS CDK CLIのcdk migrateを使いますが、こちらはプレビューリリースです。