--- title: "AWS Amplify Hostingとは？料金・デプロイ手順とS3+CloudFront・App Runner後継との違い" url: "https://www.issoh.co.jp/tech/details/7252/" published: 2025-06-16 updated: 2026-10-13 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Amplify Hostingとは？料金・デプロイ手順とS3+CloudFront・App Runner後継との違い AWS Amplify Hosting（旧 Amplify Console）は、GitHubなどのリポジトリと接続するだけで、フロントエンドや Next.js などのSSRアプリを自動ビルド・デプロイできるフルマネージドのホスティングサービスです。内部では Amazon S3 と Amazon CloudFront が自動構成され、CI/CD・カスタムドメイン・HTTPS・プレビュー環境までコンソールから完結します。本記事では、仕組みと主な機能、Next.jsの対応範囲、料金（従量課金の内訳・無料枠・月額の試算）、amplify.ymlとリライト設定・CLIでの手動デプロイの手順、そしてS3+CloudFrontや、新規受付を終えたApp Runnerの後継との使い分けまでを、AWS公式ドキュメント（2026年10月時点）をもとに整理します。 ## まとめ：Amplify Hostingの採用条件・料金・代替サービスの選定 - 向いているケース：ReactやNext.jsで作ったフロント／SSRアプリを、IaCやCI/CDを自前構築せず短期間で公開したいとき。ブランチごとのプレビューURLを使ってレビューを回したいチーム。 - 向かないケース：CloudFront FunctionsやLambda@Edgeでエッジ処理を細かく制御したい、CDNのパラメータを自分で管理したいとき（内部リソースが隠蔽されるため）。Next.jsのEdge RuntimeやオンデマンドISRに依存する設計も対象外です。 - 料金の要点：ビルド$0.01/分・転送$0.15/GB・保存$0.023/GB月の従量課金。SSRを使うとリクエストと計算時間が別途加算され、WAFを付けると月$15/アプリが上乗せされます。 - 選定の軸：手軽さと統合管理を取るなら Amplify Hosting、細かい制御と構成の作り込みを取るなら S3+CloudFront。常時稼働のコンテナAPIは、新規受付を終えたApp Runnerではなく ECS Express Mode が新規案件の受け皿です。 ## AWS Amplify Hostingの仕組みとS3・CloudFrontが裏で動く構成 Amplify Hosting は AWS Amplify のうち「ホスティング（配信）」を担う機能で、読み方は「アンプリファイ ホスティング」です。GitやAmazon S3にあるアプリを接続すると、コミットをトリガーにビルドからCDNへの配信までを自動化します。開発者からは1つのサービスに見えますが、裏側では静的アセットをS3に格納し、CloudFrontでグローバル配信する構成が自動的に作られます。この内部リソースは基本的に隠蔽され、コンソールから直接は触れません。SSRアプリの場合は、さらに「Amplify Hosting compute」と呼ばれるマネージドの実行環境がリクエストごとにHTMLを生成します。 バックエンド（認証・API・データベース）まで含めて構築する場合は、TypeScriptで定義する Amplify Gen 2 と組み合わせますが、既存のフロント／SSRアプリを「置いて公開するだけ」ならホスティング機能単体でも利用可能です。Google Cloud側で同じ役割を担うサービスは[Firebase Hostingの解説](https://www.issoh.co.jp/tech/details/16674/)で扱っています。AWS Amplify全体の仕組みとGen 2のバックエンド定義・採用判断は[AWS Amplifyとは何かを実装者目線で解説した記事](https://www.issoh.co.jp/tech/details/15590/)で、ampxを使った初期化からCI/CDまでの手順は[Amplify Gen 2の使い方](https://www.issoh.co.jp/tech/details/2842/)で確認できます。 ## Amplify Hostingの主要機能：CI/CD・プレビュー・独自ドメイン・WAF ### Git連携の自動ビルドとamplify.ymlによるデプロイ設定 接続したブランチにpushすると、ビルド設定（`amplify.yml`）に従って自動でビルドし、成功すれば本番URLへ反映します。Amplifyはリポジトリの `package.json` からフレームワークとビルドコマンドを自動検出し、環境変数もコンソールから登録可能です。ビルド設定はコンソールに保存する方法と、リポジトリ直下に `amplify.yml` を置く方法があり、後者があればそちらが優先されます。 ### ブランチ・プルリクエスト単位のプレビュー環境と公開前のレビュー運用 ブランチや Pull Request 単位で独立したURLを払い出せるため、レビュー前に実画面で確認できます。ステージングと本番をブランチで分離する運用が容易です。プレビュー用のビルドもビルド分数として課金されるので、対象ブランチを絞っておくとコストの膨らみを防げます。デプロイ戦略の考え方は[ブルーグリーンデプロイメントの解説](https://www.issoh.co.jp/tech/details/4040/)も参考になります。 ### 独自ドメイン接続とSSL証明書の自動発行・自動更新の流れとDNS設定 独自ドメインを接続するとSSL/TLS証明書が自動発行・更新され、HTTPS化まで自動で完了します。Route 53で管理しているドメインならDNSレコードも自動で追加され、他社DNSの場合は表示されるCNAMEを手動で登録する方式です。サブドメインやリダイレクト、カスタムヘッダーの設定もコンソールから行えます。 ### WAF連携とBasic認証による公開前サイトのアクセス制御と設定単位 2025年3月26日に AWS WAF 連携が[一般提供（GA）として発表](https://aws.amazon.com/about-aws/whats-new/2025/03/aws-amplify-hosting-web-application-firewall-protection/)され、Amplifyアプリにウェブ用のファイアウォールを直接アタッチできるようになりました。AWSのマネージドルール、レートベースルール、IPアドレスや国単位の制限を使えます。設定手順と注意点は[公式ドキュメントの「Firewall support for Amplify hosted sites」](https://docs.aws.amazon.com/amplify/latest/userguide/WAF-integration.html)にまとまっており、Web ACLはアプリと同じリージョンにある必要があります。料金は後述の表のとおり月額$15/アプリ＋WAF利用料です。公開前サイトを隠すBasic認証もブランチ単位で設定できます。 ## Amplify Hostingの対応フレームワークとNext.jsのSSR対応範囲 ### Next.js 12〜15系の対応機能とEdge・オンデマンドISRの非対応 実運用で中心になるのは Next.js のホスティングです。[公式ドキュメント「Amplify support for Next.js」](https://docs.aws.amazon.com/amplify/latest/userguide/ssr-amplify-support.html)では、2026年10月時点で Next.js 12〜15系のSSRを Amplify Hosting compute が管理すると記載されています。SSR・SSG・ISR・APIルート・動的ルート・i18nルーティング・ミドルウェア・画像のサイズ・形式の自動調整・App Router（app ディレクトリ）が対応機能です。画像のサイズ・形式の自動調整に必要なSharpはAmplifyが自動で配置するため、自分でインストールする必要はありません。 一方で、Edge API Routes（Edgeミドルウェア）、オンデマンドISR、Next.jsのストリーミング、静的アセットやサイズ・形式が自動調整された画像に対するミドルウェア実行は非対応と明記されています。Next.js 16系については第三者による動作報告はあるものの、公式ドキュメントの記載は15系までにとどまるため、16系で本番運用する場合は検証環境でビルドと主要画面を確かめてから切り替えてください。各レンダリング方式の使い分けは[Next.jsのレンダリング方式の解説](https://www.issoh.co.jp/tech/details/3791/)で整理しています。 ### SPA・静的サイトの配信とSSR課金が発生する境目の見分け方 Nuxt.js のSSRも扱えるほか、React・Vue・Angular・Svelte などのSPA（CSR）も配信できます。SPAとして配信する具体例は[Remix SPAモードとAWS Amplify Gen 2の構成手順](/tech/details/2281/)で扱っています。ビルド設定はフレームワークを自動検出して生成されるため、多くの場合は接続するだけで動作する仕組みです。 料金面の分かれ目は、リクエスト時にサーバー側で処理が走るかどうかです。静的サイト（SSG）やSPAはCDN配信のみで完結しますが、Next.jsのSSRやAPIルートを使うと、リクエストごとに計算が走り、後述のSSRリクエスト・計算時間の課金対象になります。SSRとCSRの挙動の差は[CSRとSSRの違いと使い分け](https://www.issoh.co.jp/tech/details/5895/)で整理しています。 ## Amplify Hostingの料金体系と無料枠・月額コストの試算例 Amplify Hosting は初期費用なしの従量課金です。以下は [AWS公式の料金ページ](https://aws.amazon.com/amplify/pricing/)（2026年10月時点）の単価と無料枠です。単価は改定されることがあるため、契約前に最新の料金ページで確認してください。 | 項目 | 単価 | 無料枠（月あたり） | | ------------- | -------------------- | --------- | | ビルド（Standard） | $0.01 / 分 | 1,000 分 | | ビルド（Large） | $0.025 / 分 | なし | | ビルド（XLarge） | $0.10 / 分 | なし | | データ保存（CDN） | $0.023 / GB・月 | 5 GB | | データ転送（配信） | $0.15 / GB | 15 GB | | SSRリクエスト | $0.30 / 100万件 | 50万件 | | SSR計算時間 | $0.20 / GB・時 | 100 GB・時 | | WAF（アタッチ時） | $15 / 月・アプリ ＋ WAF利用料 | なし | ビルドのインスタンスは Standard（8GBメモリ・4vCPU）、Large（16GBメモリ・8vCPU）、XLarge（72GBメモリ・36vCPU）の3段階で、大きいサイズほど分単価が上がります。データ保存の料金はアプリを削除するまで毎月かかり続けるため、使わなくなった検証用アプリは削除しておきます。 ### 無料枠の12か月とクレジット制への移行で変わる新規アカウントの扱い 上表の無料枠は、従来の AWS Free Tier の対象アカウントに適用されるもので、料金ページでは「12か月間無料」と案内されています。2025年7月15日以降に作成した新規アカウントは、最大$200のAWS無料利用枠クレジットを消費する方式に変わりました。新規アカウントは作成時に無料プランと有料プランを選べ、無料プランは作成から6か月、クレジットの有効期限は作成から12か月です。既存アカウントと新規アカウントで無料分の扱いが異なるため、コスト試算の前に自分のアカウント種別を確認しておきます。 ### Next.jsのSSRサイトで月額を見積もる計算手順と試算例 無料枠を使い切った前提で、Next.jsのSSRサイトを公開した場合の月額を上表の単価で試算します。条件は、ビルド300分（Standard）、保存2GB、転送100GB、SSRリクエスト200万件、SSR計算時間200GB・時とします。 - ビルド：300分 × $0.01 ＝ $3.00 - 保存：2GB × $0.023 ＝ 約$0.05 - 転送：100GB × $0.15 ＝ $15.00 - SSRリクエスト：200万件 × $0.30／100万件 ＝ $0.60 - SSR計算時間：200GB・時 × $0.20 ＝ $40.00 合計は約$58.65で、WAFを付けると$15＋WAF利用料が加わります。SSRの計算時間がいちばん大きな比率を占めており、同じ規模でもSSGやISRへ寄せたページが多いほど請求は下がります。逆に静的サイトなら、転送とビルドだけで月$20前後に収まる計算です。 ### ビルド分数と転送量のコストを抑えるキャッシュ設定と自動ビルドの管理 ビルドは分単位課金なので、`cache` で依存関係を再利用し、不要なブランチの自動ビルドを止めると無駄なビルド分を減らせます。転送量が主なコストになりやすいため、静的アセットにはカスタムヘッダーで長めの `Cache-Control` を付けてブラウザ側のキャッシュを効かせます。SSRを使わない静的サイトであれば、SSRリクエスト・計算時間の課金は発生しません。 ## Amplify Hostingへのデプロイ手順：GitHub連携とCLI手動デプロイ ### コンソールでGitHubリポジトリを接続して公開する5ステップ 基本的な流れは次のとおりです。マネジメントコンソールから数分で公開まで到達できます。 1. AWSマネジメントコンソールで「Amplify」を開き、「新しいアプリをデプロイ」を選ぶ。 2. GitHubなどのGitプロバイダを接続し、対象リポジトリとブランチを選択する。 3. フレームワークが自動検出され、ビルド設定（`amplify.yml`）が生成される。必要に応じて環境変数を登録する。 4. 「保存してデプロイ」でビルドが走り、成功すると発行されたURLで公開される。 5. 独自ドメインを接続すると、証明書発行とHTTPS化まで自動で完了する。 認証やユーザー管理を追加する場合は、[Amazon Cognito](https://www.issoh.co.jp/tech/details/3108/)と組み合わせるのが一般的です。 ### amplify.ymlの最小構成とNext.jsのSSR用ビルド設定例 ビルド設定はコミットして管理できます。[公式のビルド仕様リファレンス](https://docs.aws.amazon.com/amplify/latest/userguide/yml-specification-syntax.html)では、`preBuild`・`build`・`postBuild` の3フェーズ、成果物の場所を示す `artifacts`、次回ビルドへ持ち越す `cache` が定義されています。Create React App やViteで作ったSPAの最小構成は次のとおりです（Viteなら `baseDirectory` を `dist` にします）。 ``` version: 1 frontend: phases: preBuild: commands: - npm ci build: commands: - npm run build artifacts: baseDirectory: build files: - '**/*' cache: paths: - node_modules/**/* ``` Next.jsのSSRアプリでは、成果物を `.next` に向け、npmのキャッシュとNext.jsのビルドキャッシュを持ち越します。キャッシュのパスはプロジェクトルートからの相対パスで書き、絶対パスはエラーにならずに無視される点に注意します。 ``` version: 1 frontend: phases: preBuild: commands: - npm ci --cache .npm --prefer-offline build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/* ``` ### SPAの直リンクで404や真っ白になる画面を防ぐリライト設定 SPAはトップから遷移すると動くのに、`/users/1` のようなURLを直接開くと404や真っ白な画面になることがあります。サーバー側にそのパスのファイルが無いためで、拡張子の付いていないリクエストを `index.html` へ200で書き換えるルールを入れることで解決可能です。正規表現は[公式のリダイレクト・リライト例](https://docs.aws.amazon.com/amplify/latest/userguide/redirect-rewrite-examples.html)のSPA向けルールをそのまま使い、[AWS CLIのupdate-app](https://docs.aws.amazon.com/cli/latest/reference/amplify/update-app.html)で登録できます。 ``` aws amplify update-app \ --app-id d1a2b3c4d5e6f7 \ --custom-rules '[{"source":"","target":"/index.html","status":"200"}]' ``` ルールは上から順に評価されるため、個別の301リダイレクトはこのルールより上に置きます。コンソールの「書き換えとリダイレクト」画面でもJSONとして同じ内容を貼り付けられます。 ### Git未接続アプリをCLIのcreate-deploymentで手動デプロイ 社内のCIで成果物を作ってから配信だけAmplifyに任せたい場合は、Gitを接続しない「手動デプロイ」のアプリを使います。[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/amplify/create-deployment.html)で発行されたアップロードURLへzipを送り、`start-deployment` で公開します。create-deployment から start-deployment までの実行期限は8時間以内です。 ``` APP_ID=d1a2b3c4d5e6f7 cd dist && zip -r ../site.zip . && cd .. RES=$(aws amplify create-deployment --app-id "$APP_ID" --branch-name main --output json) JOB_ID=$(echo "$RES" | jq -r .jobId) UPLOAD_URL=$(echo "$RES" | jq -r .zipUploadUrl) curl -sS -X PUT -T site.zip "$UPLOAD_URL" aws amplify start-deployment --app-id "$APP_ID" --branch-name main --job-id "$JOB_ID" ``` GitHub ActionsやCodeBuildからこの手順を呼べば、ビルドは自社のCIで行い、Amplifyのビルド分数を使わずに済みます。 ## Amplify Hostingのメリットと欠点：CDN制御の制限と回避策 ### CI/CD・証明書・CDNを個別構築せずに本番配信環境を整えるメリット 最大の利点は、CloudFrontやS3、証明書、CI/CDパイプラインを個別に構築せずとも、リポジトリを接続するだけで本番配信環境が整うことです。IaCやDNSの深い知識がなくても、プレビュー環境・独自ドメイン・HTTPSまでコンソールで完結し、フロントエンド開発に集中できます。WAFやBasic認証もアプリ単位で付け外しでき、運用の窓口が1つにまとまります。 ### Lambda@Edgeが使えないなどCDNが隠蔽される制限と回避策 裏側のS3・CloudFrontが隠蔽されるため、CDNの細かいパラメータを直接設定できません。具体的には、CloudFront FunctionsやLambda@Edgeによるエッジ処理が使えず、レスポンスのステータスコードを動的に変える制御もリダイレクト系に限られます。カスタムエラーページの動的な出し分けなど、CDNレイヤーを作り込みたい要件では窮屈に感じます。 回避策は2つあります。ヘッダー付与やリダイレクト程度なら、カスタムヘッダーとリライトルール、Next.jsのミドルウェアで足りることが多いです。それでも足りない場合は、次に述べるS3+CloudFrontを自前で組むほうが向きます。自前で組む場合のCLIでの構築手順は[CloudFrontとS3で静的サイトを公開する手順](https://www.issoh.co.jp/tech/details/18064/)で、S3を非公開に保つ設定は[CloudFront OACの解説](https://www.issoh.co.jp/tech/details/3684/)で扱っています。 ## S3+CloudFront・ECS Express Mode・App Runnerの比較 「Amplify Hosting でいいのか、S3+CloudFront か、App Runner か」は検索でも頻出の論点です。ただし前提が変わりました。[AWS公式の「App Runner availability change」](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html)によると、App Runnerは新規顧客の受付を終了しており、既存顧客は引き続き利用できるものの新機能の追加は予定されていません。AWSは移行先として Amazon ECS Express Mode を案内しています。経緯は[App Runnerは終了するのかを整理した記事](https://www.issoh.co.jp/tech/details/7023/)、移行先の使い方は[ECS Express Modeの解説](https://www.issoh.co.jp/tech/details/9958/)にまとめています。 | 観点 | Amplify Hosting | S3 + CloudFront | ECS Express Mode | | ---------- | --------------- | --------------- | ------------------ | | 主な対象 | フロント／SSRアプリ | 静的サイト／SPA | コンテナのAPI・バックエンド | | CI/CD | 標準搭載 | 自前構築 | GitHub Actions等で構築 | | CDNの細かい制御 | 不可（隠蔽） | 可（自由） | 対象外 | | 常時稼働 | 不要（配信のみ） | 不要 | あり（Fargate） | | App Runner | 関係なし | 関係なし | 新規案件の移行先 | | 向くケース | 速く安全に公開 | 細かい制御 | 常駐するWeb API | 整理すると、静的サイトやSSRフロントを手早く公開するなら Amplify Hosting、Lambda@Edgeやエッジ関数でCDNを作り込みたい、あるいはコストと構成を細かく詰めたいなら S3+CloudFront です。常時稼働するサーバー（コンテナ化したWeb APIやバックエンド）は、そもそもホスティング用途ではありません。既存のApp Runner利用者はそのまま運用できますが、新規案件では[Amazon ECRに置いたDockerイメージ](https://www.issoh.co.jp/tech/details/2667/)を ECS Express Mode で起動する構成を選びます。フロントは Amplify Hosting、APIは ECS Express Mode、というように併用する構成も一般的です。 AWSの外まで候補を広げるなら、Next.jsの開発元が運営する[Vercel](https://www.issoh.co.jp/tech/details/2964/)や、静的サイトに強い[Cloudflare Pages](https://www.issoh.co.jp/tech/details/3438/)も比較対象になります。Next.jsの新機能を発表直後から使いたいならVercel、AWSの他リソースとIAMや請求をまとめたいならAmplify Hostingという分け方が実務的です。 ## Amplify Hostingを採用する条件と見送る場面：受託開発での判断基準 受託開発でホスティング先を決めるとき、私たちは次の条件で判断しています。結論は「AWSに寄せる方針があり、Next.jsを公式対応の範囲で使うなら Amplify Hosting を第一候補にする」です。 - 採用する条件：AWSアカウント内で請求・IAM・WAFを一元管理したい。フロントの更新頻度が高く、ブランチごとのプレビューでレビューを回したい。インフラ担当を置かずに公開まで持っていきたい。 - 見送る条件：Edge RuntimeやオンデマンドISR、Lambda@Edgeが要件にある。CloudFrontのキャッシュキーやオリジン構成を細かく設計したい。SSRの計算時間が大きく、試算で月額がS3+CloudFront＋自前の実行環境を明確に上回る。 - 保留にする条件：Next.jsの新しいメジャー版を使う予定で、公式ドキュメントの対応表がまだ追いついていない。この場合は検証環境で動作を確かめてから決めます。 Amplify Hostingで始めて、要件が増えた段階でS3+CloudFrontへ移す判断も現実的です。ビルド成果物は同じなので、移行時の作業は配信基盤の構築とDNSの切り替えが中心になります。AWS上でのホスティング構成の設計、App RunnerからECS Express Modeへの移行、WAFを含めた運用設計まで相談したい場合は、[一創のインフラ構築（AWS・Google Cloud・Azure）サービス](https://www.issoh.co.jp/service/system/aws/)でお手伝いしています。 ## よくある質問 Amplify Hostingの利用を検討する際によく寄せられる質問をまとめます。 ### Amplify Hostingとは何ですか？ Gitリポジトリと接続してフロントエンドやSSRアプリを自動ビルド・配信するフルマネージドのホスティングサービスです。内部でS3とCloudFrontを自動構成し、CI/CD・プレビュー環境・独自ドメインのHTTPS化までを一括で提供します。SSRアプリはAmplify Hosting computeという実行環境で動き、Next.jsは公式ドキュメント上12〜15系が対象です。 ### Amplifyの料金はいくらですか？ 初期費用はなく従量課金です。ビルド$0.01/分（Standard）、転送$0.15/GB、保存$0.023/GB・月が基本で、無料枠（ビルド1,000分・転送15GB・保存5GB）を超えた分に課金されます。SSRを使う場合はリクエスト$0.30/100万件と計算時間$0.20/GB・時が加算され、WAFは月$15/アプリです。2025年7月15日以降の新規アカウントはクレジット方式になります。 ### AWS Amplifyの欠点は何ですか？ 内部のS3・CloudFrontが隠蔽されるため、CDNの細かい設定ができない点です。CloudFront FunctionsやLambda@Edgeが使えず、ステータスコードの動的制御もリダイレクト系に限られます。Next.jsのEdge API Routes、オンデマンドISR、ストリーミングも非対応と公式ドキュメントに記載されているため、これらに依存する設計なら別の配信基盤を選びます。 ### Amplify HostingとS3+CloudFrontはどちらを選ぶべきですか？ 手軽さと統合管理を優先し、速く安全に公開したいなら Amplify Hosting です。エッジ処理やCDNパラメータを作り込みたい、構成とコストを細かく詰めたいなら S3+CloudFront を自前で構成するほうが適します。迷う場合はAmplify Hostingで始め、制約に当たった時点で移す方法もあり、ビルド成果物はそのまま流用できます。 ### デプロイしたアプリが真っ白になるのはなぜですか？ 多くはビルド出力ディレクトリ（`baseDirectory`）の指定ミスか、SPAのルーティングでリライト設定が不足しているのが原因です。Viteなら `dist`、Create React Appなら `build` を指定し、ビルドログでartifactsの出力先を確認します。直リンクで崩れる場合は、本文で紹介した拡張子なしのパスを `index.html` へ200で書き換えるルールを追加すると解消します。 ## 関連記事 - [AWS Amplifyとは？Gen 2のバックエンド定義と料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15590/)：ホスティング以外を含むAmplify全体の位置づけ - [CloudFrontとS3で静的サイトを公開する手順：OAC・独自ドメイン・デプロイまでCLIで構築](https://www.issoh.co.jp/tech/details/18064/)：Amplifyを使わず自前で組む場合の手順 - [ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説](https://www.issoh.co.jp/tech/details/9958/)：APIやバックエンドの置き場所 - [Amazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説](https://www.issoh.co.jp/tech/details/3108/)：公開したアプリへの認証の追加 - [CSRとSSRの違いと使い分け｜レンダリング方式を比較して実装で選ぶ](https://www.issoh.co.jp/tech/details/5895/)：SSR課金の有無を決めるレンダリング方式 --- 出典: [AWS Amplify Hostingとは？料金・デプロイ手順とS3+CloudFront・App Runner後継との違い]()（株式会社一創）