Hooks

概要 本ガイドは、個人 Obsidian Vault を Claude Code に統合し、AI Agent が個人ナレッジを 読み取り・書き戻し の両方向で活用する循環構造を実装する手順をまとめる。シリーズ 5 記事の実装ステップを 5 段階のロードマップに整理した、再現用ピラー（土台）ガイド。 5 段階ロードマップ ステップ 1: Vault の機密性に対応した接続方式を選ぶ 方式 接続スコープ 特徴 A. グローバル MCP -s user 全プロジェクト共通。個人プロジェクト中心の人向け B. プロジェクト local MCP -s local（デフォルト） .claude/settings.local.json に gitignored で書く。機密プロジェクトに向く C. symlink .claude/knowledge/ Vault サブセットを安定パスで取り込む。CLAUDE.md からの参照を一貫させる 推奨: 方式 B + C のハイブリッド。symlink で安定パスを提供し、検索・走査は MCP を使う。 1 2 3 4 5 6 mkdir -p <proj>/.claude/knowledge ln -s ~/Documents/ObsidianVault/topics/nextjs <proj>/.claude/knowledge/nextjs echo ".claude/knowledge/" >> .gitignore claude mcp add -s local vault-readonly -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault ステップ 2: CLAUDE.md と Skills を階層別に配置 ~/.claude/CLAUDE.md: 全プロジェクト共通の Vault 参照ルール <proj>/CLAUDE.md: プロジェクト固有の参照ポイント（「個人 Vault がない人でも壊れない逃げ道」を明示する） ~/.claude/skills/: Vault 横断スキル（vault-search, vault-daily-log, summary-back-to-vault） <proj>/.claude/skills/: プロジェクト固有のワークフロー（decision-log など） ステップ 3: 書き戻し（writeback）の安全設計 書き込み用 MCP を読み取り用と分離し、inbox/ にしか書けない よう物理隔離する。 ...

概要 Claude Code のフックは、エージェントのライフサイクル上の特定イベント（ツール呼び出し前後、応答終了、セッション終了など）でシェルスクリプトを発火させる仕組み。settings.json の hooks フィールドで定義する。フックは 直接エージェントを駆動できない（次のターンを発火できない）が、stdout の出力がエージェントの文脈に注入されるため、「フックは器を用意し、AI が中身を書く」という分業が成立する。 主なイベント イベント 発火タイミング エージェントへの指示 主な用途 PreToolUse ツール呼び出し直前 ✓ 危険なコマンドのブロック・引数の正規化 PostToolUse ツール呼び出し直後 ✓ stdout で次ターンに hint を渡せる 結果の通知・後続スキルの promote 通知 Stop アシスタントの応答が終わった瞬間（毎ターン） ✓ 直前のターンの成果に応じた追加作業の促し SessionEnd セッション終了時（1 回） ✗ もうエージェントは動かない 純粋な事後ログ・成果物のアーカイブ UserPromptSubmit ユーザープロンプト送信時 ✓ プロンプトの前処理・コンテキスト追加 SessionStart セッション開始時 ✓ 環境チェック・初期文脈の差し込み Notification 通知発火時 ✓ デスクトップ通知などへの中継 SubagentStop サブエージェント終了時 ✓ サブエージェント完了の伝播 PreCompact コンテキスト圧縮直前 ✓ 重要情報の退避 設定例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 // ~/.claude/settings.json { "hooks": { "PostToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "~/.claude/hooks/detect-pr-merge.sh" } ] } ], "Stop": [ { "hooks": [ { "type": "command", "command": "~/.claude/hooks/append-daily-log.sh" } ] } ] } } matcher はツール名（Bash, Write, Edit など）を正規表現で指定 フックは標準入力で JSON 形式のイベント情報を受け取る（tool_input.command, transcript_path など） 標準出力に書いた内容がエージェントの次ターンに hint として渡る Stop と SessionEnd の使い分け Stop: 会話継続中の hint。直前のターンで成果が出たとき、AI に追加作業（書き戻し本体など）を促す SessionEnd: 会話後の墓標。AI には頼めないので、純粋な事後ログ用途に絞る セキュリティ上の注意 settings.json のフック設定は 任意コード実行と等価 なので、信頼できないリポジトリの <proj>/.claude/settings.json を無批判に有効化しない stdout への過剰出力はエージェントの文脈を汚染する。promote 通知は 1〜3 行に抑える フックスクリプト本体のオーナー・権限を確認しておく 関連ページ Claude Code — フックの母体となる CLI Obsidian Vault Writeback Loop — フックの代表的な応用例 Claude Code × Obsidian 統合ガイド — 具体実装 ソース記事 Obsidian Vault 書き戻しの自動化 — 2026-05-18 GitHub Actions self-hosted runner で Obsidian Vault 書き戻しを完成させる — 2026-05-18

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

概要 Anthropic が開発する CLI ベースの AI コーディングエージェント。ターミナル上で対話しながらコードの読み書き、ファイル操作、git 操作、テスト実行などを行える。 主な特徴 CLI ネイティブ: ターミナルで直接対話（IDE 拡張版も提供） ツール統合: ファイル読み書き、Bash 実行、Grep/Glob 検索、Web 検索等 CLAUDE.md: プロジェクトごとのルール・設定ファイル（圧縮後も再読み込みされる） サブエージェント: 複雑なタスクを並列エージェントに委任可能 スキル/フック: カスタムワークフローの定義と自動化 コンテキスト管理 5段階の圧縮カスケードでコンテキストウィンドウを管理する: Microcompact → Context Collapse → Session Memory → Full Compact → PTL Truncation 詳細: コンテキスト圧縮 LLM Wiki との関連 Karpathy は Claude Code を LLM Wiki の実行環境として使用。「左画面に Claude Code、右画面に Obsidian」というワークフローを実践。 思考深度のサイレント・ダウングレード問題 2026年4月、AMD のシニア AI ディレクターが約 6,852 セッション分のログ分析で発見した問題。2026年3月8日以降、Claude Code の思考の中央値が約 2,200 文字から約 600 文字（67%減）に低下していた。Anthropic は「アダプティブ・シンキング」による変更を認め、/effort max コマンドで高い思考深度を維持できると説明した。 ...

Claude Code をインストールして「で、次どうすれば…？」となっていないだろうか。導入は単なる入口に過ぎない。フック、カスタムコマンド、サブエージェントの3つを使いこなすことで、Claude Code は「1人のAIアシスタント」から「自分専用の開発チーム」へと変わる。 この記事では、X で話題になった @wad0427 氏の記事「Claude Code、インストールしたけど「で、次どうすれば…？」ってなってない？」をベースに、それぞれの機能の概要と実践的な使い方を解説する。 フック（Hooks）— 自動化ルールを仕込む フックとは、「AIが〇〇したら、自動で△△を実行するルール」のことだ。 料理に例えると、「盛り付けたら、最後に必ずパセリを振る」と自分ルールを決めておく感じに近い。Claude Code では以下のような自動化が可能になる。 AIがファイルを保存したら → 自動でコードの見た目を整える（フォーマッター実行） AIがコードを書き換えたら → 自動でテスト（動作チェック）を走らせる AIの作業が終わったら → 自動で変更履歴を記録する（コミット） つまり、毎回「フォーマットして」「テストして」と指示しなくていい。フックを設定するには Claude Code のターミナルで /hooks と打つと設定画面が出る。選択肢を選んでいくだけなので、コードを書かなくても OK だ。 フックの設定例 プロジェクトルートの .claude/settings.json（またはユーザー設定の ~/.claude/settings.json）に以下のように定義する: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" } ] } ] } } この例では、AI がファイルを書き換えるたびに Prettier が自動実行され、コードスタイルが統一される。 ...

Claude Code や Codex といった AI コーディングエージェントを現場に投入する開発者が増えるなか、「ハーネスエンジニアリング」という新しい実践領域が注目を集めている。逆瀬川氏（@gyakuse）が公開したまとめ記事（読了 54 分）から、要点を紹介する。 そもそも「ハーネス」とは何か 「ハーネス（harness）」とは、もともと馬具の意味だ。馬の力を人間が制御して活かすための装具一式 — 手綱、鞍、轡（くつわ）などを指す。馬がどれだけ優秀でも、ハーネスなしでは暴走するだけで仕事にならない。 ソフトウェアの世界では「テストハーネス」という用語がすでにある。テスト対象のコードを「つなぎ止めて」、入力を与え、出力を検証する枠組みのことだ。テスト対象そのものではなく、テスト対象を正しく動かすための外側の仕組みを指す。 AI コーディングエージェントにおける「ハーネス」もこれと同じ発想だ。AI エージェント（= 馬）は強力だが、そのままでは暴走する。古いドキュメントを信じてしまう、リンターのルールを勝手に緩和する、前のセッションで何をしたか忘れる。エージェントを制御し、安定した成果を引き出すための外側の仕組み全体がハーネスであり、それを設計・構築する技術がハーネスエンジニアリングだ。 具体的にハーネスを構成する要素は、大きく 3 つの層に分けられる: 入力層 — エージェントに何を読ませ、何を読ませないかを制御する（AGENTS.md の設計、リポジトリの衛生管理、セッション間の状態引き継ぎ） 実行制御層 — エージェントの作業中にリアルタイムで品質を強制する（リンター・フォーマッターの自動実行、計画と実行の分離） 検証層 — エージェントの出力が正しいことを確認する（E2E テスト、プリコミットチェック） 核心的な洞察は「ハーネスがモデルより重要」という点だ。Morph の分析によると、同じモデルでもハーネスを変えると SWE-bench スコアが 22 ポイント変動するのに対し、モデルの交換では 1 ポイントしか変わらない。開発者の責任は「正しいコードを書く」から「エージェントが確実に正しいコードを生産する環境を設計する」へとシフトしている。 7 つの主要トピック 1. リポジトリ衛生 〈入力層〉 「衛生（hygiene）」は、ソフトウェア開発で「不要物や汚染を取り除き、健全な状態を保つ」という意味で使われる慣用表現だ（「コードハイジーン」「ブランチハイジーン」なども同様）。ここでは、リポジトリ内に古くなったドキュメントや不正確な情報が溜まらないよう清潔に保つことを指す。人間なら「このメモ、古そうだな」と判断できるが、エージェントは 3 ヶ月前のメモも最新のコードも同じ「事実」として読んでしまう。だから情報の鮮度管理が重要になる。 実行可能なアーティファクト（コード、テスト、設定）を優先する 説明的ドキュメントは腐敗しやすいため最小化する ADR（Architecture Decision Records）で決定履歴を保全する テストはドキュメントより腐敗に強い 最大の敵は「説明的ドキュメントの腐敗」だ。エージェントは「3 ヶ月前のメモ」と「現在の真実」を区別できないため、古い情報が存在するだけで性能が低下する。ハーネスの入力層として、エージェントが読む情報の鮮度と正確性を保つことが最初のステップになる。 2. 決定論的ツールで品質を強制する 〈実行制御層〉 「決定論的（deterministic）」とは、同じ入力に対して毎回必ず同じ結果を返すという意味だ。リンターやフォーマッターがその典型で、たとえば「未使用の変数がある」というコードを渡せば、何度実行しても必ず同じ警告を返す。気分や文脈によって判断が揺れることがない。 対照的に、LLM は非決定論的だ。同じコードを渡しても、実行するたびにチェックの粒度や指摘内容がブレる。「インデントを揃えて」と指示しても、ある時はスペース 2 つ、別の時はタブで揃えるかもしれない。 だからこそ、機械的に判定できるルール（構文エラー、未使用変数、フォーマット）は LLM に任せず、決定論的ツールに委ねるのが原則だ。 ここで重要なのが「ほぼ毎回」と「例外なく毎回」の差だ。CLAUDE.md に「リンターを実行せよ」と書くだけでは前者にとどまる。コンテキストウィンドウの消費が進むと、エージェントはリンターの存在を忘れてしまうからだ。Claude Code の Hook（特定のライフサイクルイベントで自動実行されるスクリプト）で強制すれば後者になる。 ...