Asanaのゲスト招待に料金はかかるのか｜無料の条件と落とし穴
「asana ゲスト 料金」で検索する人が確かめたいのは、社外の相手をプロジェクトに招いたときに請求が増えるのかという1点です。結論を先に書くと、組織で契約している場合、ゲストは無料でライセンス数にも数えられません。ただし、これには条件があり、契約している場所によっては例外が発生します。さらに、規約で禁じられている使い方もあります。この記事では、公式ヘルプセンターの記載をもとに、無料になる条件、例外、ゲストにできないこと、実務での運用の設計を順に整理します。
社外の人を巻き込む進行で、費用が読めなくなる理由
制作会社、代理店、受託開発、そして社内でも業務委託の相手と組む場面では、進行に関わる人の一部が必ず社外になります。ここで多くのチームが同じ壁に当たります。社外の人にツールを開いてもらいたいが、人数が増えれば費用が増えるのではないか、という懸念です。
その懸念が運用に与える影響は、思っているより大きくなります。費用を気にしてアカウントを配らないと、社外の相手とのやり取りはメールとチャットに戻ります。すると、決定と進捗がツールの外で起きるようになり、ツールの中の情報は古くなります。進行をとりまとめる立場から見れば、これは最も避けたい状態です。
だからこそ、ゲストの料金の扱いは、単なる費用の話ではなく運用設計の前提になります。無料で招けるなら、社外の相手を最初から中に入れる設計にできます。有料なら、誰を入れて誰を入れないかの線引きが必要になります。
ゲストとは、組織のメールドメインを持たない人のこと
料金の話に入る前に、Asanaにおけるゲストの定義を確認します。ヘルプセンターには次のように書かれています。
ゲストとは、組織のメールドメインを持たない、組織内のユーザーです。ゲストは招待されることによって、特定のタスクや、特定のプロジェクト、チーム内で作業することができます。 出典: help.asana.com
つまり、判定の基準はメールアドレスのドメインです。組織で承認済みのメールドメインのアドレスを持たないクライアントやベンダー、顧客はゲストになると説明されています。フリーメールのアドレスもここに含まれます。
逆に言えば、同じ会社のメールアドレスを持つ人は自動的にメンバーになります。ヘルプセンターの例では、メールアドレスが[email protected]の人は組織acme.comのメンバーになると説明されています。この区別が、そのまま請求の区別になります。
組織で契約している場合、ゲストは無料
本題です。ヘルプセンターのゲストに関するFAQには、料金について明確な記載があります。有料プランの組織のゲストに対して料金は発生するかという問いに対し、発生しないと答えられています。組織全体をアップグレードした場合も、ゲストはメンバーシップのライセンス数に数えられないと明記されています。
サブスクリプションの解説記事にも、同じ内容が別の角度から書かれています。ゲストは請求対象に含まれず、サブスクリプションのライセンス数にもカウントされないとしたうえで、具体例が示されています。組織メンバー10人とゲスト2人からなる12人のチームであれば、10人分のライセンスを購入すれば十分だという説明です。
ここから、実務上の含意が2つ出てきます。1つは、社外の協力者を人数の上限を気にせず招けるということ。料金ページにも、Starter以上の機能として無制限の無料ゲストという項目が挙げられており、追加料金やユーザー数への影響を心配することなく社外のコラボレーターをプロジェクトに招待できると説明されています。
もう1つは、費用の見積もりを立てるときに、社外の人数を数えなくてよいということです。契約するライセンス数は、自社のメールドメインを持つ人の数で決まります。
例外1: ワークスペースで契約している場合は有料になる
ここが最も見落とされやすい点です。Asanaには、組織とワークスペースという2つの形があります。組織は会社の共通メールドメインに基づくもので、ワークスペースはメールドメインを必要としない独立したスペースです。
ヘルプセンターには、ワークスペースについてこう書かれています。組織とは異なり、ワークスペースでコラボレーションするすべてのユーザーは、完全メンバーでもゲストでも有料プランの対象になるとされています。
つまり、同じ「ゲストを招く」という操作でも、契約している場所がワークスペースなら請求対象になります。会社のメールドメインを持たない状態でAsanaを使い始めたチームや、複数の会社が混在する形で立ち上げたスペースは、ワークスペースになっている可能性があります。ゲストが無料だと思って人を増やしたら請求が増えていた、という事態はここで起きます。
自分たちがどちらなのかは、管理者コンソールで確認できます。見積もりや請求の話をする前に、この確認を先に済ませておくべきです。
判別の目安としては、社員が会社のメールアドレスでログインしていて、同じドメインの人が自動的に同じ空間に集まっているなら組織である可能性が高くなります。逆に、参加者がそれぞれ別のドメインやフリーメールでログインしていて、招待された人だけがその空間にいるなら、ワークスペースの可能性があります。ただし見た目だけでは断定できないため、請求に関わる判断をする前には管理画面での確認が必要です。
例外2: 自社の社員をゲストとして使うことは規約で認められていない
もう1つの例外は、費用ではなく規約の話です。ヘルプセンターのゲストに関するFAQの末尾に、利用規約についての記載があります。
ゲストアカウントは、クライアント、請負業者、顧客など、外部のビジネスパートナーとのコラボレーションに使用されることを目的としていると説明されています。そのうえで、Asanaのサービスを利用する顧客が、自社の従業員または関連会社の従業員のために別途サブスクリプションを購入せずに、当該従業員にゲストとしてアクセスさせることは許可されていないと明記されています。
これは重要な線引きです。ライセンス費用を抑えるために、自社の社員に個人のフリーメールでゲストとして参加してもらう、という運用は認められていません。同様に、関連会社の従業員をゲストとして扱う運用も対象になります。費用を圧縮する手段としてゲストを使う設計は、この記載を確認したうえで見直す必要があります。
なお、ヘルプセンターには関連する注意もあります。有料組織のメンバーが他の組織でゲストアクセスを使用している場合でも、自分のホーム組織のライセンスは占有すると書かれています。他社のプロジェクトにゲストとして呼ばれている社員がいても、自社の契約人数は減らないということです。
ゲストにできること、できないこと
無料であることと、同じように使えることは別です。ゲストの権限には明確な制限があり、運用設計に影響します。
まずアクセス範囲です。ゲストの組織に対するアクセス権は限定されており、明示的に共有された内容のみを閲覧できるとされています。具体的には次のように整理されています。
・タスクを共有した場合、ゲストにはそのタスクのみが表示される ・プロジェクトを共有した場合、そのプロジェクトと中のすべてのタスクが表示される ・チームに招待した場合、そのチームと直接共有されているすべてのプロジェクトを閲覧できる ・ポートフォリオに招待した場合、招待されたプロジェクトのみが表示される
次に、操作の制限です。ゲストはルールを作成することやオーナーになることはできないが、ルールをトリガーすることはできると説明されています。タスクテンプレートの作成と編集、カスタムフィールドの設定の作成と編集、チームの作成とチーム設定の編集はできないとされています。
一方で、有料機能を受動的に使うことはできます。カスタムフィールドの値を一覧から選ぶことはできるが、カスタムフィールド自体は編集できない、という例が挙げられています。緊急度という項目の値を中から高に変えることはできるが、その項目の名前や選択肢は編集できない、という説明です。
つまり、ゲストは「決められた枠の中で作業して報告する人」として設計されています。仕組みを作る側には回れません。社外のパートナーに進行の設計まで任せたい場合、ゲストのままでは実現できないということです。
ゲスト同士の見え方は、意図しない限り遮断される
代理店や制作会社が特に気にするのが、クライアント同士が互いを認識してしまわないかという点です。ここもヘルプセンターに記載があります。
2人のユーザーが互いに非公開ユーザーとして表示される場合、2人はどちらもゲストであることを意味すると説明されています。ゲストにこの表示が出る場合、2人は同じチームまたはプロジェクトには所属していないことになります。この仕組みは、クライアントと仕事をしている場合に、意図しない限りクライアント同士が互いの名前を見られないようにするためだと書かれています。
逆に、ゲストが他のゲストの名前を見るには、1つ以上の同じプロジェクトまたはチームのメンバーになっている必要があります。両方のゲストを同じプロジェクトに追加すれば、互いの名前が見えるようになります。
運用上の注意はここです。複数のクライアントを1つのプロジェクトにまとめてしまうと、相手同士が見えます。案件ごとにプロジェクトを分ける設計が、そのまま情報の遮断になるということです。効率を優先してプロジェクトを統合すると、この境界が消えます。
誰がゲストを招待できるかは、プランによって変わる
招待の権限も確認しておきます。ヘルプセンターには、一般的にメンバーなら誰でもゲストを組織に追加できると書かれています。さらに、組織ゲスト自身も、自分にアクセス権が与えられているプロジェクトやタスクを共有することで、他のゲストを組織に招待できるとされています。
これは便利である一方、統制の観点では緩い状態です。誰が誰を呼んだのかを把握していないと、退任した担当者のアカウントが残り続けるといったことが起きます。
この統制のために用意されているのが、Enterprise、Enterprise+、旧Enterpriseの特権管理者が使える設定です。管理者コンソールのゲスト招待の管理設定で、外部ゲストを組織に招待できるユーザーに関するポリシーを設定できると説明されています。料金ページにも、Enterpriseの機能としてゲスト招待の権限が挙げられており、アドオンの権限管理ではゲストアクセスを一括で管理できるとされています。
つまり、ゲストを招くこと自体は下位プランでも無料でできますが、誰が招けるのかを制限したい場合は上位プランの領域になります。招待が無料であることと、招待を統制できることは別の話です。
マジックリンクによる認証は、上位プランの領域
ゲストの認証について、上位プランに限定された仕組みも用意されています。ヘルプセンターには、マジックリンクによるゲスト認証がAsana Enterprise+およびAsana Govで利用できると記載されています。設定するには、カスタマーサポートチームへの問い合わせが必要とされています。
このリンクの扱いも明記されており、リンクは15分で期限切れになり、Asana Govでは1回限りの使用になるとされています。あわせて、ゲスト限定ユーザーという概念も説明されており、どのホームドメインにも属していないユーザーを指すとされています。ホームドメインを持つゲストは引き続きホームドメインの認証の流れを経由するため、プロビジョン解除の懸念はないと書かれています。
情報システム部門の視点で言えば、社外のアカウントをどう認証するかは、費用より優先度が高い論点になることがあります。パスワードの管理を相手に委ねたくない場合、こうした仕組みの有無が判断材料になります。ただしこれは最上位のプランに限られるため、料金が無料であるゲストの話とは切り離して検討する必要があります。
ゲストを招く前に決めておく4つのルール
無料で招けるからといって、無計画に招くと後で困ります。運用を回すために、先に決めておくべきことが4つあります。
1つ目は、招く単位です。タスク単位で共有するのか、プロジェクト単位で招くのか、チームに入れるのか。見える範囲がそれぞれ違います。案件全体を見せてよいならプロジェクト、特定の依頼だけならタスクという使い分けになります。迷ったら狭いほうから始めるのが原則です。後から広げるのは簡単ですが、一度見えたものを見えなかったことにはできません。
2つ目は、招く人を誰にするかです。標準では、メンバーなら誰でもゲストを追加でき、ゲスト自身も他のゲストを招けます。統制の仕組みを持たないプランでこの状態を放置すると、誰がいつ誰を呼んだかが追えなくなります。プランで制限できないなら、社内のルールとして「招待は案件の主担当だけが行う」と決めておくのが現実的です。
3つ目は、外すタイミングです。案件が終わったら外すのか、契約が切れたら外すのか。決めていないと、退場処理は永久に後回しになります。案件のクローズ作業の項目に「関係者の整理」を入れておくと、忘れにくくなります。
4つ目は、相手に何を求めるかです。見るだけでよいのか、状況を更新してほしいのか。更新してほしいなら、どの項目をどのタイミングで触るのかまで伝えないと、結局は主担当が代わりに入力することになります。ゲストが受動的な操作しかできない設計である以上、相手にお願いする範囲は具体的にしておく必要があります。
ゲストの入れ替わりをどう管理するか
社外の協力者は、案件が終われば離れます。この出入りをどう扱うかで、運用の安全性が変わります。
ヘルプセンターには、削除に関する注意が書かれています。ゲストを削除したのに、タスクを割り当てるときにオートコンプリートの結果に表示されるという事象について、組織のチームまたはディビジョンから削除しても、組織自体からは削除していない可能性があると説明されています。削除されたユーザーはチームやディビジョンには表示されなくなるが、組織には存在が残っている可能性があるためだとされています。完全に削除するには、もう一度チームに招待してからプロビジョンの解除を行う必要があると書かれています。ワークスペースや組織から削除されたゲストやメンバーには、メール通知が届くとも記載されています。
ここから引ける実務の教訓は2つです。1つは、削除の操作は「どこから消したか」を意識する必要があるということ。もう1つは、案件終了時に誰を外すかを決めておかないと、退場処理が後回しになるということです。
もう1点、ゲストとメンバーの相互変換についても記載があります。ゲストをメンバーに、メンバーをゲストに変更することは簡単にはできないとされています。ゲストをメンバーに変えるには、組織のドメインに属するメールアドレスをそのゲストのAsanaアカウントに追加する必要があると説明されています。業務委託の人が正社員になったといった場合、単純な設定変更では済まないということです。
また、ゲストは有料プランの組織の管理者にはなれないと明記されています。管理者になるには正規の組織メンバーである必要があるとされています。
招いた相手が実際に開いてくれるか
料金が無料でも、相手が開かなければ意味がありません。ここは制度ではなく運用の話です。
社外の相手が新しいツールを開かない理由は、だいたい3つに絞られます。第1に、アカウントを作る手間です。招待メールが届いても、登録の手順が長ければそこで止まります。第2に、開いても自分が何をすればよいのか分からないことです。プロジェクトの画面をいきなり見せられても、どこに書けばよいのかは伝わりません。第3に、他のツールと重複していることです。すでにチャットでやり取りが成立しているなら、わざわざ別の画面を開く理由がありません。
対策として効くのは、最初の1回で用件を完結させることです。招待と同時に、その相手が最初に触るタスクを1つ割り当て、そこに具体的な依頼を書いておく。開いた瞬間にやることが目の前にある状態を作れば、次からは開いてくれます。逆に、招待だけ送って「何かあったらここで」と伝える形は、ほぼ機能しません。
もう1つは、通知の設計です。社外の相手は毎日開きません。自分に関係する更新だけがメールで届き、そこから直接開ける形になっていれば、常時開いていなくても進行に参加できます。よく聞くのは、通知が多すぎて社外の人が全部無視するようになったという話です。関係のない更新まで流れる設定になっていないかは、招く前に確認しておく箇所です。
社外と組む形が変わったときに見直すこと
ゲストの扱いは、体制が変わると前提から見直す必要があります。よくある3つの変化を挙げます。
1つ目は、業務委託の人が社員になる場合です。ヘルプセンターには、ゲストをメンバーに変えるには組織のドメインに属するメールアドレスをそのゲストのAsanaアカウントに追加する必要があると書かれています。設定のスイッチを切り替えるような操作ではないため、入社のタイミングで手続きの担当を決めておかないと、当人が古いアカウントのまま働き続けることになります。
2つ目は、社外の協力者が増えて、実務の中心が委託先に移る場合です。ゲストはルールを作れず、テンプレートやカスタムフィールドの設定も編集できません。仕組みを整える役が委託先にあるなら、その人だけはメンバーとして契約に含めるという判断が必要になります。費用は増えますが、設計を毎回社内の誰かが代行するほうが高くつきます。
3つ目は、契約している場所が変わる場合です。特定のチームだけを有料にしていたところから組織全体のアップグレードに切り替える、あるいはワークスペースから組織へ移すといった変更では、請求の対象範囲が変わります。ゲストが無料かどうかも、この変更で変わり得ます。契約の形を変えるときは、ゲストの扱いを必ず確認項目に入れてください。
前提となるプランと料金
ゲストが無料である前提として、本体の契約がどうなっているかも確認しておきます。2026年9月時点の日本語の料金ページでは、Personalが0円で2人まで、Starterがユーザー1人あたり年間請求で月1,200円、月払いで1,475円、Advancedが年間請求で月2,700円、月払いで3,300円と表示されています。EnterpriseとEnterprise+は問い合わせ制です。表示は税抜で、日本国内に請求先住所がある場合は消費税が課税されると記載されています。
無制限の無料ゲストは、Starter以上の機能として料金ページに挙げられています。また、料金ページのFAQには、すべてのチームで管理者機能や有料機能を使う必要はなく、ゲストの追加やプロジェクト単位での権限設定を行いたい場合は、その特定のチームだけをアップグレードすればよいという説明もあります。組織全体を上げずに、社外と関わるチームだけを有料にするという選び方ができるということです。
この「チームだけをアップグレードする」という選び方は、社外との協業が一部の部署に限られている場合に効きます。全社で有料にする必要がないなら、社外と関わるチームだけを有料にして、そこにゲストを招く形が費用としては軽くなります。ただし、有料機能を全社で使いたいなら組織全体のアップグレードが案内されており、どちらを選ぶかは目的次第です。
ライセンス数の刻みもあわせて確認しておきます。最少は2人分で、ユーザー総数が30人以下は5人単位、30人から100人は10人単位、100人から500人は25人単位、500人超は50人単位で増えるとされています。ゲストは数えられないので、この刻みに影響するのは自社のメンバーだけです。
社外の人を最初から中に入れる設計にできるか
ここまでの内容を、進行のとりまとめという目的に引き戻します。
ゲストが無料であることの本当の価値は、費用が浮くことではありません。社外の相手を「入れるかどうか迷わなくてよくなる」ことです。迷う設計になっていると、迷った分だけ情報がツールの外に出ます。外に出た情報は、進行の全体像から抜け落ちます。
一方で、ゲストには制限があります。仕組みを作る側には回れず、統制をかけるには上位プランが要ります。社外のパートナーが進行の中心にいる体制、たとえば制作の実務を委託先が全部持っているような形では、ゲストという枠に収まらない場面が出てきます。
進行をひとつの場所にまとめる側の考え方としては、機能で絞らず、区切るのは人数とボードの数だけという設計を取っています。誰がどの機能を使えるかをプランで分けないので、社外の人が入っても使い方の説明が1通りで済みます。何が含まれるかはできることに、人数とボードでどう区切るかは料金にまとめてあります。
ただし、認めておくべき点もあります。シングルサインオンや監査ログのような統制の仕組み、そして外部サービスとの高度な連携では勝負していません。招待できる人を情報システム部門が中央で管理する必要があるなら、その機能を持つ道具を選ぶほうが確実です。機能と料金の違いを並べたものはAsanaとの比較にまとめています。他の候補も横に並べて見るなら比較の一覧、カード型で運用してきたチームならTrelloとの比較、国産の案件管理と比べるならBacklogとの比較が近い位置にあります。すでにTrelloで動いているならTrelloからの移行で取り込みの手順を確認できます。社外の人にどこまで見せるかという整理は安全性の考え方に、導入前に出やすい疑問はよくある質問にまとめてあります。
整理すると、ゲストの料金について確認すべきことは4つです。契約している場所が組織かワークスペースか。招く相手が自社の従業員でないか。招く人と外す人を誰が決めるか。そして、相手にどこまでの操作を求めるか。この4つが決まっていれば、無料であることを運用の前提に組み込めます。決まっていないまま人を増やすと、請求が読めなくなるか、規約の線を越えるか、退場処理が滞るかのいずれかが起きます。
この記事に書いた金額と条件は、いずれも2026年9月時点で公式の料金ページとヘルプセンターに掲載されていた内容です。契約や運用の変更を決める前には、必ず公式ページで最新の記載を確認してください。
Q1. Asanaでゲストを招待すると料金は増えますか？
組織で契約している場合、ゲストに料金は発生せず、ライセンス数にも数えられません。組織メンバー10人とゲスト2人の12人のチームなら、10人分のライセンスで足りると公式に説明されています。ただしワークスペースで契約している場合は扱いが異なり、ゲストを含むすべてのユーザーが有料プランの対象になります。
Q2. 誰がゲストとして扱われますか？
組織のメールドメインを持たないユーザーがゲストになります。クライアントやベンダー、フリーメールのアドレスを使う人が該当します。逆に、自社のメールドメインのアドレスを持つ人は自動的にメンバーとして扱われ、ライセンスの対象になります。判定はメールアドレスのドメインで決まります。
Q3. 費用を抑えるために社員をゲストにしてもよいですか？
認められていません。ヘルプセンターには、自社の従業員や関連会社の従業員のためにサブスクリプションを別途購入せずに、ゲストとしてアクセスさせることは許可されていないと明記されています。ゲストアカウントは、クライアントや請負業者、顧客など外部のビジネスパートナーとの協業を目的としたものと説明されています。
Q4. ゲストにできないことは何ですか？
ルールの作成やオーナーになること、タスクテンプレートの作成と編集、カスタムフィールドの設定の作成と編集、チームの作成とチーム設定の編集はできません。有料プランの組織の管理者にもなれません。一方で、カスタムフィールドの値を選ぶといった受動的な利用や、ルールをトリガーすることは可能です。