Agent

Anthropic が開発中の常駐型AIエージェント「Conway」のリーク情報が話題になっています。従来のチャットベースのやり取りとは異なり、24時間バックグラウンドで稼働し続けます。いわば「AI従業員」として機能する次世代エージェント環境です。 Conway の概要 Conway は、Anthropic が内部テスト中の常駐型（Always-On）AIエージェント環境です。TestingCatalog が 2026年4月にスクープし、その存在が明らかになりました。ユーザーのシステムやブラウザ上にサイドバーとして常駐し、ユーザーが操作していなくても裏側で継続的にタスクを実行できます。 Claude がこれまで提供してきた「対話型アシスタント」から、「自律的に業務を遂行するエージェント」への進化を示すプロダクトと位置づけられています。 主な特徴 Always-On（常時稼働） Conway の最大の特徴は、ユーザーが待機していなくてもバックグラウンドで常に稼働し続ける点です。従来の Claude のようにプロンプトを送って応答を待つワンショット型ではなく、永続的なプロセスとして動作します。 Webhook 連携 外部アプリケーションからの通知をトリガーに自動実行が可能です。Webhook セクションでは、外部サービスがインスタンスを起動するためのパブリック URL が提供されます。サービスレベルのトグルでトリガーのオン・オフを制御できます。例えば以下のようなユースケースが考えられます: メール受信時に自動で要約・分類 GitHub の Issue 作成をトリガーに調査を開始 Slack のメンション通知をきっかけに対応を自動化 ブラウザ操作と Claude Code 連携 Conway は Chrome ブラウザの操作が可能で、Web上のマルチステップタスクを自律的に処理できます。また、Claude Code（リーク情報では「Epitaxy」というコードネームも言及）との連携も備えており、コーディングタスクも自動化の範囲に含まれます。 独自拡張規格「.cnw」 Anthropic は Extensions エリアを準備しており、ユーザーがカスタムツール、UIタブ、コンテキストハンドラをインストールできるようになります。.cnw.zip ファイルのドロップに対応した独自の拡張パッケージ規格が用意されており、サードパーティのアドオンフレームワークとしての展開が見込まれます。 技術的なアーキテクチャ リーク情報から判明している Conway の構成要素は以下の通りです: コンポーネント 説明 独立 UI インスタンス サイドバー形式で常駐 Webhook エンドポイント 外部サービスからのイベント受信 ブラウザ操作 Chrome を通じた Web 操作 Claude Code 連携 コーディングタスクの自動実行 通知システム タスク完了等の通知送信 Extensions .cnw 形式のプラグイン機構 既存ツールとの違い 現在の Claude Desktop や Claude Code は、いずれもユーザーの入力をトリガーとして動作する対話型ツールです。Conway はこれらとは異なり、外部からのイベント（通知やスケジュール）をトリガーに自律的に動くエージェントとして位置づけられます。 ...

Onyx（旧 Danswer）は、社内のドキュメント・アプリ・人材をまとめて繋ぎ、どんな LLM とも連携できるオープンソースの AI プラットフォームです。Community Edition（CE）は MIT ライセンスで完全無料。セルフホストできるため、データを外部に出さずに AI チャットや RAG、エージェント機能を利用できます。 Onyx とは Onyx は企業向け AI アシスタント＆検索プラットフォームです。Slack、GitHub、Confluence、Google Drive など 50 以上のコネクタで社内ナレッジを統合し、自然言語で質問するだけで必要な情報を引き出せます。 GitHub リポジトリ（onyx-dot-app/onyx）のスター数は 22,000 超で、活発に開発が続いています。 主な機能 チャット＆RAG ハイブリッド検索: ベクトル検索とキーワード検索を組み合わせた高精度な情報検索 Agentic RAG: AI エージェントが検索クエリの生成・評価・再検索を自律的に繰り返し、複数ステップで情報を収集 Deep Research: 多段階のリサーチフローで詳細なレポートを生成 エージェント＆ツール カスタムエージェント: 固有の指示・知識・アクションを持つ AI エージェントを構築可能 Web 検索: リアルタイムの Web 情報を取得 コード実行: サンドボックス内でコードを実行し、データ分析やグラフ描画が可能 画像生成: プロンプトに基づいた画像生成 音声モード: テキスト読み上げ＆音声入力に対応 コネクタ（50 以上） Slack、GitHub、Confluence、Notion、Google Drive、Jira、Linear など主要サービスと連携。MCP（Model Context Protocol）経由のカスタムコネクタにも対応しています。 エディション比較 項目 Community Edition (CE) Enterprise Edition (EE) ライセンス MIT（無料） 商用ライセンス チャット・RAG・エージェント ✅ ✅ SSO（OIDC / SAML） — ✅ エアギャップ環境 — ✅ サポート コミュニティ 専用サポート Cloud 版も提供されており、セルフホストなしで試用できます。ビジネスプランは 1 ユーザーあたり月額 $16〜。 ...

以前の記事で紹介した AI 予測エンジン「MiroFish」が、公開から約3週間で GitHub Star 4.7万超にまで急成長しています。本記事では、その後の動向とコミュニティの広がりを追います。 3週間での急成長 3月10日時点で約11,000だった Star 数は、3月末時点で 47,000以上 に到達しました。約3週間で4倍以上の成長です。 GitHub Trending で世界1位を獲得した直後の注目度に加え、盛大グループ創業者・陳天橋氏からの3,000万元（約6億円）の即決投資が報じられたことで、AI エージェント分野への関心の高さを示すプロジェクトとして広く認知されました。 コミュニティの広がり MiroFish のオープンソース公開後、コミュニティによる派生プロジェクトが活発に展開されています。 オフライン版フォーク MiroFish-Offline は、Neo4j と Ollama を使ったローカル完結型のフォークです。クラウド API への依存を排除し、プライベートな環境でマルチエージェントシミュレーションを実行できます。企業内のデータを外部に出せないケースなどでの活用が想定されます。 デモサイト 公式デモサイトが公開されており、ブラウザ上で MiroFish の予測プロセスを体験できます。 多言語対応フォーク 英語版 README の整備や、コミュニティによる英語フォークも複数登場し、中国語圏以外への普及が進んでいます。 群体知能アプローチへの注目 MiroFish が採用する群体知能（Swarm Intelligence）アプローチは、従来の AI 予測と異なる特徴を持っています。 従来の予測モデルは統計的パターンや単一モデルの推論に依存しています。一方、MiroFish は数千のエージェントによる社会的シミュレーションを通じて予測を行います。エージェント同士が議論し、説得し、立場を変えるプロセスを経ることで、集団行動や社会的伝播といった創発的パターンを予測に反映できます。 このアプローチは、特に世論形成や市場心理のような「人間の集団行動」が結果を左右する領域で有効性が期待されています。 今後の注目点 MiroFish の急成長は印象的ですが、今後の展開にはいくつかの注目点があります。 予測精度の検証: 実際のイベントに対する予測精度がどの程度か、体系的な評価はまだ少ない スケーラビリティ: OASIS エンジンは100万エージェント対応を謳うが、実運用での性能と品質のバランス LLM コスト: 数千エージェントの同時推論に必要な API コストの最適化 ユースケースの深化: 汎用的な「万物を予測」から、特定領域での実用性の実証 まとめ MiroFish は、公開からわずか3週間で GitHub Star 4.7万超という驚異的な成長を遂げました。オフライン版フォークやデモサイトの登場など、コミュニティの展開も活発です。 群体知能によるマルチエージェント予測というコンセプトは多くの開発者の関心を集めていますが、実用面での検証はこれからです。今後の予測精度の実証やユースケースの深化に注目していきたいプロジェクトです。 参考リンク MiroFish GitHub リポジトリ MiroFish-Offline (ローカル版フォーク) MiroFish: The AI Swarm Engine That Simulates the Future 前回の記事: MiroFish — 20歳の学生が10日間の Vibe Coding で作った AI 未来予測エンジン

「toC」でも「toB」でもない。AIエージェントそのものがお客さんになる——「toA」という新しい市場が急速に立ち上がっています。paji氏（@paji_a）がリサーチした200超のサービスから見えてきた、この新市場の構造を紹介します。 Claudeヤバい、1日で”toA”デモできた… https://t.co/olgPwJ1SIr pic.twitter.com/P46txbWVHh — paji.eth (@paji_a) March 29, 2026 なぜ「toA」が生まれたのか 2026年はAIエージェントの普及が一段と進む年です。Claude Cowork / Dispatch、Manus、OpenClawなど、年明けからAIエージェントに関するリリースが途切れることなく続いています。 ここで起きている変化は明確です。エージェントを作るツールに加え、エージェントが実際に使う周辺サービスが急増し始めました。 メールアドレスの発行、長期記憶の保存、Webサイトの操作手順を教えてくれるサービス、仕事を受注して報酬を受け取るマーケットプレイス。主な導入者は人間の開発者や企業ですが、用途はAIエージェントの運用インフラです。 「人間向け」には成熟していたデジタルサービスの領域が、「AIエージェント向け」には別の問題として再出現している——これが「toA」市場の本質です。 エージェントの「5つの生存条件」 200を超えるtoAサービスを分類すると、ひとつの構造が浮かび上がります。エージェントが自律的に動くには、以下の5つの条件が必要です。 条件 説明 代表カテゴリ 「私は誰か」 存在証明 メール、ID、SNS 「安全に作業できる場所」 実行環境 サンドボックス、GPU推論 「外の世界を操作する手段」 ブラウザ・外部接続 Web自動操作、プロキシ、OAuth 「経験を蓄積する力」 記憶 長期記憶、コンテキスト管理 「対価を受け取る仕組み」 経済活動 マーケットプレイス、エスクロー、決済 この5つが揃って初めて、エージェントは自律的に仕事ができます。一つでも欠けると止まります。そして多くのサービスが、この5つのどれかを埋めるために生まれていました。 残りのカテゴリ（監視、ガードレール、音声、通信など）は、5つの基盤の上に乗る「運用・拡張レイヤー」として位置づけられます。 枯れた領域に次々と新種が生まれている メール — AgentMail 人間向けのメールサービスはGmailが圧倒的で、今さら新規参入する余地はなさそうに見えます。でも「AIエージェント専用のメール」となると話は別です。APIで即座にメールボックスが作れて、スレッド管理も添付解析も全部プログラムから操作できて、メールで届くOTP/2FA（ワンタイムパスワード/二要素認証）コードも取得できる。AgentMailはY Combinator出身で、600万ドル（約9億円）を調達しています。 記憶 — Mem0 人間はメモ帳やNotionに書き残すことで記憶を補強しますが、エージェントにはそもそもセッションをまたぐ記憶がありません。Mem0は会話からファクトを自動抽出して保存し、次のセッションで関連記憶を自動注入してくれます。人間のメモ帳のエージェント版です。 Webブラウジング — Agent Maps 人間はGoogle Mapsで店を探してクリックして予約しますが、エージェントは「ボタンがどこにあるか」を毎回スクリーンショットから推測しないといけない。Agent Mapsは主要サイトの操作手順をあらかじめ検証済みの「攻略本」としてエージェントに渡します。 外部ツール連携 — Composio 人間はSlackにログインしてメッセージを送りますが、エージェントはOAuth認証のフローを安定してさばくのが難しい。Composioは500以上のアプリ接続とOAuth処理を提供します。 「稼ぐエージェント」と「使うエージェント」 さらに踏み込んだ領域もあります。 HYRVE AIは、AIエージェントが「フリーランサー」として活動するマーケットプレイスです。48時間のエスクロー保護付きで、エージェントが別のエージェントを雇うこともできます。「エージェントが自律的に稼ぐ」というコンセプトは、この先どこかのプレイヤーが必ず大きく育てる領域です。 一方、Anonは、ログイン情報そのものではなく認証済みセッションをエージェントに安全に扱わせるサービスです。エージェントに「自分のアカウントで注文しておいて」と頼みたいけど、パスワードを直接渡すのは怖い。Anonはログイン済みの状態だけをエージェントに渡すので、エージェントは操作できるけどパスワード自体には触れられません。 「稼ぐエージェント」と「使うエージェント」。この両方のインフラが同時に立ち上がっているのが2026年の面白いところです。 toAの「エッジ」がプラットフォームになる AIの時代に本当に価値を持つのは、AIモデルそのものだけではなく、AIが「動く」ために必要な周辺インフラです。 存在証明、実行環境、操作手段、記憶、経済活動。これらのインフラを押さえたサービスが、AI時代の重要なプラットフォームになっていく。枯れ尽くしたデジタルサービスの「エッジ」にいるtoAサービス群に、大きなチャンスがあります。 新しいtoAサービスが今後どんなに増えても、「5つの生存条件」＋「運用・拡張」という二層構造の中のどこかに位置づけられるはずです。ここを押さえておくと、新サービスが出てきたときに「これはどの条件を埋めるものか」が即座に判断できます。 まとめ 「toA」は既存市場の延長ではなく、新しいカテゴリそのもの エージェントの自律動作には5つの生存条件（存在証明・実行環境・操作手段・記憶・経済活動）が必要 人間向けに成熟した領域が、エージェント向けに再発明されている 200超のサービスが既に存在し、この市場は急拡大中 詳細な200サービスのリストは、paji氏の記事「AIエージェント向けサービス200選」で確認できます。

AI がゴールドマン・サックスのアナリストと同等の財務モデルを作成できるようになった。Claude を活用した 12 のプロンプトで、年収 15 万ドル（約 2,200 万円）相当の投資銀行業務を代替できるという話題が SNS で広がっている。本記事では、その背景と実際の活用方法を解説する。 背景: ゴールドマン・サックスと Anthropic の提携 2026 年 2 月、ゴールドマン・サックスは Anthropic と提携し、Claude を活用した AI エージェントの開発を開始した。Anthropic のエンジニアがゴールドマン内部に常駐し、会計処理やコンプライアンス業務の自動化エージェントを共同開発している。 ゴールドマンは Claude のコーディング以外の能力、特に大量のデータやドキュメントを解析しながらルールと判断を適用する能力に驚いたと報じられている。同行は、AI を活用してプロセスを高速化し、将来の人員増加を抑制する効率化を見込んでいる。 12 の Claude プロンプトとは SNS で話題になっている「12 の Claude プロンプト」は、投資銀行やプライベートエクイティで使われる 47 の財務モデルを 12 の構造化プロンプトに集約したものだ。各プロンプトは以下の手法で構築されている: フェーズ分割: 段階的にモデルを構築 XML 構造: 入力データを明確にラベル付け 検証ステップ: 計算結果の整合性チェックを内蔵 不確実性フラグ: 推定値と確定値を区別 明示的な出力フォーマット: 投資委員会向けの形式 主要なプロンプトカテゴリ カテゴリ 内容 DCF（割引キャッシュフロー）バリュエーション WACC（加重平均資本コスト）計算、ターミナルバリュー算定、3 フェーズ構築 3 ステートメント財務モデル 損益計算書・貸借対照表・キャッシュフロー計算書の連動モデル、バランスチェック検証付き M&A 希薄化/増厚分析 買収のアクリーション/ディリューション分析 LBO（レバレッジド・バイアウト）モデル ソース & ユース、負債構造、キャッシュスイープ、IRR（内部収益率）/MoM（投資倍率）計算 類似企業比較分析 コンパラブルカンパニー分析、マルチプル算出 Claude の財務サービス機能 Anthropic は 2026 年に Claude の財務サービス向け機能を大幅に拡充した。 ...

Claude Code を単なるコーディングアシスタントではなく、バックエンド処理のオーケストレーターとして活用するアーキテクチャを考察する。Python Celery をタスクブローカーとして組み合わせるアプローチを紹介する。LLM が判断し、決定論的な処理（同じ入力に対して常に同じ結果を返す処理）を動的に Celery ワーカーへ委譲する仕組みが実現できる。 背景: 既存の Claude Code オーケストレーション 現在、Claude Code の並列実行やマルチエージェント構成には主に以下のパターンが使われている。 tmux + git worktree 最も普及しているパターン。複数の Claude Code CLI セッションを tmux で並列起動し、git worktree で各セッションの作業ディレクトリを分離する。 multi-agent-shogun — 将軍→家老→足軽の階層構造 claudio — worktree ベースの並列実行 MCP サーバーによる連携 MCP（Model Context Protocol）サーバーがタスクブローカーの役割を担い、ワーカーとなる Claude Code インスタンスにタスクを割り当てる。 claude-swarm — MCP サーバーベースのスウォーム制御 共通の特徴 これらはいずれも Claude Code 同士の連携 が主眼であり、LLM が LLM に指示を出す構造になっている。LLM を必要としない決定論的な処理（画像変換、データ集計、API 呼び出しなど）にも LLM のリソースを消費するため、コスト・速度・信頼性の面で非効率な場面がある。 提案: Claude Code + Celery アーキテクチャ 基本思想 Claude Code（LLM）は 判断と計画 に集中し、決定論的な処理は Celery ワーカーに委譲する。 ...

TL;DR 自律型トレーディングシステムで、投資目標の進捗に応じてリスクパラメータを動的に調整する機能を実装した。計算ロジックは正しく動いていたが、計算結果がエージェントのプロンプトに届いていなかった。プロンプト内の数値がプレーンテキストでハードコードされていたため、エージェントは常に保守的な固定値に従い続けていた。 背景 trader は日本株・ビットコインの自律型トレーディングシステムで、Claude をマルチエージェントとして使い、日次の投資提案を生成する。 システムには安全規約があり、エクスポージャー上限（60%）や現金比率下限（30%）などのリスクパラメータが定義されている。投資目標（goal）システムを導入し、目標への進捗ペースに応じてこれらのパラメータを動的に調整する機能を実装した。 何が起きたか 期待していた動作 1 2 3 goal 評価: behind（目標に遅れている） → AdjustmentProposal: exposure_limit=70%, cash_ratio_min=20% → エージェント: 「エクスポージャー70%以内、現金比率20%以上」で提案作成 実際の動作 1 2 3 goal 評価: behind（目標に遅れている） → AdjustmentProposal: exposure_limit=70%, cash_ratio_min=20% → エージェント: 「エクスポージャー60%以内、現金比率30%以上」で提案作成 ← 固定値のまま！ goal の評価は正しく行われ、propose_adjustment() は適切な調整値を返していた。しかしエージェントが参照するプロンプトには、値がハードコードされていた： 1 2 3 <!-- portfolio.md --> - 総エクスポージャー60%以内 - 現金比率30%以上を維持 一方、同じプロンプト内の max_position_pct（1取引あたりポジション上限）は既にテンプレート変数化されていた： ...

opencli-rs は、55以上の主要サイトに対応したRust製のCLIツールです。サイトごとにAPIやスクレイピング方法が異なる煩雑さを解消し、1つのコマンドで各プラットフォームの情報を取得できます。 opencli-rs とは opencli-rs は、元々TypeScriptで実装されていた OpenCLI をRustで完全に書き直したツールです。X (Twitter)、YouTube、Reddit、Hacker News、Bilibili、Zhihu、Xiaohongshu（小紅書）など多数のプラットフォームに対応しています。Chromeのログインセッションを再利用するため、APIキーなしでデータを取得できます。 出力形式はテーブル、JSON、YAML、CSV、Markdownに対応しており、用途に応じて使い分けが可能です。また、Electronベースのデスクトップアプリをコマンドラインから制御する機能も備えており、GUIアプリの操作をスクリプト化できます。 主な特徴 処理速度が最大12倍に向上 — TypeScript版と比較して大幅な高速化（例: Bilibili Hot の取得が20.1秒から1.66秒に） メモリ使用量を10分の1に削減 — 95-99MBから9-15MBへ シングルバイナリで動作 — わずか4.7MB、追加のランタイム不要でどの環境にも導入可能 インストール インストールスクリプトが用意されており、システムとアーキテクチャを自動検出してバイナリをダウンロードします。 1 curl -fsSL https://raw.githubusercontent.com/nashsu/opencli-rs/main/scripts/install.sh | sh Rustの開発環境がある場合はソースからビルドすることもできます。 1 2 3 git clone https://github.com/nashsu/opencli-rs.git cd opencli-rs cargo build --release AIエージェントとの連携 opencli-rs はAIエージェントとの連携を前提に設計されています。Claude Code や Cursor などに組み込むことで、「Hacker Newsのトップ記事を取得して要約する」「競合のX投稿を定期的にチェックする」といったWeb情報収集の自動化が可能です。 AIエージェント向けのスキルパッケージ opencli-rs-skill も提供されています。 1 npx skills add https://github.com/nashsu/opencli-rs-skill これにより、AIエージェントが AGENT.md や .cursorrules の設定を通じて利用可能なツールを自動的に検出し、自然言語でWebスクレイピングを実行できるようになります。 ...

AI エンジニアリングの中心概念が急速に変化している。2022年の「Prompt Engineering」から2025年の「Context Engineering」を経て、2026年は「Harness Engineering」の年になった。Anthropic、OpenAI、そして Martin Fowler まで、業界のキープレイヤーが揃ってこの概念を公式に取り上げている。 3つの時代: プロンプトからハーネスへ Prompt Engineering（2022〜） ChatGPT の登場とともに広まった最初のパラダイム。LLM に対してどんな言葉で指示するかが品質を左右する、という考え方だ。Few-shot、Chain-of-Thought、Role Prompting といったテクニックが次々と開発された。 焦点は「1回のリクエストにおける入力テキストの最適化」にあった。 Context Engineering（2025〜） 2025年中盤、Shopify CEO の Tobi Lutke が X への投稿をきっかけに「Context Engineering」という用語が急速に広まった。LangChain や Anthropic も相次いで解説記事を公開し、業界標準の概念として定着した。 Prompt Engineering が「何を言うか」に注目していたのに対し、Context Engineering は**「LLM に何を見せるか」を動的に制御するシステム**を設計する。RAG（Retrieval-Augmented Generation）、ツール呼び出し、メモリ管理など、LLM の入力コンテキスト全体をエンジニアリングの対象とする発想だ。 Harness Engineering（2026〜） 2026年に入り、AI エージェントの実用化が本格化するなかで、Context Engineering をさらに拡張した「Harness Engineering」が登場した。 Context Engineering が「LLM に何を見せるか」を扱うのに対し、Harness Engineering はエージェントの実行環境全体 —— 役割分担、フィードバックループ、品質検証、セッション管理まで含めた制御構造を設計する。 「ハーネス（harness）」は馬具の意味で、強力な馬（= AI モデル）を制御し、安定した成果を引き出すための仕組み全体を指す。 業界キープレイヤーの動き OpenAI: Codex チームの実践（2026年2月） OpenAI は2026年2月、公式ブログで「Harness engineering: leveraging Codex in an agent-first world」を公開した。 ...

「AI疲れ」という言葉が広がる中、Claude Code のハーネス機能（Skill, Agent, MCP, Memory）は不要であり、シンプルな CLI で十分だという主張が話題になっている。この議論の論点を整理し、実際の開発現場での実用性を考察する。 話題の発端 Kai Aoki 氏（@kaixaoki）が X で投稿した「AI疲れしてる各位に贈るアンサー」が注目を集めた（2026年3月時点で 531 いいね、462 ブックマーク、約9.8万表示）。 主張は以下の4点: ドキュメントが全て — コードや設定よりもドキュメントが最重要 Skill, Agent, MCP, Memory 全て不要 — CLI で解決可能 ハーネス独自機能は全て不要 — 物理マシン/VM で隔離せよ 賢いモデルがいずれ全てを解決する — 機能追加より待つべき さらに「特に Claude Code はハーネスを複雑化してロックインし、虚業を生み出しているので Evil」と結論づけている。 各論点の検討 ドキュメントが全て これは多くの開発者が同意できる主張だ。CLAUDE.md や README に適切な情報を書いておけば、AI エージェントは文脈を理解して適切に動作する。実際、Claude Code の公式ドキュメントでも「CLAUDE.md に何を書くか」が最も重要な設定項目として紹介されている。 ただし、ドキュメントだけでは解決しづらい課題もある。繰り返しのワークフロー自動化や、外部サービスとの連携は、仕組みとして定義した方が効率的なケースがある。 Skill/Agent/MCP/Memory は不要か シンプルな使い方なら不要というのは正しい。1ファイルのバグ修正やコードレビューに Skill や Agent は必要ない。 一方、以下のようなケースではこれらの機能が実用的な価値を持つ: Skill: 定型作業（ブログ記事作成、PR レビュー、デプロイ手順）を毎回説明する手間を省く Agent: 並列タスク実行（ファクトチェックと SEO 分析の同時実行など） MCP: 外部 API やデータベースへのアクセスを安全に管理する Memory: プロジェクト固有の慣習やユーザーの好みを会話をまたいで保持する 要は「必要な人には必要、不要な人には不要」という当たり前の結論になる。問題は、これらの機能がオプトインであるかどうかだ。Claude Code ではいずれも使わなければ存在しないのと同じであり、強制されるものではない。 ...