Brain to Product──声で意図を渡し、AIとプロダクトをつくるという働き方
画面を見たときの違和感。
ユーザーにどう感じてほしいか。
どこを変えてよくて、どこを壊してはいけないか。
あとで認証や保存や課金が絡むなら、今の時点で何を避けるべきか。
そうした頭の中の判断材料を、声でAIエージェントへ渡し、動くものへ近づけていく。
それが、この本で扱っている Brain to Product、略してB2Pです。
以下は『Brain to Product 声で意図を渡しプロダクトをつくる』の「はじめに」から、note用に一部だけ切り出した試し読みです。
試し読み：はじめにより
画面を見ていて、ふと思う。
このボタンは押したくならない。
この登録導線は、初めて来た人には少し怖い。
機能としては動いているのに、なぜか信用できない。
スマホで見ると、最初に何をすればいいのか分からない。
以前なら、こうした違和感は、いったん頭の中で整理しなければならなかった。
仕様にし、チケットにし、デザイナーやエンジニアに説明する。実装してもらい、レビューし、また直す。
その工程は今でも大切である。
だが、AIエージェントと開発していると、別の道が見えてくる。
画面を見ながら、そのまま話す。
これは、きれいなプロンプトではない。
だが、実装に必要な材料が入っている。
目的、違和感、ユーザー心理、変えてよい範囲、変えてはいけない範囲、確認してほしいことが、一度に入っている。
AIはそこからコードを読み、実装案を出し、ファイルを直し、テストを走らせ、ブラウザで確認し、スクリーンショットを返す。
人間はそれを見て、「近い」「そこは違う」「この文言は冷たい」「ここは戻して」と返す。
この往復で頭の中にあったものが、少しずつプロダクトへ近づいていく。私はこの距離を縮める働き方を、Brain to Product、略してB2Pと呼びたい。
ここで、B2Pとトーキングエンジニアの関係を先に整理しておく。
概念メモ：B2Pとトーキングエンジニア
B2P（Brain to Product）は、頭の中の像を、AIとの往復でプロダクトへ近づける考え方である。
その中で本書が中心に扱う手法が、トーキングエンジニアである。
声で、迷い、違和感、制約、目的、ユーザーへの想像を外へ出す。
AIに整理、実装、検証を任せ、画面を見てまた言い直す。
簡単に書けば、外側にB2Pという考え方があり、その内側に、声を主軸にしたトーキングエンジニアという実践がある。
長文チャット、手入力、図やメモによる壁打ちもB2Pに含まれるが、本書では特に、声で一気に判断材料を渡す力に焦点を当てる。
世の中には、バイブコーディングについての本や情報がすでに多くある。AIにコードを書かせる速さ、プロンプトの作り方、エディタやエージェントの使い方は、今後も重要であり続ける。
本書が扱う中心は、そこからもう一段手前にある。
短いプロンプトでAIを当てにいくのではなく、声で思考量を渡す。迷い、違和感、制約、ユーザーへの想像、怖いところ、守りたいものまで含めて、頭の中の像をプロダクトへ近づける。
つまり本書は、バイブコーディング一般の解説ではなく、音声入力を積極的に使って、思考を直接プロダクトへ届けるための本である。
この略語は本書だけのものではない。
世の中では、B2Pが Business to Person、Business to People、Business to Public のような意味で使われることもある。決済やマーケティングの文脈で見かける人もいるかもしれない。
この本での意味は、「頭の中の像を、声でプロダクトへ近づけること」である。
本書では、実例として、ぽちょ研究所のホームページ（https://pochanglab.com）、自叙伝ドットコム（https://jijoden.com）、じも恋（https://jimokoi.com）を取り上げる。
固有名詞が何度か出てくるので、先に前提だけ置いておく。
ぽちょ研究所のホームページは、記事、プロダクトへの導線、小さな実験を集めた個人サイトである。ここでは、公開拠点を短期間で立ち上げ、運用しながら整える例として扱う。
自叙伝ドットコムは、人生の記憶をAIとの対話で掘り起こし、1冊の自分史としてまとめるサービスである。ここでは、入口は速く作れても、長文生成、深掘り質問、課金、プライバシーまで含めると出口が深くなる例として扱う。
じも恋は、「地元に来てほしい店や施設」を地図上に可視化するサービスである。ここでは、地図、スマホ操作、保存、マルチプラットフォーム確認を短時間で検証する例として扱う。
ここで扱う3つは、あくまで入口である。
見たいのは、個別のサービスそのものより、その裏でどう意図を言葉にし、AIへ渡し、動くものへ近づけたかである。
だから、手に取ってくださった方が、自分の仕事へ置き換えて読める形にしたい。
経費精算の承認画面でも、営業案件を管理する社内CRMでもよい。クリニックの予約サービス、学習アプリ、ECサイト、サブスクリプション管理画面、地域コミュニティの投稿サービスでもよい。
「この画面で上長が迷う」
「初回ユーザーが登録前に価値を感じない」
「スマホで予約変更の導線が遠い」
「管理者だけが見られる情報と、一般ユーザーに見せる情報を分けたい」
こうした話は、私の個人プロダクトだけのものではない。
業務アプリでも、コンシューマ向けサービスでも、B2Pで扱う中心は同じである。
AWS、Playwright、FDEといった言葉に馴染みがなくても、本書で追ってほしい軸は3つである。
短いプロンプトより、判断材料を渡すこと。
AIに任せる前に、人間が違和感、制約、目的を言葉にすること。
速く作れるほど、人間が検証する責任は濃くなること。
本書の技術用語は、この3つを具体例で見るための材料である。
ここで少し、個人開発から現場の仕事へ視点を広げたい。
近年、Forward Deployed Engineer、略してFDEと呼ばれる職種も注目されている。
顧客の現場に入り、まだ整理されていない要望を聞き、業務の制約を理解し、AIや自社プラットフォームを使って短期間でプロトタイプや本番導入へつなぐ人たちである。
FDEの仕事には、B2Pの価値が特に濃く出る。顧客の言葉は、最初から仕様書の形をしていない。業務の例外、現場の違和感、既存システムの制約、導入後に誰が責任を持つのかまで、ばらばらの形で出てくる。
それをAIへ渡せる文脈に変える。動くものを作り、現場で触ってもらい、また違和感を返してもらう。
だから、FDEは本書の考え方が効きやすい典型例である。
ただ、本書はFDEだけの本ではない。
顧客の曖昧な言葉を受け止め、制約や違和感ごとAIへ渡し、動くものへ変える仕事には、そのまま効く。
社内DX、SI、SaaS導入、AI活用支援、プロダクトマネジメント、個人開発。肩書きは違っても、頭の中や顧客の現場にあるものを、速く、正しく、責任を持ってプロダクトへ近づけたい人に向けて書いている。
長文生成を扱うサービスの開発では、B2Pの実践が特に濃く出た。AIとの対話で記憶を掘り起こし、1冊の自分史へ近づけるには、入力設計、深掘り質問、長文生成、保存、課金、プライバシーが絡む。
第3章では、その開発過程を例にして、B2Pの入口の速さと出口の深さを見ていく。
ここから先では、実際の個人開発の履歴をもとに、声で渡した意図がどのように画面、コード、テスト、運用へ変わっていったのかを具体的に追っていきます。
AIに「いい感じにして」と頼むだけでは足りない。
けれど、自分の違和感や判断基準まで渡せるようになると、AIとの開発はかなり変わります。
『Brain to Product 声で意図を渡しプロダクトをつくる』は、Amazonで公開しています。
Kindle Unlimitedで表示されている場合は、そのまま読み放題でも読めます。
ぜひAmazonでチェックしてみてください。
