Tech News JP

Claude Codeの2つのキャッシュバグ、APIコストを最大20倍に膨張させる恐れ AnthropicのAIコーディングアシスタント「Claude Code」に、プロンプトキャッシュを無効化し、APIコストを静かに10〜20倍に膨らませる可能性のある2つの独立したバグが報告された。Redditユーザーがスタンドアロンバイナリをリバースエンジニアリングした結果、発見したものだ。 バグ1：スタンドアロンバイナリのセンチネル置換によるキャッシュ破壊 Claude Codeのスタンドアロンバイナリ（claude.ai/install.sh や npm install -g で取得するもの）には、AnthropicがカスタマイズしたBunフォークにネイティブ層の文字列置換処理が組み込まれている。この処理は、ZigのHTTPヘッダービルダー関数に注入されており、APIリクエストのJSONボディ内に含まれる課金帰属センチネル（cch=a9ffd）を特定し、ボディのハッシュ値から導出した5文字の16進数で置換する。 問題となるのは、この置換がJSONボディ内の最初の出現箇所を対象とする点だ。シリアライズされたJSONでは messages[] が system[] より先に来るため、会話履歴にセンチネル文字列が含まれている場合（例：Claude Codeのソースコードについて話し合っている、CLAUDE.md にセンチネルが含まれているなど）、system[0] ではなく messages[] 内のセンチネルが置換されてしまう。これによりリクエストごとにメッセージの内容が変化し、キャッシュのプレフィックスが壊れ、毎回フルキャッシュの再構築が発生する。コンテキストサイズに応じて、1リクエストあたり約0.04〜0.15ドルの追加コストが生じる計算だ。 回避策： スタンドアロンバイナリの代わりに npx @anthropic-ai/claude-code で実行することで問題を回避できる。置換処理はカスタムBunフォークにのみ存在し、標準的なNode/Bun上で動くnpmパッケージには含まれていないことが実験的に確認されている。 バグ2：--resume オプションが常にキャッシュミスを引き起こす（v2.1.69以降） もう1つのバグは、セッション再開を行う --resume オプションに関するものだ。v2.1.69で導入された deferred_tools_delta（ToolSearch経由で利用可能なツールを列挙するシステムリマインダー）の実装の違いにより、再開時に毎回会話履歴全体のキャッシュミスが発生する。 新規セッションでは約13KBのリマインダー群が messages[0] に注入されるのに対し、再開時には messages[0] に約352Bのコンテキストのみが含まれ、リマインダー群は末尾（messages[N]）に追加される。この構造の違いにより、キャッシュプレフィックスの不一致、課金ハッシュの変化、cache_control ブレークポイントの位置ズレという3つの独立した要因でキャッシュが破壊される。再開後の2ターン目以降は正常にキャッシュが機能するため、被害は最初のリクエストに限られるが、コンテキストが大きい場合のコストインパクトは無視できない。 このバグはv2.1.68には存在せず、deferred_tools_delta の導入と同時に発生した。現時点で外部から適用できる回避策はない。 日本のユーザーへの影響 Claude Codeは日本でも多くの開発者が利用しており、特にAPIコスト管理を重視するチームや個人開発者にとって見過ごせない問題だ。Anthropicの公式対応を待ちながら、スタンドアロンバイナリを使用している場合は npx 経由への切り替えを検討したい。--resume については正式な修正リリースを待つしかない状況だが、バグ報告のIssue（#40524、#34629）は既に公開されており、Anthropic側も認識していると見られる。 元記事: Claude Code bug can silently 10-20x API costs

Claude Codeで利用制限の枯渇が急増——Anthropicが調査中と公表 AnthropicのAIコーディングアシスタント「Claude Code」において、トークン消費が異常に速く使用量上限（クォータ）に到達してしまうという問題が多発しており、開発者から大きな不満の声が上がっている。 Anthropicはこの問題を公式に認め、「Claude Codeの利用制限に想定より遥かに速く到達するケースが報告されている。現在チームのトッププライオリティとして調査中だ」と声明を発表した。 「30日中12日しか使えない」——ユーザーから怒りの声 Discordの公式フォーラムでは、年間200ドル（約3万円）のClaude Proプランを契約するあるユーザーが「毎週月曜日には上限に達し、土曜日にリセットされるの繰り返し。1ヶ月30日のうち12日しかまともに使えていない」と訴えている。 RedditのAnthropicフォーラムにも批判が集中しており、「Max 5プラン（月額100ドル）を1時間で使い果たした。以前は8時間使えていたのに」といった報告が相次ぐ。 問題の原因として浮上する3つの要因 今回の問題には複数の要因が重なっている可能性がある。 1. ピーク時間帯のクォータ削減 先週、Anthropicはピークタイムにおけるクォータを削減すると発表した。エンジニアのThariq Shihipar氏によれば、約7%のユーザーに影響するという。 2. 倍増プロモーションの終了 3月28日をもって、ピーク外の6時間帯に利用制限を2倍にするプロモーションが終了。これにより体感上の使用量が大幅に低下したとみられる。 3. プロンプトキャッシュのバグ Claude Codeのバイナリをリバースエンジニアリングしたユーザーが「プロンプトキャッシュを無効化する独立した2つのバグを発見した。これによりコストが10〜20倍に膨れ上がっている」と主張している。旧バージョン（2.1.34）へのダウングレードで改善したという報告も複数寄せられており、バグの存在を裏付けている。 プロンプトキャッシュの仕様も落とし穴に Claude Codeのプロンプトキャッシュは、繰り返し処理や共通要素を含むプロンプトの処理コストを大幅に削減できる機能だ。しかしキャッシュの有効期限はデフォルトでわずか5分。少し作業を中断しただけでキャッシュが無効になり、再開時にコストが跳ね上がる。 1時間のキャッシュ延長オプションも存在するが、その場合「キャッシュ書き込みトークンは通常の入力トークンの2倍」の料金がかかる。読み込みは0.1倍と安いため、使い方によってコスト最適化の余地が大きく異なる。 自動ワークフローへの深刻な影響 特に問題視されているのは、自動化パイプラインへの影響だ。あるユーザーはこう警告する。「Claude Codeを自動ワークフローで使っているなら、レート制限エラーを明示的にキャッチする必要がある。一般的なエラーに見えるため、気づかずにリトライし続け、ループ1セッションで日次予算を数分で使い果たすことになる」。 なお、AnthropicはProプランの利用量について「無料プランの5倍以上」、Standard Teamプランは「Proの1.25倍」という曖昧な表記にとどめており、開発者が実際の上限を把握しにくい状況も批判を招いている。 業界全体の課題：AIツールの価格モデルへの不満 こうした問題はAnthropicだけではない。今月初めにはGoogle Antigravityのユーザーからも同様の不満が報告されている。AI開発ツールの「使い倒したいユーザー」と「収益を確保したいプロバイダー」の間の暗黙の交渉が続いている状況だ。 AIを全プロセスに組み込むよう促すベンダーのマーケティングと、実際には突然応答が止まることもあるクォータ制限との間の矛盾——この課題は、AIコーディングツールが本格的に業務インフラ化するうえで、避けては通れない問題となりつつある。 元記事: Claude Code users hitting usage limits ‘way faster than expected’

MicrosoftがWSLを2026年に大幅強化——開発者向け環境の本気アップデート Microsoftは2026年、Windows Subsystem for Linux（WSL）に大規模な改善を加えることを明らかにした。LinuxとWindows間のファイル転送高速化、ネットワーク性能の強化、初期セットアップの簡略化、そしてエンタープライズ向けのセキュリティ・ポリシー管理機能の充実が予定されている。 なぜ今WSLの強化なのか WSLは、Windowsの中でLinuxディストリビューションをネイティブに近い形で実行できる仕組みだ。デュアルブートや仮想マシンが不要で、軽量な仮想化レイヤーを通じてLinux環境を利用できる。WSL2では実際のLinuxカーネルが動作しており、bash・ssh・git・Docker・Node.js・Pythonといった開発ツールをそのまま使えるのが強みだ。 Webアプリ開発者がローカルサーバーを立ち上げたり、DevOpsエンジニアがコンテナやオーケストレーションツールを扱ったりと、WSLは現代の開発ワークフローに深く組み込まれている。Docker Desktop for WindowsもWSL2に強く依存しており、Visual Studio CodeもWSL環境への直接接続をサポートしている。 一方で、macOSはUnixベースの環境をデフォルトで持ち、ネイティブLinux環境はそのまま使える。Windowsが開発者のシェアを争うにあたって、WSLの品質向上は不可欠な施策だ。 具体的な改善ポイント ファイルアクセスの高速化は最大の目玉だ。現状のWSLでは、Windowsファイルシステム（/mnt/c/ 以下のパス）へのアクセスが遅く、大量ファイルを扱うビルドや依存パッケージのインストールでボトルネックになることがある。この課題に直接メスを入れる。 ネットワーク性能の強化も開発者には嬉しい変更だ。WSL内からのHTTP通信やコンテナ間ネットワーキングの安定性・速度が改善されることで、バックエンド開発やマイクロサービス構成を組む際の体験が向上する。 セットアップの簡略化により、新しいWindowsマシンにWSLを導入するまでのハードルが下がる。企業導入においても、ポリシー管理やセキュリティ制御の強化が予定されており、IT管理者が組織全体でWSLを安全に展開しやすくなる。 開発プラットフォームとしてのWindowsの再評価 WSLが登場した背景には、Linuxに精通した開発者をWindowsエコシステムに引き留めるというMicrosoftの戦略があった。初代WSL1は互換性に問題が多かったが、WSL2でLinuxカーネルを直接動かす方式に転換し、実用性が大きく向上した。 2025年のBuildカンファレンスでSatya Nadella CEOがWSLのオープンソース化を発表するなど、Microsoftはこの分野への本気度を示し続けている。 日本でもクラウドネイティブ開発やコンテナ活用が当たり前になる中、開発PCの選定においてWindowsとmacOSの比較は常に議論になる。今回のWSL強化が実際に体感できるレベルで届けば、Windows PCを選ぶ開発者にとって大きな後押しになりそうだ。詳細は2026年中の公式発表を待ちたい。 元記事: Microsoft to upgrade Windows Subsystem for Linux (WSL) with faster file access, better networking and easier setup

Axios npmパッケージが供給チェーン攻撃の標的に JavaScriptアプリケーション開発で広く使われているHTTPクライアントライブラリ「Axios」のnpmパッケージが、2026年3月31日に悪意ある第三者によって侵害された。セキュリティ企業のEndor Labs、Socket、Aikido、StepSecurityの調査によると、攻撃者は悪意のあるバージョンを2つ公開し、Linux・Windows・macOSの全プラットフォームを対象にリモートアクセス型トロイの木馬（RAT）を配布した。 Axiosは月間約4億ダウンロードを誇る人気ライブラリであり、今回の侵害による影響範囲は極めて広い可能性がある。 攻撃の手口 攻撃者はAxiosのメインメンテナーであるJason Saayman氏のnpmアカウントを乗っ取り、悪意のあるバージョンaxios@1.14.1とaxios@0.30.4を公開した。さらにSaayman氏のGitHubアカウントも掌握し、関連メールアドレスをifstap@proton.meに変更。侵害に関する報告スレッドを削除するなど、発覚を遅らせる工作も行った。 注目すべき点として、これら悪意のあるバージョンはOpenID Connect（OIDC）によるパッケージ起源の自動検証が行われておらず、対応するGitHubコミットも存在しなかった。こうした兆候は本来、直ちに警戒を促すべきシグナルである。 感染チェーンの詳細 攻撃者はAxiosのコード自体には手を加えず、package.jsonに悪意のある依存パッケージplain-crypto-js@^4.2.1を追加した。このパッケージはインストール時にポストインストールスクリプトを実行し、難読化されたドロッパー（setup.js）を起動。ドロッパーはC2サーバーへ接続し、検出されたOSに応じたペイロードを取得する。 Windows: VBScriptとPowerShellを組み合わせて非表示のコマンドプロンプトを起動。%PROGRAMDATA%\wt.exeにPowerShellをコピーして検出を回避し、再起動後も持続するよう設計されている macOS: AppleScriptを使って/Library/Caches/com.apple.act.mondにバイナリをダウンロードし、バックグラウンドで実行 Linux: Pythonベースのペイロードを/tmp/ld.pyに保存し、nohupコマンドでバックグラウンド実行 いずれのケースでもRATに感染し、攻撃者によるリモートコマンド実行・シェルコマンドの送受信・ディレクトリ列挙が可能な状態となる。感染完了後、ドロッパーは自身を削除し改ざんされたpackage.jsonをクリーンな状態に戻すことでフォレンジック調査を困難にする。 北朝鮮系APTグループによる計画的攻撃 StepSecurityの調査では、悪意のある依存パッケージが公開の18時間前に事前ステージングされており、今回の攻撃が「計画的」なものであることを示している。 Googleの脅威インテリジェンスグループ（GTIG）のチーフアナリストJohn Hultquist氏はBleepingComputerに対し、本攻撃の背後には北朝鮮系の脅威アクター「UNC1069」がいると語った。このグループはソフトウェアサプライチェーンおよび暗号資産関連の標的を狙うことで知られている。 開発者への推奨対応 Axiosを利用しているプロジェクトは、package-lock.jsonやyarn.lockなどのロックファイルを確認し、axios@1.14.1またはaxios@0.30.4が含まれていないか至急チェックすることが強く推奨される。該当するバージョンをインストールした可能性がある場合は、システムの侵害有無を確認し、最新の安全なバージョンへ即座に更新する必要がある。 今回の事件は、オープンソースのサプライチェーンセキュリティの脆弱性を改めて浮き彫りにした。npmのような大規模パッケージレジストリにおけるアカウント保護とパッケージ検証の重要性が、かつてないほど高まっている。 元記事: Hackers compromise Axios npm package to drop cross-platform malware

Trivy連鎖攻撃がCiscoを直撃——AIプロダクトのソースコードが流出 米Ciscoがサイバー攻撃の被害を受け、内部の開発環境が侵害されたことをBleepingComputerが報じた。攻撃者は2026年3月に発覚したTrivyサプライチェーン攻撃で盗んだ認証情報を転用し、Ciscoのビルド・開発環境への侵入を果たした。 何が起きたのか Ciscoの「Unified Intelligence Center」「CSIRT」「EOC」各チームが侵害を封じ込めたものの、攻撃者はその前に以下を実行したとされる。 300以上のGitHubリポジトリを複製（AI Assistant、AI Defense、未発表プロダクトのソースコードを含む） 複数のAWSキーを窃取し、一部のCisco AWSアカウントで不正操作を実施 数十台のデバイス（開発者ワークステーション・ラボ端末）のデータを取得 さらに、複製されたリポジトリの一部には銀行、BPO（業務プロセスアウトソーシング）、米政府機関など顧客のソースコードが含まれている可能性があるという。 Trivyサプライチェーン攻撃とは Trivyはコンテナイメージや構成ファイルの脆弱性を検出するOSSスキャナーで、開発現場での採用が広い。今月初め、脅威アクターがTrivyのGitHubパイプラインを侵害し、公式リリースおよびGitHub Actionsを通じて認証情報窃取型マルウェアを配布した。 Ciscoはこの不正なGitHub Actionプラグインを踏んでしまい、CI/CD環境の認証情報が流出したとみられる。 背後に「TeamPCP」グループ セキュリティ研究者は今回の一連の攻撃を、TeamPCPと呼ばれる脅威グループに帰属している。同グループは独自のインフォスティーラー「TeamPCP Cloud Stealer」を用いており、GitHub・PyPI・npm・Dockerを標的にしたサプライチェーン攻撃を繰り返している。 Cisco侵害と並行して、LiteLLM（PyPIパッケージ）およびCheckmarx KICSプロジェクトも同じマルウェアで侵害されており、合計で数万台規模のデバイスに影響が及んでいる。 Ciscoの対応 Ciscoは影響を受けたシステムを隔離し、再イメージングを開始。大規模な認証情報のローテーションを実施中だという。ただし、BleepingComputerの取材に対してCiscoからの公式回答はまだ得られていない。 日本のエンジニアへの示唆 Trivyは国内でも広くCI/CDパイプラインに組み込まれているツールだ。今回の攻撃はOSSツールのGitHub Actionsやパイプラインが攻撃経路になり得ることを改めて示した。 利用中のGitHub Actionsのバージョンとハッシュを固定しているか確認する CI/CD環境で使う認証情報（AWS、GitHub Token等）のスコープを最小権限に絞る 依存パッケージの更新時にはリリースノートと変更差分を必ずチェックする サプライチェーン攻撃は「信頼しているツール」を踏み台にする点で被害が広域に及ぶ。OSS利用時のセキュリティ検証プロセスを今一度見直すべき時期だ。 元記事: Cisco source code stolen in Trivy-linked dev environment breach

GitHub CopilotのPR広告問題、Microsoftが「バグだった」と釈明 Microsoftが提供するAIコーディングアシスタント「GitHub Copilot」が、プルリクエスト（PR）のレビュー画面に宣伝的なメッセージを表示し始めたことが判明。これを発見した開発者たちがSNSや各種フォーラムで強い不満を表明し、Microsoftは事態を沈静化するべく即座に対応を迫られた。 何が起きたのか 問題となったのは、CopilotがPRのサマリーや提案欄に、有料プランや追加機能を促すようなプロモーション文言を埋め込んでいたこと。多くの開発者は、コードレビューという業務上の重要なフローに広告が混入することに強い抵抗感を示した。「開発ツールの中でまで広告を見せられるのか」という声がX（旧Twitter）やHacker Newsなどに相次いで投稿された。 開発者コミュニティには、GitHubが企業向けの有料ツールとして長年信頼を培ってきた背景がある。そのため、今回のような「ツールが自分自身を宣伝する」という行為は、ユーザーとの信頼関係を損なうものとして批判が集中した。 Microsoftの説明と対応 Microsoftはこの騒動を受けて公式に声明を発表。「意図的な機能追加ではなく、プログラミングロジックの不具合（programming logic issue）によって意図しない動作が発生した」と説明し、謝罪した。 同社は問題の修正を迅速に展開し、宣伝的なメッセージの表示は停止された。ただし、「バグ」という説明に対しては、開発者コミュニティから懐疑的な見方も出ている。意図せずして広告のような表示が実装されるほど複雑なロジックが組まれているとは考えにくいとの指摘もある。 開発ツールへの広告混入という懸念 今回の件は、AI開発ツールのマネタイズ戦略に関する根本的な議論を呼び起こした。GitHub CopilotはMicrosoftの収益源として重要な位置を占めており、フリープランの制限拡大や有料プランへの誘導は今後も続く可能性がある。 日本国内でもGitHub Copilotの導入企業は増加しており、今回のような「開発フローへの割り込み」はエンジニアの生産性や心理的安全性に影響を与えかねない。今後、同様の問題が再発した場合にMicrosoftがどう対応するかが注目されている。 MicrosoftとGitHubに対する開発者コミュニティの信頼を維持するためには、透明性の高い説明と再発防止策の明示が求められるだろう。 元記事: GitHub Copilot ads in PRs were due to a “programming logic issue”, claims Microsoft

Microsoft、Windows全バージョンから伝統のコマンドラインツールを正式削除 Microsoftは、Windows 11の25H2・24H2・23H2、そしてWindows 10のすべてのサポート対象バージョンとWindowsサーバー製品から、長年にわたり使われてきたコマンドラインツールを正式に削除すると発表した。 廃止の背景 今回の削除は突然の決定ではない。Microsoftは2021年のWindows 10 バージョン21H1の時点で、当該ツールを「非推奨（deprecated）」として公式にアナウンスしていた。それから数年の移行期間を経て、今回ついに全バージョンからの正式削除という最終段階に踏み切った形だ。 非推奨から正式削除までのこうした段階的アプローチは、Microsoftが近年採用する標準的な廃止プロセスであり、企業や開発者に十分な移行時間を確保する目的がある。 影響範囲と代替手段 影響を受けるのはWindows 11の現行サポートバージョン（23H2・24H2・25H2）に加え、Windows 10、さらにWindowsサーバー製品群と広範にわたる。 Microsoftは代替手段として、PowerShellおよびWindows Management Instrumentation（WMI）をPowerShell経由で利用することを推奨している。PowerShellはWMIクラスへのアクセスを Get-WmiObject や Get-CimInstance コマンドレットで提供しており、従来のコマンドラインと同等以上の機能を持つ。 企業IT管理者への影響 日本国内でも多くの企業システムやIT管理スクリプトに組み込まれているケースがあるため、IT部門は以下を早急に確認することが望ましい。 社内スクリプト・バッチファイルでの使用有無の棚卸し 監視・管理ツールによる依存関係の確認 PowerShellベースのスクリプトへの移行計画の策定 Windows合理化の一環 Microsoftは近年、レガシーコンポーネントの整理を積極的に進めている。WordPadの削除（2023年）、Internet Explorerの廃止（2022年）に続き、今回の決定も「Windowsの合理化とセキュリティ強化」という長期方針の一環と見られる。 古いツールへの依存を断ち切り、よりモダンな管理インターフェースへの移行を促すことで、Windowsのセキュリティポスチャー（セキュリティ態勢）の向上を図る狙いがある。 移行を検討している管理者は、Microsoft公式のPowerShell移行ガイドや、Windows管理センター（Windows Admin Center）の活用も選択肢に入れると良いだろう。 元記事: Microsoft formally removes a command line tool from Windows 11 25H2, 24H2, 23H2, Windows 10

英国競争当局がMicrosoftのビジネスソフト市場を調査へ 英国の競争・市場庁（CMA：Competition and Markets Authority）は、Microsoftのビジネスソフトウェア市場における支配的地位について、正式な調査を開始すると発表した。調査の焦点は、Windows、Microsoft Teams、そしてAIアシスタント「Copilot」のライセンス体系と市場慣行にある。 なぜ今、調査が始まるのか Microsoftはここ数年、企業向けソフトウェア市場で圧倒的なシェアを維持している。特に新型コロナウイルス禍以降、リモートワーク需要の急増に伴いTeamsの利用が爆発的に拡大。さらに生成AIブームを追い風に、Microsoft 365スイートへのCopilot統合も加速している。 CMAはこうした動きが、競合他社にとって不公平な障壁となっている可能性があると判断。バンドル販売や契約上の制約が、Slack（Salesforce傘下）やZoom、Google Workspaceといった競合サービスの参入を阻んでいないか検証する方針だ。 ライセンス体系が問題の核心 欧州では2023年、欧州委員会がMicrosoftに対してTeamsをOffice 365/Microsoft 365から分離販売するよう求め、Microsoftはこれに応じた。英国でも類似の懸念が浮上しており、CMAは特にエンタープライズ向けライセンスの構造が市場競争を歪めていないかを精査する。 Copilotについても、AI機能を既存の企業契約にどのように組み込んでいるかが問われる。企業が特定ベンダーのAIサービスに事実上「ロックイン」される構造になっていないかが焦点となりそうだ。 日本企業への示唆 日本でも多くの企業がMicrosoft 365を基幹インフラとして採用しており、今回の調査結果は無縁ではない。欧州・英国での規制強化がライセンス体系の変更につながれば、グローバル展開する企業のIT調達戦略にも影響が及ぶ可能性がある。 CMAの調査は数か月から1年以上かかる見通しで、最終的な勧告次第ではMicrosoftのライセンス販売方法に大きな変更が求められることになる。テック業界全体が注目する調査となりそうだ。 元記事: UK watchdog to probe Microsoft business software over market dominance concerns

Microsoftは2026年3月を通じて、ビジネスコミュニケーションツール「Microsoft Teams」に多数の新機能と改善を順次展開した。今回の更新は単発の大型リリースではなく、月を通じて段階的に適用されたもので、チャット、会議、そして日常的なワークフロー全般にまたがる幅広い改善が含まれている。 チャット機能の強化 チャット周りでは、メッセージの検索性や整理に関する改良が加えられた。スレッドの視認性が向上し、長期にわたるやりとりを追いやすくなった。また、リアクション機能やメッセージの固定表示といった既存機能の使い勝手も細かく磨かれており、日々の情報共有がよりスムーズになっている。 会議体験の向上 オンライン会議に関しては、参加者の管理や発言権（スピーカー制御）に関連する操作が整理された。ノイズキャンセリングや背景フィルターといった既存のAI機能も継続的に精度が高められており、ハイブリッドワーク環境における会議品質の底上げが図られている。日本でも定着しつつあるリモート会議の場面で、その恩恵を実感しやすい改善といえる。 ワークフロー連携の改善 業務フロー全般においては、TeamsとMicrosoft 365の各アプリ（OutlookやSharePoint、Copilotなど）との連携がさらに深化した。タスク管理や承認フローをTeams内で完結させる動きが加速しており、アプリを行き来するコンテキストスイッチを減らす狙いがある。 日本企業への影響 国内でもTeamsはMicrosoft 365ライセンスに標準で含まれることから、多くの企業・組織で導入が進んでいる。今回のアップデートは自動的に適用されるため、ユーザー側での追加作業は基本的に不要だ。ただし、新機能の中には管理者がポリシーで有効化する必要があるものも含まれる場合があるため、IT管理者は変更内容を確認しておくことが推奨される。 Microsoftは毎月このようなアップデートを積み重ねており、Teamsは着実に進化を続けている。競合するZoomやSlackとの差別化を図りながら、Microsoft 365エコシステムの中核プラットフォームとしての地位を強化する姿勢が、今回の更新からも読み取れる。 元記事: Here are all the new features Microsoft added to Teams in March 2026

MicrosoftがCopilotを「エンターテインメント目的のみ」と規約に明記 Microsoftの生成AIアシスタント「Microsoft Copilot」の利用規約（Terms of Use）に、サービスが「エンターテインメント目的のみ（for entertainment purposes only）」であるとする文言が含まれていることが注目を集めている。Hacker Newsで366ポイントを獲得し、145件のコメントが寄せられるなど、技術者コミュニティで大きな話題となっている。 利用規約の主なポイント 2025年10月24日付で更新されたCopilotの利用規約は、読みやすさと明確さを重視して全面的に書き直されたと説明されている。今回の改訂では以下の点が明記された。 Copilot Actionsおよびショッピング体験に関する新規条項の追加 行動規範（Code of Conduct）の改訂——できること・できないことの明確化 免責事項の強調——Copilotの回答が不正確・不完全・不適切になり得ることを利用者に明示 規約では「Copilotは良い回答を提供しようとするが、誤りを犯すこともある」と率直に認めており、「説得力があるように見えても、不完全・不正確・不適切な回答が表示される場合がある」と警告している。また、インターネット上の情報を参照して回答を生成するが、その内容をMicrosoftはコントロールできないとも明記している。 「判断は利用者自身で」 規約はさらに、「Copilotから得た情報をもとに意思決定や行動をする前に、必ず自分で判断し情報を確認するように」と求めている。不適切な回答を見た場合は、フィードバック機能を通じて報告することも推奨されている。 日本への影響と背景 日本国内でも、企業や個人がCopilotを業務・学習・情報収集に活用するケースが急増している。こうした中で今回の規約表現は、AIツールを「信頼できる情報源」として扱うことへのリスクを改めて浮き彫りにした形だ。 医療・法律・財務など専門性の高い判断が求められる領域では、AIの出力をそのまま利用することは特に危険を伴う。「エンターテインメント目的」という表現はいわゆる法的免責（ディスクレーマー）の一環とも読めるが、企業としての公式見解がここまで明示された点は見逃せない。 AI時代のリテラシーが問われる ChatGPTやGeminiなど他の主要AIサービスも同様の免責事項を設けているが、「エンターテインメント目的」という表現の強さは異例とも言える。生成AIの爆発的な普及が続く中、利用者一人ひとりが情報の正確性を自ら検証する「AIリテラシー」の重要性が、あらためて問われている。 元記事: Microsoft: Copilot is for entertainment purposes only

Mistral AI、多機能統合モデル「Mistral Small 4」をリリース フランスのAIスタートアップMistral AIは、新モデル「Mistral Small 4」を公開した。同社がこれまで別々に提供していた複数の専門モデルを1つに統合したのが最大の特徴で、Apache 2.0ライセンスのもと商用利用も可能だ。 4つのモデルを1つに Mistral Small 4は、以下の4つの役割を単一モデルで担う。 Mistral Small（命令追従・一般チャット） Magistral（推論・思考） Pixtral（マルチモーダル・画像理解） Devstral（エージェントコーディング） 従来はタスクに応じてモデルを切り替える必要があったが、Small 4ではAPIを変えずにすべてのワークロードを処理できる。システム設計の複雑さを減らし、運用コストを下げることが狙いだ。 アーキテクチャ：MoEで「軽さ」と「賢さ」を両立 アーキテクチャにはMixture-of-Experts（MoE）を採用。総パラメータ数は1,190億（119B）と大規模だが、1トークンあたりの推論に使うアクティブパラメータは約60億（6B）に抑えられている。埋め込み・出力層を含めても80億（8B）程度であり、実際の計算コストは総パラメータ数ほど大きくない。128の専門家（エキスパート）のうち、各トークン処理時に4つだけが有効化されるスパース構造が効率化の鍵だ。 コンテキストウィンドウは256,000トークンと広大で、長文ドキュメントの分析、コードベース全体の探索、複数ファイルにまたがる推論といった実用的なエンジニアリングシナリオで効果を発揮する。 推論の深さをリクエストごとに調整可能 注目の新機能が、推論努力量（reasoning_effort）のリアルタイム制御だ。開発者はAPIリクエストごとにこのパラメータを指定できる。 設定値 挙動 none 高速・簡潔な応答（Mistral Small 3.2相当） high 段階的な深い思考・詳細な回答（Magistral相当） これにより、軽量な質問には素早く、複雑な問題には時間をかけて思考させるという使い分けが、同一モデル・同一エンドポイントで完結する。「高速モデル」と「推論モデル」を別々に管理する必要がなくなり、プロダクト開発の効率が向上する。 処理速度と効率の改善 Mistralによると、Mistral Small 3比でエンド・ツー・エンドの完了時間が40%短縮、スループット最適化構成では1秒あたりの処理リクエスト数が3倍に向上したという。 ベンチマーク結果 Mistralが公開したベンチマーク結果では、Small 4（推論モード）はGPT-OSS 120Bと同等以上のスコアを複数のベンチマーク（AA LCR、LiveCodeBench、AIME 2025）で記録した。特筆すべきは出力効率で、QwenシリーズがAA LCRで同等性能を出すために5,800〜6,100文字の出力を要するのに対し、Small 4は1,600文字程度で同等の精度を達成したとされる。LiveCodeBenchではGPT-OSS 120Bを上回りつつ、出力量を約20%削減している。 ただし、これらはMistral自身が公開した数値であり、第三者による独立した検証は今後に委ねられる部分も多い。 日本の開発者への影響 国内でも、RAGシステムやエージェントAIの開発において「モデルの使い分け」が運用上の課題となっているケースは多い。Small 4のような統合型モデルが実用レベルで機能するなら、マルチモデル管理の負担軽減につながる可能性がある。Apache 2.0ライセンスでの公開により、オンプレミス環境やプライベートクラウドでの自社ホスティングも検討しやすい。 元記事: Mistral AI Releases Mistral Small 4: A 119B-Parameter MoE Model that Unifies Instruct, Reasoning, and Multimodal Workloads

GoogleのTurboQuant、LLMインフラの常識を覆す圧縮技術を発表 Googleが発表した量子化技術「TurboQuant」が、大規模言語モデル（LLM）のインフラ業界に衝撃を与えている。最大の特徴は、モデルの再学習（ファインチューニング）を一切必要とせず、精度損失ゼロのままKVキャッシュ（Key-Valueキャッシュ）を3ビットへ圧縮できる点だ。 KVキャッシュとは何か KVキャッシュとは、LLMが推論（テキスト生成）を行う際に計算済みの中間状態を保持するメモリ領域のことだ。長い文章を扱うほど、またバッチサイズ（同時処理リクエスト数）が増えるほど、このキャッシュは膨大なGPUメモリを消費する。現在の多くのモデルでは16ビットや8ビットの浮動小数点数で保存されており、これがサーバーコストを押し上げる主要因のひとつになっていた。 TurboQuantが実現すること TurboQuantは、KVキャッシュを3ビットに圧縮することで6倍以上のメモリ削減を実現する。既存の量子化手法では精度劣化や再学習コストが課題だったが、TurboQuantはこの両方を解決したと主張しており、これが業界で注目を集めている最大の理由だ。 メモリ消費が大幅に減少することで、同一ハードウェアで扱えるコンテキスト長の拡大や、同時処理リクエスト数の増加が見込める。クラウドプロバイダーやLLMサービス事業者にとっては、インフラコストの抜本的な見直しにつながる可能性がある。 48時間でllama.cppとApple MLXに移植 技術の影響力を示すように、論文公開から48時間以内に主要なオープンソース実装への移植が報告されている。Meta製の軽量推論ライブラリ「llama.cpp」と、AppleのシリコンチップをターゲットにしたMLフレームワーク「Apple MLX」の両方に対応コードが登場した。 この迅速な移植は、TurboQuantがアルゴリズムとして実装しやすい設計になっていることを示唆している。日本でもローカルLLMの実行にllama.cppを活用しているエンジニアは多く、実用的な恩恵が比較的早期に広がる可能性がある。 インフラ業界への波紋——メモリチップ株が下落 TurboQuantの発表はソフトウェア分野を超えた影響も起こしている。LLMの需要拡大を背景に株価を上げていたメモリチップメーカーの株価が発表後に下落したと報じられており、投資家が「AIのメモリ需要が想定より早く圧縮技術で緩和されるのではないか」と警戒していることをうかがわせる。 今後の展望 現時点ではKVキャッシュの圧縮が対象だが、モデルウェイト全体への応用や、エッジデバイス（スマートフォン、組み込み機器）での推論実行への展開も議論されている。再学習不要という特性は、既にデプロイ済みのモデルにもそのまま適用できることを意味しており、現場への導入ハードルは低い。 LLMの活用が本格化する中、TurboQuantはクラウドインフラのコスト構造と、エッジでのAI実行可能性の両方を同時に変えうる技術として、今後も注目が続きそうだ。 元記事: Google’s TurboQuant: The Compression Breakthrough That Could Reshape LLM Infrastructure

Windows 11が本格的なゲーミングOSへ——「Xbox Mode」が2026年4月に登場 MicrosoftはGDC（ゲーム開発者会議）2026において、Windows 11向けの新機能「Xbox Mode」を2026年4月より段階的に提供開始すると正式発表した。同時に、次世代Xboxコンソールの開発コード「Project Helix」の詳細も初公開され、MicrosoftのゲーミングエコシステムがXbox Game Pass登場以来最大の変革期を迎えようとしている。 Xbox Modeとは何か Xbox Modeを有効にすると、Windows 11がコンソールライクなゲーミング環境に変身する。コントローラー操作に最適化されたフルスクリーンUIが起動し、Xbox本体のダッシュボードに近い操作感でゲームを楽しめる。バックグラウンドで動作する不要なWindowsプロセスを一時停止し、電源設定を自動最適化することで、ゲームパフォーマンスの向上を図る。 ゲームライブラリの管理も大幅に改善される。Xbox Game Pass、Microsoftストア、Steam、Epic Games Storeなど複数のプラットフォームのゲームが一つのインターフェースに統合され、購入先を問わずXbox Liveを通じた実績管理が可能になる。日本でも人気の高いSteamとの統合は、PCゲーマーにとって特に魅力的な機能だろう。 技術の核心——DirectX ML Xbox Modeの技術的な目玉が「DirectX ML」だ。DirectX 12 Ultimateに直接組み込まれたこの機械学習フレームワークは、リアルタイムのアップスケーリング、フレーム生成、AIによるテクスチャフィルタリングを実現する。 NVIDIAのDLSSやAMDのFSR（FidelityFX Super Resolution）と同様の技術だが、決定的な違いがある——プラットフォーム非依存であることだ。DirectML（Direct Machine Learning）を基盤とし、NVIDIAのテンソルコアだけでなく、AMDやIntelの対応GPUでも動作する。GDCでのデモでは、対応タイトルで視覚品質を維持しながら40〜70%のパフォーマンス向上が示された。 ドライバーレベルで動作するため、開発者側の実装コストも低い。DirectX 12 Ultimateを使用するゲームは、Xbox Modeで起動するだけで自動的にDirectX MLの恩恵を受けられる。当初はXbox Mode限定で提供され、通常のWindows環境への展開時期は未定とのことだ。 次世代Xbox「Project Helix」——AIゲーミングに注力 「Project Helix」は次世代Xboxコンソールの開発コード名だ。詳細は限られるが、カスタムAMD SoCを搭載し、Windows PCのゲーミングアーキテクチャと共通の設計思想を持つとされる。「Helix（二重螺旋）」という名称から、業界アナリストは従来型コンソールとクラウドネイティブデバイスの並行展開、もしくはモジュール型ハードウェアの可能性を指摘している。 Microsoftはローカルとクラウドゲーミング間の「シームレスな移行」を強調しており、Xbox Cloud Gamingとの深い統合が予想される。性能目標は非公開だが、「AIで強化されたゲーミングにおける世代的飛躍」という表現からは、単純なテラフロップス競争ではなく、機械学習能力の向上に重点が置かれていることがうかがえる。 PCゲーマーへの影響 Xbox ModeとDirectX MLの組み合わせは、ミドルレンジのGPUユーザーにとって恩恵が大きい。RTX 3060やRX 6700 XTクラスのGPUでも、AI支援によって上位クラスに近い描画品質が期待できる。国内のPCゲーマーにとっても、Steamライブラリとの統合やコントローラー対応の強化は、Xbox GamePassへの移行ハードルを下げる可能性がある。 4月の提供開始は段階的なロールアウトとなる見込みで、まずWindows Insider向けから展開されると予想される。Project Helixの正式発表時期は不明だが、2027年以降のリリースが濃厚とみられる。 元記事: Xbox Mode Launches on Windows 11 in April 2026 with DirectX ML, Project Helix Teased for Next-Gen Xbox ...

Microsoft Agent 365とは何か Microsoftは2026年5月1日、AIエージェント管理の新サービスMicrosoft Agent 365を正式リリース（GA）する。エンタープライズ向けAI活用が加速するなか、IT部門・セキュリティチームにとって準備必須の新プラットフォームだ。 Agent 365は、組織内で稼働するすべてのAIエージェントを一元的に「観測・ガバナンス・セキュリティ管理」するためのコントロールプレーンである。エージェントを構築するツールではない点に注意が必要だ。エージェント構築はCopilot Studio、Microsoft Foundry、またはAgent Builderが担う。Agent 365の役割は、Microsoftプラットフォーム製・サードパーティ製を問わず、テナント上で動作するすべてのエージェントを管理下に置くことにある。 Microsoftはこれを「Microsoft PurviewやEntraがユーザーとデータに対して行ってきたことを、エージェントにも拡張したもの」と説明しており、AIガバナンスの中核インフラとして位置づけている。 2種類の認証フロー：OBOとエージェントIDの違い Agent 365はMicrosoft Entra Agent IDを基盤とした2種類の認証フローをサポートする。この違いを正しく理解することが、設計・ライセンスの両面で極めて重要だ。 On-Behalf-Of（OBO）フロー — 5月1日よりGA GAリリース時の標準モデルはOBO（代理実行）フローだ。エージェントはユーザーの委任トークンを受け取り、ユーザーの権限・コンテキストで処理を実行する。メールや予定表、ファイルなどユーザー固有のデータへのアクセス、明示的なユーザー同意が必要な操作、ユーザーコンテキストの保持が求められるシナリオに最適だ。監査ログも充実しており、コンプライアンス要件に応えやすい。 エージェントID認証 — プレビュー継続 もう一方は、エージェントが自身の認証情報で独立して動作するモデルだ。ユーザーとは切り離された独自のIDと権限を持ち、スケジュールタスク・監視ジョブ・バックグラウンド処理など完全自律型の操作に向いている。エージェント自身のメールボックスからメール送信や会議作成を行うことも可能だ。ただし、こちらは5月1日以降もプレビューのまま継続される。 ライセンス：従来の「エージェント単位」から「ユーザー単位」へ ライセンスモデルの変更も注目点だ。初期のFrontierプログラムではエージェント単位の課金が示唆されていたが、GAに際してユーザー単位のSKU、月額15ドル/ユーザーに刷新された。Microsoft 365 E7ライセンスに同梱されるほか、スタンドアロンでの購入も可能だ。 この変更理由について製品チームはAMA（Ask Me Anything）セッションで「予算の予測可能性」を挙げている。組織はユーザー数を把握しているが、将来的に何台のエージェントが稼働するかを事前に見積もることは困難だ。ユーザー単位に統一することで、IT部門が導入コストを計画しやすくなる。 日本のIT管理者へのポイント 国内企業でもMicrosoft 365の活用が進むなか、Copilot Studioで社内エージェントを構築・展開しているケースが増えている。Agent 365の登場により、これらエージェントの可視化・統制が一段と強化される。5月1日のGA前に、認証フローの設計方針とライセンス要件を社内で確認しておくことが推奨される。 元記事: Microsoft Agent 365 FAQ: What You Need to Know Before May 1st

OneDrive・SharePointでMarkdown編集がネイティブ対応——追加ツール不要に Microsoftは2026年4月中旬から5月下旬にかけて、OneDriveおよびSharePointにおいてMarkdown（.md）ファイルのブラウザ内直接表示・編集機能を順次展開する。これまで.mdファイルをSharePoint/OneDrive上で編集するには、Visual Studio CodeやObsidianなどの外部ツールを別途用意する必要があったが、今後はWebブラウザだけで完結できるようになる。 この機能は開発者やテクニカルライター、ドキュメント管理担当者にとって特に恩恵が大きい。GitHubのREADMEやWikiと同様に、Microsoft 365環境内でもMarkdownが「一級市民」として扱われる形だ。SharePointをナレッジベースやプロジェクトドキュメントの管理基盤として活用している企業では、運用フローの簡素化が期待できる。 同時期に展開される主な関連アップデート 今回の発表はMicrosoft 365全体の2026年3月分アップデートの一環として公開されたもので、他にも注目すべき変更点がいくつか含まれている。 Microsoft 365 Backup のターゲットリストア強化（4月下旬〜5月上旬）: SharePointとOneDriveの復元ポイントから、ファイルやフォルダ単位での個別リストアが可能になる。これまでのサイト全体リストアから細粒度化され、誤削除対応の運用が大幅に改善される。 SharePoint外部共有の認証方式変更（2026年5〜7月）: 現在利用されているSharePoint OTP（ワンタイムパスコード）による外部共有が廃止され、Microsoft Entra B2Bゲストフローへ移行する。5月以降の新規招待から順次切り替わり、7月中に完全移行が完了する予定。既存のOTPリンクは、ユーザーがB2Bゲストフローを完了するまで引き続き一部アクセス可能だが、管理者は早めに移行計画を立てておくことが推奨される。 Teamsにも複数の新機能 Teams関連では、録画ミーティングのハイライトクリップと要点まとめを自動生成する「ビデオ会議リキャップ」機能が4月下旬〜5月上旬に展開される。ただしこの機能はCopilotライセンスが必要なため、広範囲に展開する場合はライセンスコストと管理ポリシーの整備が必要になる。 また、外部の自動参加ボット（ミーティングアシスタントサービスなど）を検出してオーガナイザーや管理者が制御できる機能（6月上旬〜中旬）、1アカウントで最大10番号を扱えるTeams Phone マルチライン対応（4月下旬〜5月中旬）も予定されている。 管理者向けアクションチェックリスト Markdown編集機能を有効化・動作確認する SharePoint OTPからEntra B2Bへの移行計画を7月までに完了させる Copilotライセンスの割り当てと会議リキャップ機能の利用範囲を整理する Teams Phoneマルチライン割り当てを計画する ターゲットリストアのワークフローをバックアップ設定でテストする Markdownのネイティブサポートは一見地味に見えるが、エンジニアリングチームがSharePointをドキュメント基盤として活用する文脈では実用的な価値が高い。既存のMicrosoft 365環境をそのまま活用できる点は、ツール乱立を抑制したい企業にとって評価しやすいアップデートといえるだろう。 元記事: OneDrive and SharePoint Markdown File Editing Support (April 2026 Rollout)

Microsoft 365 Copilot、3月の大型アップデートで企業活用をさらに加速 Microsoftは2026年3月、Microsoft 365 Copilotに複数の新機能を追加した。今回のアップデートは「Copilotが正確な情報を返すか不安」「社内でどれだけ活用されているかわからない」といった、企業のIT管理者や現場が抱える課題に直接応えるものとなっている。 SharePoint管理センターに「権威あるソース」指定機能が登場（4月ロールアウト開始） 最大の目玉は、SharePointの管理センターからCopilot検索の優先情報源（権威あるソース）を指定できる新機能だ。4月より順次展開される。 Copilotは社内のさまざまなドキュメントやサイトを横断して回答を生成するが、情報源の信頼性にはばらつきがある。この機能を使うと、管理者が「このSharePointサイトの情報を優先して参照せよ」と明示的に設定できるため、公式ポリシー文書や最新の製品仕様書など、確度の高い情報をCopilotが優先的に参照するようになる。 日本企業においても、部門ごとにばらばらな情報が散在していることが多い。権威あるソースを明示できるこの機能は、Copilotの回答精度向上と情報ガバナンス強化を同時に実現するものとして注目される。 Teamsにコミュニティエージェントが追加 Microsoft Teamsでは、コミュニティ向けのCopilotエージェントが新たに利用可能になった。Teamsのコミュニティ機能（社外を含む大規模グループ向け）にもAIエージェントを配置できるようになり、Q&Aへの自動応答や情報共有の効率化が期待できる。 コミュニティ運営者がエージェントをカスタマイズし、よくある質問への自動回答や特定ドキュメントへの案内を設定するといった活用が見込まれる。 管理者向け「Readinessページ」で利活用状況を可視化 Copilotの導入後に「実際にどれだけ使われているのか」を把握できていない管理者は多い。今回展開されるReadinessページでは、組織内のCopilot利用状況をダッシュボード形式で確認できる。ライセンス割り当て状況、アクティブユーザー数、機能別の利用傾向などが一目でわかるようになり、ROI（投資対効果）の評価や追加トレーニング計画の立案に活用できる。 日本企業への影響 日本のMicrosoft 365ユーザー企業では、Copilotの段階的導入が進んでいる。特にSharePointの権威あるソース指定は、コンプライアンス要件の厳しい金融・製造・医療業界での活用促進につながる可能性が高い。また、Readinessページによる利活用の可視化は、DX推進担当者が経営層へ効果を報告する際の強力な根拠となるだろう。 各機能のロールアウトスケジュールはテナントによって異なるため、Microsoft 365管理センターのメッセージセンターで最新情報を確認することを推奨する。 元記事: What’s New in Microsoft 365 Copilot | March 2026

Microsoftは2026年3月16日、Copilot Chatの提供形態を変更すると発表した。変更は2026年4月15日から順次適用される。 何が変わるのか 最大の変更点は、Word・Excel・PowerPoint・OneNoteにおけるCopilot Chatの利用が、有料の「Microsoft 365 Copilot」ライセンス保有者に限定されることだ。 これまでライセンスなしでも一部利用できていたCopilot Chatは、4月15日以降はOfficeアプリ内から消える。ただし以下の機能は引き続き無償で利用可能だ。 Microsoft 365 Copilotアプリ上でのセキュアなAIチャットおよびチャット起点のコンテンツ作成 OutlookでのCopilot（受信トレイ・カレンダーとの連携を含む） ラベル表記も刷新 ユーザーやIT管理者が自分の利用状況を把握しやすいよう、製品内のラベルも変更される。 ユーザー種別 新ラベル M365 Copilotライセンスなし Copilot Chat (Basic) M365 Copilotライセンスあり M365 Copilot (Premium) すでにライセンスを持つユーザーへの影響はなし Microsoftは「有償ライセンスユーザーには変更はない」と明言しており、Premium利用者は引き続きWord・Excelなど主要Officeアプリでフルのコパイロット機能を使い続けられる。 企業IT担当者への影響 日本国内でもM365を広く導入している企業では、ライセンス体系の見直しが求められる場面が出てくる可能性がある。特に「ライセンスなしでもOffice内でCopilotが使えていた」という認識のまま運用していた組織は、4月15日以降に現場から問い合わせが増えることが予想される。 事前にIT部門から「4月15日以降はOfficeアプリ内のCopilotは有償プラン限定になる」と周知しておくことが望ましい。 今後もMicrosoftはCopilot系機能の提供範囲・ライセンス区分を継続的に見直す方針とみられ、動向を注視する必要がある。 元記事: Copilot Chat Changes - April 2026

1ファイル置くだけでClaudeが「無駄話」をやめる GitHubで公開された「claude-token-efficient」が、Hacker Newsで293ポイントを獲得し話題となっている。このプロジェクトが提供するのは、たった1つのCLAUDE.mdファイル。プロジェクトのルートディレクトリに置くだけで、Claudeが生成する出力の冗長さを平均63%削減できるという。 コードの変更は一切不要。Claude Codeは起動時にCLAUDE.mdを自動で読み込むため、ファイルを配置した瞬間から挙動が変わる。 Claudeのデフォルト出力はなぜ冗長なのか Claudeを使ったことがある開発者なら、こんな出力に心当たりがあるはずだ。 「Sure!」「Great question!」「Absolutely!」で始まるレスポンス 「I hope this helps! Let me know if you need anything!」で締めくくる定型句 質問を答える前に丁寧に言い換えて繰り返す 頼んでもいない追加提案や「改善案」を付け足す 指示していない抽象化レイヤーを盛り込んだコードを生成する 誤った前提に対して「You’re absolutely right!」と同調してしまう こうした振る舞いはすべてトークンを消費する。しかし、ほとんどの場面で実質的な情報価値はゼロだ。 ベンチマーク結果：同じ情報量、63%少ないトークン 5つのプロンプトを使って、CLAUDE.mdあり・なしの出力を比較した結果は以下の通り。 テスト内容 適用前 適用後 削減率 async/awaitの説明 180語 65語 64% コードレビュー 120語 30語 75% REST APIとは 110語 55語 50% 誤情報の訂正 55語 20語 64% 合計 465語 170語 63% 4プロンプトあたり約384出力トークンの節約。情報の欠落はなし、とプロジェクトは主張している。 コスト換算では、1日1,000プロンプトで月額約$8.64（Claude Sonnet基準）、複数プロジェクト合算では月$25超の節約になる計算だ。 正直なトレードオフ：すべての用途に向くわけではない プロジェクトはその効果を素直に認める一方で、適用すべきでないケースについても率直に説明している点が好感を呼んでいる。 効果が高いケース： 大量の出力を扱う自動化パイプライン（エージェントループ、コード生成） 数百回の繰り返し構造タスク チームで一貫したパース可能な出力が必要な場合 効果が薄いケース： 単発・短いクエリ（ファイル自体が入力トークンを消費するため、むしろマイナス） 設計議論やブレインストーミングなど、冗長な応答が価値を持つ用途 幻覚（ハルシネーション）や構造的な誤りの修正（それにはフックやゲートが必要） 確実なJSON出力が必要なケース（APIのJSON modeやツールスキーマのほうが堅牢） 重要な注意点として、CLAUDE.mdは毎メッセージごとに入力トークンとして読み込まれる。そのため、出力量が十分に多い場合にのみ節約効果がプラスになる。低頻度利用では逆にコストが増える可能性があることを、作者は明記している。 ...

ウィキペディア、AI生成コンテンツを正式禁止 インターネット最大の百科事典「ウィキペディア（Wikipedia）」が、ChatGPTなどの大規模言語モデル（LLM）を用いた記事執筆を公式に禁止した。Wikimedia財団のボランティア編集者たちによる投票で40対2という圧倒的多数で承認されたこの新ポリシーは、ウェブ上に「AIスロップ（粗悪なAI生成コンテンツ）」が氾濫する現状への明確な対抗措置だ。 なぜ禁止に至ったのか 新ポリシーが禁止の理由として挙げるのは、AIが生成するテキストが持つ構造的な問題だ。ウィキペディアが長年守り続けてきた検証可能性・中立性という核心的な基準を、AIは満たせないとしている。 具体的にはAIの「ハルシネーション（幻覚）」——存在しない事実の捏造、リンク切れ、実在しない文献の引用——が問題視されている。フランスのボランティア編集者で「WikiProject AI Cleanup」の創設メンバーであるIlyas Lebleuは、「ウィキペディア通常の文体と異なるスタイルで書かれた記事が増えていることに気づき始めた」とNPRのインタビューで述べている。 許可される限定的なAI利用 全面禁止というわけではない。以下の用途に限り、人間の編集者によるレビューを条件としてAIの使用が認められる。 他言語記事の翻訳補助 軽微な文章校正の提案 重要なのは「新しい情報の追加」を伴わないこと。あくまでも補助ツールとしての活用に留まる。 ウィキペディア共同創設者も警鐘 昨年10月、ウィキペディア共同創設者のジミー・ウェールズ（Jimmy Wales）もBBCの取材に対し、現在のAIモデルを「信頼できない」と一刀両断し、「人間編集者の代替としての利用準備はまだ整っていない」と警告していた。 皮肉な構図——育てた子に追い抜かれる この禁止措置には深い皮肉が込められている。ウィキペディアは創設から25年間、インターネット上で最も信頼されてきた情報源の一つだった。そして同時に、ChatGPTを支えるLLMを学習させるデータ源としても大きく貢献してきた。 しかし2025年後半のデータによると、ChatGPTの月間訪問数はウィキペディアをすでに上回り、ウィキペディアの人間によるページビューは2024年比で8%減少している。2023年末から2024年初頭にかけてChatGPTユーザーは36%増加しており、「歴史上ほぼあらゆるプラットフォームより速くインターネットに浸透している」（GWI上席データジャーナリスト Chris Beer氏）という状況だ。 ドミノ効果への期待と不安 Lebleuは「AIバブルへの不安が高まるにつれ、他のプラットフォームのコミュニティが自分たちの条件でAIを受け入れるかどうかを決定する、ドミノ効果を予見している」と述べ、今回の決定がウェブ全体の議論の起点になる可能性を示唆した。 日本のウィキペディアコミュニティも同様の課題に直面しており、今後の動向が注目される。AIと人間が情報の信頼性をめぐって綱引きを続ける中、25年の歴史を持つ百科事典の決断は、オープンな知識共有の未来を問い直す重要な一石となった。 元記事: Wikipedia officially bans AI-generated content

Claude Codeが10分ごとにgit reset –hardを実行？　調査の結果は「自作ツールの誤動作」 GitHubのClaude Code公式リポジトリに、衝撃的なバグレポートが投稿された。「Claude Codeが10分おきに git reset --hard origin/main を実行し、未コミットの変更をすべて消し去っている」というものだ。Hacker Newsでも250ポイント超・195コメントを集め、大きな注目を浴びた。 当初の「証拠」は非常に説得力があった 報告者のjohnmathews氏は、macOS上でClaude Code 2.1.87（--dangerously-skip-permissions モード）を使用中に異変に気づいた。Gitのreflogを確認すると、ちょうど600秒（10分）間隔で reset: moving to origin/main が95件以上記録されていた。 元記事: Claude Code runs Git reset –hard origin/main against project repo every 10 mins