Notionでタスクを管理する｜自分で組み立てる前に考えること

「notion タスク管理」で検索する人の多くは、道具そのものを探しているというより、いま手元にある進行の記録が散らばっていて、その置き場所を決めかねている状態にあります。チャットに流れたお願い、表計算ソフトの工程表、頭の中にだけある「あの人が抱えている案件」。それらをひとつにまとめる場所として、名前が挙がりやすいのがNotionです。

ただし、検討に入る前にひとつ整理しておきたいことがあります。Notionのタスク管理は「まっさらな板に全部を自分で組み立てる」ものだと説明されることがありますが、公式の案内を読む限り、それは正確ではありません。プロジェクト管理向けの組み込みテンプレートが用意されていて、そこには2つのデータベースも、両者を結ぶリレーションも、担当者や期日のプロパティも、完了率のプログレスバーも、複数のビューも最初から入っています。自作が始まるのは、その先です。

この記事では、標準で配られる範囲と、利用者側の作業になる範囲の境目を、公式ヘルプと料金ページの記載にもとづいて切り分けます。そのうえで、5人から数十人のチームで進行を預かっている立場から見て、どこを検討材料にすればよいかを整理します。

タスク管理の道具選びが「自作」の話から始まってしまう理由

チームの進行をとりまとめている人が道具を探すとき、判断を狂わせやすいのは「その道具で何ができるか」という機能の一覧です。できることの数を並べた比較表を見ると、多機能なほうが正解に見えます。ところが実際に困るのは、機能が足りないことよりも、入力する人が増えないこと、そして誰かひとりが構造を作り込んだ結果、その人しか直せない状態になることのほうです。

Notionは自由度の高さで知られています。その自由度は、うまく効いたときには他の道具では代えがたい強みになります。仕様書、議事録、顧客の一覧、そして進行の板を、同じ場所に置いて相互に参照できる。ドキュメントとデータベースが地続きになっている構造は、資料と進行が行ったり来たりする仕事にはよく合います。設計の議論をページに書き、そこからタスクを起こし、完了したら元のページに戻って結論を書き足す。この往復が一箇所で完結するのは、実務ではかなり大きい利点です。

一方で、自由度の高さは「決めることの多さ」と裏表になります。どのプロパティを持たせるか、どのビューを標準にするか、ステータスをいくつに割るか。決めごとが多い道具は、決める人が優秀であるほどよく回り、決める人が離れると止まります。現場でしばしば出るのは、作り込んだ本人が異動したあと、誰も構造に手を入れられなくなったという話です。

だからこそ、検討の最初にすべきなのは「どこまでが配られていて、どこからが自分の作業か」の線引きです。この線を引かずに機能一覧だけを眺めると、実際には最初から入っているものを自作する前提で工数を見積もったり、逆に自作が必要な部分を「たぶん最初から入っているだろう」と見落としたりします。以下、公式ガイドの記述に沿って順に見ていきます。

標準で配られるプロジェクト管理テンプレートは3種類

Notionの公式ガイドは、プロジェクト管理向けの組み込みテンプレートが3種類あることを明記しています。どれを選んでも、あとからプロパティを足してカスタマイズできると書かれています。

There are three built-in project management templates in Notion, each with a designated use case in mind. Regardless of which one you start with, you'll be able to customize it by adding more properties later on. 出典: notion.com

呼び出し方も決まっていて、サイドバーの「Templates」から選びます。公式ガイドには「The Projects and tasks template is only available in the Notion app」とあり、テンプレートの利用はアプリ側からになる旨が書かれています。

To-do list：ひとつのデータベースで完結する形

いちばん軽い構成です。公式の説明では「This is a single database for simple task management where you can create, organize, and track your tasks.」とされ、単一のデータベースでタスクを作り、並べ替え、追跡するものと位置づけられています。想定されている使い道は「It's best used for one-off projects or individual task management where you want to keep your system as minimal as possible.」で、単発の案件や個人のタスク管理、そして仕組みを最小限に保ちたい場合です。

チームで使う場合、この形は入口としては軽い代わりに、案件と作業の階層が持てません。案件が3件ある状態までは一覧で足りますが、案件が10件を超えて、それぞれに5つ前後の作業がぶらさがると、ひとつの表の中で「どの案件の作業か」を見分けるための工夫を自分で足すことになります。フィルタやグループ化で対応はできますが、それは次のテンプレートが最初から持っている構造でもあります。

Projects & tasks：2つのデータベースをリレーションで結ぶ形

チームの進行管理として公式が想定しているのはこの形です。説明には「Ideal for team project management, these databases allow you to organize tasks by project and track progress across your team.」とあり、案件ごとにタスクを整理してチーム全体の進捗を追える構成だと書かれています。

重要なのは次の一文です。「Projects and tasks are two separate but related databases. You can record different information in each database and link them with one another.」つまり、プロジェクトとタスクは別々のデータベースとして用意され、両者を結びつけるところまでがテンプレートに含まれます。ここを自作する必要はありません。

親子関係についても明記があります。「Projects are the parent of tasks」「One project can have many tasks, but each task should only relate to a single project.」1つの案件に多数のタスクがぶらさがり、1つのタスクは1つの案件にだけ紐づく、という設計です。タスクは案件を完了させるための踏み石だ、という説明が添えられています。

この構造は、5人から数十人のチームで進行を預かる立場から見ると、実務にそのまま乗ります。案件の一覧で全体を眺め、案件を開くとその案件の作業だけが見える。この2階層は、多くのチームが表計算ソフトで手作業で再現しようとして、シートが増えて破綻するところです。

Projects, tasks & sprints：期間で区切る層を足した形

3つ目は、案件とタスクの上にもう一層を足したものです。「Selecting this template adds another layer to your projects and tasks, allowing you to arrange tasks into time-boxed sprints, ideal for project and issue tracking for engineering teams.」と説明されており、期間で区切ったスプリントにタスクを割り当てる形になります。想定はエンジニアリングチームの案件および課題の追跡です。

このテンプレートを選ぶと、タスクとスプリントの間にもリレーションが張られます。公式には「If you are using Tasks, Projects & Sprints, you'll have a relation between tasks and sprints.」と書かれています。開発以外のチームで2週間単位の区切りを持たない場合、この層は空回りしやすいので、無理に選ぶ必要はありません。案件と作業の2階層で足りるなら、Projects & tasks から始めるのが素直です。

テンプレートに最初から入っているプロパティとビュー

「テンプレートがある」と言われても、中身が空の器では意味がありません。公式ガイドは、何が最初から入っているかを具体的に書いています。ここは検討時にいちばん誤解されやすい部分なので、項目ごとに拾います。

プロジェクト側のプロパティと、完了率のプログレスバー

プロジェクトのデータベースについて、公式は「Your projects have properties like status, people, related tasks, and related task completion percent.」と書いています。ステータス、担当する人、関連するタスク、そして関連タスクの完了率。この4つが例として挙げられています。

完了率の計算も自動です。「The completion property calculates the number of completed tasks per project and displays the percentage as a progress bar.」案件ごとに完了したタスクの数を数え、その割合をプログレスバーとして表示する、と説明されています。進捗率の欄を作るために関数を自分で組む必要はない、ということです。

進行をとりまとめている人にとって、この一列があるかないかは実務でかなり効きます。案件の一覧を開いた時点で、どれが動いていてどれが止まっているかが線の長さで見える。表計算ソフトで同じことをやろうとすると、完了フラグを数える式を書き、行が増えるたびに範囲を直すことになります。その手間が最初から無い状態で始められます。

タスク側のプロパティ

タスクのデータベースについては「Tasks have properties for the assignee, due date and status.」と書かれています。担当者、期日、ステータスの3つです。

進行管理で最低限必要なのは、結局のところ「誰が」「いつまでに」「いまどこまで」の3点です。それが最初から用意されているので、テンプレートを開いた直後から作業を登録できます。逆に言えば、この3つ以外の情報、たとえば見積時間、優先度、依頼元、請求の有無といった列は、自分で足すことになります。ここが後述する「利用者側の作業」の始まりです。

最初から用意されている複数のビュー

ビューについても、公式ガイドは具体的に列挙しています。プロジェクトのデータベースには次の4つが入っています。

ひとつめは「Active」で、カンバンボードのビューです。「The "Active" view hides all projects that aren't marked as "Planning" or "In progress" to focus on and manage active projects.」計画中と進行中以外の案件を隠して、動いている案件だけに集中できるようにしたものです。

ふたつめは「Mine」で、「"Mine" view filters the database to show projects that you're tagged in dynamically.」自分が関係者として指定されている案件だけを動的に絞り込みます。

みっつめは「All」で、「The "All" table layout shows everything in the database.」データベースの全件をテーブル表示するものです。

よっつめが「Timeline」です。「Here, you'll see your projects arranged according to start and end date. By seeing how commitments overlap, you can make sure the workload is balanced and judge your team's capacity for new projects.」開始日と終了日にもとづいて案件が並び、約束事の重なりを見ることで負荷の偏りを確認し、新しい案件を受けられる余力を判断できる、と説明されています。

タスクのデータベース側にも3つのビューが入っています。「By project」は「The "By project" view splits your task list by related project.」で、関連する案件ごとにタスク一覧を分割します。「Mine」は「In "Mine", the database is filtered to show only tasks assigned to "Me"」で、自分に割り当てられたタスクだけに絞ります。「People」は「The "People" view is ideal for giving managers a view of each team member's to-do list.」とされ、メンバーごとのやることリストを管理する立場から見るのに向いた並びです。

つまり、カンバン、テーブル、担当者別、案件別、そして時系列の並びまでが、テンプレートの初期状態に含まれています。「Notionは全部を自分で組む道具」という要約は、この点で正しくありません。

権限の初期状態

権限についても記載があります。「When you add Projects & Tasks to a teamspace, everyone in the teamspace has access to those databases. This means that the whole team has visibility into what they need to do, and can take an active role in logging their progress in the database.」チームスペースにこのテンプレートを追加すると、そのチームスペースの全員がデータベースにアクセスできる状態から始まります。全員が自分のやることを見られて、進捗の記録に自分から参加できる状態が初期値だ、という設計です。

進行をとりまとめる人にとって、初期状態が「全員見える」なのか「見せる人を指定する」なのかは、運用の重さを左右します。前者であれば、まず全員に開いておいて、必要な部分だけ後から閉じる進め方が取れます。

どこから先が利用者側の作業になるか

ここまでが配られる範囲です。境目を公式の記述で確認します。

ビューの追加

公式ガイドは「In both databases, you can create any new views that you and your team would find helpful.」と書いています。両方のデータベースで、自分とチームにとって役立つ新しいビューを作れる、という案内です。裏を返せば、初期の7つ以外のビューは自分で作るものだ、ということになります。

たとえば「今週締切のものだけ」「外注先ごと」「請求待ち」といった切り口は、初期状態には入っていません。公式は柔軟性の説明として「You can create contextual views to focus on whatever matters in the moment, whether it be a view of one person's assigned tasks, tasks grouped by their parent project, or everything due in the next 7 days.」と述べており、今後7日以内に期限が来るものをまとめて見る、といったビューが作例として挙げられています。作れることは明記されていますが、作るのは利用者です。

ここで検討しておきたいのは、ビューを誰が作るかです。ビューの追加は、データベースの構造そのものを変える操作ではないため比較的軽い作業ですが、増えすぎると「どのビューを見ればいいのか」が分からなくなります。あるチームでは、ビューが十数個に膨らんだ結果、新しく入った人がまず「どれを見ればいいですか」と聞くところから始まる状態になったという話も出ます。作れることと、作ったあと維持できることは別です。

プロパティの追加

プロパティの追加手順も明記されています。「To add a new property to the database click on options …, Properties, and + New property.」オプションからプロパティを開いて新規追加する、という流れです。

プロパティの追加は、ビューの追加よりも影響が大きい操作です。列がひとつ増えるということは、全員の入力項目がひとつ増えるということでもあります。進行の板が使われなくなる原因として現場でよく挙がるのが、この入力項目の増えすぎです。管理する側は情報を細かく取りたくなりますが、入力する側から見れば、埋めなければならない欄が増えるほど後回しになります。入力する人が増えないと、進捗の表はすぐ嘘になります。

判断の目安としては、「その列が空欄のまま放置されたときに、誰かが困るかどうか」を先に考えることです。困らない列は、たいてい埋まりません。

作り込み全般と、決めておくべき運用のルール

公式は全体を「Starting with a projects & tasks template that's ready to go, you can create a fully customized system that suits the way you work best.」とまとめています。すぐ使える状態のテンプレートから始めて、自分たちの働き方に合った仕組みへ作り込んでいける、という位置づけです。

作り込みの前に決めておきたいことがいくつかあります。ステータスをいくつに割るか。「未着手」「進行中」「完了」の3つで足りるのか、「確認待ち」「差し戻し」を足すのか。担当者は必ず1人にするのか、複数を許すのか。期日は着手日と締切の両方を持つのか、締切だけにするのか。Timelineのビューを使うなら日付の範囲を持つプロパティが必要になるため、後者は結論に影響します。

そしてもうひとつ、誰が構造を変えられるのかを決めておくことです。全員が自由にプロパティを足せる状態は、始めた直後は快適ですが、半年後に列が20個ある板になりがちです。構造の変更は数人に限り、要望はその数人に集める運用にしておくと、あとから戻しやすくなります。

料金と人数の考え方

道具の検討では、料金の見方を間違えると議論がずれます。Notionの料金ページは、日本語ページと英語ページで別々の価格表を持っているのではなく、同一ページ内の「表示通貨：」というセレクタでJPYとUSDを切り替える形になっています。したがって「日本語ページの金額」ではなく、JPY表示の金額とUSD表示の金額として読むのが正確です。

プラン名と金額

日本語表記のプラン名は「フリー」「プラス」「ビジネス」「エンタープライズ」の4つです。英語表記では Free、Plus、Business、Enterprise となります。「ビジネス」には「おすすめ」のラベルが付いています。「プラス」と「エンタープライズ」にはアスタリスクが付いており、脚注に「ワークスペースによっては*プランが利用できない場合があります。」と書かれています。

2026年9月2日時点でJPY表示に切り替えて確認した金額は次のとおりです。単位表記はいずれも「メンバー/月」です。

プラン	年払い	月払い
フリー	￥0	￥0
プラス	￥1,650	￥2,000
ビジネス	￥3,150	￥3,800
エンタープライズ	カスタム料金	カスタム料金

同じページでUSD表示に切り替えると、年払いがFree $0、Plus $10、Business $20、月払いがFree $0、Plus $12、Business $24となります。JPY表示とUSD表示の換算方法や換算レートについての説明は、公式ページには見当たりませんでした。年払いについては「年間プランで最大20%お得に」という表示があります。

税の扱いについては、各有料プランのカード下部に「日本の消費税（該当する場合）」という注記が出ます。USD表示に切り替えても同じ注記が出て、英語表示では「Japanese Consumption Tax if applicable」となります。表示価格が税抜か税込かを明示する文言は、料金ページおよびヘルプの請求関連記事では確認できませんでした。読み取れるのは、該当する場合に日本の消費税が加算されるという点までです。プランと金額は改定されるため、検討の際は公式の料金ページで最新を確認してください。

無料プランでどこまで動かせるか

無料で試してから決めたい、という進め方は現実的です。ただし、フリープランには人数に関する独特の設計があります。

料金ページの比較表を見ると、フリープランの「ページとブロック」の欄には「個人の利用は無制限」「メンバーが2名以上の場合は制限あり」と書かれています。その制限の中身は、公式ヘルプ「ブロックの使用状況を理解する」の表に明記されています。ワークスペースのオーナーが1名だけなら無制限、2名以上になると「ワークスペースごとに1,000ブロック。その後、コンテンツを作成し続けるには、ワークスペースをNotionの有料プランにアップグレードする必要があります。」とされています。プラス以上のプランは、人数にかかわらず無制限です。

カウントの仕方にも注意書きがあります。「サインアップ後にワークスペースで作成されたコンテンツの量に基づいてブロックをカウントします。ブロックを削除したり、ゴミ箱を空にしたりしても、ブロック数は減りません。」つまり、試しに作って消した分も残ります。試用の段階で作りすぎると、上限に近づいた状態で本番を始めることになります。

そのほか、フリープランで数値の上限があるものを比較表から拾うと、ファイルのアップロードが「最大5MB」、ページの履歴が「7日」、外部ゲスト制限が「10」、チャートが「1」、notion.siteドメインが「1」です。ページの履歴はプラスが「30日」、ビジネスが「90日」、エンタープライズが無制限で、ファイルのアップロードはプラス以上がすべて無制限となっています。

なお、フリープランのメンバー数そのものに上限があるという記載は、公開資料では確認できませんでした。英語ヘルプには「Members can be added to workspaces on the Free Plan at no charge.」とあり、人数ではなくブロック数で制限される設計になっています。

課金はメンバー数、つまりシートの数

料金の軸ははっきりしています。「Notionの請求モデルは、ワークスペース内のメンバー数に基づいています。」と明記されており、「ワークスペース内で使用されているシート（ライセンス）の数に基づいて請求します。ワークスペース内の各メンバーに1シートが割り当てられます。」と説明されています。料金表の単位表記が「メンバー/月」なのも、人数課金であることの表れです。

出入りの多いチームでは、追加と削除のタイミングも効いてきます。月払いの場合は「月払プランのワークスペースにメンバーを追加する場合、通常の月次請求では翌月分のご利用料が請求されますが（新規メンバーを含む）、その前の請求サイクル中に追加されたメンバーに対する日割り料金も、遡って請求に追加されます。」とされています。削除については「ワークスペースからメンバーを削除した場合、請求額の減額は次回の請求サイクルから適用され、サイクル途中の日割り計算は行われません。既存の有料シートは、現在の請求期間が終了するまで引き続き利用できます。」と書かれています。減らしてもその期間は使える代わりに、その月の請求はそのまま、という理解になります。

人数で課金される仕組みは、常時関わる人が固定されているチームには分かりやすい形です。逆に、月ごとに関わる人が入れ替わる体制や、短期間だけ確認に入る人が多い体制では、シートの管理そのものが仕事になります。道具を選ぶときに、機能ではなく機能で絞らず、区切るのは人数とボードの数だけという単純な区切り方を採る製品を並べて比べると、この管理の重さの差が見えます。料金の考え方は料金のページでも整理しています。

ゲストと外部の人をどう扱うか

外部の協力者や取引先に進行を見せたい場面は、5人から数十人のチームではほぼ必ず出てきます。Notionにはゲストという仕組みがあります。

公式の定義は「Guests are individuals external to your company or organization who you invite into your workspace on a page-by-page basis.」で、ページ単位で招く外部の人、とされています。例として、異なる組織のメールドメインを持つ人、作業へのフィードバックを求めたい取引先、貢献やレビューをしてもらいたい友人や家族、指導者が挙げられています。

メンバーとの違いも明記されています。「They can't be given workspace-wide access. They must be invited to individual pages in order to view them and their sub-pages.」ワークスペース全体へのアクセス権は渡せず、見せたいページに個別に招く必要があります。また「They can't add new connections to your workspace.」と、接続の追加はできないとされています。

人数の扱いについては、課金対象がメンバーであることが明記されており、ゲストは「ワークスペースに新しいメンバーを追加せずにNotionで共同作業を行いたい場合は、ゲストを特定のNotionページに招待できます（ただし、プランのゲスト数の上限に達していない場合に限ります）。」と、メンバー追加とは別の扱いで説明されています。ただし、有料プランでゲストが一切課金されないと直接述べた文言は、公開資料では確認できませんでした。読み取れるのは、課金対象がメンバーであることと、ゲストはプランごとの「外部ゲスト制限」という別枠で管理されることまでです。

運用上の注意として、公式は誤ってメンバーに追加しない手順まで案内しています。「メールアドレスを入力したら、招待をクリックする前にメールアドレスにカーソルを合わせて、ゲストとして追加されていることを確認します。」「ゲストをメンバーにアップグレードするかどうかを尋ねられます。今はスキップを選択して、そのページに無料で追加されるようにします。」注意喚起がヘルプに書かれているということは、間違えやすい箇所だということでもあります。

ゲスト数の上限は、フリーが10、プラス以上はすべて「無制限のゲスト」です。上限に達した場合の挙動として「If your workspace is above the guest limit for your plan, new users that you share content with can only be added as a member (instead of as a guest) if they belong to your workspace's email domains.」という記載があります。外部の人が多いチームがフリープランで始めると、この上限に先に当たる可能性があります。外部の人にどこまで見せるかという設計は、安全性の考え方のページで、権限の切り方の観点から整理しています。

工程表として使う場合のタイムラインビュー

工程表を引く必要があるチームにとって、時系列のビューが使えるかどうかは判断材料になります。

公式ヘルプの説明は「Notionのタイムラインは、タスクとスケジュールを把握できるデータベースで、時間や日、週、月、年など、時系列でプロジェクトを表示できます」です。作り方は、新しいページを作って「ここから始めるで•••をクリックし、タイムラインを選択します。」という手順か、任意のページで「/Timeline view」と入力してEnterを押す方法が案内されています。既存のデータベースに追加する場合は、データベース名または現在のビュー名の横にある「+」をクリックして、ドロップダウンからタイムラインを選びます。利用条件として、日付の範囲を持つ日付プロパティが必要である旨が記載されています。

プランによる制限については、慎重に扱う必要があります。ヘルプ記事「タイムラインビュー」にはプランを限定する注記が見当たらず、料金ページの比較表にも「タイムラインビュー」という行そのものが存在しません。データベース関連の行は「サブタスクと依存関係」「カスタムプロパティとフィルタリング」「チャート」「フォーム」「ダッシュボード」の5つで、このうち「サブタスクと依存関係」と「カスタムプロパティとフィルタリング」はフリーを含む全プランにチェックが付いています。したがって、タイムラインビューが有料プランからであるという記載は、公開資料では確認できませんでした。制限があるとも、無いとも明記されていないため、断定はできません。実際に検討する段階では、無料の状態で試して確かめるのが確実です。

なお、前述のとおり、公式のプロジェクト管理ガイドでは、標準テンプレートのプロジェクトデータベースに最初から「Timeline」ビューが含まれていると説明されています。工程表の枠組み自体は配られている、という理解でよいことになります。

ここで実務の話をひとつ。工程表を表計算ソフトで引いているチームでは、1人が引き直している間、他の人はその表を見られません。ファイルを開いていると編集がぶつかるからです。データベースのビューとして工程表を持つ形は、その待ち時間が構造的に発生しません。この一点だけでも、表計算ソフトから移る理由になります。

書き出しと取り込み、つまりデータを持ち出せるか

道具を入れるときに見落とされやすく、辞めるときに効いてくるのが、データの出し入れです。

書き出しについて、公式ヘルプは「PDF、CSV、HTMLなどの形式でコンテンツを共有する手順を解説します！ Notionのページやデータベース、ワークスペース全体を、いつでもエクスポートできます」と説明しています。案内されている形式は PDF、HTML、Markdown、CSV の4つです。

プランによる差もあります。料金ページの比較表には「ワークスペース全体のエクスポート（HTML、Markdown、CSV）」という行があり、フリーを含む全プランにチェックが付いています。一方「ワークスペース全体のエクスポート（PDF）」の行は、ビジネスとエンタープライズのみです。PDF書き出しの「サブページを含める」オプションについても「ビジネスプランまたはエンタープライズプランをご利用の場合は、サブページを含めるオプションのご利用が可能です。」と書かれています。

ワークスペース全体の書き出しには、いくつか実務上の制約があります。ダウンロードリンクが記載されたメールが届き、そのリンクの有効期限は7日間です。処理時間については「エクスポートの処理には、ワークスペースのサイズによっては最大30時間かかる場合があります。」とされています。実施できるのはデスクトップまたはWebのみです。そして重要な注記として「エクスポートしたワークスペースコンテンツを再アップロードしても、ワークスペースを即座に再現することはできません。」とあります。書き出したものをそのまま戻せば元通り、というわけではない点は、移行を考える段階で押さえておく必要があります。

書き出せないものも明記されています。データベースの「フォーム」ビューは現時点でエクスポートできず、代わりにテーブルビューから質問と回答を書き出すよう案内されています。カスタム絵文字はPDF書き出しでは表示されません。PDF書き出しに失敗した場合はHTMLとして書き出される、という注記もあります。また、他のユーザーのプライベートページなど、実行者にアクセス権がないページは書き出されません。

取り込みについては、対応形式としてプレーンテキスト（.txt）、テキストとマークダウン（.txt、.md、.markdown）、Microsoft Word（.docx）、CSV（.csv）、HTML（.html）、PDF（.pdf）、ZIP（.zip）が列挙されています。他のツールからの取り込みについては「Confluence、Asana、Evernote、Trelloなど、さまざまなアプリからのデータインポートにも対応しています。」とされ、個別のページが用意されているものとして Confluence、Asana、Monday.com が挙げられています。取り込みはデスクトップとWebで利用でき、モバイルではまだ利用できないと明記されています。複数ファイルの同時取り込みはPDF、HTML、Markdown、Word、プレーンテキストで可能ですが、CSVとZIPは同時に複数を取り込めません。

移行を検討するときの見方としては、「入れるときにどれだけ楽か」よりも「出すときに何が欠けるか」を先に見るのが安全です。板型のツールから移す場合の考え方はTrelloからの移行にまとめてあります。自動で取り込める範囲には限りがあり、それ以外は手作業になる、という前提で工数を見ておくのが現実的です。

日本語対応と、データがどこに置かれるか

日本語の対応状況ははっきりしています。公式ヘルプ「言語の変更」に対応言語が列挙されており、日本語は含まれています。列挙されているのは英語、英語（英国）、日本語、フランス語、ドイツ語、スペイン語（スペイン）、スペイン語（中南米）、ポルトガル語（ブラジル）、中国語（簡体字）、中国語（繁体字）、オランダ語、ノルウェー語、スウェーデン語、デンマーク語、フィンランド語、韓国語、ベトナム語、タイ語、インドネシア語、アラビア語、ヘブライ語、イタリア語です。設定から環境設定に進み、言語と時間の下にあるドロップダウンで切り替えます。モバイルではシステム側の言語設定に従います。

ひとつ留意点があります。日本語のヘルプ記事の上部には「このコンテンツはAI翻訳されている可能性があります」という注記が表示されます。社内の説明資料などでヘルプの文言をそのまま根拠にする場合は、英語版と突き合わせておくほうが安全です。

データの保管場所については、選べるプランが限られます。公式ヘルプには「営業経由で購入される（つまり、アカウントチームと連携している）エンタープライズプランのお客様は、既存のデータを指定したデータ地域へ移行できます。」とあり、データレジデンシーの移行はエンタープライズプランが対象です。選べる地域として US-West-2（オレゴン）、EU-Central-1（フランクフルト）、AP-Northeast-1（東京）、AP-Northeast-2（ソウル）が表に挙げられており、日本国内（東京）での保存が選べるのはエンタープライズプランに限られます。

既定の状態については「デフォルトでは、データは引き続き米国に保存されます。」と明記されています。インフラは「NotionはAmazon Web Servicesと提携し、地域のデータセンターを通じて信頼性の高い高性能データストレージを提供しています。」とされています。地域内に保存されるのはページの内容、アップロードしたファイル、検索インデックスなどで、アカウント情報や利用状況のデータは対象外と説明されています。

取引先との契約で保管場所の指定がある場合や、業界の指針で国内保存が求められる場合は、この点が先に効いてきます。逆に、そうした要件が無いチームであれば、実務上の判断材料としての優先度は下がります。

進行の板をどう選ぶか、比較の軸の置き方

ここまでの整理をふまえて、どういう場合にNotionのままがよく、どういう場合に他の形を検討する価値があるかを書きます。

そのままがよいのは、まず、資料と進行が同じ場所にあることに価値があるチームです。仕様書や議事録がタスクのすぐ隣にあり、ページからタスクへ、タスクからページへ行き来する仕事の進め方をしているなら、その往復を切り離すと不便になります。次に、構造を作り込める人がチーム内にいて、その人が今後も関わり続ける見込みがある場合。自由度は、使いこなす人がいるときに最大の強みになります。そして、社内の情報基盤としてすでにNotionが定着していて、進行だけを別の場所に出すとかえって二重管理になる場合も、動かす理由は薄いです。

一方で、検討の余地が出るのはこういう場合です。ひとつは、入力する人が増えない状態が続いているとき。列が多く、決まりごとが多いほど、たまにしか触らない人は入力を後回しにします。進行の板は、更新されなければただの古い記録です。もうひとつは、構造を作り込んだ本人しか手を入れられなくなっているとき。これは道具の欠点というより運用の問題ですが、道具の自由度が高いほど起きやすい現象ではあります。三つめは、外部の協力者が多く、シートとゲストの管理そのものが手間になっているとき。

比較を進めるときは、機能の数ではなく、次の3点で並べると判断がぶれません。1つめは、標準で配られる範囲がどこまでか。2つめは、入力する人にとって埋める欄がいくつあるか。3つめは、辞めるときに何が持ち出せるか。この3つは、どの製品でも公開資料から確認できます。

板型のツールを並べて見たい場合は、比較の一覧に主要な製品との違いをまとめてあります。個別には、カードを並べる形の代表格であるTrelloとの比較、タスクの依存関係やワークフローの自動化に強いAsanaとの比較、この記事で扱ったNotionを板型の道具と並べたNotionとの比較、画面の作り込みと自動化を売りにするmonday.comとの比較、日本の開発現場で使われることが多いBacklogとの比較、国内発のカンバン型であるJootoとの比較を用意しています。どれも、相手のままがよい場合を先に書く方針で書いています。

板型のタスク管理から見た、Notion検討時の考察

進行をひとつの板にまとめる道具を作る側の視点から、Notionを検討している人に伝えたいことを整理します。

第一に、Notionのテンプレートが最初から持っている構造は、多くのチームにとって十分です。プロジェクトとタスクの2つのデータベース、両者のリレーション、ステータスと担当者と期日、完了率のプログレスバー、カンバンとテーブルと担当者別とTimelineのビュー。この一式が配られている道具は、そう多くありません。「Notionは全部自作」という前提で見送るのは、判断としてもったいないです。

第二に、決めるべきことが多い道具は、決められる状態のチームで強く、そうでないチームでは重くなります。どちらが優れているという話ではなく、チームの状態との相性の問題です。進行の管理に割ける時間が週に1時間しかない立場から見れば、設定項目が少ないほうが結果として板が生き残ります。逆に、専任で仕組みを整える人がいるなら、作り込める道具のほうが伸びます。

第三に、料金の考え方は道具ごとに異なります。人数（シート）で課金される形は、常時関わる人が固定されているチームでは読みやすい反面、出入りが多いと管理が仕事になります。板型のタスク管理ツールとしては、機能で絞らず、区切るのは人数とボードの数だけという考え方を採る形もあります。どの機能がどのプランからか、を毎回確認しなくてよいぶん、検討にかかる時間が減ります。できることの範囲はできることにまとめています。

第四に、板型のツールにも当然できないことがあります。リポジトリ機能は持っておらず、自動化と外部連携の豊富さで勝負する製品ではありません。画面は日本語のみで、自動で取り込めるのはTrelloからだけです。Notionの自由度や連携の広さが必要な仕事であれば、その必要性のほうが優先されます。相手を貶して選ばせる比較には意味がありません。

最後に、検討の順番についてです。多くのチームは、まず候補を並べて機能を比べ、そのあとで運用を考えます。順番を逆にしたほうが早く決まります。いま進行が止まっている原因は、機能が足りないからなのか、入力する人が増えないからなのか、それとも構造を触れる人が1人しかいないからなのか。原因を先に特定すれば、必要な機能の一覧は自然と短くなります。短い一覧で比べれば、選択肢は数個に絞れます。導入前によく出る疑問はよくある質問にまとめてありますので、社内で検討を進める際の材料としてください。

Q1. Notionのタスク管理は、最初から全部を自分で作る必要がありますか？

その必要はありません。公式のプロジェクト管理テンプレートは3種類あり、Projects & tasks を選ぶと、プロジェクトとタスクの2つのデータベース、両者を結ぶリレーション、ステータス・担当者・期日のプロパティ、完了タスクから計算される完了率のプログレスバー、カンバンやテーブルやTimelineなど複数のビューが最初から入っています。自作が始まるのは、ビューの追加とプロパティの追加から先です。

Q2. 無料プランで何人まで使えますか？

フリープランのメンバー人数そのものの上限は、公開資料では確認できませんでした。制限されるのは人数ではなくブロック数で、ワークスペースのオーナーが1名なら無制限、2名以上になるとワークスペースごとに1,000ブロックまでとされています。削除しても数は減らない仕組みなので、試用の段階で作りすぎると本番前に上限へ近づく点に注意してください。

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

2026年9月2日時点のJPY表示では、年払いでプラスが￥1,650、ビジネスが￥3,150、月払いでプラスが￥2,000、ビジネスが￥3,800です。単位はいずれもメンバー1人あたりの月額表記で、フリーは￥0、エンタープライズはカスタム料金です。税抜か税込かを明示する文言は確認できず、「日本の消費税（該当する場合）」という注記のみが表示されます。料金は改定されるため公式ページで最新を確認してください。

Q4. 工程表として使うタイムラインビューは有料プランからですか？

プラン制限に関する記載は、ヘルプ記事にも料金ページの比較表にも見当たらず、公開資料では確認できませんでした。制限があるとも無いとも明記されていないため断定はできません。ただし公式のプロジェクト管理ガイドでは、標準テンプレートのプロジェクトデータベースに最初からTimelineビューが含まれると説明されています。利用には日付の範囲を持つ日付プロパティが必要です。