はじめにLayerXで執行役員／VP of Product をしているnumashiといいます。 これまでキャリアの多くを、新規プロダクトの立ち上げにプレーヤーとして費やしてきました。ゼロからプロダクトを作り、顧客に届け、失敗し、作り直す——その繰り返しの中で、Minimum Viable Product(以下、MVP)という概念は自分にとって単なるフレームワーク以上のものでした。 「何を作るべきか」を問い続けるための、思考の型でした。 今、新規事業をやる中で、改めて生成AIの登場によってMVPの意味が根本から変わりつつあると感じたため、言語化しようと思います。 MVPとは何か新規プロダクトを作る際、MVPは開発の羅針盤でした。 Minimum Viable Product——その本質を説明するとき、Henrik Knibergのイラストがよく引用されます。 「車を作るなら、まずタイヤだけ

こんにちは。最近、AI将棋モデルの対局解説動画を見るのにハマっている大塚です。 将棋は全然わからないのですが、AIの予想外の手に驚いている解説を聞くのが結構面白いんですよね。 さて今回は、Agent–User Interaction（AG-UI）がどのような課題を解決するプロトコルなのかを確認します。 また、CopilotKitというフレームワークを利用して、AG-UIに準拠したアプリをどのように作成できるのかも試してみます。 1. AG-UIとは 1.1. AG-UIが解決しようとしている課題感 1.2. 他エージェントプロトコル（MCP・A2A）との違い 1.3. AG-UIが標準化している主なイベント 2. AG-UIを利用する 2.1. AG-UIを利用しない場合 Strands Agentsを利用したバックエンド実装 Google ADKを利用したバックエンド実装 フロントエンド

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

はじめに かつての私は、深夜2時にベッドの中で転職サイトを開いていた。 開いて、求人を眺めて、閉じて、また開く。そういうことを繰り返していた。辞めたいのか、と聞かれると困った。会社の限界が見えたのか。自分の天井が見えたのか。それとも、隣の芝生の青さに目が眩んでいただけなのか。たぶん、全部だった。たぶん、どれでもなかった。 今は、転職を考えていない。 これは「今の会社が最高だから」という話ではない。どんな会社にも良い面と悪い面がある。不満がゼロになることはない。ただ、深夜に転職サイトを開く衝動は、いつの間にか消えた。何が変わったのか。環境が変わったのか、自分が変わったのか。たぶん、両方だ。 「エンジニアは転職で年収が上がる」「成長できる環境に身を置け」——そんな言葉がタイムラインに流れてくる。転職エージェントからのスカウトメールは週に何通も届く。カジュアル面談のお誘い。年収アップの可能性。も

こんにちは。ソフトウェアエンジニアのyasuandです。株式会社estieのデータマネジメントグループ（DMG）という部署で、登記簿データの管理システムを作っています。 登記簿に限らず不動産データと日々触れ合っていると、時々”変な”データと出会うことがあります。住所の読みが面白いという程度ならその場でスルーして終わりなのですが、なかにはデータモデリング上の扱いが問題になるものも存在します。 そこで今回は『プログラマの抱いている名前についての誤謬』をオマージュして『プログラマの抱いている不動産データについての誤謬』というタイトルで、建物を中心とした不動産データに関して多くの方が誤解しているであろう点を10個厳選しました。それぞれ解説もつけているので、ぜひご覧ください。 1. 同じ住所の建物は存在しない 複数の建物が同じ住所になっていたら、郵便物や荷物を配達するときに困りますよね！ 解説 建物

https://2026.emconf.jp/

1週間の気になる生成AI技術・研究をいくつかピックアップして解説する連載「生成AIウィークリー」から、特に興味深いAI技術や研究にスポットライトを当てる生成AIクローズアップ。 今回は、ローカルで起動できるリアルタイム文字起こしAI「Moonshine Voice」を取り上げます。 ▲Moonshine Voiceリポジトリのスクリーンショット OpenAIの音声認識モデル「Whisper」は、リアルタイムの音声インタフェースとして組み込む場合にはいくつかの弱点を抱えています。まず、常に30秒の音声を処理する仕様のため、短い発話であっても空白部分の処理に計算リソースを浪費し、結果として応答遅延（レイテンシ）が生じやすくなります。 また、継続的な音声入力に対してもキャッシュの仕組みを持たず毎回ゼロから計算をやり直す点や、日本語などの非英語言語の精度が低下する点、さらにモバイルやIoT機器への

本書について 協力的多様性のための技術 『Plurality』は、社会的差異を超えた協力の力を認識し活用する、新たな技術パラダイムを描いています。テクノロジーが社会の絆を引き裂くのではなく、デジタルツールがいかに民主主義を強化し、分断を橋渡しし、人間の協力の可能性を解き放つかを示しています。 政治経済学者・技術者のE・グレン・ワイルと、台湾初のデジタル担当大臣オードリー・タンの共著である本書は、テクノ・リバタリアニズムと中央集権的AI統治の両極端の間に道を拓きます。デジタル民主主義の世界的リーダーとしての台湾の経験に基づき、技術がいかに公共の利益に資するよう設計できるかを示しています。 本書自体がその原則を体現しています：GitHubでオープンに執筆され、世界中のボランティアコミュニティにより十数カ国語に翻訳され、CC0の下でパブリックドメインに捧げられています。 本を入手する 読む・ダウ

以前上記で、自作しているtuiツールを紹介しました。 需要があるかわかりませんが、今回はoctorusで行っているパフォーマンス最適化について紹介します。 そもそも何が速いのか？ 「速い」といっても色々あります。表示ひとつとっても、初回表示の速さやハイライトを当てる速さ、スクロールのスムーズさ（fps）など多様です。 ユーザーの体感速度の速さと、内部的な速さは必ずしもイコールにはなりません。例えばどれだけゼロコピーやキャッシュを頑張っても、取得するPRが巨大な場合API通信がボトルネックになりますし、レンダリング面を工夫しなければフリーズしてしまうこともあります。 octorusでは実装面でできることはやりつつ、ウェブアプリ的な最適化（FCP/LCP/INP）もしています。 コアコンセプト 基本的にはtuiの表示状態によって非同期にキャッシュを構築し、利用しています。5層のキャッシュを持つ

ChatGPTやClaudeから、行政APIを介して最新の行政データにアクセス － AI HYVEとN-3、「行政オープンデータリモートMCPサーバ」を無料公開 －～ ChatGPTやClaude等のAIエージェントから、不動産取引価格・官公需入札・政府統計（e-Stat）へのデータアクセスを実現。MCP公式レジストリで無償公開 ～ 株式会社AI HYVE（東京都渋谷区、代表取締役：北條敦也、以下当社）と合同会社N-3（東京都文京区、代表者：栗本浩佑、以下N-3）は、バイブコーディングの普及および行政データ活用の推進による生産性向上を目的に、行政サービス（行政API）をAIエージェント／LLMから利用可能にする「リモートMCPサーバー（Model Context Protocol Server）」を無料で公開したことをお知らせします。 本取り組みは、当社が提供するAIドリブン開発の次世代S

The Art of Reading MarkdownA beautiful, offline-first macOS app that faithfully reproduces GitHub-style Markdown rendering. Because reading Markdown should be a quiet, deliberate act of understanding. Why Arto?Most Markdown tools focus on writing. Arto focuses on reading—giving you a distraction-free, beautiful experience. Reading-First DesignPurpose-built for reading, not editing. Enjoy a calm, f

Since launching Skills in October, we've seen strong interest from developers who want Claude to follow specific workflows consistently, power users automating repeatable tasks like document creation or research processes, teams looking to standardize how Claude operates across their organization, and MCP connector builders pairing their integrations with reliable workflows. The common thread: peo

GPT-5.2 vs Claude Opus 4.5、なぜ「伝わる」感覚が違うのか【設計思想から比較】 前回の記事でCodex vs Claude Codeの比較を書きました。内容をもう少し深掘りしたくなったので、普段業務で両方を使用している私が、今回は「設計思想の違い」という観点から掘り下げてみます。 Claudeが選ばれる本当の理由 前回、エコシステムの成熟度でClaudeが優位という話をしました。MCPサポートの充実、10,000以上のプラグイン対応など。 ただ、MCP、サブエージェント、スキル、フック、リワインドなど、Claude発の機能は現状ではCodexでも使えるものが多くなっています。本当にエコシステムが主要な理由でしょうか。 私がClaudeを使い続けている理由は、もっと単純なところにあると思っています。話してて伝わりやすい。 同じ質問に対する回答の違い 「このコードはUI

静的なWebサイトを生成するJavaScriptフレームワーク「Astro」を開発するAstro Technology Companyは、CDNサービス大手のCloudflareによる買収を発表しました。 We are joining Cloudflare!https://t.co/pZXCJcRxgA — Astro (@astrodotbuild) January 16, 2026 Astroはさまざまなフレームワークに対応したサイトジェネレータ Astroは、ReactやVue、Svelte、Alpine.js、TypeScriptなどのさまざまなフレームワークやライブラリに対応したオープンソースの静的サイトジェネレータです。 ビルド時にWebサイト全体のHTMLが生成され、しかもそのHTMLには全くJavaScriptが含まれないか、もしくはWebブラウザ上での動作に必要な最小限の

はじめに前職で技術顧問として そーだいさん にJOINしていただいていた際、私はデータベース設計から仕事の進め方相談まで、本当にお世話になりました。 そーだいさんは「ガタイも(物理的に)声も大きくて、ちょっと圧倒されるな……！」というものでしたが、実際にお話ししてみると、その中身は驚くほど優しく、そして本当にロジカルで誠実な方でした。 その圧倒的な「言語化能力」で、技術的な課題はもちろん、エンジニアとしての振る舞いや問題解決の考え方を、誰にでもわかる言葉で解きほぐしてくれます。 今回は、私が定期的に読み返し、1on1などの場でも「まずこれを読んで！」と周囲に布教している、そーだいさんの発信をいくつか紹介したいと思います。 1. 仕事を進めるうえでのマインドセット1-1. Howだけ考えると複雑さを導入して仕事が増える 「偽の進捗」の連鎖によるリソース枯渇の防止 手段に没頭して手順書の保守や

2025年は色々ありすぎた年だった。人生が進みすぎた。 学業 3月に筑波大学を卒業した。2019年に入学して2回留年して、やっと卒業できた。 自分は昔から本当に勉強ができなくて、高校生の時は大して頭のよくない学校で学年でビリから5番目くらいだったから、6年かかったとはいえ割とまともな大学をちゃんと卒業できたってのは本当に嬉しい。 卒論の出来は本当に悪くて「えっこれでいいの？」ってくらい酷かった。LadybirdブラウザのJavaScript処理系であるLibJSに、可能な限りオーバーヘッドが少なくなるようにGCの動作をトレースするinstrumentationを実装して性能を評価する、みたいなやつをやった。これは実際にはJava向けの既存の手法をほぼそのまま実装しただけのやつなので研究としては普通にめっちゃしょぼかったし、性能評価も「それはそうですよね」という感じだった。 ただ、他の人のや

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

デンソーは、エンジニアの暗黙知を蓄積し共有するためのナレッジマネジメント基盤の開発を進めている。文書や音声に含まれる暗黙知をAI（人工知能）技術で抽出し、組織全体で検索可能にすることで設計力・開発力を高めるのが目的だ。開発を支援する富士ソフトが2025年11月28日に発表した。 デンソーが開発しているのは、エンジニアの暗黙知をデジタルデータとして蓄積・共有するためのナレッジマネジメント基盤（図1）。経験や判断の勘所を組織全体で活用できる知識として蓄積・整理し、設計力・開発力を高めるのが目的だ。 35の国と地域で事業を展開するなか、海外拠点では日本以上に人材の流動性が高く、限られた在籍期間の中で、エンジニアが持つ知識やノウハウをいかに組織に残すかが課題になってきたほか、熟練者の退職や異動によって知見が失われるリスクも顕在化していた。 開発中のナレッジマネジメント基盤では、エンジニアが蓄積して