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 ↦ Published 2026/04/02 Arganoの池田です。 本記事ではTypeScript, JavaScriptプロジェクト内の不要なコードを検知・削除できるKnipというツールの概要と設定について紹介します。
Knip このツールは冒頭に記載した通りTypeScript, JavaScriptプロジェクト向けの不要コードを検知して削除できるツールです。 例えば、package.jsonに記載があるにも関わらずどこからも使用されていない依存パッケージや、exportしているにも関わらずプロジェクト内でどこからもimportしていないモジュールを検知することが可能です。
https://github.com/webpro-nl/knip
導入〜使用方法 ※最新の情報は公式ドキュメントを参照してください。
下記のコマンドでインストールできます。
npm install -D knip 実行コマンドはpackage.jsonのscriptsに以下のように記載した場合は npm run knip で実行可能です。
{ "name": "my-app", "scripts": { "knip": "knip" } } dependencies 実行後、もしプロジェクト内に未使用の依存パッケージが存在する場合は以下のように検知することができます。
my-app % npm run knip > my-app@0.0.0 knip > knip Unused dependencies (1) uuid package.json:16:6 --fix オプションで自動修正にも対応しています。knip:fix をpackage.jsonに追加して実行すると、未使用の依存パッケージがpackage.jsonから削除されます。なお、lockファイルの更新は別途必要になります。
{ "name": "my-app", "scripts": { "knip": "knip", "knip:fix": "knip --fix" } } my-app % npm run knip:fix > my-app@0.0.0 knip:fix > knip --fix Unused dependencies (1) uuid package.
Continue reading ↦ Published 2026/03/27 Argano の江川です。
前書き Gemini の埋め込みモデルに Gemini Embedding 2 が追加されました。
これまで Vertex AI ではテキスト向けの埋め込みモデルとして gemini-embedding-001 が提供されていました。
今回追加された Gemini Embedding 2 では、モデル ID としては gemini-embedding-2-preview が公開されており、テキストだけではなく画像、動画、音声、PDF といった入力も扱えるようになっています。
ちなみに、Vertex AI では multimodalembedding@001 というマルチモーダルの埋め込みモデルも以前からありました。
なので「Google Cloud で初めてマルチモーダルの埋め込みができるようになった」というよりは、Gemini 系の埋め込みモデルでもマルチモーダル入力を扱えるようになった、という理解が近いかなと思います。
性能比較 まず gemini-embedding-001 と Gemini Embedding 2 (gemini-embedding-2-preview) の違いのうち、最初に見たいのは扱える入力とサイズ感かなと思います。
ざっくり比較すると以下のようになります。
項目 gemini-embedding-001 gemini-embedding-2-preview 入力 テキスト テキスト、画像、音声、動画、PDF 最大入力トークン 2,048 8,192 出力次元数 最大 3,072 最大 3,072 次元数の調整 可 (outputDimensionality) 可 (output_dimensionality) トークン数だけ見ると Gemini Embedding 2 のほうがかなり余裕があります。
Continue reading ↦