はじめに
Day4では、calculator.pyに2種類のバグ（スタックトレースが出るZeroDivisionErrorと、エラーが出ない符号ミス）を仕込み、それぞれ違うアプローチでデバッグを依頼しました。どちらもClaudeが正確に原因を特定してくれて、Windowsコンソールの文字化け問題にも指示なしで対策込みのコマンドを組み立てるようになっていたのが印象的でした。
Day5の今日で最終回です。実務に近いタスクをいくつか投げてみた上で、通常のClaudeチャットとの使い分けを整理し、5日間を総括します。
1. 今日やったこと
今日は3つの実務寄りタスクを試しました。
- これまでの
day1〜day4を読ませて、進捗が分かるREADME.mdを生成 -
day4のcalculator.pyを、コマンドライン引数で演算できるCLIツールに発展 -
average()・discount_price()に対するpytestのテストコードを整備
# day5フォルダに移動してClaude Codeを起動
cd D:\AI\work\day5
claude
:: コマンドプロンプトの場合
cd D:\AI\work\day5
claude
①README自動生成
day1からday4までのフォルダとコードを読んで、この連載の進捗が分かる
README.mdをdayフォルダの親ディレクトリ直下に作成してください。
各Dayで何を学び、どんなファイルがあるかを簡潔にまとめてください
各Dayのドラフト記事まで読み込んだ上で、Day1〜Day4それぞれの「やったこと・つまずき・解決・学び」を要約した進捗表を作ってくれました。今まさに作業中のDay5については「未着手」と正直に記載されていました。
②CLIツール化
day4のcalculator.pyを、コマンドライン引数で演算できるCLIツールに
発展させてください（例：python calc_cli.py 10 + 5 のように実行すると
15が返ってくる）。day5フォルダにcalc_cli.pyとして作成してください
動作確認の過程で、実行結果が一度崩れて見えたことについて「Git Bashのパス展開とコンソールのエンコーディングの問題で、PYTHONIOENCODING=utf-8を設定すれば直る」と、Day4で学んだ内容をそのまま参照する形で説明してくれました。既存のcalc.pyと同じ思想（例外を投げずエラーメッセージを返す）でエラー処理を統一し、*や/はシェルによって解釈が変わるため引用符で囲むことを推奨する注意書きまで添えられていました。
③テストコード整備
day4で修正したaverage()関数とdiscount_price()関数に対して、
pytestでのテストコードをday5フォルダに作成してください。
正常系だけでなく、今回直したバグのケース（空リスト、10%引きの計算）も
テストに含めてください
pytestが未インストールだと気づくと、自分でインストールしてから作業を続けてくれました。day4/calculator.pyをsys.path経由でインポートする形にして、day4側のファイルには一切手を加えていない点も丁寧でした。正常系に加えて、Day4で実際に直したバグのケース（空リストの平均、1000円の10%引き）もテストに含まれており、8件全てパスしました。生成された.pytest_cacheも不要と判断して自分で削除していました。
2. つまずいたポイント
今日は特に大きなつまずきはありませんでした。3つのタスクとも、環境の不足（pytest未インストール）や表示上の問題（Git Bashでの文字化け）にはClaude自身がその場で気づいて対処しており、作業を止めるような事態にはなりませんでした。
3. どう解決したか
つまずきがなかった分、今日は「Claudeがどこまで自分で気づいて対処するか」が際立つ回になりました。pytest未インストールへの対応も、文字化けの原因説明も、こちらが指摘する前にClaude側から出てきたものです。
4. 今日の学び
- README生成やCLIツール化、テスト整備といった実務寄りのタスクでも、これまでのDayで培った「読ませて説明させる→計画を立てさせる→確認しながら進める」という進め方がそのまま通用しました。
- CLIツール化のとき、Day4で学んだ
PYTHONIOENCODING=utf-8の対処法を、Claudeが「Day4's learnings」として明示的に参照していました。単に同じ対策を繰り返すだけでなく、それがどこで学んだ知見かを踏まえて説明してくれるのは、連載を通してやり取りを重ねてきたからこその挙動だと感じました。 - テスト整備では、
day4のファイルを変更せずday5側からインポートする形を自分で選んでいました。指示していないのに「過去のDayの成果物には手を加えない」という連載の構成を汲み取った判断だったのは意外でした。 - 生成後の後片付け（不要なキャッシュファイルの削除など）は、Day3の
__pycache__の掃除から一貫して見られる挙動でした。
5. 5日間を振り返って
5日間を通して、大きく4つの気づきがありました。
- Plan Modeは「聞き方」を教えてくれる：要件が曖昧なとき、Claudeは黙って進めるのではなく選択肢付きで質問を返してきます。Day2のゼロ除算の挙動、Day4のaverage関数の挙動など、実装方針が複数ありうる場面でこの一問一答に何度も助けられました。
- CLAUDE.mdはセッションをまたぐ記憶装置：Day3で気づいた、起動ディレクトリから親ディレクトリまで遡って読み込まれる仕様は、意図しない範囲の情報が混ざるリスクがある一方、ルート/サブディレクトリで情報を設計すれば強力な仕組みになります。今日、Day4の学びをCLIツール化の際に参照してきたのも、この記憶の持続性があってこそでした。
- diffを1つずつ見る習慣とauto modeの使い分け：Day3でauto modeのまま一気に進めてしまった経験から、「確認しながら進めたいときはmanually approve、任せて良いときはauto mode」という判断がしやすくなりました。
- デバッグは聞き方を選べる：スタックトレースがあればそれを貼るだけ、なければ期待する動作との差を説明するだけ。Day4で試した2つのアプローチは、どちらも同じ精度で原因特定につながりました。
Claude Codeと通常のClaudeチャットの使い分け
5日間の実体験をもとに整理すると、判断基準は以下の通りです。
| 観点 | Claude Code | 通常のClaudeチャット |
|---|---|---|
| ファイル 操作 | 実際にファイルを読み書き・実行する | コードを提案するだけで、反映は自分で行う |
| コンテキストの持続性 |
CLAUDE.mdに指示が宿り、セッションをまたいで持続する |
基本的にその会話の中でしか文脈を保持しない |
| 差分の確認しやすさ | diff形式で1つずつ確認・承認できる | 変更点は自分で見比べる必要がある |
| 向いている作業 | 既存コードの読解・修正・デバッグ・複数ファイルの一括変更など、実際に手を動かす作業 | 設計の相談、方針の壁打ち、仕様を言葉にする作業 |
| この連載 での実例 | Day2〜5のほぼ全て（読解・分割・デバッグ・実務タスク） | 記事の構成やプロンプトそのものを相談する場面 |
一言でまとめると、要件がある程度固まっていて実際にファイルを触ってほしいときはClaude Code、まだ考えがまとまっておらず方針を一緒に詰めたいときは通常のClaudeチャット、という使い分けになりそうです。
5日間、ほぼ触ったことがない状態から始めましたが、最終的には実務に近いタスクを一通り任せられるところまで来られました。次回はHooksやSkillsを活用してDay4関連の自動化を検証してみます。