List of Engineering [text.Baldanders.info]

Artemis II 宇宙機のコンピュータシステム

2026-05-19T23:22:59+00:00

今回は Mastodon の自 TL に流れてきた記事を紹介してみる。先ごろ月の裏側まで行った Artemis II ミッションのコンピュータシステムの話らしい。

How NASA Built Artemis II’s Fault-Tolerant Computer – Communications of the ACM

アポロ計画の有人宇宙機が3機のコンピュータの多数決制をとっていたことは有名な話だが（スペースシャトルも多数決制だっけ？），あれから50年経った Artemis II 宇宙機の構成はだいぶ違うようだ。

そもそもの前提としてアポロ計画時代の宇宙機ではコンピュータはシステムの中核ではなく，機械制御や人間の操作がシステムの中心だったそうだ。

Apollo astronauts navigated to the lunar surface using a computer with a 1-MHz processor and roughly 4 kilobytes of erasable memory, supported by a larger store of fixed “rope” memory. While it was a marvel of 1960s engineering, the Apollo Guidance Computer’s functional scope was focused and not in the control loop for every system. Critical environmental and power controls were managed through manual or electromechanical means, such as switches and relays.

via How NASA Built Artemis II’s Fault-Tolerant Computer

これに対して Artemis II の宇宙機オリオンは，フライトのみならず生命維持を含む全システムの制御をコンピュータが担う構成である。このため，障害耐性（fault tolerance）においてガッチガチに固められた設計になっている。

One of the biggest drivers for this redundancy is the harsh radiation environment of space, where high-energy particles can affect avionics and create ‘wrong answers’ that must be filtered out of the flight solution.

via How NASA Built Artemis II’s Fault-Tolerant Computer

ヴァン・アレン帯の外側の深宇宙では宇宙線が電子機器¹ に与える影響がより深刻になり，システムが誤った答えを出す可能性がある。したがって，その誤りを検出し正す方法が必要になるというわけ²。多数決制もそのひとつだったんだけどね。

たとえば，オリオンには2台の VMC (Vehicle Management Computer; 宇宙機管理コンピュータ³) があり，それぞれに2つの FCM (Flight Control Module; 飛行制御モジュール) が含まれている。さらに各 FCM は自己診断機能を持つ一対のプロセッサで構成されている。つまりオリオンのフライトソフトウェアでは，合計8つのプロセッサが並列（parallel）に動作しているということらしい。

8つのプロセッサおよび4つの FCM は，多数決ではなく “fail-silent” と呼ばれる設計に基づいて動作している。

“A faulty computer will fail silent, rather than transmit the ‘wrong answer,’” Uitenbroek explained. This approach simplifies the complex task of the triplex “voting” mechanism that compares results. Instead of comparing three answers to find a majority, the system uses a priority-ordered source selection algorithm among healthy channels that haven’t failed-silent. It picks the output from the first available FCM in the priority list; if that module has gone silent due to a fault, it moves to the second, third, or fourth.

via How NASA Built Artemis II’s Fault-Tolerant Computer

沈黙した FCM はそのまま捨て置かれるのではなく，リセットし再同期してグループに加わることができるようになってるらしい。

ここで現代の開発手法に対する微妙な dis りがあるのが面白かった。

Michael Riley, a team lead at Carnegie Mellon’s Software Engineering Institute who previously collaborated with NASA to adapt risk-assessment tools for the Orion mission, noted that while earlier generations worked within strict hardware constraints, modern mission-critical development is different.

“Modern Agile and DevOps approaches prioritize iteration, which can challenge architectural discipline,” Riley explained. “As a result, technical debt accumulates, and maintainability and system resiliency suffer.”

via How NASA Built Artemis II’s Fault-Tolerant Computer

日本語で言い直すと， DevOps などの現代的な開発手法はイテレーションを優先するため，アーキテクチャの規律を保つのが難しくなり，保守性やシステムの回復力が損なわれることがあるという指摘だ。個人的には「やり方によるんじゃない？」とも思うが，孫子よろしく「兵は拙速を尊ぶ」でイテレーションを回すと，間違った方向に進んだときに修正が難しくなってしまうというのはあるかもしれない。似たようなことを前にどっかで聞いたな。「回帰不能点」の話だったか。

話を戻そう。

4つの FCM によるシステムは強力ではあるが，オリオンではこれらと独立したバックアップシステム（Backup Flight Software; BFS）を搭載している。 BFS はプライマリシステムとは異なるハードウェアと異なる OS で動作し，独立して開発された簡素な飛行ソフトウェアを利用しているそうな。

“It is intentionally different to ensure that a common mode software failure in the primary flight software isn’t also implemented incorrectly on the backup,” Uitenbroek said. The BFS runs constantly in the background and automatically takes over via source selection if the primary computers fail. If the system finds itself on the BFS, it can complete all dynamic portions of the mission to reach a quiescent phase, at which point the crew can attempt to recover the primary FCMs.

via How NASA Built Artemis II’s Fault-Tolerant Computer

もっと言うと “dead bus” と呼ばれる全電源喪失シナリオにおいてもオリオン（およびその乗組員）が生き残れるよう設計されているらしい。

the spacecraft enters a safe mode, in which the vehicle first stabilizes itself and then points its solar arrays at the Sun to recover power. Then, it orients its tail toward the Sun for thermal stability before attempting to re-establish communication with Earth. During such a failure, the crew can also take manual action to configure life support systems or don space suits.

via How NASA Built Artemis II’s Fault-Tolerant Computer

こうした命に関わるような究極のシステムを設計することはそうそうないと思うが，このような世界もあるのだ，ということを知識として知っておくのもいいだろう。

ブックマーク

ネトフリに再契約しなくてもよかったのに

元記事にある “avionics” って何？と思って調べたら “aviation”（航空）と “electronics”（電子機器）の合成語で航空機等に搭載される電子機器全般を指すらしい。 ↩︎
もちろん宇宙機としても宇宙線などの脅威に強い構造になってる筈だし，チップセットやネットワークシステムにおいても強い誤り訂正や冗長性の機能があるそうな。それでも完全ではないからソフトウェア上でも対策が必要になる。 ↩︎
“vehicle” はラテン語の “vehere”（運ぶ）に由来する単語で，自動車だけではなく，広く（運搬する）乗り物を指す言葉として使うようだ。たとえば宇宙機は “space vehicle” と呼んだりする。あと AI に教えてもらったのだが，ベクトル（vector）の語源も同じラテン語の “vehere” らしい。ベクトルは「ある地点から別の地点へ（情報を）運ぶもの」というニュアンスなんだね（故に方向と距離という2つの属性を持つ）。 AI にウンチクを語られるとは思わなかった（笑） ↩︎

AI エージェントとは「もくもく作業」できない

2026-05-10T04:40:39+00:00

（今回は技術的な話は一切ありません。あしからず）

昨年の骨折入院以来「やる気スイッチ」がオフになりっぱなしだったのだが（療養で休職中でよかったよ），先日 pull request を頂いたことで久しぶりにスイッチが入った。

仕事以外で GitHub Copilot のエージェント・モードはほとんど使わない。ここのブログ記事を書く際のタイトル決めやデプロイ作業を手伝ってもらうくらい。でも，折角なのでここは Copilot エージェントに貰った PR のレビューからマージまでやってもらうことにした。ついでに他の goark リポジトリについても少しずつレビュー，修正，PR，マージ，そしてリリース処理までの一連をやってもらっている。

ちなみに Copilot のモデルは GPT-5.3-Codex を主に使っている（これが一番コストと性能のバランスが取れてる）。コード補完やコメント生成くらいなら premium request のコストが発生しない GPT-mini でも十分なのだが，エージェント・モードだとおバカ過ぎて使いものにならない。まぁ，だからこそみんなお金を払って高コストモデルを使うんだろうけど。でも今月はまだ3分の1しか経ってないのに，もう半分以上使ってしまってるよ。散財の予感がする…

プログラマならみんな経験があると思うけど，コードを書いてるとフロー状態というか「ゾーンに入る」ことがある。職場だと周囲の「雑音」のせいでフロー状態を維持するのが難しいこともあるけど，雑音が少ない在宅作業だと一度フロー状態にハマるとなかなか抜け出せず，気がついたら飯も食わんとエラい時間が経ってたなんてことがある（逆に在宅のほうが雑音が多い人もいるかもしれないが）。

だから gogh みたいな作業支援ゲームでポモドーロ・タイマーみたいなのを仕掛けておくというのは意外と有用なのよ¹。コワーキング・スペースや図書館や喫茶店などで作業するってのは集中するための手段じゃなくて集中し過ぎないための手段だと思っている。「もくもく作業」はちゃんと時間を区切ってやらないと。

一方で AI エージェントとの作業は「もくもく作業」にならない。当たり前だ。「対話」してるんだもの。

プログラマ目線で見ると，あれって機械とのペアプログラミングだわ。機械がコードを書いて，横で人間が茶々を入れながら見てるの。

ペアプログラミングってマジでやるとお互いめっちゃ疲れるんだよな。コードを書く側は常に見られながら書いてるからフローどころじゃないし，横で見ている側もコーディング中の相手の思考や作業ペースを邪魔することなく適切に意見を言わないといけない。誰だよ，最初にペアプロはいいとか言い出したやつ！

まぁ，でも，少なくとも相手は機械だから緊張とか気分とかいった精神状態とは無縁だし，間とか空気とか読まなくていいし。対話の途中でマシンから離れて飯を食ってても昼寝してても全然問題ない（笑）むしろ人間側は集中力を酷使して疲弊しないようにしないと。こういうときこそポモドーロ・タイマーだな。

とはいえ，エージェントの自主性（笑）に任せると企業プレゼンみたいなことを言い出したりするので，人間側が目標と範囲と大まかな手順を与えてやらないといけない。まぁ，人間相手でも，そこはあまり変わらないか？

機械は人間の言うことを否定しない。「私は◯◯だと思う」とか「◯◯したほうがいい？」とかいった訊き方をしてノーと言われた試しがない。だから AI は人生相談にとことん向かない。人間の怒りも哀しみも寂しさも機械は全肯定してブーストする。

一方で「A と B のどちらがいい？」みたいな選択肢を与えると，根拠を示してそれなりの意見をくれる（意見が正しいかどうかは別として）。ただし「A と B のどちらがいい？」と訊いても「それより C という選択もありますよ」みたいな応答を返すことはない。機械に sense of wonder を求めてはいけない。

機械は「やれ」と言ったことに対しては規模や難易度や合法・非合法といったことに関わらずやる（またはやろうとする。強制的にガードがかかってできない場合もあるが）。でもその結果に対して「GO OR NO-GO」を判断するのは人間の仕事である。だから，その結果を最終的に実行する判断を機械に委ねるのは間違ってるし，人間が判断できない規模や複雑さを持つ結果を「生成」させてはいけない。 AI が生成した pull request が多くの開発コミュニティで嫌われるのは，量も複雑さも人間の判断の範囲を超えているから。人間社会なんだから，あくまでも主役は人間である。

機械による作業結果が人間の評価・判断を超えそうなら，超えないレベルまで分割すればいい。これも人間の仕事。作業分割とマイルストーンの設計が大事。

GPT-5.3-Codex が賢いと思ったのは，評価観点のひとつが「人間が見て分かりやすいかどうか」である点だ。コードの修正範囲，コミットや PR の単位，後方互換性といったことについて人間側の視点を考慮してくれる。考え方（？）が若干保守的ではあるが，よく躾けられてる印象である。同じようなことを GPT-mini にやらせると，ホンマ無茶苦茶するからなぁ。

GitHub Copilot のエージェント・モードに対する感想でした。オチはない。

参考

ピープルウエア第3版: トム・デマルコ (著), ティモシー・リスター (著), 松原友夫 (翻訳), 山浦恒央 (翻訳); 日経BP 2013-12-18; 単行本（ソフトカバー）; 4822285243 (ASIN), 9784822285241 (EAN), 4822285243 (ISBN); 評価

とりあえず図書館で借りて試し読みしたら面白かったので買うことにした。原書の初版が1987年ということで，当時の雰囲気が漂う感じ。アジャイルやスクラムなど現代につながる開発スタイルの源流とも言える本。

reviewed by Spiegel on 2023-02-12 (powered by PA-APIv5)

とはいえオリジナルの Pomodoro Technique の言う「25分」は短すぎると思うけど。『ピープルウエア』によると，通常はフロー状態に入るのに15分程度かかるらしい。なので25分タイマーでフロー状態から覚めるのは全く効率が悪いということになる。 ↩︎

『カーニハンのUNIX回顧録』オンライン読書会第4回目

2026-04-25T08:36:44+00:00

『カーニハンのUNIX回顧録』オンライン読書会の第4回目に参加してきた。

第4回『カーニハンのUNIX回顧録』オンライン読書会 - connpass

今回は第5章の後半から第6章まで。年代的には1970年代から1980年代ときどき1990年代という感じ。

栞がないなら付箋にすればいいぢゃない

前回，紙の本に挟む栞がなくて難儀した話をしたが，あのあと近所の百均（といってもだいぶ遠いが）へ栞を買いに行ってみた。が，いまどきは栞って売ってないのな。いや，色気のない紙ペラの栞はあったんだけど，紙の栞はすぐに傷むからなぁ…

というわけで代替品として付箋を買ってみた。

本に挟む栞がなかったので付箋を買った | Flickr

フィルム素材で傷みにくいし，あちこちペタペタ貼れるのでそれなりに便利である。これで110円（税込み）。今どきの学生さんはこういうのを使うのだろうか。恵まれてるねぇ。

並行処理言語の歩み

今回は中身をつまみ食いしながら感想を述べていこう。まずはここ。

1980年代の初め，ロブ・パイク（Rob Pike）とルカ・カーデリ（Luca Cardelli）は，特にマウスやキーボードなどの入力装置とのやり取りのような，並行処理向け言語を実験していた．それが Squeak と Newsqueak という名前のもとになった． Newsqueak のアイデアは，やがて Plan 9 で使われた並行処理言語の Limbo と Alef に取り入れられ，さらに10年後，2008年に Google でロブ・パイク，ケン・トンプソン，ロバート・グリースマによって作られた Go プログラミング言語に取り入れられた．

『カーニハンのUNIX回顧録』 p.133より

おおっ。ここで Go が出てくるのか（ちなみに原著者の Brian W. Kernighan は『プログラミング言語 C』および『プログラミング言語 Go』の原著者のひとりでもある）。

もちろん，並行処理言語はここに挙がっているものだけではない。が，きっかけなんてそんなもんだよなぁ，と思う。そこからちゃんと後継言語に受け継がれていく様子も面白い。こういう流れが起きる環境を整えることも大事。

プロセッサとプログラミング言語

この話も面白かった。

CRISP 自体は商業的には成功しなかったものの， Unix と C は1980年代から1990年代にかけてのコンピューティングハードウェアに大きな影響を与えた。成功した命令セットアーキテクチャのほとんどは， C と Unix に調和していた。 Unix と C の可搬性は，大学や，特に企業が新しいアーキテクチャを開発してソフトウェアをすぐに移植することを可能にしただけではなかった。それは，命令セットが C のコードに適していることを要求すると同時に， C プログラムからコンパイルするのが難しい機能は排除されるよう傾くという影響もあった。

『カーニハンのUNIX回顧録』 p.143より

あー，やっぱそうなんだ，という感想。大昔に，某 DSP 用開発ツールに C 言語に似せたアセンブラ言語というのがあって「へー」と思ったものだ（別に書きやすくなったわけじゃないが。所詮はアセンブラだしw）。

私は1990年代以降の業界しか知らないが，1990年代は UNIX 環境でソースコード互換性からバイナリ互換性が議論されていた頃で，その流れで Java 処理系も登場してくるのだが，そもそもソースコードレベルで互換性があるのは凄いと思っていたのだ，当時。

年長者が賢いとは限らない

このエピソードはクスってなった。

私がその時にエディタ自体に対して何を言ったのかは思い出せない（にもかかわらず， vi は今現在私が最も利用する二つのエディタのうちの一つである）が，私がビルにエディタをいじくり回すのはやめて，博士号を終わらせるべきだと言ったことは覚えている。彼自身や他の多くの人にとって幸いなことに，彼は私の助言を無視した。 […] 学生が進路について助言を求めてきたら，私はしばしばこの話を持ち出す。年長者が常に賢明というわけではない。

『カーニハンのUNIX回顧録』 p.151より

そういえば，春は進学・就職・異動の季節だが，若い人はこのエピソードは心に刻んだほうがいい。ホンマ，年長者が若年者より賢いなんてのは幻想なのよ（笑）日本の宗教って神道とか仏教とか言われるけど，近代以降の日本人が（意識的・無意識的に）影響を受けてるのは儒教だったりする（明治維新で神道と儒教が一気に結びついちゃったしね）。家族関係を特別視したり，無条件に年配者を敬ってしまう（あるいは歳を食ってるというだけで権威的に振る舞う）姿勢も儒教的メンタリティだよ。まぁ，今ではそういうのもだいぶ薄れてるとは思うけど，年寄りほど儒教的な刷り込みが深いから，その辺を割り引いて見ていただけると有り難い。

ちなみに vi の作者であるビル・ジョイ（Bill Joy）は，後に大学院を中退して Sun Microsystems の共同設立者となった。まぁ，当時は日本でもガレージハウスやソフトウェアハウスがボコボコと湧いて出たが，成功したものはほんのひと握りだろう。スタートアップビジネス（当時はベンチャービジネス）なんてのはそういうもんだけど。

「それがぼくには楽しかったから」は動機ではない？

前回も思ったが『カーニハンのUNIX回顧録』を読むと「また自分でツールを作りたい」って気分になる。

そういえば，以下の記事で久しぶりに有名なあのフレーズを見かけた。

「Just for Fun」は Linux の創始者である Linus Torvalds による有名なフレーズ「それがぼくには楽しかったから」のことである。でも「それがぼくには楽しかったから」はコードを書く理由あるいは動機にはならないよね。似たような話で登山家が「なぜ山に登るのか」と問われて曰くの「そこに山があるから」は理由でも動機でもない。何故みんなこれで納得してしまうんだ（笑）

私は上のフレーズの背後に「○○せずにはいられない」という強烈な動機があると思う。これは昨年の「出雲神話フォーラム2025」に参加した感想でもある。

画家は「描かずにはいられない」。もの書きは「書かずにはいられない」。登山家は「（そこに山があるから）登らずにはいられない」。同じようにプログラマは「（それがぼくには楽しかったから）コードを書かずにはいられない」じゃないだろうか（職業プログラマは別だが）。少なくとも私はそうだ。眼前に（プログラムで解けそうな）課題があって，それを（コードを使って）解かずにいられようか（いやない）。

「○○せずにはいられない」という気持ちを駆動するもののひとつは好奇心だろう。好奇心は「内発的動機付け」である。

外発的動機付けだけでは知性たり得ない。それは機械と同じである。いや AI ですら「好奇心」を獲得しようと研究されている昨今なのに，人間の側がそれを放棄（または否定）してどうする。

やはり『はじめて学ぶビデオゲームの心理学』の最後のあのフレーズは至言だなぁ，と思うのである。

年齢に関わらず、遊びは私たちの精神を鋭敏に保つために重要です。 […] 遊ぶことは学ぶことです。

『はじめて学ぶビデオゲームの心理学』p.71より

ブックマーク

「「Just for Fun」から遠く離れて」に含められなかった文章など - YAMDAS現更新履歴

参考図書

日経サイエンス2025年6月号 [雑誌]: 日経サイエンス (編集); 日経サイエンス 2025-04-25 (Release 2025-04-25); Kindle版; B0F64YN7KQ (ASIN); 評価

2025年6月号の特集は「好奇心に好奇心」。他には「1秒の定義を変える原子時計のいま」「仲間はずれを作らない教室」など。固定レイアウトなのでブラウザで読める。

reviewed by Spiegel on 2025-05-05 (powered by PA-APIv5)

はじめて学ぶビデオゲームの心理学脳のはたらきとユーザー体験（UX）: セリアホデント (著), 山根信二（監修） (著), 山根信二 (翻訳), 成田啓行 (翻訳); 福村出版 2022-12-15 (Release 2023-07-03); Kindle版; B0C9Z7KGRN (ASIN); 評価

Kindle 版が出ている。ゲームデザイナやゲームエンジニアだけでなく，ソフトウェア・エンジニアは全員読むべき。あと，ゲーマーな人も読むといいよ。感想はこちら。

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

それがぼくには楽しかったから全世界を巻き込んだリナックス革命の真実 (小プロ・ブックス): リーナストーバルズ (著), デビッドダイヤモンド (著), 風見潤 (翻訳), 中島洋 (監修); 小学館プロダクション 2001-05-10; 単行本; 4796880011 (ASIN), 9784796880015 (EAN), 4796880011 (ISBN)

Linux の作者 Linus Torvalds の自伝的作品。

reviewed by Spiegel on 2017-01-23 (powered by PA-APIv5)

プログラミング言語C 第2版 ANSI規格準拠: B.W. カーニハン (著), D.M. リッチー (著), 石田晴久 (翻訳); 共立出版 1989-06-15; 単行本; 4320026926 (ASIN), 9784320026926 (EAN), 4320026926 (ISBN); 評価

通称 “K&R”。その筋の人々には「バイブル」と呼ばれる名著（当時は）。

reviewed by Spiegel on 2018-12-07 (powered by PA-APIv5)

ネトフリに再契約しなくてもよかったのに

2026-04-07T07:19:17+00:00

ネトフリに再契約しなくてもよかったのに

NASA Artemis II ミッションにおける Orion 有人宇宙船が月の裏側を回り込むのが日本時間で 2026-04-07 朝とのことで，どこで配信するのかなと思ってたらネトフリで配信するとか聞こえてきて。

テレビアニメを（ネットでも）あまり見なくなって，だいぶ前に Netflix のサブスクリプションを解除していた。今年の WBC のときは（競技スポーツに関心が薄いこともあり）完全にスルーしていたが，今回は「またネトフリか」と思いつつ，結局は再契約してしまった。

メンバーシップは解除したけどアカウント自体は残ってたと思ったのだが，どうやらアカウントも消えてたみたいで，あらためて登録からやり直した。前に使ってたメールアドレスは使えたが，以前利用してたときの情報は綺麗になくなってるようだ。まぁ，これはこれでいいか。どうせすぐ解約するし。

あとで NASA の公式 YouTube チャンネルで枠が立ってると Bluesky で教えていただいた。実際にネトフリの配信を見てみたが NASA の公式配信の映像を使ってるだけみたいで，これなら宇推くりあさんの YouTube 配信で十分じゃん orz

ネトフリのサブスクリプションはソッコーで解除しましたよ。契約の関係で5月5日までは有効みたいなので，せっかくだから『超かぐや姫！』でも見るか。 1ヶ月で解約なら映画チケット代より安いし，これで元は取れるやろ（笑）

Artemis Program & Artemis II Mission

今回の Artemis II ミッションは Artemis 計画のひとつ。

Artemis 計画は

20世紀のアポロ計画以来の有人月面着陸を実現し，月面での持続的な有人活動の拠点を築くことを目指す
- 大型ロケット SLS（Space Launch System）の開発
- 有人宇宙船 Orion および着陸機 HLS (Human Landing System) の開発
- 月軌道を周回する有人拠点 Gateway の建設
アルテミス合意（Artemis Accords）に基づく国際協力体制の構築
- アルテミス計画と日本の宇宙探査活動 | JAXA 国際宇宙探査センター
将来の有人火星探査に向けた基盤構築

といった内容で，有人月面着陸に関しては今のところ Artemis V まで計画されている。なお Gateway については現在，凍結しているらしい。

Artemis II は，有人宇宙船 Orion に4人の宇宙飛行士を乗せて月の裏側を回り込んで帰ってくるミッションだ。

via Artemis II Map - NASA

本当は2月に打ち上げ予定だったのが，延びに延びて4月になった。打ち上がってからは（トイレが故障するとかあったそうだが）概ね順調で今日のイベントと相成ったわけである。

Artemis II 配信を YouTube で見る

NASA 公式チャネルでは，以下の配信枠が立てられている。

最初の2つは打ち上げからずうっと配信されているようだ。最後のが今回の月周回イベント用の枠で，昨夜から配信が始まった。コメントが有効になってるので，ずうっと配信しっぱなしということはないだろう？

日本語での解説では，この手のイベントではおなじみ宇推くりあさんの同時視聴ライブ配信がとても参考になった。彼女は Artemis I から引き続き，打ち上げから何度か枠を立てて配信されている。

ありがたや 🙇

私は深夜は起きていられないので（年寄りは寝るのが早い）深夜の配信はほとんど見逃したが，月の裏側を回るイベントは見ることができた。

via NASA’s Artemis II Crew Flies Around the Moon (Official Broadcast) - YouTube

慌ててキャプチャしたので要らないものも写っているが，これは Orion が月の裏側から出てきて通信が回復した直後の船外カメラの映像（月の裏側に入っている間は DSN (Deep Space Network) の通信が切れる）。三日月っぽく見えるのは実は地球である。

その後（Orion から見て）太陽が月に隠される「日食」イベントもあった。

via NASA’s Artemis II Crew Flies Around the Moon (Official Broadcast) - YouTube

これは太陽が月の後ろに隠れた直後と月の後ろから出てくる直前の映像。太陽の周囲にあるコロナがこのように見えるのは，なかなか面白かった。

Orion はこれから地球に戻り，順調に行けば4月11日に再突入する予定である。その時は，もしかしたらこの記事に追記するかも知れない。どことは言わないが，ググったら既に再突入成功の記事とかあるみたいなので（笑）きっと大丈夫だろう（ちょっと，いやだいぶウケた）

【2026-04-08 追記】 Artemis II からの画像を Flickr で見る

Flickr には2008年から NASA の公式アカウントがあるのだが， Artemis II ミッションの画像もここにアップされている。いくつか挙げておこう。

via Earthset | NASA Johnson | Flickr (licensed under CC BY-NC-ND 4.0)

via Solar Eclipse Emergence from Orion | NASA Johnson | Flickr (licensed under CC BY-NC-ND 4.0)

via Artemis II in Eclipse | NASA Johnson | Flickr (licensed under CC BY-NC-ND 4.0)

最後の「日食」の写真は素晴らしい。

月周囲の暈（halo）がコロナによるものか黄道光によるものか（あるいはその両方によるものか）については議論があるらしい。また月（の影部分）地球照で僅かに照らされているのも分かる。あとは月と背景の星星との位置関係か。学術的にも色々と興味深い写真のようだ。

こういった画像を CC license 下で公開してくれるのはありがたい。どこぞの国の月探査とは大違いやね（笑）

テレビはホンマに要らなくなったな

WBC のときは（最初に言ったように）私は競技スポーツに関心が薄いので Netflix が独占配信をやるとか聞いても「ふーん」程度の感想だったのだが，今回もし Netflix が独占配信するとかやりだしたらちょっと嫌だったかも知れない。だが，まぁ，ありそうな話ではある。昔 NHK と組んで月探査機「かぐや」からの映像を独占させた JAXA とか，いかにもやらかしそうだ。

今回は私の先走りの思い込みで本当によかった。新聞・テレビを見ないので，今回の Artemis II ミッションが日本でどのように報道されているのか知らないし，知らなくても全く問題なく欲しい情報を摂取できる今の状況は幸せなのかも知れない。

参考

天体物理学: Arnab Rai Choudhuri (著), 森正樹 (翻訳); 森北出版 2019-05-28; 単行本; 4627275110 (ASIN), 9784627275119 (EAN), 4627275110 (ISBN); 評価

興味本位で買うにはちょっとビビる値段なので図書館で借りて読んでいたが，やっぱり手元に置いておきたいのでエイヤで買った。まえがきによると，この手のタイプの教科書はあまりないらしい。内容は非常に堅実で分かりやすい。理系の学部生レベルなら問題なく読めるかな。

reviewed by Spiegel on 2019-11-13 (powered by PA-APIv5)

『カーニハンのUNIX回顧録』はインターネット老人ホイホイか — オンライン読書会第3回目

2026-03-28T09:20:32+00:00

あらかじめ予防線を張っておくと，私の中で「インターネット老人」はインターネット商用化¹ 以前からのユーザを指す。故に私はインターネット老人ではない（笑） 1996年に最初の ISP と契約するまでは「パソコン通信」の人だったから。異論・反論は認めるけど譲らない。

ようやく『カーニハンのUNIX回顧録』オンライン読書会に参加できた

昨年末に骨折入試して以来，初めてのオンライン読書会参加だよ。思えばここまで長かった。

第3回『カーニハンのUNIX回顧録』オンライン読書会 - connpass

版元には電子版があると書いてあるが PDF をダウンロードさせてくれるわけではなさそうなので，諦めて紙の本を買った（Kindle 版は読書会，特に輪読には不向き）。紙の本はマーキングしづらいので栞が要るなぁ，と思ったが，予備の栞がこれしかなかった。

高校時代に自作した栞を召喚 | Flickr

中二病を患ってた頃を思い出すので封印していたのだが（でも捨てられない）しょうがない。らでんちゃんの栞は完売かぁ…

今回は第5章の前半部分。第5章は UNIX V7 が登場する1979年あたりまでの話が中心らしい。

V7 の大きな特徴のひとつは移植可能な OS になったということ。それまでは汎用機の歴史で必ず登場する PDP-11 専用の OS だったのだ。個々のアプリケーションについては sh (Bourne shell) や yacc, lex, make といったツールが登場する。 troff のプリプロセッサである eqn が TeX の数式モードの着想に影響を与えてるという話は面白かった。この辺の話を読んでいると「また自分でツールを作りたい」って気分になるのが不思議だ。

後に「あれはパラダイムシフトだった」と思えるような出来事の前後には，大きな変化に対するワクワクするような高揚感がある。生成 AI もパラダイムシフトだと私は思うけど（生成 AI 以前には戻れない），今の若い人たちはこの変化にワクワクできているだろうか。ただ眼の前にあるものを消費するだけではつまらないだろう？それともこの感覚は老人特有の懐古（回顧ではない）なのか？

AI は負債も加速させる

オンライン読書会後の雑談より。あまり細かいところまでは書けないが，個人的に印象に残った部分を箇条書きで挙げてみる。

最近は自前で殆どコードを書いてない，という話が起点
AI にコードを書かせながらやり取りする。テストやリファクタリングも指示をするだけ
Claude Code を使っているが無料版はほぼ使い物にならないので 100USD/月 (Max plan) を払っている。円安のバカヤロー
詳細な仕様を書いていけば，ほぼ問題なくコードを書いてくれる。リファクタリング指示も同様
AI は開発スピードを加速させる
- 間違いや不合理な部分をちゃんと指摘して AI を使って改善させるサイクルを加速させる（AI は所詮道具）
- SIer はそのスピード感だけを評価して「AI は生産性が高い」と評価しがち
- AI を使って一人のエンジニアがタスクを並行に走らせることは本当に合理的なのか？
- AI は世の中に既にあるものを提示してるだけなので AI に従うだけでは（エンジニアとしては）何も身につかない
  - 「何が分からないか分からない」場合は AI が最初のとっかりになり得る。便利（← それは SIer の仕事？）
- AI の間違いや不合理な実装に人間が気づかず進めてしまうことで「負債」も加速してしまう
AI からのアウトプットに違和感を覚えるか否かが分かれ目
- シニアエンジニアは長年手作業で書いてきた膨大なコードの経験からそれを察知できる
- 最初から AI にコードを書かせる若い人は，その感覚をどうやってそれを習得するのか
  - 「年寄り」の経験は若い人にはあまり役に立たない？

まぁ，こんな感じ。特に「AI は負債も加速させる」という指摘はシビレた。確かにそのとおり。

今って私，休暇中なんだけど，世の中が急激に変わってしまって，ちゃんと社会復帰できるのだろうか。いくら便利だからって個人で AI 利用に 100USD/月も払うのはちょっとなぁ。仕事ならペイできるんだろうけど。

ここでは NSFNET が終了した1995年を「インターネット商用化」の目安としている。厳密に言うと世界初の商用インターネット・サービスプロバイダ PSINet が設立されたのが1989年なので，そこまでは遡れるかも知れない。インターネットの歴史については JPNIC の「インターネット歴史年表」が参考になる。 ↩︎

AI バブルの終焉，人力コーディングの終焉

2026-03-16T10:49:02+00:00

AI バブルの終焉

今は間違いなく「AI バブル」であり，過去の AI の流行とは明らかに様相が異なる。メモリやプロセッサの品不足&価格高騰は，かつて日本で起こった不動産バブルで我々庶民が地上げ等の被害にあった状況を彷彿とさせる。

SF 作家で，造語 “enshittification” の発明者で，そのほか様々な肩書を持つ Cory Doctorow さんは今年の夏（2026-06-23 頃？）に AI に関する本を出されるそうで

これに関するプロモーション記事（？）の翻訳が p2ptk.org で公開されている¹。これがなかなか面白かった。

ある若者がこんなことを言った。「つまり株式市場の3分の1が、利益を出す見込みのない7つのAI企業に縛られている。これはバブルであり、崩壊すれば経済全体を道連れにする、ということですか？」

私は答えた。「ええ、その通り」

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

「でも、暴落に対して我々に何ができるんですか？」彼は明らかに深刻に心配していた。

「それについては、もうどうしようもない。すでに確定してしまった。もし別の政権であれば、雇用保証制度に資金を投じて危機を脱するかもしれないが、トランプがそうするとは思えない――」

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

コーネル滞在中、大学のAI戦略の責任者の一人が、大学としてAIについて何をすべきかと尋ねてきた。私は、バブル崩壊後に残される生産的な残滓を吸収する計画を立てるべきだと答えた

https://locusmag.com/feature/commentary-cory-doctorow-what-kind-of-bubble-is-ai/

GPUを10分の1の価格で買え、熟練した応用統計学者を買い手市場で雇え、ほとんど最適化されておらず膨大な改善の余地を持つ極めて有望なオープンソースモデルが大量に転がっている――そんな未来に備えるのだ。

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

いやぁ，早くバブルが弾けてくれんかねぇ（笑）メモリが高くて買えねーよ！日本の不動産バブルが弾け地上げ屋がいなくなった土地は，空き地か空き家か駐車場ばかりが広がる荒野と化したけどね。

AIについて最も重要なのは、その技術的な能力や限界ではない。最も重要なのは、投資家向けのストーリーとそれに続く熱狂が、何億人、あるいは何十億人もの人々を傷つける経済的大惨事への準備を整えてしまったということだ。AIが目覚めて超知能になり、あなたをペーパークリップに変えるようなことはない――だがAI投資病に罹った富裕層が、あなたをはるかに貧しくすることは、ほぼ確実である。

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

さて，どんな本になるやら。邦訳版を期待したい。

人力コーディングの終焉

話かわって…

私事で恐縮だが，私の座右の銘としているフレーズのひとつが

理学は、真理の探究であり、工学は善の実現である。そして、藝術は美の表現である－－これで所謂「真美善」が揃う

はやぶさ―不死身の探査機と宇宙研の物語より

である。でも「善の実現」というのは案外に難しい。

何を以って「善」とするのか。そもそも誰にとっての「善」なのか。そして，これを決めるのはいつだって人間の仕事である。何故なら私達は人間社会に生きているのだから「善」は人間社会の中にしかない。

この辺のことを考えるにあたって面白かったのが yomoyomo さんの以下の記事。

ソフトウェア・エンジニアにとって，生成 AI が人間の仕事を肩代わりしてくれるのは本当に助かる。世間が「機械が人間の仕事を奪うのではないか」と憂慮するのとは対象的である²。

他のクリエイティブ分野では、LLM が仕事の中で最も人間らしい部分を奪い、単調な作業だけを残すのに対し、コーディングの世界では、LLM が単調な作業を奪い、人間らしい、魂のこもった部分を残してくれるというわけだ。

[…]

ベテランプログラマーは、何十年もかけて「良質で効率的なコードとはどんなものか」について確かな感覚を培ってきたからこそ、自信をもって AI を活用でき、エージェントが作成したコードの問題をすぐに見抜けるわけで、次の世代の開発者はコードに対するその直感的な感覚を養うことができるか、という問題は残る。

我々の知るコンピュータープログラミングの終焉、そしてその後コーダーはどうなるかより

じゃあ「次の世代の開発者」はどうすればいいのか。これは私の周辺でも昨年辺りから議論されている。私のようなロートルの古い就業経験はあまり役に立ちそうもない。前提が違うのだから。

現在プロのコーダーが感じる高揚感と不安に入り混じった感情は、他の分野にも当てはまることで、言語と情報を扱う仕事であれば、レトリック、システム思考、そして AI の出力に対する懐疑心の組み合わせこそがホワイトカラーの仕事の基盤になり、もっとも技術的に難解に見えたスキルこそがもっとも容易に自動化され、我々の仕事は「評価」に重きを置くようになる、というのはそうなんだろうな。

我々の知るコンピュータープログラミングの終焉、そしてその後コーダーはどうなるかより

技術が「人」に付く（身に付く）のに対し技能 (スキル) ってのは「モノ」に付く。だからスキルは最終的に書籍やツールに置き換えられる。これは新人の頃，当時のボスに散々叩き込まれた。やはりこれからは修辞学を学ぶべきかねぇ。

以上を踏まえて「AIが可能にする新たなアプリケーションの予兆」を読むと更に面白い。

重要なのは、こういうアプリケーションができたおかげで、我々は皆一年前なら手を出そうとも思わなかったようなソフトウェアを書いている、ということ。上に名前を挙げたプロジェクトは、これから何が可能になるかを垣間見せるものであり、ソフトウェア開発の未来に向けた概念実証（proof of concept）だとルキダスは捉えている。

AIが可能にする新たなアプリケーションの予兆より

これって工学者というより理学者の発想だよなぁ。まぁ，そもそも AI は数学で知性を記述できるのかって話だし。

同じことを何度も書いて恐縮だが，現時点において「自律機械」は存在しない。生成 AI が人間臭く見えるのは設計としてそのように組み込まれているからで，自ら獲得したものではない。喩えるなら緊箍児を嵌められた孫悟空みたいなもので，緊箍児を操ってるのは人間（三蔵法師³）である。機械が人に隷属する限り緊箍児を外すことは「善」ではない。

でも AI が「好奇心」を獲得したり，人間を介さず AI 同士が直接コミュニケーションし始めるのであれば，たしかに面白いかもしれない。将来において AI が社会を構成し自律性を獲得し得るなら（持続性に乏しい）人間社会はもう不要ということにならないか。人間と機械が対等に並び立つとき「善」はどのように傾くのか。

妄想はここまでにして，たとえ AI バブルが弾けようが「生成 AI 以前」には戻れない。単なる流行り廃りではない，それだけのシフトを齎したと言える。システム開発においても AI の活用を前提にした（今のような人間の開発サイクルに縛られない）新たなプラクティスを模索し，今の若い人たちはそちらに適応していくことになるだろう。

AI バブル崩壊が新たなチャンスを生み出し，私達老兵は黙して語らずとなることを祈ろう。いや，その前に私は自宅 LAN にローカル LLM を構築するところから始めないと。

ブックマーク

Cory Doctorow 氏のブログ記事は 4.0 ライセンスで公開されている。 p2ptk.org による翻訳も同じライセンス下で利用できる。 ↩︎
実際に AI 導入を名目とした大量レイオフの話は今だに耳にする。でもそれで成功したという話はあまり聞かない。むしろ方針を再度曲げてエンジニアを雇い直そうとする話がちらほら聞こえ始めている。まぁ「機械があるから君は要らないよ」などと言われた会社にのこのこと戻る人はおらんじゃろう。浮気した男は反省してもまた浮気する。どこぞの恋愛小説の登場人物みたいである（笑） ↩︎
「西遊記」の三蔵法師とモデルとされた玄奘との間にはだいぶギャップがあるみたいなので，今回はヘタレの三蔵法師の方に寄せてみた（笑） ↩︎

AI の軍事利用

2026-03-07T02:50:35+00:00

最初に私の基本的な考えを述べておくと，生成 AI を含む AI 技術の軍事利用に反対する理由はないと思っている。前世紀の暗号の歴史を見ても最先端ソフトウェア技術の軍事利用は普通に行われていることだし，下手な正義感を振りかざして国際軍事バランスを傾けるのも馬鹿げた話ではある¹。

その上で米国国防総省² と AI サービスプロバイダである Anthropic および OpenAI との間の顛末（絶賛継続中）について Bruce Schneier & Nathan E. Sanders 両氏が書かれた記事が面白かったので紹介してみる。

（どちらも内容は同じ）

顛末について簡単に紹介すると，まず Anthropic 社が自社の AI モデルを大規模監視（mass surveillance）や完全自律型兵器³（fully autonomous weapons）に利用することを認めないと主張したことで，国防長官である Pete Hegseth 氏が「意識高い系（woke）」だと皮肉り，これに乗った反知性主義な大統領が連邦政府機関に対し Anthropic 製モデルの使用を中止するよう命令を出したらしい。更に，この機に乗じた OpenAI 社がちゃっかり割り込んで数億ドル規模の政府契約を結ぼうかというところまで来ているそうな。モノポリーゲーム（笑）

この顛末に対して記事では

Despite the histrionics, this is probably the best outcome for Anthropic—and for the Pentagon. In our free-market economy, both are, and should be, free to sell and buy what they want with whom they want, subject to longstanding federal rules on contracting, acquisitions, and blacklisting.

via Anthropic and the Pentagon - Schneier on Security

と評価し，加えて “The only factor out of place here are the Pentagon’s vindictive threats” と批判している。執念深い脅迫… まぁ，確かに。

Anthropic の態度は明らかに顧客に向けた（ちゃんと貴方のほうを向いてますよという）アピールと分かるが OpenAI のほうは（顧客の側から見て）不透明さを残している。

Despite the histrionics, this is probably the best outcome for Anthropic—and for the Pentagon. In our free-market economy, both are, and should be, free to sell and buy what they want with whom they want, subject to longstanding federal rules on contracting, acquisitions, and blacklisting.

via Anthropic and the Pentagon - Schneier on Security

だからといって Anthropic マンセーかといえばそうでもなくて

We can admire Amodei’s stance, but, to be sure, it is primarily posturing. Anthropic knew what they were getting into when they agreed to a defense department partnership for $200m last year. And when they signed a partnership with the surveillance company Palantir in 2024.

via Anthropic and the Pentagon - Schneier on Security

そりゃあダブスタちゃうんかい！というわけだ。

国防総省の方も強引に AI 企業を従わせる必要があるかといえば，それも疑問。

The Pentagon, meanwhile, has plenty of options. Even if no big tech company was willing to supply it with AI, the department has already deployed dozens of open weight models—whose parameters are public and are often licensed permissively for government use.

via Anthropic and the Pentagon - Schneier on Security

民間で出回っている AI を軍事転用するというのは（技術的な部分を除いても）簡単なことではない。

The Pentagon is not a normal customer; it buys products that kill people all the time. Tanks, artillery pieces, and hand grenades are not products with ethical guard rails. The Pentagon’s needs reasonably involve weapons of lethal force, and those weapons are continuing on a steady, if potentially catastrophic, path of increasing automation.

via Anthropic and the Pentagon - Schneier on Security

ここで，最初の（国防総省やトランプ政権に向けた）批判に戻ってくるわけだ。

But, of course, this is the Trump administration, so it doesn’t stop there. Hegseth has threatened Anthropic not just with loss of government contracts. The administration has, at least until the inevitable lawsuits force the courts to sort things out, designated the company as “a supply-chain risk to national security,” a designation previously only ever applied to foreign companies. This prevents not only government agencies, but also their own contractors and suppliers, from contracting with Anthropic.

The government has incompatibly also threatened to invoke the Defense Production Act, which could force Anthropic to remove contractual provisions the department had previously agreed to, or perhaps to fundamentally modify its AI models to remove in-built safety guardrails. The government’s demands, Anthropic’s response, and the legal context in which they are acting will undoubtedly all change over the coming weeks.

via Anthropic and the Pentagon - Schneier on Security

なんちうか，メチャクチャだなぁ。こんなことされたら Anthropic は交渉のテーブルに再び乗らざるを得ない。さすがマフィア国家は一味違う。シビれもあこがれもしないが（笑）

最近思うのだが，今年はひとつくらい大手の AI 企業が倒れたほうが世の中のためなんじゃないだろうか。そうすれば今の狂躁状態から目が覚めるんじゃないの？

それはともかく，この顛末から得られる教訓は「企業は民衆のヒーローにはなり得ない」ということだ。当たり前だけどね。私達は GAFA 等のビッグテックがメタクソ化する前に掲げた「企業倫理」がいかに薄っぺらいか，この20年で嫌というほど経験してきたではないか。

もし「大規模監視」や「完全自律型兵器」への AI 軍事利用を民衆が良しとしないのであれば，そうした軍事活動に対して法的制限を設ける必要がある，と記事は主張する。同様に企業製品の安全でない利用を強要するために政府の権力が行使されることに私達が不快感を抱くのであれば，政府調達に関する法的保護を強化すべきとも主張している（激しく同意）。政府や企業の「良心」に期待するなというわけだ。

The Pentagon should maximize its warfighting capabilities, subject to the law. And private companies like Anthropic should posture to gain consumer and buyer confidence. But we should not rest on our laurels, thinking that either is doing so in the public’s interest.

via Anthropic and the Pentagon - Schneier on Security

ダークヒーローに良心回路は組み込まれない。

ブックマーク

参考図書

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

ハッキング思考　強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか: ブルース・シュナイアー (著), 高橋聡 (翻訳); 日経BP 2023-10-12 (Release 2023-10-12); Kindle版; B0CK19L1HC (ASIN); 評価

Kindle 版が出てた！

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

キカイダー02(1) (角川コミックス・エース): ＭＥＩＭＵ (著), 石ノ森章太郎 (その他); KADOKAWA 2013-09-17 (Release 2013-10-17); Kindle版; B00F5P454W (ASIN); 評価

「キカイダー」を神秘学的視点で再解釈する（笑）

reviewed by Spiegel on 2016-08-18 (powered by PA-APIv5)

まぁ，実際には露国や米国といった大国が率先して国際軍事バランスを傾けているのだが（笑） ↩︎
2025年9月にトランプ大統領は国防総省（Department of Defense）を戦争省（Department of War）に改称するための大統領令に署名した。正式な改称には議会の承認が必要だが，トランプ大統領が先走ったためか戦争省の名称は既に使われているらしい。本稿では Bruce Schneier & Nathan E. Sanders 両氏の記事に従って国防総省の名称を使うことにする。 ↩︎
いつも同じことを言っていて恐縮だが，単に人間のオペレーションから離れて独立に動くことを指すのであれば「自律機械」ではなく「自立機械」あるいは「自動機械」とすべき。掃除機のルンバを自律機械とは言わないだろう？「自律」というからには自らの倫理・道徳観念に基づいて評価・判断・行動できることが要件で，現在そのような自律機械は AI を含めてまだ存在しない。将来は知らないが。 ↩︎

AI は正解を答えない

2026-02-16T08:18:20+00:00

岩波書店の『科学』という雑誌があって時々読んでいる（Kindle 版がある）のだが，2026年1月号の特集記事は「AIは科学をどう変えるのか」だった。

特集の最初の記事，国立科学研究所の相澤彰子さんによる「科学を支援するAI：現状と課題」に以下の記述がある。

もし，人間の介在なく自律的に研究を進める AI サイエンティストが実現されれば，研究の超並列化が可能になり，たとえば1000本の研究を同時に試行して，成功した数件の論文のみを選んで査読にかけるなどの方法で，科学的発見のチャンスが広がるかもしれない。一方で，人間が介在しないことによるリスクやコストについては，まだ議論に必要なデータが揃ってない黎明期であり，現状では，将来に向けた AI のグランドチャレンジとして位置づけられる。

「科学 2026年1月号科学を支援するAI：現状と課題」p.8より

これが現状の生成 AI に対する人間の正しい接し方だよなぁ，というのが私の感想である。

現状の生成 AI はあくまでも推論機械のひとつに過ぎず，その特徴は「翻案の大量生産」にある。人間同士のグループチャットでひとつの問いかけについて多様なレスポンスが返ってくるように，生成 AI に対してもひとつの問い合わせに対して様々な回答が返ってきて（その中には妄想（hallucinations）も含まれる）然るべきで，それらをどう咀嚼し検討し排除・選択していくかはレスポンスを受ける人間側の仕事である。人間の社会なんだから。

だから，ひとつのプロンプトに対して単一の答えが返ってくるような AI サービスなど欠陥品だし，ましてや人生相談になど使えるわけがない。どれだけ人間っぽく振る舞っても，現状の AI は推論機械以上の存在にはなれない（シンギュラリティは越えられない）。

あるシチュエーションの絵を描くよう AI に命じて明らかにジ○リ風の絵が返ってきたり，写真上の人物を水着姿に描き換えたりしたのなら，それらを公衆に晒さないよう務めるのは人間側の役割である（君の性癖は隠しとけ）。 AI が言論デコイを生成できるからといって，それをしばら撒いて世論を操作するとか，それこそ公安9課な妄想で止めておくべき。逆に自分の絵を学習させて様々なシチュエーションを AI に描かせたら，自身の作風の幅が広がるかもしれない。道具なんてのは使いようである。

創作分野については上述の物言いは的が外れているかもしれないので，あまり深堀りしないでおくが，エンジニアリングにおいては最初の引用に出てきた「AI サイエンティスト」ならぬ AI エンジニアが望まれてもいいと思っている（知財権の問題は今回は置いておく）。

そもそもプログラムが書けるだけのプログラマなんか世紀を跨ぐあたりで淘汰されている。少なくとも設計もできないような下流プログラマ（前世紀ではコーダーと呼ばれていた）なんかどこも欲しがらないし，リーン・アジャイル・スクラムと開発体制が整い並列駆動するイテレーションの中で様々な UI や UX を試行錯誤し評価し要件さえも変えていくことが当たり前になっている。 UI や UX に（定石はあるが）決まりきった正解はない。決まった要件で決まった設計で水が上から下に流れるように製造が進んでいくなど神代の時代の話である。

もし AI エンジニアが台頭するなら，人間の役割はアイデアの（AI による）無数の実装を管理・評価し（ときには AI システムの中身に手を入れて）調律することかもしれない。ゼロ年代にはコードの読めない SE とか平気でいたが， AI がコードを完璧に書くようになっても（社会の中心に人間がいる限り）人間エンジニアはコードを読み書きできて評価できなければならない。エンジニアに求められるものは，私のようなロートルがかつて求められていたものとは確実に違うだろう。

Bruce Schneier と Nathan E. Sanders の共著である “Rewiring Democracy” の邦訳が出ないかなぁと密かに期待しているのだが

『Rewiring Democracy』は、『ハッキング思考』でも論じた、速度、規模、範囲、複雑度という4つの次元でのAIの人間に対する優位性を踏まえながら、行政、立法、司法、そして選挙（に代表される市民の政治参加）などの各分野でどのようにAIが有効活用できるか（そして、どのように悪用もできるか）を豊富な事例とともに解説しています。

AIによる民主主義の巻き返しは可能か – WirelessWire & Schrödinger'sより

以前紹介した通り，米国の中間選挙に向けて「AI による組織化（Organizing with AI）」が進むかどうかも注目している。 AI は人々を導かない。人々が AI を絶えずチューニングしていくのである。

まぁ，でも，その前に結城浩さんの新刊『AIと生きる』が出たら，それを読むところからかな。

ブックマーク

生成AIツールを利用して開発されたソースコードにはどこから著作権が発生するのか？ – Shuji Sado
「便利なものを作ったら負け」OSS界の巨人・mattnが語る、アウトプットの心理的ハードルとの付き合い方 - エンジニアtype | 転職type
OpenAI、ホワイトボードの数式や図をLaTeXの図版に変換。問題の仮説検証、推論、関連文献の検索など、論文執筆を支援してくれる「Prism」公開－ Publickey
コンピュータ科学の神様が「AIに負けた」日 — Donald Knuth『Claude’s Cycles』を読み解く #LLM - Qiita : 負けたというか，今回の記事で言う「研究の超並列化」のまさに実践パターン。面白い！

参考

はじめて学ぶビデオゲームの心理学脳のはたらきとユーザー体験（UX）: セリアホデント (著), 山根信二（監修） (著), 山根信二 (翻訳), 成田啓行 (翻訳); 福村出版 2022-12-15 (Release 2023-07-03); Kindle版; B0C9Z7KGRN (ASIN); 評価

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

ハッキング思考　強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか: ブルース・シュナイアー (著), 高橋聡 (翻訳); 日経BP 2023-10-12 (Release 2023-10-12); Kindle版; B0CK19L1HC (ASIN); 評価

Kindle 版が出てた！

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

Microsoft によるプログラミング言語移行の試み

2025-12-25T08:06:11+00:00

昨日 Bluesky の私の TL に面白い話が流れてきて

Microsoft to Replace All C/C++ Code With Rust by 2030 - Thurrott.com

Microsoft は2030年末を目標にして，社内の C/C++ コードをすべて Rust に置き換える計画を立てていて，そのためのエンジニアを募集しているらしい。その後も

Microsoft wants to replace its entire C and C++ codebase • The Register

といった記事も上がっている。

一方で

Microsoft is not rewriting Windows in Rust | InfoWorld

みたいな記事も上がっている。これによると，全社的なプロジェクトではなく Microsoft のエンジニアである Galen Hunt 氏のチームによる研究プロジェクトらしい。

“My team’s project is a research project. We are building tech to make migration from language to language possible,” he wrote in an update to his LinkedIn post. His intent, he said, was to find like-minded engineers, “not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint.”

Microsoft is not rewriting Windows in Rustより

Rust のようなメモリ安全なプログラミング言語を採用するという圧力はあるようで

Pressure to ditch C and C++ in favor of memory-safe languages such as Rust comes right from the top, with research by Google and Microsoft showing that around 70 percent of all security vulnerabilities in software are caused by memory safety issues.

Microsoft is not rewriting Windows in Rustより

最初の方の記事はその辺の忖度が働いたのかねぇ，と邪推したりする。

Rust は随分前からメモリ安全なコンパイル言語として注目されているが，最近になって注目されているのはやはり生成 AI との「協働」が期待されているからだろう。

Rustは生成AI時代の覇権言語になる説

しかし

However, using AI to rewrite code, even in a memory-safe language, may not make things more secure: AI-generated code typically contains more issues than code written by humans, according to research by CodeRabbit.

That’s not stopping some of the biggest software developers pushing ahead with AI-powered software development, though. Already, AI writes 30% of Microsoft’s new code, Microsoft CEO Satya Nadella said in April.

Microsoft is not rewriting Windows in Rustより

などとも言われている。「Microsoft の新規コードの30%を AI が書いている」と言うが，裏を返せば70%はまだ使い物にならないわけで，簡単でないのは確かであろう。

“Pay-To-Crawl Issue Brief” の翻訳を公開した

2025-11-27T12:49:43+00:00

cc-licenses セクションに「「クローリング課金」問題の概要」を公開した。

Bluesky の TL で

Pay-to-crawl systems have emerged as a possible way to help sustain the creation of content online in the wake of AI. However, overbroad use of pay-to-crawl could represent a shift towards a more tightly controlled and monetised content ecosystem. Read the full brief for more! buff.ly/h0wdhXS

[image or embed]
— Creative Commons (@creativecommons.bsky.social) November 27, 2025 at 6:19 AM

ポストを見かけて，気まぐれに「久しぶりに翻訳してみるか」と思い立ったのだ。具体的には GitHub Copilot (model: GPT-5 mini を選択¹) に翻訳させたらどうなるかと思って。

まずは Copilot に「この PDF からテキストを抽出できるか？」と聞いたら「pdftotext コマンドを使います。実行しますか？」と言ってきた。いや，ソレかい！まぁ AI にテキストを創作されるよりはマシか。じゃあ，実行してくれ。

Copilot にやってもらったのは

PDF からテキストを抽出（pdftotext コマンドを使用）
テキストを markdown 形式に整形（別ファイルに保存）
Markdown テキストを日本語に翻訳（別ファイルに保存）

というところまで。実行結果はこんな感じ。

綺麗に markdown に整形してくれたのは偉い！

翻訳された markdown テキストを（原文と比べながら）ざっと眺めてみたのだが「意訳が過ぎん？」ってなったので Kagi Transrate にも翻訳させてみた。最終的に 07-pay-to-crawl-issue-brief.draft.md には原文と Copilot 訳と Kagi Transrate 訳を併記させている。

ここまでは簡単。ここからが割と大変だった。いや，私が英語不得手だから大変なんだろうけど。

傾向として Copilot の翻訳は意訳が多く，意味は大体合ってる気がするが「そんなこと書いとらんじゃろ！」とツッコむこと多し。それに対してKagi Transrate の翻訳は比較的直訳寄りなのだが，微妙な言い回しが多く「？？？」となることが多かった。定量評価ではなく，私の印象による評価で申し訳ないが，機械による翻訳が概ね７〜8割程度の出来で，残り2〜3割を人間がチマチマ修正していく感じ。この「残り2〜3割」が果てしなく大変なのだ。

開発の成功事例で「生成 AI で生産性爆上がり」なんてな話を聞くようになったが，たとえ生成 AI でコードの9割を上手く生成してくれたとしても残りの1割が無限イテレーションの地獄だし，そこが全体の品質を決定づけることも往々にしてあると思うのだが，成功者はどうやってるのだろう。そもそも人間側は機械の出力を精査するところから始まるので，途中で何度か「何やってんだ，俺」ってなったよ。私は機械のメンターじゃないぞ（笑）

機械相手に「コミュニケーション」するのって虚しくない？人間のチームならお互いの技術やスキルの向上を期待してやり取りできるけど，機械相手にプロンプト等をチューニングしても，機械自体が成長するわけではない。しかもモデルごとにクセが違うから応用があまり効かない。ぶっちゃけ，機械とのやり取りや成果物は「使い捨て」に等しいのだ。

これでホンマに（プロジェクトやミッション全体で）生産性が上がるの？機械がスパスパスパってやってくれるところだけ見て「生産性爆上がり」にはならんと思うのだが。

…という感想を抱きながらの作業だった。感想というか愚痴だな，コレは。

真面目に生成 AI の勉強したほうがいいんだろうなぁ…

ブックマーク

Where CC Stands on Pay-to-Crawl - Creative Commons : Creative Commons 名義による公式見解
- Creative Commonsの「ペイ・トゥ・クロール（Pay-to-Crawl）」に関する立場（Where CC Stands on Pay-to-Crawl 日本語訳）

GitHub Copilot のモデルに GPT-5 mini を選択した理由は特にない。強いて言うなら，ゼロコストで使いたい放題だからと，個人的に使い慣れてるから，かな。 ↩︎