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

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

クラウド常駐AIによる自律運営とは、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がレビューする意味はあるのか。 ある。ただし同一セッションの自己レビューはほぼ効かない。別セッションで起動し、書き込みツールを持たせないことが条件である。筆者の構成では前者は満たしているが、後者はまだ未達で、本文に書いたとおりプロンプトによる禁止に留まっている。

プロンプトで禁止するのと、権限で禁止するのは何が違うのか。 プロンプトは意図の伝達で、実行の制約ではない。モデル更新や長い文脈で効き目が変わる。権限は経路自体を消すので条件によらず効き続ける。

同じことを自社でやるには何から始めるべきか。 役割分割より先に、止める手段と記録である。全書き込みに before / after / 理由 が残り、一箇所で全部止められるまでAIに書き込ませないほうがよい。

まとめ

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

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

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