MEMOKET NOTEのObsidian入出力で、繰り返し書き出しと上書き競合を確かめる

新しいAIエディタを試すとき、生成結果と同じくらい気になるのが、手元のメモをどう持ち帰れるかです。出力先で直した文章を、次の書き出しで消してしまうと困ります。

KITEを使ったコミュニティの個人開発MEMOKET NOTEで、架空の日本語メモ3本を取り込み、編集して別のVaultへ書き出しました。私はMemoketでKITEの開発に関わっています。この記事では生成品質の評価ではなく、Markdownの受け渡しと競合時の動きを確認します。

確認した環境とメモ

公開コードの992cebaを、macOS、Python 3.11.15、Node.js 22.22.3で起動しました。普段のノートとは分けた保存先を使い、外部モデルの呼び出しや実アカウントとの連携は行っていません。

メモは、読書会の予定、開始時刻の変更、お知らせ案の3本です。たとえば予定は次のようなMarkdownです。

---
title: 読書会の予定
date: 2026-10-19
---

これは動作確認用の架空の記録です。

10月25日の読書会は19:00開始、オンライン開催の予定です。

別のメモには、開始時刻を19:30へ変えたことを書きました。お知らせ案も19:30としています。今回は、この変更をAIが正しく推論できるかまでは試していません。

まずはノートだけを取り込む

接続ガイドでは、ImportからMarkdownやObsidian Vaultを選び、取り込み先を選択します。画面の表記は現在英語です。

• Notes only：本文をノートとして取り込む
• Knowledge base only：知識を抽出する
• Notes + knowledge base：両方を行う

今回はNotes onlyに相当するAPIのto=notesを使いました。基本の入出力を確かめる段階では、知識抽出やモデル推論は必要ありません。取り込み後、お知らせ案に「参加希望は10月24日までに連絡してください。」と手で追記し、保存しました。

ブラウザ版のExportからはMarkdownをダウンロードできます。デスクトップ版にはローカルVaultへ書く経路もあります。以下では、その書き出しAPIを使って、同じ3本を繰り返し出力したときの動きを確認します。

空の出力先で3回確かめる

前提は、開発手順でバックエンドを起動済みであることです。ここでは127.0.0.1:8784で起動し、ワークスペースのIDはdefaultにしています。自分の環境と合わせてください。X-User-Idはワークスペースの選択値で、認証ではありません。APIはループバックのまま使います。

ノートのIDは、次のCLIで確認できます。has_body: trueの確認用メモ3本のIDを控えます。本文のない親ノートは含めません。

cd backend
MEMOKET_NOTE_URL=http://127.0.0.1:8784 \
MEMOKET_NOTE_USER=default \
  .venv/bin/python -m app.cli list --query 読書会

次のコードをリポジトリ直下のcheck_export.pyへ保存します。出力先は毎回新しい一時フォルダです。元のVaultを変更せず、そのコピー1本にだけ確認用の追記を入れます。

import json
from pathlib import Path
import sys
import tempfile

import httpx

note_ids = sys.argv[1:]
if len(note_ids) != 3:
    raise SystemExit("確認用ノート3本のIDを指定してください")

vault = Path(tempfile.mkdtemp(prefix="memoket-note-export-"))
with httpx.Client(
    base_url="http://127.0.0.1:8784",
    headers={"X-User-Id": "default"},
    trust_env=False,
    timeout=20,
) as client:
    def export():
        return client.post(
            "/api/export/obsidian",
            json={"vault_dir": str(vault), "note_ids": note_ids, "force": False},
        ).raise_for_status().json()

    def show(label, result):
        print(label, json.dumps({
            "written": result["written"],
            "skipped": result["skipped"],
            "conflicts": len(result["conflicts"]),
        }))

    show("first", export())
    show("repeat", export())
    target = sorted(vault.rglob("*.md"))[0]
    edited = target.read_text(encoding="utf-8") + "\n出力先だけの確認メモ。\n"
    target.write_text(edited, encoding="utf-8")
    show("after_edit", export())
    assert target.read_text(encoding="utf-8") == edited
    print("destination_edit_preserved: True")

リポジトリ直下から実行します。ID1〜ID3は確認用メモの実際のIDに置き換えてください。

backend/.venv/bin/python check_export.py ID1 ID2 ID3

手元で得られた結果です。

first {"written": 3, "skipped": 0, "conflicts": 0}
repeat {"written": 0, "skipped": 3, "conflicts": 0}
after_edit {"written": 0, "skipped": 2, "conflicts": 1}
destination_edit_preserved: True

最初は3本を書き、同じ内容なら3本ともスキップしました。次に出力先の1本を編集すると、その1本は競合になり、追記が残りました。force=Falseを指定した、この条件での結果です。出力先の変更を取り込んで自動マージする機能を確認したわけではありません。

取り込み直しで気づいたこと

同じ3本をもう一度取り込んだとき、本文を持つノートのIDは変わりませんでした。一方で、親フォルダに相当する空の「読書会」ノートが重複しました。本文の重複がなかったことと、階層全体がきれいに再利用されることは分けて見たほうがよさそうです。

このため、普段の大きなVaultへ戻す前に、別の出力先で構成と差分を見たいと感じました。今回の3本では、手で編集した日本語本文もMarkdownへ出力できています。

追記：別のMarkdownエディタで直して戻す

2026-10-22追記：morststsさんの開発記事で知ったSirusitaのWeb版（ヘルプの表記はv1.8.1）でも、架空の「読書会の予定」1本を試しました。NOTEから書き出したMarkdownを取り込むと、front matterのタイトルが使われました。開始時刻を19:00から19:30に直し、確認用の一段落を追記して書き出せました。

Sirusitaの出力は、先頭のH1見出しと本文でした。画面で付けたタグ、作成・更新日時、元ファイルにあったNOTEのIDは含まれていません。ヘルプにも、通常の書き出しにはタグと日時を含めないと説明されています。

この実ファイルを、新しい保存先を使ったNOTEのNotes only取り込みAPIへ、FastAPI TestClientから渡しました。修正した時刻と追記は残り、取り込み後の本文は末尾の改行1文字を除いて一致しました。サーバーは起動せず、ソケット接続を禁止した状態での確認です。

Markdownを介して本文を持ち帰れた、1本の小さな例です。元のノートIDを保つ更新や、フォルダ・添付ファイルの往復、常時同期までは確認していません。

追記：Markdownの本文と記法はどこまで残るか

2026-10-22追記：読書会のメモとは別に、構文を変えた架空のMarkdown3本を、同じ版のNotes only取り込み・書き出しAPIで確認しました。FastAPI TestClientで実行し、外部へのソケット接続を禁止しています。

編集せずに書き出しても、元ファイルとバイト単位では一致しませんでした。今回の例では、参照形式リンク、HTMLコメント、数式のソース、未知の言語名を付けたコードブロックは残りました。一方、front matterの独自項目やaliases、tagsは出力に引き継がれず、連続する空行も整理されました。

Obsidianのウィキリンクは表示文字列になり、リンク先やアンカーは残りませんでした。架空の埋め込み参照とdataviewブロックも除かれています。取り込み処理には、こうした整形が実装されています。もう1本では、コードブロック内に書いた説明用の [[DoNotChange|literal]] も literal に変わりました。

取り込み後にAPIで一段落だけ編集した出力は、保存された本文と一致しました。画面での編集・表示や、実際の添付ファイルの扱いは未確認です。元のMarkdownを保つ用途では、作業用のコピーで差分を確かめたいところです。

ほかのエディタとの接続範囲

NOTEは、文書を選んでPolishやRewriteを使い、関連するKITEの記憶や元の資料を横で見ながら書くエディタです。既存のノートを持ち込めるのは、この作業を普段の道具につなぐための入口になります。

ただし、接続先ごとの範囲は同じではありません。NotionとFeishuには取り込み・書き出しのアダプターがありますが、公開資料では実アカウントの検証が残っています。Apple NotesはmacOSでの取り込みと、その後のMarkdown出力です。今回の確認から、すべてのエディタとの常時双方向同期まで言えるわけではありません。

ノートとKITEの記憶はローカルに保存されます。AIによる生成や知識抽出を使う場合、必要な内容は設定したモデルの処理先へ送られます。アプリはAGPL-3.0-only、KITEはApache-2.0です。

エディタの比較では、生成した一文だけでなく、編集して戻すところまで試すと見えるものがあります。今回の小さな例が、Markdownを中心に道具を組み合わせるときの確認材料になればうれしいです。