本文へ
ハクソク

世界を動かす技術を、日本語で。

Show HN: ホワイトボード (YC W26) – 思慮深いソフトウェア設計のためのオープンソースIDE

元記事: 原文(github.com)

概要

  • Whiteboard はオープンソースのデスクトップアプリで、 人間とAIエージェント が共にソフトウェア設計を行うための共通ワークスペースを提供
  • Claude Code や Codex など既存のツールと連携し、エージェントがアプリ内キャンバス上に作業内容を描画可能
  • シーケンス図やER図 などの可視化から直接コードにジャンプできる機能や、 意味的差分ビューア、 意思決定ログ などを搭載
  • MITライセンス で公開、ローカル環境で自己ホスト可能、将来的にチーム向けホスティングも計画中
  • コントリビューション やフィードバック歓迎、匿名テレメトリでプライバシーにも配慮

Whiteboard：人間とエージェントが協働するソフトウェア設計ワークスペース

  • Whiteboard は人間とAIエージェントが同じワークスペース上で ソフトウェア設計・レビュー を行うためのデスクトップアプリ
  • Claude Code、 Codex などのエージェントと連携し、既存の開発フローに組み込み可能
  • エージェント用 SDK により、作業内容の説明や図解を アプリ内キャンバス に描画
  • VSCode互換のキーバインド・LSPサポート を標準搭載し、コードナビゲーションが容易
  • Semantic diff viewer （Rust製AST対応差分ビューア）で、本質的なコード変更のみを抽出・表示
  • 意思決定ログ 機能により、エージェントが自律的に行った判断やその経緯を可視化
  • MITライセンス で公開、ローカルチェックアウトに対応、自己ホストが可能
  • 匿名テレメトリ はコードやプロンプト内容を含まず、プライバシーを尊重
  • コントリビューション やバグ報告、機能提案はGitHubリポジトリで受付

Whiteboardの主な機能と特徴

  • エージェント連携 ：Claude CodeやCodexなど主要なAIエージェントとの接続が簡単
  • キャンバス描画SDK ：エージェントがAPIを通じて図や説明をキャンバス上に描画
  • 可視化からコードへジャンプ ：シーケンス図やER図、エージェントのトレースから直接該当コードに遷移
  • 意味的差分ビューア ：ノイズの多い生diffではなく、ASTベースで本質的な変更のみを提示
    • 大規模関数追加 は疑似コードで要約
    • ユニットテストやドキュメント変更 は自動で折りたたみ
    • WASMプラグイン でカスタマイズ可能
  • 意思決定ログ ：エージェントの自律的な意思決定や要件実装の経緯を可視化
  • ローカル動作・自己ホスト ：MITライセンスで公開され、自己ホストやローカル利用が可能
  • VSCodeベース ：Code OSSをベースにしており、既存のエディタ体験を活用
  • 匿名テレメトリ ：コード内容やプロンプトを含まない安全なデータ収集
  • チーム向け機能 ：将来的にホスト型プロダクトやマルチプレイヤーレビュー機能も計画中

使い方・クイックスタート

  • Whiteboardをダウンロード し、アプリを起動
  • Welcome画面 からClaude CodeやCodexなどのコーディングエージェントを接続
  • エージェントに 現在のブランチをmainと比較してレビュー を依頼し、その結果をWhiteboardで表示
  • 気になる点があれば クリップボードでハイライト し、エージェントに再描画を依頼

推奨プロンプト例

  • 新API変更 ：
    • 「このコミット群で[API]を[目的]のために用意した。提案API例と、その動機（可能ならコンテキストやリポジトリ内情報）を示してほしい。その後、実装方法や仕組みの説明に進みたい」
  • テレメトリ追加 ：
    • 「最新のposthog PRでのテレメトリ変更を説明して。何をトラッキングしているか、良いダッシュボードやプロダクトウォーターフォールをどう構築できるか、ハング・エラー・クラッシュ対策は？」

なぜWhiteboardが必要か

  • 図とコードの連携 ：HTMLベースのツールでは仕様や図からコードへの連携が難しかった
  • 本質的なコードレビュー ：生diffではノイズが多く、意味的な差分表示が求められた
  • 意思決定の透明化 ：エージェントの自律的な判断・実装経緯を人間が理解しやすくする必要
  • “認知的負債” の解消：エージェント主導の高速開発で全体像の理解が難しくなる課題への対応

既知の制限事項

  • Whiteboard内でのファイル編集は未対応 （要望があればIssue提出を推奨）
  • 複数リポジトリ横断のレビュー は現状不十分
  • レビュー共有機能 は後からの更新が他ユーザーに反映されないため、再共有が必要
  • マルチプレイヤーレビュー や ファイル編集機能 は今後の開発課題

コントリビューション・ライセンス・プライバシー

  • コントリビューション歓迎 ：CONTRIBUTING.md参照
  • セキュリティ報告 ：SECURITY.md参照
  • MITライセンス ：Code - OSS由来の部分はMicrosoftのMITライセンスとサードパーティ通知を遵守
  • プライバシー ：匿名テレメトリはコードやプロンプトを含まず、設定で無効化可能

Whiteboardの開発背景・ストーリー

  • 開発者4人（Sid, Alex, Ketan, Milan） が「もう一人の開発者とホワイトボードセッションする」感覚を再現するために開発
  • エージェント主導の高速開発 で生じる“認知的負債”を解消し、理解しやすいコードベース維持を目指す
  • SalesforceやModal などの企業でもアーキテクチャレビューや仕様レベルの変更レビューに活用
  • AIエージェントによるプロトタイピングとWhiteboardセッション を組み合わせて、設計の反復的改善が容易
  • Greptile など他ツールとの連携で、機械的なレビューと人間の判断が必要なレビューを適切に分担

参考・インスピレーション

プロジェクトリンク・インストール情報

ご意見・ご質問はDiscordやGitHubで受付中。Whiteboardの利用・フィードバックを心より歓迎！

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

おお、すごい！12ヶ月後にはどこにでもある技術（フェイクペン描画アニメーション + ストリーミング図）を最初に見ることができるなんて。今でも「ファースト！」コメントってするの？ ~~[編集：もっと目立つ場所に「macOS専用」と書いてほしい。魂が傷つくし、リーナスも怒るかも]~~ [編集2：勘違いしてた！] これ、すごくしっかりしてるね。で、二つのコメントがあるんだけど、1. OS LSPとの統合はかなり楽しいし、称賛に値するよ。図が独自のLSPを持つことは可能なのかな？それとも、直接TSコールサイトのままの方がいいのかな？ 2. 「IDE」という言葉の選び方は、ちょっと問題になりそうだね。「ファイルを編集できない」という小さな詳細があるから。そこに関して何かコメントある？例えば「ブレインストーミングツール」とか、「[建築的]ハーネス」とかにするのはどう？ 3. 擬似コードの「セマンティックディフ」ってアイデア、すごくいいね。4. この言語がちょっと気になるな：「あなたが設定した要件がどのように実装されたか」。私の恣意的な開発フローでは、理想的には アイデア -> スペック/要件 -> プラン -> テスト -> 実装 -> 評価 -> リリース -> レビュー って感じなんだけど、このツールは明らかに二番目と三番目に特化してて、その周辺のカバーも部分的だよね。具体的には、実装を追加することで、強力な特異性のセールスポイントを失って、全てのフルハーネスと競争しなきゃいけなくなるんじゃない？ 5. 「GPT-6 Luna と Claude Opus 5.5」を提案してるのは、たぶんタイプミスだよね？Opus 5.5の相当はAstraだし、それでもあまり関係ないけど。

└

こういう新しいツールがたくさん出てきてるけど、名前が必要だね。偶然見つけた似たようなもの（https://github.com/Maksim-Burtsev/merl）は「コードナビゲーター」って名乗ってるよ。同じような感じで、T3やSupersetみたいなツールを何て呼ぶかもわからない。基本的にはハーネスのためのハーネスだね。

└

ありがとう！本当に感謝してる。1. そうだね、これについても考えたよ。最低限、アプリを再構築せずに自分の図のタイプを追加できるバイブコード可能な拡張システムを実装するつもりだよ。将来的には共通のスキーマやLSP型のものができることを期待してる。2. これはいい指摘で、考えたことがあるし、苦労したことでもある。最終的に「IDE」という用語に決めたのは、今はほとんどの人がコードレビューにVSCodeを使っているから（そうすると、頭の中で構成を描くのが少し楽になる）。編集機能を追加することも強く考えてるけど、正確な形はまだわからないから、今回は出さないことにした。編集は指揮者やスーパーセット型の製品に傾くからね。「IDE」の代わりに「キャンバス」とかにしてみる？もう少し考えてみる。4. そう、これは確かに難しい。だから、今回のリリースでは編集を出さなかったんだ。この解決策の一部は、ライフサイクルの「スペック」部分とのより密接な統合だと思う。ホワイトボードが、スペック（正式な証明みたいなもの）が拡張可能か一般化可能かを理解しやすくするから。もう少し考えてみる。5. そう、それはタイプミスだよ！今直してるところで、「GPT 6 Sol」（基本的には、速いTPSで、知性の制限は本当に必要ない）って言いたかったんだ。編集：Fedora Linuxのビルドもあるから、もしそれを使ってるなら！すべてのディストリビューションでリリースするには少し気を使うから、どのプラットフォームで見たいか教えてね（アプリイメージについて笑）。編集2：（5）は修正済み！ありがとう。

これは、今日のエージェントとの仕事の仕方について、少なくともいくつかのことを正しく捉えてるね。特に、私たちがしばしばアーキテクチャレベルで作業すること、そして現在のコーディングエージェントが提供するプランモードのより良い代替が必要だってこと。高レベルでソフトウェアを効率的に設計するためには、もっと視覚的でエージェントとのやり取りが良好なものが必要だよね。「Xメッセージで最終プランを拒否する」だけじゃなくて。ウェブサイトのデモを見る限り、これはクリーンなインターフェースだと思うけど、エージェントがアーティファクトファイルとして書いてユーザーに提示できるシンプルなカスタムMermaidフォーマットと比べて、どれだけ良いのかはわからない。全体を見渡すと、このアプリは1つの機能（GUIが付いたMCP）って感じで、製品全体ではないように思える。あと、エージェントに特定のコード変更をプランに書かせるのが良いアイデアかどうかもわからないな。「プラン -> 承認 -> コードを書く」の方が、「コードを含むプラン -> 承認」よりもエージェントがより高品質なコードを書くことができると思うけど。特定のプロンプトでコードを明確に進行中のものとしてマークして、プランに対して異なる部分をユーザーに提示するようにエージェントに指示することで、うまくいくかもしれないね。

└

フィードバックありがとう！二つのポイントがあるよ。1. 「これは機能なの？」 - それかもしれない！実際、次はこれをMCP UIとして公開して、Codex DesktopやSuperset/Conductor/Emdashで直接情報を見られるようにするつもりだよ。それはさておき、私たちにとって重要なことは、(1) 良いコードナビゲーション（図/スペック -> コード）、(2) 美しい差分表示、(3) エージェントのトレースをコードに接続して視覚化することだとわかった。これらの問題は十分に難しくて、これらの要件にうまく対応できないプラットフォームを使っている人が多かったから、これらの問題に特化した専用の製品が必要だと思ったんだ。2. 「プランモードでホワイトボードを使う」：うーん、ちょっと意見が食い違ってるかも。今のところ、ホワイトボードの使い方は、プラン -> 承認 -> エージェントがコードを書く -> ホワイトボードを使ってコードを説明する、って感じなんだ。（あるいは、プランフェーズを正式なアーティファクトとして省略して、プランとコードを一緒に出す、ゴーランのデザインドラフトみたいに[A]）。「プランをホワイトボードに最初に入れる」モードを明示的に探求しているけど（今は実験的なスクラッチパッド機能がある）、まだ本番には適していないよ。[A] ゴーランの「デザインドラフト」の実践に強く影響を受けていて、エンジニアリングの速度をスケールさせる方法として、例えば：https://go.googlesource.com/proposal/+/master/design/draft-i...（レジェンド、ラッス・コックスに感謝）

└

現在のプランモードのより良い代替 これは簡単なアップグレード（ime）で、プロセスを意図的にし、計画アーティファクトをファイルに移し、複数のリサーチ/提案/レビューセッションを使って調整することだね。実際の実装に入るときに予見できなかった何かがあるから、実際の探求的な実装要素を追加するタイミングを調整中だよ。ただ、彼らに「プラン」としてマークダウンで実装させるのは避けたい。

すごくクールだね。ローンチおめでとう。2026年の前半は、みんなが何らかの形で内部ツールを作った年だったね。君たちがそれを製品にできたのは嬉しいよ。面白いのは、このツールが認知負荷を減らすためのいくつかのユースケースに対処しているけど、それが頻繁に起こるから積み重なっていくんだ。認知負荷の鍵は、エージェントがたくさんのトレースやドキュメントを生成することが多いけど、最終的にはそのトレースの小さな割合しか最終的な変更には重要じゃないってことだと思う。簡潔な変更は通常とても小さく、自己完結しているからね。これが重要になるのは、このツールを使って構築された内部ツールを維持することだと思う。私は、コードを構築する前にデザインを手伝う内部ドキュメントシステムを維持していて、そのドキュメントシステムは完全にバイブコードされていて、すぐに機能を追加できるけど、今はすっかり成長してしまった。そこでの課題は、新しい提案された変更について十分に理解して承認できるかどうかなんだ。それが、ドキュメントシステムが自体で負担にならないための鍵であり、厳密なコア機能セットを維持することなんだ。

└

最終的な変更に重要なのはほんの小さな%のトレースだけなんだ。というのも、簡潔な変更は通常とても小さくて自己完結的だから。そうだね、これは広いパズルの一部だと思う。特に複雑な変更では、頭を使わなきゃいけないことが多いからね。 > じゃあ、提案された新しい変更について、承認するためにどれだけ理解できるかが課題だね。ホワイトボードは私たちにとって強力なツールだったよ！君が言ったように、これをもっと大きなシステムの一部として計測する必要があると思う（ちなみに、私たちも同じ考えだよね：https://dev.fast/about/）

図の正確性についての懸念がある。例では、「いいえ」の決定の後に「リリースを待つ」とラベル付けされたセッションサービスに戻る遷移があるけど、表示された差分にはそれが見当たらない。コードを見ると、「いいえ」はコンテキストの期限切れに関連しているようだから、コンテキストがすでに期限切れなら、もっと待つ必要はないし、止めるべきだよね。そのラベルが存在する理由は何かあるの？LLM開発ツールが幻覚を見て時間を無駄にするのが心配なんだけど、リースブローカーの例でそうなってるのかな？

└

やっほー！あ、そのGIFはデザイン用の仮のやつで、更新するのを忘れてた。実際の図は全部コードにリンクしてるから、実際には幻覚みたいなことは起こらないよ（幻覚的なアーキテクチャは私も気になるけど！）。アプリの実際のGIFをすぐに更新するね。ごめんね！

いいタイミングだね！実は私も同じことを考えてたんだ。私のはウェブサイトを作るスキルで、フローをマッピングして関連するコードを用意してるんだけど、君も同じことをしてるみたいだね。これはフォローする価値ありそう！頑張ってね、みんな！

└

ハハ、そうだね。私もサイドプロジェクトとして自分用に作ってるんだ。この分野で実験してる人はたくさんいると思う。どう発展していくか楽しみだね。

Hacker Newsで議論の続きを見る

同じ出典の記事