ファイルマネージャーを開いて、ざっと中身を見てみてください。
契約書、報告書、論文、提案書、請求書、電子書籍、メモ、備忘録、会議議事録——これらはあなたのコンピューター上で最も価値のあるファイルです。仕事の成果、蓄積された知識、ビジネスの取引を記録しています。
さて、自分に問いかけてみてください：あなたのAIアシスタントは、これらを読めますか？安心してアップロードできますか？
答えは「できない」です。
エクスプローラー、Spotlight、Raycast…ファイル名でしか検索できません。Linuxのgrepは、PDFやWordのバイナリ形式を読み取れません。Claude、ChatGPT、Cursor——これらはあなたのコンピューター上のコード以外のドキュメントについて何も知りません。
コードはすでに十分にインデックス化されています。IDEには検索機能があり、grepは行単位で特定でき、Claude CodeはGlob+Grep+Readの三つの武器でコードベース全体を隅々まで調べ上げます。しかし、あなたのドキュメントは？AI時代の「ダークマター」になってしまっています——存在はするのに、見えない。 多くのAIナレッジベースがこれらのコンテンツを活用しようとしてきましたが、いまだに十分とは言えません。
私たちはこの問題を解決するツールを作りました。この記事では、なぜ作ったのか、どう作ったのか、そしてどんな落とし穴があったのかをお話しします。
AI時代でも、あなたのドキュメントは依然として情報の孤島
私たちは奇妙な断裂点にいます。
一方ではAIの能力が爆発的に成長しています。Claudeはコードを書き、データを分析し、文献を要約し、提案書を起草できます。もう一方では、あなたのコンピューター上の数百のPDF、数十のWordドキュメントに、AIはほとんど手が届きません。
数十のドキュメントならまだこれらのAIにアップロードできますが、数百、数千となると手に負えません。
ChatGPTに一般的な質問をすれば、流暢に答えてくれます。しかし「先月のプロジェクト提案書の技術スタック選定の部分に何を書いたか」と聞いても、答えは「申し訳ございませんが、ローカルファイルにはアクセスできません」だけです。
これはAIの問題ではなく、インフラの問題です。AIはすでに十分に賢いのですが、ローカルに保存されたドキュメントを見るための「接続」が欠けています。 そして、これらのドキュメントこそが最も価値あるコンテキストなのです。一般的な知識はAIがすでに持っています。AIが本当に役立つのは、あなたの具体的な状況を理解しているとき——契約条件、プロジェクトの背景、研究資料を知っているときです。
既存のソリューションが不十分な理由
RAG（Retrieval-Augmented Generation）という言葉を聞いたことがあるかもしれません。過去2年間、「AIにドキュメントを読ませる」ソリューションのほぼすべてがRAGベースでした。
RAGの仕組みはこうです：ドキュメントを小さなチャンクに分割し、各チャンクのEmbeddingベクトルを生成し、ベクトルデータベースに格納します。ユーザーが質問すると、まずベクトル検索で最も関連性の高いチャンクを見つけ、それらをAIのプロンプトに詰め込みます。
合理的に聞こえます。では、何が問題なのでしょうか？
AIが受け取るのは、あらかじめ噛み砕かれた断片です。
その断片がドキュメントのどの部分から来たのか、前後のコンテキストが何なのか、ドキュメント全体の構造がどうなっているのか——AIには分かりません。断片が足りなくても、「もう少し読む」ことができません。 もちろん、これらの問題に対処するパッチ技術は多数ありますが、通常はさらなる問題を引き起こします——コスト上昇、パフォーマンス低下、アーキテクチャの複雑さによる不安定な結果など。
これは、研究者に報告書の分析を依頼しながら、原文ではなく、報告書からランダムに破り取った5枚の紙切れを渡すようなものです。
実際の体験はどうでしょうか？AIの回答は曖昧で、的外れなことが多い。ドキュメントに答えがあるのに、チャンキング戦略が不適切だったために関連コンテンツが2つのチャンクに分割され、ベクトル検索がそのうち1つしかマッチせず、答えが失われてしまう——そんなことが起きます。
私たちは昨年、数ヶ月をかけて完全なRAGパイプラインを構築しました——3段階処理（Extract、Chunk、Embed）、3つの検索戦略（Vector、BM25、Hybrid + Reranking）を備え、それをベースにしたバージョンを開発しました。 技術的には美しい仕上がりでした。しかし最終的に、ある事実を認めざるを得ませんでした：結果が十分ではなかった。
重要な洞察：AIに必要なのは検索エンジンではなく、図書館
転機は昨年生まれたある共通認識からでした：LLMは少数の検索コマンドだけで複雑な検索タスクを自動的に完了できる。
Claude CodeはRAGを使いません。3つのシンプルなツールを使います：Glob（パターンでファイルを検索）、Grep（キーワードを検索）、Read（ファイル内容を読む）。
そのアプローチは「検索エンジンが断片を返す」のではなく、研究者がファイルキャビネットを閲覧するようなものです——まずディレクトリを見て関連しそうなファイルを見つけ、開いて目次構造を確認し、どの章が有用かを特定し、そのセクションを正確に読む。
これは人間の読書方法とまったく同じです。本をバラバラに破いてから検索する人はいません——興味のある本を見つけ、目次で関連する章を探し、そのページを開いて読むのです。
しかし、globとgrepはコードにしか適用できません。なぜでしょうか？コードベースには明確なディレクトリ構造と命名規則があるからです。src/services/auth.ts——このパス自体が認証サービスのコードだと教えてくれます。では、あなたのドキュメントは？2024年度報告書(修正版)(最終版)(本当の最終版).docx——パスが教えてくれる情報はほぼゼロです。さらに、PDFとWordはバイナリ形式なので、grepでは全く読めません。
そこで問いはこうなりました：ドキュメントにもコードベースのような「ディレクトリインデックス」を構築し、AIがsearch-browse-readの方法で段階的にファイルを閲覧できるようにできないか？
Outline Index：AIが人間のようにドキュメントを閲覧する
私たちが提案するソリューションはOutline Indexです。
コアとなるアイデアはシンプルです：各ドキュメントに「AIの名刺」を作る。この名刺にはドキュメントの核心情報が凝縮されています——このファイルが何であるか、何を扱っているか、どんな構造かが分かります。
ドキュメントのコピーではなく、原文を保存するものでもありません。ナビゲーションツールです。AIはこれを使ってドキュメントの全体像を把握し、原文を深く読むかどうかを判断します。 これは実はAgent Skillsの原理と似ています。SKILL.mdはメタデータと簡潔な説明によって、AIにスキルの全体像を把握させ、使うかどうか、どう使うかを判断させます。
各ドキュメントに対してOutline Indexを作成します。これは2つのパートで構成されます：
メタデータ：ファイル名、パスなどのメタデータ。AIが検索段階でドキュメントの関連性を素早く「判断」できるようにします。
アウトライン：ドキュメントの種類に応じて生成されるナビゲーション情報（構造的な大綱）。PDF、Markdown、Wordファイルでは、章見出し、要約、行番号などの情報を抽出します。
重要な設計原則は**段階的開示（Progressive Disclosure）**です：すべての情報を一度にAIに渡すのではなく、必要に応じて段階的に深掘りさせます。
- Layer 1 — search：関連ファイルのリストを返す。1ファイルあたり約50トークン。20件でもわずか1,000トークン。
- Layer 2 — outline：ドキュメントの構造マップを返す。1ファイルあたり約200-500トークン。このレイヤーでAIはどの章が最も関連性が高いかを判断できます。
- Layer 3 — read：原文の指定された章・行を読み取る。オンデマンドで読み込み。
従来のRAGと比較すると：RAGは一度に数十のチャンク、数千から数万トークンの雑多な断片情報を返し、かえってAIの回答品質に悪影響を及ぼす可能性があります。 Outline Index方式はより正確で、トークン効率が高く、Agentic能力を持つAIは必要な情報を素早く正確に見つけることができます。
3つのシンプルなツールで、無限の可能性
システム全体が外部に公開するのは3つのMCPツールだけです：
- search(query, filters?) — ドキュメントを検索し、マッチしたファイルリストとメタデータを返す
- outline(path[]) — 1つまたは複数のドキュメントのアウトライン構造を表示
- read(path, anchor?) — ドキュメント原文の指定部分を読み取る
これだけです。
例を挙げましょう。Claude Codeで「Dockerデプロイに関するドキュメントを探して」と聞きます。
- Claudeが
search("Docker デプロイ")を呼び出す → 5ファイルのメタデータが返される - Claudeは
.env.example（短いファイル）とdeployment-guide.pdf（長いドキュメント）を確認 - 短いファイル → 直接
read（数百字、読了） - 長いドキュメント → まず
outlineで構造を確認 → “Docker Setup” の章を発見 →readでその章を正確に読み取り - 合計消費：約800トークン。正確な情報を取得
従来のRAGは同じシナリオで10個の断片を返し、4,000-6,000トークンを消費します。コンテキストは不明で、「もう少し読む」こともできません。
さらに興味深いのは創発的能力です。3つのアトミックツールを組み合わせると、LLMは自然にこうしたことを行います：
- クロスドキュメント分析：2つの提案のメリットとデメリットを比較
- 既存資料に基づく執筆：過去の週報のスタイルを参考に新しい週報を作成
- パーソナルナレッジ検索：存在すら忘れていたファイルを発見
- 検索リトライ：初回の検索結果が不十分なら、AIが自動的にキーワードを調整して再試行
これらの能力のために、エージェントオーケストレーションロジックを開発する必要はありません。LLMは自然にツールを組み合わせて複雑なタスクを完了します。私たちはこの3つのアトミックツールを適切に提供するだけでいいのです。
極限の軽量さ
Linkly AIはバックグラウンド常駐ツールです。Dropboxのように：インストール → フォルダを選択 → あとは忘れる。バックグラウンドで静かにインデックスを構築し、あなたは普段通りの作業を続けます。
24時間365日バックグラウンドで実行されるアプリケーションにとって、パッケージサイズとリソース使用量は生命線です。ユーザーはアクティビティモニタでメモリ使用量をチェックします。常駐バックグラウンドツールが150MBのメモリを消費すれば、ユーザーは躊躇なく終了するでしょう。 Linkly AIのインストーラーはわずか約20MB。完全な検索エンジンとドキュメント解析機能を内蔵しています。実行時メモリ使用量は約50-100MB。設計目標は：存在を感じさせないほど軽量であること。
段階的可用性設計も重要です：インストールから1分でキーワード検索が使えます。セマンティック検索はインデックス完了後にシームレスに利用可能になります。
100%ローカル、データ収集ゼロ
あなたのファイルがコンピューターから出ることはありません。
テキスト抽出、インデックス構築、検索マッチング——すべてローカルで完結します。クラウドへのデータアップロードなし。テレメトリなし。「匿名使用データ収集」なし。 Outline Indexはローカルに保存され、抽出されたプレーンテキストも同様にローカルファイルシステムに保存されます。
これはビジネス戦略上の選択ではなく（プライバシーは確かに差別化要因ですが）、エンジニアリング上の必然です。ドキュメント検索は高速でなければならず、ネットワークのラウンドトリップは体験を損ないます。ローカルハイブリッド検索のレイテンシは通常ミリ秒レベル——これはどのクラウドソリューションにも実現できません。
MCPプロトコルとCLIツールを通じて、Linkly AIはCodex、Cursor、Claude Codeなどのツールにシームレスに統合されます。将来的にはトンネル機能をサポートし、クラウドAIがローカルドキュメントに安全にアクセスできるようにする予定です。
設定1行で、あなたのAIアシスタントがコンピューター上のドキュメントを「見る」ことができるようになります。ツールを切り替える必要はありません——お気に入りのAIツールをそのまま使い続けてください。
今すぐ試してみよう
Linkly AIのポジショニングはシンプルです：Spotlight for AI。AIがローカルドキュメントを摩擦なく利用できるようにする。
インストール → フォルダを選択 → あとは忘れる。
バックグラウンドで静かにインデックスを構築します。すると、あなたのClaude、Cursor、ChatGPTが、突然コンピューター上のPDF、Word、メモ、電子書籍を「見える」ようになったことに気づくでしょう。
APIキー不要。モデル選択不要。「ナレッジベース」の作成不要。RAGやEmbeddingが何なのか理解する必要もありません。
ファイルの場所を教えるだけ。あとはLinkly AIにお任せください。
Linkly AI チームが開発