「あのリポジトリどこだっけ？」を完全卒業。VS Code使いがあえて「ghq×fzf」を手放せない理由

2026/09/09

開発環境ツール・効率化

開閉

日々の開発において、VS Codeはもはや多くのエンジニアにとってなくてはならない必須エディタです。会社支給のMacBook Proでも自宅のWindowsノートPCでも、私もVS Codeを開かない日はありません。

ここで、ひとつの疑問が浮かぶ方も多いと思います。

「VS CodeのGitHub拡張機能や『最近開いたリポジトリ（Cmd/Ctrl + R）』を使っていれば、リポジトリ移動で困ることなんてなくない？」

結論から言うと、「VS Codeを開いて、その中でコードを書くことだけに集中している時間」 であれば、確かにエディタ標準の機能や拡張機能だけで十分事足ります。

しかし、実際の現場で開発を進めていると、エディタのGUIだけではどうしてもカバーしきれない「地味で痛い摩擦」がターミナル側に確実に残ります。

今回は、VS Codeを毎日使い倒している私が、なぜ今でもターミナル上の「ghq」と「fzf」を手放せないのか、その本質的な理由と、VS Codeと組み合わせることで爆速化する実践テクニックを詳しくお話しします。

ぶっちゃけ「VS Codeの履歴や拡張機能」だけでは何が困るのか？

VS Codeには、直近で作業したプロジェクトを瞬時に開くショートカット（Macなら Cmd + R、Windowsなら Ctrl + R）があります。また、GitHubの拡張機能を使えばリモートリポジトリを直接開くことも可能です。

それでもなお、実務の中で私たちが直面する「3つの壁」があります。

graph TD
    A["VS Code中心の開発日常"] --> B{"直面する3つの壁"}
    B --> C["1. 『最近開いた』履歴から消えたリポジトリの遭難"]
    B --> D["2. ターミナルファーストな作業（Docker / CLI）の存在"]
    B --> E["3. シェル側の長文コマンド履歴（Ctrl + R）はエディタ外"]
    C --> F["ghq × fzf で解決"]
    D --> F
    E --> F

1. 「最近開いた」リストから押し出された瞬間の遭難

VS Codeの「最近開いた項目」に常駐しているのは、せいぜい直近1〜2週間に触ったアクティブな数個のリポジトリだけです。

「3ヶ月前に作ったあの検証スクリプト、どこに置いたっけ……？」
「別チームのマイクロサービスのリポジトリ、ローカルのどこにクローンしたっけ……？」

こうして履歴から押し出されたリポジトリを探す時、結局はOSのファイルツリー（Finderやエクスプローラー）をポチポチ辿るか、ターミナルで cd ../../../ を連打して階層迷子になることになります。

2. ターミナルファーストな作業（Docker / DB / インフラ操作）

Webエンジニアの仕事は、コードをエディタで書くだけでは終わりません。

Dockerコンテナのビルドや再起動
DBのマイグレーション実行（migrate や psql）
TerraformやAWS CLIによるインフラ確認
自作のシェルスクリプトやバッチのローカル実行

こうした作業は、ターミナルで直接叩く方が圧倒的に早い場面が多々あります。その際、「まずターミナル上でそのリポジトリのルート階層に移動していなければコマンドが叩けない」という物理的な制約が立ちはだかります。

3. VS Codeでは絶対に代行できない「コマンド履歴の検索」

先週叩いた複雑な引数付きのDockerコマンドや、滅多に使わないデータベースのダンプコマンド。
これらはエディタの機能ではなく、シェルの履歴から掘り起こす必要があります。bashやzshの標準 Ctrl + R では1件ずつしか遡れず、探している間に思考が途切れてしまいます。

過去の苦い失敗：適当なディレクトリ配置が生んだ「深夜の先祖返り事件」

かつての私は、この問題に対して「その場の気分で適当に git clone して cd で移動する」という運用で乗り切ろうとしていました。

~/dev/、~/workspace/、ときには ~/Desktop/tmp/ など、思いつきのフォルダにクローンしていた結果、ある深夜にとんでもないやらかしを起こしました。

1時間溶かした「幻のバグ修正」

緊急の不具合修正で急いでプルリクエストを作ろうと、コードを直してテストを通し、「よし、これでプッシュ！」と意気込んでいたのですが、なぜかGitの変更差分が最新ブランチと全く噛み合いません。

深夜の朦朧とした頭で原因を調査して血の気が引きました。数ヶ月前に古い検証で別階層にクローンしていた「過去の亡霊リポジトリ」側で作業していた のです。

「どこに置いたか分からない」「同じリポジトリが複数存在する」という状態は、単に移動が遅いだけでなく、こうした重大なヒューマンエラーの温床になります。

ghq × fzf がもたらす「最強の役割分担」

この問題を根本から解決するのが、ghq と fzf の組み合わせです。

graph TD
    subgraph "ghq（配置のルール化）"
        A["ghq get <URL>"] -->|"自動で階層分類"| B["~/ghq/github.com/org/repo"]
        C["保存先ルールを物理的に強制統一"]
    end

    subgraph "fzf（あいまい即時検索）"
        D["Ctrl + G（リポジトリ検索）"] -->|"2〜3文字入力"| E["一瞬で目的の階層へ cd"]
        F["Ctrl + R（履歴検索）"] -->|"あいまいインクリメンタル"| G["過去の複雑コマンドを一発呼び出し"]
    end

ghq: リポジトリの保存先を ~/ghq/github.com/ユーザー名/リポジトリ名 に強制一本化するツール。「どこにクローンしようか」と悩む余地を物理的になくします。
fzf: ターミナル上で動く超高速な対話型あいまい検索（Fuzzy Finder）。適当なキーワード（site, api, batch 等）を打つだけで候補をリアルタイムに絞り込みます。

VS Codeと対立しない。「VS Codeを最速で開くランチャー」になる

ここが最大のポイントです。ghqとfzfは、VS Codeと競合するものではありません。むしろVS Codeを最速で立ち上げるための「最高のランチャー」として機能します。

# ターミナルで Ctrl + G を押す
# → 「blog」と打って Enter（1秒で目的のリポジトリへ移動）
# → そのまま以下を叩く
code .

たったこれだけで、数ヶ月触っていなくてVS Codeの履歴から消え去っていたリポジトリでも、2秒後にはVS Codeで開き直すことができます。

5分でできる実践セットアップ

MacでもWindows（WSL2 / PowerShell）でも、手順は非常にシンプルです。

1. ツールのインストール

macOS（Homebrew）

brew install ghq fzf

Windows（WSL2 または winget）

WSL2（Ubuntu環境）ならパッケージマネージャ等で導入できます。

# WSL2 (Ubuntu / Debian)
sudo apt update
sudo apt install -y fzf

# ghq は Go 製バイナリ、またはパッケージマネージャで導入

Windowsネイティブ（PowerShell）を使う場合は winget でも手に入ります。

winget install -e --id x-motemen.ghq
winget install -e --id junegunn.fzf

2. シェルの設定（.zshrc / .bashrc）

ghq の一覧を fzf に渡し、選択したディレクトリへ移動する関数をシェルに定義します。

以下を ~/.zshrc（または ~/.bashrc）に追記してください。

# ==============================================================================
# ghq + fzf による爆速リポジトリジャンプ（Ctrl + G）
# ==============================================================================
function ghq-fzf-repo() {
  local selected_dir
  # ghq list の結果を fzf に流し込み、選択されたパスを取得
  selected_dir=$(ghq list --full-path | fzf --reverse --height 40% --query "$LBUFFER")

  if [ -n "$selected_dir" ]; then
    BUFFER="cd ${selected_dir}"
    zle accept-line
  fi
  zle reset-prompt
}

# ウィジェットとして登録し、Ctrl + G にキーバインドを割り当て
zle -N ghq-fzf-repo
bindkey '^G' ghq-fzf-repo

# ==============================================================================
# fzf 標準の履歴検索（Ctrl + R）の有効化
# ==============================================================================
# fzf のキーバインドと自動補完を読み込む（brew インストールの場合の標準パス）
if [ -f "$(brew --prefix)/opt/fzf/shell/key-bindings.zsh" ]; then
  source "$(brew --prefix)/opt/fzf/shell/key-bindings.zsh"
  source "$(brew --prefix)/opt/fzf/shell/completion.zsh"
fi

設定を保存したら、source ~/.zshrc で反映させます。

おじさんエンジニアの本音：あえて「プレビュー機能を凝りすぎない」理由

fzf には、右側にファイルのプレビュー（bat や cat で中身を表示する）を出す強力なオプションがあります。

私も一時期、「どうせなら最高にかっこよくしよう」とリポジトリ移動時に README.md を右側にプレビュー表示させたり、Gitログをグラフィカルに出す設定をモリモリに盛り込んでいた時期がありました。

しかし、数ヶ月使って行き着いた本音の結論は、「リポジトリ移動と履歴検索に、豪華なプレビューは邪魔なだけ」でした。

【プレビューを盛りすぎた時の弊害】
1. ノートPCの画面（13〜14インチ）でターミナルを2分割すると、横幅が狭くて文字が折り返され視認性が落ちる
2. プレビュー生成プロセスの呼び出しで、キー入力への追従がコンマ数秒もたつく
3. そもそもリポジトリを移動したい時に見たいのは「リポジトリ名」だけであり、READMEの中身ではない

開発において最も大切なのは、「思考のスピードを落とさないこと」（低レイテンシ）です。
装飾は最低限にし、純粋にパスだけを高速にフィルタリングするシンプルな設定こそが、何年経っても飽きずに使い続けられる秘訣だと実感しています。