Claude Code × Codex × Obsidianで作る「自己代謝型ナレッジシステム」

8月 19, 2026

AIエージェントを本格的に使い始めると、仕事のボトルネックが変わってきます。

以前は「情報を探す」「資料を読む」「コードを書く」「文章を書く」ことに多くの時間を使っていました。Claude CodeやCodexのようなエージェントを使えば、この部分はかなり高速化できます。

ところが、そこで仕事が終わるわけではありません。むしろ次に、もっと厄介な仕事が残ります。

「で、どれを信じるのか？」

AIが短時間で大量の情報を集められるようになれば、人間が一件ずつ検索する必要は減ります。しかし、「この情報源は信用できるのか」「これは現在も有効なのか」「一次情報なのか、誰かの解釈なのか」「複数の情報が矛盾しているが、どちらを採用するのか」「AIが作った複数案のうち、本番環境へ入れていいのはどれか」という仕事は残ります。

これからは、人間の時間のかなりの部分が、この判断に使われるようになるのではないかと思っています。

だからClaude Code、Codex、Obsidianを組み合わせて作るべきものは、単なる「第二の脳」ではありません。必要なのは、情報の出所、鮮度、検証状態、採用状態まで管理できるナレッジシステムです。

情報をたくさん与えればAIは賢くなる、という誤解

最初に陥りやすいのが、「AIに情報をたくさん与えれば、それだけ賢くなる」という考え方です。

会議メモ、設計資料、過去の意思決定、技術調査、障害対応、AIとの会話。全部Obsidianへ保存して、Claude CodeやCodexからアクセスできるようにする。一見すると理想的です。

しかし、情報が増えてくると問題が起こります。2024年の調査ではA、2025年にはB、2026年にはC。でも昔のAも検索すると出てくる。

AIにとって難しいのは、情報を「見つける」ことではありません。見つけた情報の中から、今どれを信じるべきか判断することです。

長大なドキュメントより「地図」を作る

そこで最初に必要になるのが、ナレッジの分割です。

巨大なknowledge.mdに何でも詰め込むのではなく、architecture.md、security.md、decisions.md、operations.md、current-stack.mdのように意味のある単位へ分け、Obsidianの[[WikiLink]]などで接続します。

Claude CodeならCLAUDE.md、CodexならAGENTS.md。これらにもすべての知識を詰め込むのではなく、「何を知りたければ、どこを見るべきか」という地図を置きます。

重要なのは、エージェント向け指示書を百科事典にしないことです。常に必要な原則と入口だけを置き、詳細な知識は構造化されたMarkdownへ分離する。この設計なら、コンテキストを無駄に圧迫せず、古いルールが重要な指示に紛れ込む問題も抑えられます。

ObsidianのWikiLinkをAIは辿ってくれるのか？

ここは重要です。

たとえば[[Authentication]]というリンクがあれば、Claude CodeやCodexがその文字列を手掛かりとして、アクセス可能なファイルを検索・参照することはできます。

しかし、WikiLinkを書けば、自動的にリンク先がすべてコンテキストへ展開されると考えてはいけません。

むしろ、そうならないほうが都合がいい場合があります。なぜならリンクを無制限に辿ると、情報量が爆発するからです。

1ページから10ページ、その10ページからそれぞれ10ページ、さらにその先にも10リンクあるとすれば、候補は10、100、1,000と急速に広がります。

必要なのは「全部読む」能力ではありません。読むべきものを選ぶ能力です。

「リンクのリンク」は必要になったときだけ読む

そこで探索を、次の順番にします。

Task → Map → Relevant Document → Deep Link

たとえば「認証方式を変更して」というタスクなら、まず地図を見る。そこからAuthenticationへ進む。そこで今回の変更にセッション管理が関係すると判断したら、初めてSessionを読む。さらにDB変更が必要ならDatabaseへ進む。

つまり、必要性を判断してから、次のリンクへ進む。リンクの深さを固定する必要もありません。重要なのは、無条件に再帰探索しないことです。

WikiLinkだけに依存しない

AIは人間と同じ方法でObsidianを使う必要はありません。

人間はWikiLinkをクリックします。しかしClaude CodeやCodexなら、ファイル名検索、全文検索、grep、ディレクトリ、タグ、メタデータといった手段でも情報を探せます。

したがってAI向けVaultでは、Map + Search + WikiLinkの組み合わせが重要になります。

リンクは関係性を示す。Mapは入口を示す。Searchは未知の情報を発見する。それぞれ役割が違います。

Claude CodeとCodexで知識そのものを分断しない

Claude CodeとCodexを両方使うのであれば、ナレッジをどちらか一方専用にしすぎないほうがいいでしょう。

共通知識：Markdown / Obsidian
Claude Codeの入口：CLAUDE.md
Codexの入口：AGENTS.md

設計思想、採用技術、過去の意思決定、障害情報などは共通のMarkdownとして残す。CLAUDE.mdとAGENTS.mdには、それぞれのエージェントが「どこへ行けば何があるか」を理解するための薄いレイヤーを置く。

そうすればClaude CodeからCodexへ移っても、知識そのものを作り直す必要がありません。

情報が増えると、メンテナンスの問題が始まる

このシステムを半年、1年と運用すると、Vaultには大量の情報が蓄積されます。

同じテーマのページが複数ある。昔の設計が残っている。実験だけして不採用になった案がある。AIが生成しただけで誰も確認していない情報がある。古いリンクがある。同じ概念なのに名前が違う。現在の仕様と昔の仕様が検索結果に同時に出る。

つまり、情報を集めるフェーズから、情報をメンテナンスするフェーズへ移ります。

しかもAIによって情報生成が高速化すると、この問題はむしろ大きくなります。ナレッジ管理をAIで自動化しても、ナレッジ管理そのものが不要になるわけではありません。情報が増える速度が上がれば、放置したときに腐る速度も上がります。

AIには再現性がない。それを前提にする

Claude CodeでもCodexでも、同じ課題から常に同じ答えが出るとは限りません。

それなら、無理に一発で正解を出させる必要もありません。重要なタスクでは、複数回試して、良い出力を採用するという運用が現実的です。

A案、B案、C案を作る。Claude Codeで作った案をCodexにレビューさせてもいい。Codexで複数案を作り、Claude Codeに別視点から評価させてもいい。

問題はその後です。A、B、Cを全部ナレッジへ入れてしまったら、半年後のAIにはどれが正解なのか分かりません。

だから保存すべきなのは単なるAI出力ではなく、「Bを採用した」という意思決定です。できれば、「なぜBなのか」も残します。

情報には「状態」を持たせる

そこで情報にライフサイクルを持たせます。

Draft：収集または生成しただけ。未検証。
Verified：一次情報、実験、人間による確認などで検証済み。
Adopted：現在のシステムやプロジェクトで採用中。
Outdated：過去には有効だったが、現在は古い。

これだけでも大きく変わります。AIがDraft / 2025とAdopted / Verified 2026を発見したとき、同じ重みで扱う必要がなくなるからです。

「更新日」だけでは危険

updatedだけでは不十分です。

2024年に調査した技術情報の誤字を2026年に直せば、更新日は2026年になります。しかし内容自体は2024年の情報かもしれません。

そこでcreated、updated、verifiedを分離します。

文章を最後に編集した日と、情報そのものを最後に検証した日は別物です。情報の新しさではなく、検証の新しさを見ることが重要になります。

使った情報は、その場で再検証する

さらに効率を上げるなら、Vault全体を定期的に人間が棚卸しするのではなく、使われた情報から再検証するという運用ができます。

たとえばCodexが今回の実装で、8か月前の設計判断を参照した。重要な判断なら「この前提は現在も正しいか？」を確認する。正しければverifiedを更新し、変わっていれば内容を更新する。

Read → Verify → Use → Update

利用頻度の高い知識ほど自然に鮮度が維持されます。

古い情報は削除しない。ただし「現在の正解」から降ろす

以前Aという方式を採用し、問題が発生してBへ変更したとします。

Aを完全に削除すると、半年後にClaude CodeやCodexがAを再提案するかもしれません。

そこで、status: outdated、superseded_by: [[Decision-B]]、廃止理由などを残します。

すると、「Aは知らない」のではなく「Aは知っているが、現在は採用しない」という状態を作れます。

古い情報はゴミではありません。過去の失敗を繰り返さないための知識でもあります。ただし、現在の情報と同じ重みで扱わないことが重要です。

最終的にボトルネックになるのは「人間の判断」

ここまで自動化すると、面白い逆転が起きます。

AIが情報を集める。AIが要約する。AIがリンクする。AIが複数案を作る。AI同士でレビューする。テストもAIが実行する。これらはどんどん高速になります。

しかし最後に残るのが、「これを信じていいのか？」という判断です。

そして、これから人間の時間の多くがここへ移っていく可能性があります。

情報収集のコストが100から10になったとしても、判断すべき情報が10倍になれば、判断コストはむしろ増えるかもしれません。

だからAI時代の生産性を「どれだけ大量に生成できるか」だけで測るのは危険です。本当に希少になるのは、人間の判断力と注意力です。

その情報は「どこから来たのか？」

そこでナレッジシステムに、もう一つ必要になる情報があります。

Source（情報源）です。

「Claude Codeについてこう書いてある」だけでは不十分です。

Anthropicの公式ドキュメントなのか。OpenAIの公式ドキュメントなのか。GitHub Issueなのか。誰かのブログなのか。コミュニティ投稿なのか。AIが別の記事を要約したものなのか。自分たちの実験結果なのか。

これらは同じ信頼度ではありません。

だからナレッジには、source、source_type、retrieved_at、verified_atなどを持たせる価値があります。必要ならofficial、primary、secondary、community、internal-testのように情報源を分類してもよいでしょう。

重要なのは、「何を知っているか」と同時に「なぜそれを知っているのか」を保存することです。

PoCなら雑でもいい。本番はそうはいかない

個人の実験やPoCなら、「たぶんこれで合っている」でも進められる場面があります。間違っていたらやり直せばいい。

しかし本番環境へ載せるシステムでは話が変わります。

セキュリティ、個人情報、料金、法令、データベース変更、外部API、インフラ、認証。こうした判断で「AIがそう言っていました」は根拠になりません。

どの情報源に基づいて判断したのかを追跡できる必要があります。

本番システムへ近づくほど、ナレッジ管理は単なるメモ管理から、プロベナンス（情報の来歴）管理へ変わっていきます。

「正しい情報」ではなく「検証可能な情報」を残す

ナレッジベースに「絶対に正しい情報」だけを保存しようとすると、運用できません。

情報は変わります。仕様も変わります。AIも間違います。公式ドキュメントでさえ更新されます。

だから目標は、正しい情報だけを保存することではありません。必要になったときに、その正しさを再検証できる状態で保存することです。

そのためにSourceが必要です。検証日が必要です。状態が必要です。過去の判断理由が必要です。

ナレッジの価値は「本文＋メタデータ」で決まる

こう考えると、一つのMarkdownページの価値も変わります。

status: adopted
created: 2025-04-12
updated: 2026-08-15
verified: 2026-08-10
source: 公式ドキュメント
source_type: primary
supersedes: [[Old Decision]]

こうした情報があれば、Claude CodeやCodexは「何が書かれているか」だけではなく、「現在使ってよいのか」「いつ確認されたのか」「何を根拠にしているのか」「以前は何を使っていたのか」まで判断材料にできます。

情報が増えるほど「Lint」が重要になる

もちろん、こんなシステムを作ればメンテナンスは増えます。

重複、リンク切れ、古い情報、未検証情報、Sourceのない情報、長期間再検証されていないAdopted情報、矛盾するページ、巨大化したページ。

これらを放置すると、Vaultは徐々に腐ります。

だからコードと同じように、ナレッジにもLintが必要になります。

SourceのないAdopted情報を列挙する
長期間Verifiedされていないページを探す
OutdatedなのにCurrent側から参照されている情報を探す
同じテーマで矛盾している記述を探す
巨大化したページを分割候補として出す

ここはClaude CodeやCodexが得意な仕事です。

人間が全部読むのではなく、AIに「判断が必要な場所」を絞り込ませる。そして最後だけ人間が判断する。

AIの役割は「答えを出すこと」から「判断材料を整えること」へ

ここまで来ると、Claude CodeやCodexの役割も変わって見えてきます。

大量の情報から現在の候補を探す。Sourceを確認する。古い情報を検出する。矛盾を発見する。複数案を生成する。テストする。比較する。

そして、「人間が判断すべきポイント」を圧縮して渡す。

人間は100件の情報を読むのではなく、「公式仕様ではこう」「実環境のテストではこう」「過去にはBだったが現在はOutdated」「したがって候補はAとC」という状態まで整理されたものを判断する。

AIに人間の判断を完全に置き換えさせるのではなく、人間の判断コストを最小化するためにAIを使う。本番運用では、この考え方が重要になってきます。

「自己進化」ではなく「自己代謝」

情報を収集する。要約する。ページを作る。WikiLinkを増やす。

これだけなら自己進化ではありません。自己増殖です。

本当に必要なのは、次の循環です。

Ingest → Structure → Link → Source → Verify → Compare → Adopt → Re-verify → Deprecate → Compress

情報を入れる。構造化する。接続する。出所を残す。検証する。複数案を比較する。採用する。使うときに再検証する。古くなったら降格する。増えすぎたら圧縮する。

これは「成長」というより、代謝です。

だからClaude Code、Codex、Obsidianで本当に作りたいものを、私は自己代謝型ナレッジシステムと呼ぶほうが本質に近いと思っています。

最後に残るのは、人間の「編集責任」

AIによって情報収集は安くなります。コード生成も文章生成も、複数案を作ることさえ安くなります。

しかし、何を信じるか。何を採用するか。どのリスクを取るか。どの情報源を信用するか。いつ再検証するか。どの古い情報を残すか。

これは依然として重要です。

むしろAIが大量の仕事を高速に処理できるようになるほど、人間の仕事は「作ること」から「選ぶこと」へ移っていく。

だから未来のナレッジシステムで本当に重要なのは、情報量ではありません。WikiLinkの数でもありません。コンテキストウィンドウの大きさでもありません。

「この情報はどこから来て、いつ検証され、なぜ採用され、今も信頼できるのか」を追跡できることです。

Obsidianは、その記憶を保持する。Claude CodeとCodexは、そこを探索し、整理し、検証を助ける。そして人間は、最後に判断する。

この役割分担ができれば、昨日の仕事が今日のAIを賢くするだけではありません。昨日の間違いも、古くなった知識も、採用しなかった案も含めて、「なぜ今、この判断をしているのか」を未来のAIと人間に引き継げる。

それこそが、単なる「第二の脳」より価値のあるナレッジシステムだと思います。

このブログを検索

NotebookOrigin