宮本佳林さんがClaude Codeで作った配信システムに学ぶ AI時代のものづくり
「配信するだけ」なら、YouTubeやTikTokの機能で十分です。でも「この企画を実現する配信」となると、話が変わります。
元Juice=Juiceの宮本佳林さんが、自身のブログで明かした話が、この週末Xでかなり話題になっていました。プログラミング経験ゼロ、コードは1行も自分で書いていない。それでもClaude Codeを中心にAIと一緒に、10時間の生配信を支える専用の周辺システムを、自分で設計して組み上げたという話です。
配信そのものではなく、配信を成立させるための裏側を作った。ここに、AI時代のものづくりの本質が詰まっている気がします。
既存のプラットフォームでは、この企画は実現できなかった
まず何が起きたか。2026年7月31日、5thシングル「HANAKIN／シャニカマー」の発売週に、朝8時から夜18時までの10時間、宮本さんはYouTubeで生配信をしました。企画は「みんなと協力して家にあるものでMV再現配信」。視聴者がCDを買ってハッシュタグで投稿するたびに、メイクや衣装、編集アプリが少しずつ解放されていき、宮本さんが自宅でMVを再現していく、という参加型の仕組みです。
この企画、既存の配信サービスの標準機能だけでは成立しません。CD購入報告の投稿数をリアルタイムで数え、閾値に達したら演出を解放し、本家MVとその場で再現した動画をAIに比較・採点させる。つまり、配信そのものの外側に専用のシステムが要る企画でした。だから宮本さんは、YouTubeの枠の中で我慢するのではなく、システムを自分で作る方を選びました。
4つのシステムを、コードを書かずに組み上げた
技術編のブログによると、構築したのは大きく4つです。非エンジニア向けに噛み砕いて紹介します。
- リアルタイムHUD: 配信画面下部に常時表示される2本のゲージ(CD購入報告数のSUPPLY、盛り上がり度のHYPE)
- X投稿の集計: ハッシュタグ投稿を検索APIで拾い、管理画面のボタンを押したタイミングで取得してHUDに反映
- AI採点アプリ: 本家MVと、その場で再現した動画を読み込ませ、AIが再現度を採点してコメント付きで表示
- 管理画面: スマホからでも数値を手動で操作できる、本番用の操作パネル
裏側の設計もしっかりしています。数字を扱う部分はクラウド(Cloudflare Workers + KV)に置き、動画のような重いデータを扱うAI採点だけは手元のパソコンで動かす。「みんなで見る数字はクラウドに、重い処理は手元に」という役割分担を、本人が意識して設計したと書かれています。ここは経験のあるエンジニアが読んでも筋の通った判断です。
光ったのは技術力ではなく、壊れないための備え
読んでいて特に唸ったのが、当日を見据えた設計判断です。
「何かが壊れても配信は止まらないようにする」。これが一番大事にした方針だったそうです。実は当初、X投稿の取得は10分おきの自動ポーリングで組む予定でした。ところが使っていたCloudflareの無料プランでは自動実行の機能が使えないと分かり、方針転換。管理画面に「Xから取得」ボタンを置き、押したタイミングだけ数字を取りに行く方式に変えたそうです。これが結果的に、盛り上がりに合わせて取得タイミングを調整できる利点にもなりました。数字がうまく取れなくても手動で動かせるよう、取得方法や保険を何重にも用意しておく。生配信は一発勝負なので、自動化に頼りきらないという判断です。
もうひとつ印象的なのが、土壇場でのAIプロバイダの乗り換えです。当初Claude APIで実装を進めていたものの、クレジット購入の決済が何度やっても失敗する(住所表記を直しても通らず、同じカードで他サービスの決済は通る、という状況)。原因の切り分けに見切りをつけ、残り日数を考えてOpenAI APIに乗り換えたところ、あっさり解決したとのこと。実装の変更点はAPIの呼び出し部分だけで、設計自体は変えずに済んだそうです。特定のサービスに固定しない作りにしていたことが、土壇場で効いたという話でした。
本人が語る核心 「技術力より、言葉にできるかどうか」
技術編の冒頭で、宮本さんはこう書いています。記事に出てくる用語は完全には理解していない、実装はすべてClaude Codeに任せていてコードは読んでいない、と。それでも、何がどこで動いていて、なぜその置き場所を選んだのか、当日どこでつまずいたのかは、自分で判断してきたそうです。
そして企画編の結びに、こう書いています。
コードが書けなくても、作りたいものが明確なら、AIと一緒にここまで作れる。
大切なのは「何を作りたいか」「どう動いてほしいか」を具体的に言葉にできることだった、と。しかも、いきなり作り始めたのではなく、事前に仕様書を用意し、その仕様書自体もAIと壁打ちしながら作ったそうです。ディレクトリ構成やデータ構造、フェイルセーフの方針、当日の運用フローまで言葉にしてから「この通りに実装して」と渡す。最初の設計に時間をかけたことが、後半の開発速度に効いたと振り返っています。企画を考え、必要な機能を洗い出し、優先順位をつけて、ひとつずつ形にしていく。その過程は、プログラミングというより「ものづくり」そのものだった、というのが本人の総括です。
中小企業にとっての意味 企画力が、そのまま実行力になる
この話を、システム開発の逸話として消費するだけではもったいないと思います。アイデアを形にする力は、システムだけの話ではありません。
- 顧客向けの案内ページを、他社の見よう見まねではなく自社の企画そのままの形で作る
- 社内の集計作業を、既存のExcelテンプレートに合わせるのではなく、自分たちの業務フローに合わせて作る
- イベントの受付や来場者とのやり取りを、汎用ツールの制約に収めず、やりたい体験に合わせて組む
いずれも「既存の仕組みに企画を合わせる」のではなく、「企画に合わせて仕組みを作る」という発想です。これまでは開発リソースがある会社だけの特権でしたが、AIコーディングツールの進化で、企画力さえあれば実行力を後から獲得できる時代になりつつあります。非エンジニアの代表が自社システムを直せるようになった話でも書きましたが、AIが補完しているのは「コードを書く手」だけでなく、「アイデアを形にする経路」そのものだと感じます。
手放しでは真似できない部分も 注意点
一方で、素直に感心して終わるには、注意しておきたい点もあります。
- 決済トラブルのような、技術外の不確実性は普通に起きます。今回はプロバイダを乗り換えて解決しましたが、本番直前にこの手のトラブルが起きる前提でスケジュールを組む必要があります
- 「何を作りたいか」を言葉にする力こそ、実はいちばんのボトルネックです。プログラミング知識がなくても作れるとはいえ、要件を具体的に分解して指示する力がなければAIも動けません。ここは訓練が要ります
- セキュリティへの目配りは最低限必要です。技術編では書き込み系のAPIをすべて認証トークンで保護したとありますが、こうした基本的な防御をAI任せにせず、人が意識して確認する姿勢は欠かせません。プロンプトインジェクションの記事で書いたとおり、外部からの入力を扱うシステムほど、この意識が重要になります
「誰でも簡単に」ではなく、「企画力と最低限の注意力があれば、技術力の壁は越えられる」。この距離感で受け止めるのが正確だと思います。
まとめ: 作りたいものを、まず言葉にする
宮本佳林さんの事例が示しているのは、AIが「プログラミングを代行してくれる」という話にとどまりません。企画を、既存の枠に妥協せず形にする力そのものが、コードを書けなくても手に入る時代が来ているということです。
自社に置き換えるなら、まず問うべきは「どのツールを使うか」ではなく「本当は何を実現したいか」です。その答えが具体的な言葉になった時点で、実は半分できています。今日、社内で「本当はこうしたいけど、既存のツールでは無理だから諦めている」ことをひとつ思い出してみてください。それが、次に形にできるものかもしれません。