企画・設計・コーディング・テスト・デプロイ・運用 ── すべての工程でAIを協働者にする。コミュニケーションコストゼロ、判断の一貫性、機動力の最大化。十章で築く、個人の生産性の極限
かつて「規模の経済」は組織の専売特許だった。2026年、その前提が崩れた
チームで作るから品質が上がる、という時代があった。デザイナーがワイヤフレームを引き、エンジニアがコードに落とし、テスターがバグを探し、PMが全体を調整する ── 分業が生産性の源泉だった。しかし分業には代償がある。コミュニケーションコストだ。
打ち合わせ、認識合わせ、仕様変更の伝達、コードレビューの順番待ち、意思決定の上申、デザインと実装の乖離 ── これらはすべて、チームが大きくなるほど比例して増える摩擦だ。ブルックスの法則はこれを1975年に既に指摘していた。「遅れているソフトウェアプロジェクトへの人員追加は、さらに遅らせる」と。
AI協働ツールの成熟は、分業の利益をほぼそのまま個人に与えながら、コミュニケーションコストをゼロにするという転換をもたらした。一人の開発者が、AIという「瞬時に応答し、文脈を理解し、専門知識を持つ協働者」を複数同時に動かせる。これはチームに対する個人の、構造的な優位だ。
本書は、この転換を最大限に活かす指針だ。「AIを道具として使う」という受動的な話ではない。AIを協働者として設計し、工程全体を一人で完結させるという能動的な構造の話だ。企画から本番運用まで、すべての工程でAIをどう組み込むか。その全体像を十章で描く。
ただし一つ先に言っておく。「AIがあれば誰でも開発できる」という話ではない。本書が想定するのは、Webの基礎知識を持ち、自分が何を作りたいかを言語化できる人間だ。AIはその判断を加速し、実行を代替する。判断そのものは、依然として人間のものだ。
「人が少ない」は弱点ではない。「摩擦が少ない」という強みだ
「一人では限界がある」という常識を、まず解体するところから始める。この常識が指す「限界」は二種類ある。一つは作業量の限界（一人の手は二本しかない）、もう一つは専門性の限界（一人がデザインも開発もできるわけがない）。2026年現在、この両方をAIが大きく押し上げた。
5人チームで1ヶ月かかるプロジェクトを想像する。5人×1ヶ月＝5人月の作業時間が使われる。しかし実際に「作業」に使われる時間はそれより遥かに少ない。ミーティング、Slackの往復、仕様書のレビュー待ち、PR（プルリクエスト）のマージ待ち、環境差異のデバッグ ── これらが「作業時間」を侵食する。
Paul Graham は "Maker's Schedule, Manager's Schedule"（2009）で、作る人間のスケジュールは会議一つで半日が壊れると書いた。チーム開発には、必然的にこの破壊が組み込まれている。一人で開発するとき、この破壊はゼロだ。誰も割り込まない。認識の齟齬が生まれない。決定が即座に実行に移る。
コミュニケーションコストゼロの効果は線形ではなく複利で積み上がる。一つの決定がすぐ実行に移り、その結果がすぐフィードバックされ、次の決定がより良くなる。このサイクルが1日10回回る一人と、1日2回しか回らないチームの差は、一週間後には埋めがたい距離になる。
チームが持てないもので、一人が持てるものがある。ビジョンの完全な一貫性だ。デザインの細部から、コードの変数名の選び方から、コピーの語調まで、すべてが一つの頭から出てくるとき、それらは自然に整合する。チームでは、この整合を作るために「デザインシステム」「コーディング規約」「トーンガイド」という文書が必要になる。それを守らせるための時間もかかる。
一人で作ったプロダクトが持つ独特の統一感は、これが理由だ。Craigslist、Instagramの初期、Notion の初期バージョン ── 小さいチームや一人が作ったものには、チームで作ったものが持ちにくい「一つの頭から出た」感がある。
全てで一人+AIがチームを超えるわけではない。正直に分けておく。
本書が射程とするのは前者だ。小さく始めて検証し、育てるWeb制作の全工程。ここでは、一人+AIは組織よりも速く、一貫性を持ち、機動力がある。
AIを「一つの万能ツール」として使うのをやめ、「役割を持ったチームメンバー」として設計する
「ChatGPTに聞けばなんでもできる」という誤解がある。一つのLLMに全てを任せることは、一人の人間に「企画も、デザインも、開発も、テストも全部やれ」と言うのと同じだ。それぞれの工程に適したツール・モデル・プロンプト設計がある。AIチームを設計するという発想が必要だ。
2026年現在の主要AIツールは、それぞれ異なる強みを持つ。一つのツールに固執するのではなく、工程ごとに最適なものを選ぶ。重要なのは、各ツールをどの「役割」として使うかを事前に決めておくことだ。役割が決まっていると、プロンプトの設計が安定し、期待する出力が安定する。
PM / ブレスト相手 ── Claude Opus（深い推論と対話）
コード生成・補完 ── Claude Code / GitHub Copilot / Cursor
UI生成 ── v0 by Vercel / Lovable / Bolt.new
デザイン補助 ── Figma AI / Framer AI
コンテンツ・コピー ── Claude Sonnet / GPT-4o
画像生成 ── Midjourney / DALL-E 3 / Flux
テスト・QA ── Playwright MCP / GitHub Copilot for Tests
コードレビュー ── Claude Code（専用エージェント設定）
Claude（Anthropic）は長い文脈の保持と、指示への忠実な追随に優れる。複雑なシステム設計の議論、長いコードベースへの適用、ニュアンスのある文章生成に向く。Claude Codeは特に、ファイルシステムを直接操作しながら自律的に開発を進める能力が高い。
Cursor / GitHub Copilotはエディタに統合されたAIだ。コードを書いている途中でのリアルタイム補完・提案が強み。Cursorは複数ファイルをまたいだ文脈理解と、チャットからコード編集への橋渡しが優れている。
v0 / Lovable / Bolt.newはテキストプロンプトからUIを生成するツール群だ。「こういうダッシュボードが欲しい」と書くだけで、動くReactコードが出てくる。完成品ではなくたたき台として使い、そこから自分でカスタマイズするのが正しい使い方だ。
LLMの能力は、与える文脈（コンテキスト）の質に大きく左右される。「コードを修正して」ではなく、「このファイルは○○の目的で、このクラスは××を担当していて、今起きている問題は△△で、期待する動作は□□だ。この前提で修正して」と伝えると、出力の品質が劇的に変わる。
Claude Codeのようなエージェント型ツールは、ファイルを自ら読んで文脈を補完する。しかし、設計意図・ビジネスロジックの背景・制約条件はコードに書かれていない。これらを `CLAUDE.md` やコメントで明示しておくことが、AIとの協働精度を上げる最も費用対効果の高い投資だ。
一人の頭の中にある曖昧なアイデアを、AIとの対話で具体的な設計図に変える
企画フェーズは、一人開発の最大の弱点が現れやすい段階だ。チームなら、アイデアを出し合う中で盲点が消える。一人だと、自分の思考の外にある問題が見えない。AIはここで、視点の多様化装置として機能する。
AIに「すごいですね」と言わせるのは簡単だ。しかし、それは価値がない。AIを企画フェーズで最も効果的に使う方法は、批判者・悪魔の代弁者として動かすことだ。「このアイデアの最も深刻な欠点を10個列挙してください。容赦なく」と頼む。出てきた批判の中から、本質的なものを選んで検討する。
この使い方で重要なのは、AIの批判を全部受け入れないことだ。AIは批判するよう頼まれれば批判するが、そのすべてが正しいわけではない。批判を読みながら「これは本質的な問題か、それとも表面的な問題か」を自分で判断する。AIは批判の生成器であり、判断者は自分だ。
① 競合分析の加速 ── 「○○領域の主要プレイヤーをリストアップし、それぞれの強みと弱点を分析して」
② ユーザストーリーの展開 ── 「このペルソナが抱える課題を、1日のタイムラインに沿って詳細に描いて」
③ 機能の優先度付け ── 「これらの機能をMoSCoW分析（Must/Should/Could/Won't）で分類して、その根拠を示して」
④ リスクの洗い出し ── 「このMVPが失敗する最もあり得るシナリオを5つ、具体的に描いて」
対話で固まったアイデアを、構造化された要件定義書に変える。ここでもAIを使う。「以下の対話ログを元に、エンジニアが実装できる粒度の要件定義書（PRD）を作成してください」と対話履歴を渡す。出力はたたき台であり、必ず自分でレビューして修正する。
要件定義書に含めるべき項目。
要件が固まったら、技術スタックを決める。「要件はこれで、制約はこれで、自分のスキルはこれだ。最適な技術スタックを、理由とともに提案してください」とAIに投げる。複数の選択肢が返ってきたら、それぞれのトレードオフを深掘りする。
注意点は、AIが常に最新で最も話題のスタックを提案しがちなことだ。「あなたが今挙げたスタックの、2年後のリスクと、初心者がつまずきやすいポイントを挙げてください」と追加で問う。長期のメンテナビリティと、自分のスキルへの適合を最終的な判断軸にする。
「デザインができない」は2026年においてもはや言い訳にならない
デザインは、一人開発の最大のボトルネックだった。エンジニアがコードは書けてもデザインに時間がかかり、デザイナーを雇う予算もなく ── という詰まり方をした個人開発者は多い。AI生成ツールの登場は、このボトルネックを劇的に解消した。
AI時代のデザインスキルは、「美しいものをゼロから作る能力」ではなく、「AIが生成したものの良し悪しを判断し、的確に修正指示を出す能力」だ。これはデザインセンスの終わりではなく、変容だ。センスは「見る目」として残り、「手を動かす」部分をAIが担う。
だから、デザインの基本原則（コントラスト、整列、反復、近接 ── Robin Williamsが整理した4原則）を知っていることは、以前より重要になった。AIが生成したデザインのどこが問題かを言語化できなければ、修正指示が出せない。
v0 by Vercel ── プロンプトからReact/Tailwindの動くUIを生成。コンポーネント単位で使うのが最も効果的。
Lovable / Bolt.new ── フルスタックのアプリ全体をプロンプトから生成。MVPの初期スケルトン作成に向く。
Figma AI ── 既存のデザインファイルへのAI支援。バリアント生成・コピー変更・自動レイアウト調整。
Framer AI ── Webサイトをプロンプトから生成し、そのままホスティング。ランディングページの高速制作。
v0の効果的な使い方は、コンポーネント単位での生成だ。「サイト全体をv0で作る」ではなく、「ダッシュボードのデータカード部分をv0で作る」「ナビゲーションバーをv0で作る」という使い方が、修正のしやすさと品質のコントロールの両面で優れている。
プロンプトの書き方で品質が大きく変わる。避けるべき書き方：「かっこいいダッシュボードを作って」。目指すべき書き方：「Tailwind CSSを使った、ダークテーマのSaaSダッシュボード。左サイドバーにナビゲーション、メインエリアに3列のKPIカード（数値・前月比・スパークライン付き）、下部にデータテーブル。フォントはInter。アクセントカラーはindigo-600」。具体性が品質を決める。
AI生成ツールを使うほど、バラバラなスタイルが量産されるリスクが高まる。v0で作ったコンポーネントAと、別に作ったコンポーネントBで、フォントサイズや間隔の基準が違う ── これを防ぐのがデザインシステムだ。
一人開発におけるデザインシステムは、複雑なStorybook構成は不要だ。Tailwindの `tailwind.config.js` にカラー・フォント・スペーシングのトークンを定義するだけで十分な場合が多い。これをAIに対して「このtailwind.configの設定を必ず使って」と渡すことで、AIが生成するコードのスタイルを統一できる。
AIはペアプロのパートナーを超え、自律的に動くジュニアエンジニアになりつつある
コーディング支援は、AI活用の中で最も成熟した領域だ。GitHub Copilotの登場（2021年）から数年、AIコーディング支援は「補完」から「生成」へ、「提案」から「自律実行」へと大きく進化した。2026年現在、Claude CodeはClaudeMD（プロジェクト設定ファイル）を読み、ファイルを自律的に操作しながら、複数ファイルにまたがる実装を完遂できる。
AIがコードを書く時代においても、人間の役割は消えない。それはレビュワーとしての役割だ。AIが出力したコードを「動くかどうか」だけで評価するのは危険だ。「このコードは正しく動くか」「この設計は1年後も保守できるか」「セキュリティ上の問題はないか」「テストはあるか」── これらを判断する知識と責任は、依然として人間にある。
AIコードのレビューで最も気をつけるべきは、動くが間違っているコードだ。期待した挙動はするが、エッジケースで壊れる。動くが、セキュリティホールがある。動くが、パフォーマンスが致命的に悪い。これらはテストなしでは発見できない。
段階1：補完 ── Copilotが行の続きを予測する。受動的。コードを書きながら採用・却下する。
段階2：生成 ── 「○○の関数を書いて」とチャットで依頼する。能動的だが単発。
段階3：自律実行 ── Claude Codeが「この機能を追加して」と言われ、ファイルを読み、複数ファイルを編集し、テストを実行し、問題があれば自己修正する。人間はゴールを指定し、結果をレビューする。
Claude Codeを最大限に活用するための最重要ファイルが `CLAUDE.md` だ。プロジェクトルートに置くこのファイルは、AIが作業を開始する前に必ず読む「チームへの引き継ぎ書」だ。記載すべき内容：
AIにコードを書かせるとき、最も品質が高まるパターンはテストファーストでの依頼だ。「この関数のユニットテストを書いて」→テストをレビュー・修正する→「このテストを通る実装を書いて」という順序を取る。これにより、AIが生成した実装の正しさをテストが自動的に検証してくれる。
特に役立つのは、エッジケースのテストを先に書かせることだ。「この関数に対して、バグが入りやすいエッジケースを10個考えて、テストとして書いて」と依頼する。AIは自分が書くコードの落とし穴を、コードを書く前の段階で予測できる。この予測をテストに変換することで、実装後のバグを大幅に減らせる。
一人でチームのQAプロセスを超える、自動化の設計
チーム開発においてQA（品質保証）は専任の担当者が行う。一人開発では、自分が開発者であり同時にQA担当でもある。この二役を人間が担うのは認知的に困難だ。「作った直後の自分」は「バグがある」とは思いにくい。AIと自動化の組み合わせが、この問題を解決する。
品質保証の目標を「動くことの確認」から「壊れないことの保証」に転換する。「動く」は一時点での状態だ。「壊れない」は変更が加えられても、環境が変わっても、予期しない入力が来ても、機能が維持されるという保証だ。この保証を一人で維持するためには、自動化しかない。
単体テスト ── Vitest / Jest。AIが実装と同時に生成。
E2Eテスト ── Playwright。主要ユーザーフローを自動で叩く。Playwright MCPでAIが直接テストコードを書く。
型チェック ── TypeScript。コンパイル時の静的検証。AIが型を正確に書くよう指示する。
Lint / Format ── ESLint / Prettier / Biome。コミット前に自動実行。
AIコードレビュー ── Claude Codeに「このPRをセキュリティ・パフォーマンス・保守性の観点でレビューして」と依頼する。
依存関係の脆弱性スキャン ── Dependabot / npm audit。GitHub Actionsで自動実行。
Playwright MCPは、AIがブラウザを直接操作してE2Eテストを書けるようにするツールだ。「ログインからダッシュボード表示まで、ユーザーが使うような形でテストを書いて」と依頼すると、実際にブラウザを操作しながらテストコードを生成する。
E2Eテストは「クリティカルパスだけ守る」という方針が一人開発には現実的だ。全機能のE2Eテストを書こうとすると維持コストが高い。ログイン・サインアップ・コア機能の実行・決済フロー ── これらだけをE2Eで守り、それ以外はユニットテストに任せる。
チームのコードレビューをAIで代替するとき、重要なのはレビューの観点を明示することだ。「レビューして」では広すぎる。以下のように観点を分けて依頼する。
各観点を独立したセッションで依頼すると、一つの長い会話で頼むより精度が上がる。
インフラとCI/CDを一度正しく設計すれば、それ以降の運用コストはほぼゼロになる
一人開発の時間的制約の中で、最も「設計に時間をかける価値がある」のがCI/CDとインフラだ。最初の2〜3時間を投資して正しく構成すれば、それ以降は`git push`一本でテスト・ビルド・デプロイが自動実行される。この自動化を持つ一人開発者は、持たない5人チームよりも速くリリースできる。
自力でサーバを管理しない。2026年において、個人開発者がVPSを借りてnginxを設定し、Let's Encryptを更新し、OSのパッチを当て続けることは、合理的ではない。プラットフォームの重力に乗るのが正しい選択だ。Vercel・Netlify・Cloudflare Pages・Render ── これらは、デプロイ・HTTPS・CDN・スケーリングを自動で処理する。
データベースも同様だ。Supabase・Neon・PlanetScaleのようなDBaaS（Database as a Service）は、バックアップ・可用性・スケーリングをマネージドで提供する。一人で運用できるのは、こうしたプラットフォームの上に構築したときだ。
フロントエンド/フルスタック ── Vercel（Next.js）/ Cloudflare Pages（Remix・Astro）
データベース ── Supabase（PostgreSQL + Auth + Storage）/ Neon（サーバーレスPostgreSQL）
認証 ── Supabase Auth / Clerk / Auth.js
ファイルストレージ ── Supabase Storage / Cloudflare R2
メール ── Resend / Postmark
決済 ── Stripe
監視 ── Sentry（エラー）/ Vercel Analytics（パフォーマンス）
GitHub Actionsのワークフローは、AIに書かせるのに最も向いているインフラコードの一つだ。「main ブランチへのpushで、Lint・型チェック・テストを実行し、全部通ったらVercelにデプロイするGitHub Actionsのワークフローを書いて」と依頼する。YAMLが正確に出てくる。
CI/CDが整うと、デプロイの心理的コストが下がる。「壊れたら大変だから今日はリリースやめよう」という判断が消え、小さな変更を頻繁にリリースできるようになる。これはフィードバックサイクルを速くし、製品の改善速度を上げる。
一人で運用するとき、問題に気づくのが遅れることが最大のリスクだ。ユーザからの報告で初めて本番障害を知る ── これは避けなければならない。最低限の監視を設計する。
AIが作業を引き受けるほど、人間に残る仕事は「何を作るか」の判断と、「続けること」の自己管理になる
一人開発の見えにくい難しさは、技術的なものよりも自己管理にある。チームがあれば、締め切りや仲間の存在が外部の圧力として機能する。一人では、その圧力がない。AIが作業を代替するほど、人間に残る「作業」は減り、「判断」と「継続」が全てになる。
一人でAIと開発するとき、最大の生産性の罠は進捗の錯覚だ。AIとのやり取りは活発で、コードは量産され、「何かが進んでいる」感がある。しかし1週間後に振り返ると、ユーザに届く成果が何も増えていないことがある。
この罠を避けるために、週次でのゴール設定を軸にする。今週の終わりに「○○ができるようになっている」というゴールを月曜に設定する。日々の作業はそのゴールに向かっているかどうかで評価する。AIとの作業中も「これは今週のゴールに貢献するか」という問いを持ち続ける。
朝（90分）── 深い思考の時間：設計・企画・難しい問題の解決。AIとの対話も朝に集中させる。通知はオフ。
午前中（2〜3時間）── 実装の時間：Claude Code・Cursorと並走しながら、コードを進める。
午後（1〜2時間）── 確認と改善の時間：テスト実行・デプロイ・小さなバグ修正・ドキュメント更新。
夕方（30分）── 棚卸しの時間：今日の成果を記録し、明日のタスクをリストする。
一人開発でAIを使う最大の難点は、自分の頭の中のコンテキストをAIに毎回伝える手間だ。チームでは「みんなが状況を知っている」という暗黙の共有知識があるが、AIとのセッションはリセットされる。
この問題への対処は三つある。第一にCLAUDE.mdの充実（前章で述べた通り）。第二に開発ログの維持：毎日作業の終わりに「今日何をしたか・何が残っているか・次のセッションで伝えるべき文脈」を短くメモする。第三にセッション冒頭のブリーフィング：新しいAIセッションの最初に「現在のプロジェクト状況は○○で、今日やりたいことは△△で、特に注意してほしいのは□□だ」と伝える。
AIと作業していると、特定の問題で長時間詰まることがある。「AIに聞いてもうまくいかない」という状態だ。このとき、いつまでも同じアプローチを繰り返すのは時間の無駄だ。詰まったときのプロトコルを持つ。
全てをAIに任せようとする誘惑と、全てを自分でやろうとする頑固さ ── どちらも間違いだ
AIへの委譲は、「できるかどうか」ではなく「すべきかどうか」で判断する。技術的にはAIが書けるコードでも、自分が理解していないまま本番に入れるべきではない。逆に、AIが確実にできることを自分でやり続けるのは、時間の浪費だ。
何をAIに委譲するかを決める判断軸は二つだ。「理解の確認可否」と「失敗のコスト」だ。
理解の確認ができる領域 ── コード出力を自分でレビューでき、正しいかどうか判断できる ── では、積極的に委譲する。理解の確認が難しい領域 ── セキュリティの設計、データモデルの根本構造、法的なリスク ── では、慎重に委譲し、必ず専門家への確認を経る。
失敗のコストが低い領域（CSSの修正、コピーの言い回し、小さなユーティリティ関数）は大胆に委譲する。失敗のコストが高い領域（認証の実装、決済フロー、個人データの処理）は、AIの出力を深くレビューし、既存の信頼できるライブラリを優先する。
AIに委譲してよいもの
ボイラープレートコード・定型的なCRUD実装・CSS/スタイリング・テストコードの下書き・ドキュメント・コピーの初稿・定型的なCI/CD設定
自分が持つべきもの
データモデルの設計・認証/認可の方針・ユーザへの価値提案・プロダクトの方向性・セキュリティの最終判断・ユーザインタビューの実施・ビジネスモデルの検証
2026年現在、AIが構造的に苦手な領域がある。これを知ることで、自分の注意を集中させる場所がわかる。
一人+AIで完結しない、人間の専門家が必要な領域もある。「一人開発だから全部自分でやる」という誤解が、後で高いコストになることがある。
AIで一人が何でもできる時代だからこそ、何をすべきでないかの判断が重くなる
一人+AIの組み合わせは、個人の能力を劇的に拡張する。この拡張は、同時に影響力の拡張でもある。かつては組織が持てた規模の影響力を、一人が持てる時代に、倫理的な判断の重さは増している。
「AIが書いたコードだから」「AIが提案したから」は、ユーザへの責任から逃れる理由にならない。AIが生成した認証の実装に脆弱性があれば、その責任は開発者にある。AIが生成した誤情報を含むコンテンツが公開されれば、その責任も開発者にある。AIの出力に署名するのは、常に人間だ。
一人開発では、この責任を担う組織的な牽制がない。だからこそ、個人としての判断基準を明示的に持つことが重要だ。「このプロダクトは誰を傷つける可能性があるか」「この機能はユーザの利益になるか、それとも自分の利益のためだけか」 ── これらの問いを、リリースのたびに自分に問う習慣が必要だ。
プライバシー ── 必要以上のデータを収集していないか。収集した目的と異なる使い方をしていないか。
セキュリティ ── ユーザのデータを適切に保護しているか。脆弱性の報告窓口はあるか。
アクセシビリティ ── 身体的制約を持つユーザが使えない設計になっていないか。
透明性 ── AIを使って生成したコンテンツを、そうと示さずに人間の著作として公開していないか。
依存性 ── ユーザが意図せず依存するような設計（ダークパターン）を使っていないか。
一人開発の最大のリスクは、燃え尽きだ。AIがあるから全部できる ── という思い込みで、際限なくスコープを広げ、深夜まで作業を続け、ユーザからのフィードバックに一人で対応し続ける。チームがあれば分散される負荷が、一点に集中する。
持続可能な一人開発のために守るべき三つのこと。第一にスコープの明示的な境界：「このプロジェクトでは○○はしない」を最初に書いて、見えるところに貼る。第二に稼働時間の上限：週に何時間をこのプロジェクトに使うかを事前に決め、超えたら翌週に回す。第三にユーザとの距離：月に一度はユーザと直接話す。メトリクスだけ見ていると、人間の感覚が鈍る。
一人+AIが限界を迎える規模がある。以下のいずれかに達したとき、チームを作るか、システムを整理するかの判断が必要になる。
これらの閾値に達したとき、「チームを作る」は失敗ではない。一人軍団が成功した証拠だ。小さく始めて、機能することを証明し、その後に拡張する ── これが最も合理的な順序だ。
チームを組まないことは、後退ではなく、一つの戦略だ
一人でWebを作るという選択は、孤独だ。承認してくれるデザインレビューがない。「いいね」と言ってくれるチームメンバーがいない。本当に正しい方向に進んでいるのか、誰も教えてくれない。この孤独は、解消できるものではない。引き受けるものだ。
しかし、その孤独の中にしかない自由がある。誰の承認も待たずに作れる。誰の合意も取らずに変えられる。誰の感情も気にせず、正しいと思う方向に進める。この自由は、チームの中では手に入らない。
AIは、この自由を技術的に拡張した。かつて一人では届かなかったデザインの水準に、コードの品質に、コンテンツの深さに、今は届く。届くが、それは技術的な話だ。何を作るかは、依然として一人の判断だ。なぜ作るかも。誰のために作るかも。
AIは作業の速度を上げる。しかし方向を決めるのは人間だ。
AIは選択肢を広げる。しかし選ぶのは人間だ。
AIは孤独を紛らわせる。しかし責任を分かち合うことはない。
一人軍団の強さは、AIと組んだことで生まれる。しかしその強さを何に使うかは、一人の意志にかかっている。
本書を読んで、明日から一つだけ変えるとしたら何か。企画中のプロジェクトをAIと議論してみること、CLAUDE.mdを書いてみること、v0でコンポーネントを一つ生成してみること ── どれでもよい。始めることが全てだ。完璧な準備が整うのを待っていたら、永遠に始まらない。
作ってください。作りながら学んでください。壊れたら直してください。それが全工程だ。
さらに深く学ぶための地図