Opus4.7の登場により、Claude Codeの開発者と公式が「これはもうやめろ」と言い始めた6つのこと - Qiita
2026年4月16日、AnthropicがClaude Opus 4.7をリリースしました。 同時に公式ブログ「Best Practices for Using Claude Opus 4.7 with Claude Code」が公開され、Claude Code作者のBoris CherneyもXで「6つの新技」を投下しています。 両方を通してAnthropic公式が言っているのは「これまでのClaude Codeの使い方は、今日でやめろ」です。 4.6までは正解だった作法が、4.7では逆効果になることもあるようです ↓Claud CodeはもはやただのAIコーディングツールではなく、誰もがアプリで稼げるようになる収益化ツールです！ よければこちらのツイートも見てみてください！ 「ペアプロ（細かく指示する）」のはもうやめろ 4.6までの「細かく指示するほど賢く動く」という感覚は、4.7では
【エンジニアの教養】なぜかエンジニア界隈で有名な◯◯の法則的なやつをまとめてみた - Qiita
まずは、ソフトウェア開発の現場で法則として扱われることが多いものです。 1-1. プロジェクトと組織の法則 $$ コンウェイの法則 ★★★★☆ $$ システムの構造は、それを作る組織のコミュニケーション構造に似る、という法則です。 たとえば、認証チーム、決済チーム、在庫チームがまったく会話しない組織では、その断絶がAPI境界や画面遷移にも出やすくなります。アーキテクチャの話に見えて、実は組織設計の話でもあります。マイクロサービス分割、チーム分割、責務境界の議論でよく登場します。 $$ ブルックスの法則 ★★★★☆ $$ 遅れているソフトウェア開発に人を追加すると、さらに遅れることがある、という法則です。 「人を増やすな」という単純な話ではありません。新しく入った人への説明、認識合わせ、レビュー、マージ、意思決定の調整が増えるため、遅延プロジェクトに後から人を入れても即効性がない、という話で
上司になったら｜miyasaka
上司になる人にアドバイスするとしたらどういうことを伝えるだろうか？ 機能する上司になるのはほんとに難しい。 役職は会社から与えてもらうことができるが、、だからといって部下がついていくかどうか？は別物だ。フォロワーシップのない管理職は本人も部下も辛い。 はじめて管理職になったのはたぶん32歳のときだった。当時の職場には管理職トレーニングなんてなかったし、そもそも上司ってほとんど見たことなかったし（小組織にしかいたことなかった）で、とりあえず現場プレイヤーのまま管理職になり、そのまま突進して、そして組織がでかくなって見事にいちど自分自身でパンクした。 そのときに幾つかの本を読み始めたんだがその一冊がジャックウェルチのエグゼクティブコーチをしてた人の本。 そこにリーダーにありがちな悪癖が20ある。おもいあたることがみなさんもないだろうか？ 極度の負けず嫌い 何かひとこと価値を付け加えようとする。
防御的プログラミングを学ぶ — 契約による設計とTDDの間にある語彙
はじめに AIエージェントにコードを書かせていて、過剰にnullチェックや例外処理が埋め込まれた経験はないでしょうか。私はこの場面に何度か遭遇したとき、「これは防御的プログラミングというものなのだろうか」と気になり始めました。 ところが防御的プログラミングという言葉自体に、自分は明確な像を持っていないことに気づきました。なんとなくコードの堅牢性を高める手法、というぼんやりした認識はありましたが、自分の中で言語化できていない領域でした。 調べてみると防御的プログラミングは契約による設計(Design by Contract、以下DbC)やTDDと深く関わる概念で、チームのコーディングの決め事やAIへの指示の語彙としても重要だと感じました。本記事はその学習記録です。 参照したのは『達人プログラマー』(Andy Hunt & Dave Thomas)、『実装パターン』『テスト駆動開発』(Kent
『システム思考の世界へ』に学ぶ、AI時代にエンジニアが「技術に詳しくあるべき」理由【nwiizo】 - エンジニアtype | 転職type
本連載では、業界の第一線で活躍する著名エンジニアたちが、それぞれの視点で選んだ書籍について語ります。ただのレビューに留まらず、エンジニアリングの深層に迫る洞察や、実際の現場で役立つ知見をシェア！初心者からベテランまで、新たな発見や学びが得られる、エンジニア必読の「読書感想文」です。 著名エンジニアが、独自の視点で「おすすめ書籍」の紹介を行う本連載。 今回の語り手は、人気ブログ「おい、」シリーズの著者であり、株式会社スリーシェイクのソフトウェアエンジニア・nwiizoさんだ。 複雑化する現代のシステムに向き合い、よりよい判断へとつなげるための思考法を解説した名著『システム思考の世界へ』（オライリー・ジャパン）を紹介してくれた。 生成AIの台頭で「コードを書く量」が減りゆく今、それでもエンジニアが「技術の手触り」を持ち続けるべき本当の理由が、本書には隠されているという。 発売日：2026年04
Web 標準動向 2026年4月版
こんにちは！ サイボウズ株式会社 フロントエンドエンジニアの Saji (@sajikix) です。 はじめに サイボウズは 2025 年 4 月より、W3C のメンバーに加入しました。 標準化プロセスに関わることができるようになるための最初の一歩として、フロントエンドエンジニアの一部のメンバーは積極的に Web 標準のキャッチアップを行っています。 そこで、毎月メンバーが興味を持った Web 標準に関する話題や、実際に標準化プロセスに関わることができた場合にはその報告などを 1 つの記事としてまとめ、紹介していきます。 また、ここでは W3C に限らず、TC39 や WHATWG などの標準化団体のトピックについても扱います。 HTML Improved Japanese phonetic name support in Chrome autofill Chromeにおいて氏名を入力する
「Claude Codeに全部やらせる時代が来た」のか検証してみた
はじめに こんにちは。セキュリティエンジニアの@okazu_dmです。 この記事は、最近リリースされたLLMベースのセキュリティスキャンツールとしてclaude-security-scan を使ってみた所感の記事です。 先週、以下の記事を見つけました。 検出率100%という結果が紹介されており、Claude Codeに全部やらせる時代が来た、というタイトルから「楽な時代が来たな」と思ったのですが、実際のところどの程度やらせることができるのかを検証するため、より網羅的に脆弱性が仕込まれている OWASP Juice Shop で再評価してみました。本記事ではその結果と、LLMベースのセキュリティスキャンツールに対する考察をまとめます。 なお、claude-security-scan はClaude Codeのslash commandとして実装されており、ソースコード解析と依存関係チェックを
認知負債 - kawasima
生成AIがプロンプトからコードを大量に生成してくれるので、出力されたものを理解する時間と引き換えに早くリリースする。この構造は技術的負債と同じなので「認知負債」と呼ばれることがある。 Margaret-Anne Storey が AI 時代のソフトウェア健全性を技術的負債・認知負債・意図負債の3層で整理している Addy Osmani は AI 生成コードでこのギャップが急拡大する現象を「理解負債」と呼ぶ Thoughtworks Technology Radar では "コードベースの認知負債" を Caution に分類している 認知負債と意図負債を分ける Storey の3層モデルの肝は、コード側の問題 (技術的負債) と人間側の問題を分けただけでなく、人間側をさらに「人の頭の中」(認知負債) と「外部化された知識」(意図負債) に分けたことにある。 table:table 種類 宿
「誰かに連絡する」タスクがとても苦手な部下のために試行錯誤した話
この記事で書きたいのは、大体以下のようなことです。 ・昔の部下に、「他者への連絡・相談」が絡むタスクを必ず遅らせてしまう人がいました ・「叱られないか、どう反応されるかに対する不安」「相手の時間を奪ってしまうことへの罪悪感」「相談するタイミングの見極めが苦手」「過去の上司に対話を拒絶された経験」などが主な問題だったようです ・心理面とインフラ面の両方から、なんとか解決できないか、上司・同僚として色々試行錯誤しました ・しんざきのチーム内で一番効果があったのは「エスカレーションの単純化」と「エスカレーションルールの設定と周囲への共有」でした ・「部下のコミュニケーションコストをどう下げるか」というのはマネージャーにとって重要な仕事のひとつです ・一方、「連絡・相談が気軽にできる」というのが、ビジネスパーソンとして非常に強力なスキルになることも確かです ・特に4月からの新人の皆様には、「こまめ
役割と責任の区別をつける
みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。 本記事は、先日Xに書いた記事の転載です。 先日Xで「スクラムマスターが何もしない。ふざけんな（意訳）」という話を見かけました。 確かに、何もしていないのであれば不要なんじゃないか、という気もします。 ただ、この話はいくつか論点が混ざっていそうなので、分けて見ていきましょう。 役割と責任は違うスクラムマスターの話なので、見るべきはスクラムガイドです。とりあえず擦り切れるくらい読んでください。 スクラムガイド2020年版では、今回の話に関係がある大きな改訂が行われました。 それが「責任（Accountability）」です。 スクラムガイド2017まではプロダクトオーナー、開発
WSL2+Docker環境における、CVE-2026-31431 (Copy Fail) への対策メモ
【2026/05/09 追記】注意：まだ暫定対策は解除しないでください wsl --update を実行したところ、WSLの更新（2.7.3）が配信されていることを確認しました。 しかし、uname -r を確認する限りカーネルは 6.6.114.1 であり、リポジトリを見るとこれは2025年12月のリリースです。 時系列的に、本脆弱性（CVE-2026-31431）に対する修正パッチではありません。 https://github.com/microsoft/WSL2-Linux-Kernel/releases/tag/linux-msft-wsl-6.6.114.1 読者の皆様は、引き続き .wslconfig による暫定対策（module_blacklist=algif_aead）を維持してください。 公式の修正版が配信されるまで、引き続き状況を観測します。 $ wsl --updat
【第1部】フロントエンドにテストを入れる、とはどういうことか
はじめに 本記事は、バックエンドエンジニアとして9年目を迎えた私が、フロントエンドのテスト導入をチームでリードすることになってからの1ヶ月間を振り返る実践記です。VitestとAIエージェント(Cursor、Claude Code)を組み合わせてテストを書き進めるなかで、何がうまくいき、何がうまくいかず、どこで方向転換をしたか。その途中経過を、3部構成で記録していきます。 先に断っておきますが、私はフロントエンドエンジニアではありません。バックエンドを主軸にキャリアを積んできた身で、フロントエンドのコードとの接点はバックエンドAPIとの接続部分を一緒に確認する程度でした。フロントエンドのドメイン知識もフレームワーク知識も、お世辞にも豊富とは言えない状態からのスタートです。 また本記事は、これまで書いてきたテスト設計シリーズのフロントエンド×AI時代の実践編として位置付けています。シリーズで
コードを書きながら学ぶ プログラミングの原理原則
はじめに 事業会社でエンジニアをしているいっぺいです。最近、転職をして以前よりも規模の大きなサービスの開発に携わることになりました。まだ転職して数ヶ月しか経ってはいませんが、1つのコードに対して求められる品質が上がり、自分の考えや知識がまだまだ足りていないと感じることが多いです。 プルリクエストのレビューを通して、要件を満たして動くコードは書けているが、「もっとこう書いた方がよいのでは？」という視点のコメントをもらうことも多く、将来的な変更に耐えられるか・保守性は良いか・読みやすいコードになっているかといった観点で、まだまだ力不足だと感じています。 そこで、改めて「プログラミングの原理原則」について体系的に学び直したいと考え、その学習のアウトプットとして本記事を書いています。 また、AIが大量のコードを書く時代だからこそ、そのアウトプットの良し悪しを判断する物差しとして「プログラミングの原
人を増やしても減らしてもアウトプットの品質は向上しない
結論 人を増やしてもアウトプットの量は人数に比例して増えませんし、人を減らしてもアウトプットの品質は下がります。優秀な人やAIエージェントを増やしても、組織のあちこちでバラバラなものができたり、ナレッジが古くなって信用できなくなったり、特定の人に判断が集中して燃え尽きたりといった問題は残ります。 これを防ぐためには、組織として「何を許し、何を禁じるか」を、できるだけ少ないルールとして明文化することが必要だと考えています。ただし、ルールを増やしすぎると、組織はそれを守ることに気を取られて動きが遅くなります。だからこそ、壊れると最も困る機能や品質に絞って、リスクの大きさに応じて詳しさを決めることが大切です。 「人を増やすか減らすか」の前にある問い チームの人数が増えるほど、それぞれのメンバーに求められる情報の発信量・受信量が増えていき、やがて情報の伝搬速度がチーム開発のボトルネックになりがちで
Go開発者によるDDDの実践：概念理解から具体的な応用まで - DMM Developers Blog
1. はじめに 2. 既存管理画面のリプレース背景 2.1 技術選定の理由 2.1.1 フロントエンド: React 2.1.2 バックエンド: Go 2.1.3 設計: ドメイン駆動設計（DDD） 2.2 再構築による期待効果 3. DDD導入における課題 3.1 DDDの概念理解と実践のギャップ 3.2 Go言語におけるDDD実装のノウハウ不足 3.3 ビジネスロジックの適切な配置 4. 課題解決に向けた対策 5. Go言語を用いたDDDの実践 5.1 DDDの基本概念 5.1.1 ドメイン (Domain) 5.1.2 エンティティ (Entity) 5.1.3 バリューオブジェクト (Value Object) 5.1.4 アグリゲート (Aggregate) 5.1.5 リポジトリ (Repository) 5.1.6 サービス (Service) 5.2 DDDにおけるDI/D
コードを1行も書く前にバグを潰す — 生成AIが「理想論」だったシフトレフトを現実にする
はじめに こんにちは！TOKIUMでQAチームのリーダーをしている西田です。 「シフトレフト」「ATDD（受け入れテスト駆動開発）」「BDD（振る舞い駆動開発）」 — テストを上流に持っていこうという考え方は、ソフトウェア開発の世界で10年以上前から提唱されてきました。概念としては広く知られているのに、実際に徹底できている現場は少ない。「理想はわかるけど、やるのが大変」というのが正直なところだったと思います。 ところが今、生成AIの急速な進化によって前提が変わりつつあります。Claude CodeやGitHub Copilotによるコーディング自動化、Playwright Agentsによるテスト自動化。かつて「理想論」だったプラクティスの実現コストが、AIによって劇的に下がっているのです。 この記事では、これらの概念が生成AI時代に再び現実的な選択肢として浮上する先に、開発プロセスとQA
AIエージェントを会社で使いたい！→「え、セキュリティどうするの？」 企業導入への技術的アプローチ - Qiita
この記事を読んでほしい人 Claude Code / Cursor / Copilot などの AIエージェントをチームに導入したい 人 情シスから「セキュリティ面の対応は？」と聞かれて 技術的に答えたい 人 「導入したいけどセキュリティが心配」で 手が止まっている 人 AIエージェント導入で必ず聞かれる3つの質問 AIエージェントの導入を提案すると、情シスやセキュリティ部門からだいたいこう聞かれます。 Q1: 「AIが何をしているか見えないけど大丈夫？」 Q2: 「危険な操作を勝手にされない？」 Q3: 「何かあったとき説明できる？」 どれも正当な心配です。AIエージェントはチャットボットと違って、自分の判断でファイルを書き換えたり、コマンドを実行したり、外部に送信したり します。つまり「画面に出る応答」の裏で、別の何かが動いている可能性があります。 本記事では Aigis という OS
マネーフォワードのGitHub不正アクセス事件をエンジニア視点で読み解く — なぜソースコードに本番カード情報と認証キーが入っていたのか
はじめに 2026 年 5 月 1 日、マネーフォワードが「GitHub への不正アクセス発生に関するお知らせとお詫び（第一報）」を公表しました。GitHub の認証情報が漏えいし、第三者によりリポジトリがコピーされ、ソースコードと一部の個人情報が流出した可能性があるという内容です。同時に、銀行口座連携機能を一時停止する措置もとられました。 この事案は、エンジニア視点で見ると「仕方ない部分」と「明らかにアウトな部分」がはっきり分かれる、教科書のような事例になっています。GitHub 認証情報の漏えい自体は、正直に言ってどの会社でも起こり得ます。一方で、流出したとされる中身に 本番カード保持者の氏名と下 4 桁が 370 件、そして ソースコード内に各種認証キー・パスワード が含まれていたという点は、設計と運用の問題として議論せざるを得ません。 この記事ではセキュリティエンジニアの立場から、
Decision Quality と設計判断失敗パターン - kawasima
Decision Quality (DQ) は SDG が体系化した意思決定の質の枠組みで、良い意思決定の条件を6つに分解する。 Frame（解くべき問題の枠組み） Alternatives（選択肢） Information（情報） Values（評価基準） Sound Reasoning（論理的推論） Commitment to Action（実行へのコミット） 全体の質は一番弱い要素で決まる、というのがDQの中心的な主張である。意思決定そのものと、その結果は区別する。良い意思決定でも結果が悪いことはあるし、その逆もある。 設計判断の現場で繰り返し観測される失敗の多くは、6要素のうち Frame と Values の2つの取り違えで説明できる。Valuesを 評価軸 として8つに整理し、Frame の取り違えは 支配軸の取り違え として捉える。残りの4要素も副次的に絡む。早合点 は In
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeNAやGOなど、AI勉強会の資料を無料公開中 累計100件超
