TypeChat はプロンプトではなく型を書く、LLM 出力の検証と修復の設計
TypeChat is a library that makes it easy to build natural language interfaces using types.
ひと目でわかる
- これは何？
- TypeChat は自然言語入力を TypeScript の型に落とし込むためのライブラリだ。スキーマ定義、検証、失敗時の修復という流れを README から読み解き、向く用途と向かない用途を分ける。
- 誰に向いている？
- 既存の TypeScript コードベースに判別可能な共用体で表現できる意図がすでにあり、LLM の応答をその型に押し込めたいチームには向く。逆に、応答の形が毎回変わる探索的な用途や、型では表せない自由記述を主目的にする用途には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
プロンプトエンジニアリングの代わりに何を置くのか
README は、自然言語インターフェースの構築が伝統的に難しかった理由として、意図の判定と必要な入力の収集を複雑な決定木に頼っていた点を挙げている。LLM はこの部分を容易にしたが、応答を安全のために制約すること、後続処理のために構造化すること、応答が妥当であることを保証することという別の課題を持ち込んだ。プロンプトエンジニアリングはこの課題への答えだが、学習曲線が急で、プロンプトが長くなるほど壊れやすくなる。TypeChat の主張はここに対するもので、プロンプトエンジニアリングをスキーマエンジニアリングで置き換えると表現されている。対象読者は、感情分類のような単純なインターフェースから、ショッピングカートや音楽アプリのような複数段の入力収集までを LLM で扱いたい TypeScript 開発者だ。
型を書くと何が自動で起きるか
README によれば、開発者がやることは意図を表す型を定義することだけだ。追加の意図は判別可能な共用体に型を足して表現し、スキーマを階層化したい場合はメタスキーマを使ってユーザー入力に応じて一つのサブスキーマを選ばせる。型を定義した後は三つの処理が続く。第一に型を使って LLM へのプロンプトを構築する。第二に LLM の応答がスキーマに適合するか検証し、適合しなければ言語モデルとの追加の対話を通じて不適合な出力を修復する。第三に、LLM を使わずにインスタンスを簡潔に要約し、ユーザーの意図と一致するかを確認する。三番目が LLM を介さない点は見落としやすい。要約と確認は決定的な処理として行われるという設計だ。
検証と修復の往復が意味するコスト
この設計の中心は、モデルの出力をそのまま信頼しないことにある。検証に失敗した場合、TypeChat は追加の言語モデル対話で修復を試みる。つまり一つのユーザー入力に対してモデル呼び出しが一度で終わらない可能性がある。README は修復の試行回数や打ち切りの条件、レイテンシへの影響について何も述べていない。ここは導入前に自分で確かめるべき領域だ。プロンプトにスキーマを含める以上、スキーマが大きくなれば入力トークンも増える。判別可能な共用体に型を足していくほどプロンプトは長くなり、README がプロンプトエンジニアリングの欠点として挙げた「プロンプトが大きくなるほど脆くなる」問題が、形を変えて戻ってくる可能性がある。型で制約しても、スキーマ自体の肥大化は別問題として残る。
導入の手順と、README が示す範囲
TypeScript/JavaScript 向けの導入は README では `npm install typechat` の一行だ。Python と C#/.NET についてはソースから作業する形が案内されており、Python はリポジトリ内の `python/README.md`、TypeScript は `typescript/README.md`、C#/.NET は別リポジトリの microsoft/TypeChat.net が参照先として示されている。動作を見るには `typescript/examples` のサンプルプロジェクトをローカルか GitHub Codespace で試すことが推奨されている。README の本文にはモデルの指定方法、API キーの設定、プロバイダの選択といった設定キーの記述は含まれていない。これらは上記の各 README とドキュメントサイトに委ねられている。ライセンスは MIT で、リポジトリはアーカイブされていない。
型で表せないものは型で守れない
TypeChat が保証するのは、応答がスキーマに適合していることだ。適合した応答が意味的に正しいことや、ユーザーの意図を実際に満たしていることは保証しない。README の三番目の処理が要約と確認を別途行うのはこのためだと考えられる。したがって、応答の形が事前に決まらない用途、たとえば自由記述の文章生成や、対話のたびに新しい構造を生み出す探索的なタスクにはこの道具は合わない。また、意図を判別可能な共用体として整理できることが前提になる。業務の意図が絡み合っていて型に落とせない場合、TypeChat を入れても整理されない。整理されていないものをスキーマとして書けば、そのままプロンプトの肥大化になる。
プロンプトを自前で組む場合との違い
比較対象として素直なのは、OpenAI の Structured Outputs や JSON Schema を指定できる各社の関数呼び出し機能を、自前のプロンプトと組み合わせて使う方法だ。違いは検証失敗後の扱いにある。自前で組む場合、応答がスキーマに合わなければ開発者がエラーハンドリングを書き、再試行のプロンプトを組み立てる。TypeChat はこの修復をライブラリの処理として持ち、型定義からプロンプトを生成する部分も含める。逆に、プロバイダ側が構造化出力をネイティブに強制できるなら、TypeChat の修復機構は二重の安全策になる。どちらが良いかは、対象モデルがスキーマ準拠をどこまで自力で守れるかに依存する。README はこの比較には触れていない。
維持コストとライセンスの確認点
MIT ライセンスなので、商用利用を含めて比較的自由に組み込める。ただしライセンス文の保持など条件の解釈は個別に確認が必要で、ここで法的助言はできない。維持の観点では、TypeChat は Microsoft のリポジトリとして公開され、コントリビューションには CLA への同意が必要と README に明記されている。これは外部からの変更提案の敷居を上げる方向に働く。また README には、このプロジェクトが Microsoft の商標やロゴを含む可能性があり、改変版での使用は Microsoft のスポンサーシップを示唆してはならないと書かれている。フォークして製品に組み込む場合、名称とロゴの扱いは別途確認が要る。リリース情報は取得できておらず、バージョニングの方針は本記事では判断できない。
編集部の結論
既存の TypeScript コードベースに判別可能な共用体で表現できる意図がすでにあり、LLM の応答をその型に押し込めたいチームには向く。逆に、応答の形が毎回変わる探索的な用途や、型では表せない自由記述を主目的にする用途には向かない。導入前に確認すべきは、README が示す検証と修復の往復が自分のモデルとレイテンシ予算で許容できるか、そして対象モデルがスキーマを含むプロンプトで安定して構造化出力を返すかだ。
コミュニティノート