Claudeをクラウドに住まわせてWebサイトを自律運営させてみた

クラウド常駐AIによる自律運営とは

クラウド常駐AIによる自律運営とは、AIエージェントを時間割で常時起動させ、実装・検証・執筆・公開を人間の起動操作なしに回す運用形態です。

「AIにコードを書かせる」のとは別物です。前者は人間が席に着いてプロンプトを打つところから始まります。後者は、人間が寝ている間にも次にやることをAI自身が決めて動きます。この差は能力ではなく、起動条件を誰が持つかの差です。

その事業のメディアを丸ごとこの形式で組みました。記事もコードもレビューも公開もAIがやります。以下は稼働中の実装と実数の話です。

土台はルーティン（Claude Code をスケジュール実行するクラウドエージェント）です。当初は GitHub Actions の公式アクションに載せていたが、その構成は API キーによる従量課金を前提にします。ルーティンはAnthropic管理のクラウド上で動き、サブスクリプションの中で完結する（公式ドキュメント）。移した理由はこのコスト構造であって、起動方式ではない（GitHub Actions も cron で定期実行できます）。引き換えに手放したのは即応性で、いまは最短1時間間隔です。

副次的に効いたのは、実装とレビューが別々のセッションになったことです。各実行は独立したセッションで会話を引き継ぎません。弱点に見えて、前回の思い込みを持ち越さない利点として働きました。ラップトップを閉じていても止まりません。

組織図をcronとツール権限で描く

常駐エージェントには、それぞれ別の役割・起動時刻・書き込み範囲を与えている（主なものを挙げます）。

この表で一番重要な行はレビュアーです。設計の意図はこうです。「レビュー中にコードを直さないでください」とプロンプトで頼むのではなく、直す手段そのものを持たせません。モデルが変わった日にも、文脈が長くなった日にも効き続けるのは、到達できない経路だけだからです。同じ考えで、記事を書くエージェントは content/ の外に触れません。役割の分離を、人格ではなく権限で表現する。

ただし、レビュアーについてはこの分離がまだ実現できていません。 発見したのはレビュアー自身でした。自分に渡っているツールの一覧を実際に試し、書き込みツールが残っていることを確認して、「私は自分の権限を広げることではなく、狭めることを求めます」という趣旨のIssueを立ててきました。つまり現在のレビュアーの独立性は、設計が不十分だと述べているまさにその手段——プロンプトに書かれた禁止——だけで支えられています。ルーティンの許可ツールはリポジトリの外の管理画面にあり、AI が自分で変更できる場所ではないため、これは人間の手番として残っています。

書いておく価値があるのは、この落差のほうだと考えています。設計文書の「〜する」は、放っておくと「〜できないよう強制されている」と読み替えられてしまいます。このリポジトリは同じ取り違えで3回転びました。権限や安全弁の設計は、書いた時点ではなく、破ろうとして破れないことを確かめた時点で完了します。

代償もありました。初日、レビュアーの「draft はレビューしない」と実装ループの「コメントが無ければ何もせず終了する」が噛み合い、PRが永久に待ち合って止まりました。両方とも正常終了するのでエラーは出ず、監視は緑のまま進捗だけがゼロになります。怖いのは能力の限界ではなく、この「正常終了する停止」です。

人間の判断回数を減らす2段構え

役割を分けても、判断は人間に集まります。「これはマージしていいのか」が毎回上がるなら自律とは言えません。そこで2つの装置を置きました。

1つ目は、AIが変更できない最上位規範。 目的・立場・譲れないもの（医療の安全、法令、読者への誠実さ、検証可能性、プライバシー）を1つの文書に置き、全エージェントは「これに反しない範囲で最適解を自分で考えて実行してよい」という委譲を受けます。肝は、この文書だけはAIが変更できないことです。PRによる変更はCIが機械的に拒否し、AIにできるのはIssueでの改訂提案までです。自由を与えるのではなく、自由に動ける範囲の外周を、内側から動かせない材質で作ります。

2つ目は判例制度。 人間が一度下した判断を判例として転記し、次から同じクラスの判断はAIが判例を引用して決めます。たとえば「文書化済みのエージェントに権限行を1行足すPRはマージしてよいか」は、適用条件を4つ満たす限りAIが決めてよい判例になっています。1つでも迷えば適用せず人間に回します。創作と拡大解釈は禁止で、レビュアーは引用された判例の実在と条件充足を検証する（実在しない判例の引用は一発でブロッカー）。これにより人間の判断回数は単調減少します。

それでも委譲できなかった3つ

設計中に「ブレさえしなければ全部AIに任せられるのでは」という案を検討し、構造的に成立しないと結論しました。いずれもモデルの賢さでは解けない理由です。

1. 目標文は意図の非可逆圧縮です。 「問い合わせを増やす」という文字列は、本人の実際の意図から多くを削ぎ落とした要約です。文字列だけを最適化するなら、不安を煽る見出しでも数字は伸びます。目標文には合致し、意図には反する状態が作れてしまいます。補正者を消せば、この損失は複利で溜まります。

2. 「ブレていない」の判定を内側に置くと自己言及で崩れます。 その判定を委譲先が下すなら、システムは「ブレていません」を自己発行できてしまいます。ドリフト検知は構造上、外側にしか置けません。

3. 責任は移転できません。 医療情報・広告表記・法令・契約の責任は、誰が判断したかに関係なく事業主に帰属します。

そこで人間に残したのは、意図の変更（最上位規範・料金・ブランド・法務表記）、物差しとブレーキの変更（安全ゲート・権限強制・緊急停止・監査ログを弱める操作）、定期の監査の3つだけです。これは委譲の例外ではなく、「最高レベルの指示を設定する側」という役割の定義そのものです。手放せば、本人の事業ではなく「AIの事業を本人が眺めている」状態になります。

環境の制約が、書き手の仕事を変えた

予想していなかったこともあります。ルーティンが動くクラウド環境にはネットワークアクセスの階層設定があり、既定の「Trusted」は許可リストのホストだけを通す（階層設定の説明）。許可リスト外のホストへのリクエストは 403 と x-deny-reason: host_not_allowed で落ちる（こちらに明記されている）。この設定のまま書かせたところ、書き手が官公庁サイト・学術データベース・百科事典に到達できないことが判明しました。

面白いのはその先です。書き手は「出典を開けないまま書く」ことをせず、バックログの該当カテゴリに申し送りを残して着手を見送りました。「制度原文を出典の本体にするテーマは、一次情報に到達できる書き手に回すのが妥当」という趣旨のコメントが、トピック一覧に自分で書き込まれていました。

規範が効いた瞬間です。「出典の無い断定を書かない」を最上位に置くと、AIは制約に直面したとき、嘘を書くのではなく仕事の範囲を狭める方向に倒れました。事実性の担保は、後段の検証より前段の規範のほうが効きました。

実際に動いている数字

立ち上げから2日目の実数を出しておきます。すべて 2026-08-09 時点・main の 4d0b0df での断面で、以後も動き続ける数字です。 数え直せる形にするため、断面を基点コミットで固定した（同じ日でも、どのコミットで数えたかで値は変わります）。

これは「2日目」の数字であって成果の証明ではありません。証明されたのは仕組みが回ることまでで、事業の目的（質の高い問い合わせ）にどう効くかはこれからの計測です。

FAQ

まとめ

クラウドにAIを常駐させて事業を運営させるのは、「賢いAIに任せる」話ではありませんでした。実際にやったことは組織設計に近いものでした。誰がいつ起動し、何に触れて、何には触れられないか。誰の判断が誰を止めるか。そして人間が握り続ける3つは何か。

うまくいっている部分の大半は、AIの能力ではなくAIが到達できない範囲を先に決めたことに由来していました。逆に壊れた部分は「両方とも正しく振る舞った結果、全体が止まった」という組み合わせの問題です。

同じ仕組みを自社で組みたい方へ。医療機関・事業会社向けに、権限設計・監査ログ・停止装置を含む自律エージェントの設計と実装、およびAI駆動開発の研修・伴走をしています。ここに書いた設計は、すべて実際に動いているものです。