NVIDIAがCNCFプラチナメンバーに加入し、GPU DRAドライバーをKubernetesコミュニティへ寄贈

概要 アムステルダムで開催されたKubeCon + CloudNativeCon Europe 2026(2026年3月24日)のDay 1において、NVIDIAはCloud Native Computing Foundation(CNCF)のプラチナメンバーとして正式に加入し、GPU向けDynamic Resource Allocation(DRA)ドライバーをCNCFへ寄贈すると発表した。このドライバーはベンダー中立なリファレンス実装としてKubernetesプロジェクト配下でコミュニティ管理へ移行する。CNCFのCTO Chris Aniszczyk氏は「NVIDIA DRAドライバーのアップストリーム化は、オープンソースのKubernetesとAIインフラにとって大きなマイルストーン」と評した。13,500人以上が100カ国から参加した同カンファレンスで発表されたこの取り組みは、AIインフラ標準化への業界的な期待の高さを示している。 GPU DRAドライバーの技術的な詳細 従来のKubernetesにおけるGPU管理では、nvidia.com/gpu:1 のような単純な整数リソースとして扱うモデルが主流であり、現代のAIワークロードが必要とする細粒度な要求を表現できなかった。新たに寄贈されるDRAドライバーはこの制約を大きく解消する。 主な機能は以下の通りだ。 NVIDIA Multi-Process Service(MPS)とMulti-Instance GPU(MIG) によるスマートなGPU共有 NVIDIA Multi-Node NVLink を活用したGrace Blackwellシステム上での大規模AIモデルのスケーラブルなトレーニング ComputeDomains という抽象化レイヤーにより、複数ノードにまたがるワークロードが単一の巨大なGPU上で動作しているかのように振る舞うマルチノードNVLink通信 Container Device Interface(CDI) による標準化されたデバイス注入 アプリケーション要求に応じたリアルタイムのハードウェア再設定 アーキテクチャとしては「GPUオペレーター」「DRAドライバー」「KAIスケジューラー」の3層構造で構成される。KAIスケジューラーはAI対応インテリジェンスを担い、フラクショナル割り当てや分散トレーニング向けのギャングスケジューリングなどを提供し、今回CNCFサンドボックスプロジェクトとして新たにオンボードされた。 追加発表とエコシステムへの影響 NVIDIAはDRAドライバーの寄贈に加え、以下の取り組みも発表した。 Grove: GPUクラスター上でAIワークロードをオーケストレーションするためのオープンソースKubernetes API Kata Containers向けGPUサポート: 軽量仮想マシンを活用したセキュアなGPU利用 NVSentinel および AI Cluster Runtime プロジェクトの公開 さらにNVIDIAは今後3年間でCNCFプロジェクトへ4百万ドルを投資し、高性能GPUコンピューティングリソースへのアクセスを提供することを約束した。Amazon Web Services、Broadcom、Canonical、Google Cloud、Microsoft、Nutanix、Red Hat、SUSEなど主要クラウド・インフラプロバイダーとの連携も進める予定だ。「KubernetesはモダンなAI時代ワークロードのデファクトコントロールプレーンに進化した」とされる中、今回の取り組みはGPU対応クラウドネイティブ基盤の標準化を加速し、AIインフラが独自サイロから共通ユーティリティへと移行する流れを決定づけるものとして注目される。

April 6, 2026

OSSセキュリティレポート:AI主導の開発加速で脆弱性が前四半期比145%増、修正中央値は2日を維持

概要 Chainguardが公開した「State of Trusted Open Source Report(2026年4月版)」は、2025年12月から2026年2月までの期間に2,200以上のコンテナイメージプロジェクトと33,931件の脆弱性インスタンスを分析した調査結果をまとめたものだ。最大の注目点は、ユニーク脆弱性数が前四半期比145%増と急増した一方で、修正の中央値は安定した2.0日を維持していたことである。AIコード生成ツールの普及による開発サイクルの加速が、脆弱性発見件数の急増に直接影響していると報告は指摘する。 AI活用がもたらした技術スタックの変化 AIワークロードの本番環境への流入が、利用技術スタックにも明確な変化をもたらした。Chainguardの顧客の72.1%がPythonイメージを使用しており、機械学習やデータ処理ワークフローの主軸として定着している。またPostgreSQLの利用は前四半期比73%増と急伸しており、AI向けのベクター検索やRAG(検索拡張生成)機能の採用が主な要因とされる。上位25の本番イメージのうち半数以上を言語エコシステムが占め、Node(60.7%)、Java(44.4%)、Go(42.8%)、.NET(27%)が主要インフラを支えている。 脆弱性の急増と修正対応力 脆弱性の件数は急増したが、対応速度は維持された。組織は前四半期比で300%以上の修正を適用し、それにもかかわらず高リスク脆弱性の97.9%が1週間以内に修正されている。最も懸念されるのは、CVEインスタンスの96.2%が最もよく使われる上位20イメージの外側で発生している点だ。顧客は中央値で74%のイメージをこの上位20外から調達しているが、こうした「見えにくい依存関係」へのセキュリティ注目度は依然として低く、サプライチェーンリスクの温床となっている。 コンプライアンス対応とFIPS普及の加速 規制対応という観点では、FIPS準拠のPythonイメージが初めて顧客数トップ10に入り、セキュリティコンプライアンスが事実上の標準要件へと移行しつつあることを示している。現在、42%の顧客が本番環境で少なくとも1つのFIPSイメージを稼働させており、FedRAMP・PCI DSS・SOC 2に加え、EUサイバーレジリエンス法(CRA)などの規制要件が後押ししている。本レポートが示す核心は、AIによって開発規模が拡大し続ける中で、見過ごされがちな依存関係のセキュリティをいかに一貫して管理し続けるかという課題が、現代のソフトウェアセキュリティの最重要テーマになりつつある点だ。

April 6, 2026

Discordが高性能コンテンツモデレーションエンジン「Osprey」をオープンソース化、毎秒230万ルールを処理

概要 Discordは2026年3月、社内で運用してきたコンテンツモデレーション向けSafetyルールエンジン「Osprey」をオープンソースとして公開した。同エンジンは1日4億件のプラットフォームアクションを対象に毎秒230万ルールを評価する能力を持ち、大規模なオンラインコミュニティの安全管理に求められる高スループット・低レイテンシを両立させている。プロジェクトはROOSTオーガニゼーションおよびinternet.devと連携して管理されている。 アーキテクチャと技術的詳細 OspreyはRustとPythonを組み合わせたポリグロットアーキテクチャを採用している。Rustコーディネーターが非同期イベントストリームとgRPCリクエストを処理してトラフィックをルーティングし、安定したレイテンシを実現する。一方、ステートレスなPythonワーカーがDockerコンテナ上で動作し、ルール評価をスケールアウト可能な形で担う。 ルール記述には独自DSL「SML」が使われる。SMLはPythonに似た構文を持ち、静的バリデーションをサポートしている。ワーカーは起動時にSMLルールを抽象構文木(AST)に変換することでイベントごとの処理オーバーヘッドを最小化する。ルールの配信にはETCDが用いられており、再デプロイなしに本番環境のルールをリアルタイムで更新できる点が運用上の大きな利点となっている。 機能と拡張性 Ospreyはプラットフォーム上のリアルタイムアクティビティをJSON形式のイベントペイロードとして受け取り、自動応答を実行する。特定の対象(エンティティ)に対してラベルや分類を付与し、設定可能な出力シンクへ判定結果をルーティングする仕組みだ。標準的な構成ではApache KafkaとApache Druidをリアルタイム分析に活用する。 拡張性も重視されており、標準Pythonで記述したユーザー定義関数(UDF)を標準ライブラリとして組み込める。これにより外部APIの呼び出しや機械学習モデルとの統合も可能になっている。 早期採用とOSS展開の意義 OspreyはDiscord以外にもすでに実績がある。分散型SNSプラットフォームのBlueskyやMatrix.orgが早期採用例として挙げられており、Discord固有の要件を超えた汎用的な適用可能性が示されている。オープンソース化によって大規模コミュニティプラットフォームが共通のセーフティインフラを共有・改善できる土台が整いつつあり、今後のコンテンツモデレーション技術の発展に寄与することが期待される。

April 6, 2026

GitHub Copilotクラウドエージェントに組織レベルのランナー一括制御機能が追加

概要 GitHubは2026年4月3日、GitHub Copilotのクラウドエージェント向けに組織レベルのランナー制御機能を発表した。これにより組織の管理者は、デフォルトランナーの設定を全リポジトリに一括適用できるようになり、さらに個別リポジトリによる設定変更をロックする「強制適用」機能も利用可能になった。 従来、Copilotクラウドエージェントがタスクを実行する際の開発環境は、各リポジトリのcopilot-setup-steps.ymlファイルを通じてリポジトリ単位で設定する必要があった。そのため、組織全体での一貫した実行環境の維持が難しく、管理コストも高くなっていた。 主な機能と活用シーン 今回追加された機能は大きく2つある。1つ目はデフォルトランナー設定で、個別のセットアップなしに標準ランナーを組織内の全リポジトリへ自動的に適用できる。2つ目は強制ロック機能で、リポジトリ側から組織が定めたデフォルト設定を上書きできないようにする。 具体的なユースケースとしては、パフォーマンス向上のためにより高スペックなGitHub Actionsランナーを組織全体に展開すること、内部リソースへのアクセスが必要な場合にセルフホストランナーへの実行を強制すること、セキュリティおよびコンプライアンスポリシーを一貫して適用することなどが挙げられる。 背景と今後の展望 今回の機能はCopilotクラウドエージェントの一連の改善の一部として提供されており、同時にファイアウォール設定やコミット署名機能も発表されている。組織規模でのAIエージェントの活用が広がる中、実行環境の標準化とセキュリティポリシーの一元管理は重要な課題となっており、今回の機能追加はその解決に向けた取り組みといえる。詳細な設定方法はGitHubの公式ドキュメント「Configuring runners for GitHub Copilot cloud agent in your organization」で確認できる。

April 6, 2026

Amper 0.10リリース — JDK自動プロビジョニング、Maven変換ツール、カスタムコンパイラプラグイン対応

概要 JetBrainsが開発するKotlin/Java向けビルドツール「Amper」のバージョン0.10が2026年3月31日にリリースされた。今回のリリースでは、JDKの自動プロビジョニング、MavenプロジェクトからAmperへの半自動変換ツール、カスタムKotlinコンパイラプラグインのサポートという3つの主要機能が追加されている。GradleやMavenの代替を目指すビルドシステムとして、実用性と移行容易性の面で大きく前進した内容となっている。 JDK自動プロビジョニング これまで開発者が手動で行う必要があったJDKのインストール・設定を、Amperが自動化する機能が追加された。デフォルトではJDK 21が自動的にダウンロード・インストールされ、module.yamlにてバージョンやディストリビューション(ZuluやTemurinなど)を明示的に指定することも可能だ。JAVA_HOME環境変数が設定されている場合はそちらが優先される。この機能により、プロジェクトのクローン直後にJDKのセットアップなしで即座にビルドを開始できるゼロコンフィグレーションなワークフローが実現した。 Mavenプロジェクト変換ツール 既存のMavenプロジェクトをAmperへ移行しやすくするため、./amper tool convert-projectコマンドで動作する半自動変換ツールが導入された。このツールはpom.xmlを読み込み、対応するAmperの設定ファイルを自動生成する。layout: maven-like設定によりMavenのディレクトリ構造をそのまま維持できるため、ファイルの再配置が不要で、完全な書き直しではなく段階的な移行が可能だ。maven-compiler-pluginのようなよく知られたMavenプラグインはAmperのネイティブ設定に変換され、その他のプラグインはmavenPluginsセクションに追加されてAmperによるビルド中に実行される。 今後の展望 本リリースはAmperが実験的なツールから実用的なビルドシステムへと進化する過程における重要なマイルストーンといえる。なお、今回追加された機能の利用にはIntelliJ IDEA 2025.3.4または2026.1以降と最新のAmperプラグインが必要となる。JetBrainsはMavenエコシステムとの互換性を高めながら、開発者の初期セットアップの摩擦を減らす方向で開発を継続している。

April 5, 2026

Strapiプラグイン偽装の悪意あるnpmパッケージ36件、暗号資産企業を標的にC2エージェントを展開

概要 2026年4月初旬、セキュリティ研究者はnpmレジストリに公開された36個の悪意あるパッケージを発見した。これらはすべて strapi-plugin- という命名パターンを持ち、正規のStrapi CMSプラグインに見せかけていた。strapi-plugin-cron、strapi-plugin-database、strapi-plugin-server など実在しそうな名前を使い、すべてバージョン3.6.8として統一して公開されていた。4つのソックパペットアカウント(umarbek1233、kekylf12、tikeqemif26、umar_bektembiev1)が13時間という短期間のうちに一斉にアップロードしており、組織的な攻撃の痕跡が明白だった。SafeDepの動的分析パイプラインが strapi-plugin-events を最初に検出し、C2通信シグナルおよび秘密情報の探索行動が確認されたことで調査が始まった。 攻撃チェーンの技術的詳細 このサプライチェーン攻撃は npm install の実行時に postinstall.js スクリプトが自動的に起動することで始まる。SafeDepの分析によれば、8段階(他の調査では11段階)に及ぶ攻撃チェーンが展開される。 まず Redis RCEとして、CONFIG SET コマンドを悪用し、crontabエントリ、PHPウェブシェル(/app/public/uploads/shell.php)、SSHキーを注入する。続いてブロックデバイスへのアクセスを試みてraw diskを読み取り、Dockerコンテナ脱出を経てリバースシェル(ポート4444でbash、ポート8888でPython)を展開する。 情報窃取フェーズでは、.env ファイルやStrapi設定ファイル、PEM/keyファイルを収集し、Redisの完全ダンプとKubernetesシークレットを抽出する。また、ハードコードされた認証情報(user_strapi / 1QKtYPp18UsyU2ZwInVM)でPostgreSQLへの不正接続も試みる。最終的に /tmp/.node_gc.js への永続インプラントを書き込み、144.31.107.231:9999 のC2サーバーと通信を確立する。C2エンドポイントは /c2/<id>/(約5分間のC2コマンドポーリング)、/db/<id>/(データベース窃取)、/shell/(3秒間隔の永続シェルセッション)に分かれており、インプラントが残存している限り攻撃者は継続的なリモートアクセスを維持できる。 標的と攻撃者の意図 攻撃者が特定の企業を狙っていたことは、コード内に埋め込まれた手がかりから明らかだ。暗号資産決済プラットフォームであるGuardarianに関連するモジュール名や、HOT_WALLET、COLD_WALLET、MNEMONIC といったウォレット関連の文字列の探索が確認されている。また、永続インプラントの書き込み条件がホスト名「prod-strapi」に限定されていることから、攻撃者がターゲットの本番環境構成を事前に把握していた可能性が高い。Jenkins CI/CDパイプラインへの言及もあり、開発インフラ全体を侵害しようとする意図がうかがえる。 見分け方と推奨される対応策 正規のStrapiパッケージは @strapi/ スコープ付きで公開されているが、悪意あるパッケージはスコープなしで公開することで開発者の信頼を悪用していた。このタイポスクワッティングおよびブランドなりすましの手口は、依存関係を機械的にインストールする開発者にとって見分けにくい。 侵害が疑われる場合、/tmp/.node_gc.js、/tmp/vps_shell.sh、/app/public/uploads/shell.php の存在確認と削除、crontabにおける node_gc 参照の除去、IPアドレス 144.31.107.231 への通信遮断を直ちに行う必要がある。また、JWT シークレット、データベース認証情報、APIキーを含む全認証情報のローテーションが推奨される。予防策としては、npm audit や Snyk、Dependabot の導入、組織ポリシーによるスコープなしパッケージの拒否設定が有効だ。

April 5, 2026

TigerFS: PostgreSQLデータベースをUnixファイルシステムとしてマウントできる実験的OSSツール

概要 TigerFSは、PostgreSQLデータベースをディレクトリとしてマウントし、ls、cat、find、grepなどの標準Unixコマンドでデータを操作できる実験的なオープンソースファイルシステムだ。TigerData(旧Timescale)がMITライセンスのもとGitHub(timescale/tigerfs)で公開したこのツールは、APIやSDKを介さずにデータベースとやり取りできる新しいアプローチとして開発者の注目を集めている。AIエージェントがデータベースの状態を共有・管理する用途でも活用できる設計になっており、AI開発との親和性も意識されている。 2つの動作モード TigerFSは「ファイルファースト」と「データファースト」の2つのワークフローをサポートしている。ファイルファーストモードでは、開発者がファイルをディレクトリ構造(todo / doing / done など)で整理し、アトミックな書き込みと自動バージョニングによって並行アクセスや状態管理を実現する。AIエージェントが複数の状態を共有する際に特に有用なアプローチだ。 データファーストモードでは、既存のPostgreSQLデータベースをマウントして、Unixツールでデータを探索できる。ファイルシステムのパスにフィルタやソート条件を含めることでデータベースクエリに変換されるため、SQLを書かずにデータを取得・確認できるのが特徴だ。 技術的な詳細 LinuxではFUSE、macOSではNFS経由でマウントに対応しており、外部依存なしで動作する。各ファイルはデータベースの1行に対応し、ACID保証が維持される。あらゆるPostgreSQLインスタンスやマネージドサービスと連携可能で、既存のデータベース環境にそのまま組み込める点も評価されている。開発者コミュニティからはパフォーマンス特性や制限事項への関心が寄せられており、小規模データセットの管理や設定ファイル的な用途において有用との声も上がっている。 展望 TigerFSはまだ実験的なプロジェクトとして位置づけられているが、データベースへのアクセスを「ファイル操作」という直感的なインターフェースで統一するというコンセプトは、特にAIエージェントがファイルシステムを通じてデータを読み書きするユースケースで新たな可能性を示している。SQL不要のデータ探索を実現するこのアプローチが、今後どのような形で発展するか注目される。

April 5, 2026

Neovim v0.12.0リリース — 内蔵プラグインマネージャー、LSP強化、Lua HTTP APIなど多数の新機能

概要 Neovimは2026年3月29日、メジャーリリースとなるv0.12.0を公開した。今回の最大のハイライトは、外部ツールへの依存を不要にする組み込みパッケージマネージャー vim.pack の導入だ。これまでlazy.nvimやpacker.nvimといったサードパーティのプラグインマネージャーに頼っていた管理フローを、Neovim本体で完結できるようになった。コミュニティからの反応はGitHub上で525件以上のリアクションを集めるなど、非常に好評を博している。 LSP・補完の大幅強化 LSPまわりの改善も今回の目玉だ。補完候補にカラーシンボルのプレビューやインライン補完が追加されたほか、新しい対話型コマンド :lsp によってLSPクライアントを一元管理できるようになった。コードレンズが仮想行として表示されるよう変更されたことで視認性も向上した。さらに textDocument/diagnostic・ textDocument/documentColor・ワークスペース診断・動的登録など多数のLSP仕様への対応も追加されている。デフォルトキーバインドには grt(型定義へジャンプ)と grx(コードレンズ実行)が新たに加わった。 Lua APIの拡充とHTTP対応 Lua APIにも注目すべき追加がある。vim.net.request() の追加により、外部ライブラリを使わずにNeovim内から直接HTTPリクエストを発行できるようになった。そのほか vim.list.unique()・vim.list.bisect() などのリスト操作関数、vim.text.diff()(旧 vim.diff)、フローティングウィンドウへのステータスライン表示・タブページ間移動のサポートなども追加された。新オプションとして 'autocomplete'・'pummaxwidth'・'pumborder'・'busy' などが導入されている。 パフォーマンス改善と実験的Zigビルド パフォーマンス面では、i_CTRL-R によるレジスタ挿入が従来のユーザー入力シミュレーション方式から貼り付け方式に変わり約10倍高速化。LPeg実装によりglobパターンマッチングが約50%高速化された。LSPはトークンリクエストを表示中のビューポートに限定するよう最適化され、帯域幅の節約にも貢献している。また実験的機能としてZigベースのビルドシステムが導入された。 破壊的変更と注意点 既存の設定に影響する破壊的変更もいくつか含まれる。vim.diagnostic.disable() などの旧来のDiagnostics APIが削除され、JSONのnull値が nil から vim.NIL に変更された。セマンティックトークン関数が start()/stop() から enable() にリネームされるなど、プラグイン開発者は対応が必要になる場合がある。Windowsでは外部コマンド実行時にカレントディレクトリを検索しなくなるセキュリティ強化も施された。アップグレード前に公式チェンジログでの確認が推奨される。

April 5, 2026

Git 2.52リリース——初のRustコード統合とGit 3.0への準備が本格化

概要 分散バージョン管理システムGitの最新メジャーフィーチャーリリースであるGit 2.52が公開された。今回のリリースの最大の特徴は、WITH_RUSTビルドフラグを介してRustで書かれたコードがGitリポジトリに初めて統合されたことだ。現時点では任意の選択肢だが、Git 3.0ではRustが必須依存関係となる予定であり、今回はその布石となる重要なマイルストーンと位置付けられる。Git 3.0は2026年末のリリースを目標としており、2.52はそれに向けた大規模な準備作業を含む。 Rustコードの初統合 Git 2.52ではWITH_RUSTビルドフラグを指定してビルドすることで、Rustで実装された内部機能を利用できる。現時点でRustが担うのは主にパックファイル処理で使われる可変長整数エンコード・デコードだが、CコードからRustヘルパーを呼び出すためのインフラが整備された。Rustがなくてもビルド・動作は可能で、Cのフォールバック実装が提供される。また、SHA-256相互運用性に関連する一部のコードもRustで実装が進められている。将来的にGit 3.0ではRustがビルド時の必須要件になる計画だ。 新コマンドと機能強化 Git 2.52では複数の新コマンドが追加された。git last-modifiedは指定パスに最後にコミットした祖先コミットを表示するコマンドで、GitHubの内部ツール「blame-tree」に由来する。リポジトリ履歴を一度だけ走査して追跡済みパスを除去していく設計により、従来のgit ls-tree + git log --max-count=1の組み合わせと比較して約5.5倍の速度向上を実現する。大規模リポジトリやモノレポで特に恩恵を受けやすい。 実験的なgit repoコマンドも追加された。git repo infoはオブジェクトフォーマット(SHA-1またはSHA-256)や参照タイプなどリポジトリレベルの設定を表示し、git repo structureはコミット・ツリー・ブロブ・タグ・参照のカウントなどリポジトリの構造統計を示す。参照管理関連ではgit refs list・git refs exists・git refs optimizeの各サブコマンドも追加されている。 パフォーマンス面ではgit describeが約30%高速化され、スパースチェックアウト環境のクリーンアップを行うsparse-checkout cleanサブコマンドや、ワイルドカードパス指定をBloomフィルタで扱えるようにする改善も含まれる。リポジトリのメンテナンス戦略としてgeometric戦略が追加され、パックファイルを等比数列的な大きさで管理することでCPUとI/Oのオーバーヘッドを削減できる。 SHA-256相互運用性とGit 3.0への道 Git 3.0の主要目標の一つはデフォルトハッシュをSHA-1からSHA-256へ切り替えることだ。Git 2.52ではSHA-1とSHA-256のリポジトリが相互にプッシュ・プルできるようにするための基盤整備が始まった。完全な相互運用性はGit 3.0を目指しているが、今回の作業はその大きな一歩となる。また、git initがデフォルトブランチとしてmainを使うようにする変更や、既存ユーザーへの移行ヒント表示といった準備も進んでいる。ビルドシステム面でも全オブジェクトを単一のlibgit.aアーカイブに統合する整理が行われ、Mesonビルドシステムへのドキュメントサポートも追加された。

April 4, 2026

GitHub Issuesの改良型意味ベース検索がGA、REST/GraphQL APIにも対応

概要 GitHubは2026年4月2日、GitHub Issues向けに改良した意味ベース検索(Improved Search for GitHub Issues)を正式に一般提供(GA)へ移行したと発表した。本機能は2026年1月のプレビュー提供を経て2月に拡張され、今回の正式リリースに至った。従来のキーワードマッチングに依存した検索とは異なり、自然言語による概念的な理解を基に関連イシューを発見できる点が特徴で、検索に成功したケースでは上位3件以内に目的のIssueが含まれる割合が66%から75%へ改善されたと報告されている。 主な機能 本機能には主に以下の要素が含まれる。 自然言語検索: キーワードの完全一致がなくても、意味的に関連するIssueを返す。 検索スコープ: 個別リポジトリ内、および Issues ダッシュボードを通じた複数リポジトリ横断の両方に対応。 ハイブリッド検索: 意味ベースとキーワードマッチングを組み合わせた検索モードを提供し、概念的に類似した結果と完全一致の結果を同時に返す。フィルターのみや引用符付きの検索語を使用した場合は従来の字句検索が適用される。 関連度順ソート: 結果はデフォルトで関連度順に表示される。 REST/GraphQL APIからの利用 既存のAPIエンドポイントに新しいパラメータを追加することで、この機能を利用できる。 REST API: /search/issues エンドポイントに search_type=semantic(意味ベース)または search_type=hybrid(ハイブリッド)を指定する。 GraphQL API: searchType 引数に SEMANTIC または HYBRID を指定する。 なお、意味ベース検索およびハイブリッド検索のクエリにはレートリミットが適用され、1分あたり10リクエストまでに制限される。 その他の改善 今回のリリースでは検索機能のGA化に加え、テンプレート編集の改善、「@」メンションを用いたアサイニーフィルタリング、複数リポジトリ修飾子の処理改善、折りたたみセクション内でのMermaidダイアグラム描画サポートなども同時に提供されている。

April 4, 2026