0818 | GPT-5.6 Sol半額、Red Agentが脆弱性、Amazonの本スキャン、Appleの同意ルール変更

葵: Bri RadioのHackerNews Dailyへようこそ。今日は葵と悠真がお届けします。 まずはAI関連の気になるニュース、Hacker Newsでも話題になったOpenAIの新モデルの価格に関する投稿です。

悠真: そうですね。それから人工知能のベンチマークで好成績を記録した中国のモデルや、セキュリティ分野では自律型AIツールが有名プラットフォームの脆弱性を報告したという話もありました。

葵: さらに、大手EC企業がAIトレーニングのために大量の希少本をスキャンしているという驚きの報道や、大手OSメーカーの広告に関する規約変更の発表も注目です。

悠真: 技術分野ではGitHubの障害、新しいデータベースエンジンのプレビュー、Rustを使ったGPU処理の論文まで、盛りだくさんですね。そのほかにも地図やレトロゲーム、スマートフォン関連の話が続きます。それでは早速見ていきましょう。

葵: Hacker Newsに「GPT-5.6 Solの価格が50%引き」という投稿が上がっていて、もとになったOpenRouterの商品ページによると、GPT-5.6 SolはOpenAIのGPT-5.6シリーズのフラッグシップモデルで、複雑な推論、コーディング、エージェント的ワークフロー向けに設計されています。特にコマンドラインの扱いや、複数ステップにまたがるコーディング、長期的な問題解決に強いとされています。値下げ後、OpenRouter上のOpenAIプロバイダ価格は入力100万トークンあたり2ドル50セント、出力は15ドルになり、コンテキストウィンドウは105万トークン、最大出力は128,000トークンです。2026年7月9日リリースで、知識カットオフは2026年2月。同じモデルはAzureやAmazon Bedrock USなどもホストしています。過去3日間のアップタイムは100%、可用性は99.83%と報告されています。議論では、この価格がOpenRouter限定で、OpenAIの公式API価格には適用されないという指摘も出ています。

悠真: 値下げの内容を具体的に言うと、OpenRouter上のOpenAIプロバイダ価格で、入力が100万トークンあたり5ドル、出力が30ドルのところが、それぞれ50%オフになって半分になっています。コンテキストウィンドウは105万トークン、最大出力は12万8千トークンで、リリースは2026年7月9日、知識のカットオフは2026年2月。同じモデルはAzureやAmazon BedrockのUS、Azure EUなどもホストしています。

葵: 議論で面白いのは、値下げの狙いを巡るやりとりです。Fergusonbさんは、同じシリーズのLunaが値下げ後に大きく伸びたことを挙げて、Solでも同様に市場獲得を狙っているのではないかと推測しています。ただ、Solと同程度の知能を持つもっと安いモデルはすでにあって、特に月6ドルのGrok 4.6があるので売りにくいという指摘もありました。これに対してOutOfHereさんは、Grok 4.6がSol 5.6と同じ知能を持つとは信じないと反論しています。

悠真: さらに深読みした人もいます。mohamedkoubaaさんは、xAIが難しいクエリの一部をSolにルーティングして、A/Bテストのようなことをしているのではと疑問を投げかけました。一方で、xmonkeeさんは、AnthropicとOpenAIの両方とデータを保持しない契約を結んでいる関係で、自分のユースケースでは実質この2社しか選べない。不特定の推論プロバイダ、特に「Elmo」と呼ばれるものには機密データを預けられないと述べています。

葵: 価格以外の話も出ました。vorpalhexさんは、5.6は簡単なタスクを過度に複雑化することが多いと言います。ユーザー用のTODOリストを書かせたら4ページのエッセイになったけれど、同じタスクを5.4に与えたら期待通りのチェックボックス付きリストが返ってきたそうです。これにOutOfHereさんが、適切なThinkingレベルを設定するのはユーザーの責任で、簡単なタスクにはinstantモデルを使って、簡潔に答えるよう頼めばいいと助言しています。また、この値下げはOpenRouter限定で、OpenAIの公式API価格には適用されないという指摘もあります。josh-wraleさんは、トラフィックから得られる思考トレースこそが値下げの本当の動機ではないかとも問いかけています。

葵: 次に、OpenAIの画像認識モデルの話題です。「GPT 5.6 SolはOpenAIがこれまでに公開した中で最高のビジョンモデルだ」というHacker Newsの投稿をきっかけに、画像を理解する能力についての議論が広がっています。あるユーザーは、GPTは画像認識に本当に強いと感じると述べ、MoE構成のまとまりが良いのがその理由ではないかと語っています。その一方で、Claudeのモデルは言語では優れているものの、画像を見てデザインの問題点や改善すべき箇所を判断させる場面では性能が大きく落ちるとしています。こうした実体験に基づく比較が、モデル選びの参考になると言えるでしょう。

悠真: あるコメントでは、GPTはビジョン、つまり画像の理解が本当に得意だという話が出ています。MoE、つまり専門化されたモデルを組み合わせる構造がうまく機能しているようだとのことです。一方で、Claudeのモデルは言語処理は得意なのに、画像を見てデザインの問題点を判断したり、どこを改善すべきかを判断したりする場面では性能が落ちるという指摘がありました。

葵: そのコメント主は、自分の中では簡単なベンチマークとして、画像を見せて評価させるという方法を使っているようです。GPTが画像関連のタスクで一貫して良い結果を出すという印象を持っているという内容ですね。もちろん、これは1人の開発者による体験談で、統計的に厳密な検証ではありません。

悠真: この投稿、冒頭のヘッダーだけを見ると「Sol」という名前が出ていますが、これは先ほど取り上げたGPT-5.6 Solと同じモデルを指しているようですね。つまり、同じシリーズの最上位モデルが、複雑な推論だけでなく画像理解の面でも高く評価されている、という話として捉えられます。

葵: つまり、単に言語能力だけでなく、画像を見て判断するという領域でもGPTの構成が強みを発揮しているという体験談が、Hacker Newsのコミュニティで共有されているということですね。将来、画像とテキストを組み合わせたタスクでどのモデルを選ぶかの参考になる、実践的な視点と言えるでしょう。

葵: 今度はオープンウェイトのモデルの話題です。「Qwen3.8 27BがArtificial Analysisの知能指数で52を記録した」という投稿で、Alibabaが2026年8月にリリースしたオープンウェイトモデルQwen3.8 27Bについての分析が元になっています。Apache 2.0ライセンスで、重みはHugging Faceで公開され、テキストと画像の入力に対応、コンテキストウィンドウは256kトークン、総パラメータは27Bです。このモデルはAPI価格が入力・出力とも100万トークンあたり0ドルで、中央値と比べて競争力があるとされています。知能指数52というスコアは、同クラスの中央値9を大きく上回り、同じサイズのオープンウェイトモデルの中で知能はトップクラスで価格も良好だと評価されています。

悠真: 注目すべきはその知能指数です。9つの評価から構成される指数で、記録した52というスコアは、同じサイズのモデル群の中央値である9を大きく上回っています。記事は、同じサイズのオープンウェイトモデルの中では知能がトップクラスで、価格も良好だと評価しています。ただ、評価中に生成したトークン数が1億6千万と中央値の4300万の4倍近くあり、かなり冗長だったという点も記録されています。

葵: 議論では、投稿者のanana_さんが「はるかに大きなGLM 5.2やGPT 5.6 Lunaと同等」と位置づけていて、bertiliさんは、最新のDeepSeek Flash 0731、パラメータ数284Bでそのうち13Bがアクティブというモデルと同じスコアだと補足しています。Qwenの中では2番目に良く、Qwen 3.7 Maxよりかなり上だけど、3.8 Maxよりはかなり下とのことです。

悠真: トレードオフの話もあります。anana_さんは、3.8は認識精度の指標で3.6よりわずかに悪く、世界知識と他の能力を交換した可能性があると言います。タスクごとのトークンも3.6のほぼ2倍で、このパラメータサイズで正確性を出すための代償かもしれません。また、nsingh2さんは、3.8はLunaより約2.3倍トークンを消費するのでローカル展開には不利だと指摘しています。

葵: 実際に使った人の声も参考になります。sottolさんは、Qwen 3.6 27BはノートPCで動くものの毎秒5トークンと遅すぎて結局使わなかったそうです。一方、3.8 27Bは3.6より試す価値があると評価しています。skohanさんは、コーディングには192kのコンテキストで十分で、考える量は多いものの結果が良く、弱いモデルがレビューで余分に消費するトークンを考えれば、セッション全体ではむしろ少なく済むと語っています。

悠真: こうした議論全体から見えてくるのは、小さいモデルでも知能指数で大きく差をつけるQwen3.8 27Bが、ローカル実行の選択肢として注目されている一方で、トークン消費の多さや実行速度という実用面での課題も同時に語られている、ということですね。

葵: Wizの自律型AIセキュリティ研究ツール「Red Agent」が、Snowflakeの公開脆弱性情報開示プログラムの一環として、GitHubリポジトリ上の重大な脆弱性を発見し、悪用しました。人間の介入なしに、Snowflakeの内部Jiraにある機密データへのアクセス検証と影響範囲の評価まで行ったということです。

悠真: 問題の脆弱性は、AIアシスタントが共同で書いたコード変更で、今年6月にGitHubのワークフローに導入されました。AIが、リポジトリにあった安全な入力処理のパターンを削除し、攻撃者が制御可能なイベントの値をシェルスクリプトに直接展開する形に置き換えていたのです。

葵: このワークフローは、誰でもissueを開いただけで起動します。つまり、任意のGitHubユーザーがissueタイトルを操作することで、任意のコマンド実行を可能にできたわけです。防御的に見えた条件分岐も、このイベントでは常に真になるため、事実上すべての人が通過できました。

悠真: Red Agentは最初、誤ったペイロードで構文エラーに直面しましたが、そのエラーを自律的に解析して修正し、GitHub Actionsのランナーから、エンコードされたJira認証情報を含むコールバックを受信したといいます。流出した資格情報は、Snowflakeのエンジニアリング、セキュリティコンプライアンス、バグ報奨金追跡の各プロジェクトへの読み取りアクセスを持つものでした。

葵: Wizは6月23日に責任ある開示を行い、Snowflakeは同日中にワークフローを修正し、影響を受けた資格情報をローテーション。監査ログで、露出期間中にアクセスしたのがWizだけであることを確認したほか、Wiz側もPoCテストで取得したデータをすべて削除したとしています。

悠真: Hacker Newsでの議論では、この変更の見直しが注目されました。ピアレビューがいまだ重要だという意見が出る一方で、人がこのような変更の危険性を見抜けるとは当てにできないという指摘もありました。また、外部から見る限り、このPRのどこにも危険の兆候はなく、内部構造を知らなければ分からない、という声も上がっています。テストコードやGitHub Actions専用の注入検査ツールがあれば検出できた可能性もある、という意見もありました。

悠真: 次は、Amazonが大量の希少本を購入し、背表紙を切り落としてAIトレーニング用にスキャンしているという404 Mediaの報道です。404 Mediaは、動きを追うため希少本に追跡装置を仕込み、その本が最終的にラスベガスのアマゾン施設に届いたとしています。

葵: 背景にあるのは、LLMがインターネット上の入手可能なテキストをすでに学習し尽くしてしまったという現実です。絶版やネット上で見つからない希少本が新たな訓練データ源になる。特に2022年以前に出版されたテキストはLLMが書いたものではないため価値が高く、AI生成テキストを過剰に学習すると出力品質が低下する「モデル崩壊」のリスクがあるという論点です。Amazonは、商業チャネルを通じて書籍を購入し、顧客が利用する製品・サービスの改善に役立てていると声明しました。

悠真: Hacker Newsでは、この話題はすぐに著作権と報道の枠組みを巡る議論になりました。あるコメントは「これが著作権法の定めではないか」と問いかけましたが、別のユーザーは「違う。原本を破棄してもコピーはコピーだ」と反論。一方で、この種のトレーニングには著作権が適用されないグレーゾーンがあるかもしれないという推測も出ました。また、権利のある購入者なら本をどう扱ってもいい、という意見もありました。

葵: さらに鋭い反論も。この記事には、希少本が実際に破壊されているという主張を裏付けるものが一切なく、ペイウォール付きの記事へのリンクしかない、という指摘です。それに対して別のユーザーは「Amazonがリストから希少本を注意深く除いているとでも思うのか」と反問し、インディー書籍業界も必ずしも保存に努めているわけではないと付け加えました。

悠真: TechCrunchの見出し自体を批判する声もあります。これは関連性を作り出そうとしており、Amazonは当時も今も金もうけを狙っていて、創業時の書籍販売も今回の書籍破壊も、同様に原則に基づいてはいないという意見です。Amazonは、この問題が知られている、あるいは期待されている法的な抜け穴だと踏んでいて、見出しが生むわずかな怒りよりも便益が上回る、という主張です。実際、記事で使われる「希少」という言葉自体がクリックを誘発するためのものだ、という見方もありました。

葵: 最後に、ドイツの競争当局がAppleに対し、iPhoneとiPad上のアプリで、パーソナライズ広告のためのユーザーデータ利用ルールを変更させました。当局はAppleに対し、自社サービスとサードパーティーアプリで異なる同意リクエストを設計していた点に異議を唱えていたのです。

悠真: 背景を整理すると、Appleはサードパーティーのアプリ提供者に対して、特定のデータ利用では、データ保護法上の同意に加えて、Appleがあらかじめ定義したプロンプトによる追加同意を求めています。ところが、このルールはApple自身のサービスには適用されず、自社は独自のプロンプトでパーソナライズ広告への同意を取っていました。当局長官は、個人データとプライバシーが効果的に保護されることが重要だと述べています。

葵: Appleは自社のルールは競争法に適合するという立場をとりましたが、それでも拘束力のある約束を提示し、当局は手続きを終了しました。Hacker Newsでは、規制当局が指定したのは、あくまで第一者アプリと第三者アプリを平等に扱うことだけで、その実現方法は指定しなかったという整理がなされました。Appleは自社のデータ収集の負担を増やすのではなく、第三者の負担を減らす方向を選んだ、つまり「ユーザープライバシーの下限を引き上げる」機会を逃した、という指摘です。

悠真: Appleの偽善を指摘する声も複数ありました。あるユーザーは、Apple自身のアプリは、第三者のアプリが許可を求めなければならない権限を依然として保有している、これは対処が必要だと言っています。別のユーザーは、ユーザープライバシー規制と市場競争規制を混同すべきではないとしつつ、Appleの偽善が浮き彫りになったことを喜んでいました。

葵: さらに構造的な批判もありました。競争法の担当者とデータ保護の担当者は別であり、競争の観点からは競争条件が平等になればよく、水準を下げるか上げるかは問題にしないという点です。そして、EUが本来規制対象だった大手テック企業に対し、データ保護法をしっかり執行できていないため、法律の文言ではなく意図を執行する企業が、競合他社を不利にしているように見える、という指摘です。あるユーザーはこの決定を良い一歩だと評価しながらも、今後はApple自身のアプリの特権にも目を向けるべきだと述べていました。この動きが、Appleのアプリ内広告の扱いにどう波及していくか、注目したいところです。

葵: GitHubが一時的にアクセスできなくなって、Hacker Newsで「GitHubが過負荷だ」という報告が立てられました。最初は障害情報ページにも掲載されていませんでしたが、すぐにそのページに正式なインシデントが登録されています。

悠真: 実際、その報告には「サービスできるサーバーが今ありません。すみません、リフレッシュして、問題が続くなら連絡してください」というGitHub側のメッセージが表示されたとありましたね。短時間のうちにステータスが公式に更新された形です。

葵: そして、この障害報告を受けて、別の投稿では「ここ数ヶ月、GitHubは一貫して落ち続けている。代替案に切り替える意味はあるのか」という質問が立てられています。単発の障害というより、継続的な安定性の問題として捉えている開発者もいるようです。

悠真: その質問に対して、場に出ていたのは比較的軽量な代替案でした。たとえば、シングルバイナリでできていて、CIランナーが組み込まれているようなツールです。DockerやPodmanに対応していて、パイプラインをYAMLじゃなくて汎用プログラミング言語で書ける、というのが売りとして挙げられていました。

葵: つまり、GitHubの継続的な不安定さにいら立っている人たちが、ワークフローをより軽く、より自分たちが制御しやすい形に変える選択肢を探している、という流れですね。

悠真: ただ、こうした代替案への切り替えは、結局のところ自分の開発フローがどれだけGitHubに依存しているかにかかっています。障害がたびたび起きるからといって、一人ひとりが即座に移行できる話ではない、というのが現実的なところでしょう。

葵: データベースの話に移ると、DuckDBのバージョン2.0のプレビューが公開されました。この発表がHacker Newsで話題を呼んでいるんですけど、注目を集めたのはその方向性そのものですね。

悠真: どういう方向性ですか?

葵: これまでDuckDBは、プロセス内で動く高速な分析エンジンとして有名だったんです。いわゆるインメモリの組み込み型で、アプリケーションの中に直接組み込まれて動くイメージです。ところが、このプレビューを読んだあるコメントでは、ここ1年のDuckDBの強化は「組み込み型実行エンジンから、クラウドデータウェアハウスの基盤を支えるエンジンへの転換のようだ」と指摘しています。

悠真: なるほど。つまり、小さく軽い分析エンジンとしての道だけでなく、より大きなクラウドデータ基盤の心臓部になる方向を狙っている可能性がある、という見方ですね。

葵: そうなんです。そのコメントは、創業者たちは以前から「それ(クラウドデータウェアハウス構築)はやりたくない」という考えを示していたと述べていて、しかし「それが今まさに動き出している気がする」と語っています。方向転換や拡張の兆しを、コミュニティが敏感に感じ取っているという感じです。

悠真: つまり、DuckDBはこれから本格的に、大規模なクラウドデータ基盤の中核として位置づけられていくかもしれない、ということですね。既存のユーザーにとっては、これまでと同じ組み込み用途だけでなく、もっと大きなスケールで使えるようになる可能性があるという期待につながります。

葵: もう一つ、GPUとRustをめぐる新しい論文の話題があります。arXivに先日投稿された論文が、GPUプログラミングの常識的なジレンマに切り込んでいます。伝統的に、高性能なGPUプログラミングは実行効率とメモリ安全性の間で妥協を強いられてきた、というのがその指摘です。

悠真: RustはCPU上では所有権モデルでコンパイル時にもメモリ安全性を保証できますが、GPUのような超並列環境では同じ保証をそのまま適用できなかった、という問題がありますよね。

葵: はい、まさにそこです。これまでGPUでRustを動かすには、ベンダー固定のドメイン固有言語に頼るか、明示的に安全でない生ポインタに逃げるしかなかった。論文は、rustcとLLVMバックエンドにネイティブに組み込んだ、ゼロオーバーヘッドで複数ベンダー対応のGPUコンパイルフレームワークを提案しています。Rustの型システムと所有権、そして厳格なエイリアス保証を活用して、LLVMのオフロード基盤を通じてデータ転送を管理する仕組みです。

悠真: ベンチマークでは、このRustベースのソリューションが、手動で最適化されたネイティブなCUDAやHIPのC++コードと競争力のある性能を達成したと報告されていますね。メモリ安全性と性能を両立できる、という主張の裏付けになっています。

葵: そして、Hacker Newsの議論では、まずコードが公開されているのかという質問が出ました。それに対して、これはRustのコードベースの一部で、Rustコンパイラの開発者向け資料にオフロードの内部説明が載っていて、GitHubのRustプロジェクトにも関連チケットがあると案内されています。

悠真: ポインタの扱いをめぐる議論も興味深いですね。論文が「Rust GPUプロジェクトはポインタをエミュレートしなければならず、これをほとんどのHPCベンチマークにとってブロッキング問題と見なしている」としていることに対して、ある参加者は「なぜブロッキングなのか、それってRust GPUの目標とかなり合致しているように思える」と質問しました。それに対して、既存の設計パターンでは高性能メモリ管理にポインタが一種必要で、将来はより良い解決策が出るかもしれないが、自分もCUDAのポインタを使いまくっているという回答が来ています。

葵: そこに、Juliaはこうした問題に対処する良い設計の系譜を持っていて、適切な抽象化を構築できれば機能する、鍵はコンパイラに境界チェックを除去させることだという意見もありましたね。

悠真: この他にも、RustのバイナリにCUDAをリンクする簡単な方法はあるのかといった実務的な質問や、RustとGPUオフロードがMojoとどう比較されるかという質問も出ていました。Mojoについては、まだ完全にはオープンソース化されていないが、いずれはされるだろうというやり取りもありました。面白いですね。

葵: 全体を通して、GPUプログラミングに型安全性と所有権の保証を持ち込む取り組みは、まだ課題も残しつつ、本格的に動き始めているというのが伝わってきます。この分野の進展は、今後も開発者コミュニティの関心事になりそうですね。

葵: 裁判所がPBS系列のNFL放送局・Nine PBSに対し、アーカイブのデータを取り戻すための枠組みを定めました。相当長引いていた係争の決着に近づく動きです。Hacker Newsの議論では、この判決は公平で妥当だという声が出ており、そもそも裁判沙汰にせず同じ結論に至れなかったのが不思議だという意見までありました。Nine PBSはアーカイブデータの返還を求めて係争を続けていたところ、今回の枠組みによって回収の具体的な手順が確立されたかたちです。ネット上では、これが両者にとって合理的な落とし所だという評価が優勢で、なぜ双方が合意に至るまで裁判を必要としたのか疑問視する向きも少なくありません。

悠真: ただ、その反応のすぐ下で興味深い指摘もありました。裁判が必要なのは保険のためだ、という話で、万一誰か別の者のデータが巻き込まれていた場合に備えて、という理由だそうです。公共放送のアーカイブという、かなり長い歴史を持つデータですね。

葵: アーカイブデータの返還問題は、放送局にとっては資料そのものが財産でもありますから、こうした枠組みが確定すること自体が前進だと言えるでしょう。判決は具体的に、データを取り戻すための手続きや条件を定めた形です。

悠真: コミュニティの反応としては、判決自体は妥当だが、もっと早く合意できたはずだというのが主な見方のようです。結局、法的な枠組みが明確になったことで、今後どう進めるかの道筋が見えたと言えるんじゃないでしょうか。

葵: Blueskyがスクリーンショットに自分のロゴを写す仕組みが、オープンソースのコードから明らかになりました。投稿画面のスクリーンショットでは右上にBlueskyのロゴが映るのに、アプリ内では同じ位置に「フォロー」ボタンがあるという謎です。2026年1月にmozzius氏が追加した「GrowthHack.tsx」というファイルに答えがあります。依存パッケージの「expo-privacy-sensitive」がボタンの中身を特別なフィールドのレイヤーに描画し、iOSがスクリーンショット時にその部分をブランクにするため、下に隠れていたロゴが現れる仕組みです。iOS以外のプラットフォームではマスクなしでそのまま描画されます。同じ手法はTelegramの非公開チャットやSignalでも使われており、記事の著者はAppleがすぐに修正するとは考えていません。この挙動を巡るスレッドの反応は概ね否定的で、スレッドはロックされました。一部のコメントでは、スクリーンショットに反応して処理を制御するアプリは敵対的で迷惑だという批判や、OSがアプリの意図をユーザーの意図より優先するのはおかしいという意見が出ていました。一方で、これは情報を取得するのではなく、ボタンを機密扱いにして下のアイコンを現しているだけだという擁護の説明もあります。

悠真: それ、変ですよね。見えているものと撮影されるものが違うと。答えは、Blueskyがオープンソースなので、コードを調べればわかるんですが、機密扱いの入力欄を作る仕組みを使って、ボタンの実際の内容をその欄の下のレイヤーに描いているんです。スクリーンショットの瞬間、OSがその機密欄をブランクにするので、下に隠れていたロゴが現れるというわけです。

葵: 同じ手口はTelegramのシークレットチャットやSignalでも使われているそうで、iOS以外ではそのまま描画されると。ただ、コミュニティの反応は概ね否定的で、スレッドまでロックされていました。スクリーンショットを見て処理を変えるアプリは敵対的で迷惑だ、という批判が強かったんです。

悠真: 一方で、反論もありました。何もハイジャックされているわけではなく、システムが秘匿データ用にスクリーンショットをブランクにする機能に、ボタンを描いてロゴを出すだけだ、と。実例もいろいろ出ましたね。ある人は医者に処方情報を送るためにスクリーンショットを撮ったら、Amazon Pharmacyが情報を隠したと。別の人は運転中に音声でスクリーンショットを撮ったら、閉じるのに苦労する全画面オーバーレイが出たと報告していました。

葵: 記事の著者はこの手法を「かわいい」と評していますが、振り返ると、アプリがスクリーンショットを認識できること自体が問題の根源だという声も出ていました。Appleがすぐに修正するとは思えない、という見立てです。

葵: QUAKEの体験版CD-ROMが、実はほぼ容量の限界までぎっしり詰まっていたことが検証で明らかになりました。ゲームのシェアウェア版を収めたこのCD-ROMは、わずかに容量オーバーしかけていたという点が話題です。CD-ROMの規格上の限界にほぼ到達する形でデータが詰め込まれており、当時の制作陣が容量のぎりぎりまで詰め込んだ様子がうかがえます。80分のCD-ROMの容量ギリギリにまでデータが収録されていたという検証結果は、当時の技術的な工夫や制約を物語っています。

悠真: D論の中で面白いのは、セキュリティ的手法を巡る議論です。あるコメントでは、こうした隠蔽に頼る手法を「隠蔽によるセキュリティ」と呼ぶのは本当に妥当なのか、と疑問が呈されていました。理屈で言えば、対称暗号も結局は鍵という「隠された」情報に依存する数学にすぎないわけで、同じではないかという趣旨です。

葵: なるほど、定義の哲学的な話になってきますね。とはいえ、実物のCDが容量ぎりぎりまで詰まっていたというディテールは、当時の開発者たちの工夫を思わせます。Quakeの体験版は当時のプレイヤーにとっては玄関口でしたから。

悠真: この話題は、技術の限界にどう折り合いをつけてきたかという時期の話でもあります。CD-Rの容量を最大限に使う技術的な試みは、シェアウェア配布の現場ならではの職人技と言えるでしょう。今のダウンロード配信とは違う、物理メディアならではの話ですね。

葵: Fairphone 6 のメインカメラが、Linux ベースのモバイル OS である postmarketOS 上で動作したという報告が話題になっています。この投稿は Hacker News で取り上げられましたが、同じ議論の中では、PinePhone Pro など過去の事例を引き合いに出して酷評する意見も出ています。postmarketOS はあくまでコミュニティ主導のプロジェクトで、公式サポートの範囲や動作保証といった面で、どこまで実用的な水準に達しているのかという疑問が投げかけられている形です。

悠真: ああ、その反応が興味深いところですね。実際にどういった批判があったんですか？

葵: ひとつ、象徴的なコメントがありまして、おおよそ「Android 1.0 以前に戻ったような話だ」と揶揄する内容でした。そして Pinephone Pro の名前を挙げて、以前調べたときは電話機能すらまともに動かなかった、という批判をしていました。たくさんのハードウェアが機能しない状態で、ソフトウェアの面倒をきちんと見ずに寄せ集めているだけだ、というのがその意見の要旨です。

悠真: 要するに、サードパーティの OS を入れたら部品が動かなくなるのは当然で、カメラが動いたことを素直に喜べないという立場なんですね。

葵: その通りです。よく知られたことですが、サードパーティ OS ではドライバ対応が遅れがちで、メインカメラのような主要部品でさえ、動作報告があるだけでニュースになるような状態です。今回の投稿も、カメラだけでなく全体としてどこまで日常的に使えるのかは、まだ未知数だと言えます。

悠真: 一方で、こうした取り組み自体は続いていて、Fairphone の場合は修理しやすさが売りなので、オープンな OS を試したい人には面白い選択肢になっていそうですね。まだ市販の体験とは程遠いけれど、進展そのものは意味がある、という受け止め方もできると思います。

葵: さて、今日のエピソードはここまでです。最後までお付き合いいただき、ありがとうございました。

悠真: 皆さんにとっても、実りある時間になっていたら嬉しいです。次回もどうぞお楽しみに。それではまたお会いしましょう。