アパラタス（機関）：私たちが動いていない間も稼働し続けるマシーンの構築

ダッシュボードからすべてが始まった

現在、TwelveLabsでは「トークンは眠らない」というフレーズが飛び交っています。しかし、これがフレーズになる前は、1つの問いでした。そして正直なところ、その始まりこそがこのストーリーの最も素晴らしい部分です。

数週間前、当社のCEOであるJae（ジェ）は、かつてなら数週間かかっていたものを、あるチームメンバーがものの数分で構築するのを目にしました。LLMに接続され、人間が手を貸すことなく、実際的な分析と出力を生み出す財務ツールです。大抵の人は「素晴らしいデモだ」と言って終わらせたでしょう。しかしJaeは全く別のものを見ていました。彼は、AIを後から付け足す機能としてではなく、構築の基盤としたとき、業務がどのように変化するかを見抜いたのです。彼の問いはダッシュボードそのものについてではありませんでした。「もっと多くのものを接続できないか？」というものでした。

私は「やってみましょう」と答えました。

そこで私は、LLMの内部に競合分析の「スキル」を構築しました。それを当社のCRM、ナレッジベース、ウェブ検索に接続し、実行ボタンを押しました。するとLLMは、手動で作成すれば丸一日かかるような競合分析ダッシュボードを生成したのです。Jaeはそれを見て、すべてを変えることになる問いを投げかけました。「これを全員が使えるようにできないか？ 私たちが眠っている間もこれを機能させることはできないか？」

ここから「トークンは眠らない」が誕生しました。マーケティングのキャッチコピーとしてではなく、現実の運用上の問いとしてです。「もしAIコパイロットが、チケットのトリアージ、システムのプロビジョニング、アップデートの追跡といった、反復的な認知的作業を24時間365日継続的に処理してくれたらどうだろうか？ その間、私たちは人間の判断を本当に必要とする仕事に集中できるのではないか？」

1つのコパイロット：コンセプトの実証

私たちは、1つのコパイロットから始めました。私専用のものです。

AI企業のIT部門には、特有の状況があります。地球上で最も洗練された動画AIモデルを構築できても、アカウントのプロビジョニングができなかったり、権限エラーによって深夜にエンジニアの作業がブロックされたり、大陸間の時差の隙間に社内ツールがダウンしたりすれば、生産性は急停止します。従来のIT部門は、チケット管理のキューとSLA（サービス品質保証）タイマーでこれに対処します。誰かが申請を送信し、それが保留され、営業時間中に人間が対応し、やり取りが発生する。このモデルは、複数のタイムゾーンにまたがって拠点が分散している場合には機能しません。

そこで私は独自のコパイロットを構築しました。それは私の役割、使うツール、優先事項を理解していました。私はそれに、チケットのトリアージ、アクセス権のプロビジョニング、アイデンティティ管理、セキュリティ監視、デバイス管理といったスキルを与えました。デモ用ではなく、実際の運用計画を処理する1つのコパイロットです。

そして、それは機能しました。数値で見る「機能した」とは以下のようなものです。日常的なアクセス要求の解決時間は、8時間から実質15分に短縮されました。オンボーディングは、新規採用者1人あたり丸一日（私が管理コンソールをクリックし続ける作業）かかっていたものが、10分間の確認作業に短縮されました。新規採用者は、入社3日目ではなく初日にすべてのツールを使えるようになります。そして現在、日常的なITチケットの60%は、人間が一度も触れることなく解決されています。残りの40%は、十分なコンテキストがあらかじめ付与された状態で私のキューに届きます。例えば、「何を確認し、何が判明し、どのようなアクションが推奨されるか」が事前に診断されています。

現在、私たちはコパイロットに24時間体制でチケットシステムを監視させています。

拡大：1つのコパイロットからネットワークへ

1つのコパイロットが機能したことで、次に思い浮かぶ当然の問いは「全員がこれを持てたらどうなるか？」でした。

そこで私たちはコミュニケーションレイヤーを構築しました。TwelveLabsの全員が、それぞれの役割、進行中のプロジェクト、使用ツール、権限を理解している個人用コパイロットを持つようにしたのです。しかし、これを単に「全員がチャットボットを持つ」以上のものにしているのは、コパイロット同士がお互いのスキルを検出し、タスクを相互にルーティングできる点にあります。

例えば、サンフランシスコが午前2時、ソウルが午後6時だとします。ソウルにいるエンジニアが、新しい社内ツールで権限エラーに遭遇しました。彼らのコパイロットは問題を認識し、私のコパイロットのプロビジョニングスキルに問い合わせて権限マトリックスを確認し、セキュリティ監視スキルと照合して障害がないことを確認した上で、アクセス権の要求を解決します。これらすべてが数分で完了します。旧世界であれば、そのエンジニアは私が目を覚まして朝にキューを確認するまでブロックされていたでしょう。新世界では、彼らが次の展開を考え終える前に処理が完了しています。

そして、信頼を担保する上で重要なのは、コパイロット間のすべての連携アクションについて、Slack上で人間の承認を必要とすることです。承認なしにコパイロットが勝手に動くことはありません。システムは高速ですが、管理外で動いているわけではありません。判断が必要な事態が発生した場合は、あらかじめ整理されたすべての文脈（コンテキスト）とともに段階的にエスカレーションされます。人間はただ意思決定を行うだけです。

トラブルシューティングも同様に機能します。誰かが「この社内アプリの挙動がおかしい」と報告したとします（正直なところ、これがチケットの約30%を占めます）。コパイロットネットワークは、その曖昧な報告をシステムログ、最近の変更、および過去の同様のインシデントと関連付けます。人間がそれを確認する頃には、「動作がおかしい」という状態は、具体的な診断結果へと翻訳されています。

単なるトラブルシューティングにとどまらない、ビルダーとしてのIT

ここからが本当に面白いところです。この取り組みは3つの原則に基づいて運営されています。「完璧さよりもスピード（数時間でリリースし、フィードバックを元に反復する）」、「デモ駆動開発（デモができないなら、やる価値があるか疑う）」、そして「AIファースト思考（タスクに取りかかる前に『AIにこれの80%を任せられないか？』と問いかける）」です。

最後の原則は、TwelveLabsにおけるITのあり方を完全に変えました。以前は、「Xを追跡するためのシンプルなダッシュボードを作れませんか？」や「Yを行うツールはありますか？」といった要望が寄せられていました。そして、その解答は常に「調べておきます」のバリエーションであり、その後2週間の調達プロセスが続くか、開発チームへの依頼が1ヶ月間バックログに放置されるかのどちらかでした。

現在はどうでしょうか。私は社内ツールを数日ではなく、数時間で構築しています。私だけではありません。「AIに80%を任せられないか？」というマインドセットのもと、社内の様々なチームがこの取り組みを通じて独自のツールをリリースしています。財務チームはダッシュボードを構築し、採用チームはソーシングアプリを構築しました。私たちはサイドプロジェクトを、本番環境に耐えうるツールへと変貌させました。AIから始め、デモをリリースし、フィードバックに基づいて反復する。完璧さよりもスピードを優先するのです。

IT部門は「折り返しご連絡します」と答える部門から、「こちらをご覧ください」と提案する部門へと変わりました。これが実現したのは、かつて私の時間の70%を奪っていたメンテナンスや火消し作業を、コパイロットたちが処理してくれているからです。

隙間の時間のために構築する

システムに関する意思決定を下す際、私は常に同じシナリオでテストを行います。「両オフィスが眠っているとき」。サンフランシスコチームはログアウトし、ソウルチームはまだ始業していません。TwelveLabsの人間が誰も働いていない時間帯が毎日必ず存在します。その時間帯に何が起きるでしょうか？

もし答えが「何もしない」であれば、それは問題です。また、答えが「人間が起きなければならない」であっても問題です。コパイロットがそれを処理すべきなのです。人間の価値が低いからではなく、人間の集中力は有限のリソースであり、真に人間の判断を必要とする事柄に割くべきだからです。午前2時に日常的なアクセス要求を承認することは、それに該当しません。新しい社内プラットフォームのアーキテクチャを決定することは、それに該当します。

私たちが眠れるように、トークンは眠りません。そして正直なところ、最近は本当によく眠れるようになりました。

Rick Mondragon はTwelveLabsのIT主幹であり、サンフランシスコとソウルにまたがるインフラおよび社内システムの運用を担当しています。