# 1往復目の批評（codex） - 日時: 2026-11-14 20:21（JST） - モデル gpt-6.1-sol・考える深さ medium・82秒・34,104 トークン --- ## 案A ### この案のいちばん尖っている所（守る・もっと強めるべき所） **「日本語で頼めるAIが、目の前のペン1本を片づけられるか」を、実物と回数で決着させる所。** 誰でも成功・失敗を判定でき、最後まで見る理由もある。「頼み直し○回」は残す。 さらに、頼むたびに「何ができるようになったか」を見せたい。つかめた、持ち上がった、入口まで届いた、と進展が見えれば、失敗も続きを見たくなる材料になる。 ### 弱い所と、その直し方（弱い所1つにつき、必ず具体的な直し方を書く。「弱い」だけの指摘は書かない） - **「コードを1行も書かず」が、準備まで不要に見える。** → 冒頭で「接続と動作範囲の設定は準備済み。ここから人はコードを書きません」と明示する。既存の制御ソフト、カメラの有無、AIに渡した機体情報も一画面で示す。人が座標を教えた場合は、それも介入として記録する。 - **頼み直し回数の数え方が曖昧。** → 最初の依頼を「初回」、その後の人による追加指示を「頼み直し」と定義する。AI自身のコード修正回数と、実機を動かした回数は別に数える。物の配置と成功条件を固定し、「手を離してペンが立った状態を3秒保つ」を成功にする。 - **失敗の原因と結論を、撮影前に決めている。** → 「たぶん失敗」「失敗の多くは世界の見え方」を外し、観察後に説明する。原因候補は「位置」「つかみ方」「動作順序」として画面に置き、一度に変える条件を絞る。「確認手順を足したら改善した」と言う場合も、実際の前後映像を添える。 - **2時間の試行が、似た失敗の繰り返しになり得る。** → 撮影は準備30分、挑戦90分、結果整理30分を目安に区切る。本編では「最初の動作」「最大のつまずき」「最後の挑戦」を中心に編集し、全試行の結果は一覧で残す。成功した場合は同じ条件でもう一度試し、偶然の1回かも見せる。 ### 事実の直し（間違い・言い過ぎ・出典がない所を、事実の範囲で一番強い言い方に書き直す。出典の URL と日付を添える。確かめられなければ「未確認」） - **「AIに頼むだけでロボットが動く」** → 「AIに日本語で制御プログラムの作成・修正を頼み、この環境で実機を動かせるか試す」。Claude Codeはコードの編集や実行などを行う道具であり、今回のアームを動かせるかは実験で確かめる事項。 出典：[Anthropic公式発表](https://www.anthropic.com/news/claude-3-7-sonnet)、2025年2月24日。 - **「AIは、ペンがどこにあるかは教えないと分からない」** → 「この実験では、ペンの位置をAIが何から知るのかも確かめる。画像を渡すのか、人が座標を教えるのかで、任せている仕事が変わる」。今回の画像入力・位置計測の構成は**未確認**。 - **「人なら1秒」「文章や画像なら一発」「失敗の多くは世界の見え方」** → 「人には簡単に見える片づけを、この環境では何回の指示でできるか確かめる」。秒数と失敗原因は**未確認**。測定前の断定を、実験の問いに変える。 - **「手元の機体はmechArm 270 Pi」「エイイチが外部レビュー省略を決定」** → いずれも、提供された作り手の条件からは**未確認**。メーカーに機種が存在することと、本人が所有していることは分ける。決定事項として載せるのは実際に確認した内容だけにする。 出典：[メーカー公式製品資料](https://docs.elephantrobotics.com/docs/mecharm-pi-en/2-serialproduct/2.6-mecharm_270/2.6.1-mechArm.html)、公開日記載なし・2026年11月14日確認。 - **利用料** → 「撮影当日の契約方式と、この実験に対応する費用を表示する」。月額料金と実験ごとの従量課金は分ける。回数・時間・費用の実測値と記録URLは**未確認**。 ### もっと見られるための一手（題名・サムネイル・冒頭・見せ場のどれか1つを、具体的な文で） **題名を短くし、課題と制約を先に出す。** > AIに「ペンを片づけて」と頼んだ。人はコードを書かずに、ロボットはできるか？ --- ## 案B ### この案のいちばん尖っている所（守る・もっと強めるべき所） **「データセンターの捨てる熱で、食べられるエビを育てる」という意外性。** AIに詳しくない人にも伝わる、強い入口になっている。 もう一段強くする鍵は、「莫大な熱」よりも**「比較的低温で使い道が限られる熱を、養殖の加温に合わせる」**という工夫。ここを図で理解できる動画にする。[4社共同発表、2026年11月13日](https://www.ntt.com/about-us/press-releases/news/article/2026/1113.html) ### 弱い所と、その直し方（弱い所1つにつき、必ず具体的な直し方を書く。「弱い」だけの指摘は書かない） - **中盤以降が「物理って面白い」の繰り返しになる。** → 本編を「何度の熱が取れるか」「水温を保てるか」「設備・運転費を含めて得になるか」の3問で進める。公表されていない数値は「未公表」と表示する。視聴者が実証の成否を見る物差しを持てる構成にする。 - **開発者の視点が、熱への感想にとどまっている。** → 「ロボットも、目標を言うだけでは動かない。測って、動かして、結果を確かめる。養殖の水温管理も同じ観点で見る」とつなぐ。温度計→制御→加温設備→水槽の図を作り、**考え方を説明する模式図**と表示する。実際の設備構成と混同させない。 - **利益の比較表に、計算の根拠がない。** → 表を「従来の加温費」「回収・供給設備費」「追加の運転費」「保守費」の比較に直す。数値を入れるなら仮定と明記し、条件を変えると採算がどう変わるかを示す。エビの売上を丸ごと排熱利用の利益に数えない。 - **借りたGPUで学習しているのに、自宅の排熱を実体験として撮ろうとしている。** → 実際の学習ログを見せ、「計算は借りたGPUで行っています」と説明する。手元のPC映像は操作端末として使う。新規の3D制作はハコブくんと簡単な矢印の図に絞り、撮影時間を確保する。 ### 事実の直し（間違い・言い過ぎ・出典がない所を、事実の範囲で一番強い言い方に書き直す。出典の URL と日付を添える。確かめられなければ「未確認」） 以下のニュース事項は、検索の要約ではなく、[4社共同発表の本文](https://www.ntt.com/about-us/press-releases/news/article/2026/1113.html)で確認。発表日は**2026年11月13日**。 - **「共同実証を開始」「東京都の事業に採択」** → 確認できる。出典はトップページから、上記の発表本文へ差し替える。 - **「AIの熱でエビや魚を育てる」** → 「データセンターの排熱で、バナメイエビを育てる実証へ」。対象施設の排熱がAI計算由来に限定されるかは**未確認**。今回の飼育対象として魚は記載されていない。 - **「プロジェクトが始まり、エビを育てている」ように見える表現** → 「2026年度に排熱の回収方法を評価し、2027年度にバナメイエビを飼育する計画」。開始したプロジェクトと、今後の飼育を分ける。 - **「熱をそのまま使う」「究極の物理的解決」** → 「回収した熱を飼育水の加温に使い、水温維持と加温エネルギーの削減効果を検証する」。追加設備の方式・消費電力、削減率、採算は**未確認**。成果が出る前に解決済みとは言わない。 - **「熱が食料に変わる」「この循環がないとAIやロボットの未来は成り立たない」** → 「捨てていた熱を、食料生産に必要な加温へ回せるか。その成立条件を調べる実証だ」。熱の役割を具体化し、未来全体への断定を外す。 ### もっと見られるための一手（題名・サムネイル・冒頭・見せ場のどれか1つを、具体的な文で） **題名に、意外性と本編で解く疑問を両方入れる。** > 捨てる熱でエビを育てる？ NTTなど4社の実証、何を確かめるのか 発表を紹介するだけで終わらず、「成功する条件まで分かる」ことを約束できる。