STR Network の AI 導入 —— 技術からマネジメントへ

「AI は技術の問題ではなく、マネジメントの問題です」——Sunnyは 『商業週刊』第 1963 期 のインタビューで、こう語っています。

コンサル会議のスローガンのようにも聞こえますが、STR Network（薩泰爾娛樂）の文脈では、これは工程の順序を示した記述です——多くの会社が ChatGPT、Cursor、n8n のどれが優れているかを比較している段階で、この共同創業者はすでに問いを反転させています。社内で何を統治するのかを先に定義する。そこからやっと、ツールに意味が生まれる、と。

本稿は、STR Network が Zeabur 上で運用している複数の社内システムの棚卸しです。ただし話の順序——そして STR Network の工程ペースが、一般的な「スタートアップは速い」というイメージとは違って見える理由——は、彼らが自分たち自身をどう組織しているか、という話から始める必要があります。

At a glance

一、STR Network はどう AI など新しいツールを社内に根づかせるか

STR Network は、台湾で風刺コメディから始まったコンテンツ制作会社です。代表番組には『博恩夜夜秀』などがあります。会社のコア DNA はコンテンツ——企画、脚本、制作、タレントマネジメント——にあり、技術部門は厳密に言えば一人だけ、エンジニアのFengです。

Zeabur の側から STR Network チームの導入と運用を見ていると、彼らは同規模のコンテンツ会社よりも明らかに速いペースで社内システムを立ち上げ、ツールを使いこなしています。技術リソースが豊富だからではありません。社内の役割分担がはっきりしているからです。

共同創業者 Sunny がブリーフを担います。会社が何を統治すべきか、誰が何を見られるか、権限をどう切るか、新しいツールが入ってきたときにどのフレームで受け止めるか——この層の判断が一枚のブリーフに落とされ、実行者へ引き渡されます。

Sunny が引き渡したブリーフを受け取った Feng は、それを動くシステムへと落とし込みます。プロセス棚卸しと工程実装はリレー競技ではなく、同じテーブルを囲んで交わされる対話です——Sunny が書いた要件文書に対し、Fengは実装段階で「このフィールドは本当にこの権限階層が必要ですか」と問い返し、weekly brief で Sunny とすり合わせます。

「Sunny の意思決定 + Fengの実装」というこの構造こそが、新しいツールや新しいシステムが会社に入る前に必ずフィルターを 1 枚通させます——一人のエンジニアにガバナンス、設計、施工の三役を同時に背負わせない。これがいわゆる「ガバナンス構造」であり、STR Network ではすでに何年も実践されています。AI 時代に多くの中堅企業がツールに飲み込まれてしまう本当の原因は、まさにこの構造の欠如にあります。

具体的な場面を 1 つ。各公演ごとに、規模に応じて 20 枚から 200 枚の招待券を確保する必要があります——役員会の VIP に、メディアに、業務提携先に、エージェント関係に、すべての重要関係者とその助手に。年間で締結する契約、追跡する勤労報告書、突き合わせるチケット販売実績——どれも 1 枚の Google Sheet では支えきれない量まで膨らんでいます。

プロセスを整え、システムを構築する必要があることは誰もが知っています。AI 普及前の時代から、STR Network はすでにこの問題に体系的に取り組んでいました。技術部門のない会社にとって、次に来る問いは絶対に「どの AI ツールを使うか」ではなく「私たちは結局、何を管理したいのか」だったのです——ChatGPT がリリースされた 2022 年、さらにはそれ以前の GPT-3 の時代から、STR Network はこの問いをずっと考え続けていました。

二、STR Network における「マネジメント負債」の 3 層

「マネジメント負債（管理債）」という言葉を、Sunny は 『商業週刊』第 1963 期 のインタビューで使っており、本稿の冒頭で引用したものです。Zeabur との対談では、この言葉を彼女はさらに具体的に分解しています——3 つの層に。

第 1 層：マネジメントの定義は、システム設計に先立つ。

「マネジメントの定義が先に出てきた後で、いわゆるシステム設計や概念が、ようやく育つことができるんです」

彼女が挙げる具体例が「元帳（帳本／ledger）」という社内概念です——1 つの公演プロジェクトに 2 冊、3 冊と元帳が存在し得て、それぞれの元帳で権限が異なり、最後にはどれも同じプロジェクトに収束する。システムでこれを実現できるかは工程上の問題ですが、それを実現したい前提として、会社の経営層が先に「給与は個人情報であり、公開できない」「撮影現場の弁当はどのアシスタントでも経費精算してよい」といったルールを定義し終えている必要があります。工程の用語で言えば、データの権限を定義し終えている、ということです。

第 1 歩が無ければ、第 2 歩にも着手できない。

第 2 層：小さな修正にもすべてコミュニケーション・コストがかかる。

「タグを 1 つ増やす、ステータスを 1 つ増やす、ユーザーロールを 1 つ増やす、使用する何かを 1 つ増やす——そのコストは高い、コミュニケーション・コストが高いんです」

スプレッドシートで列を 1 つ追加するのは無料ですが、システムに移したあと、フィールド 1 つの変更が引き起こすのは工程人員、権限設計、その後の保守、関連するロールのトレーニングです。この連鎖を開いて計算する——時間コストも、人的リソースも——のは、STR Network が「やるかやらないか」を決める前に必ず終えておくべき作業です。先にエンジニアに手を動かさせてから、コミュニケーションの残骸を拾う、というやり方ではありません。

第 3 層：人が去るとシステムを引き継ぐ人がいなくなる。

システム（後述する Jerry が立ち上げたゲスト招待プロジェクト INVITI のことです）を Google Sheet から自作の業務サイトへ移行することについて、Sunny は保守的な姿勢を保っています。彼女は率直に語り、ついでにブラックジョークを 1 つ差し挟みます（コメディ会社の社員はみんな冗談を言うのか？）：

「私がある日交通事故で死んでもまあ大丈夫なんですけど、Fengがいなくなったら、この全部のもの（他のメンバー）には分からない、誰も引き継いで保守できる人がいないんです。実はこの問題は今もまだ解決していません」

プロセスをシステム化することは、同時に新しい依存も生み出す——そして、その依存はただ一人のエンジニアに集中している。「マネジメント負債」のこの層が意味するのは：「システム全体を一人しか理解していない」という依存を解消する前に、新しいシステムを 1 つ作るたび、借金がさらに積み重なっていく、ということです。

この 3 つを足し合わせたものが、STR Network における「マネジメント負債」の実際の意味です——どのツールを使うかという問題ではなく、組織の内部で何を管理するか、誰が何を管理するか、誰が何を見られるか、を広げて、定義して、追跡し切ったうえで、それをシステムに落とすかどうかを決める。何でも非常に簡単に書けてしまう、まさにこういう時代だからこそ。

三、「技術的負債」は Sunny の vibe coding に対する直接的な懸念

STR Network は AI ツールに対してまったく抵抗していません——むしろ、すでに自動化を一巡走らせ、Gemini Embedding を RAG に接続し、Sunny 本人も Claude Code で Skill フレームを書いています。彼女が懸念しているのは別のことです —— 新しい AI マネジメントの問題 という問題。インタビューの終盤、彼女はかなりはっきりとこう語っています：

「STR Network は大丈夫です、運営も事業モデルも安定していますから。でも、立ち上がったばかりの会社の多くは、最近の AI 焦りの中で、みんなスプリント・モードになって、本来のプロダクトやサービスの上に、いろいろなものを乗せて作ろうとします。私が一番つらいと感じるのは、みんなが似たようなものを 100 個も作ってしまうかもしれない、でもそれらは互いに基本的に重複作業だ、という現象です。vibe coding をひたすら押し進めることは、実はもっと大きな効率問題を引き起こします——もっと多くの技術的負債、そしてそれに伴う運用負債を」

「ChatGPT や Cursor に、ただ単に『システムが 1 セット必要だ』と告げるだけでは、本当にひどいものしか返ってきません」——Fengも『遠見雜誌』のインタビューで、こう語っています。

技術的負債と運用負債、これがインタビューで彼女が直接名指しした 2 つのリスクです。インタビューの翌日（4 月 2 日）、彼女は Facebook に〈How to Read the Vibes〉という記事を公開し、この懸念をより完結した形で書き残しています：

「私がずっと気にしているのは、個人がどれだけ強くて凄いかを強調することではなく、もう二度とやらなくてよくなるのは何か、ということに強い好奇心を抱いていることです。同時に、私の最も深い恐れは、大量に建設したあと、それがさらに多くの違法建築のような技術的負債とマネジメント負債に変わってしまうことです。みんなが修繕に疲れる一方で、建設だけが手軽になってしまえば、私たちは『どうすればもっと長く保つフレームを設計できるか』への信念を失ってしまうでしょう」

「違法建築」——これが、コントロールを失った vibe coding の結果に対する、彼女の具体的な形容です。一文のあとに、彼女はもう 1 つ転換を加えています：

「でも誤解しないでください、私は建設を拒否しているわけではありません。むしろ何の心配もなく建設するためにこそ、マネジメントのフレームが必要なんです」

彼女の応答は、「Dev Diagnosis Skill」というスキルを 1 セット書き下ろすことでした。すでに Claude Code Skill の形で GitHub に公開されています。README の冒頭は「動き出す前に、価値を見極めよ」、そのすぐあとに鋭い 1 文——「高効率でゴミを生産しても、ゴミはゴミ」。

このスキルは、入ってくる要件の処理を 4 段階に分解します——診断 → 解法選択 → レベル管理 → 着地。Sunny は Facebook の投稿で、このスキルの進化過程を説明しています：

「昨年 STR Network で作った課題レベリングのフロー図は、もともと『影響範囲 × 継続性 × 複雑度』のクロスで 3 つのレベルを出して、私たちがどう監督するかを判断するためのものでした。でも『影響範囲 × 継続性 × 複雑度』そのものが、抽象的すぎたんです。私はずっと『診断』の技術について考えていました——患者が描写できるのは感覚で、医師の知恵は、症状からどう病名へ繋ぎ、そこから解決方法へ繋ぐかにある」

言い換えれば、彼女はマネジメントのフレーム自体を書き直しています——ユーザーに「影響範囲 × 継続性 × 複雑度」というボキャブラリーを覚えてもらうのではなく、症状そのものを描写してもらい、スキル側で症状から採るべき開発モードへとマッピングする。

スキルはツールではなく、会社のガバナンスを markdown に書き起こしたものです。Sunny 自身の総括が次の一文：「私が気にしているのは、チームの中の基礎的な判断にコンセンサスが取れるかどうか、です。一貫した同期率が高まって初めて、個々人の経験から生まれる多様な観点を増幅させていける」。

何の心配もなく建設するという言葉に応えるなら、より多くの技術的負債、それに伴う運用負債——そしてさらに重要なのは、源流からアーキテクチャを持ち、意識的に「新しいシステムを建てる必要があるか」を検証することです。

四、Zeabur 上で動いているいくつかのシステム

以下は、STR Network が Zeabur 上で運用しているプロダクトとシステムです。一部は Zeabur の 共有クラスター（2026-02-23 以降は新規受付を停止）で動き、一部は BYOS を介して、彼ら自身の GCP インスタンスに接続されています。

1. ゲスト招待管理システム INVITI

INVITI はコードを書くところから始まったのではなく、招待券の処理に頭を抱えていた CEO 補佐 Jerry（小傑）の 1 ヶ月にわたるプロセス棚卸しから始まりました。

冒頭で述べたとおり、STR Network は各公演ごとに規模に応じて 20 枚から 200 枚の招待券を、役員会 VIP、メディア名簿、業務提携先、エージェント担当のメディア名簿へと割り当てる必要があります。チケット 1 枚の背後には 1 人の関係者がいて、各関係者にはさらに助手がいる——情報量は、単一の Google Sheet が支えられる規模をすぐに突破します。

Sunny とFengはインタビューの中で、Jerry の作業について次のように共有してくれました：「最初におよそ 1 ヶ月かけて、彼自身が歩んだゲスト招待プロセス全体を棚卸ししたんです」。それは、ゲスト招待の完全なフローを「ロール対応表」という 1 枚のドキュメントに描き出すことでした——誰が誰を招待し、どのロールがどのフィールドを見られるか、チケット種別をどう分類するか、各段階で何をすべきか。このドキュメントはシステムアーキテクチャ図ではなく、現実生活の中で起きているフローそのものです。

そのうえで、Fengが 1 ヶ月半をかけて、データベースとフロントエンドを組み上げました。このシステムにおける Zeabur の役割——内製化の後押しとして——について、彼の表現はかなり率直です：

「Zeabur がこの部分で一番役立つのは、Postgres のワンクリックデプロイです。それ以前は、BigQuery や Google 上のデータデプロイ以外には、ほとんどデータデプロイの選択肢を持っていませんでした。Zeabur 上でワンクリックで立ち上がる Postgres のおかげで、ローカルテストが非常に便利になりました。クラウドに上げずにテストできるとき、コストが大幅に下がる——これは僕にとって大きいです」

2. 営業オペレーションシステム —— 会社のすべての数字とプロセスを集める社内ミッドオフィス

「全体は Zeabur 上にデプロイされています」——Fengはインタビューの中で 4 回、この言葉を繰り返しました。彼が指しているのは社内のミッドオフィス——STR Network の営業オペレーションシステムで、経費精算、勤労報告書、チケット販売実績のレポーティング、プロジェクトリストを管理しています。「会社の中の数字はどれも集めていて、全部このサイトに集中させています」。

技術アーキテクチャは、実のところウェブアプリケーション 1 セットそのものです：Django + Celery のアプリケーション層、PostgreSQL のデータ層、Redis で Worker とバックグラウンドジョブを動かし、django-celery-beat が定期タスクを処理し、Nginx がリバースプロキシとして立っています。Fengは自身について、「あえてマイクロサービスの方向で実装したわけではないのですが、振り返ってみると、すでに雛形はできていました」と語ります——サービスが分散し、それぞれが独立して動き、互いに隔離されている。もちろん、データベース独立・デプロイ独立という厳密な意味でのマイクロサービスには、まだ距離があります（Zeabur のバックエンドエンジニア Pan が SITCON 2025 で マイクロサービスの定義と実装 について発表しています）。STR Network は引き続きシステムをイテレーションしており、次の段階では漸進的にサービスを切り離していく予定です——依存リスクを下げることに加え、開発効率もさらに改善できるからです：

「理想的には、このサービスはこのインスタンスにデプロイして、もう一つのサービスは別のインスタンスにデプロイしたい、という形ですね」

しかし、営業オペレーションシステムで本当に難しいのは技術構成ではなく、権限です。

Sunny によれば、大規模なイベントを支えるチーム編成の本質は外部委託による協働で、イベント現場の大部分は正社員ではありません。誰がどの元帳を、どのプロジェクトを、どの給与データを見られるかを、厳密に切り分ける必要があります。システムは RBAC で処理していますが、Sunny は先のインタビューでその前提を明確に指摘していました：「マネジメントの定義が先に出てきた後で、いわゆるシステム設計や概念が、ようやく育つことができるんです」。

STR Network がプロジェクト管理上で設計した「元帳」の概念——1 つのプロジェクトに 2 冊、3 冊の元帳が存在し得て、それぞれの権限が異なり、最後にはどれも同じプロジェクトに収束する——これは本質的に、情報セキュリティ領域でいう「最小権限の原則（Principle of Least Privilege, PoLP）」そのものです。各ロールは、業務を完了するために必要な元帳だけが見える、それ以上は与えない。

この仕組みを設計した目的は、外部委託のスタッフでもスムーズにシステムへ入り、正社員の準備を支援できるようにすることでした：「これは私たちの社内ツールですが、社内の人だけが使えるものではいけません。社内の人だけが使うとなれば、ボトルネックに行き当たります——結局、社内チームの生産能力に縛られてしまう」と、Sunny は補足します。

これは対外側のロジックですが、同じマネジメントの論理を社内に引き戻すと、1 冊の元帳について、社内のすべてのメンバーが本当に閲覧する必要があるのか？答えはあきらかです。ただし、より責任ある社内の権限と役割の帰属に関わってくると、それをどう着地させるかは、さらに高次の挑戦になります。

対外から対内への権限、ユーザー側から基盤アーキテクチャまでの隔離——この 2 つが織り合わされたものが、企業が AI を導入したあとに次に直面するマネジメントの問題です。そして STR Network は、導入のもっとも入口にあたる部分はすでに解いており、いまはシステム自体のアップデートを通じて、逆方向からマネジメントのフレームの改訂を進めています。

3. 総務 Slack Bot RAG

このシステムは、インタビュー前日にデプロイされたばかりのものです。

STR Network の社内には「#help-総務」という Slack チャンネルがあり、メンバーがそこで質問をします：Wi-Fi のパスワード、会社アカウントのパスワード、会議室予約、STR Network までのバスは何番か。もともとは Apps Script で書いたキーワードマッチの bot で、バックエンドのデータベースは Google Sheet でした——フィールドが噛み合わなければ答えられず、同じ質問が 2、3 回繰り返し回答をトリガーすることさえありました。

Fengは、これ全体を Zeabur 上に作り直しました：Gemini Embedding 2 API（2026 年 3 月 10 日リリース）でセマンティック・ベクトルを生成、PG Vector テンプレート（Zeabur でワンクリック起動）にベクトルを格納、Python FastAPI をバックエンドに据える、という構成です。リリース時期について、彼の説明は STR Network の工程ペースを反映しています：

「モデルとは特に関係ないんです。たまたま 3 月 10 日に Gemini Embedding 2 API がリリースされて、それが ToDo リストに残っていた、というだけです。元々動いてはいたものの、キーワードでトリガーしていて、LLM の成分はそこに無かった、というだけで」

モデルがリリースされたから即対応した、ではなく、この要件はずっと ToDo リストに残っていて、新しいツールが入ったことで優先順位が上がってきた、ということです。Zeabur の役割について、Fengはこう形容します：「Zeabur との関係は、要するに、デプロイが簡単になる、ということです。元々は Apps Script で動かしていて、LINE のバックエンドのような感じでした。今は FastAPI で包んで、Zeabur 上で動かす、という形になっています」。

RAG には自己反復のメカニズムもあります：システムが答えを見つけられなかったとき、なぜ見つけられなかったかを逆引きし、セマンティックな判定をかけ、ケースをデータベースに補充していく。Fengは、これがしばらく動いて初めて「だんだん賢くなる」と強調します。

五、これらのシステムが、Zeabur 上でどう動いているのか

上記のシステムの要件を積み重ねていくと、STR Network にとっての Zeabur の役割が明確になってきます——それは運用チームを置き換えるものではなく、「システムをデプロイして本番に流し、安定的に動かし続ける」という作業そのものを、捉え直すことです。チームに既にいるメンバーが、Zeabur Agent の補助を組み合わせることで、本来は運用チーム 1 つを丸ごと抱えなければ担えなかった仕事を、一人で担えるようにする。

STR Network の技術チームは、Fengただ一人——それでも彼一人で、本番に上がっているシステムを複数管理できています。それぞれがどのインスタンス上で動いているかを細かく追う必要も、「システムを本番に上げる」「システムを安定運用し、深夜に事故が出ないようにする」「データベースのバックアップと性能を保つ」、その一つひとつに専任の担当者を立てる必要もありません。代わりに、Zeabur の 3 つの機能を通じて運用を行っています：

• テンプレートのワンクリックデプロイ： INVITI の出発点は Postgres、総務 RAG Bot の出発点は PG Vector、業務サイトは Postgres と Redis に支えられています。Fengはこれを、「ローカルテスト vs クラウドテスト」のコスト差を引き下げてくれるもの、と形容します——一人でフルスタックを背負うエンジニアにとって、これは新しいアイデアの反復とテストの速度を、直接決定づける要素です。
• ハイブリッドクラウド管理： コアな本番の一部は自前の GCP サーバーで動き、デプロイ・モニタリング・ログはすべて Zeabur のインターフェースを経由します。一方で、一部のリソースは Zeabur 経由で購入した別のリソースの上にデプロイされています。サーバーリソースはハイブリッドで（STR Network はオンプレの Mac マシンも持っていて、それを Zeabur に紐付けて管理することも検討中です）、運用のインターフェースは同じ 1 つで足りる、という状態を実現しています。
• 統一された抽象レイヤー： 営業オペレーションシステムだけでも 6 つのサービス（Django、Celery、Redis、Postgres、Nginx、django-celery-beat）があります。これに INVITI や総務 RAG Bot など GCP 上で動くコアシステムが加わる——それらすべてを同じ Zeabur インターフェースで一覧し、サービスのヘルスステータスを可視化して、統一的に管理しています。

もちろん、もともと技術基盤を専任で見るメンバーを抱えているチームに対しては、Zeabur は同じメンバーが運用をより速く、より省力で進めるための土台を提供します。そうして節約された手元の余力を、より領域専門性を要する判断——プロダクトアーキテクチャの反復、情報セキュリティ・コンプライアンスの担保、システムを将来どう拡張していくかの計画——に振り戻してもらう、という設計です。

六、「AI 導入は技術の問題ではない」に立ち戻る

「AI の導入は技術の問題ではなく、マネジメントの問題だ」——この一文の意味は、AI が重要ではない、ということではありません。

その意味は次のとおりです：AI の前に、リソースとプロセスの完全な棚卸し（さらに言えば、長年にわたって蓄積された社内データソース）が必要であり、Sunny が繰り返し見直してはじめてシステムへ書き込まれる判断フローが必要であり、小さな修正の一つひとつに対するコミュニケーション・コストの精算が必要だ、ということ。STR Network は、AI 導入における 2 つの大きな難題——マネジメント負債と技術的負債——をこのやり方で扱ってきました。

基盤のマネジメント負債と、そこから派生する技術的負債。表面的には技術の混乱に見えるもの——アーキテクチャが複雑すぎる、サービスが多すぎる、速く書けば書くほど早く壊れる——も、根っこではすべて「マネジメント・システムが定義し切れていない」ことに起因しています。STR Network は、2 つの仕掛けでこの根因に手を打ちました：

• 第 1 節と第 2 節で書いた「Sunny ブリーフ × Jerry × Feng」の 3 人ガバナンス構造に、元帳概念と RBAC 権限モデルを重ねた仕組み。組織レベルで、何を管理するか、誰が管理するか、誰が何を見られるかを、ごく早い段階から明確に線引きしています。
• Sunny が最近書いた Dev Diagnosis Skill。要件が入ってくるたびに 1 度診断を走らせ——表面は技術の問題に見えて、その実、マネジメントの定義が曖昧なだけ、というケースをその場で食い止め、「違法建築」式の車輪の再発明を未然に防ぎます。

基盤のマネジメント負債が返済され、要件構造が明確になったあと、残るのは「運用」です——システムを立ち上げ、安定して動かし続ける。この層を担うのが Zeabur Agent です：Postgres をワンクリックで起動し、FastAPI をワンクリックで本番投入し、サービスをあるインスタンスから別のインスタンスへスケジューリングし、すべてのサービスの状態を 1 つのインターフェースに集める。

基盤の下には、まだ次の課題が待ち構えています：システムが多人数協業、複数インスタンス、複数環境にまで成長したとき、誰がどのインスタンスにアクセスでき、誰がどのサービスを変更でき、誰がどの区間のログを見られるか——これは技術が生み出すマネジメント要件であり、STR Network が次に Zeabur を通じて整理し、議論を重ねていく挑戦です。

ツールの部分は、AI 時代の流れの中でずっと変わり続けています——Apps Script から FastAPI へ、キーワードマッチから RAG へ、共有クラスターから BYOS へ——しかし、その底にある棚卸しのロジックは変わっていません。

「AI は技術の問題ではなく、マネジメントの問題だ」——Sunny は、そう語っています。

参考文献

• 何佩珊、陳盈螢（2025-06-26）。〈AI のフロントランナー STR Network はなぜ繰り返し作り直すのか？AI に取り組むなら、まず「マネジメント負債」を整理せよ〉。『商業週刊』第 1963 期。
• 曾子軒（2025-02-27）。〈『博恩夜夜秀』の舞台裏、STR Network チームの AI 神業——どうやって全員をレベルアップさせたのか〉。『遠見雜誌』。
• Sunny（2026-04-02）。〈How to Read the Vibes〉。Facebook 公開投稿 + GitHub repository mseatingtpe/dev-diagnosis-skill。
• Yuanlin Lin（2026-02-23）。〈共有クラスターでの新規プロジェクト受付を停止します〉。Zeabur Changelog。