2026年4月4日土曜日

Obsidianのinbox整理をAIに任せてみたら、自分の「気になり方のクセ」が見えてきた

Obsidianのinboxにメモが溜まっていくのに、整理できない時期がしばらく続いていました。

「あとでまとめよう」と思って放り込んだメモが、気づくと数十件になっている。整理しようとデスクに向かっても、どこから手をつけていいかわからなくて、結局また閉じてしまう。そういう状態が繰り返されていました。

転機になったのは、inbox整理をAIに任せてみたことです。整理が進んだのはもちろんですが、それ以上に、整理後に残るメモのパターンを見て「自分の気になり方にはクセがある」と気づいたのが、予想外の収穫でした。

続かなかった理由は「分類の判断」が重かった

自分でinboxを整理しようとすると、必ず「このメモ、どこに入れるべきか」で止まります。

たとえば、
「これはObsidian運用の話として残したいのか、AI活用の話として残したいのか」
で止まることがありました。ブログネタっぽいメモなのに、同時にVault整理の話でもある。そういうメモは、どこに置いても少し違う気がして、結局そのまま残りやすかったです。

「topics? decisions? それとも別のinboxに移すべき?」という判断が、1件ごとにかかってくる。疲れているときや時間がないときは、その判断コストが重くて、整理を後回しにしてしまっていました。

「完璧に分類しなければ」という感覚も邪魔していたと思います。中途半端に整理するくらいなら、まとめてやろうと思って、まとめてやる余裕もなくて、溜まる一方でした。

AIに投げたら「判断の外注」ができた

inbox-triageスキルをCoworkに入れて、「inboxを整理して」と投げてみました。

最初はかなり雑に、
「inboxを見て、topics・decisions・別inbox候補に分けて」
くらいの指示で投げました。それでもAIは、
「これはObsidian運用寄り」
「これはブログ素材寄り」
「これはまだ判断保留」
という形で叩き台を返してきて、自分がゼロから考えるよりずっと動きやすいと感じました。

AIは各メモを読んで、「これはdecisions候補」「これはtopicsへ」「これは別のinboxへ移動を検討」と仕分けを提案してくれます。自分が「うーん」と悩むところを、一旦AIが判断の叩き台を出してくれる。

重要なのは、AIの提案をそのまま採用しなくてよいという点です。「ちょっと違うな」と思ったら修正すればいい。自分がゼロから判断するより、AIの案にOK/NGを返す方がずっと軽い。整理が進むのは、この「判断コストの軽減」が大きかったと感じています。

整理後に気づいた、自分の「残るメモ」のパターン

何度かinbox整理を繰り返すうちに、あることに気づきました。
整理後に「どのtopicsにも入らない」「分類が難しい」と残り続けるメモに、ある共通点があることです。

残りやすかったのは、
まだ結論が出ていないこと、
運用としては気になるけれど言い切れないこと、
誰かに見せるには早いけれど自分の中では引っかかっていること、
みたいなメモでした。

ブログの下書きにもなりそうで、でもまだ論点が固まっていない。そういうメモが、何度整理しても最後に残りやすかったです。

AIが「どこに入れるか迷う」と判断したメモは、自分も「どこに入れるか迷う」ものでした。そしてそういうメモの多くは、まだ自分の中で考えが固まっていない、宙ぶらりんなテーマのものでした。

逆に言えば、「すぐ分類できるメモ」は、自分の中でもう処理が済んでいる話だということです。inboxに「宙ぶらりんの思考」が溜まっているという構造が、整理を通じて初めて見えてきました。

まとめ

inbox整理をAIに任せて良かったのは、「続かなかった作業が動き出した」というだけではありませんでした。
整理のプロセスを外から見ることで、自分がどんなテーマに引っかかっていて、どんなメモを手放せないでいるかが見えてきました。それはある意味、自分の思考の現在地を確認する作業でもあったと思っています。

Obsidianのinboxは「後で考えるもの置き場」ではなく、「今の自分が気になっていること置き場」なのかもしれない。AIに整理を任せて、そういうことを考えるようになりました。

関連記事

2026年4月3日金曜日

AIとやり取りするなら、handoffメモを残すだけでかなり楽になった

 AIを使って作業する時、つい

「その場で会話が進めば十分」
と思いがちだった。

自分も最初はそうだったし、返ってきた内容がよければ、それでだいたい終わりだと思っていた。

でも、AIを1回だけ使うのではなく、

  • 何日かに分けて続ける
  • 別のAIに渡す
  • あとから自分で見返す

みたいな使い方が増えてくると、その場の会話だけでは少し足りなくなってくる。

最近それをかなり感じるようになって、今は
handoffメモ(引き継ぎメモ)を残すだけで、運用がかなり楽になる
と思うようになった。


最初は、その場で話が進めば十分だと思っていた

最初の頃は、AIとのやり取りはその場限りに近かった。

必要なことを聞いて、
返ってきたものを見て、
よければそのまま使う。

それで一応回っていたし、特に困っている感じもなかった。

だから、途中経過を別で残すとか、引き継ぎ用のメモを作るとか、そこまで必要だとは思っていなかった。

でも、作業が少し長くなってくると話が変わる。


困るのは、前に何を考えていたかが薄れていくことだった

AIを使っていて地味にしんどいのは、

  • 前に何を考えていたか
  • 何を決めたか
  • 何が未完了だったか

が、少しずつ薄れていくことだった。

その場では分かっていても、次の日になると意外と曖昧になる。

特に、

  • どこまで終わっているか
  • 何を次にやればいいか
  • この下書きの狙いは何だったか
  • どこを別のAIに見てもらいたいのか

このあたりは、会話ログだけだと後から拾いにくい。

しかも、AIをまたぐ時は、ほぼ毎回少し説明し直すことになる。
それが積み重なると、思ったより疲れる。


handoffメモがあるだけで、説明し直しがかなり減った

そこで最近は、必要なものだけ handoff メモとして残すようにしている。

大げさなものではなくていい。

  • 何のファイルか
  • 何をやりたいか
  • 今どこまで進んでいるか
  • 次に何を整えてほしいか

このくらいが書いてあるだけでも、かなり違う。

実際、これがあるだけで、別のAIに渡す時の説明がかなり短くなった。

「これを見て続きをやってほしい」
と言いやすくなるし、自分でも後から見返した時に、そのメモが何のためにあったのか思い出しやすい。

たぶん効いていたのは、情報量が増えたことではなく、必要な文脈だけを短く残せること だった。


本文そのものより、周辺のメモが効く場面がある

少し意外だったのは、本文そのものより、こういう周辺メモの方が効く場面があることだった。

記事の下書き自体は読める。
でも、それだけだと

  • どこがまだ弱いのか
  • 何を足したいのか
  • どういうトーンで整えたいのか

みたいなことまでは伝わりきらないことがある。

そこを handoff メモで一言添えるだけで、次の作業がかなり自然につながる。

この感じは、AIを1つだけ使う時より、複数のAIを併用する時の方が特に大きい気がしている。


handoffメモは、作業を止めないための小さい橋みたいなものだった

今の感覚だと、handoff メモは大きな設計資料というより、
作業を次につなぐための小さい橋 に近い。

完璧にまとめる必要はないし、長く書く必要もない。

でも、

  • その時の目的
  • 次に見てほしいポイント

だけが残っていると、作業がその場限りで終わりにくくなる。

自分はこれまで、AIとの会話そのものに意識が寄りがちだった。
でも最近は、会話の質と同じくらい
「どう引き継げる形で残すか」
が大事なんだと思うようになってきた。


今のところ、自分にはこのくらいの残し方がちょうどいい

今のところ、自分には

  • 本文は本文として残す
  • 補助メモは補助メモとして分ける
  • 引き継ぎたい時は handoff メモを短く残す

このくらいのやり方がかなり合っている。

派手ではないけれど、こういう小さい運用の方が後から効く。

AIとやり取りするなら、全部を覚えておく前提にするより、
次に渡しやすい形で少し残しておく 方がずっと楽だった。

今後やり方はまた変わるかもしれない。
でも少なくとも今は、handoff メモを残すだけでかなり助かっている。


関連記事

2026年4月2日木曜日

AIと一緒にVaultを使うなら、補助メモの置き場を分けた方がかなり楽だった

・ AIと一緒にVaultを使うなら、補助メモの置き場を分けた方がかなり楽だった


Obsidian の Vault を AI と一緒に触るようになってから、メモの種類が少しずつ増えてきた。

                                       

普通のメモや daily だけならそこまで迷わない。

でも、実際に運用し始めると、それ以外のものも増えてくる。


- 下書きの引き継ぎメモ

- 関連記事の候補メモ

- ネタ出しの共有メモ

- 整理用の補助メモ




こういう「本文そのものではないけど必要なメモ」が、思ったより増える。


最初はあまり深く考えず、inbox に近い場所へ置いていた。

すぐ見返せるし、その時はそれが一番楽だったからだ。


でも、しばらくすると少しずつ見通しが悪くなってきた。

未整理メモと補助メモが同じ場所にあると、見た目以上に頭が引っかかる。


最近それを整理してみて、やっぱり補助メモの置き場は分けた方がかなり楽だと感じた。


---


## 最初は、同じ場所にあってもそんなに困らない気がしていた


最初のうちは、inbox に補助メモが混ざっていてもそこまで違和感がなかった。


むしろ、

「今まさに触っているものが近くにある」

という意味では便利だった。


下書きの handoff メモも、

関連記事の候補も、

ネタ出しの共有メモも、

その時の自分にとっては全部「今必要なもの」だったからだ。


だから、その時点では置き場が多少混ざっていても回っていた。


でも、あとから見返す段階になると話が少し変わってくる。


---


## 困っていたのは、未整理メモより「役割の違うメモが混ざること」だった


しばらくして分かってきたのは、

inbox が重くなる原因は、単に未整理メモが多いことだけではなかったということだった。


もっと地味に効いていたのは、

役割の違うメモが同じ場所にあることだった。


たとえば、


- まだ整理していないメモ

- テーマ別に分けた inbox

- 記事用の handoff メモ

- 関連記事ブロックの補助メモ

- ネタ出しの共有メモ


こういうものが一緒に並ぶと、

どれが「これから整理する対象」で、

どれが「整理を助けるための補助」なのかが一目で分かりにくくなる。


この違いは小さそうで、実際にはかなり大きかった。


inbox を見た時に、頭の中で

「これは処理対象」

「これは参照用」

「これはブログ用の運用メモ」

と切り替え続ける必要があるからだ。


たぶん自分がしんどかったのは、量そのものより、この切り替えの多さだった。


---


## それで補助メモだけ別フォルダに寄せたら、かなり見やすくなった


そこで最近は、ブログ運用の補助メモを別フォルダに寄せるようにした。


実際には、


- 下書きの handoff メモ

- 関連記事メモ

- ネタ出し共有メモ


このあたりを `docs/blog_support` にまとめた。


やったこと自体はかなり地味だし、大きな機能追加でも何でもない。

でも、これが思ったより効いた。


`inbox` には未整理メモやテーマ別 inbox を残して、

補助メモは補助メモとして別に置く。


これだけで、inbox を開いた時の迷いがかなり減った。

前より「ここは今から整理するものを見る場所」と意識しやすくなったからだと思う。


---


## 大事だったのは、きれいさより役割を混ぜないことだった


今回やっていて思ったのは、

最初に必要なのは完璧な構造ではなく、

役割の違うものを混ぜすぎないことなんだな、ということだった。


Vault を整えようとすると、つい

「最適なフォルダ構成」

とか

「理想のルール」

を考えたくなる。


でも、実際にはそこまで大きな話でなくても、

補助メモを補助メモとして分けるだけでかなり違う。


少なくとも自分の場合は、

inbox をきれいにしたかったというより、

inbox を「inboxとして見られる」状態に戻したかったのだと思う。


---


## AIを併用するほど、本文以外のメモは増えやすい


この感覚は、AIを複数使うようになるほど強くなる気がしている。


下書きの本文だけならそこまで増えないけれど、

AIと一緒に進めると、その周辺にあるメモが増えやすい。


- 引き継ぎメモ

- 方針メモ

- 関連記事候補

- ネタ出し

- 途中経過の整理メモ


こういうものは便利だし、実際かなり助かる。

でも、置き場が曖昧なまま増えると、あとでじわじわ効いてくる。


だから最近は、本文そのものだけでなく、

「本文以外のメモをどこに置くか」

も運用の一部として考えるようになった。


これを決めておくだけで、別のAIとやり取りする時もかなり渡しやすい。


---


## 今のところ、自分にはこの分け方がかなり合っていた


今のところ、自分には


- `inbox` は未整理メモやテーマ別 inbox を置く

- ブログの補助メモは `docs/blog_support` に寄せる

- 整理した内容は `daily` にも残す


この分け方がかなり合っている。


派手ではないけれど、こういう整理の方がちゃんと効く。

AIと一緒に Vault を触る時ほど、

メモの量より「役割の混線」を減らすことの方が大事なのかもしれない。


今後また運用が変わることはあると思う。

でも少なくとも今は、補助メモの置き場を分けただけで、かなり楽になった。


---


## 関連記事


- ObsidianをAI向けに整える時、最初にやったのは自動化じゃなくて詰まりどころを減らすことだった

- inboxを完璧に整理するより、次に触る順だけ決める方が続いた

- frontmatterは最初から完璧に揃えるより、最小限だけ決めた方が続いた

- AIに記事を丸投げしないために、役割分担を考えるようになった

 

2026年4月1日水曜日

frontmatterは最初から完璧に揃えるより、最小限だけ決める方が続いた

 ・frontmatterは最初から完璧に揃えるより、最小限だけ決める方が続いた

Obsidian を AI と一緒に使うようになると、frontmatter をどうするかはかなり気になってくる。
ノートの種類や状態が少しでも見えた方が、あとで読み返しやすいし、AI 側も扱いやすそうに見えるからだ。

自分も最初は、どうせやるならちゃんと揃えたくなっていた。
項目もできるだけ丁寧に決めたくなるし、後から困らないように最初に設計しておきたくなる。

でも、実際に触ってみると、最初から完璧に揃えようとするほど続きにくかった。
今はむしろ、最小限だけ決めておく方がずっと運用しやすい と感じている。


最初は、項目をしっかり作った方がいいと思っていた

frontmatter を入れるなら、最初にある程度きれいに設計した方がいい気がしていた。

たとえば、

  • ノートの種類
  • 進捗状況
  • 関連プロジェクト
  • タグ
  • 優先度
  • 情報源
  • 更新日

こういうものをしっかり持たせた方が、あとで便利そうに見える。

実際、見た目としてはかなり整うし、「管理している感」も出る。
だから最初は、項目は多い方がいいのではと思っていた。

でも問題は、それを毎回埋める側の自分が続くかどうかだった。


項目が多いほど、ノートを作る時の勢いが止まりやすかった

実際にやってみると、frontmatter の項目が増えるほど、ノートを作る時の勢いがかなり削られる感覚があった。

まだ考え途中のメモなのに、

  • 種類は何か
  • 状態は何か
  • 優先度はどうか
  • タグは何か

と埋め始めると、書く前に少し疲れる。

しかも、書き始めた直後だと、まだ決めきれないものも多い。
その段階で無理に埋めると、あとでズレることもある。

結局、項目が多いこと自体より、
「今ここでそこまで決める必要があるのか」
が自分の中で引っかかっていたのだと思う。

ノートを残すことより、項目を埋めることが先に来ると、だんだん面倒になっていく。


それで最近は、最小限だけに絞る方が合っていた

そこで最近は、frontmatter は最初から全部を持たせるのではなく、最低限だけに絞るようにしている。

自分の中で今しっくりきているのは、

  • type
  • status
  • updated
  • project
  • next_action
  • source

このくらいの項目だった。

これなら、ノートが何者で、今どういう状態で、次に何をするのかが最低限見える。
しかも、そこまで書く負担も重くなりすぎない。

特に大きかったのは、next_action があることだった。
情報が整理されていることより、次に何をするかが残っていること の方が、自分の運用ではずっと効いていたからだ。


きれいな管理より、続けて埋められることの方が大事だった

今振り返ると、frontmatter で欲しかったのは完璧な管理ではなかった。

そうではなくて、

  • ノートの役割が最低限分かる
  • 今動いているか止まっているかが見える
  • 次に何をやるかを拾える
  • AI が読んだ時にも迷いにくい

このくらいで十分だった。

むしろ、最初から項目を増やしすぎると、
「ちゃんと埋めないといけない」
という感覚が強くなってしまって、運用そのものが重くなりやすい。

きれいに揃っていることより、毎回ちゃんと残せることの方がずっと大事だった。


全ノートを一気に直さないのもかなり大きかった

もう1つ大きかったのは、既存ノート全部を一気に揃えようとしなかったことだった。

Vault を見直していると、どうしても過去ノートまで全部きれいにしたくなる。
でも、それをやると作業量が急に大きくなるし、途中でルールが変わるとまた気になってくる。

だから最近は、

  • 新規ノートから入れる
  • よく使うノートだけ整える
  • 過去ノートは必要になった時だけ触る

このくらいのやり方にしている。

この方が、運用を止めずに少しずつ揃えやすかった。


最初に必要だったのは、理想の設計より止まりにくい形だった

結局、自分に合っていたのは、最初から理想の frontmatter を作ることではなかった。

そうではなくて、

  • 書く時に重すぎない
  • 後で見た時に少し分かる
  • AI が読んでも崩れにくい
  • 少しずつ広げられる

こういう 止まりにくい形 を先に作ることだった。

frontmatter は、ちゃんと設計した方がよさそうに見える。
でも今の自分には、最初から完璧を目指すより、最小限だけ決めて、それを続ける 方がずっと合っていた。

地味だけど、このやり方の方がちゃんと残る。


関連記事

2026年3月31日火曜日

inboxを完璧に整理するより、次に触る順だけ決める方が続いた

 

・inboxを完璧に整理するより、次に触る順だけ決める方が続いた

Obsidian を使っていると、inbox の扱いはずっと悩みどころになりやすい。
とりあえず入れておける場所があるのは便利なんだけど、気づくとそこに何でも集まり始める。

自分も最初は、inbox をちゃんと整理できる形にしたいと思っていた。
できればきれいに分類したいし、後で見返しても迷わないようにしたい。
でも、しばらくやっていて分かったのは、完璧に整理しようとするほど逆に止まりやすい ということだった。

最近はむしろ、

「全部をきれいに並べる」より
「次にどれを触るかだけ決める」

くらいの方がずっと続いている。


最初は、inbox をちゃんと整理できる形にしたかった

最初に考えていたのは、いわゆる分かりやすい inbox だった。

何が入っていて、
どの話題に属していて、
何をどこへ移せばいいかが見えている状態。

そういう形にできれば気持ちいいし、運用も安定しそうに見えた。

でも実際には、inbox に入るものはそこまできれいじゃない。

  • まだ考え切れていないメモ
  • 一時的に置いておきたい話
  • どこへ送るべきか決まっていないもの
  • 後で記事になるかもしれない素材
  • その日の思いつき

こういうものが普通に混ざる。
しかも、入れた時点では重要度も粒度も揃っていないことが多い。

だから、最初から完璧に分類しようとすると手が止まる。
「これはどこに置くのが正しいか」を考え始めた時点で、もう少し面倒になる。


問題は、散らかっていることより「次が決まらないこと」だった

しばらくして気づいたのは、inbox の本当の問題は、散らかっていることそのものではなかったということだった。

もっと困るのは、

  • どれから触ればいいか分からない
  • 何を今週動かすのか決まらない
  • 保留のまま増えていく

この状態だった。

逆に言うと、全部が整っていなくても、
「次はこれを触る」
が見えていれば、意外と止まりにくい。

この感覚が自分の中ではかなり大きかった。

inbox を完璧に片づけることより、
今の自分にとって優先度の高いものを1つだけ前に出せることの方が、ずっと重要だった。


それで最近は、分類より「優先順位を決める場所」として見るようになった

そこで最近は、inbox を「整理棚」というより、
「次に触る順を決める場所」 として見るようになった。

要するに、完璧に分類するより、triage 的に見る感覚に近い。
とりあえず、優先順位だけ決めるやり方だ。

たとえば inbox を見た時に、

  • 今すぐ触る
  • 今週は保留
  • 参照用に置いておく

このくらいに分けられれば、とりあえず十分だと思うようになった。

ここで無理に「最終的にどこへ置くのが正しいか」まで決めなくてもいい。
今必要なのは、分類の正しさより、次の動きやすさ だからだ。

この見方に変えてから、inbox を開くハードルがかなり下がった。
前は「ちゃんと整理しなきゃ」と思って重かったのが、
今は「とりあえず次に触るものだけ決めればいい」と思えるようになった。


巨大な1ファイルに戻さないのも、かなり大事だった

もう1つ効いたのは、inbox をまた巨大な1ファイルに戻さないようにしたことだった。

何でも1か所に集めると、その場では分かりやすい。
でも、量が増えると結局また見通しが悪くなる。

しかも、話題ごとの温度差も大きい。

  • すぐ記事にしたい話
  • まだ考え途中の話
  • 後で見返せばいい記録
  • 長期テーマに育つかもしれないメモ

こういうものが全部同じ場所にいると、inbox が「入口」ではなく「墓場」に近づいてしまう。

だから最近は、必要に応じてテーマ別に分けるようにしている。
ただし、ここでも大事なのは完璧な分類ではなく、
今の自分が触りやすい単位に分けること だった。


自分に合っていたのは、きれいさより止まりにくさだった

今振り返ると、自分が欲しかったのは、きれいに整理された inbox そのものではなかった。

そうではなくて、

  • 開くのが重くない
  • 次に触るものが見える
  • 保留でも罪悪感が増えすぎない
  • その後に topics や記事下書きへつなげやすい

このあたりだった。

たぶん inbox は、最初から完成形を目指すと苦しくなりやすい。
特に、考え途中のメモや、まだ言葉になっていないものまで入ってくるなら、なおさらだと思う。

だから今のところは、

「完璧に整理する」より
「次に触る順だけ決める」

くらいの方が、自分にはずっと合っていた。

地味だけど、このくらいの方が本当に続く。


関連記事

ObsidianをAI向けに整える時、最初にやったのは自動化じゃなくて詰まりどころを減らすことだった

・ObsidianをAI向けに整える時、最初にやったのは自動化じゃなくて詰まりどころを減らすことだった

最近、Obsidian の Vault を AI と一緒に使うことが増えてきた。
使っているうちに少しずつ分かってきたのは、最初に必要なのは派手な自動化ではない、ということだった。

もちろん、自動化にはかなり憧れがある。
毎日の整理が勝手に進んだり、メモから次のアクションが自動で出てきたり、週次レビューの下書きまで流れてきたりしたら、かなり便利そうに見える。
実際、自分も最初はそっちに目が向いていた。

でも、自分の Vault を見直してみると、その前に詰まる場所がいくつもあった。

inbox は膨らみやすい。
何が今動いていて、何が止まっているのか分かりにくい。
ノートごとの役割も揃っていない。
次に何をやるかが、その場の記憶に依存している。

こういう状態だと、AIを入れても思ったほど気持ちよく回らない。
読めることは読めても、判断しにくい。
要約はできても、その先の整理につながりにくい。

それで最近は、まず 「詰まりどころを減らす」 方向で Obsidian を整えるようになった。


最初に欲しかったのは、賢い仕組みより止まりにくさだった

少し前までは、AI をうまく使うには高機能な仕組みが必要だと思っていた。
テンプレート、スクリプト、連携、細かいルール。
そういうものをしっかり作らないと、AI向けの Vault にはならない気がしていた。

でも、実際に欲しかったのはもう少し手前のものだった。

  • 今どのノートが何者か分かる
  • 次にやることが拾える
  • inbox が墓場にならない
  • 週単位で見直せる

このくらいでも、かなり違う。

逆に言えば、ここが曖昧なままだと、AI が賢くても運用は止まりやすい。
その場では助かっても、次の日に続きをやろうとした時にまた引っかかる。

最近は、この 「次の日に止まりにくいか」 を前より気にするようになった。
一回うまくいくことより、続きやすいことの方がずっと大事だと思い始めたからだ。


まずやったのは、派手な改善ではなく地味な整理だった

そこでやったことは、かなり地味だった。

新規ノートはテンプレから作る。
frontmatter は最小限に絞る。
inbox を巨大な1ファイルで抱え込まない。
weekly review をちゃんと残す。

書くと本当に地味だし、見た目の変化も大きくはない。
でも、自分の中ではこのあたりがかなり効いた。

特に大きかったのは、全部を一気に直さない と決めたことかもしれない。

既存の Vault を見ると、どうしても一気に揃えたくなる。
でも、それをやろうとすると途中で疲れる。
しかも、途中でルールが変わると、前に直したものまでまた気になってくる。

だから最近は、

  • 新規ノートから整える
  • よく使う場所から整える
  • 過去ノートは必要になった時だけ触る

このくらいの感覚でやっている。

完璧ではないけれど、この方が止まりにくい。


AI向けに整えるというより、AIが読んでも崩れにくくする感覚

ここで少し感覚が変わったのは、
「AI向けに最適化する」 というより、
「AIが読んでも崩れにくい形にする」
と考えるようになったことだった。

最初は、AIに合わせた設計をしないといけないと思っていた。
でも、それをやりすぎると、逆に特定の道具に寄りすぎる気がした。

それよりも、

  • Markdown で残る
  • ノートの役割が分かる
  • 状態が少し見える
  • 次アクションが拾いやすい

このくらいを揃えておく方が、結果的に長く使いやすい。

Claude でも、Codex でも、別のAIでも、最低限読める形にしておく。
最近はその方がずっと安心感がある。

AIは入れ替わるかもしれないけれど、Vault 自体は母艦として残したいからだ。


高度な自動化は、土台が少しできてからでも遅くなかった

最初は、自動化を後回しにするのは遠回りな気もしていた。
でも実際には、詰まりどころを減らしてからの方が、自動化したい場所も見えやすくなった。

たとえば、

  • どこで inbox が膨らむのか
  • weekly review のどこが面倒なのか
  • どの frontmatter なら本当に使うのか

こういうことは、少し回してみないと分からない。

最初から全部を想像で決めるより、
最低限の形で回してから、詰まった場所だけを自動化する方が自然だった。

今もまだ途中だけれど、前より 「何を自動化したいのか」 がかなりはっきりしてきた。
これは、最初に地味な整理をしたから見えてきたものだと思う。


今のところ、自分にはこの順番が合っていた

結局、自分に合っていた順番はこうだった。

まず、詰まりどころを減らす。
次に、AIが読める土台を作る。
その後で、本当に必要なところだけ自動化を考える。

派手さはないし、最短ルートにも見えない。
でも、今のところはいちばん続いている。

Obsidian を AI と一緒に使いたいと思うと、どうしても大きな仕組みの方に目が向きやすい。
でも、自分の実感では、その前に

  • 止まりにくいか
  • 次が拾いやすいか
  • 別のAIが来ても読めるか

このへんを整えておく方がずっと効いた。

自動化を急ぐより先に、まず止まりにくい土台を作る。
今のところ、自分にはこの順番がいちばん合っていた。


---------------------------------
関連記事

Coworkの制限がきつくて、Obsidian運用を止めない形を考え始めた

・Coworkの制限がきつくて、Obsidian運用を止めない形を考え始めた

最近、Obsidian の Vault を AI と一緒に触る流れがだいぶ固まってきた。
ただ、それと同時に、少し気になることも増えてきた。

1つのAIでずっと回せたら楽なんだけど、実際にはそうもいかない。
特に Cowork は、考えを整理したり、次に何をやるか決めたりする場面ではかなり助かっている。
でも、少し長く使いたい時とか、重めの整理を続けたい時とか、細かい往復が増える時になると、やっぱり制限が気になってくる。

そのたびに「今日はここまでか」と止まるのが、地味にしんどい。
最近は、そのことを前より強く感じるようになってきた。

最初は、別にそこまで深く考えていなかった。
強いAIが1つあれば、だいたい何とかなるだろうと思っていたし、できるだけ同じ場所で相談も整理も下書きも回した方が早い気もしていた。

でも、続けていると、作業って思ったより種類が違う。

今日は何を優先するか考える時間もある。
メモを読みながら整理方針を決める時間もある。
Markdown を整える時間もあるし、新しいノートを起こす時間もある。
同じような作業を何回も繰り返す日もある。

これを全部、同じ前提で回すのはやっぱり少し無理があるんだなと思い始めた。

特に Obsidian の Vault は、会話だけで終わるものじゃない。
既存のメモ、daily、inbox、手順書みたいなものが少しずつ積み上がっていく。
そうなると、その場の会話がうまく回るかどうかだけじゃ足りなくて、途中で止まっても流れ全体が止まらないことの方が大事になってくる。

それで最近は、
「Cowork をやめるかどうか」
ではなく、
「Cowork が止まった時に、別のAIへ自然に渡せる形を作れないか」
を考えることが増えた。

ここで自分の中でしっくりきたのは、「置き換え」より「肩代わり」という感覚だった。

どちらかがいらなくなるわけではない。
ただ、同じ場所に全部抱え込まなくてもいいんじゃないか、と思うようになった。

方針を考えるとか、迷いを言語化するとか、このメモをどう扱うか相談するとか、そういう流れを整える時間はある。
一方で、既存メモをまとめるとか、weekly review の下書きを作るとか、ブログ素材を拾って整理するとか、Markdown ファイルを実際に起こすとか、そういう「手を動かす側」の時間もある。

全部をきれいに分けられているわけじゃないけど、少なくとも同じノリで全部を回そうとしない方が楽なんだろうな、という感覚はだんだん強くなってきた。

ただ、ここで1つ問題がある。
作業を別のAIへ逃がそうとしても、Vault 側が最低限読める形になっていないと、結局また止まる。

自分の Vault も最初から整っていたわけではない。
むしろ、inbox は膨らみやすいし、next action は見えにくいし、frontmatter は揃っていないし、weekly review も弱い。
そういう、よくある詰まり方を普通にしていた。

だから最近は、高度な自動化を急ぐより前に、
「どのAIが来ても最低限読める形にしておく」
ことの方を優先している。

新規ノートはテンプレから作る。
frontmatter は最小限に絞る。
inbox は巨大な1ファイルに戻さない。
weekly review はちゃんと続ける。

書くと地味なんだけど、こういう土台があると、どこかが重くなった時に別の場所へ逃がしやすい。
最近はそこがかなり大きい気がしている。

結局、自分が欲しかったのは、最強のAIを1つ決めることではなかったのかもしれない。

そうじゃなくて、

制限が来ても流れが止まりにくいこと。
作業を別のAIへ渡しやすいこと。
Vault の中身がどこか1つに閉じすぎないこと。

そのへんの方が、今の自分にはずっと大事だった。

AIを使っていると、どうしても性能比較の話になりやすい。
でも、日々の作業に入れてみると、最後に効いてくるのは性能だけじゃない。
止まりやすい場所をどう前提にするか、止まった時にどう逃がすか、その方が自分には大きかった。

まだ途中なので、これで完成とは全然思っていない。
でも今のところは、

  • 止まりやすい場所を前提にしておく
  • 別のAIへ渡しやすい形を考える
  • Vault 側を最低限読める形に整える

この3つを意識するだけで、前よりかなり動きやすくなった。

しばらくは、たぶんこの方向で少しずつ整えていくと思う。 


関連記事

2026年3月29日日曜日

AIに「自分」を渡すファイルを作ったら、毎回のセッションが変わった

・AIに「自分」を渡すファイルを作ったら、毎回のセッションが変わった

AIを使い続けていると、だんだん気になってくることがある。
作業の内容は積み上がっていくのに、AIへの自己紹介は毎回ほぼゼロから始まる、ということだ。

自分はどんな仕事をしているのか。
今どんな作業を進めていて、何を優先しているのか。
どういう道具や環境で動いているのか。

そのへんを毎回説明していると、地味に時間がかかる。
しかも、ある日は詳しく書き、ある日はかなり省略する。
渡す前提がそのたびに少しずつ違うと、返ってくる整理や提案の粒度も微妙にブレる。

これは一度整理した方がいい。
そう思って作ったのが claude_context.md だった。

作ろうと思ったのは、説明を減らしたかったからというより、前提の渡し方をそろえたかったから

きっかけは、「毎回説明するのが面倒だった」だけではない。
どちらかというと、毎回同じ形式で前提を渡せるようにしたかった という方が近い。

AIに何かを任せるとき、前提情報の渡し方がセッションごとにバラバラだと、返ってくる結果もバラつきやすい。
特に、継続して整理したい作業や、あとから見返したい記録系の作業では、このブレがじわじわ効いてくる。

その場その場で説明を組み立てるのではなく、最初から決まった形で渡せるファイルがあれば、AIへの依頼はもっと安定するはずだと考えた。

何を入れるかは、思ったより時間がかかった

claude_context.md に何を書くかを決めるのは、思っていたより難しかった。

あれもこれも入れたくなる。
でも、情報を盛りすぎると読み込みが重くなるし、更新も面倒になる。
逆に削りすぎると、文脈ファイルとしての意味が薄くなる。

最終的には、AIが作業を始めるために必要な最低限の文脈 に絞ることにした。
今はだいたい次のような内容を入れている。

  • 基本プロフィール
    仕事、PC環境、そのほか作業前提になる情報
  • 現在進行中の作業やプロジェクト
    それぞれの現在地と次のアクション
  • AI活用方針
    どう使うか、どこまで任せるか
  • 確定済みの主要方針
    あとからブレると困る判断の抜粋
  • 保管場所の構成
    どこに何があるかの全体像

これを1ファイルにまとめて、セッション開始時に読ませるようにしている。

「AIに覚えさせる」より、「自分が渡す」と考えた方がうまくいった

このファイルを作る前は、どこかで
「AIがもっと覚えてくれたら便利なのに」
と思っていた。

でも実際に運用してみると、発想は逆の方がうまくいくとわかった。
AIは毎回リセットされる。そこは前提として変わらない。

だったら、記憶してもらうことを期待するより、自分の側で文脈を管理して、必要なときに毎回渡す 方が確実だった。

その方がコントロールもしやすい。
何を渡していて、何を省いているかが自分でわかる。
しかも、ファイルを更新するたびに「今の自分の状況」が少し整理される。

作業が進んだら書き換える。
方針が変わったら更新する。
この更新作業自体が、自分の現在地を確認する機会にもなっていた。

使ってみて、一番変わったのは立ち上がりの速さだった

一番変わったのは、セッションの立ち上がりだった。

以前は、まず「今何をやっているか」から説明し始める必要があった。
今は claude_context.md を渡せば、そこからすぐ本題に入れる。

説明に使っていた時間が、そのまま作業時間になった感覚がある。

もうひとつ変わったのは、AIへの依頼の精度だ。
前提がそろっていると、返ってくる提案や整理の質が安定しやすい。

何も知らない相手に毎回説明するのと、
自分の状況をひと通り把握した前提で入るのとでは、やはり違う。

まとめ:文脈はAIに期待するより、自分で持って毎回渡した方が安定する

AIとやり取りを続けていると、どうしても
「セッションをまたいで覚えていてくれたら楽なのに」
と思う場面が出てくる。

でも今のところ、自分には
文脈は自分で持って、必要なときに毎回渡す
という形の方が合っていた。

claude_context.md は、そのための一枚だ。
完成形というより、使いながら育てていく前提のファイルだと思っている。

今のところ、これがあるかないかで、毎回の作業の入りやすさはかなり違う。
AIに何かを覚えてもらう仕組みを探すより、まずは自分の文脈を自分で管理する。
その方が、少なくとも今の自分の運用では安定している。


関連記事

自分の作業フローをCoworkのスキルにしてみたら、習慣の言語化を迫られた

 

・自分の作業フローをCoworkのスキルにしてみたら、習慣の言語化を迫られた

Coworkを使っていると、同じような頼み方を何度もしていることに気づく。

ブログのネタを出してもらう。
その中から1本選んで、下書きを作ってもらう。
必要ならObsidianに保存する。

一つひとつは大した作業ではないけれど、毎回最初から説明するのは地味に面倒だった。
それであるとき、「この流れごとスキルにできないか」と思って試してみた。

実際にやってみると、スキルを作ること自体より、自分が普段どうやっているかを言葉にする方がずっと大変だった。

スキルを作るには、「自分がどうやっているか」を説明しないといけない

スキルというのは、ざっくり言えば
「こう頼まれたら、こういう順番で動く」
をあらかじめ決めておくものだと思っている。

Coworkにブログ管理系のスキルを作れないか相談したとき、最初に詰まったのはここだった。

たとえば、

  • 公開済み記事のリストはどこで管理するのか
  • 下書きはどこに保存するのか
  • アイデアと下書きをどう分けるのか

そういうことを聞かれる。
見れば当たり前の質問なのに、これが意外とすんなり答えられなかった。

Obsidianで管理したい気持ちはあった。
でも、具体的にどのファイルに、どういう形で持つのかを改めて聞かれると、思ったより決まっていなかった。

「なんとなくやっている」は、スキルにならない

今までのブログ運用は、かなり「なんとなく」の積み重ねで回っていた。

ネタが思いついたらメモする。
書けそうなら下書きを起こす。
書き終わったらBloggerに貼る。

流れとしては一応あったけれど、
それがどこに保存されていて、いまどの状態なのかまできちんと管理できていたかというと、正直かなり怪しかった。

スキルにしようとすると、その曖昧さを放置できない。

  • どのフォルダに保存するのか
  • アイデア一覧はどこに置くのか
  • 下書き本体は別ファイルにするのか
  • 公開済みの記録はどこに持つのか

こういうことを一つずつ決めていく必要がある。
やってみると、自分の運用の曖昧な部分がかなり見えてきた。

言語化しようとして、初めて「決まっていなかった」と気づく

一番時間がかかったのは、保存先の設計だった。

最初は「AI_workspace に置けばいい」とかなりざっくり考えていた。
でも実際に考え始めると、それではあとから見返しにくい。

アイデア一覧と、記事ごとの下書き本体は分けた方がいい。
そう考えて、最終的には

  • blog_ideas.md で一覧管理
  • blog_draft_〇〇.md で記事ごとの下書き管理

という形に落ち着いた。

今振り返ると、この整理はスキル化を考えなければ、たぶん後回しのままだったと思う。
「どこかに保存してある」で済ませて、そのたびに探す、という運用を続けていた気がする。

スキルを作ろうとして、運用の土台まで見直すことになった

スキルが形になってからは、ネタ出しや下書きの流れをかなり短く呼び出せるようになった。

ただ、実際にはそれ以上に、自分の中の運用が前よりはっきりしたことの方が大きかった。

何が公開済みで、何がアイデア段階で、何が下書きなのか。
その状態が、少なくとも前よりは見えるようになった。

スキルを作るために始めたはずなのに、やっていたのは結果的に
情報整理の土台を作り直す作業
でもあったんだと思う。

まとめ:スキル化は、自分の習慣を棚卸しする作業でもある

Coworkのスキル機能は、繰り返し作業をまとめるためのものだ。

でも実際に触ってみると、その前に必ず必要になるのが、
自分は何を、どういう順番でやっているのかを言葉にすること
だった。

そこがいちばん難しくて、いちばん時間がかかった。
ただ、その工程を通ると、スキルができるだけでなく、自分の運用も少し整理される。

「なんとなくやっている」を言語化するきっかけとして、スキルを作ってみる。
これは思っていた以上に意味のある作業だった。


関連記事

[Coworkを使い始めて最初に詰まった3つのこと]

[AIに記事を丸投げしないために、役割分担を考えるようになった]

[AIで稼ぐ前に、自分用の第二の頭を作りたい]

生成AIは万能じゃない。むしろ向き不向きを見抜く力の方が大事だった

 ※この記事は 2026年4月時点 の使用感です。 AI系の機能や使い勝手は更新が速いため、その時点の実運用メモとして読んでください。 最近、生成AIを触っていて思うのは、うまく使うために必要なのは、 何でもできると信じることではなかった 、ということだった。 もちろん、今...