ただ、実務でデザインがM3に沿っているケースはあまり多くない印象です。Figmaを開くと Brand/Blue/500 や Neutral/100 といった独自トークンが並んでいたり、HIGベースの命名になっていたりすることの方がだいたい多いです。なので個人的には ThemeExtension に寄せておく方が潰しが利くと思っています。 この記事ではそのあたりの理由も含めて順番に説明します。 よく見る例 AppColors に全色を定義してWidgetから直接参照する、よくある構成です。 これで動くし一箇所にまとまっているし、問題ない気がします。 abstract class AppColors { static const primary = Color(0xFF4F46E5); static const background = Color(0xFFFFFFFF); } Contain
はじめに こんにちは。データエンジニアの山口歩夢です。 以前、Claude CodeとPlaywright CLIを使ってStreamlitで作ったアプリケーションの動作確認レポートを自動作成するスキルを作りました。 対話形式で動作確認手順をClaudeに指示すると、Playwright CLIがStreamlitアプリを動かして、指示した通りに操作して、動作確認手順をスクショ付きで出力してくれると言ったものです。どんな風にレポートが出力されるのかは、以下の記事をご確認ください。 そして、今回はこちらをGitHub Actionsに組み込んで、PRを出した時に自動で動作確認レポートを作成できるようにしてみようという挑戦をしてみたので、工夫した点を色々と紹介してみようと思います。 完成イメージ この機能を使うと、動作確認手順書（ここでは、docs/operation_check.mdとします
こんにちは、坪田です。 前回のClaude記事で触れた、Claude CodeやAI最適化したデザインシステムを作ってみたのでまとめです。 Claude Codeが生成するUIの品質が安定しない課題最初の頃は、何か作っても 「いかにもAIが作りました」感のあるデザインで生成されてしまう ストレスがあって、例えば、コンポーネントに強めのシャドウをかけたり、カードUIの上部に強めのカラーバーを付けたりしてイマイチだった。 「いい感じに」とか「シンプルに」と指示してもダメで、AIには「いい感じ」の基準がなく、 基準がないから、学習データの中で「よくあるデザイン」を確率的に再現してしまう。 その結果、同じプロダクトなのに、画面ごとに微妙にボタンの高さが違ったり色のトーンがズレる、スペーシングがバラつくし、AIはやたらと絵文字を多用するのが課題だったので、Claude Code開発に適したデザインシ
Go-style error handling for TypeScript. Unions instead of tuples. instanceof instead of nil checks. In Go, functions return errors as values instead of throwing exceptions. errore brings the same convention to TypeScript—but instead of Go's two-value tuple (val, err), you return a single Error | T union. Instead of checking err != nil, you check instanceof Error. TypeScript narrows the type automa
後編はこちら！: 「アーキテクチャ図はもう要らない」は本当か？ ── LLM時代のC4モデル再考 「アーキテクチャ図」の曖昧さ 「アーキテクチャ図」を作成するとき、どのような図を描くかはチームや個人によって異なることがあります。 例えば、「ユーザーが画面から帳票をPDF出力でき、出力の結果をメール通知する」ようなシステムの場合、以下のような図が描かれることがあります。 例1 - スライド 例2 - draw.io どちらも「アーキテクチャ図」として正しいです。しかし、このような図を継続的にメンテナンスしていこうとすると、以下のような課題に直面します。 フォーマットがバラバラ PowerPoint、Googleスライド、draw.io、.. 人によって使うツールが異なり、編集できる人が限られる 粒度がバラバラ ある人は例1のようなシンプルな図を描き、別の人は例2のような詳細な図を描く 「どこ
はじめにこんにちは。TIG（Technology Innovation Group）の亀井です。 フューチャー社内の有志メンバーで 非同期設計ガイドライン を作成し、公開しました！ 本記事では、ガイドライン策定の背景や、ガイドラインで取り上げている設計のポイントをピックアップしてご紹介します。 本ガイドライン策定の背景かつて非同期処理といえば、専門的なメッセージングミドルウェアを必要とする、一部のミッションクリティカルなシステムで採用される特別な技術でした。フューチャーでも独自のミドルウェアフレームワークを構築して、大量データをリアルタイムで処理するような仕組みを数々の工夫を凝らして実装してきました。 一方で、昨今ではAWS SQSなどのクラウドネイティブなサービスの登場により、応答時間の長い処理のオフロードなどを目的に非同期処理を取り入れることは珍しくなくなりました。 しかし、非同期特有
還元率の高さが、前から不思議だった。65、70、75、80%還元！とか。最大90%を謳う会社もあるようです。 単価80万で65%渡すと、52万。残り、28万。社保会社負担や諸々経費引いたら、残っても15。どうやって回すんだと思っていたら、基本給とは全然別なんだって。 見聞きした高還元SESの仕組み 辞めたけど働いていた人に聞いたり、ネットで公開されている情報をかき集めた。 基本給は爆安。20前後に抑えられる。 案件のアサインがインセンティブと連動し、売上〜万円超は〜円バック。この比率が高いことを高還元と謳っている。歩合制の営業じゃん。 社保負担分を差っ引いて還元するケースもある。 待機になった時の扱い、会社都合と自己都合を分けるケースがあり、休業扱いにして基本給の60%しか支払わない会社もある。 時給制ですから、フルコミ前提。140H以下の場合はインセンティブ満たせませんで還元額が下がるこ
目次 目次 はじめに この記事の対象読者 背景・課題 背景 課題 AI駆動開発ワークフローの概要 AIサービスごとの役割 Devin Playbook ユーザー起動のPlaybook（Slack → Devin） !ai_task（単一タスク実装） !ai_tasks（タスク分割＆並列実装） !human_review（人間承認フロー） 人間レビューが必要なケース ワークフロー自動呼び出しのPlaybook !fix_ci_failure（CI失敗時の自動修正） !fix_review_comments（レビュー指摘の自動修正） !context_curation（AIコンテキストの週次更新） 使用技術 機能一覧 アーキテクチャ SlackからPR承認までの完全フロー 2つのワークフローの役割 フロー別の使い分け 実装 設定ファイル AI Task Implementation：Issue
今年、大学院入試の取りまとめ役をやっていたのですが、私が所属してる専攻は教員が100人ぐらいいるんですけど、毎年1名のメイン担当がほぼすべての情報を把握し、ほぼすべての書類を作成するので、けっこう大変でした。夏の院試は170人ぐらい、冬の院試は30人ぐらいが受験していて、一斉に行われる筆記試験はともかく、1人1人違う時間、違う部屋で行う面接試験のスケジュール管理などは非常に神経をつかう仕事で、面接官をやる先生もすべて変わるので、誰に何を依頼するか間違えそうでハラハラします。大学院入試というのは案外複雑な制度で、受験資格や試験のカテゴリが何種類もあるので、「この人にはこの書類でよかったっけ？」というのがよく分からなくなりがちです。 で、受験生ごとの個別資料にせよ全員に関わる共通資料にせよ、「去年までの書類をベースに、日付や名前や番号だけを書き換える」という作業がとても多く、こういうものは自動
はじめにTechnology Innovation Groupの八木です。 フューチャー社内の有志メンバーでログ設計ガイドラインを作成し公開しました！ ログは、システムの稼働状況を可視化し、トラブルが発生した際に迅速に原因特定するための生命線になります。しかし、その重要性の一方で、プロジェクトごとに設計がバラバラになりがちだったり、とりあえず標準出力しているだけになっていたりと、十分に活用しきれていないケースも多く見受けられます。 本記事では、今回公開したログ設計ガイドラインの背景や、現場で役立つ設計のポイントを抜粋してご紹介します。 ガイドライン作成のモチベーションこれまで、ログ設計は個々のエンジニアの経験則や、プロジェクトごとの慣習に委ねられることが多くありました。しかし、システムが複雑化し、マイクロサービスやクラウドネイティブな構成が当たり前になった現代において、ログの役割は「単なる
RAGの精度評価をRagasで自動化してみた：いつまで「目視確認」で消耗してるの？ はじめに：「なんとなく動く」からの脱却 RAG（Retrieval-Augmented Generation）アプリケーション開発における最大の敵は、開発者自身の「主観」だ。 「いくつか質問してみたけど、いい感じに回答してくれている気がする」 「プロンプトを変えたら、なんとなく良くなった気がする」 PoC（概念実証）段階ではこれでも許されるが、プロダクション運用やチーム開発において「気がする」は通用しない。上司やクライアントからの「で、精度は何％なの？」という問いに、数字で答えられなければエンジニアとしての信頼に関わる。 そこで導入するのが、**「LLM-as-a-Judge（LLMを用いてLLMを評価する）」**フレームワークである Ragas だ。この記事では、Ragasを用いてRAGの精度を定量的に計
あちきも・・・これ、すごい思う・・・ pyama.fun 2025年時点では、僕にもない。部分的に使うことはあると思うけど。 生成AIに抱かれたプロダクトを作るのが怖い 理由は単純で、自分には生成AIのモデルを自作する能力がなく、誰かの肩に乗っかるしか無いため。 生成AIを使ったコーディングそのものは、どのモデルを使っても大枠同じ。動かすだけなら、1日。プロンプトを投げるだけだから。 問題は、アウトプットの均質化が極めて難しいこと。モデルが変わるだけで、同じプロンプトでも回答が変わる・観点が変わる。似たようなデータを食わせても、僅かな違いが大きなズレとなって、パーソナライズの障壁となる。 人が見たら「これはすごくうまい例えで良い」と評価される文章だとしても、AIが見たら「説明が足りてないのでは」みたいな評価になり得る。 それらの「ズレ」を直すにしても、モデルでやってるロジックがわからない。
はじめに こんにちは、新規事業部フロントエンドブロックの安土琢朗です。普段はZOZOマッチのFlutterアプリ開発を担当しています。 ZOZOマッチは2025年6月にリリースされた、ゼロから立ち上げたマッチングアプリです。zozomatch.jp本記事では、開発初期から取り組んできたデザインシステムの導入によって、どのように開発効率とUIの品質を向上させたか、そしてそれを支える具体的な運用プロセスや仕組みについてご紹介します。 プロダクトを継続的に成長させるうえで、デザインと実装のズレを最小化し、誰が開発しても一定の品質が保たれる状態をどう実現するかは重要なテーマです。その課題に対し、私たちはデザイントークン・UIコンポーネント・UIカタログを軸にしたデザインシステムを構築しました。 目次 はじめに 目次 デザインシステム構築の背景と課題 デザインシステムとは なぜデザインシステムが必要
こんにちは！運用イノベーション部の大野です。 最近ひょんなことから知り合ったカナダ在住エンジニアの方に、「UI作成ならStitchが便利」というお話を伺いました。 ...が恥ずかしながら「Stitch」について全くの無知だったため、軽くですが実際に触って確かめてきました。 今回はその感想を共有させていただきます。 Stitchってなんだ？ Stitchとは、Google Labs提供のUIデザイン生成支援用AIツールです。 2025年5月に行われた「Google I/O 2025」にて発表されました。 自然言語や画像を入力として与えることで、AIによってWebやモバイル画面のUIを生成してくれる機能を持っています。 また、生成したUIをHTMLコードとして表示することや、Figmaに直接エクスポートすることが可能です。 UI生成可能なAIツールは他にも多数存在しますが、以下の点においてSt
How Functional Programming Shaped (and Twisted) Frontend Development A friend called me last week. Someone who’d built web applications back for a long time before moving exclusively to backend and infra work. He’d just opened a modern React codebase for the first time in over a decade. “What the hell is this?” he asked. “What are all these generated class names? Did we just… cancel the cascade? W
PeopleX社でフロントエンドエンジニアをしている芹澤（せりざわ）です！社内では「せりせり」や「せりちゃん」と呼ばれています。みんなとランチに行くのが趣味です！ 私がフロントエンド開発を担当している 「PeopleX AI面接」 というプロダクトでは、shadcn/ui をベースにしたデザインシステムを構築しています。今回この記事では、なぜshadcn/ui を採用しているかに加え、それをどのようにカスタマイズしながら運用しているかを、実践例を交えながらご紹介できればと思います。 そもそも shadcn/ui とは？ shadcn/ui は、Radix UI のプリミティブに Tailwind CSS を組み合わせて構築された React コンポーネントライブラリです。 最大の特徴は、npm パッケージとしてではなく CLI 経由でコードを直接プロジェクトに取り込むスタイルである点です。
はじめにこんにちは。TIGの長谷川です。 フューチャー社内の有志メンバーでWebフロントエンド設計ガイドラインを作成し公開しました！ 本ガイドラインではガイドライン策定の背景やガイドラインの特徴に加えて、内容の一部をピックアップしてご紹介します。 本ガイドラインの背景昨今のWebフロントエンド領域は、単なるHTML、CSS、JavaScriptでのページ制作から大きく変化しました。React、Vue.jsなどのモダンなフレームワークを活用した大規模かつ動的なWebアプリケーションの構築が主流となっています。 これにより開発の効率化とユーザー体験（UX）が向上しています。しかし一方で、設計の考慮点も多様化し、セキュリティやアクセシビリティなど、より多面的な品質も求められるようになりました。 本ガイドラインでは、Webフロントエンド設計における考慮点・設計パターン・推奨手法を提示し、開発チーム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
