Eagle V5 開発中:この数か月、私たちは何を作っていたのか

Eagle V5 開発中:この数か月、私たちは何を作っていたのか

ここ最近 Eagle をチェックしてくださっている方は、以前と比べて少し静かになったと感じているかもしれません。

前回の大きな Blog 更新から、すでに数か月が経ちました。その間も Eagle V4 のメンテナンスを続け、不具合の修正や互換性、安定性の改善、必要なアップデートを行ってきましたが、大きな新機能や新しいバージョンについてお知らせする機会はあまりありませんでした。

外から見れば、そう感じられるのも無理はないと思います。

実際、最近ではユーザーの皆さんから、こんな質問をいただくことも増えてきました。

「Eagle は今も開発されているのでしょうか?」

答えは、もちろん「はい」です。

むしろ現在は、開発リソースのかなりの部分を、もっと大きな取り組みである Eagle V5 に移しています。

これまで V5 についてあまり詳しくお話ししてこなかったのは、現在も開発の途中にあり、まだ確定していない計画を約束として伝えたくなかったからです。この記事はリリースのお知らせではありませんし、現時点でリリース日を発表する段階でもありません。

それでも今、私たちが何に取り組んでいるのか、なぜこれほど時間がかかっているのか、そしてなぜ Eagle の大部分を作り直す必要があると考えたのかについて、一度きちんとお話ししておきたいと思います。

Eagle V4 の開発も続いています

V5 についてお話しする前に、まず一つ明確にしておきたいことがあります。

Eagle V4 の開発やメンテナンスが終了したわけではありません。

現在も V4 の安定性や互換性の改善を続け、日常的な利用に影響する問題への対応を行っています。また、もともと V5 の一部として検討していた機能の中には、すでにプラグインという形で V4 に提供しているものもあります。

AI Search、AI Action、Eagle Skills、Eagle MCP などがその例です。これらの技術が実用段階に入るにつれて、将来の大型アップデートまで待っていただく必要はないと判断し、既存の Eagle ユーザーにも早い段階で利用していただける方法を選びました。

一方で、長年 Eagle を開発し続ける中で、次第にはっきりしてきたこともあります。

それは、現在の Eagle の基盤をそのまま拡張し続けるだけでは、実現が難しいことが増えてきたということです。

Eagle が最初にリリースされたのは 2017 年です。それから現在までに、扱われるライブラリははるかに大きくなり、ワークフローも複雑になりました。そして、ユーザーが素材へアクセスし、活用する方法そのものも大きく変化しています。

私たちが次に実現したいことの中には、もはや単純な「機能追加」だけでは解決できないものがあります。

アーキテクチャそのものを見直す必要がある問題です。

なぜ V5 はゼロからの再構築になったのか

V5 の構想を始めた当初から、ここまで大規模な再構築になると考えていたわけではありません。

しかし開発を進めるにつれて、私たちが直面していた多くの制約が、Eagle の初期設計における前提そのものから生まれていることが分かってきました。

現在の Eagle では、多くの役割がデスクトップアプリケーションと密接に結びついています。インターフェース、アプリケーションのロジック、ライブラリの状態、データ操作などは、基本的に一つのデスクトップアプリケーションがすべての中心になることを前提として設計されてきました。

この仕組みは、長い間 Eagle を支えてきました。

しかし、複数ウィンドウ、複数ユーザー、複数アカウント、さまざまなデバイス、ブラウザからのアクセス、AI エージェント、そして将来的な iPad やその他のモバイルデバイスへの展開を考えると、この前提が徐々に大きな制約になってきます。

これらすべてを現在のアーキテクチャの上に追加し続けることは、本来そのような用途を想定していなかった設計を、延々と回避しながら開発することを意味します。

そこで私たちは、現在の基盤を無理に拡張し続けるのではなく、新しい基盤そのものを作ることにしました。

Eagle V5 では、素材ライブラリを管理するコアサービスと、それに接続するアプリケーションやインターフェースを分離する、新しいアーキテクチャを採用しています。

一見すると内部的な技術変更にすぎないように思えるかもしれません。

しかし私たちにとっては、これは Eagle が将来どのような製品になれるのかを大きく変えるものです。

V4 と V5 は根本的に異なるアーキテクチャです

ここで、新しい基盤を構築することによって生じる重要な点についても、あらかじめ率直にお伝えしておきたいと思います。

Eagle V5 は、Eagle V4 の内部を少しずつ置き換えたものではありません。

V5 は、根本的に異なる新しいアーキテクチャの上に構築されています。

これによって、V4 の現在の基盤では難しかった問題に対して、より自由な設計ができるようになります。しかし同時に、アーキテクチャという観点では、V4 と V5 に直接的な互換性があるわけではありません。

そのため、将来 V5 が利用可能になった際、V4 からの移行は単に新しいバージョンをインストールして、そのまま何も変わらず使い続けられるというものではありません。

もちろん、既存の V4 ライブラリを V5 にインポートし、移行するためのツールを提供する予定です。できる限り分かりやすく、信頼できる移行プロセスを用意することが私たちの目標ですが、実際の移行ではデータの変換が必要になる可能性があり、一部のワークフローや動作については、新しいアーキテクチャに合わせた変更が必要になる場合もあります。

根本的に異なる二つのシステムを完全に互換にできるかのように伝えるよりも、この点については今の段階から明確にしておくべきだと考えています。

そして、これも V5 の開発に時間がかかっている理由の一つです。

私たちは単に新しいシステムを作っているだけではありません。約 10 年にわたって蓄積されてきた Eagle のライブラリ、データ、そしてユーザーのワークフローを、できるだけ大きな負担をかけずに新しい環境へ移行できる方法についても、同時に考える必要があります。

開発時間の多くは、この基盤づくりに費やされています

開発期間が長くなると、「きっと大量の新機能を作っているのだろう」と思われるかもしれません。

しかし実際には、この数か月の開発時間の多くは、ユーザーの目には直接見えない部分に使われています。

これまで密接に結びついていた役割を分離し、Eagle 内部の各部分がどのように通信するかを作り直し、ライブラリの管理方法を再設計し、複数のアプリケーションやクライアントが同じ素材ライブラリを安全に扱える基盤を構築しています。

こうした作業は、スクリーンショットで紹介してもあまり面白く見えないかもしれません。

数か月かけて開発した結果、表面上は以前とほとんど同じに見えることさえあります。

しかし、その内部ではシステムそのものが大きく変わっています。

そしてこの基盤が整うことで、これまでなら大量の個別対応が必要だった機能も、より自然な形で実現できるようになります。

一つのウィンドウに縛られないための基盤

分かりやすい例の一つが、複数ウィンドウです。

現在のアーキテクチャでは、Eagle は基本的に一つのデスクトップアプリケーションが一つのライブラリを管理することを前提として設計されています。

複数ウィンドウをきちんとサポートするには、単にもう一つ画面を開けばよいわけではありません。それぞれのウィンドウが同じ状態を共有し、変更を正しく反映し、操作を調整しながら、お互いに干渉しないようにする必要があります。

V5 のアーキテクチャでは、アプリケーションのインターフェースそのものがライブラリを唯一管理する存在ではなくなります。

複数のウィンドウを、同じワークスペースへ接続する異なるクライアントとして扱えるようになります。

これによって、本格的なマルチウィンドウのワークフローが、これまでよりずっと現実的になります。

例えば、一つのウィンドウでは参考資料を表示したまま、別のウィンドウで素材を整理したり、一つの画面の状態を何度も切り替えることなく、異なるビューを並行して利用したりできるようになります。

これは比較的シンプルな例ですが、個々の機能を V4 に追加し続けるのではなく、なぜ私たちがアーキテクチャそのものにこれほど時間をかけているのかをよく表しています。

複数ユーザーと複数アカウントも、より現実的になります

同じアーキテクチャの変化によって、複数ユーザーや複数アカウントを扱うための基盤も大きく改善されます。

これまで Eagle は、基本的に一人のユーザーが一つのアプリケーションからローカルライブラリを利用することを中心に設計されてきました。

このシンプルさは Eagle の大きな強みであり、私たちもそれを失いたいとは考えていません。

しかし一方で、個人用と仕事用の環境を切り替えたい、異なるアカウントで別々のライブラリへアクセスしたい、あるいは将来的に複数のユーザーやアプリケーションが権限を管理しながら同じワークスペースを利用したい、といったニーズもあります。

ユーザー情報、アプリケーションの状態、ライブラリ操作が密接に結びついた現在の仕組みでは、こうした問題をきれいに解決することは簡単ではありません。

V5 では、それらを考えるためのずっと良い出発点を作ることができます。

もちろん、これは考えられるすべての共同作業機能が V5 の最初のリリースですぐに登場する、という意味ではありません。

重要なのは、アーキテクチャそのものが、こうした可能性を妨げなくなることです。

デスクトップの外にも可能性が広がります

このアーキテクチャによる変化の中でも、特に大きな可能性の一つは、Eagle を「すべてが一つに入ったデスクトップアプリケーション」としてだけ考える必要がなくなることです。

コアとなるワークスペースがインターフェースから独立して動作できれば、さまざまな種類のクライアントがそこへ接続できます。

Windows や macOS のアプリケーションも、一つのクライアントです。

ブラウザも、将来的には別のクライアントになれるかもしれません。

iPad アプリケーションも同様です。

そして同じ基盤があれば、より広い意味でのモバイル対応も、現在よりずっと現実的になります。

ここで私たちが意図的に「可能性があります」「将来的には」といった表現を使っていることにも注意してください。

この記事でお伝えしているのは、新しいアーキテクチャによって可能になる方向性であり、ここで挙げたすべてのプラットフォームを V5 と同時にリリースすると約束するものではありません。

それでも、これこそが私たちが基盤の再構築にこれほど多くの時間を投資している理由の一つです。

「現在のデスクトップ向けアーキテクチャに、どうやって iPad 版を組み込むか」と考えるのではなく、最初から異なるインターフェースやデバイスが存在することを前提としたシステムを設計できるようになります。

AI エージェントも、一つのクライアントになります

そしてもう一つ、2017 年に Eagle を最初に設計した頃には、ほとんど存在していなかった種類のクライアントがあります。

AI エージェントです。

この方向については、すでに Eagle MCP や Eagle Skills を通じて少しずつ取り組み始めています。

現在でも、AI システムが Eagle に保存された素材を検索し、理解し、操作するための仕組みを提供しています。

しかし私たちは、これはまだ始まりにすぎないと考えています。

人間と AI エージェントが一緒に作業することが当たり前になっていく世界では、素材ライブラリは画面を見ている人間だけが理解できるものである必要はありません。他のツールや AI エージェントも、同じ情報へ構造化された方法でアクセスし、許可された操作を実行できるべきです。

V5 のアーキテクチャでは、これをより自然な形で実現できます。

デスクトップアプリケーション、別のデバイス、ブラウザ上のインターフェース、AI エージェント。これらすべてを、同じワークスペースへ接続する異なるクライアントとして考えられるようになります。

私たちにとって、これは単に Eagle の中に AI チャットを追加するよりも、ずっと重要な方向性です。

私たちは Eagle 自体を、ユーザーが選んださまざまなツールから活用できる、より良い基盤にしていきたいと考えています。

すべてが一度に登場するわけではありません

アーキテクチャの可能性について話していると、将来実現できることのすべてが、すでに決定した機能のように聞こえてしまうことがあります。

しかし、この記事はそのような発表ではありません。

複数ウィンドウ、複数アカウント、さまざまなプラットフォーム、ブラウザからのアクセス、モバイルデバイス、AI との連携、新しい共同作業の形などは、V4 のアーキテクチャ上の制約がなくなることで、これまでより大幅に実現しやすくなる可能性の例です。

これらを、V5 の最初のリリースですべて提供する機能リストとして受け取らないでください。

現在、私たちが最も優先しているのは、あくまでその基盤です。

新しいアーキテクチャが十分に信頼できること、Eagle の中心であるライブラリ体験が高速で安定していること、そして既存の V4 ユーザーに対して、自信を持って提供できる移行方法を用意すること。

まずはそこをしっかり完成させる必要があります。

その上で初めて、新しい基盤の可能性を本格的に広げていけると考えています。

では、V5 はいつリリースされるのか?

おそらく、多くの方が最も知りたいのはこの点だと思います。

現時点では、まだ発表できるリリース日はありません。

V5 にはまだ多くの開発作業が残っています。そして現在の V5 は、一般的なメジャーアップデートよりもはるかに大きなアーキテクチャ変更になっているため、無理に期限を設定し、その期限に間に合わせるために基盤の品質を妥協することはしたくありません。

皆さんにとって意味のある、具体的な情報をお伝えできる段階になったときに、改めて詳しくお知らせします。

それまでも Eagle V4 のメンテナンスは継続します。また、V5 を待たなくても提供できる機能については、すべてを将来のリリースまで保留するのではなく、可能なものから既存の Eagle ユーザーへ届けていきたいと考えています。

Eagle は今も前に進んでいます

最近の Eagle が以前より静かに見えていたとしても、それは開発が止まっているからではありません。

むしろ、これまで表から見えていた開発の多くが、今は表面から見えにくい部分へ移っているからです。

Eagle を約 10 年にわたって開発してきた中で、私たちは、これから実現したいことに対して、同じ基盤の上に機能を追加し続けるだけでは十分ではない段階に来たと判断しました。

だからこそ今、新しい基盤を作っています。

もちろん、それにはトレードオフもあります。V5 は V4 とは根本的に異なるアーキテクチャになるため、V4 から V5 への移行は、何も意識せずに完了する単純なアップデートではありません。実際の移行には、データの変換や新しい仕組みへの適応が必要になる可能性があります。

しかし、その大きな変化があるからこそ、これまで Eagle が抱えていた古い制約を見直し、複数ウィンドウ、複数ユーザーや複数アカウント、より多くのデバイスやプラットフォーム、AI エージェント、そして Eagle が最初に設計された頃には現実的ではなかったさまざまな可能性に向けて、新しい基盤を作ることができます。

まだ多くの開発作業が残っています。

それでも、Eagle の開発は今も確実に続いています。

そして V5 は、これからの Eagle を支える次の基盤として、現在も開発が進んでいます。