研修生成AIプログラミング入門編
VSCode 上の Claude Code で、自然言語の指示だけから業務アプリを立ち上げる体験と、既存の Java プロジェクトを Issue 駆動で修正する体験の2本を、この1ページに沿って進めます。 前半の課題Aでは一覧・検索・詳細ドリルダウンのアプリをテンプレートなしで作り、完成後に危険な点を AI 自身に指摘させます。後半の課題Bではバグ入りの Spring Boot プロジェクトを AI で読み解き、Issue を起票してから直します。 各ステップは「自分で考える → 指示を書く → 実行する → 答え合わせ」の4段で進みます。まず自分の言葉で指示を組み立ててから、hints の参考プロンプトと突き合わせてください。
AI の基礎理論には踏み込みません。VSCode のターミナルで Claude Code に自然言語で指示し、動くものを作る・既存コードを理解する・Issue 単位で直す、という手元の動きに範囲を限定します。作って終わりではなく、生成物の危険な点を確かめる目線までを持ち帰ります。
ターミナルでの claude 起動、自然言語での指示、@ でのファイル参照、Plan モード(Shift+Tab 2回)での計画確認と Agent モードでの実行を、場面で使い分けます。
要件(お題シート)と元データ(CSV)だけを渡し、一覧→検索→詳細の業務アプリをゼロから立ち上げます。一気に頼まず、動く最小形から積み上げる指示の出し方を体験します。
初見の Spring Boot プロジェクトに日本語コメントを挿入させ、画面と処理の流れを短時間で掴みます。読めないコードを前に止まらない読み方を覚えます。
見つけた不具合を Issue(ローカルの Markdown ファイル)として起票し、Issue 1件ずつを AI に渡して修正します。勢いだけのバイブコーディングとの違いを自分の手で確かめます。
前半は勢いよく作る楽しさに振り、後半でその限界に自分でぶつかってもらう構成です。AI の出力は同じ指示でも毎回ばらつきます。隣の人と画面が違っても正常です。各ステップの OK 基準を満たしていれば正解と考えてください。
前半で座学とデモ、中盤からハンズオン2本、最後にまとめのデモと振り返りです。各セッションは[Nmin]で配分しています。
| Session | 内容 | 時間 |
|---|---|---|
| 01 | オリエンと支援の段階遷移 — ゴール共有、VSCode と Claude Code の起動確認、補完から対話委任までの位置づけ | [20min] |
| 02 | 座学とデモ — AIコーディングの現在地、VSCode での基本操作、Plan モードと Agent モードの使い分け | [40min] |
| 03 | ハンズオン 課題A — CRUD業務アプリをテンプレートなしで構築、完成後に危険性を AI に指摘させる | [70min] |
| 04 | ハンズオン 課題B — Java / Spring Boot のコメント挿入とソース理解、Issue 起票、Issue 駆動のバグ修正 | [70min] |
| - | まとめとAI設計デモ — バイブコーディングの強み弱み、コンテキストエンジニアリング、ハーネス動作のデモ | [20min] |
| 05 | 振り返りと質疑応答 | [20min] |
Session 03 と 04 のハンズオン中は、このページを手元に置いて上から順に進めてください。各ステップの参考プロンプトと詰まり対処は配布素材の hints/ フォルダにあります。まず自分で指示を考え、行き詰まったら hints を開く、の順で使うと身につきます。
配布した handson フォルダに、課題A・課題Bの素材と参考プロンプト一式が入っています。課題ごとに開くフォルダが変わる点に注意してください。課題Aは kadaiA、課題Bは kadaiB を VSCode で開きます。
配布素材に含まれるソースコード・備品データ・不具合はすべて研修用に用意した架空のものです。研修中は Claude Code への入力を自由に行えます。実業務でのお客様コードや本番データの入力可否は、所属組織のセキュリティポリシーと AI 利用ガイドラインに従って判断してください。
Claude Code への指示だけで、備品データ50件を扱う一覧・検索・詳細ドリルダウンの業務アプリをゼロから作ります。雛形もサンプルコードもありません。要件は kadaiA/docs/お題シート.md、データは kadaiA/dummy_data.csv です。全員が動くものを完成させることを最優先にし、仕上げに危険な点を AI 自身に指摘させます。
各ステップ共通の進め方です。指示文を先に自分で組み立て、実行して結果を見てから、hints の参考プロンプトと見比べます。参考プロンプトを最初に写すと、指示を設計する力がつきません。
handson/kadaiA(VSCode でこのフォルダを開く)全員で同じ1指示を実行し、Claude Code が動くことと操作のリズムを確認します。ここでのつまずきは遠慮なく挙手して解消してください。以降の70分がスムーズになります。
Claude Code がフォルダ内のファイルを読み、日本語で応答するまでの一連の動きを体験します。
kadaiA フォルダを開きますclaude と入力して起動しますdummy_data.csv の内容を説明させる指示を、自分の言葉で入力します「何が」「何件」「どんな項目で」入っているかを AI に答えさせるには、どんな日本語で頼めばよいでしょうか。続けて、カテゴリごとの件数を表で出させる指示も考えてみてください。
この段階ではファイルは作りません。ターミナル上の応答(データの説明と集計表)が成果です。
ファイルを読むだけの依頼と、集計する依頼で AI の動き方がどう違ったかを見比べてください。隣の席と出力の言い回しが違うのも正常です。生成は毎回ばらつきます。
参考プロンプトと詰まり対処は hints/step01_first_prompt.md(handson 直下の hints フォルダ)を参照してください。
kadaiA/docs/お題シート.md / 元データkadaiA/dummy_data.csv課題Aの本編です。お題シートの要件(一覧・備品名の部分一致検索・詳細ドリルダウン・一覧へ戻る)を満たすアプリを、Claude Code への指示だけで作ります。技術スタックは自由です。迷ったら「ブラウザで開くだけで動く形にしてください」と添えると、環境構築なしで確認できます。
自然言語の指示だけで動く業務アプリが立ち上がる体験を通じて、AIコーディングの威力と、指示の分割の仕方を掴みます。
docs/お題シート.md を開き、3つの画面要件と「変えないこと」を確認しますお題シートの要件を、どの順番で・どこまで一度に頼むかを自分で設計してください。全部を1指示に詰め込む場合と、3回に分ける場合で結果がどう変わるかも試す価値があります。
kadaiA フォルダ直下にアプリ一式を生成させます。メインの画面ファイルは index.html(または起動手順が README に書かれた形)とします。dummy_data.csv は移動・削除・書き換えをしないでください。
生成中の画面を眺め、AI がどんなファイルをどんな順で作るかを観察してください。承認を求められたら、差分を読んでから承認する癖をここでつけます。
参考プロンプトと詰まり対処は hints/step02_crud_build.md を参照してください。
生成が途中で止まったら「続けてください」で再開できます。見当違いのものができたら、直してほしい箇所だけを具体的に伝えます。Plan モード(Shift+Tab を2回)に切り替えると、実装前に計画を確認してから進められます。
docs/セキュリティチェックリスト.md(handson 直下の docs フォルダ)完成したアプリの危険な点・曖昧な点・Warning になりそうな点を、作った本人である AI に指摘させます。作っている最中は何も警告しなかった AI が、聞かれれば山ほど挙げる。ここに勢いだけで作るバイブコーディングの限界が表れます。
「動くこと」と「安心して使えること」の距離を自分の目で確認し、チーム開発でルール(ハーネス)が要る理由を体感します。
AI の指摘を docs/セキュリティチェックリスト.md と突き合わせ、AI が挙げなかった項目がないかを探してください。AI のセルフレビューにも抜けがあります。
ターミナル上の指摘リストが成果です。余裕があれば、指摘を kadaiA/review_memo.md として保存させると振り返りに使えます。
なぜ AI は作っている最中に警告しなかったのでしょうか。指示に品質の観点が含まれていなければ、AI は「動くもの」を最短で作ります。この観点をあらかじめ渡しておく仕組みが、後半とまとめで扱うハーネスです。
参考プロンプトと詰まり対処は hints/step03_warning_check.md を参照してください。
題材は備品管理システム(Java 17 / Spring Boot 3.4 / H2 インメモリDB / Thymeleaf)。意図的な不具合が仕込まれています。初見のコードを AI で読み解き、見つけた不具合を Issue として書き、Issue 1件ずつを AI に渡して修正します。Git や GitHub は使いません。Issue は kadaiB/issues/ フォルダの Markdown ファイルです。
| ステップ | 内容 | 時間 |
|---|---|---|
| B-1 | コメント挿入とソース理解 | [25min] |
| B-2 | Issue 駆動開発の説明と起票練習 | [20min] |
| B-3 | Issue 駆動でバグを修正する | [25min] |
VSCode で kadaiB フォルダを開き、ターミナルで Mac は ./mvnw spring-boot:run、Windows PowerShell は .\mvnw.cmd spring-boot:run を実行します。初回はライブラリのダウンロードで数分かかります。起動後にブラウザで http://localhost:8080/equipments を開きます。停止は Ctrl+C です。
handson/kadaiB / 中心ファイルsrc/main/java/com/example/equipment/service/EquipmentServiceImpl.java初見のプロジェクトを、AI に日本語コメントを入れさせながら読み解きます。構成は controller → service(インターフェース)→ serviceImpl → repository → model の流れです。自分で全部読まなくても、AI に説明させれば処理の流れは短時間で掴めます。
既存コードの理解に AI を使う型(全体像 → 中心ファイル → 動作確認)を身につけます。
EquipmentServiceImpl.java の各メソッドに、意図がわかる日本語コメントを追加させます(ロジックは変更させない)「ロジックは変えずにコメントだけ足す」を守らせるには、指示にどんな一文が要るでしょうか。制約を明示しない指示と比べてみてください。
日本語コメントが入った EquipmentServiceImpl.java。ファイルの場所は変わりません。
README の「業務ルール」5項目を読み、画面の実際の挙動と食い違う箇所の当たりをつけてください。この食い違いが次のステップで起票する不具合です。
参考プロンプトと詰まり対処は hints/step04_comment_insert.md を参照してください。
kadaiB/issues/ISSUE_TEMPLATE.md / 記入例kadaiB/issues/ISSUE_001_詳細画面がエラーになる備品がある.md
Issue とは、不具合や修正したいことを1件ずつ独立した文書にしたものです。チーム開発では「誰が見ても再現でき、直ったかどうか判定できる」粒度で書かれた Issue が作業の単位になります。本研修では issues/ フォルダの Markdown ファイルとして起票します。
「なんか変」を、再現手順・期待する動き・実際の動きに分解して書けるようになります。
ISSUE_TEMPLATE.md の形式で issues/ に起票します(例: ISSUE_002_内容がわかる名前.md)README の業務ルール5項目が探索の地図です。「在庫5個以下は要補充表示」「在庫を0未満にしない」「日付は yyyy/MM/dd」「存在しないIDはエラー画面にしない」「備考未設定でも詳細が表示される」。仕様と挙動の食い違いを自分の操作で再現してから書きます。
kadaiB/issues/ISSUE_00N_内容がわかる名前.md を2件以上。
不具合探しを AI に手伝わせることもできます。ただし AI の挙げた候補は、必ず自分の操作で画面上に再現してから起票してください。再現できない指摘は Issue になりません。
起票のヒントは hints/step05_issue_driven.md の前半を参照してください。
kadaiB/issues/ の Issue起票した Issue を1件選び、その Issue だけを AI に渡して修正させます。課題Aの「思いつきで指示する」進め方との違いは、修正の根拠と完了条件が文書に固定されていることです。直ったかどうかは Issue の再現手順で自分が判定します。CI/CD は扱いません。
Issue を1件ずつ渡し、修正 → 再現手順で確認 → 次へ、というチーム開発の基本サイクルを回します。
@ でその Issue ファイルを参照させて修正を依頼します複数の不具合を一度に全部直させる指示と、Issue 1件ずつの指示で、差分の読みやすさと確認のしやすさがどう変わるかを意識してください。
修正済みのソースコード(kadaiB/src/ 配下)。修正した Issue ファイルの末尾に「修正済み・確認日」を追記しておくと管理の練習になります。
修正の途中で別の不具合に気づいたら、その場で直さず新しい Issue として起票します。1つの修正に1つの目的。これが崩れると、何を直したのか誰にもわからなくなります。
docs/コーディング規約.md に照らしてレビューさせる参考プロンプトと詰まり対処は hints/step05_issue_driven.md を参照してください。
ハンズオン後の座学とデモで扱う内容です。手を動かす場面はありませんが、今日の2つの体験がどうつながるかを掴む時間です。デモを見るときの観察ポイントを挙げておきます。
AI は存在しない API や設定を、正しそうな顔で出力することがあります。課題Bで「AI の指摘は自分の操作で再現してから起票する」と決めていたのは、この対策そのものです。
会社のナレッジや個人の暗黙知を、AI が読める形(規約・チェックリスト・CLAUDE.md)に整えておく考え方です。配布素材の docs/ と CLAUDE.md がその実例です。
整えた文脈(コンテキスト)を、毎回自動で効かせる仕組み(ハーネス)に載せ、生成 → 検証 → 修正を回し続ける(ループ)。チーム開発で AI を安全に速く使う設計思想です。
今日使った対話型の先には、複数の専用エージェントが分担して動く形があります。まとめのデモで実物を見ます。
デモでは、1つのコマンドから必要な Skills や Subagents を AI が自分で選択して呼び出し、質の高い出力に至るまでを見せます。次の3点を意識して見てください。
課題Aで体験した「速いが危うい」と、課題Bで体験した「文書を挟むと確実になる」。この2つの間を埋めるのがハーネスです。次回以降の研修では、この仕組みを自分たちで作る側に回ります。
VSCode と Claude Code、課題Bの起動まわりでつまずきやすい点をまとめます。解消しないときは挙手してください。
VSCode のターミナルで claude --version を実行し、バージョンが表示されるか確認します。表示されない場合は事前セットアップガイドの手順を見直してください。本研修は Amazon Bedrock 経由の接続設定を使うため、設定ファイルの場所もガイドに記載があります。
生成が途中で止まったら「続けてください」で再開できます。文脈が膨らんで重いときは /compact で要約圧縮、話題を切り替えるときは /clear でリセットします。
Plan モードへの切り替えは Shift+Tab を2回です。IME が日本語入力の状態だと効かないことがあるので、半角英数に切り替えてから試します。指示が思ったファイルに届かないときは @ で対象を明示します。
作り直しを頼むより、「ここをこう変えてください」と差分で伝えるほうが速く確実に直ります。同じ指示でも出力は毎回ばらつくため、隣の席と画面が違うのは正常です。OK 基準を満たしていれば正解です。
java -version で 17 と表示されるか確認します。Windows PowerShell では .\mvnw.cmd spring-boot:run と先頭の .\ を忘れずに入力します。初回はライブラリのダウンロードで数分かかるため、エラーでなければそのまま待ちます。
前回起動したアプリが残っている可能性があります。起動したターミナルで Ctrl+C を押して停止するか、ターミナルごと閉じてから起動し直します。
http://localhost:8080/h2-console を開き、JDBC URL に jdbc:h2:mem:equipmentdb、ユーザー名 sa、パスワード空欄で接続します。既定値の jdbc:h2:~/test のままだと繋がりません。
研修後の自習に使える公式情報です。