← 2026-05-14 の一覧へ戻るホーム
GitHub を辞めて Forgejo に移った。

2026/05/13 21:54

GitHub を辞めて Forgejo に移った。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

2026 年 4 月 27 日、オランダ政府は、プロジェクトマネージャーの Boris Van Hoytema の監督の下でオープンソースの Forgejo プラットフォームのセルフホスト版である code.overheid.nl を正式に稼働させ、デジタル自律への決定的な転換を告げた。この動きは、ベンダーによる統制とサービス信頼性に関する緊急の懸念に基づいており、2025 年 5 月から 2026 年 4 月にかけて GitHub は 257 のインシデント（そのうち主要な停止 48 件を合わせ）を記録し、合計約 112 時間の稼働停止をもたらした。また、2025 年 8 月に CEO を失った後の GitHub がマイクロソフトの CoreAI シブに吸収されたことに伴い、EU のコードが合意なく AI 訓練用に利用される恐れが生じた。2026 年 4 月 24 日には、データ利用に関する Copilot ポリシーがオプトインからオプトアウトに転換し、リポジトリレベルでのオプトアウトオプションが存在せず、ユーザーは個人でコードスニペットの提供を決定することを強いられた。2025 年 6 月の法廷証言では、FISA 第 702 条や CLOUD アクトといった米国法が、海外に格納された EU データへの政府アクセスを可能にし、主権を損なう可能性があることが確認された。これらのリスクを軽減するため、オランダは GitHub に特有の互換性問題などの初期移行摩擦にもかかわらず、隔離されたインフラ上で Forgejo v15 LTS を導入し、KVM などの堅牢なセキュリティ層を含むデジタル自律の先例を設定した。

本文

GitHub からセルフホストの Forgejo への移行：所有権、信頼性、そしてデジタル主権

私は、コードを GitHub からセルフホストされた Forgejo インスタンスに移しました。これはサービス障害のためにではなく、「所有権」の問題からです。すなわち、その上で動作するものは誰が管理・所有するか、という点にあります。オランダ政府も最近、まさに同じ決断を下しました。

背景とタイムライン

2026 年 4 月 27 日、オランダ内務省は、同省のソースコード用に設置されたセルフホスト型 Forgejo インスタンス 

code.overheid.nl
をソフトランディングさせる形で公開しました。プロジェクトマネージャーのボリス・ファン・ホイテマ氏によると、このプラットフォームは「省内が法的に源代码を自らが所有する場所で公開しなければならない」という要件から生まれたものであり、GitLab ではなく Forgejo が選ばれたのは、完全にオープンソースであり、デジタル自律性に必要なすべての自由を提供するからだそうです。

一週間前、私は静かに自分自身のコードも同じ方向へと移行させました。私の標準的な Git ホストは現在 

code.jorijn.com
で、強化された環境設定において、単一の NUC（ネットブック・パソコン用ミニコンピュータ）上で Forgejo v15 LTS を実行しています。すでにいくつかのリポジトリがそこに存在し、残りのものは待機中です。長期的な計画としては、移行完了後に公開中の GitHub リポジトリをアーカイブ化し、それぞれの README に新しい住所への変更を加えることを目指しています。

GitHub から退散する議論の多くは「障害」に焦点を当てています。障害自体は確かに存在しますが、それがこの決断の唯一の理由ではありません。サービス障害、デフォルトで AI に参加させる仕組みへの同意（opt-in）、そして GitHub がもはや独立した CEO を有していないことなどは、すべて一つの根本的な事実を示しています：「私はこれを所有していません」。オランダ政府も先日、同様の結論を公表しました。本ドキュメントは、この決断に至る長期的な思考プロセスと、実際の移行が完了した後の姿について記述しています。

TL;DR

  • GitHub の信頼性: 2025 年 5 月から 2026 年 4 月まで、GitHub は 257 件のインシデント（そのうち 48 件が重篤）を記録しました。CTO は公に謝罪し、AI に driven な負荷に対処するにはキャパシティを 30 倍も拡大する必要があると認めています。
  • 企業構造: 2025 年 8 月、GitHub は独立した CEO（トマス・ドームケ氏）を失い、Microsoft の CoreAI 部門に吸収されました。現在は Copilot と広範な AI ス tack に注力するユニットとなっています。
  • データポリシーの転換: 2026 年 4 月 24 日、GitHub は Copilot ユーザーインタラクションデータを AI 学習のためにデフォルトで「同意（opt-in）」制に変更しました（以前は異議申し立て(opt-out) でした）。リポジトリレベルでのオプトアウトはありません。各コントリビューター自身が個別にこれを無効化する必要があります。非公開リポジトリも、Copilot を使用しながら生成されたインタラクション文脈によってリスクに晒されています。
  • 法域上のリスク: アメリカ合衆国の管轄下（FISA 第 702 条および CLOUD Act）は依然として解決されていない重大なリスクです。Microsoft の弁護士は宣誓供述の中で、米国政府の静默的なアクセスに対して EU データの安全を担保できないと認めています。「EU データ居住」は対策ではなく、安心感に過ぎません。
  • 政府の先例: オランダ政府も 
    code.overheid.nl
    向けに Forgejo を選択したのは同じ理由でした：完全なオープンソース、オープナーコア（open-core）モデルによる分割がないこと、そしてデジタル自律性のためです。
  • 私の環境: 
    code.jorijn.com
    は、単一の NUC上で KVM 分離されたアクションランナーが週ごとの再構築を通じて動作する Forgejo v15 LTS を実行しています。

なぜ障害が本当の原因ではないのか

2026 年 4 月のサービス障害は深刻でした。4 月 23 日、マージキュー機能フラグの展開が無断で、658 のリポジトリにわたるコミットを逆転させました。その 4日後、過負荷状態にあった Elasticsearch クラスターがプルリクエスト、イシュー、およびパッケージのオフライン化を招き、超過 6 時間に及ぶ障害を引き起こしました。2026 年 2 月単独で記録されたインシデント数は 37 件に上ります。

しかし、この事象を読むべき方法は単に「GitHub は信頼できない」というものではありません。大規模システムは故障します。問題提起の方法が重要です。CTO のヴラド・フェドロフ氏は、負荷の要因を 2025 年 12 月以来の「エージェント型 AI ワークフローの成長」に直接関連付けました。GitHub は AI 機能の開発を加速させており、この障害はまさにその加速が生産環境においてどのような形を取るかを表しています。他のプラットフォーム（GitLab、Bitbucket、Vercel）も同様の要求圧力の下で開発者を提供していますが、この特定の一昨年の危機的パターンは見られません。

GitHub はもはや独立した CEO を持っていない

より重要な事実です。この事実は謝罪よりも古いです。2025 年 8 月 11 日、トマス・ドームケ氏は退任しました。GitHub に新しい独立したリーダーが代わって就任したのではなく、Microsoft の CoreAI 部門に吸収されました。

  • 収益、エンジニアリング、サポートは現在、Microsoft の開発者部門へと報告しています。
  • CPO は Microsoft の AI プラットフォーム VP に報告します。

2018 年から 2024 年まで、GitHub に残存すべきとの論拠は、Microsoft がそれを一定の距離に保っていたというものでした。これはドームケ氏が製品の意思決定において実質的な座を有していた間には事実でした。しかし 2025 年 8 月以降、この論拠はもはや成立しなくなりました。今日 

github.com
にコードをプッシュする場合、それは Microsoft の AI 組織の一ユニットへとプッシュすることになります。あなたが Microsoft の AI 組織にどれほど信頼するかによって、それがどう気になるかは異なります。旧来の GitHub があなたのリポジトリについて行っていたであろう同じ決定を下してくれるかという点です。私はもはやそう信じていません。

学習データのデフォルトが逆転した

2026 年 3 月 25 日、GitHub は 4 月 24 日から有効となるプライバシーステートメントの変更を発表しました：

  1. 同意（opt-in）ではなく異議申し立て (opt-out): デフォルトとして、Copilot Free、Pro、および Pro+ ユーザーから得られるインタラクションデータ（入力、出力、コードスニペット）は、設定で明確にオフにするまで学習用途に使われます。
  2. リポジトリレベルでのスイッチなし: メンテナとしての私は、GitHub に自分のリポジトリ内のインタラクションを学習させないよう指示することはできません。オプトアウトはユーザーアカウント単位です。私のコードベースは、Copilot を使用して触れるすべての人がそれを学習材料にします。
  3. 非公開リポジトリは安全ではありません: GitHub が非公開リポジトリのコンテンツを「静止状態（at rest）」で使用しないことを主張していますが、Copilot が非公開リポジトリ内で使用される際に生成されたコードスニペットとインタラクション文脈を収集します。この境界線は曖昧です。

Copilot Business およびエンタープライズ顧客は、別途のデータ保護合意によって例外となります。この分割は明確です：十分な支払いを行えばインタラクションは学習データではなく、それ以外は学習データになります。GitHub はあなたのインタラクションデータへの戦略的関心が構造的に不可欠であり、オプションのものでは不再是ません。私はこのプラットフォーム上でいたいとは思いません。

それから管轄権の問題があります

GitHub Inc. と Microsoft Corp. はアメリカ合衆国企業です。彼らが保持するものはすべて、FISA 第 702 条および 2018 年の CLOUD Act を含む米国法の範囲内にあります。どちらもデータの物理的位置に関係なく適用されます。

  • 第 702 条: 米国内の住居にある提供者を通じて非米国人に対する情報収集を許可します。
  • CLOUD Act: 世界にどこかに保存されたデータを生成することを米国法執行機関が米国の本部を持つ会社に対して命令できることを可能にします。

GitHub はエンタープライズクラウドで EU データ居住を 2024 年 10 月に発表しました。これはデータ所在地は解決しますが、管轄権の問題は解決しません。CLOUD Act の曝露は企業のコントロールに従い、地理には従いません。コードが 

github.com
にある限り、あなたのコードは米国の法的領域に住んでいます。

オランダ政府の決断：code.overheid.nl

オランダ政府の選択は、「Open, tenzij」ポリシー（公費で開発されたソフトウェアは原則としてオープンソース）により注意を引くべきです。コンプライアンスのために、彼らは実際に制御できる場所でコードを公開する場所が必要でした。

code.overheid.nl
はその答えです。

欧州委員会では GitLab (

code.europa.eu
) を運用しており、ドイツの 
openCode
もまた GitLab を使用しています。フランスは集約剤を使用しています。オランダ政府は意図的に Forgejo、GitLab ではありません。

  • 合理的根拠: Forgejo は完全にオープンソースであり、オープナーコア分裂がありません。デジタル自律性の自由を提供します。
  • ガバナンス: ファン・ホイテマ氏は、Forgejo のロードマップが他の選択肢に比べて「はるかに整合性がある」と述べました。政府は単に主権的なフォージだけでなく、商用ベンダーのプレミアムティアによってブロックされないものを求めていました。

この制度的なパターンは重要です：真面目な弁護士を備えた国家政府は、同じ画像を見て、同じ決断を下し、私が行う週よりも前にそれを出荷しました。これは決断がもはやマジョリティではないという証拠です。

なぜ Forgejo なのか、GitLab はなぜ違うのか

GitLab を真剣に検討しました。セルフホスト型 GitLab CE は既知のエコシステムと洗練された UI を有しています。しかし、2 つの要素がこの選択を傾かせました：

1. ライセンス

GitLab は「オープンコア」です。コミュニティエディションは MIT ライセンスですが、多くの生産環境に必要な機能は非自由ライセンスでエンタープライズティアに存在します。Forgejo は別の道を選びました：2024 年 8 月 24 日（v9.0）で、MIT から GPLv3+ へ再ライセンスし、copyleft を維持し、将来の商業的支配に対抗することを明確な目標としました。Gitea からのフォークは、正に Gitea Ltd がコミュニティの同意なしで商標を掌握したという教訓を反映しています。

2. ガバナンス

Forgejo は Codeberg e.V.（2018 年以来ベルリンに登録された）の下で運営されています。メンバー選出の理事会、公開予算、および 30 万個以上のリポジトリがあります。メンバーは年次で予算に投票します（2025年の計画は全会一致：88 賛成、0 反対、1 棄権）。これはドイツの Verein がするべきことであり、単なるマーケティング主張ではありません。

技術的なステータス

  • Forgejo v15.0 LTS は 2026 年 4 月 16 日に出荷されました（プロジェクトの 100 回目のリリース）。
  • ランニングサポートは 2027 年 7 月 15 日まで続きます。
  • Actions が v15 で成熟しました（一時的ランナー、OpenID Connect、再利用可能なワークフローの拡張など）。

注釈: セルフホスト型 Forgejo のための商業エコシステムは薄いです。最も清潔な提供は Codey by VSHN です（スイスホスト管理型の Forgejo で 19 CHF/月）。Red Hat スタイルのエナタープライズサポートサブスクリプションはありません。24 時間/7 日の電話サポートが必要な場合は、自分で構築するか、待つしかありません。私はプラットフォームを所有することを優先するため、待つことに寛容です。

私が行ったもの：
code.jorijn.com

ハードウェア: 64 GB RAM を備えた単一の Intel NUC。 スタック: Forgejo v15 LTS、Postgres 17、Traefik が Docker 内で実行されています。Incus で管理された KVM 仮想マシンがそれらと並んでおり、Actions ランナーを実行しています。それがプラットフォーム全体です。

興味深い決断は Forgejo のデプロイ自体ではありません。最も多くの思考を要したのは ランナー です。

危険が実際にどこにあるか

フォージをセルフホストする場合、フォージ自体は簡単な部分です。難しい部分は CI ジョブを実行する何かです。私のランナーは、自分のリポジトリで生成されたロックファイルに対して 

npm install
、
composer install
、および 
pip install
を実行します。これはライフサイクルスクリプトを実行することを意味します。すべてのジョブは潜在的に不信任されたコードを実行することを意味します。

ランナーの仕事: コードを実行することではなく、実行中にコードを 収容 することです。ランナーアーキテクチャ内のすべてのものはその理由のために存在します。失敗した場合に次のレイヤーが失敗を吸収するように設計してください。

防衛策（最も弱いから最も強いまで）

ランナーは 5 つの重なり合うレイヤーを使用しています：

  1. 永続的 KVM 仮想マシン: ランナーはホスト上のコンテナではなく独自の VM に存在します。ホストカーネルはジョブ環境と共有されません。ランナー内の Linux カーネル CVE が NUC を触るには、KVM の境界を壊す必要があります。
  2. gVisor をデフォルトの Docker Runtime として: ジョブコンテナは 
    runsc
    の下で実行され、システムコールをユーザー空間でインターセプトし、ホストカーネルに渡しません。コンテナエスケープには gVisor と周囲の KVM の両方を壊す必要があります。
  3. 週次破壊的な再構築: 毎週月曜日の UTC 02:00 に、すべての VM が破壊され、新しく焼かれた Ubuntu ベースイメージと新しい永続的ランナー登録から再作成されます。ベースイメージ自体は日曜日に再構築されます。永続状態は最大 7 日間しか生きられません。
  4. nftables エグレスフィルター: ランナーはポート 
    :443
    、
    :80
    、
    :22
    、および 
    :53
    をパブリック宛先（npm、pypi、ghcr）に到達できます。内部ネットワーク（
    192.168.0.0/16
    など）には到達できません。Compromised ジョブは LAN をスキャンしたり、ルーター管理インターフェースに到達したりできません。
  5. 範囲制限されたランナートークン: 永続的ランナー登録は単一ユーザー/組織の範囲（例：
    write:user
    、
    write:organization
    ）に紐付けられています。漏洩したトークンはその範囲の外でランナーを登録できず、管理範囲の何ものもできません。

まとめ: 各レイヤーはフェンスです。それらと一緒に、深さのある周回線を作ります。これは新しいものではありません；プリミティブはアップストリームにあります。革新は、プラットフォームが単一 NUC に収まり、清潔にリバートできるためにそれらを単一ユーザーのホームラボ向けにワイヤーすることです。

放棄したもの

セルフホスト型 Forgejo への移行にはコストがかかります：

  • 発見とソーシャルグラフ: GitHub はコントリビューターが私を見つける場所です。誰かが小さな修正をプッシュする場合、彼らは 
    github.com
    でそれを期待します。私の計画は、移行完了後、公開中の GitHub リポジトリをアーカイブし、README を 
    code.jorijn.com
    に指差すことです。現在、実際の間隙があります；私はこれを受けます。
  • GitHub Actions エコシステムの脆弱性: Forgejo Actions は親しみやすさを求めますが、完全な互換性を求めません。
    • ワークフローレベルでの 
      permissions:
      ブロックは静かに無視されます。
    • actions/checkout@v6
      は 2026 年初頭に非-GitHub ランナーでの認証チェックアウトを壊しました（v5 に固定）。
    • actions/upload-artifact@v4
      は Forgejo ホストフォークが必要です。
    • OIDC は機能しますが、GitHub の 
      permissions.id-token
      よりも異なるワークフローキー (
      enable-openid-connect: true
      ) を使用します。 ワークフローが GitHub 固有の機能に強く依存する場合、移行は夜間のプロジェクトではなく、プロジェクトになります。
  • Dependabot: Forgejo にはありません。私は同じランナー上で Renovate を実行しています（3 時間スケジュール）。より多くの設定で同じ仕事をしますが、セットアップには 1 日かかりました。
  • 24/7 ベンダーサポート: GitHub Enterprise は電話番号と SLA を提供します。Forgejo はイシュートラッカーとチャットルームを提供します。これは一人のオペレーションでは問題ありませんが、200 エンジニア組織ではそうではないかもしれません。

このやり方は価値がない場合

セルフホスト型 Forgejo への移行を行わないでください：

  1. ゼロインフラストラクチャアペタイト: 管理された Forgejo（Codey または Codeberg）は大部分のギャップを閉じますが、あなたはまだ移行コストを所有します。
  2. GitHub 固有機能への大量投資: アプリマーケットプレイス、Codespaces、Copilot Workspace、高度セキュリティなど。Forgejo はフォージであり、開発者プラットフォームサービスではありません。
  3. コントリビューターベースが GitHub ソーシャルグラフに依存: 発見可能性が所有権よりも重要なら、コントリビューターがいる場所にいます。アーカイブして後から移行し、決断を見直すことができます。
  4. クレディブルランナー回答なし: ランナーは物事が深刻になる場所です。KVM 分離、gVisor、週次再構築、LAN をブロックするエグレスフィルター（または管理されたランナーホストを使用）に準備されていない場合は、GitHub に留まるべきです。

オランダ政府のモデルは正しいモデルです：彼らはすべてを一度に移行しませんでした。

code.overheid.nl
は ministry がオープンソースコードを共有するためのソフトランディングプラットフォームであり、包括的代替品ではありません。私のセットアップは同じ形状に従います。

主要な教訓

  • 独立性の喪失: 2025 年 8 月以来、GitHub は独立した会社ではなく、Microsoft の CoreAI 部門の一部です。
  • 下流の症状: 2026 年 4 月のサービス障害と Copilot 学習データデフォルト転換は、この構造的シフトの予測可能な結果です。
  • 管轄権の現実: FISA 702 と CLOUD Act 下の米国管轄下リスクは実在しており、顧客側から解決できません。EU データ居住は安心感であり、対策ではありません。
  • 制度的先例: オランダ政府は 
    code.overheid.nl
    ために Forgejo を選びました（主権性、オープンソース、商業的ゲートキーピングがないため）。このパターンが形成されています。
  • 防御可能なセルフホスティング: セルフホスト型 Forgejo デプロイメントは単一 NUC で実現可能ですが、ランナーには真の注意が必要です：KVM 分離、gVisor、週次再構築、範囲制限トークン、LAN をブロックするエグレスフィルターなど。
  • 移行戦略: 移行摩擦は実在します。公開 GitHub リポジトリをアーカイブし、新しい住所へのポインターを持つことで、発見経路を維持しつつ、移行を完了できます。

同じ日のほかのニュース

一覧に戻る →

2026/05/11 5:54

Linux のゲーム処理が高速化しているのは、Windows API が次第に Linux カーネル機能へと統合されてきたからである。

## Japanese Translation: 2026 年 3 月、Steam ライニングでの Linux ゲーム利用は史上初の重要な人口統計学的閾値を超え、Steam ユーザーベースの 5％に達した。同時に、NTSYNC ドライバーの導入により主要な技術的マイルストーンを達成した。CodeWeavers とオープンソースコミュニティが共同開発した NTSYNC は、Linux カーネルに直接統合され、以前は Wine/Proton のワークアラウンド（例：fsync）によってエミュレートされていた Windows 協調ツールに対して、ネイティブの実装を提供する。 Valve のエンジニアである Pierre-Loup Griffais が推奨する通り、2026 年 3 月の更新済み Steam Deck においてデフォルトでロードされるこのドライバーは、デッドロックやフイッチなど長年存在したエッジケースの問題を解決する。ベンチマーク結果によると、NTSYNC は顕著なパフォーマンス向上をもたらしており、未変更のアップストリーム Wine と比較するとフレームレートの最大 200％の増加を実現している。ただし、Proton（すでに fsync を含む）に対する利得はより modest（小規模）である。Microsoft が昨年 10 月に Windows 10 の公式サポートを終了したという背景において、この進展は技術的障壁を軽減し、Bazzite、CachyOS、Fedora、Ubuntu など複数のディストリビューションが新しいカーネルバージョンを採用するよう促すことで、Linux エコシステムを強化している。これは、外部パッチへの依存から、Windows 互換性を Linux コアに直接組み込むという戦略への変換をもたらした。

2026/05/13 23:45

地域レベル（自治体）向けの無料ドメイン「*.city.state.us」の設定手順（2025 年）

## Japanese Translation: 米国の居住者および組織は、特定の町が .us 下のサブドメインを委任した場合に、無料で地域固有のドメイン名（例：frederick.seattle.wa.us）を検索・登録することが可能です。対象者は米国市民または永住者、米国で設立された団体、あるいは米国において実際の事業活動および合法な活動を行う組織に限られます。地域固有ドメインは 1992 年に作成され、以降も政府との契約下で運用されていますが、インフラの變更により多くの連絡先リストが陳腐化しています（例：NW Nexus が 2009 年に NuOz Corporation に再編されたこと等）。委任されていないドメインは NeuStar が管理しており、2002 年のポリシーに従い現地政府のみを対象としています。特定の地域サブドメインが存在しない場合、gen.your-state.us 下（例：next.gen.oh.us）で一般的な独立系エンティティとして登録できます。登録には「Interim .US Domain Template v2.0」を使用し、申請者は組織情報を自身の詳細で記入し、メールを Admin/Technical/Zone コンタクトとして記載しても構いません。登録時に提供される個人アドレスは WHOIS 結果に表示されず、表示されるのはレジストラー情報のみです。承認には手動レビューが必要であり、所要時間は数日から数週間かかります。承認後、申請者はレジストラーが提供する無料のネームサーバーを介して DNS レコードを追加することで構成します（例：Amazon Lightsail の場合）。Lightsail を使用するには、AWS アカウントを作成し、「Domains & DNS」から「Create DNS zone」をクリックし、「Use a domain from another registrar」を選択し、提示されたネームサーバーアドレスを記録します。これらのサーバーの IP アドレスは、オンライン DNS ツールまたは `dig` コマンドを使用して解析できます。最後に、Lightsail（または同等のサービス）で DNS レコードを追加し、GitHub Pages や他のサーバーなどへのポインタを設定することで、有料ホスティング費用なしに真正な地理的 소유権を確保できます。申請者は、企業の構造を反映していない可能性があるレガシーの連絡先データに依存する際に注意する必要があります。

2026/05/09 20:14

グーグルにおける IDE の歴史

## 要約： Google は、デスクトップ型エディタと初期段階の独自 Web エディタ（「Cider」）から構成されていた分断されたエコシステムから移行し、単一の成熟した Web ベースのプラットフォームである Cider V に統合することで、膨大なソフトウェア開発事業を一元化しました。この重要な転換は、2020 年頃、VSCode をフロントエンドとして採用するピボットにより開始され、各内部ツールに対して独自のカスタム統合が必要という長年のツールの課題に対処しました。当初のリーダーシップが「不満」を引き起こすリスクや、エディタへの宗教的な熱狂を理由に単一エディタへの強制を推奨しなかったことに対し、Google は Cider V のバックエンドサーバーアーキテクチャを利用して重いインデックス化タスクを外注することに成功し、規模拡大における以前の限界を克服しました。導入の拡大は緩やかでした；元々の Cider は技術作家には支持されていましたが、Java 開発者からは懐疑的な態度が示され、VSCode ベースのアプローチにより馴染みのある体験を提供するまで、その姿勢を変えませんでした。2023 年までに Cider V は主要なコードベースの 80% をカバーし、分散した環境を標準プラットフォームに置き換えるとともに、クロスチーム拡張機能や自動コードレビュー、スマートペーストといった高度な AI 機能をサポートしています。

GitHub を辞めて Forgejo に移った。 | そっか～ニュース