手動でのセットアップを省略したい場合は、このページのリンクをDevinのセッションに貼り付けて、すべてのセットアップを依頼してください。ある開発者がDevinに、APIエンドポイントにページネーションを追加するよう依頼しました。プロンプトは短く、妥当そうな内容でした。 ```txt Original prompt (vague) theme={null} Add pagination to GET /api/users. Run the tests when done. ``` セッションは問題なく完了し、テストも通過し、PRも良さそうに見えました。しかし、本来 **約12 ACU** で済むはずのタスクに対して、**42 ACU** を消費していました。コードベースの他の箇所ではすでに動作しているパターンがある機能にもかかわらず、想定の3.5倍のコストになっていたのです。ここでは、何が問題だったのかを突き止め、同じことを二度と起こさないようにする方法を説明します。すべての完了したセッションでは、無料の [Session Insights](/ja/product-guides/session-insights) 分析を利用できます。完了した任意のセッションの上部のバーにある **電球アイコン** をクリックし、次に **Generate Analysis** をクリックすると実行されます。Advanced セッションは不要です。このページネーションに関するセッションでは、Session Insights によって次の点がフラグ付けされました: * **Issue Timeline** — Devin がアプローチを完全に変えた 14 分と 28 分の位置に赤いマーク。 * **Issues Detected** — 「`src/utils/paginate.ts` が既に存在するにもかかわらず、ページネーションをゼロから実装したため、コードベースに関する前提が誤っていた」と「テストがオフセットベースのページネーションを期待しているのに、カーソルベースのページネーションを使用したため、実装方式が誤っていた」。 * **Improved Prompt** — 不足していたコンテキストを補って書き直されたバージョンで、そのままコピーできます。 * **ACU Usage** — 42 ACU。タスクの規模に対して不相応としてフラグされました。多くのセッションでは、これで十分です。改善版プロンプトをコピーし、新しいセッションを開始して比較してください。しかし、フェーズごとのコスト内訳を完全に把握したい場合は、さらに掘り下げて確認してください。セッションインサイトパネルで **Investigate with Devin** をクリックすると、元のセッションの全履歴があらかじめ読み込まれた Devin セッションが起動します。あるいは、新しいセッションを手動で開始し、分析してほしい内容を記述してください: ```txt Analyze the pagination session theme={null} このセッションでは、GET /api/users にページネーションを追加するために 42 ACU を使用しました。想定は約 12 でした。内訳を説明してください: 1. Devin が異常に長い時間を費やしたのはどこですか？ 2. どのような行き止まりや誤ったアプローチを試しましたか？ 3. もっと効率的にできた点はどこですか？ 4. 私のプロンプトにはどんなコンテキストが欠けていましたか？ 5. これらの問題を避けられるように、構造化された改訂版プロンプトを作成してください。 ``` Devin は元のセッションのすべてのアクションを精査し、時間が非効率に費やされた箇所を特定します: ``` セッション分析 | タスク: GET /api/users へのページネーション追加実際: 42 ACUs | 想定: ~12 ACUs 非効率な点: 1. 不要な調査 — 調査フェーズが異常に長時間かかった Devin はページネーションヘルパーを探して 23 ファイルを調査した。ゼロからページネーションを実装した後、 src/utils/paginate.ts を発見し、すべてをリファクタリングする必要が生じた。修正方法: プロンプトに既存のユーティリティについて記載する。 2. 誤ったアプローチ — 実装全体を書き直す必要があった Devin はカーソルベースのページネーションを実装した。API がオフセットベースを使用しているためテストが失敗し、実装全体をゼロから書き直した。修正方法: プロンプトに「オフセットベース」と明記する。 3. 環境の問題 — インストールの繰り返し失敗プライベートレジストリ用の .npmrc 設定が欠落していたため、 npm install が 2 回失敗した。Devin は回避策を試みながら再試行した。修正方法: リポジトリのセットアップにレジストリ設定を追加する。 ``` 根本原因は3つ。いずれもプロンプトやリポジトリ設定を改善すれば防げます。 Devin に、改善版プロンプトを使って新しいセッションを直接開始するよう依頼できます。コピー＆ペーストは不要です。分析によって、不足していた前提情報を正確に含む構造化プロンプトが生成されます: ```txt Optimized prompt (structured) theme={null} GET /api/users にオフセット方式のページネーションを追加してください。 ## Context - 既存のページネーションユーティリティ src/utils/paginate.ts を使用すること - すでにページネーション済みの GET /api/projects と同じパターンに従うこと - クエリパラメータ: page (デフォルト 1), limit (デフォルト 20, 最大 100) - レスポンス形式: { data: User[], meta: { page, limit, total, totalPages } } ## Implementation 1. page と limit のクエリパラメータを Zod バリデーション付きで追加する 2. Prisma クエリをラップするために src/utils/paginate.ts の paginate() を使用する 3. 上記の形式に一致するページネーション済みレスポンスを返す ## Testing - 既存のテストを npm test で実行する - 結果が 0 件、1 ページ、複数ページのそれぞれでページネーションが動作することを確認する - 不正な page/limit パラメータが 400 を返すことを確認するすべてのテストがパスするまでは PR を作成しないでください。 ``` 2 つのプロンプトを並べて比較します: | | Original | Optimized | | --------------------- | ------------- | ----------------------- | | **Pagination type** | Not specified | "オフセット方式" | | **Existing utility** | Not mentioned | `src/utils/paginate.ts` | | **Reference pattern** | None | "GET /api/projects と同じ" | | **Response shape** | Not specified | 明示的なスキーマ | | **Testing criteria** | "テストを実行" | 具体的なエッジケース | | **ACU result** | 42 ACUs | 約 12 ACUs | この最適化されたプロンプトにより、3 つの根本原因がすべて解消されます。Devin は 23 個のファイルを探索する必要がなくなり、最初の試行で正しいページネーション方式を選択し、実績のあるパターンに従います。 1回のプロンプト書き換えで、1つのセッションのACU使用量を削減できます。そこで得られた知見を恒久的な設定に反映すると、今後のすべてのセッションでACU使用量を削減できます。 **[Knowledge](/ja/product-guides/knowledge) に繰り返し使うコンテキストを追加する。** ページネーションの分析で、Devin が繰り返し必要とする 2 つの事実 (ページネーションの種類とユーティリティの場所) が判明しました。これらを Knowledge のエントリとして追加し、すべてのセッションが自動的にそのコンテキストで始まるようにします。 * *"すべての API エンドポイントはオフセットベースのページネーションを使用しています。共通ユーティリティは `src/utils/paginate.ts` にあります。参照実装として GET /api/projects を確認してください。"* * *"テストは `npm test` で実行します。型チェックは `npm run typecheck` で実行します。"* **[環境設定](/ja/onboard-devin/environment) でワークスペースの問題を修正する。** `npm install` の失敗によって無駄になった 3 ACU は、プライベートレジストリ用の `.npmrc` 設定が欠落していたことが原因でした。レジストリ設定を環境に追加することで、今後のすべてのセッションでこのエラーが発生するのを防げます。 **バッチ分析でチーム全体のパターンを見つける。** 複数の開発者のセッションでACU使用量が高くなっている場合は、いくつかをまとめて分析し、共通する根本原因を特定します。 ```txt 最近のセッションをバッチ分析する theme={null} 今週のセッションを 5 件共有します: [セッションリンクを貼り付け] それらすべてに共通する、ACU の無駄な消費パターンを見つけてください。こうした問題を今後のすべてのセッションで防ぐために、どのような Knowledge エントリを追加すべきですか？ ```

{title}