
Claude Codeを仕事OSにする前に、ObsidianをAIが働ける職場にした話
Claude Codeを使い始めてから、気づいたことがある。
Claude Codeを入れる。
すごいのは分かる。
でも、数日後にはこうなる。
「で、結局なにを任せればいいんだっけ?」
これは、かなり多くの人がぶつかる壁だと思う。
AIに仕事を任せるうえで本当に大事なのは、プロンプトのうまさだけではなかった。
もっと手前にある。
AIが迷わず働ける「職場」を用意できているか。
ここが決定的に大事だった。
この記事は、特に Obsidianをすでに少し使っていて、Claude Codeを仕事に組み込みたい非エンジニア に向けて書いている。
事業側、PM、マーケター、講師、経営者、ライターのように、コードを書くこと自体が本業ではない人たちが、Claude Codeをどう仕事に組み込むか。
ここが今回のテーマだ。
2026年5月8日時点で、noteの #claudecode タグには2万件以上の記事がある。人気欄を見ると、「非エンジニア向け」「業務Skills」「チーム導入」「並列実行」「コンテンツ制作」といったテーマの記事が、確認時点では目立っている。
つまり、もうClaude Codeは一部のエンジニアだけが触る黒い画面ではなくなりつつある。非エンジニア側も、「自分の仕事そのものをAIにどう渡すか」を考え始めている。
これはAIの性能不足ではない。多くの場合、AIに渡す仕事の文脈が散らかっている ことが原因だと思っている。
人間の新入社員に仕事を頼むときも同じだ。机もない、資料の場所も分からない、社内ルールもない、過去の議事録もない、判断基準もない。そんな状態で「うまくやって」と言われても困る。
AIも同じだ。
Claude Codeを仕事OSにしたいなら、その前に、AIが働ける職場を作る必要がある。
自分の場合、その職場がObsidianだった。
この記事では、僕のObsidian Vaultを「AIエージェント用ハーネス」として見たときに、どんな設計になっているかを整理する。
ここでいうハーネスとは、難しい言葉で言えばAIを安全かつ再現性高く動かすための周辺設計のこと。もっと簡単に言うと、AIのための机、棚、ルール、道具、点検表 である。
僕は普段、企業向けの生成AI導入支援や研修設計、AI活用記事の執筆をしている。その中で何度も見てきたのは、「AIツールを入れたのに、仕事の置き場所がないから定着しない」という問題だった。
この記事は途中まで無料で読めるようにする。
無料部分では、なぜObsidianがClaude Codeの仕事OSになり得るのか、僕のVaultをどういう6層構造で見ているのかをほぼ全部書く。
一方、有料部分には、完全に真似するためのテンプレートを置く。
Vaultフォルダ構成
ノート用YAML
AI_BRIEF テンプレ
MOCテンプレ
CLAUDE.md 完全版
Skills 4本
記事執筆プロンプト
ファクトチェック表
3日で移植する手順
公開記念価格は980円。そのうち通常価格1,480円へ戻す予定だ。
理由はシンプルで、これは「読み物」というより、自分のObsidianに移植するための設計図 だからだ。
考え方だけ知りたい人は、無料部分だけで十分だと思う。
今日から自分のVaultに組み込みたい人だけ、続きを読んでもらえればいい。
この記事で伝えたいこと
結論はシンプルだ。
AI時代のメモ術は、「記録」ではなく「実行環境の設計」になる。
これまでObsidianは「第二の脳」と呼ばれてきた。
もちろん、それは今でも正しい。自分の考えを残し、つなげ、育てる場所として、Obsidianはものすごく強い。
でも、Claude CodeやAIエージェントを使い始めると、Obsidianの意味が少し変わる。
Obsidianは、自分が読むためのメモ帳であると同時に、AIが仕事を始める前に読む業務環境 になる。
つまり、こういう変化が起きる。
Before: 人間があとで思い出すためのメモ
After : AIが今すぐ働くための文脈
この差は大きい。
「あとで思い出す」だけなら、多少散らかっていてもいい。自分が分かればいいからだ。
でも「AIが働く」ためには、情報の置き場所、要約、信頼度、読む順番、実行ルール、再利用可能な手順が必要になる。
これを雑にすると、AIは毎回迷う。
毎回同じ説明を求められる。
毎回ファイルを読み漁る。
毎回ちょっと違うやり方をする。
毎回「それっぽいけどズレたアウトプット」を出す。
逆に、ここを整えるとClaude Codeの体感が変わる。
AIに「この記事を書いて」と言うだけではなく、
「このMOCを起点に、この記事テンプレを守り、信頼度ラベルを見ながら、足りない部分だけ調査し、最後にファクトチェックして」
と言えるようになる。
これが、ObsidianをAIの職場にするということだ。

Claude Codeは「賢い部下」ではなく「環境に依存する作業者」
Claude Codeの公式ドキュメントでは、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携するエージェント型のツールとして説明されている。
これはものすごく重要だ。
Claude Codeは、ただ会話するAIではない。
ファイルを読める。
編集できる。
コマンドを実行できる。
複数ファイルにまたがって作業できる。
つまり、Claude Codeは「質問に答える人」ではなく「作業する人」に近い。
でも、作業する人には環境が必要だ。
新人が会社に入ったときに必要なのは、根性論ではない。
どこに資料があるか
何が最新情報か
何を信じてよいか
誰に何を確認すべきか
どの手順で進めるべきか
どこまで自分で判断してよいか
これが分かるから働ける。
AIも同じだ。
Claude Codeを入れたのに仕事が変わらない人は、AIの使い方が下手というより、AIが働くためのオンボーディング資料がない 状態になっていることが多い。
だから僕は、Obsidianをただの知識置き場ではなく、AIのオンボーディング環境として使うようになった。
僕のVaultは、すでにハーネスになっていた
自分のObsidianを見返すと、主なフォルダはこんな構造になっている。
00_自分
01_索引
10_AI技術
11_AI動向
12_AIビジネス
20_人物
30_仕事
40_学習
90_プロジェクト
.claude/skills
docs/workflows
一見すると、普通の分類に見える。
でもAIエージェントの視点で見ると、かなり意味が変わる。
00_自分 は、AIが僕というユーザーを理解するためのプロフィール層。
01_索引 は、AIが迷子にならないための地図。
10_AI技術 は、技術解説やClaude Codeまわりの参照知識。
11_AI動向 は、時系列の変化を追うためのニュース層。
12_AIビジネス は、組織導入、リスク、活用事例などのビジネス文脈。
30_仕事 は、実際の原稿、研修、テンプレ、プロフィール。
40_学習 は、動画、論文、人物理解などのインプット。
90_プロジェクト は、実験や個別案件の作業場。
.claude/skills は、AIに渡す業務手順の置き場。
こう見ると、Obsidianは単なるノートの集まりではない。
AIが仕事をするための組織図 になっている。
人間が見ても分かる。
AIが見ても分かる。
そしてClaude Codeがファイルとして扱える。
これが強い。
ハーネスとしてのVault 6層構造
僕のObsidianをAI用ハーネスとして分解すると、だいたい6層になっている。

Layer 1: フォルダ分類
まず一番下にあるのが、フォルダ分類だ。
これは人間にとっては整理整頓だが、AIにとっては探索範囲の制限になる。
Claude CodeにVault全体を読ませると、当然ながら情報量が多すぎる。そこでフォルダ構造があると、
「今回は記事執筆だから 30_仕事/執筆・コラム を見て」
「Claude Codeの設計だから 10_AI技術/Claude Code と 01_索引/MOC Claude Code を起点にして」
「組織導入の文脈だから 12_AIビジネス/組織活用 を見て」
という指示ができる。
AIにとって、フォルダは単なる置き場所ではない。
読むべき範囲を限定するためのガードレール になる。
Layer 2: メタデータ
次に重要なのが、ノート冒頭のメタデータだ。
僕のノートには、だいたい次のような情報が入っている。
note_type: "article"
source_kind: "transcript"
ai_summary: "このノートの要約"
ai_use_case: "いつ開くべきか"
area: "10_AI技術"
date_bucket: "2026-05"
organization_status: "classified"
tags:
- "tech/claude-code"
- "topic/context-engineering"
source_reliability: "secondary"
verification_status: "unverified"
needs_citation: true
これは人間用というより、かなりAI用に近い。
特に重要なのは、source_reliability と verification_status だ。
AIは、文脈を与えられるとそれを素直に信じやすい。だから、ノートごとに「これは一次情報なのか」「二次情報なのか」「未検証なのか」「公開記事に使うなら出典確認が必要なのか」を明示しておく。
これは地味だが、めちゃくちゃ重要だ。
AIに仕事を任せるとき、本当に怖いのは「何も知らないこと」ではない。
未検証の情報を、検証済みのように扱うこと だ。
だからメタデータは、AIに対する信頼度ラベルになる。
Layer 3: AI_BRIEF
次に、AI_BRIEF という要約レイヤーがある。
これは、AIがそのノートを開いたときに最初に読む短いブリーフィングだ。
たとえば、
> [!AI_BRIEF]
> このノートは、Claude CodeのHooks機能を初心者向けに整理したもの。
> コンサル先にAIの確率的な振る舞いと決定論的制御の必要性を説明するときに開く。
こういう短い説明があるだけで、AIの動きはかなり変わる。
人間でも、いきなり1万字の資料を渡されるより、「これは何の資料で、いつ使うものか」を先に言われたほうが読みやすい。
AIも同じだ。
AI_BRIEF は、ノートの冒頭に置く小さな受付係みたいなものだ。
この資料は何か。
いつ使うのか。
どのテーマと関係するのか。
どの程度信じていいのか。
それを先に渡すことで、AIは本文を全部読まなくても、そのノートの使いどころを判断できる。
これはトークン節約にも効く。
Claude Code公式のコスト管理ドキュメントでも、HooksやSkillsへの処理の切り出し、専門的な手順を CLAUDE.md からSkillsへ移すこと、具体的なプロンプトで探索範囲を絞ることなどが、コンテキスト効率を上げる方法として紹介されている。[3] AI_BRIEF はまさに、読む前に読むべきか判断するための圧縮レイヤーだ。
Layer 4: MOC
MOCはMap of Contentの略で、テーマごとの索引ノートだ。
僕のVaultには、たとえばこんなMOCがある。
MOC Claude Code
MOC AIツール・技術解説
MOC AIビジネス・組織活用
MOC セミナー・講義ノート
MOC 執筆・コラム関連
MOCは人間にとっても便利だが、AIにとってはさらに重要だ。
AIにとって一番困るのは、「どこから読めばいいか分からない」ことだからだ。
Claude Codeにこう頼むとする。
Claude CodeとObsidianを組み合わせた記事を書きたい。
まずMOC Claude CodeとMOC 執筆・コラム関連を見て、
記事に使えそうな素材を整理して。
このとき、MOCがあるだけで探索が一気に安定する。
AIがVault全体をgrepし続けるのではなく、地図から入れる。
これが大きい。
AIにとってMOCは、検索結果ではなく 読む順番の設計 だ。
Layer 5: CLAUDE.mdとSkills
ここからがClaude Codeらしい層になる。
CLAUDE.md は、Claude Codeに継続的な指示を渡すMarkdownファイルだ。公式ドキュメントでは、./CLAUDE.md または ./.claude/CLAUDE.md に、ビルドやテストのコマンド、コーディング標準、アーキテクチャ判断、命名規則、共通ワークフローなどを書くものとして説明されている。
僕の感覚では、CLAUDE.md はAI社員の就業規則に近い。
毎回必ず守ってほしいことを書く。
作業の哲学を書く。
セキュリティ上やってはいけないことを書く。
どの粒度で報告してほしいかを書く。
一方で、細かい業務手順を全部 CLAUDE.md に詰め込むと重くなる。
ここで出てくるのがSkillsだ。
Claude CodeのSkillsは、SKILL.md を起点に、テンプレート、例、スクリプト、参考資料をまとめられる仕組みになっている。公式ドキュメントでも、Skillは使われるときに読み込まれること、複雑なSkillでは補助ファイルを追加して本体を簡潔に保てることが説明されている。
つまり、こう分ける。
CLAUDE.md = 常に守るルール
Skills = 必要なときだけ呼ぶ業務マニュアル
これはObsidianとも相性がいい。
たとえば僕なら、こういうSkillsを作れる。
article-draft: note記事の構成と初稿を作る
citation-research: 出典確認と一次情報探しをする
seminar-design: 研修設計を作る
ai-brief-generator: ノートにAI_BRIEFを付ける
moc-maintainer: MOCを更新する
fact-check-note: 公開前の記事をファクトチェックする
これらは単なるプロンプトではない。
業務手順のパッケージ化 だ。
同じ仕事を何度も頼むなら、毎回プロンプトを書くのではなく、Skillにする。
これが、AI時代の業務マニュアルになる。
Layer 6: ログと棚卸し
最後に、ログと棚卸しがある。
AI環境は、放っておくとすぐ腐る。
使わないSkillが増える。
古いルールが残る。
MOCのリンクが古くなる。
未検証ノートが検証済みっぽく扱われる。
似たようなテンプレが増える。
だから、棚卸しが必要になる。
僕のVaultには、Skillsのカタログやダッシュボードがある。どんなSkillがあり、何に使うのか、使われていないものはどれかを見えるようにしている。
これは地味だが、ハーネス設計ではとても重要だ。
AIに仕事を任せる環境は、一度作って終わりではない。
運用して、点検して、腐った部分を捨てる ところまでが設計だ。
なぜ「プロンプト」より「環境」が大事なのか
プロンプトはもちろん大事だ。
でも、プロンプトだけで仕事を回そうとすると、どうしても属人的になる。
うまい人はうまく使える。
慣れていない人は毎回迷う。
同じ依頼でも出力がブレる。
前提説明が長くなる。
過去の判断が引き継がれない。
これは、AI活用が「個人芸」になっている状態だ。
一方、Obsidianをハーネスとして設計すると、AI活用が少しずつ「仕組み」になる。
プロンプト芸:
その場の言い方で品質が決まる
ハーネス設計:
情報、ルール、手順、検証で品質を支える
この差は、仕事で使うほど効いてくる。
特に非エンジニアにとっては、プロンプトを毎回うまく書くより、最初に仕事の文脈を整えておくほうが再現性が高い。
「自分はコードが書けないからClaude Codeは難しい」と思う人ほど、実はこの発想が向いている。
コードを書く前に、仕事を分解する。
資料を置く。
判断基準を言語化する。
出典を残す。
手順をテンプレ化する。
これは、エンジニアだけの能力ではない。
むしろ事業側、講師、PM、マーケター、編集者のほうが得意なことでもある。
ここまで読めば、考え方はほぼ全部わかる
ここまでが、無料部分でいちばん伝えたかったことだ。
Claude Codeを使うと、「AIがここまでできるのか」と驚く。
でも、しばらく使うと次の壁に当たる。
AIは賢い。
でも、自分の仕事の文脈は知らない。
だから、文脈を整える必要がある。
僕にとって、それがObsidianだった。
MOCで地図を作る。
AI_BRIEF でノートの役割を伝える。
メタデータで信頼度を示す。
CLAUDE.md で就業規則を書く。
Skillsで業務マニュアルをパッケージ化する。
ログと棚卸しで環境を腐らせない。
これらを合わせると、Obsidianは単なるメモ帳ではなくなる。
AIが働ける職場になる。
ここまで読めば、「なぜObsidianをAI用ハーネスとして設計するのか」は十分わかると思う。
ただ、実際にやろうとすると、たぶん次の壁が来る。
「で、自分のVaultには何を置けばいいの?」
「CLAUDE.md には何を書けばいいの?」
「MOCはどの粒度で作ればいいの?」
「Skillsって、最初に何を作ればいいの?」
「AIに読ませるノートのテンプレはどうするの?」
このあたりから先は、思想ではなく実装の話になる。
なので、ここから先は有料部分にする。

有料部分は、公開記念980円の「完全再現パック」という位置づけだ。
買わなくていい人もいる。
Claude CodeとObsidianの考え方だけ知りたい
自分でテンプレを作るのが楽しい
まだObsidianをほとんど使っていない
AIに任せたい具体業務が決まっていない
この場合は、無料部分だけで十分だと思う。
逆に、続きを読む価値があるのはこういう人だ。
すでにObsidianにメモがたまっている
Claude Codeを入れたが、使い道がまだ定まっていない
記事執筆、研修設計、リサーチ、資料作成をAIに任せたい
自分のVaultをAIが読める形に整えたい
CLAUDE.md やSkillsを、ゼロから考える時間を減らしたい
公開記念価格を980円にしたのは、最初に試すハードルを下げたいからだ。
ただ、通常価格は1,480円に戻す予定だ。
1回読んで終わりのコラムではなく、自分のObsidianに貼って使うテンプレ集 にするからだ。
自分で同じ構成をゼロから考えると、たぶん3から5時間はかかる。フォルダ構成を決め、YAMLを作り、CLAUDE.md を書き、Skillsを分け、MOCを整え、ファクトチェック表まで作る必要があるからだ。
ここから先は、その時間を短縮するためのパーツ集だ。
たとえば、有料部分ではこういう CLAUDE.md の型を、そのまま使える形で置いている。
# このVaultでClaude Codeが守ること
## 目的
このVaultは、記事執筆、AI活用リサーチ、研修設計、提案資料作成を行うための作業環境です。
ここまでが地図。
ここから先は、3日で自分のObsidianへ移植するための具体テンプレだ。
ここまでの参考リンク
ここから先は、完全再現パックです
ここからは、僕なら最初にこう作る、という形でテンプレを置いていく。
考え方は無料部分で書いた。
有料部分では、手を動かすための部品を渡す。