2026年8月から、フィールフロウはAIO実践シリーズ（AIOはAI Optimizationの略で、LLMOとも呼ばれます）を週1本のペースで制作してきました。検索とAI引用の関係から始め、SEOとの違い、自社サイトの技術監査、AI仕様駆動開発、記事構造のチェックリストまで、前半5本を一つずつ形にしました。
この記事では成果だけでなく、出典確認、構成、校正、公開準備で何に手間がかかったかを振り返ります。自社で記事制作を続けたい方が、そのまま工程設計に使える中間記録です。
結論：速く書くより、判断を分ける方が再現しやすい
要点：テーマ選定、一次資料の確認、構成、執筆、校正、公開境界の検証を分けると、修正理由を追跡できます。
5本を通じて効いたのは、AIに長い指示を渡して一度で完成させる方法ではありませんでした。先に「誰の、どの判断を助ける記事か」を決め、原典で事実を固定し、本文を書き、別の観点で校正し、最後に実際の配信面を確認する方法です。
結論ファースト、見出し直下の要点、FAQは読みやすさを揃える型として有効でした。ただし、型を満たすことと、内容が正しいことは別です。数字の分母、研究の対象、構造化データと可視本文の一致は、独立して確認する必要がありました。
表1：5本の制作記録を数字で見る
要点：完成稿5本には参考資料URL延べ24件、画像・図版12ファイル、FAQ20問があり、初期方針の大幅な見直しも1回ありました。
| 回 | テーマ | 参考資料URL | 画像・図版 | 制作上の主な負荷 |
|---|---|---|---|---|
| 1 | 検索順位とAI引用 | 4 | 2 | 実測中心から実践中心へ公開前に全面改稿 |
| 2 | SEOとAIO（LLMO）の違い | 5 | 3 | 用語を6つの比較軸へ整理 |
| 3 | 自社サイトのAI可読性監査 | 5 | 2 | 12項目を実サイトと成果物で照合 |
| 4 | AI仕様駆動開発 | 5 | 3 | 自社の7文書・10工程と公開研究を分離 |
| 5 | 記事構造チェックリスト | 5 | 2 | 18項目の再利用導線と非公開検査を実装 |
集計日は2026年8月31日です。参考資料URLは各記事末尾の「参考資料・データソース」にあるリンクを数え、同じ記事内の重複を除きました。延べ24件、シリーズ全体の重複を除くと19件です。画像・図版は各記事ディレクトリの本文以外のファイルで、横長カバー、正方形画像、記事内図解を含みます。FAQは各記事4問、合計20問です。
これは制作量の記録であり、引用されやすさや品質との因果を示すデータではありません。また、執筆時間を一貫して記録していなかったため、「1本あたり何時間」とは報告できません。ここを推測値で埋めないことも、今回の振り返りの一部です。
効いた型：事実、文章、公開を別の工程にする
要点：一つの原稿を何度も読み直すより、工程ごとに問いを変える方が見落としの場所を特定しやすくなりました。
最初に、対象読者、結論、独自情報、必要な一次資料を決めます。次に原典から、数値、対象、期間、指標、言い切れる範囲を整理します。本文では、各見出し直下に要点を置き、根拠と自社の解釈を分けます。執筆後は、日本語、事実、論理、用語、Markdown、既存記事との重複を別々に確認しました。
最後に、ビルド成功だけで終わらせず、記事詳細、一覧、サイト内検索、サイトマップ、RSS、OGP、構造化データを確認します。予約記事では、公開前に404かつ各掲載面に出ないこと、将来日時のプレビューでは完成形が見えることを対にしました。
文章制作の認知研究でも、計画、文章化、見直しはいずれも作業記憶の実行機能を使うと整理されています。ただし、この研究はAIO記事やAIとの共同執筆を直接検証したものではありません。私たちの工程分割に因果効果があると示す根拠ではなく、複数の判断を同時に抱えない設計と整合する知見として参照しています。
つまずき：書く前の前提が間違っていた
要点：最大の手戻りは文章表現ではなく、連載で何を実測できるかという企画前提の見直しでした。
当初は、複数のLLMへ同じ質問を繰り返し、引用変化を追う「実証シリーズ」を想定していました。しかし、短い連載期間、モデルごとの取得経路、回答の非決定性を考えると、記事施策との因果を責任を持って説明できません。そこで第1回の一般公開前に、定点計測の成果を約束する構成をやめ、制作・技術監査・運用設計を公開する「実践シリーズ」へ変更しました。
もう一つの失敗は、制作時間を工程別に記録しなかったことです。PR作成からマージまでの時間は確認できますが、調査や執筆の多くはPR作成前に進むため、工数の代わりにはなりません。見える数字だけで都合のよい生産性を作らない、と決めました。
後半5本で変えること
要点：後半は、完成稿だけでなく、どの工程に時間と修正が発生したかを再利用できる記録にします。
改善は4点です。
- Issueコメントに、調査開始、構成確定、初稿、校正完了の時刻を残す
- 原典の事実表を本文より先に作り、出典未確認の主張を初稿へ入れない
- 見出し直下の要点とFAQをテンプレート化し、内容に合わない項目は理由を記録して外す
- 公開前404と公開後200を同じURLで確認し、「マージ済み」と「一般公開」を分けて報告する
これにより、後半では「速くなった気がする」ではなく、工程別の時間、修正件数、公開境界の結果を比較できます。数字が改善しなくても、どこに負荷が残るかを説明できる状態を目指します。
FAQ
要点：最初から大きな運用を作らず、対象読者、一次資料、校正観点、公開確認の4点から始めます。
Q. 少人数でも同じ工程を使えますか？
使えます。担当者を分けられなくても、調査、執筆、校正を時間で分け、各工程で見る観点を固定すると混同を減らせます。
Q. すべての記事にFAQが必要ですか？
必要とは限りません。読者が本文だけでは確認しにくい疑問がある場合に使います。検索向けの項目数を増やすためだけに作らず、本文と同じ内容を簡潔に答えます。
Q. AIに任せると一番短縮しやすい工程はどこですか？
今回の記録では工程別時間を測っていないため、断定できません。候補出し、構成案、表現の比較には使いやすい一方、出典の原文確認と公開結果の判断は人が責任を持ちます。
Q. 最初に記録する数字は何ですか？
工程別の開始・終了時刻、初稿後の修正件数、参照した一次資料数の3つから始めます。閲覧数やAI引用は公開後の結果として分け、制作効率と混ぜません。
まとめ
要点：5本で得た一番大きな学びは、記事の型より、判断と証拠を工程ごとに残すことでした。
結論ファースト、出典、FAQ、構造化データは、単独で引用を保証する技法ではありません。誰に何を伝え、どこまで確認し、いつ公開されたかを追えるようにする部品です。後半5本では、完成物だけでなく制作時間と修正の記録も残し、再現できる運用へ更新します。
参考資料・データソース
確認範囲：制作記録はリポジトリとGitHub、文章制作の整理は原著論文の要旨を確認しました。
- FEEL-FLOW「AIO実践シリーズ前半5本」 — 上表の各記事とGitHub PR #1000、#1008、#1358、#1541、#1646、#1649。記事ファイル、参考資料URL、制作物、編集履歴を2026年8月31日に確認・集計。
- Kellogg, R. T., Whiteford, A. P., Turner, C. E., Cahill, M., & Mertens, A. (2013). Working memory in written composition: A progress report. Journal of Writing Research, 5(2), 159–190. Abstractの計画・文章化・見直しと中央実行系に関する整理を2026年8月31日に確認。