Claude Code

Claude Code でコーディングする時間が増えると、ふと気づくのが「VSCode って、けっこうメモリを食うな」という事実です。プロジェクトを 5 つも同時に開けば、エディタだけでメモリがカツカツになります。 note の記事「GhosttyをVSCodeみたいにしよう！」（Naoki | 電電猫猫 氏）では、まさにこの悩みを起点に、高速なターミナルエミュレータ Ghostty の上に VSCode 風の開発環境を再現する構成が紹介されていました。本記事ではその考え方を整理しつつ、使われている TUI ツール群を補足して紹介します。 なぜターミナルで VSCode を再現するのか VSCode の基本的な画面構成はだいたいこうなっています。 左サイドバー：ファイル一覧と Git のツリー表示 右側メイン：エディタ（または Claude Code）と、その下にターミナル 便利な一方で、Electron ベースの VSCode は 1 ウィンドウあたりのメモリ消費が大きく、プロジェクトを並行して開くほど重くなります。そこで「同じレイアウトを、軽量なターミナル上で組めないか？」という発想に至ります。 Ghostty は Mitchell Hashimoto 氏が開発する GPU アクセラレーション対応のターミナルエミュレータで、標準で画面分割（split）機能を持っています。この分割機能と、小さな TUI ツールを LEGO のように組み合わせることで、VSCode のレイアウトをそのまま再現するというのが今回のアプローチです。 前提：以降の手順は Rust の cargo と Ghostty がインストール済みであることを前提にしています。FileTree・keifu・zellij はいずれも cargo install で導入できます。 各パーツの役割は次のとおりです。 サイドバー（細い列）：上に FileTree、下に keifu メイン領域（広い列）：上に Claude Code / エディタ、下に ターミナル 高頻度で触るプロジェクトは zellij のセッションとして保存しておく FileTree — VSCode 風のファイルツリー TUI FileTree は、VSCode のファイル一覧をターミナル上で模倣した TUI ファイルエクスプローラです。記事の著者（電電猫猫 氏 = Naoki Takahashi 氏）自身が作ったツールで、Vim キーバインドに対応した高速・軽量なファイルブラウザになっています。 ...

はじめに X（旧 Twitter）でこんな投稿が流れてきました。 【衝撃】Claude Code でとんでもないモードが解禁👀 Opus 4.8 ＋ /ultracode で有効になる新機能「Dynamic Workflows」！ ・タスク難易度を自動検知 ・オーケストレーション用スクリプトを生成 ・複数エージェントに役割分担 ・検証フローまで自動構築 ・エージェントスウォームで並列実行 つまり開発フローの全工程を Claude が自走。 「人間はゴールを投げるだけ、Claude Code が PM ＋ 開発チームを自動編成して並列実行する」——確かにインパクトのある話です。 ただ、こういうバイラル投稿は機能を過度に一般化しがちです。本記事では、/ultracode と Dynamic Workflows の実体を公式ドキュメントと実機の挙動から整理します。そのうえで「本当に変わること」と「誇張されていること」を切り分けます。結論から言うと、機能はほぼすべて実在しますが、“完全自動” ではありません。 Dynamic Workflows とは何か Dynamic Workflows は、Claude Code が複数のサブエージェントを JavaScript スクリプトで決定論的にオーケストレーションする機能です。現在は research preview（研究プレビュー）として提供されています。 ポイントは「決定論的」という部分です。通常のエージェントはモデルが自分の判断で次の手を決めますが、Workflow ではループ・分岐・ファンアウト（並列展開）といった制御フローをスクリプトで明示的に記述します。「何を並列にやるか」「何を検証するか」「何を統合するか」を人間（あるいは Claude）がコードとして固定できるわけです。 スクリプトは export const meta = {...} で始まり、本体で以下のような構成要素を使います。 phase(title) — フェーズ（工程）を区切る agent(prompt, opts) — サブエージェントを 1 体起動する parallel(thunks) — 複数タスクを並列実行する（全完了を待つバリア） pipeline(items, stage1, stage2, ...) — 各アイテムを複数ステージに流す（ステージ間でバリアなし） これらは実際の Workflow ツールが提供する API です。最小の例を見てみましょう。 ...

grill-me とは何か mattpocock/skills は、Total TypeScript で知られる Matt Pocock が自分の ~/.claude/skills/ から実際に使っている 23 本のスキルをそのまま公開したリポジトリだ。「教材向けに整えた」ではなく「本番運用している実物」というのが特徴で、X（旧 Twitter）でも注目を集めている。 その中でも最も人気が高いのが /grill-me だ。スキルの定義は英文 4 文だけ。しかしこの短さが本質で、「コードを 1 行も書く前に AI があなたを徹底的に詰める」という仕組みを実現する。リポジトリには engineering・productivity・misc の 3 カテゴリにわたる 18 本以上のスキルが収録されている。 実際のスキル定義（skills/productivity/grill-me/SKILL.md）は次のとおり： 1 2 3 4 5 6 7 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead. なぜ「詰め」が必要なのか 生成 AI にコードを書かせる際の最大の落とし穴は、曖昧なまま走り出すことだ。「なんとなくこういうのを作りたい」で投げると、それらしいコードは出てくるが、後から要件とのズレが発覚して作り直しになる。 ...

Anthropic の研究・プロダクトチーム（Barry Zhang・Mahesh Murag）が、2025年11月の AI Engineering Code Summit で衝撃的な発言をした。 「Agents をやめて、Skills に全振りした」 Agent ツールを実際に開発してきた当事者が、この言葉を口にした意味は重い。単なる命名変更ではなく、AI 自動化の設計哲学そのものが変わった瞬間だ。 この記事では、なぜ Anthropic が Agents から Skills へシフトしたのか、その背景と技術的な理由、そして今すぐ自分のワークフローに活かせるポイントを解説する。 Agents の限界 — 何が問題だったのか 従来の「Agent」アプローチの核心は、中央集権型オーケストレーターだった。1 つの LLM が多数のツールを持ち、あらゆるタスクに対応しようとする構成だ。具体的には以下の 4 点が問題になった。 ツールオーバーロード: ツール数が増えるほど、LLM はどのツールを使うべきか判断しにくくなる 再現性の低さ: 複雑なシナリオで中央オーケストレーターが混乱し、同じ入力に対して異なる結果が出やすい モデル依存: Claude 専用に設計された Agent は、他のモデルでは動かない コンテキスト肥大化: すべての能力を一度にロードするため、トークンが無駄に消費される Barry Zhang と Mahesh Murag はこれらの問題を実装レベルで体験し、「根本から再設計が必要だ」という結論に至った。 Skills とは何か — Agent との本質的な違い Skills は、Claude Code の拡張機能の単位だ。SKILL.md と必要なスクリプト・設定ファイルを 1 つのフォルダにまとめて定義し、必要なときだけオンデマンドでメイン会話コンテキストに注入される。 観点 Agents Skills 設計思想 中央集権型オーケストレーター モジュラー・再利用可能な能力単位 モデル対応 Claude 専用 Claude + 他モデル両対応 実行コンテキスト 独立した隔離環境 メイン会話内（記憶・フォローアップが可能） ロード方式 常時ロード オンデマンド（トークン節約） 再現性 複雑なシナリオで低下しやすい 実用レベルで高い 最も重要な変化はモデル非依存になったことだ。Anthropic は 2025年12月に Skills をオープンスタンダードとして agentskills.io で公開し、Microsoft/VS Code・OpenAI・Cursor・GitHub・Google Gemini CLI・JetBrains Junie など主要プラットフォームが採用済みだ。Claude だけでなく、他のモデルでも同じスキルが動作する。 ...

AIに「作らせる」だけでは足りない時代 AIコーディングツール（Claude Code、Codex、Cursor など）を使う際、多くの開発者が次のプロンプトで止まってしまっている。 1 2 3 「作って」 「修正して」 「いい感じにして」 これで機能は動く。しかし、後から「なぜそうなったのか」が一切わからない。 Claude Code Studio（@ClaudeCode_love）が紹介した、Anthropic 社員が使っているとされるプロンプトは、その問題に真正面から切り込んでいる（公式声明ではなく、あくまで伝聞である点に注意）。 Anthropic 社員が使うプロンプト 元ツイート（2026-05-19）では「自分がいちばん使っているプロンプト」として次の指示が紹介されている。 1 2 3 仕様書通りに実装して。 その途中で、仕様書に書かれてなかった判断・変更・妥協点・意思決定を、 全部 implementation-notes に残して 英語で書くなら次のようになる。 1 2 3 Implement according to the specification. Along the way, record every judgment, change, trade-off, and decision not covered by the spec into implementation-notes. 一見地味に見えるが、これは AI コーディングの本質を突いたプロンプトだ。本記事では、このプロンプトを 「計画レビュー」と対比する形で深掘り し、なぜ AI コーディング時代に implementation-notes パターンが支配的になるのかを考察する。 ...

概要 本ガイドは、個人 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

Obsidian Vault を Claude Code に繋ぐ実践編 では、読み取り側（Vault → プロジェクト）の設定パターンを整理しました。本記事はその続編で、書き戻し（writeback）側（プロジェクト → Vault）の設計を扱います。 ここを設計しないと、Vault は「過去の自分が書いたノート集」のまま古びていきます。プロジェクトで詰まったこと・学んだこと・設計判断の根拠が Vault に還流して初めて、AI Agent が「3 ヶ月前のあの話、応用できないか？」を提案できるようになります。 書き戻し設計で外せない3つの原則 具体的なパターンに入る前に、絶対に外せないルールを確認します。 AI に Vault の正本（topics/ や projects/ の本文）を直接書かせない Obsidian の [[リンク]] 構造とノート間の整合は、人間が編集してきた歴史の積み重ねです。AI に直接書かせると、リンク切れ・重複ノート・タグ揺れが一気に発生します。 inbox/ を必ず噛ませる AI は ~/Documents/ObsidianVault/inbox/ にしか書かない。inbox/ は「下書き置き場」と割り切り、人間が後で内容を吟味して Vault 本体に統合します。 書き戻す対象は「リポジトリに収まらない知見」だけ コードや設計書はリポジトリの docs/ に書きます。Vault に書くのは、プロジェクトを跨いで再利用される可能性のあるメタ知識 だけです。 つまり「AI が inbox/ に下書きを溜める → 人間が週次レビューで Vault 本体に統合する」という二段階フローを基本形にします。AI は下書き工場、人間は編集長、という分業です。 permissions と MCP の分離設計 書き戻しを安全に行う最大のコツは、読み取り用 MCP と書き込み用 MCP を別サーバとして分離する ことです。前作で触れた permissions 設計 を一段深めます。 1 2 3 4 5 6 7 # 読み取り専用ルート: Vault 全体を grep / Read できるが書き込みは禁止したい claude mcp add -s local vault-readonly -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault # 書き込み用: inbox/ 限定で AI が書ける claude mcp add -s local vault-inbox -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault/inbox これに加えて、<proj>/.claude/settings.json 側で symlink 越しの書き込みを禁止しておきます（前作で作った <proj>/.claude/knowledge/ — Vault のサブセットを symlink した読み取り専用ディレクトリ — を経由する書き込みを塞ぐ目的）。 ...

Obsidian Vault 書き戻しの自動化 では、3 方式（Claude Code hooks / Git クライアントフック / GitHub Actions）の使い分けをまとめました。そこで「GitHub Actions は会話文脈が失われる・Vault に書けない」と書きましたが、これは cloud-hosted runner を前提にした話です。self-hosted runner（GitHub の job を手元のマシンで実行する仕組み）に切り替えると、その制約が一気に外れます。 本記事では、自宅 Mac を self-hosted runner にして、PR マージのイベント駆動で claude -p を ローカル文脈（Vault・Skills・CLAUDE.md・MCP サーバ）の中で動かし、Vault に直接書き戻す構成を解説します。ここでの「ローカル文脈」は 対話履歴ではなく、ファイルシステムに永続化された個人資産のセット を指す点に注意してください。シリーズ 5 部作の最終ピースです（思想編 → 読み取り側 → 書き戻し設計 → フック自動化 → self-hosted runner）。 なぜ self-hosted runner が正解になるか cloud-hosted Actions の最大の弱点は次の 3 点でした。 Vault が手元のファイルシステムにあるので、cloud runner からは見えない ローカルの MCP サーバ（vault-readonly / vault-inbox）に接続できない ローカルの Skills や CLAUDE.md が読めず、/summary-back-to-vault を呼べない self-hosted runner は「ジョブは GitHub のイベント駆動で立ち上がるが、実体は手元のマシンが処理する」というハイブリッドです。3 つの弱点がすべて解消します。 ...

開発者にとって、GitHubは事実上の「最強のナレッジベース」になりつつあります。Issue・PR・Wiki・Markdown ドキュメント — 仕事に必要な情報のほとんどがリポジトリの中で完結しており、コードの近くにドキュメントを置く「Docs as Code」のスタイルは、エンジニアリングとして極めて洗練されています。 それでも 2026 年に入ってから、「AI Agent + Obsidian」の組み合わせが開発者コミュニティでホットになり続けています。GitHub で完結しているなら無理に Obsidian を入れる必要はないはずなのに、なぜこれほど話題になるのか。本記事ではその違いを、特に AI Agent に渡せる「文脈の質」 という観点から整理します。 結論を先に書くと、すべてが構造化された「プロジェクト」単位で完結していて、現状の運用にストレスがないのであれば、無理に Obsidian を導入する必要はありません。ただし、「プロジェクトを跨いだ伏線回収」を AI にやらせたい瞬間が来ると、思想の違いが効いてきます。 GitHub方式とObsidian方式の決定的な違い 最大の違いは、情報の「繋がり方」の思想です。 比較軸 GitHub方式（プロジェクト管理型） Obsidian方式（ネットワーク型） 情報の構造 ディレクトリ構造（階層型・縦割り） グラフ構造（網の目型・横断的） 主な単位 リポジトリ / Issue / PR / Wiki ノート（アイディア、ファクト、ログなど） AIとの相性 コンテキストがプロジェクト内に閉じる プロジェクト間を跨いだ「点と点の結合」が得意 向いている情報 目的・ゴール・成果物が明確なもの 抽象的なアイディア、長期的な知見、個人の備忘録 検索の単位 リポジトリ単位の全文検索 Vault 全体のリンク・タグ・全文検索 GitHub は「プロジェクトという箱」に閉じることで一貫性と版管理を担保します。Obsidian は「ノート」というアトミックな単位を Vault 全体にフラットに置き、[[リンク]] で網の目を作ることで横断性を担保します。どちらが優れているという話ではなく、扱う情報の性質によって適切な箱が違うだけです。 「プロジェクトの壁」を越える横断性 GitHub はリポジトリごとに境界線がはっきり分かれています。これは「コードと文脈をセットで版管理する」目的にはとても合っていますが、知識の再利用にはコストがかかります。 GitHub の場合: プロジェクト A で得た「Next.js の認証に関する知見」は、リポジトリ A の docs/ か Wiki か Issue 内コメントに残ります。プロジェクト B を始めたときにそれを再利用するには、「どこに書いたか」を思い出して検索しに行く必要があります。複数リポジトリを横串で検索したい場合は gh search code などに頼ることになります。 Obsidian の場合: 「Next.js の認証」という独立したノートを作っておき、プロジェクト A からも B からもリンクを貼ります。情報がプロジェクトに属するのではなく、知見そのものが独立して進化していく点が決定的に違います。 つまり、GitHub は「プロジェクトに紐づく情報」を蓄積するのに最適で、Obsidian は「プロジェクトから独立した知見」を蓄積するのに最適だ、と整理できます。 ...