AIエージェントに開発を任せる仕組みを「どこまで自前で持つか」で悩んでいる人向けの記録です。結論から言うと、私はローカルForgejoでの完全自前運用を一度組み上げ、そして捨てました。捨てて初めて分かった「管理を手放す価値」と、その先で出会ったスマホ運用のパラダイムシフトまでを、時系列で残します。
これは「やってみてうまくいった成功談」ではなく、「作り込んで撤退した正直な記録」です。3日かけて組んだものを3日で捨てたので、その判断に至るまでの過程と、そこで得た教訓を共有します。
きっかけは、以前作った agent runner だった
そもそもの出発点は、以前作った GitHub IssueからCodexを動かすagent runner でした。
GitHub Issueをキューにして、VPS上のrunnerがそれを定期的に拾い、Codex CLIを非対話で実行してPRまで作る。ターミナルに張り付かなくても、スマホからIssueを投げれば作業が進む。ここまでは確かに動いていて、私の開発体験は一度大きく変わりました。
ただ、AIエージェントを使い込むほど、人は欲が出てきます。「この仕組み、もっと自分の手元に寄せられないか」と。そこから今回の迷走が始まりました。
GitHubのIssueが使いづらくて、自分で作り始めた
そもそもの発端は、もっと素朴な不満でした。GitHubのIssueが、どうにも使いづらかったのです。
動作がなんとなくもっさりするし、リポジトリが増えてくると「これはどのリポジトリのIssueだったか」が分かりにくい。実際、別のリポジトリにIssueを書き間違える、というミスが何度も起きていました。
それで、こう思ったのです。「Issueくらいなら、自分で作ってローカルサーバーに立てておけばいいのでは」と。さっそく、AIエージェントの力を借りて、Issue管理の仕組みをさくっと自作しました。
ところが、作っているうちにスコープがどんどん膨らんでいきます。Issueがあるなら、プルリクエストも要るのではないか。PRがあるなら、差分を確認する仕組みも要るのではないか。AIエージェントがIssueを読み込むところまではいいとして、その後のPRやレビューのやり取りは、いったいどう作ればいいのか。
考えているうちに、はたと気づきました。これは結局、GitHubそのものを作ろうとしているのではないか、と。
であれば、答えは単純です。同じものがOSSにあるなら、それを使えばいい。そこでOSSの Forgejo を採用しました。ForgejoはGiteaから派生した、セルフホスト前提のGitフォージです。GitHubに近いIssue・PR・Webhookの機能が一通りそろっています。
根っこには、外部サービスへの依存を切りたい、全部を手元に置きたい、という気持ちもありました。実行時間の枠や無料プランの制約、コードやIssueを外部に預けることへのうっすらとした抵抗。そして正直に言えば、「この仕組みを一から自分で組んでみたい」という技術的な好奇心も、大きな燃料だったと思います。
そこでローカルにサーバーを立て、Forgejoをインストールしました。ただ、立てて動かすまでにも、地味な手間が少しずつ積み重なります。APIトークンや権限まわりの設定、サーバーとして動かし続けるための構築と運用。意外なことにWebhook連携そのものは素直に動いたのですが、「GitHubなら最初から用意されていたもの」を一つずつ自分で揃え直している感覚は、この時点ですでにありました。
「これでGit基盤も含めて、開発のループが全部自分の管理下に入る」——そう思っていました。
ClaudeとCodexで「3往復の自動レビュー」を組んだ
Forgejoを土台に、私は前回のrunnerをさらに進化させた「エージェントランナーv2」を組みました。
流れはこうです。
- ForgejoにIssueを書く
- そのタイミングでWebhookが発火し、処理が起動する
- Claude CodeがIssueを読み取る
- そのままClaude Codeが実装まで進める
- その実装を内部でCodexにレビューさせる
- このレビューのやり取りを最大3回まで自動で往復させる
- 完成したらIssue/PRにコメントで結果を返す
ポイントは、AI同士が互いをレビューし合う閉ループを自動で回す構造にしたことです。Claudeが実装し、Codexがレビューし、また直す。前回の記事で AIエージェント自身がテストを実行して直す閉ループ の話を書きましたが、それを「実装者AI」と「レビュアーAI」の二者間にまで広げた形になります。
Issue → PR → レビュー往復 → コメントに記録を残しつつ手元に戻る。図にすると一本の気持ちのいいパイプラインで、組んでいる間はかなり楽しかったです。
つまずいたのは「どのサーバーに置くか」だった
ところが、組み上げた直後から現実的な問題が頭をもたげてきました。「これ、結局どのサーバーで動かし続けるのか」という問題です。
最初はローカルのマシンに置きました。しかしローカルに置いたままでは、外出先など別のネットワークからは叩けません。そこで VPN でつなぐことを考え、Tailscale を試しました。手元のマシン同士を VPN 網で直接つないでしまえば、外からでも安全にアクセスできます。
ただ、普段使いの Mac のバックグラウンドで VPN クライアントが常駐し続けるのが、どうも好きになれませんでした。ならばと、VPS 側に Tailscale を入れて、運用一式を VPN ネットワークの中に閉じ込めてしまえば安全ではないか——と考えて構成してみました。
しかし実際にやってみると、これがなかなか雑で、手間のかかる構成でした。管理する箇所もトラブルの種も、明らかに増えていきそうです。結局、この VPN 構成は廃止しました。
では素直に VPS に置くか。しかし VPS に自前の Git 基盤一式を置くとなると、今度はその VPS の面倒を見続ける不安が出てきます。メモリは足りるのか。落ちたら誰が気づくのか。バックアップは。アップデートは。
GitHubなら当たり前に任せられていたことを、全部自分で抱え込むことになる。組み上げた高揚感が、じわじわと管理の重さに上書きされていきました。
結局、GitHubのシンプルな構成に戻した
結局、私はGitHubに戻りました。
3日かけて一気に組んだ実装が、水の泡になったように感じました。Forgejoも、v2のレビューループも、自分の手では使い続けないと決めた瞬間です。
正直、その場では「無駄なことをした」という残念さが先に立ちました。——でも、振り返ってみると、捨てたからこそ見えたものが二つありました。ここからが、この記事で本当に書きたかったことです。
気づき①：自前で全部抱えると「精神的コスト」が積み上がる
一つ目は、自前管理の精神的コストです。
サーバーが落ちていないか。メモリは大丈夫か。Webhookは届いているか。Git基盤そのものが壊れたらどうするか。——これらは一つ一つは小さな不安ですが、自前で全部抱えると、常に頭の片隅で動き続けるバックグラウンドプロセスのように積み重なっていきます。
シンプルなGitHubのエージェントランナー構成に戻したとき、その積み重なっていた不安が一気に消えて、驚くほど気持ちが解放されました。「ああ、自分はこんなにエージェント基盤の心配をしながらコードを書いていたのか」と、戻って初めて気づいたのです。
ここで学んだのは、技術選定は性能だけでは決まらない、ということです。性能ではなく「持ち続けられるか」で決まる。どれだけ理想的なループを組めても、それを管理し続ける精神的コストに自分が耐えられないなら、その選択は長続きしません。
気づき②：AIエージェントはForgejoに不慣れだった
二つ目は、もっと意外で、もっと本質的な壁でした。AIエージェントが、Forgejoに不慣れだったのです。
Claude CLIに「Issueを書いて」「これを直してPRにして」と頼むとき、相手がGitHubであればghコマンドで一発で通ります。AIはGitHubのCLIやAPIに習熟していて、迷いがありません。
ところがForgejoのAPIを相手にすると、これが途端にうまくいかなくなりました。同じ依頼をしても、ghのときとは別物のようにトラブルになりやすい。AIがForgejoの作法に習熟していないのか、つまずく場面が目立ちました。
念のため補足すると、ForgejoはGiteaから派生した、広く使われているOSSです。だからAIがまったく知らないわけではありません。ただ、GitHubのghのように手に馴染んだ専用CLIや、厚い実例の蓄積がない分、どうしても扱いがぎこちなくなる——という温度感です。
精度を上げる方法は想像がつきます。おそらくForgejo用のMCPサーバーを自前で立てることです。AIにForgejoの操作インターフェースをきちんと与えてやれば、習熟の差は埋まるはずです。
でも——そこまでやるか、と思いました。Git基盤を自前にし、レビューループを自前にし、その上さらにAIにForgejoを教えるためのMCPサーバーまで自前で抱える。これが、撤退の決定打でした。GitHubに任せるのが、精神的にどれだけ楽か。
ここから一つの一般論が見えてきます。AI時代の技術選定には「AIフレンドリーか」——つまりAIがそのツールに習熟しているか——という新しい軸が加わる、ということです。
これまで技術選定の軸といえば、性能、コスト、エコシステムの大きさ、学習コストあたりでした。そこに「AIがそのツールをどれだけ使いこなせるか」が乗ってきます。GitHubがメジャーであること自体が、AIにとっての学習データの厚みになり、無形の資産になっている。マイナーで高機能なツールより、AIが習熟しているメジャーなツールのほうが、結果的に開発が速い。そういう逆転が、AIに開発を任せる時代には起こります。
機能比較表だけを見てForgejoを選んだ私は、この「AIフレンドリー」という軸を見落としていました。
たどり着いたのは、スマホから自宅Macを動かす運用だった
自前運用から撤退して、私が最終的に落ち着いた運用は、想像していたのとは全く別の方向にありました。スマホです。
具体的には、Claude Codeの Remote Control という機能です。これは、自宅のMacで起動しておいたClaude Codeのセッションに、外出先のスマホアプリやブラウザから接続して操作できる仕組みです（公式ドキュメント ）。執筆時点ではリサーチプレビューで、Pro/Maxなどのプランで利用でき、Claude Code v2.1.51以降が必要です。
重要なのは、処理はクラウドではなく、あくまで自宅のMacの上で動くという点です。公式ドキュメントも “Claude keeps running locally the entire time, so nothing moves to the cloud”（セッションは終始ローカルで動き続け、何もクラウドには移らない）と明記しています。スマホやウェブの画面は、そのローカルセッションを覗く窓にすぎません。ローカルのファイルシステム、MCPサーバー、ツール、プロジェクト設定が、そのまま外出先から使えます。
補足：紛らわしいことに、Anthropicには「Claude Code on the web」という別機能もあります。こちらはAnthropic管理のクラウド上でタスクを実行するもので、Remote Controlとは別物です。私が使っているのは、自宅Macで動かすRemote Controlのほうです。
やってみると、最初は「一見、普通のチャットと同じだな」と思いました。こちらが「〇〇して」と指示する感覚は、ふだんのチャットと変わりません。
でも、返ってくるものが違います。返ってくるのは、ビルド結果であり、PRなのです。
差の正体は三つあります。
- プロジェクトの全文脈をそのまま認識している。 Claudeが見ているのは自宅Macの特定ディレクトリそのものなので、コードを貼り付ける手間がゼロです。そのプロジェクトの全知識を持った状態で、その場で精度の高い修正をしてくれる。これは CLI型AIエージェントの強み として前に書いた「ローカルプロジェクトを理解してくれる」ことが、スマホ越しにそのまま効くということです。
- ビルドやテストを実行できる。 ローカルのMacで動いているので、Xcodeのテストのような、macOSでしか動かない処理も走らせられます。クラウドのサンドボックスでは難しい部分です。
- GitHubへのpush/pull、ブランチ作成ができる。 外出先から本番の開発フローがそのまま回ります。
つまりこれは、チャットの皮をかぶった、フル装備のリモート開発環境なのです。一見ただのチャットなのに、中身はまったく違う。
かつての私は、Codexに張り付くために4窓のターミナルを左右に分割し、8ペインを監視していました 。手元のMacに縛られ、どの窓が何をしているかをひたすら追い続ける日々です。あのころと比べると、ポケットの中から自宅Macを動かす今は、まるで対極にあります。
スマホの手元の、ほんの小さな指の動き。それが自宅のMacというフル開発環境を動かし、アプリを大きく前に進めていく。小さな指の動きで、大きなテコを振る——アルキメデスのテコのようなレバレッジが、ポケットの中で起きています。
そして、私がいちばん楽になったのは、実はもっと手前の部分でした。アイデアから実装の着手までが、ひとつながりになったことです。
これまでは、何か思いつくたびに、まずスマホのメモ帳に書き留めていました。それを後でIssueの形に整え、起票し、そこからようやく実装に入る。思いつきから着手まで、三段階くらいの手間が挟まっていたのです。
それが今は、思いついたその場で、スマホのClaude Codeのチャットに「こんなことを考えているんだけど、どうだろう」と相談できます。しかも、そのまま起票も実装もお願いできる。思考から実装までがワンステップでつながり、アイデアが冷めないうちに次へ次へと進められる。これが、私にとっての一番の変化でした。
もちろん、万能ではありません。スマホの小さな画面では、長い出力やコードの差分を最後まで追うのは骨が折れますし、込み入った操作はPCのほうが速い。ただ、たとえば承認のたびに確認を求められるような手間は、自動承認の設定にすれば消えてしまう程度のもの。本質的に残る弱点は、画面の小ささくらいだと感じています。
なお、デプロイのような「外部へ実際に出す」操作までこの運用で完結できるかは、ローカル側の構成次第で、ここでは言い切れません。少なくとも実装・ビルド・テスト・PRまでは、手のひらの上で回ります。
まとめ：自作は時代遅れか、それとも目利きの修行か
最後に、この3日間を振り返って感じた、相反する二つの本音を置いておきます。
一つは、諦観です。今回あれこれ悩みました（実装はほとんどAIに任せたとはいえ）。楽しくもあり、悩ましくもあった日々。その結果が全然通用しなかった残念さもあります。このAI時代、自分が思いつくようなツールや仕組みは、もう世に出ているか、これからどんどん出てきます。使いこなせていない人が多いだけで、車輪はとっくに発明されている。そう考えると、自分でいちいちツールを作るのは、もう時代遅れも甚だしいのかもしれない、と。
もう一つは、その反対の見方です。作って、捨てたからこそ、「何を手放すべきか」の目利きが育ったのではないか。Forgejoを実際に組んでみなければ、自前管理の精神的コストも、AIフレンドリーという軸の重みも、ここまで肌で分かることはなかったはずです。作る対象が、ツールそのものから「運用設計」へ移っただけ、とも言える。
どちらも、本当だと思います。
ひとつ、誤解のないように補足しておきます。撤退したのは今回のForgejoでの自前システムであって、AIエージェントの運用そのものをやめたわけではありません。以前作ったagent runnerは、今もVPS上で動き続けています。定期的な処理を任せるぶんには、これがやはり便利なのです。
Forgejoについても、「もう二度と選ばない」と決めたわけではありません。今回はたまたま、自前で組もうとして行き詰まっただけ。また何か面白い発想が浮かべば、性懲りもなく手を出すかもしれません。
自作は時代遅れか。それとも、目利きを育てる修行か。あなたは、どう思いますか。