製品の仕様・料金を扱う記事の更新運用：公式ページの変更を確認する仕組み

先に決めること：変動情報を本文のどこに置くか

同じ数値が本文のあちこちに散っていると、仕様や料金を更新するときに見落としが生じやすくなります。更新時に探し漏れが出ます。次の3つに分けて置き場所を決めると、確認の範囲が絞れます。

• 変動しやすい値、例：料金、利用上限、対応プラン、提供地域、本文での置き場所：記事内に1か所の表または「確認時点の情報」ブロックを設け、他の段落は数値を書かずその表を参照する
• 変動しうる手順、例：設定画面の名称、メニューの位置、本文での置き場所：手順の直前に「確認した画面・日付」を書く
• 変動しにくい考え方、例：比較の観点、選び方の基準、本文での置き場所：通常の本文。定期確認は軽くてよい

料金の例として、AnthropicのAPI料金ページ（Pricing、2026年10月29日に本文を確認）は、モデルごとに入力トークン、キャッシュ書き込み（5分・1時間の2種類）、キャッシュヒット、出力トークンの列に分かれています。さらにページ冒頭では、最新の価格は別ページ（claude.com/pricing）で確認するよう案内されています。つまり「料金」という1語の裏に複数の項目があり、確認先も1つとは限りません。台帳では「料金」を1行にせず、記事が実際に触れる項目ごとに分けるのが安全です。

手順1：記事から変動情報を洗い出す

記事を上から読み、次のどれかに当たる記述に印をつけます。

• 金額、無料枠、上限、回数、容量
• 対応プラン、対応端末、対応言語、提供地域
• 画面名、ボタン名、設定の場所
• 提供終了・開始、一般提供か試験提供かの区別
• 規約や取り扱い（データの扱いなど）に関する記述

洗い出し表の形は次の通りです（説明用の例。「サービスA」は架空です）。

• V01、記事内の位置：「料金」表、記述の要約：月額の個人向けプラン価格、種別：料金、変動しやすさ：高、確認先の種類：公式の料金ページ
• V02、記事内の位置：「料金」表、記述の要約：入力・出力の従量単価、種別：料金、変動しやすさ：高、確認先の種類：公式の料金ページ（API）
• V03、記事内の位置：手順2、記述の要約：設定画面のメニュー名、種別：画面、変動しやすさ：中、確認先の種類：公式ヘルプ
• V04、記事内の位置：「制限」節、記述の要約：1日あたりの利用上限、種別：上限、変動しやすさ：高、確認先の種類：公式ヘルプ／料金ページ
• V05、記事内の位置：「データの扱い」節、記述の要約：学習利用の設定の有無、種別：規約、変動しやすさ：中、確認先の種類：公式ヘルプ・規約

「変動しやすさ」は、過去にその項目が変わった頻度を自分の記事の更新履歴から見て付けます。履歴がない新規記事は、料金と上限を「高」、画面名を「中」から始め、数回確認して実態に合わせて直します。

手順2：確認先を一次資料に固定する

確認先は、提供元の公式ページに限定します。製品の仕様ならヘルプセンターや開発者向けドキュメント、料金なら料金ページ、規約なら規約本文です。他メディアの紹介記事で値を確認すると、その記事自体が古い可能性があるため、台帳には使いません。

台帳には確認先のURLを、ページ単位で記録します。「公式サイト」とだけ書くと、次の担当者が同じページに辿り着けません。同じ項目に複数のページが関係する場合（料金ページとヘルプの両方に上限が載っている等）は、両方を書き、食い違いがあれば食い違い自体をメモに残します。

手順3：管理シートを作る

洗い出した項目を、次の列を持つシートに移します。表計算ソフトで十分です。

• ID、入れる内容：洗い出し表のID
• 記事URL／記事名、入れる内容：どの記事の項目か
• 項目、入れる内容：例：個人向けプラン月額
• 本文の記載値、入れる内容：現在、本文に書いてある値
• 確認した値、入れる内容：公式ページで読み取った値。確認できなければ未確認と記録
• 確認先URL、入れる内容：公式ページ単位
• 最終確認日、入れる内容：実際に公式ページを開いた日
• 確認結果、入れる内容：変更なし／変更あり／ページ消失／判断保留
• 次回確認予定、入れる内容：最終確認日＋間隔
• 担当、入れる内容：確認する人
• メモ、入れる内容：食い違い、表示条件（地域・プラン）など

説明用の記入例です（日付は例で、実際の確認結果ではありません）。

• V01、項目：個人向けプラン月額、本文の記載値：（例）○○円、確認先URL：公式料金ページ、最終確認日：2026-10-28、確認結果：変更なし、次回確認予定：2026-11-11、担当：編集A
• V03、項目：設定のメニュー名、本文の記載値：（例）「設定＞□□」、確認先URL：公式ヘルプの該当ページ、最終確認日：2026-10-28、確認結果：変更あり、次回確認予定：2026-11-28、担当：編集B
• V05、項目：学習利用の設定、本文の記載値：（例）オフにできる、確認先URL：公式ヘルプ、最終確認日：2026-10-28、確認結果：判断保留、次回確認予定：2026-11-04、担当：編集A

「最終確認日」と記事の公開日・更新日は別物として管理します。Googleは、記事の日付は「ページの公開または更新の日付」を表すものと案内しています（Google 検索セントラル：記事の日付）。同ページでは、画面に表示する日付と構造化データのdatePublished・dateModifiedを一致させることも求めています。また、実質的な変更がないのに日付だけ新しくする行為は、有用なコンテンツに関するガイドラインでも好ましくないとされています。したがって運用ルールは次のようにするのが無難です。

• 確認して変更がなかった場合：シートの確認日だけ更新し、記事の更新日は変えない
• 値や手順を書き換えた場合：本文を直し、その実質的な変更に対応して更新日を変える
• 本文には「○年○月○日時点で公式ページを確認」と、表の見出し付近に1回だけ書く

手順4：確認の間隔と担当を決める

間隔は変動しやすさと、誤りが読者に与える影響で決めます。説明用の目安は次の通りです。自分の記事の変更履歴で調整してください。

• 高、読者への影響：支払い・契約に関わる、確認間隔の例：2週間〜1か月、追加の確認：公式の更新情報を購読していれば、通知時にも確認
• 高、読者への影響：操作の可否に関わる、確認間隔の例：1か月、追加の確認：検索流入の多い記事は優先
• 中、読者への影響：手順がずれる程度、確認間隔の例：2〜3か月、追加の確認：読者から指摘があれば即時
• 低、読者への影響：考え方の記述、確認間隔の例：半年〜1年、追加の確認：大きな製品更新時

担当は「記事の担当者」ではなく「項目の担当者」にすると、記事を書いた人が不在でも回ります。小規模な運営なら、担当者と、確認結果を見る二人目を決めておき、料金と規約に関する項目だけ二人で見る形でも十分です。

手順5：AIに任せる範囲と人が見る範囲

AIは、記事本文からの変動情報の抽出と、確認結果の差分整理には向いています。一方で、公式ページを開いて値を読み取る作業と、変更の有無の最終判断は人が行います。AIに渡す前に、記事内の機密情報や未公開の社内情報は取り除くか、説明用データに置き換えてください。

洗い出しを任せる依頼文の例です（未実行の例です）。

次の記事本文から、時間とともに変わりうる記述を抜き出してください。
対象：金額、上限、対応プラン、画面名やメニュー名、提供地域、規約に関する記述。
出力：表（ID／記事内の位置／記述の要約／種別／変動しやすさ（高・中・低）／確認すべき公式ページの種類）
条件：
- 本文に書かれていない値は補わない
- 確認先は「公式の料金ページ」のように種類だけを書き、URLは推測しない
- 変動しやすさの根拠を1行で添える
--- 記事本文 ---
（ここに貼る）

確認結果の整理を任せる場合は、人が公式ページから読み取った値をシートに入れたうえで、「本文の記載値」と「確認した値」の列を渡して、差があるものだけを挙げさせます。

次の表で「本文の記載値」と「確認した値」が異なる行だけを挙げ、
本文のどの箇所を直す必要があるか、修正案を1行ずつ書いてください。
値そのものは表の「確認した値」だけを使い、推測で補わないでください。

人が確認する点は3つです。(1) 公式ページに実際に書かれた値と一致しているか。(2) 地域・プラン・提供形態（個人向けか法人向けか等）が、記事の対象と合っているか。(3) AIが挙げなかった変動情報が残っていないか。

手順6：運用を回して見直す

シートを作ったら、最初の1回転は全項目を確認し、変更があった項目の割合を見ます。数値は自分のシートの実績として扱い、一般的な傾向とは言わないでください。次の見直しで調整します。

• 3回連続で変更がなかった項目は、間隔を1段階延ばす
• 変更があった項目は、間隔を1段階縮める
• 確認先ページが消えた・移動した場合は、新しいURLを探してシートを直し、メモに経緯を残す
• 読者から指摘があった項目は、次回予定を待たずに確認する

公式ページが閲覧できなかった場合は、「確認結果」を「変更なし」ではなく「判断保留」にします。確認できなかった値を、前回の値のまま「確認済み」にしないことが、この運用でいちばん大事な約束事です。