😊

GitHub Copilot のプレビューでのデータ学習の有無など|Productivity Weekly(2025-03-26)

こんにちは。サイボウズ株式会社 生産性向上チーム@defaultcfです。

僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。

2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2025-03-26 単独号です。

今回が第 183 回目です。過去の記事はこちら

news 📺

ライセンス条項とお客様のデータ利用について - GitHubブログ

GitHub Japan からのアナウンスです。GitHub Copilot Business、Enterprise において、GitHub Copilot のプレビュー機能を使ってもデータ学習はされないことが明言されました。

背景として、GitHub にはプレビュー機能に適用されがちなプレリリースライセンス条項という規約があり、機能の使用状況を GitHub に送信しうることが記載されています。この条項自体は GitHub 全体として使われており、Copilot のみを対象としたものではありません。
GitHub Copilot Trust Center によると GitHub Copilot Business または GitHub Copilot Enterprise においてデータをモデルの学習に利用しないことが明記されていますが、GitHub Copilot のプレビュー機能についてはどちらの決まりが適用されるのか不明瞭でした(参考: GitHub Copilot Pre-release Terms clarification on Data collected · community · Discussion #61434)。
したがって、慎重に判断して Copilot のプレビュー機能を有効化していない組織も少なくはなかったのではないでしょうか?

そんな中 2025/03 に登場したのが次の記事になります。GitHub Copilot のプレビュー機能は学習される可能性がある旨を警鐘していました。

規約的にどうなん?ということを知らなかった人もいたようで、これが結構 Twitter で話題になりました。
その後、話題になったことと関連があるかはわかりませんが[1]、GitHub Japan から明言された次第です。パブリックにアクセスできる場所で明言してくれたのはとても助かりました。

上記理由でプレビュー機能を利用できてなかった組織の方は、今回のアナウンスのおかげでプレビュー機能利用への道が開けたのではと思います。ぜひ組織内で再検討し、プレビュー機能を利用してみてください。

僕は最近 GitHub Copilot の PR レビュー機能(プレビュー)が使えるようになりましたが、なかなか面白くて色んなプルリクをレビューしてもらっています。プレビュー機能はやっぱりワクワクしますね。

本項の執筆者: @korosuke613

AWS CodeBuild が組織レベルおよびエンタープライズレベルで GitHub セルフホストランナーのサポートを開始 - AWS

https://aws.amazon.com/jp/about-aws/whats-new/2025/03/aws-codebuild-organization-enterprise-level-github-self-hosted-runners/

これまでも度々紹介してきた GitHub Actions セルフホストランナー on AWS CodeBuild ですが、Organization および Enterprise レベルでセルフホストランナーを登録できるようになりました。

これまで、Organization、Enterprise から webhook を受け取ることはできていましたが、ランナーの登録先はリポジトリのみでした。Organization、Enterprise に対してランナーを登録できるようになったことで、GitHub 上のランナーグループ機能を利用して特定のリポジトリのみ許可するといったことができるようになりました。
さらに今回受け取った webhook をフィルタリングする webhook フィルター機能も追加されました。webhook フィルター機能を利用することで、特定ブランチやタグのみ許可するといったさらにきめ細かい制御もできるようになります(参考)。

どんどん GitHub Actions セルフホストランナー環境の選択肢として AWS CodeBuild の存在が大きくなってきていますね!早く GitHub 側で admin:enterprise スコープに対応した Enterprise レベルの GitHub Apps が作れるようになってほしいです。楽しみですね。

発表日 タイトル ランナーの登録先 webhookの送付元 認証方法
2024年4月24日 AWS CodeBuild now supports managed GitHub Action runners repository repository PAT, OAuth App
2024年6月17日 AWS CodeBuild now supports organization and global GitHub webhooks repository repository, organization, enterprise PAT、OAuth App
2024年8月15日 AWS CodeBuild now supports using GitHub Apps to access source repositories repository repository, organization, enterprise PAT, OAuth App, GitHub App
2025年3月12日(今回の変更 AWS CodeBuild now supports organization and enterprise level GitHub self-hosted runners repository、organization、enterprise repository、organization、enterprise (webhook フィルターで制御可能) PAT, OAuth App, GitHub App

補足:

  • 2024 年 4 月の時点では、CodeBuild プロジェクト、webhook の設定をリポジトリごとに行う必要があった
  • 2024 年 6 月のアップデートで、organization または enterprise レベルで webhook を一度設定するだけで、配下の複数のリポジトリからのイベントを受信できるようになった
  • 2024 年 8 月のアップデートで、ソースリポジトリへの認証方法として GitHub Apps がサポートされた
  • 2025 年 3 月のアップデートで、organization および enterprise に対してランナーを登録できるようになった。これにより GitHub のランナーグループ機能を使ったアクセスポリシーの設定もできるようになった。さらに、webhook フィルター機能が追加され、利用して特定の organization や repository のワークフローを許可・拒否できるようになったため、CodeBuild 利用先をより細かく制御できるようになった

本項の執筆者: @korosuke613

Fine-grained PATs are now generally available - GitHub Changelog

https://github.blog/changelog/2025-03-18-fine-grained-pats-are-now-generally-available/

GitHub の Fine-grained Personal Access Token が GA になりました。

Fine-grained PATs は 2022 年 10 月にパブリックプレビューがリリースされました。約 2 年半の長いプレビュー期間を経てとうとう GA になったという感じですね。

とはいえ Fine-grained PATs はまだ Classic PATs 相当の機能を持っていません。わかりやすいので言うと Packages、Checks API の呼び出しができません。
ではなぜ GA になったかと言うと、パブリックプレビュー状態だとサポートが不十分だったり破壊的変更が容易に入る恐れがあると言うことから組織が採用しづらいという背景をなんとかするためとのことです。

Fine-grained PATs は利用に org のオーナーが承認を求められたり、監査ログで個別 PAT の利用状況を追跡できたりと、ガバナンス向上という点で使いやすくなっています。
個人的には、GITHUB_TOKEN(Actions の場合)、GitHub Apps では解決できない場面で初めて PAT を検討するものだと考えているため、そもそも利用機会が少ないのですが、今後は Classic PATs から移行していきたいですね。とりあえず Packages API に対応してほしいのと、admin:enterprise スコープに対応してほしいです。

本項の執筆者: @korosuke613

Java 24新機能まとめ #OpenJDK - Qiita

https://qiita.com/nowokay/items/03e5d720433bd4ba0eec

Java 24 がリリースされました!取り込まれた JEP や、JEP 以外の変更点についてまとめられています。
コンストラクタの super 文の前に色々書けるようになったり、void main() だけで main メソッドが書けるようになるなど、便利な構文のプレビューが進んでいます。
また、最近色々な言語で導入されている耐量子計算機暗号関連の機能も追加されています。

次の Java 25 は LTS の予定です。楽しみですね。

本項の執筆者: @takoeight0821

Amazon Bedrock Guardrails announces policy based enforcement for responsible AI - AWS

https://aws.amazon.com/jp/about-aws/whats-new/2025/03/amazon-bedrock-guardrails-policy-based-enforcement-responsible-ai/

Bedrock のガードレールについて、IAM でより権限を絞ることができるようになりました。
ガードレールは、生成系 AI のモデルへの入出力のフィルタリングを行うことで、生成系 AI アプリケーションのユーザーに一貫した UX を提供し、安全性やプライバシーを向上させるというものです。

今回の変更により、IAM のポリシーにて bedrock:GuardrailIdentifier を指定できるようになりました。
これにより、invoke や converse でモデルの推論する際に、適切なガードレールが設定されていなければ実行を拒否することが可能になります。
具体的には次のような指定ができます。
https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-permissions.html#guardrails-permissions-id

推論実行時にガードレールを強制できるようになるわけですから、より安全になって良さそうですね。

本項の執筆者: @defaultcf

Trapping misbehaving bots in an AI Labyrinth

https://blog.cloudflare.com/ai-labyrinth/

AI 同士のバトル勃発です。近年、Cloudflare のネットワーク上では AI クローラーが毎日 500 億以上のリクエストを飛ばしており、このようなリクエストからユーザーを保護したいです。しかし、AI からのリクエストを素朴にブロックすると、その旨が AI 側に知られる場合があります。そこで、敵 AI からのリクエストは、味方 AI が生成した迷路のようなサイト「AI Labyrinth」に誘導し、そこで時間と資源を浪費させるとのことです。

善良なクローラーがとばっちりを受けそうなのは少し気になりました。

本項の執筆者: @ajfAfg

know-how 🎓

TypeScript使いの憂鬱:never型はプロパティを持つか | 雑記帳

https://blog.miz-ar.info/2025/03/typescript-never-property/

never 型は任意の型の部分型なんだから任意のプロパティを持てるはずだよね、だけど TypeScript はアドホックな規則の影響でプロパティを持てないよ、という話です。

型 A が型 B の部分型であるとき、A は B の全てのプロパティを参照できます。例えば、A = {x: number, y: number} かつ B = {x: number} とすると、A は B の部分型であり、確かに A は B の全てのプロパティにアクセス可能です。だとすると、任意の型の部分型である never 型は任意のプロパティにアクセス可能であるべきです。しかし、TypeScript ではそうではないようです。

Twitter(現 X)を見てると、never 型はいわゆるボトム型ではなく、プリミティブ型を含む一部の型らの交差型みたいです。まことに!?
https://x.com/57tggx/status/1904162984798376310
https://x.com/mizchi/status/1904345477337985332

この辺りを深掘りしたことがなかったので面白かったです。

本項の執筆者: @ajfAfg

read more 🍘

Productivity Weekly で出たネタを全て紹介したいけど紹介する体力が持たなかったネタを一言程度で書くコーナーです。

あとがき

サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック!
https://www.docswell.com/s/cybozu-tech/5R2X3N-engineering-productivity-team-recruitment-information


脚注
  1. 個人的には話題になったからアナウンスされたのでは?と踏んでいます。警鐘を鳴らしてくれた Qiita 記事の著者には大変感謝したいです。 ↩︎

サイボウズ 生産性向上チーム 💪

Discussion