deltoids - Agent が変更した diff に十分な文脈を戻す
Code review でつらいのは、赤と緑の行が多いことだけではありません。その変更がどの function、どの test、どの config block の中にあるのか分からないことです。AI coding agent が入ると、この問題はさらに目立ちます。Agent は一度に十数 file を変えることがあり、通常の git diff の 3 行 context だけでは、reviewer は何度も editor に戻って function boundary を探すことになります。
今日紹介する juanibiapina/deltoids は、この小さく見えるが重要な隙間を扱う tool です。Rust で書かれた diff filter、review TUI、agent edit trace toolkit です。GitHub search result では現在およそ 20 stars、1 fork。主な言語は Rust、license は MIT です。Repository は今も高頻度に更新されており、Cargo.toml の workspace version は 0.8.1。CHANGELOG.md では 0.8.1 が 2026 年 5 月 27 日に出ています。Tag 一覧でも v0.8.1 を確認できます。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | juanibiapina/deltoids |
| 位置づけ | Agentic coding 向けの diff pager、review TUI、edit trace tool |
| Stars | 約 20 |
| Forks | 1 |
| 主な言語 | Rust |
| ライセンス | MIT |
| Current version | 0.8.1 |
| Install | Homebrew、shell installer、cargo install --git |
Diff の orientation 問題を扱う
Unified diff は machine-readable で、小さな変更を見るには十分便利です。ただし変更が 150 行の function の真ん中にあると、default context だけでは足りません。数行の変更は見えますが、それがどの handler、どの test case、どの Terraform block に属するのかは分かりません。結局 editor に戻ることになります。
deltoids の中心は、context を固定行数だけで決めないことです。Tree-sitter を使って変更位置の code structure を見つけ、hunk を関連する context まで広げます。README では、通常は enclosing function や struct まで、最大 200 行程度まで広げると説明されています。Pager の中で「この変更はどこにあるのか」を見られるわけです。
これは派手な機能ではありませんが、review にはかなり効きます。AI agent の失敗は、単なる syntax error だけではありません。変更が間違った layer に入る、隣の branch を見落とす、test case の意図を変えてしまう。Function-level context があると、reviewer は変更範囲が本当に妥当かを早く判断できます。
Git pager として使える
一番直接的な使い方は、unified diff を deltoids に pipe することです。
git diff | deltoids | less -R
git show HEAD~1 | deltoids | less -R
git log -p | deltoids | less -R
Git pager として設定することもできます。
git config --global core.pager 'deltoids | less -R'
README には lazygit の設定例もあります。Terminal で diff を読む習慣がある人にとって、導入の friction は低いです。Git workflow を置き換えるのではなく、diff output に context を足す tool と見れば分かりやすいです。
deltoids review も用意されています。これは ANSI diff をそのまま流すだけではなく、scroll できる TUI として local diff を読む subcommand です。CHANGELOG.md には review TUI や trace TUI の mouse support、pane title の調整などが並んでいて、algorithm だけでなく terminal interaction も継続的に調整されています。
AI agent workflow に向いている理由
deltoids は MCP server ではなく、coding agent そのものでもありません。それでも README を読むと、かなり agent workflow を意識して設計されています。Tool 一覧には次のものがあります。
deltoids pager:lessやcore.pager向けの ANSI diff filter。deltoids review: Diff を読むための TUI。deltoids edit/deltoids write: Coding agent から呼ぶ file edit / write tool。deltoids hashread/deltoids hashedit: line-content hash anchor 付きの read / edit tool。deltoids traces: Agent edit trace を real-time に browse する tool。
特に面白いのは trace です。edit と write は agent tool の CLI version として動き、各変更に reason を記録できます。その後 deltoids traces で、agent UI とは別に変更の流れを見られます。Reviewer が最終 diff だけでなく、「agent がどういう順番で何を変えたか」を見られるのは実用的です。
Claude Code integration もあります。Plugin は Write と Edit call を記録し、Claude session ごとに group 化します。同じ session を continue すると、同じ trace に append されます。Claude Code の UI を置き換えるものではありませんが、local review のための独立した記録になります。
Hash anchor という実務的な細部
AI agent の text edit でよくある問題は、位置ずれです。Agent が最初に 42 行目を読んだとしても、そのあと別の操作で file が変われば、42 行目はもう同じ内容ではないかもしれません。Edit tool が line number だけを信じると、間違った場所に変更を入れる可能性があります。
deltoids の hashread / hashedit は、この問題を小さくしようとします。hashread は LINEhh のような anchor を出力します。これは line number と短い content hash を組み合わせたものです。hashedit は実際に patch を splicing する前に anchor を検証します。Anchor が stale なら、batch 全体を拒否します。
これは完全な concurrency control ではありません。ただし agent tool layer ではかなり現実的です。「さっき読んだ text に基づいて編集する」という行為を、line number だけではなく内容でも確認できます。
境界: まだ active development
README の冒頭には warning があります。Project は active development 中で、diff output にはまだ問題が残る可能性があるため、疑わしいときは別の pager でも確認するように、という内容です。この点は使う前にきちんと読むべきです。
そのため、私は deltoids を audit chain の唯一の source of truth にはしません。より正確には、review experience を強くする tool です。Function-level context を素早く見て、agent trace を確認し、怪しい場所を見つける。最終確認は git diff、test、build、人間の判断で行うべきです。
また、tree-sitter による language structure の理解に依存します。Repository には Rust、TypeScript、JavaScript、Python、Go、C/C++、Java、Ruby、Lua、Bash、JSON、YAML、TOML、HCL、CSS、Markdown などの grammar が入っていますが、各 language の boundary には細部の差があります。複雑な syntax や generated code では、二重確認を残すほうが安全です。
向いている人
deltoids は次のような場面に向いています。
- Terminal で
git diff、git show、git log -pをよく読む。 - Diff に function、structure、test case、config block の context が欲しい。
- AI agent に multi-file change を任せることがあり、各 edit を後から追いたい。
- Claude Code や pi など、plugin / tool integration がある agent workflow を使っている。
- Active development 中の小さな tool として受け入れ、重要な review では別 pager も使える。
主な review 場所が GitHub PR page だけの場合や、team が IDE 内蔵 review に強く寄っている場合、価値はやや小さくなります。Terminal-first、agent-heavy、local diff を速く理解したい workflow で光る tool です。
まとめ
juanibiapina/deltoids の良さは、「AI が自動で review する」ことではありません。Human reviewer が足りない context を取り戻すことです。Tree-sitter で diff hunk を enclosing function や structure まで広げ、edit/write/hashread/hashedit/traces で agent の変更過程を見やすい形に残します。
Git を置き換えるのではなく、agent が変更した code を人間が読みやすくする。この控えめな位置づけが良いと思います。AI coding workflow では、もう一つの万能 agent よりも、こういう狭く正確な review support tool のほうが実際に役立つ場面があります。