Analyzegear
「数字が入る文書をAIに書かせたい。でも数字を1つでも作られたら終わり」——これは多くの人が最初にぶつかる壁だと思います。要約や言い換えはAIが得意ですが、そこに実在しない数値が混ざり込む可能性がある限り、顧客に出す書面には使えません。プロンプトで「捏造するな」と書いても、守られたかどうかを確かめる手段がなければ、それは祈りでしかありません。
今回は自社の保守サービス「Sonagear」の監視データを題材に、AIに集計済みの値だけを渡し、書かれた数値を1つずつ元データと機械照合する仕組みを作りました。芯は単純です。数字を作らせない一番確実な方法は、プロンプトで禁じることではなく、そもそも元データを見せないこと。そのうえで、作っていないことを毎回検証します。以下、実装と計測、ハマりどころを技術者向けにまとめます。決済者・担当者向けの要約版は 実績ページの事例（保守レポートをAIが下書きし、数字は機械が検算する） にあります。
先に運用の実態を断っておきます。これはAIが下書きを作り、担当者が内容を確認して確定する仕組みで、AIが顧客レポートを書いて自動で送るものではありません。検証は自社2サイト（toha.jp / noimi.jp）のみで行い、顧客サイトのデータは使っていません。生成した4本はすべて社内検証で、顧客に送付した実績はまだありません。
なぜプロンプトで禁じるだけでは足りないのか
保守サービスでは synth（死活チェック）、perf（Lighthouse）、seo、drills（復旧訓練）といった監視データが毎日溜まります。ただ Lighthouse のスコアや LCP のミリ秒をそのまま並べても、サイトの持ち主には意味が伝わりません。かといって毎月サイトごとに文章を書き起こすのは手間です。「じゃあAIに」となるわけですが、生データをまるごと渡して「レポートにして」と頼むと、AIは渡された数字を要約する過程で、平均を勝手に計算したり、単位を換算したり、それらしい別の数字に置き換えたりします。しかもそれは自信たっぷりの自然な日本語で出てきます。
ここが今回の設計判断の分かれ目でした。AIに与える情報を「言い換えるべき対象」だけに絞り、計算はすべてコード側で終わらせる。AIには算数をさせない。数字を作る余地を、プロンプトの言葉ではなく構造で塞ぎます。
パイプラインの分業
- 集計（コード）：監視データから回数・最小・最大・平均・失敗したチェックの内訳を計算する。AIには元データを渡さない。
- 言い換え（AI）：集計済みのJSONだけを渡し、「この値を日本語のレポートにする」ことだけをさせる。
- 検算（コード）：出力された文章から数値を全部抜き出し、渡した値と機械的に突き合わせる。
- 確定（人）：不一致の警告を見て、担当者が確認して確定する。
役割分担の原則は「正しさは機械、読みやすさは人」です。数値の一致は機械が保証できますが、「伝わる文章になっているか」は機械では測れません。逆に、読みやすさを人が見ているうちに数字の正しさまで人手で保証しようとすると、後述するような「人の目を通り抜ける誤り」を取りこぼします。だから正しさの担保だけは機械に固定しました。
技術構成とモデル選定
- Laravel 13 / PHP 8.3 / SQLite（docker 不要の小さな構成）
- 要約モデル：
claude-sonnet-5。要約は「与えられた値を言い換える」作業なので、上位モデルは使っていません。 - データ取得：
awsCLI 経由。認証情報をアプリで持たず、対象外サイト（顧客サイト）は設定で絞ったうえでコード側でも例外で弾いています。 - コスト管理：全コールのトークンと円を記録し、月次上限3,000円で自動停止。
モデル選定は「タスクに要求される能力」で決めています。今回のAIの仕事は推論でも計算でもなく、渡された値を専門用語ごと平易な日本語に開くこと（LCP →「主要な内容が表示されるまでの時間」、canonical →「正規URLの指定」）です。ここに上位モデルを使う必要はありませんでした。数字を扱う書面だからこそ賢いモデルを、と考えがちですが、数字の正しさはモデルの賢さではなく後段の機械照合で担保するので、要約モデルは軽くて構いません。
照合の設計 ― 「許可する数値」をどう定義するか
機械照合の中身は「本文から数値を抽出し、許可リストにあるかを1つずつ確認する」です。素直そうに見えて、許可リストの作り方でいきなり誤検出します。
最初は許可する数値を「集計値の値」だけにしていました。すると、こういう正しい文章が弾かれます。
HTTPステータスが200以外だった回数は0回
この 200 は集計値そのものではなく、AIに渡したJSONのキー名や文字列の中に現れる数字です。集計値だけを許可リストにすると、この 200 を「元データに無い」と誤って警告してしまいました。そこで方針を変え、AIに渡したJSONに現れる数値すべて（値だけでなく、キー名や文字列内の数字も含む）を許可する形に直しました。「AIに見せた情報の中に根拠がある数字なら書いてよい」という定義です。ここを値だけに絞ると、正しい書き写しを片っ端から誤検出します。
結果 ― 138個中136個（98.6%）が一致
自社2サイト × 2か月 = 4本のレポートを生成して計測しました。
| 項目 | 実測値 |
|---|---|
| 本文中の数値が元データと一致 | 138個中136個（98.6%） |
| 1本あたりの生成費用 | 3.78円（4本の平均） |
| 1本あたりの生成時間 | 約25.0秒（4本の平均、23.9〜25.6秒） |
元データの母数は、たとえば toha.jp の2026年8月で synth 21回 / perf 21回 / seo 21回 / drills 1回です。この件数は月とサイトで変わります。
一致しなかった2個 ― 人が読んでも見逃す種類の誤り
ここがこの検証の本題です。一致しなかった2個は、noimi.jp の9月分に出た 3.6 と 3.7 でした。本文はこう書いていました。
主要な内容が表示されるまでの時間(LCP)はモバイルで平均3712ms（最小3678ms、最大3779ms）と、いずれの回も3.6秒台後半〜3.7秒台にとどまっています
3678ms を「3.6秒台」と言い換えたものです。算数としては正しい。だが元データに 3.6 という値は存在せず、これは私たちが指示で明示的に禁じていた「単位換算」にあたります。数字が合っているので、人が読んでも素通りします。機械が「渡した値の集合に3.6は無い」と照合したから捕まりました。
この1件が示すのは、禁じたことは、検証しないと守られないということです。「単位換算をするな」とプロンプトで明示していたにもかかわらず、1回起きました。方針を書くだけでは足りず、破られたときに検出できる仕組みが要ります。そして、この種の「正しく見える誤り」こそ人の目が最も苦手とするもので、機械照合の価値がはっきり出た瞬間でした。
データが無い項目を埋めさせない
捏造対策の裏側として、「値が無いのに埋めてしまう」問題も潰しました。復旧訓練の記録が無い月には、AIは null を渡された項目を無理に埋めず、「実施記録がありません（実行回数0回）」と書き、申し送りに「所要時間・検証段階・対象範囲の割合はすべて null のため記載していません」と残しました。「無い」を「無い」と書けることは、数字を扱うレポートでは一致率と同じくらい重要です。
ついでに、出力は都合の悪いことも省かずに書いていました。特定商取引法に基づく表記が「未対応」、Cookie 同意の表示が「未対応」、ページタイトルの長さが不適切な状態が21回の測定すべてで継続（toha.jp・2026年8月）——といった具合です。集計値を渡しているだけなので、悪い数字も丸めずそのまま言葉になります。
他の案件にも持っていける設計
- AIに生データを渡さない型。集計はコード、言い換えだけAI。数値を扱う書面の生成全般に効く。プロンプトで禁じるより構造的に強い。
- 出力の数値を機械照合する型。「捏造していない」を主張ではなく検証で示す。許可リストは「AIに見せた情報に現れる数値すべて」で定義する（値だけに絞ると正しい書き写しを誤検出する）。
- データが無い項目を埋めさせない。
nullを渡し、「記録がありません」と書かせる。 - 正しさは機械、読みやすさは人。正しく見える誤りは人の目を通り抜ける。逆に伝わる文章かは機械では測れない。役割を分ける。
測っていないので書けないこと
誇大にならないよう、母数と条件を添えます。一致138個中136個・3.78円・約25秒は、いずれも自社2サイト × 2か月の4本での値です。一致率は機械照合であり、人の評価ではありません。21回は toha.jp・2026年8月の例で、月とサイトで変わります。
そして測っていないので書けないこと。「レポート作成の工数が◯%減った」とは書けません（手動で書く時間を測っていないため）。顧客満足度も書けません（4本とも社内検証で、顧客に出していないため）。「保守先◯社に導入」とも書けません（自社2サイトのみで、顧客サイトのデータは使っていないため）。Sonagear 本体（ポータル）には手を入れておらず、レポート生成のみで、自動送信もしていません。あくまで下書きをAIが作り、担当者が確認して確定する仕組みです。
まとめ
数字が入る文書でAIを使うとき、怖いのは「間違いそうな数字」ではなく「正しく見える間違い」です。3678ms を「3.6秒」と言い換えるような誤りは、算数が合っているぶん人の目を通り抜けます。だからこそ、AIに算数をさせず集計済みの値だけを渡し、書かれた数値を1つずつ機械で検算する——正しさを検証しながらAIを使う設計が要ります。「捏造していない」は、祈りではなく検証で示せます。
事例の要約（決済者・担当者向け）は 実績ページ に、AI活用の他の事例は AI活用ページ にまとめています。数字が入る文書をAIに書かせたいが間違いが許されない、といったご相談は お問い合わせ から。
