なぜTypeScriptなのか？保守性の高いコードベースの維持

TypeScriptを使うと、引数・返り値・プロパティの使い方の不整合を、コードを実行する前に確認しやすくなります。TypeScriptは静的な型チェックを行う言語で、型の情報はエディタの補完やエラーの表示にも使われます（TypeScript Handbook：The Basics、確認日：2026年10月21日）。一方で、型の注釈は実行時の動作を変えず、変換後のJavaScriptからは取り除かれます。型チェックで分かる範囲は、検査の対象になっているファイルと設定に左右されます。また、型チェックは実行速度の向上や、不具合がなくなることを保証するものではありません。

JavaScriptのままでも、エディタの補完やJSDocのコメントを使って型を確認する進め方があり、TypeScriptを採用するために、一括で書き換える必要はありません。変更を確かめるときは、次のように複数の方法を組み合わせます。

表は横にスクロールできます →

すべての変数に型を書く必要はありません。型推論を活かし、関数の入出力やモジュールの境界など、意味を共有する箇所に必要な型を書きます。TypeScriptは初期値や使われ方から型を推論し、推論と同じ型をわざわざ書かなくてもよいとされています（Type Inference、Everyday Types）。

• any：その値に関する型チェックを止めます。使った箇所とそこから広がる処理の検査は弱まりますが、プロジェクト全体の型チェックがすべて無意味になるわけではありません。使う場合は、理由と範囲、見直す条件を残します。
• unknown：中身を確かめるまで、プロパティの参照などを許さない型です。unknownと書いても検証の処理が作られるわけではなく、typeofなどの条件で実際に確かめる必要があります（Narrowing）。
• 型アサーション（as）と非null指定（!）：コンパイル時に取り除かれ、実行時の検査や変換は行いません（Everyday Types、いずれも確認日：2026年10月21日）。根拠がないまま型エラーを消すために使いません。

APIでやり取りするデータと画面で使うデータは、役割に応じて型を分けます。型の管理元は、API仕様（OpenAPIなど）から生成する、型を手で一元管理する、検証の定義から型を得るといった方法から、更新の担当と同期の方法で選びます。生成した型があるだけでは、届いた値を検証したことにはなりません。API仕様の合意と変更の管理は、APIファースト開発の記事で扱っています。

API・フォーム・保存済みのJSONなどから届く値は、型定義があっても、実行時に検査してから内部の処理へ渡します。型の注釈は、届いた値を変えることも確かめることもないためです。画面側のチェックは、サーバー側の入力検証や権限の確認の代わりにはなりません。利用者へのエラーの伝え方は、業務システムのUI/UX改善の記事で扱っています。

次は、注文の要約を受け取る処理を想定した説明用の例です。1行目の型の宣言は実行時には残らず、実際に値を確かめているのはif文の条件です。

type OrderSummary = { orderId: string; totalYen: number };

function parseOrderSummary(input: unknown): OrderSummary | null {
  if (typeof input !== "object" || input === null) return null;
  if (
    !("orderId" in input) || typeof input.orderId !== "string" ||
    input.orderId.trim() === "" ||
    !("totalYen" in input) || typeof input.totalYen !== "number" ||
    !Number.isSafeInteger(input.totalYen) || input.totalYen < 0
  ) return null;
  return { orderId: input.orderId, totalYen: input.totalYen };
}

この例では、注文IDを「空白だけではない文字列」、合計を「0以上の安全な整数（円単位）」と定めています。0円も受け付け、文字列の"1200"を数値へ自動で変換しません。返すのはorderIdとtotalYenの2項目だけで、ほかの項目が含まれていても採用しません。条件に合わない場合はnullを返すため、呼び出す側はnullを確認し、表示や保存などの後続の処理へ進まないようにします。API通信やJSONの構文解析の失敗は、この関数の前で別に扱います。

表は横にスクロールできます →

合計が0の { orderId: "O-1", totalYen: 0 } は条件に合うため、そのまま返します。この関数は、合計が明細と一致するか、注文の所有者や閲覧の権限、文字列の長さ、保存の成否などは検査しません。それらは業務と運用の条件に応じて別に実装・テストします。型が合うことと、情報が正しいことは同じではありません。既存のスキーマ定義や検証ライブラリを使う方法もあり、手書きの検証が唯一の方法ではありません。

移行は一括で書き換えず、今の動作とテストを確かめてから、対象と厳格さを少しずつ広げます。最初に、変更が多い処理、障害の影響、外部からの入力、今のテスト、依存するライブラリ、ビルドと実行の仕組みを確認します。公式の移行ガイドも、設定を整えてから1ファイルずつ移し、厳しい検査は段階的に有効にする流れを示しています（Migrating from JavaScript、確認日：2026年10月21日）。

1. 今の動作と検査の対象を記録し、確かめられている業務と、まだ確かめられない業務を分ける。
2. JavaScriptとTypeScriptを共存させる範囲、JavaScript側のチェック、変換と実行を担うツールを決める。
3. 小さな変更の単位で型と入力の条件を整理し、テストとレビューで動作の差を確かめる。
4. 例外を記録し、対象と厳格さを広げる条件、担当、戻す方法を決める。新規の開発ではstrictを基本の候補とし、既存の環境では対象の範囲とエラーの解消計画を合意する。

次の表は、既存のWebアプリを改修するときに、対象と未確認の事項を記録する例です。前の節と同じ注文の要約を扱うアプリを想定した説明用の設定で、実際の調査結果や、すべての現場に当てはまる優先順位ではありません。

表は横にスクロールできます →

一部のファイルで型チェックが通ったことを、全体の移行の完了や実行時の安全性と読み替えません。未確認の事項は0件と報告せず、担当と次の確認日を残します。

tsconfigの設定は、ほかのプロジェクトの設定をそのまま貼り付けず、一つずつ役割と影響を確かめて選びます。主な設定の役割は次のとおりです。

表は横にスクロールできます →

strictは厳格な検査の系列をまとめて有効にし、個別の設定で一部を外すこともできます。TypeScriptの更新で新しい検査が加わり、型エラーが増える場合もあります。noImplicitAnyとstrictNullChecksはこの系列に含まれますが、noUncheckedIndexedAccessとexactOptionalPropertyTypesは含まれないため、既存のコードへの影響を確かめてから別に判断します。exactOptionalPropertyTypesを有効にしても、colorThemeOverride?: "dark" | "light" | undefined のようにundefinedを型に含めれば、明示的なundefinedは許されます。出典はTSConfig ReferenceのallowJs・checkJs・strict・noImplicitAny・strictNullChecks・noUncheckedIndexedAccess・exactOptionalPropertyTypesの各ページです（いずれも確認日：2026年10月21日）。ここで示すのは役割の説明で、特定のサイトの設定値をおすすめの完成形とするものではありません。

変更を確かめるときは、型チェック、入力検証の異常系、業務の期待結果、画面の操作の確認を組み合わせ、何を確かめ、何が残っているかを記録します。型の名前が同じでも入力の仕様が変わることがあり、依存ライブラリの更新でも型と動作を別に確かめます。

• 設定ファイルを指定して型チェックだけを行う例は tsc --noEmit -p tsconfig.json です。ファイル名を直接指定する実行は、この設定を使う実行とは異なります。TypeScript 5.9系ではtsconfig.jsonを読み込まずに進み、6.0ではtsconfig.jsonがあるディレクトリでファイル名を指定するとエラー（TS5112）になります。プロジェクトの設定に沿って確認する場合は、-pで設定ファイルを指定します（tsc CLI Options・TypeScript 6.0のリリースノート、確認日：2026年10月21日）。
• noEmitは、tscが変換結果を出力しない指定で、変換をBabelやswcなど別のツールに任せる構成で使われます。noEmitOnErrorは、tscが出力する構成で、型エラーがあるときに出力を止める別の設定です（noEmit・noEmitOnError、いずれも確認日：2026年10月21日）。変換を別のツールが担う場合、型エラーで公開が止まるかは別に確かめます。すべての構成に両方を加える必要はありません。
• lintと整形、型チェック、テストは目的が異なります。CIにコマンドを書いたことだけで、マージやデプロイが止まるとは限らないため、必要なチェックと失敗時の扱いを確かめます。
• 型の管理元、API仕様の変更と更新の担当、受け取る値の検証の条件も、レビューの対象にします。

変更と引き継ぎでは、何を確かめ、何が未確認で、誰が次に確認するかを記録として残します。残す記録の例は次のとおりです。

• 変更の対象と対象外
• 型と検証の定義の管理元、更新の担当
• 再現する操作と入力の例
• 実行したチェックと結果
• anyやasを残す理由と範囲、見直す条件
• 未確認の事項の担当と、次の確認日
• 公開後の確認と、戻す方法

仕様とコードのどちらを直すかがはっきりしない場合は、業務で期待する結果を確かめてから判断します。サイト全体の構成や更新の仕組みは、モダンWeb開発の構成判断で扱っています。

導入や改修を始める前に、分かる範囲で次の点を確認します。すべてに当てはまっても、不具合がないことが保証されるわけではありません。未確認の項目は、担当と確認の時期を決めて残します。

社内や外部に相談するときは、変更時に困っている処理、APIやフォームの入力、今のテストと保守の体制について、分かる範囲をまとめておくと整理を進めやすくなります。型エラーが多い段階やテストがない段階でも、ご相談いただけます。ソースコードや機密の資料、認証情報を相談フォームに貼っていただく必要はありません。