AI検索にも人にも伝わる記事テンプレート｜設計シート・本文の型・公開前チェック

「AI検索を意識して記事を書こう」と社内で決めたものの、気をつけることが多すぎて手が止まっていないでしょうか。

引用されやすい書き方、見出しの組み方、FAQ、著者情報、更新日、構造化データ。担当者ごとに書き方がばらばらで、レビューのたびに同じ指摘を繰り返している会社もあるはずです。

この記事は、中小企業のオウンドメディアで、1本の記事を作るための実務テンプレートをまとめたものです。書く前の設計シート、本文の型、コピーして使えるMarkdownのテンプレート、公開前のチェックリスト、社内での運用、AIを下書きに使うときの注意の6つに分けました。

各要素の根拠や詳しいやり方は、別の記事に任せます。ここでは「明日から使える形」にすることに集中します。

Googleの公式ページは、2026年10月17日に開いて確かめました。テンプレートの中身は、筆者の提案です。

先に結論：書く前に1枚埋めて、決まった型で書く

要点を、先に表にします。

順番	やること	理由
1	書く前に、設計シートを1枚埋める	読者、問い、結論、一次情報、出典が決まっていないと、途中で迷う
2	本文は、決まった型で書く	冒頭の結論、要約、見出しごとの問いと答え、手順や表、FAQ、まとめ、著者と更新日の順
3	AI検索のための特別な仕掛けは、足さない	Googleは、生成AI機能に表示されるための追加の技術要件はないと説明している
4	公開前は、チェックリストで確認する	書く人と確認する人を分けると、事実の誤りや古い情報を見落としにくくなる
5	AIを下書きに使っても、確認の責任は人が持つ	Googleは、公開前に人が事実確認とレビューをすることが重要だとしている

テンプレートの目的は、人が読みやすく、どの部分を切り出しても意味が通る記事を、毎回安定して作ることです。

この記事で使った情報源

情報源	確かめた内容
生成AIコンテンツの利用についてのガイダンス（Google）	公開前の事実確認、確認対象になるメタ情報、大量生成コンテンツの不正使用
スパムに関するポリシー（Google）	大量生成コンテンツの不正使用の定義
役に立つ、信頼性の高いコンテンツの作成（Google）	Who・How・Whyの見直し、自己評価の問い、日付の扱い
生成AI機能向けの最適化のガイド（Google）	特別なファイルや細かい分割は要らないこと
AI機能と検索のページ（Google）	AI OverviewsとAI Modeに、追加の技術要件はないこと
検索ドキュメントの更新履歴（Google）	2026年10月1日のガイダンス更新、FAQのリッチリザルトの終了

なぜ記事テンプレートが必要なのか

良い書き方を知っていても、毎回は再現できない

引用されやすい文章のルールや、見出し単位で伝わる構成の原則は、一度読めば納得できます。

ところが現場では、締め切りに追われる中で、冒頭が前置きから始まったり、「上記のとおり」に頼った説明になったり、更新日を入れ忘れたりします。

原因は、書き方が手順として固定されていないことにあります。

テンプレートは、良い書き方が最初から枠に入っている状態を作るための道具です。毎回思い出す必要がなくなります。

AI検索と人の読者は、同じ記事を同じように評価する

AI検索は、質問に対して複数のページから関係する部分を探し、まとめて回答を作ります。

Googleは、生成AI機能のために内容を細かく分割する必要はないと説明しています。細かく切り刻むことより、読者のために作ることが基本です。

筆者の考えでは、人が拾い読みしても分かる記事は、AIにも伝わりやすくなります。このテンプレートも、人の読者を第一に考えた構成です。

テンプレートに入れるものと、入れないもの

AI検索向けの記事テンプレートというと、AI専用の書き方を想像するかもしれません。

この記事のテンプレートに入っているのは、読者のための基本です。AI専用の仕掛けは含めていません。

入れるもの	入れないもの
読者と問いを決める設計シート	AI検索のためだけの特別なファイル
結論を先に置く本文の型	特定のAIに合わせた文言の工夫
事実と出典を確かめるチェックリスト	同じ内容を言い換えて増やした記事
著者名と更新日の表示	実在しない著者の紹介

この記事の読み方

最初から順に読む必要はありません。いまの状況に合わせて、入り口を選べます。

いまの状況	最初に読む箇所
記事づくりの型がまだなく、これから決める	ステップ1の設計シートから順に読む
型はあるが、レビューの基準がばらばら	ステップ4の公開前チェックリスト
すぐ使える雛形が欲しい	ステップ3のMarkdownテンプレート
AIに下書きを書かせている	ステップ6のAIを下書きに使うときの注意

どの入り口から読んでも、最後に設計シートへ戻ってくる構成にしています。

ステップ1：書く前の設計シート

記事の質は、書き始める前にほぼ決まります。次の5項目を埋めてから、執筆に入ってください。

埋められない項目があるときは、まだ書く段階ではありません。

項目	書く内容	埋められないときのサイン
読者	誰が、どんな状況で、何に困って読むか	「中小企業の皆さま」のように広すぎる
問い	読者が検索窓やAIに打ち込みそうな質問。主な問いを1つと、関連する問いを3〜6個	問いが記事タイトルの言い換えしかない
結論	主な問いへの答えを、2〜3文で	「場合による」「いろいろある」で終わる
一次情報	自社にしか書けない経験、データ、手順、写真	どの会社が書いても同じ内容になる
出典	事実や数字の裏付けになる公式情報や論文	「どこかで見た」数字に頼っている

読者：1人の具体的な人を思い浮かべる

「Web担当者」と書くより、具体的に描きます。

たとえば、社員30人の製造業で、ホームページの更新を兼務している総務担当者。社長から「AIで検索されるようにしろ」と言われて困っている、といった人物です。

これは説明のための例です。

読者が具体的だと、専門用語をどこまで説明するか、手順をどこまで細かく書くかが自然に決まります。

問い：見出しの材料になる

関連する問いは、そのまま本文の見出しの候補になります。

集め方は、問い合わせのメール、営業担当がよく受ける質問、検索候補、Search Consoleの検索語句などです。

結論：先に書いてから本文を書く

結論を先に決めておくと、本文がぶれません。

結論が書けないときは、調べ方か取材が足りていないことが多いです。

一次情報：最低1つは入れる

自社の作業手順、実際に使った画面、社内で集計した数字、現場の写真、失敗談などです。

Googleは、役に立つコンテンツかどうかを自己評価する問いの中で、オリジナルの情報、報道、調査、分析を含んでいるかを挙げています。

出典：確認日も一緒に記録する

数字、仕様、日付には出典を付け、いつ確認したかも記録しておきます。

AIに関する仕様は変わりやすいため、確認日がないと、更新すべきかどうかを後から判断できません。

ステップ2：本文の型

設計シートが埋まったら、次の順番で本文を組み立てます。

順番	パーツ	役割
1	冒頭の結論	誰のどんな悩みに答える記事かを、2〜4文で示す
2	要約	結論を、3〜5個の箇条書きで示す
3	見出しごとの問いと答え	1見出しに1つの問い。見出しの直後に答えを書く
4	手順・表	手順は番号付きリスト、比較は表にする
5	FAQ	本文で扱いきれない関連質問を、3〜5問
6	まとめ	要点と、次にやることを短く
7	著者・更新日	誰がいつ書き、いつ見直したかを示す

上の図は、設計から公開後の見直しまでの流れです。型に沿って書く前に設計があり、公開後にも見直しがあります。

1. 冒頭の結論

最初の段落で、この記事が誰のどんな悩みに答えるかを書きます。遅くとも2段落目までに、答えの方向性を示します。

「近年、AIの普及により」のような一般論から入るのは避けます。

2. 要約

「この記事の結論」といった見出しを立て、箇条書きで3〜5個にまとめます。要約だけ読んでも、主な問いに答えられる状態が理想です。

3. 見出しごとの問いと答え

各見出しは、読者の問いに対応させます。書き方の基本は、次の3つです。

• 見出しの直後の1〜2文で答える。理由や補足は、その後に書く
• 見出しの中で話を完結させる。「上記」「前述の」「これ」に頼らず、主語や固有名詞を書く
• 1つの見出しに、問いは1つにする。2つの問いが混ざったら、見出しを分ける

4. 手順・表

読者が実行する内容は、番号付きリストにします。各手順は、「何をする」と「どうなれば完了か」の形で書きます。

複数の選択肢を比べる内容は、表にします。先に比べる軸（費用、手間、向いている会社など）を決めてから中身を埋めると、形の合わない表になりません。

手順記事の書き方は、別の記事にまとめています。

ハウツー記事（手順記事）の書き方

5. FAQ

本文の流れには入らないが、読者が気にしそうな質問を、3〜5問置きます。質問は疑問文で書き、回答の最初の1文で答えます。

GoogleのFAQリッチリザルトは、2026年5月7日以降、検索結果に表示されなくなりました。FAQは、読者の疑問に答えるために置きます。

6. まとめ

本文の繰り返しにせず、要点3つと、読者が次にやること1つに絞ります。

7. 著者・更新日

記事の冒頭か末尾に、著者名（著者ページへのリンク付き）、公開日、最終更新日を表示します。

仕様や数字を扱う記事では、本文中にも「2026年10月時点」のように、時点を書きます。

著者情報の整え方は、別の記事で扱っています。

E-E-A-Tと著者情報の整え方

構造化データを入れる場合は、ページに表示している日付や著者名と、一致させることが大切です。

ステップ3：コピーして使えるMarkdownテンプレート

ここまでの内容を、そのままコピーして使える形にしました。

社内の共有フォルダやCMSの下書きに置いて、毎回ここから書き始めてください。【】の部分を書き換え、不要な説明文は消して使います。

設計シートのテンプレート

# 設計シート：【仮タイトル】
- 担当：執筆【名前】／確認【名前】／公開予定日【YYYY-MM-DD】
## 読者
- どんな人か：【業種・規模・役職・状況】
- 何に困っているか：【具体的な悩み】
- 読んだ後にできるようになること：【行動】
## 問い
- 主な問い：【読者が検索・AIに入力しそうな質問】
- 関連する問い（見出し候補）：
  1. 【問い】
  2. 【問い】
  3. 【問い】
## 結論（2〜3文）
【主な問いへの答え】
## 一次情報（最低1つ）
- 【自社の手順・データ・写真・経験など】／入手元：【担当者・資料名】
## 出典
| 事実・数字 | 出典URL | 確認日 | 確認した人 |
|---|---|---|---|
| 【内容】 | 【URL】 | 【YYYY-MM-DD】 | 【名前】 |
## 見直しの予定日
- 【YYYY-MM-DD】（理由：【仕様が変わりやすい、など】）
## 関連する自社記事（内部リンク候補）
- 【記事タイトル・URL】

本文のテンプレート

<!-- タイトル：【主な問いと、答えの方向性が分かるもの】 -->
<!-- 著者：【名前】（著者ページへリンク）／公開日：【YYYY-MM-DD】／最終更新日：【YYYY-MM-DD】 -->
【導入：誰の、どんな悩みに答える記事か。2〜4文】
## この記事の結論
- 【要点1：主な問いへの答え】
- 【要点2】
- 【要点3】
## 【関連する問い1を見出しにする】
【1〜2文で答える。主語と固有名詞を書く】
【理由・具体例・自社の経験】
## 【関連する問い2：手順を説明する見出し】
【1文で全体像を示す】
1. 【やること】→【完了の目安】
2. 【やること】→【完了の目安】
3. 【やること】→【完了の目安】
## 【関連する問い3：比較する見出し】
【1文で結論】
| 比べる軸 | 【選択肢A】 | 【選択肢B】 |
|---|---|---|
| 【軸1】 | 【内容】 | 【内容】 |
| 【軸2】 | 【内容】 | 【内容】 |
【表の読み方・選び方を1〜2文で】
## よくある失敗
- 【失敗】：【避け方】
## よくある質問
### 【質問1】
【最初の1文で答える】【補足】
### 【質問2】
【最初の1文で答える】【補足】
## まとめ
- 【要点1】
- 【要点2】
- 【要点3】
まずは【読者が次にやること1つ】から始めてください。
---
著者：【名前】（【役職・担当業務】）
公開日：【YYYY-MM-DD】／最終更新日：【YYYY-MM-DD】
更新履歴：【YYYY-MM-DD】【何を更新したか】

テンプレートを使うときのコツ

テンプレートは、順番の目安です。空欄を埋めるための書類ではありません。

コツ	内容
見出しは問いの形にする	「概要」「ポイント」のように中身の分からない見出しを避け、問いか、答えが分かる形にする
すべてのパーツを無理に埋めない	比べる内容がない記事に、表は要らない
時点を書く	仕様、料金、数字を書いたら、その段落に「2026年10月時点」のように書く
更新履歴を残す	直した日と内容を、一行で残す

設計シートを使った例

使い方のイメージを、短い例で示します。内容は説明のための仮のものです。

項目	記入の例
読者	製造業の総務担当者。ホームページの更新を兼務している
主な問い	問い合わせフォームの項目は、いくつが適切か
結論	必須項目は最小限にし、補足は任意にする。自社の集計で離脱が減った
一次情報	自社サイトのフォーム変更前後の、送信完了率の集計
出典	集計期間と件数を記録した社内資料

一次情報の欄が空のままなら、書き始める前に集計を取ります。

ステップ4：公開前チェックリスト

公開前に、執筆者と確認者がそれぞれ確認します。チェック欄を、CMSの下書きやレビュー用の表に貼っておくと便利です。

内容

• [ ] 冒頭の2段落以内に、誰のどんな悩みに答える記事かが書かれている
• [ ] 要約だけ読んでも、主な問いに答えられる
• [ ] 一次情報（自社の経験、データ、手順、写真）が1つ以上入っている
• [ ] どの会社でも書ける一般論だけで終わっている見出しがない
• [ ] 推測や意見は、推測や意見と分かる書き方になっている

事実・出典

• [ ] 数字、仕様、日付のすべてに出典があり、設計シートに記録されている
• [ ] 出典は公式情報や論文などの一次情報で、確認日が記録されている
• [ ] 変わりやすい情報に、「2026年10月時点」などの時点がある
• [ ] 社外の会社名、金額、事例を、許可なく載せていない

構成

• [ ] 各見出しの直後の1〜2文で、その見出しの問いに答えている
• [ ] 「上記」「前述」「これ」に頼った文がなく、見出し単位で読んでも意味が通る
• [ ] 手順は番号付きリスト、比較は表になっている
• [ ] FAQは3〜5問で、本文と同じ内容の繰り返しになっていない

表示・技術

• [ ] 著者名、公開日、最終更新日がページ上に表示されている
• [ ] 構造化データを入れている場合、表示上の著者名や日付と一致している
• [ ] タイトル、メタディスクリプション、画像のalt属性が、本文の内容と合っている
• [ ] 関連する自社記事への内部リンクがあり、リンク切れがない
• [ ] 公開後にインデックス登録を確認する担当者が決まっている

構造化データを入れる場合の考え方は、別の記事にまとめています。

AI検索対策に構造化データは必要か

ステップ5：社内での運用

担当の分け方

中小企業では、ひとりが全部を担うことも多いでしょう。ただ、少なくとも「書く人」と「確認する人」は分けることをおすすめします。

自分が書いた文章の誤りは、自分では気づきにくいからです。

役割	主な仕事	向いている人
企画	設計シートの読者、問い、結論を決める	営業やカスタマーサポートなど、顧客の声に近い人
執筆	本文テンプレートで書く。一次情報を集める	Web担当者、現場の担当者
事実確認	出典、数字、時点を確認する	執筆者以外の人
内容監修	専門的な内容や、自社の方針と合っているかを確認する	その分野の責任者
公開・更新	CMSへの入稿、日付や構造化データ、内部リンクの確認、更新予定の管理	Web担当者

人数が少ないときは、企画と執筆、事実確認と公開を兼ねても構いません。ただし、執筆と事実確認だけは、別の人にしてください。

担当者がひとりしかいない場合は、書いた日と確認する日を分けると、誤りに気づきやすくなります。

ひとりで回すときの工夫	内容
翌日に確認する	時間を置いてから、チェックリストで読み直す
出典を開き直す	記憶に頼らず、設計シートの出典URLを実際に開いて照合する
声に出して読む	長い文や、主語が抜けた文に気づきやすくなる

レビューの進め方

レビューは、次の3つの手順で進めます。

1. 設計シートの段階で、1回レビューする。本文を書き終えてから「そもそも読者が違う」と分かると、書き直しが大きくなります。設計シートなら、10分で確認できます。
2. 本文は、チェックリストに沿ってレビューする。指摘は、どの項目に当てはまらないかを示して書くと、執筆者が直しやすくなります。
3. 指摘は、テンプレートに戻す。同じ指摘が何度も出たら、テンプレートの説明かチェックリストに1行足します。

公開後の見直し

公開して終わりにせず、見直しの予定日を設計シートに書いておきます。

AIに関する記事や、料金、仕様を扱う記事は、変化が早いため、短めの間隔で確認するのが安全です。

Googleは、役に立つコンテンツの自己評価の問いの中で、実質的に変わっていないのに日付だけ新しくして新鮮に見せていないか、を挙げています。日付は、内容を見直したときだけ更新します。

見直しの契機	確認すること
予定日が来た	数字、仕様、リンクが今も正しいか
公式ページが更新された	本文の根拠と、時点の表記
問い合わせで同じ質問が増えた	本文に答えが足りているか
担当者が変わった	著者ページと、更新の担当

チェックで引っかかったときの直し方

チェックリストで当てはまらない項目が見つかったときの、直し方の目安です。

引っかかった項目	直し方
冒頭に前置きが長い	結論の1文を先頭に出し、背景の説明は後ろへ移す
一次情報がない	担当者に聞き取りをして、手順、画面、数字のどれか1つを加える
出典が見つからない数字	根拠が示せない数字は削除し、必要なら調べ直してから書く
時点の表記がない	仕様や数字を書いた段落に、確認した年月を添える
「上記」で説明している	参照先の語を、その場で書き直す
内部リンクがない	同じ読者が次に読みそうな自社記事へ、1〜2本つなぐ

直したあとは、同じ確認者が該当項目だけを再確認します。全体を最初から見直す必要はありません。

ステップ6：AIを下書きに使うときの注意

テンプレートがあると、AIに下書きを書かせる作業もやりやすくなります。設計シートを渡し、本文の型に沿って書くよう指示できるからです。

ただし、AIが書いた文章をそのまま公開すると、事実の誤りや、どの会社でも書ける一般論がそのまま残ります。

Googleの考え方

Googleは、生成AIが話題の調査や、元の内容に構造を加える作業に役立つと説明しています。

一方で、ユーザーにとっての価値を加えないまま、生成AIで大量のページを作ることは、大量生成コンテンツの不正使用というスパムポリシーに違反しうるとしています。

また、生成AIは、学習したデータをもとにもっともらしい言葉の並びを予測する仕組みです。事実を調べて答えるものではないため、誤りが含まれることがあります。

そのためGoogleは、公開前に人が事実確認とレビューをすることが重要だと説明しています。

この確認は、本文だけでなく、titleやメタディスクリプション、構造化データ、画像の代替テキストにも当てはまります。

人とAIの役割分担

筆者の提案として、役割を次のように分けるとよいでしょう。

作業	人が担当	AIに任せてよい
読者と問いの決定	担当者が決める	問いの候補を出させる
一次情報の用意	現場の担当者が出す	集めた情報の整理
本文の下書き	設計シートを渡して指示する	型に沿った下書きの作成
事実確認	出典を開いて人が確認する	確認すべき箇所の洗い出し
公開の判断	確認者が最終判断する	任せない

一次情報だけは、AIには用意できません。自社の経験や数字は、人が出す必要があります。

Who・How・Whyの見直し

Googleは、役に立つコンテンツを作るための見直しの視点として、Who（誰が作ったか）、How（どう作ったか）、Why（なぜ作ったか）を挙げています。

AIを使った記事では、特にHowが重要になります。Googleは、自動生成やAIによる生成が大きな役割を果たす場合、その使い方を読者に分かる形で示すことを勧めています。

視点	問い	記事での対応
Who	誰が書いたかが分かるか	実在する著者名と著者ページを表示する
How	AIをどう使ったかが分かるか	必要に応じて、AIの利用範囲と人の確認を記載する
Why	読者の役に立つために作ったか	設計シートの「読者」と「問い」で確認する

著者情報の作り込みについては、別の記事で解説しています。

E-E-A-T対策に著者情報が効く理由

Googleは、AIで生成した顔写真や架空の名前、偽の経歴で専門家が書いたように見せることを、欺瞞にあたると説明しています。著者の実在性だけは、必ず守ってください。

下書きを頼むときの指示の例

設計シートの内容を渡したうえで、次のような条件を添えると、扱いやすい下書きになります。

指示の項目	書き方の例
構成	本文のテンプレートの順番で書く
根拠	設計シートの出典にある内容だけを使う。出典にない数字は書かない
不明点	分からない部分は、推測で埋めず「要確認」と書く
文体	1段落は1〜2文。結論を先に書く

「出典にない数字は書かない」という指示は、確認の手間を大きく減らします。

実際によくある失敗

テンプレートを使い始めたときに起こりやすい失敗を、筆者の想定として整理します。

失敗	起きること	対策
設計シートを飛ばして書き始める	途中で読者や結論がぶれて、書き直しになる	設計シートの確認を、執筆開始の条件にする
すべてのパーツを無理に埋める	中身のない表やFAQが増える	必要のないパーツは、省く
一次情報が空のまま公開する	どこにでもある記事になる	一次情報の欄が空なら、公開を止める
確認者が、執筆者と同じ人	誤りに気づけない	事実確認だけでも、別の人にする
更新日だけを新しくする	読者の信頼を損なう	内容を見直したときだけ、更新日を変える
見直しの予定が決まっていない	古い情報が残り続ける	設計シートに見直しの予定日を入れる

特に省きたくなるのは、設計シートです。時間がない日ほど飛ばしがちですが、本文を書く前の10分が、その後の手戻りを防ぎます。

よくある質問

Q1. 記事を1本書くのに、設計シートは必須ですか？

必須としておくことをおすすめします。設計シートの項目は、読者、問い、結論、一次情報、出典、見直しの予定日の6つだけです。

筆者の目安では、慣れれば10分前後で埋められます。

Q2. AI検索のために、特別なファイルや書き方は必要ですか？

Googleの説明では、AI OverviewsやAI Modeに表示されるための追加の技術要件はありません。通常の検索と同じ基本が当てはまります。

llms.txtのような特別なファイルについても、Google検索では不要だと説明されています。

Q3. 既存の記事にも、テンプレートを当てはめるべきですか？

まずは、問い合わせや商談につながりやすい記事から、順に見直すのが現実的です。

古い記事を一度に書き換えると、確認の負担が大きくなります。設計シートを後から埋め、空欄が多い記事から手を入れる方法もあります。

Q4. AIの下書きを使ったことは、公開ページに書く必要がありますか？

Googleは、AIによる生成が大きな役割を果たす場合や、読者が「どう作られたか」を気にしそうな場合に、その情報を示すことを勧めています。

書くかどうかは、記事の性質で判断してください。自社で決めた基準を、運用ルールとして文書にしておくと迷いません。

Q5. チェックリストの項目が多く、毎回は回せません。どうすればよいですか

最初は、事実・出典の項目だけを必須にして始める方法があります。誤った情報の公開は、後から取り消しにくいためです。

慣れてきたら、内容、構成、表示・技術の順に、必須の範囲を広げてください。

Q6. テンプレートを使うと、どの記事も似た内容になりませんか

型が同じでも、中身は設計シートの一次情報で変わります。

構成を揃えるのは、読者が探しやすくするためです。自社の経験や数字が入っていれば、同じ型でも他社の記事とは別の内容になります。

まとめ

• 書き始める前に、読者、問い、結論、一次情報、出典を設計シートに書く
• 本文は、結論、要約、問いと答え、FAQ、まとめ、著者と更新日の型で組み立てる
• 公開前は、内容、事実、構成、表示の4つの面でチェックリストを使う
• AIを下書きに使うときは、出典の確認と一次情報を人が受け持つ

まずは、次に書く記事1本で設計シートを埋めるところから始めてください。

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。