Excel台帳をNext.jsに移行する設計｜データ移行で失敗しない5つの手順とAI活用のコツ

Excel台帳を何年も継ぎ足しながら運用している中小企業は少なくありません。ある日、シートを開くのに数秒待たされるようになった、担当者しか触れない「秘伝の関数」が増えた、締め日になると複数人での同時編集が衝突する——こうした兆候が重なると、そろそろ業務システム化を検討するタイミングです。ただし、多くの企業が本当に苦労するのは「作る」ことではなく「今のExcelデータをどう新システムに載せ替えるか」です。本記事では、Next.js製の社内システムへExcel台帳を移行する際の設計と手順を、実務目線で整理します。

先に、要点をまとめます。

• Excel台帳の移行で最初につまずくのは「表記ゆれの統一」と「型の不一致」で、ここを軽視すると新システム側でエラーが多発します
• 移行は「一括切り替え」ではなく、データ検証・並行運用・段階的な機能移管という3段階で進めると失敗しにくくなります
• AI駆動開発により、CSVパーサーやバリデーションスクリプトの実装コストは以前より大きく下がっています

こんな状況ではありませんか？

• 「顧客名」「お客様名」「取引先名」のように、同じ意味の列がシートによって表記が違い、統合しようとすると突き合わせに時間がかかる
• マクロやVLOOKUPを組んだ担当者が異動・退職し、シートの中身を誰も正確に説明できなくなっている
• 業務システムを新しく作ることは決まったが、「今のExcelの中身をどうやって移すか」で計画が止まっている

この記事で分かること

• Excel台帳のどこが新システム移行のボトルネックになりやすいか
• データクレンジング・移行スクリプト・並行運用を含めた段階的な移行手順
• 費用感の目安と、移行でよくある失敗パターンの回避策

なぜExcel台帳の移行は「作る」より「移す」が難しいのか？

新システムの画面を作る工数より、既存Excelのデータを整形して移す工数のほうが読みにくく、見積もりが外れやすいためです。

Next.jsで新しい画面を作ること自体は、要件さえ固まれば工数の見積もりが比較的容易です。一方でExcel台帳の中身は、何年もかけて現場が手作業で継ぎ足してきた「生きた資産」であり、ふたを開けてみないと実態が分かりません。

典型的には次のような問題が積み重なっています。

• 同じ項目でもシートごとに列名・入力形式が違う（例:「顧客名」と「お客様名」、日付が「2026/8/1」と「令和8年8月1日」の両方で混在）
• 手入力による表記ゆれ（全角・半角、法人格の有無、スペースの入り方）
• 空欄・仮入力・削除線での「論理削除」など、正規化されていないルールが暗黙のうちに存在する
• 1つのセルに複数の情報が詰め込まれている（例:「東京都渋谷区〇〇1-2-3（担当:山田）」のように住所と担当者名が同居）

これらは画面のUIとは無関係な問題ですが、放置したまま移行スクリプトを書き始めると、想定外のエラーが延々と出続けます。移行プロジェクトの体感的な「重さ」は、画面数ではなくデータの荒れ具合に比例すると考えたほうが実態に近いです。

Excelの限界を感じるサインは何か？

行数が数万件を超えて動作が重くなる、複数人での同時編集が締め日に衝突する、関数を触れる人が1人しかいない、の3つが代表的なサインです。

Excelは1シートあたり100万行超まで扱える仕様ですが、実務上は数万行を超えたあたりから、フィルタやVLOOKUPの動作が目に見えて重くなるという声が多く聞かれます。加えて、複数人が同じファイルを編集しようとして「編集中です」の表示に阻まれる、締め日にファイルの奪い合いが起きるといった運用面の限界も、業務システム化を検討すべきサインです。ここに「異動・退職で関数の中身を説明できる人がいなくなった」という属人化のサインが重なったら、後回しにするほど移行の難易度は上がっていきます。御社の台帳にこの3つのサインのうち2つ以上が当てはまるなら、移行の検討を始めてよいタイミングです。

データ移行はどんな手順で進めるべきか？

「現状調査→クレンジング→移行スクリプト実装→並行運用→本切り替え」の5段階で進めると、業務を止めずに移行できます。

ステップ1: 現状調査（1週間程度）

まず、対象のExcelファイルをすべて洗い出し、シートごとに「本当に使われている列」と「使われていない列」を仕分けます。長年運用されたファイルには、過去のある時期だけ使われて以降放置された列や、コメント代わりに使われているだけの列が必ず紛れ込んでいます。この段階で現場の担当者にヒアリングし、「この列は何のために存在するか」を1つずつ確認しておくと、後工程での手戻りが減ります。

ステップ2: データクレンジング（1〜2週間）

表記ゆれの統一ルールを決め、変換表を作ります。「株式会社」の表記統一、日付形式の統一、全角・半角の統一など、地味ですがここが移行プロジェクトの本丸です。全件を手作業で直すのは非現実的なので、正規表現によるパターンマッチと、パターンに当てはまらない例外だけを人が目視で確認する、という役割分担にすると現実的な工数に収まります。

ステップ3: 移行スクリプトの実装（1〜2週間）

クレンジング済みのCSVを、新システムのデータモデル（Firestoreのコレクション構造など）に合わせて変換し、投入するスクリプトを実装します。1回で成功させようとせず、「投入→検証→ロールバック→再投入」を何度でもやり直せる設計にしておくのが安全です。件数の少ないテスト環境で複数回試し、エラーパターンを洗い出してから本番データに適用します。

ステップ4: 並行運用（2〜4週間）

新システムと旧Excelを同時に運用し、日々の入力を両方に行いながら、金額や件数などの集計結果が一致するかを突き合わせます。並行運用は手間がかかりますが、ここを省略すると本切り替え後に「新システムの集計が合わない」という致命的な問題が業務時間中に発覚するリスクが残ります。並行運用の期間は、最低でも1回の締め日サイクルを含めることをおすすめします。

ステップ5: 本切り替え（1週間程度）

並行運用で問題が出なければ、Excelへの入力を停止し、新システムに一本化します。切り替え直後の1〜2週間は、Excelを閲覧専用として残しておき、いつでも過去データを参照できる状態にしておくと、現場の不安を減らせます。

データクレンジングは何を基準に進めればよいか？

「表記ゆれの統一ルール」「必須項目の定義」「例外データの扱い」の3つを先に決めてから、変換作業に着手するのが失敗しにくい進め方です。

クレンジングでもっとも時間がかかるのは、実は変換作業そのものではなく「どう統一するかのルール決め」です。ここを曖昧なまま進めると、変換をやり直す手戻りが発生します。

このルールを最初にドキュメント化しておくと、AIコーディング支援にクレンジングスクリプトを実装させる際の指示も具体的になり、生成されたコードのレビューもしやすくなります。

費用感はどれくらいを見ておくべきか？

Excel台帳1〜2本規模のデータ移行であれば、新システム本体の開発費とは別に、移行専用の工数として50万円〜150万円程度を見込んでおくのが目安です。

移行の費用は、シート数よりも「データの荒れ具合」に比例します。同じ数万行のデータでも、表記が統一されていて型が揃っているExcelと、10年分の運用で表記がバラバラになったExcelとでは、クレンジングにかかる工数が数倍変わることも珍しくありません。

見積もりを依頼する際は、対象のExcelファイルを実際に見せた上で相談すると、想定と実際の差が生まれにくくなります。「きれいなデータのつもりだったが、見てもらったら表記ゆれが想定以上だった」というケースは珍しくないため、早い段階でエンジニアに現物を確認してもらうことが、費用感のズレを防ぐ近道です。

AI駆動開発は移行のどこを速くするのか？

クレンジングルールに基づく変換スクリプトと、投入前のバリデーションチェックの実装が、AIコーディング支援によって大きく速くなります。

データ移行の作業は、「入力（バラバラなExcelの行）」と「出力（新システムのデータモデル）」の仕様さえ明文化できれば、実装そのものはパターン化された処理の組み合わせです。この性質は、Claude CodeなどのAIコーディング支援と相性が良い領域です。

私たちの開発では、クレンジングルールの一覧をドキュメント化した上で、「この変換表に従ってCSVをパースし、ルールに合わない行は別ファイルに出力するスクリプトを書いて」という形でAIに実装を任せることが多いです。人が時間を使うべきなのは、コードそのものよりも「表記ゆれの統一ルールをどう決めるか」「例外データをどう扱うか」という業務判断の部分です。ここを曖昧なまま実装だけAIに任せると、動くけれど業務の実態に合わないスクリプトができあがってしまいます。AIが速くしてくれるのはあくまで実装の部分であり、判断の質は依然として人に委ねられている、という線引きを意識しておくと、移行プロジェクト全体の精度が安定します。

移行でよくある失敗パターンと回避策は？

「一括切り替え」「並行運用の省略」「クレンジングルールの後決め」の3つが、移行プロジェクトが炎上する典型パターンです。

• 一括切り替えで現場が混乱する: ある日を境に全業務をExcelから新システムに切り替えると、慣れない画面と本来の業務が同時に発生し、現場の反発を招きます。まず1つの業務・1つの部署から段階的に移行するのが安全です。
• 並行運用を省略して本番投入する: 「テスト環境で動いたから大丈夫」と並行運用を飛ばすと、実データ特有の想定外パターンが本番稼働後に発覚します。最低でも1回の締め日サイクルは並行運用に充ててください。
• クレンジングルールを後から決める: 「とりあえず移行スクリプトを書きながら考えよう」と進めると、ルールが二転三転してスクリプトの手戻りが増えます。表記統一ルールは移行スクリプトの実装前に文書化しておきましょう。
• 旧Excelを移行直後に破棄する: 何か問題が起きたときに参照できる旧データが手元にないと、原因調査すら難しくなります。切り替え後もしばらくは閲覧専用で保持してください。
• 重複データを移行時にそのまま残す: 同じ顧客が表記ゆれで複数登録されているのを放置すると、新システム上でも同じ問題が再現します。移行のタイミングこそ、重複解消の最後のチャンスです。

Next.jsでの移行データの受け皿はどう設計するべきか？

Firestoreであれば、正規化されたコレクション構造に加えて「移行元の生データ」を保持する監査用コレクションを1つ持たせておくと、移行後のトラブル対応が楽になります。

移行データを投入する際、正規化後のデータだけを保存すると、後から「なぜこの値になったのか」を追跡できなくなります。migration_raw_recordsのような監査用コレクションに、変換前の元データとどのルールが適用されたかのログを残しておくと、移行後に問い合わせが来た場合も、元のExcelのどの行に由来する値かをすぐに追跡できます。この設計はストレージ容量をわずかに消費しますが、移行後数ヶ月にわたって発生しがちな「あの数字、元はどうなっていましたか」という問い合わせへの対応コストを大きく下げてくれます。

移行スクリプトはどの単位でテストするべきか？

1行単位の変換ロジックと、全件投入後の集計結果検証を分けてテストするのが基本です。

移行スクリプトのテストを「投入して動くかどうか」だけで確認すると、個々の行の変換ミスが集計値のズレとして紛れ込み、原因の特定に時間がかかります。まず1行分のサンプルデータに対して、変換前後の値が期待通りかを確認するユニットテストを書き、次に全件投入後の合計金額・件数といった集計値が旧Excel側の集計と一致するかを検証する、という2段階に分けておくと、問題が起きた際にどちらの層に原因があるかをすぐに切り分けられます。この2段階テストの設計自体も、変換ルールが明文化されていればAIコーディング支援に下書きさせやすい領域です。

移行後に新システムを定着させるには何が必要か？

移行が完了した直後こそ、現場が「前のExcelの方が早かった」と感じやすいタイミングであり、入力の手間を最小化する導線設計が定着の鍵になります。

新システムへの切り替え直後は、画面操作に慣れていないぶん、体感的な作業時間がExcel時代より長く感じられがちです。ここで離脱者が出ると、せっかく移行したデータも活用されないまま形骸化してしまいます。よくある工夫としては、頻繁に入力する項目ほど画面の上部に配置する、前回入力した値をデフォルトで引き継ぐ、入力ミスをその場でハイライトして手戻りを減らす、といった小さな改善の積み重ねです。移行プロジェクトの成功は「データが正しく移った日」ではなく「現場が自然に新システムだけを使うようになった日」で判断するのが実態に近い見方です。

まとめ：この記事で持ち帰れること

この記事を読むことで、次の2点が判断できるようになります。

• 自社のExcel台帳が「システム化のサイン」に当てはまっているかどうかの見極め方
• データ移行を「一括切り替え」ではなく「調査→クレンジング→移行→並行運用→切り替え」の段階を踏んで進める設計の全体像

Excel台帳の移行は、新システムの画面を作ることよりも、データの荒れ具合と向き合うことのほうが本質的な作業です。表記ゆれの統一ルールを先に決め、並行運用の期間を省略せずに確保すれば、業務を止めずに移行を進められます。

まずは今使っているExcel台帳を1つ開いて、「顧客名」のような同じはずの項目が何パターンの表記で入力されているかを数えてみてください。そこで感じた「思ったより多い」という感覚が、移行プロジェクトの本当の難易度を測る最初の手がかりになります。

自社のExcel台帳がどの規模の移行に当てはまるか、実際のファイルを見ながら整理したい方は、15分のカジュアル相談からご相談ください（事例・要件が固まっていなくても大丈夫です／営業はしません）。

見積書・請求書のような特定業務の内製設計は見積書・請求書の自動作成をAIで内製する方法で、受発注管理をSaaSからフルスクラッチへ切り替える判断基準は受発注管理をSaaSからNext.jsフルスクラッチに切り替える判断基準で、それぞれ詳しく解説しています。あわせてご覧ください。

よくある質問

Q. Excelのマクロで自動化している業務は、そのまま新システムに移行できますか？

マクロの処理内容次第です。単純な集計・転記であればNext.js側の機能として再実装しやすいですが、複雑な条件分岐が積み重なったマクロは、まず「何を目的にした処理か」を業務担当者に確認し、仕様として明文化してから移行対象にするのが安全です。マクロのコードをそのまま読み解こうとすると、書いた本人にしか分からない前提が埋め込まれていることが多く、遠回りに見えても業務目的からの再定義のほうが結果的に早く進みます。

Q. 複数のExcelファイルが部署ごとにバラバラに存在する場合、どこから手をつければよいですか？

もっとも利用頻度が高く、かつ他部署との関連が薄いファイル1つから着手するのが現実的です。複数ファイルを同時に統合しようとすると、ファイル間の表記ゆれの突き合わせだけで工数が膨らみます。1つのファイルで移行の型を確立してから、他のファイルに横展開するほうが、結果的に全体の期間は短くなる傾向があります。

Q. データ移行の途中で「このデータ、もう不要では」と気づいた場合はどうすればよいですか？

移行対象から外す判断は、業務担当者を交えて行ってください。エンジニア側だけで「使われていなさそうだから省く」と判断すると、実は年に1回だけ参照される重要データだった、というケースが起こり得ます。使用頻度が低いデータほど、判断の根拠を業務側に確認してから除外することをおすすめします。

Q. 並行運用中に新システムと旧Excelの数字が合わない場合、どう対処すればよいですか？

まず、集計対象期間とデータの締めタイミングが一致しているかを確認してください。並行運用中の不一致の多くは、移行スクリプトのバグではなく、集計範囲のズレやタイムゾーンの扱いの違いが原因です。原因がスクリプト側の変換ロジックにある場合は、該当ルールを修正し、再投入してから改めて並行運用を継続します。

Q. 移行専用の予算を確保せず、新システム開発の予算に含めてしまってもよいですか？

見積もりの精度が下がるため、できれば分けて確保することをおすすめします。新システム開発は要件さえ固まれば工数が読みやすい一方、データ移行はExcelの中身を実際に確認するまで工数が確定しません。1つの予算にまとめてしまうと、移行側で想定外の工数がかかった際に開発側の品質が犠牲になりやすくなります。現状調査の結果を踏まえて、移行専用の工数を別枠で見積もる進め方が実態に合っています。