Codex × Obsidian上級編：Markdownだけで作る軽量RAGとAI知識基盤

前回は、ObsidianをCodexの「外部記憶」として使う方法を紹介しました。

次の段階では、単にCodexがVaultを読むだけでは足りません。

重要なのは、必要な知識をCodex自身が選ぶこと、古い情報を避けること、確認済みの事実だけを使うこと、そして使い終わった知識を再利用可能な形で戻すことです。

ここまで来ると、Obsidianは単なるノート置き場ではなく、Codexが利用する「知識基盤」に変わります。

上級編のゴール

目指す構成は次の通りです。

Sources → Research → Decisions → Codex → Drafts → Published

さらに、Codexは依頼内容に応じて必要なノートだけを読みます。

人間が毎回ファイルを指定する状態から、Codexが自分で読むべき知識を判断する状態へ進化させます。

1. VaultをAI向けに分ける

おすすめ構成は次の通りです。

  • Sources/：原資料や一次情報
  • Research/：確認済みの事実や調査結果
  • Decisions/：過去に何を選び、なぜそう判断したか
  • Drafts/：生成中の文書
  • Published/：完成済みの成果物
  • TODO/：未確認事項や追加調査

この構成にすると、Codexにルーティングルールを持たせやすくなります。

2. frontmatterで「知識の品質」を管理する

Markdownの先頭にメタデータを持たせます。

---
type: research
topic: pixel
status: verified
updated: 2026-08-15
expires: 2027-02-15
source_count: 5
confidence: high
---

Codexには、「status: verifiedで、expiresを過ぎていないResearchだけ使う」と指示できます。

これで古いノートを誤って使うリスクを減らせます。

3. Decisionsフォルダが意外と重要

Researchには事実を保存します。一方、Decisionsには判断を保存します。

  • Pixel 11 Proを推した理由
  • なぜこのSEOタイトルにしたか
  • なぜこの構成を採用したか
  • 前回の失敗と改善点

AIは事実だけでなく、過去にどう判断したかも読めると一貫性が上がります。

4. Markdownだけで軽量RAGを作る

本格的なRAGではベクトルDBを使うことがあります。

ただし個人利用なら、いきなりそこまで複雑にする必要はありません。

まずは、フォルダ、タグ、frontmatter、ファイル名、MOCを使って必要なノートを絞ります。

流れは、質問 → 該当フォルダを選択 → frontmatterで絞る → 関連ノートを読む → 生成です。

厳密な意味でのRAGそのものではありませんが、実用上は「検索してから生成する」軽量なRAG風運用として使えます。

5. Codexに自動ルーティングさせる

AGENTS.mdに、たとえば次のようなルールを書きます。

  • 製品仕様はResearchを読む
  • 過去判断はDecisionsを読む
  • 未確認情報はTODOを見る
  • Publishedは参考用で編集しない
  • Sourcesは原則読み取り専用
  • 最新のverifiedノートを優先する

これにより、「Pixel 11 Proの記事を書いて」とだけ依頼しても、Codexが読む場所を判断しやすくなります。

6. 普遍ルールはAIに変更させない

Codexに自由度を与えるほど、もうひとつ重要になるのが「AIに変えさせてはいけないルール」を決めることです。

記事ごとの見出し数やキーワード、対象読者のような条件は変わっても構いません。

一方で、文章の人格や事実の扱い方までAIに最適化させると、記事ごとに口調がぶれたり、いかにもAIが書いたような文章になったり、自分のブログらしさが失われる可能性があります。

そこで、ルールをPermanent RulesとProject Rulesに分けます。

Permanent Rules：変更禁止の普遍ルール

Permanent Rulesには、記事やプロジェクトが変わっても維持したい方針を書きます。

  • AI特有の大げさで抽象的な表現を避ける
  • 記事全体で日本語の口調を統一する
  • 不要な「非常に」「圧倒的」「革新的」などを多用しない
  • 同じ意味の表現を何度も繰り返さない
  • 結論を不必要に引き延ばさない
  • 根拠のない事実を追加しない
  • 出典のない数値や日付を勝手に生成しない
  • 読者を過度に煽る表現を使わない
  • 公開前には人間が確認する
  • Permanent Rules自体をCodexが変更・削除・緩和しない

特に最後の「このルール自体を変更させない」という指定が重要です。

Project Rules：案件ごとに変えてよいルール

一方、Project Rulesは柔軟に変更します。

  • 記事の文字数
  • 見出し数
  • 対象読者
  • SEOキーワード
  • 比較対象
  • 出力形式
  • 対象フォルダ
  • 今回だけ使う資料

つまり、AIに自由を与える範囲と、絶対に守らせる境界を分けるわけです。

AGENTS.mdにも変更禁止を明記する

たとえばAGENTS.mdの冒頭に、次のような考え方を置きます。

# Permanent Rules

以下のルールは変更・削除・緩和しない。

- AIっぽい大げさで抽象的な文章を避ける
- 日本語の口調を記事全体で統一する
- 根拠のない事実を追加しない
- 出典のない数値や日付を生成しない
- 読者を過度に煽らない
- Permanent Rules自体を編集しない

この考え方は文章生成だけではありません。ファイル削除、公開判断、認証情報の扱いなど、絶対にAIへ自己変更させたくない運用ルールにも使えます。

Codexが賢くなっても、自分の文章スタイルや判断基準までAIに最適化させないことが、長期運用では重要です。

7. 知識の「期限切れ」を管理する

AI知識基盤で怖いのは、古い情報をそのまま使ってしまうことです。

そこでexpiresを使います。

たとえば価格情報なら数か月、製品仕様なら一定期間、制度情報ならより短い期間など、情報ごとに更新期限を決めます。

Codexには、「期限切れResearchは使用せず、要再調査としてTODOへ追加」と指示できます。

8. Codexに定期監査させる

知識ベースは放置すると古くなります。

週1回や月1回、次のような項目を一覧化させます。

  • expires切れ
  • sourceなし
  • confidence low
  • 重複ノート
  • TODO放置
  • リンク切れ
  • 更新日が古いResearch

ここまで来るとCodexは「使うAI」だけでなく、知識ベースを保守するAIにもなります。

9. NotebookLMは調査専用に寄せる

NotebookLMには大量資料を読ませ、次のような情報だけを抽出します。

  • fact
  • source
  • date
  • exception
  • uncertainty

その結果をResearchへ保存し、CodexはResearchだけを読んで生成します。

これにより、調査と生成を分離できます。

10. 生成した成果物を知識へ戻す

完成した記事や文書は、Publishedへ保存します。

さらに、「この記事から新しく得た判断や知見をDecisionsへ追記」まで行うと、知識ベースが循環します。

読む → 作る → 学ぶ → 保存するというループです。

11. Gitを使ってAI編集を監査する

上級運用ではGitがかなり重要です。

Codexが大量編集した場合でも、何を変えたか、どのファイルを変えたか、元に戻せるかを確認できます。

AIに自由度を与えるほど、ロールバック手段も必要になります。

12. 半自律ブログ運用

ブログ用途なら最終形は次のようになります。

NotebookLMで資料確認 → Obsidian Researchへ事実保存 → Codexが必要ノートを選択 → ChatGPTで切り口・構成レビュー → CodexでBlogger用HTML生成 → 人間が確認・承認 → Bloggerへ反映

完全自動ではなく、人間の承認を残すのがポイントです。

事実確認、タイトル、結論、公開判断などは人間が確認した方が安全です。

13. さらに先はベクトルDBやMCP

Vaultが数千〜数万ノート規模になれば、Markdownだけの検索では限界が出る可能性があります。

その段階で、次のような拡張を検討できます。

  • ベクトルDB
  • 埋め込み検索
  • MCP
  • 専用インデックス
  • ローカル検索サービス

ただし、最初から導入する必要はありません。

まずMarkdownとfrontmatterで運用し、限界が見えてから拡張する方が管理しやすいです。

まとめ

上級編では、Obsidianを単なるCodexの外部記憶として使うだけではありません。

Codexが自分で必要な知識を選び、古い情報を避け、使った結果を再び知識へ戻すところまで発展させます。

そして、その自由度を高めるほど、AIに変更させない普遍ルールを明確にすることが重要になります。

重要なのは、次のポイントです。

  • 構造化
  • メタデータ
  • 鮮度管理
  • 自動ルーティング
  • Permanent RulesとProject Rulesの分離
  • 文章の口調・事実ルールの固定
  • 定期監査
  • 人間承認
  • ロールバック

ここまで設計すると、Obsidianはノートアプリではなく、Codexが読み、判断し、保守できる個人向けAI知識基盤になります。

AIエージェントには自由を与える。ただし、文章の人格、事実の扱い、安全に関わるルールまで自由に変更させない。この境界を作ることが、長く使えるAI知識基盤の重要な設計になります。

そして次のステップは、Markdownだけの軽量RAGから、ベクトル検索やMCPを使った本格的なエージェント基盤へ進むことです。

コメント

コメントを投稿

このブログの人気の投稿

初心者でもわかるMFCとVC++の基本：Visual Studio開発入門

初心者でもわかるMFCとVC++の基本：Visual Studio開発入門 MFCでWindowsアプリ開発を始めるには？ 「MFCって何？」と思っている方へ、今回はMicrosoft Foundation Class（MFC）とその基本をわかりやすく解説します。特に、VC++（Visual C++）を使ったWindowsアプリケーション開発を始めるための導入としてぴったりな内容です。 そもそもMFCとは何か？ MFCは、マイクロソフトが提供するWindowsアプリケーション構築用のクラスライブラリです。VC++（Visual C++）に付属しており、Windowsプログラミングを簡素化するために作られました。たとえば、ボタンをクリックした際に何か処理をする、といったイベント駆動型のプログラムが簡単に作れます。 最近では.NETや他のフレームワークが台頭していますが、MFCはまだ多くの企業やシステムで利用されています。 基本のメソッド：スタティックとインスタンス メソッドには2種類あります。1つはスタティックメソッド、もう1つはインスタンスメソッドです。 スタティックメソッドは、クラスそのものに属しており、クラスをインスタンス化せずに呼び出すことができます。例として、数学計算に使われるMathクラスのメソッドがあります。 Math::Sqrt(9); // 結果は 3 一方、インスタンスメソッドは、そのクラスを生成（インスタンス化）してからでないと呼び出せません。たとえば、オブジェクトの状態に依存する操作を行う場合に使います。 ガベージコレクション：メモリ管理を楽にする仕組み 「メモリリーク」という言葉を聞いたことがあるかもしれません。これは、プログラムが使い終わったメモリを解放せず、無駄なメモリを消費し続ける現象です。そこで登場するのがガベージコレクションです。 ...
Read more »

フォントサイズ単位の比較と換算表【Windows・Android】

フォントサイズには、 px・pt・dp・sp など複数の単位があります。しかも同じ「px」でも、WebのCSSピクセル、Windowsの論理ピクセル、ディスプレイ上の物理ピクセルは必ずしも1対1ではありません。 この記事では、WindowsとAndroidを中心に、フォントサイズ単位の違いと換算の考え方を整理します。デザインデータを別のプラットフォームへ移すときや、「12ptは何px？」「Androidでは何spにすればよい？」と迷ったときの参考にしてください。 1. フォントサイズ単位の違い 単位 主な使用環境 特徴 px Web、Windows、Android内部 ピクセルを表す単位。ただしCSS pxやWindowsの論理ピクセルは、必ずしもディスプレイの物理ピクセルと1対1ではない pt 印刷、DTP、Windows 1pt = 1/72インチを基準とする絶対長の単位 dp / dip Android 画面密度の違いを吸収するための密度非依存単位。160dpiを基準に1dp = 1pxとなる sp Androidの文字 dpと同様に密度を考慮し、さらにユーザーのフォントサイズ設定を反映する文字用単位 2. 「px＝物理ピクセル」ではない フォントサイズを考えるうえで、最も混乱しやすいのがpxです。 ディスプレイには実際の画素である 物理ピクセル がありますが、WindowsやWebでは、アプリやブラウザが扱う論理的な座標単位が別に存在します。 Windowsでは長年、 1論理インチ = 96ピクセル を基準としてきました。Microsoftの説明では、この基準では72ptの文字が96論理ピクセル、12ptの文字が16論理ピクセルに相当します。 つまり、Windowsで「16px」と指定したからといって、常にディスプレイ上の16個の物理ピクセルだけで表示されるとは限りません。表示倍率やDPIによって、1つの論理ピクセルを複数の物理ピクセルで描画する場合があります。 3. Windowsでのptとpxの基本換算 Windowsの標準的な論理DPIである96dpiを基準にすると、次の関係になります。 1インチ = 72pt 1論理インチ = 96px 1pt = 96 ÷ 72 = 約1.333px 1...
Read more »

プロジェクト参画初日の効率的な情報整理と2週間でキャッチアップするための方法

イメージ
案件参画時に確認すべき重要な情報：初日からスムーズにプロジェクトを進めるために 案件参画時に確認すべき重要な情報 プロジェクトに参画する際、特に初日には、多くの重要な情報を取得し、スムーズな進行を確保するための準備が求められます。ここでは、案件参画時に確認すべき情報とその活用方法について解説し、プロジェクトを成功させるための基本的な手順をまとめました。 1. 目的・方針・背景の確認 案件に参画する最初のステップとして、プロジェクトの目的や方針、背景を確認することが非常に重要です。これにより、プロジェクト全体の方向性やゴールを理解し、自分の役割を明確にできます。以下の資料を基に、目的や背景を把握しましょう。 プロジェクト提案書 : プロジェクトの目的や、なぜこのプロジェクトが重要かが記載されています。 要件定義書 : プロジェクトの技術的な要件や範囲、必要な成果物が記載されています。 プロジェクト計画書 : プロジェクトのスケジュールやタスクの詳細が確認できます。 2. スケジュールとタスクの確認 プロジェクトのスケジュールを理解することは、各タスクの進行状況や優先順位を正しく判断するために欠かせません。特に重要なのは、遅延が全体にどのような影響を与えるかを把握し、適切なアクションを取ることです。次のドキュメントを確認しましょう。 WBS（Work Breakdown Structure） : プロジェクトの全タスクを階層化し、依存関係を示しています。 プロジェクト計画書 : 全体の進行スケジュールや、マイルストーンが記載されています。 3. 体制と役割分担の理解 チームメンバーやステークホルダーの役割を理解することは、プロジェクトのスムーズな進行に大きく寄与します。誰がどのタスクに責任を持っているのかを把握することで、必要な情報を迅速に得ることができ、問題が発生した際の対応も迅速化されます。以下の資料を参考にしましょう。 組織図 : チーム全体の構成や、各メンバーの役...
Read more »