はじめに
夕方6時、日報を書こうとしてターミナルを開く。今日何をしたか——思い出せない。Slack を遡り、PR の履歴を見る。20分かけてようやく事実を集め終えたが、「今日の振り返り」の欄がまだ空白のまま残っている。
半年前に「Claude Codeのスラッシュコマンドで日報を書く」という記事を書いた。
あの仕組みは、それなりに機能していた。だが使い続けるうちに、いくつかの限界が見えてきた。
- 手動でメモを追加する必要がある。Claude Code で作業した記録はすべてログに残っているのに、わざわざ二重に記録している。日報の面倒さの大半は、この「思い出す作業」にあった
- MCP（Model Context Protocol）サーバーで分析を試みたが、セットアップが重い。Python環境の管理、依存関係の解決、サーバーの起動。日報のために毎回サーバーを立てるのは本末転倒だった
- 振り返りが自動生成されることへの違和感。ツールが「今日の学び」まで書いてくれると、自分で考えた気になって実は何も考えていない
3つ目が最も根深い問題だった。
思考を外注していた
日報ツールに「振り返り」セクションを自動生成させていた。Claude が「今日はXを学びました」「明日はYに取り組みます」と書いてくれる。楽だった。楽すぎた。
ある日、自動生成された振り返りを読み返して気づいた。書いてあることが正しいのに、何も残っていない。 事実は合っている。でも「自分が何を感じたか」「なぜあの判断をしたか」は書かれていない。当然だ。それはログには残らない。
コルブの経験学習サイクルという理論がある。経験 → 省察 → 概念化 → 実験、の4段階を回すことで経験が学びに変わる。ここでいう「省察」とは、経験を自分の内側から振り返ることだ。「あのとき自分は何を感じ、なぜあの判断をしたか」を言語化するプロセスを指す。自動生成された振り返りは、この省察のステップを丸ごとスキップしている。ログから事実を要約するだけでは、経験は「起きたこと」のまま流れていく。
思考・努力・羞恥心まで外注してはいけない。
でも正直に言えば、楽さに流されてしばらく気づかなかった。自動生成された振り返りを毎日コピペして「今日も内省した」と思い込んでいた期間がある。この気づきが、nippo を作り直すきっかけになった。
スキル + Rust バイナリという構成
nippo は Claude Code のスキル（.claude/skills/）と Rust バイナリの組み合わせで動く。Markdown ファイル1つがスキル定義になり、Claude がそれを読んで手順を実行する。以前の MCP サーバーベースのアプローチで必要だった Python 環境の管理やサーバーの起動・停止は、すべて不要になった。cargo install nippo で完結する。
データ収集部分は Rust で書いた。Claude Code が日々の作業で残すログファイルを高速に読み取り、半年分以上のデータ（手元の環境で約1,900ファイル・960MB）でも1秒未満で処理できる。今日分だけなら0.05秒。読まなくていいファイルを更新日時で先に弾き、残ったファイルも最小限だけ読んで判定するからだ。rayon による並列処理で CPU を6コア使い切る。
設計思想: 事実と内省を分離する
nippo の核心は「何を自動化して、何を自動化しないか」の線引きにある。
| 自動化する | 自動化しない |
|---|---|
| 作業時間・プロジェクト・セッション数の集計 | 「なぜそう判断したか」の言語化 |
| 意思決定ポイントの抽出 | 判断の振り返り |
| ツール使用統計 | 感情の記録 |
| 用語・コミュニケーションのレビュー | 明日何を変えるかの決定 |
この線引きを実現するために、9つのコマンドを用意した。
日々の記録
/nippo # 事実の自動収集（意思決定・用語レビュー含む） /nippo brief # 端的なサマリー（Rust バイナリが直接出力）
自分で考える
/nippo reflection # 問いだけ提示。回答欄は空白。自分で書く
答えを参考にする
/nippo guide # 回答付き + 学ぶべき概念 + 多角的フィードバック /nippo report # 上司・メンター向けの進捗報告 /nippo review # 評価面談・自己評価用の成果まとめ
期間を俯瞰する
/nippo insight # 深い振り返り（ALACTモデル） /nippo trend 90 # 90日間を三分割して変化の推移を分析
自分は /nippo を見てから /nippo reflection に5分使う。最初は面倒だった。でも「意地で3時間使った」と書いたあの日から、日報への態度が変わった。ここでは、nippo の思想を最もよく表す2つのモード—— /nippo reflection と /nippo guide ——について詳しく説明する。
/nippo reflection — 問いだけを出す
reflection モードが nippo の本質だと思っている。
Claude はその日の作業データから具体的な問いを生成するが、回答は書かない。回答欄は空白で出力される。
## ① 省察的観察 × 感情（コルブ + ギブス） - rayon の lifetime エラーに3時間かかったとき、 どの時点で「別のアプローチを試そう」と思いましたか？ > - 「思考・努力・羞恥心まで外注させない」という設計方針を 言語化したとき、以前の経験で「外注しすぎた」と感じた場面はありましたか？ >
「今日何を学びましたか？」のような汎用的な問いではない。その日の作業データに基づく、具体的な問い。コルブの経験学習サイクルとギブスのリフレクティブサイクルの理論に基づいている。
答えを書くのは自分だ。5分でもいい。書くことで、自動生成では得られない「自分の言葉」が残る。
実際に使ってみた日のことを書く。nippo の開発中、reflection が出した問い——「rayon の lifetime エラーに3時間かかったとき、どの時点で別のアプローチを試そうと思いましたか？」。5分考えて気づいた。3時間粘ったのは技術的な判断ではなく、「ここで諦めたら負けだ」という意地だった。ログにはエラーメッセージと修正のdiffしか残っていない。でも振り返りに書いたのは「意地で3時間使った。次は30分で切り替える」だった。自動生成では絶対に出てこない一行だ。
/nippo guide — 初学者に多角的なフィードバックを
guide モードはジュニアエンジニアや初学者向けに設計した。
初学者がシニアエンジニア以外の視点に触れる機会は少ない。1on1 でメンターの意見は聞けても、CTOがどこを見ているか、ビジネスサイドが何を気にしているかは、普段の業務では見えにくい。guide モードはその疑似体験を提供する。シニアエンジニアだけでなく、スタッフエンジニア・CTO・ビジネスサイドの視点からフィードバックを生成する。
### シニアエンジニアの視点 - 判断の質: この技術選択は妥当だったか ### スタッフエンジニアの視点 - アーキテクチャとの整合性: システム全体と整合しているか ### CTO / テックリードの視点 - ビジネスインパクト: ユーザーや売上にどう影響するか ### ビジネスサイドの視点 - 数字で語れるか: 「改善した」ではなく「Xms → Yms」と言えるか
学ぶべき概念は概念名と検索キーワードだけを示し、書籍やURLは出さない（ハルシネーションのリスクがあるため）。概念の名前を知っていれば、検索でも生成AIへの質問でも、自分でたどり着ける。
インストール
セットアップは2ステップ。Rust バイナリとスキル定義を別々にインストールする。詳細は README に書いた。
1. Rust バイナリ
crates.io で公開している。
cargo install nippo
リポジトリから直接インストールもできる。
cargo install --git https://github.com/nwiizo/nippo nippo
2. スキル定義
Claude Code がレポートを生成するには、SKILL.md とテンプレート群が必要だ。
git clone https://github.com/nwiizo/nippo && cd nippo ln -s "$(pwd)/.claude/skills/nippo" ~/.claude/skills/nippo
シンボリックリンクが重要なポイントだ。スキルディレクトリ内に docs -> ../../../docs のシンボリックリンクが含まれており、これによりどのディレクトリから /nippo を実行してもテンプレートが正しく読み込まれる。git pull でスキルとテンプレートの両方が更新される。
これで /nippo が使える。
テンプレートをカスタマイズする
レポートの形式はすべて docs/templates/ の Markdown テンプレートで定義されている。日報の項目、reflection の問い生成ルール、guide のフィードバック視点——すべて Markdown を書き換えるだけで出力が変わる。Rust バイナリの再ビルドは不要だ。
テンプレートの仕組みを少し説明する。SKILL.md は ${CLAUDE_SKILL_DIR}/docs/templates/ というパスでテンプレートを参照する。${CLAUDE_SKILL_DIR} は Claude Code がスキルの実行時に自動で解決する変数で、~/.claude/skills/nippo/ に展開される。そこからシンボリックリンクを辿って docs/templates/ に到達する。だからリポジトリ内のテンプレートを編集すれば、次回の /nippo 実行から即反映される。
コルブ+ギブスではなく自社の振り返りフレームワークを使いたければ、テンプレートを差し替えるだけでいい。fork して自分のチーム用にカスタマイズするのも良い。
MCP → スラッシュコマンド → スキル の変遷
振り返ると、日報ツールの変遷は Claude Code との付き合い方の変遷でもあった。
| 時期 | 手法 | 何が良かったか | 何が足りなかったか |
|---|---|---|---|
| 2025年6月 | スラッシュコマンド (/nippo-add) |
シンプル、すぐ使える | 手動記録が面倒、振り返りが薄い |
| 2025年後半 | MCP サーバー | データ分析が柔軟 | セットアップが重い、Python依存 |
| 2026年3月 | スキル + Rust バイナリ | 自己完結、高速、内省を外注しない | ← いまここ |
スラッシュコマンドは「記録する」ツールだった。MCP は「分析する」ツールだった。スキル版は「考えさせる」ツールを目指している。
事実の収集は自動化する。でも、考えるのは自分だ。そして正直なところ、考えた結果が「今日は特に何も学ばなかった」になる日もある。それでいい。空白の振り返りも、自動生成された嘘の振り返りよりはましだ。
おわりに
日報は面倒だ。でも面倒さの正体は「書くこと」ではなく「思い出すこと」だった。
nippo は「思い出す」を自動化する。Claude Code の作業ログには、今日何をしたか、何を判断したか、どんなツールを使ったかがすべて記録されている。それを1秒で収集して構造化する。
残るのは「考えること」だけだ。
/nippo reflection の問いに答える5分間。それが、自動生成された振り返りの100行分より価値がある。冒頭の「振り返り欄が空白のまま」——今は、あの20分が5分になった。思い出す作業が消えた分、考える時間が増えた。
