Open2

Claude Code 関連の手記

あんこあんこ

今回は Claude Code とその周辺の話題で、自分にとって最高の環境を作り上げた上で知見になったことを紹介します。

Claude Code ってどうなの?とか記憶喪失しがちでやめちゃったよ〜って人向けでどう使えばいいのかなっていうところをサクッと読めるものにしてます。

TL;DR

  • コンテキストは有限のリソース → リソース管理ゲー & 曖昧性との戦い
  • AI はアルゴリズムに絶対に勝てない
  • 発展が早いので OSS を活用しよう
  • MCP と DeepResearch の発展が今のボトルネック
  • 現状は全然だめなので捨ててもいいし、発展が早いので希望的観測をしてもいい

環境

ツール 概要
Cursor エディタ
ccmanager worktree 管理
ccusage コンテキスト使用量のステータスラインを表示
SuperClaude commands / subagents / MCP を管理してる OSS
kiro like なコマンド 要件定義・技術選定・タスク分割をしてくれるコマンド
通知フック Claude Code hooks

コンテキストリソース管理ゲーの理由

まずは LLM の仕組みから入りましょう。

LLM はこれまでの文脈から次のトークン列を確率的に推定するモデルです。この仕組みについてはここでは解説しませんが次のプレイリストがわかりやすいです。

https://www.youtube.com/playlist?list=PLomzhH_XCG4y0GFY4XJWYE5F8u2CAh5iL

皆さんが使ってる GPT-5 とか Gemini は統計的なデータをもとに論理的っぽく誠実な答えを返すようファインチューニングされてます。なので曖昧なプロンプトを渡すと、もっともらしい不要な情報や見当違いな情報も返してきます。逆に例えば「あなたは〇〇の専門家です」とか与えるとその分野の専門家のブログの統計情報と結びついて質のいい回答をしてくれます。このように適切な文脈を与えるとハルシネーションを抑えたり効率化できます。なぜ論理があるように答えられるのかは人類誰もちゃんとわかってないです。

そして LLM 自体は 1 つの文章に対してしか出力できません。普段 LLM と話せていますがこれは次の手順で行なっています。

  1. ユーザーがプロンプトを入力して LLM に渡してテキストを出力してもらう
  2. ユーザーがまた入力して、これまでの会話履歴をすべて LLM に渡して出力してもらう (以降 2 の繰り返し)

このようにこれまでの会話履歴をすべて渡すことで話しているようにみせています。この会話履歴をコンテキストウィンドウと言います (以降コンテキストと呼ぶ)。Claude Code の場合 200K トークン (1 行 70 文字として 1 万行程度) のコンテキストを持てます。会話を続けるとコンテキストが満杯になるので、不要な部分を捨てて縮約しなければなりません。この時必要な情報が失われてしまうとハルシネーションに繋がります。

実際に使ってみると大量にハルシネーションが起こります。これを極力起こさない為にはコンテキストを管理する方法が必要です。

アプローチとしては 3 つあります。

  1. 与えるコンテキストを減らす
  2. コンテキストを自己修正し続ける
  3. コンテキストの圧縮精度やキャッシュ戦略の向上

後者は処理時間はかかるけれども優秀な結果になる手法ですが Claude Code では実装されていません。なので前者を取ります。コンテキストを減らせると人間にとってもわかりやすいので一石二鳥ですね。

結論としてはコンテキストを減らし、曖昧性をなくす方針でプロンプトを組み立てていけばよいです。

高打点の出し方

そうは言ってもむずかしいので最初は ccusage のコンテキストの使用量や ~/claude/projects を見ながら適切なプロンプトについて試行錯誤してみると面白いです。

筆者が感じた特に重要な点をいくつか伝えます。

修正をするな・叱るな

修正は間違った情報と不要な情報をコンテキストに入れる確実な方法です。ハルシネーション起きまくります。解決方法としては

  • 修正不要な完璧なコンテキストを最初に作る
  • うまくいかなかったり、別の作業へ取り掛かる際は /clear する

コンテキストは対話的に作ると上手くいきます。
割とこまめに /clear して ultrathink してるだけでかなり性能良くなります。

抽象度を徐々に下げる

最初は抽象度の高い説明から入り、徐々に具体化する方が沼にハマりません。

kiro のようなスペック駆動開発 (Chain-of-Thought prompting)
具体例を提示する (Few-shot prompting)のがかなり効果的。

AI は純粋なアルゴリズムには勝てない

アルゴリズム的な処理は既存ツールの方が効率的です。

  • テスト駆動開発
  • エコシステム (linter, formatter) の活用
  • Serena / Morphllm などの MCPの活用

MCP でいうと特に Sequential Thinking MCP が優秀で、次点として Serena もおすすめです。

commands / subagents は OSS に頼ろう

  • 計測手法がむずかしいため、コミュニティで実績あるものを使うのがよくなる
  • 英語ネイティブがクリティカルな単語を用いてトークン数を削る日々に僕らが勝てない
  • 発展が早くて自動追従してくれる OSS の恩恵が大きい

英語で書こう

日本語は翻訳によってトークン消費が倍増します。そのため、英語で書いた方がコンテキスト消費を抑えられます。でも〜これは英語を書ける人の特権で、書けない人は英語を学ぶチャンスだと思ってやるといいかも。機械翻訳で必要性が消えてってるけど、僕は特定の言語でしか表現できないニュアンスがわかるのが好きなのでこういうチャンスがあるの嬉しい。

これから

ここからは僕の感想です。

MCP は発展途上でまだ赤ちゃんサービスしかないのでアイデアや気力、運次第で覇権とれると思います。正直ここの競争が激しくなるべきなのになってないのが謎。例えばこんなのかな

  • CLAUDE.md serena などの外部記憶のコンテキスト圧縮精度の劇的な改善
  • MCP のベンチマーク指標の開発
  • ~/claude/projects を使ったデバッグ手法
  • プロンプトのフィードバックを行うコマンド

数ヶ月もすれば MCP が飽和して今の体験の悪い状態から抜け出せるようになるんじゃないかなと思ってます。

AI のおかげで学習コストが消えて全部が Rust に置き換わっていくんだなと嬉しい反面、他の言語が今の Lisp みたいな立ち位置になるのは悲しいなと思う今日この頃です。

参考文献

あんこあんこ

ほんとに AI というか Gemini DeepResearch が世界をぶち壊しにきてる。

がんばれば誰でもこれまでにない未知のうますぎるラーメンを作れてその動画作って公開できるってことがどれだけ幸せになれるかって毎回思う。

知識になってなかったものが誰かの発見で知識になって共有されて人類全体で並列に発見していってそれらがまとまって学問になっていくプロセスが Gemini DeepResearch 並びに AI によってとてつもなく無駄がなくなって早くなってる。それだけだと Polymath Project みたいなのと同じだけど、それまで学問とも知識になるとも思われてこなかったものが学問になっていく過程がすごく面白い。それで学問創設 RTA みたいな文化が広まっていってほしい。そういう埋もれてた知識が目に見えるようになってく。

AI があっても問題になるのが全く違う分野を繋げられるかで、どんなに AI が発達したとて専門知識とかが必要な分野ってたくさんあって一人がそれら全部を知り尽くせないし、基本別分野に興味はわかない。だから人と人を繋いでほぐせるような基盤があるといいかなって思う。

AI が代替できるかどうかはわかんない。論理に関して現状はカスで人類の誰も仕組みがわかんないから割とないよりで 3 割くらいあるかもの期待を持ってる。割と論理って AI 用に中心の論理を通してあげさえすればあとはパターンマッチで賄えるのかもしれない。