AI エージェントで学ぶべきこと、構築すべきこと、避けるべきこと (2026 年版)

AI エージェントで学ぶべきこと、構築すべきこと、避けるべきこと (2026 年版)

@rohit4verse
英語2 週間前 · 2026年4月29日

AI features

2.5M
1.6K
242
46
6.3K

TL;DR

AI エージェント開発に関する戦略的な深掘り解説。コンテキストエンジニアリングや MCP といった持続可能なプリミティブに焦点を当てつつ、流行に左右されるフレームワークを避け、堅牢な評価とサンドボックス環境の構築を優先すべき理由を説く。

日本語翻訳

毎日のように新しいフレームワーク、新しいベンチマーク、新しい「10倍」のローンチが登場する。「どうやって追いつけばいいのか」という問いはもはや意味をなさない。本当の問いはこうだ:本当に重要なシグナルはどれで、緊急性の仮面をかぶったノイズはどれなのか。

あらゆるロードマップは、ローンチから1ヶ月で時代遅れになる。先 quarter に習得したフレームワークは、今やレガシーだ。最適化したベンチマークは、ゲーム化されて置き換えられた。私たちは従来のキャリアパスを歩むよう条件づけられてきた:トピックとレベルで構成されたスタック、一連の職務と在職期間、ゆっくりとした昇進。AI はそのキャンバスを塗り替えた。適切なプロンプトと適切なセンスを持つ人なら誰でも、かつては2年の経験を持つエンジニアが1スプリントかけてやっていた仕事を、今や出荷できる。

専門知識は依然として重要だ。システムが壊れるのを目の当たりにした経験、午前2時にメモリリークをデバッグした経験、賢い選択よりも退屈な選択を主張して正しかった経験に代わるものはない。そういったセンスは複利的に効く。しかし、以前のように複利的に効かなくなったものもある:今週のフレームワークの API サーフェスを知っていることだ。6ヶ月後にはそれは変わっている。2年後に勝っている人々は、耐久性のあるプリミティブを早期に選び、残りは素通りさせている。

私はこの分野で2年間構築に携わり、25万ドルを超える複数のオファーを獲得し、現在はステルスモードの企業で技術責任者を務めている。これは、「今、本当に注目すべきことは何か」と尋ねる人に私が送る内容だ。

これはロードマップではない。エージェント分野にはまだ目的地がない。大手研究所は公開でイテレーションを繰り返し、何百万ものユーザーにリグレッションを出荷し、ポストモーテムを書き、ライブでパッチを当てている。Claude Code のチームが47%のパフォーマンスリグレッションを出荷し、ユーザーコミュニティが気づくまで気づかなかったという事実を考えれば、このすべての背後に安定した地図があるという考えはフィクションだ。誰もが手探りで進んでいる。スタートアップが繁栄しているのは、巨人たちも答えを知らないからだ。非プログラマーがエージェントとペアを組み、ML 博士号保持者が火曜日に不可能だと言っていたことを金曜日に出荷している。

この瞬間の興味深い点は、それが資格の問題に与える影響だ。従来のキャリアパスは、資格のために最適化されていた:学位、ジュニア職、シニア職、スタッフ職、ランクのゆっくりとした蓄積。それは、自分の足元の分野が動かなかった時代には理にかなっていた。今や分野は、すべての人の足元で等しく動いている。公開でエージェントのデモを出荷する22歳と、35歳のシニアエンジニアの差は、もはや10年間のスタック習熟度の蓄積ではない。22歳もシニアも同じ白紙のキャンバスを持っており、どちらにとっても複利的に効くのは、出荷する意欲と、1 quarter で時代遅れにならない少数のプリミティブのリストだ。

これが、この記事全体の基盤となるリフレーミングだ。以下は、どのプリミティブに注目する価値があり、どのローンチをスルーすべきかを考えるための方法だ。自分に合うものを選び、合わないものは捨てよう。

実際に機能するフィルター

毎週のローンチに追いつくことはできない。追いつこうとすべきでもない。必要なのはフィードではなく、フィルターだ。

過去18ヶ月間、5つのテストが有効だった。ローンチをスタックに取り入れる前に、これらのテストにかけてみよう。

これは2年後も重要か? フロンティアモデルのラッパー、CLI フラグ、「Devin だけど X 向け」のようなものなら、答えはほぼ常にノーだ。プリミティブ(プロトコル、メモリパターン、サンドボックス化アプローチ)なら、答えはイエスであることが多い。ラッパーの半減期は短い。プリミティブの半減期は数年だ。

あなたが尊敬する誰かが、その上に実際に何かを構築し、正直にそれについて書いたか? マーケティング投稿はカウントされない。ポストモーテムはカウントされる。「本番環境で X を試してみて、何が壊れたか」というブログは、10のローンチアナウンスに値する。この分野の良いシグナルは、常にそれに週末を費やした誰かによって書かれる。

それを採用するには、トレーシング、リトライ、設定、認証を捨てる必要があるか? もしそうなら、それはプラットフォームになろうとしているフレームワークだ。プラットフォームになろうとするフレームワークの死亡率は90%だ。良いプリミティブは、移行を強制することなく、既存のシステムにスロットインできる。

これを6ヶ月間スキップするコストは? ほとんどのローンチでは、答えは「なし」だ。6ヶ月後にはもっとよくわかるだろう。勝ちバージョンがより明確になる。これは、不安なく90%のローンチをスキップできるテストであり、ほとんどの人がスキップすることを拒否するテストでもある。なぜなら、スキップすることは遅れを取ることのように感じられるからだ。実際は違う。

それが実際にエージェントの役に立っているか測定できるか? できなければ、推測していることになる。評価のないチームは雰囲気で動き、リグレッションを出荷する。評価のあるチームは、今週 GPT-5.5 か Opus 4.7 のどちらが特定のワークロードで勝つかをデータに教えてもらえる。

この記事全体から1つの習慣を身につけるなら、これにしよう:何か新しいものがローンチされたとき、6ヶ月後にそれが重要だと信じるために何を見る必要があるかを書き留める。そして、戻って確認する。ほとんどの場合、その問いは自然に答えが出ており、あなたは複利的に効くものに注意を向けていたことになる。

これらのテストの根底にあるスキルは、どれよりも名前をつけるのが難しい。それは、自分が選ばないものについて格好悪くあることを厭わない姿勢だ。今週 Hacker News で話題になるフレームワークには、14日間応援団が現れ、皆賢そうに見える。6ヶ月後には、それらのフレームワークの半分はメンテナンスされておらず、応援団は次のものに移っている。関与しなかった人々は、ローンチの誇大広告が過ぎ去った後も退屈であるという試練に耐えたもののために注意を温存した。その姿勢、つまり、手をこまねいて見守り、「6ヶ月後にわかるだろう」と言うことは、この分野の実際のプロフェッショナルスキルだ。誰でもローンチを読むことはできる。それに反応しないことが得意な人はほとんどいない。

何を学ぶべきか

コンセプト。パターン。物事の形状。これらは複利的なリターンをもたらすアイデアだ。モデルの入れ替え、フレームワークの入れ替え、パラダイムシフトにも耐える。それらを深く理解すれば、新しいツールは週末で習得できる。それらをスキップすれば、表面的なメカニクスを永遠に学び直すことになる。

コンテキストエンジニアリング

過去2年間で最も重要な名称変更は、「プロンプトエンジニアリング」が「コンテキストエンジニアリング」になったことだ。この変化は表面的なものではなく、本質的だ。

モデルはもはや、巧妙な指示を考案する対象ではない。すべてのステップで、動作するコンテキストを組み立てる対象だ。そのコンテキストは、システムインストラクション、ツールスキーマ、取得されたドキュメント、以前のツール出力、スクラッチパッドの状態、圧縮された履歴のすべてを同時に含む。エージェントの振る舞いは、ウィンドウに入力したものの創発的な特性だ。

これを内面化しよう:コンテキストは状態だ。無関係なノイズのトークン1つ1つが、推論の質を低下させる。コンテキストの腐敗は、実際の本番障害だ。10ステップのタスクの8ステップ目までに、元の目標はツール出力の下に埋もれてしまう。信頼性の高いエージェントを出荷するチームは、積極的に要約、圧縮、剪定を行う。ツールの説明をバージョン管理する。静的パーツはキャッシュし、変更されるパーツはキャッシュしない。経験豊富なエンジニアが RAM について考えるように、コンテキストウィンドウについて考える。

これを実感する具体的な方法:本番環境の任意のエージェントを取得し、フルトレースログをオンにする。ステップ1のコンテキストを見る。ステップ7のコンテキストを見る。そのトークンのうち、いくつがまだ価値を生み出しているか数えてみよう。初めてこれを行うと、恥ずかしい思いをするだろう。そして、それを修正しに行き、モデルやプロンプトを一切変更せずに、同じエージェントが顕著に信頼性を増すのを目にするだろう。

これについて何か読むなら、Anthropic の「AI エージェントのための効果的なコンテキストエンジニアリング」を読もう。次に、彼らのマルチエージェント研究のポストモーテムを読もう。そこには、スケールアップしたときにコンテキストの分離がどれほど重要かが数値で示されている。

ツールデザイン

ツールは、エージェントがビジネスと出会う場所だ。モデルは名前と説明に基づいてツールを選択する。モデルはエラーメッセージに基づいてリトライする。モデルは、ツールの契約が LLM が表現するのが得意なものと一致するかどうかに基づいて成功または失敗する。

5〜10の適切に命名されたツールは、20の平凡なツールに勝る。ツール名は英語の動詞句のように読めるべきだ。説明には、ツールを使用すべき場合と使用すべきでない場合を含めるべきだ。エラーメッセージは、モデルが行動できるフィードバックであるべきだ。「最大トークン数500を超過しました。最初に要約してみてください」は、「エラー:400 Bad Request」よりもはるかに優れている。ある公開研究のチームは、エラーメッセージを書き換えただけで、リトライループが40%減少したと報告している。

Anthropic の「エージェントのためのツール作成」は適切な出発点だ。その後、自分のツールを計測し、実際の呼び出しパターンを確認しよう。エージェントの信頼性における最大の成果は、ほとんどの場合ツール側にある。人々はプロンプトを調整し続け、実際のレバレッジが存在する場所を無視している。

オーケストレーター-サブエージェントパターン

2024年と2025年のマルチエージェント論争は、今や誰もが出荷する統合で終結した。複数のエージェントが並行して共有状態に書き込むナイーブなマルチエージェントシステムは、エラーが複合するため、壊滅的に失敗する。シングルエージェントループは、予想以上にスケールする。本番環境で機能するマルチエージェントの形状は1つだけだ:狭いスコープの読み取り専用タスクを分離されたサブエージェントに委任し、その結果を統合するオーケストレーターエージェントだ。

これが Anthropic の研究システムの動作方法だ。Claude Code のサブエージェントの動作方法だ。Spring AI とほとんどの本番フレームワークが現在標準化しているパターンだ。サブエージェントは小さく焦点を絞ったコンテキストを得る。共有状態を変更することはできない。オーケストレーターが書き込みを所有する。

Cognition の「マルチエージェントを構築するな」というエッセイと、Anthropic の「マルチエージェント研究システムの構築方法」は、対立しているように見えて、同じことを異なる語彙で言っている。両方を読もう。

デフォルトはシングルエージェントだ。オーケストレーター-サブエージェントに手を伸ばすのは、シングルエージェントが実際の壁にぶつかったときだけにしよう:コンテキストウィンドウのプレッシャー、逐次ツール呼び出しによるレイテンシ、または焦点を絞ったコンテキストから真に恩恵を受けるタスクの多様性。痛みを感じる前にこれを構築すると、必要のない複雑さを出荷することになる。

評価とゴールデンデータセット

信頼性の高いエージェントを出荷するすべてのチームには評価がある。そうでないチームには評価がない。これはこの分野で最もレバレッジの高い習慣であり、私が見てきたすべての企業で最も過小投資されているものだ。

何が機能するか:本番トレースを収集し、失敗にラベルを付け、それをリグレッションセットとして扱う。新しい失敗が出荷されるたびに追加する。主観的な部分には LLM-as-judge を使用し、残りには完全一致またはプログラムによるチェックを使用する。プロンプト、モデル、またはツールの変更の前にスイートを実行する。Spotify のエンジニアリングブログは、彼らのジャッジレイヤーがエージェント出力の約25%を出荷前に拒否すると報告している。それがなければ、4つに1つの悪い結果がユーザーに届いていたことになる。

これを定着させるメンタルモデル:評価は、他のすべてがその下で変化している間、エージェントを正直に保つユニットテストだ。モデルは新しいバージョンを得る。フレームワークは破壊的変更をリリースする。ベンダーはエンドポイントを非推奨にする。評価だけが、エージェントがまだ仕事をしているかどうかを教えてくれる。評価がなければ、あなたは、その正しさが動く標的の善意に依存するシステムを書いていることになる。

評価フレームワーク(Braintrust、Langfuse evals、LangSmith)は問題ない。どれもボトルネックではない。ボトルネックは、そもそもラベル付けされたセットを持っていることだ。何かをスケールする前に、初日にそれを構築しよう。最初の50の例は、午後で手動ラベル付けできる。言い訳はできない。

ファイルシステム-as-状態と思考-行動-観察ループ

実際のマルチステップ作業を行うエージェントにとって、耐久性のあるアーキテクチャはこれだ:考え、行動し、観察し、繰り返す。ファイルシステムまたは構造化ストアを信頼できる情報源として。すべてのアクションがログに記録され、リプレイ可能。Claude Code、Cursor、Devin、Aider、OpenHands、goose。それらすべてがこれに収束したのには理由がある。

モデルはステートレスだ。ハーネスはステートフルである必要がある。ファイルシステムは、すべての開発者がすでに理解しているステートフルなプリミティブだ。このフレーミングを受け入れると、ハーネス全体の規律(チェックポインティング、再開可能性、サブエージェント検証、サンドボックス実行)は、パターンを真剣に受け止めることから自然に導き出される。

これが教えているより深いこと:本番環境で計算コストに見合うエージェントでは、ハーネスはモデルよりも多くの作業を行っている。モデルは次のアクションを選択する。ハーネスはそれを検証し、サンドボックスで実行し、出力をキャプチャし、何をフィードバックするかを決定し、いつ停止するかを決定し、いつチェックポイントするかを決定し、いつサブエージェントを生成するかを決定する。モデルを同程度の品質の別のモデルと交換しても、良いハーネスはまだ出荷される。ハーネスをより悪いものと交換すると、世界最高のモデルでも、自分が何をしていたかをランダムに忘れるエージェントを生成する。

単発のツール呼び出しよりも複雑なものを構築しているなら、ハーネスに時間を費やすべきだ。モデルはその内部のコンポーネントだ。

MCP、概念的に

MCP サーバーの呼び出し方法を学ぶだけではない。モデルを学ぼう。エージェント機能、ツール、リソースのクリーンな分離と、その下にある拡張可能な認証とトランスポートのストーリー。一度理解すれば、他の「エージェント統合フレームワーク」はすべて MCP の劣化版に見え、それぞれを評価する時間を節約できる。

Linux Foundation が現在それを管理している。すべての主要なモデルプロバイダーがそれを支持している。「AI の USB-C」という比較は、今や皮肉ではなく正確だ。

サンドボックス化をプリミティブとして

すべての本番コーディングエージェントはサンドボックスで実行される。すべてのブラウザエージェントは間接プロンプトインジェクションの影響を受けたことがある。すべてのマルチテナントエージェントは、ある時点でパーミッションスコーピングのバグを出荷したことがある。サンドボックス化を、顧客が尋ねたときに追加する機能ではなく、プリミティブなインフラストラクチャとして扱おう。

基本を学ぼう。プロセス分離。ネットワーク出力制御。シークレットスコーピング。エージェントとツール間の認証境界。顧客のセキュリティレビューの後にこれを追加するチームは、取引を失うチームだ。最初の週から組み込むチームは、汗をかかずにエンタープライズ調達を通過する。

何を使って構築するか

2026年4月時点での具体的な選択。これらは変化するが、ゆっくりとだ。ここでは退屈なものを選ぼう。

オーケストレーション

LangGraph が本番環境のデフォルトだ。大企業の約3分の1がエージェントの実行に使用している。その抽象化は、エージェントシステムの実際の形状と一致する:型付き状態、条件付きエッジ、耐久性のあるワークフロー、ヒューマンインザループチェックポイント。欠点は冗長さだ。利点は、その冗長さが、エージェントが本番環境に入った後に実際に制御する必要があるものと一致することだ。

TypeScript で作業しているなら、Mastra が事実上の選択だ。そのエコシステムで最もクリーンなメンタルモデル。

チームが Pydantic を愛し、型安全性を第一級市民として望むなら、Pydantic AI は合理的なグリーンフィールドの選択肢だ。2025年後半に v1.0 に達し、勢いは本物だ。

プロバイダーネイティブな作業(コンピューター使用、音声、リアルタイム)には、LangGraph ノード内で Claude Agent SDK または OpenAI Agents SDK を使用しよう。どちらかを異種システムのトップレベルオーケストレーターにしようとしないで。それらは自分のレーンに最適化されている。

プロトコルレイヤー

MCP、これに尽きる。ツール統合を MCP サーバーとして構築しよう。外部統合も同じ方法で消費しよう。レジストリは、サーバーを構築する前にほとんどの場合見つけられるポイントを超えた。2026年にカスタムツール配管を配線することは、何のためにも税金を払っていることになる。

メモリ

誇大広告ではなく、自律性レベルで選ぼう。

チャットスタイルのパーソナライゼーションには Mem0。ユーザー設定、軽い履歴。状態が進化し、エンティティ追跡が必要な本番会話システムには Zep。エージェントが数日から数週間の作業にわたって一貫性を維持する必要がある場合には Letta。ほとんどのチームはこれを必要としない。必要なチームは、まさにこれを必要とする。

間違いは、メモリ問題が発生する前にメモリフレームワークに手を伸ばすことだ。コンテキストウィンドウが保持できるものとベクターストアから始めよう。解決する障害モードを明確に説明できる場合にのみ、メモリシステムを追加しよう。

可観測性と評価

Langfuse が OSS のデフォルトだ。セルフホスト可能、MIT ライセンス、トレーシング、プロンプトバージョン管理、基本的な LLM-as-judge 評価をカバー。すでに LangChain ショップなら、LangSmith の方が緊密に統合される。厳密な比較を伴う研究スタイルの評価ワークフローには Braintrust が適切な選択だ。ポリグロットスタックでベンダーニュートラルな OpenTelemetry 計装が必要なら、OpenLLMetry / Traceloop が答えだ。

トレーシングと評価の両方が必要だ。トレーシングは「エージェントは実際に何をしたか?」に答える。評価は「エージェントは昨日より良くなったか悪くなったか?」に答える。両方なしで出荷してはいけない。目隠しして実行するコストは、初日にこれを適切に配線するコストの10倍だ。

ランタイムとサンドボックス

一般的なサンドボックスコード実行には E2B。ブラウザ自動化には Browserbase(Stagehand とペアで)。実際の OS レベルのデスクトップ制御が必要な場合には Anthropic Computer Use。短命のバーストには Modal。サンドボックス化されていないコード実行は絶対に実行してはいけない。本番環境でプロンプトインジェクションされたエージェント1つの爆発半径は、語りたくないストーリーだ。

モデル

ベンチマーク追跡は exhausting で、ほとんど役に立たない。現実的に、2026年4月時点:

信頼性の高いツール使用、マルチステップの一貫性、優雅な障害回復には Claude Opus 4.7 と Sonnet 4.6。Sonnet はほとんどのワークロードでコストパフォーマンスのスイートスポットだ。最強の CLI/ターミナル推論が必要な場合、または OpenAI インフラにいる場合には GPT-5.4 と 5.5。長いコンテキストまたはマルチモーダルが多いジョブには Gemini 2.5 と 3。特に狭く明確に定義されたタスクでは、コストがトップエンドのパフォーマンスよりも重要な場合には DeepSeek-V3.2 または Qwen 3.6。

モデルは交換可能なものとして扱おう。エージェントが1つのモデルでしか動作しないなら、それはムートではなく、においだ。評価を使用して何をデプロイするかを決定しよう。毎週ではなく、毎 quarter 再評価しよう。

何をスキップすべきか

これらすべてを学び、構築するように言われるだろう。その必要はない。スキップするコストは低い。節約できる時間は大きい。

本番環境での AutoGen と AG2。 Microsoft のフレームワークはコミュニティメンテナンスに移行し、リリースは停滞し、抽象化は本番チームが実際に必要とするものと一致しない。学術的な探求には問題ない。製品をそれに依存させてはいけない。

新しい本番構築のための CrewAI。 デモが簡単なのでどこにでもある。実際のシステムを構築するエンジニアはそれから離れている。プロトタイプには使いたければ使ってもいい。それにコミットしてはいけない。

Microsoft Semantic Kernel。 Microsoft のエンタープライズスタックにロックインされており、購入者がそれを気にしている場合を除く。エコシステムが向かっている方向ではない。

DSPy。 大規模なプロンプトプログラムを特に最適化している場合を除く。哲学的なメリットはあるが、ニッチなオーディエンスだ。一般的なエージェントフレームワークではない。それとして選んではいけない。

アーキテクチャ選択としてのスタンドアロンコード作成エージェント。 コード-as-アクションは興味深い研究だ。まだ本番環境のデフォルトパターンではなく、競合他社にはないツールとセキュリティの戦いに直面することになる。

「自律エージェント」の売り込み。 AutoGPT と BabyAGI の系譜は、製品形態としては死んでいる。業界が落ち着いた正直なフレーミングは「エージェンティックエンジニアリング」だ:監視され、境界があり、評価される。2026年にもまだデプロイして忘れる自律エージェントを売り込んでいる人は、2023年を売り込んでいる。

エージェントアプリストアとマーケットプレイス。 2023年から約束されているが、エンタープライズの牽引力を決して提供していない。エンタープライズは汎用的な事前構築済みエージェントを購入しない。成果に結びついた垂直エージェントを購入するか、自分で構築する。アプリストアの夢の周りにビジネスを構築してはいけない。

顧客としての水平「任意のエージェントを構築」エンタープライズプラットフォーム(Google Agentspace、AWS Bedrock Agents、Microsoft Copilot Studio ティア)。 いつかは役立つだろう。今のところ、それらは混乱しており、出荷が遅く、購入対構築の計算は依然として狭いエージェントを自分で構築するか、垂直のものを購入することを支持している。Salesforce Agentforce と ServiceNow Now Assist は例外だ。なぜなら、それらはすでに使用しているワークフローシステムに埋め込まれていることで勝つからだ。

SWE-bench と OSWorld リーダーボード追跡。 Berkeley の研究者は2025年を通じて、ほとんどすべての公開ベンチマークが、根本的なタスクを解決せずにゲーム化できることを文書化した。チームは現在、Terminal-Bench 2.0 と独自の内部評価を実際のシグナルとして使用している。単一数字のベンチマーク飛躍は、デフォルトで懐疑的に扱おう。

ナイーブな並列マルチエージェントアーキテクチャ。 共有メモリ上でチャットする5つのエージェントはデモでは印象的に見えるが、本番環境では崩壊する。ナプキンに読み取り/書き込み境界のあるクリーンなオーケストレーター-サブエージェント図を描けないなら、出荷してはいけない。

新しいエージェント製品のシート単位の SaaS 価格設定。 市場は成果ベースと使用量ベースに移行した。シート単位の価格設定は、テーブルにお金を残し、購入者に自社製品が成果を提供できると信じていないことを示す。

今週 Hacker News で見る次のフレームワーク。 6ヶ月待とう。それでも重要なら、明らかになる。そうでなければ、移行を節約したことになる。

実際にどう動くか

エージェントを採用しようとしているのであって、追いつこうとしているのではないなら、このシーケンスが機能する。退屈だ。機能する。

すでに重要である1つの成果を選ぶ。 ムーンショットではない。水平な「エージェントプラットフォーム」プロジェクトではない。ビジネスがすでに気にかけている測定可能な何か。サポートチケットの転送。ファーストパス法務レビューのドラフト作成。インバウンドリードの資格評価。月次レポートの生成。その成果が動いたときにエージェントは成功する。これが初日の評価ターゲットになる。

このステップが何よりも重要な理由は、その後のすべての決定を制約するからだ。特定の成果があれば、「どのフレームワークか」という問いは哲学的なものではなくなる。成果を最も早く出荷するものを選ぶ。「どのモデルか」という問いはベンチマークの議論ではなくなる。評価がこの特定のジョブで機能すると言うものを選ぶ。「メモリ/サブエージェント/カスタムハーネスが必要か」という問いは思考実験ではなくなる。特定の障害モードが必要とするものだけを追加する。このステップをスキップするチームは、誰も求めていない水平プラットフォームを構築することになる。これを真剣に受け止めるチームは、1 quarter で元が取れる単一の狭いエージェントを出荷し、その単一の出荷されたエージェントは、2年間の読書よりも多くのことをこの分野について教えてくれる。

何かを出荷する前にトレーシングと評価を設定する。 Langfuse または LangSmith を選ぶ。配線する。必要なら手動で小さなゴールデンデータセットを構築する。50のラベル付けされた例で十分だ。測定できないものを改善することはできない。後でこれを構築するコストは、今構築するコストの約10倍だ。

シングルエージェントループから始める。 LangGraph または Pydantic AI を選ぶ。モデルとして Claude Sonnet 4.6 または GPT-5 を選ぶ。エージェントに3〜7の適切に設計されたツールを与える。状態としてファイルシステムまたはデータベースを与える。小規模なオーディエンスに出荷する。トレースを監視する。

エージェントをプロジェクトではなく製品として扱う。 予測できなかった方法で失敗する。それらの失敗がロードマップだ。実際の本番トレースからリグレッションセットを構築する。すべてのプロンプト変更、すべてのモデル交換、すべてのツール変更は、デプロイ前に評価を通過する。ここがほとんどのチームが過小投資する場所だ。ここがほとんどの信頼性の源泉だ。

スコープを獲得したときにのみ追加する。 サブエージェントは、コンテキストがボトルネックになったときに導入する。メモリフレームワークは、シングルウィンドウコンテキストが必要なものを保持できないときに導入する。コンピューター使用またはブラウザ使用は、基礎となる API が本当に存在しないときに導入する。これらを事前にアーキテクチャしないで。障害モードにそれらを引き込ませよう。

退屈なインフラを選ぶ。 ツールには MCP。サンドボックスには E2B または Browserbase。状態には Postgres またはすでに実行しているデータストア。既存の認証と可観測性スタック。エキゾチックなインフラが勝利になることはめったにない。規律が勝利だ。

初日からユニットエコノミクスを監視する。 アクションあたりのコスト。キャッシュヒット率。リトライループコスト。モデル呼び出し分布。エージェントは PoC では安く見え、100倍のスケールで爆発する。実行あたり0.50ドルの PoC は、中程度のボリュームで月5万ドルになる。それが来るのを見ないチームは、楽しくない CFO ミーティングを得る。

モデルを毎週ではなく毎 quarter 再評価する。 1 quarter ロックインする。quarter の終わりに、現在のフロンティアに対して評価スイートを実行し、データが切り替えを指示すれば切り替える。モデル改善のメリットを、すべてのリリースを追いかける混乱なしに得られる。

潮の流れを読む

何かがシグナルである具体的な兆候:

ある尊敬すべきエンジニアリングチームが、単なる導入実績の主張ではなく、数字を伴ったポストモーテムを公開している。それは、ラッパーやバンドルではなく、プリミティブ(プロトコル、パターン、インフラ)である。既存のシステムを置き換えるのではなく、相互運用できる。その提案は、有効にする機能ではなく、解決する障害モードを説明している。そして、「何がうまくいかなかったか」を綴ったブログ記事が書かれるほど、長く存在している。

ノイズであることを示す具体的な兆候:

  • 30 日経ってもプロダクションのケーススタディがないデモ動画。
  • あまりに綺麗すぎて現実味のないベンチマークの飛躍。
  • 「自律型」「エージェント OS」「任意のエージェントを構築」といった言葉を、条件付けなしで使う提案。
  • 既存のトレーシング、認証、設定を破棄することを前提としたドキュメントを持つフレームワーク。
  • コミットやリリース、コントリビューターの増加を伴わない、急上昇するスター数。
  • GitHub の活動を伴わない Twitter での勢い。

役立つ週次の習慣:金曜日に 30 分間、この分野のために時間を確保する。3 つの記事を読む。Anthropic のエンジニアリングブログ。Simon Willison のノート。Latent Space。もし公開されていれば、1 つか 2 つのポストモーテムに目を通す。それ以外はその週はすべてスキップする。そうすれば、本当に重要なことがわかるようになる。

注目すべき点

今後 2 四半期にわたって注目に値するもの。それが確実な勝利だからではなく、「これはシグナルか?」という問いがまだ完全には解決されていないからだ。

Replit Agent 4 の並列フォークモデル。 共有状態でつまずかない、「複数のエージェントが並行して動作する」ことへの初の本格的な試み。スケールしても機能するなら、オーケストレーター・サブエージェントのデフォルトが変わる可能性がある。

アウトカムベースの価格設定の成熟。 Sierra と Harvey の収益軌道は、限られた垂直領域内でその有効性を検証している。問題は、それが垂直領域以外にも一般化するのか、それとも垂直領域限定のモデルに留まるのかだ。

パッケージングレイヤーとしてのスキル。 GitHub 全体での AGENTS.md とスキルディレクトリの急増は、エージェントの機能をパッケージ化する新たな方法が出現していることを示唆している。これが MCP がツールに対して行ったように標準化されるかどうかが、未解決の問いである。

Claude Code の 2026 年 4 月の品質低下とそのポストモーテム。 業界をリードするエージェントが 47% のパフォーマンス低下を起こし、内部の監視が捉える前にユーザーに発見された。これは、プロダクションにおけるエージェントの評価手法が、たとえリーダー企業であっても、いかに未熟であるかを示す教訓だ。これが業界全体のオンライン評価への投資を促進するなら、その修正は健全である。

デフォルトのサポートインターフェースとしての音声。 Sierra の音声チャネルは 2025 年後半にテキストを上回った。このパターンが他の垂直領域でも続くなら、設計上の制約(レイテンシ、割り込み、リアルタイムのツール使用)が最優先事項となり、現在のアーキテクチャの多くは再構築が必要になる。

オープンモデルのエージェント性能が差を縮めている。 DeepSeek-V3.2 のネイティブな思考からツール使用への連携。Qwen 3.6。より広範なオープンな環境。狭いエージェントタスクにおけるコストパフォーマンスが変化している。クローズドソースがデフォルトである状態は永続的ではない。

これらのそれぞれには、「6 ヶ月後に何を確認できれば、それを信じるに値するか」という明確な答えがある。それが試金石だ。発表ではなく、その答えを追いかけること。

型にはまらない賭け

採用しなかったすべてのフレームワークは、負う必要のなかった移行作業だ。追いかけなかったすべてのベンチマークは、維持した集中力の四半期だ。このサイクルで勝っている企業(Sierra、Harvey、Cursor はそれぞれの領域で)は、狭いターゲットを選び、退屈な規律を身につけ、分野のノイズを無視してきた。

従来の道はこうだった:スタックを選び、それを何年も習得し、階段を登る。それはスタックが 10 年間安定していた時代には機能した。しかし今、スタックは四半期ごとに変わる。勝っている人々は、スタックの習得を最適化するのをやめ、センス、プリミティブ、そして出荷速度を最適化し始めた。彼らは小さなものを公開で作る。出荷することで学ぶ。彼らがすでに作ったものによって、重要な場に引き込まれる。その証明書は、成果物そのものだ。

少し考えてみてほしい。なぜなら、これこそがこの記事全体の本当のポイントだからだ。私たちのほとんどは、世界が十分に静止していて、資格が価値を増すことを前提とした仕事のモデルで育ってきた。学校に行き、学位を取得し、階段を登る。ここに 2 年、あそこに 3 年、そしてゆっくりと履歴書は扉を開くものへと変わっていく。その仕組み全体は、その先に安定した業界があることを前提としていた。

エージェント領域には、今のところ安定した「その先」はない。あなたが働きたいと思うかもしれない企業は、設立から 6 ヶ月だ。それらが基づいているフレームワークは 18 ヶ月前のものだ。その下にあるプロトコルは 2 年前のものだ。この分野で最も引用されている記事の半分は、3 年前にはこの分野にいなかった人々によって書かれたものだ。登るべき階段はない。なぜなら、建物は常にフロアを変えているからだ。階段が機能しないときに残るのは、もっと古い方法だ:何かを作り、インターネットに公開し、その仕事があなたを紹介してくれるのを待つ。それは資格制度を無視するから、型にはまらない道だ。しかし、変化する分野で唯一価値を増す方法でもある。

これが、内部から見たこの時代の姿だ。巨人でさえ、公開で反復し、品質低下を出荷し、ポストモーテムを書き、本番環境にパッチを当てている。今年最も興味深いものを出荷しているチームには、18 ヶ月前にこの分野にいなかった人々が含まれている。コードを書かない人々がエージェントとペアを組み、実際のソフトウェアを出荷している。博士号を持つ人々は、適切なプリミティブを選び、行動を開始したビルダーに追い抜かれている。門は開かれている。ほとんどの人はまだ申込書を探しているところだ。

あなたが今、実際に開発すべきスキルは「エージェント」ではない。表面が絶えず変化する分野において、どの作業が価値を増すのかを見極める規律だ。コンテキストエンジニアリングは価値を増す。ツール設計は価値を増す。オーケストレーター・サブエージェントパターンは価値を増す。評価の規律は価値を増す。ハーネスマインドセットは価値を増す。火曜日にリリースされたフレームワークの API を知っていることは、価値を増さない。それらを見分けられるようになれば、毎週のローンチの波はプレッシャーではなくなり、無視できるノイズのように感じられるようになる。

すべてを学ぶ必要はない。価値を増すものを学び、そうでないものをスキップすればいい。1 つの成果を選べ。出荷する前にトレーシングと評価を設定せよ。LangGraph またはチームの同等のものを使え。MCP を使え。ランタイムをサンドボックス化せよ。デフォルトはシングルエージェントにせよ。障害モードがそれを必要とするときにスコープを追加せよ。モデルは四半期ごとに再評価せよ。金曜日に 3 つの記事を読め。

それがプレイブックだ。残りはセンス、出荷速度、そして重要でないものを追いかけない忍耐力だ。ものを作れ。インターネットに公開せよ。この時代は、そのものを説明できる人よりも、そのものを作る人に報いる。作る側になるための、かつてないほど良い機会が今、訪れている。

More patterns to decode

Recent viral articles

Explore more viral articles

クリエイターのために。

𝕏 のバズ記事から企画の種を見つけ、伸びた理由を分解し、次のコンテンツ案に変えましょう。