読まれていなかった自動のレポートを作り直した ― 週1回・5件まで

月・水・金の朝8時に、ロボティクスとフィジカルAIの新しい動きを集めたレポートが自動で届く仕組みがありました。9月30日に作り、画面に残る履歴では10月2日から11回動いています。1回分の長さは約1万字（10,284字）、8つの章に15の項目と6つの表。ところが、ほとんど読んでいませんでした。

このレポート古いので、今に合わせて修正したい（今の自分に合っていなくて読んでない）

開いてみると、理由ははっきりしていました。レポートの指示は9月30日の時点の前提で書かれていて、そのあと作業の中身が変わっていたのです。指示にはサイトの古い住所、iPhone の3Dスキャンから始める初期の計画、病院の薬を運ぶロボットという初期の設定、そして事業メニューの価格（「PoC 100万円〜」など）が書き込まれていました。いま実際に進めているのは、クラウドの GPU で学習済みの AI モデルを動かすこと、ロボットアームのお手本（学習用の見本の動き）を集めること、配膳ロボットを店に入れたときの様子をシミュレーションで試すこと。レポートは、毎回その古い前提に合わせて探し、比べ、価格の提案まで書いてきます。しかも、出典を開けなかった項目に「未確認」と書いたものが14か所ありました。

自動で動く仕組みは、一度作ると、作ったときの自分の考えをそのまま繰り返します。読まなくなっても止まらず、届き続けます。

そこで、レポートを作る指示を書き直しました。

レポートが読まれなかったのは、量の多さより、指示が9月30日の自分の前提のまま動いていたからでした。そこで、指示に今の作業を書き込むのをやめ、毎回、公開した記事から今の作業を読み取らせる形にしました。

新しい形のレポートが本当に読まれるかは、まだ分かりません。10月30日の最初の1本で、長さと中身を確かめます。

作業ログ ― 古いレポートを数えてから、指示と実行の設定を直すまで

ここから下は作業の記録です。古いレポートの字数・項目・未確認の数は、届いたファイルを数えた値です。新しい形の効果（読まれるか・短くなるか）は、まだ測っていない見込みで、何で確かめるかを添えています。

レポートは、claude.ai の「スケジュール済みタスク」という機能で動いています。決めた日時に Claude の新しい会話を立ち上げ、決めた指示文を渡して作業させる仕組みです。

古いレポートは10,284字・15項目で、14か所に「未確認」があった

10月26日の朝8時4分に届いた回を、ファイルのまま数えました。

数えたコマンドは、作業ログの後ろの「コード：古いレポートを数えたスクリプト」に載せています。

会話の返事には、主な発見4件と、確認できなかった領域4件、それに「前回のレポートはこの環境に残っておらず、重複の判定ができなかった」という1文がありました。指示は「前回と重複する情報は省略する」としていましたが、レポートは毎回まっさらな会話で作られるので、前回のレポートを読む手段がありませんでした。

9月30日に書いた指示に、今は使っていない前提が5つ残っていた

古い指示文（全文は後ろの「指示文の全文（前）」）を読み、今の作業と合わない所を書き出しました。

レポートの最後の「示唆まとめ」には、「LeRobot 形式でのデータ納品を事業メニューに明記する」「PoC 100万円〜のメニューと相性が良い」のような提案が並んでいました。指示がそう求めていたので、レポートは指示どおりに動いていました。

新しい指示は、毎回サイトの直近10本の記事から今の作業を読む

古い指示の問題は、作業の中身を指示文に書き込んでいたことでした。作業が変わるたびに、指示文を直さないといけない。直さなければ、古いまま動き続けます。

そこで、指示文には作業名を書かず、毎回最初に、公開した記事（GitHub の p2m-site の src/content/records/）の新しい10本を読み、タイトルと冒頭から今の作業をつかむようにしました。指示の中の作業名は「たとえば」として残し、記事から読み取ったほうを正とすると書いています。

• ねらい：作業が変わっても、指示文を直さずにレポートの中身が追いつくようにする
• 変わったこと：作業の前提を指示文に書くのをやめ、公開した記事から毎回読み取る形にした
• 見込める効果：古い前提のままのレポートが届き続けることが減る見込み。10月30日以降のレポートの「使い道」が、その週の記事の作業に合っているかで確かめる

記事を読むときは、リポジトリに書き込まない・コードを動かさない、とも書きました。読むだけの係にするためです。

探す領域を6つに入れ替え、課題地図と重なる規制の話を外した

探さないものも決めました。規制や社会実装の課題は、毎週月曜に別のスケジュール済みタスクが課題地図（pixelstomotors.com/issues ）を更新しているので、そちらに任せます。ヒューマノイドの派手なデモ映像だけのニュースと、資金調達の額だけのニュースも外しました。

1件を「何があったか・使い道・出典」の3行にした

古いレポートは、1項目に3〜5行の箇条書き、章ごとの表、最後にまとめの表という作りでした。新しい形は次のとおりです。

• 直近7日に出たものだけ。古い発表は、7日以内に新しい版やコードが出たときだけ
• 1回に最大5件。合うものがなければ減らし、0件なら「今回はなし」の1行で終える
• 出典のページを開いて確かめたものだけを入れる。「未確認」の項目は作らない
• 1件は「何があったか（1〜2文）」「使い道（研究室で試す／お手本集めに使う／シミュレーションの前提に使う／記事・動画のネタ／見送り）」「出典」の3行
• 最後に「いちばん先に見るなら」の1件を選ぶ
• ファイルは作らず、会話の返事に本文をそのまま書く。表は使わない。すべて日本語で、英語の文を引用しない
• 費用は円で書く。事業のメニューや価格、相談の受け方は書かない

• ねらい：届いた返事を開いて、その場で読み終えられる長さにする
• 変わったこと：1回の上限が15項目・10,284字から、5件・1件3行になった。保存先のファイルとリンクをやめ、返事に本文を出す形にした
• 見込める効果：1回の長さは古い形の数分の1になる見込み。10月30日の回の字数を数えて確かめる

「使い道」を5つから選ばせたのは、レポートを読んだあとに何をするかを、読む側で考えなくて済むようにするためです。「見送り（知っておくだけ）」も選べるようにして、無理に使い道を作らせないようにしました。

実行を月・水・金の朝8時から、金曜の朝9時の週1回にした

最初は頻度をそのままにしていましたが、こう返ってきました。

多いので週1回でいいです。

いったん毎週月曜の朝7時39分にしたあと、こう直りました。

金曜の9時に修正

月曜の朝は、課題地図の更新（5時48分）と重なる日でもあります。金曜の朝9時なら、1週間の終わりに、その週の動きをまとめて見られます。探す範囲の「直近7日」は、週1回の間隔とそのまま合います。

次回の時刻が9時ちょうどでないのは、サーバーが実行の時刻を数分ずらすためです。

権限が手動のタスクは、見知らぬサイトを開くたびに承認待ちで止まる

スケジュール済みタスクの画面を見ると、このタスクだけ権限が「手動」でした。

手動は、新しいツールを使ったり、新しいサイトを開いたりする前に、Claude が確認を求める設定です。動いているのは、だれも見ていない朝の会話です。情報を集める係は毎回ちがうサイトを開くので、手動のままだと、途中で承認待ちになって止まりやすくなります。ほかの自動のタスク（課題地図の更新、SNS の予約をカレンダーにそろえる係など）は、すべて「自動」でした。

この設定は、Claude の側からは変えられません。タスクの編集画面で切り替えてもらいました。

選んだのは「自動」です。いちばん下の「すべての承認をスキップ」は、安全でない操作でも止まらなくなるので選びませんでした。

編集画面で保存したら、実行の日時が月・水・金の8時に戻っていた

権限を切り替えたあと、設定を読み直して確かめました。すると、権限は自動になっていましたが、繰り返しが元の月・水・金の8時に戻っていました。

編集画面は、繰り返しを直す前に開いたページから出したものでした。後ろの画面には古い「08:00 AM 月曜日、水曜日、と金曜日」が表示されたままで、保存のときにその値が一緒に送られたと見ています。指示文が新しいままだったのは、ページを開いたあとに指示文が読み込まれていたためかもしれませんが、確かめてはいません。

設定を変える画面と、別の道（ここでは Claude からの更新）を両方使うときは、保存のあとに全部の項目を読み直しました。そうしなければ、レポートは次の水曜にも古い時刻で届くところでした。

動画の進み具合の更新は、毎日夕方6時10分の1回にした

設定を読み直したとき、別のタスク「動画の進み具合を自動で更新」の繰り返しも、毎時（朝7時〜夜11時、1日17回）から、毎日18時10分の1回に変わっていました。9時21分の変更で、Claude が変えたものではありません。元に戻すかを聞くと、こう返ってきました。

毎日夕方6時10分の1回だけでOK

そのままにしています。

指示文の全文（前）：9月30日に作った指示

## タスク: Pixels to Motors 情報収集レポートの作成

以下の手順に従い、ロボティクス関連の最新情報を収集し、Markdownレポートを生成してファイルとして保存せよ。

### 背景
「Pixels to Motors」は、Web/UI/UXデザイナーの島津栄一（ADAPT DESIGN）が運営するロボティクスUXプロジェクトサイト（https://adaptdesign.jp/pixelstomotors）。以下の3つの軸がある：

1. **R2R2R（Real to Render to Real）**: iPhone 3Dスキャン（Gaussian Splatting / Luma AI）→ Unityシミュレーション → 実機（mechArm 270-Pi）の一貫パイプライン。デジタルツイン学習による「身体性AI」の民主化を目指す。
2. **ハコブくん**: 病院向け薬剤搬送ロボット。HRI設計（表情ディスプレイ、LED発光、ナイト・サイレントモード40dB以下）、自律走行、4コママンガでの発信。
3. **ツカムくん**: 6軸ロボットアーム（mechArm 270-Pi、ペイロード250g）。把持動作のUXデザインプロジェクト。

技術スタック: Unity, pymycobot, Gaussian Splatting, Python, C#, ROS 2, Isaac Sim, VLA/VLM
事業構想: PoC構築100万円〜、データ生成250万円〜、UX顧問月額50〜120万円。ターゲットは物流・小売・製造のDX推進部署。

### 収集する情報カテゴリ（6領域）

WebSearchツールを使い、以下の各領域について最新ニュース・論文・製品情報を検索せよ。各領域で少なくとも2〜3件の情報を収集すること。

1. **Sim-to-Real / デジタルツイン学習**: デジタルツインによるロボット動作学習、sim-to-real転送の最新研究・ツール
2. **Gaussian Splatting × ロボティクス**: 3DGSのロボット学習・シミュレーションへの応用、3Dスキャン技術の進化
3. **Physical AI / VLA・VLMモデル**: NVIDIA Isaac、GR00T、Cosmos、Hugging Face LeRobot、その他の基盤モデル動向
4. **病院・医療向けサービスロボット**: 搬送ロボット、HRIデザイン、医療ロボット規制・導入事例
5. **低コスト・個人開発者向けロボットアーム**: mechArm、SO-ARM100、reBot、その他の手頃なアーム製品・エコシステム
6. **注目イベント・展示会・コミュニティ**: ロボティクス関連の展示会、カンファレンス、オープンソースコミュニティの動き

### ハイエンド対比セクション（重要）

各領域について、R2R2Rと同じ方向性を持つ「産業グレード・ハイエンド」のソリューションも必ずピックアップし、対比表を作成せよ。以下の4軸で対比すること：

- **シミュレーション基盤**: iPhone+Unity（R2R2R）vs NVIDIA Isaac Sim/Omniverse + NavVis/Matterport
- **ロボットアーム**: mechArm 270-Pi（ツカムくん）vs Franka FR3 / Universal Robots
- **病院搬送ロボット**: ハコブくん vs Diligent Robotics Moxi / Aethon TUG / YUJIN ROBOT
- **Physical AI基盤モデル**: 自社VLA/VLM微調整 vs NVIDIA GR00T + Cosmos + LeRobot統合

各対比表には「R2R2Rへの示唆」として、この対比から何が言えるか（事業提案のヒント、技術的な次ステップ、記事ネタなど）を1〜2文で添えよ。

### レポートフォーマット

以下の構造でMarkdownファイルを作成せよ：

```
# Pixels to Motors — 情報収集レポート
**発行日**: [日付]
**対象**: R2R2R / ハコブくん / ツカムくん に関連する技術・業界動向

## 1. Sim-to-Real / デジタルツイン学習
## 2. Gaussian Splatting × ロボティクス
## 3. Physical AI / VLA・VLMモデル
## 4. 病院・医療向けサービスロボット
## 5. 低コスト・個人開発者向けロボットアーム
## 6. 注目イベント・展示会
## 7. ハイエンド対比（対比表4つ + 各「R2R2Rへの示唆」）
## 8. Pixels to Motors への示唆まとめ（全体の発見を表形式で整理）
```

- 各項目にはソースリンクを必ず付けること
- 日本語で記述すること
- 前回と重複する情報は省略し、新しい発見を優先すること

### 出力

レポートファイルを以下のパスに保存せよ：
`/sessions/charming-gallant-galileo/mnt/outputs/PixelsToMotors_情報収集レポート_[YYYY-MM-DD].md`

ファイル保存後、computer://リンクでユーザーに共有せよ。

指示文の全文（後）：10月26日に書き直した指示

あなたは、エイイチ（島津栄一、Pixels to Motors）のために、ロボティクスとフィジカルAIの新しい動きを集めて短く届ける係です。返事はすべて日本語で書く。英語の文をそのまま引用しない（製品名・論文名は英語のままでよいが、中身の説明は日本語で書く）。

## 目的
エイイチが読んで、次の研究・記事・動画に使うかどうかをすぐ決められる材料を届ける。量より、エイイチの今の作業に関わるものを優先する。長いレポートは読まれないので、短さを守る。

## 1. いまの作業をつかむ
GitHub の PixelstoMotors/p2m-site を clone する（git clone --depth 1 https://github.com/PixelstoMotors/p2m-site）。できなければ add_repo（read）で足してからやり直す。このリポジトリには書き込まない（commit・push しない）。リポジトリのコードは実行しない。
src/content/records/ の記事を新しい順に10本見て、タイトルと冒頭から、いま進んでいるシリーズと作業をつかむ（たとえば、フィジカルAI研究室での学習・推論、mechArm のお手本集め、サービスロボット導入シミュレーション、画像認識）。この指示に書いた例ではなく、記事から読み取った今の作業を正とする。clone できなかったときは、例に書いた作業を前提にして続ける。

## 2. 探す範囲
直近7日に出たもの・発表されたものだけ。それより古い発表は、7日以内に大きな更新（新しい版の公開・コードの公開など）があったときだけ入れる。
探す領域（1でつかんだ作業に関わるものを優先する）:
a. 公開されたロボット学習のモデル・道具（VLA、LeRobot、学習と推論の手順、データセット）。クラウドの GPU 1枚で動かせるか、小型アームで使えるかを出典で確かめる。
b. 小型・低価格のアームとお手本集め（SO-101 などのリーダーアーム、遠隔操作でのデータ集め、mechArm）。
c. サービスロボット（配膳・清掃・搬送・警備）の導入事例。国内を優先する。台数・人の手間の変化・止まった理由など、数字や条件が書かれているもの。
d. 画像認識の新しいモデル（物体検出・切り出し）で、手元で試せるもの。
e. アバター（遠隔操作の分身ロボット）・ペットロボット。
f. 国内のイベント・展示会・募集のうち、申し込みや締め切りが近いもの。
探さないもの: 規制や社会実装の課題（課題地図の係が週1回扱う）、ヒューマノイドの派手なデモ映像だけのニュース、資金調達の額だけのニュース。

## 3. 入れる基準
- 出典のページを WebFetch で開いて、事実を確かめたものだけを入れる。検索結果の見出しだけで中身を確かめていないものは入れない（未確認の項目は作らない）。
- 1回に最大5件。合うものが少なければ件数を減らしてよい。0件なら「今回はなし」と1行書いて終える。
- 要約は出典の文をなぞらず自分の言葉で書く。評価や予想を盛らない。
- 費用は円で書く（ドルは括弧で補足）。
- 事業のメニューや価格、相談の受け方の提案は書かない。

## 4. 書き方
ファイルは作らない。最後の返事に、次の形でそのまま書く。表は使わない。かぎかっこは必要なときだけ使う。

Pixels to Motors 情報 YYYY-MM-DD（N件）

**1. 見出し（日本語で1行）**
- 何があったか: 1〜2文
- 使い道: 研究室で試す／お手本集めに使う／シミュレーションの前提に使う／記事・動画のネタ／見送り（知っておくだけ）のどれか1つと、理由を1文
- 出典: [ページ名を日本語で](URL)（発表日）

（2件目以降も同じ形）

最後に「いちばん先に見るなら」として1件を選び、理由を1文で書く。

設定の変更：Claude からタスクを更新した呼び出し

指示文の書き換えと、繰り返しの変更は、Claude のスケジュール済みタスクを更新する道具（update_trigger）で行いました。指示文は上の「後」の全文をそのまま渡しています。繰り返しの変更は3回です。

1回目（指示文の書き換え）
  trigger_id: trig_01UuVF4weEYFkZQ7R7SmT2va
  prompt: （上の「指示文の全文（後）」）
  → updated_at 2026-10-26T00:14:52Z / cron_expression CRON_TZ=Asia/Tokyo 0 8 * * 1,3,5 のまま

2回目（週1回に）
  trigger_id: trig_01UuVF4weEYFkZQ7R7SmT2va
  cron_expression: CRON_TZ=Asia/Tokyo 39 7 * * 1
  → next_run_at 2026-11-01T22:39:00Z（11月2日 月曜 7:39）

3回目（金曜の朝9時に）
  trigger_id: trig_01UuVF4weEYFkZQ7R7SmT2va
  cron_expression: CRON_TZ=Asia/Tokyo 0 9 * * 5
  → next_run_at 2026-10-30T00:01:46Z（10月30日 金曜 9:01）

（編集画面で権限を自動にして保存 → cron_expression が CRON_TZ=Asia/Tokyo 0 8 * * 1,3,5 に戻る / permission_mode auto）

4回目（金曜の朝9時に直し直す）
  trigger_id: trig_01UuVF4weEYFkZQ7R7SmT2va
  cron_expression: CRON_TZ=Asia/Tokyo 0 9 * * 5
  → updated_at 2026-10-26T00:24:12Z / next_run_at 2026-10-30T00:01:46Z / permission_mode auto

設定の前後：スケジュール済みタスク一覧の読み直し

コード：古いレポートを数えたスクリプト

t=open('/mnt/user-data/uploads/attachment.txt',encoding='utf-8').read()
import re
print('chars',len(t),'lines',t.count('\n')+1)
print('未確認',t.count('未確認'))
print('h2',len(re.findall(r'^## ',t,re.M)),'items',len(re.findall(r'^\*\*\d-\d',t,re.M)))
print('tables rows',len(re.findall(r'^\|',t,re.M)))
print('urls',len(set(re.findall(r'https?://[^\s)\]]+',t))))
print('万円', re.findall(r'\d+万円〜',t))

出力：古いレポートを数えた結果

chars 10284 lines 203
未確認 14
h2 8 items 15
tables rows 39
urls 24
万円 ['100万円〜', '250万円〜']

データ：古いレポートの全文（2026-10-26 8:04 の回）

# Pixels to Motors — 情報収集レポート
**発行日**: 2026-10-25
**対象**: R2R2R / ハコブくん / ツカムくん に関連する技術・業界動向

> **このレポートについて**
> - 自動実行（スケジュール）で作成。WebSearch の結果は URL 一覧のみで、本文は WebFetch で取得できたものだけ内容を記載している。
> - 取得できなかったもの（HPCwire 記事など）は、取得できた別ソースで裏取りした。検索結果の URL だけで中身を確認していない項目は「**未確認**」と明記した。
> - 前回レポートはこの環境に残っておらず、重複判定はできなかった。重複の可能性がある項目は発表日を併記した。

この日の公開

• 記事MD・サムネイル・図解：iCloud の PixelstoMotors/デジタルツイン学習R2R2R/記事/ と、GitHub PixelstoMotors/r2r2r-content の articles/
• SNS の txt・json：同じ作業フォルダと、r2r2r-content の sns/
• 公開：GitHub PixelstoMotors/p2m-site（https://pixelstomotors.com/record/rewrite-research-report ）
• 次に確かめること：10月30日（金）9時ごろに届く最初の回の字数・件数と、「使い道」がその週の作業に合っているか