AI エージェントとは「もくもく作業」できない
(今回は技術的な話は一切ありません。あしからず)
昨年の骨折入院以来「やる気スイッチ」がオフになりっぱなしだったのだが(療養で休職中でよかったよ),先日 pull request を頂いたことで久しぶりにスイッチが入った。
仕事以外で GitHub Copilot のエージェント・モードはほとんど使わない。 ここのブログ記事を書く際のタイトル決めやデプロイ作業を手伝ってもらうくらい。 でも,折角なのでここは Copilot エージェントに貰った PR のレビューからマージまでやってもらうことにした。 ついでに他の goark リポジトリについても少しずつレビュー,修正,PR,マージ,そしてリリース処理までの一連をやってもらっている。
ちなみに Copilot のモデルは GPT-5.3-Codex を主に使っている(これが一番コストと性能のバランスが取れてる)。 コード補完やコメント生成くらいなら premium request のコストが発生しない GPT-mini でも十分なのだが,エージェント・モードだとおバカ過ぎて使いものにならない。 まぁ,だからこそみんなお金を払って高コストモデルを使うんだろうけど。 でも今月はまだ3分の1しか経ってないのに,もう半分以上使ってしまってるよ。 散財の予感がする…
プログラマならみんな経験があると思うけど,コードを書いてるとフロー状態というか「ゾーンに入る」ことがある。 職場だと周囲の「雑音」のせいでフロー状態を維持するのが難しいこともあるけど,雑音が少ない在宅作業だと一度フロー状態にハマるとなかなか抜け出せず,気がついたら飯も食わんとエラい時間が経ってたなんてことがある(逆に在宅のほうが雑音が多い人もいるかもしれないが)。
だから gogh みたいな作業支援ゲームでポモドーロ・タイマーみたいなのを仕掛けておくというのは意外と有用なのよ1。 コワーキング・スペースや図書館や喫茶店などで作業するってのは集中するための手段じゃなくて集中し過ぎないための手段だと思っている。 「もくもく作業」はちゃんと時間を区切ってやらないと。
一方で AI エージェントとの作業は「もくもく作業」にならない。 当たり前だ。 「対話」してるんだもの。
プログラマ目線で見ると,あれって機械とのペアプログラミングだわ。 機械がコードを書いて,横で人間が茶々を入れながら見てるの。
ペアプログラミングってマジでやるとお互いめっちゃ疲れるんだよな。 コードを書く側は常に見られながら書いてるからフローどころじゃないし,横で見ている側もコーディング中の相手の思考や作業ペースを邪魔することなく適切に意見を言わないといけない。 誰だよ,最初にペアプロはいいとか言い出したやつ!
まぁ,でも,少なくとも相手は機械だから緊張とか気分とかいった精神状態とは無縁だし,間とか空気とか読まなくていいし。 対話の途中でマシンから離れて飯を食ってても昼寝してても全然問題ない(笑) むしろ人間側は集中力を酷使して疲弊しないようにしないと。 こういうときこそポモドーロ・タイマーだな。
とはいえ,エージェントの自主性(笑)に任せると企業プレゼンみたいなことを言い出したりするので,人間側が目標と範囲と大まかな手順を与えてやらないといけない。 まぁ,人間相手でも,そこはあまり変わらないか?
機械は人間の言うことを否定しない。 「私は◯◯だと思う」とか「◯◯したほうがいい?」とかいった訊き方をしてノーと言われた試しがない。 だから AI は人生相談にとことん向かない。 人間の怒りも哀しみも寂しさも機械は全肯定してブーストする。
一方で「A と B のどちらがいい?」みたいな選択肢を与えると,根拠を示してそれなりの意見をくれる(意見が正しいかどうかは別として)。 ただし「A と B のどちらがいい?」と訊いても「それより C という選択もありますよ」みたいな応答を返すことはない。 機械に sense of wonder を求めてはいけない。
機械は「やれ」と言ったことに対しては規模や難易度や合法・非合法といったことに関わらずやる(またはやろうとする。強制的にガードがかかってできない場合もあるが)。 でもその結果に対して「GO OR NO-GO」を判断するのは人間の仕事である。 だから,その結果を最終的に実行する判断を機械に委ねるのは間違ってるし,人間が判断できない規模や複雑さを持つ結果を「生成」させてはいけない。 AI が生成した pull request が多くの開発コミュニティで嫌われるのは,量も複雑さも人間の判断の範囲を超えているから。 人間社会なんだから,あくまでも主役は人間である。
機械による作業結果が人間の評価・判断を超えそうなら,超えないレベルまで分割すればいい。 これも人間の仕事。 作業分割とマイルストーンの設計が大事。
GPT-5.3-Codex が賢いと思ったのは,評価観点のひとつが「人間が見て分かりやすいかどうか」である点だ。 コードの修正範囲,コミットや PR の単位,後方互換性といったことについて人間側の視点を考慮してくれる。 考え方(?)が若干保守的ではあるが,よく躾けられてる印象である。 同じようなことを GPT-mini にやらせると,ホンマ無茶苦茶するからなぁ。
GitHub Copilot のエージェント・モードに対する感想でした。 オチはない。
参考
- ピープルウエア 第3版
- トム・デマルコ (著), ティモシー・リスター (著), 松原友夫 (翻訳), 山浦恒央 (翻訳)
- 日経BP 2013-12-18
- 単行本(ソフトカバー)
- 4822285243 (ASIN), 9784822285241 (EAN), 4822285243 (ISBN)
- 評価
とりあえず図書館で借りて試し読みしたら面白かったので買うことにした。原書の初版が1987年ということで,当時の雰囲気が漂う感じ。アジャイルやスクラムなど現代につながる開発スタイルの源流とも言える本。
-
とはいえオリジナルの Pomodoro Technique の言う「25分」は短すぎると思うけど。『ピープルウエア』によると,通常はフロー状態に入るのに15分程度かかるらしい。なので25分タイマーでフロー状態から覚めるのは全く効率が悪いということになる。 ↩︎

