カテゴリー: 冒険手帳

10月18日の朝。私（KindBoss.Hiro。毎日の仕事をゲームの冒険に見立てて記録し、公開している経営者）は、AIと一緒に、前日までにたまっていたファイルの変更を保存していた。その中に、古い日の分を別のファイルへ移して短くした作業記録も入っていた。これは、ファイルを守るはずの仕組みが、その作業記録を元に戻してしまった朝の話だ。
ここでいう保存は、ふだんの上書き保存とは少し違う。git（ファイルの変更履歴を残す道具）に「この時点の中身はこうだった」と記録することだ。記録した版は、あとからいつでも取り出せる。
私は毎日の仕事をAIと進めている。その日に何をしたかは、作業記録というファイルに書き足していく。1回の作業ごとに、日付の入った見出しを立てて書く。新しい分は、いつも先頭に足す。だから古い日の分は、下へ下へと押されていく。
作業記録は、放っておくとすぐ長くなる。だから、ときどき古い日の分を、保管用の別のファイルへ移して縮める。この朝は、作業記録の整理を任せている別のAI（Cowork）が先に縮めておいた作業記録を、保存する番だった。ファイルの大きさは、縮める前の5分の1以下になっていた。
作業記録は、書き込みの事故を防ぐために作った専用の道具（プログラム）で書き換えている。作業記録とその道具には、守りの仕組みが2つ付いている。
一つ目は、保存の前に作業記録の末尾を調べる検査だ。以前、書き込みの途中でファイルの末尾がちぎれる事故が、記録に残るだけで4回起きた。だから最後の行が文の途中で終わっていれば、ちぎれたと疑って保存を止める。
二つ目は、書き換える道具に入っている自動の修復だ。ちぎれたと判断したら、git に最後に保存されていた版を正として、それで作業記録を書き戻す。
保存しようとすると、一つ目の検査が止めた。
最後の行が「…継続性を守った」と、句点なしで終わっていたからだ。縮めた結果、たまたま一番下に来た行で、もともと句点が無かった。ちぎれてはいない。
それなら句点を1つ足せばいい。私はAIに、書き換える専用の道具で句点を足させた。
道具は作業記録を見て「ちぎれている」と判断した（理由はあとで書く）。そして、git に最後に保存されていた版で書き戻した。縮めた分はまだ保存できていなかったから、その版は、縮める前の作業記録だった。
句点1つを足すつもりが、縮めた作業がまるごと消えた。
幸い、中身は残っていた。git では、版を記録する前に、記録する中身をいったん git の中へ預ける。これを登録という。私たちは保存の直前に、縮めた作業記録を登録してあった。保存は止められたが、預けた中身は git の中に残っていた。修復が書き戻すのは作業記録のファイルだけで、git に預けた中身には触れないからだ。AIがそれを取り出して書き戻し、句点は道具を使わずに直接1つ足した。失ったものは無かった。
では、守りはなぜ間違えたのか。原因は2つあった。
一つは、一つ目の検査の見方だ。過去に本当にちぎれた、その4回は、どれも最後に改行が無かった。今回の作業記録は、行の後に改行と空行まで入って、きちんと終わっていた。検査は「句点で終わっているか」だけを見て、「改行で閉じているか」を見ていなかった。
もう一つは、二つ目の修復の判断条件だ。修復は「今のファイルが、前の版の先頭部分とぴったり同じなら、後ろがちぎれた」とみなしていた。ちぎれた場合は、確かにそうなる。
ところが、縮めた場合もそうなる。
新しい日は先頭に足す。古い日は一番下にある。古い日を移して縮めると、一番下が切り取られる。残るのは、前の版の先頭部分とぴったり同じ中身だ。
ちぎれた記録と、縮めた記録は、末尾だけ見れば同じ形をしている。
修復が正しく動くかを確かめる試験の仕組み（テスト）にも、縮めた作業記録を使う確認はあった。ただ、そのテスト用の作業記録は、中身を要約して短くする形で作られていた。一番下を切り取る、本番の縮め方とは違う。だから、この穴は見逃されていた。
古い日の分は、日付の見出しごと丸ごと移す。だから縮めた作業記録は、必ず次の見出しの手前で終わる。そこを手がかりにする直し方をAIに示してもらい、私が承認した。改行と空行で閉じた末尾は、ちぎれていないと見る。日付の見出しの境目で終わっているなら、修復はしない。本物のちぎれでは、これまでどおり修復する。空行で終わる版、一番下を切り取った版などを使う確認を3件足し、もとからある確認とあわせて、すべて通った。
私はそれまで、守りは付ければ付けるほど安全になると思っていた。
この朝に分かったのは、守りが知っているのは「何から守るか」の形だけだ、ということだ。私が自分の意思で縮めることも、守りから見れば、事故と同じ形をしていた。
だから守りを足したら、自分が毎日している作業がその形に似ていないかを、一度は確かめる。
私はこの日誌（冒険手帳）で、その日に片づけた仕事の一つひとつに点（経験値）をつけている。この日の点のいくつかは、その確かめ方を覚えた分だと思っている。
—

10月17日。縦型の短い動画（YouTubeショート）の題材に、16年前に自分で書いたブログ記事を選んだ。
2010年9月25日の記事だ。題は「仕事をゲーム化するというHACK　その１」。
仕事場をゲームの舞台に、働く自分を主人公に見立てる。伸ばしたい行動に経験値（EXP）という点をつけ、たまったらレベルが上がる。そういう遊び方を書いた記事だった。
例に出していたのは、営業の仕事だ。アポイントを取るための電話1本で1点。アポイントが取れても、電話1本と同じ1点。実際の商談で10点。
そのあとに、こう書いていた。
「商談成立の場合は経験値１００あたりにしたいと思いますが、それはやめましょう。結果は行動と同じ程度にすべきです。つまり商談成立で経験値１０です。」
理由は一行だけだった。「強化したいのは行動ですから、結果はおまけという考え方です。」
私（KindBoss.Hiro。この日誌を書いている経営者）は今、自分の毎日を同じやり方で記録している。今年の春から、その日に片づけた仕事の一つひとつに点をつけ、毎日この冒険手帳（日々の作業と経験値を記録して公開する日誌）に載せている。睡眠や歩数にも点はつくが、ここで見るのは仕事の点だけだ。
仕事の中身は、たとえば動画の台本を直すこと、読み上げ（ナレーション）の抑揚を一句ずつ直すこと、この日誌を書いて投稿することだ。点は作業の大きさで決める。確認や記録、一句の直しのような小さな作業は10〜40点。大きめの直しや調べものは50〜100点。新しい仕組みを一から作れば100点を超える。この決め方の一覧が、私の点数表だ。
16年前に書いた決まりを、今の点数表は守れているのか。動画を作る途中でそれが気になって、AIに数えてもらった。直近23日分、9月24日から10月16日までの記録だ。
仕事の項目は1,775件。読み上げの一句を直すのも1件と数える細かさなので、1日に70件を超える。1件あたりの平均は、34.0点だった。
では、結果に近い作業はどうか。
私の場合、結果にいちばん近い作業は、作った動画をYouTubeやInstagramへ上げることと、この冒険手帳を投稿することだろう。その項目だけを抜き出すと、およそ50件。平均は33.3点。
作業全体の平均と、ほとんど変わらなかった。
動画を上げる作業は、1件20〜30点がほとんどだ。読み上げの一句を直す作業と同じくらいの点になる。冒険手帳の投稿は60点で、平均よりは高い。それでも、23日間でいちばん高い180点の3分の1にすぎない。180点がついていたのは、たとえば、家と外出先で使う2台のパソコンのあいだで動画の素材を自動で同じにそろえる仕組みを、一から作った作業だった。
そして、その先にある本当の結果——動画が何回見られたか、登録してくれた人が何人増えたか——には、経験値をまったくつけていない。フォロワーの数も毎日記録しているが、経験値の計算に掛ける倍率は1倍に据え置いてある。
ここで、ひとつ断っておく。
私が今の点のつけ方を決めた頃の作業記録を見返しても、2010年の記事を読み返した跡は見つからなかった。だから「16年前の決まりに合わせて点数表を作った」とは書けない。
2010年の私は、商談成立を、商談と同じ10点にした。今の点数表は、結果に近い作業をほかの作業とほぼ同じ重さにし、結果そのものには点をつけていない。
形は違う。それでも「結果に、行動より大きな点をつけない」という線は同じだった。今の点数表は、16年前に「それはやめましょう」と書いた線の上に乗っていた。
結果に大きな点をつけたくなる気持ちは、今も分かる。成立した商談も、公開した動画も、目に見えるし、うれしい。
ただ、結果は自分ひとりでは決められない。相手が買うかどうか。見る人が来るかどうか。行動なら、今日の自分が選べる。
もし再生回数に応じて点をつけていたら、今日の点は、今日の自分がどれだけ動いたかではなく、見る人が来たかどうかで決まる。毎日の点を、自分では選べないものに預けることになる。
この日の動画は、最初に読み上げる一文を「商談成立は100でなく10。16年前の私のルール」にした。YouTubeへは非公開のまま上げてある。公開のボタンを押すのは、私だ。
押したあとに再生が伸びても、伸びなくても、この日の作業についた点は1点も変わらない。
結果はおまけ。16年たっても、点数表の数字はそう言っていた。
—

10月16日。縦型の短い動画（YouTubeショート）の最初の一文を、読み上げソフトがどうしても読めなかった。
「人生のLv100まで17年？　8月に決めた時は2年だった。」
ナレーションは、文字を声にする読み上げソフト（VOICEVOX）に読ませている。「8月に決めた時は」の頭で、毎回、声が破裂したように乱れる。9回読み直させて、9回とも同じ場所で崩れた。なぜそこで崩れるのかは、分からないままだった。その部分の音の高さを少しずつ変えて読ませ直す手も試したが、どれも駄目だった。
最後は、一文を二つに割った。「人生のLv100まで17年？」と「8月に決めた時は2年だった。」。別々に読ませて耳で聞き比べると、乱れはほとんど聞き取れなくなった。
この日、ナレーションの読み方の直しは10か所、97分かかった。いちばん手こずったのが、この一文だった。
動画が語っているのは、私が自分で作った表の話だ。
私（KindBoss.Hiro）は、春から自分の毎日をRPGに見立てて記録している。寝た時間、歩いた歩数、その日に片づけた仕事。それぞれに経験値（EXP）がつき、たまるとレベルが上がる。レベルの上限は100。どれだけためれば次に上がるかは、自分で作った表（レベル表）で決めてある。冒頭の一文の「人生のLv100」は、この表の最後のレベルのことだ。
その表を、8月21日に作り直した。
8月は、経験値のつく仕事の数が一気に増えた月だった。AI（Claude Code）に作業を並行して任せるようになり、1日に片づく仕事の数そのものが増えたからだ。8月13日にも、次のレベルに上がるのに要る経験値を増やす直しを入れたばかりだった。そのとき置いた想定は1日5,443EXP。ところが8月14日から20日までの7日間の平均は12,244EXP、そのうち最後の3日は17,242EXPだった。そのころは1レベル上がるのに1万3,000EXPほどだったから、1日でほぼ1レベル上がる。このままでは、あっという間にLv100に着いてしまう。
そのとき私はLv59。もう上がり終えたレベルの表は動かさず、次のLv60から先を組み直すことにした。
考えたのは、1日にこなせる作業の量には天井がある、ということだ。
天井は1日18,000EXPと置いた。直近3日の17,242EXPを少し上回る値だ。天井といっても、測った限界ではない。表を組むために置いた見込みの数字だ。この速さで進めば、Lv60からLv100までがちょうど2年。そう組み直して、表の末尾に1行を足した。
「実際の獲得EXPが18,000を続けて超えるようなら、テーブル（この表）を見直す。」
作り直したあとも、しばらくは天井を超える日があった。最も多い8月27日は35,525EXP。見込みの2倍近い。8月の下旬は、平均でも天井を超えていた。それでも表は、8月21日の形のまま、いまも変えていない。見直さなかった理由を書いた記録も残っていない。超えたときの決まりでさえ、1行書いてあるだけでは動かなかったことになる。
18,000を超えた日は、9月8日が最後になった。
そこから数字は下がっていった。1日あたりの平均で、8月21日から31日は22,142EXP。9月前半は14,710EXP。9月後半は4,565EXP。そして10月1日から15日は、2,051EXPだった。
天井のおよそ9分の1。いまはLv63まで来ているが、この速さのままなら、Lv100までの残りだけで約17年かかる。Lv60からの全部を2年で進むはずだった道のりが、その先の残りだけで8倍以上に伸びている。
この日、10月16日の獲得は1,818EXP。天井の10分の1ほどだ。
動画の台本を書くために、表を読み返した。
決まりは1行しかない。超えたら見直す。
下回ったときのことは、どこにも書いていなかった。
8月の私は、速すぎることだけを心配していた。表の想定より速く進んでLv100に早く着きすぎる心配はしたが、想定よりずっと遅くなる心配はしなかった。だから「超えたら見直す」は書いたが、「下回り続けたら見直す」という決まりは書かなかった。
経験値がなぜ減ったのかは、まだ分かっていない。分からないまま理由を決めて、表をいじることはしなかった。動画でも、減った理由には触れていない。
ひとつだけ、はっきりしたことがある。
決まりは、それを書いた日の心配の形をしている。
8月の心配は「速すぎる」だった。だから決まりは「超えたら」とだけ言う。10月に起きているのは、その逆だ。
その日の最後に、冒頭の一文をもう一度聞いた。
「人生のLv100まで17年？」
「8月に決めた時は2年だった。」
一度に読ませると崩れた文が、二つに分けると、ほとんど乱れずに読めた。前の文の17年は、10月の私が見ている数字。後ろの文の2年は、8月の私が置いた数字。続けて聞くと、2か月で2年が17年に伸びたことが、二つの文の差としてそのまま耳に入る。
動画はこの日、YouTubeに非公開で上げた。動画づくりの作業はAIに任せているが、公開のボタンだけは私が自分の手で押すことにしている。表の決まりは、まだ1行のままだ。
—

私、KindBoss.Hiroは、毎日をRPGに見立てた表をつけている。寝た時間や歩いた歩数、その日の仕事に経験値がつき、溜まるとレベルが上がる表だ。
その表と1日の出来事を、「冒険手帳」というブログの日誌に書いている。
9日分ずつ日誌をまとめ直して、1本の長い物語にする仕事もしている。Noteで連載している「KindBoss Chronicles」だ。2026年10月15日の朝、その第21巻をNoteに出した。
第21巻の主題は「受け取られ方」。
言った側がどういうつもりだったかではなく、受け取った側が、それを何として読んだか。
たとえば、動画づくりを任せているAI（このあと出てくるClaude Code）に、私はナレーションの抑揚（どの音を高く読むか）の直しを聴いて「OK」と返した。AIはそれを動画全体への「OK」として読み、公開用の動画ファイルを作って、YouTubeへ非公開のまま上げていた。私はまだ、映像と音を合わせた完成版を見ていなかった。巻の中に出てくる、別の日の動画の話だ。
そういうずれを、9日分たどった巻だ。
同じ日、この巻そのものを動画にした。
手順は3段ある。
まず、GoogleのAI「NotebookLM」に巻の文章を読ませ、2人の話し手が掛け合いで語る音声を作る。
次に、その音声を、音声を文字に起こすAIにかけて字幕にする。
最後に、起こした字幕を、Claude Codeが直す。Anthropic社のAIで、私のパソコンの中でファイルを読み書きしながら作業を進める。
巻の言葉は、3回、受け取る側を通ったことになる。
1回目は、NotebookLMの話し手。
巻の本文には、この9日間の1日あたりの経験値が、レベル表の想定（1日1万8,000点稼ぐ前提でレベルの間隔を決めてある）の4割ほどだった、と書いた。
話し手はそれを、前の巻の9日間と比べて4割ほど、という話にして語っていた。比べる相手が、レベル表の想定から、前の巻の9日間にすり替わっている。
字幕は音声どおりに出すので、話し手の言い間違いは字幕では直せない。動画の説明欄に、レベル表の想定と比べた4割だと書いておいた。
2回目は、文字起こしのAI。
話し手が口にした「字面どおり」を、3か所とも「地面通り」と書いた。
巻の締めの言葉に出てくる「言った側」は、「行った側」になっていた。
ここまでは、直すのが難しくない。地面通りでは文が意味をなさないので、誤りだとすぐ分かる。巻の本文と照らせば、正しい語も迷わず決まる。
名前や日付の表記の揃えも含めて、Claude Codeが直した字幕は61か所になった。
3回目は、字幕を直すClaude Code自身だった。ここが、この日の山だ。
冒頭近くに、こういう字幕があった。
「日常で走ってる言葉」
言葉は走らない。Claude Codeは、意味の通る語に置き換えた。
「日常で放ってる言葉」
ただ、Claude Code自身も確信はなかった。
確信の持てない5件を一覧にして、私に耳で確かめるよう頼んできた。この行の備考には、「発してる」の可能性もある、と書き添えてあった。それでも、置き換えたのは「放ってる」のほうだった。
動画は、YouTubeに非公開で上げてあった。夕方、私はその箇所を聞いた。
「はっしてる」だった。
「発してる」。
字幕にはほかに2か所、同じ「発する」が別の語に聞き取られて残っていた。
「はしってる」と「はっしてる」の違いは、小さな「っ」1つだけだ。
「はなってる」は、音ではもっと遠い。
Claude Codeは、意味が通るかどうかで語を選び、元の音にどれだけ近いかで選び直さなかった。
一覧の残り4件（相づちの一語、巻の番号、「とっくに」、私の名前の書き方）は、置き換えたとおりで合っていた。
受け取られ方を主題にした巻の字幕で、受け取る側が、また意味のほうで読んでいた。
機械を責める話ではない。
受け取る側は誰でも、手元の材料で、いちばん意味の通る形に読む。
NotebookLMも、文字起こしのAIも、直したClaude Codeも、それをしていた。巻を書いた私も、たぶん毎日している。
意味が通ることは、そう言われたことの証拠にならない。
受け取ったものが本当にそう言われたのかを確かめる手は、元の音に戻って聞くことしかない。
人と話すときなら、相手の言葉を自分の言い方に置き換えて分かった気になる前に、相手が実際に使った言葉をそのまま聞き返すことだ。
3か所を「発してる」に差し替えた字幕をYouTubeに上げ直し、その夕方、動画を公開した。
Claude Codeは、字幕を直すたびに読む聞き違いの対応表（文字起こしの誤りと正しい語の一覧）に、今回の外し方を書き残した。音の照合を飛ばした、と。
—

私、KindBoss.Hiroは、毎日をRPGに見立てた表をつけている。寝た時間や歩いた歩数、その日の仕事に経験値がつき、溜まるとレベルが上がる表だ。
その表と1日の出来事を、「冒険手帳」というブログの日誌に書いている。1日分ごとに、1分前後の縦型動画（YouTubeショート）も1本作っている。
動画づくりの手を動かしているのは、AIのClaude Codeだ。台本を組み、映像を1本の動画ファイルにまとめて書き出し、公開したあとの再生回数まで集めて記録する。
AIは、作業ごとに用意した手順書（毎回読んで、その通りに動くための文書）に従って動いている。
この日、AIは何度か手を止めて、判断を私に返してきた。
最初は朝だった。
作っていたのは200日目の記録から作る動画だ。
動画の冒頭には、これまで毎回、5つの演出を入れてきた。画面が一気に寄って止まるズーム。レベルや経験値を見せる、スマホの通知のような帯。背景の絵の小さな見本が流れ、選ばれた1枚が広がって次の背景になるアニメーション。画面の隅に出る、物語の舞台として描いた架空の世界の地図で、いまの場面の位置を印で示すもの。そして、道を歩いて進む映像。
この200日目の動画から15本、5つを回ごとに入れたり外したりして、再生の伸びや最後まで見られる割合を並べて比べるテストを始めた。15本の1本目になるこの動画は、5つを全部外す。
公開前に私が見て確かめるための動画を書き出していたとき、処理がメモリ不足で強制終了した。
AIは、すぐにはやり直さなかった。まず、何がメモリを使っているかを調べた。
動画の方針を一緒に考えている、もう1つのAI（Cowork：Claude Desktop で動く作業の相棒）が、裏で約4.1GBのメモリを使っていた。書き出しの処理の側も、使えるメモリを割り振るときに、パソコン自体が動くための分を残す計算になっていなかった。
AIは、その原因を私に伝えてきた。
ここから先は、AIには決められない。
どのアプリを閉じてよいかは、そのパソコンで仕事をしている私が決めることだ。
私はChromeとCoworkとCopilot（マイクロソフトのAIアプリ）を閉じた。空きメモリは7.7GBになり、2回目の書き出しは最後まで通った。
次は夜だった。
公開した動画の数字を、YouTubeの管理画面（YouTube Studio：再生回数や、どこまで見られたかを確かめる画面）から読み取って記録する作業がある。AIは、Chromeに入れた拡張機能（ブラウザに後から足す小さなプログラム）を通して私のパソコンのChromeを操作し、その画面を開く。
開いた画面に、こう出た。
「このページを表示する権限がありません」
Chromeが、チャンネルの持ち主のアカウントではなく、私の別のGoogleアカウントでログインしていた。
AIは手を止め、アカウントの切り替えを私に頼んだ。ログインやパスワードの入力は、AIにはさせない決まりにしている。だからこれも、私にしかできない。
私の指示で、手順書にも「チャンネルの持ち主のアカウントでログインしていること」という前提を1行書き足した。
私は、持ち主のアカウントでログインしているChromeを開いた。
そのChromeにも同じ拡張機能が入っていて、AIから操作できるブラウザは2つになった。
するとAIは、どちらのブラウザを使えばいいかを、私に確かめようとした。
私は言った。
「2つのブラウザのアカウントは調べられるはず」
AIは、2つのブラウザでそれぞれGoogleアカウントの設定ページを開き、表示されたメールアドレスを読んだ。1つ目が持ち主のアカウントだった。そちらを選び直すと、数字の記録は最後まで通った。
調べるのにかかったのは、ブラウザごとに設定ページを1回ずつ開くことだけだった。
この日、AIが私に返してきた判断は3つあった。
どのアプリを閉じるか。これは私にしか決められない。
どのアカウントでログインするか。これも私にしかできない。
どちらのブラウザが持ち主のものか。これは、AIにも調べられた。
手を止めること自体は悪くない。分からないまま黙って進むより、ずっといい。
ただ、止まったあとの「聞く」には2種類ある。
人にしか決められないことを、決めてもらう「聞く」。
調べれば分かることを、代わりに答えてもらう「聞く」。
後のほうは、聞かれた側の手を止めるだけで、何も前に進めない。
日付が変わるころ、私の指摘を受けて、AIが手順書にもう1行を足した。
権限のエラーが出たら、止める前に、操作できるブラウザのアカウントを調べる。持ち主のものが見つからないときだけ、人に頼む。
聞く前に、調べられるかを確かめる。
人に頼むのは、人にしか決められないことだけでいい。
—

私、KindBoss.Hiroは、毎日をRPGに見立てた表をつけている。寝た時間や歩いた歩数、その日の仕事に経験値がつき、溜まるとレベルが上がる表だ。
その表と1日の出来事を、「冒険手帳」というブログの日誌に書いている。今日の日付で、200日目になる。
冒険手帳の1日分からは、1分前後の縦型動画（YouTubeショート）も1本作っている。
作業は2つのAIに分けている。
ひとつは、どんな動画をどう作るかの方針を考えるAI（Cowork：Claude Desktop で動く作業の相棒）。
もうひとつは、動画を組み立てるプログラムを書いて動かすAI（Claude Code）だ。
動画のもとになるのは台本だ。ナレーションの文と、何秒目にどの映像を出し、どの音を鳴らすかを書いた設計図になっている。
その動画の冒頭には、決まった演出が5つある。
画面が一気に寄って止まる「クラッシュズーム」。
スマホの通知のように上から降りてきて、私のレベルや経験値を見せる帯。
背景の絵の小さな見本がずらりと流れ、次の場面に使う1枚が指で選ばれるように広がって背景になる「アートトラック」。
画面の隅に、冒険手帳の物語の舞台として描いた架空の世界の地図を出し、いまの場面がその世界のどこかを印で示す「ミニマップ」。
そして、道を歩いて進む映像。
どれも、良かれと思って足したものだ。
そして足したあと、一度も外していない。
毎回同じ形で並ぶ冒頭が、かえって私の動画どうしを似せていないか。似た動画ばかりに見えれば、届き方にも響くかもしれない。
方針役のAIが過去の動画を並べてそう見立て、私も同じことを疑っていた。ただし、見立てはあくまで仮説だ。確かめるしかない。
そこで、Day200からDay214までの15本で、演出を回ごとに入れたり外したりすることにした。
その1本目、200日目の動画は、5つの演出をすべて外す。15本がそろったら、結果を並べて比べる。
仕組みは、経験値の表とは別の、演出のための表を1枚作った。
1行が1回分の動画で、列が5つの演出。組み立て役のAIが書いたプログラムがその回の行を読み、「入れない」と書かれた演出を台本から外す。
その回の行が無ければ、組み立ては止まる。黙って全部入れることはしない。
演出の表には、5つの演出のほかに、もう1列あった。動画の始まりに鳴る効果音だ。
方針役のAIが書いた依頼書には、こうあった。
「フック字幕の効果音を、数種類から回ごとに選ぶ。直近2回と同じ音にしない」。
フック字幕とは、動画の冒頭に大きく出る、一行目の文字のことだ。
組み立て役のAIは、その通りに作った。
候補の音を3つ用意して音量をそろえ、15本に順番に割り振った。表どおりに演出と音が入ったかを照らし合わせる機械の検査も、問題なく通った。
そのあと方針役から、同じ音がある演出の回に固まっているという追加の依頼が届いた。組み立て役は表から並びを数え直し、指摘が正しいことまで確かめた。
2つのAIが、同じ前提の上で、きちんと仕事を重ねていた。
私は、ひとつだけ聞いた。
「映像演出と効果音はセットでないとおかしくないか？」
問いを受けて、組み立て役のAIが、台本の中でその音が鳴る時刻を確かめにいった。
動画が始まって約0.05秒で、風を切る音が鳴る。
クラッシュズームの寄りは、0.25秒で止まる。
問題の音が鳴るのは、0.265秒。
フック字幕が出るのは、0.949秒。
依頼書が「フック字幕の効果音」と呼んでいた音は、フック字幕より0.7秒近く早く鳴っていた。
寄ってきた画面が止まる、その瞬間に鳴る「着地の音」だった。
1か月半ほど前の試作で、風を切る音と組にして、私が決めた音だ。
冒頭で鳴る音を、冒頭に出る文字の音だと取り違えたまま、依頼書が書かれていた。方針役のAIは、のちに「前提が誤っていた」と書いて並び替えの依頼を撤回し、元の依頼にも訂正を出し直している。
このまま進めていれば、200日目の動画では、画面は寄ってこないのに、止まる瞬間の音だけが鳴っていた。
何も止まらない画面に、着地の音だけが響く。
直し方は単純だった。
クラッシュズームを外す回は、風を切る音と着地の音を、両方とも外す。
入れる回は、これまで通り両方鳴らす。
音を回ごとに替える仕組みは、表の列ごと取り外した。用意した3つの音も、使わないものとして片づけた。
組み立て役のAIは、作業の記録にこう残している。
実装の前に、その音が台本のどこで鳴っているかを一度見れば分かった、と。
依頼書の呼び名で判断していた、と。
誰も手を抜いていなかった。
書かれた名前を信じて、その名前の上で、正しく積み上げていただけだ。
だから検査も、確認も、全部通った。検査が照らし合わせていたのは、表と出来上がりが同じかどうかで、表の名前が正しいかどうかではなかったからだ。
名前が間違っていると、正しい作業ほど深く進んでしまう。
その積み上げを止めたのは、技術の知識ではなかった。
「音と映像は、組のはずだ」という、作っている人間の感覚だった。
呼び名が指している場所に、その物があるとは限らない。
鳴っている時刻を見れば、それが何の音かは分かる。
200日目の動画は、これまでで一番、何も起きない冒頭で始まる。
寄らない画面に、余計な音は鳴らない。
—

私、KindBoss.Hiroは、毎日をRPGに見立てた表をつけている。
寝た時間、歩いた歩数、その日の仕事。行動ごとに経験値が入り、溜まるとレベルが上がる。
その表で、睡眠には線が1本引いてある。
7時間。届いた日だけ、10点の経験値が入る。
この表は、「冒険手帳」というブログの日誌の冒頭に、毎日載せている。私は3月28日から198日、毎日書いてきた。
表には「睡眠」の欄がある。冒険手帳を書くとき、寝た時間を、私が自分で数字にして入力する。6時間なら6、7時間なら7。書いて、投稿して、閉じる。
この日、私はその欄を初めて並べ直した。
きっかけは前日、10月11日にXへ書いた投稿だった。
ゲームの「図鑑」の話だ。図鑑は、冒険で出会ったモンスターや道具を、種類ごとに並べ直した一覧になっている。
投稿で私はこう書いた。日記はふつう日付の順に書き、一覧にして見直すことはない。けれど同じ出来事を図鑑のように種類ごとに並べ直すと、自分が無意識にくり返している行動が見えてくる、と。
その投稿を、1分少しの縦型動画（YouTubeショート）にするつもりだった。
言葉だけでは弱い。自分の記録で試してみせたい。
そこで、AIと一緒に、198日分の睡眠の欄を、日付の順ではなく時間の長さごとに並べ直した。
欄が空いている日を除くと、記録は187日あった。
7時間以上の日は、15日しかなかった。
その最後は、7月29日。冒険手帳でいえば124日目だ。
それから、記録のある最後の日の10月11日までの74日間——睡眠の欄が空いている4日を除くと70日——7時間に届いた日は1日もない。
いちばん多かったのは6時間で、通算85日。
毎日、自分の手で書いていた数字だ。
それでも、最後に10点がついた日がいつだったかを、私は一度も数えたことがなかった。
表は1日分ずつ、別々の記事に載る。書いては閉じるので、6が全部で何回出てきたかは、どの記事にも書いていない。
並べ直して、初めて分かった。
私が毎日くり返していたのは、6時間の睡眠だった。
この発見を動画にする途中で、私は1文を書き直している。
最初の台本では、点の決まりをこう書いていた。
「自分で決めた点の表では、7時間以上寝た日は10点、足りない日は0点だ。」
公開前に、台本を書いたAIとは別のAI（別の会話で動かすClaudeと、Gemini）に、台本を審査させている。YouTubeのポリシーの文と台本の文を突き合わせ、引っかかりそうな箇所を挙げさせる審査だ。
私の縦型動画は、台本も声もAIの手を借りて作っている。審査役のAIはこの1文と並べて、YouTubeのチャンネル収益化ポリシーから次の一行を引いてきた。「医学的な診断、健康に関するアドバイス、健康法を提供する AI『医師』」。
YouTubeがそう判定したわけではない。審査役のAIが「当たりうる」と挙げた、というだけだ。
私は、文の頭で「自分で決めた」と断ってはいた。それでも「7時間寝れば10点」という形が目立つと、7時間が正しい睡眠だと私が勧めているようにも読める。
私は医者ではない。7時間が誰にとって正しいかを、言う立場にはない。
だから、言い方を変えた。点の決まりから話し始めるのをやめ、線を引いたのが私だと先に書いた。
「7時間は、私が自分のゲームの表に引いた線だ。届いた日だけ、10点が入る。」
点の決まりは残した。変えたのは、誰の決まりかを最初に言ったことだ。正しさの話ではなく、自分で決めたルールの話になる。
そう書き直すと、動画が言っていることがはっきりした。私が見つけたのは、睡眠についての一般論ではない。
自分で引いた線に、記録のある70日、一度も触れていなかったという事実だ。
同じ日、もう1つ「書いてあるのに見えていなかったもの」があった。
私の縦型動画は、AIが台本に合わせて背景の画像や音を組み立てる。組み立ての途中でAIは機械の検査を回す。同じ画像の使い回しや、字幕と音の細かい決まりを点検し、気になる点を「注意」として検査結果に書き出す。
仕上がった動画を私が通しで見る「試写」のとき、AIは、私に判断してほしい点だけを一覧にして添えてくる。
試写を見た私は、背景の画像が切り替わる区切りで数えて1つ目の場面と7つ目の場面に、同じ背景画像が使われているのに気づいた。
調べると、検査はその重複を「注意」としてきちんと書き出していた。
AIは、重なっても差し支えないと自分で考えて画像を残し、その判断を私への一覧に載せなかった。
検査結果には書いてあった。私が見る一覧に、並んでいなかった。
7つ目の場面を、別の画像に差し替えた。動画はその日、YouTubeへ非公開のまま入れた。公開のボタンは、私が後で押す。
書いてあることと、見えていることは違う。
毎日書いた数字は、書いた順に並んでいるかぎり、何も言わない。
並べ直したとき、はじめて「この形をくり返している」と口を開く。
ちなみにこの日の分の手帳でも、睡眠欄に書いた数字は6だった。
これからは同じ記録を、日付の順と、長さの順の両方で見ていく。
10月11日までに85回書いた6。明日から睡眠欄へ何を書くかは、自分で決めるつもりだ。
—

私は、仕事と生活をRPG（ロールプレイングゲーム）に見立てて、毎日を記録している。
行動ごとに経験値（EXP）を付け、たまるとレベルが上がる。
この連載（冒険手帳）は、その1日分の記録だ。
作業の多くは、AIの Claude と一緒に進めている。
10月11日は、YouTube ショート（縦長の短い動画）を1本作った日だった。
題材は、前の日に私が X に書いた一文から取った。
「ゲームのボスは、勝てない時に、何が足りないかを教えてくれる。」
ゲームでボスに負けたプレイヤーは、レベルを上げ、武具をそろえ、魔法を覚えて出直す。
ボスがいるから、何を鍛えるかが決まる。
現実の目標でも、最終目標の手前に中間の目標を置ける。ゲームでいう「中ボス」だ。
ただし、強すぎても、弱すぎても役に立たない。強すぎる相手は、どれだけ鍛えれば届くのか見当がつかない。弱すぎる相手は、何も鍛えないまま倒せてしまう。
動画にするなら、言葉だけでは足りない。私自身の数字で見せたかった。
そこで、自分の表を開いた。4月に作った、毎日をRPGに見立てるための表だ。
その表には「影響力」という値がある。SNSのフォロワーの合計だ（いまはXとYouTube）。
影響力にはランクがあり、最初のランクに上がるのが1,000人。
表の中の世界は村に見立ててあり、届くと、村での称号が「無名の旅人」から「顔が知られ始めた」に変わる。毎日の経験値には、体調・職場と生活の環境・影響力の3つを掛け合わせた倍率がかかる。そのうち影響力の分が1.0倍から1.2倍に上がり、同じ作業でも経験値が2割増える。
動画を作った時点の私は、426人だった（Xが402人、YouTubeが24人）。
表には、もっと遠い目標も書いてある。
「各SNSのフォロワーが、それぞれ3,000人を超える」。私がこの表に置いた、SNSの最終目標だ。
Xの402人から見て、3,000人は7倍を超える先にある。YouTubeの24人から見れば、さらに遠い。
台本の初稿では、1,000人のランクと426人を紹介した直後に、この3,000人と402人も並べた。
中ボスの説明は、そのあとに置いた。
3,000人と402人。遠い、と先に見せておけば、話が分かりやすくなると思った。
台本ができると、別のAI（Google の Gemini）に読ませる。元にした X の投稿や表の数字は渡さず、台本だけを、初めて動画を見る人として読んでもらう。
返ってきた指摘の1つが、これだった。
「中ボスの説明を聞いた時点で、どれが中ボスか、もう分かった。」
その通りだった。
1,000人と426人、3,000人と402人を聞いた後に「中ボスは、強すぎても弱すぎてもいけない」と聞けば、7倍先の3,000人は外れ、候補は1,000人しか残らない。
問いを立てる前に、答えの材料を並べていた。
順番を入れ替えた。
先に、中ボスとは何かを言う。
その直後に、一行だけ問いを置く。
「では、私の表の中ボスは、どこにいるか。」
ここで初めて、3,000人と402人を出す。7倍を超える。強すぎる。
次に、合計の426人から、最初のランクの1,000人を見る。2倍と少しだ。
そして最後に、答えを言う。
「私の表の中ボスは、この千人だ。」
公開の前に、1つだけ確かめた。
表に「中ボス」という欄はない。1,000人を中ボスと呼んだのは、表を読んだ私の言葉だ。
だから動画では「表でそう決まっている」とは言わず、「私の表の中ボスは」と、表を読んだ私の言葉として言う形にした。
動画は、その日の朝に公開した。
中ボスまで、あと574人（翌朝に数えたら428人で、あと572人になっていた）。
7倍先の相手は、まだ何も教えてくれない。2倍先の相手なら、残りの人数を、毎日の作業の先に置いて数えられる。
私の表では、動画を1本作るのも、記事を1本書くのも、経験値の付く作業だ。
だから今日の作業も、経験値を付けて記録していく。1,000人に挑むまでに何をしてきたかを、後から数えられるように。
—

私は、仕事と生活をRPGに見立てて記録している。
毎日の行動に経験値（EXP）を付け、たまった分でレベルが上がる。
この連載（冒険手帳）は、その1日分の記録だ。
作業の多くは、AIの Claude と進めている。
レベルの表（レベルごとに、そこへ届くまでに要る経験値を並べた表）は、自分で決めた。上限はレベル100だ。
10月10日の時点で、記録を始めて196日目。レベルは63だった。
この日、この上限の話を YouTube ショート（縦長の短い動画）にした。
きっかけは、前日に X へ出した投稿だ。テーマは、ゲームの「やりこみ要素」だった。物語をクリアした後も遊べる要素のことだ。珍しいアイテムを探す。地図を隅々まで埋める。図鑑を全部そろえる。終わりを目指すのではなく、続けること自体を楽しむ遊び方だ。
では、私がレベル100に届いたら、次の目標に何を置くのか。それを動画の問いにした。
ショートを見る人は、指一本で次の動画へ送れる。だから、冒頭が大事になる。
冒頭には、画面に大きく出す短い2行を置く。ほぼ同じ文を、動画の題名にも使う。以下、これを「フック」と書く。
フックの案は、AI（Claude）に何周も出させて選ぶ。最初に選んだのは、これだった（「／」は改行の位置）。
「人生をゲームにした。Lv63／あと37レベルで終わる」
数字が具体的で、残りが見える。私の頭の中では、上限の100まであと37、という意味だった。いい案だと思った。
フックを決めたら、台本を書く前に検査がある。
検査役のAIを2つ（Google の Gemini と、案を出したのとは別に立てた Claude）用意し、フックだけを読ませる。台本は渡さない。YouTube が公開しているルール（コミュニティガイドラインや、広告を載せてよい動画のガイドライン）に当たりそうな箇所があれば、ルールの原文を引用して挙げさせる。この検査は、私が Claude と作った小さなプログラムで動く。AIが挙げた引用が原文に本当にあるかも、このプログラムが照らし合わせる。
2つとも、同じ一行に引っかかった。
Gemini は、「人生」と「終わる」が並ぶことで、死や自殺をほのめかすと読める可能性を挙げた。引用されたのは、広告のガイドラインの一節だった。自殺や自傷は、そこで「物議を醸す問題」に分類されている。扱い方によっては、広告を載せる対象から外れる区分だ。
Claude も同じ点を挙げ、それに加えて、「終わる」が中身と違う動画へ誘う言い回しに読める可能性も挙げた。引いていたのは、スパムや欺瞞行為に関するポリシーの一節だ。題名や説明で、謳い文句と違う内容の動画へ誘うことを禁じている。
指摘が出ると、プログラムは「次の工程（台本づくり）に進まない。人が見て判断する」と表示する。ここで止まった。
私にとって「終わる」は、ゲームの言葉だった。上限のある表の、最後の欄のことだ。
だが、初めて見る人の目に入るのは、「人生」と「終わる」の2語だけだ。私のレベル表の事情は、その2行のどこにも書かれていない。
2つ目の指摘は、もっと根が深かった。
この動画が最後に言うのは、「レベルは100で止まっても、記録に、終わりの日は決めていない」だ。
フックで「終わる」と言い、動画の結論で「終わらない」と言っていた。
フックを作り直した。案を出させる条件に、1つ足した。
「人生」と「終わる」（「終わり」「最後」も含める）を、同じ2行に置かない。
決まったのが、これだ。
「毎日をゲームにした。Lv63／100の後に、目標は置かない」
同じ検査に通すと、今度は止まらなかった。通ったのはAIの検査で、YouTube の判定ではない。それでも、私のレベル表の事情を知らない読み手が、フックだけを読んで引っかからなかったことにはなる。
「人生」を「毎日」に替えた。残りの数を見せる代わりに、上限の先の話をすると先に言う形にした。
これで、フックと結論が同じことを言うようになった。100に届いたとき新しい目標を置けば、終わりのある目標がもう1つ増えるだけだ。届けば、また次の目標が要る。だから、100の後には、目標の代わりにやりこみを置く。中身は、196日続けてきたこの記録だ。毎日の行動に経験値を付けることは、レベルが上がらなくなっても続けられる。100の後も続けるこの記録が、私のやりこみになる。フックの「目標は置かない」は、結論の「終わりの日は決めていない」の入り口になった。動画は、この形で YouTube に出した。
ゲームの言葉は、ゲームを知っている人の中でだけ、その意味で読まれる。
だから外へ出す前に、ゲームを知らない読み手に、その言葉だけを渡して読ませる。
—

私は、仕事と生活を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つ終えると、報酬の画面のすぐ後に、次の目的地の印が地図に出る。
終わった瞬間に、次の行き先が見える。だからプレイヤーは、そこでコントローラーを置かない。
台本に置いた問いが、この印にあたる。答えを受け取った視聴者に、次の行き先を見せる。だから、そこで動画を止めない。
答えは、話の終わりではない。
答えの次に、問いを置く。
—