ニューラルネットワークの出番は実店舗の映像 ― Unityの配膳ロボットが教材になる

ニューラルネットワークは、規則で書ききれない所に、外れても人が困らない形で入れるものだ。Unity で作った配膳ロボットのシミュレーションでは、ロボットがどこで止まったかはログに全部残っているので、止まりを見つけるだけなら規則で足りる。ニューラルネットワークの本当の出番は、ログのない実店舗の映像のほうにあった。 これは実物の店ではなく、Unity の3Dで再現したファミレスと、このサイト（pixelstomotors.com）を題材にして、Claude（Anthropic の AI）と話しながら考えた記録だ。

この整理で、次の3つが手に入る。

• 自分のサイトや研究にニューラルネットワークを入れるとき、どこから入れるかの見分け方。規則で書けるか、外れたときに人が困るか、の2つで候補を並べる
• Unity のシミュレーションを、正解つきの教材として使う道筋。ふつうは人が1枚ずつ付ける正解を、Unity のログが自動で付けてくれる。夜に回すほど教材がたまる
• 作る前に止める判断。記事を意味で探す仕組みは、サイトの計測を見て、作らずに待つことにした。手を動かす前に計測を見たので、使われないかもしれない仕組みに時間をかけずに済んだ（作った場合の時間は見積もっていない）

最初は、ニューラルネットワークを使ったプロダクトとは何か、という一般的な問いから入った。Claude が候補を挙げ、いちばん先に手を付けるとしたのは、Unity の録画から配膳ロボットが止まった場面を拾う案だった。ところが中身を詰めていくと、Unity は止まった時刻・場所・原因をログに全部残している。録画から拾い直す必要はなかった。

もう一つの候補だった、記事を意味で探す仕組みも、詰めるうちに向きが変わった。サイトの計測を見ると、AI は利用者の質問を受けて自分で検索し、記事を1本ずつ開いて答えていた。AI 向けの案内のページ（llms.txt）が読まれたのは、13日で2回だけだった。

これは実験の記録ではなく、対話しながら考えた記録だ。録画の数字は、前に公開したサービスロボット導入シミュレーション Log#28（LOG418）の結果をそのまま使い、サイトの数字は、このサイトの計測（2026-10-26〜11-07）から引いた。

作業ログ ― Claude との対話を、そのまま残す

ここから下は、対話の全量です。私の発言を引用で、Claude の答えを本文で載せています。各節の頭の太字の一文は、その節で Claude が答えようとした問いです。記事化の段取りのやり取りは外しました。Claude の答えの中の太字は記事の太字の決まりに合わせて外しています。対話の中で Claude が出した図は、記事の図解（下）にまとめ、対話の中では何の図だったかを一行で書いています。各節の後ろに、補足を足しました。

この記事に出てくる言葉

ニューラルネットワークでプロダクトを作るとは、規則の代わりに例から覚えさせること

ニューラルネットワークを使ったプロダクトやサービスをつくるという考えについて教えてください。 現行のサイトやプロジェクトなどをニューラルネットワークを使って変えていく時にどんなことが必要になりますか？

またニューラルネットワークを使ったプロダクトやサービスがあれば詳しく教えてください。

— ニューラルネットワークでプロダクトを作るとき、何が変わり、何が要るのか。

ふつうのソフトは、人が規則を書きます。料金が○円以上なら送料無料、のように。ニューラルネットワークでは規則を書かずに、例を大量に見せて規則を覚えさせます。猫の写真を何万枚も見せると、猫の見分け方を自分で身につける、という作り方です。

この違いから、プロダクトの中心にあるものが変わります。コードよりも、どんなデータを集めるか、何をもって良くなったとするか、が品質を決めるようになります。

もうひとつ大きいのは、ニューラルネットワークは必ず間違えることです。確率で答えるので、正答率が99%でも100回に1回は外します。だから、間違えたときに人がどう困らずに済むかを設計した製品だけが、現場で使われ続けます。配膳ロボットのシミュレーションで決めた、30秒動けなければスタッフが来て動かす、という運用がまさにこれです。精度をあとから上げるのは技術でできますが、外れたときの逃げ道は最初から体験として組んでおく必要があります。エイイチさんの、精度より体験の成立を先に、という考え方がいちばん効く場所はここです。

今のサイトやプロジェクトを変えるときに要るもの。

一番の要は、どこに入れるかを選ぶことです。向いているのは、人が見れば分かるのに規則にすると書ききれない所です。写真や動画を見て判断する、言葉の意味をくむ、動きを滑らかにする、といった所ですね。逆に、計算で答えが一つに決まる所（試算の式など）は、今のまま規則で書いた方が速くて安く、説明もしやすいです。

そのうえで、次の4つを用意します。

データ　何を入れて何を正解とするかを決め、ため続ける仕組みを作ります。台帳や保存先の決まりがすでにあるのは、この点でかなり強いです。

良し悪しの物差し　直す前と後を同じ条件で比べる数字と、比べるためのデータの組を固定しておきます。基準データを v4、v5 と区切ってきたやり方がそのまま使えます。

外れたときの扱い　人に戻す、確認を挟む、やり直せる、のどれにするかを決めます。

運用の費用と遅さ　自分で一から学習させるのか、既存のモデルを借りるのか（Claude などを呼び出す）、既存のモデルを少しだけ追加で学習させるのか。π0.5 に LoRA（モデル全体は変えずに、小さな追加部分だけを学習させるやり方）を貼っているのは三つ目にあたります。呼ぶたびにお金と時間がかかるので、どこまで使うかの線を引く必要があります。

今のプロジェクトに当てはめると、すぐ効きそうなのは次のあたりです。

• 観察シート　店の写真や図面から、席の数や通路の幅を先に読み取って、埋まらない所だけ手で打つ形にする。以前考えていた形は、画像を読み取るニューラルネットワークでそのまま作れます。
• サイト　記事を言葉の一致ではなく意味で探せるようにする。訪れた人の質問に、LOG の全文を元に答える。LOG を全文で残しているので、相性がとても良いです。
• シミュレーション　ロボットと人の動きを部品として切り出す設計を進めていますが、その部品の中身を、あとで学習した動き方に差し替えられます。Unity で何度も回して道の選び方を覚えさせる（強化学習）こともできます。
• 実機の録画　LOG418 で試した PatchCore（正常な画像だけを覚えさせて、見慣れない場面を拾う方法）のように、長い止まりを自動で拾う仕組みを夜の録画に常に掛けておく。

実際のプロダクトの例。

表を縦に見ると、うまくいっている製品は、外れても困らない場面を選んでいるか、外れたら人や別の方法へすぐ戻れるか、のどちらかです。写真の検索やおすすめは、外れても誰も困りません。顔認証や自動運転は外れると困るので、パスコードや遠隔の担当者という戻り先を必ず持っています。

もうひとつの共通点は、使われるほど良くなる仕組みです。TikTok は、見た・飛ばしたという反応がそのまま次の学習データになります。π0.5 で失敗した区間を巻き戻して補正し、学習データにしているのも同じ形です。ニューラルネットワークの製品で強いのは、モデルそのものより、このデータが自然にたまっていく流れを持っているかどうかです。

配膳ロボットの多くは、地図の上を決まりで動く部分が大きく、ニューラルネットワークは周りを見る部分などに使われています。全部をニューラルネットワークにしなくても製品は成り立ちます。規則で書ける所は規則で書き、書ききれない所にだけ使う組み合わせが、今の現場では一番の落とし所です。

補足：外れたときの逃げ道は、配膳ロボットの運用にもある

表の右の列は、どの製品も持っている、外れたときに戻る先だ。これは画面の中の製品に限らない。サービスロボット導入シミュレーションで決めた運用にも、同じ形がいくつも入っている。ロボットどうしが向かい合って30秒動けなければ、スタッフが来て片方を動かす。受け渡し口で料理が2分待ってもロボットが来なければ、スタッフが運ぶ。どちらも、ロボットが外れたときに人へ戻す決まりだ。

ニューラルネットワークを入れる話も、ロボットを店に入れる話も、問いの形は同じになる。外れたときに、だれが、どう困らずに済むか。精度の数字を上げる前に、そこを先に決めておく。

一方で、表の製品の中にも、全部をニューラルネットワークで作っているものはほとんどない。顔認証の後ろにはパスコードという規則があり、配膳ロボットは地図の上を決まりで動く。規則で書ける所は規則で書く、という組み合わせが、この対話の最後まで判断の軸になった。

サイトと観察シートで、ニューラルネットワークを入れる候補を2つの軸で並べた

サイトや観察シートのどこから入れるか、候補を図にして並べる

— サイトと観察シートのどこから、ニューラルネットワークを入れるか。

（ここで Claude は、横を入れやすさ、縦を効きにして、サイトと観察シートの候補を並べた図を出した。図は記事の図解の「最初の見立て」にまとめた）

横は入れやすさで、データがもう手元にあるか、外れたときに誰も困らないかで並べています。縦は効きで、店の人が知りたい4つ（どこで・なぜ止まるか、何を変えれば良くなるか、どれくらい良くなるか、スタッフは楽になっているか）にどれだけ近づくかで見ています。

最初に手を付けるなら右上の2つです。

録画から問題の場面を拾う案は、夜に回している Unity の録画がそのまま材料になります。LOG418 の PatchCore の続きで、長い止まりを自動で見つけ、問題の場所に寄る動画の寄り先を決めるところまでつなげます。今は寄り先を人が選んでいるので、ここが自動になると動画の本数を増やしやすくなります。外れても動画を作り直すだけで済み、記録としても研究の側に数えられます。

届いた記録を表に整える案は、LINE やメールで届いた観察シートの文を読み取って field/ の表の形にそろえるものです。届く文は人によって書き方がばらばらなので、規則で読み取ろうとすると書ききれません。言葉を読むモデルが得意な所です。読み違えても、元の文と並べて見比べれば直せます。

左上の2つは効きは大きいものの、少し先になります。図面の画像から店の形を起こす案は他の店へ広げる入口になりますが、テーブルや通路の寸法を読み違えると試算全体がずれるので、確かめの手間がかかります。言葉で試算の条件を入れる案は、うちは30卓でスタッフ3人、と書けば条件がそろう形です。店の人には一番わかりやすいはずですが、呼ぶたびに費用がかかるので、置き方を考える必要があります。

下の3つは急がなくてよい案です。サイトは AI に読ませて使う前提なので、サイトの中で質問に答える仕組みは、訪れた人の AI にやってもらう方向と重なります。声で計測を始める案は、騒がしい店内では聞き取りが外れやすいです。

前回、写真や図面から席の数を読み取って観察シートに入れる案を挙げましたが、シートでは写真を扱わないと決めていたので取り下げます。図面を読むのはシートではなく、届いたあとの受け取る側でやる形に置き直しました。測り間違いを見つける案は、10回測った中で極端な回を知らせるだけなので、ニューラルネットワークを使わず規則で書けば足ります。

補足：並べた候補と、そのときの見立て

図に置いた候補を、そのときの見立てのまま表にしておく。この表の右上の1つ目は、次の節で評価が変わる。

見送りの2つは、それぞれ別の理由で外れている。写真の案は、技術ではなく決まりと合わない。観察シートで写真と動画を扱わないのは、店の人に、お客さんを写さないように、と伝えるのが難しいからだった。測り間違いの案は、ニューラルネットワークを使うまでもない。規則で書けるなら規則で書く、という前の節の軸が、ここでそのまま効いている。

Unity の録画から止まりを拾うだけなら、ニューラルネットワークは要らなかった

Unityの録画から問題の場面を拾う案を詳しく

— Unity の録画から配膳ロボットの止まりを拾う案は、何に効き、どう進めるのか。

（ここで Claude は、上の段に Unity の中の動画づくり、下の段にニューラルネットワークの出番を分けた図を出した。図は記事の図解の「見直した後」にまとめた）

詳しく見ていくと、前回の説明は一つ直す必要がありました。Unity の録画から寄り先を決めるだけなら、ニューラルネットワークは要りません。Unity は、ロボットがいつ・どこで・何が原因で止まったかをログに全部残しています。LOG418 で長い止まりの正解として使ったのも、このログです。動画の寄り先は、ログから30秒以上止まった場面を選ぶ規則で決められて、こちらの方が確実です。

ニューラルネットワークが本当に役に立つのは、ログがない実際の店の動画です。Unity はその練習台として使えます。ふつうの学習では正解を人が一つずつ付けますが、Unity ならログから正解が自動で付きます。夜に回すほど、正解つきの教材がたまっていきます。

LOG418 で分かっている出発点。

道の線が描かれた録画では、長い止まりを72%拾えました。ところが実際の店のカメラにはない道の線を消すと、28%まで落ちます。特に、ロボットどうしの詰まりは47回中4回、スタッフとのすれ違いは18回中3回しか拾えていません。お客さんとのすれ違いだけは、線がなくても17回中13回拾えました。ロボットの白とお客さんの服の色の差が画面に出るからです。

もう一つ大事なのは、1枚の画像では止まりが長く続くかどうかがまったく分からなかったことです。長い止まりと短い止まりの見分けは 0.51 で、当てずっぽうと同じでした。止まりの長さは時間の話なので、1コマを見ても分からないのは当然でした。

次にやること。

まず、1枚ではなく数秒分の動きを続けて見せるモデルに変えます。ロボットが同じ所にいて、まわりの人だけが動いているか、といった変化は時間の流れの中にしか出ません。

次に、覚えさせ方を変えます。PatchCore は普段の画像だけを覚えて、見慣れない絵を怪しいとする方法です。正解がない場面向けのやり方ですが、Unity ではログの正解があります。止まった原因を、もう1台のロボット・スタッフ・お客さん・人が立ち止まっていた、の4つから当てさせる形に変えると、拾えたかどうかに加えて、なぜ止まったかまで出せます。店の人が一番知りたい、どこで・なぜ止まるか、にそのまま答える形になります。

物差しは LOG418 と同じにしておきます。誤報を5%に固定し、覚えさせた回とは別の回で確かめ、線なしの28%からどこまで上がるかを見ます。数秒分の動きを扱うとクラウドの CPU 2コアでは足りなくなりそうなので、GPU を時間で借りて処理時間と費用を測ってから決めます。

そのあと、共有してもらっている実際の配膳ロボットの動画で試します。Unity の絵と実際の店の映像は見た目がかなり違うので、Unity で覚えたことが実際の映像でどこまで通じるかが、ここで初めて分かります。拾えなかった場面は、Unity の録画をどう実物に近づけるか（カメラの角度、床や人の見た目）の手がかりになります。斜めのカメラ（60°見下ろし）で撮った録画は、店の天井カメラに近いので教材に向いています。

外れたときと、先の使い道。

拾い漏れや誤報は必ず出ます。ただ、この仕組みは怪しい場面を人に見せる所までの役目なので、最後は人が動画を見て判断すれば困りません。

うまくいけば、店に入れた配膳ロボットがどこで止まっているかを、店の人がストップウォッチで測らなくても数えられるようになります。観察シートの手間を減らす方向にもつながります。ただし店の映像にはお客さんが写るので、映像を外に出さず、店の中で処理して止まった回数と場所だけを出す形が前提になります。シートで写真や動画を扱わないと決めた理由とも、これで食い違いません。

記事にするときは、LOG418 と同じくサービスロボット導入シミュレーションの記事として書く形になります。最初の一歩は、線なしの録画の数を増やすところからです。夜の録画で線なしを標準にするかどうかを決めてもらえれば、依頼の文を用意します。

補足：LOG418 の数字（線あり・線なし）

Claude が出発点に使った数字は、LOG418 の測定の記録（Unity の録画から配膳ロボットのまわり3m四方を切り出し、PatchCore で長い止まりを拾えるかを見たもの）からそのまま引いている。確かめに使ったのは、③の店でロボットありの3回分だ。

この表の長い止まり・短い止まりという正解は、人が画像を見て付けたものではない。Unity のログにある、ロボットが止まった時刻と長さから自動で付けている。つまり、正解はもう手元にある。Unity の中で止まりを見つけたいだけなら、画像を見る必要はなかった。画像から見つける力が要るのは、正解のログがない実物の店の映像に向かうときで、そのとき Unity のログは、ふつうなら人が何千枚も付ける正解の代わりになる。

ねらい：Unity の録画とログを、実店舗の映像で止まりを見つけるための教材として使う 変わったこと：Unity の中の寄り先は、ニューラルネットワークではなくログの規則で決めることにした。ニューラルネットワークは、ログのない実店舗の映像のために育てる 見込める効果：見込み。動画づくりは今の仕組みで回せる。教材は夜に回すほどたまる。実店舗の映像でどこまで通じるかは、まだ測っていない

記事を意味で探す仕組みは、言葉が出すぎて絞れない問題を解く

記事を意味で探す案を詳しく

— 記事を意味で探す仕組みは、このサイトの何を解くのか。

（ここで Claude は、同じ質問を言葉の一致で探す場合と意味の近さで探す場合を並べた図を出した）

今のサイトで何が困るか。

サイトには今、検索がありません。記録は126本、見出しで区切った節にすると2,300ほどあります。

言葉が見つからないことより、出すぎて絞れないことの方が問題です。たとえば立ち往生という言葉は31本、すれ違いは33本の記事に出てきます。しかも同じ出来事を、詰まる、止まり合う、向かい合って動けない、と回によって違う言葉で書いています。言葉の一致で探すと、言い換えた回は漏れ、出てきた31本も結局は自分で読むしかありません。

しくみ。

節ごとに、文の意味を数字の並びに変えておきます。埋め込みと呼ばれるやり方で、意味の似た文ほど近い数字になります。立ち往生と向かい合って動けないは、言葉は違っても近い所に置かれます。質問も同じように数字に変えて、近い節から順に返します。

サイトはもう Cloudflare の上で動いているので、新しいサービスを足さずに作れます。日本語に対応した埋め込みのモデル（Workers AI）と、数字の並びをためて近いものを探す倉庫（Vectorize）を使います。main に push したら、変わった記事の節だけ数字を作り直す形です。記事の量からすると費用は小さいはずですが、入れてみて円で測ってから決めます。

誰のために作るか。

前回は効き小に置きましたが、誰向けに作るかで評価が変わります。

人向けの検索窓としては、効きは小さいままです。サイトは AI に読ませる前提で作っていて、人が自分で探す場面が少ないからです。

効きが大きいのは、AI 向けの入口として作る場合です。サイトの住所で質問を受けて近い節を返す窓口を用意し、llms.txt に書いておきます。利用者の AI が126本を順に読む代わりに、この窓口に聞いて答えの節に直接たどり着けます。主に見る数字の一つ、AI の利用者の依頼で読みに来た数に一番つながる使い方です。

エイイチさん自身と Claude にも役立ちます。前にどう決めたかを探すとき、今は記憶とメモを頼りにしています。似た節が近くに集まるので、同じ話が何本の記事に散らばっているかも見えます。LOG から使える情報を選んで残す整理の材料にもなります。

弱いところと確かめ方。

LOG番号、PatchCore、cs:52 のような決まった名前は、言葉の一致の方が確実です。意味で探すと、似た別の名前を拾ってしまうことがあります。なので両方の結果を混ぜて返す形にします。

確かめは、エイイチさんが答えを知っている質問を20個用意して行います。正しい LOG の節が上位5つに入るかを、言葉の一致だけの場合と比べます。外れても違う節が並ぶだけで、誰も困りません。URL を消したりデータを消したりする変更ではないので、外部レビューは要らず、ビルドと実際の画面で確かめれば足ります。

この作業はサイトづくりなので、研究の外側の作業です。記事はロボティクスデザイン実務フローに置き、研究の記録の割合が半分を切らないよう、録画の案など研究側の作業と交互に進める形がよさそうです。

AI 向けの入口から作るか、人向けの検索窓も一緒に作るか、どちらで進めますか。

補足：言葉の一致で探すと、何本出るか

Claude が挙げた本数は、サイトの記事の Markdown（2026-11-07 時点で126本）を、言葉ごとに数えたものだ。

同じ出来事を指す言葉でも、1本にしか出てこない言い方もあれば、30本を超える言い方もある。言葉の一致では、どの言葉で探したかで結果が大きく変わる。意味で探す仕組みが解こうとしているのは、この揺れだ。

なお、この節の最後で Claude が、外部レビューは要らない、と言った所は、次の節で自分から取り消している。新しい住所が増える変更は、公開後に戻しにくい変更にあたるからだ。

AI 向けの入口は、住所に質問を入れる窓口より、固定のページを先に作る

AI 向けの入口から作る

もう少し詳しく。あと図解で説明をください。

あと導入するメリット、デメリットについても教えてください。

— AI 向けの入口は、どんな形で作り、何が得られて、何を失うのか。

（ここで Claude は、AI が答えの節にたどり着くまでを、今と作った後で並べた図と、記事を節に切って数字に変え、3つの出口を作る仕組みの図を出した）

窓口より先に固定のページを作る理由。

AI 向けの入口というと、住所に質問を入れると答えが返る窓口を思い浮かべますが、これには落とし穴があります。AI によっては、自分で組み立てた住所を開けない決まりがあります。Claude にもあって、会話の中に出てきた住所か、検索で見つけた住所しか開けないことがあります。窓口だけ作っても、使えない AI が出てきます。

そこで最初は、リンクをたどるだけで着ける固定のページを作ります。どの AI でも、ページの中のリンクなら開けます。窓口はそのあと、開ける AI のための近道として足します。

段階1の中身。

一つ目は、全文ページ（/record/〇〇.md）の各節の末尾に、意味の近い節を3件、LOG の題名と節の見出しとリンクで並べるものです。立ち往生の扱いを書いた節の下に、別の回で同じ問題を別の言葉で書いた節が並びます。AI は1本読み終えたあと、関係する回へそのまま進めます。

二つ目は、問いの索引ページです。立ち往生はどう扱っているか、ロボットを増やすと何が起きるか、のような問いを1つずつページにして、近い節を5つ、抜粋つきで並べます。llms.txt の一覧の先頭に置き、AI が最初に目にする所に問いが並ぶ形にします。

この問いの20個は、確かめ用の問いと同じものにできます。エイイチさんが答えを知っている問いなら、正しい節が5つの中に入っているかをそのまま点検できます。点検の材料と AI 向けの入口を一度に作れるので、問いは Claude が下書きして、エイイチさんが選ぶ形がよさそうです。

読まれた数は、今の計測がすべての住所で AI の名乗りを記録しているので、新しいページもそのまま数えられます。問いのページから入った読みと、今までの記事から入った読みを分けて比べられます。

導入するメリットとデメリット。

一番気をつけたいのは、古い決定と新しい決定が並ぶことです。たとえば立ち往生の扱いは、回を追って決まりが変わっています。近い節を並べるとき、日付と LOG 番号を必ず出し、新しい順に並べて、AI が最新の決まりを取り違えないようにします。公開済みの LOG は直さない決まりなので、どれが最新かは並べ方で伝えるしかありません。

決めてもらいたいこと。

問いの20個は、Claude の下書きから選ぶ形でよいか。それと、新しいページの住所を /questions/〇〇 のような形にするかです。この2つが決まれば、問いの下書きと、近い節を作る道具の試作から始めます。

補足：AI 向けの入口として考えた3つの出口

この節で Claude が組んだ仕組みを、出口ごとに表にしておく。段階1と段階2を分けたのは、AI が開ける住所の種類が違うからだ。

この時点では、AI が llms.txt を入口にしてサイトを読むと考えていた。次の節で計測を見て、その前提が崩れる。

サイトの計測を見たら、AI は記事を1本ずつ読んでいて、案内のページは通っていなかった

これはAIが読むことを増やしたいというサイトの意図がメリットとして大きいですか？

— AI 向けの入口のメリットは、AI に読まれる数を増やしたいというサイトのねらいから来ているのか。

（ここで Claude は、サイトの計測から、AI が今サイトを読んでいる道すじと、手を入れられる場所を描いた図を出した）

はい。メリットのほとんどは、AI に読まれる数を増やしたいというサイトのねらいから来ています。人に検索で来てもらうサイトなら、この入口の価値は小さいままです。

ただ、実際の計測を見たら、前回の説明はねらいとのつながりを大きく見積もりすぎていました。

計測で分かったこと。

10/26〜11/7 の AI の利用者の依頼で読みに来た数は、週に50回ほどです。ほとんどが ChatGPT で、記事ページを1つずつ、たいてい1回だけ読んでいます。利用者の質問を受けた AI が自分で検索し、出てきた記事を1本開いて答える、という読まれ方です。

一方、llms.txt が読まれたのは13日で2回だけで、それも11/3 に集中しています。エイイチさんや Claude の試しが混ざっている可能性もあります。つまり、llms.txt から問いの索引へ案内する形は、今の AI の読み方ではほとんど通られない道です。

もう一つ見落としていた点があります。AI が答えの節に早く着けるようになると、1つの質問で開くページが減ります。読まれた数を伸ばすことと、読みやすくすることは、同じ向きとは限りません。

ねらいに本当に効くのはどこか。

読まれる数を決めているのは、サイトに着いたあとより、AI が検索したときに選ばれるかどうかです。そこに効きうるのは、問いのページを llms.txt の案内としてではなく、検索で選ばれる新しいページとして作ることです。ロボットどうしが動けなくなったらどうするか、という問いを題名にしたページは、利用者が AI にした質問と同じ形をしているので、AI の検索に選ばれやすくなる可能性があります。ただし可能性の段階で、本当に選ばれるかは公開して数週間見ないと分かりません。

近い節のリンクは、全文ページではなく、AI が実際に着いている記事ページの方に置くべきでした。着いた先から次の回へ進む AI がいれば、読まれる数が少し増えます。進む AI が少なくても、関係する決定を一緒に読んでもらえるので、答えの正しさは上がります。

見直した結論。

メリットの中心は二つです。一つは問いのページが検索で選ばれて、読まれる入口そのものが増えること。もう一つは、読まれたときに正しい最新の決定まで届くことです。前者は読まれる数に効きますが、効くかどうかはまだ分かりません。後者は読まれる数にはあまり効きませんが、引用されたときの中身の確かさに効きます。

なお今の数はまだ小さく、ページごとに比べると30回に届きません。試すなら、問いのページを10個ほど公開して、それらが読まれた数を週ごとに数えるところから始めるのがよさそうです。判断できるのは数週間後です。この形に組み直して進めますか。

補足：計測の数字（2026-10-26〜11-07）

Claude が見たのは、このサイトで主に見ている3つの数字のうち2つだ。AI の利用者の依頼で読みに来た数は、ChatGPT・Claude などが利用者の質問を受けてページを読んだ回数。AI のサービスのリンクから来た人の数は、AI の答えに付いたリンクを人が押して来た回数。

読まれたページの内訳を日ごとに見ると、ほとんどの記事が1日に1回だけ読まれていた。同じ日に同じ記事が3回以上読まれたのは、11/2 の1本（4回）だけだった。トップページ（/）が多い日もあるが、私が自分で ChatGPT や Claude にこのサイトのことを聞いた分が混ざりうる。数はまだ小さく、ページごとに比べられるほどではない。

ここで分かったのは、入口を作り込む前に、AI がどこから来ているかを見る必要があったということだ。Claude の最初の組み立ては、AI が案内のページから入ってくる前提に立っていた。実際の AI は、自分の検索で見つけた記事に直接来ていた。

記事を意味で探す仕組みは、読まれ方が分かるまで保留にした

もう少し待ちますか。ページの状況がよりわかるようになってから進めましょう。それまで保管しておいてください。

— 意味で探す仕組みを、いつ作るか。

案を保管しました。保留にしてあるので、今は作りません。

Project の作業メモに、ここまで話した内容をまとめてあります。しくみ、見直した作るもの（問いのページと記事ページの近い節。窓口は後回し）、11/7 時点の計測で分かったこと、メリットとデメリット、再開するときに見る数字、最初の一歩です。待つと決めたことも書き残したので、別の会話からでも続きを始められます。

再開の目安はまだ決めていません。AI が読んだページの内訳と、記事から記事へ続けて読まれているかを週の分析で見ていけば、判断できるだけの数がそろったところで分かるはずです。

補足：保留にした理由と、再開のときに見るもの

待つことにしたのは、作る物の良し悪しより、AI がどう読んでいるかのほうが、まだ分かっていないからだ。問いのページが AI の検索に選ばれるかは、公開してみないと分からない。けれど、今の数は週に50回ほどで、ページごとに比べると30回に届かない。何かを足しても、効いたのかたまたまなのかを見分けられない。

再開のときに見るものは、AI が読んだページの内訳（どの記事が何回読まれたか）、記事から記事へ続けて読まれているか、llms.txt が読まれる回数が増えているか、の3つだ。どれも今の計測でそのまま見られる。

ねらい・変わったこと・見込める効果

この対話で決めたことを、ここでまとめておく。どれも見込みで、効果はこれからの記事で確かめる。

ニューラルネットワークの出番は、ログのない所にある

この対話は、ニューラルネットワークで何ができるか、から始まって、どこには要らないか、に行き着いた。Unity のシミュレーションは、ロボットが止まった時刻も場所も原因も知っている。そこで画像から止まりを見つけ直すのは、答えを知っているのに答えを当てる練習をするようなものだった。

答えを知らないのは、実物の店だ。店のカメラの映像には、ロボットがなぜ止まったかのログがない。そこで初めて、映像から見分ける力が要る。そしてその力を育てる正解は、Unity が夜ごとに作ってくれる。

サイトの検索も、同じ順番で考えた。AI に読まれる数を増やしたいなら、先に、AI がどこから来ているかを見る。計測を見たら、AI は案内のページではなく、自分の検索で見つけた記事に直接来ていた。だから、作る前に待つことにした。

ニューラルネットワークは、規則で書ける所には入れない。ログのない所に入れ、ログのある所はその教材にする。

出典

• サービスロボット導入シミュレーション Log#28 | 道の線を消すと、配膳ロボットの詰まりは3割しか拾えない（LOG418）
• Roth et al., Towards Total Recall in Industrial Anomaly Detection（PatchCore の論文、arXiv:2106.08265）
• Physical Intelligence：π0.5
• Cloudflare Workers AI
• Cloudflare Vectorize
• llms.txt