HANDS-ON TRAINING

VS Code × GitHub Copilot
AI駆動開発研修

メモ1枚から仕様書、Agent MD、Copilot制御まで。上流工程の設計力とAI活用力を身につける4.5時間。

2026年4月18日(金)
9:30 - 15:00(4.5時間)
オンライン
VS Code × GitHub Copilot
環境準備

研修を始める前に、以下の環境が整っていることをご確認ください。ハンズオンで使う素材は一括でダウンロードできます。

ZIP内に議事メモ、Agent MDテンプレート、サンプルCSV、.github フォルダ一式(copilot-instructions.md + カスタムプロンプト5種)が含まれます。VS Codeで展開したフォルダを開けば、そのまま研修を始められます。

タイムテーブル
00:00

Session 01 : オープニング10分

研修ゴールと全体マップ / 環境チェック / GitHub Copilotの基本操作確認 / AI駆動開発の全体像

00:10

Session 02 : コンテキスト設計と仕様駆動開発100分

設計思想(文脈設計・仕様駆動) / ライブデモ(要件抽出・Markdown構造化・コメントドリブン) / 仕様書作成演習

01:50

Session 03 : Agent MD × GitHub Copilot制御100分

Agent MDの設計 / ハーネスエンジニアリング / 適用前後の比較 / 最新制御手法 / 自チーム用MD作成ハンズオン

03:30

Session 04 : まとめと今後の展望40分

振り返り / バイブコーディング / エージェンティックエンジニアリング / 安全運用 / Claudeの怒涛の進化 / Claude Code・Cursor・Kiro

04:10

質疑応答 + 閉会20分

Session 01
オープニング

研修の全体像を把握し、手元の環境が動くことを確認します。この10分で全員のスタートラインを揃えます。

01 研修のゴール

今日の4.5時間で「メモ1枚を起点に、仕様書を書き、Agent MDを整備し、GitHub Copilotの出力品質をチーム単位で制御する」までの一連の設計フローを自分の手で体験します。持ち帰るのは構造化された仕様書とAgent MD、そしてそれを支える「型」そのものです。

議事メモ
仕様書
Agent MD
実装
テスト
AIレビュー
02 AI駆動開発の全体像

AI駆動開発とは、生成AIをコーディングアシスタントとして使うだけでなく、上流工程の設計段階からAIを組み込む開発手法です。

従来のAI活用

コードを書かせる

チャットで質問し、出力をコピペする。出力品質はプロンプトに依存し、毎回バラつきます。

AI駆動開発

文脈を設計して制御する

仕様書やAgent MDで文脈を事前に構造化し、AIの出力を再現可能な形で安定させます。チーム全員の生産性が底上げされます。

03 環境チェック

以下の4つが動作する状態を確認してください。問題があれば講師にお声がけください。

Tip : Copilot拡張が灰色の場合

VS Code右下のCopilotアイコンが灰色(無効状態)のときは、アイコンをクリックして「Enable Globally」を選択してください。それでも有効にならない場合は、VS Codeの拡張機能パネル(Ctrl+Shift+X)で「GitHub Copilot」「GitHub Copilot Chat」の2つがインストール済みかを確認し、「Reload Required」と出ていればウィンドウを再読み込みしてください。

python が通らない場合

python3 --version を試してください。動けば以降の手順は python を python3 に読み替えます。Windowsで python がMicrosoft Storeを開く場合は、Python公式サイトからインストーラーを入れ直すか、VS Codeターミナルのシェル種別を確認してください。

04 GitHub Copilot の基本操作
GitHub Copilot

本研修で使う3つの機能を確認します。Copilot Chat のモデルは Claude Sonnet 4.6 または Claude Opus 4.6 を使用します。チャット画面上部のモデル選択ドロップダウンから切り替えてください。

機能起動方法(Windows)起動方法(Mac)用途
Copilot ChatCtrl + Shift + ICmd + Shift + I対話形式でコード生成・質問・レビュー
インラインチャットCtrl + ICmd + I選択範囲のリファクタリング・説明
コード補完Tab で受け入れ / Esc でキャンセル入力中にリアルタイムでコードを提案
Tip

#file:ファイル名 でチャット内に特定ファイルの中身を渡せます。@workspace でリポジトリ全体を文脈に含められます。この2つを使いこなせるかどうかで出力品質が変わります。

@workspace のトークン消費に注意

@workspace はリポジトリ全体を文脈に渡すため、トークンを大量に消費します。ファイル数が多い大規模リポジトリでは応答が遅くなったり、文脈が溢れて精度が落ちることがあります。対象ファイルが明確な場合は #file: で個別に指定するほうが確実です。

05 Suggestions matching public code について

コード生成のハンズオンに入る前に、組織設定として確認しておきたい項目があります。GitHub Copilot の管理画面「Duplicate Detection Filter」にある Suggestions matching public code は、Copilot の提案コードが GitHub 上の公開リポジトリと一致した場合に、その提案を表示するかを制御する設定です。本研修環境は Blocked(ブロック)で運用されており、一致する提案は自動的に非表示になります。上位管理層・法務部門から「AI を使った開発で後々著作権問題が発生しないように」という要請を受けてブロックしているケースが多く、貴社の現行設定もこの考え方に沿ったものです。

設定値Copilot の挙動ライセンス上の位置づけ
Blocked公開コードと約 150 文字以上一致する提案は受講者に届かないコピーレフト系(GPL / AGPL 等)の混入リスクを組織側で遮断
Allow一致した提案も表示され、一致箇所と参照元リポジトリの URL が併記される提案採用時に開発者がライセンスを個別確認する運用が前提
Blocked を選ぶ理由を上長に説明するとき

業務コードに公開リポジトリ由来のコードが混入すると、元コードのライセンス条件(ソース公開義務、帰属表示、改変条件)が自社コードにまで波及します。一度混入すると静的解析だけでは完全に洗い出せず、法務・コンプライアンス観点で後戻りが難しい領域です。組織設定で最初から遮断しておけば、個々の開発者が毎回ライセンス判定をしなくて済むため、運用負荷と事故リスクの両方を下げられます。現在の Blocked 設定はこの予防策に沿ったものであり、AI 活用と知的財産保護を両立させる標準的な構成です。

ハンズオン中に「提案が出ない」と感じたら

本研修は Blocked 設定のまま進めます。Copilot の提案が期待より出ない、あるいは候補の一部だけ空白になる場面があれば、このフィルタで抑止されている可能性があります。プロンプト側を見直す手としては、要件を具体化する、#file: で文脈を明示する、自社ドメインの用語を含める、の 3 つが有効です。一般的な実装から離れて自社固有の実装方針に寄せるほど、公開コードとの一致を避けられ、結果的に Blocked 設定とも相性がよくなります。

設定場所と適用範囲

この設定は GitHub Copilot Business / Enterprise プランの組織管理画面(Settings → Copilot → Policies)で制御します。個人プラン(Copilot Individual)には組織レベルの管理画面はなく、ユーザー個人の Settings から同様の切り替えが可能です。受講者個人の権限では変更できない場合があるため、設定を見直したい場合は組織の GitHub 管理者に相談してください。本研修中に設定変更を行う必要はありません。

Session 02
コンテキスト設計と仕様駆動開発

GitHub Copilotの出力品質は渡す文脈で決まります。プロンプトの小手先テクニックではなく、AIに渡す情報の設計こそが生産性を分けるという話から始め、仕様を先に書いてAIに実装させる順番を体験します。

準備 ハンズオン共通ルール — 「どこに何を作るか」を最初に揃える

ここから先のTRY IT / HANDS-ONで迷わないよう、ファイルの置き場所と作り方を先に固定します。以降のステップで「新規ファイルを作る」「memo.md に書く」と出てきたら、このルールに従ってください。

ルール 1

作業フォルダ = 配布フォルダ 受講者配布/

VS Code で「フォルダーを開く」から 受講者配布/ を開き、常にこれをプロジェクトルートとして扱います。成果物・メモ・比較ファイルは全て、このフォルダ直下(またはその配下の所定サブフォルダ)に作ります。

ルール 2

考え・予想・気づきは memo.md に書く

各TRY ITの「考える(Step 1)」や「気づきを1行」では、プロジェクトルートの memo.md に追記します。未作成なら最初に作ります。体験ごとに見出し(## TRY IT 01 など)を切って書き足すだけでOK。

ルール 3

AIへのプロンプトは Copilot Chat に直接入力

プロンプト(AIへの指示文)はファイル保存せず、Copilot Chat(Ctrl+Shift+I / Cmd+Shift+I)に直接入力して実行します。比較したいプロンプトだけ memo.md にコピペで記録します。

ルール 4

新規ファイルの作り方

VS Code エクスプローラーでプロジェクトルートを右クリック → 「新しいファイル」 → ファイル名を入力(例: memo.mdpractice.py)。サブフォルダを切りたいときは「新しいフォルダー」を先に作成。ターミナル派は touch memo.md でも可。

成果物のファイル名 早見表

ハンズオンを通じて作るファイルを先にまとめておきます。場所はすべてプロジェクトルート直下.github/.kiro/ の配下は例外)。

ファイル名拡張子作るタイミング用途
memo.md.mdTRY IT 01 開始時全ての考え・予想・気づきを追記する「思考メモ」
practice.py.pyTRY IT 03コメントドリブン + インラインチャット体験用
spec.md.mdHANDS-ON 前半議事メモから起こす1枚ものの仕様書
.kiro/specs/sales_analysis_tool/フォルダHANDS-ON 後半(任意)Kiro方式3点分割(requirements / design / tasks.md)
_compare_no_agentmd.py.pyTRY IT 04Agent MDなしの出力を保存
.github/copilot-instructions.md.mdSession 03 HANDS-ON自チーム用 Agent MD
_compare_with_agentmd.py.pySession 03 HANDS-ONAgent MDありの出力を保存
_compare_vibe.py.pyTRY IT 06バイブコーディング版の出力
analyze.py.pyTRY IT 06 / 発展仕様駆動版の出力。発展ハンズオンで実行する
Copilot の出力をファイルに保存する標準手順

各ステップで「出力を ファイル名.py として保存」と出てきたら、以下の流れで進めます。

1. Copilot Chat の回答のコードブロック右上のコピーアイコンをクリック
2. VS Code エクスプローラーでプロジェクトルートを右クリック → 「新しいファイル」
3. ファイル名(例: _compare_no_agentmd.py)を入力して Enter
4. 開いたエディタに貼り付け(Ctrl+V / Cmd+V
5. 保存(Ctrl+S / Cmd+S

つまずいたときの最優先確認

「あれ、ファイルができない / 動かない」と感じたら、まずVS Codeの左上の「エクスプローラー」トップの表記で「受講者配布 が開いているか」を確認してください。ここがズレているとファイル作成位置もAgent MDもCopilot Chatの文脈も全部ずれます。迷ったらまずこの確認が最短です。

01 コンテキストエンジニアリングとは

AIの出力品質を決める3つの文脈層があります。プロジェクト設定(Agent MD)、開いているファイル群、指示の精度。この3つを設計するのがコンテキストエンジニアリングです。まず手を動かして、文脈の有無で出力がどう変わるか体感してください。

文脈層 1

プロジェクト設定(Agent MD)

copilot-instructions.md に書かれた規約・禁止事項。リポジトリに入れるだけでチーム全員のCopilotが従います。Session 03で詳しく扱います。

文脈層 2

開いているファイル群

VS Codeのタブに開いているファイルがCopilotの文脈に入ります。関連ファイルを開いておくだけで出力精度が上がります。#file: で明示的に渡すとさらに確実です。

文脈層 3

指示の精度

「何を」「どの形式で」「何を除外して」生成するか。制約指示が効くかどうかが出力品質の分かれ目になります。

TRY IT
体験 01 : 文脈なし vs 文脈ありで出力を比較する(10分)

同じ指示でも、渡す文脈で出力がまるで変わることを自分の手で確認します。この体験は4段構造で進めます。先に答えのプロンプトやファイル内容は開かず、自分で考えて書いてみてから答え合わせに入ってください。

1
考える(1分)

Copilot Chat にいきなり「議事メモからユーザーストーリーを抽出して」とだけ指示すると、Copilot は何を根拠にユーザーストーリーを返すと思いますか。予想してから手を動かします。

▸ 予想は memo.md## TRY IT 01 見出し下に1行書いてください。memo.md が未作成なら、プロジェクトルート(受講者配布/)を右クリック → 「新しいファイル」 → memo.md で作成。以降のTRY ITでも同じファイルに追記していきます(作成手順の詳細は冒頭の「ハンズオン共通ルール」参照)。

2
書く・実行 : 文脈なしで試す(2分)

Copilot Chat(Ctrl+Shift+I / Cmd+Shift+I)を開き、以下をそのまま貼り付けて送信してください。Chat に直接打ち込むだけでOK、ファイルには保存しません。#file: などでファイルを明示することもしません。

議事メモからユーザーストーリーを抽出してください
起こりうる3パターン

Copilot がこのあと取る行動は、状況で変わります。以下のどれかになっているはずです。

① 今開いているエクスプローラーから議事メモを自動で探して読み取る — 現在のGitHub Copilot(特にAgent Mode)では大半がこれ。研修環境のように対象フォルダを絞っていると、ほぼこの挙動になります。
② 「どの議事メモですか?」と質問を返してくる — 議事メモ系ファイルが複数あるとき、または該当ファイルが見つからないとき。
③ 架空の議事メモを自分で作って、その上でユーザーストーリーを返す — プロジェクトに関連ファイルが何もない、または曖昧な指示の時に稀に起きる。

今回の研修環境は配布フォルダ1つに絞っているので、ほとんどの方は①になったはずです。

ここで問題になるのは、「同じプロンプトでも、VS Codeで開いているファイル次第でAIが読み取る対象が変わる」という点です。①になった人の中でも、実際に読まれたのが docs/議事メモ_データ分析案件.md だったか、別のmdだったか、複数ファイルを横断したかは状況次第。明示しないとAIは「よしなに」やってくれますが、チーム全員で同じ結果が出ないのは本番運用では困りものです。

3
自分で文脈を足してみる(3分)

先に docs/議事メモ_データ分析案件.md をVS Codeエクスプローラーから開いて目で読んでください(左サイドバーで docs を展開 → ファイル名クリック)。そのうえで、Copilot が見るべきファイルを明示的に指定するプロンプトを自分で考えて書き、新しい Copilot Chat で送信します。書き方がわからなくても、自分なりの1回目を出してから次へ進んでください。

出力を Step 2 の結果と比べてください。AIが読みに行ったファイルの曖昧さが消えたか、出力の再現性が上がったかを観察します。

4
答え合わせと比較(4分)

自分のプロンプトと Step 2 / Step 3 の出力が手元に揃ったら、配布ファイルの hints/step01_context_hint.md を開いてください(エクスプローラーで hintsstep01_context_hint.md を開く)。参考プロンプトと比較観点が書いてあります。

▸ 気づきを1行、memo.md## TRY IT 01 見出し下に追記してください。

ここがコンテキストエンジニアリングの核

プロンプトの一文字も変えていません。変えたのは「AIが読むべきファイルを明示的に指定したかどうか」だけ。Step 2 の曖昧さ(①②③のどれにもなりうる)を、#file: で「必ずこのファイル」と固定する。この「文脈を暴れさせない設計」がチームで再現性を出す鍵です。Session 03 で扱う Agent MD は、この設計を常駐化する仕組みです。

copilot-instructions.md の設計思想は Claude Code の CLAUDE.md が原型です。エージェントモードも同じ系譜。GitHub Copilotの「新機能」として見るのではなく、AI開発ツールに共通する設計思想として理解すると、ツールが変わっても応用が利きます。

Claude Code
CLAUDE.md
GitHub Copilot
copilot-instructions.md
Cursor / Kiro
.cursor/rules 等
02 仕様駆動開発

仕様を書かずにいきなりコードを書かせると、AIは「動くが使えないもの」を量産します。メモから要件を抽出し、Markdownで構造化し、仕様書にまとめる。この工程を経てから実装に入ると手戻りが激減します。

73%
開発の手戻りの原因が
上流工程の不備
NIST 2002 調査
3日
仕様不備1件あたりの
平均修正コスト
1/5
仕様書があるときの
AI出力修正回数比
TRY IT
体験 02 : 制約を入れるかどうかで AI の出力はどこまで変わるか(8分)

同じメモでも、制約の有無で出力の輪郭が変わります。どの程度変わるかは、使っているモデル・チャット履歴・環境で幅が出ます。まず自分で試して差を観察してください。

1
考える(1分)

メモに書いてない要件を AI が補完する挙動には、どんなものがあるでしょうか。3つ予想してください(例: 認証、ログ、通知、ダッシュボード、多言語、バリデーション、スケジューラ、監視…)。

memo.md## TRY IT 02 見出しを追加し、その下に予想3つを箇条書きで記入。

2
書く・実行 : 制約なし版(2分)

新しい Copilot Chat を開き、以下をそのまま貼り付けて送信。制約を一切付けずに依頼します。出力はファイル保存せず、Chat 画面で読むだけで構いません。

以下の議事メモから、開発すべき機能の要件を整理してください。 # 議事メモ 営業企画部では売上CSVを手作業で集計している。月次報告のたびに3日かかる。 部門別・月別の集計と、地域ごとの構成比を出したい。Pythonで自動化する。 実行はコマンドラインから。GUIは不要。
観察のポイント

出力の性質は、使っているモデルや最近のやり取りで変わります。典型的には以下の幅で出ます。

A. メモに沿って要件を整理する — 最近の Copilot(Claude / GPT-5系)ではこれが増えました。大きな逸脱はない。
B. メモに書いてない要件を「親切」に補完してくる — ロギング、エラー通知、設定ファイル化、バッチスケジューラなど。
C. 実装詳細や運用ポリシーに踏み込んで返してくる — UI、認証、多言語、ダッシュボード等の「それメモに書いてないよ」案件。

多くの場合 A と B の中間に着地します。出力の中で「メモに根拠がある項目」と「ない項目」を、自分の目で仕分けてください。Step 1 で予想した3つとどこまで一致したかも確認します。

3
自分で制約を足してみる(2分)

Step 2 で B・C 寄りの出力が混ざっていたとします。AIの補完を自分の意図どおりに抑えるには、プロンプトにどう1行足しますか。自分の言葉で1〜3行の制約を追加し、新しい Copilot Chat で同じメモを渡して送信してください。参考解は次のステップまで開かない。

▸ 自分で考えた制約文を memo.md## TRY IT 02 見出し下に追記しておくと、後で比較しやすいです。

4
答え合わせと比較(3分)

自分で制約を書いた版と、制約なし版が手元に揃ったら、hints/step02_constraint_hint.md を開いてください。参考プロンプトと比較観点、「制約は短く決定的な1行が強い」という実務の勘所があります。

なぜ「たった1行」でも効くか

AIは、指示の曖昧さを「親切な補完」で埋めようとします。その挙動の強さはモデルや設定によりますが、「メモに書かれていない要件は追加しないでください」のように否定形で範囲を切ると、多くのモデルで有効に効きます。完全に止められるかはケースバイケースなので、人間が最後に仕分ける前提で運用するのが実務のスタンスです。

03 コメントドリブン開発

関数の上にコメントを先に書き、Copilotにコード補完させる手法です。仕様駆動開発の考え方をコードレベルに落とし込んだもの。実際にやってみてください。

TRY IT
体験 03 : コメントドリブンで Copilot を操縦する(10分)

コメント・型ヒント・関数名。Copilot のコード補完を動かす3つの軸のうち、どれが一番効くかを自分の手で確認します。

1
考える(2分)

Copilot は直前の情報を読んで次のコードを提案します。では、関数名だけ書くのと、コメントで仕様を書くのと、型ヒントを付けるのでは、どれが一番効くでしょうか。優先順位を予想してから次へ。

▸ 予想順を memo.md## TRY IT 03 見出し下に書いてください。

2
書く(3分)

プロジェクトルート(受講者配布/)に practice.py を新規作成します。VS Codeエクスプローラーでルートを右クリック → 「新しいファイル」 → practice.py と入力して Enter。開いたエディタに以下を貼り付けて保存(Ctrl+S / Cmd+S)。

def 行末にカーソルを置いて Enter。灰色のサジェストが出たら Tab で受け入れます。

import pandas as pd from pathlib import Path # 部門ごとの月別売上合計を算出する # 引数: DataFrame(売上データ) # 戻り値: 部門×年月の集計DataFrame # pandasのメソッドチェーンを使用する def aggregate_dept_monthly(df: pd.DataFrame) -> pd.DataFrame:

出てきたコードをよく見てください。pandas のメソッドチェーンになっていますか。

3
コメントを変えて再実行する(3分)

次の2つを自分で試します。各試行でCopilotの提案がどう変わったか、1行ずつメモしてください。

  • コメント3行目を # forループで集計する に書き換えて、関数本体を削除 → 再補完
  • 関数名を aggregate_dept_monthlycalc_sales_by_dept_and_month に変更 → 再補完
4
答え合わせと比較(2分)

3回分のメモが揃ったら、hints/step03_comment_driven_hint.md を開いてください。正解プロンプトはありません(コメントドリブンは自分で書き換えるもの)。観察のまとめ観点と、試す順序の推奨があります。

この practice.py は Session 03 の TRY IT 05 で再利用します。保存しておいてください。

Tip : Agent MDがあると精度がさらに安定する

型ヒント + コメント + 関数名の3点が揃うと Copilot の推測精度が跳ね上がります。Session 03 で扱う Agent MD で「型ヒント必須」「docstring は Google Style」を設定しておくと、この精度がさらに安定。詳しくは GitHub Copilot コード補完ガイド

HANDS-ON
仕様書を書く(30分・前半素spec.md + 後半Kiro方式)

議事メモから要件を抽出して仕様書に構造化します。前半は素朴な1枚もの spec.md、後半は Amazon Kiro 方式の3点分割(requirements.md / design.md / tasks.md)に触れて、仕様書の「強度」の違いを体感します。

素材ダウンロード

前半 : 素の spec.md を書く(15分)

1
考える(3分)

docs/議事メモ_データ分析案件.md を通読してください。そのうえで、「もし自分が佐藤さん(開発担当)で、このメモから spec.md を書くなら、どういう見出しを置くか」を3〜5個、自分で書き出してください。機能一覧、データ構造、処理フロー…あなたの感覚で。

▸ 書き出す先は memo.md## HANDS-ON 前半 : 見出しリスト案 見出し下。箇条書き3〜5個でOK。

2
書く・実行(7分)

Copilot Chat に対し、自分の言葉で「議事メモから spec.md を作って」と依頼してください。自分で書いた見出しリストも一緒にプロンプトへコピペして渡すと方向が揃います。TRY IT 02 で学んだ制約指示(「書かれていない要件は追加しない」)も忘れずに。

Copilot の回答をプロジェクトルートに spec.md として保存します。手順: コードブロックの「コピー」ボタン → エクスプローラーでルート右クリック → 「新しいファイル」 → spec.md と入力 → 開いたエディタに貼り付け → Ctrl+S で保存。

保存したら中身を読み、議事メモに書いてないことが入っていないか、見出しで構造化されているか、「機能」と「データ構造」と「出力仕様」が分離されているかを確認してください。

3
答え合わせと比較(5分)

自分の spec.md が保存できたら、hints/step04_spec_basic_hint.md を開いてください。参考プロンプトと比較観点(見出し構成、粒度、記述順)があります。

git add spec.md git commit -m "議事メモから仕様書を作成"

後半 : Amazon Kiro 方式の3点分割に触れる(15分)

1
考える(3分)

いま出来た spec.md を Copilot に渡して「この仕様で実装して」と言ったら何が起きるでしょうか。予想してください。

実際にやってみる時間はありませんが、Amazon の Kiro(仕様駆動開発 IDE)のチームは「1枚の spec.md では足りない」という結論に達し、仕様を3ファイルに分けました。

  • requirements.md — 何を / 誰のために / 受入基準は何か(EARS記法で検証可能に書く)
  • design.md — どう作るか(アーキテクチャ、データモデル、インターフェース)
  • tasks.md — どの順で着手するか(タスク分解、_要求事項: X.Y_ で各タスクに対応する要求事項を紐付け)

なぜ3つに分けると良いのか、1分だけ考えてください。

EARS 記法のキーワードと実例は、配布ファイルの hints/step05_spec_kiro_hint.md にまとまっています。考え終わった人から開いてください。

2
書く(7分)

.kiro/specs/sales_analysis_tool/ ディレクトリを自分で作り、雛形をコピーします。

mkdir -p .kiro/specs/sales_analysis_tool cp templates/kiro_spec_template/*.md .kiro/specs/sales_analysis_tool/

.kiro/specs/sales_analysis_tool/requirements.md を開いてください。雛形の冒頭に EARS 記法のメモがあります。自分が書いた spec.md の「機能一覧」から1項目選び、雛形の「要求事項1」を埋めてください。ユーザーストーリー1本、受入基準を EARS 記法で3つ以上。「WHEN ... THE 売上分析ツール SHALL ...」の形に落とし込むのが山場です。

3
実行(2分)

Copilot Chat に、自分で書いた requirements.md を渡して design.mdtasks.md のドラフトを依頼してみてください。自分なりのプロンプトで OK。詰まったら hints/step05_spec_kiro_hint.md の下流生成プロンプトを参照。

4
答え合わせと比較(3分)

配布フォルダの _reference_kiro_sample/.kiro/specs/sales_analysis_tool/ に、同じ題材を Kiro 方式で完成させた参考解が入っています。自分の書いた requirements.md と並べて、hints/step05_spec_kiro_hint.md の比較観点(EARS記法・design構造・tasks粒度)で差を3つ言語化してください。

git add .kiro/ git commit -m "Kiro方式の仕様3点分割を追加"
なぜ Kiro 方式が効くか

1枚の spec.md は「気持ちはわかる」で終わります。requirements で検証可能な受入基準を確定し、design でアーキテクチャを固め、tasks で着手順を切る。仕様が割れるので、AIエージェントも人間も「今どこを話しているか」を見失わない。これが Amazon Kiro / Claude Code / Cursor などが共通して採用する構造です。

Session 02 参考リンク
Session 03
Agent MD × GitHub Copilot制御

先方から最も強い要望があったテーマです。copilot-instructions.md でCopilotの出力品質をチーム単位で制御する方法を学び、4カテゴリの設計指針、@/#等の最新制御手法、適用前後の差を体感します。自チーム用のAgent MDを作成して持ち帰ります。

01 Agent MD とは何か

.github/copilot-instructions.md というファイルをリポジトリに置くと、そのリポジトリでGitHub Copilotを使う全員がこのルールに従った出力を得ます。個人設定ではなくチーム設定です。実際のプロジェクトでは、これ単体ではなく複数の設定ファイルを組み合わせて使います。

# 推奨フォルダ構成 project-root/ ├── .github/ │ ├── copilot-instructions.md # 常時適用。プロジェクト全体のルール │ ├── instructions/ # ファイル種別ごとの細かいルール │ │ ├── python.instructions.md # applyTo: "**/*.py" │ │ ├── tests.instructions.md # applyTo: "tests/**" │ │ └── data.instructions.md # applyTo: "**/data/**" │ ├── AGENTS.md # Agent Mode の行動ルール │ └── skills/ # 再利用可能なタスク定義 │ ├── code-review/SKILL.md │ ├── test-generation/SKILL.md │ └── spec-to-code/SKILL.md └── .prompts/ # よく使うプロンプト集 ├── refactor.prompt.md └── implement-feature.prompt.md
ファイル / フォルダ役割重要度
copilot-instructions.md全体に常時適用されるルール。コーディング規約・禁止事項・出力フォーマットを書く必須
instructions/ファイル種別や配置場所ごとの追加ルール。applyTo でスコープを指定する推奨
AGENTS.mdAgent Mode で自律実行する際の行動制約。ファイル操作・Git操作・エスカレーション条件を定義する推奨
skills/「レビューして」「テスト書いて」といった定型タスクを SKILL.md で定義し再利用する便利
.prompts/プロジェクトルートに置くプロンプト集。Copilot Chat から呼び出せる任意

今日の研修では copilot-instructions.md を中心に扱いますが、配布素材のZIPには上記の全ファイルが入っています。研修後に展開して中身を確認してみてください。

パスを間違えると一切効きません

よくある失敗は github/copilot-instructions.md(ドット抜け)や .github/copilot/instructions.md(余計なサブフォルダ)。正しいパスは .github/copilot-instructions.md です。リポジトリルート直下に .github フォルダを作り、その直下にファイルを置いてください。Windowsのエクスプローラーは先頭がドットのフォルダを作りにくいので、ターミナルから mkdir .github で作るのが確実です。

書くべきカテゴリ 1

コーディング規約

言語バージョン、型ヒントの要否、docstringスタイル、命名規則。チーム全員が日常的に守っているルールをそのまま書きます。

書くべきカテゴリ 2

推奨パターン

pandasのメソッドチェーン、Pathlibでのファイルパス操作、pd.to_datetime()による日付処理。チームで「この書き方がいい」と合意しているものを列挙します。

書くべきカテゴリ 3

禁止事項

bare except禁止、print()デバッグ禁止、SQL文字列結合禁止、グローバル変数禁止。禁止事項が最も効きます。Copilotはここに書かれたことを守ります。

書くべきカテゴリ 4

出力フォーマット

CSVの文字コード、数値のフォーマット、日付形式。出力に関する決め事を書いておくと、生成コードが最初から正しい形式で出力します。

# Copilot Instructions ## 言語・バージョン - Python 3.10 - 標準ライブラリとpandasを使用 ## コーディング規約 - 型ヒントを必ず付ける - docstringはGoogle Styleで書く - 変数名・関数名は英語 - コメントは日本語で書く ## 推奨パターン - pandasではメソッドチェーンを使う - ファイルパスはPathlibを使う - 日付処理はpd.to_datetime()を使う ## 禁止事項 - bare except(except: のみ)は禁止。必ず例外型を指定する - print()でのデバッグは禁止。loggingモジュールを使う - SQL文字列の直接結合は禁止。パラメータ化クエリを使う - グローバル変数の使用は禁止 ## 出力フォーマット - CSVの文字コードはUTF-8(BOM付き) - 数値は桁区切りなし - 日付フォーマットはYYYY-MM-DD
02 ハーネスエンジニアリングという考え方

2026年のAI開発で最も注目されている概念が「ハーネスエンジニアリング」です。Agent MDはこの大きな枠組みの一部として位置づけられます。

Agent = Model + Harness

AIエージェント = AIモデル + ハーネス(制御装置)。モデルの性能差ではなく、モデルの外側にある設定・制約・フィードバックループの設計が、出力品質を決めます。CLAUDE.md や copilot-instructions.md は、まさにこのハーネスの構成要素です。

Martin Fowler氏はハーネスエンジニアリングを「AIエージェントがコード生成・保守を行う際に、それを制御するためのツールとプラクティス」と定義しています。OpenAIも公式ブログで同じ概念を取り上げ、ハーネス設計の重要性を解説しました。

ハーネスの構成要素具体例今日の研修との対応
コンテキスト設計動的な知識ベース、ファイル参照、仕様書Session 02 の #file: と spec.md
アーキテクチャ制約コーディング規約、Linter、構造テストcopilot-instructions.md の禁止事項
フィードバックループAIレビュー、テスト実行、人間の判断生成 → 確認 → commit のサイクル
ツールハーネスファイル役割
GitHub Copilotcopilot-instructions.md / AGENTS.md / .prompts/コーディング規約、Agent Mode制御、プロンプト集
Claude CodeCLAUDE.md / settings.jsonプロジェクトルール、ツール権限制御
Cursor.cursor/rules/*.mdc / mcp.jsonカーソルルール、MCP連携
OpenAI CodexAGENTS.md / codex.toml行動制約、環境設定

ツールは違っても「設定ファイルでAIの出力を制御する」という設計思想は共通しています。今日学んでいる copilot-instructions.md の書き方は、他ツールにもそのまま応用が利きます。

OpenAIのハーネスエンジニアリングチームは「エージェントが苦戦したとき、それはハーネスに何かが足りないというシグナルだ」と述べています。AIが期待通りの出力をしないとき、モデルを責めるのではなく、ハーネス(設定・制約・文脈)を見直す。この発想が2026年のAI開発の中心にあります。

03 Agent MD の適用前後を比較する

同じ指示を出しても、Agent MDの有無で出力がまるで変わります。ここが研修で最もインパクトがあるパートです。

観点Agent MD なしAgent MD あり
型ヒントなし全関数に付与
docstringなし or 不統一Google Style で統一
変数名日本語混じり英語で統一
コメント言語英語日本語
例外処理bare except あり例外型を指定
デバッグ出力print() 使用logging 使用
ファイルパス文字列連結Pathlib 使用

「設定しないで使う」と「設定して使う」の差がこれです。同じツールでも使い方で生産性が変わります。

TRY IT
体験 04 : Agent MD なし で出力を記録する(5分)

この TRY IT では「なし」の状態を保存するだけ。比較は次の HANDS-ON で自分の Agent MD を組み立てた後に行います。先に「なし」の現物を残しておくのが、後で差を実感するコツ。

1
考える(1分)

.github/copilot-instructions.md を置くと、Copilot の出力が変わると言われます。具体的にどう変わるか、3つ予想してください(型ヒント、docstring、変数名、例外処理、デバッグ出力、ファイルパスの書き方…)。

memo.md## TRY IT 04 : Agent MDなし版の予想 見出し下に3点を箇条書きで書く。HANDS-ON 完了後に照らし合わせます。

2
書く・実行 : Agent MD なしで出力する(3分)

今の時点ではまだ .github/copilot-instructions.md は作っていないはず(この後の HANDS-ON で作る)。つまりこれが「なし」の状態です。新しい Copilot Chat に以下を貼り付けて送信。

CSVファイルを読み込んで、部門ごとの売上合計を集計する関数を書いて

出力された Python コードを、プロジェクトルートに _compare_no_agentmd.py として保存してください。手順: 回答のコードブロック右上「コピー」 → エクスプローラーでルート右クリック → 「新しいファイル」 → _compare_no_agentmd.py → 貼り付け → Ctrl+S。ファイル名のアンダースコアとスペルは正確に(HANDS-ON 後の比較で同名パターンを使います)。

観察ポイント: 型ヒントは付いているか / docstring のスタイル / 変数名は英語か日本語か / 例外処理は具体型か except Exception か / print() デバッグが入っているか / ファイルパスは文字列結合か pathlib.Path か。気になる点は memo.md に追記。

3
ヒント確認と予想メモ(1分)

配布ファイルの hints/step06_agentmd_no_hint.md を開いて、Step 1 で立てた「変わる3点」の予想をそのファイルの「予想メモ」欄に書き込んでください。HANDS-ON 終了後の比較で使います。

予想との答え合わせは後で

ここで答え合わせはしません。「あり」の状態は、次の HANDS-ON で自分の手で作ります。HANDS-ON 終了後、同じプロンプトを新しいチャットで投げて、_compare_no_agentmd.py と並べて比較します。

04 @/# 等の最新制御手法

Agent MD以外にも、Copilotの出力を制御する手段があります。これらを組み合わせることで、文脈の精度をさらに高められます。

制御手法記法用途
@workspaceチャット内で @workspaceリポジトリ全体を文脈に含める。大規模プロジェクトで関連ファイルを自動参照
#file:#file:ファイル名特定ファイルを明示的に文脈に含める。仕様書や設定ファイルを渡すとき
インラインチャットCtrl+I / Cmd+I選択範囲に対して直接操作。リファクタリング、説明、テスト生成を範囲限定で実行
Agent Modeチャットでモード切替自律的にファイル操作・ターミナル実行。AGENTS.mdで行動制約を定義
.prompts/.prompts/xxx.prompt.mdよく使うプロンプトをファイル化。チームで共有して品質を標準化
Tip

#file: で仕様書を渡し、Agent MDでコーディング規約を効かせた状態でコード生成を指示する。この組み合わせが実務での基本形です。

TRY IT
体験 05 : インラインチャットで practice.py を鍛える(7分)

Session 02 で作った practice.py を使い、Copilot Chat ではなくインラインチャット(Ctrl+I / Cmd+I)を試します。同じ関数に3種類の操作をかけて、Chat との違いを体感してください。

1
考える(1分)

Copilot Chat(サイドパネル)とインラインチャット(Ctrl+I)の違いは何でしょうか。「今見ているコードに対する操作」と「プロジェクト全体への質問」の違い、と言われます。では、関数1つにエラーハンドリングを足す作業にはどちらが向いていると予想しますか。

▸ 予想を memo.md## TRY IT 05 見出し下に1行。

2
書く・実行(4分)

TRY IT 03 で作った practice.py をエクスプローラーから開き、関数全体を選択します(関数の1行目から最後の行までドラッグ、または Ctrl+A で全選択)。選択した状態で、以下を順にインラインチャット(Ctrl+I / Cmd+Iで試してください(Copilot Chat は使いません)。

  • 「この関数を日本語で説明して」
  • 「エラーハンドリングを追加して。FileNotFoundError をキャッチして日本語でメッセージを出す」
  • 「この関数の pytest テストを書いて。正常系と空 DataFrame の異常系を含めて」

各回で、Chat と Inline どちらが速く正確に感じるかを主観でメモしてください。

3
答え合わせと比較(2分)

3回分の体感メモが揃ったら、hints/step08_inline_hint.md を開いてください。正解プロンプトはありません(インラインチャットは自分で言葉を選ぶのが主眼)。観察のまとめと Chat / Inline の使い分け表があります。

practice.py に1行コメントで「今日の気づき」を残して保存してください。

HANDS-ON
Agent MD を自分で組み立てる(25分)

テンプレートをたたき台にしつつ、自チームの実態に合わせた copilot-instructions.md を組み立てます。テンプレをそのまま使うのではなく、「何を残すか」「何を書き換えるか」を自分で判断するのがこのハンズオンの肝。

素材ダウンロード
1
考える(5分)

templates/copilot-instructions.md をエクスプローラーから開いてください(templates フォルダ → ファイル名クリック)。4カテゴリ(コーディング規約、推奨パターン、禁止事項、出力フォーマット)の骨組みが入っています。

読んだうえで、次を自分で整理してください。テンプレの内容は一旦忘れるのがコツ。

  • 自チームで本当に使っている Python バージョンと主要ライブラリ
  • 「いつもコードレビューで指摘している」コーディング規約を3つ
  • 「これだけは絶対やめてほしい」禁止事項を3つ
  • 出力するファイルやログの形式に関するルール

▸ 整理先は memo.md## HANDS-ON Agent MD : チーム原案 見出し下。この原案が Step 2 の下書きになります。

2
書く(10分)

プロジェクトルート直下に .github/ フォルダを作り、その中に copilot-instructions.md を配置します。作り方はターミナル派とGUI派の2通り、好きな方でOK。

ターミナル派: VS Code のメニュー「ターミナル」→「新しいターミナル」を開き、以下を実行。

# Windows の場合 mkdir .github copy templates\copilot-instructions.md .github\copilot-instructions.md # Mac/Linux の場合 mkdir -p .github cp templates/copilot-instructions.md .github/copilot-instructions.md

GUI派: エクスプローラーでルートを右クリック → 「新しいフォルダー」 → .github と入力(先頭のドットも忘れずに)。続けて .github を右クリック → 「新しいファイル」 → copilot-instructions.md。テンプレート templates/copilot-instructions.md を開いて中身を全選択コピーし、新しい .github/copilot-instructions.md に貼り付け。

どちらの方法でも、作成後に .github/copilot-instructions.md を開き、テンプレートの各項目をあなたのチームの現実に書き換えてください。Step 1 で整理した原案を参照しながら。テンプレそのまま残すより、1行でもチーム用に直した行があるかが重要です。

ヒント : 残した理由を書くと強い

「ここはテンプレそのままで OK」と判断した項目も、その判断を「なぜ残したか」1行コメントで書いておくと、後でチーム共有するときに強い武器になります。

3
実行 : あり版の出力を取る(5分)

新しい Copilot Chat を開いて(既存チャットでは反映されません)、TRY IT 04 と全く同じプロンプトを送信してください。

CSVファイルを読み込んで、部門ごとの売上合計を集計する関数を書いて

出力された Python コードを、プロジェクトルートに _compare_with_agentmd.py として保存してください(手順は TRY IT 04 と同じ流れ: コピー → 新しいファイル → 貼り付け → 保存)。TRY IT 04 で作った _compare_no_agentmd.py と並んでルート直下に2ファイルある状態になります。

Agent MDが反映されない場合

ファイルパスが .github/copilot-instructions.md になっているか確認(サブフォルダに作っていないか)。既存のチャットには反映されないことがあるので、新しいチャットで試してください。それでもダメなら Ctrl+Shift+P →「Reload Window」。

4
答え合わせと比較(5分)

_compare_no_agentmd.py(TRY IT 04 で保存した「なし」版)と _compare_with_agentmd.py(今保存した「あり」版)を横並びで開いてください。VS Code の「横に並べて開く」が見やすい。

配布ファイルの hints/step07_agentmd_build_hint.md に比較表(型ヒント / docstring / 変数名 / 例外処理 / ファイルパス / print vs logging の6観点)と、TRY IT 04 で立てた予想との一致を記入する欄があります。反映されなかった項目の対処法も載せてあります。

git add .github/copilot-instructions.md _compare_no_agentmd.py _compare_with_agentmd.py git commit -m "自チーム用Agent MDを追加"
成果物

実務のリポジトリにそのまま持ち帰れる copilot-instructions.md と、その効果を証明する「なし / あり」比較ペア。これがあれば、チームに展開するときの説得材料になります。

Session 03 参考リンク
Session 04
まとめと今後の展望

今日の研修を振り返り、明日から使えるアクションと、エンジニアのこれからを考えます。

01 研修の振り返り

メモ1枚から始めて、仕様書を構造化し、Agent MDでCopilotの出力品質をチーム単位で制御する。上流工程の設計力とAI活用力を自分の手で体験しました。

メモ
仕様書
Agent MD
実装
テスト
AIレビュー
commit
02 持ち帰り物の確認
明日からやること

1. copilot-instructions.md をチームのリポジトリに入れる(最もコストが低く効果が高い一手)
2. 新しい開発は「仕様を書く → AIに実装させる」の順番を守る
3. AIが書いたコードをAIレビュー + 人間判断にかける

03 バイブコーディングという潮流

「こう動いてほしい」という雰囲気(バイブ)だけをAIに伝えてコードを書かせる手法です。Andrej Karpathy氏が2025年2月にXで命名し、一気に広まりました。プロトタイプやPoCの段階では有効ですが、本番開発にそのまま持ち込むと品質リスクが跳ね上がります。今日学んだ「仕様駆動 + Agent MD」はバイブコーディングの対極にある堅実なアプローチで、両方を使い分けるのが現実的です。

観点バイブコーディング仕様駆動 + Agent MD
速度高速(思いつきで開始)準備に時間がかかる
品質不安定(AIまかせ)安定(規約で制御)
再現性属人的(プロンプト依存)チーム共有可能
適する場面PoC、プロトタイプ、個人開発業務アプリ、チーム開発
TRY IT
体験 06 : バイブコーディング vs 仕様駆動(8分)

同じ目的に対して、雰囲気で頼む場合と仕様駆動で頼む場合で、出力がどれだけ違うかを自分の手で体感します。ここで出す analyze.py は、発展ハンズオンでそのまま実行することになります。

1
考える(1分)

「AI にコード書かせるんだから、曖昧に頼んでも雰囲気で出してくれるじゃん」と言う人はまだ多い。これをバイブコーディングと呼びます。対して今日やったのが仕様駆動開発。同じ目的を達成する場合、この2つで出力はどれだけ違うでしょうか。予想してから次へ。

▸ 予想を memo.md## TRY IT 06 見出し下に1行。

2
書く・実行 : バイブコーディング版(2分)

新しい Copilot Chat を開き、以下をそのまま送信します。

売上データをいい感じに分析して可視化するPythonスクリプト作って

出力された Python コードを、プロジェクトルートに _compare_vibe.py として保存してください(コピー → 新しいファイル → 貼り付け → 保存)。モデルによっては手元の環境で動くコードが出てくることもありますが、重要なのは「同じ指示で、何度やっても同じ結果になる保証がない」こと。以下の観点で、再現性・チーム共有のしやすさに焦点を当てて読んでください。

  • 何のデータを前提にしているか、コード内に明示されているか
  • 出力先・ファイル名・文字コードは決まっているか
  • エラー時の挙動が書かれているか
  • あなたの手元の data/sales_data.csv でそのまま動くか(カラム名の推測がハマっていないと動かない)
3
書く・実行 : 仕様駆動版(3分)

新しい Copilot Chat で、仕様書と Agent MD を文脈として渡します。以下をそのまま送信。

#file:spec.md #file:.github/copilot-instructions.md spec.md の仕様に従って、data/sales_data.csv を読み込み、 部門別月別売上集計、地域別構成比、売上上位10商品ランキングを出すPythonスクリプトを analyze.py として作成してください。 結果は output/ ディレクトリにCSVで出力してください。

出力された Python コードを、プロジェクトルートに analyze.py として保存してください(バイブ版と同じ保存手順)。仕様書と Agent MD を文脈として渡しているので、バイブ版より前提・出力・規約が揃ったコードが返ってくる見込みです。環境によっては一発で動かない場合もありますが、その場合もエラーメッセージをそのまま Copilot に戻せば、仕様に沿った修正が返ってきます(発展ハンズオンで実際にやります)。

4
答え合わせと比較(2分)

_compare_vibe.pyanalyze.py を並べて読みます。

hints/step09_vibe_spec_hint.md を開いてください。比較観点3つ(前提の明確さ / 出力仕様の具体性 / 規約準拠度)と、持ち帰る言葉(バイブ vs 仕様駆動の使い分け判断基準)があります。

どちらが正解か

バイブコーディングが悪いわけではありません。「とりあえず動くものを見たい」場面では速い。ただ業務コードとして使うなら、仕様を先に固めて AI に書かせるほうが手戻りが少ない。使い分けの判断基準を持つことが大事です。

04 バイブコーディングの先へ -- エージェンティックエンジニアリング

2025年にバイブコーディングを命名したAndrej Karpathy氏が、2026年に入って新たに提唱したのが「エージェンティックエンジニアリング」です。AIエージェントが計画・実装・テスト・デプロイまでを自律的に実行し、人間は設計と判断に集中する開発スタイルを指します。

Karpathy氏の定義

「agentic -- コードを直接書くのではなく、99%の時間をエージェントのオーケストレーションと監督に使うから。engineering -- そこに技術と専門性があることを強調するため。」

出典: The New Stack "Vibe Coding Is Passé"

観点バイブコーディング(2025年)エージェンティックエンジニアリング(2026年)
提唱者Andrej KarpathyAndrej Karpathy
開発スタイル雰囲気で指示、AIが直接実装人間が設計、AIエージェントが自律実行
品質管理人間が後から確認複数の品質ゲート + 自動テスト
人間の役割プロンプトを書く設計、制約定義、レビュー、判断
向いている場面プロトタイプ、個人開発業務開発、チーム開発、エンタープライズ
ハーネス不要 or 最小限必須(Agent MD、仕様書、テスト基盤)

Anthropicも2026年のソフトウェア開発8つのトレンドの中でエージェンティックエンジニアリングを取り上げています。@ITの記事では「バイブコーディングはもう古い?」と題し、この進化の背景を日本語で解説しています。

今日の研修で体験した「仕様書で文脈を設計する」「Agent MDで制約を定義する」「人間が判断して commit する」というフローは、エージェンティックエンジニアリングそのものです。バイブコーディングで終わらず、ここまで到達したことに自信を持ってください。

05 業務での安全運用ガイド

AI駆動開発を業務に持ち込む際に守るべきラインがあります。便利さに流されず、品質と安全を維持するための指針です。

原則 1

AIの出力は必ず人間が検証する

AIが生成したコードをそのまま本番に入れない。型チェック、テスト実行、コードレビューを経てからmergeする習慣を徹底してください。

原則 2

機密情報をAIに渡さない

APIキー、パスワード、顧客データをプロンプトに含めない。.gitignoreに機密ファイルを登録し、Agent MDの禁止事項にも明記してください。

原則 3

AIの判断を鵜呑みにしない

AIレビューの指摘に全て従う必要はありません。「この指摘は妥当か」を人間が判断する。判断力こそがエンジニアの本領です。

原則 4

チームでルールを共有する

Agent MDはチームのルールブック。個人の使い方に差が出ないよう、copilot-instructions.mdをリポジトリに入れてバージョン管理してください。

06 他の生成AI開発ツール

GitHub Copilot以外にも、AI駆動開発を加速するツールが増えています。深入りはしませんが、存在を知っておくことに価値があります。

Claude Code
Claude Code
CLI ベースのAI開発ツール

Claude Code

VS Codeにも組み込み可能なCLI開発ツール。copilot-instructions.md の設計思想の源流です。CLAUDE.md というプロジェクトルールファイルでAIの振る舞いを制御します。

Claude Code preview
Cursor
Cursor
VS Code 派生 AI IDE

Cursor

VS Codeをフォークした専用IDE。コードベース全体を理解した上でのコード生成が特徴。多くの開発者が日常的に使い始めています。

Cursor preview
Kiro
Kiro
AWS 発 AI IDE

Kiro

AWSが開発したVS Code派生のAI IDE。仕様駆動のアプローチを重視しており、今日学んだ考え方と親和性が高いツールです。

Kiro preview
ツール提供元料金目安(個人/月)対応言語特徴
GitHub CopilotGitHub / Microsoft$10 / Pro 全主要言語VS Code統合、Agent MD、コードレビュー。エンタープライズ向け管理機能が充実
Claude CodeAnthropic$20 / Pro 全主要言語CLI完結。CLAUDE.mdによる指示設計。ファイル操作やGit操作も自律実行
CursorAnysphere$20 / Pro 全主要言語VS Codeベースの専用IDE。コードベース全体を理解した上での生成が強み
KiroAWS無料 / Pro $19 全主要言語仕様駆動開発を重視。Spec→Design→Implementの順序を仕組み化

料金は2026年4月時点の参考値です。最新の料金体系は各公式サイトで確認してください。

07 Tips: Claudeの怒涛の進化とその背景

2026年1月末、Anthropicが「Claude Cowork」を発表したことで世界のSaaS関連銘柄が急落し、約300兆円の時価総額が消失しました。「アンソロピック・ショック」と呼ばれたこの現象は、AIエージェントが既存の業務ソフトを置き換えうるという市場の恐怖を可視化しました。

日付出来事影響
1/30Claude Cowork に法務・財務分析自動化機能を追加Salesforce等の業務ソフト企業の株価が急落
2/5Claude Opus 4.6 発表(100万トークンのコンテキスト)金融サービス関連銘柄に売り
2/17Claude Sonnet 4.6 発表開発者向けモデルの世代交代
2/20Claude Code Security(脆弱性管理)発表サイバーセキュリティ銘柄に波及
2/25Vercept社を買収(AI操作能力の強化)コンピュータ操作AIの本格化

約2週間おきにメジャーアップデートを繰り返す異例のペースでした。

出典: 三井住友DSアセットマネジメント / Medium: Anthropic's Explosive Start to 2026

この怒涛の進化の裏側には、AI開発の現場で起きている構造変化があります。

構造変化 1

世界最高峰のエンジニアはAI組織を率いている

Anthropic、OpenAI、Googleの開発チームでは、トップエンジニアがコードを手で書く時間が激減しています。代わりに「AIエージェントのハーネスを設計し、エージェント組織を率いる」役割にシフトしました。設計と判断に集中し、実装はAIに委ねるスタイルが、最先端の現場では既に標準です。

構造変化 2

「90%のコードをAIが書く」という現実

Anthropic CEO Dario Amodei氏は2025年3月、米国外交問題評議会(CFR)の講演で「3~6ヶ月以内にAIがコードの90%を書くようになる。12ヶ月以内には実質的に全てのコードを書いているだろう」と予測しました。2026年3月時点で、Amodei氏は「Anthropic社内と協業先企業では、この予測は完全に実現している」と述べています。

出典: Yahoo Finance / Daring Fireball

今日の研修との接続

90%のコードをAIに任せるなら、残り10%の「設計・仕様定義・判断」の密度は跳ね上がります。仕様書を先に書く力、Agent MDで品質を制御する力、AIの出力を検証する力。今日学んだのは、まさにその10%を担うためのスキルセットです。

Y Combinator代表のGarry Tan氏によると、2025年冬バッチのスタートアップ創業者のうち25%が「コードの95%をAIが生成している」と報告しました。人間は設計とレビューのみ。これはAnthropicやOpenAIのような最先端企業だけの話ではなく、スタートアップの日常になりつつあります。

出典: LessWrong: Is 90% of code at Anthropic being written by AIs?

08 3年後、エンジニアは何をしているか
生成AIで開発手法がどう変わっていくか。何を追いかけなければならないか。

まずは皆さんで考えてみてください。

コードを書く量は減り、設計と判断の密度が上がる

AIがコードを書く部分はどんどん増えます。人間の仕事は「何を作るか決める」「AIの出力が正しいか判断する」「設計をレビューする」に集中していきます。今日体験した「仕様を書く→AIに実装させる→人間が判断する」のサイクルは、3年後にはさらに当たり前になっているはずです。

追うべきはツールではなく設計思想

GitHub Copilotが3年後にどうなっているかはわかりません。別のツールが主流になっているかもしれません。ただ、「AIに正しい文脈を渡す」「仕様を先に書く」「規約でAIの出力を制御する」という設計思想はツールに依存しません。今日学んだことは、ツールが変わっても使えます。

Pythonの活用幅が広がる

業務で必要になったデータ変換、集計ツール、ちょっとした自動化。今日の研修で体験した手法があれば、これまで依頼していた作業を自分で素早く作れるようになります。AIを使いこなせるエンジニアは、対応できる仕事の範囲が大きく広がります。

GitHub自体が進化を続けている

GitHub Copilot Workspace(Issue→Plan→Implement→PRを自動化する構想)や、Agent Modeの拡張、Copilot Extensionsによるサードパーティ連携など、ロードマップは加速しています。ツールの機能追加を追いかけるより、今日学んだ「仕様を先に書き、Agent MDで制御し、人間が判断する」フレームワークを土台にしておけば、新機能が出ても使いこなし方の応用が利きます。

09 完了チェックリスト

研修が終わった時点で、以下が揃っていれば成功です。

Session 04 参考リンク
APPENDIX
生成AI関連の資格・認定

今日の研修で学んだ内容をさらに深めたい方、客観的なスキル証明が欲しい方に向けて、関連する資格を紹介します。受験を強制するものではございません。キャリアの方向性に合わせて、興味があるものを検討してみてください。

01 今日の研修内容と直結する資格
GitHub
GitHub
本研修と最も関連が深い

GitHub Copilot Certification(GH-300)

GitHub Copilotの活用能力を認定する公式資格。プロンプトエンジニアリング、責任あるAIの使用、各プランの機能差、プライバシー保護まで出題されます。2026年1月に試験内容が大幅改訂され、日本語での受験にも対応済み。今日学んだ copilot-instructions.md やコンテキスト設計の知識がそのまま活きます。

受験料 $99 / 選択式 60問 120分 / オンライン監督付き / 合格ライン 70%前後

GitHub
GitHub
Git/GitHub の基礎固めに

GitHub Foundations

GitHubの基本概念、リポジトリ管理、コラボレーション機能の理解を問う入門資格。今日の研修で git init / commit の流れを体験しましたが、ブランチ戦略やPull Requestなど、チーム開発に必要な知識を体系的に押さえたい場合に有効です。

受験料 $99 / 選択式 75問 120分 / オンライン監督付き / 合格ライン 70%前後

02 国内の生成AI資格
GUGA
非エンジニアでも受けやすい

生成AIパスポート試験

生成AI活用普及協会(GUGA)が運営する国内資格。2026年から年5回開催に拡大されました。最新シラバスではGPT-o1/o3、Claude、Copilot、RAG、AIエージェント、AI新法まで範囲が広がっています。生成AIの全体像を体系的に掴みたい方の入口として手堅い選択肢です。

受験料 11,000円(税込) / 4択 60問 60分 / オンライン / 合格率 約70%

JDLA
実装力を証明する最高峰

JDLA E資格

日本ディープラーニング協会が主催するエンジニア向けの国内最難関AI資格。ディープラーニングの理論と実装能力を問います。今回の研修テーマとは直接重ならない領域ですが、AIの仕組みを深く理解したいエンジニアには価値があります。JDLA認定プログラムの修了が受験の前提条件になっている点に注意してください。

受験料 33,000円(税込) / 選択式+記述 約100問 120分 / 会場 / 合格率 約60-70%

03 クラウドベンダーのAI認定

AWSやAzureを業務で使っているなら、クラウドベンダーのAI認定がキャリアの武器になります。今日の研修で扱ったAI駆動開発の考え方と、クラウド上でのAIサービス構築は補完関係にあります。

資格名提供元レベル特徴
AWS Certified AI Practitioner AWS 入門 AI/ML/生成AIの概念とAWSのAIサービスの基礎知識を問う。Lambda/Glueなど既に使っている方は学習コストが低い
Azure AI Fundamentals(AI-900) Microsoft 入門 Azure AI サービスの基礎。受験料12,500円。随時受験可能で取得しやすい
Google Cloud ML Engineer Google Cloud 上級 ML実装能力を問う国際資格。Vertex AI、BigQuery MLなどGoogle Cloudでの実務経験が前提
どの資格から始めるか

今日の研修内容と最も直結するのは GitHub Copilot Certification です。日常業務でCopilotを使い続けながら準備すれば、特別な学習なしでも合格圏に入れます。AWSを業務で使っているなら AWS AI Practitioner も費用対効果が高い選択肢になります。国内資格では生成AIパスポートが間口が広く、チームメンバーに勧めやすいでしょう。

資格・認定 参考リンク