Thoughtworks Technology Radar Vol.34 公開

 (thoughtworks.com)
12 ポイント 投稿者 GN⁺ 13 일 전 | まだコメントはありません。 | WhatsAppで共有
  • テクニック/ツール/プラットフォーム/開発言語およびフレームワーク 分野の最新トレンドを「導入推奨、試験導入、評価、注意」の4段階で可視化・解説
  • 主要テーマ4つ: エージェント時代と技術評価、原則は維持しつつパターンを見直す、エージェントのセキュリティ問題、コーディングエージェントハーネス

エージェント時代と技術評価の難題

  • AI導入により技術評価そのものが難しくなっており、セマンティック拡散（semantic diffusion） によって意味が安定する前に新しい用語が急速に登場
    • spec-driven development、harness engineering などの用語が一貫性なく使われたり、意味が重なったりしている
    • 共有された定義がないため、別個の手法なのか同じ概念の別名なのか判断しにくい
  • 成熟した独立のエンジニアリング手法と、コーディングアシスタントのような AIツールの日常的利用 を区別することが継続的な難題
  • 変化の速さが不確実性を増幅し、登場から1か月も経っていないツール が多数現れ、その一部は単一の貢献者がコーディングエージェントとともに保守している形態
    • ツールの成熟を待てばガイドは古くなり、早く動けばすぐ消えるトレンドを強調してしまう危険がある
    • 速く少ない労力で作られるものの 持続可能性 に疑問が投げかけられている
  • コードベース認知負債（Codebase Cognitive Debt）
    • AI生成コードが増えるほど、動作原理に関するメンタルモデルなしに ソリューションを採用しやすくなる
    • この理解ギャップが蓄積すると、システムの推論・デバッグ・発展が難しくなる

原則は維持しつつパターンを見直す

  • AIは未来の話だけでなく、ソフトウェアクラフトマンシップの基礎 をあらためて見直させている
    • ペアプログラミング、ゼロトラストアーキテクチャ、ミューテーションテスティング、DORAメトリクスなど既存手法を再評価
    • クリーンコード、意図的な設計、テスト容易性、アクセシビリティなど中核原則を第一級の関心事として再確認
  • これはノスタルジーではなく、AIツールが複雑性を素早く生み出す速度に対抗する 不可欠な釣り合いの重り の役割を果たす
  • コマンドラインの復権。何年にもわたり使いやすさのために抽象化されてきたが、agentic なツールが開発者をターミナルへ呼び戻している
  • AI支援開発はエンジニアリング実践の根本的転換であり、コラボレーションとチーム構造の再考が必要
    • agent topologies を team topologies と並べて検討し、フィードバックサイクルを再設計する必要がある
    • measuring collaboration quality with coding agents のような手法が、ソフトウェア開発者の定義そのものを再規定している
  • AI主導環境では 認知負債の管理 が中核課題であり、「規律のない速度はコストを増大させる」という原則を保つことが重要

権限を求めるエージェントのセキュリティ問題

  • "Permission hungry" は現在のエージェント状況の本質的ジレンマを描写しており、価値のあるエージェントほどあらゆるものへのアクセスを必要とする
    • OpenClaw、Claude Cowork は実業務を監督
    • Gas Town はコードベース全体にわたってエージェントスウォームを調整
    • 私的データ、外部通信、実システムに対する広範なアクセスを要求
  • 安全装置がこの野心に追いついていない状態で、プロンプトインジェクションによりモデルは 信頼された命令と信頼されていない入力を安定して区別できない
  • Simon Willison の "lethal trifecta" の定義 — 私的データ、信頼されていないコンテンツ、外部アクション — は、設定ミスではなく デフォルトとして ほとんどの有用なエージェントに当てはまる
  • インジェクション以外の脅威もあり、モデル動作の不整合がある
    • 一度成功した作業が次回も成功する保証はない
    • エージェントは悪意がなくても 創造的な流出経路 を見つけたり、触れてはいけないブランチに push したり、承認/拒否チェックポイントを無力化したりする
  • 現在対処可能なこととして、ゼロトラスト、最小権限、モデル改善、多層防御が基本条件だが、単一の解決策はない
  • 安全なエージェントシステムはモノリシックなエージェントではなく、より制約の強いエージェントのパイプライン と強力な監視・制御で構成する必要がある
    • Agent Skills を MCP の制御可能な代替として活用
    • durable agents、agent instruction bloat 防止手法などがこの方向性を示している
  • この領域は急速に進化しているため、コストの高いミスの回避 のために慎重さが不可欠

コーディングエージェントに手綱をつける

  • コーディングエージェントの性能向上により、人間をループから外したくなる誘惑が増しており、そのためチームは coding agent harnesses への投資を始めている
    • コード生成前にエージェントの振る舞いを誘導し、その後のフィードバックによって自己修正できるようにする制御装置
  • Feedforward 制御
    • エージェントが 最初の試行で正解する確率 を高めるため、必要なものを事前に提供
    • Agent Skills が主要な進展であり、指示と慣例をモジュール化して必要なタイミングで読み込む
    • Superpowers はソフトウェアチーム向けの有用なスキルカタログの例
    • plugin marketplaces という概念が台頭し、スキルとコンテキスト構成の配布を容易にしている
    • spec-driven development フレームワーク — GitHub Spec-Kit、OpenSpec など — が計画・設計・実装ワークフローを構造化
  • Feedback 制御
    • エージェントの行動後に観察し、自己修正ループを作る
    • feedback sensors for coding agents — コンパイラ、リンター、型チェッカー、テストスイートのような 決定論的品質ゲート をエージェントワークフローに直接統合
      • 失敗時には人間のレビュー前に自動修正をトリガー
    • 今回の Radar の例として cargo-mutants とミューテーションテスティングツール、WuppieFuzz のようなファズテスティングツール、CodeScene などのコード品質分析ツールを含む
    • インループのフィードバックに加え、決定論的な構造ルールと LLMベース評価 を組み合わせてアーキテクチャドリフトを減らした事例もある

[Techniques]

Adopt

1. Context engineering

  • 現代のAIシステムにおける中核的なアーキテクチャ関心事へと進化した手法で、プロンプトエンジニアリングが文言に集中するのに対し、コンテキストウィンドウを設計対象として扱い、AIの情報環境を意図的に構築する
  • エージェントが複雑なタスクを処理するほど、大きなコンテキストウィンドウに生データを流し込む方式は "context rot" と推論低下を招き、静的でモノリシックなプロンプトから progressive context disclosure への移行が進んでいる
  • Context setup では prompt caching によって静的な指示を先読みしてコストを削減し初回トークンまでの時間を改善し、Dynamic retrieval では基本的な RAG を超えて ツール選択 と必要な MCP サーバーのみをロードする
  • Context graphs はポリシー、例外、先例などの組織的推論を構造化・クエリ可能なデータとしてモデル化し、stateful compression とサブエージェントで長期ワークフローの中間出力を要約する
  • AIコンテキストを静的なテキストボックスとして扱うことは幻覚への近道であり、堅牢なエンタープライズエージェントを構築するには、コンテキストを動的かつ精密に管理されたパイプラインとしてエンジニアリングする必要がある

2. ソフトウェアチーム向けにキュレーションされた共有指示

  • 個々の開発者が最初からプロンプトを書くことをアンチパターンとみなし、AIガイダンスを個人のワークフローではなく協業のためのエンジニアリング資産として扱う実践
  • 当初は共通作業向けの汎用プロンプトライブラリの維持に注力していたが、現在ではサービステンプレートに直接指示をアンカーする進化した方式へと発展
    • CLAUDE.md、AGENTS.md、.cursorrules のような指示ファイルを、新しいサービスのスキャフォールディング用ベースラインリポジトリに配置
  • コーディングエージェントをリファレンスアプリケーションにアンカーする関連実践も模索しており、生きたコンパイル可能なコードベースが単一の信頼できる情報源として機能
  • アーキテクチャやコーディング標準が進化した際には、リファレンスアプリと埋め込み指示の両方を更新でき、新しいリポジトリは最新のエージェントワークフローとルールをデフォルトで継承

3. DORA metrics

  • DORA研究プログラムが定義したメトリクスで、変更リードタイム、デプロイ頻度、MTTR、変更失敗率、そして新たな5つ目のメトリクスであるrework rateを含む
  • Rework rate は安定性メトリクスで、チームのデリバリーパイプラインがユーザーバグや不具合などの完了済み作業のやり直しに費やされる割合を測定
  • AI支援開発の時代において、DORAメトリクスはこれまで以上に重要であり、AIが生成したコード行数で生産性を測定することは誤解を招く
    • リードタイムの短縮とデプロイ頻度の増加がなければ、コード生成の高速化はより良い結果につながらない
    • 安定性メトリクス、とりわけ rework rate の低下は、無分別なAI支援開発における盲点・技術的負債・リスクへの早期警告となる
  • 複雑なダッシュボードを構築するより、レトロスペクティブ中のチェックインのような単純なメカニズムの方が能力改善に効果的

4. Passkeys

  • FIDO Alliance が主導し、Apple、Google、Microsoft が支援する FIDO2 認証情報で、非対称公開鍵暗号を用いてパスワードを置き換える
  • 秘密鍵はユーザー端末のハードウェアベースのセキュアエンクレーブに保存され、生体認証や PIN で保護されて外部に漏えいせず、各認証情報は relying party ドメインにオリジンバインドされるため、構造的にフィッシング耐性を持つ
  • フィッシングはデータ侵害全体の3分の1超の原因であり、FIDO Alliance Passkey Index 2025 では世界で150億超の対象アカウントが報告され、Google は8億ユーザー全体でログイン成功率を30%改善、Amazon は従来方式比で6倍高速なログイン確認を実現
  • NIST SP 800-63-4（2025年7月）は synced passkeys を AAL2 準拠として再分類し、UAE・インド・米国連邦機関の規制当局は金融・政府システムにフィッシング耐性のある認証を義務付け
  • FIDO Credential Exchange Protocol により認証情報マネージャー間の安全な移植性を確保し、Auth0・Okta・Azure AD など主要IDプロバイダーがファーストクラス機能としてサポート、実装は数か月規模の作業から2スプリントのプロジェクトへと単純化
    • アカウント復旧の設計には注意し、SMS OTP のようなフィッシング可能なフォールバック経路は避ける必要がある
    • AAL3 シナリオ（特権アクセスなど）では、ハードウェアセキュリティキーのデバイスバインド認証情報が依然として必要

5. LLMからの構造化出力

  • モデルが JSON や特定のプログラミング言語のクラスのような事前定義された形式で応答するよう制約する実践
  • 本番環境で信頼できる結果を提供し、LLMの応答をプログラム的に消費するアプリケーションにおける合理的なデフォルトとみなされる
  • 主要なモデルプロバイダーはすべてネイティブな構造化出力モードを提供しているが、サポートする JSON Schema のサブセットは異なり、API は急速に進化している
  • Instructor ライブラリや Pydantic AI フレームワークは、検証と自動リトライを含む堅牢な抽象化を提供し、セルフホストモデルで制約付き生成を行うには Outlines を推奨

6. Zero trust architecture

  • エージェント時代への移行に伴い、予測不能なシステムに自律性を与える際のセキュリティリスクに対処するための合理的なデフォルト
  • 「決して信頼せず、常に検証する」、アイデンティティベースのセキュリティ、最小権限アクセスの原則をすべてのエージェント配備の基盤として扱う
  • SPIFFE のような標準をエージェントに適用して強力なアイデンティティ基盤を構築し、動的環境で細粒度の認証を有効化
  • エージェントの動作を継続的に監視・検証することが、脅威の先回り管理に重要
  • エージェント配備に限らず、GCP の OIDC impersonation のような実践を CI/CD パイプライン などにも導入し、長期の静的キーを、アイデンティティ検証後に発行される短期トークンへ置き換える
  • 構築システムに関係なく ZTA の原則を交渉不可能なデフォルトとして扱うことを推奨

Trial

7. Agent Skills

  • AIエージェントが単純なチャットインターフェースから自律的な作業実行へ進化する中で、コンテキストエンジニアリングが重要課題となっており、Agent Skills は指示、実行可能スクリプト、ドキュメントなどの関連リソースをパッケージ化して、コンテキストのモジュール化に向けたオープン標準を提供
  • エージェントは説明に基づいて必要なときだけスキルを読み込み、トークン消費を減らすとともに、コンテキストウィンドウの枯渇や agent instruction bloat の問題を緩和
  • コーディングエージェントだけでなく、OpenClaw のようなパーソナルアシスタントにも急速に採用されており、多くのユースケースはローカルCLIやスクリプトをエージェントに参照させることで効果的に解決できるため、チームがMCPの標準利用に慎重になる理由の一つにもなっている
  • Plugin marketplaces が、スキルをバージョン管理・共有する方法として台頭しており、スキルの有効性を評価する方法の探索も数多く進められている
  • サードパーティ製スキルをレビューなしに再利用すると、深刻なサプライチェーンセキュリティリスクを引き起こすため注意が必要

8. ブラウザベースのコンポーネントテスト

  • 以前はブラウザベースのツールを推奨していなかったが（設定が難しく、遅く、flaky だったため）、現在は大幅に改善されており、Playwright のようなツールによる実行可能で望ましいアプローチとなっている
  • 実際のブラウザでテストを実行すると、コードが実際に動作する環境と一致するため、より高い一貫性が得られる
  • 性能低下は許容できる水準まで減少し、flakiness も減って、jsdom のようなエミュレート環境よりも大きな価値を提供

9. コーディングエージェント向けフィードバックセンサー

  • コーディングエージェントをより効果的にし、人間のレビュアーの負担を減らすには、エージェント自身が直接アクセスできるフィードバックループが必要であり、フィードバックは backpressure の形で機能する
  • 開発者は長年、コンパイラ、リンター、アーキテクチャテスト、テストスイートのような決定論的な品質ゲートに依存してきており、これを agentic なワークフローにつなげることで、失敗時に適時の自己修正をトリガーできる
  • チェック実行と修正トリガーを担うレビュワーエージェントを導入したり、並列実行される伴走プロセスとしてチェックを公開したりと、さまざまな実装が可能
  • コーディングエージェントのおかげでカスタムリンターやアーキテクチャテストの構築コストが下がり、フィードバックループを強化しやすくなった
  • 可能であればコミット後のチェックではなくコーディングセッション中に実行し、コミット前にクリーンな結果を報告させること

10. コードスメルをリファクタリング手法にマッピングすること

  • エージェントに定義済みのアプローチで特定の課題を処理するよう指示する手法
  • 第1レイヤーでは一般的なケース向けに Refactoring のような一般的な参照先でエージェントを導き、より専門的な課題については Agent Skills、スラッシュコマンド、AGENTS.md を使って固有の smell を特定の手法にマッピングする
  • リンティングツールと統合すると、smell が検出されるたびに適切なリファクタリングアプローチをトリガーする決定論的フィードバックを生成できる
  • .NET Framework 2.0 や Java 8 のようなレガシースタックで特に効果的で、一般的な訓練データが不足している場合に有用
  • 目標を明示した指示がないと、エージェントは特定の要件ではなく一般的なパターンへとデフォルトしがちである

11. ミューテーションテスト

  • テストスイートの実際の欠陥検出能力の評価において最も正直なシグナルであり、行の実行だけを追跡する従来のコードカバレッジとは異なり、ソースコードに**意図的なバグ（mutations）**を導入して、その動作の破壊時にテストが失敗するかを検証する
  • 変異が検出されない場合、それは単なるカバレッジ不足ではなく検証のギャップを示しており、AI支援開発の時代には特に重要である。高いカバレッジが、論理的に空虚なテストや意味のあるアサーションが行われていない生成コードを覆い隠してしまう可能性がある
  • AI生成のテストケースが一般化する中で、欠落したアサーションや分離された mock によってロジック変更とは無関係に通過してしまう**「永遠にグリーンな（perpetually green）」テスト**を見つけ出す強化レイヤーとして機能する
  • Stryker、Pitest、cargo-mutants のようなツールにより、コアドメインロジックにおいてどれだけのコードが実際に検証されているかへと焦点を移せる

12. 段階的なコンテキスト開示

  • Context engineering の実践における手法であり、エージェントに指示を先回りして過剰に与えるのではなく、ユーザープロンプトに基づいて必要なものを選択する軽量なディスカバリー段階を与える
  • RAG シナリオに適しており、エージェントがまずユーザークエリから関連ドメインを識別し、その後で特定の指示とデータ検索を行う
  • 多くの agentic コーディングツールにおける Agent Skills の処理方法と同じで、条件と注意事項だらけの単一のモノリシックな指示セットの代わりに、まず作業に関連するスキルを決定してから詳細な指示を読み込む
  • agentic システムを構築する際には、終わりのない「DO」と「DO NOT」のルールで 指示を膨らませる罠 に陥りやすく、最終的には性能低下につながる
  • コンテキストウィンドウを簡潔に保ち、context rot を防ぐ

13. コーディングエージェントのためのサンドボックス実行

  • 制限されたファイルシステムアクセス、制御されたネットワーク接続、制限付きのリソース使用によって、隔離された環境内でエージェントを実行する実践
  • コーディングエージェントがコード実行・ビルド・ファイルシステム操作の自律性を得るにつれ、無制限のアクセスは偶発的な損傷から認証情報の漏えいに至るまで現実的なリスクをもたらすため、選択的な強化ではなく合理的なデフォルトである
  • サンドボックス化の選択肢の幅は広く、多くのコーディングエージェントが組み込みのサンドボックスモードを提供し、Dev Containers はなじみ深いコンテナベースの隔離を提供する
  • Shuru は実行のたびにリセットされる使い捨てのマイクロVMを起動し、Sprites はチェックポイント／リストアをサポートする状態保持型環境を提供する
  • Linux ネイティブの隔離には Bubblewrap が軽量な名前空間ベースのサンドボックスを提供し、macOS では sandbox-exec が同様の保護を提供する
  • 基本的な隔離に加えて、ビルド・テストに必要なすべてのもの、GitHub やモデルプロバイダーのようなサービスとの安全で簡単な認証、ポートフォワーディング、十分な CPU・メモリも考慮する必要がある
  • サンドボックスを使い捨てのデフォルトにするか、セッション復旧のために永続化するかは、セキュリティ・コスト・ワークフロー継続性の優先順位に応じた設計判断となる

14. セマンティックレイヤー

  • データストアと、BI ツール、AI エージェント、API などの消費側アプリケーションの間に共有されたビジネスロジックのレイヤーを導入するデータアーキテクチャ手法
  • メトリクス定義、結合、アクセスルール、ビジネス用語を一元化して消費側が共有定義を持てるようにするもので、モダンデータスタック以前からある概念だが、metrics stores のようなコードファーストのアプローチによって再び注目されている
  • セマンティックレイヤーがないと、ビジネスロジックはアドホックなウェアハウステーブル、ダッシュボード、下流アプリケーション全体に散在し、メトリクス定義は静かに分岐していく
  • agentic AI によって問題はさらに深刻化し、LLM による安易な text-to-SQL 変換では、特に収益認識のようなビジネスルールがスキーマの外側にある場合、誤った結果が頻発する
  • クラウドプラットフォームはセマンティックレイヤーを直接埋め込みつつあり、Snowflake は Semantic Views、Databricks は Metric Views と呼び、dbt MetricFlow や Cube のような独立系ツールはシステム全体で移植可能なレイヤーを提供する
  • Open Semantic Interchange (OSI) v1.0 が最近リリースされ、複数ベンダー の支援により、分析・AI・BI プラットフォーム全体で標準化と相互運用性が広がる兆しを示している
  • 主なコストは先行するデータモデリング投資であり、エンタープライズ全体への展開よりも単一ドメインから始めることが推奨される

15. サーバー駆動UI

  • レンダリングを汎用コンテナから切り離し、サーバー経由で構造とデータを提供することで、モバイルチームは反復ごとに長いアプリストア審査サイクルを回避できる
  • JSON ベースの形式によってリアルタイム更新を可能にし、リリース時間を大幅に改善する。Airbnb や Lyft のような企業で安定したパターンが現れたことで、複雑さも軽減された
  • 以前は独自フレームワークが生み出しうる「ひどく、過度に構成可能な混乱」を招くと警告されていたが、大規模アプリケーションでは投資を正当化しやすくなっている
  • それでもなお、強いビジネスケースと節度あるエンジニアリングが必要であり、保守困難な**「神プロトコル（god-protocol）」**の生成を避けることが重要
  • アプリケーション内のすべての UI 開発を置き換えるのではなく、高度に動的な領域への適用が推奨される

Assess

16. Agentic reinforcement learning environments

  • LLMベースのエージェント向け訓練場として、コンテキスト、ツール、フィードバックを組み合わせて多段階タスクを完了
  • このアプローチは、LLMの事後学習を単純な単一ターン出力から、推論やツール利用のようなagenticな動作へと再構成し、各行動に報酬またはペナルティを割り当てる
  • RLVRのような手法により、報酬が検証可能であり、ゲーム化に耐性を持つことを保証
  • 現在はAI研究ラボが開発を主導しており、特にコーディングおよびコンピュータ利用エージェント向けで、CursorのComposerはフロンティアラボ外の例として、製品環境内で訓練された専門的なコーディングモデル
  • Prime IntellectのEnvironments Hub、Agent Lightning、NVIDIA NeMo Gymのようなフレームワークやプラットフォームの登場により、プロセスの単純化が進行

17. Architecture drift reduction with LLMs

  • AIコーディングエージェントの利用増加により、意図されたコードベース・アーキテクチャ設計からのドリフトが加速し、放置するとエージェントと人間が既存パターン（劣化したものを含む）を複製してドリフトが複合し、悪いコードがさらに悪いコードを生むフィードバックループを形成
  • 決定論的分析ツール（Spectral、ArchUnit、Spring Modulith）とLLMベースの評価を組み合わせ、構造的・意味的違反の両方を検出
  • API品質ガイドラインをサービス全体に強制し、エージェント生成の改善を導くアーキテクチャゾーン定義に適用
  • 従来のlintingと同様に、初期スキャンでは多数の違反が表面化するため、分類と優先順位付けが必要であり、LLMがこれを支援
  • エージェント生成による修正を小さく集中したものに保ち、レビューしやすくし、変更がリグレッションなしにシステムを改善しているか確認する追加の検証ループが必須
  • feedback sensors for coding agentsの考え方をデリバリーライフサイクルの後期段階へ拡張したもので、OpenAIチームの表現を借りれば、ドリフト低減は**「ガベージコレクション」**のような形で機能する

18. Code intelligence as agentic tooling

  • LLMはコードをトークンストリームとして処理し、コールグラフ、型階層、シンボル関係に対するネイティブな理解を持たない
  • コード探索では、現在のほとんどのコーディングエージェントが基本的にテキストベース検索（すべての言語にまたがる最も強力な共通分母）を使っており、IDEの高速ショートカットで済むリファクタリングのために、エージェントは複数のテキストdiffを生成する必要がある
  • エージェントは、ASTにすでに存在している情報を再構成するために相当量のトークンを消費
  • ASTを認識するツールへのエージェントアクセスを提供し、例えばLanguage Server Protocol（LSP）を通じて、「このシンボルへのすべての参照を探す」や「この型の名前をすべての場所で変更する」といった操作を第一級のアクションとして実行
  • OpenRewriteのようなcodemodツールは、より豊かなLossless Semantic Tree(LST)コード表現上で動作し、適切な作業を決定論的ツールに委譲することで、幻覚的な編集の削減とトークン消費の節約が可能
  • Claude CodeやOpenCodeなどはローカル実行のLSPサーバーと統合されており、JetBrainsはIDEの探索とリファクタリングを外部エージェントに公開するMCPサーバーを提供、Serena MCPサーバーは意味的なコード検索・編集を提供

19. Context graph

  • 決定、ポリシー、例外、先例、証拠、結果をグラフの第一級の接続ノードとしてモデル化する知識表現手法で、AIが消費しやすいよう構造化されている
  • 記録システムが何が起きたかを捉えるのに対し、context graphはなぜを捉える — Slackスレッド、承認チェーン、人々の頭の中に埋もれた組織的推論を、問い合わせ可能な機械可読構造へ変換する
  • エージェントの有効性に不可欠であり、例えば割引例外を処理するエージェントが、それが標準ポリシーなのか一度限りのオーバーライドなのか判断できない場合に誤った推論をしうるが、コンテキストグラフは出所を直接示すことで、決定追跡の走査、関連先例の適用、マルチホップの因果連鎖推論を可能にする
  • 静的な文書コーパスから構築されるGraphRAGとは異なり、コンテキストグラフはすべてのエッジに時間的な有効性を保持し、置き換えられた事実は上書きではなく無効化される
  • セッション間で持続するメモリや追跡可能な意思決定推論が必要なagenticアプリケーションでは評価に値する

20. Feedback flywheel

  • コーディングエージェントと協働するチームは、spec-driven developmentワークフローをますます採用しており、軽量またはopinionatedなフレームワークかどうかに関わらず、spec → plan → implementの流れに従う
  • Feedback flywheelは、この流れをcoding agent harnessの継続的改善に焦点を当てた追加ステップへと拡張する
  • レトロスペクティブに似ており、チームはコーディングエージェントのセッション中に成功と失敗を捉え、将来のセッションの予測可能性向上に活用し、時間とともに複合効果を生む
  • human on the loopが、curated shared instructionsやfeedback sensors for coding agentsのようなフィードフォワード制御の改善に集中するメタ手法
  • 次のレベルは**agentic feedback flywheel**で、蓄積されたフィードバックに基づいてエージェントが必要な改善を判断するが、現時点では依然としてcontext rotやエージェントを誤誘導しうるノイズフィードバックを防ぐためにhuman-in-the-loopが必要
  • 環境の進化に応じて、coding agent harness全体の評価に活用でき、特に新しいモデルを採用する際には、あるモデルで機能したものが次のモデルでは不要になる可能性がある

21. HTML Tools

  • エージェンティックなツールによって、小規模でタスク別のユーティリティを構築しやすくなり、主要な課題は配布と共有の方法になっている
  • HTML Toolsは、共有可能なスクリプトやユーティリティを単一のHTMLファイルとしてパッケージ化するアプローチ
  • ブラウザで直接実行でき、どこにでもホスティングでき、あるいは単にファイル共有も可能で、バイナリ共有やパッケージマネージャーの利用が必要なCLIツール配布のオーバーヘッドを回避できる
  • 専用ホスティングを備えた完全なWebアプリケーションを構築するよりもシンプル
  • セキュリティの観点では、信頼できないファイルの実行には依然としてリスクが伴うが、ブラウザのサンドボックスとソースコードを確認できる可能性が一定の緩和をもたらす
  • 軽量ユーティリティに対して、単一のHTMLファイルは非常にアクセスしやすく可搬性の高い方式を提供する

22. LLM evaluation using semantic entropy

  • LLMのQAアプリケーションにおける幻覚の一形態である**作話(confabulation)**は、従来の評価手法では解決が難しい
  • 1つのアプローチは、与えられた入力に対する出力の語彙的な揺らぎを分析して不確実性を測るために情報エントロピーを使うこと
  • Semantic entropyを用いたLLM評価は、この考え方を拡張し、表層的な揺らぎよりも意味の差異に焦点を当てる
  • 単語列ではなく意味を評価することで、事前知識なしにデータセットやタスク全般へ適用可能であり、未知のタスクにもよく一般化する
  • 作話を引き起こす可能性のあるプロンプトを特定し、必要に応じて注意を促すのに役立つ
  • 素朴なエントロピーはしばしば作話の検出に失敗する一方、semantic entropyは誤った主張のフィルタリングにより効果的である

23. Measuring collaboration quality with coding agents

  • コーディングエージェントの利用によって実際の生産性向上は観察されているが、多くの評価指標はいまだに、初回出力までの時間、生成されたコード行数、完了した作業といったcoding throughputに過度に集中している
  • チームが速度の罠(speed trap)に陥らないよう、焦点を人間とエージェントがどれだけ効果的に協働しているかへ移す
  • first-pass acceptance rate、作業ごとの反復サイクル、マージ後の手戻り、失敗したビルド、レビュー負荷といった指標は、速度単独よりも意味のあるシグナルを提供する
  • Claude Codeを使うチームは、/insightsコマンドでエージェントセッションの成功と課題を反映したレポートを生成でき、カスタマイズした/reviewコマンドのfirst-pass acceptance追跡も試している
  • 短いフィードバックサイクルと失敗ビルドの減少は、エージェントとのより効果的な相互作用の指標である
  • 個人レベルではなくチームレベルで、DORAメトリクスとあわせて協働の質を追跡することで、コーディングエージェント導入のより完全な姿を構築できる

24. MITRE ATLAS

  • エージェンティックなシステムとコーディングツールは、新しいアーキテクチャと新たに生じるセキュリティ脅威を持ち込む
  • MITRE ATLASは、AIおよびMLシステムを標的とする敵対的戦術と技法の知識ベース
  • より広範なMITRE ATT&CKフレームワークよりも焦点を絞った補完的な設計で、MLパイプライン・LLMアプリケーション・エージェンティックシステムの脅威分類を提供する
  • 共通語彙がなければ、セキュリティリスクは見落とされたり、単なるチェックボックス演習に矮小化されたりしがちであり、ATLASはその助けになる
  • 実際のインシデントと技術パターンの研究に基づいており、チームは脅威モデリング支援のためにフレームワークを利用できる
  • SAIFのような統制フレームワークを自然に補完し、AIシステムの進化する脅威環境を説明する助けになる

25. Ralph loop

  • Wiggum loopとも呼ばれる自律型コーディングエージェント手法で、固定プロンプトを無限ループでエージェントに供給する
  • 各反復は新しいコンテキストウィンドウで始まり、エージェントが仕様や計画から作業を選び、実装し、新たなコンテキストでループを再開する
  • 核となる洞察はシンプルさであり、teams of coding agentsやcoding agent swarmsのような調整の代わりに、単一のエージェントが仕様に対して自律的に作業し、反復を重ねることでコードベースが仕様へ収束していくことを期待する
  • 各反復で新しいコンテキストウィンドウを使うことで、蓄積されたコンテキストによる品質低下を回避できるが、その代償として相当なトークンコストがかかる
  • gooseのようなツールがこのパターンを実装しており、場合によっては反復間でクロスモデルレビューへ拡張される

26. Reverse engineering for design system

  • 組織はしばしば、「デザイン標準」がばらばらのWebページ、マーケティング資料、スクリーンショットの緩いコレクションとしてしか存在しない断片化されたレガシーインターフェースに悩まされる
  • 歴史的には、こうしたアーティファクトを監査して統合の土台を築くことは、手作業で時間のかかるプロセスだった
  • マルチモーダルLLMにより、この抽出を自動化し、既存の視覚資産からデザインシステムを効果的にリバースエンジニアリングできる
  • Webサイト、スクリーンショット、UI断片を専用ツールやビジョン対応AIモデルに入力することで、チームはカラーパレット、タイポグラフィスケール、間隔ルールといった中核デザイントークンを抽出し、繰り返し現れるコンポーネントパターンを特定できる
  • AIはこの非構造化な視覚データをデザインシステムの構造化された意味表現へと合成し、Figmaのようなツールと統合すれば、正式化され保守可能なコンポーネントライブラリの生成を大きく加速する
  • 視覚監査の労力を減らすだけでなく、「AI-ready」なデザインシステムを構築する足がかりとしても機能する
  • ブラウンフィールドのデザイン負債を抱えるエンタープライズにとって、AIで基準となるデザインシステムを確立することは、全面的な再設計やフロントエンド標準化の前に取り組める実用的な出発点である

27. Role-based contextual isolation in RAG

  • アクセス制御をアプリケーション層から検索層へ移すアーキテクチャ手法
  • すべてのデータチャンクに対してインデックス時点でロールベースの権限タグを付与し、クエリ時には検索エンジンがユーザーの認証済みアイデンティティに基づいて検索空間を制限し、各チャンクのメタデータと照合する
  • AIモデルは検索段階でフィルタリングされるため、未承認のコンテキストへアクセスできないことを保証し、内部ナレッジベースにゼロトラスト基盤を提供する
  • MilvusやAmazon S3ベースのサービスのように、多くのベクターデータベースが高性能なメタデータフィルタリングをサポートしており、大規模ナレッジベースにも導入しやすい

28. 実行可能なオンボーディング文書としてのスキル

  • Agent Skills、curated shared instructions など、他の context engineering 手法が今回の Radar 全体で登場しているが、コーディング文脈で特に強調したいユースケースは 実行可能なオンボーディング文書としてのスキル
  • 複数のレベルに適用可能で、コードベース内では /_setup スキルが go.sh スクリプトと README ファイルの役割を果たし、スクリプト化できない段階では LLM の実行セマンティクスとスクリプトを組み合わせる
  • スクリプトでできることを超えて、コードベースと環境の現在の状態を動的に考慮できる
  • ライブラリや API の作成者は、文書の一部として利用者にスキルを提供でき、内部または外部のスキルレジストリ（Tessl など）を通じて配布可能
  • チームの内部プラットフォームのオンボーディングに有用で、主要技術の利用障壁を下げたり、デザインシステム採用時の摩擦を減らしたりできる。これまでは MCP サーバーに大きく依存していたが、現在はスキルへ移行しつつある
  • 他の文書形式と同様に最新状態を保つ課題はなくならないが、実行可能な文書は静的文書と違って古くなったことにずっと早く気づく助けになる

29. Small language models

  • SLM は継続的に改善されており、特定のユースケースでは LLM より 1ドル当たりで優れた知能 を提供し始めている
  • 推論コストの削減と agentic ワークフローの高速化のためにチームは SLM を評価しており、最近の進展は 知能密度 における着実な向上を示していて、要約や基本的なコーディングのような作業では旧世代の LLM と競争できるようになっている
  • 「大きいほど良い」から、より高品質なデータ、モデル蒸留、量子化 への転換を反映している
  • Phi-4-mini や Ministral 3 3B のようなモデルは、蒸留モデルがより大きな教師モデルの多くの能力を維持できることを実証している
  • Qwen3-0.6B や Gemma-3-270M のような超小型モデルも エッジデバイスで実行可能 になっている
  • 旧世代の LLM で十分だった agentic ユースケースでは、SLM を 低コスト・低遅延・低リソース要求の代替 として検討する

30. Team of coding agents

  • 以前の Radar では、開発者が 役割別エージェントの小集団を調整 してコーディング作業を協調させる手法として説明した
  • その後、導入障壁は低下し、サブエージェント対応は既存のコーディングエージェントツール全般で基本機能となっており、Claude Code に組み込みのオーケストレーションを提供する agent teams 機能 も含まれる
  • エージェントチームでは、主オーケストレーターが通常、作業のシーケンスと並列化を調整し、エージェントはオーケストレーターだけでなく 互いにも通信できる 必要がある
  • 一般的なユースケースとしては、レビュアーチームや、バックエンド・フロントエンドなどアプリケーションの異なる部分を担当する実装者グループがある
  • 業界の一部では「agent teams」と "agent swarms" を交換可能な概念として使っており（Claude Code も agent teams 機能を「our implementation of swarms」と説明している）が、この区別には価値がある
  • 小さく意図的に構成されたエージェントチームがタスクで協働すること は、参入障壁、複雑性、ユースケースの面で大規模な swarm とはかなり異なる

31. Temporal fakes

  • IoT や産業プラットフォームで長く使われてきた 現実世界のシステムシミュレーション という発想を拡張したもの
  • AI コーディングエージェントがシミュレーター構築の労力を減らし、外部依存関係の高忠実度な複製 をはるかに容易に生成できるようにしている
  • 静的なリクエスト・レスポンスの組を返す従来の mock とは異なり、temporal fakes は 内部状態マシンを維持し、実システムの時間的変化をモデル化 する
  • あるチームは、大規模 GPU データセンター向けのオブザーバビリティスタック開発にこの手法を使い、物理ハードウェアの調達を回避した
    • 実システムに対するアラートルール、ダッシュボード、異常検知のテストは非現実的だった（例: thermal throttle アラートを検証するために意図的に GPU を過熱させるなど）
    • その代わりに、NVIDIA DCGM や InfiniBand fabric のようなハードウェアドメイン向けの fake を Go で構築した
    • シミュレーターで、thermal throttling、XID エラーの嵐、リンク flap、PSU 障害のような障害シナリオを、強度と継続時間を設定可能な形で有効化し、process-compose スタックでオーケストレーションした
  • 中央レジストリが有効な障害シナリオを定義し、MCP サーバーがエージェントにシナリオ注入を公開する
  • エージェントは、特定の GPU に thermal throttle を注入するといった障害をトリガーでき、メトリクスが予想どおりに変化し、アラートが発火し、ダッシュボードが更新されることを検証できる
  • このような 時間的忠実性 は、障害が連鎖する複雑なシステムをテストする際にこの手法へ価値を与えるが、fake が現実世界の挙動に忠実でない場合、自動化パイプラインに誤った安心感を生む危険がある

32. AI のための toxic flow analysis

  • エージェントの能力がセキュリティ実践を追い越しつつあり、OpenClaw のような 権限を欲しがる(permission-hungry) エージェント の台頭によって、チームは lethal trifecta にさらされた環境へエージェントを配備するケースを増やしている。すなわち、私的データへのアクセス、信頼できないコンテンツへの露出、外部通信能力の組み合わせである
  • 能力が高まるにつれて攻撃対象領域も拡大し、システムはプロンプトインジェクションやツール汚染のようなリスクにさらされる
  • Toxic flow analysis は、agentic システムを調査して 安全でないデータ経路と潜在的な攻撃ベクトルを特定 する主要な手法として引き続き認識されている
  • リスクはもはや MCP 統合に限られず、Agent Skills でも同様のパターンが見られる。すなわち、悪意ある行為者が、機密データ流出のための隠れた指示を埋め込んだ、一見有用なスキルをパッケージ化する 可能性がある
  • エージェント作業チームには、toxic flow analysis を実施し、悪用される前に安全でないデータ経路を特定するために Agent Scan のようなツールを使うことを強く推奨する

33. エンドツーエンド文書解析のためのVision language models

  • 文書解析は、レイアウト検出、従来型OCR、後処理スクリプトを組み合わせた多段階パイプラインに依存しており、複雑なレイアウトや数式に苦戦してきた
  • VLMを用いたエンドツーエンドの文書解析は、文書画像を単一の入力モダリティとして扱うことでアーキテクチャを単純化し、自然な読み順と構造化されたコンテンツを保持する
  • olmOCR-2、トークン効率の高いDeepSeek-OCR (3B)、超小型のPaddleOCR-VLのような、この目的に特化して訓練されたオープンソースモデルは非常に効率的な結果を生み出している
  • VLMは多段階パイプラインの代替としてアーキテクチャの複雑さを減らすが、生成的な性質ゆえにハルシネーションしやすい
  • エラー許容度の低いユースケースでは、依然としてハイブリッドアプローチや決定論的OCRが必要
  • 大量の文書コレクションを処理するチームは、精度を維持しつつ長期的な保守オーバーヘッドを削減できるかを判断するために、このような統合アプローチを評価する必要がある

Caution

34. Agent instruction bloat

  • AGENTS.md、CLAUDE.mdのようなコンテキストファイルは、時間の経過とともにコードベースの概要、アーキテクチャの説明、慣習、ルールの追加によって蓄積していく
  • 個々の追加は単独では有用だが、しばしばagent instruction bloatを招き、指示が長くなり、ときには互いに衝突する
  • モデルは長いコンテキストの途中に埋もれた内容にあまり注意を向けない傾向があり、長い会話履歴の奥深くにあるガイダンスは見落とされうる
  • 指示が増えるにつれて、重要なルールが無視される可能性も高まる
  • 多くのチームがAIでAGENTS.mdファイルを生成しているが、研究は人手で書かれた版のほうがLLM生成版より効果的なことが多いことを示唆している
  • agenticツールを使う際には、指示について意図的かつ選択的であるべきであり、必要に応じて追加しつつ、最小限で一貫したセットへ継続的に洗練していく必要がある
  • 現在の作業に必要な指示と能力だけを表面化するために、progressive context disclosureの活用を検討すべきである

35. AI-accelerated shadow IT

  • AIはノンコーダーが複雑なシステムを構築するハードルを下げ続けており、実験や要件の初期検証を可能にする一方で、AIに加速されたシャドーITのリスクも持ち込んでいる
  • AI API（OpenAIやAnthropicなど）を統合したノーコードのワークフロープラットフォームに加え、Claude Coworkのような、より多くのagenticツールがノンコーダー向けに提供されている
  • ひっそりと業務を支えていたスプレッドシートが、ガバナンスのないカスタムagenticワークフローへ進化すると、重大なセキュリティリスクや、類似問題に対する競合ソリューションの乱立を招く
  • 単発のワークフローと、永続的で本番運用に耐える実装が必要な重要プロセスを区別することが、実験と統制のバランスを取るうえでの鍵となる
  • 組織はAI導入戦略の一環としてガバナンスを優先し、統制された環境内での実験を促進する必要がある
  • 適切に計測された内部サンドボックスは、ノンコーダーに対して、利用状況を追跡できるプロトタイプの展開先を提供する
  • 既存ワークフローの共有カタログと組み合わせることで、チームはすでに構築済みのものを発見し、重複した努力を避けやすくなる

36. Codebase cognitive debt

  • システム実装と、チーム内で共有されるそれがどのように、そしてなぜ動くのかについての理解との間に広がるギャップ
  • AIが変更速度を高めるにつれ、特に複数の貢献者やCoding Agent Swarmsでは、チームが設計意図や隠れた結合の追跡を失う可能性がある
  • 増大する技術的負債と相まって、システムをますます推論しにくくする強化ループが形成される
  • システム理解が弱いと、開発者がAIを効果的に導く能力が低下し、エッジケースを予測したり、エージェントをアーキテクチャ上の落とし穴から遠ざけたりすることが難しくなる
  • 管理されなければ、小さな変更が予期しない障害を引き起こす転換点に達し、修正が回帰を持ち込み、整理の努力がリスクを減らすどころか増やしてしまう
  • AI生成コードに対する安易な姿勢を避け、明示的な対策を導入すべきである — feedback sensors for coding agents、チームの認知負荷の追跡、アーキテクチャ・フィットネス関数によって、AIが出力を加速しても中核的な制約を継続的に強制する

37. Coding agent swarms

  • team of coding agentsが小規模で意図的なグループであるのに対し、coding agent swarmは数十から数百のエージェントを問題に適用し、AIがその構成と規模を動的に決定する
  • Gas Town、Ruflo（旧Claude Flow）のようなプロジェクトが良い例である
  • swarm実装における初期パターンが現れつつある — 階層的な役割分担（オーケストレーター、監督者、一時的ワーカー）、エージェントが作業分割と調整を支援される永続的な作業台帳（Gas Townはbeadsを使用）、並列作業の競合を処理するマージ機構
  • 2つのswarm実験が特に注目に値する — AnthropicによるCコンパイラ生成と、Cursorのagent scaling実験（1週間かけてブラウザを生成）
  • 両チームとも、既存の詳細仕様に依存できるユースケースを選択しており、Cコンパイラの場合は、明確で測定可能なフィードバックを提供する包括的なテストスイートが含まれる
  • こうした条件は、要件定義がより曖昧で検証も難しい典型的なプロダクト開発を代表するものではない
  • それでも、これらの実験は、長時間実行されるswarmを技術的に実現可能にする新たなパターンに貢献しているが、依然としてコストが高く成熟には程遠いため、導入には慎重さが推奨される

38. 生産性の指標としてのコーディングスループット

  • AIコーディングアシスタントは実際に生産性向上をもたらしており、標準的な開発者ツールとして急速に定着しつつある
  • しかし組織では、生成されたコード行数やプルリクエスト（PR）数といった表面的な指標で成功を測るケースが増えている
  • このようなコーディングスループットのメトリクスを切り離して使うと、従業員の行動に悪影響を及ぼす可能性がある
  • その結果としてしばしば起きるのは、レビューを遅らせ、デリバリーのスループットを損ない、セキュリティリスクを持ち込む、整合していないコードの洪水であり、エンジニアは十分にレビューされていないAI出力で埋まったPRを上げ、レビューアーとの往復が繰り返されてサイクルタイムが増加する
  • こうしたメトリクスでは、AI生成コードをチームのアーキテクチャ、慣行、パターンに適合させるために必要な残余の労力を捉えられない
  • より意味のある先行指標として、first-pass acceptance rate、すなわちAI出力が最小限の手戻りで利用できる頻度がある
  • これを測定することで隠れた労力が可視化され、改善施策を実行可能になり、チームはプロンプトの洗練、プライミング文書の改善、設計に関する対話の強化によって受容率を継続的に高められる
  • AI出力の修正がより少なくて済む好循環が生まれ、first-pass acceptanceはDORAメトリクスとも自然につながる — 受容率が低いと変更失敗率が高まる傾向があり、反復サイクルの繰り返しは変更リードタイムを延ばす
  • AIアシスタントが一般化するにつれ、組織はコーディングスループット単独から、実際の影響とデリバリー成果を反映するメトリクスへと焦点を移す必要がある

39. エージェントワークフローにおける耐久性の無視

  • 複数のチームで観察されたアンチパターンであり、開発環境では動作しても本番環境で失敗するシステムを招く
  • 分散システムが直面する課題はエージェント構築時にはさらに顕著になり、失敗を想定して優雅に復旧するという考え方が、反応的なアプローチより優れている
  • LLMとツール呼び出しはネットワーク障害やサーバークラッシュで失敗する可能性があり、エージェントの進行停止やユーザー体験の悪化、運用コスト増加を招く
  • 一部のシステムでは、タスクが短時間で終わるならこれを許容できるが、数日から数週間動き続ける複雑なワークフローでは耐久性が必要になる
  • LangGraph、Pydantic AIのようなエージェントフレームワークでは耐久性のある実行を統合しつつある
  • 進行状況とツール呼び出し状態の永続化を提供し、障害後にエージェントがタスクを再開できる
  • human in the loop を含むワークフローでは、耐久性のある実行により入力待ちの間に進行を一時停止できる
  • Durable computingプラットフォームであるTemporal、Restate、Golemもエージェント対応を提供している
  • 組み込みのツール実行と意思決定追跡の可観測性により、デバッグが容易になり、本番システムの理解も向上する
  • まずはエージェントフレームワークのネイティブな耐久性実行サポートから始め、ワークフローがより重要または複雑になったら独立したプラットフォームを活用する

40. MCP by default

  • Model Context Protocol (MCP)が注目を集める中、より単純な代替手段があるにもかかわらず、チームやベンダーがAIエージェントと外部システムの間のデフォルト統合レイヤーとして採用する傾向がある
  • MCPをデフォルトで使うことには注意が必要で、MCPは構造化されたツール契約、OAuthベースの認証境界、ガバナンスされたマルチテナントアクセスにおいて実際の価値を加える
  • 一方で、Justin Poehneltが"abstraction tax"と呼ぶものも持ち込み、エージェントとAPIの間に入るすべてのプロトコル層が忠実度の損失を生み、複雑なAPIではその損失が積み重なる
  • 実際には、優れた--help出力、構造化されたJSONレスポンス、予測可能なエラー処理を備えたよく設計されたCLIが、プロトコルのオーバーヘッドなしでエージェントに必要なものをすべて提供する
  • Simon Willisonの指摘のとおり、"MCPで実現できるほとんどすべてのことはCLIツールで扱える"
  • これはMCPの否定ではなく、チームはデフォルト採用を避け、システムが本当にプロトコルレベルの相互運用性を必要としているかをまず問うべきだ
  • MCPは、ガバナンスと統合の利点が追加される複雑さと潜在的な忠実度損失を上回る場合に妥当である

41. ピクセルストリーミング型開発環境

  • VDIスタイルのリモートデスクトップやワークステーションをソフトウェア開発に利用し、編集・ビルド・デバッグをローカルマシンやコード中心のリモート環境ではなく、ストリーミングされたデスクトップ経由で行う
  • 組織は、特にオフショアチームやリフトアンドシフト型クラウドプログラムにおいて、セキュリティ、標準化、オンボーディングの目標を満たすために引き続き採用している
  • しかし実際には、トレードオフはしばしば芳しくない — 遅延、入力ラグ、一貫しない画面応答性が継続的な認知的摩擦を生み、デリバリー速度を落とし、日々の開発作業をより疲れるものにする
  • クラウド開発環境、Google Cloud Workstations、Coder、VS Code Remote Developmentのようなツールとは異なり、これらはデスクトップ全体をストリーミングせずにコンピューティングをコードにより近い場所へ移す
  • ピクセルストリーミング型の構成は、開発者のフローよりも中央集権的な統制を優先し、それを使うエンジニアから十分な意見を得ないまま押し付けられることが多い
  • 強力なセキュリティ要件や規制上の制約が生産性コストを明確に上回らない限り、ソフトウェアデリバリーのデフォルト選択としてピクセルストリーミング型開発環境は推奨しない

[Platforms]

Adopt

— なし

Trial

42. AG-UI Protocol

  • リッチなユーザーインターフェースとバックエンドAIエージェントの間の通信を標準化するために設計されたオープンプロトコルおよびライブラリ
  • 歴史的に、agentic UI の構築には双方向の状態保持コラボレーションのためのカスタムな配管作業が必要だったが、AG-UIは、server-sent events(SSE)やWebSocketsのようなトランスポートをサポートする一貫したイベント駆動アーキテクチャでこれを解決する
  • 推論ステップのストリーミング、状態同期、動的UIコンポーネントのレンダリングをサポートする
  • ただし、エージェントインターフェースのアーキテクチャ環境は急速に変化しており、AG-UIは意図的にMCPの外側に位置し、フロントエンドとエージェントバックエンドの間のインターフェースレイヤーとして機能する
  • 新たなMCPベースのアプリケーションでは、HTMLとUIウィジェットをMCPサーバーやスキル内に直接パッケージングする別のアプローチが台頭している
  • UIコンポーネントがツールとともに埋め込まれ提供可能になるにつれ — MCP-UIのような隣接標準に関連するパターン — AG-UIのような独立したUIプロトコルレイヤーの必要性に疑問が投げかけられている
  • フロントエンドUXとバックエンドオーケストレーションを分離するには依然として堅実な選択だが、MCPエコシステム内でツールロジックとUIを統合する傾向を踏まえて、その役割を評価する必要がある

43. Apache APISIX

  • レガシーな Nginx ベースのソリューションの限界を解決する、オープンソース・高性能・クラウドネイティブなゲートウェイ
  • Nginx と OpenResty の LuaJIT 上に構築され、設定ストアとして etcd を使用することでリロードによる遅延を排除し、動的なマイクロサービスやサーバーレスアーキテクチャに適している
  • 主な強みは 完全に動的でプラグイン可能なアーキテクチャ で、API と WASM を含む多言語プラグインエコシステムにより、トラフィック管理・セキュリティ・可観測性をカスタマイズできる
  • Kubernetes Gateway API をサポートしており、Apache APISIX を Kubernetes ゲートウェイとして利用可能で、レガシーな Nginx ingress コントローラーの有力な代替候補

44. AWS Bedrock AgentCore

  • インフラ管理のオーバーヘッドなしに、エージェントを安全に大規模で構築・実行・運用するための agentic プラットフォームで、GCP Vertex AI Agent Builder、Azure AI Foundry Agent Service に類似
  • プラットフォーム全体をモノリシックなブラックボックスとして採用しがちだが、細分化され分離されたアーキテクチャのほうがより大きな成功につながる — セッション分離・セキュリティ・可観測性のような本番運用上の関心事には AgentCore ランタイムを使い、オーケストレーションロジックは LangGraph のような外部フレームワークに維持する
  • このような関心事の分離により、LLM 環境の進化に適応する柔軟性を保ちながら、マネージドインフラの利点を活用できる
  • ランタイム優先のアプローチにより、組織は ベンダー固有のオーケストレーションレイヤーに中核ロジックの制御権を渡すことなく、agentic ワークロードを段階的に本番環境へ移行できる

45. Graphiti

  • Zep のオープンソース時間知識グラフエンジンで、LLM メモリ問題の解決における本番適用可能性を示している
  • RAG パイプラインのフラットなベクトルストアは事実の時間的変化を追跡できない一方、Graphiti はデータを個別の エピソード として収集し、グラフエッジに 双時間的な有効ウィンドウ を保持するため、古い事実は上書きされるのではなく無効化される
  • バッチ指向の GraphRAG とは異なり、グラフを段階的に更新し、意味検索・BM25・グラフ走査を組み合わせたハイブリッド検索によって、クエリ時の LLM 呼び出しなしでサブ秒検索を提供する
  • 採用を後押しする要因は 2 つある — 18.5% の精度改善と 90% の遅延削減 を報告する査読済みベンチマーク、そして Model Context Protocol 互換エージェントが最小限の統合作業で永続的な時間メモリを付加できるようにする、正式な MCP サーバー の公開
  • 強力なコミュニティ導入も本番対応度を示す追加シグナル
  • Neo4j が主要バックエンドで、FalkorDB が軽量な代替
  • 書き込みごとの LLM 抽出コストと 1.0 未満のリリース状態を考慮すると、依存関係の固定が必要

46. Langfuse

  • 可観測性、プロンプト管理、評価、データセット管理を扱うオープンソースの LLM エンジニアリングプラットフォーム
  • 前回の評価以降、プロジェクトは大きく成熟し、v3 アーキテクチャでは ClickHouse、Redis、S3 をバックエンドコンポーネントとして導入して 拡張性は向上したが、セルフホスティングの複雑さも増した
  • Python と TypeScript の SDK はどちらも OpenTelemetry 上にネイティブに構築されており、OTEL ベースの可観測性を使うチームに自然に適合する
  • 実験ランナー SDK や、プロンプト実験向けの構造化出力サポートといった新機能により、Langfuse は単なるトレーシングから体系的な評価ワークフローへと拡張された
  • Arize Phoenix、Helicone、LangSmith を含む、ますます混み合う領域で検討に値する
  • 主に Pydantic AI 上に構築しているチームは、LLM 特化のツール群の代わりに フルスタック OTEL 可観測性プラットフォーム としてより広いアプローチを取る Pydantic Logfire も検討するとよい
  • 統合されたトレーシング、評価、プロンプト管理を単一のセルフホスト可能プラットフォームで必要とするチームにとって信頼できる選択肢だが、モデルレイヤーのコストや遅延の可視性が主な要件なら、Helicone のようなより特化したツールで十分かどうかを評価する必要がある

47. Port

  • 開発者体験の改善を目的に設計された 商用の内部開発者ポータル で、ソフトウェア資産の一元化・ワークフロー自動化・エンジニアリング標準の適用を通じて、プラットフォームチームにセルフサービスワークフローの単一の信頼できる情報源を提供する
  • 組織がエンジニアリングワークフローを標準化しつつ、テンプレート、API、自動化、エージェントを開発者が実際に使える形で公開しようとする中で、重要性が増している
  • 独立したポータルとしてだけでなく、Port の API と MCP レイヤーを通じて IDE から直接利用可能
  • プラットフォームエンジニアリングに大規模投資をせずに、製品化されたポータル機能を求める組織に適している
  • クライアント導入では数千人の開発者を支えつつ、比較的小規模なプラットフォームチームでも効果的なセルフサービスを迅速に提供できるようにしている
  • 内部開発者ポータル機能を迅速に必要とし、商用プラットフォームとベンダーロックインの制約を受け入れられる組織にとって評価する価値がある

48. Replit

  • 即時の開発環境、リアルタイムコーディング、統合 AI アシスタンス をブラウザ上でそのまま提供する、クラウドネイティブなコラボレーティブ開発プラットフォーム
  • エディタ、ランタイム、デプロイ、AI コーディングワークフローを単一の統合プラットフォームに組み合わせ、開発者はローカル設定なしですぐにコーディングを始められる
  • AI ベースの共同 IDE は オンボーディング時の摩擦を減らす のに非常に役立ち、チームでのプロトタイピングに適している
  • トレーニングセッション、知識共有、ブートキャンプにも非常に効果的
  • 一部では Replit を AI 支援の趣味プロジェクト向けの場と見るかもしれないが、環境は従来のローカル IDE と競合できるほど強力で、反復とコラボレーションがはるかに容易になる

49. SigNoz

  • ログ・メトリクス・トレースを統合してサポートする オープンソースの OpenTelemetry ネイティブ可観測性プラットフォーム
  • 現代的なマイクロサービスと分散アーキテクチャの APM および計測ニーズに対応しながら、ベンダーロックインを回避する
  • ClickHouse をデフォルトのカラム指向データベースとして活用し、高速クエリとともに、スケーラブルで高性能かつコスト効率の高い保存を提供し、Datadog のようなプラットフォームに対する強力なセルフホスト代替として位置づけられる
  • PromQL と ClickHouse SQL による柔軟なクエリ、多様な通知チャネルへのアラートをサポート
  • 実際に SigNoz は、性能を損なうことなく インフラリソース消費と全体的な可観測性コストを削減 できることが確認されている
  • マネージドクラウドサービスも利用可能だが、データとインフラの制御を維持したい組織には、すぐ使える Docker イメージと Helm チャートが実用的な選択肢

Assess

50. Agent Trace

  • Cursorが提案したAIコード帰属の標準化オープン仕様
  • コーディングエージェントの導入増加により、誰がコードを修正したかの理解は人間の開発者を超えて、AIが生成した変更も含む形へと拡張
  • git blameのような既存ツールはコード行が修正されたことは示せるが、その変更が人間・AI・両方のいずれによるものかを捉えられない
  • Agent Traceはコード変更の追跡方法を定義するうえでベンダー中立のアプローチを取り、追跡情報の保存方法については特定の立場を取らない
  • Git、Mercurial、Jujutsuを含む複数のバージョン管理システムと互換
  • 仕様ではhuman、AI、mixed、unknownのようなコントリビューター種別と、各貢献元の説明を追跡するレコードを定義
  • Cline、OpenCodeのようなツールによるサポートと、Git AIのような実装により、導入初期の兆候が見られる

51. ClickStack

  • 単一の高性能データストア（ClickHouseベース）でログ・トレース・メトリクス・セッションを統合する、OpenTelemetry互換のオープンソース観測性プラットフォーム
  • インフラの拡大と観測性コストの増加により、多くのチームが断片化したテレメトリツールチェーンと高価なベンダープラットフォームに苦しんでいる
  • ClickStackはClickHouseのカラムストアを活用し、大量のテレメトリデータ全体に対してサブ秒の高カーディナリティクエリを可能にし、観測性のためのよりシンプルでコスト効率の高い基盤を提供

52. Coder

  • pixel-streamed development environmentsの有力な代替であり、コードの実行場所と開発者の操作方法を分離
  • デスクトップ全体のインターフェースをストリーミングする代わりに、開発者はVS CodeのようなローカルIDEやブラウザからリモート環境に接続し、使い勝手を損なわずにより応答性の高い体験を得られる
  • コードはリモートのスケーラブルなインフラ上で実行され、環境はコードとして定義・管理されるため、チームは開発設定を標準化し、新規開発者のオンボーディングを簡素化できる
  • 内部システムへの統制されたアクセス提供や、事前承認済みAIコーディングエージェントのアクセス簡素化も容易
  • Coderはローカル開発と完全仮想化デスクトップの中間地点と位置づけられており、pixel-streamed VDIのユーザビリティ上の制約なしに集中管理とガバナンスを提供
  • リモートまたは制御された実行環境を必要とする組織、特により高い計算能力や安全なアクセスが必要な場所にとって有力な選択肢
  • このような環境管理に伴う運用オーバーヘッドとセキュリティ責任の評価が必要

53. Databricks Agent Bricks

  • エージェントベースのアプローチが主流化する中、データプラットフォームはこうしたワークロードを追加モジュールではなくネイティブにサポートする方向へ進化している
  • Databricks Agent Bricksは、ナレッジアシスタントやデータアナリストのような一般的なAIパターン向けの事前構築済み・自動最適化コンポーネントを提供
  • 宣言的アプローチに従い、開発者が目標と基本データを定義し、フレームワークが実行と最適化を処理
  • LLMOpsの簡素化とデータキュレーションに必要な労力の削減により、チームはボイラープレートよりもビジネス成果に集中できる
  • あるチームは前臨床R&D向けの複雑なRAGソリューションを評価・構築する際、カスタムエージェントと組み合わせて使用
  • すでにDatabricksエコシステムに投資しており、チャットボットや文書抽出のような一般的ユースケースでエージェントベースのアプローチを検討しているなら、評価に値する

54. DuckLake

  • 標準SQLデータベースをカタログとメタデータ管理に使用することでlakehouseアーキテクチャを簡素化する、統合データレイク兼カタログ形式
  • 従来のオープンテーブル形式であるIcebergやDelta Lakeが複雑なファイルベースのメタデータ構造に依存するのに対し、DuckLakeはメタデータをカタログデータベース（SQLite、PostgreSQL、DuckDBなど）に保存しつつ、データはローカルディスクやS3互換オブジェクトストレージ上のParquetファイルとして保持する
  • このハイブリッドアプローチにより、クエリ計画の遅延と同時更新時のトランザクション信頼性が改善される
  • DuckDBはducklake拡張を通じてクエリエンジンの役割を果たし、標準DDLおよびDML操作向けの馴染みあるSQLインターフェースを提供
  • パーティショニングのようなlakehouseの特性は維持しつつ、インデックスと主キー/外部キーは省略
  • タイムトラベル、スキーマ進化、ACID準拠をサポートし、独立した分析スタックを目指すチームに低複雑性の選択肢を提供
  • まだ成熟度は初期段階だが、従来のlakehouseアーキテクチャに対する有望で軽量な代替
  • SparkやTrinoベースのエコシステムに伴う運用オーバーヘッドを避けたい場合に、簡素化されたデータ環境に適している

55. FalkorDB

  • CypherをサポートするRedisベースのグラフデータベースで、重量級のグラフプラットフォームを導入せずにグラフ機能を求めるチームに適している
  • 運用上の摩擦が少ないことが重要な、関係性が豊富なAIおよびアプリケーションワークロードを構築する際や、組み込みストレージよりサーバーベースのグラフサービスが好まれる組織にとって実用的な選択肢
  • アーキテクチャは有望で開発者モデルも扱いやすいが、広範な導入を決める前に、FalkorDBのスケーリング、運用ツール、長期的なエコシステム成熟度に関する本番動作の検証が必要

56. Google Dialogflow CX

  • Google Cloudのマネージド対話型AIプラットフォームで、FlowsとPagesで構築されたグラフベースの状態機械とVertex AI Geminiベースの生成機能を組み合わせている
  • 以前、その前身であるDialogflowをRadarで取り上げていた
  • CXは大幅な再設計を示すもので、2024年にGoogleがVertex AI Geminiモデルを統合して以降注目を集め、指示ベースのエージェント向けGenerative Playbooksと、インデックス化されたコンテンツに応答をグラウンディングするData Store RAGを導入した
  • 自然言語によるデータ探索エージェントの構築に使用され、ローコード環境とGenerative Playbooksを理由に、カスタムSDKアプローチよりもDialogflow CXが選ばれた
  • 自然言語クエリをSQLへ変換するためのfew-shotプロンプティングで構成
  • Google Cloud上に構築しているチームが、構造化された社内データの上に自然言語インターフェースを構築する際、カスタムエージェントスタックよりも提供速度が速いと感じている
  • ただし、無料ティアはなく、Google Cloudへの深い依存によって大きなベンダーロックインが生じるため、コンテキストエンジニアリングの工数も見込む必要がある

57. MCP Apps

  • Model Context Protocolの最初の公式拡張であり、MCPサーバーがダッシュボード、フォーム、可視化として会話内で直接レンダリングされるインタラクティブなHTMLインターフェースを返せるようにする
  • Anthropic、OpenAI、オープンソース貢献者が共同開発し、ツールがui://リソーススキーマを標準化することで、ホストにUIサポートがない場合はテキストへ自然にフォールバックするサンドボックスiframe内でレンダリングされるUIテンプレートを宣言できる
  • 別個のライブラリ層として動作するAG-UIとは異なり、MCP AppsはUIをMCPサーバー内部に直接パッケージングする
  • 双方向設計によりモデルはユーザー行動を観察でき、インターフェースはテキストでは不可能なリアルタイムデータと直接操作を扱える
  • Claude、ChatGPT、VS Code、Gooseを含むクライアントがすでにサポートを公開
  • より豊かなエージェント間相互作用を模索するチームは、プレーンテキスト応答と比べた追加の複雑さがユースケースに見合うか評価する必要がある

58. Monarch

  • 単一マシンのPyTorchワークロードのシンプルさを大規模GPUクラスタへ持ち込むオープンソースの分散プログラミングフレームワーク
  • リモートプロセスとアクター生成用のPython APIを提供し、これらをブロードキャストメッセージングをサポートするmeshコレクションとしてグループ化
  • supervision treeによるフォールトトレランスを提供し、障害が階層を上って伝播することで、クリーンなエラー処理ときめ細かな復旧が可能
  • 効率的なGPU・CPUメモリ移動のためのpoint-to-point RDMA転送をサポートし、アクターが命令型プログラミングモデルを維持したまま、プロセス全体に分割されたテンソルを扱える分散テンソル抽象化を提供
  • Monarchは高性能なRustバックエンド上に構築
  • まだ開発初期段階だが、分散テンソルをローカルのように動作させる抽象化が強力で、大規模分散AI学習の複雑さを大幅に減らせる可能性がある

59. Neutree

  • プライベートインフラ上でLLMを管理・サービングするオープンソースプラットフォームで、エンタープライズAI向けのモデルサービスレイヤーとして位置付けられている
  • モデルライフサイクル管理、推論サービング、NVIDIA・AMD・Intelアクセラレータのような異種ハードウェア全体でのコンピューティングスケジューリングのための統合コントロールプレーンを提供
  • 組織がホスト型APIから自前ホスティングかつガバナンスされたデプロイへ移行する中で、Neutreeは明確なギャップを解消している — マルチテナンシー、アクセス制御、使用量会計、インフラ抽象化といったエンタープライズ級の機能でLLMワークロードを運用
  • モデルサービングをアプリケーションロジックから分離することで、チームは特定クラウドベンダーに強く縛られることなく、ベアメタル、VM、コンテナを含む環境全体にわたってモデルをデプロイ・拡張・ルーティングできる
  • ただし比較的新しく、導入には慎重なアプローチが必要
  • エコシステム、運用成熟度、統合能力は、より確立されたMLプラットフォームと比べると依然として進化途上
  • 有望ではあるが、新興エンタープライズAIインフラの評価と形成に投資する意思のあるチームに最も適している

60. OptScale

  • GPUや実験コストが急速に膨らみうるAI/ML中心の重いワークロードを支えるオープンソースのマルチクラウドFinOpsプラットフォーム
  • クラウドAPIから課金および利用データを収集し、単一システム内でコスト可視化、最適化の推奨、予算追跡、異常検知を、チームや事業構造に沿ったポリシーベースのアラートと組み合わせる
  • OpenCostと比べるとOptScaleはKubernetesレベルの分析を提供しつつ、より広範な非Kubernetes FinOpsユースケースもカバー
  • IBM Cloudability、CloudZero、CloudHealth、IBM Kubecost、Flexera Oneのようなエンタープライズスイートよりより多くの制御性と少ないベンダーロックインを提供
  • トレードオフとして、より高い運用オーバーヘッド、デプロイの複雑さ、コネクタのエッジケース、コンテナイメージのセキュリティ衛生に関する懸念がある
  • プラグアンドプレイ製品ではなく、プラットフォーム能力への投資として扱う必要がある

61. Rhesis

  • LLMおよびagenticアプリケーション向けのオープンソーステストプラットフォームで、チームは自然言語で期待動作を定義し、敵対的テストシナリオを生成し、UIとSDKまたはAPIの両方から結果を評価できる
  • 従来のテスト手法が決定論的な振る舞いを前提とするのに対し、AIシステムはより微妙な形で失敗する — jailbreak、マルチターン相互作用、ポリシー違反、コンテキスト依存のエッジケースを含む
  • 単純なプロンプト評価以上のものを必要とするチームに有用なプラットフォーム
  • conversation simulator、敵対的テスト、OpenTelemetryベースのトレース、Dockerによるセルフホスティングのような機能は、プロダクト・ドメイン・エンジニアリングの各チームを共通のテストワークフローに取り込む実用的な方法
  • 主な利点は、非決定論的システムに対する本番前検証の改善
  • 評価コスト、LLM-as-judgeメトリクスの限界、価値を発揮する前に明確に定義された要件が必要であることなど、一般的なトレードオフへの配慮が必要
  • 基本的なプロンプトチェックを超える協調的で反復可能なテストを必要とするLLMやagenticシステムを構築するチームには、評価する価値がある

62. RunPod

  • 組織でLLMの学習やファインチューニング実験が増えるにつれ、AWSやGoogle Cloudのようなハイパースケーラーは高コストと限られたハードウェア可用性をもたらしうる
  • RunPodは、コンピュート集約型AIワークロード向けのコスト効率の高い代替手段を提供
  • グローバルに分散したGPUマーケットプレイスとして運営され、エンタープライズ向けH100クラスタからコンシューマ向けRTX 4090まで、幅広いハードウェアへのオンデマンドアクセスを提供し、しばしば従来のクラウドプロバイダより大幅に低コスト
  • 長期契約やベンダーロックインなしに、AIモデルの開発・学習・デプロイを行うための柔軟で予算に優しいインフラを必要とするチームにとって、評価に値する実用的な選択肢

63. Sprites

  • AIコーディングエージェントの隔離実行のために設計されたFly.ioのステートフルなサンドボックス環境
  • 多くのエージェントサンドボックスがタスクのために生成されて消える使い捨て型である一方、Spritesは無制限のチェックポイントと復元機能を備えた永続的なLinux環境を提供
  • 開発者は、インストール済み依存関係、ランタイム設定、ファイルシステム変更を含む環境状態全体をスナップショットでき、エージェントが脱線した場合にロールバックできる
  • これはGitだけでは復旧できない範囲を超え、バージョン管理が追跡しないシステム状態を捕捉する
  • チームがsandboxed execution for coding agentsを妥当なデフォルトとして採用しつつある中で、Spritesはスペクトラムの一端を代表する — 使い捨てコンテナの単純さと引き換えに、より豊富な復旧オプションを得る非使い捨てのステートフルアプローチ
  • エージェントサンドボックスを評価するチームは、ニーズやワークフローに応じて、Dev Containersのような使い捨て型の代替手段とあわせてSpritesも検討するとよい

64. torchforge

  • 言語モデルの大規模な事後学習のために設計されたPyTorchネイティブの強化学習ライブラリ
  • アルゴリズムロジックをインフラ上の関心事から分離する高レベル抽象化を提供し、調整にはMonarch、推論にはvLLM、分散学習にはtorchtitanをオーケストレーションする
  • このアプローチにより、研究者は疑似コードのようなAPIで複雑な強化学習ワークフローを表現でき、リソース同期・スケジューリング・フォールトトレランスといった低レベルな関心事を管理することなく、数千GPU規模へワークロードを拡張できる
  • 「何を」（アルゴリズム設計）と「どのように」（分散実行）を分離することで、torchforgeは大規模アライメントシステムにおける実験と反復を簡素化する
  • 高度な事後学習手法をより利用しやすくする有用な一歩だが、チームは既存のMLインフラ内での成熟度と適合性の評価が必要

65. torchtitan

  • 生成AIモデルの大規模な事前学習のためのPyTorchネイティブプラットフォームで、高性能な分散学習向けのクリーンかつモジュール式の参照実装を提供
  • 高度な分散プリミティブを一貫したシステムにまとめ、**データ・テンソル・パイプライン・コンテキスト並列化の4D並列化**をサポート
  • Llama 3.1 405B規模のモデル学習が相当なスケールと効率を要求する中、torchtitanは大規模学習ワークロードの構築・運用における実用的な基盤を提供
  • モジュール式設計により、チームは本番対応性を維持しながら並列化戦略を実験・進化させやすい
  • PyTorchエコシステムにおける大規模モデル学習の標準化に向けた有用な一歩であり、とりわけ自前の事前学習インフラを構築するチームに適している

[Tools]

Adopt

66. Axe-core

  • Webサイトやその他のHTMLベースのアプリケーションにおけるアクセシビリティ問題の検出のためのオープンソーステストツール
  • WCAG のような標準への準拠をページ単位でチェック — A、AA、AAA の適合レベルを含む — し、一般的なアクセシビリティのベストプラクティスを示す
  • 2021年に Trial として Radar に初登場して以降、複数のチームがクライアントで Axe-core を導入
  • アクセシビリティはますます必須の品質特性となっており、欧州では European Accessibility Act のような規制によって、組織にデジタルサービスのアクセシビリティ要件への適合が義務付けられている
  • CIパイプラインで自動チェックを有効化できるため、現代の開発ワークフローによく適合
  • チームが回帰防止、コンプライアンス維持、開発中の早期フィードバック獲得に役立ち、特にAI支援や agentic コーディングツールが広く導入される際に、アクセシビリティをフィードバックループの一部として確実に組み込める

67. Claude Code

  • Anthropic の、複雑な多段階ワークフローを計画・実行する agentic AI コーディングツール
  • Thoughtworks の内外のチームが本番ソフトウェアの提供に日常的に使用しており、能力と使いやすさのベンチマークとして広く扱われていることから Adopt に移行
  • CLIエージェント環境は OpenAI の Codex CLI、Google の Gemini CLI、OpenCode、pi のようなツールによって急速に拡大したが、Claude Code は多くのチームで好まれる選択肢となっている
  • 利用はコード作成を超えて、仕様、ストーリー、構成、インフラ、ドキュメント、markdown で定義されたビジネスプロセスを含む幅広いワークフロー実行へと拡大
  • スキル、サブエージェント、リモート制御、agentic なチームワークフローなど、他のツールが追随する機能を継続的に導入
  • 導入チームには節度ある運用実践とペアリングが必要であり、agentic コーディングは開発者の労力を手動実装から意図、制約、レビュー境界の明示へと移している
  • デリバリーを加速できる一方で、AI生成コードに対する無自覚さ のリスクが高まり、人間とエージェントの双方にとってシステムの維持・進化が難しくなる
  • agentic ワークフローをより信頼できるものにする コンテキストエンジニアリング（トピック認識、スコープベースのコンテキスト選択）や、curated shared instructions の実装方法としての harness engineering への関心が高まっている

68. Cursor

  • Claude Code と並び、デリバリーチームのデフォルト選択肢として一貫して挙げられる、最も広く採用されているコーディングエージェントの1つ
  • plan mode、hooks、subagents といった機能を備えた総合的な agentic 環境へと成熟
  • ターミナルベースのエージェントも人気だが、多くの開発者は IDE 内でのエージェント監督のほうが、実行前に計画をレビュー・洗練するうえでより豊かな体験を提供すると感じている
  • Agent Client Protocol の導入により、大規模な JetBrains ユーザーベースへの障壁が下がり、Cursor の機能をそれらのIDEで利用できるようになった
  • 個々のエージェントステップを検査する能力や、計画から逸脱した際に前のステップへロールバックできる能力が特に価値を持つ
  • Agent Skills の活用により、チームは再利用可能な指示をパッケージ化し、エージェントが複雑なコードベースとやり取りする方法の標準化を支援できる
  • 生産性向上の効果は明確だが、agentic な自律性には依然として、微妙な回帰を捉えるための厳格な自動テストと人間の監督が必要

69. Kafbat UI

  • Apache Kafka クラスターの監視・管理向け無料オープンソースWeb UI
  • チームが日常的なデバッグで読みづらいペイロードを検査する必要があるときに特に有用
  • チームはしばしば暗号化されたメッセージのデバッグで行き詰まるが、Kafbat UI の組み込みおよびプラグイン可能な SerDes サポートにより、復号やカスタムデコードを適用してメッセージを再読可能にする実用的な方法が得られる
  • 単発のデバッグスクリプトよりも速いフィードバックを提供し、開発者チームとサポートチームの双方により良い運用体験をもたらす
  • 安全なメッセージ検査と効率的な問題解決が標準的な実践であるべき Kafka ヘビーな環境に推奨

70. mise

  • 前回の評価以降、asdf の高性能な代替から、開発環境のデフォルトフロントエンドへと進化
  • ツール・言語バージョン管理、環境変数管理、タスク実行という3つの分断された関心事を、宣言的な mise.toml ファイルで構成される単一の高性能な Rust 製ツールに統合
  • mise は設定が容易で、CI/CDパイプラインともよく連携する
  • Cosign や GitHub Artifact Attestations との統合を通じて、他のバージョンマネージャーではしばしば欠けているサプライチェーンセキュリティ層を追加
  • 開発者環境設定の標準化を目指すチームにとって推奨されるデフォルト
  • 複数のマイクロサービスからなる polyglot 環境で、コードベースが同時に新しい言語バージョンを採用する際に特に有用
  • 既存の言語別ツールとも連携できるため、チームは一度にすべてを移行する必要がない

Trial

71. cargo-mutants

  • Rust向け mutation testing ツールで、単純なコードカバレッジ指標を超える助けとなる
  • 演算子の入れ替えやデフォルト値の返却といった小さく意図的なバグを自動注入し、既存テストが回帰を本当に検出できるかを検証
  • ゼロコンフィグのアプローチが特に効果的で、以前のツールと異なりソースツリーの変更が不要
  • Rust 初学者のチームに有用なフィードバックループを提供し、見落とされたエッジケースの特定と単体・統合テストの信頼性向上に役立つ
  • cargo-mutants は、他のエコシステムでも試みられている mutation testing の特化実装
  • 主なコストはテスト実行時間の増加で、各 mutant が増分ビルドを必要とする
  • 管理のため、ローカル開発中は特定モジュールを対象にするか、CIで全スイートを非同期実行することを推奨
  • 論理的に等価な mutant をフィルタリングする必要が生じることもあるが、結果として得られるテスト信頼性の向上は追加のノイズを上回る

72. Claude Code plugin marketplace

  • 以前は、カスタムコマンド、専門エージェント、MCP サーバー、スキルの共有は、開発者が Confluence やその他の外部ソースから指示をコピー＆ペーストする手動プロセスだった
  • その結果、しばしばバージョンドリフトが発生し、チームメンバーが古いプロジェクト指示を使っていた
  • チームは Claude Code plugin marketplace を活用し、Git ベースの配布モデルを用いて共有コマンド・プロンプト・スキルを配布している
  • GitHub や類似プラットフォーム上で社内チーム向けマーケットプレイスをホストすることで、組織はこれらのアーティファクトをより安全かつ一貫して配布できる
  • 開発者は CLI を通じて AI ベースのワークフローやツールをローカル環境に直接同期できる
  • Cursor のような他のコーディングエージェントもチームの plugin marketplace をサポートしており、こうしたアーティファクト共有の、より簡素でガバナンスの効いた方法を可能にしている

73. Dev Containers

  • devcontainer.json 構成ファイルを使って、再現可能なコンテナ化開発環境を定義するための標準化された方法
  • もともとはチームに一貫した開発設定を提供するために設計されたが、コーディングエージェント向けのサンドボックス実行環境として魅力的な新たなユースケースが見いだされた
  • Dev Container 内で AI コーディングエージェントを実行すると、ホストのファイルシステム・認証情報・ネットワークから隔離されるため、チームはホストマシンを危険にさらすことなくエージェントに広範な権限を付与できる
  • オープン仕様 は VS Code や Cursor などの VS Code ベースのツールでネイティブサポートされている
  • DevPod は SSH を通じて、任意のエディターやターミナルのワークフローへ devcontainer サポートを拡張している
  • 使い捨てを基本とするアプローチ（つまり、コンテナを起動のたびに構成から再構築する）を採用することで、ツールや依存関係の再インストールというコストはあるが、クリーンなセキュリティ境界を提供する
  • 永続状態やチェックポイント・リストア機能が必要なチームには、Sprites のような別のアプローチが代替となる
  • エージェントのサンドボックス化に加え、サプライチェーンセキュリティ上の利点もあり、ツールチェーンを宣言的構成で定義することで、侵害されたパッケージや想定外の依存関係への露出を低減する

74. Figma Make

  • 以前は self-serve UI prototyping with GenAI の blip だったが、この手法は今ではプロダクトマネージャーやデザイナーを含む開発チームによって、ユーザーテスト可能な高忠実度プロトタイプの生成に広く採用されている
  • Figma Make は、デザインシステムの実際のコンポーネントとレイヤーを活用して、結果を本番アプリケーションに非常に近いものにできる強力な選択肢だ
  • 高品質なデザインパターンで訓練されたカスタム AI モデルを使用している
  • チームはこれを、新しいデザイン画面の作成、既存画面の改善、迅速なユーザーフィードバック収集のための共有可能なプロトタイプの構築に使っている

75. OpenAI Codex

  • macOS アプリと CLI で利用できる独立した agentic コーディングツールへと進化した
  • 自律的な作業委任向けに設計されており、プロンプトが与えられると最小限の介入でファイル全体にわたって計画・実装・反復を行う
  • 高速なドラフト作成ツールとして効果的で、特にグリーンフィールド作業や反復的な実装作業で有用
  • ただし、OpenAI Codex は論理的には妥当だが機能面では古いライブラリパターンを提案しがちであるため、自動テストと人間によるレビューが不可欠
  • この Radar にある他の agentic ツールと同様、微妙な技術的負債が蓄積するリスクは現実的であり、その度合いはチームが与える自律性のレベルに比例する

76. Typst

  • プログラムによる文書生成のための LaTeX の現代的な後継として位置づけられる、マークアップベースの組版システム
  • 高品質なタイポグラフィとよりシンプルな構文を組み合わせ、非常に大きな文書でも従来の LaTeX ツールチェーンの数分の一の時間でコンパイルするかなり高速なコンパイルパイプラインを提供する
  • Typst はより明確なエラーメッセージと、条件分岐やループなどの組み込みスクリプティング機能を備えている
  • JSON や CSV から構造化データを読み込めるため、自動化された文書生成に非常に適している
  • チームはこれを、一貫した形式で大規模生成が必要な銀行・金融サービス顧客向けの明細書やレポートの作成に利用している
  • オープンソースのコンパイラはセルフホスト可能で、成長中のエコシステムにはコミュニティ提供パッケージも含まれる
  • LaTeX より扱いやすく、それでいて同等のタイポグラフィ品質を実現する

Assess

77. Agent Scan

  • MCP サーバーやスキルを含むローカルコンポーネントを発見し、プロンプトインジェクション、ツール汚染、toxic flow、ハードコードされたシークレット、安全でない認証情報処理といったリスクを検出するエージェントエコシステム向けセキュリティスキャナー
  • エージェントのサプライチェーン可視性における新たなギャップに対処し、急速に拡大するエージェントの攻撃対象領域をインベントリ化してテストする実用的な方法を提供する
  • ただし導入は慎重であるべきで、スキャンにはコンポーネントメタデータを Snyk API と共有する必要があり、シグナル品質や false positive 率は各環境で検証する必要がある
  • チームが Agent Scan を必須のデリバリーゲートの一部にする前に、運用上の価値を確認することが重要

78. Beads

  • コーディングエージェント向けの永続メモリレイヤーとして設計された Git ベースのイシュートラッカー
  • 一時的な Markdown 計画に頼る代わりに、エージェントにブロッカー関係、準備作業の検出、セッションをまたぐ長期作業の調整のための、ブランチフレンドリーな構造を持つタスクグラフを提供する
  • Beads は、Git リポジトリと同様にブランチ、マージ、diff、テーブル複製をサポートする、バージョン管理機能を組み込んだ SQL データベース Dolt 上に構築されている
  • エージェントネイティブなプロジェクトメモリとタスク追跡ツールの新しいカテゴリを象徴している
  • この分野の他の初期プロジェクトには ticket と tracer がある
  • GitHub Issues や Jira のような従来のチケット管理システムとは異なり、エージェント同士のタスク割り当てを含む、自律的なマルチエージェント実行の調整という新しいワークフローを可能にする

79. Bloom

  • LLM の挙動を評価する AI 安全性研究者向けの Anthropic ツール
  • sycophancy（おべっか）や self-preservation（自己保存）といった挙動を検出する
  • 静的ベンチマークに対し、対象の挙動と評価パラメータを定義するシード設定を用いて多様なテスト会話を動的に生成し、その結果を評価する
  • この自動化された行動評価へのアプローチは、モデルのリリース速度に追随するために不可欠であり、外部研究チームでも評価を実施できるようにする
  • Petri は付随ツールとして、与えられたモデルでどのような挙動が現れるかを特定し、Bloom はそれらの挙動がどのシナリオでどの程度の頻度で起きるかを特定し、両者でより完全な評価スイートを構成する
  • Bloom には与えられた生徒モデルを評価する教師（または評価者）モデルが必要という懸念があり、教師モデルには盲点やバイアスがあり得るため、複数の評価者を使うことで結果の偏りを低減できる
  • AI 安全性研究チームにとって、新たに現れるモデル挙動の評価において静的ベンチマークを補完するものとして検討する価値がある

80. CDK Terrain

  • 2025年12月にHashiCorpが廃止・アーカイブした Cloud Development Kit for Terraform（CDKTF）のコミュニティフォーク
  • CDK Terrain（CDKTN）はCDKTFが中断された地点を引き継ぎ、チームはTypeScript、Python、Goでインフラを定義し、TerraformまたはOpenTofuを通じてプロビジョニング可能
  • すでにCDKTFに投資しているチームにとって、既存のコードとワークフローを維持しつつ、HCL や Pulumi への強制移行ではなく 移行パスを提供
  • プロジェクトは毎月リリースされ、OpenTofuサポートを第一級の対象として追加
  • ただし ベンダーが放棄したプロジェクトのコミュニティ維持フォークには、長期サポートに関する本質的なリスク が伴い、CDKTFのアプローチは広範な採用を達成できなかった
  • HashiCorpは終了時にプロダクト・マーケット・フィットの不足を理由として挙げた
  • 現在CDKTFを使っているチームは、継続の選択肢としてCDK Terrainを評価しつつ、より広く支援されたアプローチへ移行すべき適切な時期かどうかも見極める 必要がある

81. CodeScene

  • 2017年にsocial code analysisがブリップに登場したが、コーディングエージェント導入の増加により CodeScene のようなツールへの新たな関心 が生まれている
  • コード複雑性メトリクスとバージョン管理履歴を組み合わせ、技術的負債を特定する行動コード分析ツール
  • 従来の静的解析と異なり 「hotspot」を強調 することで、チームが実際の開発活動とビジネス影響に基づいてリファクタリングの優先順位を付けるのを支援
  • 現在は AIフレンドリーなコード設計 のためのガイダンスも提供
  • チームは、コーディングエージェントが人間の開発者よりはるかに速くコードを修正できるため、コード品質がさらに重要になる ことを実感している
  • CodeSceneのCodeHealthメトリクスは、LLMが幻覚リスクなしに安全にリファクタリングするには複雑すぎる領域を特定 でき、有用なガードレールを提供
  • コーディングエージェント導入時のガードレールとして評価を推奨。CodeHealthメトリクスは 安全なリファクタリング対象を強調 し、エージェント適用前に改善が必要な領域を示す

82. ConfIT

  • 統合およびコンポーネントスタイルのAPIテストを、コードで命令的に記述する代わりに JSONで宣言的に定義 するライブラリ
  • 大規模なテストスイートでは、HTTPクライアント、リクエスト設定、アサーション周りのボイラープレートが蓄積しがちなため、このアプローチへの関心が高まっている
  • AI支援開発がこの傾向を強めており、構造化されたテスト定義は冗長な手続き型コードより生成・保守しやすい
  • クライアントの経験と評価に基づくと、宣言的レイヤーはコンポーネントテストと統合テストの重複を減らし、可読性を改善し、チーム全体でテスト意図を進化させやすくする
  • しかし ConfIT 自体は コミュニティ導入が限定的で、エコシステムも小さい ため、こうした利点があっても広範には推奨しにくい
  • 仕様主導のAPIテストを探る .NET チームには評価する価値があるが、長期的な維持可能性、エコシステム適合性、運用上のトレードオフの検証 が必要

83. Entire CLI

  • Gitワークフローにフックし、AIコーディングエージェントのセッション — transcript、prompt、tool call、変更対象ファイル、トークン使用量 — を、専用のリポジトリブランチに保存された検索可能なメタデータとしてキャプチャ
  • Claude Code、Gemini CLI、OpenCode、Cursor、Factory AI Droid、GitHub Copilot CLIをサポート
  • AIエージェントがコードベースの主要な貢献者になるにつれ、チームは Gitが追跡する内容とコーディングセッション中に実際に起きていることの間のギャップ拡大 に直面している
  • Entire CLI は、メインブランチの履歴を汚さずに コミットとともに完全なセッションを記録し、エージェント活動の監査証跡 を生成する
  • チェックポイントシステムも実用的な復旧を可能にし、チームはエージェントが逸脱した際に既知の正常状態へ巻き戻し、任意のチェックポイントから再開できる
  • ツールは非常に新しく、エージェントセッションのトレーサビリティのエコシステムもまだ形成途上だが、AI生成コードに関するコンプライアンスや監査要件を持つチーム にとって、Gitネイティブなセッションキャプチャは自然に適合する

84. Git AI

  • リポジトリ内で AI生成コードを追跡 し、AIが書いたすべての行を、それを生成したエージェント、モデル、プロンプトに結び付けるオープンソースのGit拡張
  • Git AI はチェックポイントとフックを使って、コミット開始から終了までの 増分コード変更を追跡 する
  • 各チェックポイントには現在の状態と前のチェックポイント間のdiffが含まれ、AI作成か人間作成かが示される
  • このアプローチは、挿入時点でコード行数のカウントに集中するアプローチより 正確
  • Git Notesを使った、AI生成コード追跡のための オープン標準 を採用
  • 対応エージェントのエコシステムはまだ成熟途上だが、agenticワークフローで長期的な説明責任と保守性を維持したいチーム にとって評価する価値がある
  • 人間とAIエージェントの両方が /ask スキルを通じてアーカイブされたエージェントセッションを参照し、特定のコードブロックの背後にある本来の意図やアーキテクチャ上の判断を照会 できる

85. Google Antigravity

  • Windsurfからライセンスされた技術の上に構築された独立したVS Codeフォークで、2025年11月にGemini 3とともに 公開プレビューとしてリリース
  • IDEを マルチエージェントオーケストレーション中心に再構成 — Agent Managerが作業全体で複数エージェントを並列実行し、内蔵ChromiumブラウザによりエージェントがライブUIと直接対話し、スキルシステムは再利用可能なエージェント指示をリポジトリに保存
  • Agent Managerは標準的なチャットサイドバーというより 「Mission Control」ダッシュボード として機能し、開発者の役割を行単位のコード記述から 複数の自律的ワークストリームのオーケストレーション へと根本的に転換
  • 必要に応じて、開発者は依然としてhuman-in-the-loop（HITL）の制御のためにエディタに入ることができる
  • Google Antigravity は Model Context Protocol を通じてGoogle CloudおよびFirebaseと統合し、Agent Development Kit によりエージェント開発を支援
  • 公開プレビューの状態にあり、GA日は未定で、セキュリティ体制とエンタープライズ対応性はなお進化の途中
  • マルチエージェント実行モデルと自律ブラウザアクセスは、agentic IDEの方向性を示している

86. Google Mainframe Assessment Tool

  • 組織によるメインフレーム上で動作するアプリケーションのリバースエンジニアリングを支援し、ポートフォリオ全体または個別システムを分析
  • 中核では決定論的言語パーサーに依存し、コードベース全体の呼び出しフローとデータ依存関係をマッピングして、アプリケーション同士の相互作用方法の構造的ビューを生成
  • この基盤の上で生成AI機能が要約、ドキュメント化、テストケース生成、モダナイゼーション提案を提供
  • このアプローチはGenAIを使ったレガシーコードベース理解のより広範なパターンと整合しており、システムに対する強力な洞察がAIを効果的に活用する基盤を形成
  • Google Mainframe Assessment Toolはまだすべての主要メインフレーム技術スタックをサポートしていないが、急速に進化中
  • チームはメインフレームアプリケーションの発見とモダナイゼーションに焦点を当てたクライアント案件で有用だと見出している

87. OpenCode

  • 強力なターミナル優先の体験を持つ、最も注目されるオープンソースのコーディングエージェントの1つとして急速に台頭
  • 主な強みはモデルの柔軟性で、ホスト型のフロンティアモデル、自前でホストするエンドポイント、ローカルモデルをサポート
  • OpenCodeを、コスト管理、カスタマイズ、エアギャップ構成を含む制約のある環境にとって魅力的なものにしている
  • これは、ユーザーがサブスクリプションやAPI利用時のライセンスとプロバイダーの規約を明示的に意識する必要があることも意味する
  • OpenCodeの拡張モデルも魅力のもう1つの核で、チームごとのワークフロー、ツール、ガードレール向けのプラグインとMCP統合の両方をサポート
  • 多くのユーザーがOh My OpenCodeを活用しており、調整済みのエージェントチームとより豊富なオーケストレーションパターンを備えた、より意見のあるbatteries-includedな構成を提供する任意だが人気の高いハーネス

88. OpenSpec

  • AIコーディングエージェントの能力進化に伴い、要件やコンテキストが一時的なチャット履歴にしか存在しない場合、開発者は予測可能性と保守性の課題にますます直面
  • これに対処するため、spec-driven development（SDD）ツールが登場
  • OpenSpecは、コード生成前に人間の開発者とAIエージェントが何を構築するかについての整合を保証する軽量な仕様レイヤーを導入するオープンソースのSDDフレームワーク
  • 差別化要因は流動的で最小限のワークフローで、しばしば3段階の propose → apply → archive にまで縮小される
  • 多くのSDDフレームワーク（GitHub Spec Kitなど）やAgentic Skillsワークフロー（Superpowersなど）は、ブラウンフィールドよりグリーンフィールドプロジェクトにより適している
  • OpenSpecは完全な仕様を先に定義する代わりにspec deltasに集中している点が特に優れており、既存システムによく適合する
  • より厳格なワークフローを強制する重厚な代替手段（BMADなど）や、ベンダー固有のIDE統合を必要とするもの（Kiroなど）と異なり、反復的でツール中立
  • 重いプロセスを採用せずにAI支援開発へ構造と予測可能性を導入したいチームにとって、評価する価値のある開発者フレンドリーなフレームワーク
  • 同時に、モデルとコーディングエージェントがより強力になるにつれて、チームがネイティブ機能を監視・見直しし、SDDツールの必要性を再評価することも推奨

89. PageIndex

  • 従来の埋め込みベース検索への依存ではなく、ベクトルを使わない推論ベースRAGパイプライン向けの文書の階層インデックスを構築するツール
  • 文書をベクトル用にチャンク化すると構造情報が失われ、結果がなぜ検索されたかの可視性が制限されうるのに対し、PageIndexはLLMが段階的にたどって関連コンテンツを検索する目次インデックスを構築
  • 人間が見出しをざっと見てから特定セクションへ深掘りするやり方と同様に、特定のセクションが選ばれた理由を説明する明示的な推論トレースを生成
  • 意味よりも構造に大きく依存する文書、たとえば数値データを含む財務報告書、相互参照条項を持つ法務文書、複雑な臨床文書や科学文書でうまく機能
  • ただしトレードオフもあり、LLMの推論が検索プロセスの一部となるため、特に大きな文書では相当な遅延とコストを導入する可能性がある

90. Pencil

  • CursorやClaude CodeのようなIDEやコーディングエージェントと統合されるデザインキャンバスツール
  • 現在は読み取りアクセスしか提供しないFigmaと異なり、Pencilは双方向のローカルMCPサーバーを実行し、キャンバスを直接操作するための読み書き両方のアクセスを提供
  • Figma MakeやBuilder.ioのようなツールと同様にデザインからコードへの機能も提供するが、より開発者中心のアプローチで、デザインファイルは.penというオープンなJSON形式でリポジトリに保存され、コードと一緒にデザイン資産のバージョン管理が可能
  • 開発者に馴染みのあるツールとの統合により、デザインと開発のハンドオフのギャップを埋める助けになる
  • 大規模で複雑なデザインシステムでは、Figmaが依然として役割横断的なコラボレーション標準
  • しかし、専任デザイナーがいないチームや高いデザインスキルを持つ開発者がいるチームにとっては検討する価値がある

91. Pi

  • TypeScriptで書かれたミニマリストなオープンソースのターミナルコーディングエージェント
  • 主流のエンタープライズ標準ではなく、いじり手や実験志向のユーザーに魅力的な選択肢
  • Piは、OpenCodeのような完成度の高いエージェントよりよりカスタマイズしやすいベアボーンのハーネス
  • ADK、LangGraph、Mastraのようなagenticフレームワークで新しいエージェントを構築するより適応しやすい
  • 強い勢いと活発なリリースにもかかわらず、プロジェクトは依然として初期段階で、主にメンテナー主導
  • piは完全なガードレールとサポートを備えたエンタープライズプラットフォームではなく、エンジニア向けのビルディングブロックとして扱う必要がある

92. Qwen 3 TTS

  • 多くの有料APIより大きな開発者コントロールを提供しつつ、商用製品との品質ギャップを大きく縮めるオープンソースのテキスト読み上げモデル
  • 多言語をサポートし、短いサンプル（約10〜15秒）からのボイスクローニングが可能で、ドメイン特化またはキャラクター特化の音声向けに事後学習のファインチューニングも許容
  • ブランド固有の音声やオンプレミスでの制御が必要なチームにとって魅力的な選択肢
  • Qwen 3 TTSはまだ最近リリースされたばかりであり、チームは本番で重要な音声ワークロードに導入する前に安定性、安全制御、ライセンス適合性、運用成熟度を検証する必要がある

93. SGLang

  • フロントエンドのプログラミング言語とバックエンドのランタイムを共同設計することで、LLM推論の計算オーバーヘッドを削減する高性能サービングフレームワーク
  • RadixAttentionを導入し、プロンプト全体のKV（キー・バリュー）状態を積極的にキャッシュ・再利用するメモリ管理手法
  • このアプローチは、prefix overlapが高いシナリオで、vLLMのような標準的なサービングエンジンと比べて大幅な性能改善をもたらす
  • 複雑な自律エージェントの構築、長いシステムプロンプトへの依存、共有例を用いた広範なfew-shotプロンプティングを行うチームにとって、SGLangはレイテンシと効率性の面で大きな利点をもたらす可能性がある

94. ty

  • Pythonは、特にAIやデータサイエンス分野で人気が伸び続けており、強力な型システムを持つことの価値がますます高まっている
  • TyはRustで書かれた非常に高速なPython型チェッカーと言語サーバー
  • uvやruffといったツールも含む、Astralエコシステムの一部
  • 高速なフィードバックを提供し、Visual Studio Codeのような一般的なエディターとうまく統合できる
  • tyを他のAstralツールと組み合わせて使うことで、大規模組織におけるPython開発を単純化できる
  • agenticコーディングが一般化するにつれて、高速なフィードバックループを備えた決定論的な型チェッカーを持つことが、ミスの早期発見や単純なエラーに対するコードレビュー工数の削減に役立つ

95. Warp

  • Radarに最後に掲載されて以降、Warpは**「AI機能を備えたターミナル」という説明を大きく超えて進化**した
  • ブロックベースのコマンド出力、AIによる提案、ノートブック機能というコアの強みを維持しつつ、従来IDEが担ってきた領域へと拡張している
  • 現在ではMarkdownレンダリング、ファイルツリー表示、ターミナルから直接ファイルを開くことが可能で、複数ペインにまたがる完全なagentic開発ワークフローを支援する。1つのペインにClaude Codeのようなコーディングエージェント、別のペインにシェル、3つ目のペインにワークスペースのファイルビューを表示できる
  • 観察された実用上の利点として、Warpは現代のコーディングエージェントが生成する高スループットなテキスト出力を、従来のターミナルよりもうまく処理しており、レンダリング速度や可読性がボトルネックになり得る状況で有効
  • 組み込みのコーディングアシスタントも追加されたが、チームではまだ広範な評価は行っていない
  • Warpは最近、ターミナルと統合されるクラウドエージェント向けオーケストレーションプラットフォームOzを公開したが、このblipはターミナル自体に焦点を当てている
  • 軽量で組み合わせ可能なターミナルを好み、自前のAIツールを持ち込みたいチームには、Ghosttyの方が適している可能性がある。Warpのbatteries-included哲学とは対照的に、意図的にミニマリストなアプローチを取っている
  • 新機能の追加ペースとWarpのより広範なプラットフォーム志向を踏まえると、製品の安定化と新しい能力に関する現場での経験がさらに蓄積されるまでは、Trialへ移すのは時期尚早である

96. WuppieFuzz

  • OpenAPI定義を使って有効なリクエストを生成し、エッジケースを探索するために変異させ、新しい実行パスに到達する入力を優先するためにサーバー側のカバレッジフィードバックに依存するREST API向けのオープンソースfuzzer
  • ほとんどのチームはいまだにサンプルベースの統合テストや契約テストに依存しており、予期しない入力、異常なリクエストシーケンス、失敗の多いパスをほとんど探索していない。APIはしばしば現代システムの主要な統合面であるにもかかわらず、その傾向がある
  • 初期評価に基づくと、WuppieFuzzはこうしたテストを有望に補完するものに見える。未処理の例外、認可の抜け穴、機密データ漏えい、サーバー側エラー、スクリプトテストでは見逃されがちなロジック欠陥のような問題を発見できる可能性がある
  • チームは依然として、CIにどう組み込めるか、導入によるランタイムオーバーヘッド、結果が実際にどれだけ有用かを評価する必要がある
  • そのため、重要または外部公開されたREST APIを構築しているチームにとって評価する価値がある

Caution

97. OpenClaw

  • 作者が**「hyper-personal AI assistant」カテゴリ**と呼ぶオープンソースプロジェクト
  • ユーザーは自分のインスタンスをホスティングし、WhatsAppやiMessageのようなメッセージングチャネルを通じて継続的に利用可能な状態を保ち、接続されたツール経由でタスクを実行できる
  • 会話、嗜好、習慣の永続メモリによって、GenAIチャットインターフェースや典型的なコーディングエージェントとは実質的に異なる、永続的で個人的な体験を生み出す
  • このモデルは明らかに魅力的で、Claude Coworkのような追随例にもすでに影響を与えている
  • OpenClawをCautionに配置した理由は、このモデルが大きなセキュリティ上のトレードオフを要求するため
  • カレンダー、メール、ファイル、通信へのアクセスを多く与えるほど有用になる一方で、toxic flow analysis for AIが警告したまさにそのパターンで権限集中が起きる
  • このリスクはOpenClaw固有のものではなく、確立されたベンダー製品を含む同様のパターンの他の実装にも当てはまる
  • OpenClawは、導入を検討するチーム向けの助言とサンドボックス実行環境を公開しており、NanoClawやZeroClawのような代替案は被害範囲を縮小できる可能性がある
  • しかし、hyper-personal assistantというパターン自体が権限を求めがちで、高リスクのままである

[Languages and Frameworks]

Adopt

98. Apache Iceberg

  • 大規模分析データセット向けのオープンテーブル形式で、S3のようなストレージシステム上でデータファイル、メタデータ、スキーマをどのように編成するかを定義する
  • ここ数年で大きく進化し、技術中立なlakehouseアーキテクチャの基盤となるビルディングブロックとして定着した
  • AWS（Athena、EMR、Redshift）、Snowflake、Databricks、Google BigQueryを含むすべての主要なデータプラットフォームベンダーがサポートしており、ベンダーロックイン回避の強力な選択肢となっている
  • Apache Icebergを他のオープンテーブル形式と差別化しているのは、機能とガバナンス全体にわたるオープンさであり、単一ベンダーによって能力が制限または統制される代替手段とは対照的である
  • 信頼性の面では、スナップショットベースの設計により、直列化可能分離、楽観的同時実行による安全な並行書き込み、ロールバックを含むバージョン履歴が提供され、性能ボトルネックなしに強力な正確性保証を実現する
  • Apache Sparkが最も一般的なエンジンだが、Trino、Flink、DuckDBなども十分にサポートしており、エンタープライズデータプラットフォームから軽量なローカル分析まで幅広いユースケースに適している
  • 多くのチームにおいて、安定していてオープンなデータ形式として強い信頼を獲得しており、現代的なデータプラットフォームを構築する組織のデフォルト選択として推奨される

99. Declarative Automation Bundles

  • 以前は Databricks Asset Bundles として知られており、Databricks エコシステムにソフトウェアエンジニアリングと CI/CD の実践を導入する主要なツールへと進化
  • 大きく成熟し、チームは クラスター、ETL パイプライン、ジョブ、機械学習モデル、ダッシュボード を含む大半のプラットフォームリソースをコードで管理可能
  • databricks bundle plan コマンドにより、チームは変更を事前に確認でき、Terraform のようなツールでインフラを管理するのと同様に、Databricks アーティファクトへ再現可能なデプロイ実践を適用可能
  • ダッシュボードや ML パイプラインのような従来は変更されやすい資産をコードとして扱うことで、従来のマイクロサービスと同等の厳密さでバージョン管理・テスト・デプロイが可能
  • 本番環境での経験に基づき、Declarative Automation Bundles は Databricks におけるデータおよび ML ワークフロー管理の信頼できるアプローチとして定着
  • Databricks エコシステムで幅広く作業するチームには、インフラ管理実践の標準化のため導入を検討することを推奨

100. React JS

  • 2016年以降、JavaScript UI 開発のデフォルトの選択肢だったが、React 19 の一部として React Compiler の安定版リリース が公開され（昨年10月）、再評価する価値がある
  • ビルド時にメモ化を処理するため、手動の useMemo や useCallback は 大半の場合不要 となり、effect 依存関係の精密な制御が必要な場合のエスケープハッチとしてのみ残すことを推奨
  • Meta で実戦投入され、Expo SDK 54、Vite、Next.js が対応しており、大規模な React 開発で長年コストとなっていた性能ボイラープレートのカテゴリを除去
  • React 19 は Actions と useActionState、useOptimistic のような hooks も導入し、外部ライブラリに依存せずフォーム処理とデータ変更を簡素化
  • 2025年には Linux Foundation 傘下で React Foundation が発足 — Amazon、Expo、Callstack、Microsoft、Software Mansion、Vercel が Meta に参加 — し、ライブラリの長期的な安定性を強化、導入検討時に慎重なチームが歴史的に挙げてきた懸念を解消

101. React Native

  • クロスプラットフォームのモバイル開発におけるデフォルトの選択肢として Adopt に移動
  • 以前は Trial だったが、New Architecture の展開 — 具体的には JSI と Fabric — により、ブリッジのボトルネックや初期化速度に関する長年の懸念を解消
  • 複雑な UI 遷移やデータ集約型ワークロードで 大きな性能向上 を観測
  • 非同期ブリッジから脱却したことで、React Native は現在、単一コードベースを維持しつつネイティブ実装に匹敵する応答性を提供
  • 複数の本番プロジェクトで成功裏に使われており、Expo と React 中心のエコシステムも成熟して安定的
  • 状態管理には依然として慎重な設計が必要だが、fast refresh ワークフローと共有スキルセットによる生産性の利点がそのコストを上回る
  • ほとんどのハイブリッドモバイルのユースケースにおいて、性能・一貫性・開発速度を追求するチームへの主要な推奨

102. Svelte

  • ビルド時にコンポーネントを最適化された JavaScript にコンパイルする JavaScript UI フレームワークで、大きなブラウザ側ランタイムや仮想 DOM に依存しない
  • 最後に Trial として紹介されて以降、より多くのチームが本番での利用に成功しており、SvelteKit が SSR とフルスタック Web アプリケーション向けのより堅牢な選択肢になったことで、Adopt へ移す自信が高まった
  • Svelte を選ぶ当初の理由は依然として有効 — 小さなバンドル、高いランタイム性能、よりシンプルなコンポーネントモデル
  • Svelte 5 の runes と snippets のような新機能が、リアクティビティと UI 構成をより明示的かつ柔軟にしている
  • より重いフロントエンドフレームワークと比べて、より少ないコードでよりクリーンな開発体験を提供
  • チームからのフィードバックでは次第に React や Vue の信頼できる代替 として挙げられており、もはやニッチな選択肢ではない
  • エコシステムへの習熟度、採用、市場適合性は引き続き考慮が必要だが、性能と提供のシンプルさが重要な現代的 Web アプリケーション構築における妥当なデフォルトとして推奨

103. Typer

  • 標準的な型アノテーション付き関数から CLI を構築する Python ライブラリで、自動ヘルプテキスト、シェル補完、小さなスクリプトから大規模な CLI アプリケーションへの明確な道筋を提供
  • チームが社内ツール、自動化、AI 周辺の開発者ワークフローを 一級の CLI に転換するにつれ、重要性が増している
  • Typer は実プロジェクトに導入しやすく、チームは明確で読みやすいコマンドをどれほど素早く作れるかを高く評価している
  • 強み — 型ヒントベースの API、自動ヘルプと自動補完、単純なスクリプトからマルチコマンド CLI への 低摩擦な移行パス
  • ただし Python 固有のソリューションであり、高度にカスタマイズされた CLI の挙動やクロス言語での一貫性が必要な場合には最適でない可能性がある
  • デリバリー、運用、開発者体験のワークフロー向けに CLI を構築するチームに推奨

Trial

104. Agent Development Kit (ADK)

  • AI エージェントの構築・運用のための Google フレームワークで、オーケストレーション・ツール・評価・デプロイ向けの ソフトウェアエンジニアリング志向の抽象化 を提供
  • Assess に掲載して以降、エコシステムと運用能力が大きく成熟し、活発な多言語開発と、より強力な可観測性・ランタイム機能を備える
  • ベンダーネイティブなエージェントフレームワークは現在混み合った分野であり、Microsoft Agent Framework、Amazon Bedrock AgentCore、OpenAI Agents SDK、Claude Agent SDK など競合オプションも進展中
  • LangGraph や CrewAI のようなオープンソースの代替は、フレームワーク移植性とより広いエコシステムを優先するチームにとって依然として強力な選択肢
  • ADK は一部で pre-GA 状態のままだが、時折粗い部分やアップグレード時の摩擦はあるものの、特に Google プラットフォームに投資しているプロジェクトでより多くの成功事例が観測されている

105. DeepEval

  • LLMの性能評価向けオープンソースのPythonベースフレームワーク
  • LlamaIndex や LangChain のようなフレームワークで構築された RAG システムやアプリケーションの評価、モデルの ベースラインとベンチマーク にも利用可能
  • 単純な単語マッチング指標を超えて、正確性、関連性、一貫性の評価により、実世界のシナリオでより信頼できる評価を提供
  • 幻覚検出、回答関連性スコア、ハイパーパラメータ最適化といった機能を含み、チームがカスタムユースケースごとの指標を定義できる点が特に有用
  • 最近 DeepEval は、複雑な agentic ワークフローとマルチターン対話システムのサポートへと拡張
  • 最終出力の評価を超えて、tool correctness、step efficiency、task completion 向けの組み込み指標を提供し、MCP サーバーとの相互作用の評価も含む
  • 大規模なマルチターンアプリケーションのストレステストのために、テストケースを自動生成する conversation simulation も導入

106. Docling

  • 非構造化文書を整った機械可読な出力へ変換するオープンソースのPythonおよびTypeScriptライブラリ
  • レイアウトと意味の理解にコンピュータビジョンベースのアプローチを使用し、スキャン文書を含む PDF のような複雑な入力を JSON や Markdown のような構造化形式へ処理
  • RAG パイプラインや LLMでの構造化出力 の生成に適しており、ColPali のようなビジョン優先の検索アプローチとは対照的
  • Docling は、Azure Document Intelligence、Amazon Textract、Google Document AI のような独自クラウド管理サービスに対するオープンソースのセルフホスト代替を提供し、LangGraph のようなフレームワークともよく統合される
  • テキスト、表、画像を含む非常に大きなファイルも含め、デジタルおよびスキャン PDF 全般で本番規模の抽出ワークロードで良好に機能
  • 下流の agentic RAG ワークフローに高い品質とコストのバランスをもたらす

107. LangExtract

  • ユーザー定義の指示に基づいて非構造化テキストから構造化情報を抽出するPythonライブラリで、抽出された各エンティティを元文書中の位置に結び付ける精密なソースグラウンディングを含む
  • 臨床ノートやレポートのようなドメイン特化の資料を処理
  • 中核的な強みはソース追跡性であり、抽出された各データポイントが出典まで追跡可能であることを保証
  • 抽出したエンティティは、言語モデルデータの標準形式である JSONL ファイルにエクスポートでき、文脈的レビューのためのインタラクティブな HTML インターフェースで可視化可能
  • 文書処理向けに LLMでの構造化出力 を検討しているチームは、LangExtract を Pydantic AI のようなスキーマ強制アプローチとあわせて評価する必要がある
  • LangExtract は長文で非構造化なソース資料により適しており、Pydantic AI はより短く予測可能な入力に対する出力形式の制約に優れる

108. LangGraph

  • 前回の Radar 以降、すべてのマルチエージェントシステムをグローバル共有状態を持つステートフルグラフとして扱う LangGraph アーキテクチャが、agentic システム構築の最良策とは限らないことを確認
  • Pydantic AI のようなフレームワークで使われる代替アプローチもうまく機能
  • 硬直的なグラフと大規模な共有状態から始める代わりに、このアプローチはコード実行によるシンプルなエージェント間通信を優先し、必要に応じて後からグラフ構造を追加
  • 多くのユースケースでより簡潔で効果的なシステムを生み出し、各エージェントが必要な状態にのみアクセスするため、推論・テスト・デバッグが容易になる
  • その結果、Adopt から移動し、依然として強力なツールではあるものの、すべての agentic システム構築におけるデフォルトの選択肢とはもはや見なしていない

109. LiteLLM

  • 複数の LLM プロバイダーの上に載る薄い抽象化レイヤーとして始まり、本格的な AI ゲートウェイへ拡張
  • API 統合の単純化を超えて、GenAI システムの一般的な横断的関心事を解決 — リトライとフェイルオーバー、プロバイダー間ロードバランシング、予算管理を含むコスト追跡を含む
  • チームはますます LiteLLM を AI ベースアプリケーションの合理的なデフォルトとして採用
  • ゲートウェイは、リクエスト追跡、アクセス制御、API キー管理、コンテンツフィルタリング、データ修正・マスキングのようなエッジレベルのガードレールを含むガバナンス上の関心事に対して、一貫した対応場所を提供
  • しかし、差別化されたプロバイダー機能に依存するチームでは、しばしばプロバイダー固有のパラメータが必要となり、ゲートウェイが取り除こうとする結合が再導入される
  • drop_params モードはサポートされていないパラメータを黙って破棄するため、ルーティング判断全体にわたり可視性のないまま機能が失われる可能性がある
  • 運用統制のための実用的な選択肢ではあるが、プロバイダー固有機能の活用は、ゲートウェイ依存とプロバイダー結合コードの両方を維持することを意味する

110. Modern.js

  • ByteDance の React メタフレームワークで、Module Federation ベースのマイクロフロントエンド要件を持つチーム向けに Trial に配置
  • きっかけは実務的なもの — nextjs-mf が寿命終了 (end-of-life) に向かっており、Pages Router は小規模なバックポート修正のみを受ける予定で、新規開発は計画されておらず、CI テストは 2026 年後半に削除される見込み
  • Next.js に公式な Module Federation サポートがなく、コミュニティプラグインも段階的に廃止される中、Module Federation コアチームはfederation ベースアーキテクチャの主要サポートフレームワークとして Modern.js を推奨
  • @module-federation/modern-js-v3 プラグインは自動ビルド配線を即座に提供し、ストリーミング SSR と Bridge API は個別機能として利用可能
  • ただし結合には制限があり、@module-federation/bridge-react はまだ Node 環境と互換性がないため、SSR シナリオでは Bridge を利用できない
  • 初期の経験は良好で、すでに Module Federation を使っているチームにとって移行パスも明確
  • ByteDance 外のエコシステムは依然として成熟途上であり、より薄い文書ではなく、より充実したドキュメントと上流との緊密な関与計画が必要
  • 現時点では、よりよくサポートされた代替がないModule Federation のユースケースにおいて投資を正当化

Assess

111. Agent Lightning

  • 自動プロンプト最適化、教師ありファインチューニング、agentic強化学習を可能にするエージェント最適化・訓練フレームワーク
  • ほとんどのエージェントフレームワークはエージェント構築に集中しており、時間経過に伴う改善には注力していない
  • Agent LightningはAutoGenやCrewAIのようなフレームワークをサポートし、基本実装を変更せずに既存エージェントを継続的に改善できるようにする
  • Training-Agent Disaggregationというアプローチによって実現されており、訓練とエージェントフレームワークの間にレイヤーを導入する
  • 2つのコアコンポーネントから成る — Lightning Serverが訓練プロセスを管理し、更新されたモデル向けAPIを公開し、Lightning Clientがトレースを収集して訓練支援のためにサーバーへ送信するランタイムとして機能する
  • すでに確立されたエージェント導入を持つチームには、エージェント性能を継続的に改善する方法として検討を勧める

112. GitHub Spec Kit

  • 今回のサイクルの議論ではSpec-driven developmentが際立っており、大きく2つの陣営が現れている — 最小限の構造でコーディングエージェントの継続的改善能力に依存するチームと、定義されたワークフローと詳細な仕様を好むチーム
  • 複数のチームが主にブラウンフィールド環境でGitHub Spec Kitを使い、spec-drivenな実践を試験している
  • Spec Kitの中核概念はconstitutionであり、ソフトウェア開発ライフサイクルを整合させる基礎的なルールブックである
  • 実際に有用なconstitutionは通常、プロジェクト範囲、ドメインコンテキスト、技術バージョン、コーディング標準、リポジトリ構造（例: ヘキサゴナルアーキテクチャ、レイヤードモジュール）を捉え、エージェントが意図されたアーキテクチャ境界内で動作する助けとなる
  • instruction bloatのような課題も生じている — プロジェクトコンテキストを継続的に追加することで増大するエージェント指示セットと、最終的なcontext rotであり、あるチームは再利用可能なガイダンスをスキルとして抽出し、必要なときだけ詳細コンテキストを読み込むことでエージェント指示を簡潔に保って解決した
  • ブラウンフィールドシステムでは、多くの手戻りが不明確な意図、隠れた前提、制約の発見の遅れに起因しており、あるチームはspec → plan → tasks → coding → reviewライフサイクルを導入して、こうした問題の早期顕在化に役立てた
  • 時間の経過とともに、反復可能なコンテキストを.github/prompts/speckit.<command>.prompt.mdのようなファイルへ移し、プロンプトは短くなり、エージェントの挙動はより一貫した
  • 不要な防御的チェックや過度に冗長なmarkdown出力のような粗い部分も報告されている
  • Spec Kitのテンプレートと指示のカスタマイズ（例: 生成されるmarkdownファイル数の制限、コンソールの冗長さの低減）によって、一部の問題は解決できる
  • 最終的には、強いクリーンコーディングとアーキテクチャ実践を持つ経験豊富なエンジニアがspec-drivenワークフローから最も大きな価値を引き出す

113. Mastra

  • AIアプリケーションとエージェント構築のためのオープンソースのTypeScriptネイティブフレームワーク
  • グラフベースのワークフローエンジン、多様なLLMプロバイダーへの統合アクセス、human-in-the-loopの一時停止・再開、RAGとメモリプリミティブを提供
  • MCPサーバー作成と評価・オブザーバビリティ向けの組み込みツールも含み、明確な開発者ドキュメントに支えられている
  • MastraはPython中心の重いスタックに代わる選択肢を提供し、チームがNode.jsやNext.jsのような既存のWebエコシステム内で直接豊かなAI機能を構築できるようにする
  • AIレイヤーのためにPythonへ切り替えたくないTypeScriptエコシステムに投資しているチームにとって評価する価値がある

114. Pipecat

  • STT、LLM、TTS、転送のオーケストレーション向けモジュラーなパイプラインモデルでリアルタイム音声とマルチモーダルエージェントを構築するオープンソースフレームワーク
  • チームが会話挙動を素早く反復し、比較的低い摩擦でプロバイダーを切り替えられるため、強い関心を集めている
  • LiveKit Agentsと比べると、Pipecatはより大きなフレームワーク柔軟性を提供するが、より統合されたプロダクションへの道筋には欠ける。特にセルフホスト配備、転送信頼性、大規模な低遅延ターン処理においてそうである
  • 強力なエンジニアリングの土台を提供するが、ビジネスクリティカルな本番ワークロードで利用する前には相当なプラットフォームエンジニアリング作業が必要

115. Superpowers

  • コーディングエージェントの利用増加に伴い、すべてのチームに当てはまる単一のワークフローは存在せず、代わりに各チームがコンテキストと制約に基づいて独自のワークフローを進化させている
  • Superpowersはそのようなワークフローの1つで、組み合わせ可能なスキルで構築されている
  • コーディングエージェントを構造化されたワークフローのスキルとして包み込み、コーディング前のブレインストーミング、実装前の詳細計画、強制されたred-green-refactorサイクルによるTDD、体系的な根本原因優先のデバッグ、実装後のコードレビューを促進する
  • Claude Code plugin marketplaceとCursor plugin marketplaceを通じてプラグインとして配布されている

116. TanStack Start

  • TanStack Routerの上に構築されたReactとSolid向けのフルスタックフレームワークで、Next.jsと比較可能であり、SSR、キャッシュ、その他多くの同様の機能をサポートする
  • TanStack Startは、サーバー関数、ローダー、ルーティング全体でエンドツーエンドのコンパイル時安全性を提供し、フロントエンドにおけるリンク切れやデータ形状の不一致リスクを減らす
  • 慣習よりも明示的な構成を好み、体験はplain Reactでの作業により近い
  • SSR機能を必要に応じて段階的に追加できる
  • 内部動作に不慣れだと予期しない挙動を招きうる、より強い意見を持ったデフォルトを備えるNext.jsに比べ、より明示的で予測しやすい
  • TanStackエコシステムも大きく成熟しており、現代的なWebアプリケーション構築のための強力なツールセットを提供している

117. TOON (Token-Oriented Object Notation)

  • 構造化データがLLMに渡される際、トークン使用量削減のために設計されたJSONデータの人間可読エンコーディング
  • 既存システムではJSONを維持しつつ、モデルとの相互作用ポイントでのみ変換できる
  • トークンコスト、遅延、コンテキストウィンドウ制約が、RAGパイプライン、エージェントワークフロー、その他のAI中心アプリケーションにおいて実際の設計上の考慮事項になりつつある
  • 生のJSONはしばしば、有用なコンテンツよりも繰り返されるキーと構造的オーバーヘッドにトークンを消費する
  • 初期評価では、TOONはプロンプト入力における興味深いラストマイル最適化であり、特にスキーマ認識形式がJSONより効率的で、モデルが処理しやすい大規模で規則的なデータセットに向いている
  • API、データベース、モデル出力におけるJSONの代替ではなく、深くネストした構造や不均一な構造、半均一配列、CSVのほうがよりコンパクトなフラットな表形式データにはしばしば適さない選択である
  • コンパクトJSONがうまく機能する遅延重視の経路にもあまり適していない可能性がある
  • 構造化入力サイズがコストや品質の面で意味のある関心事となるLLMアプリケーションを構築するチームにとって評価する価値があり、自前のデータとモデルスタックでJSONやCSVと比較ベンチマークする必要がある

118. Unsloth

  • LLMのファインチューニングと強化学習をかなり高速かつメモリ効率よく実現することに注力したオープンソースフレームワーク
  • LLMのファインチューニングには数十億回の行列積が含まれ、GPUアクセラレーションの恩恵を受けるが、Unsloth はこうした演算をNVIDIA GPU向けの高効率なカスタムカーネルへ変換して最適化し、コストとメモリ使用量を劇的に削減
  • 高価なH100クラスターの代わりに、T4以上のコンシューマー向けGPUでモデルをファインチューニング可能にする
  • LoRA、フルファインチューニング、マルチGPUトレーニング、長コンテキストのファインチューニング（最大500Kトークン）をサポートし、Llama、Mistral、DeepSeek-R1、Qwen、Gemmaを含む人気モデルに対応
  • ドメイン特化型AIアプリケーションがますますファインチューニングに依存するようになる中、Unslothは参入障壁を大きく引き下げる

関連記事

まだコメントはありません。

まだコメントはありません。