タスク・知識管理OS v15 → 29に至るまでの記録(随時更新)

有限の時間や気力を有意義に使うのは極めて難しい。 また、個人が蓄積した知識を管理するのもかなり難しい。 学部生活が終わりに近づき、院生活が見えてきた頃、タスク・知識管理をするモチベーションには以下のようなものがあった。

  • 鬱を罹患して使える気力が少ないため、気力を有意義に使いたい。
  • 会社に勤めながら研究をすることになるため、どちらにおいても使える時間が少なく、時間を適切に使いたい。
  • 自分の記憶だけで予定管理をするとダブルブッキングが遅延が多発する。
  • 自分の記憶だけで知識を持つようにすると知識の蓄積の効率が悪い。

鬱を罹患していたり、社会人学生をしているのは比較的特殊な事情だが、「やりたいことに対して気力も時間もまるで足りない」という状況はかなり普遍的だと思う。

このブログでは、M1から現在までにかけてどんな「タスク・知識管理OS」を構築したか、どのように段階を踏んでそれを構築したかを記録しておく。(追記:たまに更新している)

特に、「今どうなってるか」だけでなく「ゼロからどのように習慣を構築したか」はあまりネットにない記録だと思う。このやり方は、複雑でコストのかかる習慣を構築したい人のほとんどにとって参考になるだろう。

現在どうしているか?

複数のツールを組み合わせて包括的にタスク・知識管理をしている。

Todoist: 短期タスク管理

直近1,2週間でやるタスクの大部分を入れている。どのくらい大部分かというと、食事とかシャワーを浴びるとか寝るとか以外のほぼ全部である。タスクが消化しきった場合、あとは自由時間になるが、その際もやることを決めたら一瞬だけタスクがキューされる。

基本的に、「取り掛かるときに」完了チェックをつけている。(終わらなかった場合はタスクを入れなおす)自由時間のときもやることを決めたら一瞬だけタスクを入れて完了チェックをつけている。これは、やることを決めて自分にフィードバックしたり、自分自身に「タスク開始の小さな報酬」を与えるためだ。この挙動はGetting Things Doneというテクニックを参考にしている。

タスクは4段階に優先順位をつけており、(気分が乗らないとか物理的に実行不可能なときでなければ)基本的には上から順番に処理をする。ミーティングのようなものは優先度がなくてもどうせやることになるので、優先度は最低にしている。

また、「何をするか」ではなく、「タスクを達成するとどのような状態になるか」をタスク名にすることを心がけている。こうすると、心なしかタスクが分解しやすい。

Toggl Track: 時間記録

何をいつからいつまでやったのかを記録している。Todoistと連携して、タスクを始める時にTodoistの画面から記録を開始したり終了したりすることができる。 睡眠時間も含めて24時間すべて記録に載るようにしているが、後述の学業:労働比率調整に用いる以外は割かし適当に取っている。

Google Spreadsheet: 記録の集約とフィードバック

Toggl Trackで記録された時間をもとにGoogle Spreadsheetで曜日ごとにどのくらい何をすべきかを計算する。(例:火曜日は学究関連でn時間費やすべきである、など)情報の取得や計算はシートで自動的に行われる。

Obsidian: 知識ストレージ + いろいろ

テキストベースの情報はObsidianで管理している。そこそこ軽量でオフラインでも動き、プラグインによる拡張性も高いので便利である。

書くときは制約がなく適当に放り込んでいるが、参照頻度が上がってきたときは構造化されたフォルダに適宜分類する。

このブログ記事もObsidianで書いているし、長期的な計画などもこれで行っている。

Google Keep: 知識キャッシュ + 長期リマインダー

思いついたものをさっと記録したいときに実はObsidianはやや起動が遅く、Google Keepの方が速いのでそっちを使っている。Obsidianへの転記は時間があるときにタスクを積んで行っている。

また、Todoistに全部入れてしまうと煩雑になってしまうような数週間~数年に一度発動すればいいリマインダーなどもGoogle Keepで運用している。

Zotero: PDF管理

言わずと知れた論文管理ソフトだが、PDF管理としても結構使える。デバイス間同期はinfinicloud(webdav)をバックエンドに行っている。

Google Calendar: ブロッキング予定管理

時間が決まっているタイプの予定はgoogleカレンダーにすべて入れている。どの時間がブロックされているかは会社の他の人間から確認できるようにしてある。ここの運用は会社の方針である。

v15v29までの過去の軌跡

段階的にやる

上の習慣は現時点のもので、M1開始直前時点では全く何も使っていなかった。

これを一気に導入するのは難しいと思う。ツールとの相性が人によって違うのもあるが、生活の変化が大きすぎて定着しないだろう。

自分の場合、年単位の時間をかけて何回ものバージョンアップを経て、上の習慣を構築している。

習慣を構築する際に特に気を付けたのは以下のことだ。

  • 習慣化したいものの負荷をとにかく下げ、定着してから難しくしていくこと
    • 他のテクニックはこれに比べればすべて枝葉末節であるといっていい。時間はかかるが焦ってはいけない。
  • スマホとPCの両方で使えるツールにする。
    • 日常的にアクセスできるようにするために必要。
  • 新しいツールに生活を適応させる。
    • 生活を保ったままツールで便利さを上げるのではなく、ツールの良さを最大限引き出せるように自分の生活を改善していくという心構えのことだ。
  • 完璧を目指さない。
    • 完璧にしようと思うとツールに縛られてしまう。生活の改善はしつつ、それは段階的に行い、問題があったら対処するという柔軟な姿勢が必要だと思う。

過去の履歴

ということで過去の履歴を見ていく

v1 ~ v15の詳細

v1 タスク管理

最初にTodoistですべてのタスクを入れることを目標にした。思えばこれが一番構築に時間がかかった習慣な気がする。優先度はまだこの時点では入れていない。

v2 Notion, v3 Paperpile

知識管理を導入した。これにより、ある程度頭を空っぽにしても行動はできるようになった。

v4 時間記録, v5 単純フィードバック

時間を記録し、記録を分類する。複雑な計算をしなくても、学究と労働の時間を1:1に保つのは実はそこまで難しくない。

v6 カレンダー管理

会社の都合でカレンダーの運用体制を整えた。修士課程はここらへんで終わった。

v7 複雑フィードバック, v8 フィードバック半自動化, v16 完全自動化

博士課程になり、学究の割合を増やす必要が出てきたため、1:1でフィードバックするような単純な方法は使えなくなった。また、日によってどのくらい活動すればいいのかの目安がわからず、活動しすぎたり少なすぎたりしたため、フィードバックシートを構築し、時間記録と連結した。

最初は手動で転記や計算を行い、週一回更新していたが、今では自動化され、タスクが終わるごとにリアルタイムに更新されるようになっている。

v9 Obsidian移行, v10 Zotero移行

詳しい理由はここに書いてあるが、利便性の向上のため、Obsidian + Zoteroに移行をした。

neutron63zf.hatenablog.com

v11 部分的ポモドーロ

適宜ポモドーロを回すようにした。まあまとまった時間が取れることは少ないのでたまにではあるが。

v12 タスクオフロード

実はこの時点まではすべてのタスクがTodoistにあったが、タスク数が多すぎてやる気が低下してきたため、直近で必要でないものをObsidianに隔離して必要に応じてタスクを錬成する方向性に切り替えた。

リマインダーについてはGoogle Keepに移動した。 TodoistやGoogle KeepからObsidianにリンクを張ることができるので、実現は難しくなかった。

v13 トリガータスク化, v14 優先度の導入

Todoistの改善。これにより、「今現在の瞬間に気にすべきタスク」の数は1-2個程度まで減少した。「トリガータスク化」とは「タスクやるときの最初の30秒でできることをタスク名にする」ようにしたことだ。小さな変更だが、体感で倍くらいタスクにとりかかりやすくなった。

v15 記録キャッシュ

Obsidianがもっさりしてきたので、とりあえず何か書きたいときはGoogle Keepを優先的に使うようにした。

v16 ~ v24の詳細

v16 タスク管理Obsidian移行, v17 出戻りと連携強化

obsidian tasksにタスク管理を移行したものの、スマホでの動作が重かったため、各アプリでのタスク管理に戻り、代わりに連携を強化して、PCではobsidianで完結、スマホでは各アプリで軽量に操作できる、という風にした。

v18 Obsidianスマホでのリードオンリー化

スマホでの書き込みはスループットが悪いうえに、同期が複雑なので、スマホでのObsidianはリードオンリーにすることにした。

v19 StayFree導入

ShortsやTLを無心で見ている時間があまりにも無駄そうだったので時間制限アプリを入れた。最初は緩い制限だったが、今は時間を決めて、集中したいときにフォーカスしてアプリをブロックするのに使っている。

v20 Audify導入

移動時間を適切なインプットに使うため、新着論文や書きかけの原稿をインプットする手段として読み上げブラウザを導入した。インプットが多くなるとアウトプットしたくなることも増えるので良い。

v21 RooCodeの導入

RooCodeを導入した。これにより、簡単なタスクであればコーディングをある程度自動化できるようになった。まだ部分的なLLMの補助ではあるものの、関連するタスクは大幅に高速になった。

v22 時間記録の粗視化

ObsidianやスマホからToggl Trackを操作する都合上、Todoistとは切り離して、フィードバックに必要な情報だけTogglに入力するようにした。 基本的には学究か労働かを区別できればよく、さらに学究の中でプロジェクトが追跡出来ればよい。

v23 Todoistへのタスク再集約

一見するとv12の逆に見える。Todoistにタスクの詳細をある程度書き込むようにする変更。 Obsidianにすべてがある状況だと、タスクを開始するときのコンテキストを頭に入力するのに時間がかかるため、Obsidianに記録は残しつつ、Todoistだけでタスクは取り掛かれたりタスク分解できるようにする。 v12以前と違うのは、Obsidianのタスク管理のキャッシュとしてTodoistを運用するようになったということだろうか。

v24 睡眠表導入

精神科の担当医と相談して、睡眠記録と気分の記録をつけることにした。服薬の最適化を目指す。

v25 Audify, StayFreeの停止

可処分時間のすべてを能動的なインプットに使うのはメンタルが持たなかったのでやめた。StayFreeについては、主にやる娯楽がyoutubeやPCゲームではなくswitchのゲームになってしまったのでいったん停止している。

v26 タスク特性の分類

頭が空っぽのときや、逆に集中したいときなどでやることを切り替えるため、以下のようにタスクを分類してタグを適宜つけることにした。 - transportive: 入力だけ、出力だけ、もしくは入力を変形して出力するだけ。あまり頭をつかわなくてもいい。 - interactive: 実際に環境と相互作用しながら動的に情報を組み立てる。他のタスクとは同時にできない。 - need-divide: タスクが大きく、何からとりかかればよいかわからないというマーカー。

v27 取り掛かり判断コストの削減

「どのタスクをやるべきか」を考える時間は集約したい、ということで、事前に優先度をつけ、さらに「すぐに見えるタスク」をプロジェクトごとに3つまで制限した。 タスク分解についても集約し、1pomoでできる粒度まで分割するようにした。

v28 短中期スケジュールの接続

todoistのタスクについて、タスク名を「やること」ではなく「目指すべき状態」にしてみる。(やることは説明やコメントに書く)これにより、タスクをすることで何を達成しようとしているかというメタ情報がわかるようになる。
期限を動かす余地のあるタスクではなく、最も優先的に期限を達成したいものを1つ選んでラインを引く。

v29 生活習慣、時間フィードバックの改善

学業:労働時間が比率に到達するために必要な時間をすぐに見れるようにした。(今までは間接的なフィードバックだけを見ていた。) さらに、すべての時間を記録するようにした。 また、今まで起床時間が遅かったのを、朝活(スプラ)をすることで、生活リズムを2.5時間前倒しした。土日どうするか、今まで適当にしていた朝食が課題。

これから

いろいろやってきたが、まだ完全ではない。おそらく向こう何年かは改善が続くのだろう。直近で考えているのは以下のことだ。

LLMの補助を汎用的に使いたい

今までの習慣はリソース管理を最適化しているだけであって、自分の能力が拡張されたわけではない。まあこれでもリソース管理がないころに比べて1.5倍以上の生産性は達成できているが、自分が本当に欲しい水準には達していない。

体力を上げるのもそうだが、LLMなどで重要度の低い知的生産を補助できるようになるといいな~と漠然と思っており、今いろいろ試している。

長期的な計画が苦手なのどうにかしたい

今は基本的に空いた時間にできることを順番に消化しているだけであり、「いつまでにここまで終わらせる」というのは苦手としている。予測も難しい。 実際にやるのはともかく、予測はできるようになりたい。

生活習慣

生活リズムを巻き戻せたが、いろいろ生活習慣には課題がある。どのように体重を減らすかいろいろ試していく。

「なんでも忘却できる力」の祝福と呪縛

こんなツイートが話題になっていた。

https://x.com/mental_ot/status/1828547007117697487

要約すると「嫌なことを忘れるためには、思い出したことを自覚した瞬間に他のことを考えよう」というものだ。

この方法は自分の思考を常に監視する必要があるためかなり大変だが、かなり効果がある。

なぜ言い切れるのかというと、自分はとある経緯(後述)で忘却術を身につけることを余儀なくされ、最初に効果があった(そして一番効果が強い)のがこの方法であることを身をもって経験しているからだ。

しかし、忘却の力は「嫌なことを忘れる」だけからは想像もつかないほど強力であり、危険なものだ。

このブログでは、小学生の頃から15年以上「なんでも忘却できる力」とともに過ごしてきた自分の体験談を交えつつ、その祝福と呪縛について述べるものである。

そして、「本当に死ぬことを考えているが、どんな精神的な犠牲を払っても身体だけは生きたい」人でなければ、このやり方を試すのは推奨できない。そしてその場合でも、まずは精神科医にかかるべきだと自分は考える。

ここに来てはいけない!

なぜ「なんでも忘却できる」のか?

(自分は心理学については何冊か本を読んだ程度の知識しかなく、この節の説明は学術的に検証されていない。あくまでも個人的な体感に対する説明である。)

人が物事を思考するには主に以下の3つのステップが必要であると考えている。 「記銘」「保持」「想起」。 計算機で言うと、それぞれが「書き込み」「維持」「読み出し」にあたる。

重要なのは、「想起」を行うことで記憶を強化できることだ。 よく使う記憶は重要だし、どんどん引き出しやすくなっていく。 そして、「想起」が行われなければ記憶は少しずつ忘却されていく。

では、人が自動的に「想起」している分まで何らかの方法でブロックするとどうなるか? すると、忘却に対してのブレーキが効かなくなるため、他の記憶に比べてすごい速さでその記憶は思い出せなくなっていく。 なので、忘却術と言っているが、その実態はむしろ「自然治癒を邪魔しない」のに近い。

「想起」を行うことができなければ効果は同じため、常に思考を監視する必要も本質的には必須ではなく、慣れたら自己暗示や条件反射をベースにしたものに移行することもできる。これらは思考監視よりも効果が弱いが、即効性があり、手軽に展開できる。

そして、「想起」できる対象にはなんでも指定できる。自分の思考と言語化能力で自分の他の記憶と区別ができる限り「なんでも」だ。

この「なんでも」はきわめて強力な性質だ。次の節ではそれを述べていく。

「なんでも忘却できる」は「覚えたいものだけを選べる」の裏返し

忘却術の運用を始めたのは小4の時だが、高1の半ばごろからこの力には通常の生活で非常に有用な使い方があることがだんだんわかってきた。

「誤答の選択肢」だけ忘れられる。 正解だけを覚えるのよりも、暗記系の学習を今までよりも少しだけ速くできた。

忘却の力は裏を返せば、「覚えたいものだけを選べる力」だった。 そこに気づいてからは応用は速かった。

「具体的な枝葉末節」を忘れて「抽象的な本質」を見極める。 「今考えなくてもいい雑念」を忘れて「今やるべきこと」に集中する。 「心無い言葉の暴力や激情」を忘れて「精神の平穏」を保つ。 「良くない習慣をやりたくなる衝動」を忘れて「日々の生活」を改善する。

東大にこれた要因の1/3くらいはこの応用に由来するだろう。

自分の精神に関して言えばほとんどなんでも選ぶことができる。 root権限のようなものだ。 そして、外部からの精神攻撃に対して、対象を特定できる場合はきわめて強力な防壁として運用することができる。 今や自分はこの力なしでは生きていけないほど適応した。

しかし、よく言われるように、大いなる力には大いなる責任が伴う。 使い方を誤ると、極めて深刻な問題が発生することに、ほどなくして気が付いた。

人をその個人たらしめる記憶の消去

人をその個人たらしめる、というのは、いうなれば「その人が他の人とどのように違うのか」ということだ。人間の場合、それは過去の経験と記憶、そしてその記憶の蓄積からもたらされる自我と人格である。

高2の終わりごろ、比較的つらい体験の記憶(正確にはそれによる感情の記憶)を何日かかけて消していたとき、あることに気づいた。

「昨日の自分の行動にまるで共感ができない」

理解はできるけど共感ができない。消した記憶に紐づく体験が自我の一部からはがれてしまっていた。 このようなことが起こる理由は、忘却するときに「それと強く紐づいている周りの思考パターン」を変形させるからだ。 転校すると通学路が変わるように、忘却をすることは対象の記憶だけでなく、その周囲の記憶にも影響を与える。そして、自分の行動や感情に大きな影響を与える記憶を忘却しようとすると、副作用で価値観が変わり、人格の連続性が途切れてしまう。

忘却の力を乱用すると、自我を分解してしまう危険性がある。

昨日の自分に共感できない症状は1ヵ月ほどつづき、記憶の消去が落ち着くとともに消えた。 しかし、「そのラインより過去の行動」には共感できないままで、結果として過去の自分は他人になってしまった。これは今でもそうだ。 これは成長なのかもしれない。しかし、成長というのは過去の体験を取り込んで変化することで、自分がやったのは腐食した部位を隔離しただけではないだろうか。

しかし、気づいたころには忘却の力はあまりにも日常に必須のものとなっており、結局自分は危険性を抑えながら付き合っていくしかなかった。

思い出せないだけ

自分は心理学に詳しくないが、似たような指摘はいくつか引用で見受けられた。 中でも興味深いと思った指摘がこれだ。

「たとえ思い出せなくなっても、体は覚えている」

忘却の力の実態は上でも述べたように「思い出せなくするだけ」であり、あなたの記憶そのものは風化こそしているものの確実に存在している。想起を抑制する力は有限であり、その壁が突破されると、あなたは再びそれを思い出すことになるだろう。

そして、忘却の効果が及ぶのは「言語化できる範囲」だけだ。 無意識の体のトラウマなどの反応まで抑制するのはきわめて難しい。 過去の出来事は取り消せない。できるのは、目をそらすことだけである。

最後に

小3の頃に受けたいじめの傷は深く、小4になっても思い出して動きが固まってしまうことがあった。しかし、そのままではいけなかった。特異な挙動をする人間はいじめの標的になりやすいと考えていたからだ。1か月間昼夜を問わずに考えたのちにたどり着いたのが忘却の方法であり、15年間以上生きるための武器の一つとなってきた。 おそらく、本当の意味でのギフトと呼んでいいだろう。

しかし、親すらも味方してくれなかったいじめの中で一人だけ寄り添ってくれた同級生がどのような励ましの言葉をくれたのか、今では思い出せない。他のより暗い記憶を封じ込める引き換えに、それらは手の届かないところにある。

忘却の力は強力だが、幸せになることを考えるならば、このような力が必要になる人生を送るべきではないだろう。 自分の精神を削り、自分が自分でなくなっても生き残る方法は推奨できない。 今から身に着けようと思っているほどつらいならば、どうか能動的に幸せになる方に舵を切ってほしい。 既に運用している人は、くれぐれも気を付けることだ。この方法に溺れないように。

この深みに来てはいけない。

テンセント版三体を見終わった(後半ネタバレあり)

注意

この記事は後半に大量のネタバレを含みます。(特に三体II, IIIも部分的に含む)初見で楽しみたい方はなるべくスクロールをしないでください。

感想(なるべくネタバレなし)

原作にきわめて忠実な映像化であり、原作のSFとしての魅力を存分に伝えられていたのではないかと思いました。一方で、映像作品単体としてみるとやや評価をしづらい部分もありました。また、原作に忠実な分、微妙な差異に目がいきやすかったというのもあります。 また、映像としてやや冗長だった部分もあったように思いました。 良くも悪くも「小説版の三体の映像化」としてかなり優れていたのではないでしょうか。

以下それぞれの側面を見ていきます。(なるべくネタバレなしで)

キャスト・演技

かなりイメージ通りのキャストの起用でした。 個人的にはこの要素だけを取ってみても作品を見る価値があるのではないかと思います。 三体の登場人物には個性あふれる様々な人間がいますが、どれも原作を彷彿とさせるものばかりです。ビジュアルからしてかなりイメージ通りだったのもそうですが、口調などもまさに原作そのもののイメージでした。

映像化

三体にはいくつかの見せ場があり、いずれもきわめて印象的なシーンです。 三体のSFとしての魅力の結構な部分、少なくともSFのエンタメとしての部分を支えるこれらのシーンも、映像では完璧に再現されていました。 実際に見てみるとこれらは圧巻というほかなく、原作を読んだ人間からするとかなり感動します。 また、これらの他のシーンでも、細やかな映像化の配慮がいたるところに見られました。原作ではいくつか説明が短い部分についても、映像としてわかりやすく見えている部分があったりします。

原作要素からの改変

台詞などが極めて原作に近い分、原作からの差異に敏感になりやすいなと思いました。特に、原作小説とはやや章の流れが意図的に変えられています。 どちらの構成にもいい点と悪い点があり、一概には言えないと思います。 個人的には、映像の尺の問題なのか構成のわかりやすさのためか、はたまた当局への忖度のためか原作から消されてしまった要素があるのが今回のテンセント版三体での数少ない残念ポイントだと思っています。

以下、ネタバレありで感想を書いていきます。

.

.

.

.

.

.

.

.

.

.

.

.

感想(ネタバレあり)

キャスト・演技

史強の演技よすぎだろ!!!本当にわかっているなあ!! 自分は中国の親類たくさんいるし何年かに一回帰省してたからわかるけど、マジで「そこら辺を歩いている中国人のおっさん」のしゃべりなのよ。良すぎる。知り合いの子供を甘やかすのもマジで親戚のおっさん。

汪淼も汪淼で陰キャインテリ眼鏡感あっていいね。丁儀も。(理論物理学者ってどこの国でもああいうラフな感じなのかね)

葉文潔(現代)も典型的老婦人という感じだった。作品自体の(中国に関する)リアリティーラインは高めなんで、そこを外さないのはめっちゃいい。

一方で子供の演技はなんていうかその......深くは言うまい。

あと女優もかなり良かった。申玉菲の冷徹さや楊冬の透き通る感じもかなり素晴らしいと思う。

欧米人の演技はどうだったのだろう。三体で一番しっかり描写がされているのはエヴァンズだが、幼少期も含めてあまり違和感はなかった。 他の欧米人は全員軍人だったので、多少棒読みでも気にならない。 三体IIでは面壁者たちがガチで名キャラぞろいだし、IIIではトマス・ウェイドとかいう最強人間が出てくるのでシリーズものを作るなら期待したい。 今の中国だと俳優の確保は大変そうだが......

前半部分の汪淼の焦燥と混乱の演技はめちゃくちゃ良かったと思う。三体現代編はここを抜きにしては語れんからね。あとは原作ではほとんど蚊帳の外だった沙瑞山もちゃんと描写されてていい感じ。

映像化

「「「三太陽の日だ―――」」」

100万点だね。エンタメSFとしての三体って結構な割合がVR三体なんですけど、そこの映像化はばっちりでした。 しいて言えば(原作読んでても思ったけど)2006年時点にこんな高度なVRがあってたまるかいというところだが、まあそこは目をつむろう。

文王と三飛星、烈火と墨子(ついでに孔子)、三太陽、人列コンピューター、大断裂。どれもすばらしい出来でした。(コンピューターを知らないフォンノイマン、エアプノイマンは実際に見てみるとかなり突っ込みどころがある)

宇宙の瞬きもめっちゃいい。上位存在を目の当たりにしてSAN値を削られてしまう人間さんからしかとれない栄養がある。

逆に、ちょっと難しいなと思ったのは最後の監視員と三体政府総統の対話部分。あからさまにエイリアンが出てきてしまったのは、まあ原作では可能な限り言及が避けられていたのであれだが......難しいと思う。VR三体なので、今までと同じ人間でもよかったのではないか。

原作からの改変

文革を削ってしまったのだけは本当に残念。ここだけでも1話割いて追加してほしいくらいには残念に思っている。 葉文潔の絶望は原作では4段階くらいに分かれて描写されていて、以下のようになっている。 文革の暴徒による父親の殴殺と母親の離反、沈黙の春と白淋霖による裏切り、母親による口封じ、そして紅衛兵との対面の4つだ。 文革の描写が映像からはごっそり削られており、BGMになってしまったので、人類への憎悪要素は半分くらいになってしまっている。これだと葉文潔はただの生まれついてのマッドサイエンティスト(否定しきれないのだが)になってしまい、リアリティに欠けるのではないか。

アンチ人類としては、人類への憎悪というのは「きわめて個人的な悲劇の体験」をし、「悲劇が人間性の根源によるものだと認知」し、「悲劇は不可避だと理解したので人類を滅ぼすという決意を抱く」の3要素が必要であり、文革がなくなってしまうと1つ目と3つ目が大幅に薄れてしまう。ここは本当にいただけない。(テンセント版三体だとエヴァンズや途中で出てきた紛争地帯の人の方がよほど反人類になる説得力がある)

逆に言うとそれ以外は結構映像化としてわかりやすさのために受け入れられる範囲だったと認識している。たとえば、三体原作は過去編、VR三体(三体世界)編、現代編の3つが複雑にいりまじる構造で、たぶんそこそこ認知負荷が高いのが、テンセント版三体結構ストレートなストーリーになっている。慕星についても、降臨派の暗躍を描写するという点では悪くない改変だったのではなかろうか。

また、原作では説明が不十分だった箇所(たとえば実験物理で結果が食い違うなんてよくあることだけど、なんで絶望して死んじゃったのさ)についてもきわめて明瞭に説明が与えられている。ここは原作よりも優れているかも。作者に取材とかしたんだろうか。

ただ、ストーリーをわかりやすくするという点なら、もう少しいろいろ削っても逆に良かったのではないかと思っている部分もある。特にVR三体が一通り済んでから物語の進行が遅くなってしまった感を抱いた。いやでも難しいな~。回想も回想で大事だからな~。

小ネタ

ちょくちょく三体IIやIIIが匂わせられている。例えば葉文潔の墓参りや最後のシーンでは羅輯と思われる人物がシルエットだけ出ているし、OPの歌詞では「世界をどうか壊さないで」「地球はもう回らない」「あなたが贈ってくれた小宇宙」みたいなIIIの要素がちりばめられている。 匂わせにしては直接的すぎる気もするが......

あと、葉文潔の回想で「石油にまみれて泣いている少年」はエヴァンズだったりする。(これはわかりやすいかも)

申玉菲の名刺に「しん・ぎょくひ」と日本語で名前が書かれてるのも理解度が高い。(原作でも申玉菲は日本籍に帰化した中国人ということになっている)

三体II, IIIの映像化への期待

三体の三部作ってこれが一番「SF要素が弱い」んですよ!!信じられなくないですか!!!!

この映像クオリティで水滴とか双対箔とか出された日にはマジで感激で昇天してしまうかもしれん。インターステラーブラックホール描写並みにepoch makingなSF映像になるのではないか。

一方で三部作で一番短いこれでも20時間あったので2部や3部がこの調子で映像化されたらまず間違いなく通して見れる人間は少ない。適度な取捨選択を頑張ってほしいところだ。 気になる人間は今すぐ買って読んだほうがいい。II, IIIってIを超える名作ですよ。ちょっと高いけど。

最後に

ところで最近はVRChatというゲームが話題ですね。VR三体のワールドは今のところ存在してないみたいだが、もしかしたらそのうちできるかもしれないし、なんなら作れるなら作りたいかもしれない。 ではまた。

NextDNSでブロック不可能なtwitter広告を消す

要約

DNSをカスタマイズするとブロック不可能なtwitter広告を消せる

背景

ブロック不可能なtwitter広告が増えてきた。増えるだけなら良いのだが、これらの広告は以下の点でやっかいだ。

  • 「興味がない」を押しても何度も表示される
  • たまに血とか不快な音とかそういう表現を伴う

特に後者がとても嫌だ。平穏なtwitterライフを送るにはとても邪魔で、しかもブロックができず、「興味がない」も効果がない。

いよいよ引っ越しか......と考えていたころに、以下のツイートが流れてきた。

なるほど。しかし、FilterProxyはかなり古いAndroidでしか動かない。もっと最新の機種でもいける方法が欲しい。

そこで思い出したのがこれだ。

これを利用すれば、粒度はやや粗くなるが、ドメインごと広告をブロックできるに違いない。ということで試してみたところ、見事広告が一つもでてこなくなったので記事を書くことにした。

やり方

https://nextdns.io/ に登録し、拒否リストに「.doubleclick.net」を加える。 そして、広告が表示されてる端末を用意して、NextDNSが表示している「セットアップガイド」に従ってDNSを設定すればよい。

しばらくすると、ブロック不可の広告は見えなくなった。

DNSをカスタマイズすることが本質なので、実現できれば他のサービスでもいいと思う。

注意

NextDNSには月30万クエリ分の無料枠があり、それを超えるとフィルタリングは機能しなくなるため、無料で済ませるならなるべく設定する端末は減らすのが良い。 自分の場合、PCでは広告ブロックが別の手段で提供されているため、スマホでしか有効化していない。

究極の物理系であり、究極のソフトウェアであるものへの情熱

プログラミング言語では物理工学の博士号は取れないだろう。しかし、それでも自分は量子プログラミング言語が好きだ。(まあ情報理工の院試の問題を見てチキったのが一番悪いんだけど)

だからこれは供養になるかもしれない。もしくは「本当に忘れたくないもの」だ。

本当に気持ちだけで書いたから、論理展開にはかなり飛躍があるが、若さとか情熱というのはそういうものだと思ってほしい。このために大学院に入ったのだ。

究極の物理系としての量子プログラミング言語

物理学は基本的には、現実世界のことを客体として測定し、機序と力学を解き明かす営みだと理解している。

その中でも、プログラミング言語は究極の物理系だと思う。

任意の物理系は何かしらの計算にマッピングできることは有名だが、ある程度強力なプログラミング言語はその計算や物理系すべてを表現できる。とても普遍的だ!

逆に、プログラミング言語はあらゆる物理系をモデル化するだけの力を持たなければいけないだろう。

しかも、物理学は人間による人間のための学問だから、そのモデルは人間が扱いやすいものである必要がある。

あらゆる物理系を、扱いやすくモデル化する力を持つ。もちろんそれ自体は一般的すぎて何もできないが、適切に制約と整合性を加えて特定の系について論じることができる。これは物理学に他ならない。

現代のプログラミング言語は普遍的な物理的モデルとしての能力を持つべきだ。

現代の物理学において、量子情報理論はかなり根源的な理論とみなされているから、理想的なプログラミング言語はその理論構造を反映したものになるであろう。

コンピューター内であらゆる実験を原理的には行えるように、量子プログラミング言語はあらゆる物理現象をサブモデルとしてモデル化できる必要があり、「扱いに習熟することで量子力学を自然と理解できる」ものになるだろう。 そして、逆に、あらゆる物理現象や推論を計算とみなして抽象化することで、理想的な量子プログラミング言語に到達できると考えている。

理想的な量子プログラミング言語は、強力で扱いやすい量子情報理論の構造をバックボーンに持っているはずであり、そのために理論の理解が進むことが必要である。

究極のソフトウェアとしての量子プログラミング言語

全てのソフトウェアは理念的にはプログラミング言語によって書かれるはずだ。(過激派)

だから、理想的なプログラミング言語はすべてのソフトウェアを書けるだけの表現力が必要になる。

プログラミング言語もソフトウェアだから、プログラミング言語はすべてのソフトウェアを生成できる存在、究極のソフトウェアと言えるだろう。

プログラミング言語はソフトウェアを書く人に使われるものなので、どのようなソフトウェアを人々が書いているかに大きな影響を受ける。

なので、量子計算機を用いたソフトウェア、量子ソフトウェアだったり、量子アルゴリズムをすべて表現できるプログラミング言語である量子プログラミング言語があるのが適切だろう。

古典計算機でメモリの破壊を実行前に推論できたりするように、量子プログラミング言語は量子ソフトウェアを書く上で便利な機能、たとえば量子ビットの複製の禁止などを保証できるようにするべきだろう。

そして、そもそも量子ビットではない物理系に対処する必要もある。私が知る限り、ボソン系とフェルミオン系による量子計算の両方をいい感じに表現できる言語はまだない。

量子プログラミング言語との触れ合いとこれから

B2だかB3だったかではじめて量子回路を組んだ時は本当に驚いたものだ。

古典計算機におけるアセンブリ言語にも満たないような抽象度、ビット演算レベルの処理を並べて計算を記述している。

そして、量子力学を知っていないと何をやっているかほとんど何も理解できないのにも驚いた。

中学生の、古典力学も計算機科学も、つい最近まで右クリックも知らなかった人間が「Hello world」できるのとは対照的だ。

とても使いにくいというのが最初の感想だった。これでは将来量子計算機ができても、使う人はほとんど増えないだろう。

しかし、大学院に入り、量子情報の教育を受ける傍らで折に触れて再考するとかなり違う景色が見えてくる。

まず一番重要なのは量子情報は量子計算よりもはるかに多様で広い分野であることだ。量子計算の実現に限った話でも「回路をゲートからアセンブリする」よりは非常に広い話題に触れる必要がある。

そして、ビット演算レベルのきわめて低レイヤーと思えた量子ゲート演算も、物理系の立場からすればきわめて高レイヤーであり、抽象的な存在だ。今よく使われている量子ゲート演算セットは「組み合わせれば一応なんでも表現できる」だけの存在であり、それ以上でもそれ以下でもないことが分かってきた。

量子計算も、どちらかというと必要なのは量子力学というよりかは線形代数(+α)である。

そして量子ソフトウェアは物理学ではないという見方が圧倒的だった。(まあ自分でもかなりこれは思うので妥当なんだけど)一応断っておくと、弊研究室は極めて理解がある方だ。特に、指導教員には修論で「物理と言えそうな貢献」を相談する上でかなり苦労をかけたと思う。何より、そういう方向性に興味を持ってくれる知り合いや若手研究者、ITエンジニアに自分は恵まれていた。かなり恵まれている。しかし、色々模索したが博士号は多分これでは取れないだろう。これは物理工学科に来た自分が全面的に悪い。

上で書いた理想の言語の要求は極めて高い。人生をかけてもたどり着くかは怪しいだろうし、博士課程ではなおさら難しい。そして博士論文にはならない。だからしばらく忘れることにしよう。

だから、これのために量子情報を志したという気持ちだけは残すことにした。未来の自分が、これを見て少しでも量子プログラミング言語のやる気を取り戻すことを祈る。それではまた。

量子コンピューターに必要なソフトウェアを概観してみる

これは、情報科学若手の会 56thで発表した内容(非公開)を修正してテキストベースで公開したものです。 そして、量子コンピューター Advent Calendar 2023の14日目でもあります。(遅刻してすみません。完全に忘却していました......)

量子コンピューターのどこがすごいのか

量子コンピューター、なにやらすごそうなイメージがありますよね。ニュースとかで調べると、「次世代の計算機!」「スーパーコンピューターでも解けない問題を短時間で解いた!」というキャッチーな解説が踊っています。

実際、量子コンピューターは特定の問題、たとえば素因数分解*1や「問題の構造に依存しない全探索」*2を通常のコンピューター(この記事では以降「古典コンピューター」と呼ぶことにします)よりも少ない計算量で解けることが知られています。*3

特に、これらの問題を高速に解くことによって、量子コンピューターはRSA暗号や対象鍵暗号の解読を今までよりも効率的に(特に、RSA暗号に関しては現実的な時間で)解読ができるようになると考えられています。

また、量子コンピューターが提案されたそもそもの経緯の一つ*4である、「複雑な量子物理的な現象の効率的なシミュレーション」なども期待されており、これらによって新しい材料や薬などの開発が加速することが期待されています。

未来は明るいですね!!!

「すごい」量子コンピューターのためには何が必要なのか

......もちろんそんなうまい話はなく、現実には非常に大きな障害が複数存在しており、先ほど述べたような「すごい量子コンピューター」はまだ実現していません。

その中でも一番大きな障害の一つが「ノイズ」です。 量子コンピューターは量子ビットを用いて計算をしていくのですが、1ステップ計算を進めるごとに量子ビットにノイズが乗っていきます。このノイズのため、先ほど述べたような「大規模な」計算をしようとすると求めたい答えがノイズの中に埋もれて取り出せなくなってしまうのです。

IBMが公開している量子コンピューターの情報。(ibm_brisbane, 23年12月17日00:10時点)大体の量子ビットに1%程度の誤差がある。

これに対するアプローチはいくつか存在しますが、その中でもある程度根本的に問題に対処するために必要なのが「量子誤り訂正」です。量子誤り訂正の基本的なアプローチは、複数の量子ビットが分散して一つの量子ビットの情報を持つことで、ノイズで少し情報が破損しても残りから情報を復元できるようにする、というものです。

表面符号*5による量子誤り訂正符号。黒丸と白丸がそれぞれ量子ビットであり、全体で1量子ビット分の情報を保持する。

ではこれで問題がすべて解決するかというと、そんなことはありません。 一つの量子ビットを表現するために多数の量子ビットが必要になる上に、「情報を分散したまま」「ノイズを訂正しながら計算する」必要がある*6ため、量子計算の手続きがかなり複雑かつ長大になります。

例えば、先ほどの図の表面符号を用いたRSA暗号の解読では、素因数分解のためになんと「2000万量子ビットで8時間」のコストが必要である*7と試算されています。 *8

量子コンピューターは制御する古典コンピューターがいないとまともに扱える代物ではありません。 しかし、ここまで複雑になってくると、古典コンピューター側の制御プログラムも非常に複雑になってくることが予想されます。困りました。

量子コンピューターの実現に必要なソフトウェア

実用的な量子コンピューターを実現するには、超多数の量子ビットを適切に制御し、抽象的なタスクを実現しなければいけません。 そのため、通信プロトコルのように複数の階層からなるソフトウェアスタックが必要になります。 以下の項目に分けて紹介していきます。

物理制御組み込みソフトウェア

量子ビットは方式にもよりますが、近代まで発見されなかっただけあって、極めてデリケートであることが多いです。 そのため、量子計算を実現する一番オーソドックスな手段は、「古典コンピューターにあらかじめ実行したい計算を格納しておき、ほぼ自動的*9に物理制御をする」というものになります。

超伝導量子ビットの場合、適切な波形のマイクロ波量子ビットに対して適切なタイミングで照射することで制御をするわけですが、これを「数万量子ビットレベル」までスケールするような装置があることが望ましいです。 みなさんはパソコンに「数万個レベル」の外部機器を接続できますか?ちょっと考えただけでも気が遠くなりそうですね。

理研のプレスリリースより引用。
冷凍機(中心白)から青い配線が伸びている左右の筐体が制御部と思われる。

量子回路シミュレーター

直接量子コンピューターの実現には寄与しないものの、古典コンピューター上で動く量子回路シミュレーターは研究にとって非常に重要です。 量子コンピューター(実機)は数がまだ限られていますが、古典コンピューターは世界中に文字通り遍在していますし、研究者もユーザーも圧倒的に多いです。 そもそも、今の量子回路シミュレーターは大体の量子コンピューターよりも精度が良く、現在も進歩を続けています。 そのため、「このアルゴリズムを実際に動かしてデバッグしたい!」となったとき、実機で動かす前にまずはシミュレーターで試すというのがよくあります。

2023年末現在、量子コンピューターの実機とシミュレーターの精度はかなり拮抗しており、何かしらの技術的ブレイクスルーで量子ビット数はそのまま精度が数桁向上するか、同じ精度のまま腕力で多数量子ビット(少なくとも万レベル)を制御するまではこの状況は変わらないと私は考えています。

IBMが今年7月にnatureに発表した「量子コンピューターの有用性」を示す論文*10に対する反論の一つ*11から引用。実機(青丸)の結果をシミュレーション結果(水色線)がきれいに再現している。この分野の人間にとってはもはやおなじみの光景。

誤り訂正・デコーダ

ニューラルネットワークで表面符号の誤り訂正を計算する手法の論文。*12左の列から、アルゴリズム閾値*13、精度pに対応する計算時間(ms)

量子誤り訂正をソフトウェアの観点で見た場合、かなり要求はハードです。 量子状態がデコヒーレンスによりノイズに埋もれるマイクロ秒~ミリ秒単位の時間で100から1000個のオーダーの入力をもとにエラーを推定してリカバリーまでしないといけません。 計算量を減らしつつ、誤り訂正の精度を損なわない誤り訂正アルゴリズムの研究や、「そもそも少ない計算量で誤り訂正ができる符号」*14の研究開発などが重要です。

量子回路オプティマイザ・コンパイラ

量子コンピューターには相対的に得意な(=精度よく高速にできる)操作と、苦手な操作があります。 例えば、1量子ビットだけを操作するのが2量子ビットをもつれさせる操作よりも得意だったりすることが多いです。 また、同じ2量子ビットをもつれさせる操作でも、近くにあるもの同士でやる方が遠くにあるもの同士でやる方よりも得意だったりします。 そうすると、同じ計算を実現する量子回路でも、「苦手な操作を減らした表現」の方が精度が上がったりします。

また、少し方向性は変わりますが、「ある量子ビットが操作されている間になるべく同時に他の量子ビットを操作して計算時間を圧縮する」なんて方向性もあります。

素因数分解を従来より高速化したと主張する論文*15より引用、抜粋。こういう「量子ビットが遊んでいる時間」は減らしていきたいときもある。

利便性を上げるために必要なソフトウェア

古典コンピューターでWebアプリケーションを作りたいときに毎回TCPスタックから自作しなければいけないとしたらとても大変ですね。 せっかく量子コンピューターができても、抽象化が足りていないと使いづらくて悲しいです。 ということで、ここでは計算機を抽象化して使いやすくするソフトウェアについて以下のものを紹介していきます。

量子ライブラリ・ソフトウェア

複雑性を隠蔽する一番オーソドックスな手段です。 例えばQiskitでは量子アプリケーション モジュールとして化学、金融、機械学習、最適化の4分野について、「簡単に量子計算ができる」ライブラリを提供しています。

他に有名なライブラリだとCirqPennylaneなどがあります。

量子プログラミング言語

先ほどのアプローチでは問題の数だけライブラリが必要になってしまいます。 より細やかな制御がしたいときはそれでは足りないので、量子コンピュータの挙動をもっとプリミティブに記述できるようなプログラミング言語を作ると便利です。 また、古典コンピューターについて手続き型パラダイムよりもスケール手段として関数型パラダイムが注目されているように、量子コンピューターについてもよりスケールする手法が提案されるかもしれません。

量子プログラミング言語だと代表的なものとして QuipperSilqが知られています。

量子クラウド・サービス

一般の家庭で量子計算機保有することはまだ難しいです。*16なので大部分の人はどこかの量子計算機を間借りすることになると思います。 これは現在のクラウドとほぼ同じものであるため、量子クラウドと呼ばれています。 IBM Quantumなどが有名ですね。 また、実機だけでなく、オンラインで量子コンピューターの学習ができるサービスも重要です。未踏での取り組み*17もあり、こういった取り組みでそもそも「量子コンピューターに関わる人口を増やす」というのも重要になっていくでしょう。

個人的雑感

量子コンピューターの実現はまだまだ遠いので課題が山積みです。 情報科学が80年近くかけて蓄積してきた試行錯誤の結果のいいとこどりをしてスムーズに実現を目指せるというのが理想ですが、今の状況では物理学系の人が多く、思ったより知見を導入できていないのではないかと感じることが多いです。 量子ソフトウェアはこれからますます重要性を増していくと思うので、よければぜひ大学の量子コンピューターの研究室の見学や、OSS活動などをしてみてください。

*1:Shor, P. W. (1994, November). Algorithms for quantum computation: discrete logarithms and factoring. In Proceedings 35th annual symposium on foundations of computer science (pp. 124-134). Ieee.

*2:Grover, L. K. (1996, July). A fast quantum mechanical algorithm for database search. In Proceedings of the twenty-eighth annual ACM symposium on Theory of computing (pp. 212-219).

*3:よくある誤解として「なんでも速くなる」というのがありますが、量子コンピューターの方が速く解けることが理論的にわかっている問題はかなり限られているのが現状です。

*4:Feynman, R. P. (2018). Simulating physics with computers. Int. j. Theor. phys, 21(6/7).

*5:Fowler, A. G., Mariantoni, M., Martinis, J. M., & Cleland, A. N. (2012). Surface codes: Towards practical large-scale quantum computation. Physical Review A, 86(3), 032324.

*6:古典コンピューターの通信のように、いったん一つの量子ビットに情報を復号してしまうと、そこにノイズが乗って情報が破壊されてしまうためです

*7:Gidney, C., & Ekerå, M. (2021). How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits. Quantum, 5, 433.

*8:ちなみにコストがあまりにもでかいので、もっといいやり方あるんじゃね?という研究も多く存在しています。

*9:量子ビットの測定結果に応じて計算を変えることもありますが、そのプログラムごと送り込むと考えることが普通です

*10:Kim, Y., Eddins, A., Anand, S., Wei, K. X., Van Den Berg, E., Rosenblatt, S., ... & Kandala, A. (2023). Evidence for the utility of quantum computing before fault tolerance. Nature, 618(7965), 500-505.

*11:Begušić, T., & Chan, G. K. (2023). Fast classical simulation of evidence for the utility of quantum computing before fault tolerance. arXiv preprint arXiv:2306.16372.

*12:Meinerz, K., Park, C. Y., & Trebst, S. (2022). Scalable neural decoder for topological surface codes. Physical Review Letters, 128(8), 080505.

*13:詳しく説明すると長くなるので割愛するが、誤り訂正の精度だと思うとよい。数値が高いほど良い。

*14:有名なものだと Dinur, I., Hsieh, M. H., Lin, T. C., & Vidick, T. (2023, June). Good quantum LDPC codes with linear time decoders. In Proceedings of the 55th Annual ACM Symposium on Theory of Computing (pp. 905-918). など

*15:Litinski, D., & Nickerson, N. (2022). Active volume: An architecture for efficient fault-tolerant quantum computers with limited non-local connections. arXiv preprint arXiv:2211.15465.

*16:情報科学若手の会ではこの部分に質問があって、量子コンピューターを自作する方法を紹介しましたが、それが一番ウケが良かったです。

*17:https://x.com/small_onions/status/1734531013131588088?s=20

notion + paperpileからobsidian + zoteroに移行したい

修士の間ずっと慣れ親しんできたnotion + paperpileによる情報管理をobsidian + zoteroに移行することにした。4月から博士課程だったのでちょうどよいだろう。 obsidianへの移行はほぼ完了しており、zoteroはこれからだ。 ここではかつてnotion + paperpileを選んだ理由と移行の理由について備忘録的に書いていく。

かつてnotion + paperpileを選んだ理由

修士以前、自分はメモを蓄積する体系的な方法を持たなかった。 しかし、大学院と会社員生活を並行に進めるにあたって、頭の中だけのメモ+αでは立ち行かなくなっていき、notionを選択することにした。 当時obsidianにしなかったのは単純にobsidianを知らなかったからなのだが、当時の比較対象への評価は以下の状況だったと記憶している。

つまり、重要視していたのは以下の3つだった。

重すぎない

evernoteはB2の時期に一瞬使っていたが、スマホでの動作がもっさりしすぎという印象だった。 具体的に言うと、アプリをタップで立ち上げてから書けるようになるまでの時間が長い。

スマホでの読み書きが必須

当時、スマホで記事を読んで保存するという行為を頻繁にしていたため、スマホから書き込みができることは重要だった。特に、ウェブページを簡単に取り込めることは重要だった。これはvscodemarkdownを書くだけでは達成が非常に難しい。

スケールする

複雑なメモを大量にストックし、整理する能力である。 google keepはその点で対象外だった。なぜならフォルダのような階層構造を形成できなかったためである。

paperpileを選んだのも似た理由であるが、追加で2つ理由がある。

手軽である

公式アプリがiPad, android, chrome拡張の形式で提供されており、google drive経由の同期が自動でセットアップされて使いやすい。 文献管理初心者としてセットアップの手間がかからないのは楽である。

モバイルアプリがある

東大はmendeleyが無料で使えるのだが、iPadで書き込みできない、スマホから取り込めないというのは痛いと考えた。paperpileはiPadで直接書き込みができるのと、スマホから簡単に文献を取り込めるのが良い。

notion管理の問題とobsidianへの移行

notion管理はM2の夏くらいまではうまく行っていたが、秋くらいから以下の問題が出てくるようになった。

気軽に書き込めない

思いついたときにぱっと書き込む、という使い方をしづらくなってきた。これは、notion管理が成熟してどこに何を書くかが決まってきたからである。notionのスマホアプリは最後に書き込んだページではなくワークスペースのホームページが立ち上げ時に出るため、書き込む先まで移動しないといけず、書き込みコストが上がってしまった。

拡張しづらい

notionを長く使っているとプログラマーとしては拡張したいケースが出てくる。例えばカスタムコマンドを追加するなどだ。しかし、notionでそれを行うにはwebで開いた上でchrome拡張になってしまう。これは正直微妙だ。

というわけで、色々調べた結果、obsidianに移ることにした。 obsidianは、上の2つの問題を以下のように解決できる。

  • 気軽に書き込めない > デイリーノートが自動で立ち上がるようにすることで、アプリを開くとすぐに書き込める。
  • 拡張しづらい > プラグイン機構がある。コミュニティープラグインだけでなく、自分で作ることもできる。

逆に、obsidianで面倒だったこととして、同期のセットアップがある。多分プログラマーじゃないとめんどくさいだろうが、自分はプログラマーだったのでそんなに問題ではなかった。ここは結構人を選ぶポイントだと思う。あと、共同作業はほぼ不可能な気がするのでそこも諦めポイントだ。

paperpileからzoteroへ行きたい

obsidianへの移行をしてしばらく経ち、論文をobsidianで書いていると、当たり前だが文献管理ツールとつなげたくなってくる。 しかし、そうなるとpaperpileはつらい。なぜならプログラマティカルに外部から操作する手段がほぼないためである。その点でいうとzoteroは既にobsidian用のプラグインもあり、apiもあるので問題ないように見える。 paperpileのエクスポート機構はよくできているようなので、多分そこまで移行は困らないだろう。

最後に

zoteroへの移行はまだやってないので最終的に上手くいくかは不明である。うまく行ったとしてD3で嫌になって出戻りする可能性もある。だがしばらくはこれで行きたい。