NotionをOttermindに取り込む：チームのページを仕事に生かす

Notionのプロジェクトページを、Ottermindで進めている仕事に取り込みましょう。Notionスキルを設定すると、エージェントがアクセス可能な内容を読み、役立つ説明資料にまとめる手伝いをし、チームが普段使っているページへの更新案を用意できます。まずは、理解したいプロジェクトと、下す必要のある判断を明確にします。

実際に役立つのは、ページを開いてから「次に何をすべきか」が分かるまでの作業です。リリース計画には対象範囲が、決定事項の記録には変更の理由が、進捗管理表には残りの作業が書かれています。これらを合わせて読むことで、元のページをいつでも参照できる状態のまま、プロジェクトに参加する準備を整えられるはずです。

この記事では、架空の新規ユーザー向けオンボーディング機能のリリースを題材に、準備から会議後のフォローまでをたどります。掲載する資料と出力例はワークフローの説明用であり、実際の顧客タスクの記録や製品テストではありません。

Notionとの接続を準備する

このワークフローでは、NotionがホストするMCPサーバーに接続するNotionスキルを使います。Ottermindに掲載されているサードパーティー製のスキルです。設定にはmcporterとNotionのOAuth認証を使用します。スキルを有効にし、作業を担当するエージェントに紐づけ、開始前に接続手順を完了してください。

続いて、自分が知っているページのURLをエージェントに送り、ページタイトルの確認を依頼します。最初の読み取りで、接続先からどの内容にアクセスできるかを確かめます。個人用と会社用のワークスペースを使い分けている場合は、正しいワークスペースに接続しているかも確認しましょう。

スキルの紐づけはOttermindの設定ガイド、認証についてはNotionの接続ガイドで説明しています。利用できるツールは、接続したアカウント、権限、プランによって異なります。

背景情報を整理してからプロジェクトレビューに臨む

オンボーディング機能のリリース調整を引き継ぐ場面を想像してください。同僚から、リリース計画、決定事項の記録、リリース準備の管理表という3つのリンクが届きました。明日のレビューまでに、チームが何をリリースすることで合意しているのかを把握する必要があります。

最初の依頼で、その目的を伝えましょう。「これらのページを要約して」では、どの情報が重要かをエージェントに委ねることになります。「リリース範囲と未決事項を議論するための準備をして」なら、説明資料の読み手と役割が明確になります。

オンボーディング機能のリリース調整を引き継ぐことになりました。
次のURLにあるリリース計画、決定事項の記録、リリース準備の管理表を読んでください。
[ページURL]。明日の範囲レビューに向けて、1ページの説明資料を作ってください。

リリースの目的、合意済みの範囲、すでに決まったこと、
未解決の質問を含めてください。重要な各項目に元のページへのリンクを付けてください。
提案と確定した決定事項を分けてください。ページ間に食い違いがあれば、
矛盾する記述と、私たちが解決すべき問いを示してください。
関連する内容を読めなかった場合は、その旨を伝えてください。

役立つ回答に何が必要かを見るため、元のページに次の情報が書かれていると仮定します。

重要なのは、これらの記述の関係です。ページごとの要約では、3つの情報を繰り返すだけでしょう。役立つ説明資料は、計画と管理表を一致させるために必要な判断を示します。

Notionのツールでは、ページ内容の取得や、アクセス可能なワークスペース内の資料の検索ができます。説明資料を作る際は、検索結果の抜粋だけに頼らず、重要な結果の元ページを開くようエージェントに依頼しましょう。

元のページを読む: Notion MCPがサポートするツール

最初の説明資料ができたら、読み手をさらに具体的に指定します。「サポート責任者向けに書き直してください。顧客が使う登録経路と、サポートチームが準備すべきことに重点を置いてください。」この追加依頼では、根拠を変えずに重点を調整できます。また、最初の原稿が読み手の既知の知識として扱っていた背景情報を見つけるのにも役立ちます。

情報の多い管理表を短い会議アジェンダにする

範囲を理解したら、次はレビューの時間をどこに使うかを考えます。管理表に何十件ものレコードがあっても、今日判断が必要なものは数件かもしれません。

チームが実際に保存して使っているビューから始めます。アジェンダを整理する前に、フィールドと表示されているレコードを確認するようエージェントに依頼してください。Notionのデータベースツールはビューとデータソースの情報を提供しますが、クエリへのアクセスはプランによって異なります。指定したビューをすべて読み取れない場合は、作成するアジェンダにその旨を明記する必要があります。

このリリース準備管理表のビューを使ってください：[ビューURL]。
オンボーディング機能のリリースに関する未完了の項目を確認してください。

項目名、元のリンク、記録されている担当者、
記録されている次のアクション、判断が必要な質問を表にしてください。
担当者や次のアクションが未記入の項目と、先ほど確認した
決定事項の記録と範囲が食い違う項目に注目してください。
人や日付を割り当てないでください。会議アジェンダの案としてまとめてください。

架空のリリースを例にすると、役立つアジェンダは次のようになります。

これらの行は説明用の例であり、実際のワークスペースから取得した情報ではありません。求めるべき具体性を示しています。つまり、正確な不足点、その元となるレコード、そして誰かが答えられる質問です。

同じ会話の中でアジェンダをさらに絞り込めます。レビューを終える前に解決すべき3つの質問を挙げてもらったり、回答すべき人ごとに項目をまとめてもらったりします。提案された議論の順番は、記録済みの優先順位とは明確に区別してください。

こうして、目的のある会議資料ができます。関連レコードがすでに特定されているため、参加者は担当と範囲を決めることに時間を使えます。レビュー後は同じレコードに戻り、合意した変更を反映できます。

チームが使うページに決定事項を書き戻す

レビューは仕事の一部にすぎません。決定事項には、後から継続して参照できる場所が必要です。特に、会議に出席していない人が1週間後にリリースページを読む場合には重要です。

説明資料から続けて、確定した会議メモを追加します。たとえば、シングルサインオンは今回のリリース対象外とし、指名されたサポート責任者がFAQを担当することで合意したかもしれません。Notionに書き込む前に、更新案を提示してもらいましょう。

リリースレビューで確定した結果はこちらです：[承認済みのメモ]。
このプロジェクトページに追加する、日付付きの更新案を作ってください：[ページURL]。

決まったこと、その理由、メモに明記された次のアクションを
含めてください。追加するセクションの全文と、追加位置の案を示してください。
ページのほかの部分はそのままにしてください。書き込む前に私の確認を待ってください。
その後、変更したセクションを読み直し、ページへのリンクを返してください。

更新は、決定事項 → 理由 → 次のアクション → 関連レコードという簡単な構成にできます。次の読み手が、結果と、その後の作業がどこで続くかを理解するのに十分な背景を伝えられます。決定に影響しなかった議論は省きましょう。

選択したスキルは、アクセス可能なNotionコンテンツを更新できます。その指示では、変更する具体的な対象について明確な意図が求められています。書き込み先を指定し、提案されたセクションを確認することで、その意図を具体化できます。

合意した更新を書き込む: 選択したNotionスキルと対応する操作

管理表のプロパティも変更する必要がある場合は、別の明示的な編集として扱ってください。決定メモを追加しても、以前の範囲を参照するすべてのレコードが自動で更新されるわけではありません。残っている不整合をエージェントに一覧にしてもらい、今回のタスクでどこまで更新するかを判断します。

実際の判断に関わるページから始める

すでに関わっているプロジェクトの計画、決定事項の記録、管理表を用意しましょう。次の話し合いの前に読める説明資料を依頼し、その後、同じ文脈を使ってアジェンダを準備し、結果を記録します。

これは、Ottermindのエージェントワークスペースを活用する実用的な方法です。元の資料と、それが支える仕事をつなげておきましょう。再利用できるスキルを初めて使うなら、スキルの入門記事から始めてください。すでにプロジェクトがあるなら、Notionスキルを開き、そのプロジェクトの元ページから始めましょう。