AIは「違和感」を認知できない

• 

DeepSeek v4.1 Flashの推論能力は、トップレベルのクラウドLLMクラスだと言われる。
しかもオープンウェイト。

これをMacStudioで動かしたりするのが一部界隈で流行している。

筆者も少し時代遅れのA100 80GBを8基搭載したマシンがあったため、これでなんとか最新のモデルが動かせないか挑戦してみることにした。もちろん挑戦するのはAIで、筆者は指示をするだけだ。

しかし意外にも、これをやることでAIの弱点が見えてきた。

その詳しい顛末については筆者のnoteに書いてあるのでそちらを参照されたい

https://note.com/shi3zblog/n/nd5fc5341b342

この体験からわかったことは、AIはどこまでいっても「有名大学を出たちょっと生意気な新入社員」以上のものにはならないということだ。つまり、頭でっかちなのだ。

なにかに取り組む前にあれこれと理由をつけて諦める。またはこちらをあきらめさせようとする。
勝手に処理を省略する、「理論上はこうだ」と繰り返し主張して本質的なところにあたろうとしない。

なぜこうなるのかというと、AIが学習元にしているのが、あくまでも人間の書いた文章だからだ。そして、まとまった文章というのは、基本的に「いいこと」しか書いてないのである。

QiitaやZendeskやStack overflowがそうであるように、センセーショナルなことやニュース生のあることがメインで書かれて公開されている。成功に至るまでの泥臭い過程について詳しく書かれた文章は驚くほど少ない。その理由は、世の中の人は大半が、文章を書く訓練を受けていないからだ。

つまり困難な状況に直面した際、それをどのように乗り囲えたか、ということについて書かれた文章は、過度に誇張されているか、ドラマチックに書かれていて、本当に必要だったことが書かれていることは少ない。それは抽象的に言えば「直感と信念」だったり、「突破力」だったりするのだが、それは文章だけ見てもわからない。

筆者にはそもそも経験がある。
ずっと以前から、「AIに勝つためには人間として生きる/生きた経験」が何よりも大切になると考えていたのだが、思った以上にこの「文章化できない経験そのもの」には価値があるようだ。

今回、まずDeepSeekをA100で動かそうとしたとき、最初に言われたのが「無理です」だった。
その答えは三流であると言わざるを得ない。なぜなら無理なわけがないからだ。

なぜ無理ではないのか?

DeepSeek v4.1は、552B、つまり5500億パラメータのモデルである。その容量は、約1TB(テラバイト)になる。
筆者らの持つAIスーパーコンピュータ、継之助は、A100 80GBを8基、つまり640GBのGPUメモリ(VRAM)と別に、1.7TBのシステムメモリを搭載している。

つまり、1TBの情報を読み込むことが不可能なわけでは決してないのだ。

多少は知識のある人間なら「動くかもしれませんが、実用的な速度で動くとは限りませんよ」と答えるだろう。
だが経験豊富な(さすがに40年もやってるんだからそう名乗っても怒られないと思うが)プログラマーである筆者は、こう思った。

「実用的な速度で動かないわけがないだろう。だってDeepSeek v4.1 FlashがAmpare世代を対象外としているのは、FP4(4ビット)命令がないからだ。しかし実際にニューラルネットで用いられる計算の多くは単なる行列の積和演算(掛け算と足し算)、つまりFP4がないからといって動かない理由にはならない」

棍棒を持つ人は、なんでも棍棒で解決しようとする。FP4命令があれば当然それを使う。FP4命令がない世界のことなんか忘れてしまう。

しかしスーパーコンピュータクラスのマシンは大金である。継之助もなんのかんので4000万円くらいはかかっている。4000万円のスーパーカーがたった6年で中古車になっていいのか。いや、まだ走れるはずだ、そう考えるのは当然だ。

そこで本格的に継之助で動かすことにしたのだが、とにかく次から次へと「無理です」と拒絶したり、「こういう方式に変えろ」と言うと、プログラムを書きもしないで「非効率的です」などと言ってサボろうとする。

こういうAIと付き合おうとすると、まず専門知識が必要になる。

「その方式ではなく、こっちの方式を試せ」と指示する時に、相手が何をやろうとしていてどこで躓いているか想像して指示しなくてはならない。人間のプログラマーに指示をする時とほとんどまったく同じことをしている。

適切な指示を出さないとどうなるか?

トークンを無駄に消費するのである。
トークンの無駄な消費は、現代において死活問題だ。最新のAIはすぐにトークン制限に達して止まってしまうからだ。

トークン制限に達することは論理的な死を意味する。どうしても使い続けたければ追加料金を払うしかない。
先日、某社で誤ってトークン使用を無制限にしたところ、一人で50万円も追加請求された人が居たらしい。50万円も使ってしまう人がその金額に見合う成果をあげられたかは甚だ疑問だ。

興味深いのは、トークンを大量消費すれば必ずしも正解に辿り着けるわけではないということだ。
いかに無駄なトークンを消費せずに最短時間で正解にたどり着くか。ここがこれからの人類の「賢さ」の基準となる。

筆者もまた、DeepSeekの最適化中にトークン制限に達し、まだ火曜日だというのにClaudeの週間リミットが来てしまった。次に制限が解除されるのは四日後だ。筆者のClaudeの契約はMAX 20倍という最大のもので、月額3万円する。リミットが来るまでに別のアカウントを契約してさらに3万円払うか、他の方法を考えるか。とりあえずChatGPTのWebインターフェースとLinuxのコンソールを行ったり来たりする、二年前のバイブコーディング(という言葉はまだなかったが)に逆戻りして進めた。

https://note.com/shi3zblog/n/n93b0161463b4

ある時点まで行くと、「Codexのリセット権」というものがあることに気づいた。
そこで途中からCodexに引き継ぐと、再び怒涛のように作業を進めた。

ところがCodexのトークン制限に達するのはあっという間だった。
5時間制限というのがあり、これが厳しい。半日も持たない。

正直言って、この5時間制限をすることに何の意味があるのかわからない。
腹立たしたかったが、背に腹は変えられないので一回目のリセット権を行使した。

しかしリセットしてもあっという間にトークンを消費してしまう。
しかたないのでAIのレベルをだいぶ下げて、少しずつでも前に進めるようにした。

Codexの二回目の制限に達した時、たまたま自作のDeepSeekサーバーが実用的な速度で動くまで最適化されていたので作業をDeepSeekサーバーに引き継いだ。今のところ、驚くほどうまく動いている。怖いくらいだ。

筆者が最初に作らせたのは、Claude Codeのログ可視化ツール。
最近、クライアントから「Claude Codeの使い方がよくわからない」という相談を受けることがあって、ログを可視化してもらって送ってもらおうと考えたのだ。

また、そもそもClaude Codeとどんな会話を過去にしたのか、自分でも興味があるし、これ単体でも読み物として需要がありそうだと考えたのもある。どうやってDeepSeekを最適化したのか、そのプロセスを知ることはAIを使う専門家でなくても価値がありそうだ。

こうやって実用的なタスクをうごかすと、今度は推論エンジンが「ただ動くだけ」とは違う性質を備えていることに気が付く。

どうも遅い。何かが変だ。
そこで、推論エンジンにダッシュボードをつけることにした。今どんなことをやっていて、どんなふうにGPUが動いて、どのように推論しているのかわかるようになる。

そこで奇妙なことに気がついた。

Claude Codeはもともと5000トークン近い長大なシステムプロンプトを持っている。そのため、どのような命令をしても最低5000トークンを最初に読み込まなければならない。ところが推論エンジンは4並列で動いているので、全部の並列タスクで毎回長いプロンプトを処理しようとしている。

これは可視化すれば一目瞭然だが、普通に使っているだけでは「なんかちょっと遅いな」と自分を誤魔化してしまう領域だ。

しかし会話が進むほどプロンプトは肥大化していくため、この「ちょっと遅いな」は「どんどん遅くなるなあ」そして「使い物にならないな」になっていく。それでは意味がないので、この処理を並列化するように指示を出した。

すると完全に並列に動くようになって、しかもシステムを占有しているのでトータルでは本家のClaudeを使うより速く仕事が進むことになる。これは気持ちのいい状態だ。

ユースケースを前提としない最適化には意味がない。
ただ目先の速度だけを追いかけていたら、本当に「速い」推論エンジンは作れないということだ。

エンジンだけ速くてもカーレースに勝てるとは限らない。
エンジン、シャーシ、ミッション、タイヤ、それを調整するメカニック、そしてドライバーが勝負を分ける。

作ってて思ったのだが、本来は推論エンジン(DeepSeek v4.1)とエージェント(Claude Code)の距離をもっと縮めることができる。なぜ誰もやらないのか疑問だ。

推論エンジンとエージェントを疎結合にしているメリットがあることはよくわかる。推論エンジンの進歩とエージェントの進歩は独立させたほうがビジネス的には都合がいいからだ。

不思議なのは、Claude Codeはクローズドソースなのにもかかわらず、他のバックエンドでも動くように設計されていることだ。もしもベンダーロックインが目的なら、つまり、Claudeの客を他に取られたくないのなら、本家のAPIに隠しコマンドを入れて、本家としか通じない暗号通信をするべきである。ただこの方法にはリスクもある。暗号化されているといってもリバースエンジニアリングは出来てしまうので、好ましからざる客にも暗号化APIはバレてしまうし、二つのエンドポイントを管理しなければならなくなる。でもそれがそこまで大きな負担になるとは思えない。

プログラムというのは、規模が巨大になればなるほど、細部まで細かく把握することは難しくなる。

けれどもクリティカルな部分に関してはトップのアーキテクトが直接認識しなくてはならない。
細部は把握できないが全体は把握しなければならない。これは作業の大部分がAIに置き換わっても同じである。

エージェンティックコーディング、またはバイブコーディングによって、エンジニアの役割はどのように変わるか、というテーマで立て続けに講演したり出演したりする仕事が来た。おそらく業界全体が漠然とした先の見えない不安を抱えているのだと思う。

ただ、およそそれがどんなシステムであろうと、システムとの接点は結局人間だ。

たとえば今回のように追い込まれなければ、筆者はDeepSeek v4.1 Flashが本来動かないとされていた時代遅れのマシンで動いただけで満足していた。

しかし実際に実用的に使えるところまで持っていくと、色々な不満や不備が見えてきて、結局それを潰していくことは、自分にとってよりAIへの理解を深めたり、コンピュータとの向き合い方を改めて認識させてくれた。

「人間」がなにを快、不快と思うか、何を不安とするか。
こんな話がある。

サラリーマンをやめてアメリカから帰ってきたばかりの頃、アメリカで知り合った某通信キャリアの部長さんも同じタイミングで帰任していた。

その部長さんに言われて、とある大手電機メーカー(品川ではない)の開発部門に少し通っていた時期がある。ほんの数週間だったと思うが。

そこでは、新しい通信機器のソフトウェア開発で頭を抱えていた。それまで使ったことのないOSで開発していて、しかもそれがLinuxのようなオープンソースのものではなく、ガチガチのクローズドソースのものなので「一体どこで何が起きているのか」誰にもわからないという状態だった。

問題は、とにかく起動が遅いということだった。

OSの起動画面はすぐ出るのだが、そのあとのアプリの起動が遅い。ひたすら遅い。しかし、もうそのアプリは削るところがないくらいに無駄な処理を省いていた。大手電機メーカーの優秀なソフトウェアエンジニアたちは来る日も来る日も色々な組み合わせを試しては苦しんでいた。

ある日、筆者が書いたコードは、彼らのやっていることとは真逆のものだった。処理を削るのではなく、余計な処理を増やしたのである。

すると、それを見た部長が言った。

「あれ?すごく速くなってない?」

「速いですね」

「清水さん、なにをやったんですか?」

「余計な処理を増やしたんですよ」

筆者が付け加えたコードは、現在、どのフェーズまで初期化が進捗しているか表示するプログレスバーを付け加えたものだった。

純粋に計算処理という視点から見れば、無駄でしかない。しかし、プログレスバーをつけるだけで人間からは「速く動いているよう見える」という心理学的効果がある。

実はその機械も、アプリの実際の立ち上げスピードは30秒くらいだった。それにプログレスバーを表示する処理をつけたら31秒くらいにはなったかもしれない。しかし、あるとないとでは使う側の気分が全く違う。

こういうことを、いまのところAIは考えられない。

知識としては知っていても、現象として起きていることを見て「プログレスバーがあったほうが心が休まる」とは考えない。人間がハエや恐竜がどのように感じたか、まったく想像もできないのと同じように、AIにとってはプログレスバーは「できるだけ速く処理を終えろ」という命題の真逆のことを実現する余計なウェイトに過ぎない。

同じ話が、某通信キャリアのホーム画面を作っている時にもあった。

ある日、会議をしていると、別の部署の上役が慌ただしく部屋に入ってきて

「遅い!君たちのアプリは遅いんだよ!」とカンカンに怒った。
「iPhoneを見ろ!iPhoneはこんなに速いじゃないか!」

そこまでは良い。
誰かが口を開いた。

「でもですね課長、iPhoneとちがって、うちのケータイはアプリが最初から200以上入ってるんです。そりゃ同じスピードにはできませんよ」

「知るか!遅いものは遅いんだよ!」

そう言って出ていってしまった。
さてどうするか。

ただ、腑に落ちないことがある。
当時の初代iPhoneのCPUの性能と、その会社で作っていたケータイの性能はさほど大きく違いはしない。
同じような性能のCPUなら、同じことができなければおかしい。Appleだけが使える秘密の黒魔術などないのである。

そこで秋葉原に行ってカシオのカメラを買ってきた。
このカメラは高速度撮影ができるのが売りだ。秒間100フレームの高速で撮影して、スローモーションで見ることができた。今と違って、ケータイは動画撮影すら珍しかった。

そして筆者らは驚愕の発見をした。なんとスローモーションで見るとiPhoneの方が遅かったのである。
iPhoneのホーム画面で指を左右に走らせる。我々が当初作っていたホームアプリは、きっかり1/60秒遅れで指の動きに追従していた。原理的にこれ以上速くできないのだ。

ところがiPhoneは、指が滑っても全く反応しようとしない。遅すぎるくらいだ。指がだいぶ動いてしまってから、重い腰を上げたようにゆっくりと動き始めるのである。

「そうか!」

筆者は膝を叩いた。
人間は、それが速く動きすぎると、その動きが物理法則に反しているため、逆にぎこちなく見えるのである。

iPhoneのホーム画面は、わざと初動を遅らせる、いわゆるトゥイーンのイージーインという動きをさせることで物理世界との違和感を低減させ、体感的に「速い」と感じさせることができるのだ。

iPhoneの方が遅いのであれば遅い方にあわせるのは簡単である。実際、イージーインを入れると、まるで別物のようにサクサク動くようになった。実際には遅いのに体感的には速い。こういうことは、ユーザーインターフェースの世界ではよくある。

アラン・ケイはこういう一連の意図的なフェイクを「ユーザー・イリュージョン」と呼んだ。

つまり、こういうことは今のところAIにはできない。
これはユーザーインターフェースという極端に人間と機械の接点にある話だからわかりやすいが、実は同様のことは書類作成に於いても、動画作成に於いても、画像生成に於いても言える。

こうした「違和感」を感じる能力はAIにはない。

当たり前だが、AIは人間ではないからだ。