「新モデル祭り」の裏側―o3＆o4-miniを試して分かったけど…使えるのは結局“o1-pro”だった件
巷では ChatGPT o3 / o4-mini 出たすげえで、驚き屋が仕事に励んでおりますが、実際のところ、「え、それ使えるの？」「いや、なんか抽象的でビミョーじゃない？」とモヤモヤしている方も多いのではないでしょうか。そりゃあ新しいモデルが出るとワクワクしますよね。私も最初は「お、次世代バージョンだと？ めちゃくちゃ進化してるんだろうな？」とテンション爆上げでした。でもいざ見てみると、「んん？ 結局どうなの？」となりがち。特に今回話題になっているのが、同じプロンプトに対してAIが生成した 3種類の仕様書です。ここでは仮に「o3」「o4-mini」「o1-pro」と呼ぶことにしましょう。 結論をズバッと言うと、「o1-pro」以外は正直使いづらい！ これが現場エンジニアの結論です。いやもちろん、o3もo4-miniも一読の価値はあるんですよ。自分で手当たり次第に調べるよりはマシかもしれません。でも、本格的にプロダクトを組むなら o1-pro 一択だろ、というのが私の率直な感想です。今回は、その理由を少し細かく掘り下げてみたいと思います。
目次
- ざっくり比較：o3・o4-mini・o1-proとは何者？ - o3仕様書：抽象論ばかりで全然ピンと来ない話 - o4-mini仕様書：いろいろ書いてあるけど薄味 - o1-pro仕様書：いや最初からこれでいいじゃん - なぜ o1-pro が現場ウケするのか：5つのズバリポイント (1) ディレクトリ構成がそのまま実装可能 - (2) 非同期まわりを徹底してて速度も安心 - (3) DBスキーマとセキュリティ戦略が先手打ち - (4) テスト戦略とCI/CDまで言及してる - (5) 将来拡張もスムーズなアーキテクチャ - 海外コミュニティの最新トレンドと比べるとどうなの？ - まとめ：o3・o4-miniはネタで、o1-proがガチ 本題に入る前に、今回のお話は Python＋FastAPI＋Supabase＋OpenAI API の組み合わせを前提にしています。既にこういった構成でAIサービスを作り込んでいる方や、これから検討しようという方がメインターゲットですね。もし「そもそもFastAPIって何だっけ？」とか「Supabaseって聞いたことあるけどアプリ側でどう使うの？」みたいな超初心者の方でも、途中で噛み砕いて説明しますのでご安心を。 それでは早速参りましょう。1. ざっくり比較：o3・o4-mini・o1-proとは何者？
今回取り上げる 3つの仕様書は、すべて「同じ機能要件をもとに、AIモデルが書き出した仕様書」です。いわゆる「AIにテクニカル仕様書を書かせたらどうなる？」という実験で生まれた産物ですね。 - o3：最初期に出てきたバージョン。ざっくり言えば「運用やスケール時のポイント」を羅列した提案書っぽい代物。 - o4-mini：次世代感はあるものの、簡易化された記述。最小限の実装に特化してるが、詳細は読み手の脳内補完に任せる印象。 - o1-pro：最後に出てきたもの。設計の網羅度・深さが段違いで、実際の開発現場でも「そのまま使えそう」と言わせる完成度。 この3つを見比べると、o3 は中途半端な抽象論が多く、o4-mini は形だけ整ったミニマム仕様、そして o1-pro は“プロ向け仕様書”の名に恥じぬ中身という感じです。結局のところ「機能要件が抽象的だとAIの出力も抽象的になる」わけですが、o1-pro だけは何かが違う。おそらく執筆時のプロンプトやコンテキストがしっかりしていたことも理由でしょう。後述するように、エンドポイント定義やテスト戦略までセットで語られています。 因みに今回のプロンプトはこれ、# TASK:あなたは、Pythonのコーディングのエキスパート技術者として Pythonを利用したバックエンドAPI開発の仕様書を書き上げる必要があります。 上記の クライアント側UI仕様書 と API仕様書 を確認し、今回作成する必要があるPythonを利用したバックエンドAPI開発の仕様書を書き上げてください。最新の技術とあなたの高度なPython開発エンジニアスキルを駆使して一番簡単な仕組みで書き上げてください。 入れ込んだ仕様書は長すぎるので省略、3モデルとも全く同じ内容で実行。
2. o3仕様書：抽象論ばかりで全然ピンと来ない話
まずは o3 です。個人的には「うーん、悪くはないけど、実装に使うには物足りない」という印象。例えば「サービス分割してリトライ機構を設けると良い」「SupabaseでRLSを設定しておくとセキュリティ的にベター」といった、一般的なベストプラクティスが羅列されているんですよね。確かに言ってることは正しいんです。けど、いざ手を動かすときに「じゃあ実際どうやって設定すればいいの？」という部分がごっそり抜け落ちています。 さらに、テーブル設計やモデル定義の記述もざっくり。READMEレベルの断片を並べたっぽい感じ。「これはそのまま社内Wikiのチェックリストとして貼り付けるならアリかも…」という気はしますが、仕様書としてはもう一歩どころか二歩三歩踏み込んでほしいところですね。 「抽象論はありがたいけど、もう少し欲しい…！」というのが o3 仕様書を読んだときの感想でした。もし経験豊富なエンジニアがこれを読めば、なんとか補完できるとは思います。でも初心者や中堅クラスだと「ふーん、それで具体的には何をどう作るの？」という疑問がずっと残るでしょう。素晴らしく整理された仕様書です！ このまま実装に入っても大きな破綻は無さそうですが、運用フェーズを見据えて ―― とくに スケール と 保守性 ―― の観点で、もう少し詰めておくと後々ラクになるポイントをいくつか挙げます。
（気になるものがあれば深掘りしますので、お気軽にどうぞ。）
1. ルータ／サービス分割
| レイヤ | 推奨実装 | ねらい |
|-----------------|---------|-------|
| router | app/routers/story.py, app/routers/admin.py | URL ルーティングとスキーマ宣言だけに留め、ビジネスロジックを薄く保つ |
| service | app/services/story_service.py | OpenAI・ComfyUI・Supabase 呼び出しを集約。後からリトライやフォールバックを差し込みやすい |
| repository | app/repositories/ | Supabase テーブルごとに CRUD 抽象化。テスト時にモック差し替えが簡単 |
FastAPI の Depends による dependency‑injection で service／repository を注入しておくと、単体テストが書きやすくなります。
2. OpenAI & ComfyUI コールを包むユーティリティ
- バックオフ付きリトライ tenacity を利用し、rate_limit_error, timeout 系で指数バックオフ（max 3〜5 回）を推奨。
- タイムアウト短縮
OpenAI 側の応答が遅い場合は 30–60 秒で切る → 呼び出し履歴を Supabase に “pending” として書き込み、Celery/Arq/QStash など非同期ワーカーで再実行する設計もアリです。
- Streaming 対応
GPT‑4o 系は stream=True でトークンを逐次返せます。UI 側が SSE／WebSocket を取り込めるなら、同一エンドポイントに Accept: text/event-stream を付けた場合だけストリーム返却、のように分岐実装すると UX が上がります。
3. Supabase スキーマ補足
| テーブル | 主キー | 主なカラム | 備考 |
|-----------------|-------|-----------|-----|
| story_sessions | id (uuid) | user_id, context (jsonb), updated_at | RLS: user_id = auth.uid() に限定 |
| conversations | id (uuid) | session_id (fk), role, name, content, created_at | created_at に索引 |
| images | id (uuid) | session_id, url, prompt, created_at | Storage バケットのパスも保持 |
| saves | id (uuid) | user_id, session_snapshot (jsonb), title, created_at | |
jsonb に複雑な構造を飲み込ませておくとマイグレーションが楽になります。ただし UI 側で “最新の進行状況リスト” を頻繁にクエリする場合、story_sessions.updated_at インデックスは必須です。
以下長すぎるので略
3. o4-mini仕様書：いろいろ書いてあるけど薄味
次に o4-mini。こちらは先ほどの o3 よりはもうちょっと整理されているという印象です。セクション分けもちゃんとあって、「エンドポイントはこう」「データモデルはこう」「JWT認証はこれ」みたいに箇条書きが増量しています。最低限の説明はあるので、何となく「こうやって作るのかも？」と想像できるんです。 でも、あくまで「mini」ですからね。書いていないことが山ほどある。例えば「非同期IOを使おう」までは言うけど、どの場面でどんなライブラリを使うのか、具体的なサンプルコードはない。テスト戦略も「ユニットテストはやりましょうね」ぐらいで、CI/CDの構築手順なんかはほぼ言及ゼロ。セキュリティ面もサラッと触れるにとどまり、本当に骨格だけ示した仕様書です。 簡易ドキュメントとしては悪くないものの、現場の開発に投入するには情報が薄い。o3 ほど抽象的ではないけど、何か手応えが足りない。そんな印象ですね。以下では、クライアント側UI機能仕様書と既存のAPI仕様書を踏まえ、Python＋FastAPIを使って最もシンプルかつ拡張性のある形で組み上げるバックエンドAPI機能詳細仕様書を示します。
1. システム概要
- 目的: ユーザ入力（発言／行動）を受け、OpenAI API→（必要に応じて）ComfyUI API→Supabaseへ保存し、最新のストーリー状況を返却する
- 主技術:
- フレームワーク: FastAPI + Uvicorn
- データモデル: Pydantic
- DB クライアント: supabase-py
- AI クライアント: openai（非同期版）
- 画像生成クライアント: httpx（ComfyUI HTTP API 呼び出し）
2. 技術選定と構成要素
| 項目 | ライブラリ／サービス | 理由 |
|----------------------|-------------------------------|--------------------------------------------|
| Web フレームワーク | FastAPI | 型定義・自動ドキュメント・非同期対応が容易 |
| ASGI サーバ | Uvicorn | FastAPI 推奨 |
| 型検証・シリアライズ | Pydantic | リクエスト／レスポンス定義を明確に |
| DB（ストーリー保存） | Supabase（PostgreSQL + Storage） | 既仕様に合わせつつ、簡易クライアントで即利用可能 |
| 認証・認可 | Supabase Auth (JWT) | 既仕様Supabase Auth準拠 |
| AI ストーリー生成 | OpenAI Python ライブラリ | GPT 系モデル呼び出し |
| 画像生成 | ComfyUI HTTP API | 既仕様対応 |
| レート制限 | slowapi (Starlette ミドルウェア) | ユーザ・セッション単位のリクエスト制限実装が容易 |
| ロギング・モニタリング | Uvicorn ログ + Sentry（任意） | エラーキャプチャ・性能把握 |
3. 全体アーキテクチャ
1. クライアント → FastAPI
2. 認証チェック（JWT）
3. セッション状況をSupabaseから取得
4. OpenAI へプロンプト送信 → 生成テキスト取得
5. 必要に応じてComfyUIへ画像生成リクエスト
6. Supabaseに会話履歴／コンテキストを保存
7. レスポンス返却
mermaid
flowchart LR
A[クライアント] -->|POST /story/progress| B[FastAPI]
B --> C{Auth JWT チェック}
C -->|OK| D[Supabase: セッション/履歴取得]
D --> E[OpenAI: ストーリー生成]
E --> F{画像が必要?}
F -->|Yes| G[ComfyUI API 呼び出し]
F -->|No| H[スキップ]
G --> H
H --> I[Supabase: 保存]
I --> J[FastAPI: レスポンス組立て]
J --> A
4. エンドポイント一覧
| メソッド | パス | 機能 |
|--------|-----------------------|-------------------------------------|
| POST | /api/story/progress | 発言／行動に応じたストーリー進行と画像生成 |
| POST | /api/story/save | 現在セッションをセーブ |
| GET | /api/story/load | セーブデータからセッションを復元 |
| （管理者用）GET/POST/PUT/DELETE | /api/admin/ | シナリオ設定、ユーザ管理、パラメータ調整 |
以下長すぎるので略
4. o1-pro仕様書：いや最初からこれでいいじゃん
そしてやってきました o1-pro。もう最初からこれでいいでしょという完成度です。ここは私も読んでいて「おお、マジで書かれてる」と思わず唸りました。 たとえば、APIのエンドポイント定義が単なる箇条書きじゃなくて、 - POST /api/story/progress 入力モデル（Pydantic）: StoryProgressRequest - 出力モデル（Pydantic）: StoryProgressResponse - 処理フロー: 1. 認証チェック → 2. セッション取得 → 3. OpenAIへ問い合わせ → … → n. レスポンス - 主なエラーケース: 400, 401, 404, 500, 429 みたいにステップバイステップで書いてある。これなら誰が見ても「ここに書いてある通りに作ればいいんだな」と分かるわけです。で、さらにテスト方針やディレクトリ構成例（services/, routers/, models/ 的に分割すると良いよ、みたいな）も丁寧に記載。CI/CDのセットアップや Docker のイメージビルド方針まで載ってる。 最初から最後まで読んで「これだけ書いてくれてれば、正直もう実装できるじゃん」と思うレベルです。というか、現場でもこのくらい具体的に書いてある仕様書は珍しいかもしれません。普通はチームで相談したりスプリントで計画立てたりしながら細部が決まっていくんですが、o1-proにはすでに多くの細部が盛り込まれていました。後ほど詳しく言いますが、非同期処理の設計やSupabaseのRLS（Row Level Security）有効化みたいな高度なトピックもカバーしています。「全然ミニじゃない。めちゃくちゃプロ。」という感じですよね。以下に、Python を利用したバックエンド API 開発の機能詳細仕様書を示します。本仕様書では、「最小限の実装で動くシンプルさ」 と 「将来的な拡張性や保守性」 を両立することを目指し、主に FastAPI + Supabase + OpenAI API + ComfyUI API を組み合わせる構成としています。
Python バックエンド API 開発 機能詳細仕様書
1. システム概要
- フレームワーク: FastAPI
- 非同期実行 (async/await) による高パフォーマンス
- 型ヒントと Pydantic によるバリデーションとドキュメント自動生成
- データベース: Supabase (PostgreSQL)
- Python 用の Supabase クライアントライブラリを利用 (例: supabase-py)
- ユーザやセッション情報、セーブデータの管理
- AI 連携
- OpenAI API: ストーリー生成 (ChatGPT / GPT-4 など)
- ComfyUI API: キャラクターや背景などの動的画像生成
- 認証
- Supabase Auth (JWT Token) を使用
- もしくは簡易的に発行された API トークン (Bearer Token) による保護
- デプロイ先
- 自由 (例: Vercel, Heroku, AWS, Azure, GCP, あるいは Docker コンテナによるオンプレ)
本 API は、クライアント側 UI (Next.js + Supabase + Tailwind CSS) からリクエストを受け取り、ユーザの入力 (「発言」または「行動」) をもとに AI (OpenAI) によるストーリー生成を行い、必要に応じて ComfyUI へ画像生成をリクエストして結果を返却します。また、ゲームセッションやセーブデータは Supabase に保存され、ロード時に取得されます。
2. アーキテクチャ概要
mermaid
flowchart LR
A[FrontEnd
(Next.js)] --1. userInput POST--> B[FastAPI
(Python)]
B -->|2. 認証チェック
Supabase Auth or token| C[Supabase
DB]
B -->|3. ストーリー生成| D[OpenAI API]
B -->|4. 画像生成| E[ComfyUI API]
B -->|5. セッション/状態保存| C
B --6. レスポンス返却--> A
1. フロントエンドから、ユーザの入力やセッション ID が /api/story/progress に送信される
2. FastAPI 側でトークン検証などの認証チェックを行い、Supabase のセッション情報を取得
3. 必要なコンテキストを組み立てて OpenAI API へプロンプト送信、ストーリーテキストを生成
4. 必要に応じて ComfyUI API を呼び出し、背景やキャラクターなどの画像生成を行う
5. Supabase に更新後のストーリー状況やセーブデータ等を保存
6. 生成結果 (テキスト + 画像のパスなど) をフロントエンドに返却
3. 使用技術詳細
3.1 フレームワーク
- FastAPI
- Python 3.9+ を推奨
- Pydantic モデルによるリクエスト・レスポンスの型定義
- uvicorn or hypercorn 等の ASGI サーバで起動
- OpenAPI ドキュメント (Swagger UI, Redoc) を自動生成
3.2 データベース (Supabase / PostgreSQL)
- supabase-py ライブラリを使用して接続
- テーブル例 (簡易化):
- sessions: ユーザーのセッション管理
| カラム | 型 | 説明 |
|------------------|-----------|---------------------------------------|
| id (PK) | uuid | セッションID (主キー) |
| user_id | uuid | ユーザID |
| context_json | jsonb | 現在のストーリーコンテキスト (JSON) |
| updated_at | timestamptz | 更新日時 |
- saved_games: セーブデータ管理
| カラム | 型 | 説明 |
|------------------|-----------|---------------------------------------|
| id (PK) | uuid | セーブデータの主キー |
| user_id | uuid | ユーザID |
| session_context | jsonb | セッションコンテキスト一式 (JSON) |
| title | text | セーブのタイトル |
| created_at | timestamptz | 作成日時 |
- users: ユーザ管理 (Supabase Auth が自動生成)
3.3 AI サービス
1. OpenAI API
- openai ライブラリを使用
- ChatCompletion (GPT-3.5 / GPT-4 など) でストーリーを生成
- プロンプトには「世界観」「キャラクター情報」「直近の会話履歴」「ユーザ入力」を組み込み
- レスポンスからストーリーテキストやキャラクターのセリフを抽出
以下長すぎるので略
5. なぜ o1-pro が現場ウケするのか：5つのズバリポイント
ここからはもう少し切り込んで、o1-pro がなぜ良いのかを5つのポイントにまとめます。(1) ディレクトリ構成がそのまま実装可能
o1-proはディレクトリ例が以下のように示されていました（例）:app/
├── main.py
├── api/
│ ├── v1/
│ │ ├── story.py
│ │ └── save_and_load.py
├── models/
│ ├── request_models.py
│ └── response_models.py
├── services/
│ ├── openai_service.py
│ ├── comfyui_service.py
│ └── story_logic.py
├── database/
│ └── supabase_client.py
├── core/
│ ├── auth.py
│ └── rate_limit.py
└── ...
これがあるだけで「なるほど、APIルーターは api/v1/ 配下に置くんだな」とか「ビジネスロジックは services/ に固めるのか」といった構造がひと目で把握できます。経験者は「DI を意識して router → service → repository のような層にしておくと後々テストしやすいよね」というのは言わなくても分かるでしょうが、仕様書に書いてあると新人にも伝わりやすい。他のo3やo4-miniはここがかなり曖昧で、「ファイル分け？ まあ適当に頑張ってね」くらいで終わっていました。