はじめに
「WEBサービスを作りたい。決済も組み込んで本格的に運営したい。でも、プログラミングなんてわからない」
そんなあなたに向けて書いた入門書です。
結論から言うと、今の時代は プログラミングの知識がなくてもWEBサービスは作れます。決済機能も組み込めます。
それを可能にしているのが「Claude Code」というAIツールです。
ただし、何も知らなくていい、というわけでもありません。
「英語を知らないと海外旅行できない」は嘘ですが、「挨拶くらい知っておくと100倍スムーズ」なのと同じで、少しだけ言葉と仕組みを知っておくだけで、AIとのやりとりが格段にスムーズになります。
この本では、その「少しだけ」を丁寧に説明します。
第1章 Claude Codeってなに？
AIに「超優秀なエンジニア」を雇うイメージ
まず「Claude」というAIサービスがあります。
ChatGPTを使ったことがある方はご存知かもしれませんが、それとほぼ同じような対話型のAIです。チャットでなんでも聞けて、文章を書いてもらったり、翻訳してもらったりできます。
その「Claude」を自分のパソコンと繋いで、パソコンの中のファイルを直接作ったり、編集したりできるようにしたのが「Claude Code」です。
イメージとしては、
「超優秀なエンジニアを一人雇って、『こんなサービス作って』と言ったらその人が全部やってくれる」
という感じです。
自分はただ社長として指示を出すだけ。細かいプログラムのコードはAIが全部書いてくれます。
どうやって使うの？
使い方はシンプルです。
パソコンには「ターミナル」または「コンソール」と呼ばれる、黒い画面（コマンドを入力する画面）があります。
その画面にたった1行のコマンドを入力するだけで、Claude Codeがインストールされます。
あとは、その黒い画面でチャットのようにAIに話しかけながら開発を進めていきます。
「ログイン画面を作って」
「このボタンを押したら確認ダイアログが出るようにして」
「エラーが出てるから直して」
こんな自然な日本語での指示で、AIがプログラムを書いたりファイルを作ったりしてくれます。
アプリ版もある
Claudeにはアプリ版（画面付き）もあって、その中の「Code」というセクションでClaude Codeが使えます。
ターミナルの黒い画面が怖い方は、アプリ版から始めるのがとっつきやすいかもしれません。中身（AIの性能）は同じです。
プラグインでさらに便利に
「プラグイン」と呼ばれる拡張機能を入れると、Claude Codeはさらにできることが増えます。
たとえば、ブラウザを自動で開いて操作してくれたり、画面のスクリーンショットを撮ってくれたり、過去のやり取りを記憶してくれたりします。
最初のうちはプラグインなしで十分なので、ある程度慣れてきたら検討すればOKです。
第2章 WEBサービスの仕組みを知ろう
Claude Codeを使う前に、「そもそもWEBサービスってどうやって動いてるの？」をざっくり理解しておきましょう。
これを知っておくと、AIとの会話でつまずくことがぐっと減ります。
ブラウザとサーバーのやりとり
みなさんが普段使っているWebサイトは、こんな仕組みで表示されています。
あなた（ブラウザ） インターネット サーバー
| |
| ── 「このページ見せて」──────────────────→ |
| |
| ←──── 「ここにファイルあるよ」──────────── |
| |
画面に表示
- あなたがブラウザ（ChromeやSafariなど）でURLを入力する
- そのURLに対応した「サーバー」というコンピュータにアクセスのリクエストが飛ぶ
- サーバーが「はいどうぞ」とファイルを返す
- ブラウザがそのファイルを読み取って画面に表示する
これがWebページが表示されるまでの流れです。
たったこれだけ、と思うかもしれませんが、Amazonでも楽天でもInstagramでも、根本はぜんぶこの仕組みです。
サーバーってなに？
サーバーとは、インターネット上に置いてある「常に起動しているコンピュータ」です。
あなたのパソコンやスマホは電源を切ると使えなくなりますよね。でもサービスは24時間365日アクセスできないといけません。そのために「常に起動し続けているコンピュータ」がサーバーです。
身近なイメージで言うと、
「24時間営業のレストランの厨房」のようなもの。
誰かが「ハンバーグください」とリクエストすると、すぐに作って渡してくれる。
それをインターネット経由でやっているのがサーバーです。
サーバーには「種類」と「プラン」がある
レストランに「個人経営の小さな店」と「ファミレスチェーン」があるように、サーバーにも色々な種類とプランがあります。
- 共用サーバー（安い）: 一つのサーバーを複数の人で借りる。アクセスが少ないサービス向け
- VPS（中くらい）: 自分専用の領域がもらえる。ちょっとカスタマイズもできる
- クラウドサーバー（AWS、GCPなど）: 必要に応じて性能を上げ下げできる。本格的なサービス向け
最初は深く考えなくてOK。Claude Codeに「初心者でも使いやすいサーバーを教えて」と聞けば、状況にあった提案をしてくれます。
ローカル環境と本番環境
開発する上で絶対に出てくる2つの言葉があります。
| 言葉 | 意味 | イメージ |
|---|---|---|
| ローカル環境 | 自分のパソコンの中だけで動かす | 自宅のキッチンで試作する |
| 本番環境 | 実際にインターネットに公開されているサーバー上 | レストランで実際にお客さんに出す |
開発はまずローカル環境で行います。自分のパソコンの中でサービスを動かして確認しながら作り、完成したら本番環境（インターネット上のサーバー）に反映させます。
本番環境に反映させることを「デプロイ」または「リリース」と言います。
なぜローカル環境で先に作るのか？
「最初から本番でいいじゃん」と思うかもしれませんが、それはNGです。
理由は、本番環境で間違ったコードを動かすと、世界中のユーザーに迷惑がかかるからです。
たとえば、料理を試作もせずに直接お客さんに出すお店は絶対にないですよね。同じです。
ローカルで動作確認→OKなら本番にデプロイ、という流れが鉄則です。
データベース（DB）ってなに？
WEBサービスには必ず「データベース（DB）」が必要になります。
データベースとは、ブラウザを閉じても消えないデータを保管しておく場所です。
たとえば：
- ユーザーのメールアドレスやパスワード
- 投稿した記事の内容
- 購入履歴
- いいねの数
これらはブラウザを閉じても消えてほしくないですよね。そういったデータを保管する「保管庫」がデータベースです。
イメージとしては「巨大なExcel」
データベースは、ものすごく雑に言うと「Excelの表をたくさん集めた保管庫」です。
【ユーザー表】
ID | 名前 | メール | パスワード
1 | 田中 | tanaka@xx.com | xxxxxxxxxx
2 | 山田 | yamada@xx.com | xxxxxxxxxx
【投稿表】
ID | ユーザーID | タイトル | 内容
1 | 1 | 今日の朝食 | 卵焼きを作った
2 | 2 | おすすめの本 | 〇〇という本が...
こんな感じで、データを表形式で保存しておきます。
このデータを引っ張り出してきて画面に表示することで、サービスが成立します。
フロントエンドとバックエンド
WEBサービスの世界では、「フロント」「バック」という言葉もよく出てきます。
| 言葉 | 役割 | 担当 |
|---|---|---|
| フロントエンド | ユーザーから見える画面の部分 | 画面のデザイン、ボタンの動き |
| バックエンド | 裏側の処理 | データベースとのやり取り、計算ロジック |
例: ログインボタンを押す → 「ボタン」がフロントエンド、「メールアドレスとパスワードが正しいかチェックする処理」がバックエンド。
両方とも必要で、Claude Codeはどちらも書いてくれます。
通信ってなに？ API ってなに？
サービスを作っていると「API」という言葉が出てきます。
**API（エーピーアイ）**とは、サーバーに何かをお願いするための窓口です。
たとえば、Instagramの「いいねボタン」を押したとします。
このとき裏では、
ブラウザ → サーバーに「この投稿、いいね追加して」とAPIでお願い
サーバー → データベースを更新して「いいね数+1にしたよ」と返す
ブラウザ → 数字を更新して画面に表示
というやり取りが行われています。
この「お願いをやり取りする窓口」がAPIです。
外部のサービス（たとえばGoogleやTwitter、後で説明する決済サービスのStripeなど）と連携するときも、相手のAPIを通してデータをもらいます。
セッション・クッキー・ローカルストレージ
これらは「ブラウザ側に情報を一時保存する仕組み」です。
| 名前 | 説明 | よく使われる場面 |
|---|---|---|
| セッション | ログイン中だけ覚えておく情報 | ログイン状態の維持 |
| クッキー（Cookie） | ブラウザに長期保存される小さなデータ | 「ログイン状態を保持」のチェック |
| ローカルストレージ | ブラウザに長期保存される大きめのデータ | 設定・下書きの保存 |
最初は全部「ブラウザに何かを覚えさせる仕組み」とだけ理解すればOKです。
詳しい使い分けはAIが勝手にやってくれます。
第3章 WEBサービスの基本構成を知ろう
どんなWEBサービスにも、ほぼ必ずある「基本の機能」があります。
どのサービスにもある基本機能
| 機能 | 説明 |
|---|---|
| ホーム（トップページ） | サービスの顔。最初に表示される画面 |
| ユーザー登録（新規登録） | 新しいアカウントを作る機能 |
| ログイン | 既存のアカウントでサービスに入る機能 |
| ログアウト | アカウントからサインアウトする機能 |
| マイページ（プロフィール） | 自分の情報を確認・編集できる画面 |
| パスワード再設定 | パスワードを忘れたとき用 |
| お問い合わせ | ユーザーからの連絡を受け取る画面 |
| 利用規約・プライバシーポリシー | 法的に必要な情報を表示する画面 |
これらは「認証機能」とまとめて呼ばれることが多く、Claude Codeに「認証機能を一式作って」と言えばまとめて作ってもらえます。
よく使うサービス独自の機能
サービス特有の機能としては、よくこういうものがあります。
| 機能 | 説明 | 例 |
|---|---|---|
| 一覧表示 | データを一覧で見せる | 商品一覧、投稿一覧 |
| 詳細表示 | 1件分の詳しい情報を見せる | 商品詳細ページ |
| 検索 | 条件に合うデータを探す | キーワード検索、絞り込み |
| 投稿・登録 | 新しいデータを追加する | 記事投稿、商品登録 |
| 編集 | 既存データを変更する | プロフィール編集 |
| 削除 | データを消す | 投稿削除 |
| 通知 | ユーザーに知らせる | メール通知、画面上の通知 |
| 決済 | お金のやり取り | Stripe、PayPalなどと連携 |
これらは「CRUD（クラッド）」と呼ばれる基本操作で、サービスの土台になります。
CRUD = Create（作成）、Read（読み取り）、Update（更新）、Delete（削除）
「CRUD作って」と言うとAIは何のことか即理解します。
第4章 画面を構成するUI部品の名前
「ここのボタンを赤にして」と言うためには、「ボタン」という言葉を知っている必要があります。
同じように、画面を構成する部品の名前を知っておくと、AIへの指示がぐっと正確になります。
画面の構造
┌─────────────────────────────────────────┐
│ ヘッダー │ ← 上部にある帯。ロゴやメニューが入ることが多い
├─────────────────────────────────────────┤
│ │
│ │
│ メインエリア │ ← ページの主要なコンテンツが入る部分
│ │
│ │
├─────────────────────────────────────────┤
│ フッター │ ← 下部にある帯。コピーライト等が入る
└─────────────────────────────────────────┘
サイドバーがあるレイアウトだとこんな感じ。
┌─────────────────────────────────────────┐
│ ヘッダー │
├─────────┬───────────────────────────────┤
│ │ │
│サイドバー│ メインエリア │
│ │ │
├─────────┴───────────────────────────────┤
│ フッター │
└─────────────────────────────────────────┘
よく使うUI部品の名前
| 部品名 | 説明 | 例 |
|---|---|---|
| ボタン | クリックして何かを実行する | 「送信」「削除」ボタン |
| テキストフィールド（入力欄） | 文字を1行入力する | 名前を入力する欄 |
| テキストエリア | 文字を複数行入力する | コメント入力欄 |
| セレクトボックス（プルダウン） | ドロップダウンで選ぶ | 都道府県の選択 |
| チェックボックス | ON/OFFをチェックで切り替える | 「利用規約に同意」 |
| ラジオボタン | 複数から1つだけ選ぶ | 「男性/女性/その他」 |
| トグル（スイッチ） | ON/OFFをスイッチで切り替える | 通知のON/OFF |
| モーダル（ダイアログ） | 画面の上に重ねて出てくる小窓 | 「本当に削除しますか？」 |
| アラート（アラートウィンドウ） | 警告・お知らせを表示する小窓 | 「保存しました」 |
| トースト（スナックバー） | 画面の端に一時的に出る通知 | 「コピーしました」 |
| テーブル（表） | 表形式でデータを並べる | 売上一覧表 |
| カード | 1つの情報をまとめた四角い枠 | 商品カード、記事カード |
| タブ | 切り替え式の表示 | プロフィール / 投稿 / フォロワー |
| アコーディオン | 開閉式の見出し | FAQの質問と回答 |
| パンくずリスト | 現在地を示すリンク | ホーム > 商品一覧 > 商品詳細 |
| ページネーション | ページ送りのボタン | 「< 1 2 3 ... >」 |
| ラベル | 入力欄などにつく名前 | 「メールアドレス」という見出し |
| アイコン | 小さい絵記号 | ハートマーク、ベルマーク |
| バッジ | 数字や状態を示す小さい印 | 「通知3件」の赤い丸 |
| ツールチップ | マウスを乗せると出る吹き出し | アイコンの説明 |
| スピナー（ローディング） | 読み込み中のクルクル | 通信中の表示 |
覚えておくとAIに伝わりやすいやつ
特にこの3つは超頻出です。
モーダル
「削除ボタン押したら、本当に削除しますか？ってモーダルを出して」
トースト
「保存に成功したら、画面下にトーストで『保存しました』って出して」
バリデーション（入力チェック）
「メールアドレスの欄、@が入ってなかったらエラーメッセージを出して。これをバリデーションって呼ぶよね」
第5章 Git（ギット）ってなに？
開発を始めるとほぼ確実に出てくる言葉が「Git（ギット）」です。
Gitは「ファイルの変更履歴を記録するシステム」
Gitとは、ファイルの変更履歴を全部記録しておくシステムです。
イメージはこんな感じ。
v1: 最初のバージョン
↓
v2: ログイン画面を追加
↓
v3: ログイン画面のデザイン変更
↓
v4: バグ修正
↓
v5: 新機能追加 ← 今ここ
「あ、v3のデザインの方が良かった、戻したい」というときに、いつでも過去のバージョンに戻せます。
GitHub / GitLab / Bitbucket
Git自体は「仕組み」ですが、そのGitの履歴をインターネット上に保管するサービスがあります。
- GitHub（一番有名）
- GitLab
- Bitbucket
これらに自分のコードを保管しておくと、
- パソコンが壊れても安心（バックアップ）
- 他の人と一緒に開発できる
- 過去のバージョンにいつでも戻せる
- 本番環境への自動デプロイの起点にもなる
Claude Codeを使うときは、最低限「GitHubにアカウントを作る」だけはやっておきましょう。あとはAIが操作の仕方を教えてくれます。
Gitで覚えるべき5つの言葉
最初に覚えるのはこれだけでOK。
| 言葉 | 意味 |
|---|---|
| コミット (commit) | 「ここまでの変更を記録する」 |
| プッシュ (push) | 「自分のパソコンの記録をGitHubに送る」 |
| プル (pull) | 「GitHubから最新の記録をパソコンに持ってくる」 |
| ブランチ (branch) | 「その時点にあるファイルを全部コピーして、コピーした方で作業する」仕組み。そうすることで、もし不具合が出たり、やめたくなったときでも、そのコピー（ブランチ）を削除すれば元のファイルは元のまま残った状態にできる |
| マージ (merge) | 「枝分かれしたブランチ（コピーして編集を加えたファイルたち）を、本流（大元のファイルたち）に合流（合体）させる」こと |
ブランチのイメージ
master(本流・大元のファイルたち)
●─────────●───────────●───→
\ /
●コピー────●編集─── ← ファイルを全部コピーして、こっちで編集
(新機能ブランチ)
たとえば、いま動いているサービスがあって、新機能を試したいとします。
本流のファイルを直接いじって失敗したら、サービスが壊れてしまいますよね。
そこで、いったんファイルを全部コピーして、コピーした方で作業する。
これが「ブランチを切る」ということです。
- 上手くいったら → コピーした方を本流に合流させる（マージ）
- 失敗した → コピーをまるごと削除すれば、本流のファイルは無傷のまま
新機能を試すたびに「ファイル全部コピーするのめんどくさ」と思いますよね。
でも、Gitはこれをコマンド1つで一瞬でやってくれます。Claude Codeに「新機能用のブランチを切って」と言えば、それだけでOK。
第6章 決済の仕組みを知ろう
有料サービスを作るなら必ず必要になるのが「決済機能」です。
「クレジットカード情報を扱うなんて、未経験者には無理じゃないの？」と思うかもしれませんが、実は今は誰でもできる時代です。
自分でクレジットカード情報を扱ってはいけない
まず大前提として、
クレジットカード情報を自分のサーバーで保存・処理してはいけません
これは法律やカード会社のルール（PCI DSSという基準）で厳しく決められています。
セキュリティ事故が起きたら、損害賠償が億単位になるリスクもあります。
解決策：「決済代行サービス」を使う
そこで使うのが「決済代行サービス」です。
有名どころはこのあたり：
| サービス | 特徴 |
|---|---|
| Stripe（ストライプ） | 世界的に最も使われている。初期費用0円、API充実 |
| PayPay / LINE Pay / 楽天ペイ | 国内ユーザー向けのキャッシュレス決済 |
| Square（スクエア） | リアル店舗とWEBどちらでも使える |
| PayPal（ペイパル） | 海外ユーザーがメインなら便利 |
個人でWEBサービスを作るなら、Stripeが圧倒的におすすめです。
ドキュメントが豊富で、Claude Codeも一番得意な決済サービスです。
決済の仕組みをざっくり
Stripeを使った決済は、こんな流れで動きます。
ユーザー あなたのサービス Stripe カード会社
| | | |
|─購入ボタン押下→ | | |
| |─Stripeに依頼→ | |
|←──カード入力画面（Stripeが提供）── | |
| | |
|─カード情報入力→ Stripeに直接送信 | |
| |─認証依頼─→ |
| |←──OK ────── |
| ←─決済成功通知─ | |
|←──「購入ありがとう！」── | |
ポイントは、
カード情報はあなたのサーバーを一切通らない
ということ。ユーザーは「あなたのサービス上の購入ボタン」を押しますが、カード番号を入力する画面はStripeが提供してくれて、カード情報はそのままStripeに直送されます。
あなたのサーバーには「決済が成功しました」という通知だけが来ます。
これにより、未経験者でも安全に決済を組み込めるわけです。
決済で覚えておきたい言葉
| 言葉 | 意味 |
|---|---|
| 決済（けっさい） | お金を払う手続き全体のこと |
| 課金（かきん） | ユーザーにお金を払ってもらうこと |
| サブスク（サブスクリプション） | 月額や年額の定期支払い |
| 単発課金 | 1回だけの支払い |
| Webhook（ウェブフック） | Stripeから「決済成功した！」とお知らせを受け取る仕組み |
| テストモード | 本物のお金が動かない、開発用の決済モード |
| 本番モード（ライブモード） | 本物のお金が動く、リリース後の決済モード |
| APIキー | Stripeとあなたのサービスを繋ぐためのパスワードみたいなもの |
| リファンド（返金） | 一度受け取ったお金を返すこと |
| チャージバック | カード会社経由でユーザーから返金請求されること |
決済機能を作る大まかな流れ
- Stripeのアカウントを作る（無料）
- テストモードのAPIキーを取得
- Claude Codeに「Stripeで月額1,000円のサブスク機能を作って」と依頼
- テストカード番号でテスト（Stripeが用意してくれている）
- 動作確認OKなら、本人確認書類を提出して本番モード有効化
- 本番APIキーに切り替えて、本番リリース
実際にAIにやってもらう時のセリフ例：
「Stripeを使って、月額1,000円のサブスク機能を作って。テストモードで動くようにして、後で本番モードに切り替えられるようにしたい。APIキーは環境変数で管理して、コードに直書きしないで」
これだけで、AIが必要なコードを一式書いてくれます。
決済機能で特に気をつけること
① 必ず「テストモード」で十分にテストする
Stripeにはテスト用のカード番号があります。
-
4242 4242 4242 4242（成功するテストカード） -
4000 0000 0000 0002（失敗するテストカード）
これらを使って、成功時・失敗時の両方の挙動を確認しましょう。
本番モードに切り替える前に、ありとあらゆるパターンをテストすることが鉄則です。
② APIキーを絶対に公開しない
APIキーは「あなたのStripeアカウントを操作できる鍵」です。
これがGitHubの公開リポジトリに上がってしまうと、悪意のある人にアカウントを乗っ取られます。
必ず「環境変数」という仕組みで管理してください
Claude Codeに「APIキーは環境変数で管理して」と最初に伝えれば、ちゃんとそうしてくれます。
③ Webhookで決済完了を確認する
「決済画面でOKを押した = 決済完了」ではありません。
カード会社の最終承認まで含めると、決済の最終結果はStripeからWebhook経由で通知されます。
Claude Codeに「Webhookで決済完了を受け取って、データベースに記録するところまで作って」と依頼すれば、ちゃんと作ってくれます。
④ 特定商取引法に基づく表記
日本で有料サービスを提供する場合、法律で「特定商取引法に基づく表記」というページが必須です。
事業者情報、価格、返金ポリシーなどを書く必要があります。
これもClaude Codeに「特商法に基づく表記のページを作って。中身は埋める前提でテンプレートを作って」と頼めば作ってくれます。
⑤ 利用規約とプライバシーポリシー
決済を扱うサービスでは特に重要です。
不安なら一度AIに「利用規約のドラフトを作って」と頼んで、最終的には弁護士やひな形サービスに相談するのが安心です。
困ったらClaudeに聞けばいい
決済まわりは細かいルールが多いですが、わからないことはClaudeに聞けば全部教えてくれます。
「サブスクの解約処理ってどうするのが普通？」
「Stripeで日本円以外も扱えるようにするには？」
「決済失敗したユーザーに自動でリトライさせたい」
「インボイス制度に対応した領収書を発行したい」
こんな相談にも、ちゃんとした答えが返ってきます。
最初は完璧を目指さず、「最低限の決済機能 → リリース → 必要に応じて拡張」の流れで進めるのがおすすめです。
第7章 Claude Codeを使う前の準備
必要なもの
- パソコン（Windows / Mac どちらでもOK）
- Claudeのアカウント（Pro以上の有料プラン推奨）
- GitHubアカウント
- Stripeアカウント（決済を入れるなら）
- やる気
大まかな導入の流れ
1. Claudeアカウントを作る
↓
2. ターミナルを開いてClaude Codeをインストール
↓
3. プロジェクトを保存するフォルダを作る
↓
4. そのフォルダに移動してclaudeコマンドを実行
↓
5. AIと会話して開発開始
詳しいインストール手順は時期によって変わるので、docs.claude.com で最新を確認するのが確実です。
わからなければClaudeのチャット版に「Claude Codeのインストール方法を教えて」と聞けば手取り足取り教えてくれます。
第8章 Claude Code で知っておくべきこと
モデル（賢さのランク）の使い分け
Claude Codeでは、AIの「賢さレベル」を選べます。賢いほど高性能ですが、その分料金も高くなります。
| モデル | 得意なこと | 速度 | 料金 |
|---|---|---|---|
| Haiku（ハイク） | 単純作業・ファイル探し | 速い | とても安い |
| Sonnet（ソネット） | 大半のコーディング作業 | 普通 | 普通 |
| Opus（オーパス） | 複雑なバグ追跡・大規模設計 | 遅い | 高い |
プログラミング未経験者なら「Opus」一択
理由は、未経験者の指示はどうしても「ふんわり」しがちだからです。
Opusは言ってないことまで察してくれるので、未経験者には一番ストレスがありません。
「ログイン画面作って」
Sonnet → ログイン画面だけきっちり作る
Opus → ログイン画面 + パスワード忘れリンク + バリデーション + エラー表示まで一式作る
ある程度慣れて、自分で細かく指示が出せるようになったらSonnetでもOKです。
工数（思考の深さ）の使い分け
Claude Codeでは「工数」または「思考の深さ」を設定できます。
これは「どれだけじっくり考えるか」の設定で、低 / 中 / 高 / 超高 / MAX から選べます。
| 工数 | 用途 |
|---|---|
| 低 | ファイル探し、軽い確認、雑談 |
| 中 | 通常の機能追加、小さなバグ修正（デフォルト） |
| 高 | 画面挙動の不具合、複雑な機能追加 |
| 超高 | 計算ロジックのバグ、大規模設計判断、決済まわりの実装 |
| MAX | ここぞというときの全力モード |
工数による違いの例
「このファイルどこ？」と聞いた場合の答え方の違い：
| 低 | 超高 | |
|---|---|---|
| 回答スタイル | 「docs/xxxxx.md です」で終了 |
「ここです。関連ファイルもあって、最新版はこちらです」と周辺情報まで付ける |
| ツール使用 | 最短ルート | 念のため複数の場所を確認 |
| 確信度 | 即断 | 「他にも候補があるかも」と検証してから答える |
注意点
単純な質問に「超高」を使うとトークン（≒お金）を無駄に消費します。
逆に、複雑なバグ追跡に「低」を使うと、AIが浅い思考で間違った答えを返してくる可能性があります。
「いつもは中、迷ったら高、ヤバいときだけ超高」 くらいで考えればOKです。
ただし、**決済まわりの実装は最低でも「高」、できれば「超高」**で進めるのがおすすめです。お金が絡むので、AIにじっくり考えてもらった方が安全です。
セッション・トークン・料金
Claude Codeを使っていると「セッション」「トークン」という言葉が出てきます。
| 用語 | 意味 |
|---|---|
| セッション | 一回の会話のまとまり |
| トークン | AIが消費する「単位」。文字数みたいなもの |
なぜトークンを意識すべきなのか
Claude Codeは使うほどお金がかかります。
特に、長く会話を続けると過去のやり取りも全部AIが読み返すため、1ターンあたりの消費トークンがどんどん増えていきます。
イメージは「タクシーのメーター」のような感じ。乗っているだけで料金が増えていきます。
トークン節約のコツ
-
作業がひと段落したら新しいセッションを始める
- 長く続けるほど料金が高くなる
-
モデルと工数を作業に合わせる
- 単純作業にOpus + 超高を使わない
-
MEMO.mdに重要事項をまとめておく
- 新セッションでもすぐ続きから始められる
MEMO.md という強力な仕組み
Claude Codeでは「MEMO.md」というファイルを活用すると、開発が劇的にスムーズになります。
使い方
セッションの最後にこう言うだけ。
「今日やったことと、続きでやることをMEMO.mdに残して」
すると、AIがプロジェクトのフォルダに MEMO.md というファイルを作って、要約を残してくれます。
次に新しいセッションを始めるときは、
「MEMO.mdを見て、続きから始めて」
これで前回の続きからすぐに作業に入れます。
MEMO.mdに残すと便利なもの
- 開発の手順・ルール
- 毎回伝えるのが面倒な情報（プロジェクト名、テスト用ID等）
- 設計の判断理由
- 「これだけは絶対忘れないで」という重要事項
これがあるだけで、毎回ゼロから説明する手間が省けます。
フォークと新規セッション、どっちがいい？
Claude Codeでは、セッションを「フォーク（途中から枝分かれ）」することもできます。
| 方法 | 使うべき場面 |
|---|---|
| 新規セッション | 別の作業を始める。過去のやり取りはリセットして気分一新 |
| フォーク | 「ここまでは合ってる、ここから別パターンを試したい」 |
迷ったら新規セッションでOKです。フォークは慣れてきてからで十分。
第9章 AIへの伝え方の工夫
ここが実は一番大事なところです。
AIは「言われた通り」にしか作らない
Claude Codeはとても優秀ですが、基本的には言われた通りのものを作ります。
「ログイン画面を作って」
と言うと、ログイン画面は作ってくれます。でも、
- パスワードを忘れた人向けのリンクは？
- パスワードの最低文字数は？
- ログインに失敗した時のエラー表示は？
- ログイン後の遷移先は？
こういった「言わなかった部分」は、AIが自分の判断で勝手に決めて作ります。
その判断があなたの想定と違うと、「あれ？こんなの作って欲しかったわけじゃないんだけど…」となります。
対策①: 要件をできるだけ細かく伝える
ふんわりした指示は、ふんわりした結果になります。
❌ ダメな例:
「ログイン機能作って」
⭕ いい例:
「ログイン機能を作って欲しい。
- メールアドレスとパスワードでログイン
- パスワードは8文字以上、英数字混合
- ログイン失敗時は『メールアドレスかパスワードが違います』と表示
- パスワード忘れ用のリンクを下に配置
- ログイン成功したらマイページに遷移」
対策②: 「質問・疑問・懸念点はある？」と都度聞く
これがものすごく重要です。
依頼を伝えたら、最後に必ずこう聞きましょう。
「ここまでの要件で、質問・疑問・懸念点はありますか？」
すると、AIが「ここは決めてなかったですが、こうしますか？」と確認してくれます。
これをやらないと、AIは勝手に判断して進めてしまい、後で「いやそうじゃない」となるリスクが高まります。
対策③: 「気付かぬ不具合」に注意
AIは要件通りにしか作らず、要件通りにしかテストもしません。
なので、要件自体が間違っていると、間違ったままサービスができあがります。
たとえば、
「会員登録は無料で、月額1,000円で有料会員になれる機能を作って」
と頼んだとして、本当は「無料会員もある程度機能を使えるべきだった」のに「無料会員は何もできない」設計だったとします。
AIは要件通り作るので、後でテストしても「無料会員は何もできない」のは正常な挙動として扱われ、不具合として検出されません。
これを防ぐには、
- 作る前にAIに要件を一度復唱してもらう
- 「他に考慮した方がいいことある？」と聞く
- 画面遷移図や機能一覧を先に作ってもらう
これだけでも精度が大幅に上がります。
「よしなに」を引き出すコツ
「全部こっちが考えるなんて無理」という方は、Opus + 工数:高 を使って、こう聞いてみてください。
「〇〇というサービスを作りたい。どんな機能が必要か、画面構成も含めて提案して。一通り聞いた上で『他に考えるべきこと』も教えて」
これでAIが企画段階から伴走してくれます。
人間が0から考えるよりも、AIに提案させてから取捨選択する方が圧倒的に早いです。
伝え方テンプレート
困ったらこのテンプレで伝えてみてください。
【作りたいもの】
〇〇という機能
【目的】
これを作ることで、ユーザーは〇〇できるようにしたい
【欲しい挙動】
- 〇〇したら〇〇する
- 〇〇のときは〇〇を表示
【UIのイメージ】
〇〇画面の上の方にボタンを置いて、押すとモーダルが出る
【懸念点があったら教えて】
ここまでの要件で、足りない点、おかしい点、確認したい点があれば教えてください
第10章 開発の流れ
実際の開発は、ざっくりこんな流れで進みます。
1. Claude Codeの導入
↓
2. Gitの導入とGitHubリポジトリ作成
↓
3. ローカル環境の構築
↓
4. Gitで開発ブランチを作る（ファイルをコピーした作業用の枝）
↓
5. AIに依頼して開発
↓
6. ローカルで動作確認・テスト
↓
7. Gitにコミット & プッシュ
↓
8. masterブランチにマージ（コピーした方を本流に合流）
↓
9. 本番環境にデプロイ
↓
10. 本番環境でテスト
これを機能ごとに繰り返していくのが基本のサイクルです。
1〜3: 最初の1回だけやる準備
- Claude Codeのインストール
- GitHubでリポジトリ（プロジェクトの保管場所）を作る
- ローカルで動かせる状態にする
ここはClaude Codeに「初心者だけど、〇〇というサービスを作りたい。最初のセットアップから一緒にやって」と言えば手取り足取りやってくれます。
4: ブランチを切る
「新機能を作ろう」と思ったら、まずブランチを切る（ファイル一式をコピーして、コピーした方で作業する）のがお作法です。
> 「ログイン機能を作るための開発ブランチを切って」
これで、本流のファイルに影響を与えずに新機能を作れます。
万が一うまくいかなくても、ブランチを削除すれば元のファイルは無傷です。
5: 開発する
AIと会話しながら開発を進めます。
このとき意識すべきは：
- 小さな単位で動作確認しながら進める
- 画面ができるたびに実際に動かしてみる
- 疑問が出たらすぐ聞く
6: ローカルでテスト
機能が完成したら、必ずローカルで実際に動かしてテストします。
詳しくは次の章で説明します。
7-8: Gitに記録する
ローカルで動作確認OKだったら、Gitに記録して本流に合流させます。
> 「ここまでの変更をコミットしてプッシュして、その後masterにマージして」
これだけでAIがやってくれます。
9: 本番にデプロイ
最後に本番環境にアップロードします。
> 「最新のmasterを本番にデプロイして」
サーバーの種類によって手順が違うので、Claude CodeにサーバーやURLを伝えておくと、ちゃんと環境に合わせてやってくれます。
10: 本番でテスト
ローカルで動いていても、本番で動くとは限りません。
必ず本番環境でも最後に動作確認します。
理由は、ローカルと本番では微妙に環境が違うことが多いからです（OSのバージョン、データベースの種類、設定値など）。
決済を組み込んでいる場合は、本番モードに切り替える前に、Stripeのテストモードで本番環境でもテストすることを忘れずに。
第11章 テストで大事なこと
サービスを作ったら、必ずテストをします。
プログラミング未経験者が一番ハマるのが「自分でテストする観点」です。
「ユーザーになりきってテストする」が基本
開発者目線でテストすると、「自分が想定した通りの操作」しかしないので、不具合を見つけられません。
ユーザーになりきって、こう考えましょう。
- わざとおかしな操作をする: 空欄のまま送信、変な文字を入力など
- 想定外のルートを通る: ログインせずに直接URLを叩く、戻るボタンを連打など
- 違うブラウザでも試す: Chrome、Safari、Edgeなど
- スマホでも試す: 画面サイズが小さい時の挙動
テスト観点のチェックリスト
最低限、以下の観点でテストするのがおすすめです。
① 正常系のテスト
正しく動くかを確認するテスト。
- 正しい入力で正常に動くか
- 期待通りの画面遷移が起きるか
- データが正しく保存されるか
- 完了メッセージが出るか
② 異常系のテスト
わざと間違えてみるテスト。
- 空欄で送信したらエラーが出るか
- 不正な文字（特殊記号など）を入れたら？
- 既に登録済みのメアドで登録しようとしたら？
- 数値欄に文字を入れたら？
- 巨大すぎる数値を入れたら？
③ 境界値のテスト
「ギリギリ」のところでテスト。
- パスワード最低8文字なら、7文字と8文字でそれぞれ試す
- 100文字までOKなら、99・100・101文字で試す
- 0円、1円、上限金額前後で試す
④ 権限のテスト
「やっちゃダメな人が、やれてしまわないか」のテスト。
- ログインしないとアクセスできないページに、未ログインで入れてしまわないか
- 他人の投稿を、URLを直打ちで編集できてしまわないか
- 管理者画面に、一般ユーザーがアクセスできてしまわないか
- 有料会員専用ページに、無料会員がアクセスできてしまわないか
⑤ 画面・UIのテスト
- スマホ画面でレイアウトが崩れていないか
- 文字が長くなったときにはみ出さないか
- ボタンを連打したら同じ処理が複数回走らないか
- 読み込み中の表示が出ているか
⑥ 通信エラー時のテスト
- ネットを切った状態で操作したら？
- サーバーがエラーを返したらどう表示される？
- 通信が遅いときの挙動は？
⑦ 決済まわりのテスト（重要）
- テストカードで成功・失敗の両パターンを確認
- 決済成功時、ちゃんと有料会員になるか
- 決済失敗時、エラーメッセージが出るか
- サブスクの自動更新がちゃんと走るか
- サブスク解約後、課金されなくなるか
- Webhookが受け取れているか
- 連打で二重決済が起きないか
- APIキーが本番モード/テストモードで正しく切り替わるか
Claude Codeにテスト観点を出してもらう
これらを毎回手動で考えるのは大変なので、AIに任せましょう。
「この機能のテスト観点をリストアップして。正常系・異常系・境界値・権限の観点で漏れなく」
これでAIが網羅的にチェックリストを作ってくれます。
自動テストも作っておくと安心
慣れてきたら「自動テスト」を書いておくと、機能追加や修正のたびに自動でチェックしてくれます。
「ログイン機能の自動テストを書いて」
と言えば、AIが書いてくれます。
最初は手動テストで十分、慣れたら自動化、という流れがオススメです。
第12章 ハマりがちな落とし穴
最後に、初心者がハマりがちなポイントを共有します。
① AIの回答を盲信しない
AIは「もっともらしく間違える」ことがあります。
特に、エラーが出たときに「これで直りました」と言われても、実は直っていないことがあります。
必ず自分の目で動作確認すること
これは最低限のお作法です。
② ふんわり指示は、ふんわり結果
何度も言いますが、ふんわり伝えるとふんわりした結果になります。
特に未経験者は「自分が何を求めているか」を言語化するのが難しいので、
「私がやりたいことを整理する手伝いをして」
と最初に頼むのがオススメです。
③ いきなり大きな機能を作らせない
「Twitterみたいなサービス作って」と言うと、AIはやろうとしますが、絶対にどこかで破綻します。
機能を細かく分解して、ひとつずつ作っていくのが鉄則です。
✅ いい流れ:
- まずユーザー登録機能だけ作る
- 動作確認 → コミット
- 次に投稿機能を作る
- 動作確認 → コミット
- 次にタイムライン機能…
- 最後に決済を組み込む
④ コミットせずに突き進まない
「動いてるからまだコミットしなくていいや」で突き進むと、ある日突然全部壊れたときに戻る場所がなくて詰みます。
動いた段階で、こまめにコミット
これも鉄則です。
⑤ 本番に直接手を入れない
本番環境を直接いじりたくなる衝動が、必ず出てきます。
「ここだけちょっと直したい」「テストするのが面倒」と思っても、絶対にやめましょう。
ローカル → テスト → デプロイの流れを守るのが、結果的に一番早いです。
⑥ トークン浪費に気づかない
「今日も楽しく開発してたら月末にすごい請求が来た」というのはあるあるです。
- 単純作業に高いモデル・工数を使わない
- セッションが長くなりすぎたら新規セッションに切り替える
- MEMO.mdをうまく活用する
これだけで料金は大幅に抑えられます。
⑦ AIに丸投げしすぎて、自分が何を作っているかわからなくなる
AIが何を作ったかは、最低限自分で把握しておきましょう。
- どんなファイルができたか
- どの画面でどの機能が動くか
- データはどこに保存されているか
これがわかっていないと、後で不具合が出たときに何を直せばいいかも伝えられません。
⑧ 決済を最後に「とりあえずテストモードで」確認して終わらない
決済まわりは、本番モードに切り替えた瞬間に挙動が変わることがあります（特にWebhookのURLや、本人確認の有無など）。
本番モードに切り替えた直後、必ず自分のクレジットカードで少額決済を試す
これをやらずにリリースすると、「ユーザーが決済できない」「課金されたのに有料会員にならない」といった事故が起きます。
自分で少額（100円〜500円）の決済を試して、ちゃんと有料会員になることを確認しましょう。
その後、Stripeのダッシュボードから返金処理すればOKです。
⑨ APIキーをGitHubに上げてしまう
これは本当に多い事故です。
StripeのAPIキー、Anthropic APIキーなど、すべての「鍵」となるものは絶対にコードに直書きせず、環境変数で管理しましょう。
万が一上げてしまったら、すぐにStripeのダッシュボードでキーを再発行すれば被害は最小限になります。
第13章 よくある単語まとめ（辞書）
最後に、開発中に出てくる単語のミニ辞書を置いておきます。
開発全般
| 単語 | 意味 |
|---|---|
| コード（ソースコード） | プログラムの文字列のこと |
| ファイル | コードや設定が書かれた1つの書類 |
| ディレクトリ（フォルダ） | ファイルをまとめておく入れ物 |
| プロジェクト | 1つのサービスを作るためのフォルダ一式 |
| 環境 | コードを動かす場所（ローカル・本番など） |
| エラー | 何かが間違っていますよ、というシステムからの通知 |
| ログ | システムが動いた記録 |
| ライブラリ | 便利な機能をまとめた部品集 |
| フレームワーク | ライブラリの集合体で、開発の土台になるもの |
| 環境変数 | パスワードなど、コードに直接書きたくない設定値 |
サーバー・ネットワーク
| 単語 | 意味 |
|---|---|
| サーバー | サービスを動かしているコンピュータ |
| クライアント | サーバーにアクセスする側（ブラウザ等） |
| API | サーバーと通信するための窓口 |
| HTTP / HTTPS | 通信の仕組み。HTTPSは暗号化されていて安全 |
| ドメイン |
example.com のような名前 |
| DNS | ドメインを実際のサーバーに繋ぐ仕組み |
| デプロイ | 本番環境に反映すること |
| サーバー負荷 | サーバーにかかっている処理の重さ |
データ
| 単語 | 意味 |
|---|---|
| データベース（DB） | データの保管庫 |
| テーブル | データベースの中の表 |
| カラム | テーブルの列（項目名） |
| レコード | テーブルの1行のデータ |
| クエリ | データベースへの問い合わせ |
| JSON | データのよくある形式。{ "name": "田中" } みたいなやつ |
フロントエンド
| 単語 | 意味 |
|---|---|
| HTML | 画面の骨組み |
| CSS | 画面の見た目（色・配置等） |
| JavaScript | 画面の動き |
| Vue / React | JavaScriptを便利にするフレームワーク |
| コンポーネント | 画面の部品（ボタン・ヘッダー等）の単位 |
| レスポンシブ | 画面サイズに合わせて見た目が変わること |
Git関連
| 単語 | 意味 |
|---|---|
| リポジトリ | プロジェクトの保管庫（GitHub上） |
| コミット | 変更を記録する |
| プッシュ | 自分のPCからGitHubに送る |
| プル | GitHubから自分のPCに持ってくる |
| ブランチ | その時点のファイルを全部コピーして作業する枝 |
| マージ | 枝分かれしたブランチを本流に合流（合体）させる |
| プルリクエスト（PR） | 「このブランチを合流させていい？」のリクエスト |
| コンフリクト | マージ時にコードがバッティングしてエラーが出ること |
決済関連
| 単語 | 意味 |
|---|---|
| Stripe | 個人開発で一番よく使われる決済代行サービス |
| 決済代行 | カード会社とのやり取りを代わりにやってくれるサービス |
| サブスク | 月額/年額の定期支払い |
| 単発課金 | 1回だけの支払い |
| Webhook | 決済の結果通知を受け取る仕組み |
| テストモード | 本物のお金が動かない開発用モード |
| 本番モード | 本物のお金が動くリリース後のモード |
| APIキー | サービスとサービスを繋ぐ鍵 |
| リファンド | 返金 |
| チャージバック | カード会社経由の返金請求 |
| PCI DSS | カード情報を扱う際の国際的なセキュリティ基準 |
| 特商法に基づく表記 | 日本で有料サービスに必須の法的ページ |
その他
| 単語 | 意味 |
|---|---|
| バグ（不具合） | 想定外の動作 |
| デバッグ | バグを見つけて直す作業 |
| リファクタリング | 動作は変えずに、コードをきれいにする作業 |
| テスト | 動作確認 |
| モック | 仮の表示・仮のデータ |
| CRUD | Create / Read / Update / Delete の頭文字 |
| バリデーション | 入力値のチェック |
| 認証 | 「あなたは誰？」のチェック（ログイン） |
| 認可 | 「あなたに権限ある？」のチェック（管理者かどうか等） |
| セッション | ログイン状態などの一時保存情報 |
| クッキー | ブラウザに保存される小さなデータ |
| ローカルストレージ | ブラウザに保存される大きめのデータ |
おわりに
Claude Codeを使えば、プログラミング未経験でも本当にWEBサービスが作れます。決済機能を組み込んだ本格的なサービスでもです。
ただし、AIは魔法ではなく「超優秀な部下」です。
部下に仕事を頼むには、
- 何をやってほしいか、なるべく具体的に伝える
- 進捗を確認する
- おかしいと思ったら聞く
- 成果物を自分でも確認する
これは人間の部下相手でも、AI相手でも同じです。
最初は戸惑うこともあると思いますが、何度か繰り返すうちに「AIへの伝え方のコツ」が身についていきます。
最後に一番大事なこと
わからないことは、Claudeに聞けばいい
この本に書いてあること以外で「これってなんだろう？」と思ったら、まずClaude Codeに聞いてみてください。
あなたのレベルに合わせて、丁寧に説明してくれます。
決済まわりも、サーバー設定も、ドメインの取り方も、リリース後の運用も、全部Claudeに相談しながら進められます。
完璧を目指さず、「動くものを作る → リリース → 改善」を回していきましょう。
それでは、楽しい開発ライフを！
この本は、プログラミング未経験者が Claude Code でWEBサービスを作るための入門書です。本書の内容は執筆時点のもので、ツールのアップデートにより一部の操作や料金は変わる可能性があります。最新情報は公式ドキュメント（docs.claude.com）を確認してください。そしてこの記事もサンプル（こんな感じで）をClaudeに渡して全部書いてもらちゃったもんです。初心者からしたらわかりづらいところが多々あり、僕的には40点くらいの記事でした。。