VS Codeに載った`githubRepo`を使うことで未学習ライブラリを用いたVibe Codingを加速できるのではないか

VS Code v1.100で登場したgithubRepo機能、試しましたか？いや全然知らなかったんだわこれ。

You can now use the #githubRepo tool to search for code snippets in any GitHub repository that you have access to. This tool takes a user/repo as extra input. For example, "how to implement factory pattern in TS #githubRepo microsoft/vscode".

Search code of a GitHub repository with the #githubRepo tool

GitHubリポジトリをローカルにクローンしなくても、リモートのまま中身をサクッと閲覧できて、しかもCopilotと連携してコードの意味や使い方をAIに質問できるんです。大規模なOSSや、ちょっと気になる新ライブラリの調査が一気にラクになりました。

githubRepoの回答をコンテキストに流し込めば、生成AIが学習してないライブラリやフレームワークを用いたVibe Codingも相当程度加速するんじゃないかと思っています。これってContext7 MCPサーバが解こうとしていた課題の一つじゃないだろうか。

実際の例
- 回答
可能性を感じたこと
- 未学習ライブラリの障壁解消
- 学習コストの削減
結論

実際の例

百聞は一見に如かず、ということで、以下のようなプロンプトを投げてみた結果は次の通り。

#githubRepo Fintan-contents/example-chat をみて、Nablarchフレームワークを使った時の REST API を受け付ける Action クラスのベストプラクティスをサンプルと共に示して

回答

NablarchフレームワークでREST APIを受け付けるActionクラスのベストプラクティスは、Fintan-contents/example-chatの実装例から多く学べます。ここでは、実際のサンプルとともに、設計・実装上のポイントを解説します。

基本構成とアノテーション

@SystemRepositoryComponent でDI管理対象に

@Path でエンドポイントを指定

HTTPメソッドごとに @GET/@POST/@PUT/@DELETE などを付与

@Consumes/@Produces でリクエスト・レスポンスのContent-Typeを明示

サンプル・メッセージ投稿API
@SystemRepositoryComponent
@Path("/channels/{channelId:\\d+}/messages")
public class MessagesAction {

    private final MessagePostingService messagePostingService;
    private final LoginAccountIdSupplier loginAccountIdSupplier;

    public MessagesAction(MessagePostingService messagePostingService,
                         LoginAccountIdSupplier loginAccountIdSupplier) {
        this.messagePostingService = messagePostingService;
        this.loginAccountIdSupplier = loginAccountIdSupplier;
    }

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    @CheckPermission(Permission.CHANNEL_MEMBER)
    public void post(HttpRequest request, ExecutionContext context, TextPostRequest requestBody) {
        // パラメータバリデーション
        ValidatorUtil.validate(requestBody);

        // パスパラメータ取得
        ChannelId channelId = new ChannelId(Long.valueOf(request.getParam("channelId")[0]));
        AccountId accountId = loginAccountIdSupplier.supply();

        // サービス呼び出し
        messagePostingService.postText(channelId, accountId, requestBody.text);
    }

    public static class TextPostRequest {
        @NotNull
        public MessageText text;
    }
}
3.ベストプラクティス解説

3.1. 依存性注入（DI）を活用

サービス層やユーティリティはコンストラクタインジェクションで受け取る

テスト容易性・保守性が向上

3.2. バリデーションの徹底

ValidatorUtil.validate(requestBody); でリクエストの妥当性を必ず検証

@NotNull などBean Validationアノテーションを活用

3.3. パス・クエリパラメータの取得

request.getParam("channelId") でパスパラメータを取得

型変換やnullチェックも忘れずに

3.4. 認可チェック

@CheckPermission で権限制御を明示

コードから権限漏れを防ぐ

3.5. リクエスト/レスポンスの型設計

リクエスト・レスポンスは静的な内部クラスで定義

フィールドはpublicでシンプルに（Jackson等で自動シリアライズ）

3.6. 例外・エラー処理

サービス層で発生した例外は、ハンドラ（例：RestApiErrorResponseHandler）で一元的にハンドリング

エラー内容はAPI利用者にわかりやすく返す

反証・異論も考慮

「Actionクラスが肥大化しやすい」 → サービス層にロジックを寄せ、Actionは「受け口」として薄く保つ

「バリデーションや認可の抜け漏れ」 → アノテーションや共通ユーティリティで仕組み化

可能性を感じたこと

未学習ライブラリの障壁解消

個人的に一番インパクトを感じたのは、AIがまだ学習していない新しいライブラリやフレームワークにも、リアルタイムで適応できるようになったことです。これまではLLMの学習データに含まれていないと、AIの提案が的外れになりがちでした。でもgithubRepo機能なら、AIが「今その場でリポジトリの中身を参照」しながらコード生成してくれるので、未知のOSSでも実用的な提案がもらえます。

上にNablarchというフレームワークに関する問合せ結果の例を記載しましたが、結構いいんじゃないかと思います。変なstatic classがあるけど、全体的にはいい感じのActionクラスだ。Deepwiki MCPサーバ的な使い方（＝リポジトリを知識ベースとしてAIに参照させることで、現場の知見を即時に活用できる仕組み）もできそう。

特定のライブラリに詳しい「エキスパート」の価値は相対的に下がるかもしれません。GitHub Copilotが専門知識をコンテキストに注入してくれるので、チーム内の知識格差は縮まりそうです。