元アイドルグループ・宮本佳林さんが公開した2本のブログ記事が、アイドルファンだけでなくエンジニアや生成AIコミュニティの間でも大きな話題となっている。

テーマは「AIと一緒に10時間配信のシステムを全部作った話」と、その技術的な解説記事「HANAKIN配信システムの技術構成」。いずれも自身のYouTube生配信を支えたシステムの舞台裏を詳細に紹介する内容で、「コードを書けないアイドルがAIと協力して本番運用レベルのシステムを構築した」という実例として注目を集めている。ブログ公開後はニュースサイトでも取り上げられ、「アイドルの技術ブログ!?」という驚きの声がSNS上で広がった。(アメーバブログ(アメブロ))


10時間配信を支えたのは自作システム

宮本さんは2026年7月31日、最新シングル「HANAKIN/シャニカマー」の発売週企画として、約10時間にわたるYouTubeライブを実施した。

企画内容は視聴者参加型。

視聴者がCDを購入し、Xへ指定ハッシュタグ付きで投稿すると、その投稿数に応じてゲージが上昇し、

  • メイク道具
  • 衣装
  • 編集ソフト
  • 演出アイテム

などが順番に解禁され、最終的にはMVを完成させるというゲーム性のある企画だった。

このゲージ表示や投稿数の集計、管理画面、AIによるMV再現度採点まで、配信を支えるシステム全体を宮本さん自身が構築したという。(アメーバブログ(アメブロ))


「コードは読んでいない」

ブログの中で最もインパクトがある一文が、

コードの中身は最後まで一度も読んでいません。

という告白だ。

宮本さんはプログラミング経験者ではなく、実装には主にClaude Codeを利用。

「こういう画面を作りたい」
「管理画面を追加したい」
「ゲージを表示したい」

など、日本語でAIへ指示しながら開発を進めたという。

エラーが出ればエラーメッセージをそのままAIへ渡し、修正案を受け取る。

画面がおかしい場合はスクリーンショットを見せて修正。

つまりソースコードを書くのではなく、

「要件を伝え、動作を確認し、改善を繰り返す」

という開発スタイルだった。

これは近年急速に広まっている「Vibe Coding(AIとの対話を中心に進める開発)」を象徴する事例とも言える。(アメーバブログ(アメブロ))


技術ブログの内容が想像以上に本格的

さらに驚かされたのは技術編の記事である。

単なる「AIで作りました」という紹介ではなく、

システム構成まで公開している。

構成は概ね以下のようになっている。

  • Cloudflare Workers
  • Cloudflare KV
  • RapidAPI経由のX検索API
  • Node.js
  • Express
  • OBS
  • localhost上で動くAI判定アプリ

といった一般的なWebサービス開発でも利用される構成が採用されている。

ブログには

  • クラウド側で管理するデータ
  • ローカルで処理するデータ
  • OBSへの表示方法
  • 管理画面との接続
  • APIから取得した投稿数の流れ

まで図付きで説明されており、まるで企業エンジニアが公開する技術ブログのような内容となっている。(アメーバブログ(アメブロ))


「動けばいい」ではなく運用設計まで考えていた

記事の中で印象的なのは、

「7月31日に確実に動くこと」

を最優先に設計したという考え方だ。

ライブ配信は失敗できない。

そこで

  • API取得に失敗しても手動更新できる
  • 数字はスマホからでも変更可能
  • 管理画面でコードを書かず設定変更
  • 二重三重のバックアップ

など、本番運用を意識した設計になっている。

これは企業のシステム開発でもよく行われる考え方であり、

「美しい設計より止まらない設計」

という判断をしていた点は非常に実践的である。(アメーバブログ(アメブロ))


AIだけでは解決できなかった問題も

もちろん開発は順調ではなかった。

ブログでは苦労した点も率直に書かれている。

例えば、

海外AIサービスへの決済が通らず、

利用するAIサービス自体を変更したこと。

またX投稿数取得についても、

公式APIは高価だったため、

RapidAPI経由のサービスを採用したものの、

取得数の制限などに苦労したという。

OBSへの複数アプリ接続や、

本番環境の構築でも数々のトラブルがあり、

その都度AIへ相談しながら解決していったと振り返っている。(アメーバブログ(アメブロ))


「理解していない」と書ける誠実さ

技術ブログ冒頭には印象的な文章がある。

宮本さんは、

用語を完全には理解していません。

と正直に書いている。

コードも読めない。

専門用語もAIに教えてもらいながら理解した。

それでも

「どこで動くか」
「なぜその場所に置くか」

という設計判断は自分で行ったという。

この姿勢は、生成AI時代の新しい開発者像を象徴している。

実装はAIに任せながら、

仕様を決め、

品質を確認し、

最終判断は人が行う。

AIが万能なのではなく、

目的を明確に伝える能力や、結果を評価する能力が重要であることを示している。(アメーバブログ(アメブロ))


エンジニアコミュニティでも反響

ブログ公開後は、IT・AI業界からも反応が相次いだ。

「アイドルの技術ブログとは思えない」
「構成図まで公開している」
「Cloudflare Workersを選定しているのが渋い」
「これがAIネイティブ世代の開発なのか」

といった声がSNSで広がり、IT関係者からも高い関心を集めた。(X (formerly Twitter))

また、「コードを書けない=ソフトウェアを作れない」という従来の前提が変わりつつあることを示す実例として紹介されるケースも見られる。(shiritomo)


AI時代は「プログラミング」より「設計」が重要になるのか

今回の事例は、一人のアイドルが配信システムを作ったという話にとどまらない。

生成AIの普及によって、「コードを書くこと」そのものの価値は相対的に変化しつつある。AIが実装を支援できるようになった今、人間に求められるのは「何を作るのか」「どう動かすのか」「トラブル時にどう備えるのか」といった設計力や運用力であることが、宮本さんの取り組みからうかがえる。

実際、今回のブログではコードそのものよりも、クラウドとローカルの役割分担、本番で止めないための冗長化、管理画面による柔軟な運用といった判断が詳しく語られており、これらは現場のエンジニアが日常的に直面するテーマでもある。

AIがプログラムを書く時代になっても、「どんな体験を実現したいのか」を描き、AIへ適切に伝え、結果を検証して改善する役割は依然として人に残る。その意味で、宮本さんの事例は「AIを使って何を実現できるか」を示す好例と言えるだろう。

アイドルが公開した技術ブログが、エンジニアにとっても学びのあるコンテンツとして受け止められた背景には、こうした時代の変化があるのかもしれない。


関連リンク

By tokita