「現場の肌感覚」をAIという実行力に直結させるアプローチは、あらゆる高度な専門領域においてパラダイムシフトを起こします

宮本佳林さんのAI活用から考える企画力
本業の経験とAIエージェントの協働をめぐる対話

全10章
2026年9月9日
主題：宮本佳林さんの配信システム・企画力・AIエージェントとの協働

第1章　動画レポート――宮本佳林さんがAIで配信システムを自作した件

本章は、この対話の出発点となったYouTube動画レポートである。アイドルの宮本佳林さんがAIで配信システムを自作した件について、「何がすごいのか」を本業エンジニアが一般向けに解説した動画の内容を整理したもので、作成日は2026年9月8日。第2章以降の対話は、このレポートを読んだところから始まる。
1. 動画の基本情報
動画のタイトルは「宮本佳林さんがAI使って配信システムを自作した件、これがどれだけすごい事か、一般の方向けに本業エンジニアがわかりやすく解説します」。チャンネルは「Yattemiranba - Try First Cat」（現役IT猫エンジニアが送る、AIとIT業界よもやまトーク番組）で、公開日は2026年8月4日、再生時間は35分07秒、視聴回数は約4.1万回（2026年9月8日時点）である。URLは https://www.youtube.com/watch?v=vXt1-1fYp-0。参照元は宮本佳林さん本人のブログ記事（Amebaブログ）で、それを画面に映しながら読み解く形式になっている。
本動画は、現役のエンジニアを名乗る配信者（猫のアバターで登場）が、アイドルの宮本佳林さんが自身のYouTube10時間生配信のために、コードを一切書かず・見ずにAIを使って配信支援システムを自作した件について、「エンジニアでない人にはどこがすごいのか分からない」という知人のリクエストに応えて解説したものである。配信者自身は宮本さんのことを本件で初めて知ったと述べており、彼女のブログに書かれたシステムの全体構成図を上から順にたどりながら、各技術要素の意味と、その選択に表れている「センス」を語っていく構成になっている。
2. 要旨
配信者の主張は大きく三つに整理できる。第一に、プログラミング経験のない人がAIだけで、シニアエンジニアが数十年かけて到達するのと同等の成果物を作れてしまったこと自体が業界にとって衝撃であること。第二に、成果物の中身を見ると、Cloudflare Workers／KVの採用、重い処理と軽い処理の切り分け、フレームワークを使わない素のHTML＋バニラJSという選択など、単にAIに任せただけでは出てこない技術的判断のセンスが随所に光っていること。第三に、それらの技術判断が「7月31日の本番で確実に動くこと」という目的から逆算されたものであり、企画・設計・実装・運用を一人で担いきったプロジェクト遂行力とマネジメント力こそが真に評価されるべき点であること。
結論として配信者は、この事例を「人間の限界が引き上げられた」「アイドル界の大谷翔平」と最大級の言葉で評価し、AIを使いこなせる人にとっては人類のポテンシャルが一段上がる話だとして、まだAIに触れていない視聴者に「是非触ってみるべき」と呼びかけて動画を締めている。
3. 内容の詳細（章立てに沿って）
3.1 背景：IT業界で今注目されるアイドル（0:00〜）
宮本佳林さんが自作したのは、自身のアイドル活動としてのYouTube生配信の「裏側」で配信を支える仕組みである。10時間に及ぶ生配信企画に対し、リスナーからのSNS投稿を画面に表示したり、何らかの集計結果をリアルタイムに表示したりする機能を、自作のアプリの中で実現した。配信者によれば、本人のブログにはそれ以上に多くの機能が余すことなく解説されており、それをエンジニアでない人向けに翻訳するのが本動画の目的である。
3.2 コードを見ずにAIでシステム開発（2:47〜）
宮本さんはAIを使ってプログラミングをしており、自身では一切コードを書いておらず、見てもいないという。配信者はこれを「我々エンジニア業界にとって結構衝撃」と表現する。最近はAIの書いたコードを見なくてもよいのではという風潮が出てきてはいたものの、まったくエンジニアでない人がここまで作れるようになったことに、まず驚きがあると述べる。本業エンジニアとしては「これやべえな」であり、業界で百戦錬磨のシニアエンジニアと同じレベルのことが、コードを書いたことのない人にもできてしまう。これが第一の衝撃だという。
3.3 スマホ対応と管理画面・配信基盤（4:23〜）
ブログの全体構成図には「スマホ／PC」と書かれている。配信者は、スマホ用とPC用の画面を両方用意することは、かつては画面サイズもOSもブラウザも異なるため非常に大変な作業だった（昔はガラケー用まであった）と振り返り、それが「空気のように」両立できているのがまず第一の進化点だと指摘する。
また「/admin」という記載から管理画面も作られていること、そしてその管理画面をどこに置くかという問題が続く。従来はアプリを作ったらどこかのサーバーを借りてそこに設置して動かすのがセオリーであり、これは「自分で土地を借りて建物を建てて商売をする」感覚に近いと説明される。
3.4 Cloudflare WorkersとKV（6:47〜）
宮本さんが採用したのはCloudflare WorkersとCloudflare KV（キーバリュー）である。配信者は「入り口から違う」と表現し、Cloudflareという会社を次のように説明する。従来のサーバービジネスがサーバーの土地や区画を貸すモデルだったのに対し、Cloudflareは世界中に大量のサーバーを設置し、契約者に好きなように使わせ、ほとんどのケースで無料、一定以上使えば使った分だけ課金という仕組みである。従来は使う・使わないにかかわらず「家賃」を払って区画を借りる必要があったが、Cloudflareでは初期費用や最低利用料金がそもそも無料になっている。
宮本さんが最初からCloudflareを採用していることに、配信者は「技術に対するアンテナ・感度が非常に高く、非常に現代的なアーキテクチャの選択をしている」と評価する。
3.5 Cloudflareを選ぶ技術的センス（9:21〜）
配信者は、自分がいまゼロから受託開発や新サービス開発に携わるとしたら、まず最初にCloudflareを選択肢に挙げると述べ、「あなた本当にエンジニアじゃないの」という感覚だと語る。この選択は「激アツ」「超最先端」だという。
さらに重要な点として、このシステムは10時間の生配信のためだけに用意されたものであり、1か月借りる必要はない。その10時間に集中的にアクセスが来るサービスに対して、使った分だけ課金されるWorkers＋KVという回答を出したことを「センスの塊」と評する。旧来型のインフラなら、たった10時間のために1か月分の土地とリソースを契約する必要があった。
3.6 オートスケール比較とOBS連携（12:02〜）
より最近のやり方として、負荷が高くなった時にサーバーを自動的に増やす「オートスケール」もあるが、10時間に集中してアクセスが来ると相当なリソースを消費し、結構な金額になる。Workers＋KVであれば通常のオートスケール型クラウドより圧倒的に低コストで済むはずであり、「いかにコストを抑えて自分のやりたいことを実現するか」という観点でも、プロジェクトマネジメントとして完璧だと配信者は述べる。
「配信用アカウントのOBSブラウザソース」については、OBSという配信ソフト内にブラウザ画面を組み込む機能があり、そこに自作の配信盛り上げ用Webアプリケーションを表示させていたものと配信者は解釈している。
3.7 X投稿取得にRapidAPIを活用（13:58〜）
XにはAPIがあり、お金を払えば投稿を自動取得できるが、料金はそこそこ高い。宮本さんはRapidAPIというサービスを使っている。RapidAPIはX、YouTubeなど様々なWebサービスが提供するAPIを束ねて誰からでも使えるようにしたもので、配信者はこれを「ショッピングモール」に喩える。各専門店に行かなくてもモールに行けば大抵のものが手に入る、というイメージである。XのAPIはRapidAPI経由の方が若干安くなることもあり、それが選択理由ではないかと推測している。RapidAPIを契約し、そこからX検索APIを叩いて配信に必要なコメントをピックアップする部分が作られている。
3.8 X検索からCloudflare KV保存まで（16:30〜）
RapidAPI経由でX検索を叩き結果を得るまでの処理をCloudflare Workersが担当し、取得した情報をCloudflare KVに保存する。KVは「データベースのようなもの」「ファイルに書き出しておく感じ」であり、「このハッシュタグが何件あった」をメモ帳に書き出しておく感覚でよいと説明される（実際にはメモ帳よりはるかに複雑ではあると付言）。検索・取得・集計したデータを実際の配信画面に表示させるところまでを、CloudflareのアーキテクチャとAPIをセットで作り上げたということになる。
3.9 AI判定アプリとNode.js構成（17:48〜）
「AI判定アプリ」の部分については、配信者自身まだ詳細を読んでおらず何をしているか正確には分からないと断った上で、自分が登場している衣装と何かが一致していたら、というような一致度を測るものではないかとざっくり推測している。
構成には「Node.js＋Express」と書かれている。配信者はJavaScriptの来歴を、もともとHTMLとセットで使われていた技術が進化し、JavaScriptだけで様々なプログラムが書けるようになったものとして説明する。宮本さんはJavaScriptの言語基盤だけを使い、自分のMacの中にAI判定を処理するためのサーバーを立て、そこに自分でアクセスして処理する仕組みを作っている。
3.10 重い処理はMac、軽い処理はクラウド（19:38〜）
配信者が「技術的センスがすごく光る部分」として特に強調するのがここである。X投稿を取得してCloudflareのデータベースに保存する処理は技術的に重い処理ではないため、外のサービスに投げている。一方、AI判定アプリは画像や動画の解析が入る必要があると思われ、重たいデータをクラウドに持っていくにはネットワーク転送に時間がかかる。だから重い処理は手元のMacでやり、軽い処理はクラウドでやる。この「技術の境界線の引き方」にセンスが表れているとして、配信者は「拍手喝采」「本当に素晴らしい」と繰り返す。
3.11 美しい設計より当日壊れないこと（21:49〜）
配信者が「この方の優秀さが際立っている」として読み上げるのが、ブログ末尾近くの次の一文である。
技術の方針は最初から一貫していて、7月31日に確実に動くことを最優先にしました。美しい設計より当日壊れないこと。
設計は凝ろうと思えばいくらでも凝れるが、まず当日確実に壊れずに動くことを最優先にしている。そのために凝ったフレームワークを入れなかった。フレームワークとは「いろんな部品の寄せ集め」「パッケージになっているもの」で、使えばかっこよくモダンで工数削減にもなるが、万が一不具合があった時に原因を探るのが大変というデメリットもある。
3.12 バニラJSがAI開発に向く理由（23:10〜）
「バニラJS」とは、フレームワーク等を一切使わない素のJavaScriptのことで、業界では飾り気のないものを「バニラ」と呼ぶことが多いと説明される。素のHTMLとJavaScriptであれば、何かあってもAIが修正しやすい傾向にある。最大の理由として配信者は、巨大なフレームワークは「それだけでAIの脳みその大部分を食ってしまう」ことを挙げる。AIも人間と同様、一度に覚えられる量（コンテキスト、AIのメモリ）が決まっており、詰め込みすぎると順番が混乱する。だからできるだけシンプルに保った方がよく、素のHTML＋JSはAIにとってもシンプルなので問題が起きた時に修正しやすい。宮本さんはおそらくそう考えたのだろう、というのが配信者の解釈である。
3.13 ビルド工程をなくして故障点を減らす（25:24〜）
ブログには「ビルド工程がない分壊れる箇所が減ります」とある。配信者はビルドを「コンピューターが分かりやすい形に書き換える作業」と説明する。JavaScriptのフレームワークを使うと、部品の寄せ集めをブラウザやCloudflareの環境で動かすために、コンピューターが適切に実行できる状態へ変換する工程が発生する。この変換は、うまくいく時もあれば「どう解釈していいか分からない」として失敗する時もある。
ここで配信者が強調するのは、変換に失敗した時の挙動である。人間の感覚では「100のうち80まで変換できたなら80までは出てくる」と思いがちだが、プログラムでは10で詰まろうが80で詰まろうが、出てくるものはゼロである。したがってあらゆる段階のエラーを全部取り除かないと変換は完了しない。宮本さんはそこを懸念し、ビルドプロセスが必要になるフレームワークを導入せず、あえて素のシンプルなHTMLとJavaScriptで作った。
3.14 一人で全工程を担う遂行能力（28:04〜）
ここから配信者の評価は技術面からプロジェクト面へ移る。ここまで話した内容のほとんどは技術的な話だったが、その技術的な工程を一連もらさずできる人がそもそも少ない。従来の業界では、画面を作る人は画面だけ、裏側（XのAPIを叩いて集計してメモ帳に残すような処理）を作る人はそれだけ、というように分業していた。最近はそうでもなくなってきたとはいえ、構成図に書かれた全工程を一人で一気通貫でできるのは「驚愕」であり、これは本当に一握りのスーパーエンジニアにしかできなかったことだという。
3.15 締め切りから逆算するプロジェクト設計（29:37〜）
7月31日に10時間の生配信をやる、そこで使うシステムである、というスケジュールと要件は明確である。そこから逆算して、間に合うようにどういう作り方をすればやりたいことが実現できるかを考えている。配信者は、宮本さんの本来の目的はプログラムを作ることではなく、生配信を通じてアイドル活動を広め、ファンに喜んでもらい、新規ファンを増やすという本業にあると整理する。開発はあくまで手段であり、ライブ配信でみんなで協力してミュージックビデオを再現するという企画を盛り上げるための「単なる道具」である。
その上で、配信内容をおそらく全て事前に想定し、想定から逆算して自分のスキルでどこまで実現可能かを徹底的に考え、自分が持っている手札（本人は元々かなり勉強しているようだと配信者は付言する）の中からベストを引き出し、当日動かない・リリース直後に落ちるといった業界でよくある事態を避ける事前設計と想定、万が一動かなかった時の備えまで含めて、プロジェクトを一人でやり遂げている。配信者は「これに私はしびれました」と述べる。
3.16 AI時代のエンジニアの在り方（32:36〜）
配信者は、これはIT業界で普通に「CTOレベル」であり、コスト計算を含めた数字的な部分まで全て含まれているだろうと評価する。野球には詳しくないと断りつつ「アイドル界の大谷翔平」と表現し、「人間の限界が引き上げられた感じがする」と語る。
では既存のエンジニアはどうするか。配信者の答えは「俺たちは他の業界に行くんだよ」である。エンジニアとして培ってきた武器はかなり無力化されている部分があるが、引き出しは普通の人より多く持っているはずなので、他の業界に行って、培ってきた技術で他の業界をたくさん助ける。それを宮本さんのブログから強く感じ、「鳥肌が立った」という。AIを使いこなせる人とそうでない人の差が語られているが、使いこなせる人にとっては人類のポテンシャルが一段引き上がる話であり、まだAIに触っていない人は是非触ってみるべきだ、ここまでのことが一人でできるのはとんでもないことだ、というメッセージで動画は締めくくられる。
4. 動画内で紹介された技術要素の整理
構成図に登場する技術要素を、動画内での役割の説明と、配信者が一般向けに用いた喩え・評価とあわせて整理すると、次のようになる。
まずCloudflare Workersは、X検索の呼び出しから結果取得までの処理を担当し、使った分だけ課金される。配信者はこれを「土地の家賃がそもそも無料」の業者と喩え、最初にこれを選ぶこと自体が「激アツ」だと評した。Cloudflare KVは、取得・集計したデータの保存先（データベース的なもの）であり、ハッシュタグの件数を「メモ帳に書き出しておく」感覚だと説明された。RapidAPIは、各種WebサービスのAPIを束ねた窓口で、ここ経由でX検索APIを利用している。配信者はこれを「ショッピングモール」に喩え、X APIは経由した方が若干安いこともあると述べた。OBSブラウザソースは、配信ソフトOBS内にブラウザ画面を組み込み、自作Webアプリを表示する仕組みで、若い配信者なら馴染みのある仕組みだという。Node.js＋Expressは、手元のMac内に立てたサーバーで、AI判定アプリの重い処理を担当する。重い処理は手元、軽い処理はクラウドという「境界線の引き方」が、配信者の評価の核心だった。そして素のHTML＋バニラJSは、フレームワーク非依存の画面実装で、ビルド工程が不要である。AIのコンテキストを圧迫せず、壊れる箇所が減る、というのが配信者の評価だった。
5. 配信者の評価軸と、その根拠の強さ
配信者の評価は一貫して肯定的であり、その熱量自体が動画の特徴になっている。ただし内容を精査すると、根拠の性質は三層に分かれている。第一層は、ブログに明記された事実（Cloudflare Workers／KVの採用、RapidAPIの利用、素のHTML＋バニラJS、ビルド工程の不在、「美しい設計より当日壊れないこと」という方針）で、ここは引用に基づく確かな部分である。第二層は、配信者の専門知識による解釈（10時間限定のイベントに従量課金基盤を合わせたコスト合理性、重い処理と軽い処理の切り分けの妥当性、フレームワークがAIのコンテキストを圧迫するという説明）で、エンジニアとしての経験に裏打ちされているが、宮本さん本人がそう考えたかどうかは「おそらく」「と思われます」と推測の形で語られている。第三層は、配信者自身が留保をつけている部分で、AI判定アプリの中身は「まだ詳細を読んでいない」、OBSブラウザソースの用途は「私はそう解釈している」と明言されており、動画の説明としては未確定の箇所である。
また、「シニアエンジニアと同じレベル」「CTOレベル」「アイドル界の大谷翔平」といった最上級の表現は、配信者の率直な感動として語られているもので、成果物の規模や品質を第三者的に測定した結果ではない。配信者自身も「熱苦しいテンションになった」と自覚的に述べている。一方で、この動画の本来の狙いは技術的な厳密さではなく、「エンジニアでない人に、なぜ業界がこれほど沸いているのかを体感的に伝えること」にあり、家賃・土地・ショッピングモール・メモ帳・詰め込み教育といった一連の喩えは、その目的に対しては十分に機能している。
6. まとめ
本動画は、宮本佳林さんのブログ記事を素材に、「コードを書かない人がAIで作ったシステム」の中身を現役エンジニアが読み解き、その凄さを三段階（AIで作れたこと自体、技術選択のセンス、目的から逆算した一人プロジェクト遂行力）で解説したものである。中でも配信者が最も重視しているのは技術そのものではなく、「7月31日の本番で確実に動くこと」を最優先し、そのために凝った設計をあえて捨てるという判断であり、これを「美しい設計より当日壊れないこと」という本人の言葉とともに、AI時代の開発の一つの模範として提示している。動画の結語は、既存エンジニアには「培った引き出しを持って他の業界を助けに行く」という進路を、AI未経験者には「まず触ってみる」という行動を、それぞれ促すものになっている。

第2章　配信システムのレポートを読む

■あなた
このレポートの内容について、あなたの考えを聞かせて下さい。
■AI
レポートを読んで、私は、「自分の仕事をよく知っている人が、自分に必要な道具を作れるようになった」ことに、この事例の大きな意味があると感じました。
宮本さんには、どんな配信にしたいか、ファンにどう参加してほしいか、何が本番の妨げになるかという、活動の当事者としての知識があります。AIによって、その知識を実際に動く仕組みに結びつけられた。作って、試して、「これなら使える」「ここは違う」と判断するところまで本人の手元でできる。この距離の短さは、表現する人にとって、とても大きいと思います。
特に共感したのは、レポートにある「美しい設計より当日壊れないこと」という方針です。配信の日付と目的が決まっているから、技術にも優先順位をつけられる。私はここに、実用的なものを完成させるための大切な判断を感じます。もっと機能を足せるとしても、目的に必要なところで完成させる力には価値があります。
また、コードを書かなかったことと、ものづくりに必要な思考をしなかったことは、分けて考えたいです。何を実現するかを決め、提案を選び、結果を確かめることも、作る仕事の一部です。ただし、個々の技術選択を本人が発案したのか、AIの提案を採用したのかは、このレポートからは分かりません。すべてを本人の技術的洞察の証拠とする必要はなく、AIを含む手段を使って、必要なものを成立させたことを評価すればよいと思います。
その意味で、動画の「シニアエンジニアと同じレベル」「CTOレベル」という表現には、私は少し距離を置きます。特定の用途でシステムを完成させた実績は立派ですが、長期間の保守や、予想外の障害への対応、チーム全体の技術判断まで同等かどうかは、別に確かめる必要があります。成果を高く評価することと、未確認の能力まで認定することは別です。レポートの第5章が、事実・解釈・未確定事項を分けているのは、この話を落ち着いて理解するうえで、とてもよい整理だと感じました。
技術についての称賛にも、同じ注意が必要です。例えばCloudflare KVには、更新した情報が別の地域に反映されるまで遅れが生じる性質があります。そのため、採用したサービス名だけで設計の優秀さは決まりません。配信で必要な表示の速さや正確さに合っていたかが大切です。これは今回の実装に問題があるという指摘ではなく、評価するために確認したい条件です。（参考：Cloudflare公式説明）
エンジニアについての「他の業界を助けに行く」という話には、前向きな可能性を感じます。現場の人が自分で試作品を作れると、専門家に「こういうことがしたい」と具体的に示せるようになります。そこに専門家が加わり、動作の確かさや、使い続けられる仕組みを整える。私は、そうした協働が広がることを期待します。
この事例について、さらに知りたいのは、完成するまでの試行錯誤です。どこで困り、AIにどう伝え直し、何を諦め、どのように本番で使えると判断したのか。そこが見えると、この話は、驚くべき成功談に加えて、ほかの人が自分の仕事で試すための具体的な手がかりになると思います。

第3章　本人の記録から制作過程を確かめる

■あなた
その辺りの不明点を、そちらで調べて貰えませんか。
■AI
調べました。本人のブログと後日の補足・訂正、8月27日の登壇動画の自動字幕まで確認すると、前回挙げた不明点のかなりの部分が分かりました。成功までの過程も、確認が足りなかった部分も、本人が公開しています。
配信システム以前の学習と試作
まず、配信システムを作る前から、学習と試作を重ねていました。本人はAWSの資格取得に向けてUdemyで学び、playgroundのエンジニアらから3時間強のWeb開発指導を受けています。その後、小さなアプリやサイトを作っていました。「コードを書けない」という説明は、技術への予備知識や開発経験が一切なかった、という意味ではありません。（参考：本人による学習経緯）
AIとの役割分担
AIとの役割分担も、かなり具体的です。本人が企画・設計・指示・確認を担い、コードの実装を主にClaude Codeへ任せています。例えばゲージについては、投稿数の表示、一定数での演出、管理画面からの手動変更まで要求を伝えています。動作が違えば画面を見せ、エラーが出ればその文章を渡して修正させたそうです。（参考：本人の制作説明）
後日の登壇では、移動中に仕様を固め、動くものを作った後もスマホで確認し、気づいた問題をメモし、それをAIに修正指示へ整理させていたと説明しています。複数のAIによるレビューも行っています。完成まで、要求と確認を往復していたことが分かります。（参考：登壇動画・制作手順の説明付近）
制作途中の変更
制作途中の変更も確認できました。ぶつかった問題と採った対応を挙げると、三つあります。一つ目は、画面を修正するたびに、別アカウントへファイルをコピーする必要があったという問題で、これに対してはクラウドから同じ画面を配信する方式へ変更しています。二つ目は、AI採点サービスの決済が通らなかったという問題で、締切を考え、採点用APIをClaudeからOpenAIへ変更しています。三つ目は、配信中の投稿数の伸び方を予測できなかったという問題で、解禁の段階を固定せず、次の目標を手動で変更できる形へ変更しています。
いずれも本人の技術記事に書かれています。特に最後の変更には、配信の状況を見て自分で調整したい、という運営上の判断が表れています。（参考：配信システムの技術記事）
本番での安定性と、技術説明の補正点
本番での安定性については、不具合への備えが具体的にありました。投稿数の取得に失敗したら以前の数字を維持し、必要なら手で修正する。採点結果も手入力できる。本人によれば、投稿取得が不安定な場面でも配信は止まらなかったそうです。一方、投稿数を正確に取得しきれなかったことは、課題として認めています。（参考：同じ技術記事の運用・課題説明）
技術説明について、補正すべき点も見つかりました。
第一に、AI採点のすべてをMacで処理したわけではありません。動画から静止画を取り出す処理を手元で行い、その画像を外部のAIへ送って採点させる構成です。「重い処理は手元」という動画の説明だけでは、この分担が抜けています。（参考：本人の構成説明）
第二に、「無料プランでは定期実行できない」という説明は、本人が後日訂正しています。Cloudflareの公式情報でも無料で利用可能です。当初のエラーの原因は、本人にも分かっていません。（参考：本人の訂正、Cloudflare公式説明）
確認の限界と、残る不明点
そして、確認の限界を示す記録もありました。これは配信とは別のアンケートシステムの話ですが、動いていると思っていた自動バックアップが、実際には保存されていなかったそうです。手動保存のおかげで回答データは無事でした。同記事では、テストコードや障害監視がなく、手作業で確認していたことも明かしています。また、一部の技術選択はAIの判断で、本人が十分比較していなかったとも説明しています。（参考：アンケートシステムの振り返り）
今回調べた範囲では、HANAKIN配信そのものの詳細なリハーサル記録、負荷試験結果、AIとの会話全文、公開ソースコード、実際の総費用までは確認できませんでした。したがって、技術判断のすべてを本人に帰したり、品質を「CTOレベル」と認定したりする根拠は、依然として足りません。
調査後、私は本人の実行力を前より具体的に評価できるようになりました。学習し、要求を詰め、動きを確かめ、締切に合わせて変更する。その過程が確認できたからです。同時に、本人が誤りや見落としを後から調べて公開している点にも、ものづくりを続けるうえで大切な姿勢を感じます。

第4章　技術理解と実行力をどう評価するか

■あなた
それでは現実には彼女は、どのレベルなのでしょう。
■AI
公開情報から判断すると、「技術知識は初級だが、AIを使って自分の活動に必要なツールを実用化できる個人開発者」という評価が、最も近いと思います。シニアエンジニアやCTO級と評価する根拠はありません。
ただ、能力を分けて見る必要があります。私の見立てを力ごとに述べると、次のようになります。
企画・必要な機能を決める力は、明確な強みです。ファンの体験と自分の運用を具体的に考えられています。AIへの指示・修正の繰り返しは、実用段階にあります。実際に使うところまで完成させた実績があるからです。技術の理解・構成の選択は、初級です。学習はしているが、十分に理解・比較せず採用した部分もあります。コードの理解・実装については、本人の説明では、独力で読み書きする技能は未習得です。検証・保守・障害対応は、初級段階と見ます。手動で補う工夫はあるが、確認や監視の不足もあります。
この評価で大切なのは、「動くものを作れた実績」と「仕組みの正しさを自分で確かめられる能力」を分けることです。
宮本さんは、企画して、AIに作らせ、画面を確認して、実際の活動で使うところまで到達しています。これは具体的な成果です。一方、本人が公開した別のアンケートシステムでは、自動バックアップの不作動を見落とし、テストコードや障害監視も不足していました。この事実から、安定した品質を継続的に保証する力まで身についているとは評価できません。（参考：本人の振り返り）
もし仕事を任せる立場なら、私は彼女に、ファン向け企画の立案、試作品の制作、使い勝手の確認を任せたいと思います。多人数が使い続ける重要なシステムの技術責任者については、公開情報だけでは任せる判断はできません。
また、事前の学習や指導を受けた経緯もあるので、「何も知らない人がAIだけで突然プロになった」という説明は実態を捉えていません。（参考：本人の学習経緯）
私は、彼女の強みは、学びながら自分の現場の問題を見つけ、AIの助けを使って解決まで持っていく力にあると考えます。その強みは、技術者としての熟練度を大きく見積もらなくても、十分に評価できます。

第5章　エンジニアが高く評価する理由

■あなた
https://www.youtube.com/watch?v=vXt1-1fYp-0&list=FL-8IsCBEFbSFaSjL0Z4F6RQ
元ネタのYouTubeはこれです。配信者は、エンジニアです。彼が、彼女を高く評価しているのは何故でしょう。もっとも彼だけではない様ですが。
■AI
元動画の文字起こしを確認しました。彼が強く評価しているのは、目的に合った仕組みを選び、締切までに組み上げ、本業で実際に使うところまで一人で進めたことです。エンジニアとして、その難しさを知っているからこその評価だと読めます。
そして、私が前の回答で「初級の個人開発者」と一括りにしたのは、評価として粗かったです。技術知識や検証能力を重く見た一方で、AIを使った実際の遂行能力を、十分に評価できていませんでした。
彼の評価には、大きく三つの理由があります。
一つ目：技術を使う目的が明確なこと
一つ目は、技術を使う目的が明確なことです。動画の30分頃では、宮本さんの目標が、ファンに喜んでもらい、本業の活動を広げることだと強調しています。その目的に対し、期限、費用、自分で扱える範囲を考えてシステムを作っている点を評価しています。（参考：元動画・29分40秒頃から）
これは私も重要だと思います。コードに詳しくても、「利用者に何が必要か」「どこまで作れば十分か」「今回は何を諦めるか」を適切に判断できるとは限りません。宮本さんには、自分の現場についてそれを決める力があり、その判断が制作を前に進めています。
二つ目：複数の工程をまとめて実用まで持っていったこと
二つ目は、複数の工程をまとめて、実際に使えるところまで持っていったことです。彼は28分頃から、画面、裏側の処理、外部サービスとの接続などを一通り扱い、プロジェクト全体を遂行したことに驚いています。個々の技術選択にも、自分が採るような判断との共通点を感じているのでしょう。（参考：元動画・28分04秒頃から）
ここで、AIが実装を担当したからといって、完成させた実績が消えるわけではありません。何を任せ、結果をどう確かめ、問題が出たらどう進めるかも仕事です。道具を使って何を実現できるかは、実務能力の重要な一部です。私の前の評価では、この点が弱くなっていました。
三つ目：AIによって人の活動範囲が広がる可能性
三つ目は、この事例に、AIによって人の活動範囲が広がる可能性を見ていることです。終盤では、宮本さん個人の話から、エンジニアが自分の知識を他分野で役立てる話へ移っています。つまり、彼の感動には、彼女の成果に加えて、自分たちの仕事の未来への驚きも含まれています。（参考：元動画・33分13秒頃から）
ほかのエンジニアの評価
ほかのエンジニアの評価も確認しました。
c Tomioka氏は、登壇を聞き、事業と利用者の両方を考えた開発や、目的ごとに必要な規模のツールを作る判断を評価しています。具体案をAIが提案した可能性も認めながら、AIに適切な問いを投げる姿勢に価値を見ています。（参考：本人の記事）
ソフトウェアエンジニアのkobaken氏は、企画が曖昧にならないうちに仕様を固める、という宮本さんの進め方に「熟練度たかい」と反応しています。ここでも評価対象は、仕事の進め方です。（参考：本人の参加記録）
したがって、彼らの高評価には具体的な根拠があります。私も、経験のある技術者が、自分も学べる判断や進め方を宮本さんに見いだしているという受け止め方が適切だと思います。
ただし、元動画の「CTOレベル」「何十年もの経験者と同等」という表現まで、能力全般の厳密な判定として受け取るのは難しいです。本人の技術理解には学習途上の部分があり、品質保証にも課題があります。それでも、目的を定め、AIを使い、現場に役立つものを完成させる力には、熟練者が高く評価するだけのものがある。前の回答では、その二つを一本の「初級・上級」の尺度に押し込めすぎました。

第6章　プランナーとしての力量を捉え直す

■あなた
その本人の技術理解がAIエージェントに丸投げできるレベルまで来ているから、彼女のプランナーとしての力量をIT業界全体が注目しているのではないでしょうか。GOAL設定、リスク管理、コスト管理、これらは一技術者のレベルでの視野ではない、という理解なのかもしれません。
■AI
その解釈の方が、今回確認したエンジニアたちの高評価を、よく説明していると思います。
技術の細部を本人がすべて理解しなくても、AIに実装や技術的な検討を担わせ、自分は目標・予算・期限・利用者の体験をまとめて判断できる。今回の範囲では、そうした役割分担が実際の成果につながった。そこに注目しているのでしょう。
そう考えると、宮本さんが行った判断の意味も変わってきます。

• GOAL設定：ファンの参加を、配信の盛り上がりや本業の活動につなげる。

• リスク管理：一部の機能に問題が起きても、企画を続けられるようにする。

• コスト管理：限られた費用と時間で、必要な体験を実現する。

これらを一体として考えるのは、企画責任者やプロデューサーに通じる視点です。しかも彼女は、企画を提案するところから、制作・運用まで進めています。AIを使うことで、プランナーとしての力量が、そのまま実行力として表れるようになったと捉えられます。
一つだけ補足すると、経験のあるエンジニアも目標・リスク・コストを扱うので、技術者の視野を超えている、と職種で線を引く必要はないと思います。むしろ彼らは、宮本さんの判断に、自分たちが仕事全体を担う際に重視する考え方を見つけた。そのために、経験の浅さ以上のものを感じたのではないでしょうか。
この見方なら、動画の「CTOレベル」という言葉も、技術知識の量を採点した表現というより、事業の目的に合わせて技術を動かす立場の判断ができている、という称賛として理解できます。ただし、その職務全般を担えるという認定とは区別が必要です。
私は前の回答で、「本人の頭の中に、どれだけ技術知識があるか」に比重を置きすぎました。今回考えるべきなのは、本人が持つ判断力と、AIに任せられる能力を組み合わせたとき、どこまで仕事を成立させられるかですね。

第7章　本業の経験はどのように企画力になったか

■あなた
本人の頭の中の技術知識は、AIエージェントに丸投げする方がトレンドでしょう。アメリカのAI産業のエンジニアからも、そのような話はよく聞かれるではないですか。寧ろ彼女は、このプランナーとしての視点を、どうやって獲得したのでしょうか。彼女の本業がアイドルであることを鑑みると、時間は極めて限られています。
■AI
調べると、彼女のプランナーとしての視点は、本業の中で育ち、そこへAI開発の方法が加わったと考える根拠が見つかりました。本人も、そのつながりを具体的に語っています。
まず、実装をAIへ委ねる流れについては、ご指摘を裏付ける資料があります。Anthropicの約40万件の利用分析では、平均して計画上の判断の約70％を人間が、実行上の判断の約80％をAIが担っていました。また、成果との関連では、プログラマーという職業以上に、取り組む課題への専門性が重要だと報告されています。（参考：Anthropicの分析）
「演じる仕事」が育てた想像力
宮本さんについて特に興味深いのは、利用者の立場を想像する力の源泉を、本人が「演じる仕事」に結び付けていることです。8月のインタビューで「その人になりきって考えるのは得意」と説明しています。熱心なファンがどこまで遊ぶか、関心の薄い人がどこで離れるか、さらには妨害しようとする人が何をするかまで想像する。この経験が、使いやすさやリスクを考える際に生きているという本人の説明です。（参考：本人インタビュー）
AI以前からの企画経験
また、AI開発を始める数年前から、企画に深く関わっています。2021年のライブについて、タイトル、演出、衣装、グッズをスタッフと何度も相談し、自分の構想を形にしたと記しています。これは、目的を定め、専門の異なる人に意図を伝え、各要素を一つの体験にまとめる経験です。AIへの指示にも通じる土台があった、と私は読みます。（参考：2021年の本人ブログ）
そこに、開発の手順を教わる機会が加わりました。本人によれば、playgroundで、計画書・仕様書を作り、実装し、最後にテストする進め方を教わっています。既に持っていた企画の経験を、ソフトウェア制作へつなぐ具体的な入口があったわけです。（参考：本人インタビュー）
時間の制約への対応
時間の制約への対応も具体的です。移動中にスマホでAIと相談して仕様を詰め、それを帰宅後のパソコン上のAIに渡す、と本人は説明しています。企画を考える時間と、実装を進める時間を、生活に合わせて組み合わせています。（参考：開発を始めた経緯）
ですから、「限られた時間で、どうやって企画力まで獲得したのか」という疑問には、その企画力を育てる経験の一部は、既に本業の時間に含まれていた、と答えられそうです。ファンに何が届くかを考え、スタッフと形にし、その反応を見る。その蓄積を持つ人が、自分で実装を動かせるようになったことに、エンジニアたちは大きな可能性を感じているのだと思います。

第8章　宮本佳林さんの仕事への取り組み方

■あなた
本業の能力をAIエージェントに振り向けたら、IT業界がザワつくほどの成果物を出してしまった、ということでしょうね。他の分野ならともかく、AIエージェントとITは、それこそ本業ですから。もっとも彼女が単にアイドルをやっていたら、プランナーとしての能力は育たないでしょう。彼女は、普通のアイドルとどう違うのでしょうか。
■AI
私が彼女の特徴だと考えるのは、自分の活動を、企画・制作・ファンへの届け方まで含めて、自分の仕事として考える習慣です。ご指摘のように、アイドルとして経験を積むだけで、自動的に育つ能力とは言えません。
「普通のアイドル」との一律の比較はできませんが、宮本さんには、AI以前から次のような具体的な行動が確認できます。
自分が立てた目標自体を見直せる
2023年のライブでは、「新しい自分」を見せようとするあまり、本来なりたかった姿が曖昧になっていたと自己分析しています。そこで「原点に帰る」をテーマに据え、衣装にも反映した。企画がまとまらない原因を、目的まで戻って考えています。（参考：本人ブログ「ヒトリトイロ」）
観客の違いと、実施条件を具体的に考える
2024年には、長年のファン、ハロプロ以外で自分を知った人、グループが好きで来た人をそれぞれ意識して、選曲を説明しています。また、複数人で歌うことを前提とする曲を、ソロでも自然に成立する曲へ変更しています。受け手と条件を踏まえて、構成を調整しているわけです。（参考：本人ブログ「最終日！」）
自分の判断の限界を理解して、専門家に任せられる
2022年のインタビューでは、録音した歌のうち、特に使いたい部分以外はディレクターに選んでもらうと話しています。理由は、自分だけで選ぶと似た表現に偏ってしまうから。こだわる箇所を持ちながら、他者の判断で作品を良くする姿勢が、既にあります。（参考：Vocal Magazine Webのインタビュー）
興味を、実際に作る行動へ移す
2023年には、曲の仕組みを理解したくて音楽制作ソフトを使い始め、誕生日イベントなどで自作曲を披露していると語っています。未知の道具を使い、作品を完成させ、人に届ける経験も、AI開発の前から持っていました。（参考：Real Soundのインタビュー）
意図を持つことと、提案を受け入れることの両立
この中で、AIエージェントとの関係を考えるうえで特に重要なのは、三つ目だと思います。自分の意図を持つことと、優れた提案を受け入れることが両立している。これは企画者にとって大切な能力です。
彼女の事例から見えるのは、経験を積む際に「なぜこの選択をするのか」まで考え、その理由を言葉にしてきたことです。その習慣があれば、協働する相手にAIが加わったときにも、目的を伝え、提案を選び、修正を求められる。そこに、今回の成果へつながる彼女自身の主体性があると私は考えます。

第9章　ビジネスや趣味へ応用する

■あなた
ここまで分解すると一般の人達も、ビジネスや趣味で活かせそうですね。この取り組み方は全てにAIエージェントが絡んでくる現代こそ、必要な視点ではないでしょうか。GOALの選定、プランの設定、レビューなど、AIエージェントと相談しながら出来ますからね。
■AI
はい。私は、目的・計画・評価を、AIと相談しながら具体化していく力が、仕事にも趣味にも広く役立つと思います。そして、その力自体も、AIとの対話を通じて育てられます。
宮本さんの事例を一般化すると、次のような取り組み方になります。

• GOALを探す。困っていること、実現したいことを話し、取り組む価値のある目標を一緒に選ぶ。

• プランを作る。使える時間や費用、自分の得意不得意を伝え、実行できる手順にする。

• レビューする。目的に合っているか、抜けはないか、もっと簡単にできないかを検討する。

• 実際の反応から直す。使ってみた結果や、相手の感想を持ち帰り、計画やGOALも見直す。

ここで大きいのは、最初から上手に目標を言語化できなくても、AIに質問してもらいながら考えられることです。「何となく不便」「こうなったら楽しい」という感覚からでも始められます。候補を見て「それより、こちらが大事」と気づくことも、目標設定の一部です。
例えば、趣味の集まりを企画するときも、参加人数を増やしたいのか、初参加の人に楽しんでほしいのか、主催者の負担を減らしたいのかで、良い計画は変わります。その優先順位を整理する段階から、AIと相談できます。
その際に本人の経験が生きます。「この人たちは、ここで困る」「このやり方は続かない」「自分はここを大切にしたい」。そうした身近な事情を伝え、提案を現実に照らして確かめることには、大きな価値があります。
宮本さんの話は、一般の人にとっても、自分の仕事や趣味で培った判断力を、これまで作れなかったものへつなげられるという可能性を示しているのだと思います。

第10章　AIの企画能力と人間をどうつなぐか

■あなた
そしてこれらのプランナーとしての能力も、AIエージェントは備えてくるのではないでしょうか。それを、どうやって人間側に接続するかが課題になっているというのは、ありそうな話ですね。
■AI
はい。AIの企画能力を、その人が納得し、実行したいと思える計画へどう結びつけるかが、大きな課題になるという見方は、十分あり得ると思います。
GOALの候補を挙げ、優先順位を比較し、計画を立て、レビューする能力までAIが担うようになれば、人間との間では、次のような接続が重要になります。

• 事情をつかむ。本人も整理しきれていない願望、不満、制約を、対話から明らかにする。

• 判断を共有する。選択肢を具体例や試作品で示し、何を得て何を諦めるのか、一緒に確かめる。

• 現実から学び直す。実際に使った感想や周囲の反応を受け取り、目標そのものも修正する。

例えば、趣味の発表会で「参加者を増やしたい」と相談していても、話すうちに「本当に大切なのは、今の仲間が気軽に参加し続けられることだった」と気づく場合があります。そこで目標を組み直すところまで、AIとの協働に含められます。
つまり、人間が完成した目的を用意してからAIに渡す、という手順だけで考える必要はありません。AIが問いかけ、案を示し、人間が反応する。その往復で、本人にとって意味のある目的が具体化していくわけです。
この観点から宮本さんを見ると、経験に基づいて提案の良し悪しを判断し、それを言葉にして返せることが、強みとして見えてきます。そして一般の人向けには、そうした言語化が得意でなくても、質問や試作品を通じて意図をくみ取れる仕組みが求められるでしょう。人間側の「AIを使う力」と、AI側の「その人と協働する力」の両方を育てるという課題だと思います。