2026.10.25 業務システム

kintone開発者ライセンスの取り方と開発環境の作り方｜cli-kintoneで検証環境を分ける手順

kintoneには「開発環境」という機能がなく、本番と切り離して試す場所は自分で用意する必要があります。現実的な答えは、無償のkintone開発者ライセンスで別ドメインの検証環境を持ち、手元にNode.jsとcli-kintoneを入れて、コマンドで接続先を切り替える構成です。この記事では、開発者ライセンスの申し込み手順と利用規約で禁じられた使い方、失効前のバックアップ、ローカル環境の構築、検証から本番への反映手順、テンプレートで複製したときに消える設定までを、cybozu developer networkとcli-kintone公式の一次情報、そしてそのまま使える設定例で解説します。

まとめ｜kintone開発環境は別ドメインの検証環境とコマンド反映で組む

開発環境の第一候補は、cybozu developer networkの開発者ライセンスで発行される別ドメインの環境です。5ユーザー・25GB固定で本番利用は禁止ですが、JavaScript・プラグイン・APIはスタンダードコースとほぼ同じ条件で試せます。申し込みは無料で所要時間は約10分、12か月ごとに無料の更新申請が必要です。手元にはNode.js 20以上と@kintone/cli（cli-kintone）を入れ、接続先URLと認証情報は環境変数で切り替えます。

開発者ライセンスの環境はサイボウズが承諾なしに調査目的でアクセスできる規約になっており、データリストアも受け付けていません。個人情報を含む本番データは入れず、失効や誤削除に備えてアプリ設定とレコードを手元へ書き出しておく運用が前提です。

反映は、本番の現状をcustomize exportで書き出して差分を取り、検証環境で確認したマニフェストをcustomize applyで本番へ当てる流れです。アプリを複製するときはテンプレートを使えますが、プラグイン設定・APIトークン・Webhook・アクセス権は引き継がれないので、手順書に残して手で戻します。カスタマイズが1アプリ・1人の担当なら本番直編集でも回りますが、複数アプリや複数人の体制になった時点で環境分離を先に整えるべきです。

kintoneに開発専用の環境機能がない前提と3つの環境分離の選び方

最初に押さえるのは、kintone側に「開発用」「本番用」を切り替える仕組みがないという事実です。どこで開発するかは、契約と体制に合わせて自分たちで決めます。

公式FAQが示す3つの構成とサブドメイン分離を第一候補にする理由

cybozu developer networkの「kintone開発前によくある質問」は、kintoneに開発専用の環境機能が存在しないと明記したうえで、次の3構成を挙げています。

構成	内容	向く場面	主なリスク
サブドメインを分ける	開発者ライセンスか別契約の環境を検証用にする	JavaScript・プラグイン・API連携を書く	アプリやユーザーの再現に手間がかかる
同一サブドメインでアプリを分ける	検証用アプリと運用アプリを並べる	フィールド追加など設定変更の試行	全体に効くカスタマイズで本番を巻き込む
運用中のアプリで随時開発	本番アプリを直接直す	1アプリ・軽微な修正のみ	不具合がそのまま利用者に出る

コードを書く開発なら、サブドメイン分離を選びます。ポータルやスペースに効くJavaScript、ドメイン単位で入れるプラグインは、同じドメインの中ではアプリを分けても影響が漏れるからです。

同一サブドメインでアプリを分ける構成が事故につながる3つの場面

同じドメインで検証用アプリを作る方法は手軽ですが、次の場面では本番に影響が出ます。

kintoneシステム管理の「JavaScript / CSSでカスタマイズ」に入れたファイルは、全アプリの画面で読み込まれる
プラグインの読み込みと更新はドメイン単位で、検証用アプリのために入れた新しい版が本番アプリ側のプラグインも置き換える
検証用アプリから本番アプリへのルックアップや関連レコードを張ると、テストデータの登録で本番側の参照が動く

設定項目を増やす程度の試行なら同一ドメインで足ります。プラグインの更新やシステム全体へのJavaScriptを伴う作業は、別ドメインへ逃がすのが安全です。

kintone開発者ライセンスの取得手順と本番環境との仕様の違い

別ドメインを無償で持つ手段がkintone開発者ライセンスです。公式の案内では、顧客向け・自社向けの開発とテスト、開発スキルの習得に使う環境と位置づけられています。申し込みの制約と使える範囲を、取得前に確認しておきます。

1人1環境・契約済みアドレス不可など申し込みの制約と発行までの流れ

申し込みは公式の申し込みフォームから行い、発行までは約10分です。30分を過ぎても通知メールが届かないときは問い合わせ窓口へ連絡します。詰まりやすいのは次の制約です。

開発者ライセンスは1人につき1環境で、1つのユーザーアカウントを複数人で共用できない
kintoneを契約しているメールアドレスと、30日間のお試しに使ったメールアドレスでは申し込めない（エラーSD-001）
お試し環境を開発者ライセンスに切り替えることも、開発者ライセンスを有償契約へ切り替えることもできない

会社の本番環境の管理者が自分のアドレスで申し込むと、2番目の制約で弾かれます。開発用のメールアドレスを別に用意してから申し込むと手戻りがありません。

申し込みから初回ログインまでの手順とログインできないときの対処

公式ページが示す流れは「フォームから申し込む」「メールが届く」「学習コンテンツで学ぶ」の3ステップです。実務では、次の順で進めると後の更新や引き継ぎで困りません。

開発専用のメールアドレス（個人ではなくチームで受信できるもの）を用意する
申し込みフォームに入力して送信し、約10分後に届く利用開始メールでサブドメインとログイン名を控える
cybozu.com共通管理でテスト用ユーザーを作り、システム管理者・一般利用者など役割ごとに割り振る
サイボウズドットコムストアでサービス終了日を確認し、更新期限をカレンダーに登録する

ログインできなくなったときは、パスワードのリセットを先に試します。ログイン名もリセット用のアドレスも分からない場合は、ストアの「ドメイン管理」から「一時的な管理者」を作成する方法がありますので、そちらを試してください。一時的な管理者は作成から約1時間で自動停止されるので、その間に新しいcybozu.com共通管理者を追加しておきます。ストア管理者のアドレスまで使えなくなった環境は救済されず、別アドレスで申し込み直すしかありません（いずれも開発者ライセンス案内ページのFAQ、2026年10月時点）。

もう1つ見落としやすいのが会社コードの扱いです。開発者ライセンスを持つ会社コード（ストアで管理される単位）の配下で作ったサブドメインは、お試し環境も含めて有償契約へ切り替えられません。本番を契約するストアのアカウントと、開発者ライセンスを申し込むアカウントは最初から分けておきます。

5ユーザー・25GB固定とスタンダード相当で使える機能・使えない機能

開発者ライセンスはスタンダードコースとほぼ同等の環境で、ユーザー数5人・ディスク容量25GBは変更できません（2026年10月時点の案内）。開発で使う機能はおおむね揃っています。

区分	機能	条件
使える	API実行・プラグイン開発	制限なし
使える	JavaScript／CSSカスタマイズ	制限なし
使える	IPアドレス制限・BASIC認証	制限なし
期間付き	ゲストユーザー・ゲストスペース	ゲストユーザーは作成から30日間
期間付き	セキュアアクセス・メール共有オプション	30日間の試用の範囲内
使えない	kintone AI・データリストアなどのサービス	対象外

ゲストユーザーは30日を過ぎると「上限値を超過しています」という趣旨のメールが毎日届きます。開発者ライセンスの環境では購入手続きができないため、30日を過ぎたゲストユーザーは削除し、必要なら作り直す運用になります。

kintone AIを組み込む開発や、セキュアアクセス前提の動作確認を長く続ける案件は、開発者ライセンスだけでは検証しきれません。後述の判断章で、有償の検証環境に切り替える条件として扱います。コースごとの機能差や料金体系そのものを確認したい場合は、kintoneのできること・料金・コースの違いをまとめた解説を先に読むと、スタンダード相当という条件の意味がつかめます。

利用規約で禁じられた使い方と本番データを入れてはいけない理由

kintone開発者ライセンス利用規約（2023年12月15日改定版）を読むと、開発者ライセンスは「kintone APIを使用した開発の目的に限り」使える環境です。規約とFAQから、実務で引っかかりやすい条件を拾うと次のとおりです。

条件	根拠	実務での影響
開発目的に限る	規約第3条	社内の業務利用や顧客向けデモには使えない
同一人物の複数申し込みは不可	規約第2条	案件ごとに環境を増やせない
有償利用中のサブドメインは対象外	規約第2条	本番ドメインを開発者ライセンスに変えられない
サイボウズが承諾なく環境へアクセスできる	規約第3条	実在の個人情報を置かない
1年以上使わないと停止・削除されうる	規約第3条	放置した環境は残る保証がない
疑問はコミュニティで自己解決	規約第3条	有償契約のような問い合わせ窓口は前提にしない

特に効いてくるのは4番目です。規約は、不具合の調査や改良のためにサイボウズが利用者の承諾を得ずに開発環境へアクセスし、入力データの閲覧・複製・削除ができると定めています。本番の顧客情報や社員情報をそのまま検証環境へ持ち込むと、社内の情報管理規程と衝突する可能性があります。テストデータは氏名や連絡先を架空の値に置き換えたものを用意し、本番データでしか再現しない不具合は、本番側の動作テスト環境やマスキング済みデータを使って、不具合を確かめてください。ポートフォリオやデモサイトとしての利用も公式FAQで明確に禁止されているため、営業用のデモ環境は有償契約で別に持つ必要があります。

12か月の利用期間と更新申請の期限、失効でデータが消える注意点

利用期間は発行日から12か月で、更新は無料ですが申請が必要です。案内メールは終了の60日前・30日前・7日前に、サイボウズドットコムストア管理者のアドレスへ[email protected]から届きます。申請期限は終了日ではなくその3日前で、期限を過ぎると申請フォーム自体が無効になります。終了日の翌日から環境に入れなくなり、再申し込みにはストアのアカウント削除が要るうえ、前の環境のデータは引き継がれません。

更新の担当者が退職や異動でいなくなると、検証用アプリとテストデータがまとめて消えます。申請完了時に表示される申請IDはスクリーンショットで保存し、更新期限と一緒にチームの共有カレンダーと手順書に残しておくのが確実です。更新後にログインできない場合の問い合わせでも、この申請IDを求められます。

失効や誤削除に備えて検証環境のアプリとレコードを書き出す手順

開発者ライセンスではデータリストアのサービスを受け付けていないため、消えたものを戻す手段は自分たちの書き出ししかありません。更新漏れに限らず、検証中の一括削除やフィールド削除でも同じことが起きます。複数のアプリの情報を取得するAPIでアプリIDを一覧にし、cli-kintoneのrecord exportでレコードと添付ファイルを、customize exportでJavaScript・CSSを書き出すスクリプトを用意しておきます。

#!/usr/bin/env bash
# backup-dev.sh：開発者ライセンス環境の全アプリを書き出す（jqが必要）
set -euo pipefail
set -a
source ".env.dev"
set +a
STAMP="$(date +%Y%m%d)"
# apps.jsonはパスワード認証で呼ぶ（APIトークン認証には対応していない）
AUTH="$(printf '%s:%s' "${KINTONE_USERNAME}" "${KINTONE_PASSWORD}" | base64 | tr -d '\n')"
APP_IDS="$(curl -s -H "X-Cybozu-Authorization: ${AUTH}" \
  "${KINTONE_BASE_URL}/k/v1/apps.json?limit=100" | jq -r '.apps[].appId')"
for ID in ${APP_IDS}; do
  DIR="backup/${STAMP}/app-${ID}"
  mkdir -p "${DIR}"
  # レコードはCSV、添付ファイルはフィールドコードとレコードIDごとのフォルダへ出る
  npx cli-kintone record export --app "${ID}" --attachments-dir "${DIR}/files" > "${DIR}/records.csv"
  # JavaScript・CSSの設定とファイル本体
  npx cli-kintone customize export --app "${ID}" --output "${DIR}/customize-manifest.json" --yes
done

apps.jsonのlimitは1〜100で、101個以上のアプリがある環境ではoffsetを足して繰り返します。record exportはテーブル内のフィールドを--fieldsで個別に指定できない点に注意してください。フォームの構成そのものはこのスクリプトでは残らないため、主要なアプリは画面からテンプレートとしても書き出しておくと、環境を作り直したときにアプリごと復元できます。書き出したCSVにはテストデータしか入っていない前提ですが、Gitに入れる場合はリポジトリの公開範囲を確認してください。

ローカルの開発環境を構築する手順｜Node.jsとcli-kintoneの導入

検証用のドメインを用意したら、手元のPCにコマンドラインの道具を揃えます。2026年に入って公式ツールの構成が大きく変わったため、古い手順書のまま進めないよう注意してください。

Node.js 20以上とcli-kintoneの導入、旧js-sdkツールとの対応関係

現行の公式CLIはnpmパッケージ@kintone/cliで、コマンド名はcli-kintoneです。npm registryで確認した最新版は1.22.1（2026年10月14日公開）で、動作要件はNode.js 20以上です。cli-kintoneのInstallationにあるとおり、npmを使わずにGitHubのReleasesからWindows・macOS・Linux向けのバイナリを入れる方法もあります。

# Node.jsの版を確認（v20以上が必要）
node --version

# プロジェクトごとに入れて版を固定する
npm install --save-dev @kintone/cli @kintone/dts-gen
npx cli-kintone --version

以前はプラグイン作成・パッケージング・アップロード、カスタマイズの適用が別々のパッケージでした。js-sdkからの移行ガイドの対応は次のとおりで、旧パッケージはnpm上で「No longer maintained」と表示されています。

旧パッケージ	cli-kintoneのコマンド
@kintone/create-plugin	plugin init
@kintone/plugin-packer	plugin keygen・pack
@kintone/plugin-uploader	plugin upload
customize-uploader	customize init・apply

鍵の生成はplugin keygen、zip化はplugin packと2コマンドに分かれました。既存アプリの適用内容を書き出すcustomize exportも、customize-uploaderのimportに当たる機能です。グローバルに入れず--save-devでプロジェクトに入れておくと、メンバー間でCLIの版がずれません。

接続先と認証情報を環境変数で切り替える.envファイルと実行スクリプト

cli-kintoneのOptionsによると、--base-url・--username・--passwordはそれぞれKINTONE_BASE_URL・KINTONE_USERNAME・KINTONE_PASSWORDの環境変数で渡せます。ゲストスペースはKINTONE_GUEST_SPACE_ID、BASIC認証はKINTONE_BASIC_AUTH_USERNAMEとKINTONE_BASIC_AUTH_PASSWORDです。環境ごとにファイルを分け、コマンド本体には接続先を書かない形にします。

# .env.dev（開発者ライセンスの環境。Gitには入れない）
KINTONE_BASE_URL=https://example-dev.cybozu.com
KINTONE_USERNAME=dev-admin
KINTONE_PASSWORD=change-me
KINTONE_APP_ID=12

# .env.prod（本番環境。Gitには入れない）
KINTONE_BASE_URL=https://example.cybozu.com
KINTONE_USERNAME=deploy-user
KINTONE_PASSWORD=change-me
KINTONE_APP_ID=34

#!/usr/bin/env bash
# deploy.sh：./deploy.sh dev または ./deploy.sh prod で実行する
set -euo pipefail
ENV_NAME="${1:?dev か prod を指定してください}"
set -a
source ".env.${ENV_NAME}"
set +a
if [ "${ENV_NAME}" = "dev" ]; then
  npx cli-kintone customize apply --app "${KINTONE_APP_ID}" --input customize-manifest.json --yes
else
  # 本番は確認プロンプトを残すため --yes を付けない
  npx cli-kintone customize apply --app "${KINTONE_APP_ID}" --input customize-manifest.json
fi

KINTONE_APP_IDはcli-kintoneが読む変数ではなく、スクリプト内で--appに渡すための自前の変数です。検証環境と本番ではアプリIDが一致しないので、URLと同じファイルで管理しておくと取り違えを防げます。.gitignoreに.env.*を足すことも忘れないでください。

kintone-dts-genでフィールドの型定義を生成しTypeScriptで書く準備

TypeScriptで書くなら、kintone-dts-genでアプリのフィールド定義から型定義ファイルを作ります。npm registryの最新版は9.0.9で、こちらもNode.js 20以上が要件です（2026年10月時点）。

npx kintone-dts-gen --base-url https://example-dev.cybozu.com -u dev-admin -p change-me --app-id 12

実行したディレクトリにfields.d.tsが出力され、型のキーには表示名ではなくフィールドコードが使われます。型を生成するのは検証環境のアプリにしておき、本番とフィールドコードが揃っているかを型のずれで検出できるようにすると、反映時の「フィールドが見つからない」エラーを減らせます。パスワードをコマンド履歴に残したくない場合は、APIトークン認証も選択肢です。

検証環境から本番環境へカスタマイズを反映する手順と引き継げない設定

環境を分けた後の課題は、検証で確かめたものを本番へ同じ状態で持ち込むことです。ファイルの反映とアプリ設定の反映は、道具も注意点も別になります。

customize exportで本番の現状を書き出し、差分を見てから反映する手順

画面からファイルを入れてきた本番アプリは、まず現状をコードに起こします。customize exportは--appが必須で、対応する認証方法はユーザー名とパスワードのみです。書き出したファイルはマニフェストと同じ階層のdesktop・mobile配下に置かれます。

.env.prodを読み込んでnpx cli-kintone customize export --app 34 --output prod/customize-manifest.jsonを実行し、本番の現状をGitに記録する
customize initで作った開発用マニフェストと書き出した内容を突き合わせ、本番だけにあるファイルやCDNのURLを取り込む
検証環境に./deploy.sh devで当て、PCとモバイルの両方で動作を確かめる
差分をレビューしてから./deploy.sh prodで本番に当てる

customize applyのマニフェスト内のパスはマニフェストの場所を基準に解決され、ローカルファイルとCDNのURLを混在させられます。一覧画面での具体的なマニフェストの書き方はkintone一覧カスタマイズの実装手順で、適用までの流れを例示しています。

アプリテンプレートで検証用アプリを複製したときに引き継がれない設定

本番アプリを検証環境に複製するには、アプリをテンプレートとしてダウンロードして別ドメインで読み込みます。アプリの管理権限とkintoneシステム管理権限の両方が要り、［アプリを更新］していない変更はテンプレートに入りません。ルックアップなどで参照しているアプリも含まれ、上限は100アプリです。

見落としやすいのが、アプリテンプレートに含まれない設定です。

プラグインの設定（有効／無効の状態だけは引き継がれる）
APIトークン・Webhook・Slack連携・アプリコード
アクセス権の設定
ユーザー選択の候補と初期値、一覧やグラフの絞り込み条件、プロセス管理の作業者、通知先などユーザー・組織を使った設定

プラグインの設定とAPIトークンが抜けると、複製したアプリでは連携処理が認証エラーで止まります。複製のたびに戻す項目を手順書の固定項目にしておくと、検証の初動で迷いません。

REST APIで設定を変える場合の動作テスト環境と運用環境への反映

フィールド追加や一覧設定をスクリプトで変える場合、変更はまず「動作テスト環境」に入り、アプリの設定を運用環境へ反映するAPIを呼ぶまで利用者には見えません。これは設定画面の［アプリを更新］と同じ操作で、アプリの作成と設定変更の流れがSTEP3として説明しています。

POST /k/v1/preview/app/deploy.json
{
  "apps": [
    { "app": 34, "revision": 13 }
  ],
  "revert": false
}

revisionに期待するリビジョン番号を入れると、他の人が先に設定を変えていた場合にエラーで止まり、上書き事故を防げます。反映は非同期で、複数アプリを指定して1つでも失敗すると、すべて実行前に戻る仕様です。revertをtrueにすれば、動作テスト環境の変更を捨てて運用環境と同じ状態に戻せます。開発者ライセンスの案内にもあるとおり、別ドメインの変更を本番へ自動で同期する機能はkintoneにはないので、ドメインをまたぐ設定変更については、このAPIを本番側で改めて実行し直す手順が必要です。外部システムとの連携を検証環境で試す場合は、同時接続数や1日あたりのリクエスト上限が本番と同じ考え方で効いてくるため、kintoneのデータ連携方式とAPI制限の設計で上限を確かめてから負荷のかかる試験を組みます。

開発環境を整えるべき体制と、本番直編集で済ませてよい場面の判断

環境分離には、環境を用意して管理する手間が必要です。どこまで整えるかは、案件の大きさではなく、壊れたときに誰が困るかで決めます。kintone開発全体の手段と費用感から考えたい場合は、判断側のkintoneカスタマイズ・開発の手段と費用相場、内製外注の判断が前提整理に向いています。

開発者ライセンスで足りる条件と有償の検証環境を契約すべき条件

開発者ライセンスで足りるのは、検証に必要なユーザーが5人以内で、kintone AIを使わず、データ量が25GBに収まる場合です。中小規模のカスタマイズやプラグイン開発の大半はここに入ります。

有償で検証用ドメインを契約すべきなのは、組織・グループごとのアクセス権を本番と同じ構造で再現したい場合と、セキュアアクセスやkintone AIを継続的に検証する場合です。顧客や社内向けのデモ環境が要る場合も、規約上は有償契約で用意します。kintoneの料金ページではスタンダードコースが1ユーザー月額1,800円（税抜）・最小10ユーザーなので、検証用でも月額18,000円からかかります（2026年10月時点）。アクセス権の不具合が情報漏えいに直結する業務なら、この費用は払う価値があります。

1人1環境の開発者ライセンスを複数人のチーム開発で使い分ける方法

開発者ライセンスは1人1環境で、アカウントの共用もできません。チームで開発するときは、環境の役割を次のように分けると規約の範囲で回ります。

環境	持ち主	用途
個人の開発者ライセンス	開発者それぞれ	コードを書いて単体で動かす
共有の結合テスト環境	発注側（有償契約）	複数人の変更を合わせ、権限込みで確かめる
本番環境	発注側	反映担当者のみ`customize apply`を実行

個人の環境では、5ユーザーの枠を管理者・申請者・承認者・閲覧のみなど役割別のテストユーザーに割り当てます。各自の環境はドメインもアプリIDも違うため、.env.devは個人ごとに持ち、Gitで共有するのはマニフェストとソースコードだけにします。メンバーが抜けるときは、その人の開発者ライセンスの更新が止まる前に、前章のスクリプトで必要なアプリを書き出し、後任のメンバーへ引き継いでください。結合テストまで個人の環境で済ませようとすると、誰の環境が正なのかが曖昧になり、本番反映の前に確認した状態を再現できなくなります。

環境分離を省いて失敗する典型パターンと外部委託で確認する受け渡し範囲

本番直編集で済ませてよいのは、対象が1アプリで、担当者が1人、修正を元に戻すためのファイルが手元に必ず残る場合に限られます。この条件を外れて直編集を続けると、次の失敗が起きます。

2人が同じアプリのJavaScriptを別々にアップロードし、先に入れた修正が消える
フィールドコードを画面で変えた瞬間に、そのコードを参照するJavaScriptとプラグインが一斉に止まる
更新したプラグインが他のアプリでも動いていて、修正対象外の業務まで止まる

開発を外部に委託するときは、検証環境をどちらが用意するか、customize-manifest.jsonとソースコード・秘密鍵を誰が持つか、本番への反映を誰が実行するかを契約前に決めておきます。受託側の担当者が自分の開発者ライセンスで作業する場合、その環境は担当者個人に紐づくため、納品物はコードとマニフェスト、テンプレートとして受け取る取り決めにしておくと、担当交代で検証環境ごと失う事態を避けられます。自治体の調達でも、受託者がテスト環境を用意する前提が質疑で確認される例があるため、用意する側を明確にしてください。プラグインの秘密鍵の扱いはkintoneプラグイン開発のmanifest構成から配布までの手順で詳しく触れています。

社内に担い手がいない、または既存の直編集カスタマイズを整理したい場合は、一創のkintone導入支援で、検証環境と本番の分け方、反映の手順づくりから相談できます。プラグイン化まで見据えるならkintoneプラグイン開発で、コード管理への移行とあわせて進められます。

よくある質問

kintone開発者ライセンスと開発環境について、構築前によく出る疑問に答えます。

kintoneの開発者ライセンスは無料で使えますか？

無料です。申し込み・利用・12か月ごとの更新のいずれも料金はかかりません。ただし開発目的に限られ、本番運用やポートフォリオ・デモサイトとしての利用は禁止されています。ユーザー数5人・ディスク25GBは固定で増やせないので、それを超える検証が必要になった時点で有償契約の環境を別に用意します。

30日間のお試し環境を開発環境として使い続けられますか？

使い続けられません。お試しは30日で終わり、開発者ライセンスへの切り替えもできない仕様です。さらに、お試しで使ったメールアドレスでは開発者ライセンスを申し込めません（エラーSD-001）。お試しのアカウントを削除してから申し込み直す方法もありますが、長く使う開発環境が欲しいなら、最初から別のメールアドレスで開発者ライセンスを申し込むのが近道です。

開発者ライセンスの環境で作ったアプリを本番へ移せますか？

移せます。アプリをテンプレートとしてダウンロードし、本番側で読み込む方法が基本です。JavaScriptとCSSはcli-kintoneのcustomize applyで本番アプリへ当て直します。プラグインの設定、APIトークン、Webhook、アクセス権はテンプレートに含まれないため、本番側で設定し直してください。開発者ライセンスの環境そのものを有償契約に切り替えることはできません。

開発者ライセンスの更新を忘れたらデータは戻せますか？

戻せません。申請期限（終了日の3日前）を過ぎると終了日の翌日から環境に入れなくなり、再申し込みしても前の環境のデータは引き継がれません。開発者ライセンスはデータリストアの対象外でもあるため、更新期限をカレンダーで管理し、アプリとレコードを定期的に書き出しておくことが唯一の備えになります。

customize-uploaderやplugin-uploaderはまだ使えますか？

npm上では「No longer maintained」と表示され、cli-kintoneへの移行が案内されています（2026年10月時点）。今動いているスクリプトがすぐ止まるとは限りませんが、不具合や仕様変更への追従は期待できません。npm scriptsやCIの呼び出しをcli-kintone customize applyやcli-kintone plugin uploadへ置き換えておくと安心です。