はじめに ― 一人開発の本当の弱点
45年この仕事をやってきて、腕で困った記憶はあまりない。回路も、ファームも、納期も、たいていはなんとかしてきた。困っていたのは、もっと地味なことだ。
管理である。
バックアップは取っている「つもり」だった。出荷したファームは合っている「はず」だった。旧機種の資料はどこかにある「と思う」。――一人でやっていると、この「つもり」を検査する部門がない。作る手はあっても、毎日点検する手が物理的に無いのだ。
前回(第6回)は、AIが自分でオシロスコープを操って測定する「実験室」を作った話を書いた。今回はその続きで、この一週間でいちばん効いたことを書く。派手な開発ではない。AIは、私の一人工場に品質管理部門を付けてくれたという話だ。
監視されていないバックアップは、無いのと同じ
私のバックアップは我流だが理屈がある。作業ドライブを毎日、2台のドライブへ交互に写す。毎日両方に写すと、元データの異常(消し間違い、破損)を両方の世代に忠実にコピーしてしまう。交互なら、必ずどちらかに「昨日より前の無事な世代」が残る。何十年かでたどり着いた世代管理だ。
ただし、この運用には監視が無かった。「昨日ちゃんと写したか」を確かめるのは自分の記憶だけ。
AIに鮮度確認ツールを作らせた。各ドライブの最新更新時刻を毎晩比べて、一行で報告するだけの小さなものだ。初日の報告が、これである(実物)。
ALERT E->F: tool_cs 62h前 | ALERT E->F: Ws 76h前
ALERT E->F: Work 62.4h前 | ALERT E->F: Wsd 66.2h前
OK E->V: tool_cs 14.9h前 | OK E->V: Ws 15h前
(参考) UEプロジェクト->W: 793.6h前
初日から、上司より厳しい。要点は2つだった。
- 片翼のドライブが62〜76時間止まっていた(これは交互運用の想定内と後で判明)
- UEプロジェクトの控えが793時間=33日前で止まっていた(週次のつもりが、実際は1ヶ月放置)
さらにAIはWindowsのイベントログを90日さかのぼり、45日前に約70分間、1万787件のディスクエラーと1,601件の書き込み損失が発生していたことを掘り出した。持ち出し用ドライブが電力不足で暴れた事故だ。当時の私は「なんか不安定だな」と思ってケーブルを抜いただけだった。
ここからが品質管理部門の仕事である。AIは損失イベントに記録された970件のファイルパスを抽出し、作業正本と1件ずつ機械照合した。結論、実データの損失はゼロ。壊れて見えたファイルは全て、古いバックアップの構造差や使い捨てのビルド生成物だった。45日間気づかず抱えていた傷が、発見から「実害なし」の確定まで半日で閉じた。
機械は必ず日記をつけている。読む係さえいれば、傷は45日後でも見つかり、閉じられる。
ひとつ白状すると、このツールは最初、交互運用を知らずに「バックアップが古い!」と警報を出した。私が「それはわざとだ」と説明すると、判定ロジックは「新しい方が36時間以内、古い方が96時間以内なら健全」という交代制対応に書き直された。直した後の報告がこれだ。
tool_cs: 新V:15.6h/古F:62.8h OK | Ws: 新V:15h/古F:76.3h OK
Work: 新V:14h/古F:62.4h OK | Wsd: 新V:22.4h/古F:66.2h OK
同じドライブ、同じ時刻差で、ALERTがOKに変わった。数字が変わったのではない。ツールがうちの運用を理解したのだ。運用の知恵は人間が教える。毎晩の根気は機械が持つ。この分担がちょうどいい。
いまはこの確認が管理パネルに育ち、「繋ぐ→ボタン一つで交互バックアップ→履歴表示」まで一体になっている。ドライブの健康状態(SMART・温度)も常時監視だ。
バックアップ管理パネルの鮮度確認ツール、実際の出力。各作業ドライブの更新時刻差を毎晩自動チェックする。
ドライブ健康監視の実データ(PowerShellでの実測)。SSD/HDDの状態を横断で確認する仕組みも常時稼働している。
出荷ビルドを1バイトも汚さない
検証を自動化するために、製品ファームに「テストモード」を仕込んだ。画面の自動減光を止め、USB経由でボタン操作を注入できるようにする――AIが実機を操作して検証するための改造だ。
こういう改造でいちばん怖いのは、機能ではなく管理である。テスト用のコードが出荷版に紛れ込む事故は、一人開発の古典だ。今回AIに課した受入条件はひとつ。テストモード無効でビルドしたhexファイルが、改造前とバイト単位で一致すること。
AIは実際に、ベンダーライブラリの中にガードの漏れを見つけて自分で塞ぎ、一致を検証してから「完了」と報告してきた。ついでに、書き込みスクリプトのログが何年も空だった潜在バグ(書き込みツールがGUIアプリで、リダイレクトでは出力を捕捉できない)まで発見して直した。
テストモードで動いている実機は、画面に[TESTRIG]と名乗る。出荷版と見分けが付かない、という事故を目でも防ぐためだ。
実機LCD画面のイメージ(SW16LCD Webシミュレーター画面)。実機では稼働モードがバージョン表示欄に出て、テストモード中は[TESTRIG]と表示され出荷版と区別できる。
「テストの都合で出荷版が変わる」という事故が、仕組みとして起きにくくなった。
AIの管理は、AIにもかける
面白い対称性がある。AIが私の管理部門になったのと同時に、AI自身も管理される側になった。
うちでは複数のAIが分業している(段取り役が1、実装役が4)。彼らの引き継ぎは会話ではなく指示書で行い、結果は必ず文書の「結果欄」に書かせる。やった事だけでなくやらなかった事とその理由も書かせる。文書と実態が食い違ったら、作業より先に文書を直させる。
権限も絞ってある。「読むだけ」のコマンドは素通し、「変える・消す」コマンドは必ず止まる。実装した本人に採点させず、検査役を別に立てる。――これは全部、工場で人間にやってきた管理と同じである。AIは思い込みで走ることがある(第5回で書いた通りだ)。だからこそ、AIの仕事もAIと人間で検査する。
むすび ― 職人に、品質管理部門が付いた
自分でプログラムを組むと、管理の仕組みづくりはどうしても後回しになる。面倒だからだ。AIが来て、その面倒な部分が確実に回るようになった。私はこれが最大の利点だと思っている。多少面倒でも、管理はやるべきなのだ――やってくれる係さえいれば。
AIは職人の代わりではなかった。職人に品質管理部門が付いた。腕は45年分ある。無かったのは、面倒がらずに毎晩点検する係だった。70歳を前にして、うちはようやく「管理の行き届いた一人工場」になった。
疑わしいのはいつも配線と設定――45年変わらぬ結論だが、いまはそれを毎晩黙って点検してくれる相棒がいる。そういう話である。
ここまでは、うちの中を「守る」管理の話だった。次回は、出荷した後の話をする。2つの世代が併存する製品、現場で慌てないためのファイルの焼き方、そして配布物の中に「AIが保守できる道」を開くという、これからの試みについて。
→第8回「出荷したら終わりではない」を読む
*(付記: 連載第1〜4回は技術編、第5回は協働記、第6回は計測環境の作り方。本稿のバックアップ監視・検証ファームの実装記録は、いずれも作業当日にAIが書き残した文書が一次資料になっている――それ自体が本稿の主張の実例である)*