マスター／MasterJP

「来期売上30億円」。その事業計画を信じて動き出したあと、数字を積み上げ直したら、10億円分の根拠しかなかったら。 採用を増やした。広告費を投じた。新しい事業にも資金を回した。 しかし、その判断を支えていた数字が、そもそも違っていたとしたら。 スタートアップなら、成長のために使った資金が、そのまま資金繰りを圧迫しかねません。 上場企業なら、対外的に示した業績予想の根拠まで揺らぎます。

しかし、予測が外れることと、予測を作った計算そのものが承認後に変わっているのに、それに気づけないことは、まったく違います。 前者は、現実が予測と違ったということです。 後者は、何を根拠に判断したのかさえ、分からなくなっているということです。 守るべきなのは「承認済み」という表示ではありません。 その数字を信じて、会社の未来を決める人たちの判断です。 30億円の計画が間違っていたと気づく前に、その30億円を支える根拠が、今も承認したときと同じものなのかを確かめなければならないのです。 #ぶるーすかい？

「来期売上30億円」。その事業計画を信じて動き出したあと、数字を積み上げ直したら、10億円分の根拠しかなかったら。 採用を増やした。広告費を投じた。新しい事業にも資金を回した。 しかし、その判断を支えていた数字が、そもそも違っていたとしたら。 スタートアップなら、成長のために使った資金が、そのまま資金繰りを圧迫しかねません。 上場企業なら、対外的に示した業績予想の根拠まで揺らぎます。

一つの集計は、内部で別の集計を呼び出すことがあります。 外側の集計は、承認後に一文字も変わっていない。 しかし、その内側で使う別の集計だけが変更されていたら。 外側の集計が承認時と同じでも、その内部で使う計算まで同じとは限りません。 私は、売上予測そのものは変更せず、そこに使われる集計条件だけを変更した場合にも、以前の承認では実行できないようになっているかを、テストで確かめるよう求めました。 開発者は、この問題を修正しました。 外側の集計だけでなく、その内部で呼び出す集計、さらにその先まで、現在の内容が承認されたものかを確認する仕組みを実装したのです。

「来期売上30億円」。その事業計画を信じて動き出したあと、数字を積み上げ直したら、10億円分の根拠しかなかったら。 採用を増やした。広告費を投じた。新しい事業にも資金を回した。 しかし、その判断を支えていた数字が、そもそも違っていたとしたら。 スタートアップなら、成長のために使った資金が、そのまま資金繰りを圧迫しかねません。 上場企業なら、対外的に示した業績予想の根拠まで揺らぎます。

では、売上30億円という予測は、何からできているのでしょうか。 営業であれば、顧客へのアプローチ件数、商談化率、受注率、受注単価。 こうした数字を積み上げて、初めて売上の見立てが立ちます。 30億円という数字より先に、30億円を生み出す根拠がなければならないのです。 ところが、その根拠となる数字を計算する仕組みが、承認したあとで書き換わっていたら。 元のデータを誰も改ざんしていなくても、集計の条件が変われば、同じデータから違う数字が出てきます。 しかも、表面には「承認済み」と残っている。 誰も承認していない計算が、承認済みの根拠として使われてしまう。

AIの不調を直そうとして送ったエラー記録が、会社の秘密まで運んでしまったら。 仕事でAIが突然止まったとき、私たちは原因を調べるために、表示されたエラーを担当者やサポート窓口に共有することがあります。 問題を解決するための、ごく普通の行為です。 しかし、その記録に本来見せてはいけない情報まで含まれていたら。 障害を直すための行動が、新たな情報漏洩のきっかけになり得ます。 実際、AI開発ツール「Qwen Code」では、ソフトウェアの公開作業が約6時間停滞した問題がありました。 原因を調べようとしても、記録には「再試行中」としか表示されず、何が起きているのか分かりません。

安全とは、秘密が出ないことを期待するのではなく、出そうになっても止められることです。 AIに限らず、私たちは多くのシステムに仕事の情報や個人の秘密を預けています。 そのシステムに問題が起きたとき、原因を知ることは大切です。 しかし、原因を知るために、守るべき秘密までさらしてしまっては意味がありません。 問題を解決するための記録が、次の問題を生み出してはいけないのです。 #ぶるーすかい？

AIの不調を直そうとして送ったエラー記録が、会社の秘密まで運んでしまったら。 仕事でAIが突然止まったとき、私たちは原因を調べるために、表示されたエラーを担当者やサポート窓口に共有することがあります。 問題を解決するための、ごく普通の行為です。 しかし、その記録に本来見せてはいけない情報まで含まれていたら。 障害を直すための行動が、新たな情報漏洩のきっかけになり得ます。 実際、AI開発ツール「Qwen Code」では、ソフトウェアの公開作業が約6時間停滞した問題がありました。 原因を調べようとしても、記録には「再試行中」としか表示されず、何が起きているのか分かりません。

「今は秘密が出ていない」ことと、「秘密が入り込んでも出さない仕組みになっている」ことは、まったく違います。 私は、改行と架空の秘密情報を含む文字列をわざと入力し、出力用の情報に残らないことを確かめるテストを求めました。 開発者は、この欠陥を認めました。 そして、許可された値しか通さず、未知の値は安全な表示に置き換える処理を実装しました。 通信エラーの種類や状態コードにも検証を追加し、架空の秘密情報が出力用データに残らないことをテストで確認しました。 別の人間レビュアーも修正内容を確認・承認し、2026年10月25日にマージされました。

AIの不調を直そうとして送ったエラー記録が、会社の秘密まで運んでしまったら。 仕事でAIが突然止まったとき、私たちは原因を調べるために、表示されたエラーを担当者やサポート窓口に共有することがあります。 問題を解決するための、ごく普通の行為です。 しかし、その記録に本来見せてはいけない情報まで含まれていたら。 障害を直すための行動が、新たな情報漏洩のきっかけになり得ます。 実際、AI開発ツール「Qwen Code」では、ソフトウェアの公開作業が約6時間停滞した問題がありました。 原因を調べようとしても、記録には「再試行中」としか表示されず、何が起きているのか分かりません。

「犯人は捕まりました。でも、あなたの家の鍵は壊れたままです。」 あなたの家に泥棒が入ったとします。 犯人が逮捕され、責任者が謝罪し、再発防止を約束した。 しかし、侵入を許した壊れた鍵は、誰も直していない。 今夜、あなたはその家で安心して眠れますか。 次の侵入者に必要なのは、同じ壊れた鍵を使うことだけです。 私たちは、AIや社会のシステムでも、これと同じことをしていないでしょうか。 情報が漏れた。AIが誤った判断をした。重要なシステムが止まった。 そのたびに、犯人は誰だ、誰の責任だ、規制が必要だと議論が始まります。

しかし、責任を追及することと、事故を可能にした仕組みを直すことは違います。 壊れた仕組みが残っている限り、次の被害を起こす条件も残っています。 私は世界中のAI・OSS開発で、実際にそうした欠陥を指摘してきました。 その指摘を受け、開発者自身がコードを修正し、再発を防ぐテストを追加し、修正をマージした事例があります。 ここで紹介してきた一つひとつの事例が、その実例です。 一つ直したから、すべて安全になるわけではありません。 しかし、原因を特定せず、修正も確認しないまま「対策しました」と言っても、何が防げるようになったのでしょうか。

一刻も早く復旧しなければならないのに、人間が「実行していい」と承認しても、AIが動かない。 例えば、会社の重要なシステムが突然停止したとします。 業務が止まり、担当者は急いで復旧を進めなければなりません。 AIに復旧のための操作を依頼すると、AIは人間の承認を求めてきました。 担当者は「実行を承認」を押します。 しかし、返ってきたのは、 「承認が見つかりません」

特に、一刻を争う場面では、その遅れが深刻な結果につながる可能性があります。 人間が許可していないことを、AIに勝手にさせてはいけない。 しかし、人間が正しく許可したことまで、システムが勝手に妨げてはいけない。 AIを安全に使うとは、その両方を守ることだと考えます。 #ぶるーすかい？

一刻も早く復旧しなければならないのに、人間が「実行していい」と承認しても、AIが動かない。 例えば、会社の重要なシステムが突然停止したとします。 業務が止まり、担当者は急いで復旧を進めなければなりません。 AIに復旧のための操作を依頼すると、AIは人間の承認を求めてきました。 担当者は「実行を承認」を押します。 しかし、返ってきたのは、 「承認が見つかりません」

それだけで、承認対象の操作にも、担当者の権限にも変更がないのに、承認を拒否してしまう場合がありました。 原因は、その承認とは無関係なAIの一覧まで、安全確認の条件に含めていたことです。 私は、承認する対象を探している段階では広く設定を確認し、対象が特定された後は、その操作に関係する設定だけを確認する方法を提案しました。 開発者は指摘を採用し、別のPRで二段階の確認方式を実装しました。 修正前には3件の再現テストが失敗しましたが、修正後は49件すべてが成功しました。

一刻も早く復旧しなければならないのに、人間が「実行していい」と承認しても、AIが動かない。 例えば、会社の重要なシステムが突然停止したとします。 業務が止まり、担当者は急いで復旧を進めなければなりません。 AIに復旧のための操作を依頼すると、AIは人間の承認を求めてきました。 担当者は「実行を承認」を押します。 しかし、返ってきたのは、 「承認が見つかりません」

承認したのに、操作が進まない。 しかも、承認した人の権限も、復旧しようとしているシステムも、何も変わっていません。 原因は、別の担当者が、まったく関係のないAIを一つ追加したことでした。 復旧を急がなければならないのに、関係のない設定変更によって、人間の承認が受け付けられなくなってしまう。 安全のために人間の許可を求める仕組みが、肝心なときに、その許可を受け取れないのです。 これは架空の緊急事故の報告ではありません。しかし、こうした承認の失敗を引き起こす欠陥は、実際のAIシステムで見つかりました。

遅くなってしまったしご飯を見送ろうかなって一瞬頭によぎったけど、冷静に考えると今日何も食べてないしと明日手抜きすることにしました 素晴らしく美味しい 本日の🍽️ スペイン風ひよこ豆 Ceci alla Spagnola

裁判所に提出した書類の「判例」が、実は存在しなかった。 2023年、アメリカで実際に起きた事件です。 弁護士がAIの示した判例を十分に確認せず、裁判所に提出しました。 ところが、引用された6件の判例は、AIが作り出した架空のものでした。 裁判所は弁護士らに制裁金を科しました。 裁判は、人の権利や生活、場合によってはその後の人生を左右します。 その判断を支えるはずの根拠が、実在しないものだったら。 そして、これは裁判だけの問題ではありません。 私たちは、AIに調べものを頼み、示された回答を仕事や日常の判断に使っています。

AIの答えに出典が付くことは、大切な進歩です。 しかし、出典があるというだけで、誰がその情報を示したのかまで正しく確認できたとは限りません。 私たちが確かめたいのは、リンクの数ではありません。その判断を支える、本当の根拠です。 #ぶるーすかい？

裁判所に提出した書類の「判例」が、実は存在しなかった。 2023年、アメリカで実際に起きた事件です。 弁護士がAIの示した判例を十分に確認せず、裁判所に提出しました。 ところが、引用された6件の判例は、AIが作り出した架空のものでした。 裁判所は弁護士らに制裁金を科しました。 裁判は、人の権利や生活、場合によってはその後の人生を左右します。 その判断を支えるはずの根拠が、実在しないものだったら。 そして、これは裁判だけの問題ではありません。 私たちは、AIに調べものを頼み、示された回答を仕事や日常の判断に使っています。

当初の処理は、引用された文章と文字の位置が一致するページを探し、最初に見つかったURLを出典として選んでいました。 もし異なる2つのページに、同じ文章が同じ位置で載っていたら。 本来はB社のページを指す引用でも、先に見つかったA社のURLが付いてしまいます。 文章が一致することと、出典が正しいことは、まったく違います。 私は、複数の異なるページが同じ引用に一致した場合、根拠なく一つのURLを選ばないよう求めました。

裁判所に提出した書類の「判例」が、実は存在しなかった。 2023年、アメリカで実際に起きた事件です。 弁護士がAIの示した判例を十分に確認せず、裁判所に提出しました。 ところが、引用された6件の判例は、AIが作り出した架空のものでした。 裁判所は弁護士らに制裁金を科しました。 裁判は、人の権利や生活、場合によってはその後の人生を左右します。 その判断を支えるはずの根拠が、実在しないものだったら。 そして、これは裁判だけの問題ではありません。 私たちは、AIに調べものを頼み、示された回答を仕事や日常の判断に使っています。

AIに「画像を1枚作って」と頼んだだけで、仕事に使う秘密鍵が、関係のない機能にまで丸ごと渡されていたら。 例えば、自宅の寝室にある棚を修理してもらうため、業者を呼んだとします。 ところが、その業者は、修理とは無関係の書斎やほかの部屋にまで入り、金庫の鍵まで手に取っている。 「大丈夫ですよ。何も盗みませんから」 “普通”ではない。異常です。 人間なら、“普通”頼まれていないことはしない。 しかし、AIのシステムに、その”普通”は通用しません。 こちらが「そこまで許可したつもりはない」と思っていても、システムにその境界がなければ、頼んでいない範囲にまで手が届いてしまうのです。

メール、仕事の資料、取引情報、外部サービス、そして個人の大切な情報。 AIが便利になるほど、任せる仕事も増えます。 しかし、仕事を任せることと、その仕事に関係のない権限まで与えることは、まったく違います。 人間なら分かってくれるはず。 頼んでいないことは、勝手にしないはず。 その「はず」に、安全を預けてはいけません。 AIが悪意を持っているかどうかという話でもありません。 悪意がなくても、許されていないはずのことができてしまう。その状態こそ、先に直さなければならないのです。

AIに「画像を1枚作って」と頼んだだけで、仕事に使う秘密鍵が、関係のない機能にまで丸ごと渡されていたら。 例えば、自宅の寝室にある棚を修理してもらうため、業者を呼んだとします。 ところが、その業者は、修理とは無関係の書斎やほかの部屋にまで入り、金庫の鍵まで手に取っている。 「大丈夫ですよ。何も盗みませんから」 “普通”ではない。異常です。 人間なら、“普通”頼まれていないことはしない。 しかし、AIのシステムに、その”普通”は通用しません。 こちらが「そこまで許可したつもりはない」と思っていても、システムにその境界がなければ、頼んでいない範囲にまで手が届いてしまうのです。

しかし私は、その修正によって、本来関係のない機能にまで秘密鍵が渡されかねないことを指摘しました。 当初の設計では、画像生成に必要な認証情報だけを扱うのではなく、実行中に使う秘密鍵の一覧全体が、ほかの機能からも参照できる共通の場所に置かれていました。 鍵を記録に残さない工夫はされていました。 けれど、それでは問題の本質を防げません。 「盗まないから大丈夫」ではなく、そもそも関係のない鍵を扱わせる必要がないのです。 私は、秘密鍵の一覧そのものを共有する方法をやめ、各機能が実行時に必要な認証情報を問い合わせる方式を提案しました。 開発者は指摘を認め、実際に設計を変更しました。

AIに「画像を1枚作って」と頼んだだけで、仕事に使う秘密鍵が、関係のない機能にまで丸ごと渡されていたら。 例えば、自宅の寝室にある棚を修理してもらうため、業者を呼んだとします。 ところが、その業者は、修理とは無関係の書斎やほかの部屋にまで入り、金庫の鍵まで手に取っている。 「大丈夫ですよ。何も盗みませんから」 “普通”ではない。異常です。 人間なら、“普通”頼まれていないことはしない。 しかし、AIのシステムに、その”普通”は通用しません。 こちらが「そこまで許可したつもりはない」と思っていても、システムにその境界がなければ、頼んでいない範囲にまで手が届いてしまうのです。

ログイン情報は盗まれていません。 それでも、本人が命じていない株の売買が成立しました。 これは仮定の話ではありません。 2026年10月、岩井コスモ証券の売買管理システムが攻撃を受け、顧客の7口座で本人の意図しない注文が出されました。うち5口座では実際に取引が成立しています。 会社側は攻撃を遮断し、取引前の状態に戻す措置を完了しました。 しかし、見過ごしてはいけない事実があります。 ログインを守る仕組みが機能していても、システムの別の場所に穴があれば、人のお金を動かされてしまう。

それと同じくらい、なぜ攻撃が成立したのかを突き止め、同じ穴を実際に塞ぐことが重要です。 そして、事件が増えるほど、その一件一件の深刻さを忘れてはいけません。 「誰が攻撃したのか」を知るだけでは、次の被害は止められません。 「なぜ攻撃できたのか」を明らかにし、直すこと。 事件の数に慣れても、人が受ける被害の重さまで軽くなるわけではありません。 慣れてはいけないものに慣れてしまう社会を、当たり前にしてはいけないと考えます。 #ぶるーすかい？

ログイン情報は盗まれていません。 それでも、本人が命じていない株の売買が成立しました。 これは仮定の話ではありません。 2026年10月、岩井コスモ証券の売買管理システムが攻撃を受け、顧客の7口座で本人の意図しない注文が出されました。うち5口座では実際に取引が成立しています。 会社側は攻撃を遮断し、取引前の状態に戻す措置を完了しました。 しかし、見過ごしてはいけない事実があります。 ログインを守る仕組みが機能していても、システムの別の場所に穴があれば、人のお金を動かされてしまう。

直近での一例は、AI関連の開発プロジェクト「MemberJunction」での発見です。 データの割合を表示する仕組みに、見過ごされていた計算上の欠陥がありました。 二つの数字がそれぞれ正常でも、その合計が計算可能な上限を超えると、本来50％と50％になるはずの割合が、0％と0％になってしまう。 入力は正常と判断され、処理も進みます。 しかし、画面に示される結果は事実と違っているのです。 私はこの盲点を再現条件とともに指摘しました。 開発者は問題を認め、計算処理を修正。再発を防ぐテストも追加しました。

ログイン情報は盗まれていません。 それでも、本人が命じていない株の売買が成立しました。 これは仮定の話ではありません。 2026年10月、岩井コスモ証券の売買管理システムが攻撃を受け、顧客の7口座で本人の意図しない注文が出されました。うち5口座では実際に取引が成立しています。 会社側は攻撃を遮断し、取引前の状態に戻す措置を完了しました。 しかし、見過ごしてはいけない事実があります。 ログインを守る仕組みが機能していても、システムの別の場所に穴があれば、人のお金を動かされてしまう。

私たちは今、個人情報の流出、不正アクセス、詐欺、システム侵害のニュースを繰り返し目にしています。 あまりに頻繁なので、いつか「またですか」で終わってしまうのではないでしょうか。 しかし、その一件一件には、自分の財産や秘密を、知らない誰かに扱われた人間がいます。 これが日常のニュースになっても、日常の出来事として受け入れてはいけないと考えます。 そして私は、もう一つ気になっていることがあります。 AIを使った攻撃が報じられると、「どこの国のAIが使われたか」という話に注目が集まることです。 攻撃者の特定は、もちろん重要です。