こんにちは、ともしゅうです。CloudNativeで情シスの運用支援をしています。
みなさん、NotionのAIミーティングノート使ってますか？
弊社の会議はほぼ全部、NotionのAIミーティングノートで議事録をとっています。弊社ブログのNotionが議事録をAIで生成してくれる「Notion AIミーティングノート」が結構便利だったは公開から1年以上経ちますが、いまも毎日読まれています。
情報基盤としてNotionを扱う上では、AIミーティングノートを使うだけで案件の議事録がNotionに集まっていきます。
今回はさらに今年2026年7月にリリースされた、議事録が完了したタイミングでカスタムエージェントを起動できるトリガーを使って、もう少し便利にしてみようと思います。
会議のあとに毎回やっている作業を、トリガーの先につなげられるようになりました。依頼事項をタスクに起票する、決まったことをSlackに流す、次回のアジェンダを用意する、といったことが考えられます。
今回作ったものはシンプルです。議事録が1つのDBに集まっていて、その会議メモの要約が終わると、エージェントがタスクDBに起票する。自動で動くのは3つの箱と、間をつなぐトリガー1本だけです。最後に人が目を通します。
この形に落ち着くまでに踏んだ手順と、途中で分かったことを順に書いていきます。
議事録の置き場所
本題に入る前に一つだけ。議事録は1つのDBに集めておいてください。
理由は単純で、AIから参照しやすい場所を1つ作っておくためです。
AIに何かを任せるときは、どこを見せるかが決まっているかどうかで結果が変わります。議事録が1つのDBに並んでいれば、案件や会議種別のプロパティで「どの範囲を読ませるか」を指定できます。今回のトリガーも同じで、「このDBの会議メモ」という形で対象を指定するので、議事録が集約されていないと、何を読ませるかを正確に決められません。
あわせて、議事録はこのDBに作る、というのをチームや全社の共通ルールにしてください。誰でもどこにでもページを作れるのがNotionの良さですが、そのぶん置き場所は放っておくと崩れます。誰か一人が別の場所に作り始めると、その会議だけが検索にも自動化にも乗りません。
トリガーの設定と挙動
カスタムエージェントはBusinessプランとEnterpriseプランでしか使えません。実行するたびにNotionクレジットを消費します。そして、触れるのはツールとアクセスで明示的に許可したページやDBだけです。既定でワークスペース全体が見えるわけではありません。
なお料金と予算の組み立ては弊社ブログのNotion AIカスタムエージェントとは？料金・権限・運用設計とNotion AIマスターコースで詳しく整理しているので、ここでは挙動の話だけにします。
トリガーの設定
作った手順は6つです。
- 議事録DBを用意する（案件プロパティを持たせる）
- タスクDBを用意する（タスク名、担当者、期限、関連議事録）
- エージェントを作る
- エージェントのツールとアクセスに2つのDBを追加し、議事録DBを読み取り権限、タスクDBをコンテンツ編集権限にする（入力は読むだけ、出力だけ書ける形にしておく）
- トリガーを追加する
- 指示を書く
5で選べるミーティングのメモの要約が、今回追加されたトリガーです。選んだあとの設定項目は4つでした。
- データソースを選択：監視する議事録DBを指定します
- アクセス：指定したDBに対する権限が表示されます。読み取り権限のままにしておきます
- ビューを選択：既定は「データベース全体」。そのDBのビューを指定して範囲を絞ることもできます
- プロパティを選択：プロパティを追加から条件を足せます。「クライアントが 案件A社 である」のような形です
指示のほうは、最小限から始めました。
会議メモの要約から、担当者と期限の両方が明示された依頼事項を抽出し、
タスクDBに1件ずつ起票してください。
タスク名、担当者、期限、元の会議メモページへのリレーションを設定します。
期限は会議の開催日を基準に、相対表現を具体的な日付へ変換してください。
担当者が決まっていない依頼を、あなたの判断で誰かに割り当てないでください。
担当者または期限が不明な依頼は起票せず、要確認として報告してください。
ワークスペースのメンバーとして見つからない名前を担当者に設定しないでください。指示は日本語の文章で渡せます。「担当者と期限の両方が明示された依頼事項だけ」を条件式で書こうとすると、担当者名が発話に含まれるかをどう判定するのかという話から始まります。そこを丸ごと任せられるので、判定の条件を自前で定義する必要がありません。
設定でひとつ落とし穴がありました。トリガーのデータソースに、会議メモが入っていないDBを指定できてしまいます。私はうっかりタスクDBを指定して保存しましたが、警告は出ませんし、当然ながら永遠に発火しません。動かないときはまずここを見てください。
動かしてみた
毎回会議を開くわけにもいかないので、台本を読み上げた音声を、議事録ページのMeeting Notesブロックの設定アイコンから入れる形で回しました。
検証の条件はこうです。
- 環境: 社内ワークスペースの検証用ページ配下に、議事録DBとタスクDBを作った
- 議事録: 台本を読み上げた音声を投入。要約の生成には1分以上の音声が必要
- 試行: 台本2本で計4回。うち1本は同じ音声と同じ指示文で2回流した
- 見ないもの: AIミーティングノートの要約性能そのもの
読み上げた台本は次のような内容で、実在の名前は伏せています。
司会: 貸与PCの入れ替えについて、短く決めていきます。
司会: 決定事項の1つ目。次期の標準機は現行と同じシリーズの後継モデルにします。2つ目、入れ替えの対象は購入から4年を超えた端末とし、対応は10月末までに完了させます。
司会: 分担です。Aさん、対象端末のリストアップを今週の金曜日までにお願いします。資産管理台帳の棚卸しも兼ねてください。
司会: Aさんは続けて、キッティング手順の見直しを再来週の月曜日までにお願いします。
司会: 旧端末のデータ消去の運用も決めないといけませんが、担当は次回決めます。
司会: 最後に、リース会社のCさんへの返却スケジュールの確認は、私からやっておきます。
台本に2回出てくるAさんは、どちらも同じメンバーの名前で読んでいます。
アップロードすると文字起こしと要約が自動で生成され、その数分後にエージェントが動きました。同じ音声を2回流したうちの1回目で、できたタスクはこの4件です。
| タスク名 | 担当者 | 期限 |
|---|---|---|
| 対象端末をリストアップする | 設定された | 2026年8月14日 |
| 資産管理台帳の棚卸しを兼ねて端末リストアップを実施する | 設定された | 空欄 |
| キッティング手順を見直す | 設定された | 2026年8月24日 |
| 旧端末のデータ消去の運用方針を決定する | 空欄 | 空欄 |
この回の期限の解釈は正確です。「今週の金曜日まで」は8月14日、「再来週の月曜日まで」は8月24日。会議の開催日を基準に変換されています。元の会議メモへのリレーションも張られていて、あとから経緯をたどれます。
決定事項のほうはタスクにならず、標準機の選定も入れ替え対象も要約の側に残ります。指示で担当者と期限が明示された依頼事項だけを拾うようにしているので、これは想定どおりです。
気になるのは2件目と4件目です。2件目は1つの依頼が2つのタスクに分かれたもの、4件目は会議で「担当は次回決めます」と言った項目で、指示では起票しない想定でした。
実行の記録はエージェントのアクティビティから確認できます。何がきっかけで動いて、何をしたのか、失敗したのかが並びます。
ハマりポイント：文字起こしの誤認識
文字起こしの間違いは、そのままタスクに残ります。 2種類起きました。
1つはタスク名です。別の台本を読んだ回ですが、「既存Wiki」が「既存域」と文字起こしされ、そのまま「既存域のアクセス権限を棚卸しする」というタスクになりました。意味は通じますが、日本語として変です。
もう1つは人名です。あるメンバーの名前が別の名前として文字起こしされ、担当者は空欄になりました。タスクの本文にはこう書かれていました。
会議内では担当者が「（誤認識された名前）」とされていたため、担当者プロパティは未設定。
推測で誰かを割り当てず、空にして理由を残しています。指示に「見つからない名前を担当者に設定しないでください」と書いたのが効きました。しかも同じ会議の中でも揺れていて、もう1つのタスクでは同じ人の名前が正しく解決されています。
案件ごとの絞り込み
ここまでで、エージェント1体が議事録DBを見て、タスクDBに起票する形ができました。
次はもう一歩実際の運用に踏み込んで、タスク化する案件の指定方法についてです。議事録は一つにまとまっていますが、実際タスクDBは案件ごとに保持している場合がほぼ全てです。また議事録DBには様々な打ち合わせの情報が入るため、その中にはまだタスク化しない新規案件や突発の打ち合わせもあるはずです。
タスクDBを分ける基準
タスクDBを分ける本質的な理由は、共有範囲です。Notionの共有はページやDB単位なので、1つのDBに全案件のタスクが入っていると、行単位で見せ分けることができません。支援先や案件メンバーにタスクDBを見せるなら、案件ごとに分けてページの共有設定で制御する必要があります。
逆に社内だけで見るのなら、分けないほうが便利です。1つのタスクDBに案件プロパティを持たせて、案件ページにはフィルタ付きのリンクドビューを貼る。見た目は案件ごとに分かれて見えますし、全案件を期限順に並べるような横断のビューも作れます。DBを分けてしまうと、この横断が作れなくなります。
つまり、表示を分けたいだけならDBを分ける必要はなく、分けるのは共有範囲を分けたいときだけです。議事録DBでやっていることと同じ考え方ですね。
分けるかどうかは、次のどれかに当てはまるかで決めています。
- タスクDBを支援先や案件メンバーに見せる
- 案件ごとにクレジット消費を見たい、上限を引きたい
- 案件によって運用ルールが違うので、指示も分けたい
どれも当てはまらないなら、1体のままで問題ありません。
案件プロパティで絞り込める
分けると決めた場合の話に移ります。結論から書くと、トリガーは案件プロパティの値で必要な案件のみに絞り込めます。
プロパティを選択から「クライアントが 案件A社 である」と設定すると、そのエージェントは案件A社の会議メモにだけ反応します。実際に試したところ、案件A社の議事録では発火してタスクが起票され、案件B社の議事録では要約まで作られたのにエージェントは動きませんでした。
ビューを指定する方法もあります。案件ページに貼ったフィルタ付きのリンクドビューを、トリガーの対象に選べます。ただ私はプロパティ一致のほうを勧めます。ビュー指定だと、誰かがそのビューのフィルタを変えたときに、トリガーの範囲も黙って変わってしまうからです。範囲が変わる経路は少ないほうがいい。
なお、案件で絞り込んだエージェントだけを並べた構成にすると、案件プロパティが空の議事録はどれにも拾われません。会議メモを作る時点でプロパティが埋まる運用にしておく必要があります。
複製で引き継がれるもの
案件ごとにエージェントを作るなら、既存のエージェントを複製するのがいちばん早く済みます。3.6で複製機能が入っていて、メニューから1クリックでコピーできます。
複製で引き継がれるのは、指示、トリガー、そして複製する人にアクセス権があるページやDBです。接続ツールとクレジット上限は引き継がれないので、そこは複製後に設定し直します。
気をつけるのはアクセス許可です。トリガーと書き込み先を新しい案件に直しても、アクセス一覧に前の案件のDBが残っていれば、そのエージェントは両方のDBに書ける状態のままです。案件を分けた理由が共有範囲なら、ここが残っている限り分けた意味がありません。複製したら、ツールとアクセスを1行ずつ見て要らないものを外してください。
振り分け型を勧めない理由
案件ごとにエージェントを作ると、案件の数だけエージェントが増えます。1体に全案件のタスクDBへのアクセスを許可して、指示で「案件A社ならA社のDB、案件B社ならB社のDB」と振り分けさせれば1体で足ります。
ただ、この振り分け型は勧めません。理由は4つあります。
- 指示どおりに動くとは限らない。あとの章で書きますが、同じ音声を同じ指示で流しても結果が変わりました。振り分けが揺れると、案件Aのタスクが案件BのDBに入ります。それは情報が混ざるということです
- 案件が増えるほど揺れる余地が増える。指示が「A社なら、B社なら、C社なら」と分岐で膨らみます。分岐が増えれば、ブレる箇所も増えます
- 権限が全案件に広がる。1体が全案件のタスクDBに書ける状態になり、分離の要件とは両立しません
- 止まったら全案件が止まる。クレジット消費も案件ごとに切り分けられません
混ざってはいけない情報を扱うなら、振り分けはトリガーのフィルタで閉じる。指示に判断させない。分けるほどでもないなら、1つのタスクDBに案件プロパティを持たせて起票する。振り分け型はその中間で、どちらの利点も失う形になってしまいます。
自動化の線引き
タスクは自動で並びますが、そのまま使えるわけではありません。エージェントに任せたのは転記で、会議で担当と期限が決まっている依頼は担当者ごとそのままタスクにします。決まっていないものは埋めさせません。会議で「次回決める」と保留したものを埋めるのは、転記ではなく決定の代行になるからです。
そのうえで、起票されたタスクは人が見ます。担当者も期限も転記が合っているかを定例のあとに確認して、空欄を埋め、要らないものを消す。この一手間は残す前提で組んでいて、誤字も重複もここで拾えます。
この分け方は、最初から決めていたわけではありません。エージェントが触れるのは許可した範囲だけだということ、発話の名前からメンバーを解決する精度に限界があること。触ってみてそういう制約が見えてから、ようやく形になりました。どこで区切るかは、やりたいことだけでは決まりません。
指示の効き方
同じ台本を読んだ同じ音声を、同じ指示のエージェントに2回流しました。結果が変わりました。
- 1回目は「担当は次回決めます」と言った項目まで起票されました。指示では起票せず要確認に回すはずのものです
- 2回目は同じ項目が起票されませんでした。指示どおりです
- 1つの依頼が、1回目は2つのタスクに分かれ、2回目は1つにまとまりました
つまり、指示で禁じておけば必ず守られるわけではありません。
一方で、効いた指示もあります。名前が解決できなかったときに推測で埋めなかった件は、2回とも守られていました。
どちらも禁止として書いた指示なので、境界は書き方ではなさそうでした。守られた「見つからない名前は設定しない」は、その名前のメンバーがいるかを確かめれば済みます。破られた「担当者が不明な依頼は起票しない」のほうは、その依頼の担当者が決まっているかどうかを会議の文脈から判断しなければなりません。確かめれば済む指示は守られて、判断が要る指示は揺れる。もちろん私が試した回数はわずかなので断定はできませんが、指示を書くときに「これは判断を任せていないか」を見るようになりました。
確実に閉じたいものは、指示ではなく仕組みで閉じる。書き込んでほしくないDBは、指示で禁じるのではなくアクセス許可から外す。反応してほしくない会議は、トリガーのフィルタで外しておく。前の章で振り分けを勧めなかったのは、この順序の話でもあります。
使う前に決めておくこと
便利さのほうばかり書いてきましたが、勝手に動くものを社内に入れるので、先に決めておきたいことが4つあります。
1. どの会議で発火させるか
既定では対象がデータベース全体なので、設定を忘れるとその議事録DBの全会議が対象になります。
1on1や評価面談、人事の相談。こういう会議のメモまで自動処理の対象になっていないかを確認してください。トリガーのプロパティやビューで対象を絞れるので、機微な会議が引っかからない構成にできます。あるいは、そういう会議はそもそもAI会議メモを使わない、保存先のDBを分けておく、という運用も選択肢です。
2. 結果をどこへ展開するか
確認したいのは、エージェントの出力先が会議の参加者の範囲より広くなっていないかです。
タスクDBへの起票なら影響の範囲は絞れますが、Slackへ自動投稿する構成にすると話が変わります。決定事項の要約が、その会議に参加していない人が見られるチャンネルに流れる可能性があります。エージェントに許可した接続先と、会議の参加者範囲を突き合わせて確認してください。
複製して作ったエージェントは複製元のタスクDBへのコンテンツ編集権限がそのまま残るので、出力先の見直しは複製の直後に入れてください。
3. クレジットをどう見るか
エージェントは実行するたびにクレジットを消費します。インサイトの画面で、エージェントごとの実行数と消費、失敗の有無を確認できます。
ここで気になったのが、議事録を多量にとる人がいる場合です。私のように打ち合わせをほぼ全部AI会議メモで回している人がいると、トリガーの対象を広く設定したぶんだけ発火回数が積み上がります。本人は議事録をとっているだけなので、消費が増えていることに気づきません。
エージェント単位のクレジット上限を設定できます。ワークスペースのクレジットが不足すると、カスタムエージェントは自動で一時停止します。最初は小さく上限を設定して、消費の実績を見てから広げるのが安全だと思います。
4. どう止めるか
暴走したときに誰がどこで止めるのか、を先に確認しておきます。
設定 → Notion AI → Agents から、エージェントを個別に無効化できます。エージェントのメニューにはバージョン履歴もあって、設定の変更をあとからたどれました。誰にエージェントを作らせるか、変更の記録をどう残すかは、Notion AIカスタムエージェントとは？料金・権限・運用設計のほうで整理されています。
もう1つ、案件が終わったあとのエージェントをどうするかです。誰も見ていないのに動き続けているものが残らないよう、棚卸しの仕組みは要ります。
おわりに
会議後の転記は、思っていたよりあっさり自動化に載りました。会議のあとの転記に時間を使っているなら、追いかける価値があります。
一方で、任せきりにはできないな、というのが率直なところです。文字起こしの誤認識はそのまま下流に流れますし、指示で禁じたことが必ず守られるわけでもありません。ただ、それが分かったうえで線を引けば、十分に使えます。何を任せて何を人が持つか、その線は仕様書を読むだけでは決まらなくて、触ってみて制約が見えてから初めて引けるものです。
同じように会議後の作業に頭を悩ませている方がいたら、何かの参考になれば嬉しいです。相談したいことがあればお気軽にお声がけください！
