カテゴリF最終回、最後の装備は「型」
カテゴリFもいよいよ最終回です。前回のF-09では、依存を記録する台帳として、package.jsonとlockfileを見ました。今回は、E-02で学んだ型の話を、実行する前に機械が検査してくれる仕組みへと進めます。言語・非同期・分割・依存とそろえてきたところへ、最後の装備として型を加えます。
このスライドのポイント
- カテゴリF最終回
- E-02で学んだ「型」が、ここで「実行前に機械が検査する」仕組みへ進化する
- 言語・非同期・分割・依存に、型という最後の装備を加える
3つの用語を定義する
まず用語を定義します。TypeScriptとは、JavaScriptに型の記述を加えた言語です。書いたコードは、JavaScriptに変換されてから動きます。静的型検査とは、実行せずに型の不整合、たとえば数値のつもりが文字列になっているといった食い違いを検出することです。型注釈とは、この引数は数値です、のように型を明示する書き方で、priceにコロンとnumberを添えるように書きます。これらは別々の道具ではなく、型を書き、検査で守る、という一続きの仕組みです。
このスライドのポイント
- TypeScript＝JavaScriptに型の記述を加えた言語。書いたコードはJavaScriptに変換されて動く
- 静的型検査＝実行せずに型の不整合（数値のつもりが文字列など）を検出すること
- 型注釈＝型を明示する書き方（例: price: number）
なぜ必要か——実行前の検出はAIへの意図伝達
静的型検査を使わないと、何に困るのでしょうか。E-02で見た、文字列の"1000"に数値の100を足してしまうような型のバグを、実行して初めて知ることになります。とくにAIとの協働では、型注釈がAIへの意図の伝達、つまりA-07で学んだ受入条件のコード版として働きます。ここは数値しか受け取らない、と型で伝えておけば、AIの生成も人の指示もぶれにくくなります。使わないのは損だと言える理由が、ここにあります。
このスライドのポイント
- 型を使わないと: E-02の"1000"+100型のバグを、実行して初めて知ることになる
- 型注釈はAIへの意図伝達（A-07の受入条件のコード版）として機能する
- 使わないのは損
構造——誤りに気づくタイミングが手前に移る
全体像を、誤りに気づくタイミングの違いで整理します。JavaScriptでは、コードを書き、実行し、実際に動かして初めて型の誤りに気づきます。TypeScriptでは、書いた段階で検査が働き、実行する前に気づけます。同じ誤りでも、見つかる場所が手前に移るわけです。誤りは早く見つかるほど、直す手間もやり直しも小さくて済みます。これが型検査のいちばんの値打ちです。
このスライドのポイント
- 発見タイミングの比較
- JavaScript: 書く→実行→動かして気づく
- TypeScript: 書く→検査で気づく→実行
- 早く見つかるほど直すのが安い
税込計算に文字列を渡すミスで見る
具体例で見てみます。税込を計算する関数に、うっかり文字列を渡してしまうミスを考えます。JavaScriptはこの誤りに対して実行するまで沈黙し、動かしてから初めておかしな結果に気づきます。TypeScriptなら、書いた瞬間にその行へ赤い線が引かれ、実行する前に知らせてくれます。バイブコーディングでは、これがAIの生成ミスをすくい取る検出網としても働きます。人が見落としても、検査が先に止めてくれるわけです。
このスライドのポイント
- 例: 税込計算に文字列を渡すミス
- JavaScript: 実行するまで沈黙
- TypeScript: 書いた瞬間に赤線で知らせる
- AIの生成ミスの検出網としても働く
技術サンプル——型注釈で想定外の値をはじく
サンプルを読みます。種別はコードです。目的は、型注釈で想定外の値を実行前にはじくことです。関数taxIncludedの引数priceに添えたコロンnumberが型注釈で、この引数は数値だという宣言です。かっこの後ろのコロンnumberは、戻り値も数値だという宣言です。数値の1000を渡す呼び出しは通りますが、文字列の"1000"を渡す行は、実行する前にエラーとして検出されます。AIへの質問例は、この関数に型注釈を付けて、想定外の値を渡せないようにしてください、です。
混同——静的型検査と実行時エラーは別物
混同しやすい点を整理します。静的型検査は実行する前にTypeScriptが見つける誤りで、実行時エラーは動かして初めて出る誤りです。この2つは別物です。型検査を通ったからといって、すべての失敗が消えるわけではありません。時間のかかる処理、たとえばサーバーへの問い合わせが失敗するような実行時の失敗は、F-06のtry・catchで別途受け止める必要があります。型検査と実行時の備え、その両方がそろって初めて安全側に立てます。
このスライドのポイント
- 静的型検査（実行前・TypeScript）vs 実行時エラー（動かして初めて出る）
- 検査を通っても実行時の失敗（通信の失敗など）は別途残る
- 両方の備えが要る
バイブコーディングでの確認点——anyの穴を塞ぐ
バイブコーディングでの確認点です。AIにTypeScriptで書かせると、型がAIの誤解を映す検出網になります。ただし、何でも通してしまう型を使われると、その網に穴が空きます。そこで確認したいのが、anyという何でも通す型を使っていませんか、という質問です。anyが多いと、せっかくの静的型検査が働かなくなります。AIへの質問例としては、この関数に型注釈を付けて、想定外の値を渡せないようにしてください、と頼むとよいでしょう。
このスライドのポイント
- AIにTypeScriptで書かせると、型がAIの誤解の検出網になる
- 「any（何でも通す型）を使っていませんか」を確認して検査の穴を塞ぐ
- AIへの質問例: 型注釈を付けて想定外の値を渡せないようにしてください
一問一答とカテゴリFのまとめ
最後に一問一答です。型の不整合を実行する前に見つける仕組みを、何と呼ぶでしょうか。（間）答えは、静的型検査です。30秒まとめです。これでカテゴリFは修了です。言語の動く場所、スコープ、更新の流儀、同期と非同期、Promise、asyncとawait、モジュール、npmと依存、そして型と、AIのコードを読むための装備が一通りそろいました。次回からはカテゴリG、画面の構造であるHTMLとCSSへ進みます。関連資料は「AI Builder 技術ロードマップ」と「リファクタリング指示文50」です。
このスライドのポイント
- 一問一答: 型の不整合を実行前に見つける仕組みを何と呼ぶ？
- 30秒まとめ: カテゴリF修了。言語・非同期・分割・依存・型でAIコードを読む装備が揃った
- 次回: カテゴリG、画面の構造（HTML・CSS）へ
- 関連資料: 「AI Builder 技術ロードマップ」「リファクタリング指示文50」
