Programming Languages

概要 Microsoft Build 2026が6月2〜3日にサンフランシスコのフォートメイソンで開幕し、Microsoftは「Windowsをエージェントプラットフォームとして再定義する」という方針のもと、開発者向けの大型発表を相次いで行った。約2,500人規模の開発者イベントとして設計された今回のカンファレンスでは、AIエージェントが中心テーマに据えられ、エンタープライズ展開から本番運用フェーズへの移行を加速する施策が打ち出された。 最大のサプライズはProject Polarisの発表だ。MicrosoftがGitHub Copilotのデフォルトエンジンとして採用しているGPT-4 Turboを自社開発モデルに置き換えるプロジェクトで、2026年8月より切り替えが始まる。Mixture-of-Experts（MoE）アーキテクチャを採用した同モデルは、HumanEvalおよびMBPPベンチマークでGPT-4 Turboを上回るとされ、特に低リソース言語での性能が強みとして挙げられた。この移行によりMicrosoftはモデル・推論インフラ・開発者体験の全てを自社コントロール下に置くことになる。 Windows AIエージェントプラットフォームの構造 Windowsのエージェント基盤は以下の3層アーキテクチャで構成される。 Windows Agent Framework（WAF）v1.0はMITライセンスで公開される開発者向けSDKで、YAMLでエージェントを定義すればローカルマシンからWindows 365 Cloud PC、Azure Arcエッジデバイスまでアーキテクチャの変更なしにスケールできる。Windows Agent RuntimeはOSレベルのネイティブAPIを提供し、エージェントをファーストクラスの存在として扱う。現在のプレビューではJSON・XML・PDFファイルに対するテキストベースのエージェントをサポートしており、AdobeやZoomなどがパートナーとして参加している。Windows Agent Storeはキュレーションされたエージェントのマーケットプレイスで、収益の85%が開発者に配分される——これは現行のMicrosoft Storeと同条件だ。 インフラ面では、オンプレミス・クラウド・エッジにまたがる実行を統合するAzure Agent Mesh（2026年Q4 GA予定）、Intel・AMD・Qualcomm NPUの差異を吸収してクラウドラウンドトリップなしにローカルAI推論を可能にするDirectML 2.0、GPU/NPUアクセス付きでLinuxカーネルを仮想化するWSL 3も発表された。 GitHub CopilotとAzure AI Foundryの強化 GitHub Copilot/Copilot Workspaceがベータを卒業し、正式リリースとなった。Jira・Datadog・ServiceNowとの拡張機能連携、自律的な反復タスクを処理する「フリートモード」、スケジュール実行でバックグラウンド操作を行う「オートパイロット」機能が追加されている。またCopilotはマルチモデル対応にシフトし、OpenAIモデルに加えてAnthropicのClaudeも代替として選択できるようになる。 .NETおよびPython向けのAgent Framework 1.0も本番提供が開始された。階層的なエージェント調整、イベント駆動型ワークフロー、ステートフルなエージェント機能をサポートする。Azure AI Foundryのモデルカタログは約1,600から3,000以上に拡張され、エージェント評価ツールとDevUIデバッガーも追加された。 マルチモーダルモデルMAI v2 Microsoftは自社のマルチモーダルモデルスイート「MAI v2」も発表した。画像生成・編集機能を持つMAI-Image-2.5、14言語・感情表現に対応したMAI-Voice-2、前バージョンMAI-Transcribe-1が25言語で単語誤り率3.9%（FLEURS）を達成しており、その漸進的な改良版であるMAI-Transcribe-1.5の3モデルで構成される。価格設定は一般提供時に公表される予定だ。 今回のBuild 2026は、MicrosoftがAzure AI収益の拡大を背景に、単なるAIモデルの提供者からエンドツーエンドのエージェント実行基盤へと自社を再定位する戦略的転換点と言える。Project PolarisによるOpenAI依存の低減は、同社のAI事業における長期的な独自性確保という観点でも注目される。

概要 Rustチームは2026年5月28日、Rust 1.96.0を正式リリースした。今回のリリースで最も注目すべき変更は、RFC 3550に基づく新しいcore::range名前空間のRange型の安定化だ。assert_matches!およびdebug_assert_matches!マクロも正式に利用可能となり、WebAssemblyターゲットのリンク動作変更、Cargoに関する2件のセキュリティ脆弱性修正も含まれている。 新しいCopy対応Range型 従来のcore::opsに定義されているRange型（0..5などのリテラルで生成される型）は、Iteratorトレイトを直接実装していたためCopyトレイトを実装できなかった。これにより、Range値をCopyな構造体フィールドに保持することができないという制約があった。 Rust 1.96.0では、RFC 3550にもとづいてcore::range名前空間に新しいRange型（Range、RangeFrom、RangeInclusive）が安定化された。これらはIteratorの代わりにIntoIteratorを実装する設計に変更されており、Copyトレイトが実装されている。これにより、Range値をコピー可能な構造体に格納したり、関数呼び出し後も元の値を使い続けることが可能になる。 現時点では0..5のような範囲構文は従来のcore::ops型を生成し続ける。Rustチームは将来のエディションでこの構文を新しいcore::range型に移行する計画であり、移行期間中はライブラリ作者に対して公開APIでimpl RangeBoundsを使用し、旧来型・新型の両方をサポートすることが推奨されている。 assert_matches!マクロの安定化 assert_matches!およびdebug_assert_matches!マクロが安定化された。これらのマクロは、ある値が特定のパターンにマッチすることをアサートするためのもので、マッチに失敗した場合は期待パターンと実際の値が表示されるため、従来のassert!(matches!(...)) よりも診断メッセージが格段に読みやすくなる。なお、使用する際はコード内で明示的にインポートが必要となる。 WebAssemblyの変更とセキュリティ修正 WebAssemblyターゲットのビルドにおいて、リンカの--allow-undefinedフラグがデフォルトで削除された。これにより、未定義シンボルが存在する場合はリンクエラーとなり、バグの早期発見に役立つ。 またCargoでは2件の脆弱性が修正された。CVE-2026-5223はtarball展開時のシンボリックリンク処理に関連する中程度の脆弱性、CVE-2026-5222は正規化URLの認証処理に関連する低程度の脆弱性だ。いずれもサードパーティのレジストリを使用している環境が影響を受けうるもので、crates.ioのみを利用しているユーザーへの影響はない。 まとめ Rust 1.96.0はパターンマッチのユーザー体験向上と、長年の課題だったRange型のCopy非対応問題に取り組んだリリースだ。新しいcore::range型はまだ将来のエディション移行に向けた準備段階だが、今からライブラリ設計に組み込むことで将来の移行をスムーズにできる。セキュリティ修正も含まれており、Cargoを使用しているプロジェクトではアップデートが推奨される。

概要 Linux Open-Source SummitにてKernelScript 0.1が発表された。KernelScriptはeBPF・ユーザー空間・カーネル空間の開発を単一のコードベースに統合することを目的とした型安全なドメイン固有言語（DSL）で、Apache 2.0ライセンスのオープンソースとして公開されている。従来、eBPFプログラムをC言語で手書きするには複雑な知識とボイラープレートが必要だったが、KernelScriptはその複雑さを抽象化し、必要なコードやMakefile、カーネルモジュール統合コードを自動生成することで開発効率の向上を目指している。 技術的な詳細 KernelScriptは主要なeBPFプログラム種別を幅広くサポートしている。ネットワークパケット処理向けのXDP（eXpress Data Path）、トラフィック制御向けのTC（Traffic Control）、カーネル関数のトレーシングに使うプローブ、そしてパフォーマンスイベントプログラムが対象となっている。データ構造についてはハッシュマップ、CPU別配列、LRU（Least Recently Used）マップ、ピンマップといったeBPF標準の各種マップ型に対応する。 さらに高度な機能として、テールコールの自動化、dynptrによる動的ポインタ処理、プログラムライフサイクルチェック、kfunc（カーネル関数）統合もサポートされている。これらの機能を一つの言語で統一的に扱えることで、ネットワーク・トレーシング・可観測性・セキュリティ・パフォーマンス分析といったeBPFの幅広いユースケースにおける開発体験が改善されることが期待される。 現状と今後の展望 開発チームは現時点のリリースをあくまで実験的なものと位置づけており、構文やAPIは今後変更される可能性があるとして本番環境での使用を推奨していない。バージョン0.1という初期段階のリリースながら、eBPF開発の敷居を下げるという方向性は明確であり、今後のコミュニティの反応や継続的な開発進捗に注目が集まる。

概要 Angular 22のリリース候補（22.0.0-rc.1）が2026年5月20日に公開され、安定版リリースを目前に控えている。v22では Signal Forms（リアクティブフォームの新API）の安定化と、セレクターレスコンポーネントの導入が予定されており、Angular 21で先行投入されたゾーンレス変更検出のデフォルト化やVitestへのテストランナー切り替えと合わせて、「Signal-First」設計への転換が一段と進む節目のリリースとなる。 なお、Angular 19は2026年5月19日にEOL（サポート終了）を迎えており、以降はセキュリティパッチも提供されない。Angularチームはv19在籍中に少なくとも3件の高深刻度CVEが発生した事実を挙げ、EOL後の継続利用リスクを強調している。 主要な新機能・変更点 Signal Forms の安定化は v22 最大のハイライトとして予定されている。Angular 21では @angular/forms/signals 経由で実験的 API として提供されていたが、v22 では従来の ReactiveFormsModule に代わる Signals ベースの新しいリアクティブフォーム API として安定版に到達する見込みだ。valueChanges.pipe(takeUntil(...)) のような RxJS パターンが不要になり、フォームの状態管理がよりシンプルかつ型安全になる。 ゾーンレス変更検出のデフォルト化は Angular 21 ですでに導入済みで、v22 でも継続される。新規プロジェクトでは Zone.js が不要となり、Signals ベースの変更検出機構がデフォルトで有効になる。Zone.js の除去によってバンドルサイズが削減され、変更検出のオーバーヘッドも大幅に低減される。既存プロジェクトへの自動適用はなく、段階的な移行が可能だ。 セレクターレスコンポーネントの導入により、selector プロパティを省略したコンポーネント定義が可能になる。ルーターや動的ロードなど、テンプレートへの直接埋め込みが不要なユースケースで冗長なセレクター定義を省けるようになる。 Vitestへの移行は Angular 21 で実施済みで、v22 でも継続される。Karma は完全廃止となり Vitest が標準テストランナーとなっている。Vitest は Karma と比較して5〜10倍高速とされており、開発者体験の大幅な改善が期待できる。 移行上の注意点 Angular 21 で導入された以下の破壊的変更は、v22 への移行時にも引き続き考慮が必要となる。 OnPush がデフォルト変更検出戦略に: 新規コンポーネントのデフォルトが ChangeDetectionStrategy.OnPush となる ng-reflect-* 属性の削除: デバッグ用属性が本番ビルドから除去される NgModuleFactory の削除: 旧来の NgModule ベース API が完全廃止 HammerJS 統合の削除: タッチジェスチャーサポートが組み込みから分離 Node.js v22.22.0 以上（または v24.13.1 以上）が必須: 旧バージョンの Node.js はサポート対象外となる NgModule を多用する既存の大規模プロジェクトや、サードパーティライブラリへの依存が強いチームにとっては、移行コストが相応に発生する可能性がある。移行の優先度はアーキテクチャの複雑さとデプロイプロセスを踏まえて評価することが推奨される。 ...

概要 GitHubは2026年5月22日、npmのセキュリティを強化する2つの主要機能を発表した。一つはステージド公開（Staged Publishing）の一般提供開始、もう一つはnpm 11.15.0で追加された非レジストリソースからのインストール制御フラグ群だ。いずれも、TeamPCPのようなサイバー犯罪グループによるオープンソースパッケージへの大規模なサプライチェーン汚染キャンペーンが増加する中、供給チェーン全体の防御を強化することを目的としている。 ステージド公開：2FA承認を挟むリリースフロー ステージド公開は、従来の「npm publish で即時公開」というモデルを改め、リリース前に人的承認ステップを挟む仕組みだ。開発者がCI/CDパイプラインから npm stage publish を実行すると、ビルド済みtarballがステージキューにアップロードされ、2FA（二要素認証）を有効にしたメンテナが明示的に承認するまで、利用者はそのバージョンをインストールできない。承認はnpmjs.comのウェブUIとnpm CLI両方から操作可能となっており、CI/CDは非対話的に実行し、メンテナが後から確認・承認するという運用モデルが想定されている。 この機能を利用するにはnpm CLI 11.15.0以上が必要で、対象パッケージはnpmレジストリに既存のものに限られる（新規パッケージは初回公開にステージド公開を使用不可）。また、OIDCトラステッドパブリッシングと組み合わせてパーミッションを stage-only に制限すれば、CIから直接公開することを完全に禁止できる。これにより、CIが侵害された場合でも悪意のあるバージョンが即座に配布されるリスクを大幅に低減できる。 インストールソース制御フラグ npm 11.10.0で導入された --allow-git フラグ（Gitソースからのインストール制御）を拡張する形で、npm 11.15.0では以下の3つの新フラグが追加された。 --allow-file: ローカルファイルパスおよびローカルtarballからのインストールを制御する --allow-remote: httpsなどのリモートURLからのインストールを制御する --allow-directory: ローカルディレクトリからのインストールを制御する 各フラグは all（現在のデフォルト）または none の値を受け入れ、CLIオプション・.npmrc・package.json のいずれでも設定できる。なお、--allow-git はnpm v12（次期メジャーバージョン）でデフォルトが all から none に変更される予定であり、今後はレジストリ外ソースへの依存がより明示的な許可を必要とする方向に進む見通しだ。 セキュリティ上の意義 これらの機能は、レジストリ外ソースからの依存関係導入や、CI/CDを経由した意図しないパッケージ公開を防ぐ明示的な許可リスト方式を提供する。サプライチェーン攻撃の手口が高度化・大規模化する現状において、パッケージのライフサイクル全体にわたってメンテナの意図的な関与を求める設計は、エコシステム全体の信頼性向上に寄与するものと評価されている。

概要 Node.jsチームは2026年5月20日、Current系の最新版となるNode.js 26.2.0をリリースした。リリースマネージャーは@aduh95が務め、100件以上のコミットが含まれる大型アップデートとなっている。今回の目玉は、JavaScriptのTemporal APIをファイルシステム統計オブジェクトへ組み込んだことに加え、次世代の量子耐性暗号アルゴリズムのサポート開始、そしてHTTPプロトコルに関する利便性向上である。 Temporal APIとファイル統計の統合 セマバー的にMINORの追加として、fs.Statsおよびfs.BigIntStatsオブジェクトにTemporal.Instantサポートが実装された（PR #60789）。従来のDateオブジェクトはタイムゾーン処理や算術演算において多くの落とし穴があったが、Temporal APIを活用することでより精確かつ安全な日時操作が可能になる。合わせてStatsオブジェクト上のDateプロパティがenumerableに変更され（PR #63328）、オブジェクトの列挙やシリアライズ時の挙動が改善された。 量子耐性暗号のサポート BoringSSL環境向けにML-DSA（Module-Lattice-Based Digital Signature Algorithm）とML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism）の2つの量子耐性暗号アルゴリズムが追加された。これらはNIST（米国標準技術研究所）が標準化を進めているポスト量子暗号の代表格であり、将来の量子コンピュータによる攻撃に備えたアプリケーション開発が可能となる。暗号関連では他にも、Web Cryptography APIでのChaCha20-Poly1305とAES-KWのサポート追加、CryptoKeyとKeyObjectの内部スロットセキュリティ強化、macOSでのシステム証明書列挙改善なども含まれている。 HTTP 1xxステータスコードとその他の新機能 HTTPモジュールに新メソッドwriteInformation()が追加され（PR #63155）、任意の1xxステータスコードを応答として送信できるようになった。これにより、103 Early Hintsなどのプリロードヒントや進捗通知など、中間的なHTTPレスポンスを扱う実装が容易になる。また長らく実験的扱いだったstream.composeがstableとして昇格したほか、QUICプロトコルの内部実装が完全に整備され--allow-netパーミッションへの対応も加わった。テストランナーでもタグによるフィルタリング機能が追加され、大規模なテストスイートの管理が改善された。 依存関係の更新 主要な依存パッケージも更新されており、undiciが8.3.0、corepackが0.35.0、sqliteが3.53.1、simdjsonが4.6.4、QUICライブラリのngtcp2が1.22.1へそれぞれバージョンアップしている。Node.js 26.2.0のバイナリおよびソースコードは公式サイトからダウンロード可能だ。

概要 2026年5月20〜22日にミュンヘンで開催されたKotlinConf 2026の基調講演では、言語誕生から15周年を迎えたKotlinの最新動向が多数発表された。Kotlin 2.4.0のプレビュー機能、AIエージェント向けフレームワークKoog 1.0の正式安定版リリース、Compose Multiplatform 1.11.0のリリースおよびWebプラットフォームのBeta到達が主な発表として挙げられる。決済システムや機内エンターテイメント、税務申告など幅広い分野でKotlinが活用される現在、AI駆動開発の普及とともに言語設計の信頼性がより重要になっているとJetBrainsは強調した。 Kotlin 2.4.0の新機能プレビュー Kotlin 2.4.0では、コンテキストパラメータと明示的バッキングフィールドの2機能が安定化される予定だ。コンテキストパラメータはAPIの表現力を高め、明示的バッキングフィールドはボイラープレートコードを削減するものとなっている。また実験的機能として多フィールド値クラスが導入される。値クラスはプロパティのみで定義され、equals()・hashCode()・toString()が自動生成される仕組みだ。ツールチェーン面では、Kotlin Language ServerがAlphaに昇格しVisual Studio Code公式拡張として利用可能になったほか、機械可読なドキュメント配布を実現するkdoc.jar形式も導入される。Kotlin/Nativeのビルド時間はバージョン2.2から2.4にかけて25%短縮される見込みで、パフォーマンス改善も引き続き進んでいる。 AIエージェント開発への注力：KoogとAnthropicとの協業 今回の発表で特に注目を集めたのが、KotlinネイティブのAIエージェントフレームワークKoog 1.0の正式安定版リリースだ。Mercedes-Benzがすでに車両保守支援エージェントの構築に活用するなど、実用段階に入っている。JetBrainsはAI開発ツールの整備にも力を入れており、IDEとコーディングエージェントの通信規格**Agent Client Protocol (ACP)**の策定を主導。複数LLMプロバイダに対応するコーディングエージェント「Junie」と、複数エージェントをGit worktreeやDockerコンテナで並列実行できる環境「JetBrains Air」も紹介された。さらにAnthropicとの協業として、AnthropicがKotlinで公式JVM SDKを開発し、Claude CodeがIntelliJ IDEAにネイティブ統合された。Kotlin SWE-benchでは86.4%の解決率を達成している。 Compose Multiplatform 1.11.0とマルチプラットフォーム展開 Compose Multiplatform 1.11.0では、iOSのネイティブテキスト入力（実験的）が追加され、正確なキャレット移動やネイティブジェスチャー、システムコンテキストメニュー（オートフィル・翻訳・検索）がサポートされた。バージョン1.8.0から導入されていた並行レンダリングがデフォルトで有効化され、レンダリングタスクが専用スレッドにオフロードされるようになっている。非AndroidプラットフォームへのCompose UI テスト v2 API対応も追加され、StandardTestDispatcherがデフォルトディスパッチャーとなりテストの予測可能性が向上した。Web向けはスクロール性能が大幅に改善された。なお、Webプラットフォームは2025年9月にBetaステータスへ到達済みで、本基調講演でもこの節目が改めて言及された。Kotlin Multiplatformは採用が急速に拡大しており、PayPal・Booking.com・Sony・Duolingoなど大企業が本番環境で運用している。またSwift ExportがAlphaに昇格し、iOS開発体験のさらなる向上が見込まれる。 今後の展望 バックエンド向けにはKotlin 2.4から標準ライブラリへの18ヶ月セキュリティサポートポリシーが導入され、ORMフレームワークExposed 1.0ではベクトル型とGradleプラグインが安定化される。Androidではプロフェッショナル開発者の92%がKotlinを採用しており、K2コンパイラの安定化後に採用がさらに加速した。Kotlin Symbol Processingで実行時間が17%短縮されたことも報告されている。マルチプラットフォームライブラリのハブklibs.ioには3,500以上のライブラリが登録されており、エコシステムの充実度も増している。JetBrainsは言語・ツールチェーン・AIエージェント・マルチプラットフォームを軸に、バックエンド・モバイル・Web・AIの各領域での統一開発基盤としてKotlinの役割拡大を目指している。

概要 MicrosoftはTypeScriptコンパイラをJavaScriptからGo言語に書き直したネイティブバージョン「TypeScript Native Previews」を発表し、npmパッケージ「@typescript/native-preview」として公開した。プロジェクト内部では「Corsa」と呼ばれるこのコンパイラは、従来のJavaScript製コンパイラ（社内コードネーム「Strada」）と比べて大多数のプロジェクトで約10倍の処理速度向上を実現している。VS Code向けの拡張機能「TypeScript (Native Preview)」もマーケットプレイスで提供されており、誰でも試せる状態になった。 インストールと利用方法 開発者は以下のコマンドでプレビュー版をインストールして試すことができる。 npm install -D @typescript/native-preview npx tsgo --project ./src/tsconfig.json 新しい実行ファイルtsgoは従来のtscと同様の使い勝手で動作する。VS Codeユーザーはマーケットプレイスから拡張機能をインストールし、「TypeScript Native Preview: Enable (Experimental)」コマンドで有効化することで、ネイティブコンパイラを使ったエディタ体験を試せる。 劇的な速度向上の実績 Go言語への移植によって得られた最大の恩恵は処理速度の大幅な向上だ。Goはネイティブコンパイルと共有メモリによる並行処理をサポートしており、これはJavaScriptが本質的に持っていない特性だ。実際のコードベースを使ったベンチマークでは、大規模OSSプロジェクトSentryのコードベースにおいてTypeScript 5.8での72.81秒という処理時間が、ネイティブバージョンでは6.761秒にまで短縮されたことが確認されている。 現時点の機能と制限 3月の初回発表以降、今回のプレビューでは新たにJSXの型チェックサポート、JSDocアノテーション付きJavaScriptファイルの型チェック対応、コード補完機能が追加された。一方で、現時点では--declaration（型定義ファイルの生成）、--buildモード、ES5などのダウンレベルコンパイルターゲットはまだサポートされていない。エディタ機能においても、自動インポート、全参照検索、リネームといった高度な機能は引き続き開発中だ。 今後のロードマップ Microsoftは年内に--buildモードや拡充されたランゲージサービス機能を備えた、より完全なコンパイラバージョンのリリースを目指している。TypeScript 7.0では最終的にtsgoがtscに改名され、公式のtypescript npmパッケージに統合される計画だ。一方、TypeScript 6.xシリーズでは既存のJavaScript製コンパイラ「Strada」が引き続きサポートされ、段階的な移行が可能な体制が整えられる。

概要 Vercel Labsは2026年5月15日、AIエージェントによる自律的なコード読み取り・修復・デプロイを主眼に設計したシステムプログラミング言語「Zero」をv0.1.1としてリリースした。CやRustと同じ低レベル設計空間に位置し、ネイティブ実行可能ファイルにコンパイルされる。開発者はVercel LabsのChris TateとMatt Van Hornで、ソースコードはApache 2.0ライセンスでGitHub（vercel-labs/zero）に公開されている。ファイル拡張子は.0。 従来のプログラミング言語は「人間がエラーメッセージを読み、警告を解釈し、スタック出力を手動でトレースしてバグを修正する」ことを前提に設計されてきた。Zeroはその前提を覆し、AIエージェントが中間的な人間の翻訳なしにコンパイラ出力を処理できる構造を実現している。 JSONによる機械可読な診断出力 Zeroの最大の特徴は、コンパイラが構造化JSONで診断情報を出力する点にある。zero check --jsonを実行すると、以下のような形式でデータが返される。 { "ok": false, "diagnostics": [{ "code": "NAM003", "message": "unknown identifier", "line": 3, "repair": { "id": "declare-missing-symbol" } }] } 各診断には安定したエラーコード識別子と型付きの修復メタデータが含まれる。エラーコードはコンパイラバージョン間で一貫性を保つよう設計されており、AIエージェントは同じコードに対して一度学習すれば再学習が不要になる。これに加え、zero fix --plan --jsonで機械可読な修復計画を生成し、zero explain <code>で診断コードの詳細説明をクエリできる。さらにzero skillsコマンドは、インストール済みのコンパイラバージョンに同期したエージェント向けワークフロー資料をCLIから直接提供し、外部ドキュメントのスクレイピングを不要にする。 技術的な設計方針 能力ベースのI/Oモデルを採用しており、副作用は関数シグネチャに明示的に宣言される。 pub fun main(world: World) -> Void raises { check world.out.write("hello from zero\n") } コンパイル時に利用不可能な能力は拒否されるため、AIエージェントが関数の振る舞いを記号レベルで把握しやすい。バイナリサイズは10KiB未満に最適化され、強制的なガベージコレクションや隠れた割り当て、非同期処理を排除することで予測可能なメモリ管理を実現している。静的ディスパッチを採用し、実行時の挙動が推論しやすい設計になっている。 現状と課題 現時点でZeroはv0.1.1の実験段階にあり、コンパイラと言語仕様は未安定化である。パッケージレジストリは初期段階、クロスコンパイルは文書化されたターゲットに限定されており、VS Code拡張機能は構文ハイライトのみ対応している。開発者コミュニティからは「LLMはすでにRustやPythonのエラーを処理できる」という指摘や、メモリ安全性保証の実装の未成熟さへの懸念も上がっており、実用化に向けてはこれらの課題への対応が求められる。

概要 HuaweiのEdinburgh研究センターのDan Ghica教授が中心となって開発した新しいオープンソースコンパイル言語「Cangjie（仓颉、日本語読み：そうけつ）」がInfoQで詳しく紹介された。Cangjieは、Java・Kotlin・Swiftの現代的な代替を目指して設計されており、Huaweiのモバイル・IoTエコシステムへの組み込みが期待されている。この言語はすでに中国の80以上の大学で教育に活用されており、Eclipse Foundationのフラッグシップカンファレンス「OCX 2026」（ブリュッセル開催）でも発表された。 Cangjieの主な特徴として、静的型付けとパターンマッチング、並行ガベージコレクション、代数的データ型（ADT）、マクロとアノテーションによるメタプログラミングが挙げられる。対応プラットフォームはLinux・macOS・Windows・Android・iOS・HarmonyOSと幅広く、Huaweiのマルチプラットフォーム戦略を支える言語として位置づけられている。 エフェクトハンドラー——最も注目すべき革新 Cangjieにおいて学術的に最も注目を集めているのが「エフェクトハンドラー（Effect Handlers）」機能だ。エフェクトハンドラーは、例外処理と動的バインディングを一般化する仕組みで、performとresumeという新キーワードを導入し、従来のtry/catchブロックをtry/catch/handle/finallyという拡張された構造で置き換える。現時点では実験的な機能として積極的に開発が進められている。 この機能が実現するユースケースは多岐にわたる。非決定性・バックトラッキング、スケジューリング・依存性注入、テスト用のモッキング・設定、例外処理、キャッシング・メモ化などが代表的な用途だ。具体例として挙げられるのがロギング機能で、エフェクトハンドラーを利用することでライブラリが実行環境（デスクトップ・モバイル・IoTデバイス・スマートウォッチ等）に応じてログ動作を自動的に適応させることができ、複雑な条件分岐ロジックを記述することなく環境別の動作を実現できる。 背景と今後の展望 Cangjieの設計思想は、関数型プログラミングと命令型プログラミングの融合にある。代数的データ型はHaskellやRustなどの関数型言語で一般的な概念であり、エフェクトハンドラーはEffectやKokaなどの研究言語で注目されてきた機能を実用的なアプリ開発言語に取り込んだものだ。これらのアカデミックな機能を産業利用を念頭に置いた言語に統合した点が、Cangjieのユニークな立ち位置を形成している。 HuaweiはCangjieをHarmonyOSエコシステムの主要言語の一つとして育てる意向があるとみられ、中国国内の大学教育への浸透はその裾野を広げるための戦略的な取り組みと考えられる。エフェクトハンドラーは引き続き実験的な段階にあるものの、安定化が進めば副作用管理の新たなパラダイムとしてより広いコミュニティへの普及が期待される。