20261101GISA-FOSS4G

20261101FOSS4GにおけるAIガバナンスをめぐる考察

Transcript

1. 2026/11/01 地理情報システム学会 FOSS4G分科会 KOMAZAWA UNIVERSITY 文ロ ゴタ イプ 等） Visual Identity Guidelines A02 Kマ ーク ＋和文ロ ゴタ イプ の組み合わせ は、左の3 種です。 横1 基本形とし 、優先的に使用し ます。 横2 FOSS4GにおけるAIガバナンスをめぐる考察 ワン ポイント など 、 「 横1 」が配置し にく い 場合に使用し ます。 縦1 瀬戸 寿一*,** 縦型サインなど、細長い配置に使用し ます。 必ずマスタ ーデータ を 使用し てく ださ い。 縦1 左記以外の組み合わせを 作成し な いで *: 駒澤大学文学部地理学科・准教授 **: デルフト工科大学(TU Delft) 建築・建造環境学部 く ださ い。 https://tossetolab.github.io/ tosseto@komazawa-u.ac.jp 1
2. 2026/11/01 地理情報システム学会 FOSS4G分科会 2 FOSS4G Hiroshima 2026（FOSS4G Global) https://talks.osgeo.org/foss4g-2026/schedule/ • 約370セッションのうち，AI関連 を主とした発表は56 （全体の15%) – AiｘOSSコミュニティ（12件） – MLによる空間分析（10件） – LLMエージェント＋MCP（9件） – RAG、知識グラフ（7件） – AI基盤、モデル・データ（7件） – データアクセシビリティ（6件） – 深層学習・CV（5件）
3. 2026/11/01 地理情報システム学会 FOSS4G分科会 3 FOSS4G.NL(2026年7月開催) →基調講演は「デジタル主権の強化に向けて」
4. 2026/11/01 地理情報システム学会 FOSS4G分科会 4 本日の報告内容 1. 生成AI時代のソフトウェア開発 2. OSGeoMLでの議論とQGISコミュニティの議論経過 3. 他のFOSS4G開発における状況 ・技術面：ソースコードを変更する妥当性／AIが保守を持続できるのか？ ・制度やライセンス：人自身の創作性／ライセンスの許容／トレーサビリティの確保 ・コミュニティ：レビューの負担／開発＆活用の人材育成／ツールの信頼性 ※本発表を作成するうえで、議論に関するログの取得および日本語翻訳の予備作業を、 Open Code 『DeepSeek V4.1 Flash』を用いて行った。
5. 2026/11/01 地理情報システム学会 FOSS4G分科会 生成AI時代のソフトウェア開発 (Pereira,2026) • 開発プロセス全般におけるテーマ別AIツールの評価 – 7章構成：コード生成・オートコンプリート、UI/UXデザイン、 バグ検出・コードレビュー、自動テスト＆品質保証、予測分析・ パフォーマンス最適化、ドキュメンテーション、チャットボット ＆バーチャルアシスタントの主要工程の解説 • 評価プロセス・フレームワーク – 最新ツールの製品レビュー＋生成AIツールの評価基準の提示 – それぞれのツールに対して，簡単な指示を出し出力結果を比較 （1〜10点で採点） • 実践的な導入事例と「人間（開発者）」の再定義 – 個人開発者からShopify（大企業）までの導入ケーススタディ （バイブコーディングの活用や組織導入など）を紹介 – ハルシネーションやセキュリティリスクを防ぐための人間による コードレビュー・テストの重要性 – 開発者が「コードを（直接）書く作業者」から「（生成AIに）設 計・指示・検証を担うアーキテクト」へシフトする必要性に言及 5
6. 2026/11/01 地理情報システム学会 FOSS4G分科会 生成AI駆動型開発の「Open-GIS論争」？ Missing Middle: GIS開発に存在する空白 https://github.com/opengeos https://projectgeospatial.org/geospatial-frontiers/the-battle-for-the-missingmiddle-ai-webassembly-and-the-next-generation-of-open-source-gis 6
7. 2026/11/01 地理情報システム学会 FOSS4G分科会 7 OSGeoにおける開発支援の背景 • OSGeo Projects（26）とCommunity Projects(30)の2種類の枠組み • 前者は開発の歴史が長く汎用性の高いツール 後者は比較的新しくテーマ特化型が多い – QGIS（2007年〜2008年3月） – ZOO-Project（2011年〜2023年6月） • OSGeo Projectとなるには、一定のインキュ ベーション支援（技術＋開発資金支援）を受 けた上で、自律性の高いOSGeoのコアプロ ジェクトになったものを指す – インキュベーション委員会による合議が必要 2006年3月より不定期開催 – インキュベーションを「卒業」するチェックリ ストが存在し、ライセンスや開発プロセス・環 境などの項目に合致する必要 https://www.osgeo.org/about/committees/incubation/
8. 2026/11/01 地理情報システム学会 FOSS4G分科会 8 OSGeo Community Projectsへの加入ガイドライン • 地理空間情報のプロジェクトであること – READMEやプロジェクトページに明記されていること – ユーザー向けのドキュメントが用意されていること – （地理空間情報の信頼性：座標や距離、面積計算などが正しく行える機能か） • ライセンスがフリーまたはオープンであること – ライセンスがOSI（Open-Source Initiative）によって承認されたものを、 適切に使用していること • 参加や新しい貢献者を歓迎すること – 明確な貢献ポリシーが示されていること – バグ報告やプルリクエストの履歴を通じて協力体制が築かれていること – Code of Conduct（行動規範）が定められていること • OSGeoのCoC： https://www.osgeo.org/code_of_conduct/ • QGISのCoC: https://www.osgeo.org/code_of_conduct/ https://wiki.osgeo.org/wiki/Incubation_Committee
9. 2026/11/01 地理情報システム学会 FOSS4G分科会 9 [OSGeo discuss] メーリングリスト上での主な議論経過 • 第1期：2026年6月25日–27日 「AI/LLM discussion thread」（7通） – 結論を出す場というよりもAI開発にまつわる経験や懸念の棚卸しが目的 – 反AI論者の言い分もわかるが抽象的では？…ただし「maintainer」には拒否権がある – Linuxなどは全面禁止よりも「開示」(disclosure）方式があることを提案 – 生成AIによる負荷の拡大（DDoS被害級）、品質・レビューの質的変化 • 第2期：2026年7月2日–25日 「AI/LLM discussion thread」（20通） – FOSS4G Europe 2026 Timisoara(Romania)における集中的な議論 – 次スライドで解説 • 第3期：2026年10月8日〜「Request for a moratorium on AI/LLM use within OSGeo」(7通） – 現在までの経過（議論は進行中だが、残念ながら不活発）について、 後ほど解説
10. 2026/11/01 地理情報システム学会 FOSS4G分科会 10 第2期：FOSS4G Europe 2026 Timisoara(Romania): OSGeo ProjectsにおけるAI/LLM利用に関する意見交換＋議論 • Jeroen Ticheler (OSGeo代表）からMLへの報告内容 • 「Birds of a Feather (BoF)」を開催し、25〜30名が参加 – 業務としてAIを活用している人だけでなく、AIへの懸念や過去に不快な経験を し「AIによる貢献を全面的にやめるべき」と考える人々の意見も聞きたい • 問題の所在 – 生成AIによって大量のプルリクエスト（PR）が寄せられ、少数のコアレビュー 担当者が疲弊。ソースコードの変更に対する妥当な理由が示されていない点 – 議論のプロセス自体も単調で「非人間的な」会話になっていることも – 若い開発者や学生は、プログラミングを学ぶ当初からAIを活用しているが、ソ フトウェア開発において貢献するための基礎技術・前提知識を正しく身ににつ けているのか？という問題提起（どうやって学んでいるのか？） https://lists.osgeo.org/pipermail/discuss/2026-July/040374.html
11. 2026/11/01 地理情報システム学会 FOSS4G分科会 11 BoFでの討議を踏まえたアウトプット • A call on tone and community（対話のあり方やコミュニティ） – 開発者・貢献者に対する表現に十分注意を払い敬意を持つべき – 「私たちは共に取り組む仲間」であることを再認識 – 一定のル−ルによりこれまでコードを書いたことはないけど貢献したい人を迎え入れ る重要性は高い • A call to build shared AI practices（AI活用に関する共通の実践） – OSGeoとして新たな取組を開始することへの提案 – 開発者同士がスキルやエージェント，貢献の実践方法を共有すること – OSGeo全体で進めるべきか・各プロジェクト内かは要検討 – 引き続きメーリングリストやDiscordで議論を継続したい ＜その後の議論概要＞ → 各プロジェクトがCoCのようなAI方針を明示すべきでは？ → OSGeoは議論の場・助言・インキュベーションに対する審査という実務的な落とし どころを模索すべきでは？ → とはいえ「here to stay」（AIの定着）は単純な形では成立せず、経済的な持続性や ライセンス問題など、AI企業の言い分を無批判に取り入れるべきではないと強く反論 https://lists.osgeo.org/pipermail/discuss/2026-July/040374.html
12. 2026/11/01 地理情報システム学会 FOSS4G分科会 12 第3期: Request for a moratorium on AI/LLM use within OSGeo • 「各グループに任せる」というのは法務的な側面も含めてもはや妥当 ではないのでは？という強い意見 – QGIS（QEP 428）・TorchGeo（PR #4116）が、コーディング・コ ミュニケーション双方で「全面禁止」に踏み切った背景 – インキュベーション委員会に提案されるコミュニティプロジェクトの大部分 が「vibe-coded」であるが委員会に指針がないため対応しようがない • LLMによる生成コードは知的財産法の保護を受けない？したがってラ イセンスの適用が難しい可能性 – パブリックドメインとみなされる可能性もあるが、米国・英国とヨーロッパ で法的なリスクも違うため注意 – 人間による創作があれば著作権・ライセンスは成立しうるが「十分さ」をど う担保するのか？ • 財団全体として一旦「モラトリアム」（一時停止・猶予）の期間を設 けて、プロジェクト単位ではLLMの活用を阻害しないという方法は？
13. 2026/11/01 地理情報システム学会 FOSS4G分科会 13 QGIS開発でのAIツール禁止に関する議論の過程（GitHub） ※QEP＝QGIS-Enhancement-Proposals（機能強化提案） • #363: QEP 408: AI tool use policy – 1/31〜2/19: コメント数61（同意を意味する「+1」含む) – 人間同士の「責任ある協働作業」を設計するための議論（Human in the Loop） – PRの投稿者はAIを利用した場合それを開示し、不要な変更依頼や長文での投稿を 避けるべき，投稿者がGPLライセンスで許諾できるのか？といった議論 • #387: QEP428: No ai contributions permitted – 9/24〜10/7：コメント数27（上に同じ) • #388: QEP 429: Add exception to the AI policy for trusted contributors – 10/9〜：コメント数28 • #389: QEP 430: Extend AI Policy to all texts in all the QGIS organization repositories – 10/11〜：コメント数13 →QEP428を受けて、「誰に対して／何に対して」AI利用を許可すべきか 「例外」規定に関する議論へ https://github.com/qgis /QGIS-Enhancement-Proposals/pull/387
14. 2026/11/01 地理情報システム学会 FOSS4G分科会 14 QEP428: No ai contributions permitted • • Human in the Loopの限界 →「Not Allowed」へ コード変更の生成速度の速さとレ ビュー速度の非対称性 – メンテナーへの負担の集中 – PR投稿者とレビュアーの「信頼性」が 成り立たない • AIに依存することによって、投稿者自 身のコードに対する理解や技術が、果 たして蓄積するのか？ • 禁止の範囲に対する議論（反論） – コード生成だけでなく、IDEによる コードの一部補完、翻訳、アーキテク チャ検討、コードレビュー、セキュリ ティ監査まで禁止はどうなのか？ – 暫定的な予防措置としてはどうか？ https://github.com/qgis /QGIS-Enhancement-Proposals/pull/387
15. 2026/11/01 地理情報システム学会 FOSS4G分科会 15 TorchGeo（PR #4116） (2026年6月より) PyTorchを使った地理空間情報の深層学習ツール:OSGeoプロジェクトの一つ • LLMを利用したPR（プルリクエスト）は、 全面的に禁止 – イシューや、ソースコード、コメントなど、 あらゆるものが含まれる – AIポリシーを策定・運用 • コントリビューターが「AI利用に関する開 示テンプレート」に虚偽なく記入すること を基本 • AIを利用して作成された（あるいはAIが生 成した）と明記されているPR、または開示 テンプレートが欠落している新規PRは、す べてクローズ • ポリシー違反を繰り返すコントリビュー ターは、一時的にブロック • ポリシーを無視するボットは、恒久的にブ ロック • この方針に代わる案を議論する準備がある ことを付言 https://github.com/torchgeo/governance/blob/main/AI-POLICY.md
16. 2026/11/01 地理情報システム学会 FOSS4G分科会 16 GDALの「LLM tool policy」(2026年2月より） • LLMによってコードを書く能力そのものは豊富になったと 認めた上で、重要な点はコードを長期的に維持する能力 （ソフトウェアの保守）であると指摘 • 8つの条件に従う場合に限ってLLM利用を許容 – 「主要なコード貢献者は、人間であること」を最も強調 – vibe-codeing、自律エージェント（自動化）は認めないなど – 責任の所在が人間側にある点を明示（透明性を確保すること。ま た、レビュー担当者が保守コストを増やさないようにすること） • 違反行為があった場合は、リクエストに対してLLM利用の 確認に関するメッセージを送り、即座に承認しない方針 https://gdal.org/en/latest/community/ai_tool_policy.html
17. 2026/11/01 地理情報システム学会 FOSS4G分科会 17 GeoServerの「GSIP-242」(2026年7月より） • GDALとスタンスは近く最も穏健な対応 – AIツールによるコード作成やプロジェクト活動の支援は、原則として認める が、条件を設けた上で貢献者（投稿者）がコードなどを理解・検証・保守で きるかに重きを置く • 5つの条件 – Responsibility：最終責任 – Understanding：完全な理解 – Correctness：正確性の検証 – Feasibility：本人の能力を超えないこと – Maintainability：長期的な保守可能性 • 人間同士のコミュニケーション（Community & Human Communication） – 「AI slop」(AIのみによる低品質な投稿）を防ぐため、非英語母語者向けに も伝わる簡潔で1トピックスの内容になるようにまとめる https://github.com/geoserver/geoserver/wiki/GSIP-242
18. 2026/11/01 地理情報システム学会 FOSS4G分科会 18 本発表を踏まえたまとめ • 生成AI利用に対する運用方針は、暫定的でプロジェクトごとに異なる – QGIS・TorchGeo：メンテナーとコミュニティを保護するため、AIによる貢献を原則禁止 – GDAL・GeoServer：人間による理解・検証・説明・保守を条件としてAI利用を許容 • 共通課題「OSS開発における人間の責任とコミュニティの持続可能性」 – AIによるコードの生成速度の速さと人間によるレビュー速度の非対称性問題 – 著作権・ライセンス・コードの出自に関する不確実性 – 投稿者の理解不足、メンテナーへの負担集中、開発者・レビュアー育成への影響 • 共通原則やステイクホルダー間の対話の必要性 – プロジェクトの自律性を維持しながら、AI利用に関する最低限の共通原則を整理すべき段階？ – OSGeoでもライセンス、コードの出自、保守可能性の確認方法を更新する動きの可能性？ 生成AI駆動型開発による開発コストの低下や「Missing Middle」の解決 vs. 地理空間情報を扱う機能の信頼性担保、開発コミュニティ自体の育成
19. 2026/11/01 地理情報システム学会 FOSS4G分科会 19 Thank you! tosseto@komazawa-u.ac.jp https://tossetolab.github.io/ https://speakerdeck.com/tosseto