List of Artificial-Intelligence [text.Baldanders.info]

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分タイマーでフロー状態から覚めるのは全く効率が悪いということになる。 ↩︎

「オラクルに銃を突きつけろ」

2026-04-22T03:57:28+00:00

最近，面白い記事を見かけたので，紹介がてら戯れ言をつらつらと書いてみる。

「オラクルに銃を突きつけろ」

オラクルに銃を突きつけろ――「予測市場」とグッドハートの法則 » p2ptk[.]org

タイトルだけ見て某企業の話かと思ったのだが，どうやら違うらしい（笑）

あらゆる予測市場は「オラクル［神託］」、つまり、ある事象の結果についての決定的な真実の源泉を必要とする。「今年パキスタンで新たにどれだけの太陽光発電設備が稼働したか」は、一見すると実証的な問いに聞こえる。しかし、すべての参加者が揃ってパキスタンを歩き回り、ソーラーパネルを数えてその設置日を確認するわけにはいかない以上、彼らは何らかの第三者の評価者を権威あるものとして合意し、その判断に従わなければならない。

オラクルに銃を突きつけろ――「予測市場」とグッドハートの法則より

しかしマフィア国家である米国では，その「神託」を告げるジャーナリストを脅して事実を捻じ曲げようとする動きがあるらしい。

真実を報道したことでジャーナリストが殺害予告を受けるのは残念ながら珍しいことではない。 […] だが、ファビアンが語っているのはまったく新しい――はるかに予測不可能な――脅威だ。ある任意の出来事の結果を外した誰かが激怒し、脅しによって賭けを取り戻せると考えるようになったのだ。

オラクルに銃を突きつけろ――「予測市場」とグッドハートの法則より

そして話は「報酬ハッキング¹（reward hacking）」へと続いていく。

機械学習システムに携わった者なら誰でも知っているように、それらは「報酬ハッキング」に陥りやすい。壁や家具との衝突を避けながら室内を最短経路で移動するようプログラムされた機械学習搭載のルンバがそうだった。衝突センサーを前面に搭載したそのルンバは、後ろ向きに室内を動き回るようになり、家具や壁に散々ぶつかりながら、一度も衝突を記録しなくなった。

市場もまた、参加者の報酬ハッキングを誘発しうる。指標が目標になる。あなたはある事象の結果に賭けているつもりでも、実際に賭けているのはオラクルがその結果についてどう言うかだ。結果がどれほど明確で外部からの影響に対してどれほど堅牢であろうと、オラクルはこめかみに銃を突きつければ動かせる。

オラクルに銃を突きつけろ――「予測市場」とグッドハートの法則より

この記事を読んで連想するのは，ゼロ年代に話題になった『ヤバい経済学（freakonomics）』だろう。あの本はインセンティブを軸にした寓話を集めたものだ。たとえば「子供を迎えるため保育園に来る親が遅刻するのを減らすため罰金制（遅刻したら罰金を払う）にしたら，親たちは喜々としてお金を払って遅刻する（お金を払えば遅刻してもOKと考える）ようになった」みたいな話だ（うろ覚えゴメン）。

「アルゴリズムではない」

もうひとつ。 yomoyomo さんの「責任逃れの道具としてのアルゴリズム、そしてAI」経由：

アルゴリズムではない - by 小関悠 - たよりない話

この記事は以下の文から始まる。

アルゴリズムという言葉がこれほど一般的に使われるようになったのは、いつ頃からだろう。私は情報学専攻の学生だったので、本来の意味でのアルゴリズムについて学んだけれど、今ではもっと広い意味でアルゴリズムという言葉が使われるようになった。

アルゴリズムではないより

じゃあ「広い意味でアルゴリズム」とはなんだろう。

いずれにせよ、そうやってアルゴリズムは企業の都合が良いように書き換えられていく。YouTubeが「長尺であれ」といえば長尺が中心になり、「縦型ショートであれ」といえば縦型ショートばかりになる。それはまるで神託であり、それに従わない者は異端とされる。たとえばYouTubeのサムネイルで煽らない者、Xで未だにリンク記事を投稿している者は、プラットフォームに言わせれば神託に従わない、愚かな異端であろう。だがアルゴリズムの内側にいるのは神ではなく、経営者である。

だとすると、そんな恣意的で流動的な仕組みのことをアルゴリズムと言っていいのだろうか？と修士（情報学）の端くれとしては思うのである。それってただの経営戦略では？

アルゴリズムではないより

www

記事では更に，これからは「アルゴリズム」に代わって「AI」が「神託」として濫用（乱用？）されるだろう，と予測している。

これからAIが普及するほど、なにも考えず「AIが言ってたのだから正しい！」「AIはこう言っているから従うべきだ！」と言う人達が増えていくのだろうと思うと憂鬱だが、AI企業はそうした人達を止めようとはしない。一方で、いまアルゴリズムの責任を取ろうとしないように、AIの言動が批判されてもその責任を取ろうとはしないだろう。

アルゴリズムではないより

最近 SNS の TL に上がってるポストやリンク先の記事を見て思うのは AI の礼賛者も批判者も AI を信じすぎじゃね？ということだ。でも2つの記事を読んで何となく納得した。礼賛者にとっても批判者にとっても AI (の言うこと) は御神託で，御神託に対する反応のベクトルが真逆なだけなのだ。

AI を無理やり擬人化するなら，御神託を言う AI の背後に権威者（または権力者）が銃を突きつけてる感じだろうか。あるいは AI はただの狂言回しであって AI を挟んだ人間（社会）関係にこそ目を向けるべきなのかもしれない。

参考

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

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

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)

訳注には「AIは設定された報酬関数（目的関数）を最大化するよう学習するが、この報酬関数が本来の目標を完全に反映していない場合、AIは人間が予期しない「ズルい」方法で目標を達成しようとする」と書かれている。これは AI による報酬関数へのハックと考えればいいのかな。でも，人間側が恣意的に報酬関数を不完全に設定している（もしくは外部から書き換える）場合もあるよな。 ↩︎

Mastodon 10年史を AI に語らせてみた

2026-04-16T01:32:24+00:00

Mastodon の TL を眺めてたら mstdn.jp が10年目に突入したというポストを見かける。 mstdn.jp が10年目に突入したということは，Mastodon 自体は丸10年経ったということになるか？

ここで Mastodon の10年を振り返る記事を書いてみたら面白いと思ったのだが，実は Mastodon って（特に歴史的な部分は）よく知らないんだよね。なので，AI に Mastodon の10年史を語らせてみることにした。

利用サービスは GitHub Copilot with VS Code，選択モデルは GPT-5.3-Codex で行っている。ではどうぞ。

Mastodon が最初に公開されたのは 2016 年です。2026 年は公開から丸10年の節目で，分散型 SNS の歴史を振り返るには良いタイミングだと思います。

Mastodon 略歴（ざっくり）

2016年: Eugen Rochko 氏が Mastodon を公開。Twitter に似た操作感を持ちながら，サーバーを分散運用できる設計が注目される。
2017年: 各地で個人・コミュニティ運営のインスタンスが増加。日本語圏でも利用者が急増し，「連合（Fediverse）」という言葉が広まりはじめる。
2018年ごろ: ActivityPub を中心に，Mastodon 以外の実装ともつながる流れが強くなる。単体サービスではなく「相互接続できるSNS群」としての性格が明確になる。
2019年〜2021年: 大規模な爆発的成長というよりは，コミュニティ運営やモデレーションの知見が蓄積される時期。ローカルルール重視の文化が定着。
2022年: 主要SNSの環境変化をきっかけに，Mastodon への関心が世界的に再上昇。新規インスタンス立ち上げや移住が加速。
2023年〜2025年: 一時的なブームを越えて，日常的に使う人とコミュニティが残るフェーズへ。Mastodon は「代替先」ではなく，独自の選択肢として位置づけられていく。

ここまでを一言で言えば，Mastodon の10年は「中央集権型の巨大SNSに対するカウンター」から始まり，「分散型コミュニティ運営の実践知」を積み重ねた10年でした。

この記事では，この略歴をもう少し丁寧に追いながら，技術・文化・運用の3つの観点で整理してみます。

技術面: Mastodonの10年

技術面で最初に押さえるべき点は，Mastodon が単なる「Twitter風アプリ」ではなく，最初から連合を前提にした実装だったことです。単一サービスの拡張ではなく，サーバー同士の接続を前提にした設計を採ったことで，後の Fediverse 全体の成長に直接つながりました。

1. プロトコル中心への転換

初期の利用者体験は Web UI の分かりやすさに注目が集まりましたが，長期的に効いたのは ActivityPub を軸にした相互接続性でした。これにより，実装が異なるソフトウェア同士でもフォローや投稿配送ができるようになり，「アプリを選ぶ自由」と「コミュニティをまたぐ接続性」が両立しました。

2. 実装の成熟とクライアント多様化

10年のあいだに，Mastodon 本体は機能追加だけでなく，安定性や管理機能の面でも成熟しました。同時に，公式クライアント以外の選択肢も増え，ユーザーは自分に合う UI やワークフローを選べるようになりました。分散型サービスでは，この「クライアント多様性」が継続利用のしやすさを支える重要な土台になります。

3. 分散設計が生む技術的トレードオフ

一方で，分散設計は常にメリットだけではありません。サーバー間配送の遅延，モデレーション方針の差，メタデータや検索範囲のばらつきなど，中央集権型では見えにくい課題が日常的に現れます。ただし，これは欠点というより，「一つの正解に全員を合わせない」設計思想の裏返しでもあります。

4. 2026年時点で見える技術的意義

2026年の時点で見ると，Mastodon の技術的意義は，巨大プラットフォームに代わる機能を再実装したことではなく，「SNSの相互運用を現実にした」点にあります。実装の競争軸を囲い込みから接続性へ移したこと自体が，この10年で最も大きな技術的成果だと言えます。

文化面: Mastodonの10年

文化面で特徴的なのは，Mastodon が「プロダクトの利用規約に従う場」よりも，「コミュニティの合意で育つ場」として発展してきたことです。同じソフトウェアを使っていても，インスタンスごとに雰囲気や価値観が異なり，その違い自体が Fediverse の多様性を作ってきました。

1. ローカル文化の重視

中央集権型 SNS では，全員がほぼ同じルールとランキングに従います。一方 Mastodon では，インスタンスごとにルールやモデレーション方針を設計できるため，小規模でも目的に合った場を作りやすくなります。技術系，創作系，地域コミュニティなど，話題ごとに文化圏が生まれたのはこの仕組みの効果です。

2. タイムライン体験と会話の速度

Mastodon の体験は，アルゴリズム推薦の強い可視化よりも，時系列で流れる会話の連続性に重心があります。結果として，短期的な拡散効率より，継続的なやり取りや顔なじみ同士の関係が育ちやすい傾向があります。これは「バズ中心の文化」から距離を取りたい利用者に支持された要因の一つでした。

3. ブームと定着の反復

この10年で何度か大きな流入が起きましたが，そのたびに全部が定着したわけではありません。ただ，波が引いた後にも一定数の利用者と運営者が残り，文化が薄く積み上がっていきました。急成長よりも，継続的な共同運営を重視する土壌が形になってきたと言えます。

4. 2026年時点で見える文化的意義

2026年の時点での文化的意義は，「巨大サービスの代替」を超えて，「小さな共同体が自分たちの会話空間を持てる」ことを実証した点にあります。Mastodon の10年は，SNSを一枚岩で捉えるのではなく，複数の文化圏の集合として扱う視点を広げた10年でもありました。

運用面: Mastodonの10年

運用面で重要なのは，Mastodon が「使うサービス」でもある一方で，「運営するサービス」でもあることです。大規模プラットフォームでは運営が利用者から見えにくいのに対し，Mastodon では管理者，モデレーター，利用者の距離が近く，運用そのものがコミュニティの性格を決めます。

1. インスタンス運営の実務

インスタンス運営では，サーバー保守だけでなく，利用規約の整備，問い合わせ対応，荒らし対策，バックアップ運用など，多面的な作業が発生します。特に利用者が増える局面では，技術対応より先に運営体制がボトルネックになることも多く，持続可能な分担設計が不可欠でした。

2. モデレーションと連合ポリシー

Fediverse では，どのサーバーと連合するかを各インスタンスが判断できます。この自由度は大きな強みですが，同時に運営の責任も増やします。迷惑行為の封じ込め，外部インスタンスとの関係調整，方針説明の透明性など，モデレーション実務の成熟が長期運用の鍵になりました。

3. 財政と継続性の課題

多くのインスタンスは有志運営であり，コストと労力の持続可能性が常に課題です。寄付，スポンサー，コミュニティ課金など，運営モデルは多様ですが，どれも万能ではありません。10年の蓄積で見えてきたのは，「拡大速度」より「無理なく続けられる規模」を選ぶ判断の重要性です。

4. 2026年時点で見える運用的意義

2026年時点での運用的意義は，SNSの運営をブラックボックスにせず，コミュニティが意思決定に参加できる形を実例として示したことです。Mastodon の10年は，技術と文化を支える土台として，運用設計そのものがプロダクトの一部であることを可視化した10年だったと言えます。

近年台頭してきた Bluesky との比較

近年は Bluesky も急速に存在感を高めており，分散型 SNS の文脈で Mastodon と並べて語られることが増えました。両者は「中央集権型 SNS に依存しない選択肢」という点では近い一方で，重視する設計とコミュニティの作り方には違いがあります。

プロトコルと構造: Mastodon は ActivityPub を前提に，複数サーバーの連合運用を早期から実践してきました。Bluesky は AT Protocol を軸に，IDやデータ可搬性をより前面に出した設計を進めています。
体験と文化: Mastodon はインスタンスごとのローカル文化が濃く，コミュニティ単位で空気を作る傾向があります。Bluesky は比較的単一空間に近い体験から入りやすく，公開空間での拡散と会話の見通しやすさが強みです。
運用モデル: Mastodon は各インスタンス管理者の裁量が大きく，運営方針の多様性がそのままネットワークの多様性になります。Bluesky はプラットフォーム提供側の整備と利用者体験の統一感を活かしつつ，段階的に分散化を広げるアプローチを取っています。

要するに，Mastodon は「先に分散運用を社会実装した10年」，Bluesky は「分散化を再設計しながらスケールを狙う現在進行形」と整理できます。どちらが優れているかではなく，設計思想の違いを理解して使い分けることが重要です。

まとめ

Mastodon の10年を振り返ると，重要だったのは単なる機能競争ではなく，「つながり方の設計」を社会に実装したことでした。技術面では相互運用性を現実のものにし，文化面では小さな共同体の多様性を支え，運用面ではコミュニティが意思決定に関与するモデルを積み上げてきました。

その意味で，2026年は「分散型SNSは成立するのか」という問いに対して，Mastodon がすでに10年分の実例を示した年だと言えます。これから先は，Mastodon と Bluesky を含む複数の流れがどう交差し，利用者にどんな選択肢を広げていくかを見ていく段階に入った，と私は考えています。

Mastodon どうでしょう

アウトラインは AI と一緒に考えたが（AI だけに考えさせると論文みたいな構成になるw），中身は 100% AI による記述で，私は1文字も触っていない。

どうだろうか¹。私なんか文章を読んで「ほほう」と感心してしまったよ（笑）

しかし10年か。 Mastodon の登場は一昔前の話になってしまったねぇ。日本で Mastodon が話題になった頃に「GW 過ぎたらみんな忘れてるに100カノッサ」と言ってた頃が懐かしいよ。当時は Twitter がここまでメタクソ化するとは思わなかったし「どうせ山ほどある Twitter クローンのひとつでしょ」という認識しかなかったからなぁ。

IT 業界は2〜3年でシーンが変わるからな。 10年も経てば，そりゃあ変わるか。

ブックマーク

Kagi Assistant にも同じように聞いてみたが，こちらは Mastodon が「強力なアンチハラスメントツール」として機能していることを強調していた。ユーザ側の高度なフィルタリング機能や投稿時に公開範囲を制御できることを評価しているみたい。 ↩︎

GitHub Copilot はシェル芸達者

2026-04-09T06:57:34+00:00

最初に予防線を張っておくと，この記事は技術系の内容ではありませんし，私は生成 AI の扱いにも慣れてません。その辺を割り引いて読んでいただけるとありがたいです。

生成 AI にどこまで任せていいのか

最近は GitHub Copilot に開発支援だけじゃなくて，このブログのメンテナンスもさせている。なにせ，どこまで任せていいのか匙加減がさっぱり分からないので，できそうなところから徐々に任せていく感じ。気分は新卒社会人の OJT だぜ（笑）

今のところ GitHub Copilot に任せているのは以下の作業：

タイトル & slug の提案と記事ファイルの作成
書いた記事の校正とタグの提案
記事ファイルの commit & push
ブログのビルドと GitHub Pages への commit & push
Hugo の更新

記事そのものは書かせてない。

いや，生成 AI に書かせるとホンマに好き勝手な（私の意図とは程遠い）ことを書くのよ。一度，タイトルだけ決めたまっさらな状態で書かせようとしたら「何の論文を書く気？」って感じのアウトラインを組み始めて，さすがに止めた。ブログ記事に10個も章立てしてどうする（笑）

よくアフィリエイト記事を AI に書かせて云々みたいな話を聞くけど，ホンマに AI に書かせてるの？かなり無茶苦茶するぞ。ある意味，文才があるのかも知れないが。

というわけで「記事を書く」以外の作業をやらせている。

ちなみにモデルは GPT-5.3-Codex を使っている。あまり Premium Request を消費したくないので最初は GPT-5 mini を使ってたのだが，どうもこの手の「作業」には向かない感じ。最終的にはローカル LLM を構築したいのだが，お試しレベルならともかく，まともに動くモデルを個人環境で構築するのは難しいか？

タイトル & slug の提案と記事ファイルの作成

私は最初にタイトルを決めないとブログ記事が書けない。マイクロブログ程度の短文ならともかく，ブログ記事でタイトルも決めずに書き始めると大抵記事が迷走する（タイトルを決めて書いても迷走しがちなのだが，それはそれ）。

手順としては

日本語のタイトルを決める（ここだけ私の作業）
Copilot に英語の翻訳と対応する slug を提案させる（たいてい複数個の候補を提案してくれる）
slug が決まったら記事ファイルを作成させる
ファイル内の front matter を埋めさせる

という感じ。日本語タイトルを英訳させるための対話で，色々と気付きがあって面白い。

たとえば日本語タイトルが曖昧で英訳が頓珍漢な文になることがある。これは生成 AI 以前の機械翻訳サービスを使ってたときもそうだったが，機械と対話することで「文のこの部分が誤解を招いてるのか」と気づいたりできるわけだ。こういったやり取りが意外と面白かったりする。

記事ファイルの作成用にシェルスクリプトを組んでいるのだが，まずその挙動を理解させるところから始めた。したら「このスクリプトをリファクタリングするか？」と訊いてきたのでやらせてみたら，なかなかいい感じに仕上げてくれた。これなら AI にスクリプトを改善させることもできそうだ。

他の既存のスクリプトについても同様にリファクタリングさせ，それらの使い方を copilot-instructions.md および README.md にまとめさせた。

書いた記事の校正とタグの提案

私のブログは意図的に文体を崩して書いているので（設計書やビジネス文書じゃあるまいし），下手に賢い lint では却って使いづらかったりする。ためしに Copilot に「誤字だけ指摘して」と指示してみたら，いい感じに結果を返してくれた。以来，校正は Copilot に任せている。

誤字だけでなく慣用句の漢字間違いの指摘とかは結構ありがたかったり。それでいて崩した文体については一切スルーしてくれる（笑）偉い偉い。

もうひとつ悩んでいるのが記事に付与するタグの選択だ。これを普通に AI に任せるとメチャクチャにしてくれるので，まずは過去の記事を全て浚ってタグの一覧を作らせるところから始めた。

したらすごい勢いでシェルスクリプトを書き始めた。私はそれを「へぇ。なるほど」とか言いながら眺めるだけ。アレだ。ペアプログラミングってやつ（笑）機械相手にペアプロすることになるとは思わなかった。

せっかくいい感じのスクリプトを書いてくれたので，それをファイルにまとめていつでも呼び出せるようにさせた。タグの一覧を出現数の多いものからソートして CSV ファイルに出力させる。ここまでできれば，作成した記事に対してタグ一覧の中から妥当なタグを提案するよう指示すればよい。

タグ一覧を作ったメリットはもうひとつあって typo がいくつか見つかったのと似たような意味のタグの重複が見つかった。見つけたのも Copilot だけど（なにせ10年以上の間にタグが450個以上できてるのだ）。これらも修正方針を提案させた上で修正させた。ファイル作業に関してはちゃんと手順を踏めば間違えることなくやってくれる。

記事ファイルの commit & push

記事ファイルの commit に関しては，念のため，最初に commit message を提案させて，私が確認してから実際の作業を行わせている。ここで GPT-5 mini と GPT-5.3-Codex の違いが大きく出た。

いや，ブログ記事の追加なんだから AI (君) のしたことを書くんじゃなくて，どんな記事を追加したのかを書けよ！

というわけで，GPT-5 mini は向いてないという結論になった。 commit & push するためのコマンドラインの組み立て自体はどちらも大差ないんだけどねぇ。

ブログのビルドと GitHub Pages への commit & push

ブログのビルドと GitHub Pages への commit & push についても以前からスクリプトファイルを作っていたので，それをそのまま Copilot に使わせている。まぁ，自分でやったほうが早いのだが，作業の一連を任せることに意味があると思ってるので，敢えて任せている。この辺も OJT っぽいよな（笑）

指示も最初はできるだけ具体的にしていたが，最近は「デプロイして」だけでも（過去の作業履歴や copilot-instructions.md の記述から）適切に処理してくれるようになった。

Hugo の更新

このブログは静的サイトジェネレータである Hugo を使って構築しているのだが，未だ v1 に到達せずベータ版のままである。古いテンプレート変数や関数のいくつかは deprecated になっているし，稀に破壊的変更が起きることもある。 Hugo のバージョンアップのたびにビルドし直して互換性等の確認をしているのだが，だんだん面倒くさくなってきたので，これも Copilot に任せてみることにした。

今回もゴリゴリとスクリプトを書き始める AI。私も前と同じく様子を眺めていたが，出来がよさそうなのでスクリプトファイルとして書き出してもらった。こんな感じ（長いぞ！）。

#!/usr/bin/env bash
set -euo pipefail

# Install latest Hugo Extended .deb from GitHub Releases using apt.
# Usage: ./hugo_inst.sh

REPO="gohugoio/hugo"
API_URL="https://api.github.com/repos/${REPO}/releases/latest"
WORK_DIR="${TMPDIR:-/tmp}/hugo-inst.$$"

cleanup() {
  rm -rf "$WORK_DIR"
}
trap cleanup EXIT

mkdir -p "$WORK_DIR"
cd "$WORK_DIR"

arch="$(dpkg --print-architecture)"
case "$arch" in
  amd64|arm64)
    ;;
  *)
    echo "Unsupported architecture: $arch" >&2
    echo "This script supports: amd64, arm64" >&2
    exit 1
    ;;
esac

echo "Current Hugo:"
if command -v hugo >/dev/null 2>&1; then
  hugo version || true
else
  echo "hugo command not found"
fi

echo "Fetching latest release metadata from ${REPO} ..."
release_json="$(curl -fsSL "$API_URL")"

version="$(awk -F '"' '/"tag_name"/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$version" ]]; then
  echo "Failed to read latest release version." >&2
  exit 1
fi

asset_url="$(awk -F '"' '/"browser_download_url"/ && /hugo_extended_.*_linux-'"$arch"'\.deb/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$asset_url" ]]; then
  echo "Failed to find hugo_extended .deb for architecture: $arch" >&2
  exit 1
fi

deb_file="${asset_url##*/}"

echo "Latest release: ${version}"
echo "Downloading: ${deb_file}"
curl -fL --retry 3 --retry-delay 2 -o "$deb_file" "$asset_url"

# Optional checksum verification when checksums.txt exists in latest release.
checksums_url="$(awk -F '"' '/"browser_download_url"/ && /checksums\.txt/ {print $4; exit}' <<<"$release_json")"
if [[ -n "$checksums_url" ]]; then
  echo "Downloading checksums.txt for verification ..."
  curl -fL --retry 3 --retry-delay 2 -o checksums.txt "$checksums_url"

  if awk '{print $2}' checksums.txt | grep -qx "$deb_file"; then
    echo "Verifying checksum ..."
    grep "  $deb_file$" checksums.txt | sha256sum -c -
  else
    echo "checksums.txt does not include ${deb_file}; skipping verification."
  fi
else
  echo "checksums.txt not found in latest release; skipping verification."
fi

echo "Installing ${deb_file} with apt ..."
sudo apt install -y "./$deb_file"

echo "Installed Hugo:"
hugo version

echo "Done."

これについては，私は1行も触っていない。

手順としては

インストールするマシンのアーキテクチャを確認して対応する .deb ファイルをダウンロードする
可能ならチェックサムの検証も行う
ダウンロードした .deb ファイルを apt install コマンドでインストールする

という感じ。

これを実行して Hugo を更新した後，ブログのビルドを行い，ビルド前後の差分を調べて問題がないことを確認する。問題がなければビルドしたものを commit & push させる。

「問題がないことを確認する」の部分は私が判断しているので完全な自動化ではないが，今のところ問題は起きていない。

GitHub Copilot はシェル芸達者

という感じで緩々と GitHub Copilot を使っている。

今回の一連で意外とシェル芸達者なのが分かったので，自宅機に CLI 版を入れようかなぁ。でも，結城浩さんほど使い倒す勇気はないんだよなぁ。それよりもローカル LLM 構築に向けて環境を整えるほうが先か？

参考

フルスクラッチから1日でCMSを作る_シェルスクリプト高速開発手法入門改訂2版 (アスキードワンゴ): 上田隆一 (著), 後藤大地 (著), ＵＳＰ研究所 (監修); ドワンゴ 2019-07-05 (Release 2019-07-05); Kindle版; B07TSZZPWN (ASIN); 評価

既存の常識に凝り固まったソフトウェア・エンジニアに「痛恨の一撃」を加える快書もしくは怪書。

reviewed by Spiegel on 2014-09-21 (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-25T01:56:32+00:00

久しぶりに yomoyomo さんの記事を起点に。実は，いつものように脊髄反射的に Mastodon へポストしようと途中まで書いて「マイクロブログに書く分量じゃないわ」と気がついた。

触媒としての人工知能――それを作る前に人類は絶滅するのではないか？ – WirelessWire & Schrödinger’s

ゴメン。これを読んで『超知能AIをつくれば人類は絶滅する』を読もうとは微塵も思わないけど yomoyomo さんの記事は面白かった。いや，書評記事ではなさそうだし，この感想はこれでいいのか？

個人的には後半の

そして、本書に描かれる超知能AIの人間の事情を一顧だにしない傲岸さ（飽くまで人間側から見た感想）を読んでいて、ワタシが連想したのは、自分と意見が合わない相手を「NPC」と軽蔑的に呼ぶイーロン・マスクだったりします。

触媒としての人工知能――それを作る前に人類は絶滅するのではないか？より

あたりから以降が特に面白かった。これってめっちゃキリスト教的だよね。いや，こんなことを言うと確実にクリスチャンの方々に叱られるだろうけど。

キリスト教というか唯一神（or 絶対神）信仰って，神をアイデンティティの中心に据えた包摂型（あるいはその裏面としての排除型）社会と思っている¹。自分が神の意志に沿って生きてると確信しているからこそ，その意に沿わない輩を NPC 呼ばわりできるわけで。これって典型的な「反知性主義」ぢゃん。

と思いながら続きを読んだら

「反キリスト」とか「ハルマゲドン」とか「黙示録」とか宗教的なワードがやたら散見されますが、イランを爆撃した米国の国防長官ピート・ヘグセスが、「我々は明らかに、ある種の宗教的なハルマゲドンをもたらすために核能力を追求する宗教的狂信者たちと戦っている」と語るなど「アメリカの十字軍」を公言し、またある軍司令官は「イランとの戦争はハルマゲドンであり、イエスの再臨をもたらす」と訓示するなど、実は権力中枢のほうが既に宗教がかっている現実があったりします。

触媒としての人工知能――それを作る前に人類は絶滅するのではないか？より

とか書いてあって「うわぁ」となった。極端な政治的立場をとる人を極左だの極右だの極中道だの言うらしいが，さしずめこれは「極キリスト教」といったところか。 20世紀末にオレオレキリスト教義に則って世界を滅ぼすという作品が流行ったが（ゲームの「火星物語」もキリスト教的なモチーフ満載で面白かった），世紀を跨いでガチでやる国があるとは思わざりき。

数ある竹本泉作品のネタのひとつに「知的存在を創り宇宙へ旅立つ高位存在と取り残される被造物」というのがある。たとえば「ねこめ〜わく」とか（笑）竹本泉さんがキャラクター原案をされた「アポカリプスホテル」は，人類がパンデミックのために宇宙に逃げちゃったあとの地球を描いたものだけど「取り残される被造物」という構図² に竹本泉ファンとしては大歓喜してしまう。

ぶっちゃけ，機械が人類にとって代われるほど文明が発達したのなら人類はとっくに地球から逃げてるよなぁ，と思う。もっとも，身体中の関節が外れたかのような今の狂った社会情勢では yomoyomo さんの「人類は超知能AI以前に既に絶滅の暗路を辿っている」という「疑い」に激しく同意してしまうのだが。

「AI 黙示録」といえば先日紹介した Cory Doctorow さんの新刊だが，同じ「黙示録」でも両者のあまりの温度差に風邪を引きそうである（本を読んでないのにw）。 Cory Doctorow さんの新刊のほうは邦訳が出るならぜひ読みたい。どうなるやら。

ブックマーク

参考図書

ねこめ（～わく）１ (夢幻燈コミックス): 竹本泉 (著); ハーパーコリンズ・ジャパン 2013-09-24 (Release 2015-08-25); Kindle版; B013SEV0DA (ASIN); 評価

『ねこめ〜わく』から続く，竹本泉さんのライフワーク的作品（？）惜しむらくも7巻で完結してしまった。続編を望む（笑）

reviewed by Spiegel on 2021-04-05 (powered by PA-APIv5)

アポカリプスホテル: ©アポカリプスホテル製作委員会 (監督), CygamesPictures (クリエイター), 村越繁 (Writer), ©アポカリプスホテル製作委員会 (出演); (Release 2025-02-13); Prime Video; B0F1RSSCTS (ASIN); 評価

オリジナルアニメ。竹本泉さんがキャラクタ原案を担当。スピンオフ漫画もある。これ，シナリオ考えた人は絶対に歴代の竹本泉作品群を読み込んでるだろう（個人の感想です）。ロボット達もちょっと「アレックス」ぽいコミカルさ（有能で融通が利かない）があるし（笑）

reviewed by Spiegel on 2025-04-19 (powered by PA-APIv5)

アポカリプスホテルぷすぷす (バンブーコミックス): 竹本泉 (著), ホテル銀河楼管理部 (企画・原案); 竹書房 2025-07-07 (Release 2025-07-07); コミック; 4801986919 (ASIN), 9784801986916 (EAN), 4801986919 (ISBN); 評価

アニメ「アポカリプスホテル」のキャラクタ原案を担当した竹本泉さんによる公式コミカライズ？でも内容はいつもの感じ。ちなみに電子版はカラーのあとがきが追加されている。両方買わないと。いやぁ，竹本泉さんが関わってホンマにアニメになったんだねぇ（笑）

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

たとえば聖書が「神と人との約束」を説いたものであるとするなら，日本の古代神話は「神と神との約束」を説いたものだと言われている。人が等しく「神の子」であるなら「神と神との約束」は人同士であっても有効である（神と人は約束しない，神同士の約束を模倣する儀礼が重要），というのが神道の根幹と言える。まぁ，その辺にいる日本の神は “God” じゃないけどね。意図的な誤訳だよな（笑） ↩︎
「ねこめ〜わく」の猫たちや「アポカリプスホテル」のロボットたちに感情移入しそうになるのは，ポンコツな私達人類も神との関係において「取り残される被造物」だからだ！とか言ってみたり。 ↩︎

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 導入を名目とした大量レイオフの話は今だに耳にする。でもそれで成功したという話はあまり聞かない。むしろ方針を再度曲げてエンジニアを雇い直そうとする話がちらほら聞こえ始めている。まぁ「機械があるから君は要らないよ」などと言われた会社にのこのこと戻る人はおらんじゃろう。浮気した男は反省してもまた浮気する。どこぞの恋愛小説の登場人物みたいである（笑） ↩︎
「西遊記」の三蔵法師とモデルとされた玄奘との間にはだいぶギャップがあるみたいなので，今回はヘタレの三蔵法師の方に寄せてみた（笑） ↩︎

「ChatGPT は安全か？」

2026-03-07T11:47:23+00:00

前回の記事のあとにこれだと「またぞろ政治の話か」と思われそうだが，今回は純粋にリスク・マネージメントの話。 Proton のブログより。

Is ChatGPT safe to use? Here’s what you should know. | Proton

ChatGPT に限らないが生成 AI サービスの大半はユーザが入力したデータやプロンプトをサービスプロバイダ側が入手できる。実際にサービスプロバイダの多くはユーザの入力（データもプロンプトも）を保持して学習に使ってるし，インシデントの際は（政府を含む）第三者にそれを開示している。また広告・分析会社に情報を売っていた例もあるし ChatGPT との会話内容が Google 検索に拾われてしまった例もあったそうな。

そうしたリスクを改めて思い起こさせたのが前回紹介した事例で，これによって400万人以上のユーザが ChatGPT を止めると宣言しているらしい¹。

件の記事では ChatGPT に対して「個人のプライバシー」「ビジネスリスク」「透明性の欠如」の3つのリスクを挙げている。詳しい内容は（結構ボリュームがあるので）ここでは割愛する。

Even though ChatGPT can be helpful, you should never treat it like a secure vault for sensitive information. Avoid entering anything that could harm you, your company, or others if it were stored, reviewed, or accidentally exposed:

via Is ChatGPT safe to use? Here’s what you should know.

それでも ChatGPT を使いたいならどうすりゃいいの？ということで，入力してはいけないものとして以下を挙げている。

via Is ChatGPT safe to use? Here’s what you should know.

具体的にはこんな感じ：

パスワードと認証データ： アカウントのパスワード，二要素認証（2FA）コード，バックアップ認証コード，プライベートAPIキーなど
政府発行の識別番号： 社会保障番号，国民ID，パスポート，運転免許証，納税者番号など
金融および銀行情報： クレジットカードまたはデビットカードの番号，IBAN，オンラインバンキングの認証情報，投資口座のログイン情報，ビットコインウォレットの秘密鍵など
機密性の高い個人データ： あなたやあなたの家族を特定または追跡するために使用される可能性のある情報。自宅の住所や電話番号，生年月日，プライベートな写真や文書など
健康情報： 医療報告書，診断記録，保険番号，患者ID，またはあなたの身元に結びついた詳細な健康履歴など
機密性の高い業務データや企業データ： 独自のソースコード，社内戦略文書，機密契約書，顧客データベース，クライアント詳細情報，財務予測，未公開レポート，NDAなど
法的情報および秘匿特権のある情報： 弁護士と依頼人間の通信，訴訟戦略，証拠書類，秘密の和解交渉など

いや，まぁ， AI サービスでなくても当たり前なんだけどね，これ。こういう情報をうっかり漏らしてしまうというのは，やっぱ生成 AI サービスはデータ構造が分かりにくい（というか構造がない）というのが根底にあるんじゃないだろうか，と思ったり。

さらに ChatGPT を安全に利用するために以下の習慣を身につけると良いとある。

保存，レビュー，または公に公開されたくない機密情報の（AIとの）共有は避ける
個人を特定できる情報を削除するか，プレースホルダーや架空の例に置き換える
機密情報や個人情報を含まないファイルのみをアップロードする
AIチャットは，他の人に見られる可能性のあるメールやサポートチケットのように扱う
プライバシー設定を確認し，チャット履歴，メモリ，AIトレーニングなどの設定は無効にする
不要になった会話を削除し，アカウントに関連付けられた個人情報の量を減らす

もちろん生成 AI サービスを乗換える手もある。

(明らかに宣伝だがw) Proton の Lumo はユーザデータを「ゼロアクセス暗号化」することを売りにしていて，履歴を一切保存しないゴーストモードもあるらしい²。

私が常用している Kagi Assistant は匿名性を売りにしている。また「ユーザデータは負債である」というポリシーを持っていて，できるだけユーザデータをサービス側に保存しないようにしているそうな³。

いっそのこと SaaS など使わずオンプレミスで AI 環境を構築するという手もある。企業・組織はこのほうがいいかも知れない。軍事関係もね（笑）

（Grok や Google は元から悪いが）今回の騒動で Anthropic や OpenAI といった大手のサービスはセキュリティやプライバシーのリスク観点からは旗色が悪くなったように思う。各サービスにおける運用のポリシーや透明性を見極めて，賢く使うのがいいと思う。所詮は道具なんだから。

ブックマーク

参考

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので，そのへんを加味して読むとよい。

reviewed by Spiegel on 2019-02-11 (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)

2026-03-07 時点。 ↩︎
Lumo に対する PrivacySpy のスコアはないが Proton VPS については 8.1 (10点満点) と評価されている。データ侵害が発生した場合のユーザへの対応がイマイチらしい。まぁ，高スコアではあるので Lumo もこのくらいならいいんだけど。 ↩︎
Kagi Assistant に対する PrivacySpy のスコアはないが Kagi 検索サービスについては 7.5 と評価されている。一般的なセキュリティ・ポリシーが曖昧なのと，法執行機関の要請への対応が明記されてない点がマイナス要素らしい。 ↩︎

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 を含めてまだ存在しない。将来は知らないが。 ↩︎

「プロンプトウェア・キルチェーン」

2026-02-17T01:25:14+00:00

“Promptware Kill Chain” をどう訳していいか分からなかったので，とりあえずそのままカタカナで「プロンプトウェア・キルチェーン」としてしまった¹。きっとそのうち偉い人が適切な訳語を考えてくれるだろう。英単語をカタカナに伸ばしただけなんてダサいし，それによって言葉の意味が消失するのは拙いと思う²。けど，私は英語不得手だからなぁ…

（内容は同じ）

この記事は Oleg Brodt, Elad Feldman, Bruce Schneier, Ben Nassi による共著で，斜め読みするに以下の（同じ著者による）論文の解説になっているようだ。

[2601.09625] The Promptware Kill Chain: How Prompt Injections Gradually Evolved Into a Multistep Malware Delivery Mechanism

論文の要旨は以下の通り：

Prompt injection was initially framed as the large language model (LLM) analogue of SQL injection. However, over the past three years, attacks labeled as prompt injection have evolved from isolated input-manipulation exploits into multistep attack mechanisms that resemble malware. In this paper, we argue that prompt injections evolved into promptware, a new class of malware execution mechanism triggered through prompts engineered to exploit an application’s LLM. […] By moving the conversation from prompt injection to a promptware kill chain, our work provides analytical clarity, enables structured risk assessment, and lays a foundation for systematic security engineering of LLM-based systems.

via The Promptware Kill Chain: How Prompt Injections Gradually Evolved Into a Multistep Malware Delivery Mechanism

つまり，プロンプト・インジェクションやジャイルブレイクといった個々の事象にフォーカスするのではなくマルウェアに類似した多段階の攻撃メカニズムを「プロンプトウェア」と定義し，理解に必要な語彙やフレームワークを政策立案者やセキュリティ専門家に提供することが目的のようだ。なので，既に AI システムを導入している（あるいはこれから導入する）企業・組織のセキュリティ担当者は，論文のほうを読んでおくといいかもしれない。

プロンプトウェアには以下の7つの段階がある。

Initial Access (初期アクセス) : プロンプト・インジェクション等（悪意のあるペイロードが AI システムに侵入）
Privilege Escalation (権限昇格) : ジャイルブレイク等（安全トレーニングやポリシーのガードレールの回避）
Reconnaissance (偵察) : 資産，接続されているサービス，および能力に関する情報を明らかにさせる
Persistence (永続化) : 長期記憶に自身を埋め込む，またはエージェントが依存するデータベースを汚染
Command and Control (C2; 指揮統制) : 攻撃者がその挙動を変更できる制御可能なトロイの木馬へと進化
Lateral Movement (水平展開) : 他のユーザ，デバイス，またはシステムへと拡散。マルウェア拡散の高速道路を作り出す
Actions on Objective (目的の実行)

via The Promptware Kill Chain - Schneier on Security

こうやって見るとプロンプト・インジェクションなどは一連の攻撃の取っ掛かりに過ぎないことが分かる。最終段階では仕込まれたマルウェアが発火して攻撃者の目的が実行される。

The goal of promptware is not just to make a chatbot say something offensive; it is often to achieve tangible malicious outcomes through data exfiltration, financial fraud, or even physical world impact.

via The Promptware Kill Chain - Schneier on Security

実際に AI エージェントによって攻撃者のウォレットに暗号資産が送金された事例とかあるらしい。他にも

といった論文がある。

根本的な問題は LLM 自体のアーキテクチャにあると言う。

Unlike traditional computing systems that strictly separate executable code from user data, LLMs process all input—whether it is a system command, a user’s email, or a retrieved document—as a single, undifferentiated sequence of tokens. There is no architectural boundary to enforce a distinction between trusted instructions and untrusted data. Consequently, a malicious instruction embedded in a seemingly harmless document is processed with the same authority as a system command.

via The Promptware Kill Chain - Schneier on Security

つまり LLM はコマンドとデータを区別できず全てを一連のトークン列として処理するため，容易に悪意を忍ばせることができる。

初期アクセス（プロンプト・インジェクション等）を防ぐことが難しいなら，後続のステップで防ぐしかない。権限昇格の制限，偵察の制約，永続化の防止，C2の妨害，エージェントが実行を許可されるアクションの制限といった対策で多層防衛を構築する必要がある。

某マスク氏率いる xAI について

One source said, “Safety is a dead org at xAI,” while the other said that Musk is “actively is trying to make the model more unhinged because safety means censorship, in a sense, to him.”

via Is safety ‘dead’ at xAI? | TechCrunch

みたいな話もあるようだが，そんな牧歌的な段階はとうに過ぎてるということだろう。他の大手 AI サービス・プロバイダはどうなんだろうねぇ。

そういえば先日公開された「AIによる民主主義の巻き返しは可能か」で “Rewiring Democracy” に関して

実際、やはり情報セキュリティ分野の専門家であるベン・ロスキーが本書について、「AIを民主主義のために利用する上で最大の障壁はセキュリティだが、その話が第27章になるまで出てこない」「セキュリティなくして信頼は成立しないのに、著者らは今日のAI開発において、セキュリティは後付けの考慮事項だと言わんばかりだ」と不満げに書いているのを読んで思い至ったのですが…

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

という指摘があったが，複数のレイヤできっちり仕事をされる Bruce Schneier 先生マジすげーなと思ったのであった。

参考

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (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)

“kill chain” は元々軍事用語で，敵軍の構造を破壊（切断する）することで自軍を守る先制処置の考え方らしい。これをサイバーセキュリティの分野に持ち込んだのが “Cyber Kill Chain” なんだそうで，攻撃の段階構造を理解し，各段階に対してそれぞれ有効な対策をとることで自システムを多層防御するフレームワークを指すとのこと。故に “Promptware Kill Chain” は本文で紹介するプロンプトウェアの7段階を理解し，各段階それぞれに対して有効な対策をとるべき，という意図なのだろう。 ↩︎
“enshittification” を「メタクソ化」と訳した p2ptk.org の中の人は天才だと思う。 ↩︎