【ITニュース解説】What's Actually Automated in an 'AI-Run' Blog, and What Isn't

「AIが動かすブログ」という言葉を聞くと、まるで魔法のように全てが自動で処理されるようなイメージを抱くかもしれない。しかし、実際にそのようなシステムを構築してみると、確かに大部分の作業は自動化できるものの、どうしても人間の手作業が必要になる部分が存在することがわかる。このニュース記事では、ある「自動化されたブログ」を例に、何がスクリプトによって自動で動き、何が人間にしかできないのか、その具体的な境界線が解説されている。

このブログの核となる自動化された部分は、非常に効率的に機能している。例えば、Windowsのタスクスケジューラという機能が、設定された時刻になるとスリープ状態のコンピューターを自動的に起動させる。コンピューターが起動し、インターネットに接続できるようになると、あらかじめ用意されたPythonというプログラミング言語で書かれたスクリプト（プログラム）が実行される。このスクリプトは、Bloggerというブログサービスが提供しているAPI（アプリケーションプログラミングインターフェース）を通じて、新しい記事を自動的に投稿する。APIとは、異なるソフトウェア同士が安全に情報をやり取りするための窓口のようなものだ。記事の投稿が完了すると、同じ内容がdev.toという開発者向けのコミュニティサイトにも自動でクロスポスト（同時投稿）される。この際、画像の処理や、元の記事の場所を示す正規URL（canonical URL）の設定も正確に行われる。これらの作業は、一度設定してしまえば、その後は人間の介入なしに、決められたスケジュールで繰り返し実行される。

さらに、ブログの運営状況を把握するための情報収集も自動化されている。必要に応じて、ブログの投稿数やdev.toでの閲覧数、Google Search Console（検索エンジンからのアクセス状況を分析するツール）でのクリック数や表示回数、Google Analytics 4（サイトの訪問者数を分析するツール）での訪問者数といったデータも、それぞれのサービスが提供するAPIを通じて自動的に取得できる。これらのデータは、ウェブブラウザで画面を操作することなく、スクリプトによって直接取得されるため、純粋な数値情報として手に入る。これらコアとなる機能は、まさに「自動化されている」という言葉通りに動作し続ける。

しかし、その一方で、自動化システムを稼働させるための最初の設定や、特定の状況では人間の手作業が不可欠な作業も存在する。その代表的な例は以下の通りだ。

まず、ほとんどのオンラインサービスで初めて連携を行う際に必要となる「OAuthの同意」プロセスだ。BloggerやGoogle Search Console、Google Analytics 4、dev.toのAPIキーを取得する際など、多くのサービス連携でこのプロセスが発生する。OAuthは、あなたの情報へのアクセスを許可するかどうかをユーザー自身が判断するためのセキュリティ機能だ。例えば、Googleのサービスと連携する場合、「このアプリケーションがあなたのブログに投稿することを許可しますか？」といった内容がウェブブラウザに表示され、ユーザーが手動で「許可」ボタンをクリックする必要がある。これは、悪意のあるプログラムが勝手にあなたのデータにアクセスすることを防ぐための、意図的なセキュリティ境界であり、スクリプトが自動でこのボタンをクリックすることはできない。

次に、同じウェブブラウザで複数のGoogleアカウントにログインしている場合の問題だ。スクリプトは、どのGoogleアカウントを使って連携を進めるべきかを判断できない。例えば、個人用と仕事用のアカウントを両方使っている場合、スクリプトはどちらのアカウントで操作すべきかを知る術がないため、人間が意図したアカウントを選択する手動操作が必要になる。実際にこのブログの自動化プロジェクトでも、意図しないアカウントで連携が試みられ、何度かシステムが停止する事態が発生したという。

また、BloggerのデザインテンプレートであるテーマのHTML（ウェブページの構造を記述する言語）を直接編集するような作業も、自動化が難しい。例えば、デザイン調整のために特定のJavaScriptライブラリを追加したり、ウェブサイトの所有権を証明するためのメタタグを埋め込んだりする場合だ。Bloggerが提供するAPIバージョン3には、テンプレートの内容を直接操作するための機能が用意されていないため、ウェブブラウザでBloggerの管理画面を開き、手動でHTMLコードを編集する以外の方法が存在しない。

さらに、Google Search Console、Naver Search Advisor（韓国の検索エンジン）、Bing Webmaster Tools（Microsoftの検索エンジン）といった検索エンジンのウェブマスターツールに新しいサイトを登録する際も、人手による操作が必要となる。これらのサービスはそれぞれ独自のログインシステムと、ウェブブラウザ上での登録フローを持っており、公開されているAPIには新しいサイトを自動で登録する機能は提供されていない。そのため、初回登録はウェブブラウザで画面を操作して行う必要がある。

dev.toのコメント返信も自動化できない作業の一つだ。dev.toの公開APIは、記事に投稿されたコメントを読み取る機能は提供しているが、コメントを投稿する機能は提供していない。これはAPIのドキュメントで明確に確認されており、スクリプトで自動的にコメントを返信するような処理は行えない。

これらの自動化できない作業に共通するパターンは、どれも「意図的なアクセス境界」であるということだ。これらは単に機能が不足しているのではなく、ログイン画面、同意フロー、UI（ユーザーインターフェース）からしか操作できないエディタ、読み取り専用のAPIといった形で、システムが人間による操作を要求しているのだ。これは、他者がコントロールするプラットフォーム上で何かを構築する際に、「自動化可能」な範囲を決定する構造的な制約と言える。スクリプトが操作できるのは、明確なAPIが提供され、認証が可能で、データの書き込みが許可されている部分に限られる。人間が「許可」をクリックするような操作はスクリプトにはできないし、今回の事例で挙げられたプラットフォームのほとんどは、セキュリティ上の理由やデータの整合性を保つ目的で、意図的に人間によるクリックや操作を要求する箇所を設けている。

このことは、実際にプロジェクトを運用する上で重要な意味を持つ。それは、このブログの自動化プロジェクトには、永久的に、小さいながらも定期的に、人間による画面操作や確認作業という「税金」がかかるということだ。この「税金」は、自動化の仕組みが未完成だから発生するのではなく、システムを構成する上での構造的な境界線によって生じる。例えば、Google Search ConsoleやGoogle Analytics 4といった新しいサービスとの連携を追加するたびに、初回セットアップ時には必ず一回限りのウェブブラウザでの手動操作が必要になる。その後は各サービスとの連携が自動で機能するようになるが、新しい統合が加わるたびにこの初期設定の手間はゼロから発生するのだ。

したがって、このプロジェクトを正直に表現するならば、「AIがこのブログを動かしている」というよりは、「APIが提供されており、特定の人間であることを証明する必要がない作業はスクリプトが処理し、プラットフォームが人間との対話を明確に求めているごく一部の瞬間だけ、人間が対応している」というのが実態に近い。この両方の作業が、ブログの運営にとって不可欠な「本当の仕事」なのだ。そして、その中でコードとして記録（コミットログに残る）されるのは、自動化された部分の作業だけであることも忘れてはならない。人間が行う手作業も、自動化されたシステムを支える重要な土台なのだ。