iPadだけでGitOps環境を構築できるか
——Workers Builds 方式で、ブラウザ操作だけ通す

1結論

GitOps構築ガイドは「ローカル環境が無くても進められる」と書いています。本記事はその一段先——「iPadという具体的な端末で、初期構築まで通るのか」を、工程ごとに分解して確かめたものです。

2全ステップの内訳

3唯一の関門：GitHub Appの認可

• 頻度は「アカウント／組織ごとに1回」。2つめ以降のサイトを作るときは再認可は要りません。
• 認可の範囲は絞れます。承認画面で Only select repositories を選べば、対象リポジトリだけに限定できます。全リポジトリへのアクセスを渡す必要はありません。
• 認可さえ済めば、その後は自動化できます。リポジトリ接続とビルド設定は Workers Builds の API で作れます（PUT /accounts/{id}/builds/repos/connections と POST /accounts/{id}/builds/triggers）。ただし user-scoped の API トークン（Workers CI Write）が必要で、account-scoped トークンは Invalid token で拒否されます。

4エージェントに任せられる範囲

iPad構築が成立する理由は、作業量の大半を占める部分が、そもそも人の手を離れていることにあります。

5独自ドメインがダッシュボードから消える

地味ですが、iPadでの手作業を1つ減らせる箇所です。

{
  "name": "your-app",
  "compatibility_date": "YYYY-MM-DD",
  "assets": { "directory": "./dist" },
  "routes": [
    { "pattern": "example.com", "custom_domain": true }
  ]
}

6なぜ Workers Builds を選ぶか

Cloudflare へのデプロイには、もう1つ GitHub Actions から API トークンでデプロイする方式があります。こちらなら GitHub App の認可すら要りません。それでも本記事が Workers Builds を採るのは、次の交換だからです。

7実際に叩く順番

8引っかかるとすればここ

「作れる」と書きましたが、本記事はiPad実機で構築を通していません。工程を分解して「ターミナルを要求する作業が無い」ことを確かめたに留まります。踏んでみないと分からない箇所を、正直に挙げます。

• 手順5の承認フローが iPadOS の Safari で完走するか。Cloudflareのダッシュボードから GitHub の承認画面へ遷移し、アプリのインストールを経て戻ってくる流れです。構造上はブラウザで完結するはずですが、リダイレクトやポップアップの扱いで詰まる可能性は残ります。詰まったら「デスクトップ用サイトを表示」を試すのが定石です。
• Claude Code のアプリで、空のリポジトリにセッションを開始できるか。アプリの仕様に依存します。できない場合は、人がSafariで最初のファイル（README等）を1つ置いてからセッションを開けば回避できます。
• レジストラのサイトが iPad で扱えるか。ネームサーバー変更の画面はサイトによって作りが違います。ここは各レジストラ次第です。

S情報ソース

H更新履歴