Proaction、Codex で売上60%増・月75時間超を削減

2026年9月25日、OpenAI は車両管理ソフトウェアを手がけるスタートアップ、Proaction の導入事例を公開しました。見出しの数字は明快です。Codex の活用により、エンジニアリング工数を月に40〜60時間、創業者の作業時間を月に約33時間削減し、売上は60%増加したとされています。Proaction は北米の企業で、乗用車やトラック、建設機械まで、車両群を管理する企業向けにソフトウェアを提供しています。利用しているのは Codex と API で、製品内では GPT-Live-1、GPT-6 Astra、ChatGPT-5.6 Sol といったモデルが使われています。

まず課題を整理します。車両管理の現場は、顧客ごとに車両の構成も業務の流れも異なります。そのため、見込み客に自社のプラットフォームが合うことを示す工程が、営業の要になります。ところが、個別のデモにはエンジニアの時間が必要で、小さなスタートアップにその余裕はありません。以前は創業者が会話とスライドで、できることを説明するしかありませんでした。共同創業者兼 COO の Colin Knudsen 氏は技術者ではなく、デモが欲しいたびにエンジニアを巻き込む必要がありました。 Codex はこの流れを変えました。商談の後、Colin 氏は Codex に Granola の録音、見込み客とのメールのやり取り、共有されたスプレッドシートを読ませます。Codex はその文脈をもとに、HTML のデモ環境をカスタマイズします。画面は Proaction の実際の製品を模しつつ、中身は顧客自身の車両群です。画面共有をすると、顧客は自社の乗用車、トラック、機材が自分たちの働き方に沿って並んでいるのを目にします。調整したい箇所を指さし、一緒に解決策を作り上げることもできます。Colin 氏によれば、エンジニアを一切介さずに、顧客と共同で最終的な解決策を作れるといいます。

数字を見ましょう。Colin 氏は月に4〜6件の、顧客に合わせたインタラクティブなデモを作成します。1件あたり30〜45分です。同等のデモをエンジニアが作ると約10時間かかる見込みで、月に40〜60時間のエンジニアリング工数を節約できる計算です。受注の流れでは、初回接触から、育成(ナーチャー)ではなくソリューション開発に進む案件の割合が、カスタムデモによって50〜60%増えたと推定しています。ただし注意が必要です。これらは Colin 氏本人の見積もりであり、対照実験の結果ではありません。現場責任者の経験的な判断として読み、厳密なベンチマークとは区別すべきです。 デモの価値は営業の段階で終わりません。見込み客が顧客になると、Colin 氏はカスタマイズ済みのデモをエンジニアに渡し、視覚的な参考資料として使ってもらいます。何を作るのかをめぐる質問ややり取りが減ります。Proaction は Codex を使い、顧客向けのソリューションセンターも構築しました。見込み客はログインして、自社向けに整えられたワークフローを調べ、営業資料を確認できます。顧客は必要なことを説明しやすくなり、非エンジニアの同僚もその会話を明確な要件に変えやすくなります。エンジニアが関わる頃には、作るべきものの具体像が手元にあります。 二つ目の話題は、日々の作業台としての Codex です。Colin 氏の仕事は営業、カスタマーサポート、プロダクトマネジメントにまたがります。Granola、Gmail、Slack、Linear、GitHub、HubSpot などの Codex プラグインを通じて、顧客の文脈を一か所に集め、そのまま行動に移します。通話の文字起こしやメール履歴を引き出してフォローアップを準備し、Linear の課題を作成し、HubSpot の商談を更新します。直近の通話を見直し、チーム向けの営業アップデートを用意する定期的な自動化も設定しました。以前は多くのタブを行き来し、ツール間で情報をコピーしていました。いまは必要なことを伝えるだけで、Codex が文脈を集め、次の手順を実行します。1日に15〜20種類の作業があり、Codex によって月に25〜33時間を節約できると見ています。

三つ目は製品の内側です。Proaction はプラットフォーム全体で OpenAI のモデルを使っています。顧客が車両の問題報告に写真を添えて送ると、ChatGPT-5.6 Sol が損傷の特定を助けます。さらに GPT-Live-1 を使い、車両運用の日常業務をより多く担うエージェントを構築しています。同社はこれを「Managed Execution Layer(マネージド実行レイヤー)」と呼びます。Colin 氏は、顧客が仕事を管理し追跡するのを助けるだけでなく、Proaction が顧客のために仕事を実行できるようにしたいと述べ、OpenAI の音声技術の進歩がそれを可能にする大きな理由だとしています。顧客は専門のエージェントに通行料や整備などを任せたり、適切なエージェントが自動的に動くワークフローを設定したりできます。エージェントは GPT-Live-1 や GPT-6 Astra を含む OpenAI のモデルで、音声通話をかけ、文書や画像を確認します。入手できた原文はこの後で途切れているため、これ以上の詳細は扱いません。

仕組みの面では、「文脈がインターフェースになる」点が重要です。Codex は何もない状態からデモを作るわけではありません。録音、メール、スプレッドシートという実際の材料を指定され、インタラクティブな HTML を出力します。HTML のデモは軽く、バックエンドの配備が要らず、画面共有中にその場で直しやすい形式です。要件の聞き取りと試作が一度の会話に統合され、顧客の言葉から目に見える製品までの距離が縮まります。 企業と開発者への示唆は三つあります。第一に、コーディングエージェントの利用者がエンジニア以外へ広がっています。非技術系の創業者が自分で試作を作れば、限られたエンジニアの時間を本来の製品開発に回せます。第二に、価値は単発の生成ではなくワークフローの統合から生まれます。プラグインが CRM、課題管理、メール、コードリポジトリをつなぎ、節約されるのは切り替えのコストです。第三に、音声エージェントはソフトウェアを「記録のシステム」から「実行のシステム」へ近づけます。車両管理、物流、整備など、電話でのやり取りが多い業界で特に意味があります。

一方で、冷静な見方も必要です。成果の多くは、初期段階の1社と1人のヘビーユーザーによる自己推定です。エージェントが顧客に代わって電話をかけたり、通行料や整備を処理したりするなら、責任の所在、誤りの訂正、コンプライアンス、監査の問題が生じます。原文はこれらの扱いを説明していません。顧客データからデモを作る場合も、データへのアクセス権とプライバシーの線引きが明確でなければなりません。同じ手法を採る企業は、まずこれらに答える必要があります。 今後、同様のパターンは他の業界にも広がるでしょう。営業担当はコーディングエージェントで個別の試作を作り、運用担当は繰り返しの連絡業務を音声エージェントに任せるはずです。OpenAI にとって、この事例は製品群が連携して働く姿を示しています。Codex が作業台となり、API と音声モデルが製品に組み込まれる部品となる構図です。Proaction にとっての本当の試練は、マネージド実行レイヤーが現実の顧客の複雑な状況で、安定して監査可能に動くかどうかです。もしそれが実現すれば、このカテゴリのソフトウェアの競争軸は、機能の数から、実際に完了した仕事の量へと移っていくでしょう。