Next.jsプロジェクトの初期構造と主要ファイル
この節で学ぶこと
この節では、なぜ Next.js で TypeScript を使うのか、そして最初にどの設定を見ればよいのかを、整理します。
Next.js は TypeScript を組み込みでサポートしており、新規プロジェクト作成時には必要な依存関係や推奨設定を自動で整えられます。既存プロジェクトでも、ファイルを .ts や .tsx に変更し、next dev や next build を実行すると、必要な依存関係の導入や tsconfig.json の生成が案内されています。
この節の到達目標は、次の3つです。
- TypeScript が「難しい追加ルール」ではなく、JavaScript のミスを早めに見つける仕組みだと理解すること。
tsconfig.json、next-env.d.ts、.ts/.tsxという基本要素の役割が分かること。strictやnoImplicitAnyのような重要設定が、なぜ実務で重視されるのかを自分の言葉で説明できることです。
TypeScript 公式は、JavaScript は実行してみるまで何が起きるかに頼りがちであり、静的型システムは実行前に予測を与えると説明しています。
そもそも TypeScript とは何か
JavaScript に「型」の考え方を足したもの
TypeScript 公式サイトは、TypeScript を “JavaScript with syntax for types” と説明しています。つまり、まったく別の世界の言語というより、JavaScript に型のための記法を加えたものです。さらに、TypeScript のコードは JavaScript に変換され、JavaScript が動く場所なら動かせると案内されています。
ここは大事です。
初心者のうちは、TypeScript を見ると「新しい言語をもう1本覚えなければいけない」と感じがちです。けれど実態はもう少し穏やかです。JavaScript を書きながら、間違いを早めに教えてもらう仕組みが増えた、と捉える方が近いです。TypeScript 公式も、TypeScript は JavaScript を理解し、型推論によって追加コードなしでも良いツール体験を与えると説明しています。
なぜ導入するのか
TypeScript 公式の Handbook では、JavaScript は本質的に動的型付けであり、「実行してみて何が起きるかを見る」性質が強いと説明されています。その代わりに、静的型システムを使うと、実行前に期待される振る舞いを予測できるようになります。
たとえば、次のコードを見てください。
function double(value: number): number {
return value * 2
}
console.log(double(10))
console.log(double("10"))
最後の "10" は文字列です。
TypeScript では value: number と書いてあるので、文字列を渡した時点でエディタやビルド時に問題として検出しやすくなります。実際にブラウザで変な挙動を見てから気づくより、ずっと早い。ここに TypeScript の導入意義があります。
Next.js で TypeScript を使う意味
Next.js は最初から TypeScript を前提にしやすい
Next.js の公式ドキュメントでは、Next.js comes with built-in TypeScript と明記されています。新規プロジェクトを create-next-app で作成すると、必要なパッケージの導入や適切な設定が自動で整います。
つまり、今の Next.js で TypeScript を使うのは、昔のように「あとから重たい設定を足す」感じではありません。むしろ、最初から公式の標準ルートに乗る感覚です。これは初心者にとって大きな利点です。環境構築で消耗せず、「型の意味」に集中しやすくなるからです。
React と相性がよい
Next.js は React ベースのフレームワークです。React では、コンポーネントに「どんな props を渡してよいか」を明確にしたい場面が多くあります。TypeScript を使うと、その契約をコード上に書けます。TypeScript 公式は、型は「どんな値を渡せるか」を記述する概念だと説明しています。
たとえば、次のように書けます。
type GreetingProps = {
name: string
}
export default function Greeting({ name }: GreetingProps) {
return <p>こんにちは、{name}さん</p>
}
この書き方の良いところは、使う側も読む側も安心しやすいことです。
「このコンポーネントには name が必要で、それは文字列だ」と一目で分かります。見た目は少し増えますが、後からコードを読む自分を助けてくれます。
TypeScript を入れると何が変わるのか
ファイル拡張子が変わる
基本はこれです。
.ts:TypeScript の通常ファイル.tsx:JSX を含む TypeScript ファイル
Next.js の TypeScript ドキュメントでも、既存プロジェクトへ TypeScript を追加する方法として、ファイルを .ts / .tsx にリネームする手順が案内されています。React コンポーネントを書くファイルは JSX を使うため、通常は .tsx になります。
設定ファイルが増える
最初に押さえるべきなのは、主にこの2つです。
tsconfig.jsonnext-env.d.tstsconfig.jsonは TypeScript コンパイラの設定ファイルです。TypeScript 公式は、TSConfig reference として各種オプションを整理しています。Next.js は既存プロジェクトに TypeScript を追加すると、推奨設定を含むtsconfig.jsonを生成します。
next-env.d.ts については、Next.js の next CLI ドキュメントで、Next.js types をプロジェクトで利用可能にするため tsconfig.json に含まれるファイルと説明されています。また、next typegen により生成され、.gitignore へ追加することが推奨されています。
まずは、tsconfig.jsonを読む
何のためのファイルか
tsconfig.json は、TypeScript に対して「どの厳しさで検査するか」「どのファイルを対象にするか」などを伝える設定ファイルです。TypeScript 公式では、TSConfig がプロジェクトのコンパイラ設定の中心であると整理されています。
Next.js では、最初から推奨設定が入っていることが多いため、初心者は全部を暗記する必要はありません。
ただし、どの項目が重要かは知っておくとかなり違います。
よく見る設定例
次のような形を見ることがあります。
{
"compilerOptions": {
"target": "ES2017",
"lib": ["dom", "dom.iterable", "esnext"],
"strict": true,
"noEmit": true
}
}
この中で、初心者が最初に注目したいのは strict と noEmit です。
strict: trueTypeScript 公式では、strictは幅広い型チェックを有効にし、より強い正しさの保証を与える設定だと説明されています。さらに、strict mode family の各オプションをまとめて有効にする意味があります。noEmit: trueTypeScript には JavaScript を出力する機能がありますが、Next.js ではビルドや実行を Next.js 側が担うため、TypeScript 自体には「型チェック役」に専念してもらう構成がよく使われます。TypeScript の CLI ドキュメントでもnoEmitは出力を行わない設定として整理されています。
strictがなぜ大切なのか
厳しいからこそ、早く気づける
strict は、TypeScript 公式が「より強いプログラム正しさの保証」を与えると説明している重要設定です。
初心者目線では、最初は少しうるさく感じるかもしれません。
ですが、その「うるささ」は、未来の自分を守るためのものです。
雑に書いたコードを後から直すより、書いた瞬間に「そこ危ないですよ」と言ってもらえる方が、結局は楽です。
noImplicitAnyとの関係
strict を有効にすると、strict 系の各チェックが有効になります。その中には noImplicitAny も含まれます。TypeScript 公式は、noImplicitAny について、型推論できず any になってしまう箇所でエラーを出し、見逃しを減らす設定だと説明しています。
たとえば、次のコードを見てください。
function printLength(value) {
console.log(value.length)
}
この value は型が書かれていません。
状況によっては推論できますが、推論できない場面では暗黙の any が入り込みます。noImplicitAny を有効にしておくと、「型が曖昧なまま進んでいますよ」と早めに教えてくれます。TypeScript 公式でも、any によってエラーが見逃される例が示されています。
next-env.d.tsは何をしているのか
Next.js の型を使えるようにする
Next.js の CLI ドキュメントでは、next-env.d.ts は Next.js types をプロジェクトで利用可能にするため、tsconfig.json に含まれるファイルと説明されています。
このファイルは、自分で毎回編集して凝ったことをするための場所、というより、Next.js の型の橋渡し役だと理解する方が自然です。初心者のうちは、「あると Next.js の型がちゃんと認識される」と覚えておけば十分です。
基本的には手で触り回さない
Next.js 側が生成・管理を前提にしている性格が強いため、まずは不用意に編集しない方が安全です。公式でも、next typegen がこのファイルを生成し、.gitignore に加えることが推奨されています。
初心者が最初に書くと納得しやすいコード
変数に型を付ける
const userName: string = "Tomoya"
const age: number = 20
const isActive: boolean = true
これは単純ですが、効果があります。
「この変数には何が入るのか」がはっきりするからです。TypeScript 公式の基本解説でも、文字列、数値、真偽値などの基本型が扱われます。
オブジェクトに型を付ける
type User = {
name: string
age: number
}
const user: User = {
name: "Tomoya",
age: 20,
}
こう書くと、user というデータの形が固定されます。
「名前は文字列、年齢は数値」という契約ができます。TypeScript は値の形に注目して型チェックする、いわゆる structural typing の考え方を持っています。旧 Handbook の interface 解説でも、shape に注目する原則が説明されています。
React コンポーネントに型を付ける
type ProfileCardProps = {
name: string
age: number
}
export default function ProfileCard({ name, age }: ProfileCardProps) {
return (
<section>
<h2>{name}</h2>
<p>{age}歳</p>
</section>
)
}
このコードの価値は、画面を作ること以上に、部品の使い方を先に宣言していることです。
後から別の人が使うときも、「何を渡せばいいのか」が明確です。
よくある誤解
「型を書くとコードが増えて面倒」
これは半分正しいです。確かに少し増えます。
ただし、その増えた数行が、あとで何十分ものデバッグを減らすことがあります。TypeScript 公式も、エディタ上で早くエラーを見つける価値を強調しています。
「TypeScript は実行時に全部守ってくれる」
ここは注意点です。TypeScript の型チェックは主に開発時・ビルド時の仕組みです。TypeScript 公式の class 解説でも、private や protected のような仕組みは型チェック段階で強く働く一方、JavaScript 実行時の性質とは別だと説明されています。
つまり、TypeScript は魔法の防壁ではありません。
ただ、それでも価値は大きいです。事故を「ゼロ」にするのではなく、かなり手前で気づかせるからです。
「最初から全部の tsconfig を理解しなければいけない」
そこまでしなくて大丈夫です。
最初は次の3点で十分です。
.ts/.tsxの違いtsconfig.jsonは TypeScript の設定ファイルstrictが重要
この3つが分かるだけで、導入としてはかなり良いスタートです。
まず確認したい基本設定
新規作成なら create-next-app の既定値を活かす
Next.js の Installation ドキュメントでは、create-next-app が TypeScript を含む推奨設定を自動で整えると説明されています。
つまり、新規プロジェクトであれば、まずは既定値の TypeScript 構成を受け入れるのが自然です。ゼロから tsconfig.json を手書きするより、公式の推奨構成を土台に読む方が理解しやすいです。
既存プロジェクトなら .ts / .tsx に変える
既存の Next.js プロジェクトへ TypeScript を加える場合、公式は .js / .jsx を .ts / .tsx に変更し、next dev や next build を走らせる流れを案内しています。これにより必要な依存関係や tsconfig.json が整います。
ミニ練習問題
問1
TypeScript の説明として最も適切なものはどれですか。
A. JavaScript と無関係な別言語
B. JavaScript に型のための構文を加えたもの
C. CSS を自動生成するツール
D. データベース管理システム
答え
B
解説
TypeScript 公式は TypeScript を “JavaScript with syntax for types” と説明しています。JavaScript を土台にしつつ、型のための構文を追加したものです。
問2
Next.js における TypeScript の扱いとして正しいものはどれですか。
A. Next.js は TypeScript を公式にサポートしていない
B. TypeScript は使えるが、毎回すべて手動設定が必要
C. Next.js には組み込みの TypeScript サポートがある
D. TypeScript は Pages Router でしか使えない
答え
C
解説
Next.js の公式 TypeScript ドキュメントには、built-in TypeScript と明記されています。新規作成時には必要な設定や依存関係が自動で整います。
問3
tsconfig.json の役割として最も近いものはどれですか。
A. TypeScript のコンパイラ設定を管理する
B. 画像を保存する
C. パスワードを暗号化する
D. ブラウザ履歴を削除する
答え
A
解説
TypeScript 公式の TSConfig リファレンスは、tsconfig.json を中心に各種コンパイラオプションを整理しています。
問4
strict: true の説明として正しいものはどれですか。
A. 画面の色を厳密に固定する
B. 幅広い型チェックを有効にし、より強い正しさの保証を与える
C. JavaScript の実行速度だけを上げる
D. CSS の自動整形だけを行う
答え
B
解説
TypeScript 公式は、strict が幅広い型チェックを有効にし、より強い program correctness の保証につながると説明しています。
問5
next-env.d.ts について正しいものはどれですか。
A. Next.js の型をプロジェクトで使えるようにするためのファイル
B. 画像専用の保存場所
C. npm の実行履歴
D. Tailwind CSS の設定ファイル
答え
A
解説
Next.js の CLI ドキュメントでは、next-env.d.ts は Next.js の型をプロジェクトで使えるようにするため tsconfig.json に含まれるファイルだと説明されています。
まとめ
TypeScript を導入する意味は、見た目を難しくすることではありません。
実行前に気づけることを増やし、コードの約束を見える形にすることです。TypeScript 公式は、静的型システムが実行前の予測を可能にすると説明しており、Next.js はその仕組みを最初から使いやすい形で提供しています。
初心者の段階でまず押さえたいのは、次の4つです。
- TypeScript は JavaScript を土台にした型付きの書き方であること。
- Next.js には TypeScript の組み込みサポートがあること。
tsconfig.jsonが設定の中心であること。strictが実務でも学習でも重要な出発点であること。
ここが腑に落ちれば、TypeScript は「難しい壁」ではなく、「先に転びそうな場所を照らしてくれるライト」に変わります。次の節では、この土台の上で実際の構造やファイルの意味をさらに具体的に見ていくと、理解がぐっと安定します。
参考文献
- Next.js Documentation, TypeScript.
- Next.js Documentation, Getting Started: Installation.
- Next.js Documentation, next CLI.
- TypeScript Documentation, The Basics.
- TypeScript Official Site.
- TypeScript TSConfig Reference.
- TypeScript Documentation, Compiler Options.
- TypeScript TSConfig Option:
strict. - TypeScript TSConfig Option:
noImplicitAny. - TypeScript Documentation, Classes.
