文脈窓が100万トークンになって、私はプロンプトの「分割」をやめました — 個人開発の前処理を畳み直した記録

壁紙アプリのクラッシュログを Claude に渡すとき、私がいちばん時間を取られていたのは解析そのものではなく、「どの断片を渡すか」を選ぶ作業でした。スタックトレースの本体、関連する Activity のコード、直近の変更差分。当時の文脈枠には全部を一度に収められないので、章立てするように分割して、要点だと思った部分だけを抜き出して貼っていました。

6月9日に Claude Fable 5 が一般提供になり、100万トークンの文脈窓が手元の API から普通に使えるようになりました。最初に試したのは派手な使い方ではなく、この「分割をやめられるか」という地味な検証です。結論を先に書くと、私の前処理はずいぶん軽くなりました。ただそれは「全部詰め込めば賢くなる」という話とは少し違っていて、そこに腑に落ちるまで何度か遠回りをしました。その記録を残しておきます。

「分割」に費やしていた見えない時間

分割という言葉はきれいですが、実際にやっていたのは「どこを切り捨てるか」の判断でした。クラッシュの原因が自分の貼った断片の外側にあれば、Claude の回答も当然そこには届きません。すると私は「たぶんこのあたりだろう」と当たりをつけて貼り直し、外れたらまた貼り直す、という往復を繰り返していました。

厄介なのは、この往復にかかった時間がどこにも記録されないことです。1回あたりは数分でも、解析のたびに数往復していれば、見えないところで毎日それなりの時間が溶けていきます。個人開発では誰かに「ここを見て」と相談できないぶん、この「渡す断片を選ぶ」作業が地味に効いてきます。私が文脈窓の拡大に最初に期待したのは、頭の良さよりもこの往復をなくせるかどうかでした。

全部渡しても、賢くなるわけではなかった

最初の検証で、私はモジュール全体とログ全文をそのまま貼って投げました。確かに「断片が足りない」という失敗は消えました。けれど別の手応えのなさが出てきます。原因がはっきりしている単純なクラッシュでも、回答が以前より少しぼやけるのです。「いくつかの可能性が考えられます」という、当たり障りのない方向へ寄っていく感触がありました。

これは考えてみれば当たり前でした。関係のないコードまで一緒に渡せば、モデルが注意を向ける先は薄まります。大きな文脈窓は「何を見るべきか」を勝手に絞ってくれる装置ではありません。私が手放せたのは「断片を選ぶ作業」であって、「何が重要かを伝える責任」までは手放せなかったのです。

ここが、私にとっていちばん大事な気づきでした。100万トークンの本当の効きどころは「全部を読ませて賢くする」ことではなく、「どれを入れるか迷う時間を畳む」ことの方にあります。だから今は、文脈はまとめて渡しつつ、質問の側で「どこを見てほしいか」をこれまで以上にはっきり書くようにしています。

私が実際に変えた前処理の組み方

具体的には、安定して変わらない大きな文脈（モジュール全体やログ全文）を先頭に固めて置き、変わるのは末尾の質問だけ、という形に整理しました。あわせて、その大きな文脈にキャッシュ境界を切っておきます。同じログに対して角度を変えて何度も質問することが多いので、2回目以降をキャッシュ読み出しにできると、コストが目に見えて落ち着きます。

import anthropic
 
client = anthropic.Anthropic()  # APIキーは環境変数 ANTHROPIC_API_KEY から読み込みます
 
# read_module / read_log は対象ファイルを文字列で返すだけの素朴なヘルパーです
stable_context = read_module("WallpaperListActivity.kt") + "\n\n" + read_log("crash_20260623.txt")
 
resp = client.messages.create(
    # 正確なモデル識別子は最新の API ドキュメントで確認してください
    model="claude-fable-5",
    max_tokens=1024,
    system=[
        {"type": "text", "text": "あなたは Android アプリのクラッシュ解析を手伝うアシスタントです。"},
        {
            "type": "text",
            "text": stable_context,
            "cache_control": {"type": "ephemeral"},  # ← ここまでをキャッシュ境界にする
        },
    ],
    messages=[
        # 変わるのは末尾の質問だけ。大きな文脈は使い回す
        {"role": "user", "content": "このログの IndexOutOfBoundsException は、どの行のどの前提が崩れて起きていますか。該当箇所だけ示してください。"}
    ],
)
 
print(resp.content[0].text)
print(resp.usage)  # cache_read_input_tokens が増え、フルレート課金の input_tokens が減る

ポイントは、質問文を「全部読んで考えて」ではなく「該当箇所だけ示して」と狭めていることです。大きな文脈を渡すほど、質問側で焦点を与える一文が効いてきます。resp.usage を毎回見ておくと、2回目以降の呼び出しで cache_read_input_tokens が大きくなり、フルレートで課金される input_tokens が小さくなっているのが確認できます。文脈の予算をどう配るかという観点は、Claude API のコンテキスト予算をどう割り振るかでも触れています。

「詰め込む」から「キャッシュする」へ、コストの考え方

文脈窓が広がると、つい「入るだけ入れよう」と考えたくなります。けれど入れたぶんは（キャッシュに乗らなければ）毎回フルレートで課金されます。私が実運用で軸足を移したのは、「どこまで詰め込めるか」ではなく「どこをキャッシュできるか」という見方でした。

安定した大きな文脈を1時間キャッシュに乗せておけば、その上で角度を変えた質問を何度も投げても、課金されるのは末尾の差分だけに近づきます。キャッシュの有効期間を 5 分と 1 時間で使い分ける設計は、Claude API のプロンプトキャッシュを 5m と 1h の二段で設計するに詳しくまとめました。文脈窓の拡大は、頭の中の計算式を「トークン数 × 賢さ」から「変わらない部分をいかに使い回すか」へ静かに書き換えてくれました。

それでも分割を残した場面

全部を撤廃したわけではありません。文脈が呼び出しごとに大きく変わる処理では、キャッシュがほとんど効かないので、大きく渡す利点は薄れます。こういう場面では、必要な範囲だけを渡す従来のやり方の方が素直でした。

もうひとつは、モデルに「探させたい」ときです。膨大なログから一本の異常を見つけてほしい場合、関係する範囲をこちらで先に絞ってから渡した方が、回答が鋭くなることが多いと感じています。大きな文脈窓は便利な道具ですが、「何を見るべきか」を考える役割まで肩代わりはしてくれません。そこは個人開発でも、結局は自分の判断が要るところだと考えています。1M 文脈そのものの扱いについては、1Mトークンコンテキストの移行と注意点も参考になります。

次に試すなら

まずは、いつも分割して渡している処理をひとつだけ選んで、「安定した文脈を先頭にまとめてキャッシュ境界を切り、質問は末尾で狭める」形に組み替えてみてください。resp.usage の cache_read_input_tokens が伸びていれば、その処理は大きな文脈窓の恩恵を素直に受けられる候補です。私はこのやり方に変えてから、解析のたびの往復が一段減りました。私自身、まだ全部の前処理を移し替えたわけではなく、ひとつずつ確かめている途中ですが、往復が減っていく手応えは確かにあります。