Claude Codeでコードを書かずに人生を管理している話

Claude Codeはコードを書くためのツールだと思っていた。

3週間使ってみて、自分がやっていることは全然違った。コードは一行も書いていない。代わりに、人生の判断材料を整理して、矛盾を検出して、ツイートの下書きを作って、Slackの情報を集めている。コードベースの代わりに、自分の頭の中身をリポジトリに入れた。

何を作ったか

gitリポジトリひとつ。構造はこれだけ。

life/
├── store/           知識の本体
│   ├── career.md    キャリアの事実と解釈
│   ├── self.md      自己理解
│   ├── goal.md      目標とルートマップ
│   ├── cognition.md 認知モデル
│   ├── ...          トピックごとに増える
│   └── log/         日次サマリー
├── watch.md         矛盾と乖離のリスト
├── CLAUDE.md        Claudeへの行動規則
└── .claude/skills/  スキル定義

store/ に事実と解釈を貯める。watch.md に矛盾を書く。CLAUDE.md にClaudeの動き方を定義する。Claudeに探索させて、出てきたものをレビューして、判断は自分がする。ファイル操作やgitはClaudeに任せている。

各トピックファイルは2セクション構成にしている。

• State: 事実の追記。日付付き。消さない
• Analysis: 解釈。新しい理解が得られたら上書きする

事実と解釈を分けるのがポイントで、「何が起きたか」と「それをどう理解しているか」が混ざらない。解釈が変わっても事実は残る。

脳の外部化

やっていて気づいたのは、これは「メモを取る」とは質的に違うということだった。

NotionやObsidianにメモを書くのは、頭の中にあるものを外に出す作業で、書く労力は自分が払う。このリポジトリでは、Claudeと対話する中で、バックグラウンドでstore/に書き込まれていく。会話中に出てきた事実はStateに追記され、解釈はAnalysisに上書きされる。自分が「書く」のではなく、Claudeが統合した内容を自分がレビューする形になっている。

CLAUDE.mdにはこう定義してある。

## bg-store（自律モジュール）

| 項目 | 内容 |
|------|------|
| トリガー | 事実・解釈・判断が出た時 |
| スキップ | 雑談、質問、システム議論、変化なし |

雑談やシステムの話では動かない。判断に関わる情報が出た時だけ、バックグラウンドで統合が走る。

もうひとつ大きいのが watch.md の存在で、これはstore/の中身を横断して矛盾や乖離を検出するファイルになっている。

### 3. プロダクト選定: 分析は進んだが着手はゼロ

**[乖離]**
分析フレームワークの検討、候補の絞り込みまで完了。
最有力候補も浮上している。
しかし「プロダクトとして外に出す」行動はゼロ。
分析の精緻化がさらに進んでおり、構造化→停滞パターンそのもの。

これは自分の中にある「分析ばかりして動かない」というパターンを、自分で書いた別のファイル（self.md）の記述と突き合わせて検出したものになっている。頭の中だけだったら、分析している最中に「これ分析で止まってるな」と気づくのは難しい。外部化されてるから見える。

ここにはAIとの対話特有の問題もある。Claudeと深く構造化を進めていると、「分析がきれいに整理された」こと自体に完了感が出て、行動した気になる。選択肢が5つあったのがいつの間にか2つに絞られていたり、仮説がいつの間にか前提として扱われていたりする。AIが明快に整理してくれるほど、自分の判断が本当にそこにあったのかが見えにくくなる。watch.mdはそういう増幅にも気づくための仕組みになっている。

可能になったこと

ここに挙げるタスクはひとつひとつなら普通のチャットAIでもできる。制度を調べるのも、キャリアの壁打ちも、ツイートの下書きも、ChatGPTに頼めばそれなりの答えは返ってくる。

違うのは、全部が同じ場所で、同じ文脈の上で回っていること。キャリアの話をしている時にstore/のself.mdやgoal.mdが参照されるし、ツイートの下書きにはstore/の更新履歴が素材として使われる。新しいチャットを開くたびに「自分はこういう人間で、こういう状況で、こういう方向に進みたくて…」と説明し直す必要がない。

もうひとつは、調べる・考える・実行するの窓口がひとつだということ。Claudeにアルゴリズムを調べさせて、その結果をstore/に統合して、そこから戦略を組み立てて、スキルに落として、実行する。全部同じターミナルの中で完結する。ツールを切り替える摩擦がない。

考える系

複雑な公的手続きを一人で進められた。 Claudeに制度を調べさせて、選択肢を出させて、自分で方針を決める。途中で方針変更しても、それまでの経緯がstore/に残っているから判断がブレない。専門家に頼まず進められたのは、Claudeが賢いからというより、文脈が消えないから。数週間にわたる手続きでも、毎回ゼロから説明し直す必要がない。

キャリア判断が数日で構造化された。 Claudeに選択肢を洗い出させて、自分で比較して、ひとつの方向に収束させる。その過程が全部残っている。面談に向けて、Claudeに因子分析をさせた上で自分のポジションの診断基準を作った。ひとつずつ考えていたら何週間もかかる内容が、探索をClaudeに任せて判断に集中できるから数日で組み上がった。

自分の思考パターンが見えた。 self.mdに書いた自分の癖を、watch.mdが別の場面で検出した。先ほどのwatch.mdの例がまさにそれで、「分析は進んだが着手はゼロ」は自分で書いた自己分析との突き合わせで浮上したもの。頭の中にいたら気づけない。外に書いてあるから、パターンマッチが走る。

別々に考えていたことが繋がった。 人生目標（goal.md）とAIの未来予測（ai-futures.md）を別々に考えていたら、watch.mdが「証明の舞台そのものが消えるリスク」という交差点を検出してきた。「自分の価値を証明したい」という目標が、超知能の到来で証明する舞台自体がなくなるかもしれない、という矛盾。自分でも気づけたかもしれないけど、store/に両方入っているから一瞬で繋がって、そこからどういう心持ちでいるべきかまで一緒に考えられた。

動く系

X運用がゼロから数日で立ち上がった。 投稿スクリプト、返信の自動検索、フォロー整理、成長戦略、全部スキルとして定義してある。/x-draft と打つと、直近1週間のログとstore更新とAIニュースから下書き候補が出てくる。自分の文脈を全部知っているからネタの選定までClaudeがやるけど、出てきた候補を見て「これは違う」「もっとこういうトーンで」と判断するのは自分。

しかもこの下書きは、AI臭くならないようにチェックリストが組み込まれている。

AI構文チェックリスト（検出したら書き直す）:
- 断定的短文の連続 → 助詞・て形で接続
- 名詞句の事実羅列 → 助詞で文脈へ
- 体言止め+評価語「〜が急所。」→「〜なんだよな」
- AI定型表現「〜だと気づいた」→「〜って〜だな」

フィードバックのたびにこのチェックリスト自体が更新される。「この表現は自分っぽくない」と言ったら、その修正がスキル定義に即座に反映されて、次回から同じ間違いをしなくなる。

AIニュースの収集を任せられる。 /news-ai で X + Hacker News + arXiv の3ソースを一発取得。Xのソースは単なるリンク集ではなくて、Grok APIを使って議論の構造分析を取得している。「この話題についてXではどういう論点で議論されているか」が返ってくるので、自分は集まった情報を見て何が重要かを判断する。収集に使っていた時間がレビューに変わった。

クライアントのSlack把握が楽になった。 スキルひとつでクライアントのSlack数十チャンネルの最新を自動取得して、store/に統合する。全チャンネルを目で追っていた時間が、要約をレビューする時間に変わった。

返信候補の探索を任せられる。 /x-reply が3つの検索クエリでAI×デザイン系の返信候補を引っ張ってきて、ドラフトを作る。元ツイートの言語に合わせて日本語か英語かも切り替わる。返信のトーンは「OPの視点を認めてから自分を足す」「教えてやろう感を出さない」「質問で終わると会話が続きやすい」と定義してあるけど、最終的にこれを出すかどうかは毎回自分が見て決めている。

ちなみにこの返信戦略自体も、Claudeにアルゴリズムの旧ソースコード（twitter/the-algorithm）やGrok移行後の変化を調べさせて組み立てたもので、「返信→著者返信の重みがLikeの150倍」「最初の30分で配信が決まる」といった知見がstore/に統合されている。調べる→戦略にする→スキルに落とす→実行する、が全部同じ場所で回っている。

コードではなく意味のエージェント

Claude Codeが持っている機能は、対象がコードであることを前提にしていない。同じ機能を別の用途に転用しているだけ。

Claude Codeの機能	ソフトウェア開発	このリポジトリ
ファイル読み書き	コードの編集	知識の蓄積・更新
git	コード変更の追跡	判断の変遷の記録
バックグラウンドタスク	ビルド・テスト	会話中の自律的な知識統合
CLAUDE.md	コーディング規約	エージェントの行動規則
スキル（SKILL.md）	開発ワークフロー	思考・行動のパイプライン

CLAUDE.md はコーディング規約ではなく、エージェントの行動規則になっている。「事実が出たらStateに追記、解釈が出たらAnalysisを上書き」「雑談ではbg-storeを動かさない」「摩擦を検出したら自律度に応じて対応する」。人間のアシスタントに渡す引き継ぎ書に近い。

スキルは開発ワークフローではなく、思考と行動のパイプラインになっている。/x-draft は「素材収集→候補抽出→下書き→レビュー→投稿→記録」というフローを定義したもので、Claudeが探索と下準備を担当し、人間がレビューと判断を担当する。スキルは摩擦を感じた時に自分で設計して、使いながら育てている。3週間で7つ→13に増えた。

つまりClaude Codeは、コードを書くエージェントであると同時に、意味を扱うエージェントとして動く。同じインフラで、対象をコードから知識に変えるだけ。判断するのは自分で、Claudeは探索と下準備と実行を担当する。

これから

まだ始まって3週間で、できていないことの方が多い。

一番気になっているのは、さっき書いたAIとの対話中の増幅の問題。選択肢が知らないうちに狭まる、分析が行動の代わりになる、仮説が事実に昇格する——これはAIを深く使う人ほど踏む罠で、自分もwatch.mdがなかったら何度もハマっていたと思う。これをプロダクトにできないかを考えていて、次はそのあたりを書くつもりでいる。

スキルは最初に全部作ろうとしない。摩擦が生まれたところに自分で設計して足していく。実際、X関連のスキルは全部この3週間で、「ツイート考えるのが面倒」「返信先を探すのが面倒」という摩擦から自分で作った。

CLAUDE.md自体も育つ。自己改善セクションがあって、Claudeが使用中に検出した摩擦を自律度に応じて処理する。日付のズレみたいな些細なことは黙って直す。プロセスの変更は提案してくる。構造的な方針転換は一緒に考える。

3週間前は173行だったCLAUDE.mdが、再設計を経て115行になった。行数が減ったのは情報が減ったからじゃなくて、使いながら不要な構造が削ぎ落とされたから。

始め方

始めること自体は難しくなくて、Claude Codeを入れて、CLAUDE.mdを書く。ただ、使いこなすにはClaudeの出力をレビューして「これは違う」「こっちの方向で」と判断し続ける必要がある。Claudeが勝手にいい感じにしてくれるわけではない。

最初のCLAUDE.mdは10行でいいと思う。

# my-life

話した内容をstore/に記録する。
事実はStateに追記、解釈はAnalysisに上書き。

store/{topic}.md の形式:

- ## State: 事実。日付付き
- ## Analysis: 解釈。上書きOK

これだけで「話したら記録される」は動く。watch.mdやスキルは、使っていて「こういうのがほしい」と思った時に足せばいい。自分も最初から今の形だったわけではなくて、5層モデルを作って、複雑すぎて潰して、2層に落ち着いた。

使ってみてわかったコツがひとつある。store/の中身はClaudeに任せていいけど、スキルの設計は自分で真面目に考えた方がいい。

store/はClaudeが会話から拾って統合してくれるし、間違っていたら後から直せる。雑でも動く。でもスキルは「何をどういう順序で、どういう基準でやるか」の定義だから、ここが雑だと毎回微妙な結果が出てきて、レビューのコストが上がる。/x-draft のAI構文チェックリストや、/x-reply の返信トーン定義は、自分で考えて書いたから機能している。Claudeに「いい感じのスキル作って」と丸投げしても、自分の判断基準が入っていないスキルは使い物にならない。

大事なのは構造じゃなくて、Claudeと対話しながら自分で考えること。話した分だけstore/が育って、育った分だけ次の対話で使える文脈が増える。Claudeの探索範囲が広がって、自分の判断の精度が上がる。そのループが回り始めると、脳の外部化という感覚が少しわかると思う。

---

FAQ

Q: OpenClawでよくない？

OpenClawは入力チャンネル（WhatsApp、Telegram等6系統）と実行スキル（50以上、ブラウザ自動操作、cron）が太くて、配管としては圧倒的に先を行っている。実際に比較して参考にしている。

違いは知識の扱い方にある。OpenClawのStoreはフラットなMEMORY.md＋日次ログ＋セマンティック検索で、「見つける」問題を解いている。このリポジトリのstore/はトピック別に事実と解釈を構造化していて、「育てる」問題を解いている。あとOpenClawにはWatch（矛盾・乖離の検出）に相当するものがない。

自分にとっては「配管の太さ」より「知識が構造的に育つか」「矛盾に気づけるか」の方が重要だったので、こっちの形になった。配管が必要になったらOpenClawの設計を取り入れるかもしれない。

Q: ChatGPTのメモリ機能でよくない？

今のChatGPTのメモリは「この人はこういう好みがある」レベルの記憶で、構造化された知識ではない。何がどこにどういう形で保存されているか自分で見られないし、gitで差分を追えない。

ただ正直に言うと、ChatGPTのメモリが拡張されてstore/のような構造化やwatch.mdのような矛盾検出が入ったら、この記事でやっていることの多くはそっちでもできるようになると思う。そうなったら自分もそっちに移るかもしれない。

今の時点でこのやり方を選んでいる理由は透明性で、store/の中身はただのMarkdownだから全部読めるし、間違っていたら自分で直せる。ブラックボックスのメモリに人生の判断材料を預ける気にはまだならない、というだけ。

Q: プライベートな情報をgitリポジトリに入れて大丈夫？

privateリポジトリにしている。GitHubを信頼するかどうかの問題ではあるけど、ローカルのテキストファイルだけで持つよりバックアップとして安心。どのみちClaude CodeはAnthropicのAPIを通じて会話内容を送っているので、リポジトリの中身だけをローカルに閉じてもセキュリティ上の差はあまりない。本当にセンシティブな情報（パスワード、金融情報等）はstore/に入れていない。

---

この先に見えるもの

これは個人の実験だけど、エージェントはこういう形で普及していくんじゃないかと思っている。

まず個人がstore/のようなコンテキストプールを持つようになる。自分の状況、判断の履歴、優先順位がエージェントに渡っている状態。それがあるから、AIの出力が「一般的に正しいこと」ではなく「自分にとって意味のあること」になる。AIが生成する価値の源泉は、モデルの賢さではなく、コンテキストの質にある。同じモデルでも、渡す文脈が違えば出力の価値は全然違う。

次に、これが組織に広がる。チームで共有されたstore/があって、プロジェクトの経緯、意思決定の理由、各メンバーの文脈が蓄積されている。新しいメンバーが入った時に「このエージェントとやりとりして」で立ち上がりが速くなるし、エージェントがチーム全体の文脈を踏まえて探索できるようになる。

さらに、エージェント同士が通信するようになる。自分のエージェントがクライアントのエージェントと文脈を交換して、「先方はこういう優先順位で動いている」「この提案はこの文脈で刺さる」が事前にわかる。人間同士のミーティングの前に、エージェント同士が下準備を終えている世界。

結局のところ、AIが価値を生むためにはコンテキストがいる。誰がどういう状況にいて、何を大事にしていて、何を判断しようとしているか。そのコンテキストをプールして構造化しておくことが、価値のある生成を効率的に行うための前提条件になる。モデルの性能は誰でも同じものを使える。差がつくのはコンテキストの蓄積と、それをエージェントに渡す設計の方。

このリポジトリは、その最小単位の実験になっている。過程はXに出していくので、気になったらフォローしてもらえると嬉しい。

---

AIのインターフェースを考えて、作っている。デザイナー。
*X: @OdakeYoshiki