Whiteboardに設計図を描かせると、AIのPRレビューは楽になるか。

AIエージェントが出してきた大きなPRを上から読んでいって、途中で集中が切れたまま承認したこと、ありませんか？ dev.fastが公開したOSSのWhiteboardは、エージェントに設計図を描かせて図からコードへ飛べるようにし、AIのコードレビューを軽くしようとしています。ただ「レビューが楽になった」という数字は公式にもHacker Newsにもまだないので、自分のリポジトリで確かめる手順まで組みました。

GitHub - devdotfast/whiteboard: open-source canvas for thoughtful software design

open-source canvas for thoughtful software design. Contribute to devdotfast/whiteboard development by creating an account on GitHub.

github.com

10月1日時点でスターは2,480、ライセンスはMIT、最新版は9月28日のv0.1.5です。Code OSSを取り込んだデスクトップアプリで、Claude Code、Codex、Copilot CLIなどとつないで使います。更新が速いので、以下は執筆時点の情報です。

AIのPRレビューで、手が止まるのはどこですか？

止まる場面は、だいたい決まっています。追加された長い関数を前に読む気が失せる。テストとドキュメントの差分に挟まれて、本題の変更を見失う。そして差分をいくら読んでも、なぜこの実装になったのかがわからない。

創業者たちもShow HNの投稿で、エージェントが書いたコードを自分が理解できなくなる「認知負債」を開発の動機に挙げていました。

右端の列は、どれも作り手の説明です。あなたのレビューで一番時間を食っているのは、この4行のどれでしょうか？ そこが、あとで測るときの的になります。

Whiteboardへの反論は、HNでほぼ出そろっている

9月24日のShow HNは423ポイントを集め、試す前に気になる疑問がコメント欄にひととおり並びました。決着したものと、していないものがあります。

図は、コードからずれていかないのか？

「図もそのうちコードからずれていく、厄介なものがまた1つ増えるだけでは」という指摘に、創業者は「図は設計上コードに紐づいているので、ずれれば検知できる」と返しています。一方で開発チームの別のメンバーは、図は古くなる短命なもので、長く残るのは自分の理解のほうだと書いていました。

僕はこれを、図はレビューのその場で読み捨てる道具だという意味に読んでいます。全体の地図を最新に保つ仕組みは、ホスト版の構想として語られている段階です。

デモの図が差分と合っていなかった件

READMEのデモGIFで、差分にない処理が図にだけ描かれていると指摘されました。創業者はデザイン用の架空の図だったと認め、実際の図はコードに紐づくのでハルシネーションは実務ではほぼ起きない、と答えています。これは作り手の主張なので、図の処理が本当に差分にあるかは自分で数える項目に入れておきます。

MermaidやLikeC4で足りるのでは、という声

MermaidとMarkdownで十分では、という質問に開発チームが挙げた違いは、図のノードを押すと裏のコードが開くことと、差分をガイド付きで順に追えることでした。ところがLikeC4を推すユーザーからは「LikeC4にも対話的な図とガイド付きの説明はある。コード表示を足すのは機能1つ分の話では」と再反論が入り、話は決着していません。

図をテキストで管理していて困っていないなら、急いで乗り換える理由は薄いと僕は見ています。

Whiteboardはローカルで動くのに、テレメトリは既定でオン

Codexで使おうとしたユーザーが「Whiteboardはリポジトリのデータをauthoring serverに送る必要がある」という警告を見た、と書き込んでいます。開発チームの説明では、これは手元で動くstdioのMCPサーバーのことで、外には出ないそうです。

とはいえ、外に出るものがゼロなわけではありません。docs/telemetry.mdとdocs/privacy.mdに書かれた既定はこうです。

• 匿名の利用統計（テレメトリ）は既定でオン。コード、差分、ファイルパス、リポジトリ名は含まないと明記されている
• バグ報告は、送信を押せばテレメトリがオフでも送られる。セッションの記録、変更ファイルの差分行、スクリーンショットが既定で添付対象（送る前に外せる）
• クラッシュ時のダンプは開いていたソースを含むことがあり、テレメトリがオンなら次の起動時に送られて30日保管される。オフなら送らずに削除
• whiteboard share は本文、画像、コミット、GitHubのログイン名、クローンURLを共有サービスに上げる。ソースコード自体は含まない

切るなら、アプリの Preferences → Settings で「Share anonymous usage data」をオフにするのが確実で、アプリと whiteboard CLIの両方に効きます。環境変数の DO_NOT_TRACK=1 は1回のコマンドやシェル、ヘッドレス環境向けです。ここ、マジで勘違いしやすいのですが、DEV_FAST_REVIEW_TELEMETRY_DISABLED だけはアプリが自分の設定で上書きするので、シェルで設定してもアプリ側は止まりません。

残りの指摘は、事実として受け止めれば済む話でした。編集できないのに「IDE」と名乗っていた点は、公開直後にサイトとGitHubの表記を「canvas」に改めています。macOS版の736MBが重いという声には、いずれネイティブで書き直すと答えました。Windows版とUbuntu向けパッケージは、HN公開の2日後に追加されています。

READMEが既知の制約に挙げているのは、アプリ内でファイルを編集できないこと、複数リポジトリにまたがる1つのレビューは十分に扱えないこと、共有したレビューには共有後の更新が反映されず再共有が要ること、の3点です。

git diffとWhiteboard、どちらで読むと速いかを測る

Claude CodeとCodexへの入れ方

アプリはGitHubのReleasesからmacOS、Windows、Linux向けを直接ダウンロードできます。公式の手順では、起動後のウェルカム画面からClaude CodeやCodexを接続します。コマンドでプラグインを入れるなら、プルリクエスト#576に残っている次の手順です。

# Claude Code
claude plugin marketplace add devdotfast/whiteboard
claude plugin install whiteboard@devfast --scope user

# Codex
codex plugin marketplace add devdotfast/whiteboard
codex plugin add whiteboard@devfast

つないだら、クイックスタートの例文どおり「今のブランチを最新のmainと比べてレビューして、結果をWhiteboardで開いて」とエージェントに頼みます。READMEは推奨モデルにGPT-6 SolとClaude Opus 5.5を挙げているので、比べている間はモデルを1つに固定しておきます。

比べる項目と、外しておくPR

同じPRを2回読むと、2回目は中身を知っているぶん速くなってしまいます。規模の近いAI生成のPRを2本用意し、1本はgit diffだけで、もう1本はWhiteboardを開いてからレビューします。

数行の修正は図を開く手間のほうが大きいので、最初から外します。複数リポジトリにまたがる変更も、既知の制約に入っているので対象外です。

あなたのチームで今週いちばん大きかったAIのPRは、どれでしたか？ それが1本目の候補です。

試すなら、AIのPRレビューで一番重い1本から

Whiteboardが効くかどうかは、図が差分と合っているかと、図を開く手間を差し引いても読む時間が減るかで決まります。表の2列が埋まれば、その答えは自分の数字で出せます。

毎週のように大きなAIのPRを読んでいるなら、1本だけ測ってみる価値はあります。小さなPRが中心なら急がなくて大丈夫です。会社のコードで試すときは、開く前にテレメトリの設定画面だけ見ておいてください。