話題の「NotionからLinearへ」を全部実測してみた。1つだけ逆の結果が出ました
話題の「NotionからLinearへ」を全部実測してみた。1つだけ逆の結果が出ました
SNSで見かけた「Claude CodeでのタスクをNotionからLinearに移そうと思う」という投稿。 挙げられていた理由がどれも納得できるものだったので、ひとつずつ数字で確かめてみました。
結果、6つの論点のうち**逆の結果が出たのは1つだけ**でした。 「ステータス更新などでAPI呼び出しが増えやすい」という指摘です。 42件をまとめて移す操作で、APIを呼んだ回数はLinearが**45回**、Notionが**5回**。 件数が増えると増えるのは、むしろLinearのほうでした。
かかった費用は0円。何をどう測って、どこで考えが変わったのか、順に書いていきますね。
きっかけは、たまたま見かけた投稿
ある日、SNSでこんな投稿を見かけました。
Claude Codeを使ったタスク管理を回す中で、NotionからLinearに変えようかかなり検討しています。 理由はシンプルで、AIとの相性がかなり良いからです。
■ Notionの課題 ・DBの自由度が高く、AIが毎回構造を読み解く必要がある ・ステータス更新などでAPI呼び出しが増えやすい
Notionのデータベースって、自由に作れるのがいいところですよね。「ステータス」って名前の列を作る人もいれば「進捗」にする人もいる。選択肢も「未着手/対応中/完了」だったり「ToDo/Doing/Done」だったり、人それぞれです。
AIからすると、毎回「このデータベース、どんな作りだったっけ？」って確認するところから始まるわけです。それは確かに手間がかかりそう。
一方でLinearは、タスクの形が最初から決まっています。ステータスも担当者も優先度も、最初からある。だからAIは調べなくていい、と。
そうなん？
ちょうど手元に試せる環境があったので、実際に測ってみることにしました。
そもそも、無料で試せるの？
まず気になったのがお金の話でした。会社で使うツールを検討するとき、ここが引っかかると話が進みません。
調べてみたら、Linearは無料で普通に試せます。
無料プランで使えるのはこんな感じ。
タスク（Issue）は250件まで
メンバーは何人でもOK
チームは2つまで
APIも使える
ファイルは10MBまで
有料はBasicが月$10/人、Businessが月$16/人（年払い）です。
よかったのは、メンバー数が無制限なのと、無料でもAPIが使えるところ。今回いちばん試したかった「AIからLinearを動かす」がそのままタダでできます。クレカの登録もいりませんでした。
つまずきポイント：会社名が弾かれた
Googleアカウントでサクッとサインアップして、ワークスペースを作ります。
ここで、いきなり止まりました。
会社名の「Visk.co」を入れたら、こんなエラーが出たんです。
Unable to create workspace Organization name cannot contain a URL.
「組織名にURLを入れちゃダメ」って言われてます。どうやら .co の部分がドメインだと思われたみたい。ドットを消して「VISK」にしたら、あっさり通りました。
会社名に .co とか .jp が入ってる方は、たぶん同じところで止まります。 頭の片隅に置いておくといいかもしれません。
あともう一つ。作成画面に「Enable access for（自社ドメイン）」ってトグルがあります。これをONにすると、同じドメインのメールを持ってる社員が誰でも入ってこられる状態になるんですね。まだ試している段階だったので、OFFにしておきました。あとから変えられます。
AIとつなぐのは、コマンド1行だけ
さて本題です。ターミナルでこの1行を打ちます。
claude mcp add --transport http --scope
--scope user を付けているのは、どのフォルダで作業してもLinearが使えるようにするためです。これがないと、打った場所でしか有効になりません。地味だけど大事なところ。
あとはClaude Codeを起動して /mcp と打ち、linear を選んで「Authenticate」。ブラウザが開くので、作ったワークスペースを選んで承認するだけです。
「Authentication successful」と出たら完了。ほんとにこれだけでした。
まずは軽く動かしてみる
つながったら、ターミナルに日本語で話しかけます。
これだけでタスクが一覧で返ってきました。コマンドを覚える必要はありません。
じゃあ作るほうも、ということでこんな指示を。
一発で4件、優先度も期限も担当者も入った状態でできました。
ただここで、「あれ、どこにできたんかな？」 となりました。
Linearの画面を見ても、作ったはずのタスクが出てこないんです。しばらく探して分かったんですが、新しく作られたタスクは「Backlog」というステータスで入るので、初期表示の「Active」タブには出てこないんですね。
Linearのステータスはこんな感じに分かれています。
Backlog … いつかやる。まだ着手予定なし
Todo … 今やると決めたもの
In Progress … いま進めてる
「Active」に出てくるのはTodo以降。「Backlog」タブか「All issues」タブに切り替えたら、ちゃんといました。
初めて触る方はここで一回「?」ってなると思うので、先に書いておきますね。
本番：Notionの42件を引っ越しさせてみる
ここからが本題です。実際に使っているNotionのタスクリストを、まるごとLinearに持っていきます。
いきなり壁：ゲストだと接続できない
Notion側もAIとつなごうとしたんですが、認証画面でストップ。
あなたはゲストのため、Notion MCPに接続できません。ワークスペースオーナーにメンバーへのアップグレードを依頼するか、ワークスペースを切り替えてください。
自分は会社のNotionにゲストとして入っています。
Notionって、ゲストは無料だけどメンバーは1人ずつ課金（Plusなら月$10、Businessなら月$20）という仕組みなんですね。なので「ちょっとの間だけメンバーにして」とお願いすると、その分のお金がかかることになります。
……でも、よく考えたらページの中身は普通に見えているわけです。だったら手でエクスポートすればいいだけでした。壁っぽく見えて、実は回り道でなんとかなるやつでした。
CSVで書き出す
Notionのタスクリストを開いて、右上の「•••」→「エクスポート」→形式は「マークダウンとCSV」。
ページの中に埋め込まれたデータベースの場合は、データベースだけを全画面で開いてからエクスポートすると、余計なものが混ざらずスッキリ取り出せます。
出てきたCSVには、概要・ステータス・担当・優先度・期日・親タスクといった列がそのまま入っていました。全部で123件、そのうち未完了が42件です。
公式ルートがないので、AIに投げる
実は、LinearにはNotionからの公式インポート機能がありません。 用意されているのはJira・GitHub Issues・Asana・Shortcut用のインポーターと、あとはCSVをCLIツールで取り込む方法くらい。Notionは入っていないんです。
なので普通なら、CSVの列名をLinearの形式に手で整えることになります。今回はそこをAIに任せました。
結果は42件ぜんぶ移行できました。ステータスの読み替えも、親子関係も、日本語の日付（「2026年2月13日」）の変換も、指示どおりに通っています。
この記事で見てほしいのは移行の成否ではなく、このとき裏で何回APIを呼んでいたかのほうです。
で、Notionだと何回かかるの？
ここまでは「Linearでうまくいった」という話でしかありません。最初の投稿を確かめるには、Notion側の数字がないと比べられませんよね。
そこで、自分の個人Notionに（こっちは自分がオーナーなので普通につながります）同じ作りのデータベースを用意して、まったく同じことをやらせてみました。
比べたのはこの4つです。
一覧を読む
4件まとめて作る
2件のステータスを変える
42件をまとめて移す
ひとつ気をつけたのが、測る前にAIの記憶を一度リセットしたこと。直前に自分でデータベースを作らせていると、構造を覚えたままになってしまいます。それだと「毎回構造を読み解く必要がある」という話を確かめられないので、まっさらな状態から測りました。
測った結果、こうなりました
いちばん大事な数字
42件をまとめて移す操作で、こうなりました。
Linear：45回 / Notion：5回
あれ？…。中身を見たら理由がはっきりします。
Linearは save_issue というのを42回、つまり1件につき1回ずつ呼んでいました。件数が増えれば、その分そのまま増えていく作りです。
対してNotionは、create-pages という命令ひとつで36件をまとめて処理していました。件数が増えても、呼ぶ回数はほとんど変わりません。
投稿にあった「ステータス更新などでAPI呼び出しが増えやすい」という指摘、件数が多い場面ではむしろLinearのほうに当てはまるという結果でした。
トークンのほうはどうか
「AIが毎回構造を読み解く必要がある」というのは、呼び出し回数じゃなくてトークンの量に出るはずです。そこも調べました。
3つの操作を合わせた出力トークンは、Linear 2,740 / Notion 2,862。
ほぼ同じでした。 差は4%くらい。「Notionのほうが重い」とは言えない数字です。
むしろ意外だったのが、一覧を読むときのキャッシュ書き込み量。Linear 42,663 / Notion 10,162 と、Linearのほうが4倍も多かったんです。
これはたぶん、AIに読ませる「説明書」の量の差だと思います。Linear側は55個、Notion側は28個のツールを持っているので。「構造が決まってる」というのは、裏返すと「その構造をAIに教える説明が長い」ということでもあるわけですね。
（※ここは数字からの推測です。他の要因が混じっている可能性もあります）
少ない件数だと？
参考までに、数件レベルの操作も並べておきます。
操作 | Notion | Linear |
|---|---|---|
一覧を読む | 3回 | 2回 |
4件作る | 1回 | 4回 |
2件ステータス変更 | 3回 | 2回 |
読むのと変えるのはLinearが少なくて、作るのはNotionが少ない。数件ならほぼ互角で、差がつくのは件数が増えたときだけ、という感じでした。
まとめて処理して、抜け落ちない？
1件ずつなら失敗に気づけますが、42件を1回で処理すると1件抜けても分かりません。気になったので、元のCSVと移行後を突き合わせました。
食い違いゼロでした。 件数（42/42/42）、取りこぼし、重複、ステータス・優先度・期日、すべて一致。この規模なら心配なさそうです。
ただ、処理直後のAIの報告はこうでした。
既存6件＋今回42件＝48件 未開始 41 / 進行中 3 / pending 6
41 + 3 + 6 は 50 です。データは正しくて、報告の計算だけが間違っていました。
AIの作業より、AIの「できました」のほうが危ない。 最後に数を数えるのは、人間の仕事として残しておいたほうがよさそうです。
（ちなみに元データには同じ名前のタスクが2件ありました。移行されたのは未完了の1件だけで正解でしたが、タイトルだけで照合すると取り違えます）
で、この数字って気にすることなの？
ここまで回数の話をしておいてなんですが、書きながらずっと引っかかっていました。
API呼び出しの回数って、使う側が気にすることなんだろうか。
正直に言うと、今回くらいの規模ならほぼ関係ありません。トークンの量もほぼ同じでしたし、どちらも待たされている感覚はありませんでした。
回数が効いてくるのは、こういう場面くらいです。
数百件・千件をいっぺんに処理して、レート制限に当たるとき
何かに失敗したとき、どこでコケたか切り分けたいとき（1件ずつのほうが分かりやすい）
つまり、元の投稿が「変える理由」に挙げていた指標は、測ったら逆で、しかもそもそもあまり関係なかったということになります。
じゃあ意味のない検証だったかというと、そうでもなくて。測ったからこそ、本当に差が出ていたのは別のところだったと分かりました。次はその話です。
それでもLinearが良かった、2つのこと
数字だけ見ると「じゃあNotionのままでいいじゃん」となりますが、触った感触はまったく逆でした。
1. 想定外の値を、うまく飲み込んでくれる
移すタスクの中に、ステータスが pending のものが6件ありました。これ、Notion側で使っていた独自の呼び方です。
Notionだと：選択肢に pending がなくて、APIに拒否されました。「新しく選択肢を追加しますか？」と聞かれて、データベースの作り自体を変えることに。
Linearだと：「pendingはBacklogに読み替えて」という一言で、そのまま通りました。最初から決まった箱（Backlog / Todo / In Progress / Done / Canceled）があるので、近いところに置けるんですね。
これ、まさに「構造が決まってることの強み」でした。面白いのは、投稿が「Notionの弱点」として挙げていた"自由度の高さ"が、API呼び出し回数じゃなくてこっちに出てきたことです。指摘自体は正しくて、出る場所が違った、という感じでしょうか。
2. キーボードだけで進む
これは触ってみないと分からないところでした。
C… 新規作成がパッと開くCmd + K… コマンドパレット。やりたいことを名前で呼べるI… 担当を自分にするS/P… ステータス / 優先度を変える
しかもコマンドパレットには、それぞれの操作の横にショートカットキーが書いてあるんです。使いながら自然に覚えられるようになっていて、慣れるほど速くなる感じ。よく考えられてるなあと思いました。
複数行を選んでからキーを押せば、まとめて処理もできます。担当者が空っぽだった6件を一気に自分に割り当てるのも、キーひとつでした。
で、結局どっちがいいの？
今回やってみて感じたことをまとめます。
Linearが向いてそうなのは
タスクの形（ステータス・優先度・担当）を決めて回したい
キーボード中心でサクサク進めたい
開発のタスクとして管理したい
Notionのままでよさそうなのは
大量のデータをまとめて処理する場面が多い
タスクと同じ場所に資料や議事録も置いておきたい
今の運用にとくに不満がない
そして現実的には、「タスクはLinear、資料はNotion」の使い分けに落ち着く気がします。競合というより、得意なことが違うツールでした。
「AIとの相性」という言葉が指していたのは、API呼び出しの少なさじゃなかった。 決まった形があるおかげで、AIがふわっとした指示をちゃんとした形にしてくれる——測ってみて分かったのは、そういうことでした。
正直に、この検証の弱いところ
ちゃんと信じてもらえる記事にしたいので、うまく測れていないところも書いておきますね。
どの操作も1回ずつしか測っていません。 何度かやって平均を取ったわけではないので、多少のブレは入っているはずです
Linear側とNotion側で、指示の文言が完全には同じではありません。 Linearで4件作ったときは「担当者を設定して」も入れていましたが、Notion側には入れていません。回数の差にその分が混じっている可能性があります
確かめたのは42件の規模だけです。 数百件になったときに同じ結果になるかは分かりません
この結果は変わりえます。 Linear側がまとめて処理する仕組みを追加すれば、数字はひっくり返ります
参考リンク
SNSで見かけた「Claude CodeでのタスクをNotionからLinearに移そうと思う」という投稿。 挙げられていた理由がどれも納得できるものだったので、ひとつずつ数字で確かめてみました。
結果、6つの論点のうち**逆の結果が出たのは1つだけ**でした。 「ステータス更新などでAPI呼び出しが増えやすい」という指摘です。 42件をまとめて移す操作で、APIを呼んだ回数はLinearが**45回**、Notionが**5回**。 件数が増えると増えるのは、むしろLinearのほうでした。
かかった費用は0円。何をどう測って、どこで考えが変わったのか、順に書いていきますね。
きっかけは、たまたま見かけた投稿
ある日、SNSでこんな投稿を見かけました。
Claude Codeを使ったタスク管理を回す中で、NotionからLinearに変えようかかなり検討しています。 理由はシンプルで、AIとの相性がかなり良いからです。
■ Notionの課題 ・DBの自由度が高く、AIが毎回構造を読み解く必要がある ・ステータス更新などでAPI呼び出しが増えやすい
Notionのデータベースって、自由に作れるのがいいところですよね。「ステータス」って名前の列を作る人もいれば「進捗」にする人もいる。選択肢も「未着手/対応中/完了」だったり「ToDo/Doing/Done」だったり、人それぞれです。
AIからすると、毎回「このデータベース、どんな作りだったっけ？」って確認するところから始まるわけです。それは確かに手間がかかりそう。
一方でLinearは、タスクの形が最初から決まっています。ステータスも担当者も優先度も、最初からある。だからAIは調べなくていい、と。
そうなん？
ちょうど手元に試せる環境があったので、実際に測ってみることにしました。
そもそも、無料で試せるの？
まず気になったのがお金の話でした。会社で使うツールを検討するとき、ここが引っかかると話が進みません。
調べてみたら、Linearは無料で普通に試せます。
無料プランで使えるのはこんな感じ。
タスク（Issue）は250件まで
メンバーは何人でもOK
チームは2つまで
APIも使える
ファイルは10MBまで
有料はBasicが月$10/人、Businessが月$16/人（年払い）です。
よかったのは、メンバー数が無制限なのと、無料でもAPIが使えるところ。今回いちばん試したかった「AIからLinearを動かす」がそのままタダでできます。クレカの登録もいりませんでした。
つまずきポイント：会社名が弾かれた
Googleアカウントでサクッとサインアップして、ワークスペースを作ります。
ここで、いきなり止まりました。
会社名の「Visk.co」を入れたら、こんなエラーが出たんです。
Unable to create workspace Organization name cannot contain a URL.
「組織名にURLを入れちゃダメ」って言われてます。どうやら .co の部分がドメインだと思われたみたい。ドットを消して「VISK」にしたら、あっさり通りました。
会社名に .co とか .jp が入ってる方は、たぶん同じところで止まります。 頭の片隅に置いておくといいかもしれません。
あともう一つ。作成画面に「Enable access for（自社ドメイン）」ってトグルがあります。これをONにすると、同じドメインのメールを持ってる社員が誰でも入ってこられる状態になるんですね。まだ試している段階だったので、OFFにしておきました。あとから変えられます。
AIとつなぐのは、コマンド1行だけ
さて本題です。ターミナルでこの1行を打ちます。
claude mcp add --transport http --scope
--scope user を付けているのは、どのフォルダで作業してもLinearが使えるようにするためです。これがないと、打った場所でしか有効になりません。地味だけど大事なところ。
あとはClaude Codeを起動して /mcp と打ち、linear を選んで「Authenticate」。ブラウザが開くので、作ったワークスペースを選んで承認するだけです。
「Authentication successful」と出たら完了。ほんとにこれだけでした。
まずは軽く動かしてみる
つながったら、ターミナルに日本語で話しかけます。
これだけでタスクが一覧で返ってきました。コマンドを覚える必要はありません。
じゃあ作るほうも、ということでこんな指示を。
一発で4件、優先度も期限も担当者も入った状態でできました。
ただここで、「あれ、どこにできたんかな？」 となりました。
Linearの画面を見ても、作ったはずのタスクが出てこないんです。しばらく探して分かったんですが、新しく作られたタスクは「Backlog」というステータスで入るので、初期表示の「Active」タブには出てこないんですね。
Linearのステータスはこんな感じに分かれています。
Backlog … いつかやる。まだ着手予定なし
Todo … 今やると決めたもの
In Progress … いま進めてる
「Active」に出てくるのはTodo以降。「Backlog」タブか「All issues」タブに切り替えたら、ちゃんといました。
初めて触る方はここで一回「?」ってなると思うので、先に書いておきますね。
本番：Notionの42件を引っ越しさせてみる
ここからが本題です。実際に使っているNotionのタスクリストを、まるごとLinearに持っていきます。
いきなり壁：ゲストだと接続できない
Notion側もAIとつなごうとしたんですが、認証画面でストップ。
あなたはゲストのため、Notion MCPに接続できません。ワークスペースオーナーにメンバーへのアップグレードを依頼するか、ワークスペースを切り替えてください。
自分は会社のNotionにゲストとして入っています。
Notionって、ゲストは無料だけどメンバーは1人ずつ課金（Plusなら月$10、Businessなら月$20）という仕組みなんですね。なので「ちょっとの間だけメンバーにして」とお願いすると、その分のお金がかかることになります。
……でも、よく考えたらページの中身は普通に見えているわけです。だったら手でエクスポートすればいいだけでした。壁っぽく見えて、実は回り道でなんとかなるやつでした。
CSVで書き出す
Notionのタスクリストを開いて、右上の「•••」→「エクスポート」→形式は「マークダウンとCSV」。
ページの中に埋め込まれたデータベースの場合は、データベースだけを全画面で開いてからエクスポートすると、余計なものが混ざらずスッキリ取り出せます。
出てきたCSVには、概要・ステータス・担当・優先度・期日・親タスクといった列がそのまま入っていました。全部で123件、そのうち未完了が42件です。
公式ルートがないので、AIに投げる
実は、LinearにはNotionからの公式インポート機能がありません。 用意されているのはJira・GitHub Issues・Asana・Shortcut用のインポーターと、あとはCSVをCLIツールで取り込む方法くらい。Notionは入っていないんです。
なので普通なら、CSVの列名をLinearの形式に手で整えることになります。今回はそこをAIに任せました。
結果は42件ぜんぶ移行できました。ステータスの読み替えも、親子関係も、日本語の日付（「2026年2月13日」）の変換も、指示どおりに通っています。
この記事で見てほしいのは移行の成否ではなく、このとき裏で何回APIを呼んでいたかのほうです。
で、Notionだと何回かかるの？
ここまでは「Linearでうまくいった」という話でしかありません。最初の投稿を確かめるには、Notion側の数字がないと比べられませんよね。
そこで、自分の個人Notionに（こっちは自分がオーナーなので普通につながります）同じ作りのデータベースを用意して、まったく同じことをやらせてみました。
比べたのはこの4つです。
一覧を読む
4件まとめて作る
2件のステータスを変える
42件をまとめて移す
ひとつ気をつけたのが、測る前にAIの記憶を一度リセットしたこと。直前に自分でデータベースを作らせていると、構造を覚えたままになってしまいます。それだと「毎回構造を読み解く必要がある」という話を確かめられないので、まっさらな状態から測りました。
測った結果、こうなりました
いちばん大事な数字
42件をまとめて移す操作で、こうなりました。
Linear：45回 / Notion：5回
あれ？…。中身を見たら理由がはっきりします。
Linearは save_issue というのを42回、つまり1件につき1回ずつ呼んでいました。件数が増えれば、その分そのまま増えていく作りです。
対してNotionは、create-pages という命令ひとつで36件をまとめて処理していました。件数が増えても、呼ぶ回数はほとんど変わりません。
投稿にあった「ステータス更新などでAPI呼び出しが増えやすい」という指摘、件数が多い場面ではむしろLinearのほうに当てはまるという結果でした。
トークンのほうはどうか
「AIが毎回構造を読み解く必要がある」というのは、呼び出し回数じゃなくてトークンの量に出るはずです。そこも調べました。
3つの操作を合わせた出力トークンは、Linear 2,740 / Notion 2,862。
ほぼ同じでした。 差は4%くらい。「Notionのほうが重い」とは言えない数字です。
むしろ意外だったのが、一覧を読むときのキャッシュ書き込み量。Linear 42,663 / Notion 10,162 と、Linearのほうが4倍も多かったんです。
これはたぶん、AIに読ませる「説明書」の量の差だと思います。Linear側は55個、Notion側は28個のツールを持っているので。「構造が決まってる」というのは、裏返すと「その構造をAIに教える説明が長い」ということでもあるわけですね。
（※ここは数字からの推測です。他の要因が混じっている可能性もあります）
少ない件数だと？
参考までに、数件レベルの操作も並べておきます。
操作 | Notion | Linear |
|---|---|---|
一覧を読む | 3回 | 2回 |
4件作る | 1回 | 4回 |
2件ステータス変更 | 3回 | 2回 |
読むのと変えるのはLinearが少なくて、作るのはNotionが少ない。数件ならほぼ互角で、差がつくのは件数が増えたときだけ、という感じでした。
まとめて処理して、抜け落ちない？
1件ずつなら失敗に気づけますが、42件を1回で処理すると1件抜けても分かりません。気になったので、元のCSVと移行後を突き合わせました。
食い違いゼロでした。 件数（42/42/42）、取りこぼし、重複、ステータス・優先度・期日、すべて一致。この規模なら心配なさそうです。
ただ、処理直後のAIの報告はこうでした。
既存6件＋今回42件＝48件 未開始 41 / 進行中 3 / pending 6
41 + 3 + 6 は 50 です。データは正しくて、報告の計算だけが間違っていました。
AIの作業より、AIの「できました」のほうが危ない。 最後に数を数えるのは、人間の仕事として残しておいたほうがよさそうです。
（ちなみに元データには同じ名前のタスクが2件ありました。移行されたのは未完了の1件だけで正解でしたが、タイトルだけで照合すると取り違えます）
で、この数字って気にすることなの？
ここまで回数の話をしておいてなんですが、書きながらずっと引っかかっていました。
API呼び出しの回数って、使う側が気にすることなんだろうか。
正直に言うと、今回くらいの規模ならほぼ関係ありません。トークンの量もほぼ同じでしたし、どちらも待たされている感覚はありませんでした。
回数が効いてくるのは、こういう場面くらいです。
数百件・千件をいっぺんに処理して、レート制限に当たるとき
何かに失敗したとき、どこでコケたか切り分けたいとき（1件ずつのほうが分かりやすい）
つまり、元の投稿が「変える理由」に挙げていた指標は、測ったら逆で、しかもそもそもあまり関係なかったということになります。
じゃあ意味のない検証だったかというと、そうでもなくて。測ったからこそ、本当に差が出ていたのは別のところだったと分かりました。次はその話です。
それでもLinearが良かった、2つのこと
数字だけ見ると「じゃあNotionのままでいいじゃん」となりますが、触った感触はまったく逆でした。
1. 想定外の値を、うまく飲み込んでくれる
移すタスクの中に、ステータスが pending のものが6件ありました。これ、Notion側で使っていた独自の呼び方です。
Notionだと：選択肢に pending がなくて、APIに拒否されました。「新しく選択肢を追加しますか？」と聞かれて、データベースの作り自体を変えることに。
Linearだと：「pendingはBacklogに読み替えて」という一言で、そのまま通りました。最初から決まった箱（Backlog / Todo / In Progress / Done / Canceled）があるので、近いところに置けるんですね。
これ、まさに「構造が決まってることの強み」でした。面白いのは、投稿が「Notionの弱点」として挙げていた"自由度の高さ"が、API呼び出し回数じゃなくてこっちに出てきたことです。指摘自体は正しくて、出る場所が違った、という感じでしょうか。
2. キーボードだけで進む
これは触ってみないと分からないところでした。
C… 新規作成がパッと開くCmd + K… コマンドパレット。やりたいことを名前で呼べるI… 担当を自分にするS/P… ステータス / 優先度を変える
しかもコマンドパレットには、それぞれの操作の横にショートカットキーが書いてあるんです。使いながら自然に覚えられるようになっていて、慣れるほど速くなる感じ。よく考えられてるなあと思いました。
複数行を選んでからキーを押せば、まとめて処理もできます。担当者が空っぽだった6件を一気に自分に割り当てるのも、キーひとつでした。
で、結局どっちがいいの？
今回やってみて感じたことをまとめます。
Linearが向いてそうなのは
タスクの形（ステータス・優先度・担当）を決めて回したい
キーボード中心でサクサク進めたい
開発のタスクとして管理したい
Notionのままでよさそうなのは
大量のデータをまとめて処理する場面が多い
タスクと同じ場所に資料や議事録も置いておきたい
今の運用にとくに不満がない
そして現実的には、「タスクはLinear、資料はNotion」の使い分けに落ち着く気がします。競合というより、得意なことが違うツールでした。
「AIとの相性」という言葉が指していたのは、API呼び出しの少なさじゃなかった。 決まった形があるおかげで、AIがふわっとした指示をちゃんとした形にしてくれる——測ってみて分かったのは、そういうことでした。
正直に、この検証の弱いところ
ちゃんと信じてもらえる記事にしたいので、うまく測れていないところも書いておきますね。
どの操作も1回ずつしか測っていません。 何度かやって平均を取ったわけではないので、多少のブレは入っているはずです
Linear側とNotion側で、指示の文言が完全には同じではありません。 Linearで4件作ったときは「担当者を設定して」も入れていましたが、Notion側には入れていません。回数の差にその分が混じっている可能性があります
確かめたのは42件の規模だけです。 数百件になったときに同じ結果になるかは分かりません
この結果は変わりえます。 Linear側がまとめて処理する仕組みを追加すれば、数字はひっくり返ります
参考リンク
AI・システム開発のこと、VISKにご相談ください
「自社の業務にAIを活かせないか」「この作業、自動化できないか」——
そんな漠然とした段階からで大丈夫です。大阪のAI・システム開発会社VISKが、御社の課題に合わせて、企画から開発・検証までサポートします。
