AI実務情報サイト(仮)

一般企業に勤めるSE向けに、AI関連の最新情報を「実務での判断」に翻訳して届ける。

/ 実装

移動中にAIが書き、スマホで承認し、家で公開する

このサイトの記事は、PCの前に座っていない時間に半分くらい進んでいる。

移動中にスマホから「この件を調べて書いておいて」と投げる。クラウド側で Claude Code が動いて、ブランチを切って PR を立てる。信号待ちで差分を見て、よければ merge する。家に着いてから最後の公開だけ自分で踏む。

大げさな仕組みは要らなかった。実際に何が要って、どこで詰まったかを書く。

3つの入口を使い分ける

Claude Code は同じリポジトリに対して3つの入口がある。どれで作業しても成果が同じ場所に集まるようにしておくのが要点だ。

入口 実行場所 向いている作業
ターミナル 手元のPC ビルド、デプロイ、git 操作
ブラウザ クラウド 出先での調査・執筆
モバイルアプリ クラウド 移動中の確認と指示、PRの承認

クラウドとモバイルは、起動のたびにリポジトリを clone した使い捨ての環境が立つ。だから CLAUDE.md のような設定ファイルがそのまま効く。成果は claude/ で始まるブランチに push され、PR 経由で本流に入る。

準備は /web-setup を一度実行するだけだった。手元の GitHub CLI の認証情報をクラウド側に同期する仕組みで、GitHub App を入れる作業とは別経路である。ひとつ注意があって、このコマンドは VS Code 拡張からは出てこない。 素のターミナルで起動する必要があった。

スマホだけで承認まで通るか

ここが一番知りたかった。通った。

クラウドセッションに立てさせた PR を、GitHub のモバイルアプリで開き、差分を確認して merge した。ターミナルもコマンドも使っていない。所要は数分である。

ただし前提が1つあった。GitHub のモバイルアプリが必要である。

最初に Claude アプリ内のブラウザからリンクを開いたら 404 が返ってきた。PR が消えたように見えて焦ったが、原因は単純で、アプリ内ブラウザが GitHub のログイン状態を共有していなかった。**非公開リポジトリは、権限のない相手には 403 ではなく 404 を返す。**存在を隠す仕様である。権限の問題ではなく、ログインの問題だった。

クラウド側は外に出られないことがある

もう一つ、これは知らないと確実に踏む。

クラウド側の環境には通信制限がかかっていることがある。 このプロジェクトでは、論文サイトも企業のサイトも全滅で、外部への接続が一律で塞がっていた。通ったのはパッケージの取得と GitHub だけである。

つまり調べ物はクラウドで完結しない場合がある。 コードを書く・ドキュメントを直す・PRを立てるといった、リポジトリの中だけで済む作業は問題ない。一次資料を取りに行く作業は手元でやることになった。

で、SEの実務ではどう使うか

効くのは「レビューを待たせない」ことである。

多重下請けでも社内開発でも、承認待ちで止まる時間がいちばん長い。 レビュアーがPCを開くまで進まない。しかもレビュアーは大抵、会議で席にいない。

ここに使う。PRの確認と承認だけを、移動中に片付けられる状態にしておく。実装や修正はAIとクラウドに任せ、人間は判断だけをスマホで通す。設計レビューのような重い判断には向かないが、「意図どおりか」を見るだけの承認なら十分に通る。

導入するときの勘所は2つある。

**1つめ。承認する人にモバイルアプリを入れてもらう。**アプリ内ブラウザ経由だと非公開リポジトリで404になり、「PRが見えない」という問い合わせが来る。原因が分かりにくいので、最初に案内しておくほうが早い。

**2つめ。公開や本番反映は、意図的に手元に残す。**このサイトでは、デプロイだけはクラウドから叩けないままにしてある。技術的には可能で、認証情報をクラウド環境の環境変数に置けば通る。やらなかった理由は2つで、環境変数はその環境を使う全セッションから見えることと、世に出る直前に人間が必ず一度入る構造を残したかったことだ。

週に1本の運用では、ここがボトルネックにならない。自動化しない場所を決めておくのも設計である。


移動中に進むようになって変わったのは速度ではなく、着手までの時間だった。「PCを開いたらやろう」と思っていたものが、そのまま消えずに進む。

出典

  1. https://code.claude.com/docs/en/claude-code-on-the-web