NVIDIA DGX Spark 互換機 (以下 Spark) を 2 台購入し、クラスター起動して ローカルで DeepSeek V4 Flash 0731 の運用を開始したので雑感を書いて行く。 前提そもそもコスパを検討するなら API 利用をすべきなので、コスト面でのメリットはとても薄い。 速度まずローカル LLM の一番気になっていた「速度」だが「仕事で十分利用できるレベル」という判断になった。 最大 114 tok/s まで確認した 安定している ローカル LLM は主に社員に使って貰っており、社員からは「今まで API で利用していたのと特に違和感なく利用できている。API の料金やサブスクの制限を考えず、完全クローズド環境で使える安心感はとても良い」とのフィードバックを貰った。 安定面以下のレシピを使わせて頂いている。FP8 重み + NVFP4 MLA KV 。 Commi
If you haven’t already seen a job listing for a “product engineer,” you probably will soon. The job everyone’s suddenly hiring for, this role is like a cross between a product manager and an engineer (as the name suggests). And it’s a hiring trend worth paying attention to. Companies are opening more of these roles every single month, but they’re struggling to fill them. The reason has almost noth
最後の「古くなる速さ」がODR特有の重要な性質で、フォーマットにも反映しています。そして後述するとおり、この性質こそが規模の限界の正体でもあります。 フォーマット 軽量であることを最優先にしています。書くコストが高いと、いちばん記録してほしい「インシデント直後」に書かれなくなるからです。イメージしやすいように、Uber Eatsのようなフードデリバリーサービスの「配達員のGPSロスト」を例に書いてみます。 # ODR-0003: 配達員GPSロスト時は30分様子を見てから自動返金へ切り替える - Status: Accepted - Date: 2026-11-02 - Review-by: 2027-05-02 # この日を過ぎたら前提を再検証する - Scope: service-delivery / alert: courier-gps-lost - Decided-in: inci
競馬について知識ゼロの状態からAIを使った機械学習によって収益化できないか検討しました。2週間ほどデータ分析をして一定の手応えはあったものの収益化はまだ難しそうです。 これまで得た知見の整理を含めて記録として一旦まとめをしています。 対象:JRA単勝市場の8年35万走データ 手法:LightGBMによる条件付きロジットモデル 検証:ウォークフォワード、リーク検定、期間分割、データ汚染チェック 競馬の知識が皆無なため基本的にはAIが出してきた視点の偏りを是正することが私の役割でした。この記事自体の本文も大体はAIを使って書いています。 競馬に精通している方からすると当たり前のことなのかもしれないですが、なかなか面白い市場なのでしばらく分析をしていこうと思います。 現状は特にうまくいっていないので全文無料公開しています。 面白かったと思ったら投げ銭でもしてくださいな。 第1章 市場のオッズは思
Cloudflareへ移るまで、我々が富豪プログラミングをしているとは気づきませんでした。 EC2で動かしていたNestJSをHono + Cloudflare Workersへ移しました。RDSはそのまま使い、ElastiCacheの役割はCloudflare側へ移しています。 大きなSDKを入れる。レスポンスを全部メモリへ載せる。DBのSELECTを順番に待つ。Cronで全件を完走する。SSEをつなぎっぱなしにする。ElastiCacheの細かいキーを何度も読む。 どれも珍しい実装ではありません。少なくとも私のAWS構成では普通に動き、わざわざ直す理由もありませんでした。サーバーとクラスターの月額に、まとめて収まっていたからです。 Cloudflareへ移すと、それぞれにバンドルサイズ、128 MBのメモリ、ネットワーク往復、CPU時間、Durable ObjectsのDuration
最近、ソフトウェア開発における概念設計の威力と重要さについて人に伝えたい機会が何度かあった。[1] しかし、概念の整理がなぜどのように重要なのか、という一点を取り上げて書かれたものは少ないようで、人に渡すのにちょうどよい文章や書籍が見つからなかったので、このたび私なりに咀嚼して書いてみたい。 そのアプリケーションの世界には、そもそも何が存在するのか。 何と何を同じものとして扱い、何と何を別のものとして扱うのか。 ここの判断が合っていると、その後の実装は驚くほど素直になる。逆にここを外すと、一つ一つの実装は正しくても、仕様が増えるたびに少しずつ帳尻合わせが必要になる。 まず、一つの小さなECサイトから話を始めよう。 Acme社のECサイトでの出来事 Acme社では、小さなECサイトを作っている。注文には商品ごとの明細があり、その配送状況も確認できる。最初のモデルはこうなった。 type Or
こんにちは。AIを効率的に使うならSkillを入れた方がいいとよく言われていますよね。 実際、Agent Skillを探し始めるとかなりの数が見つかります。 ですが、何でもかんでも入れればいいというわけではありません。む […]
生成AIの利用が広がるほど、情報システム部門やセキュリティ部門が承認していないAIを、従業員が業務で使う「シャドーAI」は増えます。 個人アカウントの生成AIへ会議録を貼る。部門が独自にAIエージェントを作る。開発者が個人契約のコーディングAIに業務コードを読ませる。私物端末でローカルLLMを試す。いずれも現実に起こり得る利用です。 この問題を「未承認サービスを見つけて遮断すること」だけで扱うと、AI利用は見えない場所へ移るだけです。IT技術者が作るべきなのは、禁止リストではなく、誰が、どの機能を、どのデータに対し、どの責任で使えるかという運用の仕組みです。 シャドーAIは、責任分担が未設計であることの表れ 現場が未承認AIを使う理由は、必ずしもルール違反をしたいからではありません。公式環境では必要な機能が使えない、申請が遅い、相談先が不明、業務改善を求められている、といった事情があります
作るより消すほうが大変 Webサービスは、作るときより終わらせるときのほうが面倒です。 少なくとも私はそうでした。 作り始めたころは、 「Cloudflare Workers便利!」 「Supabase最高!」 「決済もSaaSでいける!」 「AIも載せちゃおう!」 「監視も入れとくか!」 と、現代Web開発の恩恵を浴びながら、楽しそうに外部サービスを増やしていました。 数か月後。 サービスを閉じることになった私は、それらの管理画面を一つずつ巡回しながら、 「全部俺が登録したんだった」 という当たり前の事実に直面することになります。 Webサービスの終了は、サーバーを停止すれば終わりではありません。 新規登録を止める。 課金を止める。 書き込みを止める。 ユーザーに通知する。 個人データを消す。 Webhookを止める。 APIキーを殺す。 DNSを消す。 リポジトリを片付ける。 サービス
同じ質問を投げたのに、部署ごとに違う数字が返ってくる。しかも、どちらのAIも間違ってない。 生成AIを業務に入れた組織で、いま静かに起きている現象です。この記事では、その正体を解きほぐしたうえで、2025年くらいから主要ベンダーが揃って使い始めた「オントロジー」という言葉が、いま何を指し、技術的に何を作る話なのかを整理します。 この記事の立ち位置 オントロジーの技術スタック――URI から RDF、RDFS / OWL、推論、SPARQL、トリプルストアへと積み上がっていく話――は、すでに良質な解説がたくさんあります。この記事では、構文の書き方までは踏み込みません(用語が何を指すかだけ、2章で一度まとめて整理します)。 扱うのはその手前です。「なぜ今この言葉が戻ってきたのか」「業務のどこで効くのか」「そして誰がそれを書くのか」。コードは出てきますが、動かすためではなく、話を具体にするために
メルカリが明かす「Claude Code全社展開」「シャドーAI対策」を支える仕組み:メルカリのAIエージェント活用&AIガバナンス大解剖(2) 「AIを使わない選択自体がビジネスリスク」と断言するメルカリ。同社は2026年5月、「Claude Code」「Claude Cowork」の全社展開に踏み切った。だが、ローカルファイルの操作やOSコマンドまで実行できる強力なツールの配布は、ガバナンスの課題も伴う。全社のAI活用を支える同社の「仕組み」に迫る。 メルカリのAIエージェント活用&AIガバナンスに迫る本連載。第1回では、2025年5月に「AI-Native Company」への転換を宣言したメルカリが「AIを前提に再設計された組織」になるために、推進とセキュリティを一体化した組織体制を構築したこと、そして「ガードレール」としての伴走型ガバナンスを目指していることを聞いた。 2026年
Studies show that Japanese firms are dragging their feet when it comes to using AI Facing acute labour shortages, ageing demographics and chronic productivity problems, Japanese companies should be fertile ground for the take-up of artificial intelligence (AI). Yet, compared with the US and UK, adoption in many workplaces remains sluggish and cautious. Japan's response to AI is beginning to resemb
円や直線を使って幾何学的にロゴをデザインできる──そんなサービスを日本の個人開発者が作り、Xで話題となっている。この機能を紹介した投稿の表示回数は500万件を超えた。 サービス名は「Rikyū」。作りたいものを指示することで、ロゴやWebサイト、ポスターなどさまざまなデザインを作成できるという。MCP連携にも対応し、「Claude」や「Codex」、「Cursor」など、普段使っているAIツールからデザイン制作を依頼できる。写真や動画など300万点を超える素材も無料で利用できるという。 開発者の鈴木海星氏(@kaiseisuzuk)がXで公開した例では、ゴリラやライオンをモチーフにした完成ロゴとともに、円や直線による“設計図”風の画像も添えられていた。Xでは、実際に機能を試したユーザーから生成したロゴの投稿が相次ぎ、「設計動画まで出してくれるのは面白い」「Twitterの美しい鳥のロゴを思
1週間の気になる生成AI技術・研究をいくつかピックアップして解説する連載「生成AIウィークリー」から、特に興味深いAI技術や研究にスポットライトを当てる生成AIクローズアップ。 今回は、WordやPDFといった多様な文書をMarkdown(GitHub-Flavored Markdown)に高速変換するRust製ライブラリ「anydoc」を取り上げます。 AIに読ませやすい形へ整えることを目的に作られており、どの形式を入れても出力の体裁が揃うのが特徴です。FirecrawlがMITライセンスのオープンソースとして公開しました。 対応形式はWord(.doc/.docx/.docm)、PowerPoint、Excel、OpenDocument、リッチテキスト、EPUB、CSV、PDFです。PDF以外の各形式では、どの形式もいったん共通のドキュメントモデルに変換してから同じ処理でMarkdow
この例では、確率2位の dog が、たまたま高い乱数 r = 0.95 を引いたおかげで勝っています。とはいえ p_i が大きいほど指数 1/p_i が小さく r_i^{1/p_i} は 1 に近づくので、基本的には確率の高い候補ほど勝ちやすい競争です。そして、この選び方でトークン i が勝つ確率は元の p_i に厳密に一致することが、Gumbel-Max トリックとして知られる古典的な性質から従います。乱数でくじ引きする代わりに「乱数を使った決定的な最大値選び」をしているだけなので、外から観察できる振る舞いは通常のサンプリングと区別がつかないわけです。 では、分布が同じなのにどうやって検出するのでしょうか。着眼点は、透かし入りテキストの各単語が「高い r_i を引いたから勝った」勝者の集まりだという点です。 人間が書いた文章に同じ計算を適用すると、各単語に割り当たる r は書き手と無関係
はじめに Coding Agentの進化によって、ソフトウェア開発の形が大きく変わり始めています。 少し前までAIによる開発支援といえば、 コード補完 コード生成 リファクタリング テストコード生成 など、「人間が主体で、AIが支援する」使い方が中心でした。 しかし現在のCoding Agentは、単にコードを生成するだけではありません。 仕様を読み、Repositoryを調査し、実装し、テストを書き、失敗すれば原因を分析して修正する。 そしてテストがGreenになるまで、このループを自律的に回せるようになってきました。 これは非常に強力です。 しかし、ここで一つ重要な疑問が生まれます。 AIが実装し、AIがテストを作り、AIがそのテストを通るまで修正したとき、そのGreenは何を保証しているのでしょうか。 この記事で考えたいのは、まさにこの点です。 「テストがGreenだから正しい」は、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く