Next.jsアプリの保守引き継ぎ｜前の開発会社から受け取る3つと、改修前に確かめること

前の開発会社との契約が終わる。社内でシステムを作った担当者が退職する。Next.jsで作った業務システムやサイトの保守を引き継ぐ場面は、たいてい十分な準備期間がないまま来ます。

この記事は、保守を引き継ぐ側の情シス担当の方に向けて、前任者と連絡が取れるうちに何を受け取り、新しい保守担当が作業を始める前に何を確かめるかを、Next.js固有の確認箇所に絞って整理したものです。

先に、要点をまとめます（2026年10月13日確認）。

• 最初にそろえるのは、リポジトリの全量、本番を動かすアカウントの管理者権限（ホスティング・データベース・ドメイン）、環境変数の一覧の3つです。この3つがあれば、仕様書がなくても調査を始められます
• 受け取ったら、そのコードが本番と同じ版かと、手元でbuildできるかを先に確かめます。ここがずれたまま改修を始めると、直したはずの不具合が本番で直らない、出すつもりのない変更が本番に混ざる、といったことが起きます
• Next.jsとNode.jsのサポート期限も同時に確認します。Next.js 15系のサポートは2026年10月21日に終わり、Node.js 20系は2026年4月30日に終わっています

前任者とすでに連絡が取れない場合も、確かめる項目は同じです。違うのは、アカウントの名義が誰にあるかを先に調べる点です。

Next.jsアプリの引き継ぎで、最初に受け取るものは何？

リポジトリの全量、本番を動かすアカウントの管理者権限、環境変数の一覧の3つです。ソースコードのzipだけを受け取っても、本番を更新する手段がないため保守は始められません。

Next.jsのアプリは、コードだけでは動いていません。ホスティング（Vercel、Firebase App Hosting、AWSなど）、データベースや認証（Firebase、Supabaseなど）、ドメインとDNS、外部サービスのAPIキーがそろって、はじめて本番が動いています。受け取るものを一覧にすると次のとおりです。

この中で、後から取り戻すのにいちばん手間がかかるのはアカウントの名義です。次の節で詳しく見ます。

アカウントの持ち主は、なぜ最初に確認する？

名義が前任の会社や個人にあると、契約が終わった時点で本番を更新できなくなるおそれがあるからです。引き継ぎでは「ログインできる」状態ではなく、「自社が管理者である」状態を作ります。

主なサービスには、名義や管理者を移す手段が用意されています。ただし、操作できるのは今の管理者だけです。前任者と連絡が取れるうちに済ませます。

• Vercel：プロジェクトを別のチームへ移す機能があります。移す元のチームのOwnerであり、移す先のチームのメンバーであることが条件です。デプロイ・環境変数・ドメインは移りますが、連携しているIntegrationは移った後に設定し直す必要があり、ログやモニタリングのデータは移りません（Vercel: Transferring a project）
• Firebase：プロジェクトを「譲渡」するのではなく、自社のGoogleアカウントにオーナー（Owner）のロールを付けてもらいます。Ownerは、メンバーとロールの管理、課金の設定、プロジェクトの削除ができるロールです（Firebase: Basic roles）。あわせて、課金先のCloud Billingアカウントが前任者の名義になっていないかも確かめます
• GitHub：リポジトリを自社のOrganizationへ移せます。移す元のリポジトリの管理者権限と、移す先でリポジトリを作る権限が必要です。Actionsのシークレットやデプロイキーは移した後も残るため、中身の入れ替えは別に行います（GitHub Docs: Transferring a repository）

前任者と連絡が取れない場合は、自社名義で契約しているサービスから管理者を取り戻すところから始めます。名義が前任者側にあるものは、開発委託の契約書で、成果物の権利と引き渡しの範囲がどう書かれているかを確認してから相談することになります。

自社が管理者になっても、前任者の権限を外すのは最後にします。調査の途中で聞きたいことが出てくるためです。外す日を先に決めておき、その日に後述する鍵の入れ替えと一緒に行います。

受け取ったコードが本番と同じか、どう確かめる？

ホスティングのデプロイ履歴で、本番に出ているコミットを特定します。受け取ったリポジトリにそのコミットがあり、手元でbuildが通れば、そこを調査の起点にできます。

注意したいのは、本番には出ているのに、リポジトリに入っていない変更があるケースです。前任者の手元のパソコンから直接デプロイしていた場合や、本番用とは別のブランチから出していた場合に起きます。

確かめる順序は次のとおりです。

1. ホスティングの管理画面で、本番に出ている最新のデプロイのコミットIDを見る（Vercelはデプロイの一覧、Firebase App Hostingはロールアウトの履歴に、ソースのコミットが表示されます）
2. 受け取ったリポジトリで git log を見て、同じコミットがあるか確かめる
3. そのコミットをチェックアウトし、ロックファイルどおりに依存パッケージを入れてbuildする

git checkout <本番のコミットID>
npm ci          # package-lock.json どおりに入れる（pnpm・yarnはそれぞれのロックファイル）
npx next info   # Next.js・React・Node.jsのバージョンを表示
npm run build

next info は、OSとNode.jsのバージョン、next・react・react-dom などの関連パッケージのバージョンを表示するコマンドです（Next.js: next CLI）。

buildが失敗したときに最初に疑うのは、環境変数の不足とNode.jsのバージョン違いです。ロックファイル（package-lock.json など）がリポジトリにない場合は、本番と同じバージョンの依存パッケージを再現できません。そのときは、本番のbuildログに出ている依存のバージョンを控えてから進めます。

本番のコミットがリポジトリに見つからなかった場合は、改修を始める前に、本番と同じ状態をリポジトリに取り込み直すことを先にします。

環境変数と秘密情報は、どう棚卸しする？

コードから process.env. の参照を抜き出して名前の一覧を作り、ホスティングに登録されている値と突き合わせます。引き継いだ後は、前任者が知っている鍵をすべて発行し直します。

Next.jsの環境変数には、扱いの違う2種類があります（Next.js: Environment Variables）。

• NEXT_PUBLIC_ で始まるもの：next build の時点でJavaScriptに埋め込まれ、ブラウザへ配信されます。秘密にすべき値を入れてはいけません。build後に値を変えても反映されないため、変えたら再buildが必要です
• それ以外：サーバー側（Route Handler、Server Action、Server Component）だけで読めます。APIキーやデータベースの接続情報はこちらに置きます

名前の一覧は、次のような小さなスクリプトで作れます。あわせて、ページ・Route Handler・Server Actionの数、proxy.ts（15系までの名前は middleware.ts）の有無、Node.jsのバージョン指定とロックファイルの有無も出します。

// handover-inventory.mjs — 使い方: node handover-inventory.mjs <リポジトリのパス>
import { readFileSync, existsSync, readdirSync, statSync } from "node:fs";
import { join, relative } from "node:path";

const root = process.argv[2] ?? ".";
const skip = new Set(["node_modules", ".next", ".git", "dist", "out"]);
const files = [];
(function walk(dir) {
  for (const name of readdirSync(dir)) {
    if (skip.has(name)) continue;
    const p = join(dir, name);
    if (statSync(p).isDirectory()) walk(p);
    else if (/\.(ts|tsx|js|jsx|mjs|cjs)$/.test(name)) files.push(p);
  }
})(root);

const rel = (p) => relative(root, p);
const read = (p) => readFileSync(p, "utf8");
const env = new Set();
for (const p of files) for (const m of read(p).matchAll(/process\.env\.([A-Z0-9_]+)/g)) env.add(m[1]);
const pkg = JSON.parse(read(join(root, "package.json")));

console.log({
  next: pkg.dependencies?.next,
  engines: pkg.engines ?? "未指定",
  nodeVersionFile: [".nvmrc", ".node-version"].filter((f) => existsSync(join(root, f))),
  lockfile: ["package-lock.json", "pnpm-lock.yaml", "yarn.lock"].filter((f) => existsSync(join(root, f))),
  pages: files.filter((p) => /\/app\/.*\/?page\.(t|j)sx?$/.test(p)).length,
  routeHandlers: files.filter((p) => /\/app\/.*route\.(t|j)s$/.test(p)).length,
  serverActionFiles: files.filter((p) => /^\s*["']use server["']/m.test(read(p))).length,
  proxyOrMiddleware: files.map(rel).filter((p) => /^(src\/)?(proxy|middleware)\.(t|j)s$/.test(p)),
  envVars: [...env].sort(),
});

当社のこのサイト（nextjs.zetlinker.com）のリポジトリで実行した結果は、次のとおりです（2026年10月13日）。

自社のサイトでも、16系で非推奨になった middleware.ts という名前のままで、Node.jsのバージョン指定もありませんでした。どちらも今すぐ動かなくなるものではありません。ただ、引き継ぐ側から見ると「どのバージョンのNode.jsで動かす前提か」を、ホスティングの設定から逆算する必要があります。middleware.ts から proxy.ts への置き換えはNext.js公式のcodemodで行えます（Next.js: proxy.js）。15から16への移行で一緒に直す箇所は、Next.js 15から16への移行手順にまとめています。

このスクリプトは、process.env[name] のような変数を使った参照や、apphosting.yaml・vercel.json などコード以外の設定ファイルに書かれた値は拾いません。最終的な一覧は、必ずホスティングの管理画面に登録されている環境変数と突き合わせて作ります。

引き継いだ後に入れ替える鍵は？

前任者が値を知っている鍵は、引き継ぎが終わったら発行し直します。対象は次のとおりです。

• 外部サービスのAPIキー（決済、メール送信、AIのAPIなど）
• データベースのサービスアカウントの鍵
• セッションの署名などに使っている認証用のシークレット
• GitHub Actionsのシークレットと、デプロイ用のトークン

入れ替えは、新しい鍵を発行する → ホスティングに登録する → 再デプロイする → 動作を確認する → 古い鍵を無効にするの順で行います。順序を逆にすると、新しい鍵が反映されるまでの間、本番が外部サービスにつながらなくなります。NEXT_PUBLIC_ の値を変えた場合は、再デプロイではなく再buildが必要です。

.env ファイルが過去に一度でもリポジトリへ入っていないかは、次のコマンドで確かめられます。

git log --all --oneline -- '.env*'

履歴に出てきた場合は、その鍵はすでに外へ出たものとして扱い、発行し直します。履歴からファイルを消すだけでは、すでに複製されたリポジトリや手元のコピーには残るためです。

Next.jsとNode.jsのサポート期限は、どこを見る？

Next.jsは公式のサポートポリシー、Node.jsは公式のリリース予定表で確認します。2026年10月13日時点で本番に使えるのは、Next.js 16系とNode.js 22系・24系の組み合わせです。

出典：Next.js Support Policy、Node.js Release schedule

Next.js 16系の package.json が求めるNode.jsは20.9以上ですが、20系自体のサポートが終わっているため、引き継ぎを機に22系か24系へそろえます。決めたバージョンは package.json の engines か .nvmrc に書いておくと、次に引き継ぐ人が迷いません。

引き継いだアプリが15系のままなら、10月21日を過ぎると、脆弱性が見つかっても15系の修正版は出なくなります。期限を過ぎた後のリスクと移行の判断は、Next.js 15のサポート期限とEOL後の判断で整理しています。

仕様書がないとき、コードのどこから読めばいい？

App Routerのアプリは、app/ ディレクトリのフォルダ構成がそのまま画面のURLになっています。先に画面の一覧を作り、次にデータを書き換える入口を洗い出します。

読む順序は次のとおりです。

1. 画面の一覧：app/（または src/app/）の下の page.tsx を並べます。(admin) のような括弧付きのフォルダはURLに現れず、[id] のような角括弧のフォルダは値が入る部分です
2. データを書き換える入口：route.ts（Route Handler）と、'use server' を書いたファイル（Server Action）です。どちらも外部から呼べるため、それぞれの処理の中で、ログインと権限を確かめているかを見ます
3. リクエストの前処理：proxy.ts（または middleware.ts）と、next.config のリダイレクト・ヘッダーの設定
4. 環境変数：前の節で作った一覧
5. データの構造と守り方：Firestoreなら firestore.rules（セキュリティルール）とインデックスの定義

2番目は、引き継ぎ調査でとくに時間をかけたい箇所です。Next.jsの公式ドキュメントは、Server Actionは使われているページへのPOSTとして処理されるため、proxy の対象パスから外れると proxy での確認を通らないと説明しています。そのうえで、認証と認可は proxy だけに頼らず、Server Actionごとに確かめるよう求めています（Next.js: proxy.js）。

画面とデータの対応表づくりには、Claude CodeなどのAIコーディングツールも使えます。「このリポジトリの画面の一覧と、データを書き換える処理の一覧を表にして」と指示すると、たたき台が短時間で出てきます。ただし、権限の確認が漏れていないかの判断は人が行います。AIに任せる作業と人が判断する作業の分け方は、Claude Code × Next.js 16で受託開発はどう変わったかで扱っています。

引き継ぎ調査で、どの状態なら先に手を打つ？

秘密の値が外に出ている、外部から認可なしに呼べる入口がある、本番を再現できない、の3つは改修より先に対応します。サポート期限と通知先は、その次に片付けます。

調査で確かめる箇所と、問題がある場合の対応を表にまとめます。

上の3行は、放置すると情報漏えいや不正な操作につながる状態です。見つかったら、機能の追加や画面の改修より先に直します。

引き継いだ後は、どの順で作業する？

受け取る → 確かめる → 入れ替える、の順です。鍵の入れ替えと前任者の権限の取り消しは、調査が終わってから同じ日にまとめて行います。

1. 受け取る：リポジトリ、アカウントの管理者権限、環境変数の一覧をそろえる
2. 確かめる：本番と同じコミットか、手元でbuildできるか、サポート期限は大丈夫かを確認し、画面と入口の一覧を作る
3. 入れ替える：鍵を発行し直し、前任者の権限を外し、通知の送り先を変える。Next.jsとNode.jsの更新計画を決める

ここまで済んでから、保守の範囲と体制を決めます。月額の保守に何を含めるか、更新の判断と適用を誰が担うかは、Next.js保守運用の費用と契約とNext.jsのCVE対応は誰がやるのかで整理しています。

ゼットリンカーでは、引き継ぎをどう進めるか？

改修の見積もりより前に、上の表を埋める調査から始めます。仕様書がなくても、リポジトリとアカウントの一部がそろえば調査はできます。

私たちが保守の引き継ぎをご相談いただいたときは、本番と同じコミットの特定、buildの再現、環境変数と入口の一覧づくりを先に行い、その結果をもとに保守の範囲と更新の計画をご提案しています。前任者と連絡が取れない、どのアカウントが誰の名義か分からない、という段階からでもご相談いただけます。

まとめ

• 最初にそろえるのは、リポジトリの全量、本番を動かすアカウントの管理者権限、環境変数の一覧の3つです
• 改修を始める前に、本番と同じコミットを特定し、手元でbuildを再現します
• 鍵の入れ替えと前任者の権限の取り消しは、調査が終わってから同じ日に行います

本記事はNext.js 16.x時点の情報です。サービスごとの名義変更の手順やサポート期限は変わることがあるため、作業の前に各サービスの公式ドキュメントで最新の内容を確認してください。