Transcript
00:00:00CloudCodeに「第二の脳」を与えるスタックとして、これまで見た中で最高のものかもしれません。
00:00:04誰もがObsidianやGraphifyを使ってCloudCodeの記憶力を向上させようと躍起になっています。
00:00:10ですが、どちらか一方を選ぶのではなく、それらをすべて組み合わせてみたらどうでしょうか？
00:00:15Graphifyを使ってリポジトリ（コードベースであれ、一連の
00:00:20ドキュメントであれ）をナレッジグラフに変換し、それをObsidianに
00:00:26組み込んで、CloudCodeが自由自在にクエリできるようにするのです。
00:00:28さて、今日の動画ではその具体的な方法をお見せします。
00:00:32それでは始めましょう。
00:00:33まず最初に、「なぜ」なのかを説明します。
00:00:35なぜ右側のGraphifyと左側のObsidianを組み合わせる必要があるのでしょうか？
00:00:41その答えは、これら2つのツールを組み合わせることで、CloudCodeが
00:00:46自分たちのボルト（Vault）の文脈の中で、大規模なリポジトリに関する質問に答えやすくなるからです。
00:00:51どういう意味でしょうか？
00:00:53Graphifyの役割を思い出してください。
00:00:56Graphifyを使えば、CloudCodeを任意のリポジトリやコードベースに向けるだけで、
00:01:01ナレッジグラフを作成できます。
00:01:02このナレッジグラフはCloudCodeにとって地図のような役割を果たし、コードベースや
00:01:08ドキュメントの中で何が起きているのか、異なる概念がどう関係しているのか、そして
00:01:12「なぜ」なのかを示します。
00:01:13この地図をCloudCodeに渡すことで、コードベースに関する質問に対して、
00:01:16より迅速かつ効率的に答えられるようになります。
00:01:17しかし、Graphifyにおける唯一の欠点は、それが真空状態で動いていることです。
00:01:22単なるコードベースに過ぎません。
00:01:23単なるドキュメントのセットです。
00:01:24私たちがボルトの中で検討している壮大なプロジェクトとは、全く関連性がないのです。
00:01:29Obsidianのボルトは非常に広範囲に及びますから。
00:01:31Obsidianのボルトはかなり広範囲に及ぶ可能性があります。
00:01:35Graphifyで何らかのリポジトリや一連のドキュメントを調べたとき、それが
00:01:39全体像の中でどう収まるのかを知りたい、というシナリオがあるかもしれません。
00:01:43そこでObsidianの出番です。
00:01:44そこでObsidianの出番です。
00:01:45Graphifyで見つけたすべてをボルトに入れることができます。
00:01:50あるいは、Obsidian自体が好きで、Graphifyの構成全体を
00:01:56独立したObsidianボルトにしたい場合も、それが可能です。
00:02:00Obsidianに持ち込む理由は2つあります。
00:02:02一つは「Graphifyでこれらを理解したから、
00:02:05より大きなプロジェクトの文脈の一部にしたい」という場合。
00:02:08これなら、ほとんど直接入れることができます。
00:02:10もう一つは、単にObsidian関連のものがすべて大好きで、
00:02:13Obsidianのインフラ内にいたい、という場合です。
00:02:14アドオンが使いたい。
00:02:15UIも好き、といった具合です。
00:02:17それも簡単な話です。
00:02:18それが、なぜこの手法が重要なのかという理由です。
00:02:19さて、具体的な方法に入る前に、本日のスポンサーである私から一言。
00:02:24先日「Cloud Codeマスタークラス」をリリースしました。これは、
00:02:28技術的な背景がなくても、AI開発者になれる一番の近道です。
00:02:31毎週更新しており、Obsidianに関するコンテンツも盛りだくさんです。
00:02:36自分専用の「Cloud OSコマンドセンター」を構築する方法なども含めて、
00:02:39今日触れるかもしれません。
00:02:41興味があれば、固定コメントのリンクから詳細をご覧ください。
00:02:44Chase AI+の中で見つけられます。
00:02:46では、GraphifyとObsidianのスタックを動かすには、当然GraphifyとObsidianが必要です。
00:02:52この動画は、両方のツールを一から使い方を教えるチュートリアルではありません。
00:02:56それについては既にカバーしたコンテンツがあり、
00:02:56上にリンクを貼っておきます。初めての場合は私のプロフィールをチェックしてください。
00:03:00初めての方は私のプロフィールを覗いてみてください。
00:03:04まず必要なのはGraphifyです。
00:03:07何らかのドキュメント、あるいは最終的にObsidianに取り込みたいコードベースが必要です。
00:03:12繰り返しますが、選択肢は2つです。
00:03:13繰り返しますが、選択肢は2つです。
00:03:15一つは本格的なコードベース、もう一つはコード以外のもの、
00:03:20つまりドキュメント、PDF、画像、動画、その他何らかの情報源、
00:03:28Graphifyが読み込み、意味とつながりを抽出して
00:03:32ボルトへと変えてくれるようなディレクトリです。
00:03:34今日はこれを行います。
00:03:35非コードベースのボルト構築シナリオを見ていきましょう。
00:03:40デモではCloud Codeのドキュメントを取り込みます。
00:03:43まずCloud Codeのドキュメントをダウンロードします。
00:03:45そしてGraphifyをそれらドキュメントに向けます。
00:03:48ナレッジグラフが作成されたら、それをObsidianにプッシュします。
00:03:52これがデモの内容です。
00:03:53Graphifyの素晴らしい点は、これが既に組み込まれていることです。
00:03:57Obsidian側で特別な準備をする必要はありません。
00:04:00一つか二つだけやるべきことがあります。それをお見せします。
00:04:02ほとんどの処理はGraphifyのコマンド経由で行われます。なぜなら、
00:04:08「発見したものすべてをボルトとして作成せよ」というGraphifyフラグが存在するからです。
00:04:14こちらをご覧ください。
00:04:16「graphify --obsidian」コマンドがObsidianボルトを生成します。
00:04:19Graphifyをインストール済みであれば、そのGraphifyスキルが含まれているので、
00:04:23実行は非常に簡単です。
00:04:24自然言語を使うだけです。
00:04:25Cloud Codeに入って、「公式Cloud Codeドキュメントをダウンロードして、
00:04:30Graphifyを向けて、Obsidianコマンドを使ってボルト化して」と言うだけです。
00:04:36たったそれだけです。
00:04:37実際にどのような結果になるか見てみましょう。
00:04:39ドキュメントのフェッチが完了しました。
00:04:41計171ページありました。
00:04:44すべてスタンドアロンフォルダーにダウンロードし、Graphifyのナレッジグラフシーケンスを
00:04:50実行し始めました。
00:04:51ドキュメントから作成されたナレッジグラフはこれですが、
00:04:55ノードがどのように作成されたか詳しく見ていきましょう。
00:04:58一体どこからこれらのノードが来ているのでしょうか？
00:04:59ノード一つ一つがダウンロードしたページに対応しているのでしょうか？
00:05:02必ずしもそうではありません。
00:05:03Graphifyが公式Cloud Codeドキュメントから取得したドキュメントの数は、
00:05:09145件です。
00:05:11すべてのドキュメントがノードに対応しているわけではありません。
00:05:14Graphifyはそれらすべてのドキュメントを調べ、
00:05:20ドキュメントから概念を抽出するのです。
00:05:20実際、591個のノードと685個のつながりが生成されました。
00:05:26繰り返しますが、ノードの一つひとつがドキュメントではありません。
00:05:31ダウンロードされたWebページでもありません。
00:05:32ページから抽出された「概念」であり、それらを接続しているのです。
00:05:35こちらで見ることができます。
00:05:36例えば「context window（コンテキストウィンドウ）」を見ると、何につながっているでしょうか？
00:05:39path scoped rules、sub-agent separate context window、post tool use hook、
00:05:45extended 1 million token context などが見えますね。
00:05:49つまり「context window」が大きなノードであり、関連する概念が見えます。
00:05:54145件のドキュメント、591個の概念、685個の接続、67個のコミュニティです。
00:06:00コミュニティとは何でしょうか？
00:06:01コミュニティは単なる概念のグループ化です。
00:06:04「context」のようなものは、おそらくコミュニティでしょう。
00:06:07こちらで確認できます。
00:06:08checkpointing、cloud and web、LLM gateway skillsなどですね。
00:06:12前回のGraphify動画を覚えているなら、これこそがGraphifyの真骨頂です。
00:06:16情報から概念を抽出し、マッピングする手法。
00:06:19このナレッジグラフ、つまり「地図」を渡せば、Cloud Codeは
00:06:22ドキュメントに関する質問に非常に簡単に答えられるようになるからです。
00:06:27もし「sub-agents（サブエージェント）」について質問すれば、
00:06:31何がサブエージェントに関連しているかを見抜くのは簡単です。
00:06:32agent teamsなどがそうですね。
00:06:34ただ文字列を検索（grep）しているわけではないからです。
00:06:35Ctrl+Fをしているわけでもありません。
00:06:37地図を持っているのです。
00:06:37接続関係を把握しています。
00:06:38その「理由」も理解しています。
00:06:40しかし現時点では、Graphify上では優れていても、これは真空状態です。
00:06:44自分のObsidianボルトとは何の関係もありません。
00:06:47私のObsidianボルトにはCloud Codeに関するものがたくさんあります。
00:06:50Cloud Codeプロジェクト、Cloud Codeコンテンツなど、Cloud Codeに関わる資産が
00:06:54たくさんあり、ドキュメントの情報は貴重な資産になるはずです。
00:06:57では、どうやってそれらを自分のObsidianの中にある
00:07:02ナレッジグラフに取り込むのでしょうか？
00:07:03ただ、Obsidianで扱う場合、これは厳密にはナレッジグラフと同じではありません。
00:07:09ただの接続されたMarkdownファイルの集まりです。
00:07:10ただの接続されたMarkdownファイルの集まりです。
00:07:12GraphifyのナレッジグラフからObsidianへの移行は、先述の通り
00:07:16Graphifyが自動で行ってくれるため簡単です。
00:07:19Obsidianフラグを呼び出すと、Graphifyはすべてのノードに対し、
00:07:26例えば「sub-agent」なら、そのためのMarkdownファイルを作成します。
00:07:31そして、Obsidian内で接続関係を持たせるための
00:07:35自動バックリンクを作成し、つながりを持たせます。
00:07:41つまり591個のMarkdownファイルを作成し、それぞれに適切なリンクを685個張り、
00:07:50それを瞬時にObsidianに挿入するのです。
00:07:54かなりの量ですね。
00:07:55これだけのMarkdownファイルが、現在のObsidianボルトや構造の中に
00:08:01そのまま注入されることになります。
00:08:03貴重な情報が含まれているので良いことでもありますが、一方で、
00:08:06意図しない形で注入される可能性もあります。
00:08:06600件のドキュメントをむやみに放り込むのは、理想的ではないかもしれません。
00:08:12少し多すぎる可能性があるのです。
00:08:14では、どう対処すべきでしょうか？
00:08:16注入される新しいデータすべてに、どのような選択肢があるのでしょうか？
00:08:21私のように「Cloud OS Obsidianコマンドセンター」を作り上げた人間にとって、
00:08:26システムにものを放り込むのは警戒すべきことです。
00:08:29何が入り、何が出るのかを把握したいものです。
00:08:31単にカッコいいObsidianのナレッジグラフを作ることが目的ではありません。
00:08:35一貫したシステムの一部なのです。
00:08:38Markdownファイルの洪水に対しては、4つの選択肢があります。
00:08:42ボルトへの溢れを防ぐ、またはうまく制御するための4つの選択肢です。
00:08:45一つ目は、単にObsidianエコシステムに情報を取り込みたいだけで、
00:08:50メインのボルトにある必要はないという場合、
00:08:54情報すべてに対して独立したボルトを作成することです。
00:08:59ナレッジグラフを持ったまま、それを独自のボルトにするという方法です。
00:09:04依然として真空状態ですが、Obsidianの中での真空です。
00:09:07それだけで十分な人もいます。
00:09:08それが望み通りの人もいます。
00:09:09実際、これはGraphifyのデフォルトの挙動でもあります。
00:09:12Obsidianボルトを作成するよう求めると、
00:09:15最初から専用ディレクトリに配置されます。
00:09:16隔離するようなものです。
00:09:17二つ目は「隔離用ダンプ」を作る方法です。
00:09:21どういう意味でしょうか？
00:09:21私のObsidianをご覧ください。
00:09:24左側に多くのフォルダーがあります。
00:09:26この新しいCloud Codeドキュメントの一連のMarkdownファイルを
00:09:32600件すべて、専用のサブフォルダーに入れて
00:09:38「Cloud Code Documentation」と名付けるのです。
00:09:40もし全体像に合わないと感じたら、そのサブフォルダーを削除するだけで
00:09:45すべて解決します。
00:09:46文脈には取り込むけれど、簡単に元に戻せるという方法です。
00:09:50取り込みつつ、逃げ道を作っておくのです。
00:09:53三つ目は、必要な情報だけを「収穫」する方法です。
00:09:57Graphifyが作成したMarkdownファイルの専用ディレクトリをCloud Codeに確認させ、
00:10:03「これは取り込む、これは無視する」といった選別をさせるのです。
00:10:07600件すべてが必要なわけではありませんから。
00:10:11600件すべてが必要なわけではありません。
00:10:13例えば、サブエージェントに関連する100件だけでいいかもしれません。
00:10:17ピース単位で選んでいくのです。
00:10:18四つ目は最も複雑な「再配布」です。
00:10:22ケースバイケースになります。
00:10:24Cloud Codeドキュメントを特定のサブフォルダーに入れて
00:10:29気に入らなければ削除できるという話でしたね。
00:10:32ここでもう一度、Cloud Codeを使って、
00:10:36Graphifyが作成したMarkdownファイルすべてを、適切な別のサブフォルダーへ
00:10:42再配置させることもできます。
00:10:43こうすれば、大きなボルト構造の中で一貫性を保てます。
00:10:47ただし、元に戻すのがより難しいという点は理解しておいてください。
00:10:50選択肢はあるということです。
00:10:51Graphifyの知識グラフを、Obsidianでどう運用するかについては、
00:10:57すべてが二者択一というわけではありません。
00:10:59私の提案であり、今日お見せするのは、まず専用の個別のボルトを作成する方法です。
00:11:03これは自動的に作成されるので、非常に簡単です。
00:11:07そして、それを独自のサブフォルダーとして取り込むだけです。
00:11:10そうすれば必要に応じて簡単に削除できます。
00:11:12何が構築されたか見てみましょう。
00:11:13Graphifyのデータがありますが、これまでgraph.htmlとgraph.jsonを見てきましたね。
00:11:18しかし、ここにあるのが作成されたスタンドアロンのボルトです。
00:11:23私のChaseフォルダーのvaults配下に、cc-docsという独立したObsidianボルトがあります。
00:11:28ボルトですね。
00:11:29さて、Obsidianにこれを認識させる必要があります。
00:11:31独立したボルトを作成した後でも、Obsidianを開いて
00:11:35このディレクトリを指定しなければなりません。
00:11:38Obsidianを開き、左下の「ボルトの管理」を選択し、
00:11:41「フォルダをボルトとして開く」をクリックします。
00:11:45ファイルディレクトリを指定するだけです。
00:11:48私の場合、vaultsフォルダーの中のcc-docsです。
00:11:51作成されたフォルダーを選択して開きます。
00:11:54これで、ナレッジグラフに基づいたObsidianボルトが完成しました。
00:11:58まだ終わりではありません。ナレッジグラフを取り込めたのは良いのですが、
00:12:02すべてのノードをMarkdownファイルに変換することはできても、
00:12:07問題は、これらのMarkdownファイルがご覧の通り非常に簡素だということです。
00:12:12本当に基本的な内容です。
00:12:15「エージェントの脅威モデル」や「プロンプトインジェクション」といった概念のタイトルと、
00:12:20実際の接続先があるだけです。
00:12:22どこにあるのか？
00:12:23グラフのエッジは何なのか？
00:12:24これだけではあまり役に立ちません。
00:12:27例えばCloud Codeにエージェントのコマンドについて調べさせても、
00:12:31これだけの内容しか出てこないわけです。
00:12:33そこで、これらが基づいている元となるソースドキュメントを取り込む必要があります。
00:12:37すべてはそのソースに基づいています。
00:12:39そうすることで、Cloud Codeにこの知識グラフのマップを渡したときに、
00:12:42Obsidianビュー上で、単にランダムなノードを読み込むだけではなくなります。
00:12:45例えば「データ保持」といったノードを読み込む際、
00:12:49Obsidian内で行うのと同じように、
00:12:51それを適切なソースドキュメントにリンクさせます。
00:12:55もし私が「オートモードについて話して」と言えば、
00:12:59単にこのMarkdownファイルに導かれるだけではありません。
00:13:02このMarkdownファイルを確認し、
00:13:03それに関連するすべてを理解します。
00:13:05そして、情報を抽出できるソースドキュメントを参照します。
00:13:08これは、Cloud Codeを正しい情報源へと導く道標のようなものです。
00:13:12正しい情報へと誘導します。
00:13:13そこで私が与えたコマンドは、ソースドキュメントを引っ張り出し、
00:13:15すべてのノードをccdocsフォルダー内の原点と結びつけるというものです。
00:13:19こうして、どのMarkdownファイルをクリックしても、
00:13:22ソースドキュメントへのリンクが明確になります。
00:13:25これらをクリックすれば、Obsidian内に取り込まれたオリジナルのドキュメントへと飛べます。
00:13:28すべてObsidianの中にあります。
00:13:30例えば「バンドルされたスキル」についてCloud Codeに質問すれば、
00:13:33スキルドキュメントにリンクされた該当のドキュメントを参照してくれます。
00:13:38これが、マップをアプリとして機能させる方法です。
00:13:41ナレッジグラフを、Obsidian内で機能する
00:13:44Markdownのミラーへと変換する手法です。
00:13:49スタンドアロンのObsidianボルト内にこれが作成できたら、
00:13:53次のステップは、このボルトをメインの大きなボルトへ移動させることです。
00:13:58メインボルトが何であれ。
00:13:59先ほど言ったように、選択肢は4つあります。
00:14:01少しずつ移動してもいいですし、
00:14:02好きなようにすればいいです。
00:14:03この動画では、いかに簡単かをお見せします。
00:14:04ただ移動させるだけです。
00:14:06私は今、このccdocsボルトの構造を、
00:14:08メインボルト内のサブフォルダーへ移動させました。
00:14:111分もかかりませんでした。
00:14:13メインボルトの中には、graph importsというサブフォルダーがあり、
00:14:17その下にccdocsフォルダーがあります。
00:14:20658個の概念スタブがあります。
00:14:22これらはGraphifyからのナレッジグラフ上のノードに
00:14:25関連するMarkdownファイルです。
00:14:27そして、これらはすべて146個のフルソースドキュメントのいずれかにリンクしています。
00:14:33メインボルトに入って、graph imports、ccdocsを確認すると、
00:14:39すべてここに表示されています。
00:14:41例えば「work tree flag」をクリックすると、
00:14:44完全なドキュメントがここに表示されます。
00:14:48Obsidianのグラフ構造がすでに変化しているのがわかります。
00:14:52右側にすべてが表示されています。
00:14:54これが、取り込んだすべてのCloud Codeドキュメントです。
00:14:58私たちが普段行っているCloud作業の全体的なコンテキストの中に、
00:15:04どのように挿入されたかの視覚的表現です。
00:15:06冒頭で話した通り、これが「売り」です。
00:15:08すべてのCloud Codeドキュメントが使えるようになったということです。
00:15:12必要な場所に挿入して、自分にとって意味のある形で使ってください。
00:15:15以前は孤立したエリアに過ぎなかったものが、Obsidianボルトのエコシステムに組み込まれました。
00:15:24そうですよね？
00:15:25究極的な価値は、あなたのユースケース次第です。
00:15:29ユースケースは山ほどありますから。
00:15:31単に分離しておくこともできます。
00:15:32特にコードベースなどの場合は、Graphifyで止めておくのも理にかなっていると思います。
00:15:36Graphifyだけでいい場合もあるでしょう。
00:15:37しかし、Obsidianが大好きで、Cloud Codeを連携させて、
00:15:42コマンドセンターのようなものを構築したい人はたくさんいるはずです。
00:15:45今日お見せしたこのオプションは、あなたの道具箱にある一つのツールに過ぎません。
00:15:49万能ではありません。
00:15:49いつ使うべきかを知っておく必要があります。
00:15:51そして幸いなことに、
00:15:52今日お見せしたような実行方法であれば、それほど難しくはないはずです。
00:15:58こういったことは難しくありません。
00:16:00それでは、この動画はここで終わりにします。
00:16:02Graphify内で生成されたものを、
00:16:07今日やったような非構造化ドキュメントであれコードベースであれ、
00:16:11孤立したプロセス、あるいはより大きなコンテキストの一部として
00:16:16Obsidianに取り込む方法でした。
00:16:17ObsidianとGraphifyはどちらも素晴らしいツールです。
00:16:20これらを組み合わせることで、さらに多くの可能性が広がります。
00:16:24色々なことを試してみてください。
00:16:25いつものように、感想を聞かせてください。
00:16:28「Chase AI+」もチェックしてください。
00:16:30Cloud Codeマスタークラスに興味がある方は、概要欄のリンクからどうぞ。
00:16:34それでは、またお会いしましょう。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video