AIにWeb改善を任せたあと、何をもって「完了」とするか

AIにWebサイトの改善を任せると、診断は速く出てくる。問題は、実装したあとに起きる。変更が本当に入ったのか、その後に検索や問い合わせの数字がどう動いたのかが、依頼した側の手元に戻ってこないことがある。エージェントが「PASS」と報告していても、それは外の世界で何かが起きた証拠にはならない。

この記事は、Netsujo SIGNALとAgent Role Contracts(ARC)の2026年10月の改善記録だ。結論は、AIへの委任を顧客の成果につなげるには、目的・権限・作業の実施・観測・効果を分けて受け入れる、ということである。技術的な観測は10月27日のもの、mergeと本番の状況は10月28日8時20分(JST)時点のものだ。顧客への影響や、顧客をまたいだ学習への同意を主張するものではない。

SIGNALが目指すもの

Netsujo SIGNALは、企業サイトの購入検討者が、見つけ、理解し、比較し、自分に合うかを判断して、問い合わせや注文に進めるようにするためのサービスだ。診断はコードレベルまで踏み込み、実装できる変更仕様(ChangeSpec)まで出す。SEOやAIOは、この目的のための手段だ。詳しくはSIGNALのサービスページにある。

1. 目的を先に固定する

最初に分けるのは目的だ。「検索順位を上げる」と「比較検討中の人が自分に合うと判断できる」は、同じ作業とは限らない。SIGNALはワークスペースに承認済みの目的を持たせ、検出した課題を結びつけて保存する。10月27日、自社の2サイトで本番のget_workspace(読み取り専用)を呼び、承認済みの目的と保存済みの課題が読めることを確認した。

2. 権限は別の文書で見る

ARCは、役割・書き込み範囲・引き継ぎ・レビューの宣言を、実行の前にオフラインで検査する。v1.0.0は公開リポジトリで安定版として公開している。ここで注意したいのは、PASSの範囲だ。PASSは宣言に矛盾がないことしか示さない。実行者が誰か、ツールの権限が実際にどう設定されているか、現実に何が起きたかは証明しない。詳細はPASSの意味を扱った記事に譲る。

ARCの10月27日の動きは4つある。PR #81で、オフラインの合成ケース18件の比較をmergeした。これは18社の顧客事例ではなく、人工的に作ったケースだ。PR #82では、タスク権限の保証についての設計をmergeした。これは設計であって、数学的に証明されたものではない。PR #83は外部からの意見を受けた統合設計の見直しで、これも設計のみをmergeした。PR #84は、承認の受領書に付いたEd25519署名と対象の現在性を検証する処理を、範囲を絞ってオフラインのテストで確かめた。実行時の権限を与えるものではない。

3. 作業の実施は、報告と別に観測する

ここが今回いちばん手応えのあった部分だ。ローカルの未公開コミット(88220a9、公開リポジトリにはmergeしていない)で、架空の50バイトの「読み取り→送信」を、ループバックの受信側に対して試した。正常時は204が返る。受信側がすでに1件を記録したあとにHTTP 404が返る場合を作り、さらに送信を拒否する場合も作った。同じ処理を再実行しても、1つのプロセス内では受信側の記録が重複しなかった。

これは、送信側の「失敗した」という報告と、受信側の「1件記録された」という事実がずれうることを小さく確かめたものだ。外部APIでの厳密な1回実行(exactly-once)を示すものではなく、ARCが本番で実行を強制している証拠でもない。ARCの実行時の仕組みがSIGNALに技術的に組み込まれている、ということも主張しない。持ち帰ったのは設計の考え方だけだ。報告と観測は別の行に書く。

4. 観測が戻ってきていない

SIGNALの本番を同じ日に確認したところ、実装が観測されたことを示す行と、成果が観測されたことを示す行が見つからなかった。これは「サイトが変わっていない」という証明ではない。変更が行われていても、SIGNAL側に記録が返っていないという意味だ。診断までは出るのに、そのあとが空白になっている。この空白が、今回いちばん直したい点だった。

続く改善は、SIGNALのPR #778に入っている。実装の報告・訂正・撤回、ポータルでの版を指定した受け入れ、計測の帰属、顧客ごとに閉じた学習が含まれる。このPRは、独立したコードレビューとCIを経て、10月27日23時53分(JST)にmergeされた。集計の#777も10月28日0時4分(JST)にmergeされ、両方を含む本番デプロイは10月28日8時19分(JST)に完了した。ただしデプロイの完了は、コードが本番に置かれたという意味にとどまる。観測を返すこの仕組みが本番で実際に動き、実装と成果の行が埋まるかどうかは、まだ確かめられていない。人による受け入れや、顧客が受け入れたという記録もない。

5. 効果は、最後に別に問う

実装が確認できても、検索の表示や問い合わせが増えたかは別の問いだ。実装した版と計測期間を結びつけないと、変化の理由を決められない。だから受け入れを分ける。目的は合っているか、権限は適切か、作業は行われたか、観測は返ってきたか、効果はあったか。1つが済んでも、残りが済んだことにはならない。

次にやること

SIGNAL側は、本番に置かれた#778と#777が実際に動くかを確かめ、本番の読み出しで実装と成果の行が埋まることを確認する。ARC側は、設計を証明やテストで裏づけられる範囲だけ進める。ARCとSIGNALは審査の原則を共有するが、技術的に統合されてはいない。確認できたことだけを公開する。

AIに改善を任せるなら、実装後に何が戻ってくるかを先に決めておくと、完了の基準が定まる。SIGNALの無料診断で現状を確認できる。ARCは公開リポジトリから試せる。