24
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

記憶に頼るな。Claudeセッションの記録を取ろう

24
Last updated at Posted at 2026-10-26

1. AIをどう使ったか、覚えていますか?

普段、Claude CodeなどのコーディングAIを使って開発をしている皆さんに質問です。

「自分が適切にコーディングAIを使えているかどうか、事例を挙げて具体的に説明することができますか?」

私の場合、提出する人事評価の材料としてこれが必要になりました。が、記憶力に自信はありません。今やほとんど自然言語のやり取りだけで行われる作業の一つ一つでどういう判断をしたか、どう指示をしたかなど、覚えておくことは到底できません。

そこで、私は 「記憶できないなら記録を取ってしまえばいい」 という回答を出しました。記録すべき判断などはセッションに入っているので、セッションの終わり際に呼び出す「統合振り返りskill」を作ってみてはどうかと考え、運用し始めてみました。

今回、そのアイデアの共有をメインとして、skill自体とその今のところの成果を紹介してみようということでこの記事を書いてみました。

2. どんなskill?

このskillの使い方は至ってシンプルです。「一通り実装は済んだな」というタイミングで、そのセッション内で /decision-log を呼ぶだけです。大まかにこのskillがやってくれるのは、

  • セッション内のやり取りから、あらかじめ決めた観点で「判断」にあたるものを拾う
    • 技術や構成の選定(採用しなかった案とその理由も)
    • AIの案をそのまま通さず変えた箇所
    • PRを出す前にセルフレビューを回したか
    • 生成コードのライセンスや、AIに渡した情報の機密性を確認したか
  • 拾った内容を月ごとの振り返りに追記する
  • 選定があればADRも書く

といったことです。

そして記録そのものと記録する観点は、skill定義とは別のディレクトリに蓄積しています。私の場合、次のような構成でまとめてみています。

~/.claude/skills/decision-log/SKILL.md    # 手順だけ。何を拾うかは持たない
<記録先>/振り返り観点.md                  # セッションの何を拾うか、拾わないか
<記録先>/振り返り/<YYYY-MM>.md            # 振り返り内容のジャーナル。月ごとに追記
<記録先>/adr/NNNN-<タイトル>.md           # 判断に基づく選定があったとき

3. 品質を確保するために

AIは「自分を評価して」系統の指示をするとだいたい良いように解釈した言葉を贈ってくれます。お悩み相談などしているならありがたいですが、こと記録となるとそれでは困ります。事実ベースで書くことを徹底させ、「やっていないことは書くな」といった指示が必要です。逆に、「チェックしたか」といった観点を設定した場合は、特に言及がないからといって「やっていない」と断定されても困ります。このあたりの事実確認はしっかり行うよう、skillの設計を行いました。

また、指示をどう受け取るかもモデル次第なところがあるので、パフォーマンスを見つつどのモデルで振り返りを行うかも吟味すべきかもしれません。今のところはOpus 5.5で数回試していますが、見た範囲では「やってもいないことを書いている」といったケースは見当たりませんでした。

4. 共有できる出力

このskillでは、2種類の成果物を想定しています。一つは振り返り自体の記録です。記録を取ってさえいれば、AIに読ませて要点を抽出するのはさほど難しくありません。人事評価用のデータをまとめるのは後から成果物の提出タイミングに行えば済みます。

もう一つはADR(Architecture Decision Record)です。一言で説明するならば、「実装上の設計判断をその経緯や対立案も含めて説明したドキュメント」といったところでしょうか。

Claude Codeでのセッションではたびたび「この部分についてはどうしますか?」といったやり取りが行われます。そうしたいわゆる決めの問題は大小様々ですが、それを決める判断自体、ADRに残す価値があることも多いです。そこで、この振り返りskillはその経緯からADRを作成する機能も包含しています。

そうしてできたADRをプロジェクト内のリポジトリで共有することで、コードという現状値には残しにくい経緯を保管する効果も狙えます。

5. 使ってみた結果

9月末から1ヶ月ほど運用してみて、記録した作業は5件、あわせて書いたADRは10件になりました。

また、私自身の課題として、かねてからPRを出す前のセルフレビューが甘いと感じていました。そのため振り返り観点には「セルフレビューを行ったか」も記載していましたが、さっさとPRを上げるフローに沿って大体はレビューを挟まずじまいだった、ということが decision-log によってさらに露呈しました。

そこで私は別途セルフレビューskillを作り、それを通していないとPRを作れないようフックで止めることで、レビューという作業を私の意識に対する依存から解放しました。自己改善の材料を集めてくれるものとして、decision-log が問題点の発見に役立った事例といえそうです。

6. まとめ

セッション情報を集約して、あらかじめ作った観点での反省とADRの作成をしてくれるskill、decision-log の紹介でした。「結局呼び出しに振り返りタイミングが依存している」「compaction後、正確にやり取りを拾えない」といった課題が見えておりまだまだ改善の余地はありますが、いつも置き去りにしてしまう情報を拾い上げるのに上手く機能してくれているように思います。

ここで紹介した他にも、インシデントの対処記録や学習記録など、別の内容でも同じような型を活用できるのではないかと思います。「前やったこと、覚えてないし記録にもないんだよなぁ」といった悩みがあれば、ぜひ試してみてください。

シンシアについて

株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。

※ シンシアにおける働き方の様子はこちら
株式会社シンシアの働き方とストーリー - Wantedly

ともに技術力を高め合える仲間として、一緒に働きませんか?コンタクトをお待ちしています!

24
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
24
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?