下書き、監査ログ、それとも「つなぐな」：三つのプラットフォームの AI エージェント書き込み対応

この一年で、三つのプラットフォームが AI エージェントの書き込みを解放しました。三者とも同じ問いに答える必要がありました——エージェントが誤った値を書いたらどうなるのか——そして、本当に異なる三つの答えを出しています。

比較ページを作るためにドキュメントを読み、手元に三つの引用が残りました。個別に見れば平凡ですが、並べると面白い。三社とも間違っていません。違う層で問題を解いているだけで、自分の問題がどの層にあるかを知ることが、誤った仕組みを採用せずに済む方法です。

Sanity：既定で下書きへ

Sanity の Agent Actions は、コンテンツを生成・変換・翻訳するイベント駆動の API です。注目すべきはその既定値です。

既定では、Agent Actions が公開済みドキュメントを変更することはありません。公開済み ID を指定した場合、アクションは変更を加える前にまず下書きを作成します。

公開済みドキュメントに対して実行した場合、新しい値は「新規の下書きドキュメントに書き込まれ、公開してもらう必要があります」。

これは無効化できます（forcePublishedWrite: true、また liveEdit: true のスキーマは元からその挙動）。しかし安全な側が既定になっている——多くの製品がエージェントの書き込みを解放したやり方とは逆で、もっと評価されてよい設計です。

得られるもの：人が公開するまで、読者には何も届かない。

答えていないこと：その値が正しいかどうか。自信に満ちた誤った数値の入った下書きは、正しい下書きと見分けがつきません。

Notion：事後の監査ログ

Notion 3.6（2026 年 7 月）は External Agents を出し、最初の二つが Claude と Cursor です。「チーム全体で共有するボードからタスクを割り当て、同僚のように @ メンションし、動く様子を見る」。Custom Agents はスケジュールとトリガーで動き、AI Autofill がそれをデータベースに直接持ち込みます。

監督については、Enterprise プランにこれがあります。

監査ログには Custom Agent の活動が含まれ、エージェントがいつ実行され、何を変更し、誰が起動したかを確認できます。

実在する仕組みです。答えているのは誰がいつ変更したか。

答えていないのは、それが事実になってよかったのか——しかも最初の問いに答える時点で、書き込みは確定しています。

ここは少し留まる価値があります。監査ログは、書き込みが遅く、次に読むのが人間だった世界のために設計されました。エージェントは一分に 800 行を更新でき、次に読むのはたいてい次の実行、定時レポート、あるいは顧客が見るページです。人が気づく頃には、その誤った値は読まれ、要約され、判断に使われています。

「エージェントが何を変えたか見える」と「エージェントが何を変えるか制御できる」は、いつの間にか別の約束になりました。

Supabase：本番には向けるな

Supabase は「エージェント型ワークロードのために作られた完全な Postgres 開発者プラットフォーム」を掲げます——MCP サーバー、Agent Skills、すべての呼び出しに効く RLS。そしてエージェントに関する自社のエンジニアリング記事は、珍しく率直です。エージェントは、と彼らは書きます：

• 「公開スキーマで RLS ポリシーを飛ばす」
• security_invoker = true のないビューを作り、「これは RLS を静かにバイパスする」
• 「UPDATE には SELECT ポリシーが必要で、ないと更新は静かに 0 行を返す」ことを見落とす
• 「存在しない CLI コマンドを幻覚する」
• 「ドキュメントを完全に無視し、数か月古いかもしれない訓練データに頼る」

そして端的に、「エージェントはその点で怠惰である」。

結論は証拠から素直に導かれます。

Supabase MCP サーバーを本番データベースに接続することは強く推奨しません。

ローカルかステージングのみ、と。

妥当な助言であり、なぜ妥当なのかに注目する価値があります。先のリストをもう一度見てください。すべて正しさの失敗であり、それを捕まえることを期待されている仕組み——RLS——が管理するのは権限です。RLS は「この呼び出し元はこの行を書いてよいか」に答えますが、「その値は正しいか」には答えられません。完全に正しい権限を持つエージェントが自信を持って誤った数値を書けば、データベースのあらゆる検査を通過します。

エンジン層には他の答えが存在しない——だからこそ「本番から遠ざけよ」は逃げではなく誠実な推奨なのです。

三つの等級ではなく、三つの層

三者を並べると、ひとつの考えの三通りの実装ではないことが分かります。別々の層なのです。

プラットフォーム	ゲートの位置	単位	防げるもの
Sanity	公開の前	ドキュメントの版	未レビューのコンテンツが読者に届くこと
Notion	書き込みの後	セッション	帰属——誰がいつ何を実行したか
Supabase	接続の地点	環境	エージェントが本番に触れること自体

それぞれ、その製品の目的によく合っています。Sanity の終着点は読者なのでゲートは公開に、Notion の舞台は大半の編集が低リスクな共同作業空間なので仕組みは帰属に、Supabase はインフラなので使えるレバーは「誰が接続できるか」だけです。

そして三者が等しく残している隙間は同じものです。許可され、形式も正しく、しかし偽である書き込み。

どれが必要かの見分け方

三つの問いを順に。

1. 出力は読者に公開されるか。 そうなら公開ゲートが正しい仕組みで、Sanity の既定はまさにその形です。
2. 次に読むのは、横で見ていた本人か。 そうなら帰属で十分です。監査ログは実際に問われる質問に答えます。
3. 次に読むのは別のエージェント、レポート、アプリか。 ならどちらのゲートも助けになりません。下流が消費する前に値の真偽を評価するものが経路上に何もないからです。

三つめで不意を突かれます。誤った一行が四つのものに読まれた後で誰かが開くまで、最初の二つと同じに見えるからです。

それを埋めるもの：データのための pull request

開発者はすでにこのメンタルモデルを持っています。コードが直接 main に入ることはありません。pull request を通ります——何がどう変わるかを示す差分、作者、コメントできる場、承認、そしていつ現実になったかを記録するマージコミット。

**今日のエージェントによるデータ書き込みは、全員に main への直接 push 権限を渡しているのと同じです。**上記の三つのゲートはそれぞれ部分的な代替にすぎません——公開レビューはリリースブランチ、監査ログはレビュー工程のない git log、「本番につなぐな」はそもそも権限を与えないこと。

どれも pull request ではありません。データに当てはめると、こうなります。

Pull request	データ書き込みに適用すると
差分	どのフィールドが何から何へ変わるか
作者	どのエージェントが、どの根拠で提案したか
レビュー	値が事実になる前に人が見る（後ではなく）
マージコミット	いつ正式になり、誰が決めたか

同じ形は、エージェントが書くものだけでなく知っているものにも当てはまります——プロンプト、指示、再利用可能なスキルは、コードとまったく同じように drift し、まったく同じ処置から恩恵を受けます。

実際にどう見えるか

Busabase は三つめの選択肢です——書き込み経路が既定で pull request になるよう作られたワークスペース。MIT ライセンスでローカルに動くので、判断する最短路は読むことではなく動かすことです。

npx busabase server
# → http://localhost:15419/dashboard/local

サインアップもアカウントもクラウドも不要。組み込みの Postgres（PGlite）、ローカルファイルストレージ、そして最初から入っているデモコンテンツで起動します。

エージェントを向けて——MCP、Agent Skill、あるいは /api/v1 の OpenAPI——何かを書かせてみてください。届くのはこれです。

変更されたフィールドの変更前と変更後、どのエージェントが提案したか、使った出典、そしてコメントのスレッド。承認・修正要求・却下が選べます。承認された値は正式なものになり、提案者・レビュアー・コミットが紐づいたまま残ります。

正直な限界を二つ。レビューは影響度に比例します——低リスクの書き込みは速いままで、マージ権限のあるキーはそのまま通ります。そして、エージェントが書くもののうち検査に値するものが一つもないなら、この仕組み全体は不要なコストです。

---

開示：筆者は Busabase に関わっています。AI エージェントのためのオープンソースのデータベース兼ワークスペースで、三つめの道を取っています——重要な書き込みはフィールド単位の差分つき提案として届きます。各比較の詳細版は出典つきで公開しています：Notion との比較、Sanity との比較、Supabase との比較。いずれも相手のほうが優れている場面を明記しています。細工が透けて見える比較には価値がないからです。

出典：Sanity Agent Actions ドキュメント、Notion 3.6 リリースノート、Supabase — AI Agents Know About Supabase. They Don't Always Use It Right.。2026 年 9 月 21 日検証。三社とも更新は頻繁です。