Claude-Code

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 で以下をすべて管理できます: ...

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