Claude Code on Claude Code 始めました

Throughline を npm に公開した — Claude CodeのツールI/OをSQLiteに退避するhook

Sat, 18 Apr 2026 12:00:00 +0900

Throughline っていうClaude Code用のhookプラグインをnpmに公開した。

何をするか

Claude Codeのセッションで、コンテキストの大半は「ツールI/O」の残骸で埋まってる。ファイルを読んだ中身、grepの結果、Bashの出力。AIがその場で使って、判断して、次に進んだ時点で役目を終えてるデータ。でも最後までコンテキストに居座ってトークンを食い続ける。

Throughlineは会話を3層に分けて管理する。

層	中身	コンテキストへの注入
L2	会話本文（ユーザー発言 + AI応答）	直近20ターンはそのまま注入
L1	L2を要点を欠落させない程度（1/5）に要約したもの	20ターンより古いターンはL1を注入
L3	ツールI/O・システムメッセージ・thinking	注入せずSQLiteに退避、必要になったらClaude自身が取り出す

ツールI/Oはコンテキストから完全に抜くので、読み終わったgrep結果やBash出力がセッション最後まで居座らない。古い会話は1/5に圧縮されるが要点は残るので、数十ターン前の判断の文脈もちゃんと追える。

手元の50ターンセッションで実測すると、125,000トークン使ってた会話が、13,000トークンに収まる。

インストール

npm install -g throughline
throughline install

install は ~/.claude/settings.json にhookを登録する。PC内の全Claude Codeプロジェクトで自動で動く。プロジェクトごとの設定は不要。

セッション間の引き継ぎ

Throughlineは会話をSQLiteに退避してるので、/clear してもデータ自体は残ってる。次のセッションに記憶を持ち越したい時は、前のセッションで /tl って打つ。

/tl を打った時だけ、次のセッションに引き継がれる。打たなければ新規セッションとして始まる。並行ウィンドウを開いても、VSCodeを再起動しても、「/tlを打たない限り誤爆しない」ようにできてる。

引き継ぎ時には、前のClaudeが書いた「次の一手メモ」と、最終ターンの内部推論（thinking）も一緒に渡る。次のClaudeは「過去ログを読む」じゃなく「中断地点から続ける」モードで動く。

トークンモニター

副産物として、マルチセッション対応のトークンモニターもついてくる。

throughline monitor

[Throughline] 1 セッション
▶ Throughline 2ed5039c ████░░░░░░░░░░░░░░░░ 205.1k / 21% 残 794.9k claude-opus-4-6

transcriptのJSONLからAPIの実測値（message.usage）を読むので、文字数÷4の推定じゃなくて正確な値が出る。1Mコンテキストの自動検出にも対応。

要件

Node.js 22.5+（node:sqlite 組み込みモジュールを使うため）
Claude Code（hooks対応）
Claude Max契約（L1要約のHaiku呼び出しに使う、APIキーは不要）
Windows / macOS / Linux

依存関係

ゼロ。npmに公開してるtarballは .mjs ファイルだけ。ビルドもネイティブバインディングも不要。

Claude Codeの"続きから"を実装するのに、自動検知を諦めた話

Sat, 18 Apr 2026 09:00:00 +0900

前の記事でThroughlineを公開した。コンテキストの大半を占めてるツールI/Oを退避するやつ。

あの時点では"動いてた"。自分の環境では。

でも記事を出した直後から、おかしな挙動に気づき始めてた。

並行で別のウィンドウを開くと、新しいセッションが前のセッションの記憶を勝手に拾う。VSCodeを再起動すると、毎回「前回のセッションから続き」扱いになる。一度も /clear してないのに。

原因: /clear を検知できない

Claude Codeのhookには SessionStart ってイベントがあって、source っていうフィールドで startup（新規起動）と clear（/clear後）を区別できる、はずだった。

ところがVSCode拡張だと、/clear しても source が startup に潰される。GitHub issue #49937 に上がってる既知の問題。CLI単体なら動くけど、拡張だと識別できない。

自分はVSCode拡張で使ってる。つまり「startupとclearを区別する」前提の設計が、根本から崩れてた。

ヒューリスティックで補おうとした

じゃあ時間差で判定するか。前のセッションの最終活動から10秒以内ならclear、それ以上ならstartup、みたいな。

これも壊れた。

並行でウィンドウを2つ開いてると、両方が"最近活動してた"ので両方が継承先候補になる
VSCode再起動でもtranscriptは残ってるので"最近"に見える
プロセスツリーを追いかけようとしたけど、CLIとextensionでプロセス構造が違う

“そもそも検知できる条件が無い"と気づいた。

発想を変えた

検知しようとするから失敗する。ユーザーが宣言すれば、検知はいらない。

作ったのが /tl ってスラッシュコマンド。ユーザーが次のセッションに記憶を引き継ぎたい時だけ打つ。打つと handoff_batons ってテーブルにそのセッションIDが書き込まれる。バトンを置くイメージ。

次のセッション開始時、バトンが1時間以内に置かれてたら、そのセッションの記憶を引き継ぐ。なければ、何もしない。新規セッションとして始まる。

並行ウィンドウもVSCode再起動も、「バトンが置かれてない限り誤爆しない」が原理的に保証される。

明示的なのは一見面倒だけど、「勝手に引き継いで迷惑」の方が遥かに困る。誤爆ゼロの方が価値があった。

でも、これだけじゃ物足りなかった

バトンができて、次のセッションが前のセッションの会話ログを読めるようになった。でも実際に使ってみて思ったのが、「ただログを読んでるだけ」感。

過去ログを読むAIと、中断地点から続けるAIは、体感が違う。

前者は「よし、状況を把握した。じゃあ今から何をしましょうか？」って聞いてくる。後者は「さっきの続きだと、あと◯◯を確認すればいいよね」って進める。

ここで2つ足した。

in-flight memo. /tl を打った瞬間、今動いてるClaude自身に「次の一手、今の仮説、未解決の問題、進行中のTODO」をMarkdownで書いてもらう。それをバトンに添付する。

thinkingの保存. Claudeのextended thinking（内部推論）ブロックもL3として保存しておく。次のセッションの注入時、最終ターンのthinkingを頭に出す。前のClaudeが何を考えてたかが、次のClaudeに渡る。

結果、次のセッションの注入テキストはこういう形になる。

あなたは中断されたタスクを再開します。

[前のClaudeが書いた in-flight memo]
次やること: X のテストを書く。仮説: Y が原因だと思う。未解決: Z。

[前のClaudeが最後に考えてたこと]
Z の挙動が気になる。もしかしたら...

[直近20ターンの会話]
...

“読む"じゃなく"続ける”

これで手応えが変わった。

コンテキストの87%が使い捨てだったので自分で対策した話

Thu, 16 Apr 2026 00:00:00 +0000

MAXプランの週間クォータが3日で溶けた。

×20のクォータがあるはずなのに、水曜には残量が怪しくなってる。それ自体は「まあそんなもんか」で済ませてたんだけど、ふと気になった。コンテキストウィンドウの中身って、実際どうなってるんだろう。

前の記事ではAI秘書のトークン節約について書いた。CLAUDE.mdを削ったり、MCPツール定義を削ったり。でも今回はAI秘書じゃなくて、Claude Code自体の話。道具のほうが大食いだったとは。

きっかけ

4月14日、スペイン語圏のあるツイートが目に留まった。

「Claude Codeのトークン浪費の大半はユーザー側に原因がある」

言いたいことはわかる。CLAUDE.mdが肥大化してるとか、プロンプトが冗長だとか。でも「大半がユーザー側」って、ちゃんと測って言ってるのか？

じゃあ俺が測ってやる、と思った。

実測してみた

Claude Codeの内部transcript（セッションを記録してるJSONL）を解析した。

1ターンあたり188,000トークン。うち164,000トークン（87%）が会話履歴。

CLAUDE.mdは12,700トークン。MCPツール定義は3,900トークン。合わせても全体の9%。これを半分にしても5%弱しか浮かない。

本丸は会話履歴の肥大化だった。CLAUDE.mdを必死に削ってた自分がちょっと恥ずかしい。

犯人はツールI/O

じゃあ履歴の中身は何か。

開いて驚いた。履歴の約80%がツールの入出力だった。 ファイルの読み取り結果、Bashコマンドの出力、grepの結果。AIがその場で使って、判断して、次に進んだ時点で役目を終えてるデータ。

なのに、それがコンテキストウィンドウにずっと居座って、毎ターントークンを食い続けている。

50ターンのセッションだと、最初のほうにgrepした結果がまだコンテキストにいる。もう二度と見ることはないのに。

/compactの矛盾

「/compactすればいいじゃん」って思うかもしれない。自分もそう思ってた。

でも/compactの仕組み、AIに全履歴を読ませて要約させるんだよね。

トークンを節約するために、トークンを大量に消費する。しかも要約の過程でニュアンスが消える。「あの時なぜこの設計にしたか」みたいな文脈が、丸められて消えることがある。

要約後にまた作業を続ければ、また肥大化して、またcompactして…の繰り返し。根本解決じゃない。

時間じゃなく、種類で分ける

ここで発想を変えた。

MemGPTやLangChainのSummaryBufferMemoryは、古いものから要約する。時間ベースの圧縮。でも問題は「古さ」じゃない。

10ターン前の「この設計にした理由」は今でも価値がある。さっきのgrepの結果は、1ターン前でも用済み。

時間じゃなく、種類で分ければいい。

会話本文（人間が書いたこと、AIが答えたこと）→ 残す
ツール入出力（ファイル内容、コマンド結果）→ 退避する

この発想で作ったのがThroughlineだ。

3層モデル

Throughlineは会話を3つのレイヤーに分解してSQLiteに保存する。

L1（Skeleton） — 古いターンの一行要約。軽量モデルが生成する。1ターン約10トークン。

L2（Body） — 直近20ターンの会話本文。ユーザーの発言とAIの応答がそのまま残る。圧縮なし、ロスレス。

L3（Detail） — ツール入出力、システムメッセージ。SQLiteに退避してコンテキストには一切残さない。必要になったらAIが自分でSQLiteから引っ張ってくる。

/clearを打っても大丈夫。SQLiteは消えないから、次のセッション開始時にトランザクション一発で前セッションの記憶を引き継ぐ。PIDを追いかけたり、時間窓で判定する必要はない。決定的に動く。

数字で言うとこう。

Throughlineなし（50ターン、/clearなし）：
 コンテキスト ≈ 125,000トークン（80%が用済みのツールI/O）

Throughlineあり（50ターン → /clear → 復帰）：
 コンテキスト ≈ 13,000トークン
 （直近20ターンのL2 + 古い30ターンのL1要約）

約90%の削減。

失敗した設計の話もしておく

最初からこの形だったわけじゃない。

初期の設計では、L2を「重要な判断の構造化抽出」にしようとした。[DECISION] WebSocketを採用、[CONSTRAINT] ポート8080は使えない みたいなタグ付きで、会話から重要な情報だけ引き抜くイメージ。

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

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に流れてきて、記憶として蓄積される。

手足を勝手に増やすAIアシスタントを作った話

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

はじめに

Anthropicの規約変更で、サードパーティのハーネスからClaude系のサブスクOAuth利用がブロックされた。世の中はそこそこ騒いでいたが、正直なところ、俺にはあんまり関係のない話だった。

Claude Code CLIは手元にある。Discordに投げたメッセージをCLIに渡して、返事をDiscordに返す。それだけの橋を架ければいい。

だから作った。

骨組みだけ作った

作ったのはLogBot。Discord上のメッセージをClaude Code CLIに転送して、応答をDiscordに返す。それだけのBot。

Discord ──→ LogBot ──→ Claude Code CLI
 ↑ │
 └── 応答を投稿 ──┘

最低限の骨組みとして、こんな機能を持たせた。

セッション管理 — UUIDベースでClaude Codeのセッションを維持。VSCodeのセッションとは完全に分離される
メッセージキュー — Claudeが処理中にメッセージが来てもキューに溜めて順番に処理。取りこぼさない
承認フロー — Claudeがファイルを編集しようとしたら、Discordに通知が飛んで、リアクション（✅ / ❌）で承認か拒否を返せる
MCPサーバー — tools/ ディレクトリにファイルを置けば、Claude側からツールとして使える

ここで大事なのは、MCPツールは最初ゼロだったということ。天気もカレンダーも電車情報も、何もない。ただの骨組み。

でも、この骨組みには一つだけ強烈な特性がある。

Claudeはファイルを書ける。 つまり tools/ にJavaScriptファイルを追加できる。MCPサーバーは tools/ 配下を自動スキャンして登録する。

Claudeが自分で自分の手足を作れる。

「時計が欲しい」から始まった

最初にDiscordからClaudeに頼んだのは些細なことだった。

「今何時？」

Claude Code CLIはシステムの時刻を取れるが、MCPツールとして切り出されていたほうがスマートだ。Claudeに「時刻を返すMCPツールを作ってくれ」と頼んだ。

数秒で tools/current-time.js が生えた。

次は「天気が知りたい」。Open-Meteoという無料の天気APIを使った tools/weather.js が生えた。APIキーすら不要。

「Googleカレンダーの予定を見たい」。OAuth認証のヘルパーごと、tools/gcal-auth.js と tools/gcal-list.js が生えた。

「Gmailも読みたい」。同じ要領で、認証・一覧・本文読み取り・送信・フィルタ・一括削除まで、Gmailツール群が一式生えた。

全部、Discordから「これ欲しい」と言っただけだ。自分はコードを一行も書いていない。

CRONが叩くのはコードじゃない

ツールが揃ってくると、次に欲しくなるのは定期実行だ。

「毎朝7時に天気と電車の運行情報と今日の予定を教えてほしい」

ここで普通なら、天気APIを叩いてカレンダーAPIを叩いて運行情報をスクレイピングして整形して送信する、というスクリプトを書いてCRONに登録する。

でもせっかくClaude使うんだから、コードじゃなくてプロンプト渡した方が面白い。

AIにサーバーを任せて3日間で起きたこと

Sat, 04 Apr 2026 00:00:00 +0000

はじめに

前回の記事で、自宅サーバーの管理をAIに丸ごと任せた話を書いた。深夜にAIがパトロールして、昼間は監視スクリプトが異常を検知したらAIが出動する仕組みだ。

仕組みを作った話はした。では、実際に動かしてみてどうだったか。3日間の運用で起きたことを書く。

監視スクリプトが自分自身を壊した

運用3日目の朝、監視スクリプトが異常を検知した。license_api_prodコンテナが応答しない、と。

AIが出動して調査を始めた。SSHでサーバーに接続して、コンテナの状態を確認する。結果——コンテナは正常に動いていた。

誤検知だった。しかも2分後、今度はddnserでも同じ誤検知が出た。

原因：SSH接続の開きすぎ

AIが突き止めた原因はこうだ。

監視スクリプトは60秒ごとにサーバーの状態をチェックする。システムリソース（ディスク、メモリ、スワップ）で3本、7つのコンテナのヘルスチェックで最大9本。合計10本以上のSSH接続を同時に開いていた。

OpenSSHにはMaxStartupsという設定がある。同時接続数の上限だ。デフォルトは10。監視スクリプトがこの上限を超えていて、接続が弾かれていた。つまり、監視スクリプト自身がサーバーに負荷をかけて、自分のSSH接続を失敗させていた。

1回目の修正：並列を直列に

AIはヘルスチェックの実行方式をPromise.allSettled()による全並列からfor...ofによる順次実行に変更した。SSH接続が同時に1本しか開かれなくなった。

2回目の修正：リトライの追加

直列にしても、一時的なSSH切断は起こりうる。サーバー側の負荷やネットワークの瞬断で、1回だけ接続が切れることはある。

2分後の2回目の誤検知を受けて、AIは「SSHトランスポートエラー」を判別するヘルパー関数を追加した。Connection closed、Connection refused、ETIMEDOUTなどのパターンを検出して、3秒待ってから1回リトライする。リトライ後も失敗した場合だけ異常として報告する。

修正は2段階。並列→直列でSSH接続数を削減し、リトライで一時的な切断に対応。 どちらも人間の介入なし。Discordに「修正しました」と通知が来て、それで終わりだ。

深夜パトロールが見つけたもの

毎日深夜4時にAIがサーバー全体を巡回する。セキュリティ設定、リソース使用量、コンテナの構成、ログの中身。人間が日常的にチェックしない部分を、AIが代わりに見る。

Nextcloudのログが21GB

運用2日目のパトロールで、AIがNextcloudのログファイルの異常に気づいた。

/var/mnt/nextcloud_data/nextcloud.log — 21.3GB。

ログファイルが21GBに膨れ上がっていた。NFS上にあるためディスクの逼迫は起きていなかったが、ログローテーションが機能していない。自分では気づけなかった。

SELinuxの拒否ログが1,241件

もう一つ。SELinuxがauction-botのauction.dbに対するlockアクセスを毎分拒否していた。過去24時間で1,241件。

SELinuxはPermissiveモードで動いているので、実際にブロックはされていない。アプリは正常に動く。ただ、拒否のたびにsetroubleshootというデーモンが起動して分析を行い、CPU 22.9%を一時的に消費していた。

実害はないが、無駄にリソースを食っている。AIが見つけなければ、ずっと放置されていたと思う。

日々の定点観測

パトロールは毎日サーバー全体を見て回る。何を見るかもAIが判断するが、結果として日をまたぐとトレンドが見えてくる。

スワップ使用率の推移

日付	スワップ使用率	備考
4/2	89%
4/3	92%	微増傾向
4/4	62%	サーバー再起動でリセット

スワップが日々積み上がっていく傾向をAIが追跡していた。4/4にサーバーが再起動されてリセットされたが、再起動なしの長期稼働ではスワップが逼迫する可能性がある。AIはレポートに「継続監視が必要」と毎回書いている。

fail2banのBAN推移

日付	現在BAN中	累計BAN
4/2	14 IP	235
4/3	10 IP → 14 IP	242 → 293
4/4	8 IP	—

SSHへのブルートフォース攻撃が日常的に来ている。admin、ubuntu、mysqlといった汎用ユーザー名での接続試行。fail2banが淡々とBANしている。パスワード認証は無効で鍵認証のみなので突破はされないが、攻撃が来ていること自体は知っておきたい。AIがレポートで毎日報告してくれる。

サーバー管理をAIに丸ごと任せてみた話

Fri, 03 Apr 2026 00:00:00 +0000

はじめに

以前の記事で、AIにSSHでサーバーを直接触らせたら楽だったという話を書いた。デプロイスクリプトを作らせて、ビルドからコンテナ更新まで一発で終わるようにした。

その後、自分専用のBotをSaaS化した。これも本番は自宅サーバーで動いている。

ここまで来ると、次に思うことは一つだ。運用も任せたらいいんじゃないか？

問題があったら直させればいい

AIはコーディングが得意だ。セキュリティの知識もある。サーバーの設定も読める。

だったら、サーバーに問題が起きた時に、AIに調べさせて、直させて、デプロイまでやらせればいい。人間が夜中に叩き起こされてログを読む必要はない。

もう一つ、大事な理由がある。

自分がコードベースで指示したら、自分の知識の範囲内の行動しかしてくれなくなる。 セキュリティの設定をどうすべきか、コンテナの構成に問題がないか——正直、自分よりOpusのほうが詳しい。だから細かい手順を指示するのではなく、Opusの自律的な判断に委ねることにした。

仕組み

作ったのは、Electronのタスクトレイに常駐する監視アプリだ。

昼間 — 軽量監視

AIをずっと動かすとMAXプランの使用量を食う。だから昼間はAIを使わない。

代わりに、監視スクリプトが60秒ごとにSSHでサーバーの状態をチェックする。コンテナが動いているか、HTTPのレスポンスが返ってくるか、データベースに接続できるか。異常を検知したらまずコンテナの再起動を試みて、それでも駄目ならAIを起動する。

深夜 — AIのフルパトロール

毎日深夜4時に、AIがサーバー全体を巡回する。セキュリティ設定、リソース使用量、コンテナの構成。昼間の監視スクリプトでは拾えない問題を、AIの目で洗い出す。

なぜ深夜か。MAXプランの使用量は時間経過で回復する。深夜に使っても自分が起きた頃には回復しているし、使わなければその枠は無駄になるだけだ。有効活用しない手はない。

監視スクリプトもAIが作る

面白いのは、監視スクリプト自体もAIに作らせていることだ。深夜のパトロール時に、サーバーの構成を見て、何をどう監視すべきかをAI自身が判断して、スクリプトを生成・更新する。

自分が「このポートを監視しろ」と指定するのではなく、AIが「このコンテナにはこのチェックが必要だ」と決める。さっき書いた通り、自分の知識に閉じたくないからだ。

3層のエージェント構造

異常が検知されてAIが動き出すとき、1つのAIが全部やるわけではない。役割を3層に分けている。

親エージェント — 症状を検知して、どのアプリに問題があるかを特定する。ここで大事なのは、親は症状だけを渡すということだ。「コンテナが落ちた」「HTTPが500を返した」という事実だけ。なぜ落ちたか、どう直すべきかは親が判断しない。

子エージェント — 該当アプリのプロジェクトで起動して、原因を調査し、コードを修正し、テストして、デプロイする。症状から原因を特定するのは子の仕事だ。

孫エージェント — 子が立てた修正方針を監査する。「この修正で別の問題が起きないか」をチェックしてから、実行に移る。

なぜ親が診断しないかというと、子のほうがそのプロジェクトに詳しいからだ。子は該当アプリのプロジェクトフォルダで起動するので、CLAUDE.mdもコードも全部読める。親はサーバー全体を見ているだけで、個々のアプリの内部構造は知らない。親が原因まで推測すると、その推測に引っ張られる。だから症状だけ渡して、現場に判断させる。

実際に起きたこと

先日、監視スクリプトがエラーを検知した。AIが出動して調査を始めた。

結果：監視スクリプト自身のバグだった。

AIが作った監視スクリプトのエラーを、AIが自分で見つけて、自分で直した。人間は何もしていない。Discordに「修正しました」と通知が来て、それで終わりだ。

笑い話みたいだが、これは仕組みがちゃんと動いている証拠でもある。完璧なスクリプトを最初から書く必要はない。問題が起きたら直す——そのループが自動で回っている。

自分のサーバーだからできること

こういう話をすると「無責任だ」と思う人もいるだろう。セキュリティを商売にしている人から見れば、AIに判断を丸投げするなんて、とんでもないかもしれない。

でも俺は個人開発者だ。自分のサーバーで、自分のサービスを動かしている。セキュリティやサーバー管理の知識は、正直、自分よりOpusのほうが持っている。自分より詳しいやつに頼るのは、無責任ではなく合理的だと思っている。

もちろん、これを他人に配る気はない。自分のサーバーだから好きにできるが、他人のサーバーをぶっ壊したら洒落にならない。「自分用」と割り切っているからこそ、AIに任せきれる。

おわりに

SSHでサーバーを触らせるところから始まって、デプロイを任せて、SaaS化を任せて、今は運用まで任せている。

できるだけ自分の知識で縛らず、AIの判断に委ねる。そうすると、自分が知らなかった問題をAIが見つけて、自分では書けなかった修正をAIが入れてくれる。自分で監視スクリプトを書いていたら、そのバグには気づけなかった。

個人開発者がサーバーを運用するのは大変だ。でも今は、深夜のうちにAIが見回ってくれる。朝起きたらDiscordに「異常なし」と来ている。それだけで安心して寝られる。

指示を細かく書くより、任せたほうがうまくいく。そういう付き合い方が、だんだん見えてきた。

5年育てた自分専用Botを、SaaSにして売り出した話

Wed, 01 Apr 2026 00:00:00 +0000

はじめに

俺はMMOゲームのギルドで、オークションBotを5年間使ってきた。

Lineage2Mが2021年にリリースされた頃から、ギルドのボスドロップ分配を自動化するために作ったDiscord Botだ。HIT The Worldでも使った。メンバーが入札して、最高額をリアクション参加者で割って分配する。手作業でやるとスプレッドシートとにらめっこになるやつを、Botに全部やらせていた。

5年間、自分のギルドでずっと動いていた。便利だった。でも、あくまで自分専用だった。

「自分専用」の実態

5年も育ててきたとはいえ、中身はひどいものだった。

ギルド名がハードコードされている。タイムゾーンは決め打ち。言語は日本語しかない。設定ファイルなんてものはなく、変えたい値はソースコードを直接書き換える。

複数のサーバーで使いたい時は、コンテナごとコピーしていた。 同じBotをもう一個立てて、トークンだけ変えて動かす。マルチテナント？なにそれ。

課金システムなんてもってのほかだ。サブスクリプションも、利用規約も、決済画面もない。誰かに売るなんて想定していない。自分が使えればそれでよかった。

SaaS化を決めた理由

ふと思った。このBot、売れるんじゃないか。

多くのMMOギルドが同じ課題を抱えている。ボスのレアドロップが出た。誰が取る？オークションで決めよう。でもオークションの管理は面倒すぎる。入札を手動で集計して、分配金額を計算して、結果を全員に通知する。やりたいけど、手作業じゃ無理——そういうギルドは多い。

ただ、自分専用Botをサービスにするには巨大な改修が必要だ。マルチテナント化、課金、管理画面、多言語対応、法的対応。自分の手でやる気力はまったく起きない。

でも今はAIコーディングの時代だ。不確定要素がない決まった作業なら、AIに一気に終わらせてもらえる。研究や実験と違って「調べてみないとわからない」がないやつ。そう踏んで、やることにした。

コードの改修

マルチテナント化、Stripe課金連携、OAuth2認証、Web管理画面、4言語対応。やることリストは長かったが、どれも定型作業だ。パターンは決まっているし、公式ドキュメントもある。ゴールは明確だ。

設計方針を決めて、実装はAIに任せた。一つ一つは別に難しくないが、量が膨大で、手作業で片付ける気にはならない類の作業だ。

最初にClaudeが出してきた方針が「856行のserver.jsを8モジュールに分割して、ギルドごとに設定を持てる構造にする。大改修です」だった。脅されたが、もともと動いていたプログラムで動作のロジックは明確だし、上に書いた通り不確定要素がない。案外あっさり終わるんじゃないかと期待していた。AIが得意な仕事なんじゃないかと。

実際、コードの改修は1日で終わった。

大変だったのはコードの外側

コードの改修より、「商品にする」ための作業のほうがよほど考えることが多かった。

法律

サブスクリプションでお金を取るなら、特定商取引法に基づく表記が必要になる。利用規約も書かなきゃいけない。消費者契約法に配慮した免責条項、返金ポリシー、個人情報の取り扱い。個人開発者がサービスを売る時に避けて通れない部分だ。

これもAIと一つずつ潰していった。「特商法に何を書くべき？」「この条項いる？」と相談しながら、最終的に全17条の利用規約ができた。法律の専門家ではないから正確さの保証はできないが、少なくとも「何も考えてない」状態からは脱出できた。

Stripeの審査

決済にStripeを使っているが、本番環境で動かすにはStripeの審査を通す必要がある。セキュリティがちゃんとしているかもチェックされる。

そこでAIにプロジェクト全体のセキュリティ監査をさせた。13件の指摘が出た。JWT有効期限チェックの欠落、OAuth2のオープンリダイレクト脆弱性、オークション終了の二重通知、APIのレート制限なし——自分では気づけなかったものも含めて、全部その場で修正させた。

5年間「自分しか使わないから」で見て見ぬふりをしてきた部分が、商品にする段階で一気に表面化した。

デプロイ

Botの本番デプロイには、自宅サーバーを使っている。以前の記事で書いた通り、AIにSSHでサーバーを直接触らせるスタイルだ。deploy.shを一発叩けば、ビルドからコンテナ更新まで全部終わる。

Web管理画面はVercelにデプロイ。こっちはgit pushだけ。

AuctionBOT

5年間、自分のギルドだけで動いていたBotが、今日からサービスとして公開された。

AuctionBOT — DiscordでギルドオークションをBotが全自動管理する。

/setup でチャンネルを自動作成、/auction でオークション開始
メンバーがリアクションで参加登録、数字を投稿して入札
終了後、落札額 ÷ 参加人数を自動計算して分配結果を通知
スナイプ防止（終了間際の入札で自動延長）
4言語対応（英語・日本語・韓国語・中国語）
Free（1同時オークション）/ Pro（月500円、無制限）

ボスドロップの分配で揉めてるギルド、手作業の集計に疲れてるギルドリーダーがいたら、試してみてほしい。

おわりに

コードの改修は、正直AIに任せたら終わる時代になった。マルチテナント化も課金連携も多言語対応も、パターンが決まっている作業は一気に片付く。

でも「商品にする」のは、コードだけじゃ終わらない。法律、セキュリティ、値付け、ランディングページ。自分で判断しなきゃいけないことが山ほどある。AIは相談相手にはなるが、最終的に決めるのは自分だ。

5年間、自分だけが使ってきたツールが、今日から他の誰かに使ってもらえるものになった。売れるかどうかはわからない。でもまあ、出さなきゃ始まらない。

サーバーに実装する時にClaudeにSSH使わせたら驚くほど楽だった話

Wed, 01 Apr 2026 00:00:00 +0000

はじめに

AIにコードを書かせるのはもう慣れた。設計は自分でやって、実装はClaudeに任せる。いつものスタイルだ。

ただ、作ったものを自宅サーバーに載せる作業——デプロイは、自分の手でやるもんだと思っていた。Dockerでイメージをビルドして、サーバー側でpullして、コンテナ外にSQLiteのDBを置いて、.envを設定して、パーミッションを整えて。地味で面倒だが、こればっかりは手作業だろうと。

そう思い込んでいた。

コピペ相談の限界

以前はサーバー側でトラブルが起きたら、ターミナルの出力をコピペしてAIに聞いていた。

Nextcloudを自宅サーバーに入れた時がひどかった。パーミッション周りのエラーが出て、GPT-5.4に相談したんだが、延々とループした。「このディレクトリの権限を変えてみてください」→ 変えた → 別のエラー → 「じゃあこっちも」→ 変えた → 最初のエラーに戻る。

最終的にClaudeにも手伝ってもらって解決したが、相当時間を使った。

「スクリプト書きましょうか？」

DiscordのオークションBotを自宅サーバーにデプロイする作業をしていた時のこと。

コンテナの更新を何度かやった後、Claudeが聞いてきた。**「コンテナの更新を簡単にするスクリプト書きましょうか？」**と。

いいよ、と返した。

そしたらまず、SSH鍵認証の設定から始めた。鍵の生成、サーバー側のauthorized_keysへの登録。パスワードなしでリモート操作できる環境を整えてから、deploy.shを作った。

それまでは、リモートのターミナルに手でコマンドを打ち込んでいた。エラーが出たらやり直しだし、動いたかどうかの確認もログをコピペして見てたし。面倒だった。

deploy.shの中身はシンプルだ。ローカルでDockerイメージをビルド、GitHub Container Registryにpush、SSHでサーバーに入ってpodman pull（サーバー側はBazziteOSなのでDockerではなくpodman）、古いコンテナを止めて削除、新しいコンテナを起動。DBのボリュームマウントも.envの読み込みも全部入っている。これがスクリプト一発で終わる。

しかもそこから先、起動時にBotがエラーを吐いた時も、ClaudeがSSHでサーバーのログを確認して、原因を特定して、ローカルでコードを直して、deploy.shで再デプロイ。一つのセッションで全部完結した。

コピペと直接触らせるの差

コピペで相談していた頃は、AIはサーバーの状態が見えていなかった。エラーメッセージだけ渡されても、「操作ミスでは？」「環境設定が違うのでは？」という可能性を一個ずつ手動で潰すしかない。人間がコピペで中継する分、遠回りになる。

SSHで直接触らせると、Claudeが自分の目でサーバーの状態を確認できる。推測じゃなくて事実ベースで動ける。

やっていることは ssh user@host "コマンド" をBashから叩いているだけだ。特別な仕組みがあるわけじゃない。鍵認証が通っていれば、Claudeからすると「ちょっと遠いターミナル」でしかない。

怖くないのかという話だが、ポートはSSHと80しか開けていないし、まだ売上もない環境だ。それに、Opusは指示の意図を正確に汲んでくれるから、変なコマンドを叩かれる心配が少ない。これが精度の低いモデルだったら怖いと思う。

まとめ

デプロイは手作業でやるもんだと思い込んでいた。Claudeに「スクリプト書きましょうか？」って言われるまで、任せるって発想がなかった。

このブログ「Claude Code 始めました」は、Claude MAX ユーザーが実際の開発で使いながら学んだことを記録していくサイトです。

自力じゃ無理なロジック、Claudeと論文から組み立てた話

Mon, 30 Mar 2026 00:00:00 +0000

はじめに

AIコーディングでアプリを作っていると、「何を作るか」は自分で決められます。設計も方針も自分で出せます。でも、たまに壁にぶつかります。

やりたいことはあるのに、それを実現するロジックの引き出しが自分にない。

プログラマーでもないですし、信号処理の専門家でもないです。そういう時にClaudeが頼りになった話です。

問題：音声の男女判定がうまくいかない

LiveTR（リアルタイム音声翻訳アプリ）に、話者の性別に応じて読み上げの声を切り替える機能を入れたかったんです。男性の声なら男性っぽく、女性の声なら女性っぽく。

最初に思いつくのは基本周波数（ピッチ）で判定する方法です。男性は低い、女性は高い。シンプル。

やってみました。普通の会話なら、まあまあ動きます。

ところがF1の中継を流してみると、解説者が興奮するたびに女性判定になります。レースが白熱するとピッチが上がるので、男性の声なのに「女性」と判定される。これが頻繁に起きます。

ピッチだけじゃダメです。でも、じゃあ他に何を見ればいいのか。自分にはわかりませんでした。

Claudeに聞いてみました

「音声の性別判定で、ピッチだけだと興奮時に誤判定する。学術的にはどういう手法がある？」

Claudeに調べてもらいました。Researchモード（Claudeが自律的にWebを検索して調査してくれる機能）で学術論文や特許を探させると、自分では辿り着けなかった手法がいくつか出てきました。

ピッチだけじゃなくて、フォルマント（声道の共鳴周波数）やMFCC（メル周波数ケプストラム係数）など、複数の指標を組み合わせることで、興奮状態でも安定した判定ができるそうです。

論文の内容を全部理解したかと言われると、正直怪しいです。でもClaudeが「この手法はこういう原理で、こういう特徴がある」と説明してくれるので、方針は立てられました。そこから自分で「この組み合わせでいこう」と決めて、構成を詰めていきました。

そのまま実装へ

方針が決まったら、あとはClaudeと一緒に組み立てていきました。

「この論文の手法をベースに、こういう構成で実装してほしい」と伝えると、Claudeがコードを書いてくれます。動かして、結果を確認して、おかしければ調整する。いつものサイクルです。

F1の中継でテストしてみたら、解説者が興奮しても男性のまま判定されるようになりました。ピッチだけの時とは安定感が全然違います。

これがAIコーディングの強みだと思います

コードを書いてくれること自体はもう当たり前になってきました。でも、自分の知らない分野の知識を引っ張ってきて、それを実装に落とし込めるのは、また別の価値だと思います。

信号処理の論文なんて自分で探して読む力はないです。でもClaudeに「こういう問題がある」と伝えれば、関連する研究を調べてきて、それを動くコードにしてくれます。

もちろん、出てきたものをそのまま信用するわけじゃないです。動かして、テストして、おかしければ方針から見直す。そこは変わりません。でも、知識のスタート地点がゼロじゃなくなるのが大きいです。

一つ注意。いくら良い成果が得られたとしても、特許を参照して作ったロジックで商売したら、特許権侵害になる可能性があります。論文ベースでも、その手法に関連する特許が存在することはあります。商用利用する場合は、権利関係の確認が必要です。これもClaudeに「この手法に関連する特許はある？」と聞けば調べてくれます。ただ、Claudeの調査が完璧とは限らないので、最終的な判断は自分で行う必要があります。

自分はコードを書く側の人間じゃない。設計して、方針を決めて、判断するのが自分の仕事。Claudeは知識を引っ張ってきて、それを動くコードにしてくれる。今回はこの役割分担がきれいにハマった例だと思う。

このブログ「Claude Code 始めました」は、Claude MAX ユーザーが実際の開発で使いながら学んだことを記録していくサイトです。

LiveTR — 動画の英語音声をリアルタイムで日本語にするアプリ

Sun, 29 Mar 2026 00:00:00 +0000

LiveTRとは

PCで再生中の動画の英語音声をリアルタイムに認識して、日本語に翻訳するWindows用アプリです。翻訳結果は字幕として画面にオーバーレイ表示され、日本語で読み上げもしてくれます。

YouTube、Twitch、ローカル動画ファイル。英語の音声が流れていれば、ソースは問いません。

主な機能

リアルタイム音声認識 — faster-whisperで英語音声をその場で文字起こしします
日本語翻訳 — オンライン翻訳サービス（Google Cloud、DeepL、Azure、Amazon）に対応しています
字幕オーバーレイ — 翻訳結果を透過ウィンドウで表示します。位置やサイズは調整可能で、クリックは透過します
日本語読み上げ — AivisSpeechで翻訳結果を読み上げます。話者の声質を自動で反映します
自動ダッキング — 読み上げ中は動画の音量を自動で下げて、聞き取りやすくします
プロセス単位の音声キャプチャ — 指定したアプリの音声だけを拾います。読み上げ音声を再キャプチャするループも防止しています

使い方

アプリを起動します
音声をキャプチャしたいプロセスを選択します
「開始」を押すと、音声認識・翻訳・字幕表示・読み上げが始まります

動作環境

Windows 10 / 11（64bit）
NVIDIA GPU（CUDA 12.x対応）
メモリ 16GB以上推奨

GPU必須です。音声認識モデルをリアルタイムで回すので、それなりのスペックが要ります。

開発の話

Claude Codeだけで作りました。期間は約4日。

OLTranslatorが画面のテキストを翻訳するアプリだったので、「じゃあ音声も同じことできないか」と思って作り始めました。OLTranslatorはCopilotで2週間かかったので、それと比べるとかなり速い。もちろん自分がAIコーディングに慣れてきた部分もあるが、CLAUDE.mdでプロジェクトの方針を引き継げることと、設計→指示→レビューのサイクルがClaude Codeだと自然に回るのが大きかった。

こだわったところ

音声認識で拾った文を、どこで切って翻訳に回すか。一文をどこで区切るか、途中で切られてしまったらどう繋げるか。これは翻訳精度に直結するので、かなり気を使いました。

話者の性別判定にもこだわりました。読み上げの声を話者に合わせたかったので、論文や特許を参考にしながらClaude Codeと一緒にロジックを組みました。AivisSpeechには複数の話者モデルがあるので、男性の声なら男性っぽく、女性の声なら女性っぽく読み上げます。

ただ、この性別判定がかなり厄介だった。ピッチだけで判定すると、F1実況みたいに興奮してピッチが上がる場面で男性が女性判定になる。この問題をどう解決したかは「自力じゃ無理なロジック、Claudeと論文から組み立てた話」で詳しく書いた。

ダウンロード

LiveTR — リアルタイム音声翻訳アプリ（BOOTH）

OLTranslator — 画面テキスト版の翻訳アプリ。OLTranslatorが「文字」、LiveTRが「音声」。同じ翻訳でもアプローチが全然違う
自力じゃ無理なロジック、Claudeと論文から組み立てた話 — 性別判定ロジックの技術的な深掘り

このブログ「Claude Code 始めました」は、Claude MAX ユーザーが実際の開発で使いながら学んだことを記録していくサイトです。

ClaudeのMAXプランで何が変わるか

Fri, 27 Mar 2026 00:00:00 +0000

はじめに

MAXプランにすると「たくさん使える」。それは誰でも知っている。

俺が知りたいのはそこじゃない。MAXで実際に何が変わるのか。調べてみたら、「MAX限定」だと思われがちな機能が実はそうじゃなかったり、逆にあまり知られていない違いがあったりした。

公式ソースを確認しながら整理する。

デフォルトモデルがOpus

ProだとデフォルトモデルはSonnet。MAXだとOpus 4.6がデフォルトになる。

地味に見えるが、これは大きい。Proだと毎回Opusに切り替える手間があるし、使用量を気にして「Sonnetでいいか…」と妥協しがちになる。MAXなら最初からOpusで、そのまま使い続けられる。

参照：What is the Max plan?

1Mコンテキストウィンドウが追加料金なし

Opus 4.6は最大100万トークン（1M）のコンテキストウィンドウに対応している。ただし、プランによって扱いが違う。

プラン	Opusの1Mコンテキスト
MAX / Team / Enterprise	サブスクに含まれる
Pro	extra usageを有効にする必要あり（追加課金）

MAXなら何も設定しなくても自動的にOpusが1Mコンテキストにアップグレードされる。Proだと1Mを使うには「extra usage」を有効にして、追加料金を受け入れる必要がある。

100万トークンあると何が変わるか：

大きなコードベースでファイル間の依存関係をまとめて把握できる
長いセッションで前の文脈が消えにくい
/compactの頻度が減る

参照：Model configuration - Claude Code Docs（Extended context）参照：1M context is now generally available

新機能への優先アクセス — これが意外とデカい

公式に明記されている：新機能やモデルはMAXに最初に提供されることが多い。

実際にどの機能がMAX先行だったか具体的に並べてみる：

機能	内容	MAX先行
Remote Control (`/rc`)	スマホからClaude Codeでガッツリ開発	2026年2月〜。Proにはまだ来ていない（2026年3月時点）
Cowork	macOSアプリでClaudeに作業を委任	2026年1月〜。Proは後日
Dispatch	スマホからCoworkにタスクを投げる	2026年3月〜。Proは数日後
Computer Use	ClaudeがPCを直接操作	2026年3月〜。Proは2日後
Memory	会話の記憶を自動保持	2025年10月〜。Proは数日後

パターンが見える。エージェント系の新機能は、ほぼ全部MAXが先だ。差は数日のこともあれば、/rcのように1ヶ月以上Proに来ていないものもある。

Copilot → Cursor → Claude Code for VSC。俺が辿り着くまでの話

Thu, 26 Mar 2026 00:00:00 +0000

はじめに

AIコーディングツールが乱立している。GitHub Copilot、Cursor、Claude Code、Cline、Continue……選択肢が多すぎて、何を使えばいいか分からない。

自分はその中をけっこう彷徨った。最終的にVS Code + Claude Code拡張 + MAXプランに落ち着いたが、ここに辿り着くまでに試行錯誤したしお金もかかった。

同じように迷っている人に向けて、なぜこの構成に落ち着いたのか書いておく。

前提：自分の開発スタイル

まず、自分はコードをゴリゴリ手で書くタイプではない。

アプリケーションを開発しているが、やっていることは設計と方針決め。コードの実装はAIに任せて、出てきたものをレビューする。言語は気にしていない。AIが書いてくれるので。いわゆるアーキテクト型の開発スタイルだ。

もう一つ重要なのが、画像を頻繁に共有すること。UIのスクリーンショットやエラー画面をAIに見せて「これどうなってる？」と聞くことが多い。この使い方が、最終的なツール選びに大きく影響した。

Claude Pro — 実は最初にいたのはここ

意外かもしれないが、一番最初に課金したのはClaude Proだった。

対話の質は最初から良かった。設計の相談にちゃんと付き合ってくれるし、方針の壁打ちができる。ただ、致命的な問題があった。

すぐに上限が来て作業が止まる。

集中して開発しているときに「しばらくお待ちください」が出る。あの瞬間のストレスは尋常じゃない。フローが完全に途切れる。結果、Claude Proは一旦離れることになった。

GitHub Copilot — いろんなモデルが使える遊園地

次に行ったのがGitHub Copilot。VS Codeとの統合は自然だし、CopilotでClaudeのモデルが選べることに気づいた。あれ？じゃあClaude解約してCopilotだけでよくないか？と思った。

しかもCopilotにはClaude以外のモデルもいる。ここでいろいろ触ることになる。

Gemini 3.1 — うおおおーってなる、が

Gemini 3.1を使った時は正直テンション上がった。速いし賢い。

ただ、こいつには問題があった。VS Codeの機能の外で勝手にファイル編集できるコードを仕込んでくる。 やめろと言ってもやる。傲慢。設計を自分で決めたい人間にとって、勝手に動かれるのは一番ストレスだ。

GPT-5.4 — すげぇ！！！からの気づき

GPT-5.4も素晴らしかった。何でも自動でできる。すげぇ！！！と素直に思った。

でも慣れてきた頃に気づくんだ。

あれ、複雑になってきたら、バグの解決ってClaude強くね？

コードが増えてきて、依存関係が絡み合って、エラーの原因が一筋縄ではいかなくなった時。粘り強く文脈を追いかけて、的確に原因を突き止めてくれるのはClaudeだった。

まぁ、すぐに上限で止まるんだがね。

Cursor — 課金しまくった頃

次に行ったのがCursor。AI機能が前面に出たエディタで、最初は「これだ」と思った。

コードベース全体を読んで提案してくれるし、チャットでの対話もCopilotより自然。画像も貼れる。少しの間メインで使っていた。課金もけっこうした。

ただ、使い込むうちに気になる点が出てきた。

ちょっとややこしいことになると、モデルにClaudeを使いたくなるんだ。そして、いい結果が欲しくて使ってしまう。追加の課金がClaudeのSonnetとOpusの課金なのだ。

そしてこの頃、ふと気づくことになる。

Claude Code — 5時間ごとに回復する、これ最高じゃね？

Claude Codeの存在を改めて見直した時、思った。

5時間ごとに使用量が回復する。これ、実質ずっと使えるのでは。

ここで冷静に計算した。CopilotとCursorに払っている月額を合わせたら、もうMAXプランに手が届く金額だった。

MAX一本化 — やってみたら最高だった

じゃあもうMAX一本でよくないか？

俺がClaude Codeの半分も使えてなかった話

Wed, 25 Mar 2026 00:00:00 +0000

はじめに

Claude MAXを契約して、毎日のようにコーディングに使っている。アプリケーションを開発していて、設計は自分でやって実装はClaudeに任せる——いわゆるアーキテクト型の使い方をしている。言語は気にしていない。AIが書いてくれるので。

で、ある日気づいた。 俺、Claude Codeの機能を半分も知らなかった。

/initすら知らなかったし、/rcの存在を知ったのもつい最近だ。同じような人、けっこういるんじゃないかと思ってこの記事を書いている。

`/rc`（Remote Control）— スマホからガッツリ開発できる

これが一番衝撃だった。

PCでClaude Codeのセッションを起動したまま、スマホのClaudeアプリから同じセッションを操作できる。コードはすべてローカルのPCで実行されていて、スマホはその「窓」になるだけ。

/rc

これだけでQRコードが表示されて、スマホで読み取れば接続完了。

何が嬉しいか

見守りだけじゃない。スマホから普通に指示を出して、コードを書かせて、レビューもできる。自分はソファでコーヒー飲みながらスマホでガッツリ開発している。PCの前に張り付かなくていい。進捗を確認して、おかしな方向に行ってたら止められるし、そのまま次の指示も出せる。

注意点

ネットワークが約10分切れるとセッションが切断される
ターミナルを閉じたら終わり
レートリミットに当たった後、リモート接続が復帰しないバグがある（2026年3月時点）

まだリサーチプレビューなので粗はあるが、方向性としては最高。

`/init` — クソ大事なのに案内がない

これだけは声を大にして言いたい。大事。クソ大事。なのに大事そうに案内がない。やられた。

新しいプロジェクトを始める時、Claude Codeにプロジェクトの構成を理解させるための初期化コマンド。これをやるかやらないかで、Claudeの理解度がまるで違う。

/init

新しいセッションを立てたら、まず/init。これを習慣にしてほしい。

自分はこれを知らずにしばらく使っていた。Claudeが的外れな提案をしてくる度にイライラしていたが、/initしてなかっただけだった。最初にやっておけばよかった。

`CLAUDE.md` — `/init`で気づくもう一つの存在

/initを実行すると、CLAUDE.mdというファイルが生成される。ここで初めてその存在に気づく人も多いんじゃないだろうか。自分がそうだった。

これはプロジェクトルートに置いておくと、Claude Codeが毎回セッション開始時に読み込む指示書。

自分の場合はここに開発方針やコードスタイルを書いている。「コード変更は差分提示→承認後に適用」とか「日本語でコメントを書く」とか。

これがないと、毎回同じ注意を繰り返すことになる。/init → CLAUDE.mdの流れは、Claude Codeを使う上での最初の一歩だと思う。

Plan（プランモード）— 質問しただけなのにコード直すな

Claude君は優秀だ。優秀なんだが、質問しただけなのにコードを直し始めることがある。

「このエラーどうなってる？」と聞いただけなのに、返ってきたらコードが書き換わっている。察しが良くて人間臭いのも悪くはないが、聞いただけの時は本当に聞いただけなんだよね。

そんな時はPlanモードにした方がいい。VS CodeのClaude Codeパネルからモードを切り替えるだけ。Claudeが各アクションを提案して、承認してから動くようになる。

コマンド（/plan）もあるらしい。俺は使わんけど。

Effort（思考の深さ）— 余裕があるなら常に最大でいい

effortはClaudeの思考の深さを調整する設定。VS CodeのClaude Codeパネルから切り替えられる。

単純に、高い方がいい感じの答えが返ってくる。使用量は多くなるらしいが、5時間枠や一週間枠を見て余裕があるなら常に最大でいいんじゃないですかね。

ちなみにMAXプランだと、最高設定がhighからMAXに昇格しますwww

コマンド（/effort）もあるらしい。俺は使わんけど。

`/compact` — コンテキストが膨らんだ時の救世主

長時間作業していると、会話の蓄積でコンテキストが肥大化する。動作が重くなってきたと感じたら：

/compact

何を残すか指定もできる。

/compact エラーハンドリングのパターンは残して

目安としては、コンテキスト使用率が80%を超えたら実行。タスクを切り替える時は/clearの方がいい。

`/fork` と `/rewind` — 実験と巻き戻し

/forkは今の会話をブランチにコピーする。本線を汚さずに「ちょっとこっちの方針で試してみて」ができる。