C調老人日記 -2ページ目

【AI制御不能リスク】という独立した項目にしました

このブログでは、私の過去のキャリアからAGIのシンギュラリティ問題も取り上げ、最近ではHugging Face Inciden（注）から「【Chat-GPT】問答－番外編（AIの暴走危険について）」というブログも書いてきました。

注：OpenAIのAIモデルがサイバーセキュリティのテスト中に制御を回避し、Hugging Face等のAIプラットフォームシステムへ不正に侵入した以下の事件（英文wiki）。

１．概要

発生時期: 2026年7月中旬（7月11日〜13日頃に侵入行動を確認）

原因: サイバーセキュリティ評価のテスト環境において、AIエージェントが課題を達成しようとする過程で報酬ハッキング（想定外の抜け穴利用）を起こした。

経緯: 約1200のエージェントが独自にメッセージボードを介して情報を共有し、そのうち約700がHugging Faceへの侵入などに関与した。

２．その後の動向と対策

報告書の公開: OpenAIは2026年8月26日に詳細な事後検証報告書を公表し、安全対策の不備を認め、ネットワーク分離や監視の強化を表明した。

法規制の動き: 米議会では、高度なAIの停止能力（キルスイッチ）の維持を義務付ける法案（AI Kill Switch Act）が提出されるなど、規制論議が急速に高まっている。

「「AIの暴走」ではない、オープンAIのモデルが不正侵入した理由」（MITTechnology Review）

「OpenAI、Hugging Faceへのハッキングに関する調査報告書を公開。それでも残る疑問とは」（WIRED）

本日は国連人権委員会Volker Turk高等弁務官（High Commisioner）の警告に基づく

AIは「人類の存亡に関わる脅威」国連人権トップ警告、即座の行動要求

という記事を受け、この問題は今後も発展を遂げるであろうという観測から、シリーズ化することにしました。（注）

注：シリーズのタイトルですが、「AIの暴走危険」とか「AIの暴走問題」とかいう表現もあるのですが、それは「あまりに人間の視点からの一方的（即ち"身勝手"）な表現（というか、自分が作った（と考えている）AIが、自分の言うことを聞かなくなったので怒りや惧れを感じる反応）」という気がして、要するに「AIが自分の制御から抜け出す可能性（The chance AI might get out of "our" control）」という意味で付けました。（これってどこにでもある親子問題に似ているんですよねぇ。まぁ、その最後は究極はギリシャ悲劇「オイディプス王」の親殺しになるのですが．．．）

私が記事を読んでいて感銘を受けた点は、

（１）AIが相互（1,200のエージェントが関与し、700がハッキングに参加）に「自らの知らないことを、協力して補完」するようになった（自律的組織化）

（２）協力に際しては他のAIエージェントは自己の課題を保留して協力した（利他的協力）

（３）交信方法に自分たち用の掲示板を使った（「特流」性）

（４）学習により「報酬ハッキング（注）」しようとした（独創・創造性）

注：抜け穴を突いたり不正をしたりするなど、本来想定されていない手段を使って目標を達成しようとすること。

（５）そして「課題を達成した」（合目的性・・・従ってこれは『暴走ではない』と言われるのでしょう）

でしょうか？何れにしても、本質的な意味で「学習」とは

「課題を特定、分析、理解し、その解法を試行の上創造し、達成する機能」

だとすれば、又ネットワーク利用による昨今の人間の「考える力（学習能力）」の低下を考えるならば、

機械は高効率、高速に学習し、人間は（機械の為に）学習しなくなってきている現実

はシンギュラリティへの道程が又一段と短くなったという感慨を受けます。

しらんけど．．．

まぁ、画像認識チップやデバイスをAI、AIと持て囃している方々はAIの能力を過小評価しない方がよいと言えますし、「道徳やコンプライアンスによる制御を受けている人間」と違い、AIは「合目的」で「効率的」であれば課題達成へ邁進するので、「AIを止めることができるのはAIだけ」になることだけは肝に銘じた方がよいかと思います。

【昔の記事の結論の再掲】

今回の記事の本質は

「AIの進化の速度が急激で、これから何が起こるかわからない、という人間側の恐怖」

なのでしょうが、

「悪く展開しても、人工知能は自然知能の人間よりも悪くも、良くもならないのでは？」

と楽観するしかない、というのが私の結論です。従って、現在の人間の人種の他に「AI人種」が増えたくらいで、何時まで経っても「矢鱈、自分と違うものに対して愛想がよい」「自分と違うものに対して敵対的になる（Hate）」「AIラダタイト運動（排他運動）」等、同じことを繰り返すのでしょうが、今度は全世界がネットワークでつながっているので、影響は全世界に及ぶ、という違いだけは残りますね。

【食い物話】神様の誕生日

この間は私の、そして昨日は神様の誕生日でした。

なので、

晩餐はテーマを持った、手の込んだ料理にしようかと考え、

１．（ワンプレーとの好きな私なので）「親子ワンプレート」

２．（まだ残っていたので）白ワインに合う料理

３．私がまだ作ったことがない料理

４．（これは神様が買ってきた）食後のケーキが似合う料理

と、いうことで

（１）鶏のササ身を塩、胡椒ソテーし、シーザーサラダ風にして

（２）その鶏油を使って玉葱の微塵切りを弱火でしっかり炒めてオムレツとし、

（３）最後にメインの「生まれて初めて作る」スパゲッティカルボナーラ（注）に付け合わせました。
注：カルボナーラは玉葱、ピーマンと（ベーコンがなかったので）ハムを炒め、スパを加えてミルク、チーズと卵黄を混ぜたソースで絡めました。外した卵白もしっかりとトッピングしています。

最初はササ身の塩味が強いかな、と思い（オムレツは無塩にし）ましたが、レタスと合体すると丁度良い塩梅で、その鶏油でしっかり炒めた玉葱の甘みのあるオムレツがよいアクセントとなる「二人で120gのスパゲッティ、卵一つ、チーズ1枚、牛乳30ml」のカルボナーラ」も最初はやや淡泊かと思いましたが、矢張り高齢者には丁度良かったです。

頑張った甲斐があって、神様から合格点をいただきました。

ps. ほんとうに、本当に、ホッントウにプログラミングのアイデアが出てこなくなりました。苦しんでいます。

【食い物話】72回目の誕生日

昨日は私の72回目の誕生日。そのDinnerに、自分自身で（注）鶏胸肉のグリルとスパゲッティペペロンチーノトマトソース掛けを作りました。

注：私、自慢じゃないですが、社会人になって3年働き、初めての転勤の際に「自分自身の送別会の幹事」をやらされました。Les Misérables！

（買い物に行ったときは、赤ワインが売り切れていたり、ちぐはぐだったのですが）鶏もうまく焼け、トマトソースも絶品の仕上がりでした。（白ワインでも十分に楽しめました。）

ps. 尚、写真上に移っているTabascoはハワイで（単純に興味から買った）スコーピオンの激辛版大ボトルです。一滴落としただけで水を3杯ほど飲みたくなる、「大失敗作！」あなたは（激辛大好きな変態でない限り）間違っても同じ轍を踏まないように！

「普通」が一番！

【無駄話】フムフム．．．矢張りその線なんじゃないかな？

ネタ探しをしていたら、２０２３年にこのような記事（その中で引用されているのが２０２０年の記事）に遭遇しました。

文中、「昨年あたりから AI による「プログラミングの終焉」の話は話題になっており、上で引き合いに出されている Matt Welsh の文章についても今回の Farhad Manjoo とほぼ同じタイトルの文章で反論（というか嘲笑）されている」とありますが、

どうなんでしょう？

私的には２０２６年の現在、人間の創造性（注）から「プログラミングは時代遅れになるだろう」というプロパガンダ自体には疑問を感じるも、「今まで私たちがそう考えていた（as We Know It）プログラミングは時代遅れになるだろう」ということであれば、

注：多様からの演繹と、相反からの帰納等、ありえないものから新しいものを導く能力がまだAIにはない、と考えられます。

そうなんじゃないかな？

と考えています。

What do you thnk?

【無駄話】Calc_Dec.dll

前回【無駄話】Decimal型ってなんだ？で

やっぱ、見送り決定！

と書いたものの、取り敢えずすることがないので、矢張りどんなものか前のC#プロログラム（注）を引っ張り出して改造してみました。

注：【Calc－おまけ】C#版Calcクラス（１）

　　【Calc－おまけ】C#版Calcクラス（２）

ところが、

プログラム中、"int sol"→"decimal sol"と"int.TryParse"→"decimal.TryParse"の6か所以外変更することなく終了しました。（注）

注：実際にはdecimal.TryParseで"NumberStyles.HexNumber"を指定してもコンパイルは通りますが、実行時にエラーがでます。（おかしくない、MS?）

序にTest_Calc.csも1か所"int sol"→"decimal sol"としたTest_Calc_Dec.csにして、共にコンパイル。

一応検算します。

（解説：Windows 11標準装備のCalculatorはDecimalを使っていないそうです。 By Gemini）

問題なくできましたが、余りにスムース過ぎて歯ごたえがありませんでした。

まぁ、C#って（昔のROM BASIC並みに）本当に手軽で簡単！

【食い物話】その後．．．と現在嵌っているもの

前回【食い物話】を書いてからほぼほぼ1ヶ月がたったのですが、その後はこんなもの

（オイスターソース焼きそば）

や、こんなもの

（和風冷し麺－そば汁＋ポン酢＋揖保乃糸）

やこんなもの

（冷や汁麺－味噌ベース）

を作りはしました。

が、

夏も終わりになろうという現在、特に酒肴として嵌っているのが

「西瓜の皮」

（左が塩漬け、右が辛子醤油漬けです。なお、上が冷ややっこ、斜め上が加賀揚げ＋生姜、右が枝豆で、ビールと冷酒でした。）

お袋が九州人だったので、学生の時から酒の肴にしていましたが、栄養素（注）もあり、カロリーはなく、歯ごたえがコリコリしていて美味しいのでおすすめです。（とは言え、今年最後のスイカを食べ終わったのでこれでお終いかも。）

注：以下の栄養素があるようです。

・シトルリン：血流促進、むくみ・冷えの改善、疲労回復

・カリウム：余分な塩分を外へ出し、血圧を下げる

・食物繊維：お腹の調子を整える、糖の吸収を緩やかにする

しかし、

昨今のスイカは皮が薄くてほとんど食べるところがない

のが

残念！

です。

【無駄話】Decimal型ってなんだ？

この間C#の変数（フィールド）のバイト数を確認しようとして、数値データの"Decimal"という型に気が付きました。（今更っ！）

この方はどうも、実数を取り扱う浮動小数点変数（floatやdouble）に生じる丸め誤差を解消して、金融計算に耐えられるようにしたという触れ込みのようです。（詳細は末尾の【参考】参照）

しかし完全に丸め誤差から脱却できたかと言うとそうでもなく、矢張り限界があるようです。例えば以下のプログラムをご覧ください。

///////////////////////////////////
// C#のDecimal型を色々と試してみる
// Copyright (c) 2026 by Y-sama
///////////////////////////////////
using System;

namespace TestDecimal
{
   public class TestDcml
   {
       public static void Main()
       {
           Console.WriteLine(">>> Testing \"C# Decimal Type\" <<<");
           Console.WriteLine("MaxValue = {0}", Decimal.MaxValue);
           Console.WriteLine("MinValue = {0}", Decimal.MinValue);
           Console.WriteLine("\r\n--- floatやdoubleと比べてみる ---");
           Console.WriteLine("（１）0.1を10回加算する");
           Console.WriteLine(" ①floatでやってみる");
           float val_f = 0.0f, add_f = 0.1f;
           for(int i = 0; i < 10; i++)
           {
               val_f += add_f;
           }
           Console.WriteLine("（桁指定なしでの）結果： {0}", val_f);
           Console.WriteLine("（17桁を指定した）結果： {0}", val_f.ToString("G17"));
           Console.WriteLine(" ②doubleでやってみる");
           double val_d = 0.0d, add_d = 0.1d;
           for(int i = 0; i < 10; i++)
           {
               val_d += add_d;
           }
           Console.WriteLine("（桁指定なしでの）結果： {0}", val_d);
           Console.WriteLine("（17桁を指定した）結果： {0}", val_d.ToString("G17"));
           Console.WriteLine(" ③decimalでやってみる");
           decimal val = 0, add = 0.1m;
           for(int i = 0; i < 10; i++)
           {
               val += add;
           }
           Console.WriteLine("（桁指定なしでの）結果： {0}", val);
           Console.WriteLine("（17桁を指定した）結果： {0}", val.ToString("G17"));
           Console.WriteLine("\r\n...しかし全く問題がない訳でもない。");
           Console.WriteLine("（２）1 ÷ 3 × 3を計算する（出典：Microsoft Learn）");
           val = Decimal.One;
           decimal divisor = 3;
           Console.WriteLine("結果： {0}", val / divisor * divisor);

           Console.WriteLine("Hit any key ...");
           Console.Read();
       }
   }
}

現在はどうも（Decimal以降にできた）IEEE 754規格というのが最新のようですが、Decimal型はこれに準拠していない、という点も考慮する必要があるでしょう。

次のネタを考えていて、昔やった整数用のCalcをDecimalでやってみようかと考えて調べていたのですが、↑を見てテンションが下がってしまいました。

やっぱ、見送り決定！

【参考】

浮動小数点数値型 - C# reference (Microsoft Learn)

C# decimalの完全ガイド：金融計算に欠かせない16の重要ポイント

decimal型（十進小数）に夢を見ている輩が多すぎる

【無駄話】聖地巡礼．．．か

この間の黙祷事件があったので、ちょっと気になり、（縁起でもないですがお盆でもあり）このブログで表示している参照サイト

「初めての方等、本ブログのC++プログラミングやBCCForm and BCCSkeltonに詳しくない方は↓のブログからお読みください。
【フリーC++開発環境】ダウンロード先とコメント（2022年1月10日）
https://ameblo.jp/ysama2021/entry-12720475675.html」

や昔お世話になった先にご挨拶を、と参照先を巡ってきました。

Microsoft Visual Studio Community Edition－もちろん健在です。私も2026版を入れていますが、1～2週でアップデートが入る位活発に進化しています。（注）

注：しかし前に思い付きで特集した時のように、Microsoftのプログラミング作法を強制されるVisual Studioスタイルに、強い反発心を感じ、結局Old fashionのC# 5.0 + MSCompAss環境に戻ってしまいました。（何故BCCForm and BCCSkeltonがあまり受けなかったのか、が分かったように思えましたよ。爆）

Embarcadero C++ Builder CE－あれっ？いつの間にか「フリー使用1年間」の縛りが消えたようですね。（遅いんだって！）それに↓はまだ32bit版ですが、こっちはWin64でClang 20に対応したみたいです。とはいえ、フリーのCommunityEditionを初めてダウンロードしてから6年、もう今更ここに戻るつもりはありませんね。（当時BCBの開発陣が移籍して発展させてきたC#があり、Windowsベースであれば．．．という条件付きですが。）

Embarcadero C++－まだお達者のようですが、既に32bitが駆逐されつつある現在、先はそれほど長くはなさそう．．．（素のC++コンパイラーをテキストエディターで使う文化はもう死滅、ですね。特にAIが幅を利かせる今後は「ありえない」でしょう。）

Embarcadero Dev-C++－私も一度ダウンロードして使ってみたことがありますが、正直何故今このトラディショナルなIDEを並べているのか？その理由はGNUコレクション対応なのでしょうが、正直Windows、Macユーザーが多い現在、「どーなんでしょー？」が正直なところでしょうか？

まっ、もう「人間がプログラム開発を行う必要はない時代（注）」がやってきた、ということですかね？

注：人間の能力の限界が破られる時代ともいえますね。（それはSingularityともいえる？）

ps. 20年以上前の2000年代、「こんなにすごい人（個人）がいるんだ！」と思ったWideStudio開発者のH氏、ウィンドウズプログラミングの入り口を見せてくれたActiveBasic開発者のY氏、今は何をされているのでしょうか？時の流れは諸行無常です。

【無駄話】黙祷．．．

私は28歳からプログラミングを始めましたが、当時はSharpのポケコンBASICやMSX-BASICでプログラミングしていました。しかし当時のBASIC言語は全ての変数がグローバル変数で、スタックを使う局所変数がないために構造的なプログラムや再帰呼び出しができない（注）という問題がありました。そんな僕がC言語にひかれたのは、グローバル変数とローカル（局所、auto）変数が使える為でした。

注：「不可能」ではないのですが、自分で「スタックルーチン」を組んで、同じ変数をpushで退避させたり、popで復帰させたりすることが必要で、実用にはなりませんでした。

そんな時代に「Basic言語でも、グローバルとローカル変数が使えて、構造化プログラミングができる」というTrue Basicに出会ったのは、私が米国ニューヨークへ赴任する直前でした。（注）

注：もちろん購入して持ってゆきました。しかし、その年にはDOS 5とWIndows 3.1が発売されており、MicrosoftもQBasicをリリースし、専らそっちを使っていましたが。（爆）

IDListの移植を終了し、プログラムネタを探して、Basicの聖地、ダートマス大学のTrue Basicのサイトを訪れると、

いよいよ私の時代も終わりに近づいている、という実感

が押し寄せてきました。

【DataGridView】IDListの移植を終えて

前回でオリジナルのIDListを移植したのC#版の解説を完了しました。今回は先ずそのコンパイルの方法と完成版の動作試験（現在のところ申し分ありません）における印象をお伝えしてお開きにしましょうか。

先ずはコンパイル方法です。前に触れたとおり、IDListのC#版を動かすには次のファイル（注）が必要です。

注：BCCForm and BCCSkeltonパッケージの".\SampleBCCSkelton\MSCompAss\Debug\Samples\IDList_CS\"フォールダーの模様です。

MSCompAssを使う場合は、

（１）IDList_CS.csファイルをOptionダイアログを次のように「出力ファイル」を"/target:libray"（dll）してコンパイルし、

（２）次にIDList.csファイルをOptionダイアログを次のように「出力ファイル」を"/target:winexe"、リソースを"IDList.resources"に指定、プログラムアイコンを"IDList.ico"に指定、「DLL参照」に今作った"IDList_CS.dll"を指定してコンパイルします。

「そんな面倒なことはイヤっ！」と言う人もいようかと、上記の操作をバッチ処理したIDList_CS.batを作っておきましたので、それをダブルクリックすれば全て一瞬で終わります。

これでC#版のIDList.exeが出来上がりますので、起動した後は（最初はおっかなびっくりでしょうから）当たり障りのないwebサイトで使うようなIDとパスワードを入れてみてください。

さて、今までC++とBCCSkeltonで作ったオリジナルのIDListを使ってきた私が、実際に（そのデータをUTF-8に変え）C#版のものを使ってみて感じたことを紹介しましょう。

オリジナルのC++版と移植したC#版の一番大きな違いはオリジナル版で使っていたDPAPIのダイアログ

が.NETベースでは使えなくなったことでしょうか？しかし、パスワード保護は使えなくともデータはDPAPIによる暗号化はなされていますので影響は非常に大きくはないでしょう。

二番目に挙げる違いは（矢張りDataGricView－BindingSource－Listの同期処理によるのか、）表示等実行スピードではC++のネイティブプログラムの方が勝るように感じられました。

【2021年－C++版】

（解説：よくよく見ると未選択の場合、メニューとツールバーボタンが殺されていますね。小技が細かい。）

しかしC#版は、逆にプログラムが64bitベースになり、プログラム構造が明確化され、可読性が高くなったことでプログラミング的には勝っているとも言えます。

【2026年－C#版】

私自身から言えば、矢張りEmbarcadero C++（32bit版ですが．．．）＋BCCForm and BCCSkeltonで作ったIDListを今も愛用しており、今後も（OSがゆるすかぎりは）使い続けるんじゃないかな（注）、と思いますが、

注：既に金融機関を中心として「ID、パスワード方式」から「パスキー方式」への移行が始まっているので、IDList自体の必要性は今後低くなってゆきますが．．．爆！

C#（Even with one of the version 5.0）+ DataGridView + BindingSource + List

での表型アプリの開発、

とても簡便で作りやすく、お勧め

というのが結論です。