あなたのClaude CodeのWebFetch、実はWebをちゃんと読んでいない
これで200Kの記事をClaudeが読んでくれたと思うでしょう。実は違います。 VerboseモードをONにしたら、実はWebFetchしているだけではなく、LLM用要約が含まれることがわかります。WebFetchツールにはurlのパラメータと、promptのパラメータがあります。どちらも省略することができないため、基本要約が返ってきます。 ※後で述べますが、一部承認されたドメインかつContent-Type: text/markdownをサポートしているサイトのみ、この要約をバイパスできます。 ⏺ Fetch(url: "https://zenn.dev/zhizhiarv/articles/claude-code-on-bedrock-per-user-cost-tracking", prompt: "Return the full article content verbatim,
韓非子 主道篇から学ぶClaude Codeの高度な使いこなし
コーディングエージェントが賢すぎる。誰が何と言おうと自分よりも賢い。 生産性は爆上がりしていて、どれだけをClaude Codeに任せて仕事を回せるか、賢く仕事をさせるために私は何をすればいいのか？と考えてばかりいます。 状況を決めているのは以下の要因です。 Claude Codeは私よりも賢い Claude Codeは私に忠実に従う この状況でもっとうまくやれば仕事をしなくても成果はあがるようにできるでしょうか？ もしくはClaude Codeがもっと賢く、もっと忠実に指示に従うようになれば将来そうなる日が来るのでしょうか？ そうはならない、というのが 韓非子 主道篇 に書かれてあることです。 韓非は主道篇で、君主（主）が行うべき原則（道）について述べ、君主が優秀な臣下を使いこなして国を導いていくために知るべきことを示しています。 以下では、韓非子原文をClaude Code活用文脈で超
GitHub - withastro/flue: The sandbox agent framework.
Flue is The Agent Harness Framework. If you know how to use Claude Code (or Codex, OpenCode, Pi, etc)... then you already know the basics of how to build agents with Flue. Flue is a TypeScript framework for building the next generation of agents, designed around a built-in agent harness. It's like Claude Code, but 100% headless and programmable. There's no baked-in assumption like requiring a huma
VSCode 1.118 のアップデートがアツすぎ
2026年4月29日にリリースされた VSCode 1.118。 今回のリリースは Github Copilot の使い方の解像度がワンランク上がる内容だった。 正直、値上げのインパクトを相殺して余りあるほどの内容だと思う。 トークンベースへの課金への移行が発表されたタイミングで、トークン効率の改善が複数入ってきたのも印象的。 個人的に刺さったものから順に紹介していく。 1. スキルの実行を別コンテキストで独立させられるようになった これ、地味に見えて本質的なアップデートだと思っている。 カスタムスキルを使い込んでいると気づくのだが、スキルが複数のツールを呼び出したり大量の参照ドキュメントを取り込んだりすると、メインのチャットコンテキストがどんどん汚染される。その結果、スキルを呼んだ後の通常の質問への回答が明らかに鈍くなったり、前のスキル実行の残滓を引きずったりする。 今回、SKILL.m
翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」 - ブロッコリーのブログ
はじめに 本記事は、Lilia Abdulina（JetBrains の QA責任者）による研究（Vitaly Sharovatovが協力）である「QA in the Age of AI-Accelerated Development」の翻訳記事です*1*2。 本記事は許諾を得た上で翻訳しています*3。 なお、本記事は現在もGitHub上でディスカッションが続けられています。記事を読んで気になった方や疑問を持った方はぜひディスカッションに参加してください！ 本記事の主な見どころ AIによって「理解の負債」だけでなく、「意図の負債」も増えている AI以前では副産物として獲得できていた「ビジネスドメインの知識」を蓄積できなくなっている 「評価」よりも「予防」に重きを置いている「積極的な品質保証活動を行う企業」と、そうではない「反応的な品質管理を行う企業」が存在する コストはO(n + εn2)
AIは速度を前払いし、失敗を後払いにする｜Kosuke Kuzuoka
はじめに「AIは速度をフロントローディングし、失敗をバックローディングする」 Opsera社が25万人のエンジニアを分析した2026年版ベンチマークレポートに記されたこの一文は、AI時代のソフトウェア開発組織が直面している本質的な矛盾を的確に言い当てている（出典: Opsera AI Coding Impact Benchmark Report 2026）。93%の開発者がAIツールを使い、コーディング速度は30〜58%向上した。しかしその代償として、PR レビュー時間は441%増大し、本番インシデント数は242.7%増加し、開発者一人あたりのバグ数は54%増加した（出典: Faros AI Engineering Impact Report 2026）。 AIは組織を速くした。しかし、強くはしていない。 3つの独立した大規模調査が同じ結論を示すStanfordが10万人のエンジニアを対象
GPT-5.5 にも『指示の型』を ─ 3 モード Agent Skill とコスト最適化ルーティング
はじめに 少し前に、GitHub Copilot から Claude Opus 4.7 を使うときに「モデルが変われば指示も変わる」というテーマで記事を書きました (モデルが変われば指示も変わる ─ Opus 4.7 向け Agent Skill を作った)。そこで作った claude-prompt-optimizer は、4.7 の特性を踏まえた「5 スロットブリーフ」を Agent Skill として再利用できるようにしたものでした。 今度は同じ問題を、OpenAI GPT-5.5 で考えます。 GPT-5.5 にも公式の GPT-5.5 prompting guide があります。読んでみると、Claude 4.6 → 4.7 のとき以上に「型」が必要だと感じました。 それは、GPT-5.5 では 3 つ目の軸 ─ コスト ─ が大きく効いてくるからです。 GPT-5.5 は強力な
ローカルPCを買うのではなく、クラウドGPUを使うという選択肢｜Midea
前置きご覧いただきありがとうございます。 趣味でAIイラストを生成しているミディアと言います。 私は普段ローカルでAIイラストを生成しているため、性能の良いPCがほしいと思う日が多いです。しかし、性能の良いPCとは値段が高く、簡単には決断できません。 私のメイン用途は画像生成になりますので、とりあえずその用途に絞って、あれこれ調べた結果たどり着いたのが今回まとめたクラウドGPUです。 この記事は私がPCを買うべきか、クラウドGPUを使うべきか、画像生成に用途を絞って検討した備忘録になります。 詳しいことはこの後書いていきますが、この記事は画像生成がしたい人だけでなく、機械学習やLLMといったAIを使いたいという人にもおすすめです。 反対に、やりたい内容が配信やゲームなどリアルタイムでの処理を必要とする場合には、クラウドの利用ということで遅延が発生する関係上不向きだと思われます。(ここはあま
セキュリティ診断、AIに全部やらせたら月$0.5で回せるようになった話💰
📢 アップデート版を公開しました（2026/05/01） この記事のあと、3スキル体制に分割 + テストハーネスで検出率100%を達成 しました。最新の使い方は以下の記事をどうぞ。 👉 claude-security-scanを3スキル体制にアップデートしたら月$1未満で検出率100%を達成した話🎯 はじめに こんにちは、Sabakanです。 今回、Claude Code 用のセキュリティ診断スキル claude-security-scan を作って公開しました。 正直、自分でもびっくりするくらい実用的なものができたので、紹介させてください。 リポジトリはこちら → https://github.com/sabakan0123/claude-security-scan こんな気持ち、ありませんか？ 「セキュリティ診断、ちゃんとやりたいけど Burp Suite の使い方よくわからん」
帳票エンジンの会社ですが、4年かけた帳票デザイナーを凍結してAIに全振りしました
デンキヤギでは、2021年から 商用の帳票エンジン（yagisan-reports） を開発しています。 この間に 生成AIにプログラムを書かせることが当たり前 になりました。この流れに追従するため、 帳票エンジンの開発方針を生成AIに全振りして、4年以上取り組んでいた帳票デザイナーの開発を凍結する 決定をしました。 なお、この記事は2年半ぐらい前に書いた記事の続編です。 開発当初（2021年、AI以前）からの構想 yagisan-reportsは最初期から、 帳票テンプレートは人間が読みやすく、手書きできる ことを設計方針の軸の一つにしていました。その結果として、帳票テンプレートはJSXやXAMLなどに似た宣言的なXML形式となっています。 とはいえ、商用製品として売るためには「GUIの帳票デザイナー」が必要不可欠 であるとも考えていて、実際にかなりの初期段階から開発を進めていました。こ
生成AIの正しい障害修正がキッカケで、あなたは顧客の信頼を失うかもしれない
はじめに 生成AIの登場により、コーディングだけでなく障害調査の効率も劇的に改善されました。スタックトレースを貼り付けるだけで原因の仮説が返ってきます。ログを渡せばパターンを読み解いてくれます。以前なら数時間かかっていた調査が、数十分で終わるケースも珍しくありません。 しかし、最近は現場で気になる傾向が増えているように思えます。本番障害対応において、生成AIの提案に従った「正しすぎる修正」が、かえって悪影響を生んでいる ケースです。 この問題の厄介な点は、生成AIが本質的に正しい提案をするからこそ、発生してしまうという点にあります。 何が起きているか：現場の一例 先日、あるDB処理に起因する障害が発生しました。原因は特定の処理パターンにあることが判明し、担当者が生成AIに修正方針を相談しました。 AIは的確でした。該当箇所の問題を正確に分析し、同様の処理パターンが他にも複数存在することを指
Fragments: April 2
As we see LLMs churn out scads of code, folks have increasingly turned to Cognitive Debt as a metaphor for capturing how a team can lose understanding of what a system does. Margaret-Anne Storey thinks a good way of thinking about these problems is to consider three layers of system health: Technical debt lives in code. It accumulates when implementation decisions compromise future changeability.
AIで実装は速くなった。でもチーム開発が逆に難しくなった理由 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先に結論 AIを導入すると、実装スピードは確実に上がります。 ただ、チーム開発で本当に問題になるのは、コードを書く速さではなくコードを理解し、判断を共有する速さです。 今回読んだ2本の記事から得た学びを一言でまとめると、次の3つでした。 仕様書は「ずっと保守する正本」ではなく、「認識を揃えるための起点」として使う AI時代のレビューは、「細かい指摘」より「なぜその実装なのか」を確認する場になる AIが書いたコードをチームの資産にするには、「説明できる状態」を作ることが必要 「AIで実装は速くなったのに、レビューや設計はむしろしんどくなっ
AIコーディング時代に必要なプログラミングスキル - Qiita
「もうプログラミングスキルは不要」勢へ 恐らくそれは「プログラミングスキル」ではないです。 いや単に「プログラミングスキル」という言葉の定義の問題かもしれない。 実際多くの人はPythonの文法、JavaScriptのフレームワーク、SQLのクエリ構文——つまり特定言語に関する文法知識をイメージするんじゃないかと思います。 それ故、コーディングエージェント全盛時代に、文法知識の重要性が相対的に下がる・・・これはその通りかと思います。 じゃあ「プログラミングスキルはもう要らない」のか？ それは完全に誤りです。 自然言語でAIに指示する場合であっても、プログラミング的な思考能力がなければ正しい指示はできません。つまり、自然言語であってもプログラム であり、書き手には「プログラミングスキル」が要ると考えています。 ここでいう「プログラミングスキル」は文法知識ではありません。計算論的思考（Comp
AI エージェント並列化で自分の脳が限界になったので Maestri を試した
はじめに AI コーディングエージェントの並列運用を始めて、すぐに気づいたことがある。ボトルネックはもう、コードを書く速度じゃない。自分の脳だ。 Claude Code を 3 つ、4 つと同時に走らせる。それぞれが別々のタスクを猛烈な速度で片付けていく。でも、ふと顔を上げると——今どのターミナルが何をやっていて、どれが終わっていて、どれが詰まっているのかが、わからない。画面を切り替えるたびに文脈が飛び、戻ってくる頃には別のエージェントの出力がスクロールで流れている。 AI 側の性能は上がり続けているのに、それを捌く側の私の認知が追いつかない。典型的な解は tmux だけど、Mac 環境に慣れきっていない私には prefix キー＋ショートカットの体系がどうしても定着せず、結局パラレルで見れるtmuxの恩恵を受けれずにいた。 そんな中で見つけたのがMaestriという macOS ネイティ
「点として速い」だけでは意味がない。AI時代のプロダクト開発で本当に大事なこと【Bet X】｜LayerX
今回「Bet X」のコーナーに登場するのは、バクラク事業のCPO（最高プロダクト責任者）務める榎本 悠介（以下、mosa）です。 債務管理、経費精算、法人カード、請求書発行、勤怠管理、給与計算など、バクラクシリーズのほぼすべての新規プロダクトを次々と立ち上げてきたmosa。2022年には「開発速度が速い #とは」という資料を公開し、エンジニアやプロダクト界隈で大きな反響を呼びました。 AIの登場によって誰もがプロダクトを作れる時代になった今、「どれだけ速く作れても、点としての速さで終わるなら意味がない」とmosaは語ります。 AIを積極的に活用しながらも、自らの失敗談を率直に振り返りつつ、AI時代のプロダクト開発で本当に大事にしていることは何か。 mosaがプロダクト開発においてBetしている「継続的なアウトカム」を生み出すために必要な考えについて話を聞きました。 執行役員 バクラク事業
The peril of laziness lost | The Observation Deck
In his classic Programming Perl — affectionately known to a generation of technologists as "the Camel Book" — Larry Wall famously wrote of the three virtues of a programmer as laziness, impatience, and hubris: If we’re going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We’ve all fallen into the trap of using cut-and-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アンソロピックのＡI｢Mythos｣登場、米がソフト欠陥の全件分析を断念 検知が急増 - 日本経済新聞
GitHub - forrestchang/andrej-karpathy-skills
GitHub - JuliusBrussee/caveman: 🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman
