Andrew Ng氏、DeepLearning.aiをAIエンジニアリングに焦点

「AI エンジニアの台頭」という記事が発表されて以来、どれほどの採用の節目を数えきれないほど経験してきたか、もはや記憶にありません。しかし、Google Brain や Coursera の共同創設者であるアンドリュー・ン氏が、DeepLearning.ai を再始動し、その焦点を「AI エンジニアリング」に置いたことは、間違いなく大きな転換点と言えるでしょう。

この分析は、1 万件以上の求人票の調査や AI の専門家、採用担当者、リクルーターとの数十回にわたる構造化されたインタビューの実施、アンケートによるデータ収集、そして他のオンラインデータの統合といったプロセスを通じて行われました。

アンドリュー・ン氏の原稿をそのまま読むことで、より詳細な知見を得ることができますが、「AI エンジニアリングのスキル」は「AI エンジニア」という肩書きを持つ人々だけでなく、広く他の職種にも応用可能であるという点に、我々は強く同意します。これは非常に洞察に富んだ視点です。

4 つのスキルに関する解説：

AI アプリケーションの構築と展開において重要なのは、LLM（大規模言語モデル）、コンテキストエンジニアリング、RAG（検索拡張生成）、エージェントワークフロー、機械学習、深層学習といった AI の構成要素を理解していることに加え、統計的手法を用いて AI システムを測定・誘導・ガバナンスし、予測可能な挙動を実現する方法を知っていることです。その中核となるスキルは、体系的な評価とエラー分析のループを回せるかどうかです。

これは従来の MLE（機械学習エンジニア）や MLOps のワークフローに最も近い部分で、「ゼログラディエント」と呼ばれるプロンプトエンジニアリング手法から、ハッチャーエンジニアリング、ファインチューニングを経て、ハービーのような事例に見られるような独自のエージェントラボを構築する段階までを含みます。

ソフトウェアエンジニアリングの基礎知識も不可欠です。これにより、存在するトレードオフを認識できるようになり、ソフトウェアスタックの選択やシステムアーキテクチャの設計、データストアの設計、テストなどにおいてより良い判断を下すことができます。また、コーディングエージェントがどのようなトレードオフを行っているかを知りもしないまま「感覚」だけでコードを書く経験不足の開発者よりもはるかに優れた成果を生み出します。なぜなら、彼らはコーディングエージェントに適切な文脈を与えられないため、往々にして不適切な選択をしてしまうからです。

この点も従来の SWE（ソフトウェアエンジニア）のワークフローに最も近い部分です。LLM は専門性を評価し、熟練した開発者の能力上限を大きく引き上げる一方で、初心者の下限も引き上げます。つまり、両者とも向上しますが、その効果は熟練者においてより顕著になります。

コーディングエージェントの活用

「効果的なコーディングエージェントの利用は、現在すべての開発者にとって重要なスキルとなっています。このスキルを身につければ、エージェントがどのように動作するかを理解する適切なメンタルモデルを持つことができます。その限界や回避策も把握し、過度な時間やトークンの浪費を防ぎつつ堅牢なソフトウェアを構築するために、どの程度介入すべきかを見極めながら素早く方向転換できるようになります。

また、明確な仕様書（そしていつそれを無視すべきか）の扱い方や、連携する複数のエージェントを統率する方法、生産環境のデータベースを破損させるリスクのような落とし穴を避ける方法も知っておく必要があります。コーディングエージェントは急速に進化しているため、スキルフルに扱うには最先端の実践法を知るだけでなく、新しいツールを試すルーチンを維持し、ベストプラクティスが変化するにつれてワークフローを進化させ続ける姿勢が求められます。」

2023 年に「1,000 倍の AI エンジニア」について初めて議論した際、当時 Copilot が唯一の選択肢だった時代には、この点は最も見通しが悪く、まだ先のことのように思われていました。しかし、コーディングは 2024 年から 2026 年にかけて爆発的に発展し、Cursor の劇的な成長（0 から 600 億ドルへの急伸）や、Claude Code、Codex、Cognition、Cline など「C」で始まらない新たなコーディングの巨人たちの台頭という頂点に達しました。この分野では、柔軟に対応できることがプラス要因となる一方で、LLM の幻覚現象（ psychosis ）に陥るトークン消費過多のツールへの警戒心も同様に重要です。

構築を形作る。効果的な AI エンジニアリングには、製品感覚とビジネスコンテキスト、顧客の目標を理解することが不可欠です。これにより、プロジェクトの方向性を形作り、推進する役割を果たすことができます。この機会を活かすためには、プロジェクトを前に進める方法を理解している必要があります。例えば、ユーザーにテストしてもらうために MVP を迅速に構築すべきタイミングと、より慎重に構築するために時間をかけるべきタイミングを見極めることが重要です。

これはおそらく、AI エンジニアリングに関する元のエッセイで想定されていなかった部分でしょう。私たちは 2024 年の World's Fair で AI PM（プロダクトマネージャー）トラックを追加し、すぐにデザインエンジニアリングやその他の AIE（AI エンジニアリング）関連領域も加えました。その理由は、両方向の境界線が非常に早く曖昧になり始めたからです。

全体として、DeepLearning.AI の焦点に関する素晴らしいアップデートです。アンドリュー・アン氏とチームにようこそ！

2026 年 8 月 22 日〜24 日の AI ニュース。12 のサブレッド、544 件の Twitter（X）投稿を確認し、Discord は確認していません。AINews のウェブサイトでは過去のすべての号を検索できます。念のためにお知らせしますが、AINews は現在 Latent Space の一部となっています。メール配信の頻度を選択・解除することも可能です。

AI Twitter レビュー

エージェントハーネス、永続的エージェント、およびエンタープライズ MCP

設計の重要性が最適化の主要な対象となりつつあります。複数の投稿で共通して指摘されているのは、エージェントの質は基盤モデルそのものよりも、それを動かす「ハルネス（環境）」によって大きく左右されるという点です。

NVIDIA の新しい評価研究では、エージェントの「スキル」に対する構造的なチェックが実際の有用性をほとんど予測できないことが示されました。具体的には、スキャンスコアと評価された質との相関は Spearman ρ = 0.14 と非常に低く、この指標だけでは不十分です。そこで同研究は、「Skill Lift（スキルの向上幅）」という新たな測定方法を提案しています。これは、同じ条件下でスキルあり・なしの両方でタスクを実行し、完了した作業量の差分をスコアリングする手法です（概要は @omarsar0 による論文サマリー）。

一方、Anthropic 型のハルネスに関する位置づけ論文では、企業は個別に構築されたオーケストレーショングラフではなく、再利用可能な単一のコーディングエージェント用ハルネスに標準化すべきだと主張しています。その理由として、企業向けワークロードにおいては「モデルの選択」よりも「ハルネスの選択」の方が重要になる場合があると指摘されています（概要は @dair_ai による）。

永続的で自己改変可能なエージェントが、概念段階からオープンソースの実装へと移行しています。@andykonwinski は、リクエストに応答するだけでなく継続的に思考する永続型エージェント向けのオープンソース「マイクロハルネス」である Headlong を紹介しました。このシステムは、経路を jsonl ファイルの DAG（有向非巡回グラフ）として保存し、自己誘導型の内部ループを常時稼働させます。報告によると、48 分間で無人による自己デバッグと修復を実現しましたが、背景で思考を続けるためのコストが時間あたり 1〜2 ドルかかることや、偶発的な自己起因の失敗が発生する可能性といったトレードオフも存在します。

これに続く形で、@omarsar0 は再帰的自改善のためのハルネスアーキテクチャ「exo」を紹介しました。これは追加のみで記録されるイベントログ、交換可能なエグゼキューター、スナップショットとロールバックが可能なサンドボックスを備えています。エージェントがプロンプトやツール、メモリを書き換えても永続的な状態を破損できないように、意図的に設計されています。

これらの投稿は、次世代のエージェントインフラが単なるプロンプトの改善ではなく、耐久性、フォーク機能、ロールバック、そして継続的な運用に焦点を当てていることを示唆しています。

MCP は企業インフラとしての成熟を遂げつつあります。Anthropic が MCP コネクタ向けに企業管理型認証を導入し、組織の ID プロバイダーを通じて権限付与を一元的に管理することで、エンドユーザーは Asana、Atlassian、Canva、Datadog、Figma、Notion、Slack、Supabase といったコネクタごとに個別に OAuth を実行する必要がなくなりました（@ClaudeDevs の発表）。また、MCP ロードマップでは、ストリーミングやサーバープッシュによる長時間実行ワークロードのサポート、ローカルサーバー向けの HTTP プロトコル、大規模カタログ用の段階的検出機能、標準的なアイデンティティと委任された権限の対応が今後の予定として明記されています（@_philschmid によるロードマップ要約）。これにより、おもちゃのようなデモと監査可能な企業展開の間にある大きなギャップが埋められました。

モデルリリース、リーク、競争優位性

Qwen3.8-27B はそのサイズクラスを遥かに凌駕する性能を発揮し続けています。Code Arena の WebDev ベンチマークでは総合 9 位（1595 ポイント）を獲得し、同サイズクラスのモデルの中でトップ 10 にランクインしたのは Qwen3.8-27B だけでした。上位の Qwen3.8-Max とはわずか 6 つの順位差です（@arena によるリーダーボード更新）。また、消費者向け製品、ブランド/マーケティング、ゲームのカテゴリーでも高い評価を得ています。

関連するオープンソース派生モデルとして、Carnice-V3-27B が @kaiostephens によってリリースされました。これは 27B パラメータの Qwen ベースで、Hermes-agent の SFT（Supervised Fine-Tuning）を施したもので、消費者向け GPU（RTX 3090 以上など）に収まるよう設計されています。BF16 と GGUF の両方のバリアントがマージされた形で提供されます。

未発表の最先端モデルに関する噂のサイクルが激化しています。複数のツイートで、未発表システムの早期アクセスや痕跡が示唆されました。特に「claude-melon-eap」や「claude-marshmallow-eap」と名付けられた EAP モデルは、3D や RL スタイルのタスクに重点を置き、思考トークンを多数使用しているとのことです（@Lentils80 によるデモ）。また、@kimmonismus は新しい Claude モデル、Ox Alpha、Qwen 4、そして確認された GPT Astra の兆候を集め、@eliebakouch はトレーニング中のモデルにアクセスできると主張し、そのパブリックな W&B ランを示しました。これらは検証済みの仕様として扱うのではなく、エコシステムからのシグナルと捉えるべきですが、注目すべきは、現在の議論の中心が公開リリースではなく「未発表モデルへのアクセス非対称性」に移っている点です。これは @michael_nielsen の警告を彷彿とさせます。つまり、未発表モデルへのアクセスを制御することが、権力の集中化につながる恐れがあるという指摘です。

OpenAI と Anthropic の立ち位置は依然として流動的です。OpenAI の開発者は、Kiro 環境における GPT-5.6 の利用可能性を発表しました。この Kiro の仕様駆動型環境では、Terra バリアントが Terminal-Bench 2.1 タスクを成功させる際のコストが約 82% 削減されるとされています（発表）。また、OpenAI は GPT-5.6 Sol API の価格を、入力トークンあたり 4 ドル、出力トークンあたり 20 ドルに引き下げました（@kimmonismus 経由の価格情報）。Arena の更新データでは、Sol と Luna がコストとパフォーマンスのパレートフロンティアをシフトさせていることが示されています (@arena)。一方 Anthropic 側では、@tenobrus が指摘するように、過去 6 ヶ月以上明確な Opus ラインのアップグレードは行われていません。外部テスターが新しい Claude バリアントから中程度の推論結果でより強力な性能を示したと報告しているにもかかわらずです（@kimmonismus）。

推論、ベンチマーク、コスト効率

ツールレイテンシの重なりが、ハイレベルでの速度向上の鍵として浮上しています。@a1zhang が提案した「Speculative Programmatic Tool Calling (sPTC)」では、コード生成中に安全なツールの呼び出しを予測し、環境のコピーで早期に実行を開始することで、トークン生成と並行して実行できるようにします。現時点での報告では改善幅は modest（約 1.0–1.2 倍）ですが、この仕組み自体が重要です。これは、トークンレベルのデコーディング技術への最適化から、エージェントワークフローのパイプライン化へと焦点を移すものです。

@lateinteraction はこれを CPU の予測実行に例え、多くの推測が当たっていれば、外れた作業は許容されると強調しています。

トークンの集計とベンチマークの衛生管理はまだ混乱した状態です。複数の投稿で、誤解を招く報告慣行が指摘されました。@bnjmn_marie は DeepSWE の実行結果（入力トークン数 918.9M）を共有し、その多くはキャッシュヒットだったと明確にしました。一方、@cHHillee は「キャッシュされた入力トークンを『トークン使用量』に含めるのは信じられないほど愚かだ」と断言しています。

評価の側では、@jmbollenbacher が警告します。量子化モデルがベンチマークで参照モデルを上回る場合、それは量子化への過学習を示している可能性があり、真の改善ではないかもしれません。@xeophon はこの教訓を要約し、「ベンチマークを最適化するよりも、評価自体を修正する方が重要である」と述べています。

コスト正規化されたエージェントベンチマークが、モデル選定の基準を再び書き換えています。Together AI の報告によると、100 ドルの予算内で GLM-5.3 は DeepSWE において Fable 5 よりも約 5 倍の作業量を完了しました（それぞれ約 17 件と 3 件のタスク解決）。両者の初回成功率は似ていましたが、この差は明確です。

@reach_vb も同様に、GPT-5.6 Sol Max が DeepSWE v1.1 で 72.7% のスコアを記録した一方、Fable 5 Max は 69.7% と報告しました。コスト面では、前者が 1 タスクあたり約 6.47 ドルに対し、後者は約 21.63 ドルと大きな開きがあります。

Cline も実際のバグ修正タスクで Ox Alpha と Fable を比較し、両者とも解決に成功したものの、Ox は出力トークン数が約 3 分の少なかったことを示しました。これは、最初の結論に基づいて即座に行動するのではなく、再検証を重視するといった、後処理における哲学的な違いが反映された結果と考えられます。

オンデバイス AI と推論システム

Liquid AI と Artificial Analysis が、本格的なオンデバイスベンチマークスタックを発表しました。@liquidai は「Pipette」というオープンソースの評価スイートをリリースし、モデル・量子化・ランタイム・デバイスの組み合わせにおける品質、速度、レイテンシ、メモリ使用量を測定するものです。35 種類のモデルクラス、7 つの量子化手法、llama.cpp ランタイム、4 種類のデバイスにまたがる 1 万件以上の検証済み結果が含まれています。

Artificial Analysis はこれに加え、iPhone 17 Pro と Galaxy S26 Ultra を用いた独立したスマートフォン規模での知能評価も実施しました。

Phone-scale results highlight a different Pareto frontier than cloud evals: Under an 8 GB memory / 16K context framing, Nanbeige4.2-3B and LFM2.5-2.6B topped the average score at 63, with LFM2.5-2.6B much more efficient on iPhone (8.0s, 2.3 GB) than Nanbeige (21.4s, 4.0 GB). MoE designs such as LFM2.5-8B-A1B and Ling 3.0 Tiny are notable because they activate ~1B parameters/token, enabling sub-6-second responses on phone hardware. The evaluation also makes explicit that many "smart" reasoning models are poorly matched to mobile memory and latency constraints.

Inference vendors are competing on agent-specific throughput, not just raw TPS: NVIDIA's Groq 3 LPX was described as adding a dedicated token-generation accelerator to Vera Rubin, with a claimed 3,400 output tokens/s on Gemma 4 31B at 100K context in Artificial Analysis benchmarking (summary via @kimmonismus); Groq said it will be among the first to deploy it in production (announcement). Separately, vLLM published extensive AgentX 1.0 results on real multi-turn coding traces, emphasizing KV offload, prefix reuse, and prefill/decode disaggregation as the keys to high agentic throughput rather than classic single-turn serving metrics (@vllm_project).

Research, Papers, and Technical Education

LLM に対する強化学習と、Harness ネイティブなトレーニングは依然として注目されています。@cwolferesearch が公開した包括的な強化学習ガイドでは、トークンレベルと完了レベルの定式化の違い、PPO や GRPO のバリエーション、アクター・クリティック手法、ルブリックベースの RL、そしてエージェント型 RL や世界モデルについて解説しています。

これに呼応して、「Harness ネイティブ」な RL やエージェント環境への関心も高まっており、@TheTuringPost による論文まとめや、Agent Lightning、LEGO-RL、EnvHarness、SkillGate といった論文に関する議論がその表れです。

その他注目すべき研究動向として、Meta と USC が共同で開発した「Periodic Row-wise Muon」があります。これは高価なニュートン・シュルツ更新を近似処理することで計算コストを抑えつつ、AdamW を上回る性能維持を実現し、大規模な拡散トランスフォーマーへの最適化手法として拡張されたものです（概要は @iScienceLuvr 経由）。また Adobe の「Latent Dynamics Reasoning」は、直接未来を予測するのではなく潜在状態の進化をモデル化することで、ピクセルから外挿的な動画世界モデルを学習します（論文は @_akhaliq 経由、著者ノートあり）。さらに Cartwheel は、人間動作生成における計算最適スケーリング則を発表しました。Chinchilla 法のようなスケーリング挙動を示すことから、動作が第五のモダリティとなる可能性を指摘しています（ローンチ情報）。

保存すべき教育コンテンツもいくつかあります。@fchollet は『Deep Learning with Python』の第 15〜16 章を、ドット積アテンションがなぜ機能するのかを最も分かりやすく解説した箇所として推奨しました。@ProfTomYeh は自己回帰アテンションの手計算による詳細な手順を公開しています。また @mervenoyann は llama.cpp のドキュメントの新たなホスト先を発表し、今後推測的デコーディング、量子化、コーディングエージェントに関する資料が追加される予定です。

注目すべきツイート（エンゲージメント順）

製品・UI パフォーマンスの実践：Anthropic は、Claude の Web およびデスクトップ版での長文回答が約 4 倍スムーズにストリーミングされ、ストール回数が 9 分の 1 に減り、低速なノート PC でも最悪のフリーズ時間が 4.5 倍短縮されたことを発表しました。

高速画像生成 UX：@samdape は、GPT の画像生成をより速く描画するための手法を紹介しました。

OpenAI の研究文化：@gdb は、フルデュプレックスモデルのような長期的な賭けを継続する OpenAI の姿勢を称賛した @kundan2510 氏の投稿を拡散しました。

学習リソース：@fchollet が『Deep Learning with Python』の注意機構（Attention）に関する章を推奨したのは、今回のセットの中で最も示唆に富む教育ポストの一つでした。

エンタープライズ MCP：Anthropic のエンタープライズ向け管理認証機能を持つ MCP コネクタは、本番環境でのエージェント展開における最も重要なプラットフォームアップデートの一つです。

AI Reddit まとめ

/r/LocalLlama と /r/localLLM のまとめ

1. Qwen 3.8 27B のコーディングおよび量子化ベンチマーク

「Qwen 3.8 は Opus レベルではない」という主張について、私はテストを再実行しました（アクティビティ：911）。提示された画像は、C#/OpenGL の海洋レンダリングタスクにおいて、qwen3.8-27b を「Plan」モードで使用し、Deepseek/pi.dev 風のコーディングハネスを採用した様子を示しています。これは、ハネスの質がモデルの実装能力に大きく影響するという投稿の主張を裏付けるものです。

著者の再実行では、同じ Qwen3.8 モデルとプロンプトを用いても、VS Code Copilot 環境下では黒い画面が表示されるだけで失敗しましたが、代替のハネスを使用すると成功しました。このハネスはスクリーンショットフィードバックを活用し、ビジュアル機能がオフになっている状況でも PNG デコーダーを生成してしまいました。結果として、RTX 5090 で動作する ninfer-nvfp4 ビルド（コンテキストサイズ約 190k、トークン生成速度 150〜180 tok/s）上で、波や空、太陽、水中の景色が約 1 時間で描画されました。

コメント欄では、この結果が「怠惰」なサンドボックス型ハネスと、実行機能やスクリーンショットフィードバックを備えたエージェント型ハネスとの間に大きな差があることを示していると、ほぼ一致して評価されています。Qwen3.8 に対する元々の批判者は、自身の以前の結論が誤りだったことを認め、pi.dev を用いた再テストを開始しました。その結果、VS Code や BYOM（Bring Your Own Model）と llama.cpp の組み合わせに比べて、クラッシュの頻度が少なく、メモリ使用量も低いことが確認されています。

議論の重要な技術的テーマは、「ハネスの質がモデル能力の評価を支配しうる」という点です。コメント投稿者たちは、Qwen 3.8 が実行環境の初期設定ミスや制限にもかかわらず、動的に PNG デコーダーを実装して動作する海洋シェーダーを生成したことを指摘しました。この議論は、適切なランタイムやテストループが与えられた場合、Copilot 型のサンドボックス環境ではコーディングエージェントの真の実力が過小評価されている可能性を示す証拠として捉えられています。

あるテスターは、以前の検証環境が不十分だと認めた後、VS Code と BYOM（Bring Your Own Model）で llama.cpp を使う構成から pi.dev へ移行しました。この VS Code 設定では、2 つの具体的な問題が発生しています。1 つ目はテスト実行ファイルを起動した後のドライバエラーです。2 つ目は、Lemonade SDK からビルドされた llama.cpp の RocM 1200 ビルドが出力エラーなしで継続して動作している最中に、VS Code がランダムにクラッシュする現象です。一方、pi.dev はクラッシュせず、明らかに少ないメモリ使用量でした。

複数のコメント投稿者が、pi.dev/OhMyPi や opencode、ローカルの llama.cpp 設定といったエージェント検証環境を比較しました。彼らの関心は、標準的な Claude 風のチャットワークフローを超えて、これらの検証環境がどの程度の自律性を提供できるかという点にあります。ハードウェアの制約についても議論があり、ユーザーたちは RTX 5090 や同等の高性能なローカル GPU 環境（Ninfer などのツールを併用する場合もある）であれば、クラウドサブスクリプションなしでもローカルでのエージェント型コーディングワークフローが実用的になる可能性があると推測しています。

Qwen3.8:27b の新リリースに関する 39,000 行の C プログラムを単一ファイルの HTML/Three.js へ移植するベンチマークの結果（アクティビティ数：655）

1 つの試みで、2.1 MB / 39,000 行 / 約 60 万トークン規模の C 言語製シングルファイル・シューティングゲームを、単一ファイルの HTML/Three.js へ移植する「ワンショットエージェント」ベンチマークが行われました。ただし、ソースコードは利用可能な 262,144 トークンのコンテキストサイズを 2 倍以上も超えていました。

RTX 6000 Pro（96GB）上で vLLM を使用し、FP8 重みと FP8 KV キャッシュを有効にした環境では、Claude Code + Opus 5 が 21 分間で唯一「まあまあの」移植結果を出しました（1,759 LOC）。一方、qwen3.8:27b は Hermes を経由して 4 時間 18 分、CodeHammr（リポジトリ）を経由して 1 時間 40 分かかりました。どちらも 1,056 LOC と 949 LOC の結果でしたが、「悪い」と評価されました。

コメント欄では、「このコードを変換してください」という直接的なプロンプトは、モデルが挙動を勝手に再解釈してしまう原因になると指摘されています。より確実なパイプラインとしては、まずトランスパイラー（言語変換ツール）を生成して実行可能なターゲット言語の出力を得た上で、高レベルのピクセル比較や低レベルのレジスタ・状態参照に基づき、関数単位で反復的に書き直す手法が提案されています。

技術的な議論では、ローカルでの結果が悪かった原因が、プロンプトやハッチャー設計の問題か、分解やテストの欠如か、あるいは推論設定の不備のいずれにあるかが焦点となりました。複数のコメント投稿者は、FP8 KV キャッシュ量子化が長文コンテキスト性能を著しく低下させる可能性があると警告し、これを無効にして再実行するよう推奨しています。

一方で、壁時計での時間差は当然であり、Anthropic はより多くのハードウェアで並列処理が可能だと指摘する声もあります。その代わりとして、vLLM のトークン/秒を測定すること、移植前に計画を立てること、巨大な C ファイルをモジュールに分割すること、そして移植前に振る舞いテストを追加することを推奨しています。

複数のコメント投稿者が、コードベース全体を「変換せよ」というプロンプトは、最先端モデルであってもソースの動作を維持するのではなく、モデルがソースを再解釈してしまう可能性があると指摘しました。提案されたワークフローでは、まずモデルにターゲット言語向けのトランスパイラー作成を手伝わせ、その後、高レベルのピクセル比較や低レベルのレジスタ・値トレースに対して検証しながら関数単位で反復的に書き換えを行い、ピクセル単位の完全な等価性を達成するというものです。

複数のコメントでは推論設定について疑問が呈されました。具体的には FP8 KV キャッシュ量子化、Q8、および t の実行に関する問題です。