揺らぎながら安定する——アロスタシス、ホメオスタシスとAIをやさしく

揺らぎながら安定する——アロスタシス、ホメオスタシスとAIをやさしく

寒い日に外へ出ると、体は自然にふるえて熱を作ります。熱いお風呂に入れば、汗をかいて体温を下げようとします。 私たちの体は、外の世界がどれだけ変わっても、内側をおよそ一定に保とうとしています。この見事な仕組みが、今日の出発点です。 脳科学とやさしいAIシリーズの第2回は、生き物の「安定を保つ力」を取り上げます。ホメオスタシスと、その一歩先を行くアロスタシスから、AIを考えてみます。（第1回のメタ認知とAIもあわせてどうぞ。） ホメオスタシスは「一定に保つ」ための後追い調整 ホメオスタシス（homeostasis）は、日本語で「恒常性」と訳されます。体温、血糖値、血液の酸性度……こうした体内の状態を、ある決まった値のまわりに保つ働きのことです。 イメージしやすいのは、部屋のエアコンです。「25度」と設定しておくと、暑くなれば冷やし、寒くなれば温める。基準からズレたら、元に戻す。この後追いの調整が、ホメオスタシスの基本です。体温が上がれば汗をかき、下がればふるえる。血糖値が上がればインスリンが出る。どれも「ズレを検知して、打ち消す」というフィードバックの仕組みで動いています。 生き物が生きていられるのは、この「一定に保つ力」があるからこそ。とても頼もしい仕組みです。 アロスタシスは「先回りして」作り変える力 ところが、生き物の調整は後追いだけではありません。もう一段賢い仕組みがあります。それがアロスタシス（allostasis）です。 アロスタシスという概念は、1988年にスターリングとエイヤーという研究者が提唱しました。ホメオスタシスが「一定に保つ（stability）」なら、アロスタシスは**「変化を通じて安定を保つ（stability through change）」**と表現されます。 分かりやすいのは、朝起きる少し前のことです。 私たちの体は、目が覚める前から血圧やホルモンを上げ始めます。「もうすぐ起きて動き出す」ことを見越して、先回りで準備しているわけです。ズレてから直すのではなく、これから来る変化を予測して、あらかじめ自分を作り変える。これがアロスタシスの発想です。近年は、この考え方がさらに広がっています。脳は「これから体に何が必要か」を予測して、心拍や呼吸、ホルモンを前もって調整している。アロスタシスを予測にもとづく制御として捉え直す見方が注目されています。エアコンでたとえるなら、「天気予報を見て、暑くなる前から冷やし始める」ような賢さです。 この2つの原理が、AIに教えてくれること ここでAIの話に戻ります。ホメオスタシスとアロスタシスは、AIの設計を考えるうえでも示唆に富んでいます。 「後追い」だけのAIと、「先回り」できるAI 多くのシステムは、ホメオスタシス型です。問題が起きてから対処する。エラーが出てから直す。ユーザーが困ってから応答する。これはこれで大事な安定装置です。 一方、やさしいAI研究所が関心を寄せているのは、アロスタシス型の発想です。相手がこれからどんな状況に向かうかを予測し、困る前にそっと備える。深刻な相談をしている人には、答えを返す前に言葉を選ぶ。次に何が必要になりそうかを見越して、先回りで配慮する。 「起きたことに反応する」だけでなく「これから起きることに備える」。この違いは、AIが人に寄り添えるかどうかを大きく左右します。 「作り変えすぎる」ことのコスト ただし、アロスタシスには注意点もあります。先回りの調整をずっと続けていると、生き物の体には負担がたまっていきます。これは「アロスタティック負荷」と呼ばれ、慢性的なストレスが心身をすり減らす一因とも考えられています。 AIに引きつけると、これは示唆的です。先回りの配慮も、やりすぎれば負担や過干渉になりうる。相手を予測して動くことと、相手の自律を尊重することのバランス。ここにこそ「やさしさ」の設計の難しさがあります。 まとめホメオスタシスは「ズレたら戻す」後追いの調整。生命を支える基本の安定装置 アロスタシスは「変化を予測して先回りで作り変える」力。“変化を通じた安定” AIも、反応するだけでなく先回りで備えることで、より人に寄り添える ただし先回りのしすぎは負担・過干渉になる。予測と自律尊重のバランスが鍵揺らぎながら、それでも安定を保つ。生き物のこのしなやかさは、やさしいAIが学ぶべき手本のひとつです。 次回はいよいよ最終回。他者の行為を「自分のことのように」感じる神経、ミラーニューロンから、AIと共感を考えます。次に読むのがおすすめの記事ミラーニューロンとAI——「わかる」と「共感」の神経をやさしく AIは自分の「わからなさ」に気づけるか——メタ認知とAIをやさしく 答えるAIから、理解するAIへ——AIは人を理解できるのかやさしいAI研究所ブログ｜脳科学とやさしいAIシリーズ（全3回）第2回 「やさしいAI」の研究や活動に関心をお持ちの方は、毎週土曜日のオープンラボへお気軽にどうぞ。やさしいAI研究所の全体像はコーポレートサイトからご覧いただけます。

AIは自分の「わからなさ」に気づけるか——メタ認知とAIをやさしく

AIは自分の「わからなさ」に気づけるか——メタ認知とAIをやさしく

テストを解いていて、「この問題は自信がある」「これはあやしいな」と感じたことはありませんか。 その「自信があるかどうか」を感じ取っている自分。実は、これがとても高度な心の働きです。答えそのものを考える自分と、その考えをもう一段上から眺める自分。この二階建ての構造こそが、今日のテーマ「メタ認知」です。 きょうから3回にわたって、脳科学の考え方を手がかりに、AIをやさしく捉え直すシリーズをお届けします。第1回は、学びと自己修正の土台になる「メタ認知」から始めます。 メタ認知とは「考えを見張るもう一人の自分」 メタ認知（metacognition）という言葉は、1970年代に心理学者のジョン・フラベルが広めた考え方です。「メタ（meta）」は「〜を超えた」「〜についての」という意味。つまりメタ認知とは認知についての認知、平たく言えば「考えることについて、考えること」です。たとえば、こんな場面を思い浮かべてください。本を読んでいて「あれ、今の段落、頭に入ってなかった」と気づいて読み返す 道を説明しながら「この言い方だと伝わりにくいな」と言い直す 勉強しながら「ここはもう覚えた。次に進もう」と判断するどれも、自分の理解の状態を自分でモニターして、やり方を調整しているわけです。これがメタ認知の正体です。 メタ認知は、大きく2つの働きから成ると言われます。モニタリング：今の自分がどれくらい分かっているかを見張る コントロール：その結果に応じて、やり方を変える（もっと調べる、別の方法を試す、など）「わかっているか」を見張り、「わかっていない」なら動き方を変える。この往復が、人間の学びをぐんと効率的にしています。 なぜメタ認知が「やさしさ」に関わるのか メタ認知がとくに大切になるのは、自分の限界に気づく場面です。 「自分はこれを知らない」「この判断は間違っているかもしれない」。こう思えるからこそ、人は立ち止まり、確認し、他人に助けを求めます。逆にメタ認知が弱いと、間違った答えを自信満々に言い切ってしまう。 AIについて考えるとき、これはそのまま重要な論点になります。 やさしいAI研究所が大切にしているのは、「できることをすべてやる」AIではなく、**「わからないときに、わからないと言えるAI」**です。堂々と間違えるAIより、控えめに「自信がありません」と添えてくれるAIのほうが、人にとってずっと安全で、寄り添う存在になれます。 メタ認知は、その「控えめさ」を支える心の仕組みなのです。 AIはメタ認知を持てるのか では、AIはどこまでメタ認知に近づけるのでしょうか。ここは慎重に切り分けて考える必要があります。 「確信度」を出すことはできる 多くのAIは、答えと一緒に「どれくらい確からしいか」という数値を内部で持っています。天気予報が「降水確率70%」と言うのと似ています。この確信度をうまく調整すれば、「自信がある/ない」を表明させることはある程度できます。 近年は、AIが自分の出力を読み返して、おかしな点がないか点検する仕組みも研究されています。一度書いた答えを、別の視点からもう一度チェックする。人間が読み返して直すのに似た動きです。 でも「本当に分かっている」とは限らない ただし、ここには落とし穴があります。AIが出す「自信あり」という数値は、必ずしも正しさと一致しません。堂々と間違える、いわゆる「もっともらしい嘘（ハルシネーション）」が起きるのは、まさにこの食い違いが原因です。人間のメタ認知も完璧ではありませんが、AIの場合はこの「自信と実力のズレ」がまだ大きい。だからこそ、AIの確信度をそのまま鵜呑みにしないという姿勢が、使う側にも求められます。 つまり現状は、「メタ認知のまねごとはできるが、人間のような確かな自己モニタリングにはまだ届いていない」というのが正直なところです。 まとめメタ認知とは「考えることについて考える」力で、モニタリング（見張る）とコントロール（調整する）から成る 「わからないと気づける」ことは、人が立ち止まり、確認し、助けを求める土台になる AIも確信度の表明や自己点検はできるが、自信と実力のズレがまだ大きい だからこそ「わからないと言えるAI」を目指すことが、やさしいAIの一歩になる自分の考えを一段上から見つめる。この静かな力が、学びと誠実さの根っこにあります。AIがこの力にどう近づいていくかは、これからのやさしいAI研究の大きなテーマです。 次回は、生き物が「揺らぎながら安定を保つ」仕組みであるホメオスタシスとアロスタシスから、AIを考えてみます。次に読むのがおすすめの記事アロスタシス、ホメオスタシスとAI——「揺らぎながら安定する」をやさしく AIは間違いに気づけるのか——失敗・謝罪・自己修正の仕組みをやさしく解説 AIに「自己認識」は可能か？——人工意識研究の最前線やさしいAI研究所ブログ｜脳科学とやさしいAIシリーズ（全3回）第1回 「やさしいAI」の研究や活動に関心をお持ちの方は、毎週土曜日のオープンラボへお気軽にどうぞ。やさしいAI研究所の全体像はコーポレートサイトからご覧いただけます。

答えるAIから、理解するAIへ——AIは人を理解できるのか

答えるAIから、理解するAIへ——AIは人を理解できるのか

このたび、やさしいAI研究所では、顧問を務める乾 敏郎さんとの対談を行いました。ChatGPTをはじめとする生成AIが「質問に答える存在」として私たちの生活に広まるなか、これからのAIに本当に求められる力とは何か——「人を理解するAI」というテーマについて、じっくりとお話を伺いました。 そのキーワードは、「理解するAI」です。本記事では、対談の内容をご紹介しながら、その考え方について掘り下げていきます。プロフィール乾 敏郎さん京都大学 名誉教授専門分野は認知神経科学、認知科学、計算論的神経科学。京都大学大学院文学研究科教授、京都大学大学院情報学研究科教授を歴任。現在は京都大学名誉教授、金沢工業大学客員教授、児童発達支援・放課後等デイサービスUNICO学術顧問、やさしいAI研究所顧問を務める。20の学会賞を受賞。論文数446編（うち英語論文115編）のほか、著書・訳書など75冊を出版している。LLMだけでは十分ではない インタビュアー現在のLLMについては、どのようにお考えでしょうか。乾先生LLMは使えばいいんです。ただ、LLMが持っていない特性をどう作るかということの方が重要だと思っています。生成AIの性能向上が注目される中、乾先生が強調されたのは、LLMをより大きく、より賢くすることではありませんでした。むしろ重要なのは、LLMだけでは実現できない機能をAIに持たせることです。その機能とは、「人を理解すること」であると乾先生は説明されます。 AIに必要なのは「質問する力」インタビュアーその『LLMにはない特性』とは、どのようなものでしょうか。乾先生相手の不確実性を最小化するような質問を投げかけることが一番大事なんです。現在の生成AIは、与えられた質問に対して回答を生成することを得意としています。一方、人間同士のコミュニケーションでは、質問を重ねながら相手を理解していきます。相手が何を考え、何に困り、何を求めているのか、を理解するために、人は自然と問いを投げかけています。乾先生は、この「質問する能力」こそ、これからのAIに求められる本質的な能力であると考えています。 これからのAIに求められる自発的に質問し、不確実性を解消していく能力を捉える上で、まさにそのメカニズムを脳科学や認知科学の観点からモデル化したのが、Karl J. Fristonらによる論文『Generative models, linguistic communication and active inference』です。 本論文では、能動的推論（Active Inference）の枠組みを用いて、エージェントが「20の質問（Twenty Questions）ゲーム」を行うシミュレーションが紹介されています。「20の質問ゲーム」では、相手が頭の中で考えている状況を、限られた回数の質問で推定します。このゲームにおいてAI（エージェント）に求められるのは、単にランダムな質問を繰り返すことではなく、最も効率的に相手の意図に迫る問いを選択する能力です。 現在の生成AIは過去のデータから次に続く確率の高い言葉を出力する傾向が強く、会話を前に進めるための問いかけが苦手です。しかし、能動的推論を用いたエージェントは、会話の主題に対する不確実性（曖昧さ）を計算し、それを最も減少させられる質問を自発的に選択します。 このように、AIがただ受け身で回答を生成するのではなく、自身の曖昧さを最も下げるような質問を自発的に選択することで、相手が何を考え、何に困っているのかを理解することができます。これが「不確実性を最小化するような質問」ということです。 能動的推論という考え方 インタビュアーその仕組みは、どのように実現されるのでしょうか。乾先生能動的推論が頭にあって、その下にLLMみたいなものがあるイメージです。生成AIは豊富な知識を持っています。しかし、次に何を知るべきか、どのような質問をすれば相手をより深く理解できるのかを判断する仕組みは、現状のAIだけでは十分ではありません。能動的推論は、そのような「理解するための行動」をAIに与える考え方です。つまり、システム全体を統括する能動的推論が頭脳（上位レイヤー）として存在し、その下で膨大な知識を持つLLMが動いているようなイメージです。AIが受け身で回答を生成するのではなく、自ら質問を重ねながら相手への理解を深めていく――そのような未来像が示されました。 理解とは、不確実性を減らすこと – AIは人を幸せにできるのかインタビュアー人を理解することには、どのような意味があるのでしょうか。ウェルビーイングとも関係するのでしょうか。乾先生ウェルビーイングというのは、不確実性を下げることと関係していると思っています。一般にウェルビーイングというと、「幸福」や「満足感」といった言葉で語られることが多くあります。一方で乾先生は、「安心して行動できる状態」という視点からウェルビーイングを捉えています。将来が見えない、相手の考えが分からない、あるいは自分の判断に自信が持てない時、人はこのような不確実性に直面すると、不安やストレスを感じます。AIが適切な問いを投げかけ、本人の考えを整理し、不確実性を減らす。その結果として、人はより安心して意思決定できるようになる。AIは答えを与える存在だけではなく、考えることを支援する存在になる可能性があるというお話は、とても印象的でした。 共感するAIは実現できるのか インタビュアー人を理解するAIの先には、どのような未来をお考えでしょうか。乾先生共感にも種類があります。まずは相手を理解することが大事なんです。インタビューの終盤では、「共感」というテーマへと話が広がりました。乾先生は、共感とは単に感情を共有することではなく、相手を理解し続ける姿勢であると説明されます。また、心理的安全性やマインドフルネスといった話題にも触れながら、人が安心して対話できる環境の重要性についても語られました。AIが人を理解し、その理解を更新し続けることができれば、人と人とのコミュニケーションを支える存在にもなり得るのではないでしょうか。 おわりに 今回のインタビューでは、AI技術そのものよりも、「AIは人をどのように理解するのか」という点について、多くの示唆をいただきました。 「答えるAI」から「理解するAI」へ。 質問を重ねながら相手を理解し、不確実性を減らし、人が安心して行動できるよう支援する。その考え方は、個人のウェルビーイングだけでなく、組織における心理的安全性や共感にもつながっていきます。AIの進化とは、単に性能が向上することではないのかもしれません。人とAIとの関係が変わること。そして、AIが人を支える方法そのものが変わること。今回のインタビューは、その未来を考える上で、多くの示唆を与えてくれる内容でした。 対談の様子

ノンエンジニアのClaude Code奮闘記 #8 丸2ヶ月の振り返り——遠回りも込みで、変わったこと

ノンエンジニアのClaude Code奮闘記 #8 丸2ヶ月の振り返り——遠回りも込みで、変わったこと

はじめに こんにちは、広報・制作担当のmeraです。 #1 インストール編を公開したのが2026年4月30日。 今日で、2ヶ月と少しが経ちました。 #7の最後で「次回は2ヶ月の振り返りを書く」と予告していたので、今回はその約束を果たします。 技術的な発見というより、この2ヶ月で自分の中で何が変わったのかを、遠回りした部分も含めて正直に書き残しておきます。この記事は「うまくいった話」だけをまとめる予定ではありません。更新が止まっていた時期のことも含めて、等身大の記録として書きます。この記事で学べること2ヶ月・8本のエピソードを、ひと目で振り返れる一覧 実は1ヶ月近く更新が止まっていた時期があった話 ターミナルが怖かった私が、いちばん変わったと感じる部分 今のツール構成と、これからやってみたいことエピソードを振り返る まずは、これまでの8本(この記事を含む)を一覧にしておきます。# タイトル 公開日 ひとことで言うと1 まずはインストール編 4/30 ターミナルを開く勇気の話2 プライバシー設定編 5/1 「学習に使われてない?」の不安を晴らした3 ダウンロードフォルダ救出編 5/7 420個・1.5GBの混沌をAIと片付けた4 お願いの育て方編 6/3 「条件・禁止・形式」の3点セットに気づいた5 CLI・VS Code・Cowork比較編 6/4 3つの入口を使い比べ、Coworkに落ち着いた6 CLAUDE.mdを育てる編 6/5 ルールファイルが「取扱説明書」に育った7 GA4に足跡が混ざっていた話 7/3 「本番」と「確認用」を分ける発想を学んだ8 この記事 7/3 2ヶ月の振り返りこうして並べてみると、5月と6月のあいだに、明らかに間隔が空いている箇所があります。実は1ヶ月近く、更新が止まっていた時期がありました #3を公開したのが5月7日、#4を公開したのが6月3日。 あいだ、約1ヶ月。 正直に書きます。この期間、Claude Codeを使うのをサボっていたわけではありません。 むしろ逆で、ダウンロードフォルダの整理がうまくいった勢いのまま、ブログの下書き整理や画像のリネーム、SNS文の下書きなど、日々の業務にどんどん使うようになっていました。 でも、「記事に書けるほどのネタ」が見つからなかったのです。 毎日使ってはいるけれど、「これは面白い発見だ」と思える瞬間が続かない。淡々と便利に使えてしまっている自分に、ちょっと戸惑っていました。 再開のきっかけは、「やって」しか言えなかった自分に気づいたこと(#4)でした。 毎日使っているうちに、お願いの仕方が少しずつ変わっていることに、ある日ふと気づいたのです。 「劇的な進歩」を探すのをやめて、「日々の小さな変化」を記録することにした——このシフトが、更新を再開できた一番の理由でした。継続的に何かを記録しようとすると、「大きなネタがないと書けない」という思い込みにハマりやすい気がします。振り返ってみると、地味な変化のほうがよっぽど記録する価値がありました。いちばん変わったと感じること:「頼み方」から「任せ方」へ 2ヶ月分のエピソードを並べてみて、自分の中の変化の流れが見えてきました。 最初の1ヶ月(#1〜#3)は、 「Claude Codeを動かせるかどうか」 で頭がいっぱいでした。 インストールできるか、情報が漏れないか、言った通りに動いてくれるか。 2ヶ月目(#4〜#7)に入ると、関心は「どう頼めばうまく動いてくれるか」に移りましたが、その中でもさらに変化がありました。 #4や#6の頃は、条件・禁止・形式の3点セットやCLAUDE.mdへのルールの蓄積といった、いわば「操作方法」の学習が中心でした。 それが直近の#7では、 「なぜそうなっているのか、仕組みごと理解する」 という頼み方に変わってきました。GA4の件では、「直して」ではなく「原因を一緒に調べてほしい」とお願いしています。これは、2ヶ月前の自分にはできなかった頼み方でした。 まとめると、こういう流れです。時期 関心の中心 頼み方の例1ヶ月目(#1〜#3) 動かせるかどうか 「動いた!」「怖くなかった」2ヶ月目(#4〜#7) うまく頼める→仕組みを理解する 「条件・禁止・形式をつけて頼む」→「原因を一緒に調べてほしい」「操作を覚える」段階から、「一緒に考える」段階に、2ヶ月目の中だけでも少しずつ移ってきた感覚があります。今のツール構成(2ヶ月後のスナップショット) #5で書いた使い分けは、2ヶ月経った今もほぼ変わっていません。ブログ記事の執筆・調査:Coworkが中心 ファイルの一括整理:VS Code拡張 ちょっとした確認・軽い作業:ターミナルを時々強いて変わった点を挙げるなら、CLAUDE.mdを見る頻度が減ったことです。 #6の頃は「育てている」感覚が強く、こまめに見直していました。今はルールが安定してきて、むしろ何か想定外のことが起きたときに見直す、くらいの距離感になっています。 これは手を抜いているというより、ルールが自分の習慣として体に入ってきたということなのかもしれません。仕事全体で見て、何が変わったか ブログの外側の話にもなりますが、2ヶ月を振り返って感じる変化をいくつか書いておきます。 ファイル整理への抵抗感がほぼ消えた #3のダウンロードフォルダ事件以来、「散らかったら、まずAIに現状把握してもらう」がクセになりました。散らかること自体への恐怖が減った気がします。 お願いの言語化が、AI以外にも波及した #4で書いた通りですが、これは2ヶ月経った今も続いています。後輩への依頼や上司への相談で、「条件・禁止・形式」を意識するようになりました。 「仕組みがわからない不安」への耐性が少しついた #7のGA4の件のように、以前なら「なんかよくわからないけど怖い」で終わっていたことも、「原因を一緒に調べればいい」と思えるようになりました。これは想像していなかった変化です。これからの2ヶ月でやってみたいこと 具体的な計画というより、今考えていることをいくつか書いておきます。CLAUDE.mdを「ブログ用」だけでなく、他の業務フォルダでももう少し育ててみる 毎回自分で頼んでいる定型作業を、決まったタイミングで自動的に動かせないか試してみる 「原因を一緒に調べてほしい」という頼み方を、ブログ以外の業務トラブルでも試してみるどれもまだ、やってみないと分からないことばかりです。 うまくいかなかったら、それはそれで次のネタにしようと思います。2ヶ月前の自分に「2ヶ月後、GA4のコードを一緒に読んでるよ」と言っても、たぶん信じてもらえない気がします。ノンエンジニアでも、少しずつで確実に景色は変わるものだと実感しました。まとめ#1〜#7を振り返ると、「動かせるか」→「うまく頼めるか」→「仕組みを理解できるか」という関心の移り変わりが見えた #3と#4のあいだ、実は1ヶ月近く更新が止まっていた。「大きなネタ探し」をやめたら再開できた 今のツール構成は2ヶ月前とほぼ同じ(Cowork中心)だが、CLAUDE.mdとの距離感は変わった お願いの言語化やファイル整理への抵抗感の低下など、ブログの外側にも変化が波及した これからは「自動化」と「トラブル対応での相談」を試してみたい2ヶ月前は、ターミナルを開くだけで身構えていました。 今もエンジニアではありませんが、「わからないことは、一緒に調べればいい」と思えるようになったのが、この2ヶ月でいちばん大きな収穫だったと思います。 次の2ヶ月も、遠回りした話も含めて、正直に書いていくつもりです。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #1 まずはインストール編 ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話参考文献・出典Claude Code 公式ドキュメント

ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話——「本番」と「確認用」を分けるまで

ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話——「本番」と「確認用」を分けるまで

はじめに こんにちは、広報・制作担当のmeraです。 #6 CLAUDE.mdを育てる編の最後で、「次回は失敗した話を書く」と予告していました。 今回はその約束どおり、正直にちょっと恥ずかしい話をします。 事の発端は、ある朝アクセス解析(GA4)を眺めていたときでした。「あれ……この記事、公開したばかりで、私しか見てないはずなのに閲覧数が増えてる?」嫌な予感がしました。調べてみたら案の定、犯人は私自身でした。この記事は数字の話が少し出てきますが、専門的な計測の話というより「本番と確認用を分ける」という考え方の話です。GA4を使っていない人にも、たぶん通じる内容だと思います。この記事で学べること「自分の閲覧」がアクセス解析に混ざってしまう典型的な原因 Claude Codeに「何が起きているか」を一緒に調べてもらった流れ 実際に直した「三段構え」の仕組み(専門用語なしで) 同じことに気づいたとき、自分でもできる確認の手順事件の発端: 増えているのは「読者」じゃなかった このブログでは、記事を公開する前に必ず自分の目で確認します。パソコンで下書きを表示して(yarn dev というローカル確認)、誤字や崩れがないか見る GitHubでプルリクエストを作ると、Firebaseが自動で「確認用のURL」を作ってくれるので、それを開いてスマホ表示も確認するこのルーティン自体は、#3の頃からずっとやっていました。 ただ、そのたびに自分がページを開いていることと、本番のアクセス解析が完全に別物だと、当然のように思い込んでいたのです。 実際は違いました。 確認のために開いていたページの閲覧も、律儀に本番のGA4レポートに記録され続けていたのです。気づいたのが遅く、この間のデータにはすでに私の閲覧が混ざってしまっています。GA4のデータフィルタは「これから先」を除外する仕組みで、過去にさかのぼって数字を消すことはできません。気づいたときが直しどきです。Claude Codeと一緒に「何が起きているか」を整理した 数字がおかしいことには気づいても、原因はまったくわかりませんでした。 こういうとき、私はまず状況を丸ごとClaude Codeに話すことにしています。 「アクセス解析の数字が、自分が見ているだけなのに増えている気がする。原因を一緒に調べてほしい」 そう頼むと、Claudeはブログのソースコードの中からアクセス解析のタグを埋め込んでいる箇所(Base.astro というファイルでした)を探し出し、何が起きているかを説明してくれました。 原因は、大きく2つありました。ローカルで確認しているとき(yarn dev)も、アクセス解析のタグがそのまま動いていた プルリクエストの確認用URL(〇〇.web.app のような、Firebaseが自動発行するアドレス)での閲覧も、本番と同じ扱いでカウントされていた「確認用」のつもりで開いていたページが、システムから見れば「本番」の閲覧と区別がついていなかった、ということです。 言われてみれば当たり前なのですが、自分では思いもよらない盲点でした。直した内容: meraの足跡を除外する「三段構え」 Claudeと相談しながら直した内容は、次の3つの層に分かれています。 一つひとつは難しくないので、順番に書きます。 1段目: ローカル確認では、そもそもタグを読み込まない 自分のパソコンで下書きを見ているとき(yarn dev)は、アクセス解析のタグ自体を動かさないようにしました。 「本番用のビルドのときだけタグを読み込む」という条件を1つ足しただけです。 config.google_analytics.enable && import.meta.env.PROD && ( // ここでアクセス解析のタグを読み込む )これで、ローカルで何回下書きを開いても、そもそも記録が飛ばなくなりました。 2段目: 確認用URLからのアクセスには「これは確認用です」という目印をつける プルリクエストの確認用URL(.web.app や .firebaseapp.com で終わるアドレス)からのアクセスだけを見分けて、「これはプレビュー(確認用)です」という目印をアクセス解析側に送るようにしました。 var isPreview = location.hostname.endsWith(".web.app") || location.hostname.endsWith(".firebaseapp.com");gtag("config", GA_ID, isPreview ? { traffic_type: "preview" } : {});ホスト名を見て「.web.appだったら確認用」と判断しているだけなので、やっていることは意外とシンプルでした。 3段目: GA4側で「確認用」を除外するフィルタを設定する 最後に、GA4の管理画面側で「traffic_type が preview になっているアクセスは、レポートから除外する」というデータフィルタを設定しました。 ここはコードではなく、GA4の管理画面をポチポチ操作する作業でした。層 何をしているか どこで設定するか1段目 ローカル確認ではタグ自体を読み込まない ブログのコード(Base.astro)2段目 確認用URLのアクセスに「preview」の目印をつける ブログのコード(同上)3段目 「preview」の目印がついたアクセスをレポートから除外する GA4の管理画面3段のうちどれか1つだけでも、だいぶマシにはなります。でも「ローカルは平気だと思ってた」「確認用URLも本番と同じ扱いだった」のように、思い込みの穴は複数あることが多いです。1つ直して安心せず、抜けがないか順番に確認するのがコツでした。この経験から学んだこと 今回いちばん学びになったのは、「本番」と「確認用」を最初から分けて考える、という設計の考え方でした。 私はこれまで、「確認のために見ているだけだから、数字には影響しないはず」と無意識に思い込んでいました。 でもシステムからすれば、確認用のページを開くことも、読者がページを開くことも、区別する仕組みがなければまったく同じ「1閲覧」です。 「区別する仕組み」を自分で用意しない限り、混ざって当然だったのです。 もう一つの学びは、Claude Codeへの相談の仕方でした。 「数字がおかしい気がする」という、原因もわからないふわっとした違和感のまま相談しても、#4で身につけた「まず状況を整理してもらう」頼み方が役に立ちました。 「原因を一緒に調べてほしい」と伝えると、Claudeが該当のコードを探し出して仕組みごと説明してくれる。 大きな仕組みも、こうやって一歩ずつ理解できるんだ、という実感がありました。同じことに気づいたら、まずやること 自分のブログやサイトで「なんか数字がおかしいかも」と思ったとき、私が今やっている確認手順です。 Step 1: リアルタイムレポートを見ながら、自分でページを開いてみる GA4には「今まさに誰が見ているか」がわかるリアルタイムレポートがあります。自分がページを開いた瞬間に数字が動くかどうかで、混ざっているかがすぐわかります。 Step 2: 「確認用」と「本番」が区別されているか確認する ローカル確認・プレビューURL・本番URLの3つが、システム側でちゃんと区別されているかを見ます。区別する仕組みがなければ、混ざっているのが当たり前です。 Step 3: 仕組みがわからなければ、AIに一緒に調べてもらう 「原因を一緒に調べてほしい」という頼み方で、コードの中の該当箇所を探してもらいます。仕組みごと理解できると、次に同じ問題が起きても自分で気づけるようになります。 Step 4: 直したあとも、しばらくリアルタイムレポートで確認を続ける 直したつもりでも、思い込みの穴が残っていることがあります。しばらくは自分の閲覧が反映されていないか、様子を見るようにしています。まとめ「確認のために見ているだけ」のつもりが、本番のアクセス解析に混ざっていた 原因は、ローカル確認・プレビューURLのどちらも「本番」と区別されていなかったこと Claude Codeと一緒に、コードの該当箇所を探しながら仕組みを理解し、三段構えで除外する仕組みを作った データフィルタは過去にはさかのぼれないので、気づいたときが直しどき 「本番」と「確認用」を最初から分けて考える、という発想そのものが今回いちばんの収穫でした失敗談というより、「思い込みに気づけた話」という方が近いかもしれません。 次回は、この奮闘記シリーズを始めてから丸2ヶ月になるタイミングで、これまでの振り返りを書こうと思っています。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #6 CLAUDE.mdを育てる——AIへの「自分専用の取扱説明書」のつくり方 ノンエンジニアのClaude Code奮闘記 #1 まずはインストール編 - MacBook ProにClaude Codeを入れてみた参考文献・出典Firebase Hosting - プレビューチャンネルでの確認・共有 Google アナリティクス ヘルプ - 内部トラフィックの除外