Agent

minicoohei 氏（@minicoohei）が、freee の公式 MCP サーバーと Claude Code を組み合わせて確定申告の仕訳1,428件をわずか20分で完了させた事例を公開した。手作業なら4〜5時間かかる Amex のクレジットカード明細の仕訳登録を、AI が自動化した。 ワークフローの概要 Amex の取引明細（1,428件）を入力データとして用意 — 通常の手作業では1件ずつ勘定科目を判断して登録する必要がある AI が70以上の分類ルールを自動生成 — 取引内容のパターンを分析し、勘定科目の振り分けルールを構築する 対話的なルール調整 — 人間との会話を通じてルールを精緻化する。税務リスクのある取引を事前に特定し、適切な処理方法を提案する 並列バッチ処理で一括登録 — freee API 経由で全件をエラーゼロで登録する freee MCP とは freee は公式の MCP サーバー（freee-mcp）を OSS として公開している。会計・人事労務・請求書・勤怠・販売の5領域にわたる API を、AI エージェントから操作可能にするインターフェースだ。 Claude Code や Claude Desktop から接続すると、「この請求書を発行して」「今月の経費を集計して」といった自然言語の指示で freee の業務を実行できる。 なぜ効果的なのか 従来の会計ソフトの自動仕訳機能は、事前に設定したルールに基づく単純なパターンマッチングだった。Claude Code を使うアプローチには以下の利点がある: 文脈理解による分類精度 — 取引先名や摘要の自然言語を理解して勘定科目を判断する。「AWS」なら通信費、「タクシー」なら旅費交通費、といった判断を人間と同等の精度で行える 対話による例外処理 — 判断に迷うケースを人間に確認し、その回答を以降のルールに反映する バッチ処理の効率 — MCP 経由で freee API を直接操作するため、GUI での手作業が不要 実務での注意点 freee MCP を Claude Code と組み合わせる場合、いくつかの実務的な考慮点がある: ...

Andrej Karpathy が公開した autoresearch は、AI エージェントが自律的に ML 実験を繰り返すツールだ。寝ている間に AI が 100 回実験し、朝起きたらモデルが賢くなっている——そんな研究スタイルを 630 行の Python コードで実現する。 autoresearch とは nanochat（軽量 LLM 学習コア）をシングル GPU・1 ファイルに凝縮し、AI エージェントが自律ループで学習コードを改善していく仕組み。 基本構造はシンプル: 人間が .md ファイル（プロンプト）を設計する AI エージェントが .py（学習コード）を自律的に改善する 各実験は ちょうど 5 分間 のトレーニングで構成され、1 時間あたり約 12 回、一晩で約 100 回の実験が自動で回る。 人間: program.md を設計（研究の方針・制約を定義） ↓ AI エージェント: 学習コードを修正 ↓ 5分間のトレーニング実行 ↓ 結果を評価（validation loss） ↓ 改善されていれば git commit → 次のイテレーションへ 技術的な特徴 630 行のミニマル設計 autoresearch の核心は「小さく始めて、エージェントに任せる」という哲学にある。 シングル GPU で完結（マルチ GPU 不要） ニューラルネットワークのアーキテクチャ、オプティマイザ、ハイパーパラメータすべてを AI が調整 git feature ブランチ上で動作し、改善があれば自動コミット MIT ライセンスで公開 「コードを書く」のではなく「プログラムをプログラムする」 Karpathy が強調するのは、研究者が Python ファイルを直接触るのではなく、Markdown でエージェントへの指示を設計するというパラダイムシフトだ。 ...

20歳の中国の大学4年生・郭航江（Guo Hangjiang）氏が、わずか10日間の Vibe Coding で開発した OSS「MiroFish」が GitHub Trending で3日連続1位を獲得し、Star 数は約 11,000 を超えて急増中です。さらに、盛大グループ創業者の陳天橋氏がデモを見て24時間以内に3,000万元（約6.9億円）の即決投資を行ったと報じられています。 MiroFish とは MiroFish は、マルチエージェント技術を活用した次世代の AI 予測エンジンです。ニュース・政策・金融データなどのテキストを投入すると、AI が数千の人格を持つエージェントを生成し、エージェント同士が相互作用することで未来の社会・市場の動きをシミュレートします。 公式の説明では「A Simple and Universal Swarm Intelligence Engine, Predicting Anything（簡潔で汎用的な群体知能エンジン、万物を予測）」とされています。 仕組み MiroFish の動作は以下のステップで構成されます。 シード情報の抽出 — ニュース速報、政策草案、金融シグナルなどの現実世界のデータを取り込む デジタルワールドの構築 — 取り込んだ情報から高忠実度な並行デジタル世界を自動構築 エージェントの生成 — 独立した人格、長期記憶、行動ロジックを持つ数千〜数万のエージェントを生成 社会進化シミュレーション — エージェント同士が自由に相互作用し、社会的進化を遂げる 変数注入と予測 — ユーザーが動的に変数を注入し、未来がどう展開するかの精密なシミュレーションを実行 想定される活用シナリオ 金融意思決定支援 — 市場動向の予測と投資判断 政策・世論予測 — 政策変更がもたらす社会的影響の分析 PR 危機シミュレーション — 企業の危機管理対応の事前検証 マーケティング戦略テスト — キャンペーン効果の事前予測 ストーリー・フィクション推演 — 物語の展開シミュレーション 学術研究支援 — 社会科学的仮説の検証 Vibe Coding で10日間 注目すべきは、MiroFish が Claude Code などの AI コーディングツールを活用した「Vibe Coding」で開発されたという点です。Vibe Coding とは、AI エージェントと対話しながら直感的にコードを生成していく開発手法で、従来の開発と比較して大幅な時間短縮が可能です。 ...

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 と 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 形式に対応 コンプライアンス上の懸念 技術的には可能だが、プラットフォームの利用規約やコンプライアンスの問題は無視できない。 ...

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 の改善に時間を費やすより、コードベース自体を改善すべきということだ： ...