OSS

移行の背景と理由 Zigプログラミング言語プロジェクトは、約10年間にわたってGitHubでホストされてきたが、2025年11月26日、公式リポジトリをCodebergへ移行すると発表した。主な理由として、マイクロソフト買収後のGitHubにおけるエンジニアリング品質の低下と、AIツールの強制的な組み込みへの反発が挙げられている。 プロジェクト創設者のAndrew Kelley氏は、「JavaScriptフレームワークが肥大化し、バグが多く、以前は素早く動いた機能が遅くなり、しばしば完全に機能しなくなった」と述べ、プラットフォームとしての信頼性が失われたと指摘している。Zigは「厳密な非LLM・非AIポリシー」を掲げており、GitHubがCopilot機能を積極的に推し進めることが、このポリシーとの整合性を失わせているという。 技術的な移行計画 移行後、GitHubのziglang/zigリポジトリは読み取り専用に変更され、正式なリポジトリはhttps://codeberg.org/ziglang/zig.gitとなる。既存のIssueやプルリクエストはGitHub上にそのまま残され、プロジェクト側は引き続き確認すると表明している。 ベンダーロックインを避けるため「コピー・オン・ライトモデル」が採用されており、Codebergでの新規Issue番号は30,000から開始することで、GitHub側との番号の混乱を防ぐ設計となっている。ユーザーは既存のGitHubのIssue・PRを新環境へ移行させる必要はなく、編集や追加コメントが必要な場合のみ対応すれば良いとされている。 GitHub ActionsとSponsorsへの不満 CI/CDについても深刻な問題が挙げられており、GitHub Actionsに「弁解の余地のないバグ」が存在し、しかも放置されている状況だとしている。「ジョブがランダムに実行されるようになり、マスターブランチのコミット検証がバックログで積み重なる事態になっている」と具体的な障害を説明した。 収益面では、GitHub Sponsorsがプロジェクトの重要な収入源だったが、担当プロダクトマネージャーのDevon Zuegel氏が去った後、機能が放置・衰退していると指摘し「負債と見なしている」と明言した。今後は非営利団体Every.orgを通じた寄付受付へ移行し、従来のホームページへの名前掲載やリリースノート掲載といったスポンサー特典も同等の形で提供する予定だ。 非営利組織としての哲学 Andrew氏はこの移行を単なる技術的な選択にとどまらず、哲学的な立場の表明として位置付けている。プラットフォーム資本主義と弱い独占禁止規制が支配する時代において、「非営利組織は共有資源を守る砦だ」と述べ、Zigが公共の利益のために独立したインフラを選択する意義を強調した。Codeberg自体も非営利組織が運営するForgejo（Giteaから派生したオープンソースのGitホスティング）ベースのプラットフォームであり、その価値観の一致がこの選択を後押ししたとみられる。

概要 Eclipse Foundationは、VS Code互換プラットフォーム向け拡張機能レジストリ「Open VSX Registry」のセキュリティを強化するため、「セキュリティ研究者認定プログラム（Security Researcher Recognition Program）」を正式に発表した。このプログラムは、脆弱性の責任ある開示（Responsible Disclosure）を奨励しつつ、世界中のセキュリティ研究者による貢献を公式に表彰することを目的としている。 Open VSX Registryは直近で月間ダウンロード数3億件を突破し、AIネイティブIDEを含む多数の開発者プラットフォームにとって重要なインフラとなっている。Eclipse FoundationのエグゼクティブディレクターであるMike Milinkovichは「Open VSXは現代の開発者プラットフォームにとって重要なインフラであり、悪意ある行為者にとってますます魅力的なターゲットになっている」とコメントし、プロアクティブなセキュリティ対策の必要性を強調した。 プログラムの仕組みと参加対象 プログラムの核心は、脆弱性を安全に報告するための透明性のある経路の整備だ。報告した研究者は「Security Hall of Fame（セキュリティ殿堂）」への掲載という形で公式に表彰されるほか、影響度に応じてデジタルバッジ、証明書、グッズなどが授与される。金銭的な報奨金（バグバウンティ）ではなく、認知・表彰を重視した設計となっている点が特徴的だ。 参加対象は独立したセキュリティ研究者、学術機関、セキュリティコンサルタント会社、オープンソースコントリビューター、そして実際にエコシステムリスクを発見した開発者と幅広い。 背景：拡張機能レジストリへのサプライチェーン攻撃リスク 拡張機能レジストリはサプライチェーン攻撃の標的として注目されており、攻撃者が悪意あるコードを正規パッケージに紛れ込ませて開発環境を侵害するリスクが高まっている。今回の取り組みは、外部の目を活用することでそうしたリスクへの対処能力を高めようとするものだ。Eclipse Foundationはベンダーニュートラルなガバナンスのもとでオープンソースインフラの持続可能性を重視しており、本プログラムはその姿勢を具体的に示した施策といえる。

概要 Block社が開発するオープンソースのAIエージェントフレームワーク「Goose」が2026年4月8日、バージョン1.30.0を正式リリースした。このリリースは40名以上のコントリビューターによる136コミットを含む大規模なアップデートで、ターミナルUI（TUI）の全面刷新、新規プロバイダーの追加、セキュリティ強化、拡張機能管理の改善など、幅広い領域にわたる変更が盛り込まれている。 ターミナルUIの刷新と新コマンド 今回のリリースで最も目立つ変更がTUIの大幅刷新だ。ツール呼び出しの出力をタブで展開・折りたたみできるようになり、長大な出力に埋もれることなく作業の流れを把握しやすくなった。メッセージのレンダリングも改善され、ストリーミング中の表示順序が安定した。 新たに追加された goose serve サブコマンドはGooseをバックグラウンドサービスとして起動できる機能で、ヘッドレス運用を想定した --text モードも独立して利用可能になった。また、設定トラブルシューティング向けの goose doctor コマンドが追加され、環境設定の問題を素早く診断できるようになっている。 プロバイダーとモデルの拡充 プロバイダー面ではGemini OAuth認証のサポートと、GitHub Copilotとの統合を担うCopilot ACPプロバイダーが新たに追加された。中国のAIサービス「Zhipu」向けの宣言型プロバイダーも追加され、ZHIPU_BASE_URL で接続先を柔軟に設定できる。さらにGoogleの最新ローカルモデル「Gemma 4」にも対応し、ローカル実行環境の選択肢が広がった。 宣言型プロバイダー全般では fast_model の設定が可能となり、処理速度を優先するタスクでより軽量なモデルへ切り替えやすくなった。VMware Tanzu Platformプロバイダーの改善も含まれており、エンタープライズ環境での利用が一層進みやすくなっている。 セキュリティ・拡張機能・設定の強化 セキュリティ面では、アウトバウンド通信を記録するEgressログインスペクターが追加され、Gooseが行うネットワーク呼び出しの監視が可能になった。シークレットファイルのパーミッションもOS標準のセキュリティ機能を利用して制限され、認証情報の保護が強化された。 拡張機能（スキル）の管理も強化された。デスクトップUIでのスキル表示、ネストされたスキルの再帰的な探索、拡張機能ごとのタイムアウト設定など、実運用で求められる細かな機能が整備された。設定面でも GOOSE_SHOW_FULL_OUTPUT によるツール出力の切り詰め制御や、GOOSE_CONTEXT_LIMIT の config.yaml からの読み取りなど、環境変数やファイルによるカスタマイズ性が向上している。 バグ修正とパフォーマンス改善 バグ修正も多岐にわたる。MCPサブプロセスが異常終了した際のクリーンアップ処理が改善されたほか、Ollama プロバイダーのハングアップ防止、OpenAI ストリーミング中のJSONパース安全性向上、Bedrockのツール入力でnullの代わりに空オブジェクトを返すよう修正するなど、各プロバイダー固有の問題が解消された。デスクトップアプリでは「Markdownで表示」機能の復元やスラッシュコマンドの修正も行われた。パフォーマンス面ではACPサーバーでの拡張機能ローディングが並列化され、起動時間の短縮が期待できる。

概要 Rubyおよびすべてのラック互換フレームワーク向けの高性能ウェブサーバー Puma がメジャーバージョン 8.0 をリリースした。今回のリリースはIO並行処理の抜本的な改善を中心に据えており、高負荷な本番環境での運用効率を大きく引き上げることを目的としている。長年の課題だった「スレッドプールの上限に達するとIOバウンドなリクエストが詰まる」という問題に対し、新たなAPI設計で解決策を提示した点が最大のハイライトだ。 主要な新機能 IOバウンドリクエストの動的処理 最も注目される新機能が、env["puma.mark_as_io_bound"] APIと max_io_threads 設定の組み合わせによるIOバウンドリクエストの超過処理機構だ。従来のPumaはスレッドプールの上限（max_threads）を超えたリクエストをキューイングするしかなかったが、Puma 8.0ではリクエストハンドラがそのリクエストをIOバウンドとしてマークすることで、スレッドプール上限を超えた追加スレッドで処理できるようになった。データベース待ちや外部APIコールが多い混合ワークロード環境で特に効果を発揮する。 動的スレッドプール更新 新たに update_thread_pool_min_max APIと ServerPluginControl が導入され、サーバーを再起動せずにランタイムでスレッドの最小・最大数を変更できるようになった。トラフィック変動に応じてスレッド数をオンザフライで調整するオートスケーリング実装が容易になる。 モード固有設定フック シングルモードとクラスターモードそれぞれに専用のDSLフック（single / cluster）が追加された。デプロイ形態ごとに異なる設定を一つの設定ファイル内でクリーンに記述できるようになり、設定管理が簡潔になる。 シャットダウンデバッグの強化 shutdown_debug オプションに on_force が追加され、グレースフルシャットダウンではなく強制シャットダウン時にのみスレッドバックトレースをダンプするよう制御できるようになった。通常運用のログを汚さず、問題発生時のみ詳細情報を記録できる。 Linux/JRuby向けシグナル対応 SIGINFO未対応のLinux/JRuby環境でSIGPWRを使ってスレッドバックトレースダンプを呼び出せるようになり、プラットフォーム間でのデバッグ体験が統一された。 パフォーマンス改善 JRuby向けのHTTPパーサーが最適化された。ヘッダーキーの事前割り当てと完全ハッシュルックアップ（perfect hash lookup）の採用、メモリコピーの削減により、JRuby環境でのパース性能が向上した。 また、全Ruby実装共通の改善として、str_headers でダウンケース済みヘッダーキーをキャッシュすることで冗長な String#downcase 呼び出しを排除し、レスポンスごとのアロケーションが約50%削減された。大量リクエストを捌くサービスではガベージコレクション圧力の軽減が期待できる。 破壊的変更と移行上の注意点 Puma 8.0では本番環境のデフォルトバインドアドレスが 0.0.0.0（IPv4）から ::（IPv6）に変更された。IPv6が利用できない環境では自動的に 0.0.0.0 にフォールバックするが、ファイアウォール設定やリバースプロキシの設定によっては動作が変わる可能性があるため、アップグレード前に確認が必要だ。 バグ修正としては、fork_worker 利用時にフェーズ再起動でワーカー0が古い状態のまま置き換わらない問題が解消された。

WordPress 7.0リリース延期の背景 WordPress 7.0のリリーススケジュールが延期されることが、3月31日に公式発表された。延期の主因はリアルタイムコラボレーション（RTC）機能のデータベースアーキテクチャへの対応であり、「リリースサイクルの延長が必要」と説明されている。4月17日まで事前リリース版の公開は一時停止され、新しいリリーススケジュールは4月22日までに改めて公表される予定だ。 あわせて重要な変更として、WordPress 7.0ではPHP 7.2および7.3のサポートが終了する。最小要件はPHP 7.4となり、PHP 8.2以上が推奨バージョンとなる。古いPHP環境を利用しているサイト管理者は、アップグレードへの対応が求められる。 リアルタイムコラボレーション（RTC）の技術的詳細 今回の延期の中心にあるRTC機能は、分散システムでの競合解決に広く使われるCRDT（Conflict-free Replicated Data Type）エンジンとして「Yjs」を採用している。通信方式にはWebRTCではなくHTTPポーリングが選択されており、これはWebRTCの互換性よりも汎用的なホスティング環境への対応を優先した判断だ。なお、クラシックなメタボックスが存在する投稿ではコラボレーションモードが無効化される。 新ビルドツールとAI統合API 開発者ツールの面では、esbuildを基盤とした新しいビルドツール「@wordpress/build」が発表された。従来の@wordpress/scriptsと比べて大幅な高速化が実現されており、移行パスは「低摩擦（low-friction）」になるよう設計されているという。 AI統合の基盤となる新機能も複数発表されている。WP AI ClientはAIサービスとの連携を標準化するPHPライブラリで、Connectors APIは認証情報やプロバイダーの選択をプラットフォームレベルで管理する仕組みを提供する。またJavaScript側でもAbilities APIが利用可能となり、サーバーで登録された機能をREST API経由で自動取得できるようになった。 テーマ開発・ブロック開発の改善 テーマ開発においてもいくつかの改善が加えられた。グローバルスタイルでボタンのホバー・フォーカス・アクティブといった疑似状態を編集できるようになったほか、theme.jsonでの疑似要素サポートも拡張された。ブロックのビューポートベースの可視性制御（CSSによる実装）や、ナビゲーションリンクのアクティブ状態スタイリングにも対応している。 ブロック開発では、カスタムブロックへのパターンオーバーライド対応が追加された。Interactivity APIではstate.navigationが非推奨となり、Formsブロックには非表示入力フィールドのバリエーションが加わった。 さらに、WordPress Playground MCPサーバーも発表されており、Claude CodeやGemini CLIなどのAIコーディングエージェントをPlaygroundインスタンスに接続し、ファイル操作やPHPの実行が可能となる。AIを活用したWordPress開発ワークフローの強化に向けた取り組みが着実に進んでいる。

概要 Linuxカーネル7.0が2026年4月13日にLinus Torvaldsによって正式リリースされた。バージョン7.0への移行はカーネル開発の慣例に従ったもので、6.19に達したタイミングで混乱を避けるために番号を繰り上げた。Torvaldsはリリースを総評して「小さな修正が多く、全体的に問題なく落ち着いた（benign）サイクルだった」と述べており、今回のリリースは革命的な変更よりも着実な改善の積み重ねとなっている。なお、本バージョンはLong-Term Support（LTS）版ではなく、引き続きLinux 6.18が2028年12月まで対応するLTSリリースとなる。 ハードウェアサポートの強化 Intel面ではNova Lakeオーディオのサポートが標準NVLバリアントに拡張され、従来のSシリーズのみの対応から幅が広がった。Intel Arc GPU向けのXeドライバーはシャットダウン制限値やメモリコントローラー温度、個別のVRAMチャンネル温度など詳細な温度情報を公開するよう改善された。また、Panther LakeがGSCファームウェアのロードとProtected Xe Path（PXP）に対応し、Diamond RapidsはPCIe経由での高速データ転送を実現するNTBドライバーサポートを獲得した。 AMD面ではZen 6向けにブランチ予測やキャッシュ活動、TLBオペレーションに関するパフォーマンスカウンターサポートがマージされた。KVM仮想化においてはReturn Address Predictor Security（ERAPS）のサポートが強化され、Return Stack Bufferの容量が32エントリーから64エントリーに倍増した。また、今後のRDNAバリアントに向けた新しいグラフィックスIPブロックの有効化や、NPU統合に向けた準備も進められている。その他、ARM、RISC-V、Loongsonプロセッサへのサポートも強化されており、RISC-VはユーザースペースのControl-Flow Integrity（CFI）サポートを獲得した。 ファイルシステムと開発環境の改善 ストレージ面での注目は、XFSに追加された自律的な自己修復機能だ。新たに導入されたxfs_healerデーモンが、ファイルシステムがマウントされたままの状態でメタデータの障害を自動検出し修復する仕組みを提供する。Btrfsについてはより大きなブロックサイズへのDirect I/Oサポートや実験的なremap-tree機能が追加され、EXT4は遅延エクステント分割による並行書き込みパフォーマンスが向上した。 開発環境においては、Rust言語によるカーネル開発のサポートが「実験的」のステータスを脱して正式サポートとなった大きな節目を迎えた。ネットワーク面ではWiFi 8のUltra-High Reliability（超高信頼性）に向けた下地が実装されたほか、ASUS製マザーボードのセンサーサポートも拡充されている。 AIとカーネル開発の新潮流 今回のリリースではLinus Torvalds自身がAIのカーネル開発への影響について言及した点も注目された。TorvaldsはリリースメールにおいてAIツールの普及によるバグ発見の増加を予想し、「AIツールの活用がしばらくはコーナーケースを見つけ続けるだろう。これが『新しい常態』になるかもしれない」とコメントした。この見解は、メンテナーのGreg Kroah-Hartmanが以前指摘したAIによるカーネルバグ検出の有効性とも一致しており、AIがカーネル開発のエコシステムに新たな側面をもたらしつつある状況を示している。

背景：相次ぐサプライチェーン攻撃への対応 2026年3月には「Trivy」「LiteLLM」のサプライチェーン侵害が発生し、それ以前にも「Ultralytics」「tj-actions」「Nx」など著名なOSSプロジェクトが攻撃を受けた。こうした状況を受け、Python向け高速ツールチェーン「uv」と「Ruff」を開発するAstralは、2026年4月8日に自社OSSプロジェクトで実践しているセキュリティ対策を包括的に公開した。執筆者はAstralのWilliam Woodruff氏で、ユーザーや他のメンテナー、CI/CDシステム開発者にとって参考になる知見を共有することを目的としている。 CI/CDワークフローのセキュリティ強化 CI/CD面では、まずpull_request_targetやworkflow_runといったGitHub Actionsのトリガーを組織全体で禁止している。Astralはこれらを「安全に使うことがほぼ不可能」と断じ、より安全な代替手段が存在するケースがほとんどだと主張している。 GitHub Actionsのアクション参照はすべてコミットハッシュへのピン留めを必須とし、可変なタグやブランチへの参照は許可しない。ピン留めの強制には静的解析ツールzizmor（unpinned-uses・impostor-commitチェック）とGitHubの組織レベルポリシーを組み合わせて使用する。ただし、ハッシュピン留めで改ざんは防げても「ピン留め済みアクションが実行時に未検証のバイナリをダウンロードする」ケースは防ぎきれないという限界も率直に認めている。 ワークフローはデフォルトでpermissions: {}（権限なし）とし、ジョブ単位で必要最小限の権限のみ付与する。シークレットはリポジトリや組織全体でなく、デプロイ環境単位にスコープを限定している。 リリースプロセスとリポジトリ管理 リリースセキュリティの核心は長期有効な認証情報の排除だ。PyPI・crates.io・NPMへの公開にはOIDCベースのTrusted Publishingを採用し、固定のクレデンシャルが不要な仕組みを実現している。加えてSigstoreの署名・証明機能で、公開済みアーティファクトとそれを生成したワークフローの間に暗号学的な検証可能リンクを形成する。 GitHubのイミュータブルリリース機能によってリリース後の成果物改ざんを防ぎ、キャッシュポイズニング攻撃を防ぐためリリースワークフロー中はキャッシュを無効化している。uvのような大規模プロジェクトでは、最小権限のGitHub Appがタグ作成を仲介するrelease-gate環境を設け、タグ保護ルールセットによりデプロイ完了前のタグ作成を禁止している。また、リリースには別の権限保有メンバー1名以上の承認が必要で、多人数承認ゲートが設けられている。 組織レベルのブランチ・タグルールセットは管理者でも回避できない形で設定されており、そのルールセットはGitHub Gistで公開して他プロジェクトへの横展開を促している。 依存関係管理と上流コミュニティへの関与 依存関係の自動更新にはDependabotとRenovateを利用し、既知の脆弱性を継続的に検出している。特徴的なのは「クールダウン戦略」で、新バージョンリリース直後は意図的に更新を遅らせる。これは「一時的に侵害された依存関係がリリース直後に最も影響しやすい」というサプライチェーン攻撃の窓口を意識した対策だ。RenovateのグループごとのクールダウンでAstral自社依存は緩め、サードパーティ依存は厳しく設定している。 技術的な対策に加え、主要な上流依存のメンテナーと社会的な関係を構築し、セキュリティ改善を上流プロジェクトへ積極的にコントリビュートしている（例：apache/opendal-reqsignへのCI/CDセキュリティ改善）。Python Packaging AuthorityやPython Security Response Teamへの参加、不必要な依存の削除、バイナリblobを含む依存の回避、OSSファンドを通じた財政的支援も実践している。 まとめ：4つの原則 Astralはこれらの実践を4原則に集約している。①CI/CDの限界を尊重し安全に実行できない操作はGitHub Appで代替する、②OIDC活用で長期有効な認証情報を排除する、③環境保護・多人数承認・ルールセット・イミュータブルリリースでリリースプロセスを強化する、④自動化ツールと上流コミュニティへの積極的な参加で依存関係を継続的に監視・管理する。本記事はzizmor・pinact・Sigstore・Trusted Publishingなど具体的なツール名とともに実践的な知見を詳述しており、OSSプロジェクトのセキュリティ強化を検討するメンテナーにとって参考価値が高い内容となっている。

概要 JavaScriptランタイム「Bun」のv1.3.12が2026年4月9日にリリースされた。作者Jarred Sumnerによるこのリリースは、120件のバグ修正と219件のユーザーフィードバックへの対応を含み、開発者体験とパフォーマンスの両面で大きな強化が施されている。今回のバージョンでは、単なるバグ修正にとどまらず、ヘッドレスブラウザ自動化やcronスケジューリングといった実用性の高い大型機能が追加されており、Bunをより包括的なJavaScript実行環境へと進化させる内容となっている。 新機能：Bun.WebView・Bun.cron・Markdownレンダリング 最も注目すべき新機能はBun.WebViewだ。これはプロセス内でネイティブに動作するヘッドレスブラウザ自動化機能であり、外部ツールへの依存なしにブラウザ操作を自動化できる。テストやスクレイピングなど、これまでPlaywrightやPuppeteerを必要としていたユースケースを、Bunランタイム単体で賄える可能性がある。 インプロセスcronスケジューラ「Bun.cron()」も新たに搭載された。外部デーモンやジョブキューを用意しなくても、アプリケーションコード内にcron形式でタスクスケジュールを定義できる。定期実行が必要な処理の実装が大幅にシンプルになる。 また、bun ./file.mdコマンドを実行するとターミナル上でMarkdownが整形表示されるようになった。ドキュメントの確認やREADMEの閲覧が手軽にできる開発者向けのQoL改善だ。さらに、ネイティブエラーに対する非同期スタックトレースのサポートも追加され、非同期処理のデバッグが容易になった。 パフォーマンス改善とNode.js互換性強化 パフォーマンス面でも顕著な改善が報告されている。URLPatternの処理速度が約2.3倍に向上し、Bun.Glob.scanが約2倍高速化された。LinuxにおけるLinux cgroupへの対応によって並列処理の最適化も図られており、CI/CDやコンテナ環境での動作改善も期待できる。 Node.js互換性についても継続的な改善が行われており、既存のNode.jsエコシステムとの相互運用性がさらに高まっている。バグ修正の数が多いことからもわかる通り、コミュニティからのフィードバックに積極的に応答する形でリリースサイクルが回っており、実用レベルでの安定性向上が着実に進んでいる。

概要 macOSで20年以上の歴史を持つネットワーク監視ツール「Little Snitch」を開発するObjective Developmentが、2026年4月8日にLinux版「Little Snitch for Linux」を初めてリリースした。アプリケーションがどのサーバーと通信しているかをリアルタイムで可視化し、不要な接続をブロックできるツールで、macOS版で培った知見をLinuxプラットフォームへ展開した形となる。 技術的な仕様 技術面では、eBPF（extended Berkeley Packet Filter）を活用してLinuxカーネルのネットワークスタックにフックし、アウトゴーイング接続を監視する設計を採用している。eBPFプログラムが接続を監視してデーモンにデータを渡し、統計を追跡する仕組みだ。実装言語にはRustが使われており、動作にはLinuxカーネル6.12〜6.19.0およびBTF（BPF Type Format）のカーネルサポートが必要となる。 UIはWebインターフェースとして提供されており、http://localhost:3031/ にアクセスすることでプログレッシブウェブアプリ（PWA）として利用できる。機能としては、アプリケーションごとの接続監視とフィルタリング、複数フォーマット（ドメイン、ホスト名、/etc/hosts形式、CIDR範囲）に対応したブロックリストの自動更新、プロセス・ポート・プロトコル単位の細かなカスタムルール設定、時系列でのトラフィック量可視化などが含まれる。 ライセンスとプライバシーの考え方 ライセンス面では、eBPFカーネルプログラムとWeb UIがGNU General Public License v2（GPLv2）でオープンソース公開されており、GitHubでソースコードが入手可能だ。一方、デーモンコンポーネントはプロプライエタリだが、無料で利用・再配布が可能とされている。 開発元はこのツールの目的について「セキュリティではなくプライバシーの保護」を優先すると明言している。eBPFの制約上、高負荷なトラフィック環境ではパケットとプロセスの正確な紐付けが難しくなるため、システム強化よりも監視・把握のための用途に適したツールと位置づけられている。

概要 MicrosoftのBingチームは2026年4月、埋め込みモデル「Harrier」をMITライセンスのオープンソースとしてHugging Face上で公開した。Harrierは多言語MTEB-v2ベンチマークで総合スコア74.3を記録し首位を獲得、OpenAIやAmazonが提供するプロプライエタリな埋め込みモデルを上回る性能を示している。商用・非商用を問わず無償で利用可能なMITライセンスのもと提供されており、エンタープライズ用途から個人開発まで幅広い活用が期待される。 モデルの技術的詳細 Harrierは3つのサイズ展開で提供される。フルサイズの270億パラメータモデルに加え、より軽量な6億パラメータ版と2億7000万パラメータ版が用意されており、利用するハードウェアのスペックに応じて選択できる。94の言語に対応し、3万2768トークンのコンテキストウィンドウと5376次元の埋め込みベクトルを持つ。学習データは20億件以上の実例に加え、GPT-5を用いて生成した合成データも活用されている。 活用シナリオと今後の展開 埋め込みモデルはAIシステムが情報を検索・取得・整理し、正確な応答を生成するための基盤となる技術であり、RAG（Retrieval-Augmented Generation）などの構成において中核的な役割を担う。MicrosoftはHarrierをBing検索へ統合するとともに、複雑なマルチステップタスクを処理するAIエージェント向けのグラウンディングサービスにも組み込む計画を明らかにしている。高性能かつオープンなモデルの公開により、開発者コミュニティが自前のRAGパイプラインや検索システムを構築する際のベースラインが大きく引き上げられることになる。