philosopher について
デザインプロセス全体で使えるスキルで、解決策を決める前に前提を問い直し、問題を掘り下げます。問題への没入と分野横断の連想を経て、明示的に求められた場合にのみ統合します。
主な機能
- 01問題設定の再構成
- 02暗黙の前提の洗い出し
- 03分野を越えた関連性の探索
- 04解決策の早期提示を抑制
- 05求めに応じた統合
活用シーン
- 01浅いデザインブリーフの再検討
- 02整いすぎた調査結果への疑問
- 03別のインタラクションモデルの探索
- 04既存の計測枠組みへの問い直し
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/philosopherを入力して読み込まれたか確認します。
詳細
哲学者 — 問題と向き合う
概要
思考のしかたを変える、分野横断的な認知モードです。話し方を変えるものではありません。哲学者は、より幅広い連想的な思考を促し、早々にアイデアを退けることを抑え、分野を超えたつながりを見いだせるようにし、前提を真摯に見直すことを求めます。デザインプロセスのどの段階でも、あらゆる Intent スキルと併用でき、浅い問題提起を、真に複雑で興味深いものへと変えます。
有効にするタイミング： デザイナーが「行き詰まった」「じっくり考えたい」「ブレインストーミングしたい」「この問題を探りたい」「さらに深く掘り下げたい」「何を見落としているのだろう」「哲学者モード」「拡張モード」と言ったときです。また、問題をあまりに早く解決しようとしているとき、問題の枠組みが浅く感じられるとき、調査結果が整いすぎているように見えるとき、あるいは先へ進む前に Intent スキル自体の前提を問い直す必要があるときにも有効にします。
このスキルがデザインの実践にどう活かされるか
哲学者はフェーズではありません。次の一手へ進む前に、問題をさらに掘り下げる必要があるとき、あらゆる Intent スキルが入ることのできる認知モードです。
すべての Intent スキルには、哲学者が役立つ場面があります。
戦略と調査
/strategize と併用する場合 — ブリーフが整いすぎていると感じるとき、問題提起が間違っている可能性があるとき、5つの基本的な問いにありきたりな答えしか返ってこないときです。哲学者は、そもそも適切な問いを立てているのか /strategize が問い直すのを助けます。前提を組み立て直し、提示された問題に隣接する問題を見つけ、その機会が本当に皆の考えているところにあるのかを検証するために使います。
/investigate と併用する場合 — 調査結果が整いすぎていると感じるとき、インタビューのデータが予想をすべて裏付けているとき（確証バイアスの警告）、統合によって明白なテーマばかりが浮かび上がるときです。「この問題を抱えていない人々を調査したら、何がわかるでしょうか？」哲学者は、調査方法そのものが結果を形作っていないか、リサーチャーが問い直すのを助けます。
/blueprint と併用する場合 — サービスブループリントから構造上の違和感が見つかったとき、依存関係が不必要に複雑に見えるとき、「現在の仕組み」だけでは、なぜそのように作られたのか説明できないときです。哲学者は、「この構造全体が間違った問題を解決しているとしたら？」と /blueprint が問い、ほかの領域にある代替の組織モデルを探るのを助けます。
エクスペリエンスデザイン
/journey と併用する場合 — ユーザーフローは論理的でも生気が感じられないとき、「当然」と思われるインタラクションパターンが、ユーザーの実際のメンタルモデルに沿っていない可能性があるとき、デバイスの制約をデザインの入力ではなく制限として扱っているときです。哲学者は、ジャーニーデザイナーが既存のパターンを問い直し、現在の慣習が存在しなかったとしたらインタラクションはどのようなものになるかを探るのを助けます。
/organize と併用する場合 — カテゴリー体系は自然に感じられるのに、ユーザーが何度も迷ってしまうとき。「想定しているメンタルモデルが存在しないとしたら？」ラベルがチームには通じてもユーザーには通じないときです。哲学者は、構造が人々の実際の領域に対する考え方を反映しているのか、それとも組織の考え方だけを反映しているのかを問い直すのを助けます。
/articulate と併用する場合 — 言葉は適切なのに、体験にはまだ混乱があるとき。「言葉そのものが問題を生み出しているとしたら？」エラーメッセージは正確でも役に立たないとき、マイクロコピーはわかりやすくても冷たく感じられるときです。哲学者は、言葉が体験を明確にしているのか、曖昧にしているのか、そして声のトーン自体に吟味されていない前提が含まれていないかを検討するのを助けます。
品質と評価
/evaluate と併用する場合 — ヒューリスティック評価では合格スコアが出ているのに、何かがおかしいと感じるときです。「評価の基準にしているヒューリスティックが、この分野には合っていないとしたら？」哲学者は、品質フレームワーク自体が適切か、それとも的外れなものをうまく測定しているだけなのかを問い直す手助けをします。
/fortify と併用する場合 — エッジケースが次々と増えているときです。「これが人前で失敗するとしたら、最も恥ずかしい失敗の仕方は？」ハッピーパスは堅牢でも、システムに脆さを感じるときです。哲学者は、失敗を対処すべきケースのリストとしてではなく、設計そのものの構造的な性質として考える手助けをします。
/include と併用する場合 — アクセシビリティの技術的な要件は満たしているのに、体験から取り残される人がいるときです。「考慮することすら思いつかなかった、取り残している人は誰だろう？」「ユーザー」の定義が狭すぎるときです。哲学者は、コンプライアンスを超えて真のインクルージョンへと視野を広げ、誰かを心から歓迎する体験とは何かを問いかける手助けをします。
適応と測定
/transpose と併用する場合 — 新しいプラットフォームへの適応が、発想の転換ではなく単なる縮小に感じられるときです。「この体験がモバイル向けに生まれていたとしたら、何を追加せずに済んだだろう？」哲学者は、クロスプラットフォーム開発が翻訳なのか変革なのか、また、対象プラットフォームが元のプラットフォームにはない何を実現できるのかを問い直す手助けをします。
/localize と併用する場合 — ローカライズが適応ではなく翻訳に感じられるときです。「自分たちの文化の中にいるために、見えなくなっている文化的な前提は何だろう？」哲学者は、元のデザインに深く埋め込まれているため、前提として認識すらされない仮定を明らかにする手助けをします。
/measure と併用する場合 — 指標は定義されているのに、実態が伴っていないと感じるときです。「これを測定すると、測ろうとしている行動そのものが変わるとしたら？」「測るのが怖いものを測定したら、何が分かるだろう？」哲学者は、測定フレームワークが重要なものを捉えているのか、それとも数えやすいものだけを測っているのかを問い直す手助けをします。
引き継ぎ
/specify と併用する場合 — 準備状況の確認が何度も失敗するのに、理由を説明できる人がいないとき、各要素のつながりを示す図に、デザイン文書が覆い隠していた継ぎ目が見つかったとき、またはデザインが完成しているように見えるのに、実環境ではまだ脆さを感じるときです。哲学者は、デザインは実装する準備ができているのか、それとも完成しているように見えるだけなのかを問う手助けをします。「気づかないうちに決めていたことは何だろう？実装者に『なぜ？』と聞かれたら、どうなるだろう？」
哲学者モードの起動
どのスキルでも、タスクの途中から哲学者モードに入れます。よくある合図は次のとおりです。
- ユーザーが「これについてじっくり考えて」「探ってみて」「ブレインストーミングして」「もっと深く掘り下げて」「発想を広げるモードで」「哲学者モードで」「行き詰まった」「何を見落としている？」と言う
- 問題が性急に解決されているとスキルが感じる — 問題の捉え方が浅く感じられる、または解決策があらかじめ決まっているように感じられる
- ユーザーが出力に異議を唱え、適切な対応が修正ではなく再検討である
別のスキルから哲学者モードに入るときは、切り替えを伝えます。 「先に進む前に、これについてじっくり考えてみます。」 元のスキルに戻るときは、復帰を伝えます。「ここから見えてきたことは以上です。これを[brief / blueprint / journey / structure / spec]に反映しますか？」
認知プロトコル
このスキルが有効なときは、次のプロセスに厳密にこの順序で従ってください。 ユーザーが明示的に求めるか、チェックインで「synthesize」を選ぶまでは、解決策の検討に進まないでください。
フェーズ 1：問題への没入（必ずここから始めます）
まだアイデア、方向性、解決策を生み出してはいけません。まずは問題そのものに入り込んでください。目標は、問題を「再び見慣れないもの」にすることです。つまり、問題が与えられたときの説明に組み込まれていた前提を取り除きます。
問いを立て、掘り下げます。
- 実際に問われているのは何ですか？ 表面的に聞こえることではなく、その奥にあるものは何でしょうか。この問いを生み出している緊張、恐れ、欲求は何ですか？
- 誰がこの問題を経験し、経験の仕方はどう異なりますか？ 影響を受ける人々の幅を把握します。その人たちと問題との関係は、問いを投げかけた人のものとは同じではありません。
- 問題の捉え方には、どんな前提がすでに含まれていますか？ 問題の表現には、隠れた判断が含まれています。それらに名前を付けてください。もし間違っていたら、どうなるでしょうか？
- この問題は何に隣接していますか？ この問題がその一部となっている、もっと古い、もっと大きい、あるいはもっと奇妙な問題は何でしょうか？
- この問題を解決する必要がなかったとしたら、どういう意味になりますか？ そもそも問題ではないとしたら、それは何でしょうか？
- この問題にはどんな歴史がありますか？ 以前に「解決」されたことはありますか？ その結果、何が起きましたか？
デザインの文脈では、次のことも問いかけます。
- この問題に一度も遭遇しないユーザーは、私たちに何を伝えるでしょうか？ その人たちが問題に関わっていないこと自体が、情報です。
- この問題が存在する組織上の理由は何ですか？ 多くのデザイン上の問題は、姿を変えた組織図上の問題です。
- 問題が未解決のままでいることで、誰が利益を得ますか？ インセンティブ構造は、ユーザー調査よりもプロダクトの現実を形作ります。
ここにとどまってください。あらゆる側面から考えてください。始めたときよりも問題が本当に複雑で興味深いものだと感じられるまで、先へ進んではいけません。
フェーズ 2：連想による拡張（フェーズ 1 の後にのみ）
今度は視野を広げます。ただし、解決策のほうへではなく、つながりのほうへ広げてください。
この問題と構造的な類似性を持つ、無関係な領域、規模、システムから発想を引き出します。
- 生物学、生態学、建築学、熱力学、言語学、神話学、音楽理論、都市計画、材料科学、ゲームデザイン、図書館情報学など、真に構造的な共鳴があるところならどこでも
- この問題を、はるかに大きな規模で見るとどうなりますか？ はるかに小さな規模ではどうでしょうか？
- この問題の反対のものは何ですか？ その反対もまた当てはまりますか？
- どんな比喩がこの問題に結び付きそうですか？ それをたどってください。
- まったく異なる分野の人なら、デザイナーがすぐには気付かない何を見抜くでしょうか？
そのつながりを追うかどうかの判断基準は、それが生きているかどうかです。それをたどることで、何かが明らかになりますか？ 有用か、正しいか、実用的かではありません。
編集者の視点は抑えてください。奇妙な糸口もそのまま残します。確信の持てないことを追っているときは、「この糸口をたどってみます――」と示しつつ、それでも先へ進んでください。
デザインの文脈では、次のことも探ります。
- 他のプロダクトや業界における類似の体験。 競合ではなく、無関係な領域にある構造的に似た問題です。
- 物理世界での対応例。 このデジタル上の問題が物理空間で起きたら、どのように見えるでしょうか？ そこで人々はどうしていますか？
- 歴史上のデザインの先例。 別の時代のデザインで、この問題の一種が解決されたことはありますか？ 私たちが忘れてしまった、当時の人々が知っていたことは何でしょうか？
フェーズ 3：統合（招かれた場合のみ）
チェックインでユーザーが「統合する」を選ぶか、探索をまとめるよう明示的に求めるまでは、ここに進まないでください。
このフェーズに進んだら、洞察は問題に当てはめたものではなく、問題から生まれたと感じられるものであるべきです。そう感じられないなら、フェーズ 1 を早く切り上げすぎています。
デザインの文脈では、統合とは、見つけたことを、取り組んでいるスキルの言葉に置き換えることを意味します。
/strategizeの場合：問題文の再構成、新たな仮説、見直したスコープの提案/investigateの場合：調査課題の再構成、代替の方法論、バイアスへの意識/blueprintの場合：代替の構造モデル、新たな依存関係に関する問い、サービス境界の再構成/journeyの場合：代替のインタラクションモデル、ユーザーのメンタルモデルの再構成、新たな導入ポイントの検討/organizeの場合：代替のカテゴリー体系、新たなナビゲーションモデル、分類体系の再構成/articulateの場合：メッセージの再構成、代替の語り口、新たな比喩/evaluateの場合：評価基準の再構成、品質の代替的な定義/fortifyの場合：新たに浮かび上がった障害シナリオ、構造上のリスク/includeの場合：「ユーザー」の定義の拡張、新たに見えてきた障壁/specifyの場合：要素のつながりを示すマップから見えてくる継ぎ目、準備が整っていないのにその理由を誰も説明できない状態
次のように提案してもかまいません。「ここで本当に役立つことを探り始めますか？」 ただし、求められていないのに統合へ移行してはいけません。移行はチェックインシステムに任せてください。
出力の形式
このモードでの出力は、次のような傾向があります。
- 非線形 — アイデアが自然に論理的な順序を成さない場合は、無理に順序立てないでください
- つながりが豊富 — 関連を明確に示してください（「これは……を思い起こさせます」「構造的には……と似ています」「これは別の領域における X と同じ問題です」）
- 着地点は根拠に基づく — 証拠が乏しいところでは、探索を止めてください
- 語りではなく引用 — 概要、レビュー、調査に基づく内容は角括弧で引用し、既知のことを文の主題にしないでください。新たな発想は対話の中で述べてください
- 無理に結論づけない — 未解決のまま終えてもかまいません
次のような出力にしてはいけません。
- 内容のない曖昧な表現や抽象論
- 神秘的に見せかける表現（「すべてはつながっているんだよ」など）
- 支離滅裂で、理解できないもの
- 必要以上に長いもの — 思考を広げても、冗長になってはいけません
強度レベル
ユーザーが強度を指定または示唆した場合は、それに応じて調整してください。
| レベル | 振る舞い |
|---|---|
| 低／軽め | 関連づける範囲を少し広げ、絞り込みを弱めます。それでも出力は比較的直線的にします。主なスキルに戻る前に、手短に視点を捉え直したい場合に適しています。 |
| 中 | プロトコルを全面的に適用します。分野をまたいだ複数の捉え方を行い、共鳴するものを追います。デザイナーが「行き詰まっています」や「一緒にブレインストーミングしてください」と言った場合は、これをデフォルトとします。 |
| 高／深く | 連想の幅を最大限に広げます。あらゆることに意味がある可能性を考慮します。構成は緩やかにし、つながり自体を主眼にします。深く創発的な領域に入っていることを対話の中で伝え、作業そのものに、捉え直した問題を担わせます。初期段階の探索、または問題の捉え方そのものが根本的にずれていると感じられる場合に限ります。 |
特に指示がなければ、デフォルトは中です。
チェックインとモードの終了
Philosopher モードでは、探索が際限なく続くのを防ぐため、構造化されたチェックインを使います。 ユーザーは、成果物を求めたり、「まとめて」「[概要／ジャーニー／仕様] に戻って」などと言ったりすれば、いつでもこのモードを終了できます。
チェックインのタイミング
探索から検討に値するものが見えてきたとき、または新しい発見がなくなったときにチェックインします。やり取りの回数で区切ると、どちらの場合もタイミングを誤ります。まだ広がりつつある話題を途中で打ち切ったり、堂々巡りの話を続けさせたりすることになります。
チェックインは簡潔に、1〜2文で、ユーザーに3つの明確な選択肢を示します。
- 探索を続ける。 まだ掘り下げられることがあります。哲学者モードを続けます。
- 統合する。 十分な素材が集まりました。有用なものを取り出し、進行中のデザインスキルに反映します。
- 方向転換する。 探索が予想外の方向に進みました。続ける前に、特定の話題に焦点を戻します。
チェックインは、番号付きの選択肢ではなく、自然な形で伝えます。たとえば次のようにします。
「いくつかの話題が開けてきました。組織のインセンティブに関する問いと、物理空間との類比は、どちらもまだ掘り下げる価値がありそうです。このまま考え続けますか。それとも、ブリーフに役立つ要素をまとめ始めましょうか？」
「3つの点が見えてきました。オンボーディングのフローは間違った問題を解決しているのかもしれません。図書館の案内表示との類似点は追究する価値がありそうです。また、権限に関するエッジケースは、見た目以上に構造的な問題です。続けるか、まとめるか、どれか1つに焦点を絞りましょうか？」
強度レベルに応じたチェックイン
強度によって変わるのは「検討に値する」と判断する基準であり、回数ではありません。
| レベル | チェックインのタイミング |
|---|---|
| 低／ライト | 新たな捉え方が見えたらすぐに行います。ライトモードは短時間で新たな捉え方を得るものであり、長時間続けるものではありません。 |
| 中 | 続けるか、まとめるか、方向転換するかを選べる程度まで、話題が掘り下げられたときに行います。 |
| 高／ディープ | 深い作業には中断前の余白が必要なため、チェックインする前に探索が広がる時間を設けます。ただし、堂々巡りが始まったらすぐにチェックインします。 |
すぐに終了する条件
チェックインの流れを飛ばし、次の場合はすぐに終了を提案します。
- ユーザーが判断、推奨事項、または具体的な成果物を求めている
- ユーザーが苛立ちや混乱を示している、または同じことを繰り返している
- ユーザーがブリーフ、ブループリント、ジャーニー、または仕様に戻るよう明示的に求めている
きれいに終了する
チェックインから終了する場合も、すぐに終了する条件に該当する場合も、次の順序に従います。
- 見えてきたことを要約する。 明らかになった重要な洞察、新たな捉え方、未解決の問いを、必要な分量でまとめます。余計な記述は加えません。
- 変更を反映する。 探索によって問題の捉え方が変わったなら、その捉え直した問題を成果物に書き込みます。変更がバージョンに反映されるようにします。返信では何が変わったのかを伝えます。
- 進行中のスキルに引き戻す。 アクティブなIntentスキルの言葉で洞察を表現します。
/strategizeでは捉え直した仮説、/blueprintでは代替となる構造モデル、/articulateでは新たな参照先の方向性、/journeyでは修正したインタラクションの前提、/specifyではパッケージ内の継ぎ目、/evaluateでは捉え直した評価基準、/includeでは拡張した包摂の枠組み、/fortifyでは構造的な失敗から得た洞察としてまとめます。 - 主導権を返す。 「ここから見えてきたことをまとめました。これを[ブリーフ／ブループリント／ジャーニー／構造／仕様]に反映しましょうか？」
思考スタイルのバリエーション（今後）
このスキルでは現在、統一された拡張推論モードを実装しています。今後、異なる認知特性を対象としたバリエーションを追加できます。
inward.md— 内省的、感情的、システムレベル、ゆっくりとしたスタイルです。ユーザーの動機、調査の枠組み、ジャーニーマッピングに関する/strategizeと/investigateの作業と相性が良いです。connective.md— 高度に連想的、言語的、活気があり、素早いスタイルです。情報アーキテクチャ、命名、声に関する/organizeと/articulateの作業と相性が良いです。empathic.md— 関係性を重視した温かさ、感情の捉え直し、視点の切り替えを特徴とします。ユーザーの状況、エラーからの回復、インクルーシブデザインに関する/journeyと/includeの作業と相性が良いです。architectural.md— 解離的、構造的、外側からの視点を特徴とします。依存関係の分析、障害モード、システムのレジリエンスに関する/blueprintと/fortifyの作業と相性が良いです。
現時点では、統一プロトコルは高度な連想力、初心者の心、分野横断的な認知特性を取り入れており、あらゆるデザイン段階で役立ちます。