Atlassian Connectのサポートは2027年1月31日に終了：独自のJiraとConfluenceのアプリをForgeへ移す

緑のジグソーパズルのピースの中に置かれた赤いピース1つ

2027年1月31日、Atlassianは、古いJiraやConfluence Cloudのアプリの多くが使っているフレームワークであるConnectのサポートを終了します。Atlassianによれば、その日から「Connectについては重大なセキュリティ脆弱性にのみ対処する」とし、Connectのまま動いているプライベートアプリは「サポートされなくなり、正常に動かなくなる可能性がある」と述べています。

サイト上のアプリがすべてAtlassian Marketplaceから入手したものなら、これはベンダーの仕事で、ほとんどのベンダーはすでに対応を終えています。Atlassianは2026年8月に、「有料アプリのシートの95%以上がForgeに移行した」と報告しています。

この記事は、もう一方のケースのためのものです。社内の開発者、外部の業者、パートナーなど、誰かが自社のために作ったJiraやConfluenceのアプリがある場合です。購入したのではなく、リンクからインストールしたものです。社外の誰もそれを移してはくれず、作った人ももういないかもしれません。

サポート終了が意味すること、意味しないこと

公表された停止日はありません。AtlassianはConnectのアプリが2027年2月1日に動かなくなるとは言っておらず、当初のスケジュールの発表では、「Connectのアプリをインストールしている顧客がアプリへのアクセスを失うことはない」としていました。

これを安全だと読まないでください。変わるのは、Atlassianの誰もConnectの面倒を見なくなることです。

修正されるのは重大なセキュリティ脆弱性だけです。重大でないバグは残ります。
「Connectの機能の廃止は、ほとんど予告なしに行われる」。
Atlassianのサポートは「そのレガシー技術が原因の問題を修正することはできない」。
Atlassian自身の言葉では、「サポート終了後、Connectが安定した状態にとどまることはない。不具合は増え、互換性の隙間は広がる」。

つまりリスクは崖ではなく、少しずつ進むものです。ありそうな障害はこうです。Jiraがあるページを変え、Connectのパネルが表示されなくなり、問い合わせる相手が誰もいない。そのアプリが財務の承認フローや顧客向けのサービスデスクの中にあれば、それに頼っている人たちから知らされることになります。

すでに起きたこと

1月の日付は、2025年に始まった一連の流れの最後の段階です。

2025年9月：MarketplaceがConnectの新規アプリの受け付けを停止しました。
2026年3月31日：アップデートが凍結されました。Atlassianの独自アプリ向けのガイダンスははっきり書いています。その日以降、「Connectのアプリにアップデートをプッシュすることはできなくなる」。自社のサーバー上のコードは引き続き自由に変更できますが、アプリがJiraやConfluenceに宣言している内容（モジュール、スコープ、Webhook）は固定されます。
2026年3月：スケジュールでは、「Connected Appsから新しいConnectのプライベートアプリをインストールする機能は利用できなくなる」ともされていました。アンインストールは後戻りできないものとして扱ってください。何が壊れるかを見るためだけに、Connectのプライベートアプリを削除してはいけません。
2026年8月：Atlassianはサポート終了を2026年12月から2027年1月31日に移しました。1か月延びただけです。さらなる延期を当てにしないでください。
現在：AtlassianはAtlassian Administrationで警告の表示を進めており、Connectのままのプライベートアプリには「LEGACYのステータスが付く」としています。

プライベートアプリを見つける

まずAtlassian AdministrationのConnected Appsのページを開きます。LEGACYと表示されているものは、Connectで動いています。Atlassianは、プライベートアプリを見分けるためのチェックリストを示しています。次の項目のほとんどが当てはまるなら、自社で移すべきアプリです。

Marketplaceからではなく、直接のリンクか開発者モードでインストールされた。
Marketplaceの検索に表示されない。
自社の組織がソースコードを管理している。
ライセンス情報がなく、インストール先として載っているのが自社の組織だけ。
Connected Appsのページに関連リンクのサイドバーがない（Marketplaceのアプリにはある）。

Atlassianは目安も加えています。5年以上前に作られた独自のクラウドアプリはConnectのアプリである可能性が高く、ConnectのアプリはAtlassianの外でホストされており、「一般的にはHeroku、AWS、Azure、Google Cloud Platformのようなサービス」の上にあります。アプリの View app details のリンクを開くと、Atlassianが把握している限りの開発者が表示されます。

誰かがコードに触れる前に、アプリごとに5つのことを書き留めてください。

何をするものか、誰が使っているか。業務の責任者が見て分かる1文で。
ソースコードがどこにあるか。 自社で管理しているリポジトリか、業者のノートパソコンか、どこにもないか。
どこで動いていて、ホスティング費用を誰のアカウントが払っているか。 サーバーが以前の業者のクラウドアカウントにあるなら、それは1月ではなく今日のリスクです。
ディスクリプター。 Connectのアプリはどれも、あるURLでatlassian-connect.jsonファイルを配信しています。そこにはアプリが使うすべてのモジュール、スコープ、Webhookが載っており、手に入る中で最も信頼できる棚卸しになります。
どんなデータをどこに保持しているか。 自前のデータベースか、Jiraの課題やConfluenceのページに保存したプロパティか。

作る前に決める

すべてのプライベートアプリが移行に値するわけではありません。Atlassian自身の助言は、JiraやConfluenceの標準機能がいまその役割を果たせるかを確認し、組織がまだ必要としているものだけを移行することです。古いアプリは、製品がその後に埋めた穴を埋めていたことがよくあります。

アプリごとに、3つの答えのどれかを割り当てます。移行するか、サポートされている何かで置き換えるか、廃止するかです。廃止は正当な結論です。Atlassianは、アプリをやめるなら、勝手に動かなくなるのを待つのではなく、利用者に知らせ、2027年1月31日より前に削除を予定に入れることを勧めています。

Forgeへの移行に含まれるもの

Forgeは、名前を変えたConnectではありません。ホスティングのモデル、セキュリティのモデル、UIのモデルがすべて違います。だからAtlassianは、単純なアプリの所有者にも、早い段階で概念実証を始めるよう勧めています。

ホスティング

Connectのアプリは、自社で運用するWebサービスです。ForgeのアプリはAtlassianのインフラ上で、厳しい制限のある関数として動きます。ユーザーが起動する関数は25秒、非同期イベントとスケジュールトリガーは最大900秒です。ユーザーを待たせながら10分間の同期を行うConnectのアプリは、その処理を非同期イベントに移さなければならず、15分を超えるものはステップに分割しなければなりません。外部への呼び出しも制限されます。アプリのマニフェストで宣言していないドメインへの呼び出しは拒否されます。

いまのバックエンドを残す

Forge Remoteを使うと、Forgeのアプリから別の場所でホストしているサービスを呼び出せ、自社のサーバーはリクエストが本当にForgeから来たものかを確認でき、バックエンドはAtlassianのAPIを呼ぶためのトークンを受け取れます。何年分もの業務ロジックをサーバーに抱えたプライベートアプリにとっては、たいていこちらが近道です。UIと連携ポイントはForgeに移し、ロジックはそのまま残します。

トレードオフもあります。Forge Remoteを使うと、アプリがAtlassianのRuns on Atlassianプログラムの対象外になることがあります。社内ツールではそれほど問題になりませんが、セキュリティチームにはそれを承知のうえで受け入れてもらってください。

認証と権限

Connectのアプリは、共有シークレットで署名したJWTで認証します。Forgeはこれを、マニフェストで宣言するOAuth 2.0のスコープに置き換え、リモートのバックエンドについては、JWTの代わりにサーバーが検証するForge Invocation Tokenを使います。

JiraやConfluenceのAPIへの認証付きの呼び出しは、それぞれasUser（アプリを使っている人の権限で）か、asAppのどちらかで行います。asAppはAtlassianの言葉では「誰がアプリを使っているかにかかわらず」動きます。呼び出しを1つずつ見直し、意図して選ぶことが、移行全体で最も重要なセキュリティレビューです。

チームがつまずく違いが1つあります。Connectのモジュールは、既定でライセンスのないユーザーや匿名ユーザーにも表示されます。Forgeのモジュールは、マニフェストでunlicensedAccessを指定しない限り表示されません。アプリがサービスデスクの顧客や匿名のConfluenceの閲覧者に何かを見せているなら、その経路を単独でテストしてください。

ユーザーインターフェース

Connectのページは、AtlassianのJavaScript APIを通じてJiraやConfluenceとやり取りするiframeです。Forgeには2つの選択肢があります。

UI Kit：Atlassianのネイティブのコンポーネントを描画する、Reactベースのフレームワークです。速く、見た目も揃いますが、Atlassianのコンポーネントを使って組み立てることになります。独自のHTMLは動かないことがあり、受け付ける静的リソースは画像だけです。
Custom UI：iframeの中の独自のHTML、CSS、JavaScriptで、@forge/bridgeを通じて製品とやり取りします。

既存のiframeのフロントエンドは、たいていCustom UIに移すのが最も変更が少なくて済みます。小さなパネルや設定画面は、UI Kitで作り直したほうが早いことがよくあります。

データ

移行が失敗するのはここです。Forgeには独自のホスト型ストレージがあります。キーバリューストア、カスタムエンティティストア、Forge SQL、そしてプレビュー版のオブジェクトストアです。データはインストールごとに区切られ、ホストであるJiraやConfluenceのサイトと同じ場所に保存されるので、追加の設定なしにデータレジデンシーが確保されます。

プライベートアプリにとっての意味は次のとおりです。

Connectのアプリ自身のデータベースにあるデータは、1回限りの移行ジョブでForgeのストレージに移すか、その場に残してForge Remote経由で参照します。
ConnectのアプリがAtlassianの側に自らのアプリキーで保存していたものは、古いアプリがまだ動いているうちにエクスポートしてください。新しいアプリがそれを読めるかどうかは、決めつけずに早めにテストします。
Forgeはアンインストール後28日間ホスト型のデータを保持しますが、再インストールしても自動では復元されません。

移行は、確認できる件数を出す繰り返し可能なスクリプトとして書き、テストサイトでリハーサルし、エクスポートを残しておいてください。

段階的な移行の道と、それがおそらく自社向けではない理由

AtlassianはConnectのアプリのために、より穏やかな道を用意しました。Forgeを段階的に採用する方法で、既存のインストールを維持し、ディスクリプターをForgeのマニフェストに変換し、モジュールの系統ごとに1つずつ移していくものです。マクロ、カスタムフィールド、ワークフローのバリデーターなど一部のモジュールには、組み込みのデータ移行もあります。

落とし穴はガイドの最初の段落にあります。「Forgeの段階的な採用は、すでにMarketplaceに掲載されているConfluenceとJiraのConnectアプリでのみ利用できる」。

プライベートアプリの場合は、新しいForgeアプリを作る前提で計画してください。本番環境にデプロイし、デベロッパーコンソールのインストールリンクで自社のサイトに共有し、データを移行して利用者がテストする間は古いConnectのアプリと並べて動かし、その後Connectのアプリを削除します。

それでも、段階的採用のガイドはモジュールの対応表として役に立ちますし、Forgeでは利用できないConnectの機能の一覧も同様です。Jira Service Managementのいくつかのモジュールとモバイルアプリへの対応は予定なしとされ、jiraReportsはまだ検討中です。最初の週に、ディスクリプターをこの一覧と突き合わせてください。そこに欠けているものがあれば、設計が変わります。

2027年1月31日から逆算した計画

2026年10月初めからは約17週間あり、12月は誰にとっても短い月です。持ちこたえる計画は次のとおりです。

今週：LEGACYのアプリをすべて、上記の5つの事実とともに洗い出します。ソースコードとホスティングのアカウントを誰が管理しているかを確認します。
10月半ばまで：アプリごとに、移行、置き換え、廃止のどれにするかを決めます。廃止するものの利用者に知らせます。
10月末まで：最も難しいアプリの最も難しい部分について、Forgeでの概念実証を行います。たいていは、Forgeに直接対応するもののないモジュールか、最も多くのデータを抱えるモジュールです。
11月：構築し、テストサイトに対してデータ移行を複数回実行します。
12月初め：ForgeのアプリをConnectのアプリと並べてインストールし、データのコピーを移行し、毎日使っている人たちに確認してもらいます。
2027年1月：最終的な移行を行い、利用者を移し、新しいアプリがしばらく問題なく動いてからConnectのアプリを削除します。

Jiraのデータを読むだけで何も保存しないパネル1つなら、小さな仕事です。独自のデータベース、ワークフローのルール、ほかのシステムとのつながりを持つアプリには、この期間がすべて必要です。

期限に間に合わなくても、その日にアプリが止まるとAtlassianが公表しているわけではありません。しかしその場合は、所有者が直すのをやめたプラットフォームの上で業務プロセスを動かしていることになります。その時間は借り物だと考え、移行をやり遂げてください。

最初の開発者がもういない場合

Atlassianはこのケースに直接触れています。元のアプリの所有者を特定できない、連絡が取れない、あるいは開発の体制がもうない場合は、Solution Partnerに依頼することを勧めています。ソースコードがなければ「Forgeでゼロから作り直す必要があるかもしれない」ことも、同じくはっきり書いています。

ソースコードがなくても、手探りで始めるわけではありません。ディスクリプターにはアプリが接続しているものがすべて載っており、その動きはテストサイトで観察でき、自社がサーバーの費用を払っているなら、実際に何がデプロイされているかを見られます。これらの材料から作り直すのは移植より時間がかかりますが、見通しの立つ作業です。

ご相談先

当社は、いまのチームの誰も書いていないコードを引き継ぎ、それが本当は何をしているかを解明し、移行します。Connectのアプリなら、ディスクリプターとサーバーを読み解き、Forgeのアプリを作り、データ移行を書いてリハーサルすることです。たいていは当社のレガシーシステムの保守の仕事から始まります。開発者はいるが人数が足りないなら、スタッフ増強で、必要な期間だけチームに人を加えます。アプリが何をしていて、どこで動いているかを、office@c9group.devまでお知らせください。