PRの背景・目的、変更内容、動作確認のセクションを体系的に作成し、PRを作成・更新します。必要に応じて主要な変更箇所に補足コメントを追加します。

手順

•
情報整理
- •
  これまでに以下が未整理の場合、まずそれらを整理してください
  - •変更内容の技術的な目的：「このPRは何をするものか？」を明確にします
  - •根本目的：「なぜその技術的変更が必要なのか？（どのようなビジネス上や運用上の課題があったのか）」を明確にします
•
目的の整理
- •
  以下のステップ・指針・記法をもって、PRの目的を段階的に整理し、文章を考えてください
  - •ステップ
    
    •根本目的: ビジネス上の課題解決や障害防止など（なぜこの取り組みが必要か）
    
    •中間目的: 技術的な仕組みの改善や導入（どのような手段で解決するか）
    
    •直接的作業: 今回のPRで実際に行う変更内容（具体的に何をするか）
  - •指針
    
    •時系列で背景を説明（いつ何が起きたか）
    
    •原因と根本原因を明確に分ける
    
    •なぜ今回の対応が必要かの論理的つながりを示す
    
    •現状の問題と今回の解決アプローチを説明
    
    •「◯◯な必要があり、本PRで対応しました」のように、PRの目的を明確に述べる
  - •記法
    
    •基本的に見出しの使用は避け、文章で書く（バッククォートによる囲みは使用可）
    
    •ですます調で、全体として3〜7文程度のまとまりで記述する
    
    •文ごとに改行を入れ、段落の区切りには空行を入れる
    
    •チケットやPR、出来事に対する言及はリンクとして記載する

文章例：

code

(チケットへのリンク) で実装したXX表示機能では、開始日時と終了日時をstring型として扱っていました。
しかし、日時データをstring型で扱うと、管理画面での入力時に誤った形式で入力されるリスクがあり、また型安全性の観点からも改善の余地がありました。

本PRでこの改善に対応しました。
date型をサポートすることで、管理画面でdatetime-localフィールドを使った直感的な日時入力が可能になり、型レベルでの安全性も向上します。

また、内部実装についても、文字列ベースから型付き値ベースへのリファクタリングを行い、バリデーションを型チェックに統一することで、より堅牢な実装としました。

•
変更内容整理
- •
  PRの技術的変更内容のうち、主要なポイントを整理してください
  - •細かすぎる変更点は省略すること
  - •特定の手順に則って変更を加えた場合は、行った手順とその説明も記載すること

良い例（適度な粒度）：

code

## 変更内容
- date型のサポートを追加
- 管理画面UIの改善
- ...

悪い例（詳細を書きすぎ）：

code

## 変更内容
### 1. date型のサポート追加
- schemaに`date`型を追加
- `str_to_value`/`value_to_str`でdate型の変換処理を実装
  - 文字列からTimeオブジェクトへの変換
  - TimeオブジェクトからISO8601形式文字列への変換
- date型のバリデーション追加（Time/ActiveSupport::TimeWithZoneの型チェック）
- ...

### 2. 管理画面UIの改善
- 表示を日本語化（文字列、真偽値、整数、日付）し、英語名も併記
- ...
### 3. ...

•動作確認の整理
•前段までに動作確認方法を検討済みの場合、それに従います
•
動作確認方法を未検討の場合、動作確認方法を検討してください
- •開発環境とQA環境での動作確認内容を検討してください
•
例のようなフォーマットで ## 動作確認 セクションに記載する文章を考えてください
- •チェックボックスについて、未実施の場合はチェックを空にしてください。実施済みの場合はチェックを入れてください
- •この作業において未実施の動作確認を実施する必要はありません
- •実際の動作確認（ブラウザでの確認など）が未実施の場合は、動作確認セクション自体を空欄にしてください

例：

code

## 動作確認

開発環境で以下を確認します

- [x] 管理画面での日時の入力が正しく動作することを確認
- [x] 入力した日時がxxの画面に正しく反映されることを確認

QA環境で以下を確認します

- [ ] 管理画面での日時の入力が正しく動作することを確認
- [ ] 入力した日時がxxの画面に正しく反映されることを確認

•
補足コメント検討
- •「補足情報の提示有無の判断基準」に基づいて、PRの変更内容について、補足情報が必要な箇所を洗い出してください
- •各箇所について、「補足情報の書き方」に基づいて、文章として整理してください
- •行数を指定した補足コメントは、インラインコメントとして投稿してください（詳細は「補足情報の投稿方法」参照）
•
反映内容の確認
- •上記までにで整理した内容を、ユーザーに提示し、文章や内容のレビューを依頼してください
- •OKが出たら次の「反映」ステップに進みます
•
PRテンプレート確認
- •PR未作成の場合、.github/PULL_REQUEST_TEMPLATE.md を確認し、テンプレートの構造を把握してください
- •テンプレート内の各セクション（「なぜ必要なのか？」「動作確認」など）を特定し、整理した内容をそのセクションに埋める形で作成します
•
反映
- •
  OKが出たら、以下の手順でPRを作成または更新してください
  - •反映・更新手順
    
    •PR未作成の場合
    
    •gh pr create --draft で必ずdraftとして作成する
    
    •レビュワーは追加しない
    
    •PRテンプレートの構造に従って、該当セクションのみを埋める（他のセクションには一切手を加えない）
    
    •PR作成済みの場合
    
    •gh pr edit コマンドを使用してPRの概要欄を更新する
    
    •既にセクションがあればそれを使い、無ければ新規に設け、整理した内容で追加または更新する
    
    •整理した補足情報を、インラインコメントとして追加してください（詳細は「補足情報の投稿方法」参照）

補足情報の提示有無の判断基準

以下のような箇所には補足情報を追加する：

•
コードの呼び出し元・利用箇所が自明でない箇所
- •どこから使われているのか
- •どのような経路で呼ばれるのか
•
実装方式の選択理由が不明瞭な箇所
- •なぜ他の実装方式ではなくこの実装方式を選んだか（why not）
- •どのような選択肢を検討したか
- •それぞれの選択肢の利点・欠点
•
変更範囲の妥当性が疑問に思われそうな箇所
- •なぜこの箇所の変更のみで必要十分か
- •なぜ他の関連箇所を変更しなくても問題ないのか
- •過不足がないと言える理由

逆に、以下のような箇所には補足情報を追加しない：

•コードを読めば自明な変更
•単純なリファクタリング
•明らかなバグ修正
•PR説明文で十分に説明されている内容

補足情報の書き方

各補足箇所について、以下を簡潔に記載：

•
呼び出し元・利用箇所の補足
- •「このメソッドは XX から呼ばれます」
- •「処理フロー: A → B → このメソッド → C」
•
実装方式の選択理由
- •「当初 XX を検討しましたが、YY の理由で ZZ を選択しました」
- •「XX ではなく YY とした理由: ZZ」
•
変更範囲の妥当性
- •「XX は変更不要です。理由: YY」
- •「この変更のみで十分な理由: XX」

補足情報の投稿方法

行数を指定した補足コメントは、インラインコメント（レビューコメント）として投稿します：

•

PRの最新コミットIDを取得：

bash

gh api /repos/{owner}/{repo}/pulls/{pr_number} --jq '.head.sha'

•

インラインコメントを投稿：

bash

gh api \
  --method POST \
  -H "Accept: application/vnd.github+json" \
  /repos/{owner}/{repo}/pulls/{pr_number}/comments \
  -f body='コメント内容' \
  -f commit_id='取得したコミットID' \
  -f path='ファイルパス' \
  -F line=行番号 \
  -f side='RIGHT'

•
複数行にわたる範囲にコメントする場合は、-F start_line=開始行番号 を追加

チェックポイント

• PR未作成の場合、gh pr create --draft で作成されているか
• PR未作成の場合、レビュワーが追加されていないか
• PR未作成の場合、デフォルトテンプレートが使用され、指定セクション以外に手を加えていないか
• PR作成済みの場合、gh pr edit コマンドで更新されているか