Claude Code × Obsidian｜AIとの相談が”会社のナレッジ”になる置き場設計

Claude Code を使い始めて2〜3週間すると、多くの人が同じ場所で手が止まる。

昨日聞いたあの話、先週の戦略メモ、一昨日 Claude に推敲してもらった提案書の下書き——どこに保存したんだっけ、というやつ。私もそうだった。気がつくとプロジェクトのルート直下に api-design.md やら notes-2026.md やら memo.md やらが 20 個くらい転がっていて、Finder で検索しても何が何だか分からなくなる。

これ、ただの整理整頓の話じゃない。AI との相談は、そのまま会社の知的資産になりうる。議事録、調査メモ、契約書の下書き、経営判断のたたき台。全部が会話ログとして流れていって、どこにも残らない。いや本当にそう。私も数えきれないくらい「あのとき Claude と詰めた話、もう一度やり直してる」というムダを重ねてきた。

そんなときに、2026年4月18日に Qiita へ公開された htani0817 さんの記事「Claude Code × Obsidian Vault で作る『何でも相談』プロジェクト」（元記事リンク）を読んで、頭の中で「あ、これだ」と腑に落ちる音がした。

結論から書くと、この記事の核はひとつ。CLAUDE.md は、コーディング規約を書く場所ではなく、”ファイルの置き場を AI に自動判定させる装置”として使う。

書いてみると一行で済むんだけど、これが効く。発想をここに据え直すだけで、Claude Code との会話がそのままナレッジとして積み上がっていく構造ができあがる。私が毎日使っている mothership-lab（AI 氣道 Lab の母艦プロジェクト）も、根っこは同じ思想で動いている。ここは実測の話にもつながるので、後半で数字を出す。

この記事では、元記事のエッセンスを押さえつつ、私のプロジェクトの現実も重ねて、経営者目線で「何が得なのか」を一本の線で通して書いていきます。

元記事でいちばん刺さった一節が、Before と After のこの対比だった。

CLAUDE.md に何も書いていない状態で「API 設計のメモを書いて」と頼むと、Claude はプロジェクトのルート直下に api-design.md をそっと作る。悪気はない。ただ、置き場のルールがないから、一番目立つ場所に置くしかない。

ところが CLAUDE.md にフォルダ別の配置ルールを1枚の表で書いておくと、同じ指示で obsidian-vault/research/2026-04-18-API設計.md という具合に、意図した場所に勝手に収まる。

指示はまったく同じ。違うのは、CLAUDE.md に「研究系のメモは research 配下」「議事録系は daily 配下」という一文があるかないかだけ。たったそれだけで、AI と話すたびに発生していた”片付けコスト”がゼロになる。毎回「Vault の research に入れて」「いや daily に置いて」と言わなくていい。これが地味にデカい。

多くの人は、CLAUDE.md を「コーディング規約を書く場所」や「AI に口調を指示する場所」として使っている。htani0817 さんはそれを“ファイル配置の自動化装置”として再定義した。コードを書かせるためじゃなく、相談相手としての Claude に”片付けの習慣”を与えるという発想。これはエンジニアだけの話じゃなく、むしろ経営者にこそハマる使い方だと思う。

料理で言うと、CLAUDE.md は厨房に渡す”食材の引き出しマップ”に近い。野菜はここ、肉はここ、調味料はここ、と最初に決めておく。新人スタッフ（＝その日その日の新しい Claude Code セッション）が来ても、迷わず正しい引き出しに戻してくれる。そういう話。

htani0817 さんの「何でも相談-pj」の構成は、だいたいこんな形になっている。

何でも相談-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 の中に入れてしまうと読んでくれない。だからこの2つだけはルート固定。

ふたつ目。obsidian-vault/ をプロジェクトに内包する。Claude Code の作業ディレクトリはプロジェクトルートのままだから、.claude/ や .mcp.json の設定もちゃんと拾われる。それでいてノート本体と成果物は全部 Vault 配下に入るから、Obsidian で開けばそのまま知識グラフ化できる。Claude の作業場所と、自分の思考が蓄積される場所が、きれいに二階建てで分かれる。

サブフォルダの6つは、役割で見れば「毎日のログ」「コード関連」「調べもの」「ちゃんとした成果物」「参考にした元ネタ」「終わった相談の倉庫」と、要はそれだけのこと。名前をそろえておくことに意味がある。daily に入ったファイルは日付で追えるし、research に入ったメモは後で別案件から再利用できる。archive だけは少し特殊で、月ごとのフォルダ（archive/2026-04/ のような形）に元の階層ごと引っ越させる。こうしておくと Vault のルートは常にすっきりして、かつ「あの相談、いつやったっけ」で遡るときも元の階層のまま見つけられる。

私が2年近く Obsidian を「分身 AI の魂を蓄積する場所」として使い続けてきてつくづく思うのは、フォルダ名を凝るより、ルールを守り続けるほうが100倍効くということ。だから6つで十分。細かく分けすぎると、分けたこと自体が次の迷子を生む。

htani0817 さんの CLAUDE.md 本体には、こういう表が1枚貼ってあるだけ。

## フォルダ構成とデフォルト置き場ルール

新規ファイルを作る際は、内容に応じて以下のフォルダに配置してください
（絶対にプロジェクトルートや Vault ルートに散らさない）：

| フォルダ | 用途 | ファイル命名例 |
|----------|------|----------------|
| obsidian-vault/daily/ | デイリーノート | YYYY-MM-DD.md |
| obsidian-vault/coding/ | コーディング相談 | <トピック>/... |
| obsidian-vault/research/ | 技術調査・学習メモ | YYYY-MM-DD-トピック.md |
| obsidian-vault/docs/ | ドキュメント成果物 | <ドキュメント名>.md |
| obsidian-vault/references/ | 参考資料・URL集 | links.md |
| obsidian-vault/archive/ | 終了した相談 | YYYY-MM/<元のパス> |

会話の冒頭で obsidian-vault/daily/<今日の日付>.md が存在する場合、
Claude はそれを一度読んで当日の文脈を把握してから作業に入ってください。

この表1枚と、最後の一文。これで Claude Code の挙動が本当に変わる。

特に効くのは最後の一文のほう。「会話の冒頭で当日のデイリーノートを読む」と書いておくだけで、セッション開始時に Claude が勝手に今日までの文脈を拾ってから返答に入ってくれる。これ、会社の業務に置き換えると、毎回「前回の議事録に目を通してから会議に入ってください」と部下に口頭で言うのをやめて、「毎朝デスクに座ったら当日のノートを最初に読む」を全社ルール化するのと同じ構造になる。後者のほうが明らかに疲弊しない。ルールを一度書いてしまえば、あとは毎回の指示がいらなくなる。

私は以前「AI秘書に”なんか違う”を返されたら。マスタードキュメントを先に作る理由」でも書いたけれど、AI は”その場で最適化”するより、”参照するマスタードキュメントがある”ほうが圧倒的に精度が安定する。CLAUDE.md はまさに、その最小実装形なんだと思う。業務マニュアルを作るほど大がかりじゃなく、表1枚と宣言1文。それで相棒の動きが変わる。

ここからは少し、私の側の実測を書きます。私が毎日の仕事場にしている mothership-lab という Claude Code プロジェクトは、カスタムスキルが 151 個（SKILL.md を持って独立動作するものが 134 個）、プロジェクト内に置いている hook が 140 ファイルあり、そのうち settings.json に登録して常時発火しているのが 49 個ある。Obsidian の Vault としても動いていて、.obsidian/ が lab のルートに同居している構造。GPTs 研究会という 7,900 名規模のコミュニティでも朝の LIVE を毎日続けていて、その仕込みと記録が全部この母艦に溜まっていく。

一方、htani0817 さんの「何でも相談-pj」はカスタムスキルが 1 個、MCP も基本は AWS Docs まわりの 1 本だけ。

並べて書くと、規模は 150 倍違う。でもこれ、同じ設計思想の上にある。

CLAUDE.md をマスタードキュメントとして使い、Vault で成果物を蓄積し、MCP と自作スキルを必要なぶんだけ使い分ける。この 3 点セットは、規模が 1 でも 151 でも動く設計になっている。私の mothership-lab でも、CLAUDE.md の冒頭には rules/ 6 ファイル（soul / kenpou / judgment / quality-first / ux-settings / cw-send-policy）を常時ロードさせる宣言と、「このプロジェクトは AGI Cockpit の Master Agent として動き、./cockpit task / ./cockpit autorun で実働する」という運用規約が書いてある。要するに htani0817 さんの CLAUDE.md を、自分のドメインに合わせて肥大化させたもの、と言える。

デザイナー業界の具体例で同じ思想を整理したものは、「デザイナーがClaude Codeで実働8h→60分｜1人マーケを支える5層21スキルの作り方」で書いた。スキルをどう育てていくかの温度感は、「Claude Codeで何ができる？スキル化×自動化で広がる、言葉だけで世界を作る時代」のほうに置いてある。どちらも「一気に大きくしない」が共通のキーワードです。

ひとつだけ、本気で釘を刺させてほしい。最初から 151 スキルを狙うと、ほぼ確実に挫折する。これ、私自身が遠回りした話でもあるから、自信を持って言える。初動は htani0817 さんの「1スキル+1MCP」が正解。やってみて、詰まったところだけに足していく。スキルも hook も、困ったから生まれたものしか長生きしない。

htani0817 さんの .claude/settings.json は、結局こういう形だった。

{
  "model": "claude-opus-4-7",
  "enabledPlugins": {
    "everything-claude-code@everything-claude-code": true
  },
  "effortLevel": "xhigh",
  "env": {
    "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1"
  }
}

肝になるのは後半2行。effortLevel を xhigh にしておくと、Claude は「ここは手を抜いてさらっと流そうかな」という自動判定を控えめにして、じっくり考えた回答を返してくる。CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING は、その”手抜き自動判定”自体をオフにするスイッチ。

意思決定の相談に Claude を使う経営者こそ、この 2 つは入れておいたほうがいい。意思決定まわりで AI が途中から手を抜いたら、判断材料が痩せる。数字を突き詰めるとき、契約条件を洗うとき、来月の方針を決めるとき——ここで浅い答えが来ると、後日手戻りで 5 倍のコストがかかる。

MCP（Model Context Protocol）のほうも、htani0817 さんは AWS Docs 系を 1 本だけプロジェクトスコープで常時有効にしていた。逆に言うと、それ以外は全部オフ。これは見落とされがちだけど、かなり大事な判断で、元記事にもはっきりこう書かれていた。

これは私が以前「AIが急にバカになった朝——「全部渡す」が裏目に出るcontext rotの正体」で扱ったのと同じ根っこの話。MCP を盛れば盛るほど、Claude が一度に考えられる”思考のキャパ”が削られていく。情報をいっぱい渡したほうが賢くなりそうな気がするけど、実際は逆。必要なものだけ渡したほうが返ってくる答えがキレる。

私がこの感覚をつかむのに時間がかかったのは、「AI はなんでも食べられる」と無邪気に思っていた頃の自分のせい。実際には、Claude も人間と同じで、机の上が散らかっていると集中できなくなる。MCP はとりあえず 1 本に絞って、必要になったタイミングで 1 本ずつ足す、が運用の正解でした。

ここまではエンジニア向けの記事の翻訳だったので、経営者目線に寄せて書き直します。

日々の経営で発生する「誰かに相談したいこと」「でも相談相手がいないこと」を、Claude Code × Obsidian で受け止めるとしたら、だいたいこう置いていきます。

ミーティング議事録は obsidian-vault/daily/ に入れる。日付で追えるから、月末に「先月の経営会議で決まったこと、どこまで進んだ？」を 10 分で Claude に振り返ってもらえる。

市場調査や業界動向のメモは research/ に入れる。競合分析、業界ニュースの要点、気になった海外の先行事例。ここに貯めておくと、次の戦略ミーティングのときに Claude が勝手に「前回の調査と今回の案を突き合わせると、こういう穴があります」と指摘してくれる。

契約書や提案書の下書きは docs/ に入れる。最終版の手前までを Claude と揉んで、弁護士先生や取引先に出す前の”最後のひと磨き”を相談相手として使う。この使い方、中小経営者にとってはわりと大きい。顧問弁護士に毎回相談すると費用も時間もかかるけど、「こういう条件を入れたいんだけど、抜けはないかな」を先に Claude で潰しておけば、本当に相談すべき重要論点だけを専門家に持っていける。

参考資料や読んで気になった URL は references/ に。完了した案件は archive/2026-04/ のように月単位で倉庫にしまう。

ここまでそろえると、Obsidian 側にもうひとつ効いてくる機能がある。ノート同士をリンクで繋いでおくと「あの契約書の下書きは、どの調査レポートを元にしたのか」「この戦略は、先月のどのミーティングの発言から派生したのか」が一目で追える。経営判断の再現性が取れる、というのは口で言うとふわっとしているけど、実際にやるとけっこう心強い。

もう一つ、地味だけど本質的な効果を書いておく。担当社員の頭の中にしかなかった情報が、会社の側に残るようになる。ベンダーとのやり取り、過去に検討して見送った施策の理由、何となくでやってきたオペレーションのクセ。こういう属人化している”暗黙の資産”は、退職や異動のタイミングで一気に蒸発する。それを Vault という形で会社側に残していくと、人が変わっても組織としての記憶は連続する。

経営者が AI に任せる設計の全体像は、「経営者がAIに委ねる5つの設計論｜月150億トークンの広木大地に学ぶ「抱え込みOS」を捨てる日」にまとめた。Claude Code × Obsidian の組み合わせは、あの設計論のうちで一番具体的な実装の形だと思って読んでもらえるとちょうどいい。

私はもともと、自分で全部やらないと気が済まないタイプだった。抱え込みが快感にすらなっていて、手放すのが怖かった時期が長かった。Obsidian に言葉を残しはじめた頃、最初は「これ本当に役に立つのかな」と半信半疑だったけど、数ヶ月経った頃に Claude が過去の自分のメモを引きながら返してくるようになって、ようやく「ああ、これ分身 AI を育てるってこういうことか」と腑に落ちた。相談相手を作るつもりで置き場を設計していたら、知らないうちに”もう一人の自分”が育っていた、という順番でした。

元記事の流れに沿って、経営者が今日その日から動ける最小セットを書いておきます。段取りとしては 5 つ。

まずプロジェクト用のフォルダをひとつ作る。名前は 何でも相談-pj/ でも 経営相談/ でもいい。ここが Claude Code の作業場になる。次に Obsidian をインストールして（無料）、その中に obsidian-vault/ フォルダを作る。このフォルダを Vault として Obsidian で開くだけで、初期設定は終わり。続いて obsidian-vault/ の中に daily/ research/ docs/ references/ coding/ archive/ の 6 つのサブフォルダを切る。中身は空で構わない。そのあと、プロジェクトルートに CLAUDE.md を作って、先ほど紹介した置き場ルールの表と、デイリーノートを冒頭で読む一文だけをコピペする。最後に、その作業フォルダを Claude Code で開いて、何でも相談を投げてみる。「今日の経営会議の議事録を整理して」「このメール文面、取引先に失礼にならないか見て」「昨日の勉強会で出た質問を、社員向けに噛み砕いて整理して」。配置は Claude が勝手に判断してくれる。

ここまで、慣れれば 1 時間かからない。

慣れてきたら、.claude/skills/ に自分の業務に特化したカスタムスキル（たとえば「月次レポート生成」「クライアント向け提案書テンプレート」）を 1 つずつ足していく。MCP も、「Notion を読ませたい」「Google ドライブを参照したい」と必要になったタイミングで .mcp.json に 1 本ずつ追加していく。最初から全部揃えようとしない。ここが、長続きと挫折の分岐点です。私も 151 スキルに至るまでは 1 個ずつ育ててきた時間がある。近道はない、というかむしろ近道しない方が結果的に早い。

Obsidian じゃないと動かないんですか、という質問が一番多い。結論、動きます。Markdown ファイルの集まりなので、VS Code でも他のテキストエディタでも中身は読める。ただ Obsidian を推す理由は 3 つあって、ノート同士の関係を可視化するグラフビューがあること、クラウドを介さずローカルに保存できるので機微情報を扱いやすいこと、そしてプラグイン資産が豊富で育てていける余地が大きいこと。とくにグラフビューは、経営判断を振り返るときに効いてくる。一度の勘で決めたように見えた判断も、実は3ヶ月前のメモと先月の調査と一昨日の会議が全部繋がって出ていた、ということがグラフで見えるとちゃんと分かる。食わず嫌いしないで、一度試してみる価値はあります。

MCP はいっぱい入れたほうが賢くなりますか。これは逆です。元記事にもあったし、私も体感しているけれど、MCP を盛るほど Claude の思考範囲は削られていく。経営者が最初に入れるなら、自社で使っているクラウド系のドキュメント（Notion、Google Drive など）の MCP を 1 〜 2 本、業界特化の情報源があればそれをもう 1 本、くらいで止めるのがいい。慣れてきたら、必要なときだけ起動するプラグイン方式に寄せていく。MCP は食材です。いっぱいあれば豪華な料理ができる、というわけではなくて、冷蔵庫が散らかるだけ。

プロジェクトごとに CLAUDE.md を分けるべきですか。これは分けることを強くおすすめします。経営相談、ブログ執筆、顧問業務、社内向けドキュメント整備——業務の性質が違えば、Claude に期待する振る舞いも違う。経営相談プロジェクトなら「数字と論理、結論先出し」、ブログ執筆プロジェクトなら「親しみやすい口調、一人称は私」、社内向けなら「用語の統一と敬語の徹底」といった具合に書き分けると、同じ Claude でも別人みたいに使い分けができます。一つの CLAUDE.md に全部詰めると、どれもぼんやりする。プロジェクト分離はめんどくさそうで実は一番ラク、というのが使い込んだ上での実感です。

AI との相談が散らかる問題は、スキル不足でもツール不足でもない。設計不足です。

CLAUDE.md に置き場ルールを書く。Obsidian Vault を内包する構成にする。MCP は最小限に絞る。この 3 点だけで、AI との会話がそのまま会社のナレッジとして積み上がっていく。明日から Claude を閉じても、資産は残る。

最初の一歩は、今日の議事録を1本、Claude に書いてもらうところから。1 時間で最小セットは組めます。あとは毎日使いながら、自分の業務のかたちに合わせて育てていけばいい。1 スキルから始めて、3 ヶ月後に振り返ると、もう他人の頭では追いつけないほどの資産が Vault に積もっていると思います。

• 元記事：Claude Code × Obsidian Vault で作る「何でも相談」プロジェクト (@htani0817)
• Claude Code 公式ドキュメント
• Obsidian 公式

関連記事（AI氣道）

• AI秘書に”なんか違う”を返されたら。マスタードキュメントを先に作る理由
• AIが急にバカになった朝——「全部渡す」が裏目に出るcontext rotの正体
• 経営者がAIに委ねる5つの設計論｜月150億トークンの広木大地に学ぶ「抱え込みOS」を捨てる日
• Claude Codeで何ができる？スキル化×自動化で広がる、言葉だけで世界を作る時代
• デザイナーがClaude Codeで実働8h→60分｜1人マーケを支える5層21スキルの作り方