Local AI Compass：選択を減らしてローカルAIへ入るケーススタディ

1. Project概要

WindowsでローカルAIを始める人へ、PC条件、導入、GGUF選び、トラブル解決をつなぐ診断入口。

対象

Windowsユーザー / ローカルAI初心者

カテゴリ

AI・ローカルAI・開発

構成

React + Viteの静的Webアプリ

確認したGit履歴

2026-07-11の直近コミットまで

公開サイトを開く ↗GitHubリポジトリを開く ↗

2. 最初の問題と検索意図

Local AI CompassのProjectデータには、環境選び、PC負荷、接続トラブルが問題として記録されています。WindowsローカルAIの初心者は、ツール名を知る前に「自分のPCで動くか」「何から始めるか」「困ったときどこを見るか」を判断する必要があります。

そのため検索入口は、単一の製品紹介ではなく、PC条件、目的、導入、GGUF選び、トラブル解決を順番に読む構成として確認しました。これは検索順位や検索数の推測ではなく、公開されている画面とデータから整理した検索意図の仮説です。

照合単位は四つに分けます。公開画面で読める導線、リポジトリで確認できる実装、Project dataに記録されたproblemとlesson、そしてこのケーススタディでの解釈です。順位、クリック、利用者の完了率はこの証拠束には含めず、分からないものを成果として補いません。

3. コンテンツ構造と役割分担

診断だけで完結させず、結果から記事、ツール、開始ガイドへ進めるため、短い操作と長い説明に役割を分けています。

4. 静的HTMLと操作の分担

確認したリポジトリはReact + Viteで構成されています。画面全体はReactで組み立てつつ、`npm run build`後に`generate-static-routes.mjs`で静的ルートを生成し、`public/`にsitemap、robots、OGP画像を置く運用です。

この事例から再利用できる判断は、フレームワーク名ではなく責務の分離です。診断の入力と結果はクライアントで変化しますが、記事、ガイド、比較表、meta、直接URLは静的成果物として確認します。BUILD ORBIT側の設計パターンでは静的な本体に操作だけを重ねるに接続します。

5. 初心者導線

1. 自分のPCで動くかを診断する。
2. LM Studio、Ollama、GGUF、GPUなしなどの言葉を目的別に読む。
3. 最初に試すモデルやツールを一つへ絞る。
4. 重い、止まる、接続できないときは症状別の記事へ移る。

Projectデータで確認できる教訓も「最初の選択を減らすと長い解説も読まれやすい」です。利用者の反応や改善率を示す記録ではなく、制作時に置かれた判断として扱います。

6. 内部リンクとSEO設計

• 診断結果から、目的や症状に一致する記事へ接続する。
• 記事から診断・比較・開始ガイドへ戻し、読み物を終点にしない。
• タイトル、description、canonical、OGP、JSON-LD、sitemapを静的生成物として確認する。
• 公開サイトとGitHubのURLを外部リンクとして明示し、リンク先の意味をaccessible nameへ含める。

Local AI CompassはBUILD ORBITのProject AtlasのLocal AI Compassからもこのケーススタディへ戻れるようにしています。 要件の再利用と集計の前提はResourcesで照合できます。

7. アクセシビリティと検証

このケーススタディで確認したのは、診断フォーム、結果、比較表、記事リンクが役割を持って実装されていることです。個別の公開サイトの全画面をこのリポジトリのテスト結果として誤記せず、BUILD ORBIT側ではno-JS、keyboard、320px、axe、route、link、upload parityを別に検証します。

診断の結果は一般的な目安であり、PC構成、OS、GPU、VRAM、モデル、ツールのバージョンで変わります。これは公開READMEにも記載された注意で、断定的な診断結果を作らないという選択を減らす診断フローの条件に対応します。

8. 採用Pattern

• 選択を減らす診断フロー：PC条件と目的を質問し、最初に読むものを絞る。
• 静的な本体に操作だけを重ねる：記事・ガイド・比較表と診断操作の責務を分ける。

9. うまくいかなかった案

• ツール比較を最初に置き、初心者へ製品名を先に選ばせる。
• 記事を増やすだけで診断結果や次の行動へのリンクを用意しない。
• PC条件を無視して、動くモデルや速度を一つに断定する。

これらは公開画面とデータの役割分担から確認できる「避けた設計」であり、A/Bテストの結果や利用者の反応ではありません。

10. 次へ再利用できる教訓

1. 検索入口は製品名ではなく、最初の不安と判断単位から作る。
2. 診断の質問、判定ルール、説明記事、次のリンクを別データとして保つ。
3. 結果の便利さと同じ画面に、前提・注意・別ルートを置く。
4. 静的配信では、build成功だけでなく直接URL、sitemap、404、納品物を確認する。