Llm

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、コードレビュー）にますます圧力がかかる。 ...

Claude Code はコーディング専用ツールと思われがちだが、実はコーディング以外の日常業務を半自動化する強力なツールとしても活用できる。みのるん氏（@minorun365）の Qiita 記事 から、その実践例を紹介する。 AI は「自動化ツール」ではなく「優秀な同僚」 Claude Code を使う上で重要なマインドセットは、AI を単なる自動化ツールではなく「一緒に仕事できる優秀な同僚」として捉えること。どんな作業でも「この作業、Claude Code に任せられないか？」と必ず考える習慣が、業務効率を大きく変える。 また「AI 活用＝やっつけ品質」という認識はもう過去の話で、適切に指示を出せば高品質なアウトプットが得られる。 プチ仕様駆動開発 Claude Code との作業では、以下の 4 つのドキュメントで「プチ仕様駆動開発」を行うのが効果的。 ドキュメント 用途 PLAN.md 音声入力で計画を記録 SPEC.md 仕様の壁打ち TODO.md タスク管理 KNOWLEDGE.md 学びとナレッジの蓄積 音声入力（Aqua Voice 等）で大まかな計画を PLAN.md に吹き込み、Claude Code に仕様化してもらうフローが実用的。 実践例: 経費精算を 5 分で終わらせる MoneyForward の CSV を Claude Code に渡して、以下を自動化する: CSV を解析して取引を分類 Gmail から領収書を自動検索 勘定科目を自動マッピング Markdown 形式で出力 手作業なら 30 分以上かかる経費精算が、5 分で完了する。 実践例: メール監視とリマインド 放置しがちなメールの監視を自動化する構成: EventBridge（定時起動） → AgentCore Runtime → Gmail API でメール抽出 → Slack に通知 重要なメールを見落とすリスクを、システムで解消する。 ...

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倍になった」話 だ。 ...

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 の中核となるワークフローパターンです: ...

AIエージェントに役職・組織図・予算・目標を与え、24時間自律的に会社を運営させる——そんなコンセプトのオープンソースプロジェクト「Paperclip」が公開され、注目を集めている。 Paperclip とは Paperclip は、複数の AI エージェントを「社員」として組織化し、会社として機能させるためのオーケストレーションプラットフォームだ。 “If OpenClaw is an employee, Paperclip is the company.” 個々の AI エージェントを個別に管理するのではなく、組織図・予算・ガバナンス・目標整合・タスク調整といった会社レベルのインフラを提供する。 GitHub: https://github.com/paperclipai/paperclip 公式サイト: https://paperclip.ing/ ライセンス: MIT 主な機能 エージェントの組織化 組織図（Org Chart）: 階層構造、役職、レポートラインを定義 目標整合（Goal Alignment）: 会社のミッションからプロジェクト目標、個別タスクまで文脈が伝播 マルチカンパニー対応: 1つのデプロイで複数の会社を完全分離して管理 対応エージェント Claude、OpenClaw、Codex、Cursor、Bash スクリプト、HTTP Webhook など、ハートビートシグナルを受信できる任意のランタイムと連携できる。 コスト管理 エージェントごとに月次予算を設定し、使用量80%で警告、100%で自動停止する。暴走的なトークン消費を防ぐ仕組みが組み込まれている。 ガバナンスと監査 人間による承認ゲート（採用・戦略変更時） 設定変更のバージョニングとロールバック 全ての会話・意思決定・ツール呼び出しの追跡ログ いつでもエージェントの一時停止・再割り当て・終了が可能 セットアップ 1 2 3 4 5 6 7 8 # クイックスタート npx paperclipai onboard --yes # 手動インストール git clone https://github.com/paperclipai/paperclip.git cd paperclip pnpm install pnpm dev API は http://localhost:3100 で起動し、組み込みの PostgreSQL データベースを使用する。要件は Node.js 20+ と pnpm 9.15+。 ...

Alibaba Cloud の Qwen チームが 2026 年 2 月にリリースした Qwen3.5-27B は、27B パラメータという中規模サイズながら上位モデルに匹敵する性能を発揮する密（dense）モデルです。メモリ効率に優れ、量子化を活用すれば個人の PC でも快適に動作するため「自分専用 AI」を構築するのに最適な選択肢として注目されています。 Qwen3.5-27B の主な特徴 アーキテクチャ Qwen3.5-27B は MoE（Mixture of Experts）ではなく、全パラメータが推論時に活性化される 密モデル（dense model） です。Gated Delta Networks と Feed Forward Networks を組み合わせた構造で、高い計算密度を実現しています。 パラメータ数: 27B（全パラメータ活性化） コンテキスト長: 262K トークン（最大 1M まで拡張可能） 対応言語: 201 言語 マルチモーダル: 視覚・言語の統合能力を搭載 ベンチマーク性能 27B というサイズにもかかわらず、主要ベンチマークで際立った成績を残しています。 ベンチマーク スコア MMLU-Pro 86.1% GPQA Diamond 85.5% SWE-bench Verified 72.4% LiveCodeBench 80.7% IFEval 95.0% HMMT（数学） 92.0% 特に SWE-bench Verified で 72.4% は GPT-5 mini と同等の数値であり、オープンウェイトの 27B 密モデルとしては驚異的な結果です。コーディング、数学、指示追従の各タスクで中規模モデルカテゴリをリードしています。 ...

Claude Code などの LLM エージェントを業務で使う際、最大のリスクは**ハルシネーション（幻覚）**です。プロンプトの改善ばかりが注目されがちですが、本当に必要なのは「仕組みで縛る」アプローチです。 きっかけとなった事故 ある開発者が実際に遭遇した事故が、この議論のきっかけです: which コマンドの結果だけで「未インストール」と診断されたが、コードは PATH 外のディレクトリを直接参照していた。ログを1行も読まずに断言。 LLM エージェントは自信に満ちた口調で誤った結論を出すことがあり、人間がそれを鵜呑みにしてしまうリスクがあります。 Anti-Hallucination Protocol の4つの柱 提唱されている Anti-Hallucination Protocol は、以下の4つのルールで構成されます: 1. 事実主張にはツール実行による検証を義務化 LLM が「〜がインストールされていない」「〜が原因です」と主張する場合、必ず対応するコマンドやツールを実行して裏付けを取ることを求めます。推測だけで結論を出すことを許容しません。 2. 禁止パターンの明示 以下の4つのパターンを明示的に禁止します: パターン 説明 推測診断 十分な証拠なしに原因を断定する 確認なし否定 実際に確認せず「存在しない」「動かない」と主張する 記憶による主張 過去の学習データだけに基づく事実主張 自信に満ちた誤り 高い確信度で不正確な情報を提供する 3. 違反時のインシデント記録と伝播 ハルシネーションが検出された場合、インシデントとして記録し、全プロジェクト横断で伝播させます。これにより同じ失敗パターンを繰り返さない仕組みを構築します。 4. プロジェクト設定への組み込み CLAUDE.md や類似の設定ファイルにルールを記述し、プロジェクト単位で一貫したガードレールを維持します。 2026年のハルシネーション対策の現状 2026年3月時点で、各 LLM のハルシネーション率は改善が進んでいます。LLM Hallucination Index 2026 によると、Claude Sonnet 4.6 は BS 検出成功率 91.0%、誤検出率 3.0% とトップクラスの精度を示しています。 しかし、モデル性能の向上だけでは不十分です。特に以下の場面ではハルシネーションが発生しやすいことが報告されています: コンテキスト圧縮後: 長い会話でコンテキストが圧縮されると、計画と実装の乖離が起きやすい Plan Mode での実装フェーズ: 計画作成後の実装で、計画にない機能を追加してしまう 実践的な対策 CLAUDE.md への記述例 1 2 3 4 5 6 ## Anti-Hallucination Rules - ファイルの存在確認は必ず `ls` や `cat` で実行すること - パッケージのインストール状況は `which` だけでなく、実際のインポートやバージョン確認で検証すること - エラーの原因を主張する前に、必ずログファイルを読むこと - 「〜のはずです」「おそらく〜」という推測を事実として扱わないこと CLEO のようなツールの活用 CLEO は Claude Code 向けのタスク管理ツールで、4層の Anti-Hallucination 保護と SQLite による不変の監査証跡を提供します。 ...