hunk（modem-dev/hunk） は、AIエージェントが書いた差分をターミナルでレビューするための「レビューファースト」なdiffビューアだ。AIにコードを書かせる時間より、エージェントが書いた差分をレビューする時間のほうが長くなってきた——そう感じている人は多いはずだ。Claude CodeやCodexが数十ファイルにまたがる変更を一気に生成し、人間はそれをgit diffの長い出力とにらめっこして承認可否を判断する。従来の差分ツールは「色を付けて読みやすくする」ところで止まり、AIの意図や人間の指摘はチャット欄に散らばっていく。
hunkは、この「AI時代のレビュー」を正面から作り直したツールだ。サイドバーで変更ファイルを一望し、AIのコメントを差分行の真横に置き、さらにエージェントと人間が同じ画面を往復する双方向レビューまで踏み込む。Qiitaでの紹介やGhostty作者Mitchell Hashimoto、Hono作者の和田裕介（@yusukebe）の反応で注目を集め、公開4ヶ月でGitHubスターは6,700を超えた。この記事では、hunkが「結局何ができて・何を解決し・何を代替するのか」を、公式リポジトリの一次情報をもとに図と実コマンドで解説する。
Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。本記事はその補完として「エージェントが書いた差分をどうレビューするか」に絞って深掘りする。
- ・hunkが「レビューファースト」なdiffビューアとして何を解決するのか。
- ・split・stack・サイドバーからなる画面構成と基本操作。
- ・npm/Homebrewでの導入と、Git・Jujutsu・Saplingでの最初のレビュー手順。
- ・AIエージェントが差分の横にコメントを注入し、人間の`c`メモを回収する双方向レビューの仕組み。
- ・delta・difftastic・difitとの立ち位置の違いを比較表で整理。
- ・v0.17.0時点の制限とClaude Code連携の運用例。
hunk とは何か——「レビューファースト」という発想の diff ビューア
hunkの公式説明は「エージェントが書いたchangesetのための、レビューファーストなターミナルdiffビューア」だ。ここで大事なのは「表示」ではなく「レビュー」を第一に置いている点にある。従来のgit diffやページャは、変更内容を色付きテキストとして流すことがゴールだった。読みやすくはなるが、「どのファイルから見るか」「AIがなぜこう変えたのか」「ここは直してほしい」といったレビュー行為そのものは、ツールの外——頭の中やチャット欄——に置かれていた。
hunkはその前提をひっくり返す。変更セット全体をサイドバー付きのレビューUIとして開き、ファイル間をジャンプし、上から下まで通してレビューする。AIの推論コメントは差分の横に並び、コンテキストが「別タブ」ではなく「差分の中」に生きる。これがhunkの核心的な価値提案であり、AIがコードを量産する時代にレビューのボトルネックを解きにいく設計だ。
技術的には、hunkはターミナルUIフレームワークの OpenTUI と、差分レンダリングライブラリ Pierre diffs の上に構築されている。TypeScript製で、npmにはhunkdiffという名前で公開されている。ライセンスはMIT、開発元はModem社だ。「diff」ではなく「hunk（差分のかたまり）」という名前が、行単位ではなく変更のまとまりを単位にレビューするという思想を表している。
著名エンジニアの反応が語る立ち位置
hunkが単なる「もう一つのdiffツール」で終わらなかった理由は、レビュー体験の質の高さにある。Ghostty・Vagrantの作者Mitchell Hashimoto は、hunkがローカルの他のdiffビューアを完全に置き換えたと評価している。Ruby on Rails・Omarchyの作者DHH も “Love hunk.” と短く反応した。日本では、Honoの作者である和田裕介（@yusukebe）が取り上げたことで一気に認知が広がった。
こうした反応に共通するのは、「AIが書いた差分を人間が捌く」という新しいワークフローに、既存ツールが追いついていなかったという感覚だ。hunkはその空白を埋めにきた。特にターミナルで作業を完結させる開発者にとって、ブラウザやGUIに切り替えずにレビューできることは大きい。
なぜ今「レビューファースト」なのか
少し立ち止まって、なぜこのタイミングでレビュー特化のdiffツールが必要になったのかを整理しておきたい。理由はシンプルで、コードを「書く」コストと「レビューする」コストのバランスが、AIエージェントによって崩れたからだ。以前は、コードは人間が一行ずつ書くものだった。書く過程そのものがレビューを兼ねており、差分は「自分が数時間かけて書いたもの」だった。だからgit diffの色付きテキストで十分だった——書いた本人が読むのだから。
ところが、Claude CodeやCodexのようなエージェントは、数分で数十ファイル・数百行の変更を生成する。人間はその差分を「初見で」「大量に」「短時間で」判断しなければならない。ここで求められるのは、単なる色付けではなく、「どこから読むべきか」「なぜこう変えたのか」「どこを直させたいか」を素早く判断できるレビュー環境だ。変更ファイルの一覧、AIの意図が添えられたインラインコメント、指摘をその場に残せる仕組み——hunkが備えるこれらは、いずれも「大量の他人（AI）の差分を高速に捌く」ための道具立てになっている。
もう一つの背景が、ターミナルへの回帰だ。AIエージェントの多くはCLIとして動き、開発者はエージェントと同じターミナルの中で作業する。差分レビューのためだけにブラウザのGitHub UIへ切り替えるのは、コンテキストスイッチのコストが高い。hunkが「ターミナルの中で完結するレビューUI」を選んだのは、この作業導線に素直に乗るためだ。「diffは読めればいい」から「diffはレビューする対象だ」へ——hunkの設計は、その認識の転換を体現している。
画面構成と基本操作——split・stack・サイドバーで差分をレビュー
hunkの画面は大きく3つの要素で構成される。左のサイドバー、中央の差分ビュー、そして差分の横に並ぶインラインコメントだ。まずは公式READMEの実スクリーンショットで、実際の見た目を確認しよう。
サイドバーによるマルチファイル・レビューストリーム が、レビュー体験の土台だ。変更されたファイルが一覧で並び、各ファイルの変更行数（追加/削除のカウント）が見える。ファイル間をキーボードやマウスでジャンプし、changeset全体を「上から下まで」レビューしていける。単一の巨大なdiff出力をスクロールするのと違い、「今どのファイルのどこを見ているか」を常に把握できるのが強みだ。
split・stack・auto の3レイアウト
hunkはターミナルの横幅に応じてレイアウトを切り替えられる。左右に並べる split、上下に積む stack、そして端末幅から自動選択する auto の3モードだ。狭い縦長のターミナルではstack、広いワイド画面ではsplit、というように環境に合わせて最適化できる。実行中にレイアウトを切り替えたり、行の折り返し（wrap）や行番号の表示をトグルしたりできるのも、レビュー作業を止めない配慮だ。
操作はキーボードとマウスの両対応だ。フルキーボードで駆動しつつ、メニューをマウスで選ぶこともできる。テーマはtキー、またはメニューのView -> Themes…から選択でき、github-dark-defaultをはじめとする複数の組み込みテーマや、自作テーマの読み込みにも対応する。以下のように設定ファイルへ好みを永続化できる。
# ~/.config/hunk/config.toml もしくは .hunk/config.toml
theme = "github-dark-default" # 組み込みテーマID / auto / custom
mode = "auto" # auto / split / stack
vcs = "git" # git / jj / sl
watch = false
line_numbers = true
wrap_lines = false
agent_notes = false
theme = "auto" にすると、起動時にターミナルの背景色を問い合わせ、明るい背景なら github-light-default、暗い背景なら github-dark-default を自動選択する。応答がない端末では暗テーマにフォールバックする。インストールと最初の diff レビュー——Git・Jujutsu・Sapling 対応
導入は驚くほど簡単だ。npmかHomebrewで1コマンド、Node.js 18以上があれば動く。
# npm でグローバルインストール
npm i -g hunkdiff
# もしくは Homebrew
brew install hunk
# 動作確認
hunk --version
インストールが終わったら、hunkのコマンド体系がGitのdiff系コマンドを踏襲していることを押さえておくとよい。hunk diffはgit diffに、hunk showはgit showに対応する——ただし出力はプレーンテキストではなくレビューUIで開く、というのがポイントだ。
hunk diff # 作業ツリーの変更をレビュー（未追跡ファイルも含む）
hunk diff --watch # 作業ツリーが変わるたび自動リロード
hunk show # 直近コミットをレビュー
hunk show HEAD~1 # 1つ前のコミットをレビュー
hunk diff before.ts after.ts # 2ファイルを直接比較
git diff --no-color | hunk patch - # stdinのパッチをレビュー
特に強力なのが --watch モードだ。作業ツリーの変更を監視し、ファイルが変わるたびに自動でリロードする。エージェントが別のペインでコードを編集している間、hunkを開きっぱなしにしておけば、差分がライブで更新されていく。これはAIエージェントとの協調作業を前提にした設計であり、後述する双方向レビューの土台にもなる。
Git・Jujutsu・Sapling を自動検出
hunkのバージョン管理システム対応は幅広い。デフォルトはGitだが、Jujutsu（jj） と Sapling（sl） のチェックアウトを自動検出し、それぞれのネイティブなrevset記法でhunk diff [revset]やhunk show [revset]が使える。検出結果を上書きしたい場合は、設定でvcs = "git" / "jj" / "sl"を明示すればよい。
さらにhunkを各VCSのページャとして登録することもできる。Gitなら次の1行で、git diffやgit showが自動的にhunkで開くようになる。
# hunk を Git のページャに設定
git config --global core.pager "hunk pager"
# ~/.gitconfig に直接書く場合
[core]
pager = hunk pager
Gitのデフォルトページャを残したい場合は、git hdiff・git hshowのようなオプトインのエイリアスを追加する方法も用意されている。JujutsuやSaplingにも同様のページャ統合手順があり、既存のワークフローを壊さずに段階的に導入できるのが親切な点だ。
AIエージェントとの双方向レビュー——hunk の本命機能
ここからがhunkの真骨頂であり、他のdiffツールとの決定的な差別化ポイントだ。hunkは単に「人間がAIの差分を読む」だけでなく、AIエージェントと人間が同じライブセッションを往復してレビューを進めることを想定して作られている。仕組みそのものは拍子抜けするほどシンプルで、「スキルファイルをエージェントに読ませるだけ」だ。
# エージェントへの汎用プロンプト（README掲載）
Load the Hunk skill and use it for this review.
Run `hunk skill path` to get the skill path.
流れはこうだ。まず別のターミナルでhunk diffまたはhunk showを開いてレビューセッションを立ち上げる。次にhunk skill pathが返すスキルファイル（skills/hunk-review/SKILL.md）をエージェントに読み込ませる。あとは「このスキルを使ってレビューして」と頼むだけで、エージェントはライブセッションを検査・操作できるようになる。この往復の全体像を、まずサイクル図で掴んでおこう。
AI → 人間：エージェントが差分にコメントを注入し、画面を誘導する
スキルを読んだエージェントは、hunk session系のサブコマンドを通じて、あなたが今見ているまさにその画面に働きかけられる。まずセッションの状態を検査する。
hunk session review --repo . --json # 変更ファイルとhunk構造をJSONで取得
そのうえで、特定の差分行にコメントを注入したり、人間の視点を目的の箇所へ誘導したりする。次のコマンドは、README.mdの103行目に「この表現を締めよう」というコメントを追加する例だ。
# 差分の横に単一コメントを追加
hunk session comment add --repo . --file README.md --new-line 103 \
--summary "Tighten this wording"
# 人間の画面を特定ファイル・特定hunkへジャンプさせる
hunk session navigate --repo . --file src/App.tsx --hunk 2
hunk session navigate --repo . --next-comment
複数のコメントをまとめて適用したい場合は、comment apply --stdinにJSONを流し込む。エージェントが自分の指摘を構造化して一括投入できるため、レビュー観点を漏れなく差分の横に並べられる。AIの推論が「差分の中」に留まり、別のチャット履歴を遡らなくてよくなるのがこの機能の本質だ。
人間 → AI：c キーで残したメモをエージェントが回収する
双方向の「もう半分」がこれだ。人間はhunkの画面上でcキーを押してインラインメモを残せる。「この関数は分割して」「命名がわかりにくい」といった指摘をその場で差分に貼り付ける感覚だ。そしてエージェント側は、人間が残したメモを次のコマンドで回収できる。
hunk session comment list --type user # 人間が残したメモだけを列挙
エージェントはこの一覧を読み、指摘を実装へ反映し、必要ならクリーンアップとして人間のメモを一括削除することもできる。ただしエージェントは人間名義のメモを「新規作成」したり「編集」したりはできない——あくまで人間の指摘は人間のもの、という役割分担が保たれている。この非対称性が、レビューの信頼性を担保している。
この往復を、時系列のシーケンス図で整理すると次のようになる。人間・hunkセッション・エージェントの3者が、同じ差分を介してやり取りしている構図が見えてくる。
hunk session list（アクティブなウィンドウ一覧）や hunk session get --repo . で確認する。複数リポジトリでhunkを開いていると、意図しないセッションを操作してしまう恐れがあるため、--repo の指定を徹底したい。セッションモデルとリロード——「ライブな1枚の画面」を共有する
この双方向レビューを支えているのが、hunkの「セッション」という概念だ。hunk diffで開いた画面は、単なる静的な表示ではなく、外から検査・操作できるライブなセッションとして存在する。エージェントはhunk session listでアクティブなウィンドウを一覧し、hunk session get --repo .で自分が操作すべきセッションを特定する。そのうえでhunk session contextやhunk session review --jsonでファイル・hunk構造を把握し、コメントやナビゲーションを差し込む——という流れだ。
レビューが進んで差分の中身自体が変わったときは、hunk session reload --repo . -- diffでセッションの内容を丸ごと差し替えられる。エージェントが指摘を実装し、作業ツリーが更新されたら、リロードで最新の差分に切り替えて次のレビューへ進む。comment clearでコメントを一括整理する、comment rm <id>で個別に消す、といった細かな操作も用意されている。「人間とAIが、同じ1枚のライブな画面を見ながら、コメントで会話する」——この体験が、hunkが他のdiffツールと一線を画す理由だ。
より作り込んだ運用をしたい場合は、--agent-contextを使ってエージェントに渡すコンテキストをファイルで管理する方法や、公式のdocs/agent-workflows.mdにある詳細なワークフローガイドが参考になる。hunkはhunkdiff/opentuiとしてHunkDiffViewなどのコンポーネントも公開しており、同じ差分レンダラを自作のOpenTUIアプリに組み込むこともできる。単体ツールとしてだけでなく、レビュー体験を部品として再利用できる設計になっているわけだ。
なお、Claude Codeを使っている場合は、この「スキルファイルを読ませる」手順がそのままClaude Skills（スキル）機能の完全解説の使い方に一致する。hunkのSKILL.mdは、Claude Codeのスキル読み込みの仕組みにきれいに乗る形で設計されている。エージェントに「使えるコマンドの説明書」を渡すという発想は、MCPやツール定義と同じく、AIエージェントを外部システムに接続する標準的なパターンだ。
delta・difftastic・difit との比較——hunk の立ち位置
「diffツールならもうdeltaを使っている」という人は多い。ではhunkは何が違うのか。結論から言うと、delta・difftasticは「読みやすく表示するページャ」、hunkは「レビューするためのUI」、difitは「ブラウザで開くレビューツール」という住み分けになる。それぞれの一次情報をもとに整理したのが次の表だ。
| 観点 | hunk | difit | delta | difftastic |
|---|---|---|---|---|
| 種別 | ターミナルTUI | ローカルWebサーバ＋ブラウザ | ページャ（表示） | 構造的diff（表示） |
| レビュー専用UI | ✅ サイドバー＋split/stack | ✅ GitHub風UI | ❌ | ❌ |
| インラインAIコメント | ✅ 差分の横に注入 | ✅ コメントをプリロード | ❌ | ❌ |
| 人間の指摘をAIへ渡す | ✅ cメモをAIが回収 |
✅ Copy Promptで渡す | ❌ | ❌ |
| 双方向（AIが画面を操作） | ✅ navigate/reloadで誘導 | ❌ | ❌ | ❌ |
| 構文ハイライト | ✅ | ✅ | ✅ | ✅ |
| 構造的（構文木）diff | ❌ | ❌ | ❌ | ✅ |
| VCS対応 | Git/jj/sl 自動検出 | Git（PR/コミット比較） | Git | Git |
| 動作環境 | ターミナル完結 | ブラウザで表示 | ターミナル完結 | ターミナル完結 |
delta はdandavison氏の定番ページャで、構文ハイライトと美しい行内diffが強み。difftastic はWilfred氏の構造的diffツールで、構文木を比較するため「フォーマットだけの変更」を賢く無視できる。どちらも「差分をどう表示するか」に特化しており、レビュー行為やAI連携は守備範囲外だ。
difit（yoshiko-pg氏）はhunkに最も近い思想を持つが、実装アプローチが異なる。difitはローカルにWebサーバを立ててブラウザでGitHub風のUIを表示し、「difit-review」スキルでエージェントが指摘をコメントとしてプリロードできる。「Copy Prompt」ボタンで人間のコメントをAIエージェント向けに整形して渡せる点も似ている。違いは、hunkがターミナル内で完結し、AIが画面そのものをnavigateで操作できる（人間の視点を誘導できる）点だ。ブラウザに切り替えたくないターミナル派にはhunk、GitHub風のリッチなUIを好むならdifit、という選び方になる。
AIコーディングでレビューが追いつかない構造的な理由はハーネスエンジニアリング入門でも触れているとおりで、hunkやdifitは「エージェントの出力を人間が捌く」ためのハーネスの一部として位置づけられる。
hunk を選ぶべきでないケース
公平を期すために、hunkが最適でない場面も挙げておく。まず、deltaをGitのページャとして既に使い込んでいて、レビューは「差分をきれいに読めれば十分」という人には、hunkはオーバースペックかもしれない。deltaは設定も軽く、既存のgitコマンドに透過的に差し込めるため、AI連携を必要としないなら乗り換える理由は薄い。次に、「フォーマット変更を無視して意味のある差分だけ見たい」というニーズが強いなら、構文木ベースのdifftasticのほうが噛み合う。hunkは行/hunk単位のdiffであり、構造的diffではないからだ。
また、チーム全体で非同期にレビューを回し、コメント履歴をPRに残したいワークフローなら、GitHubやGitLabのPRレビュー、あるいはブラウザUIを持つdifitのほうが向く。hunkの双方向レビューは「今まさに開いているライブセッション」を前提とするため、レビュー記録の永続化や複数人での並行レビューは主戦場ではない。hunkが最も輝くのは、1人の開発者が1体（あるいは複数）のエージェントと、ターミナルの中でリアルタイムに差分をやり取りする局面だ。ツールは「何ができるか」だけでなく「どの作業導線に乗るか」で選ぶと失敗しにくい。
導入時の注意点と Claude Code 連携の運用例
最後に、実際に使う前に知っておきたいv0.17.0時点の制限と、Claude Codeと組み合わせる運用例をまとめる。良いツールほど、限界を理解して使うと化ける。
・コメントは1行またはhunk単位が基本で、複数行にまたがるコメントは想定外。
・エージェントは人間のメモを読む・消すはできるが、人間名義のメモを新規作成・編集はできない。
・
hunk pager経由でgit diffを開くと、未追跡ファイルはGitの挙動に従うため表示されない（hunk自身のhunk diffなら含まれる）。・ターミナルの絵文字幅やNerd Fontの扱いは端末依存になり得る。
これらは「レビューのためのTUI」という若いプロダクトの現状であり、開発は活発だ（2026年3月公開、v0.17.0は7月リリース）。特に複数行コメントは、レビューで「この関数全体について」と言いたい場面が多いため、今後の改善に期待したいポイントだ。
Claude Code との運用例
Claude Codeと組み合わせる場合、次のような分業が現実的だ。エージェントにコードを書かせながら、人間はhunkでその差分をライブレビューする。
# ペイン1：作業ツリーの変更をライブでレビュー
hunk diff --watch
# ペイン2：Claude Code にコードを書かせつつ、レビュー用スキルを読ませる
# → Claude に「hunk skill path のスキルを読んで、この変更をレビューして」と依頼
運用のコツは3つある。まず、--watchで開きっぱなしにして、エージェントの編集が差分に反映される様子を常に見ておくこと。次に、気になった箇所はcキーでその場にメモを残し、口頭やチャットではなく差分に指摘を紐付けること。最後に、エージェントにはcomment list --type userで自分のメモを回収させ、指摘を実装へ反映させる——この往復をリズムにすると、レビューが「読むだけの作業」から「対話」に変わる。
- ・Claude CodeやCodexが生成した大きめの差分を、毎日ターミナルでレビューしている。
- ・レビューの指摘をチャットに書くのではなく、差分そのものに紐付けたい。
- ・ブラウザやGUIに切り替えず、ターミナル内で作業を完結させたい。
- ・Jujutsu・Saplingなど、Git以外のVCSも使っている。
diffツールは長らく「表示」で競ってきた。hunkはそこに「レビュー」と「AIとの往復」という新しい軸を持ち込んだ。エージェントがコードを書く量が増えるほど、レビューの質と速度がボトルネックになる。hunkは、そのボトルネックをターミナルの中で溶かしにいく、AI時代らしい設計のツールだ。まずはnpm i -g hunkdiffとhunk diffから、5分で体験してみてほしい。
まとめ
hunk（modem-dev/hunk）は、AIエージェントが書いた差分を「レビューファースト」で捌くためのターミナルdiffビューアだ。サイドバーで全ファイルを一望し、split/stackで柔軟にレイアウトし、AIのコメントを差分の横に置く。そして最大の特徴は、エージェントがコメントを注入し画面を誘導し、人間がcキーで残したメモをエージェントが回収する双方向レビューにある。delta・difftasticが「表示」で止まるのに対し、hunkは「レビューと対話」まで踏み込む。Git・Jujutsu・Saplingを自動検出し、npm i -g hunkdiffで今すぐ試せる。AIにコードを書かせる時代の「レビューの相棒」として、ターミナル派なら一度触れておく価値がある。
参照ソース
・modem-dev/hunk — GitHub リポジトリ（README・機能比較表・設定）
・hunk — Agent workflows ドキュメント（session/comment/navigate コマンド）
・hunk — hunk-review SKILL.md（エージェント用スキル定義）
・hunk 公式サイト（hunk.dev）
・hunk v0.17.0 リリース（GitHub Releases）
・yoshiko-pg/difit — 比較対象のローカルレビューツール
・YouTube — “Hunk changed the way I write and review code with my agent”（実演動画）
