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 コマンドでインストール済みスキルの一覧を確認できます。 ...

Figma が提供する AI デザイン機能「Figma Make」を実務で活用するための実践的なコツをまとめる。1000 回以上のプロンプト作成を通じて見つかった知見や、効率的なワークフローを紹介する。 Figma Make とは Figma Make は、Figma に統合された AI 搭載のデザイン生成ツール。テキストプロンプトからUIデザインを自動生成でき、AutoLayout 付きの構造化されたデザインを高速に作成できる。 実践テクニック 1. Context 設計を明確にする AI に指示を出す前に、以下を明確にしておくことが重要: ユーザーペルソナ: 対象ユーザーの年齢層、IT リテラシーなど 実行アクション: 何をデザインするのか具体的に 制約条件: ブランドカラー、フォント指定、アニメーション仕様など 例: 「40代のITリテラシーが低いユーザー向けの、 シンプルで直感的なダッシュボード画面を作成してください。 フォントはNoto Sans JP、メインカラーは#2563EB」 2. 「大枠 → ピンポイント」の2段階アプローチ 一度に完璧を目指すのではなく、2段階で進める: 第1段階（大枠）: 初期プロンプトで全体構造を作る 対象画面の詳細説明 必要な機能リスト デザインテイスト（既知のサービス名で参照すると有効） 第2段階（ピンポイント）: ファイル名やクラス名を指定して細部を修正 3. デザインシステムを活用する 既存のテンプレートやサンプルをインポートして効率化する: 既存のデザインをキャンバスに置いて「これっぽく作って」と指示 Guidelines.md にデザインシステムとコーディングルールを記載 「〇〇画面の△△表と同様の UI で」と既存 UI を参照指示 4. Figma Design との往復ワークフロー Figma Make 単体で完結させるのではなく、通常の Figma Design と組み合わせる: Figma Make でデザインを生成 コピーして Figma Design にペースト Design で手動修正して期待通りに調整 修正版を再度 Figma Make に取り込んで再実行 このサイクルを回すことで、レイヤー構造が整理され、より高品質なコード生成が実現する。 ...

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がエクスポートしていない」という問題が発生しない。契約が明示的で、検証可能になる。 ...

AI スタートアップが必死に探している人材がいる。営業でもマーケでもエンジニアでもない、しかしその全部を1人でやる「GTMエンジニア」だ。Y Combinator 出身の創業者たちがこぞって求めるこの職種は、AI 時代のキャリアの新しい形を示している。 GTMエンジニアとは GTM は “Go-To-Market” の略で、プロダクトを市場に届けるための戦略とオペレーション全体を指す。どのターゲットに、どのチャネルで、どうやって届け、売上につなげるか。マーケティング、営業、カスタマーサクセスにまたがるこの一連のプロセスが「GTM」だ。 従来はこの領域を、SDR（インサイドセールス）、RevOps（レベニューオペレーション）、グロースチームといった複数部門が分担していた。それが今、AI の進化によって 1人で完結できる ようになりつつある。 この「1人で全部やれる人間」が GTMエンジニアだ。テック業界で最も高給な職種の一つになりつつあり、平均年収は3,000万円〜5,000万円程度とされる。 GTMエンジニアが1人でやること その仕事の範囲は驚くほど広い： ICP（理想的な顧客像）とTAM（獲得可能な市場全体）の設計 メール配信インフラの構築 「買いそうなシグナル」の検知 — 企業の採用情報や資金調達などからリストを構築 アカウント情報のエンリッチメント アウトバウンド営業の自動化と有望リードの自動振り分け インバウンドのリード評価・スコアリング・商談準備の一気通貫設計 営業コールのAI分析とフィードバックループ構築 CRMのアーキテクチャ設計とレポーティング 以前は3つ以上のチームが10人以上で回していた仕事だ。それを AI を武器にして1人でやる。 なぜ今、この役割が生まれたのか 背景は2つある。 1. AIツールの進化 Clay、Apollo、Gong、Salesforce といったツールが個別に進化してきたところに、ChatGPT や Claude のような LLM が登場し、ツール間の「接着剤」となる作業を自動化できるようになった。API を繋ぎ、プロンプトでロジックを組み、ワークフローを自動化する。技術的に考えられる人間が1人いれば、チーム全体のオペレーションを設計・実行できてしまう。 2. スタートアップの経済的現実 シード期のスタートアップに SDR チーム、RevOps マネージャー、グロースマーケターをそれぞれ雇う余裕はない。でも GTM はやらなければ売れない。「1人で全部やれる人間」への需要が爆発した理由はここにある。 GTMエンジニアに求められる3つの能力 1. 営業サイクル全体の理解 見込み客の発掘からナーチャリング、商談、クロージングまで。一連の流れを理解していないと、自動化の設計ができない。何を自動化すべきで、何は人間がやるべきか。この判断は営業プロセスへの深い理解なしにはできない。 2. 技術的思考力 コードをゴリゴリ書く必要はないかもしれないが、API の仕組み、データの流れ、ワークフローの設計ができなければ話にならない。「Clay のテーブルを作れます」程度では全く足りない。システム全体をアーキテクチャとして設計する力が必要だ。 3. AIで実務を回した経験 「AI を知っている」ことではなく「AI で実際にオペレーションを回した経験がある」ことが求められる。パイプラインを組んで、データを流して、結果を見て改善する。この実務経験がなければ、チーム全体の業務を1人で回すことはできない。 「AIが仕事を奪う」話ではない GTMエンジニアの登場は「AI が人間の仕事を奪った」話ではない。「AI によって1人の人間の能力が10倍になった」話 だ。 ...

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 の有効化が必要。 ...

Andrej Karpathy が公開した autoresearch は、AI エージェントが単一 GPU 上で自律的に ML 実験を繰り返すツールです。わずか約630行の Python コードで「コード修正 → 学習 → 評価 → 改善」のループを自動化し、研究の競争軸を「コード品質」から「改善ループの速度」へと変えようとしています。 autoresearch とは autoresearch のコンセプトはシンプルです: AIエージェントに小さいが本物の LLM トレーニング環境を渡し、一晩中自律的に実験させる エージェントはトレーニングコード（train.py）を自動修正し、5分間のトレーニングを実行、検証損失（val_bpb）が改善したかを確認し、結果に基づいて次の実験に進みます。 プロジェクト構成 autoresearch はたった3つのファイルで構成されています: ファイル 役割 編集者 prepare.py データ準備・ランタイムユーティリティ 変更不可 train.py モデル・オプティマイザ・学習ループ AIエージェント program.md エージェントへの指示書 人間 従来のML研究では Python ファイルを直接編集しますが、autoresearch では Markdown ファイル（program.md）でエージェントに指示を与える という設計になっています。人間が行うのは「プログラムのプログラミング」です。 固定時間予算という設計判断 autoresearch の重要な設計判断は、全てのトレーニングを ちょうど5分間 に固定していることです: 1時間あたり約12回の実験が可能 一晩（8時間）で約100回の実験を自動実行 プラットフォームに依存せず公平な比較が可能 1 2 3 4 5 6 # セットアップ uv sync uv run prepare.py # データ準備（初回のみ、約2分） # 単一実験の実行 uv run train.py # 約5分で完了 エージェントの起動は、Claude などの AI に対して以下のように指示するだけです: ...

OpenAI が Symphony というオープンソースの自動化基盤をリリースしました。Issue トラッカーから課題を読み取り、課題ごとに隔離ワークスペースを作成し、AI エージェントに実装を走らせるオーケストレーションフレームワークです。 Symphony とは Symphony は、AI コーディングエージェントを手動のプロンプト操作から構造化された自律実行へと移行させるためのフレームワークです。Elixir / Erlang BEAM ランタイム上に構築されており、長時間実行される独立した「実装ラン（implementation run）」を高い並行性と耐障害性で管理します。 従来の「AI にコードを書かせて PR を出す」という手動プロンプト型のワークフローを、カンバンボードのタスクカードを移動するだけで管理できるようにします。 動作の仕組み Symphony の基本的な流れは以下の通りです: 課題の読み取り — Issue トラッカー（現在は Linear をサポート）からタスクを継続的に監視 隔離ワークスペースの作成 — 各課題に対して独立したワークスペースを生成 エージェントの実行 — ワークスペース内でコーディングエージェントセッションを実行 成果物の提出 — CI ステータス、PR レビューフィードバック、複雑度分析、操作動画などの「作業証明」を提供 承認とマージ — タスクが承認されると、エージェントが安全に PR をマージ 技術的な特徴 WORKFLOW.md によるエージェント制御 エージェントのプロンプトやランタイム設定は、リポジトリ内の WORKFLOW.md に直接保存されます。これにより、AI の動作指示がコードとしてバージョン管理され、変更対象のブランチと同期されます。 Elixir / BEAM ランタイムの採用 Elixir と Erlang/BEAM ランタイムを採用することで、以下のメリットがあります: 高い並行性 — 複数のエージェントセッションを同時に管理 耐障害性 — 個別の実装ランが失敗してもシステム全体に影響しない 長時間実行への対応 — エージェントの長時間稼働を安定的にサポート Poll-Dispatch-Resolve-Land ワークフロー Symphony の中核となるワークフローパターンです: ...

18歳、コーディング経験ゼロ、高校を卒業したばかりの起業家が OpenClaw を使って15人の AI エージェントチームを構築し、月額400ドルで24時間稼働させている事例が話題になっています。GitHubやIDEの知識がなくても、AI チームを組織できる時代が来ています。 OpenClaw とは OpenClaw は、Peter Steinberger が開発したオープンソースの自律型 AI エージェントです。2026年3月時点で GitHub スター数は約247,000、フォーク数は47,700を超え、爆発的な成長を遂げています。 完全にオープンソースでサブスクリプションや API 費用が不要なため、実際にかかるコストはハードウェアと電気代のみ。専用サーバー（OVH で月45ドル、Hetzner で月40ドル程度）を使えば、低コストで本格的な AI チームを運用できます。 AI チームの構成 YouTube 動画「I Built a Full AI Team Inside OpenClaw for $400/Month」（4.2万回再生）では、以下のような AI エージェントチームの構築が紹介されています: エージェント名 役割 ATLAS 戦略・計画策定 SCRIBE ドキュメント・コンテンツ作成 PIXEL デザイン・ビジュアル NOVA リサーチ・分析 SENTINEL 監視・品質管理 CLOSER セールス・クロージング CLAND コーディング・開発 CLIP 動画・メディア編集 各エージェントは agents/ フォルダ内にサブフォルダとして定義され、それぞれの AGENTS.md に役割・ツール・振る舞いが記述されます。 セットアップの仕組み OpenClaw のマルチエージェント構成は以下のような構造です: workspace/ ├── agents/ │ ├── atlas/ │ │ └── AGENTS.md # 戦略担当の定義 │ ├── scribe/ │ │ └── AGENTS.md # ライティング担当の定義 │ ├── cland/ │ │ └── AGENTS.md # 開発担当の定義 │ └── ... └── program.md # チーム全体への指示 エージェントは MCP スキルを通じて各種ツールと連携し、Reddit や Twitter のシグナル収集、トレンド分析、コンテンツ生成などを自律的に実行します。 ...