FPGAのちょっといいとこ見てみたい

はじめに

今日は FPGA のいいところを思いつくまま列挙してみようと思います。

思い付きで書くので、グダグダになるかもしれませんが、ご容赦を。

AIが変えるハードウェア開発 AIが変えるシリーズ

FPGA のよいところ

いろんなものが沢山繋がる

まずなによりFPGAの良いところ。

品種にもよりますが、LVTTL/LVCMOS/LVDS/SSTL/HSTL/MIPI-DPHY など各種電気信号に加え、ギガビットトランシーバーでは、PCIe/SATA/USB/DisplayPort/SLVS-EC など様々なものを見かけますし、DDR4-SDRAM なんかも繋がってしまいます。

そして I/O ピンも少ない物から多いものまでさまざまで、大きい物なら 1000ピン以上のものもあり、それらを全部同時に制御するようにもプログラミング可能です。

「秋月電子で売られているもの大体なんでも繋がる」ぐらいの誇張をしてみたくなります。

カメラやディスプレイはもちろん、様々なセンサーやアクチュエーター、リレーや光源、マイクなんかをアレイ状に沢山並べるなんていうのも面白いかもしれません。

複数のセンサーを使って集めたあなただけのデータで深層学習モデルを学習させるなんてこともできちゃいます。

まさに Physical AI にうってつけ です。

いろんなものが同時に同期制御できる

これもとても大事です。 マイコンでは基本的には１つのプログラムで１つの制御を行いますし、マルチコアCPUでもコア間をサイクル単位で同期させるのは困難です。

一方で、FPGA では複数の並列処理を、同じクロックで同期させて完全に同じサイクルでナノ秒単位でタイミングを揃えて同期実行させることが簡単にできます。

複数の照明とカメラの電子シャッターでぴったり時刻を合わせて撮影して、三角法で測量するなんてこともできますし、沢山並べたマイクを位相をずらしながらサンプリングしていくなんてことも簡単です。

さらには FPGA 内の PLL などで作ったクロックの位相をコントロールするなどすれば、本当にピコ秒オーダーで狙ったタイミングでデータの取得や出力が出来たりします。

光は 1nsec で 30cm しか飛びませんので、それこそ ToF や LIDAR のようなものを考える事すら視野に入ってくるのです。

FPGAの原理と構成

全部異なる並列計算ができる

以前こちらで、こんな絵を描きました。

CPU の SIMD(Single Instruction, Multiple Data) や GPU の SIMT(Single Instruction, Multiple Threads) などの並列演算機能は、基本的に同じ命令を同時に複数実行することしかできません。以前も書きましたがこれは並列演算できるだけデータを溜めないと効率的な演算ができないので、リアルタイム性を落とします。 また、一気に入力を吸い込んで、一気に大量の出力をしてきますので、入出力の取り扱いが、センサーなどのデバイスと相性が悪いケースがあります。

これがFPGAのパイプライン演算の場合は外部からやってきたデータを次々取り込んで、受け取ったものから計算をはじめ、終わったものから出力していきますので、多くの入力デバイスや出力デバイスと直結しやすく低遅延です。つまり Physical AI にうってつけ です。

また、パイプラインに限らず、ライフゲームのようなセルオートマトン系の並列協調演算なども得意で、リザバーコンピューティングのようなものも得意です。

さらにリソース効率の面でもこれは重要で、CPU や GPU は何でもできる万能社員を大勢用意しておいてあらゆるタスクを全員にこなさせるという事をやります。つまり万能ALUがいっぱい並んでいます。

一方で、FPGA は１芸に秀でた多様性のある社員を集めて、各々に得意なタスクだけに専念してもらいます。したがってリソース効率や電力消費で有利になる事がしばしあります。

FPGAプログラミング大全 Xilinx編 第2版

ビット演算など簡単な演算が超得意

FPGAは それこそ AND、OR などのシンプルな bit 演算や、 2～3bit 程度の数値の演算が超得意です。昨今だと量子化された AIモデルがいろいろ提唱されているのでイメージしやすいのではないでしょうか？ 他にも決定木を解くなどの論理演算なども得意です。また本物のハードウェアだと NAND演算とXOR演算ではトランジスタ数が違うところ、FPGA は LUT で行う基本ビット演算はすべて同じコストであるため、プログラマにとっては非常に見積もりやすいというソフトウェア的性質も持っています。

これらビット演算を CPU や GPU でやらせた場合、1～2bit でよい演算に 32bit 演算命令を使う羽目になったり、ビット演算中にたくさん保有している巨大な浮動小数点演算器が丸々何もせずに遊んでしまったりと、もったいないことばかり起こります。

CPU/GPU が得意な演算を FPGA にやらせても、まあ多少効率が悪いなりに何とかなしますが、逆に FPGA が得意な演算を CPU/GPU にやらせるとボロボロになります。

FPGAに得意そうな計算をいろいろ考えてアルゴリズムを工夫しなおすのも面白いのでおススメです。

リアルタイム性が高い

これはとても強い武器です。RTLで記述するすべてのプログラムにおいて、プログラマは何サイクル後に結果が出てくるか知っていますし、それは毎回きっちり同じサイクルになるようにシステムを構成することも容易です。

つまり、「データを入れたら、きっちり 1000 サイクル後に結果が出ます」なんてことが簡単にできます。 これは製造現場などで、「センサーに反応があったら 500usec後に照明を焚いて撮影して、1msec 後に正常か異常か認識結果を出して振り分けする装置を作って」みたいなことを簡単にやってのけるという事です。

他にも現実世界と相互作用するすべてのものでリアルタイム性は重要で、例えば「マウスに代わるジェスチャーデバイスをAIで作ろう」みたいなことを考えるときに、演算応答時間がばらつていたら認識結果が正しくても、マウスカーソルがちぐはぐに動くことになります。

現実世界と計算機の相互作用にはリアルタイム性はとても大事です。FPGA はまさに Physical AI にうってつけ です。

それなりに演算能力もある

そしてこのような特殊なデバイスである割に、パソコンのCPUなどと同じぐらいの価格帯の最近のミドルレンジの FPGA は、積和演算をする DSP なんかも平気で 1000個 ぐらい入っていたりします。 これは GPU などと比べると見劣りはしますが、ちょっとした画像認識程度のAIは十分実行できます。

これは FPGA でないとこなせないような特殊デバイス制御やリアルタイム性の問われる特殊領域にも十分実用的なAI が入れられるという事で、まさに Physical AI にうってつけ です。 なにも LLM が動かなければ AI じゃないなんてことは無くて「やりたいことがやれる」事が大事なんです。

TANG PriMERで始めるFPGA&Verilog入門 AI時代の高速・並列計算デバイスへの第一歩 (技術の泉シリーズ（NextPublishing）)

種類も規模もベンダーも豊富

ワンコインで買えるものから、数千万円するものまでラインナップが豊富なのも FPGA のいいところです。

ベンダーも AMD/ALTERA などの大御所から Lattice、Microchip、QuickLogic、Efinix、Achronix、GOWIN などいろんなベンダーがあります。

当然、価格や規模、欲しいI/O数や機能や、使いたいツールまで含めてとても広い選択肢を持っています。

また、以前私が 2,980円の Tang Nano 4K カメラセット で AI 認識をやってみる という暴挙に出て、Interface 2025年12号 の付録雑誌に記事を書かせて頂いたとおり、結構、小さなところから深層学習自体は応用できるんです。

まさに Physical AI にうってつけ です。

Interface(インターフェース) 2025年12号

AI を活用した開発がいい塩梅

FPGA はプログラミング以前に、ツールの理解や環境構築がわかりにくく、初学者の最初の一歩目のハードルが高めでしたが、プログラマ人口の少なさからすぐ聞ける人が近くにいないという問題がありました。

一方で今は「AIに聞けばいい」という時代になりましたので、この問題はだいぶ緩和されている気がします。

加えて、RTL(VerilogとかVHDLとか) や HLS (C++) などの FPGA の為のコード開発自体もそれなりに定型パターンについては AI が行えるようになってきています。

もっとも AI の学習の元になっているインターネット上のデータ自体が、Web系プログラムのそれに比べて圧倒的に少ない為、Web系ほど AI に丸投げは出来ない面もあります。

ただそれは悪いことではなく、世の中に事例がいくらでもあるような部分はAIに任せ、自分が本当に作りたい新規性のある部分は自分で作る、という住みわけがやりやすいことを意味します。

逆に Web系プログラミングは、もはや AI に書けない部分がなくなりつつあり、趣味プログラマがプログラミングの楽しみを奪われかけている部分さえありますが、FPGA はまだまだ「AIが学習データに持ち合わせてないような突飛なアイデアの実装」が山ほど残っているフロンティアですので、プログラミングを楽しみたい人には逆にお勧めだったりもします。 そしてレビューとかデバッグとかには AI をガンガン使えば良いわけですから、現時点では AI と 人間が Win-Win の関係になりやすい塩梅ををもった分野であるとも思います。

おわりに

思いつくままに書いてしまいましたが、「なんかFPGAって面白そう」 って思ってくれた方が一人でもおられると嬉しいです。

FPGAユーザは少ないのか？

はじめに

今回はかなり憶測交じりの駄文回です。

当ブログでは FPGA の話を取り上げることが多いわけですが、それは筆者がプログラミングデバイスとして FPGA がとても面白い対象だと思っているに他ならないです。

もちろん私は Python でデータ処理することもあるし、C や Rust でマイコンのベアメタルを書くこともあるし、CUDA プログラミングなども楽しんでいます。それでもその中でやはり FPGA プログラミングは一味違う楽しさがあると思っています。

一方で、なかなか同じように FPGA プログラミングを楽しんでいる人に出会う比率は、CPU や GPU に比べてやはり少ないなと感じています。

当ブログも、普段 FPGA や RTL の話を書いてもアクセス数は大した数では無いのですが、稀に GPU とか Rust とかの話を書くとアクセス数が跳ね上がります。これはおそらく別に記事の内容が秀逸だとかそういうのでは一切なく、FPGAユーザーに比べて 分母が非常に多い という事に他ならない気がしております。

一部のニッチ層に刺さる優良記事よりも、万人がなんとなく楽しめる普通の記事の方がまあ需要があるというか、そもそも 日本中のFPGAが趣味な人が全員アクセスしてきてもそもそも大した数じゃないのかもしれない という身も蓋もない憶測すらあります。

ということで、その原因と、どうすれば FPGA ユーザーは増えてくれるのだろうというのが今回の駄文です。

FPGAプログラミング大全 Xilinx編 第2版

そもそもデバイスがマイナーなのか？

そもそも FPGA 自体があまり製造されておらず、デバイスとしてニッチなのではないか？ という可能性もあるのですが、私はこのようなことを調べる能力はあまりありません。

私の適当なフェルミ推定より、まだAIに聞く方がマシだろうという事で某AIに聞いて表にしてもらったのが下記です。

順位	カテゴリー	推定年間出荷数	主なプレイヤー / 補足
1	マイコン (MCU)	約300億個〜	ルネサス, ST, TI。圧倒的な生活基盤。
2	スマホ用 SoC	約12.5億個	Snapdragon, MediaTek, Apple Aシリーズ。
3	PC/サーバー用 CPU	約2.8億個	Intel Core, AMD Ryzen, EPYCなど。
4	FPGA (全種合計)	約1.8億〜2億個	AMD(Xilinx), Intel, Lattice, GOWIN, Efinix。
5	単体GPU (dGPU)	約4,500万個	NVIDIA GeForce, RT/H100, AMD Radeon。

まあ AI ですので盛大にハルシネーション起こしている可能性もありますが、一旦、これを信じてみることにします。

マイコンの数凄いなと思いつつ、とりあえず、GPU よりは数は出ているようです。

という事は FPGAユーザー数やFPGAコミュニティーが GPUのそれより多くても良さそうな気もしますが、そんなことは無いような気がしてます(体感)。

そもそもトップにいるマイコンユーザーやコミュニティーが、スマホやPC/サーバーのプログラマより多いかと言うのすら怪しい気はしていて、数で決まるなら、プログラマの大半は C/C++ や 組み込み Rust プログラマになってないといけない気がしますが、そんなことは無さそうです。

逆に、これらデバイスの数だけは沢山出ているデバイスのプログラミングをしている人たちはどこに生息しているんだろうかと、不思議に思ってしまいます(苦笑)。

高度 CUDA プログラミング: GPU による高性能コンピューティング (高度GPUアーキテクチャと並列計算)

プログラミングされないプログラマブルデバイス

この理由を少し考えて見るに、１つのデバイスの上で動くプログラムが固定されるケースが多いか否かがありそうな気がします。

スマホにせよ、サーバーにせよ、パソコンにせよ、ありとあらゆるアプリが共存しており、それらがとっかえひっかえ実行されています。 つまり、デバイス当たりのアプリ収納数が非常に多い気がしています。

一方でマイコンは、「書き換え寿命の短い内蔵フラッシュに一度だけプログラムを焼いて出荷」と言った使われ方はいまだに多く、FPGA もこれに近い使われ方が多いのではないかと想像します。

要するに 大量のデバイスを少数の人間が独り占めしてプログラミングしている というのが、マイコンやFPGA界で起こっていそうなことな気がします。

再構成可能なプログラマブルデバイスのはずなのに全然再構成されていないという由々しき事態です。

職業プログラマと趣味のプログラマ

上で「独り占め」と書きましたが、こう書くと美味しいものを数人が占めてるようにも聞こえますが、実際には趣味で楽しくプログラミングしている人間の比率も実は少ないんじゃないかなと想像してみました。

「仕事で仕方なくプログラミングしてるけど、会社を一歩出たらもうFPGAの話なんかしたくない」なんて人も中にはいるかもしれません。

「仕事終わったー、FPGA開発しよ」なんて人は実は少ないのかもしれません。お仕事だと守秘義務もあるでしょうしあまり表立った活動がなされないので、オープンな情報交換の起こるコミュニティーにはなりにくい側面があるかと思います。

という事でこれも AI に推測させてみました。

プロセッサ種別	プロ : 趣味	コミュニティの性質
CPU (汎用/Web)	7:3	分母が最大。初心者からプロまで層が厚い。
GPU (CUDA等)	9:1	圧倒的にプロ寄り。 学術・業務利用が中心。
FPGA (SystemVerilog)	8:2	プロの聖域だったが、最近趣味層が急増中。
マイコン (MCU)	5:5	趣味層が最強。 Arduino等の教育・工作需要。

おっと意外なことに GPU よりも趣味な人多い可能性をほのめかしてきました。

使いやすいプログラミングキットの不在

マイコン分野で趣味な人を増やしている要因に Arduino とか Raspberry PI とか M5Stack とかそういうのはある気がしています。

一方で、FPGA にはまだまだそういうものが不足している気はしています。

個人的には、以前 妄想 したように、Arduino 的にパソコンに繋いで VS Code からボタン一発で簡単実行できて、十分な拡張I/O と、CPUをアクセラレーションできるだけの簡単な通信I/Fを持ったボード作りたいなと言うのはあります。

なかなか手が出せていませんが。なんかメモリも高騰してるし安くて良い FPGA も絞り込み切れず、モヤモヤしております。

ベンダーの開発ツールが巨大なので F4PGA みたいな OSS に走るのがいいのかもですが、ベンダーの HLS の性能も捨てがたい。あ、好きなの使えるようにすればいいのか(笑)

おわりに

なんともとりとめもない駄文になってしまいましたが、他人とちょっと違うプログラミンを嗜んでみたいという超絶趣味な人に FPGA は本当にお勧めだと思っています。

正直 GPU より速いとか遅いとかどうでもよくて、CUDAプログラミングより楽しい側面だっていっぱいある というだけじゃダメですかね？(笑)

FPGA ユーザーが増えてくれると嬉しいなと思います。

ハッカーと画家 コンピュータ時代の創造者たち

なぜFPGAがフィジカルAIで有利なのか

はじめに

似たような話は過去にも何度も書いた気がしますが、改めて少し以前に描いた絵を引っ張り出してきて整理しておきます。

身も蓋もない話、GPU向けに作られたAIモデルを持ってきた場合、しばし、性能／コスト／電力すべての項目で FPGA は GPU/NPU に惨敗するわけですが(GPU有利に作られたモデルなので当然なのですが)、それでもなおそういうモデルを FPGA-AI をやる意味というのはどこにあるのかと言うお話です。

ゼロからはじめるフィジカルAI: フィジカルAI入門

従来のAIアクセラレータの場合

フィジカルAIの前提として、物理世界からの入力(センシング)や、物理世界への出力(アクチュエーション)が何らかの形で入ってくるわけですが、従来型のAIアクセラレータであるGPU/NPUは CPU がハブになってシステムが構成される形になるかと思います。

ここで言う CPU は、いわゆるパソコン とか RaspberryPI とか Jetson とかそんな類のものをイメージしていて、GPUなりNPUなりをつけてAIアクセラレーションしているイメージのものです。

従来のAIアクセラレータの場合

ここで IoT をやれることは今どきのシステムとして必須ですが、まあ、IoT をやれる OS とリアルタイム処理を共存させるのは、いろいろと難易度が高いですし、制約も出てきます。

センサーなどのフィジカルな情報をAIアクセラレータに入れるためにも一度CPUを経由することになるので、どうしても PCIeとかEtherとかUSBとか、物理制御に向かない I/F を経由することになりますし、それら PC などに接続可能な用意されたデバイス しか繋がりません。

RT-Linux(PREEMPT_RTパッチ) のようなものや、EtherCAT のようなものや、様々な工夫はなされていますが、この形でリアルタイムシステムを扱うのはそれはそれで難易度も高く、各種の産業用規格のライセンスフィーなどでコストを押し上げる原因にもなっています。

FPGAの場合

一方で FPGA の場合、あらかじめソフトリアルタイムの世界とある程度分離して、ハードリアルタイムの世界を構築できます。

またフィジカルAIで重要な、センサーやアクチュエーターに対して、ネイティブな専用I/Fできめ細かい制御 ができます。

なにより、世の中の電子部品なら だいたいなんでも繋がる のが FPGA なので、リレーやモーター、圧力センサ、接触センサなどなどなんでも繋がりますし、イメージセンサやモニタ、マイクやスピーカなどもPC用のものよりより低遅延に接続可能です。

FPGAにおけるフィジカルAI

そしてこの勝利の方程式の出来上がった形の中にAIを入れたい場合、FPGAでAIをやる合理性 になってきます。

これが FPGA が フィジカルAI に有利な理由であろうと考えております。

もちろんこれは、GPU向けの学習モデルあっても FPGA に持ってくる意味があるという話であって、ここにさらに FPGA向けのモデルでさらに差別化を図るようなことも視野に入ってきます。

ただし毎回ここで課題になるのが、CPUとFPGAをどうつなぐか問題で、以前 FPGAを始めるときの壁 とかになりがちな気がしてます。 PCIe とか人気ではありますがお手軽ら考えたらいっそ USB とか、Zynq みたいな一体型が楽じゃないかなども思います。

おわりに

当方は、リアルタイムビジョン長らくやっておりますが、昨今は AI が無視できなくなってきています。

そういった中でフィジカルAIというのは、FPGAを活かすシステムをの上でAI をやる優位性をもたらしてくれます。

そしてやはりFPGAに適したAIやモデルの開発と言うのも引き続き価値を生み出してくれると考えています。

こういった観点でAIモデルを研究したときにも、その新規性はモデルの Accuracy であったりパラメータ数であったりではなく、このようなシステム構造の求める要件に適合させやすいモデルになっているかどうかではないかと思っています。特にレイテンシとサンプリングレートの関係は重要で、実時間システムに適合させる際にダイナミクスと演算時間も考慮に入れた誤差の低減とか、リアルタイム保証のやりやすさとか、そういったものも新規性になってくるのではないかと思う次第です。

FPGA ユーザーや、FPGAを活用する研究者が、今後もっと増えてくれると嬉しいなと思う次第です。

FPGAの原理と構成

なぜGPUはリアルタイム処理に向かないのか

はじめに

久しく CUDA プログラミングもしていないなと思いつつ、久々に Wiki で RTX5090 などのスペック眺めてたら、凄いことになっているなと思ったので自分への備忘録も兼ねて記事にしておきます。

あと、あくまで当サイトがメインとするFPGAと比べて、GPUがリアルタイム処理に向かないというお話で、FPGAがGPUよりリアルタイムに強いと言われる話を裏返して考えてみようというものです。 用途によってリアルタイムの定義も変わってきますし、GPUがデータセンターなどでの大量のデータプロセッシングで十分な応答性で高いパフォーマンスを出しているのもその通りです。

先日書いた「続・FPGAに対する誤解」や「なぜGPUは高性能なのか」を少し補完するものにもなるかと思います。

最近の NVIDIA RTX のスペック

RTX4090 と RTX5090 のざっくりと重要な数字だけ拾って換算してみました。

下記のような感じでしょうか。

	RTX 4090	RTX 5090
SM数	128	170
CUDAコア数	16,384	21,760
レジスタ数	8,388,608	11,141,120
最大スレッド数	262,144	348,160

1 つの SM に最大で 2048個のアクティブスレッド(64 WARP)を収容することができるようです。 またこの世代では 1 つの SM に 128個の物理コアが入っているようです。

GPGPUではその性能を最大限に出すためには、物理コア数以上にコア数以上のスレッドを割り当てる必要があります。 これは、実際のコアの実行でメモリアクセス待ちなどのタイミングで、別WARPを実行してパイプラインを埋めることで性能を出す仕組みになっているためです。

また、GPGPU ではスレッドの数に合わせて大量のレジスタは持っているものの、インストラクションデコーダは１つであり、基本的には「同じ演算を大量に並列で行う」ことを前提にしています。

従って最新のGPGPUで性能を出そうとすると、348,160スレッド などで並列演算できるだけのデータを用意する必要があります。

高度 CUDA プログラミング: GPU による高性能コンピューティング (高度GPUアーキテクチャと並列計算)

GPGU がリアルタイム演算が苦手な理由

ここがそのまま GPGPU がリアルタイム演算が苦手な本質的な部分に繋がります。

例えば SSD や YOLO などの画像認識では 512x512 などの画像サイズを処理しますが、512x512=262,144ピクセル でやっと RTX4090 の 262,144スレッドが埋まります。なんと RTX 5090 だとこの程度の画像だと、ピクセル数よりもスレッド収納数の方が多いことになります。

そうすると、この規模の信号処理だと、１フレーム分以上データをメモリに溜めて(バッファリングして)から計算を開始しないとパイプラインが埋まらない などといった事が平気で起こり始めてしまいます。

ここで注意点はスループット(処理性能)とレイテンシ(遅延)は異なるという事です。GPUの全演算器がフル稼働して高スループットで大量のデータを処理していたからと言ってレイテンシが小さくなるかと言うとそんなことはありません。 並列処理を行う為に一度メモリへのバッファリングした分はそのまま信号遅延(レイテンシ)になります。60fps のカメラを使うと、露光に 16.6ms、読み込んでメモリに溜めるので 16.6ms かかるので、33.3ms 経ってからやっと計算を始める という事になります。

ここから計算と出力があるので、すぐに 50～100ミリ秒ぐらいの遅れが起こるのですが、こちらの動画 を見るまでもなく、用途によってはこれは致命的です(製造分野とかドローンみたいなものとかの画像処理だともっと早く計算したいケースがあります)。

しばし、遅延の解消は非常に大きなユーザー体験の向上をもたらすのですが、この事実はあまり一般に知られていないため、ユーザーは知らない間に遅延のある状態を当たり前として慣らされてしまっている面があったりもします。

リアルタイム組込みOS基礎講座

FPGA との比較

大雑把に比較すると

• 並列演算に必要なデータ数が揃うまで溜めて、一気に並列演算するのがGPU
• データが届いた端から順にパイプライン並列で演算していくのがFPGA

と言うような言い方ができます。

当然一度、データをメモリに溜めている分、遅延とコストが増加するのが GPU です。

そして残念ながらレイテンシに関しては 今後並列度が向上すればするほど悪化する可能性がある というアーキテクチャ上の特性を持っていると言えると思います。

ただしデバッグも含めたプログラミングの難易度は圧倒的に GPU が楽ですし、遅延以外の項目でも長所／短所がお互いにあるのは過去にいろいろ書いてきた通りです。

おわりに

久しぶりに GPU のスペックをちゃんと見てみて、コアの増えっぷりに改めて驚きました。普段 16nm プロセスとかの FPGA でのほほんと遊んでる身からすると、最先端半導体プロセス恐るべし です。

GPUの発祥であるゲーム用途で、プログラミングシェーダーが出始めたころには、「ピクセルの数だけ並列化できるから、実質無限に並列化が捗る」ぐらいの勢いだったのですが、そろそろ「ピクセル数じゃ足りなくなる日が来るんじゃないか？」という予感さえしてしまいました。

いずれにせよ、GPUで性能を出そうとすれば、データを溜めれるだけ溜めて、なるべく大きなバッチで大量のスレッドを回す という方向に全力で振るべきなので、今後、コア数が増えて並列度が上がれば上がるほど、遅延(レイテンシ)と言う観点では不利になっていく可能性があるかと思います(特に産業用途とかのエッジ環境では)。ますます FPGA などとの住みわけも広がっていくのではないかと感じました。

もちろん、GPUでもデータを小分けにしてパイプライン化するなど、遅延を減らす工夫はいろいろできるのですが、それをやりだすとプログラミングの難易度が FPGA と同じになってしまいますし、本質的なところであくまで「並列処理で性能を上げる」事しかできないのが SIMT の宿命かと思います。

今後の進化の中で、GPUの特性が、ますますGPUらしく出てきたときに、他のアーキテクチャとの住みわけが再度議論されてきても面白いかなと思った次第です。

当サイトがFPGAを駆使して、ミリ秒遅延であれこれ画像処理しているのは、そういったお話に繋がってくるわけです。

FPGAプログラミング大全 Xilinx編 第2版

OPS(Operations per second)とは何なのか？

はじめに

今日は OPS(Operations per second) って何だろうという個人的疑問からの駄文です。

スーパーコンピューターやパソコンなどの性能を示す指標として FLOPS(Floating-point Operations Per Second) は昔からよく使われていたかと思いますし、多くの場合それは倍精度浮動小数点演算の能力を示していたかと思います。 また演算能力に対するメモリ帯域の性能指標である B/F (Byte per Flop) を語る際のベースとしても FLOP は重要な指標でした。

一方で、OPS(Operations per second) という単位もあり、これも昔からあるのですが、一般には FLOPS ほどは見かけない指標で、私のような組み込み分野で、浮動小数点演算器を持たないマイコンを使う 人々が良く使うものだった気がします。整数演算のみで性能を語る際に、「このマイコンはXX OPS あるから、このオーディオコーデック移植できそうだな」とかそんな用途で使われることが多かった気がします。

FLOPSに関しては x86なパソコンを例にとっても 8087 をはじめ、486DXで標準搭載されて以降、当たり前に浮動小数点演算ができるので、スパコンからパソコンまで一貫して性能比較に使える標準的な指標として長らく君臨していたように思います。

一方で、深層学習(ディープラーニング)の出現によって、これらの用語が一般の人にも認知されるようになり、さらに使われ方も深層学習の実行時性能を測るのに適した形に大きく姿を変えたものが一般に広まってきているように思います。

深層学習の出現による使われ方の変化

まず FLOPS がいつのまにやら FP64(倍精度浮動小数点) 以外を指すケースの方が見かけることが多くなってきました。

FP32での FLOPS、BF16 での FLOPS、 はては FP8 とか FP4 とかいろいろ現れています。

特に、深層学習の推論で、FP64 などまず使われませんので、GPUやNPU などの性能で謡われる FLOPS は特に何も語られていなければ FP32以下を指すことが多くなった気がします。 当然ですが、FP64 の FLOPS 値と、FP8 の FLOPS値では、計算機の総能力としては全然違うものになります。

加えて、 深層学習の推論では、浮動小数点演算を使わずに整数演算だけでやってしまおうというものを増えています。そうすると FLOPS という単位が使えなくなります。そこで OPS(Operations per second) という単位が急速に市民権を得たように思います。

そして実際 INT64/32/16 などもありますが、量子化技術により INT8/4/3/2/1 などの小さな単位の整数や、果ては b1.58 や バイナリなども現れています。

当然ですが、 INT4 の OPS値と INT8 の OPS 値でも、計算機の総能力は全然違うものになります。

また、深層学習 では、演算の多くは行列乗算の為の積和演算です。これは乗算と加算の組み合わせですが、FLOPS や OPS に換算する場合はこれを個別にカウントします。FMA命令のような複合演算命令もちゃんと2演算として数えます。 まあ深層学習向けにはあまりないと思いますが、乗算命令がなくて加算だけ沢山出来るCPUでも OPS は OPS なので、このあたりも OPS や FLOPS の中身はよく理解してカタログスペックを読み解く必要はあると思います。

もう少し踏み込むと、積和演算時、しばし、乗算よりも和の部分で、Accumulation や Reduction 演算するときは一時的に大きな桁数が必要だったりもしますので、この辺りも少し注意点だったりします(とくに SIMDなど)。

深層ニューラルネットワークの高速化 ML Systems

どのように性能を読み解けばいいのか

ここで、「計算効率のいい学習モデルを作ろう」、「効率よく計算機に実装しよう」と言った時に、どのような計算機を調達してきて、どのようなモデルを開発して、どのように実装するのかと言うのは非常に重要です。

FP32 で計算しないと精度が出ないモデルを作ってしまったら、「INT8 で 何十TOPS もある NPU を用意したはずなのに、全然性能が出ない」なんてこともあり得るわけです。

また、逆もしかりで、INT4 で十分な精度が出るのに、INT8 しか計算できない計算機を持ってきた場合、下手すると、「演算器の 3/4 と、メモリバス幅の 1/2 は、調達時の無意味な部品コストと、運用時の無駄な電力消費でしかない」なんてことになりかねません。

ちなみに、乗算器は、私が調べた範囲では深層学習に使う範囲程度なら、おむね桁数の二乗に比例する程度に思っておいて大きな誤差は無さそうです(筆算で掛け算を計算する回路を想像してみてください)。つまり桁数が倍になると4倍程度のトランジスタを使ってしまう可能性があるわけです。

ここでまた、別の罠もあって、深層学習においては、この層は BF16 が欲しいが、この層は INT4 でも十分、などといった事が起こったりもします。

このようなケースでは、「BF16 も計算できるが、モードを切り替えると4倍量の INT4 も計算できる計算機」みたいなものを良く調べて見つけてくる必要があります。

そのうえで、「私の作ったモデルは、この計算機を使えば XXX token/s 出せそうだ」とか見積もっていかないといけないことになるわけです。

逆もしかりで、計算機が先に指定されるケースもあり、「この計算機で要件の XX fps を出すには、INT8 なら XX GOPS、 INT4 なら XXX GOPS まで行ける」とか見定めて、パラメータ数や層数を逆算して学習モデルを作らないといけないケースもあるでしょう。

ようするに、ちゃんと性能を読まないと、モデル設計前に見積もれないということなのですが、正しく見積もらずに設計してる事例って結構あるあるではないかとも思ってしまうわけです。

実践的パフォーマンスエンジニアリングによるAI高速化 ML Systems

オレオレ型とオレオレ演算でも OPS を定義できるのでは？

ここで再び OPS の話に戻しますが、実はこれ FLOPS と違って かなりあいまいな表現じゃないかと個人的に思っています。

FLOPS における IEEE 754 のようなある程度同一の基準で比較できるものと比べて、「演算(Operation)」という、とても曖昧なものを扱っているため、物は言いよう といった事も出来てしまします。

FPGA などを活用すれば、オレオレ型 や おれおれ演算 なんかを定義することが可能ですが、それに対しても、「〇〇 OPS です」と言えちゃうわけです。

ここで仮に オレオレ型として MY3 という 3bit の型を作って、思いつくまま適当に「-1.1, 0, +0.1, +0.7, +1.2, 1.5+0.3i, +π, +∞」 の8種類の値を表します、みたいな好き勝手な定義をしても何も構わないわけです。MY3 と MY3 の間に四則演算以外の演算子を定義することも自由です。

ここで FPGA の 6入力 LUT を考えると、 MY3 を ２つ入力して、1つの MY3 を出力する回路は LUT が 3 個あればどんな演算でも行えますし、一部を複合演算だと言い張ることも自由です。

要するに OPS値盛り放題 と言えなくもありません(笑)。

まあ、冗談は話半分としても、作ろうとしている学習モデルに対して、もっとも最適な型を独自定義 して、それに対する もっとも効率のいい演算を独自定義 して、「それに対するモデルの精度と演算量を OPS値としてカタログスペックにする」などという事も理屈上は可能なわけです。

現在、$100 程度の FPGA でも LUT は 数十k 個は入る時代になっています。 LUT単位の演算であれば 500MHz ぐらいで動かすことも可能ですので、「数万円で 10TOPS のNPUを自作したぞ～」などという事も出来ちゃうという事です。

深層学習　改訂第２版 (機械学習プロフェッショナルシリーズ)

おわりに

先日ふと、RISC-V などのカスタム命令で馬鹿みたいにOPS値だけ謡えるSIMD命令って追加できないかなみたいなこと考えておりましたら、「そういえば OPS って単位謎だよな？ ハックすれば幾らでも盛れるんじゃないのか？」みたいな疑問を抱いて、ちょっとした駄文にしてみました。

もっとも多くの場合は、既存の GPGPU などで使える型と演算をベースに正しく議論されるのだとは思います。

一方で、「今はまだ存在しないデータ型や演算子を定義して、もっと効率よく高精度な学習モデルが作れないか？」というのもまた一つ興味深いテーマな気はしております。

そういったものを、手軽に実験してみるのにもまた FPGA は面白いデバイスなのではないでしょうか？

また普段 FPGA お使いの方も、DSP の数だけで深層学習の性能を決めてしまわずに、オレオレモデルに手を出すことで、もっとLUTでしかできない特殊な演算モデルを考えるのも楽しいと思います。

FPGAの原理と構成

システムアーキテクチャ設計とは何なのか

はじめに

業種や分野を問わず「全体を見てシステムアーキテクチャ設計できる人が少ない」というような話はよく聞きます。

私も決してそういう設計の上級者でも何でもないのですが、長いエンジニア人生の中で、平均的な人よりはちょっとだけ多くそういう設計をする機会には恵まれてきたように思いますし、何よりお仕事とは関係なく趣味でオレオレアーキテクチャは沢山作ってきましたので、一体全体システム設計だとかアーキテクチャ設計だのを学ぶのの何が難しいのかというのを勝手気ままに考察してみたいと思います。

世の中には、シンプルで美しいアーキテクチャもあれば、複雑怪奇な継ぎはぎだらけで二度と触りたくないシステムまで様々です。後者をに関しては、設計した人を「システムアーキテクチャ設計できる人」と呼んではまずいケースも多々あるので、まあそういうのも含めて考察してみようと思います。

コンピュータアーキテクチャ[第6版]定量的アプローチ

システムアーキテクチャ設計できる人が少ない理由

能力的な問題

まず人それぞれ得意不得意は必ずあります。私がいくら勉強しても英語が話せないとか、人の顔と名前覚えられないとか、絵心がさっぱりでダサいプレゼンしか作れないとか、まさにそれだと思ってます。個人的には、向かないことをわざわざ労力掛けても仕方ないので適材適所で分担すればいい話だとは思っています。

で、私の経験上、世の中には 全体はよくわからないけど部品なら作れるよ と言う人がそれなりの数いらっしゃいます。

でそういう方々にうまいこと得意分野を割り当てていって、ゴールを目指すスキルに長けている人をプロジェクトマネージャーと呼ぶわけです。

が、ここにちょっとだけ罠があって、「部品は作れるよ」という方々の中には 100点満点近い部品を作れる人もいれば、指摘や指導を繰り返してやっと60点のギリギリ及第点の部品を作れる人まで様々です。 少なくともソフトウェア開発の現場でのソフトウェア部品の個人差による品質バラツキは顕著にあるかと思います。

人間が一度に把握できるスコープは人それぞれですので、どうしても部分しか見れない人はここで壁にぶつかりがちな気がします。

一方でシステム設計できるように育っていく人は、部品がどう使われるのか、その外側の要件も視野に入れているので、部品に求められる要件の意味や行間まで考えて100点近い部品を作ってくる人が多いように思います。

スキル習得機会の問題

もう一点は、折角能力があっても、スキルを伸ばす機会がなかなか手に入らない事です。開発に携わる人間で ゴールを決める 工程に携われる機会は決して多くはありません。多くの場合は、誰かの決めたゴールを達成するための部品 を任される機会しかないのが実情でしょう。

そして私の知る範囲で、よくある２つの課題があります。

• 全体像を教えてもらえることなく、ただ部品を作ることだけを指示されるケース
• そもそもスキル習得にならない悪い見本のようなシステムの部品開発を指示されるケース

でしょうか。

特に前者は聞けば教えてもらえることもありますが、 NDA だったり組織の縦割り行政だったり、政治的理由で情報を教えてもらえないケースもあり、何に使うのかわからないまま部品を作らされるというケースがあります。

また後者も、これをそのまま受け入れてしまう人も多いのですが、それだとそれ以上成長できなくなってしまいますので、まだ、システムのダメさ加減を愚痴りながら仕事してるエンジニアの方が、全体の事を考えてる分マシなのかもしれません(まあ、愚痴るだけで終われば同じことなんですが)。

あとは最近だと、「AI が作っちゃうのでよくわからないままスキル習得にならないまま終わってしまうケース」なんてのもあるのかもしれません。

どうあれ「個々の技術を磨きながら、全体を設計する能力も磨く」という事が阻害されるケースはいろいろあるという事です。

ダメな設計はなぜ生まれてしまうのか

どこかの銀行のシステムの例を挙げるまでもなく、ダメなシステム開発と言うのは大小いっぱいあります。FPGA用の回路設計だって例外ではありませんし、ソフトウェア以外にも、機械だったり、組織の運用マニュアルだったり、いろんなシステムが世の中にあります。

多くのダメなシステムは、正しい最終イメージがアーキテクトの中で出来上がっていないとか、細部を知らない人間が間違った理解の土台の上に物理的にありえない形態をイメージしてしまったりしたまま、部分から作っていって破綻するようなケースが多い気がします。

全体を見せてもらえない／全体を見る能力がない／土台となる基礎力が無い、などの制約下で、とにかく部品を作ってくっつければなんか出来上がるだろう(というか闇雲でもなんでも前に進む以外にやれることがない)、ぐらいのノリでどんどん作ってしまったんじゃないかと言うぐらい行き当たりばったりでカオスなシステムと言うのは、まあ残念ながら世の中にあります。

要するにグランドデザインがちゃんと出来ておらず、ゴールがどこにあるかあいまいなまま作っているので、ゴールまでにあと何を作れいいのか、どちらに向かえばいいのか、あとゴールまでどれぐらいかかるんか、などがわからないまま、目の前にある課題だけが課題として上がっていく状態です。

で、作った部品の数だけで進捗管理してるから、100個作ったのにくっつけても動かない状態になった後は、進捗率が 99% のまま工数がどんどん伸びていくというあの状態ですね。納期を過ぎた後、ひたすら疲弊しながら人海戦術でデバッグして、ぎりぎり60点の合格ラインで納品するわけです。

逆に、正しい最終イメージが頭に描けるだけのスキルのアーキテクトが居る場合、あとゴールまで何が足りていないのかちゃんと把握できますし、仮にゴールが見えていない場合も ゴールが見えていないというリスク を正しく認識できるので、ゴールの位置を確認するための作業 なども正しく計画に組み入れていけるわけです。優秀なアーキテクトの居る組織ではおおむね 80点ぐらいのシステムを毎回きっちり約束通り仕上げていきますし、そのような組織の中で適正のある若者の中からは次のアーキテクトも育っていくわけです。

美しい設計はなぜ生まれるのか

ここで、経済的合理性は一旦おいておいて、100点に近い設計を考えてみます。

建築にせよ、機械にせよ、ソフトウェアにせよ、半導体プロセッサにせよ、美しいと思える設計 というのは少なからずこの世に沢山あります。美しいものはシンプルです。美しいものは機能性が高いです。美しいものは長持ちします。美しいものは時代を超えて美しいです。

もはや、お金の為に作るというよりは、匠がある種の芸術の領域に片足突っ込んで、自己満足の為に作らないと作れないような領域なのかもしれませんが、まあ確かにそういうものはあるように思います。

そして経験上、美しい設計を作っているアーキテクトは、驚くほどなんでも知ってるし何でも良く見て ます。例えばプロセッサアーキテクチャ設計で巨匠と言われるような人たちは、トランジスタレベルのロジック構造から、演算器やキャッシュの構成、メモリの特性まで熟知して、それらも極めてタイトでピーキーな部品として設計できる能力まで有した上で、最新のAIの学習モデルから半導体製造工程まで熟知してて神業みたいなアーキテクチャを設計しています。

私なんかは見ていてポーカンとなるだけなのですが、ほんと凄い人たちは凄いのです。

ハッカーと画家 コンピュータ時代の創造者たち

ここでおもむろにハッカーと画家のミケランジェロがシスティーナ礼拝堂の天井画の全ての像を自分自身で描くと 主張した話なんかをふと思い出したので、私見交じりに書くと、きっとミケランジェロの描く100点満点の作品には、100点満点の部品が揃っている必要があったのではないかなと想像してみます。

ここで言う100点満点の部品とは、例えばプロセッサを作る場合、そのプロセッサアーキテクチャ用に専用部品を作れと言ってるんじゃなくて、拘りたい部分に関してちゃんとトランジスタレベルで無駄のない綺麗な設計になってる汎用部品たれという話です。

で、冒頭の話に戻りますが、芸術観点で拘ったシステムが作りたくても、商業として部品開発者の中には 60点の部品しか作れない人がどうしても含まれてしまいますので、ミケランジェロは一切合切そういう要因を排除して拘りたかったのかな、なんて考えてみたりもするわけです。

どうすればシステム設計力が身につくのか

小さなゴールを自分で置く

一番の王道はこれじゃないかと思います。大きなゴールは初めから置かれているケースがほとんどと思いますので、自分の裁量の範囲で自分の小さなゴールを置く事です。

特にソフトウェアでは、要望された仕様を満たす部品の設計や実装方法、アルゴリズム選択は無数にある場合が多いですので、自分なりのゴールを置いてより自己満足度の高い部品を作ることを心がけることだと思います。

何よりも自分でゴールを置くという事は、完成形をイメージするという事であり、なぜそれを選択したのか一つ一つに自分なりの理由を見つけ、開発中もあと何が足りていないのか考え、不足を埋めながらゴールを目指すことができます。

そして少しづつ、大きなゴールを任されるようにポジション取りをしていくという事が重要に思います。

趣味で設計する

で、実はこっちが個人的にはメインだった気もしていて、なかなか「王道でアーキテクトが育っていくような環境をずっと維持できてる職場」と言うのは決して多くはないです。

となると仕事と言う枠を気にせずに自分でオレオレアーキテクチャを設計してみるというのが実はとても重要な気がしています。いくらでも大きなゴールを置いて挑戦することができますし、失敗しても誰も困りませんし、面白いものが出来ればOSSで公開したり、ブログ記事を書いたりすればいいわけです(笑)。

なんでもかんでも自己責任と言われてしまうこのご時世、ある程度は職場に頼らずに自分のスキルには自分で責任を持たないといけないのかもしれません。 まあ、さすがに「この先この職場環境だと能力を活かす環境が来そうにないな」とあれば転職なども選択になったりもするのかもしれませんが。

研究開発の場合どうなのか

研究の場合、「まだ誰もやってない未知のことを確認する」というのがメインタスクになります。要するに「やってみないとわからない」ので「ゴールも分からないし、進捗管理何てできるわけないじゃないか」というのもまあ、一理ある意見かとは思います。が、一方で、だからこそアーキテクト的な能力が問われることも多い気がします。

研究を行う場合、必ず何らかの仮説をもって実験を行う事になります。実験の結果仮説があっていることもあれば間違っていることもあります。

一方で、仮説を立てた以上は、正しかった場合のゴールイメージは立つはずです。そして仮説が正しいことを証明するための美しいシステムとは何か、どうすればそこにたどり着けるかを考える事は、仮説が間違っていた場合の証明もまた最短で行う事になります。

研究を一連のシステムとして、研究計画を立てて進めていく際にもシステム設計力やアーキテクト力みたいなものは同様に問われてくるように思う次第です。

おわりに

今回もかなり抽象的な駄文にはなってしまいましたが、新しいものを作るときに「そのゴールを想像してグランドデザインができる能力」と言うのは、大小問わず、研究するにも開発するにも重要な事ではないかと思います。

一方でそれらの能力は 意識的に取りにいかないと身につかない し、悪い環境にいても身につかない ので、そうなりたいと思った人がそれなりに自分で自分を育てるという事をやらないと身につかない能力なんだと思います。

「馬を水辺に連れて行くことはできても、水を飲ませることはできない」ということわざがありますが、組織も簡単に育てられる人材じゃない気がしていますし、昨今の組織は自分で育てるよりも、即戦力を中途採用したがる時代になっています。逆に言えばアーキテクトを目指す人にはリターンの大きい時代ではあるかと思いますので、是非頑張っていただければと思う次第です。

CODE COMPLETE 第2版 上 完全なプログラミングを目指して

(コーヒーブレイク) AIにSF小説書かせてみた

個人事業主になって間もなく１年ですが、初めてやってくる青色申告を前に必死に勉強しながら準備しております(まあ大半は 会計ソフトがやってくれるんですが、仕組みがわからないと安心できないのがエンジニアのサガでして)。

今、大学様と一緒に研究連携させて頂いて、論文の連名にして頂いたりとか、ぼちぼちそういう赤字の活動もしているのですが、商品にならないようなものもいろいろ試作したりしているわけで、こちらの制度 に該当するのではないかと思い、いろいろ調べたり、計算したりしていたのですが、結局１日費やしてしまいました。

freee会計を使っているのですが個人事業主向けの安いプランだとこの申告は未対応で、やるなら自分でやる必要がありそうです。 法律系の条文を読み解いて計算するというのは、エンジニアにはなかなか難易度が高いですね。

幸い今はAIがあるのと、私の父が役人だったのである程度こういう条文作ってる方々の裏側の苦労とかも多少の見聞きはしており興味は持っていたので、いい勉強にはなりましたが、金額が小さすぎて申請をためらうレベルだなとか思いつつも、正しく税金計算して納税するコストってて案外大きいな と改めて。

そして、もうちょっと理系向けの数式で表現したり、機械的に最適化したら、少しぐらいマシになったりしないものなの？ なにより もう全自動で徴税してほしい というフラストレーションを感じてみたりもしつつ。

ということで、今日、いっそお金のない世界で全部アルゴリズムに支配してもらえないの？、といったホモ・デウス に出てくるような話を AI に愚痴っておりましたら、何やらSF小説が出来てしまったので張っておきます。

いろいろ注文つけて、星新一さん風に仕上げてもらいましたが、いやはや生成AI に、コード以外にちゃんとなにか生成させたのはじめてかもです。

戯れに置いておきます。

星新一オーディオブックス〈1〉: 最後の地球人 コレクション

---

タイトル：『完璧な収支』

　エヌ氏は、窓辺に届いたリンゴを手に取り、その艶やかな皮を眺めた。 　この世界には、「お金」という言葉も「金額」という概念もない。あるのは、膨大な計算機網が編み上げる、巨大で精密な「あみだくじ」だけだ。

　エヌ氏が一篇の詩を書く。その所有権が網に吸い込まれた瞬間、彼は夕食のリンゴと、冬を越すための軽油を手に入れる。 　詩を欲した誰かのニーズが、リンゴを余らせていた誰かのニーズと、一瞬で、物理的に直結したのだ。そこには、情報の不透明さを利用して、見えないコストを上乗せする仲介者の入り込む余地などなかった。

　「実に気分がいい。昔の人は、不自由だったらしいな」

　エヌ氏は、古びた資料で読んだ「税金」という奇妙な制度を思い出した。 　かつての人類は、リンゴを買うためにまず「円」という名の数字を集め、さらにその中からいくらかを「納税」として差し出していたという。役所という建物に人々が集まり、「確定申告」なるパズルに頭を悩ませる。払いすぎた、足りない、計算が違う……。そうして集められた数字が、本当に目の前の道路に使われたのか、誰にも分からなかったのだ。

　しかし、今のアルゴリズムは冷徹に、そして誠実に働く。 　エヌ氏が散歩に出れば、一歩ごとに「道路の摩耗代」や「街灯の明かりの代金」が、彼がこれまでに提供した価値の「貯蔵分」から、一滴の無駄もなく、リアルタイムで差し引かれていく。 　申告も、徴収も、着服もない。世界は完璧な「等価交換」だけでメンテナンスされているのだ。

　「さて、残りの分を確認しておこうか」

　エヌ氏が端末を操作すると、彼がこれまで積み上げてきた「貯蔵リスト」が表示された。 　そこには「米一トン」「石油五百リットル」「最新の治療薬へのアクセス権」、そして「純金十グラム」といった、実体のある価値が並んでいる。 　これらはアルゴリズムが、世界中の倉庫や工場で常に「エヌ氏の取り分」として確保している権利だ。たとえ明日、何らかのシステムトラブルが起きても、この「実物」へのアクセス権が消えることはない。

　「これで老後も安心だ。私が若いうちに提供した価値は、こうして腐らない形で世界にストックされている。何しろ、『仲介』という名目で複雑な手数料を差し引く、得体の知れない管理者を介さずに済むのだからね」

　散歩の途中、エヌ氏は資料にあったもう一つの、最も理解しがたい記述を思い出した。 　『金利』と『インフレ』という現象だ。 　昔の人々は、何も生み出さず、何も提供していないのに、銀行に預けておくだけで数字が増えることを期待したという。その一方で、誰かがどこかで数字を刷り増やすと、昨日までリンゴ一個と交換できた数字が、今日は半分しか交換できなくなる……。

　エヌ氏は思わず足を止めた。 　「何もしていないのに数字が増えたり、何も使っていないのに価値が減ったりするなんて。それはまるで、物理法則を無視した幽霊の仕業じゃないか」

　実体のない数字に魔法をかけ、人々の労働を吸い取る。そんな、論理が崩壊した呪術のような世界で、彼らは正気を保てていたのだろうか。

　エヌ氏は、リンゴを最後の一口まで味わった。 　ふと見ると、足元の舗装路が、ほんの少しだけ輝きを増した。 　エヌ氏が今朝書いたコードが、どこか遠くの道路補修システムの効率を向上させたらしい。その「お返し」として、彼のリストに、新たな「高級肥料の優先権」が一つ付け加えられた。

　「なんて素晴らしい、合理的な世界だ」

エヌ氏は満足して歩き出した。 　そこには、銀行も、税務署も、証券会社もない。 　ただ、人々が互いに差し出した「価値」と「感謝」が、目に見えない網となって、どこまでも美しく、公平に広がっているだけだった。

---

ホモ・デウス　上下合本版　テクノロジーとサピエンスの未来 ホモ・デウス　テクノロジーとサピエンスの未来

---

（感想とか）

AI面白いこと書くな、と思いつつ、昨今の米価格の騒動とか見てると「適正な価格って何」なんてことは考えさせられてしまいます。

おにぎりが一個あったときに、それは間違いなく「おにぎり美味しい」という体験とともに「おにぎり一個分お腹が膨れる」という価値を提供してくれるわけで、安く買えても、テンバイヤーから倍の値段で買ったとしても、そのモノ自体の価値は変らないわけです。

小説の世界は、ニクソンショック前の金本位制の時代とか、加賀百万石とか言ってた江戸時代とかの価値観に近いのかもしれません。

たぶん真逆の世界観としては、すべての価値をお金で支配する世界 で、例えば政府が紙幣発行をやめて、アクセスコントロール付きのトークンとしてデジタルマネーだけを発行し

• 発行量を自在に調節してお金の価値を上げ下げする
• 消費を加速するためにお金に消費期限を付ける
• 一日の利用額を制限する／犯罪者の資産を凍結する

などなど、お金を支配することで世界を支配する世界でしょうか。

最近でも、現金で買うよりローンにしてその分NISAに入れた方が得、みたいな、モノに目が行かずお金で損得を考えてしまうパターンは増えているのですが、「いい車に乗りたい」とか「美味しいもの食べたい」とかモノや体験そのもの価値と、「今日も一日頑張って働いた」という達成感を、もう少しダイレクトに結び付けられる思考方法もあっていいのかなと思って見た次第です。