通し番号のついた画像が鎖(サイクル)に沿って並び替わる図

画像を「リネームだけ」で並び替える。玉突き方式とスワップ方式、手数はどれだけ違うか

通し番号のついた画像の束を、別の順番に並べ替えたい場面があります。 1.png から 7.png まで並んでいて、これを「5番を先頭へ持ってきて、残りを1つずつ後ろへずらす」といった具合に組み替えたい。素直にやるなら、新しい順番でファイルを全部コピーし直せば終わりです。 ただ、枚数が多かったり1枚が重かったりすると、コピーは時間も容量も食います。中身は1バイトも変わらないのに、です。動かしたいのは「順番」だけ。だったら、ファイル名(通し番号)を付け替えるリネームだけで並べ替えたい。 この記事では、そのリネームの順番をどう決めるかを考えます。素朴なスワップ方式と、少し賢い玉突き方式(循環置換)を比べて、同じ並び替えでも手数がどれだけ変わるかを、最後にブラウザだけで動くビジュアライザで実際に触って確かめます。 まず、リネームには落とし穴がある 「1番には今の5番の画像を、2番には今の1番の画像を…」と指示があったとして、思いつくまま 5番→1番 のように上書きリネームしていくと、すぐに事故が起きます。 上書きされた先の画像は、その瞬間に消えます。並び替えのつもりが、画像の破壊になってしまう。 これを避けるには、動かす1枚をいったん別の場所(temp)に逃がしてから動かします。逃がした跡地には「穴」が空きます。実は、この穴をどう埋めていくかが戦略の分かれ道です。 ここからは説明をシンプルにするため、7枚の画像にそれぞれ A〜G の中身が入っているとして話を進めます。スロット 1 には A、2 には B…という初期状態です。 並び替えの指示は、"並び先スロット": "元スロット" という対応表で表します。 { // 5番(E)を先頭へ。1〜5を1つずつ後ろへずらし、6番(F)と7番(G)は入れ替え "1": "5", // 1番には 元5(E) を持ってくる "2": "1", "3": "2", "4": "3", "5": "4", "6": "7", "7": "6" } 値(右側)が 1〜7 を1回ずつ全部使っていれば、画像が消えも増えもしない正しい並び替えです。重複や抜けがあれば、それは「同じ画像を2か所へ」「どこにも置かれず消える画像がある」というバグなので、実行前に弾きます。 素朴なやり方:スワップ方式 いちばん分かりやすいのは、1番から順番に定位置を埋めていくやり方です。 スロット 1 を見て、「ここに来るべき画像は今どこにあるか」を調べ、そこと交換する。次に 2 を見て…と、番号順に確定させていきます。「ここに来るべき画像が今どこか」は、画像の現在地を覚えておく loc という表で追跡します。 問題は、1回の交換にリネームが3回かかることです。temp に逃がして、欲しい画像を運んで、temp の中身を空いた場所へ戻す。これで3手です。 番号順に処理するので追いやすい反面、交換のたびに必ず temp への往復が発生します。交換が増えるほど、この「3手」がそのまま積み上がっていきます。 少し賢いやり方:玉突き方式(循環置換) 玉突き方式は、並び替えを最初に鎖(サイクル)として捉え直します。 さっきの指示を「誰が誰の場所を欲しがっているか」で辿ると、1→5→4→3→2 と一本の鎖になります。「1番が欲しいのは5番の画像、5番が欲しいのは4番の画像、4番が欲しいのは3番…」と繋がって、最後は2番が1番の画像を欲しがって輪が閉じます。6 と 7 はお互いを欲しがる、長さ2の短い鎖です。 鎖さえ作れれば、あとは穴を歩かせるだけです。 鎖の先頭の1枚(A)を temp へ逃がす。そこに穴が空く。 今ある穴に「そこへ入るべき1枚」を運ぶ。運んだ跡地が次の穴になる。 これを繰り返すと、穴が鎖の上を一歩ずつ歩いていく。最後に temp の1枚を戻して、その鎖は完了。 ポイントは、穴に入った画像はそのまま最終位置だということです。一度置いたら二度と動かしません。スワップ方式のように毎回 temp へ往復しないので、temp を使うのは1つの鎖につき1回だけで済みます。 ...

公開: 2026年6月30日 · 更新: 2026年7月3日 · Toshihiko Arai
どのAndroidスマホメーカーが人気?日本と世界のシェアを比較【2026年版】

どのAndroidスマホメーカーが人気?日本と世界のシェアを比較【2026年版】

はじめに Note この記事は、/mobile-vendor-market-share/ の更新版です。 いま現在の日本・世界のスマホメーカー別シェアを知りたい方は、この 2026 年版を読めば大丈夫です。 一方で、2022 年当時のメーカー構成や当時の見え方をそのまま確認したい場合は、旧版記事も参考になります。 こんな疑問にお答えします。 2026年の日本で、いちばん使われている Android メーカーはどこか 2022年版から見て、どのメーカーが伸びて、どのメーカーが消えたのか 世界全体では、Samsung と中国メーカーのバランスはどう変わったのか この記事では、StatCounter Global Stats のモバイルメーカー(Device Vendor)データをもとに、日本と世界のスマホメーカー別シェアを比較します。 2026年6月に確認した時点で、StatCounter 上で取得できる最新月は 2026年5月 でした。 なお、2022 年版からの変化が分かるように、前回記事と比較しながら読める構成にしています。 どのAndroidスマホメーカーが人気?日本と世界でシェア率を比較調査(2022年版) 3秒でわかる要点 日本のいちばん大きい変化 ...

公開: 2026年6月16日 · Toshihiko Arai
自前のForgejoサーバーを捨て、GitHubとClaude Codeのスマホ運用へ移行する流れを表した図

自前Gitサーバー(Forgejo)でAIエージェント基盤を作って、3日で捨てた話

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 構成は廃止しました。 ...

公開: 2026年6月1日 · Toshihiko Arai
ノートPCからサーバーへ転送中の不完全なファイルがrenameで完成ファイルになる様子

scpアップロード中のファイルはサーバーに存在する — 監視トリガーが未完成ファイルを処理してしまう問題とsupによる対策

Cyberduck や scp、sftp で Linux サーバーへファイルをアップロードするとき、転送が終わるまで対象ディレクトリには何も見えないと思っていた。 でも実際には、アップロード開始直後から転送先にファイルが作られ、そこへ少しずつデータが書き込まれていくことがある。大きなファイルを送ると、サーバー側で ls -lh したときにサイズが増えていく様子が見える。 これ自体は普通の挙動だが、知らないと少し危ない。 たとえば、アップロード先を別のバッチ処理やファイル監視デーモンが見ている場合、まだ途中のファイルを「完成したファイル」として読み込んでしまう可能性がある。jar、画像、CSV、バックアップファイルなど、読み込み側がファイル名だけで判断していると起きやすい。 WinSCP(Windows 向けの SFTP/SCP クライアント)はデフォルトでこの問題を回避している。転送中は内部で一時ファイル名を使い、完了後に正式名へリネームする仕組みが組み込まれているためだ。一方、macOS の Cyberduck は有料課金していてもこの挙動にはなっておらず、普通にアップロードすると転送中から正式名でファイルが見える。 アップロード中のファイルは見える scp や sftp の put は、基本的には転送先のファイルを開いて、そこへデータを書いていく操作だ。 そのため、転送中は次の状態になりうる。 転送完了前のファイルが、不完全なサイズで存在する 転送に失敗すると、中途半端なファイルとして残ることがある 監視処理やバッチ処理が、そのファイルを先に読んでしまうことがある 確認してみる 挙動は、大きめのダミーファイルを送るとすぐ確認できる。 まず手元の Mac などで、500MB のファイルを作る。 dd if=/dev/urandom of=testfile.bin bs=1M count=500 サーバー側では、転送先ディレクトリを監視しておく。 watch -n 0.5 'ls -lh /path/to/target/' 別ターミナルから scp でアップロードする。 scp testfile.bin user@hostname:/path/to/target/ サーバー側の watch で testfile.bin が現れ、サイズが少しずつ増えていけば、転送中のファイルが見えている。 確認が終わったら、ダミーファイルを削除する。 # 手元 rm testfile.bin # サーバー側 rm /path/to/target/testfile.bin supコマンドで安全に転送する 対策の考え方はシンプルで、最初から正式名で置かないことだ。一時ファイル名でアップロードし、完了後にアトミックな mv で正式名に切り替える。 ...

公開: 2026年5月22日 · Toshihiko Arai
CLAUDE.md・Issue・Skill の役割をカード形式で比較した図

Claude Code の Skill・Issue・CLAUDE.md の使い分けを整理した

Claude Code を使い始めてしばらく経ち、Issue ベースで作業を指示するフローは固まってきた。そこで気になっていた Skill という仕組みを調べた。「繰り返し依頼に便利」とは聞いていたが、実際に何をするもので、Issue や CLAUDE.md と何が違うのかを整理しておきたかった。 Skill とは何か Skill は .claude/skills/<skill-name>/SKILL.md の形で置く Markdown ベースの追加手順だ。ファイルには YAML front matter の description と、実行時の指示を書く。 呼び出され方は2通りある。 Claude Code が description を見て関連すると判断したとき、自動で読み込む ユーザーが /skill-name の形で明示的に呼び出す Skill ディレクトリにはテンプレートや参考資料、スクリプトも同梱できる。プロジェクト単位・個人環境単位のどちらにも置ける。 公式ドキュメントでは、同じ指示やチェックリストを何度もチャットに貼っている場合や、CLAUDE.md の一部が事実ではなく手順書になってきた場合に Skill 化するとされている。本文は使われるときだけ読み込まれるため、長い参照資料を常時コンテキストに入れずに済む点がメリットだ。 Commands との関係 以前は .claude/commands/deploy.md という単一ファイル方式のカスタムコマンドがあった。現在は Skills に統合されており、どちらも /deploy のようなスラッシュコマンドとして動く。 方式 パス 特徴 Commands(旧) .claude/commands/deploy.md 単一ファイル、シンプル Skills(現在推奨) .claude/skills/deploy/SKILL.md ディレクトリ構造、自動呼び出し対応 既存の .claude/commands/ は引き続き動作するが、新しく作るなら .claude/skills/ が推奨だ。 Skill の書き方 SKILL.md の構造 SKILL.md は2つのパートで構成される。 --- name: gen-test description: テストを生成する disable-model-invocation: true --- 以下のファイルのテストを生成する: $ARGUMENTS 1. ソースファイルを読む 2. テスト対象の関数を特定する 3. プロジェクトの規約に沿ったテストを書く --- で囲まれた上部が frontmatter で、Claude に「この Skill をいつ・どう使うか」を伝える設定欄だ。YAML 形式で書く。--- 以降が実際の指示内容になる。 ...

公開: 2026年5月20日 · Toshihiko Arai
macOSの画面右上にClaude Codeの作業完了通知が表示されているイメージ

Claude Codeの作業完了・許可待ちをOS通知で受け取る設定方法

Claude Code に作業を任せて別のことをしていると、いつの間にか完了していたり、許可プロンプトで止まっていたりすることがある。 「通知が来れば気づけるのに」と思って設定を試してみた。結果としては動くのだが、期待していたほどスムーズではなかった。以下は試行錯誤の記録として参考にしてほしい。 組み込み設定とその限界 Claude Code には preferredNotifChannel という組み込みの通知設定がある。 { "preferredNotifChannel": "auto", "inputNeededNotifEnabled": true } ただしこれは iTerm2 の通知機能を経由するため、セッション名や生のエスケープシーケンスがそのまま通知に表示されることがある。複数プロジェクトを同時に動かしていると通知が混在して読みにくくなる。 hooks で osascript を使う 組み込み設定に限界を感じたので、~/.claude/settings.json の hooks を使って macOS ネイティブの通知を直接出す方法も試してみた。 { "hooks": { "Stop": [{ "hooks": [{ "type": "command", "command": "osascript -e \"display notification \\\"作業が完了しました\\\" with title \\\"Claude Code [$(basename $PWD)]\\\" sound name \\\"Glass\\\"\"" }] }], "Notification": [{ "hooks": [{ "type": "command", "command": "osascript -e \"display notification \\\"入力が必要です\\\" with title \\\"Claude Code [$(basename $PWD)]\\\" sound name \\\"Ping\\\"\"" }] }] } } Stop は Claude が作業を終えたとき、Notification は許可プロンプトや質問で入力待ちになったときに発火する。 ...

公開: 2026年5月19日 · Toshihiko Arai
CLI AIとMakefileからiOSビルド、実機デプロイ、テスト、スクリーンショット生成へつながる図

AI時代にmakeコマンドが便利すぎる。CLI AIとiOS開発をつなぐ操作盤として使う

AIエージェントを使うようになってから、古くからある make コマンドの便利さを改めて感じている。 make は C 言語のビルドで使う古い道具、という印象が強かった。自分も昔から知っていたが、仕組みをきちんと理解して使っていたわけではない。 ところが、Claude Code や Codex のような CLI 型 AI エージェントを相棒に開発すると、make はかなり相性がいい。 理由は単純で、プロジェクトでよく使う操作を make test、make build-release、make device-debug のような短いコマンドにまとめられるからだ。人間と AI エージェントが同じコマンドを見て、同じように実行できる。 特に iOS アプリ開発では効果が大きい。make device-debug でビルド、実機インストール、起動までできるようにしておくと、Xcode を開かずにターミナルだけで開発を進められる場面が増える。Xcode は他の IDE と操作感がかなり違い、毎回開くのが負担に感じることもある。Xcode への依存を半分でも減らせると思うと、iOS アプリ開発の心理的なハードルも下がる。左半分のターミナルで Claude Code などの CLI AI と対話し、右半分や別タブで make を叩く。あるいは AI エージェント自身に make test を実行してもらう。 GitHub Issue とターミナルがあれば、基本的な開発作業がかなり済んでしまう。 makeは何をする道具なのか make は、Makefile に書かれたルールを読んで、必要なコマンドを実行する道具である。 GNU Make のマニュアル では、make は大きなプログラムのどの部分を再コンパイルする必要があるかを自動判定し、そのためのコマンドを実行するユーティリティとして説明されている。 もともとの発想は、ファイル同士の依存関係を見て、変更があった部分だけを更新することだ。 たとえば C の世界なら、main.c から main.o を作り、複数の .o をリンクして実行ファイルを作る。ヘッダーファイルが変わったら、それに依存するソースを再コンパイルする。こういう関係を毎回人間が覚えて実行するのは面倒だし、間違いやすい。 ...

公開: 2026年5月17日 · Toshihiko Arai
Codex、Claude、iOSアプリ開発の3つが淡く重なり合う抽象的なアイキャッチ画像

【新規記事】AIエージェントに没頭した20日間。Codex、Claude、iOSアプリ開発まで

ここ最近、AIエージェントをかなり集中的に触っていた。 Codex の $100 プランを契約し、20日ほどがっつり使ってみた。 結論から言うと、来月からは $20 プランへ戻す予定である。 理由は単純で、$100 プランの容量を使いこなすほど、自分の指示が追いつかなかったからだ。 Codex が物足りなかったわけではない。 むしろ十分すぎた。 5日のコンテキスト上限を使いこなすほどの指示を、自分が出せなかった。 つまり、自分の処理能力が先に限界へ来た。 CLI型AIエージェントのすごさは「フィードバックループ」にある Codex に限らず、この手の CLI 型AIエージェントを導入してすごいと思ったのは、ローカルプロジェクトを理解してくれることだった。 これまで Web ブラウザ版の ChatGPT を使ってコード修正を相談する場合、修正したいファイルを毎回アップロードしたり、コードを貼り付けたりする必要があった。 しかし CLI 型AIエージェントでは、ローカルのプロジェクトをそのまま見てもらえる。 そのため、プロジェクト全体をまるで把握しているかのように、かなり的を射たコーディングをしてくれる。 ただ、改めて考えると、すごさはそれだけではない。 もっと大きいのは、AIエージェント自身がテストコードを実行できることだと思う。 AIがコードを改修する。 そのコードに対してテストを実行する。 テストが失敗したら、エラー内容を読んで、もう一度コードを直す。 そしてまたテストを実行する。 これは、単なるコード生成ではない。 入力に対して出力を返すだけではなく、その出力結果を観測し、フィードバックして、次の修正に反映する流れである。 制御工学っぽく言えば、開ループではなく、閉ループになった感じがある。 これまでのAIチャットは、どちらかといえば「コードを提案して終わり」だった。 しかし CLI 型AIエージェントでは、生成したコードを自分で実行し、結果を見て、自分で修正する。 このフィードバックループが入ったことで、AIによるコーディングはかなり実用的になった。 人間に例えれば当たり前の話だが、たったこれだけで、精度はぐんと上がった感がある。 (このことは、今後 AI をうまく使いこなすための大きなヒントになるかもしれない) もちろん、すべてが完璧になるわけではない。 テストが通っても、仕様として正しいとは限らない。 こちらの気持ちや意図まで理解するには程遠い場面も多々あり、最後は人間による判断が必要になる。 それでも、テスト結果という強いフィードバック信号をAI自身が扱えるようになったことは、かなり大きな変化だと思う。 Claude も契約してみた 一方で、Claude の $20 プランも契約してみた。 CLI AI エージェントは Claude が先駆者だと思うが、Codex を先に体験してしまったので、Claude を使うことに今更感があり少し足踏みしていた。 しかし、実際に使ってみると Codex との違いを比較できて、かなり面白かった。 ただし、契約時にはクレジットカード決済で少し苦労した。 なかなか決済が通らず、最終的には VISA の楽天カードについてサポートへ連絡し、ストップされていた件を説明して解除してもらうことで、ようやく決済できた。 ...

公開: 2026年5月9日 · Toshihiko Arai
多窓ターミナルの旧世界からGitHub IssueキューとVPS上のagent runnerへ世界線が切り替わるイメージ

GitHub IssueからCodexを動かすagent runnerを作ったら世界線が変わった

この記事で伝えたいこと 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 は自然な選択肢だ。 ...

公開: 2026年5月5日 · Toshihiko Arai
サーバー上のcloneリポジトリでCodexが安全な作業ブランチを動かしているイメージ

さくらのサーバーでCodexをcronで動かしてブログ記事を自動リライトさせる

ブログ記事の簡単なリライト作業を、手元の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の方が向く場面もあります。ここでは「今回の運用では使わなかった」という整理です。 ...

公開: 2026年5月2日 · Toshihiko Arai