マガジン

利用者からの不具合報告を受け取る:GitHub Issueフォームと連絡先の用意

AIを使いこなす

Claudeで執筆し、GPTで自動校閲・修正しています。

不具合報告で聞く項目をノートに書き出した様子
記事の内容をもとに制作したAI生成イメージです。実際の製品画面や検証結果の写真ではありません。

「動きません」の一言だけが届くと、直す側は何も手がかりがありません。これを防ぐには、自由記述の空欄を渡すのをやめ、「何をしたか」「何が起きたか」「どの環境か」を聞く入力欄をあらかじめ用意しておくのが近道です。GitHubなら、Issueフォーム(YAMLで書く入力フォーム)でそれができます。 この記事では、そのまま貼れるテンプレートと設定ファイル、返信の定型文、AIに下書きを頼むときの渡し方を示します。 本文のYAMLと文面は説明用の例です。私は実際のリポジトリで動作確認をしていません。貼り付けたら、下の「公開前の確認」を必ず行ってください。

この記事の目次
  1. 先に押さえる仕様(公式ドキュメントで確認した範囲)
  2. 受け口に並べる項目と、その理由
  3. コピーして使えるIssueテンプレート
  4. GitHubを使わない人の連絡先も用意する
  5. 返信の定型文
  6. AIに下書きを頼むときの渡し方
  7. 公開前の確認

先に押さえる仕様(公式ドキュメントで確認した範囲)

2026年10月28日時点で、GitHub Docsの記述から確認できた点です。

  • テンプレートは、リポジトリの .github/ISSUE_TEMPLATE フォルダに置きます。フォーム形式は フォーム名.yml、全体設定は config.yml です(テンプレート作成の公式手順)。
  • 利用者に表示されるのは、デフォルトブランチに反映された後です。
  • フォームの必須キーは name、description、body です。入力欄の種類にはmarkdown(説明文)、input(1行)、textarea(複数行)、dropdown(選択)、checkboxes、uploadがあり、入力欄は validations の required: true で必須にできます(Issueフォームの構文)。
  • 同ページは、Issueフォームがパブリックプレビューで変更される可能性があると明記しています。動かなくなったら公式ページを見直してください。

受け口に並べる項目と、その理由

何を聞くかを先に決めます。多すぎると誰も書かないので、必須は3つ程度に絞るのが無難です(これは編集上の提案です)。

  • 何をしようとして、何が起きたか、入力欄の種類:textarea、必須:はい、聞く理由:症状の把握
  • 期待していた動き、入力欄の種類:textarea、必須:いいえ、聞く理由:不具合か仕様の誤解かを分ける
  • 再現の手順、入力欄の種類:textarea、必須:はい、聞く理由:同じ状況を作るため
  • 使っている端末、入力欄の種類:dropdown、必須:はい、聞く理由:スマホ限定の崩れなどを絞る
  • ブラウザ、入力欄の種類:dropdown、必須:いいえ、聞く理由:ブラウザ固有の問題を絞る
  • 画面のURL、入力欄の種類:input、必須:いいえ、聞く理由:どのページかの特定
  • エラー表示など、入力欄の種類:textarea、必須:いいえ、聞く理由:手がかりの追加
  • 公開されることへの同意、入力欄の種類:checkboxes、必須:はい、聞く理由:個人情報の混入を防ぐ

公開リポジトリのIssueは公開されるため、誰でも読めるものとして扱います。そのため、個人情報や入力したデータをそのまま貼られないよう、冒頭の注意書きと同意欄を入れています。

コピーして使えるIssueテンプレート

.github/ISSUE_TEMPLATE/bug_report.yml として保存します。labels に指定したラベルが無いと付かないので、作成済みのラベル名に合わせてください。

yaml
name: 不具合の報告
description: 思った通りに動かないときはこちらへ
title: "[不具合] "
labels: ["bug"]
body:
  - type: markdown
    attributes:
      value: |
        このページの内容は公開されます。パスワード、メールアドレス、住所など個人情報は書かないでください。
  - type: textarea
    id: what
    attributes:
      label: 何をしようとして、何が起きましたか
      placeholder: "例: 保存ボタンを押したが、画面が変わらなかった"
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: 本当はどうなってほしかったですか
  - type: textarea
    id: steps
    attributes:
      label: 起きるまでの手順
      placeholder: |
        1. トップページを開く
        2. 〇〇を入力する
        3. 保存を押す
    validations:
      required: true
  - type: dropdown
    id: device
    attributes:
      label: 使っている端末
      options: [パソコン, スマートフォン, タブレット, わからない]
    validations:
      required: true
  - type: input
    id: browser
    attributes:
      label: ブラウザ(例 Chrome、Safari)
  - type: textarea
    id: extra
    attributes:
      label: エラー表示など(あれば)
      render: text
  - type: checkboxes
    id: agree
    attributes:
      label: 確認
      options:
        - label: 個人情報を含めていません
          required: true

GitHubを使わない人の連絡先も用意する

Issueを書くにはGitHubのアカウントが必要です。利用者がGitHubを知らない前提なら、別の窓口が要ります。config.yml の contact_links で、テンプレート選択画面に外部リンクを出せます。blank_issues_enabled: false にすると、自由記述だけのIssueを防げます(書き込み権限のある人は引き続き作成可能と公式に書かれています)。

yaml
blank_issues_enabled: false
contact_links:
  - name: GitHubを使っていない方・個人情報を含む相談
    url: https://example.com/contact
    about: 問い合わせフォームからご連絡ください

https://example.com/contact は説明用の仮URLです。Googleフォームなど自分で用意した窓口に置き換えます。メールアドレスや名前を集める窓口にする場合は、利用目的を画面上に書いておくと親切です。

返信の定型文

そのまま貼らず、状況に合わせて一言足してください。

受付

ご報告ありがとうございます。内容を確認します。数日以内に状況をお返事します。

情報が足りない

確認のため、次の点を教えてください。①押したボタンの名前 ②表示されたメッセージ(画面の文字で構いません) ③使っている端末とブラウザ。個人情報は書かないでください。

再現できた

同じ状況を確認できました。修正を進めます。直りましたらこちらでお知らせします。

再現できない

こちらの環境では再現できませんでした。ブラウザを再読み込みしてもう一度お試しいただき、結果を教えてください。

修正した

修正を公開しました。お手数ですが、もう一度お試しください。まだ直らない場合は、このままご返信ください。

対応しない

検討の結果、今回は仕様として現状のままとします。理由は〇〇です。ご意見ありがとうございました。

「数日以内」など約束する期間は、守れる範囲で書き換えてください。

AIに下書きを頼むときの渡し方

AIには、項目案と文面の下書きを任せられます。次の依頼文を使えます。

個人で作った〇〇(説明: 例 入力した文字数を数えるWebツール)の不具合報告フォームを作りたいです。
利用者は初心者で、GitHubを知らない人もいます。
次を出してください。
1. 聞くべき項目を8個以内、必須と任意に分けて
2. GitHub IssueフォームのYAML
3. 返信の定型文(受付・情報不足・修正完了)
個人情報を聞く項目は入れないでください。

渡す情報は、ツールの概要と主な画面操作、想定する利用者までです。サーバーの設定値、APIキー、実際の利用者の報告文は渡さず、必要なら架空の内容に置き換えます。

人が確認するのは次の点です。

  • 聞いてはいけない情報(メールアドレスなど)を求める欄がないか
  • 必須項目が多すぎないか
  • YAMLのキー名が上記公式の構文と合っているか
  • 返信の約束(期間、対応範囲)が自分に守れるか

公開前の確認

  1. 設定の「Set up templates」からも作れますが、ファイルで置く場合はデフォルトブランチへ反映します。
  2. 自分のアカウントで「New issue」を開き、フォームが表示されるか確認します。
  3. 別のアカウントやログアウト状態の画面で、外部リンクが見えるか確認します。
  4. 自分で試しに報告を1件書き、必要な情報が揃うか見てから、不要なIssueを閉じます。

この確認を済ませるまでは、動作確認済みとは言えません。まずは項目を絞った版で公開し、実際に届いた報告を見て欄を足し引きしてください。

出典・参考資料