目次
はじめに
こんにちは、フォースタートアップス株式会社エンジニアの野尻（@jsotakebmx）です。ヒューマンキャピタル支援システム（社内プロダクト）の開発を担当しています。
私は業務ではずっとGitHub Copilot CLIを中心に使っているのですが、「あれ、俺いつも似たことでCopilotにキレてるな？」と思うことが最近増えてきました。
コード規約やワークフロー、ガイドのようなものをSkillsとして作成しているチーム（人）は既に多いと思いますが、それでもうまくいかないことも少なくはないと思います。 これにはSKILL.mdが冗長すぎるとか、そもそも内容が古いなど考えられる原因は多岐に渡ります。
これらの原因を特定するための一つのアプローチとして、過去のCopilotとのセッションログを詳細に分析し、実装済みSkillsの改善と新規抽出に取り組んでみた、という話をさせていただきます。
セッションログの全体像
GitHub Copilot CLIとのやりとりは、基本~/.copilot/に保存されています。
公式ドキュメント：
.copilot/のディレクトリ構成はこちら。
~/.copilot/ ├── config.json # ユーザー設定 ├── mcp-config.json # MCP サーバー設定 ├── command-history-state.json ├── session-state/ # セッションログ本体（メイン） ├── history-session-state/ # 過去セッションのアーカイブ ├── logs/ # セッションログファイル ├── ide/ # IDE 連携情報 ├── marketplace-cache/ # Copilot Marketplace のキャッシュ └── pkg/ # インストール済みパッケージ
session-state/を覗いてみると、UUIDのディレクトリ並んでおり、私の環境では200個以上ありました。これが全部過去のセッション（= Copilotとの会話履歴）になっています。
config.json — 意外と多い情報量
// 079r67fe-e011-1a12-w26s-3efw82re24y8 { "last_logged_in_user": { "host": "https://github.com", "login": "your-name" }, "theme": "auto", "model": "claude-sonnet-4.6", "reasoning_effort": "high", "trusted_folders": [ "/Users/user.name/repository-name", "/Users/user.name/copilot-session-insight", ... ] }
ログインユーザー、テーマ、デフォルトモデル、そしてtrusted_folders。どのプロジェクトを信頼フォルダとして登録しているかが一覧で分かります。自分の作業プロジェクトの遍歴を振り返れますね。
session-state/ の構造
各セッションディレクトリには以下のファイルが入っています。
~/.copilot/session-state/{sessionId}/
├── events.jsonl # 1行1イベントのJSONL（全行動の記録）
├── workspace.yaml # ワークスペース情報
├── vscode.metadata.json # VS Codeメタデータ
├── session.db
├── checkpoints/ # チェックポイント（作業の節目）
│ ├── index.md
│ ├── 001-{title}.md
│ └── 002-{title}.md
└── files/ # セッション成果物（plan.md、調査レポート等）
├── rewind-snapshots/ # 巻き戻し機能
│ ├── index.json # スナップショットのメタデータ一覧
│ ├── backups/ # バックアップの本体
│ └── <contentHash>-<timestamp>
├── research/
ちなみに、全207セッションのうち、events.jsonlがあるのは71個、checkpoints/があるのは122個でした（セッションの性質によって異なる）。
workspace.yaml — セッションのメタデータ
id: 079r67fe-e011-1a12-w26s-3efw82re24y8 cwd: /Users/user.name/repository-name git_root: /Users/user.name/repository-name repository: organization/repository-name branch: feature/#2424-post-api-get-composite-part2 summary: Add Composite API Support created_at: 2026-02-17T06:44:55.081Z updated_at: 2026-02-18T01:36:23.085Z
どのリポジトリの、どのブランチで、何をしていたかが記載されています。summaryフィールドにはGitHub Copilotが自動生成したセッション要約が入っています。セッション一覧を眺めるだけで、過去の作業履歴を大まかに把握できます。
checkpoints/ — 作業の節目
/compactコマンドを実行するか長いセッションではチェックポイントが作られます。
つまり、チェックポイント時点でのセッションコンテキストが圧縮されて保存されるわけですね。
ちなみに、/compactを必ずしも手動でトリガーする必要はなく、セッションの長さや内容によって自動的に作成されることもあるようです。
圧縮を手動でトリガーする必要がある場合は、/compactを使用します。これは、システムが自動的に処理するため、ほとんど必要ありません。 チェックポイントは、セッションコンテキストが圧縮されるときに作成され、Copilotが作成した概要コンテキストを表示できます。
index.mdにはチェックポイントの一覧が、001-{title}.mdには各チェックポイントの内容が入っています。
| # | Title | File | |---|-------|------| | 1 | BigQuery統合パターン 学習・ナレッジ作成 | 001-bigquery.md | | 2 | BigQuery Skills/Agents フォーマット変換 | 002-bigquery-skills-agents.md |
- ディレクトリ構成
checkpoints/ ├── index.md # チェックポイント一覧 ├── 001-composite-api-get-query-refact.md ├── 002-composite-api-skill-and-list-r.md └── 003-composite-get-refactor-doc-syn.md
files/ — セッション成果物の保存先
plan.mdや調査レポートなど、セッション中に生成したファイルが格納されます。こんなものまで残っていました。
files/composite-api-investigation-report.md
Copilotに「調査結果をファイルに保存して」と頼んだときに作られたものでした。ただのチャット履歴ではなく、成果物まで丸ごと保存されていることもあります。
events.jsonl — 行動のフルログ
本命はここです。events.jsonlを開くと、1行1イベントのJSONLが並んでいます。
session.start 2026-02-17T06:44:55 user.message 2026-02-17T06:45:51 assistant.turn_start assistant.message tool.execution_start tool.execution_complete skill.invoked ←Skillが呼ばれた記録 assistant.turn_end subagent.started ← サブエージェントが起動した記録 ...
主要なイベント型の一覧：
| type | 内容 |
|---|---|
session.start |
セッション開始。branch, repository, copilotVersionなど |
user.message |
ユーザーのプロンプト本文 + 添付ファイル一覧 |
assistant.message |
AI の応答 |
tool.execution_start |
ツール呼び出し（Read, Edit, Bash, Glob など） |
tool.execution_complete |
ツール実行結果（success: true/false） |
skill.invoked |
Skillが呼ばれたとき。Skill名とパスと内容が記録される |
subagent.started |
サブエージェントの起動 |
skill.invokedイベントが特に面白くて、「どのセッションで、どのSkillが呼ばれたか」や「Skillの内容自体」が全部記録されています。
{ "type": "skill.invoked", "data": { "name": "composite-api-query-skills", "path": "/Users/user.name/repository-name/.github/skills/composite-api-query-skills/SKILL.md", "content": "---\nname: composite-api-query-skills\ndescription: Composite APIを使った..." } }
セッションログから読み取れること
実際にログを集計してみると、自分の行動パターンが数字で見えてきます。
リポジトリ別セッション数（workspace.yamlのrepositoryを集計）:
// プライベートリポジトリなのでディレクトリ名は仮にしています 72回 [Orgs]/hoge-project 38回 [Orgs]/huga-project ...
さらにevents.jsonlを分析すると：
- どのツールをよく呼ぶか（Read? Edit? Bash?）
- ツールの成功率（
tool.execution_completeのsuccessから） - 何時に作業が集中するか（
timestampの時間帯分布） - どのSkillがよく呼ばれるか（
skill.invokedの集計） - どんな意図の依頼が多いか（
user.messageの内容）
これら全部をセッションログから読み取とることができます。つまりCommit履歴など細かく振り返らなくても自分の開発スタイルを丸ごと分析可能ということですね。
Skillsへの抽出
ログを眺めていてふと思ったのが、「繰り返し出てくる依頼パターンはSkill化できるのでは？」ということです。
user.messageを見ると、こんな依頼が何度も出てきます：
- 「このファイルにテストを書いて」
- 「ユニットテスト追加して」
- 「spec を作成して」
表現は違うけど意図どれも同じですよね。このパターンを検出できれば、「テスト生成」というSkillを作るべきだと分かります。
さらにtool.execution_startのシーケンスを見ると、こんなパターンが繰り返されています：
Read → Edit → Bash(test) → Bash(lint)
これも「編集→テスト→lint」という定番ワークフローで、Skill化の候補です。
skill.invokedが記録されていることも重要で、ここから「このSkillは既に活用されている」という事実もログから読み取れます。活用されていない繰り返しパターンを見つけて新規Skillを作り、既存Skillの呼ばれ方を見てチューニングする——ログがSkill設計のフィードバックループになります。
実際にやってみた
「じゃあ実装しよう」と思ったとき、最初に考えたのはTypeScript + Copilot SDKでパイプラインを書くことでした。が、これ自体を、Skillsとして書けばいいんじゃないか？と思い直しました。
SDKでやろうとしていたのは「セッションログを読んで、パターンを見つけて、Skill候補を出す」ことです。ですがそれ自体、Copilot自身がファイルを読めるし構造化データの分析もできるし、パターン検出もできます。わざわざコードを書かなくても、分析の観点をSKILL.mdに書いておけば、Copilotが直接ログを読んで分析してくれるはずです。
実際にcopilot-skill-extractというSkillを作って実践してみました。以下は一部抜粋ですが、SKILL.mdの内容はこんな感じです。
--- name: copilot-skill-extract description: 'セッションログから繰り返しパターンを見つけてSkill化すべき候補を提案する' allowed-tools: Read, Glob, Grep, Bash --- GitHub Copilotのセッションログを分析し、繰り返されているパターンを検出してSkill化（自動化）すべき候補を提案する。 ### データの場所と構造 セッションログは`~/.copilot/session-state/`に格納されている。 ## 分析手順 1. ~/.copilot/session-state/ から直近30日のセッションを読み取る 2. 以下の5レイヤーで繰り返しパターンを検出する: - Layer 1: Intent Patterns — プロンプトを意味でグループ化 - Layer 2: Prompt Templates — 構造が同じで変数が違うパターン - Layer 3: Domain Patterns — 同じドメイン知識が繰り返し必要なパターン - Layer 4: Workflow Patterns — ツールチェーンの繰り返し - Layer 5: Cross-Branch Promotion — 複数ブランチで出現したら昇格 3. 各候補について SKILL.md の雛形を提案する
あとはいつも通りセッションを開始して、SKILL.mdを読み込ませて「Skill化すべきパターンを見つけて」と頼むだけですね。
ちなみにModelはclaude-sonnet-4.6を指定しています。
以下は実際に出力されたセッションの一部ですが、直近30日のセッションを分析して、繰り返されているパターンを候補として提案してくれています。
$ copilot ← セッション開始 > Skill化すべきパターンを見つけて 直近30日のセッションを分析しました。以下が候補です: 1. unit-test-generation（12回 / 3ブランチ） 「テストを書いて」「ユニットテスト追加して」「spec を作って」が同じ意図 → 高優先度: 複数ブランチで繰り返されている 2. edit-and-verify（15回 / 4ブランチ） Read → Edit → Bash(test) の編集検証フローが最頻出ワークフロー → 既に定型化されているのでSkill化の効果が高い
今回の具体例には記載していませんが、Skillsの内容によっては既存Skillsを分析させて、「逆にSkillを使った時の方がやり直し多いで。」だったり「一つのSkillに集約しすぎているから分割した方がいいで。」といったフィードバックも得られると思います。
まとめ
Coding Agentが開発と切り離せなくなった今、~/.copilot/は最早「自分自身の開発行動履歴」と言っても過言ではありません。
- config.json, mcp-config.json: 自分のツール設定の全貌
- session-state/: 207個のセッション、各セッションにevents.jsonl・workspace.yaml・checkpoints・files
- events.jsonl: user.message, tool.execution_start, skill.invoked……行動の全記録
このデータを使うと、「どのプロジェクトで何時間何をしたか」「どのツールをよく使うか」「どんな意図の依頼が多いか」が全部分かります。さらに繰り返しパターンを検出すれば、Skill化すべき候補を見つけられると思いますし、もっと言えばSkillに留まらず、「自動化すべきワークフロー」やPremium Request消費の改善なども見えてくると思います。
まずはopen ~/.copilot/session-state/してみてはいかがでしょうか。きっと努力と涙の結晶が何百件も眠っているはずです...
