フィード

freee·1日前

はてなブックマーク2

RubyKaigi 2026 でfreee Drink upを開催しました!

はじめに こんにちは！freee人事労務のエンジニアのkaseです。 RubyKaigi 2026が函館にて開催されました。 参加された方はいかがでしたか？私は初参加だったのですが、興味のある講演を聞きつつ、ハセガワストアのやきとり弁当やラッキーピエロといったローカルフードを満喫でき、大変満足でした!(少し食べすぎました) freeeは、GoldスポンサーとDrinkupスポンサーとして参加しており、三日目の夜にDrinkupを開催しました。 今回はその模様をレポートします! SweeeもDrinkupの参加者をお出迎え Drinkup当日の様子 Drinkupは、PREMIER HOTEL -CABIN PRESIDENT- HAKODATEにて開催されました。 Matzさんのkeynoteと、次回開催地が宮崎であるという発表をもってRubyKaigi 2026は閉幕。その余韻のなか、Drinkup会場には少しずつ参加者が集まり、乾杯が行われました。 円卓のオードブルを囲みながら、各テーブルで振り返りや会社の話に花を咲かせました。 会場全体は、落ち着いたトーンで、RubyKaigi最終日の夜にふさわしい空気でした。 ビンゴも盛り上がりました 食事が落ち着いてからは、ビンゴも開催されました! これはただのビンゴゲームではなく、RubyKaigiにちなんでRubyのメソッドをビンゴのマスとしたWebアプリを有志で企画し完成させたものです! 先ほどまでの落ち着いた空気から一転、みんな画面に集中して手元のビンゴと照らし合わせていました。 開発運営の私視点では、リーチからなかなかビンゴ達成者が出ず、バグがあるのではと非常にソワソワしました。 先着10名にfreeeオリジナルのノベルティを用意していたのですが、10人目と一瞬の差でビンゴを達成した方がいて……結局、11人にお渡ししました! 普段業務で扱わないメソッドも多く、「これは何だろう？」といったRuby自体への反応も生まれ、最後までRubyKaigiの空気を楽しめたのかなと思います。 出てくるRubyメソッドに一喜一憂 おわりに RubyKaigi、最高のイベントでした!改めて、Drinkupに参加してくださった方ありがとうございました! 来年もぜひ参加したいです!

• Ruby

freee·1日前

はてなブックマーク1

Coding Agentの時代: ソフトウェアエンジニアの未来

社内 IT の部署であるGYOMUハックでマネージャーをやっている kumataro です。私たちの取り組みから実感している次の時代のソフトウェアエンジニア像のひとつについて書いてみました。 2025年から2026年にかけて、Coding Agent が爆発的に進化しました。Claude Code や Codex、GitHub Copilot Agent など、コードを書くだけならAIが人間よりも高速かつ正確にこなせる時代が現実のものになりつつあります。 最近は、自分で1行もコードを書いていないという話も聞くようになってきました。 そんな環境ですので「AIに仕事を奪われるのではないか」という不安を抱いているソフトウェアエンジニアの方も多いのではないでしょうか。 「コードを書くことそのもの」に強いやりがいを感じているエンジニアにとっては、大きな変化に戸惑う側面もあるかもしれません。しかし「課題を解決すること」が目的であるエンジニアにとって、AI はこれ以上ない強力な武器です。私たちはこの変化を、エンジニアという職種がより本質的な価値へと回帰するチャンスだと捉えています。 Coding Agent 時代に陥りやすい罠 私たちは社内のバックオフィスの生産性を向上させるためのエンジニアチームです。Claude Code を用い、実装の速度が増したことにより、寄せられる要望に対応できる能力も高まっています。 同時に、ここには罠が存在することにも気づきました。それは、開発速度が増したことにより、寄せられた要望に素早く対応するだけの存在に陥ってしまいやすいということです。対応は感謝されるだけに、すぐに要望を実現したい気持ちはエンジニアにとっても、とても強いものです。 しかし、この先に待ち受けているのは、部門、業務ごとに個別最適化された処理やデータの乱立です。一見、業務は最適化されているように見えますが、全体的な視点では業務の重複による一貫性のなさや、データの散在が起こり、連携が困難な状況が急速に拡大するのが目に見えています。 実際に freee のバックオフィス内でも、従業員数の予測値について、労務と社内IT、財務の間でそれぞれの課題感から別々に算出している事例がありました。このような組織横断的な不整合の解決は個別の部署の業務改善では実現できません。 こうした「部分最適の罠」を回避し、AI を真の武器として活かすためには、単なる「対応力」を超えた、より戦略的なアプローチが不可欠です。そこで私たちが今改めて立ち返ったのが BPR と FDE というふたつのキーワードです。 道を切り開くふたつのキーワード、BPR と FDE BPR（Business Process Re-engineering）: 既存の業務プロセスをそのままシステム化するのではなく、プロセスそのものを根本から再設計すること。 FDE（Forward Deployed Engineer）: 本社のオフィスで仕様調整を待つのではなく、現場に入り込み、業務を観察し、課題を発見し、動くものを作って解決する「前線配備エンジニア」。 FDE は米国 Palantir 社などが先駆けて導入し有名になったポジションですが、これが「今の時代」に特にもてはやされているのには、明確な技術的・ビジネス的な背景があります。 freee でも社内のバックオフィスでは、ドッグフーディング的に自社プロダクトを利用しています。そういった環境での業務改善において、パッケージ化された SaaS をそのまま導入するだけでは解決できない企業固有の複雑な課題は残るのが現実です。 SaaS のデータと社内独自のデータの統合: 業務活動ではデータ分析の要求は常にあります。しかし、SaaS 内のデータと SaaS 外のデータを統合して扱うのは簡単なことではありません。また同じ元データのはずのものが部署毎の処理の中で異なる数字になって出てくることもあります。 スピード感: フィードバックは SaaS プロダクトに届けることができます。しかし、開発優先度の問題や SaaS としての全体最適化の中で、対応スピードは思うように上がりません。 個別最適化: SaaS という性質上、個社別の環境に最適化するわけには行かないため、個別の事情にピッタリマッチする改善はできないのが現実です。 こういった課題に対して、FDE は現場で活動している強みで、自ら解決策を提示し、導入、運用まで進めることができる役割となっています。 私たちのチームは社内における FDE として、業務をハックするエンジニアチームです。私たちが取り組んでいるのは、まさにこの FDE の動きを通じた BPR の実践です。 ミッションとバリュー では、ふたつのキーワードと陥りやすい罠を避けるために、どのようなマインドセットを持って業務に取り組めば良いと考えているのか紹介してみます。 私たちのミッションは「テクノロジーと対話を通じて、バックオフィスの生産性を最大化し、全従業員がより創造的な業務に集中できる環境を創り出す」ことです。このミッションを実現するために、以下の4つのバリューを大切にしています。 Why First（なぜ？から始める） 私たちは、表面的な要望の奥にある本質的な課題を探求することを常に最優先します。依頼された解決策をそのまま実装するのではなく「その業務はそもそも必要なのか？」「理想の状態は何か？」という問いから始めます。必要であれば「開発しない（業務自体をなくす）」という選択すら積極的に行います。 Be a Partner（最高のパートナーであれ） 私たちは、依頼者を「お客様」ではなく「課題解決のパートナー」と捉え、共に考え、共に成功を目指します。依頼者と対話し、業務のAs-Is/To-Beを描きながら、現場の泥臭い課題を共に解きほぐしていきます。 Impact Driven（インパクトで動く） 私たちは、取り組むべき改善を、そのインパクト（効果）の大きさによって判断します。 Go Simple（シンプルを追求する） 私たちは、複雑な問題を、誰もが使い続けられるシンプルで持続可能な解決策へと導きます。 私たちが目指すシステム全体像 こういった理想を実現するため、現場の課題に寄り添いながら、同時にそれを支える強固な技術基盤も並行して構築しています。現在、私たちが構築しているシステム全体のイメージ図を共有します。 開発中の基盤の全体像 Cadiz: OneLogin × AWS Cognito × Cerbosを組み合わせ、行・列レベルの認可制御を一元化した社内アプリ開発基盤。社内業務で用いる社員のセンシティブなデータも適切に守る。 Service Data Pipeline: AWS EKS 上で構築した自前のデータ連携基盤。複数の SaaS やデータソース間を柔軟に連携。 データ分析基盤: Google Cloud（BigQuery）/ Looker Cloud Core / Looker Studio Pro で構築したバックオフィスデータマネジメントを支えるデータ活用基盤。局所最適化された自動化でデータの分断が起こらないように一元化。 これらは単なるツールではなく、バックオフィスという複雑な領域を、他社にも誇れる「ショーケース」に変えるための重要なパーツです。これらの技術選定の裏側や、なぜその構成を選んだのかというトレードオフについても、また別の機会に詳しく共有していきたいと考えています。 まだまだ道半ば ここまで「FDE 的な動き」や「強固な基盤」について書いてきましたが、正直に言えば私たちはまだ、目的を成し遂げるための努力が必要な「発展途上」の段階です。 バックオフィスの現場には、未解決の複雑な業務フローや、解決すべきレガシーな仕組みが山ほど残っています。しかし、だからこそ面白い。 完成されたシステムを保守するのではなく、業務の現場に深く入り込み、技術の力で泥臭い課題を一つずつ解きほぐし、組織のあり方そのものを変えていく。この「変化のプロセス」こそが、私たちがエンジニアリングを通じて体験できる最大の醍醐味です。 これらの状況は、程度の差こそあれ、どのような会社にも存在するものではないでしょうか。 Coding Agent が強力になる中で、これからのエンジニアに必要なスキルセットは現場の深い理解（ドメイン知識）と、それを技術で最適化するアーキテクチャ設計能力の掛け合わせではないか、というのをひとつの答えとして提示してみました。 最後に GYOMUハックは、AIを武器に変え、バックオフィスの「前線」で挑戦を続ける仲間を募集しています。 「技術を使って組織を強くしたい」「コードを書く以上に、本質的な課題解決をしたい」と考えているエンジニアの方、ぜひ私たちと一緒にバックオフィスの新しいあり方を創りませんか？ hire.wantedly.com

• 生成AI
• アーキテクチャ
• AWS
• Google Cloud

freee·2026/06/09

はてなブックマーク1

TSKaigi 2026 に登壇者 & 運営スタッフとして参加してきました！

freee でエンジニア兼 Dev Branding をやっているけむりだま (@_kemuridama) です. TSKaigi では 2024 年の初回の開催から運営に参加し, 昨年からコアスタッフとして企画や運営にも携わっています. 2026/5/22-23 で東京の羽田で開催された TSKaigi 2026 で外部のカンファレンスへの初登壇を行ったので, 登壇者と運営の両輪で走り抜けた話を振り返っていこうかなと思います. TSKaigi 2026 に参加した freee のメンバー 登壇者として Day 1 に 「密結合なバックエンドから TypeScript のコードを生成する」 というタイトルで 10 分のセッションを行いました. speakerdeck.com 自分自身がエンジニアとして開発に携わっている freee会計で行っている Ruby のコードを元に TypeScript のコードを生成する取り組みについて話しました. リリースから 13 年が経っているプロダクトで密結合となっているバックエンドとフロントエンドにどうやって向きあっていくのか—— この話は実は 2024 年の Advent Calendar で書いた話 が元になっているのですが, なぜ freee会計では OpenAPI Schema などのスキーマ駆動開発ではなくバックエンドのコードを SSoT (Single Source of Truth) としてコードの生成を行っているのかという点について深堀って話すことができたんじゃないかなと思います. 今後も freee会計の開発生産性や品質の向上に向けて対象範囲を広げていければ良いなと思っています. セッションの最後で話した Sorbet の型アノテーションから TypeScript の型を生成する取り組みも絶賛検証を行っています. 発表後に X を眺めると「Node.js から Ruby の Parser (WebAssmbly) を呼ぶのは面白い」「密結合は決して悪ではない」といった反応がもらえて登壇してよかったなと思いました. 背中を押してくれた (?) 同じコアスタッフの yuta-ike には感謝してますｗ 運営スタッフとして TSKaigi ではスポンサーチームとして TSKaigi 2026 のスポンサープランの検討からスポンサー集め, スポンサーベネフィットの履行に向けたタスクなどを行っていました. 今年もありがたいことにたくさんのスポンサーの応募があり, 希望に添えないところがたくさんあり心苦しかったです. 実は freee もゴールドスポンサーとして応募をしていたのですが, 厳正な抽選に外れてしまってブロンズスポンサーとしての協賛となってしまいました. 登壇があったのでドキドキしていたんですが, 当日はいろいろな運営タスクに忙殺されていたので良い意味で登壇の緊張を和らげることができました. 昨年開催された TSKaigi Hokuriku 2025 に続き Day 2 の懇親会の冒頭挨拶もさせてもらっていい経験ができました. 2 日間フルで動きっぱなしだったので流石に疲れましたが, 無事に大盛況で TSKaigi 2026 を終えることができてよかったです. セッションをほとんど見られなかったので, 後日ゆっくりアーカイブで気になっていた発表をチェックしたいなと思っています. 最後に TSKaigi 2026 に参加してくれた方, 自分のセッションを見に来てくれた方, スポンサーをしてくれた企業の方々ありがとうございました. 次は 2026/11/1 に仙台で TSKaigi Sendai 2026 が予定されています. 開催に向けて引き続き企画や運営を頑張っていきたいと思いますので, また会場でお会いしましょう! 本日 19:00 から TSKaigi 2026 でスポンサーをした freee と M3 でアフターイベントを開催します. 直前のお知らせですが, ご都合が合う方は是非ご参加ください! freee の大崎本社での現地参加と YouTube Live でのオンライン参加の両方が可能です! freee.connpass.com

• TypeScript
• Ruby
• Rails

freee·2026/06/01

はてなブックマーク0

Laravel Live Japan に参加してきました！

こんにちは！フリーナンスのエンジニアをやっているthe よしだです！ 今回は2026年5月26日(火)・27日(水)に立川ステージガーデンで開催された Laravel Live Japan についてお話したいと思います！ Laravel は PHP の人気フレームワークの一つで、Ruby における Ruby on Rails のような立ち位置になりますが、日本で Laravel を題材にしたカンファレンスは、2019年に開催された Laravel JP Conference が最後となり、7年間開催されていませんでした。 今回、Laravel コアチームエンジニアである Ryuta Hamasaki さんのご尽力により開催され、海外からも多数の PHPer の方が来日されました！ 登壇者の多くは英語で話していましたが、日英同時通訳システムにより内容は即座に理解できるようになっていました。 Ask The Speaker においても同時翻訳システムがあるおかげで、かなり込み入った内容の質問でも日本語・英語でコミュニケーションが取れる状態です！ 余談ですが、 PHPerという言葉は海外では馴染みがない場合があるため、シンプルに『Do you use PHP?』と聞くのがスムーズでした！ 印象に残ったトーク Strict AI Engineering 大人気PHPテスティングフレームワーク Pest の作者であり、Laravel コアチームエンジニアの Nuno Maduro さんは、AI時代のコーディングにおけるガードレールとして下記の4つを主張していました。 より厳格なデフォルト設定の利用 型と静的解析ツールの導入 コーディングパターンの一貫性 強力なテストパイプラインの構築 特にコーディングパターンの一貫性では、AIがコードを生成する前に、プロジェクト内でどのようなコーディング規約やパターンが使われているかを読み取って理解しようとする点を指摘していました。 だからこそ、品質を保つためには、一貫したコーディングスタイルを維持することが大切です。 Keynote: Laravel Updates 我らが Laravel 生みの親である、Taylor Otwell さんによる Laravel の最新情報です。 Laravel Boost Laravel Boost は 今年リリースされた、AIコーディング支援ツールです。 プロジェクトを解析し、エージェント用指示書の自動生成を行えます。 また、Laravel 13 への自動アップグレードをAIを使って行うことができるようになります！！！ Laravel AI SDK 様々なAIプロバイダーをシームレスにLaravelに統合できる公式SDKです。 Laravel AI SDK を使うことで、OpenAIからAnthropicへの切替に伴うコード変更を最小限にできます。 それだけでなく、OpenAIが繋がらないときにAnthropicといった切替も可能です！ また、エージェントクラスを作成することで、Laravelの流儀に近い形で指示出し、結果取得を行えるところも熱いポイントです！！ Laravel Cloud Laravel で作成した Web アプリを簡単に外部公開できる Laravel Cloud ですが、ついに待望の東京リージョンでのデプロイが可能になりました！ また、ワーカーのスケーリングやキュー監視機能も追加されています！ Laravel and the Future of Native Apps デスクトップアプリを PHP で作れる、Native PHP の創設者 Simon Hamp さんと Shane Rosenthal さんによる革新的な発表です。 Native PHP が今ではモバイルアプリまで作ることができますが、WebViewベースでした。 しかし今回、ネイティブウィジェット（AndroidのJetpack ComposeやiOSのSwift UI）を直接操作する「Super Native」を開発しました！ 特徴的な点として、C言語で書かれたPHP拡張機能を通じてUIの構成を直接バイナリコードに変換しています。これをOSと共有するメモリ領域に書き込むことで、PHPとネイティブUI間のやり取りをほぼゼロレイテンシで実現しています！ また、HTMLではなく、専用のBladeコンポーネントでUIを構築していく点や、Tailwind風のクラス指定をすることで、ネイティブのカラーコードに自動変換される点も面白いポイントになります！ What's Next for PHP | The PHP Foundation The PHP Foundation の設立者、 Roman Pronskiy さんが PHPコアの開発状況と、今後の展望について語ってくれました。 その中で、いくつか最近の機能が紹介されましたが、日本の開発者 Saki Takamachi さんが開発に貢献したBCMathのオブジェクトAPIが本人のビデオレター付きで紹介された点は見逃せません。 Polling API ついに PHP に 非同期処理がやってきます。ストリームの刷新と Polling APIの実装を今後予定しているとのことです！ Closure optimizations 外部スコープの変数を持たないクロージャをキャッシュする最適化が入り、これによりLaravelアプリが無料で4%高速化すると発表されました！ PHPをバージョンアップするだけで4%の高速化です！ Generics 待望の Generics についてRFCで議論の真っ最中とのことです！ Generics のないPHPでは下記のように、配列などに様々な型のものを含めることができてしまいます。 $users = []; $users[] = new User(); $users[] = "文字列"; // 何でも入ってしまう しかし、Generics が導入されることで、下記のように安全なコードを書くことができます！ // <T> の部分にあとから好きな型を指定できる class Collection<T> { private array $items = []; public function add(T $item) { $this->items[] = $item; } } $userCollection = new Collection<User>(); $userCollection->add(new User()); // OK $userCollection->add("文字列"); // エラー（実行前や実行時に弾ける！） 続報が楽しみです！！ その他 専門チームによる正式なセキュリティ監査を実施し、複数の脆弱性を修正したことが報告されました。 有給コア開発者が稼働しており、コミュニティからのコントリビューションも右肩上がりで増加しています。 コミュニケーションのハブとしてのカンファレンス Kaigi on Rails のオーガナイザーの 大倉 雅史 さんによるライトニングトークでは、AI時代においても良い開発者になる必要があるということを、お話されていました。 トークの流れとしては下記の通りです。 良い開発者になること 成長するためにはコミュニケーションが重要 Hallway tracks（廊下での会話）の重要性 自身が有名かは気にする必要がない 人との繋がりを大切にする姿勢は素晴らしく、技術のインプットを得るだけでなく、カンファレンスという場に直接足を運んで予期せぬ出会いや会話を楽しむことの意義を強く再認識させてくれるセッションでした。 Kaigi on Rails のオーガナイザーが、世界中から開発者が集まる Laravel のイベントでこの普遍的なメッセージを発信してくれた事実が、何よりも嬉しく、胸が熱くなりました。 終わりに 今回は、かなりグローバルなPHPカンファレンスでした！ 言語の壁はありますが、同じ言語を使い、同じフレームワークを使っているというだけで、たどたどしい英語でも盛り上がることができました！ ぜひ、皆さんも色々なカンファレンスに参加してみてはいかがでしょうか！

• PHP
• Laravel

freee·2026/05/21

はてなブックマーク72

Claude Enterprise を全社に安全に展開するために、SCIM × IaC で権限運用を整備した話

こんにちは！最近 デスクセットアップ が趣味である freee AI Platform Engineering チームの JaeSoon です。 ゴールデンウィークに合わせて、リビングと作業部屋のレイアウトをまるごと組み直しました。 あれこれ動かしているうちに気づけば連休が終わっていましたが、毎日座る場所だけに作業のコンディションが目に見えて変わって、満足しています 🪑✨ 新しく整えたデスク/部屋全景 私がもともと所属していた「AI駆動開発（AI-Driven Development）チーム」 は、社内のプロダクト開発組織における AI 活用を定着させる仕事をしてきました。 その結果、freee の開発組織では すでに 97% のエンジニア（残りの 3%は経営陣もしくは EM なので、ほぼ全エンジニア）が AI コーディングエージェントを日常的に使っている 状態に到達し、次の課題は自然と この成功をエンジニア組織の中だけに閉じず、Sales / CS / 企画 / 管理部門など全社へ広げること に移っていきました。 それに合わせてチーム名も AI Platform Engineering チーム へと変わりました。今や単なるAI駆動開発領域、便利 Coding Agent ツールの導入にとどまらず、業務フロー自体をAIで再定義できる技術基盤の構築へと活動領域が広がっています。 なお、freee では Claude Enterprise の全社展開にあたり、複数のレイヤーで安全性を担保する取り組みを並行して進めています。たとえば: Jamf を活用して各設定をエンジニア・非エンジニア双方への端末配布 managed-settings.json による Claude Code の挙動制御 (危険な操作の Deny) OpenTelemetry で Claude Cowork, Code Log を収集し SIEM に転送してモニタリング Claude を安全に使うための社内ガイドライン・オンボーディング整備 といった対応を組み合わせています。これらについては追って別途公開予定ですが、本記事ではその中でも「SCIM × IaC による権限設計と運用」 に絞って詳しく解説します。メインはあくまで 権限設計と IaC 運用 で、Usage Controls はその上にもう一枚かぶせた補助装置という位置づけです。 freee が AI ツールを社内に入れて運用してきたストーリーは下記の記事にまとまっていますので、合わせてご覧ください。 数字で振り返る freee の AI 駆動開発 - 後編 - freee Developers Hub AI駆動開発へ。freee は開発環境をどう進化させているか？- 前編 - freee Developers Hub AIエージェントCline、freeeはどうやって全社導入した？ - freee Developers Hub 本記事に頻出する OneLogin (freee が社内標準 IdP として使用している製品) × Terraform ベースの権限管理基盤は、freee 社内ですでに整備済みのものであり、それ自体については下記の記事にまとめられています developers.freee.co.jp 本記事で扱う Claude Enterprise の SCIM 連携も、この基盤の上に乗っかる形になっています。OneLogin 以外の IdP 環境であっても、本記事の設計パターン自体はほぼそのまま通用するはずです。 はじめに: Enterprise 契約後に向き合った 4 つの問い エンタープライズ契約を結んでシートを発行した瞬間がゴールではなく、そこからが本当のスタートでした。運用に乗せてみると、「みんなが安心して触れる状態」 を維持するために、もう一枚レイヤーを足す必要が出てきます。具体的には次の 4 つの問いです。 誰が どこまで 触れるか (管理者権限・課金変更・SCIM 設定など) どの利用フレーム で渡すか (例: Claude Code を ON にするか OFF にするか、ヘビーユーザー / 一般 / 検証フレーム) 暴走を防ぐための 予算ガードレール をどこにどう敷くか 上記すべてを IaC で再現可能 な形にできるか (人間の SaaS コンソールクリックに依存しない) この 4 つに正面から向き合うために整備したのが、本記事のメイントピックである SCIM × Custom Role による権限設計と、その IaC 運用 です。Spend Controls はその上に補助的に一枚かぶせたガードレールという位置づけで、本記事の最後で軽く触れます。 📝 補足: 本記事で扱う SCIM 連携 / Group mappings / Custom Roles / Spend controls はいずれも Claude の Enterprise プラン で提供される機能です (Team プランでは利用不可、または制限あり)。ご利用前に Anthropic 公式の Enterprise プラン案内 で最新の対応範囲をご確認いただくのがおすすめです。 整備の前提: Claude Enterprise が提供してくれるもの Enterprise プランで使える「権限まわり」の機能を、freee 運用の観点で整理するとこうなります。 機能 できること freee での活用先 SSO / SCIM directory sync OneLogin (社内 IdP) をマスターに据え、ユーザー / グループ情報を同期 既存の OneLogin ベースに権限管理を一元化 Group mappings OneLogin 側のグループ名を Claude 側 Role に自動マッピング 「グループに入れる = ロールが付く」を IaC で再現 Custom Roles 既定の Owner / Admin / User とは別に 細分化された権限プロファイル を作れる 「Claude Code を使ってよい / ダメ」「default / ai-sandbox」などの利用フレームをグループで指定し、それに合わせたロールで表現 Spend controls 組織全体・ロール単位で予算ガードレールを設定 暴走時の保険、検証フレームの予算分離 Usage analytics ユーザー / Role 単位の利用状況の可視化 「利用フレームの見直し」「sandbox の効果計測」のインプット Audit logs 重要操作の監査証跡 コンプライアンス・インシデント対応用 このツールセットの上で、設計の決めとして置いたのはシンプルです — OneLogin を唯一の source of truth とし、Claude 側の状態はそこから同期されるアウトプットとしてのみ扱う。コンソールから直接手を入れるオペレーションは、できるかぎり作らないようにしました。 User ロールではなく Custom Roles を使う Claude Enterprise の Group mappings 設定画面では、OneLogin 側のグループ名を次の 4 種のいずれかにマッピングできます。 Owner … 最上位の管理権限 (SCIM 設定・課金変更など) Admin … 組織管理権限 User … 一般ユーザー (= デフォルトのまま渡す) Custom roles … 自前で定義したロール SCIM directory sync 設定パネル — Connected, group mappings ON, User 行が空欄の状態, Custom roles に 6 グループ 一見すると「全員に Claude Code を渡したいなら User に紐づければいいのでは?」と感じますが、f

• IaC
• Terraform
• OneLogin
• SaaS

freee·2026/04/30

はてなブックマーク26

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/28

はてなブックマーク2

スクリーンリーダーに触れてみるワークショップを「freee 技術の日 2025」で開催しました

デザイナーだったりコードを書いていたりアクセシビリティまわりのことをやっていたりする id:ymrl です。すっかり半年も前になってしまいましたが、昨年11月30日に開催した「freee 技術の日 2025」で、スクリーンリーダーに触れてみる「アクセシビリティワークショップ」を開催しました。その紹介をしたいと思います。 なぜアクセシビリティワークショップをやるのか アクセシビリティというのは、「製品やサービスにアクセスできる利用状況の度合い」というふうに表現されます。障害のある人や高齢の人、何らかの不便や不自由がある人でも、なるべく問題なくアクセスできる製品やサービスであることは、freeeの目指す「だれもが自由に経営できる統合型経営プラットフォーム」に必要不可欠なものです。そのためにfreeeは「freeeアクセシビリティー・ガイドライン」の策定をはじめ、いろいろな形でアクセシビリティを高めるための取り組みをしてきました。 開発者としての私たちは、自分たちと同じようなユーザーが、同じような状況で製品やサービスを使ういう前提を無意識のうちに置いてしまいがちです。しかし実際には、多くの人に使ってもらえば様々なユーザーが様々な状況で利用することになります。そのなかには障害者や高齢者をはじめとして、利用に困難を感じることの多い人もいます。しかし、なかなか私たちはそういった人や状況を想像することができません。 そこで、PCやスマートフォンに搭載されている、スクリーンリーダーという音声読み上げ機能を使う体験をしてみよう！というのがこのワークショップです。freeeには全盲の視覚障害者として、スクリーンリーダーを使ってPCを操作して仕事をしているエンジニアがいます。スクリーンリーダーで実際にPCやスマートフォンの操作をすることで、音声を頼りに操作できる意外さや、その一方で操作が難しい場所もあることを体験してもらうことがワークショップの目的でした。 ワークショップは会議室で、テーブルを囲むかたちで開催しました ワークショップの内容 今回のワークショップでは、事前の準備なしで、1時間でできるようにということで「参加者のスマートフォンで、スクリーリーダーでWebページを見てもらう」という内容にしました。PCのスクリーンリーダーのほうが機能が多く、特にWebについては私が詳しいのもあって内容の濃いものにできるはずなのです。しかし、スクリーンリーダーによって操作方法が大きく異なり、そもそもキーボードでの操作をたくさん覚えるのが大変ということもあって、PCよりは覚えることの少ないスマートフォンで体験してもらうことにしました。普段使っている普通のスマートフォンで実はスクリーンリーダーが動くというところにも面白さを感じられるものでもあろう思います。そして、ここからアクセシビリティに興味をもつ開発者が1人でも増えてくれると嬉しく思います。 ワークショップの進行・講師は私が担当しつつ、全盲のエンジニアのkennyさんに実際のユーザーがどんなふうに使うのかを聞いたりしながら進めました（本当はもう一人、catさんにも来てもらう予定でしたが、残念ながら体調の都合で参加できずでした……）。参加者のフォローにはshunitoさんに協力してもらいました。 kennyさん shunitoさん iOSにはVoiceOver、AndroidにはTalkBackという、それぞれ別のスクリーンリーダーが搭載されています。これらも操作方法はだいぶ違うのですが、基本的な機能は非常に似ています。ワークショップでは、この2つのスクリーンリーダーで同じことをそれぞれひとつずつやる、という流れで行いました。みんなが同時にスクリーンリーダーを操作しはじめると大変なことになるので、参加者にはイヤホンを持ってきてもらいました。 講師としてはデモ用に、普段会社で検証用に使っているiPhoneとAndroidのスマートフォンを一台ずつ用意して、それらはBluetoothスピーカーに接続して参加者に音声を聞いてもらいやすくしておきました。さらに私は普段使っているiPhoneとAndroidを一台ずつ持ち込み、手元に4台のスマートフォンがある、という状態になっていました。 スクリーンリーダーの起動・終了の設定 スクリーンリーダーを実際に起動する前に、簡単に起動と終了ができるようにしておきます。 iOS VoiceOver 「設定」の「アクセシビリティ」→「ショートカット」を開く 「VoiceOver」にチェックを入れる こうすることで、サイドボタンまたはホームボタンのトリプルクリックでVoiceOverが起動するようになります。「ショートカット」に指定されているものが複数あるとダイアログで選ぶようになるので、VoiceOverの操作に慣れないうちは1つにしておくのが良いでしょう。 Android TalkBack 「設定」の「ユーザー補助」→「TalkBack」を開く 「TalkBackショートカット」をON 「音量ボタン」になっていない場合は、「TalkBackショートカット」をタップしてチェック これで、音量ボタンの+と-を同時に長押しでTalkBackの起動・終了ができるようになります。 スクリーンリーダーの読み上げ内容を見られるようにする スクリーンリーダーは、ときどき不思議な読み方をすることがあります。目が見えている人は「何言ってるんだ？」と思ったときに確認できるように、読み上げている内容を見えるようにしておくと良いです。 iOS VoiceOver 「設定」→「アクセシビリティ」→「VoiceOver」を開く 「キャプションパネル」をON Android TalkBack 「設定」→「ユーザー補助」→「TalkBack」→「設定」の画面を開く 「TalkBackをOFFにする手順を表示」をOFF 「詳細設定」→「デベロッパー向けの設定」で「音声出力の表示」をON デフォルトでは、TalkBackが起動しているとき、画面の中央付近に「TalkBackをOFFにする手順」のテキストが表示されます。ふだん視覚に頼って操作している人にとっては非常に邪魔なものであるはずなので非表示にしています。 スクリーンリーダーの起動 ここまで設定して、いよいよ起動です。 iOSの人は、サイドボタンまたはホームボタンのトリプルクリック Androidの人は、音量ボタンの+と-を同時に長押し で、スクリーンリーダーが起動してスマートフォンが喋りだします。ここでスクリーンリーダーの起動と終了を3回くらい繰り返して、「スクリーンリーダーの操作方法がわからなくなっても終了すればいいんだ」というマインドになっておくのが良いです（ワークショップでもそのための時間を取りました）。 スクリーンリーダーで、Webを読んでみる 基本的な操作は、iOSのVoiceOverもAndroidのTalkBackも似ています。 タップ: カーソルの位置をタップした位置に移動する ダブルタップ: カーソルの位置にあるものをタップ 右にフリック: カーソルの位置をひとつ進める 左にフリック: カーソルの位置をひとつ戻す 上下にフリック: スクリーンリーダーの設定に応じた操作 iOSでは2本指で「ねじる」ジェスチャーで設定を変更 Androidでは3本指で上下左右いずれかへのスワイプで設定を変更 ジェスチャーを覚えるのはなかなか大変なので、チートシートを用意しておくのが良いでしょう。ワークショップでは、私が以前作ったチートシート をfreee風の色にしたものを印刷して参加者に配布しました。 iOS VoiceOver / Android TalkBackチートシート（freee風味） まずは、左右のフリックでWebページを読んでみる練習をしました。Webページを開くところまではスクリーンリーダーはオフで、ページが表示されてから、スクリーンリーダーを起動して、音声を聞きながら画面の適当なところをタップして、そこから右へのフリックで読んでいきます。 画面をタップするとその場所に配置されているものが読み上げられるので、それを頼りに読んで回ることもできますが、最初から順番にページの内容を読んでいくには右方向のフリックを繰り返していくことになります。フリックによって、スクリーンリーダーのカーソルが移動していき、その部分にあるものが読み上げられます。画面の上では、スクリーンリーダーのカーソルの枠線が表示されるので、視覚的に挙動を確認できます（もちろん、スクリーンリーダーのユーザーがこれを見えているとは限りません。見えてないことのほうが多いでしょう）。 ワークショップでは、freeeでの研修に使用しているfreee Accessibility Trainingというページを使用しました。スクリーンリーダーをオフにして、スライドに表示したQRコードからページを開き、スクリーンリーダーをオンにして、「画像」のページへのリンクを探してみます。 見出しジャンプ機能を使う ページの内容を全部読み上げてそれを聞いていくのは大変なので、ショートカットがしたいものです。そういうときにはPC向けのスクリーンリーダーにも存在する機能である「見出しジャンプ」を利用できます。 見出しジャンプをするためには、上下方向のフリックを使用します。ただし、上下方向のフリックによって何が起きるかは、別のジェスチャーによって切り替える必要があります。 iOSでは2本指で「ねじる」ジェスチャー Androidでは3本指で上下左右いずれかへのスワイプ iOSのジェスチャーはわかりづらいですが、画面に親指と人差し指をのせ、画面の上にある「つまみ」を回すような感覚です（それらしきグラフィックが表示されます）。Androidは三本指であれば縦でも横でも切り替えができます。このジェスチャーを何度か繰り返し、「見出し」と言ったところで下にスワイプすると、スクリーンリーダーのカーソルの位置よりも後ろにある見出し要素にジャンプすることができます。 「画像」ページにはいろいろなサンプルがあり、それぞれに見出しがついています。Wikipediaもたくさん見出しのあるページが多く、「アンパンマンの登場人物一覧」のページは社内でよくデモに使っています。 画像を読んでみる 「画像」ページのサンプルには、「良い例」「悪い例」があり、alt 属性が無かったり、間違っていたりする状態でスクリーンリーダーがどんな動きをするのかを体験することができます。 alt 属性のない画像は、「画像」や「イメージ」と読まれるだけで、その内容はわからなくなってしまいます。また、alt 属性が間違っている画像も、画面を見ずにスクリーンリーダーを使っていると、その間違いに気付くことができません。 kennyさんは、画像の内容が知りたいときにAIを使って説明を取得したりもするらしく、その実演も行われました。 スクリーンリーダーでチャレンジ！ ここからはチャレンジで、スクリーンリーダーでできそうでできないお題をやってもらいました。 アプリを切り替えてみよう ホーム画面に移動してみよう 自分の関わっているWebサイトやアプリを操作してみよう 文字入力に挑戦してみよう カメラで写真を撮ってみよう ChatGPTやGeminiを使って、画像を解析させてみよう X (Twitter) に投稿してみよう 参加者のなかには、個人で開発しているWebサービスを試している人もいました。講師側にもその画面を見せてもらいながら機能をアクセシブルに実現する方法の議論でも盛り上がりました。どうかここが、アクセシビリティの高いアプリやサービスが世に出ていくキッカケになっていたら嬉しく思います。

• アクセシビリティ
• UI
• UX

freee·2026/04/27

はてなブックマーク34

大規模Railsアプリを支える「バックエンド委員会」とRuby YJIT導入によるパフォーマンス改善

こんにちは！フリー株式会社でエンジニアをしているyassyとkenzaです。 2026年1月30日に開催された「freee Tech Night」にて、「freee会計の大規模開発を支える "バックエンド委員会"」というテーマで登壇しました。 www.youtube.com freeeの基幹プロダクトである「freee会計」は、リリースから14年が経過した国内でも有数の大規模Ruby on Railsアプリケーションです。本記事では、この巨大なプロダクトをいかにして健全に保ち、進化させ続けているのか、その中核を担う「バックエンド委員会」の活動と、直近で取り組んだYJIT導入の詳細について解説します。 1. 巨大なモノリスと14年の歴史：freee会計の現状 freee会計のバックエンドは、2012年7月の最初のコミットから今日まで、膨大な機能追加と修正を繰り返してきました。そのため、以下のような課題があります。 開発規模: 毎週1,000以上のコミットが積み重なり、非常に多くのチームとエンジニアが同時に開発に関わっています。 複雑なドメイン構造: 長年の開発により、会計のコアロジックと周辺の業務ドメインが密結合しており、システム全体が巨大なモノリスとなっています。 技術負債の蓄積: 14年前のベストプラクティスが、現代のエンジニアリングにおいては逆に負債となってしまうケースも少なくありません。 2. 横断組織「バックエンド委員会」の役割 こうした技術的課題に対し、組織横断で改善を推進しているのが「バックエンド委員会」です。 委員会の2つのミッション 開発生産性の向上: 開発者が複雑な環境に惑わされず、素早く価値を届けられる状態を作る。 保守性・品質の向上: 10年後もメンテナンス可能なコードベースを維持し、障害に強い基盤を作る。 多様なメンバーによる草の根活動 この委員会の特徴は、参加の敷居が極めて低いことです。Rubyやバックエンドの知識に精通したエキスパートだけでなく、配属直後の新卒エンジニアも積極的に参加しています。 実際に、筆者の一人であるkenzaは、配属時にRuby未経験でしたが、Ruby歴3ヶ月の状態で委員会に参加しました。 普段は別々のチームでプロダクト開発をしているメンバーが集まり、組織横断的に兼務で改善タスクをこなしています。 3. 生産性と品質を高めるための具体的な取り組み バックエンド委員会が行ってきた主な取り組みを紹介します。 コードの治安維持：フォーマッタ/リンター(Syntax Tree, RuboCop) の整備 コードの品質を一律に保ち、実装やコードレビューでの負荷を最小限にするために導入しています。 メリット: 開発者は本質的なロジックの開発に集中でき、レビューに対するコストが大幅に下がりました。 課題: 導入時に作成した「rubocop_todo（後回しにしたルール）」が肥大化している点です。これを委員会で計画的に解消する仕組み作りを進めています。 型の導入：静的型チェッカー(Sorbet) / 型定義生成ツール(Tapioca) の普及 Rubyのような動的型付け言語において、大規模開発の安全性をもたらすのが静的型チェッカーのSorbetです。 取り組み: GitHub Actionsやテスト実行時のランタイムで型チェックを自動化。 効果: 型定義ファイル（RBI）の差分チェックにより、予期せぬ実行時エラーを未然に防げるようになりました。また、入出力の型が明確になることで可読性が向上しました。 開発サイクルの高速化：CI（継続的インテグレーション）の改善 1,000件/週のコミットを捌くためには、CIの高速化が命題です。 具体策: RuboCopを実行する際に変更差分のみを対象にしたり、テストデータのシード値をキャッシュ化するなどの工夫をしています。 地道な修正: 時折失敗するflakyなテストの撲滅や、実行時間の長いRSpecのチューニングを継続的に行っています。 4. Ruby YJIT 有効化によるパフォーマンス改善 今回のメイントピックが、Ruby 3.1から搭載されたJITコンパイル機能「YJIT (Yet another Ruby JIT)」の導入です。 YJIT導入の動機 大規模アプリケーションにおいて、ロジックの改善だけでパフォーマンスを劇的に上げるには限界があります。YJITは、実行時にRubyコードをマシンコードへ変換・キャッシュすることで、アプリケーション側のコード変更なしに速度向上を狙える、コストパフォーマンスの高い手法です。大規模でパフォーマンス改修が困難なfreee会計では一定の効果が見込めそうだったので、導入に至りました。 事前調査とリソース計画 YJITはメモリを多く消費することが分かっていたので、以下の観点で調査を進めました。 リソース見積もり: KubernetesのPod単位で、YJITで消費する分上乗せされるメモリリミットやワーカー数を試算しました。 OOMKilled対策: YJITが生成するコードのサイズやメタデータによるメモリ増加分を見積もり、Podのメモリ制限をあらかじめ調整しました。 検証からプロダクション導入まで staging環境での負荷テスト: HPA（自動スケーリング）をあえて停止し、試験環境に一定の負荷をかけて集中的にメトリクスを計測しました。 独自メトリクスの監視: code_region_size（生成コードサイズ）や ratio_in_yjit（YJIT実行率）をロギングし、期待通り動作しているか確認しました。 手動カナリアリリース: 本番環境では、いきなり全台に適用するのではなく、一部のPodから段階的に反映しました。異常がないことを確認しながら展開し、万が一の際のロールバック体制の整備も行いました。 導入成果 レスポンスタイム: APIにおいて、平均・中央値で約15%もの高速化を確認。さらに、遅いリクエスト（P90〜P99）でも約13%改善しました。 YJIT導入後のレスポンスタイム CPU使用率: 全体で約20%低下。以下のようにCPU使用率が大幅に減り、リソース効率が向上しました。 YJIT導入後のCPU使用率 メモリ増: 想定通りメモリ消費は増えましたが、リソース計画の範囲内であり、安定稼働を続けています。 YJIT導入後のメモリ使用率 5. 今後の展望：ZJITへの備えとAIの活用 次世代JIT「ZJIT」を見据えた設計 Ruby 4.0から導入されたZJITは、メソッド単位でのコンパイル方式に移行します。現在はまだYJITの方が高速ですが、将来的に採用していく可能性があります。 型の安定性: ZJITを最大限活かすには、実行時に型が変動しない設計が重要です。Sorbetなどを活用することで型安全なコードを書くことが、将来のさらなる高速化にも繋がると考えています。 AIによる負債解消の自動化 今後は、AI（LLM）を活用して技術負債を自動で検出し、優先順位付けを行う仕組みを構想しています。 調査や定型業務のSkills化: 修正案をAIが提示し、委員会がそれを承認してデプロイするような、AIがオーナーシップを持つ効率的なメンテナンス体制を目指します。 CLAUDE.mdの整備: AIでコーディングを行った際に、自動でフォーマットや型をチェックしてテストを実行する仕組みを整備しています。 おわりに freee会計のような巨大なプロダクトにおいて、技術基盤を健全に保つのは簡単なことではありません。しかし、バックエンド委員会のように、メンバーが自発的に「自分たちの環境を良くしよう」と動く文化こそが、freeeのエンジニアリングの強みです！

• Rails
• Ruby
• パフォーマンス
• CI
• SRE

freee·2026/04/22

はてなブックマーク0

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/21

はてなブックマーク0

要求から体験への変換を、AIが検証する時代のデザインシステム

はじめに 現在freeeでAIフィジビリティ検証基盤のPdMをしています。Jです。もともとはフロントエンドエンジニア、デザインエンジニア、プロダクトデザイナーとキャリアを渡り歩いてきました。 どの職種にいても感じていたのは、要求が画面になり体験になるまでの変換のたびにロスが発生する、という問題です。デザイナーがFigmaで描いた画面をエンジニアが実装すると、見た目のズレで差し戻しが入る。デザインシステムのコンポーネントが標準化されても、画面全体の組み立て方（どのパターンを使い、要素をどう配置し、状態遷移をどう設計するか）は各チームの解釈に委ねられていた。コンポーネントが揃っていても、組み合わせ方の解釈が食い違えば「意図と違う」は起き続けます。 2023年頃には、この断絶の橋渡し役として「デザインエンジニア」が業界で注目されましたが、橋渡しを人に求める限りスケールしません。この変換を、人ではなく仕組みで担保する必要がありました。しかし当時、その仕組みは存在しなかった。AIコーディングエージェントの登場が、このパラダイムを変えることになります。 この記事では、freeeのデザインシステムの変遷と、この変換の検証をAIが担うに至るまでの過程を整理します。 要求、UI設計、実装、体験 要求が画面になり、ユーザーの体験になるまでには、3つの変換を経て4つの層を通ります。 要求: 機能要求やユースケース。何を実現するか、誰がどう使うか。 UI設計: 要求を画面構成に落とし込む。どの画面パターンを使い、どの要素をどう配置するか。 実装（この記事ではフロントエンド実装に焦点を当てる）: 状態管理や異常系を考慮し、UI設計をコードに具現化する。 体験: 実装されたUIを通してユーザーに届くもの。操作感、情報の見通し、業務の流れやすさ。 デザインシステムはUI設計と実装に使われる制約を定義します。freeeでは、その制約を通して届けたい体験を「デザインプリンシプル」として定義しています。 デザインプリンシプルとは、プロダクトの見た目や使い勝手を設計する際の「判断基準」となる基本方針（原則）のことです。プロダクト全体の体験に一貫性を持たせつつ、素早く質の高いデザイン判断を行うための土台として機能します。 プリンシプルは、UI設計の判断基準であると同時に、実装されたUIを通して届く体験の質を測る基準でもあります。 フィジビリティ検証とは、今の要求をデザインシステムの制約を通してUI設計・実装したとき、どのような体験になるかを確認すること。制約の中で設計・実装できるかだけでなく、その結果がプリンシプルの目指す体験に到達できるかまでを含みます。 ここまでの前段：freeeのデザインシステムが辿ってきた2つの試行 freeeのデザインシステムがどのような試行を経てきたかを整理します。 freeeがこれまで辿ってきた2つの試行。部品レベルの標準化から画面パターンレベルの標準化へと、制約の粒度が拡張されてきた。 第1の試行：UIの部品を標準化する（vibes） freeeでは2018年からデザインシステム「vibes」を開発・運用してきました。ボタン、テキストフィールド、テーブルといったAtomsやMoleculesレベルのコンポーネントを共通化し、アクセシビリティを含む品質を標準化しました。 vibesの導入で、部品レベルの見た目と品質は統一されました。しかし、規模が拡大し開発チームが増えていく中で、制約の粒度が足りないことが見えてきました。個々のコンポーネントは揃っていても、要求からUI設計への変換は各チームの裁量に委ねられていました。同じような要求に対しても、アプリケーションによってUI設計が異なり、実装もバラバラになり、ユーザーに届く体験が一貫しなくなっていました。 部品の制約だけでは、要求→UI設計→実装→体験の一貫性は保てませんでした。 第2の試行：プリンシプルを画面パターンに翻訳する（標準UI） 個々の部品ではなく、要求をUI設計に変換するパターンそのものを標準化する。これが第2の試行の答えでした。 freeeではまず、UIを通して届けるべき体験を「デザインプリンシプル」として策定しました。そしてこのプリンシプルを体現する画面パターンとして、高機能UIライブラリ「標準UI」の開発を進めました。この取り組みについては「デザインシステムを拡張し、プロダクト開発の共通基盤を目指す」で詳しく紹介しています。 標準UIは、vibesのコンポーネントを内部的に使用しつつ、業務システムで基本となる3つのパターン（一覧・詳細・作成/編集）を、少数のコンポーネントを組み合わせるだけで作成できるようにしました。UI設計だけでなく、状態管理やAPI連携、エラーハンドリングといった実装ロジックも標準化の対象とし、プリンシプルが目指す体験をUI設計と実装の両面から担保できる状態を目指しました。 この試行の本質は、プリンシプル（目指す体験）を、画面パターン（UI設計と実装の制約）に翻訳したことです。 制約は成熟した。使いこなすためのハードルが残った 第2の試行で制約は成熟し、今も成長を続けています。標準UIの画面パターンのおかげで、要求→UI設計→実装の変換における組み合わせ方のばらつきは大幅に減りました。しかし、2つのハードルが残っていました。 制約を作るハードル 画面パターンレベルの制約を作るには、具象から抽象を描き出せるシニアデザイナーの知識と、エンジニアリングとデザインの両方を持つUIエンジニアの力が必要です。 制約を使いこなすハードル 制約を利用する側にも、コンポーネント仕様の理解、インターフェースの把握、画面パターンの使い分け判断という学習コストが伴いました。そして最も大きな問題は、「この要求を、この制約でUI設計・実装したとき、プリンシプルが目指す体験に到達できるか」の判断が専門家にしかできなかったことです。Figmaでは制約の外でも何でも描けるからこそ、この検証が後回しになっていました。 これらのハードルは、標準UIの成果を否定するものではありません。標準UIがなければ、組み合わせ方の標準化自体が存在しなかった。しかし、標準化された制約を使いこなし、要求から体験までの変換を検証する仕組みは、まだありませんでした。 cutterの構築：制約をAIに渡すだけでは解決しない では、制約をAIに渡せば解決するのか。答えはNoでした。 freeeではこの問題を解決するために、デザインシステムの制約をAIのコンテキストとして活用する検証パイプライン「cutter」を構築しました（noteの「AIで速く作るほど遅くなる──手戻りを生む「変換コスト」を潰す、基盤化の話」で紹介しています）。このcutterの画面設計エージェントが1枚の画面を設計するとき、実際に参照しているものを並べてみると、コンポーネント仕様だけでは足りない理由がわかります。 コンポーネントの仕様: UIの部品として何が存在し、どんなインターフェースを持つか 画面パターン別の設計ガイドライン: 一覧・詳細・ウィザードそれぞれの構成ルール UIの要素別ガイドライン: ボタン配置、フォームバリデーション、モーダルの原則、ライティングルール、誤操作防止など デザインプリンシプル: 「業務フロー動線に沿った画面分割」「反復操作の効率」「情報の一覧性」など13のプリンシプル 実現可否の判定基準: 機能・レイアウト・視覚表現・インタラクションの4観点での評価 階層構造のルール: Container → Area → Segment → Block → ElementというUIの入れ子の文法 これらが整備されていない状態でAIにUIを作らせると、何が起きるか。これは人のチーム開発で起きていた問題と同じ構造です。1人の熟練者なら暗黙知でカバーできても、複数人で開発すると解釈がずれる。AIエージェントも同じで、明示的なルールがなければ各画面で判断がばらつき、スロップ（意図しないばらつき・劣化）を生みます。 設計ガイドラインがなければ、一覧画面と詳細画面の構成ルールの違いを知らず、すべて同じ構造で組み立てる。要素別ガイドラインがなければ、削除ボタンを確認なしで配置したり、バリデーションメッセージの表示位置が画面ごとに異なったりする。プリンシプルがなければ、「動くが使いにくい」UIが生成される。実現可否の判定基準がなければ、制約を無視して自由に組み立ててしまう。階層構造のルールがなければ、レイアウトが破綻する。 人のチーム開発では、これをレビューやペアプログラミングで防いできました。AIの場合は、これらのルールをコンテキストとして渡すことで防ぎます。解決の手段は違いますが、問題の構造は同じです。 つまり、コンポーネント仕様は6つの要素のひとつにすぎません。要求をUI設計に変換する判断基準（ガイドライン）、UIを通して届ける体験の基準（プリンシプル）、変換の実現可否を判定する仕組み。これらすべてをAIのコンテキストとして整備し、さらにFigmaを介さずコードベースで要求からUI設計・実装・体験の検証までを一気通貫で行う。これがcutterの発想です。 cutterを支える4つの要素とAIオーケストレーション デザインシステムの制約をAIがフィジビリティ検証に使えるようにするために、4つの要素を整備しました。 体験の判断基準をテキスト化する: プリンシプルやコンポーネントの使い分けルールを、AIがスキルとして参照できるMarkdownに変換する。Claude Codeのskillsのように、AIエージェントが設計判断の場面で必要なナレッジを呼び出せる形式にします。 制約の範囲をAIリーダブルにする: 各コンポーネントの仕様をAIリーダブルなドキュメントに整理する。人向けのStorybookやデザインファイルではなく、AIエージェントが機械的に参照・判定できるテキスト形式にすることがポイントです。 変換プロセスを標準化する: PRDのフォーマットと画面設計の記法（UFML、slideの「図じゃなく言語で描く - Common Ground for Design AI Operations」で紹介しています）を定義し、AIエージェントのワークフローに組み込みます。UFMLはユースケースの完遂に必要な画面要素・遷移・アクションを宣言的に記述する中間言語です。 品質評価の仕組みを組み込む: 各ユースケースが必要な要素を満たしているか、複数のユースケースが干渉し合わないか、仕様に曖昧さが残っていないか。こうした品質チェックをパイプラインに組み込み、変換精度を構造的に担保します。 11のエージェントによるオーケストレーション これらの要素は、渡すだけでは機能しません。要求→UI設計→実装→体験の変換は一度に行えるほど単純ではなく、デザイナーやエンジニアが日常的に行っている設計・実装・検証のオペレーションを丁寧に分解し、各工程を専門のAIエージェントに委ね、中間成果物を次の工程に受け渡していく。このオーケストレーションが品質の鍵です。 cutterでは、中央のオーケストレーターが11の専門エージェントを協調させて検証を実行します。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/n/neejack72/20260421/20260421164247.png" alt="上部にオーケストレーター、下に4つのフェーズが縦に並ぶ構成図。PHASE 1「要求の構造化」にエージェント1 (プロジェクトセットアップ) と2 (プランニング)、PHASE 2「UI設計の検証」にエージェント3 (プロトタイプ準備) と4 (画面間連携の構築)、PHASE 3「画面単位の並列処理」にエージェント5 (UI設計)・6 (カスタム要素構築、条件付き並列)・7 (画面実装)・8 (画面エラー解決)・9 (レイアウト検証)・10 (UIレビュー) の5段階パイプライン、PHASE 4「全体検証」にエージェント11 (全体エラ&#x

• デザインシステム
• 生成AI
• React

freee·2026/04/15

はてなブックマーク1

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

freee·2026/04/07

はてなブックマーク0

freeeにおけるAuthlete Terraform運用プラクティス

こんぺこ。freeeでID Federationを担当している てらら です。ぺこ。 最近はバイオハザードレクイエムの追加シナリオがあるのかないのかどっちなのかを心待ちにして過ごしています。今日はそんな中、freeeで採用している Authlete のTerraform運用についてまとめてみました。特にfreeeではfreeeアプリストアを使った特殊な要件が多いためそういった事情も踏まえて紹介していきます。 はじめに freeeでは、OAuth 2.0 / OpenID Connect に基づく認可基盤（以降、「認可基盤」と呼びます）をマイクロサービスにて運用しています。この認可基盤のバックエンドには Authlete を採用しています。 Authleteは「Component as a Service（CaaS）」と呼ばれる形態のサービスで、認可基盤そのものではなく、認可基盤を構築するためのコンポーネントをAPI経由で提供します。つまり、認可基盤のエンドポイント実装はfreee側で行いつつ、OAuthクライアントの管理やトークン発行といったコアロジックはAuthleteに委譲するアーキテクチャです。 Authleteには Terraform Registry が公式に提供されており、認可基盤に格納するデータをTerraformで管理することが可能です。 前提: freeeにおける認可基盤の利用者 freeeの認可基盤には、大きく4種類の利用者がいます。 Public API開発者: freee APIを外部公開するにあたり、API単位のOAuthスコープ設計に関わる サードパーティ開発者: freee APIを利用するOAuthクライアントを開発する外部の開発者 自社プロダクト開発者: freee内部のプロダクトチームが開発するクライアント。サードパーティとは異なるクライアント設定が必要な場合が多い グループジョインプロダクト開発者: M&A等で新たにグループに加わったプロダクトが、まずはOIDCでfreeeのID連携を利用する これらの利用者に対して、Authleteで管理するデータは大きく2つに分かれます。認可基盤の設定（Authlete Service: OAuthスコープ、エンドポイント、JWKなど）は全利用者に共通で影響するもの、OAuthクライアントの設定（Authlete Client: client_id、client_secret、redirect_uriなど）は主に自社プロダクト開発者やグループジョインプロダクト開発者が日常的に追加・変更するものです。 IaC化の背景と動機 IaC導入以前の運用は、大きく2つのフェーズを経ています。 初期は、認可基盤の管理画面（admin画面）にOAuthクライアントの登録・変更を行う専用機能を実装して運用していました。しかし、admin画面の機能は設定項目の増加やプロダクト側の要件変化に追従し続ける必要があり、メンテナンスコストが課題となりました。 さらに突発的な変更要件や結合テスト環境への設定変更に関してはKubernetes Pod内で認可基盤APIを直接呼び出すCLIベースの運用もありました。手動でのCLIコマンド実行には設定ドリフト、操作の属人化、再現性の欠如といった別の課題がありました。 IaC化はこれらの課題を一度にすべて解決しようとしたわけではなく、段階的に進みました。 第1段階: 本番と開発の設定値を揃える（Service） 最初の動機は、本番環境と開発環境で認可基盤の設定値を一致させ、環境依存の問題を防ぐことでした。OAuthスコープ100以上、サポートするクレームや各種エンドポイントの設定が環境間で食い違っていると、「開発環境では動くが本番では動かない」という問題が起きます。Authlete Serviceの設定をTerraformモジュール化し、全環境で同じ定義を再利用することで、この問題を根本的に解消しました。 第2段階: 結合テスト環境の運用コスト削減（Service） 次の動機は、複数ある結合テスト環境ごとのService作成・運用コストを下げることでした。freeeでは10以上の開発環境が存在します。これらすべてにAuthleteのServiceを手動で構築・維持するのは大きな負担です。Terraformモジュールの再利用により、新環境の追加はたった6行の定義ファイルで済むようになりました。 第3段階: 自社プロダクト開発の特殊要件への対応（Client） Service側のIaC化が軌道に乗った後、Authlete ClientもIaC管理の対象に拡大しました。自社プロダクト開発では、サードパーティとは異なる設定が必要であり、さらに各結合テスト環境間で同じclient_idとclient_secretを使いたいという開発者サイドからのニーズがあります。特に後者に関しては操作の属人化問題が大きな課題となりました。これらに関してもClientのIaC化により、シード値のコード管理と環境間の自動同期が実現しました。 リポジトリ構成とモジュール設計 Terraform管理用のリポジトリは以下のような構成になっています。 authlete-console/ ├── module/ # 再利用可能なTerraformモジュール │ ├── authlete_service/ # 認可基盤（サービス）の設定 │ │ ├── main.tf # サービスリソース定義 │ │ └── supported_scopes.tf # OAuthスコープ定義 │ ├── authlete_client/ # OAuthクライアントの設定 │ │ └── main.tf # クライアントリソース定義 │ └── client_seeds/ # クライアントのシード値定義 │ ├── local/main.tf # ローカル開発用シード │ └── integration/main.tf # 結合テスト環境用シード ├── development/ # 開発環境の定義 │ ├── env_alpha.tf, env_beta.tf, ... # 各開発環境 │ ├── staging.tf # ステージング環境 │ └── local/ # ローカル開発環境 │ ├── alice.tf, bob.tf, ... # 各開発者のローカル環境 │ └── locals.tf # シード値の読み込み ├── production/ # 本番環境の定義 │ └── main.tf └── .github/workflows/ # CI/CDパイプライン アーキテクチャの核となるのは3つのモジュールです。 authlete_service モジュール は、Authleteの「サービス」（= 1つの認可基盤インスタンス）を定義します。issuer URL、各種エンドポイント、JWK（JSON Web Key）、サポートするOAuthスコープやクレーム情報を管理します。 # module/authlete_service/main.tf（抜粋） resource "authlete_service" "as" { issuer = var.issuer service_name = "${var.stage}_${var.project_name}" # 例: "env_alpha_auth_platform" supported_grant_types = var.supported_grant_types authorization_endpoint = "${var.issuer}/public_api/authorize" token_endpoint = "${var.issuer}/public_api/token" revocation_endpoint = "${var.issuer}/public_api/revoke" dynamic "supported_scopes" { for_each = coalesce(var.supported_scopes, local.supported_scopes) content { name = supported_scopes.value.name dynamic "attributes" { for_each = supported_scopes.value.attributes content { key = attributes.value.key value = attributes.value.value } } } } jwk { TF_VAR_... } # JWKの設定（署名鍵） } output "api_key" { value = authlete_service.as.id } output "api_secret" { value = authlete_service.as.api_secret sensitive = true } authlete_client モジュール は、個々のOAuthクライアント（Relying Party）を定義します。client_id_alias、client_secret、redirect_uri、grant type、トークン有効期限などを管理します。 client_seeds モジュール は、各環境に投入するOAuthクライアントのシード値（初期データ）を定義します。ローカル開発用とステージング用でモジュールを分離しています。 メリット1: 環境別に認可基盤の設定値を統一 authlete_service モジュールを全環境で再利用することで、全ての環境で認可基盤の設定値が一貫して管理されています。 各環境の定義ファイルは、stage（環境名）、issuer（issuer URL）、jwk_json_string（署名鍵）のみが異なるシンプルな構成です。なお、JWKの署名鍵はリポジトリに直接格納せず、SecretsからTF_VAR_環境変数として注入しています。 # development/env_alpha.tf（開発環境の例 — たった6行） module "env_alpha_authlete_service" { source = "../module/authlete_service" stage = "env_alpha" issuer = "https://env-alpha.example.co.jp" jwk_json_string = var.DEV_OPENID_CONNECT_JWK } # production/main.tf（本番環境 — 同じモジュール、異なるパラメータ） module "production_authlete_service" { source = "../module/authlete_service" stage = "production" issuer = "https://example.co.jp" jwk_json_string = var.PRODUCTION_OPENID_CONNECT_JWK } freeeでは結合テスト環境にウイスキーの銘柄名やツバメの名前をつける文化があり、10以上の結合テスト環境がそれぞれ独自の名前を持っています。これだけの数の環境があっても、各環境の定義ファイルはたった6行で済みます。 これはIaCの基本的なメリットではありますが、OAuthスコープ、サポートするクレーム、各種エンドポイント設定を含む認可基盤の設定が全環境で一貫していることの価値は大きいです。スコープの追加や変更をモジュール側で行えば、全環境に自動で反映されます。 メリット2: ローカルシード値のコード管理 IaC化により、ローカル開発環境のOAuthクライアント（シード値）をコードで管理できるようになりました。アプリケーション開発におけるDB Seedsと同様の考え方で、認可基盤の初期データをコードとして定義・投入する仕組みです。 module/client_seeds/local/main.tf に全クライアントのシード値をコードとして定義しています。 # module/client_seeds/local/main.tf（抜粋・値は例示） output "value" { value = { "alpha-dev" = { client_id_alias = "alpha_app_uid" client_secret = "alpha_app_dev_secret" client_name = "alpha-app-dev" redirect_uris = ["com.example.app.debug:///auth-redirect-dev"] client_type = "CONFIDENTIAL" client_grant_types = ["AUTHORIZATION_CODE", "REFRESH_TOKEN"] client_response_types = ["CODE", "TOKEN"] token_auth_method = "CLIENT_SECRET_POST" description = "Alpha app development client" attributes = { freee_client_type = "internal" } }, "beta-dev" = { client_id_alias = "beta_uid" client_secret = "beta_dev_secret" # ... 以下同様 }, # 他にも多数のクライアント定義が続く } } 各ローカル環境は、このシード値を for_each で読み込んで全クライアントを自動プロビジョニングします。 # development/local/locals.tf module "client_seeds" { source = "../../module/client_seeds/local" } locals { client_seeds = module.client_seeds.value } # development/local/alice.tf（開発者 alice のローカル環境） module "alice_authlete_service" { source = "../../module/authlete_service" stage = "alice" issuer = "https://accounts.dev.example.co.jp" jwk_json_string = var.DEV_OPENID_CONNECT_JWK } module "alice_local_common_authlete_client" { source = "../../module/authlete_client" for_each = local.client_seeds # 全シード値をループ service_api_key = module.alice_authlete_service.api_key service_api_secret = module.alice_authlete_service.api_secret client_id_alias = each.value.client_id_alias client_secret = each.value.client_secret client_name = each.value.client_name redirect_uris = each.value.redirect_uris # ... その他のパラメータ } 新しいOAuthクライアントが必要になった場合、client_seeds/local/main.tf にエントリを追加するだけで、全ローカル環境に自動的に反映されます。個別環境でseedコマンドを打つ必要はありません。 メリット3: 環境間のclient_id / client_secret同期とセキュアなオペレーション 3つ目のメリットは、複数のローカル環境間でclient_idとclient_secretを自動的に同期でき、しかもそれが人間の手作業を介さないためセキュアに実行できることです。 環境ティアに応じたシークレット戦略 ローカル開発環境とステージング環境では、client_secretの管理戦略を意図的に分離しています。 - ローカル環境: 開発者の利便性を優先し、人間可読な固定値（例: "alpha_dev_secret"）を使用します。 - ステージング環境: Terraformの Random Provider でclient_secretを自動生成し、keepers によるローテーション機構を備えています。 これにより、secret の値を人間が共有する必要がなく、かつ必要に応じて再発行が可能です。 # module/client_seeds/staging/main.

• Terraform
• OAuth
• OIDC
• Authlete
• IaC

freee·2026/04/07

はてなブックマーク15

RubyKaigi 2026 登壇の hachi さんインタビュー & 4/24 freee Drinkup イベントのお知らせ

こんにちは。関西拠点で freee 販売を開発しております、bucyou (ぶちょー) と申します。今日は4月22日(水)〜24日(金) にかけて、北海道は函館にて開催される RubyKaigi 2026 に登壇する hachi さんに話を聞いてみました。また、RubyKaigi 2026 の3日目 4/24 に開催されるDrinkup イベントのご案内もさせていただきます。 hachi さんとトークセッションの紹介 木村 駿生 (Hayao Kimura): Kyobashi.rb の共同主催者。Kaigi on Rails や、関西Ruby会議08などのオーガナイザー。フリーとしては、freee 請求書や、その周辺領域のテックリードを担当している。技術書典の書籍として、『マイコンでRubyが動くまで〜PicoRubyを理解する〜 (2015/11)』『Rubyではじめる電子工作~ラジコンを作ろう~(2024/5)』など。 hayaokimura (Hayao Kimura ( hachi )) &middot; GitHub https://x.com/hachiblog トークセッション rubykaigi.org 4月23日 (2日目) のSmall Hall にて、17:20 〜 17:50 に予定されております。 内容としては、PicoRuby で利用されているファームウェアであるところの PPK (キーボードファームウェア)と R2P2 (汎用的なファームウェア) の2つを統合できるか? という話題だそうです。が、hachiさんによると諸般の事情があり、PicoRuby 関連の別のトピックに変わるそうです。 今回は、hachiさんと電子工作周りの活動について聞いてみたいと思います! 電子工作との出会い -- 普段、Kyobashi.rb などでお話を聞いていると、電子工作に関係するトピックはよく話されていますね。普段はWebエンジニアとしてお仕事されているので、電子工作を始めるのにはどういう経緯があったのですか? 実は、電子工作のほうが先にあって、その後にプログラミングがついてきたのですよね。小学生のころ、親の仕事の都合でベトナムのハノイにいたことがあったのですが、おじいちゃんから日本の生活物資が送られてきてたんですよ。 で、コロコロコミックとかも送られてくるんですが、そのなかに 東京ホビーセンターの「電子工作通信講座」なる広告が雑誌裏にあって、それを買ってもらって遊び始めたのが始まりなんですよね。 -- おお。ベトナムまで送ってもらってやってたんですね。それはすごい。 そうなんです。なので、プログラミングより先に電子工作に出会っていたんです。プログラミングについては実はこの後で、学研の『子供の科学』っていう雑誌も日本から送られていたんですけど、ここに「HTML & JAVAスクリプトかんたんプログラム1」っていう連載があって、これで何か動くものを作り始めたのがきっかけ。 -- この辺の話していたスライドがありましたけど、あれベトナムでやってたんですね。いい原体験だ。。めちゃくちゃいいですね。 確かに、そのくらいの時代の時、子ども向けでのホームページを作るとかそういう本もちょっとずつ出始めてましたよね。 speakerdeck.com で、こういうところで興味を持って大学では電気電子工学科っていう電子系の話題と、プログラミングの話題が両方できるトコに進んだんですけど、どちらかというと電気とかの話題が多いのですよね。プログラミングのスキルとかは、アルバイトやサークル活動でCMS作成などを通じて磨いた感じです。 Ruby を通じて「知らない世界を掘り下げる」面白さ -- PicoRuby はどんなところが、たのしいですか? Ruby は普段の仕事で使っているのですが、一方で趣味などでも同じ手触りの言語で知らないことを知れるというのが面白いです。ウェブのアプリケーションで使っている Rails だと、HTTP通信や、さらにそれが物理的な電気信号に変わっていくといったところを Ruby とか、その裏で動いている C のライブラリを全部追っていくのは非常に難しいです。 一方で、PicoRuby は物理的なもの (低レイヤー) への距離が近いので Ruby という言語を通して割と簡単にいろんなことが知ることができるのが魅力です。 -- 技術書典で最近出してた本は、マイコンでRubyが動くまで、ということで CRuby (普段使っているRuby) との比較について解説していましたね。 techbookfest.org 今回のトークについて -- 今回のトークは、どんな人に聞いて欲しいですか? まずは、PicoRubyに入門してみたい人ですね。今回のRubyKaigi では他のテーマとして PicoRuby に関するもっと凝った話題もあるのですが、それよりかは「PicoRuby が盛り上がっているらしいが、その次の一歩が難しい」と感じている人がターゲットになると思います。 ファームウェアが複数あったりして、とっかかりにくいみたいなところもあるのですが、もっと簡単に楽しめるということを伝えていきたいと思ってます! -- ありがとうございました! 登壇後、また社内で内容を聞かせてください! freee Drinkup イベントの紹介 スピーカーの hachi さんも参加する、freee Drinkup イベントは 3日目 4/24 に開催されます。参加には、RubyKaigi 2026 のネームタグと、受付票が必要です。ぜひ、ご参加ください。 https://freee.connpass.com/event/388862/freee.connpass.com インタビュアー bucyou (ぶちょー): 川原 翔吾, freee販売エンジニア。関西拠点所属。Rubyは10年ほどの付き合い。最近は Claude Code で理想のフレームワークを作ったりしてみて遊んでいる。Kyobashi.rb によく参加している。ちなみに、今年は RubyKaigi には参加しない。みんな楽しんできて欲しい。 本来は JavaScript と記載するところですが、雑誌の表記を尊重してそのままの形式で記載しています。↩

• Ruby
• PicoRuby

freee·2026/04/06

はてなブックマーク25

AI Agentに関する試行錯誤を共有する社内LTイベントを開催しました！

こんにちは！freee請求書の開発エンジニアをしているkochanです。 近年、AI Agentの進歩が目覚ましく、AI Agentを使って開発生産性を向上させた事例や、AI Agentを組み込んだ機能提供の事例が続々と登場しています。 しかし、いざ実務に投入しようとすると、プロンプトの微調整に追われたり、期待通りの挙動にならず頭を抱えたりと、理想と現実のギャップにぶつかることも少なくありません。 今回は、そんな現場の泥臭い試行錯誤を組織で共有するために開催した、社内LTイベントの様子を紹介します。 LT会の様子 開催の背景 組織全体でClaude Codeを利用した開発が推進されていたり、AI Agentを利用した機能提供が進んでいます。その中で、Claude Codeによる生産性向上やAI Agent機能開発の知見が、各チームや個人に閉じてしまっているという課題が出てきました。 AI Agentを業務に適用するにはまだまだ試行錯誤が必要です。特定のタスクに適用するために格闘したプロセスをオープンに共有し、「不確実性を楽しみながら乗りこなせるエンジニア」を増やしたいと思い、今回のイベントを企画しました。 社内でAI Agentを用いた機能開発をしている方やClaude Codeを使った開発生産性向上のための仕組み作りに取り組んでいる方々にお声がけし、9人の方に発表してもらいました。 セッション紹介 全9セッションの中から、特に印象的だった2つの発表をピックアップして紹介します。 Rails UpgradeをAI Skillで仕組み化した話 登壇者：nuresen 内容の要約 nuresenさんは、Rails 7系から8.1への一気通貫したアップデートを、Claude CodeのSkillsを活用して仕組み化した事例を共有してくれました。 初めは1つのセッションでUpgrade作業を実施しようとしましたが、コンテキストの肥大化による精度低下の問題があることや、途中で人間による細かい介入がしづらいといった課題が見つかりました。 そこでUpgrade作業を、調査、依存関係解決、失敗の分析、修正、設定更新の５つのステップに分割し、それぞれに対応したSkillを定義。各ステップの成果物をMarkdownとして出力し、それを次のステップの入力にする設計にすることで、コンテキストの肥大化による精度低下を回避。人間が各チェックポイントで意思決定できる仕組みを構築しました。 詳細はfreee Developers Hubにも投稿されているので、気になる方はぜひこちらの記事も見てください！ developers.freee.co.jp nuresenさんの発表の様子 現場の反応 「ベテランの暗黙知がSkill化されて、誰でも簡単にRails Upgradeできる状態になったのすごい」「巨大なタスクをステップごとに分割するアプローチは、他の業務自動化にも展開したい」と、実用性の高さを評価する声が多かったです。 まほう経費精算プロジェクト 登壇者：momoji 内容の要約 まほう経費精算の開発に関わったエンジニアのmomojiさんからは、サービス提供に至るまでの、泥臭い試行錯誤の記録が共有されました。 まほう経費精算とはAIエージェントが過去の傾向から申請内容を推測することで、誰でも迷わず正確な申請ができる機能です。 corp.freee.co.jp 開発当初はのチャットUIで何でも解決できるという構想でしたが、ユーザーの入力負担が多く、利用してもらえないという失敗談からスタート。そこからターゲットを大量の領収書が発生する訪問ワーカーに絞り込み、まずは利用してもらってフィードバックを得ることを目指しました。フィードバックと改善を回す中でAIの推測が正しいか確認することに特化した専用UIへと方向転換した経緯が語られました。 まほう経費精算のUIの試行錯誤 現場の反応 「まずはN=1でもいいから使い倒してもらい、フィードバックを回す姿勢を見習いたい。」「AI Agentという不確実な対象だからこそ、これまで以上にアジャイル開発の重要性が上がっている。」といった、反応がありました。 振り返りと今後 AI Agentの進化スピードは凄まじく、今日得た正解が明日には古くなっているかもしれません。だからこそ、組織全体で知見をオープンにし、互いの失敗と成功を共有して資産にしていく文化が重要だと思います。 これからも定期的にこうした知見共有の場を設け、freee全体でAI Agentという荒波を楽しみながら、開発生産性とプロダクト価値の向上に挑み続けていこうと思います！

• 生成AI
• 自動化
• アジャイル

freee·2026/03/26

はてなブックマーク5

OIDF-J 第2期 人材育成WG 下半期の参加レポート 〜総集編〜

こんにちは。IAM基盤エンジニアのハトンです。 以前の記事で、OpenIDファウンデーション・ジャパンのデジタルアイデンティティ人材育成推進WG フェーズ2における上半期の活動や、8月に開催された中間報告会についてご紹介していただきました。 OIDF-J 第2期 人材育成WG 上半期の参加レポート - freee Developers Hub 今回はその続編であり、1年間の活動の総集編として紹介させてもらいます。 下半期の活動について 下半期も引き続き、参加企業の方々とともにビジネスと技術の2つのサブグループのテーマごとに資料作成を進めていき、先日に1年の集大成となる最終活動報告会が開催されました。 報告会では、各チームがこの1年間で深掘りしたテーマについての成果発表を行い、大盛況のうちに幕を閉じました。 発表資料や報告会の配信アーカイブはこちらから確認できます。 20260311 技術SWG活動報告（デジタルアイデンティティ人材育成推進WG Ph2 活動報告会） - Speaker Deck 20260311 ビジネスSWG活動報告（デジタルアイデンティティ人材育成推進WG Ph2 活動報告会） - Speaker Deck www.youtube.com 1年間のWG活動に参加して得られた効果と学び この1年間、WGの活動を通じて他社の方々と密度の濃い時間を過ごしてきました。ここでは、実際にWGに参加し、活動を通じて得られた個人的な学びや効果について振り返ってみたいと思います。 業務の枠を超えたインプットと議論から得られる知見 OIDF-JのようなIDに関わるコミュニティの集まりに参加する最大のメリットの一つは、自社の業務だけに閉じない、幅広い知識や最新の業界動向を得られることです。各社が直面しているリアルな課題や、それを解決するためのアプローチを聞くだけでも非常に勉強になります。 しかし、1年間参加を続けて強く感じるようになったのは、ただ話を聞くだけよりも、自ら議論に参加した方が得られるものが何倍にも膨れ上がるということです。 インプットした情報を、自身の言葉で言語化して語ってみる。そして、それに対する他者の意見や異なる視点の言葉を聞く。このキャッチボールを繰り返すことで、自分の中にある曖昧だった理解の解像度がグッと上がり、知識がしっかりと腹落ちしていくのを感じました。 議論しなくてはいけない環境に身を置く価値 とはいえ、IDのコミュニティには、ID領域を専任で担当されているような、いわゆる「その道のプロ」がたくさんいらっしゃいます。正直なところ、そんなプロフェッショナルの方々に対して、自分から積極的に話しかけたり、議論を吹っかけたりするのは、かなり勇気のいることです。「的外れなことを言ってしまわないか…」と躊躇してしまうこともありました。 そこで非常にありがたかったのが、教育WGの各テーマに参加することでした。 WGでの活動は、単なる聴講ではなく、参加者同士で意見を出し合いながらアウトプットとして資料を作り上げていくスタイルです。つまり、半強制的に「議論しなくてはいけない環境」に身を置くことができます。 また、他社の方々と議論をしていてハッとさせられたのが、「自社の業務で一般的だと思っている用語や概念が、標準化の世界や他社では全く通じないことがある」という事実です。文脈の違いや前提知識の違いによって生じるギャップを肌で感じることで、より客観的で標準的な視点を身につける必要性に気づかされました。 技術とビジネスを繋ぐ視座を獲得する このような環境で1年間議論を重ねることで得られた最大の効果は、仕様や技術に対する視座が高くなったことです。 具体的には、以下のようなことが深く理解できるようになりました。 「そもそも、これはなんのための仕様なのか？」という根本的な目的 その仕様を採用している「標準ガイドライン」に従うことで、結果としてどのような「法要件」や「ビジネス要件」を満たすことができるのか エンジニアとして技術を選定・採用する際、どうしても「技術的に優れているか」「実装しやすいか」といった技術的な理解に偏りがちです。しかし、本来、技術を採用するには「それがビジネスにどう貢献するのか」というビジネス的な理解が不可欠です。 OIDF-Jの活動では、IDの専門家の方々から直接フィードバックをもらい、議論を交わしながら、技術とビジネスの繋がりについての理解を深めることができます。日々の業務の中だけでは、ここまで多角的な視点からフィードバックをもらい、考えを深める機会はなかなかありません。 おわりに 1年間のOIDF-J 人材育成推進WGでの活動は、単に仕様書を読むだけでは得られない知識と多角的な視点を与えてくれました。最初は勇気がいるかもしれませんが、一歩踏み出して議論の輪に加わってみることで、圧倒的な成長の機会が得られると実感しています。 今後もコミュニティでの活動を通じて知見を深め、freeeのプロダクトやIDのさらなる進化に還元していきたいと考えています。

• OIDC
• OAuth

freee·2026/03/25

はてなブックマーク0

隣の会社のEMも、同じことで悩んでいた─EMConf 2026 freeeスポンサーレポート

正解がない。相談できる人も少ない。それでも意思決定を続けなければならない。 Engineering Manager（EM）という役割を担っていると、そんな場面に何度も直面します。freeeのEMたちも例外ではありません。「任せると丸投げの境界線がわからない」「デリバリーに集中するあまり、気づけば視野が狭まっていた」日々そんな悩みを抱えながら、それでも考え抜くことをやめない人たちが、freeeには集まっています。でも、その悩みはfreeeだけのものではありませんでした。 freee は2026年 EMConf（Engineering Management Conference Japan）にプラチナスポンサーとして参加しました。EMConf は、日本のエンジニアリングマネージャー（EM）たちが実践知を持ち寄り、共有するカンファレンスです。2026年のテーマは「増幅」と「触媒」。EMが組織や個人の能力を引き出し、変化を加速させる存在であることを象徴しています。 freeeがスポンサーになったのは、ブランディングや採用のためだけではありません。正解のない課題に向き合う EM たちが、会社の枠を超えて集まり、泥臭い悩みも成功体験も「あえて共有する」その場を一緒に作りたかったからです。 この記事では、当日の様子とともに、freee の EM たちが EMConf で何を感じ、何を持ち帰ったかをお伝えします。 EMConf 2026 当日の様子 「増幅」参加者の感想 mattsun micci sentokun sayoshi hiwa 「触媒」スポンサーブースの様子 「触媒」スポンサーセッションの様子 あえて共有：スポンサーに込めた思い 発案者 mattsun (X:mtskhs )としての思い 会社としての思い さいごに: フリーなりの「増幅」と「触媒」 EMConf 2026 当日の様子 メンバーに任せているのに、なぜかうまく回らない。その原因は、信頼の問題ではなく意思決定の設計の問題かもしれません。ある登壇者は「"信じて任せた"は失敗する」という言葉からはじまり、意思決定を「必ず止まれ／確認して進め／止まらず走れ」の3色に色分けして移譲する、という具体的なアプローチを紹介しました。 デリバリーを回すことに集中していたら、いつの間にか視野が狭まっていた。これはfreeeのEMが自分自身について語った言葉です。数字は「何が起きたか」を教えてくれるが、「なぜそうなったか」は顧客の声と隣接組織への理解からしか得られない。頭ではわかっていても、できていない。そのギャップをこのカンファレンスで突きつけられた、という話です。 AI時代に開発スピードが上がるほど、マネージャーとして考えることが増えている気がする。その感覚は正しくて、アウトプットが爆発的に増える今だからこそ、考えるための時間を「たまたま空いた余白」ではなく「戦略的に確保するもの」として設計し直す必要がある、という話も出てきます。 悩みの種類は違っても、どこかひとつは刺さるはずです。以下、EMConf 2026当日の熱を「増幅」させるべく、参加者の感想を載せていきます。 「増幅」参加者の感想 mattsun 支出管理開発本部で、部長をしている mattsun です。フリーには入社して4年弱になるところで、プレイングマネージャーを経て去年から部長という役割となり日々挑戦中です。 冒険する組織のつくりかた 著書を事前に読んだうえでセッションに臨みましたが、読了済みにもかかわらず新しい気づきが次々と出てきました。本来はマネージャー専用の書籍ではありませんが、このカンファレンス向けのセッションとして「目標」「興味」「会議」「文化」という4つのマネジメント観点に再構成され語られており、自分の日常業務と照らし合わせながら聞くことができました。 「会議」のマネジメントでは、「メンバーから意見が上がらない」というどの組織でも起きがちな課題が取り上げられました。そこで強調されていたのは、オープンクエスチョンではなく「答えやすい問いかけ」の重要性です。 問いかけの例： 点数でいうと？ どれが一番おもしろかった？ どちらがよい？ 心理的安全性の話は昨今あちこちで語られますが、「場のデザイン」という具体的な行動レベルに落とし込まれているのが印象的でした。「意見が出ない」のは、メンバーの問題ではなく問いかける側の設計の問題—そう捉え直すことで、自分自身のファシリテーションを見直すきっかけになりました。 「文化」のマネジメントでは、文化とは風土とは異なり「他にはない独自の価値基準」であるという定義が示されました。価値基準の集合が文化であるため、以下のような実践が必要だという話がとても刺さりました。 AよりもBを大事にする 繰り返し伝える 体現しているメンバーを称賛する 「文化づくり」と聞くとつかみどころのないものと捉えていましたが、こういった価値基準を言語化し、伝えていくことが部長の役割だと捉えると自分も実践できることが多いと理解できました。 「事業目線」の正体〜EMがもつべき視点〜 資料 3つのレベルで「事業目線」の正体を解説するセッションでしたが、特に「Lv2 お客さまと隣接組織を知る」に大きな発見がありました。 数字は「何が起きたか」を教えてくれますが、「なぜそうなったか」はお客様の声からしか得られない—という指摘は、シンプルながら改めて刺さりました。データドリブンが強調されるほど、定性的な顧客理解が相対的に軽視されがちだという構造的な問題を改めて意識しました。 隣接組織を知ることの意味として挙げられていたのは以下の2点です。 組織ごとに業務フローや力学が異なるため 自組織のアウトプットに関わる組織を理解することで、成果を出しやすくなるため 「言われてみれば当たり前」と感じた瞬間に、むしろ警戒が必要だと思っています。「当たり前」と感じる事柄こそ、できていないまま放置されやすいからです。部長という役割になり、関連セクションからの期待をより深く理解すべき立場になった今、正直に言えば「全然できていない」と気づきました。知っていることとやっていることの間にある溝を、このセッションで突きつけられた感覚です。 感じたこと・今後 新規プロダクト立ち上げに関わる自分の立ち位置を、改めて厳しく見直す機会になりました。EMとしてデリバリー領域にフォーカスしてきた一方で、プロダクトの中期的な方向性や周辺組織への理解が不足していることは否定できません。「デリバリーを回す」ことに集中するあまり、組織の外側に対する視野が狭まっていたと感じています。 EMお悩み相談室でsotarokさんと話すなかで、異なる組織間の連携における視座の違いをリアルに感じることができました。自分の「当たり前」が、他の文脈では通用しないことがある。そのことを体感できたのは、カンファレンスならではの収穫でした。 今後、隣接組織との連携を深めるうえで、以下のようなフォーマットで対話を積み重ねていくつもりです。 ミッション・役割の理解：その組織が何を目指し、どのような価値を生み出しているかを聴く 現在の課題や優先事項：今抱えている問題や注力していることを整理してもらう 自組織への期待・連携ニーズ：自分たちのチームにどう関わってほしいか、どんな貢献が期待されているかを具体的に聴く そして、この先1年間の目標をひとつ宣言します。来年のEMConfに、自組織のマネージャーの参加者を増やすこと。 スポンサーとして「増幅」と「触媒」に貢献すると書きましたが、まず自分の足元から始めます。 micci 冒険する組織のつくりかた 安齋さんのルーツが研究者ということで、お話の中でも頻繁に歴史的に重要なポイントになった書籍や、初めて経営の文脈で軍事用語が使われるようになったタイミングなど、事実や先行研究をベースにした内容はとても高い納得感とウンチクを知る時のような楽しさを持って聞くことができました。特に印象に残っていたのは、人の興味のパターンを2つの軸の掛け合わせて分類できる、という話でした。具体的には、対象を「ヒト」「コト」どちらかの2つと、対象へのアプローチの「創造」「解明」「介入」「運用」の4つを掛けた8パターンに分類できる、というものです。十人十色あって捉えづらいものを少ないパターンに分け、それにあったアサインを考えやすくなるものとしてとても使いやすそうで、早速自分のチームでもそれぞれ興味はどこに向いてそうか聞いてみたいなと思いました。 エンジニア組織全体で取り組むDX改善：現場とマネジメントが連携した生産性向上への挑戦 資料 私は主務でネクスト開発グループのPMOをしており開発生産性の計測や向上のための企画をしているので、他の現場でどういったアプローチが取り組まれているのかとても興味がありました。3ヶ月に一度のアンケートでの定点観測、グッドハードの法則を意識して数値上で見える改善にこだわりすぎないこと、上がってきたフィードバックに素早く返すこと、取り組まれていたことの1つ1つは珍しいことではないように見えます。しかし、様々なプレッシャーがある中で真摯に取り組んで着実に進ませることの難しさを私も日々感じてるので、実践者の方には頭が上がらないなぁと感じました。 マネージャー版 "提案のレベル" を上げる 資料 以前こにふぁーさんが話されていた内容のマネージャー版でした。以前の内容に大きく感銘を受け周りのメンバーにもよくオススメしていたので、マネージャー版を聞けるのをとても楽しみにしていました。マネージャーが提案のレベルを上げることの難しさと、こにふぁーさん自身の経験からきた乗り越え方のお話がありとても参考になりました。特にマネージャーがまず「組織図」「目標」「会議体」「予算」を抑えると理解しやすい、というお話は、普段PMOとしてEMがもっと活躍しやすくする環境づくりをする上でのヒントとなりました。ask the speakerでもこにふぁーさんの経験からPMO的な立場の人にやってもらうと嬉しいことなどを会話させていただいて、より理解を深めていくことができました。 感じたこと・今後 今回初めてEMConfにスポンサーとして参加して振り返ってみると、EMConfの場自体が安齋さんのお話の中にあったALIVEの法則を体現しているなと深く感じました。ALIVEとは、組織の目標設定において「変化に適応できる」「学びの機会になる」「好奇心をそそる」「未来を見据える」「実験的である」の5要素を重要視する考え方でSMARTとの対比で語られていました。EMConfは、今後の社会の変化にも適応できるような学びを得ることができ、それぞれが好奇心をそそるような内容で、組織を超えて未来を良くしていく人たちの交流ができ、アンカンファレンスのような当日まで何が起こるかわからない要素もありました。だからこそ、EMConfの場にいる全員が前向きに参加しているように感じられたのかなと改めて思いました。私もPMOとして現場でキックオフや交流の場作りをすることが多いので、全員にとってALIVEな場になっているかを常に考えて設計していきたいです。 sentokun 統合flow基盤本部 IAM部で、権限管理基盤チームのEM 兼 PdM を務めている sentokun です。フリーには入社して3年半ほどになります。現在は権限管理基盤のEMとして主軸を置きつつ、Product、Project、People Managementといった多岐にわたる領域でオーナーシップを持って活動しています。 自律型組織の真実：『甘い自走』を捨てて導いた、EMによる戦略的組織変革 資料 どのように自律型組織が活躍できる状態を設計するか？というセッション チームに対してずっと持っている課題として、自律型のチームに対する「任せるところは任せる・締めるところは締める」の塩梅があると思っています。このあたりのテーマについては、理想論としてのあるべきは色々たまっているのですが、じゃあどうするかは個人的にずっと抱えている課題です。 なので同じ悩みを抱えてる方の生の事例だと思い、セッションを聞きました。 スライド頭、「メンバーを信じて、現場を任せる」だからあなたは失敗する。いやほんとそうなのよ。悪く言えば丸投げ、無計画を隠した「信じてる、任せた！」は失敗する。そして、これは組織の設計上の課題である。 ここがコアなメッセージだと思います。おっしゃる通り、耳が痛い。 内容の要点は以下だと思います ちゃんと期待値とその責任、そして自由に振る舞う境界(ガードレール) を設計し、チームやリーダーに持ってもらうことが大事だよ そのために必要なことは色々あるが、全部は無理。レバレッジが効くセンターピンは「意思決定の移譲」で、ここからはじめるとチームは自律に向かう EM が意思決定を移譲するには、業務判断を3つに色分けすること。「RED:承認 必ずとまれ」「YELLOW:相談 確認して進め」「GREEN:報告 止まらずに走れ」。 要は、意思決定をするための判断基準(意思決定に対する判断)を構造化して、その構造に従い行動するというアプローチ。わかりやすいし理にかなっているなと感じました。 私自身の経験として、このあたりは例えばティーチング・コーチング・メンタリングの使い分けだったり、介入ポイントを意識して任せるといった手段で会話しているのが主でしたが、濃淡もあり都度の判断も難しかった印象でした。 その意思決定に対する判断を設計してしまうアプローチはなかったので学びになりました。 特定領域から複数領域へ、そのとき何を求められるのか？縦と横、2つの影響力：統合型を目指す大規模な開発組織での実践 資料 freee 社内で統合の EM といえば名前が必ず上がる tomoz さんのセッション。 「仕事は待ってくれないので、意思決定を続けないといけない」というのは、tomoz さんの基本姿勢としても日々感じられます。リーダーとして純度が上がるほどこの強度が高まる、重要な変数だなと思った。 また、組織の内側だけ見ていては、適切な判断は下せないので、ちょっと外から広げていくことの重要性も感じます。 縦の影響について、領域を深く全部は見きれないことを認めて任せる。そのためにどこまでの意思決定を移譲するのかの期待値設定をして、ガードレールを引くのが重要なんだろうなということを感じました。 横の影響について、組織全体へ波及させていくことの難しさは実感しています。うまい人と自分の違いはメッセージングだなと常々感じている。焦点と胆力というポイントはほんとそうだなと思う。幅広く課題を捉え特定していくのも大事だが、最後に広めるぞ！のフェーズでは腹を決めて焦点を当てる・後はとにかく何度も伝える！実行する！とできる環境を整えていくことが重要だなと改めて感じました。 組織・文化・技術の壁に挫折したEMが、アーキテクトとして「構造化思考」を手に、再び保守開発組織の変革に取り組む 資料 個人的一押し学びセッション。モデリング・構造化思考を活かして組織に立ち向かうという話で、共感と学びの両面が深く、めちゃくちゃよかった。 元々 EM -> 挫折してアーキテクト -> EM と転籍し、アーキテクトとして培われた構造化思考を EM に転用しましたという話。 freee VPoE のyoshi さんが語られていた話 (https://ttj.paiza.jp/archives/2024/08/06/14953/) ともリンクして興味が沸いたのと、私自身 PdM と EM の兼務になって視点が変わったなと感じる体験が面白かったので、期待を胸に発表を聞きました。 レガシーの本質は「モデルのずれ」により発生し、そのずれから技術的負債や組織的負債が発生する。そのため、あらゆるものをモデルにし、概念を構造化していくことで全ての課題がとける！という立ち向かい方をされていました。私にとっては、とても説得力のある話だった 過去この方も EM=仕事しやすい環境づくりと捉えており、その環境が作れないならうまくいかないよねと考えていた。 そこから組織の課題を「モデルのずれ」として思考し、なぜずれるのか？どうすればずれをなくせるのか？の構造を捉え改善するアプローチに変えた。構造化思考により EM としてやれることが生まれたという話をしていました。 とにかくソフトウェアの原理原則から組織を捉え、紐解いていく話をしており、AI時代でもその構造化思考によりプロセスや組織を整理することが、成果につながると語られていました。かみごたえのある資料なので、ぜひ見てみてください。 私も友人から「 AI 時代のマネジメントってどう変わるの？」と聞かれ、「ソフトウェア開発の原理原則は変わらず、それを実現する手段が劇的に変わるって感じなんじゃないかな」と話していたことがあったのですが、綺麗に言語化されて感動した。 組織崩壊と向き合う技術〜2度の崩壊から得た再生の実践知〜 資料 個人的一押しエモセッション。失敗談は栄養価が高くて大好きなのですが、自身の組織崩壊というどでかいテーマに対して身を切るようなお話を聞かせていただき、感謝しかないです。 登壇内容の要約については、伝聞により意味合いが変わることを避けたいので NG とのことでした。なので公開記事の内容 + 感想に留めます。 個人的に一番共感したポイントは、頭と心を整理するという話。自身・チームが変化により混乱している状態では、頭と心の整理がめちゃくちゃ大事だととても共感します(私の経験とは規模がまるで違うけど)。頭の中で事実関係を冷静に整理すること、そしてなにより心の状態に向き合い、本音

• マネジメント
• エンジニアリング
• 組織開発
• キャリア

freee·2026/03/24

はてなブックマーク1

PHPerKaigi 2026 登壇 & 参加レポート

こんにちは！フリーナンスのエンジニアをやっているthe よしだです！ 今回は2026年3月20日(金)から22日(日)に中野セントラルパーク カンファレンスで開催された「PHPerKaigi 2026」に登壇 & 参加してきました！ 登壇では私がどんな内容を話したのか、他にはどんなトークがあったのか紹介していきたいと思います！ 登壇内容 今回私は、「Laravelで学ぶOAuthとOpenID Connectの基礎と実装」というテーマを話してきました！ speakerdeck.com 今回のテーマを選んだきっかけとして、昨年9月にフリーナンスがfreeeへのジョインしたことが挙げられます。 フリーナンスとfreee内サービスとの連携を高めていく中で、アカウント周りの連携強化にOIDCを学び直す必要がありました。 また、OIDCと並行して、OAuthについても調べていき、OAuth2.1がドラフト状態であることや、それによって変わる部分も明確になってきました。 PHPのフレームワークであるLaravelの場合、ライブラリを入れることで楽に実装できる反面、自身で対応しなければいけない部分もあります。 ライブラリを盲目的に使うだけでは抜け落ちてしまう部分に気づくためにも、基本的な考え方は理解しておくに越したことはありません。 この発表が、OAuthやOIDCの理解を深めるきっかけになれば幸いです。 印象に残ったトーク 正直なところ、聞いた全てのトークを紹介したいくらい、素晴らしいトークばかりでしたが、その中でも特に印象に残ったものをいくつか紹介します！ 「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 speakerdeck.com スピーカーの武田さんといえば、普段はLaravelについて様々なお話をしてくださる方です。 今回はwebサービスについて原理原則とも言える基本部分の話が中心でありながらも、経験豊富な方にもおすすめできる内容となっています。 私自身、接続プーラーは知らなかったので勉強になりました・・・・。 モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について speakerdeck.com 4年前にモジュラモノリス導入を決めてから現在に至るまでの答え合わせをするといった主旨の内容でした。 トークの中では、求められる役割にあわせて変更されていく組織図、その中での試行錯誤について語られており、かなりリアルな話が聞けました。 この4年間、モジュラモノリス導入についての途中経過のトークがいくつかありましたが、その総括にふさわしい素晴らしいお話でした。 Laravel OctaneはFrankenPHPをどう高速化しているのか？ソースコードから読み解く、高速化の仕組み www.docswell.com まず、FrankenPHPとは、Go言語で構築されたCaddy Webサーバー上で動作する、高速でモダンなPHPアプリケーションサーバーのことです。 最近、PHP関連のカンファレンスでも名前を見かけることが多いです。 OctaneでFrankenPHPを起動する際、Laravelのブートを都度しなくて済むことと、その原理を説明していました。 また、良い部分だけでなく、注意点にも丁寧に触れており、非常に学びの多いトークでした。 最後に PHPerKaigi 2026は終わりましたが、PHPカンファレンス 2026は7月20日(月)に大田区産業プラザPiOで開催されます！ ぜひ会場でお会いしましょう！

• PHP
• Laravel
• OAuth
• OIDC
• アーキテクチャ

freee·2026/03/16

はてなブックマーク0

Claude Code SkillsでRailsアップグレードを仕組み化した話

はじめに こんにちは。freee請求書チームでエンジニアをやっているnuresenです。 この記事では、Rails 7系から8.1へのアップデートを Claude Code の Skills を使って実施した記録を紹介します。 みなさん、Railsのアップデートはできていますか？ Railsは定期的に新しいバージョンがリリースされますが、大規模なプロダクトになるとキャッチアップするのもなかなか大変ですよね。 freee請求書では、現在のバージョンがEOLを迎える前にアップデートしていく方針をとっており、だいたい年に1、2回くらいの頻度でバージョンアップを実施しています。 今回は7系から8.0へのバージョンアップを予定していましたが、8.0のEOLが2026年11月に迫っていることを踏まえ、8.1まで一気に上げてしまうことにしました。 ただし、Railsガイドにも書いてあるように、アップデートはジャンプアップせずに1つずつ段階的に上げていくのが鉄則です。そのため、今回は 7系 → 8.0 → 8.1 と2段階に分けてアップデートすることにしました。 2回同じ作業を繰り返すこと、そして今後も定期的にアップデートが必要になることを考えると、この作業自体を仕組み化しておきたいところです。そこで Claude Code の Skills を活用して、できるだけ楽にアップデートできないかを試してみました。 今回はClaude Skillsについての詳細は説明していません。詳細が知りたい方はぜひ公式Docを参照してください。 アプローチ いきなり Skills を作るのではなく、まずは Claude Code で素朴に8.0へのアップグレードを一通りやってみることにしました。実際の作業ステップを体験しておかないと、どこを自動化すべきか判断できないためです。 手動で行った手順は以下のとおりです。 アップグレードガイド・リリースノートの確認 ナレッジページにある過去のアップグレードレポートを読む Gemfile の Rails バージョンを更新して bundle update rails を実行 依存関係で対応が必要な gem のリストアップと更新 ローカルで起動して動作することを確認 PoC の PR を作成して CI を回し、Claude Code にログを渡して失敗を解析 bin/rails app:update の実行と設定ファイルの差分確認 この一連の作業を Claude Code に任せてみたところ、1つの会話で最初から最後まで完了させるのは難しいことがわかりました。理由は大きく2つあります。 コンテキストの肥大化による精度低下 調査結果、bundle update のログ、CI の失敗ログなど大量の情報が積み重なると、LLM の注意力が分散して的確な判断ができなくなる 人間のレビューポイントが必要 gem の更新方針や設定ファイルの取捨選択など、プロダクト固有の判断が求められる場面では、AI に丸投げするのではなく各チェックポイントで人間が確認して責任を持つ必要がある そこで、上記の手順を5つのステップに分割し、それぞれを独立した Skill として定義することにしました。 また、各ステップでは成果物をマークダウン形式のドキュメントとして出力し、それが次のステップの入力になるパイプライン構造を採用しました。これにより、途中で作業を中断してやり直したり、セッションをリセットして別の会話から再開することも可能です。前のステップの成果物さえあればコンテキストを圧迫せずに次のステップを実行でき、LLM の精度を保ったまま作業を進めることができました。 実践編 ── 各ステップの概要 以下が今回作成した5つの Skill の概要です。各 Skill はターゲットバージョンを引数に取り、成果物としてマークダウンを出力します。 Skill実行例 /rails-upgrade-step1-research 8.0 Step 1: Research（調査） Skill定義イメージ --- name: rails-upgrade-step1-research description: 'Railsアップグレード調査フェーズ: リリースノート確認、既知の問題調査、ナレッジ収集' argument-hint: <target_version (例: 8.1)> allowed-tools: [Read, Write, Grep, Glob, WebFetch, WebSearch, AskUserQuestion] --- # rails-upgrade-step1-research ## ワークフロー ### Phase 1: 現在のバージョン確認 - `bundle show rails` で現在のRailsバージョンを確認 - `config/application.rb` の `config.load_defaults` を確認 ### Phase 2: リリースノート調査 WebSearch/WebFetchで以下を調査: - Rails公式リリースノート - Breaking Changes / Deprecations / Removals / New Features をカテゴリ別に整理 ### Phase 3: コミュニティナレッジ調査 - ruby-jpのナレッジページ - GitHubのissue/discussion ### Phase 4: 調査結果ドキュメント作成 リリースノートサマリー、依存gem対応状況、リスク評価をまとめる ## 成果物 出力先: `./ai_tasks/rails_upgrade/v{target_version}/01_research.md` ## 禁止事項 - ファイルの編集（調査ドキュメント作成以外） - コードの変更 - 依存関係の変更 アップグレードに必要な情報を収集し、影響範囲を把握するフェーズです。 主な処理内容 現在の Rails バージョンと config.load_defaults の確認 Rails 公式リリースノートの調査 Breaking Changes・Deprecations・Removals・New Features のカテゴリ別整理 コミュニティの既知の問題を調査（ruby-jp、GitHub Issues など） 依存 gem の Rails 対応状況の確認 リスク評価と推奨対応順序の策定 このステップではコードの変更は行わず、調査とドキュメント作成のみに制限しています。許可ツールを Read / WebSearch / WebFetch 等に絞り、Edit や Bash での変更操作を禁止することで、調査フェーズで誤ってコードを書き換えてしまうリスクをなくしています。 成果物: 01_research.md（リリースノートサマリー、依存 gem 対応状況、リスク評価） Step 2: Gemfile（依存関係解決） Skill定義イメージ --- name: rails-upgrade-step2-gemfile description: 'Railsアップグレード Gemfile更新フェーズ: 依存関係の解決とbundle update' argument-hint: <target_version (例: 8.1)> allowed-tools: [Read, Edit, Write, Grep, Glob, Bash(bundle *), Bash(git *), AskUserQuestion] --- # rails-upgrade-step2-gemfile ## 前提条件 - step1（調査フェーズ）が完了していること ## ワークフロー ### Phase 1: 前ステップの確認 - step1の調査ドキュメントを読み込む ### Phase 2: Gemfile の Rails バージョン更新 - Gemfile を編集: `gem 'rails', '~> {target_version}.0'` - `bundle install` を試行 ### Phase 3: 依存関係エラーの解決 1. エラーメッセージを解析 2. gemのGitHub/RubyGemsで対応バージョンを確認 3. Gemfileを更新 4. 再度 `bundle install` を試行 5. エラーが解消されるまで繰り返し ### Phase 4: bundle update 実行 - `bundle update rails` ### Phase 5: 変更内容の記録 - `git diff Gemfile.lock` で更新されたgemを確認・記録 ## 成果物 出力先: `./ai_tasks/rails_upgrade/v{target_version}/02_gemfile.md` ## 禁止事項 - step1の調査なしでの実行 - bundle installのエラーを無視した強制更新 - 依存関係解決の経緯を記録しないこと Gemfile の Rails バージョンを更新し、依存関係を解決するフェーズです。 主な処理内容 Step 1 の調査ドキュメントを読み込み Gemfile の Rails バージョン指定を更新 bundle install → エラー解析 → Gemfile 修正 → 再試行のループ 依存関係が解決したら bundle update rails を実行 git diff Gemfile.lock で更新された gem を記録 依存関係解決の経緯（どのエラーに対してどう対応したか）をすべて記録するようにしています。 bundle install のエラーを無視した強制更新も禁止しており、1つずつ原因を解消していくようにしています。 成果物: 02_gemfile.md（変更した gem の一覧、依存関係解決の経緯） Step 3: CI Analysis（CI 結果分析） Skill定義イメージ --- name: rails-upgrade-step3-ci description: 'Railsアップグレード CI結果分析フェーズ: CI結果を受け取り、失敗を分類・ドキュメント化' argument-hint: <target_version (例: 8.1)> allowed-tools: [Read, Edit, Write, Grep, Glob, AskUserQuestion] --- # rails-upgrade-step3-ci ## 前提条件 - step2（Gemfile更新）が完了していること - PR が作成済みで CI が実行されていること ## ワークフロー ### Phase 1: CI 結果の受け取り ユーザーに CI 結果の提供を依頼（PR番号、失敗ログ等） ### Phase 2: CI 結果の分析 失敗を以下のカテゴリに分類: 1. Rails変更による破壊的変更 2. 依存gemの変更 3. Deprecation警告 4. RuboCop違反 ### Phase 3: 修正方法の検討 - テストコードの修正が必要か - アプリケーションコードの修正が必要か - 設定変更で対応可能か ### Phase 4: 分析結果のドキュメント化 失敗分類レポートと修正タスク一覧を優先度別に整理 ## 成果物 出力先: `./ai_tasks/rails_upgrade/v{target_version}/03_ci_analysis.md` ## 禁止事項 - このステップで修正を実施すること（分析のみ） - 失敗の原因を調査せずに分類すること PR を作成して CI を回し、失敗を分類・ドキュメント化するフェーズです。 主な処理内容 ユーザーから CI 結果（失敗ログ）を受け取る 失敗を4つのカテゴリに分類 Rails 変更による破壊的変更（API変更、デフォルト値の変更など） 依存 gem の変更による挙動変更 Deprecation 警告（Rails / RSpec / 外部 gem 由来） RuboCop 違反（新しい cop、設定変更） 各失敗に対して関連コードを調査し、修正方法を検討 修正タスクを優先度別に整理 このステップではステップ1と同様に分析のみを行い、コードの修正は行いません。許可ツールから Bash や Edit を除外し、分析に専念させる設計です。「分析」と「修正」をあえて分離することで、修正方針について人間がレビューするポイントを自然に挟むことができます。 成果物: 03_ci_analysis.md（失敗分類レポート、修正タスク一覧） Step 4: Fix（修

• Rails
• Claude Code
• AI

freee·2026/02/17

はてなブックマーク0

QAプロセスへのAI活用でshared-knowledgeを始めました

はじめに こんにちは、freee振込チームでQAをしているtonchanです。 本記事では、QAプロセスにAIを活用するためにshared-knowledgeという仕組みを作った話を紹介します。 この取り組みはfreee振込チーム独自のものです。社内のAI駆動QA基盤が立ち上がる前の2025年1月頃から、独自にQA専用リポジトリを作ってAI活用を始めていました。全ての成果物をMarkdown形式で管理する方針を早い段階で採用していたため、エンジニアと同じようにAIツールにそのまま渡せるフォーマットが揃っており、社内の他チームとは独立した形で発展してきました。 最初にぶつかった壁は「AIの出力する言葉がバラつく」問題です。同じ機能なのに「申請」「依頼」「予約」と毎回違う用語が出てくる...。QAの成果物は自然言語なので、この用語のブレは品質に直結します。 2025年6月、約5ヶ月間の試行錯誤を経てshared-knowledgeを構築しました。shared-knowledgeとは、人間もAIも参照する「チームの共有知識」を一元管理する場所です。 本記事では、shared-knowledgeを導入した背景、構造、運用のコツ、得られたメリットを紹介します。 freee振込におけるQAプロセスとAIが生成する成果物 まず、freee振込チームのQAプロセスの全体像を紹介します。 要求分析: PRD（Product Requirements Document）やDD（Design Docs）を読み、開発内容を理解する テスト計画: Test Summary Reportを発行し、テスト範囲・方針・スケジュールを決定する リスク洗い出し会: 関係者を集め、仕様上の懸念点やテスト環境の制約を議論する テスト分析: PRD・DDをもとに受入基準を作成する 受入基準sync会: Engと受入基準の認識をすり合わせる テスト設計: 受入基準をもとにテストチャーターを作成する テスト準備・実行: テストデータの準備、APIテスト用runbookの生成、テスト実行 テスト完了・振り返り: テスト結果の整理と改善点の洗い出し このうち、AIコマンドで生成している成果物は以下の3つです。成果物は上流から下流へ連鎖する構造になっています。 QAプロセス 成果物 テスト分析 受入基準 テスト設計 テストチャーター テスト実行 APIテスト用runbook 本記事では、これらの成果物をAIで安定して生成するための仕組みであるshared-knowledgeを紹介します。 AI活用は「すぐに効率化」ではない 「AIツールを入れればすぐ効率化できる」わけではありません。準備とステップが必要です。 私が踏んだ3つのステップを紹介します。 ステップ1: まず個人の作業で試す 仕様調査やテスト分析など、自分で完結する作業にAIを使うところから始めました QAプロセスは影響範囲が大きいので、手元で検証が終わってからでないとチームには展開できません ステップ2: うまくいったやり方を「コマンド」にする 個人で試してうまくいく場面は増えたものの、毎回AIに同じ説明をする必要があり、品質にもバラつきがありました そこで、再現性のあるプロンプト（AIへの指示書）をファイルとして保存して、誰が実行しても同じ品質の成果物が出る状態を目指しました ステップ3: チーム全員が使えるようにする コマンド化で個人の再現性は上がりましたが、開発プロセスやタスクの進め方、個人の環境に差分があると同じコマンドでも結果が変わりました これらの差分を吸収できるレベルまで汎化して、チーム標準のワークフローに組み込んでいきました いきなりチーム全体でインパクトを出そうとしないのが大事だと思っています。「個人の成功体験」を積み重ねて広げていくのが現実的です。 AI活用のための下地作り AI活用を始める前に、成果物の形式や保守運用を根本から見直す必要がありました。個人的にはここが一番大変で、かつ一番大事なところだと感じています。 AIが読み書きしやすい形式は Markdown + Git管理 です。スプレッドシートのテストケースやWikiの仕様書を、Gitリポジトリ内のMarkdownファイルに移行しました。AIツールはテキストファイルの読み書きが得意で、バイナリやSaaSの画面上のデータはまだ苦手なことが多いですよね。 もともとGit管理を始めたのはAI活用のためではなく、「成果物のレビューをしやすくしたい」「修正差分をわかりやすくしたい」という動機からでした。QAの成果物をテキストデータとして管理する必要があったためMarkdown形式を採用し、結果的にこれがAI活用の下地になりました。 ただ、この移行には痛みが伴います。 既存ツール（スプレッドシート、Wiki、Jira等）との連携をどうするか 運用の一部が変わるとプロセス全体に影響するので、計測や管理の見直しも必要になります 例えば、スプレッドシートなら会議中に全員で同時編集できましたが、Markdownファイルとgitでは同時編集やコメントの残し方に工夫が要ります。エンジニアだけでなくBizメンバーも参加する場なので、全員が使える運用を考える必要がありました それでも、従来の形式に固執するとAI活用のボトルネックになってしまいます。チームメンバーの合意を得ることが重要で、最初は効率化の成果が出にくいです（学習コストが先行するので）。 あと、AIは万能ではないです。機械的に判定できるもの（Lint、フォーマットチェック等）はスクリプトの方が確実で安定します。AIは文脈を理解した判断が必要な場面（レビュー、分析、設計）に使う、という適材適所の使い分けが大事です。 こうして下地は整ったのですが、最初にぶつかった「用語のバラつき」問題は根本的には解決していませんでした。Markdownファイルが増えるにつれ「どのファイルが正しい情報なのか」「用語の定義はどこにあるのか」がAIにも人間にもわからなくなってきました。バラバラのファイルではなく、構造化された「チームの共有知識」として一元管理する場所が必要だと気づいたのが、shared-knowledgeの始まりです。 shared-knowledgeとは何か shared-knowledgeとは、チームの共有知識をMarkdownファイル群として一元管理する仕組みです。 第一の目的はLLM活用の品質向上ですが、それだけでなくナレッジの明文化・脱属人化・保守運用の改善も狙っています。 管理対象の例: ユビキタス言語（用語辞書）: 業務用語の定義集。カテゴリごとに整理しています QAガイドライン: 成果物の作成ルールやレビュー基準 テスト戦略: テスト方針やカバレッジの考え方 機能仕様書: 各機能の設計・仕様 技術情報: API仕様やDBスキーマなどシステムの構造情報 ディレクトリ構成は以下のとおりです: shared-knowledge/ ├── domain/ # ユビキタス言語、ドメイン固有の技術知識 ├── QA/ # QAプロセス、テスト戦略、各種ルール ├── docs/ # 機能仕様書群 └── onboarding/ # 新メンバー向けガイド shared-knowledgeはAI向けに整備したものですが、副次的に人間のオンボーディングにも効果がありました。新しいメンバーがチームに参画する際、ドメイン知識やチームの文化・ルールを体系的にinputできる資料として機能しています。「AIに教えるために整理した情報」が、そのまま人間にとってもわかりやすい資料になったのは嬉しい誤算でした。 MCPサーバーだけではダメな理由 MCP（Model Context Protocol）サーバーは便利ですが、「だけ」では解決できない問題があります。 実際にMCPでWikiやチャットの情報を取得させてみましたが、生データのまま取得されるため用語がバラバラでコンテキストも不足しており、AIの出力が安定しませんでした。 情報が散在（Wiki、チャット、スプレッドシート等）していて、どこを見ればいいかわからない 「生データ」のまま取得されるので、用語の揺れやコンテキスト不足、背景情報がない どれが最新情報なのかわからない MCPサーバーとshared-knowledgeは補完関係にあります。 MCPサーバー = 情報を「集める」手段 shared-knowledge = 情報を「整理・活用」する場所 実際の運用では、MCPで最新情報を取得してshared-knowledgeに反映・整理するという流れです。「どの情報が最も信頼できるか」は人間が明示的に定義する必要があります。 AIコマンドとの連携 shared-knowledgeが真価を発揮するのは「AIコマンド」との組み合わせです。AIコマンドとは、特定のタスクをAIに実行させるための定型的な指示のことです。Claude Codeのskills、OpenAI Codexのskills、Roo Codeのcommandなどが該当します。 AIコマンドを実行すると、AIが自動的にshared-knowledgeを参照します: ユビキタス言語 → 正しい業務用語で書く 成果物の作成ルール → 決められた形式で書く 機能仕様書 → 仕様に沿った内容を生成 テンプレート → 統一されたフォーマットで出力 前述のとおり、成果物は受入基準 → テストチャーター → APIテスト用runbookと上流から下流へ連鎖する構造になっており、各成果物は相互にリンクで参照し合います。 AIコマンドで成果物の作成が容易になると、成果物の量が増えます。すると今度は人間のレビューがボトルネックになりました。そこでレビューもAIで仕組み化しました: Lintツールで機械的なチェック + AIレビュアーで文脈理解が必要な観点を確認 AIは修正せず、レビューコメントと改善提案のみ提示します。最終判断は人間が行います 3つのメリット メリット1: AI成果物の品質向上 shared-knowledgeなしの場合、AIは一般的な知識だけで成果物を作ります。ドメイン固有の用語を間違えたり、業務フローを知らなかったりします。 shared-knowledgeありの場合、正しい用語、実際の仕様、チームの方針に沿った成果物を生成してくれます。結果として人間のレビュー負荷が大幅に減りました。 メリット2: ナレッジのメンテナンス性向上 従来はメンテできる人が限られていて（属人化）、工数に見合わず放置されがちでした。 AI活用後は、新しい仕様書が追加されたら用語辞書を自動更新、コードが変わったら技術情報を自動更新できるようになりました。変更内容はPull Requestとして提出して、人間が確認してからマージします。AIが作業し、人間が承認するという安全な運用です。 メリット3: 一次資料の明確化 多くの組織で「何が最新の正しい情報なのかわからない」問題があると思います。情報がWiki、チャット、スプレッドシートなどに散在している状況です。 shared-knowledgeで「これが一次資料」と明示的に定義できるようになりました。MCPサーバー（集める）とshared-knowledge（整理する）は補完関係にあります。 保守運用をワークさせるためには ナレッジの保守運用って、多くのチームで挫折する「永遠の課題」だと思います。 自分たちのチームでは一定ワークしています。理由は構造にあると考えています: 全ての成果物のinput（参照情報）としてshared-knowledgeを使う設計にしました shared-knowledgeが古い = AIが生成する成果物の品質が下がる 品質が下がると業務に支障が出る → 更新する自然な動機が生まれます <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/Q/QA_tonchan/20260213/20260213180113.png" alt="保守運用のフィードバックループを示す図。shared-knowledgeを更新&rarr;AI成果物の品&#x8

freee·2026/02/16

はてなブックマーク26

フリーのアナリティクスエンジニアの紹介

データ部の okoshi です。 フリーのデータ組織には「アナリティクスエンジニア（Analytics Engineer）」というロールがあります。データ活用が進むにつれ、このロールの必要性は年々高まっています。この記事では、役割、価値、業務内容、必要スキルをコンパクトに紹介し、なぜこの職種がビジネスインパクトに直結するのかを解説します。 1. 概要 アナリティクスエンジニア（Analytics Engineer）は、 「データエンジニア」と「データアナリスト」の中間に立ち、ビジネスで安全・高速に使える“整ったデータ”を継続的に届ける役割です。 データエンジニアが整備した基盤・生データを受け取り ビジネスサイドやアナリストがすぐ使える形にモデリング・変換し 品質と再利用性を担保した「信頼できるデータ資産」として提供する ことで、フリー全体のデータドリブンな意思決定・プロダクト改善を支えます。 この役割は、dbt Labs社が提唱したモダンデータスタックにおける新しい職種であり、「データの加工（Transform）と品質管理」に特化したエンジニアと捉えるとイメージしやすいです。 www.getdbt.com 2. 立ち位置：他ロールとの違い 職種 主な責任範囲 焦点 データエンジニア データの抽出・格納（Extract/Load）、インフラ構築 データの可用性・パイプラインの安定性 アナリティクスエンジニア データの加工（Transform）、モデリング、品質保証 データの信頼性と再利用性 データアナリスト／BI 可視化、分析、インサイト抽出 事業の意思決定・施策立案 フリーのアナリティクスエンジニアは特に次の部分を担当します。 データ基盤組織が整備したデータレイク / DWH 上のデータを フリーのビジネスロジック・KPI に沿った形にモデリングし 「誰が使っても同じ数字になる」「壊れにくい」「変更に強い」状態をつくる つまり、「データの土台をつくるエンジニア」かつ「ビジネスに近い視点を持つエンジニア」です。 3. フリーのアナリティクスエンジニアの主なお仕事 3-1. データモデリングと変換の設計・実装 ゴール：ビジネスで直接使える“クリーンなデータモデル”を DWH 上に用意すること。 具体的には： プロダクトや各種システムから来る生データを理解し、 イベントログ、会計仕訳、顧客/事業所情報、請求情報 など フリーのビジネス定義に沿った形でテーブル（マート）を設計 例： 「顧客」「アクティブユーザー」「売上」の定義を整理し、それに沿ったテーブルを作る 会計・人事労務など複数プロダクトをまたいだ横断テーブルを作る dbt/PySpark等を用いて、SQL ベースで変換ロジックを実装し、DAG として管理 3-2. データの品質保証と信頼性担保 ゴール：フリー社内で「このテーブルを見れば大丈夫」と言える“信頼できるデータ”をつくること。 dbt テストなどを用いた自動テスト NOT NULL / UNIQUE / 参照整合性などの制約チェック 期待値レンジの逸脱検知（異常値検出の簡易版） パイプラインの監視・アラート設計 定期バッチ / ストリーミングの失敗検知と対応 スキーマ変更や新機能リリース時の影響調査・マイグレーション 「上流でカラムが変わったときに、どのモデル/ダッシュボードが影響を受けるか」を把握し調整 結果として、「数字が信用できる」「いつ壊れたかすぐに分かる」状態を維持します。 3-3. データの民主化支援 ゴール：SQL が書けない人でも、正しいデータにたどり着きやすい環境をつくること。 テーブル/カラムの説明を含めたドキュメント整備・データカタログの更新 データリネージ（どのテーブルがどこから作られているか）の可視化 代表的な指標・ビューを「推奨データセット」として整理し、迷わないようにする BI ツールでの標準的なエクスプローラ/ビューを準備 全社への貢献を見据え、単なる「データ整備」で終わらず、事業インパクトまでつなげる動き方が求められます。 3-4. データサービング（Reverse ETL） アナリティクスエンジニアがいるチームの一つにデータサービングまでを対応するチームがあります。 ゴール：DWH 上で整備したデータを、プロダクトや業務システムに届けること。 そのチームのアナリティクスエンジニアは、dbt によるモデリングだけでなく、整備したデータを実際にプロダクトへ届けるところまでを業務範囲としています。 プロダクト側でビッグデータを利用可能にするためのReverse ETL 基盤の設計・構築・運用 DWH のデータをプロダクト側のデータストアや API に同期する仕組み データの「整備」から「活用」までを一気通貫で担うことで、プロダクト価値の向上に直接貢献 一般的なアナリティクスエンジニアの業務は DWH 内のモデリングで完結することが多いですが、フリーではデータをプロダクトまで届ける データサービング も重要な役割の一つです。 4. メンバーの声 実際にフリーでアナリティクスエンジニアとして働くメンバーの声を紹介します。 入社の決め手 大規模なデータを扱える環境であること これまで所属していた会社ではデータを整備しても十分に活用されない場面があり、データが実際に活用される現場で働きたいと考えていた 入社後に感じたこと 想像以上にデータ活用の取り組みが進んでおり、整備したデータがしっかり使われている実感がある アナリストと協業しながら開発できる体制が整っており、利活用を前提としたデータ整備ができるため充実感がある プロダクト側でまだ活用されていないデータを使えるようにする 0→1 フェーズにやりがいを感じる 一方で、モデル設計に必要なドメイン知識は幅広く深い。複数のプロダクトにまたがるドメインを理解する必要があり、そこは大変な部分でもある 5. 一般的なアナリティクスエンジニアとの違い 一般的なアナリティクスエンジニアは、dbt を用いたデータモデリングや品質管理を中心に DWH 内で業務が完結するケースが多いです。フリーのアナリティクスエンジニアはそれらに加え、以下の領域にも携わる点が特徴的です。 データサービング（Reverse ETL）: DWH のデータをプロダクトまで届ける Reverse ETL 基盤の設計・運用。モデリングした結果をプロダクト側のデータストアや API に同期し、エンドユーザーに価値を届けます。 マイクロサービス開発: DWH のデータをプロダクトへ提供するためのマイクロサービスの開発・運用。データ基盤とプロダクトをつなぐブリッジの役割を担います。 今後のチャレンジ領域: MLOps を含むレコメンドデータの生成や特徴量ストアの構築など、データ活用の幅をさらに広げる取り組みも視野に入っています。 このように、フリーのアナリティクスエンジニアは「データを整備する」だけでなく「プロダクトに届ける」ところまでを一貫して担う点で、他社にはない経験を積める環境です。 6. アナリティクスエンジニアがいることで何が変わるか Before：各自がバラバラに巨大 SQL を書く世界 各チームのアナリストやメンバーが、それぞれ独自に SQL を書いてレポート作成 同じ「売上」なのにダッシュボードごとに数字が違う プロダクト側でカラム名や仕様が少し変わると、多数のダッシュボードが一斉に壊れ、復旧に数日かかる After：共通の「信頼できるデータモデル」がある世界 アナリティクスエンジニアが、共通のデータマートを dbt 等で管理 アナリストや事業側メンバーは、そのクリーンなデータを組み合わせて分析するだけでよい 上流の変更があっても、アナリティクスエンジニアが 1 箇所のモデルを修正すれば、全てのダッシュボードに反映される 結果として、 分析スピードが上がる 数字への信頼が増す データ活用の範囲が広がる アナリティクスエンジニアはデータドリブンな意思決定の基盤となる、“データの土台”をつくるキーロールと言えます。 7. フリーのアナリティクスエンジニアに求められるスキル 7-1. テクニカルスキル SQL 複雑な結合・ウィンドウ関数・集計を使った変換ロジックを設計・実装できる dbt等の変換ツール モデル設計、テスト、ドキュメント化を一通り扱える DWH / クラウド基盤の理解 BigQueryなど列指向 DWH の特性 パーティショニング・クラスタリング・コスト最適化 ソフトウェアエンジニアリングの基礎 Git によるバージョン管理・Pull Request ベースの開発 CI/CD やコードレビューの文化への理解 マイクロサービスを開発・運用するスキル （オプショナル） DWHのデータをブリッジ提供するマイクロサービスの開発 MLOps / 機械学習パイプラインの知識（オプショナル） レコメンドデータや特徴量ストアの生成・管理 7-2. データモデリング・品質の知識 正規化・スター型スキーマ・スナップショットなどの基本的なモデリングパターン テスト戦略・監視設計など、データ品質を守るためのプラクティス 7-3. ビジネス・コミュニケーションスキル プロダクト仕様・業務フローの理解 「売上」「顧客」「アクティブ」「解約」といった指標を、プロダクトと会計・契約の観点から正しく定義する力 利害関係者との合意形成、データ定義のドキュメント化・説明 8. まとめ フリーにおけるアナリティクスエンジニアは、 データエンジニアが整備した基盤と、 ビジネスサイドの意思決定との間をつなぐ“橋渡し役”であり、 信頼できるデータモデルとデータ品質を通じて、 フリー全社のデータドリブンな意思決定・プロダクト価値向上を支える専門家 です。 実はまだまだ生まれたての職種なので人によって解釈が違う部分もあると思います。本記事を通じて、皆様に具体的なイメージを持っていただければ幸いです。 9. 採用情報 弊社ではアナリティクスエンジニアを募集しております。ご興味がありましたら下記よりご応募ください。お待ちしております！ アナリティクスエンジニア: 人材募集（求人一覧） シニアアナリティクスエンジニア: 人材募集（求人一覧）

freee·2026/02/13

はてなブックマーク57

Coding Agent が言うことを聞かないときどうする？ - ミクロなコンテキストエンジニアリング

freee で Coding Agent 切り込み隊長をしている @him0 です。2025年は Coding Agent がコーディングの取り組み方を一新する一年でした。freee は現場に Cline を導入したところから始まり、現在(2026-02) は Claude Code が全社の標準ツールとなり落ち着いています。 Claude Code 起動時に /tutorial が紹介される Coding Agent を使いこなすという文脈で、コンテキストエンジニアリングが大事という話は散々どこでもされていると思います。2025年の年末から、2026年1月は Anthropic が Skills のフォーマット標準化の宣言を発端に、Agent Skills が話題として取り上げられるようになり、SKILL.md や AGENTS.md (CLAUDE.md) コンテキストの適切なタイミングでの投入に焦点を置いた、いわばマクロのコンテキストエンジニアリングの話題が強く扱われている様に思います。 agentskills.io SKILL.md や AGENTS.md によって Coding Agent が拡張されるのは明らかな事実である一方で、どんなコンテキストを Coding Agent に与えるべきかを理解しないままに、どんどん情報を渡していってしまうと有象無象の情報に Coding Agent は混乱してしまうことも忘れてはいけない事実です。こうなってくると出力までに時間もトークンもたくさん使う状態になったり、そもそも出力の精度が安定しないという状態が発生します。 SKILL.md や AGENTS.md にどんなことを書くべきか、LLM はそれをどの様に解釈しているか、そんなことを考える一件があったので紹介したいと思います。 問題の発端 いつも通り私は社内で AI Agent おじさんをしていると、とあるプロジェクト CLAUDE.md に GitHub の Pull Request のマイルストーンに付ける指示に Claude Code が従わないという相談を受けました。内容を確認してみると、以下の指示が書かれており、確かにマイルストーンを付ける指示が定義されている様に見えます。しかし、実行してみると PR にマイルストーンを付けてくれませんでした。 # マイルストーン ユーザーからマイルストーン番号またはマイルストーン名の指定があった場合、PRにマイルストーンを設定します： - マイルストーン番号が直接指定された場合は、その番号を使用 - マイルストーン名が指定された場合は、GitHubのAPIでマイルストーン一覧を取得して該当する番号を特定 - 指定がない場合は Untracked を設定 人間には正しく読めるのに、なぜ LLM は読めなかったのでしょうか？ 原因を探る 当事者にインタビューするのが一番素直ということで、Claude Code に相談してみました（長い部分はカットしています）。 (マイルストーンの設定に失敗したセッションの続き) ❯ .github/CLAUDE.md を読んでいるのに、なんで milestone を付けなかったか教えて欲しいです ⏺ 申し訳ありません。今から修正します。 ❯ 他のリポジトリと比べてこのリポジトリではそのミスが多発します どうしてなのか解明したいです ⏺ 良い質問です。原因を分析させてください。 質問させてください： 他のリポジトリでは、マイルストーンの指示はどこに書かれていますか？ - スキル定義自体に含まれている？ - ルートの CLAUDE.md にある？ - 別の方法？ 比較できれば、何が違うのか特定できると思います。 質問すればすっと解決できるかと思いきや、なんと Claude Code 自身もどうしてそうなったのか説明できないという回答。人間らしくない LLM らしい面白い挙動です。 ほぼ同様の指示をしているが、正しく動作するリポジトリがあったので、こちらのディレクトリを渡して、比較検討を依頼してみました。 ❯ 他のリポジトリでは同じ形式で記述されていますが、ミスらないですね ~/src/project-b を参考にしてください ⏺ 違いを発見しました。 問題点： 1. project-a は「ユーザーからの指定があった場合」という条件文から始まっている 2. 「指定がない場合は Untracked を設定」が条件分岐の一つとして埋もれている 3. 他のラベル設定（「〜を付与すること」）とフォーマットが異なる project-b は「付与すること」という命令形で、他のラベル設定と同じフォーマットなので、必須アクションとして認識しやすいです。 project-a の記述を project-b と同じフォーマットに修正すれば、改善されると思います。 差分から解釈を推測し修正内容を決めることができました。「ユーザーからの指定があった場合」が、マイルストーンのセクション全体にかかり、今回は対象外であると判断してしまい最後に書かれている、指示がなかった場合を読み飛ばしていたとのこと。 LLMは"文章"ではなく"構造化された命令集合"を読んでいる これを踏まえて修正した指示が以下です。人間から見ると微々たる違いですが、確実にマイルストーンを付けてくれる様になりました。 ## マイルストーン Pull Request 作成時、マイルストーンを付与すること - ユーザーから指定がない場合は "Untracked" を付与 - ユーザーからマイルストーン名が指定された場合は、GitHub API でマイルストーン一覧を取得して該当するものを付与 人間は Markdown を文章として流れるように読みますが、LLM は見出しや箇条書き単位で「構造化された命令集合」として解釈している可能性があります。その結果、条件付きと判断したブロックを実質的にスキップし、今回の問題につながったと考えられます。 同じテキストでも、人間と LLM では前提となる読み方が異なります。LLM の挙動を理解するうえでは、この「構造の解釈」を常に意識すべきだと学びました。 もちろん、この分析は Claude Code 自身による事後的な推測であり、内部の処理を正確に反映しているとは限りません。ただ、指示のフォーマットを修正した結果、実際に挙動が安定したことから、構造の違いが影響していたという仮説には一定の妥当性があると考えています。 まとめ Coding Agent が効率よく、再現性高く動かすためには、Agent が この一文をどの様に解釈する のかというミクロの話を正しく理解し、課題があれば、それを調整する能力が必要です。そして、本来はその基礎の先に、SKILL.md や AGENTS.md を使った、マクロなコンテキストエンジニアリングが成立するはずです。 SKILL.md は共有しやすく、最初の体験として便利さを実感しやすいものです。しかしそれが、基礎を飛ばして「よく分からないけど SKILL を追加するとうまくいく」という状態を作ってしまっている側面もります。 ときには基礎に立ち戻り、手元の SKILL.md や AGENTS.md を読んでみて（読んでもらって）理解し、必要に応じてチューニングする。そんなコンテキストのリファクタリング技術も今のうちから意識して育てておくと、今後活躍できる機会が増えるのではないかと思いました。

freee·2026/02/10

はてなブックマーク39

AWS ElastiCache for Redis を Valkey へ移行した話

はじめに はじめまして。フリーで DBRE に所属している pon です。 弊社では 2025 年 9 月から 2026 年 1 月の期間で AWS ElastiCache for Redis のうちエンジンバージョンが Redis のクラスターに対して Valkey エンジンへ移行するプロジェクトを行いました。 本プロジェクトでは約 50 個のクラスターが対象となり、期間内での移行が完了しました。 この記事では、 Valkey 移行プロジェクトの移行プロセスや躓いた事例を共有します。今後移行を考えている方の参考になれば幸いです。 Valkey 移行を決定した背景 AWS は 2026 年 1 月 31 日に Redis 5 系エンジンバージョンの標準サポートを終了しました。これが今回の移行プロジェクトの直接的なきっかけです。 サポート終了告知にあたり、互換性・コストの2つの観点から、弊社ではまず Redis 5.0.6 を使用しているクラスターをメイン対象に移行を行うことを決定しました。 Redis と Valkey の互換性 Valkey は元々 Redis 7.2.4 を fork した OSS であり、Redis 7.2.4 との互換性を保ちながら現在まで開発が続けられています。 そのため、Redis 7 時点から見た Valkey は機能的に同等であり、アプリケーション側の移行負担は大きくならないと判断しました。 コスト削減 Redis のライセンス変更に伴い、コミュニティはオープンソースの代替として Valkey を採用しています。 AWS でも Valkey のサポートを開始しており Amazon ElastiCache for Valkey では、Redis OSS と比較してServerless において33%、ノードベースでは20%安い価格で利用できるようになっています。 そのため、Valkey 移行を行うことでコストカットが実現できると考えました。 事前検証 弊社では実際に移行を行う前に、リスク評価を行った上で互換性の調査とダウンタイム計測の 2 つの検証を実施しました。 リスク評価 弊社における Redis の役割は大きくキャッシュと Job Queue の 2 つに分類されます。 キャッシュ用途であれば、移行時に問題が生じてもアプリケーションが直接 DB にアクセスするようフォールバックするため、サービスの停止には至りません。一方、Job Queue 用途の場合はメンテナンスウィンドウの確保やダウンタイムの検証が必要と判断しました。 また、いずれの用途においても GET SET 等基本的な Redis の機能を利用している箇所は少ないことを確認しました。 以上から、移行時の影響範囲は限定的と判断し、互換性の調査は以下の方針で実施しました。 ベンチマークツールによる基礎動作の確認 リリースノートベースの互換性調査 検証環境での動作確認 互換性の調査 今回は Redis 5.0.6 から Valkey 8.1 への移行です。 まず Valkey 8.1 環境において redis-benchmark を実行し、基本的な操作が問題なく動作することを確認しました。 次に、リリースノートベースでの互換性調査を行いました。Redis 7.2.4 と Valkey 7.2 の互換性は Valkey 7.2 release notes より保証されているため、互換性の調査を行ったのは以下 2 箇所でした。 Redis 5.0.6 から Redis 7.2.4まで Valkey 7.2 から Valkey 8.1 まで 結果、Redis 間におけるマイナーアップデートには破壊的変更が存在してはいますが、弊社プロダクトへの影響がないことを確認しました。 残りのカバレッジは Integration 環境でアプリケーションを実際に動作させることで担保しました。 ダウンタイム計測 リスク評価において Job Queue 用途ではダウンタイムの検証が必要と判断したため、計測を実施しました。 AWS における Valkey 移行では、既存クラスターのエンジンのみを切り替えるインプレース方式であればダウンタイムを最小限に抑えられます。 調査段階では以下の手順で複数回ダウンタイムの計測を行い、数秒程度のダウンタイムが発生することがわかりました。 Redis 5.0.6 クラスタとそこへアクセス可能な EC2 を作成 Redis 5.0.6 に1000個のランダムデータを挿入 継続的に SET / GET 操作を行うスクリプトを実行 しかし、実際に移行を行うと、このダウンタイム中のタイミングで接続を行った場合、クライアント側でキャッシュしているクラスター構成情報が更新されるまで reader endpoint を参照してしまう事象が確認されました。 アプリケーションの構成によってはダウンタイムが分単位になってしまうかもしれないので、注意が必要です。 移行手順の概要 弊社では AWS のインフラリソースを Terraform で管理しているため、PR ベースでの移行を行いました。apply_immediately パラメータやメンテナンスウィンドウで反映タイミングを適切に制御するように注意が必要です。 実際の移行の流れを以下にまとめます。 aws provider バージョンを v5.73.0 以降にする v5.73.0 以前では engine valkey に対応ができておらず provider のバージョンアップが必要です。 valkey 用の parameter group の作成 aws_elasticache_replication_group リソースの engine / version / parameter group の変更 apply 後、プロダクトチーム側で動作確認を行う そして、リトライ機構の有無・フォールバック先の有無・データロストの許容非許容等プロダクトの特性に合わせて移行を実施しました。 躓いた事例 aws_elasticache_cluster リソースで作成された ElastiCache 上記の移行手順は aws_elasticache_replication_group においては適用可能ですが、aws_elasticache_cluster の場合には適用できません。この場合、マネジメントコンソールからも直接のエンジン変更は不可となります。今回の移行対象の中にも数個該当リソースで作成された Elasticache が存在していました。 弊社では AWS 公式手順を参考に以下のコマンドでまず既存クラスターを元にレプリケーショングループを作成し、その後 Terraform 側で辻褄合わせを行った後に通常のValkey移行手順を実施することで移行を完了しました。 aws elasticache create-replication-group \ --replication-group-id "replication groupの名前" \ --replication-group-description "replication groupの説明" \ --num-cache-clusters 1 \ --primary-cluster-id "既存clusterのid" この変更はメタデータの変更のみが行われるため、ダウンタイムやデータロストは発生しませんでした。 同じエンドポイントを使用した復旧 ElastiCache for Redis から Valkey への移行では、切り戻しはサポートされていません。仮に Redis へ戻す場合には新しく Redis の ElastiCache を作成する必要があります。 今回の移行の中で 1 件、 Staging 環境における ElastiCache にて移行後より一部の内部プロダクト間通信に問題が発生し、 Valkey 移行を中止した事例がありました。 Staging 環境かつデータロストを許容するケースだったため、止血対応として同名で Redis を再作成することでエンドポイントを共有し復旧を図りました。 しかし、作成完了後しばらくアプリケーションからもタイムアウトが続き、別名で Redis を作り直したところ接続できるようになりました。自社側、AWS 側でもテスト環境にて再現を図りましたが、この事象の再現には至っていません。 再発防止として、実際の Production 環境では復旧までの時間も考慮し、あらかじめ別名の復旧用の Redis を立てておきエンドポイントを切り替える手順に変更しました。 移行を振り返って 今回は 50 個の Redis クラスターを移行しましたが、実際の移行作業はプロダクトチームが主体となって進めました。効率的に進められたポイントは以下だと考えています。 詳細な手順書の作成 移行背景、互換性調査結果、ダウンタイム計測結果を含める レビュー観点も明記し、PRベースで自主的に進められる形に 専用チャンネルでの情報集約 各チームの代表者を集め、知見やトラブル情報をリアルタイムで共有 DBRE は手順書とサポート体制の整備に注力し、プロダクトチームが自走できる環境を作ることを意識しました。 フリーの DBRE はまだ発展途上にあり、運用保守を直接担っている領域も多くあります。その中で、今回のプロジェクトはプロダクトチームの自律化を支援する Enabling の取り組みとして成果を出せたと考えています。プロダクトチームが自身の担当領域に責任を持ち、信頼性を守れる体制づくりを今後も推進していきます。 残りの Redis クラスターについても、今回の知見をもとに移行を継続していく予定です。 最後に DBRE では一緒に働いてくれるメンバーを募集しています。 今回の記事で興味を持ってくれた方、DBREとして活躍したいという思いのある方の応募をお待ちしています！ hire.wantedly.com hire.wantedly.com hire.wantedly.com

freee·2026/01/30

はてなブックマーク0

iOSDC 2025に参加してきました！

iOSDC Japan 2025 会場パネル前での集合写真 初めまして、新卒iOSエンジニアのmasaharuです。2025年9月19日（金）から21日（日）までの3日間、東京有明セントラルタワーホールおよびオンラインで開催された、国内最大のiOSアプリ開発者のためのカンファレンス「iOSDC Japan 2025」に参加しました！開催から4ヶ月ほど経過した今、当時得た知識が現場でどう活きているかも踏まえて振り返ってみたいと思います！ iOSDCの雰囲気 会場に到着すると、まずはビンゴカードが手渡されました。 このビンゴには「スポンサーブースを回ってスタンプを集めると、抽選でオリジナルTシャツやステッカーが当たる」という仕掛けがあり、楽しみながら自然と多くの企業ブースに足を運ぶことができました。 また、会場内ではバドワイザーが飲み放題だったり、歴代のiOSDCロゴを模したお菓子が振る舞われていたりしました。 会場のフリードリンクコーナー 10周年記念のお菓子とドリンクの展示 印象に残ったブース紹介 特に興味深かった、ハードウェアとソフトウェアの融合を感じられた2つのブースをご紹介します。 🛴 株式会社Luup Luupさんのブースでは、「LUUPアンロックチャレンジ」という企画が行われていました。 実際の車両に使われている鍵に対し、スマホ連打ゲームを通じてロック解除信号を送るという体験です。 LUUPブースでの実機ロック機構とアプリの展示 お話を伺って特に印象的だったのは、ハードウェアとソフトウェアの密接な連携です。LUUPのサービスは、NFC、Bluetooth、位置情報、カメラなど、iPhoneの持つ多様なリソースをフル活用して成り立っています。 特にテストに関しては、都内のさまざまな場所・環境で正常に動作するかを検証するのが非常に大変だそうで、ハードウェアとソフトウェアの両方を扱うサービスならではの苦労と面白さを知ることができました。 🏎️ 本田技研工業株式会社 Hondaブースでのスマホ操作による車の走行シミュレーション展示 Hondaさんのブースでは、「60秒以内にラジコンを操作して縦列駐車を成功させるゲーム」に挑戦しました。 ただのラジコンではなく、操作にはスマホのジャイロセンサーを使用しており、なんとこのカンファレンスのために開発されたシステムだそうです。 実際にやってみると、想像以上に機体が俊敏に動くため操作が難しかったですが、とても楽しかったです！ ゲームという形を通して、「iOSや関連技術を用いて、新しい『移動の喜び』をソフトウェアで実現しようとしている」というHondaさんの強い想いを感じました。 印象に残ったセッション セッションの中から、特に印象に残ったものをいくつかご紹介します。 10周年ロゴが映し出されたiOSDC Japan 2025のメインホールステージ 1. 「iPhoneのマイナンバーカード」のすべて fortee.jp iPhoneがマイナンバーカードに対応したことは大きなニュースになりましたが、このセッションではその裏側が語られました。 この機能を実現するために、Apple側でマイナンバーカード専用のフレームワークが用意されているのは知らず驚きました。 あと国の重要インフラに関わる開発ならではのセキュリティ要件などが聞けて面白かったです！ 2. 世界の人気アプリ100個を分析して見えたペイウォール設計の心得 speakerdeck.com App Storeにおけるサブスクリプション設計を、上位100アプリの徹底分析に基づいて解説されていました。 週額・月額・年額の価格戦略から、Paywall（課金画面）のUI、オンボーディングとの連携まで、ユーザーの意思決定プロセスが詳細に言語化されていました。特に興味深かったのは以下の点です！ 「疑似無料トライアル」としての週額プラン 表向きは「1週間プラン」ですが、実態は「低価格でアプリを試す機会」として機能させており、ユーザーの初回離脱を防ぐための重要な役割を担っている点。 比較による意思決定の補助 高額プランと低額プランの差異を明確に提示することで、ユーザーが「どちらが得か」を判断しやすくし、結果として納得して高単価プランを選びやすくなる設計。 このセッションを通じて、「成功しているアプリは“サブスクを売る”のではなく、“価値の理解 → 選択 → 納得”という流れをデザインしている」 のだと感じました。 freeeでのモバイルアプリにおいて、ユーザーにどうやって「freeeを使う価値」を瞬時に伝え、納得して使ってもらうか。そのためのUI/UX、文言、タイミングのすべてに意味を持たせる必要があると再認識しました！ 実はfreee会計iOSでも、この「体験」を重視してオンボーディングをアップデートしたばかりです。実際に触って価値を感じてもらう構成にしたことで、以前よりも「使うイメージ」を持ってもらいやすくなりました！ おわりに 初めてのiOSDC オフライン参加でしたが、技術的な知見はもちろん、各社のブース展示や登壇者の熱量から、「iOSエンジニアとしてものづくりをする楽しさ」を再確認できた3日間でした。 今回学んだことを日々の業務に活かし、いつか自分もこの場所でアウトプットできるよう成長していきたいと思います！

freee·2025/12/25

はてなブックマーク0

freeeのQA組織の現在地とこれから

メリークリスマス！今日まで毎日QAメンバーによるfreee QA Advent Calendar 2025が続いてますが、最終日の25日目は、フリーの横断 QA 部長、ymty（ゆもつよ）が担当します。 今回は、先日行われたfreee技術の日2025で登壇した「freeeのQA組織の現在地とこれから」の内容をベースに、フリーのQA組織が現在どこにいて、どこへ向かおうとしているのかをご紹介します。 当日の登壇で使用したスライドは以下になります。 freeeのQA組織の現在地とこれから-freee技術の日2025 - Speaker Deck 当日の動画も公開されています。 www.youtube.com freee QAのミッションとビジョン まず、私たちが組織として何を目指しているのかを再確認します。 freee QAのミッション 起こしちゃいけないハッピー*1が起きにくい体質にすることでマジ価値*2を継続的に届け続ける このミッションには、品質という言葉の定義が広いためにQAがやることが中途半端になることを避け、当たり前品質にフォーカスする意志が込められています。また、品質をプロセスやマインドに組み込むことで、「起こしちゃいけない不具合」が発生しにくい体質を作ること、そしてリリーススピードにこだわり、マジ価値を継続的に届けることが重要だと考えています。 freee QAのビジョン 当たり前品質の高速フィードバックの実現 どの開発フェーズにおいても、目指すべき品質とのギャップを高速にフィードバックすることで、手戻りをなくし、高頻度にユーザーに価値を届けられるようにしていくことを目指しています。 私たちの行動指針は「もっと速く、もっと手前で！」です。いつでもどこでもフィードバックするのが大事としました。QAによるテストもフィードバックの一つとして位置づけています。これは英語で Act faster, Align earlierとしました。Tシャツを今年の夏にyamaeriさんに作ってもらったので、登壇でも着てます（笑）。 Act faster Align earlier なぜ組織の「現在地」を変えていく必要があるのか freeeはここ数年で急激な成長を遂げています。現在、freeeを使ってくださっている事業所の数は60万を超えています。プロダクトの数も、freee会計だけでなく、freee人事労務、freee販売、freeeカードなど、どんどん増え続けており、プロダクト間の連携機能が多い「統合型」プラットフォームであるため、内部の連携まで確認が必要でテストが複雑になりがちです。 さらに、freee会計のように10年以上の歴史を持つ大規模なプロダクトもあれば、去年リリースされたばかりでこれから成長していくプロダクトもあり、ステージの異なるさまざまなプロダクトが混在しています。 私たちが直面した大きな問いは、組織が急拡大し、プロダクトが複雑化していき、QAの難易度も変わり続ける中で、「このミッションとビジョンをどうやって実現し続けていくか？」ということでした。 過去の組織と活動の軌跡 フリーのQA組織は、2019年頃、私が入社したときは、案件ごとに人がアサインされる派遣型組織でした。この体制には、QA担当者の自分ごと感が足りず、開発スピードが遅れるという課題がありました。 そこから脱却するため、各開発チームにQAエンジニアを専任配置する一体型の組織へと変更しました。 テストだけするチームからの脱却 組織を変えるとともに、QAエンジニアの役割も「リリース直前のテスト実行だけをする人たち」ではなく、開発工程のできる限り早い段階で品質向上に貢献し、リリース直前のテストはできるだけ短時間にして、的をえたテストをすることを目指しました。目指していることがみんなにわかるように、上記したQAのミッションとビジョンを定義したのもこの頃です。これまでの取り組みとしてどのようなことをしてきたかは、昨年のアドベントカレンダーで、でーにしさんが「10分でわかるfreeeのQAあえ共」という内容で書いています。 developers.freee.co.jp この結果、2019年から2025年までの比較で、以下の実績が出ています。 2019年から2025年の変化 PR数の増加は3.3倍になり、QAエンジニア数が2.2倍になるが、参画する案件数は3.6倍に増加している（より効率的に多くの案件に参画できるようになった）。 無闇な網羅的テストを排除し（目的ベースでテストするテストチャーターの考え方を導入）、実行したテストケースの数は80%削減したが、QAで見つけるハッピーの数は2.9倍に増加している。 QAで見つけるハッピーの数は2.9倍に増加しているが、障害（リリース後に起きる重篤な不具合）は1.3倍となっている。 自動テストは安定して短時間でたくさん実行できるようになり、2019年は実行回数が年間で10万回だったのが、2025年は、11月時点で実行回数は年間60万回となっている。 自動テストの実行回数の推移 これらの実績を出すために、2022年-2024年の３年間のロードマップを作り、実行しました。その中で取り組んだことは、QAのテストプロセス標準化とQAの人材育成、重篤度の定着や品質目標KPIの設定、リグレッションテストの自動テストカバー率の向上など多岐に渡ります。 今年行ったこととしては、人材育成のひとつとして、ソフトウェアエンジニアリングについて理解するワークショップの実施があります。また、品質目標KPI達成のための施策として障害DeepDiveをトライアルしてる最中ですが、品質企画のkuritaroさんがこの取り組みの考え方に関してアドベントカレンダーを書いてくれました。 developers.freee.co.jp しかし、組織の人数が増えて、プロダクト数も増えていく中で、組織全体の品質/生産性を向上させるには、次のステップが必要となりました。 QAがこれまでしたさまざまな取り組みとこれから目指すこと Whole QAの概念と組織再編 組織の急拡大と複雑化に対応し、freeeのミッションを最速で実現できるチームを目指すために、私たちは「Whole QA」という考え方を提唱し、何をしていくかを決め、組織全体でできるように努力しています。 Whole QAとは、QAチームだけでなく、開発に関わる人全員（各工程）で品質を良くするぞ！という考え方です。WholeQAの取り組みは、kenseiさんが昨年のアドベントカレンダーで書いてくれています。 developers.freee.co.jp このWhole QAを全体的にできるようにし、進化していくために、2025年7月から組織体制を再編しました。 組織再編の狙い：分離と横断 QA組織は、大きく「各開発組織に所属するプロダクトQA」と「横断QA」の二つに分けました。 1.プロダクトQA (分離：各プロダクト配属) 狙い：プロダクトへのコミットメント強化と迅速な意思決定。 QAがプロダクト組織の一員となり、プロダクトのOKRとQA活動を直結させることで、「もっと速く、もっと手前で！」のフィードバックループをプロダクト内で完結させやすくなります。ドメイン知識の深化も目指します。 2.横断QA (これまでと同じ独立した部署) 狙い：サイロ化の防止と技術の標準化・横展開。 各プロダクトにQAを配属すると、プロダクトごとにやり方がバラバラになってしまう（サイロ化）リスクがあります。横断QAは、この新しい課題を解決することをミッションにしています。 具体的には、開発全体で取り組むべきテーマ（例：組織的な障害削減施策、AI活用　による生産性向上）から方針や具体的な施策を決めて、各プロダクトへ展開する役割を担います。そのため、品質企画やSEQは横断QAにいます。QAエンジニアの採用、育成、評価といった、freee のQAが同じカルチャーで取り組めるための土台も横断QAがリードしてQA全員で取り組むことが出来るようにしていきます。 現在の組織体制 これからのフリーQAの取り組み この新しい組織体制のもと、私たちはさらなる高みを目指します。現在のフリーのQA組織全体の重点領域には、以下のようなものがあります。 リソースの選択と集中: QAの関与にメリハリをつけるため、重篤度が高いハッピーが出るリスクを開発の最初に判断できるようにして、より集中が必要なプロダクトにQAエンジニアが確実に入れるようにします。この判断にはAIを活用していきます。 開発生産性にマッチしたQA: Whole QA（前述）　、テストレシピやテストアーキテクチャーを活用し、提供したい機能をより早くリリースできる体制を作ります。ここでもAI活用を施策のために進めます。テストレシピやテストアーキテクチャーは昨年のアドベントカレンダーを参照してもらえればと思います。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdevelopers.freee.co.jp%2Fentry%2Ffreee-qa-advent-c