オウンドメディアの記事制作は、社内が読者の問い・自社の事実・公開の判断を持ち、外注が調査・取材・執筆・編集を担うよう工程ごとに分けます。「記事を作る」という一括の依頼では、誰が技術条件を確認し、誰が公開後に直すかが抜けやすくなります。
最初に作るのは、発注本数の一覧より、一つの記事の分担表です。営業の相談から企画を決め、技術者への取材、下書き、確認、公開、修正までたどります。各工程で渡すものと、次へ進める条件を決めてください。
どの仕事を社内に残す?
自社が何を受けられるか、公開してよいかは、外の書き手だけでは判断できません。社内に文章を書く人がいなくても、この確認をする人は必要です。営業や技術者が知っている事実を、外注が読者に伝わる文章へ整える形にします。
以下は分担を決めるための表です。会社の体制に合わせて担当を置きます。法務部門がなければ、契約や表示を確認できる社内の責任者を決め、判断できない点を相談する先も用意します。
| 工程 |
社内が持つこと |
外注へ任せること |
| 企画 |
問いと自社の対応範囲の決定 |
検索調査・構成案・重複確認 |
| 取材 |
経験・資料・公開範囲の提示 |
質問設計・聞き取り・整理 |
| 執筆 |
自社の事実への回答 |
原稿・図表案・出典の整理 |
| 確認 |
技術・法務・公開の承認 |
未確認箇所の提示・修正 |
| 公開後 |
事業の変更通知・修正承認 |
検索語の確認・改善案・入稿 |
外注先に技術知識があっても、自社設備の現在の対応範囲まで知っているとは限りません。経験のある書き手を選ぶことと、自社の事実確認を省くことは別です。社内の確認者が不在なら、原稿は公開待ちにします。
企画では、誰が問いを決める?
営業が実際に受けた質問を出し、外注が検索される言葉や既存記事との重なりを調べます。社内は、読者の困りごとと、自社が答えられる範囲を確認します。検索される量だけで、自社が受けられない依頼の記事を優先しないようにしてください。
製造業なら「図面が固まっていなくても加工を相談できるか」という問いを想定できます。企画を承認する前に、相談だけは可能なのか、概算を出せるのか、正式な見積もりには何が必要なのかを社内で確かめます。これは制作工程を考える例で、実際の受付条件を示すものではありません。
問いが決まったら、記事で答える範囲、読んだ後に進む窓口、確認する技術者を書きます。既存記事が答えているなら、新記事ではなく修正にします。似た問いの言い換えで本数を増やすより、読者が必要な答えを一つのページで見つけられるかを見ます。
企画書には、題だけでなく、冒頭で答える一文も入れてもらいます。その一文に自社で確認できない条件が含まれていたら、取材前に問いの範囲を修正できます。費用や料金の考え方はオウンドメディアの費用を決める要素で扱い、ここでは確認の仕事を誰が持つかを決めます。
取材で、社内は何を渡す?
外注には、自社が答えられる事実と、まだ確認できていない点を分けて渡します。設備の仕様、実際の作業で判断した条件、断る依頼の範囲などです。話した内容がすべて公開可能とは限らないため、取材時に公開範囲も確認します。
聞き手には、一般論だけでなく、判断の理由と例外を聞いてもらいます。「対応可能」という答えには、材質や形状などの条件が付くのか。その条件を原稿で落とすと、実際には受けられない問い合わせにつながります。
質問の型や聞く順番は技術者への聞き取りから記事を作る手順にまとめています。分担として決めるのは、誰が資料を準備し、誰が取材内容の不足へ回答するかです。取材後の追加質問を受ける窓口も社内で決めておきます。
録音やメモを納品してもらうなら、原稿のどの記述がどの発言に基づくかを追える形にします。技術者が言っていない条件を、書き手が自然な説明として足していないかを確認できます。顧客名や図面など、公開できない情報を原稿へ移さないことも、受け渡し時に明記します。
執筆と確認は、どう分ける?
書き手は、問いへの答え、条件、理由、相談前の準備を読める順に整えます。社内の技術者へは、日本語の校正だけを頼まず、技術的な正しさと適用範囲の確認を依頼します。法務や契約の確認は、技術確認とは分けます。
確認する範囲を曖昧にしないため、原稿の受け取り時に次のものをそろえます。
- 本文と、冒頭の答えが分かる構成
- 数字や外部仕様の出典URLと確認日
- 自社の発言や資料を根拠にした箇所
- 未確認の事項と、回答してほしい質問
- 読者が進む製品ページや相談窓口の案内
数値は、値だけでなく単位、時点、測定条件まで確認します。取材で出た数値でも、根拠となる記録を確認できなければ掲載しません。技術用語を読みやすく直した結果、意味が広がっていないかも見ます。
法務などの確認では、公開権限、守秘情報、他社の文章や図の扱い、誤解を招く表示を点検します。社内で判断できない箇所は、そのまま公開承認へ回しません。確認者が返した指摘を反映した後、意味の変わる修正はもう一度本人へ戻します。
文章が読みやすいことと、事実が確認済みであることは別の完了条件です。最終稿には、誰の確認が済んでいるかと、残った未確認事項を示してもらいます。公開する人が、原稿の見た目だけで判断しないようにしてください。
AIで下書きを作る工程は任せられる?
GoogleのAI生成コンテンツに関する説明は、制作手段よりコンテンツの品質を重視しています。生成AIを使う際の公式ガイダンスでは、価値を加えずに大量のページを生成するとスパムポリシーに違反する可能性があると説明し、公開前に人が事実を確認するよう求めています。対象にはタイトルや説明文などの情報も含まれます。AIで下書きを整える工程を任せても、自社の経験、仕様、対応条件を推測で補わず、出典と取材内容に戻って確認する分担を残します。
外注先とは、AIへ渡してよい資料、事実確認の担当、下書きにない説明を追加するときの確認方法を決めます。整った文章だから承認するのではなく、元の資料と一致しているかを読みます。専門家らしい表現でも、実際の経験に基づくとは限りません。
公開したら、制作の仕事は終わり?
記事の修正と、事業情報の更新を誰が持つかまで決めます。設備や受付条件が変わったときに社内から知らせる担当と、対象記事を探して修正する担当が必要です。外注契約が初稿の納品で終わるなら、その後の作業を社内で引き継ぎます。
私たちは自社メディアの運営で、新しい記事から既存記事へリンクを張る一方、既存記事から新しい記事へ張り忘れる失敗をしました。出典は自社メディアの運営記録です。原稿の納品だけを完了とせず、関連する既存ページから読者が進めるかも確認する理由です。
公開担当へ渡す確認表には、本文、表示される題と説明文、内部リンク、相談先を含めます。記事で案内する受付条件と、フォームの注意書きが合っているかも見ます。技術者が本文だけを確認していても、窓口との食い違いは残りえます。
Search Consoleで実際の検索語が分かったら、本文がその問いに答えているかを点検します。一般的な追記で済むのか、技術者への再取材が必要なのかを分けて修正します。表示やクリックを見て直す判断は公開後の記事を修正する手順へ進めます。
発注前に、何を合意しておく?
企画案の提出だけなのか、取材と執筆までなのか、技術確認の往復や入稿も含むのかを書面でそろえます。修正回数だけを決めても、事実確認待ちの期間や追加取材の扱いは決まりません。確認が止まったときの連絡先と、公開を保留する条件も共有します。
成果物は原稿だけでなく、出典、取材内容、未確認事項、公開後の修正記録まで引き継げる形にします。担当が変わった後に、なぜその条件を書いたかを調べ直さなくて済みます。自社の事実を一度整理すれば、次の記事でも同じ条件を確認する手間を減らせます。
次に制作する記事を一つ選び、企画から修正まで表の各行へ担当を入れてください。オウンドメディアの構築と運用は、社内の知識を外へ伝え続ける仕事です。空欄になった工程を埋めてから任せる範囲を決めると、原稿が確認待ちのまま止まる理由も見つけられます。
仕様・出典の確認日:2026年10月22日。