新しいリポジトリに入ったとき、どこから読み始めるか毎回迷います。
READMEを読み、main を探し、なんとなく分かった気になって、次の日には忘れています。
「読んだ気になる」を「答えられる」に変えたくて、repo-educator というサービスを作りました。
- デモ: https://repo-educator.web.app/
- GitHubのリポジトリURLを渡すと、実際のコードから4択クイズが生成されます
- 同時に、機能名・関数名・やりたいこと・ファイル名の4つの粒度で引ける逆引きドキュメントも作られます
- パブリックリポジトリはそのまま試せます。サンプルも用意しています
- ログインすると、学習履歴の保存と、PATを登録してのプライベートリポジトリの解析が使えます
| psf/requests | TheAlgorithms/Python | gin-gonic/gin |
|---|---|---|
![]() |
![]() |
![]() |
何ができるのか
穴埋め4択クイズ
リポジトリのソースを取得し、Geminiに投げて、コードの一部を ? に置き換えた4択問題を生成します。
問題文には「この関数はリトライ処理の途中である」といったシナリオが添えられ、回答後には解説が出ます。
そのコードが何をしようとしているかを分かっていないと選べない選択肢になるようプロンプトで縛っています。
左に問題とコード、右に選択肢。
?の部分に何が入るかを選ぶ
| 正解のとき | 間違えたとき |
|---|---|
![]() |
![]() |
回答すると、なぜそれが正解なのかの解説が出る
逆引きドキュメント
クイズは読む力を鍛えるのには向きますが、
「この機能どこに書いてある?」に今すぐ答えるには使えません。
そこで、同じソースから索引を作ります。
| 種別 | 何で引くか | 例 |
|---|---|---|
feature |
機能名 | 「認証」「リトライ処理」 |
symbol |
関数・クラス名 | Context.Next() |
task |
やりたいこと | 「新しいエンドポイントを追加するには」 |
file |
ファイル名 | context.go |
技術構成
| 領域 | 技術 |
|---|---|
| フロントエンド |
|
| バックエンド |
|
| データベース |
|
| AI | ![]() |
| インフラ / CI |
|
呼び出しをどう減らすか
このサービスには、無視できないコストが2つあります。
- GitHub API のレートリミット: 未認証だと 60 req/h。ファイル取得はファイル数に比例して消費する
- Gemini の料金: 生成のたびにかかる
そして重要な事実として、同じリポジトリの同じコミットを解析した結果は、誰がやっても同じです。
であればユーザーをまたいで結果を共有できます。
削減方法
キャッシュを活かすために効いたのは、判定に必要な最小限の情報だけを先に取るという順序でした。
前回と中身が同じなら、ソースの取得もAI生成もまるごとスキップできます。
その判定に使ったのが pushed_at(リポジトリの最終push日時)とコミットSHAの2つです。
解析したときにこの2つをPostgreSQLへ記録しておき、
次のリクエストではGitHubから取得した最新値とDBの記録を突き合わせます。
一致していれば中身は変わっていないので、そこで打ち切ってキャッシュを返します。
PATの扱い
PATは cryptography.fernet で暗号化してDBに保存し、復号鍵はSecret Managerに置いています。
登録画面。トークンは暗号化して保存され、名前を付けて複数管理できる
複数登録でき、どのトークンでどのリポジトリを読むかは自動で判別します。
今後の展望
GitHub Appによるサインインに寄せる予定です。
PATの手動発行が要らなくなり、リポジトリ単位で権限を絞れ、失効も組織側で管理できるようになります。
「使い始めるまでにGitHubの設定画面を往復させる」のが今いちばんの障壁なので、ここを先に潰したいところです。



















