GitHub Copilot CLIの /research でMarkdownファイルが出力されない場合がある

このエントリは2026/07/17現在の情報に基づいています。将来の機能追加や変更に伴い、記載事項からの乖離が発生する可能性があります。

問い合わせ

以下のような問い合わせが届いた。

Copilot CLI の /research を多用している。先日ちょっと大きめの調査を依頼したところ、実行ログを見る限りサブエージェントが何度も検索してくれて、最後にはチャット上にすごく詳細なレポート(脚注60個以上、Mermaid図も複数)が出力されたのだが、指定した保存先のパスを見ても `.md` ファイルがどこにも無かった。ログをよく読むと、途中でAIが「自分の環境にはファイルを作成するツールがありません」と言っていて、結局そのままレポート本文をチャットに貼り付けて終わっていた。これは既知の挙動か？それとも指示の出し方が悪かったのか？

ちょうど同じような事象を体験したところだったので、自分のためにも調べておくべき、と考えて調査をしてみた。

/research って何？

GitHub Copilot CLIの /research は、以下のドキュメントにある通り、Copilotをリサーチ アシスタントに変換し、トピックに関する詳細な情報と分析情報を収集するためのコマンド。結構重宝している人も多いかもしれない。

Researching with GitHub Copilot CLI
https://docs.github.com/en/copilot/concepts/agents/copilot-cli/research

このコマンドではリサーチ結果をMarkdownファイルとして出力し、その後、このMarkdownファイルを、/share コマンドで取得する。そのため、同じMarkdownファイルであっても、以下の2種類は別物である。

  • セッションごとに自動保存される既定の保存先
  • /share コマンドで指定できる任意の保存先

そして、問い合わせ主の言う「指定したパスに無い」とは、必ずしも「セッション内の自動保存レポートも存在しない」ことを意味しない。今回はその両方を確認したうえで、実際にレポートがどこにも永続化されていないことを確かめている。

調べていくと、/research 自体の設計に欠陥があるというより、もう少し込み入った事情がありそう。

考えられること

公式ドキュメントによると、/research  の正規の挙動ははっきり書かれている。調査が完了すると、専用の research エージェントが  create  ツールを使ってレポートを Markdown ファイルとして自動保存し、CLI 上にそのファイルへのリンクを表示する。ドキュメントにも「create  ツールを使ってレポートファイルを保存するが、edit  や  bash  などのコード変更系ツールは使わない」と明記されている。つまり通常のケースでは、「調査は終わったのにファイルが残らない」という事態はまず起こらないように設計されているよう。

ところが今回のログは様子が違った。今回の調査は非常に大規模で、task  経由で検索・分析専任のサブエージェントを何十回も呼び出し、それぞれに個別の観点を調べさせる、という進め方をしていた。この「検索専任のサブエージェント」は、ドキュメントに書かれている  /research  本体の research エージェントとは別物で、あくまで情報収集の一部分を担わせるために都度呼び出していたもの。ログを見る限り、この検索専任のサブエージェント自身が

自分のツールセットには閲覧・検索系 (ファイル参照、grep、Web検索、GitHub検索など) しかなく、ファイルを作成・編集するツールやコマンドを実行するツールは一つもない

と明言していた。実際、その後に別種のサブエージェントへ切り替えたところ保存に成功しているので、この申告は裏付けられている。

同様の報告は GitHub 上の Issue にもあった。/research  実行後に

I could not save the markdown file to … because the required create tool is not available in this session, and the delegated research agent only had read-only tools.

#3123 /research can’t write it’s research report
https://github.com/github/copilot-cli/issues/3123

という、ほぼ同じ状況(委譲先の research エージェントが読み取り専用ツールしか持っていなかった)が報告されている (CLI 1.0.40、投稿時点で Open、+1が6件) 。

また、create  ツールが存在しないというエラーで保存に失敗し、保存先を変えて再依頼しても同じ理由で失敗する、という同種の事象が報告されている (CLI 1.0.47、投稿時点で Open)。

“create”: “Blocked item: I couldn’t save the report to xxx.md because the create tool is not available in this session.”

  #3315 “Research try to use not existing tool “create” for file save”
https://github.com/github/copilot-cli/issues/3315

両 Issue とも執筆時点でクローズされておらず、既知だが未解決の状態にあるとみられる。

問題が起きたのは最後の工程。多数の検索専任サブエージェントから集めた結果を1本のレポートに統合し、create  でファイルに保存する作業は、本来すでに  create  を持っているはずの、トップレベルの進行役がやるべき工程だったはず。ところが今回は、この「まとめて保存する」という最後の工程まで、検索専任のサブエージェントに「これを保存してください」と投げてしまっていた。当然、検索専任のサブエージェントは書き込み系のツールを持たないので、律儀に「保存できないので本文をここに書きます」と返すのは明らかである。

さらに厄介なのは、原因を切り分けずに同じやり方で再依頼しても、割り当てられたツールセット自体は変わらないため、同じ理由で失敗する可能性が高い。今回のログでも、1回目の依頼で失敗したあと、同じように検索専任のサブエージェントへ2回目の保存依頼を出し、また同じ理由で失敗している。3回目でようやく、ファイル書き込みを含むフルセットのツールを持つ別種のサブエージェントに切り替えたことで、保存に成功した。

つまり今回の事象について最も説明がつきやすいのは、多段階の調査を進める過程で、本来  create  を持つ側が自分でやるべき「最後の保存」という工程を、検索専任で書き込みツールを持たない相手にうっかり再委譲してしまった、という進行上の手順ミス。ただし、実際に  create  の呼び出し自体が試みられたかどうかまではログから確認できておらず、ディレクトリ作成の許可設定など他の要因が絡んでいた可能性も排除できない。/research  の標準設計 (専用エージェントが  create  で自動保存する) 自体が壊れていた可能性は低そうではあるものの、可能性は排除できない。なぜ検索専任のサブエージェント側に最初から書き込み系のツールが無いのかも公式には確認できておらず、情報収集役には副作用を伴う操作をさせない設計思想があるのではないか、というのはあくまで推測にとどまる。

回避するには？

公式に用意されている手段

調査が完了すると、CLI 上に生成されたレポートファイルへのリンクが表示される。何はともあれ、まずそのリンクをたどってファイルが実際に存在するかを確認する。

リンクを見逃した、あるいは後から確認したい場合は  Ctrl+Y  を押す。「現在のセッションで直近に作成した研究レポート」をターミナル上で開くショートカットとして公式に用意されている。ただし開く先は  COPILOT_EDITOR  →  VISUAL  →  EDITOR  の順で決まる環境変数に従い、いずれも未設定の場合は Linux で  vi、macOS で  vim  になる。見慣れないエディタが開くだけで「レポートがない」と早合点しないよう注意する。

ここまでで見当たらない場合は  /share file research [PATH]  (任意のパスにファイルとして保存)、または  /share gist research  (GitHub Gist として共有)を試す。どちらも、そのセッション中に既に作成済みの研究レポートの一覧から選んで出力する、公式にドキュメント化された手段。[PATH]  を省略すると、カレントディレクトリに調査トピックに基づいたファイル名で保存される。

機密情報・個人情報・顧客情報や内部の URL・コードを含み得るレポートには  /share gist research  を安易に使わないこと。GitHub の Gist は「secret」であっても非公開ではなく、URL を知っていれば誰でも閲覧できる。組織のポリシーで外部共有が明示的に許可され、内容も確認済みの場合を除き、/share file research [PATH]  でローカルに保存するか、承認済みの社内共有先を使う。

これらの手段はいずれも、セッション内で研究レポートがすでに作成されていることが前提。まだ何も作成されず本文がチャットに出ただけの場合は、次の「それでも見つからない場合」に進む。

保存場所そのものを直接確認したい場合は、レポートが保存されるセッションディレクトリを見る。Linux/macOS であれば、

ls -dtl ~/.copilot/session-state/*/ | head -10

で直近のセッションディレクトリを一覧し、該当セッションの  research/  配下を確認する。「指定した任意のパスに無い」ことと「このセッション固有の保存先にも無い」ことは別物なので、両方を確認して初めて「レポートがどこにも残っていない」と言える。

それでも見つからない場合(今回のようなケース)

上記の手段をすべて試しても報告書がどこにも見当たらない場合、今回のように「保存の最終工程が委譲された結果、正規のファイルとして永続化されていない」状態になっている可能性がある。チャット本文がまだ画面に表示されている間であれば、レポートの内容自体はまだ失われていない。

  • 表示されているうちに、まずチャットの本文をそのままコピーして手元に保存しておく。
  • そのうえで、「今コピーした内容を  〇〇.md  として保存してください」と、普段会話している本体(進行役)に直接頼む。進行役は本来  create  を持っているので、この一言で書き込みが完了することが多い。
  • それでも  create  が使えないという同じエラーが繰り返される場合は、apply_patch  や  edit  など別の書き込み系ツール名を明示的に指定して保存を依頼すると解決した、という報告もある(github/copilot-cli#3315)。
  • 保存できたら、そのファイルを開き直して、元のレポートにあった末尾の見出しや脚注番号が保存後のファイルにも揃っているか(分量が不自然に短くなっていないか)も確認しておく。

事前に防げること・再発防止

ドキュメント上、/research  は本来「自動保存 + ファイルへのリンク表示」が正しい挙動であり、調査完了後にそのリンクが出ない、あるいは途中で「保存できません」といった発言が見えたりしたら、それは想定外の状態のサインだと考えてよい。

特に、task  経由で何度も検索用のサブエージェントを呼び出すような、規模が大きく段階の多い調査を頼んだときほど、最後の統合・保存の工程がうっかり再委譲されるリスクが上がるようなので、そうした調査を頼んだ直後は完了時のリンクや  Ctrl+Y  の表示をひと目確認する習慣をつけておくとよい。

同じ状況に繰り返し遭遇するようであれば、想定外の挙動である可能性が高い。バージョン・実行したプロンプト・ログを添えて  /feedback  から報告しておくと、今後の改善につながる。

Resources

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。