「TypeScript対応できます」を鵜呑みにしない方法：ベンダー確認ポイントまとめ（Next.js編）

「TypeScript対応」の一言が危ない理由：動くコードと“運用できる開発”は別物

ベンダーから「TypeScript対応できます」と言われると、発注側としては安心しがちです。ですが実務では、TypeScriptが書けること＝品質の高い開発ができることではありません。特にWebでよく採用されるNext.jsは、TypeScript以外にも「設計」「ビルド運用」「デプロイ」「パフォーマンス」「セキュリティ」まで含めて、総合力が問われます。

現場で起きやすいズレは次のとおりです。

• TypeScriptは使っているが、型が薄くて結局バグは減らない（anyだらけ／型定義がない）
• Next.jsを使っているが、ページ表示が遅い・SEOが弱い・ビルドが不安定
• 納品後に、誰も触れない複雑さになって保守費が高騰
• サーバーやDB、認証、運用監視は別チーム任せで全体最適にならない

発注側（中小企業の経営者・情シス・業務担当）が確認したいのは、「TypeScriptが書けますか？」ではなく、TypeScript×Next.jsで、事業に必要な品質・速度・保守性を満たせますか？です。本記事では、非エンジニアでも判断しやすい“確認ポイント”に落とし込み、ベンダー選定や見積比較で使える形にまとめます。

まず押さえる前提：Next.jsとTypeScriptの関係（超かみ砕き）

Next.jsは、ReactというUI技術を土台にした「Webアプリの枠組み」です。ログイン画面、管理画面、EC、予約、社内ポータルなどを作る際に、表示速度やSEO、開発体験を整えやすいのが特徴です。一方で、Next.jsは設定・選択肢が多く、作り方によって成果が大きく変わります。

TypeScriptは、JavaScriptに「型（データの形のルール）」を付けてミスを減らす仕組みです。例えるなら、Excelの入力規則のようなものです。入力規則が適切ならミスが減り、ルールが形だけなら意味がありません。TypeScriptも同様で、型を“きちんと設計して回す”文化がないと効果が出にくいです。

さらにNext.jsには、事業側の要件と直結する重要論点があります。

• 表示方式の選択：SSR（サーバーで作って返す）／SSG（事前生成）／ISR（一定間隔で更新）など
• データ取得設計：API設計、キャッシュ戦略、認証・権限
• 配信と運用：Vercel、AWS、コンテナ、CDN、監視、ログ
• パフォーマンス：画像最適化、バンドル分割、遅延読み込み

つまり、ベンダーの「TypeScript対応」は入り口に過ぎません。発注側は、Next.jsを使う“理由”と“運用までの責任範囲”を一緒に確認すると、失敗確率を下げられます。

ベンダー確認ポイント：口頭で終わらせない質問リスト（コピペ可）

ここでは「Yes/No」で終わらない質問にして、ベンダーの実力と姿勢が出るようにします。可能なら、回答は口頭ではなく、議事録や提案書に残してください。曖昧な返事を放置すると、後から“言った・言わない”のコストが発生します。

TypeScriptの“品質”を見抜く質問

• 質問：TypeScriptの設定（tsconfig）はどの厳しさで運用しますか？ strictは有効ですか？
  狙い：型チェックを本気で効かせる姿勢か。strictを避ける場合は理由を確認。
• 質問：anyの使用ルールはありますか？ 例外的に使う場合、レビューやTODO管理は？
  狙い：“型がある体裁”で終わらないか。any無制限は危険信号。
• 質問：APIレスポンスの型はどう管理しますか？ 手書きですか、スキーマから生成しますか？
  狙い：バックエンドとズレてバグる典型を潰せるか。OpenAPI等の設計力を見る。
• 質問：ユニットテストと型の役割分担はどう考えますか？（型があるからテスト不要、は正しい？）
  狙い：TypeScript万能論に寄っていないか。現実的な品質設計か。

Next.jsの“設計”を見抜く質問

• 質問：このサイト/システムはSSR/SSG/ISRのどれが適切で、理由は何ですか？
  狙い：Next.jsの使い分けができるか。SEO・更新頻度・会員制など要件と結び付く。
• 質問：ルーティング（画面構成）とディレクトリ設計はどうしますか？ App Router（Next.jsの新しい方式）前提ですか？
  狙い：技術の世代差で保守が詰まないか。採用方針とリスク説明の有無を見る。
• 質問：認証（ログイン）と権限（誰が何を見られるか）はどう実装しますか？ NextAuth等の採用可否は？
  狙い：セキュリティの要。丸投げ回答なら注意。
• 質問：SEOと表示速度の測定指標（Core Web Vitals等）は何を目標にしますか？ 計測方法は？
  狙い：“速いはず”ではなく、数値で管理できるか。

運用・保守を見抜く質問（非エンジニアほど重要）

• 質問：本番障害時、どのログを見て、誰が一次対応し、何分で連絡しますか？
  狙い：運用体制の現実。SLA/SLOの考え方があるか。
• 質問：CI/CD（自動テスト・自動デプロイ）はどこまで入れますか？
  狙い：手作業デプロイは事故の温床。次の改修が高くなる。
• 質問：脆弱性対応（ライブラリアップデート）は誰が、どの頻度で行いますか？
  狙い：Next.js/React周りは更新が速い。放置するとセキュリティ・保守性が劣化。
• 質問：ドキュメントは何を納品しますか？（環境構築手順、運用手順、画面仕様、API仕様）
  狙い：担当交代や内製化に耐えられるか。

成果物でチェック：提案書・見積・設計書から“地力”を判定する見方

会話が上手いベンダーほど通ってしまうのが、発注の怖いところです。そこで、書面に出る“解像度”で判定します。専門知識がなくても、次の観点なら見抜けます。

見積の粒度：画面と機能が分解されているか

Next.js案件でよくある失敗は、見積が「一式」になっていて、後から追加費用が増えるケースです。見積は“機能ごと・画面ごと・運用項目ごと”に分かれているほど健全です。

• フロント（Next.js）だけでなく、API、DB、認証、管理画面、CMS連携が分かれている
• テスト（単体/結合/受入）やパフォーマンス改善が項目として存在する
• 運用（監視、ログ、障害対応、バックアップ）が別枠で明示されている

逆に「Next.js開発一式」「TypeScript対応一式」のような表現は、スコープが曖昧になりやすいです。曖昧さは、後で必ずコストになります。

設計の言語化：なぜその方式なのか説明があるか

Next.jsでは、SSR/SSG/ISR、キャッシュ、画像、データ取得などで性能と費用が変わります。良い提案書は、選定理由とトレードオフが書かれています。

体制：誰が何を責任持つか（属人化のサイン）

「TypeScriptが書ける人がいます」は体制の説明になりません。見るべきは、役割分担とバックアップです。

• テックリード（設計責任者）は誰か、レビュー体制はあるか
• フロント（Next.js）とバックエンド、インフラの責任境界が明確か
• 担当者が休んだときに止まらないか（2名以上で理解しているか）

ベンチャーや少人数ベンダーが悪いわけではありません。ただし、属人化を前提にするなら、発注側がリスク（納期、品質、保守）を理解した上で契約条件に反映すべきです。

ミニ実例：TypeScript/Next.jsでよくある“できると言ったのに…”パターンと回避策

ここでは、発注後に揉めやすい典型パターンを、非エンジニア向けに具体化します。同じトラブルでも、事前の質問と契約の書き方で大半は防げます。

パターンA：納品後に改修が遅い（触るたびに壊れる）

原因：TypeScriptは導入しているが型が薄く、設計が場当たり。さらにテストやレビューが弱く、変更の影響範囲が読めない。

回避策：

• strict運用、anyルール、コードレビューの基準を事前に合意する
• 重要機能（決済、予約、権限など）はテスト範囲を明記する
• 納品物に「開発手順（README）」と「設計方針」を含める

パターンB：SEOが伸びない／表示が遅い

原因：Next.jsの表示方式選定が要件と合っていない、画像・スクリプトが重い、計測していない。さらに「公開後に改善しましょう」で先送りされる。

回避策：

• 公開ページはSSG/ISRを中心にし、SEO要件（タイトル・メタ・構造化など）を整理する
• 目標指標（LCPやCLSなど）と計測方法を合意し、改善作業も見積に入れる
• コンテンツ更新頻度が高いなら、CMS連携と運用フローまで設計する

パターンC：本番運用でトラブルが起きても“誰も分からない”

原因：Next.jsのホスティング（Vercel/AWS等）や環境変数、ログ、監視が整理されていない。担当者のPC依存・手作業が残っている。

回避策：

• 障害対応フロー（連絡、一次対応、復旧、原因報告）を契約前に確認する
• 監視・ログ・バックアップを運用項目として切り出し、月額でも良いので責任者を決める
• デプロイは自動化（CI/CD）し、手順をドキュメント化する

発注側が用意すると成功率が上がる情報：要件定義の“最低限セット”

ベンダーの力量も重要ですが、発注側の情報が揃っていると、見積精度と品質が上がります。特にNext.jsは作り方の選択肢が多いので、前提が曖昧だと、ベンダーが安全側に盛る（高額化）か、逆に抜け漏れ（追加費用）になります。

加えて、情シスや管理部門が関わる場合は、次も早めに確認すると手戻りが減ります。

• ドメイン・DNS・SSL証明書の管理者は誰か
• アクセス権（Git、クラウド、解析ツール）の付与フロー
• 個人情報の扱い（プライバシーポリシー、ログの保存期間）

契約・発注で揉めないためのポイント：成果物と責任範囲を固定する

技術の話以上に揉めるのが、「どこまでが費用に含まれるか」です。特にTypeScriptやNext.jsは、品質向上のための施策（型の整備、テスト、性能改善）をどこまでやるかで工数が変わります。そこで、成果物と運用責任を“言葉”で固定します。

成果物（納品物）を明記する

• ソースコード一式（リポジトリの所在、権限移譲）
• 環境構築手順（README）とローカル起動方法
• デプロイ手順（CI/CD含む）と環境変数一覧
• 画面仕様（最低限の画面遷移と入力項目）
• API仕様（OpenAPI等があれば理想）
• 運用手順（監視、障害時連絡、バックアップ）

品質基準を“測れる形”で合意する

「高品質に作ります」では判断できません。以下のように、合意しやすい形へ落とします。

• TypeScriptのstrict運用の有無、anyの上限ルール
• テスト範囲（重要機能だけでも可）と実施タイミング
• 表示速度の目標（公開ページだけでも可）と計測方法
• 対応ブラウザ、スマホ表示の要件

保守の入口を作る（納品して終わりにしない）

Next.jsはライブラリ更新が多く、放置すると脆弱性やビルド失敗が起きやすくなります。なので、保守の契約形態（スポット／月額）を最初から決めると、結果的に総コストが下がります。

まとめ

「TypeScript対応できます」は、ベンダー選定の合格点ではなく“入口”です。特にNext.jsは、表示方式（SSR/SSG/ISR）・データ取得・認証・運用まで含めて設計することで、SEOや速度、保守性が大きく変わります。

• 確認すべきは言語スキルではなく、品質・設計・運用の具体策
• 口頭ではなく、提案書・見積・納品物の粒度で判断する
• strict運用やanyルール、テスト範囲、性能指標など“測れる合意”を作る
• 納品後を見据え、ログ・監視・更新対応まで責任範囲を固定する

もし「今のベンダー提案で大丈夫か不安」「Next.jsで作るべきか、別の選択肢が良いかも含めて相談したい」という段階なら、要件整理から一緒に進めるだけでも失敗確率は下がります。事業目的と運用体制に合わせて、無理のない設計と発注条件を整えることが、結果的に最短ルートです。