DIS AI駆動開発研修
DIS AI駆動開発研修
メモ1枚から仕様書、Agent MD、Copilot制御まで。上流工程の設計力とAI活用力を身につける4.5時間。
×
研修を始める前に、以下の環境が整っていることをご確認ください。ハンズオンで使う素材は一括でダウンロードできます。
python --version）git --version）pip install pandas）pip install pytest）ZIP内に議事メモ、Agent MDテンプレート、サンプルCSV、.github フォルダ一式（copilot-instructions.md + カスタムプロンプト5種）が含まれます。VS Codeで展開したフォルダを開けば、そのまま研修を始められます。
研修ゴールと全体マップ / 環境チェック / GitHub Copilotの基本操作確認 / AI駆動開発の全体像
設計思想（文脈設計・仕様駆動） / ライブデモ（要件抽出・Markdown構造化・コメントドリブン） / 仕様書作成演習
Agent MDの設計 / ハーネスエンジニアリング / 適用前後の比較 / 最新制御手法 / 自チーム用MD作成ハンズオン
振り返り / バイブコーディング / エージェンティックエンジニアリング / 安全運用 / Claudeの怒涛の進化 / Claude Code・Cursor・Kiro
研修の全体像を把握し、手元の環境が動くことを確認します。この10分で全員のスタートラインを揃えます。
今日の4.5時間で「メモ1枚を起点に、仕様書を書き、Agent MDを整備し、GitHub Copilotの出力品質をチーム単位で制御する」までの一連の設計フローを自分の手で体験します。持ち帰るのは構造化された仕様書とAgent MD、そしてそれを支える「型」そのものです。
AI駆動開発とは、生成AIをコーディングアシスタントとして使うだけでなく、上流工程の設計段階からAIを組み込む開発手法です。
チャットで質問し、出力をコピペする。出力品質はプロンプトに依存し、毎回バラつきます。
仕様書やAgent MDで文脈を事前に構造化し、AIの出力を再現可能な形で安定させます。チーム全員の生産性が底上げされます。
以下の4つが動作する状態を確認してください。問題があれば講師にお声がけください。
python --version）git --version）pip install pandas）pip install pytest）VS Code右下のCopilotアイコンが灰色（無効状態）のときは、アイコンをクリックして「Enable Globally」を選択してください。それでも有効にならない場合は、VS Codeの拡張機能パネル（Ctrl+Shift+X）で「GitHub Copilot」「GitHub Copilot Chat」の2つがインストール済みかを確認し、「Reload Required」と出ていればウィンドウを再読み込みしてください。
python3 --version を試してください。動けば以降の手順は python を python3 に読み替えます。Windowsで python がMicrosoft Storeを開く場合は、Python公式サイトからインストーラーを入れ直すか、VS Codeターミナルのシェル種別を確認してください。
本研修で使う3つの機能を確認します。Copilot Chat のモデルは Claude Sonnet 4.6 または Claude Opus 4.6 を使用します。チャット画面上部のモデル選択ドロップダウンから切り替えてください。
| 機能 | 起動方法（Windows） | 起動方法（Mac） | 用途 |
|---|---|---|---|
| Copilot Chat | Ctrl + Shift + I | Cmd + Shift + I | 対話形式でコード生成・質問・レビュー |
| インラインチャット | Ctrl + I | Cmd + I | 選択範囲のリファクタリング・説明 |
| コード補完 | Tab で受け入れ / Esc でキャンセル | 入力中にリアルタイムでコードを提案 | |
#file:ファイル名 でチャット内に特定ファイルの中身を渡せます。@workspace でリポジトリ全体を文脈に含められます。この2つを使いこなせるかどうかで出力品質が変わります。
@workspace はリポジトリ全体を文脈に渡すため、トークンを大量に消費します。ファイル数が多い大規模リポジトリでは応答が遅くなったり、文脈が溢れて精度が落ちることがあります。対象ファイルが明確な場合は #file: で個別に指定するほうが確実です。
GitHub Copilotの出力品質は渡す文脈で決まります。プロンプトの小手先テクニックではなく、AIに渡す情報の設計こそが生産性を分けるという話から始め、仕様を先に書いてAIに実装させる順番を体験します。
AIの出力品質を決める3つの文脈層があります。プロジェクト設定（Agent MD）、開いているファイル群、指示の精度。この3つを設計するのがコンテキストエンジニアリングです。まず手を動かして、文脈の有無で出力がどう変わるか体感してください。
copilot-instructions.md に書かれた規約・禁止事項。リポジトリに入れるだけでチーム全員のCopilotが従います。Session 03で詳しく扱います。
VS Codeのタブに開いているファイルがCopilotの文脈に入ります。関連ファイルを開いておくだけで出力精度が上がります。#file: で明示的に渡すとさらに確実です。
「何を」「どの形式で」「何を除外して」生成するか。制約指示が効くかどうかが出力品質の分かれ目になります。
同じ指示でも、渡す文脈で出力がまるで変わることを自分の手で確認します。この体験は4段構造で進めます。先に答えのプロンプトやファイル内容は開かず、自分で考えて書いてみてから答え合わせに入ってください。
Copilot Chat にいきなり「議事メモからユーザーストーリーを抽出して」と指示すると、Copilot は何を見に行くでしょうか。手元のファイル？ それとも頭の中に作った架空の議事メモ？ 予想を1つ立ててください。
Copilot Chat（Ctrl+Shift+I / Cmd+Shift+I）を開き、以下をそのまま貼り付けてください。何のファイルも指定しません。
出力されたユーザーストーリーは、あなたの手元の docs/議事メモ_データ分析案件.md の内容と一致していますか。たぶん、かすりもしていないはず。Copilot は「議事メモ」という文字列から自力で創作しています。
新しい Copilot Chat を開き、今度は「Copilot にメモを見せる」ために何をどう書けばいいか、自分で考えて書いてください。先に docs/議事メモ_データ分析案件.md の中身を目で読んで、どこをどう伝えたらいいか決めます。ファイル指定の書き方がわからなくても、自分なりの1回目を出してから次へ進んでください。
出力を見て、Step 2 の文脈なし版と比べてください。自分の書き方でどこまで改善しましたか。
自分のプロンプトと出力が手元に揃ったら、配布ファイルの hints/step01_context_hint.md を開いてください。参考プロンプトと比較観点が書いてあります。自分の書いたものと並べて、何が違ったかを1行で言語化します。
プロンプトの一文字も変えていません。変えたのは「渡した文脈」だけ。#file: 1つで出力品質がここまで変わる。この差を仕組みとしてチームに定着させるのが Session 03 で扱う Agent MD です。
copilot-instructions.md の設計思想は Claude Code の CLAUDE.md が原型です。エージェントモードも同じ系譜。GitHub Copilotの「新機能」として見るのではなく、AI開発ツールに共通する設計思想として理解すると、ツールが変わっても応用が利きます。
Claude CodeGitHub Copilot
Cursor / Kiro仕様を書かずにいきなりコードを書かせると、AIは「動くが使えないもの」を量産します。メモから要件を抽出し、Markdownで構造化し、仕様書にまとめる。この工程を経てから実装に入ると手戻りが激減します。
同じメモでも、制約があるかないかで出力が劇的に変わります。まず予想し、自分で制約を書いてみてから参考解を開きます。
売上CSV集計のような地味な業務要件に対して、Copilot はどんな機能を勝手に加えてくるでしょうか。3つ予想してから次へ。認証? ダッシュボード? 通知? 多言語? ログ?
新しい Copilot Chat に以下を貼り付けて実行。制約を一切付けずに依頼します。
出力の中で「メモに書かれていない項目」をマーカーで囲むか、箇条書きにメモしてください。何個ありましたか。Step 1 で予想した3つと一致しましたか。
AI の親切な追加を止めるには、どう書けば効くと思いますか。自分の言葉で1〜3行の制約を追加し、新しいチャットで同じメモを渡して実行してください。参考解は次のステップまで開かないのが体験のコツ。
自分で制約を書いた版と、もとの制約なし版が手元に揃ったら、hints/step02_constraint_hint.md を開いてください。参考プロンプトと比較観点、「制約は短く決定的な1行が強い」という実務の勘所があります。
制約なし版では AI が「親切心で」認証・通知・多言語・ログ出力などを追加しがち。「追加しないで」の一文がスコープ膨張の防波堤になる。ここを怠ると、仕様がずるずると膨らんで本来のやりたいことが薄まります。
関数の上にコメントを先に書き、Copilotにコード補完させる手法です。仕様駆動開発の考え方をコードレベルに落とし込んだもの。実際にやってみてください。
コメント・型ヒント・関数名。Copilot のコード補完を動かす3つの軸のうち、どれが一番効くかを自分の手で確認します。
Copilot は直前の情報を読んで次のコードを提案します。では、関数名だけ書くのと、コメントで仕様を書くのと、型ヒントを付けるのでは、どれが一番効くでしょうか。優先順位を予想してから次へ。
VS Code で practice.py を新規作成し、以下を貼り付けてください。ここまではテンプレ。def 行末にカーソルを置いて Enter。灰色のサジェストが出たら Tab で受け入れます。
出てきたコードをよく見てください。pandas のメソッドチェーンになっていますか。
次の2つを自分で試します。各試行でCopilotの提案がどう変わったか、1行ずつメモしてください。
# forループで集計する に書き換えて、関数本体を削除 → 再補完aggregate_dept_monthly → calc_sales_by_dept_and_month に変更 → 再補完3回分のメモが揃ったら、hints/step03_comment_driven_hint.md を開いてください。正解プロンプトはありません（コメントドリブンは自分で書き換えるもの）。観察のまとめ観点と、試す順序の推奨があります。
この practice.py は Session 03 の TRY IT 05 で再利用します。保存しておいてください。
型ヒント + コメント + 関数名の3点が揃うと Copilot の推測精度が跳ね上がります。Session 03 で扱う Agent MD で「型ヒント必須」「docstring は Google Style」を設定しておくと、この精度がさらに安定。詳しくは GitHub Copilot コード補完ガイド。
議事メモから要件を抽出して仕様書に構造化します。前半は素朴な1枚もの spec.md、後半は Amazon Kiro 方式の3点分割（requirements.md / design.md / tasks.md）に触れて、仕様書の「強度」の違いを体感します。
docs/議事メモ_データ分析案件.md を通読してください。そのうえで、「もし自分が佐藤さん（開発担当）で、このメモから spec.md を書くなら、どういう見出しを置くか」を3〜5個、自分で書き出してください。機能一覧、データ構造、処理フロー…あなたの感覚で。
Copilot Chat に対し、自分の言葉で「議事メモから spec.md を作って」と依頼してください。自分で書いた見出しリストも一緒に渡すと方向が揃います。TRY IT 02 で学んだ制約指示（「書かれていない要件は追加しない」）も忘れずに。
出力を spec.md としてプロジェクトルートに保存します。
保存したら中身を読み、議事メモに書いてないことが入っていないか、見出しで構造化されているか、「機能」と「データ構造」と「出力仕様」が分離されているかを確認してください。
自分の spec.md が保存できたら、hints/step04_spec_basic_hint.md を開いてください。参考プロンプトと比較観点（見出し構成、粒度、記述順）があります。
いま出来た 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 にまとまっています。考え終わった人から開いてください。
.kiro/specs/sales_analysis_tool/ ディレクトリを自分で作り、雛形をコピーします。
.kiro/specs/sales_analysis_tool/requirements.md を開いてください。雛形の冒頭に EARS 記法のメモがあります。自分が書いた spec.md の「機能一覧」から1項目選び、雛形の「要求事項1」を埋めてください。ユーザーストーリー1本、受入基準を EARS 記法で3つ以上。「WHEN ... THE 売上分析ツール SHALL ...」の形に落とし込むのが山場です。
Copilot Chat に、自分で書いた requirements.md を渡して design.md と tasks.md のドラフトを依頼してみてください。自分なりのプロンプトで OK。詰まったら hints/step05_spec_kiro_hint.md の下流生成プロンプトを参照。
配布フォルダの _reference_kiro_sample/.kiro/specs/sales_analysis_tool/ に、同じ題材を Kiro 方式で完成させた参考解が入っています。自分の書いた requirements.md と並べて、hints/step05_spec_kiro_hint.md の比較観点（EARS記法・design構造・tasks粒度）で差を3つ言語化してください。
1枚の spec.md は「気持ちはわかる」で終わります。requirements で検証可能な受入基準を確定し、design でアーキテクチャを固め、tasks で着手順を切る。仕様が割れるので、AIエージェントも人間も「今どこを話しているか」を見失わない。これが Amazon Kiro / Claude Code / Cursor などが共通して採用する構造です。
先方から最も強い要望があったテーマです。copilot-instructions.md でCopilotの出力品質をチーム単位で制御する方法を学び、4カテゴリの設計指針、@/#等の最新制御手法、適用前後の差を体感します。自チーム用のAgent MDを作成して持ち帰ります。
.github/copilot-instructions.md というファイルをリポジトリに置くと、そのリポジトリでGitHub Copilotを使う全員がこのルールに従った出力を得ます。個人設定ではなくチーム設定です。実際のプロジェクトでは、これ単体ではなく複数の設定ファイルを組み合わせて使います。
| ファイル / フォルダ | 役割 | 重要度 |
|---|---|---|
| copilot-instructions.md | 全体に常時適用されるルール。コーディング規約・禁止事項・出力フォーマットを書く | 必須 |
| instructions/ | ファイル種別や配置場所ごとの追加ルール。applyTo でスコープを指定する | 推奨 |
| AGENTS.md | Agent 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 で作るのが確実です。
言語バージョン、型ヒントの要否、docstringスタイル、命名規則。チーム全員が日常的に守っているルールをそのまま書きます。
pandasのメソッドチェーン、Pathlibでのファイルパス操作、pd.to_datetime()による日付処理。チームで「この書き方がいい」と合意しているものを列挙します。
bare except禁止、print()デバッグ禁止、SQL文字列結合禁止、グローバル変数禁止。禁止事項が最も効きます。Copilotはここに書かれたことを守ります。
CSVの文字コード、数値のフォーマット、日付形式。出力に関する決め事を書いておくと、生成コードが最初から正しい形式で出力します。
2026年のAI開発で最も注目されている概念が「ハーネスエンジニアリング」です。Agent MDはこの大きな枠組みの一部として位置づけられます。
AIエージェント = AIモデル + ハーネス（制御装置）。モデルの性能差ではなく、モデルの外側にある設定・制約・フィードバックループの設計が、出力品質を決めます。CLAUDE.md や copilot-instructions.md は、まさにこのハーネスの構成要素です。
Martin Fowler氏はハーネスエンジニアリングを「AIエージェントがコード生成・保守を行う際に、それを制御するためのツールとプラクティス」と定義しています。OpenAIも公式ブログで同じ概念を取り上げ、ハーネス設計の重要性を解説しました。
| ハーネスの構成要素 | 具体例 | 今日の研修との対応 |
|---|---|---|
| コンテキスト設計 | 動的な知識ベース、ファイル参照、仕様書 | Session 02 の #file: と spec.md |
| アーキテクチャ制約 | コーディング規約、Linter、構造テスト | copilot-instructions.md の禁止事項 |
| フィードバックループ | AIレビュー、テスト実行、人間の判断 | 生成 → 確認 → commit のサイクル |
| ツール | ハーネスファイル | 役割 |
|---|---|---|
| GitHub Copilot | copilot-instructions.md / AGENTS.md / .prompts/ | コーディング規約、Agent Mode制御、プロンプト集 |
| Claude Code | CLAUDE.md / settings.json | プロジェクトルール、ツール権限制御 |
| Cursor | .cursor/rules/*.mdc / mcp.json | カーソルルール、MCP連携 |
| OpenAI Codex | AGENTS.md / codex.toml | 行動制約、環境設定 |
ツールは違っても「設定ファイルでAIの出力を制御する」という設計思想は共通しています。今日学んでいる copilot-instructions.md の書き方は、他ツールにもそのまま応用が利きます。
OpenAIのハーネスエンジニアリングチームは「エージェントが苦戦したとき、それはハーネスに何かが足りないというシグナルだ」と述べています。AIが期待通りの出力をしないとき、モデルを責めるのではなく、ハーネス（設定・制約・文脈）を見直す。この発想が2026年のAI開発の中心にあります。
同じ指示を出しても、Agent MDの有無で出力がまるで変わります。ここが研修で最もインパクトがあるパートです。
| 観点 | Agent MD なし | Agent MD あり |
|---|---|---|
| 型ヒント | なし | 全関数に付与 |
| docstring | なし or 不統一 | Google Style で統一 |
| 変数名 | 日本語混じり | 英語で統一 |
| コメント言語 | 英語 | 日本語 |
| 例外処理 | bare except あり | 例外型を指定 |
| デバッグ出力 | print() 使用 | logging 使用 |
| ファイルパス | 文字列連結 | Pathlib 使用 |
「設定しないで使う」と「設定して使う」の差がこれです。同じツールでも使い方で生産性が変わります。
この TRY IT では「なし」の状態を保存するだけ。比較は次の HANDS-ON で自分の Agent MD を組み立てた後に行います。先に「なし」の現物を残しておくのが、後で差を実感するコツ。
.github/copilot-instructions.md を置くと、Copilot の出力が変わると言われます。具体的にどう変わるか、3つ予想してください（型ヒント、docstring、変数名、例外処理、デバッグ出力、ファイルパスの書き方…）。
今の時点ではまだ .github/copilot-instructions.md は作っていないはず（この後の HANDS-ON で作る）。つまりこれが「なし」の状態です。新しい Copilot Chat に以下を貼り付け、出力を _compare_no_agentmd.py として保存してください。
観察ポイント（全部メモ）: 型ヒントは付いているか / docstring のスタイル / 変数名は英語か日本語か / 例外処理は具体型か except Exception か / print() デバッグが入っているか / ファイルパスは文字列結合か pathlib.Path か。
配布ファイルの hints/step06_agentmd_no_hint.md を開いて、Step 1 で立てた「変わる3点」の予想をそのファイルの「予想メモ」欄に書き込んでください。HANDS-ON 終了後の比較で使います。
ここで答え合わせはしません。「あり」の状態は、次の HANDS-ON で自分の手で作ります。HANDS-ON 終了後、同じプロンプトを新しいチャットで投げて、_compare_no_agentmd.py と並べて比較します。
Agent MD以外にも、Copilotの出力を制御する手段があります。これらを組み合わせることで、文脈の精度をさらに高められます。
| 制御手法 | 記法 | 用途 |
|---|---|---|
| @workspace | チャット内で @workspace | リポジトリ全体を文脈に含める。大規模プロジェクトで関連ファイルを自動参照 |
| #file: | #file:ファイル名 | 特定ファイルを明示的に文脈に含める。仕様書や設定ファイルを渡すとき |
| インラインチャット | Ctrl+I / Cmd+I | 選択範囲に対して直接操作。リファクタリング、説明、テスト生成を範囲限定で実行 |
| Agent Mode | チャットでモード切替 | 自律的にファイル操作・ターミナル実行。AGENTS.mdで行動制約を定義 |
| .prompts/ | .prompts/xxx.prompt.md | よく使うプロンプトをファイル化。チームで共有して品質を標準化 |
#file: で仕様書を渡し、Agent MDでコーディング規約を効かせた状態でコード生成を指示する。この組み合わせが実務での基本形です。
Session 02 で作った practice.py を使い、Copilot Chat ではなくインラインチャット（Ctrl+I / Cmd+I）を試します。同じ関数に3種類の操作をかけて、Chat との違いを体感してください。
Copilot Chat（サイドパネル）とインラインチャット（Ctrl+I）の違いは何でしょうか。「今見ているコードに対する操作」と「プロジェクト全体への質問」の違い、と言われます。では、関数1つにエラーハンドリングを足す作業にはどちらが向いていると予想しますか。
practice.py の関数全体を選択して、以下を順に試してください。各回で、Copilot Chat ではなくインラインチャット（Ctrl+I / Cmd+I）を使います。
各回で、Chat と Inline どちらが速く正確に感じるかを主観でメモしてください。
3回分の体感メモが揃ったら、hints/step08_inline_hint.md を開いてください。正解プロンプトはありません（インラインチャットは自分で言葉を選ぶのが主眼）。観察のまとめと Chat / Inline の使い分け表があります。
practice.py に1行コメントで「今日の気づき」を残して保存してください。
テンプレートをたたき台にしつつ、自チームの実態に合わせた copilot-instructions.md を組み立てます。テンプレをそのまま使うのではなく、「何を残すか」「何を書き換えるか」を自分で判断するのがこのハンズオンの肝。
templates/copilot-instructions.md を開いてください。4カテゴリ（コーディング規約、推奨パターン、禁止事項、出力フォーマット）の骨組みが入っています。
読んだうえで、次を自分で整理してください。テンプレの内容は一旦忘れるのがコツ。
紙でもテキストでも構いません。これがあなたの Agent MD の原案になります。
.github/ フォルダを作り、テンプレートをコピーして自分の原案で編集します。
.github/copilot-instructions.md を開いて、テンプレートの各項目をあなたのチームの現実に書き換えてください。テンプレそのまま残すより、1行でもチーム用に直した行があるかが重要です。
「ここはテンプレそのままで OK」と判断した項目も、その判断を「なぜ残したか」1行コメントで書いておくと、後でチーム共有するときに強い武器になります。
新しい Copilot Chat を開いて（既存チャットでは反映されません）、TRY IT 04 と全く同じプロンプトを投げてください。
出力を _compare_with_agentmd.py として保存してください。
ファイルパスが .github/copilot-instructions.md になっているか確認（サブフォルダに作っていないか）。既存のチャットには反映されないことがあるので、新しいチャットで試してください。それでもダメなら Ctrl+Shift+P →「Reload Window」。
_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 で立てた予想との一致を記入する欄があります。反映されなかった項目の対処法も載せてあります。
実務のリポジトリにそのまま持ち帰れる copilot-instructions.md と、その効果を証明する「なし / あり」比較ペア。これがあれば、チームに展開するときの説得材料になります。
今日の研修を振り返り、明日から使えるアクションと、エンジニアのこれからを考えます。
メモ1枚から始めて、仕様書を構造化し、Agent MDでCopilotの出力品質をチーム単位で制御する。上流工程の設計力とAI活用力を自分の手で体験しました。
spec.md -- 構造化された仕様書テンプレートとして再利用可能.github/copilot-instructions.md -- そのままチームのリポジトリに投入可能.github/ 配下の設定ファイル一式 -- instructions、AGENTS.md、skills、.prompts1. copilot-instructions.md をチームのリポジトリに入れる（最もコストが低く効果が高い一手）
2. 新しい開発は「仕様を書く → AIに実装させる」の順番を守る
3. AIが書いたコードをAIレビュー + 人間判断にかける
「こう動いてほしい」という雰囲気（バイブ）だけをAIに伝えてコードを書かせる手法です。Andrej Karpathy氏が2025年2月にXで命名し、一気に広まりました。プロトタイプやPoCの段階では有効ですが、本番開発にそのまま持ち込むと品質リスクが跳ね上がります。今日学んだ「仕様駆動 + Agent MD」はバイブコーディングの対極にある堅実なアプローチで、両方を使い分けるのが現実的です。
| 観点 | バイブコーディング | 仕様駆動 + Agent MD |
|---|---|---|
| 速度 | 高速（思いつきで開始） | 準備に時間がかかる |
| 品質 | 不安定（AIまかせ） | 安定（規約で制御） |
| 再現性 | 属人的（プロンプト依存） | チーム共有可能 |
| 適する場面 | PoC、プロトタイプ、個人開発 | 業務アプリ、チーム開発 |
同じ目的に対して、雰囲気で頼む場合と仕様駆動で頼む場合で、出力がどれだけ違うかを自分の手で体感します。ここで出す analyze.py は、発展ハンズオンでそのまま実行することになります。
「AI にコード書かせるんだから、曖昧に頼んでも雰囲気で出してくれるじゃん」と言う人はまだ多い。これをバイブコーディングと呼びます。対して今日やったのが仕様駆動開発。同じ目的を達成する場合、この2つで出力はどれだけ違うでしょうか。予想してから次へ。
新しい Copilot Chat を開き、雰囲気で依頼します。
出力コードを _compare_vibe.py として保存。読み返して以下を確認。
data/sales_data.csv で動くか新しい Copilot Chat で、仕様書と Agent MD を文脈として渡します。
出力を analyze.py として保存。今回はちゃんと動くはず（発展ハンズオンで実行します）。
_compare_vibe.py と analyze.py を並べて読みます。
hints/step09_vibe_spec_hint.md を開いてください。比較観点3つ（前提の明確さ / 出力仕様の具体性 / 規約準拠度）と、持ち帰る言葉（バイブ vs 仕様駆動の使い分け判断基準）があります。
バイブコーディングが悪いわけではありません。「とりあえず動くものを見たい」場面では速い。ただ業務コードとして使うなら、仕様を先に固めて AI に書かせるほうが手戻りが少ない。使い分けの判断基準を持つことが大事です。
2025年にバイブコーディングを命名したAndrej Karpathy氏が、2026年に入って新たに提唱したのが「エージェンティックエンジニアリング」です。AIエージェントが計画・実装・テスト・デプロイまでを自律的に実行し、人間は設計と判断に集中する開発スタイルを指します。
「agentic -- コードを直接書くのではなく、99%の時間をエージェントのオーケストレーションと監督に使うから。engineering -- そこに技術と専門性があることを強調するため。」
| 観点 | バイブコーディング（2025年） | エージェンティックエンジニアリング（2026年） |
|---|---|---|
| 提唱者 | Andrej Karpathy | Andrej Karpathy |
| 開発スタイル | 雰囲気で指示、AIが直接実装 | 人間が設計、AIエージェントが自律実行 |
| 品質管理 | 人間が後から確認 | 複数の品質ゲート + 自動テスト |
| 人間の役割 | プロンプトを書く | 設計、制約定義、レビュー、判断 |
| 向いている場面 | プロトタイプ、個人開発 | 業務開発、チーム開発、エンタープライズ |
| ハーネス | 不要 or 最小限 | 必須（Agent MD、仕様書、テスト基盤） |
Anthropicも2026年のソフトウェア開発8つのトレンドの中でエージェンティックエンジニアリングを取り上げています。@ITの記事では「バイブコーディングはもう古い？」と題し、この進化の背景を日本語で解説しています。
今日の研修で体験した「仕様書で文脈を設計する」「Agent MDで制約を定義する」「人間が判断して commit する」というフローは、エージェンティックエンジニアリングそのものです。バイブコーディングで終わらず、ここまで到達したことに自信を持ってください。
AI駆動開発を業務に持ち込む際に守るべきラインがあります。便利さに流されず、品質と安全を維持するための指針です。
AIが生成したコードをそのまま本番に入れない。型チェック、テスト実行、コードレビューを経てからmergeする習慣を徹底してください。
APIキー、パスワード、顧客データをプロンプトに含めない。.gitignoreに機密ファイルを登録し、Agent MDの禁止事項にも明記してください。
AIレビューの指摘に全て従う必要はありません。「この指摘は妥当か」を人間が判断する。判断力こそがエンジニアの本領です。
Agent MDはチームのルールブック。個人の使い方に差が出ないよう、copilot-instructions.mdをリポジトリに入れてバージョン管理してください。
GitHub Copilot以外にも、AI駆動開発を加速するツールが増えています。深入りはしませんが、存在を知っておくことに価値があります。
VS Codeにも組み込み可能なCLI開発ツール。copilot-instructions.md の設計思想の源流です。CLAUDE.md というプロジェクトルールファイルでAIの振る舞いを制御します。
| ツール | 提供元 | 料金目安（個人/月） | 対応言語 | 特徴 |
|---|---|---|---|---|
| GitHub Copilot | GitHub / Microsoft | $10 / Pro | 全主要言語 | VS Code統合、Agent MD、コードレビュー。エンタープライズ向け管理機能が充実 |
| Claude Code | Anthropic | $20 / Pro | 全主要言語 | CLI完結。CLAUDE.mdによる指示設計。ファイル操作やGit操作も自律実行 |
| Cursor | Anysphere | $20 / Pro | 全主要言語 | VS Codeベースの専用IDE。コードベース全体を理解した上での生成が強み |
 Kiro | AWS | 無料 / Pro $19 | 全主要言語 | 仕様駆動開発を重視。Spec→Design→Implementの順序を仕組み化 |
料金は2026年4月時点の参考値です。最新の料金体系は各公式サイトで確認してください。
2026年1月末、Anthropicが「Claude Cowork」を発表したことで世界のSaaS関連銘柄が急落し、約300兆円の時価総額が消失しました。「アンソロピック・ショック」と呼ばれたこの現象は、AIエージェントが既存の業務ソフトを置き換えうるという市場の恐怖を可視化しました。
| 日付 | 出来事 | 影響 |
|---|---|---|
| 1/30 | Claude Cowork に法務・財務分析自動化機能を追加 | Salesforce等の業務ソフト企業の株価が急落 |
| 2/5 | Claude Opus 4.6 発表（100万トークンのコンテキスト） | 金融サービス関連銘柄に売り |
| 2/17 | Claude Sonnet 4.6 発表 | 開発者向けモデルの世代交代 |
| 2/20 | Claude Code Security（脆弱性管理）発表 | サイバーセキュリティ銘柄に波及 |
| 2/25 | Vercept社を買収（AI操作能力の強化） | コンピュータ操作AIの本格化 |
約2週間おきにメジャーアップデートを繰り返す異例のペースでした。
出典: 三井住友DSアセットマネジメント / Medium: Anthropic's Explosive Start to 2026
この怒涛の進化の裏側には、AI開発の現場で起きている構造変化があります。
Anthropic、OpenAI、Googleの開発チームでは、トップエンジニアがコードを手で書く時間が激減しています。代わりに「AIエージェントのハーネスを設計し、エージェント組織を率いる」役割にシフトしました。設計と判断に集中し、実装は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?
まずは皆さんで考えてみてください。
AIがコードを書く部分はどんどん増えます。人間の仕事は「何を作るか決める」「AIの出力が正しいか判断する」「設計をレビューする」に集中していきます。今日体験した「仕様を書く→AIに実装させる→人間が判断する」のサイクルは、3年後にはさらに当たり前になっているはずです。
GitHub Copilotが3年後にどうなっているかはわかりません。別のツールが主流になっているかもしれません。ただ、「AIに正しい文脈を渡す」「仕様を先に書く」「規約でAIの出力を制御する」という設計思想はツールに依存しません。今日学んだことは、ツールが変わっても使えます。
業務で必要になったデータ変換、集計ツール、ちょっとした自動化。今日の研修で体験した手法があれば、これまで依頼していた作業を自分で素早く作れるようになります。AIを使いこなせるエンジニアは、対応できる仕事の範囲が大きく広がります。
GitHub Copilot Workspace（Issue→Plan→Implement→PRを自動化する構想）や、Agent Modeの拡張、Copilot Extensionsによるサードパーティ連携など、ロードマップは加速しています。ツールの機能追加を追いかけるより、今日学んだ「仕様を先に書き、Agent MDで制御し、人間が判断する」フレームワークを土台にしておけば、新機能が出ても使いこなし方の応用が利きます。
研修が終わった時点で、以下が揃っていれば成功です。
spec.md（議事メモから作成した仕様書）.github/copilot-instructions.md（自チーム用Agent MD）git log で2回分のcommit履歴が見える今日の研修で学んだ内容をさらに深めたい方、客観的なスキル証明が欲しい方に向けて、関連する資格を紹介します。受験を強制するものではございません。キャリアの方向性に合わせて、興味があるものを検討してみてください。
GitHub Copilotの活用能力を認定する公式資格。プロンプトエンジニアリング、責任あるAIの使用、各プランの機能差、プライバシー保護まで出題されます。2026年1月に試験内容が大幅改訂され、日本語での受験にも対応済み。今日学んだ copilot-instructions.md やコンテキスト設計の知識がそのまま活きます。
受験料 $99 / 選択式 60問 120分 / オンライン監督付き / 合格ライン 70%前後
GitHubの基本概念、リポジトリ管理、コラボレーション機能の理解を問う入門資格。今日の研修で git init / commit の流れを体験しましたが、ブランチ戦略やPull Requestなど、チーム開発に必要な知識を体系的に押さえたい場合に有効です。
受験料 $99 / 選択式 75問 120分 / オンライン監督付き / 合格ライン 70%前後
生成AI活用普及協会（GUGA）が運営する国内資格。2026年から年5回開催に拡大されました。最新シラバスではGPT-o1/o3、Claude、Copilot、RAG、AIエージェント、AI新法まで範囲が広がっています。生成AIの全体像を体系的に掴みたい方の入口として手堅い選択肢です。
受験料 11,000円(税込) / 4択 60問 60分 / オンライン / 合格率 約70%
日本ディープラーニング協会が主催するエンジニア向けの国内最難関AI資格。ディープラーニングの理論と実装能力を問います。今回の研修テーマとは直接重ならない領域ですが、AIの仕組みを深く理解したいエンジニアには価値があります。JDLA認定プログラムの修了が受験の前提条件になっている点に注意してください。
受験料 33,000円(税込) / 選択式+記述 約100問 120分 / 会場 / 合格率 約60-70%
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パスポートが間口が広く、チームメンバーに勧めやすいでしょう。