連載「AIと『判断が育つ』仕事環境づくり」第3回
この記事でわかること
- 4つのツールの役割分担（Notion・GitHub・Obsidian・Eagle）
- 置き場所は「ファイルの種類」ではなく「次に何に使うか」で決める
- 「置いた」「届いた」「AIが読めた」は別々に確認が必要
前回（第2回）は、Mac miniを「仕事の母艦」にして、複数のMacを同期するところまでを書きました。今回は「じゃあ何をどこに置くの？」という話です。
ツールが増えるほど、分からなくなる
環境を整えていくと、次の問題が出てきました。
Notionがある。GitHubがある。Obsidianがある。Eagleもある。ChatGPTもClaude Codeも使う。
便利なツールは増えたのに、
「これ、どこに置けばいいんだ？」
が分からなくなるんです。
全部Obsidianに集める方法もあります。全部Notionに寄せる方法もあります。でも僕は、無理に一元化しないことにしました。それぞれ役割が違うからです。
家にたとえると分かりやすいかもしれません。冷蔵庫、本棚、アルバム、日記帳。全部を一つの箱に入れたら、かえって何も見つからなくなりますよね。
Notion ＝「今の仕事を動かす場所」
Notionには、いま進んでいる仕事があります。
- プロジェクト
- タスク
- 企画
- 進行状況
- 関係者と共有する情報
つまりNotionは今の仕事を前に進める場所。ここにあるのは「現在」です。
GitHub ＝「案件で実際に起きたことの記録」
Web制作などの案件は、GitHubで管理しています。
ここに残っているのはコードだけではありません。
- いつ、何を変更したか
- 何を直したか
- 一度つくったものを、なぜ元に戻したか
- どんな不具合が起きたか
変更の履歴（コミット履歴）まで含めると、GitHubにはその案件で実際に起きたことがかなり残っています。
だからGitHubを単なる「コード置き場」ではなく、案件の記録帳として考えるようになりました。
Obsidian ＝「案件を超えて使える判断」
一番悩んだのが、Obsidianに何を置くかです。
最終的には、案件を超えて使える、自分自身のKnowledge（知識）を置くことにしました。
ある案件の仕様をそのまま入れるのではありません。「この案件ではこうした」という記録でもありません。複数の仕事で使える、
- 「こういうときは、ここを確認する」
- 「以前、この判断で失敗した」
- 「この条件なら、こう考えたほうがいい」
といった知識です。
GitHub ＝ 案件の記録（何が起きたか）
Obsidian ＝ 案件を超えた判断（次にどう考えるか）GitHubが「日誌」なら、Obsidianは日誌から抜き出した「自分だけの教科書」のようなものです。
最初からこの分担だったわけではない
実は最初、KnowledgeもNotionで管理しようとしていました。Notionにはすでに「Knowledge Base」というページがあり、手引書やテンプレート、教材などを置いていたんです。
でも、Obsidianを使うと決めたからといって、それらを全部移せばいいわけでもありませんでした。
改めて棚卸しをすると、同じ「知識っぽいページ」の中にも、役割の違うものが混ざっていました。
| ページの例 | 中身 | 置き場所 |
|---|---|---|
| WordPress構築手引書 | 過去の案件から得た判断や失敗の知見 | Obsidianの既存Knowledgeと照らし合わせる候補 |
| 実施日や次回メモのあるカリキュラム | 今の仕事を進めるための記録 | Notionに残す |
| 教材の完成原稿 | 教材そのもの | Notionに残す（ただし「他の研修でも使える判断の型」だけはKnowledgeとして取り出せる） |
この段階でやったのは棚卸しまでで、すべての移行が終わったわけではありません。
それでも、一つはっきりしました。
置き場所は、ファイルの種類では決められない。「その情報を次に何のために使うのか」で決める。
Eagle ＝「目で考えるための記憶」
Eagleは少し毛色が違います。
デザイン、写真、構図、パッケージ、Webサイト、広告。僕の仕事では、
- 「これに近い雰囲気」
- 「この構図がいい」
- 「この質感を参考にしたい」
といった、言葉だけでは扱いにくい情報がたくさんあります。それをためておくのがEagleです。僕にとっては目で見るKnowledgeの置き場所に近い存在です。
将来的には、Eagleの素材をAIから参照できるようにすることも構想に入れています。ClaudeなどのAIが素材を検索できるようになれば、「自分が過去に集めた参考資料を、AIと一緒に見る」ことができる。ここにはかなり可能性を感じています。
全体像：全部を一つにしない
最終的な整理はこうなりました。
| ツール | 役割 |
|---|---|
| Notion | 今の仕事を動かす |
| GitHub | 案件で起きたことを残す |
| Obsidian | 案件を超えて使える判断を残す |
| Eagle | ビジュアルの経験・参考資料を残す |
| Syncthing | ObsidianやEagleのデータを端末間で同期する |
| AI | 必要なものを読み、探し、比べ、次の仕事へつなぐ |
一元化ではありません。
役割を分けたうえで、AIが横断的につなぐ
という考え方です。
GitHubに置いたからといって、AIが読めるとは限らない
役割を分けると、次は「ちゃんとつながっているか」の確認が必要になります。
Claudeでは、Obsidianへの接続先を直して、新しい保存場所につながったことを確認できました。
一方、ChatGPTからは、GitHubにバックアップしたObsidianのメモを読む方法を試しました。ここでも、「GitHubのリポジトリ（保存場所）につながること」と「Knowledgeの中身を検索できること」は別の話でした。
リポジトリ自体は見えるのに、Knowledgeを検索しても結果が出ない。調べると、そもそも最初はKnowledge/フォルダがGitに記録（commit）されていなかったんです。
その後、GitHubへの送信は成功し、ブラウザでもフォルダを確認できました。ただ、ChatGPTからKnowledgeの本文を検索・参照できるところまでは、この時点ではまだ確認できていません。
ここで学んだのは、次の3つを分けて確認することです。
- 置き場所を決める
- そこへ実際に届いているか確かめる
- AIから実際に読めるか確かめる
でも、ObsidianのKnowledgeは誰が書くの？
ここまで整理すると、新しい問題が出てきます。
GitHubには大量の経験が残っている。でもそれを毎回自分で読み返して、「この案件から得た学びは……」とObsidianにまとめるのか。
正直、たぶんやらなくなります。最初の3案件くらいは頑張って、そのうち面倒になって終わる。
だったら、
案件の記録をAIに読ませて、Knowledgeの候補を取り出してもらえばいいのでは？
ここで初めて、Claude Codeを使った仕組みづくりが始まりました。
まとめ
- ツールは無理に一元化せず、役割で分ける
- Notion＝今、GitHub＝記録、Obsidian＝判断、Eagle＝ビジュアル
- 置き場所は「ファイルの種類」ではなく「次に何のために使うか」で決める
- 「置いた」「届いた」「AIが読めた」は別々に確認する
- Knowledgeを人力で書き続けるのは難しい → AIに候補を出してもらう発想へ