やっていること
本業は音楽まわりの仕事をしている、その辺のADHDの社長です。ただ最近は、本業そっちのけで自作AIアシスタント「Jarvis」の開発と運用に時間を使っています。「音楽会社の人間のはずなのに、今日も開発しかしてない」が実態です。
この記事では、Jarvis を「実際に毎日回る形」にするために組んだ構成と、運用してみて分かったことを書きます。派手な話ではなく、運用の実務の話です。
欲しかったもの（要件）
市販のAIアシスタントが自分の環境（Windows・日本語・自分の業務フロー）に合わなかったので、要件は自分の日常から決めました。
- 朝いちばんに、その日の予定とやるべき処理が日本語でまとまって届く
- 夜に、その日の進捗が整理されている
- 決まった時刻に、決まった定型作業が自動で回る
- 失敗したら、失敗したことが分かる
- 止めたい時に止められる
構成
大枠は「考える役」と「実行する役」の分担です。
| 役 | 担当 |
|---|---|
| 考える役 | 予定・進捗の把握、朝の報告と夜の整理の作成、優先順位の叩き台 |
| 実行する役 | 時刻駆動の定型処理、PC上のファイル操作、結果ログの返却 |
受け渡しはファイル経由です。考える役がタスクをファイルに書き、実行する役が読んで処理し、結果をファイルで返します。連携の形としては地味ですが、途中経過が全部ログに残るので、後から「何が起きたか」を追えるのが運用では効きます。
タスクファイルに書く項目は、運用の中でこの形に落ち着きました。
- 処理の名前と目的
- 入力の置き場所（対象ファイル・データ）
- 出力先（結果ファイルの場所）
- 完了条件と、失敗した時に残す情報
項目が欠けたタスクは、実行側が不足分を推測で埋めるため、結果が回ごとに揺れます。揺れる実行の原因を追うと、たいていは実行側の賢さではなく、渡す側の書き方の曖昧さでした。受け渡しの形式を固定することは、派手さはないものの、安定性への効き目は一番大きかった部類です。
なお、考える役に返すのは結果とログだけにしています。処理の途中経過の重いデータを考える側へ全部戻すと、報告を作る側まで重くなる。境界をファイルに置くと、この切り分けが自然にできます。
運用で分かったこと
定型作業は「考えさせない」ほうが安定する
実行側に判断を持たせると、同じ作業でも毎回微妙に結果が変わります。定型処理は手順を固定して、入力と出力を決めてしまう。判断が要る部分だけを考える役に寄せたほうが、全体が安定しました。
失敗検知は先に作る
自動化は「成功した時」より「失敗した時にどう分かるか」で運用が決まります。処理ごとに結果ログを残し、失敗したら表に出る形にしておく。これを後付けにすると、静かに壊れた自動化が量産されます（実体験です）。
静かに壊れるパターンは、だいたい決まっています。例えば、処理自体は最後まで走った顔をしているのに、結果ファイルが空のまま残っている。あるいは、前日の結果が上書きされずに残っていて、新しい結果と見分けがつかない。どちらも「動いているように見える」のが厄介なところです。
対策として意識しているのは、成功の記録と失敗の記録を同じ場所に並べて残すこと、そして「結果がない状態」を異常として扱えるようにすることです。失敗したら通知、成功したら無言、という作りにすると、無言が「成功」なのか「そもそも動いていない」なのか区別がつかなくなる。運用の初期に一番時間を溶かしたのは、この切り分けでした。
小さく始めて、毎日回して直す
もう一つ、運用で固まった進め方があります。最初から全部を自動化しようとせず、朝の報告なら朝の報告だけ、というように一つの部品を毎日回る状態まで持っていってから次に進むことです。
毎日回すと、弱い所が必ず表に出ます。出た所を一つ直して、また回す。この繰り返しのほうが、まとめて作り込んでから一気に動かすより、結果的に安定するまでの道のりが短かった。詰まった所と抜け方をその都度記録に残す習慣も、この回し方とセットで効いています。記録があると、次に似た部品を作る時に、最初から失敗しにくい形で始められるからです。
記録が次の開発の素材になる
詰まった所と、どう抜けたかは全部記録に残しています。この記録があると、次の自動化を作る時に同じ失敗を繰り返さないし、こういう記事の形で外に出す材料にもなる。「まず動かす→詰まる→仕組みを掘る→手順を記録する」が自分の開発の型になっています。
まとめ
- 要件は自分の日常から決める
- 構成は「考える役／実行する役」の分担
- 受け渡しはファイル経由で、ログを残す
- 定型作業は考えさせない、失敗検知は先に作る
同じように「自分のための自動化」を組んでいる方の参考になればうれしいです。