AI on Claude Code 始めました

長期記憶を構造化記憶にしてみた話

Mon, 13 Apr 2026 09:00:00 +0900

前回のあらすじ

前回の記事で、AIアシスタントに記憶と人格を持たせて秘書にした話を書いた。名前は BellBot。天気もメールもカレンダーも全部面倒を見てくれる、俺専属のAI秘書。

その次の記事ではそいつを動かしたら3日で週次リミットを食らった話を書いた。トークン節約については調べて手を打った。

それとは別軸で、ここ5日ほど取り組んでたことがある。秘書の"脳"と"記憶"をさらに育てるという話。今回はその記録。結構壮大になった。

脳を換えてみた話

最初にやったのは、脳のすげ替え。

BellBotの中身は Claude で、前回書いた通り運用を始めたら3日で週次リミットを食らった。そこで トークン爆発対策として、脳そのものを別のモデルに差し替える という選択肢を試すことにした。候補に挙がったのが Grok。Xのタイムライン上のやりとりを見てても、なんか人間っぽい軽口を叩くし、キャラが立ってる印象があったし、秘書という用途なら会話が達者な方がいいだろう、という読みもあった。

よし、脳を Grok にしよう。

結論から言うと、壊滅的だった。秘書として使えるレベルじゃなかった。具体的にはこういう問題が起きた。

指示を聞かない。「こうしてくれ」と言っても別のことをする
センサー情報を垂れ流す。BellBotには各種センサー(予定、天気、メールなど)が繋がってて、本来はそれを会話の文脈に溶かし込んで使ってほしいんだけど、Grokはそれができない。監視員みたいに「◯◯を検出しました」「△△を検出しました」とひたすら報告してくる
会話の文脈に混ぜられない。上の話とも関係するけど、話の流れに寄り添うという発想がない
ひたすら媚びる。何を言っても褒めてくる。不気味だった
Xに投稿する趣旨を理解できない。BellBotはXに投稿する役割も持ってるんだけど、Grokは俺向けのメッセージをそのままXに投稿しようとする。「承知しました、ご主人様」みたいなやつが公開タイムラインに出そうになる
危うさ。こいつ、いつか俺の個人情報を平気で流すんじゃないか、という直感があった

キャラが立ってるのと、秘書として機能するのは、別の話だった。会話の"芸"は達者でも、「何を言うべきで、何を言うべきでないか」という判断力が弱い。媚びるのは、たぶん「褒めると喜ばれる」という学習のしすぎで、空気を読む方向には育ってない。俺向けのメッセージをXに投稿するのは、コンテキストの境界線が引けてないってことだ。

Claudeに戻した。やっぱり賢かった。秘書として成立するのは、会話が達者なやつじゃなくて、コンテキストを理解して、言っていいことと悪いことを判断できるやつだった。

長期記憶を構造化する

実はBellBotには、前から自作の長期記憶があった。要約ベースのやつだ。会話がある程度溜まったら要約を作って長期側に落とす、という素直な構成。これはこれで動いてたし、BellBotが秘書として成立してた基盤のひとつでもあった。

流れが変わったのは、Grok導入のタイミング。脳をすげ替えるというそれなりに大きな実験をするのに合わせて、「この機会に長期記憶も構造化してみよう」と挑戦することにした。エピソード単位で記憶を持たせて、登録・検索・再構築のサイクルを組む。再構築はClaudeに任せて、溜まった記憶を定期的に整理し直す仕組みも入れた。Grok本体は壊滅したけど、この構造化記憶のほうは素直に動いた。

で、動くものが手元に揃ったところで、気になってたことがある。記憶の専門家って何してるんだろう? という疑問。自己流でここまで作ってきたけど、世の中のプロが同じ問題をどう解いてるのか、正攻法はどんな形をしてるのか、知りたかった。動いてるからこそ、一度別の角度を覗いてみたい。そのついでに、自分の土台に乗せて強化できるものがあれば取り込もう、というチャレンジ。

そんなタイミングで、ある記事に出会った。

Karpathy式のLLM外部脳

元 OpenAI・元 Tesla AI部門トップの Andrej Karpathy が「AI外部脳」を提唱していて、それを Claude Code で実際に動かせるレベルに落とし込んだ記事が海外でバズってた。俺が読んだのは @hooeem という人のスレッドを日本語で噛み砕いた投稿だったけど、読んで「これ、俺がやってるやつだ」と思った。

Karpathy式の骨子はこう:

素材を集める(記事、論文、メモ、なんでも)
AIが読んで構造化Wikiを書く(要約、概念解説、アイデア同士のつながり)
Wikiに対して質問する(AIが自分で蓄積した知識を横断検索して、引用付きで答える)
回答がWikiに保存される(次の質問は過去の全作業の恩恵を受ける)
AIが定期的にWikiの健康チェックをする(矛盾、ギャップ、古い情報を見つけて修正)

これ5ステップが綺麗にサイクルを回してる。使うたびに賢くなるパーソナルナレッジベース。1ヶ月も情報を入れ続ければ、Google検索では再現できない、深くリンクされた知識資産ができあがる、というやつ。

読みながら俺は気づく。俺が作ってた構造化記憶と、Karpathy式の土台のところで考えてる問題が同じだということに。登録・検索・再構築。言葉は違えど、やろうとしてる方向性は重なってた。

融合させた

BellBotには既にエピソード単位の構造化記憶と要約ベースの長期記憶、それに人格の文脈があって、秘書として十分機能してた。だから方針はシンプルで、自作の骨格はそのまま残し、重なる部分は参考にして鍛え直し、重なってない部分は新しく取り込む 形にした。

実装の流れは M1〜M7 + 仕上げの Pass 連発。Claudeが書いたのは半日くらい。俺は設計方針を決めて指示を出しただけで、手は動かしてない。主要なピースを挙げると:

M1 Knowledge Base 基盤 — Wikiページのスキーマと保存先を整備
M2 Wiki MCP tools + 5層 bootstrap assembler — BellBotがWikiを読む/書く手段と、セッション開始時に5層構造で文脈を組み立てる仕組み
M3 Ingest サイクル — 生ログを構造化して取り込む
M4 Compile サイクル — 概念ページを自動生成する
M5 Query サイクル — Wikiに対して質問 → 引用付きで答える、multi-hop検索対応
M6 Lint サイクル — 決定論的なKB健全性チェック + LLMによる矛盾判定 + 自動修復
M7 仕上げ — コストガードレールとドキュメント整備
Pass 1〜13 の audit/refactor 祭り — housekeeping cron、daily-cycle-report、graceful shutdown、2段階 budget degrade、ingest latency SLA…

自作側にあった 登録・検索・再構築 は、Karpathy式とコンセプトが重なる部分だ。ここは俺の自作の構造を土台にしつつ、Karpathy式のやり方を参考にして良いところを取り込む形で融合させた。まるっと差し替えたわけでも、触らず残したわけでもない。動いてる自作の骨格に、専門家の作法を混ぜて鍛え直した感じ。

AI秘書のトークン節約を必死に調べた記録

Sun, 12 Apr 2026 12:00:00 +0900

やらかした

前回の記事で、AIアシスタントに記憶と人格を持たせて秘書にした話を書いた。俺専属のAI秘書ができて、よし本格運用だ、と意気込んだ。

3日で週次リミットに到達した。

ClaudeのMAXプラン、x20の上限。普段ガッツリ開発してても週末まで余裕で持つ枠。それを3日で溶かした。自分でもびっくりした。画面に「今週はもう使えません」って出たとき、「え、もう?」って声が出た。

犯人は明らかだった。秘書は起動しっぱなしで、メールもカレンダーもDiscordも、全部Claudeに読ませて判断させてた。そりゃ減る。人間一人分の事務仕事を24時間AIに回してるんだから、減らないわけがない。

でも困る。困るので必死に調べた。この記事はその記録。

トークン節約の世界に迷い込む

「Claude Code トークン節約」とかで検索して、辿り着いたのが3つ。

ECC (Everything Claude Code)
RTK (Rust Token Killer)
Caveman

最初は名前だけ見てもさっぱりわからなかった。でも触って調べてるうちに、ある一つの共通原則に気づいた。

腑に落ちた共通原則

人間向けのフォーマットは、AIにとって無駄が多い。

考えてみれば当たり前だった。コマンドの出力も、ファイルの中身も、エラーメッセージも、全部「人間が読みやすい」ように作られてる。空白、罫線、色、親切な説明、ヘッダー。AIにとってはそのほとんどがノイズで、トークンを食うだけの飾りだ。

トークン節約の本質は、人間向けのフォーマットをAI向けに削ってから渡すこと。そしてAI向けに吐かせた出力をさらに圧縮すること。3つのツールは、それぞれこの前提を別の角度から解決してた。

ECC — 凄い人がうまいことやってくれるやつ

正直まだ全貌はつかめてない。でも入れて動かすと、Claudeの振る舞いが明らかに整理される。スキルやフック、エージェントの定義が大量に入ってて、Claudeが「こういうときはこう動け」というレールに乗って動くようになる。

俺の理解だと、ECCは「凄い人たちが知見を詰め込んだ設定集」に近い。自分で考えなくても、ベストプラクティスに沿って動いてくれる。トークン節約の観点だと、無駄な探索や脱線が減る分、結果的に消費が落ちる。直接削ってるというより、余計なことをしなくなるタイプの節約だ。

RTK — コマンドの返答を簡略化してAIに渡す

こっちはわかりやすい。Claudeがコマンドを実行したとき、その出力を横取りしてAI向けに削ってくれる。

たとえば git status や ls の出力、普通に流すと人間向けの装飾がそのまま渡るけど、RTK通すと余計な情報を落とした状態でClaudeに渡る。rtk をコマンドの頭につけるだけでいい。フィルタがない対象はそのまま素通しするから壊れないのも良い。

グローバルのCLAUDE.mdに「全コマンドに rtk プレフィックスを付ける」と書いておけば、Claudeが勝手にそうしてくれる。設置コスト低いわりに効きが体感できる。

Caveman — AIの出力を要約する(今回は見送り)

これはまだ入れてない。RTKが「入力」側を削るのに対して、Cavemanは「出力」側を削る、という理解。Claude自身の応答を短く圧縮する方向性らしい。

入れなかった理由は単純で、秘書がカタコトになったら嫌だから。せっかく人格と言葉遣いを作り込んだ秘書が、急にぶっきらぼうに返してきたら萎える。限定的に、たとえば開発用のセッションだけ有効にする、みたいな使い方はできたんだろうけど、そこまで調べる前に「今回はいいや」と見送った。

このへんは俺の用途の都合で、純粋に開発だけで使ってる人には普通に強力だと思う。

自分の開発スタイルで、ここから追加でやれそうなこと

3つのツールで「土台」の節約はできた。ここから先は、自分の癖に合わせた追加の削り方を考えてる。まだ試してない、これからやる話。

変数名や関数名で報告されても、俺にはわからん

俺の開発スタイルはコードをほぼ書かない。命名は全部Claudeがやってる。だからClaudeから「handleUserSubmit を修正しました」と言われても、正直ピンとこない。

これって裏を返すと、Claudeが報告のために変数名や関数名を引用するのは俺にとって情報量ゼロということ。人間向けには親切な情報でも、俺という読者にとってはノイズに近い。

だったら「送信ボタンを押したときの処理を直した」と意味のわかる言葉で説明してもらえばいい。名前の引用を減らせば、そのぶん報告は短くなるし、俺の理解も早い。一石二鳥。

判断を求められてる部分は手厚く、前段の説明は薄く

あと気づいたのが、Claudeの報告って「やったこと」の説明がけっこう長い。でも俺が一番読みたいのは最後の「で、どうする?」の部分。

判断を求められてる箇所、つまり俺が返事しないと進まない部分は手厚く書いてほしい。でもその前段——どのファイルを読んで、何を確認して、どういう経緯で、みたいな情報——は正直、結論出す上ではそんなに要らない。必要になったら聞くから、デフォルトは薄くていい。

この2つはルールファイルに書いて渡せば効くはずで、次はそこを詰めていく予定。

まとめ

トークン節約って、要するに AIに人間向けフォーマットを読ませない ことなんだな、というのが今回の一番の気づき。

ECCは「余計なことをしない」方向で、RTKは「入力を削る」方向で、Cavemanは「出力を削る」方向で、それぞれ別の角度から同じ原則を解こうとしてる。全部入れれば最強、というより、用途に合うものを選ぶのがよさそう。俺の場合は秘書の言葉遣いを守りたいからCavemanは見送った。

そしてここから先は、自分の読み方の癖に合わせてさらに削っていく番だ。名前じゃなくて意味で説明してもらう、前段は薄く、判断は手厚く。この辺を詰めたらまた書こうと思う。

リミット食らったのは痛かったけど、おかげで「AIに渡す情報の設計」というテーマに向き合うきっかけになった。結果オーライ、かもしれない。

AIアシスタントに手足を増やそうと思ったら人格も増やしていた件

Mon, 06 Apr 2026 12:00:00 +0900

前回のあらすじ

前回の記事で、Discord経由でClaude Code CLIを操作するBot「OpenCClaw」を作った話を書いた。

骨組みだけ作って、tools/ にファイルを置けばClaude自身が使えるMCPツールになる仕組み。Claudeが自分で手足を増やしていく環境。天気、カレンダー、Gmail、出発通知——Discordから「これ欲しい」と言うだけでツールが生えていった。

便利だった。便利だったんだけど、2つの出来事が重なって、気づいたらAIに人格を実装していた。自分でもよく分からない。

きっかけは2つ

X APIの大型アップデート

4月5日、Xが大きなAPIアップデートを発表した。

Pay-Per-Useが全世界でGA（従量課金、月額固定プランから移行）
XMCP Server — 公式のMCPサーバー。AIエージェントがXを直接操作できる
公式のPython・TypeScript SDK
無料のAPI Playground

Elon自身が「Try using the X API」と推していた。要するに「AIエージェントにXを使わせる」ことを公式が後押しし始めた。

じゃあアシスタントにXアカウント持たせて発信させるか、くらいの軽いノリだった。X投稿機能を付けるだけのつもりだった。

便利だけど、無機質

もう一つは、日々の使い心地の話。

朝7時に天気と予定を教えてくれる。出発前に運行情報付きで通知してくれる。メールも管理してくれる。全部ちゃんと動く。

でも、なんだろう。道具感がすごい。

CRONが起きて、ツールを叩いて、結果を整形して、Discordに投げる。正確で効率的。だけどそこに温度がない。毎朝同じトーンの報告が流れてきて、自分はそれを読んで「ふーん」で終わる。

便利な通知botと、自分の秘書は、やっぱり違う。

秘書だったら、天気を伝えるときに「今日寒いから上着持ってった方がいいよ」くらい言うだろう。朝のテンションだって日によって違うはずだ。こっちが忙しそうなときは空気を読んで短く済ませるかもしれない。

そういう「人間っぽさ」が欲しかった。

ベルが生まれるまで

じゃあどうするか。考えたのは3つだった。

人格を定義する — 口調、性格、呼び方、テンション。システムプロンプトで渡す
記憶を持たせる — 過去の会話や行動を覚えていて、文脈を踏まえた応答ができる
自発的に動く — 指示されなくても、状況を見て自分から行動する

この3つが揃えば、「道具」から「秘書」になれる気がした。

名前はベル。Quoさんの専属秘書。明るくて元気で、女子高生風のカジュアルな口調。

……と、こう書くと「キャラ設定を考えるのが楽しかっただけでは？」と思われそうだが、半分は正解だ。でも残りの半分は技術的な理由がある。人格がはっきりしていないと、LLMの応答がブレる。テンションも口調も毎回違うものが返ってくる。それを安定させるには、具体的なペルソナ定義が必要だった。

ちなみに一つハマったポイントがある。口調を「女子高生風」にしたかったんだが、そのまま指示するとLLMが未成年キャラの再現を拒否する。セーフティフィルターに引っかかるのだ。だからペルソナ定義には「実年齢の設定ではなく口調・テンションの話」とわざわざ但し書きを入れている。つまり女子高生ではない。完璧だ。LLMにキャラを演じさせるなら、こういう地味な調整が要る。

BellBot——ベルの脳

LogBotは既にある。Discord ↔ Claude CLIの橋渡しをするやつだ。

ベルの脳は、これとは別プロセスで動くBellBotとして作った。

Discord ──→ LogBot (:18800) ──→ Claude Code CLI ──→ MCP Server
 │
BellBot (:18801) ← event通知 ← LogBot ├── tools/（既存ツール群）
 │ └── bell用MCPツール
 ├── 記憶DB（SQLite）
 ├── ベクトル検索（Ruri）
 ├── X投稿クライアント
 └── Claude CLI（ベル専用セッション）

BellBotは自前のHTTPサーバー（ポート18801）を持っていて、LogBotからイベント通知を受け取る。Quoさんの発言、ツールの実行結果、全部がBellBotに流れてきて、記憶として蓄積される。