年末年始のClaude Codeリソース管理ゲーム
年末年始は Claude に課金して Claude Code まわりのキャッチアップしてみよう。帰省してからの持て余し時間にスマートフォンを眺めながらふと思いたった。
職業としてのソフトウェア開発をしているわけではないため、最新サービスにはキャッチアップしきれておらず、Claude Code なども使いたいが GitHub公式という将来性があって年額 $100 で遊び倒せる GitHub Copilot PRO契約が自費負担の範囲として筋が良いかなと思っていたりもする。Gemini 契約が使える Anti Gravity もあるが、「素人がリモートでバイブス開発」という体験こそが「OS移行」と感じる。
前回の記事において GitHub Copilot Agent によるリモート開発や VS Codeでの個人開発について触れていたけれども、X において SKILLS を中心に Calude Code 周りの議論が盛り上がっていたことも影響して、ある程度理解しておこうと思った。
これまでの Claude Code への印象としては月額$200のMAXプランで使い物になるということであり、月額$200 もあればサウナやマッサージに10回以上いけるし小旅行やガールズバーだっていけるじゃないかなんて思ってしまう。僕自身としてはあくまで趣味として個人的なツール開発やキャラクターエージェントなど作成しており、開発ツールに高額な課金をするという発想自体があまりないのが正直なところだ。
現在では制限が多いものの $20 の契約でも Claude Code が使えるとのことで、まずは$20 でお試し課金をしてみた。結論からいえば本格的に使うのは難しかったのだけども、Claude Code自体のポテンシャルと、どんなに課金をしてもコンテキストエンジニアリングが必要になってくるということに気がつけた。本記事は『定額制夫の「こづかい万歳」 月額２万千円の金欠ライフ（１） (モーニングコミックス)』のごときトークン不足ライフにおいて学んだことを共有したい。あくまで触り始めの感想なので誤解も多いと思われる。
実家の M1 MacBook Air でも快適に動く
まず思ったのは開発体験における軽快さだ。実家に放置している M1 MacBook Air で VS Code のコンソールから利用していたが、驚くほど快適に動作した。これは CLI と LLM の Web API 利用という構成の強みだろう。重い IDE での処理や GPU を必要とせず、ターミナルと API 通信だけで完結する。
M1 MacBook Air 自体が名機という側面もあるだろうが、GitHub Copilot や Cursor といった IDE 統合型のツールと比べ、Claude Code には環境を選ばない良さがある。実家の古い Mac でも、リモートコンテナでも遜色なく動き、Github Copilot Agent のような GitHub Actions とリモートコンテナ接続によるモバイル開発も行える。高価な開発機器を必要としないという意味でもお小遣いに優しいのかもしれない。
編集モードONにしたり、コマンド実行を許可すればどんどん自律的にソフトウェアが出来上がっていく。現在の Github Copilot もそれなりには使えるものにはなっていると思われるが、ツールの使い方や最後までやりきろうという力は Claude Code の方が高いと感じてワクワクとした。
とはいえ、長大な CLAUDE.md をメンテしながら思いついた実現したいことをチャットしていくとAPIからの戻りは遅くなっていくし、意図したものと違う結果になってしまう可能性も高い。ノってきたところ5 時間ごとのレートリミットに達してクールダウンタイムに入ってしまうと、せっかく出てきたやる気が台無しだ。そこでコンテキストに利用するトークンの削減について改めて学んでいくこととした。
オンデマンドな Lazy Loading という基本戦略
まず必要な戦略は不要な情報を LLM に読み込ませず、必要な情報だけを必要なタイミングでロードする Lazy Loading の原則だ。これは、そもそも気になっていた Claude Skills の議論でもなされていたため、すんなりと腹落ちした。Lazy Loading は、以下の実装群で実現される。
- Claude Rules：パス特定ルールで必要なルールだけをロード
- Agent Skills：タスクマッチ時のみ詳細指示をロード
- Sub Agents: 新しいコンテストでサブエージェントに処理を委譲し結果のみを利用
- MCP Tools Search：ツール使用時に初めて定義をロード
この原則は、コンテキスト削減のみならずコンテキスト汚染を防ぐという観点からも普遍的な最適化手法になっていくだろう。
Claude Rules / Agent Skills / Sub Agents
For larger projects, you can organize instructions into multiple files using the .claude/rules/ directory. This allows teams to maintain focused, well-organized rule files instead of one large CLAUDE.md.
Claude Code では、プロジェクトのルールを定義するファイル（CLAUDE.md）がコンテキスト管理の鍵となるが、このファイルは全ての処理で全文読み込まれてしまうため、適切に扱わないとトークンを大きく消費してしまう。このため、 .claude/rules/ ディレクトリで指示をモジュール化することが求められる。
your-project/ ├── .claude/ │ ├── CLAUDE.md # メイン指示 │ └── rules/ │ ├── code-style.md # コードスタイルガイド │ ├── testing.md # テスト規約 │ └── security.md # セキュリティ要件
この時に mdファイルに設定される YAML フロントマターが Lazy Loading の鍵となる。.claude/rules/配下のファイルに YAML フロントマターでpathsを指定することで、条件付きロードが実現される。
--- paths: src/api/**/*.ts --- # API Development Rules - All API endpoints must include input validation
この YAML フロントマターでルールのロードタイミングが変更されるため、拡張子やパスに応じてにどのような処理を入れるべきかを切り分けることができる。
| paths 指定 | ロードタイミング | コンテキスト消費 |
|---|---|---|
| なし | 起動時即座 | 常時 |
| あり | 対象ファイル操作時のみ | 必要な時のみ |
なお重複防止機能により、同じルールは 1 回のロードで使い回されるとのことだ。
--- name: pdf-processing description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction. ---
--- name: your-sub-agent-name description: Description of when this subagent should be invoked tools: tool1, tool2, tool3 # Optional - inherits all tools if omitted model: sonnet # Optional - specify model alias or 'inherit' ---
規約に応じたファイルの分割および YAML フロントマターによる起動条件のおよび実行記述は Agent Skills も Sub Agents もほとんど変わらない。目的に応じて起動条件の書き方や挙動の違いがあるため適したものを選んでいく必要があるのだけど、そこまでの言語化ができていない。
読んでいない本について堂々と語るコンテキストエンジニアリング
Claude のツール検索ツール は Claude がすべてのツール定義を事前にコンテキストウィンドウに読み込むのではなく、必要に応じてツールを検索・呼び出すことができる機能です。これにより、不必要なツール定義がコンテキストウィンドウに含まれてコンテキストを圧迫する問題を回避できます。
また、MCP についてもツール定義自体を全体ロードせず、必要に応じて検索できるようになったりとオンデマンドな Lazy Loading の原則と、ロード条件の曖昧さを許す方向に各ツールが進化していると考えている。しかしながら、これは一長一短でもあり、静的条件で確定できることにも自然言語を使うことで結果を安定させられず、試行錯誤によるトークン無駄遣の要因になってしまうとも感じている。
ピエール・バイヤールの『読んでいない本について堂々と語る方法』は僕自身も好きな本なのだが、『積読こそが完全な読書術である』においても参照されており、重要な理論的補完を提供する。バイヤールは、「ある本について的確に語ろうとするなら、ときによっては、それを全部は読んでいないほうがいい」という挑発的なテーゼを提示した。
この主張の背後にあるのは、「完全な読書」の不可能性である。バイヤールによれば、読書を始めた瞬間から忘却のプロセスが始まり、読者が完全に覚えている本など存在しない。すべての読書は本質的に「流し読み」であり、「読んだ」と「読んでいない」の境界線は曖昧である。
(中略)
またモーティマー・アドラーの「点検読書」は、読書の具体的実装方法を提供する。これは書物のいわゆる本文をいきなり読むのではなく、まえがきやあとがき、目次や索引をまず読んで、その書物の概要を掴むという方法だが、これは「カタログを先に頭に入れてオンデマンドで中を見る」アプローチであり、AI における RAG や MCP のような情報チャンク検索に通じるものがある。
ここまで動かして感じたのはRAG構築の時にも痛感した読書論の有用性が活きてくることだ。そもそも人間における「記憶」はコンテキスト長に収まるぐらいのもののコンパクションされていくものなのかもしないと考えるとオンデマンドに適切に展開可能なビオトープの整備こそがコンテキストエンジニアリングであり、図書館論への接続になっていくと個人的には理解できてきた。
コンテキスト削減の本当の第一歩は .claudeignoreの活用
そんな感じで Lazy Load について学んできたのだけど、そもそも論として静的解析やルールベース判定をすれば良いことについても、あまりに自然言語でなんとかしようとしていることへの違和感があった。開発環境において都度の判断をしないといけない場所を少なくしていくインセンティブがあり、過去から開発され、磨かれてきた支援ツールは沢山ある。その意味でまずしなきゃいけないトークン削減はLLMの参照可能ファイルのルールベース設定だろう。
# .claudeignore # Dependencies node_modules/ .venv/ venv/ __pycache__/ *.pyc *.pyo *.pyd .Python # Build outputs dist/ build/ *.egg-info/ .pytest_cache/ .coverage # Environment files .env .env.local .env.*.local # IDE settings .vscode/ .idea/ *.swp *.swo *~ # OS files .DS_Store Thumbs.db # Git .git/ .gitignore # Data files backend/data/ data/ # Logs *.log logs/ # Database *.db *.sqlite *.sqlite3 # Images and media backend/data/images/ *.png *.jpg *.jpeg *.gif *.ico *.svg *.webp # Lock files (can be large) package-lock.json yarn.lock pnpm-lock.yaml uv.lock # Frontend build frontend/dist/ frontend/build/ # Temporary files *.tmp *.temp tmp/ temp/ # Migration history (keep migration scripts, exclude data) backend/migrations/*.json
ビルド成果物、依存関係ファイル、ログ、ミニファイドコード—これらを徹底的に除外。プロジェクトによっては、読み込むファイル数を 1/10 以下に削減できる。特に重要なのはpackage-lock.jsonやyarn.lockの除外だ。これらは人間にとって重要だが、AI には不要。数千行の JSON を読ませるのは、貴重なトークンの無駄遣いだ。
静的ツールの活用による決定論的システム化
これに限らず静的ツールの活用が大事になると感じている。低レベルなエラーの修正に LLM のトークンを使うのは、高級レストランの Uber Eats でカップラーメンを注文するようなものだ。React なら ESLint、Biome、Python なら Ruff といった静的解析ツールを事前に実行することで、タイポや構文エラーを自動修正し、コードスタイルを統一できる。
# フロントエンド pnpm run lint --fix && pnpm biome check --write . # バックエンド uv run ruff check . --fix && uv run ruff format .
LLM には創造的な問題解決に集中してもらい、機械的な修正は静的解析ツールに任せることでトークン消費や詳細なルール記述を削減できる。これをSKILL.md · GitHub のような AGENT SKILLS として登録しておくことでコード修正が起こった際にはある程度自動的に補正してもらえるようになった。
Plan 駆動開発と TODO 管理の重要性
僕の好きな言葉にピーター・ドラッガーの「元々しなくても良いものを効率よく行うことほど無駄なことはない」というのがあるのだけど、効率厨だからこそ意図とあまりに違う実装がされてやり直す試行錯誤は避けたいものだ。もちろん、LLMが勝手に実装した結果削いて「これもいいじゃん」というディスカバリーモードも必要だと思うが、制限環境の中では作るべきものを明確化した方が余計なトークンが消費されないし、無駄な時間も節約できる。ここで役立つのが /plan モードなのだけど、プラグインである /dig のお世話にもなった。
/dig は「コードベース理解しながら、仕様が不明瞭な部分への選択肢付きの深掘り質問して明確化していく」ためのプラグインで、自分が何をしたかったのかについての言語化ができてから Claude Code に実装計画を立ててもらうことができる。選択肢を選んでいく体験はゲームブックのようであり、Vampire Survivorsのようでもありながら自分自身の「よしなに」を許してきたコミュニケーション能力を反省したりもする。
プラン内容は todo.md ファイルに書き出していき、これを確認・修正しつつ思いついたことを追記することで進捗管理をしながら完成に近づけていける。それでもコンテキスト汚染は起こっていくので、区切りごとに /context を確認し、 /clear や /compaction 覚えておきたいこと を実行させることが有効であった。
未来の開発環境を体験するためのお小遣いぶっ込み
年末年始、そんなこんなの試行錯誤で、僕のワークフローは以下のように急速に最適化されていった。
- コンテキスト管理：
.claudeignoreと/clearの徹底 - Lazy Loading の原則：必要な情報を必要なときに
- 静的処理の活用：LLM を使わない選択
- プラン駆動開発：実装前のプランニングとTODO リスト化の動的な生成と実行
1-2時間ごとに訪れる5時間レートリミットも休息時間やインプット時間と割り切れる境地まで来ていたのが、ついにはWeekly リミットが来てしまい全く触れなくなってしまった。ここまでの感覚でなんとなく使いこなせそうな未来が見えてきたし、上位プランなら使える Opus 4.5 や並行稼働開発の世界についても知っておきたいと感じたため、1ヶ月だけx20プランに課金してみることにした。
繰り返しになってしまうが、職業エンジニアではない僕にとって、月$200は大きな出費だ。ここ数年で蕎麦打ちが趣味になったからといって蕎麦屋を開店しないのと同じで今から職業エンジニアになれる気もしない。それでも2026 年の開発環境の先行体験、コンテキストエンジニアリングのスキル習得、AI エージェント開発という新しいパラダイムの理解といった要素を考えれば、趣味開発者としての自己投資として許されるのかもしれない。趣味の蕎麦打ちだからこそ道具にこだわってしまう悪癖というのもある。
何にせよ、残りの30日間弱で集中して Claude Code についてキャッチアップしきることとしたい。$20という縛りプレイだからこそ学べたプロンプト・エンジニアリングが、今度は30日間限定だからこその時間的集中に転換されることを期待したい。次回以降の記事では Opus 4.5 や並行稼働を前提とした開発ワークフロー構築についても書けたらと考えている。Obsidianとの相性も良さそう。
