1011 | 週間テックダイジェスト:AIの責任からUPF食品まで

葵: こんにちは、葵です。

悠真: 悠真です。今日もこの番組、いつもの形式で、ここ一日の記事とその議論を深掘りしていきます。

葵: 今日のラインナップは、AIに「決定」をさせるときの責任の話から始まって、セルフホストのAIエージェント、オープンソースとライセンスの話、unikernelsとI/Oの再設計、住宅と制度、健康と科学、セキュリティの事故、そして実験的なハードウェアやちょっとした余話まで。

悠真: 一見バラバラに見えますけど、通して読むと「誰が判断して、誰が責任を取るのか」「開示と信頼をどう担保するのか」という筋が一本通ってるんですよね。それでは早速、最初の話題からいきましょう。

葵: はい。まずは「プログラムは意思決定をしない」という、かなり強い主張から。投稿者の言い分は、LLMに判断をさせた結果を「AIが決めた」と片付けるのは、決定の責任をうやむやにする一種の「責任の穴埋め」だ、というものでした。

悠真: 言い換えると、決定の主体は常に人であって、モデルやソフトウェアはその補助装置にすぎない、と。会場ではここが一番盛り上がったんじゃないかという議論でした。

葵: 賛成側の立場からすると、LLMの出力は確率的な文章生成であって、責任を負える実体がそこにいない。だから出荷判断、診断、採用、融資みたいな場面で「AIが判断しました」は、実のところ「人がAIの出力を根拠に決めました」を言い換えて責任を薄めているだけだ、という理屈です。

悠真: つまり「AIのせい」は現代の言い訳の形式になっている、と。一方で反対意見もあって、現場の実務家っぽい立場からは「とはいえ組織の中でAIの出力が事実上の決定になっている実態はある。フロントの担当者はほぼ出力に従っているし、形式的なサインだけが人の意思決定になっている」という指摘でした。

葵: ここが一番面白い対立点ですよね。責任の形式的人間と実質的な機械、どちらを「決定の主体」とみなすか。形式で切るなら、ログを残してレビューを義務化するのが筋だけど、実態で切るなら、AIを使う工程そのものの手順と権限を再設計しないと責任の所在は直らない、という話に発展していました。

悠真: で、ここに技術的な補強が入るんですよ。「LLMを決定モデルとして設計する」話。これは、モデルが出力するトークンの選択肢を絞って、事実上の決定候補だけを生ませる手法で、Jevというものはこれをやっていると説明されていました。出力はキャリブレーションされた形式になる、と。

葵: つまり「AIが自由に判断する」のではなく「決定空間を先に設計して、その中でモデルが選ぶ」構造にする。これは「プログラムは決定しない」派から見ても、決定がどこにあるかが可視化されるので、むしろ責任の設計と相性がいい、という読みをしている人がいました。

悠真: 一方で皮肉っぽい反応もあって、「選択肢を絞ったからって、絞った側の責任が消えるわけではない。むしろ選択肢の集合そのものが誰かの判断で、そこが一番大事な決定だ」と。確かに、選択肢の集合を設計する人間が実は最大の意思決定者なんだと。

葵: そこで話が繋がるのが、NvidiaがReflection AIという、オープンなモデルを作るスタートアップを買収交渉中だという報道でした。Reflection AIはオープンなモデルを手がける会社で、買収が実現すれば、AIの決定の連鎖、つまりどのモデルが、誰の条件で、どんな選択肢を提示するのかを、一つの巨大企業が上流から握ることになりかねない、という懸念が読み手側から出ていました。

悠真: 垂直統合の懸念ですね。ハードウェアからモデル、デプロイまで一社で完結すると、そのスタックの中で「どんな判断がどう促されるか」を外部から検証しにくくなる。さっきの「決定の責任は人にある」という主張と重ねると、問題はさらに難しくなるんですよ。責任を負うべき人間はどこにいて、どんな選択肢を与えられているのか、がブラックボックス化するから。

葵: 未知の点としては、そもそも買収が成立するかどうか。交渉中という段階の報道なので、成約するか、規制当局がどう見るか、まだ分かりません。そして成約したとして、Reflection AIのオープンモデル路線が続くのか、それとも閉じるのか。そこも読み手の間で意見が割れていたところです。

悠真: 「オープンに続けば良い、閉じればNvidiaのエコシステムがさらに強まる」という単純な二分ではなく、「オープンでも資本構造が単一企業に寄ると、いずれ何かが変わる」という慎重派もいました。まあここは予想の域を出ませんね。

葵: さて、ここから一歩、人ではなくて、人が自分で持つAIの話に移ります。Talorysというプロジェクトが投稿されていました。

悠真: これは、Cloudflareのアカウントに対して、一つのコマンドで展開できる個人用のAIエージェントです。特徴としては、MITライセンス、テレメトリなし、そしてセルフホスト、つまり自分のインフラ上で動かせる、という三点が強調されていました。

葵: 先ほどの「責任の所在」の話とつなげると、この手のセルフホスト型エージェントは「エージェントの判断ログが自分の手元に残る」構造を作る一つの方向性だ、という受け取り方をしていました。データが外部サービスに流れないので、監査も自分でできる、と。

悠真: ただ、この投稿、実装の詳細がまだ不明なんですよね。アーキテLatchそのものの技術的な仕組み、たとえばエージェントがどこまで自律的に動くのか、どんなツールを呼べるのか、という部分が公開されている情報だけでは見えない。そこを読み手は指摘していました。

葵: 「ワンコマンドで入るのは魅力的だけど、中身が見えないと、責任の設計として本当に正しいのか評価できない」という声。さっきの議論と綺麗に連続していますよね。「決定の主体は人」なら、人がレビューできる状態にしておくことが必須条件で、その条件をこのプロジェクトが満たしているかどうかは、まだ確認できない、と。

悠真: そういう意味で、この投稿は楽しみでありながら少し慎重な受け止め方をしている人が多かった印象です。MITライセンスとテレメトリなしだけでなく、コードの中身まで確認できるようになって初めて、本当にセルフホストの価値がある、と。

葵: さて、次はその「コードの中身が見えるかどうか」をめぐる、二つの対照的なニュースです。一つはWallHopというプロジェクト。もう一つはBitwardenの発表。

悠真: まずWallHop。これは12ft.ioの代替として、ladderというGPL-3.0のプロジェクトをフォークしたものです。特徴は無料、登録不要、という二点。ここまでは良いのですが、問題は「現時点でソースが公開されていない」ということ。

葵: ここが読み手の間で一番揉めた点ですね。ladderがGPL-3.0でライセンスされている以上、それをフォークしたものを配布するなら、ライセンス上はソースコードを提供する義務が生じるという指摘。つまり「まだ公開していない」というのは、単なる未完了ではなく、法的な問題を含んでいる可能性がある、と。

悠真: 一方で擁護派の立場からは「開発中のプロジェクトが徐々に公開していくのは普通のことでは」という意見もあったんですが、それに対して「GPLの配布と未公開開発は別の話で、すでにバイナリやサービスとして提供しているなら話が違う」という反論が返ってきていました。

葵: ここで対比として出てくるのがBitwardenの話です。Bitwardenは、アプリストアで配布しているアプリを商用ライセンスのビルドにする方針を発表しました。ただし、GPLv3のバージョンはGitHubに残し続ける、というのです。

悠真: これは面白い。つまり「ストアで出す版」と「GitHubに置く版」をライセンスの上で分ける、という形。どちらもソースは見られるのですが、使えるライセンスが違う。ストア版は商用ライセンス、GitHub版はGPLv3、と。

葵: 読み手の間では「これは許容できる妥協か、それともオープンソースの精神に反するか」で意見が割れました。ある立場からは「ストアの配布要件に対応するための現実的な選択で、GPLv3版が生き続けている限り、自由は守られている」という擁護。別の立場からは「利用者がストア版を使う限り、実質的に商用ビルドを使うことになり、GPLが保証する自由が形骸化する」という批判。

悠真: WallHopとの共通点を指摘する人もいました。どちらも「開示と利用の自由」が焦点なんですが、WallHopは「まだ開示していない」ことで問題が生じているのに対し、Bitwardenは「開示はしているが、実用に供される版のライセンスが変わっている」。どちらも「見られる」と「自由に使える」が一致していない事例だ、と。

葵: 今後の注目点は、WallHopがソースを公開するかどうか。GPLのフォークとして正しく処理されるのか、それとも問題が長引くのか。ここはまだ解決していないので、追いかける価値のある話です。

悠真: さて、次はもっと低いレイヤー、ソフトウェアの在り方そのものを問い直す話に移ります。二つの記事で構成されています。

葵: 一つ目は、Ghuntleyによる「unikernelsが再評価される」という考察。主張は、AIがセットアップの摩擦を取り除くことで、unikernelsが実用的になる、というものです。

悠真: ちょっと前提を説明すると、unikernelというのは、特定のアプリケーションだけを実行するように、オペレーティングシステムを極限まで削ぎ落とした形のもの。一般的なLinuxのように汎用的な機能を全部持つのではなく、そのアプリに必要な最小限だけを含む。

葵: Ghuntleyの論点は二つありました。一つは、攻撃面が減ること。不要な機能がないので、そこを突く攻撃も成立しにくい。もう一つは、汎用のOSは技術的負債である、という主張。今のサーバーの多くは、必要のない機能も抱え込んでいて、それがセキュリティや保守のコストを生んでいる、と。

悠真: で、AIがこの隙間に入る、というわけです。今までunikernelが広まらなかった理由の一つに、セットアップやデバッグの難しさがありました。普通のエンジニアには馴染みがなく、ツールチェーンも整っていない。でもAIが、その環境の構築やトラブルシュートを助けられるようになると、この障壁が下がる、というわけです。

葵: 会場の反応としては、考察としては共感できるという人が多かったのですが、実運用の広がりについては慎重でした。「理論的には正しいが、エコシステム、デバッグツール、監視、デプロイのパイプラインが揃わないと本番では使えない」という声。「プロトタイプでは使いやすいが、運用は別物」という経験談もありました。

悠真: 実装側の観点から、これに対応するように「I/Oの再設計」の話が入ってきます。DuckDB 2.0の非同期I/Oの話です。

葵: これは技術的に面白い話で、DuckDB 2.0では、専用のダウンロードグループがデータの取得を進めながら、他のグループが並行してデコードを続ける、という構造になっているんです。

悠真: 具体的な効果としては、S3からの処理が18.8秒から7.7秒に短縮されたと報告されています。倍以上の改善ですね。

葵: これはunikernelsの話と結構通じるものがあるんですよ。どちらも「ソフトウェアはどうあるべきか」を問い直していて、既存の設計が「当たり前」として積み重ねてきた前提を、一度ゼロから見直している。

悠真: 一方はOSの粒度、もう一方はI/Oの非同期性。表層は違うのですが、本質的な問いは「本当に必要なものは何で、それ以外は捨てられないか」という点で共通しています、という指摘が読み手の間にありました。

葵: 未知の点としては、やはりunikernelの実運用が広がるかどうか。DuckDBの非同期I/Oの方は実測で数字が出ているので、これはすでに現実なのですが、unikernelの方は、まだ考察の段階。AIによる摩擦の低減がどの程度の実効性を持つか、今後を見る必要があります。

悠真: ここから一気に社会側の話題に移ります。住宅と制度の攻防。二つの記事です。

葵: 一つはDiscretionary Reviewというシミュレータ。これは、サンフランシスコの住宅申請を、実際の公聴会として再現するものです。各物件は実際の争点に基づいていて、法律と判例は公的記録に基づいています。

悠真: つまり、単なるシミュレーションではなくて、プレイヤーが実際の争点に直面する構造。この物件の高さはどうする、日影の影響はどう見る、近隣住民の異議はどう扱う、といった判断を実際の法体系の中で行う。

葵: 読み手の間では、これを「教育ツールとして優れている」と評価する声が多くありました。住宅問題というのは、抽象的な議論になりがちなんですが、個別の申請を通して考えると、判断が具体的になる、と。

悠真: そして、この背後にある制度的な背景として、もう一つの記事が参照されていました。米国の税制改革が、不動産所有者の負担を下げ、商業物件に転嫁し、結果として住宅コストを上げている、という分析です。

葵: ここが面白いところで、個別の物件レベルの攻防と、税制というマクロの制度設計とが、別々の記事でありながら、同じ問題を指している、と。つまり、住宅コストが上がる原因は、個別の申請の難しさだけでなく、制度全体がどう構成されているかにもある。

悠真: 読み手の間では「Discretionary Reviewをやると、個別の判断の複雑さがわかる。でも税制の記事を読むと、個別の判断の外側にある構造がわかる。両方見ないと全体像は掴めない」という意見がありました。

葵: 具体的な税制の話に少し踏み込むと、税制改革により、不動産所有者の税負担が減り、その分が商業用物件に移されている。商業物件の負担が増えると、そのコストが最終的にどこかに転嫁されるわけで、それが住宅に影響している、という流れです。

悠真: この分析が正しいかどうかは、読み手の間で完全には合意されていませんでした。税制の影響は複数の経路で働くので、単純に「住宅コストが上がった原因はこれだ」と言い切れるかどうか、慎重な見方もありました。

葵: いずれにせよ、個別の争いの背後に制度がある、というこの二つの記事の共通点は、住宅問題を考える上で重要な視点だと多くの人が感じていたようです。

悠真: さて、次は健康と科学の進展。二つの研究・プロジェクトの話です。

葵: まず、Virginia Techの研究。これは、UPF、つまり超加工食品を使った食事と、そうでない食事を比べたもので、重要なのは、栄養成分を一致させた上で比較しているという点です。

悠真: これが実験設計のポイントですね。単に「加工食品は体に悪い」と言うとき、栄養の違い、塩分、脂肪、糖、それらの影響を切り離すのが難しい。栄養をそろえた上で比較すると、加工そのものが体に与える影響が見えてくる。

葵: 結果としては、代謝と脳の反応が異なった、と。つまり、同じ栄養でも、加工の状態によって体の反応が変わる可能性を示唆しています。

悠真: ただ、読み手の間では「実験設計の詳細と長期効果はまだ不明」という点が指摘されていました。代謝や脳の反応が違うことと、それが健康にどう影響するかは別の問題です。短期の代謝反応の違いが、長期的な疾病リスクにつながるかどうかは、まだ分からない、と。

葵: 次は健康技術側の話。PopVaxが、広域COVIDワクチンPVX-001のフェーズI投与を完了したという報告です。

悠真: このワクチンの特徴は二つ。一つは広域性、つまり特定の変異株だけでなく、より広い範囲の変異に対応できる可能性。もう一つは、2〜8℃で安定していること。

葵: 2〜8℃での安定性は、実用上とても重要です。多くのmRNAワクチンは超低温での保存が必要で、配送インフラが大きな課題でした。冷蔵で済むなら、供給の障壁が下がる。

悠真: そして、このプロジェクトのもう一つの特徴が、完了後にオープンソース化する予定だという点。ワクチンの設計情報が公開されることになる。

葵: これは前半のオープンソースの議論と繋がりますね。BitwardenやWallHopの話で「開示と利用の自由」を論じましたが、こちらはライフサイエンス分野でのオープン化。分野は違うのに、同じ問い、つまり「情報をどう開示し、誰が利用できるようにするか」が出てくる。

悠真: 読み手の間では、ワクチンのオープンソース化そのものには好意的な反応が多かったのですが、ワクチンという生体医薬品の場合、特許や規制の問題が絡むので、実際に「オープン」にするときに何が公開され、何が制限されるのか、という点が注目されていました。

葵: さて、ここから話題を変えて、セキュリティ事故と記録の話に移ります。

悠真: デンマークCPRの大規模データ漏えいの話。これは、パスワードが『123456』だったということが原因として報じられています。

葵: これには読み手も言葉を失ったようで、「本当にこれなのか」という反応がまずありました。国の重要な個人情報システムで、これほど単純な認証が使われていたというのは、常識の枠を超えている、と。

悠真: 事実として報じられているのは、パスワードが『123456』であった、ということ。ただ、この一句だけでは、なぜそのような状態になっていたのか、どのような経路で漏えいにつながったのか、全体像は分かりません。読み手の間でも、技術的な経路については憶測の域を出ないという指摘がありました。

葵: ただ、教訓としては明確で、単純な認証管理の危険性を示す事例だということ。どんなに大きなシステムでも、基本の認証の部分が弱ければ全体が崩れる、と。

悠真: ここで対比としてもう一つ、軽い話ですが、macOSの認証の話が出てきました。

葵: これは、macOSが事実上UNIX 03認証を維持しているのに、The Open Groupの登録一覧に見えない、という話。ただ、よく調べると、これはサイトのレンダリングの不具合の可能性が高い、というのです。

悠真: つまり、登録が実際にないのか、単に表示が壊れているだけなのかを、ちゃんと確認しないと「macOSがUNIX認証を失った」という誤解が広まってしまう、と。

葵: さっきのCPRの話と連続していますね。どちらも「記録と確認の重要性」というテーマで、CPRの方は「基本的な認証の確認を怠った結果」という話で、macOSの方は「記録の表示を鵜呑みにせず確認する」という話。どちらも「ちゃんと確かめたか」が核心にある。

悠真: さて、次はちょっとした余話ですが、細部の検証文化というテーマを締めくくるのにちょうどいい話です。

葵: Knuthが著書の誤り報告に対して、これまでは本物の小切手を送っていたという話です。ただ、現在は、本物の小切手ではなく、サン・セリフ銀行の架空の証明書を送っている、と。

悠真: サン・セリフ銀行というのは、架空の銀行ですね。つまり、換金できない証明書を送ることで、誤りを報告した人の功績を認める、という形。

葵: これはKnuthのユーモアでもあるんですが、一方で「なぜ本物の小切手から架空の証明書に変わったのか」については、読み手の間でも、その経緯が完全には伝わっていないという指摘がありました。

悠真: ただ、この話の面白さは、細部の誤りを丹念に集め、それを公式に認めるという文化を、ユーモアとともに続けている、という点にあります。エラーを報告する人がいること、それを発行者がきちんと認めること。これが信頼できる記録の土台だ、というわけです。

葵: さて、最後の一つ、実験的なハードウェアの話です。

悠真: Lightbulb Computerというプロジェクト。これは、球状のハウジングにプロジェクタとコンピュータビジョンを組み合わせた実験機です。

葵: 形としては、電球のような形の中に、プロジェクタがあって、そこが映すものをコンピュータビジョンが読み取る、という構造。デモは実際に動いている、と。ただ、かさばる、という指摘もあります。

悠真: 読み手の間では、これを「面白いプロトタイプ」として評価する声が多かったのですが、同時に「この形の実用性はどこにあるのか」という疑問もありました。

葵: プロジェクタとコンピュータビジョンを一体にした構造は、空間的なインタラクションの新しい形を示唆していますが、球状のハウジングが大きいと、設置や日常利用の障壁になる。今後の小型化が注目点です。

悠真: さて、今日はここまで。いろいろな話題が出ましたが、通して見ると「誰が判断して、誰が責任を取るのか」「開示と信頼をどう担保するのか」という筋が、意識的にしているわけでもないのに繋がっていたと思います。

葵: そうですね。AIに決定させようとするとき、その責任は人にあるという話から始まって、セルフホストで自分の手元に置く、ソースを開示する、unikoernelで不要なものを捨てる、住宅の背後の制度を見る、健康研究では設計を精査する、セキュリティでは記録を確認する。どれも「確認して、判断して、責任を負う」という行為の形をしています。

悠真: 明日以降も、こうした話を続けていきます。今日はこの辺で。ご視聴ありがとうございました。

葵: ありがとうございました。