← 2026-03-17 の一覧へ戻るホーム
小さなWebは、あなたが考えているよりもずっと大きいものです。

2026/03/17 2:17

小さなWebは、あなたが考えているよりもずっと大きいものです。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

日本語訳:

概要

本文は、「小さなウェブ」― 通常のブラウザとサーバーでアクセスできる非営利・個人向けサイトが依然として膨大かつ活発だが、1 ページだけでまとめるにはあまりにも大きい」という事実を説明しています。

  • 背景：Gemini プロトコルは世界中に約 6,000 のカプセル（capsule）という独自のエコシステムを持ち、そのフォーラムには主に IT 専門家で構成される約 100 名が参加し、商業的利用は推奨していません。
  • 手法：著者は Kagi が公開する更新フィードを配信しているサイトのリストを使用しました。このリストは昨年の約 6,000 件から今日では約 32,000 件に増加し、多くはプライベートブログや企業がホストするサイト（例：Blogger）です。
  • フィルタリングプロセス
    1. 各フィードをダウンロードし、タイムスタンプと有効な XML があることを確認した結果、約 25,000 サイトに絞られました。
    2. 月間更新が 1 回未満のサイトを除外すると、約 9,000 のアクティブサイトが残ります。
  • 結果：3 月 15 日時点でこれら 9,000 サイトは 1,251 件の更新（主に新しいコンテンツ追加）を生成し、過去の日付とほぼ同程度です。毎日の更新量を見ると、単一ページの集約は非実用的であり、小さなウェブはその規模と活発さからそのような表示には不向きです。
  • 結論：サイズが大きいにも関わらず、小さなウェブは成長を続け、主流プラットフォームに対する広告なしの代替手段として機能します。
  • 行動喚起：著者は読者に対し、このページへの参照 URL を含む Webmention を送信してもらい、継続的な関与を促しています。

本文

現在、インターネットの一部を非商業的・個人利用向けに再確立しようとする取り組みがいくつかあります。前回の記事でそれらのうちのいくつかについて触れましたが、ここでは「小さなウェブ（small web）」という用語を、広告や企業によるトラッキングがないプライベートサイトに使われている通常のブラウザとサーバーを指すものとして使用しています。

また最近、私はGeminiプロトコルも採用しました。Geminiは従来のウェブとは全く別のプロトコルとソフトウェアを利用しており、その制限が故に商業的な活用がほぼ不可能です。そのためその最大の魅力となっています。Geminiの利用者数を正確に把握することは難しく、世界中には約6,000件のGemini「カプセル」（サイト）が存在するとされていますが、その多くは稼働していないようです。Geminiのオンラインフォーラムでは活動ユーザーが百人程度で、現在は主にITプロフェッショナルが参加しています。

小さなウェブの規模を考えるきっかけとなったのは、Geminiでフィードアグリゲータ（feed aggregator）を使っていたことです。通常のウェブと同様に、Geminiカプセルの運営者はコンテンツ更新時にフィードという形式で通知することが多いです。これは各更新ごとにタイムスタンプを付けたXML文書（ATOMやRSS）が一般的です。

「フィードアグリゲータ」とは、複数サイト・カプセルのフィードを調べて、更新情報を時系列でまとめて公開するサービスです。Geminiのフィードアグリゲータを見ると、コミュニティ全体で何が新しくなったか一目で分かります。

Geminiカプセルは稼働数が少ないため、複数（あるいはすべて）のカプセルの更新を1ページにまとめることが実用的です。現在利用可能なGeminiフィードアグリゲータはいくつかあり、新しいコンテンツの検出方法や情報提供の仕方で差異があります。

私はほぼ毎日Geminiフィードアグリゲータを確認しており、常に興味深い内容が見つかります。そこで思ったのは、「小さなウェブ全体」でも同じようなものを実装できないかということです。全ウェブの更新情報を1ページに集約するのは非現実的であり、特に困難でしょう。しかし、小さなウェブは本当に小さいので、毎日の更新数がそれほど多くないのでは？

このタスクに挑むには、まず「小さなウェブ」のサイトリストが必要です。自分で作るつもりはありませんでしたが、幸いにもその手間を省けました。Kagi検索エンジンは、小さなウェブイニシアチブの一環として、そのようなリストを公開しています。このリストにはKagiユーザーが推薦したサイトが含まれ、選定基準として「小さい」ことに加え、サイトが更新フィードを提供している点があります。

Kagiのリストは主にプライベートサイトやブログで構成されており、一部はBloggerなど企業プラットフォーム上のブログも含まれます。昨年末にチェックした時点では約6,000件が掲載されており、Geminiカプセルとほぼ同数でした。その多くが非活発になるだろうと予想していました。

昨日再度リストを確認すると、32,000件程度まで増えていたことに驚きました。これは期待よりも多い数字ですが、フィードの集約ではサイト数よりも更新頻度が重要です。

フィードリストだけからは各サイトの活発度を判断しづらく、私はプログラムを書いて各フィードをダウンロードし、タイムスタンプで更新頻度を測定しました。全てのフィードにタイムスタンプが付いているわけではありません（必須ではないため）ので、時系列で並べるにはそれらが必要です。そのため、タイムスタンプが欠如していたり、インデックスできなかったサイトは除外しました。また、ダウンロード失敗や有効なフィードを返さないURLも除外しました。

これによりリストは約25,000件まで削減されました。さらに、月に1回未満の更新しかないサイトを除外すると、残りは約9,000件です。

その中には月1回程度しか更新しないものもあれば、毎日更新するものもあります。3月15日時点では1,251件の更新があり、以前の日付でも同様でした。これら「更新」は単なるスペル修正に留まらず、新しいコンテンツが追加されたことを示します。

したがって良いニュースと悪いニュースは基本的に同じです：小さなウェブは大きすぎて、1日でも全更新を1ページに掲載するには非現実的であるという事実。良い点としては、小さなウェブが非常に活発で成長していることです。一方、Geminiのようなフィードアグリゲータを導入したかった私にとっては、現在の「小さい」ウェブの規模が実用的ではないという悪いニュースとなります。

公平に言えば、「小さな」ウェブはサイト数で定義されたものではなく、商業的影響力の欠如によって定義されます。広告主に支配されたインターネットの中でもプライベート・非商業的なウェブサイトが存在し続けること自体を祝福すべき事実です。

このページに対して何か投稿しましたら、ぜひWebmentionで通知してください。その際は、このページを参照したブログやページのURLを添えていただければ幸いです。

同じ日のほかのニュース

一覧に戻る →

2026/03/17 5:59

MistralがLeanstralをリリース --- (※「Leanstral」はそのまま固有名詞として扱います。)

## Japanese Translation: --- ## Summary Leanstral は **Lean 4 専用に設計された最初のオープンソースコードエージェント** であり、Apache 2.0 ライセンスの下でリリースされ、重みファイルをダウンロードできるほか、一時的な無料 API エンドポイント（`labs-leanstral-2603`）と公開された技術レポートがあります。 このモデルは **証明工学タスクに最適化された非常にスパースな 6 B‑パラメータアーキテクチャ** を採用し、Lean を完璧な検証器として活用した並列推論を実現しています。モデルは **lean‑lsp‑mcp データセット** 上で訓練されており、Mistral Vibe 経由で任意の Model‑Composed Pipelines（MCP）をサポートします。 **FLTEval** で評価すると—FLT プロジェクトにおける形式的証明の完了と新概念の定義をベンチマークし、単独の数学問題ではなく実際のタスクを測定する—Leanstral‑120B‑A6B は **pass@2 スコア 26.3 と pass@4 スコア 29.3** を達成し、GLM5‑744B‑A40B（≈16–20）や Kimi‑K2.5‑1T‑32B よりも優れた性能を示しています。Claude 系列モデルと比較すると、Leanstral は **$36 で pass@2 スコア 26.3** を達成し、Sonnet の $549（スコア 23.7）に対して同等の性能です。また **pass@16 スコア 31.9 が $531** で得られ、Sonnet の $8,031.9 と比較しても大幅に低価格です。Claude Opus 4.6 モデルは依然として最高品質ですが、$1,650 という価格は Leanstral の同等スコア時の費用の約 90 倍以上になります。 実際のケーススタディでは、その実用性が示されています： * Lean 4.29.0‑rc6 の破壊的変更を診断し、`def` と `abbrev` 間の定義等価性問題を特定して正しい修正案を提示し、ユーザーに説明しました。 * Princeton の CS 441 コースから Rocq 定義を Lean に変換し、カスタム記法を扱い、証明が提供されていないプロパティも自動で証明しました。 Leanstral は **Mistral Vibe** に統合されており、ユーザーは `/leanstall` エンドポイントを呼び出してゼロセットアップのコーディングと証明を行えます。一時的な API エンドポイント（`labs-leanstral-2603`）はフィードバックと観測データ収集のために利用可能です。ユーザーはモデル重みをダウンロードし、Leanstral をローカルで実行したり、Mistral Vibe にサインアップして完全なドキュメントへアクセスすることもできます。 この軽量かつコスト効果の高いツールは、開発者や研究者が形式的検証ワークフローを加速させるために活用でき、コミュニティへの貢献と学術界および産業界での広範な採用を促進します。

2026/03/17 3:12

Meta、jemallocへの再挑戦を強化

## Japanese Translation: ``` ## Summary Meta は、Linux カーネルや Meta のインフラストラクチャ内のコンパイラなど重要なコンポーネントを動かす高性能メモリアロケータである jemalloc に注力することを決定しました。この移行は長期的なメリットに基づいており、保守コストの削減、コードベースの近代化、および進捗を遅らせていた技術的負債の排除が目的です。今回の取り組みの一環として、オリジナルのオープンソース jemalloc リポジトリはアーカイブから外されました。 主な改善領域は以下の通りです： - **技術的負債削減** – 効率と信頼性を向上させるためにクリーンアップとリファクタリングを実施。 - **Huge‑Page Allocator (HPA)** – CPU の効率化を図るためにトランスペアレントヒュージページ（THP）の使用を改善。 - **メモリ効率** – パッキング、キャッシュ、およびパージング機構の最適化。 - **AArch64 最適化** – ARM64 プラットフォームでのアウト・オブ・ザ・ボックス性能を確保。 Meta はオープンソースコミュニティに貢献を呼びかけ、jemalloc の将来ロードマップを共に形作ることによって、Meta 自身のソフトウェアユーザーとこのアロケータに依存する広範なエコシステム双方に利益をもたらすよう促しています。 ```

2026/03/16 22:09

私の旅―信頼性が高く、楽しめるローカルホスト型音声アシスタントへ（2025）

## Japanese Translation: > Home Assistantは、従来のGoogle‑Home/Nest Miniセットアップを置き換える完全にローカルな音声アシスタントを、llama.cppによって駆動させることができるようになりました。テストでは、RTX 3050からRTX 3090まで、またRX 7900XTXのGPUを使用すると、1〜2 秒の音声→テキストレイテンシー（中程度のカードでは約3〜4 秒）が得られます。音声ハードウェアにはHA Voice Preview Satellite、Pixel 7a hub、およびUSB4 eGPU付きBeelink MiniPCが含まれています。ASRオプションとしてはWyoming ONNXがCPU推論で約0.3 秒を実現し、Rhasspy Faster Whisperは遅いです。テストされたTTSエンジンはKokoro（ミックス可能な音声、全テキスト）とCPU上のPiper（一般的なテキストには良好だが数字や住所では苦戦します）。 > ローカルLLM統合により、「LLM Conversation」モードとツール呼び出し用「LLM Intents」が追加され、ウェブ検索・場所検索・天気予報などを可能にします。カスタムウェイクワードトレーニング（“Hey Robot”）はGPUで約30 分実行され、許容できる誤検出率が得られました。自動化では、トリガーされていないときにミュートになるよう設定できます。例として「Music Shortcut」自動化は衛星を`media_player`にマッピングし、`music_assistant.play_media`を呼び出します。 > プロンプトエンジニアリングが重要です：各サービス用の専用セクションと簡潔な箇条書き指示でツール呼び出しが改善されます。絵文字の削除は精度向上に寄与します。llama.cppによるパフォーマンス最適化と慎重なGPU選択により、レイテンシーを3 秒以下に保ち、プライバシーファーストのローカル音声制御として信頼性があります。著者は、このソリューションには相当な研究・忍耐・チューニングが必要であると警告し、高度なHome Assistantユーザーやカスタマイズ性・クラウドフリーを求める開発者に最適であると述べています。