Lancey | AI Copilot for Product Teams

Lancey | AI Copilot for Product Teams

Lancey · ライティング · 音声・言語 · マーケティング · その他

Lanceyはプロダクトチーム向けAIコパイロットだ。Slack、Intercom、Zendeskの顧客フィードバックを1つのキューに集め、コードベースにプルリクエストを出してレビューに回す。

Lancey | AI Copilot for Product Teams の画面プレビュー

Lancey | AI Copilot for Product Teams について

About

Lanceyとは

Lanceyはプロダクトチーム向けのWebベースAIツールで、エディタに向かうエンジニアのためのものではない。流れは顧客が実際に求めた内容から始まる。サポート経由のフィードバックを集めてまとめ、タスクに変える。その後ろでコーディングエージェントが動き、レビューできるプルリクエストを残す。

多くのコーディング支援ツールは「何を作るか」が決まっている前提で動く。Lanceyが埋めるのはその手前だ。Slack、Intercom、Zendeskをつなぎ、リポジトリへのアクセスを渡すと、エージェントが関係するファイルを探す。同社はこれをマルチプレイヤーのコーディングエージェントと呼ぶ。チーム全員が同じ作業文脈を共有し、各自が私有のアシスタントを走らせる形ではない。初期ユーザーはトリアージ時間を40%削減したと同社は説明する。ベンダー側の数字であり、独自に検証したものではない。

制約は機能と同じくらい重い。公開価格もドキュメントもセルフ登録もない。サイトは1ページだけで、事例と料金のURLは404を返し、バナーはチームがuseclearline.comで新しいことに取り組んでいると告げる。Lanceyは移行期の製品として扱い、リポジトリの権限を渡す前にロードマップとサポートを確認したい。

はじめかた

  1. lancey.aiからチームに連絡し、利用方法を尋ねる。登録フォームはないので、セルフの試用ではなく会話になると考えておく。
  2. すでに使っているフィードバック元をつなぐ。現時点ではSlack、Intercom、Zendeskだ。
  3. Gitリポジトリへのアクセスを許可し、エージェントにコードベースを索引させ、既存の慣習に従わせる。
  4. 最初のタスク束を確認し、ルールを決める。触れてよい範囲、書き込めるブランチ、マージを承認する人を明確にする。
  5. 最初のプルリクエストは通常のレビュー工程に流す。テストと人の確認を通してから出荷する。

AIツール情報

Lancey | AI Copilot for Product Teamsの料金、対応プラットフォーム、性能を簡単に確認できます。

無料プランいいえ
有料プランNot published
プラットフォームWeb
開発元Lancey
カテゴリライティング · 音声・言語 · マーケティング · その他
リリース日N/A
最終更新Feb 2026
サイト訪問数847
サイト世界ランキング14.1M
API提供状況N/A

こんな人におすすめ

このツールが最も力を発揮するユーザー、タスク、シーン。

ユーザー

  • 小規模SaaSのプロダクトマネージャー
  • サポート責任者とカスタマーサクセス
  • 何でも自分でやる創業者とエンジニア

タスク

  • 1週間分のサポートスレッドをバックログにする
  • 顧客が報告した小さな不具合を直す
  • 修正後の連絡まで閉じる
  • 繰り返す要望を洗い出す

シーン

  • フィードバックが整ったトラッカーではなくチャットとチケットにあるチーム
  • テストスイートと明確なレビュー規則があるチーム
  • ベンダー選定の事前調査をする購買担当

主な機能

Slack、Intercom、Zendeskからのフィードバック取り込み

顧客の声が集まる3か所につなぎ、要望を1つのキューにまとめる。エンジニアがチケットを1枚ずつ読む代わりに、エージェントがメッセージを集め、出所と顧客を残し、重複をまとめる。このまとめがあるから、表計算を手で追わずにプロダクトトリアージが成り立つ。

コードベースの理解

エージェントはリポジトリを索引し、触る可能性が高いファイルを添えてタスクを出す。命名からテストの構成まで、プロジェクトにある型を踏襲するため、レビュー側の後始末が減る。この対応づけの精度は、渡す権限の範囲とコードの整頓具合に左右される。

バックグラウンドでのタスク実行

作業は非同期で進み、エンジニアのエディタもチャット画面も占有しない。まとめて渡し、あとでdiffを受け取る形だ。範囲の狭い小さな修正に向き、設計の議論を先に要する変更には向かない。

優先順位付きのタスクキュー

問題の発生頻度や、声を上げたアカウントなどの信号で並べ替える。重複した報告は1件にまとまり、元の引用は根拠としてキューに残る。重み付けのルールはこちら側で決める。企業の更新1件が小さな不満10件より重いことを、エージェントは知らないからだ。

チームで共有する文脈

ワークスペースは1人の利用者ではなくチーム向けに作られている。全員が同じ顧客フィードバック、同じタスク、同じプルリクエストを見るので、プロダクトと開発の引き継ぎに要約メッセージは要らない。同社はここをコーディングエージェントのマルチプレイヤー部分と呼ぶ。

レビュー可能なプルリクエスト

出力はリポジトリ内の通常のプルリクエストとして届き、コメントできるdiffと、捨てられるブランチが付く。Lanceyが勝手にマージすることはない。既存のレビュー規則、CI、承認の流れがそのまま効く。顧客の不満から生まれたコードに対しては、これが妥当な初期設定だ。

メリットとデメリット

メリット

  • 空のチケットではなく顧客の証拠から始まる。多くのコーディング支援ツールが飛ばしている工程だ。
  • 初期ユーザーでトリアージ時間が40%減ったとベンダーは説明する。第三者の検証はなくても、流れを見れば納得できる数字だ。
  • バックグラウンドで動くため、エンジニアのエディタ時間を奪わない。
  • すでに使っている経路(Slack、Intercom、Zendesk)を使い、新しい受信箱や作り直した業務フローを要求しない。
  • 出力がプルリクエストなので、人のレビューとCIが輪の中に残る。

デメリット

  • 公開価格がなく、サイトから予算を立てることも、商談前にプランを比べることもできない。
  • 公開サイトは1ページに縮み、事例も料金も404で、バナーは新しいプロジェクトを指す。継続性のリスクとして評価に入れるべきだ。
  • リポジトリの権限は重い約束であり、テストが薄いとエージェントのプルリクエストは時短ではなくレビュー作業の追加になる。
  • フィードバックの対応はSlack、Intercom、Zendeskまで。メール、表計算、Linear、Jiraは挙がっておらず、別の経路を使うチームは手作業の書き出しになる。

よくある質問

Slack、Intercom、Zendeskの顧客フィードバックを集め、タスクにまとめ、コーディングエージェントにリポジトリへプルリクエストを出させる。不満を聞いてからレビューできるコードができるまでの間を埋める。