メインの文脈を節約して、品質を上げコストを下げる ── Context Drop を作るまで

上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

メインの文脈を節約して、品質を上げコストを下げる ── Context Drop を作るまで

メインの文脈を節約して、品質を上げコストを下げる ── Context Drop を作るまで

1. フック + テーゼ

ある時期から、Claude Code が「壊れる」ようになった。

正確に言えば、壊れたのは Claude Code そのものではない。壊れたのは、私たちの 使い方 だった。多エージェントを一気に走らせ、巨大なログやスクリーンショットを会話に貼り付け、長いセッションを /compact でつなぎながら回し続ける ── Claude Code の「ultracode」を on にして、重いファンアウトを当たり前のように回す運用だ。これを続けていると、ある日突然、tool 呼び出しが生のテキストとして会話に漏れ出したり、モデルが考え込んだまま一言も返さなくなったりする。

記録を見る限り、不具合群の共通項は context の肥大化 だった（因果は相関レベル、§2 参照）。会話が膨らむほど毎ターンの再送コストは増え、破損の発火条件に近づき、応答は不安定になる。

Context Drop は、この問題の一点 ── 「生の文脈（raw context）をメインの会話に直接流し込む」習慣 ── を断つために作った小さなデスクトップツールだ。スクリーンショットやログや JSON を、メインの会話ではなく 隔離されたサブエージェント（メインとは別の会話履歴で動く、作業担当の AI）に読ませ、戻ってくるのは要約（compact result）だけ。メインの文脈は軽いまま保たれる。

本稿では、まず「なぜ重い運用で壊れるのか」と「effort / model / ultracode をどう使い分けるか」を前提知識として整理し、そのうえで Context Drop とは何か・どう使うか・どうインストールするかを、画面キャプチャ入りで説明する。

2. 背景① ── なぜ壊れたのか（ultracode と context 肥大）

"ultracode" とは何か ── Claude Code の opt-in で、トークン費用を制約とみなさないモード

はじめに用語を正しておく。「ultracode」は Claude Code 側の opt-in の仕組みだ。プロンプトに ultracode というキーワードを含めるか、セッション全体で on にすると有効になる。社内の設計記録が定めた常時オンのモードではない。

on の間、モデルは実質的な作業のたびに 多エージェントの Workflow を組んで指揮 し、しかも トークン費用を制約とみなさない（トークンは、AI が入力と出力の量を数える単位で、料金もこれで決まる）。だから自然と巨大なファンアウトになる。実際、社内の記録には、v0.256.0 の 77 エージェント敵対レビューは義務ではなく裁量（ultracode）で起動したとある。規則で義務づけられていたわけではなく、ultracode を付けたからこその規模だった。

強力なのは間違いない。ただ、その裏で積み上がるのが context とトークン だ。「賢いモデルに、大量の文脈を、たくさんのエージェントで、一気に噛ませる」── この運用が積み上げる context こそが、次に挙げる不具合群の共通項だった。

症状その1 ── tool 呼び出しが "count / court" に化ける

もっとも厄介だったのが、Opus 4.8 系で起きる tool-call 破損だ。本来なら構造化された tool_use になるはずの tool 呼び出しが、生テキストとして会話に漏れ出す。内部の制御タグが count / court / call といった 実在する英単語 に化け、パーサが「tool call could not be parsed」と音を上げる。

その発火条件が示唆的だ ── Opus 4.8/4.7、長大なコンテキスト（1M セッション）、/compact 直後、日本語など非 ASCII の引数、3 つ以上の MCP サーバ、長い tool 引数、複数 tool の同時実行。要するに「重く・長く・多言語で・詰め込んだ」状態ほど起きやすい。

さらに悪いのは、一度壊れた履歴が自己強化する こと。同じセッションでリトライしても悪化するだけで自己修復しない。直し方は「前に進む」ことではなく「戻る」こと ── /rewind → /compact → /clear であって、--continue ではない。

なお、「context の肥大 → 破損」という因果は、記録上は相関レベルの裏付けにとどまる。また hook（決まったタイミングで自動実行される処理）から /compact を自動実行することはできない。だからこそ、肥大させない習慣そのものが効いてくる。

症状その2 ── compact 直後の再肥大、marathon 後の無言化

/compact は会話を圧縮して軽くするための機能だ。ところが、セッション開始時に 19〜32 KB のダイジェストを自動で再注入する仕組みが走っていたため、compact の直後に縮んだ分が打ち消され、発火条件が再び作られていた。「compact したのに、すぐ肥大する」── その機序が記録に残っている。

もう一つの顔が、長時間（marathon）セッション後の 完全な無言化。Opus がまったく出力しなくなる。同じ要求を新しいセッションで投げれば即答する ── 溜まった context が最有力の差分だった。

「全部を最大の設定で回せばいい」は成り立たなかった

ここまで読むと、「難しいなら、Claude Code をいちばん上の設定で使えばいいのではないか」と思うかもしれない。モデルを大きくし、effort を上げ、ultracode でエージェントを増やせば頭が良くなるのなら、お金さえ気にしなければ、最初から全部をいちばん賢い設定で回せばいい ── という考え方だ。

私たちも実際にそれに近い運用をしていた。そして、問題はそこで起きた。上に挙げた破損の発火条件を見直してほしい。Opus の最上位モデル、1M の長大なコンテキスト、多エージェントのファンアウト。どれも「最大の設定」そのものだ。最大の設定で回すほど会話は膨らみ、膨らんだ会話の中で tool 呼び出しが壊れ、応答が止まった。

つまり、これはコストの問題である前に 品質の問題 だった。因果は相関レベルの裏付けまでだが、私たちは、お金をかけて文脈を積み上げたこと自体が品質を下げていたと判断した。お金で品質を買っていたつもりが、実際にはお金を使って品質を下げていたことになる。だから答えは「もっと上の設定にする」ではなく、「メインの会話に何を入れないか」を決めることだった。

なぜ context が重いとお金も飛ぶのか

破損だけではない。コストの観点でも context 肥大は効く。Claude Code は毎ターン「それまでの会話全体 + 全 tool 結果」を入力として 再送・再課金 する。記録にある試算では、20k トークンのログを 1 回読むと、残り 30 ターンで 約 85k トークン相当 を払い続ける。200 トークンのダイジェストなら 約 0.9k ── 約 100 倍の差だ。しかも大きな読み込みは compaction の到来を早め、前述の破損リスクへ近づける。

極端な例として、重いゲートを全量適用したファンアウトで 1 本のブログ記事を処理したら、サブエージェント込みで 約 80 万トークン・親 context 289k を消費した事例も残っている。

肝 ── 「委譲 ≠ 節約」

ここで一つ、直感に反する事実を押さえておきたい。「重い読み込みはサブエージェントに丸投げすれば安くなる」── これは 半分しか正しくない。

サブエージェントの読み込みも 課金される。隔離は親の context を守るが、その作業をタダにはしない。委譲は課金を移動させるだけで、削減ではない。

では委譲の価値は何かというと ── 親の会話を汚さないこと だ。生の大量データを親に残さず隔離すれば、親 context は軽いまま保たれ、破損の発火条件から遠ざかり、以降のターンの再送コストも増えない。この「隔離して親を守る」という発想が、そのまま Context Drop の設計思想になった。

3. 背景② ── effort・model・ultracode: 何のため・いつ何を・どう切り替えるか

肥大とコストへの対策は、二つのレバーに整理できる。context ダイエット（読みすぎない・貼りすぎない）と、モデル tier の振り分けだ。Context Drop は前者のためのツールだが、後者 ── そして「1 回あたりどれだけ考えさせるか」「何人で分担させるか」── も知っておくと運用が安定するので、ここで整理しておく。

一言でいうと

effort は「1 人がどれだけ深く考えるか」、ultracode は「何人で分担・検証するか」 だ。この 2 つは別々に調整できる。

3 つの設定項目

設定項目決めるもの値筆者の現在の設定
model頭の良さの上限Opus / Sonnet / Haiku / Fableopus[1m]
effort1 回の応答でどれだけ考えるか（深さ）low / medium / high / xhigh / maxmedium（~/.claude/settings.json の effortLevel）
ultracode複数エージェントで並列化・反証するか（広さ・確かさ）on / off必要なときだけキーワードで付ける

effort の段階ごとの違い

以下は筆者の体感による目安で、公式に文書化された挙動ではない。

effort考え方向いている作業
lowほぼ即答で、推論は最小限文言修正、grep の結果まとめ、機械的な置換
medium標準的普段の実装や調査（筆者の現在の既定）
high手順や代替案を丁寧に検討する境界に関わる変更（課金・認証・DB）の実装、難しいバグ
xhighかなり深く考える設計判断、競合状態や並行処理の推論
max上限まで考える何度直しても直らない根本原因、重要な設計の最終判断

effort を上げるほど、遅くなり、トークンも多く使う。精度が上がるのは「考えれば分かる問題」に限られる。情報が足りないことが原因なら、effort を上げても解決しない。その場合に効くのは、調査の範囲を広げることだ。

組み合わせのパターン

パターンeffortultracode使う場面
A. 日常mediumoff普段の実装、質問、小さな修正
B. 1 人でじっくりhigh〜maxoff原因が 1 か所にありそうな難しいバグ、設計の思考実験。並列化より深く考える方が効く場面
C. 広く速くmediumon影響範囲の洗い出し、多数のファイルの移行、「X は無いか」の網羅確認。1 件あたりは簡単でも数が多い作業
D. 全力high〜xhighonmerge 前の敵対レビュー（課金・認証まわり）、本番障害、設計方針の比較
E. 混成（Workflow 内）段階ごとに指定on例: 洗い出し段階は low、検証・合否を決める段階は xhigh。筆者の運用ではコストと精度の釣り合いが取りやすい

E について補足する。Workflow スクリプトの中では、エージェントごとに effort を上書きできる（agent(prompt, {effort: 'low'}) のように、low 〜 max を指定）。そのため「数が多くて単純な段階は浅く、少数で重要な見極めは深く」と分けるのが効率的だ。ultracode のときは、この分け方で Workflow を組ませるとよい。§2 で見た「ultracode は放っておくと巨大なファンアウトになる」問題に対する、いちばん手軽な歯止めでもある。

model tier ── 何を・いつ

モデルの選び方には、社内の運用ルールがある。要約すると:

tierモデル向く作業
lightHaiku機械的作業（一括置換・リネーム・索引・小さな docs）
midSonnet標準的な実装・バグ修正・テスト作成・QA
topOpus設計・レビュー・敵対的検証・大きな仕様の大枠
max親セッションから継承（例: Fable 5）リスク床にかかる判断・タスク分解の判断・設計方針レベルの判断

判断則はシンプルで応用が効く:

  1. リスクで決める（下限）: 課金・認証・本番・不可逆な操作が絡むなら top + 人間の確認。
  2. サイズで決める: 小さく機械的なら light、複数ファイルや新規設計なら top で大枠を決める。
  3. タスク種別で決める: 実装・バグ修正・テストは mid、レビュー・敵対検証・設計は top。
  4. 迷ったら上位: 品質事故の損失はトークン節約を上回る。

model は「頭の良さの上限」、effort は「その頭でどれだけ深く考えるか」、ultracode は「何人で当たるか」。tier の判断則で model を決め、上の A〜E で effort と ultracode を決める ── という順に考えると迷いにくい。

どう切り替えるか

effort

  • 起動時: claude --effort high（claude --help で確認済み。説明は「Effort level for the current session」、値は low / medium / high / xhigh / max）
  • 会話の途中: /effort。このプロジェクトで実際に /effort を使ったところ、Set effort level to medium (saved as your default for new sessions) と表示された。つまり会話中に切り替えた値は、以降の新しいセッションの既定値としても保存される。
  • 常用の既定値: ~/.claude/settings.json の "effortLevel": "medium" を変更する。
  • Workflow 内: 前述の agent(prompt, {effort: ...}) でエージェントごとに上書き。

model

  • 起動時: claude --model ...（--help で確認済み）
  • 会話の途中: /model
  • 常用の既定値: settings.json の model フィールド（例: opus[1m] = Opus + 1M コンテキストウィンドウ）
  • 高速化: /fast は Opus の高速出力モードを切り替える（同じ Opus のまま出力が速くなる。小さいモデルに落とすわけではない）。

ultracode: プロンプトに ultracode を含める、またはセッション全体で on にする。

注意: /effort・--effort・effortLevel・/model・opus[1m]・/fast・ultracode は Claude Code ハーネス側の機能で、ここで引いた社内の設計記録が定めているものではない。設計記録の側が定義しているのは「どの tier をいつ使うか」の判断ルールの方だ。

紛らわしい名前に注意

/code-review high の high などは、レビューの範囲の広さ（指摘の拾い方） を表すレベルだ。effort（セッションの考える深さ）と名前は似ているが別物である。また /code-review ultra は、クラウドで複数エージェントが動く有料のレビューで（ユーザーが明示的に起動する）、ultracode とも別の仕組みだ。

おすすめの運用

既定は A（medium / off） のままにして、次のように切り替えるのが良い。

  • 難しい 1 点を考えさせたいとき → effort だけ上げる（B）
  • 漏れがあっては困るとき → ultracode を付ける（C）
  • merge 前や本番障害など絶対に外せないとき → 両方上げる（D）

この「設定を作業に合わせる」習慣と、「context を軽く保つ」習慣。この二つが揃って初めて、重い運用でも壊れにくくなる。Context Drop は後者を、ツールと手順の側で仕組みにしてくれる。

4. Context Drop とは

Context Drop は、ローカル専用のデスクトップ・メニューバーアプリだ。テレメトリはなく、Context Drop 自身がネットワークへ何かを送ることもない。やることは一つ ── 生の文脈をメインの会話に入れずに、隔離したサブエージェントへ逃がす。

核心のフローはこうだ:

生の文脈(raw)  →  Context Drop packet  →  隔離 subagent  →  要約(compact)  →  main Claude

そして、意図的に やらない フローがこれ:

生の文脈(raw)  →  main Claude  →  subagent      ← これは禁止

違いは「生のデータが一度でもメインの会話を通るかどうか」。前者はメインを一切汚さない。後者はメインに生データが刻まれ、以降のターンでずっと再課金され、破損リスクを上げる。Context Drop は、メインにはファイルの場所などの情報だけを渡し、中身を読む作業をプラグインの指示でサブエージェントへ回すことで、この一線を引く。

設計上のもう一つの柱が 「capture first, route later（まず溜める、あとで宛先を決める）」。素材を集める段階では行き先を決めない。送りたい Claude Code セッション（タブ）で /context-drop:pull（短縮形 /cd）を打った瞬間に、そのセッションが「引き取る」。だから「どのプロジェクトのどのセッションに渡すか」で迷わない。

5. 使い方

基本は 3 ステップだ。

  1. 集める: アプリで Start Capture（グローバルショートカット Cmd+Shift+9）を押すと、押した後に コピーした素材だけが packet に溜まっていく。ファイルはいつでもウィンドウへ drag & drop できる。Stop で一時停止（溜めた item は残る）、Clear で空にする。
  2. 引き取る: 渡したい Claude Code のタブで /context-drop:pull <指示> を打つ（オプションの短縮形 /cd を入れていれば /cd <指示> でもよい。§6 参照）。指示文から ANALYZE（調査のみ）/ FIX（修正まで）/ REVIEW（レビュー）のどれかを選ぶ。
  3. 受け取る: 隔離サブエージェントが packet の中身（スクショ・ログ・JSON・ファイル）を 自分の文脈で 読み、戻ってくるのは要約だけ。

これがどれだけ効くか、実測で示す。このプロジェクトで、PNG のスクリーンショット 2 枚（163,772 バイトと 173,585 バイト）と短いテキスト 3 つ（184 / 487 / 87 バイト）、計 5 item の packet を /cd で引き取った。隔離サブエージェントは 19,365 トークンを使って それらを読み込んだ。一方、メインの会話に入ったのはコンパクトな一覧（数百トークン規模）だけで、生のバイト列は一度もメインに入っていない。もしこの 2 枚のスクショを直接メインに貼っていたら、その重みがメインの文脈に刻まれ、以降のターンでずっと再送されていた。その重みを使い捨てのサブエージェントに肩代わりさせ、メインは軽いまま ── これが Context Drop の価値のすべてだ。（ただし「委譲 ≠ 節約」のとおり、この 19,365 トークンも課金はされる。節約できるのはメインの文脈と、以降の毎ターンの再送分だ。）

6. インストール手順（画面キャプチャ入り）

ここは丁寧に行く。Context Drop は Tauri（Rust と Web フロントエンドでデスクトップアプリを作るフレームワーク）で作っていて、macOS と Windows の両方を対象に設計している。ただし、ビルド済みの配布物（.dmg）を用意しているのは、いまのところ macOS の Apple Silicon（arm64）版だけ だ。以下は、その Apple Silicon 版での手順になる。Intel Mac と Windows の方は、Step 1 の後にある「ソースからビルドする」を見てほしい。

Step 1 ── ダウンロード

GitHub の Releases ページ（https://github.com/EarthLinkNetwork/context-drop/releases）を開き、いちばん新しい版（Latest と表示されている版） の .dmg をクリックしてダウンロードする。この記事の画面と手順は v0.1.3（Context-Drop-v0.1.3-macos-arm64.dmg、約 6.3 MB）で確認した。2026 年 10 月 4 日時点の最新版は v0.1.5 で、読むタイミングによってはもっと新しい版が出ているはずなので、必ず最新版を取ってほしい。以下のファイル名やバージョン番号も、その版に読み替えてほしい。この .dmg は Apple の Developer ID 証明書で署名され、Apple の notarization（公証）済み・staple 済み なので、Gatekeeper にブロックされない（初回のみ macOS の「インターネットからダウンロードされたアプリ」確認が出たら「開く」を選ぶ）。

GitHub Releases ページ。Context-Drop-v0.1.3-macos-arm64.dmg をクリックしてダウンロードする。（実画面）

（Intel Mac・Windows の方）ソースからビルドする

Context Drop は OSS（MIT ライセンス）としてソースコードを公開しているので、ビルド済みの配布物がない環境では、ソースから自分でビルドできる。必要なのは次の 3 つだ。

  • Rust（stable 版。rustup で入れる）
  • Node.js と pnpm
  • その OS の WebView（Windows では Microsoft Edge WebView2 Runtime）

ビルドのコマンドは次のとおり。

git clone https://github.com/EarthLinkNetwork/context-drop.git
cd context-drop
pnpm install
pnpm tauri build

できあがったインストーラやアプリは、apps/desktop/src-tauri/target/release/bundle/ の下に出力される（デスクトップアプリは独立した Cargo workspace なので、リポジトリ直下の target/ ではない）。Windows でのコンパイルとリンクが通ることは CI（GitHub Actions の windows-latest）で毎回確認している。ただし正直に書いておくと、できあがった Windows 版を実機で起動して使う確認は、私たちの手元ではまだしていない。うまくいかなかったときは、GitHub の issue か pull request で教えてほしい。

Step 2 ── Applications へドラッグ

ダウンロードした .dmg（例: Context-Drop-v0.1.3-macos-arm64.dmg）をダブルクリックして開くと、Context Drop.app と Applications フォルダへのショートカットが並ぶ。アプリを Applications へドラッグしてコピーする。

.dmg を開いた画面。Context Drop.app を Applications フォルダへドラッグする。（実画面）

Step 3 ── 初回起動

Applications から Context Drop を起動する。これは メニューバー常駐アプリ なので、画面上部のメニューバーのアイコンからウィンドウを開く。まだ Claude Code 連携が済んでいないので、上部に 「Finish setup」バナー（「Open Setup」ボタン付き）が表示される。なお、アプリを起動した時点で、同梱の context-drop CLI が所定の場所へ配置（更新）される。

初回起動。上部に「Finish setup」バナーが出ている（プラグイン未導入の状態）。（v0.1.3 の画面を状態再現して描画）

※この初回起動の画面と、以降の Context Drop アプリの画面（計4枚）は、v0.1.3 の実アプリ UI（フロントエンド）を状態を再現して描画したもので、実機のネイティブウィンドウのスクリーンショットではない。

Step 4 ── Settings の「Claude Code Setup」を開く

バナーの「Open Setup」か、ウィンドウ上部の Settings タブ から 「Claude Code Setup」 セクションを開く。ここにアプリ内の「Step 1」（プラグインを有効にする 2 つのコマンド）と「Step 2」（capture & route）が並び、コピー可能な /plugin … コマンド が置いてある。Copy ボタンでそのままコピーできる。

Settings タブの「Claude Code Setup」。アプリ内 Step 1 / Step 2 と、コピー可能な marketplace add / install コマンド、Optional / offline install が並ぶ。（v0.1.3 の画面を状態再現して描画）

Step 5 ── Claude Code でマーケットプレイスを追加

ここからは Claude Code 側の操作だ（ここはスクリーンショットではなく、コマンドと実際の出力をテキストで示す）。Claude Code のセッションで、次を打つ。これが公開マーケットプレイス方式で、リポジトリ名を直接指定できる:

/plugin marketplace add EarthLinkNetwork/context-drop

成功すると、次のような行が表示される（筆者の環境で、同じ系統のコマンドを実行したときに出た行）:

Successfully added marketplace: context-drop

Step 6 ── プラグインをインストールして反映する

続けてインストールする:

/plugin install context-drop@context-drop

出力（チェックマーク付き）:

Installed context-drop. Run /reload-plugins to apply.

メッセージのとおり、反映する:

/reload-plugins

Reloaded: で始まる行が表示されれば完了だ。

重要: インストールより前から開いていた Claude Code セッションは、/reload-plugins を実行するか新しいセッションを開くまで、/context-drop:pull を認識しない（/cd はさらに Step 6a の短縮形のインストールが必要）。実際、長時間開きっぱなしだったセッションで /cd ... を打ったところ、コマンドではなくただのテキストとして扱われた。「/cd が効かない」と思ったら、まずこれを疑ってほしい。

オフライン（インターネットなし）で入れたい場合: Settings の「Claude Code Setup → Optional / offline install → Install locally」でマーケットプレイスをローカルに配置し、表示されたローカルパスを /plugin marketplace add <パス> に渡す。公開ルートでもローカルでも、capture と context-drop CLI の配置はデスクトップアプリが担うので、アプリは起動しておく必要がある（アプリ起動時に CLI が所定の場所へ配置される）。

Step 6a ──（任意）短縮形 /cd を入れる

プラグイン本体が提供するのは /context-drop:pull で、短い /cd は別の alias だ。使いたい場合は Settings → Claude Code Setup → Optional / offline install で Install /cd short alias をクリックする。入れない場合は、本稿で /cd と書いている箇所をすべて /context-drop:pull に読み替えてほしい。

Step 7 ── 導入の確認

Settings に戻ると、「Finish setup」バナーに代わって 「Plugin installed in Claude Code」 のバッジが出る。これはアプリが Claude Code 側の導入記録（installed_plugins.json）を読んで検出している ── ここまで来れば準備完了だ。

Settings に「Plugin installed in Claude Code」バッジが表示された状態。（v0.1.3 の画面を状態再現して描画）

Step 8 ── 素材を溜める

Capture タブで Start Capture を押し（Cmd+Shift+9 でも可）、素材をコピーしていく。ファイルはウィンドウに drag & drop してもよい。Current Packet に item が溜まっていき、テキストは冒頭プレビュー、画像はサムネイル で一覧表示される。クリックすると中身を確認でき（テキストは先頭 1 MiB まで表示）、ゴミ箱アイコンで 1 件ずつ外せる。最後に引き取られた時刻は Last Dispatch に出る。

Capture タブの Current Packet。テキストのプレビューと画像サムネイル付きで item が積み上がり、下に Last Dispatch が表示される。（v0.1.3 の画面を状態再現して描画）

Step 9 ── /context-drop:pull（または /cd）で引き取る

渡したいタブで /context-drop:pull <指示> を打つ（プラグイン導入後は常に使える）。Step 6a で短縮形を入れていれば /cd <指示> でも同じだ。例えば:

/context-drop:pull このUIの問題を調べて直して
/cd このUIの問題を調べて直して

ここもスクリーンショットではなく、実際に起きたことをテキストで書く。§5 の実測（上の例の指示とは別の実行）では、スクリーンショット 2 枚（163,772 バイト・173,585 バイト）と短いテキスト 3 つの計 5 item を /cd で引き取ると、隔離サブエージェントが 19,365 トークンを使ってそれらを読み、メインの会話に入ったのはコンパクトな一覧（数百トークン規模）だけだった。メインの会話には、スクショの生バイトは一切入らない。

7. 設計の肝 / まとめ

Context Drop がやっていることは、技術的にはごく単純だ ── 生の文脈をメインの会話に入れず、隔離したサブエージェントに読ませ、要約だけを返す。

だがこの単純な一線が、ultracode で重いファンアウトを回していた頃に私たちを苦しめた三つの問題に効く。破損（長大コンテキスト + post-compact が発火条件なら、メインを肥大させない）、肥大（毎ターン再送される生データを根本から断つ）、コスト（重い読み込みを使い捨てのサブエージェントに閉じ込める。ただし委譲は節約ではないので、読ませる量そのものも絞る）。

モデルを賢くするのでも、effort を上げるのでも、エージェントを増やすのでもない。メインの文脈を軽く保つ ── その一点を、ツールと手順の側で仕組みにする。重い運用をするほど、この一点の価値は増していく。

8. OSS として公開している

Context Drop は MIT ライセンスの OSS として、https://github.com/EarthLinkNetwork/context-drop で公開している。Intel Mac 版や Windows 版のビルド済み配布物、ほかの AI ツールとの連携、使っていて不便なところの改善など、手を入れたいところはまだたくさんある。「こうしたらもっと便利になる」「この機能がほしい」という方は、ぜひ pull request を送ってほしい。お待ちしている。

この Context Drop についての記事は、開発の経緯・どんな機能があるか・どう実装したかを、順次シリーズとして公開していきます。 興味のある方は、ぜひ「いいね」と記事の購読をお願いいたします。

Context Drop は、スクリーンショットやログなどの生の文脈を、Claude Code のメイン会話ではなく隔離したサブエージェントに読ませる macOS アプリです。ダウンロードは https://github.com/EarthLinkNetwork/context-drop/releases から。 そのほかの自社プロダクトは https://www.eln.ne.jp/products にまとめています。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。

EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。

→ EarthLink Network が自社でつくっている18のプロダクト

会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。