自分がいなくなった後も引き出せる個人Wikiにする方法｜AIエージェント経由の引き継ぎ設計

もし明日、急に長期離脱することになったら、今のプロジェクトは回るだろうか。個人Wikiは作った。でも、後任がそれを読み切れるとは限らない。

この記事では、読み取り専用のAIエージェントを「引き継ぎの窓口」として立てる設計と、渡してよい情報・渡すべきでない情報の線引きを紹介します。

「Wikiを残す」だけでは引き継がれない

判断基準ログ、失敗と回避策、言い換え辞書。属人化対策として個人Wikiにこうした記録を積み重ねてきたとしても、それだけでは引き継ぎは終わらない。後任には、そのWikiを最初から通読する時間がないことがほとんどだ。

AIエージェントを「引き継ぎの窓口」にする

ここで使えるのが、他人の知識ベースを読み取り専用のサブエージェントに調べさせるという発想だ。姉妹記事で紹介した「他人の知識ベースを壊さず調べる」使い方を、今度は逆向きに使う。

自分のWikiを、自分が去った後に後任が質問できる読み取り専用エージェントとして立てておく。後任は目次を通読する代わりに、「〇〇の設定で気をつけることは」とエージェントに聞けばよい。エージェントがWikiの中から関連ページを探し、答えを組み立てて返す。

たとえば後任が「請求書の締め日について何か注意点はありますか」と聞けば、エージェントはWikiの中から該当ページを探し出し、「先方の締め日は毎月20日、25日提出だと翌月扱いになるので注意」と要約して答える。ページのタイトルや正確な検索キーワードを知らなくても、自然な質問文のまま情報にたどり着けるのが、目次を渡すだけの引き継ぎとの決定的な違いだ。

実装の骨格

技術的な骨格は、これまで紹介してきた仕組みの組み合わせでできている。

• MCP接続：Obsidian Vaultなどの個人Wikiに、AIエージェントがローカルで接続する仕組み
• 読み取り専用の権限設計：EditやWriteのツールを持たせず、後任が誤ってWikiを書き換えられないようにする
• 持ち出し可能なエクスポート形式：Wikiを別のツール・別の環境に渡す必要が出たときのための、標準的なファイル形式

MCP接続そのものの仕組みは姉妹記事に譲るが、引き継ぎ用途で特に重要なのは2点目の権限設計だ。後任に渡すエージェントには、Read・Grep・Globのような閲覧系ツールだけを与え、Wikiの中身を書き換えるツールは持たせない。自分がいなくなった後、後任がエージェント経由で誤ってWikiを壊してしまう事故を、権限の設計そのもので防いでおく。

3点目のエクスポート形式についても触れておく。後任が別のツールやチームのナレッジベースにWikiを統合したい場合、frontmatter付きのMarkdownのような標準的な形式で書き出せるようにしておくと、移行の手間が小さくなる。この形式面の設計は、OKFという標準を扱った記事で詳しく取り上げている。

エージェントに何を渡し、何を渡さないか

Wikiの全ページをそのままエージェントに公開すればいいわけではない。渡す前に、一段階の選別が要る。

• 作業の判断基準・手順・失敗の記録
• 用語の言い換え辞書、よくある質問への回答
• プロジェクトの経緯・意思決定の理由

• 同僚や取引先についての評価・私的な所感
• 個人の連絡先・給与や契約条件など機密性の高い情報
• まだ確定していない検討中の話

後任がいなくても、無駄にはならない

ここまでは後任がいる前提で書いてきたが、フリーランスや一人法人では、明確な後任がいないまま案件が終わることも多い。その場合でも、この設計は無駄にならない。数か月後、同じような案件を新しく受けたとき、質問する相手は「後任」ではなく「過去の自分」になる。読み取り専用エージェントへの問いかけ方は、後任に対しても未来の自分に対しても変わらない。

まとめ

個人Wikiに記録を積み重ねるだけでは、引き継ぎは半分しか終わっていない。読み取り専用のAIエージェントを窓口として立てておけば、後任は目次を通読する代わりに、必要なときに質問して答えを引き出せる。渡してよい情報と渡すべきでない情報を、書く段階からフォルダ・タグで分けておくことが、いざというときの負担を大きく減らす。

このあたりの設計を自分だけで組み立てるのが難しい場合は、個人・数名規模のチーム向けに生成AI活用・ナレッジ構築のコンサルティングも行っている。

関連記事