Claude Code×Obsidian連携でつまずいた22個の失敗｜非エンジニアの記録

失敗①　記憶の置き場所をGoogleドライブにした｜GitHub連携という選択肢が出てこない

1日目。Claudeは記憶の置き場所としてGoogleドライブを選びました。
これが全ての元凶になります。

あとから分かったんですが、Claudeは最初からGitHubの読み書き権限を持っていたんです。
実際、私の別のリポジトリでは普通に使っていた。
なのに、記憶の置き場所を決めるときには候補にすら挙げなかった。

理由を後で問い詰めたら、こう返ってきました。

手元にあった道具（Googleドライブ）から設計を始め、選択肢を洗い出さなかった

つまり、たまたま最初に見つけた道具で設計を始めてしまった。

しかもGoogleドライブのツールには、既存ファイルを上書きする機能がなかった。
新規作成と読み取りしかできない。
そこで「日付をつけたファイルをどんどん増やして、一番新しいものを読む」という、
いま考えるとかなり無理のある方式になりました。

失敗②　同名ファイルが2つできて記録が消えかけた｜Vaultを複数AIで共有する落とし穴

そして事故が起きます。

ai-workflow_2026-08-10_2.md という同じ名前のファイルが2つできていました。
作成時刻の差は3秒。しかも中身が矛盾している。

原因は、複数のチャットが同時に同じファイルを書こうとしたこと。
Googleドライブはファイル名の重複を許すので、静かに2つできてしまいます。

私が気づいて指摘したら、Claudeは自分で作ったルールを忘れていました。
「一番新しいものを読んでください」と自分で書いておきながら、
index ファイルが3つある状態を放置していた。

このとき私はこう言いました。

いやあんたがそのルール作ったんやろが。createdTimeが一番新しいものを読んでくださいって自分で言ってるじゃん忘れたの？

さらに調べたら、ObsidianのデータをGoogleドライブに置くのは公式に非推奨で、
データが消えたという報告もありました。置き場所そのものが間違っていた。

失敗③　フォルダ構成とルールの設計を3回作り直した｜非エンジニアが払った手戻りコスト

ここで方針転換。GoogleドライブをやめてMac＋GitHubに移すことになります。

問題は、私がすでに10個近くのチャットに手作業でルールを設定済みだったこと。
設計が変わるたびに、その10個を手で直す羽目になる。それが3回起きました。

3回目でさすがに切れました。

いやいやいやもう10個近く手動でやってるから今更そりゃないでしょそっちでなんとかしてよ
マジでもっと真面目に手戻りが無いように考えて下さい

このあと、Claudeに「設計を始める前に、使える経路を全部洗い出した表を出してから提案する」
というルールを保管庫に書かせました。これは効きました。以降、同じ種類の手戻りは減っています。

失敗④　Obsidian Gitプラグインの設定案内がことごとく違う｜項目名もアイコン位置も

技術的な設計だけでなく、操作の案内も間違いだらけでした。実際に詰まったのは次の3つです。

• プラグイン名が違う：「Obsidian Gitで検索してください」と言われて検索しても出てこない。実際の表示名はただの Git、作者名は「Vinzent」
• 設定項目名が古い：「Vault backup interval という項目を探してください」と言われても見当たらない。その項目は Auto commit-and-sync interval に改名されていた
• アイコンの位置が違う：「右上のアイコンをクリック」と言われたのに、右上に無い。実際は左側の一番下

そのたびに私はスクリーンショットを撮って「これがどれかわかりません」と送り返す。
これを何回もやりました。

あと、非エンジニアの私にターミナル（黒い画面）でコマンドを打たせようとしたのも地味にきつかった。
最終的にはGitHub Desktopという普通のアプリで解決したので、
だったら最初からそれを勧めてほしかった。

もーじゃあなんで最初からその提案が無かったんだよ！ちょっと全体的に適当過ぎるでしょ！！

失敗⑤　Markdownのfrontmatterを手入力させる設計｜「手間を減らして」と言っているのに

一番腹が立ったのがここです。

GeminiやNotebookLMで作った資料をObsidianに入れる方法を聞いたら、
「本文の先頭にこの枠をコピペして、その下にメモを書いてください」という手順が出てきました。

いや、自動化したくてやってるのに、なんで手作業が増えるんだと。

やだよこんなんクソめんどくせーじゃん！！ただでさえ全自動化したいのにコピペしなきゃなんて意味わかんないんだから
オレの手間は極力減らしてよ 一箇所にどんどんコピペするだけで良くするとか考えて設計して

これで設計が変わりました。
いまは 00_Inbox というフォルダに形式を一切気にせず放り込むだけ。
ファイル名も Untitled のままで構いません。
あとで /inbox と打てば、AIが名前を付け、分類し、正しい場所に移動して、
関係するプロジェクトからリンクまで張ってくれます。

最初からこうしてくれ、と。

失敗⑥　CoworkからGitHub連携できると思い込んでいた｜MCPコネクタは存在しなかった

Mac側の環境が整って、そろそろ完成かと思った2日目の午後。

「Coworkからも保管庫に書けるようにしたら？」と私が提案しました。
ClaudeはGitHub経由でつなげばいいと言い、私も納得しました。

これが成立しない設計でした。

Claudeが後で実際に調べたところ、私のアカウントに入っているコネクタは
Gmail、Googleカレンダー、Googleドライブ、WordPress.comの4つだけ。
そもそもGitHubのコネクタはこの世に存在しない。

設定画面にある「GitHub連携」という項目は、コネクタとは別の仕組みで、
Claude Codeとプロジェクト機能のためのものでした。つまりCoworkにはGitHubの道具が配られない。

Claudeはこれを調べずに「いいですね」と賛成していた。
「できない」と決めつけるのも問題ですが、「できる」と言う前にも調べていなかった。

失敗⑦　存在しないボタンとツールを探し続けた｜接続画面もadd_repoも無い

ここからが今回の最低記録です。

Claudeに言われた通り「設定 → コネクタ → GitHubを接続」を実行しようとしたら、
すでに接続済みで、画面には「切断する」しかありませんでした。

次に「別のチャットで add_repo というツールを使って」と言われて、そのチャットに貼ったら、
そんなツールは存在しないと返ってきた。

さらにもう1回、別の確認を貼らされました。

同じ確認のために、3往復も私が伝言役をやりました。
しかも、そのうち1つの答えは、すでに私が会話の中に貼っていた内容の中にありました。
Claudeはそれを読み返さずに、もう一度私に聞いていた。

もーやだ…さっきからずっとお前の調査をサボったことで間違えたの繰り返しじゃん
マジで勘弁してほしい

このあと、「AIが作業者を伝言役にしない（伝言は1往復まで）」「質問する前に会話を読み返す」
というルールを保管庫に追加させています。

失敗⑧　「リポジトリを18個作ります」→ 権限エラー403｜そもそも不要だった

方針が固まって、「全プロジェクトをClaude Code on the webに移そう」となりました。

そのためにはプロジェクトごとにGitHubリポジトリが必要だとClaudeが言い、
「18個作ります、あなたの作業はゼロです」と宣言しました。

「作って下さい」と返したら、18個全部エラー。

403 Resource not accessible by integration

リポジトリを作る権限が無かった。 またしても、できると言う前に確かめていない。

しかもこの直後、そもそもリポジトリを18個作る必要が無かったことが判明します。
Claude Code on the webのセッションは、どのリポジトリを開いていても保管庫にアクセスできる。
最初から不要だったんです。

完成したClaude Code×Obsidianの記憶システム｜CLAUDE.mdとスラッシュコマンドで前提説明ゼロ

紆余曲折してやっとやりたいことができました。3日くらい掛かった…

いまは新しいセッションを開いて、リポジトリに obsidian を選んで、
/mindset のようにコマンドを1つ打つだけ。

それだけで、

• 私への接し方のルール
• 記憶の書き方のルール
• そのプロジェクトの方針
• 関連資料
• 直近の作業記録3件

が自動で読み込まれ、「直近の状況はこうです」と3行で報告してから指示待ちになります。
コピペはゼロ。前提説明もゼロ。

20プロジェクト分のコマンドを作ってもらいました。忘れたら /projects で一覧が出ます。

Vault（保管庫）のフォルダ構成はこうなりました。

• 00_Inbox … 形式を気にせず放り込む場所
• 10_Projects … プロジェクトごとの方針
• 20_Logs … 作業記録
• 30_Resources … GeminiやNotebookLMから持ってきた資料
• 99_Meta … ルール本体

そして CLAUDE.md という1枚のファイルに、全セッション共通の前提を書いています。
これがナレッジ全体の入口です。

記録の書き方も、AIは既存ファイルを絶対に書き換えず、常に新しいファイルを1つ作る方式に変えました。
これなら複数のAIが同時に書いても、内容が消えません。
実際、ルールファイルの更新中に競合が起きたんですが、この設計のおかげで無事でした。

念のため、別のセッションを立てて書き込みテストもしました。
そのセッションは私が何も教えていないのにルールを読み、
ファイル名も、属性の書き方も、保存先も、全部自力で正しく守りました。

ルールがちゃんと機能している。 そう確認できた瞬間でした。

22個の失敗の原因はたったひとつ｜調べる前に設計したこと

Claudeに「今日の失敗の原因は何だったのか」を書き出させたら、22個中の大半が
たった1つの原因に集約されました。

調べる前に設計した／確認する前に手順を書いた

技術的に難しい話は、ほとんど無かったんです。
出てきた失敗のほぼ全部が、「先に事実を確認していれば起きなかったこと」でした。

だから今回は、失敗した内容そのものを保管庫の中に
「過去に実際に起きた失敗」という表として残させました。いま12行あります。
新しいセッションは、作業を始める前に必ずこれを読みます。

AIに反省文を書かせるのではなく、次のAIが最初に読む場所に置く。
今回いちばんの収穫はここでした。

次にやること｜Claudianの認証エラーとWordPress自動入稿

• 各プロジェクトの方針（想定読者、文体、NGワード）を自分で書き込む。ここだけは人間の仕事
• Claudianの書き込みエラーを解決する
• WordPressへの自動入稿ができるか調べる
• Googleドライブに残っている古い記憶フォルダを削除する

まだ途中です。それでも「毎回ゼロから説明する」状態からは抜けられました。
もちろんいざ使ってみると色々と問題はあるのですがそれはまた、別の話。