2026 年 6 月 29 日、AI のコードエディター Cursor が iPhone アプリを出した。公式ブログによれば、スマホでプロジェクトを選び、クラウドの隔離された仮想マシンで動くコーディングエージェント、つまりコードを読み、ファイルを直し、テストを走らせる AI の助手を起動できる。パソコンで動いているエージェントを遠隔で指示することもできる。エージェントが終わると、デモ、スクリーンショット、実行の記録が残り、スマホで変更の差分を見て、続きの指示を出し、そのままマージできる。
夕食の前に小さなバグを見つけ、スマホからエージェントに任せられるのは確かに便利だ。だが同じスマホには、マージのボタンもある。画面が小さく、時間が細切れだと、いちばん起きやすいのは、要約だけ読んで押してしまうことだ。
スマホは作業を始めたり進み具合を追ったりするのに向いている。だが「どの変更はこうした条件でマージしてはいけないか」は、その場の自制心で決めるものではない。前もってリポジトリの保護規則に書き、システムに止めてもらう。
修正が小さくても、影響が小さいとは限らない
変更が小さいからといって、影響が小さいとは限らない。数行しか触っていないように見える修正が、ログインの権限、支払いの流れ、データベースの移行、デプロイの設定に響くことがある。エージェントが作業の途中で、任せた範囲を広げていることもある。スマホで見えるのはたいてい要約で、完全な差分やテストの結果ではない。
逆に言えば、問題はスマホそのものではない。テストがそろい、変更が小さく、問題が起きても戻せるなら、スマホで承認しても間違いとは限らない。間違いなのは、証拠が足りないのに、スマホを判子代わりに使うことだ。
スマホでできることを三段に分ける
見るだけ： エージェントが終わった、入力が要る、テストが失敗した、といった通知を受け、進み具合、スクリーンショット、実行の記録を見る。コードは直さず、マージもしない。
まずエージェントに任せる： 範囲がはっきりしていて戻せる小さな作業。文書の補足、テストの追加、バグの再現手順の整理などだ。触ってよいファイルとデプロイ禁止を指示に書き、エージェントはプルリクエストを開くだけで、直接本番には出さない。
完全なレビューが要る： 権限、支払い、データ、移行、デプロイの設定、セキュリティに関わるコードの変更。必ずしもデスクトップの前でなくてよく、タブレットやノートパソコンでもよい。ただし完全な差分、テストの結果、影響の範囲、戻し方が見えることが前提だ。
三段めはリポジトリの規則で止める
GitHub のブランチ保護の規則では、マージの前に決まった人数のレビューの承認を求めたり、指定した自動チェックの通過を求めたり、特定のファイルが変わったときにそのファイルの担当者（コードオーナー）の承認を求めたりできる。規則を設定すれば、どの端末でボタンを押しても、条件がそろわない限りマージできない。
だから三段めのファイル、たとえば権限の設定、支払いのモジュール、移行のスクリプト、デプロイの設定には担当者を決め、必ずレビューを通すようにする。そうすれば、スマホに「エージェント完了」の通知が来ても、リスクの高い変更はレビュー待ちで止まり、うっかり押して本番に出ることはない。エージェントにコードを任せる前の準備は、その issue を coding agent に渡せるかは、最初の diff を書き出せるかで決まるを参考にしてほしい。
規則は、気軽に承認する人までは止められない
リポジトリの規則が止められるのは「条件がそろっていない」ことで、「条件はそろったが、レビューした人がよく見ていない」ことまでは止められない。レビューする人もスマホで気軽に承認するなら、規則は形だけになる。最初の一週間はスマホでのマージを一切しないことにし、エージェントが残す差分とチェックの材料がスマホで十分に読めるとチームが確かめてから、スマホで承認してよいリスクの低い種類を挙げるとよい。
また、管理者はたいていブランチ保護を迂回できる。「迂回を許可しない」設定を有効にしていない限りだ。マージのあとのレビューと保守が費用の大半を占めることは、AI が出したコード変更の第一版は試し見積もり。本当の請求はレビューと保守にあるを参考にしてほしい。
AI 整理カード
チームでスマホから AI のコーディングエージェントを起動したり追ったりし始めた。どの変更はスマホでマージしてよく、どれはリポジトリの規則で止めるべきかを決めたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/cursor-mobile-agent-approval-boundary/
記事の見方はこうだ。スマホは作業を始めたり進み具合を追ったりするのに向いているが、小さな画面と細切れの時間でどの変更をマージしてはいけないかは、その場の自制心に頼らず、前もってリポジトリの保護規則に書いておく。必須のレビュー、自動チェック、コードオーナーの承認などだ。
私が許可したリポジトリの設定とディレクトリの構成だけを、読み取り専用で確認してほしい。設定もファイルも変更しないこと。
1. ディレクトリとファイルの用途から、「完全なレビューが要る」部分を見つける。権限、支払い、データ、移行、デプロイの設定、セキュリティに関わるコードで、パスを挙げる；
2. いまのブランチ保護の規則を確かめる。レビューを求めているか、どの自動チェックを求めているか、コードオーナーを設定しているか、管理者が迂回できるか。読めないものは「管理者の確認が必要」とする；
3. 足すべき規則と、担当者を決めるべきパスを提案する；
4. 文書だけ、テストだけの変更で、すべてのチェックを通っているなど、スマホで承認してよいリスクの低い変更の種類と条件を挙げる。
規則の変更はリポジトリの管理者の判断に任せ、提案だけをすること。
参考資料
- Cursor 公式ブログ：Build from anywhere with Cursor for iOS — https://cursor.com/blog/ios-mobile-app（2026-06-29）
- TechCrunch：Cursor now has a mobile app for guiding your coding agent on the go — https://techcrunch.com/2026/06/29/cursor-now-has-a-mobile-app-for-guiding-your-coding-agent-on-the-go/（2026-06-29）
- GitHub Docs（公式）：About protected branches — https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches [accessed: 2026-10-11]
