GitHub Copilot app で「自分の文脈」を管理してみる。me.md を作って常に参照させるまで

はじめに

私は、昨日 以下の記事を書きました。
この記事では、今まで GitHub Copilot を使わなかった理由から GitHub Copilot app を使うことを決意するところまでポエムを記載していました。

周回遅れ？インフラエンジニア、今さら GitHub Copilot app を使い始める！？
https://qiita.com/carol0226/items/21c4ad96de4d8df2f047

これに対して、本記事では 第一歩となる GitHub Copilot app の導入から me.md の作成までを実際に試してみます。

本記事の位置づけについて
普段書いている Microsoft Entra ID や Global Secure Access などの記事は、自分の専門領域として、できる限り方向性や技術的な正確性を確認しながら書いています。

一方、本記事の GitHub / GitHub Copilot app については、私はまだ初心者です。

そのため、本記事は GitHub Copilot app のベストプラクティスや「正しい使い方」を解説するものではありません。

実際に触りながら、

「これは何だろう？」
「こうすればいいのかな？」
「あ、そういうことだったのか！」

と試行錯誤した過程を、そのまま記録した ポエム＋検証記録 くらいの位置づけです。

同じように GitHub Copilot app を触りながら試行錯誤したことがある方には、「そこ、自分も引っかかった（笑）」くらいの感じでニヤニヤしながら読んでいただければと思います。

これから GitHub Copilot app を体系的に学びたい方は、本記事を手順書として利用するのではなく、GitHub 公式ドキュメントや、より適切な書籍・技術記事などを参照してください。

必要なライセンス

以下の公式発表によると、GitHub Copilot app は Copilot Free を含む、すべての Copilot プランで利用できると説明されています。

また、Copilot プランを利用せず、自分のモデルプロバイダーの API キーを持ち込む BYOK という方法にも対応しているようです。つまり、有料の Copilot プランが必須というわけではなさそうです。

GitHub Copilot app available to all
https://github.blog/changelog/2026-07-07-github-copilot-app-available-to-all/

今回の環境
私は以前から GitHub アカウントだけは持っており、GitHub Copilot Max を利用できる立場にあったため、そのアカウントでサインインして進めました。

インストール

ロマホンシャヒンさんが素晴らしい記事を投稿してくれています。
ダウンロードする場所から、インストール時の画面キャプチャをステップバイステップで書かれています。
基本的に、この記事の通りに進めていきましょう。

参考
ロマホンシャヒン (@shahin0809) さんの記事を参考にしました。

GitHub Copilot App が来た！VSCode のCopilotと何が違うの？インストールから使い方までのまとめ
https://qiita.com/shahin0809/items/eadf2e0299073d0859a6

デバイス認証

以下のように、デバイスに表示されたコードを使って認証しました。
このコードが ブラウザ画面の方に表示されているので、これを GitHub Copilot app へ入力します。

GitHub Copilot app の認証で要求された権限

ロマホンシャヒンさんの記事には無い部分です。
私は、全くの初心者なので、初回に このような権限設定が必要になるものと思われます。

デバイス認証まで完了すると、GitHub アカウントへのアクセスを許可するための認証画面が表示されました。

ここで求められているのは、GitHub Copilot app から GitHub 側のリポジトリなどのリソースへアクセスするための権限です。

ローカル PC 上のファイルやフォルダーへのアクセス権限を求めているわけではないため、内容を確認して、そのまま Authorize GitHub を選択して先へ進みます。

参考
上記には Learn more というリンクが複数ありますが、実際に飛んでみると、以下の２つだけでした。

OAuth アプリの承認
https://docs.github.com/ja/apps/oauth-apps/using-oauth-apps/authorizing-oauth-apps#copilot

OAuth アプリのスコープ
https://docs.github.com/ja/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps

Authorize GitHub を押すと、以下の画面が表示されます。

以上で、GitHub Copilot app のインストール と サインインが完了しました。

初期設定

ここでは、GitHub Copilot app で使用するフォルダーまたはリポジトリを選択します。

今回はローカル PC 上だけに文脈を持たせるのではなく、複数の PC から同じ文脈を利用できるようにしたかったため、GitHub 上に新しいリポジトリを作成することにしました。

「Choose a sample repository...」から選択画面を開きます。

「Create new repository...」を押します。

Repository name には、my-context と入力し、Private の状態で Create repository を押します。
今回は、次の内容で新しいリポジトリを作成しました。

• Repository name：my-context
• Description：Personal context and knowledge for AI agents
• Visibility：Private
• README：作成する

以下のような画面になるので、Continue を押します。

以下の画面になれば OK です。

me.md を作成する

この my-context を、これから自分の文脈を維持・管理する場所として使ってみます。

ここで共有したいのは「AI の記憶」そのものではありません。

自分自身で内容を確認・修正できる形にした「文脈」を GitHub で管理し、それを必要な PC から利用できるようにする。

まずは、この形でどこまで自分が求めていた使い方ができるのか試してみます。

以下のプロンプトで指示を出します。

このリポジトリのルートに me.md を作成してください。

このファイルは、AIエージェントに私自身の文脈を伝えるために、
私自身が確認・修正しながら維持管理するファイルです。

現時点では私について推測して内容を書かず、
以下の見出しだけを作成してください。

# Me

## 基本情報

## 技術分野

## 経験・活動

## 記事を書くときに大切にしていること

## AIを使うときに大切にしていること

me.md の作成を指示すると、GitHub Copilot app はすぐにファイルを書き込むのではなく、まず書き込みの許可を求めてきました。

画面を見ると、このセッション用のブランチが作成され、その上で me.md を作成しようとしています。

さらに、ファイルへの書き込みについても、

• 今回のファイルだけ許可する
• このセッションでは常に許可する
• この場所への書き込みを常に許可する
• 書き込みを許可しない

といった選択肢が表示されます。

今回は、まず自分で一つずつ確認しながら進めたかったので、Write this file を選択しました。

また、my-context リポジトリ自体を信頼するかどうかも確認されます。

これは単なるファイルの読み書きだけではなく、リポジトリに設定された構成や hooks、extensions、plugins、MCP servers などがコードを実行する可能性があるためです。

今回は、自分自身で作成したばかりの my-context リポジトリなので、内容を把握していることを確認したうえで信頼することにしました。

ここは、以前 GitHub Copilot を使ったときとは少し印象が違いました。

AI に作業を任せるとしても、どこまで許可するのかを自分で確認しながら進められる。

「AI に全部お任せする」のではなく、「自分の管理下で AI に作業してもらう」。

私が今回もう一度 GitHub Copilot を使ってみようと思った理由とも、うまくつながりそうです。

以下のように me.md が作成されています。

作成された me.md を開いたところ
C:\Users\nogushu.copilot\repos\copilot-worktrees\my-context\carol0226-ubiquitous-fishstick

プロンプトで聞いてみる。
me.md を読んで、私が技術記事を書くときに重視していることを説明して

me.md を編集していきます。

ポイント
私の場合は、すでに Microsoft 365 Copilot が文脈を持っているので、そちらで 以下のプロンプトを作ってもらっています。

me.md の「技術分野」に以下を追加してください。
- Microsoft Entra
- Microsoft Intune
- Azure Virtual Desktop
- Windows 365
- Microsoft Global Secure Access

それ以外の項目は変更しないでください。

me.md を編集してください。

「経験・活動」「記事を書くときに大切にしていること」「AIを使うときに大切にしていること」に、以下の内容を追加してください。

既に記載されている「基本情報」「技術分野」は変更しないでください。

## 経験・活動

- Microsoft Entra、Intune、Azure Virtual Desktop、Windows 365、Global Secure Access など、Microsoft のクラウド、ID、セキュリティ、エンドユーザーコンピューティング領域を中心に扱っている
- 技術を調べるだけでなく、実際に試して確認することを大切にしている
- 技術記事の執筆、技術研修、イベント登壇、コミュニティ活動を行っている
- 技術や経験から見つけた構造や気づきを整理し、他の人にも伝わる形にすることを大切にしている
- 新しい技術やツールについて、自分自身で試し、期待していたことと実際の挙動の違いを確認することを好む

## 記事を書くときに大切にしていること

- 記事は自分自身の経験、考察、気づきをもとに、自分の言葉で書く
- 公式情報として確認できる事実と、自分自身の考察や解釈を明確に分ける
- 技術を単に紹介するだけではなく、「なぜそう考えたのか」「実際に試してどうだったのか」まで伝える
- 読者が理解しやすい流れや構造を大切にする
- 正確性を重視し、曖昧な情報や確認できていないことを事実として断定しない
- AI が生成した文章をそのまま自分の記事にするのではなく、最終的には自分自身が内容を理解し、納得できる文章にする

## AIを使うときに大切にしていること

- AI にすべてを「お任せ」するのではなく、自分自身が把握・管理できる範囲で利用する
- AI が参照する自分自身の文脈は、自分で確認・修正できる形で維持・管理する
- AI の回答をそのまま正しいものとして扱わず、重要な情報は公式情報や実際の動作で確認する
- AI は、自分に代わって考えるものではなく、自分の考えを整理したり、検証したり、形にしたりするために利用する
- AI を使うことで自分自身の思考や執筆のペースを崩さないことを大切にする
- AI に任せる範囲と、自分自身で判断する範囲を意識的に分ける

以上のように、me.md ファイルが編集できました。
テストのために、質問してみます。ちゃんと、分かってくれている様子です。

以下のように、知らないことは 知らないと回答されました。

以上で、me.md を作成することができました。

次のアクション

リポジトリの状態を確認してみる

ここまで GitHub Copilot app で編集してきた me.md は、まだ GitHub 上の正式なファイルには反映されていません。

GitHub Copilot app は、今回の作業用に別の領域を用意し、そこで me.md を編集しています。

そのため、編集した内容を GitHub 側にも正式に取り込むには、変更内容を確認して取り込む操作が必要になります。

現時点で GitHub リポジトリを参照したところ

この時点では、GitHub 上の my-context に me.md はまだありません

Pull Request とは？

リポジトリに取り込むために使用するのが Pull Request（PR）です。

Pull Request（PR）とは
今回の使い方では、

GitHub Copilot app が行った変更内容を確認し、問題がなければ GitHub 側へ正式に取り込むための「提案」を作る仕組み

と考えると分かりやすいと思います。

実際に変更を正式に取り込むには、このあと Pull Request を Merge します。

今回編集した me.md ファイルをどうしたいかで、次のアクションが決まります。

• me.md の変更を GitHub に正式に取り込む (Pull Request)
• 今回の作業を保留する (Archive)
• 今回の作業を取りやめる (Delete)

me.md の変更を GitHub に正式に取り込む

me.md の編集が終わると、画面上部に「Create PR」ボタンが表示されています。

「Create PR」の右側にあるドロップダウンメニューを開くと、変更をどのように Pull Request（PR）として扱うか、次の3つから選択できます。

• Agent merge
  Pull Request の作成後、レビューやチェックの状況を追跡しながら、マージまでの流れを GitHub Copilot に任せる方法です。
  　
  Pull Request のライフサイクルを自動化したい場合に利用します。
  　
• Create PR
  通常の Pull Request を作成します。
  　
  GitHub Copilot が行った変更を Pull Request として作成し、差分を自分で確認したうえで、問題がなければ自分でマージできます。
  　
• Create draft PR
  Draft（下書き）状態の Pull Request を作成します。
  　
  まだ変更が完成していない場合や、もう少し作業を続けてからレビュー・マージしたい場合に利用します。

選択
今回は me.md に書かれた内容を自分自身で確認してから取り込みたいので、「Create PR」 を選択しました。

私が今回やりたいのは、AI にすべてを任せることではありません。

GitHub Copilot にファイルの作成や編集を任せながらも、変更された内容は自分で確認し、納得したものを取り込む。

AI に作業してもらいつつ、最終的な判断は自分の管理下に置く。
この流れは、今回 GitHub Copilot app をもう一度使ってみようと思った理由とも合っています。

Pull Request の実施

ボタンが以下の状態に変化しました。

サイトを確認してみます。

以下のように me.md を確認することができました。

Pull Request を Merge する
ここで一つ注意が必要でした。

GitHub Copilot app で Create PR を実行しただけでは、me.md はまだ GitHub の正式なファイルとして取り込まれていません。

実際に GitHub の main を確認してみると、まだ me.md はありませんでした。

Pull requests を確認すると、作成した Pull Request が Open の状態で残っています。

Pull Request を開くと、GitHub Copilot app が作成した me.md の変更内容を確認できます。

内容に問題がないことを確認したら、Merge pull request を選択します。

Merge が完了すると、Pull request successfully merged and closed と表示されます。

これで初めて、今回 GitHub Copilot app で行った変更が GitHub 側へ正式に取り込まれました。
GitHub の main を確認すると、README.md に加えて me.md も確認できるようになります。

つまり、Create PR は「正式に取り込む」操作そのものではなく、変更を確認して取り込むための入口だったということです。

GitHub に慣れていない私にとっては、ここも実際に触ってみて初めて分かったポイントでした。

一番苦労したのは Merge
GitHub の知識がほとんどない私にとって、Merge が必要だと分かるまでは、「記録した me.md をどうやって新しいセッションから参照できるようにするんだろう……」と、かなりハマりました。今回、一番苦労したポイントです。

今回の作業を保留する (Archive)

「Archive」は、セッションをいったん片付けておくための操作です。

作業中のセッション一覧から外して整理したいものの、あとから内容を確認したり、作業を再開したりする可能性がある場合に使います。

つまり、

今はいったん作業を終えるけれど、このセッションは残しておきたい

という場合は「Archive」です。

Archive したセッションは、Manage sessions を使って復元することもできました。

目的の名称をクリック

Restore session を選択

戻った。

今回の作業を取りやめる (Delete)

「Delete」は、そのセッションがもう不要になった場合に使用します。

たとえば GitHub Copilot に me.md を編集してもらったものの、

今回の変更は採用せず、なかったことにしたい

という場合です。

まだ Pull Request を使って今回の変更を正式に取り込んでいなければ、GitHub 上の正式な me.md には反映されていません。

不要なセッションであれば「Delete」で削除できます。

整理すると、次のように考えると分かりやすそうです。

操作	使う場面
Pull Request → Merge	今回の変更内容を確認して、GitHub に正式に取り込みたい
Archive	今はいったん作業を止めるが、あとから確認・再開する可能性がある
Delete	今回の作業が不要で、変更も採用しない

GitHub Copilot に作業を任せても、「変更を残す」「あとで再開する」「採用せずに破棄する」といった判断は、自分で行えます。

このあたりも、私が求めていた「AI に任せながらも、自分の管理下に置く」という使い方に合っています。

セッションの開始時に 毎回 me.md を参照させるようにする

ここで新しいセッションを開始して、もう一度質問してみました。
ところが、今度は me.md に書いた内容を把握していません。

me.md をリポジトリに置いただけでは、新しいセッションで常に自動参照されるわけではないようです。

つまり、me.md は「AI が自動的に記憶として扱う特別なファイル」ではありません。

そこで、GitHub Copilot app の Instructions を使って、新しいセッションでも me.md を自分自身の文脈として参照する というルールを明示的に設定します。

1．Settings を開く

2．Repository の一覧から my-context を選択
3．Instructions 欄を探す

4．Instructions 欄内に、以下のような指示を入力します

各セッションの開始時に me.md を読み、
ユーザーについての基本的な文脈として使用してください。

ユーザーに関する質問や、
ユーザーの考え方、経験、技術分野、
記事執筆時の考え方、AI利用時の考え方が関係する場合は、
me.md の内容を参照してください。

me.md に記載されていないユーザー情報を推測して補完しないでください。

me.md の内容と一般的な知識や外部情報は区別してください。

me.md を変更する場合は、
ユーザーから明示的に変更を指示された場合のみ変更してください。

すると、以下のように 新しいセッションを開始しても me.md を参照してくれるようになりました。

まとめ

今回は GitHub Copilot app をインストールし、自分自身の文脈を管理するための me.md を作ってみました。

実際に試してみて分かったのは、単に me.md を作るだけではなく、

1. 自分自身の文脈を me.md として管理する
2. GitHub Copilot app に編集してもらう
3. 変更内容を自分で確認する
4. Pull Request を作成し、Merge して GitHub に取り込む
5. Instructions で me.md を参照するように指定する

という流れにすることで、自分で確認・修正できる「文脈」を GitHub Copilot app から利用できるということです。

これは、以前 GitHub Copilot を使ったときに感じていた、

「便利なのは分かる。でも、自分が把握できないことまで AI に任せるのは怖い」

という感覚とは、かなり違いました。

AI に自分のことを勝手に「覚えてもらう」のではなく、

AI に渡す文脈を、自分自身で見て、直して、管理する。

そして、AI が行った変更についても、取り込むのか、保留するのか、取りやめるのかを自分で決める。

まだ第一歩ですが、これなら自分が求めていた AI との付き合い方に近づけそうです。

今回は my-context を GitHub 上の Private Repository として作成しました。

そのため、特定の PC だけに文脈を閉じるのではなく、別の PC からも同じ my-context を利用できるのではないかと考えています。

このあたりは、実際に別の PC から利用して、今後確認してみたいと思います。

そして次は、この my-context を実際の記事執筆の中でどのように使っていくかを試してみようと思います。