Tech Teardown 022｜wordcraft：1人と一群のagent、5日間でWordを「再構築」

10月7日にキャッシュが開始され、5日間で6,000個以上の星を獲得しました。これはGitHub上のstorytold/wordcraftの成果です。しかし、これは珍しい例ではありません。同じ組織が2週間でPhotoshop、Lightroom、Premiere、Acrobat、Illustrator、Excel、PowerPoint、AutoCADを順番に「クリーンルーム再実装」しました。その中でphotocraftは4.8万個の星を獲得し、すべてRustで書かれており、「クリーンルーム再実装」と自称しています。wordcraftはその中のWordメンバーで、READMEの最初の行には「Microsoft Wordのオープンソース、クリーンルーム再実装で、純粋なRustで再構築された」と書かれています。本当に注目すべきはその生産方法です。主要な貢献者が3日間で57,353行の新しいコードを提出し、プロジェクトのロードマップ上の残りの作業時間は「Opus 5.5 agent wall-clock hours」で計測されました。1週間以内にPRの数は581に達しました。これはAIエージェントが大量にコンプライアンスのあるソフトウェアを生産する実例であり、本文では古い規則に従って6つのセクションで分解します。

一、それは何か

wordcraftはArtCraftファミリーのドキュメントプロセッサメンバーで、Microsoft Wordと機能的に一致させることを目指し、コードは完全に独立して再構築されています。規模は大きく、リポジトリには428ファイル、280個のRustソースファイルがあり、合計156,273行（テスト含む）です。彼ら自身のロードマップでは別の数値を報告しており、433個のコマンド、855個のテスト、10個のproperty block、約88,700行のRustが記載されています。自己申告と実際の統計は一致していませんが、これ自体がこの種のプロジェクトの特徴です。後ほど第4セクションで詳しく説明します。

アーキテクチャは7層に分かれています。下層は幾何計算とフォント、上層は組版エンジン、さらに上はdocxなどのファイル形式の読み書き（OOXML/ECMA-376をサポートし、ODT、RTF、HTML、Markdown、LaTeX、純粋なテキスト、さらにはWord 97-2003の.docも読むことができます）、次にレンダリングとPDFエクスポート、さらに上はエンジン層（セッション、キャンセル、コマンドレジストリ）、最外部はMCPサーバーとeguiのデスクトップインターフェースです。リリース形態は3種類あります：デスクトップアプリ、コマンドラインツール、WASMウェブバージョンです。

「純室」はその基盤であり、ルールはAGENTS.mdに記載されており、非常に厳格です：開発環境には正規のWordがインストールされていること、ブラックボックスでの観察が許可されていること、ウィンドウスクリーンショットを比較することが許可されているが、Wordのインストールパッケージ内部を読むことは禁止されており、どんなWordの生成物も提出することは禁じられています。ファイル形式は公開規格（ECMA-376、OASIS ODF 1.3、RTF規格）に従ってのみ実装されます。名前の指定では、LibreOffice、AbiWord、pandocといったGPL系コードを真似してはいけません。資産に関する規律も厳しく、ATTRIBUTION.mdでは各非コード資産の作者、出所、ライセンスを登録することが強制されており、cargo xtask assetsのチェックで行き抜きが欠けると失敗します。アイコンはすべてコードで描かれ、マイクロソフトのアイコンは一切使用禁止です。フォントはOFL-1.1のオープンソースフォントライブラリを使用します。コードのライセンスはMIT OR Apache-2.0で、ブランド商標は個別に保護されています。

二、なぜ今見る価値があるのか

純室はOfficeを再実装するものであり、この道をこれまでに歩んだのはLibreOfficeだけでしたが、その代償は数十人に年間の歴史的負担でした。現在はAIエージェントがあります：公開規格に従ってWordを再作成する作業量は、「一人のチームの職業生涯」から「一人と数人のエージェントの数週間」に圧縮されました。wordcraftのロードマップはこの点を直接示しています：残りの作業はすべてエージェントの労働時間で評価され、ベータ段階では150から230のエージェント時間が必要で、95％の完成度になると650から1100のエージェント時間が必要です。労働時間の計算に使用される例は「PR #191で約9,700行を5時間かけて作成した」や「.docリーダーで約4,500行を10時間かけて作成した」といったものです。人間ではこの速度で作業することはできず、プロジェクトはAIエージェントによる大量生成のパターンで運営されます。これについて、著者自身も否定していません。HNでの議論では、コメント欄でvibe-codedという言葉が使われています。

もう一つの背景は感情的な燃料です。AdobeとMicrosoftのサブスクリプション制度による疲労は長年にわたって蓄積されており、HNでのこの家族に関する議論では、「Adobeのセーフティーバンクが小さすぎて、いずれ誰かが価格に不満を持ち、Creative Suite全体を再構築するだろう」という高評価の意見があります。実際には、あるコメント者はプロジェクトを見た直後にAdobeの株を売り急ぎました（個人的な行動で、真実ではありません）。著者自身がHNに現れた時は率直でした：「HNにこれを投稿する準備ができていなかった。まだ準備が完全にはできていない」と。初期のアルファ段階で、公開募集を行い、奨学金やバグ報酬を提供すると約束しています。

三、核心技術メカニズム

移転する価値があるのは四つの要素です。

第一点、すべてがコマンドです。各操作はidを持つCommandSpecであり、同じ一連のコマンドが（READMEでは422個、ロードマップでは433個とされており、その数はイテレーションによって変わります）6つの入力を同時に動かします：リボンメニュー、キーボードショートカット、コマンド検索、コマンドラインツール、JSON制御チャネル、MCPサーバー。1つの機能を追加するということは、1つのコマンドを登録することに等しく、6つの入力が自動的に有効になります。READMEでは「Built for agents」を公式の売り文句としており、agentはMCPサーバーを通じてアプリ全体を無頭で動作させることができます。

第二点、never crashの規律です。テスト外のコードではpanic、unwrap、unsafe_codeを禁止し、直接forbidと設定します。hostile_params_never_panicというテストがあり、ゴミなパラメータを使ってすべてのコマンドを実行し、崩壊しないことを保証します。Session::runでは、逃げたpanicをエラーに変換し、ドキュメントの状態を回復させます。AGENTS.mdには「never crash」の条項が機能よりも優先されると記載されています。AI生成の大量のコードに対しては、このようなグローバルな保証が必要であり、清潔好きなことではありません。

第三点、クリーンルーム観察法です。前述の規則について、ここで実行の詳細を補足します：形式の実装は公開された規格のみを認め、観察にはブラックボックスのみが許されます（実行、スクリーンショット）。CIには層間参照を防ぐためのレイヤー検査があります。法的な灰色領域は自身で触れませんが、「ウィンドウのスクリーンショットに合わせてUIを整える」という方法は外観の侵害と見なされるかどうか、HN上ではすでに「Microsoftが訴えるかどうか」という質問があります。これはプロジェクトの頭上に浮かぶ問題です。

第四点、parityのテスト可能性です。cargo xtask parityを使って、Wordの機能と照合するリストを生成します。ロードマップのリボンカテゴリは481/496（97.0%）がこのコマンドでテストされており、思いつきではありません。テスト量の強制的な下限は上昇のみであり、下がることはできません。すべての品質チェックはcargo xtask ciにまとめられており、fmt、clippyは-D警告を含み、テスト、アセット登録、階層検査、WASM構築が必要で、提出前にはすべて合格でなければなりません。

付随するコンポーネントも注目に値します。cratesディレクトリにはメインロードの他に、Zoteroの参照統合（学術ライティングシーン）、オフラインスペルチェックと文法チェック（ネットワークに接続せず、内容を外部に公開しない）、Read Aloudのセンテンスレベルのモデルが含まれています。これらのコンポーネントは、著者が「ドキュメントプロセッサの完全なエコシステム」に対するリスト意識を持っていることを示しており、単に核心的なレイアウトだけを積み重ねているわけではありません。ロードマップにはまた、一つの規則があります：最新のレビュー日付と更新日付をファイルの冒頭に記載します（Last reviewed 10-10、Last updated 10-11）。各数字の横にはmeasuredかestimatedかが記されており、自己申告データの範囲が明確です。AI生成のドキュメントが氾濫する現在、これは実際には希少なものです。

四、数字と境界

3つの数字を並べてみると、その差が境界線となります：ribbonディレクトリのカバレジは97%（ツールによる実測値）、feature breadthは約80%（推定値）、「Ready for real work」は約60%（推定範囲55-63%）です。一方、ユーザー側の数字はさらに厳しい：ロードマップでは120人の外部ユーザーからのissueがあり、4件の高評価があり、移行したユーザーは0人で、約21のコアパスに未修正のバグがあります。97%のディレクトリカバレジと0人の移行ユーザーの間には、アルファ段階と製品との距離があります。

性能に関する主張はすべて自己申告です：「188ページのドキュメントを打ち込むと、重排版に約1.4ミリ秒かかる」というもので、第三者の検証はありません。行数に関する2つの数字（自己申告88,700対実測156,273、テスト含む）から、ドキュメントの更新がコード生成速度に追いついていないことがわかります。これはエージェントによる大量コード生成プロジェクトではよくあることです。貢献者構造も注目に値します：contributors.jsonには45回のコミットがあり、主な貢献者1人が3日間で57,353行を追加し、その他は小規模なPRです。リポジトリは「完成品倉庫」の形をしており、歴史が押し込められ、プロセスが追跡できません。一人の主導者とエージェントによるコード生成、長期的なメンテナンスが最大の疑問です。

HNのコメントには両方の意見があります。懐疑派は、「skeptical」と直接言う人、デスクトップ版の試用に登録が必要だと不満を言う人、スクロールバーの体験が「より良いUXに期待できない」と不満を言う人、家族主倉庫がfair sourceライセンスを使用していることに気づき、「AI slopは生まれながらにしてパブリックドメインである」という著作権の疑問を提起する人もいます。法的な質問では、「デザイン上の親本」がリスクをもたらすかどうか、さらにはMicrosoftがGUIの複製のためにwordcraftを訴えるかどうかを直接尋ねる人もいます。この投稿には3人の支持票しかありませんが、問題は未解決のままです。衝撃派は、ページデザインが素晴らしいと褒める人、3年前にこのようなものを見たら驚いただろうと言う人、このプロジェクトの規模が「vibe codingのさまざまな主張を検証するのにちょうど良い」と感じる人もいます。両方の意見を合わせて見ると、コメント欄の意見の違いと今週の対談コーナーで解明されたKarpathyのコンセンサスのギャップは同じ形状です：触れた人と触れなかった人が、それぞれ自分のサンプルに基づいて結論を出しています。

五、どうやって動作するか、誰が遊べるか

v0.4.0（10月10日リリース）は、全プラットフォーム向けのインストールパッケージを提供しています：macOS用の署名DMG、Windows用MSI、Linux用AppImage、deb、rpm、Flatpak、FreeBSDパッケージ、ウェブ版WASM。1週間以内に7つのプラットフォーム向けの配布をすべて完了させることで、これはエージェントの生産能力を示すものです。通常、従来のプロジェクトでこの段階に到達するには、1人のリリースエンジニアが数週間かかります。コードを読んだり貢献したい人は、cargo xtask ciコマンドで全ての品質チェックを行えます；AGENTS.mdは十分に詳細で、クリーンルームの規則からパニック禁止まで、資産登録まで、エージェント開発の標準テンプレートとして使用できます。AIエージェントを使ってドキュメントを作成したい人は、MCPサーバーを起動すればよいです。一般ユーザーは、単に観察するだけにしてください：ロードマップにはまだ約21の核心的なバグがあると認められており、それを使って正式なドキュメントを作成するには早すぎます。

六、価値判断と適用対象

まず、タイトルに関する質問に答えます：現在、これはWordの代わりにはなりません。移行ユーザーが0人というのが答えです。しかし、「AIエージェントを使った大量生産のコンプライアンスソフトウェア」としてのプロジェクトパラダイムとしては、価値が高いです。4つの要素を直接採用できます：クリーンルームの規律（ブラックボックス観察、公開規則のみの認識、資産の追跡登録）、never crashのグローバルなサポート、パリティの可測化（対照リストのツール化、テスト下限の上昇のみ）、1コマンドでの全品質チェック。これら4つは具体的なプロジェクトとは関係ありません。エージェントを使ってコードを書くチームなら誰でも採用できます。

以下の3種類の人に適しています：AIエージェントを使ってコードを書くエンジニア、そのプロジェクト規律を真似る人；AIの生産性の爆発に注目する人、これは「3日間5万行」の現場です；そして、vibe codingの主張の限界を確認したい人。そのロードマップは、「ディレクトリのカバー」「機能の広さ」「実際の作業での使用可能性」を3つの数字に分けて提示しており、どれがツールによる実測で、どれが推定かも明記しています。この誠実さ自体がサンプルの一部です。

リスクに関する最後に：法的な灰色地帯は未解決です（UIの複製が訴訟される可能性があるかどうか、答えはありません）、1人でのメインストーリーとエージェントコードのメンテナンスの持続性に疑問があります。自ら報告する内容と実際の測定結果との間には常に差異が存在します。これは、AIエージェント時代のソフトウェアエンジニアリングがどのようなものであるべきかという公開された実験記録のようです。このリポジトリは、その答えの一部を先に書き出しています。答えの残りの部分は、アルファ版がリリースされた後に書かれることになりますが、ほとんどの同種プロジェクトはこの段階を超えることはありません。これが、このサンプルが最も注目に値する理由です。

情報源

• リポジトリとドキュメント：github.com/storytold/wordcraftのREADME、ROADMAP、AGENTS.md、NOTICE、ATTRIBUTION.md、contributors.json（ローカルで浅いクローンを確認し、コード行数はwc -lで計測）
• 星の数とファミリーランキング：GitHub検索API、2026-10-12のスナップショット
• HNの議論：news.ycombinator.com/item?id=49958850など4つの投稿、Algolia APIから取得し、コメントはすべて要約版
• 性能、カバレッジ、完成度の数字：プロジェクト自身が報告した数値で、本文は各所に注記されている