ByteDanceのAI売上40億ドルは投資額の6分の1——収益化のために選んだのが「組織再編」だった意味

AI開発・生成AI活用公開日:2026年8月6日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 要点 (出典の事実のみ)
  2. 投資額の6分の1しか回収できていない、という読み方は雑だ
  3. 「グループウェアをチャットボットに統合する」という判断
  4. 開発会社の事業判断にどう効くか
  5. 誤読しやすい点

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

ByteDanceのAI事業の年間売上が約40億ドルに達した。中国企業が公表した数字としては最大で、DeepSeekやMoonshot、アリババの開示額を上回る。一方で同社が2026年のAIに投じる資本支出は1,600億元(約230億ドル)から2,000億元超へ引き上げられている。売上は投資額の6分の1程度にとどまる。そして同社が同じタイミングで発表したのは、新しいモデルではなく組織再編だった。ここに読むべきものがある。

要点 (出典の事実のみ)

  • ByteDance のAI関連の年間売上は約40億ドル。中国企業が公表した数字としては最大で、DeepSeek・Moonshot・アリババの開示額を上回る。ただし OpenAI や Anthropic とは依然として大きな差がある (2026年7月30日、Financial Times 報道)。
  • 同時に組織再編を実施。グループウェア Lark (飛書) の製品チームを Doubao (豆包) チャットボットの製品組織に統合し、営業・サポート人員はクラウド事業の Volcano Engine へ、エンジニアはAIアプリ部門 Flow へ移す。Feishu の GTM チームと Volcano Engine を統合した法人向けの新組織も立ち上げた。
  • 2026年の資本支出は当初計画の1,600億元(約230億ドル)から2,000億元超(約294億ドル)へ、少なくとも25%引き上げられたと報じられている。半分以上が半導体の調達に充てられる計画。
  • Doubao の月間アクティブユーザーは2026年3月時点で3億4,500万。アリババの Qwen (1億6,600万)、DeepSeek (1億2,700万) を上回り、中国国内で最大規模。
  • 同社は Nvidia への依存を下げるため、TSMC と共同設計した自社AIチップ2種類の量産を2026年に目指しているとされる。

投資額の6分の1しか回収できていない、という読み方は雑だ

40億ドルという数字は、単体で見れば大きい。だが2026年に投じる2,000億元超と並べると、比率としては6分の1程度になる。この対比だけを取り出して「回収できていない」と評するのは簡単だが、私はそこで止めるのは雑だと思う。

先日マイクロソフトの決算について書いたときにも触れたが、市場がAI投資を評価する軸は投資額の絶対値ではなく、増額を止めた状態で成果が伸びるかどうかにある(マイクロソフトのAI投資だけが好感された理由)。ByteDance は逆に増額している最中で、まだその評価軸に乗る段階にない。今の数字は途中経過であって結論ではない。

読むべきなのは金額ではなく、その投資をどう回収しようとしているかのほうだ。そしてその答えが、今回は組織再編という形で出ている。

「グループウェアをチャットボットに統合する」という判断

再編の中身が示唆的だ。Lark という業務で毎日使われるツールの製品チームを、Doubao というチャットボットの組織に入れた。営業は MaaS を売るクラウド部門に移した。

これは「チャットボットに業務機能を足す」のではなく、「業務の入口をAIの側に寄せる」判断だと私は読む。以前 Oracle が Gemini を ERP・HCM に統合したときにも同じことを書いた——AIの主導権は『モデル』から『業務の入口』へ移っている。モデルの性能で差がつかなくなるほど、誰が業務データと日常の操作画面を握っているかが効いてくる。ByteDance は自社の中で最もその条件を満たすアセット (グループウェア) を、AI製品の側に寄せた。

チャットボットのMAUが3億4,500万あっても、それ自体は業務の意思決定に接続していない。だが Lark の中で動くAIは、稟議も日報も商談履歴も見ている。課金できるのは後者だ。

開発会社の事業判断にどう効くか

三つ挙げる。

一つ目。AI機能を別チームで持つと、売上に繋がらない。 ByteDance が製品チームを物理的に統合したのは、組織を分けたまま連携させても遅いと判断したからだろう。私たちの規模でも同じことが起きる。「AI推進チーム」を作って既存の受託案件と別立てで動かすと、PoCは増えるが受注は増えない。AIを扱うチームは、業務システムを作っているチームと同じ場所にいるべきだ。顧客の業務データに触れているのは後者なので。

二つ目。提案の主語を「モデル」から「入口」に変える。 発注側が最終的に金を払うのは、モデルの賢さではなく、業務が回ることに対してだ。すでに顧客が毎日開いている画面 (基幹システム、グループウェア、業務アプリ) にAIを寄せる提案は通りやすく、独立した「AIツール」の提案は通りにくい。ByteDance ほどの資本を持つ会社ですら、後者ではなく前者を選んでいる。

三つ目。半導体の調達比率を見る癖をつける。 資本支出の半分以上がチップという構成は、モデルを自前で持つ側のコスト構造だ。私たちのようにモデルを作らない側は、その構造を持たないことが強みになる。推論コストは他社の投資に相乗りできる。自社でモデルを持つべきかという相談を受けることがあるが、この比率を見れば、ほとんどの中堅企業にとって答えは明らかだと考えている。

誤読しやすい点

「中国企業のAI投資は規模が違うので参考にならない」という読み方は、半分正しくて半分間違っている。金額は確かに桁が違う。だが収益化のボトルネックが『モデルの性能』ではなく『業務の入口をどう押さえるか』に移っているという構造は、規模に関係なく共通している。むしろ資本を持つ会社が総当たりで試した結果として先に露出しているだけで、同じ壁に後から当たるのは私たちのほうだ。

なお、AI導入が土台のある業務基盤を必要とする話はAIはERPと業務基盤なしには機能しない、受注機会が組織再設計の側に移っている件は日経225企業の87%がAIエージェントを活用、中国のAI産業が実装フェーズに入っている状況は中国AI産業は「実装フェーズ」へ、ByteDance のモデル・チップ戦略そのものはByteDance Seed 2.1 Proで扱っている。

出典: ByteDance's big bet on AI (Financial Times, 2026年7月30日)

※本記事は上記 FT 記事 (購読者限定) を起点に、同日の報道 (The Next WebTechNode) および資本支出・利用者数に関する報道 (South China Morning PostEqualOcean) で事実を確認して構成している。

Share

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

徐 聖博のプロフィール写真

この記事の書き手に直接相談する

徐 聖博株式会社シンシア 代表取締役社長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、徐 聖博を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

**約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。** 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、**先に入ったメンバーが構造を残していたから**でした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 > 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 ### この事例からの示唆 **稼働中のサービスでも基盤は入れ替えられる。** 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 **メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。** 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについては[システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns)でも整理しています。 **要件が固まりきらない領域ほど、データ設計で制約を表現する。** 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては[要件定義の進め方](https://blog.xincere.jp/articles/requirements-definition-process)を参照してください。 ### よくある質問 **Q. 稼働中のサービスを止めずに基盤刷新はできますか。** A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 **Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。** A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 **Q. どのくらいの規模・期間の支援ですか。** A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。 ### 関連する支援領域 - [システム刷新の進め方|検討・計画から移行までの方法](https://blog.xincere.jp/articles/core-system-renewal-guide) — 稼働中システムを止めずに刷新する判断基準 - [業務システム開発の要件定義とは?進め方・手順を7ステップで解説](https://blog.xincere.jp/articles/business-system-development-requirements-definition-steps) — 要件を仕様に落とす工程 - [システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns) — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する