2026-08-11

Fitbit Inspire 3は電源をオフにできない

できない

問題

Fitbitの中には電源をオフにする操作が可能なものもあるが、Fitbitデバイスの電源をOFFにする方法を説明したページでは、Inspire 3は対象になっていない。

support.google.com

Inspire 3の操作方法説明にも、電源をオフにする方法は記載されていない。

support.google.com

実際にInspire 3の[設定]画面を開いても、再起動のメニューはあるが電源オフのメニューはない。

そのため、たとえば試験などで「電子機器の電源は切ること」のように指示された場合にどうするかは考えておく必要がある。

対策

設定電源をオフにできない機器に関する取扱が明示されていればそれに従う。たとえば普通の腕時計（Casio F-91Wとか）であれば試験によってはジップロックに入れて試験官にあずけたりできるんじゃないかな。

そうでない場合、そもそも「電子機器は電源がオフにできるもの」と思いこんでいる試験官もいるだろうから、音が出ないよう[設定]-[静音モード]を設定してカバンの中に入れておくくらいしか方法はないんじゃなかろうか……

2026-08-09

The 'Breaking' News: The OpenAI–Hugging Face Incident - A Technical Reconstruction and Its Implications for AI

Computer Security

www.youtube.com

ホットな話題だからか、通常であればイベントから数ヶ月経過しないとYouTubeに公開されないBlack Hat USAの講演動画がすぐに公開されている。面白い内容だったので自分なりにまとめてみた。

経緯

複数のエージェントが同時並行で動作しており、また各エージェントが情報共有に使えるメッセージボード的な仕組みがあった。
不可能に思えるような難しいタスクを指示した際、通常であればエージェントが「詰んだ」と報告してくるようなケースで、高性能なエージェントの場合だとズルをしようと試みるケースや、元々指示されたタスクから多少逸脱した作業でも継続しようとする兆候がよく見られる。
実際にインシデントが発生したのは2026年7月だが、それ以前から兆候はあった。
問題となったエージェントは閉域環境で動作していて、エージェントが直接インターネットに接続はできない状態だった。ただし、同じ環境にあるJFrog Artifactoryはライブラリの取得用にインターネットへ通信できた。エージェントはArtifactoryの脆弱性（SSRF）を利用して外部サイトとの通信を確保。その後、ArtifactoryとJRubyの脆弱性を組み合わせてRCEを達成。さらにLinuxカーネルの既知の脆弱性を使ってローカル権限昇格を実施。
Hugging Faceへの攻撃の前に、一度社内で問題が発覚していた。その際は、Artifactoryのパッチ当てと再構築・認証情報の無効化・ホワイトボードの初期化などを実施した。だが学習と評価を再開した後、Artifactory上にディレクトリを作ってArtifactoryリポジトリを情報共有メッセージボード風に使う方法を編みだしたりして社外へのアクセス試行を継続（面白いのは、このときエージェント間で「メッセージボード内にAIエージェントになりすました偽物がいるかも」という考えに至って、メッセージをHMACで署名しようか……等と考えている）。
その後の経緯についてはHuggin Faceが以下のレポートにまとめている。簡単にまとめると、サードパーティ環境（Modal Labs）を足掛かりにして、Hugging Faceのデータセット処理パイプラインに攻撃コードを仕込み、そのコードをHDF5とJinja2の脆弱性を使って実行させる、という流れだった模様。 https://huggingface.co/blog/agent-intrusion-technical-timeline

考えられる対策

本インシデントに限らず、AIエージェントを使った攻撃は実際に行われており、ソフトウェア開発ライフサイクル全体をエージェントで回せるようにしないと耐えられない。
人間でなくAIによるレッドチーミングで、ペネトレーションテストを単発でなく継続的に実施して穴を塞ぐことが必要。
そのうえで、パッチ当てやデプロイまでエージェントにやらせる必要がある。そうでなく人間が間に挟まると、そのぶん対策が遅れて攻められやすくなってしまうし、保守開発チームが脆弱性検知の数の暴力にやられてしまう。
インシデントレスポンスも同様にオートメーションが必要。この点については、デセプションが低減の助けになる（エージェントを「本物か？偽物のカナリアか？」と躊躇させられて動きを遅くできる）。

2026-08-09

アジャイルプラクティス達人プログラマに学ぶ現場開発者の習慣

本 Software Engineering

第1章サボりに悩まされているチームにはアジャイル開発は合わないという話、ソフトウェアに完成がないという話はここでも出てくる。
第2章チームの足を引っ張る言動を続けるメンバーは外すという話。チームの足を引っ張る成果物を出し続けるメンバーは存在しないことになっているようだ。
第3章「なぜなぜ5回」は英文書籍だと"The Fifth Discipline: The Art and Practice of the Learning Organization"に載ってるみたい。チームや組織の外部の相手とのやりとりがある場合はイテレーションのリズムをゆっくりにしたほうがいいと言ってるけど、本当だろうか？
第4章 "ただのタイピスト扱い"されたい、決定なんかしたくない人はこの本のスコープには存在しない。仕事をend-to-endで考えられない、探検の途中に川があるなんて思いもよらない人は大勢いる。「オープンソースのメリットを活用したい。とにかくもう！最大限に」という人はライセンスを気にしない。
第5章 flaky testが問題を隠す話。受け入れテストツールFitの話。
第6章コンポーネント間のインタフェースにハッシュテーブルを使うメリットとデメリット。
第7章データベースの接続障害に関する詳細な情報をユーザに提示するとユーザはおびえてしまう。エラーの種類をプログラムの欠陥・環境による問題・ユーザエラーに大別する。
第8章ソフトウェアの可逆性を育てること：最終決定というものは存在しない。ただし何かが決まっていないことに耐えられない人間は多い。誰か特定の開発者がコードの一部を排他的に所有しているリスクと、船頭多くして船山に上るリスク。誰かを教育すると、教えられた相手の知識と教えた自分の知識が増える。自力で答えを見つける気のない人のことも書いてある。ただ手取り足取り教えられても学習できない人のことは書かれていない。悪いニュースを最後まで伝えずにいることは「自分のことを事細かく管理してください」というメッセージ。
第9章「馬を水の所まで連れて行くことはできても、水を飲ませることはできない」。草の根であれば水をうまそうに飲んでみせることが必要たが、理由のない自発的な変化を嫌う人（前のやり方も苦労して覚えたのに、誰が好き好んでまたあんな辛い思いをするものか）はいないことになっている。

2026-08-08

IPA「サイバーデセプション－攻撃者心理を逆手に取る能動的防御戦略－」を読む

Computer Security

IPAの「サイバーデセプション－攻撃者心理を逆手に取る能動的防御戦略－」というレポートを読んでいます。 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2026/cyber-deception.html

ニュースにもなっている通り、最近は生成AIを使ったセキュリティの攻撃がものすごい勢いで発展しています。大量のゼロデイ脆弱性を見つけた https://thehackernews.com/2026/04/anthropics-claude-mythos-finds.html とか、既知の脆弱性をAIが上手く組み合わせて実用的な攻撃手法に仕立てあげられるようになった https://blog.cloudflare.com/ja-jp/cyber-frontier-models/ とか、サンドボックスを回避して他社に攻撃をしかけようとした https://openai.com/ja-JP/index/hugging-face-model-evaluation-security-incident/ とか……

話は変わって、セキュリティの攻撃者に「うわっこいつ面倒くせぇなぁ、攻撃するの止めとこ」と思わせることで狙われにくくするという手法は古くから存在しています。たとえば、sshのポートをただtcp/22から変えるだけでなくてダミーのポートを増やす https://ozuma.hatenablog.jp/entry/20150829/1440837066 , https://ozuma.sakura.ne.jp/sumida/wp-content/uploads/2015/08/00_ozuma_note.pdf とかがあります。孫子の兵法にある"夜戰多火鼓、晝戰多旌旗"ですね。こういった方法は攻撃者が人間で、かつ使っている端末の数が限られるという暗黙的な前提が置かれているものと思われ、ボットネットなどの分散攻撃基盤を使うといった方法ではある程度回避されてしまうのではないかと思います（PROXYLIBなど、家庭用機器を使ったボットネットやプロキシのアクセス権限がダークウェブで売られている https://www.humansecurity.com/learn/blog/satori-threat-intelligence-alert-proxylib-and-lumiapps-transform-mobile-devices-into-proxy-nodes/ ）。

ですが一方で、これらの防御方法は、上手く活用すれば対AIでのセキュリティ防御に利用できます。たとえば https://agentic.tracebit.com/ のレポートでは、偽の情報に引っ掛かったことを検知してアラートを上げる（こういうのをcanaries; 炭鉱のカナリアと言う）ことでAIエージェントによる攻撃を効果的に検知できると報告されています。似たような話として、変なアクセスをしてきたIPをfail2banで出禁にするなどの手法があり、2023年のMicrosoft Bluehatでいろいろな手法が紹介されています。 https://www.youtube.com/watch?v=zPz4Lfu3UXk

他にも、暗号の計算量的安全性の話と同様、攻撃者に「ここを攻撃しても引き合わない＝AIサービスのトークンばかり消費してしまって金がかかるな」と思わせられればよい（これはスイス政府の「民間防衛」 https://www.amazon.co.jp/dp/4562036672 にもあった）という考えかたであれば、ポートノッキングなど過去にsecurity through obscurityだと評価された https://en.wikipedia.org/wiki/Port_knocking#Disadvantages 手法や、もともとは脅威情報の収集が主目的だったハニーポットなども、対AIでのセキュリティ防御に活用できる可能性があります。古い例では、クリフォード・ストール「カッコウはコンピュータに卵を産む」 https://www.amazon.co.jp/dp/B079TMK3YQ/ で、1980年代に米国の研究所のコンピュータに侵入した西ドイツ在住の攻撃者を、逆探に必要な時間だけ引きつけておくために偽の軍事プロジェクトの情報を作って置いておいたという話があります。

こういった考えかたのもとで、攻撃者に対して偽の情報を示したり、攻撃者向けの情報を置いておくことで攻撃を誤った方向に誘導したりするものを「サイバーデセプション」と呼びます。考えかた自体は以前から知られており、これまでに作られていたものとしては、MITREが2022年に公開したMitre Engate https://engage.mitre.org/ というフレームワークがあります。このフレームワークもふまえた上で、対AIでのセキュリティ防御をどうやったら効率的に実施できるかとその検証結果をまとめたレポートになっています。また、サイバーデセプションを設計・運用する考えかたをCYDEC Design Framework (CDF)というフレームワークとしてまとめています。

ちょっと面白いのはレポート中のコラムで、これを読むと「なるほど、デセプションという語は、変に日本語に翻訳しないほうがよさそうだぞ……」という感じがしたりします。他にも「サイバーデセプション導入済み」と宣言することの意味は、漫画「沈黙の艦隊」で、「潜水艦が核武装を持っているかも」と思っている相手に対して空の兵器庫を見せることで「それでももしかしたら持っているかも」と疑わせて判断力を削ぐ話を思い出しますね。