最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

2026年06月24日著者:Elena

ONLYOFFICEが今年7月に16周年を迎えるにあたり、製品を形作った決断を振り返っています。この決断は、名前が決まる前、オープンソースライセンスの前、そして2,100万ユーザーの前に訪れました。代替案に我慢の限界を迎えたチームが、誰も試したことのないものを作ることを決めた瞬間の話です。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

エディタが存在する前に、問題があった

2010年のことです。TeamLabというコラボレーションプラットフォームに取り組んでいたAscensio System SIAのチームは、ユーザーが製品内でドキュメントを操作できるようにする必要がありました。プラットフォームにはプロジェクト管理、CRMツール、Wiki、ブログ、共有ファイルスペースがありました。しかし、誰かがWordドキュメントを編集する必要があると、そのワークフローは、控えめに言っても、エレガントではありませんでした。

最初に追加されたドキュメント編集オプションは悪夢でした。「ファイルを開く」を押すと、exeファイルがPCにダウンロードされました。プリインストールされたプラグイン付きのOpenOfficeです。ポータルからのドキュメントがOpenOfficeで開かれ、編集後にクラウドに保存し直されました。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

2010年のWebにおけるドキュメント編集とはこういうものでした。ブラウザを離れ、デスクトップアプリケーションを開き、編集し、保存し直し、作業に戻る。すべてのステップが摩擦でした。すべてのステップが潜在的な失敗点でした。間違ったバージョン、間違ったフォーマット、間違った人のコピー。

チームはそれを嫌いました。マイルドでプロフェッショナルな「おそらく改善できる」という意味ではなく、本能的で日常的な「これは恥ずかしい」という意味で。そして彼らは、会社を定義するか、あるいは破壊するかのいずれかになる類の決断を下しました。独自のエディタを書くことを決意したのです。

賭け:HTML5 Canvas

2010年にブラウザでドキュメントエディタを構築することは、合理的なことではありませんでした。Google Docsは2006年に開始されており、明らかな参照点でしたが、ブラウザが標準のHTMLを使用してドキュメントをレンダリングすることで機能していました。これは、印刷した出力がスクリーンで見たものと異なって見えることを意味しました。フォーマットはブラウザをまたいで崩れました。複雑なレイアウトは崩壊しました。Webはデスクトップワードプロセッサの精度を再現する準備ができていませんでした。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

ONLYOFFICEチームは根本的に異なるアプローチを選びました。ブラウザにドキュメントをレンダリングさせる代わりに、HTML5 Canvasエレメントを使用してすべてのピクセルを直接描画することで、自分たちでレンダリングすることにしました。

Canvasは、2Dシェイプとビットマップイメージの動的でスクリプタブルなレンダリングを可能にするHTML5の一部です。このテクノロジーは、ブラウザやOSに関わらず元のフォーマットを保持することで知られています。

その意味は重大でした。ドキュメントをピクセルごとに描画するなら、どのブラウザ、どのOSでも、スクリーンに表示されようと、PDFにエクスポートされようと、プリンターに送られようと、それがどのように見えるかを正確にコントロールできます。入力は常に出力と同一です。処理されたファイルは同じスタイル、段落、記号、行間隔を保持します。見るドキュメントが、得るドキュメントです。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

しかし技術的リスクは現実のものでした。HTML5 Canvasはドキュメント編集のために設計されたものではありませんでした。誰もこれをやったことがありませんでした。チームは既存のアプローチを適応させていたのではなく、新たに構築していました。もし実際のオフィスソフトに必要なスケールとパフォーマンスレベルで機能しなければ、2年間のエンジニアリング作業が無駄になるところでした。

興味深い事実:Canvasは最初の試みではありませんでした。HTML5 Canvasに落ち着く前に、チームはCKEditorを試みました。標準的なHTMLレンダリングに基づいて構築された確立されたブラウザベースのリッチテキストエディタです。Google Docsアプローチが不十分だったのと同じ理由で失敗しました。プレーンなHTMLは単純に、チームが必要とするフォーマット精度とクロスブラウザの一貫性を提供できませんでした。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

チームには皮肉に映らないわけがありません。「GoogleとMicrosoftは、おそらく私たちからヒントを得て、私たちが使っているのと同じテクノロジーに切り替えました。」偶然の一致か収束かはともかく、業界は最終的にONLYOFFICEチームが2010年に達した同じ結論に至りました。チームはただそこに先に到達しただけでした。

事実:2021年5月、ONLYOFFICEのCeBITデビューからほぼ10年後、GoogleはGoogle DocsがHTMLベースのレンダリングからCanvasベースのレンダリングに移行すると発表し、パフォーマンスの向上とクロスプラットフォームの一貫性を理由として挙げました。ONLYOFFICEが2010年に賭けたアプローチは、少なくとも市場の2大プレイヤーの一方にとって、業界標準となっていました。

CeBIT 2012:最初の公開デビュー

2012年3月、チームはその賭けを公開しました。世界最大級のテクノロジー見本市であるハノーバーのCeBITで、TeamLabは最初のHTML5ベースのドキュメントエディタを発表しました。ベータ版はhtml5.teamlab.comでテストできました。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

TeamLabはオフィスソフトウェアに初めてHTML5ベースのドキュメントエディタをもたらしました。新しい最先端技術により、TeamLabはいかなるブラウザでも、いかなるOSでも、印刷時やインポート時でさえも、ファイルを正しく表示しました。さらに、テーブル処理、行間隔、多段階の番号付け、テキストと見出しのスタイルに関する強力なオプションも提供しました。

この段階の製品はドキュメントエディタのみでした。スプレッドシートも、プレゼンテーションエディタも。Canvasの上に構築されたテキストエディタだけが、このアプローチが機能することを実証しました。

チームはまた、コラボレーションはボーナス機能ではなく、そもそもブラウザベースのエディタを構築する目的の全体であることも理解していました。すべてのスクリーンで同じように見えるドキュメントは、複数の人が一緒にそれに取り組める場合にのみ有用です。彼らは厳格モードの共同編集を追加しました。作業しているドキュメントの部分をロックし、「保存」を押すまで誰もあなたが入力していることを見られないモードです。これは、お互いの変更を上書きすることなく同時にドキュメントに取り組む必要があるチームのために設計されました。

すべての始まりとなったスプレッドシート

これは、タイムラインが通常スキップする特定のマイルストーンです。ドキュメントエディタが見出しを飾り、CeBIT 2012が公式のパブリックデビューです。しかし、ONLYOFFICEエディタの実際の起源は、それよりも奇妙で線形でないものです。

プロジェクトはドキュメントエディタではなくスプレッドシートエディタから始まりました。そしてまだCanvasを使用していませんでした。初期バージョンはサーバー上で数式を計算しており、それ自体のパフォーマンス問題を生み出しました。ドキュメントエディタが完成する前に、プロジェクトは完全に中止されました。開発責任者のAlexが回想したように、「それで終わり、もう取り組んでいませんでした。」

次に起きたことは、公式の歴史からは平滑化されてしまう種類の詳細です。チームはプロジェクトが放棄される原因となったバグを、舞台裏で静かに修正し続けました。最終的に再起動しました。そしてその後になって初めてドキュメントエディタが登場しました。その後に続くすべてのセンターピースとなる製品です。

Canvasへの賭けは大胆でした。しかしその背後にある話は、スタート、一時停止、静かな継続、そして業界のほとんどが知らなかった再起動を含んでいます。これがONLYOFFICEのエディタが実際に存在するに至った、あまり見えていないバージョンです。

エディタが最初に発売されたとき、ONLYOFFICEのマーケティングチームは製品仕様よりもポジショニングをうまく捉えた言葉を持っていました。「Google DocsとMicrosoft Officeに子供がいたら、それはTeamLabと呼ばれるでしょう。」

それはCanvasアプローチが実際に提供するものの有用な圧縮でした。Google Docsの共同作業、ブラウザベースの性質と、Microsoft Officeのフォーマット精度の組み合わせ。どちらのアプローチだけでも十分ではありませんでした。HTML5 Canvasへの賭けは、両方を同時に得るための試みでした。

2013年:プロプライエタリフォーマットとの決別

Canvasへの賭けは技術的なものでした。2013年の賭けは互換性についてのものであり、ある意味でそれはより重要なものでした。

当時、ONLYOFFICEは独自の内部フォーマット(.doct、.xlst、.pptt)を使用していました。2013年にチームはそれらを完全に廃止し、DOCX、XLSX、PPTXの背後にあるOffice Open XML標準(OOXML)へのコミットメントを表明しました。

それは明らかな選択ではありませんでした。Microsoftのフォーマットを採用することは、その複雑さ全体を受け入れることを意味しました。10年前のWordドキュメントのすべてのエッジケース、すべての難解なExcel数式、すべてのPowerPointアニメーションが正しくレンダリングされなければならなかった。なぜならユーザーはMicrosoft Officeで作成されたファイルを持ってきて、それが開くことを期待するからです。しかし代替案、ファイルを変換するようユーザーに頼むことは、行き止まりでした。世界はDOCXとXLSXで動いており、ONLYOFFICEはすでに人々が持っているドキュメントと連携する必要がありました。

その決断が、2014年1月のTechCrunchの記事でTeamLabが「Googleのオンラインコラボレーション機能とMicrosoft Wordの高品質なフォーマットを組み合わせると主張している」と書かれ、製品が「Microsoft Office 365を出直しさせたいと考えている」という見出しが掲載された理由です。

2014年:オープンソースの決断と新しい名前

2014年半ばまでに、チームは機能する一式を持っていました。ドキュメント、スプレッドシート、プレゼンテーション、ブラウザで動作し、Microsoft Officeフォーマットと互換性があり、リアルタイムの共同編集付き。最初の挫折した決断から4年後です。

2014年7月、TeamLab OfficeはONLYOFFICEにリブランドされ、ソースコードはAGPLv3のもとGitHubとSourceForgeで公開されました。only office(オフィスのみ)、名前は焦点を反映していました。ソースコードの公開により、プロプライエタリな賭けがオープンなものへと変わりました。透明で安全、誰でも検証できるようになりました。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

振り返れば、その決断はその後に続くすべての基盤でもありました。40以上の統合コネクタ、Moodleプラグイン、Confluenceコネクタ、DocSpace MCPサーバー、すべてはコードが公開された日に遡ります。

誰も語らないサーバーの書き直し

Canvas賭けが大部分の注目を集めています。しかし、ほぼ同時期に行われた2つ目の技術的決断があり、それは独自の意味で同様に急進的なものでした。

チームがブラウザでの共同編集の構築を始めたとき、新しい問題が浮上しました。エディタの話をするときに見過ごしやすい問題です。元のDocument Serverは.NETで動作していました。TeamLabの残りと同じテクノロジースタックです。リアルタイムの共同編集要件を持つブラウザベースのコラボレーション製品にとって、そのアーキテクチャは持ちこたえられないものでした。

そこで2014年、チームは4年間開発してきたサーバー全体を廃棄し、Node.jsで一から書き直しました。当時、重要なスケールでの実際の本番使用ではほとんど知られていなかったテクノロジーです。開発責任者のAlexが説明したように、「Node.jsの選択は、Canvasの選択と同様に奇妙なものでした。誰もそれで高負荷なものを書いていませんでした。」書き直しは1人のエンジニアが4ヶ月で完了しました。構築していたNode.jsのバージョンは0.10〜0.12で、チームが特有の控えめさで指摘したように「0というのは『みんな、何も真剣なことを期待しないでください』という意味です。」

同年に、同じチームが下した2つの型破りな技術的賭け。従来の選択肢に我慢が尽きたチームによって。

2016年:高速共同編集とデスクトップエディタ

さらに2つの重要なマイルストーンが、エディタの話の第一章を完結させました。

高速共同編集モードは2016年に登場し、すべてのユーザーに本当に効果的なドキュメントコラボレーションを提供することを目的としました。厳格モードが入力中に段落をロックし、「保存」時にのみ変更を表示したのに対し、高速モードはリアルタイムで変更を表示しました。ほとんどのユーザーが今日共同ドキュメント編集と結びつける動作です。ONLYOFFICEはこれで両方を持つようになりました。意図的でコントロールされた編集モードと、ライブで同時のモード。選択はチームのワークフローに依存し、テクノロジーの限界によるものではありませんでした。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

また2016年3月、ONLYOFFICEの開発者はデスクトップアプリケーションONLYOFFICEデスクトップエディターをリリースしました。Microsoft Officeのオープンソース代替として位置づけられました。ブラウザで動作していたのと同じHTML5 Canvasエディタが、Windows、Linux、macOS向けのネイティブデスクトップアプリケーションとしてパッケージ化されました。Webのみの賭けとして始まった技術的アプローチが、どこでも動作するようになりました。

モバイル:同じエディタを、どこでも

2016年のデスクトップアプリケーションはCanvasエディタをブラウザ以外に拡張しました。モバイルアプリはさらに先へ拡張し、ドキュメント作業が実際に行われていたデバイスへと届きました。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

iOSおよびAndroid向けのONLYOFFICE Documentsは、同じ編集エンジンをスマートフォンとタブレットにもたらしました。フルDOCX、XLSX、PPTX編集、リアルタイムの共同編集、変更の追跡、コメント機能。基本的な編集機能を持つ簡易ビューアではなく、タッチ向けに適応された同じエディタです。2026年の9.4リリースでは、モバイルでのMistral AIサポート、クラウドドキュメントの手動保存コントロール、AndroidスプレッドシートエディタのFOrmula、iOSでのマルチイメージ挿入が追加されました。2010年にブラウザの賭けとして始まったCanvasアプローチは、ユーザーが実際に仕事をするすべてのプラットフォームで動作するようになりました。

賭けが実際にどのようなものだったか

14年後の今日、HTML5 Canvasの決断を先見の明があると位置づけることは簡単です。当時は、代替案に我慢が尽きたチームが取った重大なリスクのように見えました。

2010年の代替案は次のとおりでした。プラグイン付きのOpenOfficeを使用する(試みたが、嫌いだった)、Google Docsのようなブラウザレンダリングアプローチを使用する(ブラウザをまたいで一貫性がなく、フォーマットが限られている)、またはデスクトップインストールを必要とするプロプライエタリなものを構築する(クラウドプラットフォームの目的を損なう)。どれも十分ではありませんでした。そこで彼らはまだ存在しない4つ目のオプションを構築しました。

技術的リスクは本物でした。Canvasベースのレンダリングは計算集約的です。複雑なテーブル、埋め込まれた画像、数式、ライブ共同編集を伴う実際のドキュメント編集に十分な速さにするには、最初のCeBITデモの後も数年間続いたパフォーマンス最適化に関する重要なエンジニアリング作業が必要でした。

ONLYOFFICEは、参加者間のわずかなリアルタイム接続を保証し、サーバー負荷を最小化するアーキテクチャを開発しました。サーバー上のパフォーマンスのボトルネックを作成することなく同時編集を処理するために設計されたそのアーキテクチャは、今日ONLYOFFICEが共同編集を処理する方法の基盤となっています。

1つのエディタから7つのスイートへ

CeBIT 2012で単一のドキュメントエディタのベータ版を発表したチームは、今日ONLYOFFICE Docsという協調スイートで7種類のエディタを出荷しています。ドキュメントエディタ、スプレッドシートエディタ、プレゼンテーションエディタ、PDFエディタ、フォームクリエーター、ダイアグラムビューア、そしてすべてに対応するAI搭載アシスタントレイヤー。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

製品はCanvas、2Dシェイプとビットマップイメージの動的でスクリプタブルなレンダリングを可能にするHTML5の一部、を使用して構築されました。ONLYOFFICE Docsで使用される基本フォーマットはOOXML(DOCX、XLSX、PPTX)です。それは変わっていません。2010年に選ばれたレンダリングアプローチは、今日ONLYOFFICEで開くすべてのドキュメントの基盤となっています。任意のブラウザで、任意のデバイスで、45のインターフェース言語のいずれかで。

賭けはシンプルでした。すべてのプラットフォームで、毎回、ドキュメントが見えるべきように正確にレンダリングするエディタを構築すること。リスクは本物でした。誰もこのようにやったことがなく、構築するには年月がかかりました。14年後、フランスのブラウザで編集していても、日本のデスクトップで、ケニアの電話で、ドイツの病院の地下サーバーから印刷していても、ドキュメントは同じに見えます。

PDFエディタ:編集できないはずだったフォーマット

元の賭けの最も重要な拡張の一つは、新しいエディタタイプではありませんでした。既存のフォーマットの変容でした。

PDFは1993年に、最終的で固定されたものとして設計されました。ドキュメントの生涯の終わりであり、その途中のステージではありません。数十年間、PDFを扱うことは、それを表示、印刷、または他のものに変換することを意味しました。ONLYOFFICEのPDFエディタはその前提に直接挑戦しました。

最初のドキュメントエディタ:シンプルだが大きなリスクを伴った決断

今日、PDFエディタは変換なしの直接テキストと画像編集、シェイプとスタンプによるフルページアノテーション、機密コンテンツの永続的なリダクション、3つのモードのデジタル署名、役割ベースのフィールドを持つ入力可能なPDFフォーム、ドラッグアンドドロップの並べ替えを含むページ管理、スキャンされたドキュメントのOCR、リアルタイムの共同アノテーションをサポートしています。編集機能が後付けされたビューアではありません。業界が読み取り専用と決めていたフォーマットのための完全な編集環境です。

PDFエディタはONLYOFFICEに追加費用なしで含まれており、Adobeの別ライセンスも、アドオンサブスクリプションも不要です。その決断はCanvasの賭けと同じ論理を反映しています。ドキュメントフォーマットが存在するなら、人々は他のすべてを扱う同じ環境でそれを適切に扱えるべきです。

読み続けましょう

この記事は、ONLYOFFICEの16回目の誕生日を記念する16本シリーズの第2回です。これからも、主要なマイルストーン、製品の決断、そしてONLYOFFICEを形作った他のステップについて学んでいきます。一緒に振り返りましょう。

第3回の記事もお楽しみに!

ONLYOFFICEの無料アカウントを登録する

オンラインでドキュメント、スプレッドシート、スライド、フォーム、PDFファイルの閲覧、編集、共同作業