Jiraのガントチャートは標準でどこまで並ぶか｜線を引き直す前に

「jira ガントチャート」で検索する人が知りたいことは、たいてい2つに分かれます。1つは「そもそも自分たちの契約でガント形式の工程表が出せるのか」、もう1つは「出せるのは分かったが、思っていた形にならないのはなぜか」です。この2つは似ているようで、詰まっている場所がまったく違います。前者は料金とプランの話、後者は表示範囲と運用の話です。この記事では、公式に記載されている内容だけを使って、Jiraのタイムラインが標準でどこまで並ぶのか、逆に標準では届かない範囲はどこなのかを順番に整理します。そのうえで、工程表が続かなくなる原因が機能の不足ではないケースと、道具そのものを見直したほうがよいケースの境目を示します。

先に結論の一部を書いておきます。ガント形式でスケジュールを並べるタイムラインの表示は、Freeを含むすべてのプランに用意されています。有料にしないと工程表が一切見られない、ということはありません。一方で、複数のスペース（複数のプロジェクト）をまたいで1枚の計画にまとめる機能は Premium 以上に含まれます。「ガントチャートが有料から」ではなく、「1つのスペースの中の工程表は全プラン、スペースをまたぐ計画は上位プラン」という線の引かれ方になっています。ここを取り違えると、必要のないプラン変更を検討したり、逆に必要な機能を外部アプリで探しに行ったりすることになります。

なお、この記事に書いた料金・上限・機能の対応は、すべて2026年9月2日時点で公式サイトおよび公式サポートに掲載されていた表記を写したものです。対象は Jira Cloud で、料金は日本語ロケールで料金ページを開いた状態の表示です。プランと料金は変わります。契約や見積もりの判断をするときは、必ずその時点の公式ページで確かめてください。

工程表が欲しくなるのは、人数が増えて「聞かないと分からない」が増えたとき

チームが5人を超えたあたりから、進行のとりまとめをしている人のところに同じ相談が集まりはじめます。個々の作業は誰かが持っていて、担当者本人は自分の分を把握している。それなのに、全体としていつ何が終わるのかを即答できる人がいない。誰かに聞けば分かるが、聞かないと分からない状態です。この状態を解消しようとして、多くのチームがまず工程表を引きます。

ここで最初に選ばれるのは、たいてい表計算ソフトです。セルを塗って線を引けば、それらしい工程表は半日でできます。問題はそのあとに起きます。工程表を引いた本人だけが更新を担い、担当者は自分の作業を別の場所で管理する。この二重管理が始まると、表と実態は少しずつずれていきます。現場でよく言われるのは、引いた本人以外が触らなくなると2週間ほどで信用できなくなるということです。信用できない表は見られなくなり、見られない表は誰も直しません。

だから工程表を選ぶときに本当に確認すべきなのは、線を引けるかどうかではありません。日々の作業と線がつながっているかどうかです。担当者が自分の作業の期限を直したら工程表の線も動く、という関係になっていないと、表は必ず別管理になります。表計算ソフトの工程表が続かないのは、線と作業が最初から切れているからです。

Jiraのタイムラインは、この点では最初からつながっています。線の元になっているのは作業項目（work item）そのもので、専用の工程表ファイルがどこかに別で存在するわけではありません。公式サポートには次のように書かれています。

The timeline view is valuable for creating and planning long-term projects. It visualizes data from your work items in a Gantt chart so that you can manage your team's work within a single space. 出典: support.atlassian.com

「作業項目のデータをガントチャートとして可視化する」という説明です。工程表を別で引くのではなく、すでに登録されている作業をガント形式で見る、という位置づけになっています。とりまとめる立場から見ると、これは表計算ソフトで線を引き直している状態と比べてはっきりした利点です。

Jiraの標準タイムラインで並ぶもの

まず、追加購入なしで何が並ぶのかを確認します。公式サポートの記載にもとづくと、標準のタイムラインでは次のことができます。

・親（エピック）と子の階層表示 ・スケジュールバーの表示 ・スプリントやリリースの表示 ・依存関係の表示 ・フィルタによる絞り込み ・子項目のステータス表示 ・表示期間を週・月・四半期で切り替える

日付の入り方にも決まりがあります。公式には「Parent work items scheduled by manually set dates or dates inferred from child items」とあり、親の作業項目は手で設定した日付か、子の項目から推定された日付でスケジュールされます。子の作業項目については、スクラムならスプリントの日付、カンバンなら開始日と期限で並びます。

この作りが実務でどう効くかというと、「親の期間を人が引き直す作業」が減ります。子の作業がずれたときに、親のバーを手で伸ばして回る必要がありません。工程表が更新されなくなる原因の多くは、この「上の階層を人が手で直す」工程にあります。子の日付を直せば上が追随する構造になっていると、更新の負担が担当者に分散します。

依存関係の表示も標準で扱えます。ある作業が別の作業の完了を待っている、という関係を線でつなげられるので、遅れがどこに波及するのかを目で追えます。ただし後述するように、この依存関係の管理が「1つのプロジェクトの中だけ」なのか「プロジェクトをまたげる」のかは、プランによって変わります。

もう1つ、業務系（ビジネス用）のスペースについては別の説明ページがあり、「visualize the timing, duration, and dependencies of work items in your space」と書かれています。同時に「You can only use the timeline view if you are in a business space.」という注記もあり、タイムライン表示を使う場面がスペースの種類と結びついていることが分かります。開発チーム向けの使い方と、開発以外の業務チーム向けの使い方で、入口の説明が分かれている形です。

「ガントチャート」という言葉と「タイムライン」という言葉

検索するときに引っかかりやすいのが呼び方の違いです。Jiraの画面と公式ドキュメントでは、この機能はおもに「タイムライン」または「ロードマップ」と呼ばれています。「ガントチャート」という言葉は、上に引用したように機能の説明文の中に出てきます。

つまり、画面上で「ガントチャート」というメニューを探しても見つからないことがあります。探すべきはタイムラインです。ここでつまずいて「Jiraにはガントチャートが無いのかもしれない」と判断し、外部アプリを探しに行ってしまう人がいます。実際には、ガント形式でスケジュールを並べる表示は標準に含まれています。名前が違うだけです。

呼び方の違いは社内の会話にも影響します。「ガント出して」と言われた人がタイムラインのことだと分からないと、また表計算ソフトで線を引き始めます。道具を入れるときは、機能の名前を社内でそろえておくと、この種の無駄が減ります。

どのプランで使えるのか

ここが「jira ガントチャート」で検索する人にとって一番はっきりさせたい点です。公式の料金ページの記載にもとづいて整理します。

料金ページの比較表では、「Timeline view」は Free / Standard / Premium / Enterprise のすべての列に並ぶ行として掲載されています。さらに Free 欄の説明文にも「Backlog, list, board, timeline, calendar, and summary views」と明記されており、無料の範囲にタイムラインが含まれていることが読み取れます。

したがって、「Jiraでガント形式の工程表を見るには有料プランが必要」という要約は正確ではありません。10人までのチームであれば、Free のまま1つのスペースの中でタイムラインを使えます。工程表を出すためだけにプランを上げる判断は、いったん保留にしてよいということです。

Free で使える範囲は、料金ページの Free 欄に次のように書かれています。

・Up to 10 users ・Unlimited goals, projects, tasks, and forms ・Backlog, list, board, timeline, calendar, and summary views ・Reports and dashboards ・100 automation rule runs per month ・2 GB of storage ・Support from Atlassian Community

比較表の Free 列にある数値も合わせて確認しておくと、ユーザー上限は10人、サイト数は1、ストレージは2GB、メール通知は1日あたり100通、自動化ルールの実行は月100回、サポートはコミュニティサポート、依存関係の管理は「Single Project」となっています。ライセンスのページにも「The Cloud Free plan is available for up to 10 users (Jira and Confluence) and 3 agents (Jira Service Management), 2GB of storage.」という記載があります。

件数の上限については、料金ページの Free 欄が「Unlimited goals, projects, tasks, and forms」「Unlimited work items」「Unlimited spaces」と記載しており、作業項目やスペースの件数に上限は示されていません。無料の範囲で制約になるのは人数・ストレージ・自動化の実行回数・通知数のほうだ、という読み方になります。

なお、Free プランの履歴や監査ログが何日分・何か月分残るのかを明記した記述は、公開資料では確認できませんでした。比較表には「Audit logs - site changes」「Audit logs - user activity」という行がありますが、どのプランに対応の印が付くのかを文章として確認できる形にはなっていませんでした。監査ログの保持が要件に入るチームは、契約前に直接確認したほうが確実です。

標準では届かない範囲は「スペースをまたぐ計画」

では、どこから上位プランが必要になるのか。公式サポートには、次のようにはっきり書かれています。

「A timeline can only show work items from one space. Planning across multiple spaces is only possible in your plan, which is included with Jira Premium and Enterprise.」

1つのタイムラインが表示できるのは、1つのスペースの中の作業項目だけです。複数のスペースをまたいだ計画は Plans で行い、その Plans は Jira Premium と Enterprise に含まれます。ここで押さえておきたいのは、この Plans が Atlassian Marketplace の外部アプリではなく、Premium 以上のプランに含まれている機能だという点です。「スペースをまたぐ工程表を見るには外部アプリの購入が要る」と考えて探しに行く必要はありません。

料金ページの比較表でも同じ線が引かれています。Premium の説明には「Cross-team planning and dependency management」とあり、依存関係の管理は Free と Standard が「Single Project」、Premium と Enterprise が「Cross-project」となっています。さらに「Advanced planning (Plans)」「Capacity management」「Expandable Work Type Hierarchy」「Scenario Modeling」といった項目が、Premium 以上に向けた機能群として「Simplify cross-functional work」の節に並んでいます。

この線引きは、道具の設計思想として筋が通っています。1つのチームが1つのスペースで動いている限り、工程表は無料の範囲で足ります。複数のチーム・複数のプロジェクトの計画を1枚に重ねて、人の空き具合まで見ながら組み替える段階になったら、そのための機能群が上位プランにある、という組み立てです。

逆に言うと、判断のポイントは1つに絞れます。工程表を1つのスペースの中で見られれば足りるのか、複数のスペースをまたいで見たいのか。ここが決まれば、プランを上げるべきかどうかも自動的に決まります。

なお、これ以外に外部アプリ（Atlassian Marketplace のガントチャート系アプリ）が必要になる範囲を、Atlassian が公式に線引きして説明した記述は、公開資料では確認できませんでした。「この使い方には外部アプリが必須」と断定できる公式の記載は見当たらない、というのが正確な状況です。

料金は人数の段とセットで読む

料金の話をするときに一番間違えやすいのが、単価だけを持ち出すことです。Jiraの料金ページは「Team size:（人数）」と「Bill me: Monthly / Annually」で表示が切り替わり、人数の段（ユーザー階層）によって単価が変わります。金額は必ず条件とセットで見る必要があります。

月払いの表示で、Team size を10ユーザーにしたときの表記は次のとおりです。

プラン	表示
Free	￥0（Free forever for 10 users）
Standard	￥1,240 per user / month
Premium	￥2,500 per user / month
Enterprise	Billed annually. 年払い表示に切り替えると価格が表示される（Contact sales）

年払いの表示で、同じく Team size を10ユーザーにしたときは、Standard が「￥123,000 per year」「User tier: 1 - 10」、Premium が「￥253,000 per year」「User tier: 1 - 10」と表示されます。

人数が増えると単価が下がる仕組みも確認できます。料金ページの初期表示（Team size 300ユーザー、月払い）では、Standard が「￥1,085 per user / month」、Premium が「￥1,987 per user / month」となります。同じ条件の年払い表示では、Standard が「￥3,210,000 per year」「User tier: 201 - 300」、Premium が「￥5,940,000 per year」「User tier: 201 - 300」です。年払いについては料金ページに「SAVE UP TO 17%」の表記があります。

税の扱いについては注意が必要です。料金ページには税込か税抜かの注記が見当たりませんでした。購入・ライセンスのFAQには「VAT will be applied only to orders in those countries where exemption documentation or a valid VAT ID has not been supplied.」という記載と、米国の売上税についての記載がありますが、日本の消費税の扱いを明記した記述は公開資料では確認できませんでした。社内の見積もりを作るときは、この点を先に確認しておくと差し戻しが減ります。通貨については「Atlassian can generate quotes in US dollars (USD), Australian dollars (AUD), and Japanese yen (JPY).」という記載があり、AUDとJPYはその地域の顧客に限る旨の注記が付いています。

席数の数え方が費用を左右する

工程表そのものとは離れますが、とりまとめる立場の人が実際に困りやすいのが席数のカウントです。公式のライセンスページには次のように書かれています。

月払いについては「Your bill is based on the highest number of seats ("maximum quantity") assigned to each product at any point during your billing cycle.」とあり、請求期間中のいずれかの時点で割り当てられた席数の最大値が基準になります。年払いについてはユーザー階層（user tier）単位で、階層の中であれば人数が動いても更新まで価格は変わりません。

そして、見落とされやすいのがこの一文です。「Users will be counted toward billing once product access is granted. A user must be explicitly deactivated, deleted, or removed from a synced user directory to not count towards billing.」製品へのアクセス権を付与した時点で課金対象になり、明示的に無効化・削除・同期ディレクトリからの除外をしない限り、カウントから外れません。

工程表を見せたいという理由で関係者にアクセス権を配ると、そのまま席数が増えます。プロジェクトが終わったあとに整理していないアカウントが残っていると、月払いの請求は最大値基準なので、そこが効いてきます。とりまとめる人が定期的に棚卸しをする運用を決めておくと安全です。

工程表を「見せたいだけ」の相手はゲストで足りるか

外部の協力会社や、社内の別部署の人に工程表を見せたい、という要望はよく出ます。この場合にゲスト機能が使えるかどうかは、条件を確認してからにしたほうがよいです。

公式サポートによると、ゲストアクセスが使えるのは Standard、Premium、Enterprise の各プランです。料金は「Guests are free of charge (up to 5 guests per paid user).」とあり、有料ユーザー1人あたり5人までのゲストが無料枠に入ります。ただし「Total number of users (paid + guests) can't exceed your Jira site's user limit.」とあり、有料ユーザーとゲストの合計はサイトのユーザー上限を超えられません。

見える範囲にも制限があります。「Guests can only be added to a single Jira space per site, and can't see work or data outside that space unless it's been explicitly shared with them.」ゲストはサイトごとに1つのスペースにしか追加できず、そのスペースの外の作業やデータは、明示的に共有されない限り見られません。ダッシュボードやゴールのようなサイト全体の画面も、管理者が明示的に許可しない限り見えません。

さらに「You may not convert current or former paid users to guests. The purpose behind the guest feature is to invite users outside of your organization.」という規定があり、現在または過去の有料ユーザーをゲストに切り替えることはできません。ゲスト機能は社外の人を招くためのものだ、という位置づけです。費用を下げる目的で社内メンバーをゲストに寄せる、という使い方は想定されていません。

Jiraのままで問題がない場合

比較記事で先に書くべきなのは、乗り換える理由が無いのはどういう場合か、です。次に当てはまるチームは、いま使っているものを変える理由がほとんどありません。

・開発の作業項目をスプリント単位で回していて、その日付がそのままタイムラインに反映されている ・1つのスペースの中で工程表が見られれば足りている ・エピックと子の階層で作業を分解する習慣がすでにある ・依存関係を線でつなぐ運用が定着していて、遅れの波及を追えている ・自動化ルールや外部サービスとの連携を実際に組んでいて、そこが業務の中心になっている ・複数チームの計画をまたいで見る必要があり、その分の費用を払う判断がすでに済んでいる

とくに最後の条件に当てはまるなら、Plans が Premium に含まれているという構造は素直です。複数のスペースをまたぐ計画、人の空き具合の管理、シナリオの検討まで含めて1つのプランに入っているので、機能ごとに追加購入を積み上げる必要がありません。

開発チームが中心で、コードの管理や外部ツールとの連携が業務の骨格になっているなら、その周辺がそろっている環境から離れるほうがコストになります。工程表の見え方が少し不満だという理由だけで、動いているものを止める必要はありません。

見直しを考えたほうがよい場合

一方で、次のような状況が続いているなら、機能を足す方向ではなく、道具の前提そのものを見直したほうが早いことがあります。

1つめは、工程表を見る人と入力する人がずれている場合です。作業項目を登録して日付を入れているのは一部の人だけで、残りのメンバーはチャットや口頭で進捗を伝えている。この状態だと、タイムラインの精度はいつまでも上がりません。線が自動で動く仕組みがあっても、動かす元になる入力が無ければ同じことです。

2つめは、開発以外のメンバーが多い場合です。スプリント、エピック、バックログといった語彙は、開発の外にいる人にはすぐには入りません。用語の説明から始めるコストが毎回かかると、入力する人が増えないまま止まります。入力する人が増えないと、進捗の表はすぐ嘘になります。

3つめは、「工程表を見せるためだけ」に席数が増えている場合です。実際には作業を入力しない人が、見るためだけにアクセス権を持っている。この人数が増えるほど、費用は上がるのに表の精度は上がりません。見せることと入れることを分けて設計し直したほうが、費用も精度も改善します。

4つめは、必要なものが「1枚の板に全部載っている状態」であって、多機能ではない場合です。設定できる項目が増えるほど、チームの中で設定を理解している人と理解していない人の差が広がります。とりまとめる人が設定の相談窓口になってしまうと、その人の時間から先に溶けていきます。

この4つは、どれも機能の不足ではありません。道具とチームの組み合わせの問題です。だから機能を足しても解決しません。

乗り換えを検討するなら先に確認する4点

道具を入れ替える判断をする前に、確認しておくと後戻りが減る点が4つあります。

データを持ち出せるか

Jiraからのデータの持ち出しについては、公式サポートに具体的な案内があります。作業項目（work item）はCSVで書き出せて、書き出したCSVは同じJiraや別の Jira Cloud への取り込みにも使えます。書き出せる対象として「work items, users, user group settings, work item attachments, user avatars, and space logos」が挙げられています。

日本語を含むデータを扱うときに効いてくるのが、文字コードの設定です。公式には「The Advanced section allows you to change the file encoding (UTF-8 by default) and CSV delimiter」とあり、既定はUTF-8で、必要に応じて文字コードとCSVの区切り文字を変更できます。書き出したファイルを表計算ソフトで開いて文字化けした場合は、まずここを確認します。

取り込み側も同様にCSVに対応しており、JSONでの取り込みについては「The JSON import feature lets you import work items from external project management tools that cannot be exported to CSV files」と説明されています。CSVで書き出せない他のツールからの移行を想定した機能です。他ツールからの直接の取り込みとしては、Bitbucket、Trello、その他の作業管理ツールが案内されています。

なお、XML形式での書き出しや、バックアップファイルの形式について公式に案内された記述は、上記のページでは確認できませんでした。

持ち出せる形式が分かっていることは、それ自体が安心材料です。入れる前に出せるかを確認しておくと、あとで選択肢が狭まりません。

日本語で使えるか

Atlassianのクラウド製品は日本語に対応しており、対応言語の一覧に Japanese が含まれます。一覧には English (UK)、English (US)、Chinese (Simplified)、Chinese (Traditional)、Croatian、Czech、Danish、Dutch、Finnish、French、German、Hungarian、Italian、Japanese、Korean、Norwegian、Polish、Portuguese (Brazil)、Russian、Serbian (Latin)、Serbian (Cyrillic)、Slovenian、Slovak、Spanish、Swedish、Ukrainian、Turkish が挙がっています（Vietnamese は対応製品が限られる旨の注記付きです）。

切り替えはアカウント単位で行えます。公式の手順は「アバターからProfileを選び、Manage your accountを開き、Account preferencesのLanguageから言語を選ぶ」という流れです。この設定はアプリ管理者が設定した既定の言語より優先される、と説明されています。ドキュメントについても日本語訳が提供されている旨の記載があります。

多言語のメンバーがいるチームでは、この「個人ごとに切り替えられる」という点が効きます。全員を同じ言語に固定しなくてよいからです。

権限とゲストの設計が要件に合うか

権限の扱いはプランによって変わります。料金ページの比較表では「User roles and permissions」が Standard の追加機能として説明文に挙がっており、Standard の説明は「Everything from Free, plus: ... User roles and permissions」となっています。比較表には「Anonymous access」「Free guest access」「Work item-level security」「IP allowlisting」といった行もあります。

ライセンスページには「Jira and Confluence also have permission restrictions and will not include anonymous access in the Cloud Free plan」という記載があり、無料プランでは権限に制限があり、匿名アクセスは含まれません。

社外の人に工程表を共有する必要があるなら、先に見たゲストの条件と合わせて、この権限の線引きを確認しておく必要があります。要件が Standard 以上でしか満たせないなら、そこが実質的な入口になります。

チームが入力を続けられるか

最後がいちばん大事で、いちばん見落とされます。工程表の精度は、入力する人の数で決まります。とりまとめる人が1人で更新している限り、どんな道具を使っても表は遅れます。

道具を選ぶときは、機能の一覧を見比べる前に、「いちばん入力が苦手なメンバーが、迷わずに触れるか」を試すほうが確実です。試用の期間に見るべきなのは、とりまとめる人が使いこなせるかではなく、その人以外が2週間続けられるかです。

板の考え方で工程表を持つとどうなるか

ここまでを踏まえて、選択の構造を整理します。ツールごとに「何を無料の範囲に置き、何を上位プランに置くか」の線の引き方は違います。その線は、そのツールが誰に向けて作られているかを表しています。

Jiraの場合は、1つのスペースの中の工程表は全プラン、複数スペースをまたぐ計画は Premium 以上、という線でした。開発チームの単位で完結する使い方なら無料の範囲で足り、複数チームの計画を重ねる段階になったら費用が発生する、という設計です。使い方が設計に合っているなら、素直な組み立てです。

これに対して、板（ボード）に進行をまとめる考え方の道具は、線の引き方が違います。機能で絞らず、区切るのは人数とボードの数だけという組み立てにすると、「工程表を見るためにプランを上げる」という判断そのものが発生しません。工程表が見られるかどうかを契約内容で調べる作業が要らなくなる、という意味です。区切り方の考え方は料金に、板でできることの範囲はできることにまとめてあります。

同じ軸で他のツールを見ると、判断が早くなります。カード型のボードから移ってくる場合の勘所はTrelloとの比較、タイムライン表示や依存関係の考え方の違いはAsanaとの比較にまとめています。データベースの発想でプロジェクトを組み立てる場合との違いはNotionとの比較、ダッシュボードや自動化を軸に据える場合との違いはmonday.comとの比較、課題管理とソースコード管理を同じ場所で扱う考え方との違いはBacklogとの比較、日本語圏のカンバン型ツールとの違いはJootoとの比較にそれぞれ整理しています。1つずつ読むより、比較の一覧で軸をそろえて見比べるほうが結論に早く着きます。

同時に、こちらの弱いところも先に書いておきます。リポジトリの機能はありません。自動化と外部サービス連携の広さで勝負するつくりでもありません。画面は日本語のみです。データを自動で取り込めるのは今のところTrelloだけで、その手順はTrelloからの移行に書いてあります。ソースコードと作業項目を同じ場所で管理したいチーム、スプリントの単位で開発を回していて自動化ルールを実際に組んでいるチーム、日本語以外の画面が必要なメンバーがいるチームにとっては、これらは十分に大きな理由になります。合わないと分かっているものを勧めても、誰の得にもなりません。

預かっているデータの扱いをどう考えているかは安全性の考え方に、細かい疑問への回答はよくある質問にまとめています。

判断の順番としては、次のように整理すると迷いが減ります。まず、いま工程表が更新されない原因が、機能の不足なのか入力の途切れなのかを分けます。入力の途切れなら、道具を変えても同じことが起きるので、先に入力の設計を直します。機能の不足なら、それが「1つのスペースの中で足りない」のか「スペースをまたげないから足りない」のかを分けます。後者であれば、Premium 以上に含まれる Plans が答えになります。前者であれば、そもそも作業項目の粒度や日付の入れ方に手を入れるほうが効きます。そのどちらでもなく、「開発の語彙が合わないメンバーが多くて入力が広がらない」のであれば、道具の前提から見直す価値があります。

最後にもう一度確認しておきます。この記事に書いた料金・上限・機能の対応は、いずれも2026年9月2日時点で公式サイトおよび公式サポートに掲載されていた表記です。料金は日本語ロケールで料金ページを開き、Team size と Bill me の条件を指定した状態の表示であり、条件を変えれば単価も総額も変わります。税の扱いについても、料金ページには税込か税抜かの注記が見当たりませんでした。契約の前には、必ずJiraの公式料金ページで自分たちの人数と支払い方法の条件を指定して確かめてください。

Q1. Jiraのガントチャートは無料プランでも使えますか？

使えます。料金ページの比較表では「Timeline view」が Free / Standard / Premium / Enterprise のすべての列に並び、Free 欄の説明文にも「Backlog, list, board, timeline, calendar, and summary views」と明記されています。Free はユーザー数が10人までなので、その範囲であれば1つのスペースの中の工程表を無料で見られます。2026年9月2日時点の公式表記にもとづきます。

Q2. どこから上位プランが必要になりますか？

複数のスペース（複数プロジェクト）をまたいで計画を1枚にまとめたい場合です。公式サポートには「A timeline can only show work items from one space. Planning across multiple spaces is only possible in your plan, which is included with Jira Premium and Enterprise.」とあります。依存関係の管理も Free と Standard は「Single Project」、Premium と Enterprise は「Cross-project」です。

Q3. スペースをまたぐ計画には外部アプリの購入が必要ですか？

公式の記載では、複数スペースをまたぐ計画を担う Plans は Jira Premium と Enterprise に含まれる機能とされています。Marketplace の外部アプリを別途購入する前提にはなっていません。これ以外に外部アプリが必要になる範囲を Atlassian が公式に線引きして説明した記述は、公開資料では確認できませんでした。

Q4. 料金はいくらですか？

料金は人数の段と支払い方法で変わります。2026年9月2日時点の日本語ロケール表示で、月払い・Team size 10ユーザーの条件では Standard が￥1,240 per user / month、Premium が￥2,500 per user / month です。同じ10ユーザーの年払いでは Standard が￥123,000 per year、Premium が￥253,000 per year（User tier: 1 - 10）と表示されます。税込か税抜かの注記は料金ページに見当たりませんでした。