世界を動かす技術を、日本語で。

他人のアイデアを完成させるのは難しい、AIに提案されたものであればなおさら

2026年8月27日原文(ssp.sh)

概要

ObsidianでAIを活用する利点とリスクを整理。 AI生成のノートは自分の思考を薄める危険性。 本当に価値あるノートは自分の手で作るべき。 AIは検索や関連ノート発見など限定的な用途が最適。 長期的には人間自身の知識基盤が重要。

ObsidianとAI活用の限界

  • Obsidian はローカル保存・Markdown形式でAI連携が容易なノートアプリケーション。
  • AIエージェント と連携すれば、検索やファイル操作が高速化。
  • しかし、 AI生成の要約やテキスト を大量にノートへ追加すると、自分の思考や価値が埋もれる危険。
  • AI生成か自作か の区別が曖昧になり、ノイズが増加。
  • 本当に大事なのは、自分の意志・アイデア・動機で書いた内容。
  • AI要約は一時的には役立つが、後から見返すと物足りなさを感じやすい。
  • Obsidian Webclipper 利用時も、AI要約は明確に区別し引用扱いにする工夫が必要。
  • 検索や関連ノート発見 など、AIは高度なリサーチ用途で真価を発揮。
  • タグ付けや整理の自動化は、関係性や繋がりの意味が薄れるため推奨しない。
  • ノート同士の関係性は自分で作り上げることに価値。
  • Obsidian Smart Connections やGraph Analysisプラグインで、ローカルモデルによる解析も有効。
  • AI生成ノートに依存しすぎると、思考の明瞭さや洞察力が減少。

ノート管理とAIの役割

  • Zettelkasten やMemexのような知識管理法では、自分で作るノートの繋がりが重要。
  • 高度な検索やベクトル検索は Smart Connections プラグインで補完可能。
  • ノートは将来の AIプロンプトや知識ライブラリ にもなり得るが、AI生成ではなく自作が前提。
  • 人間の知識基盤 を育てることが最重要。
  • AIモデルは人間が作った知識データで再学習する方が有意義。
  • 知識創造の経済モデル も今後の課題。

「自分の知識体系」とは何か

  • Claude CodeなどのAIで自動生成されたノートやリンクは、「自分の知識体系」にはなり得ない。
  • 自分の思考やひらめき で作ることが「Second Brain」の本質。
  • アプリは単なる道具であり、重要なのは ファイルや自分の洞察
  • 人の手で作ることで、思考や学びのプロセス自体が価値となる。

AI活用の具体例と注意点

  • AIが生成したアイデア は最後まで書き切るのが難しい。
  • Andrej Karpathy’s LLM Knowledge Auto Research のような自動化知識ベースは学習には不向き。
  • Wikipediaのような人力知識グラフは有用だが、自分のノートは手作業で構築すべき。
  • PARAメソッド ではAI生成ノートを分離管理し、オリジナルノートと区別する運用も可能。
  • Voice to Text のAI活用は状況次第だが、思考の省略や誤認識のリスクあり。

長期的な視点と創造性

  • 創造性 は未来志向であり、AIに頼りすぎると独自性が失われる。
  • 思考と学びのためには、 AI活用を最小限に抑える のが望ましい。
  • ノート作成・管理は自分の「第二の脳」を育てる行為。

参考・追加リソース

  • Second Brain Assistant with Obsidian (NoteGPT)
  • Building an Obsidian RAG with DuckDB and MotherDuck
  • How To Think Better in the Age of AI (From the Stoics)
  • Everything I've published came out of one Obsidian vault

まとめ: ObsidianとAIの連携は便利だが、 自分の思考・知識を守るためにはAI依存を避けることが肝要。AIは補助的に使い、本質的なノートや知識体系は自分の手で作り上げることが、長期的な価値・創造性につながる。

Hackerたちの意見

コードベースでも同じ問題があるんだよね。クロードが何かに取り組んで、デザインから引き出した詳細なコメントを追加するんだけど、それが実際には根拠のない意図や決定を自信満々に述べてるんだ。で、後でその幻覚を読み返すと、それを正当なものとして扱っちゃうから、セッションが苦しむことになる。

最初に使える標準仕様書を作っておくのが良さそうだね。それを独立したリファレンスとして維持できるし。

アンスロピックは、最終的には君が諦めてクロードに完全に依存するようになることを望んでるんだろうね。もっと規律がない他の10人(それ以上も)開発者が加わったら、クロードの過剰設計で理解不能なテクノサラダに失望すること間違いなしで、君の終わりはほぼ確実だよ。

コードにコメントをゼロにするために、少しずつ進めてるんだけど、コメントってほとんど役に立たないんだよね。

コメントを削除してほしい:最近、これに関してはかなりイライラしてるんだ。トラブルの元にしかならないからね。最悪でも、トークンの予算を食いつぶすだけなんだけど、もっと深刻なのは、未来の作業を毒して、コードベースのさらなる修正をより負担にしてエラーを引き起こすことだよ。

うちのハーネスのマークダウンにはこんなことが書いてあるんだ。

## コメント
コメントは極力控えめに使うこと。ほとんどのコメントはユーザーのリクエストに応じて書くべきだよ。コメントが必要なときは、コードが何をしているのか、なぜそれが必要なのかを一、二行でまとめてね。背景の説明や調査の経緯、失敗の経緯なんていらないし、テスト名やコミットメッセージで言ってることを繰り返すのもダメ。仕様書にも同じことが言えるよ。もしコメントが段落になりそうなら、コードをもっとわかりやすくする方がいい。

クロードが残していたコメントは、完全に手に負えない状態になってた。意味不明なLLMの駄文が延々と続いていて、コードコメントとしての役割とは全く関係なかった。

コードエクスのせいで、役に立つコメント(直接関連はないけど、ちょっと雑なWIPノート)を削除されたことがある。エージェントのmdファイルにはコメントを削除しないように明示的に書いてるし、削除するべきだと思ったら許可を求めるようにしてるのに。コメントが削除されて、なぜそんなことをしたのか聞いたら、最初に私が促したからそれが明示的な許可だって返ってきた。実際の理由かどうかはわからないけど、ただの後付けの説明かもしれない。だけど、こういうものが完全に独立して、100%深い問題を解決するのは無理だと思う。人間ベースの組織の文脈で理解される必要があるからね。

私のアプローチは、コメントは参考だけにすること。私のLLMベースのプロジェクトには、機能を作るときの決定ログがあって、そこに日付と一緒に決定が記録されてる。これがあると、なぜ何かがコードベースにあるのかを追跡するのがすごく便利。何ヶ月もかけて、夜通し計画を実行してきた大きなプロジェクトを、私もLLMもナビゲートしやすくなる。朝にはモデルの質問に答えて、そんな感じで反復してた。正直、これを試してみてほしい。

コードではこれがさらに厄介だね。幻覚がドキュメントみたいに見えてくるから。

以前に関連する研究が投稿されてたよね。> 「人々がAIが創造的な作業をしたと思うと、タスクの意味や努力が低下する」 https://www.brookings.edu/articles/when-people-think-ai-did-...

セカンドブレインのことがよくわからないんだ。セカンドブレインは持ってないし、ただたくさん読んで考えてるだけ。昔、物理の修士をやってた時に、進捗をどうやって維持するか聞かれたら、ある教授(ポール・ディラックと共著もある人)が「実は、私はずっと物理のことを考えてるんだ」と言ってた。それを自分の興味のあることに応用し始めたら、アイデアがたくさん出てくるようになった。99%はゴミだけどね。AIがなかった頃は、同僚との会話がゴミを取り除くのに役立って、新しい視点を与えてくれた(「君が言ったことについて驚くべきことがあるよ!」みたいに)。今は、AIが実証的にテストできるアイデアの中からゴミを取り除くのに役立ってくれることもあるけど、同僚よりもノイズが多い気がする。彼らは私が見たいポイントにすぐに連れて行ってくれたから。セカンドブレインが必要だと思ったことはないな…もしそんなものがあったら、99%のゴミを抱え込むことになっちゃうと思うから、私はただ生物学に任せてる。

私は君のやり方に近いけど、いくつかの組織システムを試してみて、「セカンドブレイン」の人たちの気持ちがわかるようになったと思う。一つ目は、それが粗い形でクリティカルシンキングを強いること。物理的にもデジタル的にも、自分の考えを検討して整理できるんだ。それは、頭の中で何かを分解するのとは違うけど、それが苦手な人には「セカンドブレイン」がその恩恵を受けられる手段になる。二つ目は、頭の中で物事を素早く回転させることができるようになる。アイデアをすぐに組織システムに放り込む練習をすることで、頭の中にたくさんのことを抱え込む必要がなくなる。さらに、言葉は不変だけど、頭の中の考えはそうじゃない。でも、私の場合、良い考えは大抵上に浮かんでくる。考えていることの中には、すごく曖昧でただの感覚のものもたくさんある。それを文字にしようとすると、長期的な「後回し」のメンタルプロセスが奪われて、実際のアイデアになるために必要なものが失われちゃう。まだ胚の段階の考えなんだ。質感を文字にすることはできないし、それを「セカンドブレイン」に移そうとすると、失ってしまう。組織システムは仕事によって依存すると思う。ビジネスを運営するのには組織システムが合ってるけど、物理学のようなものは、アイデアを長期間頭の中で遊ばせて、しっかりしたものに育ててから真剣に追求する必要があると思う。プログラミングもその境界線をまたいでいて、やってることによって変わるんじゃないかな。

Hacker Newsで議論の続きを見る