2026 年 5 月、Zenn Trending で OpenAPIという間接的な型共有をやめてoRPCを導入した話 が話題になり、TypeScript モノレポでの型共有を OpenAPI ベース（生成型）から oRPC ベース（直接型）に切り替える動きが本格化しています。
受託案件で頻発する 「OpenAPI スキーマと実装がズレてフロントが壊れる」 問題は、根本的には 「型を生成で間接共有している」 構造に起因します。本記事では受託 API プロジェクトを 2026 年式に更新する方法を整理します。
なぜ OpenAPI 型共有が「間接的」と呼ばれるか
OpenAPI を中心に据えた型共有は次のフローです。
[OpenAPI YAML/JSON]
│
├─ generate ─→ [TS 型定義（クライアント）]
│
└─ generate ─→ [TS 型定義（サーバー）]
│
└─ 実装が変わると YAML 更新が必要このフローの問題は次の 4 点です。
| 問題 | 受託案件での影響 |
|---|---|
| 二重管理 | YAML と実装の同期がズレる |
| 生成タイミング | CI で生成→コミット忘れ→壊れる |
| 型表現力の劣化 | TS の Discriminated Union が表現しきれない |
| ランタイム検証分離 | スキーマと Zod 検証が二重に書かれる |
これは 既存 SaaS API を MCP サーバー化する設計パターン で扱った “API 表面” の議論を、内部の FE / BE 間に展開した話です。
oRPC が変える「直接型共有」
oRPC は TypeScript の型をそのまま FE / BE で共有するライブラリで、tRPC の系譜にあります。OpenAPI と決定的に違うのは 「コード生成しない」 ことです。
[サーバー側 oRPC ルーター定義（TS）]
│
├─ export type AppRouter = ...
│
▼
[クライアント側 import type { AppRouter }]
│
└─ 完全な型補完が効く4 つの構造的優位
| 項目 | OpenAPI 生成型 | oRPC 直接型 |
|---|---|---|
| 生成ステップ | あり（CI 必須） | なし |
| 型表現力 | YAML の制約内 | TS フル機能 |
| ランタイム検証 | 別途 Zod 等 | スキーマと型が一体 |
| API ドキュメント | YAML から自動 | OpenAPI 出力可能（oRPC は両対応） |
| 外部公開 | 標準で対応 | OpenAPI 互換層あり |
oRPC は OpenAPI 出力も標準対応しているため、「外部公開には OpenAPI、社内 FE/BE 間は直接型」 というハイブリッドが可能です。これが tRPC との大きな違いで、外部 SaaS 受託案件でも使える理由です。
受託案件での適用判断 — 3 つの軸
軸 1: クライアントの種類
| クライアント | 推奨 |
|---|---|
| 自社開発 TS フロント（Next / Astro） | oRPC 推奨（型補完が最強） |
| 外部開発者向け公開 API | OpenAPI 維持 + oRPC で内部実装 |
| モバイル（Swift / Kotlin） | OpenAPI 必須（言語横断） |
| AI エージェント向け | MCP サーバー化を別途検討 |
軸 2: モノレポ構成
oRPC は モノレポ前提で効果が最大化されます。FE / BE が別リポだと型共有の旨味が半減します。これは マルチリポ中央地図 AI 受託 で扱った “リポジトリ戦略” と整合する判断です。
軸 3: チーム構成
FE / BE が 同じチーム / 同じエンジニアで開発する受託案件では、oRPC の生産性向上が直接効きます。逆に、FE と BE が完全別組織だと OpenAPI の方が境界が明確で運用しやすい場合もあります。
移行設計のロードマップ
[Phase 0: 評価] 1 週間
├ 既存 API の棚卸し（エンドポイント数・複雑度）
├ クライアント種別の整理
└ Go / No-Go 判断
[Phase 1: 基盤導入] 2 週間
├ oRPC ルーター骨組み
├ CI / build 統合
└ 既存 OpenAPI との並行運用準備
[Phase 2: 段階移行] 6 〜 12 週間
├ エンドポイントを機能単位で oRPC 化
├ FE 側で oRPC クライアント呼び出しに置換
└ E2E テスト維持
[Phase 3: OpenAPI 出力] 2 週間
├ 外部公開エンドポイントの OpenAPI 出力
├ ドキュメントサイト整備
└ クライアント SDK 自動生成
[Phase 4: 旧コード除去] 2 〜 4 週間
├ 旧 OpenAPI 生成コード削除
├ 関連ライブラリの整理
└ 移行完了報告Phase 2 を機能単位で進めることで、「移行中も止まらない」 受託案件の典型パターンを保てます。
受託契約に書く oRPC 採用条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 外部公開 API の互換性 | OpenAPI 出力の維持と互換保証 | 既存外部クライアントへの影響 |
| エンドポイント命名規則 | RPC スタイル vs REST スタイル | 顧客の運用慣習との適合 |
| エラー設計 | 業務エラーと HTTP ステータスの対応 | 既存監視との整合 |
| ランタイム検証 | Zod ベースの入力検証範囲 | セキュリティ要件 |
| ロールバック条件 | 移行が困難と判明した場合の戻し | リスク管理 |
特に 「外部公開 API の互換性」は、「内部で oRPC を採用しても外部からは OpenAPI に見える」 ことを契約で明文化することで、外部開発者を巻き込まずに移行できるようにします。
価格モデル — oRPC 移行受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| Eval | 50 万円〜 | 1 週間 | 評価 + 移行計画 |
| Lite | 250 万円〜 | エンドポイント 20 個未満 | 単一サービスの移行 |
| Standard | 700 万円〜 | エンドポイント 100 個未満 | 並行運用 + 全面移行 |
| Enterprise | 1,500 万円〜 | 大規模モノレポ | 複数プロダクト横断 |
ハマりやすい 4 つの落とし穴
落とし穴 1: 「型補完が効いて速い」を過大評価
oRPC の最大価値は 「型ズレを起こさない」 ことで、「実装速度 3 倍」 とまでは言えません。「障害を減らす」 という観点で顧客に説明します。
落とし穴 2: REST 慣れチームでの混乱
RPC スタイルに慣れていないチームは 「メソッド名で機能を表現」 する文化に違和感を持ちます。最初のレビューで設計レビュー会を入れます。
落とし穴 3: 外部開発者への説明
外部公開エンドポイントが OpenAPI で出ても、「中身は oRPC」 と聞くと不安に思う顧客はいます。OpenAPI 出力のサンプルを初期に共有します。
落とし穴 4: エラーレスポンスの設計漏れ
oRPC は TS エラーで表現できるため、HTTP ステータスを軽視しがちです。監視・ロギングと整合する設計を契約初期に決めます。
まとめ — 「生成」から「共有」へ
oRPC が示すのは、「型を生成で間接共有する」時代の終わりです。TypeScript モノレポ + 自社 FE / BE という受託案件の典型構成では、oRPC への移行で「OpenAPI 生成のズレ」が原因の障害がゼロに近づきます。
弊社では Eval / Lite / Standard / Enterprise の 4 段階で oRPC 移行受託パッケージを提供しています。「OpenAPI 同期ズレで毎月のように障害が出る」「TypeScript モノレポを 2026 年式に更新したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
