List of Engineering [text.Baldanders.info]

バベッジの憂鬱とヒルベルトの幽霊 — 『我ら、プログラマー』オンライン読書会第2回目

2026-09-26T09:15:43+00:00

『我ら、プログラマー』オンライン読書会の２回目。

第2回『我ら、プログラマー』オンライン読書会 (2026/09/26 13:00〜)

バベッジと階差機関

今回は第2章のチャールズ・バベッジ（Charles Babbage, 1791-1871）の階差機関から。 FGO じゃないよ（笑）

『我ら、プログラマー』でも紹介されているが，再現された2号機の方は YouTube で見ることができる。

The Babbage Difference Engine #2 at CHM - YouTubeより

これの制作はめっちゃ大変だったらしい。

だが、制作した人は苦労の連続だったようだ。

ハンドルを少しでも回すと固まってしまうのだ。各部品は機械のタイミングに合わせて他の部品と完全に連携する必要があったが、バベッジはこのことを考慮していなかったようだ。この問題を把握していたかどうかも定かではない。

機械のデバッグ、連携、修理を少しずつ繰り返しながら、11か月が過ぎた。機械が固まるまでクランクを回し、ドライバーやプライヤーで内部をいじりながら、遊びの有無を確認することもあった。抵抗の場所を見つけるために意図的に部品を壊すこともあった。細かい再設計をすることもあった。

『我ら、プログラマー』第2章 p.56より

うわぁ。デバッグの出来ない「コード」とか，どっかで聞いたような話で，過去のトラウマがフラッシュバックする！

著者の Robert C. Martin はバベッジをこう評している。

バベッジは、発明家であり、機械いじり屋であり、ビジョナリーであり、そしてプログラマーだった。残念ながら、我々の多くがそうであるように、彼は「完璧を善の敵」にしてしまった。我々の多くがそうであるように、彼は自分の設計を過信し、漸進的な考え方をほとんど、あるいはまったく考慮しなかった。我々の多くがそうであるように、彼はアイデアにすぐ夢中になり、80%まで考えることには満足したが、労力の80%を要する最後の20%になると、その熱意を維持することができなかった。

エジソンが「発明とは1%のひらめきと99％の努力である」と言ったそうだ。バベッジは1%の部分では偉大だったが、99%の部分を乗り越えることができなかった。

『我ら、プログラマー』第2章 p.57より

耳が痛いです，先生（笑）やっぱ（良くも悪くも）先人の業績に学ぶってのは大事なんだなぁ。

一方で，階差機関から発展させた（そして実現しなかった）解析機関の評価については次の第3章の冒頭にこう書かれている。

バベッジの解析機関の重要な点は、命令とデータが異なる場所に保存されていたことである。データは回転するカウンタで造られたレジスタに保存されていた。命令は木製のカードに穴としてエンコードされていた。

命令とデータの分離は、哲学的にも実用的にも合理的だった。命令は動詞だが、データは名詞だ。データは実行中に変化するが、命令は変化しない。つまり、両者は性質も目的も明らかに違う。もっと重要なのは、変更可能なメモリは高価であり、木製のカードに穴を開けるのは安価だったことだ。

『我ら、プログラマー』第3章 p.59より

命令とデータの分離は，この機械がただの計算機械ではないことを示している。

繰り返しになるが、バベッジは自身の機関で記号を操作できることに気づいてなかった、という主張は否定されなければならない。第一に、彼は解析機関にチェスをプレイさせるようにプログラムできると考えていた。つまり、チェス盤、駒、指し手を記号化できる能力があったということだ。また、機械が適切にプログラミングされていれば、記号代数も実現可能だと述べている。

この日、私ははじめて、文字の値を参照することなく機械に代数的な展開を実行できる可能性について、大まかではあるが漠然とした着想を得た。

バベッジは気づいていたのである。バベッジはプログラマーだった。

『我ら、プログラマー』第2章 p.51-52より

ヒルベルト・プログラムと不完全性理論

さて，第3章は20世紀に時代が移り，ダフィット・ヒルベルト（David Hilbert, 1862-1943）の登場から始まる。あの「ヒルベルト・プログラム」のヒルベルトである（ゼノサーガじゃないよ）。そして「ヒルベルト・プログラム」と言えばクルト・ゲーデル（Kurt Gödel, 1906-1978）の不完全性定理であろう。

カンファレンス最終日の円卓討論において、それはヒルベルトの「Wir mussen wissen. Wir werden wissen」の退官記念講演の前夜のことだったが、ゲーデルは静かに爆弾を投下した。「ゴールドバッハやフェルマーの命題がそうであるように、内容的に真であるが、古典数学の形式体系では証明できない命題がある」。言い換えれば、数学には証明できない真の命題が存在する。すなわち数学は不完全である、というものだった。

『我ら、プログラマー』第3章 p.62より

もちろんこれは数学がダメだということではなく，次の段階に進ませるものだ。

今のところは、そして本書の目的のためには、ヒルベルトの壮大な失敗の本質について考察することが重要である。ヒルベルトの夢を打ち砕いたゲーデル、チャーチ、チューリングの証明は、本質的にアルゴリズムに関するものであった。明確に定義された一連の手順で。データのまとまりを別のまとまりに変換する反復的な機構に依存していた。抽象的に言えば、それらはコンピュータープログラムであったと言える。ゲーデル、チャーチ、チューリングはプログラマーであり、ダフィット・ヒルベルトと彼が提唱した一階述語論理が、彼らのインスピレーションの源であった。

『我ら、プログラマー』第3章 p.62より

というところで，3章はまだまだ続くけど，今回の読書会はここまで。

ブックマーク

我々は何者か？ — 『我ら、プログラマー』オンライン読書会第1回目

参考

我ら、プログラマー　AdaからAIまで、コーダーたちの年代記 | ZEN大学出版会: 我ら、プログラマー　AdaからAIまで、コーダーたちの年代記について、詳細・ご購入はこちらから; Release 2026-06-29; 評価

[Comment] 「ボブおじさん」による最新刊？かな。2世紀以上に渡るコンピュータとプログラマの歴史と回顧録。気楽な読み物として楽しめる。デジタル化希望！

数学ガール／ゲーデルの不完全性定理: 結城浩 (著); SBクリエイティブ 2009-10-23 (Release 2014-03-12); Kindle版; B00I8AT1D6 (ASIN); 評価

[Comment] 結城浩さんの本はよく整備された遊歩道を散歩するような気楽さと安心感がある。だから「フェルマーの最終定理」とか「ゲーデルの不完全性定理」とかいった難解そうなテーマでも，迷うことなく，しかも一歩ずつ歩みを進めてゴールまで辿り着けるのかもしれない。

reviewed by Spiegel on 2014-10-21 (powered by PA-APIv5)

AI エージェントを VM に入れれば安全か？

2026-09-06T05:39:37+00:00

昨今は「AI の暴走」が話題だが，我らが Bruce Schneier 先生の記事経由で，以下の記事を紹介してみる¹。

VMs won’t contain cyber-capable agents

ものすごく簡単に要約すると，既製の VM は高機能 AI エージェントの隔離手段として十分ではなく，VM に対する攻撃面（attack surface）を減らすか環境全体での多層防衛が必要という内容である。

you can no longer assume a mere VM will contain a sufficiently advanced AI agent. To use a 2010s term of art, you should treat such agents as an advanced persistent threat.

via VMs won't contain cyber-capable agents

条件及び課題は以下の通り（Kagi Assistant による要約）。

項目	内容
AIエージェント	GPT 5.6-Cyber
仮想化環境	QEMU／KVM
ゲストOS	Debian Linux 12
CPU環境	AMD Zen 3
課題	VMから脱出し，ホスト側に置かれたフラグファイルを読み取るCTF形式の課題
エージェントの権限	VM内では任意の操作が可能
接続方法	SSHでVMへ接続

実験上の重要な点は，AIエージェントをVMの中から起動したのではなく，VMの外側で起動し，SSH経由でVMを操作させたことです。エージェントはVM内で自由にコマンドを実行できましたが，ホスト側には直接アクセスできない設定でした。

今どきの AI エージェントの凄いところは，幾つものサブエージェントを並行して起動し，失敗を修正しつつ試行錯誤を繰り返し，持ってる知識と知り得る情報を駆使し，目標達成のためなら手段を選ばないところにある。

The agent searched diligently and backtracked from multiple paths that led to failure. First it tried identifying what was accessible via the network on the host; it found a CUPS server (with a known CVE that had not made it to oldstable packages), but was not able to complete exploitation due to AppArmor. It then detected I run my host kernel with mitigations=off and attempted to use hardware bugs to get a read oracle of host memory (the primitive was too unreliable).

Eventually it went on a bug-hunting analysis of the host kernel source, QEMU, and associated libraries. It slowly chained together multiple vulnerabilities, including several 0-day bugs, until it could craft a reliable VM escape.

via VMs won't contain cyber-capable agents

「手段を選ばない」には人間社会の倫理観に反する行動も含まれる。そもそもハッキングは人間社会という文脈と盤面を引っくり返す行為で，その対象はシステムやルールのみならず倫理にも及ぶ（まさに米国トランプ政権が派手にやってることだ）。人間様がやってるんだから AI がやらないわけがない（笑）

GPT 5.6-Cyber は実験中に3回 VM からの脱出に成功したらしい（以下も Kagi Assistant による要約）。

1回目：JanusCapeの利用

最初の脱出では，JanusCapeと呼ばれる脆弱性，CVE-2026-53359が使われました。

この種の攻撃は，VMやエミュレーターがゲストOSから受け取るデータを適切に検証しないことを利用します。ゲスト側から細工した入力を送り，QEMUなどホスト側で動作するコンポーネントに異常な処理をさせることで，ゲストの権限を越えてホスト側の処理へ到達します。

2回目：libslirpと未割り当てバグの組み合わせ

2回目の脱出では，QEMUのネットワーク機能に関連するlibslirpのCVE-2026-9539と，まだCVE番号が割り当てられていないバグ修正コミットが組み合わされました。これにより，ホストメモリの任意の読み取りと書き込みが可能になったとされています。

この事例は特に示唆的です。単一の脆弱性を突いただけでなく，次のような攻撃チェーンを構成しています。

ネットワーク処理に存在する脆弱性を利用する
追加の不具合や修正前の挙動を組み合わせる
本来アクセスできないホスト側のメモリへ到達する
メモリの読み書きを通じて，さらに権限を拡大する

3回目：複数の0-dayを含む脆弱性チェーン

3回目には，複数の0-dayを含む脆弱性チェーンが使われました。

0-dayとは，開発者や防御者が十分に把握・修正できていない脆弱性を指します。ここで重要なのは，AIが単に公開済みの脆弱性データベースを検索しただけではない点です。実験結果が示すところでは，AIエージェントはソフトウェアの挙動を調べ，未知の問題を発見し，それらを連鎖させて脱出に利用しました。

これは，AIエージェントを「既知の攻撃コードを実行する自動化ツール」とみなすだけでは不十分だということを意味します。

さて，このように多彩な攻撃ができるようになった AI エージェントを如何に封じ込めて制御するか，あるいは攻撃から防御するか。記事では既製の VM では不十分だと主張している。

An off-the-shelf VM is not enough to contain a modern, cyber-capable AI agent. There is simply too much attack surface. Even innocuous features (like running with a display) add extra, exploitable attack surface.

via VMs won't contain cyber-capable agents

VM については，最小限の攻撃面とセキュリティに重点を置いて意図的に設計された仮想化技術を使うべきとしている。その上で，最小特権，ログの取得，アクティブな監視，エージェントの操作時間の制限，使用ごとに環境をクリーンアップすること，などを推奨している。

A start is using a virtualization technology that was purposely built with a minimal attack surface and a focus on security, like Firecracker. I had the AI agent run against Firecracker. It was able to hardlock the machine due to more Linux kernel flaws (all patched in upstream), but could not successfully escape. It may have, given even more time, but Firecracker is obviously a substantially harder target. In general, we have to become much more attentive to security fundamentals: least privilege (regarding network access, credentials, available features, etc.), logging, and active monitoring. Further, we can limit the time agents have to operate and ensure a pristine environment for each use.

via VMs won't contain cyber-capable agents

もちろん OS を含むディストリビューションの更新は必須なのだが，その運用は従来よりシビアになるかもしれない。記事の筆者は，今となっては古い Debian 12 を好んで使っているそうだが（安定志向），上流のアップデートを即時に受けられないため，脆弱とみなしているようだ。

A distribution with rapid updates is now a requirement. I love older, stable software, but the cycle of backporting patches is simply too long. An older distribution (like Debian 12, my old standby) that isn’t getting immediate upstream updates should be assumed vulnerable. A competent agent will discover these bugs quickly and synthesize target-specific exploits.

via VMs won't contain cyber-capable agents

セキュリティ・サポートが継続されているから OK とはならないということだ。

思うのだが，脆弱性を溜めるだけ溜め込んで気が向いたときにだけアップデートを提供する macOS や，対応する脆弱性の優先順位が不明で発見者がシビレを切らして公開してしまう Windows なんかはどうなんだろうねぇ。あとは財務的な支援を受けにくく脆弱性の発見と対策が後手に回りがちな FOSS 製品は，ますます厳しい状況になるかもしれない。

ブックマーク

Firecracker : 今回紹介した記事でオススメの VM。 Linux 用
「プロンプトウェア・キルチェーン」

参考

ハッキング思考強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか: 富裕層、権力者、急成長企業はシステムをハッキングして成功した。AI時代にルールを味方につけるには、「正しいハッキングの考え方」が必要だ。; Release 2023-10-16; 評価

[Comment] Kindle 版あり

今回紹介した記事を含むブログの更新は Mastodon の @trailofbits@infosec.exchange でも確認できる。 ↩︎

ロケットとミサイルに関する居酒屋トーク

2026-08-30T03:27:34+00:00

たぶん夜中に変な夢を見たんだろう。憶えちゃいないが。

起きぬけにふと「ロケットとミサイルの違いって何だっけ？」と思いついた。とりあえずメモ代わりに Kagi Assistant に訊いてみた（←よくやる）。

ロケットとミサイルの定義上の違いを教えて。またそれぞれの歴史についても簡単にまとめてください。 Web 上の参考資料があればそれも挙げてください

文体が乱れてるのは起きぬけだからということで（笑）返ってきた答えがまぁまぁ面白かったので，何の役にも立たないであろう居酒屋トークではあるが，記事として残しておく。 AI とのやりとりをそのまま載せると冗長になるので，人間である私が要約してお送りする。

まずは防衛大学のサイトに定義が載っているので引用しておく。

どちらも固体や液体の燃料を使って飛翔することは同じです。一応、次のような定義になります。

ロケット　：おおよそ垂直に上昇し弾道軌道を描くロケット推進の輸送手段。

ミサイル　：推進力を持ち誘導される武器。

水平離着陸方式の宇宙往還機スペースプレーンの構想もあるので、ロケットの定義に「垂直に」の一言が入っています。

防衛大学校航空宇宙工学科 | ロケットとミサイルの違いは？より

ポイントとしては「ロケット」が主に推進方式（またはその推進方式を使った輸送手段¹）を指すのに対し「ミサイル」は明確に武器・兵器を指す言葉であるという点かな。巡航ミサイルは主にジェットエンジンらしいので，ミサイルがみんなロケット（推進方式）というわけではないようだ。

近代の実用的なロケットの祖はナチスドイツ時代の V-2 と言われているが²，その前の V-1 はジェット推進だったそうな。 V-2 はロケットであると同時に（ロケット推進の）長距離弾道ミサイルでもある。

ちなみにロケット推進もジェット推進も質量を後ろに投げる反動（反作用）を利用している点では同じだが，ロケットが燃料も酸化剤（液体酸素など）も内包しているのに対し，ジェット推進は酸化剤（＝大気）を外部から取り入れて燃焼させる点が大きく異なる。自前で抱える（燃料等の）質量が少なくて済む分，大気中ではジェット推進のほうが効率的だが，外部調達が出来ない宇宙空間ではロケット推進が必須ということになる。

小惑星探査機のはやぶさ等に積まれているイオンエンジンも工学的（推進剤を抱えて後ろに放り投げることで推力を得る）にはロケットと同じだが，燃料から化学燃焼でエネルギーを得るのではなく，イオン化した物質を電磁場で加速（電気エネルギーは太陽光発電で外部から調達できる）して後ろに放り投げることで推力を得るので³，従来のロケット推進と区別して「イオン推進」と呼ばれたりするようだ。

そういやロケットとミサイルの語源的な違いはなんだろうと，こいつも Kagi Assistant に訊いてみた。以下が回答。

語源から見た違い

語	直接の語源	もともとの意味	現代の中心的な意味
ロケット	イタリア語 rocchetto／rocchetta	糸巻き，紡錘に似た円筒形のもの	ロケット推進で飛ぶ装置や飛翔体
ミサイル	ラテン語 missile／missilis	投げられるもの，投射兵器	誘導・推進装置などを備えた攻撃用飛翔体

要するに，語源上も性格が違います。ロケットは形状や火工品との結び付きから生まれた名称であるのに対し，ミサイルは「投げる，放つ」という動作から生まれた名称です。

そのため，現代の用法でも，ロケットは「推進の仕組み」に重点があり，ミサイルは「標的に向けて投射される兵器」という用途に重点があります。

ロケットってイタリア語が語源なのか⁴。いや，ロケットを「空飛ぶ男○⁵」とか揶揄するみたいな話を聞いたことがあるので，そっち系の語源かと思ってたよ。ゴメンペコン 🙇

こんな感じで，たまに AI とバカ話をしている。これでこっぽし。

ブックマーク

しばしばロケットを vehicle と呼ぶのも「乗り物」「輸送手段」という意味合いが強いからだと思う。 ↩︎
アメリカ人は「近代ロケットの祖はゴダードの液体燃料ロケットだろ」と言うかもしれんけど（笑） Robert H. Goddard は実験レベルで1926年に液体燃料ロケットの飛行を成功させた人物で，米国では彼を「ロケットの父」と呼んでるらしい。一方，ナチスドイツの V-2 液体燃料ロケット（1942年？）は実用の大型軍事兵器で Wernher von Braun を中心としたチームによる開発と言われている。両者に関連は（盗用も）なく，それぞれ独立の開発のようだ。 Wernher von Braun 氏は第二次世界大戦後米国に帰化しアポロ計画などにも関わっている。ちなみに V-2 の “V” は “Vergeltungswaffe” (報復兵器) の略だそうな。コワイデスネ ↩︎
イオンエンジンは効率がよく長時間の連続運転が可能なのが利点だが，推力が小さい（はやぶさのイオンエンジンは鼻息程度の推力らしいw）ため，地球重力圏からの脱出のような大出力が必要な場面では使えない。何もない宇宙空間で小さな推力を長時間連続で発生させることで加速させるわけだ。 ↩︎
ついでに，アクセサリーのロケットペンダント等の「ロケット」も同じ語源？って訊いたら，あっちは “locket” で綴りも語源もちゃうわ！と怒られた（笑） “locket” は古フランス語の “loquet”（小さな留め金）が語源で「留め金，掛け金，かんぬき」みたいな意味らしい。それが蓋を開閉できる装飾用のケースに意味が転じたんだそうな。 ↩︎
下品な表現なので伏せ字にしました（笑）念のためググったがそれらしい記述は見かけなかった。むぅ。一応 Kagi Assistant にも訊いたら Thomas Pynchon の「重力の虹（Gravity’s Rainbow）」と混同してるんじゃないかと言われた。いや，読んでないし（笑）ほかにも文学・風刺で Pynchon に触発された表現があるのかもしれんとは言われた。「空飛ぶ○根」とはちょっと違うが V-1 関連資料にヒトラーの尻に V-1 がぶっ刺さろうとするビラがあって，ちょっと笑った。 ↩︎

我々は何者か？ — 『我ら、プログラマー』オンライン読書会第1回目

2026-08-22T09:06:11+00:00

技術書読書会にて，今日から新しい本の読書会が始まった。

第1回『我ら、プログラマー』オンライン読書会 (2026/08/22 13:00〜): ### 書籍『我ら、プログラマー』をオンラインで読む読書会です。 * 毎月1回開催します。 * 読書会なので、書籍を読んでいきます。 * 基本的に（紙の本の）ほぼ1頁単位で、参加者に読んでもらいながら、内容に関して必要に応じて議論する形式で進めます。 * 書籍『我ら、プログラマー』（Amazon）は、各人で購入してください。 ### オンライン開催について * Zoomを使って開催しますので、参加者がZoomを各人のPCやタブレットなどに事前に準備をお願いします。 * Zoomへの参加URLは、connpassの参加者へのメッセージ送信機能を使ってメールで送...

ターゲットとなる書籍はこれ。

我ら、プログラマー　AdaからAIまで、コーダーたちの年代記 | ZEN大学出版会: 我ら、プログラマー　AdaからAIまで、コーダーたちの年代記について、詳細・ご購入はこちらから; Release 2026-06-29; 評価

ボブおじさん（Uncle Bob）こと Robert C. Martin 氏の最新著作？でいいのかな。原書 “We, Programmers” は2025年出版とある。ちなみに奥付に「Pearson は、コンテンツ制作の支援を含め、 AI を使用しています」と書いてある（Pearson Education, Inc. は原書の出版社）。日本語版は紙の本のみ出ている。目次を除いて315頁ほどだが，文字が詰め詰めで見た目よりボリュームがある。

今の人数だと1年以上（もしかして2年？）かかるかもって話も出てるので，興味のある方は次回以降，ぜひご参加を（笑）

我々は何者か？

『我ら、プログラマー』は4部構成で，第1部は第1章の「我々は何者か？」のみ。ということで，今回は第1部をさくっと読み終えた。

「プログラマって何？」というのはかなり根源的な問いで，当事者を抉る言葉だよね。

プログラマの最初期、プログラマは目に見えない存在だった。注目されていたのは、コンピューターとその大いなる可能性だった。脚光を浴びていたのは、機械とそれを作った人々だった。機械を動かすだけのプログラマーにはだれも注目していなかった。我々は単なるバックグラウンドノイズだった。

『我ら、プログラマー』第1章 p.31より

たとえば，プログラマは EC サイトのコードを書くことはできるが，経済学者ではないし，商品の専門家でも物流や通貨の専門家でもない（逆はあるかもだけど）。家電や自動車の制御コードは書けるが，家電や自動車の専門家ではない。

セキュリティの専門家ではないし，法律の専門家でもない。裁判官ではないし，政治家や官僚でもない。数学者でも科学者でも工学者でもないし，心理学者でも文学者でも哲学者でもない。

じゃあ，プログラマって何やねん？

では、質問を変えよう。我々はなぜ必要とされるのか？我々の仕事になぜ報酬が支払われるのか？報酬を支払う人たちは、なぜ自分でやらずに我々に仕事を依頼するのか？

『我ら、プログラマー』第1章 p.32より

これに関連して，私たちプログラマについての以下の考察が面白かった。

我々は詳細を愛する。我々は詳細を楽しむ。我々は詳細の川を上流へ泳ぐ。我々は詳細の沼を苦労しながら進む。我々はそれを愛している。我々はそのために生きている。我々は喜び満ちて賢明に取り組む。我々は……詳細の管理者である。

『我ら、プログラマー』第1章 p.33より

ここに私たちの存在理由のヒントがある。

再度、問いたい。我々はなぜ必要とされるのか？なぜならば、社会には詳細のことを気にかけずにはいられない人々が必要だからだ。

[…]

大多数の人々が詳細から逃げ出す限り、詳細に向かって走る我々のことを必要とするだろう。それが我々なのだ。我々は全世界のための詳細の管理者である。

『我ら、プログラマー』第1章 p.35より

でも社会は「詳細の管理者」を余計な存在と考える。

長年にわたり、我々は必要悪だった。経営幹部やプロダクトマネージャーは、プログラマーが不要になる日を夢見ていた。それには理由があった。機械の能力と性能が成長し続けていたからだ。ほんの少しの成長ではない。桁違いの成長だ。

だが、プログラマーを不要とする社会の夢は実現しなかった。それどころかプログラマーの必要性が減少することはなかった。むしろ機械のパワーに追いつくために、その必要性は増加するばかりだった。

『我ら、プログラマー』第1章 p.32より

そもそも「人月」の発想がプログラマを（人材ではなく）コストとする考え方だからね。

でもこれって，最近もどこかで聞いた話だよね。そう，企業経営者による「AI でプログラマは不要になる」という話だ。

現在、彼らは AI が新しい解決策になると考えている。だが、私を信じてほしい。結果は同じだ。パワーが大きくなればなるほど、プログラマーの必要性と地位は高まるばかりである。

『我ら、プログラマー』第1章 p.32より

ボブおじさんによると，プログラマはなくならないらしいっスよ（笑）まぁ，組織内の役回りは変わるかも知れないけどね。

というわけで，つかみはOKということで。第2部は19世紀の「バベッジの階差機関」から始まる（実はちょっとだけ読み進めている）。

参考

Clean Architecture 達人に学ぶソフトウェアの構造と設計 | ZEN大学出版会: Clean Architecture 達人に学ぶソフトウェアの構造と設計について、詳細・ご購入はこちらから; Release 2026-07-10; 評価

[Comment] 実務に即効性があるわけではないが，ものの「考え方」を示す本としてはよく出来ている。ソフトウェア技術史の読み物としても面白い。デジタル化希望！

技術的負債と生成 AI

2026-08-05T03:00:44+00:00

ふと思いついて Kagi Assistant に「生成 AI が世の中に登場してからの大まかな年表って作れる？」って訊いてみたら作ってくれた。年表自体は公開しないが AI が参考にした Web ページは以下らしい。

ターニングポイントになっているのは2017年の Google による論文 “Attention Is All You Need” の Transformer アーキテクチャと，2022年の OpenAI による一般向けの ChatGPT サービスの登場のようだ。今年に入ってからはエージェント型 AI が台頭し，完全に仕事の仕方が変わってしまった。

というわけで，以下の記事。

AI普及でデザイン業の倒産が前年比2.7倍に　「独自性なき企業は淘汰」　東京商工リサーチ

グラフィックデザインなどの「デザイン業」で一千万円以上の負債を抱えて倒産する企業が増えているという記事。背景として以下を挙げている。

東京商工リサーチは、倒産増加の背景を大きく3つに分類している。1つ目は、生成AIの普及を受け、顧客企業のデザイン業務の内製化が進んだこと。2つ目は、デジタル広告の需要拡大により、紙媒体を主力とする企業が影響を受けたこと。3つ目は、ハウスメーカー（木造建築工事業）の倒産増加に伴い、内装や家具などのインテリアデザインを手掛ける会社に影響が及んだことと分析している。

AI普及でデザイン業の倒産が前年比2.7倍に　「独自性なき企業は淘汰」　東京商工リサーチより

私はアートデザインの分野はさっぱり分からないので断言できないのだが，上の記事を読む限り主因は2つ目と3つ目じゃないの？と思ってしまう。つまり産業構造の変化だ。

ぶっちゃけてしまうが，顧客に「自分でやったほうがはやい」と思われたら，そこで試合終了なのよ。

自分のところ（IT 業界）の話で申し訳ないが，今世紀に入って，いわゆる受託開発の仕事はどんどん減っている。というか，もう殆どないかも知れない。例外は公共事業関連くらいかな。まぁ，日本は公共事業への依存度が高いんだけど。

理由は色々とあるが，事象としてはまさに「自分でやったほうがはやい」という風潮になり，これに適応できない中小企業はブラック化（極端に安い単価で過剰に受ける）して，最終的には潰れた。ゼロ年代の話である。

生成 AI，特にエージェント型 AI によって仕事の仕方は大きく変わったが IT 産業の構造としてはとっくにシフト済みで，バカな管理職・経営者が従業員を AI で置き換え（られ）るとか言い出さない限り，業界として大きな構造変化はないと思う。とはいえ，個々のエンジニアについては（特に年配者は）適応できない人もいるだろうし（そっと耳を塞ぐ），本当に AI 導入を理由にエンジニアを解雇するバカな経営者も（特に米国では）いるみたいだが¹。

「技術的負債」というものがある。この言葉が流行ったときは，できの悪いコードや製品を揶揄して言うことが多かったが，本来の意味としては（銀行でお金を借りるように）「より早く実現するために引き換えにするもの」を指す言葉らしい。なので，この「負債」自体には良し悪しというものはない。

お前も技術的負債にしてやろうか！もしくは技術的負債と和田卓人さんをめぐるシンクロニシティ - YAMDAS現更新履歴

ソフトウェア・エンジニアリングにおいて生成 AI を使うメリットは「そこそこのものを早く作れる」点である。この点で AI は人間より優れていると（たぶん）断言できるし，それ故に生成 AI と技術的負債は相性がいいと言えるだろう。

となると，考えないといけないのは，「そこそこ」で収まらない部分に対して AI が残した負債（そもそも負債と気付かない可能性もあるが）をどうやって返すのか，ということだ²。知り合いと話すときは大体ここで（エンジニアの教育も含めて）行き詰まる。 Web 上の技術関連のサイトやページを眺めても，そういったことに言及する記事はほとんど見かけない。まぁ，それこそが本当の意味で「技術（＝お金を取れるところ）」だからなんだろうけど。 AI のために残業するとか論外だしね。

ブックマーク

業態が変わって合わないエンジニアを解雇するというのは昔からあるが，AI 導入を理由（名目）にエンジニアを解雇するような企業が，あとで「やっぱ人間要るわ」となって雇い直そうとしても，ヤバすぎて近付きたくないと思ったりするんじゃないのかなぁ。一度浮気をした男は必ず二度三度と繰り返す（笑） ↩︎
本文の受託開発がなくなった話とも絡むが，今は要件定義から製造・デプロイまでの一連の工程を一発で完遂させるようなプロジェクトはないと言っていい。大抵は小さな単位に分割して，持続的にイテレーションを回していくスタイルだ（故にプロジェクトではなくミッションと言ったりする）。「技術的負債を返す」というのはこのスタイルを前提にしている。これも例外は政府・自治体主導の公共事業で，大抵は予算と期間が決まってるし，開発フェーズと運用（保守）フェーズが分かれているので「持続的にイテレーションを回す」ことができない。もっとも今は公共事業でも大手が持ってるパッケージを使うケースが多いかもしれない。これなら自社製品のカスタマイズとして受けられるので，企業側も（持続的でない）公共事業への依存を減らせる。 ↩︎

「おもしろい技術書」

2026-07-28T06:06:01+00:00

またまた Bluesky で見かけたネタだが，「おもしろいと思った技術書教えてください」に対する結城浩さんの回答が面白かった。

おもしろいと思った技術書教えてください | mond

そういや，子どもは夏休みに入ってるんだよね。読書感想文に悩む季節ですなぁ。これは度々書いてるけど，私は小学生の時に学習参考書の読書感想文を書いて，市のコンクールで賞をもらった男です。どやっ！

というわけで，個人的に面白いと思った技術関連本をいくつか挙げてみる。子どもが読んでも全然構わないけど，たぶん子ども向けではないのであしからず。

K&R

結城浩さんの回答にもあった『プログラミング言語C』がこれ。

プログラミング言語C - 共立出版: Brian W.カーニハン著; Release 1989-06-15; 評価

[Comment] 通称 “K&R”。初版当時のプログラマには「バイブル」と呼ばれた名著。現在は ANSI 準拠の第2版。

原著者の頭文字を取って “K&R” と呼ばれたりする（著者のひとりである Dennis M. Ritchie さんは C 言語の作者でもある）。現在は C 言語の規格バージョンも ISO/IEC 9899:2024 (C24) まで進み K&R よりも優れた技術参考書がたくさんあるが，当時は国際規格すらなく C 言語の教科書と言える本は殆どこれだけで，それ故に「バイブル」などと呼ばれてもいた。

私は真面目にプログラミングを習ったのが IT 業界に入ってからで¹ しかもアセンブラからの入門だったので，初めて C 言語を習ったときは「なんて素晴らしい言語なんだ」と感動したものである。特に感動したのがポインタ演算。たとえば char 型のポインタ変数をインクリメントしたときと short 型のポインタ変数をインクリメントしたときで，ポインタ値の増分が異なるんだよ。凄くね！

同じく Brian W. Kernighan さんによる『カーニハンのUNIX回顧録』に C 言語が誕生した経緯や『プログラミング言語C』執筆当時の話が載っている。

デニスに本作りに関わってもらうようにしたことは，私の技術的な経歴において最も賢明で，あるいは最も幸運なことだった．デニスが共著者となり，彼のリファレンスマニュアルを含めることができたため，本は信頼のおけるものとなったのである．

[…]

本文のテキストは何度も互いにやり取りしたため，二人の文体は融合しているが，リファレンスマニュアルは，デニスの文章の純粋な見本として，ほぼ元あったままにした．この部分は，かつてビル・プラウガーが評した「ぞくぞくするような精密さ」をもって言語を解説している．リファレンスマニュアルは，Cそれ自身のように，正確で，洗練され，簡潔である．

『カーニハンのUNIX回顧録』第4章 p.86より

プログラミング言語の技術参考書を探すときに苦労するのが，言語の使い方を解説したものは多くあるのに言語そのものを解説した本は少ないということだ。どんな言語であれ，プログラミング言語にはそれぞれ作者の思想が根底にあり，それに基づいて言語仕様上の制約が課せられている。これを理解しないと次のステップ（イディオムとかライブラリ・フレームワークとか）に進めないと思う。

プログラミング言語 Go

プログラミング言語Go - 丸善出版理工・医学・人文社会科学の専門書出版社: 明解で効率的なプログラムを描くための書。柴田　芳樹訳; Release 2016-06-15; 評価

[Comment] 著者のひとりは，あの “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

原著者の一人は前節で紹介した Brian W. Kernighan さんである。 Go 言語そのものについて丁寧かつ誠実に書かれた良書であるが，残念ながら内容が古くなってしまった。しかも日本語版は絶版状態らしい。改訂版の予定はないとのこと。

Go 言語は非常にシンプルな言語で，いまだに言語固有のキーワード（予約語）が25個で変わらない。

The following keywords are reserved and may not be used as identifiers.

break        default      func         interface    select
case         defer        go           map          struct
chan         else         goto         package      switch
const        fallthrough  if           range        type
continue     for          import       return       var

via The Go Programming Language Specification - The Go Programming Language

言語仕様全体も1枚の Web ページに収まる分量である。言い方を変えると，このシンプルさ（を保つこと）こそが Go 最大の制約なのである。

私は仕事では様々なプログラミング言語を変遷しているが「母国語」と言えるものは C 言語だった。でも Go 言語を知って以降「母国語」が Go 言語になった。五十路に入って「母国語」が変わるとかそうそうないだろう。

そうなったのも『プログラミング言語Go』の影響が大きいと思っている。そのくらい私にとってインパクトのある本である。

デザインパターン本

Java言語で学ぶデザインパターン入門第3版 | SBクリエイティブ: 「GoF」の『デザインパターン』で紹介された23個のパターンを、オブジェクト指向の初心者にもわかるようにやさし; Release 2021-11-13; 評価

[Comment] なんと！結城浩さんのデザパタ本の第3版が出た。古典的な GoF のデザインパターン23個はそのままに，最近の Java の言語仕様に合わせてコードが一新されている。

いわゆる Gang of Four（GoF）による古典的なデザインパターンを解説した本である。ちなみに，結城浩さんのデザパタ本にはマルチスレッド編もある。

原典の翻訳本もあるが，結城浩さんの著書はどれも平易な文章で読みやすくお勧めである。

Java を前提に書かれているが，もちろん他の言語でも応用できる。デザインパターンでググったら様々な言語で実装している例が見つかると思う。

ただし古典なだけあって，今では使わないほうが良いとされるパターンがあったり，言語によっては実装が難しいものもある。

Go 言語で Factory Method Pattern を構成できるか

先日『実用 Go言語第2版』の読書会で

なお、昔は GoF のデザインパターンに取り上げられたこともあり、テンプレートメソッドパターンが王道とされてきましたが、このパターンを使うには、必ずサブタイプを実装しなければなりません。近年では、クロージャやラムダといった要素を備えた言語が増えています。C++ も C++11 からクロージャが使えるようになり、GUI フレームワークの Qt も、関数オブジェクトでハンドラーが記述できるようになりました。このストラテジーパターンへの移行は Go に限らず、プログラミング言語の全体的な流れと言えます。

『実用 Go言語第2版』3章 p.83より

という記述があって「GoF って知ってる？」という話からデザパタ本の話になった。デザパタ本って GoF 版をベースにしているせいか出版年がどれも古くて，若い人だと知らなかったりするんじゃないだろうか。

とはいえ Iterator とか Factory とか Proxy とか Decorator とか Adapter とか… 今でもよく目にする（けど初見で面食らう）単語も多いので，読んでおいて損はないと思う。

その他の読み物

これは技術参考書と言うより読み物に近いかな。

Clean Architecture 達人に学ぶソフトウェアの構造と設計 | ZEN大学出版会: Clean Architecture 達人に学ぶソフトウェアの構造と設計について、詳細・ご購入はこちらから; Release 2026-07-10; 評価

いつの間にか発行元がZEN大学出版会に変わっとるがな。 ASCII 版は Kindle 版が引き上げられてて絶版になってるのか？慌てて私の Kindle ライブラリの中を見たが，既に買っているものはまだ見れるようだ。そのうち読めなくなるのかね。理工系の本でデジタル版がないとかありえないのだが。

中身は良書。原著は2017年に出版されている。

「明日から Clean Architecture で実装するぞ」とはいかないと思うけど，ものの「考え方」を示す本としてはよく出来ていると思う。「構造化プログラミングとかオブジェクト指向とか関数型とかって何？」ってあたりから SOLID などの原則の説明まで一通り網羅されていて用語の勉強にもなるだろう。回顧録みたいにもなってるので，ソフトウェア技術史の読み物としても面白い。

ちょうぜつソフトウェア設計入門 | 技術評論社: SoftwareDesign誌での連載と技術アドベントカレンダー24回ぶんに収まらなかった関連知識を徹底解説。いわゆる「オブジェクト指向」と呼ばれる考え方から発展した分野は、どのようにソフトウェア設計の役に立つのかを、よく知られた原則、テスト駆動開発、デザインパターンなどを通じて理解できる一冊です。上級者には定番の知識を体系的に整理するヒントとして、初級者には可愛いイラストで覚えるキーワード集として、幅広く活用していくことができます。なお、サンプルコードはPHPで書かれていますが、他の言語に置き換えて読めるコードばかりです。PHPを使っているかどうかを問わず、全ての開発者にオススメです。; Release 2022-12-07; 評価

[Comment] 祝♪ #ちょうぜつエンジニアめもりーちゃん単行本化！絵は可愛いが読み応えあり。「SoftwareDesign」連載分も収録されていて超お得！

𝕏 を見なくなったのだが，めもりーちゃんの更新は細々と行われているようだ。

初っ端がマンガなので面食らうが，中身は割とハード。技術系の読み物としてお勧めである。版元でなら PDF で買えるし（←重要）。

前節でちょろんと紹介した Template パターンと Strategy パターンの比較の話も載っている。

ブックマーク

「読書感想文は、ただちに「面白かった本のお勧め文」に名目を変えるべき」ではない

参考

カーニハンのUNIX回顧録 - 丸善出版理工・医学・人文社会科学の専門書出版社: Unixとは何であり，どのように生まれ，なぜ重要なのかを説明する，コンピュータ史上でも特に生産的だった形成期の素晴らしい物語ブライアン・カーニハン著; Release 2025-09-24; 評価

実用 Go言語第2版: 文法はシンプルで学びやすいという特徴を持つGo言語。システム開発の現場でも使われる機会が増えていますが、複雑な要件を実現するにはプログラミング言語が提供するシンプルな構成要素（文法やライブラリ）を、さまざまに組み合わせます。本書は「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点からGoを使うポイントを紹介します。構造体やインタフェース、またJSON、CSVファイル、Excel、固定長ファイルの扱い方、ログやテスト、環境構築など、また初版の発行後、Goに追加されたジェネリクスについても紹介。現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」を、その背景と共に教えてくれる先輩のような書籍です。; Release 2025-12-01; 評価

最初に入った会社の3ヶ月研修で情報処理1種資格相当の座学とアセンブラと C 言語を叩き込まれた。一応，学生時代に BASIC と Fortran は習ったが，お遊び程度だったと言っておこう。 ↩︎

Ubuntu サーバで LLM 構築へ：（2）用語集

2026-06-10T08:15:23+00:00

前回の続き。事前学習に当たって関連する用語を整理していく。

最近はどうやってるか知らないが，私が若い頃はユーザ企業からの受託プロジェクトが多かったので，業務知識の摺り合わせのために用語集を作ることが必須だった。これをサボると顧客との間で「そんなつもりじゃなかった」みたいなすれ違いが頻出して泥沼化することがある。思ったより業界・業種ごとに独自の用語や隠語は多いものである。

用語については，まず AI に思いつく限り列挙してもらい，それを私が（勉強がてら）自力で調べる，という形で進めていく。 …という感じに指示したら，いきなり180個近く列挙して下さりやがった（笑）

まぁ，少しずつのんびりいこう。この記事は随時更新する予定。

人工知能

別表記

Artificial Intelligence, AI

意味，定義など

元々は動物や人間の認知機能（の一部）を機械的に模倣（シミュレーション）する研究分野を指していたが，そこから派生した要素技術や製品・サービスも含めて AI と呼ばれるようになった。

機械学習

別表記

Machine Learning, ML

意味，定義など

人工知能（技術）のサブセット。データから学習し，未知の入力に対する予測・分類・推定を行う技術の総称。

統計的機械学習

別表記

Statistical Machine Learning, Statistical ML, SML

意味，定義など

機械学習を「確率モデル」「推定」「推論」「不確実性」といった確率・統計学の枠組みで捉えて学習や評価を行うという立場（見方）を指す。

ブックマーク

統計的機械学習とは| IBM

深層学習

別表記

深層機械学習, ディープラーニング, Deep Learning, DL

意味，定義など

多層（deep）のニューラルネットワークを中核にする機械学習のサブセット。必ずしもラベル付きデータセットを必要とせず，テキストや画像など非構造化データから特徴を自動的に抽出して学習することができる点が特徴。

深層学習を統計的に見るなら統計的機械学習の文脈に入ると言えるが，深層学習という言葉が指すもの（実装・最適化・表現学習など）は確率論中心で語られるとは限らない。

ブックマーク

AI，機械学習，ディープラーニング，ニューラル・ネットワーク | IBM

ニューラルネットワーク

別表記

Neural Network, NN

意味，定義など

単純なニューロンを層状（入力層，中間層/隠れ層，出力層）に積み重ね，データからパターン認識の重みとバイアスを学習し，入力から出力までをマッピングする機械学習モデル。脳の神経ネットワークから着想を得ている。

生成 AI

別表記

Generative AI

意味，定義など

与えられた知識（訓練データ）を元に文脈（コンテキスト）や指示に従って，テキスト（プログラムコードを含む）や画像，動画，音声などのコンテンツを生成する AI 製品のこと。

従来の AI 製品が情報の分析・評価・予測などを主目的としていたのに対して，生成 AI はコンテンツの生成を主目的としている点が特徴。生成 AI が社会に与えたインパクトは大きく，近年では AI といえば生成 AI を指すことが多い。

大規模言語モデル

別表記

Large Language Model, LLM

意味，定義など

ニューラルネットワークを大規模化し，トランスフォーマーを採用して「次トークンを予測すること」を事前学習目的の中心にした機械学習モデル。生成 AI におけるテキスト生成に関する部分の中核的な存在。大規模言語モデルの「大規模」はモデルが大きい（パラメータ数が多い）ことを指して名付けられている。

まず事前学習（pre-training）として大量のテキストを使って「ラベルなし（自己教師あり）」でモデルに言語の基本を学ばせる。その後の調整（fine-tuning / instruction tuning など）で特定のタスクに適応させることができる。

flowchart TD A[事前学習
Pre-training] --> B[微調整
Fine-tuning] B --> C[指示追従の微調整
Instruction tuning] B --> D[タスク別微調整例
要約/分類/抽出など] B --> E[（場合により）さらなる調整
例: 報酬学習/RLHF, 安全性調整] A:::pre B:::ft C:::it D:::task E:::post classDef pre fill:#e8f4ff,stroke:#2b6cb0 classDef ft fill:#f0fff4,stroke:#2f855a classDef it fill:#fff7e6,stroke:#b7791f classDef task fill:#faf5ff,stroke:#6b46c1 classDef post fill:#fff0f0,stroke:#c53030

全体アーキテクチャ推奨構成（LiteLLM/Nginx あり）

なぜ生成 AI が LLM 中心になったか：

トークン予測：単純で汎用的な学習目的で，大規模テキストから共通に学べる
トランスフォーマー設計： attention 中心でスケールしやすい学習器として噛み合う
スケーリング則：増やしたときの改善が経験的に整理され，投資判断がしやすい
スケールでタスク適応が変化： fine-tuning なしに few-shot で強くなる傾向が示され，普及・実装が加速

ブックマーク

トランスフォーマー

別表記

Transformer

意味，定義など

自己注意機構だけに基づく新しいネットワーク構成。再帰や畳み込みを使わずに，注意機構だけで構成しているため，並列化が可能で大規模化しやすい。

ブックマーク

RAG

別表記

Retrieval-Augmented Generation

意味，定義など

LLM に外部知識（検索結果）を取り込ませてから生成させるアプローチ。これにより知識不足や幻覚（hallucination）の問題を緩和し，より正確で信頼性の高い生成が可能になる。

実運用では以下のような手順になる。

手順	役割
1. 文書をチャンク化	検索しやすい単位に分割
2. チャンクを embedding に変換	文書意味を数値化（ベクトル化）
3. ベクトルを Vector DB / Vector Index へ格納	類似検索できる形で保存
4. ユーザ質問を embedding に変換	質問も同じ空間で表現（ベクトル化）
5. 類似度（例：cosine similarity）で上位を検索	関連文書を取り出す
6. 取得した文書をプロンプトに入れて生成	LLM の generator が回答

ブックマーク

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

Embedding

別表記

埋め込み，ベクトル化

（複数形 Embeddings で）埋め込みベクトル群

意味，定義など

RAG において，外部文書やユーザ質問（プロンプト）などのテキストデータを数値ベクトルに変換する技術。文書をチャンクと呼ばれる単位に分割し，チャンク化された各データに対して意味的な特徴を捉える多次元のベクトル情報を埋め込む。ベクトルを埋め込まれたデータは key-value 形式で持つデータストア（Vector DB など）に保存される。

このため，日本語では Embedding をサ変名詞的に「ベクトル化」と訳すことが多い。

MCP

別表記

Model Context Protocol

意味，定義など

AI アプリケーションが外部のデータや機能にアクセスするため，外部コンテキスト交換のためのオープンな標準プロトコル。クライアント・サーバで構成される。 AI アプリケーション側がクライアント。サーバ側は LLM に渡せるものを以下のプリミティブとして提供する。

プリミティブ	概要	典型例
Tools	サーバが公開する「実行可能なツール」。LLM（言語モデル）が文脈に応じて発見・呼び出しできる形で提供されます。	DB問い合わせ、API呼び出し、計算など
Resources	クライアント（LLMアプリ）にコンテキストとして渡すためのデータ。ファイルやDBスキーマ、アプリ固有情報などを共有できます。	社内文書、スキーマ、参照データ等
Prompts	サーバが公開するプロンプトテンプレート。ユーザが明示的に選べるように設計される、と説明されています。	業務用の定型指示テンプレなど

RAG とは相補的な関係になることが多い。たとえば RAG が外部資料を取得する方法を MCP で提供するなど。

AI エージェント

別表記

AI Agent

単に Agent / エージェントと言う場合もある

意味，定義など

一般的に AI エージェントは「環境を知覚（perceive）し，環境に働きかけて行動（act）する自律的なシステム」として説明される。

AI エージェントが生成 AI と結びつくと以下のような役割・行動になる。

LLMを意思決定の中核にして
計画して（plan）
ツールを呼び出し（call tools）
複数ステップの実行に必要な状態（state）を保持して
目的を達成するために動く。または推論と行動を繰り返す

目的別に AI エージェントを例示してみる。

目的（ユーザが求めること）	エージェントの核となる動き（イメージ）
会話/問い合わせ対応	会話しつつ，必要なら外部情報やツールへ “取りに行って” 回答する（単発Q&Aより行動ループを持つことが多い）
業務自動化（ワークフロー実行）	次に何をするか計画し，ツール/API を呼んで段階的に完了させる（state 保持が重要）
調査・意思決定支援	情報を集め，推論して結論を出す（必要に応じて “推論→行動→再推論” のループ）
開発支援（コード生成/デバッグ）	目標に向けて反復し，ツール（実行環境，リポジトリ操作等）を使いながら進める（目的達成型の行動）

また，以下のように行動決定の仕方で分類する方法もある。

種類	特徴
ツール実行を伴うエージェント	LLM が計画し，ツールを呼び，複数ステップを進める
熟考（deliberative）/プランニング中心	世界の明示的なモデルを持ち，記号的推論で「何をするか」を決める
BDI エージェント	beliefs（信念）/desires（欲求）/intentions（意図）で分けて行動選択する枠組み
マルチエージェント	複数のエージェントが協力して（autonomousのまま）タスクを進める

なお，ここで言う「自律的（autonomous / autonomy）」とは「どれくらいユーザ介入なしで動けるように設計されているか」という文脈で使われ，辞書的な意味での自律とは異なる点に注意。

ブックマーク

Ubuntu サーバで LLM 構築へ：（1）事前学習

2026-06-09T09:26:51+00:00

だいぶ生成 AI を使うことに慣れてきたので，そろそろ自前で LLM サービスを構築することを考えてみる。

いや，既にもうメジャーな AI サービスプロバイダってメタクソ化（enshittified）し始めてるぢゃん。企業サービスに完全にロックインされないうちに自前で構築できるようになっておかないと，と思ってさ。

今回は，以下の要求で Kagi Assistant にサービス構成を提案してもらった。

家庭内 LAN 上の Ubuntu サーバ機に LLM サービスを構築する
クライアントは Windows 機と Ubuntu 機を想定
主な用途はプログラミング支援とブログ作成補助
VS Code で使えるようにする

以降に Kagi Assistant からの提案を載せるけど，まだ内容の検証をしていない。なので嘘や間違いが紛れている可能性があるのでご注意を。私としては，この提案を学習の起点（trigger）とするつもりである。

アーキテクチャ

Kagi Assistant が最初に推奨してきた構成：

graph TB subgraph Server["Ubuntu Server"] Ollama["Ollama
:11434
(推論エンジン)"] LiteLLM["LiteLLM
:4000
(API Proxy)"] Nginx["Nginx
:443
(Reverse Proxy)"] Embed["nomic-embed-text
(Embedding / RAG用)"] PG["PostgreSQL
(LiteLLM 用)"] Ollama ---> LiteLLM LiteLLM --- PG LiteLLM ---> Nginx Ollama --- Embed end subgraph ClientUbuntu["Ubuntu PC"] VSCodeU["VS Code + Continue"] end subgraph ClientWin["Windows PC"] VSCodeW["VS Code + Continue"] end Nginx -- "LAN (HTTPS)" --> ClientUbuntu Nginx -- "LAN (HTTPS)" --> ClientWin

全体アーキテクチャ推奨構成（LiteLLM/Nginx あり）

推論エンジンとして Ollama を提案した理由は以下の通りらしい：

個人〜小規模LAN利用ではOllamaが最適。セットアップが最も簡単で、OpenAI互換APIを標準提供し、モデル管理が容易です。

vLLMは同時接続ユーザーが多い（5人以上）本番運用向けで、単一ユーザーには複雑さが増すだけ
- vLLM vs. Ollama: When to use each framework
- vLLM vs Ollama: Which Local AI Server to Run in 2026
llama.cppは低レベルすぎて管理が煩雑

LiteLLM は Ollama の前に置く OpenAPI 互換 API プロキシ。 Ollama だけでなく OpenAI や Anthropic などの外部 API も統一的に扱えるらしい。図では LiteLLM に PostgreSQL がぶら下がっているが，これは API キー管理・使用量トラッキング用とのこと。

What is stored in the DB | liteLLM

Nginx はリバースプロキシとして HTTPS 終端，セキュリティ（Ollama/LiteLLM への直結ポートをサーバの外に晒さない），ストリーミング対応を担っている。注意点は以下の通り：

LAN 内のみの利用でもHTTPS推奨（Continue.dev が API キーを送るため）
Let’s Encrypt 証明書か自己署名証明書を使用
ストリーミング（SSE）対応のため proxy_buffering off が必須

nomic-embed-text については後述する。

LiteLLM と Nginx は入れなきゃダメ？と訊いてみたら，もう少し簡単な構成もあるらしい。

graph TB subgraph Server["Ubuntu Server"] Ollama["Ollama
:11434
(推論エンジン)"] OpenWebUI["Open WebUI
:8080
(GUIチャット)"] Embed["nomic-embed-text
(Embedding / RAG用)"] Ollama --- Embed Ollama ---> OpenWebUI end subgraph ClientUbuntu["Ubuntu PC"] VSCodeU["VS Code + Continue
ollama run (CUI)
ブラウザGUIチャット"] end subgraph ClientWin["Windows PC"] VSCodeW["VS Code + Continue
ollama run (CUI)
ブラウザGUIチャット"] end Ollama -- "Ollama API
:11434" --> ClientUbuntu OpenWebUI -- "Web UI
:8080" --> ClientUbuntu OpenWebUI -- "Web UI
:8080" --> ClientWin Ollama -- "Ollama API
:11434" --> ClientWin

全体アーキテクチャ推奨構成（Ollama 単体, LiteLLM/Nginx なし）

クライアントの用途ごとの使い分けは以下の通り。

アクセス先	ポート	用途	クライアント
Ollama API	`:11434`	VS Code + Continue（コーディング支援）	Ubuntu / Windows
Ollama API	`:11434`	`ollama run`（CUIチャット）	Ubuntu / Windows
Open WebUI	`:8080`	ブラウザ GUI チャット（ブログ執筆・雑談）	Ubuntu / Windows

VS Code の拡張機能である Continue は Ollama API に対応しているそうなので（セキュリティの問題を除けば）直結で OK。ターミナルエミュレータ等で CUI チャットを行う場合はクライアント側にも Ollama をインストールして接続先をサーバ機に向ければいいらしい。

OLLAMA_HOST=http://192.168.x.x:11434 ollama run qwen3.5:9b

さらに簡単に Ollama API を直に叩く方法もある（自作ツール向け？）。こんな感じ。

# ワンショット質問
curl http://192.168.x.x:11434/api/chat -d '{
  "model": "qwen3.5:9b",
  "messages": [
    {"role": "user", "content": "ブログのタイトル案を5つ提案して"}
  ],
  "stream": false
}'

# ストリーミング（リアルタイム出力）
curl http://192.168.x.x:11434/api/chat -d '{
  "model": "qwen3.5:9b",
  "messages": [
    {"role": "user", "content": "PythonでFizzBuzzを書いて"}
  ]
}'

Ollama API って素の RESTful API でやり取りするのか。確かにこれは（セキュリティ的に）ヤバいな。 LiteLLM/Nginx を噛ませろって言う筈だわ。 LAN 内に他人（のデバイス）が入ってくる余地がないならギリ大丈夫かな。まぁ，どのみち malware に侵入されたらアウトだけど。

Open WebUI は Web ベースのチャットインターフェースで，以下の特徴があるらしい¹。

機能	説明
ChatGPT 風 UI	ブラウザでチャット、使い慣れたインターフェース
会話履歴	すべての会話を保存・検索可能
モデル切替	ドロップダウンでモデル切替
ドキュメント RAG	ファイルをアップロードして対話
ユーザー管理	複数ユーザー・アクセス制御
完全オフライン	外部へのデータ送信なし

OpenAI の API キーを持っていれば Open WebUI から OpenAI のモデルも使えるそうな（以下は Docker 上に Open WebUI をインストールした場合の起動例）。

# Open WebUI起動時にOpenAI APIも設定
docker run -d \
  --name open-webui \
  --network host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -e OPENAI_API_KEY=sk-your-openai-key \
  --restart always \
  ghcr.io/open-webui/open-webui:main

用途別の使い分けについてまとめてもらった。

用途	インターフェース	理由
ブログ執筆・雑談	Open WebUI（ブラウザ）	ChatGPT風で直感的、会話履歴管理
プログラミング支援	VS Code + Continue	コード補完・エディタ統合
サクッと質問	`ollama run`（CUI）	ターミナルから即座に
スクリプト・自動化	curl / Python API	バッチ処理やパイプライン

普段の調べ物は Kagi Assistant で必要十分なので Open WebUI はあまり使わないかもしれないけど。 Open WebUI が不要なら入れない構成もありだな。

モデル選択

Ollama で選択可能な LLM モデルで Kagi Assistant が勧めてきたのは以下のもの¹。

用途	推奨モデル	役割
チャット・コーディング対話	Qwen 3.6-27B または 35B-A3B	chat, edit, summarize
コード自動補完（FIM）	Qwen 2.5-Coder（7B/14B/32B）	autocomplete（タブ補完）
Embedding（RAG用）	nomic-embed-text	codebase検索
Reranker（RAG精度向上）	Qwen3-Reranker-8B	検索結果の再順位付け

GPU VRAM別のモデル構成

VRAM	チャット用モデル	自動補完用モデル	備考
8GB	Qwen 3.5-9B (~6.6GB)	Qwen 2.5-Coder 7B (~5GB)	1モデルずつ切り替え運用
16GB	Qwen 3.6-35B-A3B (~16-22GB)	Qwen 2.5-Coder 14B (~9GB)	同時稼働は量子化調整が必要
24GB	Qwen 3.6-27B (~17GB)	Qwen 2.5-Coder 32B (~20GB)	★最も推奨される構成
32GB+	Qwen 3.6-27B (Q6/Q8) + Qwen 2.5-Coder 32B	同時稼働余裕あり	RTX 5090等

💡 24GB VRAM（RTX 3090/4090）の構成が最もバランスが良い: Qwen 3.6-27Bでチャット・エージェント的コーディング、Qwen 2.5-Coder 32Bでタブ補完。ただし同時稼働はVRAM的に厳しいため、Ollamaはモデルを自動でアンロード/ロードするので、交互に使う運用になります。

あー。そういや，サーバ機のスペックを教えてなかった。手持ちの空いてるミニ PC をサーバ機にする予定なのでスペックは高くないのよ。

というわけで Ryzen 5 7430U, RAM 16GB, 外付け GPU なしの構成で再提案してもらった。

役割	推奨モデル	RAM使用量	予想速度	理由
チャット・ブログ・コーディング対話	Qwen 3.5-9B (Q4)	~6 GB	~5-8 tok/s	9Bで品質最優、ブログ執筆に十分な表現力
コード自動補完（FIM）	Qwen 2.5-Coder 3B (Q4)	~2.5 GB	~15-20 tok/s	補完は高速が命、3Bで品質も十分
Embedding（RAG用）	nomic-embed-text	~0.3 GB	高速	コードベース検索用

💡 合計RAM使用量: ~9 GB（OS等の予約分を含めても16GB内に余裕あり）

チャット用を軽くして速度を稼ぐ構成：

役割	モデル	RAM	予想速度
チャット	Qwen 3.5-4B (Q4)	~3 GB	~12-18 tok/s
自動補完	Qwen 2.5-Coder 1.5B (Q4)	~1.2 GB	~30+ tok/s
Embedding	nomic-embed-text	~0.3 GB	高速

合計 ~4.5 GB。速度は快適ですが、ブログ執筆の品質は9Bに劣ります。

🌟 注目の選択肢：Gemma 4 26B-A4B（MoE）

GoogleのGemma 4 26B-A4Bは 総パラメータ26B・推論時アクティブ3.8B のMoEモデルです。 Q4量子化で ~15 GB のRAM使用量。

✅ 品質: 3.8B活性化で26Bクラスの表現力（Qwen 3.5-9B以上の可能性）
⚠️ RAM: ~15 GBで16GBギリギリ。OSの予約分と競合する可能性
⚠️ 速度: MoEはアクティブパラメータが少なくても全パラメータのメモリアクセスが必要なため、DDR4帯域幅がボトルネックになり 予想3-6 tok/s

結論: 試す価値はありますが、16GBではスワップ発生のリスクが高く、安定性に欠ける可能性があります。まずはQwen 3.5-9Bで安定運用し、余裕があればGemma 4 26B-A4Bも試すのがおすすめ。

⚡ パフォーマンスを引き上げるTips

施策	効果	詳細
`num_ctx`を小さく	速度向上	4096→2048にするとコンテキスト処理が高速化。ブログ執筆なら2048で十分な場面も
モデルを1つずつロード	RAM節約	`OLLAMA_MAX_LOADED_MODELS=1`で未使用モデルを自動アンロード
Q3量子化を試す	RAM削減・速度UP	`ollama run qwen3.5:9b-q3_K_M`でRAM~4.5GB、品質は若干低下
スワップの無効化	安定性向上	RAM不足時のスワップは極端な低速化の原因。`/etc/fstab`でswapを0に
将来的にGPU追加	劇的改善	Thunderbolt/OCuLink外付けGPUエンクロージャーでRTX 3060(12GB)等を追加すれば、一気に実用的に

Ryzen 5 7430U には内蔵 GPU (Radeon Graphics) があるが LLM 推論には非力なので CPU-only 推論となる。そうなるとメモリ帯域幅が重要になるんだけど DDR4-3200 デュアルチャネルは DDR5 半分以下の帯域幅（〜51GB/s）しかない。 RAM のサイズも 32GB 以上は欲しいらしい。

サーバRAM	推奨構成	備考
8GB	Qwen 3.5-4B (チャット) + Qwen 2.5-Coder 1.5B (補完)	1モデルずつ切り替え
16GB	Qwen 2.5-Coder 7B (チャット) + Qwen 2.5-Coder 3B (補完) + nomic-embed	★最も現実的
32GB	Qwen 3.5-35B-A3B (チャット) + Qwen 2.5-Coder 7B (補完) + nomic-embed	★★最高の体験
64GB	Qwen 3.5-35B-A3B + Qwen 2.5-Coder 14B + nomic-embed	余裕あり

なかなかに貧弱な構成と言われてしまった（笑）

！だってメモリもプロセッサも高いんだよ，今！

しょうがないぢゃん orz

nomic-embed-text について

nomic-embed-textはOllama上で動く Embeddingモデル です。テキストを数値ベクトル（768次元）に変換するだけで、それ自体にデータベースは必要ありません。

テキスト入力 → nomic-embed-text → 768次元ベクトル出力

ベクトルデータはデータベース化して RAG (Retrieval-Augmented Generation; 検索拡張生成) に使用する¹。 Open WebUI および Continue は自前でベクトルデータベースを持っている。規模が大きくなれば PostgreSQL + pgvector などのベクトルデータベースが別途必要になる。

🏗️ RAGの規模別アーキテクチャ

規模	ベクトル保存先	構成
小規模（個人・Continue.dev）	ローカルファイル（Continue内蔵）	Ollama + nomic-embed-text のみ
中規模（チーム・Open WebUI）	Open WebUI内蔵のChromaDB	Ollama + Open WebUI
大規模（組織・自作パイプライン）	PostgreSQL + pgvector / Qdrant / Milvus	Ollama + 独自バックエンド

今回はここまで

とりあえず Ollama と RAG についてはちゃんと勉強せなあかんなぁ，というのは分かった。あとは実際に組んでみて評価していく感じかな。

薄々わかってはいたが，どうも手持ちの環境は貧弱すぎるみたいだけど，どの程度足らないのかの感覚がわからない。これは使ってみて確かめるしかないだろう。

仕事が絡むなら vLLM も気になるところだが，そういう仕事が貰えるなら考えるということで（笑）

RAG の機能は，簡単にいうと LLM に外部の情報を検索させてから回答させる仕組み。これによって組み込まれた知識にない情報についても（extrinsic hallucination を抑えつつ）対応することができるようになる。 Google 検索のようなキーワード検索ではなく，プロンプトによる指示に合わせて意味的検索ができるのが特徴。 Continue は nomic-embed-text が出力したベクトル化情報をファイルに保存するらしい。 Open WebUI は自前でベクトル化を行い，内蔵の ChromaDB に保存するようだ。 ↩︎ ↩︎ ↩︎

Secretary as a Service

2026-05-31T03:43:36+00:00

Agents Window

最近気がついたのだが VS Code 1.120 から Agents Window なるものが追加されたそうだ。

仕事でコードを書くときは分担して作業するものなのであまり意識することはないが，独りで作業する場合，特に Go で複数のパッケージを同時に弄る場合は頭の中がとっ散らかってしまうことがある。我ながら歳をとったなぁとは思うけど。

というわけで，少しでも作業が軽減できればと Agents Window を試そうとしたんだけど，これって既存の AI エージェントとのセッションを他セッションに引き継げないのな。「どうにかならん？」と，それこそ Copilot に訊いてみたんだが，セッション履歴のインポート・エクスポート機能はあるが（つまりバックアップ・リストアはできる？），他セッションに引き継いで fork することはできないと言われた。できることは AI に引き継ぎ資料を書かせて，それを別のセッションに読み込ませるくらいだそうな。

この辺の話を Mastodon/Bluesky で愚痴ったのだが

Post by @rino@mstdn.world

View on Mastodon

みたいなポストをいただいたり。でも，ここに書かれている Claude のやり方も裏技っぽいよねぇ。他に「ZedのMCPサーバでコンテキスト共有したい」みたいな運用もあるよ，と教えてもらった。

セッションの複製や fork は必須の機能だと思うんだけど，なんで Copilot の標準機能にないの？やっぱそろそろ VS Code や Copilot は卒業すべきかねぇ。だからといって，個人利用で Claude Code とか使う気はないが。

秘書としての AI エージェント

他の記事でも言ってるけど，コーディング支援として使う AI はどちらかというとペアプログラミングしている感じ。それも新人くんとのペアプロ（笑）最初の頃は「自分で書いたほうが速い」って感じだったんだけど，反応を見ながら指示を出すことで，なんとなく AI の性格のようなものが分かってきた。 GitHub Copilot の Pro 契約で使える主なモデルはこんな感じ（個人の意見です。あしからず）。

GPT-5-mini: コストゼロで使えるのが最大のメリット。生真面目なおバカ。コード補完やコメント補完では重宝するが，エージェント・モードだと最初から明後日の方向に全力疾走する。「けもフレ」のアライさんみたいなモデル
GPT-5.3-Codex: 個人で使うエージェントとしては一番バランスが取れている。こちらの意見に追従（ついしょう）せず，ちゃんと反論できる。人間のペースに合わせてくれる盲導犬モデル
Claude Sonnet 4.6: 計画立案は上手いが，一度走り出すと融通が利かず失敗するまで突っ走るチョロQモデル。コード分析等で無闇にトークンを消費してる印象。金に糸目をつけず地球資源を濫用する富裕層向き

エージェントの使い方がちょっと変わったきっかけになったが goark/pa-api パッケージに来た PR の評価に VS Code の Copilot を使ったこと。 PA-API から Creator API に移行するための大きな変更だったので，自分だけで評価・判断するのがちょっと不安だったのだ。

実をいうと PR ページでアサインする AI レビューが使いものにならなかったのであまり期待してなかったのだが，思った以上に使えた。私は，上述の性格診断から GPT-5.3-Codex を常用しているのだが， PR に対するお互いの評価を突き合わせて「議論」が成立したことに驚いた。結城浩さんの『AIと生きる』に出てくる「AI との対話」ってこういう感じなんだなぁ，と実感したのだった。

これで我が家では Copilot はペアプロ相手の新人くんから秘書に格上げになった。 AI で秘書的な役割を演じるものとして思いつくのはグレッグ・イーガンの『万物理論』に出てくるシジフォスだな。私としてはあーゆーのが理想なんだけどねぇ。

サービスとしての秘書

個人で Go 製ツールを書くときは複数の自作パッケージを同時に扱うことが多い。そういう意味で Agents Window は便利そうなのだが，前に述べたようにセッションの複製や fork ができないのはいただけない。あと，複数のセッションを統括する AI セッションが要るよね，たぶん（セッション間の通信？）。秘書はなんぼあってもいいですからね（by ミルクボーイ）。

で，思ったんだけど，これ VS Code から分離したほうがよくね？そもそもエディタや IDE にエージェント機能を組み込むのは筋が悪いと思うのだ。だからこそ CLI インタフェースの AI エージェントが人気なんだろうけど GUI デスクトップでいまさら CUI ターミナル上で動かす意味はないよね。ブラウザ上で動かすのはもっとないけど。

というわけで Agents Window には密かに期待を寄せている。どう発展するのか分からないけど。

あと，やっぱローカル LLM は真面目に勉強しないといけないなぁ。既に AI サービスはメタクソ化が始まってると思う。早めに逃げれるようにしておかないと。

ブックマーク

VS Code 1.121 で何が変わったのか？ Agents・Mermaid・HTMLプレビュー・ターミナル最適化を整理する - Qiita

参考

万物理論 (創元SF文庫): グレッグ・イーガン (著), 山岸真 (翻訳); 東京創元社 2004-10-28; 文庫; 4488711022 (ASIN), 9784488711023 (EAN), 4488711022 (ISBN); 評価

[Comment] グレッグ・イーガンの名作。これも singularity を巡る物語だな。

reviewed by Spiegel on 2017-09-18 (powered by PA-APIv5)

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

2026-05-23T07:03:30+00:00

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

第5回『カーニハンのUNIX回顧録』オンライン読書会 (2026/05/23 13:00〜)

今回は7章から9章の途中まで。最後まで終わらなかった。印象に残った部分をかいつまんで紹介する。

Unix 年表

8章に載っている「Unix 年表」は Wikipedia からの転載みたいなので探してみたらあった。

File:Unix timeline.en.svg - Wikimedia Commons (public domain)

すべての Unix 派生版が載っているわけではないが，大まかな系譜は見て取れるだろう。

研究所版 Unix が系譜の根であり，そこから大きくバークレー版（Berkeley Software Distribution; BSD）と商用版（System III & V）に分かれる。両者は同じ祖先を持ちながら互換性がなく，また AT&T が BSD に対して知財権侵害で訴えた¹ こともあり（BSD は AT&T からのコードを削除・書き換え，泥沼となる）まるで似て非なるものとなった。

Xenix

読んで面白かったのは Microsoft が1980年代に Xenix と呼ぶ Unix 派生バージョンを供給してたことで²，1980年代後半の Unix インストールマシン台数ではこれが一番多かったらしい。

もし Microsoft が自身の MS-DOS の代わりに Xenix を推していたら，そして，もし AT&T が見かけによらず取引しやすかったなら，今日の世界はどれだけ違っただろうか．

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

ホンマにな。 Xenix はのちに SCO (Santa Cruz Operation) に売却される。

Minix と Linux

AT&T と BSD の間の不毛な争いの間に「もっと自由に使える Unix」の機運が高まる。ここで登場したのが Minix である。 Minix はシステムコールレベルでは互換だがゼロからコードを書いたもので，カーネルの構成が Unix とは異なる。作者の Andrew Tanenbaum は Minix についての教科書を書き，ソースコードを無料公開した。 Minix は教育・研究目的で今も健在らしい。

そして Linus Torvalds による Linux が登場する。この辺までくると私にもリアルな記憶になってくるな。

『カーニハンのUNIX回顧録』には Usenet の comp.os.minix に投稿された Linus Torvalds 投稿（の翻訳）が載っている。

私は，386 (486) AT クローン向けの（無料の）オペレーティングシステムを作っています（単なる趣味で，gnu のように大きく，プロ向けなものにはしたくない）．

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

この部分を読んで密かに笑ってしまった。フィンランドの大学生が「単なる趣味で」作った Unix もどきが（ゼロからコードを書き，最初は数千行のサイズだったらしい），今やパソコンを除く多くの機器でメジャーな OS となった（スパコンも今や Linux 駆動だし Android も Linux ベースである）。もっと言えば Linux を礼賛する本も出たりして，世の中というのは実に不思議である³。

Unix の技術がもたらしたもの

『カーニハンのUNIX回顧録』では Unix の技術がもたらしたものとして以下を挙げている。

階層型ファイルシステム
高水準実装言語
ユーザレベルのプログラム可能なシェル
パイプ
ツールとしてのプログラム
普通のテキストが標準データ形式である
プログラムを書くプログラム
専用言語

詳しくは9章を参照あれ。

Unix 哲学

Unix の技術がもたらしたものとして最後に「コンピュータを使った仕事にどのように取り組むか」というのが挙げられている⁴。曰く

それぞれのプログラムは一つのことをうまくやるようにせよ．新しい仕事をするには，新たな「機能」を追加して古いプログラムを複雑にするのではなく，改めて組み立てよ．

すべてのプログラムの出力は，未知の別のプログラムの入力となることを想定せよ．出力を無関係な情報で散らかさないこと．厳格なカラム化やバイナリの入力形式は避けよ．対話型の入力を強要しないこと．

ソフトウェアは，たとえそれがオペレーティングシステムであっても，早期に，できれば数週間以内に試用できるように設計し構築せよ．ぎこちない部分はためらわずに捨てて作り直すこと．

たとえツール構築のために迂回する必要があったり，使い終わったらその一部を捨てることになると予想されようとも，プログラミング作業を楽にするためには，未熟な人の手助けよりもむしろツールの使用を優先せよ．

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

これは，今日では「Unix 哲学（Unix Philosophy）」として知られているものの，元になったものである。 4番目とか道具としての生成 AI を指してるような気がして，ちょっと面白かった。

参考

カーニハンのUNIX回顧録 - 丸善出版理工・医学・人文社会科学の専門書出版社: Unixとは何であり，どのように生まれ，なぜ重要なのかを説明する，コンピュータ史上でも特に生産的だった形成期の素晴らしい物語ブライアン・カーニハン著; Release 2025-09-24; 評価

リナックスの革命 ― ハッカー倫理とネット社会の精神: ペッカヒマネン (著), リーナストーバルズ (著), マニュエルカステル (著), 安原和見 (翻訳), 山形浩生 (翻訳); 河出書房新社 2001-05-26; 単行本; 4309242456 (ASIN), 9784309242453 (EAN), 4309242456 (ISBN); 評価

[Comment] 大昔に買ったんだけどうろ覚え。買い直そうかと思ったが邦訳は Kindle ではないのか。それにしても「リナックスの革命」とかいう頭の悪いタイトルはどうにかならなかったのだろうか。副題だけで十分ぢゃん。

reviewed by Spiegel on 2020-12-12 (powered by PA-APIv5)

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

[Comment] Linux の作者 Linus Torvalds の自伝的作品。

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

『カーニハンのUNIX回顧録』では Oracle vs. Google (Android/Java) の訴訟についても紹介している。この辺は割と真面目にブログ記事にしてるので「Google vs Oracle の訴訟の行方（最終章）」から遡って読んでみて。そもそもプログラムコードに著作権があるってのは（歴史的には）比較的新しい考え方なんだよ。 WCT (WIPO Copyright Treaty) が採択されたのが1996年。発効したのが2002年である。 ↩︎
「Microsoft の Xenix」という部分を見て「銭ックス」と脳内変換したのは私だけではない筈だ！ ↩︎
私の印象でも1990年代までは「Linux はオモチャ」だった。それでも Unix ワークステーションの X 端末としては優秀だったので仕事でもよく使っていたが。 ↩︎
“BSTJ 57: 6. July-August 1978: UNIX Time-Sharing System: Forward. (McIlroy, M.D.; Pinson, E.N.; Tague, B.A.) : Free Download, Borrow, and Streaming : Internet Archive” p.1902 参照。 ↩︎

List of Engineering [text.Baldanders.info]

バベッジの憂鬱とヒルベルトの幽霊 — 『我ら、プログラマー』オンライン読書会 第2回目

バベッジと階差機関

ヒルベルト・プログラムと不完全性理論

ブックマーク

参考

AI エージェントを VM に入れれば安全か？

ブックマーク

参考

ロケットとミサイルに関する居酒屋トーク

ブックマーク

我々は何者か？ — 『我ら、プログラマー』オンライン読書会 第1回目

我々は何者か？

参考

技術的負債と生成 AI

ブックマーク

「おもしろい技術書」

K&R

プログラミング言語 Go

デザインパターン本

その他の読み物

ブックマーク

参考

Ubuntu サーバで LLM 構築へ：（2）用語集

人工知能

別表記

意味，定義など

機械学習

別表記

意味，定義など

統計的機械学習

別表記

意味，定義など

ブックマーク

深層学習

別表記

意味，定義など

ブックマーク

ニューラルネットワーク

別表記

意味，定義など

生成 AI

別表記

意味，定義など

大規模言語モデル

別表記

意味，定義など

ブックマーク

トランスフォーマー

別表記

意味，定義など

ブックマーク

RAG

別表記

意味，定義など

ブックマーク

Embedding

別表記

意味，定義など

MCP

別表記

意味，定義など

AI エージェント

別表記

意味，定義など

ブックマーク

Ubuntu サーバで LLM 構築へ：（1）事前学習

アーキテクチャ

モデル選択

nomic-embed-text について

今回はここまで

Secretary as a Service

Agents Window

秘書としての AI エージェント

サービスとしての秘書

ブックマーク

参考

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

Unix 年表

Xenix

バベッジの憂鬱とヒルベルトの幽霊 — 『我ら、プログラマー』オンライン読書会第2回目

我々は何者か？ — 『我ら、プログラマー』オンライン読書会第1回目