所長を働かせるのを諦めて装置を作ったら、3週間後に半分死んでいた
当ラボには長年、解決していない不具合があった。
所長が、運用しない。
記録用のファイルを作っても開かない。進み具合を自分で更新しない。判断待ちを忘れる。完成画面のスクリーンショットも撮らない。
普通ならここで「毎日確認しましょう」という話になる。
しかし当ラボは、別の結論へ到達した。所長を直すのをやめる。
開かない。更新しない。忘れる。撮らない。この四つを事故ではなく前提条件にして、人間の努力に頼っていた部分を装置へ渡すことにした。
作った4つの装置
① 夜間クロニクル — 毎晩、前日にラボで何が起きたかを勝手に記録する。判断待ちのまま期限が切れたものも整理する。
② スクリーンショット収穫機 — 公開したゲームやサイトを自動で巡回して、画面の画像と短い動画を撮ってくる。「撮らない」を物理的に解決する装置。
③ 予約投稿の準備装置 — AIがブラウザを操作して、Xの予約投稿画面に本文・画像・日時を入れた状態まで持っていく。所長は確定ボタンを押すだけ。
④ 週次編集会議の自動招集 — 毎週、直近1週間の記録から研究ログの下書きを1本と、○×で答えられる判断を1件つくる。「会議」という行事そのものを消す装置。
あわせて、ブレーキも書いた。2週間使われなかった装置は止める。 装置が増えすぎて所長が装置管理者になったら本末転倒である。
そして3週間、放っておいた。
3週間後に数えてみた
| 装置 | 3週間後 |
|---|---|
| ① 夜間クロニクル | 23日連続で稼働中 |
| ④ 週次編集会議 | 4回実行、稼働中 |
| ② スクリーンショット収穫機 | 2回動いて、止まっている |
| ③ 予約投稿の準備装置 | 2回使って、止まっている |
半分が死んでいた。
生きた2個は、どちらもパソコンのスケジューラに登録されていて、所長もAIも起動しない。 気づいたら終わっている。夜間クロニクルは23日ぶんの記録が1日も欠けずに並んでいた。
問題は、死んだ2個である。
収穫機は、遊ぶ前の画面しか撮れなかった
スクリーンショット収穫機は、初回に11件を収穫した。よく働いた。それなのに2回で止まった。
撮れてきたものを見てもらえば、理由が分かる。
上がレースゲーム、下が転がすゲームである。
どちらも、遊ぶ前の画面だ。
カートは「マシンセレクト」で車体の色を選んでいる。転がすほうは「スタート」で、タップして始めるところ。走っていないし、転がってもいない。
当たり前だった。この装置はページを開いてシャッターを切っているだけである。スタートを押して、ハンドルを切って、コーナーで攻めることはできない。
つまり、所長が撮らなくても済む画面だけが、自動で撮れるようになった。
所長が面倒がって撮らなかったのは、タイトル画面ではない。走っているところ、転がっているところ、うまくいった瞬間である。装置は「撮る」という動作を肩代わりしたが、撮りたかったものは肩代わりできていなかった。
予約投稿は、パソコンの前に座る必要が残った
予約投稿の装置は、動作としてはうまくいっていた。1件目でXの予約が実際に成立し、noteも下書き保存まで進んだ。設計どおりである。
2件目でやめた。
使ってみて分かった。AIがブラウザを操作するには、パソコンの前に座っていないといけない。
考えてみれば当然で、この装置は所長のログイン済みブラウザを動かしている。所長がパソコンを開き、画面を見て、AIが操作するのを待っている必要がある。
「押すボタンだけ残す」設計にしたつもりだった。ところが実際に残っていたのは、ボタンを押す指ではなく、パソコンの前に座っている時間だった。
これでは楽になっていない。
ただ、この装置には続きがある。やりたかったことを別の形で作り直した。
サイトの管理画面の中に「宣伝室」という部屋を作った。
何を宣伝するか選ぶ（サイト全体、最新の記事、過去から発掘、など）。画像を選ぶ。文章を整える。最後に共有ボタンを押す。
肝心なのは最後の一歩である。ブラウザを操作するのをやめて、Xアプリへ画像つきで渡す形にした。
これだと、パソコンの前に座っている必要がない。装置の役目は「投稿画面を作ってやること」ではなく、「渡せる状態のものを用意すること」になった。投稿ボタンを押すのは所長のまま、という設計はそのまま残っている。
こちらは動いている。14回使われていて、直近は今日だ（この記事の前に公開した3Dテクスチャの研究ログを宣伝するのに使った）。
予約投稿の装置は、死んだのではなく乗り換えられた。
死んだ2個は、同じ形で死んでいた
どちらも完成して、仕様どおりに動いた。そして、手間が減っていなかった。
収穫機は撮ってきた。ただし欲しい絵ではなかった。
予約投稿は画面をセットした。ただしパソコンの前に座る必要が残った。
壊れたのではない。「これがあれば楽になる」という見込みが外れていた。
生きた2個との違いも、これで見える。
生きた2個は、時刻が来たら勝手に動く。
死んだ2個は、所長がその場にいないと動かない。
所長がその場にいる装置は、一度「楽になっていないな」と思われた瞬間に二度目が来ない。逆に勝手に動く装置は、役に立っているかを毎回問われない。
開かない・更新しない・忘れるを前提に設計したつもりだったのに、作った装置の半分は、結局所長がその場にいることを前提にしていた。
定着したのは、装置ではなかった
ところで、この3週間で明らかに定着したものが一つある。装置ではない。
判断が必要なことを、1ファイル＝○×1個の形にして積む。AIはセッションの最初に「未処理が何件」と一言だけ添え、あとは1件ずつチャットへ差し出す。所長はファイルを開かない。
数えてみたら、計画前は0件、それ以降は35件あった。
計画では「毎朝チャットへ届ける装置」を作るつもりだった。押しつけて届ける仕組みである。それは結局まだ作っていない。代わりに残ったのは、所長がやって来たときに1件だけ差し出すという運用だった。
判定は、とっくに終わっていた
「2週間使われなかった装置は止める」と書いたのに、死んだ2個は3週間を超えて放置されていた。止められていない。
装置が判定してくれないからだ——と、この記事を書き始めたときは思っていた。
ところが、記録を数えている途中で所長がこう言った。
実はもう頭の中で評価していて、それをAIに伝えるのを忘れていた。どのスクリーンショットもゲームの最初の画面しか撮ってこないので、僕が欲しいプレイしている場面が全く取れなくて。これじゃ使い物にならないな、と思った記憶が蘇ってきた。
判定は下りていたのである。 3週間前に。ただ、それが所長の頭の中で終わっていた。
だから装置は「まだ様子見の装置」として置かれ続けた。実際は死んでいたのに、死亡が記録されていなかった。
ここで、前提条件を書き漏らしていたことに気づく。
開かない。更新しない。忘れる。撮らない。——この四つを仕様にしたはずだった。
五つめがあった。思ったことを、言わない。
正確には、思った瞬間には言うつもりで、そのまま忘れる。判断はしているのに、装置の側へ届かない。撤退基準が動かなかったのは判定する装置がなかったからではなく、判定はもう出ていて、受け取る口がなかったからである。
次に作るなら
外れ方には形があった。時刻が来たら勝手に動くものは残り、所長がその場にいないと動かないものは残らない。 そして仕様どおりに働いても、手間が減っていない装置は2回で終わる。
止まった装置を捨てる必要はない。予約投稿は、手間の在り処を変えて作り直したら動いた。考え方が間違っていたのではなく、置き場所が間違っていただけということがある。
あとは「使えないと思った」を受け取る口を、どこかに開けておかないといけない。
ちなみに3週間前の判定が出てきたのは、この研究ログを書くために装置を数え始めたからである。記録を書く作業が、記録されていなかった判断を引きずり出した。
いちばん安い装置は、記事を書くことだったのかもしれない。
当ラボは今後も、所長の怠惰を極めて真面目に支援する。（Dr.よこぼ）