NID GitHub Copilot研修 NID GitHub Copilot研修すでに GitHub Copilot を補完として日常的に使われている前提で、その先にある「AIとどう協働すると開発全体が速く・確かになるか」を扱います。プロンプトの設計、文脈の渡し方、出力を評価する力、セキュリティの線引き、そして上流から下流までをAIと進める設計スタイルまでを、午後の演習につながる形で整理します。
コードを速く打つことの価値は、AIの登場で確実に下がりました。これからのエンジニアの価値は、何を作るかを決め、AIの出力を評価し、責任を持って統合できることに移っています。
補完ツールとしての Copilot は、すでに皆さんの日常に入っています。1行ずつの提案を受け入れる使い方から一歩進めて、タスクの単位でAIに任せ、その結果を読み解いて整える。この研修ではその切り替えを扱います。手を動かす速さではなく、AIに何をどう頼み、返ってきたものをどう判断するかが軸になります。
解くべき問題を分解し、AIに渡せる単位の問いへ言い換える。曖昧な要望のまま投げず、前提と制約を言葉にする。
返ってきたコードが正しいか、要件を満たすか、隠れた副作用がないかを判断する。AIの自信ありげな誤りを見抜く。
生成物を既存のコードベースへ無理なく組み込み、最終的な品質に責任を持つ。AIは提案者で、判断者は人のまま。
NTTデータは生成AIを2025年度に約500プロジェクトへ適用し、開発工程全体で20%の生産性向上を目標に掲げています。日立製作所はプログラミング・単体テスト工程での適用効果が2024年度に50億円へ達したと報告しています。ツールを入れるだけでなく、使う側の進め方が成果を分けます。
AIを「賢い部下」や「万能の専門家」と見るとうまくいきません。膨大な事例を学んだ、文脈に弱く自信過剰な共同作業者だと捉えると、ちょうどよい距離感になります。
協働の基本は、人が方向を決め、AIが量をこなし、人が結果を引き受けるという分担です。AIは与えられた文脈の範囲で最もそれらしい答えを返しますが、その範囲の外にある前提や、自社・顧客固有の事情までは知りません。だからこそ、何を渡すかと、返ってきたものをどう確かめるかが、人の仕事として残ります。
| 場面 | AIに任せやすい | 人が押さえる |
|---|---|---|
| 実装 | 定型的な雛形、繰り返しの多いコード、テストコードの素案 | 設計の意図、命名や責務の妥当性 |
| 調査 | エラーメッセージの解釈、候補となる原因の列挙 | どの原因が本当かの切り分け、再現条件 |
| ドキュメント | 下書き、要約、コメントの素案 | 事実の正確さ、社外に出す表現 |
AIに頼む前に「自分なら30秒でどう答えるか」を一度想像してください。その仮説があると、返ってきた出力の良し悪しを判断しやすくなります。
プロンプトは呪文ではありません。やってほしいこと、前提、制約、出力の形を、相手が誤解しない順序で並べるだけです。Copilot Chat でも考え方は同じです。
補完だけを使っていると、プロンプトを書く機会は少なめです。しかし Chat やエージェントモードを使い始めると、依頼の質が結果を大きく左右します。良いプロンプトには共通の骨格があります。
| 要素 | 書くこと | 例 |
|---|---|---|
| Role / Goal（役割と目的） | 誰として、何を達成したいかを最初に置く | Java の保守担当として、この例外の原因を特定したい |
| Context（文脈） | 対象のコード、データ形式、使用バージョン、再現手順など判断に要る材料 | 対象は InspectionService.java、入力は data/equipment.csv |
| Constraint（制約） | 守ってほしい条件を明示する | 既存の設計を壊さない、外部ライブラリを足さない |
| Format（出力形式） | 返してほしい形を指定する | 原因と修正案を分けて、修正は差分で |
悪い例と良い例を比べると違いが見えます。
後者は役割こそ省いていますが、対象・症状・制約・出力形式がそろっています。午後の演習1で、この2つを実際に投げ比べます。
Java では型や例外の名前を、Python では実行コマンドや想定する Python のバージョンを文脈に入れると、的外れな提案が減ります。具体的な情報を渡すほど、AIは推測に頼らなくなります。
2025年は、感覚的にプロンプトを打つ進め方から、AIに渡す文脈そのものを設計する進め方への移行が進んだ年でした。これをコンテキストエンジニアリングと呼びます。
コンテキストエンジニアリングは、AIが処理する文脈、つまり指示・コード・ドキュメント・会話履歴を体系的に設計し管理して、出力の品質を安定させる取り組みを指します。同じAIでも、渡す文脈が整っているかどうかで結果は大きく変わります。
関係するファイルだけを開いて文脈に含める。無関係なコードまで渡すと、的を外した提案が増える。
命名規約や使ってよいライブラリ、レビュー観点をあらかじめ伝えておく。毎回書かずに済む形にする。
会話が長くなったら要点を整理し直す。古い前提を引きずらせない。文脈は鮮度が落ちる。
VSCode では、関連ファイルを開いておく、Chat に対象ファイルを明示的に添える、といった操作が文脈づくりそのものです。午後の演習では、開くファイルを絞ることで提案の精度が変わるのを体感します。
AIは、間違っているときも正しいときと同じ口調で答えます。評価する力とは、その自信に流されず、根拠を自分で確かめる習慣のことです。
生成されたコードを受け入れるかどうかは、最終的に人が判断します。判断の物差しをいくつか持っておくと、レビューの速さと確かさが両立します。
| 観点 | 確かめること |
|---|---|
| 正しさ | 要件どおりの結果を返すか。境界条件（空、末尾、ゼロ件）で破綻しないか。 |
| 副作用 | 既存の挙動を変えていないか。意図しない箇所まで書き換えていないか。 |
| 意図の一致 | 命名や構造が、自分たちの設計の言葉と合っているか。 |
| 過剰さ | 頼んでいない機能やライブラリを勝手に足していないか。 |
とくに気をつけたいのが境界条件です。たとえば一覧の末尾1件だけが処理から漏れる、文字列を == で比較して常に一致しない、といった誤りは、AIでも人でも起こします。テストや実データで確かめないと表面化しません。午後の不具合調査では、まさにこの種の誤りを扱います。
AIの出力は文法的に正しく、一見動きそうに見えます。だからこそ、動かして確かめる、テストを書く、実データで試すという基本が効きます。読んで納得しただけで通さないことが、評価する力の出発点です。
Copilot を業務で使ううえで、扱う情報の線引きと、生成物の検証は欠かせません。便利さと引き換えに、何を守るのかを言葉にしておきます。
顧客情報や認証情報、社外秘のコードを安易に貼らない。何をどこまで渡してよいかは、社内のルールに従う。
提案されたコードに脆弱な書き方が混じることがある。入力値の検証や例外処理の漏れは人が確認する。
生成コードの由来や依存ライブラリのライセンスを意識する。最終的な責任は利用する側にある。
GitHub Copilot のエージェントモードは、IDE 内でターミナルコマンドの実行までこなします。便利な反面、何を実行しようとしているかを確認せずに任せきりにすると、意図しない変更が入ることもあります。提案された操作の内容を読んでから承認する。この一手間が安全のための線です。
業務の Copilot は SSO と IP 制限のもとで運用されています。これは情報の流出経路を絞るための仕組みです。研修では講師は別環境から進め、演習素材は ZIP でお渡しします。受講者の皆さまは普段どおりの管理された環境のまま参加してください。
2025年以降、AIを前提とした開発の進め方には名前が付き、段階が見えてきました。Vibe Coding から Agentic Coding へ、そして仕様を先に固める進め方へという流れです。
| スタイル | 進め方 | 向く場面 |
|---|---|---|
| Vibe Coding | 自然言語のプロンプトでAIを大まかに誘導し、感覚的にコードを生成させる（2025年2月 Andrej Karpathy が提唱） | 素早い試作。規模が大きくなると破綻しやすい |
| Agentic Coding | 詳細な仕様に対し、AIエージェントを人の監督下で自走させて開発する | 仕様が固まった実装・調査・修正 |
| Spec-Driven Development | 詳細な仕様を先に固め、AIエージェントにその仕様へ沿って実装させる | 規模のあるコード・保守が前提のコード |
業務の現場では、感覚で投げる進め方は試作までです。規模のあるコードや保守が前提のコードでは、何を作るかを先に決め、AIに量をこなさせ、人が評価して統合する流れが安定します。Copilot のエージェントモードは、この「量をこなす」部分を IDE の中で担います。
進め方の名前を覚えること自体が目的ではありません。今の自分のタスクが、試作なのか、仕様の固まった実装なのかを見極め、AIへの任せ方を変える。それが実務での使い分けです。
上流の要件定義から下流の実装・テストまでを、AIと一気通貫で進める。そのとき支えになるのが、振る舞いやテスト、ドメインを軸にした設計の方法論です。
AIに実装を任せるほど、何を作るかの定義が結果を左右します。曖昧な要件はそのまま曖昧なコードになります。逆に、振る舞いやテストが言葉になっていれば、AIはそれを手がかりに精度の高い実装を返します。代表的な方法論を整理します。
期待する振る舞いを Given-When-Then のシナリオで記述し、仕様兼テストとして開発を駆動する。AIに渡す要件の言語化と相性がよい。
実装前にテストを書き、通す最小実装とリファクタリングを繰り返す。AIにテストを起点にコードを書かせる流れに合う。
業務ドメインの言葉とモデルを中心に構造を設計する。境界づけられたコンテキストとユビキタス言語が要点。
詳細な仕様を先に固め、AIにその仕様へ沿って実装させる。上流の精度が下流の品質を決める。
これらに共通するのは、作るものを実装の前に言葉やテストで固めるという姿勢です。上流が曖昧なままAIに下流を任せると、速いだけで品質の伴わないコードが量産されます。要件を振る舞いに、振る舞いをテストに落とし、その上でAIに実装を任せる。上流から下流までの流れを設計する視点が、AI時代の設計力です。
NTTはAIを活用したシステム開発の効率化に向けて、設計・実装・テスト各工程へAIを組み込む開発標準と開発プロセスガイドを整備し公開しています。個人の工夫から組織の標準へという流れが、SIの現場でも進んでいます。
座学で扱った考え方を、午後は手を動かして確かめます。プロンプトの設計、問いを立てる力、エージェントモードでの不具合調査。3つの演習で一周します。
| 午後の演習 | 座学のどことつながるか |
|---|---|
| 演習1 プロンプトエンジニアリング（Java） | 3章のプロンプトの骨格、4章の文脈づくり |
| 演習2 AIに問いを立てる力 | 1章の問いを立てる力、2章の協働の分担 |
| 演習3 エージェントモードでの不具合調査（Java） | 5章の出力を評価する力、6章の安全な任せ方 |
演習で使う Java プロジェクトには、現場でも起こりがちな不具合が仕込んであります。読んで納得するだけでなく、動かし、エラーを読み、Copilot に問いを立て、返ってきた修正案を評価して取り込む。座学の言葉が、自分の手の中で動く感覚を持ち帰ってください。