NID Claude Code研修 NID Claude Code研修4つの演習を順に進めます。どの演習も「①読ませる・②設計を相談する・③作らせる・④確かめる」の4段で構成しています。参考プロンプトと答えは本書には載せず、配布ZIP内の hints にまとめています。手が止まったら、5〜10分試してから該当ファイルを開いてください。
講義・演習 [420min] に定着・休憩 [100min]・予備 [20min] を加えた合計 [540min]（9:00〜18:00）です。60〜90分に1度を目安に、学んだ内容の定着時間を兼ねた休憩を [10min] 取ります。
| No. | 内容 | 区分 | 所要 |
|---|---|---|---|
| 1 | イントロダクション（座学ふりかえり・素材確認・起動チェック） | 座学 | [15min] |
| 2 | 演習① 簡易プログラムの実装／関数・クラスの生成 | 演習 | [75min] |
| - | 定着・休憩 | 休憩 | [10min] |
| 3 | 演習② 機能追加の実装／既存コードの読解と修正 | 演習 | [80min] |
| - | 昼休憩 | 休憩 | [60min] |
| 4 | 演習③ 不具合修正の実装／CLAUDE.md による精度向上 | 演習 | [90min] |
| - | 定着・休憩 | 休憩 | [10min] |
| 5 | 演習④ 総合実装演習（アクセスログ解析）前半 | 演習 | [55min] |
| - | 定着・休憩（演習の中間） | 休憩 | [10min] |
| 5 | 同・後半 | 演習 | [55min] |
| - | 定着・休憩 | 休憩 | [10min] |
| 6 | 振り返り・質疑・クロージング | 結び | [50min] |
| - | 予備（質疑の延長・個別質問に充当） | 予備 | [20min] |
| 合計（講義・演習 [420min] ＋ 定着・休憩 [100min] ＋ 予備 [20min]） | [540min] |
休憩は60〜90分に1度の目安で置いており、確実に取ります（連続の稼働は50〜90分）。分量の大きい演習④は中間で必ず休憩を挟みます。押していても休憩を削って先へ進まないでください。
配布ZIPを展開した nid-claudecode-handson_受講者用 の中に、演習ごとのフォルダと hints/ があります。各演習は対応するフォルダに移動し、claude を起動して進めます。_reference_完成形 は研修中は開かないでください。最初に exercise01_集計ツール へ移動して claude が起動し、プロンプト待ちになることを確認しておきましょう。
作業ログCSVを集計する小さなCLIを、ゼロから作ります。Claude Code がプロジェクト内のファイルを読み、設計を相談しながら実装まで進められることを体験します。
| フォルダ | exercise01_集計ツール |
| データ | data/work_log.csv（列: date, member, task, minutes・架空） |
| ヒント | hints/step01_集計ツール_hint.md |
exercise01_集計ツール に移動して claude を起動し、CSVにどんな列があり何件あるかを読ませます。データの中身をAIに把握させるところから始めます。
メンバー別に稼働時間を集計するなら、どんな関数構成がよいかを提案させます。いきなり実装させず、方針を言葉にさせるのがコツです。
aggregate.py を新規作成させ、メンバー別の合計稼働分数を多い順に表示させます。続けて、読み込み・集計・表示を関数に分け、集計を保持するクラスへ整理させます。
実際に実行させて結果を確認します。コマンド引数でメンバー別・作業種別を切り替えられるようにして仕上げます。
「集計して」より「メンバー別の合計稼働分数を多い順に表示して」のほうが、出力が安定します。ファイル名・列名・並び順まで言葉にしてみてください。詰まったらヒントの参考プロンプトと見比べてみましょう。
すでにあるチケット管理ツールを Claude Code に読み解かせてから、絞り込みと集計の機能を足します。自分が一行ずつ追わなくても、既存コードの全体像を素早くつかむ流れを体験します。
| フォルダ | exercise02_チケット管理 |
| 対象 | ticket_app.py（python3 ticket_app.py list で一覧表示） |
| ヒント | hints/step02_機能追加_hint.md |
ticket_app.py が何をしているか、関数ごとの役割を日本語で説明させます。あわせて data/tickets.csv の列構成も把握させます。
状態での絞り込みと担当者別の件数集計を足すなら、既存のどこに手を入れるべきかを相談します。「既存の動きは変えない」と前提を置きましょう。
list --status での絞り込みと、stats サブコマンドでの担当者別件数集計を追加させます。既存の list の動きは保ったまま拡張します。
追加した機能を実行して結果を確認し、使い方メッセージも新しいサブコマンドに合わせて更新させます。
機能追加では、既存の動作を保つことが大切です。「既存の list の動きは変えないでください」のように、守ってほしい範囲を明示すると、意図しない変更（回帰）を防ぎやすくなります。追加後は必ず元の list も動かして確認してください。
月次稼働レポートのスクリプトには不具合が3件あります。原因を調べてから1件ずつ直し、続けて CLAUDE.md を書いて、規約ファイルがあると生成結果がどう変わるかを体験します。
| フォルダ | exercise03_不具合修正 |
| 対象 | monthly_report.py（python3 monthly_report.py 2026-07 で実行） |
| ヒント | hints/step03_不具合修正_hint.md |
スクリプトを実行するとエラーになります。まずは原因を調べさせ、何が問題かを日本語で説明させます。この段階では直させません。
見つかった不具合をどの順で直すか、どう直すのが妥当かを相談します。調査と修正を分けると、見落としが減ります。
不具合を1件ずつ「どこを・なぜ・どう直したか」を説明させながら修正します。次に CLAUDE.md をプロジェクトルートに作り、型変換や実行確認の方針を書きます。
修正後に実行して、3件とも直って正しい合計が出ることを確認します。CLAUDE.md がある状態で機能を1つ追加させ、書く前との違いを振り返ります。
「直して」とまとめて頼むより、「まず原因を調べて説明して。修正はまだしないで」と段階を分けると、的外れな修正を避けられます。3件の不具合の中身と直し方の例はヒントに整理してあります。
仕様書を読み、アクセスログを解析するレポートツールを設計から実装・確認まで一気通貫で作ります。これまでの3演習で使った流れをすべて使う総仕上げです。中間で必ず休憩を挟みます。
| フォルダ | exercise04_総合演習 |
| 仕様・データ | spec.md／data/app_access.log（架空） |
| ヒント | hints/step04_総合実装_hint.md |
spec.md と data/app_access.log を読ませ、ログ1行の形式と、仕様が求める出力を整理させます。
仕様を満たすツールの関数構成・処理の流れを提案させます。パース・集計・レポート表示をどう分けるか方針を固めます。
analyze_log.py を新規作成させ、仕様の要件をすべて満たすよう実装させます。形式が崩れた行はスキップし、件数を報告させます。
実行して、仕様の各要件が満たされているかを1つずつ確認させます。満たせていない項目があれば修正して仕上げます。
総合演習では spec.md が唯一の正解条件です。「spec.md の各要件を1つずつ確認して」と頼むと、抜け漏れを自分で見つけて直してくれます。演習③で作った CLAUDE.md があれば、型変換や実行確認の方針も引き継がれます。
仕様にない拡張（日別の集計、CSVへの出力など）を、spec.md に要件として書き足してから実装させてみてください。仕様を先に書く進め方が身につきます。
最後に、4つの演習を通して見えたことを整理します。Claude Code を業務で使い続けるうえで効く観点をまとめました。各ヒントの末尾にも、演習ごとの比較の観点を載せています。
いきなり実装させず、まずファイルを読ませて状況を共有すると、後の指示が短く正確になりました。
原因の説明を先に出させると、的外れな修正を避けられました。段階を分けるほど軌道修正しやすくなります。
CLAUDE.md に型変換や確認の方針を書いておくと、毎回指示しなくても守られ、生成のぶれが減りました。
普段のプロジェクトでも、最初に /init で CLAUDE.md の雛形を作り、チームの規約を書き足すところから始められます。よく使う指示はカスタムスラッシュコマンドにしておくと、同じ作業を素早く繰り返せます。配布の「振り返りシート.txt」に3観点の書き出し欄があります。