OSS

概要 AMDは、完全にオープンソースなMixture-of-Experts(MoE)型言語モデル「Instella-MoE-16B-A3B」を発表した。総パラメータ数160億に対し、推論時にトークンごとに活性化するパラメータは28億のみという構成で、AMD Instinct MI300XおよびMI325X GPU上でゼロから学習された。モデル本体だけでなく、事前学習からポストトレーニングまでの全学習レシピ、各段階のチェックポイント、学習フレームワーク、データ構成、推論コードまで一括で公開しており、研究コミュニティが学習プロセス全体を検証・再現できる点が特徴だ。 アーキテクチャと学習の仕組み Instella-MoEは27層のデコーダ構成で、隠れ層サイズは2048、注意機構にはGated Multi-head Latent Attention(Gated MLA)を採用する。各MoE層では64個のルーティングエキスパートのうちトークンごとに6個が選択され、これに2個の共有エキスパートが加わる仕組みで、語彙数は128,896トークン。7.1兆トークン規模のコーパスで事前学習を行い、コンテキスト長は当初の4Kから64Kまで段階的に拡張された。学習パイプラインは事前学習、中間学習(midtraining)、長文コンテキスト拡張、そしてSFT・DPO・強化学習によるポストトレーニングという複数段階で構成されている。 学習効率を支えるのが、AMD独自の「FarSkip-Collective」という技術だ。これはエキスパート並列(expert parallelism)における通信を計算処理と重ね合わせることで遅延を隠す手法で、意図的に少し古い、または部分的な活性化値をMoE層・注意層に渡すことで通信待ちのボトルネックを回避する。この工夫により、事前学習速度が12.7%向上し、SGLang上でのエキスパート並列推論では初回トークン生成までの時間(Time to First Token)が最大39.2%短縮されたという。学習には、AMDが自社開発した学習フレームワーク「Primus」が用いられている。 公開内容とライセンス、今後の展望 AMDはBase、Midtrain、SFT、DPO、Think(推論特化)といった各学習段階のモデルをHugging Face上で公開しており、それぞれ用途に応じて選択できる。ライセンスは学術・研究目的での利用を前提とした「ResearchRAIL」ライセンスが適用される。推論環境としてはTransformers、vLLM、SGLangに対応し、Dockerを用いた実行環境も提供されるなど、研究者が実際に触って検証しやすい形での公開となっている。NVIDIA GPU向けの大規模言語モデル開発が主流となる中、AMDは自社のInstinct GPU上での大規模学習が実用段階にあることを示す狙いもあり、学習全体の透明性を高めることで、AMDプラットフォームでのLLM開発を後押ししたい考えとみられる。

概要 GitHubは2026年8月4日、自然言語からAIアプリを構築できるツール「GitHub Spark」の段階的な廃止を発表した。同日をもって新規ユーザーの受け入れと新規アプリの作成を停止し、既存ユーザーに対しては2026年8月31日までにアプリのコードをエクスポートするよう案内している。GitHubはこの決定の理由として、「AIモデルとエージェント型の開発ツールが大きく進化した」ことを挙げ、開発者にはVS CodeやCopilot CLI、GitHub Copilot appといった統合的なワークフローへの移行を推奨している。 既存ユーザーへの影響と対応 すでにデプロイ済みのSparkアプリは、廃止後もそのまま稼働を継続する。ただし、アプリ内でllm()関数を利用してAI推論を呼び出している場合は注意が必要だ。Sparkの推論基盤であったGitHub Modelsはこれに先立つ2026年7月30日にすでに廃止されており、llm()を使用するアプリは外部の推論プロバイダーへの置き換えが必要になる。GitHubはユーザーに対し、アプリのコード内でllm()の使用箇所を検索し、該当がなければ特段の対応は不要だと案内している。コード資産を保持したいユーザーは、8月31日までにSparkのワークベンチ画面から「Create repository」を選択し、通常のGitHubリポジトリとしてエクスポートする必要がある。 背景 GitHub Sparkは、自然言語のプロンプトからフルスタックのAIアプリケーションを生成・デプロイできるツールとして提供されてきた。しかし今回の発表では、単体ツールとしてのSparkよりも、VS CodeやCLI、Copilot appに統合されたエージェント型開発体験の方が現在のニーズに適合するとの判断が示されている。AIコーディングツール市場の急速な進化の中で、GitHubが個別プロダクトを整理し、既存の開発フローに組み込まれた形でのAI活用を推進する動きの一つと位置付けられる。

概要 GitHubは7月31日、Copilot Business/Enterprise向けにエンタープライズチーム単位でAIモデルの利用ポリシーを設定できる新機能をパブリックプレビューとして公開した。これまで組織単位でしか設定できなかったCopilotのモデルアクセス管理が、エンタープライズチームという、より業務実態に即した粒度で行えるようになる。多くの企業では8月3日から段階的にプレビューへのオプトインが可能となっている。 技術的な詳細 新機能では、管理者が各AIモデルに対して次の3段階のアクセス設定を選択できる。 Enabled: エンタープライズの全メンバーが利用可能 Disabled: 誰も利用不可 Optional: 特定のエンタープライズチームに割り当てて利用可能 評価ルールとしては最小制限戦略が採用されており、「あるユーザーが1つでもエンタープライズチームを通じてモデルへのアクセス権を得ていれば、そのユーザーはどこからでもそのモデルを利用できる」という仕組みになっている。また、複数のエンタープライズに所属するユーザーについては、それぞれ該当するエンタープライズのポリシーのみが適用される。 背景と今後の見通し 従来の組織レベルでの一律設定では、職務内容やチームの機能に応じた柔軟なアクセス管理が難しいという課題があった。今回のエンタープライズチーム単位のポリシー設定により、管理者は実際の業務構造に沿ってより細かい粒度でモデルアクセスを制御できるようになる。段階的ロールアウトが進められており、対象となるGitHub Enterprise顧客は順次この機能を利用できるようになる見込みだ。

概要 Microsoftは、言語史上初めて安定版のネイティブコンパイラを搭載したTypeScript 7.0を正式リリースした。従来JavaScriptで実装されていたコンパイラをGo言語へ全面移植したもので、実測ではVisual Studio Codeのビルド時間が125.7秒から10.6秒へと約12倍、Slackの CIビルドは7.5分から1.25分へ短縮されるなど、大手プロジェクトで軒並み大幅な高速化が確認された。Sentryでも139.8秒から15.7秒（約8.9倍）、Bluesky でも24.3秒から2.8秒への短縮が報告されており、エディタ上のエラー検出速度も17.5秒から1.3秒へと劇的に改善している。メモリ使用量についても約18%削減されたという。 技術的な詳細 今回のコンパイラは、2025年3月に実験版として発表されて以来開発が進められてきたもので、既存のTypeScriptツールセットをGoに「忠実に移植（faithful port）」した実装となっている。マルチスレッドに対応し、言語サーバープロトコル（LSP）ベースで動作する点が特徴で、--checkersと--buildersという新しいフラグにより並列処理の粒度を調整できる。UIやブラウザでの操作を想定して設計されたJavaScriptは、コンパイラのような計算集約的なワークロード向けには作られていなかったとされ、シングルスレッドの制約を超える必要性が今回の全面書き換えの背景にあるという。マイクロソフトの技術フェローAnders Hejlsberg氏は、エディタでエラーのあるファイルを開く際の速度差を実演し、TypeScript 6の17.5秒からTypeScript 7では1.3秒へと短縮されたことを示した。ベンチマークでは16コア環境で4つの型チェッカーを並列実行し、最大12コアまでのスケールが確認されている。さらに、7.0ではstrictモードとesnextターゲットがデフォルト設定に変更され、TypeScript 6.0で非推奨とされていた機能の一部は本リリースでハードエラーとして扱われるようになった。 互換性の問題と移行 一方で、コンパイラの全面刷新に伴い一部のツールとの互換性が失われている。VolarをはじめとするVue向けツール、ts-jest、Angular・Svelte・MDXのテンプレートチェッカー、ts-morphなどは、TypeScript 7.0への対応がまだ完了していない。これは、フレームワーク統合に必要なプログラマティックAPIが7.1まで実装されていないためで、TypeScript-ESLintやwebpack連携についても同様に7.1での対応待ちとなっている。また、ES5コンパイルターゲット、AMD/SystemJSモジュール形式、クラシックモジュール解決といった旧来のオプションは廃止され、指定するとビルドが強制的に失敗するようになった。新しいtsconfig.jsonでは@typesパッケージの自動読み込みも行われなくなっている。既存プロジェクトを守るため、互換性パッケージ「@typescript/typescript6」が用意されており、これを利用することで従来のツールチェーンを維持したまま移行時期を見極めることができる。Vanta のエンジニアからは「すべてが極めて高速化した」との評価が寄せられる一方、あるHacker Newsの開発者からは「責任あるかたちで移行を成し遂げたチームに賛辞を送りたい」との声が寄せられている。 今後の展望 Vue・Svelte・Angular・MDXなどが必要とする新しいコンパイラAPIは、2026年10月に予定されているTypeScript 7.1で提供される見込みだ。それまでの間、これらのフレームワークを利用するプロジェクトはTypeScript 6.0.x系列にとどまることが推奨されている。マイクロソフトは今後、3〜4ヶ月ごとのリリースサイクルで機能開発を再開する方針を示しており、7.1ではエコシステムが待ち望むAPI対応が最優先事項となる見通しだ。

概要 オープンソースのマルチメディアフレームワークFFmpegは8月3日、最新メジャーバージョンとなる9.0「Lei」をリリースした。動画・音声の変換や処理を担う業界標準ツールとして、ブラウザやメディアプレイヤー、配信基盤など幅広いソフトウェアの基盤を支えるFFmpegだが、今回のアップデートではメディアフォーマット対応の拡充とハードウェアアクセラレーションの強化が中心となっている。目玉機能はアニメーションWebPのデコードおよびデマルチプレックス対応で、これによりFFmpeg単体でアニメーションWebPファイルの再生・変換が可能になった。 Vulkanによるハードウェアアクセラレーション強化 FFmpeg 9.0ではVulkan APIを介したハードウェアアクセラレーションが大幅に拡張された。具体的には、APV（Advanced Professional Video）のビデオデコーディング、Apple ProRes RAWのVulkanアクセラレーション、そしてv360ビデオフィルタのVulkan対応が新たに追加されている。これらはプロフェッショナル向けの高品質な映像編集ワークフローを念頭に置いた強化であり、GPUベンダーを問わないVulkanの特性を活かすことで、より幅広い環境での高速処理が期待できる。あわせて、NVIDIA CUDA向けのトランスポーズフィルタも新規実装された。 AMD AMFの機能拡張とその他の変更 AMD Media Foundation(AMF)関連では、HDR対応のカラーコンバーター拡張、フレームレートコンバーター、ビデオ品質エンハンサーフィルタが追加され、AMD製GPUを用いたエンコード・処理パイプラインの表現力が向上した。このほか、SMPTE 2094-50メタデータのサポートやDolby Vision多層HEVCの分割機能も加わっており、HDRおよびDolby Visionコンテンツを扱う制作現場での活用が見込まれる。音声面では、DAB+放送などで用いられるHE-AAC 960のデコーディングにも対応した。AI関連の機能としては、ONNX Runtime DNNバックエンドがGPU実行に対応し、機械学習を用いた映像処理フィルタの高速化が図られている。一方で、長年サポートされてきたCELTデコード機能は本バージョンで廃止された。 今後の展望 FFmpeg 9.0はソースコードから最新版をビルドすることで入手可能であり、主要Linuxディストリビューションやパッケージマネージャーへの反映も順次進むとみられる。アニメーションWebP対応やVulkanベースの機能拡張は、Webコンテンツ制作からプロフェッショナル向け映像編集まで、FFmpegを基盤とする幅広いツールチェーンに恩恵をもたらすとみられ、今後のマイナーアップデートでのさらなる安定化・機能追加が期待される。

概要 Googleは、ARM64アーキテクチャのLinux向けにChromeのネイティブビルドを公式ダウンロードページから静かに公開した。Debian・Ubuntu向けの64ビットARM対応.debパッケージと、Fedora・openSUSE向けの.rpmパッケージが用意され、これによりARM64版LinuxユーザーもWidevine DRMやGoogleアカウント同期を含む、他プラットフォーム版と同等のフル機能のChromeを利用できるようになった。 背景 これまでARM64アーキテクチャのLinuxユーザーは、公式のGoogle Chromeを利用できず、各ディストリビューションが提供するChromiumビルドやコミュニティ製の代替パッケージに頼らざるを得なかった。GoogleはすでにChrome OS、Apple SiliconのMac、Windows on ARMではARM対応を進めていたが、汎用的なARM64版Linuxへの対応は長らく手つかずのままだった。今回の提供開始は、当初2026年第2四半期（6月末)に予定されていたものが遅延し、8月にずれ込む形で実現した。 インストール方法と機能 インストールは、公式Chromeダウンロードページから該当ファイルを取得し、ディストリビューションのパッケージマネージャー経由で行う標準的な手順となる。パッケージにはGoogle Chromeの公式リポジトリも同時に追加されるため、以降はAPT・DNF・Zypperを通じた自動アップデートが可能だ。拡張機能やGoogleアカウント同期、各種Googleサービスとの統合など、x86_64版と遜色ない機能セットが備わっている点も特徴で、これまでARM64版Linux環境で制約を受けてきたユーザーにとっては大きな前進となる。 今後の展望 ARM64版Linuxは、Raspberry PiやSnapdragon搭載ノートPC、各種サーバー用途などで採用が広がっており、公式Chromeのネイティブ対応はこうしたエコシステムの後押しになると見られる。今回は静かな展開であったため、今後Googleから正式なアナウンスや詳細なロードマップが示されるかが注目される。

概要 GNUコンパイラコレクション(GCC)の運営委員会は2026年7月、大規模言語モデル(LLM)から派生した著作権保護されたコードの提出を拒否する新方針を正式に採択した。焦点となるのは「AIツールを使ったかどうか」ではなく、著作権上「重要」とみなされるLLM生成資料が最終的なコントリビューションに含まれているかどうかという点である。目安としては約15行以上のLLM生成コードが対象とされ、ChatGPTやGitHub Copilotなどによって生成・編集されたコードも方針の対象に含まれる。GCCはGPLv3のもとでライセンスされており、コントリビューションの著作権的な出所を明確に保てないコードを取り込むことは、プロジェクト全体のライセンス整合性を脅かしかねないという懸念が今回の方針採択の背景にある。 方針の対象と例外 新方針では、単にLLM生成コードをコントリビューターが手作業で編集・改変しただけでは、方針の適用対象から外れない。成果物が依然としてLLM出力に基づいている場合は、著作権的に重要とみなされる限り拒否の対象となる。一方で、限定的な例外も設けられている。1つは、法的に重要でない些細な修正であり、LLMを使用した旨が明確に開示されている場合はコントリビューションとして認められる。もう1つは、著作権保護されたAI生成のテストケースであり、これは引き続き受け入れ可能とされている。 背景と意義 AI生成コードの著作権的な位置づけを巡っては、各国の著作権法や判例が定まっていない部分も多く、オープンソースプロジェクトにとっては悩ましい課題となっている。GCCのようにGPLv3という厳格なコピーレフトライセンスを採用するプロジェクトでは、コントリビューションの著作権の所在が不明確なコードを取り込むと、将来的にライセンス違反や権利関係のトラブルにつながるリスクがある。今回の方針採択は、こうしたリスクを未然に防ぐための予防的措置と位置づけられ、主要オープンソースプロジェクトがAI生成コードにどう向き合うべきかを示す先行事例として注目されている。他の大規模OSSプロジェクトも今後、同様の方針を検討する可能性がある。

概要 Rust向けの非同期ORM「SeaORM」の開発チームは、バージョン2.0を正式にリリースした。2025年7月の最初のリリース候補（RC）公開から43回ものRCを重ねた末の到達であり、プロジェクト史上最大規模のアップデートと位置付けられている。SeaORMは2021年9月に初版が公開され、2024年8月に最初の安定版1.0に到達しており、今回の2.0は約2年ぶりのメジャーアップデートとなる。GitHubスターは約9,800、crates.ioでの累計ダウンロード数は2,200万を超え、278名の貢献者が900件以上のIssueと885件のPull Requestを積み重ねてきた、Rustエコシステムを代表するORMの一つである。 主な新機能 今回の目玉は「Entity Firstワークフロー」だ。これはエンティティ定義から自動的にデータベースのテーブル構造を生成・同期する仕組みで、db.get_schema_registry("my_crate::entity::*").sync(db).await?; のような呼び出しでスキーマとコードの一貫性を保証する。これにあわせてエンティティの生成形式も刷新され、sea-orm-cli generate entity --entity-format dense によって生成される新しい「密集型（dense）フォーマット」では、リレーションが型付きフィールドとしてモデル上に直接存在するようになった。外部キーの必須・任意は BelongsTo<Entity> と BelongsTo<Option<Entity>> という型で表現され、より簡潔な記述が可能になっている。 保存処理も大きく変わった。「ネストされたActiveModel」機能により、親子関係にある階層的なオブジェクトを1回の呼び出しでまとめて保存できるようになった。システムが変更箇所を自動検出し、外部キーの依存順序に沿って一括トランザクションを実行する仕組みだ。また、従来はEnumのバリアント（例: user::Column::Name）で表現していたカラム参照が、user::COLUMN.name のような強い型付きの定数に置き換えられ、誤ったカラム指定が実行時エラーではなくコンパイル時エラーとして検出できるようになった。 その他の拡張とエコシステム 2.0では非同期APIを持たない「同期型SeaORM」が追加されたほか、Arrow・Parquet形式への対応により分析用途での利用も見据えている。データベース対応も拡大し、商用版「SeaORM X」経由でSQL Serverがサポートされた。周辺プロジェクトも合わせて進化しており、GraphQL APIを自動生成する「Seaography」は再生成不要な2.0にアップデートされ、商用版「SeaORM Pro」にはロールベースアクセス制御が追加された。クエリビルダーの「SeaQuery」もバージョン1.0に到達し、1.7k以上のスターを獲得している。 移行と今後の展望 開発チームは後方互換性を重視しており、「1.0のAPIは2.0でもそのまま動作し、段階的なアップグレードが可能」としている。主な変更点はエンティティ形式であり、belongs_to フィールドが BelongsTo<Entity>（またはOption型）へと置き換わる点が中心で、詳細な移行ガイドも別途用意されている。プロジェクトが掲げる目標は「Rustエコシステムにおけるデフォルトのデータレイヤーになること」であり、Active Recordパターンの持つ生産性とRustの型安全性を融合させる方針だ。開発チームは今回の2.0を、そのビジョンに対する「明確な回答」と位置付けている。

概要 Microsoftは7月29日、Visual Studio Codeの最新版となる1.131をリリースした。今回のアップデートはAIエージェントを活用した開発ワークフローの強化に主眼が置かれており、エージェントが複雑なタスクをサブエージェントに委譲する際の進捗を可視化する機能、拡張機能なしで使えるオンデバイスの音声入力(ディクテーション)機能、Agentsウィンドウ内でMarkdownファイルを直接編集できるハイブリッドエディタなど、複数の実験的機能が新たに追加された。 サブエージェントの可視化とAgent Hostアーキテクチャ Agentsウィンドウでは、エージェントが処理を委譲したサブエージェントの状態をリアルタイムで確認できるようになった。表示される情報には使用中のモデル名、実行経過時間、アクティブなツール呼び出しが含まれる。サブエージェントを選択すると、そのタスクの完全な進捗を別チャットで確認しながら、親となる会話も引き続き利用できる。 この機能の裏側では、専用プロセスで実行される「Agent Host Protocol(AHP)」の展開が進んでいる。これにより、単一のエージェントセッションを複数のVS Codeウィンドウから同時に接続できるようになり、エージェントの処理と表示側のプロセスを分離するアーキテクチャへの移行が進行中であることがうかがえる。 ディクテーション機能とMarkdownエディタ 実験段階の機能として、チャット・エディタ・統合ターミナルで利用できる組み込みディクテーション(音声入力)機能が追加された。従来必要だった音声認識用の拡張機能なしに、プライベートかつオフラインで動作するNemotronモデルを採用しており、音声データは一切デバイス外に送信されない。設定はdictation.enabled、dictation.showTranscript、dictation.experimental.llmCleanupの各キーで制御する。対応プラットフォームはWindows(x64/Arm64)、macOS(Apple silicon)、Linux(x64/Arm64、glibc 2.34以上)で、VS Code for the WebやIntel搭載Macは非対応となっている。 もう一つの実験的機能であるハイブリッドMarkdownエディタは、workbench.editor.markdownDefaultEditorInAgentsWindow設定を通じてAgentsウィンドウ内でMarkdownファイルの表示・編集を可能にするもので、エージェントが内容に対してコメントを追加できる仕組みも備える。「Reopen Editor With」機能を使えば通常のテキストエディタへの切り替えも可能だ。 その他の変更点 AI関連以外にも、Python Environments機能が100%ロールアウトを完了し、デフォルトの体験として確立された。環境スキャンを並行実行するよう統合したことで、起動速度も向上している。ターミナル周りでは、リサイズ時のオーバーレイ表示をterminal.integrated.resizeDimensionsOverlay.enabled設定で制御できるようになったほか、スクリーンリーダー対応も改善された。また、チャットで/vscode-petと入力すると新しいペットキャラクターが登場する遊び心のある実験的機能も追加されている。 今回のリリースは、サブエージェントの可視化やAgent Host Protocolの展開など、AIエージェントを中心とした開発体験の刷新が続いていることを示しており、今後のアップデートでもエージェント関連機能のさらなる強化が見込まれる。

概要 Cloud Native Computing Foundation（CNCF）とIT分野専門の調査会社SlashDataは、日本国内のクラウドネイティブ開発者コミュニティが約100万人規模に達したとする調査結果を発表した。両者は2025年12月から2026年1月にかけて、95カ国から1万2500件以上の回答を集めて調査を実施し、世界全体のクラウドネイティブ開発者数は約1990万人、うち日本は約95万人（CNCFの発表ベースでは約100万人）と推計されている。日本市場の規模の大きさが改めて示された形だ。 日本市場の技術動向 調査からは、日本のクラウドネイティブ環境が海外と異なる成熟パターンをたどっていることも浮き彫りになった。海外ではオンプレミス、プライベートクラウド、ハイブリッドクラウドの採用率がいずれも30％台とほぼ拮抗しているのに対し、日本は依然としてオンプレミスへの依存が強い。過去12カ月の技術導入率を見ると、APIゲートウェイが47％、マイクロサービスが39％である一方、Kubernetesは27％にとどまっている。 CNCFはこのKubernetes採用率の低さについて、開発者がKubernetes以外の環境でマイクロサービスをデプロイしている可能性や、プラットフォームエンジニアリングの成熟が進んだ結果、Kubernetesが抽象化され開発者から見えにくくなっている可能性を指摘している。単純な「Kubernetes離れ」ではなく、活用の仕方が変化していると分析している点が興味深い。 成熟度モデルと今後の展望 調査ではクラウドネイティブの成熟度を3段階に整理している。まず「基礎」段階はKubernetesとマイクロサービスの組み合わせ、次の「主流」段階では可観測性ツールやストリーミング/メッセージング、イベント駆動型アーキテクチャが導入される。そして「高度な実践手法」の段階では、不変インフラやカオスエンジニアリング、サービスメッシュといった技術が用いられる。中でも「フィーチャーフラグ」は、主流段階から高度な段階への移行を後押しする重要な役割を果たしていると分析されている。 日本市場はオンプレミス依存やKubernetes採用率の低さから、海外に比べて成熟度モデルの初期段階にとどまる開発者が多いと見られる。一方で開発者人口自体は世界有数の規模を誇っており、今後プラットフォームエンジニアリングや可観測性ツールの普及が進むことで、成熟度の底上げが進むかが注目される。