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エージェントの真骨頂でした。
-
ビルド実行
-
エラー発生
-
エラー内容を自ら解析
-
原因を特定し、ソースコードを修正
-
再度ビルド実行
このサイクルを、なんと完全に自動で繰り返していくのです。画面には、ものすごい勢いでログが流れ、コードが書き換えられていきます。
「これはすごい。本当に放置しておくだけでアプリが完成してしまうんじゃないか…？」
未来がすぐそこまで来ていることを実感し、興奮を隠せませんでした。（さすがに、完成してしまうとまでは思えませんでした・・）
しかし、現実は甘くなかった…
夢のような全自動開発を眺めていると、いくつか問題点が見えてきました。
まず、気づいたら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を無理やりリモート起動した話
最近、デスクトップパソコンを組みなおしました。
しっかり調べていなかったのが悪いのですが、どうやら新マザーボードはWOL（Wake On LAN）に対応しておらず、シャットダウン（S5）状態からの復帰はおろか、スリープ状態からの復帰も色々試しましたができませんでした。
ただBIOS/UFEIのメニューを見ていると、「AC電源復帰時に電源を付ける」という機能があることがわかりました。
そのためAC電源復帰時は常にPCを起動する設定にしたうえで、スマートプラグを購入し、リモートからコンセントをオン・オフすることでリモート起動することに。
実際に購入したのはコレ
SwitchBot スマートプラグミニ（JP） | チップ3IN1、今ある家電を手軽にスマート化 – SwitchBot (スイッチボット)
オン・オフの機能だけではなく消費電力も計測できるので、パソコンの消費電力測定とかもできてなかなか面白いです。
実際に組み込んでみて、問題なくリモート起動することができるようになりました。
ただ、PC起動中に間違ってオフにすると、いきなり電源を抜くのと同じなので注意が必要です。
そういった事故がないようにオン・オフについては、スクリプトを書いてスクリプトから行うようにしています。 APIも用意されているので簡単にスクリプトから操作可能です。
●起動する場合
pingでPCは起動しているか確認。起動している場合は何もしない
プラグの状態の確認、オンの場合はいったんオフにして少し待つ
プラグをオンにする
●シャットダウンする場合
pingでPCは起動しているか確認。起動している場合：
リモートからPCのシャットダウンを行う（SSHでつなぎshutdownコマンド実行）
pingがかえってこなくなるまでしばらく待つ
念のためさらに１０秒ほど１０秒ほど待つ
プラグをオフにする
gitlabインストール後の502エラー
起こっていた問題
仕事で使っているgithubとかbitbucketのようなものを、趣味用に欲しい、オンプレで自宅サーバにいれたいと思ったので、gitlab-ceをインストールしてみました。（環境 Ubuntu 20.04）
Ubuntu 20.04にGitLabをインストールして構成する方法 - Tutorial Crawler
このページ等を参考にインストールしたのですが
・ページにアクセスしようとしたら５０２エラー（時間がたっても解消せず）
・bundleというプロセスが常時CPUを100％近く使用している状態
になってしまいうまくいきませんでした。
単純な原因だったですが、ドンピシャな情報が出てこず、究明までに時間がかったのでメモ。
原因と対策
8080ポートを別プロセスで使用していたため（自分の場合はJenkinsが使用）
Jenkinsのポートを変更することで解消しました。
もしくは下記ページ等を参考にrailsで使うポートを変更することでも大丈夫そうです（試してないです）。なお、今の環境ですと、unicornではなくpumaという名前のようです。
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アクセスに応じて、プロセスをたちあげて処理を開始する。
プロセスをたちあげたらレスポンスを返す（プロセスの終了を待たずにレスポンスを返す）
うまくいかなかった例
別プロセスとして、以下の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)
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」欄を埋める必要があるようです。
こちらsaveした直後はつながらないままだったのですが、再度Test実行の処理などをしているうちに、つながるようになりました。
仕様を変えたら、公式ドキュメントも変更してほしいなと切に思いました。
ミニPCをUbuntuで無線LANルーター化
動機
NAS＋自宅サーバ＋ルータの機能が一台でできたら機器も減って、きっと省電力のはず。拠点間のVPNとかも簡単にはれそうだし。あとルータ回りでトラブルよくわかるけど、原因自分では深く追えないし、いっそのこと自分で構築する？みたいなところからスタートしています。
ひとまずは実家のルータ＋NASにと、Celeron J4105のLANポートが二つついているミニPC「Kodlix GK45」にSSDを追加して、仕上げてみました。
導入したOS
Ubuntu Server 20.04.3 LTS
完成イメージ
２つあるLANポートのうち、一つをWAN側に、もう一つをLAN側にします。
LANのアドレスは
192.168.1.0/24
Wifiの親機としても動いて、WiFiで接続してきた子機も同じLANに繋ぎます。
（よくある無線LANルータの設定）
インターフェース名の調べ方
対応するポートがなんというインターフェース名か(OSでなんという名前で扱われているか）は
ip a
と入力して調べます。LANポートの場合抜き差しすると状態がかわるので、LANポートが複数ある場合は、ポートに抜き差しして、どのインターフェースに変化があるかをしらべて、インターフェース名を特定します。
自分のGK45では下記のようなインターフェース名でしたので、以下、下記の名前で設定していきます。
- WAN用のポートにする有線LANインターフェース：eno1
- LAN用のポートにする有線LANインターフェース：enp3s0
- WiFiインターフェース：wlo2
ルーターに仕立てる設定１：netplan
最近のUbuntuはネットワークの設定をするのはnetplanを使うのが流儀のようです。
netplanで設定していきます。
netplanの設定ファイルは
/etc/netplan/
にあるすべてのファイルを辞書順に読んでいくようです。
ディレクトリにあるすべてのファイルを別の場所に移し、こちらに以下の内容のファイルをつくります。
network: ethernets: eno1: dhcp4: true enp3s0: dhcp4: false optional: true bridges: br0: interfaces: [enp3s0] addresses: [192.168.1.1/24] nameservers: addresses: [8.8.8.8, 8.8.4.4] optional: true version: 2
そのうえで
sudo netplan apply
を実行します。
ここで行っているのは以下の設定です。
eno1はDHCPでアドレスを取得する。
enp3s0ではDHCPでアドレスを取得しない。
br0というブリッジを作り
そこにenp3s0をつなげる
IPアドレスを192.168.1.1
DNSを8.8.8.8, 8.8.4.4
ここで注意ですが、WiFiはnetplanでは扱いません。
（最初はNetplanでやろうとしていたのですが、うまくいかずやめました）
後ほどここで作ったbr0というブリッジにWiFiもつなげます。
ルーターに仕立てる設定２：DHCPサーバ
DHCPサーバを立てます。isc-dhcp-serverを使います。
インストール
sudo apt install isc-dhcp-server
設定ファイルの記述
通常起動したときに監視するインターフェースを指定します。
編集ファイル：/etc/default/isc-dhcp-server
INTERFACESv4="br0" INTERFACES="br0"
(INTERFACESv4だけでもいいかもしれませんが、一応念のため）
DHCPで払い出す内容の設定：/etc/dhcp/dhcpd.conf
option domain-name-servers 8.8.8.8, 8.8.4.4;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.2ip55.255.0 {
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
option subnet-mask 255.255.255.0;
range 192.168.1.100 192.168.1.254;
}適用
sudo systemctl enable isc-dhcp-server sudo systemctl start isc-dhcp-server
ルーターに仕立てる設定３：NAT
ufwを使用して設定するのが最近の推奨みたいなので、ufwで設定します。
参考：
ufwでNATとポートフォーワード - Qiita
DEFAULT_FORWARD_POLICY=“ACCEPT"
/etc/ufw/sysctl.conf
net/ipv4/ip_forward=1
/etc/ufw/before.rules (最後に追記）
# NAT *nat :POSTROUTING ACCEPT [0:0] :PREROUTING ACCEPT [0:0] -F -A POSTROUTING -s 192.168.1.0/24 -o eno1 -j MASQUERADE COMMIT
（LANからきた通信を、eno1にとおします）
ufw有効化
ufwを有効化すると、基本すべてのポートの通信ができなくなるので、あらかじめ必要なポートを開放しておきます。
ここでは、２２番ポート（SSH）と、LAN内からの通信はすべてOKの設定にします。
sudo ufw allow ssh sudo ufw allow in on br0 to any
有効化
sudo ufw enable
(iptables-persistentなどをインストールしてしまっていると、再起動時にufwが無効化されるので注意（はまった））
ルータに仕立てる設定４：WiFi
hostapdを使います。
インストール
sudo apt install hostapd
設定ファイルの場所を記述
/etc/default/hostapd
DAEMON_CONF="/etc/hostapd/hostapd.conf"
設定ファイルの内容例
/etc/hostapd/hostapd.conf
interface=wlo2 bridge=br0 channel=7 logger_syslog=-1 logger_syslog_level=1 auth_algs=1 wpa=2 wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP ssid=myssid wpa_passphrase=myoasswd hw_mode=g ieee80211n=1 ieee80211ac=0
bridge=br0
とすることで、このWiFiAPをbr0ブリッジに接続されるようになります。
また、
ieee80211n=1
ieee80211ac=1
などと書かないと、11n, 11ac通信が使えません。
hw_modeは、2.4gHz帯ならばｇ、5gHz帯ならばaになります。
（手元のGK45は５gHz帯に2.4gHz帯で設定していますｓ。
sudo enable hostapd sudo start hostapd
ここまでで、よくある無線LANルータの設定になりました。
ここから色々VPNで他拠点とつないだりとか、NASとしての機能を設定したり、Jenkinsなどをたてて自宅サーバとして色々させてみたりとか、やりたいことがUbuntuなので簡単にネットで検索して実現できそうです。
さらにニッチな設定については機会があれば別記事で。
