Claude Code や Codex を使い始めると、最初はローカル PC 上で作業させることが多い。スマホからリモートデスクトップで PC に接続し、ターミナルやエディタを遠隔操作してエージェントに指示する、という構成だ。動くことは動くが、遠回りだという感覚は残る。

この記事では、その遠回りを解消するための設計の考え方を整理する。特に「チャットで議論した内容をテックブログ記事として GitHub Pages に公開する」というユースケースを中心に、Issue/PR ベースのワークフローへの移行を具体的に見ていく。

今の構成と課題

RDP ベースの構成を図にするとこうなる。

スマホ → RDP → ローカルPC → ターミナル/VSCode → エージェント

問題は、スマホが「操作端末」に近い役割を担っている点だ。RDP 越しの UI は細かい操作がしにくく、接続が切れると作業が止まる。エージェントが長時間作業していても、その結果をスマホで確認するだけでひと手間かかる。

もう一つ、構造的な問題もある。エージェントへの指示が会話履歴の中に埋もれていき、「どこまでやったか」「何を頼んだか」を履歴をさかのぼらないと把握できなくなる。

設計の転換点：スマホを承認端末として使う

解決策は、スマホの役割を変えることだ。

「開発端末」から「承認・指示端末」へ。

スマホ側でやることは Issue を書くこと、PR の差分を確認すること、コメントで修正を指示すること、そして merge することだけにする。コードを書く作業、ファイルを編集する作業、コマンドを叩く作業は、エージェントが GitHub 上の指示を読んで実行する。

移行後の構成はこうなる。

スマホ → GitHub Issue / PR / コメント
              ↓
         エージェント（Claude Code / Codex）
              ↓
         branch 作成・実装・PR 作成
              ↓
         スマホでレビュー → merge → デプロイ

ローカル PC は「手で操作する場所」ではなく、重い処理やローカル環境依存の確認が必要なときだけ使う検証環境に格下げできる。RDP をゼロにする必要はない。例外対応用に残しておく程度がちょうどいい。

Issue/PR ベースの3層設計

この構成を整理すると、3つの層に分けて考えると見通しがよくなる。

指示層（スマホ）

GitHub Mobile または GitHub Web から Issue を作成し、エージェントに作業を依頼する。PR 差分の確認、コメントでの修正指示、merge もここで完結する。

エージェント層

Claude Code が Issue / PR 上のメンションから作業を読み取り、branch を切って実装・記事生成・PR 作成まで行う。Codex は PR 差分のレビューに向いており、レビューコメントを自動で付ける用途で使える。

実行・デプロイ層

GitHub Actions が CI を実行し、merge 後の GitHub Pages デプロイも担う。ローカル PC は GitHub-hosted runner で賄えない処理が出たときの例外的な確認環境として残す。

ユースケース：チャット議論からブログ記事を生成する

このワークフローが最も効果を発揮するのが、AI チャットで議論した内容を GitHub Pages のブログ記事に変換するユースケースだ。

共有リンクだけに依存しない

ChatGPT・Claude・Gemini の会話には共有リンクを発行できる機能がある。しかし共有リンクだけを頼りにエージェントに渡すのは危うい。ログイン要件、動的レンダリング、アクセス制限などで、エージェントや GitHub Actions からのアクセスが安定しないケースがある。

実用的な設計は「共有リンク + 本文貼り付けの両対応」にすることだ。Issue テンプレートに Source link と Raw transcript の両方の欄を用意し、リンクが取得できない場合のフォールバックとして会話本文を貼れるようにする。

## Source
- Chat link:
- Raw transcript / notes:

## Article Goal
What should this article help readers understand?

## Target Reader

## Command
/quick-blog

会話ログをそのまま転用しない

もう一つ重要な点がある。AI チャットの内容をそのまま記事に転用しないことだ。

会話形式の Q&A を記事に貼っても、読者にとって価値が出るとは限らない。エージェントへの指示は「会話の主要論点を抽出し、読者に価値ある構成へ再編集すること」まで含める。ユーザーの発言、AI の提案、未検証の推測は区別して扱い、断定できない情報には注意書きを入れる。

実際の流れ

スマホで AI と議論
  ↓
共有リンク、または会話本文を Issue に貼る
  ↓
Issue に /quick-blog とコメント
  ↓
エージェントが記事企画・本文作成・PR 化
  ↓
スマホで差分確認・コメントで修正
  ↓
merge → GitHub Pages 公開

GitHub Pages は GitHub Actions からデプロイできるため、merge から公開まで自動でつながる。

_drafts か PR branch に置く

エージェントが生成した記事を最初から _posts/ に入れないのも重要だ。_posts/ に入れるとビルド次第では即公開になる可能性がある。エージェントには「draft branch で PR を作り、_posts/ に追加した状態のコミットを作る」まで指示する。merge するかどうかの判断は人間が行う。

人間の承認を残すべき境界

スマホ完結を目指すあまり、人間の確認ポイントまで自動化しないことが大切だ。

以下は必ず人間の承認を挟む。

  • main へのマージ
  • secrets / token / 環境変数の変更
  • DB マイグレーション
  • デプロイ（特に本番）
  • 課金が発生する処理
  • GitHub Actions の workflow ファイル自体の変更

特に GitHub Actions 上でエージェントが動く構成では、Issue 本文・PR 本文・コメントなどの外部入力がエージェントのプロンプトに入るため、攻撃面が広い。ブログ記事生成のような比較的安全な用途でも、workflow の変更は自動化しないのが基本だ。

最小構成から始める

いきなり全部を整備しようとするとコストが高い。実用的には次の4つがあれば動き始められる。

AGENTS.md

エージェントに毎回説明しなくていいよう、リポジトリの運用方針を書いておく。「main に直接 push しない」「PR を作ってレビューを待つ」「secrets は変更しない」「外部設定が必要な場合は人間向けのチェックリストを書く」程度があれば十分だ。

Issue テンプレート（ブログ用）

Source（チャットリンク / 本文）、Article Goal、Target Reader、Output（draft か publish 可能か）を聞く最小のテンプレートを用意する。

PR テンプレート

変更内容・確認方法・リスク・人間が確認すべきポイントをチェックリスト形式で書く欄を用意する。

CI

GitHub Actions で jekyll build が通るかだけでも確認する。これがあることで、front matter 崩れやビルドエラーを merge 前に検知できる。

この4つが揃うと、「Issue 作成 → エージェント実装 → PR 確認 → コメント修正 → merge」までスマホで完結できる状態に近づく。

参考