Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIもくもく会 #1

Avatar for KEITA YANAGAWA KEITA YANAGAWA
August 22, 2026
290

AIもくもく会 #1

Avatar for KEITA YANAGAWA

KEITA YANAGAWA

August 22, 2026

More Decks by KEITA YANAGAWA

Transcript

  1. 複眼道場 ⽭盾を感じ、抱え、進む、⼒。 本気のAIもくもく会 #1 / 導入LT どうやってAIで、 みんなが使える アプリケーションを作るの? 作るだけなら、AIが半日でやってくれます。

    「みんなが使える」にするために何が要るのかを、 いま動いている2つのアプリの中身を開けながら話します。 2026年8月23日(日)13:15 — BOTTOS 御茶ノ水駅前店 柳川慶太
  2. こ の LT の 役 割 「みんなが使える」って、どの状態のこと? 作るだけなら、AIが半日でやってくれます。難しいのはそこから先で、 アプリにははっきり分かれた3つの段階があります。 ①

    自分のPCの中で動く ② URLがある ③ 他人のデータを預かる HTMLを1枚開けば、もうここ。壊しても誰も 他人に見せられる。同時に、不特定多数に触 ログインと保存。ここから壊すと止まる世界 困りません。 られる状態になります。 に入ります。 まず目指すのは ② です。そのうえで、持ち帰ってほしい1行 「コードは書けなくていい。ただし、知識がいらないわけじゃない」。 AIに丸投げして進む人と、途中で止まる人の差は、知識の量ではなくどこを自分で決めたかにあります。 複眼道場 2
  3. 前提 AIは「記憶喪失の天才」 知識も推論力も、その辺の人間より圧倒的に上 ただしあなたのこと、作りたいもの、昨日決めたことは何も知らない そして毎回、まっさらな状態で会話が始まる 長い会話の後半では、前半に決めたことが薄れていく 作っている途中で、必ず起きること つまり 優秀すぎる新人が、毎朝、記憶を失って出社してくる。 文脈を持たせるのは、

    ずっと人間の仕事。 「さっきそう言ったよね?」が3回目になり、同じ仕様説明を毎回書き直 している。手が止まるのは、能力ではなく記憶の問題。 だから、焦点はここ 「どう聞くか(プロンプト)」より、何を、どこに置いておくか。 複眼道場 3
  4. AG E N DA この問いを、3つに分解する 第1幕 第2幕 第3幕 つくる とどける

    こわれない アプリの正体は、テキストファイルの集まり。 公開した瞬間、他人に触られる前提になる。 使われ続けるものは、揺らいではいけない。 HTMLを1枚開くところから、公開中のアプリま 難度がどこで跳ね上がるのかを、実物のコード AIに書かせながら、揺らがない場所をどう作る では地続きです。 で見ます。 か。 → 複眼道場を触ります → 段0から段5まで → 複眼道場カルテを触ります 終幕 — で、自分は何を作るのか 決まったことをどこに残すか。どこまでAIに渡していいのか。そして「何を作るか」をどう決めるか。最後はそこへ手渡して終わります。 3つとも、プログラミングの話ではありません。どこに何を置くか、の話です。 複眼道場 4
  5. 第1幕 つくる — いちばん最初の一歩 アプリの始まりは、1枚のHTMLをブラウザで開く コードの正体は、ただのテキストファイル メモ帳に書いた文章と、本質的には同じもの。それが動くのは、ブラウザ やサーバーという実行環境が読んで解釈してくれるから。特別なものでは ありません。 <!--

    index.html — これだけで動く --> <!DOCTYPE html> <html lang="ja"> <body> <h1> はじめまして</h1> <button onclick="alert(' 動いた')">押す</button> </body> だから、最初の成功体験はこれ </html> index.html を1枚作って、ダブルクリックで開く。それだけで、もうアプ リの第一形態です。サーバーもドメインも要りません。 複眼道場の詳細診断も、正体は1枚のHTMLです(4,723行まで育っていますが、構造は上と同じ)。最初の1枚と、公開中のアプリは地続きです。 複眼道場 5
  6. 第1幕 つくる — 拡張子 拡張子を見れば、何のファイルか分かる 拡張子 担当 複眼道場での実物 .html 画面の骨格

    詳細診断/index.html — 4,723行。質問も結果画面もこの中 .css 見た目・装飾 shared/design.css — 色・フォント・余白の定義元を1枚に集約(このスライドも同じ色を使っています) .js 動き shared/diagnostic-common.js — 291行。全診断が共通で使う処理 .json 設定・データ vercel.json(公開の設定)/package.json(使う部品のリスト) .ts / .tsx 型付きのJS/画面部品 middleware.ts — 753行。api/og.tsx — シェア画像の生成 .sql データベースへの命令 supabase/migrations/0001_init.sql — カルテの最初のテーブル定義 .md 文章・メモ README.md/CLAUDE.md — AIへの指示書もこれ。書くのに技術は要らない 全部覚える必要はありません。「これは何のファイル?」が分かるだけで、AIへの指示が一段正確になります。「JSを直して」と「CSSを直して」は、AIにとって別の依頼です。 複眼道場 6
  7. 第1幕 つくる — ブラウザの中 JavaScriptは、画面を描いていない HTMLを読む 骨格 ▶ CSSを当てる 見た目

    ▶ JSを実行 HTML を書き換える ▶ ブラウザが描き直す 画面 「動き」の正体 フロントだけでも、アプリは動く JSがピクセルを描いているのではありません。JSはHTMLを書き換えるだ 「サーバーを立てないと本物じゃない」は誤解です。保存する必要がない けで、描くのはブラウザ。診断で質問が切り替わるのも、結果が出るの なら、サーバーは要らない。複眼道場の診断の大半は、いまもこの形で動 も、全部この繰り返しです。 いています。 画面の担当(フロントエンド)と、裏方の担当(サーバーサイド)。つまずくとしたら、たいてい「どっちの話をしているか」がAIと噛み合っていないときです。 複眼道場 7
  8. 第1幕 つくる — 登場人物 覚えるのは、役割が3つだけ 名前 役割 やってくれること Claude Code

    / Codex 作る 日本語で指示すると、ファイルを作り、コードを書き、動かして直すところまでやる。環境構築から 始めなくていい時代になったのがここ Vercel 公開する GitHubに置いたコードを、自動で世界に出してくれる。URLが1本もらえる = 他人に見せられる Supabase 覚える データベースとログインをセットで用意してくれる。保存が必要になったときだけ登場する 黒い画面の正体 学ぶ順番が逆転した ターミナルは「エンジニアの世界」ではなく、文字でPCに命令する窓。い 「仕組みを学んでから作る」ではなく、AIで作ってから仕組みを知る。こ まは、ほぼClaude Codeが代わりに叩いてくれます。 の順番でいい、というのが今の前提です。 複眼道場 8
  9. DEMO 01 複眼道場 エニアグラムとインテグラル理論をベースにした、診断ツール群。 個人が、AIと一緒に作って、公開して、運用しています。 標準診断は3ステップ そこから枝が伸びる 結果を持ち歩ける ① タイプ診断(会話型・約10分)

    簡易5問/詳細90問/パートナーシップ/相性 無料アカウントで結果を保存。再診断せずに ② 本能の優先順位(9問・4〜6分) /リーダーシップ/仕事に求めるもの/成長 引き継いで、別の診断や交換日記から参照で ③ 2つを重ねて54タイプの取扱説明書に統合 コンパス きる。 — ここで実際に触ります。いま見た HTML・CSS・JavaScript だけで、ここまで作れます。中身は第3幕で開けます。 複眼道場 9
  10. 第2幕 とどける — サーバーって何? サーバーは、ずっと起きている誰かのPC あなたのブラウザ これください ▶ サーバー 24

    時間 起きている ▶ ファイルを返す はいどうぞ ▶ 自分のPCで開いている状態との違い URLは、住所と棚番号 手元のHTMLは、自分にしか見えない。電源を切れば終わり、URLもな fukugan-dojo.com = どのサーバーか い。 / 公開するとは、どこかで起きているマシンにファイルを置いて、来た人に 代わりに返してもらうことです。 画面になる ブラウザが描く 詳細診断 = その中のどのファイルか ブラウザは毎回この住所に「ください」と言いに行っています。 Vercelは、その面倒を全部引き受ける箱 マシンの用意、世界中への配信、https の鍵、ドメインの割り当て、そしてGitHubに上げたら自動で反映(これがデプロイ)。 複眼道場のアプリも、マシンの設定は1行も書いていません。書いてあるのはvercel.json のリダイレクト表くらいです。 複眼道場 10
  11. 第2幕 とどける — 公開する前に 公開する = 他人に触られる、ということ 上げてはいけないもの 上げるもの ・.env(APIキー・パスワードが入ったファイル)

    ・コード本体 ・外部サービスのシークレットキー ・設定のサンプル(.env.example) ・自分や他人の個人情報が入ったデータ ・READMEなどの説明 GitHubに一度上げたら、消しても履歴に残ります。 キーそのものはVercel側の設定画面に入れる、が基本です。 ついでに、commitは「セーブポイント」 Vercelに上げるためにGitHubを使いますが、非エンジニアにとっての本当の効能は公開ではなく「戻れる」ことです。AIに大きく直させる前に1回commitしてお けば、壊れても戻れる。壊すのが怖くなくなるのが、いちばん効きます。 迷ったら「これは他人に見られて困るか?」だけ考えてください。困るものは、コードと一緒に置かない。 複眼道場 11
  12. 第2幕 とどける — 複雑さの階段 難度は、なだらかには上がらない 段 状態 複眼道場での実物 そこで増えるもの 0

    HTMLを1枚、手元で開く はじめの index.html なし。壊しても誰も困らない 1 ページが増える/見た目を揃え shared/design.css + 共通JS 「1箇所直せば全部直る」設計が要る vercel.json / HTML 446枚を配信 不特定多数に触られる前提。公開していいファイル る 2 世界に公開する の区別 3 返す前にひと手間かける middleware.ts — 753行 「リクエストが来てから返るまで」という時間の概 念 4 サーバー側で処理する・記録す api/log.js + データベース 他人のデータを預かる責任と、秘密の管理 カルテ(画面36/テーブル34/マイグレ 壊すと本番が止まる。作り直しが効かない る 5 ログイン・課金・通知を持つ ーション61) まず目指すのは 段0 → 段2。それで十分すぎます。段3以降は「作れるようになった後で、必要になったら」で間に合います。 複眼道場 12
  13. 第2幕 とどける — 増えているものの正体 増えているのは機能ではなく、状態の置き場所 どこに「覚えさせる」か 同時に、失敗の種類も変わる ① どこにも持たない(毎回入力) 段0-1:見た目が崩れる(作り直せる)

    ② URLに詰める(結果をリンクに埋める) 段2:公開されない・秘密が漏れる ③ ブラウザに置く(その端末だけ・消える) 段4-5:他人のデータが消える・止まる ④ データベースに置く(別の端末からも見える) 複眼道場の診断が、いまも②で粘っている理由 診断結果は ?t= 有できる。 (タイプ)&n=(名前)&og=(要約) という形でURLそのものに入っています。だからデータベースが要らないし、リンクを送るだけで結果を共 「保存しない」は手抜きではなく、難度を上げない設計判断です。 「保存できるようにしたい」と思ったら、まず ② で済ませられないかを疑ってください。だいたい済みます。 複眼道場 13
  14. 第2幕 とどける — 永続化 「覚えておく」を、どこに置くか 電源を切っても、ブラウザを閉じても消えないところに書くこと。これを永続化と言います。 なぜ「ファイルに保存」ではダメなのか 大勢が同時に書く/あとから探す/並び替える/消す/誰のものかを分け -- create

    table entries ( この1件のID user_id uuid -- 誰のものか body_md text -- 本文 tags text[] -- タグ created_at timestamptz -- いつ書いたか id る。これを安全にやるための道具がデータベースです。 表(テーブル)に、1件=1行、項目=列で積んでいきます。 Supabase= データベース+ログイン カルテの「日記1件」の実物 uuid -- ); 「誰のデータか」を決める仕組みがログイン。カルテはメールのマジック リンクのみ・招待制。表は34、形を変えた履歴(マイグレーション)は61 本あります。 この列の並びが「データの形」です。後から1列足すのは簡単でも、名前を変えたり消したりするのは高くつく。第3幕でその実話をします。 複眼道場 14
  15. 第2幕 とどける — ミドルウェア 「返す前に、間に挟む」だけの仕組み リクエスト これください ▶ ミドルウェア middleware.ts

    ▶ HTMLファイル 静的な1枚 ▶ レスポンス はいどうぞ なぜ必要になったか やっていること 診断結果をSNSでシェアすると、カードが出る。でも中身は1枚の静的 アクセスしてきたのがSNSのクローラーのときだけ横取りして、URLのパ HTMLなので、そのままだと全員同じカードになってしまう。 ラメータから結果を復元し、その人用の見出しと画像を差し込む。 ときは素通し。 人間の 実物は753行ありますが、やっていることは「条件に合うときだけ、返す前にひと手間かける」だけ。ログイン判定も、言語切り替えも、置き場所はここです。 複眼道場 15
  16. 第3幕 こわれない — 揺らがせない場所 診断は、AIに判定させていない さっき触った複眼道場の中身を開けます。あの診断が返している結果は、AIが考えたものではありません。 揺らがせない場所:判定ロジック 揺らいでいい場所:解釈と深掘り 回答 →

    スコア → タイプ。この計算は人の手で書いたコード。だから同じ 出たタイプを、その人の言葉づかい・状況に合わせて説明する。問い返 回答を入れれば、いつ誰がやっても同じ結果が出る。 す。掘る。 ここは毎回違っていい。むしろ違ってほしい。 詳細診断(実物)— 90問を9タイプの平均点にして // 本人の回答クセを差し引いてから並べ直す // const z = (a.avg - mean) / stddev const sorted = entries.sort((a,b) => b.zScore - a.zScore) 差がつかなかったときは「判定しない」と出す if (stddev < 0.10) trust = 'low' // 順位付けが意味を持たない if (top1 - s.avg <= 0.20) tied++ // 詰まりを検出して警告 // もし全部AIに任せたら 同じ回答なのに毎回タイプが変わる。それは診断ではない。 しかも「差がつかなかったので判定しません」という誠実な出力が、AIに は出せません。 AIが揺らぐのは欠陥ではありません。揺らいではいけない場所に、揺らぐ道具を置いた人が、配置を間違えているだけ。 複眼道場 16
  17. 第3幕 こわれない — ここがいちばん面白い 人間には書けない。でもLLMは1回も呼んでいない この判定ロジックは、AIがいなければ存在していません。それでいて、診断が動いているあいだ、AIは一度も呼ばれていない。 人の手で書いて保守できる量ではない それでも、実行時にAIを呼ばない 診断12種で 合計

    40,143行/条件分岐は if だけで 1,758箇所 ・同じ回答なら同じ結果でないと診断として成立しない 詳細診断1本でも 4,723行・106関数・if 235・三項演算子 132 ・呼ぶたびにお金と時間がかかる ・「差がつかないので判定しません」を気分で省略されると困る 素点 → 回答のクセを補正 → 同順位の詰まり → 天井効果 → クロスタイプ ・ブラウザの中だけで完結する(サーバーが要らない) → 確信度 → そもそも判定を出すか出さないか。条件が掛け算で増えてい く。 AIは、生成の道具であって、実行の道具ではない 「AIを使ったアプリ」と聞くと、動くたびにAIに問い合わせる形を想像しがちです。でも実際にいちばん強いのは、AIに書かせた、揺らがないコード。 作る側にだけAIがいて、使う側には出てこない。この形が取れるようになったのが、いまの変化のいちばん大きいところです。 複眼道場 17
  18. 第3幕 こわれない — 配置の設計 揺らぐ道具に、揺らがない仕事をさせない 確定した事実 入力・保存されたデータ ▶ 確定したロジック 自分が書いた(書かせた)コード

    ▶ AIの判断 解釈・言い換え・対話 やりがちな順序:AIに集計させる 正しい順序:結果をAIに解釈させる ・毎回すこしずつ違う数字が出る ・計算・判定・集計はコードの仕事 ・行を落とす、桁を読み違える ・AIの仕事は、出た結果の説明と提案 ・「なぜその答えになったか」に誰も答えられない ・人に見せる数字はコードの出力であって、AIの生成文ではない 「揺らぐ道具に揺らがない仕事をさせるのは、ハンマーでネジを回そうとするのと同じ」。あなたが作るものにも、必ずこの線引きがあります。 複眼道場 18
  19. 第3幕 こわれない — 預かるということ 預かった瞬間に、責任が発生する 複眼道場の匿名ログ(api/log.js)の冒頭に、ルールが4行書いてあります。全部「事故ってからでは遅い」もの。 決めたこと なぜ 書き込みは INSERT

    だけできる専用の接続で 読み出しも削除もできない鍵を使う。接続情報はブラウザ側に一切置かない 行う 名前・組織名・自由記述はサーバー側で必ず 送信側の善意に依存しない。画面側のうっかりで個人情報が入っても、保存されない 落とす 戻り値は常に本文なし。読み出し経路を作ら 取り出す口がなければ、漏れようがない ない 生のリファラは保存しない(クエリは落と ?token= や ?fbclid= が混ざると、匿名テーブルの前提が崩れる す) ついでに、こういうメモも残っています 「Node関数をTypeScriptで書くと起動時に落ちる(2026-08-09に実測)。だからこのファイルだけ古い書き方にしている」 ── 「動くはず」と「動く」の間には、毎回何かがいます。そのとき調べたことを1行残すかどうかで、次の速度が変わります。 複眼道場 19
  20. 第3幕 こわれない — 実話 データの形は、後から変えるのがいちばん高い 2026年8月14日に起きたこと カルテの日記テーブルで、列の名前を deleted_at → archived_at

    に一発で改名した。同じタイミングで、GitHubからVercelへの自動デプロイが1回だけ取り こぼされた(設定は正常なまま、通知が届かなかった)。 結果:古いコードが新しいテーブルを見にいって、日記一覧が15〜20分ダウン。 だから、こう変えた そして、pushで終わらせない 列の改名は3段階に分ける。① 新しい列を足す → ② デプロイする → ③ git push の後に vercel ls で、自分のコミットが本当に載ったかを見 古い列を消す。どの瞬間でも、新旧どちらのコードも動く状態を保つ。 届ける。「上げたつもり」が事故の半分です。 画面の作り直しは何度でもできます。でもデータの形だけは、動き出した後に変えると本番が止まる。最初のうちは、保存まで行かないことを勧める理由がこれです。 複眼道場 20
  21. DEMO 02 複眼道場カルテ 月次1on1のための「交換日記」アプリ。 診断ツールと違って、こちらは他人のデータを預かっている側です。 できること だから必要になったもの 実物のサイズ 日記を書く/読んだ印をつける/コメントが ログイン(メールのマジックリンク)、デー

    画面 36/APIルート 12/テーブル 34/マイグ 返る/自分の取扱説明書が育つ/セッション タベース、決済(Stripe)、通知(Web レーション 61本。 の記録が残る Push)。全部、保存するから必要になったも 同じ人が、同じやり方で作っています。 の。 — 第2幕で話した 段0 → 段5 が、全部入っているのがこれです。診断ツールとの差が、そのまま「壊れたときの重さ」。 複眼道場 21
  22. 終幕 — 作る前に いきなり作らせない。設計書を先に書く 作る前に決めておくことを、1枚に書く。立派なものは要りません。この6行で十分です。 設計書(このアプリについて) 作るもの:読んだ本を1行でメモして、後から見返すアプリ 使う人:まず自分だけ 当面のゴール:公開してURLを配れる(保存する機能は後まわし) 決めたこと:ログインは無し/1画面/スマホで見る

    やらないこと:通知、共有機能、デザインの作り込み # 書かずに始めると カルテも、この順番で作りました ・決めたことがチャットの上へ流れて消える 設計書 → 画面定義 → HTMLモックで画面レビュー → 実装。設計書には ・「前に決めた仕様」を毎回書き直す 「進め方:画面定義を先に固めてからDB定義を決める」とだけ書いてあり ・そのうち自分でも、何を決めたか思い出せない ます。 いちばん効くのは「やらないこと」の行です。AIは頼めば何でも作ってしまうので、止める線を先に引いておく。 複眼道場 22
  23. 終幕 — 作りながら コンテキストは、対話から蒸留させる 設計書は「作る前」の1枚。ここからは「作りながら」の話です。自分で書く必要はありません。 STEP 1 STEP 2 STEP

    3 まず、普通に仕事をさせる うまくいったら、抽出させる 次から読ませて、育てる 思い通りに動かなければ、根気強くフィードバ やり取りの中に、成功に必要だった前提が全部 次は、そのファイルを読み込ませて始める。 ックする。 入っています。 途中で自分でやってしまわないこと。AIにゴー ルさせるのが大事です。 「この仕事をうまく進めるために必要だった前提と ルールを、再利用できる形でまとめて」 違和感が出たら「もっとこうして」と投げて更 新させる。AIと一緒に育てる。 巨大な1枚を作らない 最初は「自分でやった方が早い」 AIはロングコンテキストが苦手。心を鬼にして、作業ごとに分ける。詰め それで合っています。型ができるまでは時間がかかる。できた後の速度が 込むより、用途を限定して渡すほうが精度が出ます。 変わります。 チャットは流れて消え、別の話題が混ざって汚れる。エディタなら、指示した結果がファイルとして手元に残ります。 複眼道場 23
  24. 終幕 — どこまでAIに渡すか 複眼道場を一人で回すための、15工程 最後に、視野を広げます。コードだけの話ではありません。事業そのものにも「渡していい仕事」と「渡してはいけない仕事」がある。 工程 渡し方 実際どうしたか 課題発見・コンセプト △

    補助だけ 「気持ち」は外から持ってこられない。AIは前提を疑わせる壁打ち相手に徹してもらう ドメイン知識の学習 ◯ 二人三脚 教えてもらうのではなく、自分の言葉で説明して、穴を指摘させる。筋トレに近い プロダクト実装 ◎ ほぼ任せた 9割AI。設計から本番リリースまで1日。人がやるのは「何を作らないか」と動作確認 デザイン・LP ◯ 二人三脚 「初見の人が抱く不信感を全部挙げて」。褒めさせるより百倍役に立つ ネーミング △ 補助だけ 候補100連発 → 全部に却下理由をつける。その過程で自分の基準が言語化される 価格・商品設計 ✕ 渡さない 「この人たちに、この価格を、どういう顔で言えるか」。決めた後の矛盾探しだけAIに ユーザーとの対話 ✕ 絶対に渡さない 売り物そのもの。人が言葉に詰まる瞬間は、会いに行かないと取れない 決済・規約・日々の運用 ◎ ほぼ任せた 叩き台はAI、責任は人。着手の心理コストが高い領域こそAIに初手を出させる 渡すのは作業。残すのは「なぜ」と、人と向き合う時間。この線引きさえ持っていれば、一人でも事業が回る側に立てます。 複眼道場 24
  25. 終幕 — で、人間は何を出すのか Skillsじゃない、Valuesだ コードはAIが書きます。設計書も、聞けば抽出してくれます。 では、人間が出すものは何か。 差別化の場所が、How から Why へずれた

    書くべきは、コードじゃない AIはこの世のあらゆる考え方・価値観を、ほぼぜんぶ知っています。でも ノンエンジニアがAIを使い倒したいなら、書くべきは思想。 「そのどれが適切か」は決められない。 AIが書いたコードに「これでいい」と言える主体がなければ、速く作れて 人間がやるべきは、優先順位付けです。 も行き先がありません。 乗るんじゃない、乗せろ AIに乗せられて「AIビルダー」にされるんじゃなくて、自分の思想にAIを乗せる。 思想と言っても大げさなものではなく ──「自分は何が好きで、何が許せなくて、何を見ているのか」を、自分の言葉で言える状態のことで す。 育て方は、さっきの蒸留と同じです。違和感をメモして、AIに投げてエッセイにしてもらう。1回5分。繰り返し出てくるテーマに気づいたところが、あなたの輪郭です。 複眼道場 25
  26. 終幕 — いちばん効く投資 思想書を書く ── AIに被せるハーネス 違和感をメモ 回分 1 5

    ▶ AIでエッセイに 投げるだけ ▶ 束ねて記事に 溜まったら ▶ 共通テーマを掘る AI に俯瞰させる ▶ 章になり、本になる 気がついたら なぜ、これがAI活用の話なのか 概念は、コンテキスト圧縮装置 AIは賢いけれど、放っておくと暴走するか、凡庸な平均値しか返してこな エニアグラム、インテグラル理論、ニーチェ ── 概念と固有名詞をひと い。 つ共有するだけで、長い説明が要らなくなる。AIが急に頭良くなります。 そこに自分の思想を渡すと、AIが「自分の延長」として動き始めます。第3 だから「似たことを考えている人はいないの?」とAIに聞く。 幕で見た判定ロジック=コードのハーネスの、人間側の版です。 一個一個は、小さい メモを書くだけ。AIに投げるだけ。それが複利のように効いて、3ヶ月後に見返すと量が質に化けている。書くことは、自分を発信するための作業ではなく、自 分を発掘するための作業です。 複眼道場 26
  27. 終幕 — 「何を作るか」を決めるときに 壁打ちで効く、5つの投げ方 ① 「いいですね」と言わせない ④ 「何を作らないか」を先に言う AIは放っておくと肯定してきます。前提ごと疑わせるのが壁打ちの役目。 時間は必ず足りなくなります。実装力より、削る判断が成果物を決めま

    「賛成も反対もせず、この案の前提を3つ疑って」 す。 「まず動くものを出すために、削るべき機能を提案して」 ② 「これは許せない」から始める 作りたいものが出てこないときは、過去に腹が立ったことをAIに整理させ ⑤ 不信感を列挙させる るのがいちばん早い。気持ちは外から持ってこられません。 できた後にもう一手。 「初見の人がこの画面に抱く不信感を全部挙げて」 自分で書いた文章の盲点は、自分では見えません。 ③ 却下理由を100個つける 案でも名前でも、候補を大量に出させて全部に却下理由をつける。選ぶ作 業ではなく、自分の基準を言語化する作業です。 そして、迷ったら人に聞く 「この結果をどう解釈すべき?」とAIに聞き始めたら、一回、使う人に会 いに戻るサイン。AIより先に、人に聞く。 複眼道場 27