去年、TypeScriptの型についての小説を書いて、そのまま放置していた。せっかくなので、少し直して公開しておこうと思う。

プログラミング初心者、TypeScriptの初心者の読者を想定した内容になっている。

---

登場人物

• 私：高校2年生の女子。プログラミングと数学が好き。
• デルタ：高校1年生の男子。プログラミング初心者。

ある日の放課後、私が高校の図書館の自習室に入ると、デルタがノートパソコンを広げたまま、手を止めて画面を見ているのが目に入った。

「なにか困りごと？」

「先輩、ちょうどいいところに来ましたね。ちょっとTypeScriptのコードを書いていたらエラーが発生していて困ってたんです」

私はデルタのノートパソコンの画面を見た。

「型のエラーが出てるね」

デルタに指示を出し、コードを修正するとエラーは消えた。

「デルタってコンパイルエラーとか、型のことわかってる？」

「わかってますよ。文字列だったら stringとか、数だったら number とか、変数につけるヒントみたいなイメージですよね」

「他には？」私は否定せずに聞く。

「後は……真偽値のbooleanとか」

デルタは宙を見つめながらTypeScriptの型を思い出そうとしていた。

「まあ、具体例は他にも色々あるよ。string, number, boolean はプリミティブ型だけど、それ以外にも配列やオブジェクトもあるよね。ほかにはanyやneverとか」

「……そういえば！　TypeScriptの型について、一つどうしても納得できないものがあって...…」

デルタはパソコンのエディタを開き、次のコードを書いた。

const s: "foo" = "foo";

「TypeScriptって、こういう書き方ができますよね？　これって不思議じゃないですか。型を書くところに具体的な値が書けてしまうように見えるのが、納得できないんです」

「たしかに少し分かりづらいね。確認だけど、次の定数にはどんな値を代入することができる？」

const x : number = ???

「1とか、2とか」

「そうだね。3でもいいし、4でもいい。100でもいいし、-1000でもいい」

「数ならなんでもいいってことですね。最小値と最大値はありますけど」

「その通り。では次は?」

const isOk: boolean = ???

「trueかfalseですね」

「その通り。それ以外の値は入らない。型というのは、その値がある集合の要素であるということを保証するものなんだ」

「集合って、数学の集合ですか？」

「そう。数学の集合風に表記するとこのように書ける」

私はノートを取り出し、次のように書いた。

「２つしかないので、外延的に書くことができるね。numberの場合はそうはいかないので、内包的に書こう。厳密な範囲までは覚えていないから、こんな感じでどうだろうか」

number = { n | 最小値から最大値までの浮動小数点で表せる数 }

「先ほどデルタは型のことをヒントのようなイメージといったけど、集合のイメージのほうが正しい」

「なるほど。型が集合だとは考えたことがなかったです」

「では、リテラル型に話を戻そう。このリテラル型を集合論の記法で書けるだろうか」

type T = "foo"

私はデルタの前にノートとペンを差し出す。デルタはペンを手に取り、少しだけ考えてから手を動かした。

「こうでしょうか」

「その通り。このリテラル型は foo という文字列のみを許容する型だ。したがってただ一つの要素 "foo" を持つ集合とみなすことができるんだ」

「あ、そういうことなんですね。型のところに値が来るのが納得できなかったんですけど、そういう書き方なだけで集合なんですね」

「リテラル型が集合だということがわかれば、Union型も理解しやすいだろう」

「Union型ってなんでしたっけ」

「Union型は集合の言葉でいうと、和集合のことだ」

「和集合って…」デルタはノートにペンを走らせ、和集合のベン図を書いた。「……このことですよね」

「そうだ。和集合が2つ以上の集合を合成してできた型であるように、Union型は2つ以上の型を合成してできた型だ。| で型を並べて書くことで Union型を定義できる。このUnion型がどういう意味か、説明できる？」

type Status = "success" | "loading" | "error"

「"success", "loading", "error" のいずれかってことですよね。あ、なるほどこれはリテラル型という要素が一つしかない集合の和集合を作っているんですね」

こうしてデルタはTypeScriptのリテラル型を理解することができ、その応用としてUnion型の記法についても理解することができた。

そして私はデルタにTypeScriptの型を説明しながら、プログラミングと数学の関係に美しさを感じていた。

（おわり）

---

見ての通り、数学ガールのパロディだ。数学ガールなら、この後ミルカさんが現れてより数学的な話をしてくれるのだろう。カリー=ハワード同型対応に続けるなど、より高度な内容に踏み込んでくれたら面白くなりそうだ。

AIでコーディングすることが当たり前となった今、TypeScriptの型について理解していなくてもTypeScriptのコードを書く事ができてしまう。しかし型について理解するとプログラミングについての理解がかなり深まるので、TypeScriptを触る人には理解してほしい。

個人で契約している Claude Code やCodex を使えるのに使わないのはもったいないので、いろいろ作ってみている。

ブラウザの拡張機能でテキストを読み上げるものを入れているが、言語やモデルの切り替えがスムーズにできず使い勝手が悪かった。そこで使いやすい自分用の拡張機能を作ることにした

Google Text to Speech APIを使用して選択されたテキストの音声読み上げを行う拡張機能が完成した。

こうやって自分用のソフトウェアを作るのが、Claude CodeやCodexのようなコーディングAIのによって簡単にできるようになったのがいい。ブラウザの拡張機能は手軽に作れるので、自分用のソフトウェアを作るのにはちょうどいいと思う。

これまでChromeの拡張機能を作ったことがなかったので、どういう構成のプロジェクトにしたらいいかとかは全く知識がなかった。 AIが作ったファイルを見て、こういうファイルが必要なんだという構成が知れて学びにもなった。

完成したものを実際に使っていくと、もうちょっとこうしたものができるな、こうした方がいいなというアイデアが湧いてきて、少しずつ機能が増えていった。

言語の選択を手動でやるのではなく選択された言語を検知して読み上げる機能を作りたいと思った。 言語の検出にはGemini APIを使用した。こういうのはLLMが得意なタスクだろう。既存のAPIキーにGeminiの権限を与えることで、導入済みのAPIキーをそのまま使えるというのも良かった。

さらに次はテキストを選択するのではなく記事を自動で検出して読み上げてほしいと思うようになった。 1から実装するのは大変なので Readability というライブラリを導入した。

ライブラリを導入することによってビルドする必要が出てきたので、ビルドできるようにした。GeminiのAPIを叩くのもこれまではAPIのエンドポイントを直接叩いていたが、これを機にGoogleのSDKを使用することにした。

こうして一通りほしい機能がそろったものは完成した。 せっかくGeminiを導入したので、他の機能も付け加えることにした。 記事を短歌の形に要約したり、ラップのように韻を踏んだ形で要約する機能を追加することにした。

以下の画像のような要約を生成して読み上げる機能が完成した。韻を踏む機能のクオリティはまだ改善の余地がありそうだ。

PRを更新するカスタムスラッシュコマンド

Custom Commandという機能がある。あらかじめ作っておいた指示をコマンドで呼び出せる機能だ。

• Slash commands - Claude Docs
• Claude Code でカスタムスラッシュコマンドを作成する

ghコマンドを使うと CLIでPRのタイトルと説明を更新できるので ~/.claude/commands/update-pr.md にPRのタイトルと説明を更新する指示を書いたmarkdownファイルを追加して、/update-pr で呼び出せるようにした。

---
allowed_tools: [Bash]
description: "現在のブランチのプルリクエストのタイトルと説明を、変更の差分に基づいて適切に更新します"
---

# プルリクエストの更新

現在のブランチに対応するプルリクエストを見つけて、以下の手順でタイトルと説明を更新してください:

1. **現在のブランチ確認**: `git branch --show-current` で現在のブランチを確認
2. **プルリクエスト確認**: `gh pr view` で現在のブランチのプルリクエストを確認（存在しない場合はエラーメッセージを表示）
3. **変更の差分確認**: `gh pr diff` で変更内容を確認
4. **既存のタイトル確認**: 既存のプルリクエストにタイトルが十分に内容を反映した内容に設定されている場合は、そのタイトルを変更しない
5. **タイトルと説明の生成**:
   - 既存のタイトルがないか適切でない場合: 差分の内容から適切な日本語のタイトルを生成
   - 説明: 差分の内容を分析し、変更内容の要約を日本語で作成（機能追加、バグ修正、リファクタリングなどを明記）
6. **プルリクエスト更新**: `gh pr edit --title "<title>" --body "<description>"` でプルリクエストを更新

**注意事項**:
- 説明は変更の内容を分かりやすく日本語で要約する
- コミットメッセージの履歴も参考にする
- プルリクエストが存在しない場合は、その旨を伝える
- リポジトリにPRのテンプレートがある場合はそのテンプレートを使用する

このカスタムコマンド自体、Claude に生成してもらったもので、あまり手を加えていないため、改善の余地はあると思う。

背景

AIを使ったコーディングでもこれまでの開発スタイルで重要だと思われていたことは、変わらずに重要だということが分かってきた。

なので適度な粒度でプリクエストを使って、レビューをしてマージをしていきたい。

AIを使うと大量のコードを書くことができる。その結果、プルリクエストの数も増える。タイトルや説明を書く作業も増える。

AIを使えば変更内容の概要などある程度のことはできるので、AIにやってもらうことにした。

まとめ

• 繰り返し行うような作業はスラッシュコマンドにどんどん追加して便利にしていきたい。リファクタリングやテスト用のカスタムスラッシュコマンドがあると便利かもしれない。
• このことを同僚に話したら似たようなスラッシュコマンドを作っていた。他の人が追加している便利なスラッシュコマンドも知りたい。

この１ヶ月くらい、生成AIのコーディングエージェントを活用したwebアプリケーションの開発をしてきたけど、AIを使うからどうこうという学びは少なかったかも。

むしろAI使わない時代の開発で重要だったものは、たいてい重要なままというのに気が付かされることのほうが多かった。

CIを整備してテストやビルドエラーやフォーマッターを自動で確認できるようにしたら便利、とか。リファクタリングして重複しているコードを減らしたら保守性があがる、とか。

こういうのをすべて飛ばして機能の実装を進めることは可能だけど、結局後で痛い目をみるので、ちゃんとやっておいたほうがいい。

当たり前すぎる。体重を減らすのには摂取カロリーを減らしましょう、とか運動と睡眠が健康にいいとかと同じくらい当たり前過ぎて面白みがない。

現在のAIが生成するコードの保守性が高くないというのがわかったから、そこを改善する指示を書いたり、定期的にリファクタリングするタスクをやらせるとかの工夫はあるといいかもしれない。