トゥエルブラップス

Tokens Never Sleep: Twelve LabsがAIエージェントと仕事をして学んだ3ヶ月間の記録

スー・キム

Twelve Labsは過去3カ月間、「Tokens Never Sleep」イニシアチブを通じて、AIコパイロットとエージェントを実際の業務ワークフローに適用してきました。IT運用、製品開発、リサーチ、採用、総務まで、AIが反復業務や文脈の整理を担うことで、人間はより重要な判断、関係構築、構造設計に集中できるようになりました。この記事は、AIネイティブに働くということが、スピード、信頼性、そして人間の役割をどのように変化させるかについてのTwelve Labsの記録です。

Twelve Labsは過去3カ月間、「Tokens Never Sleep」イニシアチブを通じて、AIコパイロットとエージェントを実際の業務ワークフローに適用してきました。IT運用、製品開発、リサーチ、採用、総務まで、AIが反復業務や文脈の整理を担うことで、人間はより重要な判断、関係構築、構造設計に集中できるようになりました。この記事は、AIネイティブに働くということが、スピード、信頼性、そして人間の役割をどのように変化させるかについてのTwelve Labsの記録です。

この記事の内容

No headings found on page

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

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

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

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

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

2026/05/11

10分

記事へのリンクをコピー

私たちが眠っている間も稼働するシステム

Twelve Labsが実行速度を複利で積み上げる方法

最近、Twelve Labsの中でよく耳にする言葉があります。

“Tokens Never Sleep.”

今では一つのスローガンのように使われていますが、最初からスローガンだったわけではありません。始まりは極めて現実的な問いからでした。

今年初め、あるチームメンバーがLLMと連携した財務ツールを使って、以前なら数週間かかっていた分析を数分で終わらせました。ある人はその様子を見て「良いデモ/事例だな」と見過ごしたかもしれませんが、CEOが見たものは少し違っていました。AIを既存の業務に単に付け足したのではなく、最初からAIを基盤として働く方法でした。

その場で質問が続きました。

「これを他のデータや業務システムにも連携させることはできますか?」
「全員が使えるようにできますか?」
「私たちが眠っている間も稼働させることはできますか?」

「Tokens Never Sleep (TNS)」は、そのようにして誕生しました。

反復的でありながら手のかかる認知的労働、例えばチケット分類、アカウント管理、アップデートの追跡、会議の準備、リサーチのモニタリングといった仕事をAIコパイロットとエージェントが昼夜問わず処理し、人間は本当に意思決定が必要な領域に集中できるようにする仕組みです。

このイニシアチブは、最初から原則も明確でした。

  • デプロイしてフィードバックで磨き上げること。一つひとつの実行が、次の実行をより高速にする。

  • デモで示せないアイデアは疑うこと。

  • 何かを始める前に、「AIがこの仕事の80%を担えるか?」をまず問いかけること。

Twelve Labsは今年1月末からの約3ヶ月間、Tokens Never Sleepを実際の業務の中で運用してきました。最初の問いが「どれほど多くの仕事をAIに任せられるか?」だったとすれば、現在の問いは少し変化しています。

より多くのトークンを使うことが、無条件でより高い生産性につながるわけではないという事実に気づいたからです。トークン使用量のピークを通り過ぎた今、重要になっているのは、トークンをどれだけ使うかではなく、トークンがどのような文脈を読み、どのようなground truth(正解データ)の上で動き、人間の判断をどのように適材適所に配置するかです。


すべては一つのコパイロットから始まった

すべての始まりは、ITマネージャーのRick Mondragonのコパイロットでした。

どれほど優れた映像AIモデルを作っていても、深夜の権限エラー一つでエンジニアの作業が止まったり、異なるタイムゾーン間の空白の時間帯に社内ツールが停止してしまっては、生産性は途切れてしまいます。Rickはこの問題を解決するために、自身の役割や使用するツール、優先順位を理解するコパイロットを自作しました。チケット分類、アクセス権限の設定、セキュリティ監視といったスキルを実装し、実際の運用業務を委任できるようにしたのです。

結果は数値に表れました。

  • 一般的なアクセス権限のリクエスト対応:8時間 → 15分

  • 新入社員のオンボーディング:1日 → 10分の確認作業

  • 日常的なITチケットの60%:人の手を介さずに処理

残りの40%についても、コパイロットが事前に何を確認し、どのような問題が発見され、次のアクションが何であるかを整理して一緒に伝達してくれます。

一つのコパイロットが明確な効果を示すと、自然と次の疑問が湧いてきました。コパイロット同士を連携させたらどうなるだろうか?


一つのコパイロットからネットワークへ

一つのコパイロットが明確な効果を示すと、「誰もが自分だけのコパイロットを持てないだろうか?」という問いが自然と生まれました。そこでTwelve Labsは、コパイロット同士が繋がるコミュニケーションレイヤーを構築しました。各メンバーが、自分の役割、進行中のプロジェクト、使用するツール、権限範囲を理解するパーソナルコパイロットを持てるようにするためです。

例えば、サンフランシスコは午前2時、ソウルは午後6時だとしましょう。ソウルのエンジニアが新しい社内ツールで権限エラーに直面すると、そのエンジニアのコパイロットが問題を認識し、Rickのコパイロットが持つプロビジョニングスキルを呼び出して権限マトリックスを確認します。同時に、セキュリティ監視スキルとクロス検証を行い、システム自体の障害ではないかも確認します。

こうして数分以内にアクセスリクエストが解決されます。以前ならエンジニアはサンフランシスコが夜明けるまで待たなければならなかったところを、今では仕事の流れが途切れる前に問題が解消されるのです。

もちろん、ここでコパイロットが互いに協調するからといって、人間のコントロールが及ばない場所で勝手に動かすわけではありません。コパイロット間のすべてのタスクはSlack上で人間の承認を経て進められ、判断が必要な局面になれば、コパイロットが必要なコンテキストを事前にまとめて投稿し、人間はその上で判断を下すことになります。

このネットワークは、運用ツールにとどまらず、社内のビルド速度も一変させました。財務チームはダッシュボードを作り、採用チームはソーシングアプリを構築しました。以前なら「検討してみます」から始まってバックログのどこかに埋もれていたアイデアが、今では数時間で実際の運用ツールになっています。


AIを作るチームがAIを使って仕事をした

Pegasus 1.5を開発していた時期、同様の光景が製品開発の現場でも繰り広げられていました。AIモデルを構築するチームは、同時にAIを最も積極的に活用するチームでもありました。

Sam(ML Research Scientist)は、学習の初期段階で構造的な問題に直面しました。学習速度を大幅に向上させるFlash Attentionパッケージが、Twelve Labsのモデル構造にはそのまま適用できなかったのです。回避策をとる代わりに、SamはClaude Codeを活用してGPUカーネルを直接カスタムすることで問題を解決しました。

「Claude Codeを駆使してGPUカーネルを自作し、カスタムして使いました。AIネイティブな環境で働くということは、こういうことができるようになることなのだと実感しました。」

— Sam, ML Research Scientist

開発スピードも変わりました。Backend EngineerのGenieは、Pegasus 1.5のコア機能であるTBM(Time-based Metadata)をわずか2日で開発しました。PRD(製品要求仕様書)が出たら、まずTechnical Documentを丁寧に作成し、実装はエージェントとしてClaudeに委任するという手法をとりました。テストの自動化、プラットフォーム連携、バグ検出まで、すべてそのプロセスの流れの中で処理されました。

数値はその差をはっきりと示しています。タイムゾーンをまたいで協調していた以前のプロジェクトでは、2〜3週間の作業で約30件のQAバグが発生しましたが、今回のPegasus 1.5は2日の開発期間で発生したバグはわずか6件でした。

「実際に自分でコードを書く時間は大幅に減り、より美しく使いやすいAPIスペックを作成するにはどうすればよいかといった、建設的な議論をする時間がずっと増えたと感じています。」
— Genie, Backend Engineer

これは単に「コードを早く書ける」というだけの話ではありません。個人にさらなる決定権と高速なフィードバックループが与えられるとき、AIは生産性を引き上げる単純な道具ではなく、働くための前提条件に変わるのです。

「コーディングエージェントなどの進化により、個人の生産性は劇的に向上しました。これを活かすためには、個人に素早く決定を下しループを回す権限をどんどん渡していく必要があります。」
— SJ, Machine Learning Engineering Manager


チームの記憶をシステム化する:Danの2つのエージェント

Marengo and Searchチームを率いるDanは、研究チームのリードとして常に悩んでいた問題がありました。ソウルとサンフランシスコにまたがるチームメンバー、同時に進行する複数のイニシアチブ、そして絶え間なく流れるLinearのチケット、GitHubのコミット、WandBの実験結果。リードとしてチーム全体の文脈を見失わずに、自身の業務をこなすことは大きな負担でした。

Danはこの問題を構造的に解決することにしました。目的が異なる2つのエージェントを自作したのです。

一つは Dot です。Dotはチームのためのノレッジコーディネーターで、毎朝メンバーが出勤する前に、Linearのプロジェクト状況、GitHubのコミットやPR活動、WandBの実験結果、NotionのPRDを同期して要約します。誰かが「このイニシアチブは今どこまで進んでいますか?」と聞けば、Dotが複数システムに分散した情報を繋ぎ合わせ、チームメンバーが何度も同じ説明をしなくて済むようにします。

もう一つは Dan’s OS です。Dan個人のワークフローエンジンに近いこのエージェントは、夜の間に溜まったSlackのメンションを分類して朝一番に見るべきものを整理し、ミーティング前には関係者のコンテキストと直近の意思決定の流れをまとめてブリーフィングします。新着の論文が現行の研究課題やロードマップに関連するかどうかも監視します。何が決定されたかだけでなく、なぜそう決定されたかのプロセスまで説明を残します。

このように、Dotはチームの記憶を、Dan's OSはリーダーの判断の文脈を司ります。2つのエージェントは異なる役割を持ちますが、一体となって稼働することで一つのOSのように動作します。

Danには、Slack上にDot向けのスクラッチパッドも用意されています。考えを整理したい時にそこに乱雑に書き込んでおけば、Dotがそれを受け取って整理し、必要なフローへと繋げます。リードの頭の中だけに留まっていたアイデアがシステムに取り込まれ、チームが活用できる文脈に変換されるのです。

Danはエージェントを導入することで、マネジメント業務にかかるコストが大幅に削減されたと語ります。ここで言うコストとは、単なる時間のコストではありません。誰が何をしていたか、どの決定がどこから来たのか、どの論文が現行のワークストリームに関連しているか、どのトピックを再検討すべきかを常に頭の中で抱え続ける認知的コストです。Dotがチームの文脈を維持し続けてくれるため、Danはすべての情報を一人で抱え込むことなく、整理された文脈に基づいてより重要度の高い判断を下せるようになりました。


3ヶ月の記録:私たちが学んだこと

「Tokens Never Sleep」を今年の1月末にスタートさせ、気づけば3ヶ月の月日が流れました。

当初は「AIを使って働けば、より多くのことをより迅速に行える」という期待が大きかったです。実際に多くのタスク処理が加速しました。しかし3ヶ月を経験した今、より本質的な教訓を得るに至りました。

第一に、トークンを多く使っても、生産性がその使用量に比例して向上するわけではないということです。

エージェントを稼働させる理由は、人間の時間と集中力が有限だからです。その有限なリソースを本当に判断が必要なクリエイティブな仕事に振り向けるため、反復的で文脈整理が必要なタスクをエージェントへ委任するのです。核心は使用量ではなく、活用の方向性にあります。

第二に、エージェントよりもデータ管理が先決であるということです。

MCPのような接続レイヤーが多様化し、Slack、Linear, GitHub, Notion, WandBといったシステムを容易に連携させられるようになったことで、エージェントができる範囲は急速に広がっています。しかし、接続が容易になったからといって、自動的に優れた成果が生まれるわけではありません。

どれほど優れたエージェントを作っても、そのエージェントが読み込むデータが煩雑であれば全く使い物になりません。優秀な人間に対して、誤った情報だらけの本を読ませるようなものです。

結局、エージェントの処理品質はデータの品質から始まります。どのドキュメントが最新か、どのデータが基準か、どの決定が確定したものか、どのメモが単なるアイデアの跡に過ぎないかをチーム内で整理しておくこと。それがシステム全体の土台となります。

優れたエージェントを作ることは、堅牢なground truth(信頼できる情報源)を構築することと同義です。

第三に、採用の判断基準も変化しているということです。

韓国オフィスのカントリーマネージャーであるHyeminは、この変化を採用現場でも実感しています。

「3ヶ月前と今とでは、候補者の方を見る基準が変わりました。以前はデータ整理や単純作業をサポートできる方が必要でしたが、現在ではその仕事の大部分をエージェントがこなせるようになったためです。その結果、今は構造を設計して判断を下せる人、エージェントへ上手にタスクを委任し、その結果を解釈できる人を求めるようになりました。」
— Hyemin Lee, Country Manager - Korea

働き方が変われば、一緒に働きたい仲間の定義も変わります。

かつては基礎的なデータ整理やオペレーション実務をサポートする人材が必要とされていたかもしれませんが、今やその役割の多くはエージェントに任せることができます。代わりに人間にとってより重要度を増すのは別の領域です。業務全体の構成をデザインすること、優れた入力データや基準を整えること、人と人との信頼醸成やエンゲージメントが必要なポイントを見極めること、そして最終的な判断に責任を持つことです。

Twelve Labsで「AIネイティブに働く」ということは、単にAIツールを使いこなすという意味に留まりません。問題を構造化し、堅牢なground truthを構築し、再現性のあるシステムへと変換し、最終的な判断の責任を負えるようになることを意味しています。


より本質的な問題へ思考を巡らせるために、私たちはAIを使う

Tokens Never Sleepは、「AIを多用しよう」という単なるキャンペーンではありません。

私たちが眠っている間もトークンを動かし続けようという言葉ですが、その目的は人間に長時間労働を強いることではなく、人間しか持たない集中力や判断力をより大切に、効率的に使うためのアプローチです。

チケット対応はコパイロットに見守らせることができます。
ドキュメントはエージェントに整理させることができます。
会議前の背景やコンテキストの整理はシステムに事前準備させることができます。
論文調査は夜のうちに終わらせておくことができます。
繰り返されるフォローアップ業務は自動化できます。

しかし、何が解決すべき重要な問題なのかを見定める仕事、どのような決断を下すべきか判断する仕事、誰とどのように信頼を築いていくかという選択は、依然として人間に委ねられています。

Twelve Labsがこれまでの3ヶ月間で学んだことは極めてシンプルです。

AIは人にとって代わるものではなく、人間が果たすべき本質的な役割をより鮮明に浮き彫りにします。
トークンは眠りませんが、トークンが代替できない意思決定は今なお人間の役割です。
したがって、優れたエージェントを作り上げることは、結果としてより効率的な組織運営の体制を構築することにつながります。

私たちは完璧を待つことはありません。
まずは作り、実際の業務に適用し、フィードバックを取り入れて改善します。
デモで価値を示せないアイデアは疑ってかかり、人間が繰り返し抱え込んでいるタスクがあれば再度問い直します。

「AIがこの仕事の80%をこなせるだろうか?」
「もしそうなら、人間は残りの20%でどのような付加価値をもたらすべきか?」

Tokens Never Sleepはその問いから出発し、今この瞬間も毎日アップデートされ続けています。

トークンは眠りません。
だからこそ、私たちはさらに重要な問題について思索を深めることができるのです。


私たちのチームと一緒にこの挑戦をリードしていきませんか? → Twelve Labs 採用情報

私たちが眠っている間も稼働するシステム

Twelve Labsが実行速度を複利で積み上げる方法

最近、Twelve Labsの中でよく耳にする言葉があります。

“Tokens Never Sleep.”

今では一つのスローガンのように使われていますが、最初からスローガンだったわけではありません。始まりは極めて現実的な問いからでした。

今年初め、あるチームメンバーがLLMと連携した財務ツールを使って、以前なら数週間かかっていた分析を数分で終わらせました。ある人はその様子を見て「良いデモ/事例だな」と見過ごしたかもしれませんが、CEOが見たものは少し違っていました。AIを既存の業務に単に付け足したのではなく、最初からAIを基盤として働く方法でした。

その場で質問が続きました。

「これを他のデータや業務システムにも連携させることはできますか?」
「全員が使えるようにできますか?」
「私たちが眠っている間も稼働させることはできますか?」

「Tokens Never Sleep (TNS)」は、そのようにして誕生しました。

反復的でありながら手のかかる認知的労働、例えばチケット分類、アカウント管理、アップデートの追跡、会議の準備、リサーチのモニタリングといった仕事をAIコパイロットとエージェントが昼夜問わず処理し、人間は本当に意思決定が必要な領域に集中できるようにする仕組みです。

このイニシアチブは、最初から原則も明確でした。

  • デプロイしてフィードバックで磨き上げること。一つひとつの実行が、次の実行をより高速にする。

  • デモで示せないアイデアは疑うこと。

  • 何かを始める前に、「AIがこの仕事の80%を担えるか?」をまず問いかけること。

Twelve Labsは今年1月末からの約3ヶ月間、Tokens Never Sleepを実際の業務の中で運用してきました。最初の問いが「どれほど多くの仕事をAIに任せられるか?」だったとすれば、現在の問いは少し変化しています。

より多くのトークンを使うことが、無条件でより高い生産性につながるわけではないという事実に気づいたからです。トークン使用量のピークを通り過ぎた今、重要になっているのは、トークンをどれだけ使うかではなく、トークンがどのような文脈を読み、どのようなground truth(正解データ)の上で動き、人間の判断をどのように適材適所に配置するかです。


すべては一つのコパイロットから始まった

すべての始まりは、ITマネージャーのRick Mondragonのコパイロットでした。

どれほど優れた映像AIモデルを作っていても、深夜の権限エラー一つでエンジニアの作業が止まったり、異なるタイムゾーン間の空白の時間帯に社内ツールが停止してしまっては、生産性は途切れてしまいます。Rickはこの問題を解決するために、自身の役割や使用するツール、優先順位を理解するコパイロットを自作しました。チケット分類、アクセス権限の設定、セキュリティ監視といったスキルを実装し、実際の運用業務を委任できるようにしたのです。

結果は数値に表れました。

  • 一般的なアクセス権限のリクエスト対応:8時間 → 15分

  • 新入社員のオンボーディング:1日 → 10分の確認作業

  • 日常的なITチケットの60%:人の手を介さずに処理

残りの40%についても、コパイロットが事前に何を確認し、どのような問題が発見され、次のアクションが何であるかを整理して一緒に伝達してくれます。

一つのコパイロットが明確な効果を示すと、自然と次の疑問が湧いてきました。コパイロット同士を連携させたらどうなるだろうか?


一つのコパイロットからネットワークへ

一つのコパイロットが明確な効果を示すと、「誰もが自分だけのコパイロットを持てないだろうか?」という問いが自然と生まれました。そこでTwelve Labsは、コパイロット同士が繋がるコミュニケーションレイヤーを構築しました。各メンバーが、自分の役割、進行中のプロジェクト、使用するツール、権限範囲を理解するパーソナルコパイロットを持てるようにするためです。

例えば、サンフランシスコは午前2時、ソウルは午後6時だとしましょう。ソウルのエンジニアが新しい社内ツールで権限エラーに直面すると、そのエンジニアのコパイロットが問題を認識し、Rickのコパイロットが持つプロビジョニングスキルを呼び出して権限マトリックスを確認します。同時に、セキュリティ監視スキルとクロス検証を行い、システム自体の障害ではないかも確認します。

こうして数分以内にアクセスリクエストが解決されます。以前ならエンジニアはサンフランシスコが夜明けるまで待たなければならなかったところを、今では仕事の流れが途切れる前に問題が解消されるのです。

もちろん、ここでコパイロットが互いに協調するからといって、人間のコントロールが及ばない場所で勝手に動かすわけではありません。コパイロット間のすべてのタスクはSlack上で人間の承認を経て進められ、判断が必要な局面になれば、コパイロットが必要なコンテキストを事前にまとめて投稿し、人間はその上で判断を下すことになります。

このネットワークは、運用ツールにとどまらず、社内のビルド速度も一変させました。財務チームはダッシュボードを作り、採用チームはソーシングアプリを構築しました。以前なら「検討してみます」から始まってバックログのどこかに埋もれていたアイデアが、今では数時間で実際の運用ツールになっています。


AIを作るチームがAIを使って仕事をした

Pegasus 1.5を開発していた時期、同様の光景が製品開発の現場でも繰り広げられていました。AIモデルを構築するチームは、同時にAIを最も積極的に活用するチームでもありました。

Sam(ML Research Scientist)は、学習の初期段階で構造的な問題に直面しました。学習速度を大幅に向上させるFlash Attentionパッケージが、Twelve Labsのモデル構造にはそのまま適用できなかったのです。回避策をとる代わりに、SamはClaude Codeを活用してGPUカーネルを直接カスタムすることで問題を解決しました。

「Claude Codeを駆使してGPUカーネルを自作し、カスタムして使いました。AIネイティブな環境で働くということは、こういうことができるようになることなのだと実感しました。」

— Sam, ML Research Scientist

開発スピードも変わりました。Backend EngineerのGenieは、Pegasus 1.5のコア機能であるTBM(Time-based Metadata)をわずか2日で開発しました。PRD(製品要求仕様書)が出たら、まずTechnical Documentを丁寧に作成し、実装はエージェントとしてClaudeに委任するという手法をとりました。テストの自動化、プラットフォーム連携、バグ検出まで、すべてそのプロセスの流れの中で処理されました。

数値はその差をはっきりと示しています。タイムゾーンをまたいで協調していた以前のプロジェクトでは、2〜3週間の作業で約30件のQAバグが発生しましたが、今回のPegasus 1.5は2日の開発期間で発生したバグはわずか6件でした。

「実際に自分でコードを書く時間は大幅に減り、より美しく使いやすいAPIスペックを作成するにはどうすればよいかといった、建設的な議論をする時間がずっと増えたと感じています。」
— Genie, Backend Engineer

これは単に「コードを早く書ける」というだけの話ではありません。個人にさらなる決定権と高速なフィードバックループが与えられるとき、AIは生産性を引き上げる単純な道具ではなく、働くための前提条件に変わるのです。

「コーディングエージェントなどの進化により、個人の生産性は劇的に向上しました。これを活かすためには、個人に素早く決定を下しループを回す権限をどんどん渡していく必要があります。」
— SJ, Machine Learning Engineering Manager


チームの記憶をシステム化する:Danの2つのエージェント

Marengo and Searchチームを率いるDanは、研究チームのリードとして常に悩んでいた問題がありました。ソウルとサンフランシスコにまたがるチームメンバー、同時に進行する複数のイニシアチブ、そして絶え間なく流れるLinearのチケット、GitHubのコミット、WandBの実験結果。リードとしてチーム全体の文脈を見失わずに、自身の業務をこなすことは大きな負担でした。

Danはこの問題を構造的に解決することにしました。目的が異なる2つのエージェントを自作したのです。

一つは Dot です。Dotはチームのためのノレッジコーディネーターで、毎朝メンバーが出勤する前に、Linearのプロジェクト状況、GitHubのコミットやPR活動、WandBの実験結果、NotionのPRDを同期して要約します。誰かが「このイニシアチブは今どこまで進んでいますか?」と聞けば、Dotが複数システムに分散した情報を繋ぎ合わせ、チームメンバーが何度も同じ説明をしなくて済むようにします。

もう一つは Dan’s OS です。Dan個人のワークフローエンジンに近いこのエージェントは、夜の間に溜まったSlackのメンションを分類して朝一番に見るべきものを整理し、ミーティング前には関係者のコンテキストと直近の意思決定の流れをまとめてブリーフィングします。新着の論文が現行の研究課題やロードマップに関連するかどうかも監視します。何が決定されたかだけでなく、なぜそう決定されたかのプロセスまで説明を残します。

このように、Dotはチームの記憶を、Dan's OSはリーダーの判断の文脈を司ります。2つのエージェントは異なる役割を持ちますが、一体となって稼働することで一つのOSのように動作します。

Danには、Slack上にDot向けのスクラッチパッドも用意されています。考えを整理したい時にそこに乱雑に書き込んでおけば、Dotがそれを受け取って整理し、必要なフローへと繋げます。リードの頭の中だけに留まっていたアイデアがシステムに取り込まれ、チームが活用できる文脈に変換されるのです。

Danはエージェントを導入することで、マネジメント業務にかかるコストが大幅に削減されたと語ります。ここで言うコストとは、単なる時間のコストではありません。誰が何をしていたか、どの決定がどこから来たのか、どの論文が現行のワークストリームに関連しているか、どのトピックを再検討すべきかを常に頭の中で抱え続ける認知的コストです。Dotがチームの文脈を維持し続けてくれるため、Danはすべての情報を一人で抱え込むことなく、整理された文脈に基づいてより重要度の高い判断を下せるようになりました。


3ヶ月の記録:私たちが学んだこと

「Tokens Never Sleep」を今年の1月末にスタートさせ、気づけば3ヶ月の月日が流れました。

当初は「AIを使って働けば、より多くのことをより迅速に行える」という期待が大きかったです。実際に多くのタスク処理が加速しました。しかし3ヶ月を経験した今、より本質的な教訓を得るに至りました。

第一に、トークンを多く使っても、生産性がその使用量に比例して向上するわけではないということです。

エージェントを稼働させる理由は、人間の時間と集中力が有限だからです。その有限なリソースを本当に判断が必要なクリエイティブな仕事に振り向けるため、反復的で文脈整理が必要なタスクをエージェントへ委任するのです。核心は使用量ではなく、活用の方向性にあります。

第二に、エージェントよりもデータ管理が先決であるということです。

MCPのような接続レイヤーが多様化し、Slack、Linear, GitHub, Notion, WandBといったシステムを容易に連携させられるようになったことで、エージェントができる範囲は急速に広がっています。しかし、接続が容易になったからといって、自動的に優れた成果が生まれるわけではありません。

どれほど優れたエージェントを作っても、そのエージェントが読み込むデータが煩雑であれば全く使い物になりません。優秀な人間に対して、誤った情報だらけの本を読ませるようなものです。

結局、エージェントの処理品質はデータの品質から始まります。どのドキュメントが最新か、どのデータが基準か、どの決定が確定したものか、どのメモが単なるアイデアの跡に過ぎないかをチーム内で整理しておくこと。それがシステム全体の土台となります。

優れたエージェントを作ることは、堅牢なground truth(信頼できる情報源)を構築することと同義です。

第三に、採用の判断基準も変化しているということです。

韓国オフィスのカントリーマネージャーであるHyeminは、この変化を採用現場でも実感しています。

「3ヶ月前と今とでは、候補者の方を見る基準が変わりました。以前はデータ整理や単純作業をサポートできる方が必要でしたが、現在ではその仕事の大部分をエージェントがこなせるようになったためです。その結果、今は構造を設計して判断を下せる人、エージェントへ上手にタスクを委任し、その結果を解釈できる人を求めるようになりました。」
— Hyemin Lee, Country Manager - Korea

働き方が変われば、一緒に働きたい仲間の定義も変わります。

かつては基礎的なデータ整理やオペレーション実務をサポートする人材が必要とされていたかもしれませんが、今やその役割の多くはエージェントに任せることができます。代わりに人間にとってより重要度を増すのは別の領域です。業務全体の構成をデザインすること、優れた入力データや基準を整えること、人と人との信頼醸成やエンゲージメントが必要なポイントを見極めること、そして最終的な判断に責任を持つことです。

Twelve Labsで「AIネイティブに働く」ということは、単にAIツールを使いこなすという意味に留まりません。問題を構造化し、堅牢なground truthを構築し、再現性のあるシステムへと変換し、最終的な判断の責任を負えるようになることを意味しています。


より本質的な問題へ思考を巡らせるために、私たちはAIを使う

Tokens Never Sleepは、「AIを多用しよう」という単なるキャンペーンではありません。

私たちが眠っている間もトークンを動かし続けようという言葉ですが、その目的は人間に長時間労働を強いることではなく、人間しか持たない集中力や判断力をより大切に、効率的に使うためのアプローチです。

チケット対応はコパイロットに見守らせることができます。
ドキュメントはエージェントに整理させることができます。
会議前の背景やコンテキストの整理はシステムに事前準備させることができます。
論文調査は夜のうちに終わらせておくことができます。
繰り返されるフォローアップ業務は自動化できます。

しかし、何が解決すべき重要な問題なのかを見定める仕事、どのような決断を下すべきか判断する仕事、誰とどのように信頼を築いていくかという選択は、依然として人間に委ねられています。

Twelve Labsがこれまでの3ヶ月間で学んだことは極めてシンプルです。

AIは人にとって代わるものではなく、人間が果たすべき本質的な役割をより鮮明に浮き彫りにします。
トークンは眠りませんが、トークンが代替できない意思決定は今なお人間の役割です。
したがって、優れたエージェントを作り上げることは、結果としてより効率的な組織運営の体制を構築することにつながります。

私たちは完璧を待つことはありません。
まずは作り、実際の業務に適用し、フィードバックを取り入れて改善します。
デモで価値を示せないアイデアは疑ってかかり、人間が繰り返し抱え込んでいるタスクがあれば再度問い直します。

「AIがこの仕事の80%をこなせるだろうか?」
「もしそうなら、人間は残りの20%でどのような付加価値をもたらすべきか?」

Tokens Never Sleepはその問いから出発し、今この瞬間も毎日アップデートされ続けています。

トークンは眠りません。
だからこそ、私たちはさらに重要な問題について思索を深めることができるのです。


私たちのチームと一緒にこの挑戦をリードしていきませんか? → Twelve Labs 採用情報