なぜたった7日で12万行のSaaSを個人開発できたのか。Claude Codeが迷わず動くAI環境作りの理由

冒頭フック

7日間。122,213行のコード。

Stripe課金からAIレコメンドまで完備した巨大SaaSが爆誕した。

開発体制は人間1人とClaude Codeの6エージェントのみ。

これは魔法でもなんでもない。

圧倒的な生産性を生み出す、全く新しい開発手法の証明だ。

AIにコードを書かせることより、AIが迷わず動く「環境」を作ることに主戦場が移った。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

ニュースの概要

個人開発の常識が完全にぶっ壊れた。

実質7日で12万行を超えるSaaSがリリースされた。

単なるペラペラのモックアップではない。

16タイプのエンジニアスキル診断機能を備えている。

AIによる学習技術のレコメンド機能が動く。

用語を登録して経験値を貯めるゲーミフィケーション要素まで入っている。

さらに面談前の案件マッチ度チェック機能も完備だ。

当然のようにStripeによる課金導線も組み込まれている。

toC向けに蓄積したデータを、将来的にtoBの採用担当へ展開する複雑なデータ設計まで最初から仕込まれている。

これを実現したのがClaude Codeによる6エージェント体制だ。

単にAIにプロンプトを投げ続けて完成したわけではない。

泥臭いトライアンドエラーの裏には、極めてシステマチックな設計思想が存在する。

鍵となるのがHarness Engineering（ハーネスエンジニアリング）と呼ばれるアプローチだ。

AIエージェント向けのSkill（スキル）をどう設計するかが勝負を分ける。

コンテキストは極めて希少な資源だ。

設定ファイルは500行以下に抑えることが推奨されている。

ルールを詰め込みすぎると、AIは注意力の希釈を起こす。

すべてが重要だと指示されたAIは、結局何も重要だと認識できなくなる。

だからこそ、いつ起動するかを明確にする必要がある。

トリガー条件を明記し、AIが自律的に動ける条件を極限まで絞り込む。

人間が手動でAIを動かすのではなく、AI自身が必要なタイミングでサブエージェントを起動する仕組みを作る。

さらに、ターミナルやブラウザの操作権限をAIに渡すツールの活用も進んでいる。

AIが自分でターミナルのペインを分割し、コマンドを叩く。

ブラウザでプレビュー画面を開き、UIの状態を自律的にチェックする。

進捗状況をMarkdownファイルに書き出し、リアルタイムで画面に表示させる。

開発者の役割は大きく変化した。

コードの生成結果を人間が修正するのではない。

AIが正しく自律実行できるコンテキスト設計と環境構築を行う。

AIを単なるコーディングの助手として扱うか、自律的な開発マシンとして扱うか。

このギャップが、12万行を7日で駆け抜けられるかどうかを決める。

開発者目線の解説

AIエージェント開発の真のボトルネックは、AIの頭の悪さではない。

最大の敵は「コンテキストの肥大化」だ。

プロジェクトが大きくなると、AIは過去の指示を忘れ始める。

関係ないファイルを書き換え、突如として謎のバグを生み出し、無限ループに陥る。

ここで多くの開発者が最悪の罠にハマる。

AIのミスを防ぐために、設定ファイルに「クリーンアーキテクチャの原則」や「SOLID原則」を長々と書き足してしまう。

現在のLLMは、そんな一般的な技術論は事前学習の段階でとっくに理解している。

それをわざわざ毎回のセッションで読み込ませるのは、貴重なコンテキストの無駄遣いでしかない。

プロジェクト固有のルールだけを極限まで削ぎ落として渡す。

ここで重要になるのがin the loopとon the loopという概念の違いだ。

AIが生成したコードがおかしいとき、人間が手作業でコードを直すのがin the loopだ。

一方、AIが期待通りの結果を出すように、AIを動かす環境（ハーネス）そのものを修正するのがon the loopだ。

12万行のSaaSを7日で作るような人間は、間違いなく後者のアプローチをとっている。

AIの出力を人間がいちいち直している暇などないからだ。

しんたろー：
12万行を7日って、冷静に考えて頭おかしいスピードだよね。
うちのThreadPost構成でもClaudeのコンテキストが限界突破しがちだから、このルールの断捨離は効きそうだと思ってる。

さらに、AIに環境を操作させる具体的な手法がある。

ブラウザの自動操作だ。

従来のAIは、DOM全体を読み込んでCSSセレクタを推測し、要素をクリックしようとしていた。

DOMが少し変わるだけでAIは要素を見失い、操作は完全に停止する。

最新のアプローチは全く違う。

画面の操作可能な要素に直接番号を振る、スナップショット方式を採用している。

ボタンには1番、入力フィールドには2番といった具合に、視覚的なオーバーレイで番号が振られる。

AIはセレクタを推測する必要がない。

「要素1にテキストを入力」「要素2をクリック」と直接指定するだけだ。

読み込み完了やURLの変更を待機するWaitパターンを組み合わせることで、AIは人間と同じように画面の遷移を確認しながらテストを進める。

ターミナル横でMarkdownの進捗表をリアルタイム更新させる手法も秀逸だ。

Claude Codeにタスクを依頼すると、ターミナルには大量のログが高速で流れ続ける。

人間がそれを目で追うのは不可能だ。

だからAI自身に計画をMarkdownに書き出させ、タスクが終わるたびにチェックボックスを更新させる。

ファイルの変更を自動検知してプレビューを更新する環境さえ作ればいい。

人間は隣のペインのチェックボックスを眺めているだけで、今どこまで開発が進んでいるのかを一目で把握できる。

コーディング、プレビュー、進捗管理。

これらすべてが、AIの自律的な操作によってターミナル内で完結する。

これがHarness Engineeringの真髄だ。

AIの能力を引き出すのは、プロンプトの魔法ではない。

AIが迷わず、ミスなく、自律的に走り続けられる「レール」を敷く技術だ。

このレールさえ敷いてしまえば、あとはAIが勝手にコードを量産し、テストし、完成まで持っていく。

しんたろー：
AIにDOM全体読み込ませてエラー吐きまくるの、マジで「あるある」すぎる。
スナップショット方式で番号振るアプローチ、ThreadPostの構成でも安定したテストが組めそうで気になってる。

実務への影響

で、僕らの日々の開発にどう関係するのか。

巨大なプロンプトファイルや指示書を見直すところから始まる。

「コードの可読性を高めること」みたいなポエムをAIに読ませる時間は終わった。

必要なのは、プロジェクト固有の絶対的な制約だけを残すことだ。

例えば「APIのレスポンス形式は必ずこのJSONスキーマに従う」といった、LLMが推測不可能なローカルルールに限定する。

そして「いつ、どのSkillを起動するか」というトリガーを明確に定義する。

起動条件が曖昧なSkillは、存在しているだけでコンテキストを消費する負債になる。

実行してほしくないタイミングを明記する否定形のトリガーも極めて有効だ。

次にやるべきは、AIの進捗を視覚化する仕組みの導入だ。

ターミナルに流れるAIの思考プロセスを人間が監視するのは時間の無駄だ。

ターミナルを分割し、左側でAIのエージェントを走らせる。

右側にはMarkdownのビューアを開き、下部にはブラウザのプレビュー画面を配置する。

AIにタスクの全体計画を立てさせ、それを右側のMarkdownファイルに出力させる。

タスクが完了するごとに、AI自身にそのファイルのチェックボックスを更新させるルールを追加する。

これだけで、人間は「AIが今何をやっているのかわからない」というストレスから完全に解放される。

AIのエラーを人間がカバーするのではなく、AIがエラーを起こさないワークスペースを作ることに注力する。

ブラウザの自動テストやプレビュー確認も同様だ。

AIにDOMを読ませて推測させるような不安定な仕組みは今すぐやめる。

スナップショットで画面要素に参照番号を振り、AIに直接操作させるツールを導入しよう。

ナビゲーションの移動やモーダルの開閉が起きるたびに、必ず画面の再取得を行わせる。

この確実なステップを踏ませることで、AIの自律的なブラウザ操作は初めて実用レベルになる。

開発者の役割は「コードを書く人」から「AIのワークスペースを設計する人」へと完全にシフトした。

7日で大規模SaaSを組み上げるのは、一部の天才だけの特権ではない。

正しいレールさえ敷けば、誰でも到達できる領域になりつつある。

AIが最高のパフォーマンスを発揮できる最高のオフィス環境を、ターミナルの中に構築する。

それが、現代の開発者に求められるスキルだ。

しんたろー：
プロンプトにSOLID原則とか書いてた過去の自分を殴りたい。
AIが賢くなってるんだから、人間側も余計なお世話をやめる勇気が必要なんだよな。

FAQ

Q1: Claude Codeに独自のSkillを追加する際、最も気をつけるべきことは何ですか？

A1: コンテキストの肥大化を防ぐことだ。設定ファイルは500行以下が推奨されている。LLMが既に知っている一般的なアーキテクチャの原則などは潔く省き、プロジェクト固有のルールに極限まで絞り込もう。そして、いつ起動すべきかというトリガー条件を明記し、AIが自律的に適切なタイミングで呼び出せるように設計する。無駄な指示はAIの注意力を奪うだけだ。

Q2: AIエージェントにタスクを任せると、今何をしているのか分からなくなります。良い進捗管理方法はありますか？

A2: AIにタスクの計画をMarkdownファイルに書き出させ、完了ごとにチェックボックスを更新させる方法が最強だ。ターミナル横でMarkdownをリアルタイムプレビューするツールを使えば、人間はAIの大量のログを必死に追いかけなくても済む。隣のペインのチェックボックスを眺めるだけで、進捗を直感的に把握できるようになる。AIの自己管理能力を最大限に引き出す工夫だ。

Q3: ブラウザの自動操作をAIに任せる場合、CSSセレクタの推測エラーが起きませんか？

A3: 従来のDOM全体を読み込ませてCSSセレクタを推測させる方式ではエラーが頻発する。画面の操作可能な要素に直接番号を振るスナップショット方式を採用したツールを使おう。AIは「要素1にテキスト入力」「要素2をクリック」といった形で直接かつ正確に操作できるようになり、ブラウザ操作の安定性が向上する。DOMの変更に強い堅牢なテスト環境が構築できる。

まとめ + CTA

AIにコードを書かせることから、AIが走るレールを敷くことへ。

環境作りを制する者が、これからの個人開発のスピードを支配する。

AIの能力を最大限に引き出すワークスペースを構築しよう。

👉 ThreadPostでSNS運用を自動化する