アンジーでは2020年から文字起こしAIを、2022年末から生成AIを記事制作に組み入れ、6年間で3500本以上の記事を制作してきました。これまでブログでも紹介してきたCLAUDE.md（AIへの記事制作業務指示ファイル）は、生成AI活用の初期から継ぎ足しで進化させてきた指示書です。
本記事では、AIによるブログ記事制作の自動化手法を、CLAUDE.md一枚岩からAI編集部OSへの構造転換という観点で解説します。2026年3月にClaude Codeを使い始めて以降、新しい制作パイプラインAI編集部OS（ai-editorial-os）の構築に着手しました。CLAUDE.md一枚岩のやり方を「クラシック環境」としてアーカイブし、工程をバラバラに分解して、AIエージェントの編成として組み直す方針です。以下のように、GitHubにて無料公開中です
クラシック環境の課題：1本道で動く9工程
記事の編集制作の工程は、リサーチ → 企画概要 → 企画詳細 → 取材 → 文字起こし → クレンジング（誤認識の修正・話者の整理）→ 執筆 → ファクトチェック → 公開、の9段階に分けられます。Claude Code導入以前は、これが直列で動いていました。AIに任せていい工程と、人間が手を入れる工程が、ベルトコンベアの上に一緒に並んで進行する状態です。
たとえば取材直後。インタビューの記憶が新しいうちに音声を聞き返してメモを作りたい、文字起こしも回したい、執筆の下準備もしたい——こうした並行作業は、CLAUDE.md一枚岩の処理では実現できませんでした。常に人間がトリガーとなり、ひとつひとつ進める必要があったためです。
ここにAIエージェントと生成AIの機能的な違いが表れます。CLAUDE.md一枚岩は、生成AIをひとつの司令塔として呼び出す構造でした。一方のAI編集部OSは、AIエージェントを役割ごとに独立稼働させ、中間成果物を渡し合いながら自律的に工程を進める構造です。
「AIだけで自律的に進められる工程と、人間が手を入れる工程を、もっとはっきり分けられないか」——この問いから、エージェントチーム化への転換が始まりました。
編集部員の役割をマッピング
工程の分解を考えると、リアルな編集部の役割が浮かび上がります。これに沿って、ロール（役割）の単位でAIエージェントを再設計しました。各ロールは担当工程・参照する情報・アウトプット形式が異なる、AIエージェントツールのタイプ別分類と特徴を持っています。
記事をつくるフロー（8ロール）
| ロール | 担当 |
|---|---|
| researcher | 調査・情報収集 |
| planner | 取材設計・質問票作成 |
| interviewer | 取材（外向き／内向き） |
| transcriber | 文字起こし・クレンジング |
| writer | 本文執筆 |
| reviewer | 仕上げパス・発言照合 |
| editor | 最終調整 |
| publisher | 公開処理 |
組織をまわす役割（3ロール）
| ロール | 担当 |
|---|---|
| scheduler | スケジュール管理 |
| recap | 日次振り返り |
| performance | パフォーマンス分析 |
将来的には、編集プロダクション経営OSへ拡張する構想です。広報・営業・顧客対応・外注管理・財務など、編集部運営に必要な業務もすべてロール化していけば、ライター業務だけをしてきた人や企業のオウンドメディア担当者にも応用可能な「自分の編集部」を構築できます。
任意の工程から入れる柔軟性
工程をロール単位で分解した恩恵は、複数タスクの並列処理能力と自律性を獲得できることです。これは具体的には2つの効果として表れています。
1. AIの処理待ち時間が減る
クラシック環境は、上流から順番に流れていく1本道だったため、全工程をすべて読み込んで処理するうちにコンテキスト量が肥大化し、auto-compact（処理内容の圧縮）が頻発していました。ロール分解により、各エージェントが必要最小限のファイルだけを参照する設計になり、処理の停滞が解消されました。
2. 好きな工程から並行で動かせる
中間成果物（transcript・draft・review_logなど）が各工程の境目にファイルとして残るため、好きなところから再開できます。
- researcherが資料を集める → 文字起こし時に渡す／レビュー時に再利用
- 音声文字起こしだけ回したい → transcribeスクリプトに音声を投げる
- レビューだけ動かしたい → 既存ドラフトをreviewerに渡して起動
組み替えたければ組み替える。記事1本ごとに事情が違うので、その都度ベストな入り口から入れる柔軟性が、現場感覚として大きな改善でした。
取材直後の並走パイプラインで、3時間半→約2時間に圧縮
取材インタビューや会議の文字起こしと議事録作成の効率化は、AI編集部OSのもっとも分かりやすい応用例です。具体的な取材直後の動きはこうです。
- インタビューが終わったら、すぐ音声ファイルを文字起こしに投入（オーケストレーターが
transcribe.pyを直接実行） - 取材メモを作成（記憶が新しいうちに、印象的だった発言や場の空気を書き留める）
- 文字起こしが終わったら、誤変換のクレンジングを通したあと、writer→reviewerのエージェントを走らせる。reviewerがwriterに一度原稿を差し戻し、修正稿が戻ってきてからもう一度レビューする二段構え
- 設定した仕様・企画・文章表現・校正のルールに従った初稿が上がるので、最終仕上げを実施
この並走により、1時間ほどで4000文字の記事を「二稿レビュー済み」までたどり着くことができました。
クラシック環境（直列）では、60分の音源の場合、AIによる日本語の文字起こしが30分（この間は別作業に充てられる）、音源を聴きながらのクレンジングで40〜60分、草稿120分、仕上げ40分で、人が記事に向かう時間として3時間半ほどかかっていました。
AI編集部OS環境では、AIチームに資料（取材趣旨やインタビューイー情報）と音源を提供すれば、二稿レビュー済みまで60分ほどで完成します。その間に音源を聴いてインタビューのポイントを押さえつつ、ほかの事務仕事も並行できる。AIチームが上げた二稿レビュー済み原稿を40分で編集して納品。3時間半かけていた仕事を、2時間以内で終わらせることができました。レビューの精度が高いため、誤字脱字修正などの抜け・漏れも激減します。時短だけでなく、さらに品質を高めることができるのです。
ai-editorial-osとしてGitHubで無償公開
ここまで紹介したAI編集部OSは、Claude Codeによる技術記事作成システムの構築事例として、GitHubで無償公開しています。
クラシック環境（CLAUDE.md一枚岩：執筆とレビューのみ）もアーカイブとして同じリポジトリに残しています。両方を見比べると、1本道だったクラシックがロール編成にどう分解されたかを一望できる構成です。
公開の目的は、現場のフィードバックを受けて改善し続けるエコシステムを作ることです。AI業務指示の世界は週単位で変化します。常に最新版を提供しつづけることで、進化の過程ごと使ってもらえる。現場で踏んだバグや改善案が返ってくれば、OSはさらに進化していきます。AI編集ワークフローは言語依存度が低いため、世界中の編集者・ライターに展開する可能性も視野に入れています。
まとめ
CLAUDE.md一枚岩からAI編集部OSへの分解により、記事制作の工程は柔軟性と並列性を獲得しました。取材直後の並走パイプラインでは、人が記事に向かう時間を約半分に圧縮できています。次回は、このAI編集部OSを「どこで動かすか」——プライベート環境の必要性に踏み込みます。
「AI編集部OS」のお問い合わせは、下記のKIJI Baseページから受け付けております。
