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

最近 Eagle を追ってくださっている方は、以前より少し静かになったと感じているかもしれません。

大きな Blog 更新から数か月が経ちました。その間も Eagle V4 のメンテナンス、問題の修正、互換性の改善、必要なアップデートは継続してきましたが、大きな新機能や発表が少なかったことも事実です。

外から見れば、不安を感じるのも当然だと思います。実際に、

「Eagle の開発は今も続いているのでしょうか？」

という質問をいただくこともありました。

答えは、もちろん Yes です。

実際には、この数か月で開発リソースのかなりの部分が、より大きな取り組みへと移っています。

Eagle V5 です。

これまで V5 について頻繁に発信してこなかったのは、現在も開発途中であり、まだ完成していない計画を早い段階で約束のように伝えたくなかったためです。

今回の記事はリリース告知ではなく、現時点で正式なリリース日をお知らせするものでもありません。

ただ、なぜこれほど時間がかかっているのか、私たちが実際に何を作っているのか、そしてなぜ V5 がここまで大規模な再構築になったのかについては、そろそろきちんと説明すべきだと考えました。

Eagle V4 のメンテナンスは今後も続きます

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

Eagle V4 を放棄したわけではありません。

現在も V4 の安定性、OS や環境との互換性、日常利用に影響する問題の修正を続けています。

また、もともと V5 の一部として検討していたアイデアの中には、Plugin として先に V4 へ提供できたものもあります。

AI Search、AI Action、Eagle Skill、Eagle MCP などがその例です。

これらの機能を未来の大型アップデートまで意図的に保留するのではなく、現在の Eagle ユーザーへ先に提供できる方法があるなら、できるだけ早く届けたいと考えています。

一方で、長年開発を続ける中で、もう一つ明確になってきたことがあります。

現在の Eagle の基盤には、これ以上拡張し続けることが難しい部分が増えてきました。

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

これから私たちが解決したいことの中には、単に「新しい機能を追加する」だけでは解決できない問題があります。

製品の土台そのものを見直す必要がある問題です。

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

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

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

現在の Eagle は、一つのデスクトップアプリケーションを中心に動くよう設計されています。

画面に表示されるインターフェース、アプリケーション内部の処理、ライブラリの状態、さまざまなデータ操作が密接に結びついています。

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

しかし、複数ウィンドウ、複数ユーザー、複数アカウント、別のデバイス、ブラウザからのアクセス、AI Agent、そして将来的な iPad やその他のモバイルデバイスを考えると、この構造が徐々に大きな制約になります。

こうした問題の中には、V4 に Plugin を追加するだけでは本質的に解決できないものもあります。

例えば将来、一つのライブラリを複数のユーザー、自動化処理、さらには複数の AI Agent が操作するようになれば、「誰が操作しているのか」「何を許可されているのか」「何を変更したのか」「その変更をどう記録するのか」を、システム全体として理解できる必要があります。

こうした仕組みは、最初から製品の中核に存在していなければ、後からきれいに追加することが難しいものです。

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

V5 では、ライブラリを実際に管理する部分と、ユーザーが操作する画面を分けて設計します。

少し技術的に聞こえるかもしれませんが、考え方はシンプルです。

Eagle の素材はこれまで通り自分のコンピューターに保存でき、そのコンピューター自身が Eagle ライブラリを管理できます。

多くのユーザーにとって、日常の使い方が大きく変わるわけではありません。

これまでと同じように Eagle を起動し、普通のデスクトップアプリケーションとして利用できます。

変わるのは、その内部にどれだけ新しい可能性を持てるかという点です。

自分のコンピューターをライブラリの中心にできます

V5 について、アカウント、複数デバイス、同期、Server といった言葉を使うと、「Eagle が公式のクラウドサービスを始めるのではないか」と受け取られる可能性があります。

しかし、そういう意味ではありません。

私たちが現在構築している V5 の仕組みは、ライブラリを Eagle のクラウドへ移すことを前提としていません。

V5 でも、ユーザー自身が管理するデータを中心に設計します。

デフォルトでは、素材は自分のコンピューターやストレージに置いたままにでき、ライブラリを管理する Eagle の中核部分もそのコンピューター上で動作できます。

一般のユーザーは、そのコンピューターを特別な「Server」として意識する必要はありません。

これまでと同じように Eagle を起動して使えば大丈夫です。

違いは、必要に応じて、将来的に同じライブラリへより柔軟な方法で接続できるようになることです。

例えば、少しネットワークの知識があるユーザーであれば、自分のメインコンピューター上にある Eagle ライブラリへ、同じネットワーク上の別のコンピューターやデバイスから接続できるようにすることも考えられます。

より詳しいユーザーであれば、VPN や固定 IP など、自分で選んだ方法で外部からアクセスできる環境を作ることもできます。

その場合、ライブラリの中心になるのはユーザー自身のコンピューターです。

例えば小さなチームであれば、一台のコンピューターにライブラリを置き、許可されたメンバーがそこへ接続する形も考えられます。

自宅で、自分が管理するコンピューターを使って同じことをすることもできます。

重要なのは、

こうした使い方のために、Eagle 公式のクラウドへライブラリ全体をアップロードする必要はないということです。

私たちが増やしたいのは選択肢であり、すべてのデータを私たちの Server へ移すことではありません。

アカウントはクラウド保存を意味しません

V5 では、アカウントの仕組みも必要になります。

理由はシンプルです。

複数の人やデバイスが同じライブラリへ接続できるようになると、「誰がアクセスしているのか」「その人に何を許可するのか」を管理する必要があるからです。

そのためにアカウントを使います。

しかし、

Eagle のアカウントを持つことが、素材を Eagle のクラウドへ保存することを意味するわけではありません。

この二つは別の話です。

アカウントは「誰がアクセスできるか」を管理します。

素材そのものは、自分のコンピューター、ハードディスク、NAS、その他自分で管理するストレージへ置いたままにできます。

同じように、「同期」や「複数デバイス」という言葉も、複数のデバイスから同じ Eagle ライブラリを利用できる可能性を意味しています。

すべての Eagle ライブラリを Eagle 公式のクラウドへアップロードする計画を発表しているわけではありません。

サブスクリプションへの移行を意味するものでもありません

アカウントや複数デバイス、新しいアーキテクチャについて説明すると、「Eagle は将来サブスクリプション型になるのではないか」と心配されることもあります。

しかし、今回の変更はそのためのものではありません。

Eagle V5 はサブスクリプションサービスを前提として設計しているわけではなく、Eagle をサブスクリプション中心の製品へ移行することも、私たちが望んでいる方向ではありません。

今回の再設計で実現したいのは、Eagle をどのように使うか、データをどこへ置くか、どのデバイスやツールから素材へアクセスできるようにするかについて、ユーザーにより多くの選択肢を提供することです。

Eagle を SaaS に作り変えたり、ユーザーのデータを私たちのクラウドへ移したりすることが目的ではありません。

V4 と V5 は根本的に異なる仕組みになります

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

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

V5 は根本的に異なる新しい仕組みの上に構築されています。

そのため、V4 の現在の構造では難しかった問題に対して、より自由な設計ができるようになります。

一方で、V4 と V5 は内部的には直接互換ではありません。

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

既存の V4 ライブラリを V5 へ移すためのツールを提供する予定です。

できる限り分かりやすく、信頼できる移行方法を用意したいと考えていますが、実際にはデータの変換が必要になる場合があり、一部の使い方については新しい仕組みに合わせた調整が必要になる可能性もあります。

根本的に異なる二つのシステムが完全に同じものとして扱えるかのように伝えるよりも、この点については今から正直に説明しておくべきだと考えています。

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

私たちは単に新しいシステムを作っているだけではありません。

約 10 年にわたって蓄積されてきた Eagle のライブラリ、データ、そしてユーザーの使い方を、安全に新しい仕組みへ移す方法についても考える必要があります。

開発時間の多くは、目に見えない部分に使われています

長い間新しいメジャーバージョンが開発されていると、大量の新機能を作っているように見えるかもしれません。

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

これまで一体になっていたさまざまな機能を整理し、Eagle 内部の各部分がどのように連携するかを作り直し、ライブラリの管理方法そのものを見直しています。

こうした作業は、スクリーンショットで紹介してもあまり派手には見えません。

数か月かけて開発した結果、画面だけを見るとほとんど変わっていないことさえあります。

しかし、その内部ではまったく違う仕組みが作られています。

そして、その基盤ができれば、これまで非常に難しかった機能も自然に作れるようになります。

複数ウィンドウをもっと自然に扱えるようになります

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

現在の Eagle は、基本的に一つのアプリケーション画面を中心に設計されています。

本当に使いやすい複数ウィンドウを実現するには、単に画面をもう一つ開けばよいわけではありません。

それぞれのウィンドウが同じライブラリの状態を正しく共有し、変更を反映し、互いに邪魔しないように動く必要があります。

V5 では、複数のウィンドウが同じライブラリを自然に利用できるようになります。

例えば、一つのウィンドウで参考素材を表示したまま、別のウィンドウで整理作業をするといった使い方も、より自然に実現できます。

これは小さな例ですが、私たちが個々の機能ではなく、まず製品の基盤そのものを作り直している理由をよく表しています。

複数ユーザーや複数アカウントにも対応しやすくなります

同じ変更によって、複数ユーザーや複数アカウントにも、より自然に対応できるようになります。

これまで Eagle は、基本的に一人のユーザーが自分のローカルライブラリを利用する製品として作られてきました。

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

一方で、個人用と仕事用を分けたい場合や、将来的に複数のユーザーが同じライブラリを利用したい場合もあります。

例えば、一台のコンピューターにライブラリを置き、許可された複数のユーザーがそこへ接続する形も考えられます。

そのコンピューターはオフィスに置いても、自宅に置いても構いません。

重要なのは、

そのコンピューターとデータをユーザー自身が管理できるということです。

もちろん、考えられるすべての共同作業機能が V5 の最初のバージョンですぐに提供されるわけではありません。

新しい基盤によって、こうした機能を将来きちんと作れるようになる、という意味です。

重要な変更には、すべて履歴が残るべきです

一つのライブラリを複数の人、自動化処理、さらには AI Agent が操作できるようになると、もう一つ重要な問題が出てきます。

誰が、いつ、何を変更したのか。

例えばチームの中で User A と User B が作業していて、同時に Agent A と Agent B も素材整理を手伝っているとします。

誰かがタグを変更したり、ファイルをまとめて移動したり、カスタム項目を書き換えたり、コンテンツを削除したりするかもしれません。

システムが「何かが変わった」ことしか分からず、その変更を誰が行ったのか分からないのであれば、利用者や自動化が増えるほどライブラリは管理しにくくなります。

そのため V5 では、Audit Log（操作履歴） を基盤の重要な一部として扱います。

どのユーザーや Agent が、いつ、どの内容に対して、どのような操作を行ったのかを記録できるようにします。

これは問題が発生したときに原因を調べるためだけのものではありません。

安全な共同作業、自動化、AI Agent を実現するための重要な土台でもあります。

将来 AI が大量の素材を整理したり、タグ付けしたり、変更したりするようになったとき、ユーザーが最終結果しか見られない状態にはしたくありません。

AI が何をしたのかを確認できるべきだと考えています。

重要な操作に明確な記録が残ることで、将来的にはより詳しい変更履歴、元に戻す仕組み、安全制御、あるいは人による確認が必要な操作なども、その上に構築しやすくなります。

これも、V4 に Plugin を一つ追加するだけでは十分に解決できない問題です。

データを管理し、変更を実行する Eagle の中核部分に最初から存在する必要があります。

人それぞれの方法で素材を整理できるようにする

もう一つ、私たちが長い間重要だと考えてきた方向があります。

カスタム項目です。

Eagle は非常に幅広い分野のユーザーに使われています。

デザイン素材を管理する人もいれば、写真、動画、研究資料、商品情報、チーム内の素材ライブラリとして利用している人もいます。

同じユーザーであっても、プロジェクトごとに必要な情報がまったく違うこともあります。

例えばデザインチームなら、「クライアント名」「プロジェクトの進行状況」「ライセンス状態」といった情報を記録したいかもしれません。

写真を扱う人なら、「撮影者」「撮影場所」「使用期限」などが重要かもしれません。

他にも、ユーザー独自のワークフローに必要な情報があります。

私たちがすべてのユーザーに対して、必要な項目をあらかじめ決めることはできません。

そこで V5 では、Custom Fields（カスタム項目） を正式に追加し、それぞれのユーザーが自分の作業方法に合わせて、素材へ追加の情報を持たせられるようにします。

一つの機能に見えるかもしれませんが、私たちにとってこれはもっと大きな方向性を表しています。

Eagle は、すべての人に同じ固定された整理方法を強制するのではなく、ユーザー、チーム、さらにはプロジェクトごとの違いに対応できる柔軟性を持つべきです。

こうしたカスタム情報がライブラリの正式な一部になれば、検索やフィルター、自動化にも利用できるようになり、将来的には AI Agent もその意味を理解して利用できるようになります。

例えばチームが「プロジェクト状況」「レビュー結果」「ライセンス期限」といった項目を独自に作った場合、将来は人がそれらを使って素材を整理するだけでなく、権限を与えられた自動化や Agent も、チーム独自のルールに従って処理できるようになります。

私たちが V5 で目指しているのは、すべての人に一つの正しいワークフローを決めることではありません。

さまざまな使い方に対応できる、十分に柔軟な基盤を作ることです。

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

V5 の新しい構造によって、Eagle は一つのデスクトップ画面だけに縛られなくなります。

Windows や macOS の Eagle は、これからも多くのユーザーにとって中心的な使い方になるでしょう。

しかし将来的には、同じネットワーク上のブラウザからライブラリへアクセスできるようになる可能性もあります。

自分で外部アクセスの環境を設定したユーザーであれば、別の場所から接続することも考えられます。

将来的な iPad アプリやその他のモバイルデバイスについても、同じ基盤を利用できます。

改めて強調すると、これらを実現するために Eagle 公式のクラウドサービスが必須になるわけではありません。

ライブラリの中心は、ユーザー自身のコンピューターのままでも構いません。

ここで挙げているものは、新しい基盤によって可能になる方向性の例です。

V5 の最初のリリースですべて提供すると約束しているわけではありません。

AI Agent も Eagle を利用する一つの方法になります

Eagle が最初に作られた 2017 年にはほとんど存在しなかったものの一つが、AI Agent です。

この一年、Eagle MCP や Eagle Skill を通じて、私たちはすでにこの方向を少しずつ試しています。

現在でも AI は Eagle の素材を検索したり、内容を理解したり、一部の操作を行ったりできます。

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

人と AI が一緒に作業することが増えていく中で、素材ライブラリは画面を見ている人だけが使えるものではなく、許可されたツールや AI も安全に利用できる仕組みを持つべきだと考えています。

V5 はそのためのより良い基盤になります。

将来的には、デスクトップ版 Eagle、ブラウザ、別のデバイス、AI Agent など、さまざまな方法から同じ Eagle ライブラリを利用できるようになります。

しかし私たちにとって重要なのは、単に「AI が Eagle を操作できる」ことではありません。

AI の操作も、人の操作と同じように、誰が行ったのかを識別でき、権限を制御でき、履歴を確認できるべきです。

Agent が 100 件の素材を変更した場合、どの Agent が、いつ、何を変更したのかをシステムが把握できる必要があります。

異なる Agent が異なる役割を持つなら、それぞれが許可された操作だけを行えるようにするべきです。

だからこそ、アカウント、権限管理、Audit Log、Custom Fields、新しいデータ構造は、それぞれ独立した機能ではありません。

これらはすべて、V5 に必要だと考えている新しい基盤の一部です。

私たちは、Eagle の中に単純な AI Chat を一つ追加することよりも、その方がはるかに重要だと考えています。

人、デバイス、自動化ツール、AI Agent が、明確で管理可能なルールのもとで同じ素材を扱える基盤として、Eagle 自体を進化させたいと考えています。

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

新しい基盤によってできることを説明すると、それらすべてが V5 の確定機能のように聞こえてしまうことがあります。

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

複数ウィンドウ、複数ユーザー、複数アカウント、ブラウザからのアクセス、iPad、モバイルデバイス、外部からのアクセス、AI との連携、新しい共同作業の形などは、V5 の基盤によって実現しやすくなる可能性の例です。

V5 の最初のバージョンですべて提供する機能リストではありません。

現在の最優先事項は、まず基盤をしっかり完成させることです。

新しい仕組みが安定していること、Eagle の中心であるライブラリ体験が高速で信頼できること、そして既存の V4 ユーザーが安心して V5 へ移行できる方法を用意すること。

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

V5 はいつリリースされるのか？

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

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

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

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

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

それまでも Eagle V4 のメンテナンスは継続します。

また、V5 を待たなくても提供できる機能については、可能なものから既存ユーザーへ届けていきたいと考えています。

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

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

むしろ、大きな開発作業の多くが、今は画面から見えない部分に移っているからです。

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

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

もちろん、それにはトレードオフもあります。

V5 は V4 とは根本的に異なる仕組みになるため、V4 から V5 への移行は、何も意識せずに完了する単純なアップデートではありません。

しかし、その大きな変更があるからこそ、複数ウィンドウ、複数ユーザー、Custom Fields、完全な操作履歴、より多くのデバイス、AI Agent、そしてこれまで難しかった新しい使い方へ向けた基盤を作ることができます。

そして、これらすべてが変わっても、一つの大切な考え方は変わりません。

Eagle はこれからも、ユーザー自身が所有するデータと、ユーザー自身が管理できるデバイスやストレージを中心に動く製品でありたいと考えています。私たちが増やしたいのは、そのデータへアクセスし、管理し、活用する方法であって、データのコントロールをユーザーから取り上げることではありません。

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

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

V5 は、その次の段階を支える新しい基盤として、現在も開発が進んでいます。