Claude-Code

Anthropic テクニカルスタッフ（Claude Code 担当）の Thariq（@trq212）が公開した記事「Using Claude Code: Session Management & 1M Context」が注目を集めている。「1M トークンのコンテキストウィンドウがあれば大丈夫」という誤解を正し、長いタスクを成功させるカギはコンテキストの能動的な管理にあると明示した内容だ。本記事では、その内容をもとに 5 つのセッション管理手法を整理する。 Context Rot とは何か コンテキストウィンドウとは、モデルが次のレスポンスを生成する際に「見える」すべての情報のことだ。システムプロンプト・会話履歴・ツール呼び出しとその出力・読み込んだファイルがすべて含まれる。Claude Code のコンテキストウィンドウは 100 万トークン。 しかし、コンテキストを使うことには静かなコストがある。それが Context Rot だ。“Rot” は英語で「腐る・朽ちる」を意味する単語で、ソフトウェアの世界では「Bit Rot」や「Code Rot」のように、時間経過や使用とともに静かに劣化していく現象を指す慣用表現として使われる。直訳すれば「コンテキストの腐敗」、意訳すれば「コンテキストの劣化」となる。 コンテキストが増えるにつれてモデルの性能がトークン数に比例して低下する。会話が長くなるほど、モデルの注意力が分散し、古い・無関係なコンテンツが現在のタスクを妨害するようになる。 Context Rot が始まるタイミングはタスクに大きく依存するため固定のルールはないが、長いセッションになるほど確実に忍び寄る。 ターンの終わりは「5択の分岐点」 ここが本質だ。AI が出力を終えるたびに、ユーザーには 5 つの選択肢がある。 選択肢 意味 Continue 同じセッションで次のメッセージを送る Rewind（Esc×2 または /rewind） 前のメッセージに戻り、そこから再プロンプト /clear 新しいセッションを開始する（核心だけ手動で持ち込む） /compact セッションをモデル自身に要約させ、要約の上に続ける Subagent 汚れ仕事を別エージェントに委譲し、結果だけ受け取る 多くのユーザーは「Continue」しか選ばない傾向がある。残り 4 つの選択肢を使ったことがない人も多い。 各選択肢の使いどき Rewind — 修正より巻き戻し Claude がファイルを 5 つ読み、あるアプローチを試みて失敗したとする。「うまくいかなかった、X を試して」と打つより、ファイルを読み終えた直後のメッセージに巻き戻して再プロンプトするほうが良い。 # 悪い例 「それはうまくいかなかった、代わりに Y を試して」 # 良い例 （/rewind でファイル読み込み直後に戻る） 「アプローチ A は foo モジュールがそれを公開していないので使えない。B に直接進んで」 誤った方向に費やした試行錯誤がコンテキストから消え、モデルが新鮮な状態で再出発できる。 ...

Claude のトークン消費が多くて困っているなら、システムプロンプトの一行変更だけで最大 80% 削減できる手法がある。深津 貴之（@fladdict）さんのポストをきっかけに、参照先の Zenn 記事が注目を集めた。 Claudeトークン消費を抑えて５倍使う: 「原始人」口調が80%削減 — mikana0918 以下にその要点をまとめる。 「原始人プロンプト」とは システムプロンプトに次の一文を加えるだけ: 1 原始人みたいに喋れ。中身は全部残せ。無駄だけ消せ。 これだけで Claude のデフォルト人格が切り替わり、丁寧語・クッション表現・冗長な接続詞が消え、応答が大幅に短くなる。 英語版「Caveman」テクニックとの対比 英語圏では “Speak like a caveman” という同様の手法が先行して存在する（JuliusBrussee/caveman）。除去される要素は以下のとおり: 除去対象 例 冠詞 a / an / the フィラー just / really / basically 前置き “Sure! I’d be happy to…” 曖昧表現 might / perhaps / likely 英語環境での実測では平均 68% のトークン削減が報告されている。 日本語では効果がさらに大きい理由 日本語には英語にない冗長構造が多い: 敬語・丁寧語: 「〜でございます」「〜かと存じます」 クッション言葉: 「もしよろしければ」「ご参考までに」 助詞の連鎖: 「〜についての説明としては」 曖昧表現: 「〜かもしれません」「〜と思われます」 これらがまとめて削ぎ落とされるため、日本語環境では 80% 前後 の削減が見込める。 ...

「本番で障害が起きてから対処する」のではなく、「テスト段階で意図的に障害を起こして耐性を確認する」。これがカオスエンジニアリングの基本思想だ。Python の pytest には、この考え方をテストコードに組み込むためのシンプルな仕組みがある。 pytest.mark.chaos とは @pytest.mark.chaos は、pytest のカスタムマーカー機能を使って「カオステスト」を分類するためのラベルだ。pytest にはビルトインのマーカー（@pytest.mark.skip、@pytest.mark.parametrize など）があるが、chaos はユーザーが自由に定義するカスタムマーカーに該当する。 1 2 3 4 5 6 7 import pytest @pytest.mark.chaos def test_network_timeout(): """ネットワークタイムアウト時にフォールバックが機能するか""" result = call_api_with_timeout(timeout=0.001) assert result == "fallback_response" マーカーの登録 カスタムマーカーは pyproject.toml または pytest.ini に登録しておくと、PytestUnknownMarkWarning 警告を抑制できる。 1 2 3 4 5 # pyproject.toml [tool.pytest.ini_options] markers = [ "chaos: カオスエンジニアリング関連のテスト（障害注入・耐性検証）", ] 選択実行 1 2 3 4 5 6 7 8 # カオステストだけを実行 pytest -m chaos # カオステスト以外を実行（通常の CI） pytest -m "not chaos" # カオステストと統合テストを実行 pytest -m "chaos or integration" これにより、通常の CI パイプラインではカオステストをスキップし、定期的なレジリエンス検証時にだけ実行するという運用が可能になる。 ...

Claude CodeやCodexのようなAgent Harnessは、RAG（Retrieval-Augmented Generation）をほとんど使わないにもかかわらず、高精度なコード生成や理解を実現している。一方、RAGに依存しすぎたAgentはハルシネーションを起こしやすいという逆説がある。なぜこのような違いが生まれるのか？Software Engineer兼Database ResearcherのTaro L. Saito（@taroleo）氏のポストが、その本質を簡潔に説明している。 コンテキストウィンドウの拡大がRAGの必要性を変えた 現行のAIモデルのコンテキストサイズは20k〜1Mトークンに達している。これは、目安としておよそ100ファイル以下のコードベースであれば、RAGを介さずそのままコンテキストに収めて処理できることを意味する。 モデル コンテキストサイズ GPT-4o 128k tokens Claude Sonnet 4.x 200k tokens Gemini 1.5 Pro 1M tokens Claude CodeやCodexなどのAgent Harnessは、この大きなコンテキストウィンドウを活かして、必要なファイルを直接読み込みながらタスクを実行する。ベクトル検索による「関連しそうな断片」の取得ではなく、「実際に必要なコード全体」を参照できる。 RAGの弱点：断片的な情報がハルシネーションを生む RAGは「大量の文書から関連部分を検索して取得する」ことで、LLMに外部知識を与える仕組みだ。ドキュメント検索や広範な知識ベースへのアクセスには有効だが、コードベースのような相互依存が強い構造的情報に対しては課題がある。 RAG特有の問題点： 断片的なコンテキスト: ベクトル類似度で取得したチャンクは、実際の依存関係を無視している場合がある 欠落した情報: 関連するが類似度スコアが低いコードが検索から漏れる 矛盾した断片: 異なるバージョンや関連する別モジュールの断片が混在する こうした不完全な情報でコードを生成させると、存在しない関数を呼び出したり、実際のインターフェースと合わない実装を生成したりするハルシネーションが発生しやすい。 Agent Harnessが「100ファイル以下」で高精度な理由 Claude CodeのようなAgent Harnessが高精度に動く理由は、コンテキストウィンドウの有効活用にある。 プロジェクト構造の把握（ls、find など） 関連ファイルの直接読み込み（cat、read） 完全なコンテキストを持った上でコード生成・編集 RAGのように「類似チャンク」を取得するのではなく、ツールを使って必要なファイルを選択的に読み込むというアプローチだ。ファイル数が100程度であれば、現行のコンテキストサイズに収まるため、コードベース全体を「見た上で」タスクを実行できる。 これにより： 実際に存在する関数・型・インターフェースのみを参照する インポート関係や依存構造を正確に把握する プロジェクト固有の命名規則や設計パターンに従う ベクトル検索が有効なケースと直接読み込みが有効なケース NTT DATAのエンジニアリングブログ「ベクトル検索は不要なのか？」では、生成AI時代にRAGやベクトル検索をどう捉えるべきかを整理している。Taro氏のポストはこの記事を引用しており、「100ファイル以下という目安」はコンテキストサイズとトークン換算から導き出せる経験則だ。 ベクトル検索が有効なケース： 100ファイルを超える大規模コードベース（モノレポ、大企業の内部リポジトリ） 広範なドキュメント検索（社内ナレッジベース、技術文書） リアルタイム情報の取得（外部ドキュメント、最新の仕様） コンテキストに収まる場合に直接読み込みが有効なケース： 中小規模のプロジェクト（スタートアップのコードベース、個人プロジェクト） 特定モジュールへの集中作業 正確な依存関係の把握が必要な場合 RAG自体を強化する方向: GraphRAG という選択肢 「RAGを捨てて直接読み込み」ではなく、「RAGの断片性を補う」方向の研究もある。代表的なのがMicrosoft Researchが2024年に発表した GraphRAG だ。 GraphRAGの基本アイデアは次の通り： ...

Claude Code で動画編集が完全自動化できる「Video Use」が公開されました。browser-use チームが開発したオープンソーススキルです。カメラに向かって話した素材を Claude に渡すだけで final.mp4 が完成します。 Video Use とは Video Use は、Claude Code のスキルとして動作する動画編集自動化ツールです。GitHub リポジトリ browser-use/video-use で公開されており、100% オープンソースで利用できます（ただし ElevenLabs API キーが必要です）。 ブラウザ操作を自動化する browser-use を開発したチームが作成したもので、同じ「LLM に情報を読ませる」思想が動画編集に応用されています。 主な機能 フィラーワード自動カット — 「えー」「あの」「umm」「uh」などの無駄な言葉や、テイク間の無音部分を自動で除去 自動カラーグレーディング — セグメントごとにカラーグレード（ウォームシネマティック、ニュートラルパンチ、カスタム ffmpeg チェーンなど）を適用 字幕自動生成 — デフォルトでは 2 ワードの大文字チャンク形式。スタイルは完全カスタマイズ可能 30ms オーディオフェード — すべてのカット点で自動的に適用され、ポップノイズを防止 アニメーションオーバーレイ — Manim / Remotion / PIL によるアニメーションをサブエージェントで並列生成して追加可能 自己評価ループ — レンダリング後にすべてのカット境界を自動チェック。問題があれば最大 3 回まで自動修正 セッションメモリ — project.md に状態を保存し、次回セッションで継続作業が可能 なぜ LLM で動画編集できるのか Video Use の設計で興味深いのは、LLM は動画を「見ない」 という点です。 Naive approach: 30,000 frames × 1,500 tokens = 45M tokens of noise. Video Use: 12KB text + a handful of PNGs. ...

Claude Code に /team-onboarding というコマンドが追加された。新メンバーが入るたびに口頭で説明していた「うちのチームの Claude Code の使い方」が、1コマンドで自動ドキュメント化されるようになった。 新メンバーへの説明を毎回繰り返す課題 チームで Claude Code を使っていると、新メンバーが入るたびに「うちってどうやって Claude Code 使ってるの？」という質問が飛んでくる。毎回同じことを口頭で説明するのは時間がかかるし、言語化が難しい暗黙知も多い。 /team-onboarding が解決すること /team-onboarding コマンドを実行すると、Claude Code が実行したユーザーの過去のセッション履歴を分析して、チーム向けのオンボーディング資料を自動生成してくれる。 生成される内容は以下のとおり： 過去30日のセッションを自動分析 作業タイプの割合をテキスト形式で可視化（例：Build 40%, Plan 25% など ※実行例） よく使うスキルを頻度順にランキング MCP 接続の使用回数を可視化 新メンバー向けセットアップチェックリストを生成 出力は Markdown 形式なので、Notion や GitHub Wiki にそのままコピペできる。ドキュメント整備の手間が省ける。 使い方 プロジェクトルートで Claude Code を起動し、チャット欄に入力するだけ： 1 /team-onboarding 実行すると、セッション履歴が分析され、チームへの共有に適したオンボーディングドキュメントが生成される。 まとめ 「新メンバーのオンボーディングに毎回時間を取られる」という壁を崩すコマンドだ。チームの暗黙知を自動でドキュメント化し、Notion や GitHub にそのまま貼れる Markdown で出力される。Claude Code をチームで使っている場合は試してみる価値がある。 元ツイート（@SuguruKun_ai）より

Anthropic が「Claude Code Routines」をリリースした。「時間になったら勝手に動く AI」を、誰でも 24 時間クラウド上で完結させられる仕組みだ。 何が変わったのか これまで AI エージェントを自律実行させるには、PC を常時起動させたり、自前のサーバーを用意したり、cron + スクリプトをハック的に組み合わせる必要があった。Claude Code Routines はこの構成を根本から変える。 セットアップは 2 ステップだけ: プロンプトを設定する リポジトリ・外部連携を接続する これだけで、Anthropic のクラウド上でエージェントが自律的に動作する。 PC つけっぱなし → 不要 自前サーバー → 不要 ハック的な構成 → 不要 完全に「インフラレス運用」が実現した。 トリガー設計 Claude Code Routines の最大の特徴は 柔軟なトリガー設計 にある。 トリガー種別 例 cron 毎朝 9 時に定期レポートを生成 API コール 外部サービスから HTTP リクエストで起動 GitHub イベント PR が開いたら、Issue が立ったら、Webhook が飛んだら これにより、人間が起動操作をしなくてもよくなる。PR を開いた瞬間にコードレビューエージェントが動き出し、Issue が作成されると自動でトリアージが走る、といったワークフローが実現する。 「常駐しないエージェント」という設計思想 Claude Code Routines が体現しているのは、単なる「自動化」ではない。 必要なときだけ AI が “自分で目を覚まし”、処理して、また眠る ...

2026年4月14日、Anthropic が Claude Code に3つの大型アップデートを同日リリースした。それぞれ独立したアップデートながら、組み合わさることで「AI を常時活用するインフラ」としての完成度が大きく高まっている。 アップデート1: Routines — Mac オフラインでも自動実行 Routines は、Claude Code エージェントをクラウド上でスケジュール実行できる機能だ。 これまで Claude Code をバックグラウンドで自動実行するには、PC を常時起動し続けるか、別途サーバーを用意する必要があった。Routines はその制約を取り払う。 cron / API / GitHub イベントなど複数のトリガー方式に対応 Anthropic のクラウド上で実行されるため、Mac がオフラインでも動作する リポジトリや外部サービスとの接続設定のみで即稼働 毎朝定時にレポートを生成する、PR が作られたら自動でコードレビューを走らせる——そうしたワークフローが、自前サーバーなしで実現できる。 アップデート2: 新 Desktop — 複数セッションの並列管理 Claude Code の Desktop アプリが刷新された。最大の変更点は複数セッションの同時管理だ。 従来の Claude Code は基本的に「1つのターミナルで1つのタスク」という使い方が中心だった。新 Desktop ではウィンドウやセッションを切り替えながら、複数の作業を並列で進められるようになった。 複数のリポジトリや Issue を同時に扱う際のコンテキスト切り替えが容易 セッションの状態を保持したまま別タスクに移行可能 大規模プロジェクトや複数プロジェクトを掛け持ちするエンジニアに特に有効 アップデート3: ストリーム5分タイムアウトの安定性強化 長時間のタスク実行中に接続が切れる問題が、このアップデートで改善された。 Claude Code は複雑なコード生成・解析・エージェント処理を行う際、処理時間が数分を超えることがある。従来のストリーム接続はタイムアウトが発生しやすく、長尺タスクの信頼性が課題だった。 今回の改善により、5分を超える処理でも安定してストリームを維持できるようになった。Routines による長時間バックグラウンド処理との組み合わせで、より重厚なタスクを任せられる基盤が整った。 3つのアップデートが示す方向性 これら3つの変更を並べると、Anthropic の意図が見えてくる。 アップデート 解決する課題 Routines 「人間が起動する」制約の除去 新 Desktop 「1タスクずつ」制約の除去 ストリーム安定性 「短時間タスクのみ」制約の除去 それぞれが「Claude Code を使う上でのボトルネック」を1つずつ潰している。偶然の同日リリースではなく、統合されたロードマップの一部として設計されたアップデートだと考えると納得感がある。 ...

概要 Claude Code や OpenAI Codex などの AI コーディングエージェントを並列実行する際に発生しがちなファイル競合問題を解決するツール。内部で git worktree + branch の自動隔離を行い、各エージェントが独立した環境で作業できるようにする。 背景：並列実行の課題 ターミナルを複数開いたり tmux でペインを分割して AI エージェントを並列実行すると、すべてのエージェントが同一のワーキングディレクトリを共有するため: 共通ファイルの同時上書き — 複数エージェントが同じファイルを編集し、片方の変更が消える 変更の消失 — あるエージェントが直したコードを別のエージェントが元に戻す dmux はこれらの問題を git worktree の仕組みで自動解決する。 主な機能 機能 説明 自動隔離 エージェントごとに git worktree + ブランチを自動作成 衝突の自動解決 マージ競合を AI が自動解決 エージェント切り替え Claude Code、Codex、Opus、Composer 等を簡単に切り替え A/B テスト 複数エージェントの出力を並べて比較検証 git worktree による隔離の仕組み リポジトリ ├── (メインディレクトリ) ← ブランチ: main ├── .worktrees/agent-1/ ← ブランチ: agent/task-a ← エージェント1 └── .worktrees/agent-2/ ← ブランチ: agent/task-b ← エージェント2 git worktree は同一リポジトリを複数ディレクトリに展開する Git 標準機能。各エージェントが別ブランチで動くため、同一ファイルへの同時書き込みが発生しない。dmux はこの仕組みを自動化する。 ...

AI エージェントを並列実行する際に起きがちなファイル競合問題を、git worktree を活用して自動解決するツール「dmux」を紹介する。 背景：AI エージェント並列実行の落とし穴 Claude Code や OpenAI Codex などの AI コーディングエージェントを複数同時に走らせると、次のような問題が起きやすい。 共通ファイルの同時上書き：複数エージェントが同じファイルを編集し、片方の変更が消える 変更の消失：あるエージェントが直したコードを、別のエージェントが元に戻してしまう ターミナルを複数開いたり、tmux でペインを分割して並列実行する方法は手軽だが、全エージェントが同一のワーキングディレクトリを共有しているため、この問題は常に起きうる。 dmux とは dmux は、AI エージェントの並列実行環境を安全に管理するための CLI ツール。内部的には git worktree + branch の自動隔離 を行い、各エージェントが独立したディレクトリ・ブランチで作業できる環境を自動でセットアップする。 主な特徴 自動隔離：難しい設定なしに git worktree + ブランチを自動作成し、エージェントごとに完全に分離した環境を提供する 衝突の自動解決：マージ競合が発生した場合、AI が自動で解決を試みる エージェント切り替え：Claude Code、Codex、Claude Opus、Composer など任意のエージェントを簡単に切り替え可能 A/B テスト：複数エージェントの出力を比較検証できる git worktree によるエージェント隔離の仕組み git worktree は、同一リポジトリを複数のディレクトリに展開する Git 標準機能。通常の git clone とは異なり、リポジトリのデータを共有しながら、異なるブランチを別ディレクトリでチェックアウトできる。 リポジトリ ├── (メインディレクトリ) ← ブランチ: main ├── .worktrees/agent-1/ ← ブランチ: agent/task-a ← エージェント1 └── .worktrees/agent-2/ ← ブランチ: agent/task-b ← エージェント2 dmux はこの仕組みを自動化し、各エージェントを専用の worktree に割り当てる。エージェント同士は別ブランチで動くため、同一ファイルへの同時書き込みが発生しない。 ...