Claude Code のコンテキスト圧縮戦略 — ソースコードから見える5つのアプローチ

Claude Code のソースコードから、会話が長くなったときのコンテキスト圧縮方法が5種類あることが明らかになった。コンテキストウィンドウの管理は AI コーディングエージェントにおける中心課題であり、Anthropic のエンジニアがかなりの時間をかけて取り組んでいる領域だ。 5つの圧縮戦略 1. Microcompact — 古いツール結果の時間ベース消去 時間経過に応じて古いツール実行結果(ファイル読み取り、grep 結果、bash 出力など)を自動的に消去する戦略。API 呼び出しを発生させず、キャッシュされたコンテンツをローカルで直接編集する軽量な処理だ。 ツール結果は会話中で最も大きなトークンを占めるが、時間が経つにつれて重要度は下がる。この戦略により、最新のやり取りに集中しつつトークン消費を抑えられる。 2. Context Collapse — 会話の部分要約 会話の特定の範囲を要約で置き換える戦略。長い対話セクションを圧縮された要約に変換し、セマンティックな意味を保持しながらトークン消費を削減する。 全体を要約するのではなく「部分的に」要約するため、直近の文脈はそのまま保持される点がポイントだ。 3. Session Memory — 重要な文脈のファイル抽出 重要な情報を別ファイルに永続化する戦略。完了した作業、進行中の作業、関連ファイル、次のステップなどの重要な詳細を抽出し、会話の全履歴をアクティブメモリに保持せずに参照できるようにする。 Claude Code の /compact コマンドを手動で実行した際にも、この仕組みが活用される。要約には以下の情報が保持される: 何が完了したか 現在進行中の作業 関連するファイル 次のステップ ユーザーの重要なリクエストや制約 4. Full Compact — 履歴全体の要約 会話履歴全体を包括的に要約する戦略。コンテキストウィンドウが限界に近づき、大量の対話が蓄積された場合に有用だ。 自動圧縮(auto-compact)は、コンテキストウィンドウに対して約33,000トークンのバッファを残すタイミングで発動する。200Kトークンのウィンドウであれば、約167Kトークンを使用した時点がトリガーとなる。 連続する自動圧縮の失敗が3回を超えると、そのセッションでの圧縮は無効化される(MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3)。この定数は autoCompact.ts に定義されており、かつて1,279セッションで50回以上の連続失敗(最大3,272回)が発生し、日あたり約250,000回のAPI呼び出しが無駄になっていた問題を解決するために導入された。 5. PTL Truncation(Past Turn Limiting) — 古いメッセージ群の切り捨て トークン圧力が臨界に達した際に、最も古いメッセージ群を切り落とす戦略。最近の文脈を優先し、過去のやり取りを犠牲にする最終手段だ。 コンテキスト圧力のカスケード これらの5つの戦略に加え、ツール結果の割り当て制御(バジェッティング)がカスケードの最初の段階として存在する。各戦略は個別に動作するのではなく、軽量な処理から順に段階的なカスケードとして機能する: ツール結果バジェッティング → Microcompact → Context Collapse → Full Compact(Auto Compact)→ PTL Truncation 軽量な処理から順に適用され、それぞれの段階で何を保持し何を破棄するかの基準が異なる。 ...

2026年4月2日 · 1 分

Claude Code を Ollama でローカル無料実行する方法

Claude Code がローカル LLM で無料実行できるようになった。Ollama を使えば、API 料金なしで Claude Code のインターフェースを活用できる。 背景 Claude Code は Anthropic が提供する CLI ベースの AI コーディングアシスタントだ。通常は Anthropic API を通じて利用するため、API 使用料が発生する。しかし Ollama v0.14.0 以降で Anthropic Messages API 互換のエンドポイントが実装され、ローカル LLM を Claude Code のバックエンドとして使えるようになった。 2026年1月にリリースされた Ollama v0.15 では ollama launch claude コマンドが追加され、セットアップがさらに簡単になっている。 セットアップ手順 方法1: ollama launch(推奨・v0.15 以降) Ollama v0.15 で追加された ollama launch コマンドを使えば、環境変数の設定なしでワンコマンドで起動できる: 1 ollama launch claude モデルを指定する場合: 1 ollama launch claude --model qwen3-coder 方法2: 環境変数を手動設定(v0.14 以降) 1. Ollama のインストール macOS/Linux の場合は以下のコマンドでインストールできる。macOS では公式サイトのインストーラーも利用可能: ...

2026年3月31日 · 1 分

MiroFish その後: 3週間で GitHub Star 4.7万超へ — コミュニティの広がりと今後の展望

以前の記事で紹介した AI 予測エンジン「MiroFish」が、公開から約3週間で GitHub Star 4.7万超にまで急成長しています。本記事では、その後の動向とコミュニティの広がりを追います。 3週間での急成長 3月10日時点で約11,000だった Star 数は、3月末時点で 47,000以上 に到達しました。約3週間で4倍以上の成長です。 GitHub Trending で世界1位を獲得した直後の注目度に加え、盛大グループ創業者・陳天橋氏からの3,000万元(約6億円)の即決投資が報じられたことで、AI エージェント分野への関心の高さを示すプロジェクトとして広く認知されました。 コミュニティの広がり MiroFish のオープンソース公開後、コミュニティによる派生プロジェクトが活発に展開されています。 オフライン版フォーク MiroFish-Offline は、Neo4j と Ollama を使ったローカル完結型のフォークです。クラウド API への依存を排除し、プライベートな環境でマルチエージェントシミュレーションを実行できます。企業内のデータを外部に出せないケースなどでの活用が想定されます。 デモサイト 公式デモサイトが公開されており、ブラウザ上で MiroFish の予測プロセスを体験できます。 多言語対応フォーク 英語版 README の整備や、コミュニティによる英語フォークも複数登場し、中国語圏以外への普及が進んでいます。 群体知能アプローチへの注目 MiroFish が採用する群体知能(Swarm Intelligence)アプローチは、従来の AI 予測と異なる特徴を持っています。 従来の予測モデルは統計的パターンや単一モデルの推論に依存しています。一方、MiroFish は数千のエージェントによる社会的シミュレーションを通じて予測を行います。エージェント同士が議論し、説得し、立場を変えるプロセスを経ることで、集団行動や社会的伝播といった創発的パターンを予測に反映できます。 このアプローチは、特に世論形成や市場心理のような「人間の集団行動」が結果を左右する領域で有効性が期待されています。 今後の注目点 MiroFish の急成長は印象的ですが、今後の展開にはいくつかの注目点があります。 予測精度の検証: 実際のイベントに対する予測精度がどの程度か、体系的な評価はまだ少ない スケーラビリティ: OASIS エンジンは100万エージェント対応を謳うが、実運用での性能と品質のバランス LLM コスト: 数千エージェントの同時推論に必要な API コストの最適化 ユースケースの深化: 汎用的な「万物を予測」から、特定領域での実用性の実証 まとめ MiroFish は、公開からわずか3週間で GitHub Star 4.7万超という驚異的な成長を遂げました。オフライン版フォークやデモサイトの登場など、コミュニティの展開も活発です。 群体知能によるマルチエージェント予測というコンセプトは多くの開発者の関心を集めていますが、実用面での検証はこれからです。今後の予測精度の実証やユースケースの深化に注目していきたいプロジェクトです。 参考リンク MiroFish GitHub リポジトリ MiroFish-Offline (ローカル版フォーク) MiroFish: The AI Swarm Engine That Simulates the Future 前回の記事: MiroFish — 20歳の学生が10日間の Vibe Coding で作った AI 未来予測エンジン

2026年3月31日 · 1 分

「値は計算されていた。ただ届いていなかっただけ」— LLMエージェントプロンプトのハードコード問題

TL;DR 自律型トレーディングシステムで、投資目標の進捗に応じてリスクパラメータを動的に調整する機能を実装した。計算ロジックは正しく動いていたが、計算結果がエージェントのプロンプトに届いていなかった。プロンプト内の数値がプレーンテキストでハードコードされていたため、エージェントは常に保守的な固定値に従い続けていた。 背景 trader は日本株・ビットコインの自律型トレーディングシステムで、Claude をマルチエージェントとして使い、日次の投資提案を生成する。 システムには安全規約があり、エクスポージャー上限(60%)や現金比率下限(30%)などのリスクパラメータが定義されている。投資目標(goal)システムを導入し、目標への進捗ペースに応じてこれらのパラメータを動的に調整する機能を実装した。 何が起きたか 期待していた動作 1 2 3 goal 評価: behind(目標に遅れている) → AdjustmentProposal: exposure_limit=70%, cash_ratio_min=20% → エージェント: 「エクスポージャー70%以内、現金比率20%以上」で提案作成 実際の動作 1 2 3 goal 評価: behind(目標に遅れている) → AdjustmentProposal: exposure_limit=70%, cash_ratio_min=20% → エージェント: 「エクスポージャー60%以内、現金比率30%以上」で提案作成 ← 固定値のまま! goal の評価は正しく行われ、propose_adjustment() は適切な調整値を返していた。しかしエージェントが参照するプロンプトには、値がハードコードされていた: 1 2 3 <!-- portfolio.md --> - 総エクスポージャー60%以内 - 現金比率30%以上を維持 一方、同じプロンプト内の max_position_pct(1取引あたりポジション上限)は既にテンプレート変数化されていた: ...

2026年3月27日 · 2 分

AI疲れへのアンサー: Claude Code のハーネス機能は本当に必要か

「AI疲れ」という言葉が広がる中、Claude Code のハーネス機能(Skill, Agent, MCP, Memory)は不要であり、シンプルな CLI で十分だという主張が話題になっている。この議論の論点を整理し、実際の開発現場での実用性を考察する。 話題の発端 Kai Aoki 氏(@kaixaoki)が X で投稿した「AI疲れしてる各位に贈るアンサー」が注目を集めた(2026年3月時点で 531 いいね、462 ブックマーク、約9.8万表示)。 主張は以下の4点: ドキュメントが全て — コードや設定よりもドキュメントが最重要 Skill, Agent, MCP, Memory 全て不要 — CLI で解決可能 ハーネス独自機能は全て不要 — 物理マシン/VM で隔離せよ 賢いモデルがいずれ全てを解決する — 機能追加より待つべき さらに「特に Claude Code はハーネスを複雑化してロックインし、虚業を生み出しているので Evil」と結論づけている。 各論点の検討 ドキュメントが全て これは多くの開発者が同意できる主張だ。CLAUDE.md や README に適切な情報を書いておけば、AI エージェントは文脈を理解して適切に動作する。実際、Claude Code の公式ドキュメントでも「CLAUDE.md に何を書くか」が最も重要な設定項目として紹介されている。 ただし、ドキュメントだけでは解決しづらい課題もある。繰り返しのワークフロー自動化や、外部サービスとの連携は、仕組みとして定義した方が効率的なケースがある。 Skill/Agent/MCP/Memory は不要か シンプルな使い方なら不要というのは正しい。1ファイルのバグ修正やコードレビューに Skill や Agent は必要ない。 一方、以下のようなケースではこれらの機能が実用的な価値を持つ: Skill: 定型作業(ブログ記事作成、PR レビュー、デプロイ手順)を毎回説明する手間を省く Agent: 並列タスク実行(ファクトチェックと SEO 分析の同時実行など) MCP: 外部 API やデータベースへのアクセスを安全に管理する Memory: プロジェクト固有の慣習やユーザーの好みを会話をまたいで保持する 要は「必要な人には必要、不要な人には不要」という当たり前の結論になる。問題は、これらの機能がオプトインであるかどうかだ。Claude Code ではいずれも使わなければ存在しないのと同じであり、強制されるものではない。 ...

2026年3月26日 · 1 分

Claude Code の Auto Mode から見える AGI への道筋

AGI(Artificial General Intelligence、汎用人工知能)とは、特定のタスクに限定されず、人間のように幅広い知的作業をこなせる AI を指す概念だ。現在の AI は特定領域で高い能力を発揮するが、未知の領域への汎用的な対応力では人間に及ばないとされている。 Claude Code に auto mode が導入された。パーミッションの承認を Claude 自身が判断するこの機能について、「次に来るのは Claude 実行自体の auto mode、つまり AGI だ」という指摘が注目を集めている。開発ツールの自律性の進化と、その先にある可能性を考える。 Auto Mode の本質 2026年3月、Anthropic は Claude Code に auto mode を導入した。公式 X アカウントの発表によると: New in Claude Code: auto mode. Instead of approving every file write and bash command, or skipping permissions entirely, auto mode lets Claude make permission decisions on your behalf. Safeguards check each action before it runs. ...

2026年3月26日 · 2 分

Claude Subconscious:Claude Code にセッション横断の記憶力を与える Letta AI のオープンソースツール

Claude Code は強力な AI コーディングエージェントだが、セッションをまたいだ記憶の保持には課題があった。Claude Subconscious は、Letta AI が開発したオープンソースのプラグインで、Claude Code にバックグラウンドで動作する永続メモリを追加する。 Claude Subconscious とは Claude Subconscious は、Claude Code のセッションをバックグラウンドで監視し、ユーザーの作業パターンや好み、未完了のタスクを学習・記憶するエージェントだ。次のセッション開始時に、蓄積した記憶をプロンプトに自動注入することで、毎回ゼロからのスタートではなく、文脈を引き継いだ作業が可能になる。 主な特徴: セッション横断の記憶: 複数セッションをまたいで作業コンテキストを保持・統合 バックグラウンド動作: Claude Code の操作をブロックせず、非同期で動作 自動コンテキスト注入: プロンプトの前に関連する記憶やガイダンスを自動挿入 コードベースの探索: Read、Grep、Glob ツールを使ってプロジェクトのコードを読み取り、理解を深める 完全無料・オープンソース: GitHub リポジトリ で公開中 仕組み Claude Subconscious は Claude Code のフックシステムを利用して、4 つのタイミングで介入する: SessionStart — エージェントに通知し、レガシーファイルをクリーンアップ UserPromptSubmit — 記憶とメッセージを stdout 経由で注入(10 秒タイムアウト) PreToolUse — ワークフロー中の更新を配信(5 秒タイムアウト) Stop — セッションのトランスクリプトをバックグラウンドエージェントに非同期送信 バンドルされたエージェントは 8 つのメモリブロックを管理する: メモリブロック 用途 core_directives 役割定義 guidance アクティブセッションのガイダンス user_preferences 学習したコーディングスタイル project_context コードベースの知識 session_patterns 繰り返しの行動パターン pending_items 未完了の作業 self_improvement メモリ進化のガイドライン tool_guidelines ツール使用の指針 インストール方法 Claude Code のプラグインシステムを使って 2 コマンドでインストールできる: ...

2026年3月25日 · 2 分

HuggingFace hf-mount: AIモデルをダウンロードせずに仮想ファイルシステムとしてマウント

2026年3月、HuggingFace が新ツール hf-mount を発表しました。HuggingFace Hub にホスティングされている巨大な AI モデルやデータセットを、ダウンロードせずに仮想ファイルシステムとして直接マウントできるツールです。 hf-mount とは hf-mount は、HuggingFace の Storage Bucket、モデルリポジトリ、データセットをローカルファイルシステムとしてマウントするツールです。バックエンドには FUSE(Filesystem in Userspace: ユーザー空間でファイルシステムを実装する仕組み)または NFS を使用します。ファイルは最初の読み取り時に遅延フェッチ(lazy fetch)され、実際にアクセスしたバイトだけがネットワークを通ります。 HuggingFace CEO の Clement Delangue 氏は「ローカルマシンのディスクの 100 倍大きなリモートストレージをアタッチできる」と述べています。 主な特徴 ダウンロード不要: モデルやデータセットを事前にダウンロードする必要がない 遅延フェッチ: 実際にアクセスしたファイルだけがネットワーク経由で取得される 2つのバックエンド: NFS(推奨)と FUSE から選択可能 読み書き対応: Storage Bucket は読み書き両対応、モデル・データセットは読み取り専用 Kubernetes 対応: CSI ドライバー(hf-csi-driver)で Pod 内に FUSE ボリュームとしてマウント可能 インストール Linux(x86_64, aarch64)と macOS(Apple Silicon)に対応しています。 1 curl -fsSL https://raw.githubusercontent.com/huggingface/hf-mount/main/install.sh | sh デフォルトでは ~/.local/bin/ にインストールされます。INSTALL_DIR 環境変数で変更可能です。 ...

2026年3月25日 · 1 分

insanely-fast-whisper: 150分の音声を98秒で文字起こしする CLI ツール

音声の文字起こし(トランスクリプション)は AI の実用的な応用の一つだが、長時間の音声ファイルを処理するには時間がかかる。insanely-fast-whisper は、OpenAI の Whisper モデルを Flash Attention 2 とバッチ処理で高速化し、150分の音声をわずか98秒で文字起こしできる CLI ツールだ。 概要 insanely-fast-whisper は、Hugging Face の Transformers、Optimum、flash-attn を組み合わせた文字起こし CLI だ。2026年3月時点で GitHub スター 11,000 以上を獲得しており、コミュニティ主導で開発が進んでいる。 主な特徴: 高速処理: Nvidia A100 GPU で 150分の音声を約98秒で文字起こし 簡単なインストール: pipx install でワンコマンド導入 複数モデル対応: Whisper large-v3、distil-whisper など Mac 対応: Apple Silicon (MPS) でも動作 翻訳機能: 文字起こしだけでなく、英語への翻訳も可能 ベンチマーク Nvidia A100 (80GB) での 150分音声の処理時間比較: 構成 処理時間 large-v3 (fp32) 約31分 large-v3 (fp16 + batching + BetterTransformer) 約5分 large-v3 (fp16 + batching + Flash Attention 2) 約1分38秒 distil-large-v2 (fp16 + batching + BetterTransformer) 約3分16秒 distil-large-v2 (fp16 + batching + Flash Attention 2) 約1分18秒 large-v2 (Faster Whisper, fp16) 約9分23秒 Flash Attention 2 の効果が顕著で、BetterTransformer と比較しても約2.5〜3倍の高速化を実現している。 ...

2026年3月25日 · 2 分

AIにログを読ませてPDCA計画を立てさせる:深津貴之氏が提案するシンプルな振り返り術

note CXO・THE GUILD 代表の深津貴之氏(@fladdict)が、AI を使った日次・週次の振り返り手法を紹介している。やり方は極めてシンプルで、「昨日(先週)のログを AI に読み込ませて、PDCA 計画を策定させる」だけだという。 手法の概要 深津氏のツイートによると、手順は以下の通り: 昨日(または先週)の作業ログを AI に読み込ませる 「昨日(先週)の問題を解決する PDCA 計画を策定せよ」と指示する AI が問題点を分析し、改善計画を提案してくれる これだけで「仕事と人生がドンドン解決していく」と述べている。 なぜこの手法が効果的なのか ログの蓄積がそのまま改善の燃料になる 日々の作業ログは多くの人が何らかの形で残している。しかし、それを定期的に振り返って改善につなげるのは手間がかかる。AI を挟むことで、ログの分析と計画策定のコストがほぼゼロになる。 PDCA サイクルの「Check → Act」が自動化される PDCA サイクルの中で最もおろそかになりがちなのが Check(振り返り)と Act(改善アクション)のフェーズだ。AI にログを読ませることで、この2つのフェーズが自動的に回るようになる。 客観的な視点が得られる 自分のログを自分で振り返ると、どうしてもバイアスがかかる。AI に分析させることで、見落としていた問題点やパターンに気づける可能性がある。 実践のポイント ログの形式 AI に読み込ませるログは、特別なフォーマットである必要はない。日報、タスク管理ツールの履歴、カレンダーの予定、チャットの履歴など、手元にあるものをそのまま使えばよい。 プロンプトの例 以下は私の昨日の作業ログです。 [ログを貼り付け] このログを分析して、以下の観点で PDCA 計画を策定してください: - Plan: 今日取り組むべき優先課題 - Do: 具体的なアクション項目 - Check: 昨日の問題点と原因分析 - Act: 改善すべきプロセスや習慣 週次での活用 日次だけでなく、週次でも同じ手法が使える。1週間分のログをまとめて AI に渡せば、より大きな視点での改善計画が得られる。 AI × PDCA の広がり この手法は個人の生産性向上だけでなく、チームや組織でも応用できる。InfoQ では AI コード生成における PDCA フレームワークとして、日次のマイクロ振り返り(5〜10分)を AI エージェントと行うアプローチが紹介されている。 ...

2026年3月23日 · 1 分