前言
周圍的人都在用，但我一直用不起來
我周遭有 Microsoft MVP，以及充分活用 AI 的人。
やまぱん（@aktsmm）先生、Yuya（@yuyanz）先生、あいぼーい（@iboy）先生。
他們都是把 GitHub Copilot 用到極致的高手。
看著他們，我知道這工具很方便，也知道透過自動化可以減少工時的魅力。
而且，我手上也有因 MVP 特典而獲得的 GitHub Copilot 授權。
即便如此，我還是遲遲無法下手。
其實，我曾經試過一次，最後卻半途而廢。
這次想寫的，就是我一路到「再試一次看看吧」之前的心路歷程。不是導入步驟，也不是使用心得。
我想記錄的是：為什麼我當初不用，以及為什麼現在開始覺得可以用了。
我會把這段經過寫下來。
※ GitHub Copilot 三位高手的形象圖，是根據 X 的頭像以 AI 處理而成。
1. 在第一次嘗試時，我甚至寫不出文章了
我第一次試用，是在 2026 年 3 月左右。
我把 GitHub Copilot 導入 Visual Studio Code，想用 AI 來提升 Qiita 文章投稿與管理的效率。
結果一發出指示，它就開始寫一些我完全看不懂的 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，就等待我真心想用的那個時機。
這是我自己的取捨與聚焦。
我發表過、與 Entra ID 相關的代表性文章
carol0226 的 FIDO2 公開收藏清單
https://qiita.com/carol0226/stocks/3670cb8678daed11b191
Microsoft Entra Global Secure Access（GSA）
https://qiita.com/carol0226/stocks/878e7bbc57b301e0deac
4. 即便如此，我還是被 Project Opal 吸引了
即使是我，也會對名為 Project Opal 的自主型 AI Agent 感到心動。
我之所以覺得它有魅力，是因為我能看到瀏覽器在眼前開啟，像人類一樣操作的樣子。
而且它是在與自己的電腦分離的虛擬桌面中運作，還能查看操作紀錄。
這樣的話，我覺得自己應該也能管理得來。
回頭想想，我並不是討厭 AI Agent 本身。
我討厭的是，我無法知道它在做什麼，也無法自己管理它。
而且我也認為，當像 Opal 這樣的機制開始在企業中使用時，背後一定需要相對應的支撐環境。
Entra 驗證、Intune 管理、Cloud PC、連接工作環境的網路、Web 過濾，以及統整這些要素的架構設計與安全性。
那正是我擅長的領域。
而且，還需要理解 Agent 365。
我逐漸意識到，自己不需要去開發 AI 本身，而是可以去支援、控制讓 AI Agent 能夠工作的環境。
我感受到這裡有屬於我的角色，因此開始寫文章，也開始上台分享。
我與 Project Opal 相關的代表性文章
終於實現！透過 Project Opal 與 GSA（EFP）的結合打造 AI 防護欄
https://qiita.com/carol0226/items/de854d39bb970892a85e
【Qiita Tech Festa Day 演講資料】試著體驗用手機上一句提示詞，讓 AI 操作畫面來預約旅行的世界
https://www.docswell.com/s/carol0226/Z6N9W9-024320-QiitaTechFestaDayProjectOpal
5. 在研修中我意識到：「放手交給它」，真的還在自己的掌控下嗎？
轉捩點，是 11 月 6 日公司舉辦的 AI Prompt Engineering 研修。
在課程中，我學到如何使用 Codex 或 Claude Code，將自己的專業領域、思考方式、以及撰寫文章時重視的事情，整理成 Markdown 格式的檔案（.md），再讓 Agent 參考。
也就是說，這是一份讓 AI 理解自己的「使用說明書」。
在這裡，我腦中的想法發生了逆轉。
一直以來，我都期待 Microsoft 365 Copilot 能自動理解脈絡。
我以為，不需要自己管理也沒關係，只要 AI 幫我做好就行了，這樣更輕鬆，也更安心。
而且它似乎也正如我當初期待的那樣持續進化，開始能理解我、也能維持脈絡。
但我突然想到一件事。
這段脈絡，我到底能控制到什麼程度？
它記住了什麼、又是根據什麼前提來回答的？如果這些我看不清楚，那這會不會也是一個其實不在我控制範圍內的區域？
相對地，如果把脈絡做成檔案放著，我自己可以讀，也可以修改。
我可以用自己的話整理成想傳達給 AI 的內容。
至少，我能明確交付給它的脈絡，是我自己能管理的。
原本以為「交給它就安心」，但在脈絡這件事上，反而是「自己保管比較安心」。
從 3 月那次挫折以來，我的原則其實沒有改變。
優先選擇自己能負責、能管理的事情。這個想法一直都沒變。
改變的，是我開始理解：把脈絡放在哪裡，才會讓我覺得它仍在自己的掌控下。
關於我參加的研修
這次參加的是新開發的研修，目前還沒有登載在下列網站上。
如果你有興趣，請透過網站上方選單的「聯絡我們」，告訴他們「我對本文介紹的 AI Prompt Engineering 研修有興趣」。也許可以進一步諮詢是否能報名，以及舉辦條件等資訊。
INTELLILINK Training Academy
https://academy.intellilink.co.jp/course-ai
6. 為了由自己管理自己的脈絡
透過這個體悟，我也更清楚自己到底想向 AI 要什麼了。
我想要的，不只是讓 AI 幫我記住脈絡而已。
而是以我自己能控制的方式，持續維持與管理我自己的脈絡。
我可以確認自己到底傳達了什麼給 AI。
有變動時，我可以自己修正。
想保留的、以及不再需要的內容，我都能自己判斷。
作為達成這件事的方法，我覺得把脈絡整理成檔案保存，是有價值的。
重點不是去操作本機檔案本身。
而是希望把自己的脈絡放在自己的管理之下；因此我決定使用能處理檔案的 AI Agent 作為手段。
我不需要放棄 Microsoft 365 Copilot。
平常的諮詢與審稿，還是照舊使用。
同時，為了明確地維持與管理自己的脈絡，也導入其他工具。
不必把一切都交給同一個 AI，而是依照自己想管理的東西，分配不同角色就好。
到了這裡，我終於明白了對我來說，使用本機 AI Agent 的理由。
7. 終於，我覺得可以再試一次了
不過，還有一道門檻。
Visual Studio Code。
我就是不太習慣那個介面。
於是，我想起最近很受關注的 GitHub Copilot app。
也許，我真正想要的就是這個？
啊，原來如此。研修中學到的那種用法，也可以在 GitHub Copilot app 裡實現啊！
我開始想像：把自己的脈絡做成檔案，讓 Agent 參照它來工作。
而且這也許能透過不同於 Visual Studio Code 的介面來完成。
至於實際上要怎麼讓它參照脈絡、怎麼管理，接下來我會再確認。
即使如此，我腦中終於把那些零散的點連起來了。
機制與架構大致能理解了。
自己想管理的是什麼，也弄清楚了。能實現這件事的工具，也開始看得到了。
既然如此，也許可以再試一次。
我開始能這樣想了。
當然，我不打算把一切都交給它。
目前我打算先讓它主要處理特定資料夾底下的檔案。
這是先把自己願意交付的工作範圍限制住的方針。
至於技術上到底能把存取限制到什麼程度，我會實際確認看看。
如果真的使用之後，我發現把它放在自己的電腦上還是有點抗拒，也可能會改成放到 Cloud PC 之類的其他環境。
文章的寫作風格也不會改變。
我自己思考、自己寫。
AI 則幫我做審稿、來回討論，以及有限範圍內的修改。
這次我感受到的可能性，是用它來維持與管理自己能讀懂的脈絡。
不需要改變原本的立場，也不會打亂寫文章的節奏，應該就能使用。
有了這樣的展望，我才決定再次伸手去試。
結語：寫到這裡，但其實我還沒開始用
讀到這裡，也許你會想：
「所以，實際試用 GitHub Copilot app 之後怎麼樣？」
其實，我還沒開始用 GitHub Copilot app。
※我在 2026/11/8 才開始使用。
這次我寫下的是：曾經放棄過一次的我，為什麼又想再試一次。
我想趁記憶還新鮮時，把這段過程留下來。
這不是我放棄自己的原則、去配合 AI。
而是我在維持「只在自己能負責的範圍內使用」這個原則的前提下，找到了一條看起來可行的路。
至於是不是真的能如預期使用，就等我接下來去驗證。
不過，既然這篇文章都公開了，我也沒有不去用的理由了。
沒錯，這是我自己把自己逼上了背水一戰的地步。
至於這算不算慢了別人一拍，現在還不知道。
但對我來說，現在正是我覺得可以再試一次的時機。
如果你也對 AI 有類似的抗拒感，希望這篇文章能成為你整理「哪裡不安、哪些事情可以交給它」的參考。
補記（2026/11/8）
我已經發表了開始使用後的文章。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
