開発
このセクションは、Claudeと一緒に製品や社内システムを作る、すべての人を対象にします。実装の書き方ではなく、何を知っていれば安全に作り始められ、何を口に出せば製品が良くなるかを扱います。書いてあるのは弊社での判断であり、唯一の正解ではありません。
これまでとこれから
これまで、動くものを作るには実装を書ける人が必要でした。ボトルネックは実装できる人数で、作りたい人は仕様をまとめて実装者へ渡し、出来上がりを待っていました。
Claudeに頼めば動くものを作れるようになり、ボトルネックは実装から移動しました。コードを書く力の価値は下がり、代わりに2つの力の価値が上がりました。取り返しのつかない事故を避ける力と、作るものの文脈をClaudeへ渡す力です。
作るのは簡単、育て続けるのが難しい
最初に動くものを作ることは、簡単になりました。難しさはその後へ移ります。機能を追加し続けるには、設計の柔軟さと拡張性が必要になります。ライブラリの更新を放置すれば脆弱性へ繋がり、仕様を残さなければ、全体像は人にもAIにも見えなくなります(依存関係、仕様書を残す)。
このセクションの観点の多くは、作る瞬間ではなく育てる期間のためにあります。長く使う予定の製品ほど、育てるための観点を早めに口に出します。
規模と目的はClaudeには見えない
Claudeが知っているのは、会話で伝えられたことと、リポジトリから読み取れることだけです。その製品が3ヶ月で捨てる試作なのか3年運用する業務基盤なのか、利用者が10人なのか1万人なのか、扱うデータが漏れたら何が起きるのかは、言わなければ伝わりません。
テスト、監視、設計といった手法をどこまで重ねるかは、この文脈で決まります。Claudeがどれだけ賢くても、文脈を渡し、気にすべき観点を口に出すのは人間の仕事です。逆に言えば、観点の名前を知っていて適切な場面で言えれば、実装はClaudeが引き受けてくれます。このセクションの後半は、その観点の一覧です。
要件は会話の中で整理する
文脈を渡すといっても、要件を完全にまとめてから伝える必要はありません。人間が一人で整理を終え、完成した指示を渡して作ってもらう。この「仕様を渡して納品を待つ」進め方をそのままAIに持ち込むのは、遠回りだと弊社は考えています。誰であっても、勘違いしていることや知らないことがあり、それには一人では気づけません。
分かっていることから話し始め、質問や選択肢を出してもらいながら、自分のやろうとしていることを整理していきます。整理された要件は、会話の入口に用意するものではなく、会話の成果として出てくるものです。分からない言葉や提案の意図も、その場で聞きます。質問への回答は、いまの状況に合わせて返ってくるぶん、資料を探し回るより早く役に立ちます。
部分で進めて、全体で整える
Claudeは、毎回すべてのコードと仕様を読み込んで作業するわけではありません。目の前の依頼に関係する部分だけを見る方が速いためで、これ自体は正しい進め方です。その代わり、部分ごとの最適が積み重なると、名前の付け方、画面の作り、設計の方針が全体でぶれてきます。
だから、部分的に開発を進めることと、立ち止まって全体を見直すことを分けて行います。全体の調整そのものもClaudeへ依頼できます。
機能追加は一旦止めて、全体を見直して。設計や画面がぶれているところを揃えて
後回しにできること
ターミナルの操作、Gitのコマンド、言語やフレームワークの文法、各ツールの設定方法。これらは学ぶ価値がないのではなく、Claudeが代行してくれるため、必要になるまで後回しにできます。実際に必要になった場面で、目の前の具体例と一緒にClaudeへ聞く方が、先回りして学ぶより速く身につきます。仕組みの詳細な解説はMDNや各公式資料が担っているため、このサイトでは繰り返しません。
先に押さえておきたいのは、順序を逆にできないものです。起きてからでは取り返せない事故と、最初に渡さないと手戻りになる文脈がそれにあたります。このセクションの並びも、この順序に沿っています。
読む順序
最初に読むべきは、知らないまま進めると事故になるものです。トークン・APIキーは、漏れると乗っ取りと課金が起きる理屈を説明します。リポジトリの公開範囲は、履歴ごと世界へ公開される仕組みと、Claudeの操作でpublicになる経路を扱います。Claudeへの権限は取り消せない操作の見分け方、個人情報・認証・決済は一人で進めてはいけない領域の境界です。
作業に入るときは、進め方のページを読みます。新しく作るは最初に伝えることと公開前の点検を、既存の製品を修正するは壊さずに直す手順をまとめています。使う技術は推奨する技術スタックの通りに指定すれば、中身の判断はClaudeに任せられます。
概念のページは、知ると指示と切り分けが速くなるものです。用語の地図で会話に出る言葉がどの領域の話かを掴み、Webの構造、環境の分離、バージョン管理、依存関係で、Claudeの報告を理解する土台を作ります。
続く4ページは、口に出すと製品が良くなる観点の一覧です。品質の観点はテスト、mock、CI、監視、別のAIによるレビューを、UIの観点はコンポーネント、デザイントークン、アクセシビリティを、構造の観点は全体の繋がり、API、Worker、データベースを、モジュール設計はディレクトリ構成とファイルの分け方を扱います。
運用に入った製品では、仕様書を最新に保ち、日常点検を回します。その先、事業として製品開発を継続運用する方法は製品のセクションへ続きます。