KarpathyのLLM Wikiを「使えるセカンドブレイン」に:Amazon Quick Desktopで実装してみた

Dima Kramskoy — DoiT International シニアクラウドアーキテクト ソフトウェア開発歴20年以上 ・ AWS認定10冠 ・ AWS Community Builder 2026 ・ Juval Löwy氏のArchitect Master Class (2022) 修了

課題:会話のたびに、毎回ゼロから

個人的にずっと引っかかっているアンチパターンがあります。AIアシスタントとアーキテクチャの意思決定、トレードオフ、制約について45分みっちり議論する。タブを閉じる。翌日、新しいチャットを開く。AIは何ひとつ覚えていない。また一からのオンボーディングです。

これを自分の知識面すべてに広げて考えてみてください。二度と検索で掘り起こせないコンテキストを抱えたSlackスレッド、14通目の返信に判断が埋もれたメールの応酬、2つのドライブに3つのバージョンが散らばるドキュメント、そして人の頭の中にしか存在しない暗黙知。

自分の後任者にSlackの履歴だけ渡してオンボーディングを済ませたい人など、まずいないはずです。にもかかわらず、私たちがAIツールにやらせているのは事実上それと同じ —— 断片だけを渡して、筋の通った理解を期待しているのです。

本質的な問題は知能ではありません。GPT-4、Claude、Gemini —— どれも十分に賢い。問題は健忘症です。セッションはすべてコールドスタート。コンテキストは十数個のツールに散らばり、あなたとあなたの仕事を統一的にモデル化して橋渡しするものは存在しないのです。

何カ月もこのことを考えていました。そんなとき、Karpathyが解決策の輪郭をくっきりと描き出すツイートを投稿したのです。

Karpathyのヒント:RAGは「引く」、Wikiは「積み上がる」

2026年4月、Andrej KarpathyがX上で「LLM Wiki」について投稿し、現時点で1,700万回以上閲覧されています。その核心は、デザインパターンがカチッとはまる瞬間のように腑に落ちるものでした:

「RAGは引いてくる。Wikiは積み上がる。」

フレームワークはシンプルで美しい。3層構造です:

1. Raw Sources(生のソース) —— 記事、論文、ツイート、会話、メモ
2. Wiki —— 蒸留され、構造化され、相互にリンクされた知識ページ
3. Schema(スキーマ) —— 知識の整理ルールを定めるオントロジー

彼のたとえが秀逸です:「ObsidianはIDE。LLMはプログラマー。Wikiはコードベース。」

Matt Paige氏がこのコンセプトについて優れた解説記事を書いています。発想の転換はこうです:生のドキュメントをベクトルDBに放り込み、検索が正しいチャンクを拾ってくれるのを祈るのではなく、LLM自身が時間をかけて手入れし豊かにしていく**「生きた構造化ナレッジベース」**を育てる、ということ。

RAGはルックアップ。Wikiはシステム。前者はクエリごとにO(1)。後者は積み上がっていく。

ただ、Karpathy版で引っかかった点があります。手動なのです。オペレーターは自分。プロンプトを書き、レビューし、貼り付け、整理する。LLMは手伝うけれど、運転席にいるのは自分。私が欲しかったのはそこではなく —— 自分が運用するシステムではなく、これを代わりにやってくれるアシスタントだったのです。

なぜAmazon Quick Desktopを選んだのか

この実装に使うツールを評価するにあたり、Karpathyのアーキテクチャから直接落とし込んだチェックリストを用意しました:

• ✅ 会話をまたいで持続する長期記憶
• ✅ ナレッジグラフ(Slack、メール、カレンダーからエンティティと関係性を自動抽出)
• ✅ ローカルファイルに対するセマンティック検索
• ✅ 自分のファイルシステムへの読み書きアクセス
• ✅ バックグラウンドタスク(別の作業中に裏でリサーチ)
• ✅ 連携ツール(Gmail、Slack、Googleカレンダー、MCPサーバー)
• ✅ アクション層(メールのドラフト作成、ドキュメント作成、会議設定が可能)

Amazon Quick Desktopには、Karpathyが語っていたものがすでに揃っていました —— しかも組み込みで、実際の業務ツールと接続済みで。チャットウィンドウではなく、ランタイムだという感覚です。

ざっくり比較:

決め手はこれです:欲しかったのは、自分が運用するシステムではなく、自分の代わりに知識を積み上げてくれるアシスタント。 手動Wikiの運用コストは、定着を阻む最大の敵。これまで何度も目にしてきました。

1週間で組み上げたもの

フォルダ構造

~/SecondBrain/
├── raw/                          # 未処理の入力
│   ├── articles/
│   ├── transcripts/
│   └── captures/
├── wiki/                         # 蒸留した知識
│   ├── concepts/                 # メンタルモデル、フレームワーク
│   │   ├── second-brain-architecture.md
│   │   ├── rag-vs-wiki-pattern.md
│   │   └── approval-workflow-pattern.md
│   ├── entities/                 # 人、組織、ツール
│   │   ├── doit-international.md
│   │   └── amazon-quick.md
│   ├── projects/                 # 進行中の仕事
│   │   ├── genai-skill-share-talk.md
│   │   └── voice-capture-pipeline.md
│   ├── sources/                  # インデックス済みの参照
│   │   └── karpathy-llm-wiki.md
│   └── log/                      # 日次アウトプット記録
│       ├── 2026-05-19.md
│       ├── 2026-05-20.md
│       └── ...
├── SCHEMA.md                     # オントロジー
└── mkdocs.yml                    # 自動配信ドキュメント

SCHEMA.md(抜粋)

# SecondBrain Schema v1.0

## ページタイプ
- **concept**:メンタルモデル、パターン、フレームワーク。必須項目:定義、使いどころ、アンチパターン、関連する概念。
- **entity**:人、組織、ツール。必須項目:役割/目的、自分の仕事との関係性、最終やり取り日。
- **project**:進行中または完了した仕事。必須項目:ステータス、ステークホルダー、意思決定ログ、次のアクション。
- **source**:取り込んだ記事/講演/論文。必須項目:URL、重要な気づき(最大5つ)、既存概念とのつながり。
- **log**:日次エントリ。自動生成。記録内容:作成したページ、更新したページ、回答した質問、実行したアクション。

## 命名規則
kebab-case。ファイル名に日付は入れない(frontmatterで管理)。

## 相互リンクのルール
新規ページはかならず既存ページの1つ以上にリンクすること。孤立ページは危険信号。

スタック構成

• MkDocs + Materialテーマ —— Wikiをローカルのlocalhost:8000に自動配信
• launchd plist —— ログイン時にMkDocsを起動(macOS)。ブラウズまでの摩擦ゼロ。
• Amazon Quick —— Wikiの読み書き、更新案の提示、Wikiに対する質問への回答
• セマンティックインデックス —— Quickが~/SecondBrain/をインデックス化し、文脈に応じて検索

承認ワークフロー

ここが肝です。私のOKなしには何も書き込まれません。流れはこう:

1. 「この記事を取り込んで」と言うか、リンクを共有する
2. Quickが読み込み、新しいWikiページ(または既存ページへの更新)を提案する
3. 差分を確認 —— 新規コンテンツがハイライトされ、相互リンクも表示される
4. 承認・修正・却下のいずれかを判断
5. 承認されたコンテンツがディスクに書き込まれ、MkDocsが自動でリフレッシュ

最初の1週間でWikiページが15枚超。 ガリガリ作業した結果ではなく、もともとしていた会話から自然に生まれたものです。

ある1日の流れ

朝:

「おはよう」

Quickが返してくれるのは、優先メール(フラグ付き、またはキーパーソンからのもの)、返信が必要なSlackスレッド、今日のカレンダーと会議用の事前メモ。情報の洪水ではなく、簡潔なブリーフィングです。

日中:

「これ取り込んで:[アーキテクチャ系のブログ記事リンク]」

Quickが読み込み、重要な概念を3つ特定し、新しいsources/ページと、既存のconcepts/ページ2つへの更新を提案してきます。差分にざっと目を通し、承認、完了。90秒。

「セカンドブレインの実装について、ブログ記事のドラフトを書いて」

私のWikiページから情報を引き出し、(過去の文章の記憶から)私の文体を踏まえ、好みのフォーマットで構成してくれます。私の仕事はゼロから書くことではなく、編集すること。

「明日、ボイスキャプチャパイプラインのディープワーク用に2時間ブロックして」

カレンダーを確認し、空き枠を見つけ、ブロックを入れ、projects/voice-capture-pipeline.mdから事前メモまで添えてくれます。

バックグラウンド:

会議に出ている間、バックグラウンドタスクが事前にキューに入れたトピックをリサーチしておいてくれます。戻ってくると一言。「ナレッジグラフのメンテナンスに関する関連論文を3本見つけました。取り込みますか?」

積み上げの効果は本物です。5日目には、自分が承認したことすら忘れていた複数のWikiページを横断的に合成して、質問に答えてくれるようになっていました。

音声キャプチャ拡張(PoC)

いちばんいいアイデアは、デスクの前ではなく歩いているときに浮かぶもの。そこで、こんなパイプラインを組みました:

アーキテクチャ

iPhone Shortcuts(またはウェアラブルのPlaud NotePin)
    → API Gateway (REST)
        → Lambda(アップロードハンドラー)
            → S3(音声バケット)
                → S3イベント → Lambda(文字起こしトリガー)
                    → AWS Transcribe
                        → Lambda(後処理)
                            → Amazon Quick Knowledge Base
                                → Wikiページを提案

動作の流れ

1. iPhoneのShortcutをタップ(またはNotePinが周囲の音を録音)
2. API Gateway + Lambda経由で音声がS3にアップロード
3. S3イベントがAWS Transcribeで文字起こしをトリガー
4. 文字起こし結果がクリーンアップ・チャンク化され、Quickのナレッジベースにプッシュ
5. 次にQuickを開くと一言。「[トピック]についての音声キャプチャがあります。Wikiページを作りますか?」

AWS側のコストは、キャプチャあたり1セントのほんの一部。Lambda関数も大したことはなく、それぞれ50行程度。価値はループが閉じること自体にあります:思いつき → 記録 → 構造化された知識 → 実行可能なもの。

率直な自己採点:7/10

うまくいっていること

• 構造 —— スキーマが一貫性を担保してくれる。ページは見つけやすく、役に立つ。
• 積み上げ効果 —— 2週目の回答は1週目より明らかに良い。本当に知っている感がある。
• 連携ツール —— SlackのコンテキストがWikiページを厚くしてくれる。カレンダー連携で現実的なスケジューリングが可能。
• アクション層 —— 知っているだけでなく、動いてくれる。ドラフト、スライド、ブッキング。
• セマンティック検索 —— 「Xについて何を決めたんだっけ?」がWiki全体で実際に機能する。

まだ詰めたいところ

• 相互リンク —— まだ完全自動ではない。リンクが薄いままのページもある。
• ヘルスチェック —— 古いページや孤立ページの定期監査をまだ実装できていない。
• 定期取り込み —— 「毎日この5つのRSSフィードをチェック」のようなcronがない。いまだに手動トリガー。
• 矛盾検出 —— 未検証。新しい情報が既存Wikiページと食い違ったら、どう振る舞うのか?

Karpathyの原案より一歩進められた点

彼のビジョンは設計図です。ただしそれは読み取り専用 —— 問い合わせる対象としてのファイル。私の実装は生み出す側です:メールのドラフト、スライド作成、会議のブッキング、ブログ記事の執筆まで。Wikiは単なる参照先ではなく、アクションの源泉になるのです。

始め方(5ステップ)

価値を得るのに、私のフル構成は必要ありません。段階的なやり方を紹介します:

5つのステップ

1. ツールをつなぐ —— Slack、Gmail、カレンダー、ローカルフォルダ。設定画面で10分。
2. とにかく話しかける —— 記憶は初日から積み上がります。会話のひとつひとつが、あなたについての学習になります。
3. 大事な会話のあとに**「これを覚えておいて」と言う** —— 明示的な記憶アンカーになります。
4. ~/SecondBrain/とSCHEMA.mdを作る —— もう一歩踏み込みたければ、構造を与えてあげましょう。
5. 全体を横断する質問を投げてみる —— 「先週、自分はどんな重要な意思決定をした?」これでハマります。

コミットメントの3段階

まずは🟢から。本当に、ここから始めてください。インフラを組もうと組むまいと、積み上げ効果は起こります。Wiki構造は、それを見える化し、検証可能にしてくれるだけのものです。

まとめ

あなたのAIは、会話のたびにゼロからやり直すべきではありません。

道具は揃っています。パターンも実証されています。Karpathyがアーキテクチャを示し、Amazon Quickがランタイムを提供する。「AIアシスタント」と「セカンドブレイン」を隔てているのは、構造 + 永続性 + 連携ツール、それだけなのです。

積み上げ > 引き出し。 会話のひとつ、取り込んだ記事のひとつ、承認したWikiページのひとつが、次のやり取りをより賢くしていく。これは検索ではなく、成長です。

小さく始めましょう。あとは勝手に積み上がります。それこそが肝心なところです。

最後にもうひとつ —— これはAI研究ではなくJocko Willinkの言葉ですが、知識に対するExtreme Ownership(極限の当事者意識)。情報が自分の世界の中にあるのに —— Slackのスレッド、うろ覚えのカンファレンストーク、朝の散歩中に浮かんだアイデア —— それをキャプチャしないなら、その情報は自分のものではありません。むしろ、いざ必要なときに取り出せないことで、こちらが情報に振り回されることになるのです。

捕まえる。構造化する。あとは積み上がるに任せる。

この記事は、私のセカンドブレインの助けを借りてドラフトを起こしました —— 前週に積み上げたWikiページから情報を引き出しながら。皮肉なのは自分でも分かっています。でも、それこそが言いたかったことなのです。

2026年5月22日、DoiTのGenAI Community Skill Shareで発表。鋭い質問で議論をさらに先へ押し進めてくれた約27名の同僚に感謝します。