AirOpsで記事制作を工程に分ける方法｜人が止める関所の置き方

「生成AIで記事を書かせているが、毎回だれがどこを見たのか分からない」「量は増えたが、ブランドの言い方がばらばらになってきた」——記事制作に生成AIを取り入れたコンテンツ担当と、その上長からよく聞く声です。どちらも、書かせ方の工夫で直そうとすると行き詰まります。足りないのは文章の質ではなく、工程の形です。本当は、誰がどこで止めて確かめるかという関所の位置を先に決めないと、道具に工程を載せても責任の所在は見えないままです。この記事では、日本語の解説がまだほとんどない AirOps を例に、記事制作を工程に分けるときの関所の置き方と、CMSへの書き込み権限の持たせ方を整理します。

AirOpsは何をする製品か

AirOps は、記事などのコンテンツの制作を、いくつもの工程をつないだ流れとして組み立てる道具です。2026年10月時点の公式の説明では、AIによる回答と従来の検索の両方での見え方を調べる機能、ブランドの声と決まりをまとめておくブランドキット、自社の知識をまとめたナレッジベース、公開の前に置く人の確認の関所が、主な部品として挙げられています。

調べる側の機能（Insights）は、AIの回答で自社がどれだけ引用・言及されているか、競合との比較、Google の検索の管理画面（GSC）とGA4のデータをまとめて見るものと説明されています。見え方を追う対象として、ChatGPT・Claude・Gemini・Perplexity・Google のAIによる概要などが挙げられています。

作る側では、複数の生成AIのモデルを工程ごとに選び、ブランドキットとナレッジベースを参照させながら、調査・構成・執筆を進めます。公式の連携の説明によれば、工程は確認の段で止まり、作業が受信箱に回され、確認者が直すか承認すると再開します。コメント、修正の提案、版の比較、巻き戻しもできるとされています。

書き上げた記事は、CMSとの連携でそのまま公開できます。公式の会社情報では、連携先として WordPress・Webflow・Contentful・サニティが挙げられています。調べる・作る・公開する・測るが1つの道具の中でつながっていることが、この製品の特徴であり、同時に関所の設計が要る理由でもあります。

作っている会社と、国内でまだ知られていない理由

公式の会社情報によれば、AirOps を運営するのは2022年に創業した米国の非上場企業で、拠点はニューヨークとサンフランシスコです。2025年11月に、ベンチャーキャピタルのグレイロックが主導する4,000万ドルのシリーズBの資金調達を発表しています。2026年10月時点で、提供の終了や名称の変更、買収の告知は確かめた範囲では見当たりませんでした。

国内でまだ知られていない理由の1つは、確かめた範囲では、公式サイト・ヘルプ・学習用の教材がすべて英語であることです。もう1つは、この製品が「AI検索で引用されるためのコンテンツを、工程として量産する」という、海外で先に広がった考え方を前提にしている点です。公式は、こうした仕事を担う人を「コンテンツエンジニア」と呼び、育成の講座まで用意しています。

料金は、処理の回数（タスク数）で数える3つの段で、無料の段もあると公式の会社情報にあります。費用は記事の本数より、工程の数と書き直しの回数で増えていく形です。工程を細かく分けるほど、1本あたりの処理の回数が増える点は、導入前に押さえておきたいところです。

この記事では、製品の機能を順に紹介することはしません。AI検索での見え方を数字で追う道具そのものの話は、同じ便の別の記事で扱っています。ここで扱うのは、記事制作をこの種の道具に載せるときに、マーケの部門で決めておく関所と権限の線です。

工程に分けても、責任の置き場所は変わらない

工程の道具を入れると、制作の流れが目に見えるようになります。調査の結果、構成、下書き、修正の履歴が工程ごとに残り、誰がどの段で何をしたかを後から追えるようになります。冒頭の「毎回だれがどこを見たのか分からない」という悩みには、この見える化がそのまま効きます。

ただし、見えるようになることと、責任が決まることは別です。工程の道具は、止める場所を設定すれば止まり、設定しなければ流れます。記事の内容に責任を持つのは、道具でも、道具を設定した人でもなく、公開を決めた人です。この前提を部門で共有しておかないと、「工程に載っているから大丈夫」という思い込みが生まれます。

もう1つ変わらないのは、事実の確かさです。工程の中でAIに調査をさせても、AIが拾った数字や固有名詞が正しいとは限りません。工程が整うほど、下書きの見た目は整い、誤りが目立たなくなります。整った下書きほど、事実の確認を省きたくなることを、最初から織り込んでおきます。

つまり、工程に分ける目的は、作業を速くすることと同じくらい、人が止める場所を固定することにあります。ここから先は、その場所の決め方を順に見ていきます。

工程表の作り方：今の制作を6つの工程に書き出す

最初に、今の記事制作を工程に書き出します。道具の画面で組み始める前に、紙や表で書き出しておくほうが、関所の位置を落ち着いて決められます。多くの会社の記事制作は、次の6つの工程に分けられます。

書き出すときは、工程ごとに「誰が担当するか」「何を受け取って、何を渡すか」「止める条件は何か」の3つを1行ずつ添えます。たとえば調査の工程なら、受け取るのは狙う問い、渡すのは出典つきの調査の要約、止める条件は出典の無い主張が混ざっていること、という具合です。

工程を細かく分けすぎないことも大切です。前の節で触れたとおり、工程の数は処理の回数、つまり費用に響きます。人が止める場所の前後で工程を区切り、それ以外はまとめるのが、費用と見通しのつりあいを取りやすい分け方です。

関所1 事実と数字の確認を、執筆の直後に置く

1つ目の関所は、執筆の直後に置く事実と数字の確認です。ここで止めるのは、AIの下書きに入った数字・固有名詞・日付・引用が、出典と合っているかです。公開の直前ではなく執筆の直後に置くのは、誤りが後の工程に流れるほど、直す手間が増えるからです。

確認の関所を置くときは、確認する人が出典を開いて照らし合わせられるように、調査の工程で出典の場所を必ず残させます。出典の無い数字は、確認の関所で一律に削るか保留にする、という決まりにしておくと、確認する人の判断が揺れません。

AIに確認の下書きをさせることはできます。たとえば、下書きの中の数字と固有名詞を一覧にして、出典の該当箇所と並べるところまでは、工程に組み込めます。ただし、一覧を見て「合っている」と判断するのは人です。AIが出典を読み違えていれば、一覧そのものが誤ります。

確認の関所で止まった記事が溜まりやすいのも、この関所の特徴です。確認する人が1人だと、そこが詰まります。記事の種類ごとに確認する人を決め、急ぎの記事の扱いも先に決めておきます。

関所2 ブランドの言い方：ブランドキットに任せる範囲と人が見る範囲

2つ目の関所は、ブランドの言い方の確認です。AirOps の公式の説明では、ブランドキットは、エージェントや道具が参照するブランドの声と決まりを、統制された形で持つ仕組みとされています。冒頭の「ブランドの言い方がばらばらになってきた」という悩みには、ここが効きます。

ブランドキットに任せやすいのは、表記の揺れ、使わない言葉、文体の調子のような、言葉で決まりにできる部分です。逆に、自社の主張として言い切ってよいか、他社と比べる書き方が行き過ぎていないかは、決まりの文章だけでは判断できません。この部分を人の関所で見ます。

ブランドの関所で見る人は、マーケの中でブランドを預かる人か、広報の担当が向いています。事実の関所と同じ人が兼ねると、見る観点が混ざって両方が浅くなります。事実の関所とブランドの関所は、できれば別の人に持たせるのが理想です。人手が足りない場合は、同じ人でも見る順番と観点を分けて、2回見る形にします。

ブランドの関所で何度も直した箇所は、ブランドキットの決まりに書き足す候補になります。人が直した内容を決まりに戻していくと、関所で直す量が少しずつ減ります。編集の決まりそのものの作り方は、編集ガイドラインの記事で扱っています。

ブランド資料として渡してよいもの・渡さないもの

ブランドキットやナレッジベースに資料を入れると、その中身は工程の中で生成AIのモデルに渡されます。AirOps の公式ドキュメント（2026年10月時点）には、モデルの提供元に送ったデータはその提供元の保持の方針に従う、と書かれています。

同じドキュメントでは、OpenAI はAPI経由で送られた情報を学習に使わないこと、OpenAI のデータを保持しない扱いはエンタープライズ契約の顧客に限られることが示されています。一方で、他のモデルの提供元の扱いは、確かめた範囲のドキュメントには書かれていませんでした。工程ごとに複数のモデルを選べる道具なので、どの工程でどの提供元のモデルを使うかによって、データの行き先が変わります。

このため、ブランド資料として渡すものは、社外に公開しても困らない資料を基本にするのが安全です。公開済みの記事、会社案内、表記の決まり、ブランドの声の説明などです。未発表の製品の情報、顧客の名前が入った事例の下書き、社内の数字は、渡す前にマーケの上長と情報管理の担当で可否を決めます。

AirOps 自体の安全面については、公式ドキュメントに、SOC2タイプ2の報告書を秘密保持契約のもとで提供すること、保存時と通信時の暗号化、標準契約条項つきのデータ処理契約があることが書かれています。社内の審査には、これらの書類の取り寄せを、導入の手続きに入れておきます。

関所3 公開の判断：自動公開はしない

3つ目の関所は、公開の判断です。CMSに直接書き込める道具では、確認の関所を通った記事がそのまま公開されるように組むこともできます。しかし、公開の判断は、事実とブランドの関所とは別の、独立した関所として残します

公開の関所で見るのは、記事単体の正しさではなく、公開してよい状況かどうかです。たとえば、同じ問いに答える既存の記事と食い違っていないか、公開の時期が発表や広報の予定とぶつからないか、法務の確認が要る内容が含まれていないか、といった点です。これらは、記事の外の事情を知っている人にしか判断できません。

公式の連携の説明には、工程は止まって受信箱に作業を回し、確認者が承認すると再開するとあります。公開の関所は、この承認を公開の権限を持つ人だけが押せる形にしておきます。確認の関所を通ったら自動で公開、という組み方は、少なくとも運用が安定するまでは使いません。

公開の関所には、もう1つの役目があります。公開した記事の一覧と承認した人の記録を残すことです。後から「この記事は誰の判断で出たのか」と聞かれたときに、工程の記録と承認の記録が揃っていれば、説明に困りません。

関所ごとの確認項目

3つの関所で何を確かめるかを、表にまとめます。自社の記事の種類によって項目は変わるので、部門で話し合うときのたたき台として使ってください。

関所	確かめること	見る人	止める条件
事実と数字	数字・固有名詞・日付・引用が出典と合っているか	記事の担当編集	出典の無い数字がある・出典と食い違う
事実と数字	製品や制度の情報に時点が書かれているか	記事の担当編集	時点の無い仕様の説明がある
ブランドの言い方	自社の主張として言い切ってよい内容か	ブランドを預かる人	根拠の無い言い切り・他社への行き過ぎた比較
ブランドの言い方	表記と文体が決まりに沿っているか	ブランドを預かる人	決まりから外れた表現が繰り返し出る
公開の判断	既存の記事・発表の予定・法務の確認と食い違わないか	公開の権限を持つ人	既存の記事と食い違う・法務の確認が終わっていない
公開の判断	承認の記録が残るか	公開の権限を持つ人	承認者が記録されない

表の「止める条件」は、関所で迷わないための物差しです。止める条件に当たったら、その場で直すか、前の工程に戻すかを決めます。止める条件に当たった件数を月ごとに数えると、どの工程の設定を直すべきかが見えてきます。

項目を増やしすぎると、関所が形だけになります。1つの関所で見る項目は、最初は2〜3個に絞り、見落としが出た種類だけを足していきます。

CMSへの書き込み権限を誰に持たせるか

CMSとつなぐときは、道具にどの権限で書き込ませるかを決めます。公式の連携の説明では、CMSとの連携は項目の対応・構造・記事のIDを保ったまま公開できるとされています。つまり、新しい記事を足すだけでなく、既存の記事を書き換えることもできる前提で考えておく必要があります。

線を引くのは、道具の接続に使うアカウントの権限を、CMSの側で下書きの保存までに絞れるかを確かめることです。WordPress であれば、利用者の役割ごとに、公開できるかどうかが分かれています。道具の接続用に専用のアカウントを作り、公開の権限を持たない役割にしておけば、公開の関所を人の手に残せます。道具の側の設定で公開まで進められても、CMSの側で止まる形です。

下書きまでに絞れない構成になる場合は、接続を使う工程を公開の関所の後ろに限り、承認の権限を持つ人を少数に絞ります。どちらの形でも、接続の鍵を誰が発行し、誰が持ち、いつ見直すかを、情報システムの担当と決めておきます。

接続用のアカウントを個人のアカウントで代用しないことも大切です。担当者が異動したときに接続が切れたり、逆に退職した人の権限で書き込みが続いたりします。専用のアカウントにしておけば、止めたいときに1か所で止められます。

外の道具からつなぐ入口も関所の外に置かない

AirOps には、工程の画面の外から機能を呼び出す入口もあります。公式の会社情報によれば、MCP（AIの道具と外部の仕組みをつなぐ共通の決まり）での接続を通じて、ブランドキットや調べる側の機能を、Claude・ChatGPT・Cursor などの道具から使えるとされています（2026年10月時点）。公式の連携の説明でも、開発者向けの編集の道具などが接続先として挙げられています。

この入口は便利な反面、関所の設計に穴を開けることがあります。担当者が自分のAIの画面からブランドキットを呼び出して記事を書き、そのまま手作業でCMSに貼り付ければ、工程の中の関所を1つも通らずに公開まで進めてしまいます。関所を通るのは、道具の工程の中で作った記事だけだという点を、部門で共有しておく必要があります。

線を引くのは、外の道具でつないで作った文章も、公開の前には同じ関所を通すという決まりです。あわせて、MCPでの接続を許す人を決め、接続に使う鍵を個人の道具にどう渡すかを、情報システムの担当と確かめておきます。外の道具で作ったものを関所の受信箱に戻す手順が決まっていれば、入口が増えても関所は1つのままで済みます。

公式の連携の説明には、大きな変化が起きたときに処理を始める仕掛けがあることも書かれています。自動で始まる工程は、気づかないうちに下書きを増やします。自動で始めてよいのは下書きまでで、公開の関所は自動の流れに含めないと決めておけば、きっかけが増えても公開の判断は人に残ります。

既存記事の書き直しを工程に載せるときの注意

工程の道具は、新しい記事だけでなく、既存の記事の書き直しにも使えます。効果測定の結果から書き直しの候補を出し、調査と執筆の工程をもう一度回すという使い方です。記事の数が多いメディアほど、この使い方の効き目が大きくなります。

注意したいのは、書き直しは新しい記事より関所を通りにくいことです。元の記事を書いた人がもういない、元の記事の出典が古くなっている、書き直しで主張が変わっていることに気づきにくい、といった事情が重なります。書き直しでは、前の版との差分を関所で必ず見ることを決まりにします。公式の説明には版の比較と巻き戻しの機能が挙げられているので、これを関所の手順に入れておきます。

書き直しが既存の記事のIDを保ったまま反映される場合、公開済みの記事が一度に書き換わります。何本もまとめて書き直すときは、1本ずつ公開の関所を通し、まとめて流さないようにします。

書き直しの対象の選び方そのものは、AIに候補を出させてよい部分です。ただし、どの記事を書き直すか、どの記事は書き直さずに残すかは、メディアの方針を知っている人が決めます。

効果測定と書き直しの周期

工程の最後は効果測定です。AirOps の調べる側の機能は、AIの回答での引用や言及、検索の管理画面とGA4のデータをまとめて見るものと説明されています。これを、書き直しの候補を出す材料にします。

周期は、記事の種類ごとに決めます。製品や制度の情報を扱う記事は、事実が古びるのが早いので短く、考え方を扱う記事は長めにします。周期を決めずに数字だけを見ていると、数字が少し動くたびに書き直しが回り、関所の負担と処理の回数だけが増えます。

AIの回答での見え方は、モデルの更新や質問の言い方で揺れます。1回の測定で上がった・下がったと判断せず、一定の期間の傾向で見るのが基本です。数字の変化を施策の成果と呼ぶかどうかは、人が決めることです。道具が出す数字は、判断の材料であって結論ではありません。

効果測定の結果は、公開の関所を持つ人と、ブランドの関所を持つ人にも共有します。どの関所で直した記事が、どのくらいの見え方になったかを並べて見ると、関所で見る項目の見直しにもつながります。

関所が形だけになる兆しと立て直し方

工程と関所を決めても、時間がたつと関所が形だけになることがあります。承認の手間が少ない道具ほど、確認せずに承認を押す癖がつきやすくなります。兆しを早めにつかむために、次のような状態を見張っておきます。

• 関所で止まった記事が、修正の無いまま数分で承認されている
• 確認する人が、出典を開かずに下書きの見た目だけで承認している
• 急ぎの記事だけ関所を飛ばす運用が、いつの間にか常態になっている
• 書き直しを何本もまとめて流し、差分を見ずに公開している

立て直しの基本は、関所で見る項目を減らし、見る人を増やすことです。項目が多すぎると、全部を形だけ見ることになります。見る項目を2〜3個に戻し、その代わり確実に見る、という形に組み直します。

承認までの時間と、関所で直した件数を月ごとに見るのも有効です。直した件数がゼロの月が続く関所は、本当に問題が無いのか、見ていないだけなのかを確かめます。関所を通った記事から何本かを抜き取り、別の人が見直すと、形だけになっているかどうかがはっきりします。

止め方：工程を止める・接続を切る・畳む

導入の前に、止め方を決めておきます。止め方には段階があります。1つの工程を止める、CMSへの接続を切る、道具の利用そのものを畳む、の3つです。誰がどの段階の判断を持つかを決めておくと、問題が起きたときに迷いません。

誤った内容の記事が公開されたときは、まずCMSへの接続を切り、道具からの書き込みを止めます。前の節で触れた専用のアカウントにしておけば、そのアカウントの権限を外すだけで止まります。そのうえで、公開済みの記事を直すかどうかを、公開の関所を持つ人が決めます。

利用を畳むときは、道具の中に置いた資料と記録の扱いを確かめます。公式ドキュメントには、契約の終了後30日で顧客のデータを完全に削除するとあります（2026年10月時点）。ブランドキットの決まり、工程の設計、承認の記録のうち、自社に残したいものは、終了の前に書き出しておきます。

止め方を決めておくことは、導入の判断を軽くすることにもつながります。いつでも止められると分かっていれば、小さく試してみる判断がしやすくなります。

最初の3か月の進め方と導入前の確認

最初の3か月は、記事の種類を1つに絞って試すのが現実的です。たとえば、製品の用語を解説する記事のように、型が決まっていて事実の確認がしやすい種類から始めます。1か月目は工程と関所の設計、2か月目は本数を少しずつ増やし、3か月目に関所で止まった件数と承認までの時間を振り返ります。

振り返りでは、記事の本数より、関所で何が止まったかを見ます。事実の関所で止まる件数が多ければ、調査の工程の出典の残し方を直します。ブランドの関所で止まる件数が多ければ、ブランドキットの決まりを書き足します。導入の前には、次の項目を部門で確かめておきます。

• 今の記事制作を6つの工程に書き出し、関所を置く3か所を決めた
• 事実・ブランド・公開の関所ごとに、見る人と止める条件を決めた
• ブランド資料として渡してよい資料と、渡さない資料の線を引いた
• 工程ごとに使うモデルの提供元と、その提供元のデータの扱いを確かめた
• CMSへの接続用に専用のアカウントを作り、公開の権限を持たせない形にした
• 接続の鍵を誰が発行し、誰が持ち、いつ見直すかを情報システムの担当と決めた
• 工程を止める・接続を切る・畳むの判断を持つ人を決め、残したい記録を書き出せるようにした

この確認を終えてから工程を組み始めると、道具の画面で迷う時間が減ります。道具の設定は、決めたことを写す作業になります。

まとめ

AirOps のような記事制作の工程の道具は、調査から構成・執筆・公開・効果測定までを1つの流れにまとめ、途中に人の確認を待たせることができます。2026年10月時点では、ブランドキットやCMSとの直接の連携も備えています。それでも、事実と数字の確認、ブランドの言い方、公開の判断の3つの関所をどこに置き、誰が見るかは、道具ではなく部門が決めることです。下書きと調査はAIの工程、事実・数字の確認と公開の判断は人の関所。CMSへの書き込み権限は公開の関所を持つ人に限り、自動公開はしない。この線を先に引いておけば、量を増やしながら、誰がどこを見たかを説明できる制作の形が作れます。まずは、今の記事制作を6つの工程に書き出し、止める場所に印を付けるところから始めてみてください。

• 製品の機能・連携先・データの扱いは、AirOps の公式サイト、公式の会社情報、公式ドキュメントを2026年10月14日に確かめた範囲に基づきます。仕様や料金の段は変わることがあるため、導入前に最新の公式情報を確かめてください
• 生成AIのモデルの提供元ごとのデータの保持と学習の扱いは、それぞれの提供元の規約で確かめてください。社外秘の資料を渡すかどうかは、情報管理の担当と決めてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。