luxonis-project-interview

Luxonis プロジェクトのヒアリング

後の Luxonis ビルドセッションで利用できる、平易な言葉で書かれたプロジェクト仕様書を PROJECT_BRIEF.md に作成してください。

完了とは、アプリが実行できる状態になることではありません。完了条件は次のとおりです。

1. エージェントの現在の作業ディレクトリに PROJECT_BRIEF.md が作成されている。
2. ユーザーに内容を確認してもらう。

ヒアリングは製品／アプリケーションレベルにとどめます。ユーザーにとって初めての Luxonis とのやり取りである可能性を考慮してください。

ルール

• 一度に質問は1つだけにしてください。
• 各質問では、なぜそれが重要かを説明し、役立つ場合は推奨またはデフォルトの回答を示してください。
• DepthAI、ノード、パイプライン、RVC、モデル変換、キュー設定、oakctl、Hub、OAK アプリの内部仕様について質問しないでください。
• ローカルファイルや Luxonis のドキュメントから事実に関する質問の答えが得られる場合は、質問せずにそれらを参照してください。
• unknown／not sure yet という回答も受け入れますが、まずおおまかな回答を一度だけ促してください。
• 仕様書を作成可能にするために必要な、次の質問だけをしてください。
• $PWD 内では PROJECT_BRIEF.md 以外のファイルを編集しないでください。

1. 事前確認

ヒアリングの前に、現在の作業ディレクトリだけを確認してください。ディレクトリの内容を一覧表示し、次のファイルが存在する場合は読み込んでください。

• PROJECT_BRIEF.md
• DEVICE.md
• README.md
• pyproject.toml、requirements.txt、package.json など、明らかなプロジェクトマニフェスト
• 明らかなソースファイル／サンプルファイル

AGENTS.md や CLAUDE.md はヒアリングの情報源として読まないでください。これらはエージェント向けの指針であり、顧客プロジェクトの情報ではありません。

スキルに初期アイデアが渡されている場合は、それを1文で要約し、そこから推測した項目は暫定的なものとして扱ってください。

PROJECT_BRIEF.md がすでに存在する場合：

• 記載内容を要約してください。
• ユーザーが同じプロジェクトを続ける場合は、既存ファイルをそのまま更新してください。
• 別のプロジェクト案の場合は、処理を中止し、専用の別フォルダーからスキルを実行するようユーザーに伝えてください。

DEVICE.md が存在する場合は、デバイスに関する情報として利用してください。存在しない場合は、デバイスについて平易な言葉で質問してください。ユーザーがまだデバイスを持っていない場合は、そのまま続行し、未確定事項として記録してください。

2. インタビューの基本項目

必須項目について確認します。事前確認やユーザーの最初のアイデアですでに回答されている項目は飛ばしてください。

1. デバイスの有無 -- 「最初のデモに使うLuxonisのカメラ／デバイスをお持ちですか？まだお持ちでない場合は、not yetとお答えください。」
2. 希望する実行場所 -- 「最初のデモは、カメラを接続したノートパソコン／コンピューター、小型の現場設置用コンピューター、コンピューターを接続せずカメラ上で直接実行する方法のどれがよいですか？それとも、まだ分かりませんか？」
3. 実世界での目的 -- 「これによって、現実の場面で誰かが何をできるようになったり、何を判断できるようになったりするとよいですか？」
4. デモの主な動作を1つ -- 検出／分類、カウント、動きの追跡、測定、テキスト／コードの読み取り、ナビゲーションの案内、証拠の保存、または別の単一の動作。
5. 対象／イベント -- 対象となる物体、人、動作、状態、イベントを、顧客が使う言葉で具体的に確認します。
6. 最初のシーン -- カメラの設置場所、視野に入るもの、おおよその距離、シーンを難しくする要因。
7. 出力／アクション -- うまく動作したときに、ユーザーが何を見て、保存し、受け取り、または実行するか。
8. 成功基準 -- ユーザーから指定がない限り、MLの指標ではなく、デモで確認できる項目を設定します。
9. サンプルメディア／再生 -- 実装と検証のために、写真、動画、または実際のシーンを短く録画したものを撮影できるかどうか。
10. 最初のデモとその後 -- 価値を示すための最小限のデモと、後回しにする内容。

ユーザーが行き詰まった場合に限り、簡単な例を示します。主な動作の例：

• エリアに入る人をカウントする
• 制限区域にいる作業員を検出する
• 物体の位置や距離を測定する
• ラベル、テキスト、コードを読み取る
• ロボットが障害物を避けて進めるよう案内する
• 何かが起きたときに画像やイベントを保存する

希望する実行場所について、プラットフォーム用語を説明しないでください。内部的には、デバイスによってはコンピューター／サーバーへの接続が必要で、カメラ単体での動作に対応できるものもあると把握しておきます。ユーザーがカメラ単体での動作を希望する場合は、選択したデバイスが対応していることを今後の作業で確認するという前提を記録します。

ドラフト作成の条件： 基本項目がすべて回答済み、または不明／仮定として明示されたら、最初のドラフトを作成します。その時点以降は質問を続けないでください。条件に応じた追加質問は、最初のデモに大きく影響する場合にのみ行います。

3. 条件に応じた追加質問

インタビューを網羅的なコンサルティング用チェックリストにしないでください。最初のデモや実現可能性に大きく影響する場合にのみ、以下を確認します。

• 誤検知 -- 対象が曖昧な場合：「見た目が似ていても、無視すべきものは何ですか？」
• プライバシー -- 人、顔、ナンバープレート、私的な場所、または機密性の高い映像が映る可能性がある場合。
• インターネット／オフライン -- クラウドサービス、モデルのダウンロード、リモートダッシュボード、またはオフラインでの使用が話題に出た場合。
• ゾーン／ライン／領域 -- カウント、安全性、測定、棚、出入り口、通路、またはアラートが、画像内の物理的なエリアに左右される場合。
• カメラ1台か複数の視点か -- 1台のカメラではシーン全体をカバーできない場合。
• オペレーターの操作 -- 対象、領域、しきい値、または録画のクリック／選択／設定がデモに必要となる可能性がある場合。
• 連携 -- デモの中核となる動作が明確になってから確認します。
• 対象者 -- デモの評価者によって、出力、アクション、または成功基準が変わる場合。
• スケジュール -- スコープの制約が重要な場合。
• 一般的な対象か現場固有の対象か -- 認識の実現可能性が不明な場合：「これは日常的によくあるものですか？それとも、あなたの事業所／現場／製品／プロセスに特有のものですか？」
• 近似対象 -- 対象が現場固有または特殊に見える場合：「最初のデモでは、近い代替対象でも問題ありませんか？」（例やモデルの準備状況は概要作成後に確認するため、モデルを検索して判断するのではなく、ユーザーの対象の説明に基づいて判断します。）

対象が現場固有と思われる場合は、データセットの収集とモデルのトレーニングが必要になる可能性があると記録します。このワークフローでエージェントがモデルをトレーニングできるとは言わないでください。

4. 認識の一致を見える形に保つ

重要な修正の後、または回答がいくつか続いた後に、認識している内容を簡潔にまとめた一行を示します。

ここまでの内容：ノートパソコンに接続したデモ、店舗入口での人数カウント、ライブビューと イベントログ。次に確認する項目：成功基準。

方向性の確認に役立つ場合に限り、未確認項目のチェックリストを表示します。たとえば、ユーザーが 「ほかに必要なものは？」と尋ねた場合や、聞き取りが長くなってきた場合です。

5. ブリーフを作成する

次の場所にのみ書き込みます。

$PWD/PROJECT_BRIEF.md

Git ルートを検索しないでください。ブリーフを ~/.luxonis/agent-context/ に書き込まないでください。 スクリプト、アプリのコード、DEVICE.md、AGENTS.md、CLAUDE.md を作成しないでください。

目標から簡潔で説明的なタイトルを推測し、# Project Brief: の見出しに使用します。ユーザーが 命名やブランディングを希望していない限り、プロジェクト名を尋ねないでください。

次のテンプレートを使用します。簡潔にまとめてください。情報が不明なセクションには Not specified yet. と記載し、 前提や未解決の質問を記録します。

# Project Brief: <short descriptive title>

## Goal

## Device

## Desired run location

## Target user / demo audience

## First demo scope

## Later / out of scope

## Scene

## Targets / events

## Outputs / actions

## Success criteria

## Sample media / replay

## Constraints

## Assumptions and open questions

このファイルはプロジェクト仕様のみを記載します。ユーザーから明示的に求められない限り、 推奨する実装手順、推奨例、モデル名、Luxonis の技術アーキテクチャを含めないでください。

書き込み後、次のように伝えます。

PROJECT_BRIEF.md を確認してください。間違いや不足があれば教えてください。該当箇所を修正します。

関連するセクションのみを修正します。修正によってプロジェクトの中核が変わらない限り、聞き取り全体をやり直さないでください。

6. ブリーフ作成後の任意のサンプル／モデル準備状況確認

PROJECT_BRIEF.md を書き込んだ後に限り、既存の Luxonis ベースラインを任意で探します。これはブリーフが完成しているかどうかには一切影響しません。

安全な方法で取得した、ローカルの参照チェックアウト ~/.luxonis/agent-context/oak-examples を使用します。

• ユーザーのホームディレクトリに ~/.luxonis/agent-context が存在しない場合は作成します。
• https://github.com/luxonis/oak-examples を HTTPS（SSH は使用禁止）で浅くクローンし、DepthAI v3 を追跡する main に固定します。ネットワークの停止時に処理がハングせず中断されるよう、Git の低速ガード（http.lowSpeedLimit=1000、http.lowSpeedTime=60）を設定します。一時的な兄弟パス（例：oak-examples.tmp）にクローンし、成功した場合にのみ適切なホストシェル用のコマンドで所定の場所へ名前を変更します。これにより、クローンに失敗しても不完全なチェックアウトが残りません。チェックアウトがすでに存在する場合は、早送りのみのプルで更新します。
• チェックアウトに INDEX.md が含まれている場合に限り、使用可能とみなします。クローンに失敗した場合や不完全な場合は、その簡潔な理由を伝えて続行します。ブリーフはすでに完成しているため、不完全なチェックアウトや古い v2 の例には決して依存しないでください。

例を推奨する場合：

1. INDEX.md を使って候補を探します。
2. 選択した例の AGENTS.md を読みます。
3. 実行手順や詳細が必要な場合は、その例の README.md を読みます。
4. これらのファイルに裏付けられた内容のみを説明します。
   • 例でできること
   • 例でできないこと
   • 出力や成功の状態
   • 目標に近い例か、関連するベースラインにとどまるか

Model Zoo のモデルやドキュメントに記載されたパターンが存在する可能性を確認する場合は、https://docs.luxonis.com/llms.txt の Luxonis ドキュメントも使用します。

準備状況の段階は、ブリーフではなくチャットで 1 つ報告します（ユーザーから求められた場合を除く）。

• 既存のベースラインが見つかる可能性が高い — 近い OAK の例、または Model Zoo のモデルがあります。
• 近似的なデモが可能 — 関連する例やモデルはありますが、目標と完全には一致しません。
• データセット／トレーニングが必要な可能性が高い — 既存の例やモデルで適合するものが見当たりません。

データセット／トレーニングが必要な可能性が高い場合は、サンプルの撮影とモデル／データの要件を推奨します。モデルをトレーニングすると断言しないでください。

7. 任意のゼロビルドサンプルの実行

よく似た既存のサンプルがある場合は、まず内容を正確に説明してから、次の質問を1つだけします。

よく似た既存のサンプルが見つかりました。今、お使いのデバイスで実行してみますか？

デバイスの情報が DEVICE.md で確認できた場合に限り、実行を試みてください。ユーザーがヒアリング中に名前を挙げただけのデバイスは確認済みとは見なしません。DEVICE.md がない場合は、代わりに luxonis-device-setup を推奨してください。

ユーザーが同意した場合の実行ポリシー：

• サンプルに記載されているコマンドを使用します。
• 可能な場合は、スクリプト／周辺機器モードを優先します。
• 依存関係のインストールは、隔離されたローカル環境でのみ行います。Python パッケージをグローバルにインストールしないでください。
• ユーザーの明示的な承認がない限り、カメラのフラッシュ、アドプト、工場出荷時設定へのリセット、永続的なインストール／デプロイは行わないでください。
• 適切な場合はスタンドアロン／OAK アプリの実行も可能ですが、永続的な操作を行う前に説明してください。

サンプルの実行に失敗しても、ヒアリングが無効になるわけではありません。PROJECT_BRIEF.md を作成し、レビューを依頼した時点でスキルは完了しています。

8. 次のステップで終える

次に行うと最も役立つことを、簡潔に案内して終えてください。

• デバイスが確認できていない／DEVICE.md がない場合：luxonis-device-setup を推奨します。
• ブリーフを作成済みで、デバイスの準備も完了している場合：luxonis-build-poc を推奨します。
• よく似たゼロビルドサンプルがある場合：まず、その実行を提案します。カスタム作業には luxonis-build-poc を使用します。