ターミナルを閉じずに一日を終えたい、というのはVimmerにとって単なるこだわりではないと思っています。
コンテキストスイッチには、思っている以上にコストがかかります。
ブラウザに引き剥がされる瞬間の話
コードを書いていて、レビュー依頼の通知が来る。
そのままターミナルを離れてブラウザを開き、GitHubのPRページに飛ぶ。
マウスに手が伸びて、diffをスクロールして、コメントを書いて、また戻る。
この一連の動作が、正直しんどいんですよね。
キーバインドが頭の中でリセットされる感覚、というか。
Vimで鍛えた指の記憶がブラウザでは完全に死んで、急に「普通のPC操作」に引き戻される。
集中の糸が一本ぷつんと切れる瞬間です。
もう少し具体的に言うと、問題はキーバインドだけじゃないんですよね。
ブラウザに移動した瞬間に、タブが目に入る。
Slackの通知バッジが視界の端に引っかかる。
「ついでにこっちも確認しよう」という誘惑が生まれる。
レビューに集中しようとしていたはずが、気づいたら別のことをしている。
ターミナルに閉じこもっていると、そういう誘惑の入り口がそもそも少ない。
「ターミナルを出たくない」という感覚は、集中環境を守りたいという実利的な判断でもあります。
gh CLIを使えばある程度はターミナルに留まれます。
gh pr diff でdiffをパイプに流したり、gh pr review でコメントを書いたりはできる。
でも正直なところ、diffの視認性がつらい。
ターミナルに流れてくる生のdiffテキストは、ファイルをまたいだナビゲーションがぎこちないし、どこまで読んだかも追いにくい。
インラインコメントを特定の行に紐づけながら書くのも操作が煩雑で、「これならブラウザのほうが早い」と折れてしまうことが何度もありました。
gh CLIはPRを「作る・マージする・CIを確認する」のが得意なツールで、diffを 読んでコメントを書く という作業に最適化されているわけではない。
そこは設計の優先順位の問題であって、gh CLIが悪いわけでもない。
ただ、そのギャップが確かに存在していて、ずっと気になっていました。
そのギャップを埋めようとしているのが tuicr です。
「tweaker」と読むらしい。
Rust製のTUIで、GitHubスタイルのdiffをターミナル内で閲覧しながら、インラインコメントを書いてそのままPRレビューとして送信できます。
Vimキーバインドが前提の設計になっているので、指の記憶が死なずに済む。
それだけで、試してみる価値はあると思いました。
インストールから最初のレビューまで
インストールは複数の方法が用意されています。
# curl（最速）
curl -fsSL tuicr.dev/install.sh | sh
# Homebrew
brew install agavra/tap/tuicr
# Cargo
cargo install tuicr
# Mise
mise use github:agavra/tuicr
# Nix
nix run github:agavra/tuicr
curl一発が一番手軽です。
Cargoが入っている環境ならそちらでも問題ありません。
Miseを使っている人はプロジェクトごとにバージョンを固定できるので、チームで揃えるときに便利です。
認証はgh CLIに乗っかります。
あらかじめ gh auth login を済ませておけば、tuicr側で追加の認証作業はいりません。
gh CLIが入っていない場合はそちらを先にセットアップしておく必要があります。
GitLabを使っている場合はglabが対応しているので、同じ考え方で準備できます。
起動はリポジトリのディレクトリ内で tuicr を実行するだけです。
引数なしで起動すると、ローカルのgit差分を拾ってくれます。
GitHubのPRに対してレビューを送信したい場合も、起動後の操作（:submit）でリモートのPRに紐づけられるので、起動時点では特別な引数は不要です。
起動すると、左ペインにファイルツリー、右ペインにdiffが並んだ画面になります。
最初に一度戸惑うのが、フォーカスの概念です。
どちらのペインにフォーカスがあるかによって、同じキーでも動作が変わる場面があります。
操作に迷ったら ? でヘルプを開くと、現在使えるキーバインドが一覧できます。
これは最初に必ず一度やっておくと、その後の操作感がぐっと上がります。
gh CLIとの役割分担をここで整理しておくと、gh はPRのライフサイクル管理（作成・マージ・CIステータス確認・ラベル操作など）が得意で、tuicr はdiffを 読んでコメントを書いてsubmitする という行為に特化しています。
どちらか一方に乗り換えるというより、gh でPRを一覧して、tuicr でdiffを読む、という流れで両者を並べて使うイメージです。
競合ではなく、組み合わせて使うものです。
diff を読んでコメントを書いて submit するまで
実際のレビューフローを、操作の流れとして追ってみます。
# 基本ナビゲーション
j / k : 行単位でスクロール
Ctrl-d / Ctrl-u : 半ページスクロール
g / G : 先頭 / 末尾へジャンプ
{ / } : 前 / 次のファイルへ移動
[ / ] : 前 / 次のhunkへ移動
m / M : 前 / 次のコメントへ移動
# コメント操作
c : カーソル行にインラインコメントを追加
C : ファイル全体へのコメントを追加
v / V : ビジュアルモードで範囲選択（範囲コメント）
# レビュー操作
r : 対象ファイルをレビュー済みにトグル
R : 対象hunkをレビュー済みにトグル
e : フォーカス中のファイルを $EDITOR で開く
y : レビュー内容をクリップボードにコピー（Markdown形式）
:submit : GitHubへレビューを送信
この並びを見ると、Vimの操作体系がそのまま移植されているのが分かります。
g/G でトップ・ボトムに飛んで、{/} でファイルをまたいで、[/] でhunk単位に移動する。
覚えることが少ないのに、大きなdiffでも迷わず動き回れます。
特に v/V のビジュアルモードで範囲を選んでコメントを書けるのは、ブラウザのGitHub UIでも意外とやりにくい操作で、ここは素直に便利だと感じました。
ブラウザだと行を選択してコメントアイコンをクリックして、という手順が必要で、複数行にまたがる指摘をしたいときに地味にもたつく。
tuicr では v で選択を始めて、範囲を決めて c を押すだけです。
c を押すとコメント入力画面になります。
コメントタイプとして note・suggestion・issue・praise の4種類から選べます。
suggestion は変更提案のコメント、issue は問題指摘、praise は褒めるコメントです。
このタイプ分けは、レビューの意図を受け取り側に伝えやすくする仕組みで、「これは直してほしい指摘なのか、参考情報なのか」が一目で分かるようになります。
チームのレビュー文化によっては、このタイプを積極的に使い分けるだけでコミュニケーションコストが下がります。
一通りコメントを書き終えたら :submit を実行します。
ピッカーが開いて、Comment・Approve・Request changes・Draft の4択から選べます。
選択するとそのままGitHubのPRレビューとして送信されます。
インラインコメントは正しい行に紐づいた状態でPRに反映されるので、ブラウザで確認しても違和感なく表示されます。
y でクリップボードにMarkdown形式でコピーできる機能も地味に使えます。
Claude CodeやCursorなどのAIエージェントにレビュー内容を渡したいとき、この出力をそのままコンテキストとして貼り付けられます。
たとえば「このdiffのレビューコメントを書いてほしい」とエージェントに依頼して、返ってきた内容をtuicr上でひとつひとつ確認・修正してsubmitする、というフローも現実的に組めます。
AIが書いたコメントをそのまま送るのではなく、自分の目を通してから送る、という人間の判断を挟む場所としてtuicrが機能します。
e でフォーカス中のファイルを $EDITOR で開ける点も、Vimmerには自然に馴染みます。
diffを読んでいて「ここ、実装の全体像を確認したい」となったときに、そのままNeovimに飛べる。
確認が終わったらターミナルに戻ってレビューを続ける。
ブラウザを経由しないで済むのが、やはり気持ちいい。
実用して見えてきた限界と、それでも使い続ける理由
正直に言うと、tuicr だけで全てのレビュー作業が完結するわけではありません。
使い続けていると、Webに戻らざるを得ない場面が出てきます。
一番よく遭遇するのは、コメントスレッドへの返信です。
既存のレビューコメントに返信する操作は、現時点のtuicrでは対応が限定的です。
レビュアーとのやり取りが続いているPR、たとえば「この実装方針でいいですか？」「それよりもこっちのアプローチはどうでしょう」という往復が起きているような状況では、スレッドの文脈を追うためにブラウザを開くことになります。
初回レビューを書くのは得意でも、その後の議論を拾い続けるのはまだ苦手、というのが現時点の正直な評価です。
CIのステータス確認や、PRの概要・関連issueの把握も同様です。
tuicr はあくまでdiffとコメントに集中したツールなので、PRのメタ情報を読み込む用途には向いていません。
「このPRが何を解決しようとしているのか」「どのissueと紐づいているのか」を把握するには、gh CLIで gh pr view を叩くか、素直にブラウザで確認するほうが早い場面も多い。
大規模なPRも、tuicr だけで完結させるのは少し難しい。
変更ファイルが数十に及ぶような場合、全体の設計意図を把握しながらdiffを読む必要があって、そういうときはブラウザのほうがPRの説明文やコメント履歴と並べて確認しやすいです。
tuicr が最も力を発揮するのは、変更の規模が把握しやすくて、コメントのやり取りがまだ始まっていない、初回レビューの場面だと感じています。
筆者が実際に使い分けているのは、だいたいこういう基準です。
- tuicr を使う場面: 初回レビューでdiffをひと通り読んでコメントを書く、比較的小〜中規模のPR、レビュアーとして最初の一手を打つとき
- Webに戻る場面: コメントスレッドへの返信が続いているとき、PRの背景や設計意図を読み込む必要があるとき、CIの詳細ログを確認するとき、大規模なPRで全体像を把握したいとき
gh CLI・tuicr・Web の三者は「どれか一つを選ぶ」ものではなく、それぞれが得意な場面を持っています。
gh CLI でPRを一覧して、tuicr でdiffを読んでコメントを書き、スレッドの返信はブラウザで処理する。
この分担が今のところ一番しっくりきています。
tuicr を試してみる価値があるかどうかは、正直「ターミナルを出たくない気持ちがどのくらい強いか」で決まると思います。
ブラウザのGitHub UIで特に不満がない人には、乗り換えコストに見合わないかもしれない。
でも、レビュー作業でブラウザに飛ぶたびに微妙なストレスを感じているなら、一度試してみる価値はあります。
インストールはcurl一発で終わるので、試すコストは低い。
気に入らなければ消せばいいだけです。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援を手がけているIT企業です。
ターミナル中心のワークフローや開発ツールの選定・導入支援についても対応しています。
何か相談があれば、お気軽に お問い合わせ からどうぞ。