Claude Code

概要 Obsidian Vault Writeback Loop は、AI Agent が個人ナレッジ（Obsidian Vault）を 読み取るだけでなく、得た学びをそこに書き戻して自己強化する 循環設計パターン。GitHub リポジトリに閉じた知識管理（プロジェクト型）に対して、Vault を中心に据えたネットワーク型のナレッジ管理を、Claude Code のフック・スキル・MCP・GitHub Actions self-hosted runner を組み合わせて実装する。 4 つの構成レイヤー レイヤー 役割 主な構成要素 読み取り Vault → AI Agent への文脈供給 symlink (.claude/knowledge/) + 読み取り用 MCP (vault-readonly) 書き戻し設計 AI Agent → Vault inbox への安全な投入 書き込み用 MCP (vault-inbox)、inbox-first 原則 書き戻しトリガ いつ書き戻すかの発火制御 Claude Code hooks（PostToolUse / Stop / SessionEnd）、Git post-merge 昇格 inbox → Vault 本体への統合 人間による週次レビュー（4 択フロー: 昇格 / 追記 / 保留 / 破棄） 設計原則 AI に Vault 正本を直接書かせない: リンク構造を壊さないよう、inbox/ にしか書かない 読み取り MCP と書き込み MCP をサーバ単位で分離: @modelcontextprotocol/server-filesystem は引数で渡したディレクトリしか公開しないため、サーバを分けるだけで構造的な物理隔離になる CLAUDE.md には安定パス（.claude/knowledge/）を書く: Vault の生パスをコミットしない 昇格判断は人間に残す: AI に自動昇格させると Vault が壊れる 書き戻し対象はリポジトリに収まらない知見だけ: コードや設計書はリポジトリの docs/ に置く 自動化レイヤーの段階導入 Claude Code PostToolUse フック — gh pr merge 直後に書き戻しを促す Claude Code Stop フック — Daily Note の器を自動作成 Git post-merge フック — GitHub UI マージ派の取りこぼし回収 Self-hosted runner + GitHub Actions — マシン起動中なら必ず走る最後の砦（Vault・Skills・MCP がフル活用可能） cloud-hosted Actions は Vault に書けない・Skills が使えない・会話文脈ゼロという三重苦のため、書き戻し用途では self-hosted runner に切り替えるのが正解。 ...

GitHubで全部完結する開発者にObsidianは本当に必要か？ では、Obsidian を併用する場合の「思想差」と「AI Agent に渡せる文脈の質」を整理しました。本記事はその実践編です。特定のプロジェクトで Claude Code セッションを行うときに、個人の Obsidian Vault を併用してエージェントに処理させるには、CLAUDE.md / Skills / Settings をどう階層管理すべきか を具体的な設定例で示します。 ポイントは次の3つです。 Claude Code の設定階層（global / project / local）を理解して役割分担する Vault は gitignored 層 で繋ぐ（リポジトリにパスを残さない） CLAUDE.md には安定パスを書く — Vault の生パスを書かない（symlink 経由で参照） Claude Code の3層構造を整理する まず大前提として、Claude Code の設定は 3 層あり、それぞれ用途が違います。 階層 主なファイル Git 管理 使いどころ Global (user) ~/.claude/CLAUDE.md / ~/.claude/skills/ / ~/.claude/settings.json 個人の dotfiles で管理（任意） 全プロジェクト共通の個人スタイル・横断スキル Project <proj>/CLAUDE.md / <proj>/.claude/skills/ / <proj>/.claude/settings.json / <proj>/.mcp.json リポジトリにコミット プロジェクト固有の規約・公開してよい設定 Local <proj>/.claude/settings.local.json .gitignore で除外 Vault パスなど個人秘匿情報を置く claude mcp add の --scope（-s）オプションも、これと同じ 3 値を取ります（local / user / project）。重要なのはデフォルトの挙動です。 ...

Claude Code から個人 Obsidian Vault に「書き戻す」設計 では、書き戻しの設計パターンとして summary-back-to-vault スキル / Daily Note 追記 / ADR 二重書きの 3 つを示しました。本記事はその続編で、書き戻しを自動化する仕組みを扱います。 スキルを作ったとしても、毎回 /summary-back-to-vault と手で打つのは続きません。トリガを自動化しない限り、書き戻しは「気が向いたときだけ」になり、Vault は古びます。本記事では Claude Code のフック・Git のクライアントフック・GitHub Actions の 3 方式を、それぞれが拾えるトリガと文脈の違い に着目して整理します。 自動化候補の俯瞰 書き戻しを発火させる場所は大きく 3 つあります。 方式 トリガ位置 セッション文脈 適性 Claude Code hooks（PostToolUse, Stop, SessionEnd 他） セッション内、ツール呼び出し前後 ✓ 会話履歴・スキル・MCP がすべて生きている AI Agent と最も相性が良い Git クライアントフック（post-merge, pre-push など） クライアント側、git pull / git push 等 ✗ PR の diff だけ Vault が Git リポジトリ化されている人向け GitHub Actions サーバ側、pull_request: closed 等 ✗ PR メタデータのみ マシンを開いていなくても回したい場合 書き戻しに必要な「会話の文脈（なぜそう判断したか／どこで詰まったか）」を保てるのは Claude Code フックだけです。Git フックや Actions は PR の diff と説明文しか見えないため、サマリの「中身の濃さ」が大きく落ちます。これが本記事の核心です。 ...

はじめに 「AIにコードを書かせるのは得意になったが、完成品が要件とずれていて全部作り直しになった」——そんな経験はないだろうか。 Vibe coding（感覚的なプロンプトだけでAIにコーディングさせるスタイル）は手軽な反面、AIとの認識齟齬が後から発覚してリワークが発生するリスクをはらんでいる。 OpenSpec は、その問題を「仕様駆動開発（SDD: Spec-Driven Development）」で解消するフレームワークだ。2025年8月に登場してから急速に普及し、2026年5月時点で⭐50,000超を獲得している。 GitHub: Fission-AI/OpenSpec npm: @fission-ai/openspec ライセンス: MIT Vibe Codingの落とし穴 AIコーディングアシスタントは非常に強力だが、要件がチャット履歴の中にしか存在しない場合、出力は予測不能になりやすい。よくある失敗パターンは次のとおり。 「ざっくり作って」と頼んだら意図と全く異なる設計になった 途中で要件変更を伝えたら、AIが古い前提を引きずった 長いセッションでコンテキストが失われ、最初の仕様が無視された OpenSpecはこれを「コードを書く前にAIと仕様に合意する」プロセスを導入することで防ぐ。 OpenSpecとは OpenSpecは、AIコーディングアシスタント向けの軽量な仕様レイヤーを提供するフレームワーク。プロジェクトに openspec/ ディレクトリを作り、変更ごとに proposal・specs・design・tasks の4つのアーティファクトを生成・管理する。 設計哲学: 1 2 3 4 5 → fluid not rigid （柔軟、固定フェーズなし） → iterative not waterfall （反復的、ウォーターフォールではない） → easy not complex （シンプル） → built for brownfield （既存プロジェクトにも対応） → scalable from personal projects to enterprises 主要コマンド（/opsx:* スラッシュコマンド） OpenSpecは /opsx:propose から始まる一連のスラッシュコマンドで動作する。 ...

背景: 日本語の「言語税」をどこで払うか 先日の記事で、日本語入出力が英語比 1.48 倍のトークンを消費すること、Claude では最大 1.94 倍にもなることを取り上げた。 しかし現実問題、ブログ記事本文・コミットメッセージ・GitHub PR の説明・許可プロンプトなど、最終アウトプットが日本語であること自体が要求であるケースは避けられない。Claude Code を使い続ける限り、日本語コストはゼロにはならない。 問いを言い換えると、こうなる: 「日本語境界を保ったまま、実トークン消費を構造的に減らせる場所はどこか？」 検討した 5 案 案 仕組み 効く場面 弱点 A. 翻訳プロキシ (Ollama) ユーザー入力 ja→en、Claude 応答 en→ja を中間 LLM が翻訳 「思考・指示が日本語で出来ればよい」用途 ツール結果・ファイル内容・git diff まで翻訳経路に入り破綻 B. 部分英語化 思考・指示は英語、最終成果物は日本語のまま 大半の開発作業 削減率は応答側ほど効かない C. Prompt Caching 徹底 CLAUDE.md・Skills・MCP 出力をキャッシュ 日本語のまま実コストを大幅削減 設計工数が必要 D. Caveman プロンプト 「原始人みたいに喋れ」で日本語応答を圧縮 既存実績手法（最大 80% 削減） 文体が崩れるので公開記事には不向き E. モデル切替 Gemini など日本語効率の良いモデルへ部分委譲 翻訳・要約などコモディティ作業 Claude のハーネス連携を捨てる 翻訳プロキシ案 (A) が筋悪な理由 「ローカル LLM で Claude Code の入出力を翻訳する」というアイデアは一見魅力的だが、Claude Code は対話 AI ではなく エージェント環境 であることを思い出す必要がある。 ...

症状 blog-batch.sh で夜間バッチを回した結果、こんな状態になっていた: 同じ wiki ファイル（content/wiki/concepts/harness-engineering.md、content/wiki/tools/claude-code.md）が複数の blog PR で同時に変更されていた main にマージしようとすると毎回コンフリクト 直近の #368・#369・#371・#372 はすべてこの原因で手動コンフリクト解消が必要だった 調査して原因が判明したので、修正内容と「LLM スキルを書くときに気をつけるべきポイント」を共有する。 PR の中身を見ると 3 コミットあった 通常の /blog で作った PR は「記事 1 本分の 1 コミット」のはずだが、見ると 3 コミットあった: 1 2 3 35a61c2 Add blog post: トレーダーのSランクスキル5選... 86e5bd4 Update wiki-last-ingest.txt: mark all posts through 2026-05-07 as ingested 0bc4e1f Update Wiki: ingest posts 2026-04-15 through 2026-04-21 (5 updated, 16 new pages) 2 つ目と 3 つ目は wiki ingest の結果コミット。これが各 blog PR に混入していて、複数 PR で同じ wiki ファイルを並行更新 → コンフリクトという流れ。 ...

結論を先に CLAUDE.md と 4 つの SKILL.md を日本語から英語に書き換えた結果、毎セッション読み込まれる固定資産のトークン量が 13,538 → 8,441（-37.6%、絶対値で 5,097 トークン削減） になった。 文字数は逆に +49% 増えているのに、トークンは大幅に減るという一見矛盾した結果である。理由と内訳を以下に示す。 背景 CLAUDE.md 英語化の記事 と Skills 英語化 PR (#394) の続編。 前 2 つの作業で、ハーネスの「内側」（LLM だけが読む固定資産）を英語化し、「外側」（人間が読むブログ記事や許可プロンプト）は日本語のまま維持する部分英語化パターンを実装した。 ただし、その記事では「Anthropic 公開の日本語比率 1.94x」から 推定 48% 削減 とラフに見積もっていた。実際の効果は推定モデル次第で 2% 〜 48% と幅があり、本当の値を知るには実測しかない。 計測手法 tiktoken (cl100k_base) を採用 理由: オフラインで動く、API key 不要、結果が再現可能 限界: Anthropic Claude のトークナイザーではなく OpenAI GPT-4 系。ただし日本語のトークン化挙動は近似として広く使われる 対案: Anthropic SDK の count_tokens API が最も正確だが、API キーが必要 venv で隔離 PEP 668 で system Python が保護されているため、.claude/temp/venv-tiktoken/ に隔離した venv を作って tiktoken だけ入れた。 ...

TL;DR Redis 作者の Salvatore Sanfilippo（antirez）が、DeepSeek V4 Flash 専用のローカル推論エンジン ds4 (DwarfStar 4) を公開した（公開から数日で 7,700+ stars） Apple Silicon の Metal と Linux の CUDA をターゲットにした C 実装。GGML/llama.cpp にはリンクせず、DeepSeek V4 Flash 一本に特化した「narrow bet」設計 公式ベンチで Mac Studio M3 Ultra 512GB / Q4 / 12k context で 26.62 token/sec、Q2 なら 96/128GB の MacBook でも動作 OpenAI 互換 + Anthropic 互換 API を持ち、Claude Code から ANTHROPIC_BASE_URL を差し替えるだけでローカルモデルとして使える KV キャッシュをディスクに永続化するなど、ローカル推論の常識を更新する設計思想が随所に光る 実運用報告では コンテキスト 100K → 1M、KV ディスク 8GB → 64GB に拡張して Think Max モードを Claude Code 上でアンロック した例も登場 きっかけ: 「ds4 凄すぎるな」というツイート きっかけは @m_sigepon 氏のツイートだった。 ...

Claude Code をはじめとする AI エージェントの運用で 「シークレットをどこにどう置くか」 は避けて通れない設計判断になります。Git リポジトリに暗号化したまま置ける SOPS（旧 Mozilla SOPS、現在は CNCF Sandbox プロジェクト）は GitOps と相性がよく、小〜中規模のチームや個人開発では有力な選択肢の一つです。 ただし、シェルやファイル操作の権限を持つ AI エージェントと組み合わせる場合、「AI が自分で復号して中身を覗き見・漏洩させない」 ための3つのガードレール設計が前提になります。本記事では SOPS のメリットと AI エージェント特有のリスク、そして推奨構成をまとめます。 SOPS を AI エージェント運用で使うメリット SOPS は「Git リポジトリに暗号化したまま秘匿情報を保存できる」シンプルなツールです。AWS KMS、GCP KMS、Azure Key Vault、age、PGP など、環境に合わせた暗号化バックエンドを選べます。 AI エージェントとの相性で見ると、特に次の3点でメリットがあります。 構成管理の簡素化 — 開発環境（.env など）とデプロイ環境の秘密情報を、同じ Git ワークフローで一貫管理できる diff が読みやすい — SOPS は YAML / JSON の 値だけを暗号化 し、キー（変数名）は平文で残せるため、AI エージェントが「どんな設定項目があるか」を構造として理解できる 柔軟なバックエンド — クラウド KMS から手元の age キーまで、用途に応じて使い分けられる 特に「キー名は平文・値だけ暗号化」という設計は、AI エージェントに「設定の存在は知らせるが値は見せない」運用と非常に親和性が高い構造です。 なお、マネージド型のクラウドサービスでシークレットを集中管理したい場合は、Infisical のような選択肢もあります。「Git で持つか／サービスで持つか」は採用判断のポイントになります。 AI エージェント特有のリスク 一方で、Claude Code のように Bash 実行権限を持つエージェントに SOPS を扱わせると、以下のリスクが顕在化します。 ...

Anthropic で Claude Code を担当するエンジニア Thariq Shihipar（@trq212）が X に記事「Using Claude Code: The Unreasonable Effectiveness of HTML」を投稿しました。公開からわずか16時間で440万ビュー・8,200いいね・15,700ブックマークを集め、開発者コミュニティで大きな議論を巻き起こしています。 その主張は一言で言えば「HTML is the new Markdown」。AI が出力するフォーマットとして、もう Markdown に縛られる必要はない、というものです。 背景：なぜ今 HTML なのか Markdown が AI 出力の事実上の標準になったのは GPT-4 の時代、コンテキストウィンドウが小さくトークン節約が最優先だったころの話です。 現在の LLM は百万トークン超のコンテキストを扱えます。トークン効率という制約が事実上消えたいま、出力フォーマットとして HTML を選ばない理由はほとんどありません。 Thariq はこの変化を踏まえ、Claude Code に依頼する成果物の多くを HTML で生成するよう切り替えました。その体験をまとめた記事と、20 の実例サイト を公開したのが今回の反響の発端です。 HTML が Markdown より優れている 5 つの理由 1. 情報密度（Information Density） HTML はテーブル・SVG・CSS・JavaScript・画像・インタラクションを 1 つの自己完結ファイルに収められます。Markdown には構造的な限界があり、複雑な情報表現には向きません。 2. 読みやすさの閾値（Readability Threshold） 「100 行を超える Markdown ファイルをちゃんと読んでいる人はほとんどいない」 HTML であればタブ切替・折りたたみセクション・レスポンシブレイアウトを使い、長大なドキュメントを人が実際に読める形にできます。 3. 共有の効率（Sharing Efficiency） ブラウザは HTML をそのままレンダリングします。Markdown ファイルは受け取った側が変換ツールを介さないと読めませんが、HTML は URL を共有するだけで即座に読める状態になります。 ...