AIと作る"業務OS" — ドキュメント基盤を棚卸しし、Obsidian二層vault(fail-closed)で「漏らさず持ち歩く」まで

個人開発を続けていると、docs/ フォルダがいつの間にか 200個のメモの墓場になっていませんか？
「どれが最新かわからない」「機密が混ざってて外に出せない」「スマホで読み返したいけど怖い」——
この記事は、その散らかった知識置き場を、AIと一緒に "共同研究者"として使える基盤に作り替えた実装記録です。初心者の方にもわかるよう、専門用語はその都度かみ砕きます。

医療と IT のあいだで動いている立場として、自分の学び直しを兼ねて整理しているシリーズです。今回は「技術力証明」寄りの回ですが、要所は初心者の方にも読めるようにしています。

---

この記事で持って帰ってほしい3つ

1. ドキュメントにも"棚卸し"がいる — コードだけでなく、メモ・設計・ログも定期的に地図を作り直す。
2. 機密は"タグ"と"機械ゲート"の二層で守る — 人間の注意力に頼らず、#public-ok のものだけを、さらに検査を通してから外に出す（fail-closed）。
3. モバイルには"コピー"で持ち出す — 母艦は全部見える、スマホは安全なものだけ。編集の正本は1つに保つ。

---

1. 何が問題だったのか

個人で複数プロジェクトを並行開発していると、docs/ に大量のメモが溜まります。私の場合、棚卸ししたら 236個の Markdown がありました。問題は3つ。

• 地図がない：どれが現役でどれが古いか分からない。相互リンクもほぼ無く、検索でしか辿れない"孤児"だらけ。
• 機密境界が曖昧：取引先名・学校名・関係者名を含むメモと、公開して良い技術メモが、同じフォルダに同居。
• スマホで読めない：外出先で読み返したいが、機密ごとクラウド同期に載せるのは怖い。

🔰 「棚卸し（たなおろし）」って何？

お店が在庫を一個ずつ数えて「何がどれだけあるか」を把握する作業のこと。ソフトでも同じで、"今あるファイルを全部数えて、種類・状態・危険度をリスト化する" ことです。これをやらないと、地図が現地とズレていきます。

---

2. まず現状把握（棚卸し）

いきなり整理を始めず、機械的に現状を数えるところから始めました。git と find と grep で十分です。

# ドキュメント総数と、日付プレフィックス命名の遵守率
find docs -name '*.md' | wc -l
find docs -maxdepth 1 -name '*.md' | grep -cE '/(20[0-9]{2}-[0-9]{2}-[0-9]{2}|note_|qiita_)'

# 相互リンク([[wikilink]])を使っているファイル数（＝孤児の逆指標）
grep -rl '\[\[' docs --include='*.md' | wc -l

結果、命名規約の遵守は約6割、相互リンクは全体の1割強。**「立派なルールはあるが運用されていない」**という、よくある状態が可視化されました。数字にすると、直す気になります。

---

3. 機密を"二層"で守る設計

ここが今回の肝です。「人間が毎回気をつける」をやめて、設計で機密を止めます。

層1：機密軸タグ（frontmatter）

全 Markdown の先頭（frontmatter）に、機密の度合いを表すタグを1つ必ず付けます。

---
tags: [architecture, public-ok]   # ← public-ok / pii / review のどれか必須
date: 2026-07-07
status: draft
---

• public-ok：抽象化済み・固有名なし → 外に出してよい
• pii：固有名・関係者名を含む → 隔離。外に出さない
• review：判定できない → 迷ったら必ずこれ（後述の fail-closed）

🔰 「frontmatter（フロントマター）」って何？

Markdown ファイルの一番上に --- で挟んで書く、**そのファイルの"ラベル"**です。日付・種類・タグなどを機械が読める形で書いておく欄。Obsidian などのツールがこれを読んでファイルを分類してくれます。

🔰 「fail-closed（フェイルクローズド）」って何？

**「わからないときは"閉じる"（＝安全側に倒す）」**という設計思想です。
自動ドアでたとえると——センサーが壊れたとき、「とりあえず開けておく」のが fail-open、「安全のため閉じる」のが fail-closed。機密は後者。判定に迷ったら"公開OK"ではなく"要確認"に倒します。判定を全部 Python で自動化しました。

# ざっくり：固有名リストに当たれば pii、公開記事なら public-ok、それ以外は review（fail-closed）
def classify(path, text):
    if is_in_private_folder(path):        return "pii"
    if hits_ng_terms(text):               return "pii"     # 取引先/学校/関係者名など
    if path.name.startswith(("note_", "qiita_")):  return "public-ok"
    return "review"                        # ← 迷ったら閉じる

層2：公開前ゲート（publish-gate）

タグだけだと貼り間違いが起きます。そこで、外に出す直前にもう一段、機械検査を通します。これが publish-gate。

ポイントは、検査に使う"NGリスト"（取引先名などの固有名の塊）を、コード本体から切り離して git 管理外に置くこと。そして——

# NGリストが読めない/壊れている/空 なら、検査せず「公開不可(exit 1)」で止める
def load_ng_terms():
    try:
        data = json.load(open(NG_FILE))         # git管理外の外部ファイル
    except FileNotFoundError:
        print("NGリスト無し → 検証できない＝公開不可(fail-closed)")
        return None                              # ← ここで必ず落とす
    ...

「リストが無ければ"全部OK"ではなく"全部NG"」。これも fail-closed です。NGリスト無しで PASS を返すと、"安全と誤認"して機密が漏れる——それを構造で防ぎます。

🔰 なぜ2層にするの？

人間の「気をつけます」は必ず抜けます。タグ（分類）と ゲート（検査）を独立に2つ置くと、片方が漏れてももう片方が止める。実際、今回**「public-okと貼ってあるのにゲートが固有名を検出した」ファイルが4件**見つかりました。二層にしていなければ、そのまま外に出ていました。

---

4. Obsidian 二層vault — 「母艦は全部、スマホは安全な分だけ」

🔰 「Obsidian（オブシディアン）」って何？

Markdown のメモをリンクでつないで"第二の脳"のように使える無料ツールです。メモ同士を [[別のメモ]] でつなぐと、関連が地図（グラフ）で見えます。フォルダをそのまま開くだけで使えます。

🔰 「vault（ヴォルト＝金庫）」って何？

Obsidian が管理する**メモの入れ物（フォルダ）**のこと。ここでは「母艦vault（Mac・全部見える）」と「モバイルvault（スマホ・安全な分だけ）」の2つを使い分けます。

方針はシンプル。

• 母艦vault = docs/ を直接開く（Mac の中だけ・機密も含めて思考とリンクに使う）。
• モバイルvault = #public-ok かつ ゲート通過したファイルだけをコピーした、別フォルダ。これをスマホに同期する。

「なぜコピー？」——直接同期だと"うっかり機密"が載ります。"公開OKのものだけを許可リストで選んでコピー" する opt-in 方式にすると、デフォルトで何も出ない（fail-closed）。実装は数十行の Python です。

for md in docs.rglob("*.md"):
    if sensitivity(md) != "public-ok":   continue    # public-ok以外は出さない
    if not publish_gate_pass(md):        continue    # ゲートERRORも出さない
    copy_to_mobile_vault(md)                          # 両方通ったものだけコピー

実行結果は、239個のうち36個だけがモバイルへ。残り203個は「未判定113・隔離76・機密10・ゲート除外4」で除外。コピー先を固有名で grep して0件を確認しました。境界が物理的に守られている状態です。

🔰 「opt-in（オプトイン）」って何？

**「入れたいものだけ、明示的に選んで入れる」**方式。逆は opt-out（基本は全部入り、要らないものを外す）。機密は opt-in が安全です。「許可した物だけ通る」＝知らない物は通らない。

---

5. ドキュメントを"共同研究者"として扱う運用ルール

仕組みだけでなく、AIと人間の付き合い方もルール化しました（私の運用の中核ファイル CLAUDE.md に明文化）。要点は4つ。

• 反証ゲート：公開記事を書く前に、必ず docs/ を検索。過去の自分の一次情報と矛盾する主張は、応答するか修正するまで公開しない。
• 戦略照合：新しい案件や応募を決める前に、上位戦略ノートと照合する（事後報告にしない）。
• 立場変更の追記：方針を変えたら、旧ノートの冒頭に「→ 改訂済み、[[新ノート]]参照」を残す。古いメモが誤った反証に使われるのを防ぐ。
• 地図の維持：新規メモは日付＋frontmatter＋機密タグで作り、目次（INDEX）にリンクを1行足す。

面白いことに、この「反証ゲート」を作った直後、自分の過去記事と、その日書いた設計メモが食い違っているのを機械が検出しました。過去の自分に反論されたわけです。ドキュメントは保管庫ではなく、議論相手になります。

---

6. 今後どう運用するか（チェックリスト）

いきなり全部やらなくて大丈夫です。順番に。

• ① 機密タグを付ける習慣：新規メモには必ず public-ok / pii / review を1つ。迷ったら review。
• ② 母艦は全部・スマホは選抜：Obsidian の母艦vaultは docs/ 直開き。スマホ用は書き出しスクリプトで公開OKだけコピー。
• ③ 出す前は必ずゲート：記事・投稿の公開直前に publish-gate を1回。ERRORが出たら直すまで出さない。
• ④ 迷子を減らす：週1で目次（INDEX）を見直し、孤児メモにリンクを1本足す。
• ⑤ 下書きも早めにコミット：今回、未追跡のまま放置した下書きが消えました。作ったら追跡下に置く。

運用の"1日ループ"

1. 日中：Mac の母艦vaultで思考・リンク・検索（機密込みで全体を俯瞰）。
2. 外出前：書き出しスクリプトを実行 → 公開OKだけがスマホ用vaultへ。
3. 外出先：スマホで"安全な知識だけ"を読む。蓄積データ（家計簿的な運用記録）は別ツールで。

---

7. よくある落とし穴

• タグを付けただけで安心しない：貼り間違いは必ず起きる。ゲート（機械検査）を必ず併用。
• 直接同期は事故のもと：クラウドのフォルダ同期は、除外設定が粗く機密を巻き込みがち。opt-inコピーが安全。
• NGリストをコードに直書きしない：固有名の塊はコードから分離し、git管理外へ。リスト欠落時は"公開不可"で止める。
• 下書きを untracked で放置しない：消えます（実体験）。

---

まとめ — ドキュメントは"墓場"ではなく"設計図"にできる

散らかった docs/ は、放っておくとメモの墓場になります。でも、棚卸しで地図を作り直し、機密をタグとゲートの二層で守り、スマホには安全な分だけコピーする——この3つで、同じフォルダが**"持ち歩ける共同研究者"**に変わります。

そして何より、最初から完璧を目指さなくて大丈夫です。まずは「新規メモに機密タグを1つ付ける」だけでも、立派な第一歩。そこから少しずつゲートや書き出しを足していけば十分です。

「人間が気をつけること」を、一つずつ設計に置き換えていきましょう。一緒に、ちょうどいい仕組みを育てていければうれしいです。

---

参考（一次情報）

• Obsidian 公式：https://obsidian.md/
• fail-closed / fail-open の考え方（セキュリティ設計の基本原則）
• 本記事の設計判断は、筆者の運用ドキュメント（棚卸し・Obsidian連携設計・実装レポート）に基づく。

---

補足（免責）

本記事は筆者個人の運用・設計の記録であり、法的助言ではありません。機密情報・個人情報の取り扱いは、各自の契約・所属規程・関連法令（個人情報保護法など）に従ってください。

セキュリティ設計の妥当性は環境により異なり、本記事の内容が全ての現場に当てはまるわけではありません。繰り返しになりますが、本記事は特定製品の推奨や法的助言ではありません。判断に迷う場合は、契約内容と所属の規程を優先してください。

なお、固有名や取引先情報の扱いは各自の守秘義務に依存します。本記事はあくまで設計手法の共有であり、法的助言ではありません。

---

著者について

臨床工学技士 × AI エンジニア。病院の医療機器の現場に 11年 携わったのち、現在は AI エンジニアとして医療 DX を推進しています。酪農学園大学の研究生として学び直しを続け（論文博士を目指しています）、研究テーマは 遺伝子医療の未来。教育関係の仕事もしており、「伝える側」でも自分の理解を確かめながら発信しています。

医療と IT のあいだで動きながら、現場で動く Web アプリに研究知見を翻訳することに価値を置いています。

• note: https://note.com/taichi_endoh
• Qiita: https://qiita.com/TaichiEndoh
• X: https://x.com/endoh_taichi

質問・情報提供・コラボ提案、いつでも歓迎です。