Claude-Code

概要 コンテキストウィンドウが長くなるにつれてモデルの性能がトークン数に比例して低下する現象。古い・無関係なコンテンツが現在のタスクを妨害し、モデルの注意力が分散する。“Rot”（腐る）は Bit Rot・Code Rot と同じ、時間経過で静かに劣化する現象を指す慣用表現。 5 択のセッション管理 Anthropic テクニカルスタッフの Thariq 氏が整理した「ターンの終わりに行う 5 つの選択肢」: 選択肢 意味 向いている場面 Continue 同じセッションで続行 短いタスクで文脈が整理されている Rewind（Esc×2 / /rewind） 前のメッセージに戻り再プロンプト 誤った方向に進んだ試行錯誤を消したい /clear 白紙から新セッション 重要情報を自分で持ち込みたい /compact セッションをモデル自身に要約させる 手間をかけず文脈を圧縮したい Subagent 汚れ仕事を別エージェントに委譲 中間出力が大量で最終結果だけ欲しい /compact vs /clear の使い分け /compact: モデルに要約を委ねる（lossy）。/compact focus on the auth refactor, drop the test debugging のように指示を添えると精度が上がる。デバッグ後に全く別タスクを指示する場面では特に精度が落ちやすい /clear: 手間はかかるが残るコンテキストは自分が必要と判断した情報だけになる（lossless） Subagent を使うパターン 「中間出力が大量に出るが、必要なのは最終結果だけ」という作業に有効。サブエージェントはクリーンな独自コンテキストウィンドウを持ち、中間の試行錯誤が親のコンテキストを汚染しない。 実践的な把握方法 /usage で自分のトークン使用量の推移を確認し、Context Rot が始まるしきい値を事前に把握しておく。鈍くなった後では遅い。 関連ページ コンテキスト圧縮 — 5 段階の圧縮カスケード Claude Code — Context Rot 管理コマンドの実装 ソース記事 Claude Code のコンテキスト管理術 — Context Rot を防ぐ 5 つの選択肢 — 2026-04-17

概要 「本番で障害が起きてから対処する」のではなく「テスト段階で意図的に障害を起こして耐性を確認する」カオスエンジニアリングの考え方を pytest に組み込む手法。@pytest.mark.chaos というカスタムマーカーで障害注入テストを分類・選択実行できる。 セットアップ マーカー登録 1 2 3 4 5 # pyproject.toml [tool.pytest.ini_options] markers = [ "chaos: カオスエンジニアリング関連のテスト（障害注入・耐性検証）", ] 選択実行 1 2 3 pytest -m chaos # カオステストのみ pytest -m "not chaos" # 通常の CI（カオステストをスキップ） pytest -m "chaos or integration" 主要な障害注入パターン ネットワーク障害 1 2 3 4 5 @pytest.mark.chaos def test_api_timeout_fallback(): with patch("app.client.requests.get", side_effect=TimeoutError): result = app.client.fetch_user_profile(user_id=123) assert result == app.client.get_cached_profile(user_id=123) データベース障害 1 2 3 4 5 6 @pytest.mark.chaos def test_db_connection_lost(): mock_primary = MagicMock(side_effect=ConnectionError("Connection lost")) with patch("app.db.get_primary_connection", mock_primary): result = app.db.query_user(user_id=123) assert result is not None # リードレプリカから取得 ランダム障害 Fixture（確率的注入） 1 2 3 4 5 6 7 8 9 10 11 @pytest.fixture def chaos_network(monkeypatch): """30% の確率でネットワーク遅延を注入""" original_get = requests.get def unstable_get(*args, **kwargs): if random.random() < 0.3: time.sleep(random.uniform(1.0, 5.0)) if random.random() < 0.1: raise ConnectionError("Chaos: connection refused") return original_get(*args, **kwargs) monkeypatch.setattr("requests.get", unstable_get) Django との統合 1 2 3 4 5 6 @pytest.mark.chaos @pytest.mark.django_db def test_cache_backend_failure(client): with patch("django.core.cache.cache.get", side_effect=Exception("Redis down")): response = client.get("/api/users/1/") assert response.status_code == 200 # キャッシュなしでも正常応答 CI/CD 組み込み（GitHub Actions） 1 2 3 4 5 6 7 8 9 10 11 12 13 name: Chaos Tests on: schedule: - cron: '0 3 * * 1' # 毎週月曜 AM3:00 jobs: chaos-test: runs-on: ubuntu-latest env: CHAOS_ENABLED: "1" steps: - uses: actions/checkout@v4 - run: pip install -r requirements-test.txt - run: pytest -m chaos --tb=long -v 通常 CI では pytest -m "not chaos" で高速に回し、週次スケジュールジョブでカオステストのみ実行する運用が推奨される。 ...

概要 browser-use チームが開発した、Claude Code のスキルとして動作する動画編集自動化ツール。GitHub リポジトリ browser-use/video-use で公開。カメラに向かって話した素材を Claude に渡すだけで final.mp4 を生成できる。 設計の核心: LLM は動画を「見ない」 従来の素朴なアプローチ（30,000 フレーム × 1,500 トークン = 4,500 万トークン）の代わりに、2 層の情報表現を採用する: 層 内容 容量 Layer 1（常時ロード） ElevenLabs Scribe による音声トランスクリプト（takes_packed.md） 約 12KB Layer 2（必要時のみ） フィルムストリップ + 波形 + ワードラベルの PNG 判断が必要な場合のみ生成 browser-use が LLM に DOM を渡すのと同じ発想で、動画に対しては「テキスト + 必要時の画像」という形で情報を渡す。 主な機能 フィラーワード自動カット: 「えー」「あの」「umm」「uh」などと無音部分を自動除去 自動カラーグレーディング: セグメントごとにプリセットまたはカスタム ffmpeg チェーンを適用 字幕自動生成: デフォルトは 2 ワードの大文字チャンク形式 30ms オーディオフェード: すべてのカット点で自動適用 アニメーションオーバーレイ: Manim / Remotion / PIL によるアニメーションをサブエージェントで並列生成 自己評価ループ: レンダリング後に全カット境界を自動チェック、最大 3 回まで自動修正 セッションメモリ: project.md に状態を保存して次回セッションで継続 セットアップ 1 2 3 4 5 git clone https://github.com/browser-use/video-use ln -s "$(pwd)/video-use" ~/.claude/skills/video-use pip install -e video-use brew install ffmpeg # .env に ELEVENLABS_API_KEY を設定 使い方 動画素材フォルダに移動して Claude Code を起動し、自然言語で指示するだけ。出力はすべて <videos_dir>/edit/ に格納される。 ...

r.kagaya 氏（@ry0_kaga、AstarMinds CTO）が Zenn に公開した記事がある。「ハーネスエンジニアリングとは何で、何ではないのか 〜作る側のハーネス、使う側のハーネス〜」という記事だ。ハーネスエンジニアリングをめぐる言葉の混乱を整理し、エージェントハーネスとユーザーハーネスという2層の区分を提示している。 CLAUDE.md や Skills を書けば「ハーネスエンジニアリングをやっている」と言える。でも、それはハーネスエンジニアリングの全体ではない。この記事ではその全体像を整理する。 そもそも「ハーネス」の定義が割れている 前提として、ハーネスエンジニアリングという言葉には統一された定義がない。同じ言葉を使いながら、各社・各人が指しているものが違う。 用語の来歴 「ハーネス」の原義は馬具だ。馬を馬車に繋ぎ、方向を制御し、力を伝達する装備。ソフトウェア文脈では 2020 年の lm-eval-harness（言語モデル評価ハーネス）が初出とされる（r.kagaya 氏による整理）。2024 年に All Hands AI / OpenHands が「エージェントハーネス」に拡張。2026 年に Mitchell Hashimoto（Terraform 創業者）が「Engineer the Harness」と命名し、OpenAI の記事で広まった。 各社の定義 誰が 何と言っているか LangChain (Vivek Trivedy) 「Agent = Model + Harness。モデルでなければハーネス」 Anthropic 「LLM を呼び出し、ツールコールをルーティングする制御ループ」 OpenAI 宣言的制約 + サンドボックス + スケーリング Böckeler / Martin Fowler サイバネティクス的制御。フィードフォワード × フィードバック Phil Schmid (Hugging Face) Model = CPU, Harness = OS Bedi (Composio CEO) 「システムエンジニアリングのサブセットに新しい名前をつけているだけ」 LangChain の「モデルでなければハーネス」は極めて広い。Anthropic の「制御ループ」はエージェント実装寄り。「そもそも新しい概念ですらない」と言う人もいる。さらにベンダー（作り手）と利用者（使い手）で意味が違うという構造的な問題もある。 ...

スタートアップコミュニティで知名度の高い Greg Isenberg が、Obsidian と Claude Code を組み合わせて「24時間365日稼働するパーソナル AI オペレーティングシステム」を構築する方法を公開した。閲覧数 110 万超、ブックマーク 17,000 超と大きな反響を呼んでいる。 なぜ Obsidian × Claude Code なのか 多くの人は AI を「汎用チャットボット」として使っている。セッションを開くたびに自己紹介し、プロジェクトの背景を説明し直す——この繰り返しが生産性のボトルネックになっている。 Greg が提案するアプローチは、自分の思考・知識・文脈をすべて Obsidian ボルト（ノート群）に蓄積し、Claude Code がそれを読み込んで行動するというものだ。人間が書き、AI が読んで実行する、という明確な役割分担がポイントになる。 10 ステップで始めるパーソナル OS ステップ 1: 全てを Markdown で書く 日報・プロジェクト概要・自分の信念・人脈・議事録——あらゆる情報を Markdown ファイルとして Obsidian ボルトに記録する。フォーマットを統一することで、Claude Code が構造的に読み取れるようになる。 1 2 3 4 5 6 7 8 9 10 11 vault/ ├── daily/ │ └── 2026-04-22.md # 日報 ├── projects/ │ └── my-startup.md # プロジェクト概要 ├── people/ │ └── john-doe.md # 人脈メモ ├── beliefs/ │ └── product-philosophy.md # 信念・哲学 └── meetings/ └── 2026-04-22-kickoff.md # 議事録 ステップ 2: ノート同士を自分の思考回路のようにリンクする [[プロジェクト名]] 形式のウィキリンクでノートを繋ぎ、自分の思考の連鎖を反映させる。単なるメモの集合ではなく、考え方のグラフを構築することが目的だ。 ...

「もう 2 ヶ月以上、手でコードを書いていない」 Claude Code の生みの親であり、Anthropic でその開発を率いる Boris Cherny がそう語ったのは 2026 年 1 月のことだ。Andrej Karpathy の問いかけに応え、X への投稿でこう明かした。 “For me personally, it has been 100% for two+ months now, I don’t even make small edits by hand.” そして今、そのワークフローが広く注目を集めている。2 日間で 49 の Pull Request を出荷、コードは 100% AI 生成という実績が報告され、X では 30 分間のセッション動画が公開され 300 万回近く再生された。 Boris Cherny とは Boris Cherny は、Claude Code を 2024 年 9 月に社内の個人プロジェクトとして始めた人物だ。当初は自分のコーディングを助けるためのツールだったが、Anthropic 社内でその有効性が認められ、正式なプロダクトへと進化した。 彼は後にこう振り返っている。 “When I created Claude Code as a side project back in September 2024, I had no idea it would grow to what it is today.” ...

Claude Code の Skills を使い込むうちに「あれ、前と挙動が違う……」と感じたことはないだろうか。~/.claude/settings.json に 1 行追記するだけで解決できる。原因は auto-memory だ。 Claude Code の auto-memory が Skills の挙動を変える仕組み Claude Code は会話のたびに学習内容を Memory（~/.claude/projects/.../memory/MEMORY.md）へ自動で書き込む機能（auto-memory）を持っている。 問題はこの Memory の内容が次の会話でコンテキストウィンドウに自動挿入される点だ。これにより、Skills に記述した指示と競合し、設計どおりの挙動から少しずつずれていく。 会話を重ねるほど症状が顕著になるため、原因の特定に時間がかかりやすい。 解決策：autoMemoryEnabled: false ~/.claude/settings.json に 1 行追記するだけで解決する。ファイルが存在しない場合は新規作成し、既存の設定がある場合は {} 内に追記する。 1 2 3 { "autoMemoryEnabled": false } これで Memory への自動書き込み・読み込みが停止し、auto-memory 機能全体が無効化される。 影響範囲 機能 autoMemoryEnabled: false にしたときの変化 Memory への自動書き込み・読み込み 停止 CLAUDE.md の読み込み 変化なし（従来どおり動作） Skills に書いたルールの適用 変化なし（従来どおり動作） CLAUDE.md や Skills の設定はそのまま有効なので、プロジェクト固有のルールが失われる心配はない。 ...

Qiita に投稿された「Claude Code を Level 5 まで育てたら、開発が「指示と確認だけ」になった — 実ファイル構成で解説」が大きな反響を呼んでいる。CLAUDE.md・Skills・Hooks・Agents を組み合わせて Claude Code を 5 段階で「育てる」ことで、人間の作業を「指示と確認だけ」に絞り込むアプローチを実ファイル構成とともに解説した記事だ。 「AI にコードを書かせている」と「AI と開発している」は違う Claude Code を導入した当初は、毎回こんなプロンプトを書いていたという： 1 2 3 4 5 UIテキストはハードコーディングしないでください。 src/i18n/ja.ts に追加してから使ってください。 テストも書いてください。 外部リンクには rel="noopener noreferrer" を付けてください。 コミット前に npx astro check と npm test を実行してください。 毎回同じことを書くのは「AI にコードを書かせている」状態であり、「AI と開発している」とは言えない。同氏は 1 か月の試行錯誤を経て、作業は「何を作るか指示する」と「動作確認する」だけになったという。 Claude Code 5 つのレベルの全体像 Level 追加要素 何が自動化されるか 人間がやること 1 素のプロンプト なし 全指示を毎回手打ち 2 + CLAUDE.md プロジェクトルールの自動読み込み ルール違反の指摘が不要に 3 + Skills 手順書のオンデマンド注入 定型作業の手順説明が不要に 4 + Hooks 品質チェックの自動実行 「テスト実行して」が不要に 5 + Agents 並行レビューの自動実行 レビュー依頼が不要に Level 2: CLAUDE.md — 「プロジェクトの憲法」を持たせる プロジェクトルートに CLAUDE.md を置くと、Claude Code が会話開始時に自動で読み込む。これは「プロジェクトの憲法」だ。 ...

東京大学の院生（shunya_sudo）が、45 本の cron ジョブ・36 個のカスタムエージェント・132 本の Python スクリプト で構成した日常業務自動化システムの全記録を Zenn で公開した。M1 冬から約半年間 Claude Code を使い続けて構築したシステムで、メール処理・論文監視・ML コード開発・システム自己監視まで設計原則と実装を網羅している。 システムの全体構成 macOS 上で以下の構成で稼働している。 構成要素 数 cron ジョブ 45 個 カスタムエージェント 36 個 Python スクリプト 132 本 基本アーキテクチャは 「Python が処理、Claude CLI が判断」 というシンプルな分離原則に基づく。データ取得・加工は Python スクリプトが担い、要約・判断・生成を Claude CLI が受け持ち、定時実行は cron で管理する。 主な自動化タスク メール処理（Gmail API） Gmail API を用いてメールを 4 段階に自動分類 し、返信が必要なものには 下書きを自動生成 する。 緊急対応 / 要確認 / 参照 / アーカイブの 4 レベル分類 Claude が文脈を読んで返信の下書きを生成 最終判断・送信は人間が行う 日程調整（ICS URL） ICS URL を活用してカレンダーを自動更新し、日程調整の候補時間を自動挿入する。手動でのカレンダー確認作業をゼロにした。 ...

フロントエンドエキスパートの mizchi さんが「チームでの skills 共有に apm いいじゃん。採用」と X にポストして話題になった APM（Agent Package Manager）。Microsoft がオープンソースで開発しているこのツールは、AI エージェントの設定を package.json のように宣言的に管理・共有できます。 APM とは APM は AI エージェント向けの依存関係マネージャーです。npm や pip がライブラリ依存を管理するように、APM はエージェントが必要とするコンテキスト（スキル、プロンプト、プラグイン、MCP サーバーなど）を apm.yml に宣言して管理します。 対応エージェント: GitHub Copilot Claude Code Cursor OpenCode Codex CLI 解決する問題 AI コーディングエージェントを使うには、標準設定・プロンプト・スキル・プラグインといったコンテキストが必要ですが、現状は開発者が各自で手動セットアップしています。移植性がなく、再現性もありません。 APM を使えば、プロジェクトに apm.yml を 1 つ置くだけで、リポジトリをクローンした全員が同じエージェント環境を即座に再現できます。 基本的な使い方 インストール 1 2 3 4 5 6 7 8 # macOS / Linux curl -sSL https://aka.ms/apm-unix | sh # Homebrew brew install microsoft/apm/apm # pip pip install apm-cli apm.yml の設定例 1 2 3 4 5 6 7 8 9 10 11 12 name: your-project version: 1.0.0 dependencies: apm: # 任意のリポジトリからスキルを取得 - anthropics/skills/skills/frontend-design # プラグイン - github/awesome-copilot/plugins/context-engineering # エージェントプリミティブ - github/awesome-copilot/agents/api-architect.agent.md # バージョン指定した APM パッケージ - microsoft/apm-sample-package#v1.0.0 セットアップ 1 2 3 git clone <org/repo> cd <repo> apm install # エージェント設定が一括セットアップされる マーケットプレイスからのインストール 1 2 apm marketplace add github/awesome-copilot apm install azure-cloud-development@awesome-copilot 主な機能 1 つのマニフェストで全対応 apm.yml で以下をすべて管理できます: ...