付録B セルフチェックの解答と解説

第1章

1-1. （イ）に完了の基準があります。通知をオフにした翌日にメールが届くか、再読み込み後も状態が残るかを、誰でも確認できるからです。（ア）の「使いやすく」には確認方法がありません。例えば「通知の種類ごとにオン・オフのスイッチがあり、変更すると保存ボタンなしですぐ反映され、再読み込みしても維持される」のように、観察できる結果に変えます。

1-2. 空の状態（予約履歴がなければ、案内文と予約に進むボタンが表示される）、読み込み中（読み込み表示が出て、ボタンは押せない）、失敗（再試行ボタン付きのエラー案内が表示される）、権限なし（ログイン画面へ移り、ログイン後に履歴画面に戻る）です。各状態に観察できる結果が書かれていれば正解です。

1-3. 例：①お客さまが問い合わせフォームを送信すると「受け付けました」と表示され、管理者の一覧に1件追加される。②管理者が問い合わせを開いて「確認済み」に変えると、一覧の表示が変わる。③受け付けると、お客さまに案内メールが1通届く（テストでは送信記録で確認）。作業ごとにユーザーが使える成果があれば十分です。テーブル、API、画面の順で分けたなら層ごとの分割なので、分け直します。

1-4. Ctrl+Gで計画をテキストエディターに開き、自分で直接修正してから進めます。計画なしですぐに任せてもよいのは、デバッグ用のログを1行追加する場合のように、diffを一文で要約できる作業です。

1-5. ③はどの要件とも対応づけられず、アプリ全体に手を入れる、範囲外の整理作業です（問い1・2・5）。また、検証の段階がありません（問い4）。「第3段階は外してください。第4段階の前に、申し込みの保存を確認するテストの追加とnpm testの実行、画面キャプチャの段階を入れてください」のように、段階の番号と理由を添えて返します。

1-6. Claude Codeは、作業フォルダやその上のフォルダにCLAUDE.md、.claude/CLAUDE.md、CLAUDE.local.mdのうち1つでもあると、既定ではAGENTS.mdの代わりにそちらを読みます。CLAUDE.local.mdもこの対象に含まれるため、そのメンバーのセッションでチームのルールが抜けました。ルートに@AGENTS.mdを取り込むCLAUDE.mdを置くか、そのメンバーが個人設定を、両方のファイルを読む値（claude-md-and-agents-md）に変更します。

1-7. Codexは~/.codex/config.tomlのproject_doc_fallback_filenamesにTEAM_GUIDE.mdを入れます。各フォルダでAGENTS.override.md、AGENTS.mdの次にこの名前を探します。Gemini CLIはsettings.jsonのcontext.fileNameにTEAM_GUIDE.mdを入れます（名前1つ、または一覧）。

第2章

2-1. 5173番ポートをすでに別のプロセスが使っています。以前起動した開発サーバーが残っていることがよくあります。lsof -i :5173でPIDを確認し、kill <PID>でそのプロセスだけを止めるか、別のポートで起動します。名前のパターンでまとめて止める方法は、無関係なプログラムまで止める場合があるため避けます。依存関係の再インストールは通常役に立ちません。

2-2. 実行されたテストが1つもないので、何も確認していません。「失敗なし」と「検証済み」は違います。テストファイルの場所や命名規則、テスト設定の破損、フィルターによって選択されたテストがない可能性をまず疑い、実行されたテスト数を確認します。

2-3. コンソールではクリック時のJavaScriptエラーを、ネットワークタブでは要求が送られたかと、そのステータスコードを見ます。コンソールにエラーがあるか要求自体がなければ画面のコード、400番台なら送った内容や権限、500番台ならサーバー側の問題なので、サーバーの出力とログを見ます。

2-4. src/checkout/summary.tsの47行目です。スタックトレースで自分のコードの最も上にある行が実際の発生箇所で、OrderPanelはその関数の呼び出し元、node_modulesはライブラリです。nullの対象からpriceを読んだので、注文項目がnullになる場合を調べます。

2-5. 終了コードを確認します。直後のecho $?が0なら成功です。警告は失敗ではなく、エラー文言がないから成功とも限りません。CIも終了コードで成否を判断します。

2-6. 修正コードを一時的に戻すか、再びバグを入れて、そのテストを実行し失敗するかを見ます。失敗すればバグを検出し、通ればそのバグと関係のないテストです。確認後はコードを修正状態に戻します。

2-7. Linuxはファイル名の大文字小文字を区別し、macOSの既定のAPFS形式は区別しません。Macでは./components/headerでHeader.tsxを見つけても、Linuxでは見つかりません。importパスを実名どおり./components/Headerに直します。

第3章

3-1. git diffは、ワーキングツリーとステージングエリアを比較して、まだステージングしていない変更を表示します。git diff --stagedは、ステージングエリアと最後のコミットを比較して、次のコミットに入る変更を表示します。git diff HEADは、ワーキングツリーと最後のコミットを比較します。両方を一度に見るには、git diff HEADを使います。追跡していない新しいファイルは、どれにも表示されません。

3-2. 新しいファイルはGitがまだ追跡していないため、git diffには出ません。git statusで??と表示されるかを確認し、git addでステージングしてからgit diff --stagedで内容を見ます。

3-3. git diff -wで空白の違いを無視すると、本来の変更だけが残ります。コミットは、機能の変更と書式の変更に分けます。git add -pで機能のハンクだけを選び、先にコミットし、書式の変更は別にコミットするか、元に戻します。

3-4. -mで、基準となる親の番号（通常はmain側の1）を指定します。マージコミットは親が2つ以上あるため、どちらを基準に取り消すのかを伝える必要があるからです。Gitのドキュメントは、マージを取り消すと、そのマージで入った変更を今後も望まないという宣言になり、後で同じブランチを再びマージしても、すでに入っていたコミットの変更は再び取り込まれないと警告しています。

3-5. git stash applyです。applyは変更を適用してもstashの一覧に残しておくため、他のブランチにも再び適用できます。popは、適用に成功すると一覧から削除します。使い終えたら、git stash dropで整理します。

3-6. git reset --keep HEAD~2です。コミットを捨てながら未コミットの修正は残します。現在のHEADと目標地点で内容が異なるファイルに未コミットの修正があれば、上書きせずresetを中止します。

3-7. 125です。Gitによると、終了コード125は現在のコミットをテストできないことを意味し、そのコミットをスキップします。0は正常、125を除く1〜127は異常、それ以外の値はbisectを中止します。

第4章

4-1. 実行されません。Claude Codeは、deny → ask → allowの順番でルールを評価し、最初に一致したルールが結果を決めます。一致するdenyルールがあれば、より広いallowルールがあっても阻止され、allowでdenyの例外を作ることはできません。

4-2. いいえ。公式ドキュメントは、.claudeignoreには何の効果もないと明記し、その内容をRead(./secrets/**)などのReadのdenyルールに移すよう案内しています。シェルで動く他のプログラムまで阻止する必要があれば、サンドボックスの読み取り禁止も併用します。

4-3. NEXT_PUBLIC_の値はnext build時にブラウザのコードへ埋め込まれ、固定されます。またVercelの変数変更は、新しいデプロイだけに反映されます。新しい値を見るには再ビルドし、新たにデプロイします。

4-4. 正しくありません。Claude Codeのサンドボックスは、既定では、書き込みを作業フォルダと一時フォルダに、ネットワークを許可リストに制限します。しかし、読み取りは、~/.sshやクラウドの認証情報ファイルを含め、コンピューターの大半で許可されています。機密情報のあるパスは、サンドボックスの読み取り禁止で保護し、エージェントのファイルツールからの読み取りは、Readのdenyルールで阻止します。

4-5. ユーザー単位のプッシュ保護は既定で有効で、公開リポジトリへのプッシュにシークレットがあれば阻止します。リポジトリ単位は既定で無効なので管理者が有効にし、GitHub Secret Protectionが必要です。

4-6. 絞りません。npmのドキュメントによると、--audit-levelは報告を絞るのではなく、どの深刻度以上の脆弱性があればコマンドを0以外の終了コードで終えるかの基準です。high以上があれば、CIが失敗します。

4-7. 例：（ア）タイプミスの修正では、作業フォルダ内の文書の編集だけを許可し、作業フォルダの外へのアクセスとネットワークは阻止します。編集の自動承認は認めて構いません。（イ）調査は読み取り専用（plan modeやread-only）で行い、ネットワークはパッケージレジストリと公式ドキュメントだけを許可し、インストールは禁止します。（ウ）バグの修正では、作業フォルダへの書き込みとテストコマンドを許可し、作業フォルダの外へのアクセスと不要なネットワークは阻止します。依存関係の追加とプッシュは、人が承認します。作業ごとに必要な最小限だけを許可し、理由を説明できれば正解です。

第5章

5-1. 本番です。Vercelは、新しいプロジェクトの最初のデプロイを、どのブランチで行っても、--prodがなくても、必ず本番デプロイとして作ります。その後は、本番ブランチのコミットやvercel --prodが本番デプロイを作り、他のブランチとPR、--prodなしのvercelがプレビューデプロイを作ります。

5-2. ブランチURLです。そのブランチの最新のデプロイを指し続けます。コミットURLは、特定のコミットのデプロイに固定されるため、2つの時点を比較したり、「このバージョンで問題が起きた」と記録したりするときに使います。

5-3. 適用されません。ロールバックしたデプロイは、その当時の設定で動き、環境変数の変更は新しいデプロイだけに反映されます。新しいデプロイを作って昇格させると、新しい値が反映され、ロールバックの状態も解除されます。

5-4. Hobbyプランは、直前のデプロイにだけ戻ることができます。ProとEnterpriseは、本番ドメインに接続されたことがあるデプロイなら、どれにでもロールバックできます。本番に接続されたことがないプレビューデプロイは、どのプランでも対象外です。

5-5. vercel logsは既定で最近30分の最新100件を示します。--since 3hなどで範囲を広げます。それでもなければ、プランの保存期間を過ぎているかもしれません。

5-6. Production環境のBranch Trackingで、Auto-assign Custom Production Domainsを無効にします。本番ブランチからデプロイすると、ドメインに接続されずに昇格を待つので、生成されたデプロイURLで確認してから昇格させます。昇格では再ビルドせず、ドメインの参照先だけが移ります。このデプロイは本番の環境変数を使うため、本番のデータにアクセスする点に注意します。

5-7. 例（フラワーアレンジメント教室の予約アプリ）：①テスト、型チェック、ビルドが通過している ②プレビューでレッスンの申し込みとキャンセルの流れを自分で確認している ③新しく使うSMS送信キーがProductionにある ④受講者テーブルの構造変更がない（ある場合は、以前のコードとの互換性を確認している） ⑤決済Webhookが本番のアドレスと本番のキーを指している ⑥直前の正常なデプロイとロールバックする方法を確認している。各行に実際の機能名があり、確認できたかどうかを真偽で判定できれば正解です。