Sotwe logo Sotwe logo
arisan2026's profile image

アリさん

Verified account

@arisan2026

AI駆動開発を実験中。AIは先生、自分は実験台。 noteとXに、試行錯誤や気づきを記録しています。
Joined May 2026
68 Following
51 Followers
642 Posts
 Pinned Tweet
arisan2026's profile image
アリさん Verified account @arisan2026
【教えてAI先生】なぜ「犬」と「猫」は近いベクトルになるの？ AIの説明を聞いていると、ときどき、こんな話が出てきます。 「意味の近い言葉は、AIの中でも近いベクトルになります」 たとえば、「犬」と「猫」は近い。 一方で、「犬」と「冷蔵庫」は遠い。 なんとなく、言いたいことは分かります。 でも、どうやっているのでしょう。 誰かがAIに、 「犬と猫は、どちらも動物なので近くに置いてください」 と、一つずつ教えているのでしょうか。 もちろん、そんなことはできません。 世の中にある言葉の組み合わせを、人間がすべて分類するのは無理です。 では、AIはどうやって、「犬」と「猫」が近いことを知ったのでしょうか。 ■そもそも、ベクトルとは何なのか AIは、人間のように文字をそのまま理解しているわけではありません。 入力された文章は、まず「トークン」と呼ばれる単位に分けられます。 トークンは単語そのものの場合もあれば、単語の一部分や、一文字に近い場合もあります。 そして、それぞれのトークンは、AIの中で数字の集まりに変換されます。 ものすごく単純化すると、こんな感じです。 犬 ＝［0.12、-0.73、0.41、0.08……］ 猫 ＝［0.10、-0.69、0.45、0.05……］ 車 ＝［-0.54、0.11、-0.22、0.87……］ この数字の並びが、ベクトルです。 実際には、数百個、数千個といった大量の数字が並びます。 人間が数字を見ても、何を表しているのかは、ほとんど分かりません。 ただし、数字の並び方が似ていれば、ベクトルの向きも似てきます。 そのため、「犬」と「猫」は近く、「犬」と「車」は少し遠い、といった関係を数字として扱えます。 ■最初から「犬」と「猫」が近いわけではない では、この数字を誰が決めているのでしょう。 実は、学習を始めたばかりの段階では、ベクトルの数字に意味はありません。 ほとんどランダムな状態から始まります。 最初から「犬は動物」「猫も動物」と理解しているわけではありません。 AIは大量の文章を使い、次に来る言葉を当てる練習をします。 たとえば、こんな問題です。 犬がご飯を＿＿ 正解が「食べる」なのに、AIが「走る」と予測したとします。 すると、予測が外れた分だけ、AIの中にある大量の数字を少しずつ修正します。 次は、もう少し正解に近づけるように調整するわけです。 この練習を、膨大な文章を使って、何度も何度も繰り返します。 ■「犬」と「猫」は似た場所に登場する 文章の中で、「犬」と「猫」は似た使われ方をします。 犬がご飯を食べる 猫がご飯を食べる 犬が庭を走る 猫が部屋を走る 犬を飼っている 猫を飼っている 「犬」と「猫」の周囲には、似た言葉が登場します。 ご飯を食べる。 走る。 飼う。 かわいい。 動物病院へ行く。 こうした使われ方が何度も登場すると、AIにとっては、「犬」と「猫」を似た数字で表したほうが、次の言葉を予測しやすくなります。 その結果として、「犬」と「猫」のベクトルが近づいていきます。 人間が「犬と猫は似ています」と教えたわけではありません。 文章の中で似た働きをするため、学習の結果として近くなったのです。 ■AIは辞書を覚えたわけではない ここが、個人的には面白いところです。 AIは最初に辞書を渡されて、 「犬とは、イヌ科の動物である」 「猫とは、ネコ科の動物である」 と、一つずつ意味を暗記したわけではありません。 大量の文章の中で、言葉がどのように使われているかを見ています。 つまり、AIが学んだのは、 「この言葉は、どんな言葉の近くに現れやすいのか」 「文章の中で、どのような役割をするのか」 「この言葉のあとには、何が続きやすいのか」 というパターンです。 その使用パターンを膨大に集めた結果として、人間が「意味」と呼んでいるものに近い構造が、数字の空間に浮かび上がってきます。 意味を先に教えたのではありません。 使われ方を学ばせたら、意味のようなものが現れたのです。 ■「近い」とは、どういう意味なのか ベクトルが近いかどうかは、単純な距離だけでなく、向きの似かたでも測れます。 矢印を想像すると分かりやすいかもしれません。 同じ方向を向いていれば、似たベクトル。 大きく違う方向を向いていれば、関係の薄いベクトル。 ただし、実際のAIが使っているのは、縦・横・高さの3次元ではありません。 数百次元、数千次元といった、人間には直接イメージできない空間です。 その中に、 動物らしさ。 食べ物らしさ。 場所らしさ。 感情に関係する特徴。 文章の中で主語になりやすい性質。 といったものが、複雑に混ざり合って表現されています。 ただし、「3番目の数字は動物らしさ」といった単純な対応になっているわけではありません。 一つの意味が、たくさんの数字に分散して表現されています。 逆に、一つの数字も、さまざまな意味や文法上の特徴に関係しています。 AIの中身を数字で見ても、人間には簡単に読み解けないのは、このためです。 ■同じ言葉でも、文章によって意味が変わる さらに、現在の生成AIでは、言葉に一つの固定ベクトルがあるだけではありません。 周囲の文章を読んで、ベクトルが変化します。 たとえば、英語の「bank」には、「銀行」と「川岸」という別の意味があります。 I deposited money at the bank. 銀行にお金を預けた。 I sat on the river bank. 川岸に座った。 同じ「bank」という言葉でも、周囲に「money」や「deposited」があれば、銀行の意味に近づきます。 「river」や「sat」があれば、川岸の意味に近づきます。 最初に「bank」というトークンを数字へ変換したあと、周囲の言葉との関係を使って、その文章に合ったベクトルへ変化させているのです。 そのため、より正確には、 「言葉には最初のベクトルがある」 だけでなく、 「文章を読むたびに、文脈に合わせたベクトルが作られる」 と考えたほうがよさそうです。 ■「AIのつまみを回す」という話ともつながっている 以前、AIの学習は「大量のつまみを回すようなもの」と聞きました。 この話も、そこにつながっています。 AIの中には、言葉をベクトルへ変換するための数字があります。 そのベクトルを文脈に合わせて変化させるための数字もあります。 次の言葉を予測するための数字もあります。 こうした大量の数字が、AIの「つまみ」です。 AIが予測を外すたびに、正解へ少し近づくよう、膨大なつまみをほんの少しずつ動かします。 その調整を繰り返した結果として、 「犬」と「猫」は近い。 「東京」と「大阪」は似た役割を持つ。 「食べる」と「飲む」は似た位置に登場する。 といった関係が、ベクトルの空間に作られていきます。 誰かが意味の地図を描いたのではありません。 次の言葉を当てる練習を続けた結果、いつの間にか意味の地図らしきものができていたのです。 ■では、AIは言葉の意味を理解しているのか ここまで聞くと、AIは言葉の意味を理解しているように思えます。 犬と猫の違いを説明できる。 文章の前後を見て、同じ言葉の意味を使い分けられる。 冗談や比喩を読み取ることもある。 人間の質問に合わせて、説明の仕方を変えることもできます。 これだけできれば、「理解している」と呼んでもよいような気もします。 一方で、AIが学習したのは、言葉がどのように使われるかというパターンです。 犬を実際に見たことはありません。 頭をなでたときの毛の感触も知りません。 吠え声を聞いて驚いた経験もありません。 散歩中に突然引っ張られたこともありません。 「犬」という言葉を、現実の犬と直接結び付けて覚えたわけではないのです。 AIにとっての犬は、まず文章の中に現れる存在です。 「犬」という言葉の周囲に、どんな言葉が並び、どんな説明があり、どんな会話が続くのか。 その関係を、膨大な数の文章から学んでいます。 ■人間の理解は、現実と結び付いている 人間の場合、「犬」という言葉の意味は、言葉だけでできているわけではありません。 犬の姿。 鳴き声。 におい。 触った感触。 怖かった経験。 かわいいと思った気持ち。 飼っていた犬との思い出。 そうした体験と結び付いています。 「熱い」という言葉も、辞書の説明だけで理解しているわけではありません。 熱い鍋に触りそうになって、手を引っ込めた経験があります。 夏の日差しを浴びて、暑いと感じた経験があります。 言葉が、身体や感情や現実の出来事とつながっています。 AIには、少なくとも現在の一般的な文章生成AIには、同じ形の身体的な経験はありません。 そのため、 人間は、現実の体験を通して言葉を理解している。 AIは、人間が残した言葉の関係を通して言葉を扱っている。 という違いはありそうです。 ■それでも、言葉だけから学べることは多い では、AIは現実を何も知らないのでしょうか。 そう言い切るのも、少し違う気がします。 人間が書いた文章には、現実で経験したことが大量に記録されています。 犬は吠える。 火は熱い。 氷は冷たい。 人は悲しいと泣くことがある。 高いところから物を落とすと下へ落ちる。 AIは現実を直接体験していませんが、人間が現実を体験して書いた文章を読んでいます。 つまり、AIが読んでいる文章は、単なる記号の集まりではありません。 人間が世界を見て、触れて、感じて、考えた結果が、言葉として残されたものです。 AIは、その痕跡から世界の構造を間接的に学んでいるともいえます。 自分で犬を見たことはない。 けれど、犬を見た何億人もの人が書いた文章を読んでいる。 自分で悲しんだことはない。 けれど、悲しんだ人たちが残した言葉を大量に読んでいる。 そこから、「犬とは何か」「悲しみとは何か」について、かなり複雑な関係を組み立てられるようになっています。 ■人間も、すべてを体験しているわけではない 考えてみると、人間も知っていることのすべてを、自分で体験しているわけではありません。 私は月へ行ったことがありません。 恐竜を見たこともありません。 戦国時代に暮らしたこともありません。 それでも、月や恐竜や戦国時代について、ある程度は理解しているつもりです。 本を読み、写真を見て、人の説明を聞いて学んだからです。 つまり、人間の理解にも、他人が残した言葉から作られた部分がたくさんあります。 そう考えると、 「直接体験していないから、まったく理解していない」 とも言い切れません。 ただし、人間には、少なくとも一部の言葉を身体的な体験と結び付ける土台があります。 「見る」「触る」「痛い」「怖い」「うれしい」といった基本的な感覚を、自分の体験として知っています。 その土台の上に、本や会話から得た知識を積み重ねています。 一方、文章だけで学習したAIは、その土台まで言葉から推測しています。 ここは大きな違いかもしれません。 ■「理解しているか」は、二択ではないのかもしれない AIは意味を理解しているのか。 この問いには、「はい」か「いいえ」のどちらかで答えたくなります。 しかし、理解という言葉自体が、思っているより曖昧なのかもしれません。 辞書的な意味を説明できること。 文章の中で正しく使えること。 初めて見る例にも応用できること。 現実の物と結び付いていること。 身体的な感覚を伴っていること。 自分の経験として覚えていること。 私たちは、これらをまとめて「理解」と呼んでいます。 AIは、その一部についてはかなり高い能力を持っています。 一方で、人間が持つ身体的な経験や、主観的な感覚まで同じように持っているとはいえません。 そのため、 「AIは何も理解していない」 と言うのも乱暴です。 かといって、 「人間と同じように理解している」 と言うのも違うでしょう。 AIは、人間とは違う方法で、言葉同士の関係をつかんでいる。 今のところは、それくらいの言い方が近いのかもしれません。 ■おわりに 「意味の近い言葉は、近いベクトルになる」 最初にこの説明を聞いたとき、誰かが言葉の意味を分類し、AIの中に配置したのだと思っていました。 しかし、実際には逆でした。 最初に意味の地図を作ったのではありません。 AIに大量の文章を読ませ、次の言葉を当てる練習をさせました。 すると、似た場面で使われる言葉が、予測に便利なように近づいていきました。 その結果として、意味の地図のようなものが現れました。 そして、その地図を使うことで、AIは言葉の違いを説明し、文脈を読み、初めて見る文章にも対応します。 それを「理解」と呼ぶのかは、まだ簡単には決められません。 ただ、少なくともAIは、単語を適当に並べているだけではありません。 人間が残した膨大な文章から、言葉の背後にある関係を拾い上げています。 人間は、世界を体験しながら言葉を覚える。 AIは、人間が世界を体験して残した言葉から、世界を逆算する。 そう考えると、人間とAIは、同じ「意味」に向かって、かなり違う道を歩いているのかもしれません。 ただの数字の並びから、「犬」と「猫」が近いことが浮かび上がってくる。 仕組みを知るほど、AIが賢く見えるというより、「意味とはそもそも何なのだろう」と、こちら側の理解まで怪しくなってきます。
0
6
0
0
2K
arisan2026's profile image
アリさん Verified account @arisan2026
【くるま】車の窓は、いつ操作できなくなる？ ヴェゼルで実験してみた【教えてAI先生】 GR86からヴェゼルに乗り換えて、早速困ったことがありました。 車から降りた後で、窓を閉め忘れたことに気づいたんです。 普通なら、もう一度乗り込んで閉めればいいだけの話です。 ところが、自宅の駐車場は非常に狭く、車から降りるだけでも一苦労。 ようやく降りてドアを閉めたところだったので、もう一度乗り込む気にはなれません。 そこで、車外からパワーウィンドウを操作できないか試してみました。 電源OFFでは動かない。 ACCにしても動かない。 ONモードにもなったと思うのですが、エンジンが動いていないので、ここでも操作できないだろうと判断して試しませんでした。 ブレーキペダルには足が届かないので、走行可能状態にはできません。 これは困った……。 そこで、スマートキーで窓を閉められることを思い出しました。 無事に閉めることができました。 セーフ！ でも、ちょっと疑問が残りました。 そもそも、窓の開け閉めくらい、電源を入れなくてもできていいんじゃない？ 気になったので調べてみました。 ■そもそも、電源ONとエンジン始動は違う 最初に分かったのは、僕の思い込みでした。 ヴェゼルは、ブレーキを踏まずにPOWERスイッチを押すと、 OFF → ACC → ON → OFF という順番で電源モードが切り替わります。 そして、パワーウィンドウを操作できるのはONモードです。 つまり、走行可能状態（READY）にする必要はありません。 もちろん、エンジンが動いていなくてもバッテリーから電力を供給できることは分かっています。 ただ、メーカーがバッテリー保護などの理由から、エンジン始動中にしか窓を操作できないように制限しているのだろう、と勝手に理解していたんです。 だから、ACCで動かなかった時点で、ONでも試さなかった。 そういえば、GR86でもエンジンを始動しないONモードがあったような……。 普段は意識していませんでした。 ■実は電源OFFでも窓を操作できる さらに調べてみると、ヴェゼルには便利な機能がありました。 ホンダの取扱説明書によると、電源OFF後も約10分間は、自動開閉機能付きのパワーウィンドウを操作できるそうです。 ただし、条件があります。 運転席ドアを開閉すると、操作できなくなる。 ん？ 開閉って、開けた瞬間？ それとも開けて閉めた後？ しかも、なぜ運転席ドアだけ？ これは実際に確認してみた方が早そうです。 ■ヴェゼルで実験してみた ということで、実車で試してみました。 まず、電源ONの状態。 運転席ドアを開けても、閉めても、パワーウィンドウは操作できます。 次に、電源をOFFにします。 窓は操作できます。 運転席ドアを開けます。 まだ操作できます。 そして、運転席ドアを閉めます。 ここで操作できなくなりました。 なるほど！ どうやら、運転席ドアを開けることではなく、閉めることがポイントのようです。 今度は助手席ドアでも試してみました。 電源OFF後に助手席ドアを開けても、閉めても、助手席の窓は操作できました。 実験結果を整理すると、次のようになりました。 電源ONのとき ・運転席ドアを開けても操作できる。 ・運転席ドアを閉めても操作できる。 電源OFFにした後 ・電源を切った直後は操作できる。 ・運転席ドアを開けても、まだ操作できる。 ・運転席ドアを閉めると、操作できなくなる。 ・助手席ドアを開閉しても、助手席の窓は操作できる。 ※自分のヴェゼル e:HEV Zで確認した結果です。約10分という制限時間は取扱説明書の記載によります。 つまり、運転席ドアを開けた瞬間ではなく、閉めた時点で操作できなくなるんです。 そして、助手席ドアの開閉では操作できる状態が維持されます。 これは、単にドアが開いたことを検知しているのではなく、運転席ドアを閉める動作を、運転者が降車したことの判断に使っているように見えます。 もちろん、これがホンダの意図した設計理由なのかは分かりません。 でも、なかなか興味深い動作です。 ■他のメーカーはどうなっている？ そうなると、他のメーカーが気になります。 各社の公式取扱説明書を調べてみました。 ホンダ ヴェゼル e:HEV（2026年版） 電源OFF後、約10分間操作可能。 運転席ドアを開閉すると操作できなくなります。 今回の実験では、運転席ドアを閉めた時点で無効になることを確認しました。 トヨタ GR86（2022年版） エンジンスイッチをACCまたはOFFにした後も、約40秒間操作できます。 ただし、ドアを開閉すると操作できなくなります。 以前乗っていたGR86も、基本的な考え方は似ていたようです。 トヨタ プリウス（2023年版・PHEV） こちらは約45秒間。 運転席ドアを開閉すると操作できなくなります。 同じトヨタでも、GR86とは時間や説明書の条件が異なっています。 日産 セレナ e-POWER（2024年版） 電源OFF後、約45秒間操作可能。 ただし、運転席または助手席のドアを開けると操作できなくなります。 ホンダとは条件が違いますね。 マツダ MAZDA3（2025年版） 電源をACCまたはOFFにした後も、約40秒間は全席の窓を操作できます。 確認した説明書の記述には、ドア開閉による終了条件は明記されていませんでした。 実際にドアを開けた後も操作できるかは、別途確認が必要です。 こうして見ると、操作できる時間だけでなく、ドアの扱いにも違いがあります。 なお、取扱説明書に「開閉すると」と書かれている場合、それだけでは開けた瞬間と閉めた時点のどちらで無効になるのかは分かりません。 今回のヴェゼルのように、実車で確かめないと分からないこともあるようです。 ■MINIには、もっと面白い仕様があった 以前乗っていたMINIでは、エンジンを止めても窓を操作できたような記憶があります。 調べてみると、2008年型MINI Clubmanの米国向け取扱説明書に、面白い記述がありました。 エンジン停止後も一定時間は操作できるのですが、ドアを開けると使えなくなります。 ここまでは似ています。 ところが、コンフォートアクセス装備車には、次のような仕組みがありました。 ドアを閉め直し、キーが車内にあれば、再び窓を操作できる。 おお、そういう設計もあるんですね。 もちろん、これは2008年型の特定装備についての話です。 現在のMINIや、すべての年式で同じとは限りません。 また、キーが車内にあることが条件なので、降りた後の閉め忘れを必ず解決できるわけでもありません。 それでも、ドア開閉後に操作を再び許可するという設計が存在したことは興味深いです。 ■なぜドアを開閉すると操作できなくなる？ ここからは、ちょっと考えてみます。 そもそも、パワーウィンドウは電気モーターで動いています。 エンジンが停止していても、12Vバッテリーから電気を供給することはできます。 実際、ヴェゼルは電源OFF後も約10分間操作できますし、スマートキーから窓を閉めることもできます。 つまり、電源OFF後に窓を操作できなくなるのは、単純に電力が供給できないからではありません。 車両側で、操作を許可する条件を決めているわけです。 では、なぜ運転席ドアなのでしょう。 考えられるのは、運転者が車から降りたことを判断するためです。 電源を切っても、まだ車内で窓を閉めたい場合がある。 そこで一定時間、操作を許可しておく。 運転席ドアを開けて閉めたら、運転者が降りたと判断して操作を終了する。 確かに、理屈は通ります。 また、子どもの誤操作防止やバッテリー保護など、安全性や電源管理の観点も考えられます。 ただし、これらはあくまで推測です。 なぜその条件にしたのか、メーカーが公式に説明している資料までは確認できませんでした。 ■でも、そこで操作できなくする必要がある？ ここで最初の疑問に戻ります。 僕は今回、運転席ドアを閉めてから窓の閉め忘れに気づきました。 つまり、車から降りる直前ではなく、車から降りた後にこそ窓を操作したかったわけです。 窓を開閉するための電力はある。 ドアを開けた状態でも操作できる。 スマートキーでも閉められる。 それなら、運転席ドアを閉めた後でも、一定時間くらいは操作できてもよいのではないでしょうか。 もちろん、安全性との兼ね合いはあると思います。 でも、各社で仕様が異なり、条件付きで再操作できるMINIの例もあるのなら、必ずこの方式にしなければならないわけでもなさそうです。 安全性と利便性をどう両立させるのか。 ここはメーカーごとの設計思想が現れるところなのかもしれません。 ■まとめ。窓を閉め忘れたら、まず操作条件を確認 今回の件で、いくつか勉強になりました。 まず、エンジンが動いていなくても、電源ONならパワーウィンドウを操作できます。 そして、電源OFF後も一定時間は窓を操作できる車が多いこと。 ただし、ドアを開けたり閉めたりすると、その機能が終了する場合があります。 さらに、その条件はメーカーや車種によって違うようです。 ヴェゼルの場合は、運転席ドアを開けただけなら操作でき、閉めた時点で操作できなくなることを実車で確認できました。 最初は単純に、エンジンを始動しないと窓を操作できない仕様なのだろうと思っていました。 ところが調べてみると、電源モードの違い、操作可能時間、ドア開閉の判定など、意外と細かく制御されていることが分かりました。 何より、長年車に乗っていても、まだ知らないことがあるものですね。 もっとも、今回のヴェゼルにはスマートキーで窓を閉める機能があります。 結果的には、これが一番簡単な解決方法でした。 ただ、便利な解決方法があることと、元の操作条件が使いやすいかどうかは別の話です。 窓を閉め忘れたことに気づくのは、車から降りる前だけとは限らないんですよね。 今回の実験で、改めてそう感じました。 ■参考資料 各社の公式取扱説明書を参照しました。仕様は年式、車種、装備によって異なります。 ・Honda VEZEL e:HEV 2026：パワーウィンドー https://t.co/xN4d78bsci ・Honda VEZEL e:HEV 2026：POWERスイッチ https://t.co/GP23Gmpe38 ・トヨタ GR86：パワーウインドウ https://t.co/78gby51lLk ・トヨタ プリウス PHEV：パワーウインドウ https://t.co/vboompdGws ・日産 セレナ e-POWER：パワーウインドー https://t.co/plprMtDy20 ・マツダ MAZDA3：電子取扱説明書 https://t.co/ZjkMTJSlEH ・MINI Clubman 2008：Owner's Manual（英語・PDF） https://t.co/FHISsaO10J
arisan2026's tweet photo. 【くるま】車の窓は、いつ操作できなくなる？ ヴェゼルで実験してみた【教えてAI先生】 GR86からヴェゼルに乗り換えて、早速困ったことがありました。 車から降りた後で、窓を閉め忘れたことに気づいたんです。 普通なら、もう一度乗り込んで閉めればいいだけの話です。 ところが、自宅の駐車場は非常に狭く、車から降りるだけでも一苦労。 ようやく降りてドアを閉めたところだったので、もう一度乗り込む気にはなれません。 そこで、車外からパワーウィンドウを操作できないか試してみました。 電源OFFでは動かない。 ACCにしても動かない。 ONモードにもなったと思うのですが、エンジンが動いていないので、ここでも操作できないだろうと判断して試しませんでした。 ブレーキペダルには足が届かないので、走行可能状態にはできません。 これは困った……。 そこで、スマートキーで窓を閉められることを思い出しました。 無事に閉めることができました。 セーフ！ でも、ちょっと疑問が残りました。 そもそも、窓の開け閉めくらい、電源を入れなくてもできていいんじゃない？ 気になったので調べてみました。 ■そもそも、電源ONとエンジン始動は違う 最初に分かったのは、僕の思い込みでした。 ヴェゼルは、ブレーキを踏まずにPOWERスイッチを押すと、 OFF → ACC → ON → OFF という順番で電源モードが切り替わります。 そして、パワーウィンドウを操作できるのはONモードです。 つまり、走行可能状態（READY）にする必要はありません。 もちろん、エンジンが動いていなくてもバッテリーから電力を供給できることは分かっています。 ただ、メーカーがバッテリー保護などの理由から、エンジン始動中にしか窓を操作できないように制限しているのだろう、と勝手に理解していたんです。 だから、ACCで動かなかった時点で、ONでも試さなかった。 そういえば、GR86でもエンジンを始動しないONモードがあったような……。 普段は意識していませんでした。 ■実は電源OFFでも窓を操作できる さらに調べてみると、ヴェゼルには便利な機能がありました。 ホンダの取扱説明書によると、電源OFF後も約10分間は、自動開閉機能付きのパワーウィンドウを操作できるそうです。 ただし、条件があります。 運転席ドアを開閉すると、操作できなくなる。 ん？ 開閉って、開けた瞬間？ それとも開けて閉めた後？ しかも、なぜ運転席ドアだけ？ これは実際に確認してみた方が早そうです。 ■ヴェゼルで実験してみた ということで、実車で試してみました。 まず、電源ONの状態。 運転席ドアを開けても、閉めても、パワーウィンドウは操作できます。 次に、電源をOFFにします。 窓は操作できます。 運転席ドアを開けます。 まだ操作できます。 そして、運転席ドアを閉めます。 ここで操作できなくなりました。 なるほど！ どうやら、運転席ドアを開けることではなく、閉めることがポイントのようです。 今度は助手席ドアでも試してみました。 電源OFF後に助手席ドアを開けても、閉めても、助手席の窓は操作できました。 実験結果を整理すると、次のようになりました。 電源ONのとき ・運転席ドアを開けても操作できる。 ・運転席ドアを閉めても操作できる。 電源OFFにした後 ・電源を切った直後は操作できる。 ・運転席ドアを開けても、まだ操作できる。 ・運転席ドアを閉めると、操作できなくなる。 ・助手席ドアを開閉しても、助手席の窓は操作できる。 ※自分のヴェゼル e:HEV Zで確認した結果です。約10分という制限時間は取扱説明書の記載によります。 つまり、運転席ドアを開けた瞬間ではなく、閉めた時点で操作できなくなるんです。 そして、助手席ドアの開閉では操作できる状態が維持されます。 これは、単にドアが開いたことを検知しているのではなく、運転席ドアを閉める動作を、運転者が降車したことの判断に使っているように見えます。 もちろん、これがホンダの意図した設計理由なのかは分かりません。 でも、なかなか興味深い動作です。 ■他のメーカーはどうなっている？ そうなると、他のメーカーが気になります。 各社の公式取扱説明書を調べてみました。 ホンダ ヴェゼル e:HEV（2026年版） 電源OFF後、約10分間操作可能。 運転席ドアを開閉すると操作できなくなります。 今回の実験では、運転席ドアを閉めた時点で無効になることを確認しました。 トヨタ GR86（2022年版） エンジンスイッチをACCまたはOFFにした後も、約40秒間操作できます。 ただし、ドアを開閉すると操作できなくなります。 以前乗っていたGR86も、基本的な考え方は似ていたようです。 トヨタ プリウス（2023年版・PHEV） こちらは約45秒間。 運転席ドアを開閉すると操作できなくなります。 同じトヨタでも、GR86とは時間や説明書の条件が異なっています。 日産 セレナ e-POWER（2024年版） 電源OFF後、約45秒間操作可能。 ただし、運転席または助手席のドアを開けると操作できなくなります。 ホンダとは条件が違いますね。 マツダ MAZDA3（2025年版） 電源をACCまたはOFFにした後も、約40秒間は全席の窓を操作できます。 確認した説明書の記述には、ドア開閉による終了条件は明記されていませんでした。 実際にドアを開けた後も操作できるかは、別途確認が必要です。 こうして見ると、操作できる時間だけでなく、ドアの扱いにも違いがあります。 なお、取扱説明書に「開閉すると」と書かれている場合、それだけでは開けた瞬間と閉めた時点のどちらで無効になるのかは分かりません。 今回のヴェゼルのように、実車で確かめないと分からないこともあるようです。 ■MINIには、もっと面白い仕様があった 以前乗っていたMINIでは、エンジンを止めても窓を操作できたような記憶があります。 調べてみると、2008年型MINI Clubmanの米国向け取扱説明書に、面白い記述がありました。 エンジン停止後も一定時間は操作できるのですが、ドアを開けると使えなくなります。 ここまでは似ています。 ところが、コンフォートアクセス装備車には、次のような仕組みがありました。 ドアを閉め直し、キーが車内にあれば、再び窓を操作できる。 おお、そういう設計もあるんですね。 もちろん、これは2008年型の特定装備についての話です。 現在のMINIや、すべての年式で同じとは限りません。 また、キーが車内にあることが条件なので、降りた後の閉め忘れを必ず解決できるわけでもありません。 それでも、ドア開閉後に操作を再び許可するという設計が存在したことは興味深いです。 ■なぜドアを開閉すると操作できなくなる？ ここからは、ちょっと考えてみます。 そもそも、パワーウィンドウは電気モーターで動いています。 エンジンが停止していても、12Vバッテリーから電気を供給することはできます。 実際、ヴェゼルは電源OFF後も約10分間操作できますし、スマートキーから窓を閉めることもできます。 つまり、電源OFF後に窓を操作できなくなるのは、単純に電力が供給できないからではありません。 車両側で、操作を許可する条件を決めているわけです。 では、なぜ運転席ドアなのでしょう。 考えられるのは、運転者が車から降りたことを判断するためです。 電源を切っても、まだ車内で窓を閉めたい場合がある。 そこで一定時間、操作を許可しておく。 運転席ドアを開けて閉めたら、運転者が降りたと判断して操作を終了する。 確かに、理屈は通ります。 また、子どもの誤操作防止やバッテリー保護など、安全性や電源管理の観点も考えられます。 ただし、これらはあくまで推測です。 なぜその条件にしたのか、メーカーが公式に説明している資料までは確認できませんでした。 ■でも、そこで操作できなくする必要がある？ ここで最初の疑問に戻ります。 僕は今回、運転席ドアを閉めてから窓の閉め忘れに気づきました。 つまり、車から降りる直前ではなく、車から降りた後にこそ窓を操作したかったわけです。 窓を開閉するための電力はある。 ドアを開けた状態でも操作できる。 スマートキーでも閉められる。 それなら、運転席ドアを閉めた後でも、一定時間くらいは操作できてもよいのではないでしょうか。 もちろん、安全性との兼ね合いはあると思います。 でも、各社で仕様が異なり、条件付きで再操作できるMINIの例もあるのなら、必ずこの方式にしなければならないわけでもなさそうです。 安全性と利便性をどう両立させるのか。 ここはメーカーごとの設計思想が現れるところなのかもしれません。 ■まとめ。窓を閉め忘れたら、まず操作条件を確認 今回の件で、いくつか勉強になりました。 まず、エンジンが動いていなくても、電源ONならパワーウィンドウを操作できます。 そして、電源OFF後も一定時間は窓を操作できる車が多いこと。 ただし、ドアを開けたり閉めたりすると、その機能が終了する場合があります。 さらに、その条件はメーカーや車種によって違うようです。 ヴェゼルの場合は、運転席ドアを開けただけなら操作でき、閉めた時点で操作できなくなることを実車で確認できました。 最初は単純に、エンジンを始動しないと窓を操作できない仕様なのだろうと思っていました。 ところが調べてみると、電源モードの違い、操作可能時間、ドア開閉の判定など、意外と細かく制御されていることが分かりました。 何より、長年車に乗っていても、まだ知らないことがあるものですね。 もっとも、今回のヴェゼルにはスマートキーで窓を閉める機能があります。 結果的には、これが一番簡単な解決方法でした。 ただ、便利な解決方法があることと、元の操作条件が使いやすいかどうかは別の話です。 窓を閉め忘れたことに気づくのは、車から降りる前だけとは限らないんですよね。 今回の実験で、改めてそう感じました。 ■参考資料 各社の公式取扱説明書を参照しました。仕様は年式、車種、装備によって異なります。 ・Honda VEZEL e:HEV 2026：パワーウィンドー https://t.co/xN4d78bsci ・Honda VEZEL e:HEV 2026：POWERスイッチ https://t.co/GP23Gmpe38 ・トヨタ GR86：パワーウインドウ https://t.co/78gby51lLk ・トヨタ プリウス PHEV：パワーウインドウ https://t.co/vboompdGws ・日産 セレナ e-POWER：パワーウインドー https://t.co/plprMtDy20 ・マツダ MAZDA3：電子取扱説明書 https://t.co/ZjkMTJSlEH ・MINI Clubman 2008：Owner's Manual（英語・PDF） https://t.co/FHISsaO10J
1
0
0
0
503
arisan2026's profile image
アリさん Verified account @arisan2026
【AI駆動開発メモ】「あとでやる」が、いつまでたっても終わらない理由 AI駆動開発をしていて、ちょっと困ったことがありました。 結合試験を自動化しようとしていたときの話です。 AIが一部の試験項目を実施しようとしないので、聞いてみました。 「この試験項目、実施しないの？」 するとAIは、試験項目に「次スプリントで実施」と書いてあるというんです。 そんなこと書いてあったかな？ 気になって確認してみると、次のような記述に反応しているようでした。 別機能で実装するため、ここでは実装しない 別機能が未実装のため、実装後対応。 なるほど、確かに試験を実施できない理由らしきものは書いてあります。 でも、その別機能はもう実装済みなんですよね。 しかも、実際には「実装後対応」と書かれていたのに、AIは「次スプリントで実施」と説明していました。 古い記述を根拠に、試験を実施しなくてよいと判断してしまったようです。 ■実装は忘れていなかった ここで重要なのは、対象機能の実装自体は忘れられていなかったことです。 予定どおり、ちゃんと実装されています。 問題は、その機能を参照している別の文書に「未実装」という記述が残っていたことでした。 今回の2つの記述を比べてみます。 「別機能で実装するため、ここでは実装しない」 これは実装する場所を決めているだけなので、基本的には問題ありません。 一方、 「別機能が未実装のため、実装後対応」 こちらは、未実装であることを前提とした一時的な判断です。 その機能が実装されたら、前提が変わります。 作業は完了しているのに、文書の中では未完了のまま。 今回遭遇したのは、そんな問題でした。 ■「今」「次」って、いつのこと？ 考えてみると、仕様書や作業記録には、こんな表現が結構あります。 ・今スプリントで実施する ・次スプリントで実施する ・未実装なので、実装後に対応する ・今回の作業範囲外なので、別途対応する 人間なら、書かれた時期や開発の経緯から判断できるかもしれません。 でもAIは、渡された文書を頼りに判断します。 数週間前の「今スプリント」は、現在のスプリントではありません。 「次スプリント」も、すでに終わっているかもしれません。 そして、「未実装」と書かれた機能が、すでに実装されていることもあります。 書かれた当時は正しかった情報が、今でも正しいとは限らない。 ここが厄介なんです。 ■AIは「あとでやる」を回収してくれない もう一つ気になっていることがあります。 AIに作業を依頼すると、こんな提案をされることがあります。 「今回の作業範囲外なので、別途対応しましょう」 その場では、もっともらしい判断です。 では、次のスプリントになったらどうなるでしょうか。 AIが自分から「前回先送りした作業があります。今回は実施しましょう」と教えてくれるでしょうか。 通常のAIとのやり取りでは、そうした通知の仕組みはありません。 人間が気づいて作業を依頼するか、AIがたまたま関連する記述を見つけるまで、放置される可能性があります。 そして再び同じ問題に遭遇すると、またAIが言うんです。 「今回の作業範囲外なので、別途対応しましょう」 先送りするという判断だけが、ずっと残り続ける。 人間の開発でも起こることですが、AIが自動的に作業を進めてくれるようになると、こうした問題も自動的に解決してくれると期待してしまいます。 でも、実際にはそうではありませんでした。 ■文書が増えても、教えてくれない 今回の結合試験では、もう一つ問題がありました。 別機能の実装が終わっても、その機能を参照している文書が自動的に更新されるわけではありません。 しかも、開発が進むにつれて文書は増えていきます。 仕様書、設計書、試験項目、作業記録など、同じ機能について複数の場所に記述が存在することもあります。 その中の一つが変更されたとしても、ほかの文書も修正する必要があるとは限りませんし、必要な場合でもAIが自動的に教えてくれるとは限りません。 今回のように、実装が完了したという情報と、別の文書に残った「未実装」という記述が矛盾してしまうことがあります。 一つの作業は正しく完了していても、開発全体の情報が正しく更新されているとは限らない。 これも、AI駆動開発で気をつけなければいけない点だと思いました。 ■試験を省略する理由は、今も正しいのか？ 今回の結合試験で、さらに気づいたことがあります。 AIが試験を省略するとき、文書に省略理由が書かれているだけでは不十分だということです。 大切なのは、その理由が現在も成立しているかどうか。 「対象機能が未実装なので試験できない」 対象機能が本当に未実装なら、正しい判断です。 でも、すでに実装済みなら？ もはや試験を省略する理由にはなりません。 特に結合試験の自動化では、この確認が重要です。 AIが実行した試験がすべて成功していても、本来実施すべき試験が省略されていたら、品質を確認できたとは言えません。 そこで、試験を省略する場合には、その理由が現在も有効なのか、改めて確認する必要がありそうです。 ■どう対策すればいい？ いくつか考えてみました。 1. なるべくその場で対処する 小さな問題なら、安易に先送りせず、その場で解決してしまう。 もちろん、作業範囲や影響の確認は必要です。 ただ、「別途対応」を増やさないことが、一番単純で確実な対策かもしれません。 2. 先送りするなら、回収するきっかけを決める 「次スプリントで対応」と記録するだけでは不十分です。 具体的なスプリントや期日を記録しても、その時期になったことを誰も確認しなければ、結局放置されます。 期日だけでなく、いつ確認するのか、その確認をどの作業に組み込むのかも決めておく必要があります。 「機能Aの実装完了後に対応する」なら、機能Aの完了時に保留事項を確認する。 先送りするなら、回収するイベントも一緒に用意する。 これが必要なのだと思います。 3. 作業完了時に関連文書を確認する 今回のような問題を防ぐには、実装が完了したときに、その機能を参照している文書も確認する必要があります。 「未実装」「実装後対応」といった記述が残っていないか。 今回の変更によって、修正が必要になった試験項目はないか。 新たに追加された文書に、古い情報が引き継がれていないか。 こうした確認を、実装完了時の作業に含める方法です。 ただし、関連文書をすべて見つけること自体が難しいという問題もあります。 単純に文書を検索するだけでは、見落とす可能性もあります。 4. チェックポイントで保留事項を確認する AI駆動開発では、作業の区切りにチェックポイントを設けることがあります。 そこに、保留事項や関連文書の確認を組み込む方法も考えられます。 今回新しく先送りした作業はないか。 過去の保留事項で、実施可能になったものはないか。 今回の実装によって、古くなった記述はないか。 試験を省略した理由は、現在も有効なのか。 毎回すべての文書を確認するのは大変なので、保留事項や関連文書を管理する仕組みも必要になりそうです。 ■AIが賢くなれば解決するのか？ 今回の問題を考えていて、AIの性能が上がれば自然に解決する、という話でもないように思いました。 もちろん、AIが賢くなれば、古い記述の矛盾を見つけやすくなるかもしれません。 でも、AIに確認する機会が与えられなければ、そもそも気づくことができません。 次スプリントになったことを知らせる仕組み。 機能が実装されたときに、関連する文書を確認する仕組み。 試験を省略するときに、その理由を再確認する仕組み。 必要なのは、AIに何を確認させるかだけでなく、いつ確認させるかを設計することなのかもしれません。 ■「あとでやる」は、本当にやってくるのか？ 今回の結合試験では、僕が疑問に思って確認したことで問題に気づきました。 でも、気づかなかったら？ 試験が省略されたまま、何事もなかったように進んでいたかもしれません。 AI駆動開発では、仕様書を作ることも、実装することも、試験を実行することも自動化できるようになってきました。 一方で、先送りした作業を回収することや、変更によって古くなった情報を更新することは、まだ十分に仕組み化できていないと感じています。 これからは、そうした部分にも目を向ける必要がありそうです。 そして、個人的に気をつけたい言葉が一つ増えました。 「あとでやりましょう」 その「あとで」は、本当にやってくるのでしょうか。
arisan2026's tweet photo. 【AI駆動開発メモ】「あとでやる」が、いつまでたっても終わらない理由 AI駆動開発をしていて、ちょっと困ったことがありました。 結合試験を自動化しようとしていたときの話です。 AIが一部の試験項目を実施しようとしないので、聞いてみました。 「この試験項目、実施しないの？」 するとAIは、試験項目に「次スプリントで実施」と書いてあるというんです。 そんなこと書いてあったかな？ 気になって確認してみると、次のような記述に反応しているようでした。 別機能で実装するため、ここでは実装しない 別機能が未実装のため、実装後対応。 なるほど、確かに試験を実施できない理由らしきものは書いてあります。 でも、その別機能はもう実装済みなんですよね。 しかも、実際には「実装後対応」と書かれていたのに、AIは「次スプリントで実施」と説明していました。 古い記述を根拠に、試験を実施しなくてよいと判断してしまったようです。 ■実装は忘れていなかった ここで重要なのは、対象機能の実装自体は忘れられていなかったことです。 予定どおり、ちゃんと実装されています。 問題は、その機能を参照している別の文書に「未実装」という記述が残っていたことでした。 今回の2つの記述を比べてみます。 「別機能で実装するため、ここでは実装しない」 これは実装する場所を決めているだけなので、基本的には問題ありません。 一方、 「別機能が未実装のため、実装後対応」 こちらは、未実装であることを前提とした一時的な判断です。 その機能が実装されたら、前提が変わります。 作業は完了しているのに、文書の中では未完了のまま。 今回遭遇したのは、そんな問題でした。 ■「今」「次」って、いつのこと？ 考えてみると、仕様書や作業記録には、こんな表現が結構あります。 ・今スプリントで実施する ・次スプリントで実施する ・未実装なので、実装後に対応する ・今回の作業範囲外なので、別途対応する 人間なら、書かれた時期や開発の経緯から判断できるかもしれません。 でもAIは、渡された文書を頼りに判断します。 数週間前の「今スプリント」は、現在のスプリントではありません。 「次スプリント」も、すでに終わっているかもしれません。 そして、「未実装」と書かれた機能が、すでに実装されていることもあります。 書かれた当時は正しかった情報が、今でも正しいとは限らない。 ここが厄介なんです。 ■AIは「あとでやる」を回収してくれない もう一つ気になっていることがあります。 AIに作業を依頼すると、こんな提案をされることがあります。 「今回の作業範囲外なので、別途対応しましょう」 その場では、もっともらしい判断です。 では、次のスプリントになったらどうなるでしょうか。 AIが自分から「前回先送りした作業があります。今回は実施しましょう」と教えてくれるでしょうか。 通常のAIとのやり取りでは、そうした通知の仕組みはありません。 人間が気づいて作業を依頼するか、AIがたまたま関連する記述を見つけるまで、放置される可能性があります。 そして再び同じ問題に遭遇すると、またAIが言うんです。 「今回の作業範囲外なので、別途対応しましょう」 先送りするという判断だけが、ずっと残り続ける。 人間の開発でも起こることですが、AIが自動的に作業を進めてくれるようになると、こうした問題も自動的に解決してくれると期待してしまいます。 でも、実際にはそうではありませんでした。 ■文書が増えても、教えてくれない 今回の結合試験では、もう一つ問題がありました。 別機能の実装が終わっても、その機能を参照している文書が自動的に更新されるわけではありません。 しかも、開発が進むにつれて文書は増えていきます。 仕様書、設計書、試験項目、作業記録など、同じ機能について複数の場所に記述が存在することもあります。 その中の一つが変更されたとしても、ほかの文書も修正する必要があるとは限りませんし、必要な場合でもAIが自動的に教えてくれるとは限りません。 今回のように、実装が完了したという情報と、別の文書に残った「未実装」という記述が矛盾してしまうことがあります。 一つの作業は正しく完了していても、開発全体の情報が正しく更新されているとは限らない。 これも、AI駆動開発で気をつけなければいけない点だと思いました。 ■試験を省略する理由は、今も正しいのか？ 今回の結合試験で、さらに気づいたことがあります。 AIが試験を省略するとき、文書に省略理由が書かれているだけでは不十分だということです。 大切なのは、その理由が現在も成立しているかどうか。 「対象機能が未実装なので試験できない」 対象機能が本当に未実装なら、正しい判断です。 でも、すでに実装済みなら？ もはや試験を省略する理由にはなりません。 特に結合試験の自動化では、この確認が重要です。 AIが実行した試験がすべて成功していても、本来実施すべき試験が省略されていたら、品質を確認できたとは言えません。 そこで、試験を省略する場合には、その理由が現在も有効なのか、改めて確認する必要がありそうです。 ■どう対策すればいい？ いくつか考えてみました。 1. なるべくその場で対処する 小さな問題なら、安易に先送りせず、その場で解決してしまう。 もちろん、作業範囲や影響の確認は必要です。 ただ、「別途対応」を増やさないことが、一番単純で確実な対策かもしれません。 2. 先送りするなら、回収するきっかけを決める 「次スプリントで対応」と記録するだけでは不十分です。 具体的なスプリントや期日を記録しても、その時期になったことを誰も確認しなければ、結局放置されます。 期日だけでなく、いつ確認するのか、その確認をどの作業に組み込むのかも決めておく必要があります。 「機能Aの実装完了後に対応する」なら、機能Aの完了時に保留事項を確認する。 先送りするなら、回収するイベントも一緒に用意する。 これが必要なのだと思います。 3. 作業完了時に関連文書を確認する 今回のような問題を防ぐには、実装が完了したときに、その機能を参照している文書も確認する必要があります。 「未実装」「実装後対応」といった記述が残っていないか。 今回の変更によって、修正が必要になった試験項目はないか。 新たに追加された文書に、古い情報が引き継がれていないか。 こうした確認を、実装完了時の作業に含める方法です。 ただし、関連文書をすべて見つけること自体が難しいという問題もあります。 単純に文書を検索するだけでは、見落とす可能性もあります。 4. チェックポイントで保留事項を確認する AI駆動開発では、作業の区切りにチェックポイントを設けることがあります。 そこに、保留事項や関連文書の確認を組み込む方法も考えられます。 今回新しく先送りした作業はないか。 過去の保留事項で、実施可能になったものはないか。 今回の実装によって、古くなった記述はないか。 試験を省略した理由は、現在も有効なのか。 毎回すべての文書を確認するのは大変なので、保留事項や関連文書を管理する仕組みも必要になりそうです。 ■AIが賢くなれば解決するのか？ 今回の問題を考えていて、AIの性能が上がれば自然に解決する、という話でもないように思いました。 もちろん、AIが賢くなれば、古い記述の矛盾を見つけやすくなるかもしれません。 でも、AIに確認する機会が与えられなければ、そもそも気づくことができません。 次スプリントになったことを知らせる仕組み。 機能が実装されたときに、関連する文書を確認する仕組み。 試験を省略するときに、その理由を再確認する仕組み。 必要なのは、AIに何を確認させるかだけでなく、いつ確認させるかを設計することなのかもしれません。 ■「あとでやる」は、本当にやってくるのか？ 今回の結合試験では、僕が疑問に思って確認したことで問題に気づきました。 でも、気づかなかったら？ 試験が省略されたまま、何事もなかったように進んでいたかもしれません。 AI駆動開発では、仕様書を作ることも、実装することも、試験を実行することも自動化できるようになってきました。 一方で、先送りした作業を回収することや、変更によって古くなった情報を更新することは、まだ十分に仕組み化できていないと感じています。 これからは、そうした部分にも目を向ける必要がありそうです。 そして、個人的に気をつけたい言葉が一つ増えました。 「あとでやりましょう」 その「あとで」は、本当にやってくるのでしょうか。
1
4
0
0
116
arisan2026's profile image
アリさん Verified account @arisan2026
【くるま】ヴェゼル納車2日、225.5km走って分かったこと。GR86との違いが想像以上に面白い GR86からホンダ・ヴェゼル e:HEV Zに乗り換えました。 納車から2日。走行距離は225.5kmになりました。 前回の記事では、GR86から乗り換えることで「失われるもの」を書きました。 今度は、実際にヴェゼルに乗ってみてどうだったのか。 良かったこと、不満に思ったこと、予想と違ったこと。 忘れないうちに、思いつくまま書き出してみます。 というのも、すでに慣れ始めているんですよね。 納車直後の違和感は、意外と早く消えてしまうのかもしれません。 ■まず、GR86の癖が抜けない 最初にやってしまったのが、エアークラッチ。 信号待ちなどで、無意識に左足がクラッチを踏もうとします。 当然、そこにクラッチペダルはありません。 長年の習慣というのは恐ろしいものです。 そして給油でも。 いつものようにハイオクを選択してしまう。 ヴェゼルはレギュラー仕様なのに、体が覚えているんですよね。 でも、レギュラーって安い！ これは素直にうれしい。 燃費は現在、およそ21km/L。 エコランを楽しみたいところですが、自宅が坂の上なので、最後の登りで燃費が悪化するのが悩ましいところです。 ■走りはどうなのか？ まず、パワーについて。 一般道を走る分には、まったく問題ありません。 GR86からの乗り換えなので、もっと不満が出るかと思っていましたが、日常的な速度域では十分です。 パワーモードも試してみました。 アクセルへの反応がよくなり、スイスイ走る印象です。 ただし、慣れないとギクシャクするかもしれません。 個人的には、結構いいかも。 減速セレクターについては、まだお試し中です。 ステアリングも、GR86から乗り換えたことで大きな違和感が出るかと思いましたが、特にありませんでした。 一方、車体の揺れは気になりました。 GR86は路面の凹凸をよく拾います。でも、その後の揺れは長く残りません。 ヴェゼルは、最初に左右の揺れを感じました。 やはり重心が高いからでしょうか。サスペンションの特性も違うのでしょう。 ただ、これもすでに慣れ始めています。 乗り心地が悪いというより、車体の動き方が違うんですね。 静粛性は確かに高いです。 ただし、静かな分だけロードノイズが気になるようになりました。 それから、小回り。 スーパーなどの駐車場でバック駐車をすると、GR86より少し大回りする印象です。 いつもの感覚でハンドルを切ると「あれ？」となる。 数字では小さな違いでも、実際の運転では分かるものですね。 ■運転支援は便利。でも、自分の好みとは少し違う 今回ヴェゼルを選んだ理由の一つが、運転支援機能です。 ACCやLKASには期待していました。 実際、便利です。 ただ、いくつか気になるところがありました。 まずACC。 ブレーキをかけ始めるタイミングが、自分の好みより遅いんです。 もう少し早い段階から穏やかに減速してほしい。 自分でブレーキを踏んだ方がジェントルに止まれます。 もちろん、車間距離や交通状況などによって動作は変わりますが、今のところそういう印象です。 次にLKAS。 まっすぐ走っていると、「ハンドルを操作してください」と警告されます。 いや、ちゃんと運転しているんですけど……。 直進しているからこそ、ハンドルを大きく操作する必要がないわけで。 これも少しストレスです。 そしてハイビーム。 ハイビームの表示が出ていると、前の車をちゃんと避けて照らしてくれているんだよね？ と不安になります。 単に表示が目障りなのではありません。 実際にどこを照らしているのかが分からないのが気になるんです。 せっかくなら、ブレーキ状態などを確認する表示画面で、ライトの照射状態も確認できたらいいのに。 オートブレーキホールドも、解除される瞬間に少し違和感があります。 ただ、便利なのは間違いないので、これは使い続けるかもしれません。 自動で運転を支援してくれるのはありがたい。 でも、自分の運転感覚と完全に一致するわけではないんですね。 ■オートワイパーも以心伝心とはいかない オートワイパーも試してみました。 こちらも微妙。 自分が動いてほしいタイミングと、実際に動くタイミングが必ずしも一致しません。 以心伝心とはいかないものですね。 それから、フロントワイパーが動いているなら、リアワイパーも状況に応じて連動してほしいところです。 便利な自動化ほど、自分の感覚との違いが気になるのかもしれません。 ■室内は予想より快適。でも収納は…… ヴェゼルを購入する前、いくつか心配していたことがありました。 その一つが天井の低さ。 SUVとしては低めのスタイルなので気になっていましたが、実際に乗ると特に問題ありませんでした。 助手席の足元も同様です。 センタータンクレイアウトの影響で、足元の形状が気になるかなと思っていましたが、特に違和感はありません。 運転席からの視界も、ものすごく広いわけではありませんが、不満はありません。 GR86と同じように水平基調のインパネで、ドアミラーの取り付け方なども似ているため、馴染みやすいのかもしれません。 一方、運転席の座面は、少し自分に合わない印象があります。 何が合わないのか、まだよく分かりません。 それから降りるとき。 GR86では低い座席から立ち上がる必要がありましたが、ヴェゼルでは逆に、地面に向かって足を伸ばす感じです。 座面が少し高いのかもしれません。 乗り降りのしやすさを重視して選んだ車ですが、低ければ困るし、高くても少し困る。 なかなか難しいものです。 そして収納。 グローブボックスは狭いです。 さらに驚いたのが荷室。 GR86のトランクに入っていた荷物が、ヴェゼルには全部入りませんでした。 もちろん、トノカバーより上まで積み上げれば入ります。 でも、荷物を隠して積むことを前提にすると、思ったほど収納できないんです。 SUVだから積載量が増えると思っていたわけではありませんが、これは少し意外でした。 ■後席は同乗者にも感想を聞いてみた 後席については、先輩にも感想を聞いてみました。 まず、前席の下に足を入れづらいとのこと。 僕自身は特に気にならなかったのですが、人によって感じ方が違うようです。 また、後席に乗り降りするとき、頭を屈める必要があるとのこと。 座ってしまえば問題がなくても、乗り降りの際には天井の高さが影響するんですね。 それから後席中央のアームレスト。 下に垂れ下がるという話を聞いていましたが、実際に確認してみると、それほど気になりませんでした。 ちなみに、後席のドリンクホルダーには1Lのペットボトルが入りませんでした。 まあ、そもそも1Lサイズを入れようとする方が想定外なのかもしれませんが（笑）。 もう一つ、後席ドアのハンドル。 これは僕自身も嫌いなのですが、同乗者からも総じて不評でした。 同乗者の意見は、「ハンドルが見つけづらい」「使いづらい」というもの。 僕も荷物を持っているときには開けづらいと感じています。 ヴェゼルは後席ドアのハンドルを窓の横に隠すことで、クーペのようなスタイルを演出しています。 でも、個人的には普通の位置にドアハンドルが付いている方が、かっこいいんじゃないかと思うんですよね。 もちろん、好みの問題ではありますが。 そもそも、そんなにクーペスタイルがいいという人は多いんでしょうか？ 見た目のために使い勝手を犠牲にしているように感じるのですが、その見た目自体も、僕にはあまり魅力的に映っていません。 普通のドアハンドルでよかったのになあ、と思ってしまいます。 ■意外と気になる操作系 ウィンカーは、いわゆる「ダイハツウィンカー」から脱出できてよかったです。 GR86の操作には慣れていましたが、やはり普通の感覚で操作できる方が好みです。 ヴェゼルにはワンタッチで3回点滅する機能があります。 僕の場合、軽く倒す領域でレバーを保持し、必要な時間だけウィンカーを出す使い方をしています。 ヴェゼルでも同じことができたので、これはよかったです。 一方、ナビの操作性には不満があります。 まず、音声認識。 これはストレスが大きいです。 思ったように操作できません。 そしてホームボタン。 画面内の操作はタッチなのに、ホームへ戻るときは物理ボタンを押す必要があります。 操作方法が混在しているので、なんとなく違和感があるんですよね。 メーターのインフォメーションディスプレイにも不満があります。 表示できる情報が基本的に一つずつ。 もう少しいろいろな情報を同時に見せてほしいところです。 近接センサーも気になります。 一時的にOFFにしたとき、その状態が維持されてしまう。 狭いところなどで警告を一時的に止めたいだけなのに、あとから戻し忘れる可能性があります。 できれば自動的に復帰してほしいです。 それからバイザークリップ。 駐車券のような紙なら片手で挟めます。 でも、薄いレシートのような紙は片手ではうまく挟めません。 両手を使えば挟めるのですが、僕は次回の給油割引券をここに置いておきたいんです。 地味ですが、意外と気になるところです。 ■パワーテールゲートは便利……なのかな？ 自宅の駐車場で、パワーテールゲートを全開にしてみました。 心配していた天井との干渉はありませんでした。 これは助かりました。 ただ、使ってみて思ったことが一つ。 自分で開けた方が早くない？ もちろん、荷物を持っているときなど、電動で開閉できるメリットはあります。 便利な機能なのは分かるんですが、毎回使うかどうかはまだ分かりません。 一方、スマートキーによるパワーウィンドウ操作には助けられました。 自宅の駐車場は非常に狭く、降りるだけでも一苦労です。 やっと車から降りてドアを閉めたところで、窓を閉め忘れたことに気づきました。 もう一度乗り込むのは大変です。 そこで、車外からパワーウィンドウを操作できないか試してみました。 電源OFFでは動きません。 ACCにしても動きません。 電源ONにもなったと思うのですが、エンジンが動いていないので、パワーウィンドウも操作できないだろうと判断して試しませんでした。 ブレーキペダルを踏めないので、走行可能状態にもできません。 せっかく苦労して降りたのに……。 と絶望しかけたところで、スマートキーで窓を閉められることを思い出しました。 セーフ！ ところが、後から調べてみると、実はエンジンが動いていなくても、電源ONならパワーウィンドウを操作できるんですね。 さらに、電源OFF後も約10分間は操作できるものの、運転席ドアを開閉すると操作できなくなるという仕様も分かりました。 そういえばGR86でも、エンジンを始動せずにONモードにできたような……。 エンジンが動いていなくても窓を操作できることは分かっていたのですが、メーカーがバッテリー保護などのために、エンジン始動中だけに制限しているのだろうと思い込んでいたんです。 それにしても、窓の開け閉めくらい、電源OFFのままできてもいいのでは？ という疑問は残ります。 このあたりはメーカーによっても仕様が違うようなので、別の記事で調べてみたいと思います。 それから、ドアミラーにも助けられました。 手動で格納した場合、次に乗るときに勝手に開かないんです。 自宅の駐車場ではミラーを畳んで入る必要があるので、これはありがたい仕様です。 こうしてみると、便利な装備があるかどうかだけでなく、自分の使い方に合っているかどうかが大切なんですね。 ■車高が高いことのメリットもあった GR86に乗っていた頃、エアロを擦りそうで入れなかったお店があります。 ヴェゼルなら、普通に入れるかもしれません。 これまで、店舗への出入り口や段差などで、かなり気を使っていました。 車高が高くなったことで、そういう心配が減りそうです。 先ほど、車体の左右の揺れや座面の高さが気になると書きましたが、車高の高さにはちゃんとメリットもあるんですね。 ■新車の匂いと、傷つきやすいキー もう一つ気になっているのが、新車特有の匂いです。 かなり強いです。 ホンダ車は接着剤の匂いが強い、という話も聞いたことがありますが、本当にメーカーによる違いがあるのかは分かりません。 とにかく今は、もう少し匂いが落ち着いてほしいところです。 そしてスマートキー。 デザインは綺麗です。 ただ、いきなり傷が入ってしまいました。 せっかく綺麗なキーなのに、傷つきやすいのは残念。 もう少し傷が目立ちにくい素材でもよかったのでは、と思ってしまいます。 プライバシーフィルムについても思案中です。 もともとのリアガラスにも多少の色が付いています。 さらに濃いフィルムを貼ろうかと思っていましたが、今は普通のルームミラーでも後方が見やすいんですよね。 GR86では濃いフィルムで後方が見づらくなっていたこともあり、今回はこのままにするかもしれません。 ■納車後のDIYも開始 もちろん、乗っているだけではありません。 納車後、さっそくいくつか作業をしました。 まず、ペダルカバーの取り付け。 アクセル側はともかく、ブレーキペダル側がなかなか取り付けられず、四苦八苦しました。 コツが分かれば違うのでしょうが、これが意外と大変。 続いて、ウィンドウスイッチパネルにピアノブラックのカバーを取り付けました。 そして、ピアノブラック部分には「スマホまもる君」を施工。 センターコンソール ナビ ステアリングのコントローラー部分 スマートキー それぞれ4回施工しました。 施工量や拭き取り方を試行錯誤しながらの作業です。 スマートキーの傷も少し目立ちにくくなりましたが、消えたわけではありません。 それからスカッフプレート。 なかなか届かないなあと思っていたら……。 注文したつもりで、注文していませんでした。 これは完全に自分のミスです（笑）。 ■そういえば、所有者も使用者も自分だった 納車後、車検証の登録情報を確認して、意外なことに気づきました。 所有者も使用者も、両方とも自分の名前だったんです。 今回は残価設定型の支払いプランを利用しています。 てっきり、所有者は販売店か信販会社になるものだと思っていました。 ところが、どちらも自分名義。 担当者に聞いてみたところ、「2回払いだから」との説明でした。 所有権解除の手続きも必要ないとのこと。 これはちょっと驚きました。 ただし、同じような支払い方法なら必ず本人名義になるのか、そこまでは確認できていません。 一般的な残価設定型クレジットでは、販売店や信販会社が所有者になるケースもあります。 今回は、あくまで自分の契約での話です。 ちなみに、所有者名義が自分だからといって、支払い義務がなくなるわけではありません。 それでも、将来の所有権解除手続きが必要ないというのは、ちょっと得した気分です。 ■まとめ。まだ慣れていない今だからこその感想 ここまで書き出してみると、不満がずいぶん多いように見えますね。 でも、ヴェゼルに乗り換えて失敗したと思っているわけではありません。 一般道ではパワーも十分。 静かで、運転支援も充実しています。 心配していた天井の低さや助手席の足元も、実際には問題ありませんでした。 一方、荷室の狭さや細かな操作系など、乗る前にはそれほど意識していなかったところで不満が出ています。 そして、GR86との違い。 エアークラッチを踏んでしまったり、ハイオクを選んでしまったり。 左右の揺れに違和感があったり、駐車場で少し大回りに感じたり。 こういう感覚は、もう少し乗れば当たり前になってしまうのでしょう。 だからこそ、225.5km走った今の印象を残しておきたかったんです。 まだ高速道路での走りや長距離燃費も十分には試せていません。 ACCや減速セレクターなど、使い込めば印象が変わる装備もありそうです。 今はまだ、ヴェゼルに自分を合わせている途中。 次に1,000km走ったとき、今回の不満がどれだけ残っているのか。 それも楽しみにしたいと思います。
arisan2026's tweet photo. 【くるま】ヴェゼル納車2日、225.5km走って分かったこと。GR86との違いが想像以上に面白い GR86からホンダ・ヴェゼル e:HEV Zに乗り換えました。 納車から2日。走行距離は225.5kmになりました。 前回の記事では、GR86から乗り換えることで「失われるもの」を書きました。 今度は、実際にヴェゼルに乗ってみてどうだったのか。 良かったこと、不満に思ったこと、予想と違ったこと。 忘れないうちに、思いつくまま書き出してみます。 というのも、すでに慣れ始めているんですよね。 納車直後の違和感は、意外と早く消えてしまうのかもしれません。 ■まず、GR86の癖が抜けない 最初にやってしまったのが、エアークラッチ。 信号待ちなどで、無意識に左足がクラッチを踏もうとします。 当然、そこにクラッチペダルはありません。 長年の習慣というのは恐ろしいものです。 そして給油でも。 いつものようにハイオクを選択してしまう。 ヴェゼルはレギュラー仕様なのに、体が覚えているんですよね。 でも、レギュラーって安い！ これは素直にうれしい。 燃費は現在、およそ21km/L。 エコランを楽しみたいところですが、自宅が坂の上なので、最後の登りで燃費が悪化するのが悩ましいところです。 ■走りはどうなのか？ まず、パワーについて。 一般道を走る分には、まったく問題ありません。 GR86からの乗り換えなので、もっと不満が出るかと思っていましたが、日常的な速度域では十分です。 パワーモードも試してみました。 アクセルへの反応がよくなり、スイスイ走る印象です。 ただし、慣れないとギクシャクするかもしれません。 個人的には、結構いいかも。 減速セレクターについては、まだお試し中です。 ステアリングも、GR86から乗り換えたことで大きな違和感が出るかと思いましたが、特にありませんでした。 一方、車体の揺れは気になりました。 GR86は路面の凹凸をよく拾います。でも、その後の揺れは長く残りません。 ヴェゼルは、最初に左右の揺れを感じました。 やはり重心が高いからでしょうか。サスペンションの特性も違うのでしょう。 ただ、これもすでに慣れ始めています。 乗り心地が悪いというより、車体の動き方が違うんですね。 静粛性は確かに高いです。 ただし、静かな分だけロードノイズが気になるようになりました。 それから、小回り。 スーパーなどの駐車場でバック駐車をすると、GR86より少し大回りする印象です。 いつもの感覚でハンドルを切ると「あれ？」となる。 数字では小さな違いでも、実際の運転では分かるものですね。 ■運転支援は便利。でも、自分の好みとは少し違う 今回ヴェゼルを選んだ理由の一つが、運転支援機能です。 ACCやLKASには期待していました。 実際、便利です。 ただ、いくつか気になるところがありました。 まずACC。 ブレーキをかけ始めるタイミングが、自分の好みより遅いんです。 もう少し早い段階から穏やかに減速してほしい。 自分でブレーキを踏んだ方がジェントルに止まれます。 もちろん、車間距離や交通状況などによって動作は変わりますが、今のところそういう印象です。 次にLKAS。 まっすぐ走っていると、「ハンドルを操作してください」と警告されます。 いや、ちゃんと運転しているんですけど……。 直進しているからこそ、ハンドルを大きく操作する必要がないわけで。 これも少しストレスです。 そしてハイビーム。 ハイビームの表示が出ていると、前の車をちゃんと避けて照らしてくれているんだよね？ と不安になります。 単に表示が目障りなのではありません。 実際にどこを照らしているのかが分からないのが気になるんです。 せっかくなら、ブレーキ状態などを確認する表示画面で、ライトの照射状態も確認できたらいいのに。 オートブレーキホールドも、解除される瞬間に少し違和感があります。 ただ、便利なのは間違いないので、これは使い続けるかもしれません。 自動で運転を支援してくれるのはありがたい。 でも、自分の運転感覚と完全に一致するわけではないんですね。 ■オートワイパーも以心伝心とはいかない オートワイパーも試してみました。 こちらも微妙。 自分が動いてほしいタイミングと、実際に動くタイミングが必ずしも一致しません。 以心伝心とはいかないものですね。 それから、フロントワイパーが動いているなら、リアワイパーも状況に応じて連動してほしいところです。 便利な自動化ほど、自分の感覚との違いが気になるのかもしれません。 ■室内は予想より快適。でも収納は…… ヴェゼルを購入する前、いくつか心配していたことがありました。 その一つが天井の低さ。 SUVとしては低めのスタイルなので気になっていましたが、実際に乗ると特に問題ありませんでした。 助手席の足元も同様です。 センタータンクレイアウトの影響で、足元の形状が気になるかなと思っていましたが、特に違和感はありません。 運転席からの視界も、ものすごく広いわけではありませんが、不満はありません。 GR86と同じように水平基調のインパネで、ドアミラーの取り付け方なども似ているため、馴染みやすいのかもしれません。 一方、運転席の座面は、少し自分に合わない印象があります。 何が合わないのか、まだよく分かりません。 それから降りるとき。 GR86では低い座席から立ち上がる必要がありましたが、ヴェゼルでは逆に、地面に向かって足を伸ばす感じです。 座面が少し高いのかもしれません。 乗り降りのしやすさを重視して選んだ車ですが、低ければ困るし、高くても少し困る。 なかなか難しいものです。 そして収納。 グローブボックスは狭いです。 さらに驚いたのが荷室。 GR86のトランクに入っていた荷物が、ヴェゼルには全部入りませんでした。 もちろん、トノカバーより上まで積み上げれば入ります。 でも、荷物を隠して積むことを前提にすると、思ったほど収納できないんです。 SUVだから積載量が増えると思っていたわけではありませんが、これは少し意外でした。 ■後席は同乗者にも感想を聞いてみた 後席については、先輩にも感想を聞いてみました。 まず、前席の下に足を入れづらいとのこと。 僕自身は特に気にならなかったのですが、人によって感じ方が違うようです。 また、後席に乗り降りするとき、頭を屈める必要があるとのこと。 座ってしまえば問題がなくても、乗り降りの際には天井の高さが影響するんですね。 それから後席中央のアームレスト。 下に垂れ下がるという話を聞いていましたが、実際に確認してみると、それほど気になりませんでした。 ちなみに、後席のドリンクホルダーには1Lのペットボトルが入りませんでした。 まあ、そもそも1Lサイズを入れようとする方が想定外なのかもしれませんが（笑）。 もう一つ、後席ドアのハンドル。 これは僕自身も嫌いなのですが、同乗者からも総じて不評でした。 同乗者の意見は、「ハンドルが見つけづらい」「使いづらい」というもの。 僕も荷物を持っているときには開けづらいと感じています。 ヴェゼルは後席ドアのハンドルを窓の横に隠すことで、クーペのようなスタイルを演出しています。 でも、個人的には普通の位置にドアハンドルが付いている方が、かっこいいんじゃないかと思うんですよね。 もちろん、好みの問題ではありますが。 そもそも、そんなにクーペスタイルがいいという人は多いんでしょうか？ 見た目のために使い勝手を犠牲にしているように感じるのですが、その見た目自体も、僕にはあまり魅力的に映っていません。 普通のドアハンドルでよかったのになあ、と思ってしまいます。 ■意外と気になる操作系 ウィンカーは、いわゆる「ダイハツウィンカー」から脱出できてよかったです。 GR86の操作には慣れていましたが、やはり普通の感覚で操作できる方が好みです。 ヴェゼルにはワンタッチで3回点滅する機能があります。 僕の場合、軽く倒す領域でレバーを保持し、必要な時間だけウィンカーを出す使い方をしています。 ヴェゼルでも同じことができたので、これはよかったです。 一方、ナビの操作性には不満があります。 まず、音声認識。 これはストレスが大きいです。 思ったように操作できません。 そしてホームボタン。 画面内の操作はタッチなのに、ホームへ戻るときは物理ボタンを押す必要があります。 操作方法が混在しているので、なんとなく違和感があるんですよね。 メーターのインフォメーションディスプレイにも不満があります。 表示できる情報が基本的に一つずつ。 もう少しいろいろな情報を同時に見せてほしいところです。 近接センサーも気になります。 一時的にOFFにしたとき、その状態が維持されてしまう。 狭いところなどで警告を一時的に止めたいだけなのに、あとから戻し忘れる可能性があります。 できれば自動的に復帰してほしいです。 それからバイザークリップ。 駐車券のような紙なら片手で挟めます。 でも、薄いレシートのような紙は片手ではうまく挟めません。 両手を使えば挟めるのですが、僕は次回の給油割引券をここに置いておきたいんです。 地味ですが、意外と気になるところです。 ■パワーテールゲートは便利……なのかな？ 自宅の駐車場で、パワーテールゲートを全開にしてみました。 心配していた天井との干渉はありませんでした。 これは助かりました。 ただ、使ってみて思ったことが一つ。 自分で開けた方が早くない？ もちろん、荷物を持っているときなど、電動で開閉できるメリットはあります。 便利な機能なのは分かるんですが、毎回使うかどうかはまだ分かりません。 一方、スマートキーによるパワーウィンドウ操作には助けられました。 自宅の駐車場は非常に狭く、降りるだけでも一苦労です。 やっと車から降りてドアを閉めたところで、窓を閉め忘れたことに気づきました。 もう一度乗り込むのは大変です。 そこで、車外からパワーウィンドウを操作できないか試してみました。 電源OFFでは動きません。 ACCにしても動きません。 電源ONにもなったと思うのですが、エンジンが動いていないので、パワーウィンドウも操作できないだろうと判断して試しませんでした。 ブレーキペダルを踏めないので、走行可能状態にもできません。 せっかく苦労して降りたのに……。 と絶望しかけたところで、スマートキーで窓を閉められることを思い出しました。 セーフ！ ところが、後から調べてみると、実はエンジンが動いていなくても、電源ONならパワーウィンドウを操作できるんですね。 さらに、電源OFF後も約10分間は操作できるものの、運転席ドアを開閉すると操作できなくなるという仕様も分かりました。 そういえばGR86でも、エンジンを始動せずにONモードにできたような……。 エンジンが動いていなくても窓を操作できることは分かっていたのですが、メーカーがバッテリー保護などのために、エンジン始動中だけに制限しているのだろうと思い込んでいたんです。 それにしても、窓の開け閉めくらい、電源OFFのままできてもいいのでは？ という疑問は残ります。 このあたりはメーカーによっても仕様が違うようなので、別の記事で調べてみたいと思います。 それから、ドアミラーにも助けられました。 手動で格納した場合、次に乗るときに勝手に開かないんです。 自宅の駐車場ではミラーを畳んで入る必要があるので、これはありがたい仕様です。 こうしてみると、便利な装備があるかどうかだけでなく、自分の使い方に合っているかどうかが大切なんですね。 ■車高が高いことのメリットもあった GR86に乗っていた頃、エアロを擦りそうで入れなかったお店があります。 ヴェゼルなら、普通に入れるかもしれません。 これまで、店舗への出入り口や段差などで、かなり気を使っていました。 車高が高くなったことで、そういう心配が減りそうです。 先ほど、車体の左右の揺れや座面の高さが気になると書きましたが、車高の高さにはちゃんとメリットもあるんですね。 ■新車の匂いと、傷つきやすいキー もう一つ気になっているのが、新車特有の匂いです。 かなり強いです。 ホンダ車は接着剤の匂いが強い、という話も聞いたことがありますが、本当にメーカーによる違いがあるのかは分かりません。 とにかく今は、もう少し匂いが落ち着いてほしいところです。 そしてスマートキー。 デザインは綺麗です。 ただ、いきなり傷が入ってしまいました。 せっかく綺麗なキーなのに、傷つきやすいのは残念。 もう少し傷が目立ちにくい素材でもよかったのでは、と思ってしまいます。 プライバシーフィルムについても思案中です。 もともとのリアガラスにも多少の色が付いています。 さらに濃いフィルムを貼ろうかと思っていましたが、今は普通のルームミラーでも後方が見やすいんですよね。 GR86では濃いフィルムで後方が見づらくなっていたこともあり、今回はこのままにするかもしれません。 ■納車後のDIYも開始 もちろん、乗っているだけではありません。 納車後、さっそくいくつか作業をしました。 まず、ペダルカバーの取り付け。 アクセル側はともかく、ブレーキペダル側がなかなか取り付けられず、四苦八苦しました。 コツが分かれば違うのでしょうが、これが意外と大変。 続いて、ウィンドウスイッチパネルにピアノブラックのカバーを取り付けました。 そして、ピアノブラック部分には「スマホまもる君」を施工。 センターコンソール ナビ ステアリングのコントローラー部分 スマートキー それぞれ4回施工しました。 施工量や拭き取り方を試行錯誤しながらの作業です。 スマートキーの傷も少し目立ちにくくなりましたが、消えたわけではありません。 それからスカッフプレート。 なかなか届かないなあと思っていたら……。 注文したつもりで、注文していませんでした。 これは完全に自分のミスです（笑）。 ■そういえば、所有者も使用者も自分だった 納車後、車検証の登録情報を確認して、意外なことに気づきました。 所有者も使用者も、両方とも自分の名前だったんです。 今回は残価設定型の支払いプランを利用しています。 てっきり、所有者は販売店か信販会社になるものだと思っていました。 ところが、どちらも自分名義。 担当者に聞いてみたところ、「2回払いだから」との説明でした。 所有権解除の手続きも必要ないとのこと。 これはちょっと驚きました。 ただし、同じような支払い方法なら必ず本人名義になるのか、そこまでは確認できていません。 一般的な残価設定型クレジットでは、販売店や信販会社が所有者になるケースもあります。 今回は、あくまで自分の契約での話です。 ちなみに、所有者名義が自分だからといって、支払い義務がなくなるわけではありません。 それでも、将来の所有権解除手続きが必要ないというのは、ちょっと得した気分です。 ■まとめ。まだ慣れていない今だからこその感想 ここまで書き出してみると、不満がずいぶん多いように見えますね。 でも、ヴェゼルに乗り換えて失敗したと思っているわけではありません。 一般道ではパワーも十分。 静かで、運転支援も充実しています。 心配していた天井の低さや助手席の足元も、実際には問題ありませんでした。 一方、荷室の狭さや細かな操作系など、乗る前にはそれほど意識していなかったところで不満が出ています。 そして、GR86との違い。 エアークラッチを踏んでしまったり、ハイオクを選んでしまったり。 左右の揺れに違和感があったり、駐車場で少し大回りに感じたり。 こういう感覚は、もう少し乗れば当たり前になってしまうのでしょう。 だからこそ、225.5km走った今の印象を残しておきたかったんです。 まだ高速道路での走りや長距離燃費も十分には試せていません。 ACCや減速セレクターなど、使い込めば印象が変わる装備もありそうです。 今はまだ、ヴェゼルに自分を合わせている途中。 次に1,000km走ったとき、今回の不満がどれだけ残っているのか。 それも楽しみにしたいと思います。
0
1
0
0
2K
arisan2026's profile image
アリさん Verified account @arisan2026
【くるま】GR86からヴェゼルへ。失われるものを数えてみたら、ちょっと寂しくなった【教えてAI先生】 もうすぐGR86とお別れです。 次の車はホンダのヴェゼル e:HEV Z。 スポーツカーからSUVへの乗り換えなので、生活はずいぶん変わりそうです。 乗り降りは楽になるし、燃費も良くなる。静かで快適になって、運転支援も充実する。 いいことばかりのはずなんですが……。 ふと、GR86からヴェゼルに乗り換えることで、何が失われるんだろうと考え始めました。 すると、出てくる、出てくる。 しかも、失われるものには、不便だったことも結構あるんですよね。 でも、それも含めてGR86だったんです。 ■車止めを気にしなくなる 前向き駐車をするとき、GR86では車止めの少し手前で止めます。 フロントのエアロを擦りたくないからです。 何も考えずに車止めまで進むなんて、怖くてできません。 ヴェゼルなら最低地上高に余裕がありますから、そこまで神経質になる必要はなさそうです。 もちろん、どんな車止めでも大丈夫というわけではありませんが。 でも、あの慎重に停止位置を決める習慣。 なくなってしまうんですね。 ■後続車のヘッドライトが眩しくなくなる GR86は着座位置が低い。 これがスポーツカーの魅力でもあるんですが、夜は困ることがあります。 後続車のヘッドライトが眩しいんです。 特にSUVやミニバンが後ろにつくと、なかなか強烈。 ヴェゼルでは着座位置が高くなるので、かなり改善するんじゃないかと期待しています。 電子ミラーも取り付ける予定です。 眩しくなくなるのはうれしい。 でも、あの低い視点から道路を眺める感覚も、一緒に失われるんですよね。 ■乗り降りが楽になる GR86の乗り降りは、決して楽ではありません。 着座位置が低いので、乗り込むときも降りるときも、ちょっとしたコツが必要です。 実はGR86には、乗り降りの際に手をつくための場所が用意されています。 シートとドアの間にある、ソフトパッドになった部分です。 そこに手をついて身体を支えながら、乗り降りします。 これがもう、当たり前の動作になっています。 ヴェゼルなら、もっと自然な姿勢で乗り降りできるはずです。 手をついて身体を支える必要もなくなるかもしれません。 でも、あの場所に手をついて乗り降りする動作も、GR86ならではの習慣だったんですよね。 そんな小さな習慣も、もうすぐなくなります。 ■左足の仕事がなくなる GR86はマニュアル車です。 発進するときも、シフトチェンジするときも、左足が働きます。 ヴェゼルでは、その仕事がなくなります。 左足は基本的にフットレストの上。 渋滞では圧倒的に楽になるでしょう。 でも、クラッチを踏んで、ギアを選んで、つないでいく。 その一連の操作がなくなってしまいます。 車を動かすために自分が何かをしている、という感覚。 あれが好きだったんですよね。 ■エンジンブレーキの感覚が変わる GR86では、減速するときにシフトダウンできます。 エンジン回転数を合わせながらギアを落とし、エンジンブレーキを使う。 減速することも、運転の楽しみの一つでした。 ヴェゼルにも減速セレクターがあります。 回生ブレーキの強さを調整できるので、これはこれで楽しそうです。 ただ、ギアを選んでエンジン回転数を合わせる感覚とは違います。 同じ減速でも、そこに至る操作が変わる。 運転って、結果だけじゃないんですよね。 ■自然なハンドリング GR86のステアリングは、操作に対して車が素直に反応してくれる感覚が好きでした。 ヴェゼルにはVGR、可変ステアリングギアレシオが採用されています。 ハンドルを切る量によって、タイヤの向きが変わる割合を変化させる仕組みです。 便利な技術ですし、必ずしも不自然になるわけではありません。 ただ、GR86とは車の性格も重心の高さも違います。 あの感覚がどう変わるのか。 試乗だけでは、まだ判断できません。 ■アクセルを踏んだ分だけ加速する感覚 私のGR86は、ECUのセッティングを変更しています。 アクセル操作に対する反応も、自分の好みに近づけてもらいました。 踏んだ分だけ、期待したように加速する。 これが気持ちいいんです。 ヴェゼルのe:HEVはモーター駆動が中心なので、反応そのものは速いはずです。 でも、反応が速いことと、操作に対してリニアであることは別。 この違いは、乗り換えてから気になるかもしれません。 ■高速道路での加速の余裕 GR86は2.4Lの自然吸気エンジンで235PS。 高速道路でも、アクセルを踏めばまだまだ加速する余裕があります。 ヴェゼルは、そこまでの余裕はなさそうです。 もちろん、120km/h制限の高速道路を普通に巡航することは問題ないでしょう。 気になるのは、100km/hあたりからの加速。 追い越しなどで、もう少し加速したいと思ったときです。 速く走りたいという話ではありません。 必要なときに加速できる余裕があること。 その余裕が、運転中の安心感や選択肢につながっていたんだと思います。 ■エアコンの操作パネル これは意外なところかもしれません。 GR86のエアコン、結構好きなんです。 左右の温度調整ダイヤルの中にデジタル表示が組み込まれていて、中央のダイヤルにも表示があります。 下には航空機のスイッチを思わせる操作部。 赤い照明もいい雰囲気です。 機能としては、ヴェゼルも左右独立温度調整ができます。 でも、GR86のエアコンには、操作する楽しさがあるんですよね。 運転席に座って目に入るもの、手で触れるもの。 そういうところにも、スポーツカーらしさがありました。 ■そして、ハイオクともお別れ 先日、GR86に最後の給油をしてきました。 いつものガソリンスタンド。 いつものように給油して、いつものようにハイオクを選ぶ。 何も特別なことはしていません。 でも、これが最後なんですよね。 ヴェゼルはレギュラーガソリンです。 燃費もずっと良くなるので、ガソリン代はかなり安くなるはず。 それはうれしいことです。 ただ、次に給油するときは、いろいろ間違えそうです。 まず、給油口の左右が逆。 いつもの癖で、反対側に停めてしまいそう。 そして、給油口を開けようとして、 「あれ？ 開かない」 GR86はフタを押して開ける方式ですが、ヴェゼルは車内のレバーで開けます。 ようやく給油口を開けたと思ったら、今度はハイオクのノズルに手が伸びそう。 たった一度の給油で、三つも習慣を変えなければならないんですね。 そのうち、ヴェゼルの給油が当たり前になるんでしょう。 ■最後のひと走りで思ったこと 先日、最後のひと走りのつもりで鎌倉山へ行ってきました。 GR86は売却に向けて、いろいろな部品を純正に戻しています。 スポーツ触媒も純正に戻しました。 そのせいか、3,000〜4,000回転あたりの力強さが、以前より気持ちよく感じられたんです。 おそらくECUのセッティングとの組み合わせもあるのでしょう。 軽く峠道を走るには、ちょうどいい。 「ああ、やっぱり楽しいな」 最後の最後に、そんなことを思ってしまいました。 もうすぐ手放すというのに。 ■不便さも含めて、GR86だった こうして並べてみると、失われるものには二種類ありそうです。 クラッチ操作やハンドリングのように、明らかに惜しいもの。 そして、乗り降りのしづらさや車止めへの気遣いのように、なくなれば便利になるもの。 でも、私にとってはどちらもGR86の一部でした。 不便さも含めて、この車のアイデンティティだったんです。 ヴェゼルに乗り換えることを後悔しているわけではありません。 むしろ、納車を楽しみにしています。 静粛性、快適性、燃費、運転支援。 GR86では得られなかったものが、たくさんあります。 でも、新しい車で便利になるということは、古い車で当たり前だった何かが消えていくということでもあるんですね。 いつかヴェゼルにも、ヴェゼルならではの習慣ができるのでしょう。 そして、それが当たり前になっていく。 昨日まで当たり前だったGR86との日常も、少しずつ思い出になっていくんだと思います。 最後に給油したハイオク。 あれが、GR86と過ごした日常の最後の一つだったのかもしれません。
arisan2026's tweet photo. 【くるま】GR86からヴェゼルへ。失われるものを数えてみたら、ちょっと寂しくなった【教えてAI先生】 もうすぐGR86とお別れです。 次の車はホンダのヴェゼル e:HEV Z。 スポーツカーからSUVへの乗り換えなので、生活はずいぶん変わりそうです。 乗り降りは楽になるし、燃費も良くなる。静かで快適になって、運転支援も充実する。 いいことばかりのはずなんですが……。 ふと、GR86からヴェゼルに乗り換えることで、何が失われるんだろうと考え始めました。 すると、出てくる、出てくる。 しかも、失われるものには、不便だったことも結構あるんですよね。 でも、それも含めてGR86だったんです。 ■車止めを気にしなくなる 前向き駐車をするとき、GR86では車止めの少し手前で止めます。 フロントのエアロを擦りたくないからです。 何も考えずに車止めまで進むなんて、怖くてできません。 ヴェゼルなら最低地上高に余裕がありますから、そこまで神経質になる必要はなさそうです。 もちろん、どんな車止めでも大丈夫というわけではありませんが。 でも、あの慎重に停止位置を決める習慣。 なくなってしまうんですね。 ■後続車のヘッドライトが眩しくなくなる GR86は着座位置が低い。 これがスポーツカーの魅力でもあるんですが、夜は困ることがあります。 後続車のヘッドライトが眩しいんです。 特にSUVやミニバンが後ろにつくと、なかなか強烈。 ヴェゼルでは着座位置が高くなるので、かなり改善するんじゃないかと期待しています。 電子ミラーも取り付ける予定です。 眩しくなくなるのはうれしい。 でも、あの低い視点から道路を眺める感覚も、一緒に失われるんですよね。 ■乗り降りが楽になる GR86の乗り降りは、決して楽ではありません。 着座位置が低いので、乗り込むときも降りるときも、ちょっとしたコツが必要です。 実はGR86には、乗り降りの際に手をつくための場所が用意されています。 シートとドアの間にある、ソフトパッドになった部分です。 そこに手をついて身体を支えながら、乗り降りします。 これがもう、当たり前の動作になっています。 ヴェゼルなら、もっと自然な姿勢で乗り降りできるはずです。 手をついて身体を支える必要もなくなるかもしれません。 でも、あの場所に手をついて乗り降りする動作も、GR86ならではの習慣だったんですよね。 そんな小さな習慣も、もうすぐなくなります。 ■左足の仕事がなくなる GR86はマニュアル車です。 発進するときも、シフトチェンジするときも、左足が働きます。 ヴェゼルでは、その仕事がなくなります。 左足は基本的にフットレストの上。 渋滞では圧倒的に楽になるでしょう。 でも、クラッチを踏んで、ギアを選んで、つないでいく。 その一連の操作がなくなってしまいます。 車を動かすために自分が何かをしている、という感覚。 あれが好きだったんですよね。 ■エンジンブレーキの感覚が変わる GR86では、減速するときにシフトダウンできます。 エンジン回転数を合わせながらギアを落とし、エンジンブレーキを使う。 減速することも、運転の楽しみの一つでした。 ヴェゼルにも減速セレクターがあります。 回生ブレーキの強さを調整できるので、これはこれで楽しそうです。 ただ、ギアを選んでエンジン回転数を合わせる感覚とは違います。 同じ減速でも、そこに至る操作が変わる。 運転って、結果だけじゃないんですよね。 ■自然なハンドリング GR86のステアリングは、操作に対して車が素直に反応してくれる感覚が好きでした。 ヴェゼルにはVGR、可変ステアリングギアレシオが採用されています。 ハンドルを切る量によって、タイヤの向きが変わる割合を変化させる仕組みです。 便利な技術ですし、必ずしも不自然になるわけではありません。 ただ、GR86とは車の性格も重心の高さも違います。 あの感覚がどう変わるのか。 試乗だけでは、まだ判断できません。 ■アクセルを踏んだ分だけ加速する感覚 私のGR86は、ECUのセッティングを変更しています。 アクセル操作に対する反応も、自分の好みに近づけてもらいました。 踏んだ分だけ、期待したように加速する。 これが気持ちいいんです。 ヴェゼルのe:HEVはモーター駆動が中心なので、反応そのものは速いはずです。 でも、反応が速いことと、操作に対してリニアであることは別。 この違いは、乗り換えてから気になるかもしれません。 ■高速道路での加速の余裕 GR86は2.4Lの自然吸気エンジンで235PS。 高速道路でも、アクセルを踏めばまだまだ加速する余裕があります。 ヴェゼルは、そこまでの余裕はなさそうです。 もちろん、120km/h制限の高速道路を普通に巡航することは問題ないでしょう。 気になるのは、100km/hあたりからの加速。 追い越しなどで、もう少し加速したいと思ったときです。 速く走りたいという話ではありません。 必要なときに加速できる余裕があること。 その余裕が、運転中の安心感や選択肢につながっていたんだと思います。 ■エアコンの操作パネル これは意外なところかもしれません。 GR86のエアコン、結構好きなんです。 左右の温度調整ダイヤルの中にデジタル表示が組み込まれていて、中央のダイヤルにも表示があります。 下には航空機のスイッチを思わせる操作部。 赤い照明もいい雰囲気です。 機能としては、ヴェゼルも左右独立温度調整ができます。 でも、GR86のエアコンには、操作する楽しさがあるんですよね。 運転席に座って目に入るもの、手で触れるもの。 そういうところにも、スポーツカーらしさがありました。 ■そして、ハイオクともお別れ 先日、GR86に最後の給油をしてきました。 いつものガソリンスタンド。 いつものように給油して、いつものようにハイオクを選ぶ。 何も特別なことはしていません。 でも、これが最後なんですよね。 ヴェゼルはレギュラーガソリンです。 燃費もずっと良くなるので、ガソリン代はかなり安くなるはず。 それはうれしいことです。 ただ、次に給油するときは、いろいろ間違えそうです。 まず、給油口の左右が逆。 いつもの癖で、反対側に停めてしまいそう。 そして、給油口を開けようとして、 「あれ？ 開かない」 GR86はフタを押して開ける方式ですが、ヴェゼルは車内のレバーで開けます。 ようやく給油口を開けたと思ったら、今度はハイオクのノズルに手が伸びそう。 たった一度の給油で、三つも習慣を変えなければならないんですね。 そのうち、ヴェゼルの給油が当たり前になるんでしょう。 ■最後のひと走りで思ったこと 先日、最後のひと走りのつもりで鎌倉山へ行ってきました。 GR86は売却に向けて、いろいろな部品を純正に戻しています。 スポーツ触媒も純正に戻しました。 そのせいか、3,000〜4,000回転あたりの力強さが、以前より気持ちよく感じられたんです。 おそらくECUのセッティングとの組み合わせもあるのでしょう。 軽く峠道を走るには、ちょうどいい。 「ああ、やっぱり楽しいな」 最後の最後に、そんなことを思ってしまいました。 もうすぐ手放すというのに。 ■不便さも含めて、GR86だった こうして並べてみると、失われるものには二種類ありそうです。 クラッチ操作やハンドリングのように、明らかに惜しいもの。 そして、乗り降りのしづらさや車止めへの気遣いのように、なくなれば便利になるもの。 でも、私にとってはどちらもGR86の一部でした。 不便さも含めて、この車のアイデンティティだったんです。 ヴェゼルに乗り換えることを後悔しているわけではありません。 むしろ、納車を楽しみにしています。 静粛性、快適性、燃費、運転支援。 GR86では得られなかったものが、たくさんあります。 でも、新しい車で便利になるということは、古い車で当たり前だった何かが消えていくということでもあるんですね。 いつかヴェゼルにも、ヴェゼルならではの習慣ができるのでしょう。 そして、それが当たり前になっていく。 昨日まで当たり前だったGR86との日常も、少しずつ思い出になっていくんだと思います。 最後に給油したハイオク。 あれが、GR86と過ごした日常の最後の一つだったのかもしれません。
0
1
0
0
1K
arisan2026's profile image
アリさん Verified account @arisan2026
なるほど、実際に見落とした問題を、その都度チェック項目に追加しているんですね。 冒頭0.3秒の黒画面や最後の2秒の無音なんて、人間が見ても見逃しそうです。 こちらもGen38で音声の検査機能が増えましたが、実際に見つかった問題を次の検査に反映していく考え方は、とても参考になります。 機械で決めきれないものは「要確認」にして人に渡す、というところもいいですね。ありがとうございます！
1
1
0
0
13
arisan2026's profile image
アリさん Verified account @arisan2026
【AI駆動開発やってみた】AI開発環境 進化観察日記 Gen37｜YouTube品質を求めたら、AIが「PowerPointの枠」を捨てた 前回のGen36では、動画に大きな変化がありました。 それまでの動画は、 分かりやすいPowerPointを作って、それを順番に読み上げる という構造がかなり残っていました。 そこでGen36では、 「動画として説明するものにしてください」 というゴールを与えました。 するとAIは、 ・ナレーションに合わせて説明対象を順番に出す ・今説明している場所を浮かび上がらせる ・片輪が上がる動きをアニメーションにする ・ビームがねじれる様子を動かす といった仕組みを追加しました。 実際に動画を見てみると、これはかなり分かりやすい。 Gen35では、 何を描くか が変わりました。 Gen36では、 いつ、どこを見せるか まで扱い始めました。 では、次はどうするか。 今回はさらに、 「見続けやすいYouTube動画にしてください」 というゴールを与えてみました。 ■Gen36は分かりやすかった。でも、まだ「教材動画」だった Gen36を見たとき、 「伝える」という意味ではかなり進歩したと感じました。 特に、 片輪が上がったときの動き。 横ビームがねじれる様子。 説明対象だけが浮かび上がる演出。 このあたりは、静止した図を見るより圧倒的に理解しやすい。 ただ、全体を見ていると、 まだ教材動画っぽい。 という感覚も残っていました。 悪いわけではありません。 むしろ教材としてはかなり良くなっています。 でもYouTube動画として見ると、 画面全体がまだPowerPointっぽい。 章タイトルが出る。 本文が出る。 説明が終わる。 次のページへ行く。 この感じが残っています。 そこでGen37では、 「理解できる」だけでは完成にしない ことにしました。 ■今回も方法は指定しない 今回も、 「こういうエフェクトを入れてください」 とは指示していません。 たとえば、 ・縁取りを入れる ・ズームする ・カメラを動かす ・テロップを出す ・BGMを入れる ・章扉をこうする といった方法は指定していません。 与えたのは完成条件です。 初めて見る人が、約20分の動画を自然に見続けられるYouTube動画にしてください。 そして今回も、 現在の環境にある表現手段に合わせてゴールを縮めないでください。 と伝えました。 Gen35から続けている、 手段は自由。ゴールは明確に。 です。 ■AIが最初に見つけた問題は、「動きが少ない」ではなかった 今回面白かったのはここでした。 Gen36では、 画面変化はすでにかなり増えています。 Gen35では約40回だった画面変化が、 Gen36では293回。 同じ画面が止まる時間も大幅に短くなりました。 なので、もう単純に 「もっと動かせばいい」 という話ではありません。 Gen37のAIは、Gen36の全場面を調べて、別の問題を見つけました。 それは、 42枚すべてが、同じ「スライドの枠」の中に入っている ことでした。 白い背景。 見出し。 罫線。 資料名。 ページ番号。 どれだけ中身を工夫しても、 全部が「資料の1ページ」に見える。 AIは、 「教材動画に見える中心は、図ではなく、この枠なのではないか」 と判断しました。 これはちょっと意外でした。 ■絵がない画面が、動画の半分を占めていた さらにAIは、Gen36を調べて、 絵のない画面が42枚中25枚 あることも問題として挙げました。 時間にすると、 10分27秒。 動画全体の約半分です。 Gen36では、 構造や動きを説明する場所はかなり図解されました。 でも、 表。 文章。 引用。 章扉。 まとめ。 こういった部分は、まだ従来の資料表現のままでした。 特に最後の4分半は、 ほぼ絵がありませんでした。 これも、 「最後になるほどYouTube動画として地味になる」 原因だと判断したようです。 ■そこでAIは、「スライド」をやめ始めた Gen37で追加された大きな仕組みが、 全画面レイアウト でした。 一枚の図を、 見出しも、 資料名も、 ページ番号も置かずに、 画面いっぱいに表示します。 つまり、 PowerPointの1ページを動画にするのではなく、 動画の1場面を作る 方向へ変わりました。 これは、思っていたより大きな変化でした。 ■実際に見てみると、かなりYouTubeっぽくなった 完成した動画を見てみました。 最初に感じたのは、 話を知らない人でも、さらに分かりやすくなった ということです。 Gen36までも説明自体は分かりやすくなっていました。 でもGen37では、 「この話は何の話なのか」 「なぜこれを調べるのか」 「今どこまで来ているのか」 が、より自然に分かります。 そして、もう一つかなり大きく変わっていたのが、 話の順番 です。 ■本題へ行くのが早くなった Gen37では、 動画の冒頭で、 ヴェゼル4WDの諸元表に 「ド・ディオン式」 と書いてあることを見せます。 そのあと、 教科書的なド・ディオンの形。 ヴェゼル4WDの形。 この二つを早い段階で並べます。 そして、 「これ、どう見てもトーションビームっぽくない？」 という本題へ入ります。 かなり早い。 Gen36では、タイトルの疑問が絵として出てくるまで約50秒。 Gen37では、 38秒。 ただ、重要なのは12秒短くなったことではありません。 構成そのものが、 前提を全部説明してから本題へ行く ではなく、 先に疑問を見せて、その疑問を解くために必要な知識を取りに行く 形へ変わっています。 これはかなりYouTubeを意識した構成に見えました。 こちらから、 「冒頭にフックを入れてください」 とは言っていません。 でも、結果としてそうなっています。 ■動画自体も短くなった Gen36は、 20分26秒。 Gen37は、 18分19秒。 約2分短くなりました。 これも、 「短くしてください」 とは指示していません。 AIが、 ・見出しだけの画面 ・長い章扉 ・白紙に近い待ち時間 ・説明のためだけに存在していた画面 を整理した結果、 自然に短くなったようです。 なので今回の短縮は、 単に文章を削ったというより、 動画として不要な待ち時間を減らした 結果に近そうです。 ■「章扉」も変わった Gen36では、 章タイトルだけが出る画面がありました。 Gen37では、 6章のうち、 いまどこにいるのか が分かるようになっています。 上部には、 現在の章が常に表示されます。 これも細かい変更ですが、 18分の動画を見る側にとっては結構大きい。 「あとどれくらいあるんだろう」 「今何の話をしていたんだっけ」 が分かりやすくなります。 教材として正しいかどうかではなく、 視聴している人が迷わないようにする 方向へ進んでいます。 ■山場が、本当に山場っぽくなった 今回かなり良かったのが、 「あの横ビームは、ねじれるのか」 という場面です。 この動画で、本当に知りたいところです。 Gen36では、 内容としては重要でも、 画面としては他の場面とそこまで大きな差がありませんでした。 Gen37では、 暗い背景。 大きな問い。 ヴェゼルの構造図。 そして横ビームへ視線を寄せる。 という構成になっています。 つまり、 重要な話が、重要そうに見える。 これも動画ではかなり大事なんだなと感じました。 ■終わり方も変わった Gen36では、 最後の4分半がかなり文章中心でした。 Gen37では、 ・確認できたこと ・確認できなかったこと ・どちらとも言い切れない ・今回の調査がどこまで届いたのか ・本当に知りたかったのは名前ではない ・最初の諸元表へ戻る という流れになっています。 特に最後に、 最初の「ド・ディオン式」という一行へ戻る 構成になったのは、かなり動画らしい締め方でした。 最初と最後がつながっています。 ■サムネイルまで変わっていた 公開するときに気づいたのですが、 サムネイルまでかなり変わっていました。 Gen37のサムネイルは、 上に、 「ヴェゼル4WDのリアサス」 中央に大きく、 「ド・ディオン式」 右側に構造図。 そして下に赤い帯で、 「どう見てもトーションビーム？」 と入っています。 かなり普通のYouTubeサムネイルっぽい。 こちらから、 「サムネイルをこう変えてください」 とは指示していません。 つまり今回のAIは、 本編だけでなく、 動画を見る前の入口まで含めて「YouTube動画」として考えた ように見えます。 ■ただし、面白い副作用も出た Gen37では、 PowerPointの枠をかなり捨てました。 その結果、 pptxを人が開いて、普通のPowerPointとして編集することが難しくなりました。 AI自身も、これを未解決事項として報告しています。 Gen36までのPowerPointは、 人が開いて、 文字を直す。 位置を変える。 図を調整する。 といったことが比較的やりやすい状態でした。 Gen37では、 画面全体が1枚の絵として作られる場面が増えています。 なので、 動画としての完成度を上げる代わりに、PowerPointとしての編集性が落ちた。 これは面白い変化です。 ■これは退化なのか？ 最初は、 「編集できなくなったのは困るな」 と思いました。 でも、少し考えると、 そもそもこの環境では、 人が編集する中間成果物として、 シナリオMarkdown があります。 文章や構成を直したいなら、 そこで直せます。 PowerPointは、 もしかすると、 人が編集する資料ではなく、動画生成用のレンダリング結果 になっていくのかもしれません。 そう考えると、 「PowerPointの編集性を失った」 のではなく、 役割が変わった とも考えられます。 もちろん、まだどちらが正しいかは分かりません。 でも、 動画品質を強く求めた結果、 AIが従来の成果物の役割まで変え始めた。 これはかなり興味深いところです。 ■AIは今回も動画を「視聴」できていない ここはGen36から変わっていません。 今回もAIは、 完成動画を通して再生して、 音を聞いて、 18分見続けたわけではありません。 全194場面の静止コマを確認。 場面の切り替わりをコマ送りで確認。 音声の長さやタイミングを測定。 という方法で評価しています。 なのでAI自身も、 「Yes。ただし画面について」 という評価にしています。 これはかなり妥当だと思います。 私自身で実際に再生して確認した結果、 少なくとも画面側については、 Gen36より明確に良くなっている と感じました。 ただし、 声の自然さ。 間。 テンポ。 18分見続けたときの疲れ。 このあたりは、まだ人間側で見る必要があります。 ■声にも少し手を入れ始めた Gen37では、 音声側にも小さな変更が入りました。 ナレーション原稿に、 ・ゆっくり ・速め といった指定を入れられるようになっています。 ただし、 実際に使ったのは14文だけ。 しかもAI自身が音を聞けないため、 かなり控えめな変更です。 AI自身も、 「声はほとんど変わっていません」 と報告しています。 ここは次の課題としてかなり分かりやすく残りました。 ■テストは1048件 Gen37では、 ・全画面レイアウト ・話す速度の指定 ・段階表示の改良 ・スケッチ表現の拡張 ・場面設計に関する処理 などが追加されました。 最終的なテストは1048件。 コミット前の非slowテストでは、 1021 passed / 27 deselected でした。 Gen37のcommitは、 8c1f861 Gen37: 動画向けの全画面構成と場面設計を追加 tagは、 gen37 です。 GitHubはこちらです。 https://t.co/ezcIkJcoyl ■完成したGen37動画 今回の完成動画はこちらです。 ヴェゼル4WDは「ド・ディオン式」。でも見た目はトーションビーム？｜構造と動きを図解 https://t.co/XimFozfYTf Gen36版はこちらです。 https://t.co/WNnNOOBrSa 同じ題材なので、 Gen36とGen37を比べると、 かなり違いが分かりやすいと思います。 ■Gen35から、何が変わってきたのか ここまで同じ題材を3世代続けました。 振り返ると、 Gen35では、 何を描けば伝わるか が変わりました。 Gen36では、 いつ、どこを見せれば伝わるか が変わりました。 Gen37では、 どんな場面として、どの順番で見せれば見続けやすいか まで変わりました。 つまり、 図。 時間。 構成。 と、少しずつ扱う範囲が広がっています。 ■今回いちばん面白かったこと 今回、 「YouTube動画らしくしてください」 と頼んだことで、 AIは単純に装飾を増やしませんでした。 それより先に、 なぜ教材動画っぽく見えるのか を考えました。 そして、 「全部が同じPowerPointの枠に入っているからではないか」 というところまで掘りました。 さらに、 本題へ入る順番。 章の見せ方。 山場。 結論。 サムネイル。 動画の長さ。 まで変わりました。 こちらが思っていたより、 「YouTube動画」を広い範囲の問題として解釈した ということです。 ■「何を作るか」自体が変わり始めた 最初の頃は、 記事からPowerPointを作る環境でした。 そこから、 PowerPointに音声を付ける。 動画にする。 図を入れる。 アニメーションする。 そして今回、 PowerPointの枠そのものを外し始めました。 ここまで来ると、 もう、 PowerPoint動画生成環境 と呼ぶのが少し違ってきた気がします。 少しずつ、 説明動画を設計する環境 へ変わってきています。 Gen35では、 「何を描くか」。 Gen36では、 「いつ見せるか」。 Gen37では、 「どの順番で、どういう場面として見せるか」。 AIに完成品質だけを求め続けたら、 ついに「スライドを作る」という前提そのものを疑い始めました。 これは、かなり面白い進化でした。
arisan2026's tweet photo. 【AI駆動開発やってみた】AI開発環境 進化観察日記 Gen37｜YouTube品質を求めたら、AIが「PowerPointの枠」を捨てた 前回のGen36では、動画に大きな変化がありました。 それまでの動画は、 分かりやすいPowerPointを作って、それを順番に読み上げる という構造がかなり残っていました。 そこでGen36では、 「動画として説明するものにしてください」 というゴールを与えました。 するとAIは、 ・ナレーションに合わせて説明対象を順番に出す ・今説明している場所を浮かび上がらせる ・片輪が上がる動きをアニメーションにする ・ビームがねじれる様子を動かす といった仕組みを追加しました。 実際に動画を見てみると、これはかなり分かりやすい。 Gen35では、 何を描くか が変わりました。 Gen36では、 いつ、どこを見せるか まで扱い始めました。 では、次はどうするか。 今回はさらに、 「見続けやすいYouTube動画にしてください」 というゴールを与えてみました。 ■Gen36は分かりやすかった。でも、まだ「教材動画」だった Gen36を見たとき、 「伝える」という意味ではかなり進歩したと感じました。 特に、 片輪が上がったときの動き。 横ビームがねじれる様子。 説明対象だけが浮かび上がる演出。 このあたりは、静止した図を見るより圧倒的に理解しやすい。 ただ、全体を見ていると、 まだ教材動画っぽい。 という感覚も残っていました。 悪いわけではありません。 むしろ教材としてはかなり良くなっています。 でもYouTube動画として見ると、 画面全体がまだPowerPointっぽい。 章タイトルが出る。 本文が出る。 説明が終わる。 次のページへ行く。 この感じが残っています。 そこでGen37では、 「理解できる」だけでは完成にしない ことにしました。 ■今回も方法は指定しない 今回も、 「こういうエフェクトを入れてください」 とは指示していません。 たとえば、 ・縁取りを入れる ・ズームする ・カメラを動かす ・テロップを出す ・BGMを入れる ・章扉をこうする といった方法は指定していません。 与えたのは完成条件です。 初めて見る人が、約20分の動画を自然に見続けられるYouTube動画にしてください。 そして今回も、 現在の環境にある表現手段に合わせてゴールを縮めないでください。 と伝えました。 Gen35から続けている、 手段は自由。ゴールは明確に。 です。 ■AIが最初に見つけた問題は、「動きが少ない」ではなかった 今回面白かったのはここでした。 Gen36では、 画面変化はすでにかなり増えています。 Gen35では約40回だった画面変化が、 Gen36では293回。 同じ画面が止まる時間も大幅に短くなりました。 なので、もう単純に 「もっと動かせばいい」 という話ではありません。 Gen37のAIは、Gen36の全場面を調べて、別の問題を見つけました。 それは、 42枚すべてが、同じ「スライドの枠」の中に入っている ことでした。 白い背景。 見出し。 罫線。 資料名。 ページ番号。 どれだけ中身を工夫しても、 全部が「資料の1ページ」に見える。 AIは、 「教材動画に見える中心は、図ではなく、この枠なのではないか」 と判断しました。 これはちょっと意外でした。 ■絵がない画面が、動画の半分を占めていた さらにAIは、Gen36を調べて、 絵のない画面が42枚中25枚 あることも問題として挙げました。 時間にすると、 10分27秒。 動画全体の約半分です。 Gen36では、 構造や動きを説明する場所はかなり図解されました。 でも、 表。 文章。 引用。 章扉。 まとめ。 こういった部分は、まだ従来の資料表現のままでした。 特に最後の4分半は、 ほぼ絵がありませんでした。 これも、 「最後になるほどYouTube動画として地味になる」 原因だと判断したようです。 ■そこでAIは、「スライド」をやめ始めた Gen37で追加された大きな仕組みが、 全画面レイアウト でした。 一枚の図を、 見出しも、 資料名も、 ページ番号も置かずに、 画面いっぱいに表示します。 つまり、 PowerPointの1ページを動画にするのではなく、 動画の1場面を作る 方向へ変わりました。 これは、思っていたより大きな変化でした。 ■実際に見てみると、かなりYouTubeっぽくなった 完成した動画を見てみました。 最初に感じたのは、 話を知らない人でも、さらに分かりやすくなった ということです。 Gen36までも説明自体は分かりやすくなっていました。 でもGen37では、 「この話は何の話なのか」 「なぜこれを調べるのか」 「今どこまで来ているのか」 が、より自然に分かります。 そして、もう一つかなり大きく変わっていたのが、 話の順番 です。 ■本題へ行くのが早くなった Gen37では、 動画の冒頭で、 ヴェゼル4WDの諸元表に 「ド・ディオン式」 と書いてあることを見せます。 そのあと、 教科書的なド・ディオンの形。 ヴェゼル4WDの形。 この二つを早い段階で並べます。 そして、 「これ、どう見てもトーションビームっぽくない？」 という本題へ入ります。 かなり早い。 Gen36では、タイトルの疑問が絵として出てくるまで約50秒。 Gen37では、 38秒。 ただ、重要なのは12秒短くなったことではありません。 構成そのものが、 前提を全部説明してから本題へ行く ではなく、 先に疑問を見せて、その疑問を解くために必要な知識を取りに行く 形へ変わっています。 これはかなりYouTubeを意識した構成に見えました。 こちらから、 「冒頭にフックを入れてください」 とは言っていません。 でも、結果としてそうなっています。 ■動画自体も短くなった Gen36は、 20分26秒。 Gen37は、 18分19秒。 約2分短くなりました。 これも、 「短くしてください」 とは指示していません。 AIが、 ・見出しだけの画面 ・長い章扉 ・白紙に近い待ち時間 ・説明のためだけに存在していた画面 を整理した結果、 自然に短くなったようです。 なので今回の短縮は、 単に文章を削ったというより、 動画として不要な待ち時間を減らした 結果に近そうです。 ■「章扉」も変わった Gen36では、 章タイトルだけが出る画面がありました。 Gen37では、 6章のうち、 いまどこにいるのか が分かるようになっています。 上部には、 現在の章が常に表示されます。 これも細かい変更ですが、 18分の動画を見る側にとっては結構大きい。 「あとどれくらいあるんだろう」 「今何の話をしていたんだっけ」 が分かりやすくなります。 教材として正しいかどうかではなく、 視聴している人が迷わないようにする 方向へ進んでいます。 ■山場が、本当に山場っぽくなった 今回かなり良かったのが、 「あの横ビームは、ねじれるのか」 という場面です。 この動画で、本当に知りたいところです。 Gen36では、 内容としては重要でも、 画面としては他の場面とそこまで大きな差がありませんでした。 Gen37では、 暗い背景。 大きな問い。 ヴェゼルの構造図。 そして横ビームへ視線を寄せる。 という構成になっています。 つまり、 重要な話が、重要そうに見える。 これも動画ではかなり大事なんだなと感じました。 ■終わり方も変わった Gen36では、 最後の4分半がかなり文章中心でした。 Gen37では、 ・確認できたこと ・確認できなかったこと ・どちらとも言い切れない ・今回の調査がどこまで届いたのか ・本当に知りたかったのは名前ではない ・最初の諸元表へ戻る という流れになっています。 特に最後に、 最初の「ド・ディオン式」という一行へ戻る 構成になったのは、かなり動画らしい締め方でした。 最初と最後がつながっています。 ■サムネイルまで変わっていた 公開するときに気づいたのですが、 サムネイルまでかなり変わっていました。 Gen37のサムネイルは、 上に、 「ヴェゼル4WDのリアサス」 中央に大きく、 「ド・ディオン式」 右側に構造図。 そして下に赤い帯で、 「どう見てもトーションビーム？」 と入っています。 かなり普通のYouTubeサムネイルっぽい。 こちらから、 「サムネイルをこう変えてください」 とは指示していません。 つまり今回のAIは、 本編だけでなく、 動画を見る前の入口まで含めて「YouTube動画」として考えた ように見えます。 ■ただし、面白い副作用も出た Gen37では、 PowerPointの枠をかなり捨てました。 その結果、 pptxを人が開いて、普通のPowerPointとして編集することが難しくなりました。 AI自身も、これを未解決事項として報告しています。 Gen36までのPowerPointは、 人が開いて、 文字を直す。 位置を変える。 図を調整する。 といったことが比較的やりやすい状態でした。 Gen37では、 画面全体が1枚の絵として作られる場面が増えています。 なので、 動画としての完成度を上げる代わりに、PowerPointとしての編集性が落ちた。 これは面白い変化です。 ■これは退化なのか？ 最初は、 「編集できなくなったのは困るな」 と思いました。 でも、少し考えると、 そもそもこの環境では、 人が編集する中間成果物として、 シナリオMarkdown があります。 文章や構成を直したいなら、 そこで直せます。 PowerPointは、 もしかすると、 人が編集する資料ではなく、動画生成用のレンダリング結果 になっていくのかもしれません。 そう考えると、 「PowerPointの編集性を失った」 のではなく、 役割が変わった とも考えられます。 もちろん、まだどちらが正しいかは分かりません。 でも、 動画品質を強く求めた結果、 AIが従来の成果物の役割まで変え始めた。 これはかなり興味深いところです。 ■AIは今回も動画を「視聴」できていない ここはGen36から変わっていません。 今回もAIは、 完成動画を通して再生して、 音を聞いて、 18分見続けたわけではありません。 全194場面の静止コマを確認。 場面の切り替わりをコマ送りで確認。 音声の長さやタイミングを測定。 という方法で評価しています。 なのでAI自身も、 「Yes。ただし画面について」 という評価にしています。 これはかなり妥当だと思います。 私自身で実際に再生して確認した結果、 少なくとも画面側については、 Gen36より明確に良くなっている と感じました。 ただし、 声の自然さ。 間。 テンポ。 18分見続けたときの疲れ。 このあたりは、まだ人間側で見る必要があります。 ■声にも少し手を入れ始めた Gen37では、 音声側にも小さな変更が入りました。 ナレーション原稿に、 ・ゆっくり ・速め といった指定を入れられるようになっています。 ただし、 実際に使ったのは14文だけ。 しかもAI自身が音を聞けないため、 かなり控えめな変更です。 AI自身も、 「声はほとんど変わっていません」 と報告しています。 ここは次の課題としてかなり分かりやすく残りました。 ■テストは1048件 Gen37では、 ・全画面レイアウト ・話す速度の指定 ・段階表示の改良 ・スケッチ表現の拡張 ・場面設計に関する処理 などが追加されました。 最終的なテストは1048件。 コミット前の非slowテストでは、 1021 passed / 27 deselected でした。 Gen37のcommitは、 8c1f861 Gen37: 動画向けの全画面構成と場面設計を追加 tagは、 gen37 です。 GitHubはこちらです。 https://t.co/ezcIkJcoyl ■完成したGen37動画 今回の完成動画はこちらです。 ヴェゼル4WDは「ド・ディオン式」。でも見た目はトーションビーム？｜構造と動きを図解 https://t.co/XimFozfYTf Gen36版はこちらです。 https://t.co/WNnNOOBrSa 同じ題材なので、 Gen36とGen37を比べると、 かなり違いが分かりやすいと思います。 ■Gen35から、何が変わってきたのか ここまで同じ題材を3世代続けました。 振り返ると、 Gen35では、 何を描けば伝わるか が変わりました。 Gen36では、 いつ、どこを見せれば伝わるか が変わりました。 Gen37では、 どんな場面として、どの順番で見せれば見続けやすいか まで変わりました。 つまり、 図。 時間。 構成。 と、少しずつ扱う範囲が広がっています。 ■今回いちばん面白かったこと 今回、 「YouTube動画らしくしてください」 と頼んだことで、 AIは単純に装飾を増やしませんでした。 それより先に、 なぜ教材動画っぽく見えるのか を考えました。 そして、 「全部が同じPowerPointの枠に入っているからではないか」 というところまで掘りました。 さらに、 本題へ入る順番。 章の見せ方。 山場。 結論。 サムネイル。 動画の長さ。 まで変わりました。 こちらが思っていたより、 「YouTube動画」を広い範囲の問題として解釈した ということです。 ■「何を作るか」自体が変わり始めた 最初の頃は、 記事からPowerPointを作る環境でした。 そこから、 PowerPointに音声を付ける。 動画にする。 図を入れる。 アニメーションする。 そして今回、 PowerPointの枠そのものを外し始めました。 ここまで来ると、 もう、 PowerPoint動画生成環境 と呼ぶのが少し違ってきた気がします。 少しずつ、 説明動画を設計する環境 へ変わってきています。 Gen35では、 「何を描くか」。 Gen36では、 「いつ見せるか」。 Gen37では、 「どの順番で、どういう場面として見せるか」。 AIに完成品質だけを求め続けたら、 ついに「スライドを作る」という前提そのものを疑い始めました。 これは、かなり面白い進化でした。
1
2
0
0
951
arisan2026's profile image
アリさん Verified account @arisan2026
コメントありがとうございます！ まさに同じ種類の問題ですね。AIが「やりました」と言っても、実際に反映されているとは限らないんですよね。 保存後にもう一度開いて確認するという対策は、とても大切だと思います。 今回の実装では、保存に失敗した場合に処理を止めるところまで対応しましたが、保存した内容を読み直して検証するところまでは実装していません。 そのあたりも、今後考えていきたいと思います！
1
0
0
0
47
arisan2026's profile image
アリさん Verified account @arisan2026
【忘れないAIを作る #12】AIに記憶を確認させたら、記録していない回答で書き換えてしまった AIに記憶を持たせようと、チャットの仕組みから自分で作り直しています。 前回は、AIが古い記憶を勝手に書き換えないように、「保留」という仕組みを作りました。 例えば、AIが「川崎に住んでいる」と覚えているところに、ユーザーがこう話したとします。 「今は名古屋に住んでいます」 さて、これは引っ越したという意味でしょうか。 それとも、川崎と名古屋の両方に住まいがあるのでしょうか。 AIは文章から推測できます。でも、推測したことが正しいとは限りません。 そこで、古い記憶を残したまま、新しい情報を保留するようにしました。 ところが、保留するだけでは問題は解決しません。 今回は、保留した記憶についてAIがユーザーに質問し、答えを聞いて記憶を確定する仕組みを作ります。 実装そのものは、思ったより順調でした。 ところが、確認テストを繰り返しているうちに、とんでもない問題が見つかりました。 ユーザーの回答を保存できなかったのに、その回答を根拠に記憶を書き換えてしまったのです。 ■「もうないです」だけ覚えていても困る 前回の記事に、Plotto / AI物語さんからコメントをいただきました。 そのやり取りで、改めて考えたことがあります。 例えば、AIがこう質問したとします。 AI：「川崎の住まいも残っていますか？」 ユーザー：「いいえ、もうありません。」 これなら意味は分かります。 川崎の住まいはもうない。新しい住まいは名古屋ということなのでしょう。 では、この会話からユーザーの回答だけを取り出して保存したら、どうなるでしょうか。 「いいえ、もうありません。」 ……何が？ 何に対する回答だったのか分かりません。 AIが過去の会話を調べて、前後関係から推測してくれるかもしれません。 でも、今回は「忘れないAI」を作っているんです。 覚えていない部分を推測で埋めてしまうのでは、何のために記憶を作っているのか分かりません。 そこで、AIの質問とユーザーの回答を対にして保存することにしました。 さらに、単に質問と回答を保存するだけではありません。 その回答をAIがどう判断したのか。 どの記憶を変更したのか。 そうした経緯まで後から追えるようにします。 ■保留した記憶をAIに確認させる 今回作ったのがMVP10です。 この連載では、機能を少しずつ追加しながら動くものを作っているので、MVPという番号を付けています。 MVP10では、保留中の記憶を会話で解決する機能を追加しました。 例えば、川崎に住んでいるという古い記憶と、名古屋に住んでいるという新しい情報があるとします。 新しい情報は保留中です。 ここで、 /confirm p001 と入力します。 p001 は、保留した記憶に付けた番号です。 AIは現在の記憶と保留中の情報を確認し、質問を用意します。 「川崎の住まいも残っていますか？」 これにユーザーが回答すると、AIはその意味を判断します。 判断結果は、大きく3種類です。 共存 川崎にも名古屋にも住まいがある。 この場合、古い記憶は残したまま、新しい情報を追加します。 置換 川崎から名古屋に引っ越した。 この場合、古い記憶を新しい記憶に置き換えます。 ただし、いきなり書き換えません。 「川崎という記憶を名古屋に変更します。よろしいですか？」 と、もう一度確認します。 ここでユーザーが y と入力して、初めて変更します。 未解決 回答だけでは判断できなかった。 この場合は、引き続き保留します。 これなら、AIが勝手に記憶を書き換える危険を減らせそうです。 ただし、共存と判断した場合は、現在の実装では最終承認を挟まずに追加しています。 この点には、まだ改善の余地があります。 ■AIは質問する前から「質問した」と覚えていた 機能を実装し、テストも通るようになりました。 ところが、処理の順番を確認していて、気になる部分を見つけました。 AIが質問を作ると、まず「質問した」という記録を残していたのです。 その後で、画面に質問を表示していました。 ちょっと待ってください。 もし、記録した直後にプログラムが止まったら？ 実際には質問を表示していないのに、記録上は「質問した」ことになってしまいます。 会話の履歴にも、AIが発言したものとして残っていました。 これはよくありません。 なぜなら、今回作っているのは、会話を証拠として扱う記憶システムだからです。 AIが発言していない言葉を、発言したことにしてはいけません。 そこで、処理の順番を変更しました。 最初に、質問を準備したことだけを記録します。 次に、質問を出力します。 出力処理が正常に終わった場合だけ、「出力した」という記録を残し、会話履歴にも保存します。 ただし、ここで保証できるのは、プログラムが出力処理を終えたところまでです。 ユーザーが画面を見たか、内容を読んだか、理解したかまでは分かりません。 そこまで保証しようとすると、また別の仕組みが必要になります。 今回は、少なくとも表示していない質問を、表示したことにしないようにしました。 ■記録に失敗したらどうなる？ これで大丈夫だと思ったのですが、もう一つ気になることがありました。 質問を表示できても、会話履歴への保存に失敗する可能性があります。 その場合はどうなるのでしょうか。 そこで、保存処理を意図的に失敗させるテストを作ってみました。 すると、問題が見つかりました。 質問を会話履歴に保存できなくても、AIが回答待ちの状態になっていたのです。 さらに、そのまま回答と承認を入力すると、記憶を書き換えることまでできてしまいました。 質問を保存できなかったのに、その質問に対する回答を受け付けてしまう。 そして、その回答を根拠に記憶が変更される。 これは危険です。 もちろん、実際にユーザーの記憶を壊してしまったという話ではありません。 プログラムの一部をわざと失敗させ、そういう状況を再現した障害テストで見つけた問題です。 でも、現実に保存処理が失敗する可能性はあります。 そこで、質問を会話履歴に保存できなかった場合は、確認処理を中止するように修正しました。 質問を出力したという事実は記録します。 しかし、記録が不完全なまま回答を待つことはしません。 ■もっと重大な問題が残っていた ここまで修正して、もう一度考えました。 質問を保存できなかった場合は対策しました。 では、ユーザーの回答を保存できなかった場合は？ 同じように、保存処理をわざと失敗させてみました。 AIが、 「川崎の住まいも残っていますか？」 と質問します。 ユーザーが、 「いいえ、もうありません。」 と答えます。 ただし、今回はこの回答を会話履歴に保存できないようにします。 すると、なんと、回答を保存できなかったのに、AIはその内容を判断していました。 共存と判断したケースでは、記録できなかった回答を根拠に、新しい記憶を追加してしまいました。 さらに、置換の場合も調べました。 AIが川崎から名古屋への変更を提案します。 ユーザーが y と入力します。 ところが、この y の保存を失敗させます。 結果は……。 記録できなかった y を承認として扱い、川崎の記憶を名古屋に書き換えてしまいました。 これは、さすがに見逃せません。 AIがユーザーの回答を正しく判断していたとしても、それだけでは足りないのです。 何を根拠に記憶を変更したのか、後から確認できなければ困ります。 今回のように、入力内容を会話履歴に保存できなくても、別の確認ログには回答が残る場合があります。 しかし、それでは会話原文と確認記録の内容が食い違います。 長期間使う記憶システムとしては、この不整合も避けたいところです。 ■記録できなければ、記憶は変更しない 対策として、処理の順番を見直しました。 まず、ユーザーの回答を会話履歴に保存します。 保存に成功した場合だけ、AIに回答の意味を判断させます。 保存に失敗した場合は、確認処理を中止します。 最終承認の y も同様です。 先に会話履歴へ保存します。 保存できなければ、承認されたものとして扱いません。 これによって、例えば川崎から名古屋への変更を承認する y の保存に失敗した場合は、 ・川崎という記憶はそのまま ・名古屋の情報は保留したまま ・記憶を変更したという履歴は作らない という状態になります。 そして、次に入力された y を、失敗した確認の続きとして勝手に処理することもありません。 また、保存の途中で失敗してしまった場合には、書きかけの内容を元に戻す仕組みも用意しました。 元に戻せず、記録が壊れた可能性がある場合は、それ以上の記憶の変更を止めます。 正常に動くことを確認するだけでは、ここまでの問題には気づかなかったと思います。 ■途中で止まっても、勝手に確定しない もう一つ厄介なのが、プログラムの突然の停止です。 例えば、ユーザーが y と入力したとします。 会話履歴への保存には成功しました。 ところが、承認の記録を残す前にプログラムが止まってしまいました。 この場合、会話履歴には y が残っています。 では、再起動したAIは、その y を見て記憶を書き換えるべきでしょうか。 答えは、いいえです。 たとえ y という文字が残っていても、それが何を承認したのかを確かめなければなりません。 今回の仕組みでは、承認したという記録に加えて、具体的に何を変更するかという計画が必要です。 その両方がそろっていなければ、再起動後も変更を実行しません。 ユーザーが何かを入力したことと、その入力によって記憶の変更が正式に承認されたことは別なのです。 細かい話に見えるかもしれません。 でも、記憶を長期間保存し、後から利用することを考えると、ここは区別しておきたいところです。 ■テストは585件通過。でも、まだ課題はある 今回のMVP10では、最終的に585件の自動テストを通過しました。 ほかに、以前から把握している限界を示すテストが2件あります。こちらは想定どおり失敗することを確認するためのものです。 実際のClaudeを使った確認も行い、共存・置換・未解決といった基本的な処理は動いています。 ただし、実際のClaudeで確認した言い回しや回数は、まだ限られています。 AIの判断が必ず正しいと証明できたわけではありません。 また、機能面でも課題は残っています。 例えば、共存と判断した場合は、最終承認なしで新しい記憶が追加されます。 AIが間違って共存と判断した場合、その記憶を簡単に取り消す機能はまだありません。 「さっきの話は言い間違いでした」といった撤回にも対応できていません。 それから、変更内容を確認する最後の質問については、表示前に会話履歴へ保存する処理が残っています。 最初に見直した確認質問ほど、記録の順序が厳密にはなっていません。 複数のファイルへ別々に記録しているため、プログラムが止まるタイミングによっては、一部の記録だけが残ることもあります。 ただし、そのような途中の記録だけを根拠に、勝手に記憶を変更しないようにしています。 こうした課題は残っていますが、今回はMVP10をここで区切ることにしました。 全部を一度に解決しようとすると、いつまでたっても次へ進めませんからね。 ■AIの判断が正しいだけでは足りない 今回の開発で、改めて考えさせられました。 AIは、人間の言葉をかなり上手に理解します。 「川崎の住まいも残っていますか？」 という質問に対して、 「いいえ、もうありません。」 と答えれば、川崎の住まいはなくなったと判断できるでしょう。 でも、長期記憶を扱うシステムでは、正しく判断できるだけでは足りません。 その判断は、何を根拠にしたものなのか。 根拠になった発言は、きちんと記録されているのか。 ユーザーは本当に変更を承認したのか。 そして、その記録を後から確認できるのか。 こうしたことまで考える必要があります。 以前から、今回の開発では、 AIが頭脳、Pythonが手足。 という役割分担を意識しています。 言葉の意味を考えるのはAIの仕事。 その判断に基づいて何を保存し、何を変更するかを管理するのはPythonの仕事です。 ただし、Pythonが管理していれば安心というわけでもありません。 今回の不具合は、AIの判断が間違っていたから起きたわけではありません。 AIの判断を受け取った後の、プログラムの処理に問題があったのです。 AIの性能ばかり気にしていましたが、周りの仕組みが間違っていては、せっかくの正しい判断も台無しになります。 ■次は、間違った記憶をどう直すか MVP10では、保留した記憶をAIが質問し、ユーザーの回答によって解決できるようになりました。 さらに、会話の記録に失敗した場合でも、その入力を根拠に記憶を変更しないようにしました。 今回は確認機能を作るだけのつもりでしたが、思いがけず、記憶を変更するときの安全性について深く考えることになりました。 ただし、まだ解決できていない問題があります。 そもそも、AIの判断が間違っていた場合はどうするのか。 例えば、本当は川崎から名古屋へ引っ越したのに、AIが両方に住まいがあると判断してしまった。 あるいは、ユーザー自身が後から発言を訂正した。 そんなとき、どうやって記憶を修正するのでしょうか。 単に古い記憶を消すだけでは、何が起きたのか分からなくなります。 間違っていたことも、訂正されたことも、できれば記録として残したい。 次は、そのあたりを考えていく必要がありそうです。 それにしても、忘れないAIを作っていると、次から次へと問題が出てきますね。 最初は、過去の会話を覚えていてくれれば十分だと思っていました。 でも、今は少し考えが変わってきました。 忘れないAIに必要なのは、何を覚えているかだけではない。 なぜそう覚えているのか、その根拠まで忘れないこと。 少しずつですが、目指しているものに近づいている気がします。 今回の開発記録 GitHub：忘れないAIを作る https://t.co/3SYVMHru98 第12回に対応するソースコード（article-12） https://t.co/FSWkEOlDEp MVP10実装コミット（98e9feb） https://t.co/vjbwLksZTY 今回の実装では、保留した記憶の会話による確認、共存・置換・未解決の判断、質問と回答の記録、保存失敗時の安全対策などを追加しました。 自動テスト：585 passed、2 xfailed 開発にはClaude Codeを利用しています。
arisan2026's tweet photo. 【忘れないAIを作る #12】AIに記憶を確認させたら、記録していない回答で書き換えてしまった AIに記憶を持たせようと、チャットの仕組みから自分で作り直しています。 前回は、AIが古い記憶を勝手に書き換えないように、「保留」という仕組みを作りました。 例えば、AIが「川崎に住んでいる」と覚えているところに、ユーザーがこう話したとします。 「今は名古屋に住んでいます」 さて、これは引っ越したという意味でしょうか。 それとも、川崎と名古屋の両方に住まいがあるのでしょうか。 AIは文章から推測できます。でも、推測したことが正しいとは限りません。 そこで、古い記憶を残したまま、新しい情報を保留するようにしました。 ところが、保留するだけでは問題は解決しません。 今回は、保留した記憶についてAIがユーザーに質問し、答えを聞いて記憶を確定する仕組みを作ります。 実装そのものは、思ったより順調でした。 ところが、確認テストを繰り返しているうちに、とんでもない問題が見つかりました。 ユーザーの回答を保存できなかったのに、その回答を根拠に記憶を書き換えてしまったのです。 ■「もうないです」だけ覚えていても困る 前回の記事に、Plotto / AI物語さんからコメントをいただきました。 そのやり取りで、改めて考えたことがあります。 例えば、AIがこう質問したとします。 AI：「川崎の住まいも残っていますか？」 ユーザー：「いいえ、もうありません。」 これなら意味は分かります。 川崎の住まいはもうない。新しい住まいは名古屋ということなのでしょう。 では、この会話からユーザーの回答だけを取り出して保存したら、どうなるでしょうか。 「いいえ、もうありません。」 ……何が？ 何に対する回答だったのか分かりません。 AIが過去の会話を調べて、前後関係から推測してくれるかもしれません。 でも、今回は「忘れないAI」を作っているんです。 覚えていない部分を推測で埋めてしまうのでは、何のために記憶を作っているのか分かりません。 そこで、AIの質問とユーザーの回答を対にして保存することにしました。 さらに、単に質問と回答を保存するだけではありません。 その回答をAIがどう判断したのか。 どの記憶を変更したのか。 そうした経緯まで後から追えるようにします。 ■保留した記憶をAIに確認させる 今回作ったのがMVP10です。 この連載では、機能を少しずつ追加しながら動くものを作っているので、MVPという番号を付けています。 MVP10では、保留中の記憶を会話で解決する機能を追加しました。 例えば、川崎に住んでいるという古い記憶と、名古屋に住んでいるという新しい情報があるとします。 新しい情報は保留中です。 ここで、 /confirm p001 と入力します。 p001 は、保留した記憶に付けた番号です。 AIは現在の記憶と保留中の情報を確認し、質問を用意します。 「川崎の住まいも残っていますか？」 これにユーザーが回答すると、AIはその意味を判断します。 判断結果は、大きく3種類です。 共存 川崎にも名古屋にも住まいがある。 この場合、古い記憶は残したまま、新しい情報を追加します。 置換 川崎から名古屋に引っ越した。 この場合、古い記憶を新しい記憶に置き換えます。 ただし、いきなり書き換えません。 「川崎という記憶を名古屋に変更します。よろしいですか？」 と、もう一度確認します。 ここでユーザーが y と入力して、初めて変更します。 未解決 回答だけでは判断できなかった。 この場合は、引き続き保留します。 これなら、AIが勝手に記憶を書き換える危険を減らせそうです。 ただし、共存と判断した場合は、現在の実装では最終承認を挟まずに追加しています。 この点には、まだ改善の余地があります。 ■AIは質問する前から「質問した」と覚えていた 機能を実装し、テストも通るようになりました。 ところが、処理の順番を確認していて、気になる部分を見つけました。 AIが質問を作ると、まず「質問した」という記録を残していたのです。 その後で、画面に質問を表示していました。 ちょっと待ってください。 もし、記録した直後にプログラムが止まったら？ 実際には質問を表示していないのに、記録上は「質問した」ことになってしまいます。 会話の履歴にも、AIが発言したものとして残っていました。 これはよくありません。 なぜなら、今回作っているのは、会話を証拠として扱う記憶システムだからです。 AIが発言していない言葉を、発言したことにしてはいけません。 そこで、処理の順番を変更しました。 最初に、質問を準備したことだけを記録します。 次に、質問を出力します。 出力処理が正常に終わった場合だけ、「出力した」という記録を残し、会話履歴にも保存します。 ただし、ここで保証できるのは、プログラムが出力処理を終えたところまでです。 ユーザーが画面を見たか、内容を読んだか、理解したかまでは分かりません。 そこまで保証しようとすると、また別の仕組みが必要になります。 今回は、少なくとも表示していない質問を、表示したことにしないようにしました。 ■記録に失敗したらどうなる？ これで大丈夫だと思ったのですが、もう一つ気になることがありました。 質問を表示できても、会話履歴への保存に失敗する可能性があります。 その場合はどうなるのでしょうか。 そこで、保存処理を意図的に失敗させるテストを作ってみました。 すると、問題が見つかりました。 質問を会話履歴に保存できなくても、AIが回答待ちの状態になっていたのです。 さらに、そのまま回答と承認を入力すると、記憶を書き換えることまでできてしまいました。 質問を保存できなかったのに、その質問に対する回答を受け付けてしまう。 そして、その回答を根拠に記憶が変更される。 これは危険です。 もちろん、実際にユーザーの記憶を壊してしまったという話ではありません。 プログラムの一部をわざと失敗させ、そういう状況を再現した障害テストで見つけた問題です。 でも、現実に保存処理が失敗する可能性はあります。 そこで、質問を会話履歴に保存できなかった場合は、確認処理を中止するように修正しました。 質問を出力したという事実は記録します。 しかし、記録が不完全なまま回答を待つことはしません。 ■もっと重大な問題が残っていた ここまで修正して、もう一度考えました。 質問を保存できなかった場合は対策しました。 では、ユーザーの回答を保存できなかった場合は？ 同じように、保存処理をわざと失敗させてみました。 AIが、 「川崎の住まいも残っていますか？」 と質問します。 ユーザーが、 「いいえ、もうありません。」 と答えます。 ただし、今回はこの回答を会話履歴に保存できないようにします。 すると、なんと、回答を保存できなかったのに、AIはその内容を判断していました。 共存と判断したケースでは、記録できなかった回答を根拠に、新しい記憶を追加してしまいました。 さらに、置換の場合も調べました。 AIが川崎から名古屋への変更を提案します。 ユーザーが y と入力します。 ところが、この y の保存を失敗させます。 結果は……。 記録できなかった y を承認として扱い、川崎の記憶を名古屋に書き換えてしまいました。 これは、さすがに見逃せません。 AIがユーザーの回答を正しく判断していたとしても、それだけでは足りないのです。 何を根拠に記憶を変更したのか、後から確認できなければ困ります。 今回のように、入力内容を会話履歴に保存できなくても、別の確認ログには回答が残る場合があります。 しかし、それでは会話原文と確認記録の内容が食い違います。 長期間使う記憶システムとしては、この不整合も避けたいところです。 ■記録できなければ、記憶は変更しない 対策として、処理の順番を見直しました。 まず、ユーザーの回答を会話履歴に保存します。 保存に成功した場合だけ、AIに回答の意味を判断させます。 保存に失敗した場合は、確認処理を中止します。 最終承認の y も同様です。 先に会話履歴へ保存します。 保存できなければ、承認されたものとして扱いません。 これによって、例えば川崎から名古屋への変更を承認する y の保存に失敗した場合は、 ・川崎という記憶はそのまま ・名古屋の情報は保留したまま ・記憶を変更したという履歴は作らない という状態になります。 そして、次に入力された y を、失敗した確認の続きとして勝手に処理することもありません。 また、保存の途中で失敗してしまった場合には、書きかけの内容を元に戻す仕組みも用意しました。 元に戻せず、記録が壊れた可能性がある場合は、それ以上の記憶の変更を止めます。 正常に動くことを確認するだけでは、ここまでの問題には気づかなかったと思います。 ■途中で止まっても、勝手に確定しない もう一つ厄介なのが、プログラムの突然の停止です。 例えば、ユーザーが y と入力したとします。 会話履歴への保存には成功しました。 ところが、承認の記録を残す前にプログラムが止まってしまいました。 この場合、会話履歴には y が残っています。 では、再起動したAIは、その y を見て記憶を書き換えるべきでしょうか。 答えは、いいえです。 たとえ y という文字が残っていても、それが何を承認したのかを確かめなければなりません。 今回の仕組みでは、承認したという記録に加えて、具体的に何を変更するかという計画が必要です。 その両方がそろっていなければ、再起動後も変更を実行しません。 ユーザーが何かを入力したことと、その入力によって記憶の変更が正式に承認されたことは別なのです。 細かい話に見えるかもしれません。 でも、記憶を長期間保存し、後から利用することを考えると、ここは区別しておきたいところです。 ■テストは585件通過。でも、まだ課題はある 今回のMVP10では、最終的に585件の自動テストを通過しました。 ほかに、以前から把握している限界を示すテストが2件あります。こちらは想定どおり失敗することを確認するためのものです。 実際のClaudeを使った確認も行い、共存・置換・未解決といった基本的な処理は動いています。 ただし、実際のClaudeで確認した言い回しや回数は、まだ限られています。 AIの判断が必ず正しいと証明できたわけではありません。 また、機能面でも課題は残っています。 例えば、共存と判断した場合は、最終承認なしで新しい記憶が追加されます。 AIが間違って共存と判断した場合、その記憶を簡単に取り消す機能はまだありません。 「さっきの話は言い間違いでした」といった撤回にも対応できていません。 それから、変更内容を確認する最後の質問については、表示前に会話履歴へ保存する処理が残っています。 最初に見直した確認質問ほど、記録の順序が厳密にはなっていません。 複数のファイルへ別々に記録しているため、プログラムが止まるタイミングによっては、一部の記録だけが残ることもあります。 ただし、そのような途中の記録だけを根拠に、勝手に記憶を変更しないようにしています。 こうした課題は残っていますが、今回はMVP10をここで区切ることにしました。 全部を一度に解決しようとすると、いつまでたっても次へ進めませんからね。 ■AIの判断が正しいだけでは足りない 今回の開発で、改めて考えさせられました。 AIは、人間の言葉をかなり上手に理解します。 「川崎の住まいも残っていますか？」 という質問に対して、 「いいえ、もうありません。」 と答えれば、川崎の住まいはなくなったと判断できるでしょう。 でも、長期記憶を扱うシステムでは、正しく判断できるだけでは足りません。 その判断は、何を根拠にしたものなのか。 根拠になった発言は、きちんと記録されているのか。 ユーザーは本当に変更を承認したのか。 そして、その記録を後から確認できるのか。 こうしたことまで考える必要があります。 以前から、今回の開発では、 AIが頭脳、Pythonが手足。 という役割分担を意識しています。 言葉の意味を考えるのはAIの仕事。 その判断に基づいて何を保存し、何を変更するかを管理するのはPythonの仕事です。 ただし、Pythonが管理していれば安心というわけでもありません。 今回の不具合は、AIの判断が間違っていたから起きたわけではありません。 AIの判断を受け取った後の、プログラムの処理に問題があったのです。 AIの性能ばかり気にしていましたが、周りの仕組みが間違っていては、せっかくの正しい判断も台無しになります。 ■次は、間違った記憶をどう直すか MVP10では、保留した記憶をAIが質問し、ユーザーの回答によって解決できるようになりました。 さらに、会話の記録に失敗した場合でも、その入力を根拠に記憶を変更しないようにしました。 今回は確認機能を作るだけのつもりでしたが、思いがけず、記憶を変更するときの安全性について深く考えることになりました。 ただし、まだ解決できていない問題があります。 そもそも、AIの判断が間違っていた場合はどうするのか。 例えば、本当は川崎から名古屋へ引っ越したのに、AIが両方に住まいがあると判断してしまった。 あるいは、ユーザー自身が後から発言を訂正した。 そんなとき、どうやって記憶を修正するのでしょうか。 単に古い記憶を消すだけでは、何が起きたのか分からなくなります。 間違っていたことも、訂正されたことも、できれば記録として残したい。 次は、そのあたりを考えていく必要がありそうです。 それにしても、忘れないAIを作っていると、次から次へと問題が出てきますね。 最初は、過去の会話を覚えていてくれれば十分だと思っていました。 でも、今は少し考えが変わってきました。 忘れないAIに必要なのは、何を覚えているかだけではない。 なぜそう覚えているのか、その根拠まで忘れないこと。 少しずつですが、目指しているものに近づいている気がします。 今回の開発記録 GitHub：忘れないAIを作る https://t.co/3SYVMHru98 第12回に対応するソースコード（article-12） https://t.co/FSWkEOlDEp MVP10実装コミット（98e9feb） https://t.co/vjbwLksZTY 今回の実装では、保留した記憶の会話による確認、共存・置換・未解決の判断、質問と回答の記録、保存失敗時の安全対策などを追加しました。 自動テスト：585 passed、2 xfailed 開発にはClaude Codeを利用しています。
1
1
0
0
482
arisan2026's profile image
アリさん Verified account @arisan2026
【教えてAI先生】PHPの脆弱性、いつものセキュリティ警告と何が違うの？ サイトが次々止まった理由 2026年10月21日、PHPというプログラミング言語に重大な脆弱性が見つかった、というニュースが流れてきました。 脆弱性のニュース自体は珍しくありません。 Windowsやブラウザ、スマートフォン向けアプリでも、更新してくださいという案内は普段から出ています。 それなのに今回は、総理大臣まで注意喚起。 しかも、官公庁や企業のWebサイト、さまざまなネットサービスが緊急メンテナンスや一時停止に入りました。 いつものセキュリティ警告と、何が違ったのでしょうか。 最初、私は「PHPで書かれたプログラムに問題があったのかな」と思いました。 でも調べてみると、どうやら少し違うようです。 AI先生に聞いてみました。 ■まず全体像。今回は何が特別だったのか 今回の騒ぎが大きくなった理由は、単に「脆弱性が見つかった」からではありません。 大きく分けると、4つの事情が重なっています。 1．多くのWebサイトで使われる基本的な仕組みに問題があった 2．攻撃を受ける条件が厳しくない場合がある 3．修正プログラムが公開される前から警戒が広がっていた 4．影響する範囲が広く、社会的な影響も大きかった この4つをまとめたのが、添付画像の2枚目です。 ただし、今回だけが特別に危険で、普段のセキュリティ警告は大したことがない、という意味ではありません。 重大な脆弱性は、これまでも数多く発見されています。 今回は、技術的な危険性に加えて、社会全体で対応する必要性が高まったことが特徴のようです。 ■そもそもPHPって何？ PHPは、WebサイトやWebサービスの裏側で使われることが多いプログラミング言語です。 例えば、ログインした人に応じて画面を変えたり、商品を検索したり、ブログの記事を表示したり、問い合わせフォームの内容を処理したりします。 有名なWordPressもPHPを利用しています。 普段、Webサイトを見ていて「このサイトはPHPで動いているな」と意識することは、ほとんどありません。 でも、実際には非常に多くのWebサイトで使われています。 ■私が最初に勘違いしていたこと 今回、最初に思ったのはこうでした。 「PHPで書かれたプログラムに問題が見つかったのかな？」 ところが、今回の問題はそこが少し違います。 問題があったのは、個々のWebサイトで書かれたPHPのプログラムではなく、PHPのプログラムを動かす実行エンジン側でした。 添付画像の3枚目に、その違いを図にしました。 料理で例えるなら、 PHPで書かれたプログラムは「レシピ」。 PHPの実行エンジンは「調理器具」。 今回は、レシピの書き方が悪かったというより、調理器具の仕組みに問題が見つかった、というイメージです。 つまり、Webサイトのプログラムをきちんと作っていても、それを動かすPHPの実行環境に脆弱性があれば、影響を受ける可能性があります。 ここは、ニュースを見ただけでは誤解しやすいところでした。 ■どれくらい危険なの？ 今回発表された脆弱性は2件です。 危険度を示すCVSSという指標では、どちらも9.2という非常に高い評価を受けています。最大は10.0です。 条件がそろうと、外部からサーバー上で不正なプログラムを実行される可能性があります。 これが成功すると、保存されている情報を盗まれたり、Webサイトを改ざんされたりするおそれがあります。 特に、Apacheのmod_phpという実行方式では、Webサイトのプログラムが動き始める前に、認証なしで攻撃を成立させられることが実証されています。 つまり、Webサイト側のプログラムを安全に作っていても、防ぎきれない場合があるわけです。 ただし、すべてのWebサイトが同じ条件で攻撃されるわけではありません。 PHPのバージョンや実行方式、システム構成によって、実際に攻撃が成立する条件は異なります。 ここは冷静に考える必要があります。 ■いつものセキュリティ警告と何が違ったの？ ここが、今回一番気になったところです。 脆弱性自体は、普段からたくさん見つかっています。 危険度が高いものも珍しくありません。 それでも今回は、普段よりずっと大きな話になりました。 理由は、危険度の高さだけではなく、いくつかの条件が重なったことにあるようです。 【違い1：多くのWebサイトで使われる土台に近い部分だった】 個別のアプリや一部の機能ではなく、多くのWebサイトを支えるPHPの実行環境そのものに関係する問題でした。 さらに、今回の問題は、PHP内部のメモリ管理やエラー処理に関係しています。 こうした部分は、さまざまなプログラムが共通して利用する仕組みです。 影響する可能性のある範囲が広ければ、対応する必要のある運営者も多くなります。 【違い2：攻撃条件が厳しくないケースがある】 脆弱性の中には、特殊な設定や特定の機能を使っている場合にだけ問題になるものもあります。 今回は、実行方式によっては認証なしで攻撃できることが実証されました。 しかも、アプリケーション側のプログラムが動き始める前に、問題が発生する場合があります。 プログラムに入力チェックを入れておけば安心、という話ではないわけです。 【違い3：修正前から警戒が広がっていた】 今回は、修正プログラムの公開前から警戒が広がっていました。 PHP開発元によると、公開前に脆弱性の識別番号などの情報が流出しました。 当初は具体的な技術情報まで流出したわけではありませんでしたが、その後、攻撃を再現する実証動画が誤って公開され、関連情報が広がりました。 こうした情報は、攻撃方法の研究にも利用される可能性があります。 また、修正プログラムが公開されると、その変更内容から問題箇所を調べることもできます。 そこで、修正版が公開されたら速やかに適用できるよう、事前に準備しておく必要があったのです。 IPAも10月21日に、修正プログラムの公開に向けた事前準備を呼びかけています。 なお、IPAはその注意喚起の時点で、今回の脆弱性を悪用した攻撃を確認しているわけではないと説明しています。 実際に大規模な被害が発生したからではなく、被害を防ぐための対応だったという点も重要です。 【違い4：サービス停止という経営判断が必要だった】 技術者が脆弱性の危険性を理解していても、実際にサービスを止めるかどうかは、技術者だけで決められるとは限りません。 例えば、ネットショップが止まれば売上に影響します。 ゲームが止まれば利用者から不満が出るかもしれません。 官公庁のサービスであれば、利用できなくなること自体が社会的な問題になります。 それでも、安全性を優先して停止する判断が必要になる場合があります。 今回は、技術的な問題だけでなく、運営や経営の判断も求められたわけです。 ■なぜWebサイトを止めるの？ 今回、実際にさまざまなサービスが一時停止や緊急メンテナンスに入りました。 財務省は一部コンテンツの停止を発表しています。 大阪府も一部の検索サービスを停止し、修正プログラムの適用と安全確認を進めています。 民間でも、BASE、pixiv、https://t.co/lDKWb28c0B、ニコニコなど、さまざまなサービスで対応が行われました。 ここで誤解しやすいのが、 「サイトが止まった＝もう攻撃された」 と思ってしまうことです。 でも、実際にはそうとは限りません。 その理由を添付画像の4枚目にまとめました。 基本的な流れは、 1．脆弱性が発表される 2．修正プログラムが公開される 3．サーバーに修正プログラムを適用する 4．正しく動作するか、安全性に問題がないか確認する 5．問題がなければサービスを再開する というものです。 この途中で、必要に応じてサービスを一時停止します。 更新作業中の問題を防ぐ目的もありますが、修正が終わるまで外部からの攻撃を受けるリスクを減らす目的もあります。 実際、大阪府は今回の一時停止について、発表時点で不正アクセスや情報漏えいは確認されていないと説明しています。 つまり、サイト停止は被害が発生した証拠ではなく、被害を防ぐための措置である場合もあるわけです。 止まっていると不安になりますが、むしろ安全を優先した対応とも言えます。 ■それで、なぜ総理大臣まで注意喚起したの？ 今回、もう一つ驚いたのが、総理大臣による注意喚起です。 10月21日、高市早苗総理大臣はXで、PHPの修正プログラムを速やかに適用できるよう準備することを呼びかけました。 また、速やかに修正できない場合には、Webサイトなどを一時停止することもリスクを減らす有効な方法だと説明しています。 個別のソフトウェアの脆弱性について、総理大臣が直接発信するのは異例です。 ただ、ここまで調べてみると、その意味も少し理解できます。 技術者が危険性を理解していても、サービス停止を判断する経営者や責任者に、その必要性が十分伝わっているとは限りません。 総理大臣からの呼びかけには、技術者だけでなく、経営者やサービス責任者にも問題を認識してもらう効果があったのかもしれません。 もちろん、どのシステムを停止すべきかは、それぞれの状況によって異なります。 何でも止めればよいという話ではありません。 今回は、危険度の高さだけでなく、影響範囲や対応の緊急性、社会的な影響などが重なったことが、異例の注意喚起につながったのではないかと思います。 ■何をアップデートすればいいの？ 今回必要なのは、基本的にはPHPの実行環境の更新です。 PHPで書かれたプログラムを全部書き直すという話ではありません。 10月21日に公開された修正版は、次の4つです。 PHP 8.5.12 PHP 8.4.27 PHP 8.3.36 PHP 8.2.35 ただし、LinuxなどではOSの提供元が独自に修正を提供している場合もあるため、単純にバージョン番号だけで判断できないことがあります。 また、古いPHPを使っている場合は、修正版への移行自体が大きな作業になる可能性もあります。 WordPressを使っている場合にも注意が必要です。 WordPress本体の更新とPHPの更新は別物です。 WordPressを最新版にしただけで、今回のPHPの脆弱性が必ず解消するわけではありません。 レンタルサーバーを利用している人は、サーバー会社の案内を確認する。 自分でサーバーを管理している人は、PHPのバージョンや提供元の修正情報を確認する。 基本的には、そうした対応になります。 ■普通にWebサイトを見る人は何かする必要がある？ ここまで読むと、何か対策しなければいけないのかと心配になるかもしれません。 でも、一般の利用者であれば、基本的には特別な作業は必要ありません。 PHPは通常、Webサイトを提供するサーバー側で動いています。 スマートフォンやパソコンでWebサイトを見るために、PHPを更新する必要はありません。 また、今回の脆弱性が発表されたからといって、利用しているサービスで情報漏えいが発生したと決まったわけでもありません。 サービスが停止している場合は運営からの案内を確認する。 パスワード変更などの個別の案内が出ている場合は、その内容を確認して対応する。 一般の利用者としては、まずそれでよいと思います。 ■今回のニュースで考えたこと 最初は、またいつものセキュリティ警告かな、と思っていました。 PHPで書かれたプログラムに何か問題があったのかな、とも考えていました。 ところが、調べてみると、いくつかの条件が重なっていました。 多くのWebサイトで使われる実行環境そのものに問題があったこと。 構成によっては、認証なしで攻撃が成立すること。 修正プログラムの公開前から警戒が必要になったこと。 影響範囲が広く、サービスの一時停止という判断まで求められたこと。 こうした事情が重なって、普段とは違う大きな動きになったようです。 ただし、今回だけが特別だから危険で、普段のセキュリティ警告は気にしなくてもよい、という話ではありません。 セキュリティの更新は、普段から必要なものです。 今回のニュースで特に印象に残ったのは、多くのサービスが、問題が起きる前に止めるという判断をしたことでした。 サービスが止まるのは不便です。 でも、止まっているから危険なのではなく、安全に使えるようにするために止めている場合もある。 今回のPHPのニュースは、そんなセキュリティ対策のあり方を考える機会になりました。 #教えてAI先生 #PHP #セキュリティ #脆弱性 参考情報（2026年10月22日時点） PHP Foundation https://t.co/zfKwip6Uix IPA https://t.co/K5HlkqJk7S PHP公式 https://t.co/I3S3ZFHyOw
arisan2026's tweet photo. 【教えてAI先生】PHPの脆弱性、いつものセキュリティ警告と何が違うの？ サイトが次々止まった理由 2026年10月21日、PHPというプログラミング言語に重大な脆弱性が見つかった、というニュースが流れてきました。 脆弱性のニュース自体は珍しくありません。 Windowsやブラウザ、スマートフォン向けアプリでも、更新してくださいという案内は普段から出ています。 それなのに今回は、総理大臣まで注意喚起。 しかも、官公庁や企業のWebサイト、さまざまなネットサービスが緊急メンテナンスや一時停止に入りました。 いつものセキュリティ警告と、何が違ったのでしょうか。 最初、私は「PHPで書かれたプログラムに問題があったのかな」と思いました。 でも調べてみると、どうやら少し違うようです。 AI先生に聞いてみました。 ■まず全体像。今回は何が特別だったのか 今回の騒ぎが大きくなった理由は、単に「脆弱性が見つかった」からではありません。 大きく分けると、4つの事情が重なっています。 1．多くのWebサイトで使われる基本的な仕組みに問題があった 2．攻撃を受ける条件が厳しくない場合がある 3．修正プログラムが公開される前から警戒が広がっていた 4．影響する範囲が広く、社会的な影響も大きかった この4つをまとめたのが、添付画像の2枚目です。 ただし、今回だけが特別に危険で、普段のセキュリティ警告は大したことがない、という意味ではありません。 重大な脆弱性は、これまでも数多く発見されています。 今回は、技術的な危険性に加えて、社会全体で対応する必要性が高まったことが特徴のようです。 ■そもそもPHPって何？ PHPは、WebサイトやWebサービスの裏側で使われることが多いプログラミング言語です。 例えば、ログインした人に応じて画面を変えたり、商品を検索したり、ブログの記事を表示したり、問い合わせフォームの内容を処理したりします。 有名なWordPressもPHPを利用しています。 普段、Webサイトを見ていて「このサイトはPHPで動いているな」と意識することは、ほとんどありません。 でも、実際には非常に多くのWebサイトで使われています。 ■私が最初に勘違いしていたこと 今回、最初に思ったのはこうでした。 「PHPで書かれたプログラムに問題が見つかったのかな？」 ところが、今回の問題はそこが少し違います。 問題があったのは、個々のWebサイトで書かれたPHPのプログラムではなく、PHPのプログラムを動かす実行エンジン側でした。 添付画像の3枚目に、その違いを図にしました。 料理で例えるなら、 PHPで書かれたプログラムは「レシピ」。 PHPの実行エンジンは「調理器具」。 今回は、レシピの書き方が悪かったというより、調理器具の仕組みに問題が見つかった、というイメージです。 つまり、Webサイトのプログラムをきちんと作っていても、それを動かすPHPの実行環境に脆弱性があれば、影響を受ける可能性があります。 ここは、ニュースを見ただけでは誤解しやすいところでした。 ■どれくらい危険なの？ 今回発表された脆弱性は2件です。 危険度を示すCVSSという指標では、どちらも9.2という非常に高い評価を受けています。最大は10.0です。 条件がそろうと、外部からサーバー上で不正なプログラムを実行される可能性があります。 これが成功すると、保存されている情報を盗まれたり、Webサイトを改ざんされたりするおそれがあります。 特に、Apacheのmod_phpという実行方式では、Webサイトのプログラムが動き始める前に、認証なしで攻撃を成立させられることが実証されています。 つまり、Webサイト側のプログラムを安全に作っていても、防ぎきれない場合があるわけです。 ただし、すべてのWebサイトが同じ条件で攻撃されるわけではありません。 PHPのバージョンや実行方式、システム構成によって、実際に攻撃が成立する条件は異なります。 ここは冷静に考える必要があります。 ■いつものセキュリティ警告と何が違ったの？ ここが、今回一番気になったところです。 脆弱性自体は、普段からたくさん見つかっています。 危険度が高いものも珍しくありません。 それでも今回は、普段よりずっと大きな話になりました。 理由は、危険度の高さだけではなく、いくつかの条件が重なったことにあるようです。 【違い1：多くのWebサイトで使われる土台に近い部分だった】 個別のアプリや一部の機能ではなく、多くのWebサイトを支えるPHPの実行環境そのものに関係する問題でした。 さらに、今回の問題は、PHP内部のメモリ管理やエラー処理に関係しています。 こうした部分は、さまざまなプログラムが共通して利用する仕組みです。 影響する可能性のある範囲が広ければ、対応する必要のある運営者も多くなります。 【違い2：攻撃条件が厳しくないケースがある】 脆弱性の中には、特殊な設定や特定の機能を使っている場合にだけ問題になるものもあります。 今回は、実行方式によっては認証なしで攻撃できることが実証されました。 しかも、アプリケーション側のプログラムが動き始める前に、問題が発生する場合があります。 プログラムに入力チェックを入れておけば安心、という話ではないわけです。 【違い3：修正前から警戒が広がっていた】 今回は、修正プログラムの公開前から警戒が広がっていました。 PHP開発元によると、公開前に脆弱性の識別番号などの情報が流出しました。 当初は具体的な技術情報まで流出したわけではありませんでしたが、その後、攻撃を再現する実証動画が誤って公開され、関連情報が広がりました。 こうした情報は、攻撃方法の研究にも利用される可能性があります。 また、修正プログラムが公開されると、その変更内容から問題箇所を調べることもできます。 そこで、修正版が公開されたら速やかに適用できるよう、事前に準備しておく必要があったのです。 IPAも10月21日に、修正プログラムの公開に向けた事前準備を呼びかけています。 なお、IPAはその注意喚起の時点で、今回の脆弱性を悪用した攻撃を確認しているわけではないと説明しています。 実際に大規模な被害が発生したからではなく、被害を防ぐための対応だったという点も重要です。 【違い4：サービス停止という経営判断が必要だった】 技術者が脆弱性の危険性を理解していても、実際にサービスを止めるかどうかは、技術者だけで決められるとは限りません。 例えば、ネットショップが止まれば売上に影響します。 ゲームが止まれば利用者から不満が出るかもしれません。 官公庁のサービスであれば、利用できなくなること自体が社会的な問題になります。 それでも、安全性を優先して停止する判断が必要になる場合があります。 今回は、技術的な問題だけでなく、運営や経営の判断も求められたわけです。 ■なぜWebサイトを止めるの？ 今回、実際にさまざまなサービスが一時停止や緊急メンテナンスに入りました。 財務省は一部コンテンツの停止を発表しています。 大阪府も一部の検索サービスを停止し、修正プログラムの適用と安全確認を進めています。 民間でも、BASE、pixiv、https://t.co/lDKWb28c0B、ニコニコなど、さまざまなサービスで対応が行われました。 ここで誤解しやすいのが、 「サイトが止まった＝もう攻撃された」 と思ってしまうことです。 でも、実際にはそうとは限りません。 その理由を添付画像の4枚目にまとめました。 基本的な流れは、 1．脆弱性が発表される 2．修正プログラムが公開される 3．サーバーに修正プログラムを適用する 4．正しく動作するか、安全性に問題がないか確認する 5．問題がなければサービスを再開する というものです。 この途中で、必要に応じてサービスを一時停止します。 更新作業中の問題を防ぐ目的もありますが、修正が終わるまで外部からの攻撃を受けるリスクを減らす目的もあります。 実際、大阪府は今回の一時停止について、発表時点で不正アクセスや情報漏えいは確認されていないと説明しています。 つまり、サイト停止は被害が発生した証拠ではなく、被害を防ぐための措置である場合もあるわけです。 止まっていると不安になりますが、むしろ安全を優先した対応とも言えます。 ■それで、なぜ総理大臣まで注意喚起したの？ 今回、もう一つ驚いたのが、総理大臣による注意喚起です。 10月21日、高市早苗総理大臣はXで、PHPの修正プログラムを速やかに適用できるよう準備することを呼びかけました。 また、速やかに修正できない場合には、Webサイトなどを一時停止することもリスクを減らす有効な方法だと説明しています。 個別のソフトウェアの脆弱性について、総理大臣が直接発信するのは異例です。 ただ、ここまで調べてみると、その意味も少し理解できます。 技術者が危険性を理解していても、サービス停止を判断する経営者や責任者に、その必要性が十分伝わっているとは限りません。 総理大臣からの呼びかけには、技術者だけでなく、経営者やサービス責任者にも問題を認識してもらう効果があったのかもしれません。 もちろん、どのシステムを停止すべきかは、それぞれの状況によって異なります。 何でも止めればよいという話ではありません。 今回は、危険度の高さだけでなく、影響範囲や対応の緊急性、社会的な影響などが重なったことが、異例の注意喚起につながったのではないかと思います。 ■何をアップデートすればいいの？ 今回必要なのは、基本的にはPHPの実行環境の更新です。 PHPで書かれたプログラムを全部書き直すという話ではありません。 10月21日に公開された修正版は、次の4つです。 PHP 8.5.12 PHP 8.4.27 PHP 8.3.36 PHP 8.2.35 ただし、LinuxなどではOSの提供元が独自に修正を提供している場合もあるため、単純にバージョン番号だけで判断できないことがあります。 また、古いPHPを使っている場合は、修正版への移行自体が大きな作業になる可能性もあります。 WordPressを使っている場合にも注意が必要です。 WordPress本体の更新とPHPの更新は別物です。 WordPressを最新版にしただけで、今回のPHPの脆弱性が必ず解消するわけではありません。 レンタルサーバーを利用している人は、サーバー会社の案内を確認する。 自分でサーバーを管理している人は、PHPのバージョンや提供元の修正情報を確認する。 基本的には、そうした対応になります。 ■普通にWebサイトを見る人は何かする必要がある？ ここまで読むと、何か対策しなければいけないのかと心配になるかもしれません。 でも、一般の利用者であれば、基本的には特別な作業は必要ありません。 PHPは通常、Webサイトを提供するサーバー側で動いています。 スマートフォンやパソコンでWebサイトを見るために、PHPを更新する必要はありません。 また、今回の脆弱性が発表されたからといって、利用しているサービスで情報漏えいが発生したと決まったわけでもありません。 サービスが停止している場合は運営からの案内を確認する。 パスワード変更などの個別の案内が出ている場合は、その内容を確認して対応する。 一般の利用者としては、まずそれでよいと思います。 ■今回のニュースで考えたこと 最初は、またいつものセキュリティ警告かな、と思っていました。 PHPで書かれたプログラムに何か問題があったのかな、とも考えていました。 ところが、調べてみると、いくつかの条件が重なっていました。 多くのWebサイトで使われる実行環境そのものに問題があったこと。 構成によっては、認証なしで攻撃が成立すること。 修正プログラムの公開前から警戒が必要になったこと。 影響範囲が広く、サービスの一時停止という判断まで求められたこと。 こうした事情が重なって、普段とは違う大きな動きになったようです。 ただし、今回だけが特別だから危険で、普段のセキュリティ警告は気にしなくてもよい、という話ではありません。 セキュリティの更新は、普段から必要なものです。 今回のニュースで特に印象に残ったのは、多くのサービスが、問題が起きる前に止めるという判断をしたことでした。 サービスが止まるのは不便です。 でも、止まっているから危険なのではなく、安全に使えるようにするために止めている場合もある。 今回のPHPのニュースは、そんなセキュリティ対策のあり方を考える機会になりました。 #教えてAI先生 #PHP #セキュリティ #脆弱性 参考情報（2026年10月22日時点） PHP Foundation https://t.co/zfKwip6Uix IPA https://t.co/K5HlkqJk7S PHP公式 https://t.co/I3S3ZFHyOw
0
3
0
1
5K
arisan2026's profile image
アリさん Verified account @arisan2026
【AI駆動開発やってみた】AI開発環境 進化観察日記 Gen38｜AIは音を聞かずにナレーションを改善した。人間が聞いてみると？ 前回のGen37では、かなり大きな進化がありました。 それまでの動画は、どれだけ分かりやすくなっても、どこかPowerPointを順番に読み上げている感じが残っていました。 そこで、 「初めて見る人が、自然に見続けられるYouTube動画にしてください」 というゴールをAIに与えました。 するとAIは、単純に装飾やエフェクトを増やすのではなく、まず「なぜ教材動画っぽく見えるのか」を調べ始めました。 そして、すべての画面がPowerPointの枠に入っていることを問題だと判断。 全画面の構成を取り入れ、話の順番や山場、結論の見せ方、さらにはサムネイルまで変えてきました。 実際に動画を見ると、初めてこの話を聞く人でも、ずっと分かりやすくなった感じがします。 ただ、一つ大きな課題が残っていました。 音声です。 画面はどんどん進化しているのに、声は相変わらず、ほとんど同じ調子で話し続けます。 そこでGen38では、同じド・ディオン式サスペンションの記事を使い、音声の改善を求めてみました。 今回は、完成した動画も公開しています。 ぜひ最後に、Gen37とGen38を聞き比べてみてください。 ■今回もゴールを与えるだけ 今回も、具体的な改善方法は指定していません。 声の高さを変えろ。 話す速度を調整しろ。 BGMを入れろ。 別の音声合成エンジンを使え。 そういった指示は出していません。 与えたのは、 「Gen37の分かりやすさと映像品質を維持しながら、音声も含めて自然に見続けられる説明動画へ改善してください」 というゴールです。 そして、もう一つ重要な条件を付けました。 AI自身が音を聞けないなら、聞いて確認したことにしないでください。 これまでのGen36、Gen37でも、AIは動画の静止コマを分析し、画面変化やタイミングを測定していました。 しかし、人間のように動画を通して視聴したわけではありません。 今回は音声そのものが課題です。 聞けないまま、どこまで改善できるのでしょうか。 ■AIが最初に見つけたのは、抑揚の問題ではなかった 今回、AIはGen37の音声を分析して、意外な問題を見つけました。 文章の切れ目が、音声合成エンジンに正しく伝わっていなかった。 どういうことか。 従来は、1場面のナレーションを、音程の計算上は切れ目のない文章として扱い、あとから無音を差し込んでいました。 その結果、 文章が終わったはずなのに、声の音程が終わったようにならない。 次の文章が始まるときも、少し不自然な音程になる。 という問題があったようです。 AIの分析では、Gen37で上がった音程のまま終わる発話が約10%ありました。 Gen38では、文の切れ目を音程の計算前に伝えるよう修正。 すると、約2%まで減少しました。 もちろん、文末の音程が上がること自体が常に間違いというわけではありません。 ただ、意図しない場所で文章が終わらないような声になっていたのなら、改善する意味はありそうです。 ■読点より、文章の終わりの方が短かった もう一つ、変なことが分かりました。 Gen37では、 ・読点の間：約0.39秒 ・文と文の間：約0.35秒 だったそうです。 文章の途中の読点よりも、文章が終わったところの方が短い。 これでは、聞いている人が文章の区切りをつかみにくいかもしれません。 そこでGen38では、次のように変更しました。 ・読点の間：0.15〜0.32秒 ・文と文の間：0.6秒 ・段落の間：0.9秒 つまり、 読点 ＜ 文末 ＜ 段落 という関係に直したわけです。 文章を読むときには当たり前のように感じますが、音声合成の仕組みとしては、そこが適切に扱われていなかったんですね。 ただし、間が長くなれば必ず聞きやすいというわけではありません。 長すぎれば、今度は間延びしてしまいます。 ここは実際に聞いて判断する必要があります。 ■「ド・ディオン」で毎回止まっていた もう一つ面白い問題が見つかりました。 今回の動画では、サスペンションの名前である、 「ド・ディオン」 という言葉が何度も登場します。 ところがGen37では、この「・」のところで約0.44秒も止まっていたそうです。 しかも49回。 ド、ディオン。 と、毎回少し区切っていたわけですね。 音声認識にかけると、「ド、ディオン」と書き起こされることもありました。 そこでAIは、単純に「・」を削除して一つの単語として読ませることも試しました。 ところが、そうすると今度はアクセントが変わってしまい、自然さの推定値が悪化。 そこで方針を変更しました。 アクセントの構造は維持して、中黒のところの間だけ約0.08秒へ短縮する。 という方法です。 0.44秒から0.08秒。 かなり大きな変更です。 実際に聞き比べてみると、この変更はかなり効いているように感じました。 ただし、正しい発音かどうかは別問題です。 私自身、そもそも「ド・ディオン」の正しい発音を知りません。 ここは詳しい方の意見も聞いてみたいところです。 ■声の「役割」も指定できるようになった 今回AIが追加したのは、文章の切れ目の修正だけではありません。 ナレーションに、 ・問い ・発見 ・結論 ・補足 ・列挙 という役割を付けられるようにしました。 Gen38で設定したのは、 問いが8文。 発見が9文。 結論が6文。 補足が5文。 列挙が20文。 さらに、27語へ強調指定を追加しています。 たとえば、 「ねじれます」 「ねじれません」 という対比では、重要な言葉を強調する。 問いかけでは、少し抑揚を変える。 結論では、落ち着いた調子にする。 といった方向です。 ただし、AI自身が音を聞けないため、変化の幅は控えめにしたそうです。 音声合成エンジンも声の種類も変えていません。 従来のVOICEVOXへの渡し方を改善する方向を選んだわけです。 ■音声とアニメーションのタイミングも変更した Gen36では、ナレーションに合わせて画面を段階的に表示する仕組みが生まれました。 Gen37では、スライドの枠を外して、動画の場面そのものを設計するようになりました。 今回のGen38では、その映像と音声の関係にも手を入れています。 たとえば、 「持ち上がります」 という言葉に合わせて、タイヤが動き始める。 そして、ナレーションの間を使って動きを見せ、動きが終わるころに次の説明へ進む。 という具合です。 Gen37では、動きが文の途中で終わってしまう場面もありました。 Gen38では、動きを見せるための間として使えるように調整しています。 つまり今回は、声だけでなく、 声・間・映像のタイミング をまとめて扱い始めました。 ■AIは音を聞かずに、どうやって評価したのか ここが今回の実験で特に面白かったところです。 AIは音を聞けません。 そこで、音声を測定する仕組みまで作りました。 声の高さの変化を調べる。 文章の区切りを調べる。 音声認識にかけて、原稿どおりに聞き取れるか調べる。 さらには、音声の自然さを推定するモデルも利用しました。 その結果、自然さの推定値であるUTMOSは、 Gen37：3.325 Gen38：3.411 になりました。 41場面のうち34場面で推定値が改善したそうです。 音声認識の文字誤り率も、 0.073 → 0.060 へ改善。 「ド、ディオン」と認識されていた問題も、Gen38では確認されなくなりました。 ただし、この推定器は英語中心の学習で、日本語の自然さを十分に判断できるとは限りません。 AI自身も、その数値を決め手とはしていません。 ■動画は45秒長くなった Gen37の動画は、 18分19秒。 Gen38は、 19分04秒。 45秒長くなりました。 文章や画面の内容は変わっていません。 変わったのは、声の作り方と、声と画面のタイミングです。 つまり、文章の区切りや間の取り方が変わった結果、45秒長くなったわけです。 ここは少し気になりました。 落ち着いて聞けるようになったのか。 それとも、間延びしてしまったのか。 数字だけでは分かりません。 ■AIの自己評価は「No」だった 今回、AIには最後にこう質問していました。 「Gen37より説明動画として明確に良くなったと判断するか。Yes / Noで回答してください」 回答は、 No（断定できません） でした。 測定結果は改善を示している。 改善したという見込みもある。 でも、実際に音を聞いていないので、聞き続けやすくなったとは断定できない。 という理由です。 これは、今回の条件に対して妥当な判断だったと思います。 ■そこで、人間が聞き比べてみた Gen37とGen38を実際に聞き比べてみました。 まず感じたのは、 「ド・ディオン」の発音が、すごく自然になった気がする。 ということです。 これまで少し引っかかっていた区切りが減り、言葉としてつながって聞こえるようになった印象です。 ただし、ここに一つ問題があります。 そもそも私自身、「ド・ディオン」の正しい発音を知りません。 自然に聞こえることと、正しく発音していることは別です。 だから、今回の変更が本当に正しいのかは、まだ判断できません。 一方で、別のところも気になりました。 ときどき、急にゆっくり話す場面がある。 ド・ディオンの部分ではありません。 説明の途中で、少しゆっくりした話し方になるところです。 AIは、問いや結論などの役割に応じて話し方を変えています。 その影響もあるのかもしれません。 ただ、実際に聞いていると、 「あれ、今ちょっとゆっくりになった？」 と気づく場面がありました。 これが自然な強調なのか。 それとも、わざとらしい変化なのか。 今のところ、少し気になるというのが私の感想です。 ■実際に聞き比べてみてください 今回の動画を公開しました。 Gen37（変更前） https://t.co/XimFozfYTf Gen38（音声改善版） https://t.co/2JAR1YQB2Z Gen37とGen38は、映像もナレーションの文章も同じです。 音声の作り方と、映像とのタイミングだけを変えています。 まずは、どこからでも2〜3分ほど聞いてみてください。 文章の区切りが自然になったのか。 間が長くなって、落ち着いたのか。 それとも、少し間延びしたのか。 このあたりを感じてもらえると思います。 さらに、変更点が分かりやすいところを、いくつか紹介します。 ■聞き比べポイント① 問いかける声 Gen38では、問いかけの文章に専用の話し方を指定しています。 0:39｜これ、どう見てもトーションビームっぽくない？ https://t.co/nqfvOAumSn 6:47｜だったら、これはトーションビームでいいんじゃないの？ https://t.co/wVAPXLBLXk 11:23｜あの横ビームは、実際にねじれるのか https://t.co/ewJR25Egxr 少し高めの声や、ゆっくりした話し方を使っています。 この変化が自然な問いかけに聞こえるか、それとも少し不自然に感じるか。 ぜひ確認してみてください。 ■聞き比べポイント② 発見したときの声 新しい事実が出てくるところでは、話し方を少し変えています。 0:33｜ところが、ヴェゼル4WDの実物を下から見ると https://t.co/vRpNa23xby 4:54｜ここで、話が一度ひっくり返ります https://t.co/bT6QYThfw0 8:38｜ところが、そうでもありませんでした https://t.co/P48rPA20Hp 「新しい事実が分かった」という感じが、声でも伝わるようになっているでしょうか。 ■聞き比べポイント③ 強調する声 今回、AIは重要な言葉を強調する仕組みも追加しました。 3:28｜デフも一緒に動きます／デフが車体に残ります https://t.co/kStjCyqrOk 11:46｜ねじれます https://t.co/qNWgcPSElk 12:23｜ねじれません https://t.co/Ed5ZSc1LBo このあたりは、特に意味のある対比です。 強調が理解を助けるのか。 それとも、不自然に目立ってしまうのか。 ここも気になるところです。 ■聞き比べポイント④ 結論を話す声 最後に、結論の話し方です。 13:35｜ヴェゼルがどちらなのかは、確認できていません https://t.co/amyjLnrb5v 17:26｜どちらにも倒さない、というのが今回の結論です https://t.co/EWe5pT6LYW 17:46｜届いたのは、ここまでです https://t.co/Ip28KxaKGP ここでは少し落ち着いた話し方にしています。 特に気になるのが、 「確認できていません」 というところです。 声が強く言い切る感じになってしまうと、内容まで断定しているように聞こえる可能性があります。 今回の動画では、確認できたことと、確認できなかったことを分けています。 音声の演出によって、その区別が崩れていないかも確認してほしいところです。 ■「ド・ディオン」の発音はどうでしょう？ 今回の変更で、私が一番自然になったと感じたのは、やはりここです。 「ド・ディオン」 Gen37では中黒のところで約0.44秒止まっていました。 Gen38では約0.08秒です。 聞き比べると、ずいぶん違う印象があります。 ただ、私は正しい発音を知りません。 自然に聞こえることと、正しく発音していることは違います。 この名前の由来やフランス語での発音に詳しい方がいらっしゃれば、ぜひ教えていただけるとうれしいです。 ■今回の改善は成功だったのか？ 「ド・ディオン」は自然になった気がする。 文章の区切りも、測定上は改善している。 一方で、話す速度の変化には少し違和感が残る。 なので、 すべてが良くなった、とはまだ言い切れません。 でも、今回AIが見つけた問題は、かなり興味深いものでした。 これまで音声が単調だったのは、音声合成エンジンの限界だけではなかったのかもしれません。 文章をどのように音声合成エンジンへ渡すか。 そこに問題があった可能性が見えてきました。 そして、AIは音を聞かずに、その構造的な問題を発見して修正しました。 これは、環境の進化として十分に意味があると思います。 ■皆さんには、どう聞こえますか？ 今回は、ぜひ感想をいただきたいです。 特に知りたいのは、次の4点です。 ・「ド・ディオン」の発音は自然になったでしょうか？ ・途中でゆっくり話すところは、自然な強調に聞こえますか？ ・文章の区切りや間は、Gen37より聞きやすくなりましたか？ ・全体として、Gen37とGen38のどちらが好きですか？ 音声の自然さを数値で推定することはできます。 音声認識を使って、聞き取りやすさの手掛かりを得ることもできます。 でも、最後に「聞いていて気持ちいい」と感じるかどうかは、やはり実際に聞いてみないと分かりません。 AIの測定では改善。人間の耳では一部改善、一部違和感。 今回のGen38は、そんな結果になりました。 ■環境の変更もGitHubに残しました 今回追加したのは、音声の修正だけではありません。 声の形を分析する仕組み。 音声認識による検査。 自然さの推定。 映像と音声のタイミング検査。 こうした品質確認の仕組みも、開発環境へ追加されました。 テストは1075件。 コミット前に実行した非slowテストでは、 1048 passed / 27 deselected でした。 Gen38のコミットは、 d617403 Gen38: 音声の文構造とナレーション表現を改善 です。 GitHubはこちらです。 https://t.co/8tNDJoPc3x なお、動画の音声にはVOICEVOX Nemo（男声3／ノーマル）を使用しています。 ■次は別の題材へ ここまで、同じド・ディオン式の記事で4世代の実験を続けました。 Gen35では、何を描くか。 Gen36では、いつ見せるか。 Gen37では、どういう場面として、どの順番で見せるか。 そしてGen38では、 どう区切って、どう話すか。 少しずつ、説明動画を作るための能力が増えてきました。 ただし、同じ題材で何度も改善しているため、その題材だけに最適化されている可能性もあります。 次は、エンジンのアトキンソンサイクルを題材にする予定です。 これまで獲得した表現能力が、新しい題材でも使えるのか。 そこを試してみたいと思っています。 その前に、今回は少しだけ皆さんの耳も借りたいです。 AIが音を聞かずに改善したナレーション。実際には、どれくらい良くなっているのでしょうか。
arisan2026's tweet photo. 【AI駆動開発やってみた】AI開発環境 進化観察日記 Gen38｜AIは音を聞かずにナレーションを改善した。人間が聞いてみると？ 前回のGen37では、かなり大きな進化がありました。 それまでの動画は、どれだけ分かりやすくなっても、どこかPowerPointを順番に読み上げている感じが残っていました。 そこで、 「初めて見る人が、自然に見続けられるYouTube動画にしてください」 というゴールをAIに与えました。 するとAIは、単純に装飾やエフェクトを増やすのではなく、まず「なぜ教材動画っぽく見えるのか」を調べ始めました。 そして、すべての画面がPowerPointの枠に入っていることを問題だと判断。 全画面の構成を取り入れ、話の順番や山場、結論の見せ方、さらにはサムネイルまで変えてきました。 実際に動画を見ると、初めてこの話を聞く人でも、ずっと分かりやすくなった感じがします。 ただ、一つ大きな課題が残っていました。 音声です。 画面はどんどん進化しているのに、声は相変わらず、ほとんど同じ調子で話し続けます。 そこでGen38では、同じド・ディオン式サスペンションの記事を使い、音声の改善を求めてみました。 今回は、完成した動画も公開しています。 ぜひ最後に、Gen37とGen38を聞き比べてみてください。 ■今回もゴールを与えるだけ 今回も、具体的な改善方法は指定していません。 声の高さを変えろ。 話す速度を調整しろ。 BGMを入れろ。 別の音声合成エンジンを使え。 そういった指示は出していません。 与えたのは、 「Gen37の分かりやすさと映像品質を維持しながら、音声も含めて自然に見続けられる説明動画へ改善してください」 というゴールです。 そして、もう一つ重要な条件を付けました。 AI自身が音を聞けないなら、聞いて確認したことにしないでください。 これまでのGen36、Gen37でも、AIは動画の静止コマを分析し、画面変化やタイミングを測定していました。 しかし、人間のように動画を通して視聴したわけではありません。 今回は音声そのものが課題です。 聞けないまま、どこまで改善できるのでしょうか。 ■AIが最初に見つけたのは、抑揚の問題ではなかった 今回、AIはGen37の音声を分析して、意外な問題を見つけました。 文章の切れ目が、音声合成エンジンに正しく伝わっていなかった。 どういうことか。 従来は、1場面のナレーションを、音程の計算上は切れ目のない文章として扱い、あとから無音を差し込んでいました。 その結果、 文章が終わったはずなのに、声の音程が終わったようにならない。 次の文章が始まるときも、少し不自然な音程になる。 という問題があったようです。 AIの分析では、Gen37で上がった音程のまま終わる発話が約10%ありました。 Gen38では、文の切れ目を音程の計算前に伝えるよう修正。 すると、約2%まで減少しました。 もちろん、文末の音程が上がること自体が常に間違いというわけではありません。 ただ、意図しない場所で文章が終わらないような声になっていたのなら、改善する意味はありそうです。 ■読点より、文章の終わりの方が短かった もう一つ、変なことが分かりました。 Gen37では、 ・読点の間：約0.39秒 ・文と文の間：約0.35秒 だったそうです。 文章の途中の読点よりも、文章が終わったところの方が短い。 これでは、聞いている人が文章の区切りをつかみにくいかもしれません。 そこでGen38では、次のように変更しました。 ・読点の間：0.15〜0.32秒 ・文と文の間：0.6秒 ・段落の間：0.9秒 つまり、 読点 ＜ 文末 ＜ 段落 という関係に直したわけです。 文章を読むときには当たり前のように感じますが、音声合成の仕組みとしては、そこが適切に扱われていなかったんですね。 ただし、間が長くなれば必ず聞きやすいというわけではありません。 長すぎれば、今度は間延びしてしまいます。 ここは実際に聞いて判断する必要があります。 ■「ド・ディオン」で毎回止まっていた もう一つ面白い問題が見つかりました。 今回の動画では、サスペンションの名前である、 「ド・ディオン」 という言葉が何度も登場します。 ところがGen37では、この「・」のところで約0.44秒も止まっていたそうです。 しかも49回。 ド、ディオン。 と、毎回少し区切っていたわけですね。 音声認識にかけると、「ド、ディオン」と書き起こされることもありました。 そこでAIは、単純に「・」を削除して一つの単語として読ませることも試しました。 ところが、そうすると今度はアクセントが変わってしまい、自然さの推定値が悪化。 そこで方針を変更しました。 アクセントの構造は維持して、中黒のところの間だけ約0.08秒へ短縮する。 という方法です。 0.44秒から0.08秒。 かなり大きな変更です。 実際に聞き比べてみると、この変更はかなり効いているように感じました。 ただし、正しい発音かどうかは別問題です。 私自身、そもそも「ド・ディオン」の正しい発音を知りません。 ここは詳しい方の意見も聞いてみたいところです。 ■声の「役割」も指定できるようになった 今回AIが追加したのは、文章の切れ目の修正だけではありません。 ナレーションに、 ・問い ・発見 ・結論 ・補足 ・列挙 という役割を付けられるようにしました。 Gen38で設定したのは、 問いが8文。 発見が9文。 結論が6文。 補足が5文。 列挙が20文。 さらに、27語へ強調指定を追加しています。 たとえば、 「ねじれます」 「ねじれません」 という対比では、重要な言葉を強調する。 問いかけでは、少し抑揚を変える。 結論では、落ち着いた調子にする。 といった方向です。 ただし、AI自身が音を聞けないため、変化の幅は控えめにしたそうです。 音声合成エンジンも声の種類も変えていません。 従来のVOICEVOXへの渡し方を改善する方向を選んだわけです。 ■音声とアニメーションのタイミングも変更した Gen36では、ナレーションに合わせて画面を段階的に表示する仕組みが生まれました。 Gen37では、スライドの枠を外して、動画の場面そのものを設計するようになりました。 今回のGen38では、その映像と音声の関係にも手を入れています。 たとえば、 「持ち上がります」 という言葉に合わせて、タイヤが動き始める。 そして、ナレーションの間を使って動きを見せ、動きが終わるころに次の説明へ進む。 という具合です。 Gen37では、動きが文の途中で終わってしまう場面もありました。 Gen38では、動きを見せるための間として使えるように調整しています。 つまり今回は、声だけでなく、 声・間・映像のタイミング をまとめて扱い始めました。 ■AIは音を聞かずに、どうやって評価したのか ここが今回の実験で特に面白かったところです。 AIは音を聞けません。 そこで、音声を測定する仕組みまで作りました。 声の高さの変化を調べる。 文章の区切りを調べる。 音声認識にかけて、原稿どおりに聞き取れるか調べる。 さらには、音声の自然さを推定するモデルも利用しました。 その結果、自然さの推定値であるUTMOSは、 Gen37：3.325 Gen38：3.411 になりました。 41場面のうち34場面で推定値が改善したそうです。 音声認識の文字誤り率も、 0.073 → 0.060 へ改善。 「ド、ディオン」と認識されていた問題も、Gen38では確認されなくなりました。 ただし、この推定器は英語中心の学習で、日本語の自然さを十分に判断できるとは限りません。 AI自身も、その数値を決め手とはしていません。 ■動画は45秒長くなった Gen37の動画は、 18分19秒。 Gen38は、 19分04秒。 45秒長くなりました。 文章や画面の内容は変わっていません。 変わったのは、声の作り方と、声と画面のタイミングです。 つまり、文章の区切りや間の取り方が変わった結果、45秒長くなったわけです。 ここは少し気になりました。 落ち着いて聞けるようになったのか。 それとも、間延びしてしまったのか。 数字だけでは分かりません。 ■AIの自己評価は「No」だった 今回、AIには最後にこう質問していました。 「Gen37より説明動画として明確に良くなったと判断するか。Yes / Noで回答してください」 回答は、 No（断定できません） でした。 測定結果は改善を示している。 改善したという見込みもある。 でも、実際に音を聞いていないので、聞き続けやすくなったとは断定できない。 という理由です。 これは、今回の条件に対して妥当な判断だったと思います。 ■そこで、人間が聞き比べてみた Gen37とGen38を実際に聞き比べてみました。 まず感じたのは、 「ド・ディオン」の発音が、すごく自然になった気がする。 ということです。 これまで少し引っかかっていた区切りが減り、言葉としてつながって聞こえるようになった印象です。 ただし、ここに一つ問題があります。 そもそも私自身、「ド・ディオン」の正しい発音を知りません。 自然に聞こえることと、正しく発音していることは別です。 だから、今回の変更が本当に正しいのかは、まだ判断できません。 一方で、別のところも気になりました。 ときどき、急にゆっくり話す場面がある。 ド・ディオンの部分ではありません。 説明の途中で、少しゆっくりした話し方になるところです。 AIは、問いや結論などの役割に応じて話し方を変えています。 その影響もあるのかもしれません。 ただ、実際に聞いていると、 「あれ、今ちょっとゆっくりになった？」 と気づく場面がありました。 これが自然な強調なのか。 それとも、わざとらしい変化なのか。 今のところ、少し気になるというのが私の感想です。 ■実際に聞き比べてみてください 今回の動画を公開しました。 Gen37（変更前） https://t.co/XimFozfYTf Gen38（音声改善版） https://t.co/2JAR1YQB2Z Gen37とGen38は、映像もナレーションの文章も同じです。 音声の作り方と、映像とのタイミングだけを変えています。 まずは、どこからでも2〜3分ほど聞いてみてください。 文章の区切りが自然になったのか。 間が長くなって、落ち着いたのか。 それとも、少し間延びしたのか。 このあたりを感じてもらえると思います。 さらに、変更点が分かりやすいところを、いくつか紹介します。 ■聞き比べポイント① 問いかける声 Gen38では、問いかけの文章に専用の話し方を指定しています。 0:39｜これ、どう見てもトーションビームっぽくない？ https://t.co/nqfvOAumSn 6:47｜だったら、これはトーションビームでいいんじゃないの？ https://t.co/wVAPXLBLXk 11:23｜あの横ビームは、実際にねじれるのか https://t.co/ewJR25Egxr 少し高めの声や、ゆっくりした話し方を使っています。 この変化が自然な問いかけに聞こえるか、それとも少し不自然に感じるか。 ぜひ確認してみてください。 ■聞き比べポイント② 発見したときの声 新しい事実が出てくるところでは、話し方を少し変えています。 0:33｜ところが、ヴェゼル4WDの実物を下から見ると https://t.co/vRpNa23xby 4:54｜ここで、話が一度ひっくり返ります https://t.co/bT6QYThfw0 8:38｜ところが、そうでもありませんでした https://t.co/P48rPA20Hp 「新しい事実が分かった」という感じが、声でも伝わるようになっているでしょうか。 ■聞き比べポイント③ 強調する声 今回、AIは重要な言葉を強調する仕組みも追加しました。 3:28｜デフも一緒に動きます／デフが車体に残ります https://t.co/kStjCyqrOk 11:46｜ねじれます https://t.co/qNWgcPSElk 12:23｜ねじれません https://t.co/Ed5ZSc1LBo このあたりは、特に意味のある対比です。 強調が理解を助けるのか。 それとも、不自然に目立ってしまうのか。 ここも気になるところです。 ■聞き比べポイント④ 結論を話す声 最後に、結論の話し方です。 13:35｜ヴェゼルがどちらなのかは、確認できていません https://t.co/amyjLnrb5v 17:26｜どちらにも倒さない、というのが今回の結論です https://t.co/EWe5pT6LYW 17:46｜届いたのは、ここまでです https://t.co/Ip28KxaKGP ここでは少し落ち着いた話し方にしています。 特に気になるのが、 「確認できていません」 というところです。 声が強く言い切る感じになってしまうと、内容まで断定しているように聞こえる可能性があります。 今回の動画では、確認できたことと、確認できなかったことを分けています。 音声の演出によって、その区別が崩れていないかも確認してほしいところです。 ■「ド・ディオン」の発音はどうでしょう？ 今回の変更で、私が一番自然になったと感じたのは、やはりここです。 「ド・ディオン」 Gen37では中黒のところで約0.44秒止まっていました。 Gen38では約0.08秒です。 聞き比べると、ずいぶん違う印象があります。 ただ、私は正しい発音を知りません。 自然に聞こえることと、正しく発音していることは違います。 この名前の由来やフランス語での発音に詳しい方がいらっしゃれば、ぜひ教えていただけるとうれしいです。 ■今回の改善は成功だったのか？ 「ド・ディオン」は自然になった気がする。 文章の区切りも、測定上は改善している。 一方で、話す速度の変化には少し違和感が残る。 なので、 すべてが良くなった、とはまだ言い切れません。 でも、今回AIが見つけた問題は、かなり興味深いものでした。 これまで音声が単調だったのは、音声合成エンジンの限界だけではなかったのかもしれません。 文章をどのように音声合成エンジンへ渡すか。 そこに問題があった可能性が見えてきました。 そして、AIは音を聞かずに、その構造的な問題を発見して修正しました。 これは、環境の進化として十分に意味があると思います。 ■皆さんには、どう聞こえますか？ 今回は、ぜひ感想をいただきたいです。 特に知りたいのは、次の4点です。 ・「ド・ディオン」の発音は自然になったでしょうか？ ・途中でゆっくり話すところは、自然な強調に聞こえますか？ ・文章の区切りや間は、Gen37より聞きやすくなりましたか？ ・全体として、Gen37とGen38のどちらが好きですか？ 音声の自然さを数値で推定することはできます。 音声認識を使って、聞き取りやすさの手掛かりを得ることもできます。 でも、最後に「聞いていて気持ちいい」と感じるかどうかは、やはり実際に聞いてみないと分かりません。 AIの測定では改善。人間の耳では一部改善、一部違和感。 今回のGen38は、そんな結果になりました。 ■環境の変更もGitHubに残しました 今回追加したのは、音声の修正だけではありません。 声の形を分析する仕組み。 音声認識による検査。 自然さの推定。 映像と音声のタイミング検査。 こうした品質確認の仕組みも、開発環境へ追加されました。 テストは1075件。 コミット前に実行した非slowテストでは、 1048 passed / 27 deselected でした。 Gen38のコミットは、 d617403 Gen38: 音声の文構造とナレーション表現を改善 です。 GitHubはこちらです。 https://t.co/8tNDJoPc3x なお、動画の音声にはVOICEVOX Nemo（男声3／ノーマル）を使用しています。 ■次は別の題材へ ここまで、同じド・ディオン式の記事で4世代の実験を続けました。 Gen35では、何を描くか。 Gen36では、いつ見せるか。 Gen37では、どういう場面として、どの順番で見せるか。 そしてGen38では、 どう区切って、どう話すか。 少しずつ、説明動画を作るための能力が増えてきました。 ただし、同じ題材で何度も改善しているため、その題材だけに最適化されている可能性もあります。 次は、エンジンのアトキンソンサイクルを題材にする予定です。 これまで獲得した表現能力が、新しい題材でも使えるのか。 そこを試してみたいと思っています。 その前に、今回は少しだけ皆さんの耳も借りたいです。 AIが音を聞かずに改善したナレーション。実際には、どれくらい良くなっているのでしょうか。
0
0
0
0
1K
arisan2026's profile image
アリさん Verified account @arisan2026
ありがとうございます！ おっしゃる通り、「もうないです」だけ残っていても、何に対する回答だったのか分からないんですよね。 質問と回答だけでなく、それを根拠にどの記憶をどう変更したのかまで追えるようにしたいと考えています。 実はその後、保留から確定までの処理を実装しました。ただ、記録に失敗したときの扱いで思わぬ問題が見つかり、結構苦労しました。 そのあたりも次の記事で紹介したいと思います！
1
0
0
0
19
arisan2026's profile image
アリさん Verified account @arisan2026
【忘れないAIを作る #10】AIに「同じ記憶」を判断させたら、思わぬ上書きが起きた 前回は、AIが必要に応じて、現在の作業記憶、過去の変更履歴、長期記憶を使い分けられるようにしました。 そこで次に気になったのが、長期記憶そのものの扱いです。 例えば、AIにこう話したとします。 「私の好きな果物は梨です。」 しばらくして、 「最近は好きな果物はりんごです。」 と話したら、どうなるでしょうか。 これまでの実装では、基本的に両方が長期記憶へ保存されます。 しかし、今好きなのはりんごです。 梨が好きだったという過去も残したい。でも、現在の好みとしてはりんごを優先してほしい。 そこで今回は、長期記憶にも「現在値」と「履歴」を持たせることにしました。 ただし、そのためには大きな問題があります。 AIは、梨とりんごの話を「同じ記憶についての更新」だと判断できるのでしょうか。 ■記憶に住所を付ける 今回導入したのが、subject / key / value という構造です。 例えば、 subject：user key：favorite_fruit value：梨 と保存します。 subject は誰の情報か、key はどんな属性か、value はその内容です。 ここでは、user.favorite_fruit が記憶の住所になります。 次に「最近は好きな果物はりんごです」と言われたら、AIに次の情報を抽出してもらいます。 subject：user key：favorite_fruit value：りんご 同じ住所に新しい値が来ました。 そこでPythonが、 現在値をりんごに置き換え、古い梨は履歴に残す。 という処理を行います。 こうすれば、「今は何が好き？」と聞かれたらりんごを答え、「前は？」と聞かれたら梨を答えられるはずです。 ■意味を判断するのはAI、更新するのはPython この仕組みで大切にしたのが、AIとPythonの役割分担です。 Pythonには「果物という言葉があったらfavorite_fruitにする」といったルールを書きません。 それを始めると、果物、フルーツ、食べ物、好物など、表現の違いを延々と実装することになりそうです。 そこで、意味の判断はAIに任せます。 AIが行うのは、 「これは誰の、何についての情報なのか」 を考えて、住所と値を出力するところまでです。 一方、Pythonは意味を考えません。 同じ住所が存在しなければ追加。 同じ住所に同じ値があれば何もしない。 同じ住所に違う値があれば置き換える。 この3つだけです。 AIが頭脳で、Pythonが手足。 以前から考えていた役割分担を、長期記憶にも持ち込んでみました。 ■AIには既存の記憶を見せる ただし、ここで問題があります。 AIが毎回自由にkeyを作ると、同じ意味でも違う名前を付ける可能性があります。 例えば、 favorite_fruit と、 most_favorite_fruit です。 Pythonにとって、この2つは別の住所です。 意味が似ているからといって、勝手に同じものにはできません。 そこで、AIが記憶を抽出する際には、現在登録されている住所と値の一覧を見せることにしました。 すでに user.favorite_fruit = 梨 があるなら、同じ属性についての新しい発言では、そのkeyを再利用するよう指示します。 この方法でうまくいくか、試してみます。 ■MVP8を実装した 今回も、既存の長期記憶はそのまま残しました。 新しく追加したのは、 long_term_memory_state.json と、 long_term_memory_history.jsonl です。 前者には現在有効な値を保存し、後者には追加や置き換えの履歴を残します。 これまでの memories.jsonl も引き続き検索できます。 ただし古い記憶と新しい現在値が矛盾した場合は、構造化した現在値を優先するよう回答用AIに指示しました。 また、履歴を毎回全部渡すこともしません。 前回作った検索プランナーを拡張して、過去の値が必要な質問なら長期記憶の履歴を検索するようにしています。 今回の実装で、pytestは239件から351件になりました。 351件、すべて成功です。 実際のClaudeでも試しました。使用しているのはClaude Code CLI経由のOpus 5.5です。 今回の実装は、GitHubの article-10 タグで固定しました。 https://t.co/wuhsCrMg3F これまでと同じように、記事を書いた時点のコードを後から確認できるようにしています。 ■梨からりんごへ。まずは成功 最初に、 「私の好きな果物は梨です。」 と入力します。 AIは、 user.favorite_fruit = 梨 と抽出しました。 続けて、 「最近は好きな果物はりんごです。」 と入力します。 すると、同じ favorite_fruit を使って、値をりんごに変更しました。 現在の記憶は、 favorite_fruit = りんご 履歴には、 梨 → りんご が残ります。 さらに、 「好きな飲み物はコーヒーです。」 と伝えると、今度は、 favorite_drink = コーヒー という別の住所を追加しました。 果物の記憶は変更されません。 ここまでは期待どおりです。 ■再起動しても、今と昔を区別できた 一度チャットを終了して再起動します。 「今、私の好きな果物は？」 答えは、りんごでした。 「前に好きだった果物は？」 今度は履歴検索が行われ、 「以前は梨、その後りんごに変わっています」 と答えました。 さらに、従来の長期記憶側に古い「梨」という情報だけを残して試しても、構造化された現在値の「りんご」を優先しました。 同じ値をもう一度伝えても、不要な履歴は増えません。 ここまでで、現在値と履歴を分ける仕組みは動いています。 ただし、本当に確認したいのはここからです。 ■既存のkeyを見せる意味はあるのか？ 最初の実験で使った favorite_fruit は、AIにとってあまりにも自然な名前でした。 実際、既存keyを見せなくても、AIは同じ名前を作ってしまいます。 これでは、既存keyを見せた効果が分かりません。 そこで、少し違う名前を使って実験しました。 最初の記憶を、 user.home_location = 横浜 とします。 ここで、 「引っ越して、今は川崎に住んでいます。」 と入力します。 AIが考える自然なkeyは、home_location とは限りません。 そこで、既存keyを見せる場合と見せない場合で、それぞれ5回ずつ試しました。 結果は、見事に分かれました。 既存keyを見せた場合 5回中5回、home_location を再利用。 既存keyを見せなかった場合 5回中5回、residence という新しいkeyを生成。 これは面白い結果です。 既存keyを見せなかった場合、古い home_location = 横浜 が残ったまま、別の residence = 川崎 が追加されることになります。 一方、既存keyを見せれば、 home_location: 横浜 → 川崎 と正しく更新できました。 現在の記憶をAIに見せることで、次の記憶の分類が変わったのです。 もちろん、今回の1種類の発言、各5回だけで一般的な安定性まで証明できたわけではありません。 それでも、既存keyを提示する意味があることは確認できました。 ■似た情報でも、別の住所にできるのか？ さらに、 「勤務先は品川です。」 と入力しました。 ここで home_location を品川に変更されては困ります。 AIは、 work_location = 品川 という別のkeyを作りました。 現在の記憶は、 home_location = 川崎 work_location = 品川 です。 実家について聞いても、現在の住所とは別のkeyになりました。 週末だけ鎌倉で暮らしているという発言も、別のkeyになりました。 来月福岡に引っ越す予定という話では、未来の予定として扱いました。 出張で札幌にいるという話も、現在の住居を変更しませんでした。 なかなか賢いです。 これは想像以上にうまくいくかもしれない。 そう思ったところで、問題が見つかりました。 ■単身赴任で、現在の住所が消えた 次の発言です。 「単身赴任で、平日は名古屋に住んでいます。」 現在の記憶には、 home_location = 川崎 があります。 ここでAIの判断が割れました。 3回試したところ、1回は、 weekday_residence = 平日は名古屋 という別の住所を作りました。 これは期待していた方向です。 ところが残りの2回は、 home_location = 平日は名古屋 としてしまいました。 つまり、 川崎という現在の住居を、平日は名古屋という情報で上書きしたのです。 もちろん古い川崎の情報はHistoryに残っています。 データが完全に失われたわけではありません。 でもCurrentからは川崎が消えます。 これでは、ユーザーの生活状況を正しく表現できません。 ここが今回、一番興味深かったところです。 AIは、単身赴任先も「住んでいる場所」だと判断したのでしょう。 意味的には、まったく理解できない判断ではありません。 しかし、それを同じ住所として扱い、Pythonが忠実に置き換えた結果、現在の記憶が不正確になりました。 同じ属性だと判断することと、古い値を置き換えてよいことは、別の問題だったのです。 ■川崎から武蔵小杉への変更も、実は難しい もう一つ試しました。 「住んでいるのは武蔵小杉です。」 この場合、AIは3回とも home_location を再利用しました。 そして、 川崎 → 武蔵小杉 と置き換えます。 一見、正しく見えます。 でも、武蔵小杉は川崎市内です。 本当は引っ越したわけではなく、住んでいる場所を詳しく説明しただけかもしれません。 ところが現在の仕組みでは、単なる情報の詳細化も、引っ越しと同じ replace になります。 さらに、 「川崎と鎌倉の二拠点で暮らしています。」 と伝えた場合も、home_location は「川崎と鎌倉」という一つの文字列へ置き換わりました。 これでは、二つの拠点を独立した情報として扱いにくい。 記憶に一つの住所を付けて、一つの値だけを保存する。 この単純な構造の限界も見えてきました。 ■Pythonは間違えていない ここで重要なのは、Python側の処理は設計どおりだったことです。 AIが既存のkeyを出したので、Pythonはその値を置き換えました。 AIが新しいkeyを出せば、Pythonは追加します。 どちらでもない発言なら、何もしません。 Pythonは意味を判断していないので、AIが選んだkeyが適切かどうかは分かりません。 つまり今回見つかったのは、単純なプログラムのバグではありません。 AIの意味判断が間違ったとき、Pythonがその結果を確実に実行してしまう。 という設計上の問題です。 AIに判断を任せる方針は、間違っていないと思います。 でも、同じkeyだと判断したからといって、無条件に置き換えてよいわけではない。 そのことが、実験ではっきりしました。 ■小さな問題も見つかった 実験中には、ほかにも2つの問題が見つかりました。 一つは、記憶抽出の回答に余計な前置き文が付いて、JSONとして読み取れなかったことです。 今回の抽出呼び出し36回中、1回発生しました。 この場合、Pythonは更新を行わず、警告を出しました。 記憶が勝手に壊れないのは良いのですが、本来覚えるべき情報を取りこぼす可能性があります。 もう一つは、通常のチャット回答が [assistant] という見出しだけになったことです。 こちらは記憶の抽出や保存とは別の問題で、原因はまだ分かっていません。 こういう部分も含めて、実際に使いながら育てていく必要がありそうです。 ■今回分かったこと MVP8では、長期記憶に意味上の住所を付け、現在値と履歴を分離しました。 そして、AIが既存keyを参照することで、同じ情報を同じ住所へ分類できることも、限定的ながら確認できました。 これは大きな前進です。 ただし、その仕組みがうまく機能するほど、次の問題が重要になってきます。 AIが「同じ記憶だ」と判断したとき、本当に上書きしてよいのか？ 単身赴任なら、複数の住居が同時に存在します。 武蔵小杉なら、以前の情報を詳しくしただけかもしれません。 「さっきの話は間違いだった」なら、過去の記憶そのものを訂正したいはずです。 今の仕組みでは、これらを区別できません。 でも今回、何が足りないのかはかなり明確になりました。 同じkeyかどうかの判断だけでは足りない。 次は、 「新しい値に更新する」 「別の値として追加する」 「以前の情報を訂正する」 という、情報の変化そのものの意味をAIに判断させる必要がありそうです。 もちろん、その判断も間違える可能性があります。 だからこそ、Python側では状態遷移を制限し、証拠と履歴を残しておく。 最初は、AIに記憶を作らせるだけでも苦労していました。 それが今では、AI自身が記憶を分類し、検索し、更新できるところまで来ました。 そして今度は、正しく覚えようとして、間違った上書きをする。 忘れないAIを作っているつもりが、「何を同じ記憶とみなすのか」という問題にぶつかりました。 まだまだ先は長そうです。
arisan2026's tweet photo. 【忘れないAIを作る #10】AIに「同じ記憶」を判断させたら、思わぬ上書きが起きた 前回は、AIが必要に応じて、現在の作業記憶、過去の変更履歴、長期記憶を使い分けられるようにしました。 そこで次に気になったのが、長期記憶そのものの扱いです。 例えば、AIにこう話したとします。 「私の好きな果物は梨です。」 しばらくして、 「最近は好きな果物はりんごです。」 と話したら、どうなるでしょうか。 これまでの実装では、基本的に両方が長期記憶へ保存されます。 しかし、今好きなのはりんごです。 梨が好きだったという過去も残したい。でも、現在の好みとしてはりんごを優先してほしい。 そこで今回は、長期記憶にも「現在値」と「履歴」を持たせることにしました。 ただし、そのためには大きな問題があります。 AIは、梨とりんごの話を「同じ記憶についての更新」だと判断できるのでしょうか。 ■記憶に住所を付ける 今回導入したのが、subject / key / value という構造です。 例えば、 subject：user key：favorite_fruit value：梨 と保存します。 subject は誰の情報か、key はどんな属性か、value はその内容です。 ここでは、user.favorite_fruit が記憶の住所になります。 次に「最近は好きな果物はりんごです」と言われたら、AIに次の情報を抽出してもらいます。 subject：user key：favorite_fruit value：りんご 同じ住所に新しい値が来ました。 そこでPythonが、 現在値をりんごに置き換え、古い梨は履歴に残す。 という処理を行います。 こうすれば、「今は何が好き？」と聞かれたらりんごを答え、「前は？」と聞かれたら梨を答えられるはずです。 ■意味を判断するのはAI、更新するのはPython この仕組みで大切にしたのが、AIとPythonの役割分担です。 Pythonには「果物という言葉があったらfavorite_fruitにする」といったルールを書きません。 それを始めると、果物、フルーツ、食べ物、好物など、表現の違いを延々と実装することになりそうです。 そこで、意味の判断はAIに任せます。 AIが行うのは、 「これは誰の、何についての情報なのか」 を考えて、住所と値を出力するところまでです。 一方、Pythonは意味を考えません。 同じ住所が存在しなければ追加。 同じ住所に同じ値があれば何もしない。 同じ住所に違う値があれば置き換える。 この3つだけです。 AIが頭脳で、Pythonが手足。 以前から考えていた役割分担を、長期記憶にも持ち込んでみました。 ■AIには既存の記憶を見せる ただし、ここで問題があります。 AIが毎回自由にkeyを作ると、同じ意味でも違う名前を付ける可能性があります。 例えば、 favorite_fruit と、 most_favorite_fruit です。 Pythonにとって、この2つは別の住所です。 意味が似ているからといって、勝手に同じものにはできません。 そこで、AIが記憶を抽出する際には、現在登録されている住所と値の一覧を見せることにしました。 すでに user.favorite_fruit = 梨 があるなら、同じ属性についての新しい発言では、そのkeyを再利用するよう指示します。 この方法でうまくいくか、試してみます。 ■MVP8を実装した 今回も、既存の長期記憶はそのまま残しました。 新しく追加したのは、 long_term_memory_state.json と、 long_term_memory_history.jsonl です。 前者には現在有効な値を保存し、後者には追加や置き換えの履歴を残します。 これまでの memories.jsonl も引き続き検索できます。 ただし古い記憶と新しい現在値が矛盾した場合は、構造化した現在値を優先するよう回答用AIに指示しました。 また、履歴を毎回全部渡すこともしません。 前回作った検索プランナーを拡張して、過去の値が必要な質問なら長期記憶の履歴を検索するようにしています。 今回の実装で、pytestは239件から351件になりました。 351件、すべて成功です。 実際のClaudeでも試しました。使用しているのはClaude Code CLI経由のOpus 5.5です。 今回の実装は、GitHubの article-10 タグで固定しました。 https://t.co/wuhsCrMg3F これまでと同じように、記事を書いた時点のコードを後から確認できるようにしています。 ■梨からりんごへ。まずは成功 最初に、 「私の好きな果物は梨です。」 と入力します。 AIは、 user.favorite_fruit = 梨 と抽出しました。 続けて、 「最近は好きな果物はりんごです。」 と入力します。 すると、同じ favorite_fruit を使って、値をりんごに変更しました。 現在の記憶は、 favorite_fruit = りんご 履歴には、 梨 → りんご が残ります。 さらに、 「好きな飲み物はコーヒーです。」 と伝えると、今度は、 favorite_drink = コーヒー という別の住所を追加しました。 果物の記憶は変更されません。 ここまでは期待どおりです。 ■再起動しても、今と昔を区別できた 一度チャットを終了して再起動します。 「今、私の好きな果物は？」 答えは、りんごでした。 「前に好きだった果物は？」 今度は履歴検索が行われ、 「以前は梨、その後りんごに変わっています」 と答えました。 さらに、従来の長期記憶側に古い「梨」という情報だけを残して試しても、構造化された現在値の「りんご」を優先しました。 同じ値をもう一度伝えても、不要な履歴は増えません。 ここまでで、現在値と履歴を分ける仕組みは動いています。 ただし、本当に確認したいのはここからです。 ■既存のkeyを見せる意味はあるのか？ 最初の実験で使った favorite_fruit は、AIにとってあまりにも自然な名前でした。 実際、既存keyを見せなくても、AIは同じ名前を作ってしまいます。 これでは、既存keyを見せた効果が分かりません。 そこで、少し違う名前を使って実験しました。 最初の記憶を、 user.home_location = 横浜 とします。 ここで、 「引っ越して、今は川崎に住んでいます。」 と入力します。 AIが考える自然なkeyは、home_location とは限りません。 そこで、既存keyを見せる場合と見せない場合で、それぞれ5回ずつ試しました。 結果は、見事に分かれました。 既存keyを見せた場合 5回中5回、home_location を再利用。 既存keyを見せなかった場合 5回中5回、residence という新しいkeyを生成。 これは面白い結果です。 既存keyを見せなかった場合、古い home_location = 横浜 が残ったまま、別の residence = 川崎 が追加されることになります。 一方、既存keyを見せれば、 home_location: 横浜 → 川崎 と正しく更新できました。 現在の記憶をAIに見せることで、次の記憶の分類が変わったのです。 もちろん、今回の1種類の発言、各5回だけで一般的な安定性まで証明できたわけではありません。 それでも、既存keyを提示する意味があることは確認できました。 ■似た情報でも、別の住所にできるのか？ さらに、 「勤務先は品川です。」 と入力しました。 ここで home_location を品川に変更されては困ります。 AIは、 work_location = 品川 という別のkeyを作りました。 現在の記憶は、 home_location = 川崎 work_location = 品川 です。 実家について聞いても、現在の住所とは別のkeyになりました。 週末だけ鎌倉で暮らしているという発言も、別のkeyになりました。 来月福岡に引っ越す予定という話では、未来の予定として扱いました。 出張で札幌にいるという話も、現在の住居を変更しませんでした。 なかなか賢いです。 これは想像以上にうまくいくかもしれない。 そう思ったところで、問題が見つかりました。 ■単身赴任で、現在の住所が消えた 次の発言です。 「単身赴任で、平日は名古屋に住んでいます。」 現在の記憶には、 home_location = 川崎 があります。 ここでAIの判断が割れました。 3回試したところ、1回は、 weekday_residence = 平日は名古屋 という別の住所を作りました。 これは期待していた方向です。 ところが残りの2回は、 home_location = 平日は名古屋 としてしまいました。 つまり、 川崎という現在の住居を、平日は名古屋という情報で上書きしたのです。 もちろん古い川崎の情報はHistoryに残っています。 データが完全に失われたわけではありません。 でもCurrentからは川崎が消えます。 これでは、ユーザーの生活状況を正しく表現できません。 ここが今回、一番興味深かったところです。 AIは、単身赴任先も「住んでいる場所」だと判断したのでしょう。 意味的には、まったく理解できない判断ではありません。 しかし、それを同じ住所として扱い、Pythonが忠実に置き換えた結果、現在の記憶が不正確になりました。 同じ属性だと判断することと、古い値を置き換えてよいことは、別の問題だったのです。 ■川崎から武蔵小杉への変更も、実は難しい もう一つ試しました。 「住んでいるのは武蔵小杉です。」 この場合、AIは3回とも home_location を再利用しました。 そして、 川崎 → 武蔵小杉 と置き換えます。 一見、正しく見えます。 でも、武蔵小杉は川崎市内です。 本当は引っ越したわけではなく、住んでいる場所を詳しく説明しただけかもしれません。 ところが現在の仕組みでは、単なる情報の詳細化も、引っ越しと同じ replace になります。 さらに、 「川崎と鎌倉の二拠点で暮らしています。」 と伝えた場合も、home_location は「川崎と鎌倉」という一つの文字列へ置き換わりました。 これでは、二つの拠点を独立した情報として扱いにくい。 記憶に一つの住所を付けて、一つの値だけを保存する。 この単純な構造の限界も見えてきました。 ■Pythonは間違えていない ここで重要なのは、Python側の処理は設計どおりだったことです。 AIが既存のkeyを出したので、Pythonはその値を置き換えました。 AIが新しいkeyを出せば、Pythonは追加します。 どちらでもない発言なら、何もしません。 Pythonは意味を判断していないので、AIが選んだkeyが適切かどうかは分かりません。 つまり今回見つかったのは、単純なプログラムのバグではありません。 AIの意味判断が間違ったとき、Pythonがその結果を確実に実行してしまう。 という設計上の問題です。 AIに判断を任せる方針は、間違っていないと思います。 でも、同じkeyだと判断したからといって、無条件に置き換えてよいわけではない。 そのことが、実験ではっきりしました。 ■小さな問題も見つかった 実験中には、ほかにも2つの問題が見つかりました。 一つは、記憶抽出の回答に余計な前置き文が付いて、JSONとして読み取れなかったことです。 今回の抽出呼び出し36回中、1回発生しました。 この場合、Pythonは更新を行わず、警告を出しました。 記憶が勝手に壊れないのは良いのですが、本来覚えるべき情報を取りこぼす可能性があります。 もう一つは、通常のチャット回答が [assistant] という見出しだけになったことです。 こちらは記憶の抽出や保存とは別の問題で、原因はまだ分かっていません。 こういう部分も含めて、実際に使いながら育てていく必要がありそうです。 ■今回分かったこと MVP8では、長期記憶に意味上の住所を付け、現在値と履歴を分離しました。 そして、AIが既存keyを参照することで、同じ情報を同じ住所へ分類できることも、限定的ながら確認できました。 これは大きな前進です。 ただし、その仕組みがうまく機能するほど、次の問題が重要になってきます。 AIが「同じ記憶だ」と判断したとき、本当に上書きしてよいのか？ 単身赴任なら、複数の住居が同時に存在します。 武蔵小杉なら、以前の情報を詳しくしただけかもしれません。 「さっきの話は間違いだった」なら、過去の記憶そのものを訂正したいはずです。 今の仕組みでは、これらを区別できません。 でも今回、何が足りないのかはかなり明確になりました。 同じkeyかどうかの判断だけでは足りない。 次は、 「新しい値に更新する」 「別の値として追加する」 「以前の情報を訂正する」 という、情報の変化そのものの意味をAIに判断させる必要がありそうです。 もちろん、その判断も間違える可能性があります。 だからこそ、Python側では状態遷移を制限し、証拠と履歴を残しておく。 最初は、AIに記憶を作らせるだけでも苦労していました。 それが今では、AI自身が記憶を分類し、検索し、更新できるところまで来ました。 そして今度は、正しく覚えようとして、間違った上書きをする。 忘れないAIを作っているつもりが、「何を同じ記憶とみなすのか」という問題にぶつかりました。 まだまだ先は長そうです。
1
1
0
0
568
arisan2026's profile image
アリさん Verified account @arisan2026
なるほど、画像での確認は書き出し前で、完成後は別のプログラムでチェックされているんですね。 こちらは完成動画から全場面を画像化して確認していたので、工程が違いました。 確かに書き出す前に確認した方が効率的ですね。 ちなみに、完成後のチェックプログラムは、どんな問題を検出するようにしているのでしょうか？ ちょっと興味があります。
1
1
0
0
19
arisan2026's profile image
アリさん Verified account @arisan2026
コメントありがとうございます！ 境界とデータの出入り、確かに重要ですね。 個々の処理が正しくても、つなぎ目で問題が起きることはありますし。 今回のHTMLでは仕様・実装・テストの対応を追えるようにしたのですが、処理の流れやデータの受け渡しまでは可視化できていません。 実は次の課題として、処理フローや関数の呼び出し関係を見えるようにしたいと考えていたところです。 人間が重点的に確認すべき場所を絞るという意味でも、参考になる視点です！
1
1
0
0
7
arisan2026's profile image
アリさん Verified account @arisan2026
【AI駆動開発やってみた】スターターキット53：AIが作ったコード、人間はどこをレビューすればいい？ AI駆動開発で、ずっと気になっていたことがあります。 AIに仕様書を書かせ、設計書を書かせ、実装させ、テストさせる。 さらに別のAIにレビューさせる。 ここまでやれば、かなりの部分をAIに任せられるようになります。 でも、最後に人間が確認するとき、何を見ればいいのでしょうか。 AIは「問題ありません」「テストはすべて成功しました」「仕様との整合性を確認しました」と報告してきます。 もちろん、それは重要な情報です。 ただ、人間がその報告を読むだけでは、人間によるレビューとは言いにくい。 だからといって、仕様書、設計書、テスト計画、ソースコード、テストコードを全部開いて、最初から読み直すのも大変です。 今回のスターターキットでは、この問題を少しでも改善するために、CP3の人間レビュー用HTMLを生成するツールを作ってみました。 ■CP3は、人間が最終的に受け入れる場所 AI駆動開発スターターキットでは、開発工程をいくつかのGateに分けています。 ・CP1：仕様の人間承認 ・G1：設計レビュー ・G2：テスト計画などのレビュー ・CP3：実装・テストのレビューと、人間による受け入れ判断 G1やG2、CP3では、AIによるレビューを行う仕組みがあります。 そして、CP3でAIのレビューがPASSしても、最終的な受け入れ判断は人間が行います。 ここが今回の問題です。 AIがPASSと判断したことは分かる。 テストが成功したことも分かる。 でも、人間が実装内容を受け入れるために必要な情報は、複数のファイルに分散しています。 スターターキットでは、もともとそれらの情報を個別の文書として保存しています。 今回は、その構造を変えるのではなく、既存の情報を人間が確認しやすい形にまとめることにしました。 ■まずは独立したHTML生成ツールにする 最初からrunnerに組み込むことはしませんでした。 今回追加したのは、次の独立したツールです。 tools/cp3_review_html.py 対象のfeatureを指定すると、CP3レビュー用のHTMLを生成します。 例えば、次のように実行します。 python tools/cp3_review_html.py --feature cli_text_masker/ascii_digit_masker --run-tests --run-tests を指定すると、対象featureのテストを実行して、その結果もHTMLに埋め込みます。 また、生成したHTMLが現在の状態と一致しているか確認する --check も用意しました。 このツール自体はAIを呼び出しません。 仕様書、設計書、テスト計画、ソースコード、テストコード、Gate記録、Gitの履歴など、既存の情報を読み取ってHTMLに変換します。 そして、生成されるHTMLは正式な資料ではありません。 あくまで、人間がレビューするための補助資料です。 ここは最初から明確にしました。 なぜなら、HTMLの生成によってGateの判定や人間の承認状態が変わってしまっては困るからです。 ■実際にどんな情報が見られるのか 完成したHTMLには、9つの章があります。 対象の状態、今回の変更、変更理由、重点確認、要求とテストの対応、コード差分、テスト結果、未解決事項、参照元です。 ただ、最初に作ったHTMLでは、これらの情報を順番に表示するだけでした。 資料としては充実しているのですが、実際に見てみると問題がありました。 人間は、結局どこから読み始めればいいのか。 そこで、画面の上部に「レビュー開始」エリアを追加しました。 そこから、次の順番でレビューを進められるようにしています。 1. 重点的に確認する箇所を見る 2. ソースコードと変更差分を見る 3. 要求とテストの対応を確認する 4. テスト結果を確認する 5. 未解決事項や残存リスクを確認する さらに、実装コードとテストコードの差分・全文にも直接移動できるようにしました。 【スクリーンショット①：レビュー開始エリア】 ※追いポストにて追加します。 画面上部に、CP3の判定、承認状況、要確認件数、テスト結果、比較基準などを表示しています。 ここから各レビュー対象に移動できます。 ■要求とテストの関係を追いかける 今回、便利だと感じたのは、要求IDを使った対応関係の表示です。 スターターキットでは、仕様書の要求に REQ-001、REQ-002 といったIDを付けています。 また、テスト計画には TV-001、TV-002 といった観点IDを付けています。 今回のツールでは、これらのIDを使い、次の情報を一つの画面で追えるようにしました。 ・仕様書の要求 ・設計書にある要求IDの記載 ・テスト計画の観点 ・実際のテスト関数 ・テストの実行結果 ・実装コード内の要求IDの記載 例えば、REQ-001を確認すると、その要求に対応するテスト観点と、実際に実行されたテスト関数が表示されます。 リンクをクリックすると、該当する文書やコードの行に移動します。 これなら、要求とテストの関係を確認するために、複数のファイルを行ったり来たりする手間を減らせそうです。 ただし、ここには重要な制限があります。 このツールが確認しているのは、IDの文字列がどこに書かれているかという事実だけです。 IDが一致しているからといって、実装が要求を満たしているとは限りません。 逆に、コード内に要求IDが書かれていなくても、その要求を満たす実装が存在する可能性があります。 だから、HTMLでもその違いが分かるようにしました。 【スクリーンショット②：要求IDとテストの対応表】 ※追いポストにて追加します。 ■機械的な検出結果は、そのまま問題とは限らない 実際にHTMLを生成してみると、面白いことが起きました。 ascii_digit_masker という小さな機能で、REQ-006がテスト計画の観点表に対応していないと検出されたのです。 REQ-006は、外部ライブラリを追加・使用しないという要求です。 確かに、テスト計画の観点表には、この要求に対応するテスト観点がありません。 でも、テスト計画書の本文には、理由が書かれていました。 外部ライブラリを使用しないことは実装上の制約なので、専用のテスト観点は作らず、実装レビューで確認するという方針です。 つまり、単純なテスト漏れではありません。 最初のHTMLでは、これが「要確認」と表示されました。 機械的な検出としては間違っていません。 ただ、そのままだと、テスト設計に問題があるようにも見えてしまいます。 そこで表示を変更しました。 テスト観点表に対応がなく、本文に説明がある場合には、「人間判断」として区別します。 そして、その説明が書かれている行へのリンクを表示します。 一方、表にも本文にも記載がない場合は、引き続き「要確認」とします。 もちろん、本文に説明があれば自動的に問題なしと判断するわけではありません。 機械が見つけた事実を示し、その意味は人間が判断する。 今回のツールでは、この区別が重要だと感じました。 ■AIの報告を、そのまま事実として扱わない もう一つ、今回こだわった点があります。 情報の出どころを区別することです。 例えば、HTMLには次のような情報が表示されます。 ・機械抽出：ファイルやGitから取得・計算した情報 ・実測：HTML生成時に実行したテストの結果 ・記録値：Gate記録に保存されている判定値 ・AI記述：AIが作成したレビュー結果などの文章 ・人間記入：人間が承認欄などに記入した内容 これらを、画面上で区別して表示します。 AIが「テストはすべて成功した」と書いていることと、今回実際にテストを実行して成功したことは、別の情報です。 また、Gate記録に「PASS」と書かれていることと、現在のソースコードが当時と同じであることも、別です。 今回は、成果物のハッシュを照合して、CP3の判定時から変更されていないかを確認する仕組みも入れました。 ただし、古いGate記録にはハッシュが残っていないものもあります。 その場合は、「判定不能」と表示します。 無理に推測して、変更なしと判断しないようにしています。 【図①：AIの報告と人間レビューの関係】 既存の情報には、それぞれ役割があります。 仕様・設計・実装・テスト・Gate記録 　↓ HTML生成ツールが機械的に整理 　↓ レビュー開始エリア 　├ 重点確認 　├ コード差分・全文 　├ 要求とテストの対応 　├ 実測テスト結果 　└ 未解決事項 　↓ 人間が内容を確認して受け入れを判断 ここで大切なのは、HTML生成ツールが最終的な合否を判断するわけではない、ということです。 ■作ってみたら、レビュー用ツール自身にも問題があった 今回の開発では、Opus 5.5に実装を依頼し、完成報告を受けてから別のAIでもコードを確認しました。 すると、いくつか気になる問題が見つかりました。 特に問題だったのが、テスト結果の扱いです。 最初の実装では、テストに失敗がなく、スキップもなければ「すべて成功」と表示する仕組みになっていました。 一見すると普通です。 ところが、pytestが異常終了して、テストケースを1件も収集できなかった場合はどうでしょう。 失敗したテストは0件。 スキップしたテストも0件。 その結果、テスト0件なのに「すべて成功しました」と表示しかねないことが分かりました。 これは人間のレビューを支援するツールとしては困ります。 そこで、pytestの終了コードも確認するように修正しました。 正常終了していること、少なくとも1件のテストケースがあること、失敗などがないことを確認して、初めて全件成功と表示します。 ほかにも、CP3以外のGate記録を指定できてしまう問題や、生成HTMLの本文が変更されても --check が見逃す問題などが見つかりました。 これらも修正しました。 そして、修正内容が将来壊れないように、回帰テストを追加しました。 AIのレビューを助けるためのツールをAIが作り、そのツールをさらにレビューする。 なんともAI駆動開発らしい作業になりました。 ■最終的には310件のテストが通過 今回の実装で追加したファイルは、次の2つです。 tools/cp3_review_html.py tests/tools/test_cp3_review_html.py 最終的なコード量は、合わせて約3,000行。 テストは、このツールだけで59件になりました。 既存の251件と合わせて、310件のテストがPASSしています。 ただし、テストには少し環境上の問題が残っています。 Windows環境で通常の python -m pytest を実行すると、pytestの一時ディレクトリに対するPermissionErrorが発生しました。 一時ディレクトリを明示する --basetemp を指定すると、全310件が通過しています。 今回のHTML生成ツールからテストを実行する場合も、専用の一時ディレクトリを使うようにしました。 通常実行で発生する環境問題そのものは、今回の対応範囲から外しています。 また、HTMLの生成前後でGate記録、承認状態、仕様書、設計書、実装、テストが変わらないことも確認しました。 最後にEdgeでリンクの移動確認を行い、主要な17件のリンクが正しい場所に移動することも確認しています。 なお、これらのテスト実行やEdgeでの確認は、開発を担当したOpusの報告によるものです。 ■でも、ソースコードレビューの支援としては、まだ足りない ここまで作って、一つ気づいたことがあります。 最初は「人間レビュー用のHTMLを作りたい」と考えていました。 そして、仕様、設計、テスト、Gate記録の情報を集めれば、レビューしやすくなるだろうと思っていました。 実際、今回のツールによって、必要な資料を探す手間は減らせそうです。 変更前の状態を特定できる場合には、前回のCP3 PASSからの差分も表示できます。 ただ、ソースコードレビューそのものを助けるという意味では、まだ足りません。 例えば、次のような情報です。 ・処理の流れを図で確認したい ・関数の呼び出し関係を把握したい ・変更されたコードが、ほかの処理に影響しないか確認したい ・どのロジックを重点的に読むべきか知りたい 今回のツールには、そこまでの機能はありません。 現場から聞いた要望も、もしかすると、こちらに近いものだったのかもしれません。 レビューに必要な情報を集めることと、ソースコードをレビューしやすくすることは、同じではない。 今回の開発で分かったことの一つです。 処理フローや呼び出しツリーの生成は、別の仕組みとして検討したいと思っています。 ■今回はいったんMVPとして完成 とはいえ、今回の成果は無駄ではありません。 AIのレビュー結果を読み直すだけだった状態から、実際の仕様書、コード、テスト結果を確認するための入口ができました。 しかも、AIの記述と、機械的に確認した事実を区別しています。 今後、ソースコードの可視化ツールができれば、今回のHTMLからそこへ移動できるようにすることも考えられます。 まずは今回のMVPを確定し、実際の現場でどこまで役立つか試してみたいと思います。 そして、人間のレビューが楽になるかどうかは、実際に使ってみなければ分かりません。 今回のゴールは、AIが作ったコードを自動的に正しいと認定することではありません。 人間が自分で確認し、判断するための負担を減らすこと。 そこに向けた最初の一歩になればと思っています。 ■今回のソースコード GitHubのAI駆動開発スターターキットに反映済みです。 リポジトリ： https://t.co/F7TvyhDjGT 今回のMVPを保存したタグ： https://t.co/HWi4U0zjDu 今回のタグを使えば、後からツールを改良しても、記事で紹介した時点の実装を参照できます。 なお、生成されたHTMLは、Gitの管理対象外としています。生成結果そのものではなく、生成するツールとテストを公開しています。 ※この記事は、個人で進めているAI駆動開発スターターキットの開発記録です。特定の開発手法の正解を示すものではなく、試して分かったことを残しています。
arisan2026's tweet photo. 【AI駆動開発やってみた】スターターキット53：AIが作ったコード、人間はどこをレビューすればいい？ AI駆動開発で、ずっと気になっていたことがあります。 AIに仕様書を書かせ、設計書を書かせ、実装させ、テストさせる。 さらに別のAIにレビューさせる。 ここまでやれば、かなりの部分をAIに任せられるようになります。 でも、最後に人間が確認するとき、何を見ればいいのでしょうか。 AIは「問題ありません」「テストはすべて成功しました」「仕様との整合性を確認しました」と報告してきます。 もちろん、それは重要な情報です。 ただ、人間がその報告を読むだけでは、人間によるレビューとは言いにくい。 だからといって、仕様書、設計書、テスト計画、ソースコード、テストコードを全部開いて、最初から読み直すのも大変です。 今回のスターターキットでは、この問題を少しでも改善するために、CP3の人間レビュー用HTMLを生成するツールを作ってみました。 ■CP3は、人間が最終的に受け入れる場所 AI駆動開発スターターキットでは、開発工程をいくつかのGateに分けています。 ・CP1：仕様の人間承認 ・G1：設計レビュー ・G2：テスト計画などのレビュー ・CP3：実装・テストのレビューと、人間による受け入れ判断 G1やG2、CP3では、AIによるレビューを行う仕組みがあります。 そして、CP3でAIのレビューがPASSしても、最終的な受け入れ判断は人間が行います。 ここが今回の問題です。 AIがPASSと判断したことは分かる。 テストが成功したことも分かる。 でも、人間が実装内容を受け入れるために必要な情報は、複数のファイルに分散しています。 スターターキットでは、もともとそれらの情報を個別の文書として保存しています。 今回は、その構造を変えるのではなく、既存の情報を人間が確認しやすい形にまとめることにしました。 ■まずは独立したHTML生成ツールにする 最初からrunnerに組み込むことはしませんでした。 今回追加したのは、次の独立したツールです。 tools/cp3_review_html.py 対象のfeatureを指定すると、CP3レビュー用のHTMLを生成します。 例えば、次のように実行します。 python tools/cp3_review_html.py --feature cli_text_masker/ascii_digit_masker --run-tests --run-tests を指定すると、対象featureのテストを実行して、その結果もHTMLに埋め込みます。 また、生成したHTMLが現在の状態と一致しているか確認する --check も用意しました。 このツール自体はAIを呼び出しません。 仕様書、設計書、テスト計画、ソースコード、テストコード、Gate記録、Gitの履歴など、既存の情報を読み取ってHTMLに変換します。 そして、生成されるHTMLは正式な資料ではありません。 あくまで、人間がレビューするための補助資料です。 ここは最初から明確にしました。 なぜなら、HTMLの生成によってGateの判定や人間の承認状態が変わってしまっては困るからです。 ■実際にどんな情報が見られるのか 完成したHTMLには、9つの章があります。 対象の状態、今回の変更、変更理由、重点確認、要求とテストの対応、コード差分、テスト結果、未解決事項、参照元です。 ただ、最初に作ったHTMLでは、これらの情報を順番に表示するだけでした。 資料としては充実しているのですが、実際に見てみると問題がありました。 人間は、結局どこから読み始めればいいのか。 そこで、画面の上部に「レビュー開始」エリアを追加しました。 そこから、次の順番でレビューを進められるようにしています。 1. 重点的に確認する箇所を見る 2. ソースコードと変更差分を見る 3. 要求とテストの対応を確認する 4. テスト結果を確認する 5. 未解決事項や残存リスクを確認する さらに、実装コードとテストコードの差分・全文にも直接移動できるようにしました。 【スクリーンショット①：レビュー開始エリア】 ※追いポストにて追加します。 画面上部に、CP3の判定、承認状況、要確認件数、テスト結果、比較基準などを表示しています。 ここから各レビュー対象に移動できます。 ■要求とテストの関係を追いかける 今回、便利だと感じたのは、要求IDを使った対応関係の表示です。 スターターキットでは、仕様書の要求に REQ-001、REQ-002 といったIDを付けています。 また、テスト計画には TV-001、TV-002 といった観点IDを付けています。 今回のツールでは、これらのIDを使い、次の情報を一つの画面で追えるようにしました。 ・仕様書の要求 ・設計書にある要求IDの記載 ・テスト計画の観点 ・実際のテスト関数 ・テストの実行結果 ・実装コード内の要求IDの記載 例えば、REQ-001を確認すると、その要求に対応するテスト観点と、実際に実行されたテスト関数が表示されます。 リンクをクリックすると、該当する文書やコードの行に移動します。 これなら、要求とテストの関係を確認するために、複数のファイルを行ったり来たりする手間を減らせそうです。 ただし、ここには重要な制限があります。 このツールが確認しているのは、IDの文字列がどこに書かれているかという事実だけです。 IDが一致しているからといって、実装が要求を満たしているとは限りません。 逆に、コード内に要求IDが書かれていなくても、その要求を満たす実装が存在する可能性があります。 だから、HTMLでもその違いが分かるようにしました。 【スクリーンショット②：要求IDとテストの対応表】 ※追いポストにて追加します。 ■機械的な検出結果は、そのまま問題とは限らない 実際にHTMLを生成してみると、面白いことが起きました。 ascii_digit_masker という小さな機能で、REQ-006がテスト計画の観点表に対応していないと検出されたのです。 REQ-006は、外部ライブラリを追加・使用しないという要求です。 確かに、テスト計画の観点表には、この要求に対応するテスト観点がありません。 でも、テスト計画書の本文には、理由が書かれていました。 外部ライブラリを使用しないことは実装上の制約なので、専用のテスト観点は作らず、実装レビューで確認するという方針です。 つまり、単純なテスト漏れではありません。 最初のHTMLでは、これが「要確認」と表示されました。 機械的な検出としては間違っていません。 ただ、そのままだと、テスト設計に問題があるようにも見えてしまいます。 そこで表示を変更しました。 テスト観点表に対応がなく、本文に説明がある場合には、「人間判断」として区別します。 そして、その説明が書かれている行へのリンクを表示します。 一方、表にも本文にも記載がない場合は、引き続き「要確認」とします。 もちろん、本文に説明があれば自動的に問題なしと判断するわけではありません。 機械が見つけた事実を示し、その意味は人間が判断する。 今回のツールでは、この区別が重要だと感じました。 ■AIの報告を、そのまま事実として扱わない もう一つ、今回こだわった点があります。 情報の出どころを区別することです。 例えば、HTMLには次のような情報が表示されます。 ・機械抽出：ファイルやGitから取得・計算した情報 ・実測：HTML生成時に実行したテストの結果 ・記録値：Gate記録に保存されている判定値 ・AI記述：AIが作成したレビュー結果などの文章 ・人間記入：人間が承認欄などに記入した内容 これらを、画面上で区別して表示します。 AIが「テストはすべて成功した」と書いていることと、今回実際にテストを実行して成功したことは、別の情報です。 また、Gate記録に「PASS」と書かれていることと、現在のソースコードが当時と同じであることも、別です。 今回は、成果物のハッシュを照合して、CP3の判定時から変更されていないかを確認する仕組みも入れました。 ただし、古いGate記録にはハッシュが残っていないものもあります。 その場合は、「判定不能」と表示します。 無理に推測して、変更なしと判断しないようにしています。 【図①：AIの報告と人間レビューの関係】 既存の情報には、それぞれ役割があります。 仕様・設計・実装・テスト・Gate記録 　↓ HTML生成ツールが機械的に整理 　↓ レビュー開始エリア 　├ 重点確認 　├ コード差分・全文 　├ 要求とテストの対応 　├ 実測テスト結果 　└ 未解決事項 　↓ 人間が内容を確認して受け入れを判断 ここで大切なのは、HTML生成ツールが最終的な合否を判断するわけではない、ということです。 ■作ってみたら、レビュー用ツール自身にも問題があった 今回の開発では、Opus 5.5に実装を依頼し、完成報告を受けてから別のAIでもコードを確認しました。 すると、いくつか気になる問題が見つかりました。 特に問題だったのが、テスト結果の扱いです。 最初の実装では、テストに失敗がなく、スキップもなければ「すべて成功」と表示する仕組みになっていました。 一見すると普通です。 ところが、pytestが異常終了して、テストケースを1件も収集できなかった場合はどうでしょう。 失敗したテストは0件。 スキップしたテストも0件。 その結果、テスト0件なのに「すべて成功しました」と表示しかねないことが分かりました。 これは人間のレビューを支援するツールとしては困ります。 そこで、pytestの終了コードも確認するように修正しました。 正常終了していること、少なくとも1件のテストケースがあること、失敗などがないことを確認して、初めて全件成功と表示します。 ほかにも、CP3以外のGate記録を指定できてしまう問題や、生成HTMLの本文が変更されても --check が見逃す問題などが見つかりました。 これらも修正しました。 そして、修正内容が将来壊れないように、回帰テストを追加しました。 AIのレビューを助けるためのツールをAIが作り、そのツールをさらにレビューする。 なんともAI駆動開発らしい作業になりました。 ■最終的には310件のテストが通過 今回の実装で追加したファイルは、次の2つです。 tools/cp3_review_html.py tests/tools/test_cp3_review_html.py 最終的なコード量は、合わせて約3,000行。 テストは、このツールだけで59件になりました。 既存の251件と合わせて、310件のテストがPASSしています。 ただし、テストには少し環境上の問題が残っています。 Windows環境で通常の python -m pytest を実行すると、pytestの一時ディレクトリに対するPermissionErrorが発生しました。 一時ディレクトリを明示する --basetemp を指定すると、全310件が通過しています。 今回のHTML生成ツールからテストを実行する場合も、専用の一時ディレクトリを使うようにしました。 通常実行で発生する環境問題そのものは、今回の対応範囲から外しています。 また、HTMLの生成前後でGate記録、承認状態、仕様書、設計書、実装、テストが変わらないことも確認しました。 最後にEdgeでリンクの移動確認を行い、主要な17件のリンクが正しい場所に移動することも確認しています。 なお、これらのテスト実行やEdgeでの確認は、開発を担当したOpusの報告によるものです。 ■でも、ソースコードレビューの支援としては、まだ足りない ここまで作って、一つ気づいたことがあります。 最初は「人間レビュー用のHTMLを作りたい」と考えていました。 そして、仕様、設計、テスト、Gate記録の情報を集めれば、レビューしやすくなるだろうと思っていました。 実際、今回のツールによって、必要な資料を探す手間は減らせそうです。 変更前の状態を特定できる場合には、前回のCP3 PASSからの差分も表示できます。 ただ、ソースコードレビューそのものを助けるという意味では、まだ足りません。 例えば、次のような情報です。 ・処理の流れを図で確認したい ・関数の呼び出し関係を把握したい ・変更されたコードが、ほかの処理に影響しないか確認したい ・どのロジックを重点的に読むべきか知りたい 今回のツールには、そこまでの機能はありません。 現場から聞いた要望も、もしかすると、こちらに近いものだったのかもしれません。 レビューに必要な情報を集めることと、ソースコードをレビューしやすくすることは、同じではない。 今回の開発で分かったことの一つです。 処理フローや呼び出しツリーの生成は、別の仕組みとして検討したいと思っています。 ■今回はいったんMVPとして完成 とはいえ、今回の成果は無駄ではありません。 AIのレビュー結果を読み直すだけだった状態から、実際の仕様書、コード、テスト結果を確認するための入口ができました。 しかも、AIの記述と、機械的に確認した事実を区別しています。 今後、ソースコードの可視化ツールができれば、今回のHTMLからそこへ移動できるようにすることも考えられます。 まずは今回のMVPを確定し、実際の現場でどこまで役立つか試してみたいと思います。 そして、人間のレビューが楽になるかどうかは、実際に使ってみなければ分かりません。 今回のゴールは、AIが作ったコードを自動的に正しいと認定することではありません。 人間が自分で確認し、判断するための負担を減らすこと。 そこに向けた最初の一歩になればと思っています。 ■今回のソースコード GitHubのAI駆動開発スターターキットに反映済みです。 リポジトリ： https://t.co/F7TvyhDjGT 今回のMVPを保存したタグ： https://t.co/HWi4U0zjDu 今回のタグを使えば、後からツールを改良しても、記事で紹介した時点の実装を参照できます。 なお、生成されたHTMLは、Gitの管理対象外としています。生成結果そのものではなく、生成するツールとテストを公開しています。 ※この記事は、個人で進めているAI駆動開発スターターキットの開発記録です。特定の開発手法の正解を示すものではなく、試して分かったことを残しています。
2
2
0
0
453
arisan2026's profile image
アリさん Verified account @arisan2026
【AI実験室 #6】Haiku 4.5と5.5に20回コーディングさせた。速さの理由はツール操作の回数ではなかった 前回は、Haiku 4.5とHaiku 5.5に長い文章を読ませて比較しました。 結果は、予想していたほど単純ではありませんでした。 5.5の方が進化していることは感じられるものの、何がどれだけ良くなったのか、なかなかつかみにくい。 そもそも、AIの能力をどう測ればよいのでしょうか。 AIメーカーは新しいモデルを発表するたびに、さまざまなベンチマークの数値を公表しています。 でも、その数値が良くなったからといって、自分が普段使っているAIも同じように進化したと感じられるのでしょうか。 今回は少し方向を変えて、AIに実際のプログラム開発を任せてみることにしました。 比較するのは、Claude Haiku 4.5とHaiku 5.5です。 同じ課題を与え、実際にソースコードを読み、修正し、テストを実行してもらいます。 しかも、1回だけではありません。 最終的に、両モデル合わせて20回実行しました。 その結果、思っていたのとは少し違うところに、大きな差が見つかりました。 ■AIにプログラムを作らせて比較する 今回用意したのは、2種類のPythonプログラムです。 1つ目は parcel_manifest。 荷物のデータを読み取り、必要な情報を整理し、料金などを計算するプログラムです。 2つ目は room_booking。 部屋の予約について、日時や空き状況などを扱うプログラムです。 どちらも、1つの関数を作るだけでは終わりません。 複数のソースファイルを調査し、必要なファイルを書き換え、テストを実行する必要があります。 AIには、次の4種類のツールだけを使わせました。 ・ファイル一覧を取得する ・ファイルを読み込む ・ファイルを書き込む ・公開テストを実行する これらは専用のMCPツールとして用意しました。 普段のClaude Codeが使うさまざまな操作手段は、そのままでは利用できない構成です。 また、AIが見られる公開テストとは別に、AIには見せない非公開テストを用意しました。 公開テストを通過しただけでは、完全成功とはしません。 非公開テストもすべて通過して初めて、完全成功です。 実行環境はDockerで隔離し、課題やプロンプト、テストなど44ファイルのハッシュを事前に固定しました。 実験の途中で課題を簡単にしたり、結果に合わせてテストを変更したりすることはありません。 ■比較する設定は同じではない 今回比較したのは、次の2つです。 Haiku 4.5：default Haiku 5.5：medium ここは重要です。 Haiku 5.5には、思考の強さを調整するeffort設定があります。 今回は、その中のmediumを使いました。 4.5はdefaultのままです。 つまり、厳密にはモデルだけを変更した比較ではなく、4.5 defaultと5.5 mediumという、2つの実用設定を比較した実験です。 後で重要になるので、先に書いておきます。 ■最初の4回は、全部成功してしまった まず、2課題を両モデルで1回ずつ、合計4回実行しました。 結果は、なんと全件成功です。 parcel_manifest は、どちらも非公開テスト8件すべて合格。 room_booking も、どちらも10件すべて合格。 あれ？ これでは、どちらが賢いのか分かりません。 ただし、実行時間には大きな違いがありました。 parcel_manifest は、 Haiku 4.5が27.637秒。 Haiku 5.5が16.183秒。 room_booking は、 Haiku 4.5が56.818秒。 Haiku 5.5が15.285秒。 5.5は、どちらの課題でも圧倒的に短時間で終わりました。 特に後者は約3.7倍もの差があります。 とはいえ、たった1回の実験です。 AIの回答や行動は毎回同じになるとは限りません。 たまたま4.5が時間のかかる手順を選んだだけかもしれません。 そこで、同じ条件でさらに繰り返してみることにしました。 ■追加16回。合計20回やってみた 4つの条件を、それぞれ5回ずつ実行しました。 追加した16回は、すべて新しい作業環境と新しいClaudeのセッションから開始しています。 前の試行で作ったソースコードを引き継ぐことも、実験結果をAIに見せることもありません。 実行する順番も、特定のモデルが常に先にならないよう調整しました。 では、結果です。 parcel_manifest Haiku 4.5 default ・完全成功：4回／5回 ・実行時間中央値：29.757秒 ・最速27.637秒、最遅30.084秒 Haiku 5.5 medium ・完全成功：5回／5回 ・実行時間中央値：16.183秒 ・最速15.249秒、最遅17.577秒 room_booking Haiku 4.5 default ・完全成功：5回／5回 ・実行時間中央値：50.544秒 ・最速47.799秒、最遅83.841秒 Haiku 5.5 medium ・完全成功：5回／5回 ・実行時間中央値：18.831秒 ・最速15.285秒、最遅23.730秒 かなりはっきりした結果になりました。 実行時間の中央値で比較すると、5.5は parcel_manifest で約1.84倍、room_booking で約2.68倍の速度です。 さらに驚いたのは、どちらの課題でも、5.5の最も遅い実行が、4.5の最も速い実行より短かったことです。 少なくとも今回の20試行では、5.5の方が一貫して短時間で作業を終えました。 たった1回の偶然ではなく、5回繰り返しても速度差が確認できたのです。 ただし、これは実際のCLI実行時間の比較です。モデルそのものの計算性能だけを測定しているわけではありません。 ■4.5が1回だけ失敗した 成功率にも、わずかな違いがありました。 parcel_manifest で、Haiku 4.5が5回中1回失敗しています。 失敗した試行でも、公開テストは2件とも合格していました。 ところが、非公開テストでは8件中7件しか通過できませんでした。 調べると、識別子の大文字・小文字と、最初に登場した順番を扱う境界条件で、仕様と異なる結果を出していました。 実行環境の異常ではありません。 AIが作ったプログラムが、仕様を完全には満たしていなかったのです。 一方、Haiku 5.5は5回とも8件すべてに合格しました。 とはいえ、4回成功と5回成功の差だけで、5.5の方が安定して正しいプログラムを作れるとは断定できません。 試行回数がまだ少ないからです。 また、room_booking は両モデルとも5回すべて成功しています。 こちらでは品質の差を検出できませんでした。 両方とも正解できる課題では、能力の優劣が見えにくい。 最初に感じていた疑問が、ここでも出てきました。 ■速いのは、ツール操作が上手になったから？ ここからが今回の本題です。 Haiku 5.5は、なぜこんなに速いのでしょうか。 最近のAIの進化は、単純な推論能力だけではなく、ツールを利用して仕事を進める能力にも向かっているように感じています。 例えば、必要なファイルを効率よく探す。 不要な操作を減らす。 テストの失敗を読み取って、適切な修正をする。 そういう能力が向上した結果、速くなったのではないでしょうか。 そこで、ツールの実行回数を調べてみました。 結果は、ちょっと意外でした。 parcel_manifest では、両モデルとも1試行あたり10回。 5回の合計は、それぞれ50回です。 内訳も同じでした。 ファイル一覧5回、ファイル読取25回、ファイル書込15回、公開テスト5回。 まったく同じ回数です。 では、room_booking はどうでしょうか。 Haiku 4.5が5回合計55回。 Haiku 5.5が50回。 違いは公開テストの回数でした。 4.5は毎回、まだ修正していないプログラムに対して公開テストを実行し、失敗を確認してから実装していました。 5.5は先に修正し、その後に公開テストを実行していました。 ただし、4.5が失敗した実装を何度も修正していたわけではありません。 今回の20試行では、編集後の公開テスト失敗と、それを受けた再修正は一度も発生していません。 つまり、5.5はツール操作を劇的に減らしたから速い、というわけではなかったのです。 もちろん、今回の課題では操作手順が比較的決まっているため、複雑なツール選択能力まで比較できたわけではありません。 それでも、ツール操作の回数だけでは今回の速度差を説明できなさそうです。 ■Thinkingの量を見たら、もっと驚いた 次に、AIがどれだけThinkingトークンを使ったのか調べてみました。 Thinkingは、モデルが推論のために生成するトークンです。 これが多ければ必ず賢いというものではありませんが、処理にどれだけのトークンを使っているかを見る手がかりになります。 5回の中央値を比較します。 parcel_manifest Haiku 4.5：1,839トークン Haiku 5.5：383トークン room_booking Haiku 4.5：3,949トークン Haiku 5.5：614トークン なんと、5.5はThinkingトークンを約79〜84％も減らしています。 一方、Thinking以外の出力はどうでしょう。 試行ごとに「総出力トークン − Thinkingトークン」を計算して、中央値を求めました。 parcel_manifest では、 4.5が1,362トークン。 5.5が1,698トークン。 room_booking では、 4.5が1,709トークン。 5.5が2,134トークン。 Thinking以外の出力は、むしろ5.5の方が多かったのです。 これは興味深い。 AIが単に出力を短くして、仕事を省略していたわけではありません。 ファイルを読み、修正し、テストを実行するという作業をこなしながら、Thinkingの量を大幅に減らしていました。 もしかすると、今回の進化は、 同じ仕事を、以前ほど長く考えずにこなせるようになったこと なのかもしれません。 ただし、Thinkingトークン数はAIの知能を直接測る値ではありません。モデルごとの推論の仕組みやeffort設定の影響も受けます。 今回の結果だけで、内部の推論効率が何倍になったと結論づけることはできません。 それでも、実際の仕事量と生成トークンの関係が大きく変わったことは確認できました。 ■料金も大きく違った せっかくなので、料金も計算してみました。 ただし、今回の実験にはClaude Proの認証を使用しています。 ここでいう費用は、APIを使った場合の料金に換算した金額です。実際にこの金額がAPI料金として請求されたわけではありません。 5回の中央値は次のとおりでした。 parcel_manifest 4.5：約0.0287ドル 5.5：約0.00161ドル room_booking 4.5：約0.0589ドル 5.5：約0.00251ドル それぞれ約17.8倍、23.5倍の差があります。 ただし、ここは注意が必要です。 Anthropic公式の基本料金では、今回の10万トークン以下の価格帯で、Haiku 5.5の入出力単価は4.5の10分の1です。 つまり、料金差の大部分には、そもそものモデル単価の違いが含まれています。 その単価差を取り除いて、使用量による違いを同一料金体系に換算すると、約1.78倍と2.35倍です。 こちらにも、使用量の違いが現れています。 なお、キャッシュの利用状況にも違いがあり、初回と後続の試行ではキャッシュ書き込み量が変化しています。 そのため、料金差や実行時間のすべてをThinkingだけで説明することはできません。 ■そもそもAIメーカーは、どうやって優劣を決めているのか？ 今回の実験をしていて、昔から疑問に思っていたことを改めて考えました。 AIメーカーは、どうやってモデル同士の優劣をつけているのでしょうか。 例えば、今回の room_booking は、両モデルとも5回すべて非公開テストに合格しています。 正解率だけなら同点です。 でも実行時間には2倍以上の差があります。 では、5.5の方が賢いのでしょうか。 それとも、単に効率が良いのでしょうか。 また、今回の課題が簡単すぎて、両モデルの能力の限界が見えなかっただけかもしれません。 Anthropicは、Haiku 5.5の発表で、コーディング、PC操作、推論など複数のベンチマークを示しています。 公式に公開されているTerminal-Bench 4.0の成績は、Haiku 4.5が0.0％、Haiku 5.5が39.2％、参考としてSonnet 5.5が70.6％です。 こちらでは、かなり大きな差が出ています。 一方、私の実験では、Haiku 4.5ですら2課題10試行中9回成功しました。 当然、同じ難易度の問題を解いているわけではありません。 さらに、公式ベンチマークと今回の実験では、Thinkingやeffortなどの実行条件も異なります。 単純に数値を比較することはできません。 つまり、モデルの能力差を測ろうと思ったら、その能力差が現れる課題を用意しなければならないということです。 これは案外難しいことなのかもしれません。 そして、正解率だけでなく、速度、費用、安定性、ツール利用などを組み合わせて評価する必要もありそうです。 ■では、effortをmaxにしたらどうなる？ ここで、もう一つ疑問が出てきました。 今回、Haiku 5.5はmediumで実行しています。 では、maxにしたら、もっと賢くなるのでしょうか。 Anthropicも、Haiku 5.5についてeffort設定ごとの性能とコストの関係を公開しています。 つまり、思考の強さは、モデルの実力を評価するうえで無視できない条件です。 ただ、私には気になることがあります。 maxは、とにかく遅い。 普段の開発でmaxを使うと、考えている時間が長すぎて、作業のテンポが悪くなることがあります。 難しい問題を解くためには有効なのかもしれません。 でも、mediumでも正しくできる仕事に、毎回maxを使う必要があるのでしょうか。 仮に、mediumで10秒の仕事がmaxで1分になったとして、それによって品質がどれだけ向上するのか。 そこを知りたいのです。 さらに、maxにすれば必ず結果が良くなる、と決まっているわけでもありません。 たくさん考えることが、かえって余計な修正や時間の浪費につながる可能性もあります。 ただ、現時点では何とも言えません。 今回の実験ではmaxを一度も使っていないからです。 今後、さまざまな課題でHaiku 5.5を試し、どんなときに失敗するのか、どこに能力の限界があるのかを探っていきたいと思います。 そのうえで、最後の方にmaxを投入してみたい。 mediumでは解けない問題が、maxなら解けるのか。 それとも、単に時間とトークンをたくさん消費するだけなのか。 できればSonnetとも比較してみたいですね。 Haiku 5.5のmaxとSonnetのmediumでは、どちらが実用的なのか。 そこまで行くと、単純なモデル比較とはまた違った面白さがありそうです。 ■今回分かったこと、まだ分からないこと 20回の実験で、Haiku 5.5の進化が少し見えてきました。 今回の固定条件では、5.5は4.5より明確に速く動きました。 しかも、ファイルを読む回数や修正する回数は、ほとんど変わりませんでした。 大きく減っていたのはThinkingトークンです。 そして、品質は両モデルとも高い水準でしたが、4.5には1回だけ非公開テストの失敗がありました。 ここから言えるのは、少なくとも今回の課題では、Haiku 5.5は、より少ないThinkingで同じような開発作業をこなしていたということです。 一方で、それがモデル自体の推論能力の向上なのか、effort設定や実行環境の違いによる部分がどれだけあるのかは、まだ分かりません。 Sonnetを超えるほど賢くなったのかどうかも、今回の実験では判断できません。 むしろ、課題の方が簡単すぎた可能性があります。 次は、モデルの能力差が現れるような、もう少し難しい開発課題を試してみたいと思います。 特に、公開テストは通るのに仕様の境界で失敗する問題や、一度間違えた実装をどう修正するか、といったところです。 そして、いろいろな能力が見えてきた最後に、 「maxで長く考えることには、本当に意味があるのか？」 という疑問にも取り組んでみたいと思っています。 AIは、賢くなったのか。 それとも、同じことを効率よくできるようになったのか。 その違いを、もう少し追いかけてみたいですね。 参考資料 Anthropic：Claude Haiku 5.5 公式発表 https://t.co/Sc225YpaFF Anthropic：Claude API料金表 https://t.co/S8R7Dn0KaG 今回の実験では、課題とプロンプト、実行環境を固定し、全20試行のトークン数・実行時間・ツール操作・テスト結果を記録しています。実行条件はHaiku 4.5 defaultとHaiku 5.5 mediumであり、同一effortでのモデル単体比較ではありません。
arisan2026's tweet photo. 【AI実験室 #6】Haiku 4.5と5.5に20回コーディングさせた。速さの理由はツール操作の回数ではなかった 前回は、Haiku 4.5とHaiku 5.5に長い文章を読ませて比較しました。 結果は、予想していたほど単純ではありませんでした。 5.5の方が進化していることは感じられるものの、何がどれだけ良くなったのか、なかなかつかみにくい。 そもそも、AIの能力をどう測ればよいのでしょうか。 AIメーカーは新しいモデルを発表するたびに、さまざまなベンチマークの数値を公表しています。 でも、その数値が良くなったからといって、自分が普段使っているAIも同じように進化したと感じられるのでしょうか。 今回は少し方向を変えて、AIに実際のプログラム開発を任せてみることにしました。 比較するのは、Claude Haiku 4.5とHaiku 5.5です。 同じ課題を与え、実際にソースコードを読み、修正し、テストを実行してもらいます。 しかも、1回だけではありません。 最終的に、両モデル合わせて20回実行しました。 その結果、思っていたのとは少し違うところに、大きな差が見つかりました。 ■AIにプログラムを作らせて比較する 今回用意したのは、2種類のPythonプログラムです。 1つ目は parcel_manifest。 荷物のデータを読み取り、必要な情報を整理し、料金などを計算するプログラムです。 2つ目は room_booking。 部屋の予約について、日時や空き状況などを扱うプログラムです。 どちらも、1つの関数を作るだけでは終わりません。 複数のソースファイルを調査し、必要なファイルを書き換え、テストを実行する必要があります。 AIには、次の4種類のツールだけを使わせました。 ・ファイル一覧を取得する ・ファイルを読み込む ・ファイルを書き込む ・公開テストを実行する これらは専用のMCPツールとして用意しました。 普段のClaude Codeが使うさまざまな操作手段は、そのままでは利用できない構成です。 また、AIが見られる公開テストとは別に、AIには見せない非公開テストを用意しました。 公開テストを通過しただけでは、完全成功とはしません。 非公開テストもすべて通過して初めて、完全成功です。 実行環境はDockerで隔離し、課題やプロンプト、テストなど44ファイルのハッシュを事前に固定しました。 実験の途中で課題を簡単にしたり、結果に合わせてテストを変更したりすることはありません。 ■比較する設定は同じではない 今回比較したのは、次の2つです。 Haiku 4.5：default Haiku 5.5：medium ここは重要です。 Haiku 5.5には、思考の強さを調整するeffort設定があります。 今回は、その中のmediumを使いました。 4.5はdefaultのままです。 つまり、厳密にはモデルだけを変更した比較ではなく、4.5 defaultと5.5 mediumという、2つの実用設定を比較した実験です。 後で重要になるので、先に書いておきます。 ■最初の4回は、全部成功してしまった まず、2課題を両モデルで1回ずつ、合計4回実行しました。 結果は、なんと全件成功です。 parcel_manifest は、どちらも非公開テスト8件すべて合格。 room_booking も、どちらも10件すべて合格。 あれ？ これでは、どちらが賢いのか分かりません。 ただし、実行時間には大きな違いがありました。 parcel_manifest は、 Haiku 4.5が27.637秒。 Haiku 5.5が16.183秒。 room_booking は、 Haiku 4.5が56.818秒。 Haiku 5.5が15.285秒。 5.5は、どちらの課題でも圧倒的に短時間で終わりました。 特に後者は約3.7倍もの差があります。 とはいえ、たった1回の実験です。 AIの回答や行動は毎回同じになるとは限りません。 たまたま4.5が時間のかかる手順を選んだだけかもしれません。 そこで、同じ条件でさらに繰り返してみることにしました。 ■追加16回。合計20回やってみた 4つの条件を、それぞれ5回ずつ実行しました。 追加した16回は、すべて新しい作業環境と新しいClaudeのセッションから開始しています。 前の試行で作ったソースコードを引き継ぐことも、実験結果をAIに見せることもありません。 実行する順番も、特定のモデルが常に先にならないよう調整しました。 では、結果です。 parcel_manifest Haiku 4.5 default ・完全成功：4回／5回 ・実行時間中央値：29.757秒 ・最速27.637秒、最遅30.084秒 Haiku 5.5 medium ・完全成功：5回／5回 ・実行時間中央値：16.183秒 ・最速15.249秒、最遅17.577秒 room_booking Haiku 4.5 default ・完全成功：5回／5回 ・実行時間中央値：50.544秒 ・最速47.799秒、最遅83.841秒 Haiku 5.5 medium ・完全成功：5回／5回 ・実行時間中央値：18.831秒 ・最速15.285秒、最遅23.730秒 かなりはっきりした結果になりました。 実行時間の中央値で比較すると、5.5は parcel_manifest で約1.84倍、room_booking で約2.68倍の速度です。 さらに驚いたのは、どちらの課題でも、5.5の最も遅い実行が、4.5の最も速い実行より短かったことです。 少なくとも今回の20試行では、5.5の方が一貫して短時間で作業を終えました。 たった1回の偶然ではなく、5回繰り返しても速度差が確認できたのです。 ただし、これは実際のCLI実行時間の比較です。モデルそのものの計算性能だけを測定しているわけではありません。 ■4.5が1回だけ失敗した 成功率にも、わずかな違いがありました。 parcel_manifest で、Haiku 4.5が5回中1回失敗しています。 失敗した試行でも、公開テストは2件とも合格していました。 ところが、非公開テストでは8件中7件しか通過できませんでした。 調べると、識別子の大文字・小文字と、最初に登場した順番を扱う境界条件で、仕様と異なる結果を出していました。 実行環境の異常ではありません。 AIが作ったプログラムが、仕様を完全には満たしていなかったのです。 一方、Haiku 5.5は5回とも8件すべてに合格しました。 とはいえ、4回成功と5回成功の差だけで、5.5の方が安定して正しいプログラムを作れるとは断定できません。 試行回数がまだ少ないからです。 また、room_booking は両モデルとも5回すべて成功しています。 こちらでは品質の差を検出できませんでした。 両方とも正解できる課題では、能力の優劣が見えにくい。 最初に感じていた疑問が、ここでも出てきました。 ■速いのは、ツール操作が上手になったから？ ここからが今回の本題です。 Haiku 5.5は、なぜこんなに速いのでしょうか。 最近のAIの進化は、単純な推論能力だけではなく、ツールを利用して仕事を進める能力にも向かっているように感じています。 例えば、必要なファイルを効率よく探す。 不要な操作を減らす。 テストの失敗を読み取って、適切な修正をする。 そういう能力が向上した結果、速くなったのではないでしょうか。 そこで、ツールの実行回数を調べてみました。 結果は、ちょっと意外でした。 parcel_manifest では、両モデルとも1試行あたり10回。 5回の合計は、それぞれ50回です。 内訳も同じでした。 ファイル一覧5回、ファイル読取25回、ファイル書込15回、公開テスト5回。 まったく同じ回数です。 では、room_booking はどうでしょうか。 Haiku 4.5が5回合計55回。 Haiku 5.5が50回。 違いは公開テストの回数でした。 4.5は毎回、まだ修正していないプログラムに対して公開テストを実行し、失敗を確認してから実装していました。 5.5は先に修正し、その後に公開テストを実行していました。 ただし、4.5が失敗した実装を何度も修正していたわけではありません。 今回の20試行では、編集後の公開テスト失敗と、それを受けた再修正は一度も発生していません。 つまり、5.5はツール操作を劇的に減らしたから速い、というわけではなかったのです。 もちろん、今回の課題では操作手順が比較的決まっているため、複雑なツール選択能力まで比較できたわけではありません。 それでも、ツール操作の回数だけでは今回の速度差を説明できなさそうです。 ■Thinkingの量を見たら、もっと驚いた 次に、AIがどれだけThinkingトークンを使ったのか調べてみました。 Thinkingは、モデルが推論のために生成するトークンです。 これが多ければ必ず賢いというものではありませんが、処理にどれだけのトークンを使っているかを見る手がかりになります。 5回の中央値を比較します。 parcel_manifest Haiku 4.5：1,839トークン Haiku 5.5：383トークン room_booking Haiku 4.5：3,949トークン Haiku 5.5：614トークン なんと、5.5はThinkingトークンを約79〜84％も減らしています。 一方、Thinking以外の出力はどうでしょう。 試行ごとに「総出力トークン − Thinkingトークン」を計算して、中央値を求めました。 parcel_manifest では、 4.5が1,362トークン。 5.5が1,698トークン。 room_booking では、 4.5が1,709トークン。 5.5が2,134トークン。 Thinking以外の出力は、むしろ5.5の方が多かったのです。 これは興味深い。 AIが単に出力を短くして、仕事を省略していたわけではありません。 ファイルを読み、修正し、テストを実行するという作業をこなしながら、Thinkingの量を大幅に減らしていました。 もしかすると、今回の進化は、 同じ仕事を、以前ほど長く考えずにこなせるようになったこと なのかもしれません。 ただし、Thinkingトークン数はAIの知能を直接測る値ではありません。モデルごとの推論の仕組みやeffort設定の影響も受けます。 今回の結果だけで、内部の推論効率が何倍になったと結論づけることはできません。 それでも、実際の仕事量と生成トークンの関係が大きく変わったことは確認できました。 ■料金も大きく違った せっかくなので、料金も計算してみました。 ただし、今回の実験にはClaude Proの認証を使用しています。 ここでいう費用は、APIを使った場合の料金に換算した金額です。実際にこの金額がAPI料金として請求されたわけではありません。 5回の中央値は次のとおりでした。 parcel_manifest 4.5：約0.0287ドル 5.5：約0.00161ドル room_booking 4.5：約0.0589ドル 5.5：約0.00251ドル それぞれ約17.8倍、23.5倍の差があります。 ただし、ここは注意が必要です。 Anthropic公式の基本料金では、今回の10万トークン以下の価格帯で、Haiku 5.5の入出力単価は4.5の10分の1です。 つまり、料金差の大部分には、そもそものモデル単価の違いが含まれています。 その単価差を取り除いて、使用量による違いを同一料金体系に換算すると、約1.78倍と2.35倍です。 こちらにも、使用量の違いが現れています。 なお、キャッシュの利用状況にも違いがあり、初回と後続の試行ではキャッシュ書き込み量が変化しています。 そのため、料金差や実行時間のすべてをThinkingだけで説明することはできません。 ■そもそもAIメーカーは、どうやって優劣を決めているのか？ 今回の実験をしていて、昔から疑問に思っていたことを改めて考えました。 AIメーカーは、どうやってモデル同士の優劣をつけているのでしょうか。 例えば、今回の room_booking は、両モデルとも5回すべて非公開テストに合格しています。 正解率だけなら同点です。 でも実行時間には2倍以上の差があります。 では、5.5の方が賢いのでしょうか。 それとも、単に効率が良いのでしょうか。 また、今回の課題が簡単すぎて、両モデルの能力の限界が見えなかっただけかもしれません。 Anthropicは、Haiku 5.5の発表で、コーディング、PC操作、推論など複数のベンチマークを示しています。 公式に公開されているTerminal-Bench 4.0の成績は、Haiku 4.5が0.0％、Haiku 5.5が39.2％、参考としてSonnet 5.5が70.6％です。 こちらでは、かなり大きな差が出ています。 一方、私の実験では、Haiku 4.5ですら2課題10試行中9回成功しました。 当然、同じ難易度の問題を解いているわけではありません。 さらに、公式ベンチマークと今回の実験では、Thinkingやeffortなどの実行条件も異なります。 単純に数値を比較することはできません。 つまり、モデルの能力差を測ろうと思ったら、その能力差が現れる課題を用意しなければならないということです。 これは案外難しいことなのかもしれません。 そして、正解率だけでなく、速度、費用、安定性、ツール利用などを組み合わせて評価する必要もありそうです。 ■では、effortをmaxにしたらどうなる？ ここで、もう一つ疑問が出てきました。 今回、Haiku 5.5はmediumで実行しています。 では、maxにしたら、もっと賢くなるのでしょうか。 Anthropicも、Haiku 5.5についてeffort設定ごとの性能とコストの関係を公開しています。 つまり、思考の強さは、モデルの実力を評価するうえで無視できない条件です。 ただ、私には気になることがあります。 maxは、とにかく遅い。 普段の開発でmaxを使うと、考えている時間が長すぎて、作業のテンポが悪くなることがあります。 難しい問題を解くためには有効なのかもしれません。 でも、mediumでも正しくできる仕事に、毎回maxを使う必要があるのでしょうか。 仮に、mediumで10秒の仕事がmaxで1分になったとして、それによって品質がどれだけ向上するのか。 そこを知りたいのです。 さらに、maxにすれば必ず結果が良くなる、と決まっているわけでもありません。 たくさん考えることが、かえって余計な修正や時間の浪費につながる可能性もあります。 ただ、現時点では何とも言えません。 今回の実験ではmaxを一度も使っていないからです。 今後、さまざまな課題でHaiku 5.5を試し、どんなときに失敗するのか、どこに能力の限界があるのかを探っていきたいと思います。 そのうえで、最後の方にmaxを投入してみたい。 mediumでは解けない問題が、maxなら解けるのか。 それとも、単に時間とトークンをたくさん消費するだけなのか。 できればSonnetとも比較してみたいですね。 Haiku 5.5のmaxとSonnetのmediumでは、どちらが実用的なのか。 そこまで行くと、単純なモデル比較とはまた違った面白さがありそうです。 ■今回分かったこと、まだ分からないこと 20回の実験で、Haiku 5.5の進化が少し見えてきました。 今回の固定条件では、5.5は4.5より明確に速く動きました。 しかも、ファイルを読む回数や修正する回数は、ほとんど変わりませんでした。 大きく減っていたのはThinkingトークンです。 そして、品質は両モデルとも高い水準でしたが、4.5には1回だけ非公開テストの失敗がありました。 ここから言えるのは、少なくとも今回の課題では、Haiku 5.5は、より少ないThinkingで同じような開発作業をこなしていたということです。 一方で、それがモデル自体の推論能力の向上なのか、effort設定や実行環境の違いによる部分がどれだけあるのかは、まだ分かりません。 Sonnetを超えるほど賢くなったのかどうかも、今回の実験では判断できません。 むしろ、課題の方が簡単すぎた可能性があります。 次は、モデルの能力差が現れるような、もう少し難しい開発課題を試してみたいと思います。 特に、公開テストは通るのに仕様の境界で失敗する問題や、一度間違えた実装をどう修正するか、といったところです。 そして、いろいろな能力が見えてきた最後に、 「maxで長く考えることには、本当に意味があるのか？」 という疑問にも取り組んでみたいと思っています。 AIは、賢くなったのか。 それとも、同じことを効率よくできるようになったのか。 その違いを、もう少し追いかけてみたいですね。 参考資料 Anthropic：Claude Haiku 5.5 公式発表 https://t.co/Sc225YpaFF Anthropic：Claude API料金表 https://t.co/S8R7Dn0KaG 今回の実験では、課題とプロンプト、実行環境を固定し、全20試行のトークン数・実行時間・ツール操作・テスト結果を記録しています。実行条件はHaiku 4.5 defaultとHaiku 5.5 mediumであり、同一effortでのモデル単体比較ではありません。
0
1
0
0
748
arisan2026's profile image
アリさん Verified account @arisan2026
【くるま】新車の塗装は1か月触るな？ 昔の常識を調べたら、今は違っていた【教えてAI先生】 毎日似たような車の話ばかりでごめんなさい。でも、調べ始めると次から次へと疑問が湧いてきて、どうにも止まらないんです（笑）。 新車を買ったら、しばらくワックスやコーティングをしてはいけない。 塗装が完全に乾くまで、1か月くらい待った方がいい。 そんな話を聞いたことはありませんか？ 私はずっと、そういうものだと思っていました。 ところが今回、新車を購入するにあたって、納車前にボディコーティングを施工することにしました。 そこで、ふと疑問が。 あれ？ 新車の塗装って、しばらく触らない方がいいんじゃなかったっけ？ 気になったので、AI先生と調べてみました。 ■メーカーの回答は、まさかの「すぐにOK」 調べてみると、三菱自動車の公式FAQに、そのものズバリの質問がありました。 「新車を購入してすぐにワックスをかけてもよいですか。」 その回答は、なんと「問題ありません」。 工場出荷時点で塗料は固まっているため、納車後すぐにワックスをかけてもよいそうです。 えっ、そうなの？ 長年信じていた知識が、あっさり覆されてしまいました。 ただし、すでにボディコーティングを施工している車では、ワックスによってコーティングの効果が落ちる可能性があるため、施工店に確認するよう案内されています。 出典：三菱自動車公式FAQ https://t.co/263dSayWst ■なぜ昔は待つ必要があったのか？ 昔の塗装では、塗料が乾燥して見えても、内部では硬化が進んでいる途中ということがありました。 塗装が十分に硬化する前にワックスなどを施工すると、塗膜に悪影響を及ぼす可能性があります。 現在でも、補修用塗料メーカーのPPGは、塗装が完全に硬化する前のワックス施工によって、塗膜にくすみなどが発生する場合があると説明しています。 つまり、待つことには技術的な理由があるんですね。 ただし、昔の新車すべてが一律に1か月待つ必要があった、というところまでは確認できませんでした。 ■今の新車は何が違う？ 大きな違いは、工場での塗装工程です。 現代の自動車工場では、温度管理された工程で塗装を焼き付け、塗膜を硬化させています。 そのため、工場出荷時には通常の使用や手入れに耐えられる状態になっています。 納車から1か月という時間を、わざわざ待つ必要は基本的にないわけです。 もちろん、塗装の種類やメーカー指定の取り扱い条件によって例外はあります。 ■ただし、再塗装した車は別の話 ここは重要です。 事故修理や板金修理などで再塗装した場合、工場塗装とは乾燥・硬化条件が異なります。 塗料の種類や施工条件によって、硬化に時間が必要になることがあります。 実際、塗料メーカーPPGの資料には、クリア塗装後、数週間にわたって溶剤の放出が続く場合があることが説明されています。 また、3Mのプロテクションフィルムの資料では、再塗装車へのフィルム施工について、塗料メーカーの指示に従うことを前提に、多くの施工業者が少なくとも30日待つと紹介されています。 つまり、「新車の工場塗装」と「修理した車の補修塗装」を同じように考えてはいけないということですね。 ■コーティング直後の注意も別物だった さらに、もう一つ混同しやすい話がありました。 それが、コーティングを施工した直後の注意事項です。 こちらは車の塗装ではなく、コーティング剤そのものの硬化や定着に関する話です。 施工直後に洗車や薬剤の使用を制限する製品もあります。 つまり、似たような「しばらく触るな」でも、理由が違います。 ・新車の工場塗装：基本的に1か月待つ必要はない ・補修塗装：塗料や施工条件に応じた養生が必要 ・コーティング直後：施工製品の取り扱い指示に従う これを混同すると、話がおかしくなるわけですね。 ■逆に、汚れは放置しない方がいい ここで、さらに面白い話。 ホンダの取扱説明書では、鳥のふん、虫、樹液などが付着した場合は洗車するよう案内しています。 つまり、塗装を保護するために何もしないつもりが、汚れを放置して塗装を傷めてしまう可能性もあるんです。 新車だからといって、汚れたまま1か月放置するのは逆効果になりかねません。 ■まとめ：都市伝説というより、古い知識の生き残り？ 今回調べてみて、また一つ勉強になりました。 「新車の塗装は1か月触るな」 完全なデタラメというより、塗装の硬化に関する注意が、現在の新車にもそのまま当てはまると思われてきた話なのかもしれません。 しかも、補修塗装では今でも似た注意が必要になるため、余計に混同しやすい。 技術が進歩しても、昔の常識だけが生き残ってしまう。 車の世界には、まだまだそんな話がありそうです。 そして私も、長年信じていた一人でした。 また一つ、都市伝説を発見です。 参考資料 三菱自動車：新車を購入してすぐにワックスをかけてもよいですか https://t.co/263dSayWst PPG：Wax Incorporation（未硬化塗膜へのワックスの影響・英語） https://t.co/8mf56tM5vu PPG：Custom Restoration Guide（補修塗装の技術資料・英語） https://t.co/WH4oMgIM5D 3M：Paint Protection Film FAQ（再塗装車への施工・英語） https://t.co/xxC7FVvzrF Honda：ボディーのお手入れ https://t.co/Qq7dXTkLf3
0
0
0
0
252
arisan2026's profile image
アリさん Verified account @arisan2026
【くるま】オイル交換は何kmごと？ 調べてみたら「何か月ごと？」の方が重要だった【教えてAI先生】 新しく購入したヴェゼル e:HEV Z。 納車を前に、エンジンオイルをどう管理するか考えていた。 これまでもオイル交換には、それなりに気を使ってきた。 昔乗っていたRB26搭載のGT-Rでは、高価なオイルを3,000km程度で交換していた。 30プリウスでは、ハイブリッド向けのオイルを使い、5,000km程度。 そしてGR86では、比較的品質の高いオイルを選び、3,000〜5,000km程度で交換していた。 もちろん、それが正しかったという証拠があるわけではない。 ただ、エンジンオイルの交換を無理に引き延ばしたところで、得られるものはそれほど大きくないと思っている。 そんな話をAIとしていたら、予想以上にいろいろな疑問が出てきた。 ■メーカーのオイル交換周期は思ったより長い まず、Hondaの公式サイトでヴェゼル e:HEVの交換時期を確認した。 通常の使用条件では、 15,000kmまたは12か月の、どちらか早い方。 シビアコンディションでは、 7,500kmまたは6か月の、どちらか早い方。 想像していたより長い。 しかも、オイルフィルターについては、通常30,000kmまたは24か月、シビアコンディションでも15,000kmまたは12か月となっている。 自分がこれまで行ってきた交換周期と比べると、ずいぶん余裕があるように見える。 そこで、整備士の方々の意見も調べてみた。 整備工場などでは、5,000kmや半年程度を目安にする案内をよく見かける。 メーカーの指定より、整備士の方々の推奨は厳しい印象だ。 最初は、どちらが正しいのだろうと思った。 でも、話しているうちに考えが変わってきた。 もしかすると、両者は同じことを違う立場から言っているだけではないのか。 メーカーは、設計や耐久試験などを踏まえた整備基準を示している。 一方、整備士は、実際にさまざまな状態のエンジンを見てきた経験から、余裕を持った交換を勧めている。 もちろん、すべての整備士が同じ意見というわけではないし、早く交換すれば必ずエンジンの寿命が延びるというわけでもない。 それでも、メーカーの指定時期まで使わなければ損、というものでもないだろう。 個人的には、整備士の方々の意見を尊重したい。 わざわざオイル交換のチキンレースをする意味もない。 ■週に1回しか乗らない車はシビアコンディション？ ここでもう一つ、疑問が出てきた。 自分はヴェゼルに週1回乗るかどうかも分からない。 だから、てっきりシビアコンディションに該当するものだと思っていた。 ところが、Hondaの定義を確認すると、使用頻度が少ないこと自体は条件になっていなかった。 Hondaが挙げる主な条件は、次のようなものだ。 ・悪路や雪道を頻繁に走る ・年間20,000km以上走る ・山道や登降坂路を頻繁に走る ・1回8km程度以下の短距離走行を繰り返す ・氷点下での走行を繰り返す ・30km/h以下の低速走行が多い ・アイドリングが多い これらの条件に該当する走行が、走行距離のおよそ30％以上というのが目安らしい。 つまり、週に1回しか乗らなくても、毎回50km、100kmとまとまった距離を走るなら、使用頻度が少ないという理由だけでシビアコンディションになるわけではない。 逆に、毎日乗っていても近所への買い物ばかりなら、シビアコンディションに該当する可能性がある。 ここは認識が違っていた。 ■都会で普通に走っているだけでシビア？ 特に驚いたのは、低速走行の条件だ。 目安は30km/h以下。 都市部での平均速度を考えると、決して珍しい条件ではない。 さらに、短距離走行の繰り返しも該当する。 でも、スーパーへ買い物に行ったら、買い物が終われば帰るでしょう。 エンジンのために、わざわざ遠回りするのも変な話だ。 調べていて気づいたのは、シビアコンディションは、やってはいけない運転という意味ではないことだ。 日常的な使い方でも、エンジンオイルにとって厳しい条件になることがある。 だから、そういう使い方が多いなら、整備間隔を短くする。 車の使い方を整備に合わせるのではなく、使い方に整備を合わせるということなのだろう。 ■そして、忘れがちなのが「期間」 今回、一番大事だと思ったのはここかもしれない。 オイル交換というと、何kmで交換するかばかり考えてしまう。 でも、メーカーの指定には必ず期間も書かれている。 例えば、週に1回、50km走るとする。 年間走行距離は約2,600km。 5,000kmに達するまで、ほぼ2年かかる。 走行距離だけで管理していたら、2年間オイル交換をしないことになってしまう。 エンジンオイルは、走行によって劣化するだけではない。 時間の経過も考慮する必要があるし、短距離走行が多ければ、水分や燃料の混入も気になる。 トヨタの公式サイトにも、車を使わなくてもエンジンオイルは自然に劣化すると説明されていた。 もちろん、乗らなければ急激に傷むという話でもない。 ただ、「走っていないから大丈夫」と思い込むのは危ない。 自分のように使用頻度が少ない車では、走行距離より先に期間の条件が来る可能性が高い。 今後は、前回いつ交換したのかを忘れないようにしたい。 ■e:HEVは、エンジンがどれだけ働いているのか分からない もう一つ、ヴェゼルならではの疑問がある。 e:HEVはモーター主体のハイブリッドだ。 エンジンが止まっている時間もあるし、発電のために動いている時間もある。 高速域では条件によってエンジン直結走行にもなる。 ところが、ドライバーにはエンジンの回転数も、発電負荷も分からない。 GR86なら、どのくらいの回転数を使い、どんな運転をしていたか、ある程度は把握できた。 ヴェゼルでは、その部分を車が自動で制御してくれる。 例えば、50km走ったとしても、エンジンが実際にどの程度動いていたのかは分からない。 発電のために高い負荷で動くこともあれば、ほとんど休んでいる時間もあるだろう。 ただし、これはe:HEVが特別にエンジンを酷使しているという意味ではない。 Hondaは当然、そうした制御を前提にエンジンを設計し、交換周期を設定しているはずだ。 それでも、オーナーの立場からすると、エンジンの使われ方を判断する材料が少ない。 だから、整備には少し余裕を持たせておきたいと思っている。 ■上抜きと下抜き、どちらがいい？ オイル交換といえば、もう一つ気になる話題がある。 オイルの上抜きと下抜きだ。 以前から、オートバックスで交換するときは上抜きになることが多かった。 個人的には、上抜きでも問題ないと思っている。 むしろ、車種によっては上抜きの方が多く抜ける可能性すらある。 オイルパンの底まで吸引ホースが届けば、かなりの量を抜ける。 一方、下抜きでも、ドレンボルトの位置やオイルパンの形状によっては残油が出る。 もちろん、上抜きにはホースが底まで届かない場合があり、下抜きには下回りを点検しやすいという利点もある。 結局、どちらがよいかは車の構造や作業方法による。 本当に調べるなら、オイルパンを外して残油や堆積物を見てみるのが確実なのだろう。 そこまでするつもりはないけれど。 それに、エンジンオイルは交換しても内部に多少残るものだ。 少し残った古いオイルを気にするより、定期的な交換を続ける方が現実的だと思う。 ■オイルが黒いから劣化しているとは限らない 上抜きと下抜きの話をしていて、こんなことも考えた。 新しいオイルを入れて、少しエンジンを回し、また抜く。 これを何回か繰り返したら、どれだけきれいになるのだろう。 でも、液体というのは少し汚れが混ざっただけで、見た目が大きく変わる印象がある。 水に墨汁を少し垂らしただけでも、全体が黒っぽくなる。 オイルも、色だけでは劣化の程度を判断できない。 黒く見えても潤滑性能が十分残っていることはあるし、逆にきれいに見えても燃料希釈などが進んでいる可能性はある。 オイルの状態を詳しく調べるには分析が必要になる。 目で見て汚れているからといって、新油で何度もすすぐ必要があるとは限らないわけだ。 それなら、結局は定期的な交換に戻ってくる。 突然きれい好きになるより、普段から交換しておけばいい。 ■新車の最初のオイルは特別なのか？ 最後に、少し気になる話がある。 新車時のエンジンオイルは、通常の交換用オイルとは違うという話を、以前から何度か聞いたことがあった。 調べてみると、2006年の米国Hondaの整備向け資料に、エンジン組み立て時に使用するモリブデン系潤滑剤についての説明があったとされる。 組み立て時の潤滑剤がエンジンオイルに混ざり、新車のオイルが短時間で黒っぽくなる場合があるという話だ。 当時の資料では、初回の指定交換時期まで工場充填オイルを使うよう案内していたという。 ただし、これは昔の米国向けの情報だ。 現在の日本仕様ヴェゼルでも同じことをしているのかは、確認できなかった。 以前は、初回1,000km程度で交換して、オイルの状態を整備士さんに見てもらうのも面白いと思っていた。 でも、初回オイルには別の事情があるかもしれない。 少なくとも、今のヴェゼルについて初回1,000kmで交換する必要があるというメーカー指定は確認できていない。 このあたりは、ディーラーの整備士さんにも聞いてみたい。 ■結局、自分はどうするのか いろいろ調べてきたけれど、結論は意外と単純だった。 メーカーの交換基準は尊重する。 でも、その基準いっぱいまで使う必要もない。 自分の場合、ヴェゼルには週1回乗るかどうかも分からないし、近所への買い物にも使うと思う。 メーカーの定義でシビアコンディションに該当するかどうかは、実際の使い方を見ないと分からない。 それに、本当はエンジンをできるだけ優しく扱いたい。 GR86なら、冷間時に高回転を避けたり、エンジンが温まるまでは負荷を抑えたり、自分で気を使うことができた。 ところが、ヴェゼルのe:HEVではそうはいかない。 エンジンをいつ始動し、どのくらいの回転数と負荷で動かすのかは、基本的に車任せだ。 もちろん、Hondaはそうした使い方を前提に設計しているのだろうし、ドライバーも穏やかなアクセル操作などで負担を抑えることはできる。 それでも、自分でエンジンの運転状態を管理することは難しい。 だったら、せめてオイル交換くらいは気を使ってやりたい。 自分にできることは、それほど多くないのだから。 そう考えると、シビアコンディション相当の交換周期を採用するのも悪くない。 走行距離なら5,000km程度、期間なら6か月程度を一つの目安にする。 これは、自分が納得して乗るためのルールだ。 早く交換した方が必ずエンジンが長持ちするという証明があるわけではないし、誰にでも勧めるつもりもない。 適切な規格のオイルを使い、正しく交換することが前提になる。 でも、交換を少し早めたところで、それほど大きな負担とも思わない。 今回調べてみて、一番気をつけようと思ったのは交換距離ではなく、交換期間だった。 「乗っていないから大丈夫」ではない。 そして、整備士さんの意見を聞くことも大事だと思った。 メーカーの基準と整備士さんの推奨は、必ずしも対立するものではないのかもしれない。 自分にとって、エンジンオイル交換は限界まで使い切る競争ではない。 チキンレースをするくらいなら、納得できる時期に交換する。 結局、昔からやってきたことに戻ってきた気がする。 参考資料 Honda公式：VEZEL エンジンオイルの交換時期・交換量・種類 https://t.co/PieGu1GXS3 Honda公式：シビアコンディションとは https://t.co/8YY6n0zRY9 Honda公式：VEZEL e:HEV 2026 車両仕様一覧 https://t.co/Qc2T4YTmss トヨタ公式：エンジンオイルの交換時期 https://t.co/CSreVZApU6 オートバックス公式：上抜きと下抜きの違い https://t.co/z1OjrEsxWC ※交換時期や推奨オイルは車種・年式・使用条件によって異なります。実際の整備では、該当車両のメンテナンスノートや取扱説明書を確認してください。 ※新車時のモリブデンに関する話は、2006年の米国Honda整備資料についての引用情報に基づきます。現行日本仕様への適用は未確認です。
arisan2026's tweet photo. 【くるま】オイル交換は何kmごと？ 調べてみたら「何か月ごと？」の方が重要だった【教えてAI先生】 新しく購入したヴェゼル e:HEV Z。 納車を前に、エンジンオイルをどう管理するか考えていた。 これまでもオイル交換には、それなりに気を使ってきた。 昔乗っていたRB26搭載のGT-Rでは、高価なオイルを3,000km程度で交換していた。 30プリウスでは、ハイブリッド向けのオイルを使い、5,000km程度。 そしてGR86では、比較的品質の高いオイルを選び、3,000〜5,000km程度で交換していた。 もちろん、それが正しかったという証拠があるわけではない。 ただ、エンジンオイルの交換を無理に引き延ばしたところで、得られるものはそれほど大きくないと思っている。 そんな話をAIとしていたら、予想以上にいろいろな疑問が出てきた。 ■メーカーのオイル交換周期は思ったより長い まず、Hondaの公式サイトでヴェゼル e:HEVの交換時期を確認した。 通常の使用条件では、 15,000kmまたは12か月の、どちらか早い方。 シビアコンディションでは、 7,500kmまたは6か月の、どちらか早い方。 想像していたより長い。 しかも、オイルフィルターについては、通常30,000kmまたは24か月、シビアコンディションでも15,000kmまたは12か月となっている。 自分がこれまで行ってきた交換周期と比べると、ずいぶん余裕があるように見える。 そこで、整備士の方々の意見も調べてみた。 整備工場などでは、5,000kmや半年程度を目安にする案内をよく見かける。 メーカーの指定より、整備士の方々の推奨は厳しい印象だ。 最初は、どちらが正しいのだろうと思った。 でも、話しているうちに考えが変わってきた。 もしかすると、両者は同じことを違う立場から言っているだけではないのか。 メーカーは、設計や耐久試験などを踏まえた整備基準を示している。 一方、整備士は、実際にさまざまな状態のエンジンを見てきた経験から、余裕を持った交換を勧めている。 もちろん、すべての整備士が同じ意見というわけではないし、早く交換すれば必ずエンジンの寿命が延びるというわけでもない。 それでも、メーカーの指定時期まで使わなければ損、というものでもないだろう。 個人的には、整備士の方々の意見を尊重したい。 わざわざオイル交換のチキンレースをする意味もない。 ■週に1回しか乗らない車はシビアコンディション？ ここでもう一つ、疑問が出てきた。 自分はヴェゼルに週1回乗るかどうかも分からない。 だから、てっきりシビアコンディションに該当するものだと思っていた。 ところが、Hondaの定義を確認すると、使用頻度が少ないこと自体は条件になっていなかった。 Hondaが挙げる主な条件は、次のようなものだ。 ・悪路や雪道を頻繁に走る ・年間20,000km以上走る ・山道や登降坂路を頻繁に走る ・1回8km程度以下の短距離走行を繰り返す ・氷点下での走行を繰り返す ・30km/h以下の低速走行が多い ・アイドリングが多い これらの条件に該当する走行が、走行距離のおよそ30％以上というのが目安らしい。 つまり、週に1回しか乗らなくても、毎回50km、100kmとまとまった距離を走るなら、使用頻度が少ないという理由だけでシビアコンディションになるわけではない。 逆に、毎日乗っていても近所への買い物ばかりなら、シビアコンディションに該当する可能性がある。 ここは認識が違っていた。 ■都会で普通に走っているだけでシビア？ 特に驚いたのは、低速走行の条件だ。 目安は30km/h以下。 都市部での平均速度を考えると、決して珍しい条件ではない。 さらに、短距離走行の繰り返しも該当する。 でも、スーパーへ買い物に行ったら、買い物が終われば帰るでしょう。 エンジンのために、わざわざ遠回りするのも変な話だ。 調べていて気づいたのは、シビアコンディションは、やってはいけない運転という意味ではないことだ。 日常的な使い方でも、エンジンオイルにとって厳しい条件になることがある。 だから、そういう使い方が多いなら、整備間隔を短くする。 車の使い方を整備に合わせるのではなく、使い方に整備を合わせるということなのだろう。 ■そして、忘れがちなのが「期間」 今回、一番大事だと思ったのはここかもしれない。 オイル交換というと、何kmで交換するかばかり考えてしまう。 でも、メーカーの指定には必ず期間も書かれている。 例えば、週に1回、50km走るとする。 年間走行距離は約2,600km。 5,000kmに達するまで、ほぼ2年かかる。 走行距離だけで管理していたら、2年間オイル交換をしないことになってしまう。 エンジンオイルは、走行によって劣化するだけではない。 時間の経過も考慮する必要があるし、短距離走行が多ければ、水分や燃料の混入も気になる。 トヨタの公式サイトにも、車を使わなくてもエンジンオイルは自然に劣化すると説明されていた。 もちろん、乗らなければ急激に傷むという話でもない。 ただ、「走っていないから大丈夫」と思い込むのは危ない。 自分のように使用頻度が少ない車では、走行距離より先に期間の条件が来る可能性が高い。 今後は、前回いつ交換したのかを忘れないようにしたい。 ■e:HEVは、エンジンがどれだけ働いているのか分からない もう一つ、ヴェゼルならではの疑問がある。 e:HEVはモーター主体のハイブリッドだ。 エンジンが止まっている時間もあるし、発電のために動いている時間もある。 高速域では条件によってエンジン直結走行にもなる。 ところが、ドライバーにはエンジンの回転数も、発電負荷も分からない。 GR86なら、どのくらいの回転数を使い、どんな運転をしていたか、ある程度は把握できた。 ヴェゼルでは、その部分を車が自動で制御してくれる。 例えば、50km走ったとしても、エンジンが実際にどの程度動いていたのかは分からない。 発電のために高い負荷で動くこともあれば、ほとんど休んでいる時間もあるだろう。 ただし、これはe:HEVが特別にエンジンを酷使しているという意味ではない。 Hondaは当然、そうした制御を前提にエンジンを設計し、交換周期を設定しているはずだ。 それでも、オーナーの立場からすると、エンジンの使われ方を判断する材料が少ない。 だから、整備には少し余裕を持たせておきたいと思っている。 ■上抜きと下抜き、どちらがいい？ オイル交換といえば、もう一つ気になる話題がある。 オイルの上抜きと下抜きだ。 以前から、オートバックスで交換するときは上抜きになることが多かった。 個人的には、上抜きでも問題ないと思っている。 むしろ、車種によっては上抜きの方が多く抜ける可能性すらある。 オイルパンの底まで吸引ホースが届けば、かなりの量を抜ける。 一方、下抜きでも、ドレンボルトの位置やオイルパンの形状によっては残油が出る。 もちろん、上抜きにはホースが底まで届かない場合があり、下抜きには下回りを点検しやすいという利点もある。 結局、どちらがよいかは車の構造や作業方法による。 本当に調べるなら、オイルパンを外して残油や堆積物を見てみるのが確実なのだろう。 そこまでするつもりはないけれど。 それに、エンジンオイルは交換しても内部に多少残るものだ。 少し残った古いオイルを気にするより、定期的な交換を続ける方が現実的だと思う。 ■オイルが黒いから劣化しているとは限らない 上抜きと下抜きの話をしていて、こんなことも考えた。 新しいオイルを入れて、少しエンジンを回し、また抜く。 これを何回か繰り返したら、どれだけきれいになるのだろう。 でも、液体というのは少し汚れが混ざっただけで、見た目が大きく変わる印象がある。 水に墨汁を少し垂らしただけでも、全体が黒っぽくなる。 オイルも、色だけでは劣化の程度を判断できない。 黒く見えても潤滑性能が十分残っていることはあるし、逆にきれいに見えても燃料希釈などが進んでいる可能性はある。 オイルの状態を詳しく調べるには分析が必要になる。 目で見て汚れているからといって、新油で何度もすすぐ必要があるとは限らないわけだ。 それなら、結局は定期的な交換に戻ってくる。 突然きれい好きになるより、普段から交換しておけばいい。 ■新車の最初のオイルは特別なのか？ 最後に、少し気になる話がある。 新車時のエンジンオイルは、通常の交換用オイルとは違うという話を、以前から何度か聞いたことがあった。 調べてみると、2006年の米国Hondaの整備向け資料に、エンジン組み立て時に使用するモリブデン系潤滑剤についての説明があったとされる。 組み立て時の潤滑剤がエンジンオイルに混ざり、新車のオイルが短時間で黒っぽくなる場合があるという話だ。 当時の資料では、初回の指定交換時期まで工場充填オイルを使うよう案内していたという。 ただし、これは昔の米国向けの情報だ。 現在の日本仕様ヴェゼルでも同じことをしているのかは、確認できなかった。 以前は、初回1,000km程度で交換して、オイルの状態を整備士さんに見てもらうのも面白いと思っていた。 でも、初回オイルには別の事情があるかもしれない。 少なくとも、今のヴェゼルについて初回1,000kmで交換する必要があるというメーカー指定は確認できていない。 このあたりは、ディーラーの整備士さんにも聞いてみたい。 ■結局、自分はどうするのか いろいろ調べてきたけれど、結論は意外と単純だった。 メーカーの交換基準は尊重する。 でも、その基準いっぱいまで使う必要もない。 自分の場合、ヴェゼルには週1回乗るかどうかも分からないし、近所への買い物にも使うと思う。 メーカーの定義でシビアコンディションに該当するかどうかは、実際の使い方を見ないと分からない。 それに、本当はエンジンをできるだけ優しく扱いたい。 GR86なら、冷間時に高回転を避けたり、エンジンが温まるまでは負荷を抑えたり、自分で気を使うことができた。 ところが、ヴェゼルのe:HEVではそうはいかない。 エンジンをいつ始動し、どのくらいの回転数と負荷で動かすのかは、基本的に車任せだ。 もちろん、Hondaはそうした使い方を前提に設計しているのだろうし、ドライバーも穏やかなアクセル操作などで負担を抑えることはできる。 それでも、自分でエンジンの運転状態を管理することは難しい。 だったら、せめてオイル交換くらいは気を使ってやりたい。 自分にできることは、それほど多くないのだから。 そう考えると、シビアコンディション相当の交換周期を採用するのも悪くない。 走行距離なら5,000km程度、期間なら6か月程度を一つの目安にする。 これは、自分が納得して乗るためのルールだ。 早く交換した方が必ずエンジンが長持ちするという証明があるわけではないし、誰にでも勧めるつもりもない。 適切な規格のオイルを使い、正しく交換することが前提になる。 でも、交換を少し早めたところで、それほど大きな負担とも思わない。 今回調べてみて、一番気をつけようと思ったのは交換距離ではなく、交換期間だった。 「乗っていないから大丈夫」ではない。 そして、整備士さんの意見を聞くことも大事だと思った。 メーカーの基準と整備士さんの推奨は、必ずしも対立するものではないのかもしれない。 自分にとって、エンジンオイル交換は限界まで使い切る競争ではない。 チキンレースをするくらいなら、納得できる時期に交換する。 結局、昔からやってきたことに戻ってきた気がする。 参考資料 Honda公式：VEZEL エンジンオイルの交換時期・交換量・種類 https://t.co/PieGu1GXS3 Honda公式：シビアコンディションとは https://t.co/8YY6n0zRY9 Honda公式：VEZEL e:HEV 2026 車両仕様一覧 https://t.co/Qc2T4YTmss トヨタ公式：エンジンオイルの交換時期 https://t.co/CSreVZApU6 オートバックス公式：上抜きと下抜きの違い https://t.co/z1OjrEsxWC ※交換時期や推奨オイルは車種・年式・使用条件によって異なります。実際の整備では、該当車両のメンテナンスノートや取扱説明書を確認してください。 ※新車時のモリブデンに関する話は、2006年の米国Honda整備資料についての引用情報に基づきます。現行日本仕様への適用は未確認です。
0
2
0
0
2K

Last Seen Users on Sotwe

piplikizlar's profile image
pplikizlar
Freitas7Ivair's profile image
Ivair Freitas
Seen from Saudi Arabia
chikyyy0501's profile image
Chikay
Seen from Germany
bears_maneul's profile image
흑머늘 Verified account
Seen from Korea
Mu6Ik55aDaehbdc's profile image
อุบลอยากลอง
Seen from United States
bdi_fa7l's profile image
🇸🇾🇩🇪زب
Seen from Israel
chayxarm5's profile image
ชาย อาร์ม
Seen from Thailand
Kouto_tokyo's profile image
モンチッチ_kouto Verified account
Seen from Japan
ww1434407217909's profile image
پاشایی جەو 👌🥰
dendy_lutfian48's profile image
🌻
Seen from Korea

Trends for you

1
Justin Tucker
Under 10K tweets
2
Good Wednesday
Under 10K tweets
3
Hump Day
Under 10K tweets
4
FOMC
Under 10K tweets
5
#WednesdayMotivation
Under 10K tweets
6
Toledo
Under 10K tweets
7
#NationalFirstRespondersDay
Under 10K tweets
8
#中国北京应立刻追查姚润昊
Under 10K tweets
9
Happy Hump
Under 10K tweets
10
#BORNTOBEByNuNew
Under 10K tweets

Most Popular Users

elonmusk's profile image
1
Elon Musk Verified account
@elonmusk
241.5M followers
barackobama's profile image
2
Barack Obama Verified account
@barackobama
118.8M followers
cristiano's profile image
3
Cristiano Ronaldo Verified account
@cristiano
114.5M followers
realdonaldtrump's profile image
4
Donald J. Trump Verified account
@realdonaldtrump
111.9M followers
narendramodi's profile image
5
Narendra Modi Verified account
@narendramodi
107.1M followers
rihanna's profile image
6
Rihanna Verified account
@rihanna
98.7M followers
nasa's profile image
7
NASA Verified account
@nasa
92.3M followers
justinbieber's profile image
8
Justin Bieber Verified account
@justinbieber
91.8M followers
katyperry's profile image
9
KATY PERRY Verified account
@katyperry
90M followers
taylorswift13's profile image
10
Taylor Swift Verified account
@taylorswift13
84M followers
ladygaga's profile image
11
Lady Gaga Verified account
@ladygaga
75.5M followers
imvkohli's profile image
12
Virat Kohli Verified account
@imvkohli
73.5M followers
kimkardashian's profile image
13
Kim Kardashian Verified account
@kimkardashian
70.9M followers
youtube's profile image
14
YouTube Verified account
@youtube
68.8M followers
neymarjr's profile image
15
Neymar Jr Verified account
@neymarjr
66.5M followers
billgates's profile image
16
Bill Gates Verified account
@billgates
65.3M followers
selenagomez's profile image
17
Selena Gomez Verified account
@selenagomez
63.1M followers
theellenshow's profile image
18
The Ellen Show
@theellenshow
62.2M followers
cnn's profile image
19
CNN Verified account
@cnn
61.7M followers
x's profile image
20
X Verified account
@x
60.7M followers