NID GitHub Copilot研修 NID GitHub Copilot研修当日の進行表と演習手順です。参考プロンプトや答えは本書には載せず、配布フォルダの hints にまとめています。まず自分で問いを立て、行き詰まったときに hints を開いてください。AIが返した内容をそのまま信じず、動かして確かめる。この姿勢を一日通して持ち帰っていただくのが狙いです。
座学と演習をおよそ半々で進めます。所要時間は時刻ではなく分量で示します。講義・演習 [420min] に定着・休憩 [100min]・予備 [20min] を加えた合計 [540min] で、60〜90分に1度を目安に、学んだ内容の定着時間を兼ねた休憩を [10min] 取ります。
| No. | 内容 | 区分 | 所要 |
|---|---|---|---|
| 1 | イントロダクション | 座学 | [15min] |
| 2 | グループワーク: AI時代のエンジニアに必要な能力 | 演習 | [30min] |
| 3 | AIとの協働の仕方 | 座学 | [25min] |
| - | 定着・休憩（GWの意見と協働の分担を手元メモに） | 休憩 | [10min] |
| 4 | プロンプトエンジニアリング概論 + Copilot演習（Java/Python） | 演習 | [55min] |
| 5 | コンテキストエンジニアリング概論・実践 | 座学 | [30min] |
| - | 昼休憩 | 休憩 | [60min] |
| 6 | ワーク: AIに問いを立てる力 | 演習 | [40min] |
| 7 | 解説・振り返り | 座学 | [20min] |
| - | 定着・休憩 | 休憩 | [10min] |
| 8 | AIとの協働（出力を評価する力） | 座学 | [25min] |
| 9 | 生成AI利用におけるセキュリティとリスク | 座学 | [25min] |
| 10 | AI時代の開発スタイル | 座学 | [25min] |
| - | 定着・休憩 | 休憩 | [10min] |
| 11 | エージェントモードを活用した不具合調査実践（Java）前半 | 演習 | [50min] |
| - | 定着・休憩（演習の中間。修正内容を見直す） | 休憩 | [10min] |
| 11 | 同・後半 | 演習 | [45min] |
| 12 | AIネイティブなシステム設計（上流から下流まで一気通貫） | 座学 | [20min] |
| 13 | まとめ・振り返り・質疑・アンケート | 座学 | [15min] |
| - | 予備（質疑の延長・個別質問に充当） | 予備 | [20min] |
| 合計（講義・演習 [420min] ＋ 定着・休憩 [100min] ＋ 予備 [20min]） | [540min] |
座学は No.1, 3, 5, 7, 8, 9, 10, 12, 13 で合計 [200min]、演習は No.2, 4, 6, 11 で合計 [220min] のおよそ半々です。これに定着・休憩 [10min]×4回・昼休憩 [60min]・予備 [20min] を加えて合計 [540min]（9:00〜18:00）です。表の休憩は60〜90分に1度の目安で置いており、確実に取ります（連続の稼働は50〜85分）。分量の大きい演習3（No.11）は中間で必ず休憩を挟みます。
本書の演習は、やさしいものから順に次のように進みます。入門トラック（タスク管理TODO）で補完・プロンプト・チャットの基礎操作をつかみ、機器点検の演習1〜3で調査・評価・修正の型を身につけます。続くスキル別演習（テスト生成／コード説明・リファクタ／仕様から実装）でCopilotの使い方を広げ、Python（ログ整形・請求データ検算）で言語をまたいで同じ進め方が通じることを確かめます。早く終わった方や全体で時間が余ったときは、末尾の発展課題・追加課題（4本）に進んでください。分量は多めに用意しているので、自分のペースで進めて構いません。進行表の No.4・No.6・No.11 と No.2 のグループワークは講師が進行に沿ってご案内します。
最初の演習は、買い物や図書館の返却といった日常タスクを管理する小さなTODOアプリです。題材が一目で分かるぶん、Copilotの基礎3ステップ（補完・プロンプト・チャット）そのものに集中できます。java-todo/ フォルダを使います。まず TodoApp.java をそのまま実行し、「タスクを 8 件読み込みました」と表示されることを確認してから始めてください。
Copilotのインライン補完（Tabキー）を体験し、コメントが補完の精度を左右することを体感します。提案を読んでから確定する習慣づけが目的です。
java-todo/data/tasks.csv を開いてください。id・title・due・doneの4列で、タスクが8件並んでいます。この4列がそのままTaskクラスのフィールドになります。
Task.java を開くと、冒頭のコメントに持たせたいフィールドとメソッドが列挙されています。クラスの波かっこの中で private int id; のように書き始め、灰色で出る提案を読んでからTabで確定してください。コンストラクタ・getter・markDone() まで補完で進めます。どこまで一気に提案させ、どこで区切るかは自分で判断してください。
生成物は完成した java-todo/src/main/java/com/example/todo/Task.java です。フィールド4つ・4引数コンストラクタ・getter4つ・markDone() がそろい、エディタに赤い波線が残っていなければOKです。
冒頭のコメントを一度削って同じフィールドを書き始め、提案がどう変わるか比べてください（試したら元に戻します）。補完がコードだけでなくコメントも文脈として読んでいることが分かります。行き詰まったら hints/todo01_warmup_hint.md を開いてください。
Copilot Chatへの依頼文に文脈・制約・出力形式を入れると、提案の質がどう変わるかを確かめます。既存のTaskクラスとCsvLoaderを活かした実装を引き出すのがポイントです。
TodoApp.java を開き、TODOコメントのA-2 (1)〜(3) を読んでください。CSVの読み込みは CsvLoader.java が済ませており、変換以降が皆さんの担当です。CsvLoaderは編集不要です。
Copilot Chatに依頼して、(1) 読み込んだ行を List に変換、(2) タスク追加の addTask メソッド（「ベランダの植木に水をやる」期限2026-08-02を追加）、(3) 一覧表示の printTasks メソッドを実装します。依頼文にどんな制約（外部ライブラリ禁止、CsvLoader変更禁止など）を入れるかは自分で考えてください。
生成物は更新された TodoApp.java です。実行すると全9件が1行ずつ表示され、追加した「ベランダの植木に水をやる」が未完了の印付きで末尾に出ればOKです。完了済みタスク（id=1と6）に完了の印が付いていることも確認してください。
提案されたコードが、A-1で自分が作ったTaskのコンストラクタやgetterの名前と合っているか読み合わせてください。ずれている場合、Copilotに何が見えていなかったのかを考えます。参考プロンプトは hints/todo02_prompt_hint.md にあります。
仕様の曖昧さに自分で気づき、依頼文で埋める練習です。「期限切れ」の定義や「該当idがないとき」の扱いを決めるのはCopilotではなく皆さんです。
data/tasks.csv をもう一度見て、期限が研修日より前で未完了のタスクがどれか、目視で数えてください。この件数が後の検算に使えます。
Copilot Chatに1機能ずつ依頼します。(1) idを指定してタスクを完了にする markDone メソッド（id=2を完了にして再表示）、(2) 期限切れタスクだけを表示する printOverdue メソッドです。依頼する前に、期限が今日と同じ日を「期限切れ」に含めるか、完了済みは出すかを自分で決め、依頼文に書いてください。
生成物は完成した TodoApp.java です。id=2完了後の一覧で図書館タスクに完了の印が付き、期限切れ抽出の件数がステップ2で目視した件数（id=2の完了分を差し引いた数）と一致すればOKです。
markDone に存在しないid（例: 99）を渡すとどうなるか試してください。依頼文で指定しなかった端の場合をCopilotがどう処理したかを見ると、指定漏れの怖さが分かります。詰まったら hints/todo03_chat_hint.md へ。答え合わせは _reference_完成形/java-todo/ で行います。
時間が余ったら、期限切れ抽出の基準日を実行時引数（例: 2026-08-15）で差し替えられるようにCopilot Chatへ依頼し、日付を変えて件数の変化を確かめてください。もう一段進めるなら、期限が近い順に並べ替える sortByDue の追加や、追加済みタスクと同名のタスクを二重登録しないガードを依頼し、提案が Comparator や equals をどう使うか読み解いてみてください。
Copilotの入口は3つ（インライン補完・Copilot Chatへの依頼・チャットでの仕上げ）で、混ぜて使うと、どの操作が効いたのか分からなくなります。A-1で補完だけ、A-2でプロンプトだけ、A-3でチャットだけと切り分けるのは、それぞれの得意・不得意を先に体で覚えるためです。日常タスクのTODOという題材にしているのも、仕様の理解に頭を使わせず操作そのものに集中してもらうためです。ここで掴んだ3つの使い分けが、このあとの機器点検の演習でそのまま効いてきます。
A-2の(1)〜(3)を1回の依頼にまとめず、(1)を実行して動かしてから(2)へ進んでください。提案がずれたときに、どの依頼文が原因かをすぐ特定できます。
期限切れ判定が今日と同じ日を含むかどうかで、比較が「より前」か「以前」かが変わります。Copilotの提案を確定する前に、自分が依頼文で決めた仕様と一致しているか目で確認してください。
Copilot Chatの入力欄で #file と打つとファイルを参照として添付できます。A-1で自分が作ったTask.javaを添付すると、コンストラクタやgetterの名前に合った提案を引き出しやすくなります。
演習で扱うのは、保守の現場を模した小さな Java プログラム「機器点検サマリー」です。CSV から機器の一覧を読み、点検期限を過ぎた機器とカテゴリ別の台数を表示します。
配布フォルダの構成は次のとおりです。java-inventory が演習で触る本体、python-aux が補助演習、_reference_完成形 は答え合わせ用です。研修中は _reference_完成形 を開かずに進めてください。
本来は、登録12台のうち点検期限を過ぎた機器を一覧表示し、サーバー・ネットワーク機器・UPS のカテゴリ別台数を正しく数えます。ところが現状はうまく動きません。どこがおかしいのかを、演習を通して Copilot とともに突き止めます。
機器名やデータはすべて演習用に作られた架空のものです。実際の業務のコードや顧客から預かった情報を Chat に貼ってよいかは、社内ルールと案件の契約に従ってください。
配布フォルダの exercise/ には、当日の全13演習ぶんの完全手順書がそろっています。投影スライドやこのガイドを見失っても、exercise/ の番号順に開けば「何をするか・どこを触るか・どうなれば正解か」が1ファイルで分かり、一人でも進められます。まず exercise/00_進め方.md が入口です。演習の並び順と使うフォルダの対応表が載っています。各演習の節末にも、対応する手順書のファイル名を書いてあります。
編集したファイルは Cmd+S（Windows は Ctrl+S）で保存してください。保存しないと、別のファイルから参照したときに変更前の内容が読まれ、直したはずなのに結果が変わらない、という詰まり方をします。タブ名に丸い印が付いていたら未保存の合図です。もう1つはターミナルの実行フォルダです。VSCode のメニュー「表示」から「ターミナル」を開き、javac や java を打つ前に pwd（Windows は cd）で今どのフォルダにいるかを確かめてください。java-inventory の中にいるつもりで配布フォルダ直下にいると、data/equipment.csv が見つかりません と出ます。その場合は cd java-inventory で移動してから実行します。
配布ファイルはすべて UTF-8 です。日本語 Windows は既定の文字コードが UTF-8 ではないため、指定を省くと文字化けします。ターミナルから Java をコンパイルするときは javac -encoding UTF-8 -d bin ... と指定してください。JDK 18 以降はソースの既定が UTF-8 ですが、JDK 17 以前では既定が MS932 系になり、日本語コメントを含む .java がエラーか文字化けになります。Python で日本語の CSV を読むときは open(path, encoding="utf-8") と明示します。open() の既定は日本語 Windows では cp932 で、UTF-8 の CSV を指定なしで読むと UnicodeDecodeError になります（既定が UTF-8 になるのは Python 3.15 からです）。CSV の中身を確かめたいときは Excel でダブルクリックせず VSCode で開いてください。実行結果だけが崩れる場合は表示側の問題なので、VSCode の「Run」リンクから実行し直すと解消することが多いです。
同じ依頼でも、プロンプトの書き方で返ってくるコードの質が変わります。曖昧な依頼と、文脈・制約・出力形式をそろえた依頼を比べ、違いを体感します。進行表の No.4 に対応します。
「このコードを直して」のような漠然とした依頼と、対象・症状・制約・出力形式をそろえた依頼とで、Copilot Chat の返答がどう変わるかを比べます。プロンプトの骨格を自分の言葉で組み立てられるようになるのが目標です。
VSCode で配布フォルダ nid-copilot-handson_受講者用 を開いた状態にします。java-inventory/src/main/java/com/example/inventory/InspectionService.java を開き、countByCategory メソッドに注目してください。Javadoc には「指定カテゴリの機器台数を数える」とありますが、今はどのカテゴリを渡しても常に 0 を返します。Copilot Chat は左のチャットアイコン、または Windows は Ctrl+Alt+I、Mac は Cmd+Ctrl+I で開きます。入力欄のモードが「Ask」（質問）になっていることを確かめてください。Edit や Agent だとこの演習の趣旨に反してファイルを書き換えにいきます。
先に Main.java を実行して症状をつかみます。main の上に出る「Run」リンク、またはターミナルで cd java-inventory のあと javac -encoding UTF-8 -d bin src/main/java/com/example/inventory/*.java と java -cp bin com.example.inventory.Main を打ちます。出力の「サーバー」「ネットワーク機器」「UPS」がすべて 0 台と表示され、equipment.csv の実物（サーバー5台・ネットワーク機器4台・UPS3台）と合わないことを確認してください。まだ Chat には聞きません。
countByCategory のメソッド全体を範囲選択した状態で、次のような短い依頼を Chat に送ります。返答が来たら、原因の説明がどこまで具体的か、修正案は的を射ているか、頼んでいない書き換え（大文字小文字の無視や trim の追加など）が混ざっていないかを見ます。
「New Chat」（＋ボタン）で新しいチャットを開き、役割・目的と症状・出力形式・制約の4要素をそろえた依頼を送ります。下は骨格の実例です。症状の部分（常に 0 を返す）は、手順3で自分が観察した事実を書きます。2つの依頼を別チャットに分けると、前の会話が混ざらず条件をそろえて比較できます。
2つの依頼の差を、説明の具体さ・修正案の的確さ・余計な変更の有無の3観点で書き出せたら完了です。差の中に Java の文字列比較（== と equals の違い）に関する観点が入っているはずです。プロンプトの組み立て方と比較の観点表は hints/step01_prompt_engineering_hint.md を参照してください。この演習では返答を観察するだけで、コードは修正しません。返答内の適用ボタンや Insert は押さないでください（同じ不具合は演習3で直します）。
同じ整った依頼を Python 側（python-aux/format_log.py）にも投げ、言語が変わると返答がどう変わるかを観察してみてください。制約や出力形式の効き方は言語をまたいで共通です。
整った依頼だけを書いても、その良さは実感しづらいものです。同じ不具合に対して雑な依頼と整った依頼を並べると、原因の説明が「参照と内容の比較の違い」まで踏み込むか浅い推測で止まるか、修正が1行に絞られるか広めに書き換わるかの差が目に見えます。実務では、レビュー中のコードや障害対応の断片をそのまま貼って「直して」と頼みがちです。この演習で骨格（役割・症状・出力形式・制約）を体に入れておくと、あとの演習でも当日の業務でも、最初の一投で欲しい形の返答を引き出せます。
完全な手順は配布フォルダの exercise/02_演習1_プロンプトエンジニアリング.md にあります。ガイドを見失ったらこちらを開いてください。
countByCategory を範囲選択した状態で Chat に送ると、選択範囲が文脈として渡ります。「まず原因の候補だけ」「次に最小の修正案を差分で」と段階を分けると、説明が雑になりません。
返答内の適用ボタンや Insert は押さないでください。書き換わってしまったら Ctrl+Z（Mac は Cmd+Z）で戻します。同じ不具合は演習3で修正します。
入力欄の #file から InspectionService.java と equipment.csv を添付すると、症状の説明が具体的になります。2つの依頼は New Chat で分けて送ると、前の会話が混ざらず条件をそろえて比較できます。
良い答えは良い問いから生まれます。プログラムの不可解な出力を前に、何をAIに聞けば原因に近づけるかを設計するワークです。進行表の No.6 に対応します。
エラーや想定外の出力に出会ったとき、いきなり「直して」と頼むのではなく、自分なりの仮説を立て、それを確かめる問いへ言い換える練習です。問いの質が、AIから引き出せる情報の質を決めます。
Main.java を実行してください（「Run」リンク、またはターミナルで cd java-inventory のあと javac と java）。まず日付の読み取りで DateTimeParseException が出て、台数が表示される前に止まります。この例外文を要約せず、どのクラス・どの行で、どんな入力のときに起きたかを書き出してください。手がかりは equipment.csv にあります。ほとんどの行は 2026-01-15 の形ですが、1行だけ 2025/11/05 とスラッシュ区切りが混ざっています。例外を直して実行できるようになると、今度は表示される台数に違和感が出てきます。
まず、あえて材料の足りない問いを投げて返答の粒度を確かめます。何を・どの入力でかが抜けているため、汎用的な答えしか返りません。
観察から仮説を2〜3個立て、それぞれを「対象・仮説・検証できる形」を含む問いに書き換えます。下は実例です。#file で CsvLoader.java と data/equipment.csv を添付し、スタックトレースは原文のまま貼ると、行番号や例外クラスがそのまま手がかりになります。
効きにくい問いと効く問いで返答の具体さがどう違ったかをメモし、原因にたどり着く問いを1つでも作れたら完了です。この演習は問いを設計するワークで、コードの修正は演習3で行います。問いの立て方の例と、効く問い・効きにくい問いの比較表は hints/step02_questioning_hint.md を参照してください。
同じ症状について、あえて効きにくい問い（「なんで動かないの」など）も投げてみてください。返答の粒度がどう落ちるかを見ると、問いの質と返答の質の関係が体感できます。
不具合を前にすると、原因を自分で見立てる前に「直して」と頼みたくなります。ただ、見立てのない依頼は汎用的な答えを返し、当たっているかどうかも判断できません。仮説を立ててから問うと、外れても「その線ではない」と切り分けが進みます。この演習で例外を直さず問いだけを設計するのは、答えを急ぐ癖をいったん止めて、原因の当たりを付ける工程を独立して体に入れるためです。障害対応で効いてくるのは、この当たりの付け方です。
完全な手順は配布フォルダの exercise/03_演習2_問いを立てる力.md にあります。
Copilot Chat に投げる前に #file で CsvLoader.java と data/equipment.csv を添付してください。スタックトレースは要約せず原文のまま貼ると、行番号や例外クラスがそのまま手がかりになります。
「直して」とだけ頼むと汎用的な答えしか返りません。仮説と入力値を添えて問い、返答の行番号や原因は実行結果とCSVの実物で裏取りしてください。例外が消えた後も、表示される台数に違和感がないか自分の目で確かめます。
気になるメソッドを選択して Ctrl+I(Mac は Cmd+I)を押すと、その範囲だけに絞って質問や修正依頼ができます。修正提案は適用前に差分を確認し、自分の方針どおりのときだけ受け入れてください。
エージェントモードに調査を任せ、複数ファイルにまたがる不具合を特定して直します。任せきりにせず、提案を一つずつ評価しながら進めるのがこの演習の肝です。進行表の No.11 に対応します。
このプログラムには3つの不具合が仕込まれています。日付形式の混在、期限超過の判定での末尾漏れ、カテゴリ集計の比較方法。どれも現場で起こりがちな種類の誤りです。
Copilot のエージェントモードに不具合の調査を依頼し、返ってきた原因の特定と修正案を評価しながら、3つの不具合を順に直します。AIに任せる範囲と、人が確かめる範囲の線引きを実地で確認します。この演習は前半（約50分）で不具合1を直し、中間休憩をはさんで後半（約45分）で不具合2と3を直す2部構成です。
VSCode で配布フォルダを開き、java-inventory/src/main/java/com/example/inventory/Main.java を開きます。Copilot Chat の入力欄のモード切り替えで「エージェント」を選んでください。Main をいったん実行すると、日付の読み取りで DateTimeParseException が出て止まります。これが正常な初期状態です。エラーメッセージが表示されることを確認できたら準備完了です。
準備で出たエラーメッセージ全文をコピーし、エージェントモードのチャットに貼ったうえで、原因を java-inventory のソースと data/equipment.csv から調査させ、原因の説明のあとに最小の差分で修正案を出すよう依頼します。lastInspection 列に日付形式の混在があることを、CSV の実物を見て確かめてから承認してください。承認前に、変更対象が CsvLoader.java だけか、equipment.csv 側を書き換えようとしていないかを読みます。データは編集せずコード側で直すのが本演習の方針です。取り込んだら Main を再実行し、例外が出ずに最後まで表示されることを確認します。
例外が消えたら、表示された「点検期限超過」の台数と機器一覧を equipment.csv と突き合わせます。CSV のタブを右へドラッグしてエディタを2分割し、出力と並べて見比べると確かめやすいです。基準日は Main.java の 2026-07-30 です。リストの末尾の機器（EQ-011 監視サーバー）が判定に入っているかに注目してください。1台足りないことに気づけたら、それが後半で直す不具合2の症状です。ここまでが前半（約50分）で、いったん休憩します。
休憩後、気づいた症状を文脈として渡して調査させます。たとえば「findOverdue が期限超過の機器を1台少なく返しているようです。ループの範囲を確認し、末尾の要素まで判定されるように直してください」のように、観察した事実を添えます。差分が InspectionService.java の findOverdue に限られているかを読んでから承認し、再実行して末尾の機器も一覧に含まれることを確かめます。
出力の「サーバー」「ネットワーク機器」「UPS」がすべて0台であることを確認し、「countByCategory がどのカテゴリでも0を返します。原因を説明してから最小の差分で直してください」と依頼します。Java の文字列比較の方法に原因があります。修正後に再実行し、3カテゴリの台数を equipment.csv の category 列（サーバー5台・ネットワーク機器4台・UPS3台）と突き合わせます。
3つの不具合をすべて直し、Main の出力が期限超過の機器を漏れなく一覧し、カテゴリ別台数が正しく出れば完了です。各不具合の原因・調査の進め方・修正の要点は hints/step03_agent_debug_hint.md を参照してください。修正は CsvLoader.java・InspectionService.java を直接上書き保存します。_reference_完成形 は編集しません。
エージェントモードはファイルの編集やコマンド実行をまとめて提案します。承認する前に、何をどう変えようとしているかを必ず読んでください。意図しない箇所まで書き換える提案は、その場で却下して依頼し直します。
直したコードに対して「このクラスの単体テストを書いて」とエージェントモードに依頼し、境界条件（末尾・ゼロ件・日付形式）がテストに含まれているかを評価してみてください。テストの抜けに気づけたら、評価する力が働いている証拠です。
エージェントモードは複数ファイルの編集やコマンド実行をまとめて提案するぶん、任せきりにすると意図しない変更まで通ってしまいます。この演習で不具合1を直した直後に自分で台数を検算させるのは、AIが「例外が消えた」ところで完了と判断しても、末尾漏れのように症状が残っていることを人が見つける流れを作るためです。3件を一気に頼まず1件ずつ直して都度実行するのも同じ理由で、どの変更がどの出力を動かしたかを追える状態を保ちます。任せる範囲と確かめる範囲の線引きが、当日の業務でエージェントを安全に使う分かれ目になります。
完全な手順は配布フォルダの exercise/04_演習3_エージェントモード不具合調査.md にあります。
3つまとめて頼むと変更範囲が広がり、差分の評価が追いつかなくなります。エラーメッセージや「1台少ない」といった症状をそのまま文脈として渡し、1件直すたびに Main を実行して出力の変化を確かめてください。
エージェントモードはファイル編集をまとめて提案します。承認前に変更対象と差分を必ず読み、意図しない箇所まで書き換える提案はその場で却下して依頼し直してください。data/equipment.csv を書き換えて直すのは演習の趣旨から外れます。
チャット入力欄で #file と打つと CsvLoader.java や InspectionService.java を添付できます。対象を絞って渡すと調査の精度が上がり、無関係なファイルへの変更提案も減ります。
Copilot Chat の /tests を使い、税・送料計算ロジックの境界条件を突く自己検証テストを生成させます。この環境には JUnit がありません。制約を伝えて欲しい形式に誘導し、生成されたテストを自分で採点するまでが課題です。
/tests にそのまま頼むと JUnit 前提のコードが返ってきて、この環境ではコンパイルできません。制約(外部ライブラリ禁止・main内で突き合わせる形式)を伝えて出力を作り変えさせ、さらに生成されたテストの網羅性を自分で評価する。この2段構えがテスト生成を業務で使うときの型です。題材の実装には仕様と食い違う箇所が1つだけ仕込んであります。
skill-drills/tax-calc/ を開き、README.md の仕様(標準10%・軽減8%・端数切り捨て・税込小計3,000円以上で送料無料)を確認してください。data/注文サンプル.csv はキッチン雑貨ショップの注文3明細です。ターミナルで cd skill-drills/tax-calc のあと javac -encoding UTF-8 -d bin src/main/java/com/example/tax/*.java と java -cp bin com.example.tax.TaxCalcDemo を実行し、税込小計4,122円で送料無料になる表示を見ておきます。この時点では不具合は表に出ません。
まず仕様から境界の一覧(単価0円・負値・端数が出る値、数量0・負値、税込小計2,999/3,000/3,001円)を紙に書き出します。次に PriceCalculator.java を開いて /tests を実行し、返ってきたコードがこの環境で動くか確認してください。動かなければ「JUnitなど外部ライブラリを使わない」「mainメソッド内で期待値と実際値を突き合わせ、失敗があれば終了コード1」「境界一覧を必ず含める」の3条件を付けて頼み直します。生成された PriceCalculatorSelfTest.java を src/main/java/com/example/tax/ に保存し、コンパイルして実行します。失敗するケースが出たら、テストと実装のどちらが仕様に合っているかを判定し、実装側を最小の差分で修正してください。
生成物は skill-drills/tax-calc/src/main/java/com/example/tax/PriceCalculatorSelfTest.java と、修正した PriceCalculator.java です。OK基準は3つ。テストに税込小計3,000円ちょうどのケースが含まれていること、修正後に全ケース成功して ALL PASSED 相当の表示が出ること、修正前のデモ表示(小計4,122円・送料0円)が修正後も変わらないことです。詰まったら hints/skill_tests_hint.md を、答え合わせは _reference_完成形/skill-drills/tax-calc/ を参照してください。
Copilot が最初に出した期待値を疑ってください。実装の現在の挙動をなぞって期待値を作るケースがあり、その場合バグごと正解扱いになります。仕様文だけを渡してテストを書かせた場合と、実装コードを見せて書かせた場合で、3,000円ちょうどの期待値がどう変わるか比べると、この危うさが体感できます。
送料のしきい値を「税抜小計」基準に仕様変更するとどのテストが壊れるか、先にテスト側を書き換えてから実装を直す手順(テストファースト)を試してください。もう1段進めるなら、lineTotal の税計算を「単価ごと」から「行合計ごと」に変えた場合に合計が何円ずれるかをテストで示し、どちらが正しいかを国税庁の適格請求書の端数処理ルールを調べて判断します。
AIにテストを生成させるときの一番の落とし穴は、実装コードを見せると、その現在の挙動をなぞって期待値を書いてしまう点です。こうなるとバグごと正解扱いになり、全ケースPASSでも不具合は残ります。この演習で期待値を仕様の文面から自分で計算し、生成結果と照合するのはそのためです。テスト生成を業務で使う価値は、書く手間を省くこと自体より、仕様と実装のずれを浮かせることにあります。期待値の出どころを人が握る、という型をここで作っておいてください。
/tests にそのまま頼むと JUnit 前提のコードが返り、この環境ではコンパイルできません。外部ライブラリなし、main 内で期待値を突き合わせ、失敗時は終了コード1、の3条件を最初から付けると手戻りがなくなります。
実装コードを見せてテストを生成させると、Copilot は実装の現在の挙動から期待値を作ることがあります。その場合バグごと正解扱いになり、全部 PASS でも不具合が残ります。期待値は仕様の文面から自分で計算し、生成結果と照合してください。
Chat の入力欄で #file と打つとファイルを添付できます。README.md と PriceCalculator.java の両方を渡すと、実装依存ではなく仕様基準の期待値に寄ります。境界一覧は自分で書き出してプロンプトに貼ると網羅漏れを防げます。
読み手泣かせのコードを /explain で読み解き、振る舞いを変えずに整えます。題材は架空の喫茶チェーン3店舗の売上集計です。出力は正しいのに、main が1本の長いメソッドで、命名は雑、同じ形のループが3回コピーされています。業務で他人のコードを引き継いだときと同じ状況を、Copilot と一緒に切り抜けてください。
/explain でレガシーコードを短時間で読み解く手順と、「振る舞いを固定してリファクタを依頼する」プロンプトの書き方を身につけます。リファクタの合否は感覚ではなく、実行出力の完全一致で判定します。
skill-drills/refactor-report/ を開きます。data/売上.csv は date・店舗・商品・金額の売上明細20件です。src/main/java/com/example/refactor/SalesReport.java の main を実行し（main の上の「Run」リンク）、出力全体をコピーして控えてください。これがリファクタ後も守るべき「正解の出力」です。CsvLoader.java は読み込み担当で、今回は触りません。
Copilot Chat で /explain を実行します。まず main 全体、次に変数 a と b を含むループ1つだけに範囲を狭めて聞き直し、a b t flag2 が何を表すか自分の言葉でメモしてから答え合わせしてください。flag〜flag3 の3つのループの違いが「どのキーで集計するか」だけだと気づけたら、読み解き完了です。
Copilot に「振る舞いを変えずに読みやすく分割して」と依頼します。ただし丸投げにせず、変えないもの（出力の全行・並び順・空白）、直したいもの（並行リストの解消・重複ループの共通化・命名）、制約（外部ライブラリなし・CsvLoader は変更しない）をどう指示文に落とすかは自分で考えてください。提案に HashMap が混ざると店舗の表示順が崩れます。気づけるかどうかも演習のうちです。
生成物はリファクタ後の SalesReport.java（同じ場所に上書き）です。OK基準は3つ。リファクタ前後で出力が1文字残らず一致していること、main が処理の流れを追うだけで読める長さになっていること、同じ形のループのコピーが残っていないことです。詰まったら hints/skill_refactor_hint.md を、答え合わせは演習後に _reference_完成形/skill-drills/refactor-report/ を開いてください。
リファクタ後のコードに「コードレビューして。改善点を重要度順に3つ」と依頼し、指摘のうち採用するもの・しないものを理由付きで選んでください。あわせて、最高売上日の判定が >= に変わっていないかも確認を。このデータでは出力が変わらないのに振る舞いは別物、という「テストをすり抜ける差分」の実例です。
リファクタの成否を「読みやすくなった気がする」で判断すると、振る舞いが変わったことに気づけません。この演習で前後の出力を1文字残らず突き合わせるのは、見た目の改善と動作の保存を切り離して確かめるためです。実務で引き継いだコードを整えるときも、まず現在の出力を正解として固定し、そこからずらさずに構造だけ変えるのが安全な順序です。HashMapの提案が表示順を壊す例のように、出力が変わらないのに振る舞いが別物になる差分もあり、一致確認はその検出にも効きます。
main 全体を丸ごと聞くより、変数 a と b を含むループ1つをドラッグ選択してから /explain を送るほうが、具体的な答えが返ります。a b t flag2 の意味を自分の言葉でメモしてから答え合わせをしてください。
店舗・商品の表示順はCSVに最初に現れた順です。Copilotの提案に HashMap やソートが混ざると並び順が変わり、出力が一致しなくなります。適用前に集計の入れ物を確認してください。合否は控えた出力との1文字残らずの一致で判定します。
リファクタ前後の出力をそれぞれファイルに保存し、2ファイルを選択して右クリックから「選択項目を比較」を使うと、違う行だけ強調表示されます。目視より確実です。
仕様書を Copilot に渡して新機能を実装する演習です。架空の「みなと商店街」のポイントカードを題材に、規程 md に書かれたポイント付与ルールとランク判定をコードに落とします。読解やデバッグではなく「仕様をどう伝え、提案をどう検収するか」に重心を置いています。
実務の新機能開発では、仕様書のしきい値や端数処理をコードへ正確に落とすことが求められます。ここでは data/ポイント規程.md を Copilot のコンテキストとして渡し、規程どおりに動く機能を追加します。Copilot が「推測」で書いたしきい値と、仕様を根拠に書いたしきい値を見分ける目を養います。
skill-drills/point-card/ を開きます。data/購入履歴.csv（会員ID・購入日・税込金額、2026年6〜7月の25件）、data/会員名簿.csv（架空会員7名）、そして仕様書役の data/ポイント規程.md の3点です。規程には「100円ごとに1ポイント（購入1回ごとに切り捨て）」「対象月の購入合計でゴールド/シルバー/ブロンズを判定」が定められています。まず PointCardApp.java を現状のまま実行し、会員別の購入合計（全期間）が7名分表示されることを確認してください。
規程 md を自分で読んで実装すべきルールを箇条書きに整理してから、Copilot Chat に規程 md を添付して依頼します。実装するのは対象月（2026-07）の「会員別ポイント付与数の計算」と「会員ランクの判定」の2機能です。一度に頼まず、付与を実装して実行確認してからランク判定へ進むと崩れにくくなります。しきい値はマジックナンバーにせず定数にする、という制約も依頼文に含めてください。
規程のしきい値（50,000円・20,000円）と「以上/未満」をどの比較演算子で書くか、ポイントの切り捨てを購入1回ごとに行うにはどこでループを回すか、対象月に購入がない会員をどう扱うか。この3点は Copilot の提案を鵜呑みにせず、規程の該当行を根拠に自分で判定してください。データには境界値と端数購入が仕込んであり、解釈を誤ると数字がずれます。
生成物は PointCardApp.java の変更のみです。OK基準は、7名全員分のポイントとランクが表示される（7月に購入がない会員も含む）、月間合計がちょうど50,000円の会員がゴールド・ちょうど20,000円の会員がシルバーになっている、9,990円の購入が99ポイントと数えられている（月間合計に対する切り捨てだと合計が1ポイントずれます）、の3点です。行き詰まったら hints/skill_feature_hint.md を、答え合わせは演習後に _reference_完成形/skill-drills/point-card/ を開いてください。
規程の「3. ランク特典」を実装してください。前月（2026-06）のランクを判定し、ゴールドなら2倍・シルバーなら1.5倍の倍率を対象月のポイント付与に適用します。1.5倍の切り捨て単位は規程の文言だけでは確定しないため、自分の解釈を決めてコメントに根拠を残してから実装します。ランク判定を月引数で呼べる作りにリファクタリングしておくと、前月判定は同じメソッドの再利用で済みます。
新機能を実装させるとき、しきい値や端数処理をプロンプトに書かないと、Copilotはそれらしい値を推測で埋めます。規程mdを添付する場合としない場合で最初の提案を比べると、根拠のある実装と推測の実装の差が見えます。この演習の狙いは、コードを書かせることより「仕様のどの行を根拠にこの値なのか」を検収できる目を作ることです。境界値（ちょうど50,000円など）と端数（購入1回ごとの切り捨て）を仕込んであるのは、根拠の確認を省くと数字がずれるからです。
Copilot Chatに #file で data/ポイント規程.md を添付した場合と、添付しない場合で最初の提案を比べてください。添付なしでしきい値や端数処理を書いてきたら、それは仕様の根拠がない推測です。依頼は付与とランク判定の2回に分け、1機能ずつ実行確認してから進めます。
月間合計に対してまとめて割り算すると規程違反で、9,990円の購入を含む会員の合計ポイントが1ずれます。しきい値50,000円と20,000円の比較演算子も、規程の「以上/未満」の行と突き合わせてから適用してください。
提案はそのまま適用せず、インライン差分で追加行と削除行を1行ずつ確認します。定数化を頼むときは対象範囲を選択してからChatに依頼すると、変更が選択範囲に絞られて検収が楽になります。
Java の演習に余裕があれば、Python の短いスクリプトでも同じ進め方を試します。雑多なログを読みやすい形に整える小さな課題です。
言語が変わってもプロンプトの組み立てと出力の評価は同じだと確かめます。Python のサンプルログを、レベル別に集計し読みやすく出力するスクリプトを Copilot とともに仕上げます。
python-aux フォルダを開き、format_log.py と sample.log を確認してください。スクリプトには未完成の箇所（TODO）があります。
ログをレベル（INFO / WARN / ERROR）ごとに数え、件数の多い順に表示する処理を、Copilot Chat に文脈と出力形式を渡して書かせます。返ってきたコードを実行して結果を確かめ、必要なら問いを立て直します。
レベル別の件数が正しく表示されれば完了です。参考プロンプトと完成例の考え方は hints/step04_python_log_hint.md を参照してください。生成したコードは python-aux/format_log.py の TODO 箇所を埋めて上書き保存します。
Java中心の一日ですが、この補助演習をPythonで置くのは、プロンプトの組み立てと出力の評価という型が言語に依存しないことを確かめてもらうためです。文脈・制約・出力形式を渡し、返ってきたコードを実行して自分の目で件数を照合する流れは、JavaでもPythonでも変わりません。短いログを題材にしているので、生成結果を手で数えて突き合わせるところまで無理なくできます。担当言語が変わっても今日の進め方がそのまま通じる、という手応えを持ち帰ってください。
format_log.py の docstring には引数の意味と出力の期待が書いてあります。関数全体を選択して Copilot Chat に送るだけで文脈の大半が伝わります。count_levels と format_report は1関数ずつ、書かせて動かして確かめてから次へ進みます。
もっともらしい出力でも、レベルが取れない行を数えていたり並び順が少ない順になっていたりすることがあります。sample.log は短いので、必ず自分の目で数えて照合してください。parse_level を使わず独自にパースする提案にも要注意です。
Chat の入力欄で #file:sample.log と打つと、ログファイルそのものを参照として添付できます。ログ形式を文章で説明する代わりに実物を見せる方が正確です。インラインチャット(Ctrl+I、Mac は Cmd+I)なら該当箇所だけを差分表示で確認しながら書かせられます。
経理システムから出力された請求データの明細とサマリを突き合わせ、金額計算の誤りを検出するツールを Copilot と一緒に完成させます。日本語の業務ルールをプロンプトへ正確に翻訳する工程が中心です。
検算ルールを読まずに「CSVを検算して」とだけ頼むと、Copilot は消費税の基準や端数処理を勝手に決めます。ルールに書かれた条件をどこまでプロンプトに書き写せるかで結果が変わることを体験します。あわせて、float の誤差を含む提案コードに気づいて直す練習をします。
python-invoice/data/ を開きます。請求明細.csv は文具卸の請求書5枚ぶんの明細14行（請求書番号・取引先・商品・数量・単価・小計）、請求サマリ.csv は請求書ごとの小計合計・消費税・請求額です。数件、わざと計算の合わない行が混ざっています。実装前に 検算ルール.md の3つのルールを必ず読んでください。特に「消費税・請求額の基準はサマリに記載された値」と「円未満切り捨て」を読み飛ばすと、Copilot への指示も間違います。
python-invoice/verify_invoice.py を開き、TODO(1) 明細の検算（小計 = 数量 × 単価）、TODO(2) サマリの検算（小計合計・消費税・請求額の3種類を独立にチェック）、TODO(3) レポート出力の順に Copilot へ依頼します。CSV の読み込みは実装済みなので、検算ロジックに集中できます。実装のたびに python3 verify_invoice.py で実行し、検出件数の変化を確かめてください。行き詰まったら hints/python_invoice_hint.md を開きます。
生成物は完成した python-invoice/verify_invoice.py です（新しいファイルは作りません）。実行結果に明細の不一致 2 行とサマリの不一致 3 件、合計 5 件が表示されれば正解です。INV-2026-003 の消費税 8,200円 を不一致として誤検出している場合は、基準を明細の合計から取ってしまっています。また 小計合計 * 0.1 のような float 計算が残っていないかも見直してください。答え合わせは _reference_完成形/python-invoice/ で行います。
data/請求明細.xlsx を openpyxl で読む load_details_xlsx() を Copilot に書かせて、CSV 版と同じ 5 件が検出されるか比べてください（openpyxl を入れられない環境ではスキップして構いません）。もう一段進めるなら、不一致の一覧を CSV に書き出す機能を、出力する列の仕様を自分で決めてから依頼してください。
「CSVを検算して」とだけ頼むと、Copilotは消費税の基準や端数処理を勝手に決めます。この演習は、検算ルールに書かれた条件をどこまで正確にプロンプトへ書き写せるかで結果が変わることを体験する回です。実務でAIに任せる要件は、たいてい日本語の規程やマニュアルの中にあります。読み飛ばした一行がそのまま指示の欠落になり、誤検出につながる、という因果をここで一度通しておくと、当日の業務で規程をプロンプトに落とすときの丁寧さが変わります。
Copilot Chat で #file から data/検算ルール.md を添付し、「このルールどおりに」と依頼すると転記ミスを減らせます。TODO の docstring には戻り値の形まで書いてあるので、関数全体を範囲選択してから頼むと形式を守りやすくなります。
ルール3の基準はサマリに記載された小計合計です。明細の合計から計算すると INV-2026-003 の消費税を誤検出します。小計合計 * 0.1 のような float 計算も1円ずれる原因になるので、受け入れる前に提案コードを読んでください。
TODO(1)から順に依頼し、そのたびに python3 verify_invoice.py を実行します。最終的に明細2行とサマリ3件、合計5件になるかを目印に、どの段階でずれたかを切り分けられます。
演習1〜3と補助演習を終えた方向けの、実務に近いチャレンジ課題です。ここまでで身につけた「実行して観察し、仮説を立て、Copilot に文脈を渡して直す」流れを、一人で最後まで回せるかを試します。
課題は4本あります。早く終わった方は発展課題（Java 2本）から興味のあるものを、全体で時間が余ったときは追加課題（Python 2本）をみんなで1つ選んで取り組みます。それぞれ challenges/ の下に専用フォルダがあり、まず各フォルダの README.md を開くところから始めてください。業務を想定したダミーデータ（CSV・Excel・Word・画像など）が入っています。
どの課題も、コードだけ読んでも正解にたどり着けません。Excel や Word の規程・仕様を自分で読み、ルールを言葉にして Copilot に渡すところが山場です。答えは各 hints/ と _reference_完成形/challenges/ にありますが、まず自分で仮説を立ててから開いてください。
本編の演習1〜3は、症状の与え方や進める順番をガイドが細かく案内していました。チャレンジは題材が実務寄りになるぶん、案内をあえて減らしています。どのファイルを入力とみなし、どの規程を正解の基準にするかを自分で決めるところから始まります。手が止まったら exercise/ の対応する手順書（No.10〜13）を開けば、本編と同じ粒度で1ステップずつ追えます。一人で最後まで回せた実感が、明日からAIを業務に持ち込む足がかりになります。
架空の図書館の貸出データから延滞レポートを作ります。出力と業務規程を突き合わせて不具合を見つけ、Copilot に仕様書を渡して直す進め方を練習します。
本編で扱った「実行して観察→仮説→Copilot に依頼」の流れを、今度は仕様書（貸出規程）との照合込みで一人で回します。コードだけ読んでも正解が分からず、規程の定義を読んで初めて何がバグか判断できる構成です。
challenges/library-lending/data/ にある実ファイルを開いて、何のデータかを把握します。蔵書リスト.csv（20冊）と 貸出履歴.csv（30件、returned_on 空欄は未返却）がプログラムの入力です。会員名簿.xlsx・会員証サンプル.png は業務の実物、貸出規程.md には延滞の定義が書かれています。この規程が答え合わせの基準になるので、必ず先に読んでください。
src/main/java/com/example/library/LibraryReport.java を Run で実行し、「延滞中の貸出一覧」の件数を規程の定義と見比べます。延滞中の件数と会員別延滞回数の合計が食い違っているはずです。どのメソッドが規程とずれているかを自分で仮説立てしてから、貸出規程.md をコンテキストに添えて Copilot に調査と修正を依頼してください。仕様書を渡す場合と渡さない場合で提案がどう変わるかも試す価値があります。修正後、発展としてカテゴリ別の貸出ランキング（貸出回数の多い順）の出力を Copilot と追加します。2つの CSV をどの列で突き合わせるかは自分で決めてから依頼してください。
延滞中の一覧が「returned_on が空欄かつ期限超過」の4件だけになり、その全員が会員別延滞回数にも計上されていれば修正完了です。ランキングは5カテゴリの合計が貸出履歴の総件数30件と一致すれば完了です。生成物は challenges/library-lending/src/main/java/com/example/library/ の各クラスに上書き保存します。ヒントは hints/challenge01_library_hint.md、答え合わせは演習後に _reference_完成形/challenges/library-lending/ で行います。
会員別延滞回数に 会員名簿.xlsx の氏名を突き合わせて表示する改良に挑戦してください。ただし Java から xlsx は読まず、Copilot に「xlsx の内容を CSV に書き出す手順」を相談するところから始めます。データ形式の変換をどこで行うべきかという設計判断も含めて Copilot と対話してみてください。
ここからのチャレンジは、コードだけ読んでも正解にたどり着けない構成です。図書貸出のバグは文法的には正しく、貸出規程という仕様書と突き合わせて初めて食い違いが分かります。規程を渡さずに聞くと、Copilotは今の実装を仕様とみなして「問題ありません」と答えがちです。正しさの基準をコードの外（規程・就業規則・SLA）に置き、それをAIに渡すという実務の型を、一人で最後まで回せるかを試すのがチャレンジのねらいです。
まず貸出規程.md を渡さずに「延滞判定を見てください」と聞き、次に #file で規程を添えて聞き直してみてください。Copilot の答えの根拠がコードから仕様書に変わるのを体感できます。
規程なしで聞くと、Copilot は今の実装を仕様とみなして「問題ありません」と答えることがあります。延滞中の件数は自分で貸出履歴.csv を数えて検算してから、提案の採否を判断してください。
「まず規程とのずれを説明して。修正はまだしないで」と段階を切ると、Copilot の理解を確認してから直せます。差分は Accept を押す前に読み、依頼していない箇所が変わっていないかを見ます。
打刻ログから社員別の月間残業時間を出す集計プログラムですが、出力が就業規則と食い違っています。仕様書をCopilotに渡してコードとの食い違いを見つけさせる、業務ルール起因バグの調査練習です。
実務のバグはコードだけ読んでも見つからないことがあります。この課題のバグは文法的には正しく、就業規則という「仕様書」と突き合わせて初めて食い違いが分かります。仕様文書をCopilot Chatのコンテキストとして渡し、コードとの差分を特定させる進め方を体験します。
challenges/attendance/data/ にある実ファイルを開いて、何のデータかを把握します。打刻ログ.csv は社員5名×1か月分の出勤・退勤打刻で、プログラムが読むのはこのCSVだけです。社員マスタ.xlsx でemployee_idと氏名・部署の対応を、就業規則抜粋.docx で労働時間・休憩・残業・深夜労働のルールを確認します。この docx が集計ルールの正本です。
まず AttendanceReport.java をそのまま実行し、社員別の月間残業時間を控えます。ほぼ毎日18:00に退勤している社員の残業が20時間を超えていることに注目してください。次に、就業規則のどの条文がコードに反映されていないかを自分で特定します（1日分だけ手計算すると早く見つかります）。特定できたら、該当条文をコピーしてCopilot Chatに貼り付け、規則との食い違いの説明と最小差分での修正を依頼します。発展として、実労働時間を「所定内（8時間まで）」と「法定外（8時間超）」の2列に分けて表示する改修も依頼してみてください。
修正後の実行で、ほぼ定時退勤のE001の月間残業が2:15になり、全社員の残業が修正前より「出勤日数×1時間」ちょうど減っていれば完了です。生成物は challenges/attendance/src/main/java/com/example/attendance/AttendanceReport.java に上書き保存します。ヒントは hints/challenge02_attendance_hint.md、答え合わせは演習後に _reference_完成形/challenges/attendance/ を開いてください。
就業規則第24条の深夜労働（22:00以降）を「うち深夜」列として別枠集計してください。退勤打刻は当日24:00より前なので、退勤時刻と22:00の差の正の部分を月間合算するだけで求まります。E003だけに3:58が付けば正解です。余力があれば、社員マスタ.xlsx の氏名を出力に載せる方法（CSV化してから読む、コード内Mapに写す等）の設計判断をCopilotと相談してみてください。
就業規則の条文を自分で要約してから渡すと、要約に混じった解釈のずれがそのままコードの修正へ入り込みます。この課題で条文を原文のままコピーして貼るよう促しているのは、根拠を人の解釈で薄めないためです。労務や経理のような、判断が規程に厳密に縛られる領域ほど、原文をそのまま文脈に入れる価値が大きくなります。1日分を手計算して食い違いを先に自分で掴んでから依頼すると、Copilotの説明が自分の見当と合うかで提案の質を判定できます。
就業規則の条文を自分で要約せず、docxからそのままコピーしてCopilot Chatに貼り付けてください。要約に混じった解釈のずれは、そのままコードの修正に入り込みます。
条文を渡さずに「残業が多すぎる」とだけ伝えると、Copilotは一般的な労務ルールを推測して修正案を出します。この会社の休憩や控除の条件はdocxが正本なので、根拠は必ず条文に置いてください。
最初の依頼に「まだ修正しないでください」を付け、食い違いの説明だけ先に出させます。説明が自分の見当と一致してから「最小限の差分で修正」と続けると、無関係な書き換えを差分レビューで止めやすくなります。
サポートデスクの問い合わせチケット40件をCSVから集計し、月次レポートの数字を出します。仕様書（SLA規定）に書かれていない部分を自分で決めてからCopilotに依頼する練習です。
日時データの集計をCopilotに依頼するとき、仕様の曖昧な部分（未クローズチケットの扱い）を放置すると、もっともらしいけれど根拠のないレポートができます。方針を自分で決めて、それをプロンプトと出力の両方に反映する流れを体験します。
challenges/support-tickets/data/ にある実ファイルを開いて、何のデータかを把握します。tickets.xlsx を開くと40件のチケットが見えます（オレンジ色の行が対応中）。カテゴリ定義.md で5カテゴリの意味を、SLA規定.txt で優先度別の目標対応時間（高8時間・中24時間・低72時間）を確認してください。機械処理するのは同じ内容の tickets.csv です。
analyze_tickets.py の4つのTODOを load_tickets から順にCopilotで実装します。カテゴリ別件数と平均対応時間は、データの前提（列名・日時形式・未クローズは空欄）をプロンプトに含めれば一発で通るはずです。自分で考える箇所は find_sla_violations のSLA判定ロジックです。SLA規定は未クローズ（対応中）チケットの扱いを定めていません。基準日時までの経過時間で判定するか、除外して件数だけ出すか、方針を日本語で決めてからプロンプトにしてください。
python analyze_tickets.py（環境によっては python3）を実行して、カテゴリ別件数・カテゴリ別平均対応時間・SLA超過チケット一覧の3つが表示され、未クローズの扱い方針が出力から読み取れれば完了です。生成物は challenges/support-tickets/analyze_tickets.py に上書き保存します。詰まったらヒントは hints/challenge03_tickets_hint.md、完成形は _reference_完成形/challenges/support-tickets/ にあります。
Copilotに tickets.xlsx をopenpyxlで直接読む版への書き換えを依頼して、CSV版と同じ集計結果になるか比べてみてください。もう一段進めるなら、集計結果をMarkdownの表形式でファイル出力する --report オプションの追加を依頼し、月次レポートとしてそのまま貼れる形に仕上げます。優先度「高」の超過だけを先頭に出す並び替えも、業務レポートらしい改良です。
SLA規定は未クローズチケットの扱いを定めていません。仕様に空白があるまま「集計して」と頼むと、もっともらしいけれど根拠のないレポートができあがります。この課題の主眼は、決まっていない部分を自分で方針として言葉にし、それをプロンプトと出力の両方に反映することです。実務でも、仕様の穴に気づいて誰かが決めない限り、AIは黙って推測で埋めます。決めるのは人、という線引きを、曖昧さが残る題材で一度踏んでおいてください。
SLA規定は未クローズ(対応中)チケットの扱いを定めていません。Copilotに聞く前に「基準日時までの経過時間で判定する」「除外して件数だけ出す」のどちらかを日本語で書き出し、その文をそのままプロンプトにしてください。方針は出力にも明記します。
目標時間ちょうど(高で8.0時間)はSLA達成です。生成コードの比較演算子が規定どおりか、承認前に自分の目で確かめてください。SLA_HOURSやREPORT_TIMEを使わず数値を直書きしてくることもあるので、定義済み定数を使う指示を添えます。
実装したい関数をドラッグで範囲選択してからChatに依頼すると、対象がぶれません。#fileでSLA規定.txtを添付すると、規定の文面を踏まえた実装になります。4関数は一度に頼まず、load_ticketsから1つずつ実装して都度実行します。
Wordに書かれた経費規程を読み解き、CSVの経費申請30件から規程違反を自動検出するツールをCopilotと作ります。Copilotが直接読めない資料のルールを、いかに正確にプロンプトへ書き写すかが勝負どころです。
実務でCopilotに渡す要件は、WordやExcelの中に埋まっていることがほとんどです。この課題では規程文書（docx）を自分で読んでルールを箇条書きに整理し、それをプロンプトに落として実装させる、という業務そのままの流れを体験します。
challenges/expense-check/data/ にある実ファイルを開いて、何のデータかを把握します。経費規程.docx をWordで開き、科目ごとの上限金額・領収書が必須になる金額・申請できない科目を確認してください。第2条には例外規定があるので読み飛ばさないよう注意します。経費明細.xlsx と レシート_サンプル.png は経理担当が普段見ている実物のイメージです。プログラムで読むのは 経費明細.csv（30件）です。
check_expenses.py のTODOを上から埋めます。まず自分で規程のルールを箇条書きに書き出し（ここが自分で考える箇所です。Copilotはdocxを読めないため、書き写しが不正確だと検出結果も間違います）、TODO(1)の定数定義に落とします。次に check_violations（上限超過・領収書なし・申請不可科目の3種を検出）と format_report（件数と違反一覧の表示）の実装をCopilotに依頼します。実行は python3 check_expenses.py、外部ライブラリは不要です。
実行して違反が7件（上限超過3件・領収書なし3件・申請不可科目1件）検出されれば完了です。3,000円未満の交通費の領収書なし（E007・E022）を違反にしていたら、規程の例外を読み落としています。生成物は challenges/expense-check/check_expenses.py に上書き保存します。ヒントは hints/challenge04_expenses_hint.md にあります。
検出結果を画面表示だけでなく 違反レポート.csv としても書き出し、申請者ごとの違反件数サマリを末尾に付けてみてください。余力があれば「同一申請者・同一日付・同一金額の重複申請」を疑わしい申請として警告する第4のチェックを、自分で規程文の文言から考えて追加すると、規程にない仕様を自分で決める難しさまで体験できます。
経費規程はWordにあり、Copilotは直接読めません。この課題は、AIが読めない資料のルールをいかに正確にプロンプトやコメントへ書き写すか、という実務そのままの工程を体験する回です。書き写しが不正確なら検出結果も間違います。第2条の例外規定を読み落とすと、3,000円未満の交通費の領収書なしまで違反にしてしまう、という具体的な失敗が仕込んであります。AIに渡せる形に自分で整える、という一手間が、当日の業務でAIを使えるかどうかの分かれ目になります。
docxから読み取ったルールをファイル冒頭に箇条書きコメントで書いてから、関数単位で範囲選択して実装を依頼します。Copilotは同じファイル内のコメントを文脈として読むので、毎回プロンプトに全ルールを書くより安定します。例外規定は「ただし〜の場合は不要」と原則とセットで1文に書いてください。
定数の値を渡さず依頼すると、Copilotはそれらしい上限金額を勝手に置きます。生成された数値は必ず経費規程.docxの原文と突き合わせてください。違反が7件を超えたら第2条の例外の読み落としを疑い、E007とE022が一覧に混ざっていないかを確認します。
Copilot Chatの入力欄で #file と打って経費明細.csvを添付すると、列名や「あり」「なし」の表記を実データに合わせた実装が返りやすくなります。docxは添付できないため、規程だけは自分の箇条書きで渡すのがこの課題の要点です。適用前に比較演算子が「超」か「以上」かを差分で確認してください。
一日を通して扱った「問いを立て、出力を評価し、責任を持って取り込む」という流れを、自分の業務に引き寄せて言葉にします。
次の3点を、終了前に手元でメモしてください。明日からの業務で、今日の進め方をどこに当てはめられそうかを具体化するためのものです。
今日、原因に近づけた問いはどんな形だったか。文脈・制約・出力形式のどれが効いたか。
AIの提案で、評価して却下した・直させたものは何か。どう気づいたか。
自分の担当業務で、エージェントモードや Chat を使えそうな場面を1つ挙げる。
配布フォルダの振り返りシートに、この3点をそのまま書き出す欄があります。研修後に見返せるよう、具体的な場面の名前で書いておくのがおすすめです。