10年分のInstagramを第二の脳へ — Obsidianプラグイン「Memory Synapse」構想への意見募集

[ikifuse]

はじめに

このプロジェクトでは、Metaから分割提供されたInstagramデータ一式をObsidianへ移し、記憶をツリーとDB画面で確認し、人物・場所・興味・出来事の関係を融合・分離・追記しながら、人間とAIが利用できる「第二の脳」へ育てるObsidianプラグイン「Memory Synapse」を目指しています。

これまで別々に作ってきたデータ変換工程とMemory Synapse DBは、この一つの目的を実現するための内部工程だったことが、現在になって見えてきました。

私はコードを1行も読めないし、書けません。AIを勉強し始めてまだ日が浅い非エンジニアで、ただのTAXI運転士です。

このプロジェクトを友人へ見せたとき、「ここまでできていること自体が奇跡だ」と言ってもらえました。一方で、「結局、何を作ろうとしているのか」は十分に伝えられていませんでした。

私自身も、最初から現在の全体像を言葉にできていたわけではありません。

出発点となった一つのアイデア

AIを勉強し始めてから、18日間で12個のアプリを作りました。

そのアプリを作っている間、AIへ何度もいろいろなことを説明するのが面倒だと感じるようになりました。

YouTubeでAIについて勉強している中で、Obsidianというノートアプリを知りました。そのとき、「そうだ。Obsidianへメモをためていけば、毎回何度も説明しなくてよくなるのではないか」と考えました。

しかし、自分でメモを一から書いてためていくより、すでに約10年分あるInstagramのデータを、そのまま自分のメモとしてObsidianへ入れてしまえばよいのではないかと思いました。

これが、このプロジェクトの出発点となった一つのアイデアです。

この一つのアイデアには、想像していた以上に多くの思想と技術的な条件が含まれていました。それらを一つずつ言語化し、企画、設計、仕様、サンプルデータ、TypeScript、Obsidianプラグインへ翻訳してきました。

現在までに形になったもの

現在は、大きく二つの工程に分かれています。

1. InstagramエクスポートJSONを、原本を失わずMarkdown・写真・動画・Synapseへ変換する親プロジェクト
2. 変換された記憶の関係を、Obsidian上で閲覧・確認・手書き・融合・分離するMemory Synapse DB

通常投稿、リール、ストーリーの変換工程は実データで検証し、Memory Synapse DBでは公開用合成データ、ブラウザーモック、TypeScript元コード、読み取り専用の仮プラグインを使った検証へ進んでいます。

今、見えてきた最終形の候補

これまで私は、Instagramの通常投稿、リール、ストーリーを変換する工程、それらを一つへ統合する工程、変換された記憶をObsidian上で扱うMemory Synapse DBを、別々のものとして作ってきました。

しかし現在までの成果物を利用者の立場から見直したことで、これらは別々の目的を持つシステムではなく、出発点となった一つのアイデアを実現するための内部工程だったのではないかと気づきました。

私が最初に実現したかったことは、複雑なデータ移行システムを作ることではありません。

Metaからエクスポートした約10年分のInstagramデータをObsidianへ移し、自分の記憶を、人間とAIが利用できる「第二の脳」として育てられるようにすること。

これが、このプロジェクトの出発点となった一つのアイデアです。

自分にとっての完成形

現在は、Instagramエクスポートを、原本との関係を失わないMarkdown、写真、動画、Synapseへ変換し、ObsidianのVaultへ配置できるところまで進んでいます。

Obsidianのファイルエクスプローラーには、変換された投稿、人物、場所、ハッシュタグ、メンションなどが、実際のフォルダーとMarkdownによるツリー構造として表示されます。

Memory Synapse DBでは、それらを単に閲覧するだけではなく、次のように扱うことを目指しています。

• 投稿と、それに関係する人物・場所・ハッシュタグ・メンションを確認する
• 同じ人物や場所だと考えられる個別カードを、人間の判断で融合する
• 融合後も、元の各カードが持っていた情報と関連投稿を確認する
• 必要な個別カードだけを分離して戻す
• 人間自身の記憶、意味、判断理由を手書きで加える
• 間違えた操作の対象と影響を確認し、情報を失わずに戻す
• 人間が育てた状態をMarkdownへ保存し、Obsidianを閉じた後も利用し続ける

現在の読み取り専用仮プラグイン06では、実際のVaultを読み、画面内で融合・分離・手書き・取消などの操作を確認できますが、その結果は保存しません。

この06が、操作結果を安全にMarkdownへ保存できる正式プラグイン08になった時点で、私自身にとっては、出発点となった一つのアイデアが実現した状態になります。

他の利用者も使えるパッケージ版の候補

私自身が利用するためには、既に完成しているデータ変換工程をプラグイン内部へ統合することは必須ではありません。

一方で、他の利用者へ配布する場合は、利用者がIGP・IGR・IGS・IGCという内部工程を理解しなくても使える、一つのパッケージにする必要があります。

MetaのInstagramエクスポートは、必ず一つのZIPファイルで提供されるとは限りません。今回の実データでは、約10年分の記録が4個のZIPファイルに分割されて提供されました。解凍後のJSON、写真、動画、字幕なども、複数のフォルダーへ分散しています。ZIPの個数や容量は、利用者の投稿数や利用期間によって異なると考えられます。

そのため将来のパッケージ版では、利用者に個々のJSONやメディアを探させるのではなく、Metaから提供された複数のZIP、またはそれらを解凍した複数フォルダーを、一回分のエクスポート一式として扱う必要があります。

利用者から見た操作は、次のような一つの流れになります。

1. MetaへInstagramデータのエクスポートを依頼する
2. 投稿量に応じて分割された複数のZIPファイルを、すべて取得する
3. ZIPファイルを解凍し、元のフォルダー構造を維持したまま、複数フォルダーを一つの入力セットとして指定する
4. Memory Synapseが、複数フォルダーに分散したJSON、写真、動画、字幕などを確認する
5. 不足している分割データや重複を検査した上で、安全にMarkdownへ変換・統合する
6. Obsidian標準のファイルエクスプローラーに、記憶のツリー構造が現れる
7. Memory Synapse DB画面から、記憶の閲覧・確認・融合・分離・手書き・取消を行う
8. 育てた知識を、人間とAIの両方がMarkdownから利用する

利用者からは一つのプラグインに見せながら、内部では次の二つの責任を分離します。

• Instagramの原本を失わず、Obsidianで利用できる構造へ変換する処理
• 変換された記憶を、人間が確認・修正しながら育てる処理

この分離により、一つのプラグインとして分かりやすく利用できることと、原本保持、再実行、安全な復旧を両立できるのではないかと考えています。

一般的な投稿閲覧プラグインではない

Memory Synapseは、Instagramの投稿を一覧表示するだけのプラグインや、データを保存するだけのバックアップツールを目指しているわけではありません。

Instagramに残された記憶を、自分で所有できるMarkdownへ移し、人、場所、興味、出来事の関係を確認し、人間自身が意味を加えながら、長期的に育てられる知識へ変えることを目指しています。

知識を特定のプラグインやAIだけが読める内部データへ閉じ込めず、プラグインが利用できなくなった場合でも、人間とAIがMarkdownとObsidianのリンクから主要な情報を確認できる状態を維持します。

また、AIやシステムが人物や場所の同一性を勝手に確定するのではなく、候補提示や整理を支援し、融合、分離、意味付けの最終判断は人間が行います。

Instagramに残された記憶を、自分で所有できるMarkdownへ移し、人、場所、興味、出来事の関係を確認・修正しながら育てられるObsidianプラグイン「Memory Synapse」

これが、現在見えてきた最終形の候補です。

書き込み可能な正式プラグイン08は現在のMemory Synapse DBの到達点ですが、Instagramデータの変換からDB操作までを一つの配布用プラグインへ統合することは、まだ採用も実装も決定していない将来構想です。

ただ、一つの素朴なアイデアを紐解いてきた結果、これまで作ってきたデータ変換、統合、Markdown、Synapse、DB画面が、一つの製品を成立させるための部品だったことを、初めて同じ言葉で説明できる状態になったと感じています。

意見を聞きたいこと

• この全体像は、一つのObsidianプラグインとして筋が通っているでしょうか
• 利用者からは一つのプラグインに見せ、内部ではデータ変換と記憶管理を分離する構成が適切でしょうか
• 最初の公開版を考える場合、どこまでを一つの完成範囲とするのが現実的でしょうか
• プライバシーと原本保持を守るために、設計段階で追加すべき観点はあるでしょうか

現在の成果物と検証環境を確認した上で、率直な意見をいただけるとうれしいです。