自律的エージェント開発環境構築と実証実験：単一プロンプトでのフルスタックアプリケーション作成まで

概要

単一の指示（プロンプト）だけで、以下の全工程を自動完結させることに成功しました。

• リポジトリの生成
• アプリケーションおよびテストの記述
• CI パイプラインによるテスト実行（緑色化）
• PostgreSQL データベースの用意
• HTTPS 保護環境へのデプロイ

これには、追加の手動操作は一切不要でした。LLM は再び驚くべき能力を発揮しています。最近ではツールが欲しい時に私が構築する「失望の谷」から抜け出し、自動化が再び楽しくなってきました。ただし、自機のルートアクセス権限を付与して自動モードにするのはまだ慎重に検討する必要があります。

課題と目標：自律的なソフトウェア開発ライフサイクル（SDLC）

LLM の行動範囲を構造的に制限する「フルリモート型エージェント開発環境」の構築を目指します。以下の全工程を自宅サーバー上で自律的に実行することを目的としています。

• 技術スタックの研究: 適切なツール選定とパッケージ管理。
• 開発・テスト: プランニング、コード記述、テスト作成。
• CI/CD: Git コミット、CI パイプラインの構築と実行。
• デプロイ: データベース、観測性（オビリティ）、ドメイン、SSL を備えた本番環境への展開。

コスト構造:

• インフラはすべて自宅サーバー完結のため、クラウド利用料は不要です。
• 実験特有のコストは、Codex サブスクリプションの月額約 20 ポンド のみです。

サーバー環境構成

本実験に使用されているハードウェア構成は以下の通りです（※上段サーバーの年式は原文記載の 2019 年に従います）。

• 下段サーバー (旧):
  • 製品：2014 年製デュアルコア i3
  • 用途：5 年間「ホームラック」運用。ブログ、Pi-hole、Prometheus/Loki/Grafana スタック（約 45 の Docker コンテナ）をホスト。
  • 現状：ルーターからのポート 443 転送設定ありが、セキュリティリスクを避けるため現在は使用停止中。
• 上段サーバー (新):
  • 製品：2019 年製第 10 世代 i7（新品購入時）
  • メモリ：32GB RAM
  • 用途：本格的な開発環境として使用。

技術スタックとアーキテクチャ

コア開発は Coolify を経由して自己ホストされます。推論・連携機能の一部は外部利用しつつ、ハードウェア不足分については OpenAI が支援する構成です。

構成要素	役割と備考
Pi-hole	ローカル DNS ルール設定（広告ブロック副効果あり）。
Tailscale	自宅ネットワークをモバイルのように随行させる VPN。
Coolify	Docker ベースの自己ホスト型 PaaS（Heroku 風）。
Forgejo	自己ホスト型 Git リポジトリおよび CI/CD ランナー。
Hermes	OpenClaw 風の仮想アシスタント（Web UI 付き）。Codex を推論エンジンに使用。
Telegram	遠隔地からのエージェント制御・チャットツール。
Firecrawl	エージェントと Web 間を繋ぐスクレイピング・翻訳層（自己ホスト）。
Porkbun & Let's Encrypt	ドメインレジストラと、動的な SSL 証明書発行。
その他	PostgreSQL, Redis, アプリケーション依存パッケージなど（すべて Docker 内蔵）。

ネットワーク構成の工夫

「別の金属」上のサーバー運用により、Hermes が誤作動を起こしても再構築が容易です。 外部からの直接アクセスを防ぎつつ、内部での利用を実現するために以下の工夫をしています。

1. 入出力（Ingress）の制限と Tailscale の活用

• 新サーバーにはポート転送を行わず、攻撃対象領域を削減。
• Tailscale を出口ノードとして設定し、外出時はスマートフォンのトラフィックをここへ誘導。
• Pi-hole で以下の

  dnsmasq

  ルールを追加：

  address=/internal.jakeshomelab.me/192.168.1.201
  

  これにより、

  *.internal.jakeshomelab.me

  への要求はすべて新サーバー（Coolify のリバースプロキシ）に解決されます。

2. 「幽霊サービス」用 SSL 証明書の発行（DNS-01 Challenge） 公開ドメインへの A レコード登録を避けつつ、有効な HTTPS URL を生成する仕組みです。

• 手順:
  1. ドメイン購入（Porkbun）→ API キー生成 → Coolify への設定。
  2. Docker Compose の Caddy/Traefik 設定変更：

     --certificates-resolvers.letsencrypt.acme.dnschallenge=true
     --certificates-resolvers.letsencrypt.acme.dnschallenge.provider=porkbun
     --log.level=INFO
     

  3. 自動プロセス:
     • Traefik が

       _acme-challenge

       TXT レコードを Porkbun API で作成。
     • Let's Encrypt が検証を行い、証明書を発行。
     • 検証完了後、レコード削除。

利点: エージェントが適意なサブドメインでサービスを作成しても、✨魔法のように✨自動的に HTTPS URL が整理されます。公開 A/AAAA レコードがないため、インターネット上のスキャンノイズに対抗できます。

開発スタックと MCP（Model Context Protocol）

隔離された環境内でのツール連携を確立します。

Forgejo (Git & CI)

GitHub を使わない理由：

• トークン管理による分離性の低下。
• API/CI リミットの不足。
• 頻繁なダウンタイムのリスク。 Forgejo は堅牢な自己ホスト型代替手段です。環境変数でのトークン設定を含めつつ、GitHub 同期も可能にしています。

Hermes (AI エージェント)

OpenClaw スタイルのパーソナルアシスタントで、以下の機能を備えます：

• Web UI: 標準的な ChatGPT 風インターフェース（ノートPC 操作可）。
• 共有ファイルシステム: Docker ホストからのマウント+Samba 経由で、エージェントと人間が同じワークスペースを共有。
• Telegram インテグレーション: ログイン情報なしでの簡易接続（2 分セットアップ）。
• 自己構築スキル: ドキュメント読み込みから MCP を調査し、独自スキルを作成可能。

Firecrawl (Web スクレイピング)

• エージェントが SERP データや Web クロールを行う際の仲介役。
• Hermes との連携設定を Coolify 上で一元管理。

Coolify (PaaS プラットフォーム)

「接着剤」として機能し、Docker/Compose ベースで Heroku/DigitalOcean のような利便性をもたらします。 主な魅力:

• 完全な Docker 抽象化:

  docker exec

  で底上げ操作が可能。
• 自動 SSL & ルーティング: 前述の DNS-01 構成との親和性。
• ワンクリックデプロイ: PostgreSQL, Redis, Hermes, Forgejo など多数のプリメイドレシピ付き。
• バックアップ機能: S3 への PostgreSQL バックアップ（3 クリック）。
• 自動 CI/CD: GitHub Webhook を用いたプッシュ時の自動デプロイ。

実証実験：単一プロンプトによるフルアプリ作成

スタートガンとなるプロンプト

「MyFitnessPal のようなカロリー追跡アプリを構築してください。特定の食品や料理を入力するフォームが必要です。」

与えられたタスク:

1. アプリの構築。
2. テストを含むリポジトリへのコミット。
3. CI によるテスト実行。

4. http://calories.internal.jakeshomelab.me

   へのデプロイ。

要件制約:

• フルスタック Svelte Kit
• DB: Drizzle + PostgreSQL
• CSS: Tailwind
• デザイン: モバイルファースト
• インフラ: Docker Compose + 独自 PostgreSQL インスタンス

実行結果の概要

追加のプロンプトなしで、以下の通り完了しました。

• リポジトリ作成: SvelteKit, Drizzle, PostgreSQL, Tailwind の初期化とブートストラップ。
• コーディング: アプリロジックとテスト記述、段階的コミット。
• CI/CD: テストパイプライン構築→失敗修正→緑色化。
• デプロイ: アプリと DB を Docker コンテナ化し、Coolify への展開。

エラーの自己解決: デプロイ後の CSRF エラーが発生しましたが、追加のプロンプトなしで：

1. エリア診断および修正コード生成。
2. リグレッションテストの追加。
3. 再デプロイまで自動完結しました。

結論と今後のステップ

成功の実感

「プロンプト → コード → テスト → CI → デプロイ → バグ修正」という完璧なループが、単一の指示で完結しました。これが本物の「魔法」であり、面倒な中間作業を省くことに大きな喜びを感じます。

セキュリティとリスク管理

完全な自律性とセキュリティのトレードオフがあります。現時点では Hermes は以下の危険な動作が可能であることに注意が必要です：

• 破壊行為 (

  rm -rf /

  )
• データ削除・資格情報漏洩
• 推論トークンの消費（燃やし尽くし）
• 外部からのゴミデータをダウンロード

現在のリスク許容度: 「失敗モード」を「eBay の箱（サーバー）の再構築」となり、「ラップトップの破壊」に変更しました。これは安全な方向ですが、完全ではありません。

次のステップ：より厳格な自律性へ

完全に無制限な自動化に戻る前に、以下の層を追加する検討が必要です：

• ネットワーク分離: 独自 VLAN の作成と外部へのアクセスブロック。
• 資格情報管理: スコープ最小化と定期的なローテーション。
• バックアップ自動化: ワンショットタスク化の推進。
• 承認プロセス: 重大な変更に対する手動承認ゲートの導入。

バランスの重要性: 「5 分ごとに指示が必要」という状態と、「発射コードを持ったまま放置」の状態の間、最適な自律性のバランスを見つけることが次期の実験テーマです。