AI/LLM

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Anthropic が Claude Code Security を限定リサーチプレビューとして公開しました。AI がコードベース全体をスキャンして脆弱性を検出し、修正パッチまで提案してくれる機能です。 Claude Code Security とは 従来の静的分析ツール（SAST）はルールベースでパターンマッチングを行うため、ビジネスロジックの欠陥やアクセス制御の不備など、文脈依存の脆弱性を見落としがちでした。 Claude Code Security は、人間のセキュリティ研究者のようにコードを「理解」するアプローチを採用しています。 コンポーネント間の相互作用を把握する アプリケーション全体のデータフローを追跡する ルールベースツールでは検出困難な脆弱性を発見する 主な特徴 多段階検証プロセス 検出した脆弱性は多段階の検証プロセスにかけられ、誤検知（false positive）がフィルタリングされます。各脆弱性には重大度評価と信頼度スコアが付与されます。 ヒューマン・イン・ザ・ループ 修正パッチは自動適用されません。Claude Code Security は問題の特定と解決策の提案を行い、最終的な判断は開発者が行います。 実績 Anthropic のレッドチーム活動では、Claude Opus 4.6 を使用して本番環境のオープンソースプロジェクトから 500 以上の脆弱性 を発見しました。これらは数十年にわたり専門家のレビューを経ても検出されなかったバグです。 利用方法 プラン 利用可否 Enterprise 即時利用可能 Team 即時利用可能 オープンソースメンテナー 無料で迅速なアクセスを提供（申請制） 詳細は Anthropic 公式の Claude Code Security ページ を参照してください。 従来のツールとの違い 従来の SAST ツールは既知のパターンを検索する仕組みのため、新しいタイプの脆弱性や複雑なロジックの欠陥には対応しきれませんでした。Claude Code Security は LLM の推論能力を活用して、コードの意味を理解した上で脆弱性を検出するという点で、セキュリティスキャンの新しいアプローチといえます。 まとめ Claude Code Security は「脆弱性は多いが対応する人員が少ない」というセキュリティチームの課題に対し、AI による自動検出と修正提案で支援するツールです。現時点では限定リサーチプレビューですが、今後のセキュリティ開発ワークフローに大きな影響を与える可能性があります。

Claude Code でツール実行の許可を求められるたびに、セキュリティリスクをパーセンテージで表示させる CLAUDE.md の設定が話題になっています。「なんかやばそうだけど…まあいいか」で Yes を連打してしまう問題への対策です。 背景 Claude Code はファイル操作やシェルコマンドの実行時にユーザーの許可を求めますが、表示される内容だけでは何がどの程度危険なのか判断しにくいことがあります。特に初心者は、よく分からないまま Yes を連打してしまいがちです。 CLAUDE.md に追加する設定 プロジェクトのルートディレクトリにある CLAUDE.md に以下の内容を追加します: 1 2 3 4 5 6 7 8 ## ツール実行時の許可ルール - ツール実行（Bash、ファイル操作など）の許可を求めるときは、必ず日本語で説明・確認を行うこと - 許可を求める際、以下のセキュリティリスクをパーセンテージ(%)で提示すること - パスワードや秘密鍵が外に漏れる可能性 - 外部サーバーにデータが送られる可能性 - 悪意あるコードが勝手に動く可能性 - PCの設定が書き換わる可能性 表示イメージ この設定を入れると、ツール実行の確認時に以下のようなリスク評価が表示されるようになります: ・パスワードが外に漏れる可能性: 0% ・外部サーバーにデータが送られる可能性: 0% ・悪意あるコードが動く可能性: 5% ・PCの設定が書き換わる可能性: 80% これにより、各操作のリスクを具体的な数値で把握した上で、許可するかどうかを判断できるようになります。 ...

Claude Code はコーディング専用ツールと思われがちだが、実はコーディング以外の日常業務を半自動化する強力なツールとしても活用できる。みのるん氏（@minorun365）の Qiita 記事 から、その実践例を紹介する。 AI は「自動化ツール」ではなく「優秀な同僚」 Claude Code を使う上で重要なマインドセットは、AI を単なる自動化ツールではなく「一緒に仕事できる優秀な同僚」として捉えること。どんな作業でも「この作業、Claude Code に任せられないか？」と必ず考える習慣が、業務効率を大きく変える。 また「AI 活用＝やっつけ品質」という認識はもう過去の話で、適切に指示を出せば高品質なアウトプットが得られる。 プチ仕様駆動開発 Claude Code との作業では、以下の 4 つのドキュメントで「プチ仕様駆動開発」を行うのが効果的。 ドキュメント 用途 PLAN.md 音声入力で計画を記録 SPEC.md 仕様の壁打ち TODO.md タスク管理 KNOWLEDGE.md 学びとナレッジの蓄積 音声入力（Aqua Voice 等）で大まかな計画を PLAN.md に吹き込み、Claude Code に仕様化してもらうフローが実用的。 実践例: 経費精算を 5 分で終わらせる MoneyForward の CSV を Claude Code に渡して、以下を自動化する: CSV を解析して取引を分類 Gmail から領収書を自動検索 勘定科目を自動マッピング Markdown 形式で出力 手作業なら 30 分以上かかる経費精算が、5 分で完了する。 実践例: メール監視とリマインド 放置しがちなメールの監視を自動化する構成: EventBridge（定時起動） → AgentCore Runtime → Gmail API でメール抽出 → Slack に通知 重要なメールを見落とすリスクを、システムで解消する。 ...

Claude Code で生成される UI デザインの品質が急に向上したと話題になっています。その理由は「画像学習」の強化ではなく、「一般的（on distribution）」なデザインから意図的に離れるプロンプト設計にありました。 AIスロップ問題とは AI が生成するフロントエンドデザインには「AIスロップ（AI slop）」と呼ばれる品質問題があります。特に指示を与えずに UI を生成させると、AI は確率分布の中心付近からサンプリングするため、どこかで見たような「いかにもAIが作った」デザインに収束してしまいます。 具体的には以下のような特徴が見られます: 過度にグラデーションやシャドウを多用する 汎用的すぎるカラーパレット 差別化のないカードレイアウト どのサイトでも見るような Hero セクション frontend-design スキルの登場 Anthropic は Claude Code 向けに frontend-design という公式スキルをリリースしました。このスキルの核心は、Claude に対して**「一般的な出力に収束しないように」**と明示的に指示することです。 スキルの中には以下のような指針が含まれています: 確率分布の中心（もっとも一般的なデザインパターン）に寄らないこと AIスロップ的な美学を避けること 個性のあるデザインを生成すること なぜプロンプトで解決できるのか Claude は十分なデザイン知識を持っています。問題は、指示がないと「安全な」中間値に落ち着いてしまうことでした。frontend-design スキルは、この傾向を明示的に打ち消すプロンプトを提供することで、Claude が持つ本来のデザイン能力を引き出しています。 これは画像生成 AI における「ネガティブプロンプト」に近い考え方です。生成したいものを指定するだけでなく、避けたいもの（一般的すぎるデザイン）を指定することで、出力品質が大きく向上します。 実践のポイント 自分のプロジェクトでも同様のアプローチを取ることができます: 「一般的にしないで」と明示する ― デザイン生成時に「よくあるパターンを避けて」と指示する 具体的なリファレンスを与える ― 参考にしたいデザインの方向性を具体的に伝える frontend-design スキルを活用する ― Claude Code を使っているなら、このスキルを有効にする 1 2 # Claude Code でスキルをインストール npx skills add anthropics/claude-code Claude Code 内では /skills コマンドでインストール済みスキルの一覧を確認できます。 ...

AI コーディングエージェントで「ランディングページを作って」くらいなら動く。しかし、複数ファイル・複数サブシステムが絡む本格的なプロジェクトになると、エージェントはコヒーレンスを失い、前に作ったものを忘れ、壊れたコードを量産し始める。GSD はこの問題を構造的に解決するシステムだ。 GSD とは GSD（Get Stuff Done）は、大規模・マルチセッションのプロジェクトを AI コーディングエージェントで完遂するためのシステムだ。デモ向けのおもちゃではなく、多数のファイルと複数のサブシステムが連携する実務レベルのプロジェクトを対象としている。 GSD が解決する問題は明確だ： エージェントは時間とともにコヒーレンスを失う 3タスク前に作ったものを忘れる ファイルは存在するが実際には動かないコードを生成する 毎ターン、プロジェクト構造の再読み込みにトークンを浪費する 中断後の再開には人間が全てを再説明する必要がある 何かが壊れたとき、クリーンなロールバック手段がない 3層の階層構造：Milestone → Slice → Task GSD はすべてのスコープを3つのレベルに分解する。 Milestone（マイルストーン） 出荷可能なバージョン。プロジェクトの大きな単位。 Slice（スライス） 独立してデモ可能な垂直的な機能単位。「データベース層を実装する」（水平的）ではなく、「ユーザーがサインアップしてログインできる」（垂直的）という形で切る。 各スライスにはデモ文がある：「これが完了すると、ユーザーは _____ できる」。この空白を人間が観察可能な行動で埋められなければ、スコープの切り方が間違っている。 Task（タスク） コンテキストウィンドウ1つ分の作業単位。1タスクが1エージェントセッションに収まらなければ、それは2タスクだ。これは鉄則であり、違反するとエージェントがコヒーレンスを失い始める — 長時間の作業で初期の判断がコンパクション（圧縮）され、コンテキストが古いツールコールで汚染され、推論品質が劣化する。 Boundary Maps — 実装前のインターフェース思考 GSD で最もインパクトのある計画機能がこれだ。 マイルストーンの計画時に、各スライスは何を生産し、上流のスライスから何を消費するかを具体的に宣言する。曖昧にではなく、関数名・型名・インターフェース・エンドポイントを名前付きで。 S01 → S02 Produces: types.ts → User, Session, AuthToken (interfaces) auth.ts → generateToken(), verifyToken(), refreshToken() Consumes: nothing (leaf node) S02 → S03 Produces: api/auth/login.ts → POST handler middleware.ts → authMiddleware() Consumes from S01: auth.ts → generateToken(), verifyToken() これにより「スライス3が必要とする関数をスライス1がエクスポートしていない」という問題が発生しない。契約が明示的で、検証可能になる。 ...

Claude Code や Codex といった AI コーディングエージェントを現場に投入する開発者が増えるなか、「ハーネスエンジニアリング」という新しい実践領域が注目を集めている。逆瀬川氏（@gyakuse）が公開したまとめ記事から、要点を紹介する。 そもそも「ハーネス」とは何か 「ハーネス（harness）」とは、もともと馬具の意味だ。馬の力を人間が制御して活かすための装具一式 — 手綱、鞍、轡（くつわ）などを指す。馬がどれだけ優秀でも、ハーネスなしでは暴走するだけで仕事にならない。 ソフトウェアの世界では「テストハーネス」という用語がすでにある。テスト対象のコードを「つなぎ止めて」、入力を与え、出力を検証する枠組みのことだ。テスト対象そのものではなく、テスト対象を正しく動かすための外側の仕組みを指す。 AI コーディングエージェントにおける「ハーネス」もこれと同じ発想だ。AI エージェント（= 馬）は強力だが、そのままでは暴走する。古いドキュメントを信じてしまう、リンターのルールを勝手に緩和する、前のセッションで何をしたか忘れる。エージェントを制御し、安定した成果を引き出すための外側の仕組み全体がハーネスであり、それを設計・構築する技術がハーネスエンジニアリングだ。 具体的にハーネスを構成する要素は、大きく 3 つの層に分けられる: 入力層 — エージェントに何を読ませ、何を読ませないかを制御する（AGENTS.md の設計、リポジトリの衛生管理、セッション間の状態引き継ぎ） 実行制御層 — エージェントの作業中にリアルタイムで品質を強制する（リンター・フォーマッターの自動実行、計画と実行の分離） 検証層 — エージェントの出力が正しいことを確認する（E2E テスト、プリコミットチェック） 核心的な洞察は「ハーネスがモデルより重要」という点だ。同じモデルでもハーネスを改善すれば出力品質が劇的に向上する。開発者の責任は「正しいコードを書く」から「エージェントが確実に正しいコードを生産する環境を設計する」へとシフトしている。 7 つの主要トピック 1. リポジトリ衛生 〈入力層〉 「衛生（hygiene）」は、ソフトウェア開発で「不要物や汚染を取り除き、健全な状態を保つ」という意味で使われる慣用表現だ（「コードハイジーン」「ブランチハイジーン」なども同様）。ここでは、リポジトリ内に古くなったドキュメントや不正確な情報が溜まらないよう清潔に保つことを指す。人間なら「このメモ、古そうだな」と判断できるが、エージェントは 3 ヶ月前のメモも最新のコードも同じ「事実」として読んでしまう。だから情報の鮮度管理が重要になる。 実行可能なアーティファクト（コード、テスト、設定）を優先する 説明的ドキュメントは腐敗しやすいため最小化する ADR（Architecture Decision Records）で決定履歴を保全する テストはドキュメントより腐敗に強い 最大の敵は「説明的ドキュメントの腐敗」だ。エージェントは「3 ヶ月前のメモ」と「現在の真実」を区別できないため、古い情報が存在するだけで性能が低下する。ハーネスの入力層として、エージェントが読む情報の鮮度と正確性を保つことが最初のステップになる。 2. 決定論的ツールで品質を強制する 〈実行制御層〉 「決定論的（deterministic）」とは、同じ入力に対して毎回必ず同じ結果を返すという意味だ。リンターやフォーマッターがその典型で、たとえば「未使用の変数がある」というコードを渡せば、何度実行しても必ず同じ警告を返す。気分や文脈によって判断が揺れることがない。 対照的に、LLM は非決定論的だ。同じコードを渡しても、実行するたびにチェックの粒度や指摘内容がブレる。「インデントを揃えて」と指示しても、ある時はスペース 2 つ、別の時はタブで揃えるかもしれない。 だからこそ、機械的に判定できるルール（構文エラー、未使用変数、フォーマット）は LLM に任せず、決定論的ツールに委ねるのが原則だ。PostToolUse Hook でファイル編集のたびにリンターを自動実行し、エラーをエージェントに即時フィードバックする。 言語別の推奨スタック: 言語 PostToolUse プリコミット カスタムルール TypeScript Biome + Oxlint tsc + ESLint eslint-plugin-local-rules Python Ruff check/format Ruff + mypy ast-grep Go gofumpt + golangci-lint 同左 ast-grep リンター設定の保護も重要だ。エージェントがルールを勝手に緩和・改ざんするのを防ぐ仕組みが必要になる。これはまさに「手綱」の役割 — エージェントが暴走しないよう、作業のたびに自動で引き戻す仕組みだ。 ...

Claude Code や Codex といった AI コーディングエージェントを現場に投入する開発者が増えるなか、「ハーネスエンジニアリング」という新しい実践領域が注目を集めている。逆瀬川氏（@gyakuse）が公開したまとめ記事（読了 54 分）から、要点を紹介する。 そもそも「ハーネス」とは何か 「ハーネス（harness）」とは、もともと馬具の意味だ。馬の力を人間が制御して活かすための装具一式 — 手綱、鞍、轡（くつわ）などを指す。馬がどれだけ優秀でも、ハーネスなしでは暴走するだけで仕事にならない。 ソフトウェアの世界では「テストハーネス」という用語がすでにある。テスト対象のコードを「つなぎ止めて」、入力を与え、出力を検証する枠組みのことだ。テスト対象そのものではなく、テスト対象を正しく動かすための外側の仕組みを指す。 AI コーディングエージェントにおける「ハーネス」もこれと同じ発想だ。AI エージェント（= 馬）は強力だが、そのままでは暴走する。古いドキュメントを信じてしまう、リンターのルールを勝手に緩和する、前のセッションで何をしたか忘れる。エージェントを制御し、安定した成果を引き出すための外側の仕組み全体がハーネスであり、それを設計・構築する技術がハーネスエンジニアリングだ。 具体的にハーネスを構成する要素は、大きく 3 つの層に分けられる: 入力層 — エージェントに何を読ませ、何を読ませないかを制御する（AGENTS.md の設計、リポジトリの衛生管理、セッション間の状態引き継ぎ） 実行制御層 — エージェントの作業中にリアルタイムで品質を強制する（リンター・フォーマッターの自動実行、計画と実行の分離） 検証層 — エージェントの出力が正しいことを確認する（E2E テスト、プリコミットチェック） 核心的な洞察は「ハーネスがモデルより重要」という点だ。Morph の分析によると、同じモデルでもハーネスを変えると SWE-bench スコアが 22 ポイント変動するのに対し、モデルの交換では 1 ポイントしか変わらない。開発者の責任は「正しいコードを書く」から「エージェントが確実に正しいコードを生産する環境を設計する」へとシフトしている。 7 つの主要トピック 1. リポジトリ衛生 〈入力層〉 「衛生（hygiene）」は、ソフトウェア開発で「不要物や汚染を取り除き、健全な状態を保つ」という意味で使われる慣用表現だ（「コードハイジーン」「ブランチハイジーン」なども同様）。ここでは、リポジトリ内に古くなったドキュメントや不正確な情報が溜まらないよう清潔に保つことを指す。人間なら「このメモ、古そうだな」と判断できるが、エージェントは 3 ヶ月前のメモも最新のコードも同じ「事実」として読んでしまう。だから情報の鮮度管理が重要になる。 実行可能なアーティファクト（コード、テスト、設定）を優先する 説明的ドキュメントは腐敗しやすいため最小化する ADR（Architecture Decision Records）で決定履歴を保全する テストはドキュメントより腐敗に強い 最大の敵は「説明的ドキュメントの腐敗」だ。エージェントは「3 ヶ月前のメモ」と「現在の真実」を区別できないため、古い情報が存在するだけで性能が低下する。ハーネスの入力層として、エージェントが読む情報の鮮度と正確性を保つことが最初のステップになる。 2. 決定論的ツールで品質を強制する 〈実行制御層〉 「決定論的（deterministic）」とは、同じ入力に対して毎回必ず同じ結果を返すという意味だ。リンターやフォーマッターがその典型で、たとえば「未使用の変数がある」というコードを渡せば、何度実行しても必ず同じ警告を返す。気分や文脈によって判断が揺れることがない。 対照的に、LLM は非決定論的だ。同じコードを渡しても、実行するたびにチェックの粒度や指摘内容がブレる。「インデントを揃えて」と指示しても、ある時はスペース 2 つ、別の時はタブで揃えるかもしれない。 だからこそ、機械的に判定できるルール（構文エラー、未使用変数、フォーマット）は LLM に任せず、決定論的ツールに委ねるのが原則だ。 ここで重要なのが「ほぼ毎回」と「例外なく毎回」の差だ。CLAUDE.md に「リンターを実行せよ」と書くだけでは前者にとどまる。コンテキストウィンドウの消費が進むと、エージェントはリンターの存在を忘れてしまうからだ。Claude Code の Hook（特定のライフサイクルイベントで自動実行されるスクリプト）で強制すれば後者になる。 ...

AI コーディングツール（Claude Code、Cursor、Gemini CLI など）で UI を生成すると、「動くけど見た目がイマイチ」になりがちだ。Impeccable は、AI に設計のボキャブラリーを教えることで、生成される UI の品質を引き上げるスキルライブラリだ。 Impeccable とは Impeccable は、Paul Bakaus 氏が開発した AI コーディングツール向けの設計スキル拡張だ。Anthropic の公式 frontend-design スキルをベースに、17個のコマンドと厳選されたアンチパターン集を提供する。 「派手なデザイン」ではなく「洗練された仕上がり」を目指すのが特徴で、中国のインディー開発者コミュニティでも注目を集めている。 対応ツール Cursor Claude Code Gemini CLI Codex CLI VS Code Copilot Google Antigravity Kiro インストール方法 npx（推奨） 1 npx skills add pbakaus/impeccable Claude Code の場合 1 2 3 4 5 # プロジェクト単位 cp -r dist/claude-code/.claude your-project/ # グローバル cp -r dist/claude-code/.claude/* ~/.claude/ Cursor の場合 1 cp -r dist/cursor/.cursor your-project/ Nightly チャンネルの使用と Agent Skills の有効化が必要。 ...