実験日誌 #2｜AIに開発を任せたはずが、私はずっと「スクショ係」だった
記録：2026年8月26日
AIに株システムを作らせる。
最初は、もっと自動で進むものだと思っていました。
コードはAIが書く。エラーもAIが直す。私は結果を見る。
そんなイメージです。
でも実際に始めてみると、私の仕事は少し違いました。
画面を開く。
スクリーンショットを撮る。
AIに送る。
「次どこ押す？」と聞く。
言われた通りに押す。
またスクリーンショットを撮る。
気づけば、AI開発のオーナーというより、ほぼ「スクショ係」になっていました。
※GitHubは、プログラムのコードや変更履歴を保存・共有するサービスです。PowerShellは、Windowsで文字のコマンドを入力してPCを操作するための道具です。
「AIがやる」のに、人間が画面を運んでいた
最初に作ったVer.1でExcelがないところから始まったこの実験は、その後GitHubやPython（プログラミング言語）、テスト環境へ少しずつ広がっていきました。
AIにコードを書いてもらえるようになっても、問題が一つありました。
AIは、私のPCで今何が起きているのかを勝手には見られません。
PowerShellに何が出ているのか。
GitHubがどの状態なのか。
どのボタンが表示されているのか。
エラーが出たのか、成功したのか。
そのたびに私が画面を撮って、AIへ渡していました。
「これで合ってる？」
「次は？」
「この表示なに？」
こうして一つ進むたびに、またスクショです。
ついには「承認ボタンを押す係」にもなった
Codexは、プログラミング作業を手伝うAIです。コードの修正案を出したり、ターミナル（文字でPCを操作する画面）で実行する操作を提案したりします。
Codexを使い始めると、AIがターミナル操作まで提案してくれるようになりました。
これはかなり未来っぽいです。
ところが、実際のPC画面には大きく「承認」と出ます。
AIが「Pythonを入れてよいですか？」
私が「承認」。
AIが次の作業を提案。
私がまた画面を確認して「承認」。
コードを書いているのはAIなのに、最後にボタンを押しているのは私です。
この頃になると、「AIに任せている」というより、
AIが作業する
↓
私が承認する
↓
止まる
↓
スクショを撮る
↓
別のAIに聞く
という、人間を中心にしたリレーになっていました。
快活CLUBまで行って、スクショを送っていた
PCをまとまって触れる時間を作るため、快活CLUBで作業したこともありました。
会社員をしながらなので、いつでもPCを開けるわけではありません。
まとまった時間を作ってPCを開き、GitHubを確認し、AIに指示し、止まったらスクショを送る。
今振り返ると、そこまでしてAIを使っているのに、私自身の手作業がかなり残っていました。
AIで時間を減らしたかったはずなのに、スマホとPCを行ったり来たりしている。
ここで初めて、
「これ、私がスクショ係をやっている限り、自動化とは言えないのでは？」
と思うようになりました。
Codexだけでは終わらず、Julesにも頼んだ
Jules（ジュールズ）は、Googleが提供するAIコーディングエージェントです。GitHub上のコードを読み、指示された修正やテストなどの作業を進め、終わったら変更内容を人間が確認できる形で提示してくれます。
ざっくり言えば、「作業を頼むと、コードを見て実際に手を動かしてくれるAI」です。
AIを変えれば、人間の作業が減るのではないか。
そんな期待もあって、CodexだけでなくJulesなど、別のAIにも作業を任せるようになりました。
でも、Julesにも最後はこう言われました。
「変更を承認してください」
AIは働いています。
ただ、AI同士が勝手に相談して最後まで終わらせてくれるわけではありませんでした。
少なくともこの頃は、AIが止まるたびに私が間に入り、次のAIへ状況を持っていく必要がありました。
GitHubにつなぐだけでも、また私が出てくる
OpenHandsという、AIに開発作業を進めさせるための別のAIエージェントも試しました。ここでいうAIエージェントは、質問に答えるだけでなく、指示に沿って複数の作業を進めるタイプのAIです。
GitHubにつなげば、もっと自動で開発できるかもしれない。
ところが接続画面には、また大きなボタンが出ます。
Authorize（接続を許可する、という意味です）。
つまり、ここでも人間です。
もちろん、セキュリティ上、人間の承認が必要なのは正しいことです。
問題は、私は「一度承認すればAIが自走する」と思っていたのに、実際にはその後も細かな確認が大量に残ったことでした。
「動いた！」より、「また私が見ないと進まない」が増えてきた
テストが100件以上通るようになると、技術的にはかなり前進したように見えます。
ここで使っていたpytest（パイテスト）は、Pythonのプログラムが想定どおり動くかを自動で確認するためのテスト用ツールです。
実際、保存してある画面には pytest -q — 101 passed, 1 skipped という記録も残っています。
でも、この頃の私が気にし始めたのはテスト件数だけではありませんでした。
「この作業、次も私が画面を見ないと進まないのか？」
ということです。
AIにコードを書かせることと、AIに仕事を任せることは違う。
この違いが、だんだん分かってきました。
「スクショ係をやめたい」が、自動化の目的になった
※この実験では、Google Drive上の記録置き場を便宜上「本社」と呼んでいます。
本社の当時の記録には、ブログ候補としてこんな言葉まで残っています。
「スクショ係をやめるためにGitHub Copilot Proへ課金した理由」
当時使っていたGitHub Copilot Proは、コード作成などを支援する有料のAIプランでした。
最初は株システムを作ることだけが目的でした。
でも途中から、もう一つの目的が増えました。
私がPCの前にいなくても進むこと。
スマホでスクショを何十枚も送らなくても進むこと。
AI同士が証拠を残し、人間は最後の重要な判断だけをすること。
この考えが、後のGitHub中心の運用や、独立監査（作業したAIとは別のAIにも内容をチェックさせる仕組み）、本社の正本（最新版として扱う元資料）、そして「オーナーはPCを開かない」という運用へつながっていきます。
今見ると、スクショだらけなのが一番おもしろい
本社Driveを見返すと、この頃の画像が大量に残っています。
ターミナル。
Codex。
GitHub。
Jules。
認証画面。
エラー画面。
承認画面。
当時は、ただ前に進むために保存していただけでした。
でも今見ると、それ自体が「AIに仕事を任せようとして、うまく任せられなかった記録」になっています。
華麗な自動化の成功談より、私はこっちの方が面白いです。
AIに仕事を任せたはずなのに、最後まで一番忙しかったのが人間だった。
そこから「人間をどうやって作業から外すか」を考え始めた。
この失敗がなかったら、今の実験室の形にはなっていなかったと思います。
次の実験日誌では、スクショ係をやめようとして、Codex・Jules・GitHub連携をどう変えていったのかを振り返ります。
※本記事はAIを使ったシステム開発・検証の個人的な実験記録です。特定銘柄の推奨、投資助言、利益の保証を目的としたものではありません。