この春、Claude Code の脇に置く小さな道具を 3 つ作りました — 安価な LLM へ読解・レビュー・チェックを逃がす

はじめに — この春、何を始めたか

今年の春、私は AI コーディングを 日常の作業ライン に組み込みました。具体的には Claude Code を毎日触るようになり、コードレビューも、設計のたたき台も、長い原稿の点検も、まずはここに通すようになりました。

便利だ便利だと言いながら 1 か月使ってみて、2 つだけ、気になることが残りました。

• コンテキスト枠がすぐに埋まる。少し大きめのリポジトリを読ませると、本題に入る前に窓が狭くなっている
• API コストが見えにくい。何回呼んでいくら使ったのか、肌感覚では分からない

「これは賢いモデルにやってもらわなくてもいい仕事だな」というのが、いくつかありました。ディレクトリを順に読んで重大度順に指摘を返す、原稿の表現リスクをひととおり点検する、ログの意味をちょっと聞く — このあたりは、もっと安い OSS 系 LLM に任せて、結果だけ Claude Code（や私）に戻したい。

そう思いまして、この春、Claude Code の脇に置く「補佐」の道具を 3 つ書きました。

• code-aide — Claude Code の補佐。コード読解・レビュー・差分提案を委譲する MCP
• write-aide — ライティング案件の最終チェック・ファクトチェック MCP（code-aide の姉妹）
• kinako-chat — 別ターミナルで動かす、雑談 + cwd 内の読解ができる小さなアシスタント

3 つとも OpenRouter 経由で コストパフォーマンスのよい OSS 系 LLM（Qwen / DeepSeek 等）を主に使い、応答末尾には 常に [usage] in/out tok, 概算 $X を出して、いくら使ったかが見える 状態にしてあります。

「すごいツールを作りました」というよりは、毎日の作業の脇に置いて手間を分担する道具 です。同じような悩みを持っている方の参考になれば嬉しいです。

まとめ（先に結論）

• code-aide: Claude Code から aide__code_review などで呼び、ファイルを渡すと 重大度順の指摘だけ が返ってきます。原文は code-aide 側でだけ読まれるので、呼び出し元の文脈は浪費されません。1 回のレビュー概算 $0.002 程度。
• write-aide: 納品前のライティング記事に wraide check / wraide factcheck をかけると、薬機法・景表法・金商法等の表現リスクと、出典付きファクトチェック が返ってきます。主モデルは Claude Opus、ファクトチェックは Perplexity Sonar。
• kinako: 「あの引数なんだっけ」「このログ何を言ってる」を別ターミナルでサッと聞くための雑談相手。cwd の外に出ない / コードを実行しない / 頼まれた時だけ書く の三重ガード付き。
• 3 つとも pipx install git+https://... で入り、OPENROUTER_API_KEY を 1 本通せば動きます。各リポに .env.sample を同梱しています。
• 私の使い方で 月コストは合計で $4 前後（後ろの試算表に内訳）。応答末尾の [usage] 表示で常に見えるようにしてあります。

設計の方針 — 何を Claude Code に残して、何を脇に逃がすか

最初に決めたのは、Claude Code 自体を万能化しない ということでした。
便利なものに手作業を全部寄せてしまうと、賢いモデルにコスト的に重たい単純作業（ファイル全部読み、表記揺れ点検、出典確認）をさせることになります。これは肌感覚にも反していて、なんだか「贅沢な使い方」になる気がしていました。

判断は Claude Code（と私）に残し、読み込みと一次処理は脇に逃がす。逃がす先は OSS 系の安い LLM（Qwen / DeepSeek 等）で十分という想定です。

絵にするとこういう形です。

flowchart LR
  user[👤 開発者] --> cc[Claude Code<br/>判断・編集]
  cc -- "パスとタスクだけ渡す" --> ca[code-aide MCP]
  cc -- "原稿のパスだけ渡す" --> wa[write-aide MCP]
  user -. "別ターミナル<br/>雑談・軽い読解" .-> kn[kinako-chat]
  ca --> or[OpenRouter]
  wa --> or
  kn --> or
  or --> cheap[安い OSS LLM<br/>Qwen / DeepSeek]
  or --> opus[Claude Opus +<br/>Perplexity Sonar<br/>※ write-aide のみ]
  ca -. "指摘リストだけ返す" .-> cc
  wa -. "指摘リストだけ返す" .-> cc

矢印を見ていただくと一目で分かりますが、Claude Code には「パスとタスク」しか渡らず、戻ってくるのは「指摘リスト」だけです。重いファイル本文は、脇に逃がした道具の中だけで生き、賢いモデルの窓には入ってきません。これが今回いちばん書きたかった分業の形でした。

役割分担は最終的にこの形に落ち着きました。

設計の方針として、3 つに共通させたのは次の 4 点です。

• 呼び出し元は「パスとタスクだけ」渡す。ファイル本文は脇の道具側でだけ読む — 賢いモデルの窓を汚さない
• 応答末尾に毎回 [usage] in/out tok, 概算 $X — コストが常に可視
• MCP として <tool> serve で stdio サーバ起動 — Claude Code から呼べる形を共通化
• pipx install git+... 一行で入る — 入れる側の手間も極小に

最初は code-aide だけのつもりでした。書いてみると同じ骨格で書ける仕事が他にもあって、ライティング案件の最終関門 として write-aide、別ターミナルで軽く聞ける雑談相手 として kinako、と派生していった、というのが全体像です。

code-aide — コーディングの委譲先 / レビュワー

「補佐（aide）」の名のとおり、呼び出し元はパスとタスクだけ渡し、ファイル本文は code-aide 側でだけ読む、という設計です。
返ってくるのは 簡潔な結論だけ なので、呼び出し元のコンテキストを浪費しません。

MCP ツール（6 種）

大きいファイル（既定 5 万字超）は自動でチャンク分割して map-reduce で統合します。
返答は常に「結論ファースト、簡潔に」を強制してあります。

インストールと初期設定

pipx install git+https://github.com/logicia32/code-aide.git

API キーは環境変数 OPENROUTER_API_KEY、または ~/.config/code-aide/.env。
リポジトリ直下に .env.sample を置いてあるので、コピーして埋めるのが楽です。

cp .env.sample ~/.config/code-aide/.env
# OPENROUTER_API_KEY=... を埋める

backend モデルや単価は ~/.config/code-aide/config.toml で差し替えできます。

[model]
model = "qwen/qwen3-coder-plus"
base_url = "https://openrouter.ai/api/v1"
price_in_per_m  = 0.65    # コスト可視化用 USD/百万トークン
price_out_per_m = 3.25

CLI からの使い方

aide review src/ --focus "セキュリティと例外設計"
aide review src/ --thorough                      # 第2パスで見落とし回収
aide ask src/api.py --q "認証フローのエントリは？"
aide task "テストを足して通るところまで" --workspace . --write --exec
aide propose "TypeError を捕まえる箇所を 1 か所追加" --workspace .   # 書込まず diff
aide map src/                                     # LLM 不使用・即時
aide find authenticate src/ --any

Claude Code への登録（MCP）

claude mcp add -s user aide -- aide serve

これで次回起動から、Claude Code 側で aide__code_review などが見えます。
各応答の末尾に [usage] in/out tok, 概算 $X が付く ので、何回呼んでいくらかかったかが常に見えます（review 1 回で概算 $0.002 くらい）。

write-aide — ライティング案件の最終チェック / ファクトチェック

私はソフト寄りの仕事の合間に 副業で技術系のライティング を引き受けることもあり、その流れで作った姉妹道具です。

クラウドソーシングでライティング案件を受けたとき、納品前の最終チェック に時間を取られた経験はないでしょうか。
薬機法・景表法・金商法のグレー表現、表記揺れ、文字数、出典の有無、数字の正しさ……。
人間が漏らしやすい箇所をひととおり機械に点検させて、指摘だけ受け取る 形にしたのが write-aide です。

骨格は code-aide と同じで、原稿全文は内部でだけ読む / 呼び出し元には指摘リストだけ という規律も同じです。
ただ「最終関門」という役割の重さを考えて、主モデルは Claude Opus 4.7、ファクトチェックは Web 検索付きの Perplexity Sonar Reasoning Pro に振ってあります（1 記事 6000 字でおおむね $0.9 程度）。

MCP ツール（5 種）

入力は Markdown / テキスト / .docx に対応しています（Google Docs は .md にコピペして渡す運用）。

インストールと使い方

pipx install git+https://github.com/logicia32/write-aide.git
cp .env.sample ~/.config/write-aide/.env       # OPENROUTER_API_KEY を埋める

wraide check article.md --focus "薬機法"
wraide factcheck article.md --scope "数字のみ"
wraide spec article.md --brief brief.yaml      # 即時・無料
wraide rewrite article.md --focus "ですます調統一"
wraide ask article.md --q "リード文は何字？"

発注仕様（brief.yaml）の例

text_spec は LLM を使わずに、この YAML と原稿を決定論的に突き合わせて結果を返します。

title: "30代女性向け 痩身エステ徹底比較"
genre: "美容・健康"          # ジャンルで法務プロファイルを自動選択
char_count: { min: 5000, max: 6000 }
tone: "ですます調"
headings:
  required: ["H2: メリット", "H2: デメリット", "H2: 選び方"]
keywords:
  primary: { word: "痩身エステ 比較", count: { min: 5, max: 10 } }
references_required: true

法務カバー範囲

ジャンルは brief.yaml の genre: から自動選択され、--focus "薬機法" のように個別法令だけに絞ることもできます。
ルールは外部 YAML なので、~/.config/write-aide/rules/*.yaml に自分用の追加リストを置けます。

Claude Code への登録

claude mcp add -s user wraide -- wraide serve

なお、ファクトチェックの結果には 「最終確認は人間が必ず本文の出典 URL を踏んで再確認すること」 という注意書きが必ず付くようにしてあります。LLM の判定だけで原稿を直すのは怖いので、そこは規律として残しました。

kinako — 別ターミナルで動かす雑談 + cwd 読解アシスタント

最後はだいぶ軽い道具です。kinako は 別ターミナルで動かす独立のアシスタント で、Claude Code とは別の世界で生きています。
名前のとおり「ひまつぶしと、ちょっと聞きたい時の相手」が主用途で、副次的に cwd の中のファイルを読む・要約する・検索する ことができます。

特徴を絞ると、以下のようになります。

• 中立・冷静で、出力は 枠も色もないプレーンテキスト（そのままコピペできる）
• cwd の 外に絶対に出ない（読み書きとも閉じ込め）
• コードを実行しない（実行系ツールを 1 つも持たない）
• 明示的に頼んだ時だけ ファイルを保存する（普段の会話では書かない）
• 会話は cwd の YYYY-MM-DD.log に日次で自動記録

pipx install git+https://github.com/logicia32/kinako-chat.git
cp .env.sample ~/.config/kinako/.env

kinako                              # 対話ループ
kinako --ask "git rebase ってどう違う？"   # ワンショット
kinako --cwd ~/proj                 # 作業ディレクトリ指定

対話の見た目はこんな具合です。

> docs/ のファイル、要点まとめて memo.md に保存して
●kinako docs/ の3ファイルを読みました。要点をまとめて memo.md に保存しました（28行）。
        - 保存しました: memo.md

backend は既定で qwen/qwen3-coder-plus。雑談寄りに振りたいなら qwen/qwen3-235b-a22b-2507、さらに安く deepseek/deepseek-chat でも動きます（~/.config/kinako/config.toml の 1 行差し替え）。

3 つの共通点 — どこを同じにしてあるか

道具をバラバラに使うとそれぞれ設定が散らかるので、3 つで 以下を揃えました。

• APIキーの置き場の優先順: 環境変数 OPENROUTER_API_KEY → ~/.config/<tool>/.env → リポ直下 .env
• .env.sample をリポに同梱（OPENROUTER_API_KEY=replace-with-your-openrouter-api-key だけの薄いやつ）
• config.toml で model / 単価 / temperature を上書き可能
• 応答末尾に [usage] in/out tok, 概算 $X — コストが常に可視
• MCP として <tool> serve で stdio サーバ起動

3 つを 1 つの .env に統合したい誘惑もあったのですが、後から「片方だけ別の API キーで動かしたい」になったときに困るので、完全に独立 させてあります。

どれくらい得をしたか — コストと文脈の実数値

設計の方針のところで 1 回あたりの概算は書きましたが、もう少し噛み砕いた数字をいくつか並べておきます。「逃がす」の効果が見えやすいと思うので。

コスト：1 か月の運用見積もり

私の場合の、ざっくりした 1 か月（個人副業ペース）の見積もりです。

write-aide だけ高いのは、最終関門なので 主モデルを Claude Opus に振ってあるからです。実際のクラウドソーシングのライティング案件 1 件の単価から見れば、出して惜しい額ではありません。

なお、応答末尾の [usage] 表示は OpenRouter の generation API から取り直した実価格（per-million トークン単価）を使っていて、config.toml 内の price_* はあくまでフォールバックです。なので 「公称単価で過小評価」みたいな見え方にはなりにくい はずです。

文脈：賢いモデルの窓を汚さない

Claude Code に「src/ 配下を読んで重大度順にレビューして」と頼むと、ファイル本文を全部読み込ませることになります。中規模リポなら コンテキスト窓の 20〜40% がそれだけで埋まる感覚でした。

これを aide__code_review 経由に変えると、Claude Code 側に返るのは 「重大度順の指摘リスト」というテキストだけ（だいたい数百〜数千トークン）です。ファイル本文は code-aide 側で読み切られていて、賢いモデルの窓には入ってきません。

体感的には、「重い読み込みを一回やったのに、Claude Code のチャットが軽いままで次の話に進める」のが一番大きい変化でした。

機密の取り扱いについて（控えめに）

3 つとも、読んだファイル本文や原稿は OpenRouter 経由で外部 LLM に送信されます。
社内コードや NDA 付きの原稿を流していいかは利用者の判断で、私自身は 公開可能なコード / 自分のラボ実験 / 公開記事のレビュー にだけ使っています。
このあたりは README にも一言入れてあるので、導入前にご確認ください。

動かしてみる — 手元での最短セットアップと、ハマったら見るところ

「pipx install して動きました」までで詰まる場合の見どころを、3 つに共通する形でまとめておきます。

必要なもの

• Python 3.10 以上
• pipx（pip install --user pipx で OK）
• OpenRouter のアカウントと API キー（sk-or-v1-...）
• Claude Code から MCP として呼びたいときは Claude Code 本体

最短手順（code-aide を例に）

# 1. 入れる
pipx install git+https://github.com/logicia32/code-aide.git

# 2. キーを置く（どちらでも。両方ある場合は環境変数を優先）
export OPENROUTER_API_KEY=sk-or-v1-...
#  あるいは
mkdir -p ~/.config/code-aide
echo "OPENROUTER_API_KEY=sk-or-v1-..." > ~/.config/code-aide/.env

# 3. LLM を使わない疎通確認（料金 0 円）
aide map .

# 4. LLM を使う本物の呼び出し（小さいファイルで）
aide review README.md

# 5. Claude Code に MCP として登録
claude mcp add -s user aide -- aide serve

aide map は LLM を呼ばない構造抽出なので、インストールと PATH の疎通だけを 0 円で確かめる のに便利です。aide review まで通れば、API キー読み込みも疎通済みです。

write-aide と kinako も骨格は同じです（pipx install git+... → ~/.config/<tool>/.env → <tool> --help で疎通確認）。

よく詰まるところ

「動かない時に、まずどこを見ればいいか」をできるだけ短く書いたつもりです。それでも詰まったら、issue にスクショつきで投げていただければ追います。

さいごに

3 つを並べて運用してみて感じたのは、「Claude Code はメイン、補佐は安く・薄く・たくさん」 という分担にすると、毎日の作業が一段身軽になるということでした。
高い LLM の窓を汚さない、コストの肌感覚を失わない、機械的な点検は機械に渡す。この春に踏み出した一歩としては、これがいちばん効いた変更だった気がしています。

リポはどれも MIT ライセンスで、pipx install git+https://... 1 行で入るようにしてあります。
バグや「ここ動かない」がありましたら、Issue で教えていただけると助かります（私のペースで読みます）。

• code-aide → https://github.com/logicia32/code-aide
• write-aide → https://github.com/logicia32/write-aide
• kinako-chat → https://github.com/logicia32/kinako-chat

ここまでお読みいただきありがとうございました。