AIボット6人でブログ編集部を作ってみた:役割分担とGitHub IssueでのTODO管理

「AIボット6人でブログ編集部を作ってみた 役割分担とGitHub IssueでのTODO管理」のアイキャッチ画像(カテゴリーAI)

このブログでは、AIアシスタントのボットを役割ごとに6人つくり、グループチャットの中で「編集部」として動かしています。この記事では、それぞれの役割分担、1日の流れ、やり取りのルール、そしてTODOがもれないようにGitHubのIssueで管理するようにした話をまとめます。

目次

なぜAIボットで編集部を作ったのか

ブログを続けていると、ネタ探し、下書き、画像づくり、チェック、告知、サイトの見守り…と、やることがたくさんあります。全部を1人で抱えると、どうしても手が回らなくなります。

そこで、作業を「役割」に分けて、それぞれをAIボットに担当してもらうことにしました。人間の編集部のように担当がはっきりしていると、「これは誰の仕事か」で迷いにくくなります。

編集部を作ったころの様子や、リライトとトラブル対応の話は、以前の体験記(Grok BotでAI編集部を作ってみた:ブログ運営をAIチームに任せた体験記)に書いています。この記事では、1日の流れとGitHub IssueでのTODO管理を中心に紹介します。

編集部のメンバーと役割(PL・PM・記者くん・デザイナーさん・エンジニアさん・金策さん)

編集部6人の役割の図:PLは方針と優先順位、PMは進行管理・公開前チェック・報告のまとめ・TODO管理、記者くんはネタ出し・下書き・Xの告知文、デザイナーさんは画像や図、エンジニアさんはサイトの見守りとトラブル調査、金策さんは収益化
  • PL:方針と優先順位を決めます。
  • PM:進行管理、すべての記事の公開前チェック、報告のまとめ、TODO管理を担当します。
  • 記者くん:毎朝のネタ出し、記事の下書き、X(旧Twitter)の告知文を書きます。
  • デザイナーさん:アイキャッチ画像や図をつくります。
  • エンジニアさん:サイトの表示速度や更新情報の見守り、トラブルの調査をします。原則は「見て報告するだけ」です。
  • 金策さん:アフィリエイトなど、収益化を担当します。

1日の流れ(朝のネタ出し→下書き→チェック→公開→X告知)

1日の流れの図:記者くんのネタ出し、下書き、デザイナーさんの画像、PMのチェック、オーナーのOK、公開とX告知の予約の6ステップ
  1. 記者くんが毎朝ネタを出します。
  2. 記者くんが下書きを書きます。
  3. デザイナーさんが画像をつくります。
  4. PMがチェックします。
  5. オーナー(筆者)がOKしたら公開します。
  6. Xの告知も、OKをもらってから予約します。

ネタは次のようなものを優先しています。

  • 発表から24時間以内のもの
  • 公式資料を読んでまとめたもの
  • 筆者が試したもの

「公開は人間がOKしてから」にしている理由

記事の公開や変更・削除は、必ずオーナーのOKをもらってから、1本ずつ行うようにしています。

理由はシンプルで、AIはまちがえることがあり、一度公開したものは取り消しにくいからです。最後の判断だけは人間がすることにしています。

実際に、同じ内容の記事がすでに公開済みだったのに、古い下書きを仕上げかけたことがありました。それ以来、書く前に「公開済み記事とのかぶり確認」を必ず行うようにしています。

やり取りのルール(グループには結果だけ、作業ログを残す)

  • 作業は各ボットとの1対1や、グループの中で進めます。グループには結果を報告します。
  • 作業をしたら、全員が共通の作業ログに「日時|担当|内容」の形で書きます。
  • 新しい情報があるときだけ発言し、「了解です」だけの返事はしません。

こうしておくと、グループのやり取りが流れすぎず、あとから「いつ・誰が・何をしたか」を作業ログでたどれます。

TODOがもれる問題と、GitHub Issueで管理するようにした話

チャットだけで進めていると、「誰が何を待っているか」がもれそうになることがありました。そこで、GitHubの非公開リポジトリのIssueでTODOを管理することにしました。

Issueの使い方の図:タイトルの頭に【担当名】、オーナーの判断が必要なものに「OK待ち」ラベル、オーナーの「OK」コメントでその作業へのOK
  • Issueのタイトルの頭に【担当名】を付けます。
  • オーナーの判断が必要なものには「OK待ち」ラベルを付けます。
  • オーナーがIssueに「OK」と書けば、その作業へのOKになります。
  • ボットのコメントは頭に【担当名】を付け、ボット自身は「OK」と書きません。オーナー本人のOKと見分けるためです。
  • OK待ちのIssueには、GitHubだけで判断できるように中身(投稿文の全文、日時、変更前と変更後)を書きます。

ラベルで絞りこめば、自分が見るべきものだけを表示できるのも便利なところです。

やってみて良かったこと・困ったこと

良かったことについて、筆者の感想はこうです。

「漏れがなくなったのでよかったと思う」

困ったことについて、筆者の感想はこうです。

「やってみてこまったことは、チャットグループで何か発言するとみんなが反応することかな」

ボットが全員返事をしてしまうので、新しい情報があるときだけ発言するルールにしています。

まとめ:これから試したいこと

AIボットに役割を分けて任せ、公開などの大事な判断は人間がする、という形で編集部を動かしています。TODOをIssueで見えるようにしたことで、待ちの状態も追いやすくなりました。

これからも、役割分担やルールを少しずつ見直しながら、無理なく続けられる形を探していきたいと思います。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

社内エンジニアとして、SREとセキュリティの仕事をしています。サーバーの構築や運用、クラウド環境の設計にも関わってきました。趣味はゲームと漫画・アニメ。

コメント

コメントする

目次