はてなブックマーク

はじめに 実は...みんなが今使っている Chrome、実はもう AI が入ってるんですよ。API キーなし、0円 の Gemini Nano というローカル LLM が組み込まれていて、Prompt API を使えば JavaScript から数行で呼び出せます。 日頃から Claude Code や Codex で「生産性や開発速度を爆上げしたぜ！」「こんなすげぇ使い方してんだぜ！」という記事をよく見かけます。 いやぁーいい話です！うらやましい！ ただ自分は慢性的な金欠状態なので、月額課金をポチる指が動きません（昨今は物価高ですしね...) ちょうど、自分にはこんな悩みがありました。 PC 間で、Chrome 標準機能以外の方法でブックマークを共有したい リポジトリや技術記事は英語なので、ぱっと見なんのブックマークか分からない ブックマークが全く整理できない リンクはどんどん溜まってい

ラーメン二郎を知らない人のために3行で説明する。 圧倒的なボリュームと中毒性で信者を生む店であること。 「直系」と「インスパイア系」という店舗の系譜文化を持つこと。 客が自分好みにカスタムする文化があること。 この3つの構造が、2025年から2026年にかけて、AIコーディングエージェントの世界でそっくりそのまま再現された。 この記事を書いた動機 理由は単純で、この1年の変遷が面白すぎたからだ。 一人の開発者が$24,000を溶かして作った拡張が、界隈の必需品になる。公式に締め出されて、すべてが終わったかに見える。それでも作る人たちは消えず、別の場所で同じ思想を復活させ、最後には公式までがその設計を取り込む。無名の作り手たちが逆境をくらって、それでも技術で巻き返していくのを追いかけながら「これ、プロジェクトXじゃん...」とずっと思っていた。頭の中で中島みゆきが流れてもおかしくない展開であ

はじめに 皆さんはWEBサービスの収益化に取り組んだ経験はありますか？サービスを作ること自体も大変ですが、収益化はさらに難しいと感じる方も多いのではないでしょうか。この記事では、私がWEBサービスの収益を最大化するために試したことを書きます。誰かの参考になれば幸いです。 どのようなサービスを収益化したか サービス内容 私が株式会社ソニックムーブに入社する前は、個人でWEBサービスを運営しており、そこから収益を得て生活しようと奮闘していました（結局、収益は出ていたものの生活できるレベルには及ばず）。そのWEBサービスというのが、以下の「THE TOURNAMENT」というサービスです。 サービス内容はシンプルで、WEB上で簡単に、美しいトーナメント表・リーグ表、スイスドロー表を作成できます。 技術スタック 技術スタックは以下のような感じです。 フロントエンド：React（Next.js） 認

はじめに 最近、AIコーディングエージェントを複数同時に動かして開発している。 実装は Claude Code に頼む。 調査は Gemini CLI に投げる。 別のリポジトリの確認は OpenCode にお願いする。 ついでに、エージェント実行環境の pi や jcode に細かい雑用を任せる。 確かに便利だ。 ただ一つ不満がある。しばらく経つと、誰が何をしているのか自分でも分からなくなる。 ターミナルが 5 枚並んでいて、どれが本命か思い出せない。Claude Code は止まっているのか、考えているのか、詰まっているのか、もう終わっているのか、画面を見ても瞬時には判断がつかない。 正直に言うと、AIが賢すぎるというより、私の管理能力がぜんぜん追いついていない。 そんなことを考えながら作っているのが、cuekit という小さなAIエージェント開発基盤だ。 cuekit は、複数のAI

自分が使ってるプロバイダーだけ対応すればいい。これがAI時代のツール作成だ。 技術スタック 主な技術スタックはこんな感じ。 React 19 + Mantine v9 — UIコンポーネント Vercel AI SDK v6 — マルチプロバイダー対応の要。ストリーミングもこれ Zustand — 状態管理 Chrome Extension APIs — Side Panel, UserScripts, Debugger... TypeScript 6 Vite+ 私はChrome拡張を作ったことがなかったが、やりたいことを実現しようとするとかなりの知識が必要だった。Service Worker、Content Security Policy、サンドボックスでのコード実行、メッセージパッシング・・・Chrome拡張の世界は思った以上に奥が深い。 とはいえ、一番驚いたのは技術選定そのものでは

2026年5月3日(日) 僕は、子ども達と一緒にインディゲーム展示会 「東京ゲームダンジョン12」 に出展します。 出展するゲームは、3つ。 僕：「Slime Ten Puzzle」 長男：「人狼を基盤にした推理ゲーム」 次男：「SCPをモチーフにしたアクションゲーム」 ……ここまで書いて、少し不思議な気分になります。 この未来は最初から決まっていたわけじゃなくて、たった一言から始まったからです。 ある日、子どもに聞かれた 「お父さん、ゲーム作れるの？」 当時の僕は、会社でキティちゃんやドコモダケなどのIPを利用した、ネイティブアプリ・Webソーシャルゲームなどの開発をしていました。 だから当然、胸を張ってこう答えるつもりでした。 「作れるよ！！」 ……ところが、言葉が喉で止まった。 あれ？ 本当に作れるの？？ 「作れる？」じゃなくて「今、作って見せられる？」 会社のゲーム開発は、チームで

Bun を選んだのは、TypeScript をそのまま実行できるのと、起動が速いから。タスクランナーは頻繁に呼び出すものなので、起動速度は重要だ。 バイブコーディングの道具 開発には OpenCode と pi を併用した。 OpenCode はコード生成に特化しており、初期実装やボイラープレートの生成で力を発揮してくれた。一方 pi はコードの意図を理解するのが得意で、リファクタリングや設計の見直しで重宝した。両者を使い分けることで、スピードと品質を両立できたと思う。 自作オーケストレーター ...と、ここまで書くと「2つのエージェントを手で切り替えながらコーディングしていた」ように聞こえるかもしれないが、実態はもう少しカオスだ。 最近の流行りに乗って、GitHub Issue を投げたら勝手に実装して PR まで出してくれるオーケストレーターを自作して使っている。 仕組みはこうだ： G

はじめに 株式会社ソニックムーブのmito1111です。 近年、コーディング自体をAIに任せる「Vibe Coding」が広く普及し始めています。 多くの開発者がAIを活用してコードを生成するようになりましたが、開発のトリガーとなるissueやチケットを作成したり、修正内容をまとめたプルリクエストを作成する部分については、まだ手動で行っているケースが多いのではないでしょうか。 今回は、GitHub Copilot CLIのSkills機能を活用することで、issueの作成からプルリクエストの作成までをシームレスに実現する方法をご紹介します。 本記事で紹介する内容はまだ試作段階ではありますが、実際の案件に適用してみた結果、特にbugfix系の開発スピードが大幅に向上することを確認できました。 最近はコーディングよりもプロンプトを書く割合が圧倒的に多くなりましたが、開発体験としては非常に良いも

こんな経験ありませんか？ Claude Code で長めのタスクを回していると、こんな確認が何度も出てきますよね😅 Do you want to proceed? ❯ 1. Yes 2. Yes, and don't ask again for: ... 3. No 「毎回 Yes を押すのが面倒だから…」と --dangerously-skip-permissions を使ったことがある方、少なくないと思います。 このフラグ、名前からして怖いのですが、Anthropic も公式に「リスクが高い」と明言しているやつです。それでも使ってしまうくらい、承認ダイアログが邪魔に感じる場面があるのも事実です。 そんな悩みを解消してくれる Auto Mode が、Claude Code にリサーチプレビューとして登場します！ Auto Mode とは？ Auto Mode は、Claude がパーミ

知人の話などから移行したいとは思っていたものの、 最近は仕事ではIDEでの開発が多くVimを使い込む機会もそこまでなく、騙し騙しVimを使い続けてしまっていました。 いい加減そろそろかなと思い年末年始の休みを利用して移行したのでざっくりまとめます。 移行したプラグイン・所感 plugin manager dein.vim -> lazy.nvim 遅延読み込みもそうですが、プラグインごとの設定を構造的に管理しやすくなったことに意義を感じています。 syntax系 vim-polyglot -> nvim-treesitter tree-sitter製のパーサの管理・Neovimへの統合をしてくれるプラグインです。 syntax highlightingのためだけでなく、抽象構文木に対する操作全般を強力にサポートしてくれます。 nearleyというパーサジェネレータのsyntax(vim-n

Claude Codeで開発していると、PRレビューのときに「この差分、どの指示から出てきたんだっけ」となることが増えてきました。3日前の自分のPRですら判断の経緯が思い出せない。人間が書いていた時代ならコミットメッセージに意図を残せばよかったのですが、AIとの対話で生まれたコードだと意図が会話ログに散ってしまいます。 そんなときにSNSで Entire CLI を見かけました。AIとのセッションをコミットに紐付けて記録してくれるツールで、これなら解決できそうだったのでとりあえず触ってみました。 レビューはどう変わるか 差分に意図がつく たとえばPRで、すでに動いていたクエリ処理がごっそり書き換わっていたとします。差分を見れば「書き方が変わった」ことはわかりますが、「動いていたのになぜ変えたのか」は読み取れません。セッションのやり取りを見ると、パフォーマンス改善の相談から始まっていた、とい

概要 2025 年 11 月 18 日、Google より Gemini 3 と同時に Antigravity という AI エディタの発表がありました。 Antigravity の主な特徴は、Editor と Agent Manager という 2 つの大きなウィンドウで構成されていることです。開発者は Editor で従来の AI アシスタントやサジェストを活用した開発を行いながら、バックグラウンドでは Agent Manager を用いて各ワークスペースでのエージェントのタスク実行を非同期に行えるようになっています。 Editor は VS Code を fork した馴染みのある画面となっており、既存の開発環境からスムーズに移行できる設計となっています。一方、Agent Manager は全く新しい画面で、エージェントオーケストレーション用として設計されています。開発者は各 Wor

はじめに 今回は、軽量Webフレームワーク Hono を AWS Amplify Gen2 にデプロイする方法を紹介します。 Amplify Gen2はNext.jsが有名ですが、Honoのような軽量フレームワークとAmplifyの強力なBaaS（AppSync, Lambda）を手軽に組み合わせる方法を実証します。 技術スタックと構成 フロントエンド (SSR): Hono + JSX フロントエンド (UI): Alpine.js （軽量なインタラクティブUIのため） バックエンド (BaaS): Amplify Gen2 （AppSync + Lambda） データフロー: Alpine.js (UI) → Hono (APIルート) → Amplify Client → AppSync → Lambda 作成したアプリケーション HonoのSSRでページを描画し、Alpine.js

はじめに PHPでの開発において、コードの品質を高く保つことは、プロジェクトの成功に欠かせない重要な要素です。 これまで、コードフォーマッタ、リンター、静的解析といったツールは、それぞれ別のものを組み合わせて使うのが一般的でした。しかし、今回ご紹介する Mago は、これらの機能をたった一つに統合した、PHP界に現れたちょっと革新的なツールチェーンです。 私自身、普段のPHP開発では、次のようなツールを愛用していました。 PHPStan: 頼れる静的解析ツール PHP-CS-Fixer: コードを美しく整えるフォーマッタ これらのツールに大きな不満はなかったのですが、心のどこかで「静的解析、もう少し速くならないかな…」「ツールの設定がバラバラで、ちょっと面倒だな…」と感じていたのも事実です。 そこで今回は、最近注目を集めている Mago という、Rustで書かれた爆速PHPツールチェーンを

はじめに 中長期的なプロジェクトにおいてAIを用いた開発を行うには単純なプロンプト以外にルールの設計が必要です。 現状、自分の知る限りでは、ルール設計はまだ十分に確立されておらず、効果がどれほどあるかも定かではありません。 ただ、実務に活用できればさらに効率的に開発できると思うので、ルール設計の調査と検証を行ってみました。 ルールとは？ ルールとは、プロジェクト特有の情報をAIエージェントに自動で読み込ませるためのカスタムコンテキストファイルです。これにより、チャットプロンプトで毎回同じ指示を繰り返す必要がなくなります。 GitHub CopilotならCopilot Instructions、CursorならProject Rulesがそれにあたります。 メリット： プロジェクト固有の知識を共有： デザインパターンやフレームワーク、コーディングルールをAIが理解できるようになります。 生

はじめに PHPフレームワーク戦国時代に、また一つ新たな風が吹きました。その名もTempest（嵐）。名前からして何やらすごそうですが、果たしてその実力は？ この記事では、この新進気鋭のPHPフレームワークTempestを使い、簡単なアプリ作成からデプロイまで、その魅力と実力を探っていきます！ Tempestって何者？ 公式ドキュメントから抜粋 Tempestは、PHP開発のためのフレームワークで、開発者の邪魔にならないように設計されています。その核となる理念は、フレームワークに煩わされることなく、アプリケーションコードに集中できるようにすることです。 なるほど...？つまり、LaravelやSymfonyのような「至れり尽くせり」なフルスタックフレームワークが時に課してくる"お作法"や"独自ルール"から解放され、もっと自由に、もっとピュアなPHPでアプリが作れる...ということでしょうか

はじめに こんにちは、原です 🐐 少し前に Figma MCP（非公式）の Figma-Context-MCP が話題になりましたね そして 2025 年 6 月 4 日、ついに Figma 公式の MCP サーバー がベータリリースされました 🚀 早速試してみたので、セットアップ周りや使い方、使ってみた所感などをお伝えします！ Dev Mode MCP サーバー Figma 公式の MCP サーバーは Dev Mode MCP サーバー と呼ばれているようです 以下は Dev Mode MCP サーバー お披露目時のブログ記事です 誤解を恐れずに言うと、Figma と AI を連携し、効率よく開発を進められるようになるツールですね ✨ セットアップ 詳細は公式を確認していただくとして、軽くまとめておきます！ 1. MCP サーバーを有効にする Figma Design ファイルのメニ

フロントエンド及びバックエンドがTypeScriptである場合の設計例を紹介したい こんにちは！sonicmoovエンジニアのchiakiです。 本記事では、 REST APIで使用されるデータモデルやパラメータ定義 APIエンドポイントのメタ情報 といった内容をOASではなくTypeScriptで一元管理するために、@asteasolutions/zod-to-openapiを使用した設計例を紹介したいと思います！ ディレクトリ構成 今回はお問い合わせフォームや一覧といった画面を想定しています。FEとBEがともにモノレポで管理され、packagesディレクトリ配下にschemaディレクトリがあるという構成になります。 └── schema/ ├── constants/ # 定数や型定義をまとめる │ └── contact.ts ├── models/ # DBやレスポンスのモデルスキ

Create React Appが公式で非推奨となりました 2010年代の後半から長らくReact環境構築のデファクトとなっていた% create-react-appですが、先日（2025-01-29）に公式で非推奨となりました。 2016年頃に、webpack(+dev-server, style-loader), Babel, ESLintといったモダンフロントエンド開発で必須となる静的解析ツール+コンパイラの環境構築を誰でも簡単に構築できるようFacebookから公開されたのが初めてで、現在は アクティブなメンテナが不在であること 各フレームワークなどでそれぞれ環境構築が提供されていること といったような理由から非推奨となったようです。 今回は、これからの代替となりそうなフレームワークやライブラリのおさらいを改めて行いたいと思います。