私のOpenClaw構成: ウェブサイトを作れる1台の箱

今あなたが読んでいるこのウェブサイトは、自宅の小さなLinuxボックス上のAIエージェントによって保守されています。しかも、エージェントが実際の作業をこなしながら、決して何も壊せないように設計されています。

まず何よりも、この記事の自己実証的な部分から：この記事は、記事の中で説明しているまさにその仕組みによって週に一度更新されています。 スケジュールジョブがOpenClawエージェントを起こし、エージェントがこのページを読み直し、古くなった箇所を直し、ガードチェックを通し、結果にスタンプを押します。ページ上部の「更新日」はその週次ジョブが書き込んだもの — 人間は誰も入力していません。あの日付が新しければ、この後の図に描かれたパイプラインが直近7日以内に端から端まで実際に動いた、ということです。

箱の全体像

すべてが1台のマシンに載っています。モデルがトークンを供給し — 最近はほとんどDeepSeekの安価なクラウドAPIで、ローカルモデルはフォールバック — OpenClawゲートウェイがそれをツール付きのエージェントに変え、エージェントがプレーンテキストのコンテンツを編集し、決定的なジェネレーターがサイトをビルドし、ゲート付きのスクリプト1本だけがサーバーへの唯一の道です。

最終的に手に入るもの

セットアップの話の前に、完成形から：

• チャットで「Xについての記事を下書きして」 → エージェントがサイトの content/ フォルダーにMarkdown記事を書き、フロントマターのスキーマとサイトの文体ルールに従い、ローカルプレビューを再構築します。
• 「デプロイして」 → エージェントがデプロイスクリプトを実行。デフォルトはドライラン：サーバー上で変わるはずのファイルを一覧表示するだけで、何も触りません。実際の公開には私からの明示的な --go が必要で、その場合もスクリプトはまずサーバー側バックアップを取り、決してファイルを削除しません。
• 週に一度、スケジュールジョブがエージェントを起こしてサイトを更新させます — 古い日付の修正、弱い記事の改善、リンク確認 — そして何かが公開される前にガードチェックが走ります（詳細はステップ3で）。
• laserlloyd.com 自体がこの方法で管理されています。

役割分担がすべてです：エージェントが手を動かし、スクリプトがルールを強制し、私は唯一重要な判断 — 変更を公開するかどうか — だけを下します。

ハードウェアとOS：どんなLinuxマシンでもOK

私は大きなモデルをローカルで動かすのが好きなのでユニファイドメモリの多いミニPCを使っています（フルスタックは姉妹記事 8つのAIエージェント、1台のAMDボックス に詳しく）。しかしウェブサイト管理だけなら要件は控えめです：

• 64ビットのLinuxマシンなら何でも — ミニPC、古いデスクトップ、性能のあるノートPCでも。RAM 16GBで小型ローカルモデルは十分動き、32GB以上なら文章の質が目に見えて上がる中型モデルが使えます。
• systemdのあるディストリビューション（ほぼすべて） — 以下のスケジューリングとサービス管理はsystemd前提です。
• 静的サイトジェネレーター用の Python 3、デプロイ用の rsync + SSH。

GPUすら厳密には必要ありません。小型の指示チューニング済みモデルは、下書きや文章編集程度ならCPUでも十分動きます。ただ、両方を何か月も動かしてたどり着いた正直なところを言うと：DeepSeekのクラウドAPIが、いまや私のOpenClaw構成全体の主役です。 オープンなローカルモデルが当初の計画で、今も動いてはいますが、トレードオフが積み重なります — モデルの読み込みに数分、サービス間でのVRAMのやりくり、そして1メッセージあたり1セントの何分の1かで済むフロンティア級の安価なクラウドモデルに比べて、目に見えて頭が悪い。ローカルは私のフォールバックでありプライバシー層であって、日常の主力ではありません。（実際の月額はおよそ$24（約3,600円）。）

ステップ1：エージェントゲートウェイとローカルモデルの導入

必要なのは2つ：OpenAI互換APIでモデルを提供するもの、そしてそのモデルをエージェントに変えるもの — ツール、ファイルアクセス、スケジュールジョブを持つ存在に。

モデルサーバー。 LM Studio、Ollama、llama.cppのサーバー、どれでも動きます。どれを選んでも、再起動に耐えるようsystemdユーザーサービスとして動かしましょう：

# ~/.config/systemd/user/model-server.service
[Unit]
Description=Local LLM server
[Service]
ExecStart=/path/to/your/model-server --port 1234
Restart=on-failure
[Install]
WantedBy=default.target

systemctl --user enable --now model-server
curl -s http://localhost:1234/v1/models   # 動作確認

エージェントゲートウェイ。 私はOpenClawを使っています。名前付きエージェントをホストし、ツール（シェル、ファイル読み書き、ウェブ検索）を与え、各エージェントをモデル（ローカルまたはクラウド、フォールバック付き）にルーティングし、チャットインターフェースを提供するオープンなセルフホスト型ゲートウェイです。インストールしたら「ウェブマスター」エージェントをローカルモデルに向け、ウェブサイトのディレクトリに限定したツールアクセスを与えます。どのゲートウェイを選んでも重要な設定ルールが2つ：

• ゲートウェイはループバックにバインドし、チャットUIには認証を付けること。シェルアクセスを持つエージェントをネットワークに開放してはいけません。
• エージェントの作業ディレクトリをサイトのリポジトリに限定すること。編集すべきは content/ であって、ホームディレクトリではありません。

2階層：日常はローカル、修理は強力なクラウドモデル

1台の箱に2つの頭脳。OpenClawのエージェント群は — DeepSeekの安価なAPIに乗り、その背後にローカルモデルを控えさせて — 日常の大量作業（下書き、編集、リンクチェック、週次更新）をこなします。しかしシステム自体が壊れたとき（設定のリグレッション、ゲートウェイのクラッシュ、動かないビルド）は、箱全体を患者として診てくれる強力なクラウドのコーディングモデルにエスカレーションします。その話は姉妹記事 OpenClawが壊れたら、Claude Codeで直す に書きました：OpenClawのエージェントが労働力、強力なコーディングモデルが整備士です。

顔ぶれ：箱の上のすべてのボット

ゲートウェイは名前付きエージェントの一団をホストし、それぞれが自分の仕事に合ったモデルにルーティングされています。全員が家族の使うチャットアプリ DisPatch に登場します — ただし両モードに出るわけではありません：DisPatchのPINロックが一団を、常時使える安全なセットと、アンロック後にだけ現れるフルパワーのセットに分けます。

ボット	役割	実行先	DisPatch（ロック時）	DisPatch（アンロック時）
Bits	受付 — あなたが話す相手。依頼を理解し、適切な専門家に振り分ける	DeepSeek flash（クラウド）	—	✔
Brains	熟考担当 — 仕様、監査、待つ価値のあるものすべて	DeepSeek reasoner（クラウド）	—	✔
Flash	手早い仕事とスケジュールされたフォローアップ — 遅れた作業を追う番犬	DeepSeek flash（クラウド）	—	✔
Hermes	コーディングエージェントへの橋渡し — 振り分けられたプログラミング作業	DeepSeek（クラウド）	—	✔
Doxy	ローカルの働き者 — 家の外に出すべきでない大量・プライベートな作業	122Bローカルモデル（vLLM）	—	✔
Charley	画像認識 — 「この写真に何が写ってる?」など画像を扱うタスク	Gemma 31B（ローカル、LM Studio）	✔	✔
Alpha & Beta	家族向けの安全な汎用ヘルパー — 宿題の質問、日常会話	DeepSeek flash（クラウド）	✔	✔
Terminex	エージェントではない — DisPatchのReasonixコーディングターミナル、ブラウザ内の本物のPTY	DeepSeek（クラウド）	—	✔

正直なところ、実際のパフォーマンスは：

• DeepSeekを使うボットが日常の主力です。 flash層のエージェント（Bits、Flash、Alpha、Beta）は数秒で答え、1メッセージあたり1セントの何分の1かで済み、ウォームアップも要りません。reasoner層のBrainsは1回の回答に目に見えて時間がかかります — それが狙いで、考える価値のある問題を渡す相手です — それでも1セッション数円程度です。スタック全体の実測費用は費用の記事にあります。
• ローカルのボットは遅くて頭も劣りますが、プライベートで無料です。 Doxyの122Bモデルはメモリへの読み込みに数分かかり、長いターンではさらに数分走ることもあります。ゲートウェイのタイムアウトはこれに合わせて特別に引き上げる必要がありました。Charleyの画像認識モデルは例外で、常に稼働しています — 画像の説明はここの安価なクラウド層のどれもやらないので、ローカルモデルがVRAMに見合う働きをします。
• 安全なセットはあえて退屈にしてあります。 Alpha、Beta、Charleyがロックモードの顔ぶれです：一般的な情報と画像認識のみ、ファイルやシステムに触れるツールはなし。だからこそ子どもにスマホを渡すのが何でもないことになります。

ステップ2：静的サイト＋ゲート付きデプロイスクリプト

エージェントとWordPressは相性が悪い — データベース、ログイン、プラグイン、PHPはすべて攻撃面であり故障要因です。静的サイトジェネレーターこそエージェントの自然な相棒：サイト全体がフォルダー内のプレーンテキストファイルで、ビルドはコマンド1つ、「公開」はファイルコピーです。私のジェネレーターは数百行のPython（Jinja2＋Markdown＋YAML）ですが、Hugo、Eleventy、Zolaでも同じです。重要なのは次の契約：

• コンテンツはフロントマター付きMarkdownファイル。 LLMはこれをネイティブに編集でき、git diff で何をしたかが正確に見えます。
• ビルドは決定的。 同じコンテンツからバイト単位で同一のサイトが出力される — 出力の変化はすべてコンテンツの変更に遡れます。
• デプロイ経路はただ1つ、それは安全性が組み込まれたスクリプトであり、エージェントが守ってくれると期待する「指示書」ではありません。

最後の1つがこの仕組み全体の心臓部です。私のスクリプトの形：

./deploy.sh preflight   # SSH・ターゲットwebroot・サイズ予算をチェック
./deploy.sh             # ビルド＋ドライランrsync — 変わるものを表示するだけ
./deploy.sh --go        # ビルド＋サーバー側バックアップ＋公開＋検証

スクリプトが保証すること（重要度順）：

1. デフォルトはドライラン。 引数なしで実行してもサーバーを変更することは決してありません。エージェントは保留中のデプロイを見せるために自由に実行できます。
2. 決して削除しない。 rsyncは --delete なしで実行。混乱したエージェントがページを新版で上書きすることはあっても、サイトを消すことはできません。
3. 先にバックアップ。 --go 時、ファイルを上書きする前にwebrootのサーバー側tarballを取得（直近数世代を保持）。バックアップが失敗したらデプロイは中止。
4. フェイルクローズド。 マニフェスト欠落、ホスト到達不能、プレースホルダー設定値はrsync実行前に中止。ソースファイル（テンプレート、スクリプト、設定）はハード除外され、公開webrootに出荷されることはありません。
5. 事後検証。 公開後にライブのホームページを取得し、ビルドが埋め込むジェネレーターマーカーをgrepで確認 — 古いホスティングがまだドメインに応答している場合、HTTP 200だけでは偽陽性になりえます。

エージェントはドライランとpreflightをいつでも実行してよい。--go フラグは私専用。この単純な非対称性が、「AIが本番サイトへのSSH相当のアクセスを持つ」という恐怖を、退屈な日常に変えてくれます。

ステップ3：ガードレール付きの週次スケジュール更新

最後のピースがサイトを自己保守型にします。systemdタイマーが週1回発火し、エージェントに定常任務を渡します：サイトをレビューし、古くなった部分を更新し、弱い記事を引き締め、内部リンクを検証し、結果を — 公開ではなく — ステージングする。そしてこのジョブこそがこの記事を保守しています：任務の一部が「OpenClaw構成の記事を読み直し、現実からずれた箇所を直し、updated: の日付にスタンプを押す」だからです。このページ上部の日付がそのスタンプです。

# ~/.config/systemd/user/site-refresh.timer
[Unit]
Description=Weekly website content refresh
[Timer]
OnCalendar=Sun 06:00
Persistent=true
[Install]
WantedBy=timers.target

タイマーが起動するサービスは、ゲートウェイのAPI（またはCLI）に任務を渡した後、エージェントがステージングした内容にガードチェックを実行します：

• シークレットスキャン。 APIキー、トークン、パスワード、プライベートホスト名の形をしたものがないか差分をパターンスキャン。gitleaks のようなツールがそのまま使えます。1件でも検出されたら実行は中止 — フェイルクローズド、例外なし。
• プロフェッショナル・コンテンツチェック。 執筆担当とは別のプロンプトを持つ第2のLLMが、「企業がこれを公開して問題ないか？」という1つの問いに照らして変更をレビューします。トーン、主張、未完のTODO、プレースホルダーテキスト。不合格なら変更はデプロイされず、人間のレビュー待ちのままステージングに残ります。
• ビルドが通ること（リンク・アセットチェッカー含む） — 画像切れや死んだ内部リンクは、デプロイスクリプトに届く前に実行を失敗させます。

3つすべてが通って初めてジョブはデプロイのドライランに進みます — そしてこのサイトでは、実際の公開はやはり私の --go を待ちます。パイプラインを十分に信頼できるようになって週次ジョブに自律公開を許すとしても、ガード＋削除なし・バックアップ先行のデプロイスクリプトが被害範囲を「変な記事が公開されたのでバックアップから復元した」程度に抑えてくれます。

再現する方法

上記のすべては、この説明だけから構築可能です — 独自の秘伝は何もありません。レシピを凝縮すると：

1. Linuxマシンを選び、ローカルモデルサーバー（LM Studio、Ollama、llama.cpp）をsystemdサービスとしてインストール。
2. エージェントゲートウェイ（OpenClawなど）をループバックにバインドしてインストール。サイトディレクトリに限定したファイル/シェルツールを持つウェブマスターエージェントを1つ作成。
3. まだならサイトを静的ジェネレーターに移行 — Markdownコンテンツを入れて、ビルドコマンド1つで出力。
4. ゲート付きデプロイスクリプトを書く。 上記の5つの保証：ドライランデフォルト、削除なし、バックアップ先行、フェイルクローズド、デプロイ後検証。もっとも丁寧に作るべき部品で、bashで150行程度です。
5. 週次タイマーと2つのガードチェック（シークレットスキャン＋LLMコンテンツレビュー）をフェイルクローズドで追加。
6. パイプラインが信頼を勝ち取るまで、--go は人間の手に。

このサイトの慣例どおり、記事冒頭の「自分で実装してみたい方へ」ボックスは文字どおりの意味です：この記事は、そのままあなたのLLMに渡して各部品をあなたのサイト用に作らせられるだけの詳しさで、意図的に書かれています。デプロイスクリプトの保証リストは、実質そのまま仕様書です。

ハマりどころ

• デプロイスクリプトを唯一の経路にすること。 あなた（またはエージェント）が「今回だけ」と手打ちのrsyncを実行した瞬間、スクリプトが防ぐはずだった事故を自分で作ることになります。私のスクリプトがソースファイルをハード除外しプレースホルダー設定を拒否するのは、一回限りのコマンドではそれができないからです。
• HTTP 200だけではデプロイ成功と言えない。 WordPress移行中、古いホスティングがドメインに応答し続け、新しいファイルが未使用のまま「検証」がすべて通っていました。ビルドにジェネレーターマーカーを埋め込み、ライブページをgrepしましょう。
• エージェントは見せられたスキーマに従う — TODOも含めて。 記事の雛形にプレースホルダーテキストがあると、怠惰なモデルは TODO: excerpt here をそのまま公開します。プロフェッショナル・コンテンツチェックが存在する理由の半分はこれです。
• 執筆者に自己レビューをさせない。 同じモデル、同じプロンプト、同じ盲点。レビュアーには最低でも別のプロンプト、理想的には別のモデルを。
• スケジュールされたLLMジョブにはタイムアウトと「公開ではなくステージング」のデフォルトを。 無監督で公開できる週次ジョブは、いつか日曜の朝6時に変なものを公開します。ステージングのコストはレビュー1回分だけです。
• シークレットスキャンはパイプラインに置く。エージェントへの指示文に置かない。 プロンプトの「秘密情報を含めるな」は願望であり、差分へのフェイルクローズドなスキャンは統制です。