AI時代のPlatform Engineeringで生産性をブーストする。1人目プラットフォームエンジニアの募集開始！

ポジション紹介

こんにちは。ニーリー VPoEの菊地(@_tinoji)です。
ニーリーでは現在、マルチプロダクト化を加速するためにエンジニア採用をめちゃくちゃ強化中です。

note.nealle.com

あらゆるポジションで募集を行っているのですが、この度新しいポジションとしてプラットフォームエンジニアをオープンしたので紹介させてください。

AI時代に新解釈したPlatform Engineeringをゼロからやれる、しかもめちゃくちゃ事業が伸びてる環境で。というのは正直かなりアツいと思います。ぜひ！！

ニーリーのPlatform Engineeringのこれまで

ニーリーのPlatform Engineeringが明確に始まったと言えるのは、2022年の頭にSREチームが発足したタイミングです。自分が始めたことなので非常に手前味噌なのですが、立ち上げ直後のロードマップにCI/CDやIaCが入っていた記録があります。僕が入社したときにはリリース作業でscpを実行するシェルスクリプトを走らせる手順があり「スタートアップだな〜！CD作らなきゃ、、」と思ったことをはっきりと覚えています(笑)

偉そうに自分が始めたとか言っていますが、僕が入社したときにはすでにめちゃくちゃドキュメントを書く文化があり、Platform Engineeringでもっとも重要なプラクティスの1つであるドキュメンテーションのベースがありました。正社員エンジニアがまだ1人しかいなかった時代なので、シンプルにすごい。

その後アーキテクチャチームも結成され、最初は0→1のプロダクト開発や技術スタックのリプレイスの意思決定などが中心だったのですが、2023年ごろには単体テストの高速化やコーディング規約の策定など、開発生産性向上のアジェンダも増えてきました。

こうしてプロダクト・組織が拡大する中で、SREチームはクラウドインフラ周り、アーキテクチャチームはコードベース周りというざっくりとした役割分担でPlatform Engineeringが進んでいきました。

例えばSREチーム主導でデプロイ頻度を40倍まで向上させたり。 speakerdeck.com

アーキテクチャチームはオニオンアーキテクチャを導入したり、コーディングガイドラインや自動テストを強化したり。 speakerdeck.com

それ以外にも、AI開発チームがナレッジスペースを用意してAI Chatbotと喋れるようにしたり(内部開発者ポータル(Internal Developer Portal)の実践の1つ)、明確なPlatform Engineeringの役目を持つ人がいなくても全体では自律的に回っていたのは、ニーリーのプロダクト組織のもっとも濃厚なカルチャー「染み出し」によるものだと思います。
なので「プラットフォームエンジニア」というポジションを急いで作ることはあえてしませんでした。

押し寄せるマルチプロダクトの波

というわけでSREチームとアーキテクチャチームを中心に、着実にPlatform Engineeringを実践してきたのですが、2025年に大きく状況が変わります。3つ目のプロダクト『ワンデイパーク』が爆速でサービスインし、一気にマルチプロダクト感が出てきました。
もともと『Park Direct』と『Park Direct for Business』という2つのプロダクトがあったのですが、3つになると一気にカオス感が上がってくることを実感する毎日でした。

『ワンデイパーク』はローンチ後の伸びも凄まじく、最初のプロダクト『Park Direct』が数年かけてじわじわ整備してきたSREingやPlatform Engineeringの導入も一気に進める必要がありました。あっという間にユーザーが増えるのでサービスレベルを意識したモニタリングを始めたい、開発の並列数が上がっているのでPRごとのfeature環境を構築したい、というニーズがどんどん出てきました。

一度サービスインしてしまうと、"稼働させたまま"様々なものを導入するという労力が発生するのでProduction Readiness Checklistの作成をしたりと、次なるプロダクトに備える動きも活発になりました。Platform Engineeringっぽく言えばゴールデンパスの1つですね。

Production Readiness Checklistの一部が利用されている様子

マルチプロダクト化が進むと、当然ながらプロダクトごとに車輪の再発明をすることなく生産性を高めることが重要になりますし、チーム数が増えるのでプロダクト間の認知負荷を抑えないとチーム間の流動性が悪くなります。まさにPlatform Engineeringのニーズを高める大きな波です。

またマルチプロダクトによって共通基盤の開発も本格化しています。これを主導する共通基盤開発チームも、基盤 = Platformという点では似ている側面があり、実際内部開発者プラットフォーム(Internal Developer Platform)もスコープとしています。

SREチーム、アーキテクチャチーム、共通基盤開発チームという三者がそれぞれPlatform Engineeringを行い、「これってどっちがやるんだっけ？」とボールがすり抜けがちになる状況が増えたのにも少し危機感を感じています。

AI時代のプラットフォームエンジニアは間違いなく面白い

もう1つの大きな変化が、ご多分に漏れずAIです。もうさすがにコーディングエージェントを使った開発は完全にデファクトスタンダードになったと言ってよいと思いますが、開発のスピードが非連続に上がったとともに新しい悩みの種が生まれたというのも事実です。

皆さんの会社/チームでは誰がメインのコーディングエージェントを決定しましたか？MCPサーバは誰が立てていますか？いい感じのCLAUDE.mdやAGENTS.mdは誰が作って共有していますか？トークン消費量やコストの管理は誰がやっていますか？
まさにプラットフォームエンジニアの出番だ、という気がしてきます。

AIが勝手にTerraformを書いてインフラを構築し、CI/CDパイプラインも完璧に作成する様を見て、最初は「あれ、Platform Engineeringってもしかしていらなくなる？」と思いもしましたが、「いやいや、これを各チームが好き勝手続けたら1年後どうなんの？」と現実に引き戻されたのは皆さんも一緒だと思います。

単にPlatform Engineeringの守備範囲が変わっただけでなく、むしろ重要性や責任の度合いが増したと言えます。AIを正しく制御してアウトプットと品質を最大化すること(まさにハーネス)に主戦場が移り、かけられるレバレッジも大きくなることでしょう。

実際ニーリーでも数人規模のスモールチームや、極端な話1人でもAIを駆使して高速に開発しアウトカムを生み出す例も出てきています。こういった開発スタイルにガードレールを敷きつつ、スピードも上げられるようにする。プラットフォームエンジニアはますます面白い役割になるでしょう。

jacopenさんも仰っていましたが、AI時代だからこそPlatform Engineeringが重要、プラットフォームエンジニアは社内でAIにもっとも精通した人間になるべき、というのが真実だと思います。

今ニーリーを選ぶ理由

AI時代にプラットフォームエンジニアのキャリアを歩むにあたって、重要なのは「どんな環境に身を置くのか」だと思います。単にプロダクトが複数あってAIを使っていればいいという話ではないので、ニーリーがいかにベストな環境か宣伝させてください。

  • 会社・事業: とんでもない成長フェーズ
    • ニーリーの事業は現在T2D3ラインを超えるスピードで成長を続けています。
    • 会社として生産性向上を明確な"投資ポイント"と考えていることは、プラットフォームエンジニアとして非常に重要です。
  • 組織・カルチャー: エンジニアが「事業に染み出す」
    • 冒頭で少し「染み出し」というカルチャーについて触れましたが、これは単に越境を推奨しているのではなく、エンジニアも事業に対して本気でコミットしたいという組織の意思の現れです。
    • ニーリーでプラットフォームエンジニアがなにかを提案したときの開発チームのリアクションは、確実に「事業が伸びるならやってみましょう！」です。最高だと思いませんか。
  • ドメイン: ディープで複雑だから腕が鳴る
    • Platform Engineering最大のコンセプトは言わずもがな「認知負荷を下げる」です。よって認知負荷がしんどいドメインの方が介在する価値が大きいと言えます。
    • ニーリーが対面する駐車場や不動産、さらに今後切り拓いていくドメインはまさにそれです。ディープなcontextを手懐けることに挑戦すべきです。

当たり前と言われれば当たり前な観点なのですが、今後のキャリアを考えるにあたっての一助になれば幸いです。

ということでお待ちしてます！

求人票です！ herp.careers

「1人目」というのが若干の心理的ハードルになってしまうかもしれませんが、しばらくはSREチームと一緒に動くことを想定していますのでご安心を。「1人目」ではありますが、仲間はちゃんといますw

また、現在「プラットフォームエンジニア」を名乗っていなくても全然問題はなく、SREやDevOpsエンジニア、その他様々なポジションの方のご応募をお待ちしています。

T2D3の成長速度を突っ走っている事業・組織をPlatform Engineering with AIでさらにブーストする。なかなかできない経験をするチャンスです！ぜひ飛び込んでみてください！

少しでも興味がある、入ったら具体的にどんなことから始めるのか知りたい、という方はぜひカジュアル面談にお越しください！まずは僕かSREチームリードの大木にDMしていただくのが手っ取り早いです。飲みに行きましょう🍺

もしくはこちらからも進めます！
カジュアル面談で会えるメンバー一覧

JDDUG meetup #16@福岡 参加レポート~人生初の登壇をしてきた~

イベント登壇レポート

はじめに

こんにちは、SREチームの森原(@daichi_morihara)です。2/26に開催された JDDUG(Japan Datadog User Group) meetup #16@福岡に参加してきました。人生初の登壇も行なったので、記念にイベント参加レポートを書きたいと思います！

会場到着

会場に入った瞬間にとてもお洒落な料理が目に入ってきて感動しました！お腹が空かないようにイベント直前にビッグマックとサムライマックを食べてきた自分を恨みましたね (笑)
(もちろん別腹なので、美味しくいただきました！)

見てるだけで幸せになるお洒落な料理

ハンズオンコンテンツ

前半パートではハンズオンセッションを開催していただきました。実際にDatadogを触りながら、問題を解きポイントを獲得していくゲーム形式で、非常に盛り上がったセッションでした🔥🔥
ニーリーでは導入していない機能にも触れることができ、非常に有意義な時間となりました！

特に印象に残った機能：Continuous Profiler

ハンズオンの中でも、最も印象に残ったのがContinuous Profilerの体験です。Continuous Profilerは関数レベルでCPU、メモリ、I/Oなどのリソースの使用状況を監視するツールです。 APM(トレース)と合わせると、レスポンスタイムの長いリクエストにおいて、どの処理がボトルネックであるかの特定にとどまらず、「ボトルネックの原因(どの関数が原因で処理が長くなっているのか)」まで把握することができる非常に強力なツールであることを、実際に触れて実感することができました！

ハンズオンセッションの様子

登壇

「Datadogのログコスト最適化」というテーマで発表させていただきました。

speakerdeck.com

イベント参加者も多く、発表前はかなりビビっていましたが、緊張しながらも人前で話すという非常にいい経験を積むことができました！

私が発表してる様子

ログコスト最適化に関する取り組みの詳細は、こちらのブログにまとめておりますので、ご興味のある方はぜひ一読ください！

nealle-dev.hatenablog.com

交流

meetupを通じて多くの方とお会いでき、楽しい時間を過ごすことができました。現地イベントならではの良さを体感し、今後はオフラインイベントにも積極的に参加していきたいと思いました！

meetup参加者の全体写真

p.s
懇親会の２次会で食べた福岡名物？のラーソーメン(ラーメンとそうめんが融合した料理)は、締めにピッタリでとても美味しかったです。福岡に行く機会があればぜひ食べてみてください！

「1億人規模の経済圏」のプラットフォームをつくる。共通基盤プロダクトエンジニアを募集します！

共通基盤 ポジション紹介

こんにちは。ニーリー VPoEの菊地(@_tinoji)です。

ニーリーでは現在、マルチプロダクト化を加速するためにエンジニア採用をめちゃくちゃ強化中です。 note.nealle.com

あらゆるポジションで募集を行っているのですが、今日はその中でもエンジニアのキャリアの特異点となりうる、共通基盤プロダクトエンジニアというポジションについて宣伝させてください。

1億人に利用されるポテンシャルを持つ共通基盤をつくっている

ニーリーの共通基盤プロダクトエンジニアが今どんなことにチャレンジしているかについては、ぜひこちらの記事をお読みください。 nealle-dev.hatenablog.com

簡単に言うと、この2点に集約されます。

  • 急激に加速するマルチプロダクト化のために共通基盤を立ち上げている。
  • その基盤は将来的に日本で最も多くの自動車ユーザーに使われるポテンシャルがある。

「日本で最も多くの自動車ユーザー」を具体的に言うと・・・

内閣府の調べによると、令和5年末時点での運転免許証保有者数は約8,186万人で、前年より約2万人増えており増加トレンドが続いています。

「自動車ユーザー」とは言いましたが、例えば『Park Direct』はtoB側のユーザーとして不動産管理会社様や駐車場オーナーの方もいますし、『Park Direct for Business』では企業が保有する法人車を管理する従業員の方もいます。 さらに、当然モビリティに隣接するドメインにも拡大を目指しているので、これらを考慮すると「1億人」と言っても差し支えない規模になると思います。

1億人にリーチできるサービスをGeminiに聞いてみると、LINEヤフー、楽天、リクルート、NTTドコモのような、いわゆる「経済圏」を想起させるプラットフォーマーが並びます。

まさにニーリーはいま、1億人規模の経済圏に成長しうるサービス群、そしてそのための共通基盤をつくっているのです。

具体的に開発している/しようとしているものの例はこんな感じです。羅列すると素朴な印象になってしまいますが、すべて「1億人に使われるようになっていく」という前提で考えるとワクワクしますね。

共通基盤　　　　 概要
認証基盤 複数のサービスで統一的なログイン体験を提供するのはもちろん、エンタープライズのユーザー増加に伴って高まっているセキュリティ要件にも応える。
会員基盤 サービスを横断して会員情報を引き継ぎ、シームレスな体験を実現する。
決済基盤 サービスから接続することにより、最適な決済代行サービスを柔軟に選択するなど。
ポイント基盤 ポイントを起点としてサービス間の相互利用を活発化。ポイ活などの可能性も？

この規模の共通基盤開発の0→1に立ち会うチャンスは極めてレア

「1億人規模の経済圏の共通基盤開発にエンジニアとして携われる可能性」について、頭の中でフェルミ推定をするかAIに聞いてみてほしいのですが、当然ながらめちゃめちゃ希少です。

僕のGeminiの回答は以下でした。

ソフトウェアエンジニアのキャリアとして、「1億人規模のWebサービス群/エコシステム」の共通基盤開発の黎明期(いわゆる0→1)に携われる経験はどれくらい希少なことですか？国内の事例を参考に、全体のエンジニアの何%にチャンスがあるかを推測してください。
客観的な事実と確度の高い論理によって回答してください。私の意見に合わせる必要はありません。

「1億人規模のWebサービス群/エコシステム」における共通基盤（Common Platform）の黎明期（0→1）に携わる経験は、日本のソフトウェアエンジニア市場において「極めて希少（数千人に1人、あるいはそれ以下）」なキャリアと言えます。
客観的な統計と市場構造から、その希少性を論理的に推計します。
(中略)
・市場全体: 1,440,000人
・100M規模企業の基盤エンジニア: 約5,000人（全体の0.34%）
・その中で「0→1」フェーズに立ち会う人数: 10年スパンで見た場合、同時にこのフェーズを経験しているのは国内で 数百人（300〜500人程度） と推定されます。
推計結果： 1,440,000人 ÷ 500人 ＝ 約0.035% つまり、「ソフトウェアエンジニア約3,000人に1人」 程度の希少性です。

そこまで大げさではない確率なんじゃないかと思います。ぜひお手元のAIで検算してみてください。

「まだいらない」と「すでにある」の狭間に飛び込む

このレアリティについては、僕も自らの体験から実感しています。僕が新卒で入社した会社はいわゆるメガベンチャーに分類されるのですが、そこまで行くと共通基盤は「すでにある」のが普通です。

一方でスタートアップがどうかと言うと、1つのプロダクトがしっかり軌道に乗って第2第3のプロダクトが出現してくるまでは、共通基盤は「まだいらない」という状態が長く続きます。実際僕がニーリーに入社してから、共通基盤のニーズが本格化するまでには4年半かかりました。

この「まだいらない」と「すでにある」の狭間に飛び込むことが、共通基盤開発の面白いフェーズに立ち会うために必要なアクションであり、慎重に判断しないといけないのですが・・・

今ニーリーにはその環境があることを約束します！ぜひ今来てください！

ということでJob Descriptionを貼って締めたいと思います。ご応募お待ちしています！

herp.careers

まずはラフに話を聞いてみたい方は僕のXのDMでもOKですし、共通基盤開発チームのリードの松村や、CTOの三宅とのカジュアル面談もウェルカムです！

https://nealle.notion.site/26b8c35b4dfa81218100cf3bcc224ba9nealle.notion.site

TSKaigi 2026にGoldスポンサーとして協賛いたします & セッションの登壇もあります！

協賛 TypeScript

ニーリー VPoEの菊地( @_tinoji ) です。 ニーリーは、2026年5月22日(金)〜23日(土)の2日間にわたって開催される「TSKaigi 2026」に Gold スポンサーとして協賛いたします。

TSKaigi 2026 の概要

日程: 2026年5月22日(金)〜23日(土)
会場: ベルサール羽田空港 ↓↓公式サイトはこちら↓↓ 2026.tskaigi.org

3/23の18時からチケット販売されておりますので、ぜひお早めにチケットをゲットしましょう！

協賛の背景

note.nealle.com

↑のnoteにあるとおり、ニーリーでは今まさにマルチプロダクトの波が来ています。 当然、これを実現するために使っていく技術にも大いにこだわっているのですが、フロントエンドを中心に様々な用途で採用している言語がTypeScriptです。

また、プロダクト開発だけではなく、サクセスエンジニアというポジションでも社内のツール作成や業務効率化などにフルスタックに活用されています。
サクセスエンジニアは非常に面白いポジションですし、TypeScriptをフル活用できるので、ぜひJob Descriptionや入社エントリを見てみてください！(宣伝)

TypeScriptは、型安全性やコードの可読性を向上させることで、開発者がより効率的に作業できるようにするための強力なツールです。 私たちはいかにTypeScriptという言語特性を活かしつつ、高速に開発サイクルを回し続けるかを常日頃から議論しながら開発に取り組んでいます。

日々お世話になっているTypeScriptに対してなにか貢献したい！仲間と共にコミュニティを盛り上げたい！という社内からの声により、今回の協賛を決定いたしました。

セッションの登壇について

また、テックリードの立川が提出したプロポーザルが採択され、「TypeScriptとAngular Signal で実現する保守性の高いアプリケーション設計 - 3層アーキテクチャによる責務分離の実践」というタイトルでの発表させていただきます。

tskaigi.hatenablog.com

(社内ではTSKaigiへの注目度が高く、プロポーザルを出したいメンバーで集まって「プロポーザル書き終わるまで帰れま10」なんかも開催されていましたw)

その時の様子

ニーリーのブース出展について

というわけで会社全体として非常に気合いが入っています！ 現在ノベルティなどの準備を進めており、皆さんに楽しんでいただけるようなブースを作っていきたいと思っています。

セッションの合間や休憩時間に、ぜひニーリーのブースへ遊びに来てください。 事業の話、プロダクトの話、TypeScriptの話など(もちろんそれ以外も大歓迎)ざっくばらんにお話ししましょう！

Product Management Summit 2026 にExhibitionスポンサーとして協賛いたします

協賛

ニーリー VPoEの菊地(@_tinoji) です。 ニーリーは、2026年4月28日（火）に開催される「Product Management Summit 2026」に Exhibition スポンサーとして協賛いたします。

Product Management Summit 2026 の概要

「Product Management Summit」は、プロダクト・組織・ビジネスをどのように進化させていくのか、各社の実践と試行を共有しながら次の一歩を考えるカンファレンスです。 今回は「プロダクトマネジメントの進化」をテーマに、職能の境界を越えてPdM・デザイナー・エンジニアが交わる場となる予定です。 詳しくは公式ホームページで！

product-management-summit.findy-tools.io

協賛の背景

ニーリーは、2019年にローンチした月極駐車場オンライン契約サービス「Park Direct」をメインプロダクトとして事業を伸ばして来ましたが、2021年には法人向けサービスとして「Park Direct for Business」を、そして昨年2025年には1日単位で駐車場予約ができるサービス「ワンデイパーク」の提供を開始し、今まさにマルチプロダクトの波が来ています。

単にプロダクトが複数あるだけではなく、

  • Park Direct: 10→100
  • Park Direct for Business: 1→10
  • ワンデイパーク: 0→1

というフェーズの異なる事業が混在し、大きなシナジーを伴いながら全ての事業が高速に伸びている状況、つまりプロダクトマネジメントの重要度が極めて高い事業フェーズに差し掛かっています。

第1の矢 = Park Direct、第2の矢 = Park Direct for Business、第3の矢 = ワンデイパーク

ニーリーではプロダクトエンジニアが一般的にはPdMが担当するようなDiscoveryやPlanning領域にも染み出すカルチャーが非常に強いですが、だからこそPdMはあらゆる事業成長のレバーを引ける環境にあると思います。

ニーリーが提供するプロダクトはシステム単独で価値を生み出しているのではなく、システム+オペレーションが一体となってユーザーに価値を届けているというのが大きな特徴です。よってニーリーのPdMは、ユーザーが求めるプロダクト開発で伸ばすのか、業務プロセスにdeep diveしてオペレーションで伸ばすのか、はたまたマーケティングでアプローチして伸ばすのか、あらゆる選択肢を持っています。

そのような裁量の大きなPdMが、「AI」という新たな武器を持ち今後どのように顧客価値を生み続けていくのかを考える中で、Product Management Summit 2026のテーマに共感し、今回協賛をさせていただくことになりました。

↓ニーリーのPdMのことが分かる参考記事 nealle-dev.hatenablog.com

note.nealle.com

ニーリーのブース出展について

当日は Exhibition スポンサー としてブースを出展します！ 今回のブースでは、事業と開発がどのように連携してPark Directをはじめとしたマルチプロダクトを進化させていくのか、CTOやPdMが直接お話しさせていただきます。

今回は新しいノベルティや、ニーリーのカルチャーを感じていただける展示をご用意して皆様をお待ちしております。 スタンプラリーも開催されるので、ぜひお気軽にお越しください。

セッションの合間や休憩時間に、ぜひニーリーのブースへ遊びに来てください。 事業の話、プロダクトの話、組織の話までざっくばらんにお話ししましょう！

CTO三宅は当日の懇親会にも参加予定ですので、会場で多くの皆様とお会いできることを楽しみにしています！！

次世代モビリティインフラへの小さくて大きな一歩を踏み出す〜月極駐車場と1日貸しをつなぐワンデイパークが目指す世界〜

#ニーリー開発組織の野望

こんにちは、株式会社ニーリーでエンジニアリードをしている鈴木正太郎です。 和菓子では上用饅頭が好きです。

先日公開した入社エントリでは、10年働いた会社を離れてニーリーにジョインした理由を書きましたが、今回は、#ニーリー開発組織の野望シリーズとして、私がエンジニアリードを務めるワンデイパークというプロダクトについて、その魅力と可能性、そして開発の舞台裏を書いてみます。

ワンデイパークとは

ワンデイパークは、Park Directに登録されている月極駐車場を、1日単位で貸し出せるサービスです。1日貸しの設定がされた駐車場は、専用のWebサイトから、事前に予約・支払いをすることで、当日は予約した区画に車を停めることができます。

prtimes.jp

ワンデイパークのビジネスモデル

ワンデイパークは約3ヶ月という期間でリリースを行いました。今もなお非常に速いスピード感で開発が進んでいます。2026年2月現在は導入社数が100社を超え、すでに毎日どこかの駐車場がワンデイパークで予約されている状態です。

Park Directという月極駐車場のサービスを軸に展開してきたニーリーには、すでにPark Direct for Businessという2つ目のプロダクトもありました。しかし、ワンデイパークのリリースによって、いよいよ本格的にマルチプロダクトの会社としての歩みを始めます。

ワンデイパークの強みと特徴

ワンデイパークの強みは大きく3つあります。

  1. No.1のPark Directが抱える駐車場にアプローチができる
  2. 月極の空き状況とシームレスにつながる
  3. 単なるクロスセルにとどまらないシナジー

1. 業界No.1の駐車場すべてにアプローチができる

Park Directは、業界No.1*1の月極駐車場のオンライン契約サービスです。ワンデイパークはこの駐車場をベースに展開できます。1日貸しの駐車場予約サービスにおいて駐車場のシェアは競争力に直結するため、これは非常に大きなアドバンテージです。

また、すでにPark Directをご利用いただき信頼を築けている管理会社様へのアプローチとなるため、導入も非常にスムーズです。データ登録も、既存の駐車場情報に対して「1日貸し」の設定を有効にするだけで完了します。この導入障壁の低さが、圧倒的な立ち上がりの速さにつながっています。

2. 月極の空き状況とシームレスにつながる

ワンデイパークのもう一つの強みは、月極駐車場の空き状況や手続き状況とシームレスに連携できることです。例えば、以下のような運用が可能になります。

  • 月極駐車場の空き区画を1日貸ししながら、月極の申し込みが入ったら1日貸しの貸し出しを自動で停止する
  • 月極契約が解約されたら、自動で1日貸しの貸し出しを始める
  • マンションの駐車場で、月極は入居者のみに限定しつつ、1日貸しだけは広く貸し出しする

ダブルブッキングを防ぎながら、駐車場の収益機会を最大化する運用が実現できるのです。

これは、Park Directという月極駐車場の管理システムを持っているからこそできることです。月極と1日貸しが別々のシステムだと、こうした連携を手動で行う必要があり、手間がかかる上にダブルブッキングのリスクもあります。実際、ワンデイパークの導入を決めていただいた不動産管理会社様の多くが、まさにそこを課題に感じていました。

3. 単なるクロスセルにとどまらないシナジー

ワンデイパークとPark Directの関係性は、単純なクロスセルにとどまりません。これこそ私がワンデイパークが今後「モビリティインフラ」を牽引すると確信している理由なので詳しく語りたいところなのですが、極めてシンプルにまとめると、

Park Directの市場拡大が、そのままワンデイパークの成長に繋がる。そしてワンデイパークが1日貸しのニーズに応えることにより、Park Directの営業力を強化する。

という理想的な好循環が生まれています。ワンデイパークは単なる1つの新規事業ではなく、事業間の強力なシナジーを生み出すための新たな柱なのです。

ワンデイパークのワクワクの裏にある難しさ

新規プロダクトの立ち上げは、ワクワクする一方で多くの困難も伴います。 事業は急激に成長していますが、急成長ゆえの課題も山積しています。 リリースからまだ日は浅いですが、すでに技術的な課題と日々闘っています。

月極駐車場とのシームレスな連携の難しさ

ワンデイパークの事業面での大きな強みである「月極駐車場とのシームレスな連携」は、技術的な面では大きな挑戦でもあります。

Park Directは多機能ゆえに仕様が複雑化しており、駐車場区画の状態一つとっても様々なレイヤーでステータスが管理されています。 そこに1日貸しによる区画の状態が追加されるので、ワンデイパーク・Park Directどちらからでも、整合性を保ちながら貸出可否を判断する必要があります。

特に頭を悩ませているのが、既存のデータモデルと現実の運用のギャップです。 例えば、「月極としては募集停止中（データ上は『満車』）だが、実際には空いているため1日貸ししたい」といった現場のニーズへの対応です。これに応えるため、現在は運用での回避や、本来は行わない設定で対応しているケースがあります。 このような「現実とデータの乖離」をシステムで正しく吸収するために、現在はアーキテクチャチームと連携し、根本的なデータモデルの再設計を含めて様々な対応に取り組んでいます。

事業の変化による負債との付き合い方

新規プロダクトを立ち上げる際、既存システムとどう向き合うかは重要な判断ポイントです。

ワンデイパークでは当初、「将来的にPark Directからシステムを切り離せるようにしたい」一方で、「最速でリリースしなければならない」という相反する要件がありました。 そこで、バックエンドのコードベースは共有しつつDjangoアプリケーションだけを分割し、駐車場データをレプリケーション（複製）して参照する設計を採用しました。「月極と1日貸しは独立していたほうがサービスとして扱いやすいだろう」という仮説があったからです。

しかし、ビジネス検証が進むにつれ、この仮説は覆りました。むしろ「月極と1日貸しのデータを密に連携させること」こそが競争優位性になると判明し、切り離しを前提とした設計は、逆にプロダクトの負債になってしまったのです。

そこで正式リリースの2ヶ月後には方針を転換し、レプリケーションを廃止してデータを共有する構成に変更する判断をしました。すでに変更は完了していますが、負債を早めに解消したことによって、機能追加するに当たっての考慮事項が減っていることを実感しています。

速く走るために作った仕組みでも、状況が変われば潔く捨てる。ビジネスの解像度が上がったタイミングを見逃さず、開発スピードを落とさないように負債を解消していく。このバランスを大切にしています。

短期リリースの舞台裏

冒頭で述べた通り、ワンデイパークは約3ヶ月というスピードでリリースを行いました。このAI時代におけるMVP開発としては十分な期間に感じるかもしれませんが、Park Directとの連携の作り込みの程度から考えると、かなり短納期でのリリースでした。スタートアップにおいて「市場に問いを投げるスピード」は命なので、早くリリースするために工夫を凝らしました。

決断したトレードオフ

リリースに向けて、多くの「今はやらないこと」を決めました。

例えば、直前で発覚したデータモデルの不備による仕様のねじれを、影響度合いとその範囲を慎重に見極めた上で「積み残し」として許容しました。また、お問い合わせフォームの実装も見送り、PoCと同様に電話対応のみでスタートするという判断も下しました。

もちろん、こうした判断は開発チーム内部で完結する話ではありません。 リスクとメリットを提示し、社内のワンデイパークチームの方々と密に連携して合意形成を行いました。 リリース前にはCEO、CTO、ビジネスチームの執行役員を含む多くのメンバーにプロダクトを触ってもらい、直前までフィードバックをもらいながら、プロジェクトメンバー全員で盛り上がりながらリリースを迎えることができました。

なお、上記で挙げた積み残し部分は、リリース後に順次解消しています。 このスピード感あるリリースがあったからこそ、早期に営業活動を開始でき、ビジネスチャンスを最大化できたと確信しています。

リリース後の最大の山場

ファーストリリース自体は完遂しましたが、実はその裏には非常に大きな「今はやらないこと」がありました。 それは、管理画面の機能をすべて落とすことです。開発工数を削減するため、リリース当初は管理画面を作らず、BaseMachinaというツールを用いた機能外運用でカバーすることにしていたのです。

リリース後、管理画面の機能を実装する段階になったときは、画面イメージこそありましたが、細部の仕様は詰め切れておらず、根本的な部分で既存の実装とコンフリクトする箇所もいくつかありました。そのため、改めて機能要求の整理から始める必要があったのです。

すでに強力な営業メンバーの活躍により受注は順調に増えていました。しかし、不動産管理会社様に安心して導入を決めていただき、更に事業を伸ばしていくためには、やはり管理画面の存在が不可欠です。一方で、「月極駐車場とのシームレスな連携の難しさ」に記載した通り、様々な状態を考慮した「ちゃんとした」管理画面をリリースするには、どうしても長い時間がかかってしまいます。

そこで最終的には、管理画面だけですべてを完結させることにこだわらず、BaseMachinaとの並行運用を一時的に行う判断をしました。その上で、データの不整合を即座に検知できるアラート機構を整備する。このように安全性を担保しながら段階的に移行することで、この最大の山場を乗り切りました。

[野望]これからのワンデイパーク - 次世代モビリティインフラへ

ワンデイパークの目指す世界は、単なる「月極駐車場の空車を有効活用するサービス」以上のものです。

ゆくゆくは駐車場という土地の管理をニーリーにすべてお任せいただき、その中で1日貸しや月極など柔軟な駐車場の貸し出し方・利用の仕方を可能にすることで、モビリティインフラとして社会に様々な価値を提供できるようになります。

例えば、駐車場を起点としたカーシェアリング、駐車場での充電サービス、駐車場を活用したラストワンマイル問題の解消、関連サービス提供による月極駐車場の賃料負担の軽減など。駐車場という物理的な拠点を抑えているからこそ、リアルとデジタルをつなぐ様々なサービスが展開できます。

このような、必要とされている価値を届けられるサービスをどんどん世に送り出していきます！

エンジニアとして、ワンデイパークを作る面白さ

記事が長くなってしまったので、今まで書いた内容をエンジニアとして「今」ワンデイパークを作っていく面白さという観点で整理します。

事業の伸びをダイレクトに感じられる

新規プロダクトの立ち上げフェーズだからこそ、事業の立ち上がりをダイレクトに感じられます。事業のトップラインを伸ばすために「何を作らないか」を決める裁量をエンジニアが持ち、ワンデイパークに関わるメンバーと議論しながら仮説検証を回せる機会はかけがえのないものだと思います。

単なる「技術的な正解」よりも「今、事業が勝つための最適解」を自ら主導して定義し、実行できるのが今のフェーズの醍醐味です。これによって、受注や利用数がダイナミックに変化する。これを体感できるのは今のフェーズだからこそだと感じています。

toBとtoCの両面を経験できる

ワンデイパークもPark Direct同様に、管理会社様向け（toB）と駐車場利用ユーザー向け（toC）の両面があります。 例えばB側の管理画面に加えた一行のロジックが、C側のユーザーの利便性をダイレクトに向上させることにつながります。

「管理会社が空きを登録しやすくなる（B）」→「街中の予約可能枠が増える（C）」→「ユーザーがより便利に移動できる」→「管理会社の収益が増える（B）」

この一連の流れを俯瞰し、「システム全体の整合性」を保ちながらプロダクトを成長させていく経験は、toBもしくはtoC単一の領域だけでは決して得られない、プロダクトエンジニアとしての大きな武器になります。

このようにtoBの複雑な業務要件と向き合いながら、toCのユーザー体験も設計する。 それ故に、事業を伸ばすポイントもたくさんあるし、やるべきことも多岐にわたります。この幅広さが開発としての醍醐味です。

複雑な問題を解決できる

月極駐車場とのシームレスな連携、急激な成長に耐えうる設計、コストと体験の両立。ワンデイパークには、複雑な問題が山積しています。 Park Directという巨大な既存システムの制約と向き合いながら、いかにシンプルで拡張性の高い新システムを構築するか。 リアルな駐車場というアセットを、いかにソフトウェアで柔軟に、かつ堅牢に制御するか。この複雑な問題を解くことこそが、エンジニアとしての腕の見せ所です。事業に直結する複雑な問題を解決して、ビジネスの成長を自分たちが牽引するのはとてもワクワクします。

事業の拡大フェーズを「最初から」経験できる

ワンデイパークはまだ始まったばかりです。1日貸しから始まり、将来的にはカーシェアや充電サービス、月極では賄えない一時貸しなど、駐車場を起点とした様々なサービスへと広がっていく可能性があります。 この拡大フェーズを「プロダクトが安定してからの途中参加」ではなく「最初から」経験できるのは、今このタイミングだからこそ。短期的な課題解決だけでなく、中長期を見据えた設計や意思決定に関われることは、エンジニアとしての大きな成長の機会だと感じています。

一緒に働く仲間を募集しています！

ワンデイパークは、まだまだ始まったばかりです。 これからもっともっと機能を充実させ、事業を成長させ、これからリリースしていくプロダクトと共に次世代モビリティインフラへと進化させていく必要があります。

そのためには、一緒に挑戦する仲間が必要です。

  • 複雑な問題を解決することにワクワクする方
  • 事業の立ち上がりをダイレクトに感じながら働きたい方
  • toBとtoCの両面を経験したい方
  • 長期的な視点で、プロダクトと事業を成長させたい方
  • チームで一体となって、困難を乗り越えることを楽しめる方

そんな方と一緒に働けることを、心から楽しみにしています。

駐車場という一見地味に見える領域ですが、その先には大きな可能性が広がっています。次世代モビリティインフラを、一緒に作っていきませんか？

ご興味のある方はぜひカジュアル面談からお気軽にお話ししましょう。一緒にワクワクする未来を作れることを楽しみにしています。

nealle.notion.site

*1:「月極駐車場のオンライン契約サービス」の「導入社数」（サービス導入をしている不動産管理会社数）と「オンライン契約可能台数」、「オンライン契約者数」について、2025年11～12月の株式会社未来トレンド研究機構によるサービス提供事業者に対するヒアリング調査およびデスクリサーチ。

数GBのLLM用モデルを、LambdaでLinuxシステムコールを駆使して本番水準で動かす

AWS AI

はじめに

お疲れ様です。2357giです。先日のre:Inventで参加したセッション「Build high-performance inference APIs with Lambda SnapStart」にて、「数GB級のLocal LLMをサーバレスで、本番環境の要求水準で動かす」方法を学んできました。
(その際のセッション形式が「チョークトーク」というもので、めちゃめちゃ良い体験だったのですがその話はこちら )

llama.cppなどの比較的軽量なLLM(1GB~5GB)や、それらと同程度のサイズの自作モデルをLambdaを用いて動かすというものです。
bedrockにカスタムモデルインポートがある現在、本アーキテクチャに優位性があるケースは多くないと思います。セッション中でも「YOLOなどの画像認識や、10 GBに収まる言語モデル、文字起こしなどのモデル組織に合わせてカスタム化されたモデルで、且つ高スループットと低レイテンシーを必要とするケースに適している」と語られていました。
が、Lambdaのパッケージサイズ制限に収まらないモデルを動かす方法や、そのLambdaを本番環境レベルのレイテンシ(1~2s)で動かす方法など技術的面白ポイントが多かったので、そういった点を中心にレポートしていきたいと思います。

正月休みの自由研究として、公式のサンプル実装を先に見ずにまず実際に手元で実装し検証してきたので、そこで得た躓きポイントも含めてレポートしていきたいと思います💪
AWSによるサンプル実装はこちら
AWSによる関連ブログはこちら (車輪の再発明にはなりますが、長期休みの自由研究なので😎 )

セッションの中で、数GB級のLocal LLMをサーバレスかつ本番環境の要求水準で動かすにあたって、大きく以下3つのポイントとして語られていました。

  • 数GBのモデルと、Lambdaパッケージサイズ制限
  • コールドスタートの問題
  • LLMに求められるストリーミングの実現

それぞれ解説していきます🙌

(*情けない前置きと保険になってしまいますが、本記事内で出てくる「セッションの内容を元にした情報や説明」は筆者の乏しい英語力と、LLMによる文字起こしを根拠にしているので、誤情報が含まれる可能性があります。ご容赦ください 🙇️)

数GBのモデルと、Lambdaパッケージサイズ制限

Lambdaのパッケージサイズには厳しいサイズ制限が存在します。zip Lambdaの場合は250MB、 OCI(Open Container Initiative)の場合は10GBです。数GBのモデルを動かそうとする場合、zip Lambdaではまず不可能です。しかし、無邪気にOCI Lambdaを使用して数GBのモデルをLambdaに乗せようとするとコールドスタートが長くなる可能性があります。10秒以上のコールドスタート時間が発生するケースもあります。
この問題について、re:inventのセッションでは、「モデルをS3に配置し、実行時にLambdaの実行環境にロードする」というアプローチが紹介されていました。
ただ、シンプルにS3からロードしようとすると、Lambdaの /tmp ディレクトリが512MBに制限されているという、また別の壁が立ちはだかります。

通常、Lambdaの /tmp (エフェメラルストレージ)は最大10GBまで拡張することができますが、本番環境で求められる水準で動かすとなると、コールドスタートによる遅延に対処するために後述するSnapStartを有効化する必要があります。
しかし、SnapStartは512MBを超えるエフェメラルストレージに対応していない為、この制限が出てきます。

この/tmp制限を回避するために、S3 SDKのPython Boto Streamを使用して、メモリに直接ストリーミングする方法があります。
しかし、llama.cppなどlocal llmで推論を用いるためにはファイルディスクリプタ、つまりファイルパス必要になります。
これを解決するために、Linuxのシステムコールであるmemfd_createを利用して、インメモリファイルを作成し、次にS3ファイルをダウンロード、そのmemfdへ直接書き込みを行います。
非常に面白いハックで、S3からダウンロードしたモデルデータをディスク(/tmp)を介さず、直接メモリ上に「仮想ファイル」として作成する仕組みです。
これにより、ディスクI/Oのオーバーヘッドをゼロにし、/tmpをバイパスしてファイルを読み込むことで容量制限を完全に回避できます。

memfd_createでインメモリファイルの作成

    libc = ctypes.CDLL("libc.so.6", use_errno=True)
    MFD_CLOEXEC = 1  # Close the fd when executing a new program
    
    memfd_create = libc.memfd_create  # インメモリファイルの作成
    memfd_create.argtypes = [ctypes.c_char_p, ctypes.c_uint]
    memfd_create.restype = ctypes.c_int
    
    fd = memfd_create(b"model", MFD_CLOEXEC)

サンプル実装リンク

S3 マルチパートダウンロードを用いてmemfdへ書き込み

    # Create memory file
    fd = create_memfd()
    
    # Pre-allocate the full file size
    try:
        os.ftruncate(fd, file_size)
    except OSError as e:
        logger.error(f"Failed to allocate {file_size/1024/1024:.2f}MB in memory: {e}")
        cleanup_fd(fd)
        raise RuntimeError(f"Not enough memory to load model of size {file_size/1024/1024:.2f}MB")
    
    # Calculate parts for parallel download
    parts = []
    for start in range(0, file_size, chunk_size):
        end = min(start + chunk_size - 1, file_size - 1)
        parts.append({'start': start, 'end': end})
    
    logger.info(f"Downloading {file_size/1024/1024:.2f}MB in {len(parts)} parts")
    
    # Download parts concurrently using ThreadPoolExecutor
    download_func = partial(download_part, s3, bucket, key, fd)
    with ThreadPoolExecutor(max_workers=multiprocessing.cpu_count()) as executor:
        executor.map(download_func, parts)
    
    # Create a path that can be used to access the file
    fd_path = f"/proc/self/fd/{fd}"
    return fd, fd_path

サンプル実装リンク

LambdaからLinuxのシステムコールを呼び出すという概念が無かったので流石に痺れました。

実際にこの手法を試し、ファイルサイズが4.5GBもあるllama-2-7b-chatモデルをLambda上でロードすることに成功しました。

コールドスタートの問題

memfd_createでモデルのロードは成功したものの、そのまま呼び出すとコールドスタートの所要時間が絶望的に長い状態でした。
サンプル実装よりも使用しているモデルサイズが大きいこともありますが、以下のような計測値になっていました😇

フェーズ 所要時間
S3ダウンロード(4.5GB) 62-63秒
推論など 20-25秒
合計 84-87秒

そこで、セッション中で紹介されていた解決策である「Lambda SnapStart」を導入しました。 これは、関数の初期化フェーズ(今回のケースではモデルのS3ダウンロードとメモリへのロード)を完了した状態をスナップショットとして保存し、次回以降はそのスナップショットから高速に復元する仕組みです。
スナップショット時の処理はモジュールレベルで、ハンドラーの外側に記述しておくことで、Lambda関数のデプロイ時(厳密にはalias発行時)に行われます。

SnapStartの適用により、S3ダウンロードの時間をまるまる削減することに成功しました。

フェーズ 所要時間
スナップショット復元時間 4.1-4.4秒
推論時間 17.1-17.2秒
合計 21-22秒

間話: 推論の高速化

推論時間に20秒もかかるのはとても辛いのでパラメータチューニングを行い、8秒ほどに短縮しました。
これはモデル固有のチューニングであるので詳細は省きますが、割り当てられたCPUリソースを使い切るthreads数を指定していなかったというオチでした😇

LLMに求められるストリーミングの実現

次なる目標は、LLMチャットなどに不可欠な「レスポンスのストリーミング」の実現です。 re:Inventセッションでは「Lambda Web Adapter + FastAPI」というアーキテクチャが紹介されていました。これはLambda内でWebサーバーを動かし、Lambda Function URLs経由でストリーミングを実現するものです。 Lambda内でLLMの回答生成が完了するまでバッファリングすることなく、逐次回答していくことにより、結果として最初の1トークン目がクライアントに届くまでの時間(TTFT[^Time To First Tokenの略])を、Warm Start時には 1~3秒 ほどまで短縮することに実現しました🎉

フェーズ 所要時間
ColdStart時のスナップショット復元時間 4.1-4.6秒
TTFT 1.1-3.8秒
合計 1.1-8.4秒

この辺り、筆者は5GB近いサイズのモデルを利用しているためこの時間ですが、モデルの選択やスペックによってはもっと早くいけると思います。実際にサンプル実装では1GBほどのモデルにより1~2秒でのレスポンス速度を実現してるとのことです。

ハマりポイントとして、Lambda Web Adapte(LWA)を有効化したところ、SnapStartのためのINIT処理が失敗するようになりました。具体的にはモデルのロード中に失敗してしまう状態です。 原因はLWAがモデルロードの完了を待たずに初期化処理を完了していた点でした。 LWAは同期/非同期２種類の初期化モードを持ちます。非同期モードの場合、LWA自身のReadiness Check(/health等への応答確認)が成功した時点で、Lambdaサービスに対して「INITフェーズ完了」を報告してしまいます。
AWS_LWA_ASYNC_INIT='false'(同期初期化モード)を使用することにより、モデルのロードを待ってINITフェーズの完了とすることになります。この辺りは自前実装をしないと理解に繋がらないポイントだと思うので、良い学びでした。

まとめ

今回はLocal LLMをLambdaで実行するという少し珍しいケースでしたが、この検証を通じて得られた知見は、他の多くのケースでも応用できる汎用的なものばかりでした。

  • memfd_createは、LLMに限らず、機械学習のモデルファイルや遅延呼び出し可能なライブラリなど、GB級のファイルをLambdaで扱う際の強力なテクニックになりそう
  • SnapStartは、モデルのロードだけでなく、DBコネクションの確立や重いライブラリの初期化など、初期化処理が重いあらゆるLambda関数で有効なコールドスタート対策
  • Lambda Web Adapterは、PythonランタイムのLambdaでFastAPIなどの標準的なWebアプリケーションフレームワークを動かすための非常に強力なツールであり、ストリーミング以外にも様々なユースケースが考えられる

ちなみに余談ですが、本セッションの登壇者はLWAの開発者でもありました。
「Pythonランタイムは、今のところ応答ストリーミングを公式にはサポートしていません。幸いなことに、私が作成したLambda Web Adapterというツールがあります。」はウケました(会場もウケてた)。
いやー本当に良い経験をしました。チョークトークに参加して良かったとしみじみ思います。

それではみなさん、良きサーバーレスライフを👋