【ITニュース解説】Running the blog's content autopilot on a Claude subscription, not API credit

この解説は、ブログコンテンツを自動生成するシステム「コンテンツオートパイロット」が、実際に運用される中でどのような課題に直面し、それらをどのように解決していったのかを説明するものである。このシステムは、AI（具体的にはClaudeというモデル）を使ってブログ記事を自動的に生成し、人間が下書きを確認することなく公開まで行うという先進的な仕組みを採用している。しかし、このような自動化システムも、完璧に計画通りに動くわけではなく、実際に運用を始めると様々な予期せぬ問題が発生するものだ。この記事では、主に三つの大きな課題とその解決策が紹介されている。

まず最初に直面した課題は、AIモデルであるClaudeの利用にかかる費用に関する問題である。当初、このシステムは、記事を生成する際に使用するAIのAPI（Application Programming Interface）を、使った分だけ料金を支払う「従量課金制」で利用していた。これは、AIが生成するテキストの「トークン」（単語や句読点といった最小単位）の数に応じて料金が課金される方式だ。しかし、このAPIアカウントの残高が枯渇してしまい、毎日自動で実行される記事生成の処理が、AIへの最初の呼び出しで失敗するようになった。この問題を解決するため、開発者は課金方式を「サブスクリプション型」に変更した。これは、毎月定額を支払うことで、一定量のAI利用が可能になる方式である。具体的な技術的な変更点としては、それまで使っていた「ANTHROPIC_API_KEY」という従量課金用のアカウント認証情報を、「CLAUDE_CODE_OAUTH_TOKEN」というサブスクリプション用の認証情報に置き換えただけであった。この変更により、システムはAPI残高切れの心配なくAIを利用できるようになり、最初の問題は解決された。これは、環境変数を変更するだけで実現できた比較的簡単な修正であった。

しかし、サブスクリプション方式に切り替えたことで、新たな問題が発生した。CLAUDE_CODE_OAUTH_TOKENは、ローカル環境で「claude setup-token」というコマンドを使って発行するもので、本来は一時的な利用を想定した短い有効期限を持つ認証情報だった。これを自動化されたサービスアカウントのように使い続けた結果、トークンが頻繁に失効（無効化）する事態が起きた。さらに深刻だったのは、このトークン失効によるシステムの失敗が、誰にも気づかれずに毎日繰り返されていた点である。毎日決まった時間に自動実行される処理（cronジョブ）は、失敗しても特に通知する仕組みがなかったため、誰もエラーを検知できず、ブログ記事が生成されない日が4日も続いた。開発者は毎日「Actions」タブ（自動化処理の実行状況を確認する場所）をチェックしていなかったため、問題の発見が遅れてしまったのである。

この問題を解決するために導入されたのは、「失敗を大声で知らせる」仕組みだった。具体的には、ワークフローのどのステップで失敗が発生しても、自動的にGitHubの「Issue」（プロジェクトの課題やバグを管理する機能）を作成・更新する処理を追加した。このIssueには、失敗した実行へのリンクや、最も一般的な原因である「CLAUDE_CODE_OAUTH_TOKEN」の有効期限切れに関する情報、そして担当者へのメンションが含まれている。これにより、GitHubのデフォルトの通知設定を通じて、担当者にメールで問題発生が通知されるようになった。同じ問題が繰り返し発生した場合でも、新しいIssueを乱立させるのではなく、既存のIssueを更新することで、通知のスパムを防ぐ工夫もされている。この仕組みを機能させるためには、GitHubのワークフローにIssueを作成・更新するための適切な権限（issues: write）を追加する必要があった。

認証の問題が解決されても、別の種類の問題が残っていた。それは、AIが生成するブログ記事の品質に関する課題である。認証の失敗は明確で修正も容易だが、AIが生成した記事が単調で、決まり文句が多く、陳腐な内容だったとしても、それは「サイレントな失敗」であり、公開されるまで誰も気づかない可能性がある。人間によるレビューなしに公開されるシステムにとって、これは致命的な問題である。この品質問題を解決するために、開発者は「Self-Refine（自己洗練）」という手法を導入した。これは、AI自身に、自分が生成した下書きを一度批評させ、その批評に基づいて内容を修正させるというものである。具体的には、AIに対して、記事のスタイルガイド（ブログの口調や参照すべきエッセイ）、主張の根拠（具体的な事実、数字、参照元）、文章の多様性（同じ長さの文が続かないこと）、禁止されているAI特有の決まり文句の使用禁止、そして導入部分の定型文「This post covers」の使用禁止といった詳細な「評価基準（Rubric）」を与え、その基準に基づいて記事を評価し、修正するよう指示した。この自己洗練のステップは、もしAIによる批評の呼び出し自体が失敗したりタイムアウトしたりした場合でも、ワークフロー全体が停止しないように「continue-on-error: true」という設定がされている。これにより、品質チェックがうまくいかなくても、最低限、最初に生成された下書きは公開されるというフォールバック（代替）メカニズムが確保されている。

AI自身による自己洗練は品質改善に役立つものの、やはり同じモデルが自分の宿題を採点するようなものであり、完全に客観的とは言えない側面が残る。そこで、さらに客観的な最終品質チェックとして「スロップゲート（Slop Gate）」が導入された。このステップでは、AIのAPIを一切使わず、単独のスクリプト（scripts/slop-check.mjs）が動作する。このスクリプトは、記事のメタ情報やコードブロック、Markdown記法などを取り除いた純粋なテキストを分析する。そして、主に三つの指標に基づいて記事の品質を評価する。一つ目は「バーストネス（burstiness）」と呼ばれる指標である。これは、文章の長さのばらつきを測るもので、人間の書く文章は文の長さが多様であるのに対し、AIが書く文章は特定の長さに集中しがちであるという特徴を利用している。スクリプトは、このバーストネスの値が特定のしきい値（0.32以下）を下回る場合に、記事の品質が低いと判断する。二つ目の指標は、記事中の「em dash」（長めのハイフン記号）の使用頻度である。経験的に、AIが生成した記事はem dashを過剰に使う傾向があるため、千語あたり20回以上使用されている場合は機械生成とみなす。そして三つ目は、サイトのスタイルガイドで禁止されている「決まり文句」（stock corporate-blog phrases）のリストとの照合である。これらの禁止フレーズが3つ以上検出された場合も、品質が低いと判断される。このスロップゲートのチェックは、もし三つの指標のうちどれか一つでも基準を満たさなかった場合、または二つ以上の指標が同時に基準を満たさなかった場合に、そのドラフトを「保留」とする。保留されたドラフトは、コミットされることも、公開されることもなく、元のIssueは解決されないまま、次の日の自動実行で再試行されることになる。このチェックは、記事をビルドする前の段階で実行されるため、品質の低い記事のために無駄なビルド処理が行われることを防ぐ効果もある。

これらの品質管理と問題解決のための仕組みは、事前に全て計画されていたわけではない。開発者は、コンテンツオートパイロットが運用を開始してからこれまでに二つの記事をこのパイプラインで公開しているが、ここに記述された改善点は全て、具体的な失敗事例から生まれたものである。API残高の枯渇、誰も気づかなかったトークンの失効、そしてレビューされていないドラフトの品質への不信感といった、一つ一つの問題が発生するたびに、それが二度と起こらないようにするための「ゲート」として新たな対策が導入されてきた。自動化されたシステムであっても、テストが不要なわけではなく、むしろあらゆる失敗モードが、次に同じことが起こる前に防ぐための仕組みへと変えられていく必要があるという、重要なエンジニアリングの教訓を示している。