公開日 2026.07.18 / 検証日 2026.07.18 / テック比較ジャーナル編集部
ChatGPTやCodexを毎日使っていると、地味に面倒なのが「前提の説明し直し」です。「前に決めた記事の方針を、また説明するのか」「このプロジェクトで避ける表現を、また最初から伝えるのか」。会話履歴やプロジェクト機能があっても、長く続く仕事ほど、情報はチャット、PDF、ブラウザ、ローカルフォルダへ散らばります。
そこで使いやすいのが、ObsidianにMarkdownで知識を保存し、Codexにそのフォルダを読ませて整理する方法です。構成は、Obsidianの保管庫、GitHubの非公開リポジトリ、Web Clipper、AI用の記憶ファイルを中心に考えます。ただし、最初から自動化を広げすぎると、GitHub認証、個人情報、Inboxの放置、AIへの権限の渡しすぎで詰まります。
何でも保存すれば賢くなるわけではありません。AIに必要なのは、日記の全文ではなく、次の仕事で再利用できる判断材料です。具体的には、決定した方針、繰り返し使うルール、失敗した手順、採用しなかった案、その理由、進行中プロジェクトの現在地です。
たとえばブログ運営なら、「タイトルは検索語を前に置く」「結論ボックスには固定フレーズを使う」「広告がある記事でも向いていない人を書く」「このテーマはすでに記事化済み」といった情報です。これらは毎回の会話ログより価値があります。逆に、雑談、仮説段階のアイデア、古い価格、未確認の数字まで記憶させると、AIは古いルールを真顔で再利用します。
この構成を理解するうえで大事なのは、ObsidianとCodexの役割を混ぜないことです。ObsidianはローカルのMarkdownファイルを中心に扱うため、知識の保存場所と人間が読む画面を担当します。Codexはフォルダ内のファイルを読み、名前を変え、分類し、要約し、重複を見つける作業を担当します。
Codexはコード専用と思われがちですが、OpenAIのCodex活用事例でも、複雑なシステムの理解、関係性の把握、ドキュメント不足の補完に近い使い方が紹介されています。Markdownの集合を「リポジトリ」として扱い、整理規則に沿って編集させる使い方はかなり自然です。ただし、AIが勝手に削除・移動できる状態から始めるのではなく、最初は変更案だけ出させる運用が安全です。
フォルダは、Inbox、Research、Projects、Prompts、AI-Memory、AI-Contextなどに分けられます。ただし、最初から細かくしすぎると分類だけで疲れます。日本の個人利用なら、まず次の7フォルダで十分です。
| フォルダ | 役割 | 入れるもの |
|---|---|---|
| 00-Inbox | 未整理の入口 | Web記事、メモ、PDF要約 |
| 10-Projects | 進行中の仕事 | 記事、開発、顧客案件 |
| 20-Research | 調査資料 | 一次情報、比較メモ、出典 |
| 30-Knowledge | 再利用知識 | 確定したノウハウ、手順 |
| 90-Templates | ひな形 | 記事、調査、会議メモ |
| 97-AI-Memory | 長期ルール | 好み、禁止事項、重要判断 |
| 98-AI-Context | 現在の文脈 | 進捗、次の作業、未解決点 |
97-AI-Memoryと98-AI-Contextを分ける理由は、更新頻度が違うからです。Memoryには半年後も使うルールを置き、Contextには今週の進捗を置きます。ここを一緒にすると、終了した案件の途中経過まで長期記憶として残り、別案件で誤参照しやすくなります。
最初にObsidianで新しいVaultを作ります。既存の大量VaultへいきなりCodexを接続するより、AI用の保管庫を別にした方が安全です。Vault名は短い英数字にし、同期先やターミナルで扱いやすくします。保存場所は自分で把握できる固定パスにしてください。
作成後は、上のフォルダを手動で用意し、ルートにREADME.mdを置きます。READMEには、この保管庫の目的、削除禁止、命名規則、個人情報を入れないこと、整理時は先に一覧を出すことを書きます。Codex用にはAGENTS.mdも用意し、「変更前に対象ファイルを列挙する」「削除せずArchiveへ移動する」「不明な分類はInboxに残す」と指定します。Codexではプロジェクト指示用のAGENTS.mdを使えるため、会話のたびに同じルールを貼り直す必要が減ります。
次にGitHubへ非公開リポジトリを作り、Vaultを同期します。GitHubの価値は、別端末から見られることより「いつ、どのファイルが、どう変わったか」を戻せる点です。Codexに一括整理させた後、分類が気に入らなければ差分を確認して戻せます。
ただし、GitHubへ置いたから安全とは限りません。顧客名、契約書、個人情報、APIキー、パスワード、ブラウザCookieは保存しないでください。Vault内に`.gitignore`を用意し、Obsidianの一時ファイル、添付の大容量データ、ローカル設定、秘密情報を除外します。業務利用なら会社の規程が優先です。
GitHub認証にPersonal Access Tokenを使う場合は、細かい権限を設定できるfine-grained tokenを優先し、対象リポジトリを限定する方が安全です。GitHub Docsでも、fine-grained tokenは特定のリポジトリや権限へ絞れると説明されています。トークンはパスワード管理ツールかOSの資格情報ストアへ保存し、チャット画面、Markdown、スクリーンショットへ貼らないでください。
情報収集にはObsidian Web Clipperが便利です。ブラウザで読んだ記事をMarkdownとして保存し、タイトル、URL、著者、取得日、本文をテンプレート化できます。ここで大事なのは、保存先をテーマ別フォルダにしないことです。
収集時点では、その記事が本当に使えるか判断できません。最初からResearchやKnowledgeへ直接入れると、未読資料と確定知識が混ざります。保存先は00-Inboxに固定し、週1回または記事作成前に整理します。タイトルには取得日を付け、frontmatterにsource、author、captured_at、statusを持たせると、後でCodexが機械的に分類しやすくなります。
一部のサイトはWeb Clipperで本文をうまく取得できません。Obsidian公式ヘルプでも、Web Clipperはページ設定に従って抽出するため、画像は自動ダウンロードではなくWeb上のURL参照になると説明されています。動的ページ、ログイン必須ページ、特殊なPDFでは、URLと短い要約だけ残す方が後で扱いやすいです。
Inboxに資料がたまったら、Codexへいきなり「全部整理して」と頼まない方がいいです。最初の指示は、対象ファイル数、重複、空ファイル、候補カテゴリ、削除候補を一覧にするだけにします。次に人が分類案を確認し、問題がなければ移動とリネームを実行させます。
たとえば、次のような依頼が実務向きです。
00-Inboxを走査し、各ファイルについて「保存価値」「推奨移動先」「重複の有無」「追加確認が必要な点」を表で出してください。この段階ではファイルを変更しないでください。長期的な再利用価値がない資料は削除せず、Archive候補として示してください。
承認後は、ファイル名を`YYYY-MM-DD-短い題名.md`へ統一し、内部リンクを追加し、ResearchかProjectsへ移動させます。Knowledgeへ移すのは、内容を自分で検証し、今後も使うと決めたものだけです。AI要約をそのままKnowledgeへ入れると、誤りが「確定知識」に昇格します。
たとえば「ChatGPTの新モデル比較」を書く場面を考えます。これまでなら、過去記事、執筆ルール、公式情報、読者の反応を毎回探し直します。この構成では、97-AI-Memoryに記事の固定ルール、98-AI-Contextに今回の記事の進捗、20-Researchに公式料金や仕様、10-Projectsに下書きを置きます。
Codexには最初に「MemoryとContextを読み、今回の作業に関係するルールだけを列挙して」と頼みます。次にResearch内の公式情報と記事下書きを照合し、古い数字や矛盾を報告させます。最後にHTMLを編集させます。ポイントは、Codexがすべてを覚えているのではなく、必要なときに正しいファイルを読む構造にすることです。
この方法なら、モデルを変えても知識が残ります。ChatGPT、Codex、Claude Code、Cursorなど、読む側のAIが変わっても、Markdownはそのまま利用できます。特定サービスの記憶機能だけに依存しないことが、長期運用の強みです。
一番起きやすい失敗は、保存だけ増えて整理しなくなることです。Web Clipperは楽なので、数週間で数百ファイルたまります。するとCodexに整理を頼んでも、分類基準が曖昧で、同じ内容が別フォルダへ分散します。
回避策は、Inboxの上限を決めることです。たとえば30件を超えたら新しい保存を止める、毎週金曜に15分だけ整理する、Projectsに関連しない記事はArchiveへ移す、といったルールです。さらに、statusを`unread / reviewed / used / archived`の4段階に限定すると、AIも人も迷いにくくなります。
AI-Memoryへ何でも追記すると、数万字の巨大ファイルになります。AIは読めても、重要度の低い情報が混ざり、古いルールと新しいルールが衝突します。人間も修正しなくなります。
おすすめは、Memoryを1枚にせず、`writing-rules.md`、`project-decisions.md`、`tool-preferences.md`、`do-not-do.md`のように分けることです。各ファイルの冒頭に「最終更新日」「適用範囲」「優先度」を書きます。古い内容を消すのが不安なら、Archiveへ移して履歴はGitHubに残します。
向いているのは、複数月にわたる執筆、研究、開発、コンテンツ運営をしている人です。毎回同じ指示をAIへ伝えている、過去の判断理由を探す時間が長い、ツールを乗り換えても知識を残したい人には効果があります。特にMarkdownとGitに抵抗がない人は導入しやすいです。
一方、短い質問だけをAIへ投げる人、ファイル整理を続ける気がない人、機密データを厳格に扱う必要があるのに社内承認を取れない人には向きません。Obsidianを入れれば自動的に記憶が育つわけではなく、整理ルールを維持する手間は残ります。
GitHubの設定が重いなら、最初はローカルVaultだけで始めても問題ありません。別端末同期が必要ならObsidian Sync、クラウドストレージ、NASなどの選択肢があります。ただし、複数同期方式を同時に使うと競合ファイルが増えるため、同期手段は1つに絞ります。
AIへの読み込みも、Codexだけが選択肢ではありません。Claude CodeやCursorでもフォルダを扱えます。ただし、どのAIを使う場合も、削除権限、シェル実行、ネットワークアクセス、秘密情報の扱いを確認してください。道具を変えても、保存庫と整理担当を分ける考え方は同じです。
初日にすべて作り込む必要はありません。まずVaultを作り、00-Inbox、10-Projects、97-AI-Memory、98-AI-Contextの4フォルダだけ用意します。Memoryに繰り返し使うルールを10個以内で書き、Contextに進行中の1案件だけ置きます。Web Clipperで5記事を保存し、Codexには分類案だけ出させます。
1週間使って、何度も参照した情報だけKnowledgeへ昇格させます。この順番なら、立派なフォルダ構成を作ったのに使わない、という失敗を避けられます。AIの長期記憶は、仕組みを増やすことより「残さない情報」を決める方が続きます。
PR: Obsidianでノート運用を学ぶ参考書
次のテンプレートは、角括弧の部分だけ自分の環境へ置き換えて使えます。最初の実行では監査と提案だけを行わせ、ファイル移動・削除・Git操作は承認後に進める設定です。
あなたは、ObsidianのVaultを長期知識基盤として整備するAIエージェントです。
Codex、Claude Code、Cursorなど、ローカルフォルダを扱えるエージェントで再利用できる構成にしてください。
【対象環境】
- Vaultの絶対パス: [ここにVaultのパス]
- GitHubリポジトリ: [非公開リポジトリURL/未設定なら「未設定」]
- 主な研究・業務領域: [AI、投資、マーケティング、開発など]
- 主な出力先: [ブログ、YouTube、社内資料、製品開発など]
- 使用OS: [Windows/macOS/Linux]
【目的】
会話履歴を丸ごと保存するのではなく、将来の判断や作業に再利用できる情報だけを残してください。
保存対象は、次の5種類です。
1. 繰り返し使える経験とノウハウ
2. 確定した意思決定と、その理由
3. 再利用できる作業フロー
4. 進行中プロジェクトの現在地と次の作業
5. 検証済みのベストプラクティス
【基本ルール】
- チャット履歴そのものは保存しない。
- 未確認の推測を確定情報としてAI-Memoryへ入れない。
- APIキー、Personal Access Token、パスワード、Cookie、個人情報、顧客の機密情報を保存しない。
- 私の承認前に、削除、移動、リネーム、上書き、git commit、git pushを実行しない。
- 削除候補は削除せず、理由を添えてArchive候補として示す。
- 既存ファイルを尊重し、同名ファイルを無断で置き換えない。
- ルールが衝突する場合は、新旧両方を残さず、衝突箇所と推奨する現行ルールを報告する。
- 出典がある資料には、source、author、captured_at、statusを残す。
- 不明な資料は無理に分類せず、00-Inboxに残す。
【推奨フォルダ】
00-Inbox 未整理の入口
10-Projects 進行中の仕事
20-Research 出典付きの調査資料
30-Knowledge 検証済みで再利用する知識
90-Templates 記事・調査・会議メモのひな形
97-AI-Memory 半年後も使う方針、好み、禁止事項、重要判断
98-AI-Context 現在の進捗、次の作業、未解決点
99-Archive 廃止ルール、終了案件、削除候補
【AI-Memoryの扱い】
- writing-rules.md: 執筆ルールと表現上の好み
- project-decisions.md: 重要な意思決定と理由
- tool-preferences.md: 利用ツールと選定理由
- do-not-do.md: 禁止事項、失敗例、再発防止策
各ファイルの冒頭に、最終更新日、適用範囲、優先度を記載してください。
【AI-Contextの扱い】
案件ごとに、目的、現在地、完了済み、次の作業、未解決点、参照ファイルを簡潔にまとめてください。
終了した案件の途中経過はAI-Memoryへ残さず、ProjectsまたはArchiveへ移す案を出してください。
【最初に行うこと】
1. Vault全体を読み取り専用で調査する。
2. 現在のフォルダ構成、ファイル数、重複候補、空ファイル、秘密情報の疑い、命名のばらつきを確認する。
3. 既存のREADME.md、AGENTS.md、.gitignore、Git設定を確認する。
4. 変更を実行せず、改善後のフォルダ構成と移動候補一覧を提示する。
5. 私の承認が必要な項目を明確に分ける。
【承認後に行うこと】
- 必要なフォルダ、README.md、AGENTS.md、.gitignoreの作成または更新
- 承認されたファイルだけの移動、リネーム、frontmatter整備、内部リンク追加
- 97-AI-Memory、98-AI-Context、10-Projectsの更新
- 変更内容の差分確認
- GitHubが設定済みの場合のみ、承認された単位でcommitする
【最終出力】
1. 完成後のディレクトリ構成
2. 完了した設定と変更ファイル
3. 未完了の設定
4. 私が手動で操作すべき手順
5. 現在の知識基盤の評価
6. 主要トピックとファイルの対応表
7. 重複、古いルール、情報不足などの弱点
8. 次に実行すべき優先順位付きの提案
9. Gitで戻す場合の復旧方法
最初は調査結果と実行計画だけを出してください。
提案だけで終わらず、承認後は実際のファイル操作まで進めてください。
初回は「読み取り専用で調査する」という条件を外さないでください。構成案が妥当だと確認できたら、「提案した変更のうち1〜5だけ実行して」のように範囲を限定して進めると、意図しない一括整理を防げます。
自動では覚えません。Codexが参照すべきファイルと順番をAGENTS.mdやプロンプトで指定する必要があります。長期記憶というより、必要な知識を毎回正しく読み込める外部メモリと考える方が正確です。
貼らないでください。認証はローカルのGitクライアントや資格情報ストアで済ませ、トークンをチャットやMarkdownに記録しない運用が安全です。漏れた可能性がある場合は、すぐに失効して作り直します。
技術的には可能でも、同期競合の原因になるため初心者にはおすすめしません。まず1つの同期方式に絞り、GitHubは履歴管理として使うのか、端末同期まで担わせるのかを決めてください。
おすすめしません。まずInboxへ置き、内容を確認してからResearchへ移します。AI-Memoryに入れるのは記事本文ではなく、そこから確定した自分のルールや判断です。
会社の情報管理規程と利用契約を確認できる場合に限ります。顧客情報、契約情報、未公開資料を個人のGitHubや個人契約のAIへ置くのは避け、法人管理された環境を使ってください。
Codexの基本的な使い方はCodexの機能と注意点、AIエージェント全体の比較はClaude Code・Codex・Antigravity CLI比較もあわせて確認してください。