スマホとDevinで始める旅行駆動開発（旅行記あり）

背景

旅行好きのITエンジニアなら誰でも出先で開発をしたいと思ったことがあるだろう。旅行は何かと待ち時間が発生するので、そこに好きなアクティビティをねじ込むことが旅行の醍醐味の一つなのである。

しかしPCを旅行中に持ち歩くのは何かとしんどい。そこで、スマホだけで開発できないかを考えてみた。

結果、Devinという解に辿り着いた。DevinにSlack上で指示するだけで開発ができればノートPCを持ち歩く必要がなくなるのでは？

この記事は本当にスマホ&Devinだけで開発可能かどうか、2泊3日の旅行で実際に試してみたレポートである。

（茶番を多く含むので、結論だけ知りたい方はまとめを見てください）

事前準備

icebox（私の頭の片隅）で眠っていたタスクを3つ用意した。

チケットに碌に内容が書かれておらず、自分でも忘れているので、それぞれのチケットについて関連情報（チャットログなど）を収集（テキストファイルにコピペ）しなおし、それを適当なLLMに投げてDevinに渡す最初のプロンプトを作成してもらう。

要するに、最初のプロンプトだけ事前に作成しておいた。

Day 1 東京->新大阪 & トルクメニスタンパビリオン

のぞみに乗る。東京駅で関西駅弁フェアをやっていたので岡山の駅弁を購入。

駅弁を食べながら、たまに起こるデータ不整合の調査と解決を依頼。過去発生した事例集とともに「原因を調査してください。原因の特定が難しい場合は調査のためのログを出してください。」と指示。駅弁は半ばながらすぐにログを追加してくれた。

一応GitHubのコード差分を小さい画面で読んで分かった気になるも、このまま謎のログをマージされても後で困るので、ついでにエラーログが出た時のRunBookを作ってもらうことにした。

ここまでは順調だったが、原因調査は停滞した。

途中居眠りを挟みつつ原因を調べてもらった。しかしこれらはいずれも間違っており、過去事例から反例を示す羽目となった。

気づけば新大阪に到着していたので、スマホを閉じて夢洲まで移動。

2回目の万博。昼過ぎだったので東ゲートの待ち時間は15分程度。トルクメニスタン館に並んでみる。

多分ピークタイムだったのかパビリオンの入場に30分以上、そこから中にあるレストランでもう30分以上並ぶことに。

待っている間最終レビューをしようと開くと、ログ以外にロジックの修正が入っていることに気付く。結局コードベースで根本原因は見つけられないまま、この場での問題解決は見送りとなった。ただ、やり取りをする中で自分の中で整理されることが多かった。

なおレストランは、東京の中東・中央アジアのレストランに度々通う私でもあまりみたことのないものに出会えて素晴らしかった。

結果

• 原因解決せず。ログ追加のみ。
• チャット数: 80
• ACU: 16
• コミット数: 15 (Devin12, 人間3)

Day 2 梅田->京都->近江八幡 （往復）

依頼したタスク: APIの大規模改修

梅田から阪急電車に乗り烏丸に向かう（写真は乗った電車ではない）。

「ログインAPIにあるAの仕様をサインアップAPIにも実装してください。そのとき元々サインアップAPIにあったBの仕様は削除してください。それぞれ、どこかに実装があるので探してください」と指示。スマホでコードを見られないので、コードをコンテクストとして渡すことはできず、日本語で指示してみる。

これは幸先がよく、それぞれ適切なAPIを見つけてきて、それっぽいものを実装してくれた。

烏丸に着いた。10年ぶりに先斗町をぷらつき、京都駅に移動し、琵琶湖線に乗って滋賀県を走っていく。

一応コードを見てみると、古いソフトウェアアーキテクチャで実装していた。新しいアーキで実装して欲しかったな、けどそんな指示していなかったなと考える。そもそも古いソフトウェアアーキテクチャが残っていることに問題がある。rulesを整備するなり古いアーキテクチャを脱却するなりすべきである。

嫌な予感がしながらも「新しいアーキテクチャに書き換えてほしい。古いアーキは〜で、新しいアーキは〜で」と説明を添えて指示。

そのうちに近江八幡に到着し、バスで目的地のラコリーナに向かった。バームクーヘン工場を見学した。

帰り道でDevinの成果物を確認。Devinは指示をこなしてくれていたが、linterが通らなくなっていたし、なんなら他のテストが巻き込まれて落ちていた。

エラーログを見ながら指示して、9割がた修正されたが、全てのCIは通らずにギブアップ。

これに着いては帰宅後に引き継いで開発。

なお帰宅後確認したのだが最初の筆者の指示の要件が間違っていることが発覚した。それに気付き巻き戻すまでにCursorのクォータをかなり消費した。これが正しければ、もっと早く終わっていたはずである。

結果

• 叩き台の実装完了。ただしlint errorが出たままになるなどCIが通らない状態であった。ただしロジックについてはほぼ正しいものが実装されていた。
• チャット数: 68
• ACU: 44
• コミット数: 28 (Devin11, 人間17)

Day 3 うめきた公園 & 新大阪->東京

依頼したタスク: flakyな統合テストの修正

うめきた公園（グラングリーン大阪）に来た。遊んでいる子供を尻目にDevinに話しかける。

まず数千行のエラーログとともに、エラーの原因調査と修正を依頼。

すぐにエラーの特定をして修正のPRを作ってもらった。しかしこれは期待した修正ではなく、リジェクトした。

そこから頭の片隅に追いやりながら梅田を観光する。

そして新大阪から帰る。

根本的にエラーの原因分析ができていないように感じたので、一旦DevinではなくGemini 2.5 Proにエラーログだけ渡してエラーログを解析させてみた。すると、正しいエラー原因がアウトプットされた。エラーログが長すぎて理解できなかったか？

エラーログではなく、Geminiの作ったエラーレポートを別セッションで再度Devinに渡して修正を依頼正しい修正がされたので、その場でApproveした。

結果

• 完了
• チャット数: 72
• ACU: 12
• コミット数: 2 (Devin2, 人間0)

まとめ

今回の3件の課題について、解決まで行ったのは1/3件。解決しなかった1件は調査ログ追加のみで一旦完了。もう1件は帰宅後引き継いでPCで開発してマージした。加えてそのどれもに30回以上のラリーが発生した。よく聞く話のように「要件を定義するだけで一発解決」とはいかなかった。

ではDevinは役に立ったのか？ それは明確にYesである。

重要なのはDevinがトリガーになってくれることである。Devinは状況を整理し、叩き台を作って提案してくれるので、こちらの理解度が深まる。それにより解決に繋がるアシストをDevinに出せたり、最終的に自分が実装することになっても、Devinの実装をスムーズに引き継ぐことができる。

一発・全自動で解けるような簡単・明快なタスクだったら、自分か誰かがやっているので、それをDevinに完全解決してくれることはそれほど期待していない。

今回の経験で、コーディングエージェントがすんなり解けないような課題について、人間とAIがどう役割分担するといい感じに解決できるかの体験設計に興味が湧いてきた。

例えば自分はデスクで長時間じっとしているのが苦手なので、好きな場所・好きな方法で対話的にタスクを進めて、出てきた叩き台を短時間で立派な開発環境で集中して解くというふうにメリハリが付けられるといいなと思った。

実際に、スマホというデバイスで開発する体験はどうだったかについて。

SlackでDevinを利用する限りにおいては、スマホとPCでの開発体験に大きな差はないし、慣れたチャットインターフェースでやりとりできた。

PRがGitHub上で作られるので、GitHubアプリから読むことになる。コードの全文を読むのは厳しいが、Devinの言っていることの裏取りをしたり、やり取りをする中で深掘りしたいところの一次情報としてインプットしたりするのに使った。

ところで最初はスマホを持っていたこともあり「コードを一切見ないで開発する」という縛りを自分の中に入れていたのだが、これは早々に解除してしまった。 スマホの小さい画面であっても、必要に応じて人が目でコードを見て考えられることが、協調して良質なアウトプットを出す時には重要であることを認識したためである（AIとの認知的不協和が生じるときはコードを読む目も鋭くなるのである）。

繰り返しになるが、エージェントが行き詰まったコードを引き継いで開発できることがPCのスマホに対する強い優位性であると思った（なおもう一つあると思っていて、それは最初のプロンプトを作る上で各地に散らばった情報を集めてきてまとめることである。これはスマホには難しい。スマホはエントロピーを増やすツールで、PCは減らすツールである）。

最後に、Devinには大きな問題がある。それは人間がやるのと遜色ないレベルのコストが掛かることである（今回で言うと70ACU≒2万円くらいで、稼働時間を考えると本当に人間と遜色ない）。

その点においてローカル環境は偉大である。スマホとローカルPCとのシームレスな統合体験を提供できるAI SaaSの登場が私的には待ち遠しい（SlackにI/OするMCPを自作するのが早そうだが）