洪 民憙 (Hong Minhee) :nonbinary:'s avatar

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

1,107 following1,897 followers

An intersectionalist, feminist, and socialist living in Seoul (UTC+09:00). @tokolovesme's spouse. Who's behind @fedify, @hollo, and @botkit. Write some free software in , , , & . They/them.

서울에 사는 交叉女性主義者이자 社會主義者. 金剛兔(@tokolovesme)의 配偶者. @fedify, @hollo, @botkit 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

Pinned

@hongminhee@hollo.social

Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.

I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.

I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!

en.wikipedia.org

Korean mixed script - Wikipedia

Pinned

はじめまして!ソウル在住の30代後半のオープンソースソフトウェアエンジニア、洪 民憙ホン・ミンヒと申します。バイセクシュアル(bisexual)・ノンバイナリー(non-binary)で、自由・オープンソースソフトウェア(F/OSS)とフェディバース(fediverse)の熱烈な支持者です。

STF(@sovtechfund)の支援を受け、TypeScript用ActivityPubサーバーフレームワーク「@fedify」の開発に専念しています。他にも、おひとり様向けのActivityPubマイクロブログ「@hollo」、ActivityPubボットフレームワーク「@botkit」、ソフトウェア開発者向けフェディバースプラットフォームHackers' Pub、JavaScript・TypeScript用ロギングライブラリLogTapeなどの制作者でもあります。

東アジア言語(いわゆるCJK)とUnicodeにも興味があります。このアカウントでは主に英語で投稿していますが、時々日本語や国漢文混用体(漢字ハングル混じり文)の韓国語でも書いています。実はこの文体で書きたくてフェディバースを始めた、という経緯もあります。日本語、英語、韓国語、漢文でも気軽に話しかけてください!

speakerdeck.com

国漢文混用体からHolloまで

本発表では、韓国語の「国漢文混用体」(漢字ハングル混じり文)を自分のフェディバース投稿に実装したいという小さな目標から始まった旅路を共有します。 この目標を達成するために、ActivityPubのJSON-LDの複雑さやHTTP Signatures、WebFingerなどの仕様を理解する必要性に…

Pinned

安寧(안녕)하세요! 저는 서울에 살고 있는 30() 後半(후반)의 오픈 소스 소프트웨어 엔지니어 洪民憙(홍민희)입니다. 兩性愛者(양성애자)(bisexual)이자 논바이너리(non-binary)이며, 自由(자유)·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)支持者(지지자)이기도 합니다.

STF(@sovtechfund)의 支援(지원)을 받아 TypeScript() ActivityPub 서버 프레임워크 @fedify 開發(개발)專業(전업)으로 ()하고 있습니다. 그 ()에도 싱글 유저() ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者(개발자)를 위한 聯合宇宙(연합우주) 플랫폼 Hackers' Pub, JavaScript·TypeScript() 로깅 라이브러리 LogTape ()製作者(제작자)이기도 합니다.

()아시아 言語(언어)(이른바 CJK)와 Unicode에도 關心(관심)이 많습니다. 이 計定(계정)에서는 ()英語(영어)로 포스팅하지만, 때때로 日本語(일본어)國漢文混用體(국한문 혼용체) 韓國語(한국어)로도 씁니다. 聯合宇宙(연합우주)에 오게 된 動機(동기) () 하나가 바로 國漢文混用體(국한문 혼용체)로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語(한국어), 英語(영어), 日本語(일본어), 아니면 漢文(한문)으로도 말을 걸어주세요!

logtape.org

LogTape

Unobtrusive logging library with zero dependencies—library-first design for Deno, Node.js, Bun, browsers, and edge functions

@noellabo@fedibird.com · Reply to のえる

どんな内容のレポートがほしいって具体的に指示していて、内容も予測したものを出力させてはいるんですが、

このぐらい周辺情報を集めて綺麗にまとめてくれると便利ですね。

AI生成とはいえ、内容は重要なものなので、記事の類と思って読んでいただければ。

あと、Hackers' Pubという、ActivityPub対応のQiita、Zennを目指したプラットフォームのテストでもあります。

ブログどこに書こうかな……って考えている方は、検討してみるといいですよ。私も少し招待コード出せます。開発者の洪民憙さんにお願いすれば確実です。
hollo.social/@hongminhee/01973 [参照]

fedibird.com

投稿の参照(2件) by のえる (@noellabo@fedibird.com)

他1件 / AI生成プルリクエストが引き起こす開発コミュニティの課題と対応策 https://hackers.pub/@noellabo/2025/ai生成フルリクエストか引き起こす開発コミュニティの課題と対応策

@hongminhee@hollo.social
@bgl@hackers.pub

대학생때 친구(컴알못)가 노트북 견적 짜달라고 한적이 있는데, 성능 상관없고 최대한 싸게만 해달라고 했다. 그래서 운영체제 미포함 기기에 우분투 깔아서 30만원으로 맞춰줬다. 우분투를 영업하려는 의도는 전혀 없었고 싸게 해달라는 요구를 최대한 맞춘 결과였다. 걔가 그때 형편이 안 좋아서 한푼이라도 아끼는게 중요했고, 나는 나름 목적을 달성했다는 것에 뿌듯해했다. 리브레 오피스 깔아주면서 한글, 엑셀 대신에 이거 쓰면 된다고 설명했던 기억이 난다.

그리고 이 일을 까맣게 잊고 살다가 1년후 쯤에 그 친구를 다시 만났는데, 보자마자 반응이

나 너무 많은 일이 있었어
ALT text

나 너무 많은 일이 있었어

@nozomi_uetsuki_0410@songbird.cloud
@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@noellabo@fedibird.com · Reply to のえる

そしてそこに、AIがプログラムコードの追加・修正を提案できる時代がやってきました。

これまでも、いろんな補助ツールを使って、自動でテストし、記述のバラツキやミスを修正するツールを使ってはきたのですが、それはそれぞれの開発者が、自分の責任のもとで、内容を理解し、それが与える影響・コミュニティへの負担をわかった上でプロジェクトに提案してきたわけですが、

AIを使った追加・修正の提案が可能になったことをきっかけに、上記の人間が引き受けていた判断やリスペクトを飛び越え、そうした判断力や力量、責任を持たない人が、安易に大量にリクエストするようになってしまっています。

AIによる開発が有用であることは重々承知しているので、多くのプロジェクトで、上手に利用していきたいとは考えているのですが、

この安易な参加者によって、コミュニティ開発を維持していくのが難しい状況が発生しているのです。

そのあたりのことを(あえてAIに)まとめてもらったのが、先の記事です。
hackers.pub/@noellabo/2025/ai生 [参照]

fedibird.com

投稿の参照(1件) by のえる (@noellabo@fedibird.com)

AI生成プルリクエストが引き起こす開発コミュニティの課題と対応策 https://hackers.pub/@noellabo/2025/ai生成フルリクエストか引き起こす開発コミュニティの課題と対応策

@noellabo@fedibird.com

さて、自分の言葉で書き直すか。

MastodonやMisskeyは、Githubなどのオンライン上の開発支援システム上にプログラムのソースコードを置いて、

最初に作った開発者や、プロジェクトの権限を与えられたコア開発者を中心に、

みんなで問題点を洗い出して議論し(issue)、プログラムの追加や変更を提案して皆で検証・検討し(pull request)、問題が無くなったら承認を得てプログラムに反映(merge)し、一定の基準を満たしたら、みんなに使って貰うものにタグ付けしてリリースします。

集団での開発は、提起された課題や追加・変更の提案を何でも取り込めばよいというものではなく、

プロジェクトの目指しているものに合致していて必要なものであるかを判断し、それが与える影響を理解し、その追加・変更を引き受けたら継続的にメンテナンスが必要となるため慎重に検討・吟味し、

でもそれってすごく大変なので、コミュニティに参加するみんなが負担できる範囲で受け入れています。

たとえば、ソースコード全体にわたって内容を書き換えるような変更は、よほど有意義なものでなければテストや検証が難しく受け入れるのは困難です。

せっかく体制はオープンでも、みんなの要望に対応しきれなくて閉じてしまうプロジェクトもあります。

@hongminhee@hollo.social

저는 돌아가신 父母(부모)님 모두 進步(진보) 性向(성향)이셨고, 동생도 퀴어라서 當然(당연)히(?) 進步(진보) 性向(성향)이라 온 家族(가족)進步(진보) 性向(성향)이네요. 다만 父母(부모)님은 民主黨(민주당) 支持(지지)하셨고, 저와 동생은 더 왼쪽… 아무튼 그래서 家族(가족) 사이에서 政治觀(정치관) 差異(차이)葛藤(갈등)을 겪을 일이 크게 없었습니다. 그런데 이런 境遇(경우)가 흔치는 않은 것 같더라고요.

@hongminhee@hollo.social
@noellabo@fedibird.com

Hackers' Pubに、perplexity(AI)に社会問題(開発コミュニティの課題)について詳しく調査するよう指示した結果の出力を載せておいたので、AI利用事例のサンプルとしてご覧下さい。

私がperplexityに指示した問いかけは以下の内容です。
--

GithubにAIが生成したプルリクエストを送る事例が増えていて、開発コミュニティの負担が増大する事例が増えています。AIは独立した人格と責任を持つ自然人ではないため、そのリクエストを行った主体が、リクエストを行う意義と責任を担保し、開発コミュニティの負担(対応に要するコストや変更点に対して持続的にサポートすること)に対する理解を持ち、協力して開発するというモデルが成立しなくなってしまう問題に直面しています。これについて、これまで行われた有意義な議論と、提示されている解決策、あるいは実際に行っている対応について調べてください。
QT: hackers.pub/@noellabo/2025/ai生
[参照]

fedibird.com

投稿の参照(1件) by のえる (@noellabo@fedibird.com)

AI生成プルリクエストが引き起こす開発コミュニティの課題と対応策 https://hackers.pub/@noellabo/2025/ai生成フルリクエストか引き起こす開発コミュニティの課題と対応策

@noellabo@hackers.pub

※ 本記事は、noellaboが課題を提示した上で作成を指示し、perplexityによって生成されたリサーチのレポートです。

AI生成プルリクエストが引き起こす開発コミュニティの課題と対応策

要約

AI技術の発展に伴い、GitHub上でAIが生成したプルリクエスト(PR)が急増し、開発コミュニティに新たな課題が生じています。2023年以降、特に大規模オープンソースプロジェクトを中心に、AIが自動生成した低品質なPRがスパムのように送信される事例が報告されています[1][2][3][4]。これらのPRはコードの実用性に欠け、説明文もAI特有のパターンを示すため、メンテナンスコストの増大とコミュニティリソースの浪費を招いています[3:1][4:1]。本報告では、この現象の背景、影響範囲、および現在進行中の解決策を体系的に分析します。

AI生成PRが開発プロセスに及ぼす影響

従来のコラボレーションモデルの崩壊

従来のオープンソース開発では、PR提出者が「責任ある貢献者」として機能し、コードの説明・保守・修正に対するコミットメントが暗黙的に期待されていました[5]。しかしAI生成PRの場合、以下の根本的な問題が発生します:

  1. 責任主体の不在:AIは法人格を持たず、生成コードの品質保証や継続的なメンテナンスが不可能[6][4:2]
  2. 意図の不透明性:PR作成者の動機がTシャツ獲得(Hacktoberfest事例)やアカウント作成数稼ぎなど、プロジェクト改善と無関係なケースが多数[7][8]
  3. 技術的負債の蓄積:機械学習モデルが生成したコードが既存システムに組み込まれると、後続のデバッグが極めて困難[9][10]

2024年の調査では、主要OSSプロジェクトの平均38%がAI生成PRの処理に週5時間以上を費やしていることが明らかになりました[2:1][3:2]

コミュニティ主導の解決アプローチ

技術的対策の進化

  1. AI駆動のフィルタリングシステム GitHubは2024年、Copilotの技術を転用した「PR Integrity Filter」を試験導入しました。このシステムは以下を自動検出します:
    • 訓練データとの類似度が97%を超えるコードスニペット[6:1]
    • 自然言語処理による説明文のパターン分析(AI生成特有の定型表現の検出)[4:3]
    • テストケースの不在や依存関係の不整合[9:1]
  2. プロジェクト側の防御策
    • PR-Agent:CodiumAIが開発するオープンソースツールで、PRの自動トリアージ機能を提供。コード変更の影響範囲分析とリスク評価を自動化[9:2][10:1]
    • Bors-ng:マージ前の自動テストを強化し、AI生成コードの統合を阻止するCI/CDパイプライン[5:1]
# .github/workflows/pr-validation.ymlの設定例
name: AI PR Validation
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Detect AI-generated code
      uses: copilot/pr-detector@v2
      with:
        threshold: 0.85
    - name: Run test suite
      run: |
        npm install
        npm test

コミュニティガイドラインの進化

主要プロジェクトが採用する新しい行動規範の例:

  • AI Contribution Policyの明文化(Linux Foundation提案例)

AI-generated contributions must be accompanied by human-curated impact analysis and long-term maintenance commitment[5:2]

  • DigitalOceanのHacktoberfestルール改定:
    • プロジェクトオプトイン制の導入(2023年)
    • 有効PRの認定にメンテナー承認を必須化[7:1][8:1]

企業・プラットフォームの対応戦略

GitHubの政策変更

  1. 2024年セーフガードポリシー
    • 新規アカウントのPR作成制限(最初の5PRはメンテナー確認必須)[11]
    • レポジトリごとのAI-PRクォータ設定機能の提供[12]
# GitHub CLIでのAI-PR制限設定例
gh api repos/{owner}/{repo}/branches/main/protection \
  -X PUT \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  -d '{
    "required_pull_request_reviews": {
      "dismiss_stale_reviews": true,
      "require_code_owner_reviews": true,
      "ai_pr_quota": 10
    },
    "enforce_admins": false,
    "required_linear_history": false
  }'
  1. Copilotの倫理基準強化
    • 訓練データの出典追跡機能(Apache 2.0ライセンスコードの使用監査)[6:2]
    • 類似度検出アルゴリズムの精度向上(150文字→50文字のマッチング可能に)[12:1]

企業のAI開発ガバナンス事例

  • MicrosoftのResponsible AI Framework適用: AI生成PRに関連するリスクを「技術的」「法的」「倫理的」の3軸で評価[12:2]
  • Red Hatのオープンソースポリシー: AI生成コードの採用時に必要なドキュメント(モデル情報、訓練データ出典等)を規定[5:3]

倫理・法制度面での議論

著作権問題の新展開

2025年、テキサスA&M大学のTim Davis教授がGitHub Copilotを提訴した事例では、LGPLライセンスコードの無断流用が争点となりました[6:3]。裁判所は「AI生成コードのライセンス継承要件」について以下の判断を示しました:

AIが生成したコード片が訓練データの著作物と実質的に同一の場合、元のライセンス条件が適用される[6:4]

この判決を受け、OSSコミュニティでは「AI-generated code license inheritance」に関する新たな議論が活発化しています[6:5][4:4]

倫理ガイドラインの策定動向

  • IEEEの「AI協働開発ガイドライン」草案:
    • 人間の監視責任(Human-in-the-loop)の明記
    • 技術的負債の可視化基準
    • モデルバイアスの監査方法[2:2]
  • FSFのAI生成コードに関する見解:

AIツールチェーン全体の自由ソフトウェア化が不可欠[6:6]

今後の課題と展望

未解決の技術的課題

  1. 文脈理解の限界:現在のAIはプロジェクトの歴史的経緯や技術的負債を十分に考慮できない[9:3][10:2]
  2. 継続的メンテナンス:生成コードの長期サポートを保証するメカニズムの不在[3:3][4:5]
  3. セキュリティリスク:AIが生成した脆弱性コードの検出難易度の高さ[13][6:7]

提言される次世代ソリューション

  1. ブロックチェーン型貢献トラッキング:コード片の生成経路を分散台帳で管理し、責任追跡を可能にする構想[2:3]
  2. AIメンテナーシップボンド: PR提出者が担保金を預託し、問題発生時に補填する仕組み[4:6]
  3. 動的スコアリングシステム:開発者の信頼度をPR品質に応じて計算し、AI生成PRの影響力を制限[11:1]

結論

AI生成PRの急増は、オープンソース開発の根本原理である「共同責任モデル」に根本的な問いを投げかけています。現時点では、技術的フィルタリングとコミュニティガバナンスの組み合わせが最も効果的な対策として機能していますが[5:4][9:4][10:3]、長期的にはAIシステム自体の責任構造を再定義する法的・倫理的枠組みの構築が不可欠です[6:8][4:7]。今後の発展方向として、AIの創造性を活用しつつ持続可能な協働エコシステムを維持するためには、以下の要素が重要となります:

  • 透明性:AI生成コードのプロベナンス追跡
  • 説明責任:人間開発者とAIシステムの役割分担の明確化
  • 相互利益:AI活用による生産性向上とコミュニティ負荷軽減のバランス

これらを実現するため、技術者コミュニティ・企業・法制度制定者の三者連携による継続的な対話が求められています。


  1. https://github.com/orgs/community/discussions/22804 ↩︎

  2. https://mansoorbarri.com/github-spam-fix/ ↩︎ ↩︎ ↩︎ ↩︎

  3. https://navendu.me/posts/ai-generated-spam-prs/ ↩︎ ↩︎ ↩︎ ↩︎

  4. https://www.reddit.com/r/opensource/comments/125q3zs/aigenerated_spam_pull_requests/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. https://contributor-experience.org/docs/guide/tools/bots.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. https://devclass.com/2022/10/17/github-copilot-under-fire-as-dev-claims-it-emits-large-chunks-of-my-copyrighted-code/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. https://www.infoq.com/jp/news/2020/12/hacked-off-hacktoberfest/ ↩︎ ↩︎

  8. https://www.clear-code.com/blog/2020/10/23.html ↩︎ ↩︎

  9. https://inside.dmm.com/articles/introduce-pr-agent-to-monorepo/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  10. https://qiita.com/ssc-yshikeda/items/5611780d1c46886a6526 ↩︎ ↩︎ ↩︎ ↩︎

  11. https://github.com/orgs/community/discussions/53233 ↩︎ ↩︎

  12. https://docs.github.com/ja/enterprise-cloud@latest/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-pull-request-summaries ↩︎ ↩︎ ↩︎

  13. https://everything-pr.com/the-perils-of-over-reliance-on-ai-in-pr/ ↩︎

@noellabo@hackers.pub

※ 本記事は、noellaboが課題を提示した上で作成を指示し、perplexityによって生成されたリサーチのレポートです。

AI生成プルリクエストが引き起こす開発コミュニティの課題と対応策

要約

AI技術の発展に伴い、GitHub上でAIが生成したプルリクエスト(PR)が急増し、開発コミュニティに新たな課題が生じています。2023年以降、特に大規模オープンソースプロジェクトを中心に、AIが自動生成した低品質なPRがスパムのように送信される事例が報告されています[1][2][3][4]。これらのPRはコードの実用性に欠け、説明文もAI特有のパターンを示すため、メンテナンスコストの増大とコミュニティリソースの浪費を招いています[3:1][4:1]。本報告では、この現象の背景、影響範囲、および現在進行中の解決策を体系的に分析します。

AI生成PRが開発プロセスに及ぼす影響

従来のコラボレーションモデルの崩壊

従来のオープンソース開発では、PR提出者が「責任ある貢献者」として機能し、コードの説明・保守・修正に対するコミットメントが暗黙的に期待されていました[5]。しかしAI生成PRの場合、以下の根本的な問題が発生します:

  1. 責任主体の不在:AIは法人格を持たず、生成コードの品質保証や継続的なメンテナンスが不可能[6][4:2]
  2. 意図の不透明性:PR作成者の動機がTシャツ獲得(Hacktoberfest事例)やアカウント作成数稼ぎなど、プロジェクト改善と無関係なケースが多数[7][8]
  3. 技術的負債の蓄積:機械学習モデルが生成したコードが既存システムに組み込まれると、後続のデバッグが極めて困難[9][10]

2024年の調査では、主要OSSプロジェクトの平均38%がAI生成PRの処理に週5時間以上を費やしていることが明らかになりました[2:1][3:2]

コミュニティ主導の解決アプローチ

技術的対策の進化

  1. AI駆動のフィルタリングシステム GitHubは2024年、Copilotの技術を転用した「PR Integrity Filter」を試験導入しました。このシステムは以下を自動検出します:
    • 訓練データとの類似度が97%を超えるコードスニペット[6:1]
    • 自然言語処理による説明文のパターン分析(AI生成特有の定型表現の検出)[4:3]
    • テストケースの不在や依存関係の不整合[9:1]
  2. プロジェクト側の防御策
    • PR-Agent:CodiumAIが開発するオープンソースツールで、PRの自動トリアージ機能を提供。コード変更の影響範囲分析とリスク評価を自動化[9:2][10:1]
    • Bors-ng:マージ前の自動テストを強化し、AI生成コードの統合を阻止するCI/CDパイプライン[5:1]
# .github/workflows/pr-validation.ymlの設定例
name: AI PR Validation
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Detect AI-generated code
      uses: copilot/pr-detector@v2
      with:
        threshold: 0.85
    - name: Run test suite
      run: |
        npm install
        npm test

コミュニティガイドラインの進化

主要プロジェクトが採用する新しい行動規範の例:

  • AI Contribution Policyの明文化(Linux Foundation提案例)

AI-generated contributions must be accompanied by human-curated impact analysis and long-term maintenance commitment[5:2]

  • DigitalOceanのHacktoberfestルール改定:
    • プロジェクトオプトイン制の導入(2023年)
    • 有効PRの認定にメンテナー承認を必須化[7:1][8:1]

企業・プラットフォームの対応戦略

GitHubの政策変更

  1. 2024年セーフガードポリシー
    • 新規アカウントのPR作成制限(最初の5PRはメンテナー確認必須)[11]
    • レポジトリごとのAI-PRクォータ設定機能の提供[12]
# GitHub CLIでのAI-PR制限設定例
gh api repos/{owner}/{repo}/branches/main/protection \
  -X PUT \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  -d '{
    "required_pull_request_reviews": {
      "dismiss_stale_reviews": true,
      "require_code_owner_reviews": true,
      "ai_pr_quota": 10
    },
    "enforce_admins": false,
    "required_linear_history": false
  }'
  1. Copilotの倫理基準強化
    • 訓練データの出典追跡機能(Apache 2.0ライセンスコードの使用監査)[6:2]
    • 類似度検出アルゴリズムの精度向上(150文字→50文字のマッチング可能に)[12:1]

企業のAI開発ガバナンス事例

  • MicrosoftのResponsible AI Framework適用: AI生成PRに関連するリスクを「技術的」「法的」「倫理的」の3軸で評価[12:2]
  • Red Hatのオープンソースポリシー: AI生成コードの採用時に必要なドキュメント(モデル情報、訓練データ出典等)を規定[5:3]

倫理・法制度面での議論

著作権問題の新展開

2025年、テキサスA&M大学のTim Davis教授がGitHub Copilotを提訴した事例では、LGPLライセンスコードの無断流用が争点となりました[6:3]。裁判所は「AI生成コードのライセンス継承要件」について以下の判断を示しました:

AIが生成したコード片が訓練データの著作物と実質的に同一の場合、元のライセンス条件が適用される[6:4]

この判決を受け、OSSコミュニティでは「AI-generated code license inheritance」に関する新たな議論が活発化しています[6:5][4:4]

倫理ガイドラインの策定動向

  • IEEEの「AI協働開発ガイドライン」草案:
    • 人間の監視責任(Human-in-the-loop)の明記
    • 技術的負債の可視化基準
    • モデルバイアスの監査方法[2:2]
  • FSFのAI生成コードに関する見解:

AIツールチェーン全体の自由ソフトウェア化が不可欠[6:6]

今後の課題と展望

未解決の技術的課題

  1. 文脈理解の限界:現在のAIはプロジェクトの歴史的経緯や技術的負債を十分に考慮できない[9:3][10:2]
  2. 継続的メンテナンス:生成コードの長期サポートを保証するメカニズムの不在[3:3][4:5]
  3. セキュリティリスク:AIが生成した脆弱性コードの検出難易度の高さ[13][6:7]

提言される次世代ソリューション

  1. ブロックチェーン型貢献トラッキング:コード片の生成経路を分散台帳で管理し、責任追跡を可能にする構想[2:3]
  2. AIメンテナーシップボンド: PR提出者が担保金を預託し、問題発生時に補填する仕組み[4:6]
  3. 動的スコアリングシステム:開発者の信頼度をPR品質に応じて計算し、AI生成PRの影響力を制限[11:1]

結論

AI生成PRの急増は、オープンソース開発の根本原理である「共同責任モデル」に根本的な問いを投げかけています。現時点では、技術的フィルタリングとコミュニティガバナンスの組み合わせが最も効果的な対策として機能していますが[5:4][9:4][10:3]、長期的にはAIシステム自体の責任構造を再定義する法的・倫理的枠組みの構築が不可欠です[6:8][4:7]。今後の発展方向として、AIの創造性を活用しつつ持続可能な協働エコシステムを維持するためには、以下の要素が重要となります:

  • 透明性:AI生成コードのプロベナンス追跡
  • 説明責任:人間開発者とAIシステムの役割分担の明確化
  • 相互利益:AI活用による生産性向上とコミュニティ負荷軽減のバランス

これらを実現するため、技術者コミュニティ・企業・法制度制定者の三者連携による継続的な対話が求められています。


  1. https://github.com/orgs/community/discussions/22804 ↩︎

  2. https://mansoorbarri.com/github-spam-fix/ ↩︎ ↩︎ ↩︎ ↩︎

  3. https://navendu.me/posts/ai-generated-spam-prs/ ↩︎ ↩︎ ↩︎ ↩︎

  4. https://www.reddit.com/r/opensource/comments/125q3zs/aigenerated_spam_pull_requests/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. https://contributor-experience.org/docs/guide/tools/bots.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. https://devclass.com/2022/10/17/github-copilot-under-fire-as-dev-claims-it-emits-large-chunks-of-my-copyrighted-code/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. https://www.infoq.com/jp/news/2020/12/hacked-off-hacktoberfest/ ↩︎ ↩︎

  8. https://www.clear-code.com/blog/2020/10/23.html ↩︎ ↩︎

  9. https://inside.dmm.com/articles/introduce-pr-agent-to-monorepo/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  10. https://qiita.com/ssc-yshikeda/items/5611780d1c46886a6526 ↩︎ ↩︎ ↩︎ ↩︎

  11. https://github.com/orgs/community/discussions/53233 ↩︎ ↩︎

  12. https://docs.github.com/ja/enterprise-cloud@latest/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-pull-request-summaries ↩︎ ↩︎ ↩︎

  13. https://everything-pr.com/the-perils-of-over-reliance-on-ai-in-pr/ ↩︎

1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀

@hongminhee@hollo.social
@thx@mustard.blog
@hongminhee@hollo.social
@Yohei_Zuho@mstdn.y-zu.org

OSCなどのイベントでFediverseを説明するためのフリー小冊子を作っています。まだ書きかけです。
皆さんの意見をIssueやPR、リプライでお待ちしています。
github.com/YoheiZuho/Fediverse

github.com

GitHub - YoheiZuho/FediverseTutorial: Fediverse(特にActivityPub)に入門するための手引き

Fediverse(特にActivityPub)に入門するための手引き. Contribute to YoheiZuho/FediverseTutorial development by creating an account on GitHub.

@hongminhee@hackers.pub

아침에 @devunt 님이 pino에서 LogTape로 옮기려는데 아쉬운 점들이 있다고 해서 해당 부분들을 개선했다.

hackers.pub

LogTape 0.11.0 release notes

LogTape 0.11.0 introduces enhanced structured logging capabilities and a new JSON Lines formatter, improving how developers handle logs across JavaScript runtimes. The update allows direct object logging, where structured data can be logged by passing an object as the first argument to any log method, and introduces a universal property interpolation with `{*}`. This placeholder streamlines the inclusion of all properties from structured data without explicitly naming each one. Additionally, the new JSON Lines formatter outputs each log record as a JSON object on a separate line, ideal for log aggregation systems and analysis tools, with customizable options for category separation, message formatting, and properties handling. These enhancements aim to make logs more searchable and analyzable, reduce boilerplate, and improve integration with log management systems, all while maintaining backward compatibility and LogTape's zero-dependency promise.

@hongminhee@hackers.pub

LogTape is a zero-dependency logging library for JavaScript and TypeScript that works across all runtimes.

We're excited to announce the release of LogTape 0.11.0, which introduces significant enhancements to structured logging capabilities and adds a new JSON Lines formatter for better log processing.

New features and enhancements

Enhanced structured logging

LogTape 0.11.0 brings major improvements to structured logging, making it easier and more flexible to work with structured data in your logs.

Direct object logging

You can now log structured data directly by passing an object as the first argument to any log method:

logger.info({
  userId: 123456,
  username: "johndoe",
  loginTime: new Date(),
});

This creates a log entry with the object properties as structured fields, making your logs more machine-readable and searchable.

Universal property interpolation with {*}

A new special placeholder {*} allows you to interpolate all properties from your structured data at once:

logger.info("User logged in with properties {*}", {
  userId: 123456,
  username: "johndoe",
  loginTime: new Date(),
});

This is particularly useful when you want to include all available context without explicitly naming each property in your message template.

Streamlined logging methods

All logging methods (debug, info, warn, error, fatal) now support the new object-first syntax as a convenient shorthand for structured logging with the {*} placeholder.

JSON Lines formatter

LogTape now includes built-in support for JSON Lines (also known as JSONL or NDJSON) format, a popular choice for structured logging in modern applications:

import { jsonLinesFormatter } from "@logtape/logtape";
import { getFileSink } from "@logtape/file";

await configure({
  sinks: {
    jsonl: getFileSink("app.jsonl", {
      formatter: jsonLinesFormatter
    }),
  },
  // ... rest of configuration
});

The JSON Lines formatter outputs each log record as a JSON object on a separate line, making it ideal for log aggregation systems and analysis tools.

Customizable JSON Lines options

The new getJsonLinesFormatter() function provides several customization options:

  • Category separator: Control how hierarchical categories are joined
  • Message format: Choose between raw templates or rendered messages
  • Properties handling: Flatten properties, nest them, or prepend with custom prefixes

Backward compatibility

All existing logging patterns continue to work exactly as before. The new features are additive and don't break any existing code.

Why this matters

These enhancements make LogTape even more powerful for modern application logging:

  • Better observability: Structured data makes logs more searchable and analyzable
  • Improved developer experience: Less boilerplate when logging complex objects
  • Industry standard formats: JSON Lines support for better integration with log management systems
  • Flexible formatting: Customize output to match your infrastructure needs

Installation

LogTape 0.11.0 is available on both JSR and npm:

deno add jsr:@logtape/logtape@0.11.0
npm  add     @logtape/logtape@0.11.0
pnpm add     @logtape/logtape@0.11.0
yarn add     @logtape/logtape@0.11.0
bun  add     @logtape/logtape@0.11.0

Learn more

We hope these new features enhance your logging experience. As always, LogTape remains zero-dependency and works across all JavaScript runtimes.

Happy logging!

logtape.org

LogTape changelog | LogTape

Simple logging library with zero dependencies for Deno, Node.js, Bun, browsers, and edge functions