私のホームラボAI開発プラットフォーム

 (rsgm.dev)
8 ポイント 投稿者 GN⁺ 6 시간 전 | 1件のコメント | WhatsAppで共有
  • ホームラボのサービス管理のために OpenCode Web UI にGitアクセスを付与し、AIによる変更はPRレビュー後にGitOpsがデプロイする流れを構成
  • 約12個の docker compose スタックをArcaneに移してGitOpsで管理し、AIツールをサービス保守に活用
  • コンテナ更新時にはリリースノート確認、破壊的変更の点検、手動確認に数時間かかっていたが、今ではリリースノートの要約を数分で読めるため、バージョンアップグレードが容易かつ安全になった
  • OpenCodeはサーバーとして動作し、ターミナル、ファイルブラウザ、Git diff、git worktree を提供し、複数デバイス間で継続的なコーディングセッションを同期する
  • AIは実サービスへ直接アクセスできず、Gitブランチだけをpushできるため、レビューされていないコード がデプロイされない構造になっている

ホームラボ管理フロー

  • OpenCode Web UIにGitアクセスを付与してホームラボ管理を容易にし、OpenCodeがGitへ変更をpushした後、人がPRを承認してからGitOpsが変更をデプロイする
  • OpenCodeはサーバーとして動作し、継続的なコーディングセッション が複数デバイスで同期される
  • 管理しているサービスは約12個のdocker composeスタックで、最近Arcaneへ移してGitOpsで管理・デプロイしている
  • AIツール活用の最初のユースケースは コンテナ更新 だった
    • 以前は各サービスのリリースノートを探し、破壊的変更を確認し、更新を実行し、各サービスの問題を手動で確認する必要があった
    • このプロセスには数時間かかっていたが、今ではリリースノートの要約を数分で読めるため、バージョンアップグレードが容易かつ安全になった
    • ほとんどのコンテナにhealthcheckを追加するためにAIを使い、問題をより早く発見できるようになった

OpenCode

  • 主にClaude Codeを使っていたが、AIプロバイダー各社がトークン制限によって顧客価値を下げつつあるため、別の選択肢を見るようになった
  • 求めていたツールは、特定ベンダーに依存せず、主要プラグインがサポートするコーディング環境だった
  • 複数のコーディング環境を試した後、OpenCode を選び、試した選択肢の中で最も気に入ったツールだった
  • OpenCodeに 内蔵WebサーバーとWeb UI があることが、ホームラボAI開発プラットフォーム構想のきっかけになった

AI開発プラットフォーム

  • Truenasホスト上に基本的な開発ツールを備えたシンプルなVMを作成し、OpenCodeのWebサーバーを systemd unit として追加
  • この環境は内蔵ターミナル、ファイルブラウザ、Git diff、git worktreeサポートを提供し、複数のコーディングセッションを同時に管理できる
  • OpenCodeのモバイルWeb UIは質問・回答ポップアップが非常に良かった
  • GitサーバーにはOpenCode専用ユーザーと専用SSHキーを付与
    • OpenCodeはプロジェクトをクローンし、ブランチをpushできる
    • デプロイブランチには直接pushできない
  • ワークフローではAIを PRレビューの後 に置き、OpenCodeが変更を作成し、人がPR上で直接マージする
    • この構造により、レビューされていないコードがデプロイされるのを防ぐ
  • VMはインターネットとGitサーバーにはアクセスできるが、実サービスにはアクセスできない
    • 影響範囲が小さいため、ビルドツールやテスト依存関係をインストールする必要があるときにOpenCodeへVMのroot権限を与えても問題ないと判断した
  • この構造は、プリインストール済みツール、アクセスガードレール、監査ログを備えた、開発者向け一時コンテナ形式の本番開発者プラットフォームへ拡張できる
  • 現在の構成は必要な機能を提供しつつ、構成要素が多すぎない

Workflow

  • 基本的な作業フローは、OpenCodeで機能または改善を計画する段階から始まる
    • 計画には仕様、実装計画、自己レビューが含まれる
  • 可能な場合は変更をテストまたは検証する
  • 気に入らない部分はOpenCodeと反復的に修正する
  • OpenCodeが変更を機能ブランチへpushする
  • そのブランチでPRを開き、満足したらPRをマージする
  • マージ後は GitOps がデプロイを引き継ぐ
    • dockerサービス変更はArcaneが処理する
    • Home Assistant設定変更はGitOpsプラグインが処理する
    • ブログ変更はCloudflare Pages workerが処理する

Arcane GitOpsとOpenCodeの組み合わせ

  • サービス群をTruenasからArcane GitOpsプロジェクトへ移し、主な目的はTruenasで動かしていたすべてのdocker composeスタックをGitベースのリポジトリで管理することだった
  • そこへOpenCodeも加えると、この方式は予想以上にうまく機能した
  • 携帯電話からすべてのコンテナのネットワーキングを更新でき、散在した構成管理がはるかに容易になった
  • 以前はすべてのcomposeスタックを見て回り、ネットワーク接続を追跡するのに数時間かかっていた
  • 今ではOpenCodeにコードベースと目標を指定し、生成されたPR変更を確認した後にマージできる

残る制約とアクセス制御

  • 最大の空白は CIフィードバック である
  • GitHubではコーディングエージェントがActionsログを見て、失敗したテスト、リンターエラー、スタックトレース、IaC planの変更を診断できる
  • この方式は、単体テストで扱えない変更に対しても高速なフィードバックループを維持するのに役立つ
  • Forgejoではこのフローがより難しい
    • Forgejo Actionsは公開APIを通じてjobログを公開していない
    • 文書化されていないAPIはあるが、そのAPIを前提に構築したくはない
  • 現在の構成では、AIが変更対象サービスへ直接アクセスできないまま、どのデバイスからでもホームインフラの変更を作成できる
  • コンピュータで変更を始め、携帯電話でPRをレビューし、GitOpsにデプロイを任せることができる

関連記事

1件のコメント

 
GN⁺ 6 시간 전
Hacker Newsのコメント

  • 自分の環境に合った AI統合のやり方 をまだ探しているところ。今のところForgejoとコーディングエージェントの間に相互作用はなく、Forgejo Actionsランナーも試してみたが、コンテキスト管理が曖昧だった。
    IssueやPRの内容は受け取れるが、何度もやり取りが発生したり、議論がIssueからPRへ移ったりすると、すぐに見通しが悪くなる

  • 似たようなことをしていて、常駐のopencodeサーバーの代わりに Forgejoアクションランナー の中でopencodeを実行するワークフローを使っている: https://codeberg.org/dragonfyre13/forgejo-opencode
    まだ調整中だが、要点としてはForgejoのIssue内で /oc を使って Opencode を呼び出すと、レビュー用のPRを作って戻ってくる仕組み。

  • 技術業界では、多くの人がほぼ同じ時期に似たようなことを独立して経験しているのに、実際に文章にしたり共有したりする人は少ない、と感じることがある。
    自分も 似たようなシステム を作っているので、記事とコメントを見て、みんな同じ過程をたどっているのだと感じられて楽しかった。

    • 技術業界だけの話ではなく、よくある現象。私たちはそれほど独創的ではない
    • 自分もこれを 3通りの方法 で作ってみたし、e2b.devも使ったことがあるが、良いサービスだった。
      問題は、時間の99%をクールなものをハックすることに使い、1%しか発信に使っていないこと。もっと発信すべき
    • 技術業界の人たちは何でも無料であることを期待しすぎているのだと思う。
      弁護士と話していて時間がほとんど終わったときに「質問をもう1つだけ」と言おうとしたら、弁護士は「あと30分予約して、その話をしましょう」と言った。公平なやり方だ

  • 自分の AIラボ について記事を書こうという動機を探していたが、この記事がまさに必要だった刺激になった。
    自分の構成も似たアイデアだが、n8n/git/argo/k3sを使っていて、主にQwenやGemma4で処理できる自動化ワークフロー向け

  • なぜこのドメインが Quad9リゾルバ でブロックされているのか知っている人がいるのか気になる。Quad9がドメインをフィルタしていて、Webサイトを開けない。
    dig @9.9.9.9 rsgm.dev NS の結果に EDE: 17 (Filtered) が出る

    • 推測だが、登録されたばかりだからかもしれない。登録から約8時間しか経っておらず、作成時刻は 2026-06-15 14:01:25 UTC

  • この構成をまだ使っていない主な理由は2つある。1つはプロジェクトのビルドのためにopencodeを実行するVMへ与える必要がある リソース、もう1つはより高速なテスト。
    自分はpiコーディングエージェントをMac上で直接動かし、redis、postgres、kratosのような一式のソフトウェアも一緒に動かしている。コーディングエージェントがメインの開発マシン上で動けばより速くビルドできるし、バックエンドだけを再ビルドして再起動し、その後UIクライアントで変更をすぐ試す、といった形でより素早く確認できる

  • 自分もかなり似たことをしている。Proxmox LXC で OpenCode を動かし、その上に Kimaki レイヤーを追加して Discord 統合を付けた。
    好むと好まざるとにかかわらずコードベースとチャットできるし、好みなら音声メッセージも使えて、かなりクール

  • 素晴らしい。ホームラボAI はとても面白くなりそう。
    今はClaudeに、自分の全機材にまたがるホームラボを管理させているが、ホームラボの導入と保守が「何年も魅了されるが完全にはうまく動かず、時間を吸い取る罠」から「実際に良いアイデアで、自分の能力を拡張してくれるもの」へと変わった。

    • 最新モデルを使っても時間を節約できる小さな場面はあるが、たいていは微妙な 設定の問題 のせいで膨大なデバッグが発生し、全体としては損になることが多かった。
      「docker composeファイルを作って」や「NSD設定を出して」のように非常に狭く指定した作業なら問題ないが、その場合でも、どんな基盤技術が必要か、何を聞くべきかはすでに分かっている必要がある

  • OpenCode Web UIにGitアクセスを付けてホームラボ管理を簡単にし、OpenCodeがGitにプッシュしたら自分がPRを承認し、GitOpsが変更をデプロイする、という構成はかなり良さそう。
    ただ、読む前から、似たことをするには RAMとGPU を用意するのに何千ドルも必要なのか気になる。

    • 0ドルかもしれない。OpenCodeは単なる ハーネス なので、オンラインでホストされているどんなモデルにも接続できる

  • こちらでも似たことをしているが、エージェントがPRも開けるようにしており、ReARMシステムでリリースメタデータと エージェントセッション を追跡している。
    最近では、エージェントがReARM経由でHelmベースのデプロイを追跡するオプションも公開した: https://docs.rearmhq.com/workflows/devops.html

    • この点には触れていなかったが、記事を書いている最中にForgejo PR APIを呼び出すスキルを簡単に追加できそうだと気づいた。
      残念ながら、GitHubのようなCLIはForgejoにはない