はてなブックマーク

はじめに Claude Code を長く使っていると、CLAUDE.md が太ります。過去の失敗パターン、ワークフロー、ツールの使い方を書き足すたびに、ファイルが肥大化していきます。 気づいたら 2000 行近くまで育ち、どんな小さな作業でも毎セッションで全文を読み込ませていました。タスクに取りかかる前から、過去の注意書きだけでコンテキストの大部分を使っている状態でした。 この記事では、そこから 起動時のコンテキスト消費を約 83% 削減 するまでの試行錯誤を書きます。結論だけなら「rules/ と skills/ に切り分けた」ですが、2 ヶ月かけて行きつ戻りつしながら削った記録の方が実用的なので、そちらを中心に書きます（実測値は後半）。 最初はこうだった（失敗の出発点） 過去の commit ログを掘り返すと、2 月時点で以下のような状態でした。 SuperClaude Framewo

Claude Codeを複数ペインで並列に動かしても、画面を見続けていたら1本しか進みません。 ターミナルを分割して3本のClaude Codeを起動する。すると承認ダイアログが出るたびに目が吸い寄せられ、エラーが出れば手が止まり、うまくいっているか気になって経過を眺めてしまう。結果、3本動いているのに実質1本分の生産性しか出ない。 並列数の上限はツール側にあるのではなく、「張り付き」という人間側のボトルネックにありました。この記事では、張り付きをやめるために自分がやったことを書きます。現在は5〜6本のワークストリームを同時に回しており、各ストリーム内でさらにサブエージェントが最大6本並列で動くこともあります。 「張り付き」が生まれる3つの原因 まず、なぜ画面から目が離せないのかを整理しました。 1. 承認ダイアログの待ち Claude Codeはデフォルトでファイル編集やコマンド実行のた

Claude Codeでコードを書いてPRを出す。レビューで指摘を受ける。直す。次のPRでまた同じ種類の指摘を受ける。 Claude Codeはセッションをまたぐと記憶をリセットします。これが根本的な問題です。プロンプトをどれだけ丁寧に書いても、新しいセッションでは前回の学びが消えて最初からやり直しになります。 必要なのはプロンプトの工夫ではなく、過去の失敗を蓄積してセッションをまたいで読み込ませる仕組みです。 この記事では、レビュー指摘をClaude Codeの設定ファイルに蓄積し、同じミスを繰り返させなくする「失敗学習ループ」を紹介します。3ヶ月運用した結果、同種のレビュー指摘が繰り返されることはほぼなくなりました。 実例：レビュー指摘から生まれたルール 仕組みの説明の前に、実際にPRレビューで指摘を受けて記録した教訓を紹介します。「こういうものを記録するのか」というイメージを持っても

Claude Codeでブラウザ操作をしていて、ツール選びに迷いました。候補は5つ、アプローチもバラバラ。全部インストールして10項目テストした結果、用途によって最適解の変わることがわかりました。 先に結論: 認証管理ならplaywright-CLI。エージェントの操作基盤ならagent-browser。自然言語で自律操作ならbrowser-use。大量クロールならLightpanda。本番インフラならsteel-browser。 本記事ではCLIモードでの比較を中心に行っています。browser-useのようにLLMエージェントモードが本来の強みであるツールもあり、その観点での評価は別の記事で扱う予定です。 比較した5ツール ツール Stars 言語 ライセンス 開発元 一言で言うと

CIが8分を超えていました。1日に10回pushすれば、待ち時間だけで80分になります。開発のテンポが悪くなるし、プルリクエスト（PR）のフィードバックループも遅れます。 結果から書くと、CI実行時間を8m08s → 3m37sまで短縮できました。55%の削減です。しかも最初のPRではプロダクションコードの変更は一切なく、CI設定とDB設定だけで47%削減しています。 この改善はRailsアプリのCI（GitHub Actions、matrix 5分割、MySQL使用）で行ったもので、似た構成のプロジェクトならそのまま適用できる部分が多いはずです。この記事では、インフラ層の最適化（第1弾）とアプリ層の最適化（第2弾）の2段階に分けて、やったことを順に書いていきます。 改善の全体像 — なぜインフラ層から着手したか 改善前のCI構成 対象はRailsアプリのCIで、GitHub Action

Code Reviewerには「門番ではなくメンターとして振る舞え」という指示を入れています。指摘も Must Fix（必須修正）/ Should Fix（推奨修正）/ Consider（検討）/ Nitpick（好みレベル）の4段階に分けさせることで、重要度が一目でわかるようにしました。 これらを Claude Code の Agent tool で run_in_background: true にして並列起動します。PR差分を取得してファイルを backend / frontend / test / config に分類し、各レビュアーに関連ファイルだけを渡します。6人が同時に動くので、直列に6回レビューするより待ち時間が短くなります。 「指摘ゼロまで回す」収束ループ レビュー結果を受け取ったあと、ただ人間に渡すだけでは物足りません。自動で直せるものは直して、再レビューに回します。こ

きっかけ nokogiriさんの記事を読んで、自分も晒してみようという気持ちになりました。もう10年以上dotfilesを育てていて、chezmoiに移行してからは新しいMacでもchezmoi apply一発で環境が再現できるようになっています。 この記事では、grep/rm/findをモダンCLIに置き換えた設定と、fzfを使ったキーバインド、ターミナルの使い分けを紹介します。 ツール一覧 まず全体像から。Brewfileで管理しているツール群を用途別にまとめました。 用途 ツール 何をするか

はじめに 個人サイト yoshikouki.com は、以前 Next.js × Vercel で運用していましたが、最近 Hono + Cloudflare Workers に乗り換えました。理由はいくつかありますが、Next.js はいくつかの観点で過剰だと感じていたこと、単純に Hono が好きなこと、そして Hono と React の実用的な組み合わせを研究したかったという動機があったためです。 乗り換えた当初、RSC (React Server Component) は使用せずに Hono middleware の react-renderer による SSR の構成でした。しかし React の強力な機能である RSC をHono の上でも動かせないかと考えました。Next.js に戻るのは違う。Hono でやりたい。 そこで RSC そのものの仕組み — Server Co

はじめに Claude Code で複数タスクを並行して進めるようになり、Git Worktree で複数の Docker Compose 環境を同時に動かす場面が増えました。そこで地味に困るのがポート競合の問題です。本記事では、Docker Compose の標準機能だけでこれを解決する方法を紹介します。 なぜ並列に動かしたいか Claude Code の良いところは、タスクを渡すとかなりの部分を自律的に進めてくれるところです。コードを書いて、テストを回して、修正して…という一連の流れを任せられます。 しかし、1つのブランチで1つのタスクしか進められないと、Claude Code がテストを回している間やビルドしている間は待つだけになってしまいます。それなら別のブランチで別のタスクを並行して進めたいですよね。 そのためにはブランチごとに独立した開発環境が必要になります。DB もコンテナも

分類の観点としては以下を総合的に判断するようにしています。 変更が影響するコンポーネントやモジュールの数 既存の振る舞いへの影響度（インターフェース変更、DB変更、API変更など） 変更の波及範囲（他の機能やサービスへの影響） リスクの大きさ（決済・認証など重要ドメインへの関与） 2. AIによるコードレビューとApprove 同じworkflowの中で、AIがコードレビューも実施します。レビューの観点は人間のレビュアーと同じです。 コード品質とベストプラクティス 潜在的なバグ パフォーマンスへの影響 セキュリティの問題 テストカバレッジ そして、上記の観点で重大な問題がなければ、AIがApproveをsubmitします。 3. XSラベル × Approve済み → auto merge 最後のピースとして、以下の条件をすべて満たすPRでauto mergeを有効化するようにしました。

はじめに 2026年1月20日時点での開発環境です！開発環境現状確認の流れになってみます。 Claude Codeを多用することによって、2025年や2024年と比較してガラッと開発環境が変わってしまいました。そんなことがあった今日の開発環境を、開発環境2026として、アウトプットします！ AIを前提として開発や業務をすることを重要視しつつ、これまでの開発環境から徐々に変えていくようにしました。開発環境の一例として参考になれば幸いです。 また、AIに入力する情報としては社内ポリシーに従い利用しています。 開発環境2026 OS macOSを使っています。プライベートではWindowsのデスクトップPCとMacBookを使っています。仕事とプライベート共通の方がなにかと楽だなと言う次第です。 AI Claude Max を契約しています。コーディングには Claude Code、その他の作業

はじめに Claude Code（Anthropic公式のCLIツール）を使って日々の作業をしていると、有益な会話がセッション終了とともに消えてしまうのがもったいないと感じていました。 そこで、Claude Codeとの会話を自動的にObsidianに記録する仕組みを作りました。本記事ではその実装方法を紹介します。 やりたいこと Claude Codeでの会話を自動的にMarkdownファイルとして保存 Obsidianで管理しているナレッジベースに統合 手動操作なしで、会話のたびにリアルタイム同期 ノイズ（システムメッセージなど）を除去してクリーンな記録を残す 仕組みの概要 Claude Code セッション ↓ (jsonlファイルに記録) ~/.claude/projects/*/session.jsonl ↓ (5秒ごとに監視) watch-and-save.sh (LaunchA

JS/TSを長く触れていると、無意識に受け入れてしまっている不便さがあります。その一つが、TypeScriptにおける非同期処理のエラーハンドリングです。 async/await の登場で非同期処理は劇的に書きやすくなりましたが、その裏で私たちは try-catch ブロックのネストと、型安全性の喪失という新たな問題と戦い続けてきました。 今回は、そんなモヤモヤと向き合った結果、 最終的に try-ok という小さなライブラリを作った話です。 私たちが抱える「try-catch」のモヤモヤ TypeScriptで非同期処理を書くとき、誰もが一度は以下のようなコードを書いたことがあるはずです。 async function getUser(id: string) { try { const user = await api.fetchUser(id); return user; } catc

私は長い間、毎日Web上に日記を書いています（紙の日記から含めると30年以上は書いています）。 npakaさんが「そらみ と へにへに のゆるふわAI研究所」という漫画連載をしているのを見て、AIに絵日記風のマンガを生成できるとふだんの日記と違う表現ができるかも？と思って、CLIツールenikkiを作りました。 enikkiとは enikkiは、テキストで入力したストーリーから絵日記風のマンガを自動生成するCLIツールです。GoogleのGemini 3を使って、脚本生成から画像生成までを一気通貫で行います。 主な特徴は以下の通りです： 対話型UI: ストーリー、スタイル、コマ数などを対話形式で入力できます 19種類のスタイルプリセット: 4コマ漫画、少年漫画、少女漫画、Webtoon、アメコミなど ステップごとの確認: 脚本・画像それぞれで確認・再生成が可能です キャラクター画像の参照:

2025年8月15日、Anthropic社からClaude Codeの新機能として「output-style」が発表されました。この機能により、開発者や学習者は自分の学習スタイルに合わせてClaudeとのコミュニケーション方法をカスタマイズできるようになりました。 output-styleとは？ output-styleは、Claude Codeにおけるコミュニケーションスタイルをカスタマイズする機能です。/output-styleコマンドを使用することで、Claudeの応答方法を自分の学習目標や作業スタイルに合わせて調整できます。 標準で提供される3つのスタイル 1. Default（標準）スタイル 特徴： コーディングタスクを効率的に完了 簡潔で要点を絞った応答 通常の開発作業に最適化 適用シーン： 日常的な開発作業 効率重視でサクサク進めたい時 基本的なコーディングサポートが欲しい時

Effective Typescriptな勢いで書いています TypeScriptで開発していると、外部APIのレスポンスや設定ファイルの読み込みなど、実行時まで型が確定しないデータを扱うことがよくあります。このような場面でasを使った型アサーションに頼ってしまうと、ランタイムエラーのリスクが高まります。 本記事では、Zodのz.infer（型推論）、parse（ランタイム検証）、refine（カスタムバリデーション）、transform（データ変換）を使って、as型アサーションを避ける方法をまとめます。 従来の問題：型アサーションの危険性 Before: 型アサーション // 危険な例：型アサーション interface User { id: number; name: string; email: string; age?: number; } async function fetch

Claude Codeに関して、どわーーっといろんなノウハウが各所で散見されていて、辞書的な記事があったらいいなと思い、これを書いています。 いざ1から使い始める時に、これさえ読めば、ある程度使いこなせることを目指して、この記事を書きました。 細かい話はいろいろなところで書かれていると思うので、ざっくりと書いていきます。 社内で行ったチュートリアル資料です。 Claude Codeとは？ ターミナル内で動作し、コードベースを理解し、自然言語コマンドを通じてより高速なコーディングを支援するエージェンティックなコーディングツールです。 Cursorとかと違って、ターミナルで動くAIコーディングツールってことです。 そもそもなんでClaude Codeが強いの？ なんだか AIコーディングツールで、同じくSonnet4/Opusとか使うんだったら、CursorやClineでも同じじゃない？ と思

はじめに 2025年3月、Google Pixel & Android 15でLinuxターミナル環境が使えるようになりました。Google Pixelユーザーは追加のアプリをインストールすることなく本格的なCLI環境を手に入れられます。 この記事では、Android 15の新機能「ターミナル」を有効化し、Claude Codeをセットアップする手順を紹介します。また、最後に現時点での注意点も紹介します。 Android 15のLinuxターミナルとは Android 15で導入されたターミナルの主な特徴は次の通りです。 完全なDebianベースのLinux環境であり、aptを使ってツールやライブラリを自由にインストールできる。 アプリはセキュアな仮想マシン上で動作するため、Androidシステム本体から隔離され、安全性が保たれる。 デバイスをroot化したり、サードパーティアプリをインス

はじめに モバイルアプリ開発において、画面遷移のテストやUI/UXの確認作業は重要な工程ですが、手動で行うには時間のかかる繰り返し作業でもあります。 今回、AIエージェントがモバイルアプリを自動操作できる「Mobile MCP」をAndroidアプリで試してみました。まだiOSでは試していませんが、同様に使えるようです。 本記事では、Mobile MCPの機能概要と実際に使ってみた体験をもとに、モバイルアプリ開発での活用可能性について紹介します。 Mobile MCPとは Mobile MCPは、iOS・Android・エミュレータ・シミュレータ向けのMCPサーバーです。エージェントがネイティブiOS/Androidアプリケーションとデバイスを、構造化されたアクセシビリティスナップショットまたはスクリーンショットベースの座標タップを通じて操作できます。 GitHub: https://gi

Claude Codeを使ってコーディングを進める上では、適切な通知設定によって、別の作業をしている際などにもタスク完了を見逃さないための工夫を皆さん試されていると思います。 公式のガイドでは、タスク完了時のサウンドアラートを有効にする方法が紹介されています。 ただ個人的には、Claude Codeがタスクをこなしている間はPCから目を離して音楽やラジオを聴いていたりしていることもあり、画面上の情報や音での通知を見逃してしまうことがあります。 そのため今回は、空間にいるだけで視覚から完了を知ることができるように、光で感じられるようにしてみました。 用意するもの 今回は部屋の照明の色を変えることで、Claude Codeのタスク開始、完了を検知したいと思います。 使うものはPhilips Hue スマートライトとHue ブリッジです。 Philips Hueは、Wi-Fi経由でプログラマブル

はじめに Claude CodeでAWS BedrockのClaude Sonnet 4を使用していると、並列実行時に「429 Too many tokens」エラーが頻発する問題に遭遇することがありませんか？同じような事象に直面する方を想定読書とします。 私も実際にこの問題に悩まされ、調査した結果、緩和方法を見つけることができました。この記事では、その原因と緩和方法について詳しく解説します。 前提・環境 Claude Code（旧Claude CLI）を使用 AWS Bedrock経由でClaude Sonnet 4を利用 並列でのリクエスト実行 ちなみに並列実行にあたっては、弊社CTOのこちらの記事『claude-tilex: git worktreeと連携してClaude Codeを並列実行する』を参考にしました。 経緯・発生した問題 Claude CodeでBedrock Clau

NotebookLMは、Googleが提供するAI搭載のノートブック機能で、既に多くの人がさまざまな用途で活用していることでしょう。 しかし、NotebookLMは現時点(2025/06/09)ではAPIが提供されていないため、複数のソースを一括で流し込むことができず、一旦手元でテキスト化したり、各ソースの手動でのアップロードが必要になってしまい面倒です。 この記事では、Playwright MCPを使ってNotebookLMに自動でソースを流し込む方法を紹介します。 Notion MCPとの連携 今回は、Notion MCPとPlaywright MCPを併せて使うことで、NotionからNotebookLMへのソースの流し込みを実現します。 各種MCPの概要やセットアップは省略するのでこの辺の公式ガイドを参照してください。 今回はCursorでそれぞれのMCPを読み込みました。Play

※ 当記事は、さくらじまハウス 2024 のLT「レンダリングを探訪する」 の書き起こしとして作成しました。 LT資料: はじめに この記事では、ブラウザのレンダリングについて掘り下げていきます。Web アプリケーション開発において、パフォーマンスの最適化や複雑なバグの解決は日常的な課題です。ブラウザのレンダリングフローを理解することで、それらの原因をより深く突き止めることができるようになります。 ブラウザと一口に言っても数多く存在しますが、今回は多くのブラウザで採用されている Chromium を題材に、そのレンダリングの仕組みを詳しく見ていきます。Chromium は Google Chrome、Microsoft Edge、Opera などで採用されているため、その仕組みを理解することは Web アプリケーション開発者にとって大きなヒントとなるでしょう。 ※ シェア列は、資料作成時点

※ 更新: 2024/10/20 はじめに Biome は JavaScript や JSON 向けの強力なコード品質管理ツールですが、数多くのルールの中から適切なものを選ぶのは難しい場合があります。この記事では、私が Biome を使う際に最低限入れておくルールを紹介し、それぞれの具体的な使用例を解説します。 基本設定 公式ドキュメント「Getting Started」に記載されている基本設定は以下です { "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json", "vcs": { "enabled": false, "clientKind": "git", "useIgnoreFile": false }, "files": { "ignoreUnknown": false, "ignore": [] }, "formatt

ArcというブラウザをWebアプリケーション開発で利用してみました。使ってみて便利だったので、機能を紹介しようと思います。 Arcについて MacとiOSで利用できるWebブラウザです。執筆時点ではWindowsは対応していませんでした。 また、Chromiumを使用しているためChrome拡張も利用できます。 便利だった機能 Splite View ひとつのウィンドで同時に複数のサイトを開けます。 なので、左半分はChatGPTを常駐させ、右半分ではGithub、localhostなどを開くことができます。 Developer Mode Developer Toolが使えるのはもちろんですが、ArcのUIを開発者に適した状態にする「Developer Mode」が存在します。Developer Modeを有効化すると、上部にアドレスバーとショートカットボタンが表示されます。 上部にあるシ