Task-viewが照合するのは、説明に出てくるファイル・行・コミットなどとGitの実物です。変更理由の正しさ、業務仕様との一致、テストの実行結果は別に確認します。今回の試用では、誤った変更理由を書いても検査は通りました。
AIに修正を頼んだら、複数のファイルが一度に変わった。差分は読めても、入力から処理、テストまでのつながりを頭の中で組み立て直すのが大変——。そんなレビューの入口を助けるのが、オープンソースのTask-viewです。
初回のリリースv1.0.0は2026年10月23日22:17:33 UTC（日本時間24日7:17:33）、本稿で試したv1.0.1は同日23:00:10 UTC（日本時間24日8:00:10）に公開されました。GitHubのリリースAPIで時刻を確認し、公開当日の夕方に試用しています。リポジトリの作成日時や検索結果の掲載日を、公開日時の代わりにはしていません。
AIが変更を説明し、ツールが実物と照合する
Task-view自体がコードを読んで修正理由を推論するわけではありません。まず、作業をしたAIエージェントがJSON形式の「変更説明ファイル」を作ります。変更した部品、参照先の行、部品同士の関係、変更理由を記述し、それをTask-viewが読み取ってHTMLにします。公式ガイドでは、このHTMLを一つのファイルとしてオフラインで閲覧できると説明しています。
| 表示 | 何を見るか |
|---|---|
| Graph | 関数やテストなどの関係。部品を選ぶとコードや変更理由を確認できる |
| Flows | 説明ファイルに記述した処理の流れを順番に読む |
| Diff map | 実際に変わった行のうち、どこに説明が付き、どこが漏れたかを確認する |
| Claims | 説明ファイル内の主張と、添えられた参照を確認する |
コードの構文を解析して呼び出し関係を自動復元する仕組みではなく、ファイル・行範囲・差分を使います。したがって、線が引かれていても、それだけで実行時の関係が正しいとは限りません。図はレビューの案内図として使い、重要な箇所は実装まで読みます。
導入条件：GitがあるPCで動く、無料のCLI
| 項目 | v1.0.1で確認した条件 |
|---|---|
| 配布 | macOSのApple silicon／Intel、LinuxのARM64／x86-64、Windowsのx86-64向けバイナリ |
| 実行時の前提 | GitがPATHにあること。CLI操作とGitの基本知識が必要 |
| 料金・ライセンス | MITライセンスのソフトウェア。Task-viewの利用に従量API料金は不要 |
| AI側の費用 | 説明ファイルを作るエージェントの契約・推論費用は別 |
| 日本語 | 今回、日本語の概要・部品名・変更理由の表示を確認。画面の操作名は英語 |
| 通信・共有 | 生成HTMLはオフライン閲覧用。クラウドAIに説明を作らせる場合の送信は、そのAI側の設定に従う |
配布物と条件はリリースページ、ライセンスを確認してください。ローカルでHTMLを開けることは、AIエージェントへのコード送信まで自動でなくなるという意味ではありません。またHTMLにはコードや説明が入るため、社内コードから生成したページをそのまま公開しないでください。
試して分かった「通るもの」と「止まるもの」
編集部では2026年10月24日、Apple siliconのMacでv1.0.1のdarwin-arm64バイナリを試しました。公式SHA256SUMSとの一致を確認し、既存の開発環境に常駐設定を加えず、一時フォルダー内の架空のGitリポジトリだけを対象にしています。モデルの性能評価ではなく、製品の照合機能の実測です。
教材は「単価×個数」を計算するPython関数です。負の個数を拒否する処理とテストを追加し、その変更をコミットしました。説明ファイルは編集部が作成しています。自律エージェントが説明を書き上げる成功率や、大規模な実案件での時短効果は測っていません。
def total(price, count): if count < 0: raise ValueError("count must be nonnegative") return price * count| 試した説明 | 実際の結果 | 読み方 |
|---|---|---|
| 関数・テスト・参照行が一致 | 終了コード0、エラー0、警告0 | 日本語の図と変更行マップを表示できた |
| 4行の関数を「1〜999行」と記述 | 終了コード1。range_out_of_bounds | 存在しない行範囲は検出された |
| 追加したテストの説明を省略 | 終了コード0。ただしunmentioned_hunk警告 | 終了コードだけを見ると説明漏れを見逃す |
| 理由だけを「銀行の残高も検証する」に変更 | 終了コード0、エラー0、警告0 | 理由の文章の真偽は検査されない |
正常な説明では、画面に3 verifiedと4 agent statementsが表示されました。関数とテストの参照、テストから関数への参照箇所が照合される一方、理由やテスト結果などは説明者の申告として区別されています。関数のテストそのものは編集部が別途python3で実行し、通常の注文と負の個数の拒否を確認しました。Task-viewがテストを実行したわけではありません。
とくに説明漏れのケースは重要です。終了コードの公式定義でも、0は警告を許容します。レビューの完了条件を決めるなら「0だから終了」ではなく、warnings内のunmentioned_hunkが残っていないか、残っているなら何の変更かを確認します。
まず一つの変更だけで導入する手順
- 1公式v1.0.1リリースからOSとCPUに合う実行ファイル、SHA256SUMSを取得する。ファイルのハッシュと該当行を照合する。
- 2専用フォルダーに配置して実行権限を設定し、versionで版を確認する。macOSなどで実行が阻止されたら、組織のソフトウェア導入手順に従う。
- 3対象リポジトリでtask-view instructionsを読み、AIに一つの変更について説明JSONを作らせる。最初から全リポジトリ共通の設定にしなくてもよい。
- 4validateを実行してerrorsとwarningsを読む。指摘があれば参照先や説明範囲を直す。
- 5openで図を生成し、説明漏れ→重要な処理→テストの順に確認する。コードを追加修正したら説明と図も作り直す。
./task-view-darwin-arm64 version./task-view-darwin-arm64 instructions次のコマンドは、実行ファイルをtask-viewという名前でPATHに配置した後の例です。対象リポジトリ内に.review/change-example.jsonが必要です。公式の自動インストーラーはPATH設定なども変更するため、初回は手動導入の説明を読み、会社のPCなら管理ルールと合わせて選んでください。
task-view validate .review/change-example.json --format jsontask-view open .review/change-example.json --no-browser --out review.html生成されたreview.htmlをブラウザーで開きます。Graphでテストが見えない場合はTests表示を有効にします。今回の初期画面ではテストの表示がオフで、関数だけが見えていました。Diff mapに切り替えると、変更した2ファイルと説明の対応を確認できました。
そのまま渡せる、日本語の依頼文
このリポジトリの直近の修正について、Task-viewの変更説明ファイルを作ってください。まずインストール済みのtask-view instructionsとtask-view schemaを読み、版に合う形式を確認してください。
対象は私が指定したコミットだけです。レビューのためにコードを変更したり、新しいコミットを作ったりしないでください。変更した関数・設定・テストを、実在するファイルと行に結び付けて説明してください。日本語の概要と変更理由を付けてください。関係を裏付ける行が分からないときは推測せず、参照なしとして明示してください。
validateのerrorsとwarningsを両方読み、unmentioned_hunkが残る場合は何が説明されていないか報告してください。テスト結果は今回実際に実行して確認したものだけを書き、未実行はnot runにしてください。実行したコマンドと結果の記録も別途示してください。最終的な正しさやマージ可否の判断は行わず、review.htmlと未確認事項を渡してください。依頼文中の「指定したコミット」は、実際の完全なコミットIDに置き換えます。未コミットの変更を含める場合は、公式形式のWORKTREEを使うなど、どの状態を説明するかを明示します。古い行番号のまま図だけを残すと、その後の修正と食い違います。説明ファイルの仕様も版をそろえて確認してください。
小さなチームで価値が出やすい使いどころ
| 用途案 | 最初に試す範囲 | 人が確かめること |
|---|---|---|
| 複数ファイルにまたがる修正 | 入力検証とエラー表示など、一つの変更 | 入力がどの処理を通り、どこで拒否されるか |
| AI作業の引き継ぎ | 担当交代前の1コミット | 未説明の変更と未実行テストが残っていないか |
| レビューの教育 | 新人と熟練者が同じ小さな差分を見る | 説明から実コードへ移り、主張を自分で確かめられるか |
上の用途は導入案で、採用企業の成果ではありません。試すときは「図を作る時間」「人が確認する時間」「図に載らなかった変更」「理由と実装の食い違い」を記録します。図の作成にも時間やAI利用料がかかるため、短い修正では通常の差分表示だけの方が扱いやすい場合もあります。
Task-viewは、コードを読む順番を整理する道具として検討できます。自動レビューを組み合わせる場合はClaude Code Reviewの記事、不要な変更を減らす観点はDeslopの記事も参考になります。いずれも、説明・機械的な検査・実際の動作確認を分けて扱うことが大切です。