月末に Claude の Settings を開いたら、Reflect というふりかえりのページが増えていました。先月いちばん多く触れた話題、いちばん活発だった曜日、作業が集中した時間帯が、静かに並んでいます。個人開発を一人で続けていると、自分の働き方を外から眺める機会はほとんどありません。Reflect の画面は、その空白をそっと埋めてくれるものでした。
Reflect は Free / Pro / Max のいずれでも Settings の中にあり、現在は beta 提供です。特別な設定は要らず、月に一度、前の一ヶ月の対話を集計して、傾向を短い観察として返してくれます。ここでは、その数字を反省ではなく「次の一ヶ月をどう組み立てるか」の材料として読む方法を、私自身の使い方に沿って整理します。
Reflect が見せてくれるもの
Settings の中の Reflect を開くと、主に次の四つが並びます。
| 項目 | 示されること |
|---|---|
| よく触れた話題 | 先月、対話の中心にあったテーマの上位 |
| 最も活発だった日 | やり取りの件数が最も多かった曜日・日付 |
| ピークの時間帯 | 作業が集中していた時刻の帯 |
| 働き方の観察 | 上記から導かれる、短い言葉での傾向のまとめ |
大切なのは、これらが評価でも採点でもないという点です。あくまで「先月のあなたはこう動いていました」という観察であり、良し悪しを付けてはきません。だからこそ、こちらの解釈しだいで意味が変わります。同じ「深夜にピーク」という一行が、ある人には夜型の集中の証になり、別の人には生活の乱れの警告になります。数字そのものより、それをどう受け止めるかのほうが大切です。
数字を反省材料でなく設計材料として読む
たとえばピークの時間帯が深夜に寄っていたとします。ここで「夜更かししすぎた」と受け取ると、ただの自己批判で終わってしまいます。私はそうではなく、「深夜に集中が乗るなら、翌月は重い実装をあえて夜の枠に置き、昼は軽いレビューに回す」という組み替えの入口として読みます。自分の性質に逆らうより、性質に合わせて時間割を引き直すほうが、一人の開発では長続きします。
よく触れた話題も同じです。先月 API まわりに関心が偏っていたなら、それは次の一ヶ月で一本の深い記事や小さなツールに束ねられる兆しかもしれません。Reflect は方向を指し示してはくれませんが、重心の在りかは教えてくれます。私はこの重心を、翌月の学習テーマを一つに絞る根拠として使っています。あれこれ手を広げがちな月ほど、この一行に助けられます。
Reflect と自分の作業ログを重ねる
Reflect の観察は、自分でつけている記録と重ねると精度が上がります。私は個人開発の作業を簡単な JSON で残していて、リリースやデバッグの時刻を後から振り返れるようにしています。次のスクリプトは、そのログから時間帯ごとの件数を出し、Reflect のピーク時間と突き合わせるためのものです。
// devlog.json: [{ "ts": "2026-07-03T23:40", "task": "release" }, ...]
import { readFileSync } from "node:fs";
const logs = JSON.parse(readFileSync("devlog.json", "utf8"));
const byHour = new Array(24).fill(0);
for (const { ts } of logs) {
// ローカル時刻の「時」だけを取り出して集計する
const hour = new Date(ts).getHours();
byHour[hour] += 1;
}
byHour.forEach((count, hour) => {
if (count === 0) return;
const bar = "#".repeat(count);
console.log(`${String(hour).padStart(2, "0")}:00 ${bar} ${count}`);
});出力は簡素なヒストグラムです。Reflect が「夜に活発」と観察していても、自分の作業ログでは午前に山があったなら、対話は夜・実装は朝という二層の生活をしている、といった具合に、一枚の数字だけでは見えない構造が浮かびます。Claude との対話量と、実際に手を動かした時間は、必ずしも一致しません。両方を並べて初めて、翌月の時間割を現実に合わせて引けます。
翌月の時間割に落とす
観察を眺めて終わりにしないために、私は月初に十五分だけ時間を取り、Reflect の四項目を一枚のメモに書き写して、それぞれに「翌月どうするか」を一行ずつ足すようにしています。よく触れた話題には次の深掘りテーマを、ピーク時間には重い作業を置く枠を、活発だった曜日にはリリースを避ける休息日を、という具合です。App Store や Google Play への申請を控えた月は、締め切りの数日前を意図的に軽い作業だけにして、審査対応の余白を残します。こうして観察が一行の予定に変わった瞬間に、Reflect はただの画面から、翌月の設計図に変わります。
過信しないための線引き
Reflect は beta であり、示されるのは相関であって因果ではありません。「活発だった日」が必ずしも「成果が出た日」とは限らず、対話が多い日ほど詰まっていた、という月もあります。私は数字をそのまま信じるのではなく、自分の記憶や作業ログと照らして、食い違う部分にこそ注目するようにしています。食い違いは、思い込みと実際の行動がずれている場所を静かに教えてくれるからです。
月次のふりかえりは、うまく使えば翌月の設計図になり、雑に使えばただの反省会になります。私自身、最初の一ヶ月は数字を眺めて終わっていました。作業ログと重ね始めてから、ようやく次の行動に結びつくようになりました。もし同じように一人で開発を続けている方がいれば、まずは自分の記録と一度だけ突き合わせてみることをおすすめします。読んでくださってありがとうございました。