PRDテンプレート（+コピーしてすぐ使える完全な実例付き）

PRDテンプレート（+コピーしてすぐ使える完全な実例付き）

最終更新：2026年7月28日

ほとんどのPRDテンプレートのページは、空のフォームを渡して終わりだ。Atlassianのものは説明文が4セクション続いた後、空の成功指標テーブルが待っている。Product Schoolのものはタイトルに「（実例付き）」と書いてあるのに、実例が存在しない。以下の12セクションのMarkdownブロックは、それ自体がテンプレートの全体であり、無料でコピー&ペーストできる。セクション4では、その12セクションすべてを実際の構築例で埋めていく。物流会社のクライアント向け請求書ポータルで、LLMがPDFを読み取り、判断に迷うものは人間のレビューへ回す、という中身だ。空のものをコピーする。埋まったものを読む。自分の分を書く。

主なポイント

• PRDは「何を作るか、なぜ作るか」に答える文書であり、「どう作るか」は技術設計書の役割だ。
• 12セクションはプロジェクトの規模を問わず使える。1ページ版も同じテンプレートの行数を減らしただけのものだ。
• non-goals（やらないこと）は必ず書き出す必要がある。AIコーディングエージェントは、書かれていないことからスコープを推測できない。
• 受け入れ基準は機械的に検証できる形にする。「p95で400ms以内」であって、「速い」ではない。

どのPRDの形式を使うべきか

文書の形式は、製品の規模ではなく「誰が読むか」で選ぶ。社内エンジニアだけに向けた単一機能なら1ページ版で十分だ。外部チームに渡すビルドには、フルの12セクションPRDが必要になる。受け入れ基準がそのままサインオフの条件を兼ねるからだ。AIコーディングエージェントに渡す仕様書も同じ12セクションを使うが、フェーズごとに切り分ける。

みんなが求める1ページのPRDテンプレートは、別物の成果物ではない。Lenny Rachitskyの広く模倣されている1ページ版は、実例付きで彼のニュースレターに掲載されており、儀式的な部分を削ぎ落とした同じ骨格にすぎない。1ページ版は別の文書ではない。同じ12セクションから空の行を消しただけのものだ。

アジャイルチームもよくこの疑問を口にする。PRDはバックログが立ち上がった後も生き残るのか、という聞き方をされることが多い。答えはイエスだ、ただし1ページ版として。PRDは「なぜ」と境界線を保持し、チケットは作業を保持する。

PRDテンプレート（コピー&ペースト用Markdown）

以下が全体をMarkdownで表したものだ。無料で、メール登録も不要。Notion、Confluence、Google Docs、Linear、Wordに貼り付けるか、PRD.mdとしてGitHubにコミットしてコードと一緒にバージョン管理してもいい。このテンプレートを求める人は9通りのフォーマットで探すが、どこに貼っても崩れないのはMarkdownだけで、AIコーディングエージェントが問題なく読み取れるのもMarkdードだけだ。

# PRD: [製品または機能名]

## 1. ヘッダー
- 担当（プロダクト）:
- エンジニアリングリード:
- デザインリード:
- ステータス: Draft | In review | Approved | Shipped
- 最終更新日:
- 変更履歴: 日付 / 担当者 / 変更内容

## 2. 課題ステートメント
1段落で。誰が困っているか、頻度はどれくらいか、現状どんなコストがかかっているか。解決策の話はしない。

## 3. ゴールと成功指標
| ゴール | 指標 | ベースライン | 目標値 | 測定方法 | 期日 |
|---|---|---|---|---|---|

## 4. Non-goals（やらないこと）
肯定形で書く：「このフェーズではXを含まない」

## 5. ユーザーとペルソナ
誰が使うか、すでに何を知っているか、どのデバイスか、どれくらいの頻度で使うか。

## 6. ユーザーストーリーと受け入れ基準
[ペルソナ]として、[アクション]をしたい。それは[結果]のためだ。
- [文脈]の場合、[イベント]が起きたとき、[観測可能な結果]となる。

## 7. 機能要件
番号付き。1行に1つの要件。テスト可能であること。「かつ」を含む文は禁止。

## 8. 非機能要件
パフォーマンス / セキュリティとテナント分離 / データ所在地と保持期間 / アクセシビリティ / 可用性。

## 9. 依存関係と連携
外部システム、API、認証情報、アクセス管理の担当者、リードタイム。

## 10. マイルストーンとフェーズ分け
| フェーズ | スコープ | 完了条件 | 目標日 |
|---|---|---|---|

## 11. 未解決の質問とリスク
| 質問またはリスク | 担当者 | 期日 | 未解決の場合の影響 |
|---|---|---|---|

## 12. 付録とリンク
デザイン、リサーチ、競合メモ、過去のチケット、契約書。

12のセクションを順に並べると：ヘッダー、課題ステートメント、ゴールと成功指標、non-goals、ユーザーとペルソナ、受け入れ基準付きユーザーストーリー、機能要件、非機能要件、依存関係と連携、マイルストーンとフェーズ分け、未解決の質問とリスク、付録。

PRDに含めるべき12セクションと、それぞれの弱い書き方

PRD(製品要求仕様書、product requirements document)には、課題ステートメント、測定可能なゴール、明示的なnon-goals、ペルソナ、受け入れ基準付きのユーザーストーリー、機能要件と非機能要件、依存関係、マイルストーン、担当者付きの未解決の質問、変更履歴を含めるべきだ。それ以外はすべて付録になる。各行のテストとして使えるのが、ISO/IEC/IEEE 29148:2018が要件全般に適用している基準、つまり検証可能で、曖昧さがなく、1つの内容だけを述べていることだ。

ほとんどのPRDが失敗するポイントは、決まって同じ3か所だ。

特に丁寧に扱うべきセクションが2つある。

非機能要件は、静かにスコープが倍になる場所だ。パフォーマンス、テナント分離、データ所在地、保持期間、アクセシビリティ、可用性——これらはどれもコストを伴うエンジニアリング判断であり、ユーザーストーリーには登場しない。セキュリティの項目は曖昧な言い回しではなくここに書き、公開前セキュリティチェックリストのようなソースリストを使って、実際にチェックできる形で書くこと。AI要素を含むビルドなら、本番運用に必要な要件もここに書くべきで、スケジュールされないまま忘れられがちな後回しの「堅牢化フェーズ」に押し込んではいけない。私たちが使っているのはPoCから本番環境へのチェックリストだ。

未解決の質問には3つの列が要る。1列だけでは足りない。質問、担当者、期日だ。担当者のいない質問は、誰も決めていない決定であり、6週目に変更依頼として表面化する。言っておきたいのは、PRDは自社開発か購入かを決めた後に書く文書だということだ。課題ステートメントがまだ機能の買い物リストのように読める場合、そのビルド・バイの判断はまだ本当には終わっていない。

記入済み実例：請求書ポータルPRD

以下が完全な実例で、12セクションすべてに記入済みだ。中身は、中規模の物流会社向けクライアント請求書ポータル。顧客がPDF請求書をアップロードすると、LLMが明細を抽出し、システムが発注記録との不一致をフラグし、確信が持てないものは人間のレビューキューへ回る。スタックはNext.js、Supabase/Postgres、1つのLLM抽出ステップ。コピーして、印刷して、PDFに書き出して、好きなように使ってほしい。

# PRD: Client Invoice Portal, Phase 1

## 1. Header
- Owner (product): Ops director, client side
- Engineering lead: Delivery lead, Techsy
- Design lead: Product designer, Techsy
- Status: Approved for build
- Last updated: 2026-07-28
- Change history:
  - 2026-07-14 / product / first draft
  - 2026-07-21 / engineering / added confidence-threshold rule to 6.2
  - 2026-07-28 / product / moved ERP write-back to non-goals

## 2. Problem statement
Ops staff receive customer invoices as emailed PDFs and re-key them into the
order system by hand. Volume runs past 300 invoices a week, average handling
time is about 6 minutes each, and roughly 4% carry a keying error caught only
at month-end reconciliation. Every correction costs a second pass and a call.

## 3. Goals & success metrics
| Goal | Metric | Baseline | Target | Measured by | Date |
|---|---|---|---|---|---|
| Cut manual handling | Avg. handling time | 6 min | under 90 sec | Ops dashboard, weekly median | 2026-11-01 |
| Cut keying errors | Invoices corrected at reconciliation | 4% | under 1% | Finance month-end report | 2026-12-01 |
| Contain review load | Share routed to human review | n/a | under 25% | Portal queue metrics | 2026-11-01 |

## 4. Non-goals
This phase does not support multi-currency invoices, ERP write-back, customer
self-service credit notes, or a mobile app. Extraction covers PDF only.
Photographs of paper invoices and scans below 200 DPI are rejected at upload
with a message explaining why.

## 5. Users & personas
- Ops clerk (primary, 6 people): works the exception queue all day, deep
  domain knowledge, desktop only.
- Customer AP contact (external, ~140 accounts): uploads invoices, low
  tolerance for account-setup friction.
- Finance manager (secondary): pulls the month-end report, needs a per-invoice
  audit trail.

## 6. User stories & acceptance criteria
6.1 As a customer AP contact, I want to upload an invoice PDF, so that I don't
have to email it and wait.
- Given a PDF under 20 MB at 200 DPI or better, when I upload it, then the
  portal returns a reference number within 5 seconds and shows "Processing".

6.2 As an ops clerk, I want low-confidence extractions held back, so that
nothing wrong is auto-approved.
- Given a parsed invoice, when extraction confidence for any line item is
  below 0.85, then the invoice routes to the review queue and is never
  auto-approved.

6.3 As an ops clerk, I want to see the mismatch in one place, so that I can
resolve it without opening the order system.
- Given an invoice matched to an order, when any line quantity or unit price
  differs from the order record, then the portal shows both values side by
  side and flags the delta.

6.4 As a finance manager, I want to filter invoices, so that I can close the
month.
- Given the invoice list, when I filter by vendor, date range and status, then
  results return in under 400ms at p95 and the empty state offers "Clear
  filters".

## 7. Functional requirements
1. Upload accepts PDF only, 20 MB maximum, one file per submission.
2. Extraction returns vendor, invoice number, date, currency, and line items
   with quantity, unit price and total.
3. Each line item carries a confidence score between 0 and 1.
4. Matching compares the extracted invoice to the open order by PO number.
5. Exceptions enter a queue ordered oldest first, assignable to one clerk.
6. Every state change writes an audit entry with actor, timestamp, prior value.
7. Approved invoices export as a CSV batch for the finance system.

## 8. Non-functional requirements
- Performance: invoice list p95 under 400ms. Extraction completes within 90
  seconds of upload at p95.
- Security & tenancy: per-tenant isolation enforced at the database row level.
  A customer can never read another customer's invoice. Verified by an
  automated test on every release.
- Data residency & retention: documents stored in the EU. Originals retained 7
  years, extraction payloads 90 days.
- Accessibility: queue fully keyboard-operable, WCAG 2.2 AA contrast.
- Availability: 99.5% monthly, support during business hours.

## 9. Dependencies & integrations
- Order records: read-only Postgres replica. Access owned by client IT,
  credentials needed by 2026-08-15.
- LLM extraction provider: contract and data-processing agreement signed
  before build starts.
- Email notifications: existing transactional provider, sender domain verified
  by the client.

## 10. Milestones & phasing
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| P1 | Upload, extraction, confidence routing | 50 real invoices end to end, under 25% queued | 2026-09-19 |
| P2 | Order matching and mismatch view | Mismatch flagged correctly on 20 seeded cases | 2026-10-10 |
| P3 | Audit trail, CSV export, reporting | Finance closes one month in the portal | 2026-11-01 |

## 11. Open questions & risks
| Question or risk | Owner | Needed by | Impact if unanswered |
|---|---|---|---|
| Which PO number is authoritative when an invoice shows two? | Client ops director | 2026-08-08 | Matching logic blocked |
| Do the 12 largest customers send scanned or native PDFs? | Delivery lead | 2026-08-08 | Confidence threshold may be wrong |
| Is 7-year retention confirmed with client counsel? | Client finance manager | 2026-08-22 | Storage design and cost change |
| Extraction cost per invoice at 300/week | Delivery lead | 2026-09-05 | Unit economics unknown |

## 12. Appendix & links
Anonymized sample invoice set (40 files), order-table schema, current
handling-time study, Figma flows for upload and queue, signed statement of work.

この中に、あえて取り上げる価値のある選択が4つある。それぞれ、手を抜くと実際の損失につながるからだ。

セクション3、ベースライン。「6分」は飾りではない。ベースラインがなければ、うまくいったかどうかを判定できない。半年後、データのないまま誰かが会議で議論を始めることになる。「効率を改善する」という手抜きの書き方は、プロジェクトを検証不能にしてしまう。

**セクション4、non-goal。**ERPへの書き戻しは、レビュー会議で「当然含まれる」ことにされかけたが、2026-07-28にnon-goalsへ移された。non-goalとして書き出すのに要ったのは1行だけで、それがスコープをめぐる争いを未然に防いだ。

**セクション6.2、確信度のしきい値。**これは私たち自身の初稿でも最も見落としやすいルールだ。これを書き忘れると、システムは本来人間がチェックすべき請求書を自動承認してしまい、セクション3で約束した時間短縮そのものが帳消しになる。

**セクション11、担当者。**未解決の質問には、すべて名前と期日が入っている。この列があるかないかが、文書と誰も面倒を見ないタスクリストの違いを分ける。

PRDは「何を作るか」を教えてくれる。「どれくらいの期間や費用がかかるか」は別の作業で、そちらはWebアプリのスコープ定義を参照してほしい。そして、書き出さなかったnon-goalは、いずれ誰かが作ってしまう機能になる。

AIコーディングエージェントが実際に開発できるPRDの書き方

AIコーディングエージェント向けのPRDは、簡潔さより明示性を優先する。エージェントには雑談から拾う文脈も、共有された経緯も、「言わなくてもわかるだろう」という勘も存在しない。違いの大半は4つのルールでカバーでき、これらは私たち自身のエージェント支援ビルドの成功と失敗を観察して得たものだ。

**1. Non-goalsは肯定形で書く。**人間は書かれていないことからスコープを推測できるが、エージェントはできない。「このフェーズでは認証機能を追加しない」は文書の中に文として存在しなければならない。そうしなければ、認証機能は勝手に実装され、テストされ、あなたのもとに戻ってくる。

**2. 作業をフェーズ単位に分割する。**40ページの巨大な塊を渡すと、自信満々で、範囲がやたら広く、半分正しいだけのプルリクエストが返ってくる。PRDは、エージェントが1回のセッションで完結できる単位に切り分け、それぞれに独自の完了条件を持たせる。

3. 受け入れ基準を機械的に検証可能にする。「速い」は要件ではなく、印象にすぎない。「請求書リストのエンドポイントでp95が400ms以内」は、エージェントが機能を書く前にテストとして書けるものだ。

**4. ファイルパスとスタックの制約は文書に書く。**チャットには書かない。チャットの文脈はセッションが変われば消えるが、仕様書は消えない。だからこそClaude Codeのプランモードが重要になる。プランモードはファイルを読み込み、何も編集せずに計画を提示し、承認を待つ。この承認ステップは、あなたの記憶ではなく書かれた仕様書と照らし合わせて計画をチェックできるときに、はるかに役立つ。

以下は、請求書ポータルをエージェントが1回で実行できる1つのフェーズに切り分けたものだ。

# Build task: Invoice upload and extraction (Phase 1 of 3)

## Stack constraints (do not substitute)
Next.js 15 App Router, TypeScript, Supabase Postgres with row-level security,
Vercel deploy. No new dependencies without asking first.

## Files you may create or edit
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Do not touch
- lib/auth/*  (auth ships in Phase 2; do not add sign-in flows now)
- Anything under app/(marketing)/
- The existing orders schema. Read it. Never migrate it.

## Acceptance criteria (write these as tests first)
1. POST /api/invoices rejects non-PDF with 415 and files over 20 MB with 413.
2. A line item with confidence < 0.85 sets invoice.status = 'review',
   never 'approved'.
3. Every insert writes an audit row with actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returns under 400ms on a
   10,000-row seed.

## Out of scope for this pass
Order matching, mismatch UI, CSV export, email notifications.

人間向けのバージョンから変わった点は3つある。ファイルパスが登場した。触ってはいけないリストが登場した。受け入れ基準が文章ではなくアサーションになった。どのエージェントに渡すかは思われているほど重要ではないが、コーディングエージェントの比較記事には一読の価値がある。要件とプロジェクトルールは別ファイルに分けておくこと。Cursor RulesとCLAUDE.mdには規約とツールの設定を、PRDには何を作るかを書く。スコープそのものをAIに手伝ってもらいたい場合は、それは別のワークフローだ。そして抽出ステップ自体については、モデル選定と評価ループが独立したAI統合の仕事になる。

PRDが外部チームに渡るとき、何が変わるか

PRDが代理店や外部委託先に渡ると、それは合意形成のための文書ではなく、契約文言そのものになる。社内チームなら2分の会話で解消できる曖昧さが、値札の付いた変更依頼になる。PMIの Pulse of the Profession によると、不成功に終わったプロジェクトの47%は、不正確な要件管理が原因だ。この文書が存在する理由はまさにそこにある。

その状況では、3つのセクションが特に重みを持つ。受け入れ基準はサインオフの条件になるため、エンジニアでない人にも観測可能な形で書く必要がある。未解決の質問にはクライアント側の担当者名が必要だ。ベンダーはそれに答えられず、空白のまま作業を進めてしまうからだ。そして変更履歴は形式的なものではなくなる。それは「いつ何が合意されたか」の記録であり、揉め事が起きたときに誰もが最初に確認するものになる。

私たちが何度も見てきた、うまくいかないパターンのひとつが「ユーザーは自分のデータをエクスポートできる」という一文だ。どのフォーマットかを誰も書いていない。実際に高くついたケースでは、私たちの側でCSVエクスポートとして納品したが、クライアントが求めていたのは自社ブランドの入った整形済みPDF請求書パックだった。作り直しには誰もスコープに入れていなかった約1週間分のエンジニアリング工数がかかった。正直に言えば、原因は納品側ではなく文書の側にあった。受け入れ基準が書かれていれば5分で気づけたはずだ。「エクスポートのリクエストがあった場合、ファイルが生成されるとき、それは指定されたレイアウトに一致するPDFである」と。non-goalsの一行でも、逆の方向から同じことを防げただろう。だから今では、「エクスポート」「レポート」「通知」のような名詞に依存する要件には、契約書に署名する前に必ずフォーマット、トリガー、実例を1つずつ添えるルールにしている。

私たちがWebアプリケーション開発をどう進めているかの大部分は、まさにこれだ。クライアントの仕様の曖昧な部分を、コードを書く前にテスト可能な行に変換すること。

r/ProductManagementはPRDテンプレートについて実際どう言っているか

product requirements document template redditで検索すると、r/ProductManagementで繰り返される同じ愚痴が見つかる。テンプレートの肥大化。誰も読まないPRD。見出しがあったから埋めただけで、必要だから書いたわけではないセクション。キックオフの翌日には古びて、いつの間にかSlackのスレッドに置き換わっている文書。これはほとんどのテンプレートに対する妥当な批判であり、この検索クエリの上位10件のうち何件かにも同じことが言える。

私たちの答えはこうだ。空欄で埋めるくらいならセクションごと削除する。ユーザーが自明な場合はペルソナを先に削る。付録は次に削る。マイルストーンはトラッカーに置いてもいい。唯一削らないのがnon-goalsだ。作業を進めるほど短くなっていく唯一のセクションであり、6週目に起きがちな揉め事を確実に防いでくれる唯一のセクションだからだ。

執筆者について

Mert Batur Gurbuz、Techsy.io共同創業者。経歴：Techsy.io共同創業者、University of Birmingham。LinkedIn

Mert Batur GurbuzはTechsy.ioの共同創業者で、同社はB2Bクライアント向けにAIエージェント、自動化システム、音声・SDRパイプラインを構築している。University of Birminghamに在学中で、Techsyチームが実際の本番環境で使っているLLMツールスタックについて執筆している。

よくある質問

PRD（製品要求仕様書）とは何ですか？

PRD（Product Requirements Document、製品要求仕様書）とは、チームが何を作るのか、なぜ作るのかを述べる文書だ。課題、ゴールとその指標、non-goals、対象ユーザー、完了の定義となる要件が含まれる。実装の詳細は意図的に除外されており、それはエンジニアリングが後から書く技術設計書の役割になる。

PRDはどうやって書けばいいですか？

まず課題ステートメントから始め、そこでは解決策の言葉を使わないようにする。ベースラインと目標日を含む測定可能なゴールを加え、次にnon-goalsを書く。ペルソナ、Given/When/Then形式の受け入れ基準付きユーザーストーリー、機能要件と非機能要件、依存関係、マイルストーン、担当者付きの未解決の質問を埋めていく。

PRDには何を含めるべきですか？

12セクションだ。変更履歴付きのヘッダー、課題ステートメント、ゴールと成功指標、non-goals、ユーザーとペルソナ、受け入れ基準付きのユーザーストーリー、機能要件、非機能要件、依存関係と連携、マイルストーンとフェーズ分け、未解決の質問とリスク、付録。これらのどれにも当てはまらないものは、おそらく要件ではない。

PRDはどれくらいの長さにすべきですか？

単一機能なら1〜2ページ、製品フェーズ全体なら3〜5ページ、外部チームが構築し受け入れ基準がサインオフの条件を兼ねる場合は5〜8ページ。長さは製品の規模ではなく、記録すべき意思決定の数に比例する。空のセクションは水増しせず削除すべきだ。

PRDとBRDは同じものですか？

いいえ、違う。BRD（Business Requirements Document、業務要求仕様書）は、組織が求める商業的な成果とその制約を、多くの場合まだ解決策が決まる前に述べる文書だ。PRDは、その成果を実現する製品について述べる。ユーザー、振る舞い、受け入れ基準、non-goalsだ。小規模な企業では、BRDが実質的に課題ステートメントのセクションだけになっていることも多い。

アジャイルチームでもPRDは書きますか？

はい、多くの場合1ページ版として書く。作業自体はバックログが保持するが、チケットは「なぜ」やnon-goals、成功指標を保持するのが極端に苦手だ。PRDを完全に省略したチームは、プロジェクト開始から3スプリントほど経った頃に、「context」という名前のConfluenceページとして結局それを再発明することが多い。

PRDをMarkdownで書くことはできますか？

Markdownは最適なフォーマットだ。Notion、Confluence、Google Docs、Linearにきれいに貼り付けられ、PRD.mdとしてコードのそばでGitバージョン管理でき、プルリクエストで正しく差分表示され、構造を崩さずに読めるAIコーディングエージェント向けフォーマットとしても唯一のものだ。上記のテンプレートがMarkdownなのは、まさにこれらの理由による。

AIコーディングエージェント向けのPRDはどう書けばいいですか？

普段なら簡潔に済ませるところを、明示的に書く。Non-goalsは肯定形で書く。エージェントは書かれていないことからスコープを推測できないからだ。文書は1回のセッションで終わるフェーズに分割する。受け入れ基準は数値を伴うアサーションとして書く。エージェントが編集してよいファイルと、触れてはいけないファイルの両方を名指しする。

PRDと技術設計書の違いは何ですか？

PRDは「何を、なぜ」に答える。課題、ユーザー、振る舞い、受け入れ基準、non-goalsだ。技術設計書は「どうやって」に答える。アーキテクチャ、データモデル、APIの契約、検討したトレードオフだ。通常プロダクトが前者を、エンジニアリングが後者を担当し、技術設計書はPRDへの応答として読めるべきものだ。

PRDの所有者はプロダクト、エンジニアリング、それともクライアントですか？

文書とその中の意思決定を所有するのはプロダクトだ。エンジニアリングは実現可能性のフィードバックと非機能要件を所有する。代理店案件では、クライアントが課題ステートメント、ゴール、そして自社のビジネスに関するあらゆる未解決の質問を所有する。文書全体を共同所有にすると、たいてい誰もメンテナンスしなくなる。

まとめ

持ち帰ってほしいことは3つだ。テンプレートは記入されて初めて役に立つので、空のものではなく記入済みの実例の構造をコピーしてほしい。Non-goalsは文書の中で1語あたりの価値が最も高いセクションであり、真っ先に省略されるセクションでもある。そしてテスト可能なアサーションとして書かれた受け入れ基準は、納品にサインオフするエンジニアと、テストを書くエージェントの両方に等しく役立つ。

外部チームに渡すPRDを書いていて、契約書になる前にもう一組の目で曖昧な部分を確認してほしいなら、私たちが読んで曖昧な行にマークを入れる。それは私たち自身のWebアプリケーション開発で行っているのと同じ工程だ。