はてなブックマーク

はじめに 私はもともとIS（インサイドセールス）、いわゆる営業サイドの人間だった。 コードは書けない。SQLも知らない。ターミナルを開いたこともなかった。そんな自分が、ある日開発部のCRE（Customer Reliability Engineering）チームに異動した。 CREの仕事は、お客様からの技術的な問い合わせを調査して回答すること。「承認フローが変わってしまった」「エクスポートが終わらない」「メールが届かない」——毎日そういった問い合わせがJiraに積まれていく。 調査には、本番DBへのクエリ実行、Rails/Reactのコードリーディング、ログの解析が必要になる。正直に言うと、最初は「自分にできるのか」という不安しかなかった。 でも今、私のPCでは毎時0分にClaude Codeが自動で起動し、Jiraから新しいチケットを拾い、コードとDBを調査し、回答ドラフトまで作ってSl

この記事では、2024〜2025年にかけて主要ブラウザで使えるようになったCSS（一部HTML）の機能を10個紹介します。「昔はセレクターとか頑張って追いかけてたけど、最近は全然追えてない」という方を対象としています。 それぞれの機能について、目的・できること・昔のやり方・注意点をまとめました。コードを見ながら「こんなの使えるようになったのか」と感じてもらえたら嬉しいです。 1. CSS Nesting（ネイティブCSSネスト） 目的 SassやLESSなどのプリプロセッサなしで、CSSにネスト（入れ子）構造を書けるようにすることです。 できること セレクターを親子関係で入れ子にして記述できます。& を使って親セレクターを参照します。 .card { padding: 1rem; background: #fff; & .title { font-size: 1.25rem; font-w

はじめに チームのコードレビューの負担を少しでも減らすために、Claude Code の Skill を作成しました。 今回は、backend（Rails） 用として作成した /review-backend を紹介します。 暫く使って安定したら、frontend 用にも展開する予定です。 狙いは、人のレビュー工数を少しでも多く軽減することです。 まだ実運用を始めたばかりですが、同じように Claude Code でレビュー負担を減らしたい方の参考になれば幸いです。 環境 Claude Code v2.1.119 Claude Sonnet 4.6 Claude Team Ruby on Rails 7.0.6 Ruby 3.2.1 前提知識 Claude とは Anthropic 社が提供する、ChatGPT や Gemini と同じように対話形式で使える AI アシスタント 質問への回答

対象 .env に API キーを入れてそのまま開発している セキュリティーを意識して、Vibe Coding を行いたい方 はじめに 　~.env なぜ 危ない？~ 🧑‍💻: 「Hey men! .env 読むな！」 🤖: 「わかりました。 .env を読み込みます」 ※AGENT.mdやCLUADE.md で設定していても、読み込む可能性があります。 .envを読み込まれるとなにが問題なの？ AIに.env を読まれると機密情報が学習されそう、と思い浮かびますが (もちろん、AIエージェントの設定で学習されるリスクもあります..) 実際問題になるのは、学習よりも前の段階で 機密情報(.env)がAIとその周辺ツールの処理に乗ることです。 具体的に何が起きるのか .env を AI が読める状態にしていると、以下のようなリスクがあります。 1. 生成コードへの埋め込み 「この AP

以前、私は Claude Code と一緒に dark-part-time-job というオーケストレーションシステムを作りました。 これです。 複数のAIエージェントを tmux 上に並べ、親分・若頭・若衆のような役割分担で開発タスクを進めるための仕組みです。名前からしてだいぶ治安が悪いですが、やりたかったことは意外とまじめでした。 親分がユーザーの指示を受け、若頭がタスクを分解し、若衆がそれぞれ実装します。ここで重要なのは、人間がworker一人ひとりに細かく指示を出すのではなく、タスク分解と割り振り自体もAIの仕事にしていたことです。タスクはYAMLキューで渡され、作業結果はレポートとして戻されます。さらに、git worktree を使って並列作業を分離する仕組みも持っていました。 このシステムで特に重視していたのが、yb というCLIを通じて、新規・既存を問わずどのリポジトリにも

こんにちは！株式会社カンリーでエンジニアをやっている市川です。 はじめに：BigQueryに触れるようになったきっかけ データ基盤プロジェクトに関わるようになり、BigQueryを触る機会が一気に増えました。 それまで私は、主にMySQLを前提にSQLを書いてきました。Laravelアプリケーションや運用保守の中で扱うのはMySQLが中心で、SQLを書くときも自然と「MySQLならこう考える」という前提が染みついていました。 そのためBigQueryを触り始めた当初も、同じ感覚でクエリを書いていました。しかし実際に使い始めると、その感覚はすぐに通用しないことを痛感しました。 今回は、口コミデータやGBPの投稿データ、店舗情報、営業時間といったデータをBigQueryで扱う中で学んだ「設計の考え方の違い」をまとめます。 最初にぶつかった違和感 BigQueryを使い始めて最初に感じたのは、「

に投稿した記事の微修正版です いままで AWS Lambda のRustはExperimentalとして提供されていましたが、2025年11月14日に一般提供開始となりました。 Custom Runtime と Cargo Lambda LambdaのRustサポートはCargo Lambdaというオープンソースフレームワークにより実装されています。 2018年にLambdaがCustom Runtimeをサポートしました。これにより公式サポート外の言語（Rustを含む）でLambda関数が書けるようになりました。そのあとCustom Runtimeを使用したRust RuntimeがAWSにより開発されリリースされました。 しかしながら標準でLambdaがRuntimeをサポートしていたなかったこともあり、ビルド・デプロイはかなり複雑でした。この問題を解決するためにコミュニティベースで開

はじめに VS Code標準のソース管理も便利ですが、複雑なブランチの分岐やマージ履歴を追うのは少し見づらく感じたことはありませんか？ 結論から言うと、VS Code拡張機能「Git Graph」を入れると、履歴の俯瞰とグラフ起点のGit操作が劇的に快適になります。 本記事では、Git Graphがなぜ便利なのか、そしてすぐに実務で使えるおすすめの設定を紹介します。 VS Code標準機能との使い分け Git GraphはGit CLIを完全に置き換えるものではありません。VS Code標準機能と以下のように使い分けるのがおすすめです。 VS Code標準（Source Control）: 日常の差分確認、ステージング、コミット（「今」の作業） Git Graph: 履歴の把握、分岐の 理解、過去のコミット詳細の確認（「過去と全体」の作業） Git Graphのここが便利（3つのエッセンス

はじめに 画像やPDFのテキストをコピーしたいとき、オンラインのOCRサービスに画像を送るのはちょっと抵抗がありませんか？ 特に社外秘の資料や個人情報が写っている場合。 通信ゼロ、ブラウザの中だけで完結するOCR があれば安心して使えるのに — そう思って、Chrome拡張機能を作りました。 以前からいくつかの日本語OCRを試してきて、ブラウザ内でも実用レベルで動くことがわかっていたので、それを誰でも気軽に使える形にしたかったのが動機です。 yomitokuで作る日本語OCR Webアプリ — サーバーサイドで高精度な日本語OCR Tesseract.jsでカスタムモデルのトレーニング — ブラウザOCRの可能性と限界 ブラウザだけで完結する日本語OCR＋透視変換 — NDLOCRをブラウザで動かす Chrome Web Store で「オフラインOCR」と検索してもヒットします。 これま

コスパじゃなくなりそう 前回の記事で、GitHub Copilot の最大の強みはコスパだと紹介しました。 しかし、6月1日から、GitHub Copilot の課金体系が変更されるようです。 本日(2026/4/28)日本時間の午前1時頃、Githubから公式に発表がありました。 現在の「プレミアムリクエスト」から「トークンベース」に変更されるとのことです。（恐れていたことが現実に…。） そうなると、前回の記事はすぐに意味のないものになってしまい、 私はオクトキャットフィギュアをいただけなくなってしまいます。 それは困る！まじで欲しいのに！ ということで、個人的に助かっている GitHub Copilot の機能的な強みを紹介していきます。 VSCode との統合 散々言われていることかもしれませんが、GitHub Copilot は VSCode と非常に密接に統合されています。 正直

はじめに 本日、Hono の作者 yusukebe さん から @hono/inertia が正式リリースされた。 前回、サンプルアプリの中身を除いて、Hono と Inertia.js の型貫通体験の仕組みを明らかにしたところで、今回は実際に簡単あアプリを作って、その触り心地を確かめてみる。 前回の記事 今回作ったアプリ 結論から言うと、SPA の書き心地が一段階アップデートされる体験だった。ふだん React + API で書いていた時のしんどさが、けっこうな部分まるっと消える。具体的には： API エンドポイントを書かなくていい React Router が要らない useEffect + fetch のお作法が消える 取得データ用の useState も要らない 以下、何が嬉しかったのかを、実装しながら掴んだ感覚で書く。 この記事で扱うこと @hono/inertia で何ができる

はじめに こんにちは！TOKIUMでQAチームのリーダーをしている西田です。 「シフトレフト」「ATDD（受け入れテスト駆動開発）」「BDD（振る舞い駆動開発）」 — テストを上流に持っていこうという考え方は、ソフトウェア開発の世界で10年以上前から提唱されてきました。概念としては広く知られているのに、実際に徹底できている現場は少ない。「理想はわかるけど、やるのが大変」というのが正直なところだったと思います。 ところが今、生成AIの急速な進化によって前提が変わりつつあります。Claude CodeやGitHub Copilotによるコーディング自動化、Playwright Agentsによるテスト自動化。かつて「理想論」だったプラクティスの実現コストが、AIによって劇的に下がっているのです。 この記事では、これらの概念が生成AI時代に再び現実的な選択肢として浮上する先に、開発プロセスとQA

Claude / CodexのPermission確認をLLMに代行させるccgateというCLIを作った もとはAuto Mode的な体験を目指して作り、Auto Modeが使えるようになった今もPlan mode中の確認やCodexへの展開、ログ・metricsの可視化のために使い続けている 自分の環境では1ヶ月約2000件のPermission確認のうち、基本的に97%近くが自動化された はじめに こんにちは。@tak848です。今日で25になりました。もうアラサーってやつなんでしょうか。 みなさん、Coding Agentは使っていますか？ 個人的には、個人開発でも業務でもClaude CodeやCodex CLIが欠かせない道具になっています。使う時間が増えるほど、Tool実行のPermission許可で止まる場面も増えてきました。 とはいえ、面倒だからといって--dangero

皆さん、こんにちは。sotamakiと申します。 今日は、主にAIエージェント文脈で登場するサンドボックスについて学んだことをまとめていきたいと思います。 前提：AIエージェントは”行動”する 最近のAIエージェントは、単に文章を生成するだけでなく、コードを書いて実行し、ブラウザを操作し、外部APIを叩き、ファイルを読み書きします。指示を受け取り、自ら判断しながら一連の操作を完結させます。 ユーザー入力 ↓ ┌─► LLM（思考・計画） │ ↓ tool call │ 外部ツール / API / コマンド │ ↓ └── 結果フィードバック ↓ 最終応答 この「自律的にツールを呼び出せる」という特性が、従来のWebアプリとは異なるリスクを生む可能性があります。 通常のアプリは「受け取った入力をどう処理するか」をコードに書きますが、エージェントは「何を実行するか」をLLMが動的に決めます。攻

本記事では、RAGの性能を高めるための「Corpus2Skill」という手法について、ざっくり理解します。 株式会社ナレッジセンスは、「エンタープライズ企業の膨大なデータを掘り起こし、活用可能にする」プロダクトを開発しているスタートアップです。 この記事は何 この記事は、「ベクトルDB」を使わずにRAGの精度を上げる新手法「Corpus2Skill」の論文[1]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは？」については、知っている前提で進みます（参考） 本題 ざっくりサマリー 「Corpus2Skill」は、ベクトルDBを使わず、エージェンティックに検索することで、RAGの精度を上げます。 Magellan Technology Research Institute (MTRI) の研究者らによって2026年4月に提案されました。 通常のRAGでは、文章をベクトル

実際の画面とは異なるサンプルイメージです チームのSlackにAI社員を3人常駐させています。 社員5人で、2週間動かしました。 誤解を招きそうだからちゃんと書いておきます。 2週間です。半年でも1年でもなく、2週間。 それでも書きたくなるくらいのことが起きたので、この記事を書いています。 SIerの大規模開発で扱う資料は毎週溜まります。 仕様書の背景、顧客の痛点、過去の判断の残り香。 新しく参画したメンバーは、これを数週間かけて読み込むのがいつもの景色です。 そこに、このAI社員3人が入りました。 すると、2年目のメンバーが参画1週間でSKILLを直し、2週間で設計根本に疑問を出してきた。 正直、びびりました。 自己紹介・大規模現場の話を軽く 私はNTTデータグループ 技術革新統括本部のITアーキテクト（課長代理）で、大規模システムのモダナイゼーションに携わっています。 全社の高難度案件

はじめに この記事ではエンジニアが30%~40%とキー数の極端に少ないレイアウトにする場合の注意点についてまとめました。 用語について ShiftやCtrlといった「修飾キー」と、記号などを打つための「レイヤー切り替えキー」は、どちらも「他のキーと組み合わせて別の機能を持たせる」という点で本質的に同じものです。この記事では、これらをまとめて Metaキー と呼ぶことにします。 40%レイアウトの基本ルール 結論を先に言うと、 日常的にコマンドを叩くような作業をするエンジニアは5カラムなど極限までキー数を削ったキーボード配置に安易に移行するのは推奨しない というのが主な主張です。もちろんそれでうまくいっている人は全然問題ないです。これから40%キーボードを検討しようとしている人に向けて、私自身がつまずいた内容を共有することが目的です。 主張したい点は以下です。 親指のホールドキーの割当は最小

Claude Codeのルーチン（Routines）機能を、何に使うのが良いのかしばらく考えていました。 クラウド上でプロンプトを定期実行できる便利な機能なのですが、定期的に動かして意味のあるタスクは何だろう、と。 たどり着いたのが、パフォーマンスチューニングです。 「速くなったか」は数値で判断できるので、ベンチマーク基盤さえあれば、あとはAIに任せられます。 機能としてデグレしていないかもテストが充実していれば自動で確認できますし、ブランチを切って進めるので本流には影響しません。設計の創造性があまり要らないのもAIに任せやすいところですね。 私が開発しているRepomixというCLIで試してみたところ、実行速度が 約2.4倍 になりました。 ある程度再現性のある形に落ち着いてきたので、プロンプトとベンチマーク基盤の話を中心に共有します。 ルーチンとは Claude Codeには、クラウド

// サーバー側（Hono） app.get('/posts/:id', (c) => { const post = findPost(c.req.param('id')) return c.render('Posts/Show', { post }) }) // クライアント側（React） export default function Show({ post }: PageProps<'Posts/Show'>) { return <h1>{post.title}</h1> } post の型は Post として完全に推論される。間に API 定義も DTO も tRPC もスキーマ生成もない。サーバーで c.render() の第2引数に渡したオブジェクトが、そのまま React の props として、しかも完全に型付きで届く。 「API なし SPA」を謳う Inertia.j

1. はじめに 今回は、MCP 初心者が MCP サーバを試してみて考えたこと・気づいたことを紹介しようと思います。 MCP は概要だけ知っていたものの今まで使ったことがなかったのですが、GitHub Copilot（筆者は VS Code で利用）の Agent モードを活用すれば簡単に環境を作って試せるのではないかと思いつきました。 そこで、馴染みのないツールの MCP サーバでも手軽に試すことができたら良いなと思い、初めて触る Playwright を用いて UI/UX レビュー&修正のサイクルを自動化させてみました。 なお、この試みの中で私は1行もコードやプロンプトは書いていません。書いたことと言えば、チャットで自分の意向を伝えたくらいです。 ただし、本記事では、MCP サーバを使う上で学んだことがメインテーマなので、UI/UX のレビューでどういった指摘が出て、どういった修正がさ

みなさまこんにちは！エアークローゼットでCTOをしている辻です。 これまでに DB Graph MCP、社内MCP群の全体像、Biz Graph MCP と、社内向けに作っている MCP サーバーを順に紹介してきました。 今回はその中でもちょっと毛色が違うものを取り上げます。Sandbox MCP ── 非エンジニアの社員が AI と一緒に作ったアプリを、ワンコマンドで社内に安全に公開できるプラットフォームです。 「Claude Code でアプリを作れるなら、それをそのまま社内に出せばいいじゃん」という話を、安全に実現する仕組みです。 背景：作るのは簡単になったが、公開は難しいまま Claude Code をはじめとする AI コーディングエージェントの普及で、いま社内の景色が大きく変わりつつあります。 これまで「アプリを作る」と言うと、エンジニアの仕事でした。要件定義してデザインを起こ

はじめに 「どのフレームワークを選ぶべきか？」 これは初学者だけでなく、新規事業の技術選定を任された中級者にとっても常に悩ましいテーマです。 いまフロントエンドの世界は、大きな転換期を迎えています。長年使われてきたReact、Vue、Angularの三大フレームワークが、これまでの古い常識を捨てて新しい次元へとアップデートしているからです。さらに忘れてはいけないのが、私たちのすぐ隣には「Claude Code」や「Cursor」のような、最強のAIアシスタントが当たり前のように存在しているということです。 この記事では、初学者が最初のステップを踏み出すための視点から、中級者がモダンなアーキテクチャをどう捉え、AIとどう協業していくべきかまで、各フレームワークの現在地をまとめました。 1. React：サーバー主導UIへの移行と「AIエコシステムの覇者」 現在もフロントエンド業界で圧倒的なシ

この記事はAIの支援を受けて執筆しています。 はじめに 「Claude にコードを書かせ、Codex にレビューさせる」という構成は、異なるモデルによる外部視点が得られるとして注目されています。この組み合わせ自体はシンプルですが、実際に運用しようとすると 「どうやって2つのモデルをつなぐか」 というハーネス選びが課題になります。 いくつかのオーケストレーションツールを検討した中で、もう一つ制約がありました。手元の環境では Codex の API を直接呼び出せず、GitHub Copilot 経由でのみ Codex が使える状況だったのです。 この条件にマッチしたのが takt です。takt は Claude と Copilot を同じワークフロー内のステップに混在させられるため、今回の構成にそのまま当てはめることができました。 この記事では、takt を使ってこのワークフローを組む方法

アプリケーション開発の現場において、デザイナーによって作成されたFigmaなどのUIデザインがいざ実装フェーズに入ると、「このボタン、この状態ではどう動くの？」といった情報の不足が見つかったり、「裏側のデータ構造と合わない」といった手戻りが発生したりと、職種間のコミュニケーションミスが発生したことはないでしょうか。それは、開発の現場において「ビュー（見た目）」という表面的な情報を起点にデザインすることが常態化しているからかもしれません。本稿では、オブジェクト（実体）を起点にUIを設計することで、デザイナーと開発者が迷わずに進める「共通の地図」を作るアプローチについて解説します。 参考書籍 本稿の作成においては以下の書籍を参考にしました。 オブジェクト指向UIデザイン | 技術評論社 モデルベースUIデザイン 構造化UIと情報設計の方法論（丸 怜里）｜翔泳社の本 Lean UX 第3版 -

はじめに こんにちは、uchiです。株式会社ビズリーチのAI Product Studio（以下、APS）でエンジニアをしています。APSは2026年2月に新設された組織で、「AIでプロダクト創出を常態化する」をミッションに、現在はAIを前提とした開発プロセスの構築と新規プロダクト開発に取り組んでいます。 この記事では、APSでAI前提の開発フローを構築するなかで生まれた「Agentic UATスキル」を紹介します。AIエージェントに仕様を一切教えずエンドユーザーを演じさせ、業務を遂行できるかを自律的にテストする手法です。ソースコードを読ませず、UIだけを頼りに業務を進めさせることで、「テストは通るのにエンドユーザー視点では動かない」バグを人手を介さずに検出できるようになりました。 AIエージェントに実装全体を任せたある時、こんな事象が発生しました。 「ユーザーのステータス変更機能を実装し

松尾研究所シニアデータサイエンティストの太田です。普段はLLMの事後学習に関するプロジェクトに携わっています。 現在松尾研究所では各種業務をメンバーに代わって自律的に代行するパーソナルエージェントの社内開発に取り組んでいます。この記事ではそうした開発のなかで調査をしたOpenClawとHermesについて、思想の違いとデザインチョイスを主に共有したいと思います。 Claw とは 2025年11月にGitHubで公開されたOpenClaw（当時はClawdBot）は瞬く間に同プラットフォームで250k Star（React以上）を記録しました。 OpenClawの注目の理由は従来エージェントがリアクティブ（ユーザーからの指示を経て行動する）だったことに対して、常時起動とCronジョブを取り入れることで、アクセシビリティとプロアクティブ性（エージェントが自ら行動する）を見せたことにあります。一

大規模言語モデル(LLM)を中心とした生成AIの出現に伴い社会が作り変えられつつある。個人的な感覚としてはAIベンダーがリリースする定期的なモデルの刷新は2023年のGPT-4から本質的な変化はないと思っていた。だが、2025年末からのClaude Codeを先頭にした性能向上や、多様な角度での機能の拡充などが、複合的に作用しあい、2025年末以降、本格的な動きとなっている。 我々にとって生成AIは最初の1、2年はチャットを通して新しい独白、つまり内面世界を拡張するものとして、半ば暗黙的な存在のように扱われてきた。しかし、APIやプラグインの充実により、スタンドアロン性が強かったWordやExcel、そしてコードエディタとも接続されるようになった。 独白の延長であったならば、AIの出力がどんなに優れていようともーー逆にハルシネーションを含んだものであったとしてもーーそれをどのように扱うかは

はじめに GitHub Copilot CLI で複数のエージェントを使って成果物を改善するワークフローを考えていると、最初に悩むのが「誰が成果物を書き換えるのか」です。 私も最初は、執筆役が初稿を書き、その後に事実確認役、表現レビュー役、構成レビュー役が順番に本文を確認する流れを考えていました。これは逐次型のワークフローです。 一見すると自然な分担です。専門エージェントが順番に成果物を改善していくので、レビュー観点も漏れにくそうに見えます。 しかし、並列実行を前提に考えると、この設計はかなり相性が悪いことに気づきました。理由はシンプルで、複数のエージェントが同じ本文を書き換えるからです。 この記事では、GitHub Copilot CLI で複数エージェントを扱うときの考え方として、同じ成果物を安全に改善するための設計を整理します。ブログ記事執筆は、あくまで題材として扱います。具体的には