はてなブックマーク

先月、東京AI祭 ハッカソンで、スマホでバイブコーディングして、賞金20万円を獲得しました。 何をどんな仕組みで作ったのか実践知を共有したいなと思います。 東京AI祭 ハッカソンは、CoreWeaveさんが公式サポーターで、GMOさんのサポートもあったようでした。Weights & Biasesについて気軽に質問したり、H100などのGPUを自由に使い倒すことができる環境でファインチューニングしたり、とても楽しい時間でした。 ハッカソンのファイナリストでは、普段から刺激をもらっている npakaさん や 元木さんを目の前にピッチできることは特別な経験でした。 改めて運営・スポンサーの皆様に感謝したいと思います。 現場検証から生まれたバイブコーディングの発想 現場の声から始まった 「JR新宿駅は工事に伴い、凹凸のマットが敷かれ、白杖で点字ブロックを探しても感触がわかりにくい」 「時間帯次第で

はじめに インテグレーションテスト主体でテストを書いていく場合、テスト実行時間が長い問題が出てきた。 （インスタンスをたくさん並べてパラレル実行にするとかやりようはあると思う） 解決するためには出来る限りユニットテストに寄せた方が良いが、どういったコード構成ならユニットテストに寄せやすいのか？考えた。 今あるアーキテクチャから選べばいいじゃんという話もあるが。。。 既存アーキテクチャだとなんかしっくりこないのでしっくりくるのを考えてみた。 全部に当てはまる正解はないので、自分の関わってきたシステムを振り返り、それらを踏まえて考えてみる。 実際に本番稼働していたシステムを元に考えるので本番稼働できるものにはなると思う。 あくまで自分基準での話にはなるので過度な期待はしないでください。 自分のWeb開発はJavaからスタートした話 日立のJP1Scriptが最初の仕事だったけど、Webシステム

Claude Codeはより長大なコンテキストを扱える点が強みであり、大規模なプロジェクトに適している。一方Codexは実装スピードとUIの統合性に優れる。 とされている。 開発条件と設計 Todoアプリの要件 ブラウザで動作するWebアプリ Todo一覧（タイトル表示）、詳細（本文・日付表示） 新規登録・更新・削除が可能 技術スタック フロントエンド：Next.js（TypeScript）＋Shadcn＋TailwindCSS 状態管理：Zustand バックエンド：Hono（TypeScript） DB：PostgreSQL 開発環境：Docker＋docker-compose ビルドツール：pnpm（corepackで対応） セットアップ：makeコマンドでマイグレーション等を自動化 これをChatGPTに読み込ませて仕様書を作成、それを各AIツールにコピペして実装をしてもらう。 C

🚀 はじめに このチュートリアルでは、OpenAIの最新モデルGPT-OSS 20BをGoogle Colab L4 GPU（22GB VRAM）でファインチューニングする方法を解説します。UnslothライブラリとLoRAを使用することで、効率的にモデルを訓練できます。 <div class="align-center"> <a href="https://unsloth.ai/"><img src="https://github.com/unslothai/unsloth/raw/main/images/unsloth new logo.png" width="115"></a> <a href="https://discord.gg/unsloth"><img src="https://github.com/unslothai/unsloth/raw/main/images/Dis

はじめに 最近LLMコーディングエージェント(主にCodex)tipsを書きましたが、やっぱりLLMコーディングエージェントは頼りにしすぎてはいけない、重要なところは自分で書こうという思いが強まってきています。 どういうとこが変なのかをまとめることで、なぜそう感じるのかを説明したいと思います。 1. 引数のバリエーションが無駄に多い 一箇所からしか呼ばれていないメソッドで現状の呼び出し箇所は引数にidしか渡していないにも関わらず、コードの他の部分も参照して勝手にentry_idでもticket_idでも渡していいようなメソッドにしてしまう。。 一見問題なさそうですが、このフィールドを誰が参照しているんだっけ？と調べる時に余計な箇所もヒットしてしまい、そのフィールドを使って処理することに対するハードルがあがってしまうし、単に可読性も悪くなりバグの温床にもなります。 通常のメソッド呼び出しであ

「〇〇、なぜお前が至高の領域に踏み入れないのか教えてやろう」 「経験不足だからだ、視野が狭いからだ、品質への意識が低いからだ」 「ライブラリを作ろう、〇〇」 「そうすればプロダクションコードと独立したフィールドで経験を積める、強くなれる」 「そして、俺とどこまでも高め合おう」 「その資格がお前にはある」 閑話休題 はじめに 本業でiOSアプリエンジニア、趣味でmacOSアプリ開発をしているKyomeと申します。 業務でも個人開発でも必要性に迫られてライブラリの開発をしてきました。 そこで最近、一歩踏み込んだ強いエンジニアになる近道として「ライブラリ開発」が最適なんじゃないかと思い至ったので、その魅力をざっくり紹介したいと思います。 1. プロダクションコードと独立した小さいスコープでの判断経験を積める プロダクションコードは巨大かつ複雑であったり、特定のアーキテクチャ特性による制約があった

minioがビルド済みバイナリとDocker imageの提供を停止してしまったのでローカル(CI)でテストするためにminioを使っていたところもどうにかしたい。 要件 CI で S3 にアクセスするコードのテストをする S3 API で基本的な操作ができればよい bucketやobjectの読み書きぐらい versitygw というのを見つけたのでそれで試す。 Use Cases Turn your local filesystem into an S3 server with a single command! Proxy S3 requests to S3 storage Simple to deploy S3 server with a single command Protocol compatibility in posix allows common access to f

背景 Claude Codeサービス提供以来ずっと下記の理由で大好きでMaxプランを利用して、一緒にたくさんの価値を創りました。 Claude Codeを好きな理由 1. Default状態でアウトプットの質が高い 依頼Prompt以外、何にも用意しない状態で相談することで、専門家レベルの議論ができます。 Knowledge-baseやCLAUDE.mdちゃんと用意すれば、意図した通りcodingができます。 2. 仕事が早い thinkがあっても体感的に速い動きができています。 3. モデル性能と機能面最先端 Sonnet3.5から今最新の4.5までcoding領域のモデル性能が最強。 機能面もMCPからSubAgent、最新のSkillまで業界の提案者であり、豊富でした。 一方、最近自分自身とチーム全体でClaude Codeの利用からCodexに移りました。 その理由と過程及び（現状

NVIDIA DGX Sparkの概要 NVIDIA DGX SparkをNVIDIA様から貸与いただきました。NVIDIA DGX Sparkは、手のひらサイズでペタFLOPS級性能を持つ「超小型AIスーパーコンピュータ」です。AI用のスーパーコンピュータであるDGXシリーズ（DGX-1→DGX A100→DGX H100など）の系譜を組みながら、手軽にデスクトップで使えるようにした存在です。 前置きはさておき、やっぱり気になるのは実際の使い勝手、何ができるのか、性能といったことですね。この記事では、NVIDIA DGX Sparkのセットアップの方法と、大なモデルのLLM(gpt-oss-120b)や画像生成を試してみるところまでをやってみたいと思います。 セットアップに関しては、NVIDIA提供の公式のマニュアル、ソフトは大いに参考・活用していますが、一部私の好みで変更しているものや

データの世界に携わる皆さんなら、「データウェアハウス（DWH）の自動化」という言葉を何度も耳にしてきたことでしょう。日々のETLジョブのスケジューリング、リソースの自動スケーリングなど、私たちは「自動化」によって多くの定型業務から解放されてきました。 しかし、今、BigQueryはその一歩先、「自律性（Autonomy）」 を持つDWHへと急速に進化しています。 これは単なるバズワードではありません。「自動化」と「自律性」は、似ているようで根本的に異なります。そしてこの「自律性」こそが、データに関わる全ての人々の働き方を根底から変える力を持っています。 本日は、BigQueryが目指す「自律型DWH」とは何か、その具体的な機能、そしてそれが私たちの未来に何をもたらすのか、詳しくご紹介します。 🤖 「自動化」と「自律性」：決定的違いとは？ まず、この2つの言葉を整理させてください。 自動化

はじめに 世の中ではしばしば、情報を「氷山」に例える比喩が使われます。水面上に見えているのはほんの一部であり、大部分は水面下に隠れているという構図です。この考え方は、機密情報を氷山の下に、公開情報を上に置き、見えない部分こそが価値の本質だとみなす発想に結びつきます。 しかし実際の社会では、価値を生むのは「隠された情報」そのものではなく、「見えている情報をどう扱うか」です。つまり、公開情報の読み解きと運用こそが実務で決定的に効きます。 本稿では、なぜ公開情報が機密情報以上に重要なのかを、情報構造・知識形成・理解力という観点から論じ、氷山の上に見えている部分こそが社会における知的競争力の源泉であることを明らかにします。 公開情報の価値は「誰でも理解できる」ものではない 多くの人は「公開されている情報＝誰でも理解できる」と誤解しています。しかし実際には、公開情報を活用できる人は限られています。た

背景と目的 Claude Code が ver.1.0.0 になってから 5 ヶ月、弊社が全エンジニアに展開してから 3 ヶ月が経過しました。 その中で生産性が上がった人とそうでない人が明確に分かれていたり、新たな大変さが生まれてフラストレーションも多く抱えています。 Web 開発の現場で LLM 開発を導入することで何に困るのか明確にして次の施策につなげたいと考え、定性・定量の両面からチーム全体の実態調査をしました。 これから LLM 導入を考えている、導入後どうしたらいいか悩んでいる人の参考になれば幸いです。 結論の概要 調査で見えてきたのは、「生産性は確実に上がっている一方で、精神面や学習面での課題も存在している」 という現実でした。 導入後、プロダクト Issue の対応数は目に見えて増加し生産性は向上したように見えます。 しかし定性意見では、プラス面ばかりではなくマイナス面も見え

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 個人的なミッションとして ”SRE AI Agent” を開発し本番運用させることを掲げています。 "SRE AI Agent" とは、SRE（Site Reliability Engineering）業務を支援するための自律的 AI エージェントです。 このエージェントは、システムの監視、障害対応、パフォーマンス最適化などのタスクを自動化し、SRE チームの負担を軽減することを目指しています。 SRE AI Agent の本番運用化はとても恩恵が大きな取り組みです。 運用自動化・半自動化を人間の手をかけることなく実現することはまさに "No human labor is no human error" の精神にかなっています。 Spec Kit とは S

はじめに GitHub Actions (GHA)、便利ですよね。 便利なんですが、じゃんじゃん作るとワークフローが増えてエラいことになりませんか？私はなりました。 環境ごとに似たようなワークフローが乱立し、保守が大変 変更を加える際、複数のファイルを修正する必要がある ワークフローの構造がアプリケーションごとに異なり、認知負荷が高い そもそも数が多すぎて何が何やら... GHA は特にこう構成すれば良い、みたいなプラクティスやフレームワークが無いので、リポジトリの規模が大きく複雑いなってくるにしたがい、GHA も複雑になってしまいがちだと思います。 本記事では、そのような状況から脱却するべく、 3 層アーキテクチャ を採用してリファクタリングした事例を紹介します。 対象読者 GitHub Actions を使い倒している方 割と大きめな規模の GitHub Actions を構成している

デイリースタンドアップ、スプリントプランニング、レトロスペクティブ。スクラムのフレームワークは完全に導入した。チームは毎日15分のスタンドアップをしているし、2週間ごとにふりかえりとカイゼンアイテムの特定をしている。でも、何かが違う。現場は相変わらず「忙しい」と言い続け、部門間の壁は高いままで、意思決定のスピードは上がらない。 アジャイルやスクラムを始めたばかりのチームや組織において、このような状況に心当たりがあるのではないでしょうか。問題は、フレームワークそのものではありません。 ここで私たちが直面しているのは、技術的課題と適応課題を取り違えているという、より根本的な問題です。 技術的課題と適応課題 この概念は、ハーバード大学のロナルド・ハイフェッツ氏が提唱したリーダーシップ理論に基づいています。 技術的課題 問題が明確で、解決策がすでに存在する 専門家が答えを持っている 既存の知識やス

Next.jsのドキュメントやQiitaなどでは、URLの末尾に .md を付けるとページ内容を生のMarkdownで取得できます。AIエージェントにコンテキストを渡したり、別クライアントから取り込んだりするのに便利なパターンです。 この記事では Rewrites + Route Handlers（App Router） で、/post/hello はHTML、/post/hello.md は text/markdown を返す“二刀流配信”を実装します。 前提 Next.js 16.0.0 (App Router) React 19.2.0 Markdownでコンテンツを管理している 動作イメージ /post/hello-world -> 通常のWebページ (HTML) /post/hello-world.md -> Markdownがレスポンスされる Demo GitHub ディレク

とにかく競合しがちな3000と8000 複数の開発のお仕事を頂いて対応していると、このポート競合に悩まされてしまうということがよくあります。まあその時立ち上げるcomposeの環境を一つだけに限定すればいい、という話ではあるのですが、AIコーディングが常用化された今の環境化では平行に開発できないと辛いというのが実情なわけです。 大体の現場は、並行で開発をしないといけないタイプのエンジニアのことは特に考慮してくれません。故に3000番ポートというある意味Web開発デファクトみたいなポートはくっっっっっそ被ります。8000番も同じくよく使われるものなので、これをまあ被る。いちいちcompose.yamlのポートを手動で書き換えれば一応解決はしますが、変更をgitのステージ状態のまま持ちたくないというのが心情ですね。間違ってコミットする事故も生まれますし。 Mac限定にはなりますが、ループバック

これまでHonoは数々の新しいことを提供してきました。正規表現を活かしたルーター、サーバーサイドの軽量JSX、TypeScriptの型によるRPC、Web Standardを使ったマルチランタイム対応などなど。アイデアと実装力で世界と戦って来たわけです。 本日私達が紹介するのは「Hono CLI」です。 Hono CLIは全く新しいコンセプトのコマンドラインインターフェースです。 create-* ではありません ただの開発用（dev&build&deploy）のコマンドではありません Viteのラッパーではありません 人間とAIのためのCLIです。インストールすると のようにhonoコマンドを使うことができます。5つのサブコマンドがあります。 hono docs hono search hono request hono serve hono optimize では一つ一つを見ていきまし

こんにちは、とまだです。 Claude CodeやCodexを使ってAI駆動開発を始めてみたものの、「Git コミットのタイミングがわからない」と感じていませんか? AIが数十行、ときには数百行のコードを一気に生成してくれるのは便利です。 ですが、通常の開発とは違い、いつコミットすればいいのか迷いますよね。 AIが作業するたびにコミットすべきか、それとも機能が完成してから？と悩むポイントです。 この記事では、AI駆動開発におけるGitコミットの基本的な考え方から、実践的なタイミング、agents.mdへの記述例まで、初心者にもわかりやすく解説します。 ちなみに私は本業ではフリーランスエンジニア、ならびにAI駆動開発の導入支援を行っており、Udemy で AI 駆動開発講座を複数開講しており、いくつかベストセラーもいただいています。 その経験を活かして、初心者の方でもわかりやすいよう、丁寧に

はじめに Docker Compose を利用して開発環境を構築するプロジェクトは多いと思います。 Claude Code をはじめとするコーディングエージェントの普及により、git-worktree を使って複数の作業ブランチを並行して開発することが増えてきました。Docker Compose で構築する開発環境は、ワークツリーが違えどほとんどの場合同じような構成になるため、ワークツリーごとに環境を立ち上げようとすると、コンテナ名やポートの衝突といった問題が発生します。 SocialDog では、git-worktree を使った開発においても、これらの問題が生じないよう手順をドキュメント化しています。 5環境並列で動かしています 本記事では、私たちが開発で利用している Docker Compose を複数立ち上げても環境を衝突させない構成例 を紹介します。 この記事で書くこと 複数の

Claude Code Web版 - スマホで指示、帰宅後に完成する開発の未来 はじめに 2025年10月20日、Anthropicが「Claude Code Web版」をリリースしました。これまでターミナルでのみ利用可能だったClaude Codeが、ついにブラウザから直接使える時代が来たのです。 筆者は、このweb版を使ってQ-Learningの迷路問題をStreamlitで実装してみました。開発スタイルが大きく変わる可能性を感じる一方で、いくつかの制限や課題も見えてきました。 この記事では、実装を通じて感じたClaude Code Web版の実用性、メリット・デメリット、そしてMCP設定での注意点をまとめます。 対象読者と前提条件 本記事は以下の方を想定しています。 Claude Code（CLI版）の使用経験がある方 Claude Pro / Maxプランのユーザー 開発効率を高め

TL;DR 本記事は、著者自身の振り返りとClaude Codeの分析を通して得た気づきを共有するものです。要点は下記です： Deep Learning時代のEnd-to-End学習の成功体験が、汎用LLM時代では逆に足かせになっているのではないか 汎用性が高すぎるLLMには、むしろ古典的な設計原則（SOLID、関心の分離）が必要 Claude Codeの成功には、LLMの責務を最小化し従来の設計原則を忠実に適用していることが寄与している LLMの責務を減らすことで開発者の責務は増えるが、これは「本来あるべき姿」への回帰 パラダイムは変わっても、ソフトウェアエンジニアリングの基礎原則は普遍的である 0. はじめに こんにちは、sogabe(@sog4be)です。ここ数年、私はいくつかのLLMを活用したアプリケーションを開発してきました。それらを振り返るなかで、うまくいったプロジェクトとそう

Next.js 15とReact 19を使用したWebアプリケーション開発における、実践的な設計方針とベストプラクティスをまとめたガイドを作成しました。 本書では、Next.js 15 / React 19を活用したモダンなWebアプリケーション開発における設計方針を、実装観点ごとに整理しています。App Routerを前提とし、ディレクトリ構成、コンポーネント設計、データ取得、データ更新、状態管理、キャッシュ戦略、エラーハンドリングといった各テーマについて、具体的なユースケースと実装手段を紹介します。

はじめに はじめまして、hibikiです。株式会社ココナラでプロダクト開発のエンジニアとして働いており、今年で新卒3年目になります。 直近では、開発エディタ「Cursor」の全社導入や「Claude Code」の活用推進といった、AIで開発組織全体の生産性を向上させる取り組みを担当しています。 こうしたAI推進の業務に携わる中で、「AIを中心とした世界で、エンジニアとしての自分の価値、人材としてのポジショニングはどうあるべきか」を深く考えるようになりました。 そんな問題意識を抱えていたタイミングで、すてぃおさんのClaude Code時代のソフトウェアエンジニア生存戦略という記事を拝見し、自分が抱いていた危機感が的確に言語化されていることに、強く共感しました。 皆さんは、自分の仕事、5年後はどうなっていると思いますか？ 生成AIが登場するまで、私たちはスキルアップという名の、地続きの未来を

こんにちは。株式会社EVERSTEELでソフトウェアエンジニアをしている日野原です。 主にフロントエンドを担当しており、技術としてはNext.jsを使用しています。（詳しい技術内容はこちらを参照） 少し前の話になりますが、ゼロからテストを導入したので、その過程や戦略について話していこうと思います。 フロントエンドのテストを検討している方や、テストの運用方法を迷っている方の参考になるかと思います。 Reactアプリにおけるテスト戦略と実践ガイド 一昔前はフロントエンド開発においてテストはあまり重要視されていませんでした。 しかし、フロントエンドの複雑さが増したため、最近ではテストが重要視されており、テストを書くことが求められています。 ただ、なぜテストが必要なのか、どのようなテストを書けば良いのか、どの程度のバランスでテストを構成すべきなのかは、十分に理解されていない場合も多いかと思います。

まえがき vim のカーソル移動…面倒臭いですよね… 特に縦移動 これを補助するプラグイン等はあるのですが、ラベルを付けてそれを認知する必要があったりと、なかなかしっくり来るものが無い印象です それもそのはずで、大体のものは明確な行き先があり、それに対して最小のキー数で移動する事を目標としてるんですよね 自分の場合はそういうのではなくて、 ざっくりこの辺りに移動したいなぁ〜ってのがあって、そこへ大雑把に移動してから微調整みたいな感じなのが多いです マクロとか繰り返しを意識した場合ならまだしも通常時のカーソル移動なんぞ適当でいいし、脳のリソースを使いたくないぜ！のお気持ちです。 特に文字を認識するのが自分にとってコストが高いので、検索をしたり、f/t系の移動で単語の先頭を認識したりといった事はあまりしたくないです。 これは vim を使い初めた頃からそうで、自分のカーソル移動(縦)の変異とし

はじめに Next.js 15とReact 19が登場し、App Routerを中心とした新しい開発体験が標準となってきました。Server ComponentとClient Componentを意識したコンポーネント設計、データハンドリング、状態管理、キャッシュ戦略など、実務で求められる設計判断は多岐にわたります。 筆者は、2023年7月のApp Routerリリース直後から現在まで、約2年に渡りNext.js（v13~15）を使った開発に携わってきました。 実際にApp Routerを使った開発では、情報が少ない中で様々な課題に直面し、最初に挙げたような複数観点での設計や実装判断に迷う場面が数多くありました。 これらの経験を通じて得た知見を体系的にまとめ、同じような課題に直面している開発者の助けになればと思い、今回Bookを執筆しました。 本Bookでは、App Routerの思想に沿

GPT-5による翻訳 dots.ocr dots.ocr: 単一のビジョン・ランゲージモデルによる多言語ドキュメントレイアウト解析 はじめに dots.ocr は強力な多言語ドキュメントパーサであり、単一のビジョン・ランゲージモデル内でレイアウト検出とコンテンツ認識を統合し、良好な読順を維持します。1.7BパラメータのLLM基盤というコンパクトさにもかかわらず、最先端（SOTA）の性能を達成しています。 強力な性能: dots.ocr は OmniDocBench において、テキスト・表・読順でSOTA性能を達成し、数式認識においても Doubao-1.5 や gemini2.5-pro のようなより大規模なモデルに匹敵する結果を示します。 多言語対応: dots.ocr はリソースの少ない言語に対しても堅牢な解析能力を示し、自社の多言語ドキュメントベンチマークにおいて、レイアウト検出とコ