実践ワークフロー– category –

Obsidian 1.9でコア機能になったBasesは、データストアを新設せずMarkdownのプロパティだけでNotion的なDB運用を実現する。実際に618本のノートに.baseファイルを組んで分かった、Dataviewとの使い分けと落とし穴を書く。

MCPやエージェント経由でAIにObsidian vaultの書き込み権限を渡すと、読み取り連携にはなかった事故が起きる。実際にvaultが壊れた記録をもとに、Gitによる可逆化・差分承認・書き込み領域の分離という3層の防衛と、それでも防げない並行書き込みの問題を整理する。

Obsidianが標準Markdownを拡張した独自記法（wikilink・コールアウト・埋め込み・プロパティ）の書き方を、実際に生成AIとノートを共同編集した経験を交えて解説します。

ソレイユ総研の13回にわたる講義資料シリーズを、複数の生成AIと複数の作業者で作れるように支援したプロジェクトの全体像をまとめる。情報格差の解消からDB設計、技術的な落とし穴、チーム構成への配慮、Geminiからの方針転換まで、5本のスポーク記事で扱った内容を1つの物語として結び、顧客の感想も交えて振り返る。Notion wiki納入クラスタのハブ記事。

顧客の要望どおりGeminiを前提に設計したナレッジシステムは、チャットからNotionへ接続できないという壁にぶつかった。顧客がGeminiに求めていた本当の理由をたどり直し、Notion wikiへの方針転換をどう提案し、何が最終的な決め手になったかを解説する。Notion wiki納入クラスタの提案編。

生成AI活用の設計は「全員が上級者になる」ことを前提にしがちだが、実際のチームには技術者ではないメンバーもいる。13回にわたる講義資料シリーズの支援で、講師が普段どおりGoogle Driveで資料を編集し続けられるようにしたまま、構造化されたシステム側に取り込む設計をどう組んだか、その判断の理由を解説する。Notion wiki納入クラスタの続編。

複数の生成AIから読み書きするナレッジデータベースを設計し運用する中で実際にぶつかった5つの課題と、その対策を「課題→対策」形式で紹介する。蒸留2段階による情報損失、Driveを読めないAIによる検証不能、用語の訳語ブレ、候補管理と採用後詳細の衝突、恒久資産と案件都合の混在という、Notion DB設計の一般論では扱われない「LLMに読み書きさせる」用途特有の落とし穴を扱う。Notion wiki納入クラスタの続編。

複数の生成AIから情報を書き込めるようにしただけのNotionは、そのうち使われなくなる。13回にわたる講義資料シリーズの支援で実際に設計した3段階のデータベース構造と、検索せずに情報へたどり着けるHomeビューの工夫、顧客の細かい指摘にどう応えたかを解説する。Notion wiki納入クラスタ・設計編。

ChatGPTとClaudeを併用しながら複数人で13回にわたる講義資料シリーズを作った実務プロジェクトで直面した「LLM間の情報格差」という問題と、情報格納のハブにNotionを選んだ理由を、実際の判断基準とともに解説する。Notion wiki納入クラスタの課題編。

Wiki化によって、可視化の相談からWikiへの保存、過去の成果物の検索までを生成AIと一緒に回せるようになった。何を人間が確認し、何をAI任せにするかの線引きを含め、実際の運用場面を紹介する。「Wiki化で研究がどう変わったか」連載第2回。