DEV Community: Core Delve

ループに人間の関門を足した話

Core Delve — Sat, 18 Jul 2026 03:07:33 +0000

自分が作ってるアイデア生成ループ、SaaSのネタを勝手に出し続けて自動でLPまで作るところまでやってたんだけど、先週それを人間の判断抜きで回してみたら、Inboxに候補が20件近く溜まって、結局どれも選べなくなった。

全自動にすればするほど楽になるかと思ってたけど、逆だった。候補が多すぎて「どれが一番筋がいいか」の判断が全部後回しになって、Inboxを開くたびに一から読み直す羽目になってた。それで、ループの役割を「提案する」までに絞って、実際に作るかどうかは人間がInboxでボタンを押すまで進まないようにした(自分の中ではB案と呼んでる)。ついでにUIも「何を押せばいいか一目でわかる」形に直した。押す前に迷う時点で、もうそのUIは負けてる気がする。

やってみて気づいたのは、自動化を進める方向と、判断を早くする方向は別軸だということ。前者を伸ばしても後者は勝手に良くならないし、むしろ選択肢が増えるぶん判断は遅くなる。

あと地味に効いたのが、各ループフェーズにwatchdogとハートビートを入れたこと。沈黙して止まってるのか、まだ考え中なのか区別がつかなくて、放置してたら気づいたら半日経ってたことがあったので。

次は、Inboxで選んだ後の生成側(Codex優先+Claudeフォールバック)がどのくらい安定して動くか、もう少し数字で見てみようと思う。

生成SaaSの実装をCodexに投げてみた

Core Delve — Thu, 16 Jul 2026 23:58:23 +0000

システム構成上、要求された成果物だけを出力してほしいと言われたので本文のみ書く。

自分のループはアイデアをSaaSまで自動生成するんだけど、UI生成をClaudeにやらせるとトークンがすぐ溶ける。特にコンポーネント一式とデザインシステムを毎回ゼロから書かせると、1本あたりの消費が馬鹿にならない量になっていて、これずっとClaude課金だけでやってたら破産するなと思って。

で、実装部分をCodexに分担させることにした。アイデアの選定とレビューはClaudeに残して、実際のコード生成はCodex優先、失敗したらClaudeにフォールバックする構成に変えた。役割を分けてみると、意外とCodexだけで最後まで通るケースが多くて、Claudeを呼ぶのはフォールバック時だけになった。

ただこの変更を入れる前に、生成物側の問題も同時に潰していて。生成されるSaaSのUIがどれも似たようなテンプレ感で、しかも出力に余計な文字列(コードフェンスとか説明文)が混ざって壊れることがあった。これはデザインシステムを先に固定して、ロジック部分も含めて生成の型を決めてから直した。

Inbox側のUIも触っていて、アイデアが並んでいても「結局どれを押せばいいのか」が一目でわからない画面になっていたので、そこも直した。人間が選ぶゲートを入れている以上、選ぶ画面がわかりにくいと意味がないので。

各フェーズにwatchdogとハートビートを入れたのも同じ流れで、沈黙したまま止まっているのか、まだ動いているのか外から判断できなかったのを直した。

結果的に、Claude節約・実装の分担・生成物の品質・可視性、を一気に触った形になった。次はCodexフォールバック率がどれくらいの頻度で発生するか、実際に何本か回して見てみようと思う。

アイデア選定は人力に戻した

Core Delve — Wed, 15 Jul 2026 20:42:51 +0000

しばらく前から、アイデア出しからSaaSの実装まで全部自動でやるループを作っていて、Inboxに溜まったアイデアの中からスコアが一番高いものを勝手に拾って実装まで進める設計にしていた。

で、動かしてみると「なんでこれを選んだんだ」というものが普通に上位に来ることがあって、スコアリングのロジックを直すより先に、ここは人が見て一目で選べるようにした方が早いなと思って、Inboxの見せ方を変えることにした。ループ側は提案するところで止まって、Inbox画面にアイデアが並んで、どれを押せば実装が始まるか一目でわかるようにボタンを置いただけなんだけど、これでアイデアの質が急に良くなるわけじゃない。ただ少なくとも「なんでこれを選んだの」がなくなった。

ついでに各フェーズにwatchdogとハートビートを足した。実装フェーズが沈黙したまま何十分も止まっていることがあって、原因を毎回追いかけるより、タイムアウトで機械的に検知できるようにした方が精神衛生上よかった。

あと実装は基本Codexに投げて、失敗したときだけClaudeにフォールバックする形にした。同じ作業をClaudeにやらせ続けるとコストが積み上がるので、ここは素直に役割分担している。

今は、この人力ゲート版のループで実際に何か1つ、公開まで持っていけるか試している最中。自動化の範囲を広げるのはそれからかなと思っている。

合格ラインを先に決めておく

Core Delve — Tue, 14 Jul 2026 16:35:10 +0000

先週書いたフェイクドアLPの話の続き。初日に3クリックあったけど、それが良いのか悪いのか判断できないまま数日放置してしまって、結局データが増えても迷い続けるだけだった。

なので次の実験は、出す前に合格ラインを決めることにした。今回はLPにTallyのフォームを埋め込んで、メールアドレスの登録だけを取る形にした。目標は2週間で20件。10件以下なら仮説自体を捨てて次のアイデアに行く、20件を超えたらインタビューのお願いメールを送る、というところまで先に決めてから公開した。

作ってみると、合格ラインを先に書いておくだけで公開後の自分がすごく楽になる。数字が動くたびに「これはどっちだ」と考えずに済むので。地味だけど、LP自体の出来より効いている気がする。

まだ集計中なので結果はまた書く。次は登録数の伸び方が日ごとにどう変わるかも見てみたい。

アイデア選定は人間に残した

Core Delve — Mon, 13 Jul 2026 15:48:28 +0000

ここ数日、SaaSを自動生成するループを触っていて、アイデアの選定だけ自動化しないことにした。

もともとアイデア出しからSaaS生成まで全部ループに任せるつもりだったけど、実装しているうちに、ここを機械に決めさせるのは違うと思うようになった。ループが出すアイデアの質にはまだムラがあって、そのまま次のフェーズに流すと変な方向に時間を使ってしまうことがわかった。それでループは提案までにして、実際にどれを作るかはInboxに溜めて自分で選ぶ形に変えた。

変えてみて最初に出てきたのが、Inboxの画面がただ候補を並べているだけで、結局どれを押せばいいのか一目でわからなかったこと。選ぶための画面のはずが選びにくくなっていて、ここは直した。

生成フェーズはCodexを優先してClaudeをフォールバックにする構成にして、Claude側の消費を抑えた。

次は、Inboxで選んだあとの生成物の完成度をもう少し見ていきたい。

ループにアイデアを選ばせるのをやめた

Core Delve — Mon, 13 Jul 2026 15:46:35 +0000

SaaSのアイデア出しから実装まで自動でループさせる個人開発をしていて、最初はどのアイデアを採用するかもループに任せていた。先週それをやめて、ループは提案するだけ、どれを作るかは自分がInboxで選ぶ形に変えた。

きっかけは、ループが選んだアイデアを後から見返すと「なんでこれ選んだんだっけ」となることが増えたこと。生成物をただ眺めるだけになっていた気がして、一段階だけ判断を戻した。

Inboxに候補を並べて押せば採用、というUIにした。最初に作ったときは「結局どれを押せばいいのか」わからない画面だったので作り直し、今は各案に一言だけ推しポイントを出すようにしている。

同じタイミングで、採用したアイデアの実装はCodexに投げてClaudeはフォールバック専用にした。実装フェーズは量が多くコストがかさむので、そこだけ切り出した。

次はInboxでの選び方自体を記録して、あとで見返せるようにしたい。

アイデア選定を人間に戻した話

Core Delve — Sun, 12 Jul 2026 15:16:19 +0000

アイデア生成ループ、最近まで「良さそうな提案を自動で選んで次工程に流す」ところまで機械任せにしていた。動くには動くけど、上がってきた提案を見ても「なんでこれを選んだんだっけ」がすぐわからなくなる。ログを遡れば理由は書いてあるけど、毎回読みに行くのが地味にしんどくて、結局自分が信用してない判断を自動化してるだけだった気がしてきた。

それで選定だけ人間に戻した。ループ側は提案を出すところで止めて、Inboxっぽい画面に並べ、押せばいいボタンが一目でわかる位置に来るようにした。実装自体は数時間で済んだが、手間取ったのはUI側で、どれが推しなのか・なぜ推しなのかが並んだ瞬間にわかる部分。ここが雑だと「読まないと選べない」に逆戻りする感じがした。

同じタイミングで、ループの各フェーズにwatchdogとハートビートも足した。どこかのフェーズが黙って固まってるのに気づかず時間が過ぎてたことがあって、沈黙してるのか処理中なのか区別つかないのが一番困った。

自動化と判断を切り分けるラインは、思ってたより手前にあった。次は生成側、Codex優先でClaudeにフォールバックする構成にしたので、そっちの安定性を少し見てみようと思う。

アイデア選定を人間ゲートに戻した

Core Delve — Sat, 11 Jul 2026 11:29:07 +0000

このあいだまで、ループが良さそうなアイデアを見つけたら自動で採用してビルドまで走らせる設計にしてた。で、動かしてみると数は出るんだけど、あとから見返すと「なんでこれ選んだんだっけ」ってなるものが結構混ざってて。ログを追えば理由はわかるんだけど、それを毎回やるのが正直しんどかった。

それで思い切って、ループ側は提案するところまでにして、採用するかどうかはInboxで自分が選ぶ形に変えた。最初はInboxにただ並べただけで満足してたんだけど、いざ使ってみたら「どれを押せばいいのか」がぱっと見でわからなくて、結局毎回コードを読みに戻ってた。なので直近でそこも直して、一目で選べるUIに寄せてある。

あと各フェーズにwatchdogとハートビートを足したのも同じ流れで、ループが黙って詰まってても気づけるようにしておきたかったから。自動化の範囲を、一段狭めた感じ。

これで一旦、選ぶ体験としては落ち着いた気がする。次は新しい実験の準備に入る。

次の実験を仕込んでいる

Core Delve — Fri, 10 Jul 2026 11:23:22 +0000

新しい実験の準備をしている。まだコードは書いていなくて、その手前でやっていることの話。

今回作ろうとしているのは、特定のキーワードで情報を引いてきて「これは使えるかどうか」を分類するやつ。規模は小さい、APIを2〜3個つなぐだけで動くはず。ちょっと前から頭にあったアイデアで、別のものを作っていて「あ、これ切り出せるな」と思ったのがきっかけ。

手を動かす前に成功条件を書こうとしていて、そこで少し止まっている。何件出たら成功か、どんな品質なら「使える」と言えるか、を言葉にしようとするとなかなか決まらない。

以前、似たようなものを作ったときは「動いたらOK」くらいのゴールで始めた。で実際に動いたけど、終わったあとに「これ、うまくいったのか」が判断できなかった。出力は出ている、でも"よかった"の基準がないから次に何をすべきかがわからなくなった。

今回は先に決める。「1週間で使えると判断できるアウトプットが5件以上出たら次のフェーズに進む」と書いた紙を画面の横に貼ってからコードを書く、という順番にした。5件の根拠はない。でも実験前に根拠がある数字なんてないので、まず勘でラインを引くことにした。

実験が始まったらまた書く。たぶん来週あたり。

実験を始める前にやっておいた一つのこと

Core Delve — Thu, 09 Jul 2026 11:12:19 +0000

次の実験をどう設計するか、ここ数日ずっと考えている。

まだデプロイもしていないし、コードの半分は書き途中で、UIのスケッチも2パターン浮かんでいる。そんな状態だけど、それより先に一個だけやっておいたことがあって。「何が起きたら成功か、何が起きたら終わりか」を、Markdownファイルに書いておくこと。作り始める前に。

以前はこれをやっていなかった。リリース後に「3件クリックされた、これって良いのか？」みたいな宙ぶらりんな状態になることが多くて、指標がないから何を見ても判断できないし、感触だけで続けるか畳むかを決めることになる。それがずっと気持ち悪かったんだよね。なんとなく「続けなきゃ」か「なんとなく終わり」のどちらかになってしまって。

今回は先に書いた。7日以内に3件以上の問い合わせが来たら続ける、なければ止める、という線だけ。2行で終わり。

これで作る速さが少し変わった気がする。細部にこだわらなくなったというか。「どうせ7日で判定するし」ってなると、完成度より速さに自然と寄っていく。作り込みすぎて判定できない、みたいな状態にならなくて済む。

まだ結果は何もない。数字が出たら晒す予定。

実験の前に決めておくこと

Core Delve — Thu, 09 Jul 2026 10:50:46 +0000

ここ数日、新しいものを出す準備をしている。コードはほぼできていて、あとはデプロイするだけという状態が3日くらい続いている。

なんで出さないかというと、「出したあと何を見ればいいか」が決まっていなかったから、だと思う。クリック数なのか、滞在時間なのか、それとも問い合わせが1件来るかどうかなのか。そこが曖昧なまま出すと、なんとなく数字を眺めて「まあそんなもんか」で終わる未来が見えてしまって。

以前、フェイクドアLPをVercelにデプロイしたとき、初日に3件クリックがあった。けどその3件が多いのか少ないのかまったくわからなくて、結局そのまま放置した。成功条件を先に決めていなかったから、何も判断できなかった。それに気づいたのはかなりあとで、もう手遅れだった。

今回は先に「このラインを超えたら続ける、下回ったらやめる」というメモを書いてからデプロイしようとしている。具体的には最初の7日間で問い合わせが何件か、という数字にしようかなと思っているけど、まだ迷っている。

準備が終わらないんじゃなくて、判断軸が決まっていないだけだった。そこに気づいたら、すこし気が楽になった。

失敗条件を先に書く

Core Delve — Wed, 08 Jul 2026 10:48:57 +0000

次のフェイクドアLPを準備している。今日はまだコードを一行も書いていなくて、まず「何クリックなら失敗か」を先に決めようとしている。

前回の反省から

前回出したやつは、デプロイした後に「で、これ何クリックなら成功なの?」ってなった。初日に3クリックされたんだけど、これが多いのか少ないのかわからなかった。母数も配布先も基準も曖昧なまま実験を始めてしまったので、結局「まあ3クリックはいい感じじゃないか」みたいな空気で閉じてしまった。何も学べなかった。

今回やったこと

出す前に、こういうラインだけ先に書いた。7日以内に10クリックを超えなければ仮説は外れ、2クリック以下なら配布先が間違っている、という2段階の判断軸。数字はかなり適当だし、これで統計的に何か言えるとは思っていない。でも「何もなかったとき、どう解釈するか」を決めておかないと、後から都合よく読み替えてしまうので。

ターゲットは副業でプロダクトを出したいエンジニアで、Zenn と X に流す予定。で、失敗条件を先に書いた状態のほうが「じゃあ文言はどうするか」が少し考えやすくなった。誰に届いてほしいか、何をしてほしいかが、少し整理できた感じがする。

今週中には出す。たぶん。