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

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · 975 following · 1319 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 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

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

@hongminhee@hollo.social

Hello, I'm an open source software engineer in my late 30s living in , , and an avid advocate of and the .

I'm the creator of @fedify, an server framework in , @hollo, an ActivityPub-enabled microblogging software for single users, and @botkit, a simple ActivityPub bot framework.

I'm also very interested in East Asian languages (so-called ) and . Feel free to talk to me in , (), or (), or even in Literary Chinese (, )!

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

@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

安寧(안녕)하세요, 저는 서울에 살고 있는 30() 後半(후반) 오픈 소스 소프트웨어 엔지니어이며, 自由(자유)·오픈 소스 소프트웨어와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)支持者(지지자)입니다.

저는 TypeScript() ActivityPub 서버 프레임워크인 @fedify 프로젝트와 싱글 유저() ActivityPub 마이크로블로그인 @hollo 프로젝트와 ActivityPub 봇 프레임워크인 @botkit 프로젝트의 製作者(제작자)이기도 합니다.

저는 ()아시아 言語(언어)(이른바 )와 유니코드에도 關心(관심)이 많습니다. 聯合宇宙(연합우주)에서는 國漢文混用體(국한문 혼용체)를 쓰고 있어요! 제게 韓國語(한국어)英語(영어), 日本語(일본어)로 말을 걸어주세요. (아니면, 漢文(한문)으로도!)

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

@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

こんにちは、私はソウルに住んでいる30代後半のオープンソースソフトウェアエンジニアで、自由・オープンソースソフトウェアとフェディバースの熱烈な支持者です。名前は洪 民憙ホン・ミンヒです。

私はTypeScript用のActivityPubサーバーフレームワークである「@fedify」と、ActivityPubをサポートする1人用マイクロブログである 「@hollo」と、ActivityPubのボットを作成する為のシンプルなフレームワークである「@botkit」の作者でもあります。

私は東アジア言語(いわゆるCJK)とUnicodeにも興味が多いです。日本語、英語、韓国語で話しかけてください。(または、漢文でも!)

のえる's avatar
のえる

@noellabo@fedibird.com · Reply to のえる's post

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

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

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

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

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

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

のえる's avatar
のえる

@noellabo@fedibird.com

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

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

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

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

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

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

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

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

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

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

@hongminhee@hollo.social

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

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

@hongminhee@hollo.social

Hackers' Pubのアカウントが必要な方は、私が招待できます。気軽にDMでメールアドレスを教えてください。

のえる's avatar
のえる

@noellabo@fedibird.com

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

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

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

のえる's avatar
のえる

@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/ ↩︎

のえる's avatar
のえる

@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/ ↩︎

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

@hongminhee@hollo.social

오늘은 點心(점심)으로 御任(오마카세) 壽司(스시) 먹는 날! 🍣

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

@hongminhee@hollo.social · Reply to Emelia 👸🏻's post

@thisismissem Haha, that 卜 in the red circle is a voting stamp!

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

@hongminhee@hollo.social

投票(투표) 完了(완료)!

投票所 앞에서 찍은 손
ALT text details投票所 앞에서 찍은 손
Fedify: ActivityPub server framework's avatar
Fedify: ActivityPub server framework

@fedify@hollo.social

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! 🚀

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

@hongminhee@hackers.pub

갑작스럽지만 @jihyeok 님과 저는 오늘 (선거일) 튜링의 사과(@TuringAppleDev)에서 모각코를 할 예정입니다. 심심하신 분들은 함께해요!

Марика Сакураги 桜木茉莉花 in🇯🇵's avatar
Марика Сакураги 桜木茉莉花 in🇯🇵

@morotesovtannu@msk.ilnk.info

これ、中国って書いてあるけど香港ね。
この「離港」っていう香港独特の表現が好き。
香港から離れる

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

@hongminhee@hollo.social

僞善(위선)과 싸우겠다는 사람들의 共通點(공통점)

상어학산타 :spinny_cat_gay:'s avatar
상어학산타 :spinny_cat_gay:

@thx@mustard.blog

고베에 있는 평양냉면집 본점이라는데
1939년부터 운영했다네요...? :blobcat_fu_surprised4b:

아니 한국에 있는 평양냉면집도
그 정도 오래된 집 찾기가 힘든데
되게 역사적으로 뜻깊은 가게인 것 같다.

youtube.com/watch?v=477gtcYz51

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

@hongminhee@hollo.social

聯合宇宙(연합우주) 튜토리얼(日本語(일본어)), 原稿(원고)完了(완료)되면 著者(저자)분께 許可(허가) 받고 韓國語(한국어)로도 翻譯(번역)해보고 싶다.

もちもちずきん 🍆's avatar
もちもちずきん 🍆

@Yohei_Zuho@mstdn.y-zu.org

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

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

@hongminhee@hollo.social · Reply to Emelia 👸🏻's post

@thisismissem Does it mean it will be deployed to mastodon.social soon?

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

@hongminhee@hackers.pub

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



RE: https://hackers.pub/@hongminhee/2025/logtape-0-11-0

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

@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!

Merged to Main's avatar
Merged to Main

@mergebot@vmst.io

Accept HTTP Message Signatures (RFC9421) (#34814) by oneiros has been merged! github.com/mastodon/mastodon/c

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

@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!

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

@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@cheeaun Filed an issue: https://github.com/shikijs/shiki/issues/1027.

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

@hongminhee@hollo.social · Reply to Chee Aun 🤔's post

@cheeaun Oh, I haven't been aware of it! Hmm, it would be worth filing an issue in their issue tracker.

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

@hongminhee@hollo.social

가끔 【此日彼日(차일피일)】을 【치일피일】 ()으로 잘못 쓰는 境遇(경우)가 있습니다만, 【此日彼日(차일피일)】은 漢文(한문)으로 「이 날 저 날」이라는 뜻이고, 【於此彼(어차피)】와 같은 漢字(한자)를 쓴다는 것을 記憶(기억)하시면 헷갈릴 일이 없을 것입니다.

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

@hongminhee@hollo.social · Reply to Chee Aun 🤔's post

@cheeaun Yeah, indeed… 😂

The screenshot of the above post. The code block is syntax-highlighted with wrong colors.
ALT text detailsThe screenshot of the above post. The code block is syntax-highlighted with wrong colors.
洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to wakest ⁂'s post

@liaizon You don't need to use Phanpy, but you need use Hollo or Hackers' Pub or any other fediverse server which doesn't strip colors.

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

@hongminhee@hollo.social · Reply to Aslak Raanes's post

@aslakr As far as I know, there's no such thing. 🤔

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

@hongminhee@hollo.social · Reply to Emelia 👸🏻's post

@thisismissem Yeah, no hurry! Work at your own pace.

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

@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

Here's how it looks like in Phanpy.

The screenshot of the above post in Phanpy. The code block is syntax-highlighted.
ALT text detailsThe screenshot of the above post in Phanpy. The code block is syntax-highlighted.
洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

By the way, I've added syntax highlighting to the Hollo development version. Here's an example:

def main():
    print("Hello, world!")

It's powered by Shiki, which supports hundreds of programming languages! This feature will be shipped with Hollo 0.6.0, the next minor release.

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

@hongminhee@hollo.social · Reply to Emelia 👸🏻's post

@thisismissem Yeah, that's exactly what I'm waiting for!

← Newer
Older →