コンテンツは残っているのに、なぜ私は何度も整理し直すのか？

DeMinds が、ファイル、Webページ、ドキュメントリンク、マインドマップ、AIとの会話を、続きから取り組める Markdown ワークフローへ戻す方法。

---

最近、私はある言葉を聞くのがますます怖くなっています。

「前にどこかで読んだ覚えがある。」

たいてい、それはコンテンツ自体がおそらくまだ残っていることを意味します。

3か月前の AI との会話に埋もれているかもしれません。ブラウザのブックマークに入っているかもしれません。続きを展開しないまま止まったマインドマップの中にあるかもしれません。あるいは、チャット画面に残された GitHub README、DOCX、Markdown 文書へのリンクにすぎないこともあります。

コンテンツは失われていません。

それでも再び必要になったとき、私たちは探し直し、読み直し、判断し直し、もう一度整理します。十数分たっても本当の作業はまだ始まっておらず、前回離れたときの文脈を復元しているだけです。

これは、今もっとも一般的でありながら、もっとも見過ごされやすい生産性の損失の一つかもしれません。

ツールはコンテンツを保存してくれても、「次はどこから始めるか」までは一緒に保存してくれません。

コンテンツは残っていても、作業の文脈は毎回組み立て直さなければならない

ツールが保存するのはコンテンツであって、次の一歩ではない

たとえば、製品分析の記事を書くとします。

主張は AI との会話から生まれ、根拠は複数の Web 記事に散らばり、構成は MindNode や XMind にあり、補足資料は DOCX と公開 GitHub プロジェクトの README にあります。

材料は十分です。それでも実際に書き始める前に、会話を開き直し、Webページを探し、マインドマップの見出しをコピーし、文書の書式を整理し、リンクをたどって画像と文脈を確認し直さなければなりません。

一つひとつは難しくありません。問題は、こうした作業が、次回もそのまま使える作業状態をほとんど残さないことです。

繰り返し時間を奪うのは、文脈の再構築

次に戻ってきたときも、どれが最新なのか、前回どこまで進めたのか、元の資料と編集結果はどう違うのか、最終的な内容を別のツールへ移せるのかを確認しなければなりません。

AI は生成が得意です。ブラウザは目的地へたどり着くのが得意です。マインドマップは発想を展開するのが得意です。執筆ツールは文章を仕上げるのが得意です。それぞれの工程では十分に優れていても、コンテンツがツールをまたぐたびに、私たちは手作業で文脈をつなぎ直しています。

足りないのは、さらに強力な単機能ツールではなく、作業を途切れさせずにつなぐ道であることが多いのです。

ブックマークが解決するのは「どこにあるか」であって、「どう続けるか」ではない

コンテンツは元のツールや環境にとどまったまま

ブックマークがあればページを再び見つけられます。しかし、そのページの内容が自然に次の工程へ進むわけではありません。

Webページを開き直しても、ナビゲーションやおすすめの間から本文を探し直します。AI との会話の重要部分は、何十往復ものやり取りに埋もれているかもしれません。マインドマップは構造が明確でも、増え続ける本文を抱えるのには必ずしも向いていません。

これらの場面には共通した問題があります。

コンテンツは、それを生み出したり読んだりするのに最適なツールや環境にとどまり、次の段階へ自然に進めていません。

本当に足りないのは、安定した移行経路です。

コンテンツに価値があると分かった
→ 一時的な保管場所から取り出す
→ 構造と文脈を保つ
→ 編集できる状態にする
→ 次回も続きを進められる

DeMinds は、まさにここから始まりました。

リンクを保存しただけでは、なぜ作業資料にならないのか？

「リンクは保存した」と言えば、問題は解決したように聞こえます。

リンクが解決するのはアクセスであって、文脈の保存ではない

しかし、リンクが主に解決するのはアクセスです。文書の主線は何か、どの章が現在のプロジェクトに関係するのか、相対パスで参照される画像と関連文書がどうつながるのか、次回どこから読み始めるのかまでは教えてくれません。

公開 GitHub リポジトリの README には、見出しアンカーや相対パスで参照される画像が含まれ、チュートリアルや別の Markdown 文書へさらにリンクしていることがよくあります。ブラウザなら一つずつ開けますが、その関係を自分の作業資料へ自動的に変えてはくれません。

そのため DeMinds は、Web記事だけを入口にするのではなく、識別可能な公開ドキュメントリンクもローカルファイルに近いワークフローへ取り込もうとしています。アクセス条件を満たすリモートの Markdown、テキスト、HTML、DOCX、対応するマインドマップ文書は、開いて解析し、構造化できます。公開 GitHub で認識できる見出しアンカー、相対パスで参照される画像、文書間の関係も、可能な限り保持します。

すべてのリンクをインポートできるわけではありません。非公開リポジトリ、ログインや Token が必要な内容、アクセス制御されたページ、種類を確認できない対象には明確な境界があります。Webインポートプレビューを開けたからといって、そのページが必ずインポートに適しているとも限りません。

同じリンクでも、「ファイルのように見える」というだけで同じ経路へ送るべきではありません。Web記事はまずプレビューで確認するのが適しています。種類が明確なリモート文書は、実際の形式に応じて開けます。Feed は、URL、レスポンス形式、内容を組み合わせて判定する必要があります。GitHub リポジトリのトップ、リポジトリ内の単一ファイル、一般のWebページも、それぞれ異なる利用意図を表します。URL が .xml や .json で終わっていても、それだけで自動的に Feed になるわけではありません。

目立たない違いですが、インポート後の結果が編集可能な文書になるのか、手動で更新を確認できるコンテンツソースになるのか、それともブラウザで読み続けるのが適したページなのかを左右します。入口は共通でも、結果まで曖昧にしてはいけません。

本当に解決したいのは次のことです。

価値があると確認した公開文書を、単なるブックマークのままにせず、自分のワークスペースで読み続け、保守できる作業資料にできるか。

DeMinds は、もう一つの保存先を増やすためのものではない

さらに多く集めることが目的ではない

保存する入口なら、すでに十分にあります。ブラウザにはブックマークがあり、あとで読むツールにはキューがあり、ノート App には抜粋を保存でき、ファイルシステムはほぼあらゆる形式を収められます。

DeMinds が単に別の保存先を用意するだけなら、断片を一つの場所から別の場所へ移すだけです。

だから重視するのは「ほかに何を取り込めるか」ではなく、次の問いです。

残す価値があると判断した内容を、その後どのように保守できる作業資料へ変えるか。

コンテンツがある場所から始める

システム共有を使って、他の App にあるファイル、テキスト、リンクを共有インボックスへ送り、まとめて処理できます。クリップボードの内容を取り込むことも、Webインポートプレビューでリンクとページの状態を先に確認し、正式にインポートするか決めることもできます。

ローカルの内容は、MindNode、XMind、FreeMind のマインドマップ、Markdown、TXT、DOCX、HTML などの対応文書から始められます。Markdown パッケージや Obsidian Vault では、本当に処理したい範囲だけを選ぶこともできます。

一度だけ取り込む資料と、更新を追えるソース

残す価値のある内容が、すべて同じ方法でワークスペースに入るべきとは限りません。

Web記事、DOCX、マインドマップは、多くの場合、ある時点で価値があると判断して選ぶものです。通常のプロジェクトとしてインポートし、Markdown で編集と保守を続けるのが自然です。

一方、Feed や公開 GitHub プロジェクトの README は少し性格が異なります。背後にある外部ソースが、その後も更新される可能性があるからです。DeMinds では、こうした内容を独立した「コンテンツソース」として扱えます。現在の内容はローカルに保存され、いつ更新を確認するかはユーザーが決めます。あとからプレビュー、バージョン比較、復元、エクスポートができる一方、システムが生成した現在の Markdown は、通常の文書のように直接編集せず、読み取り専用のまま保たれます。

コンテンツソースは、新たな未読キューでも、バックグラウンドで動く購読サービスでもありません。DeMinds がバックグラウンドで自動的に定期チェックすることはなく、Feed 項目のリンク先にある全文や GitHub リポジトリ全体を再帰的に取得することもありません。「既読・未読・おすすめ」で新たな整理負担を増やすこともありません。出典との関係を明確に保ち、本当に継続して追いたい内容だけを、毎回最初からインポートし直さず更新できるようにします。

OPML が担うのは、これとは別の、あえて範囲を絞った互換性の役割です。階層型アウトラインでも、他のツールから書き出した購読リストでも、インポート後は一つの通常の編集可能な Markdown プロジェクトになります。階層、メモ、リンクは可能な限り保持されますが、多数の Feed コンテンツソースが自動的に作られることはありません。その後の整理と保守の土台はあくまで Markdown であり、OPML は既存の構造を持ち込むための橋です。

入口が違っても、その先は同じワークフローへ

入口が異なるのは、もともとコンテンツが別々の場所にあるからです。しかし取り込んだ後は、DeMinds はそれらを同じ主線へまとめようとします。

コンテンツがある場所から取り込む
→ 構造を見る
→ Markdown で作業を続ける
→ 進行中の作業へ戻る
→ 結果を確認して持ち出す

重要なのは「インポートに成功した」ことではありません。インポート後に、本当に作業がつながったかどうかです。

まず構造を見てから、どう続けるかを決める

直線的な読書では全体が見えにくい

長い内容で難しいのは、一文が理解できないことより、全体像が見えないことです。

AI の回答は長いチャット履歴へ伸び、Web記事はプラットフォームの要素に挟まれ、DOCX は見出しがあっても重要度を素早く判断しにくく、マインドマップは分岐が明確でも本文や細部がノードとノートに分散していることがあります。

汎用マインドマップは、構造を見渡すためのビュー

DeMinds は、異なるソースに実際に存在する見出し、分岐、文脈を、共通の構造ビューとしてまず展開します。プロダクト内では、このビューを「汎用マインドマップ」と呼びます。

すべての資料を従来型のマインドマップへ無理に作り替えるものではありません。むしろ、すばやく展開できる構造地図です。テーマはどこにあるか、主線は成立しているか、重すぎる章はどれか、どこから再開すべきかを見渡せます。

構造ビューが下げるのは、「二度目に開く」ときのコストです。

作者の代わりに書き直さない

DeMinds は、AI を使って作者の内容をいわゆる「より構造的な文章」に再生成することもしません。素材が AI 由来でもオリジナルでも、構造は文章の魂です。見出し階層、段落の関係、論証の順序には、作者の思考そのものが表れています。

作者の代わりに書き直すのではなく、元の思考を見えやすくし、続けやすくする。

Markdown への変換は難しくない。難しいのは、その後も続けられるか

変換の成功は、作業がつながったことを意味しない

DOCX、HTML、マインドマップを Markdown に変換すること自体は、もはや珍しい機能ではありません。

変換後にダウンロード待ちの .md ファイルが一つできるだけなら、問題の半分しか解決していません。別の App で見出し、画像、リンクを確認し、進行中のプロジェクトとどう関係するかを判断する必要があります。

Markdown はワークフローの中間にある

そのため DeMinds では、Markdown は終点ではなく、ワークフローの中間にあります。

見出しを直接調整し、ノイズを削り、自分の理解を加え、複数の資料を新しい作業文書へまとめられます。Markdown プレビューでは、表、画像、リンク、コード、一般的な数式も確認できます。

外国語の資料は、iOS 18 以降でシステムが対応している場合、現在の Markdown プレビューを一時的に翻訳できます。翻訳は閲覧表示にだけ反映され、原文、ワークスペース、バージョン履歴、書き出しファイルには書き戻されません。

ここでの Markdown は単なる「オープン形式」ではなく、整理、追記、組み合わせ、保守を続けるための作業の土台です。

変換は入口にすぎません。その後も続けられるかどうかが、コンテンツが本当に戻ってきたかを決めます。

DeMinds は、よく使われる生産性ツールとどう関係するのか？

この表は、DeMinds がすべての方向で優れていると証明するためのものではありません。

プロ向けマインドマップエディタのレイアウト機能を置き換えるものではなく、成熟した Markdown エディタの執筆体験を置き換えるものでもなく、Obsidian のバックリンク、プラグイン、ナレッジベース構成を置き換えるものでもありません。

補おうとしているのは、別の層の問題です。

コンテンツがこれらの専門ツールを離れたあと、構造をできるだけ失わず、次の段階へ滑らかに進めるにはどうすればよいか。

本当の効率とは、3週間後に戻っても続きから始められること

初回の使いやすさだけでは、一度の問題しか解決できない

生産性ツールは、最初に使ったときの滑らかさを過大評価しがちです。

インポートでタップが二回減る、変換が数秒速くなる。初回には確かに便利です。しかし、本当に重要な内容は一度しか使わないものではありません。

3週間後に開き直したとき、私が気にするのは、どれが現在の作業版か、前回どこまで編集したか、編集を失敗したときに戻せるか、バックアップして別の場所へ移せるかです。

ソフトウェアがもっとも保存しにくいのは作業の進捗

ファイルシステムはファイル名を覚えています。ブックマークは場所を覚えています。バージョン履歴は以前の姿を覚えています。

「作業を続ける」が本当に答えるべきなのは、次の問いです。

次に戻ったとき、どこから再開すべきか分かるか。

DeMinds の「作業を続ける」は、単なる最近開いたファイルの一覧ではありません。まず、通常のプロジェクトと「コンテンツソース」を分けます。前者は進行中の作業、後者は必要なときに更新を確認できる外部ソースです。コンテンツソースは独立した領域に控えめに表示されるため、数が増えても通常のプロジェクトのタイムラインを圧迫しません。

通常のプロジェクトが少ないうちは、カテゴリと未分類の項目をそのまま展開し、ひと目で確認できます。作業が増えると、「ピン留め」「続き」「今日」「過去7日間」「それ以前」といった時間グループに整理され、カテゴリはその構造の中で範囲を絞る役割を担います。タイムラインは「最近何をしていたか」に答え、カテゴリは「これはどの種類の作業か」に答えます。どちらかがもう一方を置き換える必要はありません。

コンテンツソースから戻ると、「作業を続ける」はそのときだけ該当する経路を開き直し、直前に見ていた内容が自然に目に入る位置へ戻します。その後、どこを開いたままにし、どこを折りたたむかはユーザーが決められます。小さな動きですが、メイン画面へ戻った瞬間に、たった今築いた文脈が消えるのを防ぎます。

同時に、作業中、ピン留め、最近の項目もすぐに見つけ直せます。バージョン履歴、文書のゴミ箱、ワークスペースのバックアップ、復元経路が、進行中の作業を一緒に守ります。

これらの機能は、もっとも目を引く宣伝用スクリーンショットにはなりにくいものです。しかし、一度のインポートが単なる「変換成功」で終わるのか、長く使える作業資料になり始めるのかを決めます。

DeMinds が本当に残そうとしているのは、ファイルだけではありません。

ソフトウェアが覚えるのがもっと難しい、次の一文も残そうとしています。

前回はここまで進めた。

ローカルファーストは、ネットワークを拒むことではない。制御をデバイス側に残すこと

中核となる内容を、最初にサービス提供者のクラウドへ渡す必要はない

内容がプロジェクト資料、執筆中の草稿、個人的なノートを含むようになると、保存方法と出口はプロダクトそのものの一部になります。

DeMinds はアカウント登録やログインを求めません。主要な解析、編集、バージョン管理、ワークスペース操作はデバイス上で行うように設計されています。文書、マインドマップ、ワークスペースの内容を整理・保守するために、まず DeMinds が運営するサーバーへアップロードする必要はありません。

ワークスペースはデバイス内に保存することも、iCloud を選ぶこともできます。iCloud はユーザーが選ぶシステムの保存場所であり、DeMinds が構築・運営するクラウド文書プラットフォームではありません。

ローカルファーストにも、明確なネットワーク境界がある

ただし、ローカルファーストはネットワークを拒むという意味ではありません。Webページやリモート文書を開くにはネットワークが必要です。iCloud とシステム翻訳は、それぞれ対応するシステムサービスを使用します。DeMinds は、インポート機能を使ってログイン、ペイウォール、CAPTCHA、その他のアクセス制御を回避することもしません。

ローカルファーストが本当に強調するのは、中核となる内容を最初にサービス提供者のクラウドへ渡す必要がないこと、ワークスペースの場所をユーザーが選べること、DeMinds を離れるときにもオープンな持ち出し手段が残ることです。

コンテンツは残せる。そして持ち出せる

異なる出力は、異なる次の用途に対応する

DeMinds は単一の Markdown ファイルを書き出せます。関連する画像やリソースを含む標準バンドルも書き出せます。iOS では、閲覧版または印刷版 PDF も生成できます。

記事全体の構造を一度に示したい場面では、DeMinds Plus で現在の汎用マインドマップをマインドマップ全体の PNG として書き出せます。記事、プレゼンテーション、アーカイブに使い、主タイトルから3階層目、4階層目までの関係を一枚で示せます。ただし PNG は構造のスナップショットであり、編集可能な Markdown やリソースを含む標準バンドルの代わりではありません。

オープン形式にも、正直に認めるべきトレードオフがある

これらの出力は、すべての元形式を無損失で再現するものではありません。複雑な DOCX レイアウト、独自のマインドマップテーマ、一部のインタラクティブ情報は、Markdown に完全には移らない場合があります。数式プレビューも完全な TeX 組版エンジンではありません。

オープン形式の価値は、損失がないふりをすることではありません。何が保持されたのかをユーザーが理解でき、現在の App を離れたあとも主要な内容を読み、編集し、移行できることにあります。

プライバシーは土台であり、構造は魂です。そして出口が、その内容が最後までユーザーのものかどうかを決めます。

DeMinds が向いている人、向いていない人

複数の場所にすでに資料を持っている人に向いている

DeMinds は、AI との会話、Webページ、ドキュメントリンク、マインドマップ、ファイルをすでに多く持っている人に向いています。Feed や公開 GitHub プロジェクトを継続して追いながらも、未読インボックスをもう一つ抱えたくない人。構造を先に理解してから、執筆、調査、プロジェクト作業へ資料を移したい人。Obsidian、MindNode、XMind、専門的な執筆ツールを使っている一方で、同じ内容を何度も整理したくない人。Markdown、バックアップ、移行可能性を重視する人です。

一つの App ですべてを置き換えたい人には向いていない

すべてのニーズに合うわけではありません。

主な目的がすばやいメモ、リアルタイムの共同編集、複雑なデータベース、プロ向けのマインドマップデザイン、集中した長文執筆、完全な Git バージョン管理であるなら、より直接的なツールがすでにあります。

DeMinds Plus が主に拡張するのは、オリジナルマインドマップの表示、マインドマップ全体の PNG、プレゼンテーション再生、ワークスペースのバックアップのインポート、「作業を続ける」で保持できる項目数です。これらは、内容を基本の Markdown ワークフローへ入れるための前提ではありません。

DeMinds は、何を残す価値があるかをユーザーの代わりに判断しません。すべての資料を自動的に知識へ変えることもしません。

できるのは、ユーザーがすでに選択したあと、その内容に比較的まとまった次の経路を用意することです。

これは続ける価値があると判断した
→ 元の場所から取り戻す
→ 構造をもう一度見る
→ Markdown で保守する
→ 次回戻って続きを進める
→ 必要なら完全に持ち出す

最後に：必要なのは、ブックマークを増やすことではなく、やり直しを減らすことかもしれない

AI はコンテンツ生成を速めています。Webページ、ドキュメントリンク、専門ツールによって、価値のある情報はますます多くの場所に現れます。

しかし、入力が増えても、自動的に知識になるわけではありません。

理解、変更、復元、移行ができる状態へ入っていない内容は、チャット履歴、ブックマーク、独自形式、無数の「あとで整理する」フォルダに沈んでしまいます。

私が DeMinds を作ったのは、すべての内容を一つの App に入れるべきだと考えたからではありません。むしろ逆です。読む、対話する、考える、書くという各作業は、それぞれにもっとも適したツールで続けたいと思っています。

ただ、その中の一つが十分に重要になり、使い続ける価値が生まれたとき、最初にあったツールを離れただけで、またゼロから始めなくて済んでほしいのです。

コンテンツが作られた、または見つかった
→ それがある場所から取り戻す
→ 構造と文脈を見る
→ Markdown で続ける
→ 3週間後に戻っても再開地点が分かる
→ ツールを離れても内容を持ち出せる

本当に必要なのは、もう一つの収集入口ではなかったのかもしれません。

すでにあるコンテンツを前へ進ませる道です。

コンテンツは失われていません。作業まで何度も最初からやり直す必要はないはずです。