会計SaaSのStampliが、製品ローンチにかかる工数を68%削減した。武器はOpenAIのCodexと業務用ChatGPT「ChatGPT Work」。増員ゼロ、締切固定という制約下で、コード・コピー・デザインを横断してAIに任せた結果だ。単発ツール導入では出ない圧縮率が、なぜ出たのか。エンジニア視点で分解する。

何が起きたか

Stampliは請求書処理を自動化するAP（Accounts Payable）領域の会計SaaSベンダーだ。今回OpenAIが公開した事例によれば、同社は新製品ローンチ準備において、ランディングページ制作、告知素材の生成、コード修正といった一連の作業をChatGPT WorkとCodexで実行し、通常数週間かかる工程を数日に圧縮した。削減率は68%。

背景にあったのはリソース逼迫だ。デザイナーもエンジニアも他案件で手が空かない一方、ローンチ日は動かせない。従来なら外注か締切延長の二択だったところを、既存メンバーのままAI側にスループットを担わせて突破した。単発ツールの部分導入ではなく、コード・文章・デザインを横断的にAIに委譲した点が事例の核心である。

なぜこのニュースが重要か（chatgptは業務基盤として何が変わるか）

これまでChatGPTの業務活用は「ドラフト生成の補助」に留まる導入が多かった。文章の下書き、コードの断片提案、アイデア出し——いずれも人間のワークフローの隙間を埋める使い方だ。この使い方では、削減率はせいぜい10〜20%に収まる。個人の作業時間の一部が短縮されるだけで、プロジェクト全体のクリティカルパスは変わらないからだ。

Stampliの68%が意味するのは、AIがクリティカルパスそのものを引き受け始めたということだ。ローンチ工程では「エンジニアがコードを書く→デザイナーが素材を作る→マーケがコピーを書く」という直列の依存関係が生じ、ここが全体工期を規定する。ChatGPT Work＋Codexは、この直列工程を並列化ないし省略する。エンジニアの手が空くのを待たずにコード修正が進み、デザインの完成を待たずにコピーが確定する。

つまりChatGPTは補助ツールから「工程を再設計するための基盤」に格上げされた。SaaSベンダーが数週間を数日に変えられるなら、同じ会計SaaS競合はもはや「AIを使うか否か」ではなく「どれだけ深く業務に埋め込むか」で差がつく。導入の遅れは半月単位のリードタイム格差に直結する。

技術的な深掘り

68%という数字を分解してみる。仮に元の工程が20営業日とすれば、6.4日まで圧縮された計算だ。この圧縮率を出すには、単なるプロンプト投入では足りない。Codexが担うのは既存コードベースへの修正パッチ生成、ChatGPT Workが担うのはランディングページのコピー、告知素材のバリエーション生成、そしておそらく社内ドキュメントを参照した文脈保持だと推定される。

エンジニア視点で注目すべきは、ChatGPT Workが「業務コンテキストを持ったChatGPT」である点だ。通常のChatGPTは会話ごとに文脈がリセットされるが、Work版は社内のブランドガイド、既存プロダクト仕様、過去のローンチ資料などを参照できる。これによりコピーの一貫性が担保され、レビュー往復回数が激減する。レビュー往復こそがローンチ工程の隠れたボトルネックであり、ここを潰せば工期は非線形に縮む。

Codex側も同様だ。既存リポジトリの構造を理解した上で修正パッチを出せるなら、レビュー段階での差し戻しが減る。仕様書とコードベースを両方読める前提のAIは、単発のコード補完ツールとは別物だと考えるべきだ。GitHub CopilotやCursorとの差はここに出る。

経営者として次に取るべき動き

第一に、締切固定の案件を棚卸しせよ。ローンチ、決算開示、規制対応、展示会——動かせない締切がある業務ほど、AI投入のROIは跳ね上がる。人員追加が間に合わない領域を優先リスト化する。

第二に、単発ツール導入を止め、業務基盤として発注し直せ。ChatGPT WorkのようなEnterprise向けは1ユーザー月額数十ドル規模だが、部分導入では圧縮率が二桁前半で頭打ちになる。コード・文章・デザインを横断させて初めて68%が出る。稟議の粒度を「ツール」から「基盤」に変える必要がある。

第三に、レビュー工程のKPIを取れ。AI導入後に測るべきは生成速度ではなく、レビュー往復回数と手戻り率だ。ここが下がっていなければ、AIは補助止まりで基盤化していない。3ヶ月以内に往復半減が出ないなら、導入設計を見直すべきである。