TypeScriptとPython——AIエージェントを組むときの言語選択

Alex Ishiguro • • • 読了目安：5分
TypeScriptとPython——AIエージェントを組むときの言語選択
目次▼
  1. 1結論を先に
  2. 2具体例：言語が決めるのは「モデル」ではなく「契約」
  3. 3TypeScriptが強い領域
  4. 4Pythonが強い領域
  5. 5混在させても壊れない切り方
  6. 6コネクタ（ツール）視点での言語差
  7. 7バイブコーディングとの相性
  8. 8選ぶときの短いチェックリスト
  9. 9よくある失敗
  10. 10いまの一手

「どっちが強い？」という問い方は、だいたい失敗する。強いのはモデル側で、言語側が決めるのはどこで壊れ、どこを人間が監査し、どこを再実行できるかだ。

この記事はプレイブックではない。AIエージェント／ツール呼び出しアプリを実際に組むとき、TypeScript（主に Node / Edge）と Python（主に FastAPI / worker）のどちらを軸にするかを、ランタイム・型・コネクタ・検証ループの単位で切り分ける。

この記事の使い方

  • 決めること: リポジトリの「主言語」と、「モデル呼び出し境界」の置き場所
  • 決めないこと: 「PythonこそAI」「TSはフロントだけ」みたいな陣営論
  • 前提: LLMはツール呼び出し・構造化出力・長文生成が使える。ローカル専用の研究コードではない

結論を先に

仕事軸にしやすい言語理由（短い）
Webアプリに埋め込むエージェント（UI・API同居）TypeScript同一型・同一デプロイ・同一観測
バッチ調査・スクレイプ・数値パイプラインPythonデータ系ライブラリとノート再利用
MCPサーバー／エディタ連携ツールTypeScript が多い（仕様上どちらでも可）SDK成熟度と配布単位
研究プロトタイプ→本番移植プロトは Python、境界は TS に閉じる、が現実的速度と契約の分離

例外はある。ただ例外を増やす前に、上の表で足りない理由を一文で書けるかが分岐点になる。

具体例：言語が決めるのは「モデル」ではなく「契約」

モデルは差し替えられる。差し替えにくいのは次の契約だ。

  1. 入出力の形 — JSON schema / Zod / Pydantic で何を必須にするか
  2. ツールの副作用 — ファイル書き込み、外部API、課金、公開
  3. 失敗の見え方 — タイムアウト、部分成功、再試行可能か
  4. 人間の介入点 — どこで stop / approve するか

言語選択は、この4つを「型とテストで固定しやすいか」の問題に近い。ベンチマーク比較ではない。

TypeScriptが強い領域

1. プロダクトと同じプロセスにエージェントを載せる

Next.js / Astro / Hono など、すでに TS で動いている面にエージェントを足すなら、別言語 worker を最初から切る必要は薄い。

  • リクエスト単位の認証・セッションをそのまま渡せる
  • レスポンス streaming を UI と同じスタックで扱える
  • 「フロント用DTO」と「ツール引数」を同じ Zod スキーマで共有できる

特に 構造化出力 → UI への即反映 が主戦場なら、TS の勝ちやすい局面が多い。

2. 型を「プロンプトの外側」に置く

良いエージェントは、モデルに型を説明しすぎない。型はランタイムのバリデータ側に置く。

import { z } from 'zod';

const Verdict = z.object({
  buy: z.enum(['yes', 'no', 'conditional']),
  reasons: z.array(z.string()).min(1).max(5),
  openQuestions: z.array(z.string()).max(5),
});

// モデル出力は必ず parse。失敗したら再生成か人間へ。

Zod（や Valibot）で失敗した出力を「文章として正しいが契約違反」として弾ける。ここが薄いと、バイブコーディングで一見動くものが本番で静かに壊れる。

3. MCP・IDE・Edge への距離

MCP サーバーやエディタ拡張、Vercel / Cloudflare 寄りの配置では TS の事例と SDK が厚い。配布が npm 一発、型定義がそのままクライアント契約になる。

ただし「TSだから MCP」ではない。Python 実装も正当。差は 配布単位と既存スタックとの距離 にある。

Pythonが強い領域

1. データが主で、UIが従の仕事

スクレイピング、表結合、埋め込み生成、評価セットの回し読み、ノートでの試行錯誤——ここは Python の重力が強い。

  • pandas / polars で中間成果物を残しやすい
  • 評価（LLM-as-judge、回帰セット）をスクリプトとして固定しやすい
  • 研究寄りのライブラリが先に Python に落ちることが多い

「調査メディアの下調べをバッチで回す」「毎晩ソースを集めて差分だけ人間に渡す」なら、Python worker を別に置く合理は大きい。

2. 長時間ジョブと明示的なキュー

エージェントが数分〜数時間かかるなら、Web リクエストに乗せず worker 化するのが正しい。Python はその手のジョブランナー事例が多い。

ここで重要なのは言語名より 境界:

  • Web（TS）はジョブを投げる・状態を読むだけ
  • Worker（Python）は副作用と再実行を持つ

言語を混ぜるなら、混ぜる単位は「ファイル」ではなくこの境界にせよ。

3. 数値・音声・画像の前処理

純粋なテキストエージェント以外——音声の前処理、画像の正規化、古典 ML の前段——は Python が依然として短い。ここを無理に TS に寄せると、依存の地獄だけが増える。

混在させても壊れない切り方

混在は悪ではない。共有すべきでないものを共有するのが悪い。

共有してよいもの

  • プロンプト本文（Markdown / テキスト）
  • JSON Schema（生成物の契約）
  • 評価用の入出力フィクスチャ
  • 観測イベントの名前（tool.started / tool.failed）

共有しないもの

  • ORM モデル
  • UI コンポーネント
  • 「なんとなく便利な util」（片側の例外処理が染みる）

実践的なリポジトリ形:

/apps/web          # TypeScript — UI + 薄い API
/workers/research  # Python — 収集・評価・重い生成
/contracts         # JSON Schema / golden fixtures（言語非依存）

contracts を先に置くと、バイブコーディングで両側が勝手に型を伸ばす事故が減る。

コネクタ（ツール）視点での言語差

ツール呼び出し品質はモデル依存が強いが、ラッパの書きやすさは言語で変わる。

コネクタの種類書きやすい側注意
HTTP JSON APIどちらでもタイムアウトと冪等キーを先に設計
ブラウザ自動操作Python 事例が厚いこともフレーキをゲートに組み込む
エディタ／MCPTS が無難なことが多い権限スコープを最小に
クラウド公式 SDK公式が厚い方「薄い方に無理やり寄せない」

ハックに見えるが効く技法: ツール関数は モデルに見せる説明 と 実装 を分離する。説明は短く、実装は厳密に。言語が違っても、この分離は共通で効く。

バイブコーディングとの相性

バイブコーディング（AIと対話しながら形にする）では、言語より フィードバックの速さ が勝敗を分ける。

  • TS: 型エラーがすぐ赤くなる。エージェントが壊した契約に気づきやすい
  • Python: 実行して初めて壊れることが多い。その代わり試行の初速は出やすい

だからこそ:

  1. プロトは速く回る言語でよい
  2. 公開面に出す前に契約（schema + golden test）を言語非依存で固定する
  3. 本番の主言語は、デプロイと観測が既にある側に寄せる

「全部を最初から正しい言語で書く」より、「どの時点で契約を凍らせるか」の方が、現場では効く。

選ぶときの短いチェックリスト

次を上から見て、2つ以上当てはまる側を軸にする。

TypeScript寄り

  • すでに Web/API が TS
  • ユーザー向け streaming UI が本体
  • 同一 PR で UI とツール定義をレビューしたい
  • Edge / serverless に載せたい

Python寄り

  • データフレーム・評価セットが本体
  • ジョブが分単位以上
  • 研究ライブラリ依存が太い
  • ノートで再現可能性を残したい

両方3つ以上当てはまるなら、混在 + contracts/ を選べ。無理に単一言語に閉じない。

よくある失敗

  1. 「AIだから Python」 — Web の認証とセッションを二重管理して破綻する
  2. 「全部 TS でデータ処理」 — 依存が肥大し、評価ループが遅くなる
  3. モデル出力を信頼して DB に書く — 言語を問わず最悪。必ず schema parse
  4. ツールに広い権限を渡す — バイブコーディング中に本番を壊す最短経路

いまの一手

本気の人

TypeScript は プロダクトと同じ契約の中でエージェントを飼う のが上手い。Python は データと長時間ジョブと評価 が上手い。モデルの優劣表を言語に投影しないこと。

次に読むなら、同じピラーの「コネクタ活用」でツールの失敗モードを、「バイブコーディング」で検証ゲートの置き方を深掘りする。言語は入口で、出口はいつも契約と観測だ。

※この記事の内容についてご意見・ご指摘がある場合は、お問い合わせよりご連絡ください。確認の上、必要に応じて追記・訂正します。

まだ様子見の人

今週は読むだけでよい。用語の地図と結論表だけ先に共有し、実装や転職の判断は次の縦スライスまで保留する。

シェアする

𝕏 でシェア LINE でシェア はてブ
← 記事一覧へ
A

Alex Ishiguro

編集長

MakuakeやCAMPFIREで話題になった商品の「その後」を追うメディアを運営。約束されたものが実際に届いたのか、消えてしまったのかを記録する。

この記事に追加情報や訂正がある場合は、お問い合わせよりご連絡ください。