概要
GitHub Copilot Chat のセッションログを分析して、AIエージェントの活用ノウハウを抽出・蓄積する試みについて紹介します。
UIに表示されている会話ログだけでは「いつセッションが実行されたか」「各レスポンスにどのモデルが使ったか」などのメタデータ情報を取得しきれないため、セッションログの生データを解析して読みやすい形式に加工するスクリプトを作成しました。
また、このスクリプト作成自体もGitHub Copilotに依頼して実装しており、エージェントと共同した開発プロセスの紹介にもなればと思います。
[目次]
- 加工用スクリプトの作成
- ログの実体はどこにあるのか: GitHub Copilot Chat のセッションログがローカルのどこに保存されているか
-
ログデータから必要な情報を抽出する: 巨大なセッションログから分析に必要な情報だけを
jqで抽出・整形- セッションを一覧する: 各セッションのタイトルを一覧化する
- セッションの分析
- AIエージェントによるツール作成: 解析用スクリプト自体をエージェントに作らせたセッションの実例を紹介
- セッションログのフィードバック: 別のLLMにセッションログを分析させ、指示の良し悪しを振り返る
- ナレッジの抽出: セッションから得られた知見を再利用可能なナレッジとして構造化
- まとめ: AIエージェントをうまく動かすための考え方を整理する
ログの実体はどこにあるのか
GitHub Copilot Chatはセッションログをローカルマシン上にJSON形式で保存しています。私の環境（Windows版VSCode1）では以下のパスに保存されていました。
- ワークスペースを開いているとき:
%AppData%\Code\User\workspaceStorage\{workspaceId}\chatSessions\{sessionId}.json - 空ウィンドウ（ワークスペースなし）で開いているとき:
%AppData%\Code\User\globalStorage\emptyWindowChatSessions\{sessionId}.json
IDは315f5bdb76d078c43b8ac0064e4a0164/chatSessions/612b1fce-77c8-6934-5bfc-94c75894edd3.jsonのようにworkspaceIdが32桁、sessionIdがUUIDの形式になっているようです。
これはあくまで現在の私の環境の例で、公式にここにあると定められているものでもないので、環境に応じて適宜似たパスを探索してみてください2。
ログデータから必要な情報を抽出する
実際のログファイルは非常に巨大で、数往復のやり取りだけで数万行にもなります。そのため、ユーザーとエージェントのやり取りの分析に必要な情報だけを抽出して新しいJSONファイルに保存するスクリプトを作成しました。
ここではjqというJSON処理ツールを使って必要な情報を抽出するシェルスクリプトにしています。以下の2ファイルをworkspaceStorageに置いて、jqがインストールされたシェルで実行できます。WindowsではWSLで/mnt/c/.../Code/User/workspaceStorage/にcdするか、WSLのワークディレクトリにコピーするといいでしょう。
transform_chat_session.jq
# GitHub Copilot Chat セッションログ整形スクリプト
# 使用方法: jq -f transform_chat_session.jq <session.json>
# レスポンスからエージェントのテキスト応答を抽出する関数
def extract_agent_text:
[.[] | select(.kind == null and .value != null) | .value] | join("");
# レスポンスから思考プロセスを抽出する関数
def extract_thinking:
[.[] | select(.kind == "thinking" and .value != null and .value != "") | .value];
# レスポンスからツール呼び出し情報を抽出する関数
def extract_tool_calls:
[.[] | select(.kind == "toolInvocationSerialized") | {
toolId: .toolId,
toolCallId: .toolCallId,
isComplete: .isComplete,
invocationMessage: (
if .invocationMessage | type == "object" then .invocationMessage.value
else .invocationMessage end
),
pastTenseMessage: (
if .pastTenseMessage | type == "object" then .pastTenseMessage.value
else .pastTenseMessage end
)
}];
# レスポンスからファイル編集情報を抽出する関数
def extract_file_edits:
[.[] | select(.kind == "textEditGroup") | {
uri: .uri,
done: .done
}];
# インタラクションを整形する関数
def transform_interaction:
{
interactionIndex: .key,
requestId: .value.requestId,
responseId: .value.responseId,
timestamp: (.value.timestamp / 1000 | strftime("%Y-%m-%d %H:%M:%SZ")),
modelId: .value.modelId,
agent: {
name: .value.agent.name,
fullName: .value.agent.fullName,
extensionId: .value.agent.extensionId.value
},
modelState: {
value: .value.modelState.value,
completedAt: (
if .value.modelState.completedAt then
(.value.modelState.completedAt / 1000 | strftime("%Y-%m-%d %H:%M:%SZ"))
else null end
),
durationSeconds: (
if .value.modelState.completedAt and .value.timestamp then
((.value.modelState.completedAt - .value.timestamp) / 1000 | floor)
else null end
)
},
timeSpentWaiting: .value.timeSpentWaiting,
userMessage: {
text: .value.message.text,
partsCount: (.value.message.parts | length)
},
variableData: {
variablesCount: (.value.variableData.variables | length),
variables: [.value.variableData.variables[]? | {
name: .name,
kind: .kind,
isRoot: .isRoot,
automaticallyAdded: .automaticallyAdded
}]
},
agentResponse: {
text: (.value.response | extract_agent_text),
thinking: (.value.response | extract_thinking),
toolCalls: (.value.response | extract_tool_calls),
fileEdits: (.value.response | extract_file_edits),
responsePartsCount: (.value.response | length)
},
result: {
details: .value.result.details,
timings: .value.result.timings
}
};
# メイン変換処理
{
# セッションメタデータ
session: {
sessionId: .sessionId,
version: .version,
customTitle: .customTitle,
creationDate: (.creationDate / 1000 | strftime("%Y-%m-%d %H:%M:%SZ")),
lastMessageDate: (.lastMessageDate / 1000 | strftime("%Y-%m-%d %H:%M:%SZ")),
durationSeconds: ((.lastMessageDate - .creationDate) / 1000 | floor),
initialLocation: .initialLocation,
responderUsername: .responderUsername,
requesterUsername: .requesterUsername,
hasPendingEdits: .hasPendingEdits,
isImported: .isImported,
interactionsCount: (.requests | length)
},
# インタラクション配列
interactions: [.requests | to_entries[] | transform_interaction]
}
transform_session.sh
#!/bin/bash
# GitHub Copilot Chat セッションログ整形スクリプト
#
# 使用方法:
# ./transform_session.sh <session.json> # 単一ファイル処理
# ./transform_session.sh <session.json> -o <output.json> # 出力ファイル指定
# ./transform_session.sh --all <workspace-dir> # 全セッション一括処理
#
# 例:
# ./transform_session.sh XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/chatSessions/YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY.json
# ./transform_session.sh --all XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
JQ_FILTER="${SCRIPT_DIR}/transform_chat_session.jq"
usage() {
echo "Usage: $0 <session.json> [-o <output.json>]"
echo " $0 --all <workspace-dir> [-o <output-dir>]"
echo ""
echo "Options:"
echo " -o <output> 出力先ファイル/ディレクトリを指定"
echo " --all ワークスペース内の全セッションを処理"
echo " --summary サマリー情報のみ出力（interactions省略）"
echo " -h, --help このヘルプを表示"
exit 1
}
# jqフィルターファイルの存在確認
if [[ ! -f "$JQ_FILTER" ]]; then
echo "Error: jq filter file not found: $JQ_FILTER" >&2
exit 1
fi
# 引数パース
OUTPUT=""
ALL_MODE=false
SUMMARY_MODE=false
while [[ $# -gt 0 ]]; do
case $1 in
-o)
OUTPUT="$2"
shift 2
;;
--all)
ALL_MODE=true
shift
;;
--summary)
SUMMARY_MODE=true
shift
;;
-h|--help)
usage
;;
*)
INPUT="$1"
shift
;;
esac
done
if [[ -z "$INPUT" ]]; then
usage
fi
# サマリーモード用の追加フィルター
if $SUMMARY_MODE; then
EXTRA_FILTER='| del(.interactions[].agentResponse.text) | del(.interactions[].agentResponse.thinking) | del(.interactions[].userMessage.text)'
else
EXTRA_FILTER=""
fi
# 単一ファイル処理
process_file() {
local input_file="$1"
local output_file="$2"
if [[ ! -f "$input_file" ]]; then
echo "Error: Input file not found: $input_file" >&2
return 1
fi
if [[ -n "$output_file" ]]; then
jq -f "$JQ_FILTER" "$input_file" $EXTRA_FILTER > "$output_file"
echo "Processed: $input_file -> $output_file"
else
jq -f "$JQ_FILTER" "$input_file" $EXTRA_FILTER
fi
}
# 全セッション処理
process_all() {
local workspace_dir="$1"
local output_dir="$2"
local sessions_dir="${workspace_dir}/chatSessions"
if [[ ! -d "$sessions_dir" ]]; then
echo "Error: chatSessions directory not found: $sessions_dir" >&2
exit 1
fi
if [[ -n "$output_dir" ]]; then
mkdir -p "$output_dir"
fi
for session_file in "$sessions_dir"/*.json; do
if [[ -f "$session_file" ]]; then
local basename=$(basename "$session_file")
if [[ -n "$output_dir" ]]; then
local output_file="${output_dir}/${basename%.json}_transformed.json"
process_file "$session_file" "$output_file"
else
echo "=== $basename ===" >&2
process_file "$session_file" ""
echo "" >&2
fi
fi
done
}
# メイン処理
if $ALL_MODE; then
process_all "$INPUT" "$OUTPUT"
else
process_file "$INPUT" "$OUTPUT"
fi
セッションを一覧する
整形スクリプトを作ってみると、どこにどのセッションがあるのかがわからない という問題が露呈しました。ワークスペース名やセクション名などはランダムなIDで、内容との関係がわからないですからね。
そこで、追加でセクション一覧をツリー形式で表示するスクリプトも作成しました。
extract_session_titles.sh
#!/bin/bash
# セッションログから customTitle を抽出し、workspace-id ごとのツリー形式で表示するスクリプト
#
# 使用方法:
# ./extract_session_titles.sh [base-dir] [options]
#
# オプション:
# --summary 統計情報のみを表示（ツリーは表示しない）
# --with-stats ツリーと統計情報の両方を表示
#
# 例:
# ./extract_session_titles.sh
# ./extract_session_titles.sh /path/to/workspaceStorage
# ./extract_session_titles.sh --summary
# ./extract_session_titles.sh . --with-stats
WORKSPACE_DIR="."
SHOW_TREE=true
SHOW_STATS=false
# 引数パース
while [[ $# -gt 0 ]]; do
case "$1" in
--summary)
SHOW_TREE=false
SHOW_STATS=true
shift
;;
--with-stats)
SHOW_STATS=true
shift
;;
-*)
echo "Unknown option: $1" >&2
exit 1
;;
*)
if [[ "$WORKSPACE_DIR" == "." ]]; then
WORKSPACE_DIR="$1"
fi
shift
;;
esac
done
# ディレクトリ存在確認
if [[ ! -d "$WORKSPACE_DIR" ]]; then
echo "Error: Directory not found: $WORKSPACE_DIR" >&2
exit 1
fi
# ツリー表示用のメイン処理
if $SHOW_TREE; then
# ワークスペース ID ごとにセッションをスキャン
find "$WORKSPACE_DIR" -maxdepth 2 -type d -name "chatSessions" | sort | while read sessions_dir; do
# ワークスペース ID を取得（chatSessions の親ディレクトリ）
workspace_id=$(basename "$(dirname "$sessions_dir")")
# セッションファイルがあるかチェック
if ! ls "$sessions_dir"/*.json &>/dev/null; then
continue
fi
# ワークスペース ID を出力
echo "$workspace_id"
# セッションファイルをソート順で処理
session_files=($(ls -1 "$sessions_dir"/*.json 2>/dev/null | sort))
file_count=${#session_files[@]}
for ((i=0; i<file_count; i++)); do
session_file="${session_files[$i]}"
# sessionId と customTitle を jq で抽出
session_id=$(jq -r '.sessionId' "$session_file" 2>/dev/null)
custom_title=$(jq -r '.customTitle' "$session_file" 2>/dev/null)
if [[ -z "$session_id" ]]; then
continue
fi
# ツリーの枝を決定
if [[ $i -eq $((file_count - 1)) ]]; then
prefix="└── "
else
prefix="├── "
fi
# customTitle のフォーマット
if [[ "$custom_title" == "null" || -z "$custom_title" ]]; then
echo "${prefix}${session_id}"
else
echo "${prefix}${session_id}: \"${custom_title}\""
fi
done
# ワークスペース間に空行を追加
echo ""
done
fi
# 統計情報を計算・表示
if $SHOW_STATS; then
if $SHOW_TREE; then
echo "═══════════════════════════════════════════════════════════"
echo " 統計情報"
echo "═══════════════════════════════════════════════════════════"
fi
# ワークスペースごとの統計を計算
declare -A workspace_counts
declare -a workspace_list
total_sessions=0
total_with_title=0
find "$WORKSPACE_DIR" -maxdepth 2 -type d -name "chatSessions" | sort | while read sessions_dir; do
workspace_id=$(basename "$(dirname "$sessions_dir")")
if ! ls "$sessions_dir"/*.json &>/dev/null; then
continue
fi
session_count=0
with_title_count=0
for session_file in "$sessions_dir"/*.json; do
session_count=$((session_count + 1))
custom_title=$(jq -r '.customTitle' "$session_file" 2>/dev/null)
if [[ "$custom_title" != "null" && -n "$custom_title" ]]; then
with_title_count=$((with_title_count + 1))
fi
done
echo "$workspace_id: $session_count sessions ($with_title_count with title)"
done | sort
# グローバル統計
echo ""
echo "総セッション数:"
find "$WORKSPACE_DIR" -maxdepth 2 -type d -name "chatSessions" -print0 2>/dev/null | \
xargs -0 -I {} sh -c 'ls -1 "$1"/*.json 2>/dev/null | wc -l' _ {} | \
awk '{sum += $1} END {print " " sum}'
fi
AIエージェントによるツール作成
上記のスクリプト、抽出処理以外にもやたらとオプション設定などが充実していることからおわかりかもしれませんが、これらのスクリプト自体もGitHub Copilot Chatに作成してもらっています。
せっかくAIによるAIセッションの分析というメタなテーマを扱っているので、ここでもその分析を実行してみましょう。
セッションログを丸ごと貼りますが、長いので後ろに要約を書きます。なお、念の為パスやIDを{CAPITAL_CASE}のように伏せ字にしています。
リクエスト(1)
このワークスペースには GitHub Copilot Chat のセッションログが記録されています。
"{workspace-id}/chatSessions/{session-id}.json" の形式で、セッションログの実体があります。
これらを加工して、AIエージェントの利用方法について分析し、ノウハウをフィードバックしようと考えています。
このために、生のセッションログから必要な情報を抜き出して整形するスクリプトを作成してください。
# 1. セッションログの解析
分析に必要なフィールドをピックアップします。
例として "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" を読み込み、インタラクションを評価するために必要となる情報をリストアップしてください。
セッション全体のメタデータがルートレベルに、インタラクションごとのデータがリストとして2階層で構成されることに注意すること。
また、例として与えたセッションログ以外で他にも必要なフィールドが無いかどうか、インタラクションの長さや階層の深さなどの観点で適切なログを見繕って確かめてください。
# 2. 整形スクリプトの実装
`jq`を利用してセッションログを加工するスクリプトを作成してください。
ステップ1で参照したセッションログデータに実際に適用して期待する出力が得られることを確認すること。
ユーザーの発言とエージェントの回答の本文は生データのまま保持されるようにしてください。また、ユーザーの発言とそれに対するエージェントの回答は対応がわかるようにすること
また、例として与えたセッションログ以外でもスクリプトが正しく動作することも確認すること。
- ログデータの加工のために、2ステップで実行させます
- 具体的なセッションログを指定して、ログとして必要そうなフィールドをAI自身にピックアップしてもらう
- そのフィールドを抽出するような
jqスクリプトを作成してもらう
-
workspaceStorageを開いてセッションを実行しています。PowerShellよりbashの方が使いやすいのでWSL経由で開いています。（後半で一括処理を行うので、速度的にはWindowsネイティブでやるべきだったかも。）
レスポンス(1)
ツールの選択を最適化しています...まず、指定されたセッションログファイルを読み込んで構造を理解します。
[](file://{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json#1-1) の 1 から 300 行を読み取り
ファイルが非常に長いので、構造をより理解するために続きを読み込みながら、他のセッションログも確認して比較します。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && find . -name "*.json" -path "*/chatSessions/*" -exec wc -l {} \; | sort -n | head -20
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && find . -name "*.json" -path "*/chatSessions/*" -exec wc -l {} \; | sort -rn | head -20
小さいファイルと大きいファイルの両方を調べて構造を把握します。まず小さいファイルから構造を確認しましょう。
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_1}/chatSessions/{SESSION_ID_1}.json" | jq 'keys'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq 'keys'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq 'del(.requests) | del(.contrib) | del(.selectedModel) | del(.attachments) | del(.selections)'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests | length'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0] | keys'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0] | {requestId, timestamp, agent, modelId, modelState, timeSpentWaiting, responseId}'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].message | keys'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].response | length'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '[.requests[0].response[].kind] | unique'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '[.requests[].response[].kind] | unique'
大きなセッションログも確認してkindの種類を網羅します。
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_2}.json" | jq '[.requests[].response[].kind] | unique'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].response[] | select(.kind == null) | keys' | head -20
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].response[] | select(.kind == null) | .value' | head -10
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].response[] | select(.kind == "toolInvocationSerialized") | keys' | head -30
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '[.requests[].response[] | select(.kind == "toolInvocationSerialized") | .toolId] | unique'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].response[] | select(.kind == "thinking") | keys' | head -20
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].response[] | select(.kind == "textEditGroup") | keys' | head -20
別のセッションログも確認して、他のフィールドがないか確認します。
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_2}.json" | jq 'del(.requests) | del(.contrib) | del(.selectedModel) | del(.attachments) | del(.selections)'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_2}.json" | jq '.requests | length'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_2}.json" | jq '.requests[0] | keys'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_2}.json" | jq '.requests[0].result'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].result | keys'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" | jq '.requests[0].result'
中サイズのセッションログも確認して、多様なデータを確認します。
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_3}.json" | jq '.'
Ran terminal command: cat "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_2}/chatSessions/{SESSION_ID_4}.json" | jq '.'
別のワークスペースで実際にrequestsがあるものを確認します。
Ran terminal command: find {APP_DATA}/Code/User/workspaceStorage -name "*.json" -path "*/chatSessions/*" -exec sh -c 'cnt=$(jq ".requests | length" "$1" 2>/dev/null); if [ "$cnt" != "0" ] && [ "$cnt" != "null" ] && [ -n "$cnt" ]; then wc -l < "$1" | tr -d " " | xargs printf "%s %s\n" "$1"; fi' _ {} \; | sort -t' ' -k2 -n | head -20
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && for f in */chatSessions/*.json; do cnt=$(jq ".requests | length" "$f" 2>/dev/null); if [ "$cnt" != "0" ] && [ "$cnt" != "null" ] && [ -n "$cnt" ] && [ "$cnt" -gt 0 ] 2>/dev/null; then lines=$(wc -l < "$f"); echo "$lines $cnt $f"; fi; done | sort -n | head -20
Ran terminal command: ls {APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/*.json | head -5 | while read f; do cnt=$(jq ".requests | length" "$f" 2>/dev/null); lines=$(wc -l < "$f"); echo "$lines $cnt $f"; done
Ran terminal command: jq ".requests | length" "{APP_DATA}/Code/User/workspaceStorage/{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_2}.json"
十分な情報が得られました。セッションログの構造をまとめてjqスクリプトを作成します。
ToDo 項目が 4 件作成されました
これまでの調査に基づいて、セッションログの構造と必要なフィールドをまとめます。
---
## セッションログ構造の解析結果
### ルートレベルメタデータ
| フィールド | 説明 | 存在確率 |
|-----------|------|---------|
| `version` | データフォーマットのバージョン | 必須 |
| `sessionId` | セッションの一意識別子 | 必須 |
| `creationDate` | セッション作成日時（Unix timestamp） | 必須 |
| `lastMessageDate` | 最終メッセージ日時（Unix timestamp） | 必須 |
| `customTitle` | ユーザー定義またはAI生成のタイトル | 任意 |
| `initialLocation` | UI上の初期位置（panel等） | 必須 |
| `responderUsername` | 応答者名（"GitHub Copilot"） | 必須 |
| `requesterUsername` | リクエスター名 | 任意 |
| `mode` | モード情報（agent, chat等） | 任意 |
| `selectedModel` | 使用されたモデルの詳細情報 | 任意 |
| `hasPendingEdits` | 未保存の編集があるか | 任意 |
| `isImported` | インポートされたセッションか | 任意 |
| `requests` | インタラクションのリスト | 必須 |
### インタラクション（requests配列の各要素）
| フィールド | 説明 |
|-----------|------|
| `requestId` | リクエストの一意識別子 |
| `responseId` | レスポンスの一意識別子 |
| `timestamp` | リクエストのタイムスタンプ |
| `message.text` | ユーザーの発言テキスト（本文） |
| `message.parts` | メッセージのパーツ情報 |
| `modelId` | 使用されたモデルID |
| `agent` | エージェント情報（extensionId, name等） |
| `variableData` | 添付された変数・コンテキスト |
| `response` | レスポンスパーツの配列 |
| `result` | 結果メタデータ（timings, details等） |
| `timeSpentWaiting` | 待ち時間 |
| `modelState` | モデルの状態・完了時刻 |
| `contentReferences` | 参照されたコンテンツ |
| `codeCitations` | コード引用情報 |
| `followups` | フォローアップ質問 |
### レスポンス（response配列の各要素）のkind
| kind | 説明 |
|------|------|
| `null`（キーなし） | エージェントのテキスト応答（value フィールド） |
| `thinking` | 思考プロセス |
| `toolInvocationSerialized` | ツール呼び出し情報（toolId, invocationMessage等） |
| `prepareToolInvocation` | ツール呼び出し準備 |
| `textEditGroup` | ファイル編集グループ |
| `mcpServersStarting` | MCPサーバー起動 |
| `inlineReference` | インライン参照 |
| `codeblockUri` | コードブロックURI |
| `undoStop` | アンドゥストップ |
| `progressTaskSerialized` | プログレスタスク |
| `confirmation` | 確認ダイアログ |
---
次に、jqスクリプトを作成します。
開始中: *jqスクリプトの実装* (3/4)
[](file://{APP_DATA}/Code/User/workspaceStorage/transform_chat_session.jq) が作成されました
スクリプトを実行してテストします。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" 2>&1 | head -100
スクリプトは動作しています。しかし、`interactionIndex`がnullになっています。修正が必要です。
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" 2>&1 | head -80
正しく動作しています。次に、大きいセッションログと、requestsが空のセッションログでもテストします。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_3}.json" 2>&1
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_2}.json" 2>&1 | head -100
大きなセッションログでも正しく動作しています。別のワークスペースのセッションログでもテストします。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_3}/chatSessions/{SESSION_ID_5}.json" 2>&1 | head -80
全て正しく動作しています。最後に、整形スクリプトにシェルラッパーを追加して使いやすくします。
完了済み: *jqスクリプトの実装* (3/4)
[](file://{APP_DATA}/Code/User/workspaceStorage/transform_session.sh) が作成されました
Ran terminal command: chmod +x {APP_DATA}/Code/User/workspaceStorage/transform_session.sh
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./transform_session.sh "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" --summary | head -50
正常に動作しています。最後にドキュメントを作成します。
[](file://{APP_DATA}/Code/User/workspaceStorage/README.md) が作成されました
完成しました。作成したファイルを確認します。
Ran terminal command: ls -la {APP_DATA}/Code/User/workspaceStorage/*.{jq,sh,md} 2>/dev/null
Ran terminal command: ls -la {APP_DATA}/Code/User/workspaceStorage/transform* {APP_DATA}/Code/User/workspaceStorage/README.md
---
## 完了報告
GitHub Copilot Chat のセッションログを整形するスクリプトを作成しました。
### 作成したファイル
| ファイル | 説明 |
|----------|------|
| transform_chat_session.jq | jqフィルター本体（4,262バイト） |
| transform_session.sh | シェルスクリプトラッパー（3,525バイト） |
| README.md | 使用方法とフィールド説明（6,524バイト） |
### セッションログ構造の解析結果
**ルートレベルメタデータ**:
- `sessionId`, `version`, `customTitle`, `creationDate`, `lastMessageDate`
- `mode` (agent/chat), `selectedModel`, `responderUsername`
**インタラクション（requests配列）**:
- `requestId`, `responseId`, `timestamp`, `modelId`
- `message.text` - ユーザーの発言本文
- `response[]` - エージェントの応答（kind別に分類）
- `kind=null` → テキスト応答（value）
- `kind=thinking` → 思考プロセス
- `kind=toolInvocationSerialized` → ツール呼び出し
- `kind=textEditGroup` → ファイル編集
### 使用例
```bash
# 単一ファイル処理
jq -f transform_chat_session.jq session.json
# シェルスクリプト経由（出力ファイル指定）
./transform_session.sh session.json -o output.json
# サマリーモード（本文除外）
./transform_session.sh session.json --summary
# ワークスペース全体を一括処理
./transform_session.sh --all {WORK_SPACE_ID_0} -o ./transformed/
```
### テスト結果
以下のセッションログで正常動作を確認:
1. 指定されたセッション（4インタラクション、57,359行）
2. 空のセッション（0インタラクション）
3. 最大セッション（37インタラクション、402,141行）
4. 別ワークスペースのセッション（19インタラクション）
Made changes.
- ファイルを読んでその内容を分析して……を繰り返す複雑な処理のため、最上位の Claude Opus 4.5 3モデルを使用しています
- ちなみに、同じリクエストで GPT-4.1 でも試しましたが、指定した以外のログを読み込もうとしない、jqクエリを出力しただけで出力確認を実行してくれないなど能力としてはかなり劣る結果となりました
- ファイルサイズによって様々なバリエーションのセッションデータを読み込み、いい感じにフィールドを抽出できています
- jqって関数定義もできるんですね。私が自分で書くよりも可読性の高いコードになっている気がします
- 最終的にE2Eで正しく出力が得られる状態まで自分で修正して、一発で動作品を完成させてくれました
リクエスト(2)
- モデルやモードはセッション途中で切り替えられるので、ルートレベル情報には不要です（セッションログには最後のインタラクションで使用されたものが記載されているだけのはずです）
- タイムスタンプはフォーマット後のものだけ記載されていればいいです。また、TZまで明記してください（この時刻はUTCだと思うので"Z"がつけばいいと思います）
- ざっと出力物を見てみて、修正依頼を出してみます
- 重複する情報の削除
- タイムスタンプを ISO 8601 形式で統一
レスポンス(2)
ご指摘ありがとうございます。修正します。
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
修正したスクリプトで再度テストします。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" > log.json && head -60 log.json
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" 2>&1 | head -60
完璧です！修正が正しく反映されました。log.jsonに保存します。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq -f transform_chat_session.jq "{WORK_SPACE_ID_0}/chatSessions/{SESSION_ID_0}.json" > log.json
READMEも修正します。
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
修正完了しました。変更内容を確認します。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq '.session' log.json
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && jq '.interactions[0] | {interactionIndex, timestamp, modelId, completedAt: .modelState.completedAt, durationSeconds: .modelState.durationSeconds}' log.json
完璧です！修正内容をまとめます。
---
## 修正完了
ご指摘いただいた点を修正しました：
### 1. セッションレベルの `mode` と `selectedModel` を削除
モデルやモードはインタラクションごとに切り替え可能なため、各インタラクションの `modelId` で確認できるようにしました。
**変更前**:
```json
{
"session": {
"mode": { "id": "agent", "kind": "agent" },
"selectedModel": { "identifier": "copilot/gpt-5.2", ... }
}
}
```
**変更後**:
```json
{
"session": {
"responderUsername": "GitHub Copilot",
"interactionsCount": 4
},
"interactions": [
{
"modelId": "copilot/claude-opus-4.5",
...
}
]
}
```
### 2. タイムスタンプをISO 8601形式（UTC）に統一
Unix timestampのフィールドを削除し、フォーマット済みのもののみを保持。タイムゾーン（`Z`）を明記しました。
**変更前**:
```json
{
"creationDate": 1767597243759,
"creationDateFormatted": "2026-01-05 07:14:03",
"timestamp": 1767597698830,
"timestampFormatted": "2026-01-05 07:21:38"
}
```
**変更後**:
```json
{
"creationDate": "2026-01-05 07:14:03Z",
"lastMessageDate": "2026-01-09 09:43:45Z",
"timestamp": "2026-01-05 07:21:38Z",
"completedAt": "2026-01-05 07:27:57Z"
}
```
すべてのタイムスタンプがUTC（協定世界時）で `YYYY-MM-DD HH:MM:SSZ` 形式で出力されるようになりました。
Made changes.
- 先程よりも部分的な修正なのでミドルレンジの Claude Sonnet 4.5 で実行しました
- 動作確認まで完了し、READMEも更新してくれています
リクエスト(3)
このワークスペース配下にある全てのセッションログからcustomTitleを抽出し、session-idとcustomTitleの対応をworkspace-idごとのツリー形式で表示するスクリプトを作成してください
- セッションのタイトル一覧も欲しくなったので、そのためのスクリプトも作成してもらいます
レスポンス(3)
[](file://{APP_DATA}/Code/User/workspaceStorage/extract_session_titles.sh) が作成されました
Ran terminal command: chmod +x {APP_DATA}/Code/User/workspaceStorage/extract_session_titles.sh
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./extract_session_titles.sh | head -60
出力がまだ整形されていません。もっとシンプルで効果的な実装に修正します。
"ファイル内の文字列の置換" を使用しています
```
```
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./extract_session_titles.sh | head -80
完璧です！さらに詳しく表示して、最後まで確認します。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./extract_session_titles.sh | tail -60
素晴らしい！全体を統計として表示するオプションも追加します。
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
スクリプトの最後に統計情報を出力する部分を追加します。
[](file://{APP_DATA}/Code/User/workspaceStorage/extract_session_titles.sh#1-1) の 1 から 80 行を読み取り
"ファイル内の文字列の置換" を使用しています
```
```
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./extract_session_titles.sh --summary
引数パース順序を修正します。
"ファイル内の文字列の置換" を使用しています
```
```
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./extract_session_titles.sh --summary
完璧です！最後に --with-stats オプションもテストします。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./extract_session_titles.sh --with-stats | tail -50
素晴らしい！スクリプトが完成しました。最後にスクリプト内容を確認し、作成したツール群の使い方を記述します。
Ran terminal command: cd {APP_DATA}/Code/User/workspaceStorage && ./extract_session_titles.sh {WORK_SPACE_ID_0} | head -50
完璧です！最後にREADMEを更新して、使用方法をまとめます。
"ファイル内の文字列の置換" を使用しています
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
"ファイル内の文字列の置換" を使用しています
```
```
完了しました！セッションログをツリー形式で表示し、統計情報を確認するスクリプトを作成しました。
---
## 完成したスクリプト
### extract_session_titles.sh
**機能**:
- ワークスペース配下のすべてのセッションログから `sessionId` と `customTitle` を抽出
- workspace-id ごとのツリー形式で表示
- workspace-id ごとのセッション数と customTitle を持つセッション数を集計
**使用例**:
```bash
# 全セッションをツリー表示
./extract_session_titles.sh
# 特定ワークスペースのセッションのみ表示
./extract_session_titles.sh {WORK_SPACE_ID_0}
# 統計情報のみ表示
./extract_session_titles.sh --summary
```
**出力例** (統計モード):
```
{WORK_SPACE_ID_0}: 84 sessions (64 with title)
{WORK_SPACE_ID_3}: 4 sessions (4 with title)
{WORK_SPACE_ID_4}: 16 sessions (13 with title)
...
総セッション数:
288
```
**出力例** (ツリーモード):
```
{WORK_SPACE_ID_0}
├── {SESSION_ID_0}: "{CUSTOM_TITLE_0}"
├── {SESSION_ID_6}: "{CUSTOM_TITLE_6}"
└── {SESSION_ID_7}: "{CUSTOM_TITLE_7}"
```
### 既存ツール（transform_chat_session.jq と transform_session.sh）
セッションログを整形スキーマで出力し、インタラクションの詳細情報を抽出できます。
Made changes.
- 試しにもっと安価な Claude Haiku 4.5 で実行してみましたが、これでも十分に対応できています
- (2)もHaikuで十分だったかもしれませんね。(1)をOpusで実行した結果がコンテキストにあるのでそれに則っている分安定度が増しているのかもしれませんが
- 動作確認で毎回全件処理しようとしてかなり時間を要したので、テストは一部ずつ実行するという指示は入れたほうが良かったかもしれません
セッションログのフィードバック
試しに、先程作成したセッションログ抽出スクリプトを使って、このスクリプト作成のセッションログ（抽出版）を Gemini で解析してもらってみます。
回答
提供されたセッションログ（GitHub Copilot Chatとの対話）を分析しました。
ユーザーは「AIエージェントの利用分析を行うためのログ整形ツール」を作成するという明確なゴールを持っており、Copilotを単なるコード生成機としてではなく、**「仕様策定から実装、テストまで行う開発パートナー」**として巧みに活用しています。
以下に、AIエージェント活用の観点から見た「良い点（Good）」と「改善・工夫の余地（Improvement）」をまとめます。
---
### 1. 良い点 (Good Points)
**① 目的とコンテキストの明確な提示**
ユーザーは冒頭で「何を作るか（整形スクリプト）」だけでなく、**「何のために使うか（AIエージェントの利用方法分析）」**を伝えています。
> *「これらを加工して、AIエージェントの利用方法について分析し、ノウハウをフィードバックしようと考えています。」*
* **効果:** AIは単にJSONをパースするだけでなく、「分析に役立つフィールド（タイムスタンプ、モデル名、対話の往復）」を優先的に抽出する判断ができました。
**② 具体的な「参照検体」の提示**
抽象的な指示ではなく、具体的なファイルパス（例: `{WORK_SPACE_ID_0}.../{SESION_ID_0}json`）を提示し、中身を確認させました。
* **効果:** ハルシネーション（嘘のデータ構造の捏造）を防ぎ、実データに基づいた正確なスキーマ解析を実現しています。特に「例として与えた以外でも必要なフィールドがないか確認して」という指示は、AIに自律的な調査（Agent機能の活用）を促す優れたプロンプトです。
**③ Human-in-the-loop（人間によるレビューと修正）**
Interaction 1において、ユーザーはAIの成果物に対し、論理的な誤りを指摘しています。
> *「モデルやモードはセッション途中で切り替えられるので…」*
> *「TZまで明記してください」*
* **効果:** AIは「最後に使ったモデル」をセッション全体の設定と誤認していましたが、ユーザーのドメイン知識（Copilotの仕様理解）によってこれを補正しました。一発で完璧を求めず、**「実装→レビュー→修正」というサイクル**を回せている点が非常に良いです。
**④ 段階的なスコープの拡大**
最初は「単一ファイルの整形（Interaction 0）」から始め、形式が固まった後に「ワークスペース全体の集計とツリー表示（Interaction 2）」へとタスクを拡大しました。
* **効果:** いきなり複雑なタスクを投げるとAIは混乱しやすいですが、基礎となるロジック（JSON解析）を確定させてから応用（ディレクトリ探索・集計）に進むことで、安定したコード生成に成功しています。
---
### 2. 改善・工夫の余地 (Areas for Improvement)
**① バリデーションプロセスの明示化**
Interaction 0で、AIは「他のセッションログも確認して…」と言いつつ、実際にどの程度のエッジケース（極端に短いログ、エラーを含むログなど）を考慮したかはAIの自己申告に依存しています。
* **改善案:** 「調査した結果、ログの構造にはAパターンとBパターンが見つかりました」といった**調査レポートを先に出力させてから**、実装に移るよう指示すると、手戻りをさらに減らせます。
**② 「仕様の固定」と「実装」の分離**
Interaction 1での修正は、本来Interaction 0の段階で防げた可能性があります。
* **改善案:** いきなりスクリプトを書かせる前に、「抽出するフィールドと、その出力フォーマット案（JSON Schemaやテーブル定義）」を一度AIに提示させ、ユーザーがそれにOKを出してからコーディングさせる手順を踏むと、コードの書き直し時間を節約できます。
**③ エラーハンドリングの要件定義**
大量のJSONファイルを処理する際（Interaction 2）、パースエラーや破損ファイルがあった場合の挙動（スキップするのか、エラーログを出すのか）が指示に含まれていませんでした。
* **改善案:** 実運用ツールを作る場合、「読み込みに失敗したファイルは `error.log` に出力して処理を継続すること」といった非機能要件を加えると、より堅牢なスクリプトになります。
---
### 3. 総評：AIエージェント活用の成熟度
このユーザーは、**Copilot Workspace（またはAgentモード）の特性を非常によく理解しています**。
特に、「ファイルの中身を見に行かせる」「ターミナルでコマンドを実行させて動作確認させる」といった権限を適切に与え、AIを自律的なエンジニアとして扱っています。
**このログから得られる最大のノウハウ:**
> **「AIには『正解』を教えるのではなく、『正解を見つけるための検証手順（複数のファイルを見て構造を比較せよ、など）』を指示する」**
このアプローチにより、人間が仕様書を書く手間を省きつつ、高品質なツールを作成することに成功しています。
---
### 次のアクション
この分析結果に基づき、**「AIエージェントへの効果的な指示出しテンプレート（タスク定義・調査指示・実装指示の3段構成）」**を作成しましょうか？
- 指示が具体的でゴールが明示されているという点、PDCAが回しやすい構造になっている点が評価されています
- 改善点としては一気に実装に入るのではなく仕様策定までで一旦人間のレビューを挟んでから実行したほうが手戻りが少ないという点が指摘されています
- ただし、今回はそれほど厳格な仕様があるわけではなく、また途中でレスポンスを分割すると逆にコストが上がってしまうというGitHub Copilotの課金体系の都合もあるため良し悪しですね
ナレッジの抽出
Obsidianに記録する用の、知識抽出も実行してみます。
出力
2026-01-09.md
# 「セッションログの整形スクリプト作成」セッションログ分析
## Summary
GitHub Copilot Chat のセッションログ処理基盤を構築したセッション。3つのインタラクションで[[JSON]]形式のセッションログから構造分析・[[jq]]スクリプト作成・ユーザーフィードバック対応・ワークスペース全体のツール開発を実現。[[データパイプライン]]の設計原則と[[インクリメンタル実装]]の実践例。
---
## Step 1: セッション内容の再構成（事実抽出）
### 実施した作業
1. セッション期間: 2026-01-09 10:15:08Z～11:06:30Z（51分）
2. インタラクション数: 3回
### インタラクション #0 （10:37:18Z～10:48:14Z、655秒）
- ユーザーリクエスト: GitHub Copilot Chat セッションログ整形スクリプト作成
- セッションログ構造分析
- [[jq]]フィルター実装
- [[シェル]]スクリプト作成
- ドキュメント化
- エージェント: Claude Opus 4.5
- ツール呼び出し: 複数セッションログの読み取り、ターミナル実行、ファイル作成・修正
- 成果: transform_chat_session.jq, transform_session.sh, README.md 作成
### インタラクション #1 （11:00:36Z～11:02:23Z、106秒）
- ユーザーフィードバック: スキーマ設計の改善指摘
- セッションレベルの mode/selectedModel 削除
- タイムスタンプの ISO 8601 形式統一（UTC Z 記法）
- エージェント: Claude Sonnet 4.5
- ツール呼び出し: ファイル置換、テスト実行
- 成果: jq スクリプト修正、ドキュメント更新
### インタラクション #2 （11:06:30Z～11:17:05Z、634秒）
- ユーザーリクエスト: ワークスペース全体のセッションタイトル抽出スクリプト
- ツリー形式表示（workspace-id 単位）
- 統計情報オプション
- エージェント: Claude Haiku 4.5
- ツール呼び出し: シェルスクリプト作成・修正、ターミナル実行
- 成果: extract_session_titles.sh 完成
---
## Step 2: 技術的知識の抽出・抽象化
### 問題領域
[[GitHub Copilot Chat]] セッションログの[[メタデータ]]から[[ノウハウ]]を抽出する際に必要なデータパイプライン設計。
実態：
- セッション全体メタデータ（ルートレベル）
- インタラクション配列（時系列）
- レスポンス配列（kind 別分類）
という階層構造
### 採用したアプローチ
1. [[jq]]による JSON 変換パイプライン
- セッションメタデータとインタラクション分離
- kind 別レスポンス分類
- Unix timestamp → ISO 8601 UTC 形式（YYYY-MM-DD HH:MM:SSZ）変換
2. [[シェルスクリプト]]ラッパー設計
- 単一ファイル処理モード
- ワークスペース全体処理モード
- サマリーモード（統計情報のみ）
### 判断理由・トレードオフ
- [[JSON]]操作に[[jq]]を選定：宣言的フィルター記述、パイプ構成が可能
- シェルラッパー層を追加：CLIユーザビリティと機能拡張性の両立
- ファイル編集グループ表現：[[テキストエディタ]]統合を視野に
### 設計原則
[[構造化ログ]]から[[知識]]への変換は段階的フィルタリング：
1. [[メタデータ]]レベルの抽出（時刻、モデル、セッション ID）
2. インタラクション単位の分解（ユーザー発言 vs エージェント応答）
3. 応答形式別の分類（テキスト、ツール呼び出し、思考プロセス）
---
## Step 3: Copilot / エージェント活用ノウハウの抽出
### 投げたプロンプトの意図
1. 初回リクエスト
- 複数サンプルログの段階的調査を明示
- 予期しないフィールド発見を促す
- [[仕様作成]]前の十分な[[ドメイン理解]]
2. フィードバック（修正指示）
- [[正規化]]の判断基準を明確に
- [[スキーマ設計]]の制約条件を示す
- モデル切り替え時のメタデータ扱いを指摘
3. 追加機能リクエスト
- [[ユースケース]]を暗示（統計情報の需要）
- [[スクリプト化]]による再利用可能性
### 期待通りだった点
- 初回：エージェントが複数セッションログを自主的に調査
- サイズ別（小・中・大）の多様性確認
- kind 分類の網羅的把握
- テーブル形式での構造化出力
- 修正対応：フィードバックをすぐに実装
- スキーマ変更の伝播先を正確に把握
- テスト実行で正しさ確認
### 期待外れだった点
- クローズド質問への曖昧な回答
- 最初「requests が存在しない」という仮定をエージェントが勝手に設定
- ユーザーが明示的に「調査対象の複数サンプル」を指定するまで気付かず
### 有効だった追加指示・修正指示
1. 「TZ まで明記」という制約
- 曖昧な「フォーマット後のみ」を具体化
- エージェントが正しく[[ISO 8601]] UTC 形式に統一
2. 「ツリー形式で」という UI 表現
- エージェントが[[tree]]コマンド互換の出力を自動生成
- 統計情報オプションを追加する動機付けになった
3. 「ワークスペース配下の全て」という スコープ
- 単一ファイル処理からワークスペース全体処理への拡張を誘導
### 次回以降に再利用すべきプロンプト構造
1. [[複数サンプル調査]]の明示
```
「以下の複数ファイルを確認して...」
（小・中・大規模サンプルの明記）
```
2. [[スキーマ設計]]の制約明示
```
「以下を保持しないこと：...」
「タイムスタンプはこの形式で：...」
```
3. [[ユースケース]]の言及
```
「後で検索・比較するための基盤として」
「複数セッションを統計分析するために」
```
---
## Step 4: 既存 Obsidian 知識との比較・位置づけ
### 既存知識との関係
- [[jq]]: 既出、JSON変換ユーティリティ
- [[シェル]]スクリプティング: 既出、システム統合
- [[GitHub Copilot Chat]]: 新規トピック、[[エージェント利用]]の実践例
- [[メタデータ]]抽出: 既出、データパイプライン設計に適用
- [[ISO 8601]]: 既出、タイムスタンプ標準化に適用
### 新規トピック
1. [[Copilot Chat]] のセッション構造
- JSON スキーマドキュメント
- kind 分類体系（nullテキスト、thinking、toolInvocationSerialized 等）
2. [[エージェント]]の[[インクリメンタル実装]]
- フィードバックループの効果的な回し方
- モデル選定（Opus 4.5 → Sonnet → Haiku）と処理時間の関係
3. [[データパイプライン]]の[[可読性]]設計
- jq による[[宣言的]]フィルター記述
- シェルラッパーによる CLI インターフェース構築
### 位置づけ
このセッションは[[エージェント]]とのコラボレーションで[[ツールチェーン]]を構築する実践例として記録。[[イテレーティブ改善]]の重要性を示す。
---
## Step 5: 再利用可能な知識への整形
### Summary（一文）
[[GitHub Copilot Chat]] のセッションログを[[JSON]]から[[構造化データ]]へ変換する[[パイプライン]]を[[jq]]と[[シェル]]で実装し、[[複数インタラクション]]を通じた[[エージェント]]との[[フィードバックループ]]でスキーマを反復改善するプロセス。
### Tips
1. [[JSON スキーマ]]設計時の段階的調査
- サンプルは「小・中・大」サイズ別に複数用意
- 予期しないフィールドを発見できる観点を意識
2. タイムスタンプの[[正規化]]
- Unix timestamp と可読形式の両方を保持するのは冗長
- 用途（再計算 vs 表示）に応じて単一形式に統一
3. [[エージェント]]への制約明示
- 「保持しない」という否定形より「この形式で」という肯定形
- 具体的な出力例を示すと精度向上
### Anti-pattern
- スキーマを決めずに実装開始
- 後から「このフィールド不要」という修正が多発
- 最初の 1～2 サンプル調査で仕様を固める
- モデル選定を意識しない
- 初回複雑分析（Opus 4.5）→ 修正反映（Sonnet）→ 追加機能（Haiku）
- コストと処理時間のトレードオフを活用
### チェックリスト（次回同様の作業時）
- [ ] サンプルログを複数サイズ用意したか？
- [ ] フィールドの「保持 vs 削除」判定基準を明確化したか？
- [ ] タイムスタンプフォーマットを統一したか？
- [ ] ユースケース（検索・比較・統計）を念頭に置いたか？
- [ ] [[シェルラッパー]]でユーザビリティを確保したか？
- [ ] [[README]] に使用例を具体的に記載したか？
---
## Step 6: Obsidian 用 Markdown 最終整形
### 記法確認
- 強調構文（`**` / `_`）の使用なし ✓
- 重要語・概念を `[[Wikiリンク]]` で表現 ✓
- 箇条書き・見出し・リンクで情報構造を表現 ✓
### ファイル仕様準拠
- ファイル名: `docs/journals/2026-01-12.md` ✓
- 推奨構成に従う ✓
### Links / Tags
#### 関連ノート
- [[GitHub Copilot Chat]]
- [[jq]]
- [[JSON]]
- [[シェル]]スクリプティング
- [[データパイプライン]]
- [[エージェント利用]]
- [[メタデータ]]抽出
- [[ISO 8601]]
- [[Wikiリンク]]記法
- [[インクリメンタル実装]]
#### タグ
- #tool/copilot
- #tool/jq
- #tool/shell
- #practice/agent-feedback-loop
- #practice/schema-design
- #topic/session-analysis
- #topic/data-transformation
- #pattern/pipe-architecture
---
## Done Definition Checklist
- [x] Markdown として構文エラーがない
- [x] 強調構文（`**` / `_`）を使用していない
- [x] 重要キーワードが本文中で `[[リンク]]` 化されている
- [x] 見出し構成・セクション名が指定フォーマットに準拠している
- [x] 技術的判断理由が明文化されている
- [x] Copilot への指示ノウハウが抽象化されている
- [x] Obsidian にそのまま配置可能な Markdown である
- [x] 将来のプロジェクトメンバーが検索・リンク経由で再利用できる
---
## 実装上の気づき
このセッションの本質は[[エージェント]]との[[フィードバックループ]]で初期設計の不備を段階的に改善するプロセスだった。特に：
1. 初回で[[データ構造]]を完全に把握できず、[[Copilot]]が「複数サンプル調査」を自主的に実施した柔軟性
2. ユーザーの「TZ まで明記」という一言で[[正規化]]方針が確定した効率性
3. 3回のインタラクションで「分析ツール→修正→ワークスペース全体処理」と段階的に拡張したスコープ管理
これらは[[AI アシスタント]]の活用における「指定と対話のバランス」を示唆する。
- 使用したモデルや実行時間など、メタデータも正しく抽出されています
まとめ
最近のコーディングエージェントの発展には目覚ましいものがありますね。指示の仕方やコンテキストの与え方をうまくやれば、実装はほとんどエージェント任せで良くなってきています。
AIエージェントの活用において、ユーザーがどのように入力し、その結果どんなクオリティのレスポンスが得られるかというのは重要なファクターです。
「こういう風に指示したらうまく自分で資料を探して読み込んでくれた」
「このモデルだとツールをうまく使ってくれなかったけれど、こっちのモデルだとうまくいった3」
など、AIに与える指示とその応答は重要な資料になります。過去のやり取りをログとして保存し分析することで、AIエージェントを使いこなすための人間側のノウハウを向上させていけます。成功した対話パターンをナレッジとして抽出し、Obsidianなどのナレッジベースに蓄積していけば、AIを使いこなすための強力な資産となるでしょう4。
今回作成したセッションログ抽出スクリプト群も、そのまま活用いただいても良いですが、フィールド選択もざっと見でいい感じそうなのでほとんどお任せのままなので、よく見てみたらもっとこんな情報を追加で記録したいというのは出てくると思います。ニーズに合わせてAIエージェントに改良を依頼してみるとより使いやすいと思います。
今回の記事作成では手作業で行いましたが、IDをサニタイズして機密情報をマスクするみたいな機能が追加できれば、分析が得意なチャットAIに投げるみたいな使い方もできそうです。
以上、AIエージェントを活用したセッションログの整形と分析の事例紹介でした。
-
Visual Studio Code バージョン: 1.108.0, 拡張機能
github.copilot-chatバージョン: 0.36.0 ↩ -
この記事を添付してエージェントモードでコマンドラインを叩かせればうまいこと探してくれるんじゃないかと思います ↩
-
GitHub Copilot Chatではレスポンスごとに異なるモデルを選択でき、モデルによってコストが異なります。Proプランだと月に「プレミアムリクエスト」が300枠まで使用でき、1往復ごとに"Claude Opus 4.5"では3倍、"Claude Sonnet 4.5"では1倍、"Claude Haiku 4.5"では0.3倍、"GPT-4.1"では0倍（制限無し）のカウントとなります（2026-01-12現在）。 ↩ ↩2
-
対話情報だけならUIに表示されている内容をコピペするだけでも分析は可能ですが、時刻やモデル情報などはエージェントが取得できないので今回のログファイル加工に至りました。 ↩