スマホでバイブコーディング

最近、通勤時間の電車内でスマホを使い、AIにプログラムを書かせる作業(いわゆる「バイブコーディング」)にハマっている。


作業の軸になっているのは、自宅で常時起動させているUbuntuサーバーだ。ここでCLI版の「Google Antigravity」を動かし、そこに指示を送るスタイルをとっている。


最初から快適だったわけではなく、いくつか試行錯誤があった。


スマホのSSHクライアントアプリ

 最初に試したのがこの方法。一見良さそうだったが、日本語入力の挙動がおかしくなったり、入力確定のタイミングが合わなかったりと、文字入力周りのストレスが多かった。ログも見づらいし余りおすすめできず。
 

既存のWeb UI(OSS)

次にWebブラウザ経由で操作できるOSSのターミナルツールなどを試してみた。ただ、トークン認証の設定やセッション保持がうまく噛み合わず、導入を断念した。

Antigravity自身にWebインターフェースを作らせる

「Web経由で操作したいなら、専用の軽量Web UIを自分で用意すればいいのでは」と思い立ち、試しにAntigravity自身に「Antigravity(agyコマンド)をWebから操作するためのPythonスクリプト」を書かせてみた。
結果として、これが一発であっさり動いた。
バックエンドはFlaskで動作し、内部でsubprocessを使ってagyコマンドを呼び出すシンプルな作りだ。途中で通信切れても作業継続するし、ページ開けばすぐに指示出せるし、ログも見やすいし最高。そこから自分に合わせて機能を追加・調整してもらった。
 

・プロジェクト管理(作業フォルダの切り替え。必ず付与したい共通プロンプトの設定)
 ・ログ出力周りの最適化(ログを別ファイルに出力し、プロンプトへファイル経由で渡す仕組みなど)


欲しいと思った機能を伝えるとすぐに実装してくれるため、スマホでの作業効率が一気に向上した。

特にWebページ制作や簡単なAndroidアプリ開発などであれば、コードの記述からビルド・確認までのデバッグ作業がすべてスマホ1台で完結してしまうのには少し驚いている。


これまでは「何か欲しい機能があったら、まずGitHubなどでOSSを探してインストールしてみる」のが定番だった。しかし、ちょっとした用途のツールであれば、OSSの仕様に合わせて設定を捏ね繰り回すよりも、AIに自分の用途ぴったりなコードを書かせた方がはるかに手軽でストレスがなく、なにかすごい時代になったなぁと…

Gemini Cliをさわってみて、可能性と無料枠の限界を感じた話

(せっかくなので概要を伝えてGeminiにブログ書いてもらいました。やたらオーバーですが、ほぼそのまま載せてみます。カッコ内はAIの文章に書き足してます)

 

最近、巷で話題のGoogle製AIエージェント「Gemini CLI」を早速試してみました。これまで、コードの一部を生成AIに書いてもらうことはありましたが、プロジェクト全体をAIエージェントに任せて自律的に開発を進めてもらう、という体験は初めてです。

結論から言うと、「世界、変わるわ、これ…」という巨大な可能性の片鱗と、同時に「そう簡単にはいかない」という現実の両方を味わう、非常に興味深い体験となりました。

 

きっかけはWear OSアプリの少なさ

ことの発端は、最近手に入れたWear OS搭載のスマートウォッチ。ガジェット好きとしては心躍るアイテムなのですが、いかんせんアプリがまだまだ少ないのが現状です。

自分で作りたいと思いつつも、そのためにWearOSをいろいろ調べるのもなぁ、ということでGemini Cliで試してみようと思い立ちました。

 

驚愕!人間よりスムーズかもしれない仕様策定

作りたいアプリの構想は、頭の中である程度しっかり固まっていました。問題は、それをどうやって正確に「仕様」という形に落とし込むかです。そこで、頭の中にある構想を箇条書きのような形で、要点をGemini CLIに伝えていくことにしました。

すると、どうでしょう。Gemini CLIは、こちらの意図を驚くほど正確に汲み取り、それらを整理して、体系的な仕様書にまとめてくれるのです。

 

さらに驚いたのは、仕様の抜け漏れや、考慮すべき点を的確に質問してくること。

正直、下手な人間のプログラマーに口頭で仕様を説明するよりも、はるかにスムーズで的確です。この対話能力の高さには、思わず「すごい…」と声が漏れてしまいました。(本当には漏れてないですが・・)

放置するだけ?全自動で進む開発プロセス

見事に完成した仕様書に満足し、次はいよいよプロジェクトの作成を依頼しました。

"この仕様書に基づいて、Android Studioのプロジェクトを作成して"

この一言で、Gemini CLIは黙々とWear OSアプリのプロジェクト構造を作り始めます。そして、開発は次のフェーズへ。

"ビルドして"

指示を出すと、Gemini CLIはプロジェクトのビルドを開始。当然のように、最初はエラーが出ます。しかし、ここからがAIエージェントの真骨頂でした。

  1. ビルド実行

  2. エラー発生

  3. エラー内容を自ら解析

  4. 原因を特定し、ソースコードを修正

  5. 再度ビルド実行

このサイクルを、なんと完全に自動で繰り返していくのです。画面には、ものすごい勢いでログが流れ、コードが書き換えられていきます。

「これはすごい。本当に放置しておくだけでアプリが完成してしまうんじゃないか…?」

未来がすぐそこまで来ていることを実感し、興奮を隠せませんでした。(さすがに、完成してしまうとまでは思えませんでした・・)

 

しかし、現実は甘くなかった…

夢のような全自動開発を眺めていると、いくつか問題点が見えてきました。

まず、気づいたらGemini 2.5 Proがすぐに利用上限に達してしまい、より性能の低いFlashモデルに切り替わっていました。処理速度が落ちたのか、ビルドと修正のサイクルがなかなか終わりません。

時計を見ると、すでに3時間が経過。Gemini CLIは健気にビルドと修正を繰り返していますが、一向に成功する気配がありません。

そして、ついにその時が訪れます。

非情なエラーメッセージ。1日のAPI利用上限に達してしまったようです。

結局、ビルドを通すという最初の関門を突破することなく、私の初めてのAIエージェント開発は幕を閉じたのでした。(続きはまた明日してみます)

結論:これは壮大な「課金への招待状」だ

残念ながら、アプリを完成させるには至りませんでした。しかし、今回の体験で得られたものは非常に大きかったです。

もし、APIの利用制限やモデルの制限がなかったとしたら?

おそらくGemini CLIは、時間はかかっても、自力でエラーを解決し、ビルドを成功させていたでしょう。そして、機能実装、テスト、リリースまで、その多くを自動化できてしまうに違いありません。(Geminiが勝手に書いてくれましたが、自動化できるところはある程度限られているのかなとも思っています。でも、いい・悪いがはっきりしていて、PC内で完結できるテストは自動化できそうですね)

自律的に学習し、問題を解決し、成果物を生み出す。

このAIエージェントのポテンシャルは、間違いなく世界を変える力を持っています。そして、今回私が直面した「リソースの壁」は、より高性能な有料プランへの、Googleからのおそらくは意図的な、そして極めて効果的な「招待状」なのだと感じました。

「この先が見たいなら…」「本当にアプリを完成させたいなら…」

そう囁かれているような気がして、思わず苦笑してしまいました。悔しいですが、その誘いに乗ってしまいたくなるほど、Gemini CLIが垣間見せた未来は魅力的でした。

AIエージェント開発、恐るべし。今後の進化と、私のお財布の未来が少し心配になる、そんな体験でした。(雑多なアプリがストアに氾濫するということがまずは起こりそうな気がしました)

 

 

 

 

Wake On LANに対応していないPCを無理やりリモート起動した話

最近、デスクトップパソコンを組みなおしました。

しっかり調べていなかったのが悪いのですが、どうやら新マザーボードWOLWake On LAN)に対応しておらず、シャットダウン(S5)状態からの復帰はおろか、スリープ状態からの復帰も色々試しましたができませんでした。

ただBIOS/UFEIのメニューを見ていると、「AC電源復帰時に電源を付ける」という機能があることがわかりました。

そのためAC電源復帰時は常にPCを起動する設定にしたうえで、スマートプラグを購入し、リモートからコンセントをオン・オフすることでリモート起動することに。

実際に購入したのはコレ

SwitchBot スマートプラグミニ(JP) | チップ3IN1、今ある家電を手軽にスマート化 – SwitchBot (スイッチボット)

 オン・オフの機能だけではなく消費電力も計測できるので、パソコンの消費電力測定とかもできてなかなか面白いです。

実際に組み込んでみて、問題なくリモート起動することができるようになりました。

ただ、PC起動中に間違ってオフにすると、いきなり電源を抜くのと同じなので注意が必要です。

そういった事故がないようにオン・オフについては、スクリプトを書いてスクリプトから行うようにしています。 APIも用意されているので簡単にスクリプトから操作可能です。

 

●起動する場合

pingでPCは起動しているか確認。起動している場合は何もしない

プラグの状態の確認、オンの場合はいったんオフにして少し待つ

プラグをオンにする

 

●シャットダウンする場合

pingでPCは起動しているか確認。起動している場合:

 リモートからPCのシャットダウンを行う(SSHでつなぎshutdownコマンド実行)

 pingがかえってこなくなるまでしばらく待つ

 念のためさらに10秒ほど10秒ほど待つ

プラグをオフにする

gitlabインストール後の502エラー

起こっていた問題

仕事で使っているgithubとかbitbucketのようなものを、趣味用に欲しい、オンプレで自宅サーバにいれたいと思ったので、gitlab-ceをインストールしてみました。(環境 Ubuntu 20.04)

Ubuntu 20.04にGitLabをインストールして構成する方法 - Tutorial Crawler

このページ等を参考にインストールしたのですが

・ページにアクセスしようとしたら502エラー(時間がたっても解消せず)

・bundleというプロセスが常時CPUを100%近く使用している状態

になってしまいうまくいきませんでした。

単純な原因だったですが、ドンピシャな情報が出てこず、究明までに時間がかったのでメモ。

原因と対策

8080ポートを別プロセスで使用していたため(自分の場合はJenkinsが使用)

Jenkinsのポートを変更することで解消しました。

 

もしくは下記ページ等を参考にrailsで使うポートを変更することでも大丈夫そうです(試してないです)。なお、今の環境ですと、unicornではなくpumaという名前のようです。

GitLab が使用する Unicorn 用のポート番号を変更する | まくまくGitノート

Jenkinsのポート変更(Ubuntu 20.04)

少しはまったのでメモ

結論

sudo systemctl start jenkins

のような形で起動している場合
/usr/lib/systemd/system/jenkins.service
を編集する必要がある

Environment="JENKINS_PORT=8080"

の部分のポートを変更する。

sudo vi /usr/lib/systemd/system/jenkins.service
sudo systemctl daemon-reload
sudo systemctl restart jenkins

ダメだった方法

/etc/default/jenkins
を編集する。
検索すると出てくる方法で、何かこれを変更すれば反映しそうな雰囲気があるファイルだが、自分の環境ではきかなかった。

Pythonのcgiで別プロセスを呼び出す際にはまったこと

やりたいこと

WEBアクセスに応じて、プロセスをたちあげて処理を開始する。
プロセスをたちあげたらレスポンスを返す(プロセスの終了を待たずにレスポンスを返す)

環境

ubuntu 20.04 server
標準で入っているApache
Python 3.8.10

うまくいかなかった例

別プロセスとして、以下のPythonスクリプトを呼び出すケースを考えます

mytask.py

import time
time.sleep(20)

以下のCGIスクリプトで処理をしようとしました。
test.py

#!/usr/bin/python3
# -*- coding: utf-8 -*-
import subprocess

devnull = open('/dev/null', 'w')
subprocess.Popen(["python3", "mytask.py"], close_fds=True, stdout=devnull, stderr=devnull)
print("Content-Type: text/html")
print("")
print("OK")

さて、このスクリプト

python3 test.py

と実行するとすぐに処理がおわり、psコマンドでpython3 test.pyのプロセスが走っていることが確認できます。
では、これでOKかと思いきや、CGIでtest.pyを呼び出すと20秒ほど応答が返ってきません。
Apacheか何かがすべての処理が終わるのを待っているようです。

対策

色々試した結果ですが、Popenの個所を以下のようにしたら、CGI経由でも意図通りに動きました。

subprocess.Popen("nohup python3 mytask.py &", shell=True, close_fds=True, stdout=devnull, stderr=devnull)

終わりに

Google Assistant経由で、声で時間がかかる処理を開始しようとしていたのですが、
この影響で処理ははじまるものの、Google Assistantから、「~と接続できません」と言われてしまっていて悩んでおりました。
少し強引な方法ですが、スマートに動くようになってよかったです。

Actions on Googleでログインできなくなっていた話

起こっていたこと

以前、以下の記事でactions on googleを設定して、テスト環境で使用する方法を記載していたのですが、昨日久しぶりに再リンクさせようとしたら、リンクできなくなっていました。

「デバイスのセットアップ」から、「Googleと連携させる」を選ぶと、確かに目的の自分のアプリがリストアップされるのですが、選択してもログイン画面などにもいくことなく、「Could not reach [test]アプリ名. Please try again.」と表示され先に進めません。

自分の認証サーバのログを見てもGoogleからアクセスがきた形跡が一切ないので、自サーバ側の問題ではなさそうです。いろいろGoogleアカウント側の設定を変更して試してみたのですが効果がなく、結構の時間が解決まで浪費しました。

解決法

いろいろ検索していたのですが、以下に解決法が提示されていました。Home Assistantというactions on googleを利用して操作できるようにできるライブラリを使っていても、同じ問題が最近発生していたようで、その解決方法です。

Can no longer link Google Assistant - #19 by Omnipius - Configuration - Home Assistant Community

Actions on GoogleのプロジェクトのDeployの「Directory Informartion」欄を埋める必要があるようです。

f:id:shimobepapa:20220410092630p:plain

 

こちらsaveした直後はつながらないままだったのですが、再度Test実行の処理などをしているうちに、つながるようになりました。

仕様を変えたら、公式ドキュメントも変更してほしいなと切に思いました。

shimobepapa.hatenadiary.jp