「toA」時代の到来 — AIエージェント向けサービス200超が示す新市場の全体像

「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選」で確認できます。

2026年3月30日 · 1 分

AI社員40人を作って1ヶ月で全部やめた話 — 壊れない設計のために知っておくべきこと

Claude Code のエージェントを40体つくり、役割を分けてルールを書いて階層もつくった。1ヶ月後、ぜんぶやめた。こはく氏(@Kohaku_NFT)の実体験レポートから、AIエージェント大量運用が構造的に壊れる理由と、そこから見えた「壊れない設計」の考え方を整理する。 やったこと Claude Code の Max プラン(月$200)1アカウントで検証 リーダー、ライター、リサーチャー、コーダー、レビュアーなど40体のエージェントを構築 役割分担、ルール、階層、性格設定まで丸2日かけて設計 最初の3日間は動いた。指示を出せばちゃんと返ってくる。SNS でスクショをあげようとした矢先に崩壊が始まった。 壊れる3つの構造的理由 理由1: Context Rot(記憶の腐敗) Context Rot とは、コンテキストウィンドウに情報が溜まるほど古い情報の精度が落ちる現象のこと。Anthropic の公式ドキュメントにも「トークン数が増えるほど、精度と想起(思い出す力)が劣化する」と明記されている。 1000ページの社内マニュアルと同じ構造 — 人間が全ページを暗記できないように、AIも情報が多すぎると処理しきれなくなる 「100万トークン入る」と「安定して使える」は別物 — 公式でさえ「文脈は大きければいいわけではない」と警告している こはく氏の実測では、10万トークンを超えるとブレが目立ち始めた ルール、コード、会話履歴が積み上がるほど再現性は低下する。 理由2: Compaction 後に構成が崩れる 長時間運用すると、コンテキストウィンドウの容量を確保するために前半の会話内容が自動で要約・圧縮される仕様(compaction)がある。Claude Code の公式リリースノートにも「圧縮後に一部のエージェントが消えたり、重複して生成される不具合」が明記されている。 会話の流れの中だけで役割や引き継ぎを設定していると、圧縮が走った瞬間にその前提ごと消え去る 会社でいうと「引き継ぎなしの二重配属」 — 過去の議事録を読まずに中途配属され、すでに同じ業務をしている人がいることも知らない状態 40人体制で3時間回せば、ほぼ確実に圧縮が走る。そのたびに「今、誰が消えた?」を人間が確認するハメになる 理由3: テキストのルールは絶対命令じゃない 「自分で作業するな。指示だけ出せ」と書いても、Claude が毎回きれいに従うとは限らない。 LLM にとってルール文は、絶対命令ではなく、文脈の一部として処理される。履歴、途中のやりとり、直前の出力に引っ張られて解釈がズレる。 最近の評価研究でも、LLM は「どの指示を優先するか」の判断や長い文脈での安定した instruction following に弱さがあると報告されている。ルールが増えて競合し始めるほどズレる前提で見たほうがいい。 厳密に書けば書くほど、今度はルールが長くなって context rot が進む。この構造そのものが、人数を増やしたときの壁になる。 「育てれば良くなる」は順番の問題 「使い込むほど育つ」とよく聞くが、ここで否定しているのは育成そのものではなく順番の話。 guidelines を育てるということは、ファイルが増えるということ。ファイルが増えるということは、コンテキストが重くなるということ。つまり context rot が加速するだけ。 壊れやすい仕組みの上に知識を積んでも、崩れやすくなるだけだ。 人間の会社で考えても同じ: エスカレーションルールがない トラブル時の判断基準がない 報告のかたちもない そんな会社は人を増やすほど混乱する。AI組織もまったく同じ構造。 エージェントには視野がない ここが核心。 ...

2026年3月30日 · 1 分

Claude AI で投資銀行レベルの財務モデルを作成する 12 のプロンプト

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 の財務サービス向け機能を大幅に拡充した。 ...

2026年3月30日 · 1 分

Claude Code + Celery: LLMが決定論的処理を動的に委譲するオーケストレーション

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 ワーカーに委譲する。 ...

2026年3月30日 · 4 分

Claude Codeベストプラクティス疲れに終止符 — claude-code-best-practiceリポジトリ一本で運用する方法

Claude Codeのベストプラクティスが毎日TLに流れてくる。追いかけるのに疲れた人向けに、1つのリポジトリだけをフォローして運用する方法を紹介する。 ベストプラクティス疲れという問題 Claude Codeの普及に伴い、SNS上には日々さまざまなベストプラクティスやTipsが投稿されている。しかし、情報が断片的で、どれを採用すべきか判断するだけでも消耗する。 結論として、ベストプラクティスを追うことに時間を費やすより、具体的な仕組みの実装に時間を割いた方が生産的だ。 claude-code-best-practiceリポジトリとは shanraisshan/claude-code-best-practice は、Claude Codeの設計や運用に関するベストプラクティスを体系的にまとめたリポジトリだ。 GitHub Star数: 約24,800(2026年3月時点) 海外コミュニティで広く参照されている 設計思想から具体的な設定まで、日々更新されている 日本のSNSでバズるClaude Code Tipsも、元ネタはこのリポジトリ周辺であることが多い 導入手順 やることは2ステップだけ。 Step 1: リポジトリをクローン 1 git clone https://github.com/shanraisshan/claude-code-best-practice.git Step 2: Claude Codeにプロジェクト固有のベストプラクティスを提案させる 自分のプロジェクトディレクトリでClaude Codeを起動し、以下のように依頼する: このリポジトリ(claude-code-best-practice)を参考に、 うちのプロジェクトに合ったベストプラクティスを提案して Claude Codeがプロジェクトの構成を読み取り、適切なCLAUDE.mdの設定やSkills、エージェント構成を提案してくれる。 startup hookで常に最新化する クローンしたリポジトリは時間とともに古くなる。Claude Codeの SessionStart hook(セッション開始時に自動実行される仕組み)に git pull を設定しておけば、起動のたびに自動で最新化される。 Claude Codeのユーザー設定ファイル(~/.claude/settings.json)に以下を追加する: 1 2 3 4 5 6 7 8 9 10 11 { "hooks": { "SessionStart": [ { "type": "command", "command": "cd /path/to/claude-code-best-practice && git pull --quiet", "timeout": 10000 } ] } } /path/to/ の部分は、Step 1でクローンした実際のパスに置き換えること。 ...

2026年3月30日 · 1 分

Mistral Voxtral TTS: ElevenLabs に匹敵するオープンウェイト音声AI

Mistral AI が 2026年3月26日にリリースした Voxtral TTS(Text-to-Speech)は、オープンウェイトで公開された音声合成モデルです。ElevenLabs に匹敵する品質を持ちながら、ローカル環境で動作するのが最大の特徴です。 Voxtral TTS の概要 Voxtral TTS は Mistral AI 初のテキスト読み上げモデルで、4B(40億)パラメータの軽量設計です。Hugging Face で mistralai/Voxtral-4B-TTS-2603 として公開されています。 主な特徴: オープンウェイト: モデル重みが公開されており、自社サーバーやローカル PC で実行可能 9言語対応: 英語、フランス語、ドイツ語、スペイン語、オランダ語、ポルトガル語、イタリア語、ヒンディー語、アラビア語(日本語は未対応) 低遅延: 500文字・10秒のサンプルに対して TTFA(Time-to-First-Audio)90ms リアルタイム性能: RTF(Real-Time Factor)6x、つまりリアルタイムの約6倍の速度で生成(10秒のクリップを約1.6秒で出力) 音声クローン: わずか3秒のサンプルからアクセント・抑揚・話し方の癖を再現 20種類のプリセット音声: すぐに使える多様な声質 ElevenLabs との比較 Mistral の公式ベンチマークによると、Voxtral TTS は: ElevenLabs Flash v2.5 より優れた自然さを実現(同等の TTFA を維持) ElevenLabs v3 と同等の音質を達成 従来は従量課金制の商用サービスに頼るしかなかった高品質音声合成が、オープンウェイトで利用できるようになりました。 動作要件 項目 仕様 パラメータ数 4B モデルサイズ 約 8 GB(BF16) GPU メモリ 16 GB 以上推奨 出力形式 WAV, PCM, FLAC, MP3, AAC, Opus サンプリングレート 24 kHz BF16 版は GPU 16GB 以上が必要ですが、量子化バージョン(mlx-community/Voxtral-4B-TTS-2603-mlx-4bit)も公開されており、Apple Silicon Mac などでより少ないメモリで実行可能です。Mistral はスマートフォンなどのエッジデバイスでの動作も想定した設計としています。 ...

2026年3月30日 · 1 分

「値は計算されていた。ただ届いていなかっただけ」— LLMエージェントプロンプトのハードコード問題

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取引あたりポジション上限)は既にテンプレート変数化されていた: ...

2026年3月27日 · 2 分

Anthropic の3エージェント・ハーネス設計: Claude が6時間でフルアプリを自律構築する仕組み

Anthropic の研究者 Prithvi Rajasekaran 氏が、Claude を使ってフルスタックアプリケーションを自律的に構築する「3エージェント・ハーネス」アーキテクチャを公開しました。人間の介入なしに6時間でプレイ可能なゲームエディタを完成させた事例とともに、その設計思想を解説します。 「ハーネス設計」とは何か 「ハーネス(harness)」とは、AI モデルを単体で走らせるのではなく、モデルの外側に構築する制御構造・オーケストレーションロジック全体を指します。具体的には、どのエージェントがどの順番で何を担当するか(役割分離)、エージェント間でどう情報をやり取りするか(契約の交渉)、いつ次に進みいつやり直すか(判定ループ)、何を使ってテストするか(ツール選択)といった設計要素が含まれます。 モデル自体の性能向上とは別の軸で、この制御層をどう設計するかが自律開発の品質を左右します。 背景: AI は自分に甘すぎる このアーキテクチャが生まれた核心的な課題は、AI モデルが自分の出力に対して甘い評価をしがちであるという点です。 「自分が生成した成果物を評価させると、エージェントは自信を持ってそれを称賛する傾向がある —— 人間の目から見れば明らかに品質が低い場合でさえ」(Rajasekaran 氏) この問題は、デザインのような正解/不正解が明確でない領域で特に顕著です。コードにおいても、理論上は正しさを検証できるはずですが、AI エージェントは自分のエラーをスルーしてしまいがちです。 解決策として採用されたのが、GAN(Generative Adversarial Network: 敵対的生成ネットワーク)に着想を得た分離アプローチ —— 「作る役割」と「評価する役割」を完全に分けるという設計です。 3エージェント・アーキテクチャ 最終的に構築されたハーネスは、以下の3つの専門エージェントで構成されるアーキテクチャになっています。 エージェント 役割 Planner 1〜4文のアイデアを完全な製品仕様に展開 Generator 機能ごとにスプリント方式で実装 Evaluator 実行中のアプリを Playwright でテスト・採点 flowchart TD A["ユーザー\n1〜4文のアイデア"] --> B["Planner\n製品仕様に自動展開"] B --> C["スプリント契約の交渉\n終了条件の事前合意"] C --> D["Generator\nReact/Vite/FastAPI で実装"] D --> E["Evaluator\nPlaywright MCP で実アプリテスト"] E -->|"採点: 製品深さ・機能性\nデザイン・コード品質"| F{合格?} F -->|"不合格\nバグ報告 + 改善指示"| D F -->|"合格"| G{次のスプリント?} G -->|"あり"| C G -->|"なし"| H["完成アプリ"] Planner: 仕様の自動展開 初期バージョンでは、生のプロンプトを渡すとモデルがタスクを過小評価する問題がありました。十分に考える前にビルドを開始してしまい、機能の薄いアプリが生成されていたのです。Planner はこの問題を解決するために追加されたエージェントで、短いアイデアを詳細な製品仕様に自動展開します。 ...

2026年3月27日 · 2 分

OpenClaw で YouTube 運用を全自動化? 「月1000万円」の主張を技術的に検証する

「1ヶ月後のYouTubeはOpenClawが全て運用し『月1000万円』収益を上げるアカウントが大量発生する」——こんな投稿が X(旧 Twitter)で話題になっています。本当にそこまでできるのか、OpenClaw の技術的な能力と YouTube 運用の現実を照らし合わせて検証します。 元の主張の要約 X ユーザー @gagarot200 の投稿では、以下のような主張がなされています: 海外では既に 2000 万円を稼いでいるケースがある 勝負のポイントは編集技術ではなく「企画設計」「視聴維持率」「CTR改善」「投稿導線の最適化」 OpenClaw で競合分析→台本生成→素材選定→動画編集→サムネイル量産→投稿→数値分析を一気通貫で回せる 個人でもチーム運用レベルの全自動化が可能 OpenClaw とは OpenClaw は、GitHub で 34 万スター以上を獲得しているオープンソースの AI エージェントフレームワークです。ローカルマシン上で動作し、ブラウザ操作・ファイル読み書き・シェルコマンド実行・cron ジョブなどを自律的に実行できます。WhatsApp、Telegram、Slack、Discord など多数のメッセージングプラットフォームに対応しています。 技術的に「できること」と「できないこと」 OpenClaw で実現可能な部分 OpenClaw の Skills(プラグイン)機能とブラウザ自動化を組み合わせると、以下のタスクは技術的に実現可能です: タスク 実現方法 実用度 競合チャンネル分析 YouTube Data API + ブラウザスクレイピング ◎ 台本生成 LLM による構成生成 ◎ サムネイル量産 画像生成 AI + テンプレート自動適用 ○ 投稿スケジューリング YouTube Data API / ブラウザ自動化 ○ 数値分析・レポート YouTube Analytics API からのデータ取得・分析 ◎ CTR / 視聴維持率の改善提案 分析データを LLM にフィードバック ○ 現状では難しい部分 一方で、以下の部分には大きなハードルがあります: ...

2026年3月27日 · 2 分

Prompt Engineering から Harness Engineering へ: AI エンジニアリングの進化と「仕組みの設計力」の時代

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」を公開した。 ...

2026年3月27日 · 2 分