AppFactorは自動化を通じてレガシーエンタープライズアプリをクラウドに移行します

AppFactorは自動化を通じてレガシーエンタープライズアプリをクラウドに移行します

技術的負債は、企業にとって陰の敵となることが多く、近代化を目指す企業は、自社のシステムスタックにどれほどの「レガシー」が残っているかに気づきその妨げとなります。そして、ほとんどの負債と同様に、通常、利息の支払いも発生します。

これは、新興の英国スタートアップ企業 AppFactor が解決しようとしている問題であり、企業がレガシー アプリケーションを自動的に再構築し、新しいクラウド ネイティブ ホームへの展開を準備できるようにするプラットフォームを提供します。

AppFactorは2021年半ばに正式に設立されたが、CEO兼創業者のキース・ニールソン氏が本格的に取り組み始めたのは1月以降で、最近、100万ポンド(130万ドル)を超えるプレシードラウンドの資金調達を完了したという。

TechCrunch Disruptのスタートアップ・バトルフィールドの一環として本日ステージに登壇したニールソン氏は、AppFactorの技術を披露し、変化が起こりつつあるこの分野における自身のスタートアップのミッションを説明した。TechCrunchは、ニールソン氏に事前にインタビューを行い、彼が考える問題の規模と、AppFactorが具体的にどのような取り組みを行っているのかを詳しく聞いた。

AppFactorチーム
AppFactorチーム。画像クレジット: AppFactor

可視性

外部の人間にとって、技術的負債はバグやシステムの遅延といった形で明らかになるかもしれません。あるいは、既存の製品の改善や新機能の導入にかかる時間の長さといった形で明らかになるかもしれません。

一方、社内にいる人たちは、IT予算支出が新しいものの開発よりもメンテナンスに偏っていることに気づくことで、自社の技術的負債をより深く理解できるかもしれません。コンサルティング会社マッキンゼーのデータによると、技術的負債は企業のIT予算全体の最大40%を占める可能性があると示唆されています。また、Stripeの別のレポートによると、開発者は平均して週の3分の1の労働時間を、新しいコードの作成ではなく既存の技術的問題への対応に費やしています。

しかし、企業が抱える技術的負債のレベルを明確に把握するのは必ずしも容易ではありません。なぜなら、負債は組織内の複数の領域やドメインにまたがっている可能性があるからです。この不透明な裏側には、過度に複雑なコード、重複したコード、あるいは明らかに質の低いコード、自動テストの欠如、セキュリティ上の脆弱性、そして全体的な設計の不備などが含まれる可能性があります。

テッククランチイベント

サンフランシスコ | 2025年10月27日~29日

「企業が抱える大きな課題は、エンタープライズグレードのアプリケーションを特定の時点で構築および設計した後、ビジネス要件とプロセスによってこれらのアプリケーションを取り巻く環境が変わり、アプリケーションとその依存関係が時間の経過とともに進化することです」とニールソン氏は述べた。

したがって、マッキンゼーが指摘するように、技術的負債とは、企業が無数のレガシー技術インフラの修正に注力する社内開発すべてに対して支払う一種の「税金」と捉えるのが最も適切でしょう。これには、新しいライブラリやフレームワーク、あるいは企業がスタックを微調整する際に発生する統合ポイントや依存関係の変更などが含まれます。最終的には、時間の経過とともに雪だるま式に膨れ上がり、手に負えないほどの混乱を引き起こす、複雑性の寄せ集めになってしまいます。

レガシーエンタープライズアプリケーションの典型的な例としては、古いMicrosoft SQLデータベース、ミドルウェア層、.NETフロントエンドなどが挙げられます。これらのアプリケーションは、物理インフラストラクチャと仮想インフラストラクチャを混在させなければ動作しません。アプリケーションとインフラストラクチャに浸透する実行中のプロセス、ライブラリ、依存関係、そして一般的なコンポーネントは、リフトアンドシフトによるクラウドネイティブな形式への変換を試みる際に、何が何であるかを把握するだけでも、膨大な手作業が必要になります。

そして、AppFactorが提供しようとしているのは、まさにこれです。企業のIT環境をスキャンしてすべてのアプリとそれぞれの依存関係を特定し、仮想アプリと物理ホストアプリを現在の環境から「分離」し、各コンポーネントとアプリレイヤーを別々のコンテナに再構築して、Kubernetesなどの最新のクラウドアーキテクチャやマネージドデータベースサービスといった新しい環境への導入準備を整えます。

「これらすべては製品 [AppFactor] によって生成され、駆動されるため、数か月や数年ではなく、数日で既存のアプリケーション資産を最新のクラウド テクノロジーに迅速に移行できます」とニールソン氏は述べています。

AppFactor: アプリモダナイゼーションモジュールの概要(11月公開予定)。画像クレジット: AppFactor

ボンネットの下

AppFactor は、サーバーに展開され、アプリケーションと依存関係を明らかにするために必要なデータを収集するスキャナー/アナライザー、IP 範囲やターゲット システムなど、スキャナー/アナライザーの動作を基本的に制御する「オーケストレーター」、および視覚的なマッピング、コンテナ化タスクなどを生成するすべてのデータ分析、機械学習 (ML) プロセスとサービスを処理する包括的な AppFactor SaaS プラットフォームの 3 つのコア コンポーネントで構成されています。

同社によると、英国に拠点を置くエンタープライズソフトウェア企業Civicaを含む複数の法人顧客と協業しているという。現在、同社のプラットフォームのうち「発見と評価」機能のみが商用利用可能となっている。しかし、同社は11月には「アプリのモダナイゼーション」モジュールのリリースも準備中だ。つまり、顧客はモダナイゼーションに適した対象を見つけ、関連するレポートや分析機能をすべて利用できるだけでなく、最終的には変革そのものを実行できるようになるのだ。

このプラットフォームの最も興味深い機能の一つは、少なくとも洗練された機能という観点から言えば、3D可視化エンジンを通じてアプリの依存関係を視覚化できるツールでしょう。将来的には、このツールを使って環境全体を視覚化できるようになるかもしれません。

「現在はインフラとプロセスレベルの視点が中心ですが、明らかにさらに深く掘り下げる余地があり、私たちはそれを構築していく予定です」とニールソン氏は語った。

興味深いことに、AppFactor はこれを VR ヘッドセットでも利用できるようにしており、TC Disrupt ブースでは Oculus を介してこの機能のデモを行っています。

「アプリの変更リスクを軽減するために事前に行う最も困難な作業の一つは、インフラ、アーキテクチャ、コードなど、あらゆる依存関係を考慮、可視化、理解することです」とニールソン氏は述べた。「この視点は、アプリケーション資産の構成と構造をきめ細かく、かつ強力な方法で可視化し、操作できるようにすることを意味します。これらのシステムの中には、通信、ライブラリ、ファイル、サービス、プロセスなどが複数の環境にまたがり、非常に複雑なものもあるため、これは知識を直感的に理解、検証、再確認できる非常に強力な方法であり、アプリケーションとその属性の将来的な進化を促進する力となります。」

AppFactor: 3D 視覚化エンジンを通じてアプリの依存関係と環境全体を視覚化します
AppFactor: 3D可視化エンジンでアプリの依存関係と環境全体を可視化します。画像クレジット: AppFactor

現状

現在のアプリモダナイゼーションツールは実質的に手作業であり、多くのリソースを消費します。Dockerなどのコマンドラインツールを使用する場合、継続的なテストが大量に必要になります。また、ツールの実行が手作業であるため、あらゆる依存関係を網羅できない可能性があります。また、5年前のVelostrata買収によって生まれたGoogleのMigrate for AnthosやAWSのApp2Containerといったツールは、企業による仮想マシン(VM)のコンテナ化をいくらか容易にしています。しかし、これらは依然として非常に手作業が多く、コマンドラインベースであるため、依存関係の詳細な可視性は必ずしも提供されておらず、物理インフラストラクチャベースのアプリもサポートされていません。

ベンチャー支援を受けた Vfunction など、モノリシック ソフトウェアからマイクロサービスへの企業の移行を支援することに重点を置いた、類似のサービスが他にも存在します。

これらの各サービスの最終的な目標は、途中で若干異なるアプローチを採用しながらも、企業が技術的負債を削減し、「時代の変化に対応」できるように支援することです。

「技術的負債には4つの柱があると考えています。インフラ、アーキテクチャ、コード、そして依存関係です」とニールソン氏は述べた。「また、マイクロサービスに適さないアプリケーションも数多く存在すると考えています。そのため、エンタープライズアプリの特性に応じて最適なアーキテクチャパターンを決定できるようにすることが私たちのビジョンです。」

AI要因

これを実現するために、AppFactorは、より複雑な「マルチホスト」アプリの変換に必要なパターンを生成するための機械学習分類を開発していると述べています。これは本質的に、複雑なアプリや特注アプリがどのような要素で構成されているかを識別するための「フィンガープリンティング」技術を開発することです。

「私たちはこれを構築するために訓練されたデータ モデルを使用しており、アプリケーション パターンを識別するのに役立つ多数の属性とデータポイントを採用しています」とニールソン氏は述べています。

さらに、ニールソン氏は、Kubernetesデプロイメント用のYAML(設定ファイルを作成するための人間が読めるデータシリアル化言語)を生成するための大規模言語モデル(LLM)を含む、他の多くのAIユースケースを実験していると述べた。

「コード生成に関しては将来的なユースケースがいくつかありますが、まだそこまでには至っていません」とニールソン氏は付け加えた。