AIにコードを書かせるのは珍しくなくなったが、その結果として「なぜそうなったのか」が見えにくくなっている。devdotfast/whiteboard は、その穴を埋めようとするオープンソースのデスクトップアプリだ。単なる図解ツールではなく、AIエージェントの作業内容や判断を、コードと行き来しながら追える作業台として作られている。GitHub上の公開リポジトリとして出てきたことで、こうした“説明できる開発”をどう実装するのかが一気に見えやすくなった。
元記事で示されている Whiteboard は、「thoughtful software design」のための open-source canvas だと説明されている。対象は開発者だけではなく、人間とエージェントが同じワークスペースでソフトウェアを組み立てる使い方だ。macOS と Fedora 向けのダウンロード、Webサイト、Discord への導線もあり、README だけの試作ではなく、実際に触る前提のプロダクトとして見せている。
中心にあるのは、Claude Code や Codex など既存の coding agent とつながることだ。Whiteboard 自体がコードを書くというより、エージェントに SDK を渡し、アプリ内の canvas に「何を考え、どう進めたか」を描かせる。導入手順もかなり具体的で、アプリを開いたらエージェントを接続し、現在の branch を最新の main と比較して、その結果を Whiteboard に出させる流れが案内されている。
README では、これを使う場面として新しい API 変更や telemetry の変更例が挙げられている。たとえば API 変更なら、提案される API、例、背景にある motivation を出してから実装へ進むよう促している。telemetry の変更では、PostHog の PR から何を追跡しているのか、どうダッシュボードや product waterfall に落とせるか、hangs・errors・crashes をどう扱うか、といった観点を Whiteboard で説明させる想定だ。気に入らない部分があれば、クリップボードで選んで agent に渡し、描き直させることもできる。
なぜそんな仕組みが必要なのかについて、README は三つの理由を挙げている。ひとつは「Diagrams that lead to code」で、sequence diagram や entity relationship diagram、あるいは agent の trace の引用をクリックすると、その元になった code に飛べること。コード側に戻れば、VS Code 由来の keybindings と LSP support をそのまま使える。二つ目は semantic diff viewer で、Rust で AST-aware の差分表示を作り、関係のある変更だけを見せる。大きな追加関数は pseudocode に要約し、unit tests や documentation は折りたたむ、あるいは隠す。ただし全部は固定ではなく、WASM ベースの plugin system で調整できる。三つ目は decision log で、agent が自律的にどんな判断をしたのかを trace として問い合わせたり、Whiteboard 上で関連づけたりできる点だ。要件、実装、agent の判断をひとつの画面でつなぐ狙いがはっきりしている。
Whiteboard は MIT license で、ローカルの checkout に対して動く。将来的な hosted product for teams の計画はあるが、自己ホスト可能であり続けるとも書いている。一方で制約も正直に並べていて、現時点では Whiteboard 内でファイル編集はできないし、複数 repo をまたいだ閲覧も十分ではない。共有した review にあとから加えた更新は相手に自動反映されず、再共有が必要になる。プライバシー面では、anonymous telemetry に code や diffs、Whiteboard のテキスト、prompts、model output は含まれないとしている。
このプロジェクトで面白いのは、単に“見栄えのいい白いキャンバス”を作っているわけではないことだと思う。Whiteboard が解こうとしているのは、AI で生成されたコードが増えるほど、レビュー対象が「差分」だけでは足りなくなるという問題だ。人間が本当に知りたいのは、変更結果だけでなく、そこに至る前提や選択肢、捨てられた案まで含めた思考の流れだからだ。そこを図、trace、diff、コードの往復で見せようとしているのは筋がいい。
ただ、ここには難所もある。AI の出力を見える化するほど、逆に「説明がそれっぽければ納得してしまう」危険もある。きれいな diagram や整理された decision log は、理解を助ける一方で、実際には不十分な実装を隠すこともある。だから Whiteboard の価値は、見栄えではなく、どこまで元の code や trace に戻れるかにあるはずだ。クリックすると根拠に飛べる設計は、その意味でかなり重要だと思う。
README にある semantic diff viewer の話は、派手さはないがかなり実務的だ。LLM が関わると、1回の変更でファイルが長くなり、コメントやテスト、補助関数まで雪だるま式に増える。人間が raw diff をそのまま眺めても、どこが本体なのか分からなくなる。そこで AST-aware にして、意味のある変化だけに絞るのは、レビューの負担を減らす現実的な手だと思う。
気になるのは、どこまでを「意味のある変化」と判断するかだ。unit tests や documentation を折りたたむのは便利だが、実はそこにバグの兆候が隠れていることもある。要するに、要約は強いが、要約される側の情報を見落としやすい。Whiteboard が plugin system で調整可能にしているのは、その弱点をある程度わかっているからではないか。レビューする側が、自分の関心に応じて表示を変えられる余地は必要だと思う。
Decision log を前面に出しているのも印象的だ。AI に作業を任せると、出来上がったコードの責任が誰にあるのか曖昧になりやすい。だからこそ、requirements をどう受け取り、どの判断を agent が自律的に行ったのかを trace として残す意義がある。これは監査のためだけでなく、チーム内で「どこまで自動化を許すか」を決める材料にもなる。
一方で、こうした記録が増えるほど、運用は少し重くなる。trace を残せるということは、見返す習慣がないと単なるログの山になるからだ。私は、Whiteboard の価値は「AI との共同作業を可視化する道具」である以上に、「自動化した判断を後から検証できるようにする道具」にあると思う。開発現場で本当に効くのは、速く書けることより、あとで説明できることだからだ。
Whiteboard は local checkout を前提にし、self-hostable を明言している。ここはかなり大事だと思う。AI 支援の開発ツールは、どうしてもクラウド依存やデータ収集に寄りがちだが、開発現場では「ソースを外に出したくない」「まずは社内で閉じたい」という要望が強い。しかも Whiteboard は telemetry について、コードや diff、プロンプト、model output を含めないと説明している。これは宣伝文句というより、導入可否を左右する条件だ。
もちろん、ローカルで動くから安心、という単純な話でもない。agent を接続し、レビューや trace を扱う以上、どこかで情報の境界はまたぐ。ただ、それでも最初から local-first と self-host を掲げるのは、少なくとも設計思想としては誠実だと感じる。AI ツールの多くが「便利さ」を先に出す中で、Whiteboard は「どう使われるべきか」を先に考えているように見える。そこは、今後こうしたツールが広がるうえでかなり重要な差になるはずだ。
参考: GitHub - devdotfast/whiteboard: open-source canvas for thoughtful software design
