事業計画の前提に使った外部データの更新を毎月追って、前提のずれを知らせる

処理の起点を決める

毎月1日の朝に動かします。 Make のスケジュールには、一定間隔（分単位）、毎日1回、平日、週単位、月単位、日付の指定、オンデマンドがあるとされています。使うのは月単位（毎月の指定日）です。既定は15分ごとで、最小の間隔は契約プランによるとされていますが、月次ではこの下限は関係しません。

1つの設定に複数の実行時刻を入れられます。 50件を一度に流すとアクセスが集中するので、午前と午後に分けられます。また、詳細設定で開始日と終了日を指定できるとされており、計画の期間に合わせて自動で止められます。

毎月にするのは粒度の問題です。 四半期だと気づくのが遅く、毎週だと年1回しか動かない統計を50件も見続けることになります。前提ごとに周期を変えたい場合も、スケジュールは1つのままにし、台帳の確認の周期の列で対象行を絞ります。

入力データを集める

locator が、この台帳のいちばん大事な列です。 「ページのどこに書かれていたか」を、位置ではなく語で書きます。「上から3つ目の表」ではなく「『年度別の出荷実績』という見出しの表の、右端の列」と書きます。位置は作りが変わればずれますが、見出しの語はしばらく残ります。

計画側の数字そのものは入力に入れません。 plan_refs は「売上計画シート12行目（国内売上）」のような行の名前だけです。

データの取得方法を決める

台帳の読み取りは、Make のスプレッドシートのモジュールで足ります。取り出した行の配列は Iterator に渡します。 Iterator は配列を次々のバンドルに変えるモジュールで、各要素が1つのバンドルになるとされています。50行が50回の処理になります。

外部ページは、エージェントの側に取りに行かせます。tools 配列は関数・カスタム・名前空間といった種類の定義を並べる形で、Web検索は組み込みのツールとして用意されています。 自前の処理を呼ばせる場合は、種類・名前・説明・引数のJSONスキーマ・strict を書いた関数の定義を同じ配列に足します。

3行目を必ず保存してください。 指定したドメインの外を見ていないかを、後から確かめられます。

AIへ渡す前に整形する

1. 今月の対象行を絞る … 台帳の確認の周期の列を見て、今月に当たる行だけを残します
2. URLの生死を確かめる … Make のHTTPモジュールで先に叩きます。404の行はエージェントを呼びません
3. PDFの扱いを決める … PDFでしか公表されない行は、テキストにできるかを確かめます。できないものは手で見る行にします
4. 長いページを切る … 文脈の窓は128kまでです。年報のような資料は locator の語の周辺だけを渡します
5. 前回の根拠を添える … 同じ場所を見ているかの手がかりになります
6. 表記をそろえる規則を渡す … 単位、年度と暦年、全角の数字。そろえるのは受け取った後の処理で行い、AIには換算させません

2番目を省かないでください。 消えたページをエージェントに探させると、似た名前の別のページを開いて値を持ち帰ります。 いちばん気づきにくい誤りです。

AIに処理させる

させるのは、台帳の1行について「出どころを開き、いまの値と公表時期を取り、根拠を写す」ことだけです。

3行目がいちばん起きやすい失敗です。 「市場規模は3年で15％成長」としか書かれていないページを年率の前提と比べさせると、年5％弱に直した数字を返し、次の月には別の直し方をします。 単位や期間が違うものは ambiguous にします。

指示内容を固定する

あなたは、事業計画の前提に使った外部データが更新されていないかを確かめる担当です。
指定されたURLのページに書かれていることだけを見て答えてください。
ページに無いことを、知識や推測で補わないでください。

【今回確認する前提】
- 前提の名前:          {name}
- 計画で使った値:      {used_value} {unit}
- その値の公表時期:    {published_at}
- 出どころ:            {source_url}
- ページのどこにあるか:{locator}
- 前回、値を取った文字列: {last_evidence}

【やること】
1. 指定されたURLを開く。{allowed_domain} の外のページは見ない
2. {locator} を手がかりに、同じ性質の値がいま何になっているかを1つだけ取る
3. その値が公表された時期（年月または年度）を取る
4. 値を取った文字列を、画面にあるまま evidence に写す

【value_status の選び方】
- unchanged ... 公表時期も値も、前回と同じ
- updated ..... 新しい公表が出ている、または値が前回と違う
- unreadable .. ページは開けたが、その値が見つからない、数値として読めない
- ambiguous ... 同じ名前の値が複数あり、1つに決められない
                （年度が複数ある、速報値と確報値が並ぶ、単位が違う）
迷ったときに unchanged を選ばないでください。

【厳守事項】
- 値の計算をしないでください。年率への直し、単位の換算、複数年の平均を
  とらないでください。換算しないと比べられないものは ambiguous です。
- 出どころを乗り換えないでください。指定したURLに値が無いとき、他のサイトの
  似た数字を代わりに取らず、unreadable にしてください。
- 計画をどう直すべきかも、影響の大きさも書かないでください。
- 値が前回と同じでも、公表時期が新しくなっていれば updated です。
- ページが見つからない、別のページに移っている場合は、値を取らずに
  source_status に gone または moved を入れ、note に移動先のURLを書いて
  ください。それらしいURLを組み立てないでください。
- evidence は、読みやすく直さずにそのまま写してください。

「公表時期が新しければ値が同じでも updated」を書いておかないと、見落とします。 版が上がっても、その年の値が据え置かれることはあります。そこで「変わっていない」と出すと、次の版で数字が動いたときに前提のずれが一気に表に出ます。

出力形式を固定する

Structured Outputs で、次の形のJSONを受け取ります。 text.format に種類（json_schema）、strict、schema、名前を指定する形とされています。

{
  "name": "assumption_check",
  "strict": true,
  "schema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["... properties の9項目すべてを並べる ..."],
    "properties": {
      "assumption_id":  { "type": "string" },
      "source_status":  { "type": "string", "enum": ["reachable", "moved", "gone"] },
      "value_status":   { "type": "string",
                          "enum": ["unchanged", "updated", "unreadable", "ambiguous"] },
      "new_value":      { "type": ["number", "null"] },
      "new_value_text": { "type": "string" },
      "unit":           { "type": "string" },
      "published_at":   { "type": "string" },
      "evidence":       { "type": "string" },
      "note":           { "type": "string" }
    }
  }
}

strict を真にするときの決まりが3つあります。 additionalProperties を偽にすること、properties の項目をすべて required に並べること、任意の項目は型に null を足して表すこと（["number", "null"]）とされています。値が読めなかったときに new_value を空にできるのは、この書き方のおかげです。

new_value と new_value_text を分けるのは、書かれ方を残すためです。 前者は差を計算する数値、後者は「約1.2兆円」「1,234千戸」という表記そのものです。読み取れなければ前者は空のまま後者だけが残り、その行は人へ渡します。

安全上の理由で応じない場合は refusal の欄が返るとされています。 機械的に見分けて unreadable と同じ扱いにできます。

システムへ連携する

Array Aggregator で1つに戻してから集計します。 複数のバンドルを1つにまとめるモジュールで、まとめ先の構造やグループ分けを指定でき、空のときに後続の処理を止める選択肢があるとされています。この「空なら止める」が、そのまま知らせの制御になります。 幅を超えた行が無かった月は通知を送りません。

最後の行が、この構成の線引きです。 事実と効く先の名前までを人に渡し、そこで止めます。

人が確認する

人が開くのは、幅を超えた行と unreadable ／ ambiguous ／ gone の行だけです。 残りは確認日が進むだけで、一覧を眺める必要もありません。

1. gone と moved を先に見る … 消えたか移ったかを確かめ、台帳のURLを人が直します
2. unreadable の行の locator を見直す … 作りが変わったのか、前提そのものが公表されなくなったのかを分けます
3. 幅を超えた行の根拠を読む … evidence と公表時期を見て、本当に新しい版の値かを確かめます
4. 採るか待つかを決める … 新しい値を前提として採るか、次の版まで待つかを決めます
5. 計画を直すかを決める … plan_refs の行を見て、直す範囲を決めます。ここは月次の会議に持っていきます

4番目と5番目は別の決めごとです。 前提の値を更新することと、計画の数字を動かすことは同じではありません。前提だけ更新して計画は据え置く、という選択が最も多くなります。

目標は、50件をならして1件4分です。 幅を超える行が月に5件前後という想定で、それより多い月は、許容の幅が狭すぎます。

例外に対処する

上から3行目が、この構成でいちばん多い例外です。 AIの誤りではなく、相手のページが変わったという事実です。 直すのは locator で、プロンプトではありません。

記録を残す

• 各行の履歴（確認日、公表時期、値、value_status、source_status）
• 根拠にした文字列 … 次の月に「同じ場所を見ているか」を比べる材料です
• 参照した全URLの一覧（sources）と、引用の注記
• 差の計算の結果と、そのとき参照した許容の幅（幅は後から変わります）
• 人が判定を覆した記録 … どの行を、どちらに変えたか
• 確認できていない行の一覧 … 何日見に行けていないか

4つ目で「そのときの幅」を残すのは、幅を後から狭めるからです。 当時の幅が無いと、過去に知らせなかった理由が分からなくなります。

最後の行が、この構成の目的そのものです。 削減時間よりも、「見に行っていない前提が何件あるか」を毎月数えられることのほうが重要です。