コードを書かず10時間配信を作った｜AI共創で必要だった4つの設計

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、アイドルの宮本佳林さんが10時間の配信システムを自分の手で作った話を紹介します。

配信本番でゲージが一目盛り上がるたび、画面の向こうでファンとの距離が縮まっていく——そういう仕組み。正直、外部の制作会社にもエンジニアにも発注しなかった、という時点で驚きました。プログラミング経験がゼロのまま、AIに直接指示を出して、自分の手で作り上げた話。

「コードは一行も自分で書いていません。」
宮本佳林さんのブログより

「発売週金曜日、なにか出来ないか」——一言から生まれた10時間配信

宮本佳林さんの10時間配信は、綿密な企画書からではなく、担当者どうしの一言から始まりました。

「発売週の土日にイベントが出来なかったのもあり、発売週金曜日なにか出来ないか」
宮本佳林さんのブログより

私はこの一文に、経営者が忘れがちな順番を見ます……多くの現場では「何を作るか」を先に決めてから、日程に当てはめる。宮本さんの場合は逆でした。まず「5thシングル発売週の金曜日」という一日が先に決まっていて、そこに何を差し込めるかを後から考えています。目的よりも先に、いつ・誰と分かち合う場面を作るかが決まっていたわけだ。私も以前、3つのAIを連携させて30分でLPを1本作りきる企画を組んだことがあります。あのときも最初に決めたのは技術構成ではなく、公開する時間と、誰に見せるかという締切でした。時計の針が動く前提で指示を出すと、AIへの言葉は自然と具体的になる。「かっこいいLPにして」ではなく、「30分後に、この商品を初めて知る人がスクロールを止める1行を上に置いて」という言い方になるからです。抽象的な理想を語っている時間がないと、要求は勝手に具体化されていく。宮本さんが「なにか出来ないか」という短い言葉からAIとの対話を始められたのも、金曜日という締切がすでに具体化を後押ししていたから——だと考えています。

今日の仕込み：次に控えている締切を一つ選び、そこに「何を差し込めるか」を一文で書き出してみてください。

四つの仕組みは、AI共創の配信企画から逆算されていた

2026年7月31日、朝8時から夜18時までの10時間YouTube生配信のために、宮本さんは四つの仕組みを用意しました。

1. リアルタイムゲージ（HUD）：「SUPPLY」（CD購入報告投稿数）と「HYPE」（応援投稿数）の2本。一定数を超えると「衣装 解禁！」のような演出が出て、次の解禁項目と必要数も表示される
2. 管理画面：配信者の手元デバイスから操作する仕組みです。配信しながら数字を調整したり、テロップを書き換えたりできます。配信画面そのものには直接触らない設計
3. X投稿数自動カウント：2つのハッシュタグの投稿数を、ボタンひとつで取得できる機能
4. AI採点システム：本家のMVと、宮本さんがその場で再現した動画をAIに見せて、構図・衣装・照明などの項目ごとに点数をつけてもらう仕組み

私も以前、複数のAIエージェントに記事執筆とSNS運用を任せていた時期があります。12日間で803本の記事が生まれたなんて、自分でもちょっと信じられない話でした。フライホイール（回すほど勢いがつく仕組み）が、たまたま噛み合った。あのとき私が実際にやっていたのは、AIから届く「この方向で合っていますか」という質問に、一つずつ答えることだけでした。書く量を増やそうとして頑張ったわけではなく、答えるスピードを上げていったら、自然と量が積み上がっていった感覚です。人間が縦に掘り、AIが横に広げる。宮本さんの四つの仕組みも、機能が先に並んでいたのではなく、「ファンとの距離を縮めたい」という一点から逆算されて広がっていったのだと、私は読んでいます。ゲージが上がる、演出が出る、採点が返ってくる。どれも、ファンの行動を数字に変えて、その数字がまた画面の中の何かとして返っていく往復です。この往復を設計したのが本人だった、という点に意味があると思う。四つの機能を別々の担当者に発注していたら、この往復のテンポは間違いなく遅くなっていたはずです。

今日の仕込み：自分の仕事の中でお客さんに見えている数字を一つ書き出し、それが増えると誰が一番喜ぶかを考えてみてください。

共有する数字はクラウド、重い動画は手元へ分けた

配信を止めないために、宮本さんはデータの置き場所も先に設計していました。

「配信しながら数字を調整したり、『今やっていること』のテロップを書き換えたり」
宮本佳林さんのブログより

複数端末から同じ数字を見るゲージと投稿数はクラウドへ置き、動画を読み込むAI採点は手元のPCで動かす——ぶっちゃけ、これは近所の町中華の厨房のやり方に似ていると思います。あの店では、客席から見える黒板に「本日の売り切れ」を書き出す一方、寸胴鍋で炊いているスープの出汁は厨房の奥に置いたまま。全員が見る必要のある情報は表に出し、重くて手間のかかる仕込みは奥に残す。クラウドかローカルかを流行で選ぶのではなく、誰が何を見る必要があるかという役割から逆算する発想です。私が複数のAIエージェントへ記事執筆やスケジュール管理を任せているときも、進捗として共有する部分と、下書きをまだ練っている部分は意図的に画面を分けています。先週も、公開予定の記事一覧はチーム全員が見る共有シートに置いたが、書きかけの下書き5本はまだ自分の手元のフォルダに置いたまま。同じ場所に置くと、確認すべき数字と、まだ人に見せたくない試行錯誤が混ざってしまうからです。

宮本さんの配信でも、もし全部の処理を1台のパソコンに集中させていたら、AI採点が動画を読み込んでいる間、ゲージの表示まで一緒に固まっていたかもしれません。役割ごとに置き場所を分けておくと、一つが重くなっても、他の部分は止まらずに動き続ける。私が記事の下書きと公開済み記事の管理画面を分けているのも、下書きの処理が重くなっても、すでに公開している記事の表示には影響が出ないようにするためです。

今日の仕込み：扱っているデータを「人に見せるもの」と「まだ見せたくないもの」に分け、今日中に置き場所を決めてみてください。

壊れても止めないため、手動操作を残した

自動化に全部を預けると、壊れた瞬間に配信が止まります。宮本さんはそこに手動の逃げ道を残していました。

「各カメラやアプリをOBSに接続していくのもかなり大変でした」
宮本佳林さんのブログより

決済の失敗、投稿数取得の不安定さ、OBS接続の手間。どれも本番前には歓迎したくない出来事です。しかもね、宮本さんはその全部を隠さずに「大変でした」と書き残していました。私が運用しているAGI Cockpitというシステムでも、似た設計をしている。hookと呼ぶ自動チェックが処理の途中で異常を見つけると、そこで先へ進むのを止め、人間の承認を待つ仕組みにしています。たとえば記事を外部へ公開する直前の一手だけは、どれだけ自動化が進んでいても必ず人間の最終確認を挟むようにしています。全部を自動化に任せてしまうと、壊れた瞬間に誰も気づけないまま処理が進んでしまうから。決済の失敗や取得制限があったからこそ、宮本さんの本番中の保険は厚くなったはずです。うまくいかない前提で先に手動の逃げ道を作っておくと、実際にうまくいかなかったときに慌てずに済みます。

この考え方は、システムだけの話じゃない。私が毎朝のLIVE配信を任せているチームでも、機材トラブルが起きた回だけ、事前に決めておいた「音声だけで続行する」という代替案がそのまま活きました。代替案を決めていなかったら、その回は配信そのものを止めていたと思います。壊れることを恐れて何も作らないより、壊れたときの逃げ道を先に一つ用意しておくほうが、結局は前に進める。

今日の仕込み：本番で一番止まってほしくない工程を一つ選び、5分で手動の代替手順を書いてみてください。

コードを書かず、指示と確認だけは必要だった

本人はコードの中身を最後まで一行も読んでいません。それでも、指示と確認という仕事だけは最後まで残ったまま。

「その過程は、プログラミングというより『ものづくり』そのものでした。」
宮本佳林さんのブログより

この言葉に、私は自分の実感を重ねてしまう……3つのAIを連携させて30分でLPを1本作りきる企画を組んだとき、画面に文字と画像が並んでいくのを見ながら、台本を読み上げていたのは私自身でした。誰かに発注していたら、あの手元の感覚は私のものにはならなかったと思う。宮本さんが「指示」と「確認」の二つだけを自分で担ったように、私もこの企画では原稿の一字一句をAIに書かせながら、出てきた文章を自分の声で読み上げ、引っかかる箇所だけをその場で直しました。コードの中身を読む必要はない。でも、出てきたものを自分の目と耳で確かめて、違和感に気づく作業だけは、誰にも任せられませんでした。

指示と確認は、似ているようで役割がまったく違う。指示は「こうしてほしい」という願望を言葉にするだけの作業――慣れれば誰でもできます。確認は、出てきたものと自分が本当に欲しかったものとの間にあるズレを、自分の感覚で見つける作業。私が原稿を声に出して読むのも、目で読むだけでは気づけない、リズムのズレを耳で拾うためです。宮本さんがAI採点システムを使い、本家のMVと自分の再現映像を並べて点数をつけさせていたのも、この確認の作業を仕組み化した例だと思う。

今日の仕込み：AIに任せた作業を一つ選び、出てきた結果を自分の目で5分だけ確認する時間を今日つくってください。

「繋がっていく感覚」——発注では買えなかったもの

配信を終えた宮本さんは、こう振り返っています。

「自分で作ったシステムが、目の前でファンのみなさんと繋がっていく感覚は、何ものにも代えがたいものでした。」
宮本佳林さんのブログより

「繋がっていく感覚」という言葉に、私は立ち止まりました——発注していたら、宮本さんが受け取ったのは「動くシステム」だけだったはず。自分の手で作ったからこそ、動いた瞬間にファンと繋がる感覚まで、一緒に手に入ったのだと思います。私にも似た記憶がある。中卒で高校にも行かず、独学で覚えたホームページ制作を初めて仕事にした年、自分が作った1枚のページを見た、会ったこともない誰かが、大きな買い物を決めてくれたことがありました。画面の向こうで何かが動いた、という感覚は、あの時から変わっていない。技術の中身には長い距離がありますが、「自分で作ったものが、誰かを動かす」という一点だけは、宮本さんの話とまっすぐ繋がっています。

「コードが書けなくても、作りたいものが明確なら、AIと一緒にここまで作れる。これが今回いちばん伝えたいことです。」
宮本佳林さんのブログより

この一文を読んで、私は自分の毎朝の作業を思い出しました。今朝も、配信の台本をAIに書かせながら、要らないところを削り、必要な一言を足した。作業時間そのものは短くても、「これを届けたい」という中身は最初から最後まで自分の中にありました。作りたいものが明確であれば、AIとの往復はむしろ速くなる。逆に、作りたいものが曖昧なままAIに頼ると、返ってくるものも曖昧になります。宮本さんの言葉は、技術の話ではなく、この順番の話をしているのだと私は受け止めている。

今日の仕込み：「発注ではなく自分で作りたい」と感じている作業を一つ、今日中に書き出してみてください。

実践で外さない境界

配信システムは、本番で一度動いただけでは完成といえません。宮本さんご自身も、こう書き残しています。

「取得数なども不安定だったりして今後の課題」
宮本佳林さんのブログより

操作する人、見る人、データの流れをあらかじめ分け、それぞれの機能に停止条件を決めておく必要がある。自動取得が失敗したときに手動の値へ戻せるか、クラウドが落ちたときに配信そのものを続けられるか——ここが一番効いてきます。決済が絡む部分は、テストであっても勝手に実行せず、必ず契約者本人の承認に戻す。X投稿数の取得結果も、完全な全件数だとは断定しません。動画やファンの投稿をAIに渡す場合は、利用目的と保存範囲を先に確認する。完了の条件は、四つのシステムの役割と、手動の逃げ道と、当日の操作担当が一枚で読めることです。公開本番は、リハーサルがうまくいった後も、別の人間の最終確認を必ず挟みます。私が記事を公開するときも同じで、下書きが仕上がった直後にそのまま公開ボタンを押すことはない。一度別の画面でプレビューを開き、リンク切れや誤字がないかを見てから、最後にもう一度「これで出す」と自分で判断する一手を残しています。

今日の仕込み：今の仕組みの中で「止まったら誰が代わりに操作するか」が決まっていない工程を一つ、今日中に書き出してみてください。

まとめ——真似すべきは、ツールではなく頼み方

宮本さんが作ったゲージは、ファンの行動を数字に変えて、また演出として返す小さな仕組みです。大がかりな技術じゃない。それでも、それを自分の手で作ったという一点が、配信を見ていたファンにも、この記事を書いている私にも伝わりました。経営者の仕事の中にも、「本当は自分でやりたいのに、忙しさを理由に発注や既製ツールで済ませている」ものが、きっと一つはあるはずです。それを取り戻す方法が、今はAIという形で手元にある。真似すべきは宮本さんが使ったAIツールそのものではなく、「発注せずに、自分で頼んでみる」という一つの選択です。頼み方さえ言葉にできれば、あとはAIが横に広げてくれる。今日ここまで読んで、まず1つだけ選ぶなら、締切を先に決めることをおすすめします。締切がないまま「いつかAIで作ろう」と思っている作業は、多くの場合、いつまでも動き出しません。

よくある質問

関連記事