【ITニュース解説】สร้าง Knowledge Base ทีม IT จาก Obsidian สู่ Cloudflare Pages (ครบจบในบทความเดียว)

ITサポートチームは日々多くの問い合わせに対応しているが、過去に解決したはずの問題や繰り返されるケースについて、時間が経つと解決策を忘れてしまうことがよくある。このような状況で、個人の記憶だけに頼らず、チーム全体の知識として蓄積し、必要な時にすぐに参照できる仕組みが求められる。そこで役立つのが「第二の脳（Second Brain）」という考え方だ。これは、繰り返し使う知識や情報を外部に体系的に記録し、あたかも自分の脳の一部のように活用するという概念である。具体的には、Tiago Forteが提唱するCODEフレームワーク（Capture: 知識を素早くメモする、Organize: 構造化して整理する、Distill: 内容を簡潔にまとめる、Express: 知識を実践に活かす）に基づいて、知識を効果的に管理する。

この課題を解決するために、Obsidianというツールが活用される。Obsidianは、Markdown形式で情報を記録できる多機能なノートアプリケーションである。書かれた記事や小さなメモ同士をリンクで関連付け、知識のつながりを視覚的にグラフで表現できる機能を持つ。また、テンプレート機能も備わっており、コンテンツの構造を整えるのに役立つ。これにより、「第二の脳」の概念に基づいた知識の整理を効率的に行える。しかし、Obsidianには一つの大きな制約がある。それは、基本的にローカル環境で動作するアプリケーションであるため、作成したノートをチームメンバーと直接共有することが難しいという点だ。チーム全体で「第二の脳」を構築するには、この共有の壁を乗り越える必要がある。

そこで、Obsidianで作成したナレッジベースをチームで共有するためのシステムが構築される。このシステムでは、まずObsidianで作成したMarkdown形式のファイルをGitリポジトリ、具体的にはGitHubにプッシュする。通常、そのまま公開するのではなく、チームリーダーが内容をレビューするためにプルリクエスト（PR）を開く形式を採用する。リーダーが内容を確認し、承認すると、GitHub Actionsという自動化ツールが作動する。このツールは、Static Site Generator（SSG）と呼ばれる技術を用いて、Obsidianで作成されたMarkdownファイルをHTML、CSS、JavaScriptといった静的なウェブサイトファイルに変換する。変換された静的ファイルは、その後、ウェブホスティングサービス（GitHub PagesやCloudflare Pagesなど）にデプロイされ、ウェブサイトとして公開される。

Static Site Generator（SSG）にはいくつかの利点と制限がある。利点としては、まず非常に高速である点が挙げられる。静的ファイルは事前に生成されているため、ユーザーからのリクエストに対してサーバーで動的にコンテンツを生成する必要がなく、直接ファイルを配信できる。特に、コンテンツデリバリネットワーク（CDN）を通じて配信される場合、世界中のどこからでも高速にアクセス可能となる。また、動的なサーバー処理がないため、攻撃の対象となるサーバー側の脆弱性が少なく、セキュリティが高い。運用コストも比較的低く、トラフィックが増えても容易にスケールできる。このような特性から、ドキュメントサイト、ナレッジベース、ブログ、企業のウェブサイトなど、内容が頻繁に変わらない情報提供型のサイトに非常に適している。しかし、制限もある。新しいコンテンツを追加したり既存の内容を更新したりした場合、ウェブサイトに反映させるためには、その都度SSGを再実行してファイルを再ビルドする必要がある。また、ユーザー入力に応じた動的な表示や複雑なデータ処理が必要な機能は、クライアントサイドのJavaScriptやサーバーレスAPI、Functionサービスと連携させる必要がある。

このシステムにおいて、デプロイ先としてCloudflare Pagesが採用される。Cloudflare Pagesは、ウェブ開発者向けのプラットフォームであり、フロントエンドのウェブサイトやJamstackアプリケーションを簡単にデプロイできるサービスである。特徴は、GitHubやGitLabなどのGitリポジトリと連携し、コードがプッシュされると自動的にウェブサイトをビルドして、CloudflareのグローバルCDN（コンテンツデリバリネットワーク）にデプロイする点にある。デプロイ後には本番環境用のURLが自動的に発行され、さらに無料でSSL証明書も提供されるため、ウェブサイトのセキュリティも確保される。

Cloudflare Pagesを選ぶ具体的なメリットは多岐にわたる。まず、GitHubやGitLabなどのGitリポジトリと直接連携できるため、開発者は慣れた環境でコードを管理できる。コードがリポジトリにプッシュされると、Cloudflare Pagesが自動的にウェブサイトをビルドし、デプロイを行うため、手動での作業が不要になり、効率が大幅に向上する。デプロイされたウェブサイトはCloudflareの広範なCDNネットワークを通じて世界中に配信されるため、ユーザーはどこからでも高速にコンテンツにアクセスできる。本番環境用のURLが自動的に提供されるので、独自ドメインを購入する手間が省け、すぐにウェブサイトを公開できる。また、SSL証明書が標準で提供されるため、追加の設定なしで安全なHTTPS接続を利用できる。さらに、継続的インテグレーション/継続的デプロイ（CI/CD）のパイプラインが組み込まれているため、開発からデプロイまでの一連の流れがスムーズに進む。

次に、Cloudflare Pagesを設定する手順について説明する。この設定では、QuartzというSSGを使って、GitHubにあるチームのMarkdownデータをHTML静的ファイルに変換し、Cloudflare Pages上に公開する。まず、Cloudflareアカウントにログインし、ダッシュボードの左側メニューから「Compute (Worker)」配下の「Worker & Pages」を選択する。次に、「Get Started」画面で「Import a repository」を選び、「Get Started」ボタンをクリックする。続いて、「Import a repository」画面で「GitHub」ボタンをクリックすると、CloudflareがGitHubへの連携を求めるページに遷移する。ここで、Cloudflareがアクセスを許可するリポジトリを選択する。「Only select repositories」を選び、対象のGitHubリポジトリを選択した後、「Install & Authorize」ボタンをクリックして連携を完了させる。Cloudflareのダッシュボードに戻り、今度は「Pages」タブから「Import an existing Git repository」を選び、「Get Started」ボタンをクリックする。GitHubアカウントを選択し、「Begin setup」ボタンを押すと、ビルドとデプロイに関する設定画面が表示される。

この設定画面ではいくつかの項目を設定する。「Project name」はGitHubのリポジトリ名が自動的に読み込まれる。「Production branch」は、Cloudflare Pagesにデプロイする際に利用するGitブランチの名前を指定する。通常は「main」や「master」となる。重要なのは「Framework preset」の設定だ。ここでは「None」を選択する。なぜなら、今回のプロジェクトではQuartzというカスタムのSSGを使用するため、Cloudflare Pagesが提供する特定のフレームワークプリセットは不要だからである。ビルドコマンドとして、「bash ./scripts/setup_quartz.sh」といったシェルスクリプトの実行コマンドを指定する。これは、Quartzを使って静的サイトを生成するための具体的な処理を指示するコマンドだ。そして、「Build output directory」には、静的サイトが生成された後にファイルが格納されるフォルダのパス、「site/public」のような場所を指定する。これらの設定が完了したら、「Save and Deploy」ボタンをクリックする。

これにより、Cloudflare PagesがQuartzを使って静的サイトをビルドし、デプロイするプロセスが開始される。ビルドとデプロイが完了すると、「Building and deploying」画面に進行状況が表示され、最終的にウェブサイトは「https://{プロジェクト名}.pages.dev」のようなURLでアクセス可能になる。

この記事で紹介された方法は、ITサポートチームが散在していた知識を「第二の脳」の概念に基づいて一元化する素晴らしいアプローチだ。ObsidianでMarkdown形式のノートとして知識を記録し、ウィキリンクやグラフ機能を使って関連性を構築する。その上で、QuartzというStatic Site Generator（SSG）を使って、それらのノートを検索しやすく読みやすいウェブサイトに変換する。さらに、Cloudflare Pagesにデプロイすることで、CloudflareのCDNによる高速なアクセス、Gitからの自動デプロイ、プルリクエストごとのプレビュー機能、そして自動HTTPS化といった多くの恩恵を受けられる。結果として、DevOpsのような効率的なドキュメント管理ワークフローが実現する。つまり、知識を作成し、プルリクエストでレビューを受け、承認されてマージされれば、ウェブサイトが自動的に更新されるという流れだ。これにより、チームは繰り返し発生するタスクにより迅速に対応できるようになり、知識が標準化され、長期的にチームの成長や知識の拡大をサポートする基盤を構築できる。