AI/LLM

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 同期とは根本的に性質が異なる。 ...

git-lrc — コミット時に AI が無料でコードレビューしてくれるツール リポジトリ: HexmosTech/git-lrc 紹介ポスト: commte これは何か git-lrc は、git commit のタイミングで自動的に AI コードレビューが走るツール。Git フックとして動作し、コミット前の差分を AI（Google Gemini）に分析させ、バグやセキュリティ問題をブラウザ上の UI でインラインコメントとして表示してくれる。 しかも Gemini の無料枠を使うので完全無料。 なぜこれが作られたのか AI エージェント時代の新しい問題 Claude Code や Cursor などの AI コーディングエージェントは、コードを高速に生成する。しかし同時に、黙ってロジックを削除したり、挙動を変えたり、バグを混入させることもある — しかもユーザーに何も言わずに。 問題に気づくのは、たいてい本番環境にデプロイした後。 既存のコードレビューの限界 PR レビュー: チームメンバーの時間を消費する。AI 生成コードの量が増えるとレビューが追いつかない 手動チェック: 大量の差分を毎回目視確認するのは非現実的 CI/CD のテスト: テストがカバーしていない箇所の論理変更は検出できない git-lrc のアプローチ 「コミット」という全開発者が必ず通るポイントにフックすることで、レビュー漏れをほぼゼロにする。エディタや AI ツールキットが何であっても、Git は共通基盤。コミットは必須操作なので、スタックに関係なくレビューが走る。 どう動くのか セットアップ（約1分、1回だけ） 1 2 3 4 5 # インストール（Mac / Linux） curl -fsSL https://hexmos.com/lrc-install.sh | sudo bash # 初期設定（ブラウザで API キーを取得） git lrc setup 必要なのは2つ: ...

コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い 紹介ポスト: えいと @7_eito_7 「AIを使っている人と、本当にAIを使いこなしている人の違いは何か。結論はコンテキストエンジニアリングができるかどうか。簡単に言えば、指示の出し方ではなくどんな文脈を渡しているか。」 はじめに 2025年半ば、Shopify CEO の Tobi Lütke が次のように発言した: 「“プロンプトエンジニアリング"より"コンテキストエンジニアリング"という言葉の方がずっと好きだ。LLM がタスクを解決できるだけの十分な文脈を与える技術 — これこそが核心的スキルだ。」 AI 研究者の Andrej Karpathy もこれに同意し、「コンテキストエンジニアリング」という概念は一気に広まった。2026年現在、プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが AI 活用の新しい標準になりつつある。 プロンプトエンジニアリング vs コンテキストエンジニアリング 観点 プロンプトエンジニアリング コンテキストエンジニアリング スコープ 1つの入力テキストの書き方 モデルが見る情報の全体設計 焦点 指示の言い回し・構造 情報の選択・順序・形式・量 対象 単発の質疑応答 複雑な推論、マルチターン、エージェント 複雑さ 文章レベル システムレベルのパイプライン 例え 「質問の仕方を工夫する」 「解答に必要な教科書・資料・道具を揃える」 プロンプトエンジニアリングはコンテキストエンジニアリングの一部にすぎない。質問の質ではなく、AI に渡す情報の質と構造が結果を決める。 なぜプロンプトだけでは不十分なのか よくある問題: RAG で正確な情報を取得し、プロンプトも丁寧に書いた。それでも AI がハルシネーションを起こす。 原因はプロンプトでも検索でもなく、コンテキストの構造にある。 プロンプトの 3 つの限界 情報不足: 質問は完璧でも、判断に必要な背景情報が足りない 情報過多: 関連情報を全部詰め込むと、かえって精度が落ちる（ノイズに埋もれる） 情報の無秩序: 重要な情報とそうでない情報が区別なく並んでいる コンテキストエンジニアリングは、この 3 つを体系的に解決する。 コンテキストエンジニアリングの 4 つの柱 1. 構成（Composition）— 何を渡すか タスクに必要な「材料」を選択する: ...