本連載は分散型マイクロブログ用オープンソースソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っています。 Misskeyの開発を行う上では、「活用したいがまだ一部のブラウザにしか実装されていない」技術がよくあります。JavaScriptを用いると非対応ブラウザでも再現可能なものもありますが、ネイティブに実装されているに越したことはありません。 今回は、今後それらの技術が広く実装されることに期待を込め、各主要ブラウザの対応状況も示しつつ簡単に紹介します。 なお、対応状況を示すアイコンの意味は、✅=完全対応、⚠️=部分対応または不安定、❌=未対応とします。 注意 各項目では、MDNなどの技術仕様のドキュメントへリンクをかけています。 ただし、MDNに示されている対応状況は、稀に間違いや反映の遅れがあるほか、実際は「一部対応」のところ「完全対応」表示になってし
はじめに 「今年読んで良かった本」という記事を書こうとしている自分に、ふと気づく。また書くのか。毎年書いている。誰に頼まれたわけでもないのに、12月になると決まってこの作業を始めてしまう。習慣なのか、義務感なのか、それとも単なる自己顕示欲なのか。たぶん、全部だ。 100冊近く読んだ、と書こうとして手が止まる。この数字を出した瞬間、どこかで「すごいですね」と言われたい自分がいる。同時に、「いや、冊数なんて意味ないですから」と予防線を張りたがっている自分もいる。めんどくさい人間だ。でも正直に言えば、100冊読んだことより、1冊を血肉にできた人のほうがよほど偉いと本気で思っている。思っているのに、冊数を書いてしまう。そういう矛盾を抱えたまま、この文章を書いている。 AIに聞けば答えは返ってくる。2025年はそういう年だった。コードを書いてもらい、設計を相談し、ドキュメントを要約させた。便利だ。本
企業による人工知能(AI)の配備に関しては、成功を妨げる障壁がいくつか存在する。具体的には、AIの活用法をよくわかっていない上層部や、AIサービスに与える情報のクリーニングと体系化がこれにあたる。 企業内AI導入促進の起爆剤に そんな中、Googleは米国時間8月28日、同社の大規模言語モデルのAIプログラム、「Gemini」シリーズのオンプレミス版の提供を始めると発表した。これは「Google Distributed Cloud」(GDC)のオンプレミス製品によって提供される。同社はこれにより、企業内でのAI導入が促進されることを期待している。 今回の発表は、Googleの親会社にあたるAlphabetが4月に行った、オンプレミス版Geminiの導入予定に関する当初の発表に続くものだ。「GDCでも顧客にGeminiの提供を開始すると発表できることに、胸を躍らせている。これにより、Goog
PostgreSQL開発チームは先月(2025年5月)にリリースした「PostgreSQL 18 Beta 1」で非同期I/O処理を実装したことを明らかにしています。 同チームのテストによると、シーケンシャルスキャンやビットマップヒープスキャン、バキュームといった処理において2~3倍の性能向上が見られたとのことです。 同期処理はシンプルだが待ち時間が発生する これまでのPostgreSQLは同期I/O処理を採用していました。これは例えばOSにファイルリードのようなI/O処理を依頼すると、処理が終了して結果が返ってくるまで、すべてのPostgreSQLの内部処理が一時停止することを意味します。 同期I/O処理の利点はすべてのI/O処理が同期的に行われるため、実装が比較的シンプルで容易だというメリットがあります。これはバグを引き起こしにくいとも言えます。 一方で、ひとつひとつのI/O処理が完了
newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo
どうも!生成AIのプロダクト開発支援やってるエクスプラザの"生成AIエバンジェリスト"みやっちです!(Xのアカウントは @miyatti ) ざっくりいうと生成AIの「社会」推進を日々がんばっている人間です。 ※ 自己紹介と会社紹介的に入社エントリおいておきます 今回はノンエンジニア向けのCursor講座という内容で、記事をかかせていただきました!だいぶ長文ですけど、もしよければご参考にしていただければ! 0. はじめに ── そもそも“エージェント”って何?「AIエージェント」……最近、こうした言葉を耳にする機会が増えていませんか? ざっくり言えば、“AIが自分で考えて動いてくれる存在”を指します。たとえば「イベントの準備を任せたい」と伝えるだけで、必要なタスクリストを自動的に生成し、順番や優先度を決めて進行管理までやってくれるのがエージェントの魅力。まるでAI秘書のように、こちらの目的
米中が主導するAI開発の覇権争いに、日本発のスタートアップが新たな変数として浮上している。創業からわずか18カ月のSakana AIが、革新的な「省資源型AI開発」を武器に、グローバルな存在感を示し始めた。急成長の一方で技術的な論争も経験しながら、このほど事業開発本部を設立し、研究成果の社会実装へと本格始動。世界的AIスタートアップとしての真価が問われる新たな段階に入った。 「日本は強い民主主義国家として、独自のAI技術を持つべきだ」。2月7日、東京大学で開催された第5回Beyond AI研究推進機構国際シンポジウムで、Google Brain(現Google DeepMind)の元研究者で同社創業者のデイビット・ハー氏はそう語った。米中が主導するAI開発の現状に一石を投じ、AI開発に必要な計算資源を100万分の1に削減する革新的な技術を武器に、新たな覇権獲得に挑む。 世界のAI開発、米中
この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される(あるいはされない)技術そのものが原因となる意思決定です。 一方、消極
なんか驚き屋っぽくてアレなんだけど、今回はさすがに驚く権利があると思うので、至急記事を書く。 やろうとしたこと 毎回手元の検証結果から技術記事を構成するのがだるい 自分のブログを適当に読ませておいて、その構成と文体を真似させればいいのでは 手元に mizchi/zenn というリポジトリがあり、ここに zennにポストする原稿を管理している。 $ tree ./articles ./articles ├── 1c35fdcc77065c02f631.md ├── 3e4742e24f2ca0118f70.md ├── 8a017097d3994ddc0a85.md ├── ai-code-generation.md ├── ai-programmer.md ├── ai-team-mate.md ├── antipattern-of-tournament-score-sheet.md ├─
リチウム空気電池は、ガソリン並みのエネルギー密度を実現できる次世代電池として注目されています。イリノイ工科大学の研究チームが、室温で1000サイクル以上動作し、通常の空気中でも安定して機能するリチウム空気電池の固体電解質を発表しました。 A room temperature rechargeable Li2O-based lithium-air battery enabled by a solid electrolyte | Science https://www.science.org/doi/10.1126/science.abq1347 この研究で開発された固体電解質は、2011年に東京工業大学の菅野了次教授らのグループによって発見されたLi10GeP2S12(LGPS)ナノ粒子を、ポリエチレンオキシド(PEO)ポリマーに組み込んだ複合材料です。LGPSナノ粒子は高いリチウムイオン伝
2025年1月31日、スタンフォード大学で大規模言語モデルを研究するニクラス・ミュニホフ氏らの研究チームが、少ないデータサンプルと簡単な方法でOpenAI o1-previewとほぼ同等のスケーリングとパフォーマンスを再現する手法を、未査読論文リポジトリのarXivに発表しました。AIアーキテクトでソフトウェアエンジニアのティム・ケロッグ氏が、この論文について解説しています。 [2501.19393] s1: Simple test-time scaling https://arxiv.org/abs/2501.19393 S1: The $6 R1 Competitor? - Tim Kellogg https://timkellogg.me/blog/2025/02/03/s1 ミュニホフ氏らが発表した論文は、テスト時の計算リソースを増やすことで言語モデルの推論性能を向上させる「Sim
物理学者の逆襲!?Entropixはわずか3億6000万パラメータで1000億パラメータ級の回答を引き出す!Claude-3でも間違う問題を360Mが正しく解く 物理学者たちがノーベル物理学賞をホップフィールドとヒントンが受賞すると知った時、まあまあ微妙な気持ちになったことは想像に難くない。 我々コンピュータ科学者にとっては、ノーベル賞は全く無縁なものだった。むしろ「ノーベル賞をコンピュータ科学者が取ることは永久にない」と言い訳することさえできた。コンピュータ科学の世界にはチューリング賞という立派な賞があるし、ノーベル賞よりも賞金が高かった京都賞は、アラン・ケイやアイヴァン・サザーランド、ドナルド・クヌースなど、コンピュータ科学者たちが堂々と受賞している。その割には本来マイクロチップの最初の設計者である嶋正利などが京都賞にノミネートされていなかったり、サザーランドの弟子であるアラン・ケイの
Spring Sale: Lock in for lessSave 20% on Annual Pro and PremierSpring Sale: Lock in for lessSave 20% on Annual Pro and PremierSpring Sale: Lock in for lessSave 20% on Annual Pro and PremierSpring Sale: Lock in for lessSave 20% on Annual Pro and PremierSpring Sale: Lock in for lessSave 20% on Annual Pro and PremierSpring Sale: Lock in for lessSave 20% on Annual Pro and PremierSpring Sale: Lock in f
株式会社ナレッジセンスは、生成AIやRAGを使ったプロダクトを、エンタープライズ向けに開発提供しているスタートアップです。本記事では、RAGの性能を高めるための「Router Retriever」という手法について、ざっくり理解します。 この記事は何 RAGを実装するエンジニアが困りがちなのは、大量の文書から「いかに、ソースとなる正しい文書を検索してくるか」という検索部分です。この記事では、そういった文書検索の精度を上げるための手法である「RouterRetriever」の論文[1]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは?」については、知っている前提で進みます。確認する場合は以下の記事もご参考下さい。 (注:前提として、今回の手法はちょっとディープです。これまでRAGをやってきたエンジニアで、「RAGの文書検索って難しい」と感じたことがある方にだけ刺さる内容
WebアプリでURLシェアを実装する際に、URLにすべての情報を持たせてしまいたい場合があります。そのとき、情報をそのままクエリ文字列に渡してしまうとURLの文字数制限に引っかかってしまうかもしれません(厳密にはURLに上限はないようですが、現実はいつもブラウザ実装依存)。 そんなときURLセーフな文字列形式で圧縮してくれるライブラリがあります。lz-sringです。 変換の例 ライブラリで compressToEncodedURIComponent というAPIが提供されているのでこれを使用します。標準のencodeURIComponentでURLセーフな文字列に変換した場合とサイズ比較をしてみましょう。 import lzstring from "lz-string"; const rawData = "Lorem ipsum dolor sit amet, consectetur a
Coding at the Speed of Thought: The New Era of Symfony Docker
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く