はてなブックマーク

newmoではフロントエンドとバックエンドの通信をGraphQLで行っています。GraphQLのスキーマは、フロントエンドとバックエンドが合意した唯一の正しい定義、いわば「正となる単一の情報源(Single Source of Truth)」です。このスキーマを正として、開発と自動テストの両方をここから組み立てたい。その基盤として@newmo/graphql-fake-serverを自作してOSSとして公開しています。 このライブラリは、スキーマを正としたまま、2つの使い方を1つのサーバで両立します。1つはスキーマに@example* directiveを書くだけで値が返るDeclarative Fake、もう1つはHTTP経由で動的にレスポンスを登録できるDynamic Fakeです。どちらの値もスキーマから派生するため、スキーマと矛盾するFakeは作れません。newmo-appではこの

newmo では依存パッケージの更新に Renovate を使っています。これまでは Mend が提供するクラウド版（Mend-hosted の GitHub App）を利用していました。しかし Kernel out-of-memory エラーで Renovate がまともに動かなくなりました。 この記事では、なぜ動かなくなったのか、そしてクラウド版から GitHub Actions 上で動かす Self-host 版へどう移行したのかを紹介します。 過去に書いた Renovate と pnpm catalog で依存を管理する話 の続編にあたる内容です。 先に結論 クラウド版 Renovate がメモリ制約（3GB）で Kernel out-of-memory を起こし、PR を作れなくなった メモリ・実行時間・環境変数の制約を回避するため、GitHub Actions 上で動かす Se

newmoのフロントエンド開発では、複数の機能を持つ単一のNext.jsアプリケーションを開発しています。このアプローチは、コードの共有やCIの管理といった面でメリットがある一方で、PlaywrightテストのCI実行における安定性とテスト時間という2つの課題を抱えていました。 この記事では、newmoで実施したPlaywright CI最適化の取り組みについて紹介します。 Docker Image導入によるセットアップの安定化と、テスト分割とShardingによる実行時間の短縮という2つのアプローチを実施しました。 結論を先に述べると、Docker Image化でセットアップ起因のCI失敗をほぼ解消し、テスト分割で最も多い小規模PRのCI時間を約42%（平均18%）短縮しました。仕組みは「①公式Docker Imageの利用」と「②変更検知によるproject単位の選択実行とShardi

Claude Code のスキルが数十個に増えてきたのですが、全員に一律で適用されるのがつらくなってきたので、Plugin Marketplace を使ってオプトイン配布に移行しました。 スキルが増えると何が起きるか Claude Code のスキルは .claude/skills/ に配置すると、リポジトリを開いた全員に適用されます。数個なら問題ないのですが、数十個に増えてくるとスキルの description マッチングで意図しないスキルまで発火するようになってきました。QA 向けのスキルがバックエンドエンジニアの作業中に反応したり、フロントエンド向けのスキルがインフラの作業で発火したりといった具合です。 使わないスキルの description がコンテキストウィンドウに載り続けてトークンを消費するのも気になっていました。改めてスキルの棚卸しをしたところ、全員に必須と言えるものは半分

この記事は newmo Advent Calendar 2025 15日目の記事です。 はじめに newmoでは2025年6月から求人サービス「newジョブ」の開発を進めており、その中でHeadless CMSとしてPayloadCMSを採用しました。 本記事では、約半年の本番運用を通じて得た知見を共有します。 newジョブ サイト・トップ なぜHeadless CMSが必要だったか jinzaiチームは少人数で構成されており、以下のような複数の用途に対応する必要がありました。 求人情報の管理・配信 SEO対策のための構造化データ管理 運用チームによるコンテンツ編集 将来的な機能拡張への対応 既存のSaaSでは要件を満たしきれず、カスタマイズ性の高いHeadless CMSが必要でした。 PayloadCMSとは PayloadCMSは、TypeScriptで書かれたオープンソースのHea

こんにちは、newmo の伊藤です。 この記事では、筆者が取り入れている「Claude Code を Deep Research の用途で使うための工夫」について、自作している Skill や端末間での共有方法、Entire の活用事例などを交えて紹介します。 既存のプロダクトが提供する Deep Research 機能に感じていた課題 筆者はこれまで様々なリサーチの用途に ChatGPT や Gemini が提供する Deep Research 機能を利用してきました。これらのプロダクトが提供する Deep Research 機能はとても便利なのですが、以下のような課題も感じていました: 個々のプロダクトが提供しているインターフェース（ウェブやモバイルアプリ）を介するのではなく、普段利用しているターミナルやエディターでリサーチを完結させたい モバイル端末では普段利用している Markdo

生成AIにドキュメントからテストケースを生成してもらったり、仕様書からコードを生成してもらったりする機会が増えてきました。しかし、こんな経験はないでしょうか？ 入力の理解が不十分 - AIが仕様を読み飛ばす、重要な制約を見落とす 出力フォーマットがバラバラ - 同じ入力でも毎回異なる構造で出力される これらの問題により、生成物の品質が安定せず、結局人間が大幅に手直しすることになります。 この記事では、これらの課題を解決するために試験導入中の「中間表現（IR）」と「出力テンプレート」を組み合わせたパターンを、テストケースの生成を例に紹介します。 課題：自然言語から直接生成する限界 PRD（製品要求仕様書）やPDD（製品設計書）から直接テストケースを生成しようとすると、いくつかの問題が発生します。 PRD/PDD（自然言語） → 生成AI → テストケース この単純なパイプラインでは： 入力の

はじめに Goのエラー処理 Goのエラー処理に何かライブラリを利用していますか？ この質問はGo 1.0のリリースから10年以上経つ今でも、日本のGoコミュニティでよくされる質問です。筆者（tenntenn）もよく他社の方からされます。 pkg/errorsやgolang.org/x/xerrorsがデファクトスタンダードだった頃と比べ、近年（2025年）はあまりデファクトスタンダードと呼べるライブラリが無いのが現状です。 また、言語仕様やerrorsパッケージについても徐々にアップデートされてきました。Go 1.13でエラーのラップやerrors.Is、errors.Asがリリースされ、pkg/errorsが作ったエラーをラップする文化が標準にも導入されました。同様にGo 1.20でerrors.Joinが入り、hashicorp/go-multierror や go.uber.org/

© 2023-Present Segun Adebayo newmoでは、1行目のCSSを書く前に1つ目のDesign Tokenを定義しました。Design Tokenを起点にした開発を実現するため、CSSスタイリングフレームワークにはPanda CSSを採用しています。 しかし、創業期のスタートアップでは、デザインシステムは完成品ではなく日々変化していくものです。Design Tokenの命名が変わる、階層構造が見直される、色の値が調整される——こうした変更が頻繁に発生します。数百箇所に散らばったtokenを手動で置換すると、必ず修正漏れが発生します。そもそもDesign Tokenの使用を強制できなければ、変更に追従する以前の問題です。 newmoでは、TypeScriptの型システムを活用して、Design Tokenの変更を安全に行える仕組みを構築しました。この記事では、なぜPa

1. はじめに newmoではメインのデータベースとしてGoogle CloudのAlloyDBを利用しています。サービスの成長に伴い、GraphQLやgRPCを通じたリクエストが増加し、最近、本番環境のデプロイ時にCPU負荷が90%を超えるという問題に直面しました。 本番環境へのデプロイ時のアラート この記事では、AlloyDBのパフォーマンス最適化に取り組んだ記録をまとめています。「発見 → 改善 → 計測」のサイクルを繰り返しながら、Slow Queryの改善、N+1問題の解消、そしてRead Pool Instanceの導入まで、段階的に行った改善とその効果について詳しく解説します。 かなり詳細な内容になっていますが、同様の問題に悩んでいる方の参考になれば幸いです。 2. システム構成と発生した問題 システム構成 newmoのバックエンドは、Goで実装されたModular Mono

newmoでは、pnpm workspaceで管理している複数のアプリケーションやライブラリに対してESLintを実行しています。 プロジェクトの成長とともにLint対象のファイル数が増加し、CI実行時間とメモリ使用量が増加していました。GitHub Actionsのmatrixオプションを使用した動的なShardingを実装し、これらの問題に対応しました。 newmoフロントエンドの開発原則 newmoのフロントエンド開発では、次の原則を重視しています。 1つ目は、「同じ目的を達成するための手段を統一する」という原則です。同じ目的に対する複数の手段が混在するよりも、統一した手段を使うことで学習コストや保守コストを削減できます。例えば、npmパッケージのバージョン管理では、One Version Ruleに基づき、同じ目的を持つライブラリは1つに絞っています。これは「同じコードを書かない」

はじめに モノレポ環境での依存関係管理は、プロジェクトの規模が大きくなるほど複雑になります。 newmoでpnpm catalogを導入してOne Version Ruleを実装し、パッケージのバージョンを一元管理する仕組みを構築しました。詳細はmonorepo内でのパッケージのバージョンを1つだけに統一するOne Version Ruleをpnpm catalogで実装する - newmo 技術ブログを参照してください。 しかし、一元管理の実現だけでは依存関係の更新作業そのものは依然として手動であり、セキュリティアップデートの適用遅延やレビュー負荷の増大という課題が残っていました。 本記事では、renovatebotとpnpm catalogを組み合わせた依存関係の自動更新システムについて、実装の詳細から運用方法まで解説します。 特にAuto Merge機能において、パッケージの自動更新

こんにちは。Platform Team の tobi (@iam__tobi) です。 本記事では feature flag の基礎的事項の説明と、Platform Team で開発してきた newmo 独自の feature flag 基盤の設計思想と全貌について二段構成でご紹介します。 これから feature flag を導入しようと考えている方にとって参考になれば幸いです。 背景・概要 feature flag 入門 feature flag の概要 feature flag の構成要素 Toggle Point Toggle Router Toggle Context Toggle Configuration feature flag の種類 Release Toggles Experiment Toggles Ops Toggles Permission Toggles Ope

この記事では、Cloud Service Mesh for Cloud Run を利用して PR 環境を構築する方法について紹介します。 背景・概要 newmo ではトランクベース開発を行なっているため、開発環境での動作確認は main branch (trunk) に merge されていることが前提になっています。 そのため現状では、手軽に開発環境で API の動作確認ができなかったり、動作検証が十分でないコードが main branch に merge されてしまう課題があります。CI での test 実行などにより一定品質は担保していますが 、PR 環境 (GitHub の Pull Request ごとに用意される一時的な環境) で QA ができれば問題発見のタイミングを前にずらすことができます。 PR 環境の要件は以下の通りです。 機能追加を行なった PR が実際に Cloud

AI開発ツールDevinが作成したPull Requestに対して、セキュリティと品質を確保するために2人の承認を必要とする実装方法について解説します。 2025/05/21 追記 レビューコメントが30件以上あったときに正しく動かない問題を修正しました 開発者が書いたPull RequestをDevinにApproveしてもらってマージするパターンも防ぎたい場合は、ifの条件を少し変える必要があります。 背景 newmoでも少し前からDevinを利用して開発を行っています。 Devinを利用するフローは、以下のような感じになります。 エンジニアがSlackやDevinのWeb UIからタスクを依頼 DevinがGitHubにPull Requestを作成 エンジニアは必要に応じてSlackやPull Request上でコメント Devinがコードを修正 問題なければ承認してマージ dev

newmo では、地図データや地理情報を扱う場面が多くあります。 たとえば、タクシーやライドシェアでは、営業区域のような営業していいエリアといった地理的な定義があります。 また、乗り入れ禁止区域のようなタクシーが乗り入れてはいけないエリアといった定義も必要になります。 これらの地理に関する定義は GeoJSON のような地理情報を扱うデータ形式で管理されることが多いです。 しかし、GeoJSONなどの定義をテキストとして手書きするのは困難です。 そのため、地図上に区域を作図するエディタやその定義した区域が正しいかをチェックするような管理ツールが必要です。 管理ツールは、ウェブアプリケーションとして作った方が利用できる環境が広がります。 このような地理情報は一度に扱うデータが多かったり、空間的な計算処理が必要になるため、専用の仕組みを使うことが多いです。 このような技術を、地理情報システム（

はじめに newmoではGoogle Cloud等のリソース管理にTerraformを使っています。また、newmoではMonorepoを使って開発しています。 Monorepoについてここでは詳しく説明しませんが、バックエンドのGoのコードもフロントエンドのTypeScriptのコードもTerraformのコードもすべて同じGitHubのレポジトリで管理し開発を行っています。 TerraformのコードをMonorepoで管理することで、以下の要素を統一的に制御できるようになりました CICDパイプライン TerraformとProviderのバージョン セキュリティポリシー Lintルール クラウドリソースの構成 パフォーマンスとコストの最適化 リソースをTerraformのコードで管理する場合に用意するGitHubでのWorkflowは一般的には以下のようなものになると思います。 T

はじめに こんにちは。newmoでソフトウェアエンジニアをやっている@tenntennです。 本稿では、2024年9月24日（火）にファインディ株式会社主催の「Goのイテレータ深堀りNight」というイベントで登壇してきましたので、その報告と内容について紹介します。 findy.connpass.com 「Goのイテレータ深堀りNight」は、2024年8月にリリースされたGo1.23の機能の1であるrange over func（通称イテレータ）について、6人の登壇者がさまざまな角度で10分のライトニングトーク（LT）を行うイベントです。筆者は、トップバッターということで「まずはイテレータ（range over func）の仕様を学ぼう 」という発表を行いました。 登壇に用いた資料は次のリンクから閲覧ができます。 docs.google.com イテレータの導入経緯 イテレータの導入経緯

はじめに こんにちは。newmoでソフトウェアエンジニアをやっている@tenntennです。 newmoには2024年8月に入社しました。この記事を書いているのは2024年9月なので、入社してだいたい1ヶ月ちょっとが経過したところです。 なお、筆者が入社した経緯などは次の記事を読んでください。 note.com 入社した当初、newmoのバックエンドコードのコードを眺めていると、次のように宣言された関数を見つけました。 func Now(_ context.Context) time.Time { return time.Now().In(time.UTC) } 単にtime.Now関数を呼び出して、LocationをUTCに設定しているだけです。 しかも、引数はブランク識別子になっているので使用していません。 しかし、筆者はこれを見て、これは後々のことを考えているなと感心しました。 ちな

newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo

newmoでは、フロントエンド、バックエンド、iOSやAndroidなどのモバイルアプリをすべて同じリポジトリで管理するmonorepoを採用しています。 monorepoを採用することで、アプリケーション間で共通のコードを共有することができたり、CIの管理が楽になったり、他のチームのコードを見るのにわざわざリポジトリをcloneする必要がなくなります。 また、monorepoを採用することで、アプリケーションが利用しているパッケージ(ライブラリやツール)のバージョンを1つだけにするOne Version Ruleが実装できます。 One Version Rule One Version Ruleは、monorepo内のパッケージのパッケージのバージョンを1つだけにするルールです。 The One Version Rule  |  Google Open Source One Versio

こんにちは、newmo 株式会社に所属しているアーキテクトの伊藤です。 5/22 に【Go】カンファレンススポンサーブースの集い 2024 〜カウシェ × newmo × メルカリ〜というイベントを開催しました。 このイベントで、筆者からは GraphQL Federation や Go のための GraphQL のコード生成、Modular Monolith によるシステム設計について話しました。 スライドや動画のアーカイブは、次の場所で公開されているので、ぜひご覧ください！ スライド: Go + GraphQL @ newmo - Speaker Deck 動画: 【Go】カンファレンススポンサーブースの集い 2024 〜カウシェ × newmo × メルカリ〜 - YouTube 筆者が発表した内容を簡単にまとめると、次の3つのポイントが挙げられます。 GraphQL Federat

newmoのCTOのsowawaです。はじめまして〜🚕 🚗 まず、最初にnewmoについて話したいと思います。 newmoはタクシーとライドシェアの会社として2024年に設立されました。 「newmo」は新しいモビリティの会社という意味で、new mobilityからnewmoと名づけました。 newmoでは、移動の問題を解決してみんなが自由に移動できる社会を作りたいと思っています。特に地域社会は移動に課題を抱えるところも多くなってきていて、好きなときに好きなところに行くことが難しいということも少なくありません。newmoではそういった課題を解決して、できるだけ多くの人が好きなときに好きなところに行けるようにできるといいなと思っています。同時に、地域で暮らす人たちが地域の交通の担い手として地域社会に貢献できるようにしたいと思っています。 そんな想いを込めてnewmoのミッションは 「移