クエリが遅くなった。直そう。ここから問題が始まる プロジェクト管理SaaSを1年ほど運用すると、Issueテーブルが200万行、変更ログテーブルが2000万行を超えてくる。ソフトデリートを採用していれば物理削除されないので、行数は増える一方だ。 最初の兆候はユーザーからの報告だった。「Issue一覧の読み込みが遅くて、フィルターを切り替えるたびに5秒くらい待たされるんですが」。スロークエリログを見ると、フィルター付きのIssue一覧クエリがp95で3秒を超えている。インデックスを追加すれば改善する。スキーマ変更も1つ控えていた。どちらもやること自体は明確だった。 問題は「200万行のテーブルにDDLを打つ」という行為そのものにあった。膨れ上がったテーブルに対するスキーマ変更は、パフォーマンスを改善するための作業が、新たな障害を引き起こす可能性を持っている。治療のための手術が患者を殺しかねな

はじめに こんにちは。データエンジニアの山口歩夢です。 以前、Claude CodeとPlaywright CLIを使ってStreamlitで作ったアプリケーションの動作確認レポートを自動作成するスキルを作りました。 対話形式で動作確認手順をClaudeに指示すると、Playwright CLIがStreamlitアプリを動かして、指示した通りに操作して、動作確認手順をスクショ付きで出力してくれると言ったものです。どんな風にレポートが出力されるのかは、以下の記事をご確認ください。 そして、今回はこちらをGitHub Actionsに組み込んで、PRを出した時に自動で動作確認レポートを作成できるようにしてみようという挑戦をしてみたので、工夫した点を色々と紹介してみようと思います。 完成イメージ この機能を使うと、動作確認手順書（ここでは、docs/operation_check.mdとします

ハーネス層が512,000行の大部分を占めており、19のパーミッション付きツール、6種類のMCPトランスポート（Stdio, SSE, HTTP, WebSocket, SDK, ClaudeAiProxy）、44の未出荷フィーチャーフラグ、そして46,000行のコンテキスト圧縮エンジンが含まれていました。UI層は一見するとターミナルアプリに不釣り合いなほど凝っていますが、これは大量の差分レンダリング・ツール実行ログ・長時間セッションのパフォーマンスを支えるための最適化です。ハーネス層は「ツール・パーミッション・クエリエンジン・コンテキスト管理・メモリ」の5領域に明確に分割されており、各領域が独立してテスト可能な構造になっています。 ハーネスパターン10選 ここからが本稿の中心です。Ken Huang氏（DistributedApps.ai）のチームが流出コードを体系的に分析し、プロダクシ

はじめに AIコーディングエージェントがコードを書く時代になりましたが、エージェントが生成するコードは必ずしもプロジェクトのベストプラクティスに沿っているとは限りません。 「不要な useEffect を使わないで」「prop drilling ではなく Context を使って」——こうしたルールをエージェントにどう教えるか？これは多くの開発者が直面している課題かと思います。 React Doctor は、この課題に対する一つの解決策です。Reactコードベースを静的解析してスコアリングするだけでなく、AIコーディングエージェントの「スキル」として組み込めるという特徴を持っています。 React Doctor とは React Doctor は、Aiden Bai が開発したReactコードベース向けの診断CLIツールです。Aiden Bai は Million.js（17.5k+ st

ある朝、俺はなにか気がかりな夢から目をさまして、自分が寝床の中で一本のチューブに変わっているのを発見した。 俺はチューブだ。AIに投げて、返ってきたものを受け取って、また投げる。ロジックの本質は俺をすり抜けて、構築中のシステムとチャットウィンドウの間を往復している。それは確かに俺の中を通ってはいるが、俺には触れていない。どこにも積み重ならない。 時にはもう少し高度な役回りをすることもある。顧客からの苦情が届く、AであるべきところがBになっている。という具合だ。俺はチューブ以外の役回りが出来たことに内心はしゃいで、意気揚々とコンディショナル・ブレークポイントを仕込む。ここがBであるときにデバッガが止まるようにする。そして顧客と同じ操作をして、デバッガが止まるのを待つ。 デバッガは止まった。変数を覗き見しても、何が起こっているかはおぼろげにしかわからない。ただ、チューブ＋αとしては上等だ。俺は

ターン数とは、1 回のプロンプト実行中に Claude が何回 API ラウンドトリップ（ツール呼び出し → 結果受け取り → 次の応答）を繰り返したかの回数です。 v1（新規作成）の所要時間 v1 では言語間の差が大きく出ています。Python（32.9 秒）と Ruby（33.2 秒）が僅差でトップ、JavaScript（36.0 秒）が続きます。一方、Ruby/Steep は 105.0 秒と Ruby の約 3.2 倍。Lua（96.4 秒）や OCaml（80.9 秒）も遅め。 v1 は空のディレクトリからスタートするので、Cargo.toml や package.json などのプロジェクト設定ファイルを生成するコストが含まれます。Python/Ruby/JavaScript などは minigit ファイル 1 つを生成するだけで済むので、差が大きくなっている可能性があります

この記事は、合併前の旧ブログに掲載していた記事（初出：2022年1月19日）を、現在のブログへ移管したものです。内容は初出時点のものです。こんにちは、LINE フロントエンド開発センターの玉田です。突...

先日 Nani というAI翻訳アプリをリリースしました。macOS / Windowsアプリを使うとショートカットで解説つきの翻訳を簡単に呼び出すことができます。 この記事ではNaniの技術的な話をまとめておきます。「レスポンスが速い」という声も多くいただいているので、そのあたりの工夫についても触れたいと思います。 ざっくりとした構成 主な使用技術やサービスは以下のようになっています。 Turso: SQLiteでユーザーの設定などを保存 Upstash (Redis): キャッシュ、レートリミット Drizzle: SQLiteのORMとして利用 Stripe: 決済管理 Next.js（App Router）: Webアプリ。Vercelにデプロイ Hono: APIを快適に書くため。Next.jsのRoute Handler上で使用 Electron: デスクトップアプリ TypeS

結論 「テストして」って言っただけなのに、AIが自分でバグ見つけて、自分で直して、「違反は切腹」ってルールを自分で追加してきた。 人間、何もしてない。 何を作ったか Claude Code × tmux でホワイトカラー向けマルチタスクツールを作った。 名前は multi-agent-shogun。 戦国時代の軍制をモチーフに、将軍1名・家老1名・足軽8名の階層構造でAIエージェントを統制する。 上様（人間） ↓ 「やれ」 将軍（Claude Code） ↓ 「家老、タスクを分解せよ」 家老（Claude Code） ↓ 「足軽ども、並列で実行せよ」 ┌──┬──┬──┬──┬──┬──┬──┬──┐ │1 │2 │3 │4 │5 │6 │7 │8 │ ← 8人同時に動く └──┴──┴──┴──┴──┴──┴──┴──┘ 足軽（Claude Code × 8） とにかくshogunにぶち

はじめに 転職や異動のたびに「立ち上がりが早いですね」と言われることが多いので、自分がやっていることを言語化してみました。 はじめに オンボーディングの速さは、エンジニアとしての評価に直結します。早く戦力になれれば、チームからの信頼も得やすく、その後の仕事がスムーズになります。 私が意識しているのは 「情報」「人」「組織」「自分」 の4つの軸です。順番に解説していきます。 1. 情報収集の仕組みを作る ドキュメントは全部AIに食わせる 自分が困ったときに聞ける仕組みを最初に作ります。私は専用のGitHubリポジトリを作成し、社内ドキュメントをまとめてClaude（またはCursor）から参照できるようにしています。

「OAuthで認証してます」 「SSOってSAMLのこと？」 「OIDCってOAuthの上位互換？」 このあたり、言葉の形が似ていて普通に混ざります。 で、混ざったままでも開発は進んでしまうので、なおさら厄介です。 ただ、ここで詰まる原因は「専門用語が多いから」じゃなくて、もっと単純で、種類の違う言葉が同じレイヤーに置かれがち だからだと思っています。 体験の名前（SSO） 信頼のつなぎ方（フェデレーション） 登場人物の役割（IdP / SP） 受け渡しのルール（OAuth / OIDC / SAML） レイヤーを分ければ、用語が多くても意外と迷子になりません。この記事はそのための整理です。 TL;TD 認証（AuthN）：あなたは誰？ 認可（AuthZ）：あなたは何ができる？ SSO：1回ログインで複数サービスを使える「体験」 フェデレーション：別システムの認証結果を「信頼して受け取る」

TL;DR GitHub issueの自動解決能力を測るSWE-bench Verifiedが15ヶ月で33%から80%へ急速に進化しました（Claude Opus 4.5）。本記事では、形式手法・帰納的学習・エージェント研究という三つの流れが2020年代に収束した結果と捉えています。 ただし80%はベンチマーク飽和の兆候でもあり、SWE-bench Proでは40%台に落ちます。評価は次々と難しいベンチマークへ移行しています。 生産性への影響は文脈に依存します。ジュニア開発者や不慣れなコードベースでは効果的ですが、熟練開発者が慣れた環境で使うと逆効果という報告もあります。むしろ質的変化として、エンジニアの役割は「コード作成者」から「AIの監督者」へ移行しています。 大規模言語モデル（LLM）の能力については学術的議論が続いています。「洗練されたパターンマッチング」という批判と「創発的な理

ユーザー「MCP使ってブラウザで確認して」 AI『分かりました！...エラーが出ているので代わりにcurlを利用します！』 ユーザー「は？？？？？？？」 どれだけClaude Codeを制御しようと、上のように勝手な解釈で意味のない代替行動をやるClaude Codeに日々ブチギレてるみなさんのストレスと無駄に消えるトークンを少しでも解消する方法を提案します ※全体的にAIに対しての文章がキツくみえるかもしれませんが、コンテキスト節約のために短文にしてます 訪れる未来 この記事の通りにセットアップすると、上記のように自動的に対応してくれるようになるので同じことを1億回言わなくて良くなりストレスが非常に減ります NG Word集を設定しよう 例えばはずや代わり、別のと言った用語が含まれていたら自動でブチギレるような設定にするとかなりストレスが減ります NG Command集を設定しよう 例え

Anthropicハッカソン優勝者が10ヶ月以上かけて実際のプロダクト開発で使い込んだ everything-claude-code というリポジトリが公開されていたので、内容を読み解いてみました。 この記事の要約 Anthropic x Forum Venturesハッカソン優勝者 が公開した本番環境で使えるClaude Code設定集 agents, skills, hooks, commands, rules, MCP設定 の6種類のファイルで構成 コンテキストウィンドウは 200kから70kまで縮小する可能性 があるため、MCPの有効化は10個以下に抑える TDD（テスト駆動開発）を中心 にしたワークフローで、カバレッジ80%以上を必須とする /tddや/planなどの スラッシュコマンド で素早くワークフローを呼び出せる hooksによる自動化 でフォーマット実行やconsole

We've encapsulated 10+ years of React and Next.js optimization knowledge into react-best-practices, a structured repository optimized for AI agents and LLMs. React performance work is usually, well, reactive. A release goes out, the app feels slower, and the team starts chasing symptoms. That’s expensive, and it’s easy to optimize the wrong thing. We’ve seen the same root causes across production

はじめに AIは、あなたが聞いたことにしか答えない。 聞かなかったことは、永遠に教えてくれない。あなたが何を知らないのか、AIは知らない。 2026年だ。AIに聞けば何でも教えてくれる。コードを書いてもらい、設計を相談し、ドキュメントを要約させる。便利だ。では、なぜ本を読むのか。300ページもある本を、最初から最後まで読む必要があるのか。 本は違う。本は、聞いていないことを語りかけてくる。知らなかった世界を見せてくる。持っていなかった問いを、手渡してくる。「そんなこと、考えたこともなかった」。そういう瞬間が、本にはある。AIとの対話では、たぶん起きない。 AIは効率的だ。知りたいことに、最短距離でたどり着ける。でも、最短距離で歩いていると、道の脇にあるものが見えない。著者が失敗した話、遠回りした話、「今思えば間違いだった」という告白。そういう「寄り道」が、不思議と頭に残る。正解は忘れる。で