Ubuntu

この記事で伝えたいこと Codex などの AI コーディングエージェントを使うと、コードを書く時間そのものは短くなる。一方で、実際に使い込むほど「エージェントへ指示を出す」「結果を確認する」「失敗したら再実行する」「別の作業をもう一つ投げる」といった運用に時間を取られるようになった。 気がつくと PC の前に張り付き、ターミナルを 4 窓から 8 窓くらい開き、どの作業がどこまで進んでいるのかを追い続けていた。これはこれで便利ではあるが、開発体験としてはまだ人間がかなり忙しい。 そこで、GitHub Issue をキューとして使い、VPS 上の agent runner が Codex CLI を非対話で動かす仕組みを作った。この記事ではプログラムの細部ではなく、なぜ作ったのか、GitHub Actions と何が違うのか、どんな構成で動かしているのか、そして何が変わったのかを整理する。 「agent runner」 はあくまで自作のプロダクト名であり、前回の記事 さくらのサーバーでCodexをcronで動かしてブログ記事を自動リライトさせる をさらに進化させた形である。 想定読者 この記事は、すでに AI コーディングエージェントを使っている開発者に向けて書いている。 特に次のような人を想定する。 Codex CLI や Claude Code などのエージェントを日常的に使っている ターミナルを複数開いて並行作業している GitHub Issue や PR を開発の入口として使っている CI/CD とは別に、AI エージェントへの作業依頼をうまく管理したい 導入: AI 駆動開発は便利だが、人間が忙しい AI コーディングエージェントを使うと、実装、調査、テスト修正、ドキュメント作成などをかなり任せられる。 ただし、使えば使うほど別の課題が出てくる。 ターミナルをいくつも開いて、複数のエージェント作業を見張る必要がある どの作業に何を指示したか分からなくなりやすい 失敗した作業を再投入するたびに、文脈を思い出して指示し直す必要がある PC の前にいないと、次の指示を出しにくい エージェントは作業を進めてくれる。しかし、作業を投げる入口がターミナルに閉じていると、人間は結局ターミナルの前から離れにくい。 この状態を変えたかった。 なぜ Codex GitHub Action ではないのか 最初に考える選択肢は GitHub Actions だと思う。GitHub のイベントをトリガーにして処理を走らせるなら、Actions は自然な選択肢だ。 ...

ブログ記事の簡単なリライト作業を、手元のMacではなくサーバー側でも動かすようにしてみました。 やりたいことは、サーバーにブログ用リポジトリを clone して、その中で Codex CLI に記事リライト系の作業を任せ、さらにコミット・push・PR作成までを自動化することです。 実際には gh の権限、privateリポジトリのclone、Codexのログイン、sandbox など、細かいところでつまずいたことがいくつかありました。それらを中心に、備忘録として残しておきます。 やりたかったこと まずはサーバーにSSHでログインし、GitHubリポジトリを用意します。 仮に、clone先は以下とします。 /home/appuser/repos/private-blog ここにブログのprivateリポジトリをcloneして、記事リライト用のバッチ処理から Codex CLI を呼び出します。最終的には、このバッチ処理をcronで定期実行する想定です。 当然、git / gh / codex がシェルで使えるように、サーバー側へ各コマンドをインストールしておく必要があります。 本番サーバーでやるのが怖い場合は、もう1台サーバーを用意するのも現実的です。さくらVPSなら比較的安いですし、私も本格運用するなら別サーバーを用意する予定です。 もちろん、ラズパイなどを使って自鯖で処理させるのも十分ありだと思います。 サーバー側でCodexに作業させるので、本番公開ディレクトリとは必ず分けておきます。 /home/appuser/public-site # 公開用 /home/appuser/repos/private-blog # 作業用clone また、私の場合は、リポジトリのmainブランチも直接編集させず、worktreeを使った別ブランチで作業させるようにしています。 全体の関係は、次のようなイメージです。 今のところ、PRのレビューからbuild / deploy作業までは、人間が担当するようにしています。 そのためローカルMacの出番は、最初の初期設定とPR確認が中心です。そこまで整えば、毎回SSHでサーバーに入って手作業する必要はかなり減ります。 なぜGitHub Actionsではなくサーバー上のcloneで回したか ところで、この手の自動化をChatGPTへ相談すると、かなりの確率で GitHub Actions 案が出てきます。 MicrosoftはGitHubを買収済みで、OpenAIにも大きく投資しています。 Microsoft → GitHubを買収済み Microsoft → OpenAIへ大規模投資 だからActionsが推されるのでは、と邪推したくなるくらい毎回出てきます。もちろん半分冗談です。実際には、定期実行やPR作成までGitHub側で完結できるので、CI/CDの定番案として出てくるのだと思います。以前、VPSへのデプロイでは GitHub CI/CD で VPS へ自動デプロイするまで にまとめたように、Actionsの便利さも確認しています。 それでも今回は、サーバー上のcloneで動かす方を選びました。 理由は主に3つです。 1つ目は、すでにサーバー上で日次処理を動かす前提があったことです。記事リライトはサイト運用のローカルな作業に近く、実行ログや失敗時のworktreeをサーバー上に残せる方が追いやすいと考えました。 2つ目は、秘密情報を増やしたくなかったことです。GitHub Actionsに渡すsecretを増やすより、サーバー側のenvファイルに閉じた方が、今回の小さな運用では見通しがよくなります。 3つ目は、OpenAI API key を新しく使わずに進めたかったことです。Codex CLIはChatGPTログインでも使えるため、今回の確認ではAPI keyを新規発行せず、手元で使っているアカウントのログインで試しました。もちろん、公式にはAPI key認証もあり、CIや完全自動化ではAPI keyの方が向く場面もあります。ここでは「今回の運用では使わなかった」という整理です。 ...