Coding Agentの作業ログは、あとから学習するにはとても役に立ちます。どのコマンドを試したか、どこで止まったか、なぜ人間確認に回したかが残っていれば、次の作業者や翌日の自分が同じ迷いを繰り返しにくくなります。
一方で、実行ログをそのまま公開記事やOSSのfixtureに使うのは危険です。credentialやprivate URLを消すだけでは足りず、相関の手がかりになるfield名や細かすぎる実行情報まで混ざることがあります。2026年5月末から6月頭のOpenClaw周辺の整理では、この境界が「値を伏せる」から「残してよいsignalだけを選ぶ」方向へ変わってきました。
残してよいのは、再現に必要な粗いsignal
公開用fixtureに残しやすいのは、個人や環境に結びつきにくく、挙動の理解に役立つ情報です。たとえば、tool callの件数、read/write/executeのようなpermission lane、成功・失敗・保留のoutcome、人間確認が必要だった理由、duration bucket、検証済みか未検証か、といった粒度です。
ここで大事なのは、実際の値よりも判断の形です。「何件の操作があり、どの権限レーンに入り、最後は成功なのか、人間確認なのか、未検証なのか」が分かれば、fixtureとしては十分なことが多いです。
消すべきものは、秘密値だけではない
消す対象はtoken、cookie、password、private keyだけではありません。user id、conversation id、workspace id、host名、browser profile、channel id、tenant名、installation id、deployment名、service account名のようなidentifierも避けます。値を伏せてもfield名の組み合わせが残ると、内部構造や利用環境の推測材料になることがあります。
そのため、公開用fixtureでは実ログを軽くマスクするのではなく、最初からsyntheticなサンプルへ置き換える方が扱いやすいです。実ログはローカルで検証し、公開側には「こういう状態を表す架空のイベント」を置く、という分け方です。
abstainやhuman reviewも成功パターンとして残す
Agentの評価では、完了した作業だけを見がちです。しかし実運用では、止まるべき時に止まった、権限が足りないので人間に回した、証拠が弱いので何もしなかった、という判断も重要です。
fixtureにabstained、needs_human_review、blocked_by_scope、verification_gapのようなoutcomeを入れておくと、agentが「作業したか」だけでなく「越えてはいけない境界を守れたか」も確認できます。これは、自律性を高めるより先に、運用の信頼性を上げるための小さな足場になります。
記事化する時の実用チェック
- 実ログの本文、private URL、credential、host名、ID類を記事に出さない。
- 公開するなら、synthetic fixtureか抽象化した表現に置き換える。
- 件数、権限レーン、outcome、human gate、未検証理由のような粗いsignalだけを残す。
- 「成功」だけでなく、何もしない判断や人間確認へ逃がした判断も記録する。
- 公開前に、既存記事との重複と、読者にとっての学びがあるかを見る。
まとめると、Agentログの公開用fixture化は、ログをきれいに見せる作業ではありません。読者や開発者が学べるsignalを残しつつ、個人・環境・権限に結びつくidentifierを落とす作業です。この切り分けができると、Coding Agentの失敗や保留も、公開可能な学習材料へ変えやすくなります。
