Github Copilot講座 - コードリーディング編 -

GitHub CopilotのTips集です。
主にコードリーディング用途での活用に焦点を当てています。

Transcript

1. Github Copilot 講座 コードリーディング編 2025/03/21 Mamoru Okamoto / @mamo-dev
2. 本日のお話 • 実例紹介 • プロンプトチューニングの考え方 • おぼえてトクする操作集 • コードリーディングにおける Github Copilotとの付き合い方
3. 実例紹介
4. 基本編
5. Tips1 - “このファイルを解説して”
6. ソースコードがノイズ
7. Tips2 - “ソースコードの解説は不要”
8. メソッドとの対応ぐらい 把握したい
9. Tips3 - “機能とメソッド名の対応をまとめて”
10. ファイル内部に 閉じたメソッドか どうかを調べたい
11. Tips4 - “外部参照しているメソッドを抽出して”
12. 見にいくにしても 1つ1つ検索するの大変
13. Tips5 - “自作ではない外部参照しているライブラリのURL一覧を表にして”
14. そもそも 見にいきたくない
15. Tips6 - “XXXでできることを教えて” ファイル 参照を offにして ソースコード 再登場を警戒
16. もうちょっと 使い方を見たい
17. Tips7 - “XXXの代表的な使い方をいくつか教えて。ソースコードあり” 引き続き ファイル参照 off 10個説明してくれる
18. 自分の得意な 言語で似ている ライブラリでいうと？
19. Tips8 - “XXXのライブラリでいうと何が似ている？”
20. コードのロジックを読み解く編
21. 詳細のロジックを読解を ラクしたい
22. 自動的に行選択箇所が 参照される エディターで 選択すると・・・
23. Tips9 - “詳細のロジックを説明して、ソースコードなし” やや見やすくなる もうちょっと 直感的にしてほしい
24. Tips10 - “詳細のロジックを図解して”
25. Process Input Output I/Oのイメージがほしい
26. Tips11 - “インプットとアウトプットのパターンを表でまとめてほしい”
27. Process Input Output Testのイメージも沸くと 理解しやすい Test
28. Tips12 - “テストして検証するパターンを表でまとめてほしい”
29. 見るに耐えない ロジックの ソースコード 通常のフロー図で 表現できるか不安
30. Tips13 - “Mermaidでロジックを図解して” Mermaid Live Editor
31. 見るに耐えない ロジックの ソースコード 外部参照先を 全部見に行かないと 不安で仕方がない
32. Tips14 - “メソッド一覧を表に。解説は不要だが、ファイルパスは用意。” アイコン付きは コードジャンプできる
33. 見るに耐えない ロジックの ソースコード 分岐にだけ 着目して分析したい
34. Tips15 - “分岐パターンのルートを網羅して整理してほしい”
35. https://text-to-diagram.com/?a=d2 PlantUMLでリッチな 図解をしたい
36. Tips16 - “分岐をPlantUMLで表現してほしい” PlantUML Editor
37. ER図を用意したい
38. Tips17 - “ER図で表現してほしい” スキーマファイルを 前提として
39. ファイル群を扱う
40. スキーマファイル以外から 導出したい 先ほどの話
41. Tips18 - “#folder:models ER図で表現してほしい” modelsのファイル群を 前提として
42. XXXなフォルダを解説してほしい
43. Tips19 - “#folder:services が何やっているかをまとめてほしい” 参照が ディレクトリになる
44. XXXなフォルダを表で まとめてほしい
45. Tips20 - “#folder:services が何やっているかを表でまとめてほしい” 表はわかりやすい
46. ディレクトリ構成を 理解したい
47. Tips21 - “ディレクトリ構成を図解してほしい” 樹形図で 図解してくれる
48. ディレクトリ構成を もう少し深く理解したい
49. Tips22 - “ ディレクトリ構成を知りたい, 3階層まで, 網羅性が大事なのでファイル名を省 略してほしくない” トークン数を節約しようとする 省略してほしくないをつけないと 省略されてしまう
50. ディレクトリの関係を 知りたい
51. Tips23 - “@workspace ディレクトリの関係図をDiagramで図解してほしい”
52. XXXな機能を探して欲しい
53. Tips24 - “@workspace 認証機能の実装箇所を教えてほしい。ファイルパスは必要, ソースコードは不要。” @workspaceの 参照を自動で決める コードジャンプできる
54. なにも考えられない・・・
55. Tips25 - “@workspace 全体を簡単に理解するために、要領よく10回に分けてプロンプ トを投げ込みたい。 おすすめの10回分のプロンプトを箇条書きで用意してほしい” プロンプトの 候補一覧を入手
56. プロンプトチューニングの考え方
57. 以下の3つを組み合わせて、プロンプトをチューニングする 読み込み範囲 依頼 表現 変数 @workspace #folders #file複数 #file単数 表示ファイル Narrate (逐次解説) Describe (要点解説) Search (探索) Extract (抽出) Suggest (提案) 見出し ソースコード有無 箇条書き 表組み 図解 目的意識を はっきりさせる 出力が適切になる 範囲が広くなると tokenにおさまらない 何がtokenとして渡るかの イメージが重要 読みやすさ = 便利さ,やる気が出る なので疎かにしない
58. 知っておくとよいこと - 隣接タブは読み込まれる 隣接タブ: 開いているタブを参照し 必要そうなものを参照する 時には タブを閉じることも重要 A/Bテストの結果 5%ぐらい受容率が UP How GitHub Copilot is getting better at understanding your code - The GitHub Blog
59. 知っておくとよいこと - Prompt Library層がローカルに存在 How GitHub Copilot is getting better at understanding your code - The GitHub Blog (推測) セッションごとに Prompt Libraryが 用意されている？
60. 知っておくとよいこと - V-modelのコンセプト V-Model - an overview | ScienceDirect Topics システム開発の レイヤーに対応したテスト を整理した考え方 要求したいレイヤーによって 投げ込む内容が変わる点は プロンプトも同等といえそう
61. (参考) レイヤーに応じた探索範囲 レイヤー 概要 依頼事項 探索範囲 要求仕様 要求仕様からどういった開発が必要になるか？ - 開発仕様に落とす際に考慮すべき重要な要素 - パッケージやライブラリは利用有無 - ベストプラクティス・アンチパターン 1: 一般的なプラクティス Githubソースコード全域 開発仕様の詳細化 既存の実装箇所は？新規に実装は必要？ - 関連しそうな既存実装の有無 - 既存実装の修正・延長、新規実装の判断 - 適切なディレクトリ・ファイルの把握 2: 実装内容の関連ディレクトリと ファイルの探索 3: 特定のディレクトリの構造 4: 特定のファイル群の関係性 ディレクトリ 複数ファイル コードの実装 具体的な実装箇所はどうなっている？ - クラス・メソッドの設計 - ロジックの具現化 5:クラスの継承関係とメソッド 6:複雑なロジックの説明 複数ファイル 単一ファイル
62. おぼえてトクする操作集
63. 3つのシンボル “@, /, #” を覚える
64. 3つのシンボルを覚える - “@” @ - 前提とする探索範囲を変更することができる
65. Tips1 - @githubで目的のレポジトリを探す
66. Tips2 - @githubで実装事例 x スター数が多いOSSを探す
67. Tips3 - @workspace内を探索してまとめる 探索範囲が Workspace ※VS CodeのWorkspaceで管理する 　習慣が必要になる
68. Tips4 - @vscodeの設定へジャンプ
69. 3つのシンボルを覚える - “#” # folderはディレクトリ単位 fileはファイル単位 symはメソッド単位 - 参照範囲を変更できるため、利用頻度が高い changesは git changes変更履歴
70. 3つのシンボルを覚える - “/” / /helpで なんとかなる - 具体的なアクションを指定できるが、自然言語でも指定できるのでなくてもなんとかなる
71. チャットウインドウの操作
72. Tips1 - 別ウインドウでチャットを開くことができる
73. Tips2 - エディター内でチャットを開かなくてもよくなる コマンドでファイル 指定する習慣があれば エディター内部でチャットを開かなくて良い
74. Tips3 - ウインドウは複数用意できる 調査したいスコープにあわせて 複数ウインドを常時立ち上げることができる
75. Tips4 - 入力内容をリセットして、スレッドを切り替える スレッドを 新規作成
76. Tips5 - なお、過去のスレッドは消えていない 履歴はここから 再表示できる
77. Tips6 - ファイル添付とボイス入力もできる Cmd + / => Attach | Cmd + i => Voice Input Cmd + / Cmd + i
78. Tips7 - 画像のER図からモデルを用意できる モデルは 限定される
79. Tips8 - 画像のスクリーンショットからhtmlを用意できる
80. Tips9 - URLも参照として利用できる inputとなるhtmlが 大きく、 省略されることが多い (雰囲気見れるだけ )
81. Github Copilotの設定
82. Tips1 - 日本語設定 - 日本語で常に対応してほしい => Locale Overrideをjaに
83. Tips2 - Markdownでの適用 - README.mdを良い感じで編集したい => markdownをtrueに
84. Tips3 - プロンプトに常時加えたいメッセージを追加する - プロンプトに常時入れている内容を追加する => .github/copilot-instructions.md に記述 - プロンプト入力時に合成されるイメージ 私たちはJavaの依存関係を管理するために MavenではなくBazelを使用しているので、 Javaのパッケージについて話す際は、常に Bazelを使用した手順やコードサンプルを提供してください。 私たちはJavaScriptのコードを常にダブルクオート（ "）とタブでインデントして記述しているため、 JavaScriptのコードを含む回答では、その規則に従ってください。 私たちのチームは、作業項目の管理に Jiraを使用しています。 サンプル文 参考: GitHub Copilot のリポジトリ カスタム命令を追加する - GitHub Docs
85. Tips4 - プロンプトに事前にルールを教えこみたい - プロンプトの事前命令 => setting.jsonに記述 "github.copilot.chat.codeGeneration.instructions": [ { "text": "Always add a comment: 'Generated by Copilot'." }, { "text": "In TypeScript always use underscore for private field names." }, { "file": "code-style.md" // import instructions from file `code-style.md` } ], サンプル文 Custom instructions for GitHub Copilot in VS Code fileを指定することも
86. Tips5 - プロンプトの再利用可能性を高める (Experimental) - .github/promptsに再利用可能なPromptsを配置 プロンプト添付ファイルから 検索 & 選択可能に
87. コードリーディングにおける Github Copilotとの付き合い方
88. 生成AIに期待していること 聖徳太子的な優秀さを期待 - 高性能・高速処理 - マルチスレッド - 正確そう - 早口そう
89. 現実の生成AI 聖徳太子？　白 Tシャツ　おもしろ Tシャツ　偉人で１言 こんな雰囲気 - 部分的に高性能 - 範囲が広いが苦手 - シングルスレッド - たまにテキトーな発言 - ハショることもある - 初見の学習は異様に早い
90. “偵察隊”としては良い働きをしそう 初見の学習が人間より早い を利用するならば、 生成AIが初見でざっくり見た景色を 報告してもらうが良い使い方？
91. こんな気持ちに出会うことがある (抵抗因子) - コードを読まないのは気持ち悪い - 最終的にはコードを読め、という教育を受けてきた - コードを読むこと自体が好きなので、読まない体験自体が萎える - コードリーディングの時間をとる習慣がない - 何かのついでの調べ物としてやっていることが多い - 意識してコードリーディングをやっていないので、効率をあげようという動きになりにくい - コードリーディングに寄与するのか懐疑的 - 生成AIの正確性に懐疑的 - 正確性と速度の両立が可能なのか？
92. といっても、コードリーディングの速度があがる = 嬉しいことが多い - 開発要件の策定がはやくなる - 既存実装の理解をはやめることで、仕様策定がはやまる - 既存実装の落とし穴や罠にはまらずにすむようになる - 自分の開発可能領域が拡張できる - 自分が知らない領域のキャッチアップ速度をあげる - 自分の開発範囲を広げていくことができる - 協調開発がスムーズになる - 誰かの書いたコードを即座に把握できる - 協調しながら並列で開発しやすくする
93. Github Copilotと 良いコードリーディングライフを！