取ってくる道具に、
考えさせない。

Instagramのインサイト、Meta広告の数字、GA4。この辺りを、AIが自分で取りに行ける形にしてある。MCPという仕組みで、私たちのデータに口を開けている。数字を人が集めて貼り付ける工程が、まるごと無くなった。

作ってみて分かったのは、この口をどこまで賢くするかが、そのまま設計の分かれ目になるということだった。

取ってくるだけの口にする

こういう口を作るとなると、便利にしたくなる。せっかくデータに触れるのだから、合計まで出しておこう、前月比も付けておこう、と。

私たちのMCPは、計算を一切しない。ツールの説明文にも、そう書いてある。合計も、比率も、前期比も返さない。返すのは、取ってきた生の値だけだ。

理由は2つある。

1つは役割の話だ。同じ「保存率」でも、分母に何を置くかは案件ごとに違う。アカウント全体のリーチで割るのか、その月の投稿リーチの合計で割るのか。どちらが正しいという話ではなく、案件ごとに決めてある。それを取得の口の側に埋め込むと、返ってきた数字がどの定義で出たものなのか、後から追えなくなる。原料を出すはずのものが、解釈を持ってしまう。

前期比も同じだ。先月と今月を並べるとき、配信が止まっていた日が片方に入っていれば、その比較は成立しない。稼働日数を揃えてから比べるのか、揃えずに総量で見るのか。ここを決めるのは、その月に何があったかを知っている側の仕事になる。取得の口が気を利かせて前期比まで返すと、その判断が済んだことになってしまう。数字は出ているのに、誰も揃えていない。

以前、AIの答えを答えとして受け取らず、素材として扱っていると書いた。素材として扱うと決めた以上、素材を出す側が先に噛んでいては話が合わない。

原料を出す口に判断を持たせると、その口はもう原料を出す口ではなくなる。

2つめはコストの話になる。サーバーの側で集計や要約までやろうとすると、その処理のためにサーバーがLLMを呼ぶことになる。呼べば、そこで料金が発生する。返ってきたものを受け取るAIの側でも、また料金が発生する。1回のレポートに、二重に払う形になる。生の値をそのまま渡してしまえば、計算するのは受け取った側の1回で済む。

順番としては、役割の方が先にあった。コストは、その線が正しいことを後から裏付けた形になる。

取得の口が、権限の口も兼ねていた

計算は混ぜなかった。ただ、別のものが混ざっていた。

ストーリーズは24時間で消える。だから一定間隔で取りに行って保存する処理を、サーバーの定時実行として動かしている。これが、あるときから毎回失敗するようになった。

原因は、定時実行が、AIから呼ばれるためのツールをそのまま呼んでいたことだった。そのツールの中には、呼んだ相手が誰かを確かめる処理が入っている。どこからのアクセスかを見て、見せてよい範囲を判定する。AIから呼ばれるときは、その情報が付いてくる。定時実行には付いてこない。誰でもないので、確かめる処理がそこで止まる。

この判定自体は必要なものだ。1つのサーバーで複数の会社のデータを扱っている以上、どのURLから来たのかで見える範囲を変えないと成り立たない。問題は、その判定が取得の内側に置かれていたことだった。取得を使いたいだけの処理まで、判定を通らないと先へ進めない。

取ってくる仕事と、見せてよいかを決める仕事が、同じ関数の中で一緒になっていた。取ってくる部分だけを別の関数として切り出して、定時実行はそちらを呼ぶようにした。

計算を混ぜないと決めておきながら、同じ口に権限の判定が入っていた。混ぜないというのは、思っているより細かい単位の話だった。

止まっていたことに、2日気づかなかった

この失敗に気づくまで、2日かかった。

その間、ストーリーズは取れていない。24時間で消えるものなので、2日分はもう戻らない。エラー自体はログに残っていた。ただ、こちらに届く仕組みがなかった。動いていないことは、放っておくと誰からも報告されない。

以前、AIが止まらなくなったせいで、指示の穴が後からしか見つからなくなったと書いた。あれと形は逆で、こちらは動くはずのものが黙って止まっていた。ただ、気づけなかった理由は同じところにある。動いていることを確かめる手段を、どちらも持っていなかった。

止まったことが分かるのは、止まっていない記録が残っているときだけだ。

今は、保存したストーリーズを返すツールの中に、実行ごとの成否を含めてある。取りに行った記録そのものを、データとして見に行ける。これも計算はしない。成功したか失敗したかを、そのまま並べて返すだけだ。

だから、渡せる形になった

判断を持たない口にしておくと、後から効いてくることがある。誰に何を見せるかを、機械的に切れるようになる。

私たちのサーバーは、1つの本体で自社用とクライアント用を兼ねている。分けているのはURLだけだ。URLごとに、見えるアカウントと広告アカウントの範囲が決めてある。自社用のURLからは権限をもらった全部が見え、クライアントに渡すURLからは、その会社の分しか見えない。

これが成立するのは、口の側に解釈がないからだと思う。取得の口が数字の読み方まで持っていたら、渡す相手ごとに読み方を出し分けることになる。URLで範囲を切るだけでは済まなくなる。

権限の設定そのものも、既存に触らずに足せる形にしてある。今入っている設定の中身は、こちらからは読み出せない。それでも、空いている場所に、このテナントにこの範囲を足す、と書けば、同じ名前のところへ畳み込まれる。開けられないものを開けずに、権限だけ増やせる。

読めないものを前提に組むのは、最初は不便に思えた。ただ、開けないと足せない構造にしていたら、権限を1つ増やすたびに、今動いているものを開いて書き直すことになる。開けずに足せるということは、既存の設定を壊しようがないということでもある。

実際に、外部への配布を始めている。渡しているのはURLが1本だけで、相手の側で用意するものはない。

分析の型は、この口の外側に置いてある。何をどう見るかは案件ごとに違っていて、そこは業務を分かっていないと決められません。私たちがクライアントの現場に入っているのは、その型が外からでは書けないからです。