Claude Code 初心者の毎日15分ルーティン: 朝に回す安全な作業手順

金曜の夜、僕はClaude Codeに「このプロジェクト、気になるところ全部直しといて」と投げて寝ました。

翌朝、変更されたファイルは23個。動くコードもありました。でも、どれが本当に直ったのか、何を確認すればいいのか、自分でもまったく説明できなかったんです。差分を上から下まで読むだけで1時間かかり、結局こわくて一行もコミットできませんでした。

賢いAIに大きく頼んだのに、前に進むどころか後退した。これ、初心者がいちばん最初にハマる落とし穴です。

原因はClaude Codeの性能ではありません。作業の「閉じ方」を決めていなかっただけ。今日は、僕が毎朝コーヒーを淹れる間にやっている15分の手順を、そのまま渡します。

この記事の要点

• 「全部直して」は事故のもと。毎日やるのは「一文で決めた小さい仕事ひとつ」だけにする。
• 編集を始める前に、終わったかどうかを判定する確認コマンドを先に決める。
• 作業後は「変わったファイル」「確認コマンドの結果」「次にやる一手」の3つだけ残せば十分。
• AIに任せるのは手を動かす部分。範囲を決める・公開ボタンを押すのは人間がやる。
• 下のスクリプトをコピペすれば、毎朝の確認を自動で並べられる。

なぜ「小さく閉じる」が初心者には効くのか

Claude Codeを触り始めた頃の僕は、毎回ゴールがふわっとしていました。「いい感じにして」「読みやすくして」。これだと、AIが何をどこまでやったのか、終わったあとも分からない。

人間の新人にも同じことが言えます。「この資料、適当によろしく」と頼まれた人は、たいてい困ります。「3ページ目の数字を最新版に差し替えて、表が崩れてないか見て」と言われた人は、すぐ動けて、終わったかどうかも自分で判断できる。

毎日のルーティンで大事なのは、賢い指示を一発で書くことではありません。小さく区切って、終わりを判定できる形にすること。これができると、初心者でも「今日はここまで進んだ」と毎日言えるようになります。

ちなみにこの考え方の土台は、別記事のClaude Code の始め方と権限管理の基本につながっています。先にそちらで環境を整えてから、この習慣を乗せると効きます。

15分でやることは、たった4ステップ

僕が毎朝やっているのは、次の4つだけです。順番も毎回同じにしています。順番を固定すると、考えなくても体が動くからです。

1. 今日の最小タスクを一文で書く。 「READMEの導入文を3行だけ書き直す」のように、終わりが見える粒度にする。大きい仕事は、わざと今日はやらない。
2. 確認コマンドを先に決める。 「npm run build が通ればOK」「テスト1件が緑になればOK」のように、編集を始める前にゴールの形を決めておく。
3. 作業して、差分・ビルド・公開URLの順で確かめる。 いきなり公開せず、機械でわかるところから順に見ていく。
4. 次回のために一行だけ残す。 「残ったリスク」と「次の最小タスク」をメモする。これが翌朝のスタートになる。

ポイントは2番です。先に確認コマンドを決めずに編集を始めると、「直った気がするけど確証がない」というあの金曜の夜に逆戻りします。ゴールテープを引いてから走る。これだけで毎日の作業がぐっと軽くなります。

AIに任せる範囲と、人間が決める範囲

初心者がいちばん混乱するのが、ここだと思います。何でもAIに丸投げしていいわけではないし、全部自分でやるなら使う意味もない。線引きの目安を表にしました。

場面	AIに任せる	人間が決める・押す
範囲決め	候補を出させる	今日やる一文を確定する
編集	コードや文章を書く	何を直すかの方針
確認	ビルドやテストの実行	どの確認をゴールにするか
公開	差分の要約を出す	公開ボタンを押す
危険操作	「やっていいか」を聞く	削除・本番反映の最終判断

迷ったときの基準はシンプルです。やり直しがきく作業はAIに、戻せない作業は人間に。 ファイルの編集はいくらでもやり直せるので任せる。本番への公開やファイルの削除は、最初は必ず自分の手で押す。慣れてきた操作だけ、あとから少しずつ自動に格上げします。許可の細かい設定はClaude Code 公式ドキュメントに一通りまとまっているので、線引きに迷ったら一度目を通しておくと安心です。

コピペで使える依頼文の雛形

毎回ゼロから依頼を書くと、粒度がブレます。僕はこの雛形をメモアプリに貼っておいて、毎朝穴埋めしています。

今日の最小タスク: （ここに一文。例: READMEの導入3行を書き直す）
触ってよい範囲: （例: README.md のみ。他のファイルは変更禁止）
完了の確認方法: （例: npm run build が成功すること）

進め方:
1. まず変更せず、現状を読んで要約してください。
2. 上の範囲だけを編集してください。範囲外は触らないでください。
3. 編集後、変更したファイル名と、確認方法の結果を報告してください。
4. 削除・本番反映・外部送信が必要なら、実行せず先に確認してください。

「範囲外は触らない」「危ない操作は先に確認」の2行を入れておくだけで、冒頭の23ファイル事故はほぼ起きなくなります。AIに自由を与えるのではなく、安全な箱を渡すイメージです。

コピペで動く確認スクリプト

毎朝の確認を、手で打つと忘れます。僕はこのスクリプトを morning-check.mjs として置いて、コーヒーを淹れる前に走らせています。Node.jsが入っていれば動きます。

// morning-check.mjs : 毎朝の確認を順番に並べて実行する
import { execSync } from "node:child_process";

// 確認したいコマンドを上から順に並べる。プロジェクトに合わせて書き換える。
const checks = [
  { label: "変更されたファイル", cmd: "git status --short" },
  { label: "ビルドが通るか", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // 結果をそのまま画面に出す。エラーなら下のcatchへ。
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(出力なし)");
  } catch (e) {
    allOk = false;
    console.log("失敗:", e.message.split("\n")[0]);
  }
}

console.log("\n--- 今日の締め ---");
console.log(allOk ? "確認OK。次の最小タスクを一行で残そう。" : "確認が止まった。直してから先へ。");

実行はこれだけです。

node morning-check.mjs

checks の中身を自分のプロジェクトに合わせて書き換えるのがコツです。テストがあるなら npm test を、静的サイトなら公開URLの確認を足す。毎朝同じコマンドが同じ順番で流れるだけで、確認漏れがほぼ消えます。僕はここに「最後にコミットせずに止まっていないか」のチェックも足しました。

こんな場面で効く（3つ）

例1: 初日はリポジトリの地図を作るだけ いきなりコードを直さなくていいです。「危ないディレクトリはどこか」「設定ファイルはどこにあるか」をAIに要約させて、それを読むだけで初日は成功。次の日からの作業がぐっと速くなります。

例2: 2日目はREADMEの一段落だけ 小さく成功体験を作ります。導入文を3行書き直して、npm run build で壊れていないか確認。これだけ。小さく終わらせて、ちゃんと確認まで通すと、「自分でも回せる」という感覚が手に入ります。

例3: 3日目は数字に結びつく小改善ひとつ 記事の見出しを直す、テストを1件足す、リンク切れを1本直す。成果が見える小さい改善を選びます。大事なのは、毎日ひとつ「確認まで通った変更」を積むことです。

失敗例と、その直し方

正直に書くと、僕はこの3つで何度も転びました。

落とし穴1: 一度で全部やろうとする。 「気になるところ全部」は、確認できない巨大な差分を生みます。直し方は単純で、今日の一文を「ひとつ」に絞ること。残りは明日のメモに回します。

落とし穴2: ローカルのビルドだけで完了にする。 npm run build が通っても、公開URLが正しく出ているとは限りません。僕は一度、ビルドは緑なのに公開ページが古いままで気づかなかったことがあります。直し方は、公開後に実際のURLを開いて、見出しと本文の冒頭が今回の変更になっているか目で見ること。

落とし穴3: 危険な承認を流れで押す。 確認ダイアログが出たとき、初心者は「とりあえずYes」を押しがちです。削除や本番反映の確認が来たら、一度手を止める。判断に迷うなら、その操作は今日はやらないのが正解です。権限の考え方は非エンジニア向けの解説も参考になります。

次回へ残すメモの形

最後に残すメモは短くていいです。ただ、翌朝の自分が同じ判断をやり直さないように、形だけ決めておきます。

- 今日やったこと: READMEの導入3行を書き直し
- 確認した方法: npm run build 成功 / 公開URLで見出し確認
- 残ったリスク: 画像のリンク切れが2本ある
- 明日の最小タスク: 画像リンクを1本だけ直す

このメモがあると、翌朝「何から始めるか」で悩む時間がゼロになります。僕はこれを始めてから、朝の立ち上がりが体感で5分は速くなりました。

よくある質問

Q. 毎日15分も取れません。もっと短くできますか。 できます。最初は「今日の最小タスクを一文書く」だけでもOKです。確認コマンドを決める習慣さえ付けば、作業時間は自然と短くなります。

Q. 確認コマンドが何か分かりません。 プロジェクトに npm run build や npm test があれば、まずそれで十分です。何もなければ「公開URLを開いて目で見る」が立派な確認です。最初は機械でわかるものをひとつ決めれば大丈夫。

Q. 全部AIに任せたほうが速いのでは。 短期的にはそう見えます。でも「何が直ったか説明できない変更」は、結局あとで全部読み直すことになります。小さく閉じたほうが、トータルでは速いというのが僕の実感です。

Q. 初心者がいちばん最初にやるべきことは。 リポジトリの地図を作ることです。コードを直す前に、どこに何があるかをAIに要約させて読む。これが安全に進む土台になります。

Q. このルーティンはチーム導入でも使えますか。 使えます。ただしチームでは「誰が公開を承認するか」「どの確認をゴールにするか」を先に文書化しておくと、個人の習慣がそのままチームのルールになります。

実際に試した結果

あの金曜の夜以来、僕は「AIにどこまで任せるか」で悩むのをやめました。代わりに毎朝決めているのは、今日の一文と、確認コマンドのふたつだけです。

morning-check.mjs を2週間回してみて、いちばん変わったのは確認漏れです。以前はビルドを通したつもりでコミットして、あとで壊れていたことが何度かありました。確認を同じ順番で機械に流すようにしてから、それがゼロになりました。

そして、毎晩残す4行メモ。これを始めてから、翌朝の「何やるんだっけ」が消えました。賢い使い方を探すより、小さく閉じて確認を残す。地味ですが、初心者が前に進む速さは、ここで決まると思います。

まずは明日の朝、一文だけ決めて、確認コマンドをひとつ走らせてみてください。続けるうちに自分の型ができてきたら、教材一覧で依頼の雛形を増やすと、毎日の手数がさらに減ります。