Kiroの並列執筆で月間123本のブログを書いてみた
はじめに
2026年7月、月間123本のブログ記事を投稿しました。
これを支えたのは、AIエージェントKiro CLIを軸にしたブログ制作ワークフローの整備です。
複数のAIモデルによる並列執筆と自動レビュー、そして要所での人間の意思決定を組み合わせた仕組みを、次のCVE-2026-42533の検証記事を実例に示します。
検証内容
ワークフロー全体像
制作の流れは次のとおりです。
工程を分けているのは、原稿を作り始めた後に検証範囲や公開条件が曖昧になることを避けるためです。各工程が担う役割は次のように分かれています。
- 調査・検証：公式ドキュメントを把握し、必要なら実際に動作を確認して結果を記録します
- 計画書作成：記事の構成・検証範囲・文体方針を計画書としてまとめます
- 計画書レビュー：複数モデルが計画書そのものを検査し、指摘の採否を人間が判断します
- 執筆仕様書作成：計画書から執筆に必要な情報だけを抜き出し、確定値に変換します
- 並列執筆：複数のAIモデルが同じ入力から独立に記事の下書きを生成します
- 統合：複数の下書きから良い部分を選び、1本の原稿にまとめます
- アウトライン承認：読者に出す構成を人間が確定し、以降は表現の修正だけに絞ります
- レビューサイクル：技術・文体・タイポ・冗長表現など複数の観点で原稿を検査します
- 人間レビュー：原稿を通読し、修正を指示します
- 公開：公開前の最終確認を経て記事を出します
マルチモデル並列執筆
執筆工程は、ファン・アウト/ファン・インの形を取っています。
Claude Opus、GPT、Grok といった複数のモデルが、同一の計画書と検証結果を入力として、それぞれ独立に記事の全文を書き上げます。どのモデルを何本走らせるかは固定せず、モデルの世代交代やKiroのサポート状況に合わせて随時入れ替えています。Kiroが直接サポートしていないモデルは、ラッパースクリプト経由で呼び出しています。
担当範囲をセクションごとに分割しない点がポイントです。たとえばCVE記事では、あるモデルは脆弱性の概要から入り、別のモデルは再現手順から入るといった構成の違いが現れました。
出揃った下書きは、統合役のモデルがベストな部分を選び取りつつ冗長さを削って1本にまとめます。どの下書きのどこを採用したかという判断根拠も記録に残します。
複数の系列のモデルを混ぜることで、統合時に採用できる表現の候補が広がりました。特に効いたのはGPTの追加です。当初はCodex経由でGPT-5.5を呼び出していましたが、KiroがGPT-5.6をサポートしてからは、同じワークフローへ組み込めるようになりました。
レビューサイクル
機械的なチェックとして、lintによる表記揺れ・文法の検査と、機械判定できる範囲での日本語の自然さの検査を行います。表記のノイズを先に潰しておくと、後続のAIレビューが本質的な指摘に集中しやすくなりました。
AIによるレビューは複数軸を並列で走らせます。実施するタイミングは軸ごとに異なります。
- 計画書レビュー（執筆前）：複数モデル並列で、記事の設計そのものを検査します
- セルフレビュー（統合前）：複数モデル並列で下書きを読み、冗長さや論理の飛躍を洗い出します
- 技術・文体・タイポレビュー（統合後）：各観点を担当モデルが並列で検査します
- AI文体チェック・メディアポリシーチェック（統合後）：機械的に読み取れない品質面を検査します
レビューの履歴は、修正前のスナップショットと変更ログをラウンド単位で残しており、どの指摘を受けて何を採用し、どこを直したかが後から辿れます。
採否判断ゲートは、主にAI文体やメディアポリシーなど判断が割れる指摘に対して設けています。技術的な誤りや表記ミスは明白なため即修正し、ゲートの対象外です。これらについては、記事の文脈に照らして採用・却下・保留を人間が決めてから修正に進みます。
人間の関与ポイント
自動化を進めても、意思決定は人間が握ります。
人間が最初に手を入れるのは計画段階で、想定読者・検証範囲・公開制約といった前提を確定させます。計画に対する疑問点を解消し、計画書レビューの指摘を採用するかどうかも判断します。ここで記事の方向性が決まります。
中間のレビュー段階では、採否判断ゲートを通して指摘の採用・却下を決めます。各工程の完了ごとに、次へ進むか一度止めるかも人間が決めます。
最終の仕上げ段階では、原稿を通読して修正を指示し、公開前の最終確認を行います。
CVE-2026-42533の検証記事では、人間が出した主要な指示は3つだけでした。
この記事読める？ https://cyberstan.co.uk/nginx-rce/
修正前のDockerイメージをダウンロードして、ローカルで問題を再現。修正後に起きないことを検証できる？
やってみたスキルで紹介したい。検証結果と再現方法を含めたログの保存、計画書の作成まで頼みたい。記事作成は別のKiroに引き継ぐので、進捗ファイルも作成して
URL共有と「再現できる？」の2指示でDocker検証が自律的に走り、記事化の依頼1件で計画書・進捗ファイル・引き継ぎ用のログ一式が生成されました。以降は進捗確認やタイトル調整など軽微なやり取りが3件あっただけです。
この記事で指示が少なく済んだのは、元の脆弱性レポートの品質が高く、検証のゴールが明確だったためです。入力情報が曖昧だったり検証範囲の判断が割れるケースでは、計画段階でのやり取りが増え、レビューでの差し戻しも発生します。
人間は、記事の骨格・品質基準・公開可否という後戻りの大きい判断に集中し、下書きの生成・比較・チェックはAIに委ねる設計です。
CVE-2026-42533記事の制作タイムライン
次の表は調査からレビューサイクルまでの経過時間です。以降のアウトライン承認・人間レビュー・公開は人間の判断待ちを含むため割愛しています。
| 経過時間 | 工程 | 実行形態 | 備考 |
|---|---|---|---|
| 0:00〜 | 調査・検証 | 逐次 | 公式情報の確認と動作検証 |
| 0:40〜 | 計画書作成 | 逐次 | 人間が検証範囲と方針を確定 |
| 1:00〜 | 計画書レビュー | 並列 | 複数モデル並列、指摘の採否を人間が判断 |
| 1:15〜 | 執筆仕様書作成 | 逐次 | 計画書から執筆に必要な情報を抽出 |
| 1:25〜 | 並列執筆 | 並列 | 複数モデルが同一入力から全文生成 |
| 1:30〜 | 統合 | 逐次 | ベストパーツを選んで1本化 |
| 1:35〜 | レビューサイクル | 並列 | 技術・文体・タイポ・AI文体を検査 |
並列執筆と各種レビューをまとめて走らせることで、直列に実行する場合より全体の所要時間を短縮できています。
統合では、導入部分の運びが最も自然な下書きをベースに採りました。検証手順の説明は、別の下書きの記述が正確だったためそちらを組み込みました。冗長な言い回しは統合の段階で削り、全体の分量を抑えています。
技術レビューでは、検証結果の解釈に踏み込みすぎている箇所を指摘され、事実の記述に修正しました。一方、AI文体チェックが指摘した言い回しの一部は、文脈上その表現が適切だと判断して却下しています。チェック結果を修正命令として扱わず、記事の読者にとって妥当かどうかを軸に採否を決めた例です。
コスト
プロンプトログのトークン量を集計し、当日の総消費クレジットに占める割合から1記事あたりのコストを概算しました。3記事を並行して制作したセッションの実績で、いずれも目安の値です。
| 項目 | 値 |
|---|---|
| API calls | 195回 |
| 推定トークン数 | 60〜90万 |
| 1記事あたりの推定クレジット | 150〜200 |
| 1記事あたりのコスト | $3〜4（約500〜600円） |
ワークフロー導入前は1記事に4時間ほどかかっていましたが、現在、人間の拘束時間は1時間程度です。経過時間ではこれより長くかかりますが、その差はヘッドレス実行の待ち時間と、Kiroが人間の判断を待って止まっている時間です。筆者の環境では、1記事あたり数百円で3時間程度の作業時間を圧縮できている計算になります。
同等の執筆時間をかけていた2025年11月の投稿実績は32本でした。32本から123本への増加には、工程の並列化が大きく寄与しました。
スキルのメンテナンス
日々の運用で手間がかかるのは、記事の執筆そのものよりもスキルの改善です。数日ごとに直近の制作を振り返り、ボトルネックや品質上の課題を洗い出して対処しています。スキル定義のリポジトリには初期化から継続的にコミットが積まれており、レビュー観点の追加や並列執筆のモデル調整といった変更を重ねています。
改善の内容は大きく2つに分かれます。
1つ目は、タスクの細分化とヘッドレス実行です。各工程をAIへ一任できる粒度まで分割し、ヘッドレスモード（人間の介入なしのバッチ実行）で一気に走らせる形にしました。これで工程を並列に実行できます。人間の拘束時間の短縮に大きく関わったのは、この設計変更です。計画書レビュー、並列執筆、セルフレビューといった工程が、人間の待機なしに並列で完了します。
2つ目は、品質向上のための調整です。レビュー観点の追加、使用モデルの入れ替え、チェック精度の改善などを、実際の制作結果を見ながら随時実施しています。品質上の問題が出たら原因を特定してスキル定義を修正する、という手順を繰り返しているため、同じ問題の再発は減りました。
今後の展望
コスト面では課題が残っています。Kiroの付帯クレジットでOpusが比較的廉価に利用できたため、Opus中心で組んでいました。Opusの20分の1のクレジット倍率で利用できるGPT-5.6 Lunaなどに、単純なタスクを任せることも検討しています。
また、7月末にリリースされたClaude Opus 5では、既存のスキル定義がそのままでは想定どおりに動きませんでした。この調整に時間を取られ、リリース後の執筆ペースは半分程度まで落ちています。モデルごとに効く指示が違うため、どのモデルへ何を任せるかは今後も見直していきます。
まとめ
「やってみた」系の記事は検証で得た理解の副産物であり、その理解の過程を正確に、誤解のない表記で読者へ渡せるかどうかが価値だと考えています。
このワークフローで人間が担うのは、何を題材に選び読者へ何を伝えるかの事前設計です。そして、成果物が意図した内容か、事実の裏付けを欠いた記述で読者の利益を損なっていないかを確かめる責任も人間の側にあります。
その正確性の確保と誤解の回避にはAIを活用できており、構築待ち時間など長くなりがちな検証や、その後のまとめ・整形も任せられたことで、同じ時間でのアウトプット量が大きく伸びました。
