【入門編】未知の外部データに対する型安全なバリデーション：unknown型と型ガードの活用 – TypeScript コア・型システムの基礎解析バイブル

こんにちは！フロントエンドからバックエンドまで、TypeScriptで頭の中をフル回転させているあなたへ。

今回は、実務で必ず直面する「外部からやってくる怪しいデータを、どうやって安全に料理するか」という超重要テーマについてお話ししますね。

API通信のレスポンスや、ローカルストレージからの読み込み、あるいはユーザーからの入力。私たちのアプリケーションの「外側」にあるデータは、TypeScriptのコンパイラから見れば完全なる無法地帯です。「絶対にこの型で返ってくるはず！」と信じ込んで `as`（型アサーション）で型をねじ曲げた結果、本番環境で突然アプリがクラッシュした……なんて経験はありませんか？

ここをクリアすれば、TypeScriptの型安全性の本質がグッと見えてきますよ。一緒にバッチリマスターしていきましょう！

—

1. 悪魔の証明：なぜ `any` ではなく `unknown` なのか？

外部データを扱うとき、私たちはよく「何が来るか分からないから `any` にしちゃえ」と思いがちです。でも、それはTypeScriptという強力な盾を自ら投げ捨てる行為なんですよね。

`any` は「型チェックをすべて無効化する魔法の免罪符」です。コンパイラを黙らせることはできますが、runtime（実行時）の爆弾を防ぐことはできません。

そこで登場するのが、TypeScriptの良心こと `unknown` 型です。

// 外部APIから取得したデータ（何が入っているか分からない）
const response: unknown = fetchUserData();

// ❌ 怒られる：unknown型のデータは、そのままプロパティにアクセスできない
console.log(response.name);
// エラー: Object is of type ‘unknown’.

`unknown` は、「今は何者か分からないけれど、とにかく安全な型が判明するまでは何もさせないよ」という厳格なガードマンです。この「何もさせない」という制約こそが、私たちのアプリケーションを守る最強の武器になります。

—

2. 型の安全地帯へ：`unknown` を手懐ける「型ガード」

`unknown` 型のデータから安全にプリミティブな値（`string`, `number`, `boolean` など）を取り出すには、「型ガード（Type Guard）」という手順を踏む必要があります。

イメージとしては、空港の保安検査場のようなものです。怪しい荷物（`unknown`）を一つひとつX線に通して、安全が確認されたものだけを通関させる、そんなプロセスですね。

プリミティブ型を安全に絞り込む基本パターン

TypeScriptには、値の型を安全に判定するためのネイティブな仕組みがいくつか用意されています。

function processInput(input: unknown) {
// 1. typeof 演算子による絞り込み（プリミティブ型に最強）
if (typeof input === “string”) {
// このブロックの中では、inputは完全に「string型」として扱われます！
console.log(input.toUpperCase());
return;
}

if (typeof input === “number”) {
// このブロックの中では「number型」
console.log(input.toFixed(2));
return;
}

if (typeof input === “boolean”) {
// このブロックの中では「boolean型」
console.log(input ? “Yes” : “No”);
return;
}

console.log(“想定外のデータ型です”);
}

コンパイラは `if (typeof input === “string”)` という条件分岐（Control Flow Analysis：制御フロー分析）を賢く追跡しています。条件の「内側」と「外側」で、変数の型を動的に書き換えているのです。これがTypeScriptの真骨頂ですよ。

—

3. 実践！APIレスポンスの安全なバリデーション設計

では、もう少し実践的な例を見てみましょう。
サーバーから以下のようなユーザーデータ（オブジェクト）が返ってきたと仮定します。

{
“id”: 101,
“name”: “Taro TypeScript”,
“isActive”: true
}

これを安全に受け取るための「カスタム型ガード関数」を作ってみましょう。

// 目指すべき型定義
interface User {
id: number;
name: string;
isActive: boolean;
}

// ユーザー定義型ガード関数
// 戻り値の `arg is User` が TypeScriptへの「お墨付き」のサインになります
function isUser(arg: unknown): arg is User {
return (
typeof arg === “object” &&
arg !== null &&
“id” in arg &&
typeof (arg as Record).id === “number” &&
“name” in arg &&
typeof (arg as Record).name === “string” &&
“isActive” in arg &&
typeof (arg as Record).isActive === “boolean”
);
}

// — 実際の利用シーン —
const rawData: unknown = JSON.parse(‘{“id”: 101, “name”: “Taro TypeScript”, “isActive”: true}’);

if (isUser(rawData)) {
// ここに入った瞬間、rawDataは「User型」に昇格します！
console.log(`ようこそ、${rawData.name}さん！（ID: ${rawData.id}）`);
} else {
console.error(“不正なデータフォーマットです。”);
}

ここがポイント！

`arg is User`（ユーザー定義型ガード）: 関数の戻り値にこの構文を使うことで、「この関数が `true` を返したならば、引数の `arg` は `User` 型である」とTypeScriptのコンパイラに保証させることができます。
JavaScriptの `typeof null` が `”object”` になってしまうバグ的挙動対策として、`arg !== null` を必ず挟むのがプロの技です。

—

4. ありがちな罠：やってはいけないアンチパターン

初学者の頃や、急いでいる現場でよく見かける「やってはいけない書き方」を確認しておきましょう。

❌ 罠1: `as` による型アサーション（強制キャスト）

// 危険！中身が何であれ、User型だと無理やり思い込ませる
const user = fetchUserData() as User;

// もしサーバーから id が文字列で返ってきたり、undefined だったりしたら…
console.log(user.id.toFixed(2)); // 💥 実行時エラーでアプリがクラッシュ！

`as` はコンパイラに対する「私を信じて、チェックは不要よ」という嘘の申告です。外部データに対して `as` を使うのは、目隠しをして地雷原を歩くようなものなので絶対に避けましょう。

❌ 罠2: `typeof` の過信

`typeof` は便利ですが、配列や `null`、オブジェクトの判定には無力です。

`typeof null` ➡️ `”object”` （JavaScriptの歴史的仕様のバグです）
`typeof []` ➡️ `”object”` （配列もオブジェクト判定されます）

配列やネストしたオブジェクトを検証したいときは、`Array.isArray()` を組み合わせるなど、多角的なガードが必要になります。

—

まとめ：境界線でデータを飼いならそう

今回は、外部データに対する `unknown` 型と型ガードの活用法について解説しました。

1. 外部データは信用せず、まず `unknown` 型 で受け取る。
2. `typeof` やユーザー定義型ガード（`arg is T`）を使って、安全性を検証（バリデーション）する。
3. 検証をクリアした安全地帯でのみ、その型としてコードを記述する。

このアプローチを徹底できるようになると、あなたの書くTypeScriptコードの堅牢性は劇的に跳ね上がります。「型エラーが出ないから安心」ではなく、「実行時でも絶対に破綻しない」というエンジニアリングの美しさを手に入れることができるはずです。

基本の型と型推論の仕組みを味方につければ、どんな複雑なシステムも怖くありません。明日からのコードに、ぜひこの型ガードのパターンを取り入れてみてくださいね！