Boris Cherny氏の知見を元に作成された、CLAUDE.mdを理解する - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Playwright + Amazon ECSでE2Eテストが秒で廃墟になる問題を解決する
はじめに こんにちは！ 株式会社エクスプラザのhyodoです！ E2Eテストの自動化を導入して3ヶ月後、こんな会話が聞こえてきたことはありませんか？ 「このテスト、また落ちてるけど誰か見てる？」 「あー、それいつも落ちるやつだから無視して大丈夫」 自動テストがあるのに誰も信用していない。書いた本人しかメンテできない。エンジニアのPCでしか動かない。——結局、数ヶ月で誰も触らなくなる。 これ、自動化の「やり方」ではなく「届け方」に問題があるケースが多いです。 今回は、QAメンバーやPMがブラウザからボタンひとつでE2Eテストを実行・結果確認できる環境をPlaywrightとAWS ECSで構築したので、その設計と実装を紹介します。 なぜE2Eテストは廃墟になるのか 自動テストが使われなくなる原因は、だいたい以下の3つに集約されます。 テスト結果を誰も信用しない。 HTMLの構造をちょっと変え
論理削除という技術的負債、それでも僕たちは使い続ける - じゃあ、おうちで学べる
はじめに 「論理削除？deleted_atカラム追加すればいいでしょ」この一言から始まる地獄を、何度見てきただろうか。 最初は簡単に見える。カラムを1つ追加するだけ。しかし、その「簡単さ」こそが罠だ。 論理削除は技術的負債の温床だ。WHERE句への条件追加忘れ、認知コストの増大、テストの複雑化、パフォーマンス劣化。すべては「最初にドメインを考えなかった」ツケである。 しかし現実として、サービスを運用していくと論理削除が必要になる場面は確実に訪れる。 論理削除の本質は、「このレコードは存在するが、存在しないことにしてほしい」という矛盾だ。この矛盾を解消するか、受け入れて安全に管理するか。本記事ではその両方のアプローチを解説する。 なお、私はDBのスペシャリストではないので、ここで紹介する方法が唯一の正解というわけではない。あくまで一つのアプローチとして参考にしてほしい。データベース設計は文脈
Claude Codeのコンテキストウィンドウを完全に理解する | gihyo.jp
「Claude Code」は、CLI上で動くLLMによるAIエージェントツールです。この記事は12月5日に発売された『Claude CodeによるAI駆動開発入門』に書ききれなかった応用的な内容や最新のアップデートについて解説します。書籍をあわせて読むとさらに理解が深まることでしょう。 コンテキストウィンドウを制するものは開発を制する Claude Codeの「コンテキストウィンドウ」とはなんでしょうか。 Anthropicの公式ドキュメントから答えると「LLMが新しいテキストを生成する際に参照できるテキストの全体量と、生成する新しいテキストを合わせたもの」です[1]。 簡単に言うと、コンテキストウィンドウの中身は、セッションの中のユーザーのメッセージ（プロンプト）とClaudeのレスポンスを合わせたものです。 下記のコンテキストウィンドウの概念図をご覧ください。 コンテキストウィンドウの
結局CISC/RISC論争とは何だったのか？ - Ryuz's tech blog
はじめに 例によって当事者でもない人間が感想を書く素人考察ポエムです。 先日 こんな 記事を書き、その中で 「 このあたりで１命令で出来ること自体を複雑にするかシンプルにするかでCISC/RISC論争とかがあった気もしますが、今となってはあまり本質ではないのでおいておきます」と、バッサリと話をスキップしたので少しだけ回収しておきたいと思います。 なぜ本質ではないと言ったかというと、先日の記事の趣旨は「演算器の並列稼働率」にフォーカスしたものであり、CISC/RISC という「命令デコーダの効率」に関わる問題はそこで取り上げるべきではないと考えたからです。 事実、RISC の成功例だったはずの ARM は Thumb2 命令以降も複雑化を続けて十分 CISC っぽさを持っていますし、CISC の代表格の x86 もいつの間にやらRISC風の 内部 μ-OPs に変換して実行するようになってい
AWS設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにTechnology Innovation Groupの神崎です。 フューチャー社内の有志のメンバーでAWS設計ガイドラインを作成しました。 この記事では、ガイドライン策定の目的と、その内容を抜粋して紹介します。 ガイドライン策定の目的詳細はガイドライン冒頭に記載していますが、ベストプラクティスを形式知化していくというのが第一の目的です。第二に、設計のベースラインを提供することで、システム固有で考えるべきところ（すなわち設計作業で重要なところ）に時間が使えるようにして、結果として設計品質を底上げできることを目指しています。 そのため、システムを跨いで再利用可能な部分に特に着目しています。 ちなみに、Geminiにガイドラインの目的を問うたところ次の回答でした。上記の思いやエッセンスは取り込めているのではないかと思います。 クラウドファーストが標準となり、システム構築においてAWSを
タイミーで蓄積された Aurora MySQL 運用ナレッジ─ 障害・チューニング・実践知を特別公開 - Timee Product Team Blog
はじめに タイミーで SRE 業務を担当している徳富（@yannKazu1）です。 日々、数千万件のデータと向き合う中で、Aurora MySQL の運用をより良くするための改善を積み重ねています。 本記事では、その中で経験してきた “机上ではわからないリアルな気づきや学び” を、できるだけ具体的にまとめました。 これから Aurora を本気で運用したい方や、同じような課題に悩んでいる方のヒントになれば嬉しいです。 (この記事はTimee Product Advent Calendar 2025の3日目の記事です。) 1. オンラインDDLでも「ゼロロック」ではない ─ ALTER TABLE 実行時の落とし穴 「MySQL のオンラインDDLなら、日中でもサッと ALTER できるよね？」 ──そんなふうに思ってしまうこと、ありますよね。 たしかにオンラインDDLはとても便利で、データ
$1で最大8時間の動画を話者分離・文字起こし・LLM分析するAWSパイプラインを作った
TL;DR 月額固定費 約$2（Secrets Manager + ECR + ログ）で話者分離付き文字起こしパイプラインを構築 AWS Step Functions + Lambda のフルサーバーレス構成 pyannote.audio 3.1 で話者分離、faster-whisper で文字起こし、gpt-5-mini でLLM分析 8時間の動画処理が 約$2.3（x86、無料枠なし）で完了（AWS Transcribe比で約5倍コスト効率） States.DataLimitExceeded などの落とし穴と解決策を詳解 リポジトリ: https://github.com/ekusiadadus/ek-transcript はじめに ユーザーインタビューの録画を分析する機会が増えてきました。既存サービスを検討しましたが： AWS Transcribe: 8時間で約$11.52（$0.0
「私たちのログ配送、コストかかりすぎ？」fluentdのログ配送に関するコスト削減に取り組んだお話 - freee Developers Hub
はじめに こんにちは！freee のPlatform Engineerをやっているyamaです。 私の所属するCloudGovernance（CGov）チームでは主にAWS関連の権限やコストの統制・可視化・最適化などを行っています。 私は主にコスト統制をメインに担当しています。 この記事はfreee Advent Calendar 2025の7日目になります！ 今回はfreeeにおけるコスト最適化において大きな成果のあった、「fluentdのログ配送に関するコスト削減」についてご紹介いたします。 背景 CGovチームではAWSのコスト可視化・最適化を進めており、AWSのコストを定期的に確認しています。 ある日、AWSのコストエクスプローラを確認していたところログに関連するS3バケットコストの内訳に違和感を覚えました。何気なしにグラフにしてみたところ以下のようになりました。 グラフからもわか
目にやさしい仕様駆動開発「spec-workflow-mcp」がもたらすブルーベリー効果
この記事は、LayerX Tech Advent Calendar 2025 の 2日目の記事です。 初日は @frkake さんの「OCR技術の変遷と日本語対応モデルの性能検証」と、@izumin5210 さんの「思考を減らしコードに集中するための tmux, Neovim 設定」の豪華二本立てでした。 こんにちは、@su8/denchuです。 クラナドは人生。電柱が好きです。現在、マサイ族の驚異的な視力を瞳に宿せると噂の「とあるブルーベリーのサプリメント」（諸説あり）が空前絶後の流行りをみせているバクラク勤怠チームで、ソフトウェアエンジニアをしています。 平均視力は3.0～8.0と推測され、中には12.0の数値を出すマサイ族もいるらしい。12...? 本記事では、大量のドキュメントレビューで目の疲れを感じやすい仕様駆動開発（SDD）に対して、いわば「仕様駆動開発におけるブルーベリー」と
DeNA、「AIエンジニアが本気で作った」LLM勉強会資料とコードを全公開 非エンジニアも学べる
DeNAは12月5日、社内で実施した大規模言語モデル（LLM）勉強会の資料とソースコードを、エンジニアブログやGitHubを通じて公開した。 講義のスライドと、そのまま実行できるPythonコードを通じて、LLMの基礎知識からプロダクト開発に必要な応用知識までを網羅した。 公開したのは、新規AIプロダクト開発に携わるプロダクトマネジャーやエンジニア向けに行われた3時間の社内勉強会の資料。入社6年目のAIエンジニア・吉田（@birdwatcherYT）さんが担当した。 資料の前半では、LLMの基本概念や、プロンプトエンジニアリングを解説。プロンプトの基本的なテクニックから、良い例・悪い例などを通じて、詳細に学べる。後半では強化学習やファインチューニング、RAG（検索拡張生成）、AIエージェントの設計手法まで踏み込んだ。 ハンズオンは、Pythonを使ってAPIを呼ぶ形式。基本的なAPI呼び出
アーキテクチャ設計の民主化とADR(Architectural Decision Records)による意思決定の未来 - Facilitating Software Architecture の読書感想文 - じゃあ、おうちで学べる
年末年始の慌ただしい時期に、数ある選択肢の中からこちらの記事をお読みいただき、誠にありがとうございます。 人生を定期的に振り返ることには、本書で取り上げられているADR（Architecture Decision Records）に通じる素晴らしさがあります。過去の決定とその背景を記録し、将来の自分や他者が参照できる形で残すことは、個人の成長にとって貴重な資産となります。そんな観点から今年を振り返ってみると、2024年は私自身にとって大きな試練と変化の年でした。 印象的だったのは、ある時期に突然、技術に対する興味や情熱が完全に失われてしまったことです。それは技術分野に限らず、仕事全般や私生活にも波及し、何をするにも意欲が湧かない、深い無気力状態に陥ってしまいました。 しかし、この困難な時期を経て、いくつかの意味のある変化が生まれました。私は以前から技術書の書評を書いていましたが、これは主に
「Postgres で試した？」と聞き返せるようになるまでもしくはなぜ私は雰囲気で技術を語るのか？ — Just use Postgres 読書感想文 - じゃあ、おうちで学べる
はじめに 「Just use Postgres」という言葉を初めて聞いたのは、いつだったか覚えていません。Twitter か Hacker News か、あるいは社内の Slack か。どこで聞いたにせよ、私の反応は決まっていました。「また極端なことを言う人がいる」と。 「それ、〇〇でもできますよ」——この手のフレーズはもう100回は聞いてきました。そして大抵の場合、その〇〇は専用ツールに置き換えられていきます。技術が専門分化していくのは自然な流れです。 全文検索なら Elasticsearch。時系列データなら InfluxDB。メッセージキューなら RabbitMQ。それぞれの分野に専門家がいて、専用のソリューションがあって、ベストプラクティスがあります。「とりあえず Postgres で」なんて、それは思考停止ではないか、と。でも、心のどこかで気になっていたんです。 www.mann
AWS / Azure / Google Cloud 各コストを Datadog に集約して確認する - MNTSQ Techブログ
はじめに 弊社では AWS を主軸としたインフラ構成をもってプロダクトを展開していますが、一部では AWS 以外にも Azure および Google Cloud も活用しています。それぞれの棲み分けは以下のようなものになります。 AWS：ほとんど全て コンピュート / ネットワーク / ストレージ / DB / セキュリティ etc. Azure：OCR 関連 Google Cloud：LLM を使う処理および OCR 関連 利用規模としては AWS >> Google Cloud > Azure といったものになり、結果としてこれらクラウドベンダーの利用にかかるコスト（利用料金の意。以下本稿では「コスト」を料金を指す意味でのみ用います）割合も AWS が支配的なものになります*1。 これらクラウドベンダーを扱う上でネックになることといえば勿論コストです。各ベンダーそれぞれコスト確認のた
統計学の基本からDatadogのモニタリング機能を理解する
Observabilityを理解するため、目先としてはDatadogを使いこなすため、統計学の基礎知識を振り返りつつ、Datadogの各機能に触れます。 Datadogの使い方を具体的に知りたい人には役立たないので、その仕様がなぜそうなっているのか、背景や違いを理解したい人向け。モニタリング機能は統計学の実装とも言える、という個人的見解が今回の動機です。 Observabilityとは システム内で「あの時どこで何が起きていたか」を知る能力。和訳では可観測性。 単なる監視だけでなく、分散トレーシング、プロファイリング(性能評価)、デバッグも含まれています。 個人的印象としては、分散トレーシングと一緒の文脈でObservabilityの重要性を言われることが多く、分散システムが流行り始めた頃と同時期に必要とされた非機能要件かと感じてます。 統計学の尺度とデータ Datadogで扱うデータを理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
S3を正しく理解するための内部構造の読解
GitHub - ashishpatel26/500-AI-Agents-Projects: The 500 AI Agents Projects is a curated collection of AI agent use cases across various industries. It showcases practical applications and provides links to open-source projects for implementation, illustrat
Amazon Bedrock Knowledge Bases × メタデータ活用で実現する検証可能な RAG 設計
ADRを運用して3年経った僕らの現在地
AI駆動開発を実現するためのアーキテクチャと取り組み