Github

Claude Code の「処理」と「ドメイン知識」をレイヤー分離する設計術 — スキルが複利で効く構造をつくる gura 氏の投稿が、Claude Code を使った PM 業務の知見を共有しています。2 ヶ月間の実運用で最も効いた設計判断は、Skill（処理レイヤー）と CLAUDE.md（ドメイン知識レイヤー）の分離だったとのことです。この考え方は、Claude Code の公式アーキテクチャとも一致する設計パターンです。 問題：なぜ全部入りの設定は破綻するのか Claude Code を使い始めると、多くの人が CLAUDE.md にあらゆる情報を詰め込みます。プロジェクトの規約、処理手順、ドメイン知識、スタイルガイド。しかしこの「全部入り」アプローチには構造的な問題があります。 コンテキスト汚染: CLAUDE.md はセッション開始時に全文がロードされるため、情報量が増えるほどトークンを圧迫します Lost in the Middle: 長大なコンテキストの中間部分が軽視される現象が発生します 再利用不能: プロジェクト固有の知識と汎用的な処理手順が混在し、別プロジェクトへの横展開ができません SO Technologies 開発者ブログの分析によると、全部入り CLAUDE.md はセッション開始時にコンテキストの 40〜50% を占有するケースもあったと報告されています。 2 つのレイヤーを分離する gura 氏が提唱するのは、明確な 2 層構造です。 Skill = 処理レイヤー 「どのフォルダから何を読んで、どう加工して、どこに出すか」を定義する Skill は入力と出力が明確な、小さな処理単位です。 Skill の例 入力 出力 議事録の文字起こし 音声データ テキスト議事録 外部向け議事録変換 内部議事録 フィルタリング済み議事録 Slack 共有 文書 Slack メッセージ レポート生成 各種データ フォーマット済みレポート Skill は どのプロジェクトでも処理の骨格は同じ です。ファイルの場所は .claude/skills/<skill-name>/SKILL.md に配置し、YAML フロントマターで名前と説明を記述します。 ...

OpenClaw で 13 体の AI チームを組織する — 低スペック PC で営業・SNS 運用を完全自動化 @gagarotai200（ガガロットAI）さんのポストが話題になっています。OpenClaw を使って 13 体の AI エージェントを組織し、営業・SNS 運用・分析・アポ取りまで完全自動化しているリアルな環境を公開した内容です。16 万回以上の閲覧、880 件のブックマークを集めており、実運用例の少ない OpenClaw 界隈で注目を集めました。 『Open Claw』って実際の環境を出してる人マジで少ないのでオラの13体のAI組織で「営業」「SNS運用」「分析」「アポ取り」など完全自動で行わせてる実際のリアルな環境を3日間限定で全て公開した。 OpenClaw とは何か OpenClaw は、PSPDFKit の創業者 Peter Steinberger 氏が 2025 年 11 月に公開したオープンソースの AI エージェントフレームワークです。GitHub スター数は 20 万超に達し、2026 年現在で最も注目されている AI エージェント基盤の一つです。 従来のチャットボットとの最大の違いは、質問に答えるだけでなく、タスクを直接実行できる点にあります。ファイル操作、メール送信、スケジュール管理、コード実行など、PC 上でユーザーが行う作業を AI が代行します。 主な特徴 特徴 内容 動作環境 ローカルマシン（Mac, Linux, Windows WSL2） 通信チャネル Discord, Telegram, Slack, WhatsApp, Signal, iMessage スキルシステム ClawHub（3,000+ のコミュニティスキル） エージェント定義 SOUL.md（自然言語でのパーソナリティ定義） マルチエージェント Multi-Agent Routing でエージェント間を分離 コスト オープンソース（API 従量課金のみ） 13 体 AI チームの構成 ガガロットさんの環境では、MacBook Pro M1 上で 13 体の AI エージェントを階層的に組織しています。 ...

Prompt Request — Pull Request の次の形：コードを書く時代から「意図を書く時代」へ @The_AGI_WAY（ハヤシシュンスケ）氏のポストが話題です。 コードを書く時代から、意図を書く時代へ。GitHub Issue にこう書く。「[auto] ユーザー認証のエラーハンドリングを追加しろ」 引用元は @Shuns_AI 氏が X で公開した長文記事「Prompt Request — Pull Request の次の形」です。AI エージェントが GitHub Issue を読み取り、ブランチ作成から実装・テスト・PR 作成・マージまでを自律的に完了するワークフローを提案しています。92 タスクで 95% の成功率を達成したという実績とともに、「良い Issue を書く能力」こそが開発者の最重要スキルになるという主張が注目を集めました。 「Prompt Request」とは何か 「Prompt Request」は、従来の Pull Request（PR）に代わる新しい開発パラダイムを表す概念です。 項目 Pull Request Prompt Request 開発者の作業 コードを書いて PR を作成する GitHub Issue に意図を書く 実装の担い手 人間の開発者 AI エージェント レビュー 人間がコードレビュー AI がピアレビュー + 人間が最終確認 マージ 人間が判断してマージ 条件を満たせば自動マージ 所要時間 数時間〜数日 5〜15 分 PR がコードの差分を中心とした「成果物の提出」であるのに対し、Prompt Request は「意図の伝達」が起点になります。開発者が書くのはコードではなく、何をしたいかという自然言語の指示です。 ワークフローの全体像 記事で提案されているワークフローは次のとおりです。 ...

Second Me — AI に「自分の分身」を持つ時代と OpenClaw との本質的な違い 前回の記事で OpenClaw による 13 体 AI チーム構築を紹介しました。OpenClaw では SOUL.md というファイルでエージェントの「人格」を定義しますが、これは本当に「自分の分身」と呼べるのでしょうか。Second Me というプロジェクトは、まったく異なるアプローチで「AI による自分の分身」を実現しようとしています。 SOUL.md の限界 — 「指示書」は「分身」ではない OpenClaw の SOUL.md は Markdown で書かれた設定ファイルです。エージェントの名前、性格、役割、制約を自然言語で記述します。 1 2 3 4 5 6 7 8 9 10 --- name: sales-agent model: claude-sonnet-4-6 --- あなたは営業チームの一員です。丁寧に話してください。 ## 役割 - リード情報の整理と優先順位付け - 提案メールの下書き作成 これは強力な仕組みですが、あくまで外から与える指示書です。「営業エージェントをこう振る舞わせたい」という設計者の意図を反映したものであり、「この人ならどう考えるか」を再現するものではありません。 ...

組織の課題管理から個人のタスク整理と優先度づけへ — Claude Code によるタスクトリアージ 各システムの役割と利用者 システム 主な利用者 目的 Backlog 利用者側の責任者・管理部門 利用者が課題を把握・確認するため Asana 開発会社の PM・経営者 開発会社の責任者が状況を把握するため GitHub 開発担当者 作業担当者が実装・コード変更を管理するため 3層の責任構造 利用者（顧客） 開発会社（経営・PM） 開発会社（作業担当） │ │ │ Backlog Asana GitHub 課題確認会で 経営判断・ Issue/PR で 進捗レビュー リソース配分 実装を管理 各システムは異なるステークホルダーが、それぞれの責任範囲で状況を把握するために存在する。 これは冗長ではなく、報告先ごとに適切な粒度・視点で情報を提供するための構造。 担当者の課題: 「今何をすべきか」の判断 3システムはどれも他者への報告用であって、担当者が「自分が次に何をやるか」を整理する場所ではない。 システム 読者 自分の優先度確認に使えるか Backlog 利用者の責任者 △ 顧客視点の優先度であって自分の作業順ではない Asana 開発会社の経営・PM △ 経営視点のフィルタがかかっている GitHub (epm-server) 作業担当者 △ Issue は技術タスク単位で、全体俯瞰しにくい 解決策: Claude Code でタスクトリアージ → プライベートリポジトリの Issue に記録 タスクトリアージ（状況分析と優先度づけ）は Claude Code セッションで行い、結論の記録先は社内プライベートリポジトリの GitHub Issue に置く。 ...

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的 Claude Code や OpenClaw で MCP（Model Context Protocol）を使っている方に知ってほしい事実があります。MCP はスキーマ注入だけで数万トークンを消費しており、同じタスクを CLI 経由で実行すると 35 倍効率的 になるケースがあるのです。 @SuguruKun_ai さんのポスト と @shinzizm2 さんのポスト でこの問題が指摘され、大きな反響を呼びました。 MCP のトークン消費問題とは スキーマ注入の仕組み MCP サーバーを接続すると、ツール定義（スキーマ）がシステムプロンプトに注入されます。これは AI が「どんなツールを使えるか」を理解するために必要な情報ですが、この定義自体が大量のトークンを消費します。 MCP サーバー接続時の処理: 1. tools/list でツール一覧を取得 2. 各ツールの名前、説明、パラメータ定義を取得 3. 全てのスキーマをプロンプトに注入 ← ここで大量消費 4. ユーザーの質問に回答 あなたが何も入力する前に、スキーマだけでトークンが消費されているのです。 具体的な数値 MCP サーバー ツール数 トークン消費量 GitHub MCP サーバー 93 ツール 約 55,000 トークン Notion サーバー 15+ ツール 約 8,000 トークン ファイルシステム 10 ツール 約 4,000 トークン 平均的なツール定義 1 ツール 300〜600 トークン GitHub MCP サーバーの場合、93 ツール分のスキーマには owner、repo、title 等のプロパティ定義、required フィールド、入出力スキーマが全て含まれます。 ...

なぜ 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 薄いグレー） これは「悪い」デザインではなく、統計的に平均的なデザインです。どのプロジェクトにも合いそうで、どのプロジェクトにも合わない — そういう出力になります。 ...

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