ビルダーの仕事は、コードを書くことではない。AI に書かせ、評価し、統合することだ (1-04)。だが、生まれたコードには置き場が要る。それがリポジトリだ。
2-05 で門番を立てた。次はその内側に、仕事場を入れる。AI が大量に生むコードほど、その置き場の主導権が効いてくる。
GitHub も Azure DevOps も、他社のサーバの上にある。ここでは、その仕事場を、2-02 で AI に渡した一台の上に立てる。
コードの置き場の主導権は自分が持つ
コードは資産だ。事業の中身そのものが、そこに書かれている。それを他社のプラットフォームに預けたままにする理由は、もう薄い。
- 依存を断つ ── 料金体系・規約・可用性が、他社の都合で変わらない
- AI と密につなぐ ── 生成・レビュー・CI を、自分のルールで回す
- 門番と一つに ── 2-05 の認証の内側に、コードも入れる
汎用の Git ホスティングは、すでに OSS にある。書くのではなく、立てる。
Forgejo を立てる
仕事場は Forgejo だ。Gitea 系の単一バイナリで、リポジトリ・Issue・プルリクエスト・レビュー・CI を一つに備える。GitHub・GitLab・Azure DevOps の置き換えである。公式が単体のバイナリを配り、systemd のユニットも公式文書にある。だから 2-02 の決めどおり、ファイルを置いて systemd に登録する。
- バイナリは
/usr/local/bin/forgejo、データは/var/lib/forgejo、設定は/etc/forgejo(公式の手順のまま) git利用者で動かす。ssh の push は、機械の sshd をこの利用者で受ける。新しい口は開けない(2-02)- データは 2-03 の PostgreSQL に乗せる。Forgejo 用のデータベースと利用者を一つ作る
- 待ち受けは localhost の 3000 番だけ。外は Caddy が受ける(後述)
# バイナリを置き、git 利用者を作り、公式の forgejo.service を登録したあと
sudo systemctl enable --now forgejo
git remote add origin git@git.example.com:team/app.git
git push -u origin main # もう自分のサーバに乗っている
Forgejo 用の PostgreSQL の利用者名とパスワードは、人が決めて渡す。
CI/CD は Forgejo Actions で回す
テスト・ビルド・デプロイの自動化は Forgejo Actions だ。GitHub Actions と同じ書式のワークフローがそのまま動く。リポジトリに一枚置くだけである。
# .forgejo/workflows/ci.yml
on: [push]
jobs:
test:
runs-on: host # コンテナを使わず、この機械の上で直接走る
steps:
- uses: actions/checkout@v4
- run: uv run pytest # 自分のランナーで、追加料金なし
ランナー(forgejo-runner)も単体のバイナリで、systemd で動かす。Docker を使わないので、ジョブは機械の上で直接走る(host)。公式文書は「隔離が無く、一つのジョブが機械を壊しうる」と注意しているので、決めを三つ置く。
- ランナーは専用の利用者で動かす(2-02 の「別の利用者」)
- CI で走らせるのはテストまで。本番へ出す手順は「やる前に言う」操作に残す
- 隔離が要るようになったら、Forgejo が対応している LXC(apt にある)に上げる
GitHub Actions の分数の上限と課金から離れる。ランナーも自分の側にあるので、回す回数を気にせず、AI が書いたコードを何度でも検証できる。
手元の道具は Zed と、その中から呼ぶ AI
サーバが Forgejo なら、手元の編集は Zed だ。Rust 製で軽く、複数人の同時編集を備えたエディタで、AI のエージェントをエディタの中から呼べる(ACP)。2-02 で契約した AI をその場に呼び、生成・修正・説明をさせながら、ビルダーは評価と統合に集中する。
git clone git@git.example.com:team/app.git
zed app/ # AI を呼んで、書かせ、評価し、push する
書くのは AI、決めるのは人。仕事場(Forgejo)と道具(Zed)が揃えば、その分担がそのまま回る。
門番の内側に置き、段階的に移す
Forgejo はリバースプロキシの内側に置く(2-05)。GitHub からの移行は、Forgejo の「新規移行」が Issue・PR ごとリポジトリを取り込む。
git.example.com { reverse_proxy localhost:3000 }
一度に切り替えなくてよい。GitHub をミラーにしたまま並行で動かし、慣れたら本番を Forgejo に寄せる(2-12)。
コードは、事業の中身そのものだ。その置き場の主導権は、他社ではなく自分が持つ。
確かめ方
この章は、次の五つができていれば済みだ。
- ブラウザで
git.example.comを開き、作った管理者でログインできる - 手元から
git pushしたコードが、Forgejo の画面にそのまま出る - push の後、Forgejo の Actions の画面でワークフローが走り、
pytestの結果が見える - Zed でリポジトリを開き、AI を呼んでコードを書かせ、そのまま push できる
- GitHub から「新規移行」で取り込んだリポジトリに、Issue と PR が付いてきている
systemctl status forgejo forgejo-runner # 二つとも systemd で動いているか
git push -u origin main # 画面に出るか見る
curl -sI https://git.example.com # Caddy 越しに応答するか見る
人が持つ物
人が渡す値
- Forgejo のドメイン名(例
git.example.com) - Forgejo 用の PostgreSQL の利用者名とパスワード
- 最初の管理者の名前とメールアドレス
- 手元の PC の ssh 公開鍵(push に使う。Forgejo の画面で登録する)
- GitHub から取り込むときのアクセストークン
AI が「やる前に言う」操作
- GitHub のリポジトリを消す、または公開範囲を変える
- DNS のレコードを
git.example.comに向ける - 本番へデプロイするワークフローを有効にする、または走らせる
/var/lib/forgejoのデータを消す、または作り直す
確かめた版と日付
- Forgejo 16.0.5(2026-09-17、Codeberg の単体バイナリ)、forgejo-runner
actions/checkout@v4── ワークフローで使う取り込みアクション- Zed、Caddy、PostgreSQL(2-03 の Debian 13 のパッケージ)── 版は指定していない
- 手順を書いたのは 2026-07-06、見直したのは 2026-10-05
- 版が上がっていたら、AI に公式の手順を確かめさせてから進める
まとめ
ビルダーの仕事場を、自分の側に。
- Forgejo ── リポジトリ・Issue・PR・レビューを一つに(2-03 の PostgreSQL に乗る)。単体バイナリを systemd で
- Forgejo Actions ── GitHub Actions 互換の CI/CD。ランナーは専用の利用者で、機械の上で直接走らせる
- Zed + AI ── 軽量エディタの中から AI を呼び、書かせ・評価し・push する
- 門番の内側 ── リバースプロキシで囲い、GitHub から段階移行
書いたコードは、設定だけだ。汎用は、すでに OSS として在る。次章では、文書の原稿を文字で持ち、Word も Claude Docs も通過させる道具にする。