Published 2026/08/31 ArganoのWanです。 この記事では、Gitのプリコミット（pre-commit）フックを高速化するために、Go製のLefthookとRust製のBiomeを導入し、Next.jsリポジトリを用いてベンチマークを測定・比較した結果について紹介します。
Long pre-commit waits often lead teams to disable hooks or bypass them entirely. Slow lint steps add noticeable latency to each commit.
Yet, keeping these checks active remains crucial because they keep commits lint-clean and help teams maintain consistent code quality.
To quantify latency improvements, we benchmarked compiled toolchains (written in Rust and Go) against a standard Node.js-based setup. We used Vercel’s Next.js repository as the test workspace because it already integrates ESLint and Husky.
Continue reading ↦ Published 2026/08/14 Argano の鈴木です。本記事では Claude Code を用いて GitHub に作成された PR に対するコードレビューをする環境を構築し、実際にGitHub上でコードレビューをもらうまでを実践していきます。 社内では AI での PR レビューを取り入れているプロジェクトはありますが、個人ではいままで AI でのPRレビューに触れてこなかったので、今後取り入れていきたいと思い、それに向けて実施したことを記事にまとめました。
検証環境 Claude Code: 2.1.220 使用モデル： claude-sonnet-5 環境構築 検証用に TypeScript + Express でのシンプルなタスク管理 REST API リポジトリを作成します。 以下のプロンプトを Claude Code のチャットに入力するとベースとなるサンプルコードが生成されます。
TypeScript + Express で、シンプルなタスク管理REST APIのリポジトリを新規作成してください。 このリポジトリは「Claude CodeによるPRレビューを検証する」ための実験用サンプルなので、 機能は最小限で構いません。実装が完了したらgit initしてmainブランチに初回コミットしてください。 ## 要件 - 言語/フレームワーク: TypeScript, Express - データストア: SQLite - エンドポイント: - POST /tasks (タスク作成: title, description, dueDate) - GET /tasks (一覧取得) - GET /tasks/:id (単一取得) - PUT /tasks/:id (更新) - DELETE /tasks/:id (削除) - 各エンドポイントには基本的な入力値検証、エラーハンドリング、簡単なユニットテストを含めてください (このベース実装は「お手本」の状態にしたいので、丁寧に書いてください) - README.
Continue reading ↦ Published 2026/07/31 Arganoでデザイナーをしている麻生です。
弊社デザインチームで行っている、Webサイト制作業務における事前調査としてどのような取り組みを行なっているかと事前調査の中で行っている自動化について紹介します。 従来は複数の競合サイトのページを手作業でキャプチャしFigmaに整列させる作業をしていましたが、AIを利用することでJavaScriptの深い知識がなくてもPlaywrightを利用したスクリプトを実装して自動化できました。 本記事では、自動化に使用した2つのコードの紹介と、事前調査の方法、Geminiを活用したスクリプト作成、完成までに苦戦したポイントについて詳しく解説します。
開発の背景 事前調査について Webデザインにおいて、十分な事前調査をせずに制作へ入ってしまうと、どうしても「自分の中にある引き出し」の中だけで同じようなレイアウトを繰り返してしまい、質の高いアウトプットを出すことができません。デザインのマンネリ化を防ぎ、要件に最適な情報設計をするために、事前調査は必要不可欠なプロセスと考えています。
Figmaを使う理由 弊社デザインチームでは、事前調査のツールとしてFigmaを活用しています。
普段のデザイン制作やレビューをFigmaで行っていることに加え、調査からFigmaを使うことで以下のメリットがあるためです。
思考プロセスや制作意図がチームに一目で伝わるようになる: 思考のプロセスがFigma上にまとまっているため、チーム内での意図共有やレビューがスムーズになる。 調査からデザイン制作へすぐに移行できる: 参考サイトのスクリーンショットと制作中のキャンバスが同じ場所にあるため、ツールを切り替える必要がなく、すぐに制作へ入れる。 内容とデザインの2軸で行う調査手法 Webサイト制作における事前調査を内容（情報設計の分析）とデザイン（UI/ビジュアルの参考）の2つの軸に分けて実施しています。
その理由は、内容が良いサイト＝デザイン面で優れているとは限らないためです。これらを混同せず、それぞれ別のアプローチで調査をしています。
1. 内容の調査・分析（情報設計） まず、制作するサイトの狙っているキーワードで検索をした後、1ページ目の上位表示サイトを中心に5〜10サイトほどピックアップします。この際、ページの役割が一致しているかを厳しく精査します。例えば、企業のTOPページを作る場合、検索上位に競合サイトのブログ記事が入っていても、ページの役割が異なるため分析対象からは除外します。
集めたサイトはセクションごとに分割し、セクションの配置順からコンテンツの優先順位を確かめ、共通するセクションからキーワードに対して必要な要素を分析・抽出します。この結果をもとに、実際に制作するWebサイトのワイヤーフレーム（情報設計）を作成します。
2. デザインの参考調査 情報設計が終わったら、分割したセクションごとに、内容が似ていて、尚且つ参考にしたいデザインをいくつかピックアップします。
チーム内でレビューをし、「メインビジュアルはこの方向性で」「サービスの特徴セクションはこの見せ方が良い」と、セクション単位でデザインの方向性をすり合わせていきます。
事前調査を効率化するために使っていた手動スクリプト 内容分析をするために、各参考サイト全体のスクリーンショットをFigmaへ配置し、チームで比較できる状態を作る必要があります。
全自動化に至る前は、スクロール位置の計算や微調整の手間を省くため、ブラウザのデベロッパーツール上で1画面（1080px）ずつスクロールさせながら撮影をしていました。
let currentY = window.scrollY; function nextShot() { currentY += 1080; window.scrollTo({ top: currentY, behavior: "instant" }); return currentY; // 実行すると1080pxスクロールして現在のY座標を返す } nextShot(); 手動スクリプトで発生していた課題 手動スクリプトの導入により、縦に長いサイトでも高画質なままFigmaへ配置できるようになりました。しかし、実際の調査業務においては依然として以下の課題が残っていました。
撮影の手間とやり直しのストレス: Consoleで関数を実行しながら手動で撮影を繰り返す必要があり、途中で少しでも手動スクロールしてしまうと座標がズレて一から撮り直す必要があった。 Figma上での配置作業の負荷: 撮影した複数枚の画像をFigmaへ持ち込んだ後、縦に並べて隙間なく整列させる作業に多くの時間を割いていた。 Geminiを活用したスクリプト作成 今回の自動化にあたり、最初からPlaywrightを使おうと決めていたわけではありません。先ほど紹介したConsole用の手動スクリプトをそのままGeminiに提示し、「これを勝手に実行してローカルフォルダに自動保存できないか？」 と相談したところからスタートしました。
Geminiからは「ブラウザのConsole単体では、セキュリティ制限によりローカルへの自動ファイル保存が難しい」という回答とともに、以下の3つの選択肢が提示されました。
ブラウザ標準機能: ChromeのCapture full size screenshot（手動・静止画） Playwright / Puppeteer: Node.
Continue reading ↦ Published 2026/07/14 Argano の松田です。
最近、オープンソースパッケージの脆弱性やサプライチェーン攻撃のニュースをよく目にするようになりました。とはいえ、日々アップデートされる無数のパッケージ情報をすべて追いかけるのは現実的ではありません。そこで、私が行っているセキュリティ情報の収集方法と、リポジトリでの対策をご紹介します。
セキュリティ情報の収集 X Node.js や React の公式、セキュリティ関連のアカウントをフォローしています 速報性が高く、脆弱性情報をいち早くキャッチできます 毎朝確認するサイト The Hacker News 海外のニュースサイトで、速報性が高く、脆弱性情報をいち早くキャッチできます Security Next に比べ、より技術的な内容が多い印象です はてなブックマーク IT 系のニュースがまとめられています。 各リポジトリの Security and quality > Dependabot > Vulnerabilities 自分が関わっているリポジトリの脆弱性情報を確認できます 対応方法は後述 社内の朝会で確認するサイト Security Next 技術的な記事以外にも、ニュースや脆弱性情報がまとめられています 朝会では各自、気になる記事を取り上げて共有しています GitHub Advisory Database GitHub が提供する脆弱性情報のデータベースです 朝会では npm をメインに Severity が High 以上の脆弱性情報を確認しています 毎朝の確認ルーティンに入れようか検討中のサイトもあります。
Continue reading ↦ Published 2026/06/30 Arganoの池田です。本記事では以前の記事で紹介した New Relic を導入した Next.js アプリケーションでAPMによるトレーシングを試してみます。バックエンドのトレースやエラー監視がどのように見えるのかを、実際に実装したアプリケーションで検証し、エラーの調査やパフォーマンスの分析に利用できることを確認します。
用語 今回はAPMのトランザクショントレースについての検証ですが、その前に用語について簡単に説明します。
トランザクション アプリケーションへのリクエストについて開始から終了までの一連の処理をまとめた作業単位です。本記事では、トランザクションのトレースをNew Relicコンソールから確認し、パフォーマンスのボトルネックやエラーの発生箇所を特定する検証を行います。
トレース トランザクションに含まれる一連の作業に関する追跡情報です。トランザクションの処理の流れ、エラー情報やクエリの応答速度を含みます。トレースは複数のスパンから構成されます。
スパン トレースの構成単位です。APIリクエストのトレースにおいてはDB処理や外部APIリクエストなどがスパンに該当します。
検証環境 以下の環境で検証を行います。 プロジェクトのセットアップについては過去の記事を参照してください。
Node: 24.17.0 Next.js: 16.2.9 React: 19.2.4 実装と検証 検証のために、簡単なログインページとログインのエンドポイントを作成します。体裁を整えるためフォームの各要素には別途UIコンポーネントを利用していますが、そちらについてはご自身の環境に合わせて標準のHTML要素に変更していただいて構いません。
/app/login/page.tsx
"use client"; import { useState } from "react"; import { useRouter } from "next/navigation"; import { Field, FieldGroup, FieldLabel, FieldSet, } from "@/components/ui/field" import { Input } from "@/components/ui/input" import { Button } from "@/components/ui/button"; const Page = () => { const [error, setError] = useState(""); const [loading, setLoading] = useState(false); const router = useRouter(); const handleSubmit = async (e: React.
Continue reading ↦ Published 2026/06/09 ArganoのWanです。 この記事では、JavaScriptにおけるオブジェクト操作に役立つ組み込みメソッドについて紹介します。
Introduction In JavaScript, objects are a fundamental structure for managing complex data. Beyond storing key-value pairs, they allow functions to be encapsulated as methods. This post covers the built-in static object methods frequently used to manage and transform object data safely and concisely.
Getting data from Objects The following object represents a standard data structure used throughout the examples in this post:
const userConfig = { id: "32975023530592", username: "wan", email: "wan@example.
Continue reading ↦ Published 2026/05/29 Argano の小林です。
本記事では Git におけるファイルのパーミッションの扱い方について述べます。
Git の挙動を確かめる はじめに Git で管理されているファイルのパーミッションを書き換えるとどうなるか見てみます。
新しく test-permisions リポジトリを作成して script.sh を追加します。
$ git init test-permissions $ cd test-permissions $ umask # デフォルトのパーミッションを確認 022 # ファイルについては 644 に設定される $ echo "echo 'This is test script.''" > script.sh $ ls -al total 16 drwxr-xr-x 3 ryohei ryohei 4096 May 29 20:10 . drwxr-xr-x 3 ryohei ryohei 4096 May 29 20:09 .. drwxr-xr-x 7 ryohei ryohei 4096 May 29 20:09 .
Continue reading ↦ Published 2026/05/21 Argano の鈴木です。TypeScript v7のリリースが迫ってきました。この記事ではどのような変更があるのか、また、Argano メンバーに聞いた疑問点などを紹介していきたいと思います。
TypeScript v7での変更点 もうすぐTypeScriptバージョン7がリリースされます(2026年5月現在v7開発中)。
v7では、これまでTypeScriptで書かれていたTypeScript本体やコンパイラをGo言語で実装し直すという大きな変更があります。 Go言語で実装し直すことでビルドや型チェックの速度の大幅改善が見込まれています。
なぜGo言語で書くと速くなるのか TypeScriptで書かれたコンパイラの場合、コンパイラはnode環境で実行されますが、v7以降のGo言語で実装されたコンパイラはネイティブバイナリとして、node環境を介さずにOSが直接バイナリを実行することになるため、高速に処理を進めることができるようになります。
また、TypeScriptとGo言語では並列処理の方法が異なっており、Go言語での並列処理の方がビルド速度を高速にするのに向いています。
Node.js (TypeScript) では、基本的にシングルスレッドで処理を行っています。async/awaitなどの非同期処理時には待ち時間の間に別の処理をするだけで、CPU自体を複数同時に使うことは苦手です。Node.jsでマルチコアを活用することは worker_threads や子プロセスを使うことで実現できますが、新しいスレッドを立ち上げる処理のコストが大きいこと、また、スレッド間でのメモリ共有が苦手であるなど、コンパイラ開発における弱点は点在している状況です。
一方Go言語での並列処理ですが、複数スレッドを使うことを前提に設計された Goroutine という仕組みによってスレッドを素早く立ち上げて使うことができます。メモリの共有においても、Node.jsのようなデータの変換・転送コストをかけずに実行することが可能となっています。
レガシー機能の削除 v7 および、v7の準備段階として位置付けられたv6から、いままで使えていたレガシーな機能が使えなくなります。
前述したようにv7では実行速度向上のためにGo言語への移植が行われます。この大規模な刷新を成功させるためには、長年蓄積された複雑なレガシー仕様を整理し、コンパイラのロジックをシンプルにする必要がありました。
v6はそのための仕様の最適化期間であり、開発者がスムーズに次世代環境へ移行するためのステップです。
v6の最大の役割は、TypeScriptを最新のJavaScript規格（ES Modulesなど）に最適化することです。そのため、古いブラウザや過去のモジュール形式に関連する設定を削除または非推奨とし、v7ではそれらを削除することで、コンパイラの「軽量化」と「高速化」を実現しようとしています。
これまでの歴史の中で積み上げてきた機能のなかには、レガシーな仕様（AMD, UMD, Node10解釈など）が含まれていますが、viteなどを使ったモダンな開発でツールの役割分担が主流となっています。
viteの例ですと、TypeScript(tsc)では型チェックのみを行い、viteの役割としてJSへの変換や、必要に応じて古いブラウザでも動くようトランスパイルしています。
Arganoメンバーに聞いたv7への疑問 TypeScript v7への期待や疑問などを Argano メンバーにインタビューしてみました。
実際にどれくらい速くなるのか計測してみてほしいです。
弊社のプロジェクトの中でも比較的ファイル数が多いリポジトリでTypeScript v6, TypeScript v7のそれぞれのコンパイラを使って型チェック(tsc --noEmit)にかかる実行時間を計測してみました。
リポジトリ内のts,tsxファイルは合計で約2,500ファイルあり、累計の行数は約140,000行となっています。
v6(TypeScript製) v7(Go言語製) 7.90s 1.104s 今回計測したリポジトリでは約1/7に処理時間が短縮されました。
コードが大きくなりビルドにかかる時間の肥大化が問題となりつつありましたが、TypeScript v7へアップデートすれば大きく改善できそうです。
v7に備えて開発者はどのような準備をする必要がありますか？
v7がリリースされる前に、準備段階としての立ち位置のTypeScript v6がリリースされています。このバージョンではv7で廃止される予定のtsconfigの設定が廃止・非推奨となります。
一度v6に上げ、tsconfig.jsonの修正を行うことでスムーズにv7を使うことができるようになります。
どのような破壊的変更がありますか？
Continue reading ↦ Published 2026/04/30 Arganoの麻生です。 今回は、clamp() の第2引数（推奨値）のブレイクポイントに基づいた設定方法とそのメリットについて共有します。
clamp()とは clamp()とは要素のサイズを3つの引数（最小値、推奨値※、最大値）で指定することでメディアクエリなしで画面幅に応じて自動的にサイズを変化させる機能です。
※推奨値には%やvwのような可変単位を使う必要があります。
推奨値（Preferred value）の役割 clamp(最小値, 推奨値, 最大値) において、推奨値は「通常時に参照される値」です。画面幅（vw）に連動させることで、ブラウザの画面幅に応じてシームレスにサイズを変化させることができます。
主な対象 現在は、テキストだけでなくレイアウトのほぼ全てにclampを使用しています。
文字サイズ: 見出しなどの大きな文字（目安1.5〜2em以上） 余白: セクション間や左右の padding や margin コンポーネント単位: 画面幅に応じて可変させたい要素の幅や高さ 感覚から計算へ 以前：2vw などの「適当な指定」
「画面を縮めた時に、なんとなく途中で最小値に切り替わればいいかな」という程度の認識でした。これでは、特定のデバイス（タブレットなど）で意図せず小さくなりすぎたり、逆に縮小が遅すぎたりといった問題がありました。
現在：文字サイズ / 画面幅 による「意図的な指定」
「どの画面幅のときに、そのサイズであってほしいか」という基準点から逆算します。
考え方: (ターゲットとする文字サイズ / 基準の画面幅) * 100
例: 1280pxの画面で 40px にしたい場合
計算：(40 / 1280) * 100 = 3.125 指定：clamp(24px, 3.125vw, 40px) このように設定することで、狙ったタイミングで縮小を開始させ、デザインの崩れを防ぐことができます。
縮小開始の基準 計算の基準となるブレイクポイントは、デザインやコンテンツの重要度に応じて、以下の基準値を使い分けます。
基準幅 対象・シーン 1920px 大画面デスクトップ。ゆったりした配置の基準。 1200〜1400px インナー（コンテナ）サイズ。コンテンツが詰まり始める起点。 1280px ノートPCの標準。ここを起点に縮小を始めることが多い。 960px 画面分割（1/2）時。タブレットへ移行する前の重要な境界。 768px タブレット（iPad等）の縦持ち基準。 640px 画面分割（1/3）時。スマホ表示への切り替え検討ライン。 480px 画面分割（1/4）時。スマホ横持ちや、大型スマホの基準。 なぜ意図的にする必要があるのか 予測可能性の向上 どのデバイスで見ても「デザイナーの意図」に近い比率が保たれます。
Continue reading ↦ Published 2026/04/14 Arganoの松田です。この記事では、npm の min-release-age オプションの挙動について詳しく解説します。
min-release-age とは min-release-age は、npm パッケージのリリース後に一定期間が経過するまで、最新バージョンをインストールしないようにするオプションです。これにより、リリース直後の不具合や悪意のあるコード（サプライチェーン攻撃など）からプロジェクトを保護することができます。
特に最近では npm パッケージに対する攻撃が増加しているため、リリース後すぐに最新バージョンを使用することのリスクが高まっています。min-release-age を設定することで、これらのリスクを軽減できます。
https://docs.npmjs.com/cli/v11/using-npm/config#min-release-age
pnpm や yarn など、他のパッケージマネージャーにも同様の機能があります。
pnpm : https://pnpm.io/ja/settings#minimumreleaseage yarn : https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate 設定方法 min-release-age は、プロジェクトの .npmrc ファイルに以下のように設定します。
この例では、リリース後 7 日が経過するまで最新バージョンをインストールしないように設定しています。
min-release-age=7 # 単位は日数 挙動の詳細 環境
Node.js : v24.14.1 npm : 11.12.1 min-release-age の挙動を調べるため、新規 npm プロジェクトを作成します。
mkdir npm-min-release-age-test cd npm-min-release-age-test npm init -y 次に、min-release-age を 14 日に設定します。
echo "min-release-age=14" > .npmrc 1. 特定のバージョンを指定した場合の挙動 この状態で、記事執筆時点で最新の lodash パッケージをバージョン指定でインストールしてみます。
Continue reading ↦