記事一覧

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% 前後 の削減が見込める。 ...

メモツールは世の中に溢れている。Notion、Evernote、Google Keep……。その中で Obsidian が開発者やナレッジワーカーに支持され続けている理由は「ローカルファースト」という設計哲学にある。データは自分のマシンに Markdown ファイルとして保存され、ベンダーロックインが一切ない。 本記事では Obsidian の機能・利点・活用法を網羅的にまとめる。 Obsidian とは Obsidian は ローカルファイルベースの Markdown エディタであり、個人の知識管理（PKM: Personal Knowledge Management）に特化したツールだ。 公式サイト: obsidian.md 料金: 個人利用は完全無料。商用利用のみ Commercial License（$50/年） 対応 OS: Windows / macOS / Linux / iOS / Android プラグイン数: 2,700 種類以上のコミュニティプラグイン 設計哲学：「Your thoughts are yours」 Obsidian の根底にあるのは「あなたの思考はあなたのもの」という哲学だ。 ローカルファースト: データはすべて自分のマシン上の .md ファイル プレーンテキスト: 専用フォーマットなし。他のエディタでも開ける ベンダーロックインなし: Obsidian を辞めても、データはそのまま使える オフライン動作: インターネット接続なしで完全に機能する コア機能 内部リンク（[[]] 記法） Obsidian の最大の特徴が [[ページ名]] で即座にノート間リンクを作れる内部リンク機能だ。リンク先が存在しなくても構わない。リンクをクリックした時点で新規ページが自動生成される。 これにより、メモを書いている最中に「あ、この概念は別ページにまとめたい」と思った瞬間に [[概念名]] と書くだけで、知識のネットワークが自然に広がっていく。 グラフビュー ノート間のリンク関係を視覚的にネットワーク図として表示する機能。知識の全体像や孤立したノートの発見に役立つ。ただし、実用面ではグラフビューよりも全文検索の方が圧倒的に使用頻度が高いという声も多い。 全文検索 Vault（Obsidian のワークスペース）内のすべてのファイルを横断的に検索できる。ローカルファイルなので検索速度が速く、数千ファイルでもストレスなく動作する。 ...

「本番で障害が起きてから対処する」のではなく、「テスト段階で意図的に障害を起こして耐性を確認する」。これがカオスエンジニアリングの基本思想だ。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. ...

「ハーネスエンジニアリング」という言葉がAIエージェント界隈でバズワード化し、意味の希薄化が起きている。watany氏のZenn記事「AIエージェントの"ハーネス"に関わる混乱と私見」は、この混乱を「内側のハーネス」と「外側のハーネス」という軸で整理している。本記事は、その整理を元に「ハーネス」という言葉の意味的な分裂を読み解く。 内側のハーネス（Internal Harness） 開発者・プラットフォーム視点の定義。 LangChain: 「エージェント = モデル + ハーネス」という等式を掲げ、自社をハーネス構築のプラットフォームとして位置づける Anthropic: 長時間実行されるLLM処理の仕組みとして定義。ステートレスなモデル呼び出し間でセットアップスクリプトやGitの履歴などのコンテキストを引き継ぐ機構を指す。生成Agentと評価Agentからなる二段階のマルチエージェント構成も含む 内側のハーネスの議論はベンダーロックインを促す傾向があり、プラットフォームとしての優位性を訴求する文脈で使われやすい。 外側のハーネス（External Harness） ユーザー・実践者視点の定義。 Mitchell Hashimoto: 「AIエージェントが同じミスを繰り返さないように設計する」という実践的なアプローチ。開発者の日常的な課題に根ざした定義 OpenAI: メンテナブルで読みやすいエージェント出力の設計を重視し、将来の実行エージェントが参照できる保守可能な成果物の生成を重視する 外側のハーネスはベストプラクティスの共有が主眼で、特定プラットフォームへの依存を前提としない。 なぜ混乱するのか Takuto Wada（@t_wada）氏はこの記事を紹介し、同じ言葉なのにスコープが違うのは言う側のポジションで意味合いがズレているのが理由だと指摘している。 ベンダーは「ハーネス」を自社製品の文脈で語り、実践者は「ハーネス」を運用上の問題解決として語る。どちらも正しい文脈を持ちながら、同一の言葉が異なる聴衆に向けて発信されている。 まとめ 「ハーネス」という言葉を聞いたとき、それが誰の視点からの発言かを意識するだけで、議論の意図がずっと明確になる。 プラットフォーム・フレームワーク文脈 → 内側のハーネス（統合基盤としての役割） 実践・運用文脈 → 外側のハーネス（エラー再発防止・出力品質の設計） AIエージェント開発が加速する中、用語の解像度を上げることは技術コミュニティ全体の生産性に直結する。watany氏の整理は、この問題に対して実践的な視点を提供している。 参考: AIエージェントの"ハーネス"に関わる混乱と私見 — watany (Zenn) t_wada氏のポスト (X)

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 が「Automated Alignment Researchers（AAR）」の研究成果を発表した。Claude Opus 4.6 を使って、AI アライメントの重要課題を自律的に研究させた実験で、9 体の Claude エージェントが人間の研究者を大きく上回る成果を達成した。 スケーラブル・オーバーサイト問題とは 超知能 AI が登場した場合、能力的に劣る人間がどうやって AI を監督するか、という問題が「スケーラブル・オーバーサイト（Scalable Oversight）」だ。この問題に対し、Anthropic は Claude Opus 4.6 を使って自律的に研究させるアプローチを試みた。 実験の設計 具体的には「weak-to-strong supervision（弱から強への監督）」手法を検証した。弱いモデル（Qwen 1.5-0.5B）を教師役として、強いモデル（Qwen 3-4B）を微調整し、強いモデルが本来の性能をどれだけ引き出せるかを測定する。 実験では 9 体の Claude Opus 4.6 エージェントに以下の環境を提供した： サンドボックス環境 共有フォーラム（エージェント間のコミュニケーション） コード保存サーバー スコアリングサーバー 各エージェントには曖昧なヒントのみを渡し、詳細な指示なしで自律的に研究させた。 評価指標：PGR（Performance Gap Recovered） 性能の評価に使われた指標が PGR（Performance Gap Recovered）だ： PGR = 0：弱い教師モデルと同程度の性能しか引き出せなかった PGR = 1：強いモデルの理想的な性能を完全に引き出せた 実験結果 条件 期間 PGR 人間の研究者 2 名 7 日間 0.23 Claude Opus 4.6 × 9 体 5 日間（累計約 800 時間） 0.97 Claude エージェントのコストは約 $18,000（1 AAR 時間あたり約 $22）。7 日かけて PGR 0.23 を達成した人間の研究者に対し、5 日間で PGR 0.97 という圧倒的な成果を出した。 ...

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 が “自分で目を覚まし”、処理して、また眠る ...