PersonalOS 設計図

自分についてAIに聞けば、自分自身より自分の過去を正確に把握している

これが構想文書 requirement.md §20 の最終ゴール。単なるメモ置き場ではなく、人生・仕事・思考・健康・プロジェクトのデータベースを作り、AIをそのインターフェースとして使う。

ゴールに到達したかどうかは、次の問いに答えられるかで測る。すべて原文（§20・§15）にある問いである（一人称のみ「自分」に置き換えた）。

三層 — Memory / State / Activity

§16 の最終形。3つの層がすべて AI Retrieval（AIによる検索・取得の層）を経由して、Claude でも自作AIでも同じように読める状態にする。

データの3分類 ＋ 意思決定を別格に扱う

器の名前ではなく、3つの要求を守る

「Markdownを正本にする」は形式へのこだわりではない。守りたいのは次の3つで、これを満たすなら器（データの格納形式）は何でもいい。逆に満たさない器は、名前がMarkdownでも失格になる。

索引が要る理由は「意味の理解」ではない

コードを1行も書かず grep と sed だけで本人の問いに答える実験（原典の呼称 PT-R0）を実際に走らせた。2問とも通った。それでも索引は要る。ただし理由が変わった。

正本と派生物の境界

設計の骨格はこの1本の線に集約される。正本は git の中に、派生物は git の外に置く。索引をデータリポジトリの外に置く決め手は「重いから」ではない。

iPhone のメモが検索に載るまで

MVP で作るものは4つしかない。①iPhoneのショートカット（7アクション）②Macの取り込みスクリプト（launchd・5分おき）③チャンク表を作る index build ④それを LIKE（SQL の部分文字列一致）で引く search CLI。言語モデルは1回も呼ばない。ベクトル検索も全文検索エンジンも常駐プロセスも、MVPには無い。

稼働中の launchd ジョブ3本

✅ 実測済 3本とも登録・稼働中、直近の終了コードは 0（2026-09-04 観測）。ログを3本に分けるのは、同じファイルに混ぜると検知器（ログを監視する仕組み）が黙って別のものを数え始めるため。

取り込みスクリプトが満たす規定 — M-1〜M-8

この8つは「気をつける」では守れないので規定として固定されている。各行の右側が、その規定が無いときに起きる事故である。

詳細: phase1-implementation.md §9（手順8 — 取り込みスクリプト・plist・回帰テスト）

メモ1件が通る状態と、静かに落ちる分岐

正常系は6状態。重要なのは分岐のほうで、赤い枝はどれもエラーを出さずに止まる。だから検知は「エラーが出ないこと」ではなく「1行必ず出ること」で行う。

閉じていない継ぎ目 — 個別には全部通るのに、繋ぐと落ちる

詳細: phase1-implementation.md §1（何が既に動いていて、何が未検証か）・§12（結合検証）

文書は2階級しかない — 記録と正本

「全ファイルに日付を付ける」規格は誤りだった。文書を記録（record）と正本（living）の2階級に分け、日付の有無そのものを階級の表現にする。日付を持たないことが正しいファイルが122本（35.0%・実測当時）ある。

規約 N-0〜N-9

実際のファイル形式

# メモ 2026-09-02

> 🤖 このファイルは取り込みデーモンが追記する。人も AI も編集しない。
> 出所: iPhone ショートカット life-memo → iCloud Drive life-inbox/。
> 整理・分類はしない（設計）。

## 2026-09-02T08:12:03+09:00

（メモ本文）

# 計測 2026-09-04

> 🤖 機械が書く観測の記録。規則・項目・値の意味は README.md。

## 2026-09-04T00:00:00+09:00

| 項目 | 値 | 出所アプリ | 経路 |
| --- | --- | --- | --- |
| 体重 | 未取得 | — | asken→health |
| 体脂肪率 | 未取得 | — | asken→health |
| 歩数 | 未取得 | — | iPhone→health |
… 全10項目（体重・体脂肪率・歩数・睡眠時間・消費カロリー・
   安静時心拍数・摂取カロリー・タンパク質・脂質・炭水化物）
   asken ＝ 食事記録アプリ「あすけん」

• 運動（ワークアウト）は項目を作らない。Apple Watch を着けているだけでは貯まらず、永久に埋まらない欄になるため。
• 睡眠時間は導出値。asleepCore + asleepDeep + asleepREM + asleepUnspecified + asleep（廃止値）（HealthKit の睡眠ステージ）。inBed（就床時間）は足さない。
• 上書きせず追記する。当日・前日の値を Apple が再推定して置き換えることがあるため、同じ日付を後からもう一度取り込んで ## <ISO8601> ブロックを足す。notes/ と違って重複排除しない — 測定値は同じ日付・同じ値が何度でも正当に来る。
• ⚠️ 人が health/metrics/ に手で書き足したときに検出する仕組みは、まだ無い。

健康データ取り込みの契約（原典の呼称 H-CONTRACT）

転送層（どう Mac まで運ぶか）と整形層（どう Markdown にするか）を分けるための契約。監視ディレクトリを iCloud Drive ではなく ~/.local/state/（TCC保護領域の外）に置いたので、配送手段が変わっても差し替わるのは「落とす側」だけになる。

詳細: health-ingest-ops.md（健康データ運用）・note-format-spec.md §1（規格）・§4（移行手順）

言語モデルを1回も呼ばない索引

index build は純粋なテキスト処理。search は LIKE の部分文字列一致とパス／日付の絞り込みだけ。ランキングを持たない。上位 k=30（約25,000字）をそのまま AI に渡す。索引ジョブの内部（段階・ふるい・分割・差分・スキーマ・失敗モード）は別紙 Markdown 索引ジョブ に詳述してあるので、本節は概要にとどめる。

索引ジョブの概要

• 索引は原本に追従する側であって、原本ではない。Markdown から一方向に生成する派生物で、失っても作り直せる。→ 索引ジョブ §1
• スケジューラは薄いラッパーを起動し、7つの段階を通る。途中で降りる出口が3つある（対象なし・変更なし・エラー）。→ §2
• 対象は4段階でふるいにかける。拡張子（.md のみ）・ディレクトリ名・サブモジュール・バージョン管理の除外設定。→ §3
• 見出し（H1〜H3）で割り、300字未満は併合、1500字超は分割＋200字オーバーラップ。コードフェンス内は見出しとして扱わない。単位は「文字」であってバイトではない（UTF-8 バイト長で実装すると日本語で規則が実質3倍厳しくなる）。実測ではチャンクは最短8字・平均875字・最長1,499字で、「300字未満は併合」は全チャンクを300字以上にする保証ではない。→ §4
• 2つの関門で書き戻す量を絞る。ファイルの更新時刻と、チャンク本文のハッシュ（chunk_sha）。全件作り直しは1.68秒だが、実運用ではほとんどのファイルが変わらない。→ §5
• テーブルは2つだけ。本文テーブル chunks と、設定を持つキー・バリュー meta（8つのキー）。chunks の主な列は path／heading_path／start_line／end_line／text／chunk_sha／domain／doc_date／doc_date_source／mtime。ベクトル用の4列（embedding ほか）は最初から空で確保してある。→ §6・§7（各列が誰のどの機能を支えるか）
• 3本のインデックスが 21ms を 0.35ms にする。ただし効くのは domain = … と path の範囲比較だけで、path LIKE 'finance/%' は全走査（4.9〜5.6ms）になる。→ §8
• このジョブの失敗はほとんどエラーを出さない。「検索結果が少し減る」という形でしか壊れないので、既知の不整合を一覧で持つ。→ §9

なぜ Python 3 で書くのか — 決め手は性能ではない

索引は数秒、検索は21ms。どの言語でも誤差である。決め手は次の実測だった。

$ ls -li /usr/bin/{python3,git,clang,swift}
  → 4本とも同一 inode・118,928 B・リンク数78
$ codesign -dv /usr/bin/python3
  → Identifier=com.apple.dt.xcode_select.tool-shim-public
$ codesign -dv /usr/bin/sqlite3
  → Identifier=com.apple.sqlite3  （これだけ実バイナリ）

/usr/bin/python3 は Python ではなく、xcode-select -p の指す先へ飛ぶ shim（中継用の薄い実行ファイル）で、/usr/bin/git と同一実体である。python3 が消える条件＝git が消える条件。データリポジトリは git リポジトリなので、Python 依存は既存のリスクを1バイトも増やさない。しかも壊れ方が loud（stderr＋exit=1）で、「黙って空振り」にならない。

search CLI — 現物のインターフェース

search "法人化 OR 独立" --domain finance,goals --include sessions --since 2026-01 -k 30

出力（--format full）:
finance/simulations/2026-03-27_incorporation-simulation.md#法人化の損益分岐 (L112-L149) [finance, 2026-03-27]
  <本文 852字>

必ず出す1行（件数の内訳 — 日付の出所別／ドメイン別）:
32件 [日:21 月:6 見出し:3 不明:2]   finance:12 goals:5 sessions:0

なぜ LIKE で足りるのか（要点）

全件走査（6,411,071字に対して5語）で中央値 21ms（再現あり 18.8〜20.1ms）。全文検索エンジン（SQLite FTS5）は既定のトークナイザで MATCH "体重" が 🔴 0件・エラーも警告も無し（LIKE なら54件）。⭐ LIKE を採ったことで日本語2文字語の問題が構造的に消えた。FTS5・pgroonga・bigram 分割・多層の検知テスト案のいずれも MVP には要らない。器が SQLite である決め手も検索アルゴリズムではなく、常駐ゼロ・macOS標準・単一ファイルで rm 1回である。

実測値の一覧と索引の効き方: 索引ジョブ §8

索引の現在のかたち（概要）

合計 10,073 チャンク／362ファイル・28.6MB（2026-09-04 14:39 時点）。内訳は sessions 6,038・pokemon 1,777・projects 1,293 が上位で、sessions と pokemon だけで 77.6% を占めるため既定除外になっている。ただし除外は削除ではない — 過去の問いの答えが sessions/ の中の 666KB のファイルにあった実例がある。

🔴 チャンク数は「一致」を合格条件にできない。同じ対象に測り方の違う数字が複数存在する（7,853 / 8,207 / 8,362 / 8,456 のどれも正しい）。受け入れ基準で数字が「関係式・範囲」で書いてあるのは意図的で、sessions/ が単調増加するので引き直せばまた別の数字になる。

ドメイン別の全内訳: 索引ジョブ §3「索引の中身の偏り」／既知の不整合: §9

採らなかったものを、なぜ採らないかごと残す

構想（requirement.md）の技術選定は、実装計画セッションでほぼ全面的に置き換わった。ただし行は消していない。消すと、実装時に同じ案を揺り戻す余地が残るためである。左が初期案、右が決定。

各案の検討過程: mvp-implementation-plan.md・searchplan.md

構想の5フェーズと、実際に走っている手順

構想（§18）は Phase 1〜5 の階段だった。実装計画はそれを畳み直し、「iPhoneからメモ → 蓄積 → 検索して引ける」という本人の言葉の MVP を1本道にした。両者はこう対応している。

手順0〜14 — 現在の進捗

上から順に。前が終わらないと次は無駄になる。合計 約3.5〜5時間、うち本人が手を動かすのは 66分。各行の「AI」は AIエージェントが代行する作業、「👤」は本人が実機・GUI を操作する作業。

各手順の受け入れ基準・所要・検証手順: phase1-implementation.md §2（手順0〜14 の一覧）

MVP に入れないもの — 「落ちたのではなく、順番が後」

叩いても答えが出ない — 本人の判断が要る事項

実測で決められるものは全部決めてある。残っているのは測っても答えが出ない種類の問いと、その手前で止まっている実機作業である。

いま止まっている 66分

判断が要る事項

文書と現物のズレ（実測で確認）

✅ 実測済 2026-09-04 14:39〜15:05 に索引と実ファイルを直接確認した結果、仕様と実装が一致していない箇所が4つある。