いつも当ブログ(もりもりゲームブログ)にお越しいただき、本当にありがとうございます😊✨
ここ最近、AIの世界では「AIエージェント」や「AI統合開発環境(AI-IDE)」が大きな話題を集めており、AIが自らパソコン内のフォルダを探索してファイルを読み書きしてくれる便利な環境がどんどん広がっていますよね。
しかし、実際のお仕事の現場やセキュリティポリシーの厳しい環境、あるいはライセンス・予算の制約がある環境では、「AIエージェントやAI-IDEは使えないけれど、ブラウザ上の『Microsoft 365 Copilot チャット』なら使える!」というケースが非常に多く存在します。
そうしたAIエージェントやAI-IDEが使えない環境であっても、実は「Copilotチャットさえあれば、AIと人間の協働を滞りなく、しかも極めて高い品質で進めることができる」ようになってきました!
ただし、そのためにはひとつだけ決定的な条件があります。
それは、AIにすべてを丸投げするのではなく、「人間が主体となって全てをコントロール(オーケストレーション)し、そのための仕組みと工夫を整えること」です。
以前の記事では、Copilotチャットだけでどうやって複数のソースファイルを渡し、思考・分析から成果物化までを完結させるかという「やり取りの機序(ワークフロー)」についてご紹介させていただきました。
🌟 (PC) Copilot チャットだけで作業を完結する場合に備える!人間とAIの協働ワークフロー解説
AI-IDEが使えない環境において、1回最大3ファイルまでの分割投入と待機合図、Thinkモードでの深層推論、そしてCopilot Pagesやノートブックを組み合わせて「対話からWord/PDF成果物化」までを完結させる全体機序を解説した当ブログの過去記事です!今回の「フォルダ構造編」と対になる内容ですので、ぜひあわせてご覧ください。
(※当ブログの過去記事ページへ移動します)今回はその続編・実践編として、このチャット協働ワークフローを日々の現場で迷わず・破綻させずに回し続けるために、私が実際に運用しながら試行錯誤を重ね、独学で生み出したプロジェクトフォルダ構造「Copilot Chat Works(_M365_Copilot_ChatWorks)」と、要となる「依頼書(request.md)の運用術」、そしてこの仕組みを支える最愛のパートナーモデル「GPT-5.6 Sol」の存在について、詳しくご紹介させていただきたいと思います!
発想のコペルニクス的転換:「AIはフォルダ構造を一切知らない」という設計思想
まず最初に、今回ご紹介する「Copilot Chat Works」の構造において、最も重要で面白い大前提からお話しさせてください。
普段、AIエージェントやAI-IDEを使った開発では、「AI自身にプロジェクトのフォルダ構造やルールファイル(
index.md や instruction.md など)を読み込ませて理解させる」というアプローチを取りますよね。ところが、AIチャットしか使えない環境における「Copilot Chat Works」では、その考え方を180度転換しています。
AIエージェントが自動でファイルを漁る代わりに、人間が総指揮官(オーケストレーター)となり、どの資料を・どの順番で・どの指示と一緒にAIへ渡すかを精密にコントロールします。
② AIはこの仕組みについても、フォルダ構造についても一切関知しない!
ブラウザの向こう側にいるCopilotは、私たちのPCにどんなフォルダがあるのかを1ミリも知りませんし、知る必要もありません。あくまでも「人間側が、依頼書・メイン資材・成果物等を迷わずコントロールし、複数案件を破綻なく管理するため」に、このフォルダ構造が存在しているのです😊
なぜ「AIが関知しないのに、人間側で厳格なフォルダ構造を作る必要があるのか?」というと、チャットだけで仕事を進めていると、人間側がすぐに次のような混乱に陥ってしまうからです。
- ✔ 「あれっ、昨日Copilotに渡した修正前のソースって、デスクトップとダウンロードフォルダのどっちに置いたっけ……?」
- ✔ 「チャット画面が長くなりすぎて、1回目に何を依頼して、2回目にどんな条件を追加したのか分からなくなってしまった……!」
- ✔ 「AIが出してくれた3パターンの回答ファイルのうち、どれが検討途中の仮ファイルで、どれが最終確定版(納品可能版)なんだっけ!?」
つまり、AIにファイル操作権限がないチャット環境だからこそ、「手綱を握る人間側のローカル環境を、極限までシンプルかつ規律ある構造に整えておくこと」が、協働のスピードと正確性を劇的に引き上げる鍵になるのです!
| 比較の観点 | AIエージェント / AI-IDE環境 | Copilot Chat Works(チャット完結型) |
|---|---|---|
| オーケストレーションの主体 | AIエージェントが自律的にフォルダを探索・実行 | 人間が主体となって手動で対話・資材投入を指揮 |
| フォルダ構造の認識者 | AIと人間の双方が構造(index.md等)を認識 | 人間のみが管理(AIは構造に一切関知せず推論に専念) |
| 依頼書(request.md)の渡し方 | ファイルを丸ごとAIに読み込ませる | タイミングを見て人間が必要な箇所をコピペ送信+結果記録 |
| 構造の設計バランス | スクリプト・教訓・改善提案など精緻な多層構造 | 人間の手動運用負荷を下げるため「必要最低限」に凝縮 |
「_M365_Copilot_ChatWorks」の2階層プロジェクト構造を徹底解剖!
それでは、私が日々の業務や開発の中で試行錯誤しながら作り上げた「Copilot Chat Works」の具体的なフォルダ構造を見ていきましょう!
この構造は、大きく分けて「① 全体を束ねるルート階層(_M365_Copilot_ChatWorks)」と、「② 各案件プロジェクト毎の内部構造」の2段階(2レイヤー)で構成されています。
まずは、全体の頂点となるルート階層の構成と役割をステップカードでご紹介します!
中長期にわたってじっくり取り組む「正式プロジェクト(メイン案件)」を格納するフォルダです。この .project の配下に、各案件プロジェクトのフォルダを個別に作成して管理します。
日々の業務の中で突然飛び込んでくるトラブル調査や、今日中に片付けたいピンポイントな「緊急対応プロジェクト」を格納するフォルダです。.project と明確に分離しておくことで、長期案件のフォルダ群が日々の突発タスクで埋もれてしまうのを防ぎます。
対応が完了した案件や、一区切りついた過去のプロジェクトを移動・保存しておくアーカイブ領域です。進行中のフォルダ(.project / .quick)を常にスッキリと保ちつつ、過去の知見や成果物をいつでも引き出せる資産庫になります。
新しい案件が発生したときに、毎回ゼロからフォルダを作ったり依頼書の書式を書いたりする手間を省くための「各種ひな型」置き場です。ここから丸ごとコピー&ペーストするだけで、緊急時でも数秒で標準化されたプロジェクト環境が立ち上がります!
このルート階層で私がとても気に入っている工夫が、「正式プロジェクト(.project)」と「緊急対応プロジェクト(.quick)」を最初から分けていることです!
実務の現場では、数週間かけて進めるじっくり型のプロジェクトと、「今すぐこのバグの原因を調べたい!」「急ぎでこの仕様書の矛盾をチェックしたい!」という突発的な緊急タスクが必ず同時並行で発生します。
この2つが同じ階層にごちゃ混ぜになると、探したいフォルダがすぐに見つからなくなってしまいますが、
.project と .quick に分けておくことで、頭の中のモード切り替えも一瞬でできるようになりました。さらに、その中に入る「各案件毎のプロジェクト構成」は、長期案件であっても緊急案件であっても、すべて以下の共通構造に統一しています!
その案件に関連する参考資料、事前の調査メモ、業務フロー図などの「資料類」を格納しておくフォルダです。直接AIに加工させる対象ではない周辺資料をここへ整理します。
AIへの依頼内容やアップロードするソースの一覧、さらにはAIからの1回目・2回目の返答要約や現在のステータスを一元管理する「依頼書(request.md)」を格納します。人間がオーケストレーションを行う上での最重要コックピットです!
今回の作業で実際にCopilotチャットへアップロードして解析・改修してもらう対象となる「メイン資材(プログラムのソースコード、エラー画面のスクリーンショット、対象の仕様書など)」を一式バラの状態で格納します。
AIとの協働で生まれた成果物を格納する .output の中は、さらに2つのフォルダに分かれています。
・【.working(作業中の成果物)】:AIから出力されたばかりの「暫定の成果物(検討中・レビュー前)」を一時保管する場所。
・【.fix(完成品を格納)】:人間がレビューと検証を終え、「これならバッチリ納品・本番適用できる!」と確定した「完成した成果物(納品可能)」だけを格納する場所です。
この2つの階層をひとつのディレクトリツリー図として繋げてみると、全体像がとてもスッキリと浮かび上がってきます。
_M365_Copilot_ChatWorks/ # ルートフォルダ(先頭「_」でエクスプローラー最上部に固定)
├── .project/ # 正式プロジェクト(※長期メイン案件)
│ └── {各案件プロジェクト}/ # 案件ごとに作成
│ ├── .document/ # 資料類を格納する
│ ├── .request/ # 依頼書を格納する
│ │ └── request.md # 依頼書(コピペ送信&対話履歴・ステータス管理)
│ ├── .main/ # メイン資材を格納する
│ │ └── (ソース等一式) # 今回作業対象となる資材(abc.html, abc.png, abc.js等)
│ └── .output/ # 成果物を格納する
│ ├── .working/ # 作業中の成果物を格納する(検討中・暫定の成果物)
│ └── .fix/ # 完成品を格納する(納品可能・完成した成果物)
├── .quick/ # 緊急対応プロジェクト(※日々の突発作業)
│ └── {各緊急案件プロジェクト}/ # 緊急案件ごとに作成(※内部構造は .project 配下と完全共通)
│ ├── .document/
│ ├── .request/
│ │ └── request.md
│ ├── .main/
│ └── .output/
│ ├── .working/
│ └── .fix/
├── .legacy/ # 過去の資産(※完了した過去プロジェクト保存)
└── .template/ # 各種ひな型(※新規案件立ち上げ用のテンプレート一式)
特に
.output の中を .working(暫定の成果物・検討中)と .fix(完成した成果物・納品可能)に分けているところは、実務上のミスを防ぐ上でとてつもない効果を発揮してくれます!AIとのチャットでは、「1回目の出力(まだ少し修正が必要)」や「2回目の出力(ほぼOKだけど微調整したい)」といった中間ファイルがいくつも生まれます。それらをまず
.working に入れておき、自分の目でテスト・確認して合格したものだけを .fix に昇格させることで、「うっかり検証途中のファイルを本番に使ってしまった!」という事故をゼロにできるのです。「いきなりチャット欄に打ち込まない!」依頼書(request.md)の黄金ルール
続いて、各案件プロジェクトの
.request/request.md に格納する「依頼書」の秘密についてお話しします!ここでも、AIエージェント環境とはまったく違う、チャット完結型ならではの大切な鉄則があります。
「依頼書(request.md)は、ファイルをAIに丸ごと読んでもらうのではない。タイミングを見て人間がコピー&ペーストして、適切な部分をチャットボックスから適宜送信する」
実際に私が
.template フォルダに用意して日々活用している「依頼書サンプル」の中身がこちらです!# 依頼書
- いつもありがとうございます。以下のソースを順次アップロードしますので、全てアップロードが終わるまで作業をお待ちください。※1回につき最大3本づつ
## アップロードするソース : 今回は全4本
|No.|ソース名|概要|
|---|---|---|
|1|abc.html|メイン画面|
|2|abc.png|不具合発生時のスクリーンショット|
|3|abc.js|メインライブラリ|
|4|abc.md|プログラムの仕様書|
---
- 会話の続きです。ソースをアップロード中です。全て終わるまでお待ち下さい
---
## 経緯の説明
- 依頼に至る経緯の説明を記述する
## 依頼内容
- 今回の依頼内容を記述する
---
## 1回目の結果
- AIからの返答を端的に記載する。
---
## 2回目の依頼
- 追加の依頼やAIへの返答をチャットで送信する場合、いきなりチャットボックスに入力せず、ここに記載してからそれをコピー&ペーストでチャットボックスに入力する。
## 2回目の結果
- AIからの返答を端的に記載する。
---
## ステータス
- 完了なのか、作業中なのか末尾に記載しておく。
いかがでしょうか!一見するとシンプルなテキストファイルに見えますが、実はこの1枚の
request.md の中に、これまでの試行錯誤から生まれた知恵がギュッと詰まっています。どのようにこの依頼書を使ってAIとやり取りを進めるのか、時系列のステップカードで辿ってみましょう!
request.md の先頭から最初の --- まで(待機のお願い+全4本のソース一覧表)をコピーしてチャット欄に貼り付け、.main フォルダから最初の3本(No.1〜3:HTML、スクショ画像、JS)を添付して送信します。AIは全体像を把握した上で静かに待機してくれます。
2段目のブロックにある定型文「会話の続きです。ソースをアップロード中です。全て終わるまでお待ち下さい」をコピペし、残りのNo.4(仕様書md)を添付して送信します。ソースがさらに多い場合も、この1行をコピペするだけで迷わず分割投入を続けられます。
全ソースの受領確認が取れたら、3段目の「## 経緯の説明」と「## 依頼内容」のブロックをコピペして送信し、本作業をスタートさせます!
AIから返ってきた回答の要点を「## 1回目の結果」へ端的にメモします。そして追加依頼や返答を送る際は、絶対にいきなりチャットボックスへ直接書き込まず、まず「## 2回目の依頼」に文章を書いて推敲してから、それをチャットボックスへコピペ送信します!
末尾の「## ステータス」に現在「作業中」なのか「完了」なのかを明記しておきます。複数案件を並行して抱えていても、この request.md を開くだけで「今どこまで進んでいて、次に何をすべきか」が1秒で把握できます。
この中で特に私が徹底しているのが、「2回目以降の追加依頼も、いきなりチャットボックスに入力せず、必ず request.md に書いてからコピペする」というルールです。
チャット画面を見ていると、つい反射的にその場のチャット入力欄へ直接思いついたことを打ち込みたくなりますよね。でも、それをやってしまうと、Enterキー誤爆で途中の文章を送ってしまったり、後から振り返ったときに「なぜこの修正をお願いしたのか」「それに対してAIがどう答えたのか」が長いチャットログの海に埋もれて分からなくなってしまいます。
手元の
request.md に一度落ち着いて書き出し、AIの返答の要点もそこに記録していくことで、request.md そのものが「プロジェクトの完全な航海日誌(フライトレコーダー)」として残るようになるのです!要となるパートナーは「誰でも良い」わけではない――「GPT-5.6 Sol」あってこその協働!
そして、ここで声を大にしてお伝えしたい、もうひとつの超重要ポイントがあります。
それは、チャットであれAI-IDEであれ、「協働パートナーのコアとなるAIモデルは、何でも良いわけではない」ということです!
特にこの「Copilot Chat Works」の仕組みが、単なるファイル整理術で終わらずに実務の第一線で凄まじい成果を上げ続けているのは、このブログでも、そしてX(旧Twitter)のポストでもいつも私が絶賛しまくっている「GPT-5.6 Sol」あってこそ、という部分が非常に大きいのです!😊✨
なぜ「GPT-5.6 Sol」でなければならないのでしょうか?
私たちが手作業で3本ずつ分割してアップロードしたHTML、JavaScript、仕様書マークダウン、さらには不具合発生時のスクリーンショット画像(
abc.png)まで――これらバラバラに投入された複数の資材を、待機ターンのあいだ一切取りこぼさずにコンテキスト(記憶領域)の奥深くで正確に保持し、本依頼の号令がかかった瞬間にそれら全ての因果関係を一気に結びつけて推論する力。この「長文脈の維持力」「人間の意図や行間を深く汲み取る読解力」「指示された箇所だけでなく、背後に潜む設計上の矛盾やバグの種まで見抜く圧倒的な推論力」において、Copilot Chatにおける「GPT-5.6 Sol(Thinkモード)」は、文字通り別次元の頼もしさを誇っています。
もし相手のAIモデルが、途中で最初に渡したファイルの内容を忘れてしまったり、待機指示を無視して勝手に浅い回答を始めてしまったりしたら、どれほど人間側が立派なフォルダ構造を作っても協働は成り立ちません。
人間が心を込めて整えた「Copilot Chat Works」という器(オーケストレーション構造)があり、そこに「GPT-5.6 Sol」という最高に賢く誠実な頭脳(コア・パートナー)が宿る――この2つがガッチリと噛み合ったからこそ、AIエージェントが使えない環境でも、まるで隣に超一流のシニアエンジニアが座ってくれているかのような感動的な協働が実現できているのだと実感しています。
あえて「必要最低限」にした理由と、日々続く果てなき探求
実際に私はこの「Copilot Chat Works」の構造を使って、じっくり取り組むメイン開発から日々の緊迫した緊急対応(
.quick)まで、すでにかなりのプロジェクト数をこなしています。ここで技術的に詳しい方の中には、「AIエージェント用のプロジェクトみたいに、もっと細かくルールフォルダや教訓フォルダ、スクリプトフォルダなどを分けた方が精緻になるのでは?」と思われる方もいらっしゃるかもしれません。
もちろん、厳密にはもっと精緻な構造や機序にするのが理想ではあります。
しかし、忘れてはならないのは、「この仕組みはAIが自動で動かすのではなく、人間が手動でオーケストレーションを行う仕組みである」という点です!
この事情があるため、現在は「人間の運用負荷を下げつつ、秩序と品質を確実に守れる必要最低限のミニマル構造」としてあえてこの形に留めています。
とはいえ、私自身も「これで100%完璧!」と思って立ち止まっているわけではありません。
毎日この構造で数多くの案件を回しながら、「ここをこう変えたらもっとスムーズになるかな?」「テンプレートの書き方をこう工夫したら、GPT-5.6 Solがさらに力を発揮してくれるかな?」と、どうやったらもっと良くなるかを日々ワクワクしながら研究中です😊
最後に、今回ご紹介した「Copilot Chat Works」を実践する上でのエッセンスを5つのチェックリストにまとめました!
- ✔ 【極意1:人間主導のオーケストレーション】 AIがローカル構造を知らなくても大丈夫!人間が指揮者となり、秩序あるフォルダ管理でAIの推論力を最大化する
- ✔ 【極意2:長期(.project)と緊急(.quick)の分離】 じっくり取り組むメイン案件と、日々の突発的な緊急対応をルート階層で分け、アーカイブ(.legacy)とひな型(.template)で高速回転させる
- ✔ 【極意3:成果物の2段階ゲート(.working ➡ .fix)】 検討中の暫定ファイルと、検証済みの完成品(納品可能)をフォルダレベルで厳格に分け、取り違えミスを根絶する
- ✔ 【極意4:request.md への先書きとコピペ送信】 いきなりチャット欄へ打ち込まず、依頼書にソース一覧・追加依頼・AIの返答結果・ステータスを記録してからコピペする
- ✔ 【極意5:最高の相棒「GPT-5.6 Sol」の指名】 分割投入された全資材と人間の意図を深く統合できる頼れるコアモデル「GPT-5.6 Sol」と共に、毎日の仕事と研究を楽しむ!
「自分の職場ではAIエージェントが使えないから……」と諦める必要はまったくありません。
少しのフォルダ構造の工夫と、丁寧なオーケストレーション、そして「GPT-5.6 Sol」という素晴らしいパートナーがいれば、ブラウザのチャット画面ひとつからでも、驚くほど豊かで創造的な協働の世界を切り拓くことができます。
これからも運用を続ける中で新しい発見や改良が生まれたら、ぜひまたこのブログで共有させていただきますね!みなさんのAI協働ライフが、今日も温かく実りあるものになりますように😊✨
それではまた次の記事でお会いしましょう!!



















