ツール/開発環境

Claude Code でコーディングする時間が増えると、ふと気づくのが「VSCode って、けっこうメモリを食うな」という事実です。プロジェクトを 5 つも同時に開けば、エディタだけでメモリがカツカツになります。 note の記事「GhosttyをVSCodeみたいにしよう！」（Naoki | 電電猫猫 氏）では、まさにこの悩みを起点に、高速なターミナルエミュレータ Ghostty の上に VSCode 風の開発環境を再現する構成が紹介されていました。本記事ではその考え方を整理しつつ、使われている TUI ツール群を補足して紹介します。 なぜターミナルで VSCode を再現するのか VSCode の基本的な画面構成はだいたいこうなっています。 左サイドバー：ファイル一覧と Git のツリー表示 右側メイン：エディタ（または Claude Code）と、その下にターミナル 便利な一方で、Electron ベースの VSCode は 1 ウィンドウあたりのメモリ消費が大きく、プロジェクトを並行して開くほど重くなります。そこで「同じレイアウトを、軽量なターミナル上で組めないか？」という発想に至ります。 Ghostty は Mitchell Hashimoto 氏が開発する GPU アクセラレーション対応のターミナルエミュレータで、標準で画面分割（split）機能を持っています。この分割機能と、小さな TUI ツールを LEGO のように組み合わせることで、VSCode のレイアウトをそのまま再現するというのが今回のアプローチです。 前提：以降の手順は Rust の cargo と Ghostty がインストール済みであることを前提にしています。FileTree・keifu・zellij はいずれも cargo install で導入できます。 各パーツの役割は次のとおりです。 サイドバー（細い列）：上に FileTree、下に keifu メイン領域（広い列）：上に Claude Code / エディタ、下に ターミナル 高頻度で触るプロジェクトは zellij のセッションとして保存しておく FileTree — VSCode 風のファイルツリー TUI FileTree は、VSCode のファイル一覧をターミナル上で模倣した TUI ファイルエクスプローラです。記事の著者（電電猫猫 氏 = Naoki Takahashi 氏）自身が作ったツールで、Vim キーバインドに対応した高速・軽量なファイルブラウザになっています。 ...

gh（GitHub CLI）は通常、gh auth login の対話的なブラウザフローで認証します。しかし CI/CD パイプライン、共有サーバー、使い捨てコンテナのような ブラウザもキーボード入力もない環境 では、その対話フローは使えません。 こうした「ヘッドレス（非対話）」環境では、アクセストークン（パーソナルアクセストークンなど）を環境変数で渡す ことでクローンを自動化できます。本記事では、推奨される認証パターンと、その際に陥りがちな落とし穴・セキュリティ上の注意点を整理します。 なお、本記事を書く過程で「gh auth token --web でトークン生成画面を開ける」という情報を検証したところ、そのようなフラグは存在しませんでした。よくある誤情報なので、後半で正しい代替手段とあわせて解説します。 方法1：環境変数 GH_TOKEN を使う（最もおすすめ） gh は、環境変数 GH_TOKEN（または GITHUB_TOKEN）にトークンが設定されていると、それを自動的に認証に使用します。gh auth login のような状態の保存を一切行わないため、自動化環境に最も適しています。 一時的にトークンを渡してクローンする場合は、1 行で実行できます。 1 GH_TOKEN=ghp_YourTokenHere gh repo clone owner/repo gh auth login --help のドキュメントにも、 Alternatively, gh will use the authentication token found in environment variables. This method is most suitable for “headless” use of gh such as in automation. と明記されており、自動化での利用は GH_TOKEN が公式推奨です。 ...

Obsidianの創業者が、自社の有料サービスである Obsidian Sync を 使わずに Vault を同期・バックアップする方法を公式ドキュメントとして明文化したことが話題になっている。 何が起きているのか Obsidian は「あなたのノートは永遠にあなたのもの」を掲げるローカルファースト型のナレッジ管理ツールだ。ノートはプレーンテキスト（Markdown）でローカルに保存され、クラウドへの依存を強制しない設計になっている。 そのObsidianの創業者が、有料の Obsidian Sync（$4〜/月・年払い、または $5/月・月払い）を契約しなくても Vault を複数デバイス間で同期できる方法を、公式ドキュメント上で余すところなく公開した。 公式が案内している無料同期の選択肢 公式ヘルプ（Sync your notes across devices）によると、以下の方法が紹介されている。 1. iCloud（Apple デバイス間） Mac・iPhone・iPad を使うユーザーにとって最もシンプルな選択肢。iCloud Drive の中に Vault フォルダを配置するだけで、Apple デバイス間でシームレスに同期される。 ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault 設定コストがほぼゼロで、iOS アプリとの相性も良い。 2. Google Drive / Dropbox / OneDrive クラウドストレージのフォルダ配下に Vault を置くだけで同期が成立する。Windows や Android ユーザーにも対応できる汎用的な方法だ。 Google Drive のデスクトップアプリで同期するフォルダを指定 Vault を ~/Google Drive/MyVault などのパスに配置 モバイルでは公式の Obsidian アプリ + ファイルマネージャアプリで Vault フォルダを指定 3. Git（バージョン履歴も残したい人向け） obsidian-git プラグインを使えば、Vault の変更を GitHub などに自動プッシュできる。 1 2 3 4 # プラグイン設定後、Vault ルートで初期化 git init git remote add origin https://github.com/yourname/my-vault.git git push -u origin main プラグイン設定で自動コミット・プッシュ間隔を指定できるため、バージョン履歴まで残せる点が他の方法と異なる。 ...

背景: 日本語の「言語税」をどこで払うか 先日の記事で、日本語入出力が英語比 1.48 倍のトークンを消費すること、Claude では最大 1.94 倍にもなることを取り上げた。 しかし現実問題、ブログ記事本文・コミットメッセージ・GitHub PR の説明・許可プロンプトなど、最終アウトプットが日本語であること自体が要求であるケースは避けられない。Claude Code を使い続ける限り、日本語コストはゼロにはならない。 問いを言い換えると、こうなる: 「日本語境界を保ったまま、実トークン消費を構造的に減らせる場所はどこか？」 検討した 5 案 案 仕組み 効く場面 弱点 A. 翻訳プロキシ (Ollama) ユーザー入力 ja→en、Claude 応答 en→ja を中間 LLM が翻訳 「思考・指示が日本語で出来ればよい」用途 ツール結果・ファイル内容・git diff まで翻訳経路に入り破綻 B. 部分英語化 思考・指示は英語、最終成果物は日本語のまま 大半の開発作業 削減率は応答側ほど効かない C. Prompt Caching 徹底 CLAUDE.md・Skills・MCP 出力をキャッシュ 日本語のまま実コストを大幅削減 設計工数が必要 D. Caveman プロンプト 「原始人みたいに喋れ」で日本語応答を圧縮 既存実績手法（最大 80% 削減） 文体が崩れるので公開記事には不向き E. モデル切替 Gemini など日本語効率の良いモデルへ部分委譲 翻訳・要約などコモディティ作業 Claude のハーネス連携を捨てる 翻訳プロキシ案 (A) が筋悪な理由 「ローカル LLM で Claude Code の入出力を翻訳する」というアイデアは一見魅力的だが、Claude Code は対話 AI ではなく エージェント環境 であることを思い出す必要がある。 ...

症状 blog-batch.sh で夜間バッチを回した結果、こんな状態になっていた: 同じ wiki ファイル（content/wiki/concepts/harness-engineering.md、content/wiki/tools/claude-code.md）が複数の blog PR で同時に変更されていた main にマージしようとすると毎回コンフリクト 直近の #368・#369・#371・#372 はすべてこの原因で手動コンフリクト解消が必要だった 調査して原因が判明したので、修正内容と「LLM スキルを書くときに気をつけるべきポイント」を共有する。 PR の中身を見ると 3 コミットあった 通常の /blog で作った PR は「記事 1 本分の 1 コミット」のはずだが、見ると 3 コミットあった: 1 2 3 35a61c2 Add blog post: トレーダーのSランクスキル5選... 86e5bd4 Update wiki-last-ingest.txt: mark all posts through 2026-05-07 as ingested 0bc4e1f Update Wiki: ingest posts 2026-04-15 through 2026-04-21 (5 updated, 16 new pages) 2 つ目と 3 つ目は wiki ingest の結果コミット。これが各 blog PR に混入していて、複数 PR で同じ wiki ファイルを並行更新 → コンフリクトという流れ。 ...

結論を先に CLAUDE.md と 4 つの SKILL.md を日本語から英語に書き換えた結果、毎セッション読み込まれる固定資産のトークン量が 13,538 → 8,441（-37.6%、絶対値で 5,097 トークン削減） になった。 文字数は逆に +49% 増えているのに、トークンは大幅に減るという一見矛盾した結果である。理由と内訳を以下に示す。 背景 CLAUDE.md 英語化の記事 と Skills 英語化 PR (#394) の続編。 前 2 つの作業で、ハーネスの「内側」（LLM だけが読む固定資産）を英語化し、「外側」（人間が読むブログ記事や許可プロンプト）は日本語のまま維持する部分英語化パターンを実装した。 ただし、その記事では「Anthropic 公開の日本語比率 1.94x」から 推定 48% 削減 とラフに見積もっていた。実際の効果は推定モデル次第で 2% 〜 48% と幅があり、本当の値を知るには実測しかない。 計測手法 tiktoken (cl100k_base) を採用 理由: オフラインで動く、API key 不要、結果が再現可能 限界: Anthropic Claude のトークナイザーではなく OpenAI GPT-4 系。ただし日本語のトークン化挙動は近似として広く使われる 対案: Anthropic SDK の count_tokens API が最も正確だが、API キーが必要 venv で隔離 PEP 668 で system Python が保護されているため、.claude/temp/venv-tiktoken/ に隔離した venv を作って tiktoken だけ入れた。 ...

開発マシンを放置していると、パッケージマネージャやコンテナ、IDE のキャッシュが気づかないうちに数百 GB に膨れ上がります。本記事では、主要なツールごとにキャッシュを安全に削除するコマンドをまとめます。 パッケージマネージャ系 Python 環境の uv は特に溜まりやすく、100 GB を超えることもあります。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # uv (Python) — 100 GB+ 溜まることも uv cache clean # npm npm cache clean --force # pnpm pnpm store prune # Yarn yarn cache clean # pip pip cache purge # Poetry — `poetry cache list` でキャッシュ名を確認してから個別削除も可能 # 下記の "." は全キャッシュソースを対象にする引数（Poetry バージョンによっては要確認） poetry cache clear --all . # Homebrew — ダウンロード済みアーカイブ brew cleanup --prune=all コンテナ・仮想化 Docker は数百 GB になりがちです。OrbStack / Docker Desktop どちらでも同じコマンドが使えます。 ...

Claude Code を使い続けると、トークン消費が積み重なってコストが気になってくる。X（旧 Twitter）ユーザーの @xiaoying_eth が、トークン消費を最大90%削減できる10のGitHubリポジトリをまとめて紹介している。本記事では出力フィルタリング・シンボル単位参照・プロンプト制御・MCP サーバーという4アプローチで各ツールを分類し、導入しやすいものから解説する。 1. RTK (Rust Token Killer) リポジトリ: rtk-ai/rtk コンテキストに流れ込む前にターミナル出力をフィルタリングするツール。よく使う開発コマンド（cargo build、npm test など）の冗長な出力を削減することで、60〜90% のトークン削減を実現する。Rust 製のため高速で、Claude Code の実際のコーディングセッションでの効果が大きい。 詳細は「RTK（Rust Token Killer）で Claude Code のトークン使用量を60〜90%削減する」を参照。 2. Context Mode リポジトリ: mksglu/context-mode Playwright や GitHub のツール出力を SQLite に転送し、クリーンな要約のみを Claude に送信するアプローチ。生のツール出力をそのままコンテキストに流さないことで 98% の削減を達成している。ブラウザ自動化や CI/CD 連携を多用するワークフローに特に有効。 3. code-review-graph リポジトリ: tirth8205/code-review-graph Tree-sitter を使ってローカルでコードリポジトリをナレッジグラフに変換するツール。ファイル全体を渡す代わりにグラフ構造で必要な情報だけを抽出するため、大型モノリポでは 49倍 のトークン削減が可能。コードレビューや依存関係の調査に向いている。 4. Token Savior リポジトリ: Mibayy/token-savior MCP サーバーとして動作し、ファイル全体ではなくシンボル単位（関数・クラス・変数）でコードを参照するツール。コードナビゲーション操作で 97% のトークン削減を達成。外部依存がゼロなので導入しやすい。 5. Caveman Claude リポジトリ: JuliusBrussee/caveman “原始人の口調” で Claude に話させることで出力トークンを削減するユニークなアプローチ。技術的な正確性は維持しつつ、出力を 65〜75% 削減できる。プロンプトエンジニアリングによる出力スタイルの制御という発想が面白い。 詳細は「Claude を「原始人」口調にするとトークンが 80% 減る話」を参照。 ...

Webスクレイピングの定番ライブラリといえば BeautifulSoup だが、それを最大784倍上回るパフォーマンスを持つ Python フレームワーク Scrapling が注目を集めている。GitHub スター数は約47,000（2026年5月時点）に達する。Cloudflare Turnstile 突破やサイト構造変化への自動適応など、現代のWebスクレイピング課題を一手に解決するのが特徴だ。 Scrapling とは Scrapling は Karim Shoair（D4Vinci）が開発した適応型Webスクレイピングフレームワークだ。単発リクエストからフルスケールクローリングまでをカバーし、以下の3つを柱とする。 Adaptive Scraping: サイトのデザインが変わっても対象要素を自動的に再探索 Anti-bot Bypass: Cloudflare Turnstile 等のアンチボットを標準でバイパス Spider Framework: Scrapy ライクな Spider API で並列クロールをスケールアウト パフォーマンスベンチマーク 5,000 個のネスト要素に対するテキスト抽出速度（100回平均）。出典: 公式 README ベンチマーク： ライブラリ 処理時間（ms） Scrapling比 Scrapling 2.02 1.0x Parsel/Scrapy 2.04 1.01x Raw Lxml 2.54 1.26x PyQuery 24.17 ~12x Selectolax 82.63 ~41x MechanicalSoup 1549.71 ~767x BS4 with Lxml 1584.31 ~784x BS4 with html5lib 3391.91 ~1679x 公式ドキュメントで強調されている「BeautifulSoup 比 784 倍」はこのベンチマークに基づいている。 ...

「Claude Code から Microsoft Teams にビルド結果を投稿したい」「OneDrive のファイルを Claude に読ませて要約させたい」──こうしたニーズは、AI 駆動の開発フローで日常的に発生します。本記事では、初心者でも今日から使える 3 つの方法を、難易度順にセットアップから操作まで解説します。 ...