続かない振り返りを、Claude Codeで解く。ラクスのKNDさんの5か月19回の記録を読む

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、ラクスのKNDさんが、個人の振り返りが続かない悩みを、毎週金曜の昼にClaude Codeが向こうから来る仕組みで解いた5か月の記録を読んで、解説します。

この記事は、私が保存したブックマークの1本です。取り上げた理由は、私の過去記事とつながるからです。毎週日曜に前の週との差を残す運用を書き、定期レポートは聞きに行く役を引き取らせる物にすると書き、手段が目的になった点検は作り込まないと書いています。KNDさんの仕組みは、この向きにそのまま重ねて読めます。

元の記事は、会社員の評価の話に見えます。でも、仕組みの考え方は立場を選びません。一人で仕事をしている人も、スタッフを抱える経営者も、自分の仕事に引き寄せて読めます。私はKNDさんの運用を自分でやった立場ではありません。元記事を読んで、自分の仕事に引き寄せて整理する、という読み方で進めます。

KNDさんの記事「仕事を進めるだけでは、仕事しか進まない。木こりのジレンマを Claude Code で解いた5ヶ月の記録」の「1. 「研ぐ時間がない」の正体は、やる気ではなくコスト」の節

そして4つ目。この3つを払わなくても、誰も困らない。相手がいないので、締切が永遠に来ない。

KNDさんが言うのは、振り返りには締切も相手もいないので、サボっても誰も困らない、ということです。ここが続かない根っこです。

ラクスのエンジニアブログ、RAKUS Developers Blogの記事は、木こりの寓話から始まります。朝、木を切っている木こりを旅人が見かけます。

夕方に戻ると、同じ木をまだ切っていて、ノコギリの刃はぼろぼろに欠けています。刃を研いだらどうですかと言われても、木を切るのに忙しいと返します。『7つの習慣』の「刃を研ぐ」の文脈でよく引かれる話です。

KNDさんは、初めて聞いたとき笑えなかったそうです。自分のことだったからです。

KNDさんの個人の振り返りは、書く週は書くのに、続きませんでした。状態はこうでした。Keep / Problem / Try（KPT）を埋めて満足し、翌週には先週何を書いたか覚えていない。

Tryが「もっと主体性を発揮する」のような抽象的な宣言になり、当然のように果たされない。忙しい週は後回しにする。

KPTは、Keepが続けること、Problemが問題、Tryが次に試すことを書く振り返りの型です。

KNDさんは、続かなかった理由を、かかっていたコストに並べ直しました。1つ目は準備コストです。さあやるぞと自分で始めないといけないので、忙しい週ほど、始める気力が先に尽きます。2つ目は品質コストです。

人に見せる前提でちゃんとした文章にしようとして、書くのが億劫になり、本音も丸まります。最後は記憶コストです。先週や先月に何を書いたかを自分で覚えていないといけません。

毎週ゼロから書くので、点が線になりません。

そして4つ目が、ここまでのコストを払わなくても、誰も困る人がいないことです。逆に言えば、この4つを仕組みで消せば、意志に頼らなくても回るはずだと、KNDさんは考えました。

打ち手は5つです。プッシュ型起動、雑に書いてAIが整える、記録を1ファイルに追記する、Tryに期日を付けて人に言う。

この4つが4つのコストを消すもので、残る1つのAIのいい人モードを外す指示は、運用してから分かった問題への手当てです。PDCAのCはチェック、Aは調整、Pは次のTryを決める、Dは実行です。

仕事の仕方のPDCAが、始まらない、Cで止まる、Dまで行かない。その理由を一つずつ潰しにいった記録です。

KNDさんの記事「仕事を進めるだけでは、仕事しか進まない。木こりのジレンマを Claude Code で解いた5ヶ月の記録」の「3. 準備ゼロ。金曜12時、向こうから振り返りがやってくる」の節

/k : コマンド実行後もウィンドウを閉じない。そのまま Claude Code との対話が始まる

KNDさんの仕組みは、決めた曜日の決めた時間に、パソコンが勝手にClaude Codeを起動する、というだけです。

使うのはWindowsのタスクスケジューラです。決めた日時にパソコンが自動でプログラムを起動するWindowsの機能のことです。プログラムはcmd.exe、引数は次の1行です。

「/k cd /d C:\work && claude %date%の週次コンピテンシー評価を振り返ります。Keep/Problem/Tryで一言ずつ書きます。

」短い1行ですが、KNDさんによると設計意図が4つ詰まっています。

1つ目の/kは、コマンドを実行した後もウィンドウを閉じない指定です。そのままClaude Codeとの対話が始まります。

2つ目の%date%は、当日の日付がプロンプトに入る仕掛けで、どの週の記録かが自動で決まります。

そして、プロンプトが一人称の宣言文になっていることです。「振り返ります」「書きます」と書いてあります。

金曜の自分にやるぞと期待しても裏切られるので、ウィンドウが開いた瞬間に、もう書き始めるしかない状態を作る、という考え方です。4つ目は、コマンド名を覚えなくていいことです。

プロンプトに「コンピテンシー評価」とあるだけで、その評価のスキルが自動で起動します。覚えることが無いので、運用が続きます。

時間を金曜の昼にしたのは、AIの回答待ちのような5〜10分の隙間で書けるからだそうです。ここは地味ですが大事です。

AI氣道『Grok Bot AI社員を何体も雇う前に、仕事ごとの持ち主を一人決める理由』より

「定期レポートは、あれはどうなったか、と私が聞きに行く役を引き取らせる物にします。回す回数は、中身を確かめてから増やします。」

定期の報告は、聞きに行く役を引き取らせる物にする。この向きを、私は『Grok Bot AI社員を何体も雇う前に、仕事ごとの持ち主を一人決める理由』で書いています。

KNDさんの「自分から始めず、向こうから来てもらう」と、私の「聞きに行く役を引き取らせる」は、同じ向きです。始める気力や、確認に行く手間を、人の意志から外して仕組みに渡す。その考え方が重なって見えました。

KNDさんの記事「仕事を進めるだけでは、仕事しか進まない。木こりのジレンマを Claude Code で解いた5ヶ月の記録」の「4. 雑でいい。整えるのは AI の仕事」の節

振り返りの精度は入力の正直さで決まるので、これは思った以上に効きました。

KNDさんが大事にしたのは、人に見せる文章にしないことです。ここで品質コストが消えます。

ウィンドウが開いたら、KNDさんは本当に雑に書きます。元記事の例はこうです。keepに、設計書の1稿を出した、AIに書かせて全部読んで直した、初動が楽。

problemに、レビュー対応で期限を聞かれてから出した、稼働入力が2週分たまっている。Tryが無くても気にしません。文の体裁も順番も整えません。

この雑でいいが、仕組みの中でかなり重要だったとKNDさんは書いています。書き始めるハードルが下がるだけでなく、本音が丸まらなくなるからです。

人に話す前提の振り返りには、これを言ったらどう見えるか、というフィルタが入ります。AI相手だとそれがゼロになります。

納得していなかったのに角が立つと思って折れた、のような体裁の悪い事実が、そのまま出せます。振り返りの精度は入力の正直さで決まる、と書かれています。

雑な入力を診断に変えるために、KNDさんはAI側に2つのものを持たせました。1つ目は評価の物差しです。ラクスには等級ごとに、この等級ならこういう行動が求められる、という定義があります。

そのMarkdown版を読ませています。Markdownは、記号で書く簡単な文章の形式です。物差しの正体は、別のチームのエンジニアが作ったコンピテンシー評価用のスキルです。

スキルは、AIに仕事の手順を覚えさせておく仕組みで、等級定義のmdと記載ガイドラインが同梱されています。

2つ目は出力フォーマットの固定です。毎回、KPT、各行動が今の等級の要件か一つ上の要件かを示す表、辛口の解剖メモ、判定可能な形に直したTry、来週の確認観点、の5つの要素で返ってきます。

物差しとフォーマットがあると、雑に書いたKeepに、それは今の等級で求められる行動か、一つ上の行動か、という軸が入ります。いい一週間でしたね、という感想ではなく、基準に照らした診断が返ってくる。

KNDさんはそう書いています。

一人で仕事をしている人なら、物差しは自分の仕事の目標の一覧でも成り立ちます。ここは私の読みです。

KNDさんの記事「仕事を進めるだけでは、仕事しか進まない。木こりのジレンマを Claude Code で解いた5ヶ月の記録」の「5-2. 週をまたいだパターン検出」の節

毎週ゼロから書く振り返りでは、何週も離れたこれらの行動が同じ視界に入ることがありません。記録が1ファイルに乗っているから、AI が点を線として読める。

この仕組みの本体は、記録を1ファイルに溜めることです。KNDさんも、たぶんここだと書いています。

結果は毎回、同じmdファイルに追記します。AIは毎週、そのファイルを頭から読んでから会話を始めます。効果は2段階ありました。1つ目はやり逃げ防止です。

会話は毎回、先週のTryはどうでしたか、から始まり、申告が鵜呑みにされません。

3回目の振り返りの実例です。Tryは「レビューの場で、質問や提案を1つ出す」でした。KNDさんは、今週は機会がありませんでしたと答えました。

AIは、今週のKeepに「仕様書レビューで『このケースは除外する』と言われて、『結合テストは網羅でやるべきでは』と返した」とありますね、これはまさに提案を出したことになりませんか、と返しました。

KNDさんは、言われてみればそうですね、と認めます。この週から、Keepを書いたら先週のTryと照合する手順が加わりました。

2つ目はKNDさんが運用して初めて分かった、週をまたいだパターン検出です。テスト作業を効率化する小さなツールを自作して、チームに共有しました。

次のTryは、1人に使ってもらってフィードバックをもらうこと。ところがこの依頼が5週間出せませんでした。ツールを磨く、共有範囲を広げる、は毎週できているのに、依頼だけが未達で積まれます。

4週目のAIの診断は、同じ週の2つの行動の対比でした。誰の担当でもない設定の修正依頼は、自分から拾ってその日に直せた。自作ツールの使用依頼は、4週間止まっている。

5週目には、スケジュールの問題ではなく回避だ、と言い切られました。6週目に依頼を出すと、翌日には使ってもらえ、フィードバックももらえました。

AIはさらに、同じ週の新人の日報へのコメントを並べました。すぐ書けています。相手に負荷のない贈り物はすぐ出せて、相手に手間を負わせる依頼だけが止まる。

避けているのは対人全般ではなく、特定の1人に負荷をかける依頼だけだ、と絞り込みました。

AI氣道『Claude Codeスキルの使い方、むっちょさんが毎日使う朝の1画面から月1の報告までの10個』より

「10月11日に、GitHubの週間ランキングTOP10の記事を出しました。以後、毎週日曜に、AIがランキングを集めて記事にする仕組みを回しています。指示に入っているのは、前の週の記事と見比べて、続けて入った物には先週も何位と書ける材料を残す、という一文。」

毎週、前の週との差を残す。この向きを、私は『Claude Codeスキルの使い方、むっちょさんが毎日使う朝の1画面から月1の報告までの10個』で書いています。

KNDさんの「記録を1ファイルに残し、前の週と突き合わせる」と、私の「毎週日曜に前の週との差を残す」は、同じ向きです。前の週が見える状態を作っておくと、点が線になります。

KNDさんの記事「仕事を進めるだけでは、仕事しか進まない。木こりのジレンマを Claude Code で解いた5ヶ月の記録」の「6-3. AI も間違える。事実を保証するのは自分」の節

過大は削り、過小は主張する。AI は物差しにも記憶にもなるけれど、事実の最終保証者にはなれません。

KNDさんの仕組みで、辛口は前提です。あったら嬉しいオプションではない、と書かれています。

そのまま使うと、AIは何を書いても「素晴らしい取り組みですね」から入ります。気持ちよくはなるけれど、何も変わりません。

そこでKNDさんは、肯定から入らない、避けている盲点を指摘する、自分に嘘をついていたら教える、という趣旨の指示を入れました。一時期話題になった、AIの良い人フィルターを外すプロンプトと同じ発想です。

10月のある金曜、辛口の指示が読み込まれないまま分析が始まり、返ってきたのは長いだけで役に立たない文章でした。起動し直して、やっといつもの診断が返ったそうです。

叱られるだけかと思ったら、一番多く言われたのは、あなたはこれをKeepに書いていません、でした。8月の回です。文書の期限を優先して振り返りを1回飛ばし、次の回で2週分をまとめました。

書いたKeepの数は3件。

AIはPR（プルリクエスト、コードの変更をチームに見てもらう依頼）の一覧を開いて、設計文書の初版が8月の第1週にマージされている、自分で決めた期限の当日です、Keepの候補にも入っていないのはなぜですか、と返しました。

追加の修正が揉めて説明の場も延期になった直近の悪い知らせが、終わっている成果を塗りつぶしていたのです。

5か月続けて、この当たり前フィルタには変種があると分かりました。一つ上の等級の行動を、下の等級の言葉に翻訳して書く。行動したのに今週は機会がなかったと申告する。

やっていることをやっていないと思い込む（期日はあまり言ってこなかった気がすると書いた週に数えたら、3週で8回言っていた）。

仕組みや段取りの工夫はKeepに上がるのに、上司の提案に別の案を論理で返して合意を得た、という対人の攻めは上がらない。共通するのは、嘘も謙遜も無いことです。本気で書くほどのことではないと思っています。

AIも間違えます。AIはMCP（AIがSlackなど外のサービスを読むための接続の仕組み）でSlackの送信履歴も開きますが、レビュー依頼の順番をわざと遅らせていたことを無駄な待ちと批判しました。

実際は、以前の1on1（上司との1対1の面談）でもらった助言に沿った順番で、伝えるとAIは撤回しました。

逆に、AI自身が書いた未レビューのドラフトをKNDさんの成果だと思い込み、今期最強の成果物と数えたので、突き返しています。

過大は削り、過小は主張する。AIは物差しにも記憶にもなるけれど、事実の最終保証者にはなれません。KNDさんはそう書いています。私はここが、一人で仕事をする人にも一番効く線引きだと読みました。

KNDさんの記事「仕事を進めるだけでは、仕事しか進まない。木こりのジレンマを Claude Code で解いた5ヶ月の記録」の「8. 足りなかったのは相手ではなく、期日だった」の節

結果は、まだ途中です。9月半ばからの3週で、外に向けて言った期日は8回。守れたのは3回でした。言えば守れる、というわけではありません。

KNDさんがたどり着いたのは、足りなかったのは相手ではなく期日だった、という整理です。

きっかけはTryの書き方でした。5月のある週、レビュー対応の予定を自分から出さず、上司にいつ対応？と聞かれました。その反省で書いたTryが「全タスクで主体性を発揮する」です。

悪くない宣言ですが、金曜に達成したかどうかを判定できません。判定できないものは、未達にもならないので、何も変わりません。AIに書き直させると、こうなります。

次にレビュー指摘を受けたら、聞かれる前に24時間以内に、対応範囲・完了予定日・次のレビュー出し先を自分から上司に提示する。誰に、何を、いつまでに。未達なら未達と記録されます。

未達の記録は失敗ログではなく診断データになる、とKNDさんは書いています。

9月の記録に、KNDさんは、人にやることを出していくのがいい、人との約束は破れないから、と書いていました。AIの返事は、半分正しい、でした。

8月の終わりにレビューの指摘を直して「ご確認お願いします」と返した件は、相手が翌日コメントをくれたのに、そのあと8営業日返していません。一方で「明日出します」と相手に言った文書は、翌日に出せています。

違いは期日です。効いていたのは、人に言ったことではなく、いつまでにを自分の口で言ったことでした。

そこで期日を2か所で口に出すことにしました。1つはClaudeです。返信や資料の下書きができたら、いつ出すか、何の後に出すかを言います。言えないなら、後回しにしているだけです。

人に言うよりずっとラフに言えるので、期日を口にする練習になります。もう1つは上司です。10月のある金曜、振り返りの日の午後の1on1で、その日に決めたTryを口に出しました。

レビューの指摘をもらったら、いつまでに直して返すかを先に伝える。この回からTryは1つに絞って、1on1で口に出しています。

結果はまだ途中です。9月半ばからの3週で、外に向けて言った期日は8回。守れたのは3回でした。言えば守れる、というわけではありません。それでも、言ってあれば、崩れそうになった時点で自分から調整を切り出せます。

KNDさんの役割分担はこうです。掘るのはAIと。忖度がなく、体裁の悪い事実をそのまま出せる相手だからです。期日は人に言う。AIは、そのための練習相手です。

KNDさんの記事「仕事を進めるだけでは、仕事しか進まない。木こりのジレンマを Claude Code で解いた5ヶ月の記録」の「おわりに」の節

仕事の PDCA は、仕事をしていれば勝手に回ります。仕事の仕方の PDCA は、仕組みがないと回りません。

KNDさんの結論は、仕事の仕事の仕方のPDCAは、仕組みがないと回らない、ということでした。

まず、続きました。5か月で19回です。皆勤ではなく、体調や繁忙や連休で飛ばした週もあります。ただ、途切れてそのまま消滅は起きていません。次に、行動が変わりました。

4月の記録には、チームの運用で気になる点があったのに、まあいいかで動かなかったとあります。

6月には、結合テストで検証環境の取り合いが起きているのを見て、QAに調整用の場所を作りませんかと自分から持ちかけ、スプレッドシートでの管理に落ち着きました。

振り返りが先か行動が先かは分離できないが、記録の上では別人だそうです。さらに、仕事中に何かつまずくと、これは金曜の振り返りで書こう、とその場で考えるようになりました。

続けるために足したルールは4つです。翌営業日ルールは、金曜に急ぎの仕事があれば無理せず翌営業日にやる決まりで、ただし月曜に回した週の記録には処方が1週間分抜けるとあり、基本は金曜です。

5分の縮退運転は、それも無理な週は今週作った物と出した物の列挙だけを5分でやることで、第一の価値は内省でなく捕捉だと書かれています。加えて、列挙を記憶ベースでなく成果物ベースにすること。

PR一覧や案件フォルダの更新ファイルから機械的に並べます。もう1つは、人に出した物をSlackの送信履歴から引くこと。文面を作っただけで送っていない物は未送と書きます。

注意点も書かれています。評価そのものをAIにやらせてはいません。自己評価を書くための壁打ち相手で、評価するのは人間です。評価基準や業務の話を扱うので、使うAIツールが社内のルール上問題ないかも確認しています。

AI氣道『Claude Codeスキルの使い方、むっちょさんが毎日使う朝の1画面から月1の報告までの10個』の別の一節より

「ただ、記録では、その点検は obsidian-skills を使うためにひねり出した作業で、手段が目的になっていました。そのため obsidian-skills は、ふだんの作業の中で使う裏方の道具として扱い、これ以上は作り込まないことになりました。」

手段が目的になった作業は、作り込まない。この向きを、私は『Claude Codeスキルの使い方、むっちょさんが毎日使う朝の1画面から月1の報告までの10個』で書いています。

KNDさんの「研ぐのは、木を切るため」と、私の「手段が目的になった点検は作り込まない」は、同じ向きです。振り返りも、振り返るための振り返りになったら、刃を研ぐ手が止まります。

最後に、あなたの仕事に引き寄せる一歩です。

KNDさんは、フル装備でなくていい、タスクスケジューラの1行と、記録を1ファイルに溜めることと、いい人モードを外す指示の組み合わせだけでも、AIの返答は感想から診断に変わる、と書いています。

ChatGPTやClaudeに、まずこう頼んでみるのはどうでしょう。「私の今週の振り返りを手伝って。次の前提を使って。

①最初に、先週のTryはどうだったかを聞いて、私が達成していないと言ったら、今週の記録と突き合わせて確かめて②振り返りの結果は、同じファイルに追記して、毎回その頭から読んで③褒めずに、私が書いていない成果と、避けている行動を指摘して④Tryは、誰に何をいつまでにやるかが分かる形に直して。

記録のファイルは、この依頼と一緒に渡します。」渡し方は、記録のファイルを添付するか、中身をそのまま貼り付けるかのどちらかです。返ってきた結果は、自分でそのファイルの末尾に貼って保存します。

翌週は、同じファイルを渡して同じ依頼から始めます。ただしAIの出力は信じ切らず、事実の確認は自分でします。KNDさんの言う通り、事実の最終保証者は自分だからです。

ラクスのKNDさんは、個人の振り返りが続かない理由を、やる気ではなく、準備・品質・記憶のコストと、締切が来ないことに分けました。そのうえで、毎週金曜の昼にClaude Codeが向こうから来る仕組みを作り、5か月で19回続けました。

仕組みの考え方は、こうです。自分から始めず、向こうから来てもらう。雑に書き、整えるのはAIに任せて、物差しと出力の形をAIに持たせる。記録を1ファイルに溜めて、AIに前の週を読ませる。会社員の評価の話に見えますが、立場に関係なく使えます。

AIのいい人モードを外すと、一番多く返ってきたのは、あなたはこれを書いていません、でした。自分では書くほどのことと思わない成果が、振り返りで最初に出てこないと、消えてしまいます。一方でAIも間違えるので、事実の最終保証は自分です。

足りなかったのは相手でなく期日でした。いつまでにを自分の口で言う。Claudeに言う練習をして、上司に言う。3週で8回言って3回守れた、という途中経過まで書かれているのが、この記事の誠実な所です。悩みを気合で解くのでなく、期日で解く。ここが一番の学びでした。

私の過去記事とも、同じ向きでつながりました。毎週前の週との差を残す。定期レポートは聞きに行く役を引き取らせる。手段が目的になった点検は作り込まない。まず記録のファイルを1つ決めるところから、始めてみてください。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！