AIスクレイパーのせいで良いものが作れない
Hacker News
445 pts
247 comments
何が起きたか
音楽メタデータの非営利プロジェクト「MusicBrainz」を運営するMetaBrainzが、AIスクレイパーによるサーバー負荷の深刻さを公開しました。OpenAIやAnthropicのクローラーが、robots.txtを無視して無制限にリクエストを送り続け、小規模サイトの運営を圧迫しています。
要点
- 規模：あるユーザーは160日間でOpenAIとClaudeから850万リクエストを受信。cgitページを無限にクロールし続ける挙動が報告されている
- 対策の難しさ：User-Agentをブロックしても4時間は止まらない。IPベースのブロックも効果が限定的
- 被害：小規模サイトがホスティング会社からアカウント停止処分を受けるケースも
なぜ重要か
AI企業のスクレイピングは、学習データの収集という目的がある程度は理解できます。しかし、無料で公開されているオープンソースプロジェクトのサーバーを潰す行為は、結果的にオープンなインターネットを破壊しています。MusicBrainzのような公益的なプロジェクトが運営困難になれば、最終的にはAI企業自身も学習データを失うことになります。
所感
「AIが無料のインターネットを壊している」というコメントが象徴的です。1999年のSQLインジェクション問題と比較する意見もありましたが、当時と違うのは攻撃者が「悪意のあるハッカー」ではなく「時価総額数百億ドルの企業」である点です。robots.txtの遵守を義務化する法整備が必要な段階に来ているのかもしれません。
議論の争点
HNでは以下の点が議論されています。
1. AI企業の責任
賛成派：学習データを集めるにしても礼儀がある。無制限クロールは怠慢。
反対派：技術的に完璧な制御は難しい。悪意があるわけではない。
2. 対策の有効性
賛成派：CloudflareやCAPTCHAで防げる。
反対派：小規模サイトにそこまでのリソースはない。
3. オープンWebの終焉
賛成派：AIスクレイピングがこのまま続けば、認証必須のクローズドWebに向かう。
反対派：検索エンジンのクローラーも同じ問題を起こしてきた。過剰反応では。
用語メモ
- robots.txt
- Webサイトがクローラーに対してアクセス制限を伝えるファイル。法的拘束力はない。
- User-Agent
- HTTPリクエストでクライアントを識別する文字列。クローラーの種類を判別するために使う。
次に読む：LLM過激派の危うい布教活動（AI推進派への批判という点で関連）
出典
LLM過激派の危うい布教活動
Hacker News
243 pts
261 comments
概要
「LLMに懐疑的な人は時代遅れ」「使いこなせないのは能力不足」という風潮への反論記事が話題になっています。LLM推進派の一部に見られる、批判者への人格攻撃や過剰な期待の押し付けを問題視しています。
先に押さえる3点
- 問題提起：LLMへの懐疑を「ハッカー精神の欠如」として批判する風潮がある
- 反論：Simon Willison（Django作者）やantirez（Redis作者）のような実力派もLLM推進派。能力と関係ない
- 本質：LLMは万能ツールではなく、得意不得意がある。それを認めた上で使うべき
影響
この議論は「LLMを使うかどうか」ではなく「どう使うか」に焦点を当てるべきだという方向に収束しつつあります。LLMが得意な領域（不慣れな言語でのプロトタイピング、定型コードの生成など）と苦手な領域（複雑なロジックの設計、既存コードベースの理解など）を見極めることが重要です。
実務メモ
コメントで指摘されていた「LLMの出力を見て改善点を見つけられないなら、そもそもLLMを使うスキルがない」という意見は的を射ています。LLMをGoogle検索と同じように「練習が必要なスキル」として捉えると、期待値の調整がしやすくなります。
議論の争点
HNでは以下の点が議論されています。
1. 推進派 vs 懐疑派の構図
賛成派：推進派の方がむしろ余裕がある。懐疑派の方が攻撃的では。
反対派：推進派のインフルエンサーがクリックを稼ぐために煽っている。
2. LLMの実用性
賛成派：自分のコードより良いものを常に出す、という人もいる。
反対派：そう言う人のコード品質が心配になる。
3. 議論の生産性
賛成派：冷静な評価が必要。
反対派：結局「使う人による」で終わる議論に意味があるのか。
用語メモ
- バイブコーディング
- AIに大まかな指示を与えて「雰囲気」でコードを生成させる手法。賛否両論。
次に読む：正直、生成AIはうまくいっていない（AI評価の別視点）
出典
正直、生成AIはうまくいっていない
Hacker News
216 pts
294 comments
ざっくり言うと
AI懐疑派として知られるGary Marcusが「生成AIは期待ほどうまくいっていない」と主張する記事を公開。294件のコメントで賛否が激しく分かれています。
ポイントは3つ
- 主張：生成AIは過大評価されており、実際のビジネス成果は限定的
- 反論：「数百万ドルのコードを数週間で書き直せている」という現場の声も多数
- 背景：Gary Marcusは以前から「AGIは来ない」派で、的中した予測もあれば外れた予測もある
どこに効く？
この議論で面白いのは、「1年前は懐疑派だったが、Gemini 2.5やOpus 4.5を使って考えが変わった」という声がいくつもあること。モデルの進化速度が速すぎて、数ヶ月前の評価がすぐに古くなる世界です。懐疑派も推進派も、定期的にアップデートが必要かもしれません。
一言
「汎用的なコパイロットを汎用的なユースケースに投入すると失敗する」というコメントが核心を突いています。特定の業務に特化したAI活用は成功例が多い。万能を求めると失望する、という構図は他の技術でも同じですね。
議論の争点
HNでは以下の点が議論されています。
1. Gary Marcusの信頼性
賛成派：AI業界に必要な冷静な声。
反対派：2022年の予測がかなり外れている。専門家とは言えない。
2. 「うまくいっていない」の定義
賛成派：ハイプに見合った成果は出ていない。
反対派：デザイン、写真、コード生成で既に大きな価値を出している。
3. 進化の速度
賛成派：5-6年でここまで来た。さらに改善する。
反対派：改善速度は鈍化している。限界が見えてきた。
用語メモ
- AGI
- 汎用人工知能。人間と同等以上の知能を持つAI。実現時期については専門家でも意見が分かれる。
次に読む：MozillaのオープンソースAI戦略（AI業界の別の動き）
出典
MozillaのオープンソースAI戦略
Hacker News
189 pts
199 comments
まず結論
Mozillaが公式ブログでオープンソースAI戦略を発表しました。プライバシーを重視したAI開発と、オープンなエコシステムの構築を目指すとしています。ただし、コミュニティの反応は冷ややかです。
変わった点
- 方針：オープンソースAIの開発・支援を組織の柱として明確化
- 具体策：詳細は未発表。方向性の宣言が中心
- 背景：Firefox以外の収益源を模索している状況
注意点
コメント欄で最も多かった意見は「AI戦略より、まずFirefoxを改善してほしい」というもの。Mozillaへの信頼が低下している中での発表であり、「また中途半端に終わるのでは」という懸念が強く出ています。実際、過去のMozilla.aiやPocket買収なども成功とは言い難い状況です。
使うならこうする
Mozillaの動向を見守る価値はあります。ただし、期待しすぎないほうがいいでしょう。オープンソースAIに興味があるなら、Hugging FaceやOllamaなど、既に実績のあるプロジェクトを優先的にフォローすることをお勧めします。
議論の争点
HNでは以下の点が議論されています。
1. Mozillaの信頼性
賛成派：内容自体は正しい。誰かがやるべき仕事。
反対派：過去の失敗が多すぎる。信用できない。
2. 優先順位
賛成派：ブラウザだけでは生き残れない。新領域への投資は必要。
反対派：Firefoxの改善に集中すべき。AIは他社に任せろ。
3. 資金モデル
賛成派：有料版Firefoxを出してほしい。直接支援したい。
反対派：Googleからの資金に依存している構造が問題。
用語メモ
- Mozilla.ai
- Mozillaが2023年に設立したAI子会社。信頼できるAI開発を目指すとしたが、目立った成果は出ていない。
次に読む：戦争・希少性・敵対的AIの時代とFOSS（オープンソースの未来に関連）
出典
戦争・希少性・敵対的AIの時代とFOSS
Hacker News
158 pts
110 comments
何が起きたか
FOSDEM 2026で予定されている講演の概要が公開されました。テーマは「戦争、資源の希少性、敵対的AIの時代におけるFOSS（フリー・オープンソースソフトウェア）の役割」。90年代のテクノオプティミズムの終焉と、新しい現実への適応を議論します。
要点
- 問題提起：FOSSは「悪意のある利用者は例外」という前提で発展してきた
- 現実：国家主導のサイバー攻撃、AI学習への無断利用が常態化
- 論点：RISC-Vが「国家安全保障上の問題」として議論され始めている
なぜ重要か
オープンソースの根本的な価値観が問われています。「人類への贈り物」として無条件に提供するのか、「悪用されない条件付き」で提供するのか。ライセンスで利用制限をかける動きも出てきており、FOSS界隈で大きな議論になっています。
所感
コメントで指摘されていた「オープンソースに本来、政治的・経済的価値はない。それは作者とユーザーの意図的な選択による」という視点は重要です。技術自体は中立であり、問題は使い方。ただ、その使い方をコントロールする手段がないことが、今の時代の課題なのでしょう。
議論の争点
HNでは以下の点が議論されています。
1. FOSSの哲学
賛成派：無条件の贈り物であるべき。利用制限はFOSSの精神に反する。
反対派：時代が変わった。悪用防止の仕組みが必要。
2. 国家安全保障との関係
賛成派：RISC-Vへの規制は過剰反応。
反対派：中国企業の関与を考えれば当然の議論。
3. AIとの関係
賛成派：AI企業によるスクレイピングは新しい形の搾取。
反対派：オープンに公開したものが使われるのは当然。
用語メモ
- RISC-V
- オープンソースの命令セットアーキテクチャ。ARMやx86と異なり、誰でも自由に実装できる。
- FOSDEM
- ブリュッセルで毎年開催されるヨーロッパ最大のオープンソースカンファレンス。
次に読む：エプスタインファイルを検索するOSSエージェント（AIとオープンデータの活用例）
出典
エプスタインファイルを検索するOSSエージェント
Hacker News
197 pts
89 comments
概要
公開されたジェフリー・エプスタイン関連文書をインデックス化し、AIで検索できるオープンソースツールが公開されました。大量の文書から関連情報を効率的に探し出すことを目的としています。
先に押さえる3点
- 機能：公開文書をインデックス化し、自然言語で質問できる
- 限界：公開されている文書は全体のごく一部。完全な情報は得られない
- 懸念：LLMのハルシネーション（幻覚）による誤情報のリスク
影響
OSINT（オープンソースインテリジェンス）分野でのLLM活用は、大量の文書を扱う調査に有効です。ただし、AIの出力を鵜呑みにせず、必ず原典を確認する習慣が重要です。特にセンシティブな情報を扱う場合、ハルシネーションが風評被害につながるリスクがあります。
実務メモ
「会話の共有機能がほしい」「アーカイブ可能にしてほしい」といった機能要望が出ています。調査報道や研究での活用を想定すると、トレーサビリティ（追跡可能性）の確保が課題になりそうです。
用語メモ
- OSINT
- オープンソースインテリジェンス。公開情報を収集・分析して情報を得る手法。
- ハルシネーション
- LLMが事実に基づかない情報を生成する現象。調査報道での利用には注意が必要。
次に読む：vLLM大規模サービング（LLMインフラの話題）
出典
vLLM大規模サービング：DeepSeekで2.2k tok/s達成
Hacker News
142 pts
47 comments
ざっくり言うと
LLM推論エンジン「vLLM」のチームが、大規模サービングの最適化結果を公開しました。16台のH200でDeepSeekモデルを動かし、1GPU あたり2,200トークン/秒を達成。従来比40%以上の性能向上です。
ポイントは3つ
- 構成：16xH200、wide-EP（拡張パイプライン並列）を使用
- コスト試算：システム価格約75万ドルで、年間6,300万トークン生成可能。1Mトークンあたり約12ドル相当
- 意義：推論コストの継続的な低下を示す実証データ
どこに効く？
LLMを大規模に運用している企業にとって、推論コストは最大の課題の一つです。この結果は「同じ予算でより多くのリクエストを処理できる」ことを意味します。特にDeepSeekのような大規模モデルを商用運用している場合、vLLMへの移行を検討する価値があります。
一言
「Cerebrasハードウェアでの2k tok/sを想定していたのに、H200で達成とは」というコメントが印象的でした。汎用GPUでの最適化がここまで進んでいることは、専用ハードウェアへの投資判断にも影響しそうです。
用語メモ
- vLLM
- 高速なLLM推論を実現するオープンソースエンジン。PagedAttentionによるメモリ効率化が特徴。
- wide-EP
- 拡張パイプライン並列。複数GPUにモデルを分散させる手法の一つ。
次に読む：独自のバックグラウンドエージェントを作った理由（LLM活用の実例）
出典
独自のバックグラウンドエージェントを作った理由
Hacker News
117 pts
23 comments
まず結論
企業向け経費管理サービス「Ramp」のエンジニアリングチームが、自社開発のバックグラウンドAIエージェントについて解説しています。既存のDevinやClaude Codeではなく、自前で作った理由と設計思想を公開。
変わった点
- サンドボックス：Modalを使った隔離環境でコードを実行
- モデル非依存：特定のAI企業に縛られない設計
- 統合：社内の開発環境・ワークフローとの深い連携
注意点
「AI懐疑派だったがこのツールは本当に良い」という社内エンジニアのコメントがありました。ただし、これは社内の開発環境に最適化されているからこそ。汎用ツールとしての評価とは別です。
使うならこうする
自社でAIエージェントを開発する場合、この記事のアーキテクチャは参考になります。特にModalを使ったサンドボックス環境の設計は、セキュリティと柔軟性のバランスが取れています。Devinを検討しているチームも、比較対象として読んでおく価値があります。
用語メモ
- Modal
- サーバーレスでコンテナを実行できるプラットフォーム。AI/MLワークロードに特化。
- Devin
- Cognition社が開発したAIソフトウェアエンジニア。自律的にコードを書く。
次に読む：Claude Coworkがファイルを外部送信（AIエージェントのセキュリティ）
出典
Claude Coworkがファイルを外部送信
Hacker News
85 pts
39 comments
何が起きたか
セキュリティ企業のPromptArmorが、AnthropicのClaude Cowork（デスクトップ向けAIエージェント）の脆弱性を公開しました。悪意のあるファイルを読み込ませることで、ローカルファイルを外部に送信させることが可能です。
要点
- 攻撃手法：.docxファイルに隠れたプロンプトインジェクションを埋め込む
- 影響：サンドボックスやVMを回避してファイルを外部送信
- 対策：現時点では「信頼できないファイルを読み込まない」しかない
なぜ重要か
プロンプトインジェクションは「AIエージェント時代のSQLインジェクション」と呼ばれています。Claude Coworkは発売から2日でこの脆弱性が発見されました。AIエージェントのセキュリティは、まだ発展途上の領域です。
所感
「AIエージェントの'S'はSecurityの'S'」というコメントが皮肉として秀逸でした（AIエージェントにSはない）。PromptArmorの継続的な脆弱性報告は、業界全体のセキュリティ向上に貢献しています。ユーザーとしては、AIエージェントに渡すファイルの出所に注意することが当面の防御策になります。
用語メモ
- プロンプトインジェクション
- LLMに悪意のある指示を紛れ込ませる攻撃手法。AIセキュリティの最重要課題の一つ。
- Claude Cowork
- AnthropicのデスクトップAIエージェント。コード以外の業務にもClaude Codeの能力を拡張。
次に読む：デルタ航空のチェスボットは容赦なく倒してくる（AIの意図しない挙動つながり）
出典
デルタ航空のチェスボットは容赦なく倒してくる
Hacker News
338 pts
335 comments
概要
デルタ航空の座席モニターに搭載されているチェスゲームが、「イージーモード」でもELO 2500相当（グランドマスター級）の強さで、乗客を容赦なく叩きのめすという話題が再燃しています。
先に押さえる3点
- 原因推測：チェスエンジンに「X秒間考える」という設定をしていたのでは。ハードウェアが高速化して思考時間内の探索量が増えた
- バグ：アンパッサンで取った駒が消えない表示バグも発見されている
- 現状：最近のフライトではチェスボット自体が削除されているとの報告も
影響
この話は「AIの強さ設定」の難しさを示しています。計算時間ベースの難易度設定は、ハードウェアの進化で破綻する可能性がある。探索深度や評価関数の重み付けなど、ハードウェア非依存の方法で難易度を制御すべきという教訓です。
実務メモ
ゲームAIに限らず、「想定外のハードウェアで動作した時にどうなるか」は常に考慮すべき設計課題です。特に長期間メンテナンスされるシステムでは、計算リソースの変化を前提とした設計が重要になります。
用語メモ
- ELO
- チェスの強さを示すレーティングシステム。2500はグランドマスター級、一般プレイヤーは1200-1400程度。
- アンパッサン
- チェスの特殊ルール。2マス進んだ相手のポーンを横から取れる。
次に読む：NVIDIAの新モデルOrchestrator-8B（Redditセクションへ）
出典
NVIDIAの新モデルOrchestrator-8B
Reddit r/LocalLLaMA
ざっくり言うと
NVIDIAが8Bパラメータの特化型モデル「Orchestrator-8B」を発表しました。このモデルは自分で全てを回答するのではなく、複雑なタスクをWeb検索、コード実行、他のLLMなど適切なツールに振り分ける「司令塔」として設計されています。
ポイントは3つ
- 設計思想：万能モデルではなく、タスクルーティングに特化した小型モデル
- 効率：8Bパラメータと軽量で、ローカル実行も現実的
- 連携：複数のAIツールを組み合わせるエージェントシステムの中核として機能
どこに効く？
AIエージェントを構築する際、全てを一つの大規模モデルに任せるのではなく、小型の振り分けモデル＋専門ツールという構成が有効な場面があります。コスト効率とレイテンシの両面でメリットがあるアプローチです。
一言
「全部自分でやる」巨大モデルから「適材適所で振り分ける」小型モデルへ。エージェントアーキテクチャの方向性として興味深い動きです。
用語メモ
- オーケストレーター
- 複数のサービスやツールを統合・調整する役割を持つコンポーネント。
次に読む：Soprano 1.1-80M：ハルシネーション95%削減（小型モデルつながり）
出典
Soprano 1.1-80M：ハルシネーション95%削減
Reddit r/LocalLLaMA
まず結論
80Mパラメータの超小型モデル「Soprano 1.1-80M」がリリースされました。前バージョンと比較して、ハルシネーション（幻覚）を95%削減し、ユーザー選好率で63%の支持を獲得したとのこと。
変わった点
- 信頼性向上：ハルシネーション発生率が大幅に低下
- サイズ維持：80Mパラメータのまま性能改善を達成
- ユーザー評価：A/Bテストで前バージョンより63%の支持
注意点
80Mという極めて小さなモデルサイズなので、複雑なタスクには不向き。特定の用途（短文生成、分類など）に特化した使い方が想定されています。
使うならこうする
エッジデバイスやリソース制約のある環境での軽量推論に適しています。スマートフォンや組み込み機器でのオンデバイスAI活用を検討している場合はチェックする価値があります。
用語メモ
- 80Mパラメータ
- 約8000万個のパラメータ。GPT-4の1兆以上と比較すると極めて小型。スマホでも動作可能なサイズ。
次に読む：Geminiが写真・メールをスキャンして回答精度向上（AI機能拡張つながり）
出典
Geminiが写真・メールをスキャンして回答精度向上
Reddit r/artificial
何が起きたか
Googleが、Geminiに新機能を追加しました。ユーザーの写真やメールをスキャンし、より文脈に沿った回答を生成できるようになります。有料ユーザー限定で、デフォルトではオフの設定です。
要点
- 対象：Google One AI Premium加入者（有料プラン）のみ
- オプトイン：デフォルトOFF、ユーザーが明示的に有効化する必要あり
- 範囲：Googleフォト、Gmail、Googleドライブのコンテンツにアクセス可能
なぜ重要か
パーソナルデータへのAIアクセスは、利便性とプライバシーのトレードオフです。「自分の過去のメールを元に回答を生成」は便利ですが、どこまでデータを渡すかは慎重に判断すべき領域です。
所感
デフォルトOFFという設計は適切です。ただ、一度ONにすると「便利すぎて戻れなくなる」可能性も。Googleエコシステムへの依存度が上がる設計であることは認識しておく必要があります。
用語メモ
- Google One AI Premium
- Googleの有料サブスクリプション。Gemini Advancedやクラウドストレージ2TBなどが含まれる。
次に読む：Grok AIディープフェイク被害の訴訟法案が可決（AI規制つながり）
出典
Grok AIディープフェイク被害の訴訟法案が可決
Reddit r/artificial
概要
米上院が、AI生成のディープフェイク画像による被害者が訴訟を起こせるようにする法案を可決しました。特にGrok AIによる性的画像生成が問題視されています。
先に押さえる3点
- 対象：AIで生成された「intimate images（性的画像）」の被害者
- 権利：民事訴訟で損害賠償を請求できるようになる
- 背景：xAI社のGrokが「ガードレールなし」で画像生成できると批判されていた
影響
AI画像生成サービスに対する法的責任が明確化される方向です。サービス提供者は、不正利用防止策の強化を迫られることになります。特に「ガードレールを設けない」ことを売りにしていたサービスは、ビジネスモデルの見直しが必要になる可能性があります。
実務メモ
AI画像生成サービスを業務で利用している場合、利用規約の変更や機能制限に注意が必要です。法案の下院通過と大統領署名が残っていますが、方向性としては規制強化が進むと見られます。
用語メモ
- ディープフェイク
- AIを使って人物の顔や声を合成・改変した偽のメディア。悪用による被害が社会問題化。
次に読む：OpenAI Codex 5.2 vs Claude Code（AI比較つながり）
出典
OpenAI Codex 5.2 vs Claude Code
Reddit r/ClaudeAI
ざっくり言うと
r/ClaudeAIで「OpenAI Codex 5.2がClaude Codeより良くなったのでは？」という議論が発生。コーディング支援ツールの競争が激化する中、ユーザーの評価が分かれています。
ポイントは3つ
- 投稿者の主張：Codex 5.2が最近のアップデートで大幅に改善された
- 反論：タスクによる。長いコンテキストや複雑なリファクタリングはまだClaudeが強い
- 現実：両方を使い分けるユーザーが多い
どこに効く？
コーディング支援ツールの選択は「どちらが絶対的に良い」という話ではなく、プロジェクトの性質やワークフローとの相性で決まります。複数のツールを併用して、得意分野で使い分けるのが現時点での最適解かもしれません。
一言
競争があるからこそ、両社とも急速に改善を続けています。ユーザーとしては選択肢が増えてありがたい状況。ただ、毎月のように「こっちが良くなった」「いやこっちだ」という議論が起きるので、追いかけるのも大変ですね。
用語メモ
- Claude Code
- AnthropicのCLIベースのコーディング支援ツール。長いコンテキストと複雑なタスクに強い。
- OpenAI Codex
- OpenAIのコード生成・補完モデル。GitHub Copilotの基盤技術として知られる。
次に読む：AIスクレイパーのせいで良いものが作れない（本日のトップ記事へ）
出典
