官公庁と業界団体が毎月公表する統計を要約し、自社の市場に関わる動きと前月からの変化を経営企画の月次メモにまとめる

処理の起点を決める

毎朝の定時実行を起点にします。 統計の公表は日によってばらばらで、20本が月のあちこちに散らばっています。月末にまとめて処理すると、早い時期に公表された統計の確認が経営会議の直前に寄ります。 公表があった日のうちに系列ごとの文まで作っておけば、会議の前の週は確認と全体の要約だけになります。

毎朝の処理は、「統計の一覧」に載っている統計について、前日に更新があったかを確かめるところから始めます。 e-Stat に載っている統計は、統計表情報取得の updatedDate で前日の日付を指定して確かめます。更新がなければ、その日はそこで終わりです。

業界団体の統計は、担当者がファイルを置いたことを起点にします。 団体のページの形はそれぞれ違い、自動で見回るより、公表日に担当者が落として決まったフォルダに置くほうが確実です。 置かれたファイルは翌朝の処理で読みます。

経営会議の5営業日前に、その月の分をまとめた下書きを1つ作ります。 その時点で公表がまだの統計は「未公表」と書いて並べます。抜けていることが見える形にしておかないと、前月のメモの数字がそのまま残ります。

入力データを集める

質を決めるのは、「統計の一覧」の系列のコードと「自社の製品との関係の説明」の列です。 系列のコードが曖昧だと、季節調整値と原数値を取り違えます。関係の説明の列がないと、AIは系列の動きを自社の話につなげられず、どの系列も同じ重さの文になります。 「この系列は給湯器の新築向けの需要に先行する」のように、1行で書いておきます。

書き方の決まりは、2名の書き方をそろえるために作ります。 例えば「前年同月比で±5％を超えたら『大きく』と書く」「増減は前年同月比を先に、前月差を後に書く」と決めておけば、どちらが担当しても同じ書き方の文が出ます。

過去のメモは、「3か月続けて減少」のような続いている動きを書くために渡します。

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

e-Stat の値は、統計表のIDと系列のコードを指定して取ります。 すべての API でアプリケーションIDの指定が必須なので、IDは担当者個人ではなく部の管理にします。 出力は JSON を選び、Python でそのまま表にします。1回で取れる件数は既定で10万件で、超える場合は次の開始位置が返り、分けて取れるとされています。自社に関わる系列だけを指定すれば、この上限に当たることはまずありません。

業界団体のファイルは、団体ごとに「どのシートの、どの見出しの列を読むか」を決めておきます。 行の位置ではなく、見出しの文字で探すように書きます。品目の並びが変わっても、見出しが同じなら同じ値を拾えます。見出しが見つからないときは、推測で近い行を拾わずに止めます（「例外処理」）。

PDFでしか出ない団体の統計は、表の部分を担当者が CSV にしてから置きます。 OpenAI API はPDFを入力として受け取れ、テキストとページの画像の両方をモデルに渡すとされていますが、数字の読み取りまでAIに任せると、計算をプログラムに分けた意味がなくなります。 数字は人かプログラムが取り、AIには取った後の表を渡します。

AIへ渡す前に整形する

1. 3時点の値を並べる … 系列ごとに今月・前月・前年同月の値を1行にします。前年同月の値がない系列（新しい系列など）は空欄のまま残します
2. 前月差と前年同月比を計算する … Python で計算し、小数第1位までにそろえます。計算はここだけで行います
3. 改定を見つける … 今回取った「前月の値」と、先月の処理で取った「今月の値」を比べます。違っていれば、改定ありの印を付けます
4. 季節調整の区分を確かめる … 系列のコードが季節調整値なら前月差を、原数値なら前年同月比を主に使う、と一覧の決まりに従って印を付けます
5. 基準の改定を確かめる … メタ情報の時点や単位が先月と違えば、系列がつながらない可能性があるとして印を付けます
6. 公表元の注記を短くする … 統計表の注記と公表時の概要から、速報・確報、改定、調査方法の変更に関わる文だけを残します
7. 未公表の系列を並べる … その月にまだ公表のない系列は、「未公表」として表に残します

3番目と5番目を軽く見ないでください。 第3章の（c）は、ここを人が毎月思い出して確かめていたことで起きていました。プログラムが毎回同じ比較をすれば、思い出す必要がありません。 印が付いた系列は、AIの文が出ても担当者が必ず見ます。

AIに処理させる

させるのは、計算済みの表と注記を読んで、系列ごとの事実の文と、注意書きを書くことだけです。

いちばん大事なのは、表にない数字を書かせないことです。 文の中の数字は、計算済みの表にある数字だけにします。「前年同月比で約1割の増加」と丸めて言い換えさせることも禁じます。 丸めた数字は照合で一致せず、確認の手間が増えます。

2行目がいちばん起きやすい失敗です。 統計の動きを要約させると、もっともらしい理由を添えてきます。会議でその理由が独り歩きすると、根拠を問われたときに答えられません。 理由を書くのは、公表元の概要にそう書かれているときだけにします。

指示内容を固定する

あなたは住宅設備機器メーカーの経営企画部で、毎月の経営会議に出す
「市場の動き」のメモの下書きを書く立場です。
渡す表の数字と注記だけを使って書いてください。推測で補わないでください。

【やること】
系列ごとに、次の項目を書いてください。
1. movement ..... 動きの向きと大きさを1文で
2. trend ........ 過去のメモと比べて同じ向きが続いていれば、その月数を1文で
3. relation ..... 「自社との関係」の欄の範囲で、自社の製品とのつながりを1文で
4. source_note .. 公表元の注記にある速報・確報、改定、方法の変更を1文で
5. caution ...... 印（revised / base_changed）がある系列の注意書き

【書き方の決まり】
- 前年同月比が ±5.0％ を超えるときは「大きく増加／大きく減少」、
  ±1.0％ 以内なら「横ばい」と書きます。その間は「増加／減少」。
- 季節調整値の系列（sa=true）は前月比を先に、原数値の系列は
  前年同月比を先に書きます。
- 数字は表にある値をそのまま、表と同じ桁で書いてください。
  丸めて言い換えないでください（「約1割」などと書かない）。

【厳守事項】
- 計算をしないでください。前月差や前年同月比が表にないときは、
  その数字を書かずに「比較できる値なし」と書いてください。
- 動きの理由は、source_note の元になる注記にそう書かれているときだけ
  書いてください。天候・価格・制度などの理由を推測で書かないでください。
- 来月以降の見通しを書かないでください。
- 自社の売上や受注の増減を推計しないでください。
- 印 revised がある系列は、caution に「前月の値が改定されています」と
  書き、movement は改定後の値で書いてください。
- 印 base_changed がある系列は、movement を書かずに status を
  needs_review にしてください。
- status が published でない系列（未公表）は、何も書かないでください。

【全体の要約】
大きく動いた系列を3つまで挙げ、それぞれ1文で書いてください。
「市場が上向いている」のような全体の評価は書かないでください。

【系列の表】{series_table}
【公表元の注記】{source_notes}
【過去3か月のメモ】{past_memos}

「全体の評価を書かない」を明記しないと、最後に必ず総括が付きます。 「住宅関連の需要は底堅く推移」のような一文は読みやすいのですが、どの数字からそう言えるのかが表のどこにもありません。 解釈は担当者が書く、という線をここで引きます。

「表と同じ桁で書く」も、照合のための指示です。 3.2％を「3％台」と書かれると、照合のプログラムは一致を確かめられません。文の読みやすさより、確かめやすさを先に置きます。

出力形式を固定する

次の形のJSONで受け取ります。 Structured Outputs で JSON スキーマを指定し、すべての項目を required に並べ、additionalProperties を false にします。値がない項目は null を許す型にします。

{
  "memo_month": "2026-10",
  "series": [
    {
      "series_id": "",
      "title": "",
      "status": "ok | needs_review | not_published",
      "movement": "",
      "trend": null,
      "relation": null,
      "source_note": null,
      "caution": null,
      "numbers_used": ["", ""]
    }
  ],
  "top_moves": [
    { "series_id": "", "sentence": "" }
  ]
}

1つ目の理由は、numbers_used で照合ができることです。 文に使った数字をAI自身に列挙させ、Python が計算済みの表と1つずつ比べます。表にない数字が1つでもあれば、その系列は needs_review に書き換えて担当者に回します。 文の中から数字を正規表現で拾って比べる処理も並べておくと、列挙の漏れも拾えます。

2つ目は、status で人が見る系列を絞れることです。 ok の系列は一覧で流し読みし、needs_review の系列だけ統計表を開きます。20系列のうち印が付くのは数本という想定です。

3つ目は、メモの書式に機械的に流し込めることです。 系列の順番、見出し、注意書きの位置が毎月同じになり、役員が先月のメモと並べて読めます。 第3章の（d）はここで解消します。

メモの見た目は次のようにします。

【市場の動き（2026年10月の経営会議）】
■ 大きく動いた系列
・（top_moves の文を3つまで）

■ 系列ごとの動き
〔住宅〕新設住宅着工戸数（原数値）
  movement の文／trend の文／relation の文
  （注）source_note の文
〔物価〕……

■ 未公表の系列
・（統計名と公表予定）

■ 担当者のコメント（担当者が書く）

システムへ連携する

経営会議の資料には自動で書き込みません。 下書きは別のファイルに作り、担当者が確認してから資料に貼ります。 自動で貼る形にすると、確認されていない文が役員に届く経路ができます。

値の履歴は、追記だけにします。 一度取った値を上書きしないことで、公表元がいつ値を改めたかが後から分かります。 改定の比較は、この履歴があって初めてできます。

e-Stat の API を使うサービスには、決められたクレジットの表示が求められています。 「このサービスは、政府統計総合窓口(e-Stat)のAPI機能を使用していますが、サービスの内容は国によって保証されたものではありません。」という文言です。社内のメモでも、末尾にこの文言と統計ごとの出典を載せておきます。

人が確認する

担当者は、needs_review の系列と、改定ありの印の系列を先に見ます。 ok の系列は一覧で流し読みします。

1. 印の付いた系列を見る … 改定ありの系列は、公表元の統計表を開いて前月の値が本当に改められたかを確かめます。基準の改定の印がある系列は、前の系列とつなげてよいかを判断します
2. 照合で合わなかった文を直す … 表にない数字を使った文は、表の数字に直すか、その文を消します
3. 理由の書きすぎがないかを見る … 注記にない理由が書かれていたら消します
4. 全体の要約を書く … AIの top_moves を参考に、市場の動きの解釈と自社への意味を担当者の言葉で書きます
5. 直したところを記録する … どの系列の、どの文を、なぜ直したかを残します

4番目は省かないでください。 AIの下書きは「何が動いたか」までで、「だから何か」を書くのは経営企画部の仕事です。 ここを下書きのまま出すと、メモは統計の言い換えになり、経営会議で読まれなくなります。

目標は、20系列をならして1系列24分です。 印の付かない系列は数分で終わり、印の付いた系列と全体の要約に時間を使います。

例外に対処する

上から4行目までが、この業務でいちばん多い例外です。 どれもAIの問題ではなく、公表の側の事情です。 推測で埋めずに止める、を全部の行で守ると、第3章の（b）と（c）が起きなくなります。

記録を残す

• 系列ごとの取得日時、統計表のID、取った値（追記のみ）
• 改定ありの印と、改定前・改定後の値
• AIに渡した表と注記、返ってきたJSONの全文
• 照合の結果（表にない数字が出た系列と、その数字）
• 担当者が直した文と、直した理由
• 毎月の月次メモの確定版

4つ目と5つ目は、指示文を直す材料です。 毎月同じ型の直しが続くなら、書き方の決まりか指示文のほうを直します。例えば「理由を書きすぎる」が3か月続いたら、指示文の厳守事項を強めます。

値の履歴は、何年分も残します。 統計の改定は数年さかのぼって行われることがあり、当時のメモがどの値で書かれていたかを説明できるようにしておきます。