AI前提の開発で品質とスピードを両立するNOTAコンシェルジュチームの取り組み

こんにちは、Software Engineerのメントス (@m_t_tion1) です。私は2026年6月に入社し、現在はコンシェルジュチームでバックエンドを主に担当しています。
本記事では、コンシェルジュチームの持つプロダクトとその開発体制を踏まえて、AI前提の開発で品質とスピードを両立するために取り組んでいることを紹介します。

扱っているプロダクトと特性

コンシェルジュチームは、以下の内製プロダクトの開発と運用をしています。

Kevinが担う役割や描く姿に関しては、こちらの記事で詳しく紹介されています。ぜひご覧ください。

NOT A HOTELに滞在中、オーナーさまが質問や依頼をする場合は、コンシェルジュチャットがメインの連絡手段となります。
例えば、チャットの送受信ができなくなったり、Kevinが適切に応答できなくなったりすると、オーナーさまの体験を大きく損なうだけでなく、CSの業務にも影響します。
つまり、品質を落とすと各方面に大きな影響を与えるため、リリースの際には細心の注意を払う必要があります。

チーム構成と開発体制

2026年10月時点で、チームは私を含めた全員が、2026年4月以降に入社または他チームから異動してきたメンバーです。
内訳は、PdMが1人、エンジニアが4人で、エンジニアはそれぞれ専門領域 (iOS/Webフロントエンド/バックエンド) が異なります。
プロダクト開発は、全員がAIを使う前提で、次の流れを短いスパンで繰り返しています。

AIを活用することで、PdM自身がプロトタイプの作成から実装、PRの作成まで担い、本番リリースにつなげることも珍しくありません。
このように、専門領域の異なる少人数のチームで、3つのプロダクトを並行して開発しています。では、この体制で品質とスピードをどう両立しているかについて、実際の事例を紹介します。

事例紹介

1. 迅速に異常を検知して対応できるようにする

冒頭で述べたとおり、コンシェルジュチームのプロダクトは、品質を落とすと大きな影響が出ます。そのため、リリースとオブザーバビリティの部分を最も重視しています。
リリースでは、次の2つを徹底しています。

慎重さが求められるからこそ、一度に大きく出すのではなく、小さく出してすぐ戻せる状態を保つことを安全策にしています。
オブザーバビリティの面では、エラーやインフラのメトリクスに対するアラートといった基本的な監視に加えて、OpenTelemetryで計装し、1つのリクエストのうちどの処理に時間がかかっているかをトレースとして記録しています。

検知と計測の仕組みを先回りで入れておくことで、異常が起きたときは、AIが推測ではなく実データを起点に調査できます。人はその結果をもとに判断に集中できるので、専門領域に関係なくすぐ対応に移ることができています。

2. 全体感を把握した上でプロダクトの裏側のあるべきを描く

スモールチームで一つのプロダクトに集中すると、コンテキストスイッチが減り、その領域に特化できます。その反面、次のような問題が起きがちです。

また、専門領域がiOSやWebフロントエンドのエンジニアも、インフラを含めたバックエンドの設計まで一気通貫で行います。そのため、安心して開発できるようにいつでも壁打ちできる体制が必要と考えていました。
そこで私は、メインで担当するコンシェルジュチャット基盤に加えて、他2つのプロダクトの以下の部分に絞って理解することを重要視しています。

日々のミーティングでこれらの認識を必要に応じて更新し、できるだけ同じ目線で話せるようにしています。
結果として、各プロダクトを複数人が理解している状態になっています。その上で、設計を考える際も、全体を踏まえてどうあるべきかを議論できています。

3. レビューする領域を限定する

インフラやDB/API設計の部分に限定して、実装者と適宜会話して意図を確認しながらPRレビューをしています。
特に、オーナーさまの情報を扱うプロダクトとして、データの取り扱いやアクセス制御など、影響の大きい変更についてはエンジニアが重点的に確認しています。
これらの部分は、一度運用に乗ると、AI前提の開発といえども変更に工数と考慮を要するものです。そのため、従来と変わらず、拡張性の高い設計を可能な限り目指してこのアプローチをとっています。

一方で、PdMのPRも含め、それ以外の変更はテストとAIによるコードレビュー・セキュリティレビューで問題が検出されなければ、マージできる運用としています。
短期間で大量のPRが作られるため、実装者とレビュアー双方の負担を減らし、スピードを落とさないための判断です。その代わり、振る舞いはテストとQAで担保しています。

テストは、ユニットテストに加えてAPIレベルのE2Eテストも書き、そのケースが妥当かは実装者自身が確認します。
マージ後に直したい箇所が出ても、修正自体はAIですぐ作れます。だからこそ、少しでも安全に直せるよう、振る舞いをテストで守る仕組みづくりに重きを置いています。

QAでは、すべてをAIに任せず、私たち自身で動かして挙動と手触り感を確かめています。リリースの頻度をさらに上げるとボトルネックになりうる部分です。しかし、LLMを使っていて出力が確率的に変わり、品質も落とせないプロダクトであるため、今はここを人が担うことを優先しています。

4. 意図的に立ち止まって振り返る時間を作る

機能開発が目まぐるしい中で、週1回意図的に立ち止まって振り返る時間を作っています。
具体的には次のようなことをしています。

このうち、食い違ったコメントの洗い出しやパフォーマンスの集計は、毎週AIが自動で行い、修正できるところはDraft PRまで作ります。私たちは、その結果を確認しつつ、何を直すか、繰り返す課題をどう仕組みで防ぐかを判断することに集中します。
例えば、実装とコメントが食い違っている箇所が見つかれば、コードからは分からない意図や背景だけを残し、それ以外は削除しました。加えて、再発しないように、このルールをAIレビューに組み込みました。

このように、気付いたことをその都度直し、仕組みで防ぐことで、AIが迷わず自走できるコードベースを保つよう取り組んでいます。AIで作るスピードが上がった今、作るだけでなく「作って直す」サイクルを回し続けることが大事だと考えています。

まとめ

今までのプロダクト開発でやってきたことのうち、AIに任せられる部分を広げ、人は設計の確認や判断など、集中すべきところに注力する形に落ち着いています。
もちろん、これは一般的な正解ではなく、今の私たちのやり方の一つです。数週間後には違うアプローチをとっているかもしれません。
しかし、NOTAが大切にしている「超ワクワクな体験を届ける」という目指す先は変わりません。それをより高速に実現するにはどうすればよいかを考えながら、日々改善を続けていきます。

NOTAでは、一緒に働く仲間を募集しています。気になった方は、ぜひ採用ページものぞいてみてください。
テクノロジー関係中途採用はこちら
採用全般はこちら
カジュアル面談からでもお気軽にどうぞ！