はてなブックマーク

開発者はPeter Steinberger氏。13年間会社を経営してきたベテランソフトウェア開発者で、「プレイグラウンドプロジェクト」としてAIエージェントの探求を始めました。 2026年2月14日、Steinberger氏はOpenAIへの参加を発表し、プロジェクトはオープンソース財団に移管されることになりました。 OpenClawの特徴 🎯 マルチチャンネル対応 一度セットアップすれば、普段使っているあらゆるメッセージングアプリからOpenClawに指示を送れます： メインチャンネル: WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Microsoft Teams、WebChat 拡張チャンネル: BlueBubbles、Matrix、Zalo、macOS、iOS/Android 🤖 「目と手を持つAI」 一般

はじめに 「AIアシスタントを自宅で動かしたい」 そう思ったとき、多くの人は高価なMac StudioやゲーミングPCを思い浮かべるでしょう。しかし、たった10ドルのハードウェアで動作する超軽量AIアシスタントが登場しました。 その名も PicoClaw。 2026年2月にリリースされ、わずか4日でGitHub 5000スターを獲得した話題のプロジェクトです。 PicoClawとは PicoClawは、Goで書かれたオープンソースの超軽量パーソナルAIアシスタントです。 驚異的なスペック 項目 PicoClaw 従来のAIアシスタント

はじめに X（Twitter）で「コーディングが不要になる」というトレンドが話題になっています。生成AIの進化により、自然言語でコードが生成できる時代。確かに、コーディングの「作業」は減っていくでしょう。 しかし、私はこの議論に違和感を覚えます。 なぜなら、エンジニアの本質は「コードを書くこと」ではないからです。 コーディングは「手段」であり「目的」ではない そもそも、私たちエンジニアは何のためにコードを書いているのでしょうか？ ユーザーの課題を解決するため ビジネスに価値を提供するため 誰かの「不便」を「便利」に変えるため コードは、これらを実現するための手段の一つに過ぎません。 包丁がなくなったからといって、料理人が不要になるわけではありません。同様に、コーディングツールが進化したからといって、価値を設計し、届ける人が不要になるわけがないのです。 AIが代替できないエンジニアの本質的な

はじめに 「llms.txt ってなんか聞いたことあるけど、実際どう使えるの？」 そんなあなたに、今すぐ体感してほしいサイトがある。 Inertia Rails のドキュメントサイト だ。 このサイトの llms.txt が、控えめに言って 最高 だ。AI と開発する時代にドキュメントサイトはどうあるべきか、その答えがここにある。 一方で、同じ llms.txt を 明確に拒否した プロジェクトもある。Tailwind CSS だ。 この記事では、Inertia Rails の llms.txt がなぜ便利なのかを紹介しつつ、Tailwind CSS がなぜ拒否したのか、その背景にある「OSSとAIの経済的ジレンマ」にも触れていく。 Inertia Rails の llms.txt がすごい そもそも Inertia Rails とは Inertia.js は、APIを書かずに React

はじめに OpenCodeを使っていて、「もっと賢く、もっと効率的に使えたらいいのに」と思ったことはありませんか？ Oh My OpenCodeは、OpenCodeに「バッテリー同梱」のエージェントオーケストレーション機能を追加するプラグインです。単一のAIモデルに頼るのではなく、複数の専門エージェントがチームのように連携して開発をサポートしてくれます。 GitHub Starsは24,000以上を獲得し、急成長中のプロジェクトです。 Oh My OpenCodeとは？ ひとことで言うと、OpenCodeの上に乗るオーケストレーションレイヤーです。 通常のOpenCodeでは、1つのAIモデルにすべてを任せます。Oh My OpenCodeを導入すると、タスクの種類に応じて最適なモデルと専門エージェントが自動的に選ばれ、まるで開発チームのように協調して作業してくれます。 ┌────────

はじめに macOSのパッケージマネージャといえば、多くの人が Homebrew を思い浮かべるだろう。「とりあえずbrew入れとけ」は、Mac開発環境構築の定番フレーズになっている。 しかし、ここで一つ問いかけたい。 本当にHomebrewがベストな選択肢なのか？ 実は、Homebrewより歴史が長く、堅牢で、パッケージ数も圧倒的に多いパッケージマネージャがある。それが MacPorts だ。 PryからIRBへ。歴史は繰り返す Rubyの世界で似たような話がある。かつて、Rubyの標準REPL（対話型実行環境）である IRB は機能が貧弱で、多くの開発者が高機能な Pry に乗り換えた。シンタックスハイライト、lsコマンド、show_source——Pryにしかない便利機能がたくさんあったからだ。 しかし、Ruby 2.7以降、IRBは劇的に進化した。インクリメンタルなシンタックスハイ

体感でも明らかに違います。VSCodeで「重い」と感じていたプロジェクトを開いても、Zedではサクサク動きます。ノートPCのバッテリー持ちにも大きく影響するポイントです。 Zed Editorのメリット 1. 圧倒的なパフォーマンス Rustで書かれたネイティブアプリケーションなので、Electronの重さとは無縁です。大規模なコードベースを開いても、検索やファイル切り替えが瞬時に完了します。 2. ネイティブAI統合 VSCodeではGitHub CopilotやCursorなどの拡張に頼る必要がありますが、ZedにはAI機能がビルトインで搭載されています。 Agent Panel: AIがファイル編集・ターミナル操作・リンター実行まで自律的に行うエージェント機能 Edit Predictions (Zeta): オープンソースの予測モデルによるコード補完 Inline Assistan

はじめに 「Tailwind は現代の jQuery だ」 この一言を聞いて、あなたはどう感じるだろうか。賛同？反発？それとも「どういう意味？」という疑問だろうか。 本記事では、jQuery がたどった道のりと、Tailwind CSS が今まさに歩んでいる道を比較しながら、Web 標準化がもたらす未来について考えてみたい。 jQuery が果たした役割を振り返る ブラウザ戦国時代の救世主 2006年、jQuery が登場した時代を覚えているだろうか。 // jQuery なしの時代 if (document.getElementById) { element = document.getElementById('myId'); } else if (document.all) { element = document.all['myId']; // IE 用 } else if (doc

はじめに 「git stash し忘れてチェックアウトできない」 「git rebase でコンフリクトの嵐」 「git reset --hard で作業が消えた...」 Git を使っていて、こんな経験はありませんか？ jj（Jujutsu） は、これらの Git の痛みをすべて解消するために設計された、次世代のバージョン管理システムです。Google のエンジニアが開発し、Rust で書かれたこのツールは、Git リポジトリとの完全な互換性を持ちながら、根本的に優れたワークフローを提供します。 この記事では、jj の魅力と基本的な使い方を紹介します。 jj とは何か Jujutsu（柔術）は、Git と互換性のあるバージョン管理システムです。既存の Git リポジトリの上にレイヤーとして動作し、チームメイトに影響を与えることなく導入できます。 最大の特徴：ロックインなし jj は Gi

はじめに Render.comでRailsアプリケーションをデプロイしようとした際、starterプラン（512MB）ではメモリ不足でアプリが正常に動作せず、月額$25のプランにアップグレードすることになりました。 しかし、適切な最適化を行うことで、メモリ使用量を大幅に削減し、starterプランでも快適に動作させることができるようになりました。この記事では、その具体的な方法とコスト削減効果について解説します。 問題：starterプランでのメモリ不足 発生した問題 Railsアプリケーションの動作が極端に遅い（トロトロ状態） メモリ使用量が512MBの制限を超過 アプリケーションが頻繁にメモリ不足でクラッシュ 一時的な対応 メモリ不足を解決するため、一時的に月額$25のプランにアップグレードしました。これにより動作は安定しましたが、ランニングコストが気になる状況でした。 解決策：メモリ使

はじめに 本記事では、Google Analytics 4 (GA4) を LLM（Claude / Gemini）から安全に読み取りするための Google Analytics MCP を、ベストプラクティス（最小構成）で導入する手順を説明します。 公式ドキュメント Google 公式の解説はこちらにまとまっています 👉 Google Analytics MCP ドキュメント 本記事はこの内容を最短で動く実手順に噛み砕き、画面で迷子にならないようにコマンド中心で進めます（API 有効化や認証を CLI で統一すると、設定場所を探す時間が激減します）。 目的 GA4 を LLM（Claude / Gemini）から安全に読み取りするための Google Analytics MCP を、ベストプラクティス（最小構成）で導入します。 前提条件（Prerequisites） Google Wo

🚀 今のおすすめは .localhost 以下の理由から、現在は auth.localhost のような .localhost サブドメインを使うのが一般的です。 ブラウザレベルで *.localhost は全て 127.0.0.1 に解決される（最近のOS・ブラウザは対応済） Google OAuth などでも http://auth.localhost:3000/callback のようなリダイレクトURIが許容される .localhost は特別なTLDとして予約されており、安全に使用可能 🔐 HTTPSが必要なケース 一部のプロバイダーはリダイレクトURIにHTTPSを必須とします。その場合は以下のような方法で対応します。 mkcert を使ってローカル開発用のSSL証明書を生成し、HTTPSで開発 ngrok や Cloudflare Tunnel を使ってHTTPSトンネル