編集制作の工程を分解する——AIエージェント編成で柔軟性とスピードを両立した話

「サイボーグジジイになりたい」と願いながら、AIを仕事に活用しているアラ還編集記者です。テック系メディアやエンタープライズIT関連の取材・編集を行いながら、株式会社アンジーという編集プロダクションを経営しています。1969年生まれ、2029年に還暦。誕生日が来るたびに「また体力のメーターが1段下がった」と実感する一方で、AIをいじり倒した分だけ仕事の幅は広がっています。

さて、ここまでの連載では、AIへの記事制作業務指示（プロンプト）を記したファイルCLAUDE.mdに書き溜めた内容を紹介してきました。前回の第9回(人とAIによる校正・校閲の分業)でも触れましたが、現在はそのファイルを「クラシック環境」としてアーカイブして、次のステップに進んでいます。

それが、今回ご紹介するAI編集部OS(ai-editorial-os)。記事の編集制作の工程をバラバラに分解して、AIエージェントの編成として組み直しています（GitHubで無料公開中です）。

さまざまな役割を、AIエージェントとして自律駆動させて、まるで編集部のようなチームを作りたいと思ったのです。これまで1本道だった制作フローが、選んだ場所から始められるように変わる。空き時間に並走で別の工程を進められる。人の脳みそが空いて、企画と取材、そして仕上げという人間にしかできない仕事に集中できるという世界を目指しています。

ただし、行く道は綺麗にできていたわけではありません。日々改善を繰り返しています。現時点で、大きく3種類の自動化パイプラインができあがっています。

• 準備段階：資料の収集（リサーチ）〜記事の構成〜質問票づくり

• 素材整理段階：日本語・英語の文字起こし〜クレンジング（誤認識の修正など）

• 執筆段階：資料と文字起こしから、記事構成〜執筆〜ファクトチェックまで

その間、数々の失敗もありました。失敗談は別の機会に紹介するとして、今回はAI編集部OSを開発するに至った経緯と、エージェント構成についてお話しします。

CLAUDE.md一枚岩は、本当に1本道だった

私は、2020年から文字起こしAIを、そして2022年末から生成AIを使い始め、6年間で3500本以上の記事制作にAIを活用してきました。クラシック環境のCLAUDE.mdは、2022年末からの生成AI活用のころから継ぎ足ししてきた「秘伝のタレ」ともいえる指示書でした。

2026年3月にClaude Codeを使い始めてから、CLAUDE.mdとは別に、それまで社内向けWebアプリとして活用していたAI文字起こしサービスのエージェントを作ったのが、新しい制作パイプライン「AI編集部OS」づくりのはじまりでした。

以前のやり方で気づいたのは、「これ、1本道だな」　ということ。記事の編集制作の工程は、ざっと並べると9段階あります。リサーチ → 企画概要 → 企画詳細 → 取材 → 文字起こし → クレンジング(誤認識の修正・話者の整理)→ 執筆 → ファクトチェック → 公開。Claude Code導入以前は、これがガッツリ直列で動いていました。AIに任せていい工程と、自分が動かないとどうにもならない工程が、ベルトコンベアの上に一緒に並んで進行します。

たとえば取材直後。私の頭の中はインタビューの記憶でほやほやになっていて、本当はその熱が冷めないうちに音声を聞き返してメモを作りたいときもあります。同時に、文字起こしテキストも作りたい。執筆の下準備もしたい。ところが、CLAUDE.md一枚岩の処理では、常に私がトリガーとなり、ひとつひとつすすめなければなりません。何事も、私なしには始まりません。

「AIだけで自律的に進められる工程と、人間が手を入れる工程を、もっとはっきり分けられないか」

正直に言うと、CLAUDE.md一枚岩のやり方には何年もかけて慣れ親しんでいて、本音では「動いているのだから変えなくていい」と思っていました。それでもエージェントチーム化に踏み込んだのは、ここからもう一段進化したい、AIエージェントが活躍する世界を自分の手で体感したいという欲求が湧いてきたからです。差別化のために新しいものを取り入れていくのは、これまでもずっと続けてきたスタイル。将来への投資のつもりで、自分から飛び込むことにしました。

Xを眺めていると「AIエージェントに自律的に動いてもらって助かっている」という発信もよく見かけます。記事制作領域ではあまり見かけませんでしたが、「AI編集部つくりたいな〜」と思ったのです。

たとえば、インタビュー後、私が記憶を頼りに音声を聞き返している傍らで、AI編集部が文字起こしから草稿生成までを自律で進めてくれる——そんな並走が成立すれば、初稿が驚くほど早くできる。老体なので、せめて頭だけはスッキリさせ、AIにコツコツ動いてもらいたい。そういう切実な動機もありました。

編集部員の役割マップ

工程の分解を考えはじめたら、リアルな編集部の役割が浮かび上がってきました。これがしっくりきたので、ロール(役割)の単位で組み直すことにしました。まだ構想中のもありますが、編集部の担当者を思い浮かべながら分担しました。

記事をつくるフロー（8ロール）

• researcher — 調査・情報収集

• planner — 取材設計・質問票作成

• interviewer — 取材（外向き／内向き）

• transcriber — 文字起こし・クレンジング

• writer — 本文執筆

• reviewer — 仕上げパス・発言照合

• editor — 最終調整

• publisher — 公開処理

組織をまわす役割（3ロール）

• scheduler — スケジュール管理

• recap — 日次振り返り

• performance — パフォーマンス分析

将来的には、編集プロダクション経営OSへ拡張するつもりです。広報・宣伝・マーケティング・営業・顧客対応・外注管理・財務——「会社をまわすために自分が今やっている仕事」をすべてロール化していけば、たぶん私の脳みその外側に編集部一個分のリソースが生まれる。働き方を永久機関化していく第一歩のようなものですね。

同業者はもちろん、ライター業務だけをしてきた人も、企業のなかでオウンドメディアの担当になった人も——誰もが「自分の編集部」を持てる世界にしたいなと思っています。

任意の工程から入れる、という柔軟性

工程をロール単位で分解した恩恵のひとつは、AIの処理待ち時間が減ったことです。

クラシック環境は、上流から順番に流れていく1本道でした。全部の工程をすべて読み込んでから処理するので、コンテキスト量が長くなってすぐauto-compact（処理する内容の圧縮）がはじまります。しばらくClaudeが黙って動かないので、コーヒーブレイクの時間かと思ってましたが、たびたび起きるとカフェイン中毒になってしまいます。

もうひとつの恩恵は、上から下まで一本道で進めなくても、好きな工程から並行で動かせるようになったことです。AI編集部OSは、中間成果物(transcript・draft・review_log など)が各工程の境目にファイルとして残ります。これがハブの役割を果たして、好きなところから再開できる仕組みです。

• researcherが制作に必要な資料を集める → 文字起こし時に渡す　/ レビュー時に再利用する

• 音声文字起こしだけ回したい → transcribeスクリプトに音声を投げる

• レビューだけ動かしたい → 既存ドラフトを渡してreviewerを起動

組み替えたければ組み替える。企画からはいるものもあれば、音声が届いて始まるものもあり、文字起こしと翻訳だけで終わるなど、記事1本ごとに事情が違うので、その都度ベストな入り口から入れるのは、現場感覚としてものすごく楽です。

具体的に、私の取材直後はこう動いています。

1. インタビューが終わったら、すぐ音声ファイルを文字起こしに投入（オーケストレーターが`transcribe.py`を直接実行）

2. 私は音声を聞きながら、自分用の取材メモを作りはじめる（記憶が新しいうちに、印象的だった発言や場の空気を書き留める）

3. 文字起こしが終わったら、誤変換のクレンジングを通したあと、writer→reviewerのエージェントを走らせる。reviewerはwriterに一度原稿を差し戻し、修正稿が戻ってきてからもう一度レビューする二段構え

4. 音声を聞き終わるころには、私が設定した仕様・企画・文章表現・校正のルールに従った初稿が上がっているので、その後は私が自分の手で仕上げます

この並走がきいて、1時間ほどで4000文字の記事を「レビュー・ファクトチェック済み草稿」までたどり着いくことができました。

クラシック環境（直列）では、60分の音源の場合、まずAIによる日本語の文字起こしが30分ほどかかります。この間はAIに任せて別の作業に充てられますが、そこから先は手作業です。音源を聴きながら自分でクレンジングしていくと40〜60分、草稿づくりにさらに120分、仕上げに40分。自分が記事に向かう時間として、3時間半くらいはかかります。

AI編集部OS環境では、AIチームへの資料（取材趣旨やインタビューイー情報）と音源を提供し、二稿レビュー済みまで60分ほどでできたのです。その間私は音源を聴いてインタビューのポイントをおさえつつ、終わったらほかの事務仕事もやりました。その後、AIチームが上げた二稿レビュー済み原稿を40分で編集しなおし、納品しました。つまり、これまで3時間半かけていた仕事を、2時間以内で終わらせたのです。しかも、レビューの精度が高いので誤字脱字修正などの抜け・漏れの数も激減しました。

3時間半かかっていた工程が、約2時間に圧縮される。老体にはありがたい時短ということで、電脳サイボーグ感覚でした。

ai-editorial-osとして公開しています

AI編集部OSは、GitHubで無償公開中です。

`https://github.com/h-mori-andg/ai-editorial-os`

クラシック環境(CLAUDE.md一枚岩：ただし執筆とレビューのみ)もアーカイブとして同じリポジトリに残しています。両方を見比べてもらうと、「1本道だったクラシックが、ロール編成にどう分解されたか」が一望できる構成にしました。

公開した理由は3つあります。

1. フィードバックループへの期待

この連載で何度も書いてきたように、AI業務指示の世界は週単位で変化します。常に最新版を提供しつづけることで、進化の過程ごと使ってもらえる。読者の方々が現場で踏んだバグや改善案が返ってくれば、私のOSもさらに進化していく。AIの世界はオープンソースカルチャーが根付いていて、その流儀の恩恵を受けたい気持ちもあります。

2. 小説連動の伏線

実はこの先、AI編集部のエージェントたちが活躍する別の場も準備中です。詳しくは追々お話ししますが、フィクションの世界に彼らを連れていくつもりです。役割と性格を持ったエージェントがどのように振る舞うか。エージェントチームを作る中で私とエージェント、エージェントとエージェントの対話が生まれています。おもわず嘘をついてしまったり、まったく指示を無視して暴走したり……そんな話を私は記者として観察し、物語にしようとしています。

3. ターボ理論の証明

原稿仕事をこなしながら、AI編集部OSの構築をすすめ、その様子を観察・記録して別のコンテンツ（小説）にいかす。エンジンを動かすことによって発生する排熱をエネルギーに変えるターボ理論を、自分の現場で実証していきたいのです。

次回は情報を守る環境のお話

次回・第11回は、AIとの協働環境を「どこで動かすか」の話に踏み込みます。テーマは取材情報をAIに渡しても大丈夫か——プライベート環境の必要性。クライアントの未公開情報・取材音源・名刺情報を扱うために、なぜAWS Bedrockのようなプライベート環境を選ぶのか。2020年から2026年にかけての情報管理の変遷と、現在の実装の理由をお伝えします。

AI編集部OSのダウンロードや利用方法のお問い合わせはこちら↓