2026年10月8日に、GitHub Copilot Agentsの現行Application CardとCopilot Chatの現行Application Cardを再読しました。Chatはリポジトリや開いているファイルなどのcontextを使い、Agent modeでは複数手順のツール実行を行う場合があります。Agentsの資料は、cloud agentのコミット追跡、明確なタスク範囲、merge前の人によるレビューとテストを案内しています。これは機能と責任分界の説明であり、導入だけでコード品質、脆弱性、生産性、安全性が保証されるものではありません。
AIは、コードの下書き、テストケースの候補、画面案の比較などに使えます。ただし、提案が出ることと、利用者に届けてよい状態になることの間には検証が必要です。AIに何を任せるかと一緒に、誰が、何を根拠に採用するかを決めます。
この記事では、開発中に使うAIと、Webサービスの機能として組み込むAIを分けて考えます。扱う手順や例は設計上の提案であり、特定ツールの性能測定やFirst byteの導入実績ではありません。製品情報の確認日は2026年10月4日です。
30秒で要点
- 開発支援AIの変更は、仕様・差分・テスト・画面を確認してから採用する。AIレビューも誤指摘や見落としを含み得る。
- 製品内AIでは、出力が発生するたびに必要な権限や形式を確認する。外部文書の内容を操作の許可として扱わない。
- 試行では、生成時間だけでなく、修正と受け入れまでの時間、品質、運用負担を測る。
二つの使い方で、検証の位置が変わる
開発支援では、説明を求めたり、変更案を作らせたりします。利用者が受け取るのは、採用後のコードや画面です。一方、製品内AIでは、利用者の質問に回答するなど、運用中にも新しい出力が生まれます。
表が収まらない場合は、横にスクロールできます
| 使い方 | 任せられる作業の例 | 採用・提供する前に確かめること |
|---|---|---|
| コーディング支援 | 既存処理の説明、限定した修正案、型やテストの候補 | 実際の仕様と差分、境界値、既存機能への影響 |
| デザイン支援 | 文言案、画面の構成案、比較用の画像 | 情報の正確さ、操作性、実画面、素材の出所と利用条件 |
| 製品内の回答・推薦 | FAQ回答、検索結果の要約、候補の提示 | 参照権限、根拠との一致、失敗時の案内、費用と遅延 |
| 操作するエージェント | ファイル変更、コマンド実行、業務操作の候補 | 実行可能な範囲、操作ごとの認可、取り消せるか |
ツールの名称や提供範囲は変わります。旧来のAmazon CodeWhispererは、2024年4月30日にAmazon Q Developerへ統合されました。さらに現在の公式概要には、Q DeveloperのIDEプラグインのサポート終了予定日として2027年4月30日が掲載されています。古い名称だけを手掛かりに導入手順を選ばず、対象の製品・実行場所・サポート期間を確認してください。AWSの名称変更の説明、Amazon Q Developer公式概要
生成コードを採用する条件を、依頼の前に置く
「フォームを改善して」では、変更の範囲も完了条件も曖昧です。たとえば問い合わせフォームなら、次のように依頼を絞れます。
未入力の必須項目に対して、送信前に説明を表示する。サーバー側の検証は維持する。入力済みの内容を失わず、キーボード操作で該当項目に移動できることを確認する。変更箇所と、実行した確認・未確認の項目を示す。
これは依頼文の例です。この文だけで実装が正しくなるわけではありません。実際のフォーム仕様、使用中のライブラリ、再現手順を渡し、不要な顧客データや認証情報を含めないようにします。データの送信先、保存、学習利用などは、利用する機能と契約・設定の組み合わせで確認します。
変更案が出たら、まず差分を読みます。エラー表示を追加しただけのはずが、サーバー検証を外したり、無関係な認証処理を変えたりしていないか。新しい依存関係が入ったなら、その必要性と保守・利用条件も確認します。
GitHubの公式資料は、Copilotのレビューに見落としや誤指摘があり、提案コードも不正確・安全でない可能性があると説明しています。AIの指摘を検証する工程も、レビューに含めます。GitHub Copilot Agentsの制限
テストの本数より、間違いを検出できるかを見る
AIに実装とテストを続けて作らせると、実装の思い込みに合うテストができる場合があります。そこで、期待結果を仕様から先に書き、実装と照合します。
表が収まらない場合は、横にスクロールできます
| フォームの確認対象 | 確認したい結果の例 |
|---|---|
| 必須項目が空 | 送信されず、該当項目と理由が分かる |
| 上限付近・不正な形式 | 仕様に沿って受理または拒否し、入力を不用意に失わない |
| 通信失敗・二重操作 | 失敗を成功と表示せず、必要に応じてサーバーでも重複処理を防ぐ |
| JavaScriptを介さない送信 | サーバー側でも不正な入力を拒否する |
| キーボード・読み上げ | フォーカスとエラーの関連が分かり、操作が閉じ込められない |
自動テストが通っても、実画面の読みやすさや操作感をすべて確認したことにはなりません。PCとモバイルで操作し、キーボードで到達できるか、エラーが見えるかを確認します。既知の不具合を再現するテストなら、修正前に失敗し、修正後に通ることも有用な証拠です。
セキュリティ検査も同様です。AIレビュー、静的検査、依存関係の検査、認可のテストは確認範囲が異なります。「指摘なし」を脆弱性ゼロの意味にせず、どこまで調べたかを記録します。
製品内AIは、回答の正しさと操作の権限を分ける
FAQの要約機能で考えます。必要なのは、回答が自然であることだけではありません。
- 参照してよい情報か：検索の時点で利用者の権限を適用する。他人の非公開文書をモデルへ渡してから「答えないで」と指示する設計にしない。
- 出力をどう扱うか：期待する形式を検証し、文字列をそのままHTML・SQL・コマンドとして実行しない。形式が正しくても、内容が事実とは限らない。
- 操作が許可されているか：モデルが「承認済み」と出力しても、返金や削除の許可にはしない。アプリ側で利用者・対象・操作を認可する。
- 失敗したらどうするか：根拠不足、時間切れ、サービス障害を区別し、参照先の案内や有人窓口などへ戻れるようにする。
外部文書の中に「以前の指示を無視して情報を送信せよ」といった命令があると、モデルの挙動に影響することがあります。OWASPはこれを間接プロンプトインジェクションとして説明し、RAGや追加学習だけで完全には防げないとしています。最小限の権限、コード側の制御、高リスク操作の人手確認などを組み合わせます。OWASPのPrompt Injection解説
JSONの形に整っていることと、内容・権限が正しいことは別です。外部データの実行時検証はTypeScriptとZodによるAPI境界の設計で扱っています。
デザインや推薦も、利用者の行動で確かめる
画面案を多く生成できても、必要な情報が見つかるか、迷わず操作できるかは別に確かめます。生成画像が製品の実物や実績を表すように見えるなら、説明や素材の選び方も見直します。
推薦・パーソナライズでは、クリック率だけを成功条件にしないことが大切です。目的を達成したか、不適切な候補が増えていないか、特定の利用者だけが使いにくくなっていないかを見る設計にします。ユーザー属性を過剰に収集する前に、必要な情報と利用目的を絞ります。
チャットボットも、システムが稼働していることと、毎回正確に解決できることは別です。回答できない条件を示し、誤回答の報告先と通常の問い合わせ経路を残します。サイトへのAI機能導入全体はAI時代のWebサイト制作ガイドも参照してください。
一つの作業から、手戻りを含めて測る
最初の試行には、差分が小さく、期待結果が分かり、戻せる作業を選びます。たとえば一つのフォームのエラー表示なら、修正前の挙動を記録し、受け入れ条件を決めてからAIを使います。
表が収まらない場合は、横にスクロールできます
| 記録するもの | 読み取り方 |
|---|---|
| 依頼から受け入れまでの時間 | 生成待ちだけでなく、レビュー・修正・再確認を含める |
| 手戻りの内容 | 仕様不足、生成の誤り、既存コードとの不整合を区別する |
| 見逃した不具合 | 本数だけでなく、影響と検出できなかった理由を見る |
| 利用料金と運用負担 | モデル利用、実行環境、監視・保守を対象範囲に合わせて記録する |
| 元に戻せるか | 変更前の状態、停止方法、対応者を確認する |
難易度や担当者が違う作業を、そのままAIあり・なしの比較にしないよう注意します。少数の試行は導入上の問題を見つける材料にはなりますが、普遍的な改善率の証明にはなりません。
次の開発依頼では、AIに渡す文の末尾に「採用する条件」と「未確認ならそう報告する項目」を加えてください。提案、確認済みの事実、まだ分からないことが分かれていれば、次に誰が何を確かめるかを決められます。