Programming Languages

概要 C++向けの高速シリアライズライブラリ「Glaze」がバージョン7.2をリリースし、C++26のP2996リフレクション仕様への対応を正式に取り込んだ。P2996は2025年6月にC++26への採択が決定した標準コンパイル時リフレクション機能で、Glazeはこれを従来の__PRETTY_FUNCTION__解析や構造化バインディングに依存したハックの置き換えとして活用する。JSON、YAML、CBOR、MessagePack、TOMLなど幅広いフォーマットのシリアライズに対応するGlazeにとって、今回のアップデートはコンパイル時メタデータ取得の根本的な刷新となる。 P2996リフレクションで何が変わるか 最も大きな変化は、これまでシリアライズ不可能だった非集約型の自動処理が可能になった点だ。カスタムコンストラクタ・仮想関数・継承を持つクラスは、従来は手動でglz::metaによるメタデータ記述が必要だったが、P2996対応環境ではそれが不要になる。また、従来は構造化バインディングの制約から128メンバーが上限だったが、この制限も撤廃された。 さらに列挙型の自動文字列化にも対応した。これまではglz::metaの手書きが必要だったが、P2996環境ではreflect_enums = trueオプションを有効化することでColor::Greenが"Green"としてシリアライズされる（後方互換性維持のためデフォルトは従来通り整数値）。アクセス修飾子も無視できるため、privateメンバーを含む型も追加設定なしでリフレクション可能となった。内部実装ではstd::meta::nonstatic_data_members_ofとaccess_context::unchecked()を組み合わせて標準APIのみでメンバー情報を取得する。 特性 従来方式 P2996対応 最大メンバー数 128 無制限 非集約型対応 手動記述が必要 自動 列挙型文字列化 glz::meta必須 自動 メンバー名取得 __PRETTY_FUNCTION__解析 標準API 対応コンパイラと有効化方法 現時点でP2996リフレクションを利用するには、GCC 16以降（-std=c++26 -freflection）またはBloomberg clang-p2996（-fexpansion-statements -stdlib=libc++）が必要となる。GCC 16はまもなく正式リリースが予定されている。CMakeではglaze_ENABLE_REFLECTION26オプションをONにするか、コンパイラに-DGLZ_REFLECTION26=1を渡すことで有効化できる。コンパイラが__cpp_lib_reflectionまたは__cpp_impl_reflectionマクロを定義している場合は自動で有効になる。 APIに破壊的変更はなく、既存のglz::metaによるカスタマイズも完全に維持される。ただし一点注意すべき変更として、型名の形式が変わった。従来は"mylib::MyEnum"のように修飾名が出力されていたが、P2996環境では"MyEnum"と非修飾名になる。自動生成されたキー名に依存するコードでは出力形式が変化する可能性があるため、移行時には確認が必要だ。 今後の展望 P2996対応はオプトイン形式であり、標準コンパイラによるビルドには影響しない。GCC 16の正式リリースとともに利用者が増えることが予想され、C++26リフレクションのエコシステム全体における実用的な先行事例となる。Glazeは今回の更新でYAMLの処理改善やストリームリクエストのバッファサイズ設定も取り込んでおり、シリアライズライブラリとしての対応範囲を引き続き拡充している。

概要 Pythonの標準パッケージマネージャーであるpipが2026年4月26日にバージョン26.1をリリースした。最大の目玉は、PEP 751で標準化されたロックファイル形式「pylock.toml」の実験的サポートだ。pip lock datasette llm のようなコマンドで依存関係ツリー全体をTOML形式のロックファイルとして生成できるようになった。例えば datasette と llm の依存関係を解決すると519行の pylock.toml が生成される。このロックファイルは -r / --requirements オプションで通常の要件ファイルと同様に読み込むことができる。開発チームは「実験的機能であり、将来のバージョンで変更・廃止される可能性がある」と明記しており、フィードバックをイシュートラッカーで募っている。 依存関係クールダウン機能（--uploaded-prior-to） 新たに追加された --uploaded-prior-to オプションは「依存関係クールダウン」とも呼ばれ、指定した期間より前にアップロードされたパッケージバージョンのみを解決対象とする機能だ。ISO 8601の期間形式（日数のみ対応）で指定し、たとえば --uploaded-prior-to P4D を指定すると4日以上前にリリースされたバージョンのみが候補となる。これにより、リリース直後のパッケージに含まれる可能性のある不具合を避け、ある程度実績のあるバージョンを優先して取得できる。pip 26.1リリース告知記事の著者であるSimon Willisonは、自身のLLM v0.31（3日前リリース）に対してこのオプションを使用し、意図的により安定したv0.30を取得する実例を紹介している。 その他の変更点 pip 26.1ではPython 3.9のサポートが廃止された。Python 3.9は2025年10月にEOL（サポート終了）を迎えており、今回の廃止はそれに合わせた対応となる。そのほか、ピン留めされていない要件がconstraintsのハッシュを活用できるようになったほか、URLベースのconstraintsがextrasを持つ要件にも適用されるようになるなど、2020年の依存関係リゾルバー刷新以来の長年の制限がいくつか解消された。パフォーマンスとメモリ使用量の改善、バグ修正、セキュリティ改善も含まれている。 今後の展望 pylock.tomlはPoetryやuvといったサードパーティツールが独自形式で提供してきたロックファイル機能をPythonの標準エコシステムに取り込む試みであり、採用が広まればプロジェクト間の再現可能ビルドの互換性が向上することが期待される。実験的フラグが外れて安定化するまでにはさらなるコミュニティフィードバックと仕様の精査が必要となる見込みだ。

概要 JetBrainsは2026年4月23日、IntelliJ IDEA 2026.1.1をリリースした。本バージョンは新機能の追加ではなく、2026.1系における安定性向上とバグ修正に特化したメンテナンスリリースである。WSL（Windows Subsystem for Linux）環境でのPython SDK設定、リモート開発のEmmetサポート、Gradleの同期クラッシュなど、多くの開発者が直面していた問題が解消されている。アップデートはIDE組み込みの更新機能、Toolbox App、Ubuntu Snap、またはJetBrainsの公式サイトからのダウンロードで適用できる。 主な修正内容 開発環境に関連する修正として、WSL上でのPython SDK設定が再び正常に動作するようになった。加えて、WSL 2上にインストールされたJDKをIDEが正しく検出できるようになり、WSLを活用したJava開発のセットアップが改善されている。リモート開発環境ではEmmetのサポートが修正され、HTMLやCSSのコード展開が正常に機能するようになった。 ビルドツールとデプロイ周りでは、InternalIdeaModuleのクラスキャスト問題に起因するGradleの同期クラッシュが修正された。また、WildFlyの管理プロセスへの接続が復元され、デプロイ操作やブラウザ起動オプションが利用可能になった。WebLogicの実行構成の作成も正常化されている。 その他の改善点 Antツールウィンドウでターゲットをダブルクリックした際にビルドが実行されてビルド出力が正しく表示されるよう修正された。「検索と置換」機能でEnterキーが正常に動作するようになったほか、Springプロジェクトにおけるコンテキストアクションの検索とコード補完の応答速度が向上している。特に大規模なSpringプロジェクトでは、検索や補完機能において顕著なパフォーマンス改善が見られるとJetBrainsは報告している。

概要 Git 2.54が2026年4月20日に正式リリースされた。137名のコントリビューター（うち66名が新規）の貢献によるリリースで、目玉機能として設定ファイルでフックを定義できる「Configuration-Based Hooks」と、インタラクティブリベースより手軽にコミット履歴を書き換えられる実験的コマンド git history が追加された。また、Git 2.52で導入された幾何学的再パック（Geometric Repacking）がデフォルト化されるなど、パフォーマンスと利便性の両面で多くの改善が施されている。 Configuration-Based Hooks 従来のGitフックは .git/hooks/ 配下にシェルスクリプトを置く方式のため、複数リポジトリへの展開や共有が難しかった。Git 2.54で導入された Configuration-Based Hooks は、~/.gitconfig などの設定ファイルに直接フックを定義できる仕組みだ。 [hook "linter"] event = pre-commit command = ~/bin/linter --cpp20 この方式では同じイベントに複数のフックを登録でき、git hook list で一覧確認が可能。hook.<name>.enabled = false で個別に無効化もできるため、プロジェクトごとの設定上書きも柔軟に行える。グローバル設定として共有できる点は、チームやマシンをまたいだ開発環境の統一に役立つ。 実験的コマンド「git history」 git history はインタラクティブリベースほどの複雑さを要しないシンプルな履歴書き換えに特化した実験的コマンドだ。現在 reword と split の2つのモードが提供されている。 reword モードは指定コミットのメッセージを編集し、そのコミットから派生する全ブランチを自動更新する。ワーキングツリーやインデックスには一切影響しないため、安全に実行できる。split モードはコミットをインタラクティブに分割でき、取り込む変更をハンク単位で選択できる。ただし、マージコミットを含む履歴は対象外で、マージコンフリクトを引き起こす操作は拒否される点に注意が必要だ。 その他の主な改善点 Geometric Repacking のデフォルト化: Git 2.52で導入された幾何学的再パック戦略が今回からデフォルトになった。全体 repack の代わりに段階的統合を実施することで、大規模リポジトリのメンテナンスコストが軽減される。 HTTP 429 への自動対応: レート制限（HTTP 429）を受けた際に Retry-After ヘッダーを解釈して自動リトライする機能が追加された。大量のリモート操作を行う環境での信頼性が向上する。 その他にも、git add -p でのハンク選択状況の可視化、git log -L と pickaxe 検索（-S/-G）の組み合わせ対応、git rebase --trailer による全 rebase 済みコミットへのトレーラー自動付与、git blame --diff-algorithm による差分アルゴリズムの選択、git alias での ASCII 以外の文字サポートなど、日常的なワークフローを改善する多数の機能追加・修正が含まれている。内部的にはオブジェクトデータベース（ODB）がプラガブルバックエンド設計に移行しており、将来の拡張性が高まっている。

概要 JetBrainsは2026年4月22日、ドイツ・ミュンヘンで5月20〜22日に開催されるKotlinConf 2026に合わせてKotlin 2.4.0-Beta2をリリースした。今回のベータ版では、これまで実験的だった複数の言語機能が安定版に昇格するとともに、コレクションリテラル構文など新たな実験的機能が追加されている。 安定化した主な機能としては、コンテキストパラメーター（コンテキスト引数や呼び出し可能参照を除く）、明示的バッキングフィールド、プロパティへの@allメタターゲット、ユースサイトアノテーションターゲットのデフォルトルール変更が挙げられる。また標準ライブラリのkotlin.uuid.Uuid APIも安定版となり、オプトインなしで使用できるようになった。 新しい実験的言語機能 コレクションリテラルは今回のベータ2で最も注目される実験的追加機能で、ブラケット構文[]を使ってコレクションを直感的に生成できる。型を明示すればMutableListなどの可変コレクション、型なしならListがデフォルトとなる。operator fun ofを定義したカスタム型でもこの構文を利用可能だが、Javaで定義されたコレクション型への適用は現時点で未サポート。有効化には-Xcollection-literalsコンパイラフラグが必要だ。 コンテキスト引数の明示指定（-Xexplicit-context-arguments）も実験的に追加された。コンテキストパラメーターの違いだけでオーバーロードが存在する場合に、sendNotification(emailSender = defaultEmailSender)のように明示的にどのコンテキストを渡すか指定できるため、あいまいさを排除できる。さらにコンパイル時定数の評価強化も試験導入され、符号なし型の演算や文字列の.lowercase()/.uppercase()/.trim()、列挙型の.nameプロパティなどをコンパイル時に評価できるようになった。 標準ライブラリと各プラットフォームの強化 標準ライブラリでは、ソート順チェック用の拡張関数群（.isSorted()、.isSortedBy()、.isSortedDescending()など）がイテラブル・配列・シーケンスに追加された。JVM向けにはUInt.toBigInteger()とULong.toBigInteger()が新設され、符号なし整数をBigIntegerへ変換できる。またJava 26のバイトコード生成サポートと、Kotlinメタデータへのアノテーション格納がデフォルト有効化された。 Kotlin/Nativeでは、GradleからSwiftパッケージを依存関係として宣言するAPI（CocoaPodsからの移行ツール付き）が追加された。Swift Exportでkotlinx.coroutines.FlowをSwiftのAsyncSequenceとしてエクスポートできるようになり、型情報も保持される。またデフォルトGCがPMCS（Parallel Mark Concurrent Sweep）からCMS（Concurrent Mark and Sweep）に変更され、マーキングフェーズのアプリケーションスレッドとの並行実行によりGCポーズが大幅に短縮された。 Kotlin/Wasmでは2.1.0から導入されていたインクリメンタルコンパイルが安定版となりデフォルト有効化されたほか、FaaSやサーバーレス用途を想定したWebAssembly Component Modelへの実験的サポートが追加された。Kotlin/JSでは、インライン値クラスをTypeScriptのクラスとしてエクスポートする機能と、js()呼び出し内でES2015機能（アロー関数、スプレッド演算子、const/letなど）をフルサポートするようになった。 今後の展望 KotlinConf 2026はミュンヘンで5月20〜22日に開催され、ワークショップやセッション、基調講演が予定されている。Kotlin 2.4.0の正式リリースに向けて、今回の実験的機能へのフィードバックが求められている段階だ。IDEサポートはIntelliJ IDEAおよびAndroid Studioの最新版に含まれており、ビルドスクリプトのKotlinバージョンを2.4.0-Beta2に変更することで試用できる。

概要 MetaがRustで開発したオープンソースのPython型チェッカー兼言語サーバー「Pyrefly」の最新版v0.62.0が、2026年4月20日にリリースされた。Pyreflyはその名が示すとおり「飛ぶように速い」型チェックを特徴としており、Metaのインフラ環境（166コア・228GB RAM）での計測では毎秒185万行以上のコードを処理できる。これはInstagramの本番コードベース2,000万行を約30秒でチェックできる水準であり、大規模Pythonプロジェクトへの適用を強く意識した設計になっている。Python型準拠テストスイートの合格率は90%に達し、従来から広く使われているmypyやPyrightと並ぶ実用レベルの精度を確保している。ライセンスはMITで、pip install pyrefly 一発でインストールできる。 技術的なアーキテクチャ PyreflyはRustで実装されており、型チェックを三つのフェーズに分割することで大規模インクリメンタル処理と並列化を実現している。第一フェーズで各モジュールの公開シンボル（import * を含む）を確定し、第二フェーズで各モジュールをスコープ情報を持つ「バインディング」へ変換、第三フェーズで他モジュールへの依存を解決して最終的な型を導出する。再帰的な型依存は Type::Var プレースホルダーで扱い、強連結成分が大きいグラフにも対応している。 コードベースは pyrefly_util（汎用ユーティリティ）、pyrefly_types（型定義と操作）、pyrefly_graph（インデックスとキャッシング）、pyrefly_wasm（ブラウザ向けWASMサンドボックス）など複数のRustクレートで構成されている。型推論は関数パラメータを除くほぼすべての箇所（変数・戻り値など）で動作し、制御フロー分析によって静的型を動的に洗練する「フロー型」もサポートする。 IDE統合と最近のリリース動向 PyreflyはLSP（Language Server Protocol）に対応しており、VS Code・Neovim・Zedなどの主要エディタ向け拡張を提供している。オートコンプリート、コードナビゲーション、セマンティックハイライト、クラスのコンストラクタシグネチャとdocstringのホバー表示など、モダンなIDEに期待される機能を網羅している。ブラウザ上で試せるWASMサンドボックスも公式サイトで提供されている。 直近のリリース履歴を見ると、v0.59.0（3月31日）では153コミット・20名のコントリビューターによる大型リリースとして実世界プロジェクト向けの型チェック速度が約2倍に改善され、モジュール解決キャッシュの最適化によるCPU削減も達成した。v0.60.2（4月10日）では「未アノテートの辞書で指数的なメモリ使用」というバグを修正、その後v0.61.0・v0.61.1を経て今回のv0.62.0に至っている。開発は活発でGitHub IssuesやDiscordコミュニティ（隔週オフィスアワー開催）を通じた外部コントリビューションも受け付けている。 他ツールとの位置づけと今後の展望 Pyreflyの設計はMetaの既存型チェッカーであるPyre1のほか、PyrightやmypyなどPythonエコシステムの先行実装から着想を得ている。差別化ポイントはRustによる実装から生まれる純粋な処理速度と、モジュールレベルのインクリメンタル処理・並列化による大規模コードベースへのスケーラビリティにある。Python型準拠テスト90%合格という数字は精度面での実用性を裏付けており、速度と精度の両面でmypy・Pyrightの実質的な代替候補として位置づけられる。現時点ではベータ扱い（既知の問題あり）だが、Metaが自社の巨大Pythonコードベースで実際に運用していることが開発継続の強力な動機となっている。

概要 OracleはJavaOneカンファレンスにおいて、Project DetroitをOpenJDKコミュニティの公式イニシアチブとして正式に位置づけることを発表した。このプロジェクトは、JVM内にChromeのV8エンジン（JavaScript用）とCPythonランタイム（Python用）を直接組み込み、JavaからJavaScriptおよびPythonを直接呼び出せるクロスランゲージ・インタロップを実現することを目標としている。OracleのJavaプラットフォームグループ上級副社長であるGeorges Saab氏は「Detroitの主な利点は、業界最高水準のJavaとJavaScript、あるいはJavaとPythonを組み合わせた統合的な技術利用が可能になること」と述べている。 技術的な詳細 技術面では、javax.script APIをJavaScript向けにV8エンジンで、Python向けにCPythonで実装する形を採用する。JVMとネイティブランタイムの橋渡しにはJava 22以降で標準化されたForeign Function & Memory（FFM）APIが活用される。Javaヒープとネイティブヒープを分離して実行することによりセキュリティを強化しつつ、既存のV8およびCPythonが持つパフォーマンス最適化の恩恵をそのまま受けられる設計となっている。完全な言語互換性を確保するためにそれぞれのオフィシャルランタイムを採用しており、独自の部分的実装に伴うメンテナンスコストを抑える狙いもある。 背景と経緯 Project Detroitの発想自体は2018年頃に、JavaScriptがJavaの機能を拡張するメカニズムとして最初に提案された。しかし一時は開発の勢いを失い停滞していた。近年、AIライブラリへのアクセスや多言語混在環境でのビジネスロジック記述といったニーズが急増したことで関心が再燃し、今回のOpenJDKプロジェクト化という形で息を吹き返している。 今後の展望 当面はJavaScriptとPythonのサポートを中心に開発が進む予定だが、ロードマップには将来的な追加言語対応も含まれている。Java開発者にとっては、まだJava向けの同等ライブラリが存在しないJavaScriptやPythonのエコシステム資産（特にAI・機械学習ライブラリ）へのアクセスが容易になるという直接的な恩恵が期待される。OpenJDKプロジェクトとして正式化されたことで、コミュニティを巻き込んだ開発の加速が見込まれる。

概要 Microsoftは2026年4月21日、TypeScript 7.0のベータ版を正式に公開した。最大の特徴は、コンパイラ全体をGoで書き直した「Project Corsa（tsgo）」の採用であり、型チェック速度がTypeScript 6.0と比較して約10倍に高速化されている。VS Codeのエディタ起動時間は9.6秒から1.2秒へと大幅に短縮され、メモリ使用量も約半減した。Microsoftは「ベータ段階であってもほとんどのCI/CDワークフローですでに本番利用可能なレベルに達している」と強調しており、Bloomberg、Canva、Figma、Google、Slack、Vercelといった大手企業との協力を通じて「圧倒的にポジティブな」フィードバックが得られているという。 技術的な詳細 高速化の根拠はネイティブコード実行と、複数CPUコアにわたる共有メモリ並列化にある。なお、このGoへの移植はゼロからの書き直しではなく、TypeScript 6.0の型チェックロジックを方法的に移植したものであり、セマンティクスの互換性が維持されている。 並列処理は次の3つの軸で制御できる。型チェックワーカーはデフォルト4個で動作し、--checkersフラグで数を調整可能。複数プロジェクトを同時にコンパイルする際は--buildersフラグを使う。デバッグやリソース制約のある環境向けには--singleThreadedでシングルスレッドモードに切り替えられる。 コマンドラインツールは従来のtscではなくtsgoとして提供され、npm経由で次のようにインストールできる。 npm install -D @typescript/native-preview@beta VS Code向けの統合拡張機能も提供されており、エディタ上でもパフォーマンス向上の恩恵を受けられる。 破壊的変更 TypeScript 7.0ではいくつかの厳格なデフォルト変更が導入された。strictモードがデフォルトで有効化され、ES5をターゲットとする設定が廃止される。また、AMD・UMD・SystemJSのモジュール形式のサポートも終了する。これらはレガシーな構成との決別を意味しており、既存プロジェクトでの採用には移行コストが伴う可能性がある。 今後の見通し Microsoftはベータ公開後数週間以内にリリース候補版を、約2ヶ月以内に安定版をリリースする予定を示している。Goベースのコンパイラへの移行はTypeScriptエコシステムに大きな転換をもたらすものであり、大規模コードベースを抱える開発チームにとって特に恩恵が大きいと見られている。

概要 JavaScriptランタイムのBunは2026年4月20日、バージョン1.3.13を正式リリースした。今回のリリースは機能追加・パフォーマンス向上・メモリ最適化の三本柱で構成されており、特にテストランナーへの並列実行機能の追加、bun installのメモリ使用量の17倍削減、zlib-ng統合によるgzip圧縮の最大5.5倍高速化が目玉となっている。また1,316件のJavaScriptCoreエンジンのアップストリームコミットをマージするなど、エンジン層の大規模アップグレードも含まれている。 テストランナーの強化 テストランナーには4つの新フラグが追加された。--parallel[=N]は、テストファイルをN個のワーカープロセスへ分散して並列実行する機能で、アイドル状態のワーカーが最も忙しいキューからタスクを盗む「work stealing」方式でCPUを効率活用する。--shard=M/NはCI環境向けの機能で、テストスイート全体を複数のジョブへ分割して実行できる。Jest・Vitest・Playwrightと同じ構文を採用しており、ファイルはパスでソートしてラウンドロビン分散することで決定論的な実行を保証する。 --isolateフラグは各テストファイルを同一プロセス内の独立した環境で実行し、マイクロタスクのドレイン・ソケットのクローズ・タイマーのキャンセルを行うことでファイル間の状態汚染を防ぐ。--changedフラグはgitの変更検知とインポートグラフ解析を組み合わせ、変更の影響を受けるテストファイルのみを選択的に実行することで開発イテレーションを高速化する。 メモリ使用量の大幅削減 bun installのメモリ最適化では、パッケージのtarballをダウンロードと同時にディスクへストリーム書き込みする方式に変更した。従来はアーカイブ全体をメモリ上に展開していたが、今後は圧縮済みバイト列とlibarchiveの固定サイズバッファのみを保持するため、メモリ使用量が最大17倍削減される。 ソースマップについても、VLQ（可変長量）方式からビットパック形式への移行により1マッピングあたり約2.4バイトへ削減（従来は約20バイト）、実測ではTypeScriptコンパイラのデータで11.3MBから1.29MBへと最大8倍の削減を達成した。加えてmimallocをv2からv3へアップグレードし、libpasのscavengerサポート（Windows/Linux対応）を追加することでランタイムのメモリ使用量を約5%改善している。 パフォーマンス向上：gzip高速化とJavaScriptCoreアップグレード gzip圧縮ではNode.js 24+やChromiumが採用するzlib-ng 2.3.3を統合した。ベンチマークでは1MBデータのgzipSync（L1）で2.50倍、123KBデータのdeflate（L6）で5.48倍の高速化を記録している。配列反復処理も1.43倍に高速化された。 JavaScriptCoreエンジンには1,316件のアップストリームコミットをマージし、配列長設定のインラインキャッシュ化・toUpperCase()のJIT内在化・日付フォーマッタのキャッシュ・SIMD高速化したequalIgnoringASCIICaseなどの最適化が含まれている。 Web APIの拡充とバグ修正 Web API面では、Bun.serve()がRange: bytes=...ヘッダに対応し206 Partial Contentレスポンスを自動返信できるようになった。WebSocketはws+unix://およびwss+unix://スキームによるUnixソケット接続をサポートし、npmのwsパッケージとの互換性が向上した。暗号API面ではSHA3-224/256/384/512のcrypto.createHash()およびcrypto.subtle.digest()サポート、RFC 7748準拠のX25519鍵導出が追加された。 バグ修正では、Workerスレッド終了時のクラッシュ、socket.setTimeout()の誤動作、HTTP/2設定の不正広告、fs.watch()のデッドロック、ファイルディスクリプタリークなど複数の重要な問題が解消されている。

概要 Solidity Language Teamは2025年度の開発者調査（Solidity Developer Survey 2025）の結果を公開した。今回の調査には87カ国から1,095名の開発者が参加し、Solidityエコシステムの最新動向が浮き彫りになった。前回調査と比較しても回答者数は堅調で、グローバルなSolidity開発者コミュニティの広がりが示された。 調査の目的は、Solidity言語の利用実態、開発環境の傾向、そして開発者が直面している課題を把握し、今後の言語仕様や開発ツールの改善に役立てることにある。Solidity TeamはこのフィードバックをEIP（Ethereum改善提案）や次期バージョンの機能優先順位付けに活用している。 フレームワーク利用状況 開発環境のフレームワークとしては、Foundryが57%のシェアでトップを維持した。Foundryはテストのパフォーマンスや充実したスクリプティング機能が評価されており、ここ数年で急速に普及したツールチェーンだ。以前はHardhatが主流のフレームワークとして長年君臨していたが、近年のFoundryの台頭によりエコシステムのバランスが変化している。 HardhatやRemix、Truffle（現在は開発停止）といった他のフレームワークも引き続き利用されているが、Foundryの圧倒的なシェアは開発者コミュニティの明確な移行トレンドを示している。Foundryの採用拡大は、Rustで実装された高速なコンパイル・テスト実行環境と、Solidity自体でテストを記述できる直感的なアプローチが支持されている結果といえる。 開発者が抱える主な課題 調査ではデバッグとスタック深度エラー（stack too deep）が依然として開発者の最大の課題として挙げられた。スタック深度エラーはEVMアーキテクチャの制約（最大16個のスタック変数）に起因するもので、複雑なロジックを持つコントラクトを実装する際に多くの開発者が直面する問題だ。これに対してSolidity Teamは新しいSSA CFGコード生成パイプラインの開発を進めており、スタック深度エラーの根本的な解消を目指している。 デバッグ環境の改善も引き続き重要な要望として挙げられた。スマートコントラクトのデバッグはオンチェーン実行の特性上、従来のソフトウェア開発とは異なるアプローチが必要であり、より詳細なエラーメッセージやトレース機能の充実が開発者から求められている。 今後の展望 調査結果はSolidity言語の今後の開発ロードマップに直接反映される予定だ。Solidity Teamは開発者からのフィードバックを重視しており、毎年の調査はコミュニティとの重要なコミュニケーション手段となっている。スタック深度制限への対応やデバッグ体験の向上、そしてコンパイラのパフォーマンス改善が引き続き優先課題として取り組まれる見込みだ。 Solidityはイーサリアムをはじめとする多くのEVM互換ブロックチェーン向けスマートコントラクト開発において事実上の標準言語としての地位を維持しており、今後も活発なコミュニティとともに進化が期待される。