はじめに

周りはみんな使っている。でも、私は使えなかった

私の周りには、Microsoft MVP や、AI をフル活用されている方々がいます。

やまぱん (@aktsmm) さん、Yuya (@yuyanz) さん、あいぼーい(@iboy)さん。
みんな GitHub Copilot をフル活用している猛者たちです。

見ていると便利なことは分かるし、自動化によって工数を減らせる魅力も分かります。
しかも、私には MVP 特典でいただいている GitHub Copilot のライセンスもあります。

それでも、どうしても手を出せませんでした。

実は、一度試して挫折しているんです。

今回は、そんな私が「もう一度使ってみよう」と思うまでの話です。導入手順や使用レビューではありません。

なぜ使わなかったのか。そして、なぜ今なら使ってもよいと思えたのか。その経緯を書いてみようと思います。

※GitHub Copilot 猛者の 3 名のイメージ画像は、X のアイコンを元に AI で取り込みさせていただきました。

1. 最初の挑戦で、私は記事が書けなくなった

最初に試したのは、2026年3月頃でした。

Visual Studio Code に GitHub Copilot を導入し、Qiita記事の投稿や管理をAIで効率化しようと考えました。

ところが、指示を出すと、なにやら自分にはよく分からないPythonコードを書き始め、承認を求めてくるんです。

この時点で、違和感がありました。

何をするのか分からないものに、自分が承認を与えて実行させる。

それが、どうしても怖かったのです。

とはいえ、やってみないと分かりません。承認しながら進めると、見た目上はQiitaの記事がローカルに取得され、指示に応じて編集できるところまでは進みました。

でも、それ以上は進められませんでした。

AIがどこを編集し、何を変えたのか、自分でチェックしきれない。そのようなものを、自分の命をつぎ込んだ記事全体へ反映することはできませんでした。

私自身、その仕組みを理解できていませんでした。
後日、あいぼーいさんに解説してもらい、Qiita CLI が使われていたことを知りました。

GitHub Copilot は、私の指示を実現するために Qiita CLI を選び、仕組みを組み上げていたわけです。

ですが、私は仕組みや内容を把握できないと、怖くて先へ進めない性分です。
出来上がったものが便利でも、そのアーキテクチャを自分で説明できないことに、不安がありました。

便利そうだという気持ちより、怖さのほうが勝ってしまいました。

さらに当時は、記事の管理だけでなく、記事を書くこと自体も AI への指示を中心に進めようとしていました。
AI に記事を書いてもらい、修正を指示する。また修正してもらう。

ところが、これも私には向いていませんでした。自分が意図していない箇所まで編集されることが嫌だったのです。

そうしているうちに、自分の中から記事を書くための発想まで生まれにくくなってしまいました。

私の場合は、効率化しようとして、かえって記事が書けなくなったわけです。

そこで一度、AIに記事の管理や執筆を任せることから離れると決めました。
元のように書けるようになるまで、2 カ月くらい掛かりました。

2. AI の利用をやめたのではなく、任せる範囲を決めることにした

ただし、AI を使わなくなったわけではありません。

自分の手の内でコントロールできる範囲では、利用の仕方を進化させていきました。

たとえば、挿絵の生成です。

まず、自分で記事を書き上げます。その記事をAIに読ませて、内容を表現した画像を作ってもらいます。
元の記事は自分が書いているので、画像が内容に合っているか、誤解を招かないかも、自分で判断できます。
このような使い方は、自分に向いていました。

記事のレビューも同じです。

自分で書いた記事を AI に読んでもらい、誤りや分かりにくい箇所を指摘してもらう。関連する情報や、似たテーマの記事を調べてもらう。

表現に悩んだときには、記事全体を見せたうえで、「この章の、この表現に違和感がある」と相談します。
自分が伝えたいことに近づくまで壁打ちし、納得できた表現だけを採用する形です。

記事全体を AI に編集させると、デグレが発生してはいないかと、今でも抵抗があります。

自分が内容を把握し、責任を持てる範囲で AI を使う。

こうして、自分なりの AI 活用と記事執筆のスタイルができていきました。

大量の記事を生み出す使い方ではありません。
でも、自分のペースを維持しながら、品質を上げていくことができるようになりました。

そして、AI が普及していく時代だからこそ、自分の経験や判断を自分の言葉で残すことには、価値があると感じています。

3. AI 活用を追いかけず、Entra に時間を使うようにした

周りの方々は、AI の最新情報を追い続け、使い方を工夫し、進化させています。スゴイことだと思います。

でも、私には同じことをする余裕がありませんでした。

私はすでに、Entra の技術を追うために、その創意工夫のエネルギーを使っていたからです。

AI にも同じだけの時間を使えば、本務である Entra セキュリティを追いきれなくなる。
だったら、自分はそちらに集中しようと思いました。

一方で、Microsoft 365 Copilot の進化には期待していました。

今、無理に使いこなし方を研究しなくても、いずれ AI のほうが進化して、私にも扱いやすい形になるのではないか。

細かく指示や設定を管理しなくても、自分の文脈を理解し、必要なことをしてくれるようになるのではないか。

そんな期待がありました。

今は Entra に時間を使う。AI については、自分が使いたいと思えるタイミングを待つ。

私なりの選択と集中でした。

4. それでも、Project Opal には惹かれた

そんな私でも、Project Opal という自律型 AI エージェントには惹かれました。

私が魅力を感じたのは、目の前でブラウザが開かれ、人間のように操作する様子が見えることでした。

さらに、自分の PC とは分離された仮想デスクトップの中で動き、操作の記録も確認できる。

これなら、自分にも管理できそうだと感じたのです。

振り返ってみると、AI エージェントそのものが嫌だったわけではありません。

何をしているのか分からず、自分で管理できないことが嫌だったんです。

そして、Opal のような仕組みが業務で使われるようになれば、それを支える環境も必要になると考えました。

Entra 認証、Intune 管理、Cloud PC、業務環境へのネットワーク接続、Webフィルタリング。そして、それらを俯瞰したアーキテクチャ設計とセキュリティです。

そこは、私が得意としている世界です。
さらに、Agent 365 も理解が必要になってきます。

AI そのものを開発するのではなく、AI エージェントが仕事をするための環境を支え、制御する。
そこに自分の役割があると感じ、記事を書き、登壇するようになりました。

5. 研修で気づいた。「お任せ」は、本当に自分の管理下なのか？

転機になったのは、11 月 6 日に会社で受けた AI プロンプトエンジニアリング研修でした。

その中で、Codex や Claude Code を使い、自分の専門領域や考え方、文章を書く際に大切にしていることなどを、Markdown 形式のファイル（.md）にまとめ、エージェントに参照させる方法を学びました。

いわば、AI に自分を理解してもらうための「自分の取扱説明書」 です。

ここで、自分の中の考え方が逆転しました。

それまで私は、Microsoft 365 Copilot が自動的に文脈を理解してくれることに期待していました。
自分で管理しなくても、AI がうまくやってくれる。そのほうが楽だし、安心だと思っていたのです。
当初期待した通りに Microsoft 365 Copilot が進化し、私を理解し文脈も維持してくれている感触がありました。

でも、ふと気づきました。

その文脈を、自分はどこまで制御できているのだろう？

何を覚え、何を前提として回答しているのか。それが自分から見えにくいのであれば、そこもまた、自分がコントロールできていない領域なのではないか。

一方、文脈をファイルとして持っていれば、自分で読めます。
修正もできます。AI に伝えたい内容を、自分の言葉で整理できます。

少なくとも、自分が明示的に渡す文脈は、自分で管理できます。

「お任せだから安心」だと思っていたのに、文脈については「自分で持つほうが安心」だった。

挫折した 3 月から、自分の原則が変わったわけではありません。

自分が責任を持って管理できることを最優先する。その考え方は同じです。

変わったのは、文脈をどこに置けば、自分の管理下にあると感じられるかでした。

6. 自分の文脈を、自分で管理するために

この気づきを通じて、自分が AI に何を求めていたのかも、はっきりしました。
私が求めていたのは、単に AI が自分の文脈を覚えてくれることではありませんでした。

自分自身の文脈を、自分でコントロールできる形で維持・管理することです。

何を AI に伝えているのか、自分で確認できる。
変わったことがあれば、自分で修正できる。
残しておきたいことも、不要になったことも、自分で判断できる。

そのための方法として、文脈をファイルにまとめて持つことに価値を感じました。

ローカルファイルを操作すること自体が目的ではありません。
自分の文脈を、自分の管理下に置きたい。そのための手段として、ファイルを扱える AI エージェントを使おうと考えたのです。

Microsoft 365 Copilot をやめる必要はありません。

普段の相談やレビューには、これまでどおり使う。
その一方で、自分の文脈を明示的に維持・管理するために、別の道具も取り入れる。

すべてを一つの AI に任せようとせず、自分が管理したいものに合わせて、役割を分ければよかったのです。

ここで、私にとってローカル AI エージェントを使う理由が、はっきりしました。

7. ようやく、もう一度使ってもいいと思えた

とはいえ、まだ一つ壁がありました。

Visual Studio Code です。
私には、どうもあの UI が馴染まなかったのです。

そこで、最近話題になっていた GitHub Copilot app を思い出しました。
もしかして、自分が求めているのは、これなのではないか。

そうか。研修で学んだような使い方を、GitHub Copilot app でもできるんじゃないか！

自分の文脈をファイルとして持ち、それを参照しながらエージェントに作業してもらう。
それが、Visual Studio Code とは別の UI でできるのではないかと考えました。

実際にどのように文脈を参照させ、管理していくかは、これから確かめていきます。

それでも、ようやく自分の中で点と点がつながってきました。

仕組みやアーキテクチャも、おおむね理解できてきた。
何を管理したいのかも分かった。それを実現できそうなツールも見えてきた。

だったら、もう一度試してもよいのではないか。
そう思えるようになりました。

もちろん、何でも任せるつもりはありません。

今のところは、特定のフォルダ配下に置いたファイルを中心に扱ってもらうつもりです。
これは、まず自分が任せる作業範囲を限定するという方針です。
技術的にどこまでアクセスを制限できるかは、実際に確認していこうと思っています。

使ってみて、自分の PC 上で動かすことに抵抗があれば、Cloud PC などの別環境に置く判断をするかもしれません。

記事の執筆スタイルも変えません。

自分で考え、自分で書く。
AI にはレビューや壁打ち、限定した範囲の修正を手伝ってもらう。

今回、私が可能性を感じたのは、自分の文脈を、自分が読める形で維持・管理するための使い方です。

今までのスタンスを変えず、記事を書くペースも乱さずに使えそうだ。

その見通しが立ったから、再び手を出してみようと思ったのです。

おわりに ： ここまで書きましたが、まだ使っていません

さて、ここまで読んで、

「それで、GitHub Copilot app を使ってみてどうだったの？」

と思われたかもしれません。

実は、GitHub Copilot app は、まだ使っていません。

今回は、一度諦めた私が、なぜもう一度使ってみようと思ったのか。
その経緯を、忘れないうちに残しておきたくて書きました。

自分の原則を曲げて、AI に合わせることにしたわけではありません。
自分が責任を持てる範囲で使う。その原則を維持したまま、使えそうな道が見えてきたという話です。

本当に期待どおり使えるのかは、これから確かめます。

とはいえ、この記事を公開してしまったからには、使わないわけにもいきません。

そうです。自分で背水の陣を敷きました。

周回遅れなのかどうかは、まだ分かりません。

でも、自分にとっては今が、もう一度使ってみようと思えたタイミングでした。

もし、同じように抵抗を感じている方がいたら、何が不安で、どこまでなら任せられるのかを整理する参考になればうれしいです。