動画を探していたはずが、目を引くサムネイルを次々に開き、見たかった内容にたどり着けない。仕事に役立つ講演や技術解説を探すときにも、こうした場面はあるでしょう。AI研究者のAndrej Karpathy氏が週末に構築した「HackerTube」は、この動画選びの問題に、技術コミュニティで積み重ねられた推薦を使って取り組んでいます。

2026年11月8日付のTHE DECODERの報道によると、Karpathy氏はClaudeのOpus 5.5モデルを使い、Hacker Newsの20年分、約4,300万件のコメントを処理しました。その中から、繰り返し推薦されてきた動画6,454本を抽出したとされています。Hacker Newsは、技術や起業に関する話題が集まるオンラインコミュニティです。そこでの長年のやり取りを、動画を選ぶための材料に変えた点が今回の取り組みの中心です。



Karpathy氏はXへの投稿で、YouTube自体の推薦よりも視聴体験が大幅に良くなったと評価しています。ただし、これは同氏の利用体験に基づく見解です。利用者全般を対象にした比較結果や、推薦精度を測った数値が示されたわけではありません。

企業が注目したいのは、単に動画サイトを短期間で作れたことだけではないでしょう。大量の既存データから、特定の利用者にとって価値のある情報を選び直し、使える形で届けたことに意味があります。生成AIの活用を「新しいコンテンツを作る作業」に限定せず、すでに存在する情報への入口を整える仕事として捉える事例です。

HackerTubeの選定を理解するには、「多く再生された動画」と「議論の中で何度も薦められた動画」を分けて考える必要があります。再生回数は広く視聴されたことを示しますが、推薦のコメントには、ある課題を理解するのに役立った、説明が明快だったといった評価が含まれる場合があります。HackerTubeは、こうしたコミュニティの推薦の蓄積に着目した仕組みです。

もっとも、今回確認できる情報では、Claudeがどのような条件でコメントを選別し、動画を採用したのか、詳細は明らかにされていません。推薦理由まで評価したのか、同じ動画への言及をどうまとめたのかも不明です。「4,300万件を処理した」という規模と、「選ばれた6,454本がどのような基準を満たすか」という品質の説明は、別に受け止める必要があります。



また、長い期間にわたって推薦された動画であっても、すべての視聴者や目的に適しているとは限りません。特定のコミュニティで支持されるテーマや説明の仕方には、その参加者の関心が反映されます。技術者に評価された詳しい講演が、初学者にも理解しやすいとは限らないでしょう。古い動画では、基礎概念の説明が役立つ一方、製品の操作方法などが現在と合わなくなっている可能性もあります。

企業内で同じ発想を使うなら、推薦の多さを品質の唯一の基準にしないことが大切です。利用者の職種、前提知識、情報の更新時期といった条件を添えることで、選定結果の使い道が明確になります。HackerTubeが示すのは、人の評価をAIで再利用する方法であり、選ぶ基準そのものを不要にする方法ではありません。

HackerTubeでは、動画を選ぶ画面にも独自の判断が見られます。ログインは不要で、視聴者の注意を引くために最適化されたサムネイルの代わりに、動画の途中の1フレームを表示します。利用状態はブラウザー内に保存される仕組みです。動画の集め方だけでなく、選ぶ際に目に入る情報も変えています。

サムネイルは、内容を短時間で伝える手段であると同時に、クリックを促す表現でもあります。途中のフレームに置き換えれば、視覚的な訴求が動画選びに与える影響を抑える設計にはなるでしょう。ただし、それだけで内容の良し悪しを見抜けるわけではありません。静止画では伝わらない説明の分かりやすさや、自分の目的との一致は、別の情報で判断する必要があります。



ログイン不要という設計も、利用開始までの手間を減らします。閲覧のためにアカウントを作成する必要がなく、試しにアクセスして動画を探せるためです。ブラウザー内に状態を保存する方式は、アカウントを中心に情報を管理するサービスとは異なる構成になります。ただし、端末間の同期や組織での管理など、企業利用で気になる機能の詳細は今回の情報からは確認できません。

この設計から読み取れるのは、便利な機能を増やすだけがサービス改善ではないという視点です。利用者が「何を見るか」を決める場面に絞り、表示や操作を簡素にする選択もあります。社内向けの学習サイトなどを考える際には、機能の数より、必要な教材を迷わず選べるかを検討する手がかりになるでしょう。HackerTubeの利用感についても、Karpathy氏の評価と、自社の利用者に合うかどうかは分けて確かめる必要があります。

Karpathy氏によると、HackerTubeの構築では、データ分析からサーバーのセットアップまで、ほぼすべての作業をClaude Codeに任せたといいます。手動で行ったのは、Google CloudのAPIキーの用意、サーバーの契約、ドメインの購入だったと説明しています。APIキーは外部サービスの機能を利用するための認証情報で、ドメインはサイトの住所に当たります。

この説明で目を引くのは、AIの担当範囲がコードの記述だけにとどまっていないことです。サービスを動かすには、扱うデータを調べ、必要な処理を組み立て、実行環境を整える作業がつながっています。その広い範囲を一連の開発として任せたことで、構想を実際に使えるサイトへ移す時間を短縮したと捉えられます。



Karpathy氏は、以前なら数週間かかったようなプロジェクトを、今では数時間で実現できると述べています。これは同氏が今回の開発を通じて示した評価であり、あらゆる開発案件に同じ短縮率を適用できるわけではありません。機能の範囲や既存システムとの接続、求められる品質によって、必要な作業は変わります。

企業で参考にするなら、「AIが書いたコードの量」より「どこまで動く状態に到達したか」を見ると、成果を捉えやすいでしょう。同時に、動作する試作品と、継続運用できる業務サービスには確認事項の違いがあります。誤ったデータを取り込んだ場合の修正方法、障害時の対応、認証情報の管理などは、開発時間の短縮とは別に検討が必要です。今回の報告では運用上の検証結果までは示されておらず、開発速度の事例として読むのが適切です。

HackerTubeの後、Karpathy氏は「TristanTube」も構築しました。こちらはTristan Hume氏によるYouTubeチャンネルのリストを基に、約4万7,000本の動画を扱うサービスです。同氏は、Claude Codeへの一度の指示で、3分で作ったと説明しています。この時間は本人の報告であり、準備から公開後の確認までを含めた総作業時間かどうかは明らかではありません。

HackerTubeとTristanTubeでは、動画を集める出発点が異なります。前者は長期間のコミュニティのコメントから繰り返し推薦される動画を抽出し、後者は特定の人物がまとめたチャンネル一覧を使っています。どちらも、すでに人が残した評価や選択を、動画への入口として使う点で共通しています。



この違いは、企業が応用を考える際にも役立ちます。議論や問い合わせの履歴から役立つ資料を探す方法と、専門部署が選んだ資料一覧を使う方法では、扱う情報の性質が変わります。前者では大量の記録から何を推薦と見なすかが課題になり、後者では一覧を選んだ人の専門性や対象範囲が結果に影響するでしょう。入口となる情報源を選ぶこと自体が、サービスの方向を決めます。

また、動画数の多さだけでは、利用者にとっての探しやすさは判断できません。6,454本と約4万7,000本という数字は、それぞれの収録規模を示しますが、使いやすさの順位を示すものではないためです。用途に合う集合を作り、その中から目的の情報を見つけられるかが問われます。TristanTubeの事例は、別の情報源を使ったサービスへ素早く展開できる可能性を示していますが、その価値を確かめるには、対象者と利用目的を具体的に置く必要があります。

今回の取り組みを日本企業の業務に置き換えるなら、社内研修の動画や技術資料など、情報は蓄積されているのに探しにくい領域が検討対象になるでしょう。ただし、これはHackerTubeで報告された導入実績ではなく、仕組みから考えられる応用です。多くの情報を集める前に、誰のどの判断を助けたいのかを決めると、試す範囲を絞りやすくなります。

例えば、新しく配属された担当者が基礎を学ぶ資料を探す場面と、経験者が特定の問題を調べる場面では、薦めるべき内容が異なります。過去に評判が良かったという理由だけで同じ資料を提示しても、双方の役には立たないかもしれません。対象者と目的が決まれば、分かりやすさ、情報の新しさ、業務との関連といった評価基準も具体的になります。



試行では、利用できる範囲が明確な資料を小さく集め、AIに候補を選ばせたうえで、担当者が選定理由を確認する方法が考えられます。推薦された資料の件数だけでなく、なぜその資料が必要なのかを説明できるかを見ることが大切です。社内資料には閲覧権限の違いもあるため、集約後も誰が何を見られるかを保つ設計が求められます。

生成AIによって試作品を作る時間が短くなるほど、企画側は複数の案を実際に比べやすくなるでしょう。ただし、短時間で構築できることと、利用者の問題が解決することは別の確認事項です。HackerTubeから得られる実務上の一歩は、自社の情報をすべてAIに渡すことではありません。探すのに困っている資料群を一つ選び、利用者が必要な内容へたどり着けるかを確かめることです。その結果を見てから対象を広げれば、開発の速さを業務上の改善につなげやすくなります。