Fable5がサブスクのうちに一生きく資産を残そうとして提案されたもの①|トークン節約系
Claude Fable 5が、モデル延期で最終日が近い。
だから「今後資産に残るものを入れてほしい」と頼んだ。やり方はディープリサーチで世の中の有識者のFable活用方法を検索し、使えなくなっても自律して資産になるものを検索。
最初にAIが出してきた答えは、statuslineとtextlintの2つだけ。理由は「スキル1個ごとに毎セッションの床トークンが増えるから」。
正直、真っ当な理屈に見えた。がFableにしては地味だなと。
「もっと欲しいな。正直AIが出力したトークンが莫大なので、そっちの節約ってあんまり意味ない気がする。例えばmdにある画像のピクセルを抑えるとか、もっと探して。絞りすぎ」
これを言った瞬間、AIの返答が変わった。「その指摘は正しい。インストール物で出力トークンは減らせない。じゃあ入力側で何が残ってるかというと——画像です」。
📋 この記事でわかること
✅ AIの「節約提案」が、なぜ最初は的外れだったか（常駐コストと出力コストの取り違え）
✅ 画像1枚を読ませるコストの計算式（幅×高さ÷750トークン）
✅ Homebrewが入っていないマシンで、その場で圧縮ツールを作った顛末
✅ Claude CodeとCodexのスキルを1本のsymlinkで共有する仕組み
✅ 「モデルが変わっても残る資産」を実際にgit化した数字
✅ 今日から真似できる3行チェックリスト
🤔 AIの節約提案が「浅かった」理由
最初にAIが提案したのは、コンテキスト使用率を表示するstatuslineと、日本語の文章校正ツールtextlintの2つだった。
理由として挙げていたのは「スキルやMCP（AIが呼び出す外部ツール）を1個増やすごとに、毎回の会話の床（最低限乗っかる分）のトークンが増える」という話。これ自体は正しい。実際、このAI環境では過去に「RTK」「lean-ctx」というトークン圧縮ツールを入れていて、その節約実績をrtk gainというコマンドで定期確認する運用になっている。
ただし、この理屈が向いていたのはAIへの入力側の話だけだった。
自分が引っかかったのはそこ。日々の作業でトークンを一番食っているのは、AIが会話中に読む短いログや文章ではない。AIに生成させた大量の出力（コード、記事、画像プロンプト）と、AIに読ませる大きな画像ファイルの方だった。
節約ツールを2個追加しても、この2つには何も効かない。
📸 画像1枚は「幅×高さ÷750」トークン
指摘してから出てきた計算式がこれ。
AIが画像1枚を読み込むコストは、おおよそ幅×高さ÷750トークン
具体的に当てはめると、次の通り。
note記事のサムネイル（1280×670px）：約1,100トークン
画像生成ツールのフル解像度出力：それ以上
LINEスタンプを100個検品する、note記事の図をH2ごとに全部確認する。こういう作業では、文章を圧縮するよりも画像の解像度を絞る方が、桁で効く。ここが今回いちばんの学びだった。
学び：節約は「常駐コスト」と「都度コスト」を分けて考える。前者はツールの数、後者は毎回読ませるファイルのサイズ。両方を同じ物差しで見ると、大きい方を見落とす。
🧩 Homebrewが無くて、その場で作戦変更した話
画像圧縮ツール（imgpeek＝AIに見せる用の縮小プレビュー、imgslim＝配布・入稿用の本圧縮）を作ろうとしたら、想定していたHomebrew（Macの定番パッケージ管理ツール）がこのマシンに入っていなかった。
新規にHomebrewを入れるのは、システム全体に影響する大きめの変更になる。なので一旦手を止めて、「Homebrewを新規に入れるか」「Pillow（画像処理の定番ライブラリ）だけで妥協するか」を確認した。
選んだのはPillowだけで実装する方。圧縮率は本来の方式よりやや劣るが、追加インストールがゼロで済む。実装はuv run --scriptという仕組みを使い、ファイルの中に必要なライブラリを書いておくだけで、専用の実行環境が自動的に用意される形にした。
実機で3パターン検証した。
✅ 1600×900pxの画像 → 768×432pxに縮小しプレビュー生成
✅ 6.2KBの画像 → 幅1280px指定で3.7KBに圧縮
✅ note入稿用のヘッダー画像（1280×670px固定）→ 幅を指定しても寸法は変わらず、圧縮だけ実行
想定した道具が無い時に、条件を変えてでも動くところまで持っていく。この泥臭さは自動化やAI活用の記事だとよく飛ばされるが、実際の作業時間の大半はここに使う。
🔗 Claude CodeとCodexを1本のsymlinkでつなぐ
もう1つの軸は、2つのAIツール（Claude CodeとCodex）の連携。普段はこのルールで役割を分けている。
Claude CodeもCodexも、依頼された作業は自分で完遂する前提で動く。「これはClaude担当」「これはCodex担当」と役割で逃がさない。
この前提の上で、文章の校正スキルなどツールに依存しないものだけ、Codex側の実体ファイルをClaude側からsymlink（参照リンク）でつなぐ設計にした。正本は1つ、参照は複数。片方だけ画像生成機能に依存しているスキルは、あえて共有しない。
さらに、重要な判断だけAIの2つ目の意見（セカンドオピニオン）を取れる仕組みも用意した。日常のタスクでは使わず、迷った時だけ発火する設計にしてある。
📦 「モデルが変わっても残る」を数字にする
今日いちばん意識したのはこれ。
モデルは消えるが、ファイルは残る。
Fable 5がモデル最終日を迎えても、その日にAIと一緒に作ったスキル・設定・ルール文書はマシンに残り続ける。逆に言えば、特定のモデルの挙動に依存する設定は、資産として数えない。
これを徹底するために、資産そのものをバージョン管理システム（git）に入れた。
スキル置き場（約120個）→ そのまま全部コミット
AIツールの設定フォルダ → ホワイトリスト方式で認証情報やログを絶対に含まない17ファイルだけを選んで追跡
ホワイトリスト方式というのは「全部を無視した上で、許可した物だけ明示的に戻す」書き方。うっかり秘密情報が紛れ込む事故を防げる。コミット前には認証・パスワード・データベース関連の文字列が入っていないか機械的に確認してから実行した。
✅ 今日から使えるチェックリスト
節約や資産管理を考えるときに、そのまま流用できる3行。
入力コストと出力コストを分けて数える。ツールの数を減らすのは前者にしか効かない
画像・PDF・動画は「幅×高さ÷トークン単価」で見積もる。文章より桁違いに効く場合がある
「モデル固有の挙動」と「ファイルとして残る資産」を分けて判断する。前者はどうせ消える
🌟 まとめ
Fable 5が最終日付近だからこそ、今日は「お別れの作業」ではなく「引っ越しの作業」をした。次のモデルが来ても、今日作ったスキルとgitの履歴はそのまま使える。
またGithubやredditではまだまだ有識者がFableで資産を残すために最適な方法を沢山案だししているので紹介できればと思っている。
読者のみなさんは、AIエージェントを複数使い分けている時、「モデルが変わったら消える設定」と「残る資産」を分けて考えたことがありますか？
スキを押してもらえると次を書く励みになります🌟
#AI活用 #ClaudeCode #Codex #トークン節約 #エンジニア #個人開発 #自動化 #生成AI #副業 #人間のバグ
