目次
相談するIT/ウェブ業界、とくにAI活用の文脈だと「AI-readyなドキュメント管理をどうするか」は、いままさに毎日アップデートされているテーマだと思います。
個人ならObsidianや個人用のメモ基盤、チームならNotion（＋Notion AI）など、選択肢はどれも魅力的で、議論も活発です。
そのうえでこの記事は、少人数でフルコミットの人が少ない組織でも回しやすい形として、Kumonoで試している「Kibela＋Google Docs＋自動同期」というやり方の事例メモです。
この記事は誰向けか
- 少人数チーム（1〜10人くらい）で、ドキュメント運用が「属人化・迷子化」しがちな人
- AIをすでに活用していて、今後さらにその力を引き出したいと考えている方
- ドキュメントを「ちゃんと残したい」気持ちはあるのに、
- 読まれない
- どこにあるか分からない
- 反応が返らなくて続かない
に心当たりがある人
これを導入すると何が変わるか
- チームにドキュメント文化が根付く
- AIが、組織固有に事情や知見を踏まて、力を最大限発揮されるようになる
- メンバーは各々得意なことに取り組む時間が増える
ドキュメント運用がつらいわけ
ドキュメント管理って、時の試練を経てこんな感じになったことありませんか？
- そもそもみんなあまり書かない
- せっかく書いても必要な人に見られない
- 探せない、必要なものがあるのかわからない
- メンテされず、古いドキュメントを信頼できない
- 車輪の再発明が起きる
最近はさらにもう1つ、別の難しさが出てきました。AIと一緒に仕事をするのが当たり前になってきたからです。
文章の整形、要約、観点出し、調査。AIをうまく使えるほど、ドキュメントは「人が読む」だけじゃなくて「AIが参照する」ことも前提になってきます。
そんな前提の中で、当社ではいま、ナレッジの置き方をこう分けています。
- Kibela：人に読まれて、反応が返ってくる"書く場所"
- Google Drive / Google Docs：AIが参照しやすい"原本の置き場"
- そしてこの2つを 自動同期 でつなぐ
今回の記事ではその理由と、運用の考え方を書きます。
<対人間>Kibelaがドキュメント文化をはぐくむ理由（完全に私見）
Kibelaって、記事が読まれて「いいね」が押されると右上の通知欄が赤くなります。
私、あれが本当に好きです。
誰にも読まれないんじゃないかっていう暗闇に、ぽっと赤く太陽が照らしてくれるような、救われたような気持ちになるからです。
私だけではないはずです。
- 読まれたことが目に見える
- 小さくても反応が返ってくる
- 「書いてよかった」が積み上がる
ドキュメントって、書くことより「書いてちゃんと届いているという実感」がないと書く意欲湧かないですよね。反応が返ってくるだけで、心理的安全性が上がる。次も書こうと思える。
さらにKibelaにはタイムラインがあって、読む導線がある。Google Docsより「ブログとして読める」。フォルダ探さないとマニュアルが、読めない、ではなくてフローな情報が流れてくるのはドキュメント文化を育むインターフェースとして欠かせないなと思っています。
なのでKumonoにとってKibelaは、硬い意味での"社内Wiki"/マニュアル保管庫というより
- ゆるい〜硬いまでオールOKなタイムライン
- 知見や議論がを雑に置いておける場（&最低限人に見せられるクオリティまでもっていきやすい）
- 将来の社外発信のネタが育つ場
という位置づけです。
Kibelaは「フロー」と「ストック」の両方に強い
もう一つ、Kibelaの良さがあります。
タイムラインとして流れる"フロー"の情報がある一方で、フォルダ（グループ）や構造に沿って"ストック"として整理して残していけることです。
つまり
- 流れて終わるだけでもない
- 重たいWikiだけでもない
フローとストックを同居させながら、見える化できるバランスが、ざっくりですがKibelaのいいところだと思っています。
でも、原本の置き場をKibelaに全部寄せたいわけではない
一方で、当社では「ドキュメントの原本の置き場」をKibelaだけに寄せていません。
その理由も説明します。
1)理由① AIの世界は、相棒が変わる前提
AIは進化が速いです。いま強いAIが、半年後も強いとは限らない。
使いたいAIも、プロジェクトも、トレンドも変わる前提。だから「このツールの中で全部完結」みたいに寄せすぎると、あとで身動きが取りづらくなるのが怖いです。
Kibela自体もAI機能があって、今後もっと強化されていくはずです。なので「Kibelaの中でAI検索まで全部完結する」という方向性も多くの組織にとっては全然あり得ると思います。
ただKumonoとしては、"どのAIを使うか"を固定したくない/そこでエッジを立たせたい気持ちが強い。そのため今は、Kibelaを中心にしつつも、参照元を外に持っておいて、必要に応じて好きなAIと繋ぎ替えやすい形にしています。
2) 理由② NotebookLMやChatGPTと連携しやすい場所に、原本を置きたい
NotebookLMもChatGPTも、Google Drive上のDocsを参照させる取り回しが良い。
NotebookLMはいま「参照元のDocsの最新版を動的に更新する」まではできないけど、時間の問題でアップデートされるような気もするので、（近未来的には）常に最新の参照基盤を保ったNotebookLMを社内で使えるようになる可能性が結構たかいと思っています。
Google Driveを唯一の社内ドキュメント基盤にしない理由
そろそろ、
「それなら最初からGoogle Drive/docsを社内ドキュメント基盤にすればいいじゃん」
という声が聞こえてきそうです。
Googleに全Betすれば将来的になんとかなる説も常にありつつ、現時点で明確に欠点や限界があります。
それは、Google driveとDocs管理だと、ドキュメントを人間が「後から見るUI」として微妙ということです。
- 誰かが書いたドキュメントをみない
- どこにあったっけが起きる
- タイムラインがない
- サイロ化しやすい
ここを「Driveで解決しよう」とすると負ける。だから当社では、Driveに"見るUI"を期待しないことにしました。
Drive/Docsは、あくまで
- AIが参照しやすい
- 必要なときに引ける
- 権限管理がしやすい
この3点に価値を絞る。
人間が読む・反応する・議論する導線はKibelaで担保する。この割り切りがいちばんうまくハマりました。
じゃあ、二重管理はどう避けるのか
KibelaとGoogle Docsを併用すると、すぐ出てくる問題が「二重管理」です。
両方に同じ内容を書き始めると、どっちが正か分からなくなるし、更新も面倒になる。
なのでKumonoではこうしました。
- Kibelaに投稿された投稿を
- APIで取り出して
- Google Docsを自動生成・更新して
- Drive側にフォルダ構造ごと保存する
自分で二重に書かない。同期スクリプトに複製させる。
これで
- Kibelaで書くと気持ちいい（&いいねもらえて嬉しい/読みやすい）
- Google側には最新の参照元が勝手にできる
- NotebookLMやChatGPTにはGoogle Docs側を参照させる
というやりたいことを妥協せずにやれてハッピー、ということです。
比較表：Kibela / Google Drive（Docs） / Notion
代案として、Notionも有力候補でしたが今のKumonoのフェーズだと「全部Notionでやる」はオーバースペックになりそうでした。
- 参照や文章生成をNotion内で完結させようとすると、便利になるほどNotion側に委ねる必要がある
- Notion AIはそれなりに高く、ヘビーユースできるなら良いが、使いこなさないまま終わる可能性もある
- 使いたいAIは自分たちで選びたい
- Notion、ページの階層が深くなりがちで運用ルールを整備しないと、AIへの参照が難しい時がある
当社では「軽く動けることと自由」を優先したかったので、いったん採用しない判断にしました。
観点 | Kibela | Google Drive（Docs） | Notion |
|---|---|---|---|
得意領域 | 人に読ませる・議論する・文化を育てる | AI参照・保管・権限で切り分け | DB＋ドキュメント＋タスクまで全部入り |
"書く気になる" | いいね・コメント・タイムラインで「届いた感」が返る | 反応が返りにくい。サイロ化しがち | 強いが運用が重くなると"整備"が勝ちがち |
読むUI | ブログ的に読みやすい | 読む導線が弱い | まとまると強いが深い階層やトグルで読みにくくなりがち |
AIとの相性 | 直接完結もできる（今後強化も） | NotebookLM/ChatGPTで参照しやすい | 内部は強いが、前提がNotionに寄りやすい |
引っ越しのしやすさ | 箱としてはシンプル | かなり良い | 中心に据えると前提が寄りやすい |
権限管理 | フォルダ単位でやりやすい可 | フォルダ単位でやりやすい可 | フォルダ単位でやりやすい可 |
コストの納得感 | 使ってない人の分が割引される仕組みがある | 多くの場合、追加コストより運用設計が中心 | AIを前提にすると便利になるほど依存が深まり、費用も上がりやすい |
今回の結論 | "書く場所"として採用 | "参照元"として採用 | 今は採用しない（重くなる可能性） |
`
（個人運用）社長個人のGtihubリポジトリに入れている
GitHubはリポジトリ単位でしかアクセス制御が切れません。
全ドキュメントを1リポジトリに入れると、業務委託メンバーにも全部見えてしまう。かといって案件ごとにリポジトリを分けると管理面倒です。
自分の意思決定支援用に、個人のprivateリポジトリへ同期しておく分には、権限管理の複雑さが発生しない。
業務委託メンバーには共有しない。あくまで自分用。この割り切り個人運用という感じです。
どんな場面で効くか
- 案件を横断して「あのプロジェクトとこのプロジェクトの共通点は？」と聞きたいとき
- 経営判断のためにナレッジを横串で検索したいとき
- Claude Codeでコードを書きながら、社内ドキュメントを参照したいとき
二層構造にしておく
チーム共有やクライアントワークはGoogle Docs、経営者の個人ワークスペースはGitHub privateリポジトリ。この二層構造にしておけば、クラウドAIにもローカルエージェントにも対応できます。
よくある質問
Q. AI参照をしたいなら、Kibela MCPサーバーを使えばよくない？
A. もちろんアリです。Cursorなどエディタ側で使うなら、MCPの手触りは強いと思います。
ただ、僕がいったん「Kibela → Google Docs へミラー」に寄せたのは、運用面の理由が大きいです。
- 人が増減したときに、各人の環境にMCP環境をつくるのが地味に面倒になりうる
- 端末やツールごとに取り回しが変わると、結局「使われない」側に倒れやすい
- NotebookLM / ChatGPT など、いま自分が主に使いたいAIとの相性は Google Docs のほうが素直
実際のところ、個人単体でドキュメント運用をするならば、CursorやClaude Codeなどローカルにあった方が取り回しが良いので、1箇所に集約してローカルファイルとして明示的に参照するような設計も作っています。
Kibela
├→ Google Docs（チーム共有・クライアントワーク用）
└→ GitHub privateリポジトリ（個人用/ Claude Code用）
もしかしたら、チーム運用においてもローカル重要視を強めるかもしれませんが、エンジニア以外のチームに導入するならどうしてもハードルは高く、本記事で紹介したやり方は落とし所としては引き続きいいんじゃないかと考えています。
Q. Kibelaの中でAI機能が強化されるなら、そこで完結させればよくない？
A. それも十分あり得ます。Kibelaが好きなので、将来的にそちらに寄せる選択肢も残したいです。
ただ、AIの世界は移り変わりが激しく、相棒（使いたいAI）が変わる可能性も高い。なので現時点では、参照元を外に持っておいて、必要に応じて繋ぎ替えられる形にしています。
Q. それって結局、二重管理にならない？
A. 自分で両方に書くと二重管理になります。
そこで僕は、Kibelaに投稿した内容をAPIで取り出して Google Docs を自動生成・更新する、という形にしました。人が二重に更新するのではなく、同期スクリプトに運ばせています。
＜まとめ＞人間にもAIにも気持ちよくドキュメントを管理したい
結局のところ、書くことが続かないとナレッジは増えないので、人間が書くハードルを下げる&「ちょっと書いてみようかなぁ」と思えるUIは前提一番大事だと思っています。Kibelaは、そこを支えてくれることを期待して使っていきたいです。
一方で、自分が使いたいAIに参照させるときの取り回しも無視できない。一旦組織運用する際にはGoogle Docsが強そう、ローカルエージェントまで視野に入れるなら、GitHub同期を足す手もある。
そして何より、未来は変わる前提でいたい。だから参照元を外に持っておいて、引っ越ししやすい形にしておく。
ツールの話というより、「書く人の気持ち」と「変化への耐性」の話という感じでした。
しばらくこの構成で運用してみて、また変化が出たら更新していきます。
現場導入のハードルが高いと感じたら
この記事を読んで「考え方はわかったけど、自社で組むのは大変だよなぁ」と思った方もいるかもしれません。
AIまわりのツール選定ははじまりにすぎず、実際はもっと泥臭く「どう運用に乗せるか」「誰がメンテするか」など。AI-readyなドキュメント基盤は、作って終わりじゃなくて、回し続ける仕組みが要ります。
Kumonoでは、こうした業務へのAI導入を一緒に設計するお手伝いをしています。興味があればお気軽にお問い合わせください。
