Agent

JS エンジニア・CTO として活動する hiroppy (@about_hiroppy) 氏が、James Shore のブログ記事「You Need AI That Reduces Maintenance Costs」を紹介するツイートを投稿した。AI エージェントによってコード生産性が向上しても、保守コストが同率で削減されなければ長期的には逆効果になるという主張だ。 ツイートの要点 hiroppy 氏は次のようにまとめている。 agent の導入でコード生産性が2倍になっても、保守コストが半分にならないと長期的には逆効果になるとのこと。AI 生成コードの保守コストが増加すると、5ヶ月程度で生産性向上分が消滅し、最終的には AI 未導入時より低い状態に陥る可能性があり、AI 活用では「速度向上率 × 保守コスト削減率 = 1」を満たすことが不可欠。 James Shore の保守コストモデル Shore は開発者 50 人を想定した試算として、次のような保守コストの見積もりを提示している。 期間 保守作業の目安 初年度 1ヶ月の開発につき 10日間 の保守 翌年以降 毎年 5日間 の保守 このモデルでは、保守コストを削減しないまま開発を続けると約 2.5 年後にチームの生産性の 50% 以上が保守に費やされる状態に達する。 AI 導入が裏目に出るシナリオ 仮に AI によって開発速度が 2倍 になっても、AI 生成コードが読みにくく保守コストが同じく 2倍 になってしまった場合を考える。 次の月の保守コストは 4倍 になる 5ヶ月後には生産性向上分が消滅する それ以降は AI 未導入時より低い状態に陥る Shore は、短期的な速度向上が保守コストの累積的な増加を生み、長期的な開発負債につながる危険性を警告している。 成功の条件：速度向上率 = 保守コスト削減率 Shore が指摘する根本的な条件は、AI が生産性を向上させた割合と同じ率で保守コストを削減することだ。 ...

複数の AI コーディングエージェントを使い分けるのは手間がかかる。その課題を解決するのが oh-my-openagent（omo） だ。Claude Code・OpenAI Codex・Gemini CLI といった主要エージェントを一元管理し、タスクに応じて最適なモデルへ自動ルーティングするオープンソースのハーネスで、GitHub スター数は 5.7 万超（2026 年 5 月時点）に達している。 oh-my-openagent とは oh-my-openagent は、もともと oh-my-opencode という名称で 2025 年 12 月に登場し、その後マルチエージェント対応を強化するかたちでリブランドされたツールだ。 作者: code-yeongyu 言語: TypeScript ライセンス: SUL-1.0 公式サイト: ohmyopenagent.com キャッチフレーズは「the best agent harness」。単一のエージェントに何でも任せるのではなく、専門化されたエージェント群がタスクを分担し、並列実行することで開発速度と品質を両立させる設計思想を持つ。 対応エージェントとプロバイダー oh-my-openagent は以下のエージェント・モデルプロバイダーに対応している。 プロバイダー 主なモデル Anthropic Claude Code（claude-opus-4-6 / 4-7 等） OpenAI Codex、GPT-5.5 Google Gemini CLI GitHub Copilot その他 Kimi K2、DeepSeek V4 等 インストール時に利用中のサブスクリプションプラン（Claude Pro/Max、ChatGPT Plus など）を選択することで、利用可能なプロバイダーのみを有効化できる。 主要機能 マルチモデルオーケストレーション タスクの種類ごとに最適なモデルを自動選択する「カテゴリベースのモデル割り当て」が核心機能だ。 visual-engineering（フロントエンド・UI 実装）→ Gemini ultrabrain（高難度なアーキテクチャ設計）→ Claude Opus 4.7 artistry（クリエイティブな文章生成）→ GPT-5.5 deep（深い推論・リサーチ）→ Claude Opus / Kimi K2 コスト最適化の観点から、大量ファイル生成のような作業は DeepSeek V4-Flash などの安価なモデルに自動振り分けされる。 ...

AIを使ったソフトウェア開発が急速に普及する中、「バイブコーディング」と「エージェンティックエンジニアリング」という2つのアプローチの境界線が曖昧になりつつある。Simon Willisonがこの問題を鋭く考察した記事が話題を呼んでいる。 バイブコーディングとエージェンティックエンジニアリングとは AI開発の文脈で、2種類のアプローチが対比されることが多い。 バイブコーディング（Vibe Coding） コードを深く読み込まず、AIの出力をそのまま使う開発スタイル。主に個人プロジェクトや試作品向けとされてきた。コードの内容を理解しなくても動くものが作れる、いわば「感覚」で進める手法だ。 エージェンティックエンジニアリング（Agentic Engineering） AIを強力なツールとして活用しつつ、プロのエンジニアが責任を持ってコードをレビューし、本番環境に耐えうるシステムを構築するアプローチ。品質・セキュリティ・保守性への意識が高い。 以前は「バイブコーディング＝個人・試作」「エージェンティックエンジニアリング＝本番」と明確に区別できた。しかし、AIの性能向上により、その境界線が揺らいでいる。 「もうコードを一行ずつ読まなくなった」という告白 Simon Willisonは自身の経験として、本番向けのコードでさえ、AIが書いたものを一行ずつレビューしなくなってきていると率直に認めている。 Willisonはこう述べる。Claude Codeに「JSON APIエンドポイントを作って」と頼めば、正しく実装してくれる——それはもう分かっている、と。 これは、大企業で別チームが開発した機能を、中身をほとんど確認せずそのまま使う感覚に近い。AIをある種のブラックボックスとして扱い始めているということを意味する。 人間のチームとの違いは「責任」にある。別チームの開発物には担当者がいて、問題が起きれば責任を取る人間が存在する。しかしAIには責任を取る能力がない。この非対称性が、Willisonに居心地の悪さを感じさせる根本的な理由だ。 AIの信頼が油断を生む 問題はさらに深い。AIが問題なくコードを書き続けることで「このAIは信頼できる」という過信が生まれる。そしていつか、本当は慎重であるべき場面でAIを過信して失敗するリスクが高まっていく。 また、AIの普及でソフトウェアの品質評価基準そのものも変化している。 従来: 充実したテストスイート、丁寧なドキュメント → 高品質の証明 現在: AIを使えばテストもドキュメントも数十分で完璧に揃えられる 見た目の完成度はもはや品質の指標にならない。代わりに価値を持ち始めたのは「実際に誰かが数週間・数ヶ月にわたって日常的に使っている」という実績だ。 開発プロセスの重心がシフトする @iwashi86 の整理によれば、AIによってコーディング速度が10倍（Willlison の元記事では「1日200行→2000行」）に跳ね上がったことで、従来のソフトウェア開発プロセス全体に変化が生じている。 コードを書くコストが劇的に下がったことで、失敗を恐れずに大胆なアーキテクチャ変更や仕様変更を試せるようになった。以前は実装コストが高すぎて試せなかったアイデアを、気軽にプロトタイプできる環境が整いつつある。 これはボトルネックを「実装」から「設計・判断・文脈理解」へとシフトさせることを意味する。 ソフトウェアエンジニアという職業の未来 Willisonは、AIが自動でコードを書く時代になってもソフトウェアエンジニアという職業は脅かされないと考えている。 その理由はシンプルだ：ソフトウェア開発はそもそも非常に困難な作業だから。AIはプロのエンジニアが持つ経験・判断力・文脈理解を増幅する道具にすぎない。AIを使いこなすためにこそ、深い専門知識が必要になる。 そして最終的には、企業も個人も「素人がAIで自作したシステム」より「プロがAIを駆使して作り上げた、実績のある製品」に対してお金を払いたいはずだ、とWillisonは結論づける。 まとめ Simon Willisonの考察は、AI開発ツールの急速な進化がエンジニアの「当たり前」を静かに書き換えていることを示唆している。 バイブコーディングとエージェンティックエンジニアリングの境界は、AIの性能向上とともに溶けつつある AIへの依存は「責任の所在」という根本的な問題を内包している ソフトウェアの品質指標は「見た目の完成度」から「実績・継続使用」へ移行しつつある 開発ボトルネックは「実装」から「設計・判断」へシフトしている それでもプロのエンジニアの価値はなくならない — AIはあくまで増幅器だ 元記事: Vibe Coding and Agentic Engineering Are Getting Closer Than I’d Like ツイート: @iwashi86

Anthropic のエンジニアとされる人物が Claude Code を使って Polymarket（予測市場プラットフォーム）向けの取引 bot を構築し、$200（約3万円）を $14,300（約200万円）に成長させたという事例が話題を集めている。ただし本人の公的な確認は取れておらず、複数の紹介ツイートも「伝えられるところによると」という留保を付けている点は注意が必要だ。 単純に取引回数を増やすのではなく、「勝てる場面だけを選ぶ」判断を AI に委ねるという設計思想が注目ポイントだ。 Polymarket とは Polymarket は分散型の予測市場プラットフォームで、政治・経済・スポーツなど様々なイベントの結果に対してポジションを取れる。各イベントの結果確率を市場参加者が売買することで価格が形成される仕組みになっている。 bot のアーキテクチャ このシステムは Claude Code をベースに、以下の3つの機能を組み合わせて動作する。 1. 大規模な取引データ分析 8,600万件の取引データを AI で分析 過去のパターンから「どういう取引が利益を出しやすいか」を学習 2. ウォレットランキング Polymarket の 14,000 以上のウォレットを数分でスキャン 各ウォレットの勝率・利益率を算出し、ランキング化 高勝率ウォレット（クジラ）が動いたタイミングを検出する 3. 厳選した取引実行 1日あたりわずか 10 回のみ取引を実行 勝率の高いクジラが動いた相乗りポジション、かつクジラより早く Exit（手仕舞い） 高確率の取引だけに絞ることでドローダウンを最小化 設計思想：「勝てる場面だけ選ぶ」 このシステムが興味深いのは、取引頻度ではなく取引品質を最大化している点だ。 多くのアルゴリズムトレードは「できるだけ多くの機会を捉える」方向に走りがちだが、このボットは逆の方針を選んでいる。 力技で数をこなす → 採用しない 「勝てる場面だけ選ぶ」判断を AI に任せる → 採用 1日10回という制約は、シグナルの質を落とさないための意図的な設計といえる。 Claude Code + Skills + MCP の連携 このような bot を実際に構築するには、Claude Code 単体ではなく、Skills や MCP（Model Context Protocol） を組み合わせた拡張が必要になる。Claude Code だけでは外部 API への接続や大規模データパイプラインを扱いきれないためだ。 ...

中国在住のあるユーザーが、Claude Code を「従業員」として使い、数十の Instagram アカウントを 24 時間体制で自動管理することで月 3 万ドル超を稼いでいるという事例が SNS で注目を集めている。AI を使った収益化が「すでにゲームのルール」になりつつある現状を、この事例から読み解く。 Claude Code による Instagram 自動管理で月 3 万ドル超 AI インフルエンス・オペレーターを名乗る @Jouhatsu_ai が X（旧 Twitter）で紹介したこの事例では、Claude Code が以下の作業を自律的にこなしている。 数十の Instagram アカウントを 24 時間運用: 投稿スケジュール管理、コンテンツ生成、エンゲージメント対応 トレンドリサーチを常時実施: バズっている数百のアカウントを継続的にモニタリングし、流行を把握 退屈な反復作業を全自動化: ユーザー本人は実務から解放され、戦略立案やチェックに集中できる 本人は「AI にすべての面倒な作業を任せ、自分は一日中のんびりできる」と話しており、Claude Code が文字通り自律エージェントとして機能している様子が伝わる。 英語圏では月 1.5 万〜4.2 万ドルの受託案件も @Jouhatsu_ai の引用ツイートによれば、英語圏の Claude Code ヘビーユーザーはこうした AI 自動化システムを構築・運用することで、クライアントから 月 1 万 5,500〜4 万 2,000 ドル を請求しているという。 さらに「Anthropic がこのやり方を 30 分の公式コンテンツでほぼすべて説明している」とも言及しており、公式ドキュメントや事例を参照すれば再現性のある手法として学べることを示唆している。 Claude Code が自律エージェントとして機能する理由 Claude Code がこうした自動化ビジネスに適している背景には、いくつかの技術的特性がある。 長期タスクの継続実行 Claude Code はコマンドラインから起動し、ファイル操作・Web 検索・API 呼び出しなどを連続して実行できる。単発の質問応答に留まらず、複数ステップにわたる業務フローを自律的にこなす。 ...

千寻（@Crypto_QianXun）さんが2026年4月のポストで紹介した「Claude + YouTube Shorts = 自動収益化」という手法が注目を集めている。カメラなし・編集なし・顔出しなし でバイラルショート動画を量産するアプローチだ。 この記事では、そのコンセプトをもとに、Claude を使った YouTube Shorts コンテンツ自動生成のフローと実践的なプロンプト例・Python コードを解説する。 YouTube Shorts アルゴリズムが評価する要素 — 顔出しなしでも収益化できる理由 YouTube Shorts のアルゴリズムは 視聴継続率・エンゲージメント をコンテンツ品質の代理指標として評価する。次の3点が鍵になる。 フック（冒頭3秒） で視聴者を引き込めるか 情報密度 が高く最後まで見られるか 感情を動かす テキスト・ナレーションがあるか これらは人間が画面に映らなくても Claude が生成したスクリプトで十分に実現できる。AI 音声と AI 生成画像/映像を組み合わせれば、顔出し不要のチャンネルが成立する。 Claude を使ったコンテンツ生成フロー Claude が担うのは最初のスクリプト生成だが、これがコンテンツ全体の品質を左右する最重要ステップだ。 Claude でバイラル Shorts スクリプトを生成するプロンプトの型 1. フック特化型プロンプト 1 2 3 4 5 6 7 8 9 10 11 あなたは YouTube Shorts のバイラル専門家です。 トピック：[テーマ] 以下の構成で60秒のスクリプトを書いてください： - 冒頭3秒：視聴者が思わず止まる衝撃的な問いかけ or 事実 - 本編45秒：テンポよく箇条書きで展開 - ラスト12秒：CTA（コメント誘導 or 保存促進） 制約： - 一文は短く（15文字以内） - 数字を多用する（例：「94%の人が知らない」） - 感情語を入れる（驚き・不安・希望） 2. ジャンル×バイラル要素の組み合わせ型 バイラルになりやすいジャンルとその鉄板フレーズを Claude にコンテキストとして渡してスクリプトを生成させる： ...

AI ターミナルとして知られる Warp が 2026 年 4 月 28 日にクライアントコードのオープンソース化を発表しました。発表からわずか 1 日あまりで GitHub Star が 34,000 を突破し、本記事執筆時点（2026-04-30）では 45,000 Star 超という勢いで成長しています。 Warp は単なるターミナルから、開発者と AI エージェントが協働する Agentic Development Environment（ADE） へと進化しています。本記事ではオープンソース化の概要、ライセンス構成、内蔵エージェントと外部 CLI エージェント連携、そして OpenAI が「設立スポンサー」として参加した意味を整理します。 TL;DR Warp クライアント（Rust 製）が warpdotdev/warp でオープンソース化 ライセンスは デュアル: UI フレームワーク（warpui_core / warpui クレート）が MIT、それ以外が AGPL v3 OpenAI が設立スポンサー。新しい Agent 駆動の管理ワークフローは GPT モデルで動作 内蔵コーディングエージェントに加え、Claude Code / Codex / Gemini CLI などの外部 CLI エージェントを呼び出せる クラウドエージェント基盤 Oz が Issue トリアージから Spec 作成・実装・PR レビューまでを担う Warp とは何か — Agentic Development Environment（ADE） Warp は当初、macOS 向けに登場した Rust 製の高速・モダンなターミナルです。現在は Linux にも対応しており、リッチな UI、ブロックベースの履歴、AI コマンド補完を特徴としています。 ...

RAGの長年の課題である「回答の網羅性の欠如」を、ベクトルDBを使わずに解決しようとする論文が登場した。2026年4月16日にarXivに公開された論文「Don’t Retrieve, Navigate」は、Corpus2Skill という新手法を提案している。文書コーパスを階層的スキルディレクトリへ事前変換し、LLMエージェントがナビゲートして回答を構築するアプローチだ。 従来のRAGが抱える課題 RAG（Retrieval-Augmented Generation）はこの数年で大きく進化し、多くの問題が解決されてきた。しかし「AIの回答が網羅的でない」という問題は依然として未解決のままだ。 従来のベクトル検索ベースのRAGでは、クエリに類似したチャンクをいくつか取得して回答を生成する。この方式の弱点は以下の通りだ。 クエリ表現に引きずられ、関連する別の観点の文書を見落とす チャンク間の文脈的なつながりが断ち切られる 広範なトピックをカバーする質問への回答が部分的になりがち Corpus2Skillのアプローチ：「検索するな、ナビゲートせよ」 Corpus2Skillは発想を根本から変える。ベクトル検索で文書を「取ってくる」のではなく、人間が目次や索引を辿るように、エージェントがコーパスの階層構造を「ナビゲートする」。 オフラインのコンパイルパイプライン まず事前処理として、文書コーパスを階層的スキルディレクトリへ変換する。 反復クラスタリング — 全文書をk-meansなどでグループ化する LLM生成サマリー — 各クラスタの内容をLLMが要約する 階層化 — クラスタをさらに上位概念でまとめ、ピラミッド構造を構築する スキルファイルツリーの実体化 — 結果を SKILL.md / INDEX.md の形式でファイルシステムに保存する この処理はオフラインで行われるため、推論時の遅延には影響しない。 推論時のナビゲーション 質問が来たとき、LLMエージェントは次の手順で回答を構築する。 コーパス全体の俯瞰図（ルートサマリー）を受け取る 質問に関連する上位ブランチを選択し、段階的に下位サマリーへ降下する 目的のノードに到達したら、文書IDを使って完全な文書を取得する 必要に応じてバックトラックし、別のブランチも探索する この探索パスが明示的に推論されるため、なぜその文書が取得されたかを追跡できるという副次的なメリットもある。 ベクトルDBが不要になる理由 従来のRAGではベクトルDB（Pinecone, Weaviate, Chromaなど）が必須だった。Corpus2Skillでは、スキルファイルツリーがその役割を置き換える。 項目 従来のRAG Corpus2Skill インデックス形式 ベクトルDB 階層ファイルツリー 検索方式 類似度検索 エージェントによるナビゲーション インフラ依存 ベクトルDBが必要 ファイルシステムのみ スケーラビリティ O(N) O(log N) 探索パスの透明性 低い 高い（明示的に推論） 文書数が10万件でも階層深度はO(log N)に収まるため、大規模コーパスへのスケーラビリティが高い点も特長だ。 実験結果 WixQAベンチマーク Wix社の企業向け顧客サポートを対象とするWixQAベンチマークで評価した。比較対象は以下のベースラインだ。 Dense Retrieval（密集検索）: 従来のベクトル検索RAG RAPTOR: 階層的サマリーを使った検索手法 Agent RAG: エージェントが検索を制御する手法 Corpus2Skillは全品質指標でこれらすべてを上回った。 ...

Hermes Agent は Nous Research が開発した自己進化型 AI エージェントで、Telegram・Discord・Slack から操作でき、使うほどユーザー固有のスキルとメモリが蓄積される。本記事ではインストールから Telegram ゲートウェイ設定、OpenClaw からの移行手順まで解説する。 Hermes Agent とは NousResearch/hermes-agent（GitHub 13.7万⭐）は、Nous Research が開発した自己進化型 AI エージェントだ。キャッチフレーズは「The agent that grows with you」— 使うほど自分専用に成長していく。 OpenClaw ユーザーからの移行を想定した hermes claw migrate コマンドが用意されており、設定・メモリ・スキル・API キーを丸ごとインポートできる。 主な特徴 使うほど成長する学習ループ Hermes の最大の特徴は、フィードバックが自分のデータ内で完結する閉じた学習ループにある。 複雑なタスクをこなすたびにスキルを自動生成 過去の会話を FTS5 全文検索 + LLM 要約でクロスセッション想起 ユーザーを深く理解するモデルを会話ごとに更新 自分が作ったスキルは /skills list --source local で一覧確認できる。スキルが積み上がっていく感覚が、個人専用のナレッジベース形成につながる。 Telegram ゲートウェイ Telegram 以外にも Discord・Slack・WhatsApp・Signal・Email に対応。VPS 上で 24 時間稼働させ、外出先からスマートフォンで操作するという使い方が現実的になっている。 モデルを自由に切り替える /model コマンドで会話中でも即時切替できる。用途に応じた使い分けの例: 用途 モデル例 日常会話 Ollama Cloud（ほぼ無料） 中程度の開発作業 Sonnet 複雑なタスク Claude Code / Codex 対応プロバイダーは Nous Portal・OpenRouter（200+ モデル）・NVIDIA NIM・OpenAI・Hugging Face など多数。コードを変更せずプロバイダーを切り替えられる。 ...

2026年4月28日、Rust 製 AI ターミナル Warp がそのクライアントコードを GitHub 上でオープンソース化した。公開から1日強で GitHub スターが 31,900 件を超え、サーバーが過負荷になるほどの反響を呼んだ。 Warp とは何か Warp は「ターミナルから生まれたエージェンティック開発環境」を標榜するツールだ。Rust で書かれており、AI によるコマンド補完・エラー診断・エージェント実行を統合した AI 統合ターミナルとして、700,000 人以上のアクティブ開発者が利用している。 公開リポジトリ: github.com/warpdotdev/warp（AGPL-3.0 ライセンス） Oz — AI エージェントのオーケストレーション基盤 Warp のオープンソース化で最も注目すべきは、コードの公開そのものより、背後にある開発協働モデルだ。Warp は Oz と呼ばれる AI エージェント・オーケストレーションプラットフォームを導入しており、コントリビューションのワークフロー自体を AI エージェントが担う設計になっている。 Oz エージェントが自動で行う作業: コードの実装・修正 テストの実行と検証 コードレビュー 技術ドキュメントの生成 build.warp.dev では、数百体の AI エージェントがリアルタイムでコードを書き、バグを修正し、Issue を処理する様子をライブで見ることができる。 Warp 公式ブログによれば、多様なアイデアを持つコントリビューターと、構造化されたプロセスを持つ Oz エージェントと、豊富なコンテキストと自己改善ループが組み合わさることで、社内だけでは作れない「魔法のようなプロダクト」が生まれると言う。 AI 時代の OSS 開発における人間の役割 このモデルが示唆するのは、オープンソース開発における人間の役割の根本的な変化だ。従来は「熱意ある開発者が週末に肝コードを書く」ことでオープンソースは成り立っていた。Warp の目指す姿はこうだ: アイデアを提案し、品質を管理し、最終方向を決めるのが人間。 コーディング・テスト・ドキュメント生成は Oz エージェントが担う。 Oz は OpenAI がファウンディングスポンサーを務めるプラットフォームで、デフォルトで OpenAI のモデルを利用する。他のコーディングエージェントの利用も自由だが、Oz を使うことで検証ループや必要なスキルが最初から組み込まれているメリットがある。 ビジネスモデル面では、ターミナルクライアントは AGPL-3.0 でオープンソースだが、Oz やサーバーコンポーネントはプロプライエタリで、月額 $12 の Pro プランを中心に収益化している。 ...