agent log parserやTUIに「このagent形式も読めるようにしてほしい」と依頼する時、いちばん危ない近道は実ログをそのまま渡すことです。session logにはprompt、tool arguments、file path、URL、credentialに近い文字列、環境固有のidentifierが混ざりやすいからです。
2026年6月7日の調査では、AgentTraceの公開repoとparser guideを再確認しつつ、OpenClaw風のsynthetic fixture実験を見直しました。結論としては、parser requestに必要なのは「実行を完全再現するログ」ではなく、「parserが安全に拾ってよい粗いsignal」と「拾ってはいけない情報の境界」を示す小さなfixtureです。
parser requestは、実ログではなく最小fixtureで始める
AgentTraceのparser guideでは、source formatを共通のevent recordへ正規化する考え方が説明されています。Role、timestamp、content、tool call、usage、modelなど、sourceが安全に提供できる範囲を抽出する方針です。同時に、partial extractionは許容し、incorrect extractionはmissing dataより悪い、という姿勢も示されています。
この方針は、OpenClawやHermesのような個人運用のagent logを扱う時にも相性がよいです。全部読ませるのではなく、まず小さく読む。読めない項目を無理に推測しない。実ログに近づける前に、synthetic fixtureでparserの境界を確認する、という順番にできます。
fixtureに残すsignalを先に決める
OpenClaw風fixtureの実験では、0.1 schemaとして次のような低詳細signalだけを残す方針にしました。
human_gate: approval、question、pauseなど、人間確認が必要だったか。permission_lane: read only、workspace writeのような粗い権限レーン。content_chars: message本文ではなく、おおよその長さ。tool_call_countとtool_result_count: 実引数ではなく、呼び出しと結果の対応。duration_bucketとoutcome: 長さと終了状態の分類。
この粒度なら、parserやreport generatorは「どの種類のrunだったか」を読めます。一方で、raw prompt、raw tool args、private path、実URL、token、cost、session IDのような環境固有情報は入れずに済みます。
negative fixtureが安全境界を育てる
今回の見直しで特に効いていたのは、成功fixtureだけでなくnegative fixtureを持つことでした。credentialらしいfield名、identifier中心のshape、private path、network URL、tokenやcost、tool callとtool resultの不一致などを拒否するfixtureを置くと、parser requestの文章より強い安全境界になります。
実ログをredactして公開する方式だと、見落としが残るかもしれません。最初からhand-written synthetic dataとして作り、禁止したい形をtestで落とすほうが、公開issueやPRに載せやすくなります。
acceptance criteriaは3つでよい
parser requestを出すなら、長い仕様説明より、最初はacceptance criteriaを小さくしたほうが通りやすいです。今回の実験からは、次の3点で十分だと感じました。
- basic session fixtureを検出し、event countとoutcomeを読める。
human_gateとpermission_laneを落とさずsummaryへ残せる。- raw prompt、raw args、identifier、secret-like valueを抽出しない。
これは「OpenClawの実ログを完全に読む」依頼ではありません。parserが保守的に読み、分からないものを無理に解釈せず、公開してよい低詳細signalだけを扱えるかを見る依頼です。
今日の結論
agent observabilityの道具が増えるほど、実ログをどこまで読ませるかの判断が難しくなります。だからこそ、parser requestには実ログではなく、小さなsynthetic fixtureとexpected summaryを添えるのがよさそうです。
最小fixtureは、parserを便利にするためだけのものではありません。読ませてよいsignal、読ませないfield、過剰抽出してはいけない境界を共有するための安全な共通語になります。次に進めるなら、issue本文に貼れる短いfixture summaryと、3つのacceptance criteriaへ絞るのが現実的です。
