PROOF

もう印刷してしまった。それで初めて気づく。

PROOFは、印刷ダイアログの再発明だ。 切手サイズのサムネイルと信仰心のかわりに、ジョブの全ページを読めるサイズで表示し、各ページが実際に消費するインク量をドキュメントの実際のレンダリングレイアウトから計測し、紙を無駄にする前に無駄なシートにフラグを立てる——そして、最後の編集が残したものではなく、意図したものを印刷する。

Cursor Calgaryハッカソン（2026年8月）のために作られた。そのお題は、退屈で日常的なアプリケーション形式を取り上げ、それを視覚的にも機能的にも、あるいはその両方で劇的に改善するというものだった。印刷ダイアログは1995年以来、実質的に変わっていない。ようやく誰かが手を付けたとしたら、こうなる。

問題を具体的に

今日のほとんどのOSが提供する印刷ダイアログのプレビュー領域は、切手ほどの大きさしかない。それが、12ページ以上に及ぶかもしれないドキュメントに対して与えられる可視性のすべてだ。そのサイズでは、1ページが改ページによって取り残された「利用規約が適用されます。」の1行だけになっていること、別のページが「— 続き —」マーカーだけで1枚のシートに溢れ出していること、さらに別のページが11ポイントのセリフ体で「このページは意図的に空白です」と書かれていることを見分けられない。あなたは「印刷」をクリックする。全ページが出てくる。そのうちの数枚はコンテンツではなく、ただの飾りだ——そして、それが起こるのを見る前に、そのすべての紙とトナー代をあなたは支払っている。

PROOFが閉じようとしているのは、まさにこの失敗モードだ。あなたがすでに信頼しているダイアログは、それが求めている判断を下すのに十分な情報を表示していない。

PROOFには現実的なデモドキュメントが同梱されている——20数段落の四半期ビジネスレポート「Q3_Operating_Review_FINAL_v4.docx」で、目次、エグゼクティブサマリー、実際の財務テーブル、サプライチェーンセクション、人員数、見通しセクションに加えて、実際のドキュメントが蓄積するまさにその種のジャンクページが5ページ意図的に挿入されている：「利用規約」フッターの孤立行、「— 続き —」の改ページアーティファクト、迷子の著作権行、「意図的に空白」の通知、そしてページ番号だけのページ。実際に読み込んでページ付けすると、このドキュメントは15ページになり、PROOF自身のライブ計測——手入力の数値ではなく——がそのうち5ページを無駄としてフラグし、10ページを印刷する。proof/index.htmlを自分で開けば、レールにはまったく同じ数値が表示される。なぜなら、それらはここに記憶されているのではなく、ページが読み込まれるたびに新しく計算されるからだ。

Related MCP server: MCP Mortgage Server

数値が実際にどう生成されるか

ここが正確に述べる価値のある部分だ。なぜなら、アイデア全体を機能させているのもこの部分だからだ：PROOFが表示するすべての数値は、読み込まれたドキュメントから計算されたものであり、手入力されたり、もっともらしく見せかけるために飾り立てられたりしたものではない——これは同梱のデモドキュメントにも、ドロップした任意のファイル（後述）にも当てはまる。

1. ページ付けは推測ではなく計測される。 ドキュメントのHTMLは、実際のコンテンツ幅で実際の隠しDOM要素にレイアウトされ、PROOFはそのブロックレベルの子要素（見出し、段落、テーブル、ブロッククォート）を走査し、それぞれの実際のレンダリング高さ（getBoundingClientRect()）を累積し、次のブロックが816×1056pxのページボックス——96dpiでの8.5インチ×11インチのレター紙、おおよそ1インチの余白——をオーバーフローしそうになったら新しいページに改ページする。ソース内の明示的な改ページマーカーは、早期の改ページを強制する。したがって、ページ数は誰かが選んだ数値ではなく、レイアウトの出力なのだ。

2. インク被覆率は実際のテキストジオメトリから計測される。 完成した各ページについて、PROOFはすべてのテキストノードを走査し、ブラウザ自身のレイアウトエンジンに、そのグリフが占める正確な矩形を問い合わせる（Range.getClientRects()）——ピクセル単位のキャンバススキャンではなく、ブラウザがすでに計算した実際のジオメトリに同じ考え方を適用したものだ。各矩形の面積は、明示されたグリフ密度定数（GLYPH_DENSITY = 0.16、つまり通常のテキストでは行ボックスの約16%が実際のインクであり、フォントの太さに応じて増加する）で重み付けされ、テーブル/ブロッククォートのボーダーストロークもインクを運ぶため、その上に加算される。合計をページのコンテンツ領域で割ったものが、そのページのインク被覆率パーセンテージだ。

3. キャンバスラスタライズのパスも存在するが、主要な数値ではない。 PROOFには2つ目の独立したメソッド（inkOf()）も同梱されている：ページをSVGにシリアライズし、オフスクリーンキャンバスにラスタライズし、輝度の暗さで重み付けした非白ピクセルを数える。コードはこれを明示的に「セカンドオピニオンであり、主要な数値には使用されない」とラベル付けしている——ソースを読むなら知っておく価値がある。2つのメソッドのうち直感的なのはこちらだが、画面に表示されているものを駆動しているのはこちらではないからだ。

4. インクが少ないだけでは無駄ではない。 2.0%のインク被覆率（WASTE_THRESHOLD）未満は必要だが十分ではない。ページがフラグされるのは、さらに、認識可能なページ付けの飾り（「意図的に空白」の通知、「— 続き —」マーカー、著作権行、孤立したページ番号）であるか、構造要素（h1,h2,h3,table,ul,ol,svg,img,blockquote）がまったくなく、テキストが120文字未満である場合のみだ。これにより、タイトルページや目次が、単にまばらだという理由で誤ってフラグされるのを防いでいる——同梱のデモでは、タイトルページは2.06%のインク、目次は1.0%を計測しており、どちらも技術的には薄いが、それぞれ見出しがあるため、どちらも印刷される。

5. フラグだけでなく理由も。 フラグされたページの実際のテキストは、実際のドキュメントが蓄積する種類の飾り——「意図的に空白」の通知、「— 続き —」マーカー、著作権行、孤立したページ番号、または明確なカテゴリのない短い末尾行——に対してパターンマッチングされる。したがって、各無駄ページに表示される理由は、そのページが実際に何を言っているかから導出されており、特定のデモ用に書かれたキャプションではない。

信頼に関わることなので、はっきり言う： 何らかの理由でレイアウトベースの計測が実行できない場合、PROOFは黙って何も表示しないとか、静かに何かをでっち上げるといったことはしない——開示された決定的な推定（estimateInk()：文字数、見出し数、テーブルセル数に対する明示された式）にフォールバックし、コード内でまさにその通り、推定であって計測ではないと文書化されている。UIのステータス行は、あなたが見ている数値をどちらが生成したかを教えてくれる——measured · N glyph runs across N pages（計測済み · NページにわたるNグリフラン）またはestimated · layout measurement unavailable（推定 · レイアウト計測不可）のいずれかが表示されるので、計測として提示された推測を見ることは決してない。シートごとの詳細パネル自身の「method」表示もそれと一致し、その特定のシートについてmeasured · glyph-run geometry（計測済み · グリフランジオメトリ）またはestimated · block model（推定 · ブロックモデル）と表示される。

下流のすべて——どのページがフラグされるか、節約されたシート数、平均インク率、シートを開いたときに表示されるページごとの理由、コスト数値——は、現在読み込まれているドキュメントに対してこのパイプラインを実行した結果から導出される。画面上の何も、計算として飾り立てられたハードコードされた結果ではない。

実際に何が見えるか

• まず判定。 ページ数（入り）とページ数（出）、削除されたシート数と平均インク率が、レールのヘッドライン統計として表示される——設定パネルに埋もれたりしない。

• シートウォール。 ジョブの全ページがライブサムネイルとして表示される——実際のレンダリングページをCSSのtransform: scale()で縮小したもので、プレースホルダーグラフィックやゼロから描き直したミニチュアではない——無駄ページには目に見えるスタンプと、ページごとのインクゲージが付く。

• ネストされたリビール。 任意のシートをクリックすると、独自の説明に展開する：どのように分類されたか、2.0%のしきい値に対する計測されたインク被覆率、そしてフラグされたページについては、どの特定の種類の飾りであり、なぜそれを落としても印刷しようとしていたものは何も変わらないのか。これがデザインの背骨だ：ドキュメント → ページ → 1枚のフラグされたシート → 理由、各レベルが次を明らかにする。同じパネルから、その1枚のシートを個別に復元または削除できる。

• 別のファイルも実際にプルーフできる。 レールには本物のドロップゾーンがある：自分の.html、.txt、.mdファイルをドラッグ（またはクリックして選択）すると、PROOFはそのドキュメントを上記とまったく同じパイプラインでページ付けして計測する——これは2つ目のデモモードではなく、同梱ドキュメントが通るのと同じload()関数だ。

• 本物の印刷ボタン。 「印刷」は、画面上のジョブをミラーリングする隠し印刷ルートに対してブラウザの実際のwindow.print()を呼び出す。削除/無駄ページは@media printの下でdisplay:noneを運ぶため、印刷しないと決めたシートは実際に印刷されない。「とにかく全部印刷」という明示的な脱出ハッチもあり、印刷CSSはアプリのクロームを隠すので、プリンタに送られるのはドキュメント自体だけだ。

• ビフォー／アフター。 1995年のダイアログはプレゼンデッキ（proof/deck.html）に正直にレンダリングされ、PROOFが代わりに表示するものと並べて、コントラストが暗黙に示唆されるだけでなく明示的に述べられている。

プラットフォーム

デスクトップとモバイルはどちらもファーストクラスのレイアウトとして設計されており、一方を縮小したものではない——シートウォール、ヒーロー統計行、ネストされた詳細ビューはすべて、電話幅までの専用ブレークポイントを持つ。

MCPサーバー——人間を介さずにドキュメントをプルーフする

ウェブページはPROOFの1つのサーフェスだ。その下では、PROOFはAIエージェントが直接使えるように設計されている：MCPサーバーが、ウェブUIが使うのと同じドキュメントモデルを公開する。これにより、コーディングエージェント、ドキュメントパイプライン、あるいはClaude自身が、1枚のシートが動く前にジョブをプルーフできる——スクリーンショットも、プレビュー領域を読む人間も不要だ。

サーバーはproof/mcp/にあり、ウェブアプリが計測するのとまったく同じ15ページのドキュメントをミラーリングしている——同じファイル名（Q3_Operating_Review_FINAL_v4.docx）、同じ5つの無駄ページ（4、6、9、11、13）と同じ理由、そしてindex.html自身が使うのと同じコスト定数（cost_per_sheet_usd: 0.012、cost_per_ink_point_usd: 0.0009）——したがって、ink_costを呼び出すと、UIが画面に表示するのと同じ金額が引用される（ここでは平均インク2.97%と$0.0603の節約、UIでは「2.9%」と「$0.06」に丸められている）。隠すのではなくはっきり述べられていることが1つある：サーバーのdocument.jsのインク率は、実際のブラウザ計測からミラーリングされたキャプチャ値であり、サーバー自身が再計算したものではない——index.htmlのRange.getClientRects()グリフジオメトリメソッドに移植可能なNode相当物はなく、そのAPIは実際のレイアウトエンジンにしか存在しないため、サーバーは独立して再導出したふりをするのではなく、その数値を"method": "measured_in_browser_layout"として開示している。サーバーを、ウェブUIのドロップゾーンがすでにやっているのと同じように、渡された任意のドキュメントを計測するように配線することが、自然な次のステップだ。

公開される4つのツールは、ライブのスモークテスト実行（node proof/mcp/smoke_test.mjs）で検証済み：

接続するには、Claude Desktop、Claude Code、またはMCP互換クライアントのいずれでも、クライアントをサーバーディレクトリに向ける：

cd proof/mcp
npm install

次に、クライアントの設定でMCPサーバー（stdioトランスポート）として追加する。例えばClaude Desktopのclaude_desktop_config.jsonの場合：

{
  "mcpServers": {
    "proof": {
      "command": "node",
      "args": ["/absolute/path/to/proof/mcp/server.js"]
    }
  }
}

ネットワークホップはなく、デプロイするものもない。サーバーはローカルのstdioプロセスであり、ローカルツール用に実行する他のMCPサーバーとまったく同じだ。これはプロジェクト全体に対する意図的な制約であり（後述の「バックエンドなし」を参照）、エージェント層にも拡張されている。つまり、デモ中に失敗し得るホスティング依存なしでエージェント機能を実現するということだ。

サーバーが実際にエンドツーエンドで動作することを、完全なクライアントを配線せずに検証するには、同梱のスモークテストを実行する。これはserver.jsをstdio上の実子プロセスとして起動し、MCPハンドシェイクを実行し、4つのツールすべてをリストアップして、それぞれを呼び出す。

cd proof/mcp
node smoke_test.mjs

より完全な接続手順（Cursor固有の設定を含む）はproof/mcp/README.mdにある。

実行方法

このプロダクトは静的HTML/CSS/JSである。ビルドステップも、バンドラーも、サーバーもない。

open proof/index.html

または、Finder/Explorerでproof/index.htmlをダブルクリックするだけだ。これがインストール手順のすべてである。npm installも、開発サーバーも、このリポジトリのnode_modulesへの依存も一切なく、外部フォントも、CDNスクリプトも、ネットワーク画像もない。

このページはproof/sample-document.jsと対になっており、これが完全な15ページのデモレポート（window.SAMPLE_DOC）を提供する。2つのファイルをproof/内に一緒に置いておけば、通常の<script src>タグで自動的に読み込まれる。そのファイルが万一存在しなくても、index.htmlは壊れない。ページ自体に組み込まれた、より小さな自己完結型のデモドキュメント（FALLBACK）にフォールバックするため、アプリが空白画面を表示することは決してなく、単に短いドキュメントが表示されるだけだ。いずれの場合も、インク測定はファイルを直接開く場合（file://）もサーブする場合も同じように機能する。なぜなら、パイプラインのどこにもクロスオリジンのネットワークアクセスに依存するものがないからだ。

何らかの理由でHTTP経由でサーブしたい場合（一部のブラウザ拡張機能やより厳格なローカルセキュリティポリシーがfile://ページに干渉することがある）、任意の静的ファイルサーバーで動作する。例：

npx serve proof

スクリーンショットとキャプチャハーネス

_brainstorming/ディレクトリにはこのプロジェクトの作業メモがあり、capture.mjsも含まれる。これは、ハッカソン提出用に、特定のスクロール位置とビューポートサイズ（デスクトップとスマートフォン）でページのフレーム正確なスクリーンショットを撮るための小さなPlaywrightスクリプトだ。これにはこのリポジトリのルートpackage.jsonで宣言されているplaywright devDependencyが必要だ：

npm install
node _brainstorming/capture.mjs proof/index.html --out shots

これは開発ツールであり、プロダクトの一部ではない。PROOF自体はこれを実行する必要は一切ない。

意図的なバックエンドなし

PROOFには、プロダクト自体に対するサーバーも、データベースも、デプロイステップもない。同梱のデモ「データ」は、静的コンテンツとして提供される手作りの現実的な四半期レポートだ（sample-document.js。そのファイルがない場合のより小さな組み込みフォールバック付き）。そのため、そこから計算されるすべての数値（ページ数、インク被覆率、無駄フラグ、コスト）は、ページが読み込まれた瞬間に実際のコンテンツに対する実際の算術演算であり、デモ中にダウンしたり、遅かったり、存在しなかったりする可能性のあるバックエンドへのフェッチではない。また、ドロップしたファイルも、同一のパイプラインを通して実際に受け付ける。MCPサーバーはブラウザの外で実行される唯一のプロセスであり、ホスト型ではなくローカルのstdioプロセスであるため、Webバックエンドのデプロイリスクを一切負わない。

印刷ダイアログを選んだ理由

設計中に、おおよそ十数個の他の「退屈なフォーマット」候補が検討され、それぞれ個別に理由を述べて却下された。サブスクリプションマネージャー、パッケージトラッカー、公共料金請求書は、それらを誠実に作り直すことが、正当なソースのないデータ（銀行残高、キャリアの実際の追跡状態、メーターの読み値）を発明することを意味するため、却下された。キャンセルフローとCAPTCHAは、実際の情報を追加しないため却下された。ブラウザタブマネージャーと航空会社の座席マップは、既存のプロダクト（OneTab/Arc、SeatGuru）がすでに十分にカバーしているため却下された。クッキーバナーは、意図したレイヤー状のスクロール駆動リビールにはキャンバスが小さすぎた。また、以前の処方投与量のコンセプトは、即時理解テストに不合格だったためカットされた。印刷ダイアログは、これらのハードルをすべて一度にクリアした唯一の候補だった。即座に認識でき、現在のダイアログが隠している実際の情報を追加し、画面上のすべての劇的な数値（ページ数、空白ページ検出、インク被覆率）は、ブラウザが実際のドキュメントからライブで、何も偽造せずに実際に計算できるものだ。却下された候補と各ステップの推論を含む完全な決定記録は、_brainstorming/SPEC.mdにある。

リポジトリ構成

proof/
  index.html          the product — open this
  sample-document.js   the 15-page demo report loaded into the product
  deck.html            a short, seven-slide product presentation, same art direction
  docs.html             the full feature-by-feature reference, verified against live output
  mcp/
    server.js           the MCP server entrypoint (stdio transport)
    document.js          MCP server's document model — mirrors index.html's live document
    smoke_test.mjs        end-to-end check: spawns the server, calls all four tools
    package.json          MCP server package (@modelcontextprotocol/sdk, zod)
    README.md             MCP-specific install/connect instructions
_brainstorming/
  SPEC.md             the full design/decision record for this project
  capture.mjs          Playwright screenshot harness used for the submission
  ...                  earlier design drafts and research notes, kept for the record
shots/                desktop + mobile submission screenshots of proof/index.html
shots-deck/           submission screenshots of proof/deck.html

proof/deck.htmlは、短いスタンドアロンのプロダクトプレゼンテーションページである。index.htmlと同じ方法で開き、印刷ダイアログがなぜ壊れているのか、PROOFがインク被覆率をどのように測定するか（実測 vs. ラスタライズ）、そして低インクでも維持される分類器のロジックを、プロダクト自体と同じビジュアル言語で7枚のスライドで説明する。proof/docs.htmlは、より深いスクロール可能なリファレンスである。MCPサーバーを含むすべての機能が、現在のコードに対して、実際のライブ検証済みの数値で文書化されている。

Cursor Calgaryハッカソン（2026年8月）のために構築された。