Github

AIエージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある はじめに 2026年に入り、AIエージェント開発の世界で急速に広まっている概念がある。「Agent Harness（エージェント・ハーネス）」 だ。 LLMの性能は日々向上し、Claude Opus 4.6、GPT-5、Gemini 2.5 Pro といったモデルが次々とリリースされている。しかし、現場のエンジニアたちは気づき始めている——同じモデルを使っていても、エージェントの体感品質はまるで別物になるということに。その差を生むのがモデルの「外側」にある仕組み、すなわちAgent Harnessである。 この記事では、Philipp SchmidのAgent Harness論、Lance MartinのContext Engineering解説、そしてManusの実装例を手がかりに、エージェント開発の新しいパラダイムを整理する。 Agent Harness・AIエージェント・LLM の関係 まず、3つの概念の関係を整理する。混乱しやすいのは、これらが入れ子構造になっているからだ。 レイヤー構造 graph TB subgraph UserLayer["ユーザー"] U["指示を出す / 結果を受け取る"] end subgraph AgentLayer["AIエージェント = アプリケーション層"] A1["ユーザー固有のロジック・目的"] A2["例: コードアシスタント、リサーチエージェント、カスタマーサポートBot"] end subgraph HarnessLayer["Agent Harness = OS層"] H1["コンテキスト管理 / ツール実行 / 権限制御"] H2["メモリ管理 / 再試行 / フォールバック / 承認ポイント"] end subgraph LLMLayer["LLM = CPU層"] L1["言語理解・推論・生成"] L2["例: Claude Opus 4.6, GPT-5, Gemini"] end UserLayer --> AgentLayer AgentLayer --> HarnessLayer HarnessLayer --> LLMLayer Philipp Schmidのコンピュータの比喩を使うと： ...

Claude Ads で広告運用を186項目自動監査 — Claude Code スキルが広告代理店の仕事を奪い始めた Claude Ads で広告運用を186項目自動監査 — Claude Code スキルが広告代理店の仕事を奪い始めた @ratekomaru 氏が X で紹介した「Claude Ads」が話題になっています。 Claudeやばすぎだろwwww ピンポイントで業界潰して回ってる。無料でGoogle・Meta・YouTube・LinkedIn・TikTok・Microsoft Adsなど186項目にわたるチェック機能を備えたClaude Code向けの包括的な有料広告監査・最適化スキル「Claude Ads」 12 万超のインプレッション、1,700 以上のいいねという反響は、「AI が広告運用の専門職を代替する」という予感を多くの人が共有している証拠でしょう。本記事では Claude Ads の仕組みを掘り下げつつ、広告業界に起きている構造変化を整理します。 Claude Ads とは何か Claude Ads は、Claude Code 向けに作られたオープンソースの広告監査・最適化スキルです。MIT ライセンスで公開されており、インストールは1コマンドで完了します。 1 curl -fsSL https://raw.githubusercontent.com/AgriciDaniel/claude-ads/main/install.sh | bash 主な特徴は以下の通りです。 項目 内容 対応プラットフォーム Google Ads, Meta Ads, YouTube Ads, LinkedIn Ads, TikTok Ads, Microsoft Ads チェック項目数 190（Google 74, Meta 46, LinkedIn 25, TikTok 25, Microsoft 20） 業種テンプレート SaaS, EC, ローカルサービス, B2B, モバイルアプリ, 不動産, ヘルスケア, 金融など 11 種 並列実行 6 つのサブエージェントが同時にプラットフォーム別監査を実行 ライセンス MIT アーキテクチャ — サブエージェント並列実行 Claude Ads の設計はシンプルですが効果的です。 ...

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 モードが必要な理由 危険だが、以下のユースケースでは事実上不可欠。 ...