僕がカナポスなどの個人開発でClaude Codeを使って助かったのは、コードをチャットへ貼り直す手間が減ったことです。VS Codeで開いているプロジェクトを参照し、複数のファイルにまたがる変更も相談できます。
ただ、便利だからと大きく任せると、今度は変更の量についていけなくなりました。複数ファイルが一度に変わり、どの修正が原因なのか追いにくい。そこから、「1機能ずつ依頼し、Gitの差分と実際の動作を見てから次へ進む」という使い方に変えました。この記事では導入から、その最初の一巡までを説明します。
VS CodeとGit、試すための小さなフォルダを用意する
Claude Codeは、プロジェクトのファイルを読み、編集やコマンド実行を支援するツールです。まずVS CodeとGitを用意し、動く状態のコードをコミットします。最初の練習なら、自己紹介ページのHTMLとCSSのように、変化を目で追える題材が向いています。
Claude Codeの公式案内では、VS Code 1.94.0以上が必要です。拡張のチャット用CLIは同梱されています。VS Codeの拡張画面から使い始める場合と、ターミナルでclaudeコマンドを使うために単体CLIを導入する場合を分けて準備します。
コード保存がまだなら、GitHubへ保存する手順を先に進めてください。Gitがあると、「どのファイルのどこを変更したか」を前の状態と比べられます。APIキーや個人情報を含まない練習用フォルダで始めると、依頼する範囲も絞れます。
Anthropicの公式拡張を入れて、認証する
- VS Codeの拡張機能でClaude Codeを検索する。
- Anthropicの公式配布ページと発行者を照合してインストールする。
- Windows/LinuxはCtrl+Shift+P、MacはCmd+Shift+Pでコマンドパレットを開く。
- Claude Codeを検索し、Open in New Tabなどの項目から画面を開く。
- 初回のSign inからブラウザへ進み、利用するアカウントで認証する。
エディタ右上のSparkアイコンは、ファイルを開いているときに表示されます。導入直後に見当たらない場合は、VS Codeを再起動するか、コマンドパレットのDeveloper: Reload Windowを試します。操作位置は公式のVS Codeガイドとも見比べてください。
利用枠と料金は、個人向けプラン、API利用、組織契約で異なります。認証した方式と、現在のプラン条件を先に確認します。使い始めは短い変更で一巡し、利用状況を見ながら作業を広げると扱いやすいです。
最初は、見出し一つを変更してもらう
VS Codeで練習フォルダを開き、対象のindex.htmlを示します。「ページをいい感じに」より、変更する文字と残す部分を具体的に伝えます。最初の依頼なら、次のような範囲で十分です。
このプロジェクトのREADMEと構成を読んでください。
編集する前に、変更するファイルと確認方法を説明してください。
まず見出しの文言だけを変更してください。
環境変数、認証、デプロイ設定は変更しないでください。たとえば「h1の文字だけを変更し、本文とCSSはそのまま」と頼めば、成功したかを自分でも判断できます。提案を読んで、対象がindex.htmlなのか、別のファイルまで増えていないかを見ます。
編集の承認方法は、画面で選んでいる権限モードに従います。Manualでは、提案された編集の差分を確認して承認・拒否できます。最初は変更対象を読みながら進め、コマンドの実行が提案されたら、その目的と実行場所も確かめてください。
Gitの差分と、ブラウザの表示をセットで見る
編集が終わったら、まずVS Codeのソース管理を開きます。変更されたファイルを選び、削除された行と追加された行を比べます。ターミナルならgit status --shortで一覧、git diffで未ステージの差分を見られます。すでにステージへ追加した場合はgit diff --stagedも確認します。
次にページをブラウザで開き直します。見出しが変わっているか、文章や色まで意図せず変わっていないかを見ます。差分が期待どおりでも、別の画面で使う部品へ影響することがあるので、変更に関わる操作を実際に一度通します。
確認できたら、その小さな変更をコミットします。次の機能を頼む前に戻れる場所を作っておくと、依頼を重ねても、どの変更から問題が起きたかを追いやすくなります。戻し方はAIの変更だけを切り分けるGitの練習で試せます。
カナポスで、一度に頼みすぎて分かったこと
カナポスでは、画面の作成だけでなく、LINE認証やメッセージ保存など、複数の処理をつなぐ必要がありました。Claude Codeが関連ファイルを読んでくれるのは便利でしたが、広い範囲をまとめて変更すると、確認する側の負担も一気に増えます。
それからは、まず「ログイン後にどこへ戻るかを調べる」、次に「原因となる箇所を直す」というように、調査と変更を分けるようにしました。画面の変更、保存処理、予約配信も一つずつ扱い、差分を見てから次へ進みます。
想定と違う提案が出たら、追加の指示を重ねる前に、いま何が変わったかを整理します。「残したい動作」「実際の結果」「再現する操作」を伝え直すと、話題が広がりにくくなります。この使い方はカナポスの開発記録にもつながっています。
コードを渡す手間が減った分、目的を具体的にする
チャットからコピーして貼る作業が減っても、何を作るか、結果をどう判断するかは自分の仕事として残ります。僕には、そこを短い依頼へ分けて伝える使い方が合っていました。最初は一つのファイル、一つの変更から始めてみてください。
答えをそのまま受け取るより、理由も学びながら進めたい場合は、ヒントから考えるメンタープロンプトも使えます。エラーが出たら、秘密の値を除いたメッセージと再現操作を添え、原因を確かめるところから相談します。
頼み方を「よくして」から、一つの変更へ絞る
僕がカナポスで困ったのは、関連ファイルが一度に変わると、その後の不具合を追いにくくなることでした。だから最初の練習では、AIの能力を広く試すより、自分で変更前後を説明できる量にします。自己紹介ページの見出し一つなら、差分と画面をすぐに見比べられます。
次の表では、依頼文の違いを比べています。どこを直すかが曖昧な頼み方を、一つのファイルで結果を見られる形へ言い換えてみました。
| 範囲が広すぎる依頼 | 最初に試しやすい依頼 |
|---|---|
| サイト全体をおしゃれにして。 | index.htmlのh1だけを「かたすけの自己紹介」に変えてください。本文、CSS、リンク先は維持してください。 |
| ログインが動かないので全部直して。 | まずログイン開始からCallbackまでのファイルを読み、戻り先URLを組み立てる箇所を示してください。この段階では編集しないでください。 |
| スマホ対応と新機能とデザイン変更をまとめてお願い。 | style.cssのカード幅だけを調整し、360px幅で横へはみ出さないようにしてください。HTMLの構造と機能は変えず、変更理由を教えてください。 |
対象ファイル、変えたい結果、残したい動作がそろうと、受け取った変更を読む基準ができます。「触らない部分」を長く並べるより、今回の作業に関係する境界を二つか三つ示すのが使いやすいです。AIが別のファイルの修正も必要だと判断したら、その理由を読んでから範囲を広げます。
一つのHTMLから、差分を読む練習をする
たとえば自己紹介ページの見出しが、変更前には次の状態だったとします。これは差分の読み方を試すための小さな例です。VS Codeでindex.htmlを保存してから依頼すると、変更前がはっきりします。
<main>
<h1>自己紹介</h1>
<p>Web制作を学びながら、小さなアプリを作っています。</p>
</main>次のように頼めます。「変更が終わったら差分と確認方法を教えて」と添えると、自分が次に何をするかまでつながります。最初からページを作り直すより、これくらいの変更を一巡させるほうが操作を覚えやすいと思います。
index.htmlのmain内にあるh1を
「かたすけの自己紹介」へ変えてください。
段落の文章、class、style.css、リンク先は維持してください。
変更後に、編集した行とブラウザで見る場所を教えてください。編集後のgit diffは、たとえば次の形です。先頭のマイナスは削除、プラスは追加を示します。前後にある段落の行が変わっていなければ、頼んだ範囲に収まっていると読み取れます。
diff --git a/index.html b/index.html
--- a/index.html
+++ b/index.html
@@ -1,4 +1,4 @@
<main>
- <h1>自己紹介</h1>
+ <h1>かたすけの自己紹介</h1>
<p>Web制作を学びながら、小さなアプリを作っています。</p>
</main>ソース管理に複数のファイルが出たら、まずファイル名の一覧を見ます。コードの変更に加え、依存関係のロックファイルが変わっている場合もあります。「見出しだけ」の依頼でパッケージ追加が起きていれば、必要な理由を聞いてみてください。差分を読まずに次の依頼を重ねると、どこから作業が広がったかが分からなくなります。
ブラウザで見る場所まで、依頼のゴールに入れる
差分を読んだら、そのページをブラウザで再読み込みします。見出しの文字が変わったかに加えて、長くなった文字がスマホ幅で折り返せるかを見てください。色や余白を変えていなくても、文字数が増えるだけで見た目は変わります。表示が古いときは、保存したファイルと開いているURLを照合すると、別のコピーを見ていたことに気づけます。
うまく動いたら「見出しは変わり、360px幅でもはみ出していない」と結果を短く返します。うまくいかなければ、操作、期待した状態、実際の状態を書きます。「壊れた」だけより、「360px幅で見出しの右端が画面外へ出る。PC幅では収まる」のほうが、次の修正を絞れます。
最後に小さなコミットを残せば、一つの依頼が一つの記録として追えます。僕が複数ファイルの変更で追いにくくなった経験から学んだのは、AIへ伝える量と、自分が読み返せる量を合わせることでした。慣れてきたら範囲を広げればよいので、まずは一つのファイルで、この往復を試してみてください。
修正を続けるときは、直前の結果も次の依頼へ添えると話がつながります。「見出しは意図どおり変わった。次はスマホ幅で2行になったときの行間だけを調整したい」と書けば、文字の変更をやり直す必要がありません。頼む前の画面と、変更した一行を手元へ残しておくと、AIの説明と実際の表示が合っているかを自分で判断できます。
途中で分からない変更が増えたら、その場で新機能を頼むのを止め、「この差分をファイルごとの目的で説明して」と聞いてみてください。自分が理解できる量へ戻してから、残す修正を選びます。
仕様をどこまで自分で決めるか迷うときは、素数ゲームで制限時間と連続正解の演出を決めた記録も参考になります。依頼・実装・画面確認を繰り返した過程を紹介しています。
