AI Daily Digest

Claude Codeの品質劣化を毎日追跡するベンチマークTier1

何が起きたか

MarginLabが、Claude Codeの性能を毎日計測するベンチマークサービスを公開しました。SWE-bench系の50タスクを日次で実行し、各タスクをベルヌーイ変数としてモデル化したうえで95%信頼区間を算出しています。昨日紹介したKarpathy氏のClaude利用メモでもエージェントの安定性が話題でしたが、その品質を定量的に追う試みです。

要点

• Anthropic公式（Thariq氏）がHNコメントで1/26のハーネスバグを認め、1/28に修正したと回答
• SWE-bench共著者からは「50タスク・1日1回では統計的に不十分」「300タスク×5-10回/日を推奨」との指摘
• ユーザーの不満度（プロンプト内のswear words出現率など）で品質劣化を測る別アプローチも提案されている

なぜ重要か

LLMの性能が「いつの間にか下がっていた」という報告は後を絶ちません。ベンダーは否定し、ユーザーは体感で訴える。その間を埋める独立計測の仕組みは、業界全体にとって価値があります。50タスクでは足りないという批判はもっともですが、「まず始めた」こと自体に意味があるでしょう。

議論の争点

所感

「壊れているかもしれない」と言い続けるのと、データで示すのでは、説得力が全く違います。Anthropicが即座に反応したこと自体が、この種の監視の有効性を証明しています。

用語メモ

SWE-bench

ソフトウェアエンジニアリング能力を測定するベンチマーク。実際のGitHubイシューの解決を題材にする。

ベルヌーイ変数

成功（1）か失敗（0）の2値をとる確率変数。タスクの成否をモデル化する際に使う。

英政府「AIスキルハブ」、PwCに8億円で発注した結末Tier1

概要

UK政府が2030年までに1000万人にAIスキルを教える計画の一環として、PwCに4.1百万ポンド（約8億円）で発注したAIスキルハブ。できあがったのは、外部リンクを寄せ集めたWebサイトでした。UX上の問題点も多く、アクセシビリティ基準を満たしておらず、「fair use」（米国法の概念）をUKの法律として記載するという基本的な誤りまで含まれています。

先に押さえる3点

• 予算の大半は管理費に消え、成果物としてのWebサイトは技術的にも内容的にも低品質
• UKの著作権法は「fair dealing」であって「fair use」ではない。法律の基本を間違えている
• HNではUK内のWeb開発会社なら「予算の1/10で作れた」という声が多数

影響

大手コンサルへの政府発注に対する不信感は、英国に限った話ではありません。技術的な品質を評価できない発注者と、管理プロセスで利益を上げるコンサルの構造的な問題です。AI分野では特に、「何が良い成果物か」の判断基準がまだ確立されていないため、この手の失敗が起きやすい状況にあります。

議論の争点

実務メモ

発注側に立つ場合、技術的な品質基準を事前に定義しておくことが重要です。「Webサイトを作る」では曖昧すぎて、リンク集でも契約上は「完了」になります。

用語メモ

fair dealing

英国・カナダ等の著作権法における権利制限の概念。米国の「fair use」とは適用範囲が異なる。

アクセシビリティ基準

WCAG（Web Content Accessibility Guidelines）に基づく、障害のある利用者にも使いやすいWebサイトの設計基準。

米サイバーセキュリティ高官がChatGPTに機密ファイルを流した話Tier1

ざっくり言うと

米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）の長官代行が、「公式使用限定」の契約書類を公開版ChatGPTにアップロードしていたことが発覚しました。DHS内部の監視ツールが検知し、通報に至っています。

ポイントは3つ

• DHSには承認済みのAIツール（DHSChat）が存在するのに、公開版ChatGPTを使用
• 本人は「許可を得た短期限定的な使用」と主張しているが、詳細は不明
• サイバーセキュリティの最高責任者がこの判断をしたという事実自体が、組織のセキュリティ文化の問題を示唆

どこに効く？

政府機関の話ですが、企業のセキュリティ担当者にとっても他人事ではありません。ITAR/EAR規制下の組織では、ChatGPT等の外部AIツールを全面ブロックしているところもあります。しかし、ブロックしていない組織の方が多いのが現実です。GovCloud LLMが存在するのに公開版を使ってしまう「便利さの誘惑」は、どの組織にも共通する課題でしょう。

議論の争点

一言

カーナビが「右折」と言ったら川に突っ込む人はさすがにいません。でも、「ChatGPTにアップロードして」と思ったら手が動いてしまう――その手軽さがリスクの本質です。

用語メモ

CISA

Cybersecurity and Infrastructure Security Agency。米国土安全保障省傘下のサイバーセキュリティ専門機関。

DHSChat

米国土安全保障省が承認した内部向けAIチャットツール。GovCloud上で動作し、データが外部に出ない。

テック市場は壊れている――AIはスケープゴートにすぎない注目

まず結論

テック業界の不調をAIのせいにする風潮は、問題の本質を見誤っています。2010-2020年のZIRP（ゼロ金利政策）時代に「成長＝株価」だったため各社が過剰採用し、COVID後に利益重視へ転換して大量解雇が起きた。AIは原因ではなく、解雇を正当化するためのプレースホルダーとして使われているに過ぎない、という分析です。

変わった点

• 「AI時代だから人を減らす」という説明が企業にとって便利すぎる構図が明確になった
• テック企業の「2層構造」（コア収益チーム vs 使い捨て実験チーム）の定着を指摘
• ソフトウェアのR&D的性質（成果物が永続する）が、製造業とは異なるダイナミクスを生んでいる

注意点

「AIは関係ない」という結論を急いではいけません。現時点では口実として使われている側面が大きいとしても、AIによる実質的な業務代替が進む可能性は排除できません。HNのコメント欄でも「今はスケープゴートだが、2-3年後は本当に影響が出る」という見方が目立ちました。

議論の争点

使うならこうする

転職活動中の方は、「AI枠を増やすために採用している」というポジションと、「AIを口実に削減している」ポジションを見分ける目が重要になります。面接で「AI戦略」を聞いてみるのは一つの判断材料です。

用語メモ

ZIRP

Zero Interest Rate Policy（ゼロ金利政策）。2010-2020年代前半の低金利環境がテック企業の過剰投資を生んだとされる。

MozillaのオープンAI同盟構想――14億ドルの使い道注目

何が起きたか

Mozillaが約14億ドルの準備金を活用し、安全性とガバナンスを重視するAIスタートアップに投資する「rebel alliance」の構築を進めています。1月15日にも取り上げたMozillaのオープンソースAI戦略の延長線上にある動きですが、その規模感はかなり具体的になってきました。

要点

• OpenAIやAnthropicに対抗する「オープンAI陣営」を組織化する構想
• 分散型トレーニング（BOINC等）への期待もコミュニティから寄せられている
• HNでは「Firefoxを直してくれ」が根強い意見。ブラウザ戦争はまだ終わっていない

なぜ重要か

オープンなAI開発を推進するプレイヤーが増えること自体は歓迎すべきでしょう。ただし、Mozillaの場合は資金源の大半がGoogleからの検索デフォルト契約に依存しているという構造的な矛盾があります。「帝国の資金で反乱同盟を作る」というHNコメントは的を射ています。

議論の争点

所感

Mozillaの過去を見ると、Mozilla.aiやPocket買収など、本業以外の取り組みが成功した例は多くありません。今回の構想が単なる看板で終わるのか、実質的な対抗勢力になるのかは、最初の投資先が見えてから判断しても遅くないでしょう。

用語メモ

Mozilla Foundation

Mozillaの非営利組織。Firefoxの開発元であるMozilla Corporationの親組織にあたる。

Trinity Large：米国発オープンソース400B MoEモデル

概要

Arcee AIが400Bパラメータ（アクティブは13B）のスパースMoEモデルをApache 2.0ライセンスで公開しました。NVIDIA B300を2048台使い、33日間で17兆トークンを学習。開発費は給与含めて約2000万ドルとのことです。QwenやDeepSeekに迫るベンチマークスコアを記録しています。

先に押さえる3点

• Muonオプティマイザを採用し、学習中のロススパイクがゼロ。安定した学習を実現
• アクティブパラメータが13Bなので、推論時のコストは400Bモデルとしては低め
• Apache 2.0ライセンスのため、商用利用が可能。米国発という点も注目される

影響

オープンソースの大規模モデルは、これまでQwen（中国）やDeepSeek（中国）が先行していました。米国企業からこの規模のオープンモデルが出たことは、オープンAIエコシステムの多様化として歓迎されるでしょう。ただし、2000万ドルという開発費は決して安くなく、持続性は未知数です。

実務メモ

試してみたい場合、アクティブ13Bなので推論だけなら比較的手軽に回せます。ファインチューニングを考えるなら、LoRA等のパラメータ効率化手法との組み合わせが現実的でしょう。

用語メモ

スパースMoE

Mixture of Experts（混合エキスパート）のスパース版。入力ごとに一部のエキスパートだけを活性化し、計算効率を高める手法。

Muonオプティマイザ

大規模モデル学習向けに設計されたオプティマイザ。学習の安定性を高め、ロススパイク（損失の急増）を防ぐ。

Sherlock：LLMツールの通信を丸見えにするMitMプロキシ

ざっくり言うと

Claude CodeやCodex等のLLM CLIツールが裏側でどれだけのトークンを消費しているか、リアルタイムで可視化するPythonツールです。ローカルHTTPプロキシとして動作し、APIトラフィックを傍受します。コンテキストウィンドウの消費状況を「燃料ゲージ」として表示する機能が特徴的です。

ポイントは3つ

• リクエストはMarkdown/JSONで自動保存され、あとから解析可能
• トークン使用量の可視化により、コスト管理がしやすくなる
• Claude Code、Codex等の主要LLM CLIツールに対応

どこに効く？

LLMツールのコスト管理は、個人開発者にもチームにも切実な問題です。「気づいたら月末の請求がとんでもないことに」という経験がある方は少なくないはず。Karpathy氏が指摘していたように、エージェント型ツールはループ処理でトークンを大量消費することがあり、手元で状況を把握できるのは実用的です。

一言

名前の通り、LLMツールの動作を「探偵」するツールです。デバッグ目的でも使えるので、エージェントが何をしているか分からないときに重宝しそうです。

用語メモ

MitMプロキシ

Man-in-the-Middle（中間者）プロキシ。通信を中継し、内容を傍受・記録できる。デバッグやセキュリティテストに使われる。

コンテキストウィンドウ

LLMが一度に処理できる入出力の最大長。トークン数で表される。超過すると古い情報が切り捨てられる。

JellyfinのLLM/AI開発ポリシーが問いかけるもの

まず結論

OSSメディアサーバーのJellyfinが、LLM使用に関する明確なポリシーを策定しました。コミュニケーション（Issue、PR、ディスカッション）へのLLM出力の直接貼り付けは禁止。コードはLLMで生成してよいが、理解・テスト・レビュー対応は全て人間の責任。GhosttyのAIポリシーに続き、OSSプロジェクトでAIルールを明文化する流れが広がっています。

変わった点

• 最近の大型アップデート後にバグが多発し、LLM生成PRが大量に寄せられたことが直接の契機
• 「コードを書く」のと「コードに責任を持つ」のは別問題という線引きを明確にした
• コミュニティとのコミュニケーションにLLMを使うことを明示的に禁止した点が特徴的

注意点

このポリシーは「LLM禁止」ではありません。コード生成は許可しつつ、品質の責任は人間が持つという方針です。問題はむしろ、LLM生成コードの品質が低い場合に、レビュアーの負担が増えるという現実です。PRの量が増えても質が伴わなければ、メンテナーが疲弊するだけです。

使うならこうする

OSSにコントリビュートする際は、そのプロジェクトのAIポリシーを事前に確認する習慣が必要になりつつあります。ポリシーが明文化されていないプロジェクトでも、「LLMで生成しました」と正直に書くより、コードの中身で勝負する方が受け入れられやすいのは間違いありません。

用語メモ

Jellyfin

オープンソースのメディアサーバー。Embyのフォークとして誕生し、完全無料で利用できる。

OTelBench：AIエージェントはSREタスクで苦戦する

何が起きたか

Quesma社がOpenTelemetry計装タスクでLLMの実力を測るベンチマーク「OTelBench」を公開しました。最高スコアはClaude Opus 4.5の29%。SWE-benchでは80.9%を記録するモデルが、SRE領域ではここまで苦戦するという結果が出ています。

要点

• コンテキスト伝搬（分散トレーシングの核心部分）が最大のボトルネック
• Go/C++では一部成功したが、Rust/Swift/Ruby/Javaは全滅
• SWE-benchとの乖離は、ドメイン特化の知識が不足していることを示唆

なぜ重要か

「AIエージェントがソフトウェア開発を自動化する」という期待は高まる一方ですが、SRE/可観測性のような専門領域では依然として壁があります。記事1のClaude Codeベンチマークと併せて読むと、汎用ベンチマークとドメイン特化ベンチマークの差が浮き彫りになります。

所感

29%という数字は厳しいですが、逆に言えば改善の余地が大きい領域です。OpenTelemetryの計装は定型的な部分も多いので、専用のファインチューニングやRAGで改善できる可能性はあるでしょう。

用語メモ

OpenTelemetry

テレメトリーデータ（トレース、メトリクス、ログ）の収集を標準化するオープンソースフレームワーク。CNCFプロジェクト。

コンテキスト伝搬

分散システムにおいて、リクエストのトレースIDなどを各サービス間で引き継ぐ仕組み。可観測性の基盤となる技術。

AIが架空の温泉を案内――豪旅行サイトの教訓

概要

オーストラリアのニューサウスウェールズ州で、旅行会社のWebサイトAIが「ウェルドバラ温泉」という存在しない施設を案内してしまいました。運営元のオーナーは「AIが完全にミスした」と認めています。カーナビが川に突入させる問題のAI版、と言えばイメージしやすいかもしれません。

先に押さえる3点

• 旅行会社（Australian Tours and Cruises / Tasmania Tours運営）のサイトに設置されたAIチャットが問題の発端
• 存在しない施設を具体的な詳細付きで案内しており、典型的なハルシネーション
• 旅行会社の広告として見ると「虚偽広告」にあたる可能性が指摘されている

影響

AIをカスタマー対応に使う企業は増えていますが、ハルシネーションのリスクは消えていません。特に旅行・医療・金融のように、誤情報が直接的な損害につながる領域では、AIの回答に対する検証の仕組みが不可欠です。「AIが言ったことは会社の公式見解か」という法的な整理も、まだ追いついていない状況です。

実務メモ

AIチャットボットを顧客向けに導入する場合、回答範囲を自社データに限定するRAG構成が最低限必要です。それでもハルシネーションは完全には防げないので、「AIの回答は参考情報であり、正確性は保証しません」という免責表示は入れておくべきでしょう。

用語メモ

ハルシネーション

LLMが事実と異なる情報をもっともらしく生成する現象。幻覚（hallucination）に由来する。