tsubasatwi( つばさ） 
AIのおかげで、何でも作れるようになった。
毎週1プロダクト、というペースでプロトタイプを量産できるようになったし、実際にクライアント企業に導入して「これ、業務で使えます」と言ってもらえるものも増えてきた。
今週だけでも、Firebaseプロジェクトが2つ増えた。片方はStripeのサブスクリプション＋従量課金の実装、もう片方はメール配信ソフトウェア。さらに企業向けの研修コンテンツも作った。どれも単体で1週間以上はかかるような案件。それを並行してやれている。
これと同時に、ライブ配信用のOBSツールのプロトタイプも作ったし、LPにいたっては、今月いくつ作ったかもう覚えていない。
React、Firebase、Gemini API。ツールを組み合わせれば、昔なら3人チームで1ヶ月かかっていたものが、1人で1週間で形になる。脅威の時代としか言いようがない。
正直、気持ちいい。「作れる」という感覚は中毒性がある。
でも最近、1つ気づいたことがある。
「言われた通り作る」は、もう武器にならない
これだけ作れるようになっても、だ。
先日、ある旅行会社からこう言われた。
「お客さんからの問い合わせメールをAIに読ませて、自動で返信文を作れるシステムが欲しいんです」
はいはい、できますよ。メール本文をGeminiに食わせて、過去の返信パターンを学習させて、テンプレートに流し込めばいい。技術的には2〜3日で動くものが作れる。
で、実際に作り始めた。
メールのパーサーを書いて、AIに意図を分類させて、返信テンプレートを生成して。
3日後には動くプロトタイプができた。
見せた。
「…うーん、なんか違うんですよね」
あ、これ知ってる。この空気。
何が起きていたか
「問い合わせメールからAIで返信を作る」というのは、クライアントが考えた解決策だった。
もう一歩踏み込んで聞いてみた。
「直近で一番大変だった案件って、どれですか？見せてもらえますか？」
すると、実物を見ながら話してくれた。
「これ、返信するのに丸2日かかったんですよ。何が大変って、うちの提携先が500施設以上あって、お客さんの条件に合う宿とアクティビティの組み合わせを探すのがまず半日。それが決まらないと旅程が組めないし、返信も書けない。メールに書いてあるのは『家族4人で、夏休みに、自然が多いところ』くらいの情報なんで…」
そこか。
ボトルネックは「返信メールの作成」じゃなかった。「500以上の施設から最適な組み合わせを選ぶ」のに時間がかかっていた。
メールは手がかりの1つに過ぎなくて、そこにAIをかけても、施設選定の問題は1ミリも解決しない。
作り直した
方針を変えた。
メールのパーサーは全部捨てた。3日分のコード、約900行。全削除。
代わりに作ったのは、こういうもの。
- お客さんの要件をテキストで入力する（「家族4人、8月、自然体験、予算15万」）
- AIが500以上の施設から最適な宿×アクティビティを自動で選ぶ
- 選ばれた組み合わせで旅程プラン付きの提案書を自動生成する
これを見せたら、反応が全然違った。
「え、これ。これですよ。これが欲しかった。」
最初の3日間は、何だったのか
無駄だったか？ と聞かれると、完全に無駄だったとは思わない。作ったから「違う」と気づけた部分もある。
でも、正直に言う。最初に30分、正しい質問をしていれば、3日分の遠回りはなかった。
Stripeの決済実装もメール配信ソフトもOBSツールも、全部並行で回せる時代だ。3日あればもう1つプロダクトが作れる。その3日を「言われた通り作った」で溶かした。
「メールからAIで返信を作りたい」と言われた瞬間に、こう聞けばよかった。
「直近で一番大変だった案件、1つ見せてもらえますか？」
実物を見れば、ボトルネックがメール返信じゃなくて施設選定にあることは、すぐにわかったはずだ。
技術力が高い人ほど、このワナにハマる
これは能力の問題じゃない。構造的なワナだと思う。
クライアントが「〇〇を作ってくれ」と言う。技術力があると、それを作れてしまう。作れてしまうから、「本当にそれが正解か？」を問い直すタイミングを失う。
動くものができてしまうと、「なんか違う」の原因を探すのにさらに時間がかかる。コードが手元にあると、捨てるのも心理的に難しくなる。
「作れる」が足を引っ張る瞬間がある。
1週間でFirebaseプロジェクト2つ立ち上げて、Stripe決済を実装して、LPを何枚も量産できる。その生産性が高ければ高いほど、「間違った方向に全速力で走る」リスクも大きくなる。
振り返ると、これに似た経験は他にもある。「売上ダッシュボードを作ってくれ」と頼まれて、グラフやフィルタをきれいに組んで納品したら、「見たかったのはリアルタイムの異常値アラートだった」と言われたこともある。本当に欲しかったのは毎朝チェックする画面じゃなくて、ヤバい時だけ通知してくれる仕組みだった。ダッシュボードは手段で、目的は「問題の早期発見」だった。
パターンはいつも同じだ。クライアントは「解決策」を依頼してくる。でも本当に解くべきは、その裏にある「課題」の方。
今はこうしている
クライアントが手段（「〇〇を作ってくれ」）で依頼してきた時、コードを書く前に3つ聞くようにしている。
1.「直近でそれが必要になった場面を、1つ教えてください」
抽象を殺す質問。「メール返信を自動化したい」が「先月の○○様の案件で2日かかって…」に変わる。人間は具体的なエピソードを語り始めると、抽象的な依頼では出てこなかった情報が自然にこぼれ落ちてくる。そこに本当の課題がある。
2.「それが無い今、どうやっていますか？」
本当のペインを炙り出す質問。今の代替手段 ＝ 本人が一番つらいと感じている作業。「Excelで施設リスト検索して、手作業で旅程組んで…」→ 施設選定が重い、とわかる。ここにこそAIをかけるべきで、メール返信の自動化ではなかった。クライアント自身も、聞かれて初めて「あ、大変なのってそこだったわ」と気づくことが多い。
3.「それができたら、次に何をしますか？」
真のゴールを暴く質問。「お客さんに提案書を送ります」→ つまりゴールは「提案できる状態の旅程プラン」であって、「メール返信の自動化」ではない。依頼された機能の「先」を聞くと、本当に届けるべきアウトプットの形が見える。
この3つの質問に30分かけるだけで、その後の数日間の方向性が根本的に変わる。
プロダクトマネジメントの世界では「Jobs to Be Done」とか「5 Whys」とか、似た考え方にいろんな名前がついている。でも現場では、フレームワークの名前なんてどうでもいい。大事なのは、コードを開く前に「本当にこれで合ってる？」と立ち止まる習慣があるかどうかだ。
何でも作れる時代の、次のレベル
2026年、AIツールを使えば誰でもそこそこのものが作れる時代になった。
毎週プロダクトを作れる。Stripe決済もFirebase認証もAI統合も、並行して回せる。クライアントに納品できる。それは素晴らしいことだし、実際にお金になる。
でも、「もう1段上」はそこにはない。
次のレベルは、「作る速さ」じゃなくて「作らない判断の速さ」にある。
クライアントが言った通りに作るのは、もはやAIでもできる。人間がやるべきは、「本当に作るべきものは何か」を見極めること。
そしてそれは、コードを書く前の30分で決まる。
正しいものを、正しい順序で、最小限だけ作る。
何でも作れるからこそ、何を作らないかで差がつく。
自分への戒めも込めて、書いておく。
そして、もしあなたが今まさに何かを作っている最中なら、1つだけ聞かせてほしい。
それ、本当に「作るべきもの」で合ってますか？
※ 本記事のエピソードは、実体験をもとに業界・内容を一部変更して構成しています。
