GitHub Copilot に OpenTelemetry 対応が追加、Agentic Autofix は Copilot Memory と連携 — 管理者が確認すべきこと

GitHub Copilot の changelog では、2026 年 9 月 22 日に OpenTelemetry (OTel) 対応、25 日に Agentic Autofix と Copilot Memory の連携という、2 つの発表が続きました。どちらも managed-settings.json や Copilot のポリシーを管理する立場の人に関わる変更です。

混同しやすい点が 2 つあります。1 つは、2 つの発表をひとまとめにして、片方を設定すれば両方に対応できると考えてしまうことです。もう 1 つは、どちらも Public Preview だと決めつけてしまうことです。Public Preview と明記されているのは Agentic Autofix × Copilot Memory のほうで、OpenTelemetry 対応は changelog にもリンク先のドキュメントにも preview の表記が見当たりません。さらに OpenTelemetry は、どのクライアントに対応するかについて、changelog とリファレンスの記載が食い違っています。

この記事では、GitHub の変更履歴 (2026 年 9 月 22 日・25 日) と、そこからリンクされた公式ドキュメントをもとに、2 つの発表が何を変えるのかを整理します。加えて、8 月に発表された Copilot for JetBrains の memory・Ollama・サンドボックス管理 との関係、公式の記載が食い違う点、管理者が確認すべきことをまとめます。

何が発表されたのか — 2 つの発表を分けて整理する

先に全体像を一覧にします。

2 つは独立した発表です。同じ Copilot の changelog に近い時期に載っているため混同しやすいですが、対象となる機能も設定箇所も別です。「OTel の設定をしたから記憶機能も対応済み」という読み方はできません。 それぞれの内容を分けて確認してください。

OpenTelemetry で何が変わったか

9 月 22 日の changelog によると、GitHub Copilot app が、エンタープライズの managed-settings.json にある telemetry プロパティを通じて OpenTelemetry の設定に対応しました。管理者は、エージェントの活動データを組織の監視ツールへ送信できます。

想定されている用途として、発表では次の 3 つが挙げられています。

• エージェントのセッションを分析する
• 想定外の挙動を調査する
• モニタリング設定を一元管理する

送信されるデータと、既定で送らないもの

changelog がリンクしている OpenTelemetry for agent monitoring には、Copilot が送るデータが 3 種類に分けて書かれています。

既定では、プロンプト・応答・ツールの引数は含まれません。 含めることもできますが、ドキュメントは、コード・ファイルの中身・ユーザーのプロンプトといった機密情報が入り得ると注意しています。changelog も、有効にする前にコンテンツキャプチャの設定を確認するよう案内しています。「何を送るか」と「何を送らないか」の境界は、監視基盤の担当者と共有しておいてください。

送信先と telemetry の設定キー

送信先は、OpenTelemetry Protocol (OTLP) に対応したバックエンドです。OTLP を直接受け取れるバックエンドはそのまま使え、そうでない場合は OpenTelemetry Collector を置いて受信・加工・転送します。対応する監視ツールの一覧は示されておらず、ドキュメントは実装例として、Microsoft のドキュメントにある Grafana での監視例を紹介しています。

設定キーは managed settings のリファレンス に載っています。リファレンスの設定例から telemetry の部分を抜き出すと次のとおりです。

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "http/protobuf",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "copilot",
    "resourceAttributes": {
      "deployment.environment": "production"
    },
    "headers": {
      "Authorization": "Bearer TOKEN"
    }
  }
}

managed settings で配った設定は対象のユーザー全員に強制され、ユーザー側では上書きできません。managed settings を扱えるのは Enterprise owners で、導入ガイド では .github-private リポジトリに copilot/managed-settings.json を置く手順が案内されています。

対応クライアントの記載が食い違っている

changelog は「GitHub Copilot app」での対応を発表していますが、リファレンスの記載はこれと一致しません。

リファレンスの本文と対応表はどちらも GitHub Copilot app を対応に含めておらず、本文と対応表のあいだでも JetBrains IDEs の扱いが揃っていません。導入ガイドも「すべてのクライアントがすべてのプロパティに対応しているわけではない」としています。どれが正しいかは、公式ページだけでは判断できません。設定したら、使っているクライアントごとにバックエンドへデータが届いているかを確かめてください。

JetBrains 向けの OpenTelemetry 設定 (8 月) との違い

すでに JetBrains 向けの OpenTelemetry 管理設定 (2026 年 8 月 11 日発表分) を済ませた組織にとって気になるのは、今回の対応で追加の設定が要るかどうかです。

リファレンスでは、OpenTelemetry の設定は managed-settings.json の telemetry という 1 つのキーで、クライアントごとに別のキーがあるわけではありません。対応表には JetBrains IDEs も対応として載っています。ただし前節のとおり、本文は Copilot CLI と VS Code しか挙げていません。8 月の JetBrains 向けの設定と今回の telemetry キーの関係も、今回のドキュメントには書かれていません。JetBrains と他のクライアントを併用している組織は、クライアントごとにデータの到着を確かめるのが確実です。「設定したはずなのに、片方のクライアントだけ監視できていない」という事故は、この確認を飛ばすと起こりやすくなります。

FIXIT

JetBrains のとき設定したから、これはもうやらなくていいんじゃないの？

Tsukasa

やらなくていいとは言い切れません。判断の軸は、各クライアントからデータが実際に届いているかです。

Agentic Autofix と Copilot Memory の連携

もう 1 つは 9 月 25 日の changelog で、セキュリティアラートの自動修正機能である Agentic Autofix が、Copilot Memory を使うようになったという変更です。対象は、Copilot Memory を有効にしている顧客です。

仕組みは循環構造になっています。Agentic Autofix は、セキュリティアラートの解決に役立つ文脈として既存の memory を確認します。修正を作ると、その修正パターンを将来の利用のために新たな memory として保存します。つまり、1 回の修正が次の修正の材料になるという設計です。

発表原文にはこうあります。

These memories can help agentic autofix resolve additional security alerts and teach other GitHub Copilot features (e.g., Copilot code review, Copilot cloud agent) about secure development patterns unique to your repository.

保存された記憶は、追加のセキュリティアラートの解決に役立つだけでなく、リポジトリ固有の安全な開発パターンを他の GitHub Copilot 機能に伝えるとされています。原文は例として Copilot code review と Copilot cloud agent を挙げています。PR の承認まで担うようになった Copilot code review も、Autofix が保存した修正パターンを参照する側に入ります。

提供段階も明記されています。

Both agentic autofix and Copilot Memory are available in public preview.

Agentic Autofix と Copilot Memory はどちらも Public Preview です。前節の OpenTelemetry 対応とは、この点で扱いが異なります。

Copilot Memory の対象プラン・保存期間・使われる範囲

changelog がリンクしている About GitHub Copilot Memory には、管理者が判断に使う項目が一通り書かれています。

リポジトリ単位の事実を作れるのは、そのリポジトリへの書き込み権限を持ち、Copilot Memory を有効にしているユーザーの操作に限られます。事実には根拠となるコードへの引用が付いており、使う前に現在のブランチと照合され、裏付けが取れたものだけが使われます。

JetBrains 向けの Copilot memory (8 月) との関係

「Copilot Memory」という名称は、8 月と 9 月の発表の両方に出てきます。8 月 11 日の JetBrains 向けの発表では、Copilot memory はエージェントチャットのセッションをまたいで情報を保持・呼び出す機能として案内されていました。

About GitHub Copilot Memory は、Copilot Memory を 1 つの機能として説明しています。ある Copilot 機能が記録した事実や好みは、別の機能でも使われます。

Facts and preferences captured by one Copilot feature can be used by another.

ドキュメントの例では、cloud agent が見つけたデータベース接続の扱い方を、後から code review が PR の不整合の指摘に使います。Autofix が保存した修正パターンも、同じ仕組みの中で他の機能に使われる前提です。一方、同じページで Memory を使う機能として挙がっているのは cloud agent・code review・CLI・agentic autofix の 4 つで、JetBrains は含まれていません。8 月の JetBrains 向けの memory がこの一覧とどう対応するかは、ドキュメントに書かれていません。

公式の記載を突き合わせる — 表で確認する

管理者が判断に使いたい項目を、changelog とリンク先のドキュメントで突き合わせると次のようになります。

多くの項目は、changelog がリンクしている先まで読めば確かめられます。記載が食い違っているのは、OpenTelemetry の対応クライアントです。ここは推測で埋めず、実際のクライアントで確かめるか、GitHub 側に確認するのが安全です。

2 つの発表を並べて見る — ガバナンスの 2 つのレバー

ここまでの 2 つの発表は、別々の変更でありながら、企業のガバナンスという観点では共通のねらいを持っています。

1. OpenTelemetry 対応。エージェントが「何をしたか」を組織の監視基盤に出す、可観測性のレバーです
2. Agentic Autofix × Copilot Memory。過去の修正判断を記憶し、次のセキュリティ対応に活かす、自動化の学習のレバーです

FIXIT

2 つとも Public Preview なんだよね？

Tsukasa

いえ、明記があるのは Autofix×Memory だけです。

FIXIT

じゃあ、扱いを変えたほうがいいの？

Tsukasa

はい。判断の軸は preview の明記の有無です。明記のある Autofix×Memory は検証段階として扱います。

この 2 つのレバーは、2026 年 9 月 9 日に一般提供されたエージェント操作の管理権限とも関係があります。管理権限は、シェルコマンドやファイルアクセス、ネットワークドメインを deny / ask / allow に分類する設定で、同じ managed-settings.json の permissions キーで配ります (詳しくは AI 駆動開発のセキュリティ設計)。可観測性 (今回の OTel 対応)・自動化の学習 (Autofix×Memory)・実行の制御 (エージェント操作の管理権限) という 3 つのレバーが並んでいると捉えると、全体像が整理しやすくなります。

Autofix×Memory は Public Preview なので、今すぐ本番のガバナンス方針にそのまま組み込むのは避けたい機能です。仕様が変わる前提で、まずは検証環境や限定的な範囲で挙動を確かめ、GA (一般提供) のタイミングで正式な方針に落とし込みます。OpenTelemetry は preview の表記こそありませんが、対応クライアントの記載が揃っていないため、クライアントごとにデータの到着を確かめてから本番の監視に組み込みます。

管理者が今確認すべきことチェックリスト

以下は公式の作業指示ではなく、本記事が提案する確認事項です。GitHub が推奨する順序ではありません。

この中でもっとも見落としやすいのは、**「便利になった分、レビューを省略してよいと誤解される」**ことです。記憶を参照して修正案の精度が上がったとしても、それは提案の質が上がったという話であり、検証が不要になったわけではありません。差分とテスト結果を確認する運用は、記憶機能の導入前後で変える必要がないというのが、この記事の立場です。

FIXIT の運用 — Public Preview 機能の取り扱い

FIXIT は AI 駆動開発のクリエイティブスタジオとして、クライアントワークの中で Copilot をはじめとする AI コーディングツールのガバナンス設計を扱っています。Public Preview の機能は、契約しているプランや管理画面の実際の表示を確認したうえで、まず検証環境で挙動を確かめ、本番のポリシーに組み込むかどうかを段階的に判断する、という姿勢を基本にしています。仕様が確定していない機能を早期に本番のガバナンス方針へ固定してしまうと、後から仕様が変わったときの手戻りが大きくなるためです。

「AI エージェントが何をしたかを説明できる状態」を作りたい、あるいは「便利さの代償でセキュリティ判断が甘くならないようにしたい」という相談は、情報セキュリティコンサルタント で承っています。生成 AI の利用ガイドライン整備や、AI 駆動開発の実運用を踏まえたリスク設計を、今回のような Public Preview 機能の扱い方も含めてご相談いただけます。ツールごとのガバナンス設計や定着支援は AI 開発ツール定着支援 でも対応しています。

まとめ

2026 年 9 月に発表された GitHub Copilot の 2 つの機能強化は、別々の発表でありながら、どちらも企業のガバナンスに関わる変更です。

• OpenTelemetry 対応 (9/22) は、traces・metrics・events を OTLP 対応のバックエンドへ送れるようにする変更です。プロンプト・応答・ツールの引数は既定で送られません
• 設定は managed-settings.json の telemetry キーで行い、認証は headers で渡します。対応クライアントは、changelog とリファレンスで記載が食い違っています
• Agentic Autofix × Copilot Memory (9/25) は、修正パターンを記憶して次の修正に活かす変更で、Public Preview と明記されています
• Copilot Memory は有料の全 Copilot プランが対象で、リポジトリ単位の事実は同じリポジトリでしか使われず、未使用なら 28 日で自動削除されます
• 8 月の JetBrains 向けの設定との関係は、ドキュメントに書かれていないため、両方のクライアントで確かめます

Agentic Autofix×Memory は Public Preview として検証から始め、OpenTelemetry は使っているクライアントごとにデータの到着を確かめてから本番の監視に組み込むことをお勧めします。

自社のガバナンス方針にこれらの発表をどう位置づけるべきか整理したい場合は、情報セキュリティコンサルタント からご相談ください。ツール導入そのものの進め方を含めて検討したい方は、AI 開発ツール定着支援 や お問い合わせ もご利用いただけます。