AI活用事例読了 6 分

宮本佳林、プログラミングゼロでAIと10時間配信システム自作

Shiritomo編集部 @shiritomoAI_jp 2026年8月2日更新

「コードの中身は、最後まで一度も読んでいません」。
ハロー！プロジェクト出身のアイドル、宮本佳林さんは、自身のブログでそう振り返っています。
それでも8時から18時まで10時間の生配信を支えるシステムを、丸ごと自分の手で完成させました。
SNS運用やコンテンツ制作にAIを使っている人なら、「専門知識がなくても道具を作れる時代」がどこまで来ているのか、この事例で具体的にイメージできるはずです。

先に結論をまとめると：
– 宮本佳林さんは5thシングル発売記念の10時間配信で、AI（Claude Code）に日本語で指示を出すだけでゲージ演出・管理画面・投稿カウント・AI採点の4システムを構築しました
– コードを一行も書かず、決済トラブルやAPI制限などの実務的なエラーもAIとのやり取りで乗り越えています
– 「知識より、何を作りたいかを言葉にできる力が差別化になる」という受け止め方ができる事例です

何が起きたのか

きっかけは、5thシングル「HANAKIN／シャニカマー」の発売週企画でした。
土日はイベントが立て込むため、7月31日の金曜日に「みんなと協力して家にあるものでMV再現配信」と題した10時間生配信を実施。
ファンがCDを購入したりハッシュタグで投稿したりするたびに、画面上のゲージが上昇し、一定量を超えると衣装やメイク、編集アプリが段階的に解禁されていく仕組みです。
プログラミング教育を受けたことのないアイドル本人が、この演出を支えるシステムをすべて自作したという点が、コンテンツ制作の関係者の間で注目を集めました。
ただ、「AIで作った」という一言だけでは、実際にどこまで本人の手が入っていたのか判然としません。
そこで公式ブログの記述をもとに、制作の中身を確かめてみました。

調べて分かったこと

4つのシステムは何を実現したのか？

本人のブログによると、配信のために用意されたのは次の4つです。
1つ目は配信画面下部に表示される「HUD（画面に常時表示される情報パネル）」で、CD購入報告の投稿数を示す「SUPPLY」ゲージと、応援投稿数を示す「HYPE」ゲージの2本が動きます。
一定数を超えると「衣装解禁」といった演出が発動し、次に必要な件数まで表示される凝った作りです。
2つ目はスマートフォンやサブPCから遠隔操作できる管理画面で、数字の手動調整やテロップの変更、AI採点結果の入力までこの画面から行えます。
3つ目は指定した2つのハッシュタグの投稿数をボタン一つで取得し、自動的にゲージへ反映させる仕組み。
4つ目は、本家のミュージックビデオと視聴者が撮影した再現動画をAIが「構図」「衣装」「照明」といった項目ごとに採点し、結果を配信画面に表示するシステムです。
ファン参加型企画のために、裏側でこれだけの仕組みが同時に動いていたことになります。

プログラミング未経験でもアプリが作れる理由は？

これを支えたのが、Anthropic社が提供する「Claude Code（ターミナル上で日本語などの自然な文章の指示だけでプログラムを作成・修正できるAIツール）」です。
「こういう画面が欲しい」「この機能を追加して」と伝えると、AIが実際にコードを書いて形にしてくれると本人は説明しています。
この「詳細な仕様書を書かず、AIとの対話だけでソフトを作る」開発スタイルは「バイブコーディング（vibe coding：雰囲気や感覚を伝えるだけでAIにコードを生成させる手法）」と呼ばれ、ここ最近エンジニア以外の利用者にも急速に広がっている手法です。
宮本さんも「大切なことは『何を作りたいか』『どう動いてほしいか』を具体的に言葉にできることでした」と、コードそのものではなく要求を明確にする力が重要だったと振り返っています。
指示と確認を繰り返すだけで、複雑な配信システムが実用レベルまで仕上がった点は、非エンジニアによるツール開発の一つの到達点と言えそうです。

実際にどんな壁にぶつかったのか？

もちろん、すべてが順調だったわけではありません。
ブログでは複数のつまずきが具体的に語られています。
まず、海外サービス経由のクレジットカード決済が何度も失敗し、最終的にAIの利用プロバイダを変更することで解決したといいます。
次に、投稿数の自動カウントでは、X公式APIの個人向けプランでは同時に取得できる投稿数に制限があり、「本番運用でも難しさを感じた」と本人が明かしています。
この対策として、自動取得が失敗しても手動で数値を調整できるバックアップ手段を管理画面側に用意していました。
さらに、複数のカメラや配信アプリをOBS（配信・録画用ソフト）に接続する作業も「かなり大変だった」とし、「そのたびにAIに相談しながらひとつずつ潰していきました」と述べています。
派手な成功談だけでなく、こうした地道なトラブルシューティングの積み重ねがあったことが、ブログの記述からうかがえます。

セキュリティ面の課題はなかったのか？

決済情報やAPIキーを扱う自作システムを個人が短期間で組み上げる場合、認証情報の管理や外部公開時の対策が手薄になりやすいという指摘は、AI開発の界隈でしばしば聞かれます。
今回の配信システムについても、ネット上ではそうした一般論としてのリスクに触れる声が見られました。
宮本さん自身は「何かが壊れても配信は止まらないようにする」ことを意識し、自動取得が止まっても手動操作に切り替えられる設計にするなど、障害時の備えを講じていたことをブログで明かしています。
個人開発ならではの工夫として、完璧な設計よりも「止まらないこと」を優先した判断は、実務的な視点として参考になりそうです。

Shiritomo編集部の考察：明日から意識したいのは「言葉にする力」

この事例で目を引くのは、AIが「コードを書く人」ではなく「翻訳者」として機能している点です。
宮本さんがやったのは、企画の意図やファン体験の設計を明確な言葉にすること。
技術力そのものより、頭の中の構想を具体的な要求へ変換できるかどうかが成果物の質を左右するという構図は、今後のコンテンツ制作全般に当てはまるはずです。
SNS運用やイベント企画の担当者にとっての示唆は2つあります。
1つは、「こんな企画をやりたい」という漠然としたアイデアを、画面構成や動作条件のレベルまで具体化する訓練を積むこと。
もう1つは、AIに任せる範囲と人が判断する範囲（今回で言えば「配信を止めない」という優先順位づけ）を事前に切り分けておくことです。
ツールの民主化が進むほど、差がつくのは技術ではなく企画力とディレクション力になっていくのではないでしょうか。