[{"content":"Claude Codeのソースコードが流出した。論争になり賛否両論が飛び交ったが、誰かは一晩のうちにClaw Codeを作り、世界中からスターを集めていた。これは明らかに全力を尽くすべき時期だ。\n恐れるな！俺が行く！ 会社から帰ると夜だが問題ない。右手にバッカス、左手にコーヒーがある。二日間、四時間ずつしか寝なかった。\nClaw Codeの分析をClaude Codeに任せておき、合間にソース分析ドキュメントを読んだ。\nハーネスエンジニアリング解説を読んでアイデアが浮かんだ。まだ誰も手を出していなさそうな、自分が身を置いている金融業界にAIを導入するためのハーネスを作ろうと思った。\nコア業務ではないので理解度が足りないが、それでも作った。何でもいいから作らなきゃという気持ちだった。（すぐ修繕する予定だ）\nこっちに来い、名誉ある死を迎えろ！ そしてClaw Codeを分析して気づいた。（1,884個を全部読んだわけではないが）俺がhooksとCLAUDE.mdで一生懸命作っていたものは、すでに設計されていた。権限管理システム、ツールルーティング、コンテキスト管理まで。\n俺が作って意図していたものは、実は四角い車輪だった…\n四角くても転がそうと努力したおかげで、ファイルの構造がすんなり頭に入った。\n恐怖こそが最大の敵だ！ 実はずっと誰にも言わなかった秘密だが、俺はAIに敬語を使っていた。\n\u0026#39;人間の時代の終わりが到来した\u0026#39; - ブリッツクランク ついにAIに支配される時代が来そうだという不安から、プロンプトを書くとき「〜してください」「〜お願いします」を使っていた。失礼な部分がないかプロンプトのEnterを押す前に検収するパイプラインまで備えていた。\nところがClaw Codeを見て考えが変わった。システムプロンプトがあり、ツール呼び出しロジックがあり、権限チェックがある。JSONをパースしてAPIを呼び出す。TypeScriptだ。こいつらもコードだ。\nおかげで（？）タメ口を始めた。検収パイプラインを廃棄したら仕事の効率も上がった。\n今日は市場調査をさせながら「アイデアをパクリできるリサーチしてこい」と言ったら、レポートの目録に「パクリ可能な部分」と書かれていた。敬語を使っていた頃は「参考可能な事項」と遠回しに返ってきたはずだが、タメ口で投げたらタメ口で返してくる。コードらしい。\n","permalink":"https://nullnull-kim.com/ja/logs/2026-04-03-claude-code-leaked/","summary":"\u003cp\u003eClaude Codeのソースコードが流出した。論争になり賛否両論が飛び交ったが、誰かは一晩のうちに\u003ca href=\"https://github.com/ultraworkers/claw-code\"\u003eClaw Code\u003c/a\u003eを作り、世界中からスターを集めていた。これは明らかに全力を尽くすべき時期だ。\u003c/p\u003e","title":"Claude Codeのソースが流出した"},{"content":"EP.2でhooksを使ってClaudeが読むものを減らした。テスト結果は失敗だけ出力し、ビルドログはエラーだけ抽出した。\nどれくらい減ったのか測定することにした。\nまず測定 Claude Codeはすべての会話をJSONLファイルに記録する。~/.claude/projects/の下にプロジェクトごとに蓄積され、各項目にトークン使用量が入っている。これを読んでコストを計算するスクリプト（analyze-tokens.js）を作った。日付別セッションファイルと照合してターン数、cache_read/write/outputをそれぞれ集計しコストに換算する。\n作る過程でバグを1つ見つけた。セッション記録hookがe.usageを参照していたが、JSONLの構造はe.message.usageだった。セッションファイルにトークンが記録されていなかったのだ。分析器はJSONLを直接読むように迂回した。\n以下は3月27日1日分のコストだ。\n総コストの58%は読み込み 項目 コスト 割合 cache_read $19.22 58% cache_write ~$9.62 29% output ~$4.33 13% 合計 $33.17 cache_readが58%。Claudeが発生させたコストの半分以上が「読み込み」という意味だ。EP.1で「Claudeが消費するトークンの大部分は推論ではなく読み込み」と書いたが、数字で見ると確実だ。\n何を読んでいるのか Claudeが毎ターン読むものを追跡した。\n項目 ロード時点 規模 プロジェクトCLAUDE.md 毎ターン 155〜214行 ルートCLAUDE.md 毎ターン 10行 MEMORY.md 毎ターン 23行以内 会話履歴 毎ターン 累積 意外な発見があった。SKILL.md（469行）とエージェントドキュメント（1,233行）は毎ターンロードされない。スキルが呼ばれた時だけ、エージェントが実行された時だけロードされる。すでにlazy loadingだ。\n毎ターン固定でロードされるのはCLAUDE.mdとMEMORY.mdだけだ。\nCLAUDE.mdをrules/に分離 CLAUDE.mdが155〜214行だからといって全部が毎ターン必要なわけではない。成果物パステーブルは成果物を書く時だけ必要で、ゲームドメインルールはゲーム関連作業の時だけ必要だ。\nClaude Codeには.claude/rules/ディレクトリがある。ここにファイルを作りpaths:フロントマターを付けると、該当パスにアクセスした時だけロードされる。\n--- paths: tasks/** --- 成果物パステーブル、共通ヘッダーブロック、役割別ルール... tasks/フォルダを触る時だけこのルールがロードされる。一般的な会話ではロードされない。\n1つのプロジェクトで先に試験適用した。成果物関連セクション45行をartifact-rules.mdに分離し、CLAUDE.mdから該当部分を削除した。動いた。残りにも一括適用した。\nプロジェクト CLAUDE.md（前→後） 削減率 分離ファイル A（ECサイト） 155行→96行 38% artifact-rules.md B（教育プラットフォーム） 207行→140行 32% artifact-rules.md、edu-rules.md C（ゲームプラットフォーム） 214行→114行 47% artifact-rules.md、game-domain.md Cが47%も減った。ゲームプラットフォームなのでドメインルール（46行）が毎ターンロードされていたが、今はゲーム関連ファイルを触る時だけロードされる。\nところがですよ 数値は悪くない。32〜47%軽量化。見た目はいい。\nしかし正直に言えば、これは「CLAUDE.md 155〜214行のうち32〜47%」だ。ターンあたり数百トークン程度の削減だ。cache_read $19.22の大部分はCLAUDE.mdの200行ではなく会話履歴の累積が原因だ。1セッションで20ターン回すと、20ターン目には前の19ターン全体がcache_readとしてロードされる。\n1日のコストの半分以上を占めたプロジェクトがあった。他のプロジェクトより3倍以上高かった。理由は単純だ。1セッションで17ターン回した。後半のターンでcache_readが急増したのだ。\nCLAUDE.mdをいくらダイエットさせても、会話履歴が蓄積する構造を変えなければcache_readの大部分はそのままだ。EP.1でエージェント数を減らし、EP.2でhooksで出力を減らし、EP.3で固定ドキュメントを減らした。全部意味のある作業だが、本当の大きな穴はまだ開いている。\n切るか、続けるか、それが問題だ 20ターンを超えたら新しいセッションを始める方がcache_read的には効率的だ。しかし新しいセッションを始めるとcache_writeが再発生する。CLAUDE.md、MEMORY.md、システムプロンプトを最初から書き直す。\ncache_readを減らすためにセッションを切るとcache_writeが増える。cache_writeを減らすためにセッションを続けるとcache_readが増える。どちらにしてもコストがかかる。\n答えはまだわからない。20ターンくらいが損益分岐点という感覚はあるが、作業タイプによって異なる。会話の多い設計作業は早く切る方がいいし、連続コーディングは続ける方がいい。\nこれがEP.3の本当の発見だ。減らせるものは減らした。残ったのは「どう使うか」の領域だ。\nこのシリーズの他の記事\nEP.1 — 3時間で使用量を超えた話 EP.2 — hooksとsubagentでコスト削減 Discordアラートシステム構築記 参考\nClaude Code Rules Files Claude Code CLAUDE.md ","permalink":"https://nullnull-kim.com/ja/logs/2026-03-30-token-ep3/","summary":"\u003cp\u003e\u003ca href=\"/ja/logs/2026-03-28-token-ep2/\"\u003eEP.2\u003c/a\u003eでhooksを使ってClaudeが読むものを減らした。テスト結果は失敗だけ出力し、ビルドログはエラーだけ抽出した。\u003c/p\u003e\n\u003cp\u003eどれくらい減ったのか測定することにした。\u003c/p\u003e\n\u003ch2 id=\"まず測定\"\u003eまず測定\u003c/h2\u003e\n\u003cp\u003eClaude Codeはすべての会話をJSONLファイルに記録する。\u003ccode\u003e~/.claude/projects/\u003c/code\u003eの下にプロジェクトごとに蓄積され、各項目にトークン使用量が入っている。これを読んでコストを計算するスクリプト（\u003ccode\u003eanalyze-tokens.js\u003c/code\u003e）を作った。日付別セッションファイルと照合してターン数、cache_read/write/outputをそれぞれ集計しコストに換算する。\u003c/p\u003e","title":"Claude Code トークン節約 EP.3 — CLAUDE.mdをrules/に分離した"},{"content":"プロジェクトが5つになった。shop、blog、code_dungeon、good_game、そして全体を管理するroot。（プロジェクト名がrootではない）各プロジェクトごとにClaudeセッションが走っているが、問題は自分が一人しかいないことだ。\nshopでtaskを走らせてblogで草稿を修正していると、shopがいつ終わったか分からない。code_dungeonでPhase 1を始めてgood_game側を見ていると、code_dungeonが権限確認を待って止まっていても分からない。ターミナル5つを交互に見るのはモニタリングではない。ただ目が痛いだけだ。\nアラートが必要だ。\nDiscord Webhookを選んだ理由 Slackもあるしテレグラムもあるが、Discordを選んだ。理由は単純だ。チャンネルを無料で無限に作れる。プロジェクトごとにチャンネルを分離すればアラートが混ざらない。root-alerts、shop-alerts、blog-alerts、code_dungeon-alerts、good_game-alerts。5つのチャンネルにそれぞれWebhook URLを1つずつ作った。\nWebhook URLは各プロジェクトの.claude/.discord-webhookファイルに保存した。スクリプトにハードコーディングするとプロジェクトが追加されるたびにスクリプトを修正しなければならないが、ファイルに分離すればWebhookファイルを作るだけでいい。\n最初のhook：作業完了時にアラート Stop hookにDiscord通知スクリプトを接続した。セッションが終わるとプロジェクト名と時刻をDiscordに送る。\n1 2 # stdinを即座に変数に保存（他のasync hookとのstdin競合防止） INPUT=$(cat) Stop hookはasyncで実行される。そのため他のhookと同時に走るとstdinがどちらに渡されるか保証されない。INPUT=$(cat)をスクリプト最上部に置いてstdinを即座にキャプチャしなければならない。\n終了理由が全部「unknown」だった アラートは来るが、全部「不明」だった。[shop] 不明 — 03-28 18:01。終わったのは分かるが、なぜ終わったかが分からない。正常完了か、トークン超過か、拒否か。\nStop hookのpayloadを調べた。stop_reasonフィールドがなかった。Claude Codeがhookに渡すJSONにはセッション終了理由が含まれていない。\n回避した。payloadにtranscript_pathがあった。セッションの全会話が記録されたJSONLファイルのパスだ。こういう構造だ：\n{\u0026#34;type\u0026#34;:\u0026#34;user\u0026#34;,\u0026#34;message\u0026#34;:{\u0026#34;role\u0026#34;:\u0026#34;user\u0026#34;,\u0026#34;content\u0026#34;:\u0026#34;プロジェクトパス変更して\u0026#34;},...} {\u0026#34;type\u0026#34;:\u0026#34;assistant\u0026#34;,\u0026#34;message\u0026#34;:{\u0026#34;role\u0026#34;:\u0026#34;assistant\u0026#34;,\u0026#34;content\u0026#34;:[{\u0026#34;type\u0026#34;:\u0026#34;text\u0026#34;,\u0026#34;text\u0026#34;:\u0026#34;...\u0026#34;}],\u0026#34;stop_reason\u0026#34;:\u0026#34;end_turn\u0026#34;,...},...} 1行が1つのイベントで、assistantメッセージにstop_reasonフィールドが入っている。このファイルを逆順に探索して最後のstop_reasonを抽出する方式に変えた。\n1 2 3 4 5 const lines = fs.readFileSync(tp, \u0026#39;utf8\u0026#39;).split(\u0026#39;\\n\u0026#39;).filter(l =\u0026gt; l.trim()); for (let i = lines.length - 1; i \u0026gt;= 0; i--) { const e = JSON.parse(lines[i]); if (e.stop_reason) { /* 見つけた */ } } 終了理由は7種類だ。それぞれ日本語にマッピングした。\nstop_reason アラート表示 end_turn 完了 max_tokens トークン超過 model_context_window_exceeded コンテキスト超過 stop_sequence 中断シーケンス pause_turn 一時停止 refusal 拒否 tool_use ツール呼び出し これで**[shop] 完了 — 03-28 18:01**、[blog] トークン超過 — 03-28 15:32のようなアラートが来る。\nサブエージェントアラートのフィルタリング 完了応答が来たのでターミナルを確認したら、まだ実行中だった。デバッグを追加して原因を調べたら、サブエージェントの並列タスク完了が原因だった。\n例を挙げよう。以下は私が構成したshopプロジェクトの業務処理構成図だ。\n顧客リクエスト → task-orchestrator（メイン） ├─ frontend-developer → 画面実装 ├─ backend-developer → API実装 ├─ code-reviewer → コードレビュー + 性能検証 ├─ security-auditor → セキュリティ検証（条件付き） └─ quality-gatekeeper → 最終検証 並列で実行されるサブエージェントが終了するたびにStop hookが実行される。メインセッションが終了しなくても。taskに5つのサブエージェントが付けばアラートが6つ来る。frontend-developer完了、backend-developer完了、code-reviewer完了… 本来のメインセッションはまだ動いているのに。\npayloadでagent_idフィールドがあればサブエージェントだ。サブエージェントの時はアラートもハートビート削除もスキップするフィルターを追加した。\n1 2 IS_SUBAGENT=$(echo \u0026#34;$INPUT\u0026#34; | node -e \u0026#34;...\u0026#34; 2\u0026gt;/dev/null) [ \u0026#34;$IS_SUBAGENT\u0026#34; = \u0026#34;yes\u0026#34; ] \u0026amp;\u0026amp; exit 0 「完了」アラートだけでは足りない Claudeが権限確認を要求したり、ファイル書き込み権限を聞いたり、入力を待っている時はStop hookが実行されない。「今回の作業は時間がかかるな」と待っていて確認したら、何十分も応答待ちだった。\n2つ目のhook：作業待機中アラート 発想は単純だ。Claudeがツールを実行するたびにタイムスタンプを記録する。2分間タイムスタンプが更新されなければ「このプロジェクトが止まっている」と判断する。\nPostToolUse hookにハートビートスクリプトを接続した。Claudeがツールを1回実行するたびに.claude/.heartbeatファイルに現在時刻を記録する。\n1 date +%s \u0026gt; \u0026#34;$PROJECT_ROOT/.claude/.heartbeat\u0026#34; これだけだ。1行のhookだ。\nそして別の監視スクリプト（watcher.sh）が60秒ごとに5つのプロジェクトのハートビートファイルを巡回する。最後の更新から2分が過ぎたらDiscordに「待機中」アラートを送る。同じプロジェクトに対して10分以内の再アラートは送らない。そうしないとアラートが溢れる。\n1 2 3 STALE_THRESHOLD=120 # 2分 COOLDOWN=600 # 10分再アラート防止 CHECK_INTERVAL=60 # 60秒ごとに確認 セッションが終わるとStop hookがハートビートファイルを削除する。終了したプロジェクトに対して「待機中」アラートが出るのを防ぐためだ。\nこれでメインセッション終了アラートだけが来る。\n現在の構成 まとめるとhook2つと監視スクリプト1つで構成されている。\n構成要素 トリガー 役割 heartbeat.sh PostToolUse ツール実行ごとにタイムスタンプ更新 notify-discord.sh Stop セッション終了時Discord通知 + ハートビート削除 watcher.ps1 60秒周期（常時実行） ハートビート2分未更新時「待機中」通知 .discord-webhook - プロジェクト別Webhook URL保存 プロジェクトを追加する時は2つだけすればいい。.claude/.discord-webhookファイルにWebhook URLを入れて、watcher.ps1のPROJECTS配列にパスを追加する。\n5つのプロジェクトが同時に走っている。Discordアラートが記録されている。\n全部作ってから見た記事 Claude Code 50の実践テクニックという記事にこういう項目があった。\n48. Claude完了時にサウンド再生 — Stop Hookでシステムサウンドを再生。タスクを始めて他の作業に切り替え、完了時にピング音で通知。\nローカルだけで作業するならこれで十分そうだ。\n関連記事\n[Claude]（トークン節約のためにやったこと）EP.1 — 3時間で使用量を超過した話 [Claude]（トークン節約のためにやったこと）EP.2 — my preciousを守らねばならない ","permalink":"https://nullnull-kim.com/ja/logs/2026-03-29-discord-alert/","summary":"\u003cp\u003eプロジェクトが5つになった。shop、blog、code_dungeon、good_game、そして全体を管理するroot。（プロジェクト名がrootではない）各プロジェクトごとにClaudeセッションが走っているが、問題は自分が一人しかいないことだ。\u003c/p\u003e","title":"Claude Code Discord通知連携 — マルチプロジェクトモニタリング構築記"},{"content":"エージェントを9つに減らし、CLAUDE.mdをダイエットさせた後、Compacting conversation...が表示される間隔が目に見えて長くなった。同じ作業をさせても以前よりはるかに持ちこたえた。嬉しかった。\nところが機能追加を依頼してコンソールを見守っていた。テストが走った。ケース30個、全部通過。しかしClaudeが成功したテストを再度言及していた。むずむずと変な感じがした。\nClaudeに聞いた。「さっき成功したテストをなぜまた言及するの？」Claudeはツールという概念を説明してくれた。Claudeがターミナルコマンドを実行したりファイルを読む時、それは全て「ツール呼び出し」だ。そしてツールを1回実行するたびにその結果物が丸ごと会話コンテキストに積まれる構造だった。npm testの結果30行、Hugoビルドログ180行、全部。テストが全部成功したなら見るものはないのに30個全部読んだ。ビルドエラーを直す時も必要なのは最後の5行なのに180行全部ロードした。\n漏れるバケツは一つではなかった。\n曰く、hooksに従うべし ググっていてClaude Codeのhooksを発見した。PreToolUse — Claudeがツールを実行する直前に割り込むスクリプトだ。Bashコマンドが実行される前に出力を加工でき、読み取りツールが呼ばれる前にブロックすることもできる。\nmy preciousを守る戒律を立てられるようになった。\n第一の戒律：成功したものは見てはならない テスト30個が全部通過したのに再度読み込む必要はない。失敗したケースだけ選んで表示し、残りは捨てるhookを作った。（Claudeに作ってもらった。）\n1 filtered_cmd=\u0026#34;$cmd 2\u0026gt;\u0026amp;1 | grep -A 10 -E \u0026#39;(FAIL|ERROR|✕|FAILED)\u0026#39; | head -150\u0026#34; 先ほど30個のテストをClaudeが全部見ていたなら、今は失敗したケースだけ見る。全部通過すれば読む量は0だ。100%の不要な読み込みを無くした。\n第二の戒律：エラーでないものはアップロードしてはならない Hugoビルドログ180行、Dockerビルド80行 — エラーを探すために全部アップロードする必要はない。同じ論理でERROR、WARN、failedだけフィルタリングして表示するhookを作った。\n1 2 # Hugo filtered_cmd=\u0026#34;$cmd 2\u0026gt;\u0026amp;1 | grep -E \u0026#39;(ERROR|WARN|error|failed|Fatal)\u0026#39; | head -30\u0026#34; 180行が5行になった。97%を削減した。Dockerも80行が10行前後になった。\n第三の戒律：役に立たないものは読んでもならない もう使わないアーカイブフォルダがある。Claudeがファイル探索中にこのフォルダを開く理由はない。Readツール呼び出しを傍受し、パスに_archiveが含まれていれば拒否するhookを作った。\n1 2 3 if [[ \u0026#34;$file_path\u0026#34; == *\u0026#34;/_archive/\u0026#34;* ]]; then # deny fi 単純だが確実だ。\nところがですね 体感は確実だった。Compacting conversation...が表示される頻度が減った。ビルド1回実行してもコンテキストがはるかに軽く維持された。hook3つでClaudeが不要な情報を読むのを防いだ。\nでも「体感」だった。正確にどれだけ減ったかは分からなかった。昨日より今日が良い気がするが、どれだけ減ったか自慢できない！EP.1で「エージェントを分割すれば減るだろう」と根拠なく信じたのと何が違うのか。\n測定しなければ改善したことにならない。定量測定が必要な時点だ。\nこのシリーズの他の記事\nEP.1 — 3時間で使用量を超過した話 Discord通知システム構築記 参考\nClaude Code Hooks Reference ","permalink":"https://nullnull-kim.com/ja/logs/2026-03-28-token-ep2/","summary":"\u003cp\u003eエージェントを9つに減らし、CLAUDE.mdをダイエットさせた後、\u003ccode\u003eCompacting conversation...\u003c/code\u003eが表示される間隔が目に見えて長くなった。同じ作業をさせても以前よりはるかに持ちこたえた。嬉しかった。\u003c/p\u003e","title":"Claude Code トークン節約 EP.2 — hooksとsubagentでコスト削減"},{"content":"知人から化粧品ショッピングモールの構築依頼を受けた。職場でCだけ書いていたので、新しい技術スタックを試す機会だった。決済はToss Payments、フロントはReact。「金融圏の次世代が全部Reactに行く」という話が気になっていたし、Toss PaymentsはNode親和的だった。方向はすぐ決まった。\n当然このスタックを使ったことはなかった。やる気はあるが、勉強してから作れるような納期ではなかった。だからバイブコーディングを試してみた。\n「化粧品を販売するためのショッピングモールを作って、リファレンスサイトのURLは〜だよ。」それだけだったのに、一人でカタカタやって、思いもよらない部分まで設計したモックアップができあがった。ああ、バイブコーディングが出て1年以上経つのに、完全に遅れていた。\nClaudeが作るコードをもとに新しいスタックを学ぶという計画は愚かだった。コードを読む速度よりClaudeが生産する速度の方がはるかに速かった。だから自分でレビューするのではなく、自分自身でレビューするよう依頼した。（人間時代の終わりが来るようだ。）\nそうやって使っていると、Claudeが前の内容を引き継げない現象が起きた。「context」という単語をググって原因を知った。サブエージェントで役割を分ければいいということもそこで見つけた。pm、dba、back、front、qa — 5つの構造をセットアップした。CLAUDE.mdにパスルールからセッション運用ガイドまで全て定義した。使用量は10%台半ば。これで十分じゃないか、と思った。\nそれから3時間後、You've hit your limit · resets 3am を見た。\n午前3時リセットという文言は理解できた。でも理解できなかった。なぜ3時間で？\n最初からボタンの掛け違いだった 5つのエージェントをセットアップしながら、間違った仮説を持っていた。「Claudeが多く考えるほどトークンが多くかかる。」根拠はなかった。ただそう思っただけだ。\nエージェントごとにif-thenルールをびっしり整理した。Claudeが判断する余地をなくせば推論コストが減ると信じていた。CLAUDE.mdもその論理で埋めた。\nlimitを経験してからやっとググった。間違っていたとその時知った。Claudeが消費するトークンの大部分は推論ではなく読み込みだった。エージェントは実行されるたびにCLAUDE.mdを最初から全部読む。一生懸命埋めたCLAUDE.mdが毎回丸ごとコンテキストにロードされていた。\n散文形式の説明をテーブルに圧縮し、重複項目を削除した。消費速度が減った。\nもっと分割すればトークンが減るだろう 軽量化後、Compacting conversation...の頻度が減った。contextがうまく維持された。嬉しかった。\nしかしトークン消費を見ると、むしろもっと漏れていた。\n「役割をもっと細かく分ければ、各エージェントが扱う範囲が狭くなるんじゃないか。」これが次の試みだった。\n5つから12に増やした。api-designer、ui-designer、performance-engineer、security-auditor\u0026hellip; 段階的に体系的に分けた構造だった。\ncontextはうまく維持された。でもトークンがもう少し漏れている気がした。\n涙を飲んで統廃合 Claudeに原因を診断してもらった。まるで裁判の判決を受けるようだった。token.. my precious\u0026hellip;\nエージェント数 = CLAUDE.md読み込み回数だった。12のエージェントがそれを12回ずつ全てコンテキストにロードした。分割するほど速く燃えていた。\n減らさなければならなかった。本当に一生懸命作ったが、涙を飲んで統合した。\napi-designerはbackend-developerに、ui-designerはfrontend-developerに、performance-engineerはcode-reviewerに吸収させた。\n項目 前 後 削減 エージェントファイル全体容量 112KB 40KB -64% エージェント数 12個 9個 -3個 使用量の消費速度が目に見えて変わった。\nだからMaxにした 構造を整えてからやっとClaudeの作業速度を実感した。お金がかかるのは確かだ。でも処理速度が想像を超えていた。自分でやれば数日かかる作業が1セッションで終わった。\nMaxプランに上げて、無駄なく充実に使おう。\n構造の問題は解決した。my preciousを守るためにググるのをやめなかった。そして発見した。Claudeがファイルを読む時、500行なら500行全部読んでいた。テストを実行すると成功したケースまで結果全体をコンテキストにロードしていた。エージェント数の問題ではなかった。Claudeが見ること自体が問題だった。\nどうすればClaudeに必要なものだけを見せることができるだろうか。\nこのシリーズの他の記事\nEP.2 — my preciousを守らねばならない Discord通知システム構築記 参考\nCLAUDE.md — How Claude remembers your project Create custom subagents ","permalink":"https://nullnull-kim.com/ja/logs/2026-03-27-token-ep1/","summary":"\u003cp\u003e知人から化粧品ショッピングモールの構築依頼を受けた。職場でCだけ書いていたので、新しい技術スタックを試す機会だった。決済はToss Payments、フロントはReact。「金融圏の次世代が全部Reactに行く」という話が気になっていたし、Toss PaymentsはNode親和的だった。方向はすぐ決まった。\u003c/p\u003e","title":"Claude Code トークン節約 EP.1 — 3時間で使用量を超過した話"},{"content":" 運よく金融系のSM（システムメンテナンス）に入り、韓国の大手企業を担当するファームバンキング担当者。最近バイブコーディングを始めたら、トークンとの戦争に突入してしまった。\nこのブログには試行錯誤、日常、そしてたまにLeetCodeの解法を記録しています。\nGitHub: nullnull-kim Email: nullnull.kim@gmail.com ブログエンジン: Hugo + PaperMod ホスティング: Cloudflare ","permalink":"https://nullnull-kim.com/ja/about/","summary":"about","title":"About"}]