プラットフォーム

価格

ソリューション

構築

資料

会社情報

Select Language

Playgroundへ移動

営業担当に相談する

トゥエルブラップス

Pegasus 1.5を作った人々

スー・キム

製品が世の中に出るまで、ペガサスを共に作り上げた Twelve Labs ソウルチームのストーリー。リサーチャー、MLE、データエンジニア、バックエンドエンジニア、QAまで — Twelve Labs ソウルチームがどのように Pegasus 1.5 を開発したのか、直接話を聞いてみました。

この記事の内容

No headings found on page

ニュースレターに登録する

ビデオ理解に関する最新の技術進歩、チュートリアル、業界の動向をお届けします

AIを活用してビデオを検索、分析、探索します。

プレイグラウンドを試す

2026/04/20

8分

記事へのリンクをコピー

製品が世に出る時、最初に目に留まるのは通常、機能や性能です。
しかし、実際のリリースを作り上げているのは、その裏にいる人々の判断と努力、そして協働のプロセスです。

Pegasus 1.5 もまた、そうでした。

今回のリリースは、リサーチ、機械学習エンジニアリング（MLE）、バックエンド、データ、テストインフラまで、多様な役割が「一つの目標」の下でより緊密につながることで進められました。あるメンバーは学習とデータ品質を担当し、あるメンバーは評価（evaluation）とサービング（serving）の構造を根底から再設計しました。また、あるメンバーはユーザー向けAPIとSDKを構築し、またあるメンバーは厳しいスケジュールの中でテスト自動化を進めることでリリースの品質を向上させました。

何よりも、Pegasus 1.5 チームにとって今回のリリースは、単なるアップグレードではなく、「再び土台から積み上げる」という感覚に非常に近いものでした。学習コード、サービング構造、評価方法を再整理し、次のステップのための基盤を作るプロセスだったのです。

「社外的には1.2から1.5へのアップデートですが、社内的にはもう一度ゼロからスタートするのに近い感覚でした」 — Sam, ML Research Scientist

より鮮明になった目標、より重要になったデータ

今回の Pegasus 1.5 リリースにおける大きな変化の一つは、モデル開発の目標がこれまで以上に明確になったことでした。

単にモデルを改善するのではなく、「どの課題をよりうまく解決するか」を最初に定義し、それに合わせてデータと学習が設計されました。

「漠然と大量のデータを流し込めばモデルの性能が上がるだろう、という考えが間違いであることを身をもって知りました。高めたい能力（capability）があるなら、それをピンポイントでターゲットにしたデータを本当に集めなければならない。それがどれほど重要かを深く実感しました。Data is King（データこそがすべて）です。」
— Sam, ML Research Scientist

この変化はデータチームにも影響を与えました。これまではデータを収集して手渡す役割が中心でしたが、今回はそのデータが実際に学習でどのように使われ、どのようなボトルネックを生んでいるかを間近で観察することができました。これまでの協働が「群盲象を評す」ように部分的にしか見えていなかったとしたら、今回は全体が一本の線でつながった形で見え始めたのです。

「これまでは単にデータを渡すだけだったので、会社のパイプライン全体に貢献しているという実感が少し間接的でした。しかし、今回、実際にどう使われているかを直接見ることで、モデルのフライホイールをより速く回すためのアイディアが次々と生まれるようになりました」
— Elton, Software Engineer, ML Data

「以前はデータを引き渡した後のプロセスがあまり見えていませんでしたが、今回は『あ、実際にはこのように使われているんだ』『こういう問題があるんだ』と直接見ることで、理解を深めていくことができました」 — Haley, Software Engineer, Data

広がる役割、変化する働き方

今回の Pegasus 1.5 では、各自の役割が自然と拡張されていきました。

Twelve Labsのエンジニアリングおよびリサーチチームは、Pod（ポッド）構造で組織されています。この構造の中では、機能別の役割にとどまらず、プロダクトの目標を中心に必要な課題に幅広く取り組むことになります。Podとは、特定の目標やプロダクト領域を中心とした、機動性の高い小さな協働チームのことです。例えば、エンジニア、PM、デザイナー、QAがワンチームとなり、一つの機能やドメインを自律的に担当する構造を指します。

実際に、機械学習エンジニアがトレーニングタスクをエンドツーエンドで経験したり、データエンジニアが学習直前のプロセスの最適化まで担ったり、バックエンドエンジニアがAPIスペックからサービス連携、SDKまで並行して担当するといったことが、当たり前のように行われました。

「以前の機能組織では、期待される職能についてのみ役割を割り当てられていましたが、現在はPodというプロダクトの目標に最適化された組織に変わりました。自分の専門分野（specialty）だけでなく、必要に応じて状況に応じたより広い領域にも踏み込めるようになります。その分、よりハイレベルな意思決定や全体像に触れ、理解する機会が自然と増えるのだと思います」
— Kevin, Machine Learning Engineer

「一人のメンバーがプロジェクト一つを最初から最後まで完全に責任を持つ、という流れが強くなっているのを感じます。業務範囲が広がり、個人のオーナーシップが非常に大きくなっているのを実感しており、最近はこれが特に印象深いです」 — Wade, Machine Learning Engineer

この変化は、単に業務量が増えたわけではなく、個人がより多くのコンテキスト（背景）を理解し、主体となったことで、意思決定と実行のスピードが上がったという変化に他なりませんでした。

タイトだったからこそ、密度が高かったプロセス
（そして、その中で直面した「リアルな瞬間」）

今回のリリーススケジュールは、多くのチームメンバーが共通して「タイトだった」と口にするほど逼迫していました。実際に徹夜で学習課題を解決したり、リリース直前に数時間の仮眠だけで作業を再開せざるを得ない局面もありました。

「正直に言うと、金曜日に学習がどうしても回らず、土曜日の朝7時に帰宅したのが一番記憶に残っています（笑）」 — Sam, ML Research Scientist

「モデルの学習がうまく進まず、夜中の3時までオフィスで仕事をしていたことがあったのですが、深夜特有の変なテンションになって、みんなで他愛もないおしゃべりをして大笑いしたことが思い出深いです。まるで修学旅行のような雰囲気で、楽しかったですが本当に過酷でした。『あぁ、自分はスタートアップにいるんだな』と強く実感した瞬間ですね」
— Lia, ML Research Scientist

しかし同時に、その凝縮されたプロセスが急速な学びと成長につながったという声も多く寄せられました。最初にスケジュールを聞いた際、「これは不可能だ」と思ったKevinは、評価プラットフォームを最初から最後まで構築し、LLMモデルサイクルの全行程を自らの手で経験しました。

「スケジュールは凄まじくタイトで、肉体的にはかなりハードでしたが、『それでも得られるものは確実にあった！』と自信を持って言えます」 — Kevin, Machine Learning Engineer

使いやすさを最優先したユーザー体験の設計

今回のリリースでは、モデルの技術的な改善にとどまらず、
「ユーザーが実際にこの機能をどう使うか」という視点への向き合い方も深まりました。

特にAPI設計においては、単に機能を提供するだけでなく、
より直感的な利用体験を作るために、何度も方向性を変えながら徹底的な議論が交わされました。

以前は動画を分析するために、まずインデキシング（indexing）の手順を経る必要がありましたが、今回はその工程を挟むことなく、URLを指定するだけで直接処理を回せるような仕組みに刷新しました。ユーザーからは気づきにくい部分かもしれませんが、この設計一つに非常に多くの思考のプロセスが注ぎ込まれています。

「以前であれば、モデルが進化するにつれて内部ロジックを微調整する程度でしたが、今回は新しいモデルが登場したことで、API自体をどうデザインすべきかに多くの時間を費やしました。将来の拡張性を残しつつ、今いるユーザーにより自然に使ってもらうためにはどうすればよいかを追求した結果です」
— Genie, Backend Engineer

QA（品質保証）の観点でも、変化は明らかでした。単に機能が正しく動作するかを確認するだけでなく、「これは実際のユーザーにとって十分に快適な体験と言えるか」を基準に、品質を見極めました。

「以前なら1〜2週間ほどかかっていた検証を、自動化スクリプトと入念な事前準備のおかげで、3〜4日以内にほとんどのバグや問題をすべて検知・修正することができました」 — Luke, Software Engineer, Testing Infrastructure

ソウルオフィスで「一枚岩」となって働くこと

今回の Pegasus 1.5 の道のりを振り返った時、多くのメンバーが共通して挙げたのが、ソウルオフィスに皆が集まり、膝を突き合わせて働いた経験でした。

本質は、単に同じ空間にいたということではなく、「議論から意思決定までの距離が圧倒的に短くなったこと」にあります。

Slackメッセージを長々と作って、太平洋を越えた海の向こうの返信を翌日まで待つ代わりに、必要な瞬間にその場でハドルを開き、すぐに話し合って修正を加えました。意思決定権がPodの中に凝縮されていたからこそ実現できたスピードです。

「Slackのハドルですぐに会話を始め、一緒に設計し…バグが出たらペアプログラミングをしてその場で即座に修正を入れました」 — Genie, Backend Engineer

「ソウルオフィスに全開発メンバーが集まり、必要なときにすぐ対面や口頭で話すことができたため、業務への集中度と密度の高さがこれまで以上でした」 — Kevin, Machine Learning Engineer

この変化は、単にコミュニケーション方法の違いにとどまらず、仕事を進める構造そのものと深く結びついていました。

異なるチーム同士が協力する形から、一緒に決めるべき人々が最初から一つのユニットとして動いたことで、「本当の意味でのチーム」として動いている感覚が醸成されたためです。スピーディな意思決定が可能になり、文脈（コンテキスト）を共有するための手間とコストも激減しました。

「以前はチーム同士を連携させるという感じでしたが、今は『本当に一緒に動くべき人たち』が内部にすべて揃い、お互いに頻繁に会話できるようになりました。そのため、完全に一つのワンチームとして開発が進められました」 — SJ, Machine Learning Engineering Manager

QAを担当したLukeは、一連の変化を次のようなシンプルな一言で要約しました。

「何より、計画した日程通りに進みました」

「不確実性をともなうAIモデルの開発において、予測スケジュール通りに進めるというのは非常に難易度が高いことです。それが予定通りにいけたということは、メンバーの習熟度が上がったこと、あるいは非常に熱量高く努力したことの裏返しですので、傍から見ていて『本当に素晴らしいチームだな』と感じました」
— Luke, Software Engineer, Testing Infrastructure

完成ではなく、次へ進むためのマイルストーン

非常に興味深いのは、今回のリリースの振り返りの中で、多くのチームメンバーが Pegasus 1.5 を単なる「完成されたゴール」ではなく、
「次なるステップへの確かな足がかり」として語っていた点です。

今回のプロジェクトを通じて、評価プラットフォームが文字通りゼロから構築され、データと学習のパイプラインがより強固に結束されました。そして今後、モデルのさらなる改善スピードを加速させるためのロードマップも、鮮明に見えてきています。

「今回は単に一つのプロダクトを完成させただけでなく、今後の開発効率を高めるためのフライホイールを構築できたプロセスだと捉えています。次の段階のリリースは、さらに良いものを、よりスピーディに開発できるようになると確信しています」 — Kevin, Machine Learning Engineer

その一方で、メンバーたちがモデルに対して抱く本音や期待には、非常に謙虚な一面もありました。ML Research ScientistのLiaは、Pegasusにはまだ改善の余地が多く残されていると語ります。

「自分が開発に関わったモデルなので、『本当に大丈夫だろうか、ボロボロだったらどうしよう』という不安がどうしても頭をよぎるんです。社内でGeminiとの実力を測るブラインドテストをした時、裏で『Geminiってやっぱり凄すぎる。Pegasusがこれに勝てるわけない』と思いながら回答をポチポチ投票していたのですが…集計してみたら、私が票を入れ、Geminiだと思っていた4点のうち3つは、実はPegasusの回答だったんです。未だに数え間違いやおかしなバグなんじゃないかと疑っているぐらいです（笑）」
— Lia, ML Research Scientist

生みの親自身が、誰よりも徹底的に客観視し疑い続けていること。そしてその疑念をよそに、Pegasusがすでに世界レベルの優れた結果を出していること。

取り組むべき伸び代が明確に見えているからこそ、「次はさらに力強く、圧倒的なスピードで前進できる」というチームの結束と確信は、確実に実を結ぼうとしています。