プライバシー

2026-05-27 追記: 実際にインストールしてみたところ、デフォルトのままでは TinyHumans へのサブスク課金（=有料アカウント）が必要なことが判明した。GPL-3 のオープンソースなのになぜ有料なのか、本記事に「なぜ TinyHumans への課金が必要なのか」セクションを追加した。「完全ローカル」を額面どおりに実現するための回避ルートも併記している。 「クラウドAIに自分の悩みを打ち明けるのが不安」という声をよく聞く。仕事の機密、家族の話、健康上の悩み——ChatGPTに投げてはみるものの、その会話がサーバーに残り続けることへの抵抗感は根強い。 そこに登場したのが OpenHuman だ。GitHubスター数2.7万を超え、週に1,000以上のペースで増え続けるこのプロジェクトは、「ChatGPT級のAIを完全にローカルで動かす」という問いへの実践的な回答を提供している。 OpenHumanとは OpenHuman は、TinyHumans AIが開発するオープンソースのエージェント型AIアシスタントだ。Rustをコアに持ち、デスクトップアプリとして動作する。 公式の説明は簡潔にまとめられている。 Your Personal AI super intelligence. Private, Simple and extremely powerful. ポイントは3点だ。 Memory Tree による長期記憶 Obsidianスタイルのローカルナレッジベース 118以上のサービス連携 これらを組み合わせることで、「インストールから数分でユーザーを知り尽くしたエージェント」を目指している。 なぜ「ローカルAI」が重要なのか ChatGPTをはじめとするクラウドAIの課題は、会話が外部サーバーへ送信される点にある。個人情報保護の観点から問題となるだけでなく、企業での利用では情報漏洩リスクが伴う。 OpenHumanが解決しようとしているのはこの点だ。 会話を外に出さない構成が選べる — ローカルLLM（Ollama / LM Studio経由）を選択すれば推論まで自機で完結する データは自分のPCに保存される — Memory Tree DB と Markdown Vault はローカルファイルとして残る 日本語README完備 — 日本語ユーザーへの配慮も行き届いている Rust製で爆速 — コアがRustで書かれており、動作が軽快 ただし注意点がある。デフォルト構成では「サインイン」「モデルルーティング」「Web検索プロキシ」「Composio経由のOAuth/ツール連携」がすべてOpenHuman（TinyHumans）社のマネージドバックエンドを経由する。つまり初回起動時に TinyHumans アカウントを作って有料サブスクに入らないと、せっかくのMemory TreeもAuto-fetchも動かない。「完全オフライン」を額面どおりに実現するには、ローカルモデル＋Composio直接モード＋自前のWeb検索APIキー、といった追加設定が必要になる。詳細は後述する。 主な機能 Memory Tree + Obsidian Vault OpenHumanの中核機能は Memory Tree だ。接続した各種サービスから取得したデータを3,000トークン以内のMarkdownチャンクに圧縮し、SQLiteに階層的に保存する。同時に、Obsidianと互換性のある .md ファイルとしてローカルVaultへ書き出す。 ...

概要 Open Notebook は、Google NotebookLM のような「ノートにソース文書を集約 → AI に質問」型のリサーチツールを OSS で実装したプロジェクト。プライベートな文書や機密データを外部 SaaS にアップロードしたくないユースケースで、ローカル LLM や任意の API バックエンドと組み合わせて使える点が特徴。 NotebookLM との関係 NotebookLM は Google が提供するソース駆動の AI ノートで、PDF・Web・YouTube などをノートに追加すると LLM が文脈を理解した回答を返す。Open Notebook はそのオープンソース版として、機能を再現しつつバックエンド LLM を差し替えられる柔軟性を持つ。 想定ユースケース 機密文書の要約・QA: 社外秘・クライアント文書を外部にアップロードせず分析 研究ノート: 論文・ノート・実験ログを統合してエージェント風に質問 個人の知識ベース: Obsidian や Markdown ファイル群と連携した「自分専用 NotebookLM」 関連ページ RAG — 同じ「文書集約 + 質問応答」のパターンの背景概念 Obsidian — 個人ノートとの組み合わせ候補 Ollama — ローカル LLM バックエンド ソース記事 Open Notebook — NotebookLM の OSS 代替 — 2026-04-22

海外で発生した実際のインシデント「An AI Vibe Coding Horror Story」を元に、AI に開発を丸投げするリスクを解説します。技術的リテラシーのないまま本番環境を構築した結果、患者データが完全露出するという深刻な事態が起きました。 何が起きたのか 専門知識のない医療従事者が、AI を使って自分専用の患者管理システムをゼロから自作しました。業界で実績のある既存ソフトウェアを使わず、「自分のバイブ（感覚）」で開発を進めたのです。 元記事: An AI Vibe Coding Horror Story システムの問題点 AI が生成したこのアプリには、致命的なセキュリティ上の欠陥が多数ありました。 アーキテクチャの問題 単一 HTML ファイル構成: すべてのプログラムが 1 つの HTML ファイルに詰め込まれた簡素な構造 クライアントサイド認証: パスワードなどの認証機能がブラウザ側の処理だけで実装されていた アクセス制御なし: データベースへのアクセス制限が全くなく、誰でも中身を閲覧できる状態 データ管理の問題 蓄積されていた大量の患者データをそのまま自作アプリに移行 全データが暗号化されず、無防備な状態で公開サーバーに配置 適切なセキュリティ設定をしないままインターネット上に公開 プライバシーの問題 診察中の会話を録音し、外部の AI サービスに送信して要約させる機能を実装 患者の個人情報や音声データが、事前の同意なく海外のサーバーへ転送 被害の深刻さ わずか 30 分の調査 で、全ての患者データに対する読み書き権限が奪取されました。 患者の個人情報が完全に露出 音声データも含めた機密情報が外部に流出 現地の個人情報保護法や医療従事者の守秘義務に違反している可能性が極めて高い状況 問題の本質 不備を指摘された本人は、AI が生成した定型文で回答し、問題の深刻さを理解していませんでした。 これはバイブコーディングの本質的なリスクを示しています： AI はコードを生成できるが、セキュリティ要件の判断はできない 開発者が仕組みを理解していないと、問題が起きても原因を特定できない 「動いているように見える」と「安全に動いている」は全く別の話 開発の民主化とリテラシーのトレードオフ AI によって開発の民主化が進み、非エンジニアでもアプリケーションを作れる時代になりました。一方で、最低限の技術的リテラシーがないと重大な事故を招くリスクも同時に高まっています。 特に以下の領域では、専門知識なしの AI 開発は高リスクです： 領域 リスク 医療・健康データ 個人情報保護法・医療法違反 金融データ 金融規制・顧客情報保護 個人認証システム なりすまし・不正アクセス 本番環境のインフラ サービス停止・データ消失 まとめ バイブコーディングは強力なツールですが、「AI に生成させたコードを理解できる人間が監督する」 という原則なしには危険です。 ...