2025.12.05 イベントレポート AIエンジニアが本気で作ったLLM勉強会資料を大公開 〜そのまま使えるハンズオン用コード付き〜 by Tomoki Yoshida #ai #llm #rag はじめに こんにちは、2020年に新卒入社してからDeNAでAIエンジニアをしている吉田（ @birdwatcherYT ）です。 いつもは Qiita に技術記事を発信しているのですが、今回は社内の取り組みとしてエンジニアリングブログを書くことにしました（入社6年目でなにげに初執筆です）。 それでは、2025年12月1日に渋谷オフィスでのオフライン開催とオンラインのハイブリッド形式で開催した社内勉強会の開催レポートをお届けします。 3時間の講義&ハンズオン形式のLLM勉強会を実施 新規AIプロダクトを開発しているPdM&エンジニア向けに、AIをコアとしたプロダクト作りのために必要な知識を詰め
AIエージェントの開発を一気に行っていたのでそのまとめとなる記事を書いてみようと思います。 エージェント開発のSDKやノーコードツールは充実してきていますが、MVPとしてバックエンドとして使ってる Go でライブラリなどをあまり使わず開発を進めた結果、ほぼ自前で実装することになったので一からのAIエージェント開発ということで参考になるかと思います。 1. はじめに：なぜ Go で AI エージェント基盤を作るのか AI エージェントの実装といえば、一般には Python が選ばれます。 LangChain / LangGraph や LlamaIndex など、強力なエージェントフレームワークのサポートが充実しているからです。 ではなぜ筆者は、Go で、しかも（ほぼ）自前の AI エージェント基盤を一から構築したのか？ その理由は以下の 3 点に集約されます。 既存のバックエンドが Go
1. はじめに Web開発の世界では、さまざまなフレームワークやライブラリが日々進化を続けています。2025年現在、フロントエンドとバックエンドそれぞれに多くの選択肢があり、プロジェクトに最適なものを選ぶことが成功の鍵となりますね。 本記事では、現在最も使われている主要なWebフレームワークについて、その特徴や違いを詳しく解説します。 1.1 本記事で取り上げるフレームワーク フロントエンド React Vue.js Next.js バックエンド Express.js (Node.js) Django (Python) FastAPI (Python) Ruby on Rails (Ruby) また、これらのフレームワークと密接な関係にあるTypeScriptについても解説します。 1.2 フレームワークとライブラリの違い フレームワークとライブラリは混同されがちですが、明確な違いがありま
はじめに10/7/2025 ~ 10/8/2025 にかけて開催された React Conf 2025 に招待を受け、参加してきた。 React Conf は Meta 社と callstack 社が主催する、React に関するカンファレンスである。 今回は、その内容を振り返り、特に印象に残ったセッションについてまとめる。 Day 1IntroductionReact Conf 2025 のはじまりは、 Seth Webster 氏の挨拶から始まった。 短い挨拶だったが、その中で彼は React の素晴らしさはただのライブラリではなくコミュニティの大きさにあると語った。 私も同意見で、 React はそれ自体が素晴らしいライブラリであることは間違いないが、それ以上に Web やそれ以外のプラットフォーム開発に対する人々の考え方を大きく変えたことが重要だと思う。 React Keynote
2025年10月7日、ReactおよびReact NativeがLinux Foundation傘下のReact Foundationに移行することが発表された。 Introducing the React Foundation -React Introducing the React Foundation: The New Home for React & React Native - Engineering at Meta Introducing the React Foundation pic.twitter.com/lmRyo9ABjB — React (@reactjs) October 7, 2025 Over 10 years ago, we open-sourced React. And now, we’re excited to announce the next cha
2025/01/04 Git Hooks ツールの Lefthook を追記 2025/01/05 フロントエンドの状態管理に XState を追記 各リンクテキストを対象名がわかりやすい形式に変更 概要 以前のプロジェクトで使っていたり、進行中に差し替えまでは出来ないけど次使うならこれを使おうと思っていたライブラリやツールなどが、いざ新しくプロジェクトを作ろうと初期構築を始めたら色々と失念している事ってよくありませんか？ 最近実際それがあり、個別のページにわかれて技術メモはとってあったりするのですが探しながらは手間なのとブクマしただけのものもあるので、インデックス的に手軽に気になった技術をメモっておく見ながら構築したり技術選定の前段階に使うようなノートを作ったので誰かのお役に立つかもと公開してみます。 気軽に雑にメモるのを前提に作ったものをそのまま公開しているので文体等は統一されてません
SaaS の管理画面を開発していると新規作成画面と編集画面を実装することがよくあります。 これらの画面は一見似ているので共通のコンポーネントで実装できそうですが、意外と多くの違いがあります。 この記事では新規作成画面と編集画面を実装するときに気をつけていることをまとめてみます。 コンポーネント設計について シンプルな例でも新規作成画面と編集画面には違いがありました。 これらを1つの共通コンポーネントで実装するとコンポーネント内でIF分岐が発生し可読性が下がったり、再利用性が低くなったりします。 では両者を完全に別コンポーネントで実装したら良いのかというとそれも微妙です。新規作成、編集の入力項目は仕様的に同じであり、バリデーションも同じであることが多いです。 ここを別に実装してしまうと仕様が変わったときに変更する箇所が多くなってしまいます。 なのでフォーム部分(入力とバリデーション)は共通化
![[React] 新規作成画面と編集画面の実装で気をつけていること](https://cdn-ak-scissors.b.st-hatena.com/image/square/985879d0df0076ca306c96492183e0dffad400f7/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--NYsUL-XL--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BReact%25255D%252520%2525E6%252596%2525B0%2525E8%2525A6%25258F%2525E4%2525BD%25259C%2525E6%252588%252590%2525E7%252594%2525BB%2525E9%25259D%2525A2%2525E3%252581%2525A8%2525E7%2525B7%2525A8%2525E9%25259B%252586%2525E7%252594%2525BB%2525E9%25259D%2525A2%2525E3%252581%2525AE%2525E5%2525AE%25259F%2525E8%2525A3%252585%2525E3%252581%2525A7%2525E6%2525B0%252597%2525E3%252582%252592%2525E3%252581%2525A4%2525E3%252581%252591%2525E3%252581%2525A6%2525E3%252581%252584%2525E3%252582%25258B%2525E3%252581%252593%2525E3%252581%2525A8%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_34%3Akult%252Cx_220%252Cy_108%2Fbo_3px_solid_rgb%3Ad6e3ed%252Cg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzhhNDQwNmNlMGUuanBlZw%3D%3D%252Cr_20%252Cw_90%252Cx_92%252Cy_102%2Fco_rgb%3A6e7b85%252Cg_south_west%252Cl_text%3Anotosansjp-medium.otf_30%3AAI%252520Shift%252520Tech%252520Blog%252Cx_220%252Cy_160%2Fbo_4px_solid_white%252Cg_south_west%252Ch_50%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzhkZmY1MjcxNzUuanBlZw%3D%3D%252Cr_max%252Cw_50%252Cx_139%252Cy_84%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png%3F_a%3DBACAGSGT)
このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。 ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。 全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。 内容としてはRailsアプリ
本日のデモ： 本日のソースコード： おっと、待たせたねぇ！今日は「DuckDB-Wasm」と「DuckDB-Spatial」についてご案内いたしやすよ！ この記事を読めば、ブラウザだけで地理空間情報の分析をサクッとこなせすための環境構築や、便利な関数を使った地理空間情報分析の基本がバッチリわかるって寸法よ！これを知っときゃ、サーバーいらずで本格的な地理空間情報分析ができちまうし、つまずきやすいポイントもスッキリ解消！あんたもいますぐ地理空間情報分析の達人になれるこたぁ間違いなしだ！さぁ、江戸っ子の心意気で、いますぐその手で試してみな！ Vite.js + React でやんでぇ！まず、Vite.js + React + TypeScriptを開発環境の基板とするってのは、問答無用で決まりだ！ほかにゃ選択肢はねぇってわけよ。Viteの速さ、Reactの使いやすさと豊富なライブラリのエコシステ
はじめに 私は今、CSVエディタ SmoothCSV 3 を開発しています。フレームワークとして Tauri を採用しており、レンダラーにはWebの技術（React + TypeScript）を使っています。 CSVエディタは大量の行・セルを表示する必要がありますが、Webの技術ではこのようなシーンではバーチャルスクロールを使うのが定石です。 SmoothCSVでもバーチャルスクロールを使っていましたが、どうやらこのバーチャルスクロールにも限界があるらしく、数百万行のような極端に大量のデータを表示する場合に最後まで表示しきれない問題に遭いました。 ここではバーチャルスクロールの基本と、その限界をどう乗り越えたかを紹介します。 About Me 株式会社ヘンリーでソフトウェアエンジニア & アーキテクト的なことをしつつ、個人開発してます。 Social accounts: kohii on
Previous slideNext slideToggle fullscreenOpen presenter view Rails vs Node.js 最終章 「Prisma」 @mizchi Cloudflare Meetup 2024/10/02 今日の Prisma + Cloudflare の様子 About https://x.com/mizchi Node.js とフロントエンドの専門家 100万円*達成率で御社のフロントエンドの高速化をやります 前書き フロントエンド/Node.js 視点のポジショントークです Railsに対するチャレンジャーとして Node.js を使ってきた話 Rubyの開発者やRubyのユーザーを否定する意図はありませんが、好き嫌いは否定しません。型が好きです 「Rails」は 2010年前後に流行っていた任意なWAFに置き換え可能 Symfony
先日 続・URLシェアを支える技術 CompressionStream という記事をZennに投稿しました。 この記事のためにlz-stringとCompressionStreamの圧縮率を比較できるサイト(以下比較サイト)をVite+Reactで作りました。 このサイトでは、入力してもらったテキストをURLに反映して、入力状態をそのままシェアできる機能を実装しています。TypeScript PlaygroundやReact Compiler Playgroundのような感じです。 例えば次のようなURLをシェアすることができます。 https://stinbox.github.io/lz-string-vs-compression-stream?source=eJx73Nj0uHHV48b5jxvXKxSXZObpJuXkpys8blz3uHnV4-bNj5vWP26a9GJH_-Omy
※ この記事はUdemyメディアにも掲載されています。下記のリンクよりお読みください ▶️ 独力でWebサービスを開発・構築できるフルスタックエンジニアへのロードマップ─幅広いスキルをUdemyで学ぶ！ ※ Udemy「夏のビッグセール」とはてなによるプレゼントキャンペーンは終了しました。記事で紹介しているフルスタックエンジニアのスキルは、引き続きUdemyの講座で学習できます。 Webで新規サービスを立ち上げる際に、UIからインフラ周りまで一人で面倒を見られるエンジニアは、少人数のスタートアップでなくとも非常に頼れる存在です。どんな課題に直面しても技術力で乗り越える、そんなスキルフルなエンジニアに憧れる方も多いでしょう。 この記事では、フロントエンドのプログラミング（JavaScript周辺）からサーバーサイド、インフラ、さらに開発手法まで、Web開発で必要になるさまざまなレイヤーのフル
そもそもDOMとは？ 仮想DOMについて知るためには、まずDOMについて知っておく必要があります。 以下の動画で、DOMについて100秒で解説しているので、そもそもDOMをよく知らないなぁという人はぜひ確認してみてください！ 仮想DOMとは？ では、本題です。 仮想DOMとは、UIの "仮想" 的な表現をメモリー上に保持して、実際のDOMと同期させるというプログラミング上の概念のことです。 仮想 DOM (virtual DOM; VDOM) は、インメモリに保持された想像上のまたは「仮想の」UI 表現が、ReactDOM のようなライブラリによって「実際の」DOM と同期されるというプログラミング上の概念です reactjs ...と言っても、これだけだとちょっと難しいですよね。 なので、仮想DOMについて解説する前に、まずはDOM操作とレンダリングの関係について先に解説します。 DOM
個人開発を7年以上続けて分かった技術選択のコツInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切って
目次 CSS小史 SUIT CSS - 命名規約ベースのCSS方法論 styled-components - CSS in JS Tailwind CSS - Utility-first CSS なぜインラインスタイルではダメなのか まとめ タイムライン 参考リンク CSS小史 CSSでアプリのUIを実装するための手法は、これまでいくかの変遷を辿ってきた。 はるか昔、CSSが生まれて間もないころには、関心の分離という文脈から、FONT要素などの物理タグはよくないものとされ、 コンテンツ(HTML)とスタイル(CSS)をきっちりと分離することが奨励されはじめた。 そこでは、HTMLはあくまで文書であり、CSSのクラスセレクタという接点でコンテンツと見た目が隔離されることで、それらは別世界のものとして管理されていた。 また、大規模サービス開発においていかにCSSを管理するかという問題意識はまだ
JetBrains は過去 7 年間にわたり、変化し続ける開発者の状況と使用されている主要テクノロジーを関連付けるために開発者エコシステムアンケートを実施してきました。 その結果は生データと分析レポートの両方の形式でコミュニティと共有され、すべての関係者がこのエコシステムの状況を把握できるようになっています。 本日は今年の調査結果を JavaScript と TypeScript に焦点を当てて確認したいと思います。 アンケートの概要 2023 年の開発者エコシステムアンケートでは、世界中の 26,348 人の開発者からインサイトを収集しました。 このアンケートの結果を自分で確認し、プログラミング言語やツール、テクノロジーから回答者に関する有用な情報や豆情報に至るまで広範なトピックを網羅した情報を入手できます。 私たちは開発者独特のライフスタイルにも注目し、その情熱や興味を明らかにする予定
かなり昔に Elasticsearch ベースの検索システム（Heineken）を作っていた。 Elasticsearch で部内 Wiki 検索高速化 - Speaker Deck 特に更新せず数年動かしていたのだけど、サーバーの置き換えに伴って Kubernetes に置きたいよねという話になり、ついでに Elasticsearch も新しくしたいよね、となった結果、現状のフロントエンドだと最新の Elasticsearch では動かないということがわかった。 nonylene.hatenablog.jp フロントエンドの改修が必要なわけだが、ここでフロントエンドの構成を見ると… FlowType create-react-app PureComponent Bootstrap 3 古すぎる！絶対アップデート難しいし触りたくない技術しかない。 フロントまわりの構成を変えたいとずっと思っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
