トークン対パフォーマンスを最大化しよう

ウォンテッドリー社内でエンジニア向けに発表したスライドです。
コンテキストの肥大化を対策する話と、LLM の成果物を理解して責任を持てるようになろうという話をしました。

Transcript

1. トークン対パフォーマンスを 最大化しよう Tech Lunch Aug.7 2026 - Hayato Kawai (@fohte) © 2026 Wantedly, Inc.
2. CONTENTS は金がかかる 02 コンテキストを意識しよう 03 トークン対パフォーマンスを上げるには? 04 セッションをどう分割するか 05 理解を放棄しない 01 LLM © 2026 Wantedly, Inc.
3. 01 LLM は金がかかる © 2026 Wantedly, Inc.
4. LLM は金がかかる はほとんどトークン数あたりの課金になっている • 一部サービスのサブスクは「一定の中で利用する分には 従量課金ではない」という方式をとっている • LLM ◦ • モバイル端末の通信プランのようなイメージ。1 ヶ月の中で 1GB までなら利用可能みたいな うちの場合は Claude Team Plan がこれに該当する © 2026 Wantedly, Inc.
5. とはいえ永久に非従量課金が続くのか? • Claude ◦ もいつまで非従量課金が維持されるかは不明 「Fable もいつまではサブスクに含めるけど、いつからは従量課金にするよ」といってた 結局 OpenAI (ChatGPT) との競争の中で従量課金には移行しなかった - • 現状は、各社血涙を流しながら従量課金にしていないだけの 状況のはず ◦ つまり将来的に従量課金になる可能性は十分にある © 2026 Wantedly, Inc.
6. Claude の rate limit はいくつか種類がある 時間ごと / 週次 / Fable は別枠、と 種別がある • これら "いずれか" を超えると従量課金が 始まる • 5 © 2026 Wantedly, Inc.
7. 自分が rate limit に引っ掛かっているかどうかを確認するには? 従量課金が始まったときは、Claude Code であれば「rate limit に 引っ掛かったのでここから先は有料です」的なことを言われる • 現状の消費量を見る場合 • から見られます ◦ Claude Code ならステータスラインに表示すると便利 「https://github.com/fohte/dotfiles/blob/master/config/claude/statusline.ts を参考に rate limit を表示するようにして」と Claude Code に指示するといい ◦ https://claude.ai/new#settings/usage - © 2026 Wantedly, Inc.
8. 02 コンテキストを意識しよう © 2026 Wantedly, Inc.
9. コンテキストとは何か コンテキストとは、それまでの各ターンの入力 (prompt) と出力 (response) を積み上げたもの。 Turn 2 では、Turn 1 の入出力も含めて渡される 1 行の質問でも、履歴が 100k token あれば毎回 100k 読ませている (ざっくり 100k 分の課金) 出典: https://platform.claude.com/docs/en/build-with-claude/context-windows © 2026 Wantedly, Inc.
10. 増えるほど精度は落ちる (context rot) 長文コンテキストの中から情報を正確に取り出せるかを測るベンチマーク。 トークン数が増えるほど、どのモデルも正解率が下がっていく。賢いモデル (例: Opus) の長いコンテキストが、安い モデル (例: Sonnet) の短いコンテキストに劣ることもある © 2026 Wantedly, Inc. 出典: https://claude.com/blog/1m-context-ga
11. 03 トークン対パフォーマンスを上げるには? © 2026 Wantedly, Inc.
12. トークン対パフォーマンスを上げる工夫 1. セッションを分割する • 1 2. セッションに複数の関心を持ち込まない 理解を放棄しない • 理解すると速度は落ちるが質は高くなる。ただ速度を犠牲にしてでも理解すべき場面は多い © 2026 Wantedly, Inc.
13. 04 セッションをどう分割するか © 2026 Wantedly, Inc.
14. セッションを分割しよう コンテキストが増えるほど精度が落ちるし、トークンも浪費する • 「1 セッションに複数の関心・目的を入れない」ことを意識すると よい • © 2026 Wantedly, Inc.
15. 複数のタスクを 1 セッションでやらないようにする • たとえば、実装 A と実装 B があったとき、両方を 1 セッションで やるのは避けたほうがよい ◦ コンテキストが増えて精度が落ちるため ◦ たとえば、A が終わった直後に、そのままのセッションで B を始めてしまう、など 極端な例として) 全く関心の異なる 2 つのプロダクトの開発を、 同じセッションで続けてやるのはやめたほうがよい • ( © 2026 Wantedly, Inc.
16. 指示役と実行役を分ける • 指示役 (設計・分解) と実行役 (実装) を別セッションにする 自分の場合: 設計は Opus、実装は複数の Sonnet というふうにしている Opus に設計書を書かせる → タスクを分解させる → その分解されたタスクごとに Claude Code を起動 (Sonnet) ◦ 各セッションは自分のタスク分のコンテキストしか持たないので、精度が落ちにくい ◦ - • 実装だけでなく色んな分野で使える 壁打ち用セッションと実行用セッションを分けたり ◦ 今回のスライドも、壁打ち → アウトライン生成は別セッションで作った ◦ © 2026 Wantedly, Inc.
17. 能動的に compact する 分割しようとしてもコンテキストを大量に消費してしまうことも、 どうしてもある • そういうときは Claude Code 標準機能にある /compact を 定期的に実行するのがよい • © 2026 Wantedly, Inc.
18. compact の仕組みと使い方 はセッションを要約して、その要約された情報以外は 消える 忘れる) • compact ( ◦ • 忘れすぎることもあるので注意 自分の使い方: context 使用率 30〜40% でまだ会話が 続きそうなら、能動的に compact する © 2026 Wantedly, Inc.
19. 05 理解を放棄しない © 2026 Wantedly, Inc.
20. LLM の出力に対し、理解を放棄しないようにしよう • LLM ◦ • が書いたコードは自分で一言一句説明できますか? すべてにおいて説明できたほうがよいわけではないが、基本的には説明できたほうがよい 自分が理解していないと、たとえばレビューで指摘されても「なぜ 指摘されたのか」がわからない 障害が起きたときも、なぜ障害が起きたのかがわからない ◦ 自分が理解できていないので、LLM にまた投げることになる → 無限ループ ◦ © 2026 Wantedly, Inc.
21. 理解度と速度は反比例する の出力を理解しないままコードを書いて取り込んでしまえば 最速で進められる • LLM ただしこれは人間対人間のコードレビューでいうと、レビューなしで merge するような もので、リスクも高い ◦ バグ・障害が起きたらどうする? 潜在的なリスクはないのか? ◦ • モデルが賢くなり、エージェントが自律的に気付けるようになる 未来も来るはずだが、いまはまだその段階ではない © 2026 Wantedly, Inc.
22. とはいえすべてを理解するのは大変 状況に応じて理解度を変えるのがよい • たとえば自分は趣味開発のコードは理解度 30 % くらいしかない • 動けば OK だし、問題あればそのときに直せばよい ◦ このスタンスにできるのは、困るのが自分だけだから ◦ • 仕事ではどうか? → 問題があったときに困るのは誰? で考えると よさそう 問題のあるコードがあって困るのは誰か? → レビュワー、そのコードを今後触る チームメンバー ◦ インシデントが起きたらユーザーも困るし、会社・プロダクトとしての信頼低下にも繋がる ◦ © 2026 Wantedly, Inc.
23. すべてを理解しなくてもよいが、理解することを放棄しない • 読んで理解する時間を取る方が、遠回りに見えてトータルの 仕事量は減るはず ◦ • 手戻りが少ないほうが、結局仕事の総量は減る 理解すれば学習機会にもなるし、自分の糧になる 同じような場面に次また出会ったとき、もっと早く判断できるようになる ◦ LLM にも適切な指示ができるようになり、望ましい結果を最短で得られるようになる ◦ © 2026 Wantedly, Inc.
24. まとめ コンテキストが増えるほど精度は落ちるので、セッションを適切に 分割しよう • LLM の出力の理解を放棄せず、自分で説明できるようになろう • © 2026 Wantedly, Inc.