<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>npmrundev の記事フィード</title>
        <link>http://izanami.dev/organizations/npmrundev</link>
        <description>npmrundev に関連する記事のRSSフィードです</description>
        <lastBuildDate>Sun, 28 Jun 2026 21:05:06 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>izanami RSS Feed</generator>
        <language>ja</language>
        <image>
            <title>npmrundev の記事フィード</title>
            <url>http://izanami.dev/favicon.ico</url>
            <link>http://izanami.dev/organizations/npmrundev</link>
        </image>
        <copyright>All rights reserved 2026</copyright>
        <item>
            <title><![CDATA[Zed 完全ガイド]]></title>
            <link>http://izanami.dev/post/903fe0a2-878a-4f4b-a02c-d8784d8ef731</link>
            <guid>http://izanami.dev/post/903fe0a2-878a-4f4b-a02c-d8784d8ef731</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 26 Jun 2026 22:52:47 GMT</pubDate>
            <description><![CDATA[Zed が気になってる人向けに書いた

この記事は乗り換え手順じゃなく、Zed の機能をこれ1本で見渡すリファレンス。各機能が何をしてくれるか、よく使うショートカットと便利な使い方まで、ひと通り書いて]]></description>
            <content:encoded><![CDATA[Zed が気になってる人向けに書いた

この記事は乗り換え手順じゃなく、Zed の機能をこれ1本で見渡すリファレンス。各機能が何をしてくれるか、よく使うショートカットと便利な使い方まで、ひと通り書いてくよ

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code テクニックを配信しています

Zed は zed-industries が作ってる Rust 製のコードエディタ。OSS で、エディタ・AI・Git・協業がひとつに集結（今どきですなあ）

https://zed.dev

こんなのでいいんだよエディタ

Vim → Sublime Text → Atom → VSCode →
Cursor → Ghostty → Cursor → Zed（new）

上記は私のエディタ遍歴である。おそらく同じような道を歩んできた人いるだろう

好みのエディタがなかったので、自作しようと考えてたところに、Zed と出会って

こんなのでいいんだよ となった

Zed を作っている Zed Industries は、Atom と Tree-sitter（あと Electron も）を生み出したチーム

Atom の作者たちが、「Electron では速度の限界がある」という反省を踏まえて、今度は Rust でゼロから作り直したのが Zed

しかも Zed 自体が完全オープンソース。めっちゃええやん！

Vim(vimmode)の編集効率、Sublime の軽快さ、Atom のハック心、VSCode/Cursor の AI・エコシステムのいいとこ取り

ファーストインプレッション

所感はこんな感じ（心の声）

- いや、起動早っ！
- お！VSCode、Cursorより軽いやん
- Ghostty より、セットアップ楽やな
- そんなにメモリを占領しない、イケてるやん
- Claude Code、Codex は、Zedのターミナルで並べて起動しよう
- ターミナルのClaude Code 文字化けしない笑
- プロジェクトパネル、Gitパネル、素敵
- Window 上下左右分割するの簡単やんけ！
- 完全オープンソースかあ。やるじゃない（ニコ！）
- Base Keymap は、VSCode, JetBrains, Cursor, Emacs などから選べるのか
- AI エージェントセットアップは、Claude, Codex GitHub Copilot, Corsorから
- Cursor から 設定をインポートできた（でしょうねえ）
- 拡張機能は少ないけど、主要どころは標準搭載なので不自由しない

向いてる人

- メモリを節約したい人
- エディタの速さと所有権（OSS で中身が見える）を重視する人
- Claude Code を普段使いしつつ、ネイティブエディタの中でエージェントを回したい人

しばらく、Zed を使うだろう

Zed とは

作者は zed-industries。中核を Rust でゼロから書いてて、ソースは GitHub で公開されてる。動く環境は macOS・Linux・Windows

強みは、盛らなくてもそろってること。補完や診断みたいな土台に加えて、AI・Git・リアルタイム協業まで最初から内蔵されてる。拡張は言語とテーマが中心で、本体機能を後付けする前提ではない

| 領域           | できること                                   |
| -------------- | -------------------------------------------- |
| 速さ           | Rust ネイティブで起動もスクロールも軽い      |
| マルチバッファ | 複数ファイルを1画面で一括編集                |
| ナビゲーション | コマンドパレットとファインダーで全操作に直行 |
| AI             | エージェント・編集予測・外部CLI連携を内蔵    |
| 実行           | タスク・REPL・デバッガをエディタ内で         |
| Git            | 差分・blame・worktree をエディタ内で         |
| 協業           | 同じプロジェクトを複数人で同時編集           |
| リモート       | SSH や Dev Container で手元の UI のまま      |
| 拡張           | 言語・テーマ・MCP を追加                     |

料金（2026年6月時点・公式 pricing）

- Personal が $0。自分の API キーや外部エージェントは無制限で使える
- Pro は月10ドル。Business は1席あたり月30ドル
- 自前キーは Anthropic や OpenAI、Google AI、Ollama、OpenRouter などに対応

ショートカット早見表

よく使うもの

| 操作                     | macOS                    | Windows / Linux          |
| ------------------------ | ------------------------ | ------------------------ |
| コマンドパレット         |             |            |
| ファイルを開く           |                   |                  |
| プロジェクト内検索       |             |            |
| シンボルへ移動           |             |            |
| アウトラインパネル       |             |            |
| 次の一致をマルチカーソル |                   |                  |
| 全一致を選択             |             |            |
| 診断を1画面に集約        |             |            |
| 定義・参照へ移動         |               |              |
| コードアクション         |                   |                  |
| ターミナルパネル         |  ＋ バッククォート |  ＋ バッククォート |
| 設定                     |                   |                  |
| タスクピッカー           |             |            |
| デバッグパネル           |             |            |
| REPL 実行                |        |        |
| 補完・編集予測を受諾     |                     |                     |

キーマップは  でまるごと差し替えられる。上の表は既定の VS Code キーマップ前提で、他エディタ風に寄せると割り当ては変わる

インストールと最初のプロジェクト

![zed install](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/cfcf0df9-1852-4a0f-a841-e25fb4239e54.png)

zed install

導入は OS ごとにワンライナー

| OS      | インストール                               |
| ------- | ------------------------------------------ |
| macOS   |                   |
| Windows |  |
| Linux   |  |

プロジェクトを開く方法

- ターミナルから 
- Zed 内で 
- 別ウィンドウで開くなら 

フォルダを開いた時点で、それがプロジェクトになる。最初に触りたい設定は、このあたりから

- 設定を開く （名前で検索して直す）
- テーマを選ぶ 
- 保存時に自動整形する  を 

キーマップ

キーを変更する場合 keymap.jsonに



完成！

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/f05b7ad9-2d6b-49f8-807f-baa77fc2b683.webp)

画面を4分割。右にはプロジェクト・Gitパネルなど

めっちゃええやん！面倒な設定なしでこれができるのは嬉しい

Rust ネイティブの速さ

Zed が軽いのは設計から。多くのエディタが土台にする Electron（Web 技術でデスクトップアプリを作る仕組み）を使わず、本体を Rust でネイティブに書いてる

描画は GPU に投げて、処理はマルチコアに振る。だから大きいファイルでも、スクロールやカーソル移動が詰まりにくい。起動も含めてキビキビ動く

マルチバッファと診断・参照

Zed の看板機能がマルチバッファ。複数ファイルの一部を1画面の抜粋としてまとめて開いて、その場で同時に編集できる仕組み

嬉しいのは、自動で集まること。次の操作が多数ヒットすると、結果が1画面に並ぶ。

- プロジェクト検索（）
- 診断（）
- 参照検索・定義へ移動（）

特に診断は強い。 でプロジェクト全体のエラーと警告が1画面に集まって、各抜粋をその場で直せる。エラーを1個ずつ開いて回る作業が消える

マルチカーソルと合わせると一気に速くなる。 で次の一致を足し、 で全一致を選ぶ。広範囲のリファクタが数操作で終わって、保存も  で全ファイルまとめて通る

流れ

1. LSP のリネームで対象を一括変更
2. 影響したファイルがマルチバッファに並ぶ
3. マルチカーソルで追加の手直し
4. 診断が即フィードバックして取りこぼしを拾う

:::success
マルチバッファは検索結果や診断を1画面に集約して、そのまま編集・一括保存できる。複数ファイルにまたがる修正で、開き直しが消えるのが大きい
:::

:::warning
診断・参照検索・定義ジャンプの多くは言語サーバー（LSP）が前提。LSP が入ってない言語だと、マルチバッファに集まる情報が出ないことがある
:::

ナビゲーション

探す動作も速い。メニューを辿らず、ほぼキーボードで完結

- コマンドパレット （全アクションの入口。数文字で絞る）
- ファイルファインダー （名前の一部から開く）
- プロジェクト検索 （結果はマルチバッファで返る）
- 現在ファイルのアウトライン 、常設パネルは 

直前の作業へ戻るならタブスイッチャー。ctrl を押したまま tab で最近使った順に循環して、離すと確定する

AI とコードアクション

AI もエディタに最初から入ってる

- Agent Panel （コードと対話して読む・書く・実行）
- 編集予測 Zeta（入力中に次を予測、 で受諾）
- インラインアシスト （選択範囲をその場で書き換え）
- MCP（GitHub などのコンテキストサーバを足してツールを増やす）

編集予測の Zeta は Zed 製の OSS モデル。無料プランは月2,000回まで、Pro は上限なし

LSP のクイックフィックスを呼ぶコードアクションは 。診断の下線が出た箇所で押すと、修正候補をその場で適用できる

Zed 自身のエージェントは、運用の細かさも持ってる

- Agent Profiles で使えるツールを Write・Ask・Minimal から選ぶ
- Tool Permissions で各ツールを許可・確認・拒否に振り分ける
- Skills に手順を書いておけば、スラッシュコマンドで呼び出せる
- 組み込みの terminal ツールには  みたいな再帰削除をブロックする、上書き不可のガードが入ってる

紛らわしいのが、Claude Code みたいな外部のエージェントを動かす経路。Zed には2系統あって、認証と課金の出どころが変わる

| 経路                 | 中身                                  | 認証・課金                             |
| -------------------- | ------------------------------------- | -------------------------------------- |
| ターミナルスレッド   | 手元の CLI をそのまま Zed 内で動かす  | CLI 側が握る（いつものサブスクのまま） |
| ACP 外部エージェント | 外部エージェントを Agent Panel に接続 | 自前で別管理（Zed は課金しない）       |

毎回同じ CLI を立ち上げるなら  に  などを設定しておくと、シェルを開いた瞬間にそのコマンドが流れる

:::discovery
手元のサブスクをそのまま使いたいならターミナルスレッドで。CLI 側が認証と課金を持つから、Zed 側の料金を増やさず、いつもの環境で動く
:::

実行・テスト・デバッグ

コードを動かす系もエディタ内で完結する。タスク・REPL・デバッガがそろってて、ターミナルを別に開かなくていい

タスクは統合ターミナルにコマンドを流す仕組み。タスクピッカー  から選んで実行して、直前のタスクはそのまま再実行できる

- 変数を渡せる （今のファイル）・（選択テキスト）・（行番号）
- 置き場所はグローバル・プロジェクト・その場限り（oneshot）から選ぶ
- VS Code の  もインポートできる

REPL は Jupyter カーネルでコードを対話実行する機能。 でブロックや選択を流して、結果をその場に出す。Python・TypeScript・R・Julia・Scala に対応する

セルモードもある。Python は 、TypeScript は  でセルを区切って、ノートブックのように順番に走らせる

デバッガは DAP（Debug Adapter Protocol）ベースでマルチ言語に対応。ガターのクリックでブレークポイントを置いて、 でデバッグパネルを開く。条件付きやヒットカウントも指定できる

事前構成が無い言語は  に書く。VS Code の  も読めるから、既存の起動設定を流用できる

Git が手に馴染むのはなぜか？

Git もエディタを離れずに回せる。CLI で打った変更も即反映

- Git パネルが作業ツリーの状態・ステージング・ブランチを表示
- Project Diff はマルチバッファで開いて、差分を見ながらその場で直してハンク単位でステージ
- blame はインライン表示で、その行を誰がいつ変えたかが横に出る
- worktree は同じリポの複数チェックアウトを並行で持って、ピッカーから切り替える
- コミットメッセージは AI に書かせられる（LLM プロバイダの設定が要る）
- ホスティング連携で参照がリンク化、 で今の行への共有リンクを取れる

worktree には作成時フックがある。 を設定しておくと、新しい worktree を切った瞬間に  のコピーみたいなセットアップを自動で走らせられる

CLI のコミットエディタを Zed にしたいなら、 に  を設定する。ターミナルで commit したとき、Zed が開いてメッセージを書ける

ターミナル統合

ターミナルも内蔵で、 ＋ バッククォートでパネルを開閉する。下部・左右・センタータブと配置を選べて、Python の仮想環境は自動でアクティベートされる

便利なのがパスのハイパーリンク化。出力に出たファイルパスを  すると、そのファイルがエディタで開く。行番号や列まで認識して、その位置に飛ぶ

ターミナル内でもインラインアシスト（）が使える。コマンドを言葉で頼んで、出力を組み立てられる

人とのリアルタイム協業

Zed は人との同時作業も標準。複数人が同じプロジェクトを開くと、互いのカーソルと編集がリアルタイムに見える。チャンネルという永続ルームに、共有プロジェクト・ボイスチャット・共同ノートがまとまる

フォローで相手のカーソルとスクロールに追従できて、画面共有も使える。音声で話しながら、同じコードを一緒に書ける

やるじゃない…

勘違いしやすいけど、これは Cursor の AI ペアプロとは別物。相手は AI じゃなく人間で、Live Share みたいな拡張も要らない

:::warning
プロジェクト共有は、相手に手元ファイルへのアクセスを渡すことになる。信頼できる相手とだけ共有する
:::

リモート開発と Dev Containers

手元のマシンで作業するとは限らない。Zed のリモート開発は、UI はローカルのまま、言語サーバーやターミナルをサーバ側で動かす

- 接続は  か  形式
- 重いビルドや言語解析はサーバに任せて、編集体験はローカルの軽さを保てる
- ポートフォワードで、リモートの開発サーバを手元のブラウザで localhost として開ける

Dev Containers にも対応する。リポジトリに  があれば、コンテナの中でプロジェクトを開いて、誰が開いても同じ再現環境で作業できる（Docker か Podman が要る）

:::warning
devcontainer.json を変えても自動では再ビルドされない。設定を直したらコンテナを止めて開き直す
:::

拡張・テーマ・移行

拡張は言語・テーマ・アイコン・MCP サーバーなどを足す仕組み。言語サポートは、対応ファイルを開くと言語サーバーが自動でダウンロードされて、更新も自動で入る

移行まわりは中々厚い

-  で VS Code・Sublime Text・JetBrains・Cursor などのキーバインドに寄せる
- ・ でモーダル編集を足す
-  で VS Code 設定をインポート（フォント・タブ・ターミナルが自動変換、拡張とキーマップは別途）

テーマとアイコンはギャラリーから選ぶ。自作は Theme Builder で作れて、本文と UI のフォントも別々に指定できる

:::discovery
VS Code から移るなら、設定インポートと  の VS Code で土台を再現できる。 を  にすれば、保存時の自動整形もすぐ戻る
:::

コード理解を助ける表示

コードを読む助けになる表示もそろってる

inlay ヒントをオンにすると、変数や引数の推論された型がコードの行内に薄く出る。型を確かめにジャンプしなくていい

構文解析は Tree-sitter ベース。ハイライトやアウトライン、言語ごとに調整されたカーソル移動が、この構文ツリーから作られてる

設定の基本

設定ファイルは JSON。 のコメントも書ける。

| 種類                          | 置き場所                              |
| ----------------------------- | ------------------------------------- |
| ユーザー設定（macOS / Linux） |          |
| ユーザー設定（Windows）       |          |
| プロジェクト設定              | リポジトリ直下の  |

プロジェクト設定をリポジトリに同梱すれば、チーム共通の整形やタブ幅を配れる。マージ順は デフォルト → ユーザー → プロジェクトで、後のものが勝つ

よく触るキーは ・・・・ あたり

:::warning
 や  みたいにエディタ全体へ反映されるキーは、ユーザー設定専用。プロジェクト設定に書いても反映されない。プロジェクト側で上書きできるのは ・・ など
:::

開発体験

よし

- 設定変更の多くは即座に反映されて、エディタの再起動が要らない
- 設定もキーマップも素のテキスト。 と  をドットファイルとして持てば、バージョン管理に乗せて持ち運べる
- 移行ガイドが各エディタ向けにそろってて、VS Code・JetBrains 系からの乗り換えで何が変わるかを先に把握できる

向いてる人とまとめ

Zed が向くのは速さと所有権を重視する人。Electron じゃないネイティブな軽さ、中身が見える OSS、そして AI は外部の CLI に寄せたい人にハマる

料金は2026年6月時点で、個人向けの Personal が $0、Pro が月$10、Business が1席あたり月$30。AI を手元の CLI で動かすなら、Zed 側の課金を増やさず、いつものサブスクのまま使える


オープンソースってのがいいね

オープンソースでコードが見える（Zed なら zed-industries/zed が GPL で公開）というのは、最悪その先を自分たちで続けられる、という保険になる。これは「いつでも逃げられる」という安心が、逆に長く使う理由になるという面白い構造

もうひとつは、最近の流れとして「無料で囲い込んで後から課金」「データを握って収益化」みたいなモデルへの疲れがある気がしてる

便利さと引き換えに何を差し出しているのか分かりにくい製品が増えた反動で、思想や立ち位置がはっきりしているもの、ユーザーと利害が大きくはズレないものに惹かれる

Cursor との違いは、Zed 公式が比較ページを出してるよ

https://zed.dev/compare/cursor
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code を動かす7手段、公式の使い分け]]></title>
            <link>http://izanami.dev/post/788bc6f5-f31c-4fde-8110-f9262e88797a</link>
            <guid>http://izanami.dev/post/788bc6f5-f31c-4fde-8110-f9262e88797a</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 22 Jun 2026 17:37:24 GMT</pubDate>
            <description><![CDATA[Anthropic 公式が「指示の届け方は7手段あって、用途で使い分けろ」という整理を出してたのが、めっちゃ実用的（いつも長いけど）だったので、7手段それぞれの選びどころを雑に書いた

体感が微妙なと]]></description>
            <content:encoded><![CDATA[Anthropic 公式が「指示の届け方は7手段あって、用途で使い分けろ」という整理を出してたのが、めっちゃ実用的（いつも長いけど）だったので、7手段それぞれの選びどころを雑に書いた

体感が微妙なとき、モデルを疑う前に指示の置き方を見直すと変わることがあるかもね

https://claude.com/ja/blog/steering-claude-code-skills-hooks-rules-subagents-and-more

X で毎日 Claude Code情報を配信してる[コムテ](https://x.com/commte)です

7手段

それぞれ「いつ Claude に読まれるか」「コンテキスト圧縮の後も残るか」が違う

1. CLAUDE.md
2. Rules
3. Skills
4. Subagents
5. Hooks
6. Output styles
7. システムプロンプト追記

同じ指示でも置き場所で変わるってのがポイント

結論。指示は CLAUDE .md に全部書くんじゃなくて、性質ごとに7手段へ散らせって言ってるな

公式ブログが挙げてる用途、長いから圧縮

| 手段                   | 使い分けのコツ                   |
| ---------------------- | -------------------------------- |
| CLAUDE.md              | 200行以内に保つ                  |
| Rules                  | 横断ルールは paths でスコープ    |
| Skills                 | 30行超の手順はここに逃がす       |
| Subagents              | 重い調査は別コンテキストへ       |
| Hooks                  | 「毎回」「絶対するな」は Hook で |
| Output styles          | 自作する前に組み込みを見る       |
| システムプロンプト追記 | 役割は変えず規約や出力形式を足す |

「絶対するな」系は指示（文章）で頼むのでなくて

- Hook
- permissions

で機械的に止める

思ったのだが、こうも面倒な使い分けが増えてくると、AI成果物の差がどんどん開いていくよね

やっぱ、ちゃんと整理して覚えておいたほうがいいな

7手段を4軸で早見する

公式は7手段を4つの軸で比べろと言ってる

- (a) いつ読まれるか
- (b) compaction（長い会話を要約して圧縮する処理）の後も残るか
- (c) コンテキストコスト
- (d) authority（強制力）

いつ読まれて、圧縮後に残るか。まずここを表で見る

| 手段                          | いつ読まれるか                       | 圧縮後に残るか       |
| ----------------------------- | ------------------------------------ | -------------------- |
| CLAUDE.md（ルート）           | 常時ロード                           | 圧縮後に再読込される |
| CLAUDE.md（サブディレクトリ） | そのフォルダを触ったとき             | 再び触るまで消える   |
| Rules                         | paths 対象を触ったとき               | 圧縮時に再注入される |
| Skills                        | 名前と説明は最初、本体は呼ばれたとき | 呼ばれたときだけ     |
| Subagents                     | 親が起動したとき                     | 隔離されて別枠       |
| Hooks                         | イベントで確定発火                   | 圧縮対象外           |
| Output styles                 | システムプロンプトに注入             | 圧縮されない         |
| システムプロンプト追記        | その起動だけ                         | 圧縮されない         |

軸のポイントだけ補足

- ルートの CLAUDE.md は常時ロードで圧縮後も再読込。強いがコストが高い
- Rules は paths にマッチしたファイルを触ったときだけ読まれる。paths なしは常時ロード
- Skills は名前と説明だけ先に見えて、本体は呼ばれたとき開く
- Hooks と Output styles は強制力の質が違う

棲み分け

- 読んでほしいだけ → CLAUDE.md や Rules
- 絶対やってほしい・やめてほしい → Hook か permissions

:::discovery
「毎回かならず X しろ」「絶対に Y するな」を指示文で書くと、Claude は守らないことがある。Hook や permissions で機械的に縛るべし
:::

各手段の選びどころ

CLAUDE.md は薄いインデックスに保つ

公式の勧めは「200行以内に保って、所有者を決めて、コードと同じくレビューしろ」

CLAUDE.md をレビューしたことなんてないんだが？？

まぁでも、行数どーだこーだよりも、コンテキストをスッキリさせるのが先かな？

ビルドコマンドやディレクトリ構成みたいな全体の前提だけ置く。詳しい手順やルールは別のファイルに逃がして、CLAUDE.md はそこを指す索引にする

Rules は paths でスコープする

特定のパスにだけの制約は Rules に置いて paths で絞る

公式の例だと「API ハンドラは Zod で入力検証しろ」みたいなファイル単位の決まり。paths を付けないと CLAUDE.md と同じで常時ロード。関係ない作業でもコンテキストを食う

Skills は長い手順を置く

デプロイ手順やリリースのチェックリストみたいな手続きは Skills へ

公式いわく「30行を超える手順は CLAUDE.md でなく Skills に切り出せ」。名前と説明だけ先に見えて、本体は呼ばれたとき開くから、常時のコストがかからない

そういえば、最近は、ブラッシュアップした内容をスキルとして保存して再利用するってことも増えたなあ

それくらいは、皆やってそうやね

Subagents は隔離して回す

深い検索・ログ解析・依存監査みたいなサイド作業は Subagents

隔離コンテキストで動いて、親には最終結果だけ返る

中間結果で本筋を汚さず、結果だけ受け取れるのが強み

Hooks は確定的に走らせたい処理に

リンタ実行・完了時の通知・コマンド遮断みたいに「毎回かならず」やりたい処理は Hook

イベントで確定発火して、コンテキストの外で動く

Hookの情報って、X で見かけないのよ。勝手なイメージだが、活用できてる人いない気がするね

公式によると PreToolUse なら exit code 2 でツール呼び出し自体を止められる

Output styles は組み込みを先に見る

役割を大きく変えるとき向き。システムプロンプトに注入されて圧縮されない、authority が最強

authority = 強制力（その指示がどれだけ強く守られるか）ってことかな

指示文（CLAUDE.md/Rules）はモデルの判断で破られうる＝弱い

Hook/permissions や Output stylesはシステム側で確定的にいける＝強い

公式の勧めは「自作する前に組み込みの Proactive・Explanatory・Learning を見ろ」

システムプロンプト追記はトーンの微調整に

CLI のフラグで、その起動だけ・追記のみの一時的な手段

指示を足すほど遵守度は下がるから、常設のルールには向かない

authority の使い分け

7手段の本質は「読ませる」と「強制する」の違い

- 読んでほしい情報 → CLAUDE.md・Rules・Skills（指示）
- 絶対やる・やめさせる → Hook・permissions（機械的）

「絶対するな」を指示文で書いても、長いセッションや曖昧な状況、ファイル経由のプロンプトインジェクションで破られることがある

決定的なガードレールが要るなら、指示でなく Hook か permissions で縛る

置いたルールやフックは動作するか検証する

ルールやフックは、置いただけだとちゃんと動作してるかよく分からない

指示の置き場所を変えたら、狙いどおり読まれてる・発火してるか一度検証する

:::warning
落とし穴が1つ。CLAUDE.md や常時ロードのルールは、セッション開始時に読み込まれる

だから変更が反映されるのは次に立ち上げたセッションから。同じセッションの中で直しても、その場では反映されない

ルールやフックをいじったら、新しいセッションで確かめる
:::

今日できる最初の一歩

:::success

1. CLAUDE.md を数えて、肥大化してたら他ファイルへ参照を飛ばすインデックス構造にする
2. 特定フォルダ専用のルールは Rules に出して paths でスコープする
3. 「絶対するな」「毎回かならず」系を1つ選んで、Hook か permissions に移す

:::

7手段ぜんぶ完璧に使い分ける必要は全然ないと思います

まずは CLAUDE.md ダイエットと「絶対するな系を機械化」をやるといいね
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Codeで実サイトのデザインをFigmaで再現する]]></title>
            <link>http://izanami.dev/post/0dab9634-bfcc-4089-8396-4c025821ac5f</link>
            <guid>http://izanami.dev/post/0dab9634-bfcc-4089-8396-4c025821ac5f</guid><dc:creator>commte</dc:creator>
            <pubDate>Thu, 04 Jun 2026 16:52:05 GMT</pubDate>
            <description><![CDATA[X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です

既存サイトのリニューアル要件が入ったとしよう

Figma デザイン提出を求められた。]]></description>
            <content:encoded><![CDATA[X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です

既存サイトのリニューアル要件が入ったとしよう

Figma デザイン提出を求められた。しかし、一から既存サイトのデザインを再現するのは骨が折れる

自分が最初からデザインするならいいけど、元々あるサイトのデザインをこちらで完璧に再現して作っていくのは苦行である

なので、楽しよう。必要なのはこれ

- Claude Code のスキル
- Chrome DevTools MCP
- Figma MCP
- Claude in Chrome
- スタイルガイドライン

目視の往復が消えて、Figma 側が実装と数値レベルで揃うよ

Chrome DevTools MCP install

Figma MCP と Chrome DevTools MCP をインストールしておく

https://github.com/ChromeDevTools/chrome-devtools-mcp

Figma は、デスクトップ版があるといいね

Chrome DevTools MCP は、Claude Code などの MCP クライアントから Chrome を操作するサーバ。一般には「ライブデバッグ・Lighthouse・スクショ」用途で知られてる

でも本命は別にある。evaluatescript で任意の JS を実サイト上で実行して、結果を JSON で返せることだ

ここが転用ポイントになる。重要なのは computed style を取る専用ツールが無いこと。少なくとも執筆時点では用意されてない

だから自分で getComputedStyle を流す。evaluatescript の中で実行して、欲しい値だけ JSON にして返す。これが実測の核になる

実サイトの寸法は目視でなく実測する

実サイトの寸法・色・フォントは目視でなく getComputedStyle で実測する。Chrome DevTools MCP の evaluatescript で測って、その数値を usefigma で Figma に反映する

これで合わせ込みが一発で決まる。スポイトで色を吸ったり、定規アイコンで測ったりする工程が消える

:::success
この記事では実測ワークフロー7ステップと、そのまま使える evaluatescript の実測テンプレを全部出す
:::

usefigma とは

usefigma は Figma 公式 MCP の write-to-canvas ツール。Plugin API 経由で JS を実行して、ネイティブな Figma ノードを直接書き換える

スクショを貼り付けるのとは違う。サイズ・色・variables といった実構造を更新できるのが強い

ひとつ前提がある。書き込みは Figma の有料プラン＋Full seat が要る（Dev seat は読み取りだけ）。ベータ中で条件は変わりうるので、最新は公式を確認してね

なぜ目視じゃダメか

目視は誤差の温床になる。3つの理由で破綻する

- スクショの色スポイトは圧縮やディスプレイで誤差る
- アイコンの実寸・行間・border-radius は目で測れない
- レスポンシブで値が変わり「いつ測ったか」でブレる

:::warning
目視で「だいたい合ってる」は、実装とデザインの乖離が静かに溜まる原因になる。数値で照合しないと気づけない
:::

getComputedStyle と getBoundingClientRect の基礎

実測で使う2つの API を整理しておく

| API                   | 取れる値                     | 主な用途            |
| --------------------- | ---------------------------- | ------------------- |
| getBoundingClientRect | レンダリング後の座標とサイズ | box の寸法・位置    |
| getComputedStyle      | CSS の最終算出値             | font・color・border |

getComputedStyle は外部 CSS も反映した最終値を返す。だから実装の真の値が取れる

疑似要素は getComputedStyle(el, "::before") で取れる。アイコンを ::before で出してる実装はこれで中身を測る

実測ワークフロー7ステップ

ここが独自性の核になる。毎回この順で回す

1. 対象セクションを決め、Figma ノードと CSS セレクタをメモする
2. Chrome DevTools MCP で実サイトを開き、viewport を固定する（resizepage で 1920×1080 など）
3. evaluatescript で box・style・::before を一括実測する
4. styleguide のデザイントークンと照合する
5. usefigma で Figma ノードに反映する
6. 実サイトと Figma を並べて視覚比較する
7. worklog に対象・実測値・反映内容を記録する

ステップ4の照合はこう判断する。トークンと一致したらトークン値を採用、特殊値なら実測値をそのまま使う

ステップ5は反映前に確認がいる。Figma 側に手動編集が入ってないか見てから、サイズ・色・font-size・line-height・border-radius・座標を流し込む

ステップ6でズレたら③〜⑤を繰り返す。ここを面倒がらないと精度が上がる

:::discovery
viewport を固定するのが地味に効く。固定しないとレスポンシブで値が動いて、測るたびに別の数字が返ってくる
:::

実測テンプレ

evaluatescript に流す JS はこれを使う。対象セレクタだけ差し替える

これも一例だから、いい感じにアレンジしてくれ



一点だけ制約がある。返り値は JSON シリアライズ可能にする。DOM ノードや関数をそのまま返さず、必要な値を文字列や数値に落として返す

色は  の文字列で返ってくる。HEX が欲しいときは受け取り側で変換する。 のようなショートハンドは空文字が返ることがあるので、longhand で取るのが確実だ

styleguide でブレを固定する

実測値はそのまま使うと危うい。14px のつもりが 13.98px で返ったり、似た色が微妙に違う値で散らばる

そこで styleguide を1枚用意する。既存サイトの CSS から設計トークンを抜き出した、Figma とコーディングの共通基準である

ここで大事なのは、新しくデザインを設計しないこと。あくまで既存サイトに出てくる値をそのまま拾ってトークン化する。だから「このスケールは妥当か」みたいな議論は起きない。サイトの実態がそのまま正解になる

中身はサイトごとに変わるけど、拾う項目はどこも同じ

- 文字サイズ: 出てくる font-size を一覧化して用途を振る
- 行間: line-height の種類を絞る
- 色: 役割ベースのトークンにする
- 角丸: border-radius を用途ごとに数種類へ固定

色だけは役割で名前を付けると効く。実装の意図が名前で分かるようにする

| トークン | 役割                           |
| -------- | ------------------------------ |
| text     | 本文の文字色                   |
| primary  | 主色（リンク・アイコン・枠線） |
| accent   | 強調                           |
| border   | 区切り線                       |

具体値はサイトから実測した値で埋める。HEX もサイズもサイト依存なので、ここでは決め打ちしない

ここまで作ると、ステップ4の照合が効いてくる。実測値がトークンに一致したらトークン値を採用、外れ値だけ特殊値として実測値を残す

:::discovery
端数や1色のブレは、styleguide に snap させた瞬間に消える。実測の精度を、設計の一貫性で受け止める形になる
:::

つまずきポイントと対処

実際に回すとここで詰まる。対処をセットで置いておく

色はそのまま使えない。getComputedStyle が返す rgb を HEX に変換すれば正確に揃う。スポイトの目視と違ってディスプレイ依存がない

アイコンは特に厄介だ。フォント版のアイコン（FontAwesome 等）はテキストでなく ::before の擬似要素で描かれることが多い。だから ::before の font-family・font-size・color を測れば実寸が取れる。SVG 版だと ::before が空になるので、その場合は background-image や子の svg を見る

viewport は必ず固定して測る。固定しないと同じ要素でも別の数字が返る

Figma にフォントが無い時もある。その場合は styleguide の代替フォントに置換して、実装値はコメントか worklog に残す。値を捨てずに記録するのが後で効く

:::alert
プライベートな実サイトの値を扱うときは、クライアント名や URL を成果物に残さない。worklog にも一般化した記述で書く
:::

スキル化して再利用

この7ステップは一度きりで終わらせない。Claude Code のスキルにして毎回呼ぶ

design-tune のような名前でスキル化すると、対象セレクタを渡すだけで実測から反映まで回せる。手順を毎回思い出さなくていい

再現可能な資産になるのが大きい。属人化したコツを、いつでも呼べる形に固定できる

スキル（一例）

例えば、 に以下のようなスキルを作る

これは一例だから、君の要件に合うようにアレンジするといいね

docs/styleguide.mdmcppluginchrome-devtools-mcpchrome-devtoolsnewpage実サイトの URLresizepage::beforefont-familyfont-sizecolorgetComputedStyledocs/styleguide.mdusefigmaCLAUDE.mdmcpclaude-in-chrometakescreenshotnode.screenshot()

終わりに

debug 用と思われてる Chrome DevTools MCP は、実測ツールに化けるね

evaluatescript で getComputedStyle を流すだけで、実装の真の値が JSON で返る

その数値を usefigma で Figma に焼き込めば、合わせ込みは目視を卒業できる
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Codeのトークンを削減しつつ、同等の回答精度を維持するライブラリ]]></title>
            <link>http://izanami.dev/post/ce82cdd3-cb71-4143-8528-7e552d2aa4c4</link>
            <guid>http://izanami.dev/post/ce82cdd3-cb71-4143-8528-7e552d2aa4c4</guid><dc:creator>commte</dc:creator>
            <pubDate>Tue, 02 Jun 2026 17:57:28 GMT</pubDate>
            <description><![CDATA[headroom は LLM にコンテキストを送る前に、その中身を圧縮してくれるミドルウェア（処理の間に挟まる中間層）だ。ツール出力・ログ・ファイル・RAG の検索結果・会話履歴みたいに、プロンプトに]]></description>
            <content:encoded><![CDATA[headroom は LLM にコンテキストを送る前に、その中身を圧縮してくれるミドルウェア（処理の間に挟まる中間層）だ。ツール出力・ログ・ファイル・RAG の検索結果・会話履歴みたいに、プロンプトに積まれて膨らみがちなテキストを手前で削ってくれる

仕組みはシンプルで、まず ContentRouter が「これは何のデータか」を型判定する。それから JSON なら JSON 用、コードならコード用、と専用の圧縮器に振り分けてから縮める

可逆性も用意されてて、原本はローカルに保持される。LLM が「ここ元の全文が欲しい」となったら  で取り戻せるようになってる。つまり消すんじゃなく、いったん畳んで必要なら戻せる仕組みだね

https://github.com/chopratejas/headroom

要するに、Claude や GPT に渡す手前で長いテキストを賢く間引いてくれる中継ぎ、と思えばいい

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code テクニックを配信しています

今回は headroom を実際に Claude Code 環境に入れて、自分の手元でトークン数を計測してみた。結論から言うと、効くデータと効かないデータがはっきり分かれた。何でも縮むツールじゃないっていうのが正直なところ

ぶっちゃけ、万人向けの「とりあえず入れとけ」ツールではないかな。トークン爆食いの自覚があるエージェント運用者が、自分の数字で確かめて入れる道具

仕組み

中身をもう少し分解しておく。headroom の処理はざっくり 型判定 → 専用圧縮 → 可逆保存 の流れで、実際は KV キャッシュのプレフィックスを揃える CacheAligner なんかも前段に噛んでる

中心になるのが ContentRouter で、これがデータの型を見分ける。次に型ごとの専用圧縮器に流す。ここが headroom の肝になる部分だ

| 圧縮器         | 担当するデータ            |
| -------------- | ------------------------- |
| SmartCrusher   | 構造化された JSON         |
| CodeCompressor | AST（構文木）対応のコード |
| Kompress-base  | 学習モデルによる汎用圧縮  |

最後に CCR が復元性を担保する。LLM に渡す圧縮ペイロード自体は情報が間引かれてる（lossy）。ただし原本はローカルにそのまま残ってて、LLM が必要になったら  で完全復元できる。畳んだ表現を渡しつつ元データは手元に温存する、という二段構えになってる

Claude Codeへの組み込み方

導入はかなり手軽な部類だ。一番ラクなのは  のワンコマンドで、Claude Code を headroom 越しに起動するやり方

もう一つは proxy（中継サーバー）を  で立てて、Claude Code の  をそのポートに向けるパターン。これならコード側を一切いじらずに差し替えできる。ゼロコードで挟めるのは地味に強い

-  一発でラップ
- proxy 経由なら  を立てて  を向けるだけ
- MCP として入れるなら 
- SDK ラッパーは Anthropic / OpenAI / Vercel AI SDK / LangChain 対応

選択肢が広いから、自分のスタックに合わせて挟み方を選べるのがいい

proxy を挟むと、全プロンプトとツール出力がローカルの proxy・CCR ストアを通る。原本がローカルに残る local-first 設計だから外部送信はないけど、機密を扱うなら原本ストアの置き場所と権限だけは把握しておきたい

:::warning
proxy や wrap を使うには fastapi などの extras が要る。 で全部入れるのが無難。実際に自分が base 単体で入れたら、CLI が fastapi 不足で動かなかった。試すときは最初から  推奨
:::

実際にインストールして計測した

ここからが本題で、 に隔離した venv（独立した Python 環境）を作って計測した。インストールは 。Python 3.10+ か TypeScript、圧縮エンジンの一部は Rust 実装、ライセンスは Apache 2.0。作者は Tejas Chopra で英語圏の OSS だね

計測は最小呼び出しの one-liner でやった。 を呼んで前後のトークン数を比べるだけのシンプルな構成



まず構造化 JSON のツール出力。コード検索100件を想定したデータを食わせた

| 項目                   | 値              |
| ---------------------- | --------------- |
| 圧縮前                 | 11,570 トークン |
| 圧縮後                 | 6,414 トークン  |
| 削減率                 | 44.6%           |
| ウォーム時のレイテンシ | 約100ms         |

これは SmartCrusher が効いた結果だ。構造化された JSON は型がはっきりしてるぶん、専用圧縮器がガツンと刺さる。44.6% は素直にでかい

それで次が問題で、冗長なビルドログ400行を食わせたら削減率は 0% だった。デフォルトの  では一切縮まなかったってこと

:::discovery
0% のとき裏で何が起きてたかというと、Kompress-base の初回ロードに約75秒かかってた。さらに HF（Hugging Face）認証なしの警告も出てた。テキストモデルは初回のモデル読み込みが重いから、初手はもっさりする
:::

つまり、構造がはっきりしたデータには劇的に効くけど、素の冗長テキストには最小呼び出しだと無風、という結果だった

作者ベンチと自分の結果のズレ

ここで気になるのが、作者が出してるベンチとの差だ。先に言っておくと、以下の数字は全部 作者ベンチ・ワークロード依存の値で、自分の 0% とは前提条件が違う

| ワークロード     | 作者ベンチの圧縮率 |
| ---------------- | ------------------ |
| コード検索       | 92%                |
| SRE              | 92%                |
| issue triage     | 73%                |
| コードベース探索 | 47%                |

精度面も出てて、作者ベンチではベースライン比で GSM8K が同等、TruthfulQA はむしろ微増、SQuAD は19%圧縮時で97%を保ってる、とされてる。 で再現できるらしい

じゃあなんで自分のログは 0% だったか。これは欠陥じゃなくて条件の違いだと見てる。自分がやったのはライブラリ最小呼び出しの  one-liner で、作者ベンチは proxy / wrap のフル構成での測定

つまり同じ headroom でも、最小呼び出しとフル構成では振る舞いが変わる。ログ系を縮めたいならフル構成で適切な圧縮器に乗せる必要がありそう、ということ。ここは自分がフル構成まで測ってないから、断定じゃなく推測として置いておく

レイテンシも正直に書いておく。ウォーム時で 15〜200ms くらい、テキストモデルの初回ロードはもっとかかる（自分の計測で約75秒）。常時挟むなら、このウォームアップ込みで考えたほうがいい

:::success
構造化データなら 44.6%、作者ベンチでは最大92%。LLM に渡す表現は間引かれるけど、原本はローカルに残るから必要なら  で完全復元できる。圧縮の前提を理解して使えば、コンテキスト節約の効果はちゃんと出るツールだ
:::

どういう人に向くか

総合すると、headroom は「何でも縮む魔法」じゃなくて「型のハマるワークロードで効く道具」だ。向き不向きをまとめておく

- 向く ツール出力や RAG 結果など構造化 JSON を大量に積む人
- 向く コード検索・SRE・issue triage 系の定型データを扱う人
- 微妙 素の冗長ログを最小呼び出しでサクッと縮めたい人
- 微妙 初回75秒のウォームアップを許容できない短時間用途

Claude Code でコンテキスト上限と戦ってるなら、proxy か wrap で挟んで自分のワークロードで一度計測するのがいい。効くデータかどうかは、結局あなたの手元のデータ次第

導入も計測も難しくないから、まずは隔離 venv で  入れて one-liner で測ってみるのがおすすめ

https://pypi.org/project/headroom-ai/

https://huggingface.co/chopratejas/kompress-base
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[AIエージェントのセキュリティ設計｜Zero Trust for AI Agents]]></title>
            <link>http://izanami.dev/post/9a6465eb-3be8-486d-9a34-3e46594c0579</link>
            <guid>http://izanami.dev/post/9a6465eb-3be8-486d-9a34-3e46594c0579</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 01 Jun 2026 11:29:27 GMT</pubDate>
            <description><![CDATA[X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です

Anthropic が「Zero Trust for AI Agents」っていう全3]]></description>
            <content:encoded><![CDATA[X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です

Anthropic が「Zero Trust for AI Agents」っていう全34ページの公式 eBook を出したね

企業が AI エージェントを安全に動かすためのセキュリティフレームワーク

これは、自律的に動くAIエージェントを企業に導入する際、「どのようにセキュリティを担保すべきか」をまとめた実践的なガイドラインですな

ゼロトラスト（何も信頼せず全部検証する、を前提にした設計思想）を、AI エージェントにどう当てはめるかを実装レベルまで落とし込んだガイドになってる

一次情報これな

https://claude.com/blog/zero-trust-for-ai-agents

8フェーズの実装ワークフローの随所に「これは Claude Code がこう対応してる」っていう Pro-tip が差し込まれてる

つまり普段ワイらが便利機能だと思って使ってる権限承認とかサンドボックスが、そのまま企業向けゼロトラスト実装として公式に名指しされてたんよね

しかし、Zero Trust for AI Agents は長い。おまけに英語

この記事では eBook のエッセンスを日本語で構造化しつつ、8フェーズと Claude Code 機能の対応表にまとめる。全訳やなくて骨格の抽出

結論

AI エージェントを企業に入れるときのセキュリティの型は、もう公式に固まりつつある。それがゼロトラスト

そして驚くのは、その実装の大半を Claude Code が標準機能でカバーしてること。8フェーズのワークフローほぼ全部に、対応する Claude Code 機能が紐づいてた

:::success
普段の便利機能を企業セキュリティの視点で読み直すといいかも。それがこの記事で渡したい一番の価値
:::

なぜ今ゼロトラストなのか

AIエージェントの登場によって以下のリスクが激増してる

- マシンスピードでの被害: AIが人間の承認なしに連続してツール（Web検索、API、データベース等）を叩くため、乗っ取られた際の被害スピードが早すぎる
- 権限の悪用: AIは正当な権限を与えられて動くため、従来のアクセス制御では「AIが正しい指示で動いているのか、悪意ある指示で動かされているのか」を区別できない
- 攻撃の低コスト化: 攻撃者側もAIを使うため、脆弱性を突く攻撃を24時間、ほぼゼロコストで大量に仕掛けてくる

これに対抗するため、「誰も信用しない、すべてを検証する、すでに侵入されていると仮定する」というゼロトラストの原則が不可欠になる

フロンティア AI のせいで、脆弱性が見つかってから悪用されるまでの時間が数ヶ月から数時間に縮んだ。守る側も攻める側も AI で加速してて、境界の内側は安全っていう昔ながらの防御はもう追いつかない

そこで効くのがゼロトラスト。3つの原則でできてる

- 何も信頼せず常に検証する
- 侵害は既に起きていると仮定する
- 最小権限のみ付与する

ゼロトラスト自体は新しい概念ちゃう。米英豪の政府が既にガイダンスを出してて、米国は2027年までに全連邦機関へ義務化する流れ

HIPAA や GDPR、EU AI Act みたいな規制ともきれいに整合する。規制業界ほど効いてくる話やね

ただ AI エージェントに当てはめるには形を変える必要がある。eBook はエージェント特有の新要件を4つ挙げてた

- 暗号学的に根拠のあるアイデンティティ
- タスク毎にスコープした権限
- ポイズニング耐性のあるメモリ
- 自律攻撃の速度で動く防御運用

エージェントは何が違うのか

AIエージェントは、従来のソフトウェアとは異なる以下のような特有の攻撃対象（アタックサーフェス）を持ってる

従来のソフトは決められたロジックを実行するだけ。エージェントは目標を解釈してツールを選び、複数ステップを自律的に実行する

この自律性のぶんだけ、新しい攻撃面が生まれる。eBook が整理してた脅威のタクソノミーがこれ

- プロンプトインジェクション 直接（ユーザー入力）と間接（Webやメール等の外部データ）。LLM は情報と実行命令を確実に区別できない、っていうのが根っこの問題
- ツールポイズニング MCP（AIと外部ツールをつなぐ規格）の記述子やメタデータを汚染する。正規バイナリ経由やからホスト監視に映らへんのがいやらしい
- アイデンティティ・権限濫用 権限を絞らず継承させたり、前のセッションでキャッシュした秘密を悪用したり
- メモリポイズニング 一度汚染されたコンテキストが、その後のセッションずっと攻撃者の目的を実行し続ける
- サプライチェーン 汚染されたモデルの重みや、悪性 MCP サーバ

ここで覚えておきたい概念が2つある

ひとつは blast radius（爆発半径、侵害されたときの被害範囲）。読み取り専用なら小さいし、クラウド管理権限なら甚大。投資はこの露出に見合わせる

もうひとつは least agency（最小エージェンシー）。OWASP が提唱した最小権限の拡張版で、各ツールが何を・どれだけの頻度で・どこでできるかまで絞り込む考え方だね

いちばん刺さった判断軸

全コントロール共通の設計テスト

問いはひとつ

> この対策は攻撃を不可能にするのか、それともただ面倒にするだけか

自律攻撃者は無限の根気と、ほぼゼロの試行コストを持ってる。だからレート制限とか追加の踏み台ホップとか SMS の二要素認証みたいな「面倒なだけ」の対策は、スケールで殴られて崩れる

逆に生き残るのは、ハードウェアに紐付けた資格情報、数分で失効する短命トークン、暗号アイデンティティ、そもそも存在しないネットワーク経路

:::discovery
迷ったら、流量を絞るコントロールより能力そのものを奪うコントロールを選ぶ。この視点は AI 関係なく普通のセキュリティ設計にも効く考え方やと思う
:::

本題 8フェーズ × Claude Code 対応表

ここが eBook の核心。実装ワークフローは8フェーズに分かれてて、各フェーズの末尾に Claude Code の対応機能が名指しで載ってる

| フェーズ                         | 要点                                                       | 対応する Claude Code 機能                                                                                                                                                                 |
| -------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 要件定義                       | 規制要件・運用目標・制約を定義して関係者を合意             | 該当なし                                                                                                                                                                                  |
| 2 サプライチェーン管理           | AI-BOM、OpenSSF Scorecard、依存ツリー監査、暗号署名        | 製品機能ではなく実践寄り。MCP サーバを自前ホストして検証後に自己署名。依存の重複監査は Claude 等の LLM に lockfile を読ませる                                                             |
| 3 エージェント境界定義           | 一意 ID、承認/禁止アクションの明文化、blast radius 特定    | 一意の  と ・ をテレメトリに付与。 で粒度の細かいアクセス制御、 パラメータ、hooks                                     |
| 4 プロンプトインジェクション防御 | 入力隔離、constitutional classifiers、攻撃面の縮小         | input sanitization、command blocklist（curl/wget 等を既定遮断）、isolated context windows、network request approval                                                                       |
| 5 ツールアクセス保護             | ツール許可リスト、能力制限、パラメータ検証、サンドボックス |  でツール単位の権限制御、PreToolUse hook で引数検証、sandboxing（FS・ネットワーク・OS レベル隔離）                                                                         |
| 6 認証情報保護                   | 短命トークン、ハードウェア紐付け、JIT、ABAC                | 資格情報を OS の資格情報ストアに保存し  で外部 Vault 連携。OAuth 2.0 自動リフレッシュ。 権限はセッション終了で失効。サブエージェントは隔離コンテキストで親履歴を見ない |
| 7 メモリ保護                     | メモリ隔離、コンテキスト整合性検証、保持ポリシー           | セッション分離が既定。 で保持期間を制御。checkpoint と rewind（Esc 2回 または ）                                                                              |
| 8 重要指標の計測                 | dwell time、coverage、explainability、検知速度             | OpenTelemetry メトリクスと audit logging で活動を追跡。重要システムは検知1時間以内が目標                                                                                                  |

表を見てもらうと分かるけど、要件定義フェーズ以外には全フェーズに Claude Code の Pro-tip が紐づいてる（フェーズ2だけは製品機能やなく実践 Tip やけど）

deny-by-default の権限承認、サンドボックス、managed settings（組織横断ポリシーを管理者が強制してユーザーは上書きできない）、OpenTelemetry での監査。普段「便利やな」で済ませてた機能が、企業セキュリティの言葉で並べ直されると別物に見える

つまりワイが毎回  をいじって権限を絞ってるのは、ゼロトラストの言葉でいう least agency と blast radius の最小化やったわけや

段階を踏むための3ティア

eBook は実装レベルを3段階に分けてた

- Foundation 最低限。ただし AI 攻撃で底が上がってて、摩擦だけの対策はもう失格扱い
- Enterprise 大半の組織が目標にすべき標準
- Advanced 高リスク・規制が厳しい環境向け

おもろいのは、この3つが固定じゃないこと。技術が進むにつれて Advanced が Enterprise に、Enterprise が Foundation に降りてくる前提で書かれてる

:::warning
今の最低限は、すぐ底上げされる。短命トークンや暗号アイデンティティは、もう Foundation の入口要件になってる
:::

守る側も同じ速度で動く

eBook の後半は、エージェントを守るだけやなくて、セキュリティ運用自体を攻撃者と同じ速度に上げる話やった。Agentic SOAR（セキュリティ運用を自動化・自律化する基盤）っていう考え方

要点はこんな感じ

- アラートキューの先頭にモデルを置く。read-only のトリアージエージェントが一次調査して、人が本当に見るべきアラートに集中させる
- 原則は「インシデントの事務作業は自動化、判断は自動化しない」。封じ込めや顧客連絡みたいな判断は人間が握る
- tabletop 訓練は5件同時インシデントで回す。1件想定やと AI 攻撃の桁違いの発見量に追いつけない

この「事務は自動化、判断は人間」っていう線引きは、Claude Code を業務に組み込むときの考え方とそのまま地続きだと思った

ワイの場合

TODO(human)

まとめ

AI エージェントを企業に入れるときのセキュリティの型は、もうゼロトラストで固まりつつある。そしてその実装の大半を Claude Code が標準機能でカバーしてた

一能力でも飛ばすと、攻撃者はその穴を突いてくる

eBook が最後に書いてた一言

最も有利な組織は、最先端 AI を持つ組織やない。土台が固くて AI スキャンでそもそもバグが出にくい組織、そして初日から侵害前提で設計した組織

:::success
次のアクションは、自分の  を一回ゼロトラストの目で見直すこと。どのツールに deny-by-default がかかってて、どこが ask になってて、blast radius がどこまで広がってるか。普段の設定が、そのまま企業セキュリティの練習台になる
:::

[PDF - Zero Trust for Al Agents](https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6a1611a04085d7cd3dadc924Claude-eBook-Zero-Trust-for-AI-Agents-05182026.pdf)

eBook 本体は34ページで、ティア別の実装テーブルや Pro-tip が全部載ってる。一次情報を当たるのが一番早いね

]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code に Chrome DevTools MCP いれて監査が便利]]></title>
            <link>http://izanami.dev/post/4065740a-3734-420b-ba5b-48529eb53615</link>
            <guid>http://izanami.dev/post/4065740a-3734-420b-ba5b-48529eb53615</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 25 May 2026 19:40:36 GMT</pubDate>
            <description><![CDATA[でるとは思ってたけど、Chrome DevTools MCP は、Google の Chrome DevTools チームが作ってる公式ツール

Claude Code、Codex、Antigravi]]></description>
            <content:encoded><![CDATA[でるとは思ってたけど、Chrome DevTools MCP は、Google の Chrome DevTools チームが作ってる公式ツール

Claude Code、Codex、Antigravity に「かます」ことができる

:::success
AI エージェントに実物の Chrome を操作させる。実際に Chrome 開いて、チェックしてくれるんよね
:::

中身は Puppeteer（Chrome を自動操作するライブラリ）経由で本物の Chrome を駆動してるから、シミュレーションやなく実ブラウザの計測値が返ってくるわけ

要するに、Claude に「本物のブラウザの目と手」を持たせるやつだと思えばいいね

:::discovery
人間が DevTools を開いてやってた表示確認・パフォーマンス計測・コンソール調査を、Claude が実際の Chrome 越しに代わりにやってくれる。すげえ楽になる
:::

ほんで、Google だけじゃなくて、Vercel、Supabase 、AxiomなんかもCLIから見れるようになってるやん？

「ブラウザで何回もページ移動するのダルい勢」からすると、DevTools 開くの、ちょいちょいストレスだったからマジ助かるよね！（圧）

あらゆるサービスを、Claude Code 内で完結させるっていうのがおいらの目標です

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code 速報やテクニックを配信しています

そうそう、今週あたりから、izanami で、AI系の記事書いてくれたら、X で pickup するで！記事中で PR してくれてもOKよ

Chrome DevTools MCP

Chrome DevTools MCP のライセンスは Apache-2.0、リポジトリは GitHub に公開されてる

https://github.com/ChromeDevTools/chrome-devtools-mcp

そして 2026/5/19 に Chrome DevTools for agents の 1.0 が stable リリースされたばっかりやな

出たての鮮度がある今のうちに触っておくと美味しい。提供形態は MCP サーバー / CLI / Agent Skills の3系統あって、自分の使ってるエージェントに合わせて選べる

https://developer.chrome.com/blog/devtools-for-agents-v1

Claude Code に Chrome DevTools MCP いれてサービスの監査をしよう

Lighthouse 監査。

Claude Code に Chrome DevTools MCP を入れて自分のサイトを健康診断させたら、実ユーザーの CLS が 0.30 で思いっきり不合格だった

手元で再現しない不合格を、プロンプト1行で炙り出せるじゃん

ツールの名前を覚えてた時代はもう終わりっぽいですねえ

監査は人間が DevTools を開いてポチポチやるものから、Claude Code に投げるものに変わった。実際にやってみたら、自分が見落としてた不合格がボロボロ出てきたので、その手触りを書いておく

結論：プロンプト1行で健康診断でき、lab では見えない実ユーザーの不合格まで炙り出せる

ツールの正体が分かったところで、結論を先に置いておく

Claude Code に Chrome DevTools MCP を入れると、ツール名を一切覚えずに自然文1行でサイトの監査ができる

しかもそれが一番効く場面は、自分の手元では絶対に再現しない不合格を見つけてくれるところにある

:::discovery
ワイの場合、手元で1回リロードして測った CLS は 0.00 だった。完璧だと思ってた。でも実ユーザーの CLS は 0.30 で、良好基準の 0.1 を大きく超えて不合格だった。この差は手作業の Lighthouse では一生気づけない
:::

つまり「自分の環境では問題ない」っていう一番タチの悪い思い込みを、Claude Code が勝手に剥がしにくる。ここからは導入の手順と、実際に出てきた監査結果を順番に見ていく

導入は2行（Claude Code の場合）

Claude Code に入れるのはめっちゃ簡単で、コマンド2行で終わる

前提は Node.js の LTS（長期サポート版）と Chrome が入ってることだけやね

まずマーケットプレイスを追加する



続けてプラグインをインストールする



これで MCP サーバー本体に加えて、専用の Skill が6個ついてくる

Skill っていうのは Claude が状況に応じて勝手に参照する手順書みたいなもので、入ってるのは以下のやつ

- a11y-debugging（アクセシビリティのデバッグ）
- chrome-devtools（基本操作）
- chrome-devtools-cli（CLI 連携）
- debug-optimize-lcp（LCP 改善）
- memory-leak-debugging（メモリリーク追跡）
- troubleshooting（トラブル切り分け）

ツール自体はデフォルトで一通り有効になってて、emulation / performance / network 系は最初からオンになってる

extensions / third-party / webmcp 系は opt-in（手動で有効化）になってるので、必要になったら足す感じやな

Claude Code 以外でも使えて、横並びで手順を置いておく

:::success

- Codex は （汎用 MCP 追加で対応）
- Gemini CLI も公式 agents ページに手順あり
- Antigravity 2.0 も対応済み
  :::

どのエージェントを使ってても、公式の agents ページに導入手順がまとまってるので、迷ったらここを見る

https://developer.chrome.com/docs/devtools/agents

使い方：プロンプトを投げるだけ

ここが一番気持ちいいところで、たくさんあるツール名を一個も覚えなくていい

やることは自然文を1行投げるだけやな

ワイが実際に投げたのはこれ



これだけで、Claude が裏でツールを自動的に選んで順番に叩いてくれる

なんつーか、今どきよね（ワイは、コマンドっぽいのが好きだけどね）

こっちが指示しなくても、こんな流れを勝手に組み立てる

- ページを開く（navigatepage）
- Lighthouse を回す（lighthouseaudit）
- トレースを取る（performancestarttrace）
- コンソールメッセージを拾う（listconsolemessages）

あー、自動で ブラウザ開いてたよ

:::discovery
従来は DevTools のどのタブを開いて、どのボタンを押して、どの数値を読むかを全部人間が覚えてた。それが「直すべき所を優先度順に教えて」の1行に圧縮された。覚えるべきは API やなく日本語の依頼文だけになった
:::

つまり監査のスキルが「ツールの操作手順」から「何を聞きたいか」に移った

これが Agentic（AI エージェント主導）な開発体験の、なにげにデカい変化だと思う

実測：自分のサイトの健康診断結果

御託はいいので、実際に自分のブログを健康診断させた結果を出す

Lighthouse のカテゴリ別スコアはこうだった

| カテゴリ         | スコア | 状態            |
| ---------------- | ------ | --------------- |
| SEO              | 100    | 満点            |
| Best Practices   | 100    | 満点            |
| Accessibility    | 91     | 惜しい          |
| Agentic Browsing | 黄信号 | pass 比率が低い |

SEO と Best Practices は満点だったので、ここは普段の運用で十分整ってた

ほんで問題は下の2つだ

Accessibility が 91 で、満点まであと一歩

そして一番ヤバかったのが Agentic Browsing で、ここは黄信号だった

:::warning
Agentic Browsing は他のカテゴリと採点方式が違って、信号の pass / fail の pass 比率で評価される。100点満点の何点っていう単純な点数やない。だから「46だった」みたいに点数として読むと誤解するので注意する
:::

よくないね

スコアの内訳だけ見ても「ふーん」で終わるけど、本番はここからだ

Core Web Vitals を lab と field の両方で測らせたら、思い込みが一発で崩れた

一番の発見：lab では CLS 0.00 なのに、実ユーザー（field）は CLS 0.30 で不合格

これがこの記事を書いた理由そのもの。Core Web Vitals を2つの計測源で並べたらこうなった

| 指標 | lab（手元1回） | field（実ユーザー p75） | 良好基準    |
| ---- | -------------- | ----------------------- | ----------- |
| CLS  | 0.00           | 0.30                    | 0.1 未満    |
| LCP  | 1370ms         | 2482ms                  | 2500ms 未満 |

CLS（Cumulative Layout Shift、レイアウトのガタつき具合）が、手元では 0.00 なのに実ユーザーでは 0.30

良好基準の 0.1 をブッちぎって不合格だった

LCP（Largest Contentful Paint、主要コンテンツの表示速度）も lab は 1370ms で爆速なのに、field は 2482ms でギリギリ「要改善」のラインだ

ここで lab と field の違いを押さえておく

lab は自分の手元で1回リロードして測る理想環境の値で、field は CrUX（Chrome User Experience Report、実際のユーザー環境を集めた Google のデータ）の実測値だ

p75 っていうのは「ユーザーの上から75%が体感した値」で、つまり遅い側のユーザーまで含めた現実の数字になる

なんでこんなに差が出るのか。理由はシンプルで言い切れる

:::discovery
lab は読み込み中・above the fold（最初に見える画面の上部）のシフトしか見ない。一方 field はページの全寿命にわたるシフトを拾う。だから lab で 0.00 でも、スクロール後や遅延読み込みで起きるガタつきを field は全部カウントする
:::

この lab と field が乖離する仕組みは、web.dev の公式記事が裏付けてる。手元の Lighthouse だけ見て安心するのが、いかに危ういかがよく分かる

https://web.dev/articles/lab-and-field-data-differences

うーん、リンク先は英語にスイッチしてな！

つまり手元で何回 Lighthouse を回しても、実ユーザーが踏んでる地雷には永遠に気づけなかった

これがまじでおっかない

Claude Code が field データまで引っ張ってきたから、初めて不合格が表に出た

根本原因と打ち手（優先度順）

Claude には「直すべき所を優先度順に」って頼んでたので、原因と打ち手をセットで返してきた

優先度順に並べる

1. ヒーロー画像の寸法未確保 → CLS の主因
2. コンソール404 → 内部リンクの prefix ミス
3. link-name 監査0点 → A11y と AI可読性を同時直撃
4. テキストのコントラスト不足 → WCAG AA 未達
5. 画像ホストへの preconnect ゼロ
6. Google Tag Manager が重い

1つ目が CLS の犯人だった

ヒーロー画像（ページ冒頭の大きい画像）に幅と高さを指定してないと、画像が読み込まれた瞬間にレイアウトが下にズレてガタつく

打ち手は width / height か aspect-ratio を先に確保すること、それと next/image で priority などを使って優先読み込みすることだ

:::warning
Next.js の priority が preload 非推奨化の方向っていう噂は、当該実装では未確認なので断定しない。ここは next/image の機能で優先制御する、くらいの粒度に留めておく
:::

2つ目のコンソール404 は、内部リンクの prefix（パスの接頭辞）がズレてて、実在しないパスへ prefetch（先読み）してたのが原因だった

地味やけど無駄なリクエストとエラーログを垂れ流してたわけだ

3つ目が個人的に一番おもろかった

link-name 監査（リンクに名前がついてるかのチェック）が0点で、これが Accessibility と Agentic Browsing の両方を同時に殴ってた

:::success
アイコンだけのリンクに aria-label を、画像リンクに alt を付ける。たった1つ直すと、Accessibility と Agentic Browsing の2カテゴリが同時に上がる構造になってる。コスパが異常にいい打ち手だ
:::

4つ目は薄いグレーの文字色が WCAG AA（アクセシビリティ基準）の 4.5:1 コントラスト比に届いてなかった

濃い階調に振れば解決する

5つ目は画像ホストへの preconnect（事前接続）がゼロで、6つ目は Google Tag Manager が重いっていう、よくあるやつだった

優先度の高い上3つを潰すだけで、CLS の不合格とエラーログとアクセシビリティが一気に改善する見込みが立った

手作業で DevTools を3タブ往復してたら、この優先順位付けまで自分でやらなあかんかった

AI可読性（Agentic Browsing）は SEO の次の戦場

ここで Agentic Browsing をもう一段掘り下げる

これは Lighthouse 13.3 の experimental（実験的）カテゴリで、AI エージェントがそのページを読めるか・操作できるかを測る指標だ

人間やなく AI 来訪者向けの健康診断っていう新しい発想になる

測ってる信号は4つ

- アクセシビリティツリー（names / labels = link-name）
- CLS
- llms.txt（AI 向けのサイト案内ファイル）
- WebMCP（ページが AI に機能を提供する規格）

採点の詳細は公式に出てて、pass / fail の比率で評価される仕組み

https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring

注目したいのは、4信号のうち link-name と CLS が、人間向けの Accessibility・Core Web Vitals と完全に被ってるところだ

さっきの「1つ直すと2カテゴリ上がる」がここでも効く

:::discovery
アクセシビリティ対応がそのまま AI可読性対応になる。人間に優しいサイトは AI にも優しいっていう、当たり前やけど見落としがちな構造がスコアに表れてる
:::

つまり A11y を真面目にやってきた人は、知らんうちに AI可読性の貯金もできてた

逆にここをサボってきたサイトは、人間にも AI にも読みにくいまま放置されてる

監査は人間が覚えるものから、AI に投げるものになった

ちょい後半はAIに書いてもらったけど、まぁいいやろ

今回やったことを一段引いて振り返る

Claude Code × Web パフォーマンス、そして Claude Code × LLMO（大規模言語モデル最適化）の交差点に、地味だけど効く鉱脈があった

- 監査はツール名を覚える作業から、自然文1行に変わった
- lab だけ見る安心は危険、field で実ユーザーの不合格が出る
- A11y 対応がそのまま AI可読性対応になる

DevTools のタブを覚えてた時代から、「直すべき所を優先度順に教えて」の1行で済む時代になった

覚えるべきは API やなく、何を聞くかだけやな

そして Agentic Browsing っていう新カテゴリは、AI可読性が SEO の次の戦場になることを告げてる

英語圏には Claude Code × Web パフォーマンスのコンテンツが大量にあるけど、日本語で field データの不合格まで踏み込んだ実測記事はまだ少ない

やっぱし今のうちに自分のサイトを Claude Code に健康診断させて、人間にも AI にも読まれるサイトに整えておくと、後で効いてくる]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Chrome公式 Modern Web Guidance — AIに何を食わせるかの標準化が始まった]]></title>
            <link>http://izanami.dev/post/38c75d90-9f0d-40b3-8285-a5ba008acfe1</link>
            <guid>http://izanami.dev/post/38c75d90-9f0d-40b3-8285-a5ba008acfe1</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 23 May 2026 10:50:19 GMT</pubDate>
            <description><![CDATA[AI コーディングは「プロンプトをどう書くか」から「AI に何を食わせるか」に主戦場が移ってる

X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commt]]></description>
            <content:encoded><![CDATA[AI コーディングは「プロンプトをどう書くか」から「AI に何を食わせるか」に主戦場が移ってる

X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です

金曜日の朝。ワイは、Google の Google Engineering Practices（コードレビュー基準のドキュメント集）を Claude Code のスキルに手作業で食わせるという回りくどい作業をしてた

https://github.com/google/eng-practices

Claude Code に質の高いPR書かせたいと思っていたからである

Google Engineering Practices をスキルにリポジトリごとぶち込んで、必要な部分だけ読ませたわけ

リポジトリを丸ごと references というディレクトリに置いて、SKILL .md で「迷ったらこの 1 ファイルだけ読め」って導線を引く、みたいな感じね

要するに「専門家が決めた作法を AI に参照させる辞書」を手で組んでた

最初に要約して入れたら原文からズレて失敗したけど、リポジトリ丸ごと積む形にしたら安定した

:::info
Claude Code がリンク先ちゃんと読まないからって、要約かますの微妙ですよね？
:::

とりま、SKILL.md 全文もコピペで作れる手順も izanami に書いた

https://izanami.dev/post/e63c7bfd-cc85-4421-a4e7-776e93fb8720

まぁ、それはいいとして

その後くらいに、Chrome が Modern Web Guidance っていう公式の Agent Skill を出してきたのを発見

https://github.com/GoogleChrome/modern-web-guidance

自分が今日手でやってた「専門家検証済みの作法を AI に食わせる」術を、プラットフォーマーが公式に標準化しに来てた

:::discovery
個人が手ロールで埋めてた穴を、半日後にプラットフォーマーが公式で塞ぎに来る流れ。AI コーディングの世界でこれから何回も起きそうです！
:::

まぁ、野良スキルより公式がいいよね

ほんじゃ、Modern Web Guidanceを、ちょい試した感想を雑に書いとく

ガッツリやりたい人は、自分で試してくれよな

AI って放っとくと古いコードを書く問題

あるよね？（ない？）

適当な例だけど「モーダル作って」って頼むと、 を重ねて  して、自前でフォーカストラップ書いて、Esc キーのハンドラを  で生やす的な、昔の Stack Overflow みたいなコードをしれっと書いてくるイメージ

でも今のブラウザには  要素がある。 一発でモーダルになるし、フォーカス管理も Esc も標準で効く（よね？）

AI がそれを使わないのは、学習データに古い書き方が圧倒的に多いから。新しい API のサンプルはまだ世の中に少ない

つまり AI は「動くけど古い」コードを書きがち。ここを矯正する辞書が要る、っていうのが今日の Chrome のスキルの出発点だね

Modern Web Guidance は何者なん？

Modern Web Guidance は、Google I/O 2026 で発表された公式の Agent Skill。今はまだ early preview（早期プレビュー）で、ユースケースは継続的に増えてってるらしい

Chrome チームに加えて Microsoft Edge チームと Web コミュニティが支援してるのかな

なんか、AI いわく「ベンダー横断でモダンな Web の作法を一個に束ねに来てる」のがポイントらしいよ（あーね）

chrome for developers ページはこっちです

https://developer.chrome.com/docs/modern-web-guidance?hl=ja

Modern Web Guidance の中身

AI に雑にまとめてもらった。こんな感じらしいよ

- 102 のモダン Web 機能を、128 のユースケースに整理した SKILL.md + CLI（多くは専門家が継続キャリブレーション済み。ただ全部じゃなくてカバレッジは作業中らしい）
-  一発で導入。 と  のサブコマンドあり
- 対応エージェントがとにかく広い。universal な skills 規格で 55 エージェント。Claude Code / Antigravity / Cursor / Codex / Gemini CLI / GitHub Copilot / Hermes Agent ほか
- 完全オフライン動作。TensorFlow.js（ブラウザ・Node で動く機械学習ライブラリ）のローカルモデルでクエリをマッチするので、ネットワークも API キーも要らない
- ライセンスは Apache 2.0、依存ゼロ

:::success
依存ゼロ + オフライン動作なのが地味にえぐい。社内ネットワークが厳しい現場でも、API キーの管理も外部通信の許可も要らずに入れられる。サプライチェーンの審査も通しやすい
:::

狙いはさっきの話そのままで、AI に古い workaround をやめさせて、 要素・Popover API・CSS Anchor Positioning・WebAuthn・CSP みたいなモダン API を使わせること。専門家が「今ならこう書く」を検証済みのユースケースとして渡す、っていう発想だね

スキルの種類も豊富

アプリケーション全体で効果的なアクセシビリティ パターンを評価、修正、実装するための中心的な監査ガイド



ページの読み込み時間のレイテンシを短縮し、ユーザー入力へのレスポンスを改善



レスポンシブなカスタム要素、スムーズなトランジション、最新のスタイリング パターンを迅速に実装



css



forms



Modern Web Guidance install

汎用の CLI で入れるなら npx 一発



Claude Code なら、この3コマンド



Antigravity CLI



インストール後、 の行を見ると、plugins・skills・agents・hooks までまとめて読み直してて、Claude Code のプラグイン体系にちゃんと組み込まれてた

Claude Code を検出して、非対話でインストールが進む



対応エージェントが「55 agents」と結構デカいよね

おお、Claude Code だけじゃなくて Antigravity / Cursor / Codex / Gemini CLI / GitHub Copilot / Hermes Agent とかに、universal な  規格で一気に入る感じかあ

install のときにセキュリティ評価（Gen / Socket / Snyk）まで出してくるのね

次に中身を引く。（アクセシブルなモーダル）でクエリを投げてみた



返ってきた。実際は JSON で返ってくるんやけど、読みやすいように整形。similarity（クエリとの類似度スコア）付きで、関連するガイドが順に並ぶ



完全オフラインで、ローカルのモデルだけで類似度を計算して返してくる。で、一番上の dialog 系を retrieve すると、AI に渡る作法の中身そのものが出てくる



返ってきたガイドがこれ（抜粋）。Invoker Commands API を使って、JS を一行も書かずに  をモーダルにする宣言的な書き方を推してた



さらにガイドには Baseline 状況（Invoker Commands は 2025-12 から Baseline）と、未対応ブラウザ向けの polyfill 戦略（feature detect して条件付き import しろ、まで MANDATORY 指定）まで入ってた

「とりあえず動く」じゃなくて「今のブラウザでこう書け、古い環境はこう逃がせ」まで面倒を見る粒度

しかも、その Baseline のターゲットはプロジェクト側で選べる。 や  に「このプロジェクトの Baseline は 2024」って書いとくと、その基準に合わせて fallback の出し方を変えてくれるらしい（何も指定しないとデフォルトで Widely available 扱い）

古い環境を切り捨てたくない案件でも、自分とこの対応ブラウザ基準に寄せられるわけやね

このガイドを読まずに「モーダル作って」と頼むと、AI はたいてい div を重ねて自前で組む（学習データに古い書き方が多いから）。ガイドを入れると、AI は上の宣言形を参照してから書くようになる。出力の寄り方はこう

| Before（スキルなし）              | After（スキルあり）                         |
| --------------------------------- | ------------------------------------------- |
| 「モーダル作って」→ div + 自前 JS | 「モーダル作って」→  ベースで提案 |
| 古い書き方を疑わない              | 検証済みユースケースを参照してから書く      |
| 出力がブレる                      | 専門家の作法に寄る                          |

これ体感だけの話かと思いきや、公式の eval（評価）でも裏が取れてて、Modern Web Guidance を入れたエージェントは「モダンな作法への準拠度」が平均で 37 ポイントくらい上がったって書いてあった

まあ early results（初期結果）らしいんで、モデルとかプロンプト、使うエージェント次第で変わる、っていう但し書き付きやけどね

要は AI が「最初に辞書を引いてから書く」状態になる。プロンプトで毎回「dialog 要素を使って」って指示しなくても、エージェントが勝手にモダン API 側に寄ってくれる。これがスキルとして食わせる意味だね

Clawd（クロード） 興奮！

Claude Code の Clawd（クロード。マスコットキャラクター） 君が嬉しそうに

「朝に組んでた eng-practices スキルと、Chrome の Modern Web Guidance を並べてみると、構造が完全に同じだった！」

って言うんだよね

- 専門家が決めた作法を、リポジトリ単位で references に置く
- SKILL.md で「いつ・どのファイルを読むか」の導線を引く
- AI に毎回 references を引かせてから書かせる

ワイの方法はイケてたってことなんよ！

自分が eng-practices でやったのは「全部を一度に読ませない。判断に迷ったら 1 ファイルだけ読め」っていう導線設計だった。Modern Web Guidance も発想は同じで、 で関連ユースケースだけ引いて、必要な分だけ AI に渡す

コンテキストを節約しながら、専門知識をピンポイントで効かせる。手ロールとプラットフォーム公式が、同じ結論に独立してたどり着いてた

:::discovery
ここで棲み分けが見えてくる。Web 標準みたいに「正解が世界共通で、ベンダーが束ねられる」領域は公式が標準化する。逆に eng-practices みたいに「組織やチームの判断基準」が混ざる領域は、手ロールで自分の文脈に合わせる価値が残る。公式が来た領域には乗る、来てない交差点は自分で埋める
:::

プラットフォーマーが AI コンテキスト辞書を標準化し始めた

ここからは自分の見立て。事実というよりは、今日の体験から見えてきた仮説

Modern Web Guidance を単体で見ると「便利なスキルが出たね」で終わる。でも最近の Chrome の動きと並べると、もっと大きな流れに見えてくる

- Modern Web Guidance ＝ AI に「どう書くか」の作法を渡す辞書
- WebMCP ＝ AI に「Web ページをどう操作するか」の口を渡す
- Chrome DevTools for agents ＝ AI に「動いてる挙動をどう観測するか」の目を渡す

この3つを並べると、書く・操作する・観測する、っていう AI 開発のコンテキスト層を Chrome が一個ずつ標準化しに来てるように見える

今までは各自が手ロールで埋めてた穴を、プラットフォーマーが公式の規格で塗り潰しに来てる、って感じだね

野良スキルが増えてるのを見かねて、こういうのを出してきたのかな？

:::warning
ここは断定じゃなく自分の解釈。「三点セットで標準化戦略だ」って公式が言ってるわけじゃない。ただ、同日に手ロールと公式がぶつかった体験からすると、こういう絵で見ると腑に落ちる、っていう話
:::

仮にこの見立てが当たってるなら、今後「AI に何を食わせるか」の標準辞書はどんどん公式から出てくるね

個人が手で organize する手間は減るし、品質も専門家検証済みで担保される。素直にありがたい流れだと思う

おわりに

今日の同日体験で腹落ちしたこと

- 公式が来た領域には乗る。Modern Web Guidance みたいに「Web 標準の作法」っていう世界共通の正解は、手ロールより公式版の方が品質も網羅性も上。 で今すぐ入る
- 標準化されてない交差点こそ個人の一次情報。eng-practices みたいに組織の判断基準が混ざる領域は、手ロールで自分の文脈に合わせる価値が残ってる
- プラットフォーマーは AI のコンテキスト層を標準化し始めてる（これは自分の見立て）。手で埋めてた穴が公式で塞がる流れは、たぶんこれから加速する

手ロールしてた発想を半日後に公式が標準化してきた、っていう体験が地味に効いた一日だったね

AI コーディングは「プロンプトをどう書くか」から「AI に何を食わせるか」に主戦場が移ってて、その辞書の供給元が個人からプラットフォーマーに移りつつある感じ
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code に質の高いPR書かせる Google Engineering Practices 食わせたスキル]]></title>
            <link>http://izanami.dev/post/e63c7bfd-cc85-4421-a4e7-776e93fb8720</link>
            <guid>http://izanami.dev/post/e63c7bfd-cc85-4421-a4e7-776e93fb8720</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 22 May 2026 21:12:08 GMT</pubDate>
            <description><![CDATA[Google が公開してるGoogle Engineering Practices Documentation。これは Google 社内のコードレビュー基準を一般公開したドキュメント群で、CL を書]]></description>
            <content:encoded><![CDATA[Google が公開してるGoogle Engineering Practices Documentation。これは Google 社内のコードレビュー基準を一般公開したドキュメント群で、CL を書く側と、レビューする側の両方の作法がまとまってる

[https://github.com/google/eng-practices](https://github.com/google/eng-practices)

CL（changelist）っていうのは Google 社内語で、要するに GitHub でいう PR のことだね

:::discovery
良いドキュメントを見つけたら「紹介する」より「AI の参照辞書に組み込む」方が資産になる。読むのは一回やけど、スキルにすれば毎回効く
:::

X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code 実践テクニックを配信しています

完成したスキルの中身を全部置いとく

スキルのディレクトリ構成。SKILL.md と、Google の原文を丸ごと同梱した references/ の2階建てや



distill は作らず、Google の原文をそっくりそのまま references/eng-practices-master/ に置いてるだけ。で、入口の SKILL.md がこれ。そのままコピペで動くよ

references/eng-practices-master/review/

指摘は「profile が optional なのに null チェックなしで displayName を辿ってる。profile が無いリクエストでランタイムクラッシュする。これも blocking」。エッジケースを通せ、の観点やな

3. 関心事の混在 = CL を分割すべき

3つ目はバグやなくて構成の問題。1つの diff に機能追加とリファクタリングが混ざってた。AI は「これは small-cls.md の観点で、リファクタと機能変更は別 PR に分けるべき。レビュアーが何を見ればいいか分からなくなる。blocking」と判断した

そして最後に、AI 自身がこう締めた。「blocking が3件残ってるので submit すべきでない」。レビュー基準を食わせた AI が、自分の書いたコードを見て自分で submit を止めた

:::discovery
nit と blocking を AI が自分で振り分けて「完璧は求めないが、これは直すまで出すな」と判断する。レビュー基準を渡すと、AI のセルフレビューが「指摘の羅列」から「出荷判断」に進化する
:::

横展開

ここで気づいたことがある。eng-practices のレビュー哲学って、よく見ると2層に分解できる

- 哲学（領域非依存）nit と blocking の規律 / 全体から読んで致命傷を先に見る / 完璧を求めない
- 観点（領域固有）空 catch・null・テストの有無みたいなコード特有のチェックリスト

哲学の方はコードに限った話やない。文章レビューにもそのまま効く。「全体の論旨を先に見て、致命的に崩れてたらそこで止める」「直すまで出すべきでない指摘と、任意の磨きを分ける」「完璧を求めず、全体の質を確実に上げる状態なら publish する」。これ、記事のセルフレビューでも全く同じことが言える

なので、同じ型からコード固有の観点だけを外して、文章レビュー用のスキル（writing-review）も作った。哲学の根拠になる原文は standard.md / navigate.md / comments.md / pushback.md の4枚だけ references/ に切り出して同梱した（コード特有の looking-for.md や small-cls.md は外した）

CL = 記事 or ポスト、code health = 記事全体の質、submit = publish、っていう読み替えを足せば、izanami 記事や X ポストを publish 前にレビューするスキルになる

:::success  
レビューは「哲学（領域非依存）」と「観点（領域固有）」に分解できる。哲学を残して観点を差し替えれば、コードレビューのスキルが文章レビューのスキルに転用できる。writing-review がその証拠だね  
:::

まとめ

今日やったことを整理するとこうなる

- Google の eng-practices をスキルに食わせた
- 最初は日本語に要約したが、原文からドリフトして失敗した
- 要約をやめて、リポジトリを丸ごと同梱し、必要な1ファイルだけ on-demand で読ませる設計に変えた
- 実 diff を流したら、AI が空 catch・null クラッシュ・CL 分割を blocking として自分で出し、submit を止めた
- 同じ型から観点を差し替えて、文章レビュー用スキルも作れた

一番言いたいのは、AI に渡すレビュー基準は自分で選んで丸ごと渡せる時代になった、ってこと。汎用の AI は「それっぽい」レビューはしてくれるけど、どの基準で見るかは曖昧やった。そこに Google の基準を原文のまま積めば、AI のレビューがその基準で揃う。要約して劣化させるより、信頼できる原文を選んで丸ごと食わせる方が強い

出典は [google/eng-practices](https://github.com/google/eng-practices)（CC BY 3.0）。良いレビュー基準を持ってる人は、それを AI の辞書にしてみると地味に効く
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code に日本向けサービスを作らせるなら、個情法の要件を .claude/rules/ に置く]]></title>
            <link>http://izanami.dev/post/b4ab1a36-b960-4c83-8ace-b4587eb298a5</link>
            <guid>http://izanami.dev/post/b4ab1a36-b960-4c83-8ace-b4587eb298a5</guid><dc:creator>commte</dc:creator>
            <pubDate>Thu, 21 May 2026 18:00:16 GMT</pubDate>
            <description><![CDATA[ユーザー情報を扱う API、利用規約、広告コピー、ログイン処理、決済、投稿の通報フローなど…

Claude は何も言わずに書き上げてくる。なんか、最近これが怖い

Claude Code ブームで一]]></description>
            <content:encoded><![CDATA[ユーザー情報を扱う API、利用規約、広告コピー、ログイン処理、決済、投稿の通報フローなど…

Claude は何も言わずに書き上げてくる。なんか、最近これが怖い

Claude Code ブームで一番怖いのが、簡単に作って事故ることかなあと

先に断っとくと、これから書く  の運用は法務レビューの代わりにはならない。まぁ、考え方みたいなもんね

論点の見落としを減らそうぜ、ってレベルの話だから、最終的な判断は法務担当や個人情報取扱責任者に通すのが前提ね（個別具体的な法律判断は弁護士にご相談ください）

ちなみに、URL の中身を確実に参照させたいなら、「取りに行け」という明示的な指示をルールに書いておく必要がある



X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です

何が変わるか

 に法律のファイルを揃える

狙いはこのあたり

- LP のコピーを書かせるとき、景表法の優良誤認・有利誤認に触れる論点が出てきやすくする
- 利用規約のたたき台を作るとき、特商法に基づく表記の項目をリストで提案してくる場面を増やす
- 投稿機能を作るとき、情報流通プラットフォーム対処法（旧プロバイダ責任制限法）を踏まえた発信者情報開示や違法情報の取扱いに触れる頻度を上げる
- ログイン処理を書くとき、認証情報の漏えい対策（試行回数制限・ロックアウト）を提案してくる確率を上げる

つまり Claude が「日本の法律の論点に気付いたコード」を書きやすくなる、ってのが期待値ですね

セキュリティ対策だけじゃなくてリーガル対策も必要よね、という話

プロンプトの組み方やモデルバージョン次第で精度はぶれるけど、論点の見落としは減るかも

Claude Code は日本の法律を知らない前提で動かす

モデルの一般知識だけに依存すると、日本法の現行条文・最新改正・所管ガイドラインを踏まえない出力が混じる

最近の Claude Code のモデルは、そんな傾向が多そうなんよね

GDPR や CCPA まわりは比較的厚いけど、日本の個別法は薄い体感

推測だけど、生成 AI 特有の落とし穴として、個人情報保護委員会が2023年6月2日に出した「[生成 AI サービスの利用に関する注意喚起等について](https://www.ppc.go.jp/news/carefulinformation/230602AIutilizealert/)」を Claude は知らないまま書いてそう

だから自分で文脈を流し込む必要があると思った

.claude/rules/ に法律ごとに置く運用

 配下に法律ごとのファイルを置く

イメージはこんな感じ

- frontmatter の  で関連ファイルを絞ってコンテキスト消費を抑える
- 本文は薄く。観点リスト + 一次情報リンクだけ

個情法用のファイル例



動かしてみると、app/ 配下のファイルを Read した瞬間に appi.md が発火して、WebFetch で個情委のガイドラインページを取りに行く動作が確認できる

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/f6c3b13d-f4e5-42e1-96b5-b9130f5c4c3d.png)

Claude Code で検証

リンク先を読んでくれないので、ドキュメントを md ファイルにして直接置くか、
リンクの中身を読みにいかせる工夫が必要

そのあたりは、よしなにやってちょうだいね

あと、frontmatter のキーは  を使う（Cursor の  とは別物）。値は YAML 配列で書く

 を指定したルールは、Claude が一致するファイルを読むときだけ条件付きで読み込まれる。指定なしのルールは起動時に常時読み込まれるから、コンテキスト消費の調整にも使える

フィールド名が違うと黙ってスコープが効かないから、書いたあとは  で実際にコンテキストに載ってるか確認しといた方がいいね

ポイントは本文の薄さ。詳細な解釈は個情委ガイドラインや e-Gov の条文に任せて、ルールファイルは「論点に気付くためのチェックリスト」に振り切る

:::discovery
.claude/rules/ は AI コンテキスト辞書として運用する。本文を分厚く書くとコンテキスト消費が膨らむから、観点リストと一次情報リンクに絞るのがコツ
:::

まとめ

ここまで書いてきたけど、ポイントは1個

Claude Code は日本の法律を知らない前提で動くから、自分で文脈を流し込む

具体的には  にリーガルファイルを置く。各ファイルは薄く、観点リスト + 一次情報リンクだけ。条文や解釈は外部に任せて、ルールファイルは「論点に気付くためのチェックリスト」に振り切る

これだけで Claude が日本の法律の論点を意識したコードを書きやすくなる。あくまでガードレールであって、最終的な判断は法務や DPO に通すのが前提

それでも「論点を見落とした状態でリリースする」リスクは大幅に減る

地味だが、日本向けサービスを Claude Code で作るなら、この法律バンドル運用は早めに揃えとくと一気に楽になるはず
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code を大規模コードベースで使うベストプラクティス]]></title>
            <link>http://izanami.dev/post/af045ef8-eff9-4317-b05a-abce17e14f55</link>
            <guid>http://izanami.dev/post/af045ef8-eff9-4317-b05a-abce17e14f55</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 16 May 2026 12:21:36 GMT</pubDate>
            <description><![CDATA[Claude Code を大規模コードベースで使うベストプラクティス

Claude Code の精度は、使うモデルよりハーネス（CLAUDE .md などの設定）の整備で決まる。RAG みたいなイン]]></description>
            <content:encoded><![CDATA[Claude Code を大規模コードベースで使うベストプラクティス

Claude Code の精度は、使うモデルよりハーネス（CLAUDE .md などの設定）の整備で決まる。RAG みたいなインデックスを持たず grep でその場で探すから、設定の質がそのまま探索の精度になる

大規模なコードベースほど、事前のセットアップが効いてくる

Claude Code、大規模コードベースでの公式ベストプラクティスが出てた

- CLAUDE .md はルートを薄く、ローカルな規約はサブディレクトリに書く
- 作業はリポジトリルートやなくサブディレクトリで始める
- ハーネスは基本 CLAUDE .md → hooks → skills → plugins → MCP の順で積む
- stop hook でセッションの学びを CLAUDE .md に反映させる
- CLAUDE .md は3〜6ヶ月ごとに棚卸しする

今回は、こちらの公式の記事を分かりやすく紐解く

https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

X で毎日 Claude Code 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code テクニックを配信しています

Claude Code はインデックスを作らない

RAG 型のツールは、コードベース全体を埋め込み（ベクトル）に変換してインデックスを作り、質問のたびに関連しそうな断片を引っぱってくる。これが大規模やと厳しい。何千人ものエンジニアが毎日コミットするから、埋め込みパイプラインが更新に追いつかない

インデックスを引いた時点で、それは数時間前、下手したら数週間前のコードベースを指してる。2週間前に名前を変えた関数や、先週消したモジュールが、古いという表示もなく平気で返ってくる

Claude Code はそこを避けてる。インデックスを作らず、人間のエンジニアと同じようにファイルツリーをたどって、grep で必要なところを探して、参照を追っていく。開発者のマシン上でそのまま動くから、サーバーにインデックスを構築・維持・アップロードする必要もない。常にライブのコードベースを見てるってことや

ただ、これには裏返しがある。Claude が「どこを見ればいいか」の手がかりを持ってないと効かない。何の文脈もないまま「この曖昧なパターンを全部探して」と頼むと、作業を始める前にコンテキストの上限に達してしまう。だから次に出てくる CLAUDE .md やハーネスの整備が効いてくる

性能はモデルよりハーネスで決まる

ハーネスは、モデルの周りに組む文脈・ツール・自動化の仕組み一式のこと。車でいうと、モデルがエンジンで、ハーネスが車体や配線にあたる

Claude Code でいちばん誤解されてるのが、性能はモデルで決まるという思い込みや。みんなモデルのベンチマークや、お試しタスクでの出来を気にする。けど実際に効くのは、モデルの周りに組み上げた仕組み、つまりハーネスのほうやと公式は言い切ってる

土台になる拡張ポイントは5つで、CLAUDE .md、hooks、skills、plugins、MCP サーバー。それぞれ役割が違う

1. CLAUDE .md → 文脈
2. hooks → 自動化
3. skills → 専門知識
4. plugins → 配布
5. MCP → 外部ツールへの接続

積む順は基本この通り

前の層の上に次が乗るから、順番が効いてくる。土台ができてないのに MCP だけ先に生やしても、ぐらついたまま機能が増えるだけや。さらに LSP 連携とサブエージェントが加わって、ハーネス全体ができあがる

個人開発者は何をすればいいんや

エンタープライズは分かった。ほんじゃ、個人開発者は何をすればいいんやって話やけど、まず安心してほしい。専任チームや DRI、エージェントマネージャーみたいな組織の仕組みは、個人開発には要らない。そこは丸ごと飛ばしていい

やることはもっとシンプル

- CLAUDE .md を薄く保つ。1人でも、肥大した CLAUDE .md は毎セッションのコンテキストを食う。ルートは要点とハマりどころだけにする
- 小さなプロジェクトでも、関係するサブディレクトリで Claude を起動する癖をつける
- stop hook を1つ入れて、CLAUDE .md を育てる。自己改善する設定はチームがなくても回せるし、むしろ1人のほうが回しやすい
- 新しいモデルが出たら CLAUDE .md を棚卸しする。1人やと古いルールがたまりやすい
- skills や plugins、MCP は、土台（CLAUDE .md と hooks）が固まってから足す

気をつけるのはここ。最初から MCP やプラグインみたいな派手な機能に手を出さないこと。土台がないまま機能だけ増やすと、かえって不安定になる。まずは CLAUDE .md を薄く整える、そこからで十分

CLAUDE .md は薄く、階層的に

CLAUDE .md は、Claude が毎セッションの最初に自動で読む文脈ファイル。ここがポイントで、タスクに関係あるかどうかに関わらず毎回読まれる。だから何でもかんでも書き込むと、そのぶん毎セッションのコンテキストを食って、性能を落とす方向に働く

ルートの CLAUDE .md は、全体像と「これを踏むと事故る」っていうハマりどころだけに絞る。それ以外は基本ノイズになる。細かいローカルな規約は、その規約が効くサブディレクトリの CLAUDE .md に書く

Claude はディレクトリを下りながら、見つけた CLAUDE .md を順に追加で読んでいく。だからルートを薄くしても、深い階層の文脈はちゃんと積み上がる。薄く、階層的に、が基本やな

起動はルートやなくサブディレクトリ

作業を始めるとき、リポジトリのルートやなく、タスクに関係するサブディレクトリで Claude を起動したほうが精度が出る。モノレポやと、ツールがルート前提で動くことが多いから直感に反するけど、効くのはこっち

Claude は起動した場所から親をたどって、道中の CLAUDE .md を全部拾う。だからサブディレクトリで起動しても、ルートの文脈が失われることはない

ついでに、テストやリントのコマンドもサブディレクトリ単位で CLAUDE .md に書いておくといい。1つのサービスをいじっただけで全スイートを回すと、タイムアウトするし、関係ない出力でコンテキストを無駄に食う

hooks の本当の使いどころは自己改善

hooks は、Claude が変なことをするのを止めるスクリプト、と思われがちや。けど真価はそこやない。もっと価値があるのは、セットアップを自己改善させる使い方のほう

たとえば stop hook。セッションが終わるタイミングで、その回に何が起きたかを振り返らせて、CLAUDE .md の更新案を出させる。文脈がまだ新しいうちにやるから精度が高い。これを回すと、設定が勝手に育っていく

start hook なら、セッション開始時にチーム固有の文脈を動的に読み込ませられる。各開発者が、自分のモジュールに合ったセットアップを手動設定なしで受け取れる。あとリントやフォーマットみたいな決まりきったチェックは、hooks で機械的に効かせたほうが、Claude に「覚えといてね」と頼むより結果が安定する

古い CLAUDE .md は足かせになる

モデルは進化する。今のモデル向けに書いた指示が、次のモデルでは逆に足を引っ張ることがある

わかりやすいのが「リファクタは1ファイルずつに分けて」みたいなルール。昔のモデルが脱線しないように書いたんやろうけど、今のモデルはファイルをまたいだ協調的な編集を普通にこなす。古いルールが残ってると、その能力を止めてしまう

skills や hooks も同じや。モデルの弱点や Claude Code のツールの穴を埋めるために作ったものは、その穴が塞がった瞬間にただのオーバーヘッドになる。実際、Perforce のコードベースでファイル書き込みに p4 edit を強制してた hook は、Claude Code が Perforce にネイティブ対応した時点で不要になった

だいたい3〜6ヶ月ごとに設定の棚卸しをするといい。大きなモデルが出たあと、性能が頭打ちに感じたタイミングでやるのも効く

設定をまとめる人を1人決める

技術的なセットアップだけでは、組織への普及は進まない。うまくいってる組織は、組織側の仕組みにも投資してる

いちばん速く広がったのは、広くアクセスを開ける前に、専任の少人数チーム（ときに1人）が先にツールを整えたケースや。開発者が初めて触った時点で、もう自分のワークフローに馴染んでる状態を作る。最初の体験が「使えない」やなくて「生産的」になるから、そこから自然に広がっていく

最近は「エージェントマネージャー」という、PM とエンジニアを兼ねたような役割を置く組織も出てきてる。専任チームが無理でも、最低限ほしいのは DRI を1人決めること。設定、権限ポリシー、プラグインのマーケットプレイス、CLAUDE .md の規約に責任を持って、最新に保つ人

ボトムアップの盛り上がりは熱量を生むけど、まとめ役がいないと断片化する。良い設定が属人化したまま、普及が頭打ちになる

おわりに

ここまでが、公式のベストプラクティス記事から読み取れた要点や。元記事はエンタープライズ規模を念頭に書かれてるけど、CLAUDE .md の書き方、起動位置、ハーネスの積み方あたりは、個人開発や小さなチームでもそのまま効く

まずは CLAUDE .md をルートとサブディレクトリに分けて薄く整えるところから始めるのがいいと思う]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code で、広告バナー200本を15分で作るえぐい手順（やってみた）]]></title>
            <link>http://izanami.dev/post/33bc0c0f-4210-4f5e-90e5-4ee8efe9ac66</link>
            <guid>http://izanami.dev/post/33bc0c0f-4210-4f5e-90e5-4ee8efe9ac66</guid><dc:creator>commte</dc:creator>
            <pubDate>Sun, 22 Feb 2026 11:47:48 GMT</pubDate>
            <description><![CDATA[前回のポストで紹介した Anthropic マーケチームの手法、「で、実際どうやるの？」って人いそうだから、実際にやってみた

X で毎日 AI 情報を配信してる[コムテ](https://x.com]]></description>
            <content:encoded><![CDATA[前回のポストで紹介した Anthropic マーケチームの手法、「で、実際どうやるの？」って人いそうだから、実際にやってみた

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code テクニックを中心に情報を配信しています

[前回のXポスト](https://x.com/commte/status/2024771301538435201)

Claude Code のサブエージェントで広告コピーを量産して、自作の Figma プラグインでバナーを 20 パターン一気に生成するまでの全手順を書く

結論から言うと、サブエージェント作成からバナー 20 枚生成まで、15 分かからなかった

相当簡単だから、みんなもやってみ？

この記事バージョンアップするから、後で試したい人は、ブクマしておくんやで

ステップ 1 - サブエージェントで広告コピーを CSV 出力

まず  にサブエージェントを 2 つ作った

1 つ目は headline-writer.md（見出し専用）。30 文字以内で広告の見出しだけを生成するエージェント

2 つ目は description-writer.md（説明文専用）。90 文字以内で説明文だけを生成するエージェント

なんで分けるかって言うと、1 つのプロンプトに「見出しも説明文も両方作って」と頼むと、文字数制限を守れなかったり品質が下がったりするんよね。Anthropic のチームも同じ理由で分けてた

サブエージェントの作り方はシンプルで、Markdown ファイルに YAML フロントマターで name、description、tools を書いて、本文にシステムプロンプトを書くだけ

こんな感じ



説明文用も同じ要領で作る。ポイントは出力形式を CSV に指定すること。後で Figma プラグインに食わせるから

そんで Claude Code に以下を指示



2 つのサブエージェントが並列で動いて、数分で見出し 20 本 + 説明文 20 本の CSV が出来上がった

見出しの例

- 「個人開発プロダクトを無料で公開しよう」
- 「あなたの技術、埋もれていませんか？」
- 「SEO最適化済みで検索に強い技術ブログ」

全部 30 文字以内。訴求ポイントもトーン（疑問形、断定形、呼びかけ形）もバラバラに散らしてくれた

ステップ 2 - Figma プラグインを Claude Code で自作

ここが一番「え、そんなことできるの？」ってなるところやね

作り方は簡単よ

Claude Code に以下を指示した



Claude Code が作ってくれたのは 3 つのファイル

1. manifest.json - プラグインの設定ファイル
2. ui.html - CSV をアップロードする画面
3. code.js - テンプレ複製＋テキスト差し替えのロジック

仕組みはこう。Figma の Plugin API を使って、テンプレートフレーム内のテキストノードをフォントサイズで判定する。一番大きいのが見出し、次が説明文。CSV の行数だけテンプレを複製して、テキストを差し替えてグリッド配置する

エンジニアじゃなくても Claude Code がコード全部書いてくれるから、「何を作りたいか」が言語化できれば作れる。自分はコードを 1 行も書いてない

ステップ 3 - テンプレート作成 → バナー量産

まずバナーのテンプレートを 1 つ作った。今回は HTML で作って Claude Code to Figma 機能で送った

Claude Code to Figma は、CC に Figama MCP をインストールするだけ

テンプレートの構成

- 背景（グラデーション）
- ロゴ（izanami）
- 見出しテキスト
- 説明文テキスト
- CTA ボタン（「無料で始める」）
- URL（izanami.dev）

このテンプレが Figma に入ったら、プラグインを起動する

Figma デスクトップアプリで「プラグイン → 開発 → マニフェストからプラグインをインポート」で manifest.json を選択。これでプラグインが読み込まれる

プラグインを起動して、headlines.csv と descriptions.csv をアップロードして「バナーを生成」をクリック

一瞬で 20 パターンのバナーが Figma 上に並んだ

見出しと説明文がそれぞれ違うバリエーションで、テンプレの見た目はそのまま。手作業でコピペしてたら 1 時間以上かかる作業が、ボタン一発で終わった

全体の流れまとめ

1.  にサブエージェント 2 つ作成（2 分）
2. Claude Code で CSV 出力を指示（3 分）
3. Claude Code で Figma プラグインを自作（5 分）
4. テンプレート作成 → Figma に送る（3 分）
5. プラグインで 20 パターン一括生成（1 分）

合計 15 分以内。コードは 1 行も手書きしてない

ポイント

- サブエージェントは  に Markdown を置くだけで作れる
- タスクごとに専門のエージェントを分けるのが品質を上げるコツ
- Figma プラグインの自作はハードル高そうに見えるけど、Claude Code が全部書いてくれる
- CSV の出力形式を最初に決めておくと、プラグインとの連携がスムーズ
- いきなりコードを書かない。まず全体のワークフローを設計してから Claude Code に渡す

感想

もはや、この方法使えば広告関係で困ることはないと思ったね

広告運用じゃなくても、LP のコピー、SNS 投稿画像、メールのバリエーションテストなど、同じ構造で応用できるよな

サブエージェント使って、プラグイン作れって話やね

自分のサービスの広告をこの手法で作ったけど、正直もう手動には戻れないよ

[サブエージェントの公式ドキュメント](https://code.claude.com/docs/en/sub-agents)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Anthropic 社内のマーケティングチームが Claude Code をガチ運用してた話]]></title>
            <link>http://izanami.dev/post/b56cafbc-4d8d-477a-8629-b5ef70282f2b</link>
            <guid>http://izanami.dev/post/b56cafbc-4d8d-477a-8629-b5ef70282f2b</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 21 Feb 2026 09:02:47 GMT</pubDate>
            <description><![CDATA[Anthropic が公式ブログで、社内チームが Claude Code をどう使っているかの事例を公開した。中でもグロースマーケティングチームの使い方がえぐい。しかも全部、真似できる

X で毎日 ]]></description>
            <content:encoded><![CDATA[Anthropic が公式ブログで、社内チームが Claude Code をどう使っているかの事例を公開した。中でもグロースマーケティングチームの使い方がえぐい。しかも全部、真似できる

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code テクニックを中心に情報を配信しています

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/6021b7a8-10da-4c6e-9da3-39c245ed9401.png)

再現してみた。Figma プラグインとサブエージェントを作る

2026/02/22。具体的な方法はこちらに書きました！↓

https://izanami.dev/post/33bc0c0f-4210-4f5e-90e5-4ee8efe9ac66

このチームは検索広告、SNS 広告、アプリストア、メールマーケティング、SEO を担当していて、驚くのは「非技術者 1 人のチーム」ということ。エンジニアがいない。Claude Code だけで、普通ならエンジニアリングリソースが必要な仕事を回してる

公式ブログ（英語）
https://claude.com/blog/how-anthropic-teams-use-claude-code

[Xでの資料](https://x.com/robjama/status/2023151595295268939)を参考にした

何をやっているのか、4 つのユースケースを紹介する

ちなみにこの事例が面白いのは、「AI を使ってマーケティングを効率化した」という話じゃなくて、「Claude Code で自分専用の自動化ツールを作った」という話であること。ここが重要

1. Google Ads のクリエイティブ自動生成

数百件の既存広告データ（CSV）をまるごと Claude Code に読ませて、成果が悪い広告を自動で特定する。そこから新しい広告コピーを生成するんだけど、ここが面白い

見出し用（30 文字制限）と説明文用（90 文字制限）で、別々のサブエージェントを用意してる。1 つのプロンプトに全部やらせるんじゃなくて、タスクごとに専門のエージェントを分けてる

これで複数キャンペーン分の広告を数分で生成。手作業だと何時間もかかるやつが、一瞬で終わる

ポイントは「サブエージェントに分ける」という設計判断。1 つのプロンプトで見出しも説明文も全部生成させると品質が下がる。それぞれに専門のエージェントを割り当てることで、文字数制限を守りながら品質を担保してる

2. Figma プラグインで広告を大量生産

SNS 広告の静止画って、基本的に同じデザインの見出しと説明文を差し替えて量産する作業なんよね。これを手動でやると、コピペ地獄になる

そこで Claude Code を使って Figma プラグインを自作した。フレームを自動認識して、見出しと説明文を差し替えることで、最大 100 パターンの広告バリエーションを一気に生成する

数時間のコピペ作業が 1 バッチ 0.5 秒に。クリエイティブの生産量は 10 倍になったらしい

3. Meta Ads の MCP サーバーでキャンペーン分析

Meta Ads API と連携する MCP サーバーを構築して、Claude Desktop アプリ内から直接キャンペーンの成果を確認できるようにした

何がいいかというと、広告管理画面にログインしてタブを切り替えて数字を確認して、みたいな作業が全部なくなる。Claude Desktop を開くだけで、キャンペーンのパフォーマンス、支出、広告効果がまとめて見れる

地味だけど、毎日やる作業の効率化は ROI に直結する

MCP（Model Context Protocol）はまさにこういう使い方のために設計されてる。外部ツールの API を Claude に繋いで、自然言語で操作できるようにする仕組み。広告運用以外でも、Slack、GitHub、データベースなど応用範囲は広い

4. メモリシステムで自己改善する広告テスト

これが一番賢い。広告の A/B テストって、何を試して何が効いたのかを人間が管理し続けるのは限界がある

このチームは Claude Code で簡易メモリシステムを作って、過去の仮説と実験結果を記録するようにした。新しい広告バリエーションを生成するたびに過去のテスト結果を参照して、精度を上げていく仕組み

テストするたびに賢くなるフレームワーク。手動では絶対に追いつけない

なぜこの事例が参考になるのか

よくある「AI で業務効率化しました」系の事例って、大企業のエンジニアチームが何ヶ月もかけて作りましたみたいな話が多い。再現性がない

でもこのチームは非技術者 1 人。Claude Code を使って、自分で Figma プラグインも MCP サーバーも作ってる。つまりコードを書く能力じゃなくて「何を自動化すべきか」を見極める能力が重要だということ

広告運用じゃなくても、同じ発想は使える。営業の提案書作成、カスタマーサポートの定型対応、データの集計レポート。API があって繰り返してる作業なら、全部候補になる

結果

- 広告コピーの作成時間が 2 時間 → 15 分に短縮
- クリエイティブの生産量は 10 倍
- 1 人で、大きなチームと同じ仕事量をこなせるようになった
- 手作業の実行ではなく、戦略設計に時間を使えるようになった

チームが語る 3 つのコツ

1. API があるツールの繰り返し作業を狙う

広告プラットフォーム、デザインツール、分析基盤。API を持ってるツールでの反復作業は、Claude Code による自動化の最有力候補。まずはここから探す

2. タスクごとにサブエージェントを分ける

1 つのプロンプトに全部やらせない。見出しエージェントと説明文エージェントを分けたように、タスクごとに専門のエージェントを作る。デバッグが楽になるし、出力の品質も上がる

3. いきなり Claude Code でコードを書かない

まず Claude .ai でワークフロー全体を設計する。何をどういう順番でやるか、プロンプトの構成はどうするか。全体像を固めてから Claude Code に渡す。一発で完成させようとしないのがコツ

まとめ

エンジニアじゃなくても、Claude Code でここまでできる。「エンジニアリングリソースがない」はもう言い訳にならない時代になってきてる

特に参考になるのは、Figma プラグインや MCP サーバーを「自分で作る」という発想。既存のツールを使うだけじゃなくて、自分の業務に合った自動化ツールを Claude Code で作るという選択肢がある

API がある繰り返し作業を見つけて、サブエージェントで分割して、Claude .ai で設計してから Claude Code に渡す。このフローは広告運用に限らず、どんな業務にも応用できる

自分の業務で「これ毎回同じことやってるな」と思う作業があったら、それが Claude Code で自動化できる最初の候補。エンジニアかどうかは関係ない
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code to Figma を実際に試してみた]]></title>
            <link>http://izanami.dev/post/d2cb475d-38bd-42b1-8ce1-7f381cef543e</link>
            <guid>http://izanami.dev/post/d2cb475d-38bd-42b1-8ce1-7f381cef543e</guid><dc:creator>commte</dc:creator>
            <pubDate>Wed, 18 Feb 2026 20:08:31 GMT</pubDate>
            <description><![CDATA[Figma と Anthropic が公式連携機能「Claude Code to Figma」をリリースした。Claude Code で作った UI をそのまま Figma に編集可能なフレームとして]]></description>
            <content:encoded><![CDATA[Figma と Anthropic が公式連携機能「Claude Code to Figma」をリリースした。Claude Code で作った UI をそのまま Figma に編集可能なフレームとして取り込めるらしい。

本当にできるのか、実際に手を動かして検証してみた

Claude Code to Figma って？

Claude Code で作った UI を、ブラウザからキャプチャして Figma に送信する機能。送られたデータはスクリーンショットではなく、Figma 上で編集可能なデザインフレームとして取り込まれるって感じ

ボタンのサイズ、色、角丸、フォントなどを Figma 上で個別に変更できる状態で届く

localhost でも本番環境でもステージングでもキャプチャ可能で、複数画面の一括キャプチャにも対応してるんよな

Figma Make との連携もできる

[@Emukei](https://x.com/Emukei/status/2024073906110242909)さんに教えてもらったんだけど、Figma Design に取り込んだフレームを右クリックすると「Figma Make に送信する」というメニューが出る

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/19d98477-35af-479c-86b5-90b5713c8d1a.png)

右クリックすると…

Figma Make はプロンプトでデザインを生成・編集できるツール。つまり Claude Code で作った UI を Figma Make でさらにブラッシュアップできる

逆に Make で作ったデザインも、右上のアイコンからコピーして Design に貼り付けられる

セットアップ

Figma MCP サーバーを Claude Code に接続する。リモート MCP サーバーを使えば Figma デスクトップアプリは不要

ターミナルで以下を実行する。でも今、これ不要かも

普通に接続できるっぽいね



これだけで接続完了。Claude Code 内で  コマンドを実行して認証を済ませる

必要な条件はこの3つ

- Claude Code がインストール済み
- Figma アカウント（Dev または Full シート）
- MCP サーバー対応の環境

実際にやってみた

まず Claude Code で簡単な HTML を作った。カード型の UI でボタンが1つあるシンプルな構成



ポイントは head にキャプチャスクリプトを1行追加すること。このスクリプトがブラウザの画面を読み取って、Figma に送信してくれる

次にローカルサーバーで配信。まぁ、適当に



ブラウザでキャプチャ用のパラメータ付き URL を開くと、画面上部にキャプチャツールバーが表示される。「Figma に送信」「画面全体」「要素を選択」などのオプションが並んでいる

キャプチャが完了すると、Figma にファイルが生成される

結果

Figma でファイルを開いてみると、ちゃんと編集可能なフレームになってた

ボタンを選択すると W 320 × H 48 のサイズ情報が表示され、塗りにはグラデーション（6366f1 → 8b5cf6）、角丸は 8px と、元の CSS の値がそのまま反映されている

スクリーンショットを貼り付けたのとは全く違う。レイヤー構造も維持されていて、Container の中に Text、Heading、Paragraph、Button がそれぞれ独立したフレームとして入ってるね

逆方向もいける

Figma に送ったデザインから、逆にコードを生成することもできた

Figma MCP サーバー経由でデザインデータを取得すると、レイヤー構造、色、サイズ、フォント、影などの情報が返ってくる。React + Tailwind CSS のコードとして出力される

つまり、こういう往復ができるんよね

HTML → Figma（Claude Code to Figma）→ React コード（Figma MCP）

デザイナーとエンジニアの間で「Figma のデザインをコードに起こす」「コードの画面をデザインに戻す」が双方向でできるようになった

うまくいかないときは

今回の検証で、キャプチャスクリプトを入れ忘れると送信が pending のまま止まることが分かった

head に以下の1行を追加すれば解決



まぁ、よしなにやってくれってことや

まとめ

検証した結果、Claude Code to Figma は確かに動く。シンプルな UI であれば、コードからデザインへの変換は問題なくできた

手順をまとめると以下の通り

1. Figma MCP サーバーを接続（コマンド1行）
2. Claude Code で UI を作る
3. HTML の head にキャプチャスクリプトを追加
4. ローカルサーバーで配信してブラウザで開く
5. 自動で Figma に送信される

複雑な UI やマルチページのフローについてはまだ試していない。今後検証してみる予定

フロントエンドや個人開発者にとっては嬉しい機能で、Claude Code でプロトタイプを作ってそのまま Figma で仕上げるワークフローが現実的になった
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code のセッション引き継ぎを自動化する]]></title>
            <link>http://izanami.dev/post/3b2789ca-30ee-403f-af43-83e2c7009fb1</link>
            <guid>http://izanami.dev/post/3b2789ca-30ee-403f-af43-83e2c7009fb1</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 16 Feb 2026 14:16:22 GMT</pubDate>
            <description><![CDATA[Claude Code の /handover っていうカスタムスラッシュコマンド、やってみた

セッション終わりに打つだけで、引き継ぎノートを自動生成してくれる

[Zara Zhang (@zar]]></description>
            <content:encoded><![CDATA[Claude Code の /handover っていうカスタムスラッシュコマンド、やってみた

セッション終わりに打つだけで、引き継ぎノートを自動生成してくれる

[Zara Zhang (@zarazhangrui)](https://x.com/zarazhangrui/status/2020992712825241801) さんのポストで知って、自分でも作って試した

何が解決されるのか

最初に断っておくと、これはデフォルトで用意されてるものではない

カスタムスラッシュコマンドなので、後述する方法で作る必要がある

Claude Code はセッションが切れると文脈がリセットされる。CLAUDE .md にプロジェクトのルールは書けるけど、今日どこまでやったか、なぜその設計にしたかは残らないよね

次のセッションで、さっき何やってたっけ？ってなるのを、解決できるかも

/handover の仕組み

.claude/commands/handover .md にカスタムスラッシュコマンドを置く。セッション終了時に /handover と打つだけで、HANDOVER .md がプロジェクトルートに生成される

コマンドの全文。意外と簡単



HANDOVER.md はプロジェクトルートに置くだけだと Claude Code が自動で読むわけじゃない。次のセッションで「HANDOVER.md を読んで」と言うか、CLAUDE.md に一行入れておく必要がある。

例えば、セッション開始時に HANDOVER.md が存在すれば、最初に読み込むこと

この一行を CLAUDE.md に追記する運用。ここが抜けてると「作ったけど次のセッションで読まれない」ってなる人が出そう

CLAUDE .md との違い

ここが一番大事なポイント

- CLAUDE .md → プロジェクト全体のルール（不変）
- HANDOVER .md → 今日の作業の引き継ぎ（毎回更新）

この2つを分けるだけで、セッション跨ぎの精度が変わる。CLAUDE .md に作業ログを書き足していくと膨れ上がるし、ノイズになる。役割を分けるのが正解

そもそも、CLAUDE .md は100行以内に収めたい

試してみた結果

実際にセッション中に何回か /handover を打ってみた

- 毎回ちゃんと上書きされて、最新の状態だけが残る
- 「捨てた選択肢と理由」が地味に一番ありがたい。次のセッションで「それもう検討して却下した」って無駄な議論を防げる
- 「関連ファイル」も便利。セッションが変わると「どのファイル触ってたっけ」ってなりがちだけど、パス一覧があるだけで再開が速い

PreCompact hook で自動化する

ここからが応用編。リプで出てた「pre auto compact hook に仕込む」ってアイデアを実際に試した

Claude Code にはコンテキストウィンドウが溢れそうになったとき、自動で圧縮する仕組みがある。その直前に hook を発火させて HANDOVER .md を生成する

設定は .claude/settings.local.json に書く



スクリプトの例。よしなに作って試してください



/compact を手動で打ったら hook が発火して HANDOVER .md が自動生成された。トリガーが manual か auto かも記録される

注意点として、hook はセッション開始時に読み込まれるので、設定を変えたらセッションを再起動する必要がある

ファイル構成まとめ


]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Codeで、テックリードを作る]]></title>
            <link>http://izanami.dev/post/93c510f4-8669-46c6-a6e8-253171fcbe7d</link>
            <guid>http://izanami.dev/post/93c510f4-8669-46c6-a6e8-253171fcbe7d</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 13 Feb 2026 14:14:06 GMT</pubDate>
            <description><![CDATA[Claude Code は使うたびにリセットされる。昨日直したバグも、先週の設計判断も、全部忘れる

人間のテックリードなら、プロジェクトの歴史を知っていて、過去の失敗を踏まえた判断ができる。タスクの]]></description>
            <content:encoded><![CDATA[Claude Code は使うたびにリセットされる。昨日直したバグも、先週の設計判断も、全部忘れる

人間のテックリードなら、プロジェクトの歴史を知っていて、過去の失敗を踏まえた判断ができる。タスクの優先順位を把握していて、チームの編成まで考えてくれる

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code の特殊な使い方 / AI 駆動開発 などを中心に情報を配信しています

Claude Code にも同じことをさせる方法がある。CLAUDE .md に7行書くだけ

仕組み

ファイルを記憶装置として使う

-  - Claude Code が最初に読む設定ファイル。ここに「何を読め」と書く
-  - タスク管理。何が終わっていて、何が残っているか
-  - 過去の失敗と学び。同じバグを二度踏まないためのログ

Claude Code はセッション開始時に CLAUDE .md を自動で読む。そこに「まず todo .md と lessons .md を読め」と書いておけば、毎回プロジェクトの現状を把握してから作業に入る

人間のテックリードが朝会でタスクボードを確認するのと同じ流れ

セットアップ

CLAUDE .md に追記する

tasks/todo.mdtasks/lessons.md[x]

こうしておけば、作業範囲が被らない

2つ目はトークン消費。チームメイトはそれぞれ独立したコンテキストウィンドウを持つ。3人編成にすると単純に3倍近くトークンを使う。速いけど高い。小さいタスクなら1人で十分。チーム編成は「並列でやる意味がある量」のときだけ使うのが現実的

テックリードに必要な3つの能力

テックリードの仕事を分解すると、3つに集約される

1. プロジェクトの歴史を知っていること → todo .md
2. 同じ失敗を繰り返さないこと → lessons .md
3. 適切にタスクを分配すること → チーム編成

この3つをファイルベースで実装するのがこの設定の本質。Claude Code を「毎回ゼロから始まる便利ツール」から「プロジェクトの文脈を持ったテックリード」に変える

使うほど lessons .md が育つ。それがプロジェクト固有の知識ベースになる。人間が抜けても残る、チームの記憶
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Checklist Driven Development（CCDD）]]></title>
            <link>http://izanami.dev/post/1dad3ac1-85a2-4656-94e9-5944023db546</link>
            <guid>http://izanami.dev/post/1dad3ac1-85a2-4656-94e9-5944023db546</guid><dc:creator>commte</dc:creator>
            <pubDate>Tue, 10 Feb 2026 17:37:59 GMT</pubDate>
            <description><![CDATA[Claude Code に  チェック入れさせる方法を使うと、ファイルを記憶装置として使うと開発効率上がる。こんなやつね



タイトルの Claude Checklist Driven Develo]]></description>
            <content:encoded><![CDATA[Claude Code に  チェック入れさせる方法を使うと、ファイルを記憶装置として使うと開発効率上がる。こんなやつね



タイトルの Claude Checklist Driven Development（CCDD）っていうのは、ワイが勝手に作った言葉

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code / AI 駆動開発 / Claude Code などを中心に情報を配信しています

ファイルを外部メモリにする

この記事は [Tech with Mak 氏の X 投稿](https://x.com/techNmak/status/2018712721538081170)にインスピレーションを受け、[Anthropic 公式ドキュメント](https://code.claude.com/docs)と複数の研究論文を引っ張り出して検証したもの

具体的には以下の 3 つのファイルを軸にする

-  - Claude Code の行動指針と記憶のインデックス
-  - 今やるべきことの計画と進捗管理
-  - 過去の失敗と学びの蓄積

この仕組みの強さは、セッションが切れても記憶が消えないこと。次のセッションで Claude Code が  を読み込んだ瞬間、前回の続きからスムーズに作業を再開できる。まるで優秀な同僚が引き継ぎノートを完璧に残してくれてるような感覚

思いついてた人もいるだろうけど、案外やってる人少なそう

:::info
NeurIPS 2023 で採択された「Reflexion」([2303.11366](https://arxiv.org/abs/2303.11366)) という論文がまさにこのアプローチの理論的裏付けになる。Reflexion は重み更新ではなく言語的フィードバックで強化学習を行うフレームワークで、エージェントがタスクのフィードバックを言語で振り返り、エピソディックメモリバッファに反省テキストを保持して次の試行での意思決定を改善する。やろうとしてるのは、まさにこの Reflexion のアプローチを Claude Code に適用すること
:::

Claude Code には [Auto Memory](https://code.claude.com/docs/en/memory) というビルトインのメモリシステムもあるが、それは後述する

CLAUDE.md

まずはじめに、CLAUDE.md にこれを書く

/tasks/todo.md/tasks/lessons.md

これだけ。Claude Code はセッション開始時に CLAUDE.md を自動で読み込むから、この指示によって必ず  と  を最初に確認するようになる。結果として、前回のセッションの続きからシームレスに作業できる

tasks ディレクトリを作る

コマンドでサクッと



ディレクトリ



tasks/todo.md による計画駆動開発

多くの開発者が Claude Code を使うとき、いきなりコードを書かせ始める。やけどそれだと Claude Code が途中で迷子になりやすい。特に複雑なタスクでは、全体の見通しがないまま部分的な実装を進めてしまい、あとで整合性が取れなくなることがある

 のワークフローはこの問題を根本から解決する



tasks/lessons.md で同じ失敗を繰り返さない

開発で一番もったいないのは、同じバグを何度も踏むこと。人間の開発者なら「あ、これ前にも見たやつや」と気づけるけど、セッションが切れるたびにリセットされる Claude Code にはその記憶がない

 がこの問題を解決する

npx prisma generateany.env.example

このファイルのポイントは、具体的な行動レベルまで落とし込むこと。「型に気をつける」みたいな曖昧な教訓やなくて、「Prisma のスキーマを変更したら必ず  を実行する」のように、Claude Code がそのまま実行できるルールにする

arxiv の「A Survey of Self-Evolving Agents」([2507.21046](https://arxiv.org/abs/2507.21046)) が整理した Plan-Execute-Reflect-Memorize ループそのもの。エージェントが計画し、実行し、結果を振り返り、学びをメモリに保存する。このサイクルを回し続けることで、エージェントはオンジョブで進化していく

Claude Code のビルトイン Auto Memory も活用する

ここまで  と  による手動メモリ管理を見てきたけど、Claude Code には [Auto Memory](https://code.claude.com/docs/en/memory) というビルトインのメモリシステムもある

公式によると、Auto Memory は CLAUDE.md とは根本的に違う。CLAUDE.md は「人間が Claude に向けて書く指示」やけど、Auto Memory は「Claude 自身がセッション中に見つけたパターンや知見を自分で書き留めるメモ帳」。保存先はユーザーのホームディレクトリ配下で、プロジェクトパスのハッシュごとに分かれてる



同じ Git リポジトリ内ならサブディレクトリが違っても 1 つの Auto Memory を共有する。Claude Code 2.1.32 で導入された機能で、セッション中に「Recalled 1 memory, wrote 1 memory」のように自動で読み書きしてくれる

ここで注意したいのは  の 200 行ルール。自動でシステムプロンプトに読み込まれるのは最初の 200 行だけ。やけどこれは Auto Memory 全体の容量制限やない。200 行を超える詳細な内容は  や  みたいなトピックファイルに分けて書いておけば、Claude が必要なときにオンデマンドで読みに行ってくれる。 はあくまでインデックスとして簡潔に保つのがコツ

Auto Memory が自動で記憶してくれる内容はこんな感じ

- プロジェクトパターン（ビルドコマンド、テスト規約、コードスタイル）
- デバッグ知見（トリッキーな問題の解決策、よくあるエラー原因）
- アーキテクチャメモ（重要ファイル、モジュール関係、抽象化）
- ユーザー設定（コミュニケーションスタイル、ワークフロー習慣）

自分から「pnpm を使うことを覚えておいて」「API テストにはローカルの Redis が必要なことをメモリに保存して」と直接指示もできるし、 コマンドでファイルセレクタを開いて直接編集もできる

:::info
Auto Memory はまだ段階的ロールアウト中。まだ見当たらない場合は  を環境変数にセットすれば強制的に有効にできる
:::

わざわざ  ディレクトリに書く理由

じゃあ Auto Memory があるのに、なんでわざわざ  ディレクトリで手動管理するのか

「プロジェクト内に作れるなら共有できるやん？」と思うかもしれないが、ここが紛らわしいポイント。Auto Memory の保存先は  なので、プロジェクトディレクトリ内やなくてユーザーのホームディレクトリ配下。つまり Git の管理外で、チームメンバーとは共有できない構造になってる

一方で  と  はプロジェクトルート直下に置くから、普通に Git で追跡できる。チーム全員の Claude Code が同じ教訓を共有できるし、新メンバーが  した瞬間にプロジェクトの知見が手に入る

もう一つの違いは、Auto Memory は Claude が「自分で判断して」書くもの。何を記憶するかの制御が人間側にない。一方で  ディレクトリは人間が意図的に構造化できる。「この教訓は絶対に忘れるな」「このタスクの順番で進めろ」みたいな強い指示は、手動メモリのほうが確実に伝わる

:::discovery
Auto Memory と手動メモリは排他的やなくて相互補完的。Auto Memory には Claude が自然に拾うプロジェクトの暗黙知を任せて、 ディレクトリには人間が明示的にコントロールしたい計画と教訓を入れる。この使い分けがベストプラクティス
:::

まとめ

Claude Code の生産性を劇的に上げるのに、特別なツールや複雑な設定は要らない。必要なのは 3 つのファイルと、それを中心にしたシンプルなワークフロー

-  で記憶のハブを作る
-  で計画を立ててから実装する
-  で失敗を記録して同じミスを繰り返さない

後は、このあたりも組み合わせるといいね

- Plan Mode で見通しを立ててから着手する
- サブエージェントでコンテキストを守る

ファイルを外部メモリとして使うというシンプルな仕組みが、Claude Code を経験から学び続けるパートナーに変える。セッションが切れても記憶は残るし、チームで共有もできる。そして使えば使うほど、lessons.md が育って、Claude Code の精度が上がっていく
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code の Agent teams を使うべき理由]]></title>
            <link>http://izanami.dev/post/8628a13f-8cff-47d0-a4fa-be8f2a4551c3</link>
            <guid>http://izanami.dev/post/8628a13f-8cff-47d0-a4fa-be8f2a4551c3</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 07 Feb 2026 13:55:42 GMT</pubDate>
            <description><![CDATA[Claude Code の Agent teams を試して分かった決定的な違い

複数の Claude が同時に独立して考えて、しかもお互いに直接メッセージをやりとりできる

これが Claude ]]></description>
            <content:encoded><![CDATA[Claude Code の Agent teams を試して分かった決定的な違い

複数の Claude が同時に独立して考えて、しかもお互いに直接メッセージをやりとりできる

これが Claude Code の Agent teams なんやけど、2026 年 2 月上旬に実験的機能として公開され、Opus 4.6 の話題と同時期に注目を集めた機能で、使ってみたらサブエージェントとは全然別物やった

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/b6fce387-b87c-4a68-a2d6-5512ee6392fb.png)

レビューを依頼すると…

バグ調査で複数の仮説を同時に検証させたり、セキュリティ・パフォーマンス・テストの 3 軸で並列レビューさせたり、できることのレベルが一段上がる

コンテキストが汚染されないから、巨大な PR や長期調査でも文脈がぐちゃぐちゃになりにくいし、各チームメイトが独立した視点で考えるから仮説の競合が自然に起きるんよね

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発 / Claude Code などを中心に情報を配信しています

参考リンク

この記事は [Anthropic 公式ドキュメントの Agent teams ガイド](https://code.claude.com/docs/en/agent-teams)と、[Lydia Hallie 氏の投稿](https://x.com/lydiahallie/status/2019469032844587505)（いいね 3,567 件、表示 80.4 万回）にインスピレーションを受けて、実際に試した結果をまとめたもの。[Addy Osmani 氏のブログ記事](https://addyosmani.com/blog/claude-code-agent-teams/)や [Anthropic の公式リリース記事](https://www.anthropic.com/news/claude-opus-4-6)も参照してる

Agent teams とは何か - なぜサブエージェントと違うのか

Agent teams は複数の Claude Code インスタンスが協調して動く仕組みなんやけど、既存のサブエージェントとは根本的に違う

[サブエージェント](https://code.claude.com/docs/en/sub-agents)は「調べて返す部下」やけど、Agent teams は「議論できるチーム」なんよね

具体的には、1 つのセッションがリード（team lead）として全体を統括して、残りのセッションがチームメイト（teammates）として独立して動く

各チームメイトは独自のコンテキストウィンドウを持つから、リードのコンテキストが汚染されることがない

そして決定的なのが、チームメイト同士が直接メッセージをやりとりできる点

サブエージェントはメインエージェントにしか結果を返せなかったけど、Agent teams ではチームメイトが互いに議論したり、意見を戦わせたりできる

これによって、複数の視点から同時に問題にアプローチできるようになった

サブエージェントと Agent teams の比較 - 使い分けの基準

両者の違いを明確にするために、[公式ドキュメントの比較表](https://code.claude.com/docs/en/agent-teamscompare-with-subagents)をベースに整理した

Subagents の特徴

| 項目               | 内容                                             |
| ------------------ | ------------------------------------------------ |
| コンテキスト       | 独自のコンテキストを持つが結果は呼び出し元に返る |
| コミュニケーション | メインエージェントにのみ結果を返す               |
| 作業調整           | メインエージェントが全作業を管理                 |
| 向いてる用途       | 結果だけ必要な集中タスク                         |
| トークンコスト     | 低い（結果がメインコンテキストに要約される）     |

Agent teams の特徴

| 項目               | 内容                                                 |
| ------------------ | ---------------------------------------------------- |
| コンテキスト       | 完全に独立したコンテキストウィンドウ                 |
| コミュニケーション | チームメイト同士が直接メッセージ可能                 |
| 作業調整           | 共有タスクリストで自己調整                           |
| 向いてる用途       | 議論と協調が必要な複雑な作業                         |
| トークンコスト     | 高い（各チームメイトが独立した Claude インスタンス） |

要するに、単純に並列処理したいだけならサブエージェントで十分

でも複数の視点から同時に考えさせて、その結果を議論させたいなら Agent teams を使うべき

例えばバグ調査で「メモリリークの可能性」「非同期処理のタイミング問題」「外部 API の仕様変更」という 3 つの仮説を同時に検証させて、チームメイト同士で議論させながら絞り込むような使い方ができる

アーキテクチャ - 4 つのコンポーネントで動く仕組み

Agent teams は 4 つのコンポーネントで構成されてる

| コンポーネント | 役割                                                           |
| -------------- | -------------------------------------------------------------- |
| Team lead      | メインセッション。チーム作成・チームメイト生成・作業調整を担当 |
| Teammates      | 独立した Claude Code インスタンス。割り当てられたタスクを実行  |
| Task list      | 共有タスクリスト。チームメイトがクレームして完了する           |
| Mailbox        | エージェント間通信システム。メッセージの配信を担当             |

実際のファイルとしては以下の場所に保存される

チーム設定は  に、タスクリストは  に配置される

この仕組みのおかげで、リードは全体の進捗を把握しつつ、各チームメイトは独立して作業できる

タスクリストは  →  →  の 3 段階で管理されて、チームメイトが自分でタスクをクレームして進めていく

タスク間には依存関係も設定できて、依存先が完了するまでブロックされる仕組みになってる。依存タスクが完了すると自動でアンブロックされるから、手動介入は不要

複数のチームメイトが同時にタスクをクレームしようとしても、ファイルロックで競合が防がれるようになってる

リードがいちいち指示しなくても、チームメイトが自律的に動くようになってるのがポイント

有効化方法 - 設定ファイル 1 行で使える

Agent teams は実験的機能やから、環境変数で有効化する必要がある

 に以下を追加するだけ



これだけで準備完了

あとは自然言語で「3 人のチームを作って」と指示すれば、自動的にチームが組まれる

ちなみに自分からチーム作成を頼まなくても、Claude が「このタスクはチームでやった方がいい」と判断したら提案してくれることもある。ただし勝手には作らず、必ず承認を求めてくるから安心

モデルも指定できて、例えば「Sonnet を使ってチームを作って」と言えば、全チームメイトが Sonnet になる

コスト削減したいときは明示的に Haiku を指定するのもあり

表示モードの選択 - tmux か iTerm2 があると捗る

Agent teams には 2 つの表示モードがある

in-process モード はメインターミナル内で全チームメイトが動く形式

 と  でチームメイトを巡回して、直接メッセージを送れる

split panes モード は各チームメイトが独自のペインを持つ形式

tmux か iTerm2 が必要やけど、全員の進捗が同時に見えるから視認性が段違い

公式は iTerm2 を使う場合  で起動するのを推奨してる。 CLI のインストールと、iTerm2 の Settings → General → Magic → Enable Python API の有効化も必要

設定は  で指定できる



CLI フラグで指定することも可能



デフォルトは  で、tmux セッション内なら split panes、そうでなければ in-process になる

:::warning
VS Code の統合ターミナル、Windows Terminal、Ghostty では split panes モードが動かない。これらの環境では in-process モードを使うか、外部ターミナルで tmux を起動する必要がある
:::

チームの作り方と操作方法 - 自然言語でほぼ完結

チームの作成は自然言語で指示するだけ

例えばこんな感じ



これだけで 3 人のチームメイトが生成されて、それぞれの視点でレビューが始まる

チームメイトの数やモデルも自由に指定できる

plan approval を有効にすると、チームメイトに計画承認を要求できる

これによって、勝手に実装が走るのを防げる。チームメイトは read-only の plan mode で作業して、計画ができたらリードに承認リクエストを送る

リードが承認すれば実装フェーズに進むし、却下すればフィードバック付きで差し戻される。リードの判断基準は「テストカバレッジを含む計画のみ承認して」とか「DB スキーマを変更する計画は却下して」みたいにプロンプトで指定できる

特にリスクの高い操作をする場合は、plan approval を使うのが安全

delegate mode は  で有効にできて、リードがコードを一切触らずに指揮だけに専念するモード

大規模な並列作業では、リードが実装に手を出さず全体を見渡す方がうまくいく

直接メッセージ は in-process モードなら  と  でチームメイトを選んで送信できる

 でチームメイトのセッションを直接表示して、 でそのターンに割り込みできる。 でタスクリストの表示/非表示を切り替えられる

split panes モードなら、チームメイトのペインをクリックするだけで直接操作できる

特定のチームメイトに追加指示を出したいときに使う

タスク管理 は共有タスクリストで行われる

リードがタスクを作成して、チームメイトが  状態のタスクをクレームして  にして、完了したら  にマークする

タスクのサイズは 5〜6 個 / チームメイトが目安

小さすぎるとオーバーヘッドが大きくなって、大きすぎるとチェックインなしに長時間作業することになる

シャットダウンとクリーンアップ はリードから指示する

:::warning
クリーンアップの順序はめっちゃ大事。先に全チームメイトをシャットダウンしてから「Clean up the team」を実行する。アクティブなチームメイトが残ってるとクリーンアップが失敗する。チームメイト側からクリーンアップを実行するのも NG で、コンテキストが正しく解決されずリソースが不整合な状態になる可能性がある
:::

シャットダウンはリードから「Ask the researcher teammate to shut down」のように指示する。チームメイトは承認してグレースフルに終了するか、理由を付けて拒否することもできる

シャットダウンが遅い場合があるけど、これはチームメイトが現在のリクエストやツール呼び出しを完了させてから終了するため

Hooks で品質ゲートを設ける - タスク完了前に自動レビュー

Agent teams では 2 つの [Hooks](https://code.claude.com/docs/en/hooks) が使える

TeammateIdle Hook はチームメイトがアイドルになりそうなときに発火する

exit code 2 を返すと、フィードバックを送信して作業を続行させられる

例えば「まだテストが足りない」「ドキュメントを書いてない」といったフィードバックを自動で返せる

TaskCompleted Hook はタスク完了時に発火する

exit code 2 を返すと、完了を阻止してフィードバックを送れる

例えば「テストカバレッジが 80% 未満だから完了させない」みたいなゲートを設けられる

Hooks を使うことで、チームメイトが勝手に終了するのを防いで、品質基準を満たすまで作業を続けさせることができる

設定例はこんな感じ



こうすることで、人間がチェックしなくても自動で品質を担保できる

実践ユースケース 1 - 並列コードレビューで抜け漏れを防ぐ

最も実用的なのが並列コードレビュー

1 人でレビューすると、セキュリティのことを考えてるときにパフォーマンスのことが見えなくなったり、テストカバレッジのことを考えてるときにアクセシビリティのことが抜けたりする

Agent teams を使えば、3 人のチームメイトにそれぞれ専門分野を担当させられる



実際に試したら、セキュリティ担当が「この API エンドポイントに認証チェックがない」と指摘して、パフォーマンス担当が「この SQL クエリが N+1 になってる」と指摘して、テスト担当が「この条件分岐のテストがない」と指摘した

3 つの視点が同時に動くから、抜け漏れが物理的に減る

しかもチームメイト同士が直接メッセージできるから、「この認証チェックを追加するとパフォーマンスに影響ある？」みたいな議論が自然に発生する

これはサブエージェントでは絶対にできなかった

実践ユースケース 2 - 競合仮説による科学的バグ調査

バグ調査で威力を発揮するのが、競合仮説アプローチ

例えば「アプリが 1 メッセージ後に終了する」という報告があったとき、考えられる仮説は複数ある



5 人のチームメイトがそれぞれ異なる仮説を検証して、お互いに議論しながら絞り込んでいく

「メモリリークの可能性」を検証する人、「非同期処理のタイミング問題」を検証する人、「外部 API の仕様変更」を検証する人、「WebSocket の切断」を検証する人、「例外処理の不備」を検証する人

チームメイト同士が「この仮説は再現しなかった」「この仮説は部分的に正しい」と議論して、最終的にコンセンサスが形成される

これは人間のチームが科学的にバグを追い詰めるプロセスと同じなんよね

1 人で全仮説を順番に検証するより、5 人が並列で検証して議論する方が圧倒的に早い

実践ユースケース 3 - CLI ツール設計を多角的に検討

設計段階でも Agent teams は有効

例えば新しい CLI ツールを設計するとき、UX・技術アーキテクチャ・悪魔の代弁者の 3 つの視点から検討させられる



UX 担当は「開発者が普段使ってるワークフローに溶け込むか」を考えて、技術アーキテクチャ担当は「スケールするか」「保守できるか」を考えて、悪魔の代弁者は「本当に必要か」「既存ツールで十分じゃないか」を問い詰める

3 つの視点が同時に動くことで、設計の穴が早期に見つかる

しかもチームメイト同士が議論するから、UX と技術のトレードオフとか、既存ツールとの差別化ポイントとかが自然に浮き彫りになる

[公式ドキュメントのベストプラクティス](https://code.claude.com/docs/en/agent-teamsstart-with-research-and-review)でも「まずはリサーチとレビューから始めろ」と推奨されてて、コードを書かないタスクで慣れるのが良い

ベストプラクティス - チームを効果的に動かすコツ

実際に使ってみて分かったベストプラクティスをまとめる

チームメイトに十分なコンテキストを与える のが最重要

spawn プロンプトに詳細を含めないと、チームメイトが何をすべきか分からなくて迷走する

「セキュリティ担当」だけじゃなくて「セキュリティ担当。特に認証・認可周りと SQL インジェクション・XSS のリスクをチェック」みたいに具体的に指示する

タスクサイズを適切に保つ のも大事

5〜6 タスク / チームメイトが目安で、これより小さいとオーバーヘッドが大きくなって、これより大きいとチェックインなしに長時間作業することになる

リードが勝手に実装し始めないように するのもポイント

リードは指揮に専念すべきで、実装はチームメイトに任せる

もしリードが実装し始めたら「Wait for your teammates」と指示すれば止まる

delegate mode（）を使えば、リードが自動的に指揮専念モードになる

まずはリサーチとレビューから始める のが公式推奨

いきなり並列実装をやるとファイル競合が発生しやすいし、調整コストが高い

並列レビュー、バグ調査、ライブラリ調査、設計検討あたりで慣れてから、並列実装に移行するのが安全

ファイル競合を避ける ために、各チームメイトが異なるファイルを担当するように分ける

同じファイルを複数人で触ると、後から保存した方が勝つから、片方の作業が消える

フロント担当・バック担当・テスト担当みたいに、ファイル単位で分けるのが確実

定期的に進捗確認・軌道修正 するのも忘れずに

完全放置はダメで、たまにチームメイトの進捗を見て「そっちじゃなくてこっちを優先して」みたいな指示を出す

split panes モードなら全員の進捗が同時に見えるから、これがやりやすい

トラブルシューティング - よくある問題と解決法

実際に使ってて遭遇した問題と解決法を並べる

チームメイトが表示されない ときは、 で巡回して探す

split panes モードなら  でセッション一覧を確認する

パーミッション確認が多すぎる ときは、[permission settings](https://code.claude.com/docs/en/permissions) で事前承認しておく

特に  を使うと、全チームメイトもスキップするようになる

ただしセキュリティリスクが上がるから、信頼できるタスクのみで使う

エラーで停止した チームメイトは自動復旧しないから、直接指示するか、新しいチームメイトに置き換える

 でエラーが出たチームメイトを選んで「このエラーを解決して」と指示すれば再開する

リードが早期終了する 問題もある

全タスク完了前に「終わった」と判断して終了することがあるんよね

その場合は「続けて」「まだタスクが残ってる」と指示すれば再開する

孤立 tmux セッション が残ることがある

 で確認して、不要なセッションは  で削除する

タスクステータスが遅延する ことがあって、チームメイトが完了したのにタスクリストが更新されないことがある

その場合はリードから「タスクリストを更新して」と指示すれば同期される

 や  で in-process チームメイトが復元されない のは既知の制限

セッションを再開すると、チームメイトが消えてる

split panes モードでも完全復元は保証されないが、in-process より状況把握はしやすい

長期作業の場合は定期的にチェックポイントを作っておく

制限事項 - 知っておくべき現時点の限界

Agent teams は実験的機能やから、[いくつか制限がある](https://code.claude.com/docs/en/agent-teamslimitations)

1 セッション 1 チームのみ で、複数のチームを同時に動かすことはできない

ネストチーム不可 で、チームメイトがさらにチームを作ることはできない

リードは固定 で、途中でリードを変更することはできない

パーミッションはスポーン時に設定 されて、リードの権限設定を引き継ぐ

スポーン後に個別変更は可能やけど、デフォルトではリードと同じ権限になる

スプリットペインは tmux or iTerm2 必須 で、VS Code の統合ターミナル、Windows Terminal、Ghostty では split panes モードが使えない

 と  で in-process チームメイトが復元されない から、セッション再開時は注意が必要

タスクステータスが遅延する ことがあって、リアルタイムで同期されないことがある

シャットダウンが遅い 場合があって、数秒から場合によっては 10 秒以上かかることがある

これらの制限を理解した上で使えば、十分実用的に動く

トークンコストとパーミッション - 運用で気をつける点

トークンコストはチームメイト数に比例して跳ね上がる

各チームメイトが独立した Claude インスタンスやから、3 人チームなら単純計算で 3 倍のトークンを消費する

ただし実際には、リードのコンテキストが汚染されないから、長期的には効率が良くなることもある

特に巨大な PR や長期調査では、コンテキストがぐちゃぐちゃになって何度もリセットするより、最初からチームで分担した方がトータルコストが低くなる

broadcast は全チームメイトにメッセージを送るから、コストが高い

特定のチームメイトにだけ伝えたいなら message を使う

パーミッションはリードの設定を引き継ぐから、リードで  を使うと、全チームメイトもスキップするようになる

セキュリティリスクが上がるから、信頼できるタスクのみで使う

スポーン後に個別のチームメイトだけパーミッションを変更することも可能やけど、基本的にはリードで事前に設定しておく方が安全

コンテキストと通信 - 各チームメイトが見えるもの

各チームメイトは独自のコンテキストウィンドウを持つ

[CLAUDE.md](https://code.claude.com/docs/en/memory)、[MCP サーバー](https://code.claude.com/docs/en/mcp)、[Skills](https://code.claude.com/docs/en/skills) はロードされるから、リードと同じ設定が使える

ただしリードの会話履歴は引き継がれない

だからチームメイトに十分なコンテキストを与えるには、spawn プロンプトに詳細を含める必要がある

メッセージは自動配信されて、チームメイトが何かを報告したらリードに届く

アイドル通知もあって、チームメイトが何もすることがなくなったらリードに通知が来る

message は 1 対 1 のメッセージで、特定のチームメイトにだけ送られる

broadcast は全チームメイトに送られるから、全員に共有したい情報を伝えるときに使う

ただし broadcast はコストが高いから、必要なときだけ使う

海外での実践事例 - 実際にどう使われてるか

海外の開発者コミュニティでも Agent teams は早速活用されてる

[Addy Osmani 氏のブログ](https://addyosmani.com/blog/claude-code-agent-teams/)によると、6 人の Claude チームで大規模なコードベースをレビューさせた結果、数時間で 13 件の即時修正可能な問題と 22 件の中長期課題を発見したとのこと

さらに極端な事例として、[Anthropic のエンジニアリングブログ](https://www.anthropic.com/engineering/building-c-compiler)では 16 エージェントが約 2,000 セッション、API コスト約 $20,000 をかけて Rust ベースの C コンパイラを一から構築し、10 万行のコードで Linux 6.9 をビルドできるレベルまで到達した事例が紹介されてる

これらの事例から分かるのは、Agent teams はレビューや調査のような「読み中心」のタスクでは即座に実用的やし、実装タスクでもファイル分担さえしっかりすれば大規模プロジェクトにも対応できるということ

ただし、トークンコストは確実に跳ね上がるから、費用対効果を見極めた上で使うのが大事

まとめ - Agent teams を使うべきタイミング

Agent teams は複数の視点から同時にアプローチしたいときに使う

並列コードレビュー、競合仮説によるバグ調査、多角的な設計検討あたりが特に相性良い

サブエージェントは結果だけ返してくれればいいタスク向けで、Agent teams は議論と協調が必要なタスク向け

トークンコストは高いけど、コンテキスト汚染を防げるから、長期的には効率が良くなることも多い

制限はあるけど、並列で探索する価値があるタスクには既に実用レベル

まずはリサーチとレビューから始めて、慣れてきたら並列実装にも使っていくのが良い

リードが指揮に専念して、チームメイトが自律的に動く形を作れれば、開発速度が段違いに上がる
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code スキル自作勢へ！Agent Skills Marketplace に6万超スキル集結]]></title>
            <link>http://izanami.dev/post/93b709b5-06ae-48a0-8489-9f1970c20756</link>
            <guid>http://izanami.dev/post/93b709b5-06ae-48a0-8489-9f1970c20756</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 16 Jan 2026 15:19:07 GMT</pubDate>
            <description><![CDATA[Claude Code のスキル、自作する前にここをチェックしてほしい

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI]]></description>
            <content:encoded><![CDATA[Claude Code のスキル、自作する前にここをチェックしてほしい

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発 / Claude Code などを中心に情報を配信しています

この記事は [Agent Skills Marketplace](https://skillsmp.com) を実際に触ってみた感想と、なぜこれが Claude Code ユーザーにとって革命的なのかを解説する

なぜ今 Skills Marketplace が注目されてるのか

車輪の再発明をやめられるから

Claude Code を使い始めると、まず直面するのが「スキルってどう作ればいいの？」という壁よね

あ、スキルっていうのは、「こういう仕事をするときは、こう考えて、こう進める」という知識と手順をフォルダ単位で定義する感じやね

公式ドキュメント読んで、SKILL.md の書き方覚えて、試行錯誤しながら自分用のスキルを作っていく。これ自体は楽しいんやけど、実は先人たちがすでに大量のスキルを作って公開してくれてるんよ

[Agent Skills Marketplace](https://skillsmp.com) というサービスがあって、ここに 65,635 個以上のスキルが集約されてる。全部 GitHub のオープンソースで、SKILL.md 標準に準拠してるから、見つけたらすぐに使える

見てみると、我々が自分で作ったスキルよりいいものが揃ってる

それじゃあ、使わせてもらったほうがいいよね？

サードパーティってどうなん？って人もいるけど、

[Anthropic 公式ブログ](https://www.claude.com/blog/building-skills-for-claude-code)でも紹介されてて、LangChain の deepagent-CLI にも統合されてるレベルのサービスなんよね

スキル数の爆発的増加

サイトのトレンドグラフを見ると、2024 年 12 月末から急増してるのがわかる。1 ヶ月で倍以上に増えてて、これはマジでエコシステムが加速してる証拠

なぜこんなに増えてるかというと、Skills の仕組み自体がシンプルやからなんよね。Markdown ファイル 1 つ書くだけでスキルになる

MCP みたいにサーバー立てたりコード書いたりする必要がない。だから参入障壁がめっちゃ低い

カテゴリ別の内訳を見ていこう

Skills Marketplace では 10 個のメインカテゴリに分かれてて、それぞれにサブカテゴリがある。全部見ていくとボリュームあるけど、どこに何があるか把握しておくと探しやすくなるから解説していく

Tools カテゴリ（22,506 スキル）

一番多いのが Tools カテゴリ。開発者が日常的に使うツール系のスキルが集まってる

| サブカテゴリ               | スキル数 |
| -------------------------- | -------- |
| Productivity & Integration | 13,241   |
| Automation Tools           | 6,532    |
| Debugging                  | 4,338    |
| System Administration      | 2,613    |
| IDE Plugins                | 2,277    |
| CLI Tools                  | 552      |
| Domain & DNS Tools         | 136      |

Productivity & Integration が圧倒的に多い。これは Notion、Slack、Google Workspace などの連携スキルがここに入ってるから。自動化系も 6,000 以上あって、定型作業を Claude に任せたい人には宝の山やね

Debugging スキルが 4,338 もあるのは意外やった。エラーメッセージの解析とか、ログの読み方とか、そういう知識がスキルとして共有されてるんよね

Development カテゴリ（19,370 スキル）

開発関連のスキルがここに集約されてる

| サブカテゴリ           | スキル数 |
| ---------------------- | -------- |
| CMS & Platforms        | 7,181    |
| Architecture Patterns  | 5,136    |
| Full Stack             | 3,596    |
| Frontend               | 3,233    |
| Scripting              | 1,974    |
| Game Development       | 1,947    |
| Mobile                 | 1,578    |
| Backend                | 1,303    |
| Package & Distribution | 710      |
| E-commerce Development | 693      |
| Framework Internals    | 579      |

CMS & Platforms が 7,000 超えてるのは、WordPress、Shopify、Strapi などの各 CMS に特化したスキルがあるから。Architecture Patterns も 5,000 以上あって、設計パターンの知識をスキルとして取り込めるのは便利

Frontend と Backend が分かれてるのもいい。React、Vue、Next.js などのフレームワーク別にスキルがあるから、自分のスタックに合わせて選べる

Data & AI カテゴリ（12,997 スキル）

AI 関連のスキルがここ。Claude Code 使ってる人なら特に気になるカテゴリよね

| サブカテゴリ     | スキル数 |
| ---------------- | -------- |
| LLM & AI         | 10,293   |
| Data Analysis    | 1,752    |
| Data Engineering | 1,491    |
| Machine Learning | 1,122    |

LLM & AI が 10,000 超えしてるのはすごい。プロンプトエンジニアリングのベストプラクティスとか、各 LLM の特性を活かした使い方とか、そういう知識がスキルとして共有されてる

Data Analysis と Data Engineering も合わせて 3,000 以上あるから、データ処理のワークフローを強化したい人にはかなり使える

Business カテゴリ（11,543 スキル）

ビジネス系のスキルも結構充実してる

| サブカテゴリ         | スキル数 |
| -------------------- | -------- |
| Project Management   | 7,339    |
| Sales & Marketing    | 4,929    |
| Finance & Investment | 2,564    |
| Health & Fitness     | 2,018    |
| Business Apps        | 557      |
| Real Estate & Legal  | 504      |
| Payment              | 119      |
| E-commerce           | 85       |

Project Management が 7,000 以上あるのは、タスク管理やプロジェクト進行のベストプラクティスがスキルとして共有されてるから。Sales & Marketing も 5,000 近くあって、マーケティング施策のアイデア出しとかに使えそう

Health & Fitness が 2,000 あるのは意外やった。ビジネスカテゴリに入ってるのは、ウェルネス系のビジネス向けってことかな

DevOps カテゴリ（10,839 スキル）

インフラ・運用系のスキルがここ

| サブカテゴリ  | スキル数 |
| ------------- | -------- |
| CI/CD         | 6,015    |
| Git Workflows | 4,781    |
| Cloud         | 1,773    |
| Containers    | 1,186    |
| Monitoring    | 814      |

CI/CD が 6,000 以上あるのはありがたい。GitHub Actions、GitLab CI、CircleCI などの各サービス別にスキルがあるから、自分の環境に合わせて選べる

Git Workflows も 4,781 あって、ブランチ戦略とかコミットメッセージの書き方とか、チーム開発のベストプラクティスがスキルとして取り込める

Testing & Security カテゴリ（7,984 スキル）

テストとセキュリティ関連

| サブカテゴリ | スキル数 |
| ------------ | -------- |
| Testing      | 3,427    |
| Code Quality | 3,097    |
| Security     | 1,727    |

Testing と Code Quality で 6,500 以上。単体テストの書き方とか、コードレビューのポイントとか、品質を上げるための知識がスキルとして共有されてる

Security が 1,727 あるのもいい。OWASP Top 10 とか、セキュアコーディングのベストプラクティスとか、セキュリティの知識は常に最新化が必要やから、コミュニティで共有されてるのはありがたい

Documentation カテゴリ（5,672 スキル）

ドキュメント作成関連

| サブカテゴリ   | スキル数 |
| -------------- | -------- |
| Knowledge Base | 4,376    |
| Technical Docs | 1,733    |
| Education      | 1,650    |

Knowledge Base が 4,000 以上あるのは、社内 Wiki とか FAQ の作成スキルがここに入ってるから。Technical Docs も 1,733 あって、API ドキュメントとか README の書き方のベストプラクティスがスキルとして使える

Content & Media カテゴリ（5,591 スキル）

コンテンツ制作関連

| サブカテゴリ     | スキル数 |
| ---------------- | -------- |
| Content Creation | 2,925    |
| Documents        | 1,935    |
| Design           | 1,297    |
| Media            | 463      |

Content Creation が 2,925 あるから、ブログ記事とか SNS 投稿の作成に使えるスキルが豊富。Design も 1,297 あって、デザインシステムとかブランドガイドラインのスキルがある

Research カテゴリ（2,653 スキル）

研究・学術関連

| サブカテゴリ            | スキル数 |
| ----------------------- | -------- |
| Academic                | 1,543    |
| Scientific Computing    | 640      |
| Computational Chemistry | 601      |
| Bioinformatics          | 496      |
| Lab Tools               | 109      |
| Astronomy & Physics     | 97       |

研究者向けのスキルもあるんよね。Academic が 1,543 あって、論文の書き方とか文献レビューのベストプラクティスがスキルとして共有されてる

Bioinformatics とか Computational Chemistry みたいな専門分野のスキルもあるのは、コミュニティの多様性を感じる

Databases カテゴリ（1,543 スキル）

データベース関連のスキルが 1,543 個。SQL の書き方とか、各データベースの特性を活かしたクエリの最適化とか、そういう知識がスキルとして使える

Skills の仕組みを理解しよう

Skills Marketplace を使いこなすには、Skills 自体の仕組みを理解しておくと良い。ドキュメントページにわかりやすくまとまってるから、そこから抜粋して解説する

Token Efficiency（トークン効率）

Skills は lazy loading を採用してて、トークンとコストを節約できる仕組みになってる

- Claude は最初、スキルの名前と説明だけを見る
- 現在のタスクに関連する場合のみ、全コンテンツをロードする
- 使われないスキルは会話でトークンを消費しない

これがめっちゃ重要で、大量のスキルをインストールしても、必要なときだけロードされるから効率的なんよね

Domain Expertise（専門知識の注入）

Skills は専門知識を注入する複数のアプローチを提供してる

- Professional knowledge injection: ベストプラクティスを SKILL.md に直接記述
- Operational consistency: 毎回安定した品質を確保
- Reference docs: 必要なときにロードされる詳細ドキュメント（references/ に配置）
- Resource files: テンプレートやアセット（assets/ ディレクトリに配置）

これによって、単なる「指示」じゃなくて「専門家の知識」を Claude に取り込めるわけ

Skills と MCP の違いを整理しよう

ここが一番大事な部分かもしれない。Skills と MCP（Model Context Protocol）は根本的に違う問題を解決してる

Skills の特徴

- 知識共有: 経験、ベストプラクティス、ワークフローを共有
- シンプルな Markdown ファイル: 誰でも作成できる
- Progressive loading: トークン効率が良い
- サーバー不要: セットアップの手間がない
- クロスプラットフォーム: Web + Desktop + CLI で動作（ほとんどのスキル）

MCP の特徴

- 機能拡張: API、データベース、ツールへの接続
- コーディングとサーバー設定が必要: 技術的なハードルが高い
- 起動時に全ツール定義をロード: トークン消費が高い
- 外部統合に強力: 実際のシステムと連携できる
- 複雑なセットアップ: 導入コストが高い

:::discovery
Skills と MCP は補完関係にある。知識共有には Skills を使い、機能拡張には MCP を使う。両方を組み合わせると本当の力を発揮する
:::

実際の使い方

Skills Marketplace の使い方は簡単

AI セマンティクス検索で探す

トップページの検索バーに「やりたいこと」を入力するだけ。自然言語で検索できるから、キーワードを考える必要がない

例えば「React コンポーネントのテストを書きたい」と入力すると、関連するスキルがヒットする

カテゴリから探す

カテゴリページ（/categories）から探すのも効率的。自分の目的に合ったカテゴリを選んで、サブカテゴリを絞り込んでいく

全部で 65,000 以上あるから、最初はカテゴリから探す方が見つけやすいかもしれない

人気順でソート

stats ページで人気のスキルを確認できる。多くの人に使われてるスキルは品質が高い傾向にあるから、まずは人気のものから試してみるのもあり

スキルのインストール方法

見つけたスキルをインストールするには、GitHub リポジトリをクローンして、.claude/skills/ ディレクトリに配置するだけ



SKILL.md 標準に準拠してるから、どのスキルも同じ構造になってて扱いやすい

なぜ今 Skills Marketplace が重要なのか

ここまで読んで「へー、便利そうだな」と思ってくれたならうれしい。でも、なぜ「今」これが重要なのかをもう少し掘り下げたい

車輪の再発明を避ける

自分でスキルを一から作る前に、まずは既存のスキルを探すべき。65,000 以上あるから、大抵のユースケースはカバーされてる

見つかったスキルをベースに、自分用にカスタマイズする方が効率的やし、品質も高くなりやすい

公式からの推奨

Anthropic 公式がこのサービスを紹介してるという事実は大きい。信頼性の裏付けになるし、今後もサポートされていく可能性が高い

LangChain の deepagent-CLI にも統合されてるから、エコシステムとしての広がりも期待できる

自分でスキルを作る場合

もちろん、既存のスキルでカバーできないユースケースもある。そういうときは自分でスキルを作ることになる

サイトの UI/UX がめっちゃ開発者向け

Skills Marketplace のサイトデザインも特徴的なんよね。ターミナル風の UI になってて、開発者にとっては親しみやすい

トップページには  みたいなコード風の表示があったり、カテゴリページでは  みたいな見出しになってたりする。遊び心があっていい

検索バーは  というコマンド風のプロンプトになってて、ここにやりたいことを自然言語で入力すると AI が関連スキルを探してくれる

実際に触ってみて感じたこと

ワイが実際にサイトを触ってみて感じたことを正直に書いておく

良かった点

まず検索性が高い。65,000 以上あると探すの大変そうに思えるけど、カテゴリ分けがしっかりしてるから目的のスキルにたどり着きやすい。AI セマンティクス検索も精度が高くて、「こういうことしたい」という曖昧な入力でもちゃんと関連スキルが出てくる

全部 GitHub のオープンソースっていうのも安心感がある。スキルの中身を事前に確認できるし、何か問題があればイシューを立てたりプルリク送ったりできる。クローズドなマーケットプレイスだとこうはいかない

カテゴリの粒度もちょうどいい。大カテゴリが 10 個、サブカテゴリがそれぞれ 4〜11 個くらいで、多すぎず少なすぎず探しやすい

改善してほしい点

スキルの品質にばらつきがあるのは仕方ないけど、もう少しキュレーションがあると助かる。人気順でソートできるとはいえ、品質保証されたスキルをまとめたセクションとかあると初心者には優しいかも

あと日本語対応がまだないから、英語が苦手な人にはちょっとハードルが高い。スキル自体は英語で書かれてることが多いけど、サイトの UI は多言語対応してほしい気持ちはある

おすすめの使い方

ここからは実践的な使い方を紹介する

新しいフレームワークを学ぶとき

例えば React から Vue に乗り換えようとしてるとき、Vue のベストプラクティスを教えてくれるスキルをインストールしておくと、Claude がそのスキルを参照しながらコードを書いてくれる

フレームワークの公式ドキュメントを読むのも大事やけど、実践的なノウハウはスキルから得る方が早いことも多い

チーム開発の標準化

チームで Claude Code を使う場合、同じスキルセットを共有することで出力の一貫性が保たれる。コーディング規約とかコミットメッセージのルールとか、チームのスタンダードをスキルとして定義しておくと便利

Skills Marketplace から見つけたスキルをベースに、チーム独自のカスタマイズを加えるのもあり

専門外の領域に挑戦するとき

普段バックエンドをやってる人がフロントエンドに挑戦するとき、Frontend カテゴリのスキルを入れておくと心強い。逆もまた然り

専門家が作ったスキルを使うことで、その領域のベストプラクティスを自然と取り入れられる

今後の展望

Skills Marketplace は今後さらに成長していくと予想してる

まずスキル数が増え続けるのは確実。12 月末から急増してるトレンドを見ると、コミュニティの勢いは止まらない

Anthropic 公式が紹介してることからも、Skills エコシステム自体がサポートされ続ける可能性は高い。Claude Code のアップデートに合わせて、スキルの仕様も進化していくやろう

MCP との連携も興味深い。現時点では Skills と MCP は別々のものやけど、将来的には両者を組み合わせたワークフローがもっと洗練されていくかもしれない

まとめ

Agent Skills Marketplace は Claude Code ユーザーにとって必須のリソースになりつつある

- 65,635 個以上のオープンソーススキル
- SKILL.md 標準に準拠
- AI セマンティクス検索で探しやすい
- Anthropic 公式も紹介
- Skills と MCP は補完関係

スキルを自作する前に、まずはここをチェックしてみてほしい。先人たちの知恵を借りることで、Claude Code の活用が一気に加速するはず

リンク: [Agent Skills Marketplace](https://skillsmp.com)

参考リンク

- [Agent Skills Marketplace](https://skillsmp.com)
- [Agent Skills Open Specification](https://skillsmp.com/docs)
- [Claude Platform Documentation - Agent Skills Overview](https://docs.anthropic.com/en/docs/claude-code/skills)
- [Equipping agents for the real world - Anthropic Blog](https://www.anthropic.com/news/equipping-agents-for-the-real-world)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Codeの CLAUDE.md、Rules、Skills、Subagents、MCPs使い分け]]></title>
            <link>http://izanami.dev/post/47deb6b9-0965-41e7-b128-12f5937e8748</link>
            <guid>http://izanami.dev/post/47deb6b9-0965-41e7-b128-12f5937e8748</guid><dc:creator>commte</dc:creator>
            <pubDate>Wed, 14 Jan 2026 13:36:34 GMT</pubDate>
            <description><![CDATA[最初にポイントをざっくり書く

CLAUDE .md、Rules、Skills、Subagents、MCPs 。5 つのレイヤーの使い分けの感覚はこれだけ覚えればいい

- どういう思想で働いてほしい]]></description>
            <content:encoded><![CDATA[最初にポイントをざっくり書く

CLAUDE .md、Rules、Skills、Subagents、MCPs 。5 つのレイヤーの使い分けの感覚はこれだけ覚えればいい

- どういう思想で働いてほしいかは CLAUDE .md
- この領域では絶対に守る知識は Rules
- 人（自動もあり）が開始する作業手順は Skills
- 自動で任せたい重い作業は Subagents
- 外部世界と触るなら MCP

Claude Code は「全部ルールを書くほど賢くなる」わけではない
レイヤーを間違えると、むしろ指示を無視し始める

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発 / Claude Code などを中心に情報を配信しています

この記事は [Mario Ottmann 氏の Claude Code Customization Guide](https://marioottmann.com/articles/claude-code-customization-guide) にインスピレーションを受け、[Anthropic 公式ドキュメント](https://code.claude.com/docs)と論文も引っ張り出して検証したもの

よくある失敗

あるある過ぎて…

- CLAUDE .md に全部詰め込む
- ワークフロー指示を Rules に書く
- レイヤーの役割を理解せず混ぜる

ポイント

段階的に構築すること

1. まず CLAUDE .md で地図を作る
2. 次に Rules で専門知識を固める
3. 繰り返し作業は Skills に切り出す
4. 重くなったら Subagents に任せる
5. 外部と繋ぐ必要が出たら MCPs を使う
6. トリガー発動は、スラッシュコマンド

わからなくなったら

- CLAUDE .md はプロジェクトの地図
- Rules は専門知識
- Skills は繰り返し作業
- Subagents は複雑な自動化
- MCPs は外部ツール連携

コムテは？

ワイ？これで SaaS を１週間くらいで作るよ

1. スラッシュコマンドを多用
2. CLAUDE .md は簡潔に 200 行以内
3. ドメイン知識は Rules
4. MCP は、少なめに
5. Skills は、多くても２つくらい
6. Subagents は必須でない。必要なプロジェクトで

それじゃあ、解説始めるよー

Claude Code のカスタマイズ、CLAUDE .md だけで頑張ってない?

Claude Code を使い始めると、まず CLAUDE .md にあれこれ書き込みたくなるよね

プロジェクトのルール、コーディング規約、よく使うコマンド、全部ここに書いておけば Claude が賢くなるはずやと

やけど、ここで多くの開発者がハマる罠がある。CLAUDE .md に全部詰め込むと、むしろ Claude は指示を無視し始めるんよね

300 行を超えたあたりから、書いたはずのルールを平気でスルーするようになる

これは Claude Code のアーキテクチャを理解していないと起こる問題で、実は Claude Code には 5 つのカスタマイズレイヤーがあって、それぞれに明確な役割がある

このレイヤーを正しく使い分けることで、Claude は「何度言っても覚えない AI」から「プロジェクトを深く理解した相棒」に変わる

arxiv で公開されている研究 [A Systematic Survey of Prompt Engineering in Large Language Models](https://arxiv.org/abs/2402.07927) でも指摘されているけど、プロンプトエンジニアリングにおいて重要なのは「適切な粒度での指示の分離」なんよ。一つの巨大なプロンプトより、役割ごとに分離された複数の指示の方が、LLM はより正確に従う傾向がある

5 つのレイヤーの全体像

まず、Claude Code のカスタマイズは「内部レイヤー」と「外部レイヤー」に分かれる

内部レイヤーは Claude の「脳」を構成する 4 つの要素で、Claude がどう考え、何を知っていて、どう働くかを決める

| レイヤー   | トリガー             | 用途                         |
| ---------- | -------------------- | ---------------------------- |
| CLAUDE .md | 常に読み込み         | プロジェクトの地図、基本設定 |
| Rules      | パスベースまたは常に | ドメイン固有の深い知識       |
| Skills     | ユーザーが起動       | 繰り返しワークフロー         |
| Subagents  | Claude が自動起動    | 複雑な自動タスク             |

外部レイヤーは MCPs で、Claude の「手」として外部ツールに接続する役割を持つ

| レイヤー | トリガー     | 用途                   |
| -------- | ------------ | ---------------------- |
| MCPs     | ツール利用時 | 外部ツールへのアクセス |

この構造を理解すると、使い分けの感覚は実はめっちゃシンプルになる

使い分けの感覚はこれだけ覚えればいい

迷ったときは、この 5 つの問いを順番に考えてみて

- どういう思想で働いてほしいかは CLAUDE .md
- この領域では絶対に守る知識は Rules
- 人が開始する作業手順は Skills
- 自動で任せたい重い作業は Subagents
- 外部世界と触るなら MCPs

arxiv の研究 [RePrompt: Planning by Automatic Prompt Engineering for Large Language Models Agents](https://arxiv.org/abs/2406.11132) では、LLM エージェントの性能は「適切なレイヤーでの指示の配置」に大きく依存することが示されている。中間フィードバックを活用した段階的な最適化が、タスク完了率を大幅に向上させるんよね

CLAUDE .md とは何か

CLAUDE .md は Claude Code の「マスター設定」で、セッションが始まるたびに必ず読み込まれる。公式ドキュメントでは「Memory」とも呼ばれていて、プロジェクト全体に適用される前提知識を置く場所や

配置できる場所は 4 つあって、優先度順に並べるとこうなる

| 種類       | 場所                 | 共有範囲   |
| ---------- | -------------------- | ---------- |
| Enterprise | システムディレクトリ | 組織全体   |
| Project    | ./CLAUDE .md         | チーム全員 |
| User       | /.claude/CLAUDE .md | 自分のみ   |
| Local      | ./CLAUDE.local.md    | 自分のみ   |

Project レベルの CLAUDE .md はリポジトリにコミットして、チームで共有する。User レベルは個人の好みを全プロジェクトに適用する。Local は git にコミットしたくない個人設定を置く場所や

CLAUDE .md に書くべきもの

CLAUDE .md はプロジェクトの「地図」であり「従業員ハンドブック」のようなもの。新入社員が初日に読む資料をイメージすると分かりやすい

具体的には

- フレームワーク規約（Next.js 14 App Router を使う、など）
- コード品質基準（DRY 原則、テストの書き方）
- アクセシビリティ要件
- CI/CD の期待値
- 利用可能な Skills、Rules、Subagents のインデックス

公式ドキュメントによると、CLAUDE .md は 300 行以下が目安。これを超えると Claude がすべてを正確に把握できなくなる傾向がある

CLAUDE .md に書かないべきもの

逆に、CLAUDE .md に書くべきでないものもある

- 深いドメイン知識（Rules に分離）
- ステップバイステップのワークフロー（Skills に分離）
- 特定ファイルパターンにのみ適用されるルール（Rules に分離）

よくある失敗は、CLAUDE .md に設計規約、セキュリティポリシー、データベースパターン、コーディングスタイル、全部を 1 ファイルに詰め込んでしまうこと。そうすると Claude はコンテキストの重要度を判断できなくなって、結果的に指示を無視し始める

CLAUDE .md の実践例

実際のプロジェクトで使われている CLAUDE .md の構造はこんな感じや

/api-design/form-builderauth-patterns.mdapi-client.md

ポイントは「参照先へのリンク」として機能させること。詳細は Rules や Skills に任せて、CLAUDE .md は全体の地図に徹する

CLAUDE .md の import 機能

CLAUDE .md には他のファイルを import する機能がある。 構文を使う



相対パスと絶対パスの両方が使える。特に便利なのは、チームメンバーごとに個別の設定ファイルを読み込ませること



これは CLAUDE.local.md の代替として機能して、複数の git worktree で作業する場合に特に便利や

Rules とは何か

Rules は  ディレクトリに配置する markdown ファイルで、ドメイン固有の深い知識を格納する場所や。CLAUDE .md との決定的な違いは「パスベースのフィルタリング」ができること

Rules のディレクトリ構造



 内のすべての  ファイルは自動的にプロジェクトメモリとして読み込まれる

パスベースのフィルタリング

Rules の真価は「特定のファイルを編集しているときだけ読み込まれる」ことにある。YAML フロントマターで  を指定する



この rule は、データベース関連のファイルを編集しているときだけ Claude のコンテキストに読み込まれる。CSS を編集しているときには読み込まれないから、コンテキストの無駄遣いを防げる

glob パターンの例

| パターン            | マッチするもの                         |
| ------------------- | -------------------------------------- |
|            | 任意ディレクトリの TypeScript ファイル |
|           | src ディレクトリ以下のすべて           |
|               | プロジェクトルートの markdown          |
|  | src 以下の .ts と .tsx                 |

Rules に書くべきもの

Rules は「専門部門のドキュメント」のようなもの。CLAUDE .md が全社共通のハンドブックなら、Rules は各部門の詳細マニュアルや

- フロントエンド
- セキュリティ要件（コード例付き）
- データベースパターン（RLS ポリシー、クエリ最適化）
- フレームワーク固有の詳細（Tailwind v4 のユーティリティマッピング）

Rules の実践例 - フロントエンド

type Props = {}React.FC

このような rule があると、Claude は自動的に HTML をサニタイズし、埋め込み追加時に CSP ヘッダーを更新するようになる

CLAUDE .md と Rules の使い分け

| CLAUDE .md               | Rules                        |
| ------------------------ | ---------------------------- |
| 常に読み込まれる         | パスフィルタ可能             |
| プロジェクト全体の基準   | ドメイン固有の深い知識       |
| クイックリファレンス形式 | 詳細なドキュメント           |
| 単一ファイル             | 複数のフォーカスしたファイル |
| 「ここでの働き方」       | 「X を具体的にどうやるか」   |

研究 [Architecting Resilient LLM Agents](https://arxiv.org/pdf/2509.08646) では、行動を起こす前に完全なステップバイステップの計画を生成することで、推論の質とタスク完了率が向上することが示されている。これは Claude Code の Rules が提供する「コンテキストに応じた詳細な指示」の有効性を裏付けている

Skills とは何か

Skills はスラッシュコマンドとして展開される「繰り返し可能なワークフロー」を定義するもの。公式ドキュメントでは「Agent Skills」と呼ばれていて、Claude が特定のタスクを実行する方法を教える markdown ファイルや

重要なのは、Skills は「モデルが起動する」という点。ユーザーのリクエストが Skill の説明にマッチすると、Claude は自動的にその Skill を適用する

Skills のディレクトリ構造

Skills は 2 つの場所に配置できる

| 場所                | スコープ                         |
| ------------------- | -------------------------------- |
|  | 個人用、全プロジェクトで利用可能 |
|    | プロジェクト用、チームで共有     |

各 Skill はディレクトリで、その中に  と追加のサポートファイルを含む



SKILL .md の構造

SKILL .md は YAML メタデータと Markdown 指示で構成される



 フィールドが特に重要で、Claude はこれを見て「いつこの Skill を使うべきか」を判断する

利用可能なメタデータフィールド

| フィールド     | 必須   | 説明                                        |
| -------------- | ------ | ------------------------------------------- |
| name           | はい   | スキル名（小文字、ハイフン、最大 64 文字）  |
| description    | はい   | 用途と使用タイミング（最大 1024 文字）      |
| allowed-tools  | いいえ | 許可するツール                              |
| model          | いいえ | 使用するモデル                              |
| context        | いいえ |  でサブエージェントコンテキストで実行 |
| hooks          | いいえ | ライフサイクルフック                        |
| user-invocable | いいえ | スラッシュコマンドメニューに表示するか      |

Skills に書くべきもの

Skills は「ユーザーの起動が必要で、実行中にユーザー入力が必要になる可能性があるマルチステップワークフロー」に最適

- アーキテクチャ決定（ユーザー確認が必要）
- コンテンツ生成ワークフロー
- 法的/コンプライアンスページ生成
- デプロイチェックリスト
- コードレビューワークフロー

Skills の実践例 - バックエンドアーキテクチャ



 と入力すると、Claude はこの決定ツリーに沿って一緒に考えてくれる

Skills と Rules の違い

Skills と Rules は似ているように見えるけど、根本的に異なる

| Skills               | Rules                    |
| -------------------- | ------------------------ |
| ユーザーがトリガー   | パスベースで自動読み込み |
| ワークフロー指向     | 知識/コンテキスト指向    |
|   |          |
| マルチステップの手順 | ドメイン固有のルール     |

「Supabase を使うときのルール」は Rules に書く。「どの DB 技術を使うか決める手順」は Skills に書く

Subagents とは何か

Subagents は「専門的な AI アシスタント」で、複雑なマルチステップタスクを自律的に処理する。各 Subagent は独自のコンテキストウィンドウ、カスタムシステムプロンプト、特定のツールアクセス、独立した権限を持つ

Skills との決定的な違いは、Subagents は「Claude が自動的に起動する」こと。タスクが Subagent の説明にマッチすると、Claude はそこに委譲する

ビルトイン Subagents

Claude Code には 3 つのビルトイン Subagent がある

| Subagent        | モデル             | 用途                                 |
| --------------- | ------------------ | ------------------------------------ |
| Explore         | Haiku（高速）      | 読み取り専用のコードベース検索・分析 |
| Plan            | Sonnet             | 実装計画のためのリサーチ             |
| general-purpose | 会話のモデルを継承 | 探索と変更の両方が必要な複雑タスク   |

カスタム Subagents

本当の力はカスタム Subagent を定義することで発揮される。設定で定義しておくと、タスクが説明にマッチしたときに自動的に起動する



これを設定しておくと、「ログイン機能を実装した」と言ったあとに Claude が自動的にセキュリティ監査を実行する

Subagents のディレクトリ構造

| 場所                | スコープ                         |
| ------------------- | -------------------------------- |
|  | 個人用、全プロジェクトで利用可能 |
|    | プロジェクト用、チームで共有     |

Subagents のフロントマター



| フィールド     | 説明                                                   |
| -------------- | ------------------------------------------------------ |
| name           | 一意の識別子                                           |
| description    | いつ委譲するかの説明                                   |
| tools          | 使用可能なツール                                       |
| model          | sonnet, opus, haiku, inherit                           |
| permissionMode | default, acceptEdits, dontAsk, bypassPermissions, plan |
| skills         | 読み込む Skills                                        |
| hooks          | ライフサイクルフック                                   |

Skills と Subagents の使い分け

| Skills                 | Subagents                  |
| ---------------------- | -------------------------- |
| 現在の会話に知識を追加 | 独立したコンテキストで実行 |
| ユーザーが起動         | Claude が自動起動          |
| ガイダンスと標準向け   | 複雑な自律タスク向け       |

「PR レビューのやり方」を教えるなら Skills。「大規模なセキュリティ監査を自動実行」なら Subagents

研究 [Prompt Injection Defense Patterns for LLM Agents](https://arxiv.org/pdf/2506.08837) では、「plan-then-execute」パターンがプロンプトインジェクション攻撃を緩和することが示されている。Subagents はまさにこのパターンを実現していて、信頼できないデータを処理する前に計画を定義し、許可されたツール呼び出しのみを実行する

Subagents の実践例 - コードレビュアー



フォアグラウンドとバックグラウンド実行

Subagents はフォアグラウンド（ブロッキング）またはバックグラウンド（並行）で実行できる

フォアグラウンドは完了するまでメイン会話をブロックする。権限プロンプトや質問はユーザーに渡される

MCPs とは何か

MCPs (Model Context Protocol) は Claude Code を外部ツールやデータソースに接続するオープンソース標準。内部レイヤー 4 つが「Claude の脳」を構成するなら、MCPs は「Claude の手」として外部世界とインタラクトする

GitHub、Slack、データベースなど、コードベース外の何かに触る必要があるなら MCPs の出番や

MCPs でできること

MCPs を接続すると、Claude Code に

- イシュートラッカーから機能を実装: 「JIRA issue ENG-4521 の機能を追加して GitHub に PR を作成」
- モニタリングデータを分析: 「Sentry と Statsig で ENG-4521 機能の使用状況を確認」
- データベースをクエリ: 「PostgreSQL から ENG-4521 機能を使った 10 人のランダムユーザーのメールを取得」
- デザインを統合: 「Slack に投稿された新しい Figma デザインに基づいてメールテンプレートを更新」
- ワークフローを自動化: 「この 10 人のユーザーにフィードバックセッションへの招待メールのドラフトを Gmail で作成」

MCP サーバーの管理



MCP インストールスコープ

| スコープ | 場所                                 | 共有範囲                       |
| -------- | ------------------------------------ | ------------------------------ |
| local    | /.claude.json（プロジェクトパス下） | 自分のみ（現在のプロジェクト） |
| project  | .mcp.json                            | チーム（git コミット）         |
| user     | /.claude.json                       | 自分のみ（全プロジェクト）     |

MCP の実践例 - Sentry でエラー監視



よくある失敗パターン

ここまで各レイヤーを見てきたけど、失敗パターンも押さえておこう

失敗 1: CLAUDE .md に全部詰め込む

CLAUDE .md はクイックリファレンスであって、500 行のドキュメントではない。深いドメイン知識は Rules に分離すべき

失敗 2: ワークフローを Rules に書く

Rules はコンテキストであって、指示ではない。「常に DOMPurify を使う」は rule。「リーガルページを生成するときは X、Y、Z をする」は skill や

失敗 3: パスベースフィルタリングを使わない

データベースルールを CSS 編集時に読み込むのはコンテキストの無駄。paths フロントマターで関連ファイル編集時のみ読み込む

失敗 4: 自律タスクに Skills を使う

実行中にユーザー入力が不要なタスクは、Subagent として Claude が自動起動すべき。Skills はユーザー起動が必要なワークフロー向け

失敗 5: 外部統合を bash コマンドでハックする

外部アクセスを bash コマンドでやろうとするのは脆弱。MCPs が適切なツールインターフェースを提供する

失敗 6: CLAUDE .md をスキップする

CLAUDE .md なしでは、毎セッション同じことを繰り返し説明することになる。「Next.js 14 App Router を使ってることを忘れないで...」

決定フレームワーク - どのレイヤーを使う?

迷ったときは、この質問を順番に聞いてみて

1. プロジェクト全体の基準またはクイックリファレンス?
   → CLAUDE .md（フレームワーク規約、コード品質基準、アクセシビリティ、skills/rules のインデックス）

2. 深いドメイン知識?
   → Rules（デザインシステム、セキュリティ、データベースパターン、RLS ポリシー）

3. トリガーする繰り返しワークフロー?
   → Skills（アーキテクチャ決定、コンテンツ生成、リーガルページ、デプロイチェックリスト）

4. 複雑な自律タスク?
   → Subagents（セキュリティ監査、コードベース探索、大規模リファクタリング、コンテンツ変換）

5. 外部ツールアクセスが必要?
   → MCPs（GitHub、データベース、Slack、CI/CD パイプライン）

実践的な組み合わせ例

フロントエンド開発スタック

- CLAUDE .md: Next.js 規約、React パターン、アクセシビリティ基準
- Rules: design-system.md、tailwind-v4.md
- Skills: /landing-page-builder
- Subagents: Explore（ビルトイン）
- MCPs: 通常不要

バックエンド開発スタック

- CLAUDE .md: Next.js 規約、コード品質、テスト要件
- Rules: database-supabase.md（パスフィルタ）、security.md
- Skills: /backend-architecture
- Subagents: Plan（ビルトイン）、security-auditor（カスタム）
- MCPs: Postgres、GitHub

コンテンツ作成スタック

- CLAUDE .md: コード品質、アクセシビリティ（生成ページ向け）
- Rules: design-system.md（一貫したフォーマット向け）
- Skills: /legal-pages
- Subagents: linkedin-to-mdx-blog（カスタム）
- MCPs: 通常不要

段階的な構築アプローチ

5 つのレイヤーすべてを一度に使う必要はない。段階的に構築していくのがベストプラクティス

ステップ 1: CLAUDE .md で地図を作る

まずはフレームワーク規約、コード品質基準、追加予定のもののインデックスから始める。これが基盤になる



ステップ 2: Rules でドメイン知識を固める

 にデザインシステムとセキュリティ要件を作成。特定コンテキストでのみ重要なルールにはパスフィルタリングを使う

ステップ 3: 繰り返し作業を Skills に切り出す

週に 2-3 回やるワークフローを特定して、 に SKILL.md と追加サポートファイルを含むディレクトリを作成

ステップ 4: 重い作業は Subagents に任せる

作業していて「Claude が自動的に専門エージェントを使えたら便利なのに」と思ったら、カスタム Subagent を設定する

ステップ 5: 外部連携が必要になったら MCPs を追加

外部ツールアクセスが必要になったら、適切な MCP サーバーを設定する

まとめ

Claude Code のカスタマイズは 5 つのレイヤーで構成される

内部レイヤー（Claude の設定）

- CLAUDE .md - プロジェクト全体の基準とクイックリファレンスインデックスを持つマスター設定
- Rules - オプションのパスベースフィルタリングを持つ深いドメイン知識
- Skills - 繰り返しマルチステッププロセスのためのユーザートリガーワークフロー
- Subagents - 必要に応じて Claude が起動する複雑タスク用の自律スペシャリスト

外部レイヤー（外部への橋渡し）

- MCPs - GitHub、データベース、Slack などの外部ツールへの接続

目標は 5 つのレイヤーすべてをどこでも使うことではない。適切な仕事に適切なレイヤーを使うことや

研究 [Agent Security Bench](https://arxiv.org/pdf/2410.02644v3)（ICLR 2025）でも指摘されているように、効果的なシステムプロンプトを書くには専門知識が必要で、それをレイヤー構造で整理することがセキュリティと効率性の両方に寄与する

この使い分けができたとき、Claude Code は本当の力を発揮する

参考リンク

- [Claude Code 公式ドキュメント - Settings](https://code.claude.com/docs/en/settings)
- [Claude Code 公式ドキュメント - Skills](https://code.claude.com/docs/en/skills)
- [Claude Code 公式ドキュメント - Subagents](https://code.claude.com/docs/en/subagents)
- [Claude Code 公式ドキュメント - MCP](https://code.claude.com/docs/en/mcp)
- [Claude Code 公式ドキュメント - Memory](https://code.claude.com/docs/en/memory)
- [元記事: Claude Code Customization Guide](https://marioottmann.com/articles/claude-code-customization-guide)
- [arxiv: A Systematic Survey of Prompt Engineering in LLMs](https://arxiv.org/abs/2402.07927)
- [arxiv: RePrompt: Automatic Prompt Engineering for LLM Agents](https://arxiv.org/abs/2406.11132)
- [arxiv: Architecting Resilient LLM Agents](https://arxiv.org/pdf/2509.08646)
- [arxiv: Prompt Injection Defense Patterns](https://arxiv.org/pdf/2506.08837)
- [arxiv: Agent Security Bench (ICLR 2025)](https://arxiv.org/pdf/2410.02644v3)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[CLAUDE.md や AGENTS.md のベストプラクティスな書き方]]></title>
            <link>http://izanami.dev/post/47b08b5a-6e1c-4fb0-8342-06b8e627450a</link>
            <guid>http://izanami.dev/post/47b08b5a-6e1c-4fb0-8342-06b8e627450a</guid><dc:creator>commte</dc:creator>
            <pubDate>Tue, 13 Jan 2026 23:16:29 GMT</pubDate>
            <description><![CDATA[Claude Code を使っていて、なんか思い通りに動かんなって感じたことない？指示を書いてるはずなのに無視される、毎回同じことを説明し直さなあかん、コードスタイルがバラバラになる

こういう問題の]]></description>
            <content:encoded><![CDATA[Claude Code を使っていて、なんか思い通りに動かんなって感じたことない？指示を書いてるはずなのに無視される、毎回同じことを説明し直さなあかん、コードスタイルがバラバラになる

こういう問題の多くは、実は CLAUDE .md の書き方に原因があったりするんよね

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発などを中心に情報を配信しています

この記事は HumanLayer のブログ記事「[Writing a good CLAUDE .md](https://www.humanlayer.dev/blog/writing-a-good-claude-md)」をベースに、Anthropic の公式ドキュメントと最新の学術研究を加えて、効果的な CLAUDE .md の書き方を徹底解説していく

CLAUDE .md、Rules、Skills、Subagents、MCPs 。5 つのレイヤーの使い分けについては以下のページで解説しました

https://izanami.dev/post/47deb6b9-0965-41e7-b128-12f5937e8748

５つの原則

Claude Code の CLAUDE .md や AGENTS .md で使えるベストプラクティス

- WHY、WHAT、HOW を定義
- 命令は少なく
- 段階的開示
- リンターをさせるな
- 自動生成は避ける

これがどれほど重要かピンときてない君！

これ、どんな AI コーディングエージェントでも何年でも使える汎用的なコツだよ？

WHY、WHAT、HOW を定義

まず、この３つを必ず書く

WHAT

テックスタック、プロジェクト構造、コードベースの全体像
Claude が最初に迷子にならないための地図を書く

WHY

プロジェクトの目的、各ディレクトリやコンポーネントの役割
なぜこの構成になっているのかを理解させる

HOW

作業の進め方そのものではなく、どうやって正解を検証できるか
テスト、型チェック、ビルドなど、変更の是非を判断する手段を示す

これについては、後述するね

少ないほど良い、を徹底する

- 理想は 300 行未満。HumanLayer の実例は 60 行未満
- 情報を詰め込みすぎると、重要な指示ほど無視されやすくなる

これは好みの問題ではなく、仕様の問題でもある

正直、この記事の方法でいけば SaaS レベルのプロダクトでも 100 行くらいで収まるよ？

それ以上書いちゃう人は、「もうちょっと抽象的に考えろ」ってことやね

CLAUDE .md には「この情報はタスクと無関係かもしれない」という前提付きで渡されるから、汎用性の低い指示が多いと、まとめて relevance なし判定されやすい

それでも収まらないって？

その対処法も後述する

LLM はステートレスという大前提を理解する

まず最初に押さえておきたいのが、LLM の根本的な性質。LLM は状態を持たない関数なんよね

重みは推論時点で凍結されてるから、使ってるうちに学習していくなんてことはない。つまり、セッションごとに完全にリセットされるってこと

HumanLayer のブログでは、この点について明確に述べられてる

LLM がコードベースについて知ってることは、こちらが渡したトークンだけ。Claude Code のようなコーディングエージェントは、明示的にメモリを管理する必要がある。そして CLAUDE .md は、デフォルトでエージェントとのすべての会話に含まれる唯一のファイルなんよね

これには 3 つの重要な意味がある

- コーディングエージェントは各セッションの開始時点でコードベースについて何も知らない
- エージェントには毎回、コードベースについて重要なことを伝える必要がある
- CLAUDE .md がそのための推奨方法

ここをちゃんと理解してないと、CLAUDE .md の設計がブレてしまうんよね

WHY / WHAT / HOW の 3 要素

CLAUDE .md に書くべき内容は、大きく分けて 3 つある。これは HumanLayer のブログでも強調されてるポイント

WHAT（何があるか）

技術スタック、プロジェクト構造、コードベースの全体像を伝える部分。Claude が最初に迷子にならないための地図を書くイメージ

特にモノレポでは重要で、各アプリケーションは何か、共有パッケージは何か、それぞれが何のためにあるのかを明示する。Claude がどこを見れば何があるかを把握できるようにするんよね

例えば、こんな感じで書く

apps/web/apps/api/packages/ui/packages/db/packages/domain/bun run buildbun run testbun run typecheckbun run lint

そして CLAUDE .md には、これらのファイルのリストと各ファイルの簡単な説明を含め、Claude に作業を始める前にどれが関連するか（もしあれば）を判断して読むように指示する

重要なのは「コピーよりポインタを優先する」こと。これらのファイルにコードスニペットを含めないほうがいい。すぐに古くなるから。代わりに、 参照を使って Claude を権威あるコンテキストに向ける

概念的には、これは Claude Skills の意図する動作に非常に似てるけど、スキルは指示よりもツールの使用に焦点を当ててる

Context Engineering という新しいパラダイム

2025 年に入って、「プロンプトエンジニアリング」を超えた「Context Engineering」という概念が注目されてる。arxiv の最新サーベイ論文「A Survey of Context Engineering for Large Language Models」（[arxiv.org/abs/2507.13334](https://arxiv.org/abs/2507.13334)）は、166 ページ、1411 件の引用を含む包括的な研究

この論文によると、LLM が単純な指示に従うシステムから複雑な多面的アプリケーションの中核となる推論エンジンへと進化するにつれて、やり取りの方法も進化する必要がある。「プロンプトエンジニアリング」という用語は基礎的やけど、もはや現代の AI システムが必要とする情報ペイロードの設計、管理、最適化の全範囲を捉えるには不十分

Context Engineering は単純なプロンプト設計を超えて、LLM のための情報ペイロードの体系的な最適化を包括する正式な分野として導入されてる。この論文では、基礎コンポーネント（コンテキスト検索と生成、コンテキスト処理、コンテキスト管理）と、それらを統合するシステム実装（RAG、メモリシステム、ツール統合推論、マルチエージェントシステム）を分析してる

Agentic Context Engineering の登場

さらに最新の研究として、「Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models」（[arxiv.org/abs/2510.04618](https://arxiv.org/abs/2510.04618)）がある

この研究では、ACE（Agentic Context Engineering）というフレームワークを提案してる。コンテキストを「evolving playbooks」（進化するプレイブック）として扱い、生成、リフレクション、キュレーションのモジュラープロセスを通じて戦略を蓄積、洗練、整理する

従来のアプローチには 2 つの問題があった

- brevity bias（簡潔さバイアス）: ドメインの洞察を捨てて簡潔な要約を好む傾向
- context collapse（コンテキスト崩壊）: 繰り返しの書き換えで時間とともに詳細が失われる

ACE はこれらの問題に対処し、エージェントとドメイン固有のベンチマークで +10.6%（エージェント）、+8.6%（金融）の改善を達成してる

この研究は CLAUDE .md の設計にも示唆を与える。静的な指示ファイルではなく、使用を通じて進化していく「プレイブック」としてコンテキストを考えるアプローチが効果的ってこと

Claude はリンターじゃない

CLAUDE .md に入れがちなものの筆頭が、コードスタイルガイドライン。やけど、これは絶対にやめたほうがいい

リンターの仕事を LLM にさせるな

LLM は従来のリンターやフォーマッターに比べて高価で遅い。決定論的なツールを使えるときは常にそっちを使うべき。コードスタイルガイドラインは必然的にたくさんの指示とほとんど無関係なコードスニペットをコンテキストウィンドウに追加し、LLM のパフォーマンスと指示への従い方を低下させ、コンテキストウィンドウを食いつぶす

LLM はコンテキスト内学習者。コードが特定のスタイルガイドラインやパターンに従ってるなら、コードベースのいくつかの検索（または良いリサーチドキュメント）があれば、エージェントは言われなくても既存のコードパターンや規約に従う傾向があるはず

どうしてもやりたいなら、Claude Code の Stop Hook を設定して、フォーマッターとリンターを実行し、エラーを Claude に提示して修正させることを検討してもいい。Claude 自身にフォーマットの問題を見つけさせるな。ボーナスとして、問題を自動修正できるリンター（Biome がおすすめ）を使い、何が安全に自動修正できるかのルールを慎重に調整して、最大の（安全な）カバレッジを得る

コードガイドラインを含み、バージョン管理の変更、または git status などに Claude を向けるスラッシュコマンドを作成することもできる。こうすれば、実装とフォーマットを別々に処理できて、結果として両方でより良い結果が得られる

/init や自動生成を使わない

Claude Code や OpenCode を使った他のハーネスには、CLAUDE .md（または AGENTS.md）を自動生成する方法がある。やけど、これは避けるべき

/init は、余計な情報書いちゃう。もったいない

CLAUDE .md は Claude Code とのすべてのセッションに入るから、ハーネスの最もレバレッジの高いポイントの 1 つ

良くも悪くも、使い方次第で悪いコード 1 行は悪いコード 1 行。悪い実装計画 1 行は、たくさんの悪いコードを生む可能性がある。システムの動作を誤解したリサーチの悪い 1 行は、計画にたくさんの悪い行を生み、結果としてさらに多くの悪いコードを生む可能性がある

やけど CLAUDE .md は、ワークフローのすべてのフェーズとそれによって生成されるすべての成果物に影響する。だから、そこに入るすべての行について非常に慎重に考える時間を取るべき

公式ドキュメントの階層構造

Anthropic の公式ドキュメントによると、Claude Code は 4 つのメモリロケーションを階層構造で提供してる

| メモリタイプ                   | 場所                                                        |
| ------------------------------ | ----------------------------------------------------------- |
| エンタープライズポリシー       | macOS:  |
| プロジェクトメモリ             |  または                 |
| プロジェクトルール             |                                       |
| ユーザーメモリ                 |                                       |
| プロジェクトメモリ（ローカル） |                                          |

階層の上位にあるファイルが優先され、最初に読み込まれる。より具体的なメモリがその上に構築される基盤を提供するってこと。 ファイルは自動的に  に追加されるから、バージョン管理にチェックインすべきでないプライベートなプロジェクト固有の設定に最適

CLAUDE .md のインポート機能

CLAUDE .md ファイルは  構文を使って追加ファイルをインポートできる



相対パスと絶対パスの両方が使える。特に、ユーザーのホームディレクトリのファイルをインポートすることで、リポジトリにチェックインされない個人の指示をチームメンバーが提供できる便利な方法になる

インポートは複数の git worktree でうまく動作する  の代替手段でもある



衝突を避けるため、インポートは Markdown のコードスパンやコードブロック内では評価されない。インポートされたファイルは追加ファイルを再帰的にインポートでき、最大深度は 5 ホップ

モジュラールール（.claude/rules/）の活用

大きなプロジェクトでは、 ディレクトリを使って指示を複数のファイルに整理できる。これにより、チームは 1 つの大きな CLAUDE .md の代わりに、焦点を絞った整理されたルールファイルを維持できる

基本構造



 内のすべての  ファイルは、 と同じ優先度でプロジェクトメモリとして自動的に読み込まれる

パス固有のルール

ルールは YAML フロントマターの  フィールドを使って特定のファイルにスコープできる。これらの条件付きルールは、Claude が指定されたパターンに一致するファイルを操作してるときだけ適用される



 フィールドのないルールは無条件に読み込まれ、すべてのファイルに適用される

glob パターン

 フィールドは標準的な glob パターンをサポートしてる

| パターン               | マッチするもの                                   |
| ---------------------- | ------------------------------------------------ |
|               | 任意のディレクトリのすべての TypeScript ファイル |
|              | src/ ディレクトリ下のすべてのファイル            |
|                  | プロジェクトルートの Markdown ファイル           |
|  | 特定のディレクトリの React コンポーネント        |

複数のパターンを指定することもできる



ブレース展開もサポートされてる



サブディレクトリでの整理

ルールはより良い構造のためにサブディレクトリに整理できる



すべての  ファイルは再帰的に検出される

シンボリックリンク

 ディレクトリはシンボリックリンクをサポートしてて、複数のプロジェクト間で共通のルールを共有できる



.claude/rules/ のベストプラクティス

- ルールは焦点を絞る: 各ファイルは 1 つのトピックをカバーする（例: 、）
- 説明的なファイル名を使う: ファイル名でルールの内容がわかるようにする
- 条件付きルールは控えめに: ルールが本当に特定のファイルタイプに適用される場合のみ paths フロントマターを追加する
- サブディレクトリで整理: 関連するルールをグループ化する（例: 、）

メモリのベストプラクティス

公式ドキュメントでは、以下のベストプラクティスが推奨されてる

- 具体的に書く: 「コードを適切にフォーマットする」より「2 スペースインデントを使用する」のほうがいい
- 構造を使って整理: 各メモリを箇条書きとしてフォーマットし、関連するメモリを説明的な Markdown 見出しの下にグループ化する
- 定期的にレビュー: プロジェクトの進化に合わせてメモリを更新し、Claude が常に最新の情報とコンテキストを使用するようにする

こんなのでいいんだよ CLAUDE .md

ここまでの知見を踏まえて、「こんなのでいいんだよ」的な CLAUDE .md の例を示す

src/app/src/components/src/lib/src/hooks/bun run devbun run buildbun run testbun run lint

この例は約 30 行。WHY/WHAT/HOW が簡潔にまとまってて、詳細は別ファイルへのポインタで参照してる

Claude が無視しにくい CLAUDE .md の書き方

先述の通り、Claude Code は CLAUDE .md の内容を「タスクに関係ない」と判断すると無視する。この挙動を踏まえて、無視されにくい CLAUDE .md を書くコツを整理しよう

普遍的に適用できる情報だけを書く

「データベースマイグレーションの手順」みたいな特定タスクの情報は CLAUDE .md に書かない。そういう情報は  のような別ファイルに分離して、必要なときだけ読ませる

CLAUDE .md には「このプロジェクトは bun を使う」「テストは vitest」みたいな、どんなタスクでも関係する情報だけを書く

指示ではなく事実を書く

「必ず〜してください」「〜は禁止です」みたいな指示形式より、「このプロジェクトでは〜を使ってる」「〜という設計方針がある」みたいな事実形式のほうが無視されにくい

指示が多すぎると、Claude は全体を「うるさいノイズ」として処理してしまう傾向がある

構造化して読みやすくする

箇条書き、見出し、テーブルを使って情報を構造化する。長い文章の塊は読み飛ばされやすい

bun run devbun run buildbun run test

こういう形式なら、Claude は必要な情報をすぐに見つけられる

LLM の注意力に関する研究知見

プロンプトエンジニアリングの研究では、LLM の「注意力」についていくつかの重要な知見が得られてる

先述の通り、LLM は指示がプロンプトの周辺部（最初と最後）にあるものに偏る傾向がある。これは「Lost in the Middle」問題として知られてて、長いコンテキストの中間部分にある情報は見落とされやすい

CLAUDE .md の設計でこれを活かすなら

- 最も重要な情報（プロジェクト概要、主要コマンド）をファイルの最初に置く
- 補足的な情報は後ろに回す
- 中間に長い説明を入れない

また、指示の数が増えると全体の従い方が均一に低下するという研究結果も重要。指示を 10 個から 20 個に増やすと、1 番目の指示も 20 番目の指示も同じように無視されやすくなる。だから「重要な指示だけを残す」んじゃなくて「指示の総数を減らす」ことが大事

AGENTS.md との関係

Claude Code 以外のツール（Cursor、Zed、Codex など）では、CLAUDE .md の代わりに AGENTS.md を使うことが多い。基本的な考え方は同じで、ここで解説したベストプラクティスはそのまま適用できる

ただし、ツールによって AGENTS.md の読み込み方や優先度が異なる場合があるから、使ってるツールのドキュメントも確認しておくとよい

トラブルシューティング

Claude が指示を無視する

- CLAUDE .md が長すぎないか確認（300 行以下が目安）
- 普遍的でない指示が混ざってないか確認
- 指示の総数を減らす
- 重要な情報をファイルの最初に移動

Claude が古い情報を使う

- CLAUDE .md 内のコードスニペットが古くなってないか確認
- コードスニペットを  参照に置き換える
-  コマンドで読み込まれてるファイルを確認

チームメンバー間で挙動が違う

- （個人設定）の内容を確認
-  の内容を確認
-  内のファイルを確認

まとめ

CLAUDE .md を効果的に書くためのポイントをおさらいしよう

1. LLM はステートレス: 毎回「初見」でコードベースを見るという前提を忘れない

2. WHY/WHAT/HOW を定義: プロジェクトの目的、構造、作業方法を簡潔に伝える

3. 指示は少なく: 研究によるとフロンティア LLM でも 150〜200 の指示が限界。Claude Code のシステムプロンプトで約 50 を使ってるから、残りは限られてる

4. 300 行未満を目指す: HumanLayer の実例は 60 行未満。情報を詰め込みすぎると、重要な指示ほど無視されやすくなる

5. 段階的開示: タスク固有の情報は  などに分離し、CLAUDE .md には参照ポイントだけを置く

6. コピーよりポインタ: コードスニペットではなく  で一次情報を指す

7. リンターの仕事をさせない: コードスタイルは Biome などの自動ツールに任せる

8. 自動生成を避ける:  は使わず、手動で慎重に作る。最重要ファイルだから

9. 定期的に見直す: プロジェクトの進化に合わせて更新する

CLAUDE .md が効く理由は、LLM が毎回「初見」でコードを見るから。重要なのは指示を書くことではなく、常に読む価値がある情報だけを残すこと。関係ない指示が増えるほど、全部まとめて無視されやすくなる

だから WHY/WHAT/HOW だけを最小単位で渡し、詳細は別ファイルに逃がす。これはプロンプトではなくコンテキスト設計の話なんよね

参考リンク

- [Writing a good CLAUDE .md | HumanLayer Blog](https://www.humanlayer.dev/blog/writing-a-good-claude-md)
- [Manage Claude's memory - Claude Code Docs](https://code.claude.com/docs/en/memory)
- [The Prompt Report: A Systematic Survey of Prompt Engineering Techniques](https://arxiv.org/abs/2406.06608)
- [A Survey of Context Engineering for Large Language Models](https://arxiv.org/abs/2507.13334)
- [Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models](https://arxiv.org/abs/2510.04618)
]]></content:encoded>
        </item>
    </channel>
</rss>