Shinichi Nakagawa(@shinyorke)
AI Platformを扱うソフトウェアエンジニアを本業とする傍ら, 「野球AIエンジニア」として活動.
2012年から野球（MLBおよびNPB）のデータ分析・システムづくりをPythonで行っており（本業にしていた時期あり）, 近年は成績予測およびこれらを本格活用するデータ分析基盤の開発・運用を行っている.
本業および野球AIエンジニアで得た知見をブログ, 登壇等で継続的に発表.
表彰&登壇: Google Cloud Partner Top Engineer 2024, PyConJPおよびデブサミでの登壇複数回.
推しのPythonはFastAPIとmarimo, 推しのクラウドサービスはCloud RunとBigQueryで推しの野球選手は万波中正（北海道日本ハムファイターズ）.
Session
「全ての野球に関わる人にAI Agentで野球に新たな価値を吹き込みたい」
私はそんな気持ちでMLB（メジャーリーグ）野球分析AI Agent「The Scouter 3」を開発しました（詳細）。
その際に私は以下の課題に直面しました。
- LLMのレスポンスが遅い
- 出力が不安定
本トークでは、これらの課題をFastAPIの設計パターンでどうやって向き合い、解決したかを紹介します。
仕様とシステム構成
- Geminiを用いてMLBの選手レポートを出力
- BackendはFastAPI, FrontendをNext.jsで構築
- Cloud Run（Google Cloud）でホスト
トークの構成
Live Demoで実際の分析レポートをお披露目します。
その上で2つの課題と意思決定について話します。
LLMのレスポンスが遅い
SSE（Server-Sent Events）を選択した背景からFastAPI StreamingResponseの実装までをコード付きで解説し、Next.jsプロキシやCloud Runタイムアウトなど運用上の落とし穴も一問一答で紹介します。
出力が不安定
Markdownフォーマット制御とPydanticによる出力バリデーションの合わせ技、野球ドメイン知識をプロンプトにどう注入するかの設計判断を共有します。
技術的な意思決定
LangChain等のフレームワークを使わずgoogle-genai SDKを直接利用した判断基準。
LLMをプロダクトに組み込むエンジニアが、知見として持ち帰れる再現可能な設計パターンを提供します。