2026年03月07日の技術動向

Go標準ライブラリ — UUIDパッケージが「Likely Accept」ステータスに到達

Go issue #62026として登録されたUUIDパッケージの標準ライブラリ採用提案が、Proposal-FinalCommentPeriod ラベルを取得した。事実上の採用確定に近い段階だ。

【補足】GoのProposalプロセスでは、Proposal-FinalCommentPeriod（FCP）ラベルが付与されると最終コメント期間（通常10日間）に入り、重大な反論がなければProposal-Acceptedに移行する。FCPはコアチームが「採用の方向で合意した」ことを示すシグナルであり、実装着手の前段階にあたる。

提案されているAPIの骨格はこうなっている。

package uuid

type UUID [16]byte

func New() UUID
func Parse(s string) (UUID, error)
var Nil UUID
var Max UUID
func (u UUID) Compare(v UUID) int

New() は内部で crypto/rand を使う設計だ。参照仕様はRFC 9562で、バージョン3・4・5に対応する。

【補足】RFC 9562は2024年に発行され、旧来のRFC 4122を更新した。v4はランダム生成、v5はSHA-1ハッシュベース、v3はMD5ハッシュベースのUUIDを定義する。v7（Unix時刻ベース、辞書順ソート可能）はRFC 9562で新たに追加されたが、初期実装への包含は未確定。Nil と Max は関数ではなく変数として公開される。uuid.Nil で直接参照できる。

Parse は従来より許容度が高い（more permissive）設計になっている。

なぜ今なのか

github.com/google/uuid はGoのサーバーサイド・DBアクセス系コードでほぼ必須のインポートになっていた。GitHubコード検索でも確認できるほど普及しており、そのAPIは数年間安定したまま変わっていない。

GoはUUID機能を長年サードパーティに委ねてきた。Python（uuidモジュール）、Java（java.util.UUID）、C#（System.Guid）はいずれも言語またはランタイムレベルでUUID機能を持つ。Goだけが異例の状態だった。

セキュリティの観点も重要だ。サードパーティパッケージが crypto/rand を正しく使っているかどうかは利用者が確認しなければならなかった。標準ライブラリに入ることで、暗号学的に安全な乱数生成が保証された実装をデフォルトとして提供できる。

github.com/google/uuid の位置づけが変わる

標準ライブラリに同等機能が入れば、新規プロジェクトでの google/uuid 採用動機は薄れる。既存コードの移行コストは低い。APIが安定していたためだ。ただし google/uuid 固有の拡張機能（v6・v7など）を使っているプロジェクトは移行判断が分かれる。

RFC 9562ではv7（Unix時刻ベース、ソート可能）が新たに定義されている。初期実装に含まれるかどうかが今後の議論の焦点になる。

go.mod のスリム化という波及効果もある。「標準ライブラリに入ったから外部依存を削れる」という判断がプロジェクト全体で起きると、UUIDはその最初の大きな事例になる。

GitHub Security Lab — LLMベース脆弱性スキャンフレームワーク「seclab-taskflow-agent」をOSS公開

GitHub Security Labが、LLMを使ったセキュリティ脆弱性スキャンのフレームワーク「seclab-taskflow-agent」をOSSとして公開した。数ヶ月の実運用で80件以上の脆弱性を報告済みで、そのうち約20件がすでに開示されている。報告された脆弱性の多くは認可バイパスや情報漏洩だ。「別ユーザーとしてログインできる」「他ユーザーのカートのPIIにアクセスできる」といった高インパクトなものが含まれる。

「1つの大きなプロンプト」ではなぜダメなのか

LLMのコンテキストウィンドウには上限があり、複雑な多段階タスクを1プロンプトで処理すると途中のステップが抜け落ちる。コンテキストウィンドウが大きいモデルでも同じ問題が起きる。

Taskflowの核心は、複雑なセキュリティ監査を「依存関係を持つタスクのチェーン」に分解する点だ。YAMLファイルでタスクを定義し、前のタスクの結果を次のタスクに渡す。

具体的な監査フローはこうなる。まずリポジトリを機能単位のコンポーネントに分割する。次に各コンポーネントのエントリポイント・想定権限・目的をLLMに収集させ、SQLiteに保存する。その文脈データをもとに、汎用的な問題提案タスクと、提案された問題を詳細に監査するタスクを実行する。

実行は以下のコマンド1つだ。

./scripts/audit/run_audit.sh myorg/myrepo

GitHub Copilotライセンスが必要で、中規模リポジトリで1〜2時間かかる。完了するとSQLiteビューワーが開き、audit_results テーブルの has_vulnerability 列でフィルタする。

同じプロンプトを複数コンポーネントに非同期で並列実行できる点も重要だ。コンポーネント固有の詳細をテンプレートで差し込む仕組みで、大規模リポジトリのスキャンを現実的な時間で完了させている。

CodeQLとの役割分担

CodeQLのような静的解析ツールは、事前に定義されたパターンやデータフローに基づく問題の検出が得意だが、認可バイパスのような「ロジックの問題」は、データフロー解析だけでは捉えにくい。

【補足】CodeQLはGitHub製のセマンティックコード解析エンジンで、コードをデータベース化してSQLライクなクエリ言語で脆弱性パターンを検索する。SQLインジェクションやバッファオーバーフローなどデータフローが明確な問題は得意だが、「AユーザーがBユーザーのリソースを操作できる」といったビジネスロジック上の認可ミスはクエリとして定式化しにくい。LLMはコードの意味的な理解が得意で、「このユーザーはこのリソースにアクセスすべきでない」という判断ができる。

GitHub Security Labはかつて同フレームワークをCodeQLアラートのトリアージに使っていた。そのときは「厳密で明確な指示と判定基準」をLLMに与えることでハルシネーションを抑制できた。汎用セキュリティ監査への拡張では、LLMの自由度を上げるほど偽陽性が増えるというトレードオフがある。タスクを細かく分割して各段階で検証可能にすることが、この問題への現実的な回答になっている。

Rust — 企業採用率48.8%、2025年State of Rust Surveyが「構造的な市場定着」を記録

2025年State of Rust Surveyは7,156件の回答を集め、企業採用率が48.8%に達したことを記録した。2023年の38.7%から2年間で10ポイント上昇している。調査チームはこれを「構造的な市場定着」と表現した。

日常的にRustを使う開発者は55.1%と4年間の追跡で最高値を記録した。生産的に書けると自己評価する割合も56.8%で、2022年の42.3%から大幅に改善している。学習コストの高さで知られてきた言語が、実際に使いこなせる開発者を増やしつつある。

用途の内訳を見ると、サーバーサイド・バックエンドが51.7%でトップだ。クラウドアプリケーション25.3%、分散システム22%が続く。組み込みやセキュリティだけでなく、一般的なバックエンド開発での採用が主流になってきている。

採用済み組織の84.8%が「目標達成に貢献した」と回答し、78.5%が「採用コストに見合った」と評価している。一方で31%が採用時の困難を認めており、ハードルがゼロになったわけではないとわかる。

コンパイル時間の問題は未解決のまま

課題として根強く残るのはコンパイル時間だ。27%以上が「深刻な問題」と指摘し、複数の調査サイクルにわたって同じ位置に居座っている。ビルド成果物のディスク使用量も上位の不満として挙がっている。この問題が解消されないまま推移すると、大規模モノレポを持つ企業での採用に天井が生まれる。

学習チャネルのLLMシフト

注目すべき変化として、学習・質問のチャネルがLLMにシフトしている兆候がある。ミートアップやフォーラムへの参加が減少し、自由回答のワードクラウドにChatGPT・Claude・Geminiが公式ドキュメントと並んで登場した。コミュニティ主導だったRustの学習文化が、AIアシスト型に移行しつつある。

採用を後押しした外部要因

米国連邦政府によるメモリセーフ言語の推奨が背景にある。NSAやCISAが2022〜2023年にかけてC/C++から離れるよう勧告を出し、政府系ソフトウェアサプライチェーンでRustが選ばれやすい状況が生まれた。Linuxカーネルへの採用（2022年）やAndroidのシステムコンポーネントへの組み込みも、企業の意思決定者に「本番で使える言語」という認識を与えた。

ForesterのアナリストはGoとの競合を指摘している。Rustの伸びは、既存のC/C++資産を持つ組織（組み込み・セキュリティ・インフラ）での置き換えが中心になっている。

Palus Finance (YC W26) — エージェンシーMBSを使ったスタートアップ向け資金運用サービスをローンチ

YC W26バッチのPalus Financeが、マネーマーケットファンド（MMF）一辺倒だったスタートアップ・トレジャリー市場に対して、エージェンシーMBSを活用した高利回り運用を提供し始めた。

問題の構造

スタートアップの資金繰りには特有のパターンがある。ラウンドで大きな資金を調達し、18〜24ヶ月かけてバーンレートに合わせて引き出す。この間、大半のキャッシュは「いつでも引き出せる状態」である必要はないにもかかわらず、ほぼ全額がMMFに置かれている。

Brex・Mercuryといった既存のスタートアップ向け銀行サービスのトレジャリー機能は、実質的に「証券口座を開設してMMFにスイープし、管理手数料を取る」だけだとPalusは指摘する。差別化を謳う競合の一つは2022年に9%の損失を出したとも言及しており、リスク管理の観点でも問題があった。

利回りの仕組み

MMFの利回りはSOFRにほぼ連動する。一方、短期フローティングレート型のエージェンシーMBS（政府機関保証付き住宅ローン担保証券）はSOFR+1〜1.5%のスプレッドが乗る。Palusはこのスプレッド分をスタートアップに渡す設計だ。

具体的には、Regan CapitalのMBSF ETFを通じて運用し、目標利回りは4.5〜5%。MMFの約3.5%と比較して1〜1.5ポイント高い。流動性は1〜2営業日。手数料はAUMの0.25%フラット。エージェンシーMBSはジニーメイ・ファニーメイ・フレディマックの政府保証が付いており、2008年に問題になったプライベートラベルMBSとは別物だ。

【補足】エージェンシーMBS（Agency Mortgage-Backed Securities）とは、米国政府系住宅金融機関（ジニーメイは政府直接保証、ファニーメイ・フレディマックは政府支援企業）が保証する住宅ローンを束ねた証券。2008年の金融危機で問題になったのは民間金融機関が組成したプライベートラベルMBSであり、エージェンシーMBSは元本保証の性質が異なる。

UXの設計思想

「2つのボタンと、増え続ける大きな数字」と表現しており、既存の銀行口座にPlaid経由で接続するだけで使える。ネオバンクを作るのではなく、既存の金融インフラの上に薄いレイヤーとして乗る構造だ。YC自体がこの問題を抱えており、バッチ内の複数スタートアップから同様の需要が集まったという経緯がある。

Linuxカーネル LTS — Greg Kroah-HartmanがLinux 6.6・6.12・6.18の延長サポートを発表

LinuxのstableカーネルメンテナーであるGreg Kroah-HartmanがLKML上で、複数のLTSブランチのサポート期間延長を発表した。2023年に「2年サポート」へ短縮された方針が、ユーザー・企業からのフィードバックを受けて部分的に撤回された形だ。

具体的な新スケジュールは以下の通りだ。

| ブランチ | 新EOL | サポート期間 | |----------|-------|-------------| | Linux 6.6 | 2027年末 | 約4年 | | Linux 6.12 | 2028年末 | 約4年 | | Linux 6.18 | 2028年末 | 約3年 |

一方で5.10と5.15は変更なく、2026年12月のEOLが維持されることになった。

2023年に「2年LTS」へ移行した際の理由はメンテナーの燃え尽き症候群だった。その問題が解消されたわけではないが、今回の延長は「多くの企業・グループとの議論」を経た判断だとKroah-Hartmanは説明する。旧来の6年サポートには戻っていない。しかし2年という厳しい上限を現行LTSブランチには適用しない、という実質的な方針転換だ。

LTSが重要な理由

LWN編集長のJonathan Corbetが指摘するように、「カーネルではほぼすべてのバグが、十分に巧みに利用されればシステムを侵害する脆弱性になりえる」のだ。カーネルはシステム上で唯一の特権的な位置にあるため、通常のバグが即座にセキュリティ上の脅威になる。

サーバーディストリビューション、Androidデバイス、組み込みアプライアンスといった製品群は、カーネルシリーズの移行に伴うハードウェアイネーブルメント・テスト・認証のやり直しを避けるために、長期のセキュリティ修正を必要としている。

上流と産業界の乖離が縮まった

Canonical（Ubuntu）は独自に最大12年のLTSカーネルを提供し、Red Hat Enterprise LinuxはRHEL 9で5.14、RHEL 10で6.12を10年以上バックポートし続ける。これらはkernel.orgのLTSとは独立した取り組みだが、裏を返せば「上流の2年サポートでは産業界のニーズを満たせない」という現実を示していた。今回の延長は、その乖離を上流側が認識した結果だ。

6.12はRHEL 10の採用カーネルでもある。kernel.orgが6.12を2028年末まで維持することで、RHELとの上流サポート期間の整合性が高まり、エンタープライズ向けディストリビューションの計画立案が容易になる。

5.10・5.15ブランチが2026年12月にEOLを迎えることで、これらに依存するプロジェクトは今年中に移行計画を確定させる必要がある。特に組み込み・産業機器分野では、カーネル移行の認証コストが大きく、移行先の選定が急務になる。

【警告】Linux 5.10はAndroid 11/12の共通カーネルベースとしても広く使われており、EOL後はセキュリティパッチが上流から提供されなくなる。Androidデバイスメーカーや組み込みベンダーは独自バックポートを継続するか、6.6以降への移行を選択する必要がある。

今日の傾向

GoがUUID issue #62026を「Likely Accept」に進め、github.com/google/uuid という長年の事実上標準をついに標準ライブラリが吸収しようとしている。同じ動きはLinuxカーネルLTSでも起きた。Greg Kroah-HartmanがLinux 6.6・6.12・6.18の延長サポートを発表し、「2年LTS」という2023年の方針を産業界からのフィードバックで部分的に撤回した。どちらも「サードパーティや独自対応に委ねていたものを上流が引き取る」という構造だ。

Rustの2025年State of Rust Surveyが企業採用率48.8%を記録し、サーバーサイド・バックエンドが用途の51.7%を占めるに至った。コンパイル時間の問題は27%以上が「深刻」と指摘したまま複数サイクルにわたって未解決だが、生産的に書けると自己評価する割合が2022年の42.3%から56.8%に上昇した。学習チャネルの変化も記録された。自由回答のワードクラウドにChatGPT・Claude・Geminiが公式ドキュメントと並んで登場し、コミュニティ主導だった学習文化がAIアシスト型に移行しつつある。

GitHub Security Labが公開した seclab-taskflow-agent は、80件以上の脆弱性報告という実績を持つ。CodeQLが「パターンに合致した問題」しか検出できないのに対し、認可バイパスのようなロジックの問題をLLMのタスク分割アーキテクチャで捉える設計だ。SQLiteに文脈データを蓄積し、GitHub Copilotライセンスで動く構成は、セキュリティ監査のLLM活用を「1プロンプトで投げ込む」段階から「検証可能なパイプライン」段階に引き上げようとしている。

参照記事

記録日: 2026-03-07