# Mac で AI コーディングツールが残したものを片付ける方法 > AI コーディングツールが残すビルド成果物、古い CLI、会話履歴を確認します。容量だけでなく、用途と復元にかかる手間を確かめてから整理します。 Published: 2026-08-21 | Updated: 2026-10-05 二年間余裕があったディスクが、コーディングエージェントを毎日使い始めてから数か月で満杯になることがあります。エージェント自体は小さいものです。変わったのは、マシンがどれだけの頻度でコンパイルするか、CLI がどれだけの頻度でディスク上の自分自身を置き換えるか、そしてあなた自身の思考のどれだけがテキストとしてホームディレクトリに残るようになったかです。増加分のほとんどは三つのカテゴリに収まり、それぞれ取り戻すコストがまったく違うので、必要な判断も三通りです。 モデルの重みは分かりやすい容疑者ですが、この問題に関しては大抵見当違いです。Ollama、LM Studio、Hugging Face はそれぞれ自分のツールでしか安全にプルーンできないコンテンツアドレス方式のストアを保持していて、これは別に[AI ツールの残渣を取り除く](https://mole.fit/ja/blog/how-to-remove-ai-tool-leftovers-mac)で扱っています。この記事が扱うのは、作業中に AI コーディングエージェントが残していくものについてです。 ## 削除する前に測る 二つのコマンドでほとんどの答えが分かります。最初のコマンドはエージェントのホームディレクトリを合計します。 ``` du -sh ~/.codex ~/.claude ~/.local/share/claude ~/.grok ~/.cache 2>/dev/null | sort -h ``` 二つ目のコマンドは、これまで開いたすべてのプロジェクトに散らばったビルド出力を見つけます。ルートは自分がコードを置いている場所に置き換えてください。 ``` find ~/www ~/Projects -maxdepth 3 -type d \ \( -name target -o -name node_modules -o -name .next -o -name dist -o -name build \) \ -prune -exec du -sh {} + 2>/dev/null | sort -h | tail -20 ``` `-prune` は、`find` がすでにマッチしたディレクトリの中へ降りていくのを止めます。これがここでは重要で、これがないと `find` は先に進む前に 24 GB の `target/` の中のすべてのファイルを歩いてしまいます。この記事を書きながら測定した Mac では、上位二行は 24 GB の Rust の `target/` と 9.8 GB の Tauri プロジェクトの `target/` で、対する `node_modules` のツリーは 134 MB から 1.5 GB の範囲でした。この比率こそが要点です。依存関係の問題に見えていたものは、実際の数字のわずか 2% でした。 リストよりマップで見たいなら、[Mole](https://mole.fit/) の分析画面で同じボリュームをツリーマップとして表示し、大きな区画を開いて中身を確認できます。`find` に渡すルートを推測する必要はありません。 ## カテゴリ一、増幅されたビルド出力 このカテゴリ自体は目新しくありません。新しいのは量です。手作業で開発する人は一日に数回コンパイルします。タスクをこなすエージェントは編集のほぼ毎回コンパイルし、テストを実行し、二つ目のアプローチを試し、また再コンパイルします。以前は数か月かけて増えていたキャッシュが、今では一日の午後だけで増え、インクリメンタルビルド用のディレクトリはそもそもディスクを引き換えに速度を買う設計です。 **Rust** は通常、大差をつけて最大です。`target/` ディレクトリにはコンパイル済みの依存関係、インクリメンタルコンパイルの状態、ビルドスクリプトの出力が入り、プロファイルごとに別々に保持されるので、debug と release は丸ごと二つのコピーになります。オプションなしの `cargo clean` は「target ディレクトリ全体を削除します」。まずプレビューしてください。 ``` cargo clean --dry-run cargo clean --release ``` `cargo clean -p ` は指定したパッケージだけをクリーンします。ワークスペースの一つのメンバーだけが問題なら、これが正しい道具です。 **JavaScript** は出力が薄く広がります。`node_modules` そのものに加えて、`node_modules/.cache`（バンドラーやトランスパイラが使う）、Next.js ビルド用の `.next`、そしてツールチェーンが書き出す `dist` や `build` があります。キャッシュだけを狙って見つけてください。 ``` find ~/www -maxdepth 4 -type d -path '*/node_modules/.cache' -prune -exec du -sh {} + \ 2>/dev/null | sort -h | tail ``` **Python** はインポートするパッケージのすべての隣に `__pycache__` を残します。一つひとつは小さくても、数は何千にもなります。削除する前に数えてください。同じ形のコマンドの末尾に `rm -rf` を付けたものは、ルートを間違えると容赦がありません。 ``` find ~/www -type d -name __pycache__ -prune -print | wc -l ``` ソースが残っていれば、バイトコードキャッシュは次のインポート時にネットワークなしで再生成されます。関連する処理を止め、対象がキャッシュだけであることを確認してから削除します。 **Go** はプロジェクトごとのディレクトリではなく、一つのグローバルビルドキャッシュを保持します。`go env GOCACHE` がその場所を表示し、`go clean -cache` は「go ビルドキャッシュ全体を削除する」動作です。`go clean -testcache` はコンパイル済みパッケージを破棄せずにキャッシュ済みのテスト結果だけを失効させます。私のマシンではビルドキャッシュが 183 MB、モジュールキャッシュが 38 MB だったので、ダウンロードされたモジュールが小さくてもビルド側は確認する価値があります。 **Xcode** は独自の扱いが必要です。DerivedData、アーカイブ、デバイスサポート、シミュレータランタイムは四種類のもので、それぞれ復元コストが違うからです。この Mac では DerivedData フォルダが 9.3 GB ありました。[Xcode のストレージを片付ける](https://mole.fit/ja/blog/how-to-clean-up-xcode-mac)で、どれを削除できてどれをシンボリケーション用に残すべきか扱っています。Gradle と Maven も同じようにプロジェクトごとの `build/` ディレクトリと `~/.gradle` や `~/.m2` 下のグローバルストアに分かれ、グローバル側は[開発キャッシュを片付ける](https://mole.fit/ja/blog/how-to-clear-dev-caches-mac)にある他のレジストリと同じ扱いです。 ## カテゴリ二、置き換えられた CLI バージョン これはほとんど誰も探そうとしないカテゴリで、複数のエージェントを動かしているマシンでは、すべてのキャッシュを合わせたより大きいことがよくあります。 エージェント CLI は、完全な新しいバージョンのリリースをまるごとダウンロードし、ランチャーの参照先をそちらに向けることで自己更新します。各リリースは自己完結していて、前のリリースとファイルを共有しません。ポインタは動きますが、古いリリースはそのまま残ります。誰も掃除しないので、更新のたびに数は一つずつ、永遠に増え続けます。 配置はどれも見た目の違いこそあれ、同じパターンに従っています。 - **Codex** は `~/.codex/packages/standalone/releases/-/` を保持し、一つ上の階層にある `current` シンボリックリンクが生きているものを指します。 - **Claude Code** は `~/.local/share/claude/versions/` を保持し、各エントリはディレクトリではなく単一の実行ファイルで、`~/.local/bin/claude` が生きているものへのシンボリックリンクです。 - **Grok** は `~/.grok/downloads/grok--macos-` をファイルとして保持し、`~/.grok/bin/grok` と `~/.grok/bin/agent` が現行ビルドを指します。 - **Cursor Agent** は `~/.local/share/cursor-agent/versions/-/` を保持し、`~/.local/bin/cursor-agent` がランチャーです。 - デスクトップ版の **Cursor** も自前の cursor-agent を `~/Library/Application Support/Cursor/User/globalStorage/anysphere.cursor-agent-worker/agent-cli/.local/share/cursor-agent/versions/` に保持し、同じ `.local` の `bin/cursor-agent` が生きているものを指します。後から測った Mac では 7 つのリリース、合計 4.1 GB が残っていました。 - npm 経由でインストールされる **GitHub Copilot CLI** は自分自身をその場で置き換えますが、インストールスクリプトは、root 以外のユーザーでは既定で `$HOME/.local` になるプレフィックスの下に、バージョン付きのパッケージを書き込みます。Mole は同じ形として `~/.copilot/pkg/universal` を確認します。 まとめて一度に測ってください。 ``` du -sh ~/.codex/packages/standalone/releases/* \ ~/.local/share/claude/versions/* \ ~/.grok/downloads/* \ ~/.local/share/cursor-agent/versions/* 2>/dev/null ``` この記事のために使った Mac では、262 MB から 310 MB の Codex のリリースが五つ、293 MB から 306 MB の Claude Code のバイナリが五つ、Grok のビルドが二つ、Cursor Agent のバージョンが二つと表示されました。合計でおよそ 3.5 GB、そのうち生きていたのは約 920 MB だけです。それ以外はすべて、すでに置き換えられたバイナリでした。Codex 自身の課題管理には、この件についての未解決の要望があり、報告者は更新のたびにおよそ 250 MB ずつ増えると測定しています（[openai/codex#22293](https://github.com/openai/codex/issues/22293)）。 ### ディレクトリを一つでも消す前にランチャーを解決する つい取りたくなる近道は、日付順に並べて最新のものを残すことです。それはやめてください。ありふれた二つの状況がこれを壊します。リグレッションのあとに意図的に古いバージョンに固定した場合と、アップデートがポインタを切り替える前に新しいディレクトリをステージングしていた場合です。生きているリリースを消すと、どこも指していないランチャーだけが残ります。 代わりにランチャーに聞いてください。これはシンボリックリンクなので、解決すればいいだけです。 ``` readlink -f "$(command -v codex)" readlink -f "$(command -v claude)" readlink -f "$(command -v grok)" ``` これで実際の参照先、たとえば `~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex` が表示されます。`ls -l "$(command -v codex)"` で見えるリンク先が、最終的な参照先とは限りません。この結果で分かるのは現在のランチャーが使うバージョンだけです。同じ階層の別バージョンを削除するには、ほかのプロセスが使っていないか、更新が進行中でないかも確認します。判断できないものは残し、確認できたものだけをゴミ箱へ移します。その後に CLI の動作を確かめ、すぐにはゴミ箱を空にしないでください。
PATH 上のランチャーが current を経由して一つのリリースを参照する図。同じ階層の別バージョンは、ほかのプロセスや更新処理が使っていないか確認が必要です。
生きているリリースを特定するのはタイムスタンプではなくランチャーです。意図的な旧バージョン固定も、途中で止まったアップデートも、どちらも最新のディレクトリを間違った答えにします。
## カテゴリ三、ジャンクではないエージェントの作業状態 三つ目のカテゴリは、クリーナーが本当の被害を与えかねない部分です。最初の二つとまったく同じように見えるからです。 セッションのトランスクリプト、メモリ、プラン、生成された添付ファイルは `~/.codex/sessions`、`~/.codex/archived_sessions`、`~/.codex/memories`、`~/.claude/projects`、`~/.grok/sessions` にあります。これらはセッション ID で名付けられ、タイムスタンプが付き、追記のみで、増え続けて止まることがない JSONL ファイルです。汎用クリーナーが使うあらゆるヒューリスティックは「ログファイル」だと言います。私が測定した Mac では、`~/.codex/sessions` が 9.8 GB、`~/.claude/projects` が 2,362 個のトランスクリプトファイルにわたって 2.7 GB、`~/.grok/sessions` が 1.3 GB でした。使い捨てに見えるファイルに、大きくて誘惑的な数字が付いているということです。 これらはログではありません。トランスクリプトは、ある変更がどうやってそこに至ったかの記録です。試して却下したアプローチ、それを退けた制約、最終的な形が今の形になった理由。その推論はどこにも他には存在しません。コミットメッセージは何が変わったかを記録し、コードは生き残った選択肢だけを記録し、却下された四つの選択肢は記録しません。何か月分もが静かに積み重なり、なぜそう作られたのかを後から問い直しに戻ったときに初めて、その価値に気づきます。 より大きなリスクはサードパーティのクリーナーではありません。Claude Code は自前の保持期間による一掃機能を持っています。`cleanupPeriodDays` の既定値は 30 日で、起動時にそれより古い `projects/` 配下のトランスクリプト、プランファイル、`file-history/` 内の編集前スナップショット、セッションごとのタスクリストを削除します。[.claude ディレクトリのリファレンス](https://code.claude.com/docs/en/claude-directory)には、どのパスが一掃され、どのパスが無期限に保持されるかが正確に書かれています。一年分のトランスクリプトを残したいなら、既定値を後から発見するのではなく、今のうちにその数字を上げておいてください。同じページには逆のケース、つまり一つのプロジェクトの状態を意図的に消したい場合のための `claude project purge` も書かれています。 [Mole](https://mole.fit/) のクリーンはこれらのどれにも触れません。この五つのパスに加えて `~/.claude/file-history`、`~/.claude/plans`、`~/.claude/tasks`、`~/.codex/attachments`、`~/.codex/generated_images` も、どれだけ古くても保護リストに入っています。年齢による除外はなく、「90 日より古い」といった例外もなく、それを有効にする設定もありません。かつてこれらのパスに年齢ゲート付きの例外を実装したことがありましたが、同じ日のうちに差し戻されました。古いトランスクリプトは、古びたトランスクリプトではないからです。 古いセッションには、あなたが自分で選ぶ別の道があります。クリーン画面の遠くにある月からAIクリーンアップとケアに入ると、ツールごとに保存期間を設定でき、それを過ぎたCodexとClaude Codeのセッション、それにプロジェクトフォルダがなくなったClaude Codeのセッションが、タイトルと日付つきで並びます。あなたがチェックするまで何も消えず、Codexのセッションはまずゴミ箱にコピーしてからCodex自身のコマンドで削除するのでインデックスも崩れず、Codexがそのセッションのために生成した画像やメモも一緒にゴミ箱へ移ります。過去24時間に使ったセッションはリストに出ないので、CodexやClaude Codeを開いたままでも整理でき、メモリ、プラン、スキルはそこでもどのリストにも載りません。 ## 仕組みを覗く、サイズではなく復元コストで並べる これが三つのカテゴリすべてを判断可能にするルールで、この記事の中で覚える価値があるのはこれだけです。すべての候補を、何ギガバイトあるかではなく、取り戻すのに何を払うかで順位付けしてください。 **ローカルで再生成できるもの。** ビルド出力、インクリメンタルコンパイルの状態、バイトコードキャッシュ、DerivedData。ソース、依存関係、ツールチェーンがそろっていれば、通常はローカルで再生成でき、主な負担は再ビルドの時間です。ビルド、テスト、開発サーバーを停止し、残すべき出力が混ざっていないことを確認してから削除します。 **再構築に手間がかかるもの。** パッケージレジストリ、`node_modules`、CocoaPods、Python の仮想環境、`vendor` ディレクトリ、モデルの重み、iOS の DeviceSupport。どれもネットワークと、ロックファイルが指定する正確なバージョンをまだ配信しているレジストリを必要とし、時にはネイティブのツールチェーンも要ります。本当のコストは、良い回線での数分ではなく、電車の中でそもそも作業できるかどうかです。これらは一つずつレビューしてください。 **取り返しがつかないもの。** チャットのトランスクリプト、エージェントのメモリ、プランファイル、プロジェクトの状態、ローカルのファインチューン。どれだけ CPU や帯域を積んでも取り戻せません。一括削除の対象には決してしてはいけませんし、うっかり選択できてしまうような扱いにもしてはいけません。 罠は、階層一と階層二が同じに見えることです。`target/` と `node_modules/` はどちらもプロジェクトルートにある大きなディレクトリで、どちらも依存関係の成果物でいっぱいで、どちらも `.gitignore` に載っていて、どちらも一つのコマンドで再生成できます。サイズで並べると隣り合います。ですが `cargo build` はすでにディスク上にあるソースから `target/` を再構築するのに対し、`npm ci` はレジストリがまだ動いていて、ロックファイルがまだ解決できることを必要とします。片方はコーヒー休憩で済みますが、もう片方は午後まるごと止まるか、再インストールできない取り下げ済みパッケージに突き当たることもあります。この二つを混同することが、このカテゴリで最もよくある間違いで、だからこそ「一番大きいフォルダを消す」は、たとえ一番容量を空けられるとしても悪いアドバイスなのです。
復元コストで順位付けされた三つの階層。target と node_modules は見た目が同じプロジェクトディレクトリなのに、片方はローカルのソースから再構築でき、もう片方はレジストリを必要とするため異なる階層に落ちる。
サイズで並べると候補の順番を間違えます。プロジェクトルートで見た目が同じ二つのディレクトリでも、復元するコストは丸一日の作業日分も違うことがあります。
## これを Mole でやる 手作業のやり方はうまくいきますし、コストもかかりません。[Mole](https://mole.fit/) が加えるのは、三つのカテゴリすべてが、階層の境界線をすでに適用済みの一つのレビューリストとして届くことです。どのドットディレクトリにトランスクリプトが入っているか、あなたが覚えておく必要はありません。 クリーン画面でスキャンを実行します。スキャンは無料で、ライセンスも不要です。候補にはパス、関連するアプリ、サイズが表示され、リストを確認するまでは削除されません。確認が必要な項目は初期状態では選択されません。キャッシュは初期設定では完全に削除されます。設定でゴミ箱へ移す方式に変更でき、ゴミ箱に残っている間は復元できます。一括操作の結果には、削除した項目だけでなく、スキップや失敗も表示されます。 置き換えられた CLI バージョンについては特に、Mole が上で説明したランチャーの解決をあなたの代わりにやってくれます。各エージェント CLI のランチャーのシンボリックリンクを読み、生きているリリースまで解決して、そのリリースを候補集合から除外します。だから意図的な旧バージョン固定は、古いバージョンとして扱われることなくそのまま残ります。この挙動の背景にある実測ケースは Codex で、1.2 GB の五つのリリースのうち生きているのは一つだけでした。デスクトップ版 Cursor が自前で持つコピーも同じ方法で扱い、どのプロセスも使っていない古いリリースなら、Cursor を開いたままでも整理できます。 [Mole CLI](https://github.com/tw93/Mole) は無料でオープンソースです。ターミナルから `mo clean` で清掃でき、clean、uninstall、optimize は `--dry-run` に対応しているため、実行前に候補を確認できます。ユーザーが登録した保護リスト `~/.config/mole/whitelist` をアプリと共有し、操作は `~/Library/Logs/mole/operations.log` に記録します。処理はローカルで完結し、アップロードやテレメトリはありません。
Mole のクリーン確認画面。キャッシュをカテゴリごとにサイズ付きで一覧し、それぞれにチェックボックスがあり、下部に選択中の 5.14 GB を完全に削除するボタンがある。
発見と削除は別々の二つのステップです。確認画面はスキャンで見つかったものをカテゴリごとに一覧し、確定するまで何も削除しません。
はっきり言っておく価値があります。Mole はバックアップではなく、マルウェア対策でもなく、ドライバやシステム拡張を伴うソフトウェアのベンダー製アンインストーラの代わりでもありません。モデルのファイルを自分で消すことはなく、通常のクリーンアップは AI のチャット履歴にも触れません。古いセッションと1か月使っていない Ollama のモデルは AIクリーンアップとケアで一つずつチェックしたものだけが処理され、モデルは Ollama 自身のコマンドで削除し、ほかのモデルは所有しているツール側に任せます。 ## また積み上がらないようにする 三つの設定変更で、再び積み上がる分のほとんどをカバーできます。 **Rust を一つのビルドディレクトリに集める。** `CARGO_TARGET_DIR` は「生成されたすべての成果物を置く場所」を設定するので、すべてのプロジェクトが一つのツリーに書き込むようになり、一か所で測定してクリーンできます。トレードオフは本物です。Cargo はビルドディレクトリをロックするので、一つの target ディレクトリを共有する二つのプロジェクトは並行してではなく一つずつビルドされます。日常的に並行ビルドを行うなら、分けたままにして代わりに定期的な一掃をスケジュールしてください。 **グローバルストアは手作業ではなくスケジュールでプルーンする。** 最近の Cargo は通常のビルドや fetch コマンドの中で、すでに未使用のエントリをグローバルキャッシュから取り除いています。npm は自分のキャッシュを自己修復するものと説明していて、メンテナンスコマンドとして `npm cache verify` を挙げています。ホームディレクトリのドットフォルダをいきなり削除するのではなく、こうしたポリシーに任せてください。ツールごとのコマンドは[開発キャッシュを片付ける](https://mole.fit/ja/blog/how-to-clear-dev-caches-mac)にあります。 **エージェント CLI が自分でリリースをプルーンするか確認し、しないものと想定する。** この記事を書いている時点では、Codex と Claude Code のどちらにも、置き換えられたリリースバイナリをプルーンするドキュメント化されたフラグや設定キーは見つかりませんでしたし、Codex への要望も未解決のままです。Claude Code の `cleanupPeriodDays` はセッションデータを一掃するものであってバージョンのバイナリではないので、ここでは役に立ちません。それが変わるまでは、これは繰り返し発生する作業であり、エージェントがアップデートを出すたびに戻ってくるので、このリストの中で最も価値の高い項目です。 ## よくある質問 ### AI コーディングツールは実際どれだけディスクを使いますか バイナリは一つあたり数百メガバイトですが、大事なのは積み重なった量です。この記事のために測定したマシンでは、四つのエージェント CLI がバージョンディレクトリ全体でおよそ 3.5 GB を占めていて、そのうち生きていたのはわずか 920 MB でした。セッションのトランスクリプトはおよそ 14 GB、一つの Rust の `target/` ディレクトリだけで 24 GB でした。あなたの数字は、エージェントよりも言語によって違ってくるはずなので、この記事も含めて誰かの数字を信じるのではなく、この記事の冒頭にある二つの `du` コマンドを自分で実行してください。 ### 古い Claude Code や Codex のバージョンを削除しても安全ですか まず使われていないバージョンを確認します。`readlink -f "$(command -v claude)"` などで参照先を調べ、そのバージョンは残します。ほかのバージョンも、プロセスや更新処理が使っていないことを確認してからゴミ箱へ移します。日付だけで判断せず、不明なものは残してください。移動後に CLI の動作を確かめ、しばらくは戻せる状態にしておきます。 ### Mac クリーナーはエージェントのチャット履歴を削除しますか 一部のクリーナーはそうします。これらのファイルはログにそっくりに見えるからです。それがこのカテゴリ特有のリスクです。Mole の通常のクリーンアップは `~/.codex/sessions`、`~/.codex/archived_sessions`、`~/.codex/memories`、`~/.claude/projects`、`~/.grok/sessions` のどれにも、どれだけ古くても触れません。どんなクリーナーを実行する前でも、これらのパスがその候補リストに現れるかどうか確認してください。実行前にリストを見せてくれないツールなら、それが答えです。独立した AIクリーンアップとケア画面では、ツールごとの保存期間を過ぎた Codex と Claude Code のセッション、それにプロジェクトがなくなった Claude Code のセッションを、チェックなしの状態で表示し、個別に確認してから処理します。 ### ビルドキャッシュを消すと何か遅くなりますか 通常は次のビルドが遅くなり、キャッシュが再生成されるにつれて元に戻ります。ソース、依存関係、ツールチェーンが残っていることが前提で、削除前に関連するビルドやテストを止める必要もあります。再生成しやすいからといって、使用中に削除してよいわけではありません。`node_modules` のように再ダウンロードが必要なものは、ネットワークや配布元が利用できるかも確認します。 ### Ollama のモデルや Hugging Face のキャッシュはどうですか ここでは意図的に範囲外にしています。これらのツールは、二つのモデルが同じ塊を共有できるコンテンツアドレス方式のストアを使っているので、ファイルを手で消すと、まだそれを参照しているモデルを孤立させてしまうことがあります。それぞれのツール自身の削除コマンドを使ってください。詳しくは[AI ツールの残渣を取り除く](https://mole.fit/ja/blog/how-to-remove-ai-tool-leftovers-mac)で扱っています。Mole が扱う唯一の例外は Ollama のモデルで、AIクリーンアップとケアは1か月使っていないものを挙げ、チェックしたものを Ollama 自身の `ollama rm` で削除するので、ほかのモデルがまだ使っている塊は残ります。 ## 次にどこへ行くか 復元コストで並べ、リリースを消す前にランチャーを解決し、トランスクリプトには触らないでください。測定結果で一番大きかった行がパッケージストアだったなら、ツールごとのプルーンコマンドは[開発キャッシュを片付ける](https://mole.fit/ja/blog/how-to-clear-dev-caches-mac)にあります。Xcode だったなら、[Xcode のストレージを片付ける](https://mole.fit/ja/blog/how-to-clean-up-xcode-mac)が、再構築できるフォルダと残しておくべきアーカイブを分けています。モデルストアだったなら、[AI ツールの残渣を取り除く](https://mole.fit/ja/blog/how-to-remove-ai-tool-leftovers-mac)が、なぜ所有ツールが削除を担うべきなのかを説明しています。 --- Canonical HTML page: https://mole.fit/ja/blog/how-to-clean-up-ai-coding-tools-mac Blog index for agents: https://mole.fit/ja/blog/llms.txt Site index for agents: https://mole.fit/llms.txt