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つの機能を確認します。
| 機能 | 起動方法（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: で明示的に渡すとさらに確実です。
「何を」「どの形式で」「何を除外して」生成するか。制約指示が効くかどうかが出力品質の分かれ目になります。
同じ指示でも、渡す文脈で出力がまるで変わることを自分の手で確認します。
Copilot Chat（Ctrl+Shift+I / Cmd+Shift+I）を開き、以下をそのまま貼り付けてください。何もファイルを開いていない状態で試します。
出力を確認してください。型ヒントはありますか? docstringのスタイルは? 変数名は英語ですか日本語ですか? エラー処理はどうなっていますか?
VS Codeで新しいファイル requirements.md を作成し、以下の内容を貼り付けて保存してください。
新しいCopilot Chatを開き（既存のチャットではなく新規で）、今度は #file: で要件ファイルを渡してから同じ指示を出してください。
以下の観点で差を確認してください。
| 観点 | 文脈なし（Step 1） | 文脈あり（Step 3） |
|---|---|---|
| 型ヒント | なし or 不完全 | 全引数・戻り値に付与 |
| docstring | なし or 自由書式 | Google Style |
| 変数名 | 日本語混じり | 英語で統一 |
| エラー処理 | bare except or なし | 例外型を指定 |
| ファイルパス | 文字列 | pathlib |
プロンプトの一文字も変えていません。変えたのは「渡した文脈」だけ。要件ファイル1枚で出力品質がここまで変わります。この差を仕組みとしてチームに定着させるのがSession 03で扱うAgent MDです。
copilot-instructions.md の設計思想は Claude Code の CLAUDE.md が原型です。エージェントモードも同じ系譜。GitHub Copilotの「新機能」として見るのではなく、AI開発ツールに共通する設計思想として理解すると、ツールが変わっても応用が利きます。
Claude CodeGitHub Copilot
Cursor / Kiro仕様を書かずにいきなりコードを書かせると、AIは「動くが使えないもの」を量産します。メモから要件を抽出し、Markdownで構造化し、仕様書にまとめる。この工程を経てから実装に入ると手戻りが激減します。
メモからの要件抽出で、制約の有無が出力にどう影響するか試します。
Copilot Chatに以下を貼り付けてください（制約なし版）。
出力を確認してください。メモに書かれていない機能（認証、通知、ダッシュボード等）が追加されていませんか?
新しいチャットを開き、末尾に制約を1行追加したバージョンを試してください。
制約なし版ではAIが「親切心で」認証機能、ログ出力、多言語対応などを追加しがちです。制約あり版ではメモに根拠がある機能だけが出力されます。「追加しないで」のたった一文が、仕様のスコープ膨張を防ぐ防波堤になります。
関数の上にコメントを先に書き、Copilotにコード補完させる手法です。仕様駆動開発の考え方をコードレベルに落とし込んだもの。実際にやってみてください。
VS Codeで practice.py を新規作成し、以下を貼り付けてください。
def 行の末尾にカーソルを置いてEnterキー。Copilotがコメントと型ヒントを読み取り、関数本体を提案します。灰色のサジェストが出たら Tab で受け入れてください。
コメントの「メソッドチェーンを使用する」を「forループで集計する」に変えてみてください。Copilotの出力が変わるのを確認します。コメントが仕様として機能していることが体感できるはずです。
型ヒント + コメント + 関数名の3点が揃うとCopilotの推測精度が跳ね上がります。Agent MDで「型ヒント必須」「docstringはGoogle Style」を設定しておくと、この精度がさらに安定します。詳しくは GitHub Copilot コード補完ガイド を参照してください。
議事メモから要件を抽出し、Markdown仕様書に構造化します。制約指示の効果を自分の手で試してください。
docs/議事メモ_データ分析案件.md を開いてください。営業企画部から開発チームへの依頼内容が書かれています。この1枚のメモが今日の全ての出発点です。
Copilot Chat（Ctrl+Shift+I）を開き、以下のように指示してください。
「追加しないで」の一文がないとAIは親切心で勝手に要件を足します。認証機能やログ出力など、メモに根拠がない機能が混ざる。気になる要件があれば「これはメモのどこに根拠がありますか?」と問い返してください。
抽出した要件をもとに、仕様書を作成します。以下のプロンプトを使ってください。
出力をプロジェクトルートに spec.md として保存してください。
研修の最初にフォルダで git init を実行してから、仕様書をcommitします。
制約なしで「この議事メモから要件を整理して」とだけ伝えると、AIは以下のような要件を勝手に追加しがちです。
・ユーザー認証機能（メモに認証の話は一切ない）
・メール通知機能（誰も頼んでいない）
・ダッシュボードUI（CLIで十分なのにWebアプリにする）
・多言語対応（国内業務なのに英語対応を入れる）
AIの「親切な追加」は仕様書のスコープを膨張させます。「メモに書かれていない要件は追加しないで」の一文が防波堤になります。
制約指示があるときとないときで出力がどう変わるか。隣の人と仕様書を見比べてみてください。同じメモから始めても、粒度や構成が違っているはずです。
先方から最も強い要望があったテーマです。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 使用 |
「設定しないで使う」と「設定して使う」の差がこれです。同じツールでも使い方で生産性が変わります。
上のデモで見た差を、自分の環境で再現します。同じプロンプトをAgent MDなし/ありの両方で試してください。
.github/copilot-instructions.md のファイル名を変更して無効にします。
新しい Copilot Chat を開いて、以下をそのまま入力してください。
出力をよく見てください。型ヒントはあるか、docstringのスタイルは何か、変数名は英語か日本語か、例外処理はどうなっているか。
新しい Copilot Chat を開いて（既存チャットではなく新規）、Step 2と全く同じプロンプトを入力してください。
Agent MDなしの出力とありの出力を見比べて、以下の観点で差を確認してください。
| 確認する観点 | Agent MD なし | Agent MD あり |
|---|---|---|
| 型ヒント | あなたの出力は？ | あなたの出力は？ |
| docstring スタイル | ||
| 変数名の言語 | ||
| 例外処理の書き方 | ||
| ファイルパスの扱い方 |
Copilotのモデルやバージョンによっては差が小さいこともあります。その場合は新しいチャットで再度試すか、Ctrl+Shift+P → Reload Window を実行してから試してください。Agent MDの読み込みタイミングの問題で差が出にくいケースがあります。
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 を使い、選択範囲への直接操作を試します。
practice.py の関数全体を選択し、Ctrl+I（Cmd+I）で「この関数を日本語で説明して」と入力してください。
同じ関数を選択した状態で Ctrl+I → 「エラーハンドリングを追加して。FileNotFoundError をキャッチして日本語でメッセージを出す」と指示してください。
同じ関数を選択 → Ctrl+I → 「この関数のpytestテストを書いて。正常系と空DataFrameの異常系を含めて」。Agent MDが効いていれば、テストも規約準拠で出力されます。
Copilot Chatはプロジェクト全体の質問に向いています。インラインチャットは「今見ているこのコード」に対して操作する場面で使います。選択範囲が文脈になるので、指示が短くても精度が高い。実務では両方を使い分けてください。
テンプレートをベースに、自チームの実態に合わせた copilot-instructions.md を作成します。
templates/copilot-instructions.md を開いてください。ここに書かれたルールがCopilotへの常駐指示になります。
.github フォルダを作成し、テンプレートをコピーして編集してください。
自チームで使っている言語・バージョンは合っているか。追加したいコーディング規約はあるか。チーム内で「この書き方はやめてほしい」と思っているものはあるか。テンプレートはあくまでたたき台です。自分たちの実態に合わせて編集してください。
新しい Copilot Chat を開いて以下を指示してください。
出力に型ヒントが付いているか、docstringがGoogle Styleか、変数名が英語になっているか確認してください。
ファイルパスが .github/copilot-instructions.md になっているか確認してください（サブフォルダに作っていないか）。既存のチャットには反映されないことがあるので、新しいチャットで試してください。それでもダメなら Ctrl+Shift+P から「Reload Window」を実行します。
成果物: 実務のリポジトリにそのまま持ち帰れる 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、プロトタイプ、個人開発 | 業務アプリ、チーム開発 |
同じ機能をバイブコーディングと仕様駆動の2通りで依頼し、出力の差を体感します。
Copilot Chat に以下をそのまま入力してください。曖昧な指示を意図的に出します。
新しい Copilot Chat を開いて、今度は仕様を明確にして指示します。
バイブコーディングの出力は何を作ったか。仕様駆動の出力は何を作ったか。どちらが業務で使える形に近いか、考えてみてください。
バイブコーディングが悪いわけではありません。「とりあえず動くものを見たい」場面では速い。ただ業務コードとして使うなら、仕様を先に固めてから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 | API従量課金 | 全主要言語 | 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パスポートが間口が広く、チームメンバーに勧めやすいでしょう。