見やすい PRを作るために取り組んでいること

Transcript

1. 2026/07/10 Tamagawa.dev #2 見やすいPRを作るために 取り組んでいること
2. 自己紹介 Furuichi (@takfjp / takf-jp) 株式会社カンリー　所属 フロントエンドがメインでしたが今はGoを書いて(書かせて)います 最近の興味はQAとシフトレフト
3. こんな経験ありませんか？ 1 LLMが書いた文章が「わかりづらい」と言われる 2 レビューする時、どこから読めばいいかわからない 3 AIでそれっぽく作れたのに、読むと何を言ってるか不明 → 今日は、これを減らすために 自分が実際にやっていること について話します
4. 例1　「Fable5のすごい点を普段 AIを使わない人に伝えたい。イ ラストを使ってキャッチーに、わかりやすく。」 「それっぽい」けど、伝わらない 例2　「GPT-5.6のすごさをフリーランスで仕事をしている人に伝 えたい。インパクトのでかいスライドで！」
5. 何がいけないのか PRに置き換えると？ 論理が繋がっているか怪しい変更理由 変更量が多く、冗長なコードが紛れ込む PR Description が長すぎて要点がわからない ここがいまいち 単語の意味が不明瞭、文章がいまいち とにかく情報が多い 本当に言いたいことが伝わってこない
6. わかりづらさを生む 3つの要素 1 自動化バイアス AIの出力を鵜呑みにする。 「それっぽい」だけで満足してしまう。 2 認知的負荷 情報量がワーキングメモリを圧迫。 量に押されて質を評価できない。 3 非注意性盲目 無いと思っているものは探さない。 欠落や冗長を見落とす。 これらが複合して「わかりづらいPR」ができあがる
7. ・PRの意図を自分の言葉で説明できるように整理する ・コーディングをエージェントに任せても変更は自分の責任で出す Q1 この変更って、こういう意図で合ってる？ Q2 Issueを達成する“別の方法”があるとしたら？なぜこのやり方？ Q3 自分に意地悪な質問をしてみて！ ①実装エージェントに質問する 取り組んでいること
8. ②見せ方を変える 差分をアーティファクトで出力 ・Markdown / CLI出力より見やすい ・ファイル単位でまとめる／ Diff表示など 用途に合わせてカスタマイズできる ・Markdownファイルのプレビューは Zed で行ってエディタと用途 を差別化 ※左は架空のPR 取り組んでいること
9. 取り組んでいること ③複数の目を通す 複数エージェントにレビューさせる } 実装担当のほかに、3つのペルソナを用意： 担当領域のスペシャリスト 「悪魔の代弁者」（全部を間違いと前提） 実装とドキュメントの乖離を見逃さない役 6 / 8 ・相互にレビュー ・MUST / IMO / ASK / NITS でランク付 ・それぞれの指摘事項はどのエージェントによるか記録 ・ これもアーティファクト出力して指摘内容を自分で精読
10. それでも残る課題 加えた変更への記憶があやふや エージェントに任せすぎて、 自分の実装への解像度が落ちている 根本的な問題を指摘される PRを作る時点で本質的な問題を理解しておらず、 設計レベルの指摘が生まれる → ツールを入れても、これが起きる 7 / 8 「他人が読んでわかるPR」を作るため、 「自分が理解できる PR」をまず目指そう