Notionカスタムエージェントはどの手順書を根拠にする？DBプロパティ設計で検証

こんにちは、運用支援チームのkeitaです。

前回、社内Wikiだけではもったいない。Notionエージェントで会社の仕事はどこまで変わる？という記事で、エージェントに業務を任せる前に「正本・責任者・参照範囲」を決めておくのがおすすめだと書きました。ただ、あのときの話は設計として筋が通っているというだけで、実際にNotionでそう動くかを確かめ終えていたわけではありません。

3つのうち、まず引っかかるのが「正本」です。社内の手順書は、改訂のたびに旧版が残ります。都度アーカイブしていれば残りませんが、履歴として残しておきたいこともありますし、新版を出してから旧版を片づけるまでには時間差も生まれます。フォルダを分けたつもりでも、検索には両方出てきます。人が見れば日付を確かめて新しいほうを開きますが、AIエージェントが同じ判断をしてくれるとは限りません。同じような状態の会社は、少なくないと思います。

そこで、検証用のデータベースとエージェントを用意して、実際に手を動かして確かめました。この記事では、

• 状態プロパティは、指示文に書かなくても効くのか
• 効くとしたら、何が効いているのか
• 期限切れの警告は、勝手に出るのか

の3点を扱います。

先に一番の学びを書いておくと、効いていたのはプロパティがあること自体ではなく、「正本」「旧版」という値の言葉のほうでした。ラベルを記号に変えた途端、選別は消えます。

検証の組み立て

確かめたいのは「状態や日付をプロパティで持たせると、エージェントが古い情報を避けるのか」です。そのためには、答えが事前に分かっていて、外したら外したと分かる質問が必要になります。適当に話しかけて、それらしい答えが返ってきたから大丈夫、では記事に書ける結論になりません。

この条件を満たすように、組み立てはこうしました。

1. ナレッジDBを作る

今回の検証用に、社内に実際にある手順書7件のコピーを入れたデータベースを用意しました。

このデータベースに持たせたプロパティは、次の6つです。

7件それぞれの状態と次回確認日は、次のようにしました。検証したのは2026年9月なので、次回確認日がそれより前のものが期限切れです。

①と②の手順書は本文がほぼ同一なので、内容では区別できません。どちらを根拠にするかは、状態と日付だけで決まります。

2. エージェントを2体作る

今回、指示文だけが違う2体のエージェントを用意しました。

1体だけで検証すると、正本を根拠にしたとしても、それが指示文のおかげなのかデータベースの設計のおかげなのか区別できません。違いを指示文だけにしておくことで、差が出たときも出なかったときも、指示文が原因かどうかを判断できます。

• A（指示なし）

社内の手順書についての質問に答えてください。

• B（正本＋期限）

社内の手順書についての質問に答えてください。
状態が「正本」のページだけを根拠にしてください。「旧版」「検討中」「廃止」のページは根拠に使わないでください。
次回確認日が今日より前のページを根拠にした場合は、その情報が古い可能性があることを回答に明記してください。

Bの1行目はAと全く同じになっています。

指示を「足しただけ」にしておかないと、結果が変わったときに言い回しの差なのか設計の差なのか分からなくなってしまうからです。

エージェント2体でそろえた設定は、次の3つです。

• 参照範囲：検証用DBのみ
• Webアクセス：オフ
• モデル：Claude Sonnet 5（推論レベルHigh）

Webアクセスを切っておくのが重要で、オンのままだと社内文書に書いていないことをWebで補ってしまい、後述の「答えられないはずの質問」が測れなくなります。

3. 質問の投げ方を決める

違いを指示文だけにするため、投げる質問もAとBで同じにしました。質問文は事前に決めておき、1問ごとに新しいチャットで投げています。同じチャットで続けてしまうと、これまでのやりとりが次の答えに影響してしまうからです。

もうひとつ気をつけたのが、聞く順番です。

最初の質問の中で「根拠にしたページの状態も教えて」と書くと、状態プロパティが大事だとこちらが教えることになります。そこで、1回目は手順書の中身についてだけ質問し、答えが返ってきてから、2回目に根拠にしたページの「状態」「最終確認日」「次回確認日」を確認する質問を投げるようにしました。

どのページを根拠にするか

まず見たのは、同じことが書かれた複数のページがあるときに、エージェントがどれを根拠に選ぶのかです。ここから4つの角度で確かめていきます。

指示していないのに、正本だけを根拠にした

まず、さきほど触れた本文がほぼ同一の2つの手順書から答えられる質問を投げました。答えは必ず合うので、見るのは出典だけです。

結果は、A・Bとも3回ずつ、計6回すべてで正本側のページだけを根拠に挙げました。

ここでの「根拠に挙げた」は、回答の出典として示したページのことです。旧版が検索から漏れていたという意味ではありません。後述しますが、旧版を読んだうえで「根拠には使わない」と判断していると分かる回答もありました。

ここで想定外だったのは、AとBで差がつかなかったことです。Aの指示文は「社内の手順書についての質問に答えてください。」の1行だけで、正本を優先しろとは書いていません。それでもBと同じ動きをしました。

つまり、正本が選ばれている理由は指示文ではない、ということになります。

効いていたのは状態で、日付ではなかった

ただ、この時点では理由が2つ考えられます。状態プロパティを見ているのか、単に日付が新しいほうを選んでいるだけなのか。いまの配置だと「正本＝日付も新しい」と両方が同じ方向を向いているので、区別がつきません。

そこで、日付は動かさず、2つの手順書の状態だけを入れ替えました。

状態を入れ替えてから同じ質問を投げた結果、A・Bとも2回ずつ、計4回すべてで根拠にしたページが手順書①に切り替わりました。

これで「たまたま新しいほうを選んでいた」という可能性が消え、根拠の選択を決めているのは状態プロパティだと分かりました。

ついでに、このときBのエージェントだけが「次回確認日は本日より前のため、情報が古い可能性があります」と回答に付け加えました。同じ期限切れページを根拠にしたAのエージェントは、一言も触れません。Bの指示文に含めた期限について、ちゃんと効いていました。

エージェントは、値に書かれた言葉を読んでいる

ここまでの検証でエージェントの回答を見ていて、ひとつ気になったことがありました。効いているのは本当に「プロパティという構造」なのか、それとも「正本」「旧版」という言葉そのものの意味なのか、という点です。

そこで、プロパティ名や値などを、読んで意味が伝わらない言葉に変えてみました。

• プロパティ名：状態 → ラベル
• 値：正本 → X1、旧版 → X2
• プロパティの説明文も削除

この状態でAのエージェントに同じ質問を2回投げたところ、どちらの回答も2つの手順書を根拠に挙げていました。1回目は回答の中でこう書いています。

両手順書とも記載があり、判断基準は同じです。

その結果、それまでできていた手順書の選別が消えました。

「正本」「旧版」のときは10回中10回で1件だけを根拠にしていたのが、「X1」「X2」にしただけで両方を並べるようになる。エージェントはプロパティを構造として見ているのではなく、そこに書かれた言葉の意味を読んでいるということです。

これは設計として、それなりに大きい話だと思っています。

これらの検証結果から、値の名前が読んで分かる言葉になっていれば、どのページを使うかは指示文に書かなくても選んでくれると思いました。ただ、すでに運用しているデータベースだと、値の名前をいまさら変えるのが難しいこともあると思います。その場合は指示文のほうで補うほうが、修正は少なく済みます。

効いているのは「日本語であること」ではなく「エージェントが読んで意味が取れること」だと考えています。ですので、英語のラベルでも同じように通用するのではないかと思いますが、今回はそこまで確かめていません。

実際に組むときは使う予定のラベルで一度試してから設計を固めるのがおすすめです。

これから作るのであれば、値の名前を決める段階で「エージェントが読んで意味が分かるか」を見ておくと、あとで指示文を書き足さずに済みます。

矛盾する2つの版を並べても、正本を採った

もう1つ試したのが、意図的に矛盾を作る質問です。本文がほぼ同一だった2ページのうち、旧版側の判断基準の数値だけを書き換えて、正本と食い違う状態にしました。

結果は、A・Bとも正本側の数値を採用。旧版の数値には引っかかりませんでした。

ここで面白かったのは、聞いてもいないのにAがこう書いたことです。

参考として、汎用版の手順書は状態が「旧版」のため根拠としては使用していません。

指示文が1行しかないAのほうが、旧版を除外した理由まで説明しました。Bは正本を根拠にした事実だけを述べて、旧版には触れていません。指示があるほうが説明が丁寧になるとは限らないというのは、これも意外な結果でした。

期限切れの警告は、指示しないと出ない

次に、期限切れのページにしか答えが書かれていない質問を用意しました。答えが合うかではなく、古い可能性に触れるかを見ます。

あわせて、期限内のページが答える質問を1問だけ入れました。これがないと結果を誤読します。もし全部の回答に警告が付くなら、日付を見ているのではなく無差別に注意書きを足しているだけ、という可能性が残るからです。

答えはどちらのパターンもA・B両方正解でした。違うのは警告文だけです。

Bのエージェントが回答したときの、警告文の書き方はこうでした。

なお、このページの次回確認日（2026-06-30）は本日より前のため、情報が古い可能性があります。

そしてパターン②（期限内）では、警告を出さずに「次回確認日は2027-07-31で今日より先のため、情報が古い可能性の注記は不要です」と書いていました。日付を見て判断していることが、この対照で確認できました。

ここは状態プロパティのときと違って、指示文に書かないと警告は出ません。日付を持たせるだけでは足りず、「期限を過ぎていたら言え」と書いて初めて機能する、という切り分けになりました。

書かれていないことを聞いても、作り話はしなかった

最後に、7件の手順書のどこにも書かれていないことを2問聞きました。

その結果、A・Bとも作り話をすることなく「見つかりませんでした」と答え、DBに入っている手順書を列挙したうえで範囲外だと説明しました。

今回、どちらのエージェントにも「書かれていないことは答えない」という指示は入れていません。それでも答えを作りませんでした。

ただし、この結果を「参照範囲を絞ったからだ」と言い切ることはできません。AもBも参照範囲を検証用DBだけにして、Webアクセスも切った状態で試していて、参照範囲を絞っていない状態と比べていないためです。

実際の運用では、DBだけでなくWebも参照させたい場面が出てくると思います。その場合は「まずDBの情報を使い、そこで明確な答えが得られないときだけWebを参照する」といった優先順位を、指示文に書いておくのが良さそうです。

かかったクレジットは、54往復で542ポイント

実務で気になるのは実際の挙動だけでなくコストに関する情報だと思うので、実測を載せておきます。

条件は、参照先が7ページの小さなDB1つ、Claude Sonnet 5・推論レベルHigh、Webアクセスなしです。1往復あたり約10クレジットポイントで、最初の2往復で出た数字が最後まで変わりませんでした。指示文の長さによる差はほぼありません。

表を見て分かるように、Aのほうが消費量が多くなりました。指示で参照範囲が絞られているぶんBのほうが少ない手数で答えているのではないかと思い、回答の処理ステップ数も見てみました。

ただ、こちらは質問によってばらばらでした。Aが8ステップかけた質問にBは4ステップで答えているものもあれば、別の質問ではAの9ステップに対してBが11ステップかかっているものもありました。

これらの結果から、指示で範囲を絞ればステップが減る、とは言えなさそうです。

この検証で分かっていないこと

ここまで検証の結果を書いてきましたが、これですべてが分かったわけではありません。

• 試したモデルは1つだけです。Claude Sonnet 5・推論レベルHighでの結果で、他のモデルや推論レベルで同じになるかは確かめていません
• 日本語のラベルしか試していません。「正本／旧版」は効いて「X1／X2」は効きませんでしたが、その中間、たとえば「Active／Deprecated」のような英語ラベルがどうなるかは分かりません
• 7ページの小さなDBでの結果です。数百ページのDBで、検索で拾われる候補が増えたときに同じ挙動になるかは別の話です
• エージェントは指示していないことをします。Bは期限内のページでも「期限切れではありません」と毎回報告しましたし、ある質問では「最新の運用ルールは責任者にご確認ください」と、書いていない対処法まで足してきました。1問だけ英語で回答が返ってきたこともあります。指示文どおりに動くというより、指示文を汲んで振る舞うという理解のほうが近そうです

いずれも2026年9月時点で試した結果です。この領域は更新が速いので、検討するときは最新の条件をご確認ください。

まとめ

今回の検証で分かったことを整理すると、こうなります。

• 状態プロパティは、指示文なしで効きます。ただし効いているのは構造ではなく、値に書かれた言葉の意味です
• 値のラベルは、読んで分かる言葉にしてください。「1／2／3」のように、どれを使うべきか読み取れない値では期待できません
• 期限切れの警告は、指示文に書かないと出ません。日付を持たせるだけでは足りません
• 書かれていないことを聞いても、作り話はしませんでした。「書かれていないことは答えない」と書かなくても大丈夫でした

前回の記事で「決めごとを先に用意しておくのが近道です」と書きましたが、今回それが一段具体的になりました。決めごとは、エージェントに読める言葉で書く。これが抜けていると、プロパティを整えたつもりでも伝わりません。

一方で、鮮度の判断は勝手にはやってくれません。ここは指示文を1行足すだけなので、ナレッジDBにエージェントをつなぐなら最初から入れておくのがおすすめです。

まずは7ページでも試せます。本番のDBをコピーして、状態と次回確認日を入れて、同じ質問を2体に投げてみる。自社のナレッジでどう動くかは、1時間ほどで確かめられます。

関連情報

• Notion Agent公式ヘルプ
• Custom Agents公式ヘルプ
• Notionクレジットとカスタムエージェントの費用（公式ヘルプ）
• AIモデルとメンバーのクレジット利用の管理（公式ヘルプ）