GitHub Copilot Dreamingは、過去のCopilotセッションとコードレビューで受け入れられた指摘をバックグラウンドで振り返り、Copilotのメモリやリポジトリの指示ファイルを書き直す機能です。2026年10月28日のGitHub Universeで発表され、11月時点ではパブリックプレビューの段階にあります。変わるのはAIモデルではなく、Copilotに渡す文脈のほうです。この記事では、更新される3種類の対象、GPT-6.1 Solやセッション同期といった前提条件、エンタープライズ・組織・個人それぞれの有効化手順、AI creditsの消費と取り消せない変更への備えまでを、管理者と実装者の目線で整理します。
まとめ：Copilot Dreamingを有効にする前に決める対象範囲と課金の上限
先に決めるべきことは2つです。ひとつは対象範囲で、組織のCopilot Memoryで選んだリポジトリがそのままDreamingの実行対象になります。動きの止まった古いリポジトリまで含めると、変更が何も起きない実行にもAI creditsが使われます。パイロットは活発なリポジトリ数本に絞るのが安全です。
もうひとつは課金の上限です。Dreaming単独の予算は作れないため、AI credits全体の予算と使用停止の設定を先に入れておきます。加えて、無効化しても作成済みのメモリ変更やプルリクエストは元に戻りません。メモリは承認なしで書き換わり、指示ファイルやスキルはプルリクエストで提案される、という反映の違いを理解したうえで、レビュー担当を決めてから有効化してください。
GitHub Copilot Dreamingの仕組みと更新される3種類のコンテキスト
まずは何が入力され、何が書き換わるのかを押さえます。ここを曖昧にしたまま有効化すると、誰がどの変更を確認するのかが決まりません。Copilot全体の機能構成と対応モデルはGitHub Copilotの対応モデル・機能・料金で整理しているので、製品の全体像から確かめたい方はそちらを先にご覧ください。
モデルではなくメモリと指示ファイルを書き換えるバックグラウンド処理
GitHub Copilot Dreamingについての公式ドキュメントは、この機能を「Copilotのメモリとリポジトリのガイダンスを最新に保つバックグラウンド機能」と説明しています。対象のセッションやレビューの指摘から役に立つ情報を拾い、古くなった記述を直し、重複したメモリを消します。公式の例は、リポジトリの指示に古いテストコマンドが残っている場合に更新を提案する、というものです。
実行のために画面を開いておく必要はありません。GitHubが管理するスケジュールで自動的に動くため、有効化した直後に結果が出るとは限りません。なお、ChatGPTやClaudeにも同じ「ドリーミング」と呼ばれる機能があります。個人の会話記憶を整えるChatGPTのDreaming V3の自動更新メモリや、エージェントが自己改善するClaudeのドリーミングの仕組みと比べると、Copilot版はリポジトリのファイルとコードレビューまで手を入れる点が大きく異なります。
リポジトリ・個人用メモリ・コードレビューの3機能で異なる入力と出力
Dreamingは3つの機能の総称です。使う情報と出てくる成果物が機能ごとに違うため、表で区別しておきます。
| 機能 | 使う情報 | 出力 |
|---|---|---|
| リポジトリのカスタマイズ | セッション・コード・メモリ・ガイド | リポジトリのメモリ更新と、指示やスキルの変更提案 |
| 個人用メモリの整理 | 対象セッションと個人用メモリ | 個人用メモリの更新のみ |
| コードレビューのカスタマイズ | マージ済みPRへの指摘と現在のコード | 今後のCopilot code reviewの指針 |
リポジトリのカスタマイズが確認するファイルは、.github/copilot-instructions.md、.github/instructions/**、.github/agents/**、AGENTS.md、CLAUDE.md、GEMINI.md、REVIEW.md、.github/skills/** です。他社のエージェント向けの指示ファイルまで読み込み対象に入っている点は見落とされがちです。個人用メモリの整理は、個人の指示ファイルやスキルファイルには手を付けません。各ファイルの役割と配置場所の違いはcopilot-instructions.mdの書き方とAGENTS.mdとの違いで解説しています。
自動で反映されるメモリとプルリクエストで提案される指示ファイルの違い
反映のされ方は3通りに分かれます。メモリは変更ごとの承認なしに、自動で追加・更新・削除されます。リポジトリに置かれた指示ファイルとスキルはプルリクエストで提案され、マージするまでファイルは変わりません。コードレビュー用のガイダンスはプルリクエストを介さず、GitHub内部のガイダンスとして更新されます。
つまり、人の目を確実に通るのは指示ファイルとスキルだけです。メモリとコードレビューのガイダンスは、事後に確認する運用を組まない限り、誰も見ないまま変わっていきます。公式も、AIが生成したガイダンスは誤りを含み得るので、マージ前に確認するよう注意しています。
Copilot Dreamingを動かすための前提条件とプラン・モデル・同期の確認作業
前提条件を満たすだけでは機能はオンになりません。逆に、Dreamingを先にオンにしてから前提条件を整えた場合は、いったんオフにしてから再びオンにする必要があります。設定の順番が結果を左右します。
Copilot Pro対象外とGPT-6.1 Sol必須など初期プレビューの利用条件
Dreamingは対象の有料プランで使えますが、初期プレビューはGPT-6.1 Solへのアクセスが前提で、Copilot Proでは使えません。データレジデンシー付きのGitHub Enterprise Cloudも対象外です。機能ごとの条件は次の表のとおりです。
| 機能 | メモリ設定 | セッション同期 | その他 |
|---|---|---|---|
| リポジトリのカスタマイズ | リポジトリのメモリが有効 | 必須 | GPT-6.1 Solをポリシーで許可 |
| 個人用メモリの整理 | 個人用メモリが有効 | 必須 | GPT-6.1 Solをポリシーで許可 |
| コードレビューのカスタマイズ | リポジトリのメモリが有効 | 不要 | code reviewとプレビュー機能が有効 |
土台になるCopilot Memoryの既定値はプランで違います。GitHub Copilot Memoryについての公式ドキュメントによれば、Pro・Pro+・Maxでは個人用の設定が既定で有効、BusinessとEnterpriseでは管理者がポリシーを有効にするまで無効です。メモリの既定の保持期間は90日で、リポジトリのメモリだけは7〜180日の範囲で変えられます。リポジトリでは、リポジトリのカスタマイズとコードレビューのカスタマイズを別々にオン・オフできない点も覚えておいてください。
セッション同期をremoteExportと組織ポリシーで有効にする設定手順
リポジトリのカスタマイズと個人用メモリの整理は、手元のセッションがGitHubアカウントへ同期されていないと材料が届きません。同期はCopilot CLIとGitHub Copilot appで既定オンですが、組織経由の利用者は、組織のポリシー「クラウドにローカル セッションを格納する」が少なくとも「クラウドから表示」になっている必要があります。ポリシーが無効か未設定なら、セッションは手元にしか残りません。
個人の設定でセッション同期を無効にしている場合もあるため、組織ポリシーに加えて確認が必要です。Copilot CLIの構成ディレクトリのリファレンスでは、~/.copilot/settings.json の remoteExport が真偽値で、既定は true と定められています。過去に false にしていたなら、キーを消すか次のように戻します。
{
"remoteExport": true
}
1回の実行だけ同期の有無を切り替えたい場合は、CLIのフラグで上書きします。
# この実行だけセッション履歴を同期する
copilot --sync-session=on
同じリファレンスには、組織側で同期が許可されていなければ同期は拒否されるとも書かれています。個人の設定とフラグは、組織ポリシーを越えられません。同期を止めても、すでに同期済みのセッションは消えない点にも注意が要ります。
エンタープライズ・組織・個人の設定画面でDreamingを有効化する手順
有効化は3つの階層で行います。エンタープライズで許可し、組織で対象を決め、利用者が個人設定でオンにする、という順番です。
エンタープライズで「組織に決定させる」を選び対象組織を絞るパイロット設定
エンタープライズ・組織・リポジトリでのCopilotメモリの管理に沿うと、エンタープライズの操作は次の流れです。
- エンタープライズのページ上部で「AI コントロール」を開き、サイドバーの「Copilot」を選ぶ
- 「機能とクライアント」で「機能とクライアントの構成」を開き、「Memory」セクションへ進む
- Copilot Memoryのポリシーが「組織が決定できるようにする」か「どこでも有効」になっているか確かめる
- Copilot Dreamingのポリシーで「組織に決定させる」「どこでも有効」「どこでも無効」のいずれかを選ぶ
「組織に決定させる」を選ぶと、既定では全組織で無効のまま、組織の所有者が個別にオンにできます。公式もパイロットではこの選択肢を勧めています。「どこでも有効」は組織側で止められなくなるため、課金の上限を入れる前に選ぶ値ではありません。
組織ポリシーとCopilot Memoryのリポジトリ選択で対象範囲を決める操作
組織では「Settings」から「Code, planning, and automation」配下の「Copilot」→「ポリシー」へ進み、「Memory」セクションの「Dreaming」を「有効」にします。この「有効」は、Copilot Memoryのリポジトリ選択に含まれるリポジトリにだけ効きます。リポジトリ単位でDreamingを個別にオンにする画面はありません。
処理対象の範囲を調整する操作は、Copilot Memoryのリポジトリ選択です。選択からリポジトリを外すと、そのリポジトリのCopilot MemoryとDreamingが両方止まります。Copilot Memoryの組織のリポジトリアクセスは既定で「すべてのリポジトリ」なので、そのままDreamingをオンにすると、アーカイブ寸前のリポジトリまで処理対象に入ります。
FeaturesでDreamingを有効にしCopilot appで結果を確認する手順
利用者側の操作は個人用アカウントのCopilotメモリの管理にあります。GitHub.comの「設定」から「Copilot」→「Features」を開き、Copilot Memoryが有効なことを確かめたうえで、「Dreaming」のドロップダウンを「有効」にします。Copilot Memoryが無効だと、Dreamingの項目自体が表示されません。
GitHub.comの設定画面は実行結果を表示しません。実行結果を確認する場所は、GitHub Copilot appの画面です。アプリに対象リポジトリを追加し、サイドバーの「Automations」から「Dreaming」タブを開くと、「Personal Dream runs」と「Repository Dream runs」に実行が並びます。各実行で状態（Running・Completed・Failed）、要約、警告、メモリの変更を確認できます。ただし、この画面は完全な操作履歴ではなく、実行を取り消すボタンもありません。
AI credits消費と変更の取り消し不可に備える運用設計と監査の手順
有効化そのものより手間がかかるのが、費用と変更履歴の管理です。どちらも後から整えようとすると取りこぼしが出ます。
変更のない実行や非アクティブなリポジトリでもAI creditsが減る課金の構造
Dreamingのモデル利用は既存のAI credits使用量に含まれ、別の明細にはなりません。費用は処理量、有効にした利用者の数、リポジトリの数で変わり、変更を生まなかった実行や動きのないリポジトリの処理でもAI creditsを使います。公式は、Dreamingを有効にする組織を増やす前に支出管理を設定するよう求めています。アラートだけでは使用は止まらず、Dreamingのアプリ単位の予算も作れません。
上限は従量制課金製品の予算設定で入れます。AI creditsを使う機能をまとめて縛る「バンドル AI credits 予算」を作り、組織・Enterpriseでは「達したときに使用量を停止」を選びます。スコープはエンタープライズ・組織・コスト センター・ユーザーの4種類で、作成後に変えられません。ユーザー単位の予算はリポジトリ側の実行に効かない場合があるため、Dreamingの抑制には組織かコストセンターの予算が向いています。プランごとのAI creditsの単価と配分はGitHub Copilotの料金とAI Creditsのプラン比較にまとめました。
無効化しても元に戻らない変更を監査ログとプルリクエストで追跡する方法
Dreamingを無効にすると今後の実行は止まりますが、加えた変更は戻りません。作成した情報の削除、プルリクエストのクローズ、消されたメモリの復元はいずれも行われない仕様です。個人のDreamingをオフにしても、組織が所有するリポジトリでの実行は続きます。止めるならエンタープライズで「どこでも無効」を選びます。
後追いの調査には監査ログを使います。管理者向けドキュメントが示す検索式は次のとおりです。監査ログに残るのは作成や削除の事実と操作者で、メモリの中身や引用元、作成理由は記録されません。
# 特定リポジトリでメモリが作られた日時と起点の利用者を調べる
action:copilot.memory_created repo:ORG/REPO
# 利用者レベル・組織所有者レベル・エンタープライズ所有者レベルの操作
action:copilot.memory
action:org.copilot_memory
action:business.copilot_memory
メモリの読み出し、投票、期限切れによる自動削除は監査イベントになりません。中身を確かめる場所は、リポジトリの「Settings」→「Copilot」→「メモリ」にある一覧です。不要なメモリを削除する際に使うのは、この一覧にあるゴミ箱アイコンです。提案された指示ファイルやスキルの変更は、通常のプルリクエストとしてレビューし、閉じるかマージします。メモリが汚されたときの影響はエージェントメモリの短期記憶と長期記憶の設計で扱った論点と同じ構造で、誤った事実が残るほどCopilotの提案が同じ方向にずれていきます。
Copilot Dreamingを採用すべきチームと見送るべき組織の判断基準
結論を条件つきで言い切ります。指示ファイルを人手で保守しきれていないチームには効果が見込め、統制や監査の要件が厳しい組織では、現時点では見送るほうが妥当です。
指示ファイルが陳腐化しやすい活発なリポジトリで導入を判断する採用条件
採用してよいのは、Copilot CLIやCopilot appでの作業が日常的にあり、ビルドやテストの手順が頻繁に変わるリポジトリです。テストコマンドを変えたのに copilot-instructions.md が古いまま、という状態はDreamingが最も効く場面です。指示ファイルの変更はプルリクエストで届くため、既存のレビュー手順に乗せられます。
コードレビューのカスタマイズも、同じ指摘を何度も手で書いているチームなら試す価値があります。受け入れられた指摘がCopilot code reviewのガイダンスになるからです。レビューの依頼方法や自動レビューの設定はGitHub Copilotのコードレビューの使い方と自動レビュー設定を参照してください。導入の進め方は、活発なリポジトリ2〜3本で1か月動かし、AI creditsの増え方とプルリクエストの採用率を見てから対象を広げる順序をおすすめします。
データレジデンシー利用やセルフホステッドランナー前提の組織で見送る場面
見送るべき条件ははっきりしています。データレジデンシー付きのGitHub Enterprise Cloudはそもそも対象外です。コードレビューのカスタマイズはセルフホステッドランナーに未対応なので、閉域でCopilot code reviewを回している組織では効果の柱が欠けます。GPT-6.1 Solを組織のポリシーで許可できない場合も使えません。
レビューを経ずに変わるメモリを許容できない組織も、プレビューの間は見送るべきです。監査ログには中身が残らず、変更を取り消す手段もないため、規程上「AIが参照する文脈の変更はすべて承認制」としている組織とは相性がよくありません。Copilotを全社に広げる際のポリシー設計、予算の上限、対象リポジトリの選び方は、生成AI導入支援サービスで利用規程の整備からご相談いただけます。
GitHub Copilot Dreamingの導入検討でよく挙がる質問に実務目線で答える
導入前に出やすい質問を、2026年11月時点の公開情報にもとづいて整理します。
Copilot Dreamingを使うとAIモデル自体が学習して賢くなるのですか？
いいえ。公式は、Dreamingが更新するのは基盤のAIモデルではなく、メモリやリポジトリのガイダンスといった文脈だと説明しています。Copilotに渡される前提情報が整うことで、提案の精度が変わる仕組みです。自社のコードがモデルの学習に使われるかどうかは、Dreamingとは別に、プランのデータ利用条件で確認してください。
Copilot Proの個人契約でもDreamingは使えますか？
2026年11月時点では使えません。初期プレビューはGPT-6.1 Solへのアクセスが前提で、公式ドキュメントにCopilot Proでは利用できないと明記されています。対象の有料プランでも、Copilot Memoryの有効化と、多くの機能でセッション同期が必要です。対象プランは一般提供までに変わる可能性があるため、契約前に公式ページで最新の条件を確かめてください。
Dreamingが提案したプルリクエストは自動でマージされますか？
自動ではマージされません。指示ファイルとスキルの変更はプルリクエストとして提案され、マージするまでリポジトリのファイルは変わりません。注意が要るのはメモリとコードレビューのガイダンスで、こちらはプルリクエストを通らずに更新されます。提案されたファイルの内容は、リポジトリにアクセスできる全員に見える点も考慮が要ります。
Dreamingだけの利用料はかかりますか？予算は分けられますか？
別料金の明細はなく、既存のAI creditsから消費されます。変更が生まれなかった実行や、動きのないリポジトリの処理でも消費する点が見落とされがちです。Dreaming単独の予算は作れないため、バンドルAI credits予算を組織かコストセンターの単位で作り、上限到達で使用を止める設定を入れてから有効化してください。
Dreamingを無効にすれば変更前の状態に戻せますか？
戻せません。無効化で止まるのは今後の実行だけで、作成された情報の削除、プルリクエストのクローズ、削除されたメモリの復元は行われません。進行中の実行は続くこともあります。既存の変更は、個人用メモリなら個人設定、リポジトリのメモリならリポジトリ設定の「メモリ」画面で確認して削除し、プルリクエストは個別に閉じる運用になります。
関連記事
- ChatGPTのDreaming V3とは？自動更新メモリの仕組みと確認・削除・オフの方法【2026年10月】：同じ名前を持つChatGPTの記憶整理機能との違いを確かめられます。
- アンソロピックの新機能「ドリーミング」とは｜Claudeエージェントが自己改善する仕組みと使い方：Claudeのエージェントが過去の作業から学ぶ仕組みを解説しています。
- copilot-instructions.mdとは？書き方とサンプル・配置場所、AGENTS.mdとの違い：Dreamingが更新を提案する指示ファイルの書き方をまとめています。
- GitHub Copilotのコードレビュー｜使い方・自動レビュー設定・Max・日本語化と料金：コードレビューのカスタマイズが効く先の機能と設定を確認できます。
- GitHub Copilotの料金（pricing）｜AI Credits移行後のプラン比較とBilling APIでの使用量集計：Dreamingが消費するAI creditsの単価と集計方法を整理しています。
