テクブロ — 技術ブログの新着まとめ

未読のみfreee

33件

フィード

freee·2026/04/30

freee の Agile Security を支える Security Champions

こんにちは、北海道から freee red team*1に参加している yu です。北海道は春らしい暖かい日が続き、雪も溶け、私は冬に家の前で落としたスマートリングをようやく見つけることができました。北国での冬の落とし物は往々にして春を待たなければならないことがあります。さて、そんなことよりも今日は2022年に始まった freee Security Champions*2 のこれまでの歴史と、今なお進化し続けるこの制度についてご紹介します。 Security Champions Program の開始（2022年） 2022 年に私が freee へ入社した頃、当時の PSIRT（Product Security Incident Response Team）は急速に拡大する Agile な開発組織の中でどのように Shift Left*3 するのか少ないリソースの中で腐心していました。そうした中で PSIRT の先人たちが組織に働きかけ続け、それに呼応するエンジニアが現れ始めていた中、入社間もない自分がラフに制度設計して「Security Champions やりたい人は手を挙げて！」というなり多くのエンジニアが手を挙げてくれました。この辺りの話は Software Design 2024年8月号にも寄稿しています。 gihyo.jp 先述の通り当時の PSIRT はリソースの少なさから仲間探しに奔走しており、その中で開発チームと PSIRT の橋渡しをしてくれるエンジニアとして Security Champions Bronze Rank を制定しました。 Bronze ということにはその上位に Silver と Gold があるはずですが、そうした制度設計を待たずにこの制度は走り出しました。大いなる見切り発車です。なお、bronze rank champions になるメリットは「かっこいいステッカーがもらえる」です。 Silver Rank 制定（2024年）立候補した Champions たちは私たちの期待に応えて様々なコミュニケーションを提供してくれる一方で、「明確に何をすれば良いのかわからないぞ」という当然の不安に身を寄せ合って集まったのが freee 販売というプロダクトに関わった Champions たちでした。そうして集まった彼らは私たち PSIRT が行っていた SDR（Security Design Review、設計プロセスにおけるセキュリティレビュー）を PSIRT よりも先に自分たちで行うという活動を自発的に始めました。そして、チームの開発事情に明るい Champions がセキュリティ観点で Review を行った Design Doc は私たち PSIRT の SDR の認知負荷や判断コストを大きく下げ、SDR の高速化が進みました。これに味を占めた私は、「有効な SDR を10件行った Champions を Silver Rank とし、Silver Rank Champions が行う Review は PSIRT の Review と同等のものと見做す！」ということにしました。発足からここまでに1年以上経っており、やりっぱなしで放置していた自分の怠慢をよそに Champions 制度を Champions 自身が拡張した結果、適切な目標が見つかった格好です。その後 Silver Rank Champions は徐々に増え、Security Champions のレビュー欄は freee の Design Doc のテンプレートに埋め込まれました。 2026/2 に社内イベントで発表した「Security Champions Recap」登壇資料より抜粋それからも freee という組織は拡大を続け、セキュリティチームが開発プロセスの中に挟まることがボトルネックになりかねない状況が続く一方、freee の Security Champions は増え続け、SDR を自発的に行い、セキュアで品質の高い開発サイクルの高速化に貢献し続けました。そのうち Champions の間で脅威分析の代表的な手法の STRIDE が流行るなど、私の想像を超えるムーブメントが静かに進行していきました。 AI エージェント時代の Security Champions（2025年〜） 2025年には AI エージェント元年を迎え、これまでとは異なるレベルの開発スピードの変化がありました。脆弱性診断全般を担当していた私たち red team も強い危機感を覚え、年始から AI エージェントによる自動診断機能の開発を行い、同年6月にはこの機能を用いて「開発者自身で脆弱性診断を行い」、「red team と一緒に検出された指摘事項をトリアージする」というフローを開始することでこの変化に対応しました。 developers.freee.co.jp これによって脆弱性診断における大きな高速化を実現した一方で、2025年の下半期はさらに開発スピードが早まり、LLM の診断結果に対する人間のレビューがボトルネック化してきました。そんな中、そうした影響を感じないプロダクトが一つだけありました。そのプロダクトチームは、脆弱性診断のスケジュールが余裕を持って組まれ、開発者自身が適切にトリアージし、そもそも LLM に指摘される脆弱性の数が段違いに少なかったです。もちろん、このチームも Coding Agent を上手に使いこなしていたし、開発スピードも他のプロダクトと遜色ありません。それが前述の freee 販売のチームでした。Security Champions 創設期から関連するチームの Champions たちが連携してバーチャルチームとして活動を続け、メンバーがマネージャーになったり異動したりしたら後継者をアサインするなど、一つのチームとして Champions 同士が連携し、活動の幅を広げ、サステナブルな改善を繰り返してきました。Dependabot Alert の数も段違いに少ないです。 LLM によるレビュー品質や、レビューを必要としないガードレール設計の必要性が議論される昨今、これは全く異なるベクトルの驚くべき結果だと思い、思わず塩漬けしていた Gold Rank Security Champions の要件を固めました。それは「事業部においてセキュリティ文化を醸成できたチームの中で、その功績に最も貢献した人」です。販売チームの Champions たちにそれぞれ推薦文を書いてもらったところ、創設期から中心的な役割を担い、また、セキュリティ改善のための機能実装などを行ってきたエンジニアが満場一致で freee 初の Gold Rank Champion に選ばれました。自分が Security Champions の制度設計に悩んでいた頃に壁打ちをしてもらっていたエンジニアでもあり、個人的にも「やっぱりこの人か」と納得感のある任命でした。 freee Security Champions のこれからさて、そうしたセキュリティ文化が醸成したチームにおいては、セキュリティ面においてもっと攻めた施策を行なっても応えてくれるはずです（いつも無茶振りしてごめんね）。 red team では兼ねてより LLM による脆弱性診断を GitHub の PR や Milestone 単位でスケジュール実行できる機能開発を続けてきましたが、それを実運用化すると従来よりも遥かな開発サイクルの高速化が達成できる一方、これまでと異なる統制フローが必要になり、red team によるトリアージが行き届かなくなる懸念がありました。 Gold Rank Security Champions が所属するセキュリティ文化が醸成されたチームでは、そんな心配をしなくても良いかもしれません。この機能を使いこなしてくれるはずですし、判断に困ることがあれば気兼ねなく相談してくれる信頼がお互いにあるはずです。こうして、freee のセキュアな開発サイクルはより一層の高速化を実現していくことができそうです。おわりに Coding Agent が一般的になった現代において、「エンジニア」という定義は揺らぎ始めています。もちろん、誰でもコードを書けるということ自体はとても素晴らしいことだと思っています。それでも、品質保証やセキュリティに関わる私のようなエンジニアにとって、本当に信頼できる「エンジニア」という概念は今もまだ全く変わっていません。そして、そうしたエンジニアに追いつこうと Gold Rank を目指す Security Champions たちがより積極的に動き始めていることも freee の中で観測しています。今後はエンジニアリング以外の領域にも、このムーブメントを広げていきたいと考えています。 *1:所属する組織に対して擬似的なサイバー攻撃を行う愉快なチームです。 *2:Security Champions とは OWASP Security Culture で定義されたプログラムですが、freee ではこれを独自に再定義し、ボトムアップ型のムーブメントにしています。 *3:ソフトウェア開発ライフサイクルにおいてテストやセキュリティ対策を企画や設計、実装フェーズなどのより早期に実施するアプローチ

セキュリティ
Agile
組織開発

freee·2026/04/22

GitHub Copilotにソースコードを学習されないために対応したこと

GitHubが大好きなセキュリティチームのhikaeです。GitHubは先日、GitHub Copilot Free / Pro / Pro+ の入出力などを、オプトアウトしない限りAIモデルの学習に利用する方針変更を発表しました。適用は2026年4月24日を予定しています。Copilot Business / Enterprise の利用者はこの変更の対象外ですが、本当に安心なのでしょうか？「自社の開発者が必ずBusiness / Enterpriseライセンスの経路で使っている」と言い切れるかという観点から、意図せず学習に使われる経路をどう塞ぐかについて実装方法を整理し、その実装方法を整理し社内で実施した対処法について紹介します。 github.blog 学習許可のオプトアウトに注意今回注意すべきはinteractionの範囲です。もしもCopilotユーザーが学習利用をオンにしている場合、プライベートリポジトリ内でCopilotを使用中に生成されたコードスニペットが収集対象となります。また、Web画面上やcommit画面*1など至るところにCopilotはGitHubに組み込まれており、気づいたらCopilotに情報が流れているという状況です。そして今回採用されているオプトアウト方式では4月24日までに設定を変更しなかった利用者は自動的に学習有効化される挙動になっています。ユーザーが意図しない許可を取ってしまう可能性があり、統制上の大きなリスクがある変更と捉えています。なぜBusiness / Enterpriseを導入していても安心できないのか 1. どのライセンスで動いているかが見えづらい Business / Enterprise Copilotの支払いは企業に紐づきますがライセンスは個人ごとに別途付与される方式です。全員にライセンス付与する設定を有効化していない場合は付与していないユーザーはポリシー制御外になります。利用者は組織に招待されてVS CodeでCopilotが使えるからとそれがBusiness / Enterpriseライセンスとは限りません。 IDE上のサジェスト体験は同じでありプランに移動するまで区別がつきません。実際に自分は検証のためにCopilotを解約してみました。月末までアクティベーション（有効化）されるのですが、月初になってプランが切り替わったことに気づきませんでした。テナントごとにアクセス制限がされる設定は現時点で存在しません。 2. 無料プランが勝手に動く気づかない理由の1つに無料プランがあります。現在、Copilotサブスクリプションを持っていない場合でもFreeプランに自動サインアップされ、即座に利用を開始できるフローになっています。つまり、組織の管理外の個人アカウントでサインインするだけで、学習対象のFreeプラン経由の通信が開始されるわけです。 3. VSCodeでCopilotがビルトイン追い打ちをかけるように、VSCode 1.116 のアップデートです。4/15にリリースされたVSCodeからGitHub Copilot Chatがビルトイン拡張として同梱されるようになりました。新規インストールでは、チャット・インラインサジェスト・エージェント機能がセットアップ手順なしで利用可能になります。つまり「拡張機能の配布をブロックする」というEDRやプロキシレベルの統制はもはや機能しません。デフォルト状態で、すべての開発者マシンにCopilotクライアントが存在するという前提で設計しなおす必要があります。 code.visualstudio.com 対応方法ここから考慮した対応策と実際にどのような意思決定をしたのかを3つ紹介します。 [却下] 1. Copilotライセンスを組織と連動させる組織で契約しているCopilot Business / Enterpriseのシートが、社員のGitHubアカウント（企業メールドメインで紐付けられたアカウント、またはEMU）に対して確実に割り当てられている状態を作ることが最も確実です。 Business / Enterpriseシートが割り当たっている限り、ビジネス・エンタープライズ顧客との契約でCopilotインタラクションデータのモデル学習利用は禁じられており、GitHubはその約束を守ると明言されており、学習懸念は排除されます。しかし利用しないユーザーの場合は無駄なコストが発生します。勝手に付属するオプションのせいでGitHub単体の利用ハードルが上がるのは悲しいです。 copilotライセンス連動 copilot.github.trust.page [部分採用] 2. プライベートアカウント利用者に個人設定を強制するあくまでもオプトアウトなので、設定さえしておけば学習されるリスク自体は低減可能です*2。GitHub利用者自身に設定をお願いするというのが次に考えられる方法です。しかし、これはあくまで最終手段であり、全てをこれに賭けてしまうのは大量のインシデントを生んでしまいます。 Copilotだけではないですが、チェックすべき個人設定は2点あります。 (a) AI学習オプトアウト https://github.com/settings/copilot/features にアクセスし、Privacyヘッダー下の "Allow GitHub to use my data for AI model training" を無効化することでオプトアウトできます。 (b) 個人でのPush protection有効化 https://github.com/settings/security_analysis の「User」セクションで、"Push protection for yourself" を有効にする。GitHub上のすべてのユーザーは個人設定からpush protectionを有効化でき、これによりリポジトリ側の設定に依存せず、パブリックリポジトリへのSecretプッシュが保護されます。秘密情報の誤Pushは学習経路に直接関係しないものの、個人アカウントの乗っ取りから発生するサプライチェーンが増えているため併せて徹底したいところです。アカウント分離のトレードオフ個人的な感覚として、会社業務用と個人用でGitHubアカウントを分けるという運用方針を設けることが最近のGitHubアカウント運用標準になっています。GitHubの規約変更で、以前は禁止されていたサブアカウント運用が可能になりサインイン中のGitHubアカウントを切り替え可能になったため、「会社のメールドメイン + Business/Enterpriseシート割当済みアカウント」と「個人アカウント」を別物として扱い、業務コードは必ず前者で開く運用を徹底するということが一般的になりました。 freeeではOSS推奨文化なども考慮してこの方法は採用しない意思決定をとっています。その上で、個人と組織はSSOをはじめとした複数のテナント越境を防ぐ検知の仕組みを敷くことを徹底して業務が個人に混ざるリスクを最小化しています。 [採用] 3. 無料プランでの通信をネットワーク層でブロックする意図しない漏洩を防ぐ上で最も効果的なのが、プラン別エンドポイントのネットワーク制御です。GitHub Copilotの特徴としてトラフィックをプランごとに別ドメインに分けており、ファイアウォールでFree / Pro経路だけを遮断できます。このsubscription based routingのおかげで、企業ネットワークのファイアウォールでCopilot Business / Enterpriseへのアクセスを明示的に許可し、Copilot Pro / Copilot Freeへのアクセスをブロックできます。許可：*.business.githubcopilot.com（Business） / *.enterprise.githubcopilot.com（Enterprise）ブロック：*.individual.githubcopilot.com（Free / Pro / Pro+）これは運用コストが低く他サービスへも転用可能な点で有効な制御点です。ライセンス付与漏れや、個人アカウントへの誤サインインが発生しても、通信自体が成立しないため学習経路には乗りません。ファイアウォールが通らない部分で利用されるとこの対策が無効化されるのでそこの考慮はGitHubとは別レイヤでしておくといいでしょう。GitHubでもAuditlogのsource ipを見ることで部分的に発見可能です。 freeeでも複数のAI Agentツールの活用が進んでいる背景もあり、コスト統制も兼ねたライセンスの棚卸しを継続的に実施しています。このルールを適用したことでライセンスが剥奪されたことに気づかずに学習されてしまう懸念を最小限にすることができました。社内のGitHubで動作しようとする個人プランCopilotをブロックする例 docs.github.com ただしこの仕組みにも課題があります。社内ネットワークを通らないものは制御されないため社内ネットワーク外ではこの制御をすり抜けます。そのような環境では同等の社内情報にアクセスできないようにする仕組みでカバーします（SSO, IP allow list）。最終的にはGitHub管理側の認証をどこまで強制できているかでここの実行強度に左右します。 docs.github.com まとめ：安全にGitHubを使うために GitHub CopilotはAI関連プロダクトの中では最もポリシー制御を効かせやすい製品の一つです。AI Control機能が充実しておりMCPサ

GitHub
Copilot
セキュリティ

freee·2026/04/15

PHPカンファレンス小田原 2026に参加してきました！

こんにちは！フリーナンスのエンジニアをやっているthe よしだです！今回は2026年4月11日(土)におだわら市民交流センター UMECOで開催された「PHPカンファレンス小田原 2026」に参加してきました！ RubyKaigi が開催地を毎年変えるスタイルなのに対し、PHPカンファレンスは地域コミュニティが主体となって開催されるという違いがあり、その多様性が面白い部分です。私自身、地方開催のカンファレンスは今回が初参加なのですが、「小田原は首都圏から日帰りで参加でき、地方カンファレンスの良さを味わえる」と聞き、早速参加することにしました。今回はその中で特に印象に残ったトークを紹介していきたいと思います！特に印象に残ったトーク Webアプリケーションエンジニアにも知ってほしいオブザーバビリティの本質 speakerdeck.com オブザーバビリティの概念の丁寧な説明から始まり、初学者だけでなく学び直しの方にも最適な内容でした。また、AIが普及してきた今だからこそ、オブザーバビリティを意識することの大切さを説いており、チーム全体で取り組む重要性にも触れていました。当たり前ではありますが、「ツールを導入することが目的ではなく、考え方を進化させることが必要」の部分には、ハッとさせられることも多く、とても実りの多い内容でした。 PHPと旅するOSI 7階層第二章 docs.google.com PHP で IPルーターを作った話でした。中でもチューニングの部分が非常に面白く、何をしたらどのくらい速度が上がったのか紹介されています。同日の別のトークではPHPでMP3プレイヤーを作成した方の話もあるくらいでして、PHPerのPHP愛を感じるトーク達です。デシリアライゼーションを理解する speakerdeck.com デシリアライゼーションに起因する脆弱性の話から、PHPのデシリアライゼーションについて、脆弱性のデモとかなり丁寧にデシリアライゼーションを理解できるトークでした。特にデモで紹介されたTODOアプリの脆弱性は、分かりやすく、理解の助けになりました。脆弱性を起こさないための方法や、デシリアライゼーションとの付き合い方をまとめており、学びの多いトークでした。ドメインエキスパートだったのでDDD+Claude Codeでチート開発します〜 speakerdeck.com ライトノベルの「なろう系」を彷彿とさせるコミカルな演出で始まりましたが、内容は非常に実践的でAIにおけるゼロイチ開発のリアルを生々しく語っていました。また、まとめとして「ユーザーに向き合って着実に作る」というメッセージを明確に出しており、面白さだけでない熱い話を聞くことができました。 Past, Present, Future: The PHPUnit Story phpunit.expert PHPUnit の作者である Sebastian Bergmann がオンラインで登壇してくれました。 PHPUnitのこれまでを振り返る濃密な時間であり、PHPUnitの恩恵を受けた私たちにとって胸が熱い話が沢山聞けました。このような方々の尽力のお陰で今のPHPは存在していると再認識させられる、そんな時間でした。最後に初めて小田原に降り立ち、カンファレンスに参加しましたが、カンファレンスの満足度も非常に高く、また参加したいと思っています！それだけでなく、小田原には観光でも行ってみたいと思いました！ぜひ、小田原おすすめの観光スポットがあれば教えてください！

PHP
オブザーバビリティ
セキュリティ
DDD
生成AI