第5章作業開始の儀式とスクショ伴走モデル（コア章）

ここからが本書の中核です。

僕自身が「最初に教えてもらって良かった」と今でも思うポイントが集中するのが、この第5章。逆に言えば、これを知らないまま作業に飛び込むと、毎回ビクビクしながら進めることになります。

第5章は2部構成です。

第1部：作業開始の儀式（5-1〜5-3）

作業を始める前に、毎回やるべき2つのこと
これを習慣にすると、事故が劇的に減ります

第2部：スクショ伴走モデル（5-4〜5-11）

1工程ずつスクショを Code またはブラウザに渡して進める作業リズム
僕が3週間で複数のアプリを作った、その実体験から抽出した6つのパターン

それでは、儀式から始めましょう。

5-1. なぜ「作業開始の儀式」が必要か — 知らずに始める恐怖

【学習目標】

「作業開始の儀式」がなぜ大事なのかを理解する
知らずに作業を始めることのリスクを知る

【前提知識】

第4章まで完了していること

【概念解説】

Code を使い始める時、誰でも「とりあえず話しかけてみよう」と思いがちです。実際、第1章ではそれでもアプリが作れました。

でも、本格的に作業を始める段階になると、2つだけ、絶対に最初にやっておくべきことがあるんです。

どのフォルダで作業するかを Code に伝える
どのモードで進めるかを選ぶ（自動 / Plan）

この2つを「儀式」と呼んでいます。儀式と呼ぶ理由は、毎回必ずやる、習慣化するという意味を込めて。

儀式をサボるとどうなるか

正直、「最初に知らないと、知らないまま作業を始めてしまってたと思うと、恐怖でしかない」。具体的にはこういうことが起こりえます。

「Code がどのフォルダにファイルを作ったか分からない」→ 後でどこを探していいか分からない
「Code が勝手にどんどんファイルを書き換えていく」→ 気づいたら元に戻せない状態に
「思っていたのと全然違う方向に進んでいる」→ 軌道修正のタイミングを逃す

これらは全部、儀式をやっていれば回避できます。

儀式をやれば何が良いか

作業の出発点が明確になる → 後で迷子にならない
Code がどう動くかが予測できる → 安心して任せられる
失敗しても、儀式の段階に戻ればやり直せる

家を出る前に鍵を確認するのと同じです。たった数秒で、ものすごく大きな安心感が生まれる。

【ハンズオン手順】

▼ ブラウザ側でやること

ブラウザに次のように打ってみてください

Claude Code を使う前に、毎回やるべき「作業開始の儀式」として
私は次の2つを挙げています：
1. 作業フォルダを指定する
2. 自動モードか Plan モードかを選ぶ

これを毎回やる重要性を、初心者にも分かるように説明してください。

ブラウザが「いい習慣ですね」「これがあると事故が減ります」といった内容で答えてくれるはずです

【つまずきポイント】

「めんどくさい」と感じるかもしれませんが、儀式は10秒で終わります。1回の事故の方が、よっぽど時間を食います
慣れてくると、無意識にやれるようになります。最初の1週間だけ意識すれば、後は体が覚えます

【確認問題】

「作業開始の儀式」として、毎回やるべき2つのことは何ですか？
儀式をサボると、どんなリスクがありますか？

【次のレッスンへの橋渡し】

それでは、儀式の1つ目「フォルダ指定」を詳しく見ていきましょう。

5-2. フォルダを指定する — どこで作業するかを最初に決める

【学習目標】

作業フォルダを指定する具体的な方法を理解する
既存のプロジェクトを開く方法と、新規プロジェクトを始める方法を使い分けられる

【前提知識】

5-1 で儀式の重要性を理解したこと

【概念解説】

Code に何かを依頼すると、Code は自分のPCのどこかにファイルを作ったり、書き換えたりします。その「どこか」を最初に決めるのが、フォルダ指定です。

これをやらないと、Code は「適当な場所」にファイルを作ります。後で「あれ、どこにあるんだっけ？」となります。

3つのパターン

新しい作業を始める時、フォルダ指定には大きく3つのパターンがあります。

パターンA：新しい空フォルダを作って始める

新規プロジェクトの定番
たとえば「カフェ紹介サイトを作る」なら、デスクトップに cafe-site という空フォルダを作って、それを Code に指定
ファイルが1つもない状態から始まる

パターンB：既存のフォルダを開く

過去に作ったプロジェクトの続きをやる時
たとえば前回の作業で cafe-site フォルダにファイルがあるなら、それを再指定
既存のファイル群を Code が把握した状態で始まる

パターンC：何もないところから始める（非推奨）

フォルダ指定をせずに依頼する
Code が適当な場所にファイルを作る
どこに作られたか分からなくなる
やらないほうがいい

「最初は必ずパターンA か B を選ぶ」と強くおすすめするのは、パターンC で痛い目に遭うのを避けるためです。

【ハンズオン手順】

▼ Finder（Mac）／エクスプローラー（Windows）側でやること（新規フォルダ作成）

デスクトップに新しいフォルダを作る
フォルダ名は分かりやすく（例：cafe-site-test、practice-app など）
フォルダ名に日本語スペースは入れない方が無難（英数字＋ハイフンが安全）

▼ Code 側でやること（フォルダ指定）

左サイドバーの「New session」をクリック
「フォルダを選択」または「Open folder」のような画面が出る
さっき作ったフォルダを選択
Code がそのフォルダで作業を開始する状態になる
画面上部や左上に、選択したフォルダ名が表示されているはず

▼ Code 側でやること（既存フォルダを開く場合）

同じく「New session」をクリック
過去に作業したフォルダを選択
Code がそのフォルダの中身を読み込む
「このフォルダには既に index.html などがありますね」のような状況把握から始まる

▼ スクショ伴走のチェックポイント

フォルダを指定した直後の Code 画面（フォルダ名が表示されている状態）のスクショを撮っておくと、「自分は今どのフォルダで作業しているか」を確認する基準になります

▼ 困ったら聞く例

Code に →「フォルダを指定したつもりですが、Code が認識していないようです。今選択されているフォルダを教えてください」
ブラウザに →「Code でフォルダを指定する方法が分かりません。具体的な操作を教えてください」

【つまずきポイント】

フォルダ名に日本語、スペース、特殊文字を入れない。後でターミナルで操作する時にエスケープが面倒になります。cafe-site のような英数字＋ハイフンが鉄板
デスクトップに作るのが見つけやすい。クラウド同期のフォルダ（iCloud、OneDrive など）に作ると、同期で問題が起きることがあります
「フォルダの中に既にファイルがあるかどうか」で Code の挙動が変わる。空フォルダなら新規開発モード、既存ファイルがあれば「現状把握」から始まる

【確認問題】

新規プロジェクトを始める時の、フォルダ指定の典型的なパターンは何ですか？
フォルダ名にスペースを入れない方がいい理由は何ですか？

【次のレッスンへの橋渡し】

フォルダが決まりました。儀式の2つ目「モード選択」に進みましょう。

5-3. モードを選ぶ — 自動モードと Plan モードの使い分け

【学習目標】

作業内容に応じて自動 / Plan モードを使い分けられる
迷ったら Plan モードを選ぶ判断ができる

【前提知識】

4-6 でモードの存在を知っていること
5-2 でフォルダ指定ができたこと

【概念解説】

フォルダを指定したら、次に「このセッションは、自動モードでいくか、Plan モードでいくか」を決めます。

第4章で概要は説明しましたが、ここでは「いつ、どっちにすべきか」を実用ベースで整理します。

自動モードを選ぶ場面

ファイル1つだけの小さな修正
すでに何度もやっている作業
結果が想像できる、シンプルな依頼
例：「色を青に変えて」「フォントサイズを大きくして」

Plan モードを選ぶ場面

新しい機能を追加する時
複数のファイルが関わる作業
結果が想像できない依頼
公開・デプロイなど、後戻りしにくい作業
例：「ログイン機能を追加して」「データベースに接続して」「Vercel にデプロイして」

実用上の判断ルール

迷ったら Plan モード。これだけ覚えておけば事故が減ります。

なぜなら、Plan モードは「先に見せてくれる」だけで、決して時間を無駄にしているわけではないからです。むしろ、間違った方向に進んでしまった時の手戻りを考えると、Plan モードの方がトータルで早いんです。

僕の使い分け

僕の実体験では、

新規プロジェクトの最初の数十回は Plan モード
慣れてきて、何が起きるか予測できるようになったら自動モード
「ログイン追加」「決済組み込み」「デプロイ」など重い作業は、何回目でも Plan モード

これくらいの感覚です。完璧に振り分けようとしなくていいですが、**「重い作業は Plan モード」**だけは徹底すると安心です。

【ハンズオン手順】

▼ Code 側でやること

フォルダ指定の直後、入力欄の近くにモード切り替えのトグルかボタンがある（バージョンによって場所が違います）
「Plan モード」に切り替える
「自動モード」と「Plan モード」のアイコンや表示の違いを目で確認する

▼ Code 側でやること（Plan モードで依頼してみる）

Plan モードで「カフェ紹介ページを作って」と打ってみる
第1章で自動モードでやった時と違って、Code がまず計画書を提示してくるはずです
「こういう手順で作ります。よろしいですか？」と聞かれる
「OK」と返すと、初めて実際の作業が始まる

▼ スクショ伴走のチェックポイント

Plan モードで Code が提示した「計画書」のスクショを撮っておくと、「Plan モードはこういうものか」が体感できます

▼ 困ったら聞く例

ブラウザに →「Code でモードを切り替えるトグルがどこにあるか分かりません。最新のUIで教えてください」
Code に →「Plan モードで進めたい依頼があります。【依頼内容】まず計画を立ててください」

【つまずきポイント】

モードの切り替えは、依頼を出す前にやる。依頼を打ち始めてからモードを変えると、混乱することがあります
Plan を出してもらった後、内容を確認せずに「OK」を返してしまわない。Plan の意味がなくなります
Plan に不満があれば、その場で「ここはこう変えて」と修正できる。一度で完璧な Plan を期待しなくて大丈夫

【確認問題】

「ログイン機能を追加する」作業は、どちらのモードで進めるべきですか？
Plan モードで提示された計画書に不満がある時、どうしますか？

【次のレッスンへの橋渡し】

儀式が完了しました。フォルダを指定して、モードを選ぶ。たった2ステップで、作業の安全性がグッと上がります。

ここからは第2部、「スクショ伴走モデル」に入っていきます。儀式を済ませて作業を始めた後、Code とどうコミュニケーションを取っていくか、です。

5-4. 「脳と手」モデル：Code が設計・実行、ブラウザが並走相談

【学習目標】

Code とブラウザの役割を「脳と手」モデルで整理できる
自分が何を依頼すべきか、どっちに依頼すべきかを判断できる

【前提知識】

4-7 で2つの Claude の併用を知っていること

【概念解説】

第5章の第2部、「スクショ伴走モデル」を学ぶ前に、もう一度 Code とブラウザの役割を「脳と手」モデルで整理しておきます。

これは僕が3週間の実践で言語化したモデルです。

「脳と手」モデルの骨格

[Code]            [ブラウザ]
設計・実行  ←→  並走相談
（手）           （脳の補助）

Code = 手：実際にファイルを作ったり、コマンドを実行したり、コードを書き換えたりする実行者
ブラウザ= 脳の補助：実行している作業を俯瞰して、「これで合ってる？」「もっといい方法ない？」を相談する相手

「脳の本体」は誰かというと、実は僕自身なんですよ。Code もブラウザも、僕の脳を補佐する役割。僕が「何を作りたいか」を決めて、Code に実行させ、ブラウザに相談する、という構図です。

この構図がなぜ重要か

「Code に全部任せる」と考えると、上手くいかなくなるんです。Code はすごく優秀ですが、僕が何を作りたいか、本当のところは僕しか知らないから。

だから、Code に任せる時も：

任せる範囲を決めるのは自分
任せた結果が意図通りかをチェックするのも自分
ダメ出しと軌道修正をするのも自分

これが「自分の脳が主役」モデルの意味です。

ブラウザの役割の本質

ブラウザは「相談相手」ですが、もう少し正確に言うと、

自分が困った時の「壁打ち相手」
Code が今やっている作業を俯瞰する「セカンドオピニオン」
概念や用語を整理する「個人教師」

これらを担っています。

【ハンズオン手順】

▼ 実際に「脳と手」モデルを試してみる

Code を起動して、適当な作業フォルダを指定
何か簡単な依頼を出す（例：「シンプルな ToDo リストアプリを作って」）
Code が作業を始める
Code が作業している間に、ブラウザを開く

▼ ブラウザ側でやること（並走相談）

ブラウザに次のように打つ

今、Code に「シンプルな ToDo リストアプリ」を作ってもらっています。
このアプリに、次に追加すべき機能を3つ提案してください。
完了した項目を削除する以外で。

ブラウザが提案を返してくれる（チェックボックス、優先度、期限など）
Code の作業完了後、ブラウザの提案を見ながら次の依頼を考える

▼ スクショ伴走のチェックポイント

Code の作業画面と、ブラウザの相談画面を並べて撮ったスクショを残しておくと、「自分の作業環境の標準形」が見えます

【つまずきポイント】

ブラウザに Code のプロジェクトファイルが見えないことを忘れない。ブラウザに具体的な質問する時は、必要な情報（ファイルの内容など）を自分でコピペする必要があります
「脳と手」モデルは、自分が思考停止しないためのもの。Code に任せきりにせず、必ず自分で「これでいいか」を判断する

【確認問題】

「脳と手」モデルで、Code はどっちですか？ブラウザはどっちですか？
「脳の本体」は誰ですか？

【次のレッスンへの橋渡し】

役割分担が見えました。次は、いよいよ「スクショ伴走モデル」の基本リズムを身につけていきます。

5-5. スクショ伴走モデルの基本リズム — 1工程ごとに確認する

【学習目標】

スクショ伴走モデルの6ステップを暗記レベルで把握する
「1工程＝1往復」の感覚を身につける

【前提知識】

5-4 で「脳と手」モデルを理解したこと

【概念解説】

僕が3週間で複数アプリを作れた最大の理由が、この「スクショ伴走モデル」と名付けた作業リズムです。

簡単に言うと、1コマンドごと・1工程ごとに、スクショで Code に確認しながら進むやり方。

基本リズムの6ステップ

1. Code に「こうしたい」と相談する
2. Code が手順・コマンド・質問を返してくる
3. ターミナルまたは外部サービス画面で、指示通りに操作する
4. 実行結果のスクショを Code に貼る
5. Code が次の一手・軌道修正・解説を返す
6. 2に戻る

これを延々と繰り返すだけ。たったこれだけ。

「コピペ＋スクショ」のループ

このリズムの本質は、

コピペ：Code が出すコマンドや指示を、こちらの環境で実行する
スクショ：実行結果や画面の様子を、Code に返す

これを「1工程＝1往復」のサイクルで回す、ということです。

なぜこれが効くのか

理由は3つ。

1. Code が作業の全体像を把握し続けられる

スクショで毎回状況を共有することで、Code は「今どこまで進んだか」「何が起きているか」を正確に把握できます。これは Code が次の指示を出す時の精度を、劇的に上げます。

2. 自分が迷子にならない

「次に何をすればいいか」を毎回 Code が教えてくれるので、自分は「これでいい？」「次は？」と聞くだけ。考える負担が激減します。

3. 失敗した時の手戻りが小さい

1工程ごとに確認しているので、間違いがあれば即座に分かる。「気づいたら大事故になってた」が防げます。

僕のリズム感

正直、「ビクビクしながら進める」のがコツです。

これでいいのかな → スクショ送る
これで合ってる？ → スクショ送る
ちゃんと動いた → スクショ送る

「自分が確信を持てない」ことを正直に出していい、ということ。プロは確信を持って進めるべき、というのは誤解で、初心者ほどビクビク確認した方が結果的に早く、安全に進めます。

【ハンズオン手順】

▼ Code 側でやること（スクショ伴走の練習）

Code に「カフェ紹介ページに、お問い合わせフォームを追加して」と依頼
Code が手順を提示してくる
最初の1ステップだけ実行する
その結果（成功でも失敗でも）をスクショで Code に貼る
Code が次の指示を出してくる
次の1ステップを実行
またスクショで報告
これを繰り返してフォームが完成するまで進める

▼ スクショ伴走のチェックポイント

各ステップでスクショを撮っているか
そのスクショを毎回 Code に貼っているか
Code が「次は何をすべきか」を毎回明確に教えてくれているか

【つまずきポイント】

「いちいちスクショ撮るのめんどくさい」と感じるかもしれませんが、慣れると数秒の作業になります。むしろこれをサボると、後で「あの時何やったっけ」が増えます
スクショを撮る範囲は「画面全体」でOK。エラー部分だけクロップしようとして時間を使うより、全体を貼る方が安全
同じところでつまずいたら、Code に「これ何回も同じところで詰まってます」と伝えると、別のアプローチを提案してくれます

【確認問題】

スクショ伴走モデルの基本リズムは、何ステップですか？
このリズムが「1工程＝○往復」と呼ばれる理由は？

【次のレッスンへの橋渡し】

基本リズムができました。ここからは、僕の実体験から抽出した「6つの伴走パターン」を1つずつ見ていきます。

5-6. パターン①②：「変更後のイメージ」提示型と「〜だよね？」確認型

【学習目標】

Code が提示する「変更後のイメージ」型の指示を正しく受け取れる
自分が「〜だよね？」と確認する口癖を身につける

【前提知識】

5-5 で基本リズムを理解したこと

【概念解説】

僕が実際の作業中によく遭遇した伴走パターンを6つに整理しました。今回はその1つ目と2つ目です。

パターン① 「変更後のイメージ」提示型

これは Code（またはブラウザ）が、設定画面の操作などを指示する時に使うパターンです。

たとえば Supabase の設定画面で、「どのチェックボックスを ON にするか、どれを OFF にするか」を伝える時、Code はこう返してきます：

変更後のイメージ:
☑ Enable Data API              ← そのままON
☐ Automatically expose new tables ← チェックを外す
☑ Enable automatic RLS         ← チェックを入れる

「変更後の状態をイメージで提示してくれる」、これがパターン①。

自分はこのイメージを見ながら、画面上のチェックボックスを実際に同じ状態にする。終わったら、設定画面のスクショを Code に返す。Code が「合ってます！」または「ここがまだ違います」と返す。

パターン② 「〜だよね？」確認型

こちらは僕が自分から発するパターンです。

こうなったら完了してるってことよね？
で、ここから左のSQLのとこに進めばいいんだよね？

自分の理解を「これで合ってる？」「次はこれでいい？」と確認する、口癖のような問いかけ。これがめちゃくちゃ大事なんですよ。

なぜ大事かというと、

自分の理解の誤りを、その場で訂正してもらえる
次に進む前に「方向性 OK」を取れる
Code 側も、自分がどこまで分かっているかを把握しやすい

「こんな初歩的なこと聞いてもいいのかな」と思う必要は一切ないです。むしろ、聞いた方が早い。

2つのパターンが組み合わさると

実際の作業では、こんな感じで使われます：

Code 「変更後のイメージはこちらです」（パターン①）
自分「これで合ってる？」（パターン②）
Code 「合ってます」
自分「次は SQL のとこ進めばいい？」（パターン②）
Code 「はい、左サイドバーの SQL Editor をクリックしてください」

このやり取りが、スクショ伴走モデルの基本的な姿です。

【ハンズオン手順】

▼ Code 側でやること（パターン①②を実践）

何か設定が必要そうな依頼を Code に出す（例：「Google アナリティクスをサイトに導入したい」）
Code が手順を提示する
各ステップで自分が画面操作する前に「これで合ってるんだよね？」と確認する
Code が「合ってます」または「もう少し補足すると…」と返す
操作完了後、画面のスクショを Code に渡す
Code が次のステップを「変更後のイメージ」付きで提示

▼ スクショ伴走のチェックポイント

各ステップで「〜だよね？」と確認している自分のテキストを見直す
Code が「変更後のイメージ」を提示している場合、それと実際の操作後の画面を見比べる

【つまずきポイント】

「変更後のイメージ」を見ずに、自分の判断でチェックボックスを ON / OFF にしない。Code の指示に従うのが安全
「〜だよね？」を聞きすぎると申し訳ないと感じるかもしれませんが、Code は何度聞かれても嫌がりません。気にせず聞きましょう

【確認問題】

「変更後のイメージ」提示型は、どんな時に Code が使うパターンですか？
「〜だよね？」確認型を使うメリットを2つ挙げてください

【次のレッスンへの橋渡し】

確認型のやり取りができるようになりました。次は、Code が自分の意図を正しく汲み取って軌道修正してくれるパターンを見ます。

5-7. パターン③：Code からの軌道修正を受け止める

【学習目標】

Code が能動的に軌道修正を提案してくれることを知る
その提案を素直に受け入れる心構えを持つ

【前提知識】

5-6 まで読んでいること

【概念解説】

パターン③は、僕が「最初は驚いた」というやつ。

自分が「次はこれでいい？」と確認した時に、Code が「いや、それは違います」と能動的に訂正してくれるパターンです。

実例

僕が Netlify の設定画面を見ながら、こう聞きました：

ここはSkipでいいよね？

Code の返答がこれ：

スキップしないでください！このページがまさにデプロイ画面です🎉

下の「Upload your project files」のエリアが見えていますよね？
Finder で /Users/yuzosaito/App Demo/訪看訪問時間管理/ フォルダを、
この点線の枠の中にドラッグ＆ドロップしてください！

僕は「Skip でいい」と思っていた。Code は「Skip しないで！」と言った。これが軌道修正パターンです。

なぜこれが起きるのか

僕はその画面の意味を誤解していました。「Skip」と書かれていたから、進めていい画面に見えた。でも実はそれが「本番の作業画面」だった。

Code は、僕の「次はこれでいい？」という確認に対して、画面の文脈と作業の文脈を踏まえて「いや違う」と判断できた。これがすごく大事です。

自分の取るべき態度

軌道修正を受けた時に、「あ、すみません、Skip しちゃおうとしてました」と素直に止まる。これだけ。

たまに「いやでも Skip って書いてあるし」と反論したくなりますが、まず Code の言う通りに止まる。それから「なぜ Skip じゃダメなのか」を聞く。すると Code が丁寧に説明してくれます。

軌道修正を素直に受け入れることが、結果的に最短ルートで進む方法です。

「軌道修正されるのは恥ずかしい」は誤解

これも大事な感覚。軌道修正を受けると、「自分の理解が足りなかった」と感じて凹みやすい。でも考えてみてください。Code が軌道修正してくれたから、間違った方向に進むのを止められたわけです。むしろ感謝すべきこと。

僕は「Code が軌道修正してくれる時こそ、伴走している実感が湧く」と言っています。

【ハンズオン手順】

▼ Code 側でやること（軌道修正を意識的に体験する）

何かの作業中、選択肢が複数ある画面に出くわす
自分の直感で「これでいいよね？」と Code に聞く
Code が「合ってます」または「いや違います、こちらです」と返す
軌道修正された場合、まず止まって、なぜそうなのかを聞く

▼ スクショ伴走のチェックポイント

軌道修正のやり取り（自分の質問と、Code の訂正）が記録されているか
自分が「素直に止まれた」かどうか

【つまずきポイント】

「自分の判断が間違ってた」と凹まない。間違いを発見できた時点で、もう価値が生まれています
軌道修正の理由が分からなければ、聞く。「なぜ Skip じゃダメなんですか？」と聞けば説明してくれます
Code が軌道修正しない場合は、それでOK。すべての場面で軌道修正があるわけではない

【確認問題】

Code からの軌道修正を受けた時の、最初の行動は何ですか？
軌道修正を「感謝すべきこと」と捉えるべき理由は？

【次のレッスンへの橋渡し】

軌道修正を受け入れる心構えができました。次は、想定外のポップアップや警告が出た時の対処法です。これも初心者が一番驚くポイント。

5-8. パターン④：想定外のポップアップ・警告は「正常な現象」として扱う

【学習目標】

想定外の表示が出ても慌てない心構えを持つ
スクショで Code に聞く動作を反射的にできる

【前提知識】

5-7 まで読んでいること

【概念解説】

作業を進めていると、必ず「え、これ何？聞いてない」という画面が出てきます。

知らない警告ポップアップ
「This will delete...」みたいな英語の警告
「DROP TRIGGER IF EXISTS」のような赤字メッセージ
クレジット切れ通知（無料枠オーバー）

これらは全部、**「正常な現象」**として扱うのがコツです。

「正常な現象」とは

ここで言う「正常」は、「想定された範囲内の現象」という意味。

たとえば SQL の警告で「DROP TRIGGER IF EXISTS」が表示されたとします。これ、初心者は「破壊的な操作？やばい？」と感じます。

でも Code に聞くと、

この警告は SQL の中に DROP TRIGGER IF EXISTS という行があるためです。
既存のトリガーを削除してから再作成する処理で、意図的なものです。
新規プロジェクトなので何も失われるものはありません。

そのまま進めてください！

つまり意図された動作だった。これは「異常」ではなく「正常」。

「想定外」を「想定内」に変換する

僕が体得したコツは、

想定外の表示が出る
↓
慌てる前にスクショを撮る
↓
Code に貼って「これは何ですか？」と聞く
↓
Code が「正常な現象です」または「対処が必要です」と教えてくれる
↓
落ち着いて次に進む

このサイクルを回せば、すべての「想定外」が「想定内」になります。

具体例：クレジット切れ

Netlify などのホスティングを使っていると、ある日突然デプロイができなくなることがあります。「Skipped due to account credit usage exceeded」のような英語メッセージ。

これも Code に貼って聞けば、

何が起きているか（無料クレジットを使い切った）
対応策（有料プランにするか、別のホスティングに移行するか）
具体的な移行手順（Cloudflare Pages への引っ越しの仕方）

を全部教えてくれます。これは第10章のテーマでもあります。

僕からのメッセージ

僕自身、最初のうちは「想定外」が出るたびにビクビクしていました。でも、毎回 Code に聞いて、「あ、なるほど」を繰り返していたら、いつの間にか「想定外って、特別なことじゃないんだ」と感覚が変わってきた、と感じています。

【ハンズオン手順】

▼ Code 側でやること（想定外を呼び出す練習）

何かの作業中に出てきた、見たことない警告やポップアップを探す
その画面のスクショを撮る
Code に貼って次のように打つ

こんな表示が出てきましたが、これは何ですか？
そのまま進めて大丈夫ですか？

Code が解説してくれる
解説を踏まえて、次に進む or 対処する

▼ スクショ伴走のチェックポイント

想定外の表示に出会った瞬間、慌てる前にスクショを撮れたか
「これは何？」と聞く前に、勝手に閉じたり進めたりしなかったか

【つまずきポイント】

「分からないけど閉じちゃえ」が一番危ない。後で「あれ何だったんだろう」になっても、もう確認できません
英語のメッセージを頑張って読まない。Code に貼って日本語で説明してもらう方が早い
同じ警告が何度も出るなら、根本原因がある。「これ何度も出てます」と Code に伝えれば、原因を一緒に探してくれます

【確認問題】

想定外の表示が出た時の、最初の行動は何ですか？
「想定外」を「想定内」に変える鍵となる行動は何ですか？

【次のレッスンへの橋渡し】

想定外への対処ができるようになりました。次は、アプリを公開した後で起きるトラブルや、機能追加についてのパターンです。

5-9. パターン⑤：デプロイ後トラブル・機能追加も対話で進める

【学習目標】

アプリを公開した後で問題が起きても、対話で解消できることを知る
機能追加も「依頼 → 確認 → 実装」のサイクルで進められる

【前提知識】

5-8 まで読んでいること

【概念解説】

アプリを世に公開した後でも、トラブルや改善要望は必ず出てきます。

「実機（iPhone など）で見たら表示がおかしい」
「ログインしたら『2人目』扱いされて管理者になれない」
「もう少し機能を追加したい」

こういう時も、作業中と同じスクショ伴走モデルで乗り切れます。

実例：admin が2人目扱いになった話

僕が訪看アプリを作って、いざ自分でログインしてみたら、「承認待ち」と表示されて先に進めませんでした。

Code に状況を伝えると、こう返ってきました：

最初の登録でプロフィールレコードが既に作られていたため、
2回目の登録が「2人目」と認識されてしまいました。

Supabaseで直接ロールを管理者に変更します：

修正手順
1. Supabaseダッシュボードの「SQL Editor」を開く
2. 以下のSQLを貼り付けて「Run」：
   UPDATE profiles SET role = 'admin'
   WHERE id = (
     SELECT id FROM auth.users
     ORDER BY created_at DESC
     LIMIT 1
   );
3. Runが成功したら、アプリに戻って再度ログインしてください

今度はメイン画面が表示されるはずです！

つまり、

何が起きたかの説明
原因の特定
修正のための具体的な SQL コード
修正後の確認手順

これが一気に提示される。僕は「こんなことまで聞いて教えてもらえるんだ」と感動しました。

機能追加も同じ流れ

「メール通知機能を追加したい」みたいな大きな機能追加でも、

Code に「メール通知機能を追加したい」と依頼
Code が「3ステップで実現できます」と段取りを提示
ステップごとに「次は何？」と確認しながら進める
各ステップでスクショと結果を共有
完成

僕の訪看アプリの v2.4 では、Resend（メール送信サービス）+ Supabase Edge Function を組み合わせたメール通知機能を、こうやって追加しました。「初心者には絶対無理」と思える機能でも、スクショ伴走で組み立てられる。

「公開して終わり」じゃない

アプリを公開すると「やっと完成だ！」と思いがちですが、実際は公開してからが本番です。

ユーザー（自分自身も含む）が使い始めると、必ず細かい不具合が出る
「もっとこうしたい」という改善要望も出る
機能追加もしたくなる

こういう「公開後のループ」を、スクショ伴走モデルで回し続けられる。これが Code を使う本当のメリットなんですよ。

【ハンズオン手順】

▼ Code 側でやること（公開後の改善を体験する）

第1章で作ったストップウォッチまたはカフェ紹介ページに、何か改善を加えてみる
改善依頼を Code に出す（例：「ラップタイム機能を追加して」「FAQ セクションを追加して」）
Code が手順を提示してくる
ステップごとに進め、各ステップでスクショと結果を共有
完成

▼ スクショ伴走のチェックポイント

「これで完成」と思った後でも、改善のサイクルを回せたか
スクショ伴走モデルが、新規開発時と公開後で同じように使えることを確認

【つまずきポイント】

公開後のトラブルを「自分の責任で全部解決しないと」と思わない。Code に聞けば、たいてい解決します
データの修正は慎重に。SQL でデータベースを直接書き換える時は、本番環境では必ず Plan モードで進め、Code の指示通りにやる

【確認問題】

アプリを公開した後でも、スクショ伴走モデルは有効ですか？
「公開して終わり」と「公開してからが本番」のどちらが正しい感覚ですか？

【次のレッスンへの橋渡し】

公開後のサイクルまで見えました。次は、Code が長時間作業している時の「並行相談」のコツです。

5-10. パターン⑥：Code 作業中の並行相談 — ブラウザに切り替えて聞く

【学習目標】

Code が作業中の待ち時間を、ブラウザで有効活用できる
並行相談のリズムを身につける

【前提知識】

5-9 まで読んでいること
4-7 で2つの Claude の併用を理解していること

【概念解説】

Code が複雑な作業（複数ファイルを書き換える、ライブラリをインストールする、Plan を実行する、など）に取り掛かると、数分かかることがあります。

その間、Code には話しかけられません。応答が返ってきません。

ここで多くの初心者は「Code が固まった？」と不安になって、勝手に止めたり再起動したりしてしまいがち。やめてください。

代わりにやるべきは、ブラウザに切り替えて、その時間を有効活用することです。

並行相談の典型シーン

僕がよくやっていた並行相談の例：

[Code が15分かけてアプリ全体をリファクタリング中]
↓
僕はブラウザを開く
↓
ブラウザに「リファクタリング中に、自分は何を考えておくべき？」と聞く
↓
ブラウザが「変更後のテスト項目を整理しておくと良いです」と返す
↓
僕はテスト項目リストを作る
↓
Code の作業が完了
↓
できたアプリを、テスト項目リストに沿って確認

待ち時間が、有意義な準備時間に変わる。これが並行相談の威力です。

並行相談で聞くべきこと（典型例）

今やっている作業の一般的なベストプラクティス
次にやるべき機能の候補
用語や概念の整理
自分のスキル状況の振り返り
別の方法でやる場合の選択肢

逆に、並行相談で聞くべきでないこともあります。

今のプロジェクトの具体的なコードについて（ブラウザは見えていない）
Code が今やっている作業の進捗（ブラウザは知らない）
Code に依頼した結果（ブラウザに確認しても意味がない）

ブラウザに貼っていい情報、貼ってはいけない情報

並行相談する時、ブラウザには Code のセッション内容を共有できません。なので、

概念的な質問は自由にしてOK
具体的なコードや設定を貼って聞きたい時は、自分でコピペが必要
ただしパスワードや API キーは絶対に貼らない

これだけ守れば、並行相談はめちゃくちゃ便利な習慣になります。

【ハンズオン手順】

▼ 並行相談を実践してみる

Code に少し時間のかかる依頼を出す（例：「アプリ全体に統一感のあるデザインを適用して、複数ファイルを修正して」）
Code が作業を始める
すぐにブラウザのタブに移動

▼ ブラウザ側でやること（並行相談）

ブラウザに次のように打つ

Code に「アプリ全体のデザイン統一」を依頼しました。
作業中の待ち時間に、私が次に考えておくべきことを教えてください。
- 完成後のチェックポイント
- 追加で考慮すべき要素
- よくある落とし穴

ブラウザが答える
答えを参考に、次にやるべきことのリストを作る
Code の作業が完了したら、そのリストに沿って確認

▼ スクショ伴走のチェックポイント

Code が作業中の画面と、ブラウザで相談している画面、両方のスクショを並べてみる
「待ち時間に何もしない」状態がなくなったか確認

【つまずきポイント】

Code が作業中に Code 画面に戻る必要はない。完了したら通知が出る or 結果が表示される
ブラウザの回答を Code の作業に反映したい時は、自分でコピペが必要。「Code の作業にブラウザの回答を反映して」と言っても伝わりません
ブラウザに Code のスクショを貼るのもアリ。「今 Code がこういう作業をしています」と共有してアドバイスをもらう

【確認問題】

Code が作業中、自分が次にやるべき行動は何ですか？
並行相談で「ブラウザに貼ってはいけない情報」は何ですか？

【次のレッスンへの橋渡し】

並行相談が身につきました。第5章の最後に、もう1つ大事な判断ポイントを押さえます。「許可プロンプト」の判断基準です。

5-11. 許可プロンプトの判断基準 — 「常に許可」と「一度だけ許可」の使い分け

【学習目標】

Code が「許可してください」と聞いてくるパターンを理解する
「常に許可」と「一度だけ許可」を場面に応じて使い分けられる

【前提知識】

ここまでの章を読んでいること

【概念解説】

Code を使っていると、頻繁にこういうダイアログが出ます：

このコマンドの実行を許可しますか？
[ 一度だけ許可 ] [ 常に許可 ] [ 拒否 ]

これは「Code が何かのコマンドや操作をしようとしているけど、確認していい？」という確認。

僕が最初にハマったポイント

僕は最初、「めんどくさいから全部『常に許可』を押してた」のですが。でも、これが後で「あれ、これ承認していいやつだっけ？」と振り返れない事態を生みました。

逆に「全部『一度だけ許可』」だと、毎回ダイアログが出てうんざりする。これも辛い。

判断基準のフレームワーク

「常に許可」と「一度だけ許可」の使い分けは、こう考えてください。

「常に許可」を選ぶ場面

何度も出てくる、安全なコマンド
例：ls（ファイル一覧）、git status（git の状態確認）、ファイル読み込み
取り返しがつく操作
自分が完全に理解している操作

「一度だけ許可」を選ぶ場面

初めて見るコマンド
データを変更する操作（特にデータベース、ファイル削除）
取り返しがつかない操作
「これ何だろう？」と少しでも思ったら

「拒否」を選ぶ場面

明らかにおかしい操作
想定外のフォルダにアクセスしようとしている
Code に「これ拒否するべき？」と聞いてもいい

実用上のコツ

僕なりのコツ：

困ったら「一度だけ許可」。次に同じものが出てきた時、「常に許可」に格上げするか判断すればいい
「常に許可」を押した後で不安になったら、Code に「この操作は安全ですか？」と聞ける
削除系の操作は、ほぼ常に「一度だけ許可」。rm -rf のような操作は、たとえ正しくても1回1回確認したい

「拒否」を恐れない

「拒否」を押すと作業が止まりますが、それでいいんです。自分が納得していない操作を、強行する必要はない。

僕は「自分の感覚で『うっ、これは止めたい』と思ったら、迷わず拒否を押す」と言っています。後で Code に「なぜさっき拒否しちゃったか」を説明すれば、代替案を出してくれます。

【ハンズオン手順】

▼ Code 側でやること（許可プロンプトを意識する）

何か作業を Code に依頼する
許可プロンプトが出るたびに、自分で判断してみる
各プロンプトで「常に許可」「一度だけ許可」「拒否」のどれを選んだか、理由とともにメモする

▼ ブラウザ側でやること（判断に迷ったら）

許可プロンプトの内容を見て、判断に迷ったらブラウザに聞く
たとえば

Code が「rm -rf node_modules を実行していいですか？」と
聞いてきました。これは安全ですか？「常に許可」と「一度だけ許可」、
どちらが良いですか？

ブラウザの答えを参考に、判断する

▼ スクショ伴走のチェックポイント

許可プロンプトのスクショと、自分の判断結果をセットで記録
後で振り返って「あの時の判断は正しかったか」を確認

【つまずきポイント】

「全部常に許可」は楽だが、リスクがある。後で「あれ、何を許可したっけ？」になります
「全部一度だけ許可」は安全だが、効率が悪い。バランスを取りましょう
判断に迷ったら、まず止める。スピードより安全優先

【確認問題】

削除系のコマンド（rm -rf など）に対する許可プロンプトは、原則どちらを選ぶべきですか？
自分が納得していない操作の許可プロンプトには、どう対応すべきですか？

【次のレッスンへの橋渡し】

第5章はこれで完了です。長かったですが、ここで身につけた11レッスンは、これから先のすべての作業の基礎になります。

作業開始の儀式（5-1〜5-3）
スクショ伴走モデルの基本（5-4〜5-5）
6つの伴走パターン（5-6〜5-10）
許可プロンプトの判断（5-11）

これらが体に染み込めば、Code を「ちゃんと使える」状態です。

次は第6章。Code がより賢く動くための「メモリの仕組み」と「習慣化すべき2つのファイル」を学んでいきます。

第5章 作業開始の儀式とスクショ伴走モデル（コア章）

5-1. なぜ「作業開始の儀式」が必要か — 知らずに始める恐怖

5-2. フォルダを指定する — どこで作業するかを最初に決める

5-3. モードを選ぶ — 自動モードと Plan モードの使い分け

5-4. 「脳と手」モデル：Code が設計・実行、ブラウザが並走相談

5-5. スクショ伴走モデルの基本リズム — 1工程ごとに確認する

5-6. パターン①②：「変更後のイメージ」提示型と「〜だよね？」確認型

5-7. パターン③：Code からの軌道修正を受け止める

5-8. パターン④：想定外のポップアップ・警告は「正常な現象」として扱う

5-9. パターン⑤：デプロイ後トラブル・機能追加も対話で進める

5-10. パターン⑥：Code 作業中の並行相談 — ブラウザに切り替えて聞く

5-11. 許可プロンプトの判断基準 — 「常に許可」と「一度だけ許可」の使い分け

第5章作業開始の儀式とスクショ伴走モデル（コア章）