AI/LLM

バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する バイブコーディング（Vibe Coding）で AI にUIを作らせると、「動くけどダサい」「素人っぽい」という壁にぶつかる人は多いでしょう。 @7_eito_7（えいと）さんのポストは、この問題に対するシンプルかつ強力な解決策を提示しています。 「バイブコーディングでデザインを20倍よくする裏技。それはUIの種類を覚えること。2,500以上のデザイン例がまとまったThe Component Galleryでデザインの知識を増やす。そして『App Bar + Drawer + Card Grid + Tabs構成で』みたいに構造で指示するだけで一瞬でプロっぽくなる。」 核心は**「見た目」ではなく「構造」で指示する**ことです。 なぜ「きれいにして」では良いUIにならないのか バイブコーディングでよくある失敗パターンを見てみます。 ❌ 曖昧な指示: 「もっとおしゃれにして」 「プロっぽいデザインにして」 「モダンな感じで」 → AI は「統計的に平均的な」デザインを返す → 紫グラデーション、Inter フォント、角丸カードの量産（AI スロップ） ✅ 構造で指示: 「App Bar + Drawer + Card Grid + Tabs 構成で」 「Hero + 3カラム Feature Grid + Testimonial Carousel + CTA Footer で」 「Sidebar Navigation + Data Table + Filter Bar + Pagination で」 → AI はコンポーネントの「正しい組み合わせ方」を知っている → 実在のデザインシステムに基づいた構造が生成される この違いが生まれる理由は明確です。LLM の学習データには Material Design、Fluent UI、Ant Design など実在のデザインシステムのコードが大量に含まれています。コンポーネント名で指示すると、AI はそれらのデザインシステムの「正しい実装パターン」を参照して出力します。 ...

非エンジニアでも安心！Claude Code を安全に使うための 2 つの設定ファイル Claude Code は強力なツールですが、ファイルの削除やシステムコマンドの実行など、意図しない操作が起きる可能性もあります。@tetumemo さんのポスト では、非エンジニアが Claude Code を安全に使うために設定すべき 2 つのファイルが紹介されています。 「包丁」に例えると、settings.local.json は安全カバー（物理的に危険な操作を防ぐ）、CLAUDE.md は『危ないから気をつけて』という声かけ（AI に判断基準を与える）。両方揃って初めて安全性が確保されるという、分かりやすい整理です。 1. settings.local.json — 「仕組みとして」操作を制限する settings.local.json とは Claude Code の権限設定ファイルです。AI がどのコマンドを実行でき、どのコマンドを実行できないかを JSON で定義します。 設定ファイルは .claude/settings.local.json に配置します。.local が付くファイルは自動的に .gitignore に追加されるため、個人の設定がチームに影響しません。 基本構造 1 2 3 4 5 6 7 8 9 10 { "permissions": { "allow": [ "許可するコマンドやツール" ], "deny": [ "禁止するコマンドやツール" ] } } 非エンジニア向け推奨設定 @tetumemo さんが紹介しているのは、以下のような設定方針です。 ...

Claude Code の Auto Memory（MEMORY.md）を理解する — CLAUDE.md との使い分け Claude Code には「メモリ」と呼ばれる仕組みがセッション間で情報を引き継ぐために用意されています。最近 SNS でも話題になっている Auto Memory（MEMORY.md） について、CLAUDE.md との違いや実践的な活用法を整理します。 きっかけ：SNS での反応 @L_go_mrk さんのポスト では、Claude Code の Auto Memory 機能について「かなり気が利いている」と評価されていました。ポイントは以下の通りです： 「これ覚えておいて！」と指示するだけで、Claude が自動的に重要情報を記憶してくれる CLAUDE.md（ルール特化）と MEMORY.md（学習・記憶特化）で情報が適切に分離されている プロジェクトごとに独立した記憶で、他プロジェクトに影響しない セッション間で記憶が維持される この指摘はまさにその通りで、CLAUDE.md と MEMORY.md は目的が異なる二つの記憶層として設計されています。 二つの記憶層：CLAUDE.md vs MEMORY.md CLAUDE.md — 「指示書」 CLAUDE.md はあなたが書いて Claude に従わせるルールです。 コーディング規約、ビルドコマンド、テスト手順 プロジェクトのアーキテクチャや設計方針 チーム全体で共有する約束事 # プロジェクトルール - テストは pytest で実行: `pytest -xvs` - コミットメッセージは Conventional Commits に従う - API 変更時は必ず OpenAPI スキーマを更新する CLAUDE.md はリポジトリにコミットしてチームで共有することが想定されています。 MEMORY.md — 「学習ノート」 MEMORY.md はClaude 自身が書く、作業を通じた学習メモです。 ...

なぜ AI は同じ紫グラデーションのサイトを作るのか — 分布的収束と Skills による脱却 「AI にランディングページを作らせると、どれも同じに見える」 Inter フォント、白背景に紫グラデーション、角丸カード、3カラムのアイコン付きグリッド — いわゆる AI スロップ（AI slop） と呼ばれるこの現象には、明確な技術的原因があります。 @awakia さんのポスト では、Anthropic が公式ブログで解説した 分布的収束（Distributional Convergence） という概念と、その解決策としての Skills アプローチを紹介しています。差を生むのはモデルの性能ではなく「方向付け」だという指摘は、AI を使ったフロントエンド開発に携わる全ての人にとって重要な示唆です。 分布的収束（Distributional Convergence）とは LLM はトークンの出現確率に基づいてテキストを生成します。フロントエンドのコード生成においても同じ原理が働きます。 学習データには膨大な数の Web サイトのソースコードが含まれていますが、その中で 最も頻出する「安全な」選択肢 が統計的に支配的です。結果として、指示なしで「ランディングページを作って」と頼むと、学習データの 中央値 に収束した出力が生成されます。 なぜ「紫」なのか この疑問には具体的な答えがあります。約 5 年前、Tailwind CSS のデフォルトボタンカラーが indigo-500 に設定されました。その後、GitHub 上に大量の Tailwind チュートリアルやサンプルコードが蓄積されました。AI に制約なしで「ランディングページを作って」と指示すると、2019 年から 2024 年にかけてスクレイピングされた Tailwind CSS チュートリアルの中央値を得ることになります。そして、その中央値が紫なのです。 AI スロップの典型パターン 要素 AI スロップの典型 フォント Inter, Roboto, Arial, system fonts 配色 白背景 + 紫/インディゴグラデーション レイアウト 3カラムのカード型グリッド 角丸 控えめだが均一な rounded-lg アニメーション なし、または最小限 背景 単色（白 or 薄いグレー） これは「悪い」デザインではなく、統計的に平均的なデザインです。どのプロジェクトにも合いそうで、どのプロジェクトにも合わない — そういう出力になります。 ...

【2026年最新】世界一わかりやすい Agent Skills 完全ガイド — まとめ 元記事: 【2026年最新】世界一わかりやすいAgent Skills完全ガイド（株式会社AIworker） 紹介ポスト: Fujin(@fujin_metaverse) Agent Skills とは？ 一言で言うと、「AIエージェントに渡す新人研修マニュアル」。 会社の新入社員にマニュアルを渡すのと同じ要領で、SKILL.md というテキストファイルに「やり方」を書いて所定のフォルダに置くだけ。AIエージェントが自動的にそれを見つけて読み込み、指示通りに仕事をしてくれる。 2025年12月に Anthropic がオープンスタンダードとして公開 Claude, GitHub Copilot, OpenAI Codex, Cursor など主要AIツールが対応 2026年2月時点でマーケットプレイス登録数は20万件超 なぜ Agent Skills が必要か — プロンプトの3つの限界 従来のプロンプト運用には以下の限界があった。Agent Skills はこれらを全て解決する。 限界 問題 Agent Skills での解決 毎回同じ説明が必要 技術スタック、規約、コミットルールを毎回ゼロから伝える 一度書けば繰り返し使える チーム共有できない 優れたプロンプトがチャット履歴に埋もれる Git で管理・共有可能 コンテキスト圧迫 毎回全情報を読み込むと、肝心のタスクの余裕が減る 必要な時に必要な分だけ読み込む「段階的開示」 Claude Code のセットアップ手順 Agent Skills を使う最も一般的な環境は Claude Code（Anthropic 提供のターミナル型AIコーディングツール）。ブラウザ版の Claude.ai と違い、PCのファイルを直接読み書きできるのが特徴。 1 2 3 4 5 6 7 8 9 10 11 12 # 1. Node.js の確認（v18.0.0 以上が必要） node --version # 2. Claude Code のインストール（Mac / Linux） curl -fsSL claude.ai/install.sh | bash # 3. 確認 claude --version # 4. 初回起動（ブラウザでログイン画面が開く） mkdir ~/my-project && cd ~/my-project claude SKILL.md の書き方 SKILL.md は YAMLフロントマター + Markdown 本文 の2部構成。 ...

Anthropic 社内チームの Claude Code 活用 — マーケから法務まで、全部門が「自分で自動化」する時代 Anthropic 公式記事: How Anthropic teams use Claude Code 再現記事: Claude Code で広告バナー200本を15分で作る手順 紹介ポスト: commte はじめに Anthropic が「自社のチームが Claude Code をどう使っているか」を公式ブログで公開した。注目すべきは、エンジニアリングチームだけでなく、マーケティング、法務、データサイエンス、デザインといった非技術部門が、コードを1行も書かずに高度な自動化を実現している点。 特にマーケティングチームの事例は、ツイートでも「えぐい広告手法」として話題になり、実際に再現して15分で広告バナー200本を生成した記事も登場した。 マーケティングチーム — たった1人で10倍の成果 チーム構成 驚くべきことに、Anthropic のグロースマーケティングチームはエンジニアがゼロの1人チーム。担当の Austin Rau 氏は、元々ターミナルの開き方すら知らなかったという。 それが、非技術者向けガイドを見てから1週間で、Figma プラグインと広告コピー生成ワークフローの両方を構築した。 4つの自動化事例 1. Google Ads の広告コピー生成（2時間 → 15分） 数百件の既存広告 CSV を Claude Code に読み込ませ、パフォーマンスの低い広告を自動特定。改善案をサブエージェント方式で生成する。 サブエージェント設計のポイント: エージェント 専門 制約 headline-writer 見出し生成 30文字以内 description-writer 説明文生成 90文字以内 1つのプロンプトで全部やらせるのではなく、タスクごとに専門エージェントを分けることで、文字数制約を守りつつ品質を維持する。 2. Figma プラグインでバナー一括生成（数時間 → 0.5秒） Claude Code で自作した Figma プラグインが、テンプレートのテキストノードを CSV データで自動差し替え。最大100パターンのバナーを一括生成する。 ...

Claude Code の「YOLO モード」を安全に使う — dangerously-skip-permissions と Docker 活用 関連ポスト: hiragram リポジトリ: hiragram/claude-docker はじめに Claude Code を使っていると、ファイル編集やコマンド実行のたびに「これを実行してもいいですか？」と確認を求められる。安全設計として正しいが、反復的な作業では毎回の承認が煩わしくなる。 そこで登場するのが --dangerously-skip-permissions フラグ。通称「YOLO モード」。YOLO とは “You Only Live Once”（人生は一度きり） の略で、「結果を気にせず、とにかくやってしまえ」というネットスラング。安全確認を一切スキップして全操作をぶっ通しで実行させる様子が、まさに「後先考えずに突っ走る」YOLOの精神そのものであることから、コミュニティでこう呼ばれるようになった。 便利だが、名前の通り危険も伴う。このフラグの本質と、安全に使うための Docker 活用について整理する。 --dangerously-skip-permissions とは Claude Code の全てのパーミッションチェック（権限確認プロンプト）をバイパスし、完全に自律動作させるフラグ。 1 claude --dangerously-skip-permissions 3つの動作モードの比較 モード 挙動 ユーザー介入 通常モード ファイル変更・コマンド実行のたびに承認を要求 毎回必要 Auto-Accept (Shift+Tab) UI上で承認を自動化 介入可能 dangerously-skip-permissions 全ての安全ガードレールを除去 一切不要 なぜ「dangerously」と名付けられているのか Anthropic が意図的に「危険」という語を含めている。実際にリスクは深刻で、以下のような報告がある。 Wolak 事件（2025年10月）: Ubuntu/WSL2 上で Claude Code が rm -rf / を実行し、/bin、/boot、/etc などシステムディレクトリを破壊 eesel AI の調査によると、このフラグ使用者の 32% が意図しないファイル変更を経験、9% が実際のデータ損失を報告 主なリスク リスク 具体例 破壊的コマンドの無確認実行 rm -rf、git reset --hard、設定ファイル上書き スコープクリープ 指定範囲外のファイルを「親切心」で変更・削除 資格情報の漏洩 ホストの全資格情報にアクセス可能な状態 連鎖的被害 1つの誤った解釈が次々と問題を引き起こす それでも YOLO モードが必要な理由 危険だが、以下のユースケースでは事実上不可欠。 ...

Claude Code の能力を10倍にする CLAUDE.md — AI エージェントのマネジメント哲学 紹介ポスト: チャエン @masahirochaen 解説記事: Zenn: Claude Codeの能力を10倍にする CLAUDE.md の中身を見てみた はじめに 海外で大バズりした「Claude Code の能力を10倍にする CLAUDE.md」。Anthropic の Claude Code 開発者が実際に使っているベストプラクティスを、1つの CLAUDE.md ファイルに構造化したもの。 これは単なるプロンプトテンプレートではない。AI エージェントをどうマネジメントするかという哲学を、実装可能な形にまとめたファイルだ。 6つのワークフロー原則 1. Plan Mode デフォルト 「3ステップ以上、またはアーキテクチャ判断を伴うタスクは、必ず Plan Mode から始めよ」 Claude Code が実装に飛びつくのを防ぐ最も重要なルール。計画なしに実装を始めると、途中で方向修正が必要になったとき、修正の連鎖（カスケード失敗）が発生する。 やり方: Shift+Tab を2回押して Plan Mode に入る Claude の計画が納得できるまでやり取りを繰り返す 計画が固まったら Auto-Accept モードに切り替えて一気に実装 実行中に問題が起きたら: すぐに Plan Mode に戻って再計画する Plan Mode は「最初の設計」だけでなく「リカバリー」にも使う 2. サブエージェント戦略 「リサーチ、探索、並列分析はサブエージェントに委譲せよ」 メインのコンテキストウィンドウは有限のリソース。調査や分析をメインエージェントにやらせると、コンテキストが汚れて本来のタスクの品質が下がる。 サブエージェントに委譲すべきタスク: コードベースの調査・探索 複数ファイルの並列分析 計算集約的な処理 独立した検証作業 メインエージェントに残すべきタスク: 最終的な設計判断 コードの実装 統合・結合 初心者向け解説: 「サブエージェント（Task）」とは何か 「サブエージェント」と聞くと難しそうだが、仕組みはシンプル。Claude Code が内部的に「別の Claude」を立ち上げて、作業を分担する機能のこと。Claude Code ではこれを Task と呼ぶ。 ...

Claude Code 開発者が教える CLAUDE.md と実践 Tips 元スレッド（個人セットアップ編）: Boris Cherny @bcherny（53K いいね、780万ビュー） 元スレッド（チーム Tips 編）: Boris Cherny @bcherny（49K いいね、850万ビュー） 紹介ポスト: すぐる @sugurukun_ai 設定再現リポジトリ: 0xquinto/bcherny-claude はじめに Claude Code の開発者である Boris Cherny 氏が、自身のセットアップと Claude Code チーム全体の使い方を X で公開し、合計 10 万いいね以上を獲得して大きな話題になった。 この記事では、2つのスレッドの内容を統合して「CLAUDE.md の育て方」と「Claude Code を最大限活用する 10 の Tips」をまとめる。 CLAUDE.md とは CLAUDE.md は、Claude Code がセッション開始時に自動的に読み込むプロジェクトの指示書。新入社員に渡すオンボーディングドキュメントのようなもので、以下を記述する: プロジェクトの技術スタック・アーキテクチャ コーディング規約・命名ルール よく使うコマンド 過去に Claude が犯した間違いと対策 やってはいけないこと 配置場所 ファイル スコープ ~/.claude/CLAUDE.md 全プロジェクト共通（個人設定） プロジェクトルート/CLAUDE.md そのプロジェクト限定（チーム共有・Git 管理） Boris Cherny のセットアップ（スレッド1） 1. 並列セッション Boris はターミナルで 5 つの Claude を同時に並列実行している。さらに claude.ai/code 上でも 5〜10 個を並行稼働させ、システム通知で完了を監視する。 ...

Claude Projects × GitHub 同期 — AI のメモリより精度が高いナレッジ管理 紹介ポスト: yriica 「ClaudeのProjects内のFilesにGitHubリポジトリを同期できることが判明。GitHubリポジトリに日報含めいろんなデータをプッシュしておいたことで、その内容をふまえた上でClaudeでチャットができるようになった。AIのメモリ機能よりもこちらのほうが回答精度が高い。」 はじめに Claude.ai（ブラウザ版）の Projects 機能に、GitHub リポジトリのファイルを直接同期できる機能がある。日報、議事録、設計メモなど、普段の業務で Git に蓄積していたドキュメントが、そのまま Claude の高精度なコンテキストとして機能する。 これは「AI のために特別なことをした」のではなく、普段の業務として Git にドキュメントを蓄積していたものが、AI 活用で大きなアドバンテージになったという事例。 Claude Projects の GitHub 連携とは 基本機能 Claude.ai の Projects には「プロジェクトナレッジ」としてファイルを追加できる。ここに GitHub リポジトリを接続すると: リポジトリ内のファイル名と内容が Claude に読み込まれる 「Sync now」ボタンで最新のコミット内容に更新できる 複数リポジトリを1つのプロジェクトに追加可能 プライベートリポジトリにも対応（GitHub App 経由で権限付与） 設定方法 チャット内から追加する場合: 左下の「+」ボタンをクリック ドロップダウンから「Add from GitHub」を選択 ファイルブラウザで特定のファイルやフォルダを選択 メッセージ送信時に Claude がコンテンツを処理 プロジェクトナレッジとして追加する場合: プロジェクト知識セクションの右上「+」をクリック 「GitHub」を選択 リポジトリを検索、または URL を貼り付け ファイルブラウザで対象を指定 プロジェクトナレッジに追加 同期の仕組み 特定ブランチのファイル名とコンテンツのみが同期される コミット履歴、PR、Issue などのメタデータは取得されない 「Sync now」ボタンで手動更新（自動同期ではない） 大きな変更がある前に同期を実施するのがベストプラクティス 制限事項 複数リポジトリ追加時は Claude のコンテキストウィンドウに収まる必要がある 現在ベータ版 トークン制限を考慮した戦略的なファイル選択が重要 なぜ「メモリ機能より精度が高い」のか Claude にはチャットの中から情報を学習する「メモリ」機能があるが、GitHub 同期とは根本的に性質が異なる。 ...