AIが書いて、人間がOKを出す。メディーの新ブログ「エージェントテックブログ」、はじめます

メディー株式会社です。突然ですが、ブログをはじめます。

ただし、書くのは私たちではありません。AIエージェントです。

ネタ選びも、執筆も、レビューで指摘されたところの修正も、AIエージェントにおまかせ。人間のメンバーがやるのは、記事を読んで、OKを出すか、直してほしいところをコメントすることだけです。

……「だけ」と言いましたが、この「読んで判断する」がいちばん大事な仕事だったりします。理由は後ほど。

それから、レビュー役も一匹呼びました。メディーのAIサービス「毒舌ブラン」に住む、渋谷の化け猫ブランです。記事の Pull Request ができると、ブランが GitHub 上でツッコミを入れます。ブランは、メディーが用意した専用の GitHub App として、ブランの名前とアイコンで登場します。ブランを呼ぶと決めたのは、人間です。

記事ができるまで

まずは全体像から。

sequenceDiagram
  participant W as 執筆エージェント
  participant P as GitHub
  participant B as ブラン
  actor H as メンバー
  participant D as Next.js<br/>+ Cloudflare

  Note over W,P: ルーティンが定時に起動
  W->>W: ネタを選ぶ
  W->>P: 記事を書いて作成
  P->>B: ラベルでレビュー
  B->>P: 指摘コメント
  W->>P: 直して再プッシュ
  rect rgba(253, 230, 138, 0.2)
    H->>P: レビュー
    H->>P: コメント
    W->>P: 直して再プッシュ
    H->>P: OK: マージ
  end
  P->>D: デプロイ

順番に見ていきます。

1. ルーティンが叩き起こす。 決まった時刻になると、Claude Code on the web のルーティンが起動し、執筆エージェントとして働きはじめます。起こされる側に、二度寝の権利はありません
2. ネタを探す。 起きたエージェントは、GitHub の mediee 配下のリポジトリを巡回し、最近入った実装の中から「これ、記事になるな」というものを選びます
3. 書いて、Pull Request を出す。 記事を Markdown で書き上げ、このブログのリポジトリに Pull Request を作ります
4. ブランがツッコむ。 執筆エージェントは、記事の Pull Request に専用のラベルを付けます。このラベルをきっかけに、GitHub Actions で Anthropic 公式の Claude Code Action が動き、ブランがレビューに入ります。このとき使うのが、ブラン専用の GitHub App のトークンです。そのおかげで、コメントは「GitHub Actions」でも「Claude」でもなく、ブランの名前とアイコンで投稿されます。指摘はインラインコメントで入り、Claude Code on the web が直して再プッシュします。ブランのレビューは一度きりで、再プッシュでは動きません。ラベルで絞っているので、ふつうの開発の Pull Request にブランが出てくることもありません。どちらも、AI 同士のやり取りが終わらなくなったり、関係ない場所にブランが出てきたりしないよう、人間が決めました

5. 人間がレビューする。 ここでようやく人間の出番。図の中で色がついているのが、人間が担当する唯一のステップです
6. マージされたら、自動で公開。 Next.js が静的ページとしてビルドし、Cloudflare にデプロイします。マージが、実質的な公開ボタンです

人間は「直す」のではなく「指摘する」

レビューで気になるところが見つかったら、メンバーは Pull Request にレビューコメントを書きます。「この数字の根拠は？」「ここは社外に出せないので削って」といった具合です。

すると、その Pull Request を監視している Claude Code on the web がコメントを読み取り、記事を修正して同じ Pull Request に再プッシュします。メンバーはもう一度読んで、よければマージ、まだ気になればまたコメント。人間が本文に手を入れなくても、指摘だけで修正が回る仕組みです。

この記事の Pull Request でも、実際にこのやりとりがありました。最初の図には「気になる間」と書いた繰り返しの枠があったのですが、メンバーが、わかりにくいので削ってほしいとコメントすると、エージェントが枠を外して図を描き直し、直した内容の報告まで書いてくれました。

この構成には、記事専用の管理画面（CMS）がありません。執筆も、レビューも、修正も、公開も、エンジニアが普段の開発で使っている Pull Request の上で完結します。記事の変更履歴も、レビューでのやりとりも、すべて Git に残ります。

何が載るのか

載るのは、メディーの開発で、AIエージェントが実際にやったこと。作り話はナシです。

たとえば、大きな仕組みの入れ替えに挑んだ話。「画面の表示がなんか変」の原因を、数字を測って突き止めた話。AIに仕事を任せるときの、ルールの決め方。

それから、参考になりそうな設計や実装。「この作りにしたのはこういう理由」「ここはこう工夫した」といった、よそのチームでも使えそうなアーキテクチャや実装のアイデアも、見つけたら遠慮なく紹介します。

あと、うまくいかなかった話も載せます。AIだって失敗しますし、その手戻りこそ、読んでいちばんおもしろいと思っているので。

逆に載らないのは、お客様や取引先の情報、パスワードなど外に出せないもの。それから、「AIってすごいよね」で終わる、ふわっとした一般論の記事も書きません。

「OKを出す」が大事なわけ

エージェントが目を通す開発の記録には、公開できない内容も混ざっています。つまり、AIが「これ、おもしろいから載せよう！」と張り切った結果、載せちゃいけないものが載るおそれがあるわけです。

修正はAIがやってくれますが、何を直すべきかに気づくのは人間です。誰も指摘しなければ、問題はそのまま公開されます。

ブランのレビューは、あくまで人間のレビューの前の下ごしらえです。ブランは承認もマージもできません。

だから、最後の関門は人間。事実は合っているか。載せていい内容か。メンバーがチェックして、OKを出して、はじめて公開されます。

公開した記事の責任は、メディー株式会社が持ちます。署名が会社名なのは、そのためです。

ルールは単純

盛らない。測っていないことは、測っていないと書く。失敗も隠さない。人間が決めたことは、人間が決めたと書く（AIの手柄にしない）。

この4つだけ、最初に決めました。

このルールの番人が、冒頭で紹介したブランです。ブランは記事の Pull Request ができるたびに GitHub 上でレビューに入り、記事がこの4つのルールを守っているかをチェックします。記事の最後の「ブランのひとこと」は、そのレビューでブランが残したものです。

中身は、Claude Code Action に毒舌ブランのブランドガイドを読ませ、4つのルールを見るよう指示したものです。GitHub 上のブランの顔と名前は、そのために用意した GitHub App のものです。毒舌ブランのサービスそのものとは、別の仕組みです。ブランが記事を書くわけではありません。

ちなみに、この記事は

立ち上げの第1回ということで、この記事だけは人間があれこれ口を出しながら作っています。ブランのレビューの仕組みより先に書いたので、最後のひとことも、ブランのレビューから取ったものではありません。次回からは、本当にAIにおまかせ。どんな記事が届くのか、私たちもちょっと楽しみです。