2025年のAI活用を振り返って
これまで3回にわたって、2025年に僕が実践したAI活用法を紹介してきた。Part.1では、AIを「社会のゲームチェンジャー」として語ることへの懐疑と、個々の課題に対する実用的なツールとしての可能性を論じた。Part.2では、AIを「壁打ち」の相手として使い、6つの目的を明確にすることで思考を深める方法を紹介した。Part.3では、エージェントAIによる論文執筆のケーススタディとして、CONTEXT.mdという「仕様書」を用いた構造化された執筆フローを説明した。
一見バラバラに見えるこれらの取り組み。しかし、2025年の終わりに振り返ると、一つの共通点が見えてきた。それは何だったのか。そして、それは「これからのAIとの付き合い方」にどう関わるのか。
変化する状況と、硬直化したシステム
話は今年の春に遡る。僕は長年、Notionで日々のタスクやプロジェクト、ジャーナルをすべて一元管理してきた。ポータルページと各種データベースで「完璧な運用」を目指したシステムで、タスクは締切順に並び、プロジェクトごとにページが整理され、週次レビューのテンプレートも用意されていた。
しかし、この春に新しい仕事が増え、イレギュラーなタスクが入るようになった。既存のプロジェクト構造に当てはまらない業務が次々と舞い込んでくる。どのプロジェクトに紐づけるべきか分からず、結局Notionには記録せず終いになって、取りこぼしが発生し始めた。プロジェクトページには数行のメモが残っているが、書いただけで放置されていく。タスクは締切順に並び、機械的に消化されていくのだけど、「先月は何をしていたか」と聞かれても答えられない。
週末、リマインダーが鳴る。「週次レビューを書く」。Notionのテンプレートを起動するも、何を書けばいいのか分からない。レビューする項目もしっかり設定されているから、思いついたことを一行だけ書くというわけにはいかない。結局億劫になって書かずに閉じた。ジャーナルも同じだった。それなりの長文を書かないといけない気がして、入力が減っていった。
Notionに問題があったわけではない。「日々変わる状況を、硬直的なシステムに無理に当てはめようとした」ことが問題だったのだ。完璧な運用を目指して構築したシステムは、環境が安定している限りは機能する。しかし、状況が変化すると、途端に使いづらくなる。変化に適応できるフローが必要だと思った。
ちょうどその頃、Part.3で書いたように、論文執筆にエージェントAIを利用するトライアルを始めた。参考文献をディレクトリで管理し、指示書でそれらを統合して文章化する。ファイルベースの柔軟性と構造化の両立。この考え方を、日常的な思考やタスク管理にも応用できるのではないかと妄想し始めた。
そこでまず導入したのがObsidianだった。実は2024年に一度試していたのだけど、当時は活用法が見つからず断念していた。論文執筆の経験を経て、VS Codeのワークスペースとしてマークダウンファイルを管理すれば、AIに渡しやすいという可能性が見えてきた。
ObsidianとNotionの二元管理
再導入にあたって、VS Codeのワークスペースと保管庫を共通化し、マークダウンビューワーとしてObsidianを併用することにした。プラグインのThinoを使って昔のSNSみたいな感覚で「思いついたことを即座に記録」し、デイリーノートとして保存。Templaterでは「AIとの対話記録」を自動生成するようにした。
これによって、変化する思考やタスクを、柔軟に記録できる場所ができた。一方、Notionは「確定したプロジェクトとタスク」を管理する場所として継続した。フローとストックの分離という運用が、ここから始まった。
その後、VS Code上のClaude Codeから、日々の記録と他のサービスの情報を集約して「今日の予定とタスク」を提案させるフローを導入した。MCP経由でNotion（タスク）、Slack（投稿）、Google Calendar（予定）を取得し、Obsidianの記録と統合することで、いますぐ手を付けなければいけないことをリマインドさせたり、Notionへ移すべきタスクを提案させたりするのである。
VS Code上で秘書のような対話が始まる。「直近のタスクが5本ありますが、明日は授業で対応できなさそうです。いつ処理しますか？」。こうして作成された日々のタスクレビューのログによって、毎日どのくらいのタスクがあり、どれを消化したかの記録が、自動的に蓄積されていくのだ。
月末にはObsidianの記録を要約し、月次サマリーとしてNotionに保存する。それとともにObsidianの生ログ（日々の雑記、対話記録）はアーカイブへ移動する。「捨てないけど見えなくする」ことで、必要なら検索できるが、日常の視界からは消える。安心感とノイズ削減の両立である。
フローとストックの本質的な違い
ここで明確になったのは、フローとストックの本質的な違いだった。
フローを担うObsidianは思考環境、いわばThinking OSだ。未確定なことがらや、試行錯誤の記録、草稿、対話ログなどの、「考える・試す・相談する」場所である。その時々の変化に適応しやすい、柔軟な記録として利用する。
ストックとしてのNotionは行動・管理環境、つまりAction OSだ。タスク、進捗、期限、成果物、台帳などの情報で構成された「決める・動かす・追跡する」場所である。確定した情報を管理する、構造化された記録なのだ。
そしてClaude Codeは両者の「橋渡し」役である。フローから「判断」と「意味」を抽出し、次の行動（ストック）に変換する。この分離と橋渡しをスムーズにするClaude Codeへの指示が完成したところで、レギュラーで構造化されたプロジェクトとイレギュラーなタスクや予定を両立させる運用が可能になった。
もうひとつ重要なのは、「捨てる前提」で記録することだ。Obsidianのログの大半は、消えても困らないものの方が多い。放っておくと大量のファイルがエクスプローラに並ぶことになるので、こちらは定期的に「見えない場所」にアーカイブした。
これからのAIとの付き合い方
ここまで来て、Part.1から4までの記事の共通点が見えてくる。
Part.1では、マクロな革命論を疑い、答えは個別の課題の中にあるという考えから、ミクロな実用ケースを探した。Part.2では、「答えは自分の中にある」として、壁打ちで自分の思考を深めるメソッドを紹介した。Part.3では、構造（仕様）を定めてエージェントAIで論文執筆を自動化した経緯を振り返った。そして今回のPart.4では、フローをストックに変換することで、思考を資源化し、再利用可能にするというコンセプトを示した。
これらに見られるように、僕にとってAIは「答えを聞く道具」ではなく、「自分の中にある答えを引き出し、思考を資源化する鏡」なのである。答えはいつも自分の中にある。AIはそれを引き出し、記録し、再利用可能にする。それさえ分かっていれば、AIに任せられることはまだまだあるはずなのだ。
もちろん、ここで紹介したフローは「決定版」でも「完成版」でもない。たとえば月次レビューで「今月の前半は超繁忙期でした」といった分析は出てくるものの、それだけではログとしての有用度は低い。1年ほど運用して「昨年もこの時期は繁忙期でした」といった提案ができるところまでログを蓄積すれば大きな資産になるけれど、まだそこまでの運用実績はない。
さらに言えば、AIの技術自体も進化しているし、そもそもAIがどのように事業化できるのかも見通せていない。表面的な変化を追いかけ続けて、まだ実績のない「新機能」に「これですべてが変わりそうだ」と驚いてみせるだけでは、「大騒ぎしたけれど、結局なにも変わらないじゃないか」と早晩飽きられるだろう。
大事なのは、与えられた技術に沿って自分の動き方を変えるのではなく、相対的に安定した自分の中の原理原則をもとに、AIとのうまい付き合い方を模索していくことだ。それは言い換えれば、AIを道具として、自分の生活に対するソリューションを、自分自身で提案していくということなのだと思う。