AIとのやりとりを記事の素材として残すために、Copilotセッションを書き出す#
はじめに#
AI とやりとりしていると、その場ではかなり大事なことを調べたり、 判断したりしているのに、あとから振り返りにくいことがある。
チャット欄で右クリックして「すべてコピー」すれば、 会話内容を Markdown として取り出せる。 しかし、毎回クリック操作をして保存するのは、 継続的な運用としては少し弱い。
今回やりたかったのは、もっと単純である。
今まさに行っている Copilot とのやりとりも含めて、 AI と調べたことや考えたことを、現在のリポジトリ配下にログとして残したい。 そして、そのログをあとから読み返し、 自分が興味を持ったことや、AI との対話で明らかになった知識を、 ブログ記事に仕立てていきたい。
今回は、そのための入口として、 Copilot Chat のセッションを Markdown に書き出すスクリプトを作り始めた記録である。
最初に考えたこと#
最初に調べたのは、既存の Copilot セッションエクスポート拡張が、 どのようにセッション情報を取得しているのかだった。
期待としては、Copilot の公開 API のようなものから、 セッション一覧、タイトル、日時、本文を取得できると扱いやすい。
しかし、調べてみると、そういう安定した API を使っているというより、 VS Code のユーザーデータ配下に保存されている transcript の JSONL を読み、 そこからセッション情報を再構成しているようだった。
つまり、実態としては次のような処理になる。
VS Code の
workspaceStorage配下を探すGitHub.copilot-chat/transcriptsにある.jsonlを読むsession.startからセッション ID や開始時刻を取るuser.messageとassistant.messageを順番に取り出す最初のユーザー発言からタイトルを作る
Markdown に整形して保存する
ここで大事なのは、 これは Copilot の公式な安定 API に乗った方法ではない、という点である。
VS Code や Copilot の内部保存形式が変われば壊れる可能性がある。 ただし、個人の作業ログを残すための道具としては、 まず十分に試す価値があると判断した。
右クリックでコピーする代わりにスクリプトで保存する#
当初の目的は、 チャット欄から手でコピーする代わりに、 コマンドラインからログを保存できるようにすることだった。
そこで、次のようなスクリプトを考えた。
rye run python export_sessions.py --latest
最新のセッションだけを書き出す場合は --latest を使う。
一覧を確認したい場合は --list を使う。
特定のセッションだけを出したい場合は --session を使う。
出力形式は Markdown とした。
ブログ記事そのものは reStructuredText で書くが、 生ログとしては Markdown の方が読みやすく、 Copilot の会話内容をそのまま保持しやすい。
ログを記事に変える段階で、 必要な内容を抜き出して reStructuredText の記事に整理すればよい。
ログの置き場所を考える#
スクリプトを書き始めたとき、 最初に迷ったのはファイルの置き場所だった。
このリポジトリは、あくまで Sphinx + ablog のブログサイトである。 そのため、ブログ本体とは少し違う補助スクリプトを ルート直下に増やし続けるのは、あまりきれいではない。
一方で、すでに translate-po-ja-en.py がルート直下にある。
これは記事の英語翻訳を支援するために作ったブログ支援ツールである。
では、今回の export_sessions.py も tools/ のような場所へ移すべきか。
それとも、ひとまずルート直下に置くことを許容するか。
調べてみると、translate-po-ja-en.py は
AGENTS.md や README.md のコマンド例から参照されていた。
移動しても大きな技術的問題はなさそうだが、
ドキュメント更新は必要になる。
今回は、スクリプト配置の整理よりも、 まずログを残す運用を回し始めることを優先した。
そのため、スクリプト本体はルート直下のままとし、 出力先だけを分けることにした。
_notes/sessions/
ここに Copilot セッションの Markdown を保存する。
_notes は手元メモや素材置き場として扱い、
公開記事そのものとは分けておく。
さらに、生ログはそのままコミットするものではないため、
.gitignore で管理対象外にする。
この方針にすると、流れは次のようになる。
AI とやりとりする
↓
export_sessions.py で Markdown に保存する
↓
_notes/sessions/ に生ログが残る
↓
ログを読み返して記事の主題を決める
↓
docs/blog/posts/ に ablog 記事を書く
「生ログ」と「公開記事」を分けられるので、 後から扱いやすい。
コミットしてよいスクリプトにする#
次に気になったのは、 スクリプトをコミットしてよい状態になっているかだった。
初期実装では、VS Code の workspaceStorage の特定 ID を前提にしていた。
これは自分の環境では動くが、
そのままコミットすると環境依存の強いスクリプトになってしまう。
そこで、固定の workspace ID を前提にするのではなく、
既定では workspaceStorage 配下を走査し、
GitHub.copilot-chat/transcripts が存在するディレクトリを探す形にした。
必要であれば、オプションで対象を絞れる。
rye run python export_sessions.py --workspace-id <workspace-id>
rye run python export_sessions.py --transcripts-dir <path>
通常は自動探索で使い、 必要なときだけ明示指定できるようにしておく。
これで、個人の workspace ID を直書きせずに済む。
この変更は、単に見た目をきれいにするためではない。 リポジトリに入れるスクリプトは、 あとから自分が別の環境で見ても意味がわかり、 必要なら少し直して使える状態にしておきたい。
環境固有の値が混ざったままだと、 その時点の作業メモとしては動いても、 リポジトリに残す道具としては弱くなる。
今回わかったこと#
今回の作業で見えてきたのは、 AI とのやりとりをそのまま保存するだけでは、 まだブログ記事にはならないということだった。
ログには、調査の途中経過、迷い、確認、実装判断が混ざっている。 それは作業記録としては価値があるが、 読者にそのまま読ませるものではない。
記事にするときには、次のような整理が必要になる。
何をしたかったのか
どこで迷ったのか
どんな判断をしたのか
実際にどう実装したのか
次回以降に使える知識は何か
今回でいえば、主題は Copilot セッションのエクスポートそのものだけではない。
むしろ、 AI との対話を一時的なチャットで終わらせず、 作業ログとして残し、 そこからブログ記事を作る流れを整えようとしている点が重要である。
ログを残す道具を作ることは、 記事作成の前処理でもある。
今後の使い方#
今後は、AI とまとまった調査や実装相談をしたあとに、 次のようにログを保存する。
rye run python export_sessions.py --latest
保存された Markdown を読み返し、
記事にできそうなテーマがあれば、
docs/blog/posts/ に未来日付の記事としてまとめる。
このとき、生ログの内容を全部記事にする必要はない。
むしろ、ログは材料であり、 記事はそこから読者向けに構成し直したものと考える。
必要であれば、 今後は次のような改善もできそうである。
タイトル生成をもう少し読みやすくする
出力 Markdown から秘密情報らしきものを検出する
特定リポジトリのセッションだけを絞り込む
ログから記事の下書き候補を生成する
ablog 記事化までの専用エージェント定義を育てる
特に最後の点は、このブログの運用と相性がよい。
ログを保存するだけでなく、 ログから記事を書くエージェントを定義しておけば、 次回以降は「このログを元に記事を書いてほしい」と頼むだけで、 日付、置き場所、記事形式、確認事項をそろえやすくなる。
おわりに#
AI との会話は、その場で問題を解くためだけに使うこともできる。
しかし、調べたことや判断したことをログとして残せば、 あとから自分の知識として再利用できる。 さらに、ブログ記事に整理すれば、 同じようなことを考えている誰かの役にも立つかもしれない。
今回は、そのための最初の導線として、 Copilot セッションを Markdown に書き出す仕組みを作り始めた。
まだ内部保存形式に依存する部分はあるが、 個人の作業ログを残す道具としては十分に使い始められそうである。
まずはログを残す。 次に読み返す。 そして、記事にする。
この流れを、少しずつ育てていきたい。
記事情報
- 著者:
mtakagishi
- 公開日:
2026-05-29