世界を動かす技術を、日本語で。

QGISがAI支援による貢献を禁止

2026年10月12日原文(github.com)

概要

  • 2026年10月12日に複数の重要な技術・セキュリティ関連ニュースが発生
  • ヨーロッパのスーパーマーケット冷蔵システムがサイバー攻撃で大規模障害
  • QGISがAIによるコード貢献を全面禁止する新方針を採用
  • Alibaba Qwenが長期エージェントタスク向け強化学習フレームワークQwenGyreを公開
  • その他のニュース・技術情報については既存アーカイブや既報との重複を理由に省略

欧州スーパーマーケット冷蔵システムへの前例なきサイバー攻撃

  • Danfoss製冷蔵制御システム を悪用したサイバー攻撃が、フランスの Intermarché、Leclerc、Coopérative U などで発生
    • 自動霜取り機能が50℃で連続稼働に設定され、 配送や電子棚札による価格表示も混乱
    • Coopérative Uの社長Dominique Schelcherが「極めて深刻かつ前例がない」とXで認める
  • オランダの Albert Heijn、Etos、Gall & Gall も日曜午後のサイバーインシデントでウェブサイトを停止
    • Delhaize(Ahold Delhaize傘下) でも障害発生
    • 初期損失は約30万ユーロ、全国規模では数百万ユーロに達する可能性
  • Tom's Hardware 記事(2026-10-12)で確認、他メディアは未検証
  • 過去に類似ケースなし、セキュリティキャンペーン枠で分類

QGIS、「AI貢献全面禁止」方針へ転換

  • QGISプロジェクト がQEP428「AIによる貢献全面禁止」案(PR #387, Nyall Dawson作)を 2026年10月7日にマージ
    • 以前の「人間レビュー必須・透明性確保」方針(QEP-408)を完全廃止
    • 「AI、LLM、エージェント支援によるコード貢献一切禁止」
      • 違反時はコードリバートとコントリビューター権限の制裁
    • Dawson氏は「まず完全禁止し、将来個別に解禁を検討」と説明
      • 旧方針は実運用されていなかった、既に有力貢献者を失った経緯
  • GitHubのPRページと.diffで内容確認、APIは未到達
  • QGIS関連で初の事例、AIコーディングガバナンス枠で分類

Alibaba Qwen、「QwenGyre」強化学習フレームワーク発表

  • Alibaba Qwen が長期エージェントタスク用オンライン強化学習フレームワーク QwenGyre を公開
    • 数時間・数百万トークン規模のエージェントランを想定
    • GPUリソースを動的分割 し、タスク終了ユニットを即座に再利用
    • Token-in Token-out 方式で出力文脈を完全記録し、軌跡をツリーベースで管理
    • Partial Scoring でタイムアウトした部分的タスクにも有用なフィードバック
  • NL2RepoBench 実験でパス率52.5%→58.5%、同等GPU予算で1.78倍高速化
    • Qwen3.6-122Bで NL2RepoBench/DeepSWE/TerminalBench をカバー
  • 公式ブログ・GitHubは未到達、ithome.com記事で確認
  • QwenGyreは初報、AIフレームワークリリース枠で分類

その他の主要ニュース・省略事項

  • 既報・重複・非技術領域 のニュースは省略
    • 例:Ledgerウォレット攻撃、Python 3.15リリース、SonicWall脆弱性、消費者向け製品発表など
  • 新規性・検証性・技術的意義 を満たすもののみ追加
  • 各フィードやニュースソースの最新情報もクロスチェック済み

Hackerたちの意見

これでオープンコントリビューションの終わりかな。メンテナはすでにやることが多すぎるし、LLMを使って自分でレビューできるから、時間を節約できる貢献者を見つけるのがますます難しくなってる。

└

誰かが貢献したいなら、そのプロジェクトに価値を生み出してることを証明する必要があると思う。これが論争になるとは思わないな。オープンソースである以上、貢献が拒否されたらフォークすればいいだけだし。オープンマーケットの競争が、貢献が本当に価値があったのか、元のプロジェクトのオーナーが見誤ったのか、あるいはその貢献が本質的に無価値だったのかをすぐに判断することになるよ。

└

それを踏まえると、問題はメンテナのボトルネックを悪化させてるよね。外部からの貢献を受け入れないと、新しいメンテナを見つけるのはどうするの?もう一つの方法は、貢献者にPRのレビューに対して小さな手数料を払わせることかも。AIの雑なものを減らすためにね。新しい貢献者には学生や低賃金の人を除外するかもしれないけど、1ドル以下でも十分だと思うな。

└

これは特定のリポジトリにおけるオープンコントリビューションの終わりに過ぎないよ。QGISのUIアプリケーションに関する話で、GDALやGEOS、その他の機能を提供するライブラリには関係ない。さらに、ここ数年でオープンコントリビューションを受け入れる新しいオープンソースプロジェクトの数と人気は、そうでない古いプロジェクトの数をはるかに超えてるからね。

└

最近の経験から言うと、オープンソースに貢献する最良の方法は、詳細なイシューを書くことだと思う。メンテイナーはそれをAIツールに貼り付けて、フィードバックをコメントして待つよりも早くやり取りできるからね。

└

まだ機能することはあるよ。例えば、https://github.com/emdash-cms/emdash/issues を見てみると、AIを使って自動的にトリアージしてPRを作成するツールがたくさんあるんだ。

└

確かに、ほとんどのプロジェクトは特にガードが固いよね……AIが登場する前からそうだったし。変わったのは、変更がしやすくなったこと(従来の一行のREADME編集の代わりに、適当に変更する感じ)と、プロジェクトをフォークしやすくなったことだよね。従来はPRを開いても、スタイルや手続きの問題でクローズされたり、無視されたりすることが多かった。メンテナンスが面倒だからフォークしないことが多かったけど、LLMがあればそうでもないよね。今は自分の変更を実装して、雰囲気でフォークするだけでいいんだから。

なんでみんなHNでAIに賛成ばっかりなの?これは客観的に見ても良い変化だと思うよ。長期的に見てコードの質が向上するからね。

└

本当にそうなるの?たくさんのオープンソースプロジェクトには、手作業では直すのが面倒すぎて、何十年もバグが放置されてるのに、今はAIで5分もあれば直せるんだよ。良いLLMはコメントやテストの更新にももっと真面目に取り組んでることが多いし。

└

なんでみんなHNでAIを支持してるの?便利なの?大体うまくいくの? > これは客観的に見ても良い変化だよ。長期的にコードの質が向上するからね。依存する?そうだね、ヒットアンドランの大量AI生成PRを禁止するのは助けになる。これらはAI以前からの問題で、人々は努力せずに自分の名前を載せたいだけなんだよね。これによって、問題を解決したり新しいものを追加する高品質なPRも禁止されちゃうかも。どちらにしても、様子を見よう。誰でもフォークできるし、もしそれがより良いプロジェクトなら、そっちが勝つだろうね。

└

AIの支援が必ずしもコードの質を下げるわけではないよ。多くの方法で改善を助けることができる。慎重なレビューなしに完全にvibeコーディングをすると、低品質なコードが生まれるんだ。だけど、多くのプロジェクトはそのバランスを取るのが難しいと思う。LLM支援の貢献を許可すると、どんなに高品質を目指しても、低品質な貢献が大量に押し寄せてきて、それをフィルタリングして拒否するのに余計に手間がかかるんだ。全てを一律に禁止すれば、拒否するのがずっと楽になるけどね。リンクされた議論は、全てのLLM支援の貢献が悪いわけではないけど、今は流れを抑えて、後でどう開放するかを考える必要があるという視点で行われているんだ。

└

自分の意見を客観的だと言うのは良くないよ。これは意見が分かれることがあるからね。

Hacker Newsで議論の続きを見る