Notion 3.8で考える、エージェントの文脈と手順の更新責任

エージェントを替えるたびに会社の事情を説明し直さずに済む。その前提は、参照される内容が管理されていることです。Notion 3.8を手がかりに、業務知識と手順の正本と、使われている版の確かめ方を考えます。

エージェントを替えるたびに、会社の事情を一から説明し直していないでしょうか。

Notionは2026年10月13日、リリースノート「Notion 3.8: Context for your agents」を公開しました。

同社はこの更新を、データ・ツール・スキルをつなぐことで、どのエージェントやモデルを使うかを自由に選べるようにするためのものと説明しています。

本稿でいう文脈とは、業務の前提、用語の定義、判断基準、過去の決定など、エージェントが仕事を進めるために参照する情報です。

スキルとは、再利用できる指示と補助ファイルをまとめたものを指します。

複数のエージェントが同じ業務知識や手順を参照できるようになると、どの内容を基準とし、どの版が使われているかを会社として確かめる必要が出てきます。

本稿では、この更新と関連する公式資料を手がかりに、担当者と確認期限、配布先への反映、使わなくなった手順の扱い、接続の見直しを、一連の運用として整理します。

特定製品の比較や推薦、設定画面の手順は対象にしていません。

Notion 3.8のリリースノートと関連資料で確認できること

まず、Notionが公表している範囲を確認します。

以下は2026年10月21日確認時点の記載です。

リリースノートによれば、MCP（AIが外部の情報や機能を利用するための接続規格）に対応したエージェントをNotionにつなぐと、ワークスペースの文脈を読み、ドキュメントやタスク管理を更新できます。

Notion MCPでは、接続した利用者に認められた権限の範囲で、エージェントが情報の読み取りや更新を行います。

Notionはこれを、エージェントに共通の参照先を与えることで、「一から説明し直さずにエージェントを切り替えられる」ためのものと位置づけています。

管理者向けには、MCP管理者コントロールが挙げられています。

リリースノートでは、管理者が各AIツールを誰が接続したかを確認し、最後にいつ使われたかを確かめ、特定の人のアクセスを、他の接続に影響を与えずに取り消せる、と説明されています。

スキルについては、同社はNotionを、スキルの作成・共有・更新に使う場所と位置づけています。

今回のリリースノートでも紹介されているSkills APIは、2026年9月17日付のNotionのブログ「A skills library for every agent」でも紹介されています。

開発者向けドキュメント「Agent Skills API」によれば、このAPIは、Notion上のスキルを、エージェントで利用できるファイルとして取得するためのAPIです。

各スキルの中心となる指示はNotionのページとして書かれ、補助ファイルを添えられます。

公式のサンプル「notion-skills-github-sync」では、定期実行するスクリプトでNotionからGitHubへスキルを同期し、そのリポジトリを各エージェントのスキルの取得元として使う構成が紹介されています。

つまり、Notionでの編集、GitHubへの反映、各エージェントへの反映は、それぞれ別の段階です。

同じリリースには、人とエージェントによる変更を追えるバージョン履歴の強化と、データベースの列ごとに閲覧・編集できる人やエージェントを分ける列権限も含まれています。

提供条件と、資料間の記載差

提供条件は機能ごとに異なります。

開発者向けの「Notion MCP」の資料によれば、メンバーが接続できるMCPクライアントを制限するには、Enterpriseプランが必要です。

Skills APIを使うには、内容の読み取り権限を持つ接続トークンなどと、対象のスキルへのアクセスが必要とされています。

料金プランの条件までは、今回確認した概要資料からは読み取れませんでした。

利用者別の接続管理については、3.8のリリースノート・管理APIの資料と、ヘルプセンターの「Notion MCP」のよくある質問とで記載に差があります。

理由は確認できていないため、利用できる画面やAPIの範囲は、契約プランと自社の環境で確かめてください。

業務知識の正本と、内容を管理する担当者を決める

MIFは、業務知識や手順の正本と、それを管理する担当者を明確にすることを重視しています。

AIの回答や作業の質は、AIが参照する会社の知識をどれだけ管理できているかに左右されると考えているためです。

モデルが変わっても業務が続く構成にするには、業務知識や手順を特定のエージェントとの会話だけに閉じ込めないことが出発点になります。

保存先を一つに統一することが目的ではありません。

この記事で紹介したように、NotionからGitHubへ配布し、そこから各エージェントが読む構成では、保存先は複数になります。

複数の場所へ配布する場合も、何を元に作られ、どの版が使われているかを確認できるようにしておく、というのが私たちの考えです。

担当者や確認期限は、会社として決め、利用できる製品機能へ反映します。

Notionのヘルプ「Wikis & verified pages」によれば、ページにオーナーを設定し、内容を確認済みとして扱う期限を決められ、期限が切れるとオーナーに通知されます。

ウィキでは、作成者が初期のオーナーになり、後から変更できます。

ウィキに属さない個々のページの確認済み設定は、BusinessプランとEnterpriseプランで利用できると案内されています。

こうした機能があっても、適切な担当者や期限が自動的に決まるわけではありません。

利用できる機能と自社の業務ルールを照合し、担当者、確認の条件、設定への反映方法をあわせて決めることを、私たちは勧めます。

業務知識や手順が実態とずれる三つの場面

MIFがここで確認したいのは、次の三つの場面です。

一つ目は、業務が変わっても内容が更新されないことです。

業務が変わったときに、誰が手順の修正を提案し、誰が確認して反映するかを決めておかないと、記載内容が実態からずれていきます。

古い手順が残っていれば、それを参照する複数のエージェントが、変更前の手順で処理を進める可能性があります。

二つ目は、配布先ごとに更新の反映がずれることです。

Skills APIのサンプルのような構成では、各エージェントは、配布された時点のスキルを参照します。

APIには、前回取得時との変更を確認するための値（version_id）があります。

同期処理ではこの値を比較できますが、内容の妥当性や承認の有無、各エージェントでの読み込みまで示すものではありません。

配布した版と、利用側での適用状況を対応づけて確認します。

同期の実行間隔、失敗時や配布対象から外れた場合の処理、同期先で直接編集した場合の扱いは、採用する同期処理と利用側の設定で確認します。

私たちは、同期処理が成功したことに加え、利用するエージェントがどの版を読み込んでいるかまで確認できるようにしておくことを勧めます。

三つ目は、使わなくなった内容が、現行の手順として参照され続けることです。

ここで「失効」とひとまとめにせず、内容の確認期限が切れること、古い手順を業務で使わなくすること、接続のアクセス権を取り消すことを、分けて考えます。

ヘルプには、確認済みとして扱う期限が切れると、オーナーへ通知されると記載されています。

一方、その期限切れだけで、エージェントによる閲覧や利用を自動的に止めるとは説明されていません。

ヘルプ「Delete & restore content」によれば、アーカイブしたページもリンクから開けるため、アーカイブはアクセスを禁止することとも同じではありません。

廃止した手順を記録として残すこと自体は問題ではありません。

記録として残す場合は、現在有効な内容と区別し、エージェントが参照・配布する対象からどう外すかを決めます。

Notion内だけでなく、GitHubなどへ配布済みのコピーについても、利用停止や差し替えが反映されたかを確認します。

担当者の退職や異動の際には、その人が管理していた手順や例外の引き継ぎ先と、それが引き続き有効かどうかを確認します。

変更履歴は、確認の材料として使う

リリースノートによれば、強化されたバージョン履歴では、ページとデータベースにまたがって、変更箇所の強調表示、データベースの変更内容、誰が変更したかが分かり、以前の版へ戻すこともできます。

ヘルプでは、以前の版へ戻す前に、何が影響を受けるかを確かめられることも説明されています。

変更履歴は、誰が何を変えたかを確認する材料になります。

Notion上で編集した内容を、エージェントへ配布・適用する前の確認にも、問題が起きた後の追跡にも使えます。

ただし、履歴があるだけでは、その内容が現在の業務に照らして妥当とまでは確認できません。

私たちは、変更履歴を、変更理由や確認・承認の記録と対応づけ、何の業務に適用する変更かを追えるようにすることを勧めます。

また、Notion上の版を戻すことと、配布済みの手順や、すでに実行された処理を元へ戻すことは別です。

版を戻した後は、配布先へ反映されたかも確認します。

接続の見直しは、誰の権限で何ができるかまで確かめる

リリースノートが挙げる「誰がどのAIツールを接続したか」「最後にいつ使われたか」「特定の人の接続だけを取り消せるか」は、運用に直結する部分だと私たちは考えます。

ただし、一覧に含まれる接続の範囲と、取り消しの効果を確認する必要があります。

管理APIの資料によれば、接続の一覧は、メンバーがMCPクライアントからNotionへつなぐOAuth接続が対象で、ワークスペース所有の内部接続は含まれません。

この一覧を、すべてのデータアクセス経路の台帳として扱わないことが大切です。

同じく管理APIの資料では、接続を取り消すとそのメンバーの接続は切れるものの、ワークスペースの方針が許していれば、再び接続できると説明されています。

退職や異動の際は、接続の解除に加え、その人が再接続できる条件や、変更後の業務で必要なアクセス範囲を確認します。

利用履歴が古いことだけで不要と判断せず、利用目的と今後の予定も確かめます。

Notionへの新たなアクセスを止めることと、すでにGitHubなどへ取得したファイルをどう扱うかも、別に確認する必要があります。

MCPの接続を取り消すことで、配布済みのファイルまで消えるという説明は、今回の資料には見当たりませんでした。

また、Notion MCPは、接続した利用者の権限で読み書きする仕組みです。

そのため、「エージェントA」という名前だけでなく、どの利用者や認証情報で接続し、何を読めて何を変更できるかを確認します。

公式の「Security best practices」は、接続したクライアントが、Notionから取得した内容をNotionの外のシステムへ送る可能性にも注意を促しています。

Notion側で見える範囲だけでなく、接続先のAIツールが、取得した情報をどう扱うかも確認しておきます。

業務知識・手順と配布先の管理表（一例）

以下は、業務知識や手順をエージェントに参照させるときに、MIFが提案する管理項目の例です。

Notionの設定項目をそのまま示したものではなく、自社の業務、適用される規則、リスクに合わせて具体化するための整理表です。

決めること	問い	設定・記録・運用先の例
置き場と正本	文書・手順の正本はどれか。対象業務と適用範囲はどこまでか	業務知識・スキルの置き場、正本の記録
更新責任者	内容を維持する担当者と、必要な変更を承認する担当者は誰か。兼務する場合も役割を分けて記録しているか	ページのオーナー設定、担当の割り当て
見直しの契機	何が起きたら見直すか。次に内容を確認する期限をいつにするか	確認期限と通知、社内の運用ルール
配布・適用状況	どこへ配布したか。配布した版、同期日時と結果、利用側で適用を確かめた方法は何か	同期処理の記録、配布先の管理
利用停止と保管	利用を終える条件は何か。参照・配布対象から外す方法、配布先の差し替え、履歴として何を残すか	アーカイブや権限の設定、配布先の更新
アクセスと操作の範囲	どの利用者・認証情報で接続し、何を読めて何を変更できるか	置き場の権限設定、列権限、接続先側の制限
接続の棚卸し	誰がどのツールを接続しているか。最終利用日、利用目的、今後の利用予定を踏まえ、いつ見直すか。再接続の条件はどうするか	管理者向けの接続一覧、接続できるクライアントの制限、社内の運用ルール
変更の確認	重要な変更を利用対象へ反映する前に、何を確認するか。エージェントが更新した内容を誰が確かめるか	変更履歴、承認の運用

決めた担当者や条件は、利用できる設定・記録・通知へ反映し、実際に機能しているかを確認します。

まとめ

MIFは、エージェントが参照する業務知識や手順について、正本、管理担当者、利用を認めた版を明確にすることを重視しています。

更新した内容が配布先へ届いているか、廃止した手順が利用対象から外れているか、接続するツールの権限が現在の業務に合っているかを、継続的に確認します。

担当者や確認期限を管理する製品機能を活用しながら、会社として決めた条件を設定と運用へ反映します。

エージェントやモデルを替える場合も、必要な情報を参照できることに加え、想定した手順と結果になるかを確認します。

AIの回答や作業の質は、モデルの性能に加え、参照する業務知識の正確さや管理状況にも左右されると、私たちは考えています。

情報確認について

本記事は、Notionのリリースノート「Notion 3.8: Context for your agents」（2026年10月13日）、Notionのブログ「A skills library for every agent」（2026年9月17日）、Notionの開発者向けドキュメント「Agent Skills API」「Notion MCP」「Security best practices」、管理APIの接続一覧・接続取り消しの各ページ、ヘルプセンターの「Wikis & verified pages」「Notion MCP」「Delete & restore content」を主要な参照元として、2026年10月21日確認時点の情報をもとに作成しています。

製品機能や提供条件に関する記述は、Notionの公表資料に基づいています。

MIFが実際の動作や、エージェントを切り替えたときの効果を独立に検証したものではありません。

業務知識や手順がずれる場面の整理、管理表の項目、運用の提案は、MIFの見解と考察です。

機能、提供範囲、利用条件は変更される可能性があります。

導入時にはNotionの最新の公式情報で条件をご確認ください。