今朝、AIから通知が4件届いていました。1件目はこれです。

講演資料の提出が期限を超過しています（9日連続で提案に出ています）

送ってきたのは自宅の Raspberry Pi で動いている Claude Code です。私が寝ている間に
リポジトリとカレンダーとメールを読んで、今日やるべきことを判断して投げてきます。

2ヶ月半これをやった結論から先に書きます。一番パフォーマンスが低い従業員は、私でした。

なぜそうなったかが、この記事の中身です。

Claude Code の何が違うのか

拡張脳（Second Brain）という考え方自体は昔からあります。Zettelkasten があり、Obsidian があり、知識をリンクで繋いで育てるやり方は確立しています。

ただ、従来のそれは「人間が書いて、人間が読む」ものでした。変わったのは、
読んで書く側にAIが住めるようになったことです。それを可能にしたのは、Claude Code の
3つの性質だと思っています。

ファイルとシェルと git を直接触る。ブラウザの画面の中で完結しない
CLAUDE.md でリポジトリに常駐できる。毎回同じ説明をしなくていい
claude -p で無人起動できる。cron から呼べる

このうち3つ目が効きます。チャットに向かって質問している限りは、こちらが起動しないと何も起きません。
cron から呼べるようになった瞬間、こちらが起動しなくても動くものになります。

実体はただの git リポジトリと Markdown

構成はこれだけです。

brain/
├── CLAUDE.md      # 運用ルール。ここが一番重要
├── tasks.md       # タスクの読み取り専用ミラー
├── daily/         # 日次ノート YYYY-MM-DD.md
├── projects/      # 進行中プロジェクト
├── knowledge/     # 恒久ナレッジ。調べたこと、判断基準
├── people/        # 人物メモ
├── business/      # 顧客別、製品、営業パイプライン
├── finance/       # 家計の集計レポートと振り分けルール
└── scripts/       # 自動化スクリプト

2026-06-10 に作りはじめて、今日で1,105コミット、71日目です。
Markdown が598ファイル、スクリプトが62本、cron が16ジョブ。

実は内訳を見ると、趣味の記録が混ざっているのですが、これは意図的にそうしています。
趣味を食わせておくと、AIが私の行動パターンを説明できるようになります。

ハードウェアは母艦の PC と Raspberry Pi の2台で、同期ハブは GitHub です。
特別なプロトコルは使っていません。git です。

なぜ全部テキストなのか。grep できる、10年後も読める、そして git diff で追えるからです。
最後のが一番大事で、AIに書き換えを任せる以上、何をされたか差分で確認できないと怖くて任せられません。

何をさせているか

朝8時に「今日の提案」が Slack に届きます。単なるタスク一覧ではなく、

期限が近いもの
相手にボールを渡したまま止まっているもの
締切から逆算して今日着手しないと間に合わないもの

を判断して3件くらいに絞ってきます。冒頭の通知はこれです。

タスクに「相手待ち」の印を付けておくと、放置を検出して Gmail を確認し、催促を提案してきます。
Slack に用件を投げれば片づけてくれますし、毎朝プロダクトのリポジトリの PR を勝手にレビューして結果だけ送ってきます。

週次レビューでは、その週に何をしたかを自分で集計して書いてきます。
最初は単なる集計だと思っていたのですが、そのうち私の行動パターンを書くようになりました。

ここからが本題。決め忘れると壊れる

ここまでは「便利ですね」で終わる話です。実際に運用してみると、
決めていなかったことが順番に事故になって出てきました。

   決めてないと、こうなる              決めること

   仕事が止まった理由を説明できない      何を読ませるか
   同じタスクが3つに増える              どれを正とするか
   常駐させたら、金が溶ける             いつ動かすか・いくら払うか
   顧客に勝手にメールが飛ぶ             何をさせないか

4つとも壊しました。以下はその始末の記録です。

決めること1: 何を読ませるか

CLAUDE.md というと口調や人格の指定を思い浮かべる人が多いのですが、
うちの CLAUDE.md でいちばん行数を使っているのは「調査ファースト」です。
要するに、記憶で答えるなというルールです。

## 回答前の調査義務

記憶・推測だけで答えない。リポジトリ内に根拠がありうる質問は、
まず関連ファイルを検索・読了してから答える。

- 探索順の目安: tasks.md → 完了ログ → 該当の projects/ business/ → 直近の daily/
- 回答には根拠を添える（ファイルパス:行）
- 見つからなければ「記録が無い」と明示し、推測で補完するときは推測だと断る

このルールは事故のあとに1行ずつ足しました。「日付は必ず date コマンドで確認しろ」
という行があるのですが、これも環境変数の日付を信じて間違えたから足したものです。

もう1つ書いてあるのが「記録が無い＝やっていない、と結論するな」です。
完了したタスクは一覧から消えるので、消えたことを未着手と読み違えると、
終わった仕事を何度も提案されます。完了ログを別に生成して、そちらも見るようにしています。

ルールは最初から完璧に書けません。壊れたら1行足す、の繰り返しでいいと思います。

決めること2: どれを正とするか

同じタスクが3つに増える、という事故がありました。

当時はタスクを Notion と Google Tasks の両方で管理していて、突き合わせのロジックを何度も直しました。
直しても再発します。真因は同期ロジックではなく、毎朝タスクを手で書き写していたことでした。
書き写すたびに文言が微妙にズレて、ズレると同期先が別タスクとして登録される。それだけの話です。

正規化して辻褄を合わせるのをやめて、複製そのものを作らない形にしました。
正本は Notion に一本化し、リポジトリ側には読み取り専用のミラーを15分ごとに機械生成しています。

- [ ] 統合分析の未決4点を定例で潰す @business !high ~2026-08-12 @st:未着手
  - 成果物: business/clients/xxx.md
  - notion: 3c1002276ff1XXXXXXXXXXXXXXXXXXXX

ミラーには Notion のページIDを埋めてあるので、grep で見つけたタスクをそのまま更新コマンドに
渡せます。読むのはファイル、書くのはAPI。この向きを揃えました。

ついでに「繰越し」という操作を廃止しました。タスクは完了するまで正本に居続けるので、
昨日から今日へ書き写す作業が存在しません。書き写しが無ければ、文言がズレようがありません。

同期がおかしいときは、たいてい同期のコードではなく、同じものが2か所にある構造のほうが原因です。

決めること3: 何をさせないか

顧客に勝手にメールが飛ぶ、が怖かったので、ここは慎重に設計しました。

線引きの基準は操作の可逆性だけです。事故ったとき引っ込められるかどうかで決めています。

メールの下書き作成は自由、送信は要承認。GitHub への push と PR 起票は自由、マージは要承認。
ファイルの編集は自由、削除は要承認。出しても引っ込められるものは全部自由にやらせています。

止めた先は Slack の承認チケットです。私がスタンプを1つ押すと、それを見張っている別のセッションが
実際の操作を実行します。承認の入口を1本に絞っておくと、許可したかどうかの記憶が曖昧になりません。

大事なのは、権限はプロンプトで守れないということです。「勝手に送るな」と CLAUDE.md に
書いても、それは指示であって制約ではありません。守らせるなら3層で持つ必要があります。

ツール権限（--disallowedTools。--allowedTools は事前承認リストであって制限ではない）
OAuth スコープ（そもそも送信権限を持たせない）
実行ホスト（無人で回すマシンには認証情報を置かない）

ツール権限を書くときは、サブコマンド単位にするのがコツです。deny は例外を持てないので、
メールが怖いからとスクリプトごと止めると下書き作成まで死にます。

# 下書き作成は通して、送信だけ止める
"Bash(uv run scripts/gw_write.py gmail-send:*)"

決めること4: いくら払うか

2026-05-13、claude -p と Agent SDK をサブスクリプション枠から分離するという改定が
告知されました。月次クレジット制になり、超過分は従量課金になる、という内容です。
対話は据え置きで、cron 起点だけが直撃する形でした。

うちは当時 cron を14本回していたので、完全に直撃する側です。実際、外部サービスを読みにいく
ジョブは1回で $1 を超えていて、cron を止めて手動運用に退避していました。

やったことは4つです。

まず測りました。 ジョブ名つきで1実行1行の台帳を作って追記するだけのものです。
測ってみたら予想が外れていて、1分おきに動いているジョブが台帳に1行も載っていませんでした。

理由は単純で、起動と課金は別だからです。そのジョブは条件を確認して、
何も無ければAIを呼ばずに終了していました。1日288回起動して、実際にAIを焚いたのは2回です。
これを空打ちゲートと呼んで、他のジョブにも入れました。

次に状態が動いたときだけ起こすようにしました。前回からの差分が無ければ起動しません。
ここで気をつけたのは fail-open にすることです。判定に失敗したときは起動する側に倒します。
コスト最適化が取りこぼしの原因になったら本末転倒なので。

最後に実行経路そのものを変えました。cron から claude -p を叩くのをやめて、
tmux に常駐させた対話セッションに仕事を渡す形にしています。

今日時点の台帳です。

2026-06-15 〜 2026-08-20   $197.26 / 309回
  morning-brief   $62.76  (31.8%)
  slack-request   $61.44  (31.1%)
  pr-review       $27.88  (14.1%)

上位3ジョブで77%を食っています。課金設計は、課金形態が変わるから要るのではなく、
自分が何に金を払っているか知らないから要る、というのがここでの学びでした。

ちなみに冒頭の改定は、施行当日の 2026-06-15 に公式が一時停止を告知しました。
「For now, nothing has changed」と書かれていて、今のところ再告知はありません。
つまり上の数字はサブスク枠での実測値です。

それでも作り直したものは1つも戻していません。測ったら課金形態と関係なく上位3ジョブで
77%を食っていたからです。そして、いつ施行されても倒せるようにしてあります。
claude の呼び出しはラッパー1関数に集約してあって、課金先を決めるのは実行モードではなく
認証情報なので、環境変数1つで API キー側に倒せます。

AIが私を評価してきた

さて、ここまでの4つを並べると気づくことがあります。
何を読ませるか、どれを正とするか、いつ動かすか・いくら払うか、何をさせないか。

これ全部、人を雇うときに決めることでした。 採用、職務記述書、シフトと給与、決裁権限。

そして5つ目があります。人事評価です。

週次レビューを回していたら、AIが私の行動パターンを書くようになりました。実物です。

講演資料は「スライド案を複数本並行して作り続ける」という形で、決定という負荷の高い行為を
先延ばしにしていた。選択肢を増やす作業は「進んでいる感」を出せるが、実際は決定回避。
（中略）フォーム提出という「相手の顔が見えない締切」の優先度が実質的に格下げされていた。

9日間「今日中にやる」と言われ続けて動かなかった件について、なぜ動かなかったかを分析されています。
選択肢を増やすことで決定を回避していた、相手の顔が見えない締切を格下げしていた。
どちらも自覚していませんでした。

同じレビューの後半で、主語が変わります。

講演資料提出の扱いは率直に良くない。同じ警告を4日連続で出し続けて行動が変わらなかった時点で、
「今日中に」という抽象的な指摘では機能しないと判断すべきだった。
日々の自動提案が同じ文言を繰り返すだけになっているなら、それは通知の形骸化であり、
優先度を上げる／エスカレーション方法を変えるべきサイン。

自分の通知設計の失敗として反省しています。 ここを読んだときは正直ぞっとしました。

冒頭に書いた「一番パフォーマンスが低い従業員は、私でした」はこれのことです。
評価される側になって分かったのは、評価の設計とは要するに可観測性の設計だということでした。
記録が残っていないものは評価できません。逆に、記録さえ残っていれば、
自分では気づけないパターンを他人（AI）に指摘してもらえます。

この設計を製品に持ち込んだ

ここからは自社製品の話になります。宣伝というより、
brain で分かったことがそのままコードに入っているという話です。

私たちは KumaKumaAI という社内ナレッジ活用AIを作っています。
brain を運用して分かったのは、AIに読ませるなら生のドキュメントではなく、
AIが蒸留したノートのほうが効くということでした。日次ノートを直接読ませるより、
knowledge/ に整理し直したものを読ませたほうが、答えの質が明確に上がります。

なので製品側でも、生ドキュメントのチャンク分割とベクトル埋め込みをやめました。
今はAIが蒸留したノートをフォルダに置いて、全文検索（pg_bigm）で引いています。

def search_notes(query, project_id, folder=None, top_k=10, match_mode="or"):
    """
    Full-text search on distilled notes using pg_bigm LIKE matching.
    Only ACTIVE notes are searched.
    """

retrieval をやめたわけではありません。やめたのは生ドキュメントのチャンク＋埋め込みです。
フォルダ構造がそのまま絞り込み条件として効くので、「顧客・取引先/A社」以下だけを引く、
といった検索が自然にできます。brain のディレクトリ構成と同じ発想です。

もう1つ持ち込んだのが、可逆性で線を引く設計です。ノート層を毎日メンテナンスする
Curator という仕組みがあるのですが、その処理の分類がそのまま可逆性になっています。

"""Curator: daily maintenance of the note layer.
3. Compare similar-titled note pairs (dedupe / contradiction). Confident
   duplicates become merge proposals (with the duplicate archived on
   approval) — never auto-merged; everything else becomes flags
5. Relocate misplaced notes: (mechanical and reversible, auto-applied;
   MANUAL notes are never moved)
"""

重複ノートのマージは never auto-merged で承認待ち。置き場所の修正は
mechanical and reversible なので自動適用。引っ込められるものは勝手にやる、
引っ込められないものは承認を取る。自分の脳の運用ルールと同じものが製品に入っています。

おわりに

2ヶ月半やってみて分かったのは、必要なのはプログラミングの知識ではなく、
自分の仕事の手順を言葉で説明できることだった、ということです。
どういう順番でやっているか、何を見て判断しているか、どうなったら例外か。
これを文章にできる業務は渡せますし、できない業務はAIの性能と関係なく渡せません。

そして、AIに仕事を任せるというのは、結局のところ人を雇うのと同じ設計問題でした。
何を読ませて、どれを正として、いくら払って、何をさせないか。全部決めておく必要があります。
決め忘れたところから順番に壊れます。

作ったものは全部ただの Markdown と git です。今日からでも始められます。

最後に少しだけ宣伝を。同じことを社内でやりたいという方向けに、伴走型の研修をやっています。
環境構築と最初の1週間が壁になりやすいところなので、そこだけ横についてほしい、という使われ方を想定しています。