  |
はてなキーワード:タイムゾーンとは
いろんな方向にAIを扇動する人たちが頑張ってるけど、より成果の主張しにくい方向性はこういう事例が増えていくんだろうなと思ってる。
コード生成とか文書要約とかはまだ成果の主張しやすい方向だけど、動画生成は成果を主張しにくい方向性の最も顕著な例の一つだよな。
だから、これからも投資をする価値があると思ってもらうためにコンテンツの模倣をリリース当初は放置した。
まぁ、現実的な問題としては連絡のとりやすい自国のコンテンツ管理者とは事前協議してたけどタイムゾーンの違う他国は後回し、という事なんだろうね。
他社の新製品リリース時の比較は邪魔する癖に自分たちの新製品リリース時には邪魔した他社の最新モデルとの比較をやってくるような卑怯な競合他社との争いで不利になるから、全世界のコンテンツ権利者とチンタラ交渉してる余裕なんかないわけだ。
宣伝にもなり、早めに対処すればダメージは最低限に緩和できるって感じなんだろう。
バブル気味のAI界隈の中でも既に明暗がくっきり別れ始めてるの面白いね。
おっ、ナカーマ
Freestlye Libre 使いのテック系患者仲間としてもう一つ面白い情報を投げておくぜ。
Libreでデータ取得するやろ？
さらにLibeview と言うWebアプリでレポートが落とせるよな。
だけどあれ、2週間程度のデータしか分析できないじゃん？ また、学術的にまだ試験中だけど色々なリスクを分析する計算法が提唱されているんだけど、ここでは見ることができない。
そこで、CSV生データを落としてきたら、以下のサイトをつかってみて
https://glyculator.btm.umed.pl/
無料で利用できる。また、内部ではPythonが動いていて、そのコードもGitHubにあるので、自分で環境を作ることも可能。
これを使うと、TIR,CV,推定A1Cなどの他に、血糖値の乱高下度を表す値や、より厳格な計算値、提唱されているリスク指数なども計算させることができる。
近年、人工知能（AI）技術は目覚ましい進化を遂げ、さまざまな分野で革新的なサービスや製品が登場している。とりわけ、自然言語処理や画像認識といった分野では、数年前には考えられなかったような精度と速度が実現され、ビジネスや研究開発に欠かせない存在となった。しかしながら、その一方で「AI」の看板を掲げていても、性能面で期待を大きく裏切る製品も少なくない。そうした中で、最近話題にのぼる中国製AI「DeepSeek」については、「使えたもんじゃない」という厳しい評価を下さざるを得ないと感じている。
まず問題となるのは、その性能の低さだ。AIが人間の作業を支援する上で最も重要なのは「正確な情報を素早く提示する」ことだが、DeepSeekはこの点で大きく劣っている。例えば、自然言語処理を用いた文書解析や要約機能を試してみても、肝心な部分の抽出が弱いため、内容の重複や不要情報が目立つケースが多かった。こちらが求める回答とはズレた情報が混在しており、結局、手動で整理し直さなければならない事態が頻繁に発生するのだ。これでは、AIによる効率化よりも、むしろ余計な手間がかかってしまう。
さらに、精度の低さだけでなく、処理スピードにも問題がある。大容量のデータや複数のタスクを同時に扱うAIとして期待していたのだが、DeepSeekの場合、サーバーの負荷や回線状況によって処理が明らかに遅延することが散見される。大量のデータを扱う現場や、リアルタイムの応答が求められるシステムに組み込むのはリスキーだと言わざるを得ない。AIによって業務を効率化するはずが、待ち時間のストレスが大きくなるようでは本末転倒である。
また、サポート体制の不十分さも見逃せない点だ。海外のAIツールを導入する際には、使用言語の問題やタイムゾーンの違いから、どうしても問い合わせやアップデートの対応が遅れることがある。しかしDeepSeekに関しては、それを差し引いてもサポートが不安定であり、技術的なトラブルに遭遇しても解決までに多くの時間と手間を要する。問い合わせに対する回答が曖昧なまま放置されてしまったり、更新版を導入しても修正が不完全だったりと、ユーザー側のストレスは増すばかりだ。導入後の運用を考えると、明確なサポートが受けられないツールを使うのはリスクが高い。
データセキュリティの面でも懸念材料がある。AIツールを利用する際には、多かれ少なかれ機密情報や個人情報を扱う可能性がある。これらの情報が外部サーバーに送信され、どのように保管・処理されるかは非常に重要だ。DeepSeekでは、プライバシーポリシーやデータ取扱いの詳細説明が不十分であり、さらにユーザーコミュニティでもセキュリティに関する不安の声が多く上がっている。いかに優れた機能をうたっていても、根本的な安全性の保証が得られない製品を業務に導入するのはリスクが大きいと言わざるを得ない。
もちろん、中国製だからすべてが悪いというわけではない。実際、中国のIT・AI分野には世界でも注目される革新的な技術が多く存在し、優れた製品やサービスを提供する企業も多い。しかし、DeepSeekに関しては、肝心のAI技術自体の成熟度が低く、安定性や信頼性に欠ける部分があまりにも目立つ。このような状況では「使えたもんじゃない」と評されても仕方がないだろう。
総じて、DeepSeekはビジネス現場や研究開発の現場で頼れるパートナーとなるには程遠い。その性能の低さ、処理速度の遅さ、サポート体制やデータセキュリティへの不安要素など、導入の際に考慮しなければならないマイナス点が多すぎる。たとえ導入コストが他のAIツールより安価だったとしても、後々のトラブル対策や、AIが正常に稼働しなかった場合の損失を考えると、逆に高くつく可能性があることを否定できない。
今後、DeepSeekがアップデートや改良を重ねて飛躍的に性能を向上させる可能性がゼロとは言い切れない。しかし、現時点での完成度に限って言えば、非常に厳しい評価をせざるを得ない。「中国製AI、DeepSeekは使えたもんじゃない」という言葉を、ただの誹謗ではなく、事実にもとづく警告として受け止めるべきではないだろうか。もし本格的に導入を検討している企業や研究機関があるならば、慎重に比較検討を行い、テスト導入などを十分に行う必要があるだろう。
AIがビジネスや研究の現場で日常的に活用されるようになったいま、選択肢は豊富にある。性能やサポート、セキュリティ面で優れたAIを選ぶことが、結果的にはコスト削減にもつながるし、企業や組織の生産性の向上にも寄与する。時間と資金を費やして導入した結果、「使い物にならなかった」という事態を招くのは避けたいものだ。DeepSeekについては、導入メリットとリスクをしっかり検討したうえで、よほどの理由がない限りは慎重な姿勢を貫くことを強くおすすめする。
| 時刻 | 2024年のサラリーマン | 美味しんぼ山岡士郎 |
|---|---|---|
| 6:00 | 朝活で起床。スマートウォッチで睡眠の質をチェック | 起床。食材店の開店時間に合わせて動き出す |
| 6:30 | 朝活仲間とオンラインミーティング。1本満足バーで朝食 | 市場で本日の特選食材を物色 |
| 7:00 | 子供のお弁当作り。インスタ映えを意識 | 出勤前に立ち寄った店で朝食の品評 |
| 7:30 | 出勤準備 | 東西新聞社へ出勤 |
| 8:00 | マスク着用で満員電車。スマホで電子書籍 | デスクで競馬新聞をチェック |
| 8:30 | 通勤継続 | 栗田に今日の「究極の取材」について説明 |
| 9:00 | UKタイムゾーンの社員からのメンション確認 | デスクで競馬の電話投票 |
| 10:00 | オンラインミーティング | 突如「取材」と称して店舗訪問 |
| 11:00 | 各種作業 | 栗田と食材の買い出しへ |
| 12:00 | ミーティング | 老舗料亭で「取材」という名目の試食 |
| 13:00 | 一時退社して子供の送迎 | デスクに戻り、優雅に昼寝 |
| 14:00 | 在宅でオンラインミーティング | 栗田に起こされ、究極のメニュー開発の打ち合わせ |
| 15:00 | 再度出社 | 編集長に呼び出され、締め切り厳守を言い渡される |
| 15:00-21:00 | 断続的なミーティングとタスク処理 | 「取材」と称して街の名店を巡る |
| 17:00 | 作業継続 | 競馬の結果を確認しながら原稿作成 |
| 18:00 | 作業継続 | 栗田と究極のメニューについて議論 |
| 19:00 | 作業継続 | 偶然、銀座で海原雄山と遭遇 |
| 21:00 | 作業終了、帰宅準備 | 雄山との料理対決開始 |
| 22:00 | 帰宅。配達サービスで夕食 | 雄山との料理対決で惨敗。雄山に「まだまだだな」と言われる |
| 23:00 | 緊急トラブル発生。リリース作業開始 | 追い打ちをかけるように栗田から原稿催促の電話 |
| 24:00 | 上長から早朝ミーティングの通知 | 自宅で雄山への対抗メニューを考える |
| 25:00 | 就寝。アラームを早めに設定 | 敗北を悔しがりながら就寝 |
| 項目 | 2024年のサラリーマン | 美味しんぼ山岡士郎 |
|---|---|---|
| 時間の使い方 | 複数タスクを同時進行。効率重視 | 食と賭博の探求に没頭。締切ギリギリ |
| 食事 | 簡便性重視。食事時間の短縮化 | 食事そのものが仕事であり趣味 |
| 通勤 | デジタルデバイスに没頭。在宅勤務併用 | 競馬新聞とにらめっこ |
| 仕事スタイル | オンラインコミュニケーション中心 | 栗田を巻き込んで食の探求を優先。賭博も欠かさない |
| 生活の優先順位 | 自己啓発や効率性を重視 | 食の探求と完璧主義、そして競馬を最優先 |
ある記事が注目されているので、カナダ（バンクーバー）で働くソフトウェア開発者として、私が目にしてきた実情を、カナダ（バンクーバー）およびカナダドルに絞って話す。
仕事面：
生活面：
はてブの通知には、バグがある。その原因がわかったので、告知する。
この画像の通知で、次の差が生じる。
・ １番目のリンクをクリックしても、反応しない。（リンク切れ）
同じブコメへのリンクなのに、１番目ではエラーが生じており、３番目では正常である。
こういうことは、しばしばある。（通知のリンク切れが発生する状況）
──
では、どうしてこういうエラーが発生するのか？
それはリンクを調べるとわかった。１番目と３番目は、それぞれリンクが違っている。
https://b.hatena.ne.jp/blueboy/20230225#bookmark-4732833807750143236
https://b.hatena.ne.jp/blueboy/20230224#bookmark-4732833807750143236
見ればわかるように、 # の直前の数字が違っている。これは日付を意味する数字だが、１番目は虚偽の数字であり、３番目は正常な数字である。
つまり、リンクの数字を取得するときに、日付を間違えて取得しているわけだ。そして、間違えたリンクのページは存在しないから、リンク切れになってしまうわけだ。
いかにも、はてなの技術水準の低さがわかる。こんなバグは、ずっと前から気づいた人が多かったはずだが、誰も直そうとしなかったわけだ。「はてな？」と首をひねるだけの注意力がなかったんだね。
リンクの取得のときにエラーが起こるだけでなく、リンクの設定の時点でエラーが起こっているように思える。なぜなら、スターの通知があるのに、実際にはスターが設置されていないからだ。スターボタンを押した人はいても、スターは付いていないわけだ。（これもバグ）
──
ご指摘いただきました不具合につきまして、修正が完了いたしましたのでご連絡いたします。
本件は、タイムゾーンの異なる方からのスターにおいて生成されるURLにおいて発生しておりました。
今後は同様の不具合は発生いたしませんが、すでに生成されたURLについては修正することはできません。大変ご不便をおかけいたしますがご容赦ください。
その後、通知を確認したところ、通知のリンク切れのバグは解消されたようだが、スターが付かないというバグは解消されないままである。バグは半分だけ直ったが、半分は残されたままだ。
暗黙的にJSTとして時間を使ったせいでUTCで作った場所で盛大にバグる
応急処置でバグったところを+9とかやってしまうと、それ以降に逆に誰も気付かずに更に影響範囲が拡がったりする
海外展開しようとしたときにバグに気付くがどうしようもなくなって途方にくれて海外だけは別アプリになったりする
UNIXTIMEを使えば楽なんだけれど、そうすると生データぱっと見で時間を判別できないので困ることも多い
素直にUTCでISO8601が良い
とりあえずUTF-8にしとけば大丈夫、ってことで実装を進めた結果、Mac/Winでハマる
他にもBOMでハマったりして、むしろSJISの方が良かったんじゃ無いか、とか言い出す
DBが統一的になっている場合はまだ後からどうにかできるが、変なところでキャッシュされてたりすると凄い困ることになる
MySQLなりPostgreSQLなりでUTF-8を正しく扱う方法はいろんな記事があるのでちゃんと読んでおけば問題無い
とかよく分からないことを言い出して価格を浮動小数にしてしまう
確かに米国なら$2.43みたいな感じで価格を使ったりするし、むしろ小数点以下が無い通貨の方が珍しいのだけれど
丸め誤差を考えないで作ってしまってバグが見つかりめちゃくちゃ揉める
