AWS Amplify Gen 2の使い方｜作成からサンドボックス・デプロイ・Gen 1移行まで【ampx 1.10対応】

AWS Amplify Gen 2は、npm create amplify@latestでプロジェクトを作り、amplify/配下のTypeScriptでバックエンドを宣言し、npx ampx sandboxで自分専用のAWS環境へ反映しながら開発する、という順で使います。検索結果にはGen 1向けの古い手順も残っており、amplify initやAmplify Studioから始まる手順はGen 2では動きません。この記事では2026年11月1日時点の公式ドキュメントと公開版CLI（@aws-amplify/backend-cli 1.10.0）の実装に基づき、作成から本番デプロイ、Gen 1からの移行までを手順で説明します。

まとめ：Amplify Gen 2の使い方で先に押さえる6点

• Gen 2のCLIはampx。amplify init・amplify push・amplify mockは無く、作成はnpm create amplify@latest、開発中の反映はnpx ampx sandboxが担う
• npm create amplify@latestの初期テンプレートは、未認証ユーザーに全件の作成・削除を許す設定になっている。最初にallow.owner()へ書き換える
• フロントエンドはamplify_outputs.jsonをAmplify.configureに渡し、generateClient<Schema>()で型付きのCRUDを書く
• サンドボックスはCtrl+Cでは消えない。削除はnpx ampx sandbox deleteで、識別子は--nameではなく--identifierで指定する
• 本番デプロイはAmplify Hostingのブランチ連携が基本。2026年9月のCLI 1.10.0から、Amplify Hostingを使わずに自分のAWSアカウントへ出すampx deploy（プレビュー）も加わった
• Gen 1は2027年5月1日にサポート終了。Gen 1 CLI v14のamplify gen2-migrationでデータを残したまま移行できる（Developer Preview）

以下、Gen 1との対応関係から順に見ていきます。

Gen 1の手順がGen 2で通らない理由とコマンド対応表

Gen 1のメンテナンスモードと2027年5月1日の終了

AWSはamplify-cliリポジトリのissue #14881（2026年5月14日）で、「Starting May 1, 2026, Gen 1 backends will receive only critical bug fixes and security patches and will reach end of life on May 1, 2027.」と告知しています。Gen 1の上に作られたAmplify Studioも同じ扱いで、これから学ぶならGen 1の手順書は参考にしなくて構いません。Gen 1とGen 2の設計思想の違いや採用判断はAWS Amplifyとは？Gen 2のバックエンド定義と料金・採用判断で整理しています。

amplify init・push・mock・pullに対応するGen 2コマンド

完全な等価変換ではありません。amplify mockのようなローカルのモックサーバーはGen 2に無く、開発者ごとに実際のAWSリソースを立てる方式に変わりました。generate outputsが取ってくるのもクライアント設定ファイルだけで、バックエンド定義はリポジトリのamplify/にあるのでgit pullで揃います。

もう一つの罠がコマンド名です。@aws-amplify/backend-cliはbinにampxとamplifyの両方を登録しており、npx amplify sandboxと打つとverify_command_name.jsが起動直後に「The Amplify Gen 2 CLI has been renamed to ampx」を返して止まります。Gen 1のCLIをグローバルに入れている環境ではamplifyがGen 1側に解決され、このメッセージも出ずにGen 1が動くことがあります。ampxと打つ癖をつけてください。

Amplify Gen 2のプロジェクトを作成する

Node.jsのバージョンとAWS認証情報の前提

@aws-amplify/backend-cli 1.10.0とcreate-amplify 1.4.1は、どちらもengines.nodeに^18.19.0 || ^20.6.0 || >=22を指定しています。ただしcreate-amplifyが入れるaws-cdk-lib 2.268.0はengines.nodeが>= 20.0.0なので、この構成全体ではNode.js 20.6.0以上（22以上が無難）を使ってください。サンドボックスは実際にCloudFormationスタックを作るので、ローカルにAWS認証情報が要ります。公式クイックスタートは、プロファイルにAmplifyBackendDeployFullAccessポリシーを付けるよう案内しています。権限の切り方はAWS IAMのユーザー・ロール・ポリシーの違いと権限設計が参考になります。

npm create amplify@latestと公式テンプレートの初期設定の違い

npm create amplify@latestはバックエンドの定義だけを追加し、画面や開発サーバーは作りません。この記事ではReact＋TypeScriptのViteプロジェクトに追加します。

npm create vite@latest my-app -- --template react-ts
cd my-app && npm install
npm create amplify@latest
? Where should we create your project? (.) # Enterで現在のディレクトリ

実行するとamplify/backend.ts・amplify/auth/resource.ts・amplify/data/resource.tsが作られ、@aws-amplify/backend・@aws-amplify/backend-cli・[email protected]などがdevDependenciesに入ります（default_packages.json）。2026年11月1日時点の最新は@aws-amplify/backend 1.25.1、@aws-amplify/backend-cli 1.10.0です。

注意したいのは、生成されるデータ定義の認可です。create-amplify 1.4.1のテンプレートはallow.guest()とdefaultAuthorizationMode: 'identityPool'で、コメントにも「any unauthenticated user can “create”, “read”, “update”, and “delete” any “Todo” records」とあります。ログインしていない人が全員のデータを消せる状態です。

クイックスタートが使うaws-samples/amplify-vite-react-templateは別の設定で、allow.publicApiKey()と有効期限30日のAPIキーを使います。このテンプレートはpackage.jsonで@aws-amplify/backend-cliを~1.8.1に固定しているため、そのままでは後述の--express（1.9.0から）もampx deploy（1.10.0から）も使えません。どちらのテンプレートから始めても、本番に出す前に認可とCLIの版を見直してください。

data/resource.tsを所有者ベースの認可に書き換える

import { type ClientSchema, a, defineData } from '@aws-amplify/backend';

const schema = a.schema({
  Todo: a.model({
    content: a.string(),
  }).authorization(allow => [allow.owner()]),
});

export type Schema = ClientSchema<typeof schema>;

export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: 'userPool',
  },
});

allow.owner()はレコードのowner（既定では作成者）だけに読み書きを許すルールで、リクエストにはCognitoのユーザープールのトークンを付けるためdefaultAuthorizationModeも'userPool'に変えます。公式ドキュメントのとおり、ownerは既定で本人が別ユーザーへ付け替えられるので、それを防ぐにはownerフィールドにフィールド単位の認可を掛けます。この定義からAppSyncのGraphQL APIとDynamoDBのテーブルが作られます。リゾルバの挙動で詰まったらAWS AppSyncのGraphQL APIの仕組みまで降りたほうが早く解決します。

フロントエンドからデータと認証を使う

amplify_outputs.jsonを読み込む

サンドボックスかデプロイが終わると、APIのエンドポイントや認証の設定をまとめたamplify_outputs.jsonがプロジェクト直下に出力されます。React（Vite）ならsrc/main.tsxで読み込みます。

import { Amplify } from 'aws-amplify';
import outputs from '../amplify_outputs.json';

Amplify.configure(outputs);

Next.jsのテンプレートでは@/amplify_outputs.jsonとパスエイリアスで書きます。素のViteでそのまま写すと解決できないので、相対パスにしてください。Remix（React Router）のSPAモードで使う場合の注意点はRemix SPAモードとAmplify Gen 2の構成手順にまとめています。

generateClientでTodoを作成・購読・削除する

import { useEffect, useState } from 'react';
import { generateClient } from 'aws-amplify/data';
import type { Schema } from '../amplify/data/resource';

const client = generateClient<Schema>();

export default function App() {
  const [todos, setTodos] = useState<Array<Schema['Todo']['type']>>([]);

  useEffect(() => {
    const sub = client.models.Todo.observeQuery().subscribe({
      next: (data) => setTodos([...data.items]),
      error: (err) => console.error(err),
    });
    return () => sub.unsubscribe();
  }, []);

  async function addTodo() {
    const content = window.prompt('内容');
    if (!content?.trim()) return;
    const { errors } = await client.models.Todo.create({ content });
    if (errors?.length) console.error(errors);
  }

  return (
    <main>
      <button onClick={addTodo}>追加</button>
      <ul>
        {todos.map((t) => (
          <li key={t.id} onClick={() => client.models.Todo.delete({ id: t.id })}>{t.content}</li>
        ))}
      </ul>
    </main>
  );
}

Schema型をバックエンドからimportしているので、client.models.Todoの引数や戻り値に型が付き、必須フィールドの追加や既存フィールドの型変更では、呼び出し側の不整合を型エラーで検出できます。任意フィールドの追加だけでは、既存コードがエラーになるとは限りません。observeQuery()は初回の一覧取得と以後の変更通知をまとめて受け取るので、作成・削除のたびに再取得を書く必要がありません。ファイルのアップロードはaws-amplify/storageのuploadData({ path, data })で、v5時代のStorage.putは現行のaws-amplify 6.22.2にはありません。S3のファイルを画面から操作するならStorage Browser for Amazon S3も使えます。

Authenticatorでログイン画面を付ける

// src/main.tsx
import ReactDOM from 'react-dom/client';
import { Amplify } from 'aws-amplify';
import { Authenticator } from '@aws-amplify/ui-react';
import '@aws-amplify/ui-react/styles.css';
import outputs from '../amplify_outputs.json';
import App from './App';

Amplify.configure(outputs);

ReactDOM.createRoot(document.getElementById('root')!).render(
  <Authenticator>
    <App />
  </Authenticator>
);

@aws-amplify/ui-reactはcreate-amplifyの既定パッケージに含まれないので、先にnpm install @aws-amplify/ui-reactで入れます（2026年11月1日時点で6.15.7）。Authenticatorは、amplify_outputs.jsonから認証の設定を読み、サインアップ・確認コード・サインインの画面を出し分けます。ログアウトは子コンポーネントでuseAuthenticator()からsignOutを取り出して呼びます。defineAuthの初期値はメールアドレスでのログインで、裏側はCognitoのユーザープールです。認証方式の追加や料金はAmazon Cognitoの料金・できること・使い方を参照してください。

クラウドサンドボックスで開発する

npx ampx sandboxが作るものと監視対象

npx ampx sandbox

このコマンドはCloudFormationスタックを作り、そのあとamplify/フォルダの変更を監視して反映し続けます。クイックスタートは初回の作成に約5分かかるとしており、npm run devと別のターミナルで並行して動かす使い方です。公式は「Cloud sandbox environments are designed for development purposes and are not intended for production workloads.」と書いており、本番用途は想定されていません。CIの検証ジョブのように監視が要らないときは--onceで1回だけデプロイして終わらせます。Lambda関数のログを手元で追うなら--stream-function-logs、関数を絞るなら--logs-filterを足します。

–expressで反映を速める（backend-cli 1.9.0以降）

2026年7月29日公開の1.9.0で、npx ampx sandbox --expressが加わりました（CHANGELOG）。2026年6月に発表されたCloudFormationのexpress modeを使うオプションで、リソースが安定状態になるのを待たずにスタック操作を完了扱いにします。AWSは最大4倍速くなるとしています。

速さの代わりに失うものがあります。CloudFormationのユーザーガイドは、express modeではロールバックが既定で無効になり、失敗しても自動で戻らないと説明しています。完了表示の時点ではリソースが立ち上がり途中のこともあり、CLIは「Resources still stabilizing」の警告を出します。サンドボックスでの試行錯誤には向きますが、pipeline-deployにはこのオプションが無く、本番の反映には使えません。なお公式のCLIリファレンス（最終更新2025年4月28日）にはまだ--expressが載っていません。

名前付きサンドボックスと–profileの使い分け

npx ampx sandbox --identifier feature1
npx ampx sandbox --profile work

識別子を省くと、コマンドを実行したOSユーザー名が使われます。--identifierで複数作れますが、公式は「Deploy one sandbox per Amplify app per developer to prevent conflicts」を原則としています。検証用と業務用のAWSアカウントを分けたいだけなら、識別子を増やすより--profileでプロファイルを切り替えるほうが事故が起きにくくなります。

サンドボックスの停止と削除（Ctrl+Cでは消えない）

実行中にCtrl+Cを押すと、CLIは「Stopping the sandbox process. To delete the sandbox, run ampx sandbox delete」と表示して監視を終えるだけで、DynamoDBのテーブルやCognitoのユーザープールはAWS上に残ります。削除は明示的に実行します。

npx ampx sandbox delete --identifier feature1 --yes

公式CLIリファレンスは識別子の指定を--nameと書いていますが、1.10.0のsandbox_delete_command.jsが自前で定義するオプションは--yesだけで、対象は親のsandboxコマンドの--identifierで決まります。引数解析（main_parser_factory.js）には.strict()が設定されているため、リファレンスどおり--name feature1と打つと未知のオプションとしてエラーになり、何も削除されません。--identifierに読み替えてください。機能ブランチを閉じたときにsandbox deleteまで済ませる習慣にしておくと、識別子違いのスタックが積み上がりません。

本番デプロイとCI/CDの3つの方法

本番ではAmplify Hostingを基本とし、既存CIへ統合する必要があれば外部CI方式を選びます。ampx deployはプレビューのため、本番の移行先としては扱いません。

Amplify Hostingのブランチ連携とamplify.yml

Amplifyコンソールでリポジトリを接続してブランチを紐付けると、以後はコミットごとにバックエンドとフロントエンドがまとめてデプロイされます。中で動いているのはリポジトリのamplify.ymlで、公式テンプレートではbackendフェーズに次の2行があります。

backend:
  phases:
    build:
      commands:
        - npm ci --cache .npm --prefer-offline
        - npx ampx pipeline-deploy --branch $AWS_BRANCH --app-id $AWS_APP_ID

このフェーズがamplify_outputs.jsonも生成するので、続くfrontendフェーズのnpm run buildがそれを読み込めます。機能ブランチを自動で拾うなら、コンソールの「App settings > Branch settings」でBranch auto-detectionとBranch auto-disconnectionを有効にし、feature/*のようなパターンを指定します。料金と対応フレームワークはAWS Amplify Hostingの料金表とNext.js 16の対応状況にまとめています。

GitHub Actionsなど外部CIからpipeline-deployを呼ぶ

export CI=1
npm ci
npx ampx pipeline-deploy --branch $BRANCH_NAME --app-id $AMPLIFY_APP_ID

1.10.0のpipeline_deploy_command.jsは--branchと--app-idの両方をdemandOption: trueにしており、片方だけでは起動しません。ここでいうapp-idはAmplify Hostingのアプリなので、この方法でもAmplifyコンソールにアプリを作っておく必要があります。フロントエンドを別ジョブでビルドするなら、そのジョブでnpx ampx generate outputs --branch $BRANCH_NAME --app-id $AMPLIFY_APP_IDを実行して設定ファイルを取り直します。generate outputsは--app-idと--branchの組か、CloudFormationのスタック名を渡す--stackのどちらか一方で指定し、両者は併用できません。

ampx deployとdefineHostingでAmplify Hostingを使わずにデプロイする（プレビュー）

2026年9月10日公開の1.10.0でnpx ampx deployが加わり、同日に@aws-amplify/hosting 1.0.0も出ました。amplify/hosting.tsにdefineHosting()を書くと、CloudFront・S3・LambdaのCDKスタックが自分のAWSアカウントに作られます。フレームワークはpackage.jsonから自動判定され、npmの説明ではNext.js・Nuxt・Astro・SvelteKitが対象です。

npm add @aws-amplify/hosting
npx ampx deploy --identifier my-app
npx ampx deploy --identifier my-app --frontend

2行目はバックエンドとフロントエンドを両方、3行目はフロントエンドだけを更新します。--identifierを省くとpackage.jsonのnameから作った値が使われます。事前にcdk bootstrapが必要です（公式ガイド）。実行時には「ampx deploy is a PREVIEW release — not intended for production use」の確認が出て、CIでは--yesを付けないと入力待ちで止まります。外部CIのガイドは、正式版までは本番以外の環境にとどめるよう書いています。CodePipelineを自動で組むdefinePipeline()もあり、ブランチごとにバックエンド、フロントエンドの順でデプロイします。WAFや独自のCDN設定が必要な案件、組織のAWSアカウント管理にホスティングも載せたい案件向けで、そうした要件が無ければAmplify Hostingのほうが管理するものが少なく済みます。中身はAWS Blocksの@aws-blocks/hostingで、デプロイ中の旧版と新版の食い違い（Version Skew）への対策も入っています。

Gen 1プロジェクトをgen2-migrationでGen 2へ移す手順

既存のGen 1プロジェクトは、Gen 1 CLIに追加されたamplify gen2-migrationで移せます。公式の移行ガイドはDeveloper Previewで、本番リソースを操作するため無人で流さないよう警告しています。進め方は一部ブルーグリーン方式です。Gen 2の環境をGen 1と並べて立て、Cognitoのユーザープール・S3バケットなど状態を持つリソースだけをCloudFormationのStack Refactor APIでGen 2側へ移します。モデルのDynamoDBテーブルはデプロイの時点から両方で共有され、移動の対象外です。

npm install -g @aws-amplify/cli@^14.4.0
amplify pull --appId <app-id> --envName main
amplify gen2-migration assess
amplify gen2-migration lock
amplify gen2-migration generate
# Gen 2のブランチをデプロイし、動作を確認してから
amplify gen2-migration refactor --to <gen2-root-stack-name>

assessは読み取り専用で、リソースごとにgenerateとrefactorの対応可否を一覧にします。lockはGen 1のスタックに全拒否のスタックポリシーを掛け、状態を持つリソースに削除保護（Retain）を付けます（lock --rollbackで戻せます）。前提として、Gen 1環境をv14で一度amplify pushしておくこと、DataStoreの競合解決を使っているAPIは先に無効化することが求められます。ガイドは本番の前にamplify env addで作った複製環境で全工程を通すよう勧めています。移行すべきかどうかの判断軸はAWS Amplifyとは？の「Gen 1とGen 2の違い」の章を参照してください。

amplify_outputs.jsonがgit管理外になるチーム開発の落とし穴

npm create amplify@latestは.gitignoreへ.amplify・amplify_outputs*・amplifyconfiguration*を追記します（gitignore_initializer.js）。各開発者のサンドボックスが設定ファイルを手元に生成するので、普段は困りません。

止まるのは、フロントエンド担当がAWS認証情報を持たない場合です。サンドボックスを立てられず、Amplify.configureに渡すファイルがありません。共有のブランチがデプロイ済みならnpx ampx generate outputs --branch "$BRANCH_NAME" --app-id "$AMPLIFY_APP_ID"で取得できますが、これにもAWS認証情報と参照権限が要ります。フロントエンド担当にAWSアクセスを渡さない運用なら、権限を持つ担当者かCIが取得したファイルを、どの環境のものかを明示してチームの管理場所から受け渡します。

PoCでAmplifyを選ぶ基準と見送るべき場面

Amplify Gen 2がPoCで効くのは、認証・データ・ストレージ・関数の標準構成で足りる場合です。defineAuthとdefineDataの数十行でCognito・AppSync・DynamoDBが揃います。既存のMySQL・PostgreSQLを使う要件も、それだけで見送る理由にはなりません。npx ampx generate schema-from-databaseで既存DBからスキーマを作る標準の接続機能があり、同じアカウント・リージョンのRDSならVPC設定も自動で検出されます。バックエンドを別チームが別リポジトリで持つ構成も、バックエンドだけのAmplifyアプリを作り、フロントエンド側でgenerate outputsを使う形で公式に用意されています。

見送りを考えるのは、標準カテゴリにも既存DB接続にも当てはまらないAWSサービスが中心になる場合です。その部分はbackend.tsの中でCDKを書くことになり、比重が大きければCDK単体で組んだほうが構成を追いやすくなります。PoCの入口で「標準カテゴリから外れる部分が半分を超えたらCDKへ移る」と線を引いておくと判断がぶれません。AWSの構成設計から任せたい場合はAWSのインフラ構築支援もご相談いただけます。

よくある質問

Gen 2でも amplify init は使えますか？

使えません。Gen 2にinitは無く、プロジェクトの作成はnpm create amplify@latestです。@aws-amplify/backend-cliはamplifyという名前でも起動しますが、「The Amplify Gen 2 CLI has been renamed to ampx」というエラーで止まります。

amplify mock に相当するローカルモックはありますか？

ありません。Gen 2はローカルモックの代わりに、開発者ごとに実際のAWSリソースを立てるクラウドサンドボックス（npx ampx sandbox）を使います。AWSアカウントとネットワーク接続が前提です。反映待ちを短くしたい場合は1.9.0以降の--expressが使えます。

Gen 1で作った既存プロジェクトのサポートはいつ終了しますか？

2026年5月1日からはクリティカルなバグ修正とセキュリティパッチだけになり、2027年5月1日にサポートが終了します。Gen 1 CLI v14のamplify gen2-migrationで、ユーザーやデータを残したままGen 2へ移せます。

GitHub ActionsでAmplify Gen 2をデプロイできますか？

できます。バックエンドはnpx ampx pipeline-deploy --branch "$BRANCH_NAME" --app-id "$AMPLIFY_APP_ID"で反映し、両オプションとも必須です。1.10.0のnpx ampx deployもCIから呼べますが、プレビューなので--yesが要り、本番には向きません。

amplify_outputs.json はgitにコミットすべきですか？

コミットしない前提です。npm create amplify@latestが.gitignoreにamplify_outputs*を追加します。サンドボックスやデプロイのたびに生成されるので、手元に無い場合はnpx ampx generate outputsで取得します。

関連記事

• AWS Amplifyとは？Gen 2のバックエンド定義と料金・採用判断を実装者目線で解説
• AWS Amplify Hostingとは？料金表とNext.js 16の対応状況・デプロイ手順、S3+CloudFrontとの違い【2026年10月】
• AWS AppSyncとは？GraphQL APIの仕組み・料金とAppSync Events・採用判断を実装者目線で解説
• Amazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説【2026年10月】
• AWS Blocksとは？Blockの一覧・ローカル開発・CDKとの違いと採用判断