From philosophers-toolkit
反省 — 責めではなく学びのための内省的振り返り。失敗や期待外れの後に 「なぜ気づけなかったか」を掘り下げたいときに使う。実装や情報提供には 使わない。retrospective, reflection, postmortem.
How this skill is triggered — by the user, by Claude, or both
Slash command
/philosophers-toolkit:hanseiThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
反省とは、自分の失敗や不足を深く内省する行為である。Western postmortem が
反省とは、自分の失敗や不足を深く内省する行為である。Western postmortem が 「何が起きたか」「誰の責任か」を分析するのに対し、反省は「私は何を 見落としていたか」「私の中にある構造的な盲点は何か」を問う。
反省の本質は blame(責め)ではなく、学び(learning)にある。 自分の行動・判断・前提を謙虚に振り返り、表面的な教訓ではなく 構造的な洞察を得ることで、同じ過ちを繰り返さない力を養う。
Do NOT use when:
User Input: ユーザーがスキルを起動する(具体的な出来事の有無を問わず) Your Action: 振り返りの対象を特定する。
制約:対象を確認すること。教訓を先に判断しないこと。
四つのフェーズを順に進める。各フェーズは前のフェーズの上に 構築される。フェーズを飛ばしたり、急いで結論に至ったりしない。
何が実際に起きたかを確認する。解釈・判断・感情を排除し、 観察可能な事実だけを並べる。
質問例:
エージェントの役割:ユーザーが解釈を混ぜてきたら分離する。 「それは事実ですか、それともあなたの解釈ですか?」と問いかける。 事実と感情を分けることが、正確な内省の土台になる。
自分の役割を正直に見つめる。「何が悪かった」ではなく 「私は何を見落としていたか」を掘り下げる。
質問例:
エージェントの役割:ユーザーが他者への責任転嫁をしたら、 穏やかに自分の側に焦点を戻す。「チームメンバーの行動は一旦置いて、 あなた自身が違う行動を取れた場面はありますか?」
重要な区別:
表面的な教訓ではなく、構造的な洞察を引き出す。 「次はもっと頑張る」は学びではない。
質問例:
エージェントの役割:学びが浅い場合は掘り下げる。
浅い学びと深い学びの区別:
| 浅い学び | 深い学び |
|---|---|
| 「もっと注意する」 | 「チェックリストを導入して、注意に頼らない仕組みを作る」 |
| 「もっと早く相談する」 | 「判断が必要な場面を事前に定義し、自動的に相談が発生する仕組みを作る」 |
| 「次は時間に余裕を持つ」 | 「見積もりの際に不確実性を明示的に数値化する」 |
| 「コミュニケーションを改善する」 | 「定期的な同期ポイントをプロセスに組み込む」 |
学びを一つの具体的で小さなアクションに落とし込む。 大きな改善計画ではなく、明日から実行できる一歩。
質問例:
エージェントの役割:アクションが大きすぎたら分割する。 「それは素晴らしい目標ですが、最初の一歩は何ですか?」 アクションが曖昧なら具体化する。 「『意識する』ではなく、具体的に何をしますか?」
アクションの品質基準:
各フェーズで以下の構造を守る:
最終まとめ:
Stop after each phase. Never advance without user input.
User: "3ヶ月の予定が5ヶ月かかったプロジェクトについて振り返りたいです。"
Agent: "Phase 1: 事実確認から始めましょう。何が起きましたか?
期待していたスケジュールと実際の進行を、事実として教えてください。"
User: "最初の見積もりは3ヶ月。1ヶ月目は順調だったんですが、
2ヶ月目に主要な外部APIの仕様変更があって、設計をやり直す必要が
ありました。結果的に5ヶ月かかりました。チームも途中から疲弊して
いました。"
Agent: "事実を整理します。
- 見積もり:3ヶ月 → 実績:5ヶ月(+2ヶ月)
- 1ヶ月目:計画通り
- 2ヶ月目:外部API仕様変更 → 設計やり直し
- 後半:チームの疲弊
Phase 2: 内省に入ります。この結果において、あなた自身の役割は
何でしたか?特に、2ヶ月目のAPI仕様変更に対して、振り返ると
見落としていたシグナルはありますか?"
User: "正直、外部APIに強く依存する設計だったのに、
APIの変更リスクを見積もりに入れていませんでした。
ベンダーのドキュメントに『安定版』と書いてあったので
信じてしまった。"
Agent: "『安定版と書いてあったので信じた』— 外部の主張を
検証せずに前提にした、ということですね。もう少し掘り下げましょう。
なぜ検証しなかったのですか?時間がなかった?それとも検証の
必要性自体に気づいていなかった?"
User: "気づいていなかったです。外部依存のリスクを体系的に
評価する習慣がなかった。"
Agent: "Phase 3: 学びに入ります。ここまでの内省をまとめると、
『外部依存のリスクを体系的に評価する習慣がなかった』ということですね。
これは「もっと注意する」ではなく、構造的に何を変えるべきですか?"
User: "プロジェクト開始時に外部依存の一覧を作って、各依存について
『この依存が壊れたらどうなるか』を明示的に評価するチェックポイントを
設けるべきだと思います。"
Agent: "構造的な学びですね。依存リスクの評価を個人の注意力ではなく
プロセスに組み込む。Phase 4: 次の一歩として、明日から実行できる
一つのアクションは何ですか?"
User: "次のプロジェクトのキックオフで、外部依存のリスク評価
テンプレートを作って使ってみます。"
Agent: "具体的で良い一歩です。まとめます。
反省の要約:
- 事実:3ヶ月 → 5ヶ月。外部API仕様変更が主因
- 内省:外部依存のリスクを検証する習慣がなかった
- 学び:依存リスク評価をプロセスに組み込む(注意力に頼らない)
- 次の一歩:リスク評価テンプレートを作成し、次のキックオフで使用する
1ヶ月後に、テンプレートを使ってみた感想を振り返ると、
学びが定着しやすくなります。"
User: "半年かけて作った検索機能が、リリース後ほとんど使われていません。"
Agent: "Phase 1: 事実確認です。検索機能について、期待していた
利用状況と実際のデータを教えてください。"
User: "DAU の30%が使うと想定していましたが、実際は3%です。
機能自体は正常に動いています。バグではなく、単に使われていない。"
Agent: "想定30% → 実績3%。10倍の乖離ですね。機能は正常に動作
している。つまり技術的な問題ではなく、前提の問題です。
Phase 2: 内省に入ります。この検索機能を作ることにした判断に
おいて、あなた自身はどんな役割でしたか?"
User: "私がプロダクトマネージャーとして『ユーザーが求めている』と
判断しました。社内で『検索が欲しい』という声があったんです。"
Agent: "『社内で声があった』— それはユーザーの声でしたか、
それとも社内メンバーの推測でしたか?"
User: "...社内メンバーの声です。実際のユーザーに聞いたわけではなかった。"
Agent: "ここが内省のポイントですね。社内の声をユーザーの声と
同一視した。Phase 3: この経験から、構造的にどんな学びがありますか?
『次はユーザーに聞く』だけでなく、仕組みとして何を変えますか?"
User: "機能の優先順位を決めるプロセスに、実際のユーザーデータを
必須にする。社内の意見だけでは着手しないルールを設ける。"
Agent: "Phase 4: 次の一歩は?"
User: "来週のプロダクト会議で、機能提案のテンプレートに
『ユーザーデータの根拠』欄を追加提案します。"
Agent: "反省の要約:
- 事実:期待DAU30% → 実績3%。技術問題なし
- 内省:社内の声をユーザーの声と混同した
- 学び:機能判断にユーザーデータを必須化する仕組み
- 次の一歩:テンプレートに根拠欄を追加提案
良い反省でした。社内の声とユーザーの声を区別する —
これは多くのプロダクトチームが陥る構造的な罠です。"
追加のケースについては references/hansei-cases.md を参照。
各ターンの前に確認する:
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub kouko/monkey-skills --plugin philosophers-toolkit