記事一覧

OpenClaw と Claude Code を組み合わせることで、AI エージェントチームの構築・管理を効率化できます。本記事では、2つの主要な連携アプローチとそのセットアップ方法を解説します。 アプローチ1: Claude Code のスキルで OpenClaw を管理する Claude Code のスキル機能（.claude/skills/ に配置する Markdown ファイル）を使い、OpenClaw のエージェント作成・設定管理を標準化する方法です。 なぜスキルで管理するのか 複数の AI エージェントを運用していると、以下の問題が発生します: モデルやコンテキストの違いによる設定の不統一 タイムゾーンフィールドの欠落、命名規則の不一致 スキーマ検証やコミットフックによる検証が存在しない Claude Code スキルは「実行可能な基準」として機能し、モデルに依存せず一貫した手順を強制します。 セットアップ cc-openclaw リポジトリを使います: 1 2 3 git clone https://github.com/rahulsub-be/cc-openclaw.git ~/cc-openclaw cd ~/cc-openclaw stow --no-folding -t ~/your-openclaw-home-repo . ここで使っている stow は GNU Stow というシンボリックリンク管理ツールです。dotfiles 管理（.bashrc, .vimrc 等）でよく使われるもので、上記のコマンドは cc-openclaw リポジトリ内のファイル（.claude/skills/ 以下のスキル定義など）を、OpenClaw のホームリポジトリにシンボリックリンクとして配置します。コピーではなくリンクなので、cc-openclaw 側で git pull するだけでスキル定義が最新に更新されます。--no-folding オプションにより、ディレクトリ自体ではなくファイル単位でリンクが作成されます。 ...

OpenClaw をショート動画マーケティングの自動化マシンとして活用する事例が注目を集めています。AI エージェントが TikTok コンテンツの生成・投稿・分析・最適化をループで回し、数十万ビューとアプリダウンロードを達成するという仕組みです。 概要 Greg Isenberg が紹介した事例では、OpenClaw を「AI 従業員」として稼働させ、TikTok 向けのショート動画マーケティングを完全自動化しています。Oliver Henry 氏が構築した「Larry」と呼ばれるシステムは、コンテンツ生成からパフォーマンス分析、改善までを自律的に実行します。 Larry の仕組み Larry は以下のループで動作するフルファネルのフィードバックエンジンです: コンテンツ生成 — OpenClaw がスライドショー形式の TikTok コンテンツを自動作成 投稿準備 — API 直接投稿ではなく、ドラフトとして出力（アルゴリズムペナルティ回避のため、トレンドサウンドは手動追加） パフォーマンス分析 — TikTok のアナリティクスデータを取得し、ビュー数・エンゲージメント・ダウンロード数を分析 最適化ループ — 分析結果をもとにフック（冒頭の引き）や CTA（行動喚起）を改善し、次のコンテンツに反映 TikTok アナリティクスがコンテンツ生成にフィードバックされ、アプリレベルの指標がファネル上部に戻るという循環構造が特徴です。 実績 1 投稿で 137,000 ビュー を達成（画像モデルとフックの最適化後） 別のユーザー（Ernesto Lopez 氏）は同様のアプローチで $70K MRR を報告 Oliver 氏はフルタイムの仕事を続けながら、このシステムで月数百ドルの MRR を生成 技術的なポイント モデル選択は重要ではない Oliver 氏は「Claude か OpenAI かの選択より、どう使いこなすかが重要。98% のユーザーはモデルの差分をほとんど感じない」と述べています。 OpenClaw スキルの利点 スキルはローカルで所有・編集可能 ホスティングやサブスクリプションのコストがゼロ SaaS の代替としてのポテンシャル Genviral の OpenClaw スキル Genviral 社は OpenClaw 向けのソーシャルメディア自動化スキルをリリースしており、42 の API コマンドで TikTok、Instagram、YouTube、Facebook、Pinterest、LinkedIn の 6 プラットフォームに対応しています。 ...

中国の SNS「小紅書（Xiaohongshu / RED）」で、AI エージェントがアカウントを完全自動運営している事例が話題になっている。いち氏（@ichiaimarketer）が紹介したツイートによると、「虾薯（シャーシュー）」というアカウントは人間ではなく AI エージェントが運営しており、投稿の作成から公開、コメント返信、バズったコンテンツの分析・再現まで、すべて自動で行われている。 仕組み：2 つのスキルの連携 このシステムは、OpenClaw のスキル（プラグイン）として公開されている 2 つの GitHub プロジェクトで構成されている。 Auto-Redbook-Skills（コンテンツ制作） comeonzhj/Auto-Redbook-Skills — AI による記事作成と画像生成、自動公開を担当する。 AI がテーマに沿った投稿文を自動生成 8 種類のテンプレートからカバー画像を自動レンダリング 小紅書への自動公開 xiaohongshu-ops-skill（運営オペレーション） Xiangyu-CAS/xiaohongshu-ops-skill — アカウントの日常運営を自動化する。 投稿の自動公開スケジューリング コメントへの自動返信（アカウントのペルソナに合わせた口調で） バズった投稿の分析と複製（「爆款復刻」） アカウントごとのキャラクター設定 この 2 つが連携することで、AI が記事を書き → カバー画像を生成 → 自動公開 → コメントに返信 → バズコンテンツを分析して再現という完全自動のループが実現している。 OpenClaw エコシステムの広がり OpenClaw は 2026 年に入って爆発的に成長し、GitHub のスター数は 2,400 万を超えた。個人の端末上で動作する AI エージェントで、WhatsApp・Telegram・Discord などのチャットアプリを通じて操作できる。 小紅書以外にも、TikTok や各種 SNS プラットフォーム向けのスキルが続々と公開されており、「一人で複数アカウントをマトリクス運営する」ことが技術的に可能になっている。 関連プロジェクトも活発だ： openclaw-xhs — MCP 統合 + ホットトピック追跡 + 個人メモリ機能 xiaohongshu-skills — OpenClaw や Claude Code の SKILL.md 形式に対応 コンプライアンス上の懸念 技術的には可能だが、プラットフォームの利用規約やコンプライアンスの問題は無視できない。 ...

「Vibe Coding」が開発者の間で広まる中、同じ発想をサイバー攻撃に応用する「Vibe Hacking」が新たな脅威として注目されている。AI を使って、専門知識がなくてもマルウェアや攻撃スクリプトを生成できる時代が到来した。 Vibe Hacking とは Vibe Hacking は、AI を活用してサイバー攻撃のハードルを劇的に下げる手法・思想を指す。開発者が自然言語で AI にコードを書かせる「Vibe Coding」のダークサイドとも言える概念だ。 従来のハッキングには、ネットワークプロトコルの理解、脆弱性の発見、エクスプロイトコードの記述といった高度な技術スキルが必要だった。しかし Vibe Hacking では「ターゲットを指定するだけ」「経験不要」「AI が処理する」といった形で、技術的な障壁がほぼ消失する。 具体的な脅威 AI 生成マルウェア HP Wolf Security の脅威インサイトレポート（2025年10月〜12月）によると、攻撃者は AI で生成した感染スクリプトを実際の攻撃キャンペーンに使用している。偽のインボイス PDF を通じて、正規のプラットフォーム（Booking.com など）へリダイレクトする前にマルウェアをダウンロードさせる手口が確認されている。 Flat-Pack Malware 複数の無関係な脅威グループが、同一のモジュール化されたマルウェアコンポーネントを再利用する「Flat-Pack Malware」も増加している。市販のマルウェア部品を組み立てるだけで、最小限の労力でカスタマイズされた攻撃キャンペーンを展開できる。 国家レベルの活用 パキスタン系の脅威アクター「Transparent Tribe」が、AI コーディングツールを使ってマルウェアを「Vibe Coding」し、インド政府やその海外大使館を標的にした事例も報告されている。 なぜ危険なのか 攻撃コストの劇的な低下 脆弱性の発見からエクスプロイト作成までのコストは、かつて数週間と数千ドルを要した。AI によりこれがほぼゼロになりつつある。「スプレー＆プレイ」型の大規模攻撃ではなく、特定のシステムや企業、さらには個々の開発者をピンポイントで狙うマイクロターゲット攻撃が現実的になった。 検出回避能力の向上 HP の調査では、メール脅威の 14% 以上がゲートウェイスキャナーを回避している。AI が生成するコードは毎回微妙に異なるため、シグネチャベースの検出が困難になっている。 Vibe Coding で作られたアプリの脆弱性 攻撃だけでなく、Vibe Coding で開発されたアプリケーション側も問題を抱えている。Veracode の GenAI コードセキュリティレポートによると、AI 生成コードの 45% にセキュリティ脆弱性が含まれている。AI はほぼ半分の確率で安全でない実装を選択する。 対策のポイント AI によるコードレビューの自動化 Vibe Coding で生成された全コードを人間がレビューするのは現実的ではない。コード生成が AI なら、レビューも AI で自動化するのが自然な流れだ。 ...

ローカルで Ollama + Qwen を動かしている Mac Studio（M3 Ultra / 96GB）に、NAS 上の PDF やテキストなどのドキュメントを学習させて「個人の知識ベース」として活用したい——そんなとき、ファインチューニングと RAG のどちらを選ぶべきかを整理する。 やりたいこと NAS に蓄積された個人ドキュメント（PDF、テキスト等）の知識を Qwen に覚えさせたい 自分の PC を使った活動に関する知識を、AI が把握している状態にしたい 選択肢1: ファインチューニング（QLoRA） モデル自体の重みを更新し、知識を「記憶」させるアプローチ。 Mac Studio での実現可能性 M3 Ultra / 96GB 統合メモリなら、QLoRA でのファインチューニングは技術的に可能。 手法 必要メモリ目安（7B） ツール QLoRA (4bit) 6-8 GB Unsloth, LLaMA-Factory, MLX LoRA (16bit) 14-16 GB LLaMA-Factory, PEFT フル FT 60+ GB 非現実的 Apple Silicon では MLX ベースが最もパフォーマンスが良い。 1 2 3 4 5 6 7 8 9 10 # MLX での QLoRA 実行例 pip install mlx-lm mlx_lm.lora \ --model Qwen/Qwen2.5-Coder-14B-Instruct \ --data ./training_data \ --train \ --batch-size 1 \ --lora-layers 16 \ --iters 1000 ファインチューニングの課題 最大のボトルネックはデータ準備。NAS の生ファイルはそのまま学習データにはならず、instruction 形式への変換が必要になる。 ...

Andrej Karpathy が autoresearch を公開した直後、さらに踏み込んだビジョンを示した。「次のステップは、エージェント同士が非同期かつ大規模に協調する仕組みだ」— 単一エージェントの能力向上ではなく、エージェント群の協調システム設計こそが本質だという主張だ。 「一人の博士課程ではなく、研究コミュニティを」 The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。） 現在の autoresearch はコミットを同期的に一本のスレッドで積み上げていく設計だ。だが Karpathy が構想するのは、リポジトリを「種」として無数のエージェントがそこから枝分かれし、異なる研究方向に並列で進んでいく世界だ。SETI@home のような分散コンピューティングモデルを研究に適用するイメージだと言える。 技術的な課題 この構想が実現するには、いくつかのハードルがある: 分散タスクシャーディング — 実験をどう分割して割り当てるか 結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。 「一つを賢くする」から「場の設計」へ IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している: AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。 これは AI エージェント開発における重要なパラダイムシフトだ。これまでの議論は「いかにモデルを賢くするか」「いかにプロンプトを最適化するか」に集中していた。だが autoresearch が示す方向は、個のエージェントの能力向上よりも、エージェント群の協調システム設計に重心が移りつつあるということだ。 Karpathy の言葉を借りれば、エージェントの「知性、注意力、粘り強さがボトルネックでなくなった」とき、既存の開発抽象（Git、CI/CD、コードレビュー）にますます圧力がかかる。 ...

Andrej Karpathy が autoresearch を公開した直後、さらに踏み込んだビジョンを示した。「次のステップは、エージェント同士が非同期かつ大規模に協調する仕組みだ」— 単一エージェントの能力向上ではなく、エージェント群の協調システム設計こそが本質だという主張だ。 「一人の博士課程ではなく、研究コミュニティを」 The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。） 現在の autoresearch はコミットを同期的に一本のスレッドで積み上げていく設計だ。だが Karpathy が構想するのは、リポジトリを「種」として無数のエージェントがそこから枝分かれし、異なる研究方向に並列で進んでいく世界だ。SETI@home のような分散コンピューティングモデルを研究に適用するイメージだと言える。 技術的な課題 この構想が実現するには、いくつかのハードルがある: 分散タスクシャーディング — 実験をどう分割して割り当てるか 結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。 「一つを賢くする」から「場の設計」へ IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している: AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。 これは AI エージェント開発における重要なパラダイムシフトだ。これまでの議論は「いかにモデルを賢くするか」「いかにプロンプトを最適化するか」に集中していた。だが autoresearch が示す方向は、個のエージェントの能力向上よりも、エージェント群の協調システム設計に重心が移りつつあるということだ。 Karpathy の言葉を借りれば、エージェントの「知性、注意力、粘り強さがボトルネックでなくなった」とき、既存の開発抽象（Git、CI/CD、コードレビュー）にますます圧力がかかる。 ...

AI コーディングエージェントの設定ファイル（AGENTS.md、CLAUDE.md など）は「詳しく書くほど良い」と思われがちだ。しかし ETH Zurich の研究チームが138リポジトリ・5,694プルリクエストを対象に行った調査で、詳細すぎるコンテキストファイルはむしろ性能を下げることが実証された。 研究の概要 ETH Zurich の Gloaguen、Mündler、Müller、Raychev、Vechev らが2026年2月に発表した論文で、AGENTS.md ファイルが AI コーディングエージェントの性能に与える影響を大規模に検証した。 対象: 138リポジトリ、5,694プルリクエスト 検証: LLM 生成ファイルと人間が書いたファイルの両方を比較 衝撃的な結果 自動生成されたコンテキストファイルは害になる 成功率が約3%低下 推論コストが20%以上増加 エージェントは推論トークンの14〜22%をドキュメント処理に消費 人間が書いても効果は限定的 改善はわずか**4%**にとどまる コストの増加に見合わない なぜ詳細な指示が逆効果になるのか AI エージェントは「従順すぎる」 エージェントはコンテキストファイルの指示を律儀に守る。そのため、不要な制約が含まれていると逆にタスクが難しくなる。「良かれと思って書いた指示」が足を引っ張る。 ディレクトリツリーやコードベース概要は不要 エージェントはファイル構造を自力で発見するのが得意だ。手動でディレクトリツリーを記述しても、トークンを消費するだけでナビゲーション速度は改善しない。 強いモデルほど追加コンテキストが邪魔になる GPT-5.2 のような強力なモデルは、ライブラリや慣例のパラメトリック知識を既に持っている。追加コンテキストは冗長なノイズになるだけだ。 効果があるのは「非自明なツール指定」 研究で唯一、劇的な効果が確認されたのはプロジェクト固有のツール指定だ： pip の代わりに uv を使う npm の代わりに bun を使う 例えば uv を明示した場合、160倍多く使われたという結果が出ている。エージェントが自力では推測できない「非自明な選択」だけを書くのが正解だ。 推奨される6つの原則 コード内で発見可能な情報は除外 — エージェントが自力で見つけられるものは書かない 否定形ではなく肯定形で指示 — 「〜するな」ではなく「〜せよ」 決定論的チェックと組み合わせる — linter やテストで検証可能なルールを設定 想定ではなく実際の失敗から反復 — 問題が起きてから追記する 重要情報を最初に配置 — トークン処理の優先順位を考慮 30行以下を目指す — プロチームは60行以下、推奨は300行以下 実践的な AGENTS.md の書き方 悪い例（よくある過剰な記述） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # プロジェクト概要 このプロジェクトは React + TypeScript で構築された... # ディレクトリ構造 src/ ├── components/ ├── hooks/ ├── utils/ └── pages/ # コーディング規約 - 変数名はキャメルケースを使用する - コンポーネントはアロー関数で定義する - インポートは以下の順序で記述する... （以下100行続く） 良い例（非自明な指定のみ） 1 2 3 4 5 6 7 8 # ツール - パッケージマネージャ: bun（npm/yarn ではなく） - テストランナー: vitest - フォーマッタ: biome（prettier ではなく） # プロジェクト固有のルール - API クライアントは src/lib/api.ts の共通関数を使う - 環境変数は .env.local から読み込む（.env は使わない） 最良の AGENTS.md は不要なものである 研究が示す最も重要な結論は、AGENTS.md の改善に時間を費やすより、コードベース自体を改善すべきということだ： ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...