utakatanka.jp 趣味で開発している短歌投稿サイトUtakataのトップページに表示される「人気の歌」の掲載ロジックを変更した。 素朴な「いいね数ランキング」から始まった Utakataは8年前、私がWeb開発未経験だった頃に作ったサービスだ。 サービス開始当初から、直近期間の被いいね数が多い短歌を「人気の歌」としてトップページに掲載していた。非常に素朴なロジックだったが、最初はそれで十分に機能していた。集計期間を直近で区切ることで、掲載される歌もほどよく入れ替わっていた。 できたばかりのUtakataには個性的なユーザーが集まっていて、トップページを読むと面白い作品を見つけることができた。 台頭する「互助会」 それが段々と、お互いにいいねを付け合う「互助会」ユーザーの投稿短歌が、トップページを占有するようになってきた。もはや短歌の体をなしてすらいないような、「仲間内での交流」を

ブログサービスなどを運営するはてな（京都市中京区／東証グロース）の株価が4月27日、値幅制限の下限（ストップ安）水準の881円で売り気配のまま推移し、終日値が付かなかった。同社が前週末に発表した、不正な送金指示による最大約11億円の資金流出事案が嫌気された。 前週末24日の終値は1181円で、27日のストップ安水準は300円安の881円。同日は寄り付きから売り注文が積み上がり、買いが追いつかなかった。 売り材料となったのは、24日に開示した資金流出事案だ。4月20日と21日、悪意ある第三者から虚偽の送金指示に従い、従業員のアカウントから銀行預金を外部の口座に送金していた。 同社の2026年7月期通期業績予想は、売上高38億5900万円、営業利益1億3600万円。最大被害額は、通期営業利益予想の約8倍に相当する規模だ。 同社は手元の運転資金について「十分な流動性を確保しており、事業運営や資金

2026年4月24日 はてな[3930]の開示資料「資金流出事案の発生に関するお知らせ」 が閲覧できます。資料はPDFでダウンロードできます

赤絨毯の敷かれた階段を登っていくと、委員会室のドアに至る。 3月16日15時22分の出来事。 休憩時間の終わりまで後3分。 まるで門番のように、大きな影が私の進路を遮った。 へずまりゅうである。 彼の顔面は私の眼前10cm程の距離にまで近づき、大きな怒鳴り声を放った。 「なんなら！！これは！？」 それがアニメであるなら、突風が正面から吹いたかのように衝撃で髪が逆立っただろう。 そのくらいの大声である。 いい大人の人間関係としては甚だ不適切で、心底不愉快だ。 議会という言論の府において、このような暴力的かつ無礼な振る舞いを目にした記憶は、少なくとも私にはない。 事態が飲み込めたわけではない。 が、へずまりゅうが私に怒っている。 そして「なんなら」と私の眼前に提示されている「これ」がその理由である、ということは間違いないようであった。 「これ」がスマホなのはわかるが、何が映っているのかよく見え

なぜ、日本のITシステム開発は丸投げユーザー企業と御用聞きベンダーという相容れない組合せで成立していたのか？ はじめに 日本のITシステム開発が丸投げ型のユーザー企業と御用聞き型のベンダーという相容れない組合せで成立していた理由は、両者の間に配置された 一人、多くても数人 の吸収役が矛盾のすべてを引き受けていたからです。本稿の結論はこの一点に尽きます。以下の議論は全部、この結論を補強するために並べます。 ここで扱う吸収役は、組織図に書かれた上流SEや業務SEの役割と重なる部分があります。重要なのは、彼らが制度的な工程分業の結果として配置されていたのではなく、契約書や組織図の外側で機能的に成立していた点です。「隠れた」という言い方がしっくり来ない読者は、契約関係の外側で実質的な設計判断を担っていた少数 と読み替えてもらって構いません。呼び名よりも、その人物が不在になると案件が止まるという属人

1830年頃、わずかな夜の明かりを得るためには、約3時間の労働が必要でした。しかし1992年ごろにはそれが1秒にも満たない労働ですむようになったと言われています。ロウソクから白熱電球、蛍光灯へという技術的発展が、光を劇的に安くしたのです。 そうして光が安くなったとき、人は同じ量の光を単に安く買って終わり――ということにはなりませんでした。 人々は、かつて置こうとも思わなかった場所にまで光を置き、街路、工場、看板といった、社会のあらゆる場所に安くなった光を敷き詰めていきました。そうして、工場は曇りや雨の日にも稼働することができるようになったり、深夜営業や夜の読書といった新しい活動が可能になったのです。 そこで儲けたのは、光を提供した会社だけではなく、それをうまく使った会社でした。 では、ソフトウェアや知能が安くなったとき、私たちはそれをどのように使うのでしょうか。 生成AIによる大きな変化は

アメリカの新興AI企業、アンソロピックが公開した新たなAIモデルをめぐり、サイバー攻撃に悪用された場合、金融システムにリスクをもたらす可能性があるとして、ベッセント財務長官が金融大手のトップらを集めた…

元々将棋もVTuberもそれぞれ好きだったけど、不意におすすめされたこの動画を見てたまげちゃった。 めったに見ない後付けの将棋エフェクト編集も楽しいね。AI評価値を載せてるあたり、切り抜き師も元々将棋ファンだったんだろう。 ↓ ぶいすぽルート - 【将棋】Twitch将棋部で学んだ全てを出し切るべく全力で勝負する夢野あかり【ぶいすぽ/夢野あかり/柊ツルギ/切り抜き】 (25:47) https://www.youtube.com/watch?v=VV7B4nOtOcE 夢野あかり(登録58.5万人)は大手事務所のぶいすぽっ！所属で、YouTubeではなくTwitchが主戦場のようだ。そういう人もおるんやな。 だいぶ初心者レベルに近いのと、2月を最後に既に彼女自身のブームはいったん落ち着いた雰囲気もあるけど、50万人超えのVTuberが将棋を楽しんでくれてるのはうれしい。 ↓ 夢野あかり -

速くてノリノリの曲でおすすめ教えてほしいでつ

Anthropic Claude Codeのnpmパッケージにソースマップが含まれ、1,902ファイル・51万行超のTypeScriptソースが公開状態に。未公開プロジェクト「KAIROS」や107個のフィーチャーフラグなど、内部コードの全貌を解説する。 Anthropicが「うっかり」自社ツールの中身を全公開した Anthropicが提供するAIコーディングツール「Claude Code」の中身が丸見えになった。 ハッキングされたわけではない。Anthropicが自分でnpm（JavaScriptのパッケージ管理システム）にコードを公開するとき、「ソースマップ」という本来含めてはいけないファイルを一緒に入れてしまった。いわば設計図を製品と一緒に箱に入れて出荷してしまったようなものだ。 発見したのはセキュリティ研究者のChaofan Shou氏。対象は @anthropic-ai/clau

TL;DR 2026年3月31日、npm で最も利用されているHTTPクライアントライブラリの一つである axios がサプライチェーン攻撃を受けました。攻撃者はリードメンテナーのアカウントを乗っ取り、マルウェアを含む2つのバージョンを公開しています。 項目 内容

はじめに エディタを開いたまま、手が止まっていた。 LLM（大規模言語モデル）が書いた Rust のコードを眺めている。WAL（Write-Ahead Log、データを安全に書き込むための仕組み）のセグメント管理。所有権（データの持ち主を明示する Rust 独自のルール）は正しい。ライフタイム（データが有効な期間の指定）も整合している。Clippy（Rust の静的解析ツール）の警告はゼロ。美しいコードだった。ただ、セグメントサイズが 128MB になっている。このプロジェクトでは 64MB だ。NVMe SSD（高速ストレージ）の消去ブロックサイズとリカバリ SLA（障害復旧の目標時間）の制約から決めた値だ——3ヶ月前の障害振り返りで。その判断はどこにも書いていなかった。コードにコメントもない。Slack のスレッドに埋もれていた。 LLM には何の落ち度もない。道具は完璧に動いた。道具

会社の運営には給与管理・財務管理・注文管理・在庫管理などさまざまな管理が必要で、企業資源計画(ERP)と呼ばれるシステムを導入すると一元管理できますが、複雑な機能の学習コストやランニングコストなどの負担が大きいため、個人経営のお店や小規模な工場などでは本格的なERPシステムを導入できません。しかし個人のお店レベルであるからこそむしろERPがあればもっと便利なはず、ということで夫が妻のパン屋のために開発したという必要最低限の機能を備えた小規模製造業向けのERPシステム「Craftplan」が、セルフホストに構築可能なオープンソースシステムとして公開されています。 puemos/craftplan: Self-hosted software for managing artisanal D2C micro-businesses https://github.com/puemos/craftpl

こんにちは。クラシル株式会社 小川です。 ここ数週間、売上分析から施策立案、MAツールへの配信設定、効果検証まで、グロース業務をClaude Codeで自動化する取り組みをしています。 マルチエージェントを活用することで、もともと複数人で分担していた作業が、1人＋AIチームで回りつつあります。 まだ発展途上ですが、設計の考え方と気づきを整理してみます。 まずは全容です。 それぞれポイントを後述していきます。 まずやったこと：業務データの集約AIチームの設計より先に、前提の話です。AIが意思決定に必要な情報にアクセスできる状態を作ることがとても重要です。 業務で使うデータって散らばっていて、売上の実績はDWH、コストや予算の計画はスプレッドシート、施策の実施状況はSlack、運用方針はNotion。人間はこれらを頭の中でつなげて判断していますが、AIにそれはできません。 なのでまず、これらを

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Connecting decision makers to a dynamic network of information, people and ideas, Bloomberg quickly and accurately delivers business and financial information, news and insight around the world

参考サイト（元ネタ）はこちらです。 じゅもんを解析した日記や、C言語やTypeScriptでのソースコードを公開されています。 ドラクエ1に存在するステータス ドラクエ1は普通にプレイすると10～20時間くらいかかる、そこそこやりごたえのあるゲームですが、使用できるデータ量は64KBと非常に少なかったです。なので、レベルは経験値から計算する、HPはレベルから計算する…などといったように、保存しておくべきステータスをなるべく削減するという工夫がなされていました。 よって、主人公の状態を決めるステータスも数が絞られ、下の項目に示す分しかありません。 名前（6bit×4文字） 経験値（16bit） 所持金（16bit） ぶき（3bit） よろい（3bit） たて（2bit） アイテム（4bit×8） やくそうの数（4bit） かぎの数（4bit） りゅうのうろこを装備したか（1bit） せんしの