Programming Languages

概要 Djangoのスチアリングカウンシルは、リリース体制を刷新する提案「DEP 20（Django Enhancement Proposal 20）」を承認した。Carlton Gibson氏が8月10日付のブログで発表したもので、2028年1月にリリース予定の「Django 2028」から、年1回のリリースサイクルに移行する。バージョン番号にはリリース年をそのまま用いる方式となり、以降は「Django 2029」「Django 2030」のように命名される。従来のような細かいマイナーバージョン番号ではなく、リリース年が版番号を兼ねる形になる。 新リリースサイクルの詳細 新体制の核心は、すべてのフィーチャーリリースが一律3年間サポートされる点にある。内訳は、リリース後1年目は一般的なバグ修正、続く2年間はセキュリティ修正とデータ損失に関わる重大なバグの修正のみを提供するというものだ。これにより、常に3つのバージョンが同時にサポートされる状態が保たれ、ユーザーは急いでアップグレードする必要がなくなり、サポート期間内であれば自分のペースで段階的に移行できるようになる。またサードパーティパッケージの開発者にとっても、対応すべきバージョンの見通しが立てやすくなるという利点がある。各リリースはリリース時点で最新の3つのPythonバージョンをサポートし、初年度中に新しいPythonバージョンへの対応も追加される。 LTS廃止の背景 これまでDjangoは、通常のリリースと長期サポート（LTS）版を区別してきたが、新体制ではこの「LTS」という呼称自体が廃止される。全リリースが同じ3年間のサポート約束を得ることになるため、特定のバージョンだけを「長期サポート版」として特別視する必要がなくなるためだ。LWNの記事のコメント欄では、期限ベースのリリースが定期的なサイクルの維持に役立つとしてDjangoの新体制を好意的に受け止める声がある一方、Symfonyのリリース体系（半年ごとのマイナーバージョンと2年ごとのメジャーバージョン、3年間のバグ修正と4年間のセキュリティサポートを伴うLTS版）を引き合いに出し、それを好ましいと評価する意見も見られた。 移行スケジュール 新体制への移行は段階的に行われ、2028年より前のリリースについては既存のサポート約束がそのまま維持される。具体的には、2026年8月リリース予定のDjango 6.1は2027年12月までサポートされ、2027年4月リリース予定のDjango 6.2はLTSとして2030年4月までサポートされる。そして2028年1月にリリースされるDjango 2028から新方式が適用され、2030年12月までサポートされる予定だ。続くDjango 2029は2029年1月のリリースから2031年12月までサポートされる見込みで、以降は毎年1月に新バージョンがリリースされるサイクルが定着していく。

概要 長年開発が続けられてきたOpenJDKの「Project Valhalla」が、大きな節目を迎えた。JDK 28にプレビュー機能として統合されたJEP 401「値オブジェクト（プレビュー）」は、Javaに新しいvalue修飾子を導入し、アイデンティティを持たないクラスインスタンス「値クラス（value class）」を定義できるようにする。最も注目すべき変更点は、値クラスのインスタンスに対して==演算子の挙動が再定義されることだ。従来のアイデンティティ・オブジェクトでは、==は「同一のオブジェクトを参照しているか」を判定していたが、値クラスでは「同じクラスで同じフィールド値を持つかどうか」を判定するようになる。この機能はプレビュー段階のため、--enable-previewフラグを付けてコンパイル・実行する必要がある。 値クラスの仕組みと==演算子の変更 値クラスは、複素数やピクセルの色、日付のように、本質的にはデータを運ぶためだけに存在する小さなクラスを想定した機能だ。value修飾子を付けて宣言すると、すべてのインスタンスフィールドが暗黙的にfinalとなり、コンストラクタが完了するまでにすべてのフィールドへの代入を終える必要があるという厳格な初期化ルールが課される。またインスタンスメソッドの同期化（synchronized）も制限される。レコード（record）にもvalue修飾子を付けられる。 最大の変更は==の意味だ。たとえば次のようなコードでは、従来ならp1とp2は別々のオブジェクトなのでp1 == p2はfalseになっていたが、値クラスではtrueと評価される。 Point p1 = new Point(3, 4); Point p2 = new Point(3, 4); assert p1 == p2; // true: 同じクラス、同じフィールド値 もっとも、これはequals()メソッドの使用を放棄する招待ではなく、「オブジェクトの比較にはequals()を使うべき」という通常のアドバイスは引き続き有効だとされている。 Project Valhallaの背景 JEP 401は、この問題を「開発者が意図することと、Javaが保証すること間の不一致」として位置づけている。複素数やピクセル色、日付を表す小さなクラスの多くは単なるデータの入れ物として使われているにもかかわらず、通常のJavaオブジェクトはアイデンティティによって定義されており、コンストラクタ呼び出しのたびに区別可能な別個のオブジェクトが生成されてしまう。この不一致を解消するため、OpenJDKの「valhalla-dev」メーリングリストで長年にわたり議論が重ねられ、今回のプレビュー実装に至った。 パフォーマンスへの最適化と注意点 値クラスの導入によって期待される主な成果は、JVMによる最適化だ。アイデンティティを持たないことで、JVMは値オブジェクトを構成フィールドに分割する「スカラー化」や、フィールドや配列要素にコンパクトな表現で直接格納する「フラット化」といった最適化を適用できるようになる。ただし、こうした最適化が常に適用されるとは限らず、適用されない場合は通常のオブジェクト割り当てにフォールバックする。フラット化はアトミック性の制約を受けるため、典型的なプラットフォームでは64ビット程度までのコード化が現実的とされる。またベンチマーク上の性能向上が保証されているわけではない点にも注意が必要だ。一方でセキュリティ面では、==やidentityHashCodeが間接的にプライベートフィールドの値を露出させる可能性があることや、大規模な値オブジェクトのツリー同士を比較する処理が無制限に時間を要しうることも指摘されている。 開発者への影響と今後の展望 開発者にとっては、新しいvalue修飾子の使い方を習得するだけでなく、==やsynchronizedの挙動変化によって予期しない動作に遭遇する可能性がある。またプリミティブラッパー型やLocalDateなど、JDKが提供する複数の「値ベース」クラスも今後この仕組みへ移行していくとみられる。関連するJEP 539「JVM内の厳格なフィールド初期化」では、バイトコード検証によって値クラスの構築ルールを強制する仕組みが導入される予定で、コンパイラの警告機能も拡充される見込みだ。今回のプレビューはJavaのオブジェクトモデルに重大な変化をもたらすものと認識されているが、開発者が実際に驚きに直面する頻度は限定的で、対応可能な範囲にとどまると見られている。

概要 MicrosoftとUno Platformは、.NET向け2Dグラフィックスライブラリ「SkiaSharp」の4系における最初の安定版として、バージョン4.148.0と4.150.0をリリースした。あわせて4.151.0のプレリリース版も公開されている。今回の刷新で最も重要なのは、パッケージのバージョン付けをChromeのリリースチャンネルが使用する上流Skiaのマイルストーンに合わせる新方針を採用した点だ。安定版はChromeのStable/Extended Stableマイルストーンに、プレリリース版はChrome Betaに追従する形となり、従来の3.119ブランチが上流から数マイルストーン遅れていた状況を解消し、更新の予測可能性を高める狙いがある。 技術的な詳細 最初の安定版となる4.148.0では、バンドルされるSkiaエンジンをm148に更新し、OpenTypeの可変フォント軸制御やカラーフォントのパレット選択に対応したほか、SKWebpEncoderによるアニメーションWebPエンコードを新たに導入した。また共有ネイティブオブジェクトのライフサイクル管理を見直し、use-after-freeによる障害を低減している。パフォーマンス面では、GPUレンダリングのUIで最大24%の性能向上、CPUベースのPerlinノイズシェーダーでは約6倍の高速化が報告されている。 7月7日にリリースされた4.150.0ではSkia m150へと進み、SKPaint.GetFastBounds()をはじめとするグラフィックス診断APIや画像フィルタリング関連のメソッドが追加されたほか、SKSurface.Canvasラッパーをキャッシュしてアロケーションを削減する改善が加えられた。一方でこのバージョンでは、.NET InteractiveおよびPolyglot Notebooks統合パッケージが削除されている。 プレリリース段階の4.151.0はSkia m151に対応し、ホットパスにおけるP/Invoke呼び出しをマネージドな整数演算に置き換えたほか、アロケーションフリーなReadOnlySpanオーバーロードを追加した。さらに.NET WebAssembly向けにEmscripten 5.0.6を同梱するなど、Web/WebAssembly方面での最適化も進められている。 破壊的変更と移行における注意点 今回のリリースでは互換性に関わる変更も含まれている。SKPaintの非推奨テキスト・フォント関連メンバーはコンパイルエラーとなるため、開発者はSKFontへの移行が必須となる。既存プロジェクトでSkiaSharpをアップグレードする際は、この非推奨APIの利用箇所を事前に洗い出しておく必要があるだろう。上流Skiaのマイルストーンに追従する体制により、今後は最新のSkia機能や修正がより速やかに.NETエコシステムへ反映されることが期待される。

概要 Python Software Foundationは8月5日、Python 3.14系の7番目のメンテナンスリリースとなる「Python 3.14.7」と、3.13系の15番目のメンテナンスリリースとなる「Python 3.13.15」を公開した。リリースを主導したThomas Wouters(トーマス・ワウターズ)によると、3.14.7には86名以上のコントリビューターによる約499件のバグ修正・ビルド改善・ドキュメント変更が含まれており、3.13.15にも約400件の修正が反映されている。両バージョンとも前回のメンテナンスリリース（3.14.6、3.13.14）以降に蓄積された不具合の解消が中心で、大きな新機能追加はない定期メンテナンスの位置づけとなる。 技術的な詳細 今回のリリースで注目すべき点の一つが、実験的JITコンパイラの扱いだ。Python 3.14系ではWindowsおよびmacOS向けの公式バイナリリリースにおいて、この実験的JITコンパイラのビルドへの対応が追加されている。3.14系はこのほか、フリースレッド対応（PEP 779）の正式サポート、アノテーション評価の遅延処理（PEP 649）、f文字列に似た構文を持つテンプレート文字列リテラル（PEP 750）、標準ライブラリでの複数インタプリタ利用（PEP 734）、Zstandard圧縮アルゴリズム対応（PEP 784）といった機能を備えており、今回のマイナーアップデートもこれらの基盤の上に積み重なる修正群となっている。 もう一つの大きな変更が、リリース成果物の検証方式だ。PEP 761に基づき、Python 3.14以降の公式リリースでは従来のPGP署名の提供が廃止され、代わりにSigstoreを用いた検証が採用されている。Sigstoreは短命な証明書とトランスペアレンシーログを組み合わせた比較的新しい署名基盤で、鍵管理の負担を減らしつつ改ざん検知の信頼性を高める狙いがある。ダウンロードはWindows、macOS、Android、ソースコードなど複数形式で提供されており、詳細な変更点は公式ドキュメントの「What’s New in Python 3.14」やPEP 745（3.14のリリーススケジュール）、PEP 719（3.13のリリーススケジュール）で確認できる。

概要 JetBrainsは8月4日、IntelliJ IDEAが持つJavaおよびKotlinの言語解析エンジンをLanguage Server Protocol(LSP)経由で外部エディタに提供するプレビュー版拡張機能「Java & Kotlin by IntelliJ IDEA」を公開した。これにより、VS CodeやCursorといったIntelliJ IDEA以外のエディタでも、同IDEが培ってきた高精度なコード解析やリファクタリング機能を利用できるようになる。拡張機能はVisual Studio MarketplaceおよびOpen VSXレジストリから入手可能で、Maven・Gradle・Bazelでビルドされたプロジェクトや、Java/Kotlin混在プロジェクトに対応する。 技術的な詳細 拡張機能はLSPを介してIntelliJ IDEAのバックエンド解析エンジンをそのまま呼び出す構成で、スマートなコード補完、シンボルナビゲーション、コード解析、リファクタリング、エディタ支援に加え、Debug Adapter Protocol(DAP)ベースのデバッグ機能も備える。プレビュー期間中は無料で利用できるが30日間の評価期間制限が設けられており、正式版としての継続利用にはIntelliJ IDEA Ultimateのサブスクリプションが必要になる見込みだ。 背景と狙い これまでIntelliJ IDEAの強力な言語解析はJetBrains製IDE内に閉じた機能であり、VS CodeやCursorのユーザーはTypeScriptベースの軽量な言語サーバーに頼らざるを得なかった。今回のLSP対応は、エディタの選択によらずJetBrainsの解析エンジンを利用可能にすることで、この差を埋める狙いがある。特にAIコーディングエージェントが多くの実装作業を担うようになり開発者自身が手作業でコードを編集する機会が減る中、エージェントが参照する解析結果がより高速かつ決定論的になることで、無駄なトークン消費を抑えられる点をJetBrainsは利点として挙げている。 今後の展望 JetBrainsはターミナルベースのエージェント型ワークフローへの対応も実験的に進めており、近く有望な結果を公開する予定だとしている。VS CodeやCursorのようなエディタ上でAIエージェントによる開発が一般化しつつある中、IntelliJ IDEA由来の高精度な言語解析がエージェントの精度向上にどう寄与するかが今後の焦点となりそうだ。

概要 Spring Frameworkの生みの親として知られるRod Johnson氏らが開発するJVM向けAIエージェントフレームワーク「Embabel」が、正式に1.0のGeneral Availabilityに到達した。JavaやKotlinの開発者が、プロンプトやツール呼び出しを手作業でオーケストレーションするのではなく、エージェントをゴール・アクション・両者をつなぐ条件から成る型付きドメインオブジェクトとして定義できる点が最大の特徴だ。Johnson氏自身もSNSでリリースを発表し、大きな反響を呼んでいる。 GOAPによる動的な計画 Embabelを他のエージェントフレームワークと区別する中心的な仕組みが、ビデオゲームAIに由来する概念「Goal-Oriented Action Planning(GOAP)」の採用だ。あらかじめ決められたスクリプトに従うのではなく、エージェントは前提条件と効果が定義された利用可能なアクション群を与えられ、プランナーが実行時にゴールを満たすアクションの並びを探索する。途中で状況が変化した場合もプランナーが再評価を行い、開発者があらゆる分岐をあらかじめ想定しておかなくても代替の経路を見つけられるという。 Spring AIとの関係とモデルの柔軟性 Embabelは、Springチームが提供するモデル呼び出し・ツール呼び出しライブラリ「Spring AI」の上に構築されている。公式アナウンスでは「Spring AIがServlet APIの水準に位置するのに対し、EmbabelはSpring MVCのような存在だ」と説明されており、開発者は実装の詳細を自前でパースするのではなく、ゴールとアクションを宣言的に記述できる。またモデル面では、OpenAI、Anthropic、Gemini、Bedrock、Mistral、DeepSeekや自前ホスティングのモデルをサポートし、個々のアクションを特定のモデルにルーティングしたり、コストや性能に応じたロールベースのエイリアスを使い分けたりできる。 他フレームワークとの比較と今後 記事では、あらかじめノードとエッジを定義するグラフ指向の「LangGraph」、アクターモデルによるインフラと耐障害性を重視する「Akka Agentic Platform」、Kotlinの言語機能を活かしたJetBrainsの「Koog」といった競合との違いにも触れられている。Embabelは実行時にプランを組み立てる点でこれらと一線を画す。Spring Bootを使うチームにとって、今回の1.0リリースは「様子見」から「実際に評価してみる」段階への転換点であるとされている。

概要 Vercelは8月3日、Reactフレームワーク「Next.js」の最新バージョン16.3を正式リリースした。今回の目玉は、複雑なアプリケーション開発時にメモリを使い果たしてNode.jsがクラッシュし「FATAL ERROR」だけが残るという、開発者を長年悩ませてきた問題への対策だ。バンドラーTurbopackにディスクキャッシュとメモリ削減機能がデフォルトで有効化され、開発サーバーの実行時メモリ使用量が最大90%削減された。実際に自社サービスで検証したところ、社内ダッシュボードでは21.5GBから2GBへ(約90%減)、nextjs.org自体でも4.6GBから840MB(約82%減)にメモリ使用量が減少したという。The Registerの報道によれば、外部の開発者からも「4GBから1.5GBへ」「20GBから5GBへ」削減されたといった報告が寄せられており、Next.jsは2026年の年間ダウンロード数が10億を突破し前年(約5.2億)からほぼ倍増するなど、利用が急拡大する中でのパフォーマンス改善となる。 技術的な詳細 メモリ削減に加えて、ビルド高速化の恩恵も大きい。16.1で導入されたディスクキャッシュ機能がnext buildにも適用され、CI環境での再ビルドではキャッシュがヒットした場合に最大5.5倍高速化した事例もあるという。型チェック面では、先月リリースされたばかりのネイティブ移植版「TypeScript 7」との統合に対応し、pnpm add -D typescript@^7で依存関係を更新するだけでnext build時の型チェックが高速化する。Microsoftの発表ではTypeScript 7は大規模プロジェクトで8〜12倍のビルド高速化を実現しているとされる。ただしAchromatic社の移行ガイドは、Drizzle MCPサーバーなどTypeScriptコンパイラAPIに依存するツールが@typescript/typescript6互換パッケージを別途必要とする場合がある点や、新しいキャッシング機能・ナビゲーション機能の採用はバージョンアップとは別コミットで行い、問題発生時に切り分けやすくすることを推奨している。 このほか、Webストリームからネイティブ Node.jsストリームへの置き換えによりApp Routerのサーバーサイドレンダリングが高負荷時に最大22%多くのリクエストを処理できるようになったほか、静的アセットのデプロイ間キャッシュ再利用、catchErrorによるカスタムエラーバウンダリ、Turbopackでのグロブインポート対応、next/root-paramsによるルートパラメータへの簡易アクセスなど、既存アプリがコード変更なしに恩恵を受けられる改善が多数含まれる。 Instant Navigationsとその他の新機能 オプトイン機能としては、SPAのような即時応答性をサーバー駆動型のNext.jsにもたらす「Instant Navigations」機能群が導入された。cacheComponentsとpartialPrefetchingの2つのフラグを有効にすることで利用でき、遅いナビゲーションを自動検出するDevTools「Instant Insights」、リンクごとにプリフェッチ範囲を細かく制御できる「Partial Prefetching」、ビルド時に事前レンダリングされなかったURLに対して初回訪問時から即座にローディングシェルを表示できるよう改良されたISR、ローディング状態を可視化する「Navigation Inspector」、ナビゲーションの応答性低下を検出するPlaywright用テストヘルパーinstant()などが含まれる。さらに実験的機能として、Babelを介さずTurbopack内で直接動作するRust版React Compiler(v0での計測でコールドビルド時34%、ウォームビルド時46%の高速化)や、ネットワーク切断時に処理を保留し再接続後にリトライするuseOfflineによるオフライン耐性機能も追加されている。

概要 npmの生みの親であるIsaac Schlueter氏や、npm CLIチームの元メンバーDarcy Clarke氏、Ruy Adorno氏らが2024年に立ち上げたセキュリティ重視の次世代JavaScriptパッケージマネージャ「vlt」が、2026年8月4日にバージョン1.0へ到達した。同時にnpmミラーレジストリとプライベートレジストリをホスティングするサービスも一般提供を開始し、vltは単体のCLIツールから「end-to-end platform」へと拡張した。開発チームは「agents are the future of software development」と述べ、AIエージェントによる開発が主流となる時代に適した、高速かつ信頼性の高いパッケージ管理基盤の必要性を強調している。 技術的な特徴 vlt CLIはinit、install、build、run、publishといった標準的な操作でnpm・pnpm・yarn・bun・denoなど既存ツールとの互換性を保ちつつ、依存関係グラフを直接検索できる60種類以上の「pseudo selector」を新たに搭載した。このうち約30種類はセキュリティ用途に特化しており、マルウェア混入の疑い、既知の脆弱性、ライセンス条件、メンテナンス状況といった観点で依存パッケージを絞り込める。また:host(local)機能を使えば、ローカルマシン上の複数プロジェクトを横断して依存関係を一括照会できるほか、インストール時にはスクリプト実行前のダウンロードと選別的なスクリプト実行を分離することで、悪意あるインストールスクリプトによるサプライチェーン攻撃のリスクを抑える設計になっている。 ホスト型レジストリサービス 新たに一般提供が始まったホスト型レジストリは、npmレジストリAPIとの後方互換性を保ちながら、エッジインフラを活用した配信によりクリーンインストールがnpm比で最大38%高速になるとしている。これはAIコーディングエージェントが使い捨てのサンドボックス環境を頻繁に立ち上げるようなワークロードを念頭に置いた最適化とみられる。料金面では「generous free tier」を用意して新規ユーザーの導入障壁を下げつつ、スコープ付きの非公開パッケージを無制限に利用できる点も特徴だ。セキュリティ面では、パッケージのマニフェスト検証による形式チェックに加え、OSVなど公開脆弱性データベースの情報を取り込んで既知の悪質なパッケージを事前にブロックする仕組みを備える。vltはこれまでに27万5000件以上のパッケージバージョンを調査し、そのうち25%超が依然として公開状態にある危険なパッケージであることを確認したとしている。 背景と今後の展望 vltはOpenJS Foundationにシルバーメンバーとして参加するなど、JavaScriptエコシステム全体との連携も進めてきた。npmの生みの親自らが、サプライチェーン攻撃の多発やAI駆動開発への移行という業界の変化を踏まえて新たなパッケージ管理基盤を構築している点は、開発者コミュニティから注目を集めている。今回の1.0リリースとホスト型レジストリの一般提供により、vltはnpmの単なる代替ツールから、セキュリティとパフォーマンスを軸にした包括的な開発者向けエコシステムへの転換を本格化させる段階に入ったといえる。

概要 Vercel Labsは、人間の開発者ではなくAIエージェントがコードを読み書き・修復することを前提に設計された、実験的なシステムプログラミング言語「Zero」を発表した。Chris Tate氏が主導するこのプロジェクトは、「エージェントにとってより速く、より小さく、より使いやすく、修復しやすい」コード生成・保守を目標に掲げている。現在のバージョンはv0.3.4で、GitHub上ですでに5,200以上のスターを獲得している。 技術的な特徴 Zeroの最大の特徴は、v0.3.0で導入された「グラフファースト」構造にある。従来のプログラミング言語がテキストファイルをコンパイラへの入力とするのに対し、Zeroではバイナリ形式のzero.graphファイルがコンパイラの本体データとなり、拡張子.0のテキストファイルはあくまで人間が読むための「投影（プロジェクション）」として扱われる。開発者やエージェントはzero queryやzero patchといったコマンドでグラフを操作し、グラフのハッシュ値によって古い状態への編集を防ぐ仕組みも備える。 もう一つの柱が、機械可読なツールチェーンだ。すべてのzeroサブコマンドは共通の--jsonフラグを持ち、標準化された診断情報を出力する。エラーには「NAM003」のような安定したコードが付与され、型付きの修復メタデータが紐づく。特にzero fix --plan --jsonは、エージェントが受け入れ・編集・却下を選択できる修復プランを機械可読な形式で返す点が特徴で、自動修正を無条件に適用する「盲目的な自動修復」を避ける設計になっている。 さらに、外部システムにアクセスする関数はWorldという明示的なケーパビリティを引数として受け取ることをコンパイラが強制する「エフェクト追跡」も採用されている。これにより、関数のシグネチャを見るだけで副作用の有無が判別できる。ファイル拡張子は.0、ライセンスはApache 2.0で、Linux・macOS・Windows向けのネイティブバイナリを生成できる。Hello Worldプログラムはミリ秒単位でコンパイルされ、バイナリサイズは16.2KiBに収まるという。 設計思想と開発の変遷 Zeroの開発は急速なバージョン更新を繰り返してきた。v0.1.4で行（row）構文を導入し、v0.2.0で.0ファイルを主役に据え、v0.3.0でテキスト入力そのものを完全に廃止するという大きな方針転換を行っている。既存コードの移行にはzero importコマンドを使い、zero exportやzero verify-projectionによってレビューやCIでの検証もサポートする。v0.3.2ではインポート速度が約12倍高速化され、移行コストの低減が図られた。 言語としての立ち位置は、ZigとRustの中間に位置づけられる。Rustが持つ借用チェッカーの成熟度や豊富なエコシステムよりもバイナリの最小性を優先し、Goの並行処理プリミティブよりも依存関係のないアーティファクト生成を重視した設計となっている。 コミュニティの反応と今後 Hacker Newsではすでに賛否が分かれている。ケーパビリティシステム自体を「今さら目新しくない」と切り捨てるコメントがある一方、「重要なのはエージェント向けだという点だ」と反論する声もあった。また、「エージェントが得意な言語は学習データに含まれているものに限られる」という採用への懸念も出たが、SvelteのようなプロジェクトでもAIが大規模な破壊的変更に対応できていることを踏まえ、学習データへの依存は懸念されているほど大きくないとの指摘もある。 Vercel Labs自身もZeroはあくまで実験段階のプロジェクトであるとし、破壊的変更が今後も続く可能性を明言している。本番環境や機密データを扱うシステムでの利用は避け、隔離された環境での試用を推奨している。

概要 Rustのコンパイラや標準ライブラリを管理する5つのチームは8月5日、rust-lang/rustモノレポへの貢献を対象としたLLM利用に関する公式ポリシーを採択したと発表した。基本方針は「質問への回答、分析、精緻化、チェックには良いが、コード生成はダメ」というもので、LLMとの対話を通じて自身の理解を深めたり、テキストの分析・要約、バグ発見の補助、翻訳支援に使ったりすることは歓迎する一方、LLMにコードを生成させてそのままPRとして投稿する行為には強い制限を課している。なお、このポリシーはあくまでrust-lang/rustリポジトリに限定されたものであり、Rustプロジェクト全体としての公式見解ではない点が明記されている。 ポリシー採択の背景 チームがこの方針を採択した背景には3つの課題があるという。第一に、これまで「磨き上げられたPR」は著者の努力や献身の指標として機能してきたが、LLMによって誰でも一見高品質なPRを作れるようになり、その指標が失われつつある。第二に、rust-lang/rustには現在1,281件ものオープンPRが存在し、レビュー体制はすでに逼迫している中で、LLMによる「弾幕」的なPR増加はレビュアーの精神的負担を急増させかねない。第三に、レビューでの指摘事項をそのままLLMに貼り付けて得た回答を投稿するといった機械的なやり取りは、時間の浪費であるだけでなく、著者とレビュアーの間の信頼関係を損なうと指摘されている。 具体的なルール 許可される利用としては、LLMとの非公開の対話による理解の補助、テキストの分析・要約、バグ発見の補助、そして開発者が母語で投稿しやすくするための翻訳支援が挙げられている。一方、LLMが生成したコードを投稿する場合は「事前に調整済みで、重要度が低く、高品質かつ十分にテストされている」ことが条件となり、テストの有無に関わらず必ずテストを添付する必要がある。コンパイラのソウンドネスに関わる変更については、既存の専門家を除いて禁止される。さらに、公開ドキュメントや診断メッセージの本文をLLMが生成することは全面的に禁止されており、診断ロジックの補助としての利用のみ条件付きで認められる。また、公開の場でLLMが生成したテキストを使う場合は、開示が必須とされ、隠すことは許されない。 コミュニティでの運用と今後の展望 運用面では、著者はLLM利用を自発的に申告することが求められ、今後PRテンプレートに使用有無を確認する項目が追加される見込みだ。レビュアーには、ポリシー違反が疑われるPRを理由を示さずに却下する権限が与えられる一方、疑いがある場合の報告は告発ではなく情報提供として扱われ、単なるスタイル上の違和感を証拠として扱わないよう配慮されている。Rustプロジェクトはコンセンサス(合意形成)によって運営されているため、今回のポリシーもトップダウンの一律禁止ではなく、コミュニティが共有する「深い専門知識の構築」「包摂的なコミュニティ」といった価値観に基づいて設計されたという。プロジェクト側は、LLM利用についてコミュニティ内で見解が一致しているわけではないと認めた上で、今後は利用実態のデータ収集やLLM関連ポリシーの承認を簡素化する専門サブチームの設立を検討するとしている。将来的には、チャットやフォーラム、他のリポジトリを含むプロジェクト全体へのポリシー拡大も視野に入れており、今回の方針は最終決定ではなく、経験を踏まえて進化させていく前提で設計されている。