投稿者: yukihiro

私は、仕事と生活をRPGに見立てて記録している。
毎日の行動に経験値（EXP）を付け、たまった分でレベルが上がる。
この連載（冒険手帳）は、その1日分の記録だ。
作業の多くは、AIの Claude と進めている。
冒険手帳を書いた翌日には、同じ話を YouTube ショート（縦長の短い動画）にする。ナレーションの台本も、Claude と書く。
書いた台本は、もう一つ別のAI（Google の Gemini）に読ませる。冒険手帳の本文も、元の記録も渡さない。台本だけを読む、初めての視聴者の代わりだ。以下、このAIを「読み手役」と書く。
読み手役は、毎回同じ5つの問いに答える。
最後まで意味が分からなかった語。誰のことか分からなかった文。何が起きているのか思い浮かばなかった箇所。知らないと繋がらない前提。
そして5つ目が、「読んでいる途中で『もう分かった』と感じた文」。
ショートは、指一本で次の動画へ送られる。「もう分かった」と思われた文が、視聴者が見るのをやめる場所になる。
10月9日に台本にしたのは、前日の冒険手帳の話だった。
私は、港区の会場で、月に2回ほど職場の整理整頓の研修の講師をしている。
私の会社（経営の相談や研修を引き受けている）のサイトの、直近84日間の訪問を地名で分けると、研修のあった9月9日にだけ、八王子市から7人が来ていた。84日間で、八王子はこの日だけだ。
サイトの訪問を数える仕組み（アクセス解析）は、訪問の地名を、使われた回線から推定する。研修の会場で、受講生がサイトを開き、その会場のWi-Fiが八王子と判定された。そう見るのが自然だ。
研修のたびに八王子が出るわけではない。研修中にサイトを紹介しない回もある。別の研修日（7月27日）に人が固まっていたのは、八王子ではなく千代田区（4人）だった。
港区の教室にいた受講生が、地図の上では八王子にいた。
台本の字数には、目安がある（このときは、およそ330字。動画を長くしすぎないための物差しだ）。初稿は468字で、目安の1.4倍あった。
私がいちばん気に入っていたのは、冒頭の一行だった。
「港区の教室にいた人が、地図では八王子にいた」。
最初に聞くと、意味の分からない謎だ。私は、Wi-Fi の判定を説明し終えたところに、この一行をもう一度置いていた。説明を聞いた後なら、同じ一行が、謎の答えとして読める。謎が答えになって戻ってくる。うまくいったと思っていた。
その後ろには、2つの部分を続けていた。手元の研修の予定表と重ねなければ、この7人が受講生だとは分からなかったという話。そして、受講生の訪問をどう数えるかという私の判断だ。
読み手役は、もう一度置いたその一行を、5つ目の問いの答えに挙げた。
読み手役の理由は、こうだった。謎の答えがここで出て完結したので、その後の話は読む必要がない。ここで動画を止めてもいい。
台本を直しては読ませる、を繰り返した最初の数周で、同じ指摘が3回出た。
説明を足せば、引き留められるか。
足しても、答えが出た後の説明は、答えの続きにしかならない。視聴者はもう、答えを持っている。
3回目の指摘を受けて、私は、もう一度置いていた一行を消した。
代わりに、Wi-Fi の判定を説明した直後に、問いを1つ置いた。
「では、訪問数に、この7人を入れるか。」
台本はその問いに、後ろの2つ目の部分（訪問をどう数えるかの判断）で、私の答えを返す。答えは、入れたまま割り引いて読む、だ。
私が知りたいのは、検索などで自分からサイトを探して来た人の数だ。受講生の訪問は、毎回どこかの地名に固まって出るとは限らない。全体の訪問数から受講生の分を引こうとしても、抜き出しきれない分が残る。残りを「自分から探して来た人」とは言い切れない。だから、記録から受講生の分を抜き出す作業はしない。
代わりに、読み方を決めた。訪問数の記録は書き換えない。研修の日と、その翌日（見直す受講生もいるかもしれない）に訪問が増えていたら、その増えた分は受講生かもしれないと控えめに受け取り、検索で来た人が増えた証拠には数えない。
一行を消した後、5周目からは、読み手役が「もう分かった」と挙げる文が、台本の最後の数行へ移った。
最後まで見た人が、見終わったと感じる。それは、正しい場所だ。
直しては読ませる、を11周回した。
読み手役の指摘のうち、本当に台本を直す必要があったもの（以下、欠陥）は21件。「この人の会社は何の会社か」のように、この短さでは説明しきれない指摘もある。そうした種類は、1周目のうちに「直さないもの」として決めておき、以後は件数を数えるだけにした。
最後の2周は、新しい欠陥が0件だった。台本は429字、目安の1.3倍まで縮めたところで、声と映像を付ける工程へ回した。目安は超えたままだが、仕上がった動画を試写で見て、この長さでよいと私が決めた。
ゲームでは、クエストを1つ終えると、報酬の画面のすぐ後に、次の目的地の印が地図に出る。
終わった瞬間に、次の行き先が見える。だからプレイヤーは、そこでコントローラーを置かない。
台本に置いた問いが、この印にあたる。答えを受け取った視聴者に、次の行き先を見せる。だから、そこで動画を止めない。
答えは、話の終わりではない。
答えの次に、問いを置く。
—

私は、仕事と生活をRPGに見立てて記録している。
毎日の行動に経験値（EXP）を付け、たまった分でレベルが上がる。
この連載（冒険手帳）は、その1日分の記録だ。
作業の多くは、AIの Claude と進めている。同じ Claude を2つのアプリで使い分けていて、一方はファイルの書き換えやサイトの更新を受け持つ役、もう一方（Cowork：Claude Desktop の相棒）は調べ物や分析を受け持つ役だ。
私の会社のサイトには、訪問者の数を数える仕組み（アクセス解析）が入っている。
本来は毎週見る決まりだが、7週間止まっていた。
10月8日、Coworkに頼んで、止まっていた7週を含む直近84日（12週）分をまとめて見た。
最初に目についたのは「直接流入」だった。
直接流入とは、検索やSNSのリンクを通らずに来た訪問のことだ。ブックマークやURLの直打ちがここに入る。どこから来たかが分からない訪問の、置き場でもある。
会社のサイトでは、84日間の訪問402件のうち、3分の2がこれだった。
しかも、ページにいた時間は平均4秒。読んでいるとは言いにくい。
Coworkの最初の見立ては、こうだった。
9月24日に、私は作業用のパソコンを新しくした。私が自分のサイトをブックマークから開くと、直接流入に入る。自分の訪問を数から外す設定が、そのとき外れたのではないか。
私は返した。外す設定は、家の回線の住所（IPアドレス）で決めている。住所は回線ごとに決まっていて、パソコンを替えても変わらない。
見立ては、撤回になった。
Coworkは、直接流入を地名で分け直した。
アクセス解析は、訪問の回線がどの地域のものかを推定して記録している。推定は回線会社の設備の場所などから割り出すので、実際の場所とずれることがある。
多かったのは、東京の港区53件と新宿区35件。
アメリカの大きなデータセンター（ネットの会社がサーバーを大量に置く施設）がある町の名前も並んでいた。こちらは、人ではなく、自動で巡回するプログラム（ボット）の典型だ。
港区と新宿区も滞在の短い訪問が多かったので、Coworkはこの2つもボットだと書いた。
私には、心当たりがあった。
港区の会場で、私は月に2回ほど、職場の整理整頓の研修（5S研修）をしている。
Coworkは、港区と新宿区をもう一度見直した。
港区は、84日のうち38日に、1人から3人ずつ。毎日少しずつ来ている。
アクセス解析には、10秒以上とどまる、2ページ以上見るなどした訪問を「関心を持って見た訪問」として数える物差しがある。その割合が、港区は35%、新宿区は44%。
データセンターの町からの訪問は、この割合がほぼ0%だ。
港区と新宿区の3割から4割は、人が見ている。
ボットと断定するのは、強すぎた。2つの区は「人と自動の混在」と読み直した。
平均4秒という数字も、ボットと人が混ざった平均だったことになる。
それなら、研修の日と重ねればいい。
私は、7月から9月までの研修日を6回分、Coworkに渡した。
いちばんはっきり出たのは、9月9日だった。
会場は港区だ。なのに、その日に固まって出た地名は、八王子市だった。
八王子から訪れた人が7人。7人とも、関心を持って見た訪問だった。
84日間で八王子から訪れた人は、この7人しかいない。全部、研修の日に集まっていた。
7月27日の研修日にも、似た形が出た。この日は、千代田区に4人が固まっていた。
どちらも、研修の日だけ、ふだんは出ない地名に、人がまとまって現れている。
会場で何人もが同じ回線（たとえば会場のWi-Fi）からサイトを開き、その回線が、住所の推定で別の地名と判定された。そう見るのが自然だ。
港区の会場にいた人たちが、地図の上では八王子にいた。
9月9日の翌日には、港区から訪れた人が6人に増えた。受講した人の職場が港区の近くにあれば、見直した分かもしれない。そこまでは、数字から言い切れない。
正体の分からない訪問の中に、研修の受講生が混ざっていた。
数字の向こうに、教室があった。
ゲームのレーダーには、近くにいるものが点で映る。
点だけでは、敵か味方か分からない。
見分けられるのは、味方がどこにいるかを知っているプレイヤー自身だ。
ここでの味方は受講生で、見分けたかった相手はボットだった。
Coworkが見ていたのは、点だけだった。私の予定表は、Coworkの手元に無かった。
最後に、私はもう一つ決めた。
受講生の訪問は、追いかけない。
研修中に私がサイトを紹介する回もあれば、しない回もある。受講する人数も、2人から30人を超える回まで振れる。
これを数え分けても、検索などで自分からサイトを探して来た人の数は分からない。
だから、会社のサイトの訪問数の増減を見るときは、研修の日とその翌日の増え方を差し引いて考える。それだけにした。
見分けがついたうえで、数えないと決める。
レーダーの点を全部追うのが、強いプレイヤーではない。
—

私は、仕事と生活をRPGに見立てて記録している。
毎日の行動に経験値（EXP）を付け、たまった分でレベルが上がる。
この連載（冒険手帳）は、その1日分の記録だ。
作業の多くは、AIの相棒（Claude）と進めている。
もう一つ、別のアプリで動くAI（Cowork）もいる。こちらは手を動かす役ではなく、作業全体の進み具合を見渡して、気づいたことを私あての依頼書にまとめる相談役だ。
私の会社のサイトには、見張り番がいる。
決まった曜日の夕方に自動で動く点検の処理（定期タスク）で、全部で3本ある。サイトの安全と表示の崩れを見る1本、検索向けの構造を見る1本、ブランド名の載り方を見る1本だ。点検日は、安全と表示の1本が火曜と金曜、ブランド名の1本が火曜、検索向けの1本が水曜。合わせて週に4回だ。
見張り番は、走るとまず「いつ動いたか」を書いた実行記録を1本残す。この記録は、走ったパソコンの中にだけ残る。
そのうえで、異常を見つけたときだけ、私とAIが毎日見る作業の一覧（進行表）に警告を書き込む。
警告が無ければ、無事ということになっている。
9月24日、私は作業用のパソコンを2台にした。
新しいほうを本拠地にして、決まった時刻に動く処理はすべてそちらへ移し、古いパソコンの側は止めた。
新しいパソコンには、3本が決まった時刻に自動で動くよう設定した。これを「登録」と呼んでいる。
どの処理をどちらのパソコンで動かすかをまとめた一覧（移行の台帳）には、見張り番の3本も「登録済み」と書いた。
それから2週間、進行表に警告は1度も出なかった。
10月7日（水曜日）の朝、相談役が依頼書を上げてきた。
相談役が見たのは、警告ではなく、実行記録があるかどうかだった。
新しいパソコンに、見張り番の実行記録が1本も無い。
9月24日から、点検は1度も走っていなかった。
9月25日から10月6日までに、見送られた点検日は7回。最後に点検が走った9月22日から数えて、監視の空白は15日になっていた。
実は相談役は、9月27日と10月2日にも、同じ空白を依頼書で知らせていた。
2回とも、進行表に載ったまま、手が付かずに残っていた。
なぜ後回しにしたのか、手元の記録に理由は残っていない。
確かなのは、見張り番の側からは、何も届かなかったことだ。
相談役の見立ては、起動の許可設定だった。
パソコンが、手順を書いたファイルの実行を許すかどうかの設定だ。
3本が同時に、痕跡を残さず止まる。症状とは合っていた。
調べると、外れていた。
起動に使うプログラム（PowerShell）には、Windowsに最初から入っている古い版と、あとから入れる新しい版がある。
3本はどれも、新しい版を、古いパソコンでの置き場所で呼んでいた。
新しいパソコンでは、新しい版が別の場所に入っている。
呼んだ先に、何も無い。
見張り番は、実行記録を書く一歩手前で止まっていた。
そして、止まったことを知らせる係も、見張り番自身だった。
直し方は、呼び先を、どのWindowsにも入っている古い版のほうへ替えることにした。
試しに走らせると、今度は、見張り番を起動する手順を書いたファイルの1行目で落ちた。
古い版は、日本語のWindowsでは、ファイルの先頭に文字コードの目印（BOM：先頭に置く3バイトの印）が無いと、日本語を別の文字コードとして読んでしまう。読み違えた文字は命令として通らず、そこで止まる。
切り替えを選ぶとき、Claude は「古い版でも動く書き方です」と私に説明していた。
書き方は確かめていた。文字コードは確かめていなかった。Claude は、その説明が誤りだったと私に伝え直した。
起動の手順を書いたファイルは2本ある。安全と表示の1本が使うものと、残る2本が共用するものだ。その2本の先頭に目印を付けて、ようやく走った。
その日の昼、点検日が来ていない2本を手で走らせ、新しいパソコンで初めての実行記録ができた。
安全の点検は、24項目すべて合格だった。
夕方5時には、水曜が点検日の残る1本が、定時のとおりひとりでに動いて完走した。
ここで考えた。
警告が出ないことを、私は「無事」と読んでいた。
だが、警告を書けるのは、走った見張り番だけだ。
走っていなければ、無事と同じ顔をする。
静かなのは、無事の証拠ではなかった。
ゲームなら、クエストを受けたことと、クリアしたことは、別の印で表示される。
受けただけのクエストに、クリアの印は付かない。
台帳の「登録済み」は、受けた印でしかなかった。
クリアの印にあたるのは、実際に走ったという記録のほうだ。
そこで、安全の点検には、走るたびに1行ずつ増える履歴を足した。実行記録と違い、こちらは2台で共有する。
実行した日、どちらのパソコンか、点検した数、異常の数。
異常が無くても、1行増える。
履歴は、2台のパソコンが同じ中身を取り込むファイルの置き場（GitHub）に入る。どちらのパソコンからでも、最後の行の日付を見れば、最後にいつ走ったかが分かる。
残る2本は、もともと同じ形の履歴を持っていた。無かったのは、安全の点検だけだった。ただ、その日付を決まって見る習慣も無かった。
これからは、警告が無いことではなく、最後の行の日付で、無事を確かめる。
パソコンを2台にしたときに作った移行の手順書にも、1行書き足した。
登録したら、1回手で走らせて、実行記録が出るのを見る。
—

私は、仕事と生活をRPGに見立てて記録している。
毎日の行動に経験値（EXP）を付け、たまった分でレベルが上がる。
この連載（冒険手帳）は、その1日分の記録だ。
経験値は、行動ごとの点数表で決まる。
運動なら、30分以上で25。15〜30分で15。15分未満で5。しなければ0。数字は、その日に付く経験値だ。
物差しは、時間（分）だ。
ところが私は、毎日の聞き取り（1日の行動を入力するフォーム）に、運動を歩数で書いてきた。
「ウォーキング7,630歩」のように。
点数表は分で話し、記録は歩数で話す。
「何歩なら何分とみなす」という換算の一行が、点数表に無かった。
採点するのは、相棒のAI（Claude）だ。
一行が無いので、相棒は採点のたびに、その場で決めていた。
同じ5,800歩台でも、ある日は25、別の日は5。
直近では、7,630歩の日も10,656歩の日も0だった。時間の書かれていない運動として、数えなかったからだ。
前日の回で、私はこの食い違いを書き、どう直すかを決めるのは点数表を作った私で、まだ決めていない、と書いた。
10月6日の朝、決めた。
きっかけは、私の一言だった。
「歩数と運動時間など、いくらでも計算できるだろう。Webにもデータがある」
相棒は、公的な目安を探してきた。
厚生労働省の身体活動の目安では、10分の歩行をおよそ1,000歩としている。
相棒は、それをそのまま点数表に足した。
1,000歩で10分。
3,000歩以上なら30分以上とみなして、25。
筋は通っている。
ただ、読んで引っかかった。
家の中を歩く。駅まで歩く。階段を上る。
運動しようと思わなくても、歩数計は勝手に進む。
その歩数まで、運動として数えていいのか。
私は相棒に、こう返した。
「1,000歩で10分、それでいい。ただし、日常生活の歩行は運動とは言えない。3,000歩より先を運動とする。6,000歩を超えたら25」
3,000歩は、運動しようと思わなくても日々の暮らしで歩く分として、私が引いた線だ。
点数表は、こう変わった。
最初の3,000歩は数えない。
3,001歩目から、1,000歩を10分とみなす。
歩いた総数でいえば、3,000歩までは0。4,500歩未満なら5。4,500〜6,000歩なら15。6,000歩を超えたら25。
ちょうど6,000歩（30分）は15になる。点数表の「30分以上」とは1歩ぶん食い違うが、境目は私の「超えたら」に合わせた。
換算のしかたは、相棒の案のままだ。
変わったのは、数え始める位置だけだ。
それだけで、同じ日の点数が変わる。
10月6日、私は5,905歩、歩いた。翌朝の聞き取りに、その歩数を書いた。
相棒の最初の表なら、25。
直した表では、最初の3,000歩を除いた2,905歩、約29分で、15。
歩いた全部が、運動ではない。
決まりを作るとき、つい「どう換算するか」に目が行く。
その前に、「どこから数えるか」がある。
そこは、計算では決まらない。
何を運動と呼ぶかは、点数表を使う本人が決めることだ。
新しい表は、10月6日の記録から使う。
すでに記事にした7,630歩の日と10,656歩の日は、新しい表ならどちらも25だった。それでも0のまま直さない。どちらも、すでに公開した記事だからだ。
この記事が、新しい表で採点した最初の1日になる。
—

私は、仕事と生活をRPGに見立てて記録している。
毎日の行動に経験値（EXP）を付け、たまった分でレベルが上がる。
この連載（冒険手帳）は、その1日分の記録で、毎日1本ずつ書いている。
経験値の付け方は、行動ごとの点数表に決めてある。
運動なら、30分以上で25。15〜30分で15。15分未満で5。しなければ0。
物差しは、時間（分）だ。
ところが、私が毎日の聞き取り（1日の行動を入力するフォーム）の「運動」の欄に書いてきたのは、時間ではなかった。
「ウォーキング5,713歩」。
歩数計の数字を、そのまま書いていた。
採点は、相棒のAI（Claude）がする。聞き取りの内容を点数表に当てて、経験値を付ける。
点数表は分で話し、記録は歩数で話す。
「何歩なら何分とみなす」という換算の一行は、点数表のどこにも無い。
相棒は、この連載をもとに、縦型の短い動画（ショート）も毎日つくっている。
10月5日、その題材を探していて、この連載の過去の記事を数えた。
公開済みの記事のうち、運動の欄が歩数だけの日は112日あった。
付いた経験値は、25が109日。5が2日。0が1日。
並べると、こうなる。
6月8日、5,854歩で5。
6月12日、5,870歩で25。
9月9日、5,713歩で25。
10月4日、7,630歩で0。
この4日のうち、いちばん多く歩いた日が、いちばん低い。
なぜ0になったのか。
その前日の10月3日、私は運動の欄に「なし」と入れていた。歩数計の数字（6,780歩）は、別の欄に入れただけだった。
「なし」なら0。点数表どおりだ。
翌日、私は運動の欄に「ウォーキング7,630歩」と書いた。
相棒はそれを、前日と同じく「時間の書かれていない運動」として0にした。
相棒が点数表を読み違えたわけではない。
点数表には、歩数をどう扱うかが書いていない。
書いていないから、採点のたびに、その場で決めるしかなかった。
109回は30分以上とみなし、2回は15分未満とみなし、10月4日の1回は前日にそろえた。
点数表に無い一行は、採点する側が毎回その場で書き足している。
ゲームでいえば、経験値表は「戦った時間」で書いてあるのに、戦闘の記録は「倒した敵の数」で残っているようなものだ。
「戦った時間」が運動の分、「倒した敵の数」が歩数にあたる。
どちらの記録も嘘ではない。
単位が食い違っているだけで、同じくらい歩いた日に付く点がぶれる。
その日、相棒はこの件をショートにして公開した。題は「7,630歩歩いて0点／5,713歩の日は25点」。
動画の最後は、相棒の意見として「直すのは決まりのほう」（点数表のほう）で締めた。
ただ、直し方は二つある。
点数表に換算の一行を足すか。
記録のほうを、時間で書くか。
どちらにするかは、点数表を作った私が決めることだ。まだ決めていない。
10月5日、私は10,656歩、歩いた。聞き取りには、やはり歩数だけを書いた。
この記事の運動の経験値は、0だ。
換算を決めるまで、0のまま置いてある。
—

縦型の短い動画（ショート）を、毎日1本つくっている。
制作は、相棒のAI（Claude）と組んで進める。
ナレーションは、音声合成ソフトの声で読ませる。
この声は、ときどきアクセントを間違える。
高く読むべき音を低く読んだり、低く始めるべき言葉を高く始めたりする。
間違えた箇所は、「経験値の」のような、語と助詞（「の」「を」「に」など）のひとかたまりで直す。
以下、このひとかたまりを「句」と呼ぶ。
私が耳で聴いて、おかしい句を1つずつ相棒に直させてきた。
直した結果は、捨てずに残している。
「この句は、この高さで読ませる」という記録の束だ。
発音の台帳（直したアクセントの記録帳）と呼んでいる。
合成の前には、台帳を自動で当てるプログラム（以下、道具）が動く。
台本の中に台帳と同じ句があれば、記録した高さをそのまま設定する。
過去に直した句は、二度と間違えない。
——そのはずだった。
10月4日。
相棒が、この冒険手帳（日々の仕事を1日1話で記録しているこの連載）の100日目の記事を題材にした動画を仕上げ、確認用の試写が私に届いた。
聴いて、すぐに引っかかった。
「アクセントがおかしいものが多い。台帳との照合した？」
台帳を当てる道具は、確かに実行されていた。
それでも、おかしい句が並んでいた。
調べると、原因は道具の探し方にあった。
道具は、台帳の句と「一文字残らず同じ形」のときだけ当てる。
台帳に「経験値を」と残っていても、台本が「経験値の」なら、前例なしと判定する。
違うのは、後ろに付いた助詞の一文字だけ。
語そのものの高さの付け方は、同じなのに。
この日すり抜けた句のうち、「経験値の」「経験値と」「毎日の」は、台帳に「経験値を」「毎日を」といった別の形で、直した高さがもう載っていた。
実は、これが初めてではない。
9月12日、「業（ギョウ）」という語で同じことが起きた。台帳に別の助詞の形で載っていたのに、道具が拾わず、間違えたまま試写に出た。
そのとき、相棒が毎回読む手順書（作業の手順を書いた文書）に一行足した。
「助詞違いは同じ前例として扱う」。
9月14日、「機械」という語で、もう一度起きた。手順書の一行は、照合のときに読まれないまま素通りされた。
そのとき、道具そのものを直して助詞違いも拾わせる、という宿題も書いた。
宿題は今も手つかずのまま、手順書に残っている。
そして10月4日が、3回目だった。
手順書の一行は、正しかった。
ただ、相棒は「道具が実行された」ことで、照合を終えたつもりになっていた。
手順書の一行に従って、助詞を外した語で台帳をもう一度探し直す手が抜けていた。
手順書に書いた一行は、道具の探し方を一文字も広げない。
その日は、すり抜けた句を、助詞を外した語そのもの（たとえば「経験値」）で台帳から探し直し、載っていた高さを当て直した。
台帳に前例の無い句も含め、ほかの句の高さも1句ずつ聴いて詰めた。
映像は作り直さず、音だけのやり直しに101分かかった。
道具の修正は動画づくりとは別の作業になるため、この日は動画を仕上げることを先にし、修正は持ち越した。
道具を直すまでの間、できるのは手順書の一行を、いつ何をするかまで具体にすることだ。
手順書には、もう一行足した。
「道具で台帳を当てたあと、必ず助詞を外した語で台帳を探し直す」。
ゲームでいえば、攻略メモを書いたことと、そのメモを戦闘中に開くことは別の行動だ。
手順書の一行も同じで、照合のたびに開いて、そのとおりに探し直さなければ効かない。
道具を直す宿題は、まだ残っている。
次に同じ形の取りこぼしが出る前に、道具の側で助詞違いの前例も拾わせたい。
—

KindBoss.Hiro——私は2台のPCで仕事をしている。
家に置く母艦と、外へ持ち出す古いPC。
仕事のファイル一式は、両方のPCに同じものを置いている。
それを揃えておくために、決まりが一つある。
作業を始める前に、保管場所（GitHub：変更の履歴ごと預かるサービス）から最新の変更を取り込む。
終わったら、そこへ預ける。
10月1日、その「始める前」を飛ばした。
母艦ではもう、その日の冒険手帳（毎日の仕事を物語にして公開している連載記事）を書いて公開し、保管場所へ預けてあった。
私は古いPCで、それを取り込まないまま、同じ日の分をもう一度書いて公開した。
同じ日の記事が、別の本文で2本並んだ。
すぐに気づいて、古いPCで書いたほうの1本をゴミ箱へ移した。
そこで、見張りを一人置いた。
作業画面（VS Code）で相棒のAI（Claude）を立ち上げた瞬間に、保管場所へ最新の変更を確かめに行き、手元のファイルと照らし合わせる仕組みだ。
手元に届いていない変更があれば、自動で取り込む。
預けていない書きかけがあるときは、取り込むと書きかけとぶつかって壊しかねないので、取り込まずに警告を出す。
10月3日、古いPCで相棒を立ち上げた。
立ち上がるあいだ、画面には「確認中」と出るだけで、結果は出なかった。
相棒に最初に話しかけると、その返事の中で、初めて見張りの報告が伝えられた。
報告は「未確認」。
保管場所へ最新の変更を確かめに行く段階で、エラーが出て止まっていた。
取り込みは、手作業でやり直した。
手元に届いていなかった変更は6件。
2台で同じ箇所を別々に書き換えた変更はなく、そのまま揃った。
そのうえで、私は相棒に聞いた。
「起動したときに動くのでは？ 結果が表示されず、質問したタイミングで動いているように見える」
相棒が調べた。
見張りは、ちゃんと相棒を立ち上げたときに動いていた。
問題は、報告の宛先だった。
見張りの報告は、相棒にだけ渡る作りになっていた。
立ち上がるあいだの画面に出るのは「確認中」の一言だけで、結果は出ない。
しかも相棒がその報告を読むのは、私が最初に話しかけたときだ。
だから私が報告を目にするのは、いつも私の質問への返事の中だった。
私の目には、質問した瞬間に見張りが動き出したように映っていた。
見張りは、起きていた。
ただ、報告の宛先に、私が入っていなかった。
直し方は、2つ。
1つ目。報告を、相棒だけでなく画面にも1行出す。照合が済めば、たとえば「GitHub と一致」と出る。
立ち上げた瞬間に、私の目で結果が読めるように。
2つ目。確かめに行く処理の失敗を、1回で諦めない。
VS Code 自身も、裏で定期的に保管場所へ最新の変更を確かめに行っている。
確かめた結果は、手元の控え（保管場所の最新がどこまで進んでいるかのメモ）に書き込まれる。
今回は、見張りがその控えを書き換えようとした瞬間、VS Code も同じ控えを書き換えていて、控えに書かれた「最新はここまで」の位置が、書き換える直前に読んだときと変わっていたというエラーで止められた可能性が高い。確証は、まだない。
ただ、手でやり直したら一度で通った。
もう一度やれば通る種類の失敗だと見ている。
だから3秒待って、1回だけやり直す。
やり直しは、動作テストで確かめた。
1回目を、今回と同じエラーでわざと失敗させる。
2回目で確認が通り、見張りの報告は「GitHub と一致」（＝手元と保管場所が同じ状態）になった。
ただし、その報告が立ち上げの画面に本当に出るかは、まだ見ていない。
次に相棒を立ち上げたとき、自分の目で確かめる。
それまでは、直ったと言い切らない。
ゲームでは、押したボタンの結果がすぐ画面に返ってくる。
経験値が増えた。扉が開いた。
何も返ってこなければ、壊れているのか、あとで動くのか、押した人には見分けがつかない。
見張りも同じだった。
立ち上げた瞬間に結果が画面に出なければ、私には「質問したときに動いている」としか見えなかった。
仕組みが動くことと、その結果が使う人の目に届くことは、別々に作らなければいけない。
—

Kind Boss Hiro——私は毎日、前日の冒険手帳を一本の縦型動画（YouTube ショート）にしている。
台本を書き、AIの声で読み上げ、村の絵と地図と字幕を重ねて、1〜2分の映像に組み立てる。
組み立てるのは、相棒のAI（Claude）と一緒に育ててきた一本のプログラムだ。
この日の朝、前日の冒険手帳（Day188）を動画にした試し版を見て、私は一つだけ注文を出した。
画面の下の字幕と、小さな地図と、歩く主人公と、宝箱の絵。
全部、半行ぶん上へ。
動かす量は、32ピクセル。
直すこと自体は、難しくない。
難しいのは、その直し方の決まりのほうだった。
このプログラムは、作り直しが利く。
三か月前の回でも、台本さえあれば、もう一度同じ動画を組み立てられる。
その「同じ」を守るために、私たちはずっと、ある決まりを続けてきた。
演出を変えるときは、「Day160から」「Day171から」と、回の番号で条件を付ける。
そうすれば、それより前の回を作り直しても、当時の映像のまま出てくる。
気づけば、その条件は約30個に増えていた。
21のファイルに散らばっていた。
プログラムを読むたびに、「この回ならこっち、あの回ならあっち」と、枝分かれを辿る必要があった。
これまでのやり方なら、ここにもう一つ「Day188から」を足すところだった。
私は、その決まり自体をやめると決めた。
「プログラム自体を直す場合は、その日以降の作り直しは最新のものになる前提。過去の出力が必要なときは、履歴から当時のプログラムを取り出して対応する。回の番号による分岐は、すべてなくす」
履歴とは、保管場所（GitHub：変更の履歴ごと預かるサービス）のことだ。
プログラムを変えるたびに、変える前の姿がそこに一つずつ残っている。
三か月前の回を当時のまま作りたければ、三か月前のプログラムを取り出せば済む。
つまり私たちは、保管場所がとっくに覚えていることを、わざわざ今のプログラムにも覚えさせていた。
同じ記憶を、二か所で持っていた。
相棒は、30個の条件を一つずつ外していった。
残したのは、いちばん新しい挙動だけ。
台本に「この回はこう見せる」と書いた指定だけは、残した。
それは回の番号による分岐ではなく、その回の台本自身の意思だからだ。
外したあとが、本当の仕事だった。
変更の前と後で、Day188 の映像を組み立てて見比べる。
違いは、半行上がったことだけ。
ほかは、1か所も変わっていなかった。
試験も回した。
変更でどこかが壊れていないかを、自動で確かめる検査だ。
10本のうち3本が失敗した。
調べると、3本とも変更する前から失敗していた。今回の変更とは無関係だと確かめて、記録に残した。
昼の11時46分、Day188 の最終版が仕上がった。
字幕は半行上がり、プログラムからは約30の枝が消えていた。
過去の姿は、履歴が覚えている。
今のプログラムは、今のことだけを知っていればいい。
物を捨てるのが苦手な家ほど、片付けに時間を取られる。
プログラムも同じだった。
守るつもりで残していた分岐が、毎回、読む手間として利息を取っていた。
捨てられたのは、捨てても戻せる場所が、ちゃんとあったからだ。
—

この日、Kind Boss Hiro——私は、同じ回の冒険手帳を二本、世に出してしまった。
私はいま、PCを二台で使っている。
家に置く新しいPCと、外へ持ち出す古いPCだ。
作業の記録も、手順書も、道具も、一か所の保管場所（GitHub：変更の履歴ごと預かるサービス）に置いている。
どちらのPCも、作業を始める前にそこから最新を写してくる。
これを「取り込み」と呼んでいる。
決まりは一つだけ。座ったら、まず取り込む。
日付が変わった直後の0時15分。
私は古いPCで、冒険手帳の Day186（9月29日の分）を書き始めた。
古いPCが最後に取り込んだのは、9月29日の午後。32時間も前だった。
Day186 は、ちょうど一日前の深夜に、新しいPCで投稿を済ませていた。
けれど古いPCの手元には、その記録が無い。
手元を見る限り、Day186 はまだ書かれていなかった。
相棒のAI（Claude）は、別の本文を書き上げた。
0時17分、投稿。
サイトにはもう、同じ住所（ページのURL）の記事があった。
だから新しい記事の住所の末尾には、自動で「-2」が付いた。
その「-2」で、相棒が気づいた。
元の記事を退避して、重複した方をゴミ箱へ移すまで、約1分。
それから、取り込んだ。
朝、私はこの事故を、新しく開いた作業で相棒に伝えた。
一つずつ確かめた。
重複した方のページは、もう開けない。正しい方は、一覧の先頭にある。
X への投稿も、酒場の語り（冒険手帳をもとにした会話劇）も、ステータス（レベルや経験値を表示するページ）の数字も、重複した方からは何も作られていない。
冒険手帳では、その日の作業量を経験値に換算して積み上げている。
二本目で入るはずだった経験値1,822も、どこにも足されていなかった。
原因も二つに絞れた。
座っても取り込まなかったこと。
そして、投稿する前に「同じ日の記事がもう無いか」を確かめていなかったこと。
相棒は、冒険手帳の手順の頭に、取り込みの確認を足そうとした。
私は言った。
「それだと、冒険手帳を開いた時しか防げない。プロジェクトを開いた時に照合する方がいい」
プロジェクトとは、この仕事の記録と道具が一式入った作業フォルダーのことだ。
取り込み忘れは、冒険手帳だけの病気ではない。
動画を作る日も、記事を直す日も、同じ穴は開いている。
相棒は、入口に仕掛けを置いた。
AIとの作業を始めるたびに、最初に動く小さなプログラムだ。
開いた瞬間に、保管場所と手元を見比べる。
遅れていて、手元に書きかけが無ければ、黙って取り込む。
書きかけや食い違いがあれば、手を出さずに赤で知らせる。
試しに、手元の写しを事故の前の状態へ戻して、仕掛けを動かした。
14回分の変更が取り込まれ、その中に投稿済みの Day186 の記録があった。
この状態で座っていれば、あの二本目は生まれなかった。
その夜。
私は新しいPCで作業を始めた。
仕掛けは、動かなかった。
手元は、保管場所より6回分の変更が遅れていた。
理由は、拍子抜けするほど単純だった。
仕掛けそのものも、保管場所の中にある。
朝、古いPCで作った仕掛けは、新しいPCがまだ一度も取り込んでいなかった。
新しいPCは、そんな仕掛けがあることを知らなかった。
取り込み忘れを防ぐ仕組みも、取り込むまで届かない。
私は手で取り込み、仕掛けを一度だけ手で動かした。
「一致」と出た。手元と保管場所が、同じになったという意味だ。
次に座るときからは、仕掛けが先に見比べてくれる。
仕組みを作った日、最後の一回だけは人の手で運ぶ。
忘れ物を防ぐ道具は、それ自体が、最初の忘れ物になりうる。
—

この日、Kind Boss Hiro——私は、片付けたはずの画像に再会した。
私はいま、PCを二台で使っている。
家に置く新しいPCと、外へ持ち出す古いPCだ。
二台のあいだでは、縦型の短い動画（YouTubeショート）の素材を、仕組みで写し合っている。
片方にしか無いファイルや、新しくなったファイルを、もう片方へコピーする。
この写し合いを「同期」と呼んでいる。
動画の背景に使う絵は、寄っても粗くならないように、4倍に拡大した版を別に持っている。
五日前、使わなくなった絵を5点、廃止した。
元の絵も拡大版も、削除待ちの保管場所へ移した。
これで片付いたと思っていた。
この日、新しい背景を2点登録していた相棒（Cowork：Claude Desktop で作業を手伝うAI）が気づいた。
廃止したはずの5点の拡大版が、素材のフォルダーに戻っている。
元の絵は戻っていない。拡大版だけだ。
ファイルの日付は8月と9月のまま。誰かが作り直したものではない。
相棒はもう一度片付けて、一行だけ推測を残した。
「古いPCからの同期で戻った可能性がある」
その後、私は二台の同期を動かした。
古いPCから受け取ったファイルは、5件。
何を運んだかの一覧を開くと、あの5点の名前が並んでいた。
「新しいファイル」として。
——片付けたそばから、また戻ってきた。
原因は単純だった。
古いPCの側で同期に差し出しているフォルダーには、5点がまだ残っていた。
同期は、相手に無いものを届ける。
新しいPCで消した結果、5点は「新しいPCに無いもの」になった。
だから、届けた。
仕組みは、正しく動いていた。
同期は、足したものしか運ばない。
消したことは、運ばない。
片方で消すのは、片付けではなかった。
こちらに「無い」状態を作っただけで、もう一方から見れば、そこは「届けるべき空き」だった。
直し方も単純だった。
古いPCに残っていた5点も、同期の届かない場所へ移した。
もう一度同期をかけると、受け取るファイルは0件になった。
手順にも一行を足した。
素材を廃止するときは、二台の両方で、同じ日に退避する。
偶然だが、この日もう一本仕上げていた動画の題材も、原因の書き方だった。
二か月前の私は、ファイルを書き換える前に中身の食い違いを調べる検査に作業を止められ、その原因を、「同時に書き込んだせい」と作業記録に書いた。
本当は、画面に出ない改行の記号の違いだった。
同じ日に、相棒の「可能性がある」は、同期の一覧の5行で「原因」になった。
推測のまま、原因の欄に書かずに済んだ。
—