文書を一つ直すだけなのに、ブラウザ、クラウドストレージ、AIチャット、PDF変換ツールを何度も行き来していないでしょうか。企画書や議事録が`.docx`で届く仕事では、本文を書く時間より、形式を保ったまま開き、直し、渡し直す時間が気になることがあります。
そこで目を引くのが、Rustで作られたオープンソースの文書編集ソフトWordCraftです。Wordに近いリボンや変更履歴、表、参照機能を目指しつつ、デスクトップだけでなくCLI、JSON control channel、MCP serverまで同じ操作の土台でつなぐ設計を掲げています。
WordCraftの面白さは、Word形式を開けることだけではありません。
人が画面で行う編集と、スクリプトやAIエージェントが行う操作を、別々の近道にせず同じコマンドの入口へ寄せようとしている点にあります。
WordCraftは、どんな文書編集ソフト？
公式リポジトリによると、WordCraftはMicrosoft Wordを参照するワークフローを、公開仕様と観察にもとづくクリーンルーム方式で作り直すオープンソースプロジェクトです。Microsoftの製品ではなく、独立したソフトとして、リボン、スタイル、表、変更履歴、参考文献、差し込み印刷といった文書編集の部品を並べています。
「Wordと同じ見た目なら乗り換えられる」と急ぐより、まずは普段の文書が何を必要としているかを分けると見えやすくなります。見出し、表、コメント、変更履歴、ページ区切り、PDF出力――使う機能は人や部署で違うからです。
画面の再現度だけで、業務文書の互換性は決まりません。相手から受け取る形式、社内で残す履歴、最終的に渡すPDFまで、一つの往復として考えるのが出発点です。
`.docx`を起点に、どこまでファイルを行き来できる？
WordCraftのREADMEは、`.docx`の読み書きに加え、`.odt`、`.rtf`、`.html`、`.md`、`.tex`、`.txt`の入出力、旧形式`.doc`の読み込み、PDF出力を案内しています。CLIの例には、文書のPDF変換、プレーンテキスト抽出、構造をJSONで調べる操作もあります。
これは「どのファイルも完全に同じに見える」という約束ではありません。複雑な図形、差し込み印刷、フォント、改ページ、コメントが重なれば、文書形式どうしの差が表面に出やすくなります。特に社外へ渡す資料や契約に関わる文書は、原本を残したまま小さなテストファイルで往復させ、PDFのページ送りまで確認する方が安全です。
最初の確認は、重要な100ページの資料ではなく、見出し・表・画像・コメントを入れた2〜3ページで十分です。
開く、編集する、保存する、PDFへ出す。この短い往復で崩れる箇所を見つけてから、対象を広げましょう。
ローカルで文書を扱う意味は、ファイルを閉じた場所へ置くだけではありません。会話から資料を作る入口をクラウド側へ寄せる動きは、Microsoft CopilotのOffice統合を扱った記事でも見た通りです。WordCraftは逆に、手元のファイルと操作の見通しを残しながら、自動化の入口を増やす方向として読むと対照がはっきりします。
人のリボン、CLI、MCPを同じコマンドで動かす意味
公式説明で最も特徴的なのは、リボン、ショートカット、コマンド検索、CLI、JSON control channel、MCP serverを、同じ422個のコマンドが動かすという設計です。画面で太字にする操作と、自動化側が文書へ命令する操作を、別の実装へ増やしにくくする考え方です。
たとえば毎週届く議事録の見出しをそろえる、定型の注記を入れる、見出し構造を点検する、といった作業では、何を自動化したかを人が画面で追える方が安心です。逆に、AIエージェントへ文書全体を自由に直させることを、そのまま推奨する設計ではありません。
MCPは「AIに文書編集を任せ切る」ためのボタンではありません。どの操作を渡し、どの結果を人が確認するかを、同じ操作系の上で決められる余地です。
Rustを使う理由も、流行語だけで片づけない方がよいでしょう。MicrosoftがRustをTier-1言語に位置付けた動きと同じく、長く扱うソフトでメモリ安全性や開発基盤をどう積み上げるか、という実務の話につながります。ただし、WordCraftの速度や対応範囲は開発チームの公開情報であり、他社製品との一律比較ではありません。
MCPで文書を触らせる前に、フォルダを絞る
READMEには、headlessで文書を扱うMCPの起動例とともに、読み取り・書き込みを許すフォルダを指定するオプションが示されています。これは、エージェントへ「PCの文書全部」を渡すのではなく、作業用に切った場所だけを対象にするための入口です。
最初は、コピーしたサンプル文書だけを置くフォルダを作り、読み取り、見出しの抽出、PDF変換のような戻しやすい処理から試すのが現実的です。原本の上書き、メール送信、共有フォルダへの移動は、結果の確認と復元手順が固まるまで別にしておきましょう。
フォルダを指定できることは、内容が必ず正しいことを意味しません。
権限を狭くし、元ファイルを複製し、差分と出力PDFを確認する。この3つを先に決めると、自動化を止める場所も見えやすくなります。
「Wordの代わり」ではなく、文書作業の検証環境として見る
WordCraftはまだ活発に開発されているプロジェクトで、README自身もロードマップと機能チェックリストを参照するよう案内しています。すべての`.docx`を同じ結果で扱えると決めつけるより、特定の文書フローで使えるかを確かめる対象として見るのが向いています。
手元のファイルを開き、必要な箇所だけ直し、同じ操作をCLIやMCPで再現できる。そこに魅力を感じるなら、まずは定型文書やテスト用の議事録で試してみる価値があります。文書編集が人の画面だけの仕事でなくなるほど、便利さの次に必要になるのは、どの操作が、どのファイルへ、どの経路で届いたかを追えることです。
AIが資料を扱う時代でも、文書は「最後に人が読む成果物」です。
WordCraftは、人の編集、ローカル処理、自動化を同じ操作へ寄せながら、その確認の余地を残そうとする試みとして注目できます。
