こんにちは、技術部 技術基盤グループの kmsnです。先日 Tamachi.sre で「Issueを見極める信頼性」というテーマで登壇しました。本記事では、登壇内容をもとに、SREとして日々の業務の中でどのように「本当に解くべきIssue」を見極めているか、その考え方と実践についてまとめます。なぜこのテーマを書こうと思ったか日々の運用や改善活動に取り組んでいると、多くの課題に直面します。しかし、それらすべてを同時に解決することはできません。限られた時間とリソースの中で、「どのIssueに向き合うべきか」を見極めることは非常に重要だと感じています。私自身、コスト最適化や運用改善に取り組む中で、表面的な問題と本質的なIssueは異なるということを何度も経験してきました。最初は「とにかく改善する」ことに集中していましたが、次第に「どの改善が本当に価値を生むのか」を考えるようになりました。本記事では、そうした経験から得た「Issueを見極めるための考え方」についてまとめます。「Issueを見極める」とは何か無数に存在する問題の中から、解決することで未来が変わる「本質的な課題」を選択して、そこにリソースを集中することです。そのために意識している軸が5つあります。【構造】 症状ではなく、裏側にある仕組みを捉える表面上のエラーログを消すのではなく、「なぜそのエラーが起きうる構成になっているのか」というアーキテクチャやコードの構造に目を向けます。【継続性】 一過性のノイズか、未来に続く課題かたまたま一度起きただけの事象にリソースを割きすぎていないか。今後も繰り返され、積もり積もって大きな損失を生む「継続的な痛み」を優先して解決します。【根本改善】 対症療法を捨て、再発の芽を摘む再起動して直すのは「運用」ですが、再起動しなくて済む仕組みを作ることが重要です。仕組みそのものをアップデートし、同じ問題が二度と起きない状態を目指します。【価値】 「量の解決」から「価値の創出」へ解決したタスクの数（量）に満足せず、その改善が「ユーザー体験」や「チームの開発生産性」にどれだけ寄与したか（価値）で、優先順位を判断します。【学習】 仮説検証を回し、小さく進化し続ける最初から完璧な正解を求めすぎず、最小限のコストで試してフィードバックを得ます。その学びを次の改善に活かす「学習のループ」こそが、不確実

こんにちは、ペパボで技術部部長をしているkenchanです。「閃光のハサウェイ」3作目が公開されるまで健康でいるために、運動を再開しました。この記事では、ペパボ技術部の2026年方針「Agent Ready」について紹介します。私たちがこの方針に至った背景と、具体的に何をやろうとしているのかをお伝えできればと思います。技術部は、GMOペパボの全事業部門にわたるインフラ・データ基盤・情報システム（コーポレートエンジニアリング）の3つを横断的に担う部門です。ロリポップ！やムームードメインといったホスティングサービス、カラーミーショップ・minne・SUZURIなどのEC・ハンドメイドプラットフォームのインフラ運用から、全社のデータ基盤の整備、社内ITの整備・運用まで、各事業部がプロダクト開発に集中できるよう技術的な土台を支えています。はじめに: なぜ今、私たちは「前提」を書き換えるのかAIの進歩は不可逆です。「逆張り」せず、この波に全力で乗る——それが2026年の技術部の基本姿勢です。私たちの現場でも、2025年を通じてAIの活用は確実に広がりました。コードレビューの補助、障害調査時のログ要約、ドキュメント作成の効率化。個々のエンジニアがAIを「便利な道具」として使いこなす場面は増えています。しかし、それは個人の生産性向上にとどまっており、組織やサービスの基盤そのものは変わっていません。2026年、ペパボ技術部は「Agent Ready」を方針として掲げます。技術部が先陣を切り、組織とサービスの両方がAIエージェント前提となるための基盤を作るという宣言です。ここで重要なのは、AIの性能がいくら向上しても、それだけでは組織は変わらないということです。AIが能力を最大限に発揮するためには、エージェントの「手足」となるインフラ、「脳」となるデータ、そして「意志」となる文化の3つが揃っている必要があります。私たちはこれをToolset・Dataset・Mindsetの3本柱として整備していきます。Toolset: Agent-Firstのための「手足」を作る1本目の柱は「Toolset」——AIエージェントが動ける手足を作ることです。現状の課題ペパボの技術部はこれまで、数十万件規模のホスティングサービスや複数のEC・ハンドメイドプラットフォームを支えるインフラを運用してきました

こんにちは！GMO ペパボのてつをです。この度、フロントエンドカンファレンス関西 2025に参加・登壇してきたので、その内容をご紹介します。フロントエンドカンファレンス関西とは「IGNITE KANSAI – 出会いが共鳴し、次の誰かを動かす」をコンセプトに、2025年11月30日にマイドームおおさかで開催された、Webフロントエンド技術に特化したカンファレンスです。会場はワンフロアを貸し切り、2つのトークルームで並行してセッションが行われました。基調講演やレギュラートークに加え、LTやスポンサーブースも設けられ、全19セッションが展開されました。また、「Ask the Speaker」として、セッション中に気になった話題についてスピーカーに直接質問できるスペースが設けられており、スピーカーとコミュニケーションできる場が提供されていました。登壇についてここからは、今回私が発表させていただいた内容について紹介します。Matter.jsでつくる「ぷにゃっ」と動く物理演算Webエフェクトとパフォーマンス改善本発表では、JavaScript製の2D剛体物理エンジンであるMatter.jsを使って、「ぷにゃっ」とした軟体風のアニメーション表現を実現する方法について紹介しました。Matter.jsは剛体物理エンジンであるため、そのままでは軟体のような柔らかい表現はできません。そこで、衝突イベントから得られる法線ベクトル（衝突方向）と速度をもとに、CSSアニメーションで衝突方向と速度に応じた縮みを表現するアプローチを紹介しました。主な内容Matter.jsの基本的な使い方（エンジン作成、レンダラー作成、オブジェクト追加）Eventsを活用した衝突方向・速度の推定方法物理計算 → JavaScript → CSSというイベント駆動の描画反映の仕組みまた、パフォーマンス改善についても紹介しました。オブジェクト数の上限管理とFPS制限による計算コストの削減エンジンと静的ボディの再利用イベントリスナーや物理オブジェクトの適切なクリーンアップによるメモリリーク防止登壇の感想今回はLT枠（5分）での発表でしたが、物理演算をWebエフェクトに応用するという内容に対して、多くの方に興味を持っていただけました。限られた時間の中でしたが、実際の使用例と注意点の両面を伝えられたのではないかと思います。

こんにちは！この度、パートナーのどすこい、yukyan、ikechi、ugoの4名がBuriKaigi 2026に参加・登壇してきたので、その内容をご紹介します。BuriKaigi 2026 とは年に一度、寒ブリの季節にソフトウェア開発・ITにおける各分野で最前線で活躍するエキスパートを全国から北陸へ招待し、技術の旬を持ち寄り、講義・ディスカッションを行う勉強会です。2026年は1月9日（金）・10日（土）の2日間、富山国際会議場で開催されました。今年は申込数318名、参加者数313名と参加率98%を記録し、300名を超える多くのエンジニアが集まりました。登壇についてここからは、今回私たちが発表させていただいた内容について紹介します。AIで開発はどれくらい加速したのか？AIエージェントによるコード生成を、現場の評価と研究開発の評価の両面からdeep diveしてみるEC事業部 事業開発チームでエンジニアをしているどすこいです。『AIで開発はどれくらい加速したのか？AIエージェントによるコード生成を、現場の評価と研究開発の評価の両面からdeep diveしてみる』でレギュラーセッションで登壇しました。故郷の富山で再度登壇できて嬉しかったです！近年のAIエージェントの進化は著しく、どのAIモデルがどのようなタスクに強みを持つのかを判断するのが難しくなっています。AIエージェントのユースケースや使ってみた肌感は多くあるものの、変化の激しいAIエージェントの良し悪しをどのように判断すれば良いかという情報があまりないなと気づき、発表しようと考えました。しかし、2026年2月5日のAnthropicが発表したClaude Opus 4.6とOpenAIが発表したGPT-5.3-CodexではTerminal-Bench 2.0というベンチマークが使われていたり、ベンチマークの変化も日進月歩のようです。本発表や資料によって、見てくださった方々が、ベンチマークの雰囲気を掴んでもらって、新たなトレンドも随時掴めるようになれると幸いです。ソースコードのEUC-JP、全部抜く大作戦EC事業部 事業開発チームでエンジニアをしている yukyanです。見出しのタイトルでLTをしました。歴史の長いPHPのプロダクトに携わっていると、一度はEUC-JPのソースコードに関わる機会があると思います。

こんにちは、技術部データ基盤チームの zaimy です。今回は、GitHubのIssue TemplateとClaudeを組み合わせて、HubSpotユーザーが作成するカスタムプロパティに対してエンジニアレビューを挟むことによる、データ品質向上の取り組みについて紹介します。背景：データ設計の課題ペパボでは営業活動やカスタマーサポートのためにHubSpotを利用しています。HubSpotは営業管理やマーケティングに使われるSaaSで、ノーコードツールとしてカスタムプロパティ（RDBのカラムに相当）を自由に作成できます。この自由度の高さは便利な反面、営業やマーケティング担当者が業務上必要なプロパティを自由に作成した結果、データ利用に問題が生じていました。命名規則がバラバラ（英語/日本語ローマ字、スネークケース/キャメルケース、prefixの有無が混在）データ型と値の指定が不適切（例：bool を意図した true / no のような値が存在）同じ意味のプロパティが複数存在用途が不明なプロパティが存在これらの問題により、HubSpotのデータをBigQueryにロードしてもデータクレンジングなしには種々の施策に使えず、データクレンジングそのものが困難なことすらある状態でした。解決策：GitHub Issue Template + Claudeによる設計の提案とエンジニアによるレビューフローこの問題を解決するため、以下のような仕組みを構築しました。HubSpotユーザーがGitHubのIssue Templateに沿ってカスタムプロパティ作成を申請GitHub ActionsがClaudeを自動実行し、HubSpotの公式ドキュメントと既存プロパティを参照して設定値を提案データエンジニアがレビューレビュー承認後、HubSpotユーザーがカスタムプロパティを作成1. Issue Templateの設計GitHubのIssue Templateには以下の情報を入力してもらいます。使用するサービスカスタムプロパティに保存する内容：保存したいデータの説明追加のコンテキスト：用途や背景情報重要なのは、プロパティ名や内部名を申請者に考えてもらわない点です。Claudeに任せることで、一般的なエンジニアリングのプラクティスに沿えるような設計にしました。Issue Templateには以下

「開発環境現状確認2026」に寄せて、ペパボパートナーの有志の開発環境を紹介します！@名前の環境詳細をみる をクリックして、各メンバーの詳細な環境を確認してみてください。 開発環境現状確認2026 まとめ エディタターミナルシェルAIコーディングエージェントランチャーバージョン管理ツールキーボード@kentaro 基本環境AIツール開発ツール環境構築・管理日本語入力ハードウェアCLIツール情報管理その他まとめ@kenchan@tnmt@rsym1290 基本環境AIツール開発ツール環境構築ハードウェアCLIツールその他一言@shibatch 基本環境AIツール開発ツール環境構築ハードウェアCLIツール一言@n01e0 基本環境AIツール開発ツール環境構築・管理ハードウェアCLIツールその他一言@takumakume 基本環境AIツール開発ツール環境構築ハードウェアCLIツール一言@haruotsu 基本環境AIツール開発ツール環境構築ハードウェアCLIツールその他一言@atani 基本環境AIツール開発ツール環境構築ハードウェアCLIツールその他一言@shunhamm 基本環境AIツール開発ツール環境構築ハードウェアCLIツールコンテナその他一言@yammerjp yadmAstroNvim@furudono2 去年との差分今年の抱負@doskoi64 基本環境AIツール開発ツール環境構築ハードウェアCLIツールその他一言@kurotaky 基本環境AIツール開発ツール環境構築ハードウェアCLIツールコンテナその他一言@yoshikouki 基本環境AIツール開発ツール環境構築ハードウェアCLIツールその他一言@tetsuwo0717 基本環境AIツール開発ツール環境構築ハードウェアCLIツールその他一言@ugo 基本環境AIツール開発ツール環境構築ハードウェアCLIツールその他一言まとめ開発環境現状確認2026 まとめ記事で紹介する17名のペパボパートナーの主要なツールを集計すると、以下のようになりました。詳細や各人が書いたコメントを知りたい方は、@名前の環境詳細をみる をクリックして、各メンバーの詳細な環境を確認してみてください！エディタエディタ 人数 Neovim 12名 Cursor 9名 VS Code 4名 Vim / vi 2名 ターミナルターミナル

こんにちは、SUZURI・minne 事業部で minne iOS アプリを開発している umatoshi です。minne iOS アプリでは主に Claude Code を利用してアプリ開発を行なっています。期待通りのコーディングをしてもらうために、さまざまな情報を CLAUDE.md に集約させていきました。その結果、レート制限に到達したり、期待通りのコーディングをしてくれないなど、CLAUDE.mdの肥大化に悩まされました。本記事では、Claude Code のドキュメント管理機能である CLAUDE.md と、2025年10月にリリースされた Skills、さらに 2025年12月に追加された Rules を組み合わせたハイブリッド構成について紹介します。CLAUDE.md の肥大化を防ぎ、期待通りに Claude Code を利用するためのノウハウを共有します。1. 導入：肥大化した CLAUDE.md と Skills、Rules のハイブリッド構成に至った経緯minne の iOS アプリでは、Claude Code の導入当初からプロジェクト固有の情報を CLAUDE.md に集約してきました。リポジトリのコードを読み込ませて分析し、アーキテクチャ方針やコーディング規約を整理してもらいながら、以下のような情報を書き溜めていきました。minne iOS アプリのプロジェクト概要アーキテクチャ方針（MVVM、SPM モジュラー構成）テストのコーディング規約（Swift Testing、TDD）MCP を活用したビルド・配信コマンドSwiftLint、SwiftFormat の利用ガイドSwiftUI 規約（Font、Color）etcその結果、CLAUDE.md は 2,500 行を超える巨大なドキュメントになり、次のような問題が出てきました。コンテキストウィンドウの圧迫: Claude Code は会話開始時に CLAUDE.md を読み込むため、ファイルが大きくなるほどコードや会話に使える容量が減ってしまう情報の埋没: Color.mi.* や Swift Testing といった重要な規約が大量の情報に埋もれ、Claude Code が見落としやすくなるトークンコストの増加: 毎回全文を読み込むため、API 利用料が高くなるmax_tokens

技術部データ基盤チームの@zaimyです。ペパボのデータ基盤チームでは、GitHub Enterprise Server（以下GHES）で運用していた全てのリポジトリをGitHub Enterprise Cloud（以下GHEC）へ移行しました。本記事では、移行の背景、実際の手順、そして注意すべきポイントについてまとめます。移行の背景 利用者のメリット運用のメリット移行前の準備 必要な権限の整理ローカルストレージの設定Personal Access Tokenの準備移行手順 GitHub Enterprise Importer CLIのインストールソースリポジトリをGHEC移行できる状態にするソースリポジトリのアーカイブ化移行の実行マネキンの割り当て移行後の設定変更移行されるデータと移行されないデータ 移行されるデータ移行されないデータ注意すべきポイント 社内向けgemの配信Rulesetによるブランチ保護とDependabotによるPRの自動マージ新機能の活用まとめ移行の背景ペパボではこれまでGHESを社内で運用してきましたが、GHECへの移行が決定しています。移行の背景には、利用者のメリットと運用のメリットの両面があります。利用者のメリットGHECへの移行により、以下のような新機能が利用可能になります。GitHub Codespaces: クラウドベースの開発環境Secret scanning: リポジトリ内の機密情報の自動検出GitHub Copilot: AI支援による開発効率の向上また、クラウドサービスとして提供されるGHECは、GHESと比較して高い可用性とレスポンス速度が期待できます。運用のメリット運用面では、以下のメリットがあります。GitHub Enterprise UserのEntra IDによる一元管理GHESの運用負荷からの解放 バージョンアップ作業サーバーメンテナンスインフラ管理既に新規のサービス開発ではGHECのリポジトリを利用していますが、各事業部でサービス開発に用いているGHESのリポジトリ数が膨大なため、全社的な移行はこれからといった状況です。そこで、各事業部での移行に先鞭を付けるために、データ基盤チームがGHESで運用している全リポジトリをGHECへ移行することにしました。移行前の準備必要な権限の整理移行作業を行うには、GHECの

SUZURI WEBアプリケーションエンジニアのarumaです。昨年、SUZURIのデジタルコンテンツ販売の新機能「バリエーション販売機能」をリリースしました。この開発では既存のデータベース構造を大きく変更する必要がありましたが、サービスを停止することなく移行を完了させることができました。この記事では、その無停止移行をどのように実現したかをご紹介します。バリエーション販売機能とはバリエーション販売機能は、1つのデジタルコンテンツ商品ページで複数の選択肢（バリエーション）を設定できる機能です。たとえば以下のような販売方法が可能になります。内容別: 壁紙データをPC用・スマホ用で別々に販売グレード別: 特典やライセンスなどによって価格差を設定投げ銭: 無料配布のデジタルコンテンツでも支援を受けられるよう、同じ内容の投げ銭バリエーションを用意移行前後のデータ構造移行前の構造移行前は、以下のような構造でした。products: デジタルコンテンツ商品（価格情報を持つ）contents: 商品に含まれるファイル（products に 1:N で紐づく）order_details: 購入履歴（products に直接紐づく）移行後の構造バリエーション販売を実現するにあたり、いくつかの設計案を検討しました。案1: productsに紐づくvariantsテーブルを新設し、価格情報と購入履歴の参照先をそちらに移す案2: 上位にproduct_groupsを追加し、既存のproductsをバリエーションとして扱う案3: products同士に親子関係を持たせる案2と案3は購入履歴テーブル（order_details）の既存レコードに手を加えなくてよいというメリットがありましたが、最終的には「1つの商品が複数のバリエーションを持つ」という実態を素直に表現できる案1を採用しました。productsとorder_detailsの間にvariantsテーブルを追加する形です。products: デジタルコンテンツ商品variants: バリエーション（価格情報を持つ、products に 1:N で紐づく）contents: 商品に含まれるファイル（products に 1:N で紐づく）variant_contents: バリエーションとファイルの紐づけ（N:M の交差テーブル）order

こんにちは！ロリポップ・ムームードメイン事業部のtakiです。近年、npmパッケージを標的としたサプライチェーン攻撃が急増しています。私たちのプロジェクトでもセキュリティ強化の一環として、パッケージの検証ツールである「Aikido Safe Chain」を導入しました。しかし、導入してすぐに一つの大きな壁にぶつかりました。それは、安全性のための「24時間制限」が、緊急時のデプロイを妨げてしまうという問題です。本記事では、Aikido Safe Chainを実運用に載せる中で見えてきた「落とし穴」と、GitHub Actionsの機能を駆使してセキュアかつ柔軟な運用を実現した試行錯誤の過程を共有します。Aikido Safe Chainとは直面した課題：緊急パッチが「24時間制限」でブロックされる 運用上の「落とし穴」解決までの試行錯誤 workflow_dispatchを使うCommit Status APIを使うブランチ名で条件分岐する（成功！）最終的なバイパス方法Tips：GitHub APIのレートリミット対策おわりにAikido Safe ChainとはAikido Safe Chainは、npm・yarn・pnpmなどのパッケージマネージャーをラップし、パッケージダウンロード時に以下の検証をリアルタイムで行うツールです。マルウェアチェック： Aikido Intelと照合し、既知の脅威をブロック公開日チェック： 24時間以内に公開されたパッケージをブロック（デフォルト設定）特に後者は、未知の脆弱性や悪意のあるコードが公開直後に混入するリスクを低減するための強力な防衛策です。直面した課題：緊急パッチが「24時間制限」でブロックされるAikido Safe Chainをインストールすると、npm installやnpm ciの実行時に自動で検証が走るようになります。私たちのプロジェクトでは、以下の3つの環境で運用を開始しました。ローカル開発環境CI（テスト実行）GitHub Actionsでのイメージビルドここで問題になったのが、脆弱性が発見されたパッケージに対して公開直後の修正パッチを当てたい という緊急ケースです。運用上の「落とし穴」npm ci --safe-chain-minimum-package-age-hours=0のように指定すれば24時間制限

はじめにこんにちは！GMOペパボでiOSアプリ開発をしているsattonです！今回は、10月21日に開催された potatotips #93 の様子をお届けします！🥔potatotipsについての簡単な紹介potatotipsは、若手からベテランまでの幅広いエンジニアが集まり、iOS/Androidアプリ開発のTipsを発表するモバイルのLTイベントです。これまで500名以上が登壇し、2000名以上が参加してきた歴史あるコミュニティで、発表者・聴講者の垣根を超えて、モバイル開発の知見を気軽に共有できる場となっています。そして、昨年の開催に続き、今年もペパボで開催させていただきました！今回は「より多くの人に参加してもらいたい」という思いから、オンライン配信を取り入れたハイブリッド形式に挑戦しました💪弊社モバイルエンジニアの発表AndroidエンジニアのKyuさんiOSエンジニアのJonnyさん開催までの道のり今回のpotatotips#93では、昨年の開催での反省をふまえて、準備期間に十分な時間を割くことタスクをNotionで一元管理して、担当と進捗を見える化することの2点を特に意識して準備を進めました。まずは運営メンバーでキックオフを行い、タスクを洗い出して担当を決めました。社内稟議・各種申請書の作成・提出飲食物の選定・手配イベントページ（connpass）の作成配信構成（カメラ・マイク・画面共有）の確認配信機材の手配・テスト会場レイアウトや案内用掲示物の作成タスクはいつまでに終わっていると安全かをベースに逆算し、社内申請や施設利用の調整など時間がかかりそうなものから着手しました。申請関連は、他部署でのイベント事例を参考にして、申請書のフォーマットや想定される質問事項を事前に確認しておくことで、差し戻しが起きないように気をつけました。フードの工夫平日夜の開催ということもあり、仕事帰りでも気軽に食べられて、しっかりお腹を満たせるもの を意識しました。片手で食べやすいお弁当を選ぶ発表の合間に取りやすい場所にソフトドリンクを配置するといった、「腹ごしらえしながらLTを聞ける」ような工夫をしました。また、イベント名のpotatotipsにちなんで、社内サービスからポテトチップスを厳選しご用意させていただきました！オンライン配信のチャレンジ今回の最大のチャレンジは、初のオ...