散らかったコーディングAIの会話をバグ報告に直す例

コーディングAIとの会話は、試したことが多いほど読みにくくなります。

コーディングAIとの会話には、ログ、推測、修正案、別件の質問が入り混じります。開発チームに渡すなら、AIとの相談履歴ではなく、再現できるバグ報告へ変換します。

先に結論

再現手順、期待する挙動、実際の挙動、環境、すでに試したこと、まだ試していないことに分けます。

図をダウンロード

変換前

- AIにログを貼りながら、キャッシュ削除、依存関係更新、frontmatter確認を順番に試している
- 500エラー、parse error、特定スラッグだけ落ちる事象が同じ会話で混ざっている
- どのコマンドで再現したか、どの修正案を試したか、まだ試していない仮説が分かれていない
- GitHub issueに貼るには、ログに含まれるローカルパスや環境変数名を確認する必要がある

変換後

# バグ報告

## 期待する挙動
ローカルで記事プレビューを開くと、対象の日本語ドラフトが表示される。

## 実際の挙動
特定の日本語ドラフトだけ500エラーになる。サーバーログにはfrontmatter parse errorが出る。

## 再現手順
1. 開発サーバーを起動する。
2. 対象スラッグのプレビューを開く。
3. サーバーログを確認する。

## 環境
- macOS
- Node.js: チームの標準バージョン
- 対象: 日本語Markdownドラフト

## すでに試したこと
| 試したこと | 結果 |
| --- | --- |
| 依存関係の再インストール | 変化なし |
| 該当Markdownの区切り確認 | YAMLの折り返しが候補 |

## 次に試すこと
- frontmatterを最小化して再現する。
- 同じ形式の他ロケールでも起きるか確認する。

変換の判断表

共有前チェック

• 再現手順が番号付きで書かれている。
• 期待する挙動と実際の挙動を分けた。
• AIの推測を原因として断定していない。
• ログにトークン、パスワード、顧客情報が残っていない。
• 次に誰が何を試すかが分かる。

実務での補足

コーディングAIとの会話では、失敗した試行も価値があります。ただし、会話順で貼るのではなく、「すでに試したこと」として表にまとめます。次の開発者が同じキャッシュ削除や依存再インストールを繰り返さずに済みます。

ログやコード片を入れるときは、再現に必要な最小限にします。非公開リポジトリのURL、顧客データ、環境変数の値は外し、必要なら役割名やダミー値に置き換えます。

日本語の業務共有での使い方

散らかったコーディングAIの会話は、そのままSlackに貼るより、GitHub issueやJiraで読めるバグ報告に変えます。再現手順、環境、試したこと、次に見る箇所を本文に置き、SlackやTeamsにはレビュー依頼とissueリンクだけを出します。

Highlight Reelを使う場面

長いコーディングAIセッションから、GitHub issueに必要なログ、手順、試したことだけを切り出せます。会話全文を貼るより、レビュー担当者が再現と調査に入りやすくなります。

よくある質問

元の会話リンクも添えますか？

必要なら添えます。ただし、整理済みの本文だけで状況が分かるようにします。

失敗した案や途中の質問は残しますか？

重要な判断に関係するものだけ残します。単なる言い直しや重複は削ります。

AIの文章をそのまま使ってよいですか？

下書きとしては使えます。共有前には、事実、機密情報、読み手に必要な粒度を人間が確認します。