08-28 アイドルから見たAIを活用した「ものづくり」の本質-コンサルティング概要
1. 精緻な診断：「痛み」はどこに現れるか？
特定された課題： 非エンジニアによるAI開発の再現性が、まだ個人技に依存している
ビジネスへの影響：
宮本佳林さんの事例は非常に強い成功例ですが、現時点では「本人の発想力」「ファン心理の理解」「粘り強い試行錯誤」「リスク感覚」に大きく依存しています。組織として再現しようとすると、同じ成果を安定的に出せない可能性があります。
特にエンタメ、マーケティング、ファンコミュニティ領域では、このような“クリエイター主導のAI活用”は大きな武器になりますが、仕組み化しないと属人的な奇跡で終わります。
想定される根本原因：
AI開発のプロセスが明確に言語化されている一方で、まだ標準化・テンプレート化・教育プログラム化されていないことが根本にあります。
宮本さんは以下のような優れたプロセスを自然に実践しています。
アイデアをAIに相談する
実現可能性を確認する
誰かを悲しませないかを検証する
仕様書に落とし込む
運用当日の流れまで先に設計する
小さく作って検証する
セキュリティ・コスト・ファン感情を守る
本番では手動介入できる余地を残す
これは実は、かなり優秀なプロダクト開発プロセスです。ただし本人は「知識がない」と表現しており、組織側がこの価値を正しく抽出しないと、単なる“バイブコーディングの面白い話”として消費されてしまいます。
追加の所見：
率直に言うと、このセッションの本質は「アイドルがAIでサイトを作った」ではありません。
本質は、「現場の顧客理解を持つ人間が、AIによってプロダクト開発者化した」ということです。ここを見誤ると非常にもったいないです。
特定された課題： 技術理解よりも先に、運用設計・顧客体験設計が求められている
ビジネスへの影響：
宮本さんはコードが読めない、ITやAIの勉強をしていないと述べながらも、実際にはかなり現実的な運用判断をしています。たとえば、10時間配信システムでは「全部自動化もできたが、自信がないため手動でできる設計にした」と話しています。
これは極めて重要です。多くのDX案件はここで失敗します。自動化できるから自動化する。AIでできるからAIに任せる。その結果、障害時に誰も制御できなくなる。
宮本さんの判断は、技術的には素朴ですが、ビジネスリスク管理としてはかなり正しいです。
想定される根本原因：
一般的なDX推進では、技術導入が先行し、実際の現場運用・顧客感情・障害時対応が後回しになります。
一方、この事例では「ファンがどう感じるか」「スタッフがどう運用できるか」「自分が当日に何ができるか」から逆算されています。
つまり、技術主導ではなく体験主導の開発になっています。
追加の所見：
「当日にQRコードをスクリーンショットして担当者に送るだけにしてください」という要件は、非常に優れた業務要件です。
これは笑い話ではなく、現場DXの核心です。現場で使えないシステムは、どれだけ高度でもゴミ箱行きです。
特定された課題： セキュリティ・コスト管理の知識不足による潜在リスク
ビジネスへの影響：
個人情報をなるべく預からない、無料枠を使う、クレジットカード登録不要のサービスを優先する、上限を目視できるようにするなど、リスクを避ける工夫はされています。
ただし、非エンジニア主導の開発では、以下のようなリスクが残ります。
権限管理の不備
APIキーやシークレット情報の漏洩
入力フォーム経由の攻撃
Bot対策の不足
著作権・肖像権・個人情報の扱い
利用規約・プラットフォーム規約違反
想定外アクセス増による停止
外部API連携時の決済・認証トラブル
特にファン向け施策の場合、一度問題が起きると技術障害だけでなく、信頼毀損・炎上・ブランドダメージにつながります。
想定される根本原因：
AIがコード生成や設計補助をしてくれる一方で、セキュリティレビュー、法務チェック、障害設計、個人情報管理まではユーザー側の設計能力に依存しがちです。
宮本さん自身も「私はプロじゃないので」と述べており、ここには本人の慎重さと同時に、専門家サポートの必要性が見えます。
追加の所見：
宮本さんは「個人情報はなるべく預からない」という非常に賢い方針を取っています。これは初心者向けAI開発の基本原則として明文化すべきです。
逆に言えば、この原則なしに非エンジニア開発を広げるのは危険です。
特定された課題： ファン体験設計が高度だが、マーケティング資産として十分に体系化されていない
ビジネスへの影響：
今回の施策では、顧客層ごとに4つのサイトが制作されています。
知らない人向け：終末生態系診断システム
CD購入を迷っている人向け：10時間配信システム
イベント参加者向け：アンケートとボイス配布システム
いつも来てくれる人向け：全通特典動画システム
これは単なるサイト制作ではなく、ファネル設計です。
認知、興味喚起、購買後押し、参加後満足、ロイヤルティ強化までをカバーしています。非常に筋が良いです。
想定される根本原因：
宮本さんはファンとの距離感、感情の動き、購買動機を深く理解しています。
一方で、この知見が暗黙知のままだと、チームや他アーティスト、他プロジェクトへ横展開しにくくなります。
追加の所見：
「来てくれている方に何の特典もないって寂しい」という発言には、顧客ロイヤルティ設計の鋭さがあります。
多くの企業は新規獲得ばかり見て、既存顧客への“感情的報酬”を軽視します。ここは企業も見習うべきです。
特定された課題： AI活用が“技術部門の仕事”ではなくなっていることへの組織的対応不足
ビジネスへの影響：
この事例が示しているのは、AIによってプロダクト開発の入り口が大きく民主化されたということです。
今後、マーケター、営業、広報、アーティスト、マネージャー、カスタマーサポート担当者など、顧客に近い人ほどAIで小さなプロダクトを作れるようになります。
しかし、企業側にそれを受け止めるガバナンスや支援体制がなければ、以下のような問題が発生します。
野良アプリの乱立
セキュリティリスク
ブランド統制の崩壊
データ管理の混乱
成功事例の再利用不能
担当者退職によるブラックボックス化
想定される根本原因：
企業の多くは、AIを「効率化ツール」として見ています。しかしこのセッションでは、AIが「事業開発ツール」「ファン体験拡張ツール」「創造性の増幅装置」として使われています。
組織のAI活用方針が、まだこの変化に追いついていない可能性があります。
追加の所見：
建設的に挑発すると、IT部門だけでDXを考えている企業は、もう遅いです。
これからのDXは、現場の“面白いことを思いつく人”をどれだけ安全にプロダクトメーカー化できるかで差がつきます。
2. 行動への道筋：「利益」はどこから始まるか？
2.1. プロセス最適化：シンプル化で加速
非エンジニアAI開発プロセスの標準化：
宮本さんが実践している開発プロセスを、組織内で使える標準テンプレートに落とし込むべきです。
推奨する標準フローは以下です。
1. アイデアメモ
誰のためのものか
何を嬉しくするのか
どんな行動を促したいのか
2. 悲しませないチェック
ファン・顧客が不公平に感じないか
スタッフの負担が増えすぎないか
既存施策やパートナーと競合しないか
見られない人、参加できない人への配慮はあるか
コストや障害で自分たちが破綻しないか
3. 実現可能性確認
AIに構成案を出させる
必要な技術要素を確認する
無料枠・低コストで成立するかを見る
外部APIや認証の必要性を確認する
4. 仕様書化
画面一覧
入力項目
出力内容
管理画面要件
本番運用手順
障害時の手動対応
公開・終了タイミング
5. 試作
まず動く骨組みを作る
完璧を狙わず、小さく確認する
6. レビュー
セキュリティ
法務・権利
ブランド表現
顧客体験
運用負荷
7. 本番運用
手動バックアップを残す
ログや上限を確認する
緊急停止手順を用意する
8. 振り返り
利用数
購買・参加への影響
ファン反応
トラブル
再利用できる部品
期待される効果：
属人的なAI開発を、再現可能なマーケティング・プロダクト開発手法に変換できます。
特にエンタメ企業、D2Cブランド、イベント事業、コミュニティ運営企業では、施策のスピードと顧客体験の質が大きく向上します。
ファン施策を顧客ファネル別に整理する：
今回の4サイトは、顧客ステージ別に非常にきれいに分かれています。この考え方を明文化すべきです。
認知層：診断・ゲーム・シェアされやすいコンテンツ
興味層：配信連動、メイキング、参加型企画
購買検討層：購入報告が可視化される仕組み、限定演出
参加者層：アンケート、限定ボイス、当日体験の拡張
コアファン層：全通特典、累積参加報酬、限定動画
離脱予備層：再接点、思い出コンテンツ、パーソナルメッセージ
期待される効果：
単発の面白い企画ではなく、売上・参加率・継続率・ファン満足度を高める体系的な施策群になります。
「何となく盛り上がった」から「どの層にどの効果があったか」へ進化できます。
本番運用を先に設計する：
宮本さんが自然に実践している「当日に何をするかまで決めてから作る」という姿勢は、全社的な標準にすべきです。
最低限、各施策には以下をセットで用意します。
当日の操作手順
担当者別の役割
スクリーンショットやQRコードの受け渡し方法
障害時の代替手順
公開停止方法
問い合わせ対応文
SNS告知文
利用者向け注意書き
期待される効果：
現場混乱、公開ミス、顧客対応の遅れを防げます。
AIで開発速度が上がるほど、運用設計の重要性は上がります。ここを軽視すると、速く作って速く燃えます。
2.2. AIの可能性：反復から革新へ
仕様書作成支援AI：
宮本さんはAIと壁打ちしてMarkdown形式の仕様書を作っています。これを専用テンプレート化し、AIが自動で仕様書を整える仕組みにできます。
実践例：
「ファン向けに、イベント参加後に限定ボイスを配布するサイトを作りたい」と入力すると、AIが以下を自動生成します。
目的
対象ユーザー
必要画面
入力項目
データ保存要否
個人情報リスク
推奨技術構成
運用手順
障害時対応
コスト見積もり
実装プロンプト
テスト項目
これにより、非エンジニアでも初期設計の品質を引き上げられます。
セキュリティチェックAI：
非エンジニア開発で最も危険なのは、「動いたから大丈夫」と思ってしまうことです。
そこで、公開前にAIへセキュリティ観点のレビューをさせる仕組みを導入します。
実践例：
公開前チェックAIに以下を確認させます。
個人情報を取得していないか
不要なログを保存していないか
APIキーが露出していないか
入力フォームに不正文字列対策があるか
Bot対策があるか
管理画面が外部公開されていないか
データ削除方法があるか
利用規約・プライバシー文言が必要か
無料枠超過のリスクがあるか
ただし、AIレビューだけで完結させるべきではありません。重要施策では人間の専門家レビューを必ず入れるべきです。
ファン心理分析AI：
アンケート、SNS反応、コメント、配信中の反応をNLPで分析し、次の施策に活かせます。
実践例：
アンケート自由回答の感情分析
ファンが喜んだポイントの抽出
不満・混乱・要望の分類
SNSで拡散された言葉の分析
コアファンとライト層の反応差分分析
次回施策アイデアの自動提案
これにより、「肌感覚」に加えて、データに基づくファン体験設計が可能になります。
プロモーション施策自動生成AI：
新曲、イベント、グッズ、配信などに合わせて、AIがファネル別の企画案を出す仕組みを作れます。
実践例：
新曲発売に対してAIが以下のような施策を提案します。
認知向け：診断コンテンツ、Xシェア画像生成
興味向け：MV再現チャレンジ、投票企画
購買向け：購入報告連動演出
参加者向け：会場限定QRコンテンツ
コアファン向け：累積参加特典
休眠ファン向け：過去楽曲との接続コンテンツ
ここで大切なのは、AIに案を出させるだけでなく、「誰も悲しまないか」を必ず人間が確認することです。
ローコード／ノーコードとAIコーディングの組み合わせ：
すべてをコード生成に頼るより、用途によってはノーコード基盤を組み合わせた方が安全です。
実践例：
フォーム：Tally、Typeform、Google Forms
データ管理：Airtable、Notion、Google Sheets
自動連携：Zapier、Make、n8n
静的サイト：Cloudflare Pages
軽量バックエンド：Cloudflare Workers
Bot対策：Cloudflare Turnstile
コンテンツ配布：R2などのオブジェクトストレージ
分析：GA4、PostHog、Looker Studio
非エンジニア主導の場合、「全部AIでコードを書かせる」よりも「安全な既製部品をAIでつなぐ」方が現実的なケースも多いです。
2.3. 戦略的・実践的解決策：対話の次のレベル
全体／戦略：現場クリエイターを“AIプロダクトオーナー”として育成する
宮本さんのように、顧客やファンを深く理解している人材は、今後のAI時代において極めて重要です。
企業はこうした人材を単なる企画担当や出演者として扱うのではなく、AIプロダクトオーナーとして育成すべきです。
推奨する育成領域は以下です。
顧客体験設計
要件定義
AIへの指示設計
簡易プロトタイピング
セキュリティ基礎
データ取り扱い
コスト管理
障害時対応
法務・権利の基本
効果測定
技術者にする必要はありません。
重要なのは、「作りたい体験を安全に形にできる人」にすることです。
全体／戦略：AI開発ガバナンスを“禁止”ではなく“安全な挑戦”の仕組みにする
非エンジニアがAIで開発できる時代に、「勝手に作るな」と止めるだけでは競争力を失います。
必要なのは、禁止ではなくガードレールです。
推奨するガードレールは以下です。
個人情報を原則取得しない
決済を直接扱わない
外部公開前にチェックリストを通す
APIキー管理ルールを決める
管理画面には認証を必須にする
無料枠・上限・アラートを設定する
公開期限と削除期限を決める
著作権・肖像権・楽曲利用を確認する
ファン向け文言は本人・チームが確認する
重要施策は専門家レビューを入れる
これにより、スピードと安全性の両立が可能になります。
全体／実践：宮本流AI開発メソッドを研修コンテンツ化する
このセッション内容は、企業研修やクリエイター向け講座として非常に価値があります。
特に「コードが読めなくても、何を考えれば安全に価値を作れるか」という観点は、多くの組織に刺さります。
研修構成案は以下です。
1. AIで何が作れるかを知る
2. 顧客・ファンの“嬉しい”を設計する
3. 誰も悲しませないチェックを行う
4. 仕様書をAIと作る
5. 小さくプロトタイプを作る
6. セキュリティとコストを守る
7. 本番運用を設計する
8. 効果測定して次に活かす
これはエンタメ業界だけでなく、小売、教育、観光、飲食、地域イベント、D2Cブランドにも応用可能です。
全体／実践：ファン体験施策の再利用可能な部品ライブラリを作る
毎回ゼロから作るのではなく、よく使う施策をテンプレート化します。
例：
診断サイトテンプレート
QRコード限定配布テンプレート
アンケート＋特典配布テンプレート
キーワード蓄積型特典テンプレート
購入報告可視化テンプレート
配信連動演出テンプレート
限定動画公開テンプレート
SNSシェア画像生成テンプレート
来場者限定メッセージテンプレート
これにより、次回以降の施策立ち上げ時間を大幅に短縮できます。
宮本さんの言う「1時間で作り終わった」という状態を、組織全体で再現しやすくなります。
全体／実践：効果測定の設計を追加する
今回の話では、盛り上がりやファンの反応は語られていますが、定量的な効果測定については限定的でした。
次のステージでは、企画ごとにKPIを設定すべきです。
推奨KPI：
サイト訪問数
診断完了率
SNSシェア数
アンケート回答率
ボイス取得率
イベント参加率
CD購入転換率
配信視聴維持率
コアファン参加率
再訪率
問い合わせ件数
トラブル件数
施策あたり制作時間
施策あたりコスト
感情を大事にしつつ、数字で学習する。ここまで行くとかなり強いです。
全体／実践：専門家サポートの軽量レビュー体制を作る
宮本さんのような現場主導の開発を止めずに安全性を高めるには、重たい承認プロセスではなく、軽量レビューが必要です。
推奨体制：
企画者：アイデア、ファン体験、文言を設計
AI：仕様書、コード、テスト項目を支援
技術レビュー担当：セキュリティ、構成、運用性を確認
法務・権利担当：規約、権利、個人情報を確認
マネージャー：公開判断、ブランド整合性を確認
運用担当：当日の手順と問い合わせ対応を確認
ポイントは、承認で創造性を殺さないことです。
速度を落とさず、事故だけ減らす。これが理想です。
次のステップ：変革はどこから始まるか？
今回のセッションから見える最大の機会は、AIによって「顧客を一番理解している人」が直接ものづくりに参加できるようになったことです。
次に進めるべき優先アクションは以下です。
1. 宮本さんの開発プロセスをテンプレート化する
2. 「誰も悲しませないチェックリスト」を正式な企画レビュー項目にする
3. 非エンジニア向けAI開発ガイドラインを作る
4. セキュリティ・コスト・法務の軽量レビュー体制を整える
5. ファン施策テンプレートを部品化する
6. 各施策にKPIを設定し、効果測定する
7. 成功した仕組みを他プロジェクト・他アーティスト・他ブランドへ横展開する
カルロス・シルバ・ジュニオールとしては、ここから関係者と一緒に「どの施策を最初に標準化するか」「どこまでをAIに任せ、どこから人間が責任を持つか」「短期で成果が出る領域はどこか」をディスカッションし、優先順位を明確にすることを提案します。
変革は、大きなDX構想書からではなく、現場の「これがあったら嬉しいよね」から始まります。
今回の事例は、その小さな発想がAIによって一気にプロダクト化される時代に入ったことを示しています。企業がやるべきことは、その芽を潰すことではなく、安全に、速く、何度も咲かせる仕組みを作ることです。