生成AIプログラミング入門編
VSCode と Claude Code で、動くアプリを自分の手で作る4時間
| Session | 内容 | 時間 |
|---|---|---|
| S01 | オリエンと支援の段階遷移 | [20min] |
| S02 | 座学とデモ | [40min] |
| S03 | ハンズオン 課題A（CRUD業務アプリ） | [70min] |
| S04 | ハンズオン 課題B（Java / Spring Boot）と発展 | [70min] |
| - | まとめとAI設計デモ | [20min] |
| S05 | 振り返りと質疑応答 | [20min] |
実施環境は VSCode × Claude Code（Amazon Bedrock 経由・Claude Sonnet 4.6）です。前半で AI 開発の威力を体験し、後半でその限界と、チーム開発に持ち込むための考え方まで進みます。
本研修のゴール
生成AIに日本語で指示して、動くアプリを自分の手で完成させる体験を持ち帰ります。あわせて、勢いだけで作ったときに何が起きるかまで自分の目で確かめます。
VSCode 上で Claude Code に指示を出し、テンプレートなしで CRUD 業務アプリを作る。バグ入りの Java / Spring Boot コードを AI と一緒に読み解き、Issue 駆動で修正する。この2つを 240 分で通します。
Claude Code クロードコードAnthropic 社が提供する開発支援 AI です。本研修では VSCode の拡張として使い、日本語の文章で指示すると、関連ファイルを自分で探し、複数ファイルをまたいで編集し、動作確認まで進めます。接続先は Amazon Bedrock 上の Claude Sonnet 4.6 です。
進め方と最初の確認
つまずきは冒頭で解消します。まず全員の VSCode と Claude Code が起動するところまで、この場で確認します。
いま確認すること
- VSCode が起動する
- 配布フォルダ（ZIP を展開したもの）が開ける
- Claude Code のパネルが表示される
- 短い指示に応答が返る（接続確認）
今日のルール
AI支援の段階遷移 — 補完から対話委任へ
コードを書く AI の支援は、この数年で「一行の続きを埋める」から「タスクごと任せる」へ段階的に移ってきました。今日扱うのは右側の段階です。
本研修は段階3の体験に集中します。段階4（規約や自動検証を仕込んだチーム運用）は、最後の AI 設計デモで入り口だけ見せ、第2回で本格的に扱います。
AIコーディングの現在地
生成AIでコードを書くことは、もう珍しい取り組みではありません。一方で、出てきたコードをそのまま信じてよいわけでもありません。
広がっている使い方
- 新規画面やちょっとしたツールの下書きを AI に任せる
- 既存コードの読解・説明・コメント付けを頼む
- エラーメッセージを貼って原因を探させる
- テストデータやドキュメントの生成
AIが得意なこと・任せ方
ツールの地図 — 本研修は Claude Code を使う
コードを書く AI ツールは形態別に整理すると見通しがよくなります。比較はここで一望し、以後は Claude Code に集中します。
| 比較軸 | Claude Code | GitHub Copilot | Cursor |
|---|---|---|---|
| 形態 | VSCode 拡張 / ターミナルで動くエージェント | VSCode 拡張（補完＋チャット） | エディタ一体型 |
| 主な使い方 | タスクを言葉で渡して自走させる | 入力中の補完と対話 | 補完と対話 |
| 規約ファイル | CLAUDE.md | copilot-instructions.md | .cursor/rules |
| 本研修での扱い | 主役。全セッションで使う | 名称のみ紹介 | 名称のみ紹介 |
エージェント agent一文の指示から、関連ファイルを自分で探し、複数の場所を編集し、実行して結果を確かめ、エラーが出たら直す、という一連の作業を続けて進める働き方です。補完のように一行ずつ提案するのとは役割が違います。
Amazon Bedrock ベッドロックAWS 上で各社の AI モデルを利用できるサービスです。本研修の Claude Code は Bedrock 経由で Claude Sonnet 4.6 に接続します。操作は通常の Claude Code と同じで、接続先だけが違います。
同じ目的でも、指示で結果が変わる
AI への指示は「注文」です。何を・なぜ・どう確かめるかが入っているほど、意図に近い結果が返ります。
曖昧な指示
- どの項目で検索するかを AI が勝手に決める
- 部分一致か完全一致かが運任せになる
- 結果が0件のときの表示が考慮されない
意図が伝わる指示
- 仕様のブレが減り、やり直しが減る
- 「変えないでほしい部分」を先に守れる
「何を（対象と完成条件）＋ どう（制約と例外時の挙動）＋ 触らないでほしい部分」。この3点を意識すると、初心者でも指示の質が安定します。ハンズオン中もこの型に戻ってください。
VSCode での Claude Code 基本操作
操作はシンプルです。パネルを開き、日本語で話しかけ、提案された変更を確認して承認する。このサイクルの繰り返しです。
@ファイル名 で対象ファイルを明示できます。「どこを直すか」を人が示すと精度が上がります。Plan モードと Agent モード
Claude Code には「先に計画だけ立てる」モードと「編集まで進める」モードがあります。使い分けが今日いちばん大事な操作です。
| Plan モード | Agent モード | |
|---|---|---|
| 動き | ファイルを読み、変更の計画だけを提示する。ファイルは編集しない | 計画にもとづいてファイルの編集・実行まで進める |
| 向く場面 | 変更範囲が広いとき、何をされるか先に知りたいとき | やることが明確で、小さく進めたいとき |
| 切り替え | 入力欄のモード表示から切り替えます（キーボードでは Shift+Tab） | |
| 今日の使い方 | 課題Bのバグ修正は Plan で計画を見てから直す | 課題Aの CRUD 構築は Agent でテンポよく作る |
課題A — CRUD業務アプリをテンプレートなしで作る
一覧が表示され、検索で絞り込め、1件選ぶと詳細が見える。この業務アプリを、雛形コードなしのまっさらな状態から Claude Code と作ります。
一覧画面 → 検索で絞り込み → 行をクリックして詳細表示、というドリルダウンが一通り動くこと。見た目の作り込みは不要です。まず全員が「動くもの」を持つことを優先します。
CRUD クラッドCreate（作成）・Read（参照）・Update（更新）・Delete（削除）の頭文字で、業務アプリの基本操作を指します。今日はこのうち参照系（一覧・検索・詳細）を中心に作ります。
環境確認 — 最初の1指示を全員で
いきなり作り始める前に、短い指示を1つ全員で実行し、操作のリズムとつまずきをここで解消します。
手順
kadai-a を VSCode で開きます。中は空に近い状態です（題材の説明ファイルだけがあります）。index.html をブラウザで開き、表示を確認します。OK基準
- Claude Code が応答を返した
- ファイルが作成され、差分の承認ができた
- ブラウザで表示を確認できた
この3つが通れば、以降の課題はすべて同じ操作の延長です。逆にここで詰まったまま先へ進むと後で必ず止まるので、遠慮なく挙手してください。
課題Aの進め方 — 3段階で積み上げる
一気に全部を頼まず、一覧 → 検索 → 詳細の順に1段ずつ作って動作確認します。小さく作って確かめるリズムが、そのまま実務の型になります。
| 段階 | 作るもの | 指示のポイント | OK基準 |
|---|---|---|---|
| Step 1 | 一覧画面 | 題材のデータ項目を伝え、サンプルデータ込みで一覧表を作らせる | ブラウザで一覧が表として表示される |
| Step 2 | 検索 | 検索対象の項目・部分一致・0件時の表示を指定する | 入力に応じて一覧が絞り込まれる。0件表示も出る |
| Step 3 | 詳細ドリルダウン | 行を選ぶと全項目が見える詳細表示。一覧へ戻る導線も指定する | 一覧 → 詳細 → 一覧の往復ができる |
登録フォーム（Create）や削除（Delete）の追加、並び替え、件数表示など、自分の業務で欲しい機能を足してみてください。指示の型は同じです。
完成したアプリを、AI自身に点検させる
動いた。ここで終わらせず、いま作ったアプリの危険な箇所・曖昧な箇所・Warning を、作った本人である AI に指摘させます。
よく挙がる指摘の例
- 入力値をそのまま画面に出している（XSS の温床）
- 検索の大文字小文字や空白の扱いを勝手に決めていた
- データが増えたときの表示や性能を考慮していない
- エラー時にユーザーへ何も知らせない
この体験の意味
数十分で動くものが作れた一方、その中には AI が勝手に決めた仕様と、指摘されるまで気づかない穴が残っています。速さの裏で何が起きているかを、自分の生成物で確かめるのがこの時間の目的です。
Warning 警告エラーではないものの、放置すると不具合や脆弱性につながりうる状態を知らせるメッセージです。動いていても Warning が残っていれば、内容を理解してから先へ進むのが安全です。
バイブコーディングの限界と、ハーネスが要る理由
いま体験した「勢いで指示して動くものを作る」進め方をバイブコーディングと呼びます。一人の試作では最強ですが、チーム開発に持ち込むと破綻します。
一人なら強い
- アイデアを数十分で動く形にできる
- 仕様の細部は動かしながら決められる
- 作り直しのコストが低い
チームだと破綻する
- AI が勝手に決めた仕様が人によってバラバラになる
- 命名・構成・書き方に一貫性がなく、他人が読めない
- 点検を人の善意に任せると、穴がそのまま本番に届く
ハーネス harnessAI の出力を一定の品質へ導くための枠組みの総称です。規約ファイル、決まった手順、自動チェックなどを組み合わせます。詳しくは今日の最後のデモと、第2回で扱います。
課題B — Java / Spring Boot のバグを Issue 駆動で直す
今度は他人が書いた（バグ入りの）既存コードが相手です。AI でコードを理解し、直すべき点を Issue として言葉にしてから修正する、実務に近い流れを体験します。
| フェーズ | やること |
|---|---|
| 1. 理解 | 配布された Spring Boot プロジェクトを AI に読ませ、コメント挿入と構成説明でソースを把握する |
| 2. 起票 | 見つけたバグ・修正点を Issue テンプレートに沿って言葉にする（起票練習） |
| 3. 修正 | 自分の Issue を2〜3個選び、Issue 駆動で約20分かけて修正・動作確認する |
Spring Boot スプリングブートJava で Web アプリや API を作るときに広く使われるフレームワークです。今日は書けなくて構いません。読んで直す側に回るための道具として AI を使います。CI/CD などの自動化は本研修では扱いません。
まず読む — AIにコメントを入れさせて構造を掴む
知らないコードをいきなり直すのは危険です。最初の仕事は理解で、ここが AI のいちばん得意な領域です。
手順
kadai-b を VSCode で開き、Claude Code に全体構成を説明させます。OK基準
- アプリが何をするものか、自分の言葉で言える
- 主要クラスの役割分担が説明できる
- 怪しい・引っかかる箇所を1つ以上見つけた
目的は完全な解析ではなく、直すために必要な範囲の理解です。「どこに何があるか」と「怪しい箇所の当たり」が付けば十分です。読解に時間を使いすぎないでください。
Issue 駆動開発 — 直す前に、言葉にする
見つけた問題をいきなり直さず、まず Issue（課題票）として言葉にします。本研修では配布フォルダ内の Markdown ファイルとして起票します。
Issue テンプレート（配布済み）
## 概要 （何が起きているか、1〜2行） ## 再現手順 1. ○○画面を開く 2. △△を入力して実行する ## 期待する動作 （本来どうなるべきか） ## 実際の動作 （いま何が起きるか） ## 修正方針（分かる範囲で） （どのファイルのどこが原因か、仮説でよい）
なぜ言葉にしてから直すのか
まず1件、見つけた問題をテンプレートに沿って issues/issue-01.md として書いてみてください。再現手順が書けない場合は、AI に「この問題の再現手順を整理して」と頼んで構いません。
Issue 駆動で修正する — 2〜3件を約20分で
自分が起票した Issue から2〜3件を選び、1件ずつ「Plan で計画 → 修正 → 動作確認」を回します。
1件あたりの進め方
OK基準
- 2件以上の Issue を起票できた
- 2件以上を修正し、動作確認まで通した
- 修正内容を自分の言葉で説明できる
AI の「修正しました」は完了の宣言であって証明ではありません。必ず再現手順をなぞり直して、期待する動作に変わったことを自分の目で確認してください。確認までがこの演習です。
発展 — エージェントの進化とハルシネーション
今日体験した「委任」の先で何が起きているか、そして任せるときに必ず知っておくべき AI の弱点を押さえます。
AIエージェントの発展
- 1指示で計画 → 実装 → テスト → 修正まで自走する範囲が広がっている
- 複数のエージェントが役割分担して並行作業する構成も実用段階
- それでも「何を作るべきか」「出力を採用するか」の判断は人に残る
自走する範囲が広がるほど、事前に渡す規約・知識・手順の質が結果を左右します。これが次のコンテキストエンジニアリングの話につながります。
ハルシネーションの具体例
- 対策1: 出力は仮説として扱い、実行・ログ・公式ドキュメントで裏を取る
- 対策2: 「分からなければ分からないと言って」と指示に添える
- 対策3: 重要な判断ほど、根拠となるコードや出典を出させる
今日の総括 — バイブコーディングの強みと弱み
課題Aで威力を、課題Bで規律を体験しました。両方を一枚で振り返ります。
| 体験したこと | そこから言えること | |
|---|---|---|
| 課題A（威力） | テンプレートなしから数十分で一覧・検索・詳細が動いた | 定型的な業務アプリの立ち上げは、もう人が一から書く仕事ではない |
| 課題A（限界） | AI 自身に点検させたら、勝手に決めた仕様と穴が出てきた | 速さの裏で品質は運任せ。動いた ≠ 正しい |
| 課題B（規律） | Issue に言葉で固定してから直すと、AI の修正が範囲内に収まった | 先に言葉と枠を与えるほど、AI は安定して働く |
ではチームとして、この「先に与える言葉と枠」をどう用意するか。それがコンテキストエンジニアリングと、これから見せるハーネスの設計です。
コンテキストエンジニアリング — AIに渡す知識を整える
AI の出力の質は、モデルの賢さより「何を渡したか」で決まる場面が多くあります。会社のナレッジや個人の暗黙知を、AI が読める形に整えておく仕事がコンテキストエンジニアリングです。
整えて渡すものの例
- コーディング規約・命名ルール（例:
CLAUDE.mdに記載） - 業務用語集とデータ項目の定義
- 「このシステムではこうする」という過去の判断とその理由
- やってはいけないことのリスト（触ってはいけないファイル、禁止パターン）
コンテキスト contextAI が応答を作るときに参照する文脈情報のことです。指示文だけでなく、開いているプロジェクトのファイルや規約ファイルもコンテキストになります。
チームでの運用
設計思想 — コンテキスト → ハーネス → ループ
チームで AI を安定して働かせる設計は、この3層で考えると整理できます。今日の体験はすべてこの図の上に載ります。
課題Aの点検指示は簡易的なハーネス、課題Bの Issue テンプレートはコンテキストとハーネスの中間にあたります。第2回では、これをチームの仕組みとして本格的に組み上げます。
デモ — 1コマンドから Skills / Subagents を自動選択
仕込みが整った環境で AI がどう働くか、講師の環境で実演します。人が出すのは1つのコマンドだけです。
デモで見せる流れ
Skill スキル特定の作業の手順・品質基準・雛形をまとめたパッケージです。AI はタスクに合う Skill を選んで読み込み、その手順に沿って作業します。ベテランの仕事の型を配る仕組みと考えてください。
Subagent サブエージェント役割を限定した子の AI です。調査係・実装係・レビュー係のように分担させると、1体で全部やるより速く、間違いも見つかりやすくなります。
注目してほしいのは出力の見事さではなく、人が介入していない区間の長さです。介入せずに任せられる範囲は、事前の仕込みの量で決まります。
振り返り — 今日できるようになったこと
最後に、今日の体験を自分の言葉にします。次の4つの問いに、手元のメモで答えてみてください。書けたものが、明日から現場で使える持ち帰りです。
明日からの最初の一歩の例
- 読み慣れないコードやファイルの説明を頼む
- 手元の繰り返し作業を小さなツールにしてもらう
- エラーメッセージを貼って原因の仮説を出させる
研修では自由に入力できましたが、実務でのソースコード・本番データ・顧客情報の入力可否は、所属組織のセキュリティポリシーと AI 利用ガイドラインに従って判断してください。
この後は質疑応答の時間です。今日の操作でも、実務への持ち込み方でも、何でも聞いてください。
本日はおつかれさまでした
最後にアンケートへのご協力をお願いします。今日の内容と、第2回で扱ってほしいテーマをぜひお聞かせください。
指示を言葉にし、計画を確かめ、生成物を点検する。今日手に馴染ませたこの型が、そのまま現場での AI 活用の出発点になります。