112x
全並列リンカ「mold」、GNU ld比の最大高速化
320B
GLM-5.3-FlashのMoE総パラメータ数(アクティブ18B)
99.4→0.0
kqueue化前後の自作Webサーバー、アイドル時CPU使用率(%)
🔥 Top Stories
組み込み型OLAP分析データベース「DuckDB」は、単一ファイルで動きPythonやRから直接クエリできる手軽さで急速に採用が広がった。開発元のDuckLabsはオランダ・アムステルダム拠点で、創業者のHannes MühleisenとMark Raasveldtが技術方向性を率い、AWSとは2024年から協業関係にあった。AWSは8月26日、DuckLabsの買収合意を発表した。DuckLabsは2026年9月上旬にもAWS傘下入りする見通しで、買収額は非公開。チームはアムステルダム拠点を維持したまま、DuckDB・DuckLake・Quackプロトコルなど関連プロジェクトの開発を続ける。重要なのは、AWSが買収するのはDuckLabsという「会社」であり、DuckDBという「オープンソースプロジェクト」そのものではない点だ。DuckDB本体はMITライセンスのまま、非営利のDuckDB Foundationがガバナンスとロードマップの主導権を維持し、ライセンスやロードマップの一方的な変更は行わないと明言されている。一方で、商用サポートやクラウド連携といった収益源はAWSのリソースを得て強化される可能性が高く、Snowflake・Databricksなど競合の分析クラウド陣営にとっては、有力なOSSプロジェクトの後ろ盾がAWSになるという構図の変化でもある。
🧠 「プロジェクトはMITライセンスの非営利財団に残る」という説明は法的には正確だが、主要コミッターの雇用主が唯一の大口クラウドベンダーになる以上、今後の機能開発がAWS自身のニーズに寄っていく可能性は否定できない。現時点でライセンスやガバナンス変更は確認されておらず、この点は事実として評価できる。ただし、Snowflake・Databricksなど競合クラウド上でのDuckDB統合が今後も同じ速度で進むかは、まだ誰にも分からない。
- DuckLabsは2024年からAWSと協業関係にあり、買収完了は2026年9月上旬を予定、買収額は非公開
- DuckDB・DuckLake・Quackプロトコルなど全プロジェクトはMITライセンスのまま非営利DuckDB Foundationの管理下に残り、創業者2名(Hannes Mühleisen、Mark Raasveldt)が技術方向性を継続主導
- チームは買収後もアムステルダム拠点を維持し、ライセンス・ロードマップ・ガバナンスモデルに変更はないと明言
💡 DuckDBを組み込んだ分析パイプラインやローカル開発環境を使う開発者にとってライセンス面のリスクは低いが、今後の新機能がAWSサービスとの連携を優先する形で追加されないか、ロードマップは注視する価値がある。
DuckDB Blog
⏱ 6 min read
▲ 951
2026-08-26
Zhipu AIは8月26日、GLM-5シリーズで初めてネイティブにマルチモーダル対応した「GLM-5.3-Flash」を公開した。総パラメータ3200億(320B)・アクティブパラメータ180億(18B)のMoE構成で、コンテキスト長は最大100万トークン、出力は最大12.8万トークンに対応する。30兆トークン規模のマルチモーダルコーパスで事前学習し、Zhipu独自のArtificial Analysis Intelligence Indexで57点を記録、AnthropicのClaude Opus 4.8と同水準になったという。重みはMITライセンスでHugging Faceに公開され、API価格はフラッグシップ「GLM-5.3」の10分の1、9月9日までは半額キャンペーンも実施中だ。
- 総パラメータ3200億・アクティブ180億のMoE、コンテキスト最大100万トークン・出力最大12.8万トークン
- Artificial Analysis Intelligence Indexで57点、Claude Opus 4.8と同水準の性能を主張
- 重みはMITライセンスでHugging Face公開、API価格はGLM-5.3本家の10分の1(9月9日まで半額)
Z.ai Blog
⏱ 4 min read
▲ 848
2026-08-26
Linux Foundation傘下のAgentic AI Foundationは、Model Context Protocol(MCP)の新たな開発ロードマップを公開した。優先領域は5つ。単発のチャット応答を超え、サーバー側からストリーミング結果をプッシュしクライアントがポーリングなしにイベントを受け取れる「AIエージェントメッセージング」、WebSocket・stdio・ローカル接続が混在する現状をHTTPベースへ一本化する「トランスポート統一」、人間のブラウザ承認を前提とした現行認証を離れAIエージェント自身がIDを持ちサブエージェントへ権限委譲できる「エージェントID」、カテゴリからツール一覧を絞り込む段階的開示などの「プリミティブ改善」、そしてSDKの直感性・ドキュメント精度を高める「開発者体験」だ。7月にはEnterprise-Managed Authorizationが安定化し、7月28日にはステートレス接続を導入する仕様更新も行われている。
- 5つの優先領域:AIエージェントメッセージング、HTTPトランスポート統一、エージェントID、プリミティブ改善、開発者体験
- 現行認証は人間のブラウザ承認が前提、新ロードマップではAIエージェントがトークン交換・監査機構を伴う独自IDでサブエージェントに権限委譲できる設計を目指す
- 7月にEnterprise-Managed Authorizationが安定化、7月28日の仕様更新でステートレス接続を導入済み、個別項目の完了時期は未定
Publickey
⏱ 4 min read
2026-08-26
⚡ Dev & Engineering
AIエージェントに実装を任せると分岐が減らないのは指示不足ではなく、型がゆるく無効な状態を許してしまうからだと指摘する記事。`isLoading: boolean`と`error: Error | null`を別々のフラグで持つと理論上8通りの組み合わせが生じるが有効なのは4通りだけで、残りを弾く`if`文がレビューのたびに「本当に起こり得るか」を人力で確認する負債になる。
- ゆるい型(フラグ4つの組み合わせ)は理論上8状態を許すが有効なのは4状態のみ、残り4状態を弾く防御的な分岐がレビュー負債化する
- discriminated unionで状態を「loading/loaded/failed」の直和型3つに絞ると、コンパイラのexhaustiveness checkが未対応の分岐を自動検出する
Zenn
⏱ 4 min read
2026-08-25
TokioやmioなどのランタイムクレートなしにRustでWebサーバーを実装する過程を追った記事。libcクレートだけを使いkqueue()でイベント通知用ファイルディスクリプタを作り、kevent()でEVFILT_READ/EVFILT_WRITEを登録、accept()・read()・write()をFutureトレイトとして実装しWakerでランタイムに通知する。busy-loop実装ではCPU使用率が`R+ 99.4`だったのに対し、kqueue実装ではアイドル時`S+ 0.0`まで下がり、OSがブロッキング待機を肩代わりする効果を実測している。
- kqueue()でイベント通知用fdを生成、kevent()にEVFILT_READ/EVFILT_WRITEフィルタを登録してソケットイベントを検知する設計
- busy-loop実装のCPU使用率`R+ 99.4`に対しkqueue実装はアイドル時`S+ 0.0`まで低下、accept/read/writeをFutureとして実装しWakerで通知する構成が要
Zenn
⏱ 5 min read
2026-08-24
プロジェクト管理・CRM・工数管理・ダッシュボードを持つ建設業向けERPを、TanStack Start(SSR+ファイルベースルーティング)・Hono・oRPC+Zod・Cloudflare Workersのフルスタック構成で構築した事例。月末に全社員が一斉に工数を入力する運用のため、書き込みをデータベースレベルで直列化するD1ではなく、行単位で同時実行できるPostgreSQL(Cloudflare Hyperdrive経由)を選択し、プロジェクト単位のadvisory lockで無関係な処理同士のブロッキングを防いだ。API契約はサーバー実装やスキーマから独立した別パッケージに分離し、EVM(出来高管理)計算をI/Oを持たない純粋関数としてサーバー集計とクライアント詳細表示の両方から共有することで、一覧と詳細で数値が食い違う不整合を構造的に排除している。
- 月末一斉入力の同時書き込みに対応するため、書き込みを全体直列化するD1ではなくPostgreSQL(Hyperdrive経由)+プロジェクト単位advisory lockを採用
- EVM計算(PV/EV/ACの3値から7指標を導出)をI/Oなしの純粋関数としてAPI契約パッケージに集約し、サーバー集計とクライアント表示の数値乖離を構造的に防止
Zenn
⏱ 5 min read
2026-08-25
PostgreSQLからCloud Spannerへの移行後、382テーブルのうち134テーブルを廃止しつつ248テーブルのER図を再構築した事例。`gcloud spanner databases ddl describe`でSpannerのDDLを抽出し、既存の222テーブル分のER図と物理名一致で187テーブルを自動継承、英語プレフィックス付き57テーブルのうち54テーブルは既存ドキュメントを流用した。残る9フィールドだけを人手でレビューする設計とし、Pythonスクリプトによる差分マージとAIエージェントによる差分分析・命名提案を組み合わせている。
- 382テーブル中134テーブルを廃止対象として除外、残り248テーブルを「継続」「英語版」「新規基盤」「削除」の4分類に整理
- 既存ER図(222テーブル分)との物理名一致で187テーブルを自動継承、最終的に人手レビューが必要だったのは9フィールドのみ
Qiita
⏱ 5 min read
2026-08-25