エンジニアよりモノ作りの本質を捉えていた3つのポイント|宮本佳林さんCloudflare登壇【2026年8月27日】

2026年8月27日、東京・京橋で開かれた開発者向けイベント「Cloudflare Workers Tech Talks in Tokyo #8」に、アイドルの宮本佳林さんが登壇しました。メルカリの導入事例やコンテナのパフォーマンスチューニングが並ぶタイムテーブルで、登壇枠としては最後(このあとはクロージングのみ)の20分です。

結論から言います。AIでものを作るとき、技術より先に決まるのは「誰を幸せにするか」です。20分の講演は、エンジニアが集まる場で、その順番を言葉にしたものでした。講演のタイトルは「アイドルから見たもの作りの本質」。ここでは、現役エンジニアの発表が並ぶ中でむしろモノ作りの本質を捉えていたと感じた3点を取り上げます。開発手法の話ではありません。

この記事の作り方: みやっち🧑‍💻は会場にいません。公開されているアーカイブ配信を視聴し、そこに映る講演スライドを読み取って書いています。引用はすべて、そのスライド・本人のブログ・報道からのもので、出典を都度示します(記事上部の画像も配信画面のキャプチャです)。

バイブコーディングとは: 2025年2月にAI研究者のアンドレイ・カルパシー氏が提唱した言葉で、作りたいものを自然言語でAIに伝え、生成されたコードを一行ずつ精査するのではなく、動作を確かめながら対話を重ねてアプリを形にしていく開発スタイルを指す。もともとは試作・プロトタイプ向けの方法として広まった。

2026年8月27日のCloudflare Workers Tech Talksで何が起きたのか

イベントはconnpassの告知ページによると、8月27日15時から17時まで、TODA HALL & CONFERENCE TOKYO(東京都中央区京橋)で開催されました。タイムテーブルは公式の順に、次のような並びです(抜粋)。

  • 15:15 Performance Tuning Containers - AWS Lambda MicroVMへの挑戦
  • 15:35 Laravel × Durable Objectsで実現するイベント向けライブ翻訳
  • 16:00 メルカリがCloudflare Imagesを導入した話
  • 16:15 15分でCloudflareのサービス全部紹介できるかな?
  • 16:30-16:50「アイドルから見たもの作りの本質」宮本佳林

宮本さんは2020年にJuice=Juiceを卒業し、現在はソロで活動しているアイドルです。Real Soundの記事によれば、公式プロフィールの趣味欄には「バイブコーディング」と書かれています。ITmedia NEWSの記事によれば、開発者イベントへの登壇はこれが初めて。開発は全てバイブコーディングで、CursorやClaudeに指示を繰り返して進めているといいます(講演スライドの表記は「Cursor / Claude Code」。ClaudeとClaude Codeは別のプロダクトです)。講演では、Cloudflare WorkersやD1・R2・KVを活用して4つのWebサイトを作った過程を紹介。ChatGPTにすすめられてAWSなどを独学してきたとも報じられています。

ポイント1: 作る前に「誰を幸せにするか」が決まっている

1つ目は、作るものを決める順番です。冒頭3枚目のスライドに、この日いちばん伝えたいことが置かれていました。

本日お伝えしたいこと / AIによるものづくりは / 人を幸せにする可能性を広げて、/ 誰も悲しまない方法を授けてくれる

技術カンファレンスの発表で、最初に「誰も悲しまない」が出てくることはあまりありません。しかもこれは精神論で終わらず、作ったものの設計にそのまま現れています。

アーカイブ配信に映る「実践」のスライドでは、ファンを「私を知らない方」から「いつもいる方」までの4層に分け、層ごとに1つずつシステムを当てていました

届けたい相手作ったもの採用技術(スライドの表記)
私を知らない方診断サイト「休日生態系診断」Cloudflare Worker/静的配信のみ
CD購入を迷ってる方10時間配信システムWorkers + KV(+ローカルNode.js)
イベントに来てくれた方アンケート&ボイス配布システムWorkers + D1 + R2 + KV + Turnstile(ボット対策)
いつもいる方全通特典動画配信システムWorkers + R2

出典: 2026年8月27日 Cloudflare Workers Tech Talks in Tokyo #8 宮本佳林さん講演スライド(アーカイブ配信より作成)

4つそれぞれに「なぜ作るのか」が併記されています。たとえば10時間配信は「花金にイベントがないなら配信で幸せにしたい」。そしてこのスライドの下段には「AI開発が、幸せを届ける対象を広げて手数を圧倒的に増やしてくれた」とありました。

事業者の言葉に置き換えれば、これは開発の話ではなく、モノ作りの上流にある事業設計の話です。まだ自分を知らない人、買うか迷っている人、一度来てくれた人、いつもいる人。どの層に何を届けるかを決めて、層ごとに道具を1つずつ置いていく——販促のファネルを、外注せずに自分で埋めています。ツールを覚えてから使い道を探すのではなく、届けたい相手の側から道具の数と種類が決まっている。順番が逆になっていないのです。

ポイント2: 「コードを書く」より前に、考える順番が決まっている

講演で一番実用的だったのは、進め方を7段階に分けたスライドです。副題は「『コードを書く』より前に、考える順番を決めると迷いにくい」。

段階やること使う端末
1 着想作りたいものをAIに話して、実現方法を相談するスマホ
2 安全確認お金・時間・安全・気持ちの面で問題がないか確かめるスマホ
3 仕様書AIと壁打ちしながら、画面と運用を固めるスマホ
4 試作固めた仕様をAIに渡して骨組みを作らせるPC(1〜2時間)
5 テスト自分で触って、不便・不安・ズレを書き出すスマホ
6 修正書き出した点をプロンプトにしてAIに直させるPC
7 公開・運用短時間で回せる運用の形にして公開するスマホ(5分)

出典: 同講演スライド(アーカイブ配信より作成)

注目したいのは、最初の2段階に置かれた問いです。1つ目が「誰かを幸せにするには?」、2つ目が「誰も悲しまない?」。手を動かす前に、届ける相手と、それで困る人がいないかを確かめる。3段階目でようやく仕様、4段階目で試作です。

そして下段にこうあります。「すきま時間を積み上げて、全体でだいたい3〜4時間」。しかもPCに向かうのは7段階のうち2つ(試作と修正)だけで、残りはスマホでの思考と確認でした。

ポイントとして挙げられていたのは「最初からなるべく完璧な仕様書を目指す。想像力を豊かにする」。時間をかけるのは考える側で、作る側ではない、という配分です。

うまくいかない人の多くは、これと逆をやっています。何を作るかをぼんやりさせたままAIに投げ、出てきたものを延々と直し続け、いつまでも公開しない。手が止まる原因はツールの習熟ではなく、問いの順番だと、この7ステップは言っています。

ポイント3: 完成度の基準を、場面ごとに変えている

3つ目は、完成度の基準がひとつではないことです。診断サイトの公開報告には、こう書かれています。

なのでいろいろ詰めが甘いです / でも「HANAKIN」を早くたくさんの方に届けるためにも爆速で公開に踏み切りました

公開後に直面したのは、共有まわりの不安定さでした。SNSで共有したときに画像が出たり出なかったり、ブラウザによって挙動が違ったりしたことを「SafariとChromeで違う!とか」と綴り、エンジニアの仕事の細やかさに感心したと書いています。そのうえで締めはこうです。「まだまだ改善点はたくさんあるけど / まずは公開まで辿り着けた自分を褒めたいと思います」。

一方で、失敗が許されない場所では慎重です。7月31日の10時間生配信を支えたシステムでは、技術構成のブログに「生配信は一発勝負なので、あらゆる自動処理に手動フォールバックを用意しました」と記されています。同ブログによれば、定期実行(Cron Triggers)の設定でエラーに突き当たったときは、有料プランに上げずに自動ポーリングを諦め、管理画面のボタンで取得する手動トリガーへ設計変更しています(結果としてAPIの消費を配信の盛り上がりに合わせて制御でき「運用としてはむしろ良くなりました」と振り返っています。なおCloudflare公式の現行のLimitsでは無料プランでもCron Triggersは使えるとされており、これは当時の開発で本人が遭遇した事象です)。また同ブログによれば、当時Claude APIのクレジット購入が決済エラーで通らなかったため、原因の追及に時間を使わずAIプロバイダごとOpenAI APIへ差し替えたとのことです。

企画のサイトは「詰めが甘くても今日出す」、本番の配信は「壊れても人手で戻せるようにする」。同じ人が、同じ時期に、違う基準を使い分けているのがこの事例の面白さです。完璧に作ってから出そうとして永遠に出せない人と、何でも見切り発車して本番で事故る人の、ちょうど間に線が引かれています。業務でどこまで自作し、どこで慎重になるかの考え方は業務アプリの作り方にも整理しています。

3つとも、開発ではなくモノ作りの話だった

ここまでの3点を、自分の商売に置き換えるとこうなります。

  1. 道具ではなく相手から決める。「どの層に何を届けるか」を先に並べると、必要なものの数と種類が決まる。宮本さんは4層に4つ用意した
  2. 作る前に2つ問う。「誰かを幸せにするには?」「誰も悲しまない?」。この2問は、AIに投げる前の設計そのもの
  3. 場面ごとに完成度の基準を変える。集客のための入口は今日出す。止まると困る本番は、人手で戻せる形にしておく

3つとも、フレームワークの選定やコードの書き方——つまり開発の話ではありません。誰に何を届けるかを決め、順番を守り、場面で基準を変える。これはモノを作る人すべてに共通する話で、だから業種を問わず持ち帰れますし、エンジニアかどうかも関係ありません。そしてこの3つを回す道具がClaude Code・Codexのような実行型のAIです。スマホで固めた仕様を、そのまま動くものに変えてくれる相手——宮本さんが「分身」と呼ぶのは的確だと思います(既製ツール・外注・自作の使い分けは前回の記事業務アプリの作り方に整理しています)。

AI Crewの受講生はほぼ全員が非エンジニアで、職業エンジニアは数名です。それでも自分の業務のための仕組みを自分で作るところまで到達しています(実例はClaude Codeの受講生実績、入門の道順は非エンジニアのClaude Code・Codex入門にまとめています)。

作って、外に出したから次が来た

登壇に至った経緯も、本人がブログに書いています。

最初の「休日生態系診断」を作った際にYusukeさんにお声がけ頂き / その後に配信システムブログでもたくさんの方に反応いただいてからの登壇の流れだったので

「休日生態系診断」は、7月29日発売の5thシングル「HANAKIN/シャニカマー」(両A面)の企画として本人が作った診断サイトです。公開報告のブログには「作り方の土台は実はプロの方々に教えてもらっているけれど / このサイトは一切誰のアドバイスもなしで私だけで作りました!」とあります。公開先は、Cloudflare Workersにデプロイすると割り当てられる workers.dev のURLでした。

作った → 公開した → 見た人から声がかかった → 裏側をブログに書いた → 反響が広がった → 登壇枠に呼ばれた。宮本さん自身も「いつも応援してくださる皆さんが私の作ったものに反応してくれたり楽しんでくれたりしたことが今回の登壇にも繋がっていると思うので、、」と書いています。作っただけでは次に進んでいない——外に出したことが、毎回スイッチになっています。

コードを書かない人が、AWSの資格まで勉強していた

10時間配信の裏側を書いた本人のブログには「プログラミングの経験はゼロ。コードは一行も自分で書いていません」とあります。講演の自己紹介スライドにも「これまでにITやAIの勉強してません」「コードは一切読めません」「全てバイブコーディングで開発」と並び、開発環境は「Cursor / Claude Codeに 指示→確認→また指示」と書かれていました。

ではその人がいま何をしているか。登壇報告のブログにこうあります。

皆さんの発表も配信で見ていたのですが / AWSで勉強したやつだ!とか / 内容を説明できるほどではなくても / そういう事かー!と思えたり

講演スライドには、2026年の歩みが月ごとに並んでいました。

  • 1月: みんなが幸せになる音楽アプリを構想し、ChatGPTにコーディングしてもらってローカルで開発。うまくいかず
  • 2月: しっかり開発できるようにITを学びたいと考え、Udemyに登録してクラウド領域(AWS SAA)を勉強
  • 3月: 仕事でチケット顔認証のシステムに触れて認証の速さに感動。ある開発会社にデータベース構成を質問して驚かれる
  • 4月: Cursorでの開発を教わってメモ帳アプリを開発。7月発売の新曲に向けて、独力でAI開発に挑戦

スライドの並びで最初に来るのは勉強ではなく、作ろうとしてうまくいかなかった経験です。そこから学びに入り、教わり、また作っている。Real Soundのインタビュー記事では「もともとチャッピー(ChatGPT)と会話することがすごく楽しくて、毎日話していた」と語り、AIには「本当の意味で私の“分身”になってほしい。そう思いながら、少しずつ自分のことを教え込んでいる」とも語っています。

AI Crewがパラシュート学習法と呼んでいるのも同じ順序です。まず動くものを作ろうとして、詰まった地点に降りて必要なことだけ学ぶ。勉強が「いつか使うかもしれない知識」ではなく、目の前で作りたいものに直結している——だから続きます。

ここは誤解されやすいので、はっきり書いておきます。AIに任せる進め方は、勉強しなくていいという話ではありません。むしろ「動いた」という手応えが先にあるほうが、その後の学習が続きます。登壇報告のブログにある「勉強がまだまだ足りていないので / もっと勉強したい」という一文が、その状態をよく表しています。

よくある質問

宮本佳林さんはいつ、どのイベントに登壇したのですか?

2026年8月27日に東京・京橋のTODA HALL & CONFERENCE TOKYOで開かれた「Cloudflare Workers Tech Talks in Tokyo #8」です。16時30分からの20分枠で「アイドルから見たもの作りの本質」というタイトルで話しました。当日の様子はYouTubeでアーカイブ配信されています。

講演では何が語られたのですか?

冒頭のスライドには「AIによるものづくりは / 人を幸せにする可能性を広げて、/ 誰も悲しまない方法を授けてくれる」とあります。内容は、ファンの4つの層それぞれに1つずつシステムを作った設計と、着想から公開までを7段階に分けた自身の進め方(すきま時間で全体3〜4時間)でした。

非エンジニアが作ったサイトを公開して大丈夫ですか?

扱うデータで線を引くのが現実的です。宮本さんが最初に公開した診断サイトは、講演スライドに「情報を預からない診断サイトで自作WEBサイトを初公開」と書かれており、個人情報を持たない設計から始めています。一方で顧客の個人情報を預かる仕組みや、止まると業務が止まる本番用の仕組みは別で、生配信システムには手動フォールバックが用意されていました。扱うデータや契約によって必要な確認は変わるため、判断に迷う場合は専門家への相談も検討してください。

前回の記事との違いは何ですか?

2026年8月2日公開のアイドル2人がClaude Codeでアプリを自作した記事では、非エンジニアの武器は技術ではなく顧客解像度である点を扱いました。本記事はその続きで、講演の中身——作る前に何を問うか——を扱っています。

モノ作りの本質は、技術の外側にある

コードを書けるかどうかは、もう分かれ目ではありません。この講演が示したのは、届けたい相手を先に決め、誰も悲しまない形を確かめてから、手を動かすという順番でした。技術の話ではないぶん、業種を問わず持ち帰れます。

AI Crewでは、プログラミング未経験の経営者・個人事業主・士業・会社員が、Claude Code・Codexで自分の仕事の仕組みを作るところまで伴走しています。まず無料セミナーでお会いしましょう。

関連記事

「AI Crew」は株式会社AI Orchestraの登録商標(登録第6942947号)です。