MANABERU BLOG / EDITORIAL STANDARD
INDEPENDENT AI JOURNAL / TOKYO
EDITORIAL / EVIDENCE / AI
編集・検証・AI利用方針。
どう作ったかまで、記事の一部にする。
公式一次情報、断定の強さ、人の判断、公開後の更新まで。学べるブログが記事をつくる基準を公開します。
LAST UPDATED / 2026.08.13
01 / PURPOSE
答えを渡すより、判断を残す。
生成AIの料金、機能、モデル、上限、提供地域は変わります。だから学べるブログは、ひとつの答えを永続的な正解として置くのではなく、何が公式情報で、どこからが条件つきで、何を運営者が判断したのかを読み分けられる記事を目指します。
- 01根拠へ戻れる
重要な事実は、確認した公式一次情報へたどれる形にします。
- 02条件をほどく
製品、モデル、プラン、Web、アプリ、APIを混同せず整理します。
- 03判断を分ける
公式の事実と、推論、比較基準、運営者の見解を区別します。
- 04変化を前提にする
確認日と更新条件を残し、古くなる場所を先に把握します。
02 / WORKFLOW
入口は2つ。出口は同じ品質基準。
新規記事は白紙から設計し、リライトは旧記事をいったん分解します。出発点は違っても、根拠の確認、構成、実装、評価、公開前確認は同じ工程を通ります。
新規記事をつくる
検索する人の迷いと、公式情報だけでは埋まらない空白を先に定義し、1本の記事の役割を決めます。
- START
- 検索意図と検索結果の構造を把握する
- DESIGN
- 記事群の中の役割と更新条件を決める
- AVOID
- 競合記事の見出しや表現を模倣しない
既存記事をつくり直す
古い構成を前提にせず、主張、数値、リンク、独自の判断材料を分解して、残すものと捨てるものを決めます。
- KEEP
- 今も有効な判断基準と固有の価値
- RECHECK
- 数値、モデル名、プラン、リンク、条件
- REBUILD
- 見出しから作り直し、スラッグは維持する
0から10まで、11の工程。
DECIDE → VERIFY → DESIGN → BUILD → QA → PUBLISH
入口を決める
新規は検索結果と情報の空白を調べ、リライトは旧記事を分解して課題を特定します。
DECIDE公式情報を確認する
根拠候補を集め、断定できる事実、慎重に書く事実、推論の3区分へ分けます。
VERIFY構成を設計する
1つの見出しに1つの疑問を割り当て、結論、判断材料、図表の役割を決めます。
STRUCTURE記事群での役割を決める
内部リンク、次に読む記事、更新トリガーを決め、単発で終わらない設計にします。
CONTEXTデザインシステムをつくる
主題に固有の比喩、配色、図表、余白、動きを決め、理解を速める視覚言語を用意します。
DESIGN本文とHTMLを完成させる
結論を先に示し、本文、図表、FAQ、出典、関連記事までを一つの完成稿にします。
BUILD12軸で全体を評価する
検索意図、正確さ、判断密度、重複、信頼性などを採点し、弱い部分を特定します。
REVIEW検索上の顔を整える
タイトル、メタ説明、見出し、リード文を再点検し、記事の約束と内容を一致させます。
SEO / AIO修正を全体へ反映する
局所的な差し替えで終わらせず、確定した変更を完成版HTML全体へ統合します。
INTEGRATE実装と公開前確認を行う
見出し階層、リンク、レスポンシブ、操作、フォールバック、禁止表現を最終確認します。
QA公開素材と運用を用意する
アイキャッチ、投稿文、初期確認項目を揃え、公開後に見直す条件を引き継ぎます。
PUBLISH
工程の詳細は記事ごとに変わりますが、公式一次情報を優先すること、実施していない体験を装わないこと、公開前に全体を再確認することは共通です。制作OSの内容を見る
03 / EVIDENCE
情報源だけでなく、断定の強さを管理する。
同じ公式ページでも、現在の仕様を直接示す記述と、条件によって変わる記述があります。出典を置くだけで終わらせず、その事実をどの強さで書けるかまで判断します。
SOURCE PRIORITY / 情報源の優先順位
- 01公式の製品・料金・ヘルプ
機能、価格、対象プラン、利用条件の確認に使います。
- 02公式ドキュメント・リリース
技術仕様、変更履歴、公開時期、実装条件の確認に使います。
- 03公式ステータス・規約
障害、提供範囲、利用上の制約、禁止事項の確認に使います。
- 04公式GitHub・原著論文
コードや研究に関する主張で、主題に必要な場合に参照します。
- 05信頼できる二次情報
背景や文脈の補助に限り、変わりやすい仕様の核心には置きません。
検索結果の要約、AIの回答、出典不明の転載は、事実を確定する根拠として扱いません。
ASSERTION CONTROL / 3つの記述区分
公式一次情報で、対象、値、条件を直接確認できる内容。根拠へつながる形で明確に書きます。
料金、上限、地域、段階提供など変化や条件差がある内容。確認日と条件を添え、範囲を限定します。
複数の公式情報から導く読み方、比較軸、推奨条件。公式発表と混同しないよう、判断であることを明示します。
通貨、税、地域、購入経路
名称、既定値、提供先
回数、容量、期間、例外
地域、言語、端末、プラン
Web、アプリ、管理画面
権利、禁止事項、データ利用
04 / EDITORIAL VALUE
詳しさではなく、判断材料を増やす。
公式情報の言い換えだけでは、読者が選べる状態になりません。企業ページだけでは埋まりにくい7つの空白を、個人メディアとして補います。
払う価値を判断する
機能の列挙ではなく、どんな使い方なら有料化の意味があり、どこまでなら無料で足りるかを条件で示します。
選ばない条件を書く
おすすめできない人、やめどき、切り替えどきまで含め、強い言葉だけで結論へ誘導しません。
競合との役割を分ける
勝敗だけを決めず、名前を挙げた選択肢ごとに、向く用途と任せる仕事を分けます。
散らばる公式情報を束ねる
料金、ヘルプ、規約、リリースなどに分かれた情報を、ひとつの疑問に答える順序へ編み直します。
曖昧さをほどく
製品名とモデル名、プランと機能、Webとアプリなど、公式ページを横断しないと分かりにくい違いを整理します。
限界と回避策を並べる
弱点だけを挙げず、避け方、代替手段、別の選択肢までを同じ場所で確認できるようにします。
条件から結論へ導く
判断フロー、比較表、計算例を使い、読者が自分の条件を当てはめて選べる形にします。
05 / AI BOUNDARY
AIは制作に使う。事実と結論は任せない。
生成AIは、調査、構成、執筆、実装を補助する道具です。AIの出力そのものを出典にせず、採用、棄却、断定、公開の責任は運営者が持ちます。
AIが補助すること
候補を広げ、構造を比較し、制作を速くするために使います。
- 検索意図と情報の空白の整理
- 公式情報の候補と確認項目の洗い出し
- 構成案、文章案、FAQ案の作成
- HTML、CSS、JavaScriptの実装補助
- 重複、矛盾、抜け漏れの検査候補
AIだけで決めないこと
もっともらしさと正しさを同一視しません。
- 事実が現在も正しいか
- 出典が主張を直接支えているか
- どの条件なら推奨できるか
- 断定の強さと例外の扱い
- 最終表現と公開の可否
人が引き受けること
記事の選択と結果に、編集主体として責任を持ちます。
- テーマと読者の課題を選ぶ
- 公式リンク、値、条件、日付を確認する
- 事実、慎重な記述、推論を分ける
- 不要な生成物を捨て、表現を整える
- 公開後の修正と更新を判断する
現在の標準工程では、実測、実機検証、スクリーンショットを記事の品質根拠として使いません。架空の画面、エラー、レビュー、数値、引用、画像の仮置きも作りません。公式一次情報と明示した論理で、読者が判断できる材料をつくります。
06 / EXPRESSION & BUILD
文章と図表に、別々の仕事を持たせる。
図表は本文の飾りや言い換えではありません。読む、比べる、選ぶ、確かめるという異なる行動を、適した表現へ分担させます。
本文
背景、条件、理由、例外を順序立てて説明し、結論までの論理を残します。
比較表
同じ軸で複数の選択肢を並べ、違いと判断条件を短時間で確認できるようにします。
判断フロー
「どの条件なら次へ進むか」を分岐で示し、読者自身の状況へ当てはめられる形にします。
情報ボックス
最終確認日、主要な公式情報、注意が必要な条件を本文から切り分けて示します。
出典・関連記事
根拠へ戻る経路と、次の疑問へ進む経路を分け、読み終えた後の行動を支えます。
WORDPRESS CONTRACT
内容と同じ厳しさで、表示を管理する。
通常の記事は本文幅最大860px、本文16px・行間1.9を基準とし、スマートフォンでは15px・行間1.85へ調整します。固定ページは役割に応じて最大1180pxまで使い、情報量と視線の流れを設計します。
- 01一つのHTMLとして完結
WordPressのカスタムHTMLブロックへ一度で貼れる単位にまとめます。
- 02CSSをページ内でスコープ
固有の接頭辞と一つのstyleに集約し、テーマや他の記事への干渉を防ぎます。
- 03JavaScriptがなくても読める
動きは補助にとどめ、失敗時も本文、リンク、図表の意味を失わないようにします。
- 04公開前にレスポンシブ確認
見出し、表、タップ領域、横あふれ、リンク、開閉操作を画面幅ごとに確認します。
- 05動きを止められる
prefers-reduced-motionを尊重し、アニメーションを情報理解の必須条件にしません。
このページのWebGLは、青い「公式根拠」と紫の「探索」が、中央の黄色い「人の判断」を通り、緑の「読者の行動」と土色の「公開・継続」へ変わる編集工程を抽象化したものです。珊瑚色は限界と注意点を示します。製品画面や検証結果を表すものではありません。
07 / QUALITY GATE
公開する前に、12の角度から疑う。
文章が整っているだけでは公開しません。読者の疑問へ答えているか、断定は妥当か、図表は判断に役立つか、次の行動まで設計できているかを全体で評価します。
点数は弱い箇所を見つけるための道具です。重大な事実誤認、根拠不足、禁止表現、実装不良があれば、合計点にかかわらず修正します。
- 01検索意図
読者が最初に解決したい疑問へ答えているか。
- 02情報の空白
公式情報の言い換えでなく、新しい判断材料があるか。
- 03判断密度
各見出しに選択や行動へ効く内容があるか。
- 04正確さと断定
根拠、条件、日付と書き方の強さが合っているか。
- 05非重複
同じ結論や説明を別の言葉で繰り返していないか。
- 06表現の役割分担
本文、表、フロー、ボックスが別々の仕事をしているか。
- 07約束の一致
タイトルとリード文の約束を本文が果たしているか。
- 08入口の明瞭さ
検索結果で記事の価値と対象読者が伝わるか。
- 09自己完結性
見出しの要点が文脈なしでも正確に伝わるか。
- 10内部リンク
読者の次の疑問へ、自然な文脈でつながっているか。
- 11信頼性
確認日、公式情報、中立性、限界が見えるか。
- 12読後の出口
読者が次に選ぶ、確認する、行動する場所があるか。
- STRUCTURE見出し階層、目次、ID、FAQの対応
- LINKS出典URL、内部リンク、リンク属性
- DISPLAYスマホ表示、横あふれ、操作、縮小時
- FALLBACKJavaScript停止、WebGL失敗、動きの軽減
08 / OPERATION
公開は終点ではなく、次の確認日。
生成AIを扱う記事は、公開時に正しくても古くなります。変わりやすい箇所を先に記録し、変更や誤りが読者の判断へ影響する場合に更新します。
見直すきっかけ
記事ごとに、古くなる可能性が高い情報を更新条件として残します。
- 料金、モデル、プラン、上限の変更
- 公式ページ、規約、提供地域の変更
- 重要なリンク切れやサービス終了
- 読者の判断を変える新しい公式情報
誤りへの対応
確認できた誤りは隠さず、影響する範囲を見て修正します。
- 値と条件を根拠へ戻って再確認する
- 結論へ影響する場合は周辺も書き直す
- 条件差が原因なら理解に必要な範囲で補足する
- 重要な修正は分かる形で反映する
関係を明示する
読者の判断へ影響し得る商業上の関係を、結論と混同しないよう扱います。
- 広告・アフィリエイトを含む場合
- 製品やサービスの提供を受けた場合
- 依頼に基づいて制作した場合
- その他の利害関係がある場合
報酬の有無と、記事の評価を同じものとして扱わない。
広告、アフィリエイト、提供、依頼などの関係がある場合は、該当記事で分かるように示します。広告配信、Cookie、アクセス解析等の取り扱いは、プライバシーポリシーと免責事項をご確認ください。
約束できること
- 01重要な事実は公式一次情報を優先して確認する
- 02事実、慎重な記述、編集判断をできる限り分ける
- 03実施していない体験や検証を装わない
- 04選ばない条件、限界、代替案も扱う
- 05確認できた誤りと重要な変更を見直す
約束できないこと
- 01すべての情報が将来も変わらないこと
- 02すべての地域、端末、プランで同じ結果になること
- 03サービス提供者による突然の変更や終了
- 04読者ごとの利用目的に対する絶対的な最適解
- 05外部サイトや外部サービスの継続的な正確性
READER FIRST / ALWAYS REVISABLE
読者が、自分で選べる状態まで。
誤り、リンク切れ、公式情報の変更、分かりにくい箇所がありましたらお知らせください。内容を確認し、必要に応じて修正します。
お問い合わせへ学べるブログ 編集方針MANABERU BLOG / EDITORIAL POLICY
制定内容は必要に応じて見直します。
LAST UPDATED / 2026.08.13