そろそろ育休が明けます。復帰が近づくにつれ、限られた時間でどう動くかを考える日々です。
Table of Contents
- はじめに
- ツェッテルカステンに挫折した話
- Obsidianのマルチデバイス同期地獄
- Slackをメモの始まりにする
- 情報収集のフロー
- 積読ならぬ積リンク問題
- 大統領デイリーブリーフィングに学ぶ情報との向き合い方
- Claude Codeで自分用ブリーフィングを作る
- 1日のワークフロー
- 最後に
はじめに
そろそろ育休が明けます。仕事復帰が差し迫ってきて、短時間で効率よく仕事や家事をこなす方法を日々研究しています。最近は食洗機を買いました。めっちゃいいですよ食洗機。
技術のキャッチアップも効率化したい分野の1つです。育休中も Obsidian を使ってやっていましたが、育休前のようなまとまった時間は取れません。以前は仕事が終わってから1〜2時間くらい、自分の書斎にこもってXや Zenn を巡回し、気になった記事をじっくり読み込み、メモを取り、という流れが普通にできていました。今はそうもいきません。
取れる時間は細切れです。飼い犬のむぎの散歩中に公園のベンチで5分、リビングでちょっと手が空いたときに10分、寝る前にベッドで15分…。どれも短く、いつ中断されるかわからない時間です。
私のような平凡エンジニアでは、速読もできないですし、知識の蓄えも少ないのでこのキャッチアップ時間ではまともに情報が自分の中に落とし込めません。
以前のようにPCの前に座って腰を据えてキャッチアップするというやり方は通用しない中、スマートフォンでさっと情報を拾い、隙間時間で学びを残し、あとで振り返れる仕組みが必要です。
この記事では、Obsidianと Slack、そして Claude Code を組み合わせて、平凡なエンジニアが忙しい中でも技術キャッチアップを続けるワークフローを構築した話を紹介します。
ツェッテルカステンに挫折した話
Obsidianで知識管理をしようとすると、必ず出てくるのがツェッテルカステン(Zettelkasten)という方式です。
ツェッテルカステンはドイツ語でメモ箱を意味する知識管理手法で、ドイツの社会学者 ニクラス・ルーマン が体系化しました。ルーマンはこの手法を使って、生涯で70冊以上の著書と400本以上の論文を書いたとされています。約40年間で9万枚以上のインデックスカードを蓄積し、このシステムを対話相手と呼んでいたそうです。なんかすごい。
ツェッテルカステンの基本は、いくつかの種類のノートを作ることです。まず思いついたことをさっとメモするフリーティングノート、本や記事から学んだことを自分の言葉でまとめるリテラチャーノート、そしてそれらを清書して1つの概念に絞り込んだパーマネントノートがあります。
最終的にパーマネントノートを相互にリンクさせることで、知識のネットワークを構築していくというものです(ズンク・アーレンス『TAKE NOTES! メモで、あなただけのアウトプットが自然にできるようになる』に詳しい解説があります)。
Obsidianの [[リンク]] によるノート間の双方向リンクやグラフビューは、まさにこのツェッテルカステンの思想と相性が良いと言われています。Obsidianをインストールしたら一度はツェッテルカステンを調べてみる人も多いんじゃないでしょうか。
で、実際に試してみたんですよ…。数日間、真面目に取り組みました…。
結果、フリーティングノートは書けるのですが、清書が続かない。なので、グラフビューはバラバラのまま。

スマートフォンでリンクを貼ったり、ちょっとしたメモを残すことはできますが、それをパーマネントノートに昇華させるには、腰を据えて考える時間が必要です。
フリーティングノートは1〜2日以内に見返してパーマネントノートに昇格させるか破棄するのがルールですが、そんな余裕がない…。
結局、メモだけが溜まっていき清書のプロセスが回らなくなっていきます。そして数日で、今の自分の生活リズムには合わないと判断しました。困りましたね。
ツェッテルカステン自体は良い方法だと思っています。ただ、清書のために別途まとまった時間を確保するという前提が、細切れ時間しか取れない今の自分には厳しかったです。
この清書のハードルをどう下げるかが、後述する仕組みづくりのポイントになっていきます。
Obsidianのマルチデバイス同期地獄
ツェッテルカステンとは別に、もう1つ頭を悩ませていた問題があります。マルチデバイス同期です。
私のデバイス構成がちょっと特殊で、仕事用のMac、個人のAndroidスマートフォン、個人(仕事用)のiPhone、そして個人のiPadと、合計4台のデバイスを使い分けています。デバイスが分散しすぎですね、すみません。
ObsidianとiPhoneを組み合わせる方法としては、iCloudを使う方法がデファクトスタンダードです。しかし、AndroidとiPhoneとMacを横断して同期するとなると、iCloudだけでは対応できません。そこでよく使われるのが、GitHub リポジトリを介してGitで同期する方法です。
私は Obsidian Git プラグインを使って自動同期を設定していました。定期的にfetchしてpullしてくれるので、理論上はシームレスにノートを同期できるはずです。
はずだったんですが、ほぼ毎日コンフリクトします!!!
何が起きるかというと、Android側でメモを書いている最中に、Mac側の変更がpushされていて、Androidがfetchする前の古い状態でメモを書いてしまう。で、commitしようとしたタイミングでコンフリクト。大したコンフリクトじゃないんですよ。テキストの数行がぶつかっているだけです。
でも、それを Termux を開いてgitコマンドで直さなきゃいけない。メモを取りたいだけなのに、コンフリクト解決という余計な作業が挟まる。めんどくさい。だんだんメモを取ること自体が億劫になってきました。
メモを取るのにコンフリクトを直す作業が必要って、めちゃくちゃ非効率でおかしいですよね。
Slackをメモの始まりにする
コンフリクト問題を解決する方法を探していたところ、ObsidianとLINEを連携する LINE Notes Sync というツールの存在を知りました。3000人以上が利用しているツールで、LINEで送ったメッセージがObsidianに同期される仕組みです。
めちゃくちゃ便利そうですし、End to Endな暗号化もしていてとても素敵な仕組みだと思いました。が、私は結果的に使わずでした。
まず、私はあんまりLINEを使わないです(友達が少ないとか言わないで)。
連絡手段としてはほぼSlack一択で、家族との連絡もSlackでやっているくらいです。さらに、仕事用のMacやiPhoneにはそもそもLINEを入れていないという事情もあります。技術メモを取りたいのは仕事端末を触っているタイミングが多いので、そこにLINEがないとなると使い勝手が悪いです。
Slackなら仕事でも家でも毎日使っているし、全デバイスにインストール済み。ならば、SlackからObsidianに同期する仕組みを作ってしまおう。ということで obsidian-slack-sync というObsidianプラグインを開発しました。
obsidian-slack-syncの仕組み
このプラグインは、SlackチャンネルのメッセージをObsidian VaultにMarkdownノートとして一方向同期するものです。中継サーバーは不要で、Slack Web API にBot Tokenを使って直接通信します。LINE Notes Syncにインスパイアされて作りました。
仕組みはシンプルで、スマートフォンからSlackの専用チャンネルにメモを投稿すると、プラグインがSlack APIを通じてそのメッセージを取得し、Obsidian VaultにMarkdownノートとして保存します。同期の方向が Slack → Obsidian の一方向なのがポイントです。Obsidian側からSlackに書き戻すことはないので、Gitで起きていたようなコンフリクトは原理的に発生しません。
セットアップ
セットアップの手順を簡単に紹介します。
まず Slack API のサイトでBotアプリを作成し、ワークスペースにインストールします。リポジトリに slack-app-manifest.json が含まれているので、From an app manifest からアプリを作成すれば、Bot Token Scopeの設定も一発で終わります。
Bot Tokenに必要な権限は以下の通りです。
| スコープ | 用途 |
|---|---|
channels:history | パブリックチャンネルのメッセージ読み取り |
channels:read | パブリックチャンネルの一覧取得 |
users:read | ユーザーID → 表示名の解決 |
files:read | 添付ファイル・画像のダウンロード |
Bot Tokenを取得したら、同期したいチャンネルにBotを招待して(/invite @YourBotName)、プラグインの設定でBot Tokenを登録するだけです。あとは定期的に(デフォルトは30分間隔で)Slackのメッセージが自動でMarkdownに変換されてVaultに保存されます。
ちなみに、Bot Tokenのセキュリティにはちょっと気を使っています。Obsidianのプラグインはデータを data.json に保存するのが一般的ですが、Bot Tokenのような秘密情報を平文でVault内に置くのは気持ち悪い…。そこで、Electronの safeStorage APIを利用した暗号化ストレージにBot Tokenを保存する設計にしました。Vault内のファイルをGitHubに同期している人も多いと思うので、トークンが平文でリポジトリに入ってしまうリスクは避けたいところです。
スレッドリプライが地味に便利
このプラグインで個人的に気に入っている機能がスレッドリプライの扱いです。
例えば、気になる記事のURLをSlackにポンと投げます。あとでその記事を読んだときに、スレッドで感想や気づきを書いていく。すると、Markdownのノートにはこんな感じで出力されます。
https://example.com/interesting-article
---
### Thread Replies
**tubone24** (10:20:15):
この記事のポイントは〜
**tubone24** (10:25:33):
特に〜の部分が参考になった
URLと、それに対する自分の考えがセットでノートに残る。これがフリーティングノート的な使い方としてとても私はいいと思いました。なんならこのメモのまま残しておけますしね。
ツェッテルカステンの清書プロセスは回せなかったけど、リンク+自分の感想というフォーマットなら、スマートフォンでさっと書けます。
日付でグルーピングもできる
設定で Group Messages by Date を有効にすると、同じ日のメッセージが1つのデイリーノートにまとまります。ファイル構成は YYYY/MM/DD/ のサブフォルダで整理されるので、あとから振り返るときにも探しやすいです。
グループ化されたノートのなかでは、各メッセージが <!-- ts:xxxx --> というHTMLコメントマーカーで管理されているので、後からスレッドに新しいリプライが追加されても、既存ノートの該当箇所を正確に更新してくれます。
情報収集のフロー
obsidian-slack-syncでメモの入口ができたので、次は何をメモに取るか、つまり情報収集のフローを整理します。
Tech Blog Spiderで企業テックブログを自動巡回
情報収集の軸の1つが、以前作った Tech Blog Spider です。これは、複数の技術ブログのRSSフィードを GitHub Actions で30分ごとに巡回し、新着記事をSlackに自動投稿するシステムです。Pythonで書いていて、feedparser でRSSを解析し、差分検知で新しい記事だけを通知します。
地味に便利なのがキーワード抽出機能です。janome(形態素解析器)と pytermextract を使って、記事本文から重要度の高いキーワードを上位6個抽出してSlack投稿に含めるようにしています。RSS要約文だけだと精度が低いので、実際の記事本文をスクレイピングしてからキーワードを抽出する設計にしました。
1日に約50記事が流れてくるんですが、タイトルとキーワードを見るだけでこれは読みたい・これはスキップというトリアージがかなり効率よくできます。全部読む必要はなくて、見出しとキーワードでざっくりフィルタリングするだけで十分です。
購読しているのは企業のテックブログと、Zenn や Qiita のトレンドが中心です。完全無料の構成で動いているので、貧乏人の私にとってお金がかからないのもありがたい…。
XとSlack、あとは犬の散歩
それ以外の情報収集はわりとカジュアルです。朝の通勤電車でXを眺めて、面白そうな記事があったらリンクだけSlackのチャンネルにポイっと貼っておくだけです。
会社のSlackで同僚が面白いことをつぶやいていたらそれもメモするだけです。
飼い犬のむぎの散歩で公園に着いたらベンチに座ってスマートフォンをチェックするだけです。
パッと携帯を見たときに、おっこれ面白そうと思ったら、とにかくリンクを貼るだけ。読むのは後。
これが細切れ時間での情報収集のコツなのです。
積読ならぬ積リンク問題
ここまでの仕組みで、情報収集とメモの入口はうまく回るようになりました。
しかし、新たな課題が出てきました。
リンクだけ貼って、読まない!!!
みなさんもめちゃくちゃ身に覚えがありませんか?
積読ならぬ積リンクです。Slackのチャンネルにはリンクがどんどん溜まっていくんですが、全然読み進められないというあの現象…。
日本語の平均的な読書速度は1分間に約400〜600文字と言われています。つまり、8000文字の技術記事を1本読もうと思ったら、15分前後はかかる計算です。
5分、10分の隙間時間で8000文字の記事を頭からお尻まで読むのはなかなか難しいです。
かといって、リンクだけ貼ってあとから追いかけようとしても、結局追いかけきれない。リンクの山だけが増えていく…。
しかもやっかいなのが、リンクが溜まれば溜まるほどあとで読むのハードルが上がっていくことです。1日放置すると翌日にはまた新しいリンクが増えている…。もういいや全部は無理だ、と何度諦めてしまったことでしょう。
これはまずい。
大統領デイリーブリーフィングに学ぶ情報との向き合い方
ここで1つ、面白い話を引き合いに出したいと思います。
アメリカの大統領には毎日、ODNI(国家情報長官室)が各情報機関の情報を集約して作成する PDB(President’s Daily Brief) という最高機密のブリーフィング文書が届きます。世界中の安全保障情報がまとまった、いわば世界で最も重要な日報です。
オバマ大統領はこのPDBをタブレットで詳細に読み込む人でした。貪欲な読書家として知られ、書面を精読することで意思決定の基盤としていたそうです。
一方で、トランプ大統領は就任前から箇条書きが好きだ。できるだけ少ない方がいい(I like bullets, or I like as little as possible)と発言し、口頭での短いブリーフィングを好んだとされています(RAND Corporation の解説記事より)。
これが大統領としてどうかという話は一旦置いておいて、自分の情報との向き合い方を考えるヒントにはなるなと思いました。
以前の私はオバマスタイルでした。一次情報を全部自分でしっかり読んで、確認して、理解する。それが正しいと思っていましたし、実際に時間があるうちはそれで回っていました。でも、時間が取れなくなった今、すべてをオバマスタイルで処理するのは無理です。ならば、AIにブリーフィングを作ってもらい、自分はかいつまんで読む。 詳しく知りたいところだけ深掘りする。そういうトランプスタイル(言い方はアレですが…)に切り替える必要があるのかなと思っています。
Claude Codeで自分用ブリーフィングを作る
この自分用デイリーブリーフィングを実現するために、Claude Codeを活用することにしました。
ObsidianはただのMarkdownテキストファイルがローカル環境に転がっているだけの仕組みなので、Claude Codeとの相性がめちゃくちゃ良いです。テキストを読んで、Claude Codeの WebFetch や WebSearch を活用してWeb上の情報を調べて、付加情報を書いてまたMarkdownに還元する、という動かし方がとても自然にできます。
そこで、いくつかのClaude Codeスキルを作りました。
summarize-linksでリンクを自動要約する
1つが summarize-links というスキルです。Slackから同期されたMarkdownファイルの中からURLを検出して、そのリンク先の記事を取得・要約し、リンクの下にブロック引用形式で追記してくれます。
夜、ちょっと手が空いたときにPCを開いて /summarize-links と叩くだけ。あとはClaude Codeが勝手にリンクを巡回して、3〜5行の要約を生成してくれます。

正直に言うと、一次情報にあたった方がいいのは間違いないです。でも、時間がないときは要約だけでも読めばなんとなく知識として入ってくる。要約を読んだうえでこれはちゃんと元記事を読みたいと思ったものだけあとで読みに行けばいい。全部読もうとするから破綻するのであって、トリアージの精度を上げるという方向で考えたほうが現実的です。
スキルの全文は以下の通りです。URLの検出パターンや除外ルール、要約のフォーマット、サブエージェントを使った並列処理など、けっこう細かく指定しています。
summarize-links スキル全文
---
name: summarize-links
description: "Slackディレクトリ内のMarkdownファイルからURLリンクを検出し、
記事を取得・要約してリンクの下に追記する。"
argument-hint: "[ファイルパス(省略時はSlack全体をスキャン)]"
---
# summarize-links スキル
Slack ディレクトリ内の Markdown ファイルに貼られた URL リンクを検出し、
各 URL のページ内容を取得・要約して、リンクの下にブロック引用形式で追記するスキルです。
## 対象ディレクトリ
Obsidian Vault の Slack/ 配下
## 実行手順
### Step 1: 対象ファイルの特定
Grep で https パターンを検索し、URL を含むファイルを特定する。
### Step 2: URL の抽出と既存要約の確認
対象パターン: 裸URL、括弧付きURL
除外パターン: 画像リンク、既に要約済み、Slack内部リンク
### Step 3: 記事の取得
1. WebFetch で取得を試行
2. 失敗した場合、agent-browser を使用
3. それでも失敗した場合、WebSearch で検索
4. すべて失敗した場合はスキップ
### Step 4: 記事の要約生成
3〜5行程度の簡潔な日本語要約を生成。
主要ポイントを箇条書きで含める。
### Step 5: ファイルへの追記
URL直下にブロック引用形式で要約を挿入。
### Step 6: 詳細記事ノートの作成
Clippings/ フォルダに詳細な記事ノートを新規作成。
## サブエージェント活用
複数URLの記事取得・要約生成をURLごとに独立したサブエージェントで
並行起動して効率化する。メインコンテキストの保護のため、
大量の記事内容はサブエージェントに処理を委譲する。
slack-digestで週間ダイジェストを生成する
もう1つが slack-digest というスキルです。直近N日分のSlackメモを読み込んで、トピック別のダイジェストを生成してくれます。技術情報、イベント、個人的なメモなどにカテゴリ分けされるので、今週はこういうことに興味を持っていたんだなという振り返りが一目でできます。

slack-digest スキル全文
---
name: slack-digest
description: "Slackディレクトリの直近N日分を読み、
トピック別にダイジェストを生成する。"
argument-hint: "[日数(省略時は7日)]"
---
# slack-digest スキル
Slack ディレクトリの直近 N 日分のメモを読み込み、
トピック別にダイジェストを生成するスキルです。
## 対象ディレクトリ
Obsidian Vault の Slack/slack-memo/ 配下
## 実行手順
### Step 1: 対象ファイルの特定
今日からN日前までの日付範囲を算出し、
対応するファイル(YYYY/MM/DD/YYYY-MM-DD-obsidian.md)を特定。
### Step 2: コンテンツの分析
各メッセージを以下の観点で分類する:
- 技術情報: 技術記事、ツール、ライブラリの共有
- イベント: 勉強会、カンファレンスの情報
- 議論: スレッドでの議論内容
- メモ: 個人的なメモや気づき
### Step 3: ダイジェストの生成
トピック別のテーブル、統計情報を含むダイジェストを生成。
### Step 4: ファイルの保存
Slack/digest-YYYY-MM-DD.md に保存。
## サブエージェント活用
複数日分のファイル読み込みを並行サブエージェントで実行。
7日分なら2〜3個のエージェントに分担させ、
それぞれ2〜3日分を担当。
N日分の全メッセージをメインコンテキストに展開せず、
サブエージェントに分類・要約を委譲する。
まさに大統領のPDBのように、AIが情報を集約して自分用のブリーフィングを作ってくれるツールなわけです。
1日のワークフロー
ここまでの仕組みを使った、典型的な1日のフローを紹介します。
まず朝の通勤電車で、XのタイムラインやTech Blog SpiderがSlackに流してくれた記事をチェックします。面白そうなものがあったら、リンクだけSlackの専用チャンネルにポイっと投げておく。このときは中身を読まなくてOKです。
日中は、休日であれば飼い犬のむぎの散歩で公園に寄ったときとか、ちょっとトイレに立ったときとかに、さっき貼ったリンクのうち気になるものをちょっとだけ読みます。読んだら、スレッドに一言二言感想を書いておくだけ。
夜、ちょっと手が空いたタイミングでPCを開いて、Claude Codeで /summarize-links を実行します。日中に貼ったリンクのうち、読めなかったものの要約が自動生成される。その要約を読んで、気になるものだけ元記事を読みに行けばいい。
週末には /slack-digest で1週間分のダイジェストを生成して、自分がどんなことに興味を持っていたかを俯瞰します。
AIにブリーフィングを作ってもらった上で、自分は本当に気になるものだけ深掘りすることで、情報収集がだいぶ楽になりました。
最後に
育休中の生活をきっかけに、ObsidianとSlackとClaude Codeを組み合わせた、自分用デイリーブリーフィングシステムを構築してみました。
ツェッテルカステンの清書プロセスは回せなかったけど、Slackにリンク+一言感想を投げてClaude Codeに要約してもらうスタイルなら、細切れの時間でもなんとか回せています。まだ運用して数週間なので、この先どう変わっていくかはわかりません。
オバマスタイルからトランプスタイルへ。それが良いかどうかはさておき、私のような平凡エンジニアが限られた時間のなかで技術に食らいついていくには、こういう仕組みが必要なのかなと思うこの頃です。
