TypeSafe AI

TypeSafe AIを選ぶ理由

TypeSafe AIは、チャットやコーディングモデルとは異なる方法でアプリに知能を加えます。汎用モデルに推論とJSON生成を任せて検証の成功を期待する代わりに、ソフトウェアで定義した判断の流れの中へモデルを組み込みます。

制御フローをアプリ側が持つ点が違いです。Jevは状態と限定された問いを受け取り、結果を次の操作にどう使うかは通常のコードが決めます。最終的にif、順位付け、振り分け、ポリシー確認に使う出力に適しています。

型が正しくても判断は誤る可能性があり、モデルのエラーをなくす設計ではありません。利点は、不確実性を説得力のある文章の中に隠さず、周辺のコードで明示的に扱えることです。

基本的な作業の流れ

まず、アプリの状態と評価する質問を分けます。状態にはチケット、文書、会話、取得した文章、モデルの実行記録など、判断に必要な情報を含められます。

次に、固定的なコードでは扱いにくい個別の意味判断を洗い出します。モデルに業務全体を決めさせず、それぞれの判断を通常のルールと組み合わせます。

AIサポートなら、返金の要望か、緊急か、アカウントの状態が自動処理を許すか、上位対応が必要かを別々に評価できます。四つの観点を不透明な単一プロンプトへ任せず、個別に確認して重み付けできます。

処理が大きくなるほど、この構成が役立ちます。業務ルール、DB照会、権限、計算、状態遷移は通常のコードに残し、意味、曖昧さ、あいまいな分類によって手書きルールが壊れやすい部分だけをモデルに任せます。

活用例

AIエージェントの実行基盤作りに適しています。ツール呼び出し、取得した情報、モデル選択、プロンプトインジェクション、回答品質、別モデルの信頼性について、低コストの判断が必要になるためです。小さな判断モデルを高価な生成モデルの前後に置き、エージェント全体の処理を任せずに使えます。

大量の意味処理にも向いています。分類、文書の選別、検索順位の調整、エンティティ照合、審査、特徴抽出、検証は、数千・数百万件に対して短い回答だけを求める処理です。後続コードがラベルや確率しか使わない場合、長い文章生成への費用は不要になり得ます。

モデルの振り分けにも使えます。意図、難しさ、関連性、リスクを見て、固定処理、安価な言語モデル、推論モデル、人の確認を選びます。振り分け方針をプロンプト内に隠さず、コードで確認できます。

生成モデルの後で、取得文章が主張を裏付けるか、ツール呼び出しが依頼に反しないか、脱獄を試みる内容ではないかを確認できます。検証も確率的ですが、確認対象のモデルとは独立して結果を扱えます。

汎用LLMの構造化出力との比較

OpenAI、Anthropic、GoogleなどもJSONやスキーマに沿った応答を返せるため、多くの同じ用途で代替になります。生成や長い推論も必要なアプリでは特に有効です。

汎用LLMは、文章生成モデルの出力を制約して構造化したインターフェースを作ります。一方、Jevは構造化された判断そのものを中心に設計されています。対象を絞ることが魅力であり、制約でもあります。

問題理解、多段階の推論、文章作成、ツール利用をひとつの依頼で行い、最後に構造化結果を返すなら、汎用LLMが合う場合があります。手順が決まっており、途中の特定箇所で素早い意味判断が必要ならJevが向いています。

すべての用途で置き換えられるものではなく、併用も可能です。自由度の高い仕事は生成モデルに任せ、Jevは高コストな呼び出しの前後で、振り分け、確認、順位付けなどを担います。

おすすめの構成

設定の中心は長いシステムプロンプトではなく、処理の設計です。質問はできるだけ単一の観点にします。関連性、安全性、緊急度、事業上の価値を分けると、コードで制御しやすく、失敗の原因も調べやすくなります。

信頼度のしきい値はモデル共通の性質ではなく、アプリ側の定数として扱います。記事分類の誤りは修正しやすくても、決済やアカウント保護の誤操作は重大です。自動実行の基準は、意味のある操作区分ごとに検証します。

複数の判断で同じ状態を使うなら、まとめて評価できます。質問は独立して処理されるため、後で必要になりそうな信号を先に集め、制御フローで必要なものだけ利用できます。

Claude Code、Codexなどの対応環境にAPIの使い方と設計指針を渡すスキルが公開されています。ただし資料では、生成された質問としきい値をレビューし、エージェント作成の方針を無条件に正しいとしないよう勧めています。

移行時の注意点

既存の構造化出力分類器から移す際、周辺アプリ全体を先に設計し直す必要はありません。状態を入力し、型付きの質問を評価して構造化回答を得る、判断インターフェースが共通の抽象になります。

公開プロジェクトsystem-one-adapter-pythonは、汎用LLM API上に互換性のあるSystem One型インターフェースを実装します。OpenAIやAnthropicを使う既存方式とJevを、別々のプロンプトではなく同じ処理構成で比較できます。

まずモデル非依存の業務ロジックと意味判断を分ける移行が実用的です。振り分け、しきい値、操作がコードにあれば、判断の提供元をテスト・交換しやすくなります。

「事例を読み、すべての対応を決める」といった大きなプロンプトはSystem Oneには不向きです。具体的な判断へ小さく分けると、評価、バージョン管理、変更がしやすくなります。

Jevは早期アクセスのホスト型モデルのため、本番ではAPIの可用性、バージョン変更、代替処理も考慮します。重大な操作を行うシステムは、応答がないことに判断を任せず、タイムアウトや障害時の動作を明示的に定める必要があります。