はじめに：Excel と SaaS の継ぎ目で、毎日が消えていませんか？

社員30〜100名規模の中小企業で、情シスを兼務しながら現場を回している方にとって、こんな光景は日常ではないでしょうか。

営業が使うExcelの集計ファイルが壊れた、と朝イチで呼ばれる
勤怠はある企業のSaaS、経費は別の企業のSaaS、顧客管理はスプレッドシート。データが繋がらない
「この数字、どこから出したの？」と上長に聞かれても、答えられる人が1人しかいない

業務の「継ぎ目」に毎日時間を吸い取られている。かといって、大きなシステムを導入する予算も人員もない。この記事は、そんな状況にある方に向けて書いています。

この記事で分かること：

どの業務から手を付けるべきかの判断軸
Next.js 16 + Firebase で社内アプリを最小構成で作る考え方
1人情シスでも運用を回す方法

なぜ今、社内業務を Next.js で作り直すのか？

「今のままでも回っているし、わざわざ作り直す必要はないのでは？」という声は当然あります。私たちも、すべてを作り直すべきだとは思っていません。ただ、いくつかの変化が、「作り直す」という選択肢の現実味を高めています。

SaaS の課金累積が、気づけば重い

SaaS は1つずつ見れば月額数千〜数万円。でも、業務ごとに契約が増えていくと、気がつけば月額10万円を超えていたりします。しかも、各SaaS の機能の9割は使っていないことが多いです。

「この機能だけ欲しかったのに、フルパッケージしか選べない」という経験はないでしょうか。中小企業にとって、SaaS の課金は固定費として重くなりがちです。

Excel の属人化が、いよいよ限界に

Excel は万能の汎用ツールです。何でもできるし、誰でも使える。ただし、「誰でも使える」は「誰かが作った仕組みに依存する」の裏返しです。

関数を組んだ人が異動したら直せない。マクロの中身を読める人がいない。ファイルが壊れたらバックアップがない。こうした問題は、社員が増えるほど顕在化します。

AI 駆動開発で、「作る」ハードルが下がった

2025年後半から、Claude Code や Cursor のような AI を使った開発環境が実用段階に入りました。これにより、従来は数ヶ月かかっていた社内アプリの開発が、数週間のサイクルで回せるようになってきています。

「エンジニアが何人も必要」「半年以上かかる」というイメージは、もう少し修正してよいかもしれません。少数精鋭のチームで、小さく始めて育てる開発が現実的になっています。

どの業務から手を付けるべきか？

「全部を一気に作り直す」のは非現実的です。優先順位をつける必要があります。判断軸として、以下の2軸を使うとシンプルです。

判断マトリクス：「頻度」×「属人化」

	属人化が高い	属人化が低い
毎日使う	★ 最優先	優先度中
月に数回	優先度中	後回しでOK

「毎日使っていて、かつ特定の人しか触れない業務」が、最初に手を付けるべき領域です。

「使用頻度」と「属人化の度合い」の2軸で内製化すべき業務の優先順位を判定する2x2マトリクス図。毎日使い属人化が高い業務（日報集計・申請承認・台帳管理など）が最優先、他の3象限は優先度中または後回しでよいことを示す。

具体的にはこのあたりが候補になります。

最初に作るべき5つの候補

日報・週報の集計：毎日発生する、集計ロジックが属人的になりやすい
社内の申請・承認フロー：紙やメールで回っていると追跡できない
顧客・案件の台帳管理：Excelだとバージョン管理が破綻する
社内ドキュメント検索：散在するファイルを「探す時間」が積み重なる
定型レポートの自動生成：月末に2日かけて作っているレポートを自動化

「どれも当てはまる」と感じた方が多いかもしれません。その場合は、一番小さく作れるものから始めてください。最初の1本を動かすことで、社内の空気が変わります。

Next.js 16 + Firebase で何がどう変わるか？

「なぜ Next.js なのか？」という問いには、正直に答えます。私たちがNext.jsを選んでいるのは、以下の理由からです。

App Router と Server Components

Next.js 16 の App Router を使うと、サーバー側でデータを取得して、HTML を生成してからブラウザに返すことができます。これにより、初期表示が速く、検索エンジンにも読み取りやすいページを作れます。

社内アプリでは「検索エンジン対応」は不要かもしれませんが、初期表示の速さは社員のストレスを直接減らします。業務アプリで「読み込み中...」が3秒続くと、使われなくなります。

Firebase Auth + Firestore で認証とデータベースを最小化

社内アプリで最初に必要なのは「ログイン」と「データの保存」です。Firebase はこの2つを、サーバーを自前で立てずに実現できます。

Firebase Auth：メールアドレス + パスワード or Google 認証でログイン機能を即座に追加
Firestore：JSON ライクなデータベースで、スキーマ設計なしにデータを保存・取得

この組み合わせなら、「認証付きの業務アプリのMVP」を数日で動かすことが可能です。

最小構成の例

以下は、Firebase Auth でログインした社員だけが見られる社内ページの最小構成です。

// app/dashboard/page.tsx（Server Component）
import { cookies } from "next/headers";
import { adminAuth } from "@/lib/firebase-admin";
import { redirect } from "next/navigation";

export default async function DashboardPage() {
  const cookieStore = await cookies();
  const token = cookieStore.get("session")?.value;

  if (!token) redirect("/login");

  try {
    const decoded = await adminAuth.verifySessionCookie(token);
    return (
      <main>
        <h1>ダッシュボード</h1>
        <p>ようこそ、{decoded.email} さん</p>
        {/* ここに業務データを表示 */}
      </main>
    );
  } catch {
    redirect("/login");
  }
}

30行未満のコードで、認証付きのページが動きます。ここにFirestoreからのデータ取得を足していくだけで、社内アプリの骨格ができます。

いくらで作れるか？

正直にお伝えすると、「いくらで作れるか」はプロジェクトの範囲で大きく変わります。ただし、中小企業の社内業務アプリであれば、以下のレンジ感を参考にしていただけると思います。

初期開発

最小MVP（1画面・1機能）：数十万円
基本的な業務アプリ（3〜5画面・認証付き）：数十万〜数百万円
複数業務を統合するアプリ：数百万円〜

私たちゼットリンカーでは、数名のチームで数週間のサイクルを基本にしています。最初のMVPを小さく作って、使いながら育てるアプローチを取ることで、初期投資を抑えています。

運用コスト

Firebase の無料枠（Spark プラン）で始めれば、社員数十名規模なら月額費用はほぼかかりません。アクセス数が増えてきたら Blaze プラン（従量課金）に移行しますが、社内アプリの場合は月額数千円で収まるケースが多いです。

SaaS の継続コストとの比較

「SaaS を続けるか、内製するか」の判断は、3年間の累計コストで考えることをお勧めしています。

SaaS 月額3万円 × 36ヶ月 = 108万円（機能の追加・変更はSaaS次第）
内製初期100万円 + 運用月5,000円 × 36ヶ月 = 118万円（自由に変更可能）

単純なコスト比較ではほぼ同等ですが、「自社の業務に合わせて自由に変えられるかどうか」という価値は、数字に表れない大きな差です。

AI 駆動開発で何が変わるのか？

「AI を使って開発する」と聞くと、「AI がコードを全部書いてくれる」と思われるかもしれません。現実はもう少し地味で、しかし確実に効果があります。

Claude Code / Cursor を使った開発フロー

私たちの開発では、Claude Code と Cursor を組み合わせて使っています。具体的には以下のような分担です。

AI に任せている部分：

データモデルの定義（Firestore のコレクション構造）
CRUD（データの作成・読み取り・更新・削除）の基本コード生成
Tailwind CSS によるUIスタイリング
テストコードの下書き
エラーハンドリングの基本パターン

人間が判断している部分：

業務フローの設計（「何を作るか」の意思決定）
セキュリティルール（Firestore のアクセス制御）
パフォーマンス上の判断（キャッシュ戦略、データ取得タイミング）
UX の最終判断（「ここはボタンの方が良いか、リンクの方が良いか」）
コードレビュー（AI が生成したコードの品質チェック）

要するに、「定型的なコーディング作業」はAIに任せ、「業務理解と設計判断」は人間が持つ、という分担です。この体制で、従来数ヶ月かかっていた開発が数週間で回るようになっています。

レビュー体制

AI が書いたコードをそのままデプロイすることはありません。必ず人間のレビューを通します。

AI がコードを生成
開発者がレビュー（ロジックの正しさ、セキュリティ、パフォーマンス）
型チェック（TypeScript）+ lint + ビルドの自動検証
ステージング環境で動作確認
本番デプロイ

この5ステップを、数日〜1週間のサイクルで回します。「AI が全部やってくれる」のではなく、「AI が下書きを作って、人間が判断する」という形です。

作って終わりにしないための運用設計

社内アプリの最大のリスクは、「作ったけど使われなくなった」です。これを防ぐために、開発段階から運用を見据えた設計をしています。

最低限やるべき3つ

1. バックアップの仕組み化

Firestore のデータは、Firebase のエクスポート機能で定期バックアップを取ります。万が一データが消えても復元できる状態を、初期段階から作っておきます。

2. 権限管理

「誰が何を見られるか」を最初から設計します。Firebase Auth + Firestore Security Rules で、管理者・一般社員・閲覧者の3段階に分けるのが基本パターンです。

3. 監視

「アプリが落ちていないか」「エラーが出ていないか」を検知する仕組みを入れます。GlitchTip（Sentry互換のオープンソースエラートラッキング）を使えば、無料で本番環境のエラーを把握できます。

「育てる」前提で作る

社内アプリは、最初のバージョンが完成形ではありません。使い始めてから「ここをこうしたい」という要望が出てきます。それは自然なことで、むしろ歓迎すべきフィードバックです。

Next.js + Firebase の構成は、こうした段階的な拡張に強いです。画面を1つ追加する、入力項目を1つ増やす、といった変更が、既存の機能を壊さずに行えます。

よくある質問

既存の SaaS と並行運用できますか？

はい。一気に切り替える必要はありません。まず1つの業務（例：日報集計）だけを新しいアプリに移し、問題なく運用できることを確認してから、次の業務に広げていく形が現実的です。

Excel からの移行は段階的にできますか？

できます。最初のステップとして、「Excel で管理しているデータを Firestore に移す」ことから始めます。既存の Excel ファイルは残したまま、新しいアプリで同じデータを参照する並行運用期間を設けます。

セキュリティは大丈夫ですか？

Firebase Auth による認証 + Firestore Security Rules によるアクセス制御 + HTTPS 通信（Vercel 標準）の3層で守ります。社内アプリとして求められるセキュリティ水準は十分に満たせます。ただし、機微情報（マイナンバー等）を扱う場合は、個別の設計が必要です。

1人情シスでも運用できますか？

Firebase のマネージドサービスを活用すれば、サーバー管理は不要です。日常的な運用作業は「エラー通知の確認」「月次のデータバックアップ確認」程度。1人情シスでも十分回せる範囲です。

ベンダーロックインは発生しませんか？

Firebase への依存はありますが、データはいつでもエクスポートできます。Next.js のコード自体は標準的な React + TypeScript なので、将来的に別のBaaS（Supabase 等）に移行することも技術的には可能です。

既存の kintone 等からの移行はどう進めますか？

kintone のデータをCSVエクスポートし、Firestore にインポートするスクリプトを作ります。移行期間中は両方を並行運用し、新アプリで問題がないことを確認してから kintone を停止する、という流れです。

いつまでに動くものが見えますか？

最小MVPであれば、要件整理から数週間で動くものが出ます。ただし、「何を作るか」の合意形成に時間がかかるケースが多いので、まずは業務の棚卸しから始めることをお勧めしています。

途中で仕様変更はできますか？

できます。むしろ、使い始めてからの仕様変更を前提に設計しています。「最初に全部決めてから作る」のではなく、「小さく作って、使いながら直す」アプローチを取っています。

社内稟議を通すコツは？

「3年間の累計コスト比較」と「属人化リスクの解消」の2軸で説明するのが効果的です。特に後者は、「担当者が退職したら業務が止まるリスク」として経営層に響きやすいです。

失敗した場合の撤退コストは？

Firebase + Vercel の構成なら、固定費はほぼかかりません。「使わなくなったら、サービスを停止するだけ」です。サーバーを買って設置するわけではないので、撤退コストは非常に低いです。

まとめ

中小企業の社内業務は、Excel と SaaS の継ぎ目を Next.js + Firebase で埋めることで、少ない投資で改善できます。AI 駆動開発で「作る」ハードルが下がった今、最初の1本を小さく作って育てるのが現実的な進め方です。「全部を一気に変える」のではなく、一番困っている業務から始めてください。

本記事は Next.js 16.x 時点の情報です