PortX / Formula — 事業紹介
競争優位を、今日から実装する
ユーザー主導SIのためのOS
PortXは、大企業の業務を実装するソフトウェア会社。
Spec-Driven Development プラットフォーム Formula を自社で開発・運用しています。
ソフトウェア会社です。
SI会社ではありません。受託開発会社でもありません。
業務を最も知る人と、ITを最も知る人が別人であるという分離が、エンタープライズSIの歪みの根本原因。
PortXは、その分離を消すためのソフトウェア(Formula Platform)を自社で開発・運用し、
大企業のユーザー部門が「業務を変える主導権」を取り戻せる構造をつくっています。
エンタープライズSIの歪みは、たった1つの分離から派生している
「業務を最もよく知る人」と「ITを最もよく知る人」が別人であること。この一点から、4つの構造歪みが必然的に生まれる。
業務知識はユーザー企業の現場部門に、IT実装能力はベンダー企業の末端エンジニアに偏在している。この2つが直接つながらないから、間に多重下請け・要件定義書・仕様書・テスト仕様書という「翻訳レイヤー」が積み重なり、歪みが固着する。
業務を最も知る末端エンジニアの単価が、最も低い
業務を翻訳して伝える階層が必要なため、元請→二次→三次→末端の多重下請けが成立する。1人月150万→30万まで中抜きされ、業務知識に最も近い人ほど報酬が低い逆ピラミッド構造になる。
生産性を上げるほど、ベンダーは貧しくなる
業務とITが分離していると価値の単位が「機能」になり、必然的に「人月」で計らざるを得ない。人月で売る限り、効率化するほど請求額が減る。業界全体が生産性を上げないインセンティブに縛られる。
業務で困っている人が、最後まで発注に届かない
分離があるから情シスという翻訳層が必要になる。予算・発注権が情シス経由になり、現場の痛みは情シスを経由するうちに二次情報化し、発注書に辿り着く前に変質する。
同じ業務が、5フェーズで5つの別書式に作り直される
業務とITの間に翻訳が必要だから、要件定義書→基本設計書→詳細設計書→実装→テスト仕様書という同じ情報の多重コピーが成立する。後半になるほどズレの影響が膨らみ、手戻りコストが爆発する。
※ この構造を、経済産業省自身が "ユーザー企業とベンダー企業の低位安定の共依存" と公式に名付けている（DXレポート2.1、2021年）。意思の問題ではなく、仕組みそのものの問題であることは国の認識でもある。
SIは「同じ業務情報」を、5フェーズで何度も作り直し続けている
業務とITが分離している以上、その間を翻訳する大量の中間成果物が必要になる。同じ情報がフェーズごとに別書式で再生成されるのがSIの本質的な非効率。
- ・業務フロー図
- ・機能一覧
- ・画面一覧
- ・要件定義書
- ・画面設計書
- ・API設計書
- ・テーブル定義書
- ・処理設計書
- ・画面コード
- ・API実装
- ・DB構築
- ・処理ロジック
- ・テスト仕様書
- ・テスト実行
- ・エビデンス作成
- ・障害管理
- ・運用手順書
- ・保守資料
- ・変更管理書
- ・障害対応書
同じ業務情報がフェーズごとに別書式に翻訳される。翻訳のたびにズレが入り、後半になるほど蓄積する。
テスト段階でズレが発覚すると、修正コストは要件段階の数十倍に膨れる。やり直しは全フェーズに波及する。
作るのも、レビューするのも、修正するのも、すべて人手。SIプロジェクトの工数の大半がこの「情報の繰り返し生成」に消える。
PortXのアプローチは「AIで速くコードを書こう」ではない。
この「同じ情報を別書式で何度も作り直す」構造そのものを、業務仕様書を唯一の正本(SSOT)に置くことで消す。差は「速さ」ではなく「決定論性 (determinism)」。Vibe coding (V0/Bolt/Lovable/Cursor) は確率的 = 動くこともある。Spec-Driven Development は決定論的 = 毎回正しく動く。本番稼働するエンタープライズSIは、後者でしか作れない。
この歪みの大きさは、国の公式数字でも見えている
前ページの分離構造を、別の角度から定量化したもの。全て公的機関の一次情報。
大企業を生んだのは、いつも「指数関数的な追い風」だった
マイクロコンピュータ→Intel・MS・Apple、インターネット→Google。大企業は意思決定の速さでは作れず、テクノロジーの指数関数的変化を追い風にする以外にない。今、ソフトウェア生産性そのものに、その変化が起きている。
どの時代の大企業も、新しいインフラが標準化する直前の数年に立ち上がっている。
要件整理・設計・実装・テスト・変更管理 — SIの「知的作業」の大半が、わずか2〜3年でAIに代替可能になった。人月で人が手作業していた工程の前提が、根本から崩れている。
このインフラが「当たり前」になる前に、仕組みを根本から作り変えたプレイヤーだけが、次の大企業になる。
なぜ「今」でないとダメか：5年後、LLMによる開発生産性向上は全SIerに当たり前のものとして普及する。その時、「人月」を前提に組まれた既存SIerの組織・契約・原価構造は、AI前提で組まれた新しいプレイヤーに置き換わる。置き換わる側に立てる窓は、今後数年しか開いていない。
Spec-Driven Development プラットフォーム。
業務仕様書を唯一の正本(SSOT)として、画面・DB・API・テスト・運用までを派生させ続ける「フルスクラッチのようなSaaS」。
新規構築も追加開発も運用保守も、すべて同じパイプラインの上で決定論的(deterministic)に動く。
プロンプト→生成→修正の繰り返し。デモまでは速い。ただしエッジケースで壊れ、変更が予期せぬバグを生み、本番で破綻する。
業務の仕様書を先に書き、AIがその仕様通りに成果物を生成・検証。毎回同じ振る舞いが保証される本番品質に到達できる唯一の道。
差は「速さ」ではなく「決定論性 (determinism)」。AIはソフトウェアを動かすものを変えていない。最も大事な工程 ＝ 仕様書を、書きやすくしただけ。
新規構築も、運用後の追加開発も、同じ1つの仕組みで動く
人が書き換えるのは業務の仕様書ただ1つ。そこから全ての成果物が生成・同期される。この仕組みは構築フェーズでも運用フェーズでも変わらない。
人が書き換えるのは
これだけ
日本語で指示
「検索条件を追加して」
「タブを4つに分けて」
成果物を人手で作り直す工程がゼロ。仕様変更から全成果物の更新までが即座に完了。
正本から自動生成するため「設計書と実装が違う」「テスト漏れ」が構造的に起きない。
設計書作成・レビュー・転記・テスト作成。従来の工数の大半をAIが自動で処理。
業務仕様書から本番システムまで、5段で自動製造する
Formulaは「コードを書くツール」ではなく、業務仕様書を入れたら本番システムが出てくる自動製造ライン。新規構築でも運用後の追加開発でも、同じ5段が動く。
FDEのヒアリング内容を、AIが業務フロー(誰が・何を・どの順で)に構造化する。
spec(view/entity/api)から、画面・データ処理・DB・テストを自動生成。
「検索条件に部署を追加」等の変更を、intent / changes / impacts のYAMLに変換。
Delta群を読み、画面・処理・DB・テストに同時反映。view/api/entityのカラム整合性を機械的に検証。
テスト自動実行、スクリーンショット取得、検証レポート出力。本番リリースの根拠が機械的に揃う。
人間が書き換えるのはここだけ。日本語の指示も可。
17以上のSkill (業務知識化された手順) が各段で動く。
プロトタイプではなく、運用・保守・変更に耐える本番品質。
構築フェーズも運用フェーズも、流れるのはこの5段だけ。同じ仕様書を変えて再度パイプラインを回せば、全成果物が整合性を保ったまま更新される。これが「フルスクラッチのようなSaaS」の中身。
人間は競争優位の設計に。AIは実装の自動製造に。
PortXはFormulaを売る会社ではない。FDEという組織能力と、Formulaという自動製造基盤が密結合した「事業モデル」そのものが差別化の本質。
顧客の現場に常駐し、業務を深く理解する人間エンジニア。Palantirが体系化したモデルをPortXが日本の製造業向けに進化させたもの。
spec.md を唯一の正本（SSOT）として、画面・データ・API・テスト・エビデンスまで全成果物を自動生成するAI製造基盤。
V0・Bolt・Lovableのような「誰でも画面を作れるツール」が作れるのは、仕様書のない vibe coding ＝ プロトタイプ止まり。本番稼働には ① 業務例外・判断ロジックの網羅 ② 変更時の影響範囲の追跡 ③ データ整合性・監査要件 ④ 運用フェーズの保守可能性 が必須で、これらは 業務仕様書を正本(SSOT)に置く構造 でしか担保できない。
PortXが投資しているのは、上流の業務知識を仕様書として固定し、そこから全成果物を派生・同期し続ける Formula Platform Layer(spec・Delta・Sync・Skill群)。次ページで詳述する。
投資先は GUI でも コード生成 でもなく、Formula Platform Layer。
V0・Cursorはコードを速く書くツール。Formulaは spec(業務仕様) → Delta(構造化変更) → Sync(整合性保証つき自動反映) という独自のパイプラインに投資している。
GUI / UI生成
V0、Bolt、Lovable等が投資している層。仕様書がないvibe codingではプロトタイプ止まりで本番稼働できない(整合性・例外処理・運用保守が不可)。PortXは投資対象としない。
コード補完 / 生成
Copilot、Cursor、Devin等が投資しているレイヤー。個人開発者や小規模案件には強いが、「動いた、でもなぜこう作ったか残らない」問題でエンタープライズ保守が成立しない。
Formula Platform Layer (spec × Delta × Sync)
業務の仕様書を正本に、変更をDelta化し、Syncで全成果物に一括反映するSI業務専用のAIオーケストレーション層。汎用LLMの上に、エンタープライズ業務特有の制約・整合性ルール・運用フェーズの継続性を実装している。
spec.md = 唯一の正本
workflow.md / view.md / entity.md / api.md の総称。人間が読み書きするのはここだけ。.svelte / .ts / .sql は全てここから派生するので、仕様書と実装が構造的に分離しない。
Delta = 変更の構造化
「検索条件に部署を追加して」等の変更要求をintent / changes / impacts の構造化YAMLに変換し蓄積。変更の意図と影響範囲が常に追跡可能。通常のgit diffにはできない知識資産化が可能に。
Sync = 一括反映と整合性保証
Delta群を読み、画面・データ処理・DB・テストに同時に反映。view.mdとapi.mdのカラム整合性を自動チェックし、ERRORなら修正。人間のレビューではなく機械可読なチェックリストで品質保証。
Formulaは ツールではなくサービス。だからモデルが強くなるほど強くなる。
If you sell the tool, you are in a race against the model. If you sell the work, every improvement in the model makes your service faster, cheaper, and harder to compete with.
Formulaは「画面を作るツール」ではなく、「業務システムを作り続ける仕事そのもの」を提供する。フロンティアモデルが強くなるほど、Formulaという仕事は速く・安く・複製困難になる。
フロンティアモデル本体
担い手: OpenAI / Anthropic / Google
汎用的な言語理解・コード生成。圧倒的な研究開発投資。PortXは戦わない。むしろ全面的に依存し、進化の果実を取り込む側に回る。
コード生成 / IDE統合
担い手: Cursor / Copilot / Devin / V0
汎用的なコーディング体験を磨く層。FMの能力向上で価値が薄まる側。FMが直接コードを書けるほど、エディタ統合の差は縮まる。
エンタープライズ業務ソフトウェア
担い手: PortX Formula
FMの能力を、エンタープライズの中核業務という特殊な制約条件に変換するソフトウェア層。FMが強くなるほど自動製造の精度が上がり、PortXの強みも増幅する。
FMプロバイダーは「水平展開」が事業構造。顧客現場に常駐するFDE組織は彼らの強みと真逆。
日本の製造業の業務制約・例外処理・情シス慣習等は、研究組織にとっては学習データになりにくい雑音。直接吸収する経済性が低い。
エンタープライズSIは継続性が命。研究資源を局所最適に張れないFMプロバイダーには、構造的に向かない事業領域。
→ PortXが Layer 3 に投資している限り、Layer 1 の進化は脅威ではなく追い風。Formulaの土台を早く作り始めて磨き続けたプレイヤーほど、後から参入したベンダーにも従来SIにも構造的に勝つ。
3つのプレイヤーマップと、PortXの位置づけ
AI時代に「業務システムを作る」プレイヤーは大きく3つに分類できる。PortXはどれとも正面衝突しない。
Vibe Coding
Cursor / Copilot / Devin / Claude Code
UI/GUI 生成ツール
V0 / Bolt / Lovable
従来型エンタープライズSI
富士通 / NEC / NTTデータ / 大手SIer
PortXは A・B・Cのどれとも正面衝突しない。投資しているのは エンタープライズ業務SIに特化したFormula Platform Layer (Spec-Driven Development基盤) と、顧客現場で業務を仕様書に変換するFDE組織。
この2つが密結合しているため、プラットフォームだけ模倣されても複製できない。大企業の中核業務を、毎回正しく動く本番品質で実装できる唯一の構造。
3階層の収益モデル
案件ごとに売り切るのではなく、プラットフォーム上で継続収益を積み上げる構造。
構築支援費用
最初に立ち上げる・追加で作る時の費用。要件整理・設計・実装・テスト・UAT支援まで。
課金：人月単価（標準工数ベース）
運用基盤費用
本番運用・保守の月額費用。認証・監視・バックアップ・問い合わせ対応・変更影響分析まで。
課金：月額固定（Standard / Pro / Enterpriseの3ティア）
高度運用支援
ハイパーケア・月次レビュー・優先対応など、追加の人手支援。
課金：月額オプション（必要な顧客のみ）
コスト構造の特徴：AIで効率化された分を値引きとして還元しない。効率化の果実は会社に蓄積し、プラットフォーム強化に再投資する。案件ごとに消費されるのではなく、プラットフォーム上でアプリが稼働し続ける構造。
同じ「SI市場」も、企業の売上規模ごとに競合構造が違う
Formulaの「入り方」は従来SIと違うので、規模帯ごとに勝ち筋・競合・取得可能シェアが変わる。PortXは規模帯を選んで攻める。
※ 業種は製造業+物流業に絞った社数。取得目標は新規開発+運用保守の合算ベース。主戦場B+Cで先行確立し、AとDに段階的に展開するのが基本シナリオ。
主戦場(B+C 約780社)だけで、年間SI支出は1.2〜1.5兆円
製造業+物流業 × 売上1,000億〜1兆円 × 中核業務 (ERP/SCM/生産/WMS/TMS/調達/品質) のSI支出を積み上げた数字。
取得目標 10–15% → PortXのTAM=400〜900億円
取得目標 10–15% → PortXのTAM=700億〜1,500億円
※ 中核業務SI支出/社・年は、JEITA/IDC/総務省のIT支出データから売上規模帯別に按分推計。新規開発+運用保守の合算ベース。詳細はAppendix参照。
主戦場B+Cで先行確立すると、A・D・隣接業種に広がる
Formulaという「サービス」は、土台を早く作り始めて磨くほど後から追えなくなる。B+Cで実績を積むことが、AとDへの最短ルート。
製造業・物流業の中核業務(SCM/生産/WMS/TMS等)に narrow wedge で深く入る。Formulaの土台を磨き、再利用可能な業務テンプレートとSkillを蓄積。
A帯：B+Cで蓄積したテンプレートを武器に、大手SIerの牙城に部門単位で食い込む。
D帯：Formulaで初めて経済性が成立する層。SaaS的提供で一気に取りに行く。
中核業務SIの構造課題は製造業以外にも共通する。業務テンプレート群が成熟すれば、業種をまたぐ展開コストが急減する。
Formula Platform Layerを業界共通基盤として開放。PortXは原盤ホルダーとして、業界全体のSI生産性を引き上げるレイヤーになる。
先行優位のロジック：Formulaは "ツール" ではなく "サービス" のため、土台を早く作り始めて磨いた者ほど強い。フロンティアモデルが進化するたびに 既存の業務テンプレート・Delta履歴・整合性ルールが自動的に強化される。後発がゼロから同じものを積むには、PortXが先に過ごした年数が必要になる。
Narrow Entry × Broad Vision
主戦場B+C(売上1,000億〜1兆円の製造業・物流業)に、ユーザー部門起点で深く入る。
製造業・物流業のユーザー部門
売上 1,000億〜1兆円 の中堅〜大手企業が中心。情シス経由ではなく、業務で本当に困っている現場部門に直接アプローチ。
在庫・納期・受注配車・生産調整・調達・品質など、企業固有性が高く、部門横断の中核業務に狙いを定める。
5つのコア戦略
勝ち筋の本質：狭く深く入ることで、大手SIerともパッケージSaaSとも正面衝突しない。部門単位の実績がFormulaの業務テンプレートとして蓄積され、横展開のたびにコストが下がる複利構造。
PortXとFormulaの進化
プラットフォームと組織能力を同時に積み上げていく。
主戦場B+Cで先行確立
- ・売上1,000億〜1兆円の製造業で実績
- ・Formulaパイプラインの完成・運用
- ・FDE組織の立ち上げ・スケール
- ・業務テンプレート資産の蓄積
A帯・D帯への上下展開
- ・売上1兆円超(A)に部門単位で食い込む
- ・売上500〜1,000億(D)にSaaS的提供
- ・物流・隣接業種への展開
- ・運用基盤ARRの積み上げ
エンタープライズ業務ソフトウェアの標準
- ・Formulaを他のSIerにもライセンス提供
- ・業界標準プラットフォーム化
- ・小売・金融・医療への業種拡大
- ・エンタープライズSIの構造を変える
核となる戦略：PortX自身がFormulaを使い倒してデリバリー能力を高め、その実績と知見を武器にプラットフォーム自体を進化させる。自社利用と外部提供の両輪で成長する。
| 会社名 | 株式会社PortX / PortX Inc. |
| 代表者 | 石田 寛成 |
| 資本金 | 1億円（累計調達金額7.2億円） |
| 設立 | 2019年12月6日 |
| 本社 | 東京都新宿区新宿2-5-12 FORECAST新宿AVENUE 6F |
| 事業 | エンタープライズ業務ソフトウェア「Formula Platform」の開発・運用 |
市場規模の算出仮説と前提
本資料の「PortX中核業務SI市場」の数字の根拠と算出過程。
PortX中核業務SI市場 = 売上500億円以上の製造業+物流業企業における、調達・購買・生産・販売・受注・物流・在庫・品質管理というバリューチェーン中核業務を支えるITシステムの新規構築・運用保守にかかる年間支出。
新規開発市場 ≒ 約4,000億円/年 の算出式
= 3.6兆円 × 35% × 45% × 70%
≒ 約3,970億円/年 → 約4,000億円/年（上限レンジ採用）
運用保守市場 ≒ 約1.0兆円/年 の算出式と仮説
= 4.14兆円 × 35% × 45% × 70%
≒ 約4,560億円/年（狭義: IDCマネージドサービス経由の推計）
「1兆円」の仮説：IDC統計の狭義マネージドサービスに加え、JUAS調査の「IT予算の8割が保守運用」という構造を踏まえ、社内IT人件費・SIer保守契約・パッケージ保守費などのマネージド外保守を含めると、狭義推計の約2〜2.5倍に膨らむ。PortXの運用基盤費用は「カスタム開発の保守＋クラウドマネージド」を両方置き換えるため、両者を合算した約1兆円/年が現実に置換可能な上限と仮説を立てた。この数字は「8:2の構造歪み」が解消される前提で成立する。
2030年予測の前提
・伸びしろシナリオ×2.5: 日本の製造業IT投資比率 1.0% → 国際水準3.3%への戻し（NRI/Gartner）
・PortXが勝ち筋として狙うのは、ベースラインではなく伸びしろ解消を主導するポジション
主要出典 — 全て公的機関・一次情報
本資料の数字・主張は以下の一次情報を根拠としている。
数字は2025-2026年調査時点の暫定値。最新版・詳細計算はお問い合わせください。