Notion議事録を自動タスク化するエージェント設定手順


会議が終わるたびに議事録を見返して、タスクを手で作り直していないだろうか。「次回までに○○を確認」「△△さんが調査」といったアクションアイテムが議事録に埋もれたまま、期限当日に思い出すパターンは意外と多い。

この記事では、Notionの議事録からタスクを自動で抽出してデータベースに登録する仕組みを、エージェントを使って構築する手順を解説する。ノーコードツールではなく、OpenAI Agents SDKとNotion APIを組み合わせる方法だ。多少のコーディングは必要だが、一度作れば「会議後に議事録を保存するだけでタスクが生成される」状態になる。


全体の流れを3段階で捉える

自動化の設計は、次の3ステップに分けると整理しやすい。

  1. 議事録の生成・入力:NotionのAI Meeting Notesや手動入力で議事録を作成
  2. アクションアイテムの抽出:LLM(大規模言語モデル)で「誰が・何を・いつまでに」を構造化
  3. Notionタスクデータベースへの登録:Notion APIでタスクを作成

この記事では、2と3をエージェントで自動化する部分に焦点を当てる。1の議事録生成はNotionのAI Meeting Notes(/meetコマンドで開始)を使う前提で進めるが、手入力の議事録でも同じ仕組みが使える。


事前準備:Notion APIのセットアップ

まずNotion側の準備から。

インテグレーションの作成

  1. Notion Developersにアクセス
  2. 「New integration」でインテグレーションを作成
  3. 「Internal integration token」をコピーして保管(後で環境変数に設定)

タスクデータベースの共有設定

タスクを登録したいNotionデータベースを開き、右上の「…」→「コネクト」から作成したインテグレーションを追加する。これをしないとAPIからアクセスできない。

データベースIDの取得

データベースのURLは https://www.notion.so/xxxxxxxx?v=yyyyyyyy のような形式になっている。xxxxxxxxの部分(32文字のハイフンなし)がデータベースIDだ。


エージェント実装:OpenAI Agents SDKでツールを定義

OpenAI Agents SDKを使うと、LLMに「関数を呼び出させる」形でNotion APIを実行できる。いわゆる「function tool」という仕組みだ。

ツール関数の設計

タスク作成用の関数を定義する。引数スキーマをJSON SchemaやZodで厳密に指定すると、LLMが「期限の形式が間違っている」「タイトルが空」といった不正な入力をしにくくなる。

// Zodスキーマの例
const CreateTaskSchema = z.object({
  title: z.string().min(1).describe("タスクのタイトル"),
  assignee: z.string().optional().describe("担当者名"),
  dueDate: z.string().regex(/^\d{4}-\d{2}-\d{2}$/).optional().describe("期限(YYYY-MM-DD形式)"),
  priority: z.enum(["高", "中", "低"]).optional().describe("優先度"),
});

期限のフォーマットを YYYY-MM-DD に強制しているのがポイント。LLMは「来週金曜」のような曖昧な表現を返すことがあるが、スキーマで弾けば誤登録を防げる。

Notion APIの呼び出し部分

タスク作成は POST /v1/pages を使う。リクエストボディで親データベースと各プロパティを指定する。

async function createNotionTask(task: CreateTaskInput) {
  const response = await fetch("https://api.notion.com/v1/pages", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${NOTION_TOKEN}`,
      "Content-Type": "application/json",
      "Notion-Version": "2022-06-28", // バージョン固定を推奨
    },
    body: JSON.stringify({
      parent: { database_id: TASK_DATABASE_ID },
      properties: {
        "タイトル": { title: [{ text: { content: task.title } }] },
        "担当者": task.assignee ? { rich_text: [{ text: { content: task.assignee } }] } : undefined,
        "期限": task.dueDate ? { date: { start: task.dueDate } } : undefined,
        // 他のプロパティも同様にマッピング
      },
    }),
  });
  return response.json();
}

Notion-Versionヘッダは必須で、固定値を指定しておくと将来のAPI変更で突然動かなくなるリスクを減らせる。


レート制限への対策

Notion APIは平均3リクエスト/秒の制限がある。議事録から10個のタスクを一気に作ろうとすると、429エラー(rate_limited)が返ってくる可能性がある。

対策は2つ。

  • Retry-Afterヘッダを尊重:429が返ってきたら、レスポンスヘッダのRetry-After秒だけ待ってからリトライ
  • キューで平準化:タスク作成リクエストをキューに入れ、300〜400ms間隔で順次処理

実装がシンプルなのは前者だが、タスク数が多い場合は後者のほうが安定する。


AI Meeting Notesを使う場合の注意点

NotionのAI Meeting Notesは便利だが、いくつか確認しておくべきことがある。

  • 同意の取得:音声・画面収録を行うため、会議参加者への事前説明と同意が前提
  • 音声データの扱い:処理後に削除されるが、モバイルでは処理中に一時保存され、失敗時は最大3日保持される可能性がある
  • ワークスペース設定:管理者がこの機能自体を無効化できる

社内ルールや情報セキュリティポリシーによっては、AI Meeting Notesの利用が制限されている場合もある。導入前に確認しておこう。


向いている人・向いていない人

この仕組みが特に効くのは、週に何度も定例会議があり、毎回同じフォーマットの議事録を作っているチームだ。議事録の構造が安定していると、LLMの抽出精度も上がる。

一方、以下のケースでは別のアプローチを検討したほうがいい。

  • 議事録が自由形式で書き方がバラバラ:抽出精度が安定しない。まずテンプレートを整備するほうが先
  • タスクの粒度を人間が判断したい:自動化するとLLMの判断でタスクが切られるため、「これは1つにまとめたかった」というズレが起きることがある
  • コーディングに抵抗がある:ZapierやMakeのようなノーコードツールのほうが導入コストは低い(ただし柔軟性は落ちる)

まとめ

議事録からタスクを自動抽出する仕組みは、「議事録入力→LLMで抽出→Notion APIで登録」の3段構成で設計すると見通しがよくなる。OpenAI Agents SDKのfunction toolを使えば、LLMに構造化データを出力させてそのままAPIに渡す流れが作れる。

レート制限やAI Meeting Notesのデータ取り扱いなど、運用上の注意点を押さえておけば、会議後の「タスク転記作業」から解放される。まずは1つの定例会議で試してみて、精度を確認しながら範囲を広げていくのがおすすめだ。


参考リンク