200個のGitHubリポジトリを横断調査したかった
by
Issei.Komori
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
200個のGitHubリポジトリを 横断調査したかった 生活協同組合コープさっぽろ 2026/06/17 小森一成(@icckx) クラメソさっぽろIT勉強会 (仮) #14 〜オススメの Agent Skills〜
Slide 2
Slide 2 text
小森 一成(@icckx)
Slide 3
Slide 3 text
「オススメのAgentSkills」 is 自作Skillsの話 200個のリポジトリを横断調査 したかった 自作Skills gh-repo-profiler やってみて設計で学んだことを共有
Slide 4
Slide 4 text
作成の背景と目的 Aさん「うちってどんな技術スタックがデファクトなの?」 私「エンジニア内でなんとなく、これっていう共通認識はありますね...」 Aさん「GitHubリポジトリみて調査して」 私「わかりました(AIある時代だし、なんとかなるよね)」
Slide 5
Slide 5 text
1個ずつ人間が見て回るのは無理。だから横断で 言語 / フレームワーク / パッケージマネージャ / IaC / クラウド… SBOMじゃ細かすぎ、GitHub CLIだけじゃ情報不足... 1個ずつ、CloneしてAIに調査させる?!だるすぎ...
Slide 6
Slide 6 text
素朴にAIに聞くと上手くいかない 抜ける(見るべきファイルを探し損ねる) 推測で埋める(ハルシネーション) 出力フォーマットが毎回バラバラ
Slide 7
Slide 7 text
作ったもの: gh-repo-profiler owner/repo を渡すと、技術選定プロファイルを ~/repo-profiles//.json に出力するSkills 目的は「単発の構成解説」ではなく 横断クエリ可能な判断材料を溜めること 1リポジトリ = 1 JSON、蓄積前提の設計 作り方: /grill-with-docs → /skill-creator
Slide 8
Slide 8 text
設計の核: 素材取得は「決定的スクリプト」 LLMに「探させる」と抜ける gh CLI + tarball で マニフェスト / CI / IaC / README を機械的に回収 LLMの仕事は「集める」ではなく 「読んで構造化する」だけ
Slide 9
Slide 9 text
設計の核: なぜ出力をJSONにしたか スキーマ固定JSONにして出力を安定化 DuckDBがそのまま読める形に、溜めたJSONを横断クエリ可能としておく Skills Skills Skills Skills Skills
Slide 10
Slide 10 text
溜めた瞬間、問いがSQL1本に DuckDBで一発(ゴールデンSQLはSkillsのReferenceに) JSON, CSV, Parquet なんでもSQLで操作で きちゃうやつ → LLMの集計に 確実性を与える
Slide 11
Slide 11 text
学び: 200個は「サブエージェント」で捌く /gh-repo-profiler サブエージェントつかって処理して。 Repo1 Repo2 Repo3 … (Repo45までは平行はためした 当時 Opus4.7)
Slide 12
Slide 12 text
おまけ:レポートはHTMLで DuckDBで集計したものを Pythonでグラフにして、 LLMのの評価とかけ合わせる レポートだとHTMLは MarkDown + Mermaid より 見やすい レポート用のSkillsが 別途あると便利
Slide 13
Slide 13 text
まとめ 取得は決定的スクリプト、構造化だけLLM → 抜け・嘘を防ぐ 出力はDuckDB可読のJSON → 出力も後続の入力も安定する 大量実行はサブエージェント → 親の文脈を汚さず200個を捌く
Slide 14
Slide 14 text
200個のGitHubリポジトリを 横断調査したかった 生活協同組合コープさっぽろ 2026/06/17 小森一成(@icckx) クラメソさっぽろIT勉強会 (仮) #14 〜オススメの Agent Skills〜