Day45|入れる前に、「どう使うか」を決める

2026年7月13日の記録

ナレッジは、入れた量では完成しない。

使える形で取り出せて、初めて完成する。


100日チャレンジ45日目。今日はClaude Codeで進めているPonoのAIワークスペースを、かなり大きな視点から見直した。

ここ数日はとにかく情報を入れることに集中していた。メニュー、薬剤、技術基準、カウンセリング、施術フロー、判断基準。質問されるたびに答えて、確実にナレッジは増えていった。

作業自体は前へ進んでいる。でも今日、途中でふと立ち止まった。

この情報を、最終的にどこで、誰が、どう使うんだろう。

ナレッジを増やすことが目的になって、実際の使い方を後回しにしていたことに気づいた。今日は作ることを一度止めて、設計を見直した一日だった。

メンズ展開を見据えて、構造から作り直す

現在のPonoは女性のお客様が中心だ。ただ男性のお客様もいるし、今後はメンズサロンの展開も構想している。

これまでClaudeへ情報を入れる中でも男性向けの内容は少しずつ加えていた。でも女性向けの既存サロンを前提にした構造へ、男性向けの情報を後から足していくだけでは、いずれ分かりにくくなる。

そこで今日は一度全体を見直した。今のPonoだけに最適化するんじゃなくて、現在の女性向けサロン、将来のメンズサロン、両方で共通するPonoの技術思想、ブランドごとに異なるメニューや判断基準を分けて扱える構造に再設計する。

まだ完成前だからこそ、今の段階で見直した方がいい。そう判断した。

Claudeの使用量はかなり増えて途中で上限に達した。それでも全体としては8割ほどまで進められた感覚がある。今日の成果は、情報が増えたことよりも、将来の横展開に耐えられる構造へ近づいたことだった。

症例を入れる前に、優先順位のズレに気づいた

構造の見直しが進んで、次は症例を入れる段階に入った。

最初は症例を蓄積すれば、スタッフ教育や判断支援に使えると思っていた。それ自体は間違っていない。

ただClaudeから求められた内容を確認していくと、かなり深いところまで症例を掘り下げる設計になっていた。一方で自分が今ほしいものは、そこまで高度な症例研究じゃない。

まず必要なのは、既存マニュアルを理解しやすくすること、スタッフが確認しやすい形へ変えること、現場で迷ったときに判断基準を取り出せるようにすること。もっと手前の部分だ。

症例を深く蓄積することは後からでもできる。でも今の優先順位じゃない。そう判断して、症例入力はいったん止めた。進められることと、今進めるべきことは同じじゃない。

作っているのに、完成形が見えていなかった

Claude Codeを本格的に使うのは今回が初めてだ。

そのため作業中はずっと「何かすごいものができている」という感覚はあった。質問に答えて、ファイルが作られて、情報が分類されて、確実に前へ進んでいる。

ただ自分自身は、どこにファイルが保存されているのか、どんな構造になっているのか、完成後にどう使うのかを十分に理解していなかった。

つまり作る工程には参加していたのに、利用する場面を具体的に想像できていなかった。

Claude Projectsは、独立したワークスペースの中にチャット履歴やナレッジを持ち、アップロードした資料を会話の文脈として利用できる仕組みだ。だからこそ、何を蓄積するかだけじゃなくて、完成後にどんな質問や業務で使うのかまで決めておく必要がある。

今日はそこを理解するために、ファイルの場所や構造を一つずつ確認した。ある程度は分かった。ただまだ誰かへ教えられるほどではない。

先に出力してみればよかった

今回の反省点はかなり明確だ。

ナレッジを入力し始めた段階で、一度でも実際に使ってみればよかった。カウンセリングマニュアルを作る、新人スタッフ向けの確認シートを出す、施術判断のフローチャートを作る。そういった成果物を一つ作っていれば、必要なナレッジと不要なナレッジが見えたはずだ。

でも今回は完成形を試さないまま入力を続けた。その結果ナレッジは増えたものの「このまま、どこまで入れれば完成なんだろう」という状態になってしまった。

AmazonやAWSで使われているWorking Backwardsは、作り手の都合から始めるんじゃなくて、最終的な利用者や得たい結果から逆算して設計する考え方だ。今回のワークスペースにも、まさにこの考え方が必要だった。

先にナレッジを完成させてから使うんじゃなくて、まず小さな成果物を出して、そのために足りない情報を追加する。次からはこの順番で進めたい。

この記事で扱っていること

Claude Codeで進めているPonoのAIワークスペースを、大きな視点から見直した日です。情報を入れること自体が目的になっていたことに気づきました。

先にナレッジを完成させてから使うのではなく、まず小さな成果物を出して、そのために足りない情報を追加する順番へ切り替えました。

  • メンズ展開を見据えて、構造から作り直す
  • 症例を入れる前に気づいた、優先順位のズレ
  • 使う場面から逆算して設計する(Working Backwards)
  • (note有料部分)NotebookLMの資料を使って、入力と出力を交互に進めたやり方

この記事の重要ポイント

  • ナレッジを増やすことが目的になって、実際の使い方を後回しにしていた
  • 成果は情報が増えたことよりも、将来の横展開に耐えられる構造へ近づいたことだった
  • 先にナレッジを完成させるのではなく、小さな成果物を出して足りない情報を足していく

この記事の後半は、noteの有料エリアです。