2026年7月16日号

新しい既定値では、パッケージがレジストリで公開されてから少なくとも3日経過するまで、Dependabotはバージョン更新PRを開かない。公開直後に判明する破損やサプライチェーン侵害の兆候をコミュニティが検出する時間を確保する狙いで、GitHubのホスト環境にある全対応エコシステムへ設定不要で適用される。GHESでは3.23から導入予定だ。

この待機は通常のバージョン更新だけが対象で、既知の脆弱性を修正するセキュリティ更新は即時に作成される。鮮度の要求が異なる場合は、Dependabot設定内のcooldown項目で期間を変更または無効化できる。更新滞留時間と緊急修正の到達時間を別々に監視すれば、安全側の既定値を保ちながら例外を絞り込める。

一般提供されたREST APIは、custom patternsのGET、POST、PATCH、DELETEを提供し、リポジトリ、Organization、Enterpriseの各スコープで利用できる。これにより、社内トークンや接続文字列の形式をコードから生成し、対象階層ごとの定義を収集して差分を確認できる。利用対象はSecret Scanningの顧客で、権限とスコープを分けた自動化が前提になる。

APIが扱うのは作成、変更、削除などの基本CRUDで、候補パターンのdry runと最終公開はまだGitHubのUIに残る。これは完全自動化の制約である一方、誤った正規表現による大量検知や見逃しを人が確認する境界にもなる。設定リポジトリで変更理由と対象を管理し、API適用後にUIで検出例を承認する二段階フローが現実的だ。

Preview 6は.NET 11の6回目の試験版で、単一機能ではなく開発スタック全体の差分をまとめている。Runtimeには非同期処理やJIT、NativeAOTの改善が入り、ライブラリではDataAnnotationsの非同期検証やSystem.Text.JsonのC# union型シリアライズが加わった。C#、EF Core、F#、MAUI、コンテナイメージにも個別の更新がある。

日常のツールチェーンでは、dotnet testのオプションと出力が改善され、xUnit v3とNUnitのテンプレートがMicrosoft.Testing.Platformへ対応した。Podmanによるマルチアーキテクチャのコンテナ公開も対象だ。ASP.NET CoreではMinimal APIの非同期検証、自動CSRF保護、OpenAPI 3.2の既定化が加わるため、評価では既存テスト、生成仕様、認証フローの差分を同時に記録する必要がある。

Notebook editorはipynbファイルの既定体験となり、分割表示、セルタグ管理、セル内選択実行、Quarto・Python・Rへの書き出し、PDFのインライン表示を備える。Packages paneは実行中セッションのRとPythonパッケージを検索、追加、更新、削除でき、requirements.txtやrenv.lockと環境の整合性確認にも使える。主要な編集と依存管理がプレビューを離れた。

従来のAI機能を置き換えるPosit Assistantも一般提供となり、管理者はai.enabledで利用可否を強制できる。DeepSeek対応は実験段階、Microsoft Foundry対応は一般提供という差がある。Data ExplorerはExcelと圧縮CSV、TSV、ParquetをDuckDB経由で扱い、Data Connectionsはまだプレビューだ。機能ごとの段階を分けて導入計画へ落とす必要がある。

新しいcf.logCustomData()は、viewer requestとviewer responseのCloudFront Functionsから任意の判断値をアクセスログレコードへ追加する。A/Bテストのバリアント、認証の成否、ルーティング先のように、レスポンス結果を解釈するための文脈をリクエスト記録と同じ場所へ置ける。CloudWatch Logsに出した関数ログを後から結合する必要が減る。

機能はCloudFrontの全エッジロケーションで利用でき、リアルタイムログと標準ログv2の両方に対応する。利用自体の追加料金はないが、関数呼び出しとログ配信の通常料金は発生し、console.log()も残る。まず少数の分岐値に絞り、機密情報を除外したスキーマと保存期間を決めてから、障害調査時間が短縮するか測定するのが安全だ。

Exporterは外部状態をPrometheus形式へ変換する小さなHTTPサーバーとして実装し、/metricsと生存確認用の/healthzを別エンドポイントにする。累積値にはcounter、上下する現在値にはgauge、分布にはhistogramを使い分ける。記事のコンテナ例はマルチステージビルドとdistrolessの非root実行を採用し、実行時イメージの攻撃面を抑えている。

Prometheus Operator環境ではServiceMonitorのselectorとServiceのlabelを一致させ、Prometheus側のrelease labelにも注意する。アノテーションによるscrapeも代替になるが、Prometheusが値を収集しただけではHPAは読めない。Custom Metrics APIへ橋渡しするPrometheus Adapterを構成し、欠損、遅延、急増をテストしてからスケール条件へ使う必要がある。

7月3日、.AL運用者が新しいDNSKEYを公開して旧鍵を停止した一方、ルートのDSレコードは旧鍵を指したままとなり、検証リゾルバは応答を拒否した。Cloudflareは約3時間後の17時15分UTCまでに1.1.1.1へNegative Trust Anchorを展開し、対象ゾーンを一時的に未署名として扱って名前解決を戻した。ただし、その間はDNSSECによる真正性保証を停止するトレードオフがある。

今回、NTA適用中の応答にはEDE 33が付き、根本原因のDNSKEY不一致を示すEDE 9と同時に返った。NOERRORと有効な回答があっても検証済みではないことをクライアントが判別できる。EDE 33はIANAから番号を割り当てられ、kdigは名称表示に対応したが、Internet-DraftはIETF DNSOPでこれから議論され、Unbound対応もレビュー中だ。監視側は標準化と実装差を前提に扱う必要がある。

各crateページのCodeタブは、Cargoが依存追加時に取得する公開版の内容をファイルツリー、検索、シンタックスハイライト付きで表示する。リンク先リポジトリには存在しない正規化済みCargo.tomlなども確認できる。バックエンドはランダムアクセスできないgzip tar形式の.crateをZIPとJSONマニフェストへ変換し、CDNから必要なファイルだけをHTTP Rangeで返す。旧版もバックフィル済みだ。

同じ更新では、RustSecが保守停止としたcrateへのバナー、標準ライブラリの代替候補、Svelteへのフロントエンド移行完了も報告された。検索は順位付け対象を最大1000件へ制限し、逆依存数は事前計算することで応答を安定させている。依存監査ではCodeタブをレビュー手順へ加え、警告だけで置換せず互換性と移行費用を確認するのがよい。

Qwen 3.5-397Bは約400GBの重みを持ち、512 expertsのうち一部だけをトークンごとに活性化する。Googleは2つのKV headsという注意機構の形とexpert数を同じ分割で扱わず、Attention Data ParallelismとExpert Parallelismをそれぞれ8-wayにした。JAXとPallasで、Batched RPA、Grouped GEMM、SparseCore unpermutationなどを独立したカーネルとして最適化している。

Googleの報告では、Ironwood 4チップ・8論理デバイスの単一ホスト、並行度512という条件で、4月から6月の間にdecode重視で約3.1倍、prefill重視で約4.7倍の改善を得た。成果はvLLMとSGLangへ統合する方針だが、この値を一般性能として扱うべきではない。入力長、出力長、バッチ、通信量を揃えた再現ベンチマークが採用判断の前提になる。

RFC 9989では、DMARCレコードが見つからないときの組織ドメイン探索が、外部のPublic Suffix Listを使う方式からDNSの親方向を最大8回調べる方式へ変わった。これにより受信システムが参照するポリシー境界が一部で変わり得る。IIJは、旧RFC 7489実装と新実装の結果を揃えるため、実際に使う組織ドメインとサブドメインへレコードを明示する方針を示す。

新しいnpタグは、存在しないサブドメインから届いたように見えるメールへ別ポリシーを指定でき、IIJはnp=rejectを推奨している。ただしp=rejectを含む強制ポリシーは、転送やメーリングリストなど相互運用の影響をレポートで確認してから進める必要がある。送信元の棚卸し、明示設定、レポート監視、段階的な拒否という順序が移行差を減らす。

LINEヤフーはAIDDを、AIへ仕事を丸投げする方式ではなく、要件整理から設計、実装、レビューまでAIと人の役割をつなぐ開発プロセスと定義する。WorkshopにはLINE Plusを含む21チーム112人が参加し、各チームが現実の業務テーマを持ち込んだ。個人参加ではなく、企画やリーダー、意思決定者を含むチーム参加にした点が設計上の核だった。

報告で繰り返される障害はツール操作ではなく、AIへ渡せる仕様、用語、既存コードとの関係、レビュー基準が整理されていないことだ。2日間で課題と文脈を可視化しても、その後の担当、評価方法、実務への接続がなければ定着しない。導入側は利用回数より、文脈整備に要した時間、レビューで戻った理由、次工程へ渡せた成果物を測る方が組織能力を把握しやすい。

Publickeyが報じたGartnerの予測は、AI前提の小規模チームを単なる人員削減策と捉えず、事業理解から製品設計、AIエージェント監督までを担う構成と、ジュニア人材の育成経路を同時に設計すべきだと補足する。これは、Workshop後の担当と判断基準まで決める必要があるというLINEヤフーの実践知を、組織設計の側から補強する。