Claude Code × Obsidian Vault で作る「何でも相談」プロジェクト ― フォルダ構成・CLAUDE.md・MCP設定まで全公開
2026-04-29 追記: 初稿から約2週間運用した結果、スキル体制・MCP構成・CLAUDE.md の中身がかなり変わりました。各セクションに取消線+追記で差分を残しています。
2026-05-18 追記: モデルを Sonnet 4.6 に変更・
effortLevel削除・フック2本追加(機密ファイル保護 / frontmatter チェック)・claude-code-setupプラグイン追加。各セクションに取消線+追記で差分を残しています。
はじめに
Claude Code を使い始めて少し経つと、多くの人が同じ問題にぶつかります。
- Claude が生成した
.mdがプロジェクトルート直下に散乱する - 「あの調査メモどこ行った?」が週1で起きる
- Mac と Windows を行き来するたびにパス問題でつまずく
この記事では、私が実際に運用している「何でも相談-pj」という Claude Code 専用プロジェクトの中身を、フォルダ構成・CLAUDE.md・.claude/settings.json・.mcp.json まで全部公開します。Obsidian の Vault をプロジェクトに内包することで、Claude Code の成果物を自動で整理し、さらに後から Obsidian のグラフビューで知識を俯瞰できる、という構成です。
対象読者:Claude Code を使い始めた〜中級者。Obsidian は未経験でも OK。
プロジェクト全体像
まず設計の軸になっている3つの原則を先に書きます。この3つが全ての構成判断を支えています。
- 成果物は全部 Obsidian Vault に入れる(プロジェクトルートには散らかさない)
-
置き場ルールは
CLAUDE.mdに書いて Claude 自身に守らせる(人間が毎回指示しない) - Mac と Windows を USB/ZIP で行き来できるポータブル設計(Git 同期は使わない)
フォルダの全体像はこうなっています。
2026-04-29 更新: スキルが7つに増え、coding/ 配下にも実際のプロジェクトが育ってきました。
何でも相談-pj/
├── README.md # 初回セットアップ手順
├── CLAUDE.md # プロジェクト指針(大幅拡充済み)
├── .mcp.json # MCP設定(AWS Docs + NotebookLM)
├── .claude/
│ ├── settings.json # model / effortLevel など
│ ├── settings.local.json # 許可リスト(個人用)
│ └── skills/ # カスタムスキル ×7
│ ├── obsidian-markdown/ # 必須: Obsidian記法の自動適用
│ ├── humanizer/ # 必須: AI臭さ除去(29パターン)
│ ├── note-article-writing/ # note.com 記事執筆
│ ├── obsidian-bases/ # .base データベースビュー
│ ├── json-canvas/ # .canvas ビジュアルキャンバス
│ ├── obsidian-cli/ # Obsidian CLI 操作
│ └── defuddle/ # Webページ→Markdown抽出
└── obsidian-vault/ # Obsidian Vault ルート
├── .obsidian/ # Obsidian 設定ごと持ち運び可能
├── daily/ # デイリーノート YYYY-MM-DD.md
├── coding/ # コーディング相談・実プロジェクト
│ ├── project-a/ # クラウドリソース管理ツール
│ ├── project-b/ # データベース移行調査
│ │ └── reports/ # スクリプト実行結果
│ ├── project-c/ # コンテンツ生成ツール
│ ├── project-d/ # サーバ構築スクリプト
│ └── project-e/ # Webサイト
├── research/ # 技術調査・学習メモ
├── docs/ # ドキュメント下書き・成果物
├── references/ # 参考資料・URL・PDF等
└── archive/ # 終了した相談のアーカイブ
初稿時点のフォルダ構成(参考)
何でも相談-pj/
├── README.md # 初回セットアップ手順
├── CLAUDE.md # プロジェクト指針(Claude Code が自動読込)
├── .mcp.json # プロジェクト固有のMCPサーバ設定
├── .claude/
│ ├── settings.json # model / effortLevel など
│ ├── settings.local.json # 許可リスト(個人用)
│ └── skills/
│ └── note-article-writing/ # プロジェクト固有のカスタムスキル
└── obsidian-vault/ # Obsidian Vault ルート
├── .obsidian/ # Obsidian 設定ごと持ち運び可能
├── daily/ # デイリーノート YYYY-MM-DD.md
├── coding/ # コーディング相談・サンプル
├── research/ # 技術調査・学習メモ
├── docs/ # ドキュメント下書き・成果物
├── references/ # 参考資料・URL・PDF等
└── archive/ # 終了した相談のアーカイブ
CLAUDE.md と README.md だけプロジェクトルートに残しています。これは Claude Code が起動時にこの2ファイルを自動で読むため、Vault の中に入れてしまうと参照されない、という理由です。
2026-04-29 更新: プロジェクトルートに残すファイルは CLAUDE.md、README.md、.mcp.json の3つです。.mcp.json は Claude Code がプロジェクトルートから読み込む MCP サーバ設定ファイルなので、Vault 内に移動すると接続が壊れます。ファイル整理をした際にこの例外を CLAUDE.md にも明記しました。
フォルダ構成とサブフォルダの役割
obsidian-vault/ をプロジェクトに内包しているのがこの構成の肝です。Claude Code の作業ディレクトリはプロジェクトルート(何でも相談-pj/)のままなので、.claude/ や .mcp.json はちゃんと認識される。一方で、ノート・成果物はすべて Vault 配下に入る。
サブフォルダ6つの役割を表にまとめました。
| フォルダ | 用途 | 命名規則 |
|---|---|---|
daily/ |
デイリーノート・作業ログ | YYYY-MM-DD.md |
coding/ |
コーディング相談・サンプル・レビュー対象 | <トピック>/... |
research/ |
技術調査・学習メモ | YYYY-MM-DD-トピック.md |
docs/ |
ドキュメント下書き・成果物 | <ドキュメント名>.md |
references/ |
参考資料・URL集・PDF |
links.md / <資料名>.pdf
|
archive/ |
終了した相談のアーカイブ | YYYY-MM/<元のパス> |
ポイントは archive/ の運用で、月単位フォルダ(archive/2026-04/ など)に元のフォルダ構造ごと移動します。こうすると Vault ルートが常に最小化されつつ、過去の文脈を辿りたい時に元の階層のまま見つけられる。
CLAUDE.md に置き場ルールを書く
ここがこの記事で一番伝えたいところです。
CLAUDE.md はプロジェクトごとの指示書として機能します。多くの人は「コーディング規約を書く場所」として使っていると思いますが、私はファイル配置の自動化装置として使っています。
たとえば私の CLAUDE.md にはこんな表が書いてあります。
## フォルダ構成とデフォルト置き場ルール
新規ファイルを作る際は、内容に応じて以下のフォルダに配置してください
(絶対にプロジェクトルートや Vault ルートに散らさない):
| フォルダ | 用途 | ファイル命名例 |
|----------|------|----------------|
| `obsidian-vault/daily/` | デイリーノート | `obsidian-vault/daily/YYYY-MM-DD.md` |
| `obsidian-vault/coding/` | コーディング相談 | `obsidian-vault/coding/<トピック>/...` |
| `obsidian-vault/research/` | 技術調査・学習メモ | `obsidian-vault/research/YYYY-MM-DD-トピック.md` |
| `obsidian-vault/docs/` | ドキュメント成果物 | `obsidian-vault/docs/<ドキュメント名>.md` |
| `obsidian-vault/references/` | 参考資料・URL集 | `obsidian-vault/references/links.md` |
| `obsidian-vault/archive/` | 終了した相談 | `obsidian-vault/archive/YYYY-MM/<元のパス>` |
会話の冒頭で `obsidian-vault/daily/<今日の日付>.md` が存在する場合、
Claude はそれを一度読んで当日の文脈を把握してから作業に入ってください。
この1枚の表を書いておくだけで、挙動が劇的に変わります。
Before(CLAUDE.md なし):
私「API 設計のメモを書いて」
Claude「api-design.mdを作りました」(プロジェクトルートに生える)
After(CLAUDE.md に置き場ルールあり):
私「API 設計のメモを書いて」
Claude「obsidian-vault/research/2026-04-18-API設計.mdを作りました」
毎回「Vault の research 配下に作ってね」と言わなくて良い。CLAUDE.md の最後の一文「会話の冒頭でデイリーノートを読む」も効いていて、セッション開始時に Claude が勝手に当日のデイリーノートを読み、前後の文脈を把握した上で返答してくれます。
2026-04-29 追記:CLAUDE.md はフォルダルールだけじゃ足りなかった
2週間運用して分かったのは、フォルダの置き場ルールだけでは Claude の出力品質を安定させられない、ということでした。現在の CLAUDE.md は初稿の3倍近い分量になっていて、主に以下のセクションを追加しています。
スキル利用ポリシー — 7つのカスタムスキルのうち、どれが「常時適用」でどれが「必要時のみ」かを明記しています。特に obsidian-markdown(Obsidian記法の自動適用)と humanizer(AI臭さ29パターン除去)は必須スキルとして、Claude がノートを書くたびに自動で適用するよう指示しています。
### 必須スキル(常時適用)
| スキル | 適用場面 |
|--------|----------|
| `obsidian-markdown` | Vault 内の .md 作成・編集時。frontmatter、wikilinks、callouts を必ず使う |
| `humanizer` | 文章生成時に自動適用。AI臭さ29パターンを除去 |
humanizer の適用ルール — 「いつ適用して、いつ適用しないか」の線引きを明確にしています。コードブロック内や YAML frontmatter には適用しない、引用ブロックは原文ママ、など。これを書いておかないと、Claude がコードのコメントまで humanize しようとして壊れます。
スクリプト文字コードルール — Windows と Linux を行き来するプロジェクトなので、.sh は BOM 無し UTF-8 + LF、.ps1 は BOM 付き UTF-8 + CRLF、.py は BOM 無し UTF-8 + LF、という具体的なルールを書いています。これを書く前は、Claude が作った .sh を Linux に持っていくと改行コードで動かない、ということが起きていました。
Obsidian 運用ルール — frontmatter の必須フィールド(title, date, tags, aliases)、wikilink の書式、callout の使い方、埋め込み記法などを網羅しています。obsidian-markdown スキルの SKILL.md に詳細は委ねつつ、CLAUDE.md にもサマリを書いておくことで、スキルを読み込む前の段階でも最低限の記法が守られるようにしています。
.claude/settings.json の工夫
プロジェクトの挙動を固めるために .claude/settings.json でいくつかのキーを明示しています。
2026-04-29 更新: モデルを Opus 4.6 に変更しています。
2026-05-18 更新: モデルを Sonnet 4.6 に変更。effortLevel を削除し、機密ファイル保護と frontmatter チェックの2フックを追加しています。
{
"model": "claude-sonnet-4-6",
"enabledPlugins": {
"everything-claude-code@everything-claude-code": true
},
"env": {
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1"
},
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [{ "type": "command", "shell": "bash", "statusMessage": "機密ファイルチェック中...", "command": "# .env / credentials / secret を含むパスへの編集を自動ブロック" }]
}
],
"PostToolUse": [
{
"matcher": "Write",
"hooks": [{ "type": "command", "shell": "bash", "command": "# obsidian-vault/*.md に frontmatter がない場合に systemMessage で警告" }]
}
]
}
}
2026-04-29時点の settings.json(参考)
{
"model": "claude-opus-4-6",
"enabledPlugins": {
"everything-claude-code@everything-claude-code": true
},
"effortLevel": "xhigh",
"env": {
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1"
}
}
初稿時点の settings.json(参考)
{
"model": "claude-opus-4-7",
"enabledPlugins": {
"everything-claude-code@everything-claude-code": true
},
"effortLevel": "xhigh",
"env": {
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1"
}
}
それぞれの狙いは次の通り。
-
→model: Opus 4.7 に固定。モデルが勝手に変わらないように。2026-04-29 更新 Opus 4.6 に変更。Claude Code では Opus 4.6 が「Fast mode」として高速出力に対応しており、→ 2026-05-18 更新 Sonnet 4.6 に変更。日常的な相談・開発では Sonnet で十分であり、コスト削減のため変更。重い推論が必要なときは/fastトグルで切り替えられます。コーディング相談や調査タスクでは出力速度が体感に直結するため、こちらに乗り換えました。/modelコマンドでその場だけ Opus に切り替えられます。 -
enabledPlugins: 後述のeverything-claude-codeをプロジェクトで明示的に有効化。 -
→ 2026-05-18 更新effortLevel: "xhigh": 推論の深さを最大寄り(maxの一段下)に固定。コーディングや調査で妥協されないように。CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING: "1"で adaptive thinking を無効化している状態では effortLevel が機能しないため削除。 -
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING: 思考量の自動調整を止める。毎回同じ深さで考えてもらう方が実運用で安定するため。 -
hooks(2026-05-18 追加): 2種類のフックを追加。-
PreToolUse(機密ファイル保護): Edit/Write の直前に実行。
.envcredentialssecretを含むパスへの編集を自動ブロック。誤って APIキーファイルを書き換えるミスを防ぐ。 -
PostToolUse(frontmatter チェック): Write の直後に実行。
obsidian-vault/内の.mdファイルに frontmatter がない場合、systemMessage で警告を表示。
-
PreToolUse(機密ファイル保護): Edit/Write の直前に実行。
加えて .claude/settings.local.json には個人の許可リストを置いています。
{
"permissions": {
"allow": [
"mcp__awslabs_aws-documentation-mcp-server__search_documentation",
"mcp__awslabs_aws-documentation-mcp-server__read_documentation",
"WebFetch(domain:qiita.com)",
"WebFetch(domain:www.anthropic.com)",
"WebFetch(domain:aws.amazon.com)",
"WebSearch"
]
}
}
settings.json は「プロジェクトとして共有したい設定」、settings.local.json は「自分の端末だけの許可」と使い分けるのがコツ。このファイルのおかげで、よく使う AWS 公式ドキュメント・Qiita・Anthropic 公式へのフェッチで権限確認プロンプトが出なくなり、作業のリズムが崩れません。
.mcp.json と everything-claude-code プラグイン
MCP サーバはプロジェクト固有の → 2026-04-29 更新: 2つに増やしました。AWS Docs に加え、NotebookLM MCP を追加しています。.mcp.json で1つだけ有効化しています。
{
"mcpServers": {
"awslabs.aws-documentation-mcp-server": {
"command": "uvx",
"args": ["awslabs.aws-documentation-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_DOCUMENTATION_PARTITION": "aws"
}
},
"notebooklm": {
"command": "npx",
"args": ["-y", "notebooklm-mcp@latest"]
}
}
}
初稿時点の .mcp.json(参考)
{
"mcpServers": {
"awslabs.aws-documentation-mcp-server": {
"command": "uvx",
"args": ["awslabs.aws-documentation-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_DOCUMENTATION_PARTITION": "aws"
}
}
}
}
起動は uvx 経由。uv/uvx を先に入れておけば、初回起動時に自動でパッケージをダウンロードしてくれます。なぜ AWS Docs を入れたかというと、Claude に AWS の話を聞くと古い情報で答えられがちなので、一次情報を直接引けるようにするためです。
NotebookLM MCP は、自分が Google NotebookLM に登録したソース群(PDF・URL・テキスト)に対して、Claude Code の会話の中から直接質問できるサーバです。npx で起動し、初回だけ Chrome で Google ログインすれば以降は Cookie が永続化されます。自分専用の知識ベースを Claude に横断検索させたい、という用途にぴったりで、「あの PDF に書いてあった気がするけど何ページだっけ」みたいな質問を引用付きで返してくれます。
大事なのは「MCP を増やしすぎない」こと。everything-claude-code の README にも「すべての MCP を有効にすると 200k のコンテキストが 70k まで縮む可能性」と書いてあります。私は AWS Docs だけをプロジェクトスコープで常時有効、他の MCP(context7 exa github memory playwright sequential-thinking)は everything-claude-code プラグイン経由で必要時だけ使う、という運用です。
そのプラグイン側でよく使っているスラッシュコマンドを表にしておきます。
| コマンド | 使いどころ |
|---|---|
/plan |
実装計画を立てるとき |
/tdd |
TDD でコードを書き始めるとき |
/code-review |
書いたコードの品質レビュー |
/security |
セキュリティ観点のレビュー |
/build-fix |
ビルドエラーの原因特定・修正 |
/refactor-clean |
デッドコード削除・整理 |
/verify |
実装後の検証ループ |
/checkpoint |
検証通過時の状態保存 |
2026-05-18 追加: claude-code-setup@claude-plugins-official プラグインも導入しました。コードベースを分析して、フック・スキル・MCP サーバの最適な設定を提案してくれます。/claude-automation-recommender で呼び出せます。
さらに .claude/skills/note-article-writing/ にプロジェクト固有のカスタムスキルを置いています。note.com 向け記事を書くためのチェックリストやテンプレを SKILL.md に記述し、Claude が自動トリガーで呼び出してくれる。プロジェクトスコープで独自スキルを配置できるのが .claude/skills/ の強みで、ワークフローに合わせたミニエージェントを自作できます。
2026-04-29 更新: スキルは7つまで増えました。「常時適用」と「必要時のみ」に分けて運用しています。
| スキル | 分類 | やること |
|---|---|---|
obsidian-markdown |
常時適用 | Vault 内の .md を書くとき、frontmatter・wikilinks・callouts・embeds・tags を自動で正しい記法にする |
humanizer |
常時適用 | 文章生成時にAI臭さ29パターン(「~と言えるでしょう」「~することが重要です」等)を自動除去。コードやYAMLには適用しない |
note-article-writing |
必要時 | note.com 向け記事の執筆・チェック。スタイルルールとテンプレートを内蔵 |
obsidian-bases |
必要時 |
.base ファイル(Obsidian のデータベースビュー)を作成するとき |
json-canvas |
必要時 |
.canvas ファイル(ビジュアルキャンバス)を作成するとき |
obsidian-cli |
必要時 | Obsidian 起動中に CLI からノート操作・検索するとき |
defuddle |
必要時 | Web ページからクリーンな Markdown を抽出するとき |
特に humanizer の導入は大きかった。Claude が書く文章にはどうしても「構成としては〜」「〜と言えるでしょう」「〜において」みたいな定型句が混ざるので、29パターンをリスト化して SKILL.md に入れておくと、出力段階で自動的に言い換えてくれます。note.com の記事を書くときは note-article-writing のスタイルルールと humanizer の両方が効く形になっていて、わざわざ「自然な文体にして」と毎回言わなくてよくなりました。
Mac/Windows 手動コピー移行のルール
このプロジェクトは Git もクラウド同期も使わず、USB/ZIP で手動コピーする前提です。Git を使わない理由は、Obsidian のグラフ・設定ファイル・PDF などバイナリ類まで含めた「丸ごと」を雑に持ち運びたいから。その代わり、ファイル作成時のルール6つを守る必要があります。
| # | ルール | 理由 |
|---|---|---|
| 1 | 絶対パスを書かない | OS をまたぐと即死 |
| 2 | ホームディレクトリ直接参照(C:\Users\... や /Users/...)を埋め込まない |
同上 |
| 3 | パス区切りは / で統一 |
Windows でも / は動く |
| 4 | BOM 無し UTF-8 で保存 | 文字化け対策 |
| 5 | 改行は LF(CRLF 混在は避ける) | Git を使わないのでエディタ側で揃える |
| 6 |
obsidian-vault/.obsidian/ も一緒にコピー |
Obsidian の設定・プラグイン有効化状態を引き継ぐため |
別 PC に移した後は、プラグインだけ再導入します。これは ~/.claude/plugins/ が OS ごとにバイナリダウンロードされるため、フォルダごと持ち運べないからです。
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
/plugin install everything-claude-code
2026-05-18 更新: claude-code-setup プラグインも追加しました。
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
/plugin install everything-claude-code
/plugin install claude-code-setup@claude-plugins-official
この3行を叩けば、2回目以降の同じ PC では ~/.claude/settings.json に記録されるので不要。Obsidian 側は、新 PC で Obsidian を起動して obsidian-vault/ を Vault として開き直すだけで、デイリーノート設定やプラグイン有効化状態がそのまま引き継がれます。
まとめ:今日からマネできる最小セット
長くなったので、マネするときに最低限やることを5ステップにまとめておきます。
- プロジェクトフォルダを作り、ルートに
CLAUDE.mdとREADME.mdを置く -
obsidian-vault/を作り、daily/coding/research/docs/references/archive/の6フォルダを切る -
CLAUDE.mdに「どこに何を置くか」の表を書く(これだけで Claude の振る舞いが変わる) -
2026-05-18 更新:.claude/settings.jsonで model / effortLevel を固定、.mcp.jsonで必要な MCP だけ有効化settings.jsonで model を固定(effortLevelは削除)、機密ファイル保護・frontmatter チェックのフックを設定、.mcp.jsonで必要な MCP だけ有効化 - Obsidian で
obsidian-vault/を Vault として開き、Daily notes プラグインを有効化
記事中で紹介したものは全部コピペで動きます。慣れてきたら .claude/skills/ に自分用のスキルを置いたり、MCP を増減させたりして、自分の作業にフィットさせていくのがおすすめです。
2026-04-29 追記: 2週間運用してみて、上の5ステップに加えて「やっておいてよかった」と思う3つを追加しておきます。
-
.claude/skills/にhumanizerとobsidian-markdownを入れる — この2つがあると、Claude が書く文章の品質とフォーマットが安定します。特に humanizer は note.com や Qiita に載せる文章を書くときに手動の書き直しが激減しました -
CLAUDE.mdにスクリプト文字コードルールを書く — Mac/Windows を行き来する人は必須。.shは LF、.ps1は CRLF + BOM付き、.pyは LF。これを書いておかないと、片方の OS で動かないスクリプトが量産されます -
ファイル整理は定期的にやる —
CLAUDE.mdにルールを書いても、Claude が100%守るわけではありません。時間が経つとルートに.txtが散らばったり、obsidian-vault/直下にファイルが生えたりします。私は2週間で1回「CLAUDE.md のルールから外れているファイルを整理して」と Claude 自身に頼んで掃除させています
記事中で紹介した設定ファイルはそのままコピペで動きます。スキルの導入は .claude/skills/<スキル名>/SKILL.md を書くだけなので、自分のワークフローに合わせたルールを1つずつ足していくのがお勧めです。