TECHSCORE BLOG

マーケティングSaaS を提供するシナジーマーケティングのエンジニアブログです。

「作りたい」を「作れる」に変えるAI駆動プロトタイピング — 計画錯誤を乗り越える開発戦略

n8n Gemini File Search Tool Firecrawl Cursor NotebookLM

1. はじめに

NotebookLMによるインフォグラフィクス

何か新しいものを作るとき、最初は壮大なアイデアを抱きます。そのアイデアは大きくて新しいものほど曖昧であり、それを実現するための技術的知識は不足しています。何から手を付けたらよいか悩んだり、いつまでも設計資料や結合できない部品を作り続けたり、あげく出来上がったものが思っていたものと違うという失敗を繰り返してしまいます。

アジャイルな開発方法論では、このような失敗を避けるためにバーティカルスライスやWalking Skeletonといった考え方が提案されています。エンドツーエンドの小規模な機能を実現するシステムの小さな実装（スライス）を作って徐々に進化させるというアプローチです。

しかしながら、私は最小なスライスを選ぶのは難しいなと感じます。完成形が見えたらすぐに作れそうと思う（計画錯誤のバイアス）ので、スライスに分解した案を考えたり実装するのは無駄に感じてしまい、設計や「水平な」機能実装に飛びついてしまいます。

この記事では、「垂直な」マイルストーンの分解と現状とのギャップ分析をAIに任せることで、目標を見失わずにプロトタイプを育てていく開発戦略を紹介します。

題材としては、Google NotebookLM の簡易版を Gemini File Search Tool × Firecrawl × n8n で構築してみます。アプリの紹介やそれら技術の紹介は最小限とします。

2. 実際にできたもの

2.1 できあがった画面

何回かの試行錯誤の結果、以下のようなものができました。

  1. プロジェクト（調べたいテーマをまとめる箱）選択画面 Harvestスクショ1
  2. ソース追加～まとめメモ作成 Harvestスクショ2
  3. チャット～チャットをメモに保存 Harvestスクショ3

2.2 技術の解説

構築に用いた技術解説はこの記事の目的から外れますが、後の説明のため軽く触れておきます。

n8nのオフライン開発環境

n8n はGUIでワークフローを組めるツールのうち、近年注目が集まっているものの一つです。勤務先でローカルにインストールされたインスタンスを利用できたため採用しました。ワークフローだけでなく、HTTPのインタフェースも提供されているので、簡易的なUIやREST APIを作ることもできます。

この記事を書く前にもいくつかワークフローを作っていましたが、GUI上での試行錯誤はどうにも遅すぎます。そこでワークフロー定義ファイルをCursorで編集してサーバと同期する開発環境を作りました。

これにより、大部分のコーディングをAIに任せられますが、AIが持つn8nノードに対する知識が不十分なため、一度に大規模なワークフローを組むことは難しいと分かりました。手作業による小さな実験も行いつつ、少しずつ機能を追加していくアプローチが不可欠です。

File Search Tool

File Search Tool は Google AI for Developers（Gemini API）で検索拡張生成（RAG）を簡単に実現するためのツールです。アカウントに紐づく File Search Store を作成でき、そこにファイルをアップロードするだけでチャンキングや埋め込みベクトルなどの処理を実行してくれます。アップロードするファイルにはメタデータを付与することができ、Geminiのテキスト生成時に参照したいファイルの範囲を絞り込めます。"NotebookLMのソース処理部分がAPIで利用できる" という風に捉えています。このツールのリリースが今回のプロトタイピングを始めるきっかけとなりました。

Firecrawl

Firecrawl は、URLを受け取り、クロールしてクリーンなMarkdownに変換するAPIサービスです。File Search Storeに格納するファイルの収集のために選びました。最近のWebサイトはURLを単純にHTTPリクエストしても内容を取得できないことが多く、何らかのサービスを使うのが早道だと考えました。FirecrawlはLLM対応をうたっており、HTMLだけでなくMarkdownが取得できることがメリットです。さらにWeb検索によってURLを収集することにも使えるため採用しました。

3. AIと育てるプロトタイピング・サイクル

NotebookLMによるサイクルの可視化

3.1 人間がアイデアを投げる

実はこのプロジェクトの前に情報収集エージェントを作ろうとして、NotebookLM の体験に遠く及ばないと感じて廃棄したものがあります。改めて NotebookLM の真似をしてみようと考え、ちょっとだけ独自性を追加した案を Gemini に投げて企画書を作ってもらいました。

Gemini File Search Tool を使って NotebookLM のクローンのようなもの（仮称: Harvest）を作ろうと思っています。
今のところNotebookLMにはカスタマイズ性や外部との接続性が弱いので、独自のものを作る若干の動機があります。
以下に現在のアイデアを書いてみるので、ラフな企画書として markdown にしてもらえませんか？
足りない情報があればディスカッションしましょう。

プロンプトの続き：アイデア

Harvest には「プロジェクト」「メディア」「ソース」「メモ」「ナレッジグラフ」という主要なコンセプトがあることにします。プロジェクトは、「ソース」「メモ」「ナレッジグラフ」を管理する箱です。メディアはWebやGoogleドライブなど情報収集先で、プロジェクトを横断して利用可能です。

ソースは、URLや社内ドキュメントなど一個の情報源を指します。File Search Toolにアップロードするファイルに対応します。コンテンツそのもの、メディアおよびURLやファイルパスなどコンテンツ識別子、ファイルの種類や登録日時などのメタ情報に加えてユーザが任意のメタ情報を管理できることとします。

メモは、ソースを元にLLMとユーザがまとめた情報で、ソースと同じようにFile Search Toolにアップロードすることができます。メモとソースを混同しないように区別します。

ナレッジグラフはメモとソース、メモとメモの間の関係性を表したものです。メモとソースの関係は参照元である、ということですがメモの間の関係性は複数のパターンがあり得ます。ナレッジグラフは、主にメモを再利用しやすくすることを狙っています。

ソースは一つずつ指定することもできますが、メディアごとに用意した検索機能によって収集することも可能とします。

メモはMarkdownなどの形式でエクスポートしたり、ワークフローツールとの連携によりGitHubその他へ送信できるようにします。

Geminiによる企画書

Harvest: Gemini File Search Toolを活用したナレッジベース 企画書 (ラフ)

1. 概要

「Harvest」は、GoogleのNotebookLMに着想を得た、Gemini File Search Toolを活用するナレッジベース・プロジェクトです。NotebookLMの優れたコンセプトを継承しつつ、弱点であるカスタマイズ性や外部との接続性を強化し、より柔軟で強力な情報収集・知識体系化・再利用のプラットフォームを目指します。

2. 目的

  • 情報源（ソース）とそれに基づく知見（メモ）を一元管理する。
  • Gemini File Search Toolを中核に据え、高度なセマンティック検索を実現する。
  • ユーザーによるメタ情報の付与や、外部ツールとの連携を可能にし、高いカスタマイズ性と拡張性を提供する。
  • 情報間の関係性を「ナレッジグラフ」として可視化・管理し、知識の再利用性を高める。

3. 主要コンセプト

Harvestは、以下の5つの主要なコンセプトで構成されます。

3.1. プロジェクト (Project)

  • 役割: 「ソース」「メモ」「ナレッジグラフ」を管理する最上位のコンテナ（箱）。
  • 単位: 調査対象のトピック、案件、研究テーマなど、ユーザーが任意に設定。

3.2. メディア (Media)

  • 役割: 情報収集先を定義するもの（例: Web検索, Google Drive, 特定のWebサイト, ローカルフォルダ）。
  • 特徴: プロジェクトを横断して利用可能。メディアごとに情報収集（検索）機能を持つことができます。

3.3. ソース (Source)

  • 役割: 個々の具体的な情報源（例: WebページのURL, PDFファイル, 社内ドキュメント）。
  • 対応: Gemini File Search Toolにアップロード（または参照登録）するファイルやコンテンツに対応します。
  • 管理情報:
    • コンテンツ: テキスト、画像などの本体（またはそのキャッシュ）。
    • 識別子: メディア、URL、ファイルパスなど、コンテンツを一意に特定する情報。
    • 基本メタ情報: ファイルの種類、登録日時、文字数など、システムが自動付与する情報。
    • カスタムメタ情報: ユーザーが自由に追加できるタグ、関連プロジェクト、重要度などの情報。
  • 収集方法:
    • 個別指定: ユーザーがURLやファイルを直接指定して登録。
    • メディア検索: 「メディア」ごとに用意された検索機能（例: Google検索、Drive内検索）を通じて収集・登録。

3.4. メモ (Note)

  • 役割: 「ソース」を元に、LLM（Gemini）とユーザーが対話し、まとめた情報、考察、要約。
  • 特徴:
    • 検索対象: 「ソース」と同様に、Gemini File Search Toolにアップロード（または登録）し、検索対象とすることができます（ソースとは明確に区別）。
    • エクスポート: Markdown、プレーンテキストなどの形式でエクスポート可能。
    • 外部連携: ワークフローツール（例: Zapier, Make）との連携により、GitHubのIssueや企業のWiki（例: Confluence）、Slackなどへ送信可能。

3.5. ナレッジグラフ (Knowledge Graph)

  • 役割: 「ソース」と「メモ」、「メモ」と「メモ」の間の関係性を表現・管理するもの。
  • 関係性の例:
    • メモ → ソース: 「参照元である」「引用している」
    • メモ ↔ メモ: 「関連している」「派生したアイデアである」「対立する意見である」「（時系列的に）次に来るステップである」など、複数のパターンを定義可能。
  • 目的: 作成したメモやソース間の文脈を明確にし、知識の再利用性や発見性を向上させる。

4. 想定されるワークフロー

  1. プロジェクト作成: 例: 「競合A社 動向調査」プロジェクトを作成。
  2. メディア設定: 「Google検索」「DocBase」「社内Drive」などをメディアとして設定
  3. ソース収集: 各メディアの検索機能やURL直接指定で、関連するWeb記事や社内レポートを「ソース」として収集。
  4. メモ作成: 収集した「ソース」をFile Search Toolで検索・参照しながら、LLMと対話し、競合A社の動向サマリを「メモ」として作成。
  5. ナレッジグラフ構築: 作成した「メモ」と参照元の「ソース」が自動的にリンク。「メモA」と「メモB」が関連するアイデアであることを手動でリンク。
  6. 再利用・連携: 作成した「メモ」をMarkdownでエクスポートし、週次報告書に貼り付け。または、GitHubに連携し、開発タスク（Issue）を作成。

5. 今後のディスカッションポイント

  • 「ナレッジグラフ」で定義する「メモとメモの関係性」の具体的なパターンにはどのようなものが必要か？
  • 「メディア」ごとの検索機能は、どのように実装・プラグイン化するか？
  • Gemini File Search Toolへのアップロードに関して、ソースとメモの区別を技術的にどう実現するか（例: メタデータでの区別、インデックスの分離など）？
  • 外部連携するワークフローツールの具体的な連携仕様（API、Webhookなど）
  • プロジェクトやソースの情報をどこに永続化するか
    • File Search Toolだけでは管理できない

3.2 AIがマイルストーンを提案

Geminiの作った企画書にはまだどんな概念を扱うかといった抽象的なことしか書かれていません。普通ならUIやデータ構造の設計に進みたいところですが、プロトタイプなので実装しないかもしれないアイデアの設計に時間を使うのはもったいないと考えました。続けて、Gemini に1日程度で達成できるマイルストーンを2つに分けて出してもらうことにしました。

この企画に沿って、n8nでプロトタイプを作ろうと思うのですが、構想（機能）が膨らんで散漫になるのを避けるため、いくつかのマイルストーンを置きたいです。
最初の1～2のマイルストーンの達成には1日程度しか掛けないとしたらどれくらいの目標とするのが良いでしょう。

詳細は省略しますが、各マイルストーンでは以下のような目標が設定されました。まず技術的な難所をおさえてから、永続化への足掛かりを作るという作戦で悪くないと見えました。

  1. n8nのチャットで質問を投げると、FirecrawlがWebを読みに行き、その内容をGeminiに学習させ、質問への回答（＝最初のメモ）が返ってくる状態を作る。
    • 達成基準として、自分が知らない時事ネタなどを質問して、Web記事に基づいた正確な回答が返ってくること。
  2. マイルストーン1の成果物だけでは、ただの「Web検索AI」で、データが流れて消えてしまうので、「Harvest」の要件である「ソースとメモの管理」 を実現するため、DB（スプレッドシート）への永続化を実装する
    • 達成基準として、質問するたびに、スプレッドシートに「どのWebサイトを見て（Source）」「どんな回答を作ったか（Note）」の履歴が溜まっていくこと。

ここで、企画書に至るまでの全てのマイルストーンを事前に設定することはやめておいた方が良いです。試してみましたがマイルストーンの分解の仕方や優先順位を人間が判断できず無駄になる可能性が高いです。

3.3 AIと人間が実装＆デバッグ

次に、マイルストーンの記述をCursorに読み込ませたうえでPlanモードを使ってTODOを計画し、実装させます。

以下のマイルストーンを目指して新しいワークフローHarvest4をデザインしてください。
Gemini File Search Toolの使い方は@experiment-gemini-file-search.json を見てください。

Firecrawlはノードがインストールされていないので、HTTP Requestノードで代用します。APIのリファレンスを参照してください。
https://docs.firecrawl.dev/api-reference/endpoint/search https://docs.firecrawl.dev/api-reference/endpoint/scrape
GeminiとFirecrawlのcredential情報が必要ですが一旦未指定としてください。後でGUI操作します。

先述したようにコーディングはCursorがやってくれますが、そのままで動くことはほとんどありません。ここでのマイルストーンは私が小さな実験を済ませていたものを組み合わせるだけなので問題ないと判断しました。ただし、場合によってはもっと細かく刻んだ方が良いと思います。

3.4 AIがギャップを分析・言語化

マイルストーンに到達したら、ワークフローのJSONと企画書を Gemini に読み込ませて、次にどうするか相談します。

「Harvest」の構想に対して、現在n8nで直線的なワークフローを実装しました。この間のギャップを分析して、次に何に取り組むべきかを議論したい。

結論としては、UIを作ろうということになりました。ここで最初の企画から一段詳細化した仕様案を書いてもらうことにします。ただし、UIの提供自体が大きな変化なので機能は思い切って削減するように指示します。

UIの提供は大きな変化なので、最低限の機能仕様+論理的な画面レイアウト案とそれをn8nでプロトタイピングするADRを書きたいです。ただ、UIはn8nの外に作った方良いと言われた点については、結局プロトタイプなのでn8nのWebhookでHTMLをホストする形で考えたいです。

Harvest_UI_Specification_ADR

Harvest UI プロトタイプ仕様書 & ADR

1. Architecture Decision Record (ADR)

タイトル

n8nホスティング型 シングルページアプリケーション (SPA) によるプロトタイピング

コンテキスト

Harvestプロジェクトは現在、チャットベースの直線的なワークフロー（n8n）で実装されているが、プロジェクトの永続性やソース情報の選別（Human-in-the-loop）を実現するためにGUIが必要となっている。 本格的なフロントエンド開発（React/Vercel等）を行う前に、仕様を固めるためのプロトタイプを低コストで提供したい。

決定事項 (Decision)

UIとバックエンドロジックの両方を n8nのワークフロー内 で完結させるアーキテクチャを採用する。

  1. 配信方法: n8nの Webhook ノードと Respond to Webhook ノードを使用し、HTML/CSS/JSをバンドルした単一のレスポンスを返す。
  2. フレームワーク:
    • Alpine.js: 軽量でHTML内にロジックを記述でき、ビルド不要でCDNから利用できるため採用。
    • Tailwind CSS: スタイリングの工数削減のためCDN版を採用。
  3. 通信方式: フロントエンドから自身のWebhook URLに対して POST リクエストを送り、JSONデータをやり取りする (RPCスタイル)。

結果 (Consequences)

  • メリット:
    • デプロイ不要。n8nのワークフローを保存するだけで更新が反映される。
    • CORS（Cross-Origin Resource Sharing）の問題が発生しない（同一オリジン扱い、もしくはn8nが適切にハンドリングするため）。
    • ユーザー認証をn8nのBasic Auth機能で簡易的に実装できる。
  • デメリット:
    • HTMLコードがn8nのノード内に文字列として埋め込まれるため、エディタでの可読性が低い（VS Code等で編集して貼り付ける運用が必要）。
    • SPAの規模が大きくなると管理が困難になる（あくまでプロトタイプ用）。

2. 機能仕様 (プロトタイプ Scope)

A. プロジェクト管理 (Project Management)

  • 一覧表示: 既存のプロジェクト（Google Sheets）を選択できる。
  • 新規作成: プロジェクト名を入力し、新しい「箱」を作成する。
  • 状態維持: 選択中の project_id を保持し、以後の操作のコンテキストとする。

B. ソース管理 (Source Management)

  • ソース一覧: 現在のプロジェクトに紐付いているソースを表示する。
  • Web検索と追加:
    • キーワードでWebを検索する（Firecrawl Search API）。
    • 結果リストから任意の項目を選択し、「登録」ボタンでプロジェクトに追加する。
    • 登録時、自動的にスクレイピングとGemini File Search Storeへのアップロードを行う（バックエンド処理）。

C. ナレッジ活用 (Chat & Note)

  • コンテキスト付きチャット: 選択中のプロジェクト（およびFile Search Store）の情報を前提にGeminiと会話する。
  • メモ作成: 会話の内容から重要な知見を「メモ」として保存する（今回はチャットログの表示までをスコープとする）。

3. 画面レイアウト案 (Logical Layout)

画面は左右の2ペイン構成とする。

左ペイン: ナビゲーション

  • Projects List: カード形式でプロジェクトを表示。クリックで切り替え。
  • New Project: 新規作成ボタン（モーダルまたはインライン入力）。

右ペイン: ワークスペース

上部に選択中プロジェクトのタイトルを表示し、その下にタブ切り替えを配置する。

  • タブ1: Sources (情報源)
    • Source List: テーブル形式（タイトル, URL, 登録日）。
    • Add Source: 検索ボックス。検索すると下に候補が表示され、チェックボックスで選択して「Import」する。
  • タブ2: Chat / Notes (知恵)
    • Chat Interface: 一般的なチャットUI。ユーザーの入力とGeminiの回答。
    • Action: 回答の下に「Save as Note」ボタン（将来用）。

最初の企画書の代わりにこの仕様書を目標として、作業計画を立てます。

Harvest_UI_Specification_ADR を実現するまでにマイルストーンを「刻む」ことを考えてもらえますか？最初の一日では何を実現したら良いか？

結果として、以下のような4日分のマイルストーンと、もう少し詳細なタスクリストを得ました。Cursorに依頼するときはマイルストーンではなくタスクリストを元に計画と実装をさせます。

  • Day 1: 基盤構築とプロジェクト参照 (Read)
    • n8nでHTMLを配信する。
    • UIからn8nへのAPIコールを通す。
    • Google Sheetから「プロジェクト一覧」を取得して表示する。
  • Day 2: プロジェクト作成とソース検索 (Write/Search)
    • 新規プロジェクト作成（Sheet作成）。
    • Web検索機能の実装（Firecrawl API接続）。
    • 検索結果のUI表示。
  • Day 3: ソース登録とバックエンド処理 (Process)
    • UIで選択したソースを受け取り、スクレイピング・要約・Store登録を行う非同期処理。
    • 処理ステータスの管理（簡易的）。
  • Day 4: チャット機能と統合 (Chat)
    • プロジェクトIDに紐づいたGeminiとの対話。
    • メモの保存。

この計画を返す時に、ちょっと名言っぽいことを生成していたのが印象的でした。

開発の鉄則は「まず疎通（Hello World）させ、次にデータをつなぎ、最後にロジックを複雑にする」です。

3.5 目標の微修正

UIの実装中、仕様書に書かれた内容から逸脱したくなったり、指示されていない箇所で問題が生じることがあります。大きなところでは以下の2つを経験しました。

  • 仕様書では画面レイアウトは左右に分かれていただけだったが、NotebookLM風に3ペイン（ソース、チャット、メモ）に変更し、プロジェクト一覧とプロジェクト選択後の画面が遷移するように変更
    • 仕様書を読んだ時点で気づけば良かったがスルーしていた。実物を見てダメ出しするのは人間相手だったら気まずい
  • ソースをFile Search Storeに追加するには時間が掛かり、フロント側でタイムアウトする場合があったので、非同期実行＋ポーリング処理を追加

こういうことがあるので、事前に先回りして計画することは無駄になることが多いと分かります。実装後にギャップを分析することで軌道修正は可能です。

4. まとめ

本記事では、Gemini File Search Tool と Firecrawl、そして n8n を組み合わせ、NotebookLM のようなナレッジベース「Harvest」をプロトタイピングする過程を紹介しました。現時点のプロトタイプはまだ機能的に弱く、見た目の応答時間やエラーハンドリングなどの課題もたくさん残っています。しかし作ったものそのものは重要ではありません。「やりたいことの大きさ・曖昧さ」と「実現性に対する知識不足」のギャップを埋める方法論を確立できたことが大きな学びでした。私たちは往々にして、最初から完璧な設計図を描こうとして挫折しがちです。しかし、今回のプロジェクトではAIの支援を受けながら以下のサイクルを回すことで、着実に前に進むことができました。

  1. AIに「垂直なマイルストーン」を提案させる： 最初から全てを作ろうとせず、最低限のスコープで仕様を言語化し、さらに「まずはWeb検索だけ」「次は永続化だけ」と、1日で終わるサイズに目標を切り刻む
  2. 動くものを作ってから考える： AIが言う「まず疎通させ、次にデータをつなぎ、最後にロジックを複雑にする」 という鉄則に従い、最低限の実装を行う
  3. ギャップ分析で軌道修正する： 実装結果と当初のアイデアを比較し、足りないものをAIに言語化させ、次の仕様に落とし込む

このようなサイクルを回すことは当然のことかもしれませんが、人間は最初に抱いたアイデアから離れることは難しく、一度書いたコードを壊したり仕様書を書き直し続けることには抵抗感があります。それに比べてAIは完成形へのこだわりが無いのか、Walking Skeleton たりえる垂直なマイルストーンを提案するのが得意であるように思います。コードや仕様書を書き直すのも厭わずに実行してくれます。

こうした面倒ごとを肩代わりさせることで、人間は実現したいアイデアの解像度を上げたり技術的な学びを得ることに注力することができるでしょう。このやり方をさらに磨き、プロトタイピングだけでなく実際のプロダクトづくりにも活かしていきたいと考えています。

Appendix

今回のプロトタイピングで使用した技術について補足します。

A. n8nのオフライン開発環境

このテーマについては、以下のスライドでLTを行いました。

補足

  • ワークフロー定義ファイルの同期にはedenreich/n8n-cliを使用
    • n8n MCP もインストールしていますが、ワークフローのバリデーションに失敗するためワークフローの更新には使っていません
  • JSON内のHTMLやJavaScriptの視認性が悪いので、YAML⇔JSON変換と、HTMLやJavaScriptを外部ファイルに切り出して結合するスクリプトをCursorに作らせて利用

B. Gemini File Search Toolの実験とn8nからの利用方法

File Search Toolを使ってみた記事はたくさんありましたが、手っ取り早く試すために NotebookLM で Deep Research を行い、以下のプロンプトで手順書を作成させました。これにより実行可能なAPI呼び出しのコード例が入手できます。

curl を使って API を叩くまでの最短手順を教えてください。Google Cloudのアカウントは持っています。

n8nには、Gemini API を使うノードはあるものの File Search Tool を使う拡張はまだサポートされていないようなので、HTTP Request node ノードを使って再現します。curl での実行コードがあれば書き換えは難しくありません。

また、アップロードできるデータはバイナリでなければならないので、Webサイトをテキストでスクレイピングした後はConvert to Fileノードを使って変換する必要がありました。

C. Firecrawlの制限

FirecrawlによるWebスクレイピングはいくつかのサイト（reddit.com, x.com, qiita.comなど）で許可されておらずエラーになったので注意が必要です。検索対象から外す必要があるでしょう。また、テキスト情報を持たないPDFファイルからは Markdown を得ることができませんでした。このような場合にはOCRを組み合わせると良いでしょう。それらの対策は今後の課題としておきます。

西尾 義英

長年のペーパードライバーを卒業し週末はカーシェアで出かけるようになりました。カーナビってすごいシステムですね

シナジーマーケティング株式会社では一緒に働く仲間を募集しています。