Notion × Gemini CLI × NotebookLM で構築する、PM業務ハイブリッド自動化パイプラインの技術仕様
はじめに：「No Code」の限界と、スクリプトへの回帰
プロジェクトマネジメント（PM）の現場において、ZapierやMakeといったiPaaS（Integration Platform as a Service）は確かに便利です。しかし、数十億規模のプロジェクトや、複雑なステークホルダーが絡む現場において、GUIベースの自動化ツールだけで「痒い所」まで手を届かせるのは至難の業です。
APIリミット、複雑な条件分岐、そしてローカル環境でのセキュアなデータ処理。これらを考慮した際、私たちエンジニア出身のPMが取るべき選択肢は、ブラックボックス化したSaaSに依存することではありません。自らの手でコントロール可能な「堅牢なパイプライン」を構築することです。
今回は、私が実務で稼働させている、Notionをハブとした「PM業務ハイブリッド自動化パイプライン」の技術仕様を公開します。 ここで言う「ハイブリッド」とは、単純なツール連携という意味だけでなく、「AIによる処理」と「人間によるトリガー/判断」の明確な役割分担を指します。 完全自動化を目指すのではなく、AIを「優秀な副操縦士（Co-Pilot）」として実装する現実的な設計図です。
Architecture：ハイブリッド・パイプラインの全貌
本システムは、クラウド（Notion/Google）とローカル（Python/Batch）を組み合わせたハイブリッド構成です。建築において基礎と構造が重要であるように、データフローもまた、明確な役割分担が必要です。
コア・アーキテクチャの役割定義
- Hub: Notion (DB & API Interface) すべてのプロジェクト情報の集約地。ただし、単なるWikiではなく、API経由でデータを読み書きする「リレーショナル・データベース」として扱います。
- Engine: Gemini CLI 非構造データ（議事録、チャットログ）を構造化データ（JSON/Markdown）へ変換するETLエンジンの役割を担います。
- Analyst: NotebookLM 生成されたデータに対し、RAG（検索拡張生成）を用いて深掘り分析を行う「参謀」です。
- Controller: Windows Batch & Python Scripts これらを統制する指揮官です。タスクスケジューラによる定期実行と、引数による手動実行を制御します。
Implementation：自動化スクリプトの勘所
このパイプラインの肝は、Phase 2 (Injection) における制御ロジックにあります。 単にデータを流し込むだけなら誰でもできます。しかし、実務では「特定のプロジェクトだけ更新したい」「先週のデータだけ再取得したい」というイレギュラーが必ず発生します。
ここで重要になるのが、私が運用している run_ai_analyzer_gemini.bat および notion_auto_sync.bat の引数設計です。
1. 引数による実行制御（Controller Logic）
バッチファイルは、Pythonスクリプトへのラッパーとして機能させ、柔軟性を持たせています。以下は、その引数設計の仕様です。
- 引数なし（Default）:
- 対象: 全アクティブプロジェクト
- 期間: 前週（月曜～金曜）
- 用途: 週末の定時バッチ処理。週次レポートの基礎データを自動生成します。
- 引数 1（Project Specific）:
- 対象: 特定のプロジェクトID（対話モードまたは設定ファイルで指定）
- 期間: 指定可能
- 用途: プロジェクト計画変更時や、緊急の会議後に特定案件のみ即時更新する場合に使用します。
- 引数 2（Date Specific）:
- 対象: 全プロジェクト
- 期間: 特定の日付範囲
- 用途: 月次締め処理や、四半期レビュー用に過去データを再集計する際に使用します。
この「運用柔軟性」こそが、スクリプトによる実装の最大のメリットです。GUIツールでは、この分岐を作るだけでフローチャートがスパゲッティ化しますが、コードであれば数行の if 文で完結します。
2. 非構造データの構造化（Engine Logic）
Phase 1からPhase 2にかけて、議事録（MP4から文字起こしされたテキスト）やTeamsのチャットログは、Gemini CLIを経由してNotionへ投入されます。
ここでGeminiに与えるシステムプロンプトは、「要約」ではありません。「構造化」です。 具体的には、以下のJSONスキームへのマッピングを強制します。
JSON
{
"decisions": ["決定事項1", "決定事項2"],
"action_items": [
{"task": "タスク名", "owner": "担当者", "deadline": "YYYY-MM-DD"}
],
"risks": ["リスク検知内容"]
}
このJSONをPythonでパースし、Notion APIの properties ペイロードに変換して POST します。これにより、議事録が単なるテキストではなく、追跡可能な「データベースのレコード」として格納されます。
Deep Dive：NotebookLMによる「参謀」の活用
Phase 3では、Notionに蓄積されたデータをCSVとしてエクスポートし、GoogleのNotebookLMに投入します。ここでのポイントは、単にログを食わせるだけでなく、「プロジェクト計画書（基本設計書やWBS）」も同時にソースとして与えることです。
これにより、以下のような高度な推論が可能になります。
- 「今週のチャットログの議論（事実）は、当初のWBS（計画）に対してどのような遅延リスクを示唆しているか？」
- 「決定事項Aは、仕様書Bの要件と矛盾していないか？」
単なる検索（Search）ではなく、文脈を理解した分析（Analysis）。これが、私が「Analyst」と呼ぶ所以です。
まとめ：エンジニアリングによる「時間の奪還」
私たち情シスやPMの時間は、有限かつ高価です。 データの転記や、会議の要約作成といった「作業」にリソースを割くのは、組織に対する損失と言えます。
今回紹介した技術仕様は、一見複雑に見えるかもしれません。しかし、一度構築してしまえば、あなたは「情報の整理」から解放され、「情報の解釈」と「意思決定」に集中できるようになります。
技術（Code）で時間を買い、人間は人間にしかできない「判断」を行う。 これこそが、ベテランPMが持つべき生存戦略（Tech Strategy）です。
もし、貴社の環境に合わせた具体的なパイプライン設計や、スクリプトの実装についてより詳細な議論が必要であれば、いつでもお声がけください。現状のツールセットを前提とした、最適なアーキテクチャを提案します。
Next Step: まずは手元の定型業務の中で、「判断」が不要なデータ移動プロセスを一つ特定し、それをPythonスクリプトでAPI操作できるか調査することから始めてみてはいかがでしょうか。
追記：実務と学習の「境界線」を引く
最後に、技術的な実装と同じくらい重要な「運用ルール」について、ベテランとして釘を刺しておかねばなりません。
それは、「コード（論理）は持ち出しても、データ（事実）は持ち出すな」 という鉄則です。
今回紹介したパイプラインを、学習のために個人契約のVPSで構築・試行すること自体は推奨されます。 しかし、そこに**「本物の議事録」や「実際のチャットログ」を流してはいけません。**
企業にとって最高レベルの機密情報を、会社の管理が及ばない外部サーバー（個人契約のVPS）にアップロードする行為は、セキュリティ・コンプライアンス上、一発アウトです。
実務（本番データ）の運用は、あくまでローカル環境（会社のPC）、あるいは会社が認可したセキュアな領域内で行うこと。 一方で、外部のVPSは**「ダミーデータを使った、あなた専用の実験室（サンドボックス）」**として使い倒すこと。
なぜ、あえてVPSが必要なのか？ それは、業務端末（ローカル）を汚さずに、失敗できる環境が必要だからです。
業務端末で慣れないPythonライブラリをインストールしたり、環境変数を書き換えたりして、PCの挙動をおかしくしてしまった経験はないでしょうか？ 月額1,000円程度で手に入るVPSは、「いくら壊しても、リセットボタン一つで元通りになる自由な実験空間」です。
外部の実験室で、ダミーデータを使って思う存分試行錯誤し、そこで検証済みの安全な知見（コード）だけを、業務という「現場」へ持ち帰る。 この使い分けができることこそが、技術に強いPMの条件であると言えます。