普段のChatからKnowledge OSへ――Skillsを作って、実際につないで分かったこと
普段のChatからKnowledge候補をMarkdownで保存し、PC側のKnowledge Managerによる正式登録まで試しました。Skills、プラグイン、Google Drive接続の役割と、実際に起きた保存形式や保存先の取り違えを記録します。
9月24日に、AIとの会話をKnowledge OSへつなぐためにSkillsを使えないかという記事を書きました。
Creerでは、AIとの壁打ちから生まれた判断や経験をMarkdownに整理し、Knowledge OSへ残しています。増えてきたKnowledgeを管理するため、採番、フォルダ移動、Index更新などを行うPython製のKnowledge Managerも作りました。
ただ、普段の会話から「これは残そう」と判断し、Knowledge Managerへ渡すところには、まだ人の手が入ります。
そこで考えたのが、会話中に、
今の話、Knowledgeに回して。
と伝える方法でした。Skillsが会話から残すべき内容を拾い、Knowledge候補を作る。前の記事を書いた時点では、そこまでが構想でした。
今回は、それを実際につないでみた記録です。試しているうちに、Skillsやプラグインだけでなく、Chat、Work、Codexの「作業する場所」の違いも考えることになりました。
最初に考えたのは、PC側へ渡す方法だった
当初のKnowledge OSとKnowledge ManagerはPC側にあります。
PC上で作業できる環境を使えば、そこにあるファイルを扱う道はあります。Creerでも、デスクトップ版のChatGPT Workから、権限のあるPCを経由して社内NASへ届くかを試したことがあります。
だから、今回の問題は単純に「AIからPCのファイルへは絶対に届かない」という話ではありません。
考え直す必要があったのは、私は普段どこでAIと話しているのかという点でした。
私が日常的に壁打ちするのは、ChatGPTのChatです。Project内で話すこともあれば、通常のチャットで話すこともあります。考えがまとまったところで「今の話をKnowledgeに回して」と言いたい。
そのたびにローカルのWorkやCodexへ作業を切り替え、会話の内容や登録対象を渡し直すのであれば、残すまでの手間はまだ残ります。
作りたかったのは「PC上のKnowledge ManagerをAIで操作する方法」だけではありません。普段のChatで生まれた話を、その場所から会社のKnowledgeへつなぐ入口でした。
同じChatGPTでも、見えている場所は同じではない
ここで、Chat、Work、Codexの違いを、ようやく実感しました。
Chatは、考えを話し、整理するために日常的に使っています。ファイルを添付したり、許可した外部サービスを利用したりはできますが、普段のChatが私のPCや社内NASを、そのまま自分の保存先として扱うわけではありません。
Workには、クラウド上で動く場合と、デスクトップアプリを通じてPC側で動く場合があります。後者のローカルWorkなら、権限や設定が許す範囲で、PCのファイルやPCから届く場所を扱えます。一方、クラウド上のWorkは、PCや社内LANへのアクセスを自動では引き継ぎません。
Codexにもローカルとクラウドの実行環境があります。
つまり「WorkだからPCへ届く」「Codexだから届く」と、名前だけでは決まりません。どこで処理が動き、どの道具を使え、その道具にどんな権限があるかで、できることが変わります。
これはOpenAIのWorkの実行環境に関する説明や、Codexの実行環境に関する説明とも一致します。
私はこれまで、同じChatGPTの画面で話していると、作業できる場所まで同じように感じていました。しかし、会話の記録が見えることと、その会話からPC上のファイルを直接操作できることは別でした。
クラウドの記事で気付いたことが、ここにもつながった
9月26日の「バックアップのために置いたクラウドが、AIと仕事をする基盤にもなっていた」では、AIの作業場所が変わると、届く情報も変わると書きました。
PC側で動く作業なら、条件が合えばローカルファイルや社内NASへ届く。一方、ブラウザーやスマートフォンから、同じ経路で社内NASへ届くとは限りません。
Knowledge OSの入口にも、同じことが言えました。
PC側のKnowledge Managerまで、すべてクラウドへ移す必要はありません。ただ、普段のChatから会話カードの候補を受け取る場所は、Chatが許可された接続を通じて届くところに必要です。
そこで、Creerで使っているGoogleの共有ドライブ上にKnowledge OSの作業入口を設け、受け箱へ候補を保存する構成にしました。
これは「Knowledge OSには必ずGoogle Driveが必要」という意味ではありません。Creerではすでに共有ドライブを使っており、Chatから利用できる接続もあった。その既存の環境が、会話とPC側の仕組みをつなぐ場所になりました。
9月24日に考えた「Skillsで会話を拾う」という話と、9月26日に書いた「クラウドがAIの作業基盤にもなる」という話が、ここで具体的につながりました。
Skills、MCP、プラグインは何が違うのか
この作業を始めた頃、私も三つの言葉の関係をはっきり説明できていませんでした。
今回の作業に当てはめると、こう整理できます。
Skillsは、仕事の進め方です。
「会話のどこを残すか」「一つの話を複数のカードに分けるか」「何を確認してから完了と報告するか」といった手順をAIへ伝えます。ただ、Skillsを書いただけで、保存先への接続や書き込み権限が生まれるわけではありません。
MCPは、AIと外部の道具やデータをつなぐための共通の規格です。
MCPそのものが「ファイルを保存する道具」なのではありません。その規格に沿った接続先が、検索や保存といった操作をAIへ提供します。
プラグインは、必要な機能をまとめて使えるようにする単位です。
Skillsだけを含むものもあれば、外部サービスへの接続を含むものもあります。両方を組み合わせることもできます。
今回の「Creer Knowledge」プラグインには、会話を整理するSkillsを入れ、既存のGoogle Drive接続を必須として指定しました。独自のMCPサーバーを新しく作ったわけではありません。
Creerの例で言えば、Skillsが「どう記録するか」を受け持ち、Google Drive接続が「どこへ読み書きするか」を受け持つ。プラグインは、その組み合わせを普段のChatやWorkから選べる入口にしています。
OpenAIのSkillsの説明とプラグインの構成に関する説明を読み直すと、この役割分担が分かります。
最初は「Skillsを作れば、つながる」と思っていました。実際に試してみて、「仕事の手順」と「外部へ届く手段」は別だと理解しました。
保存できたように見えても、実物が違った
接続を試す途中では、うまくいかなかったこともあります。
.md という名前で保存したはずのファイルが、実際にはGoogleドキュメントだったことがありました。名前だけを見るとMarkdownですが、Knowledge Managerへ渡したい実体のあるMarkdownファイルとは違います。
受け箱のフォルダ名だけで場所を探し、想定とは違う場所を見ていたこともあります。同名のフォルダや、ゴミ箱に入ったフォルダがあれば、「受け箱は空だ」という確認自体が間違う可能性があります。
そのため現在は、共有ドライブ内の対象フォルダを特定し、保存後にも次を確認するようにしました。
- 正しいフォルダに入ったか
- 名前だけでなく、実体がMarkdownか
- 保存した本文を読み戻せるか
- 候補の保存なのか、正式登録まで終わったのか
AIが「保存しました」と答えたことと、目的の場所に目的の形式で残っていることは、同じではありませんでした。
「Knowledgeに回して」と「正式登録して」は二段階
今の流れは、まずChatやWorkで、
今の話をKnowledgeに回して。
と伝えるところから始まります。
Skillsが会話を読み、後から使えそうな判断や経験を会話カードの候補に整えます。Google Drive接続を使い、共有ドライブの受け箱へMarkdownとして保存します。
そこから人間が内容を確認し、
正式登録して。
と指示します。Knowledge Manager側が採番し、所定のフォルダへ移し、Indexを更新します。
ここでも、「正式登録を依頼した」と「正式登録が完了した」は別です。登録要求が作られていても、PC側の処理がまだなら処理中として扱います。
今回のテストでは、通常のChatから候補の保存と正式登録を依頼しました。PC側の処理のあとに、会話カードへ正式IDが付き、受け箱から所定の場所へ移り、Indexにも反映されたことを確認できました。
前の記事で書いた「次は、会話の途中から実際につないでみる」は、ようやく一度通して試せたことになります。
古い単体のSkillsも整理した
試行中には、最初に作った単体のSkillsと、Google Drive接続を使う新しいプラグイン内のSkillsが併存する状態にもなりました。
同じつもりで「Creer Knowledge」を使っていても、選ばれた方によって手順や使える道具が違えば、結果が安定しません。
そこで、古い単体のSkillsは現役の選択肢から外し、戻せる形で退避しました。ChatやWorkからの入口は、SkillsとGoogle Drive接続を組み合わせた「Creer Knowledge」プラグインに寄せています。
PC上でKnowledge Managerを直接扱う方法は、別の役割として残しています。
会話カードの登録と、会社の方針への反映は別
今回つながったのは、会話から候補を作り、Knowledge OSの会話カードとして正式登録するまでです。
ただし、会話カードとして登録された内容が、そのままCompany OSの方針や、ほかの確定した知識へ反映されるわけではありません。
会話には、検討途中の案も、後から変わった考えも、試して失敗したこともあります。それらを経緯とともに残し、後から確かめられるようにすることが、会話カードの役割です。
会社の正式な知識や方針へ反映するかどうかは、内容、根拠、現在の状況を確認したうえで、人間が判断します。
AIに会社の判断を任せるためではなく、人間が判断するときに過去の考えを取り出せるようにするための仕組みです。
普段話す場所から残せることに意味があった
振り返ると、ローカルWorkやCodexを使えば、PC側のKnowledge OSへ届く道はありました。
それでも今回は、Googleの共有ドライブを入口に選びました。
理由は、技術的にPCへ届く方法を一つ作りたかったからではありません。普段のChatで考えたことを、その場から残せるようにしたかったからです。
Skillsが会話を読み、残す内容を整える。プラグインが必要な接続を使い、共有ドライブの受け箱へ候補を置く。Knowledge Managerが決めた処理で登録する。そして、人間が候補と結果を確認する。
以前から会社にあった共有クラウドが、ここではChatとPC側の仕組みをつなぐ場所になりました。これは、9月26日の記事で書いた「クラウドの意味が変わって見えた」という話の、具体的な一例です。
まだ運用を始めた段階です。どんな会話を残すか、似たカードをどう扱うか、会社の正式な知識へいつ反映するかは、使いながら整えていく必要があります。スマートフォンを含む、すべての環境で同じ流れを確認したわけでもありません。
それでも、普段のChatからKnowledge候補を作り、共有ドライブへMarkdownとして保存し、正式登録の結果まで確かめられました。
9月24日に考えたSkillsは、それだけで完結する仕組みではありませんでした。しかし、Chat、クラウド、PC側のKnowledge Managerの役割を分けてつないだことで、会話を記録として残し、後から会社の判断に生かすまでの道筋が、以前より具体的に見えるようになりました。